Quantcast
Channel: 不自量力 の Weithenn
Viewing all 591 articles
Browse latest View live

全新發佈 Nutanix Community Edition 2.1

$
0
0


簡介

日前,Nutanix 官方正式發佈新版 Nutanix Community Edition 2.1, 想要試試新功能的朋友不要錯過了。

新版 Nutanix Community Edition 2.1 中,包括大量新功能 AOS 6.6AOS 6.7AOS 6.8AOS 6.8.1 (maintenance release),還包括 Prism Central 2024 v4 API,也有適合用於 CE 小型環境的 X-Small Prism Central。





Recommended Hardware

在安裝新版 Nutanix Community Edition 2.1 之前,請參考 Community HCL 和對圖中的建議硬體規格。




Install Process Overview

影片中,使用 Intel NUC 當 Lab 主機,下列是硬體規格和網路環境規劃,以及整個 Nutanix CE 2.1 安裝流程示意圖。




活用 Azure Stack HCI 23H2 新版建超融合叢集 | 網管人 223 期

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 223 期 - 2024 年 8 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

隨著 Microsoft Ignite 2023 大會,順勢發佈的最新 Azure Stack HCI 23H2 公開預覽版(Public Preview),最大功能亮點在於,微軟觀察到零售、製造、醫療……等行業,在實際營運環境中,經常會分佈在許多地理位置不同的邊緣地點,這些邊緣地點的營運環境不僅分散,並且也非企業和組織常見的地端資料中心內完善的運作環境。

因此,對於這樣新興的營運環境需求,從最新的 Azure Stack HCI 23H2 版本開始,嘗試支援從 Azure 公有雲環境,部署及管理這些地理位置不同邊緣地點中的 HCI 超融合環境(如圖 1 所示)。
後續會將 Azure Stack HCI 超融合基礎架構,簡稱為 AzSHCI。
圖 1、透過 Azure 公有雲同時管理不同地理位置的 HCI 超融合叢集





Azure Stack HCI 23H2 特色功能

雲端部署

那麼 AzSHCI 超融合叢集,是如何達成「雲端部署」(Cloud-Based Deployment)的呢 ?首先,企業和組織採購的伺服器到達邊緣位置後,倘若已經預先安裝好 AzSHCI 超融合作業系統時,那麼現場人員只需要確保網路連線,並與 Azure Arc 建立初始網路連線後,屆時便可以透過 Azure 公有雲環境,從 AzSHCI 超融合叢集部署、儲存集區資源、網路組態設定……等完成,倘若有數量龐大的邊緣位置需要部署時,也可以透過「Azure 資源管理員」(Azure Resource Manager,ARM),以「基礎架構即程式碼」(Infrastructure-as-Code,IaC)的方式,進行大規模的部署作業。



集中管理所有工作負載

由於邊緣位置的 AzSHCI 超融合叢集,已經透過 Azure Arc 基礎架構串連在一起,所以管理人員在 Azure Portal 管理介面中,可以開始設定和啟用 Arc 虛擬主機、Azure Kubernetes Service(AKS)容器叢集、Azure Virtual Desktop(AVD)虛擬桌面會話主機(如圖 2 所示),讓管理人員可以在同一個管理介面中,分別管理和部署不同的工作負載類型。

圖 2、透過 Azure Portal 管理介面,部署和管理不同地理位置的工作負載



支援可信任啟動安全性機制

在現今的網際網路環境中,網路威脅情勢不斷的迅速變化,攻擊手法也轉變為日趨複雜,然而隨著企業和組織的數位轉型風潮,導致許多營運用途的應用程式和基礎設施處於邊緣位置。因此,在最新的 Azure Stack HCI 23H2 版本中,將各項安全性設定與 Microsoft Defender for Cloud 進行整和,讓屆時 AzSHCI 超融合叢集所部署的 VM 虛擬主機,也支援可信任啟動保護虛擬機器選項(如圖 3 所示),確保部署的 VM 虛擬主機,能夠更有效阻擋不斷演變的惡意攻擊手法。

圖 3、AzSHCI 超融合叢集支援部署可信任啟動保護 VM 虛擬機器選項





實戰 – Azure Stack HCI 23H2 單節點叢集

由於本文撰寫期間,Azure 公有雲的 AzSHCI 雲端部署功能,僅支援採用實體伺服器,尚未支援 VM 虛擬主機進行部署。因此,在實戰演練小節中,將使用巢狀式技術搭配地端資料中心的部署方式,建構 AzSHCI 超融合叢集環境。



部署支援巢狀技術VM虛擬主機

原則上,只要採用支援的硬體主機和作業系統版本,便能部署 AzSHCI 超融合叢集,然而對於中小型企業和組織來說,IT 管理人員可能沒有多台或符合軟硬體需求的主機。此時,便可以在內部資料中心內,部署支援巢狀式 VM 虛擬主機環境,或是透過 Azure 公有雲環境,部署支援巢狀式虛擬化環境的 VM 虛擬主機。

值得注意的是,無論是內部資料中心自建或採用 Azure 公有雲環境,部署支援巢狀式虛擬化環境的 VM 虛擬主機,所建構的 AzSHCI 超融合叢集,都僅適用於研究和測試用途,不適用於真實營運環境。此外,AzSHCI 單節點超融合叢集,僅支援採用單一儲存裝置,例如,NVMe 或 SSD 的 All-Flash 運作架構,不支援採用混合式儲存裝置,例如,NVMe+SSD、NVMe+HDD、SSD+HDD……等,這是採用實體伺服器建構 AzSHCI 單節點超融合叢集時,必須特別注意的地方。

在實戰演練小節中,將會在一台支援巢狀式虛擬化的 Azure VM 虛擬主機中,建立多台 VM 虛擬主機,達成部署 AzSHCI 超融合叢集的目的。值得注意的是,Azure VM Gen2 世代虛擬主機,預設在安全性類別採用「Trusted launch virtual machines」選項,以便支援 Secure Boot 和 vTPM 等新式安全性機制,但此舉卻會導致巢狀式虛擬化機制無法運作。

因此,在建立支援巢狀式虛擬化的 Azure VM 虛擬主機時,請記得將安全性類別選擇為「Standard」項目(如圖 4 所示),才能確保巢狀式虛擬化技術正常運作,詳細資訊請參考 Azure VM 的可信任啟動 - Azure Virtual Machines | Microsoft Learn 官方文件說明。

圖 4、選擇安全性類別為 Standard 確保巢狀式虛擬化功能順利運作

由於在 Azure 公有雲環境中,管理人員無法碰觸到 Azure 公有雲底層的 Hyper-V 虛擬化平台。因此,必須建立 NAT vSwitch 虛擬交換器,以便稍後建立的 DC 網域控制站和 AzSHCI 虛擬主機,能夠透過第一層 Hypervisor 虛擬化管理程序,所建立的 NAT vSwitch 虛擬交換器進行網路封包路由。

在本文實作環境中,建立的 NAT vSwitch 虛擬交換器名稱為「AzSHCI-NATSwitch」,稍後處理的網路位址轉譯 IP 網段為「10.10.75.0/24」,預設閘道 IP 位址為「10.10.75.1」。

請在 Azure VM 虛擬主機中,開啟 PowerShell 指令視窗並鍵入「New-VMSwitch -Name "AzSHCI-NATSwitch" -SwitchType Internal」指令,建立給第二層 VM 虛擬主機使用的 NAT vSwitch 虛擬交換器,並且連接類型為「Internal network」(如圖 5 所示)。

圖 5、透過 Hyper-V 管理員查看建立的 NAT vSwitch 虛擬交換器

執行「New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet(AzSHCI-NATSwitch)"」指令,為這台 NAT vSwitch 虛擬交換器,組態設定預設閘道 IP 位址為「10.10.75.1」。

執行「New-NetNat -Name "AzSHCI-NATSwitch" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"」,組態設定這台 NAT vSwitch 虛擬交換器,處理的 NAT 網路位址轉譯 IP 網段為「10.10.75.0/24」。

一旦 NAT vSwitch 虛擬交換器成功建立並組態設定完成後,管理人員可以分別執行「Get-VMSwitch」、「Get-NetIPAddress -IPAddress 10.10.75.1」、「Get-NetNat」等指令,確認 NAT vSwitch 虛擬交換器組態設定內容是否正確無誤,避免後續發生網路不通或無法路由的情況。



部署 DC 和 AzSHCI 主機

首先,請分別下載 Windows Server 2022 印象檔,以及最新版本的 Azure Stack HCI 23H2 印象檔  。在本文實作環境中,新增一台 VM 虛擬主機,擔任 DC 網域控制站的角色,組態設定的 IP 位址為「10.10.75.10」,並部署建立「lab.weithenn.org」的網域名稱(如圖 6 所示),同時建立 DNS 名稱解析服務,以及稍後 AzSHCI 主機能夠加入網域環境,並使用正確的 DNS 名稱解析。

圖 6、部署並建立 lab.weithenn.org 網域名稱

為了方便讀者建立 AzSHCI 超融合叢集環境,將採用「單台」節點主機的方式建立。值得注意的是,單台節點主機的 AzSHCI 超融合叢集環境,至少要採用 Azure Stack HCI 22H2 版本,或是本文採用的最新 Azure Stack HCI 23H2 版本才行。

在建立 AzSHCI 主機時,除了作業系統硬碟之外,還額外配置四個 3TB SSD 固態硬碟,屆時為超融合儲存集區的儲存空間,在 AzSHCI 主機處於關機狀態時,執行「Set-VMProcessor -VMName $HCINode -ExposeVIrtualizationExtensions $true」指令,為名稱為「AzSHCI」的第二層 VM 虛擬主機,啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能,確保 AzSHCI 主機能夠正確接收到,底層 Hyper-V 虛擬化平台所公開和傳遞而來,Intel VT-x 及 EPT 硬體輔助虛擬化技術,順利啟用後請再次進行確認,「ExposeVirtualizationExtensions」欄位值是否為「True」,確保啟用的工作任務已套用生效(如圖 7 所示)。

圖 7、為 AzSHCI 主機啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能

原則上,AzSHCI 主機超融合作業系統的安裝流程,和傳統 Windows Server 安裝程序相同(如圖 8 所示),安裝作業完成後系統將自動彈出命令提示字元視窗,並提醒管理人員設定 Administrator 管理者密碼,完成管理者密碼設定之後,便自動進入 「伺服器組態設定工具」(Server Configuration Tools,SConfig)互動設定視窗。

圖 8、安裝最新 Azure Stack HCI 23H2 版本超融合作業系統

透過 SConfig 伺服器組態設定工具,管理人員可以輕鬆為 AzSHCI 主機,進行基礎架構的組態設定作業,包含,電腦名稱、IP 位址網路組態設定、變更系統時區和時間、安裝最新安全性更新、加入網域環境……等工作任務。

在本文實作環境中,將 AzSHCI 虛擬主機的電腦名稱變更為「AzSHCI」、網路組態設定固定 IP 位址為「10.10.75.23」、變更系統時區為「(UTC + 8)Taipei」、在安裝完最新安全性更新並重新啟動完畢後,加入「lab.weithenn.org」網域環境(如圖 9 所示)。

圖 9、為 AzSHCI 主機進行基礎設定並加入 lab.weithenn.org 網域環境

AzSHCI 主機基礎設定完成後,請先確認額外配置的四個 3TB SSD 固態硬碟,是否能夠正確被系統識別,確保稍後建立超融合儲存集區時,能夠順利將 SSD 固態硬碟加入並匯整至儲存集區內,成為日後 VM 虛擬主機或容器等工作負載的儲存資源。

管理人員,可以直接開啟 AzSHCI 主機的 Console 畫面,離開 SConfig 伺服器組態設定工具後進入 PowerShell 指令環境,或是在 Azure VM 虛擬主機環境中,執行「Enter-PSSession -VMName "AzSHCI" -Credential lab.weithenn.org\Administrator」指令,待通過使用者身份驗證程序後,遠端連線至 AzSHCI 主機的 PowerShell 指令環境。

執行「Get-PhysicalDisk | Sort-Object -Property Size」指令,檢查 AzSHCI 主機儲存裝置,並以 Size 欄位將顯示結果進行排序,請確保四個 3TB SSD 固態硬碟中,每個 CanPool 欄位值皆為「True」,屆時這四個儲存裝置才能順利加入至超融合儲存集區中(如圖 10 所示)。

圖 10、確保系統識別四個 3TB SSD 固態硬碟且 CanPool 欄位為 True

執行「Install-WindowsFeature」指令,為 AzSHCI 主機安裝必要的伺服器角色和功能,例如,DCB 資料中心橋接(Data-Center-Bridging)、容錯移轉叢集(Failover-Clustering)、檔案伺服器(FS-FileServer)、Hyper-V PowerShell 管理工具……等,系統在安裝完畢後,提醒必須重新啟動主機才能套用生效。

由於 Install-WindowsFeature 安裝指令,會在安裝過程中執行相容性檢查,但因為本文是巢狀虛擬化測試環境,倘若使用 Install-WindowsFeature 指令,為 Azure Stack HCI 超融合作業系統,安裝 Hyper-V 虛擬化功能時,將會因為相容性檢查作業未通過而發生失敗的情況。

因此,請改為使用「Enable-WindowsOptionalFeature -Online -FeatureName "Microsoft-Hyper-V" -All -NoRestart」,確認安裝結果為 True 之後,再執行「Restart-Computer」指令重新啟動主機,以便安裝的伺服器角色和功能套用生效(如圖 11 所示)。

圖 11、為 AzSHCI 主機安裝超融合環境需要的伺服器角色和功能



建立容錯移轉叢集並啟用 HCI 超融合功能

由於,在本文撰寫期間,最新的 WAC(Windows Admin Center)2311 版本,仍尚未支援部署和組態設定「單台」AzSHCI 超融合運作環境。但若是透過 Azure Arc 在 Azure Portal 的話,則支援部署單台 AzSHCI 超融合運作環境。

管理人員可以使用 PowerShell 指令,執行部署單節點超融合叢集的動作。請執行「New-Cluster -Name HCI-Cluster -Node AzSHCI -NOSTORAGE -StaticAddress 10.10.75.20」指令,部署的容錯移轉叢集名稱為「HCI-Cluster」,節點主機名稱為「AzSHCI」,容錯移轉叢集的 IP 位址則是「10.10.75.20」,值得注意的是必須加上「-NOSTORAGE」參數。

順利部署容錯移轉叢集後,執行「Enable-ClusterStorageSpacesDirect -CacheState Disabled」指令,啟用 Storage Spaces Direct 的 HCI 超融合技術,並且停用儲存體快取機制,在系統詢問是否啟用 HCI 超融合技術時,鍵入 A 即可,當系統啟用完成後便會產生名稱為 EnableClusterS2D 的 HTML 格式報表檔案,執行「Get-StoragePool」指令,可以看到系統已經透過啟用 HCI 超融合技術,將四個 3TB SSD 固態硬碟空間,匯整為 12TB 的儲存集區(如圖 12 所示)。

圖 12、建立容錯移轉叢集並啟用 HCI 超融合技術



註冊 WAC 管理平台

雖然,最新版本的 WAC 管理平台,尚未支援部署單節點 AzSHCI 超融合叢集,但是當管理人員手動部署 HCI 超融合叢集後,同樣可以透過 WAC 管理平台,管理和組態設定 AzSHCI 超融合叢集,並新增及建立相關工作負載,例如,VM 虛擬主機、容器……等。

由於 WAC 安裝程式,無法安裝在 DC 網域控制站中,所以建立另一台安裝 Windows 10 的 VM 虛擬主機,並安裝 WAC 管理平台。順利通過使用者身份驗證機制,登入 WAC 管理平台後,請依序點選「Add > Add or create resources > Server Clusters > Add」,在Add Cluster欄位中鍵入「HCI-Cluster.lab.weithenn.org」叢集名稱,系統便會自動掃描和探索到此 HCI 超融合叢集(如圖 13 所示)。

圖 13、在 WAC 管理平台中新增管理名稱為 HCI-Cluster 的超融合叢集

順利連線並納管 HCI-Cluster 超融合叢集後,管理人員便可以透過 WAC 管理平台,查看 AzSHCI 超融合叢集的各種使用率和工作負載資訊,包括,超融合叢集節點主機數量和資訊、儲存裝置數量和資訊、管理 VM 虛擬主機、超融合叢集 CPU/Memory/Storage 資源使用資訊、IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率……等。

在 WAC 管理介面中可以看到,系統提示必須先將此台 WAC 管理平台,註冊至 Azure 公有雲環境中(如圖 14 所示),才能為剛才部署的單節點 AzSHCI 超融合叢集進行註冊的動作,後續才能導入 Azure Monitor 監控機制、啟用 Azure Benefits 權益、建置 AKS 容器平台……等,達成混合雲運作架構。

圖 14、系統提示必須先註冊 WAC 管理平台

請在 WAC 管理平台中,依序點選「Settings > Register > Register with Azure > Register」,在彈出的對話視窗中,請於 Select an Azure cloud 下拉選單中選擇「Azure Global」項目,然後在 Copy this code 欄位中按下 Copy 鈕,並按下 Enter the code 連結,此時瀏覽器將會另開新頁,請貼上剛才複製的 Code 內容,通過使用者身份驗證程序後,系統會提示關閉該新開分頁。

回到原 WAC 管理介面視窗中,可以發現多了 Connect to Microsoft Entra ID 的訊息(舊稱為 Azure AD),並顯示 Microsoft Entra(tenant)ID 資訊,請在下拉選單中選擇採用的 Microsoft Entra ID 後,選擇 Use Existing 或 Create New 選項後按下 Connect 鈕,當系統順利連接至 Microsoft Entra ID 環境後,便會顯示 Now connected to Microsoft Entra ID 訊息,請按下 Sign in to Azure 選項中的 Sign in 鈕(如圖 15 所示),即可將此台 WAC 管理主機,註冊至指定的 Azure 訂閱帳戶和 Microsoft Entra ID 環境中。

圖 15、註冊 WAC 管理主機至指定的 Azure 訂閱帳戶和 Microsoft Entra ID 環境中

值得注意的是,在繼續下一步動作之前,必須先組態設定 WAC 管理主機,提升並擁有相關 API 權限,否則後續進階操作將會失敗。請登入 Azure Portal 後,依序點選「Microsoft Entra ID > Manage > App registrations > All applications > WAC > Manage > API permissions」項目,點選其中一個 Delegated 項目後,點選「Grant admin consent for」項目後,狀態便會從原本的 Not granted 轉變為 Granted(如圖 16 所示)。

圖 16、為已註冊的 WAC 管理主機提升 API 權限

回到 AzSHCI 超融合叢集 Dashboard 頁面中,點選 Azure connection 中的 Register this cluster 連結,在彈出的 Register Azure Stack HCI 對話框中,請在 Azure subscription ID 下拉選單中,選擇要使用的 Azure 訂閱帳戶,並在 Azure Resource Group 欄位中選擇 Create new 項目,鍵入資源群組名稱,本文實作為「RG-EastAsia-AzSHCI」,在 Azure Region 選擇此資源群組所要使用的 Azure 資料中心,選擇 Azure 東亞機房「East Asia」,展開 Advanced 勾選「Enable Azure Arc」項目,連同 Azure Arc管理機制一同安裝並註冊使用,確認無誤後按下 Register 鈕,立即進行向 Azure 公有雲註冊 AzSHCI 叢集和 Azure Arc 管理機制。

註冊流程開始後,系統將會彈出 CredSSP 視窗,請鍵入連接 AzSHCI 超融合叢集時,使用的 CredSSP connection 使用者帳號及密碼,通過使用者身份驗證程序註冊成功後,可以手動開啟另一個視窗,登入 Azure Portal 中的 Resource Group,可以看到剛才指定的「RG-EastAsia-AzSHCI」資源群組已成功建立,進入後在 Resources 區塊中,可以看到註冊成功的「HCI-Cluster」超融合叢集。

確認 AzSHCI 超融合叢集註冊成功後,切換回 WAC 管理平台介面,系統顯示註冊成功資訊,而 Azure Connection 區塊中的 Status 狀態資訊,也從原本紅色錯誤的 Not yet registered 狀態,轉變為綠色打勾的 Connected 狀態(如圖 17 所示)。

圖 17、成功註冊 AzSHCI 單節點超融合叢集



選擇採用精簡佈建磁碟區

首先,為 AzSHCI 單節點超融合叢集,建立新式的「精簡佈建」(Thin Provisioning)磁碟區,以供後 VM 虛擬主機、容器、或檔案伺服器……等工作負載使用。

值得注意的是,雖然 AzSHCI 超融合叢集已全面支援精簡佈建磁碟區,然而預設情況下,系統預設值仍為「固定」(Fixed)磁碟區。因此,管理人員可以在建立磁碟區之前,在 WAC 管理介面中,依序點選「HCI-Cluster > Configuration > Settings > Storage > Storage Spaces and pools > Storage Pool : S2D on HCI-Cluster > Default Provisioning Type」,將預設值的 Fixed 選項,改為選擇「Thin」選項後,按下 Save 鈕將磁碟區預設值,修改為採用精簡佈建磁碟區(如圖 18 所示)。

圖 18、調整 AzSHCI 單節點超融合叢集預設改採精簡佈建磁碟區

雖然,將部署磁碟區的預設值,調整為精簡佈建磁碟區,但是在建立磁碟區的過程中,管理人員還是可以根據需求,為即將建立的磁碟區調整類型為固定或精簡佈建,舉例來說,在建立磁碟區的過程中,鍵入磁碟區名稱和 Size 空間大小的數值後,只要點選 More options 展示進階選項,便可以在 Provision as 區塊中,選擇採用固定(Fixed)或精簡佈建(Thin),確認後按下 Create 鈕即可(如圖 19 所示)。

圖 19、依據需求選擇建立固定或精簡佈建磁碟區

為了測試精簡佈建磁碟區的彈性,分別建立名稱為「Volume-2TB-Thin」的 2TB 精簡佈建磁碟區,和名稱為「Volume-10TB-Thin」的 10TB 精簡佈建磁碟區後(如圖 20 所示),稍後將查看實際佔用儲存集區多少空間。

圖 20、分別建立 2TB 和 10TB 的精簡佈建磁碟區

切換到 Dashboard 主頁後,可以看到雖然建立總共 12TB 大小的精簡佈建磁碟區,但是在 Used 欄位仍僅佔用「72 GB」儲存空間,而 Available 欄位仍有「11.9 TB」可供使用(如圖 21 所示),顯示精簡佈建磁碟區,確實能為企業和組織提供儲存空間彈性。

圖 21、採用精簡佈建磁碟區有效提升儲存空間可用率





結語

透過本文的深入剖析和實作演練後,相信管理人員除了理解最新 Azure Stack HCI 23H2 版本特色功能之外,透過實戰演練建立 AzSHCI 單節點超融合叢集,並部署精簡佈建磁碟區,以供後續 VM 虛擬主機和容器等工作負載使用,讓企業和組織的管理人員,能快速建立研發和測試 AzSHCI 超融合叢集環境。

Nutanix 叢集架構深入玩,動手部署 Prism Central | 網管人 224 期

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 224 期 - 2024 年 9 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

在 Nutanix 叢集運作架構中,最重要的三大核心元件分別是 AHV / AOS / Prism,其中 AHV 擔任 SDC 軟體定義運算,也就是虛擬化平台的角色,負責運作屆時的 VM 虛擬主機或 Pod/Container 容器等工作負載,而 AOS 擔任 SDS 軟體定義儲存角色,負責將每台 Nutanix 節點主機的本地端儲存資源進行整合,達成 HCI 超融合運作架構,至於 Prism 則是管理這些運作架構和工作負載,也就是整體基礎架構的集中式管理平台(如圖 1 所示)。

圖 1、Nutanix 叢集三大重要運作元件 AHV/AOS/Prism





Prism 管理平台特色功能

事實上,Prism 是一個分散式資源管理平台,幫助管理人員能夠維護管理和監控,在 Nutanix 叢集中的各種物件和多項服務,無論 Nutanix 叢集是在企業和組織的地端資料中心或是雲端。在 Prism 管理介面的部份,GUI 圖形方面採用新興的 HTML 5 UI 介面設計,在文字指令方面則是支援 RESTAPI、CLI 指令、PowerShell Cmdlets 等方式,同時也支援管理 Nutanix 叢集中的工作負載、定義安全性政策、監控和分析工作負載……等(如圖 2 所示)。

圖 2、Prism 運作架構示意圖



Prism Services

事實上,在 Nutanix 叢集中,運作在每一台節點主機上的 CVM 主機,都會運作 Prism Service,並且系統會在眾多 Prism Service 中,自動透過選舉機制選出一台 CVM 主機擔任 Prism Leader 的角色,由 Prism Leader 來處理所有收到的 HTTP Request,倘若其它台 CVM 主機中的 Prism Service,收到 HTTP Request 請求時,將會使用 HTTP Respone Status Code 301機制,把 HTTP Request 請求流量重新導向至 Prism Leader 進行處理(如圖 3 所示)。

圖 3、Prism Service 和 Prism Leader 運作架構示意圖

原則上,Prism Service 會 Listen Port 80 和 9440,來回應使用者的 HTTP Request 請求流量,一旦收到 HTTP Port 80的連線請求時,系統將會自動重新導向至加密連線的 HTTPs Port 9440,也就是屆時 Prism Element 或 Prism Central 登入頁面。

此外,Prism Leader 角色,也同時負責 Nutanix 叢集外部 IP 位址的託管作業,倘若運作 Prism Leader 的 CVM 主機故障,連帶導致 Prism Leader 角色故障時,系統會自動從叢集內還存活著的 Prism Service 中,再次透過選舉機制自動選出一台 CVM 主機擔任 Prism Leader 角色,繼續處理收到的 HTTP Request,並接手及託管 Nutanix 叢集外部 IP 位址,然後透過 Gratuitous ARP(gARP)機制,清除網路環境中過時的 ARP 快取,確保新的 Prism Leader 能夠無縫接手服務和 HTTP Request 請求流量。

倘若,管理人員希望能夠查詢,在目前的 Nutanix 叢集中,哪一台 CVM 主機擔任 Prism Leader 角色時,可以 SSH 登入任一台 CVM 主機後,執行「curl localhost:2019/prism/leader」指令,即可得知目前 Prism Leader 角色,運作在哪一台 CVM 主機中。



Prism Element vs Prism Central

在 Prism 運作架構中,GUI 圖形管理介面的部份,又區分為 Prism Element(PE)和 Prism Central(PC),這兩者之間簡單區別的方式,便是每個 Nutanix 叢集部署完成後,都將運作 Prism Element(PE),而需要管理多個 Nutanix 叢集時,則需要透過 Prism Central(PC)管理平台,達到集中和統一管理的目的(如圖 4 所示)。當然,倘若企業和組織只有一個 Nutanix 叢集時,仍然可以部署 PC 管理平台,以便啟用和使用進階特色功能及服務。

圖 4、管理單個叢集的 PE 和支援管理多個叢集的 PC

原則上,大部份的功能,無論是在 PE 或 PC 管理介面中都能設定,然而還是有些服務或特色功能,僅能在 PE 或 PC 管理介面中設定,舉例來說,每個 Nutanix 叢集的 Virtual IP 位址,以及 iSCSI Data Service IP 位址,就只能在 PE 管理介面進行組態設定,而無法透過 PC 管理介面進行設定。

然而,某些進階特色功能,就只能在 PC 管理介面進行啟用和組態設定,因為在 PE 管理介面中並沒有支援這些進階特色功能,舉例來說,當企業和組織購買的 Nutanix 軟體授權,具備成本管理機制時,便能啟用和連接 Xi Beam 特色功能,進行 Nutanix 叢集的成本估算及花費分析,或是透過 Planning Dashboard 功能,分析目前和未來資源需求的使用趨勢(如圖 5 所示)。

圖 5、透過 Planning Dashboard 功能分析目前和未來資源需求的使用趨勢

那麼,對於管理人員來說,何時該使用 PE 或 PC 管理介面 ?簡單的大原則就是,使用 PC 來管理和監控多個 Nutanix 叢集,在某些特殊工作任務需要時,才切換到 PE 管理介面進行單個叢集的組態設定作業。舉例來說,在平時維護管理 Nutanix 叢集架構中,管理 Clusters/Hosts/Disks 時,一律使用 PC 管理介面進行維護作業,然而需要增加 Node 節點主機擴充某個 Nutanix 叢集規模、修復 Host Boot Device、組態設定 Node 節點主機進入維護模式……等,這些特殊工作任務需求時,才切換到 PE 管理介面(如圖 6 所示)。

圖 6、透過 PE 管理介面處理特殊工作任務需求

一般來說,Nutanix 叢集的進階特色功能,通常也僅在 PC 管理介面才能啟用和組態設定,舉例來說,Acropolis Dynamic Scheduling(ADS)資源動態排程機制,能夠視 VM 虛擬主機和容器等工作負載情況,動態遷移至 Nutanix 叢集中其它 Node 節點主機,而 Host Affinity 原則也必須透過 PC 管理介面才能進行組態設定。此外,Calm/Karbon/Flow/Files 等進階功能服務,也必須透過 PC 管理介面才能啟用和組態設定(如圖 7 所示)。

圖 7、透過 PC 管理介面啟用和組態設定進階功能服務





實戰 – 部署 Prism Central 管理平台

在開始部署 PC 管理平台之前,除了確保 PE 叢集運作正常之外,也必須確保符合相關運作環境需求,否則可能會在部署 PC 管理平台期間,遭遇到不可預期的錯誤而導致部署作業中斷。

由於,本文實作環境中,建構的 Nutanix 叢集為 Nutanix CE 社群版本,所以並無法直接下載 Prism Central ISO 映像檔。因此,將會採用「1-Click Internet」方式,部署 PC 管理平台,在開始進行部署作業之前,請確保符合下列環境要求:
  • Nutanix 叢集運作環境中,指定的預設閘道必須通訊正常,並且能到達網際網路。
  • 確保 PE 叢集,與即將部署的 Prism Central IP 位址,其 TCP 連接埠 Port 2100 通訊正常,並允許通訊流量通過不會被防火牆阻擋。
  • 確保 PE 叢集中,CVM 主機和即將部署的 PC 主機,處於相同 VLAN 網路環境,倘若未處於相同 VLAN 網路環境時,必須確保 Layer 3 路由機制運作正常,並且過程中通訊流量不會被防火牆所阻擋。
  • 不可以將重複的 IP 位址,指派給即將部署的 PC 管理平台使用。
  • 部署 PC 管理平台的 Storage Container 儲存資源,必須確保叢集中所有的 AHV 虛擬化平台已經順利掛載。



NCC 健康狀態檢查

在正式部署 PC 管理平台之前,必須確保 Nutanix 叢集健康狀態。請使用 admin 管理帳號,登入 PE 管理介面,然後依序點選「Health > Actions > Run NCC Checks」項目,在彈出的 Run Checks 視窗中,點選 All Checks 項目並勾選 Send the cluster check report in the email 選項後,按下 Run 鈕進行 NCC 健康狀態檢查作業(如圖 8 所示)。

圖 8、在 PE 叢集部署 PC 之前,進行 NCC 健康狀態檢查作業

當 NCC 健康狀態檢查作業完成後,請確保檢查項目中 Error 或 Failed 欄位數字為 0,才進行 PC 管理平台部署作業,否則請先解決相關錯誤或失敗等問題,避免在 Nutanix 叢集不健康的狀態下,部署 PC 管理平台。



部署 Prism Central 管理平台

回到 PE 首頁,在 Home Dashboard 頁面中,可以看到 Prism Central 區塊,目前狀態為「Not registered」,表示目前的 PE 叢集,尚未受到任何 PC 管理平台連接及納入管理。

請點選下方的「Register or create new」選項,準備部署 PC 管理平台,在彈出的 Prism Central 視窗中,將有二個區塊可供選擇,倘若環境中早已經部署 PC 管理平台時,那麼只要點選 Connect 鈕,即可組態設定 PC 管理平台,連接並管理此 PE 叢集。

本文實作環境是全新運作環境,並沒有部署任何的 PC 管理平台,請按下 Deploy 鈕,進入 PC 管理平台部署程序。

在彈出的 Prism Central Deployment 視窗中,首先,系統會顯示可供部署的 PC 版本,倘若你的 PE 叢集環境,不允許網際網路連線的話,那麼必須預先下載 Prism Central Metadata file(.json),以及 Prism Central Installation Binary(.tar)檔案後,在這裡進行上傳的動作,本文選擇採用的 PC 版本為「pc.2022.6.0.11」後,按下 Next 鈕(如圖 9 所示)。

圖 9、選擇準備部署的 PC 版本

在 2 Scale type 頁面中,請選擇所要部署的 PC 規模(如圖 10 所示),分別是部署「單台」的 PC 虛擬主機,或是「3 台」PC 虛擬主機,其中單台主機的 PC 管理平台,支援管理的 VM 虛擬主機數量為 2,500 - 12,500 台,而 3 台主機組成的 PC 管理平台,則支援管理 5,000-25,000 台的 VM 虛擬主機。

圖 10、選擇 PC 管理平台的運作規模

事實上,這兩種運作規模的主要差異,除了支援管理的 VM 虛擬主機最大數量不同之外,另一個主要的差異點在於,企業和組織是否需要 PC 管理平台,具備高可用性(High Availability)和彈性容錯(Resiliency)機制,因為部署 3 台主機組成的 PC 管理平台時,系統預設會使用 RF2 資料保護機制,也就是額外會再複寫一份資料,至 PC 叢集中其它 Node 主機,確保 PC 管理平台的資料可用性。

值得注意的是,倘若企業或組織,一開始因為運作規模較小的關係,而選擇部署單台 PC 主機運作規模,後續隨著營運服務的擴大專案的增長,而運作更多 VM 虛擬主機,並需要擴大 PC 管理平台時,也無須重新部署 PC 管理平台,可以直接在 PE 管理介面中,執行 PC 管理平台的水平擴充(Scale-Out)作業,將 PC 管理平台的運作規模,由原本的單台運作規模,線上水平擴充為具備高可用性和容錯機制的 3 台主機 PC 管理平台。

在 3 Configuration 頁面中,首先選擇 PC 主機的 Size 大小,共有三種不同的 Size 等級,分別是 Small、Large、X-Large(如圖 11 所示),其中 Large 和 X-Large 都能管理,最多 12,500 台 VM 虛擬主機的規模,但是 X-Large 因為配置更多的 vCPU 和 vMemory 運算資源,所以還能額外承載其它服務,例如,ANC(Atlas Network Controller)服務。

圖 11、選擇部署的 PC 虛擬主機 Size 大小

選擇 PC 虛擬主機 Size 大小後,請往下繼續組態設定其它配置,在 Network 下拉選單中,選擇 PC 虛擬主機所要連接的 vNetwork 虛擬網路,在本文實作環境中,已經預先建立名稱為「PC-vNetwork」的 vNetwork 虛擬網路,並且子網路遮罩為「255.255.255.0」,預設閘道 IP 位址為「10.10.75.254」,使用的 DNS 名稱解析伺服器 IP 位址為「10.10.75.10」。

在 Select a Container 下拉式選單中,已經預先建立名稱為「PrismCentralContainer」的 Storage Container 儲存資源,最後在 VM Name 和 IP 欄位中,分別輸入 PC 的主機名稱以及 IP 位址(如圖 12 所示),確認無誤後按下 Next 鈕。

圖 12、組態設定 PC 網路組態和主機名稱

在 4 Summary 頁面中,再次檢查相關組態設定內容無誤後,按下 Deploy 鈕,系統便立即執行部署 PC 管理平台的工作任務。此時,回到 PE 首頁的 Home Dashboard 頁面中,可以看到 Prism Central 區塊的狀態為 Deploying,切換到 View All Tasks 頁面中,會看到 Download and deploy Prism Central 工作任務名稱正在執行(如圖 13 所示),包含工作任務開始的時間、進度百分比、持續時間……等資訊,並且有 2 個子工作任務執行中,可以按下 Details 繼續查看相關子工作任務內容和進度。

圖 13、系統開始部署 Prism Central 管理平台

事實上,整個部署的工作任務非常多,有興趣的管理人員可以逐一展示,舉例來說,展開後可以到二個子工作任務,分別是 Prism Central Deployment 和 Software downloaded,再展開又可以看到 Application Deployment 和 Tarball Extraction,再展開又有 Post Deployment Steps、Cluster Creation、VM Deployment、Setup State Machine……等,本文實作環境共花費「1 小時 6 分鐘」,完成 PC 管理平台的部署作業。



註冊 Prism Central 管理平台

此時,已經完成 PC 管理平台的部署作業,請開啟瀏覽器鍵入「https://pc.lab.weithenn.org:9440」,連接至 PC 管理平台登入畫面,使用預設的管理帳號「admin」,及預設的管理密碼「Nutanix/4u」,首次登入成功後,系統將會提示必須變更預設管理密碼,變更完成後即可切換回 PE 管理畫面,準備執行註冊 PC 管理平台的動作。

同樣的,Nutanix 官方建議,在正式註冊 PC 管理平台之前,請確保目前 Nutanix 叢集健康狀態,請在 PE 管理介面中,依序點選「Health > Actions > Run NCC Checks」項目,在彈出的 Run Checks 視窗中,點選 All Checks 項目並勾選 Send the cluster check report in the email 選項後,按下 Run 鈕進行 NCC 健康狀態檢查作業。

回到 PE 首頁,在 Home Dashboard 頁面中,請在 Prism Central 區塊中,點選下方的「Register or create new」選項,準備將此 Nutanix 叢集註冊至 PC 管理平台,在彈出的 Prism Central 視窗中,我們已經部署完成 PC 管理平台,所以點選 Connect 鈕準備執行註冊管理的動作。

在 1 Connect info 頁面中,系統提醒管理人員,一旦將 PE 註冊至 PC 管理平台後,有部份管理功能將會轉變為「唯讀模式(Read-Only Mode)」,但管理人員無須擔心,因為在 PC 管理平台中將具備完整權限(如圖 14 所示)。

圖 14、系統提示部份管理功能將轉換為唯讀模式

在 2 Configuration 頁面中,請鍵入 PC 管理平台的 IP 位址或 FQDN,並鍵入連線通訊埠 Port 9440,以及 PC 管理平台的管理帳號及密碼,確認無誤後按下 Connect 鈕(如圖 15 所示),系統將立即把目前的 PE 叢集,註冊至 PC 管理平台中。

值得注意的是,倘若先前部署好 PC 管理平台之後,並未登入管理介面變更預設管理密碼的話,那麼這裡即便鍵入正確的預設管理密碼,仍會發生無法註冊連接至 PC 管理平台的情況。

圖 15、註冊目前的 Prism Element 叢集至 Prism Central 管理平台中

一旦成功將 PE 叢集註冊至 PC 管理平台後,在 PE 管理介面中,便會看到 Prism Central 區塊狀態為 Connected,並顯示 PC 管理平台的 IP 位址,按下 Launch 連結後,系統將會開啟 PC 管理平台登入畫面(如圖 16 所示)。同一時間,PE 叢集和 PC 管理平台之間,將會開始進行資料同步作業,將 PE 叢集中「過去 90 天」內,相關的運作資料和效能數據都進行同步。

圖 16、成功將 PE 叢集註冊至 PC 管理平台

成功登入 PC 管理平台後,可以看到納入管理的 ntnx-cluster 叢集資訊(如圖 17 所示),由於目前的 PC 管理平台只有管理單一 ntnx-cluster 叢集,倘若日後管理多個叢集時,將會一次顯示多個 Nutanix 叢集的相關運作資訊。

圖 17、從 PC 管理介面中監控並管理 PE 叢集



將 PE 叢集退出 PC 管理平台

在某些情況下,企業或組織有可能會考慮,將 PE 叢集從 PC 管理平台中退出(或稱為取消註冊 Unregister),舉例來說,由於每個 PE 叢集,只能被單一 PC 管理平台納入管理,倘若企業或組織因為規模擴大或專案需求,而建立新的 PC 管理平台,那麼 PE 叢集便必須退出原有的 PC 管理平台後,才能加入並被新的 PC 管理平台所納管。

又或許是原有的 PC 管理平台,出於某種原因重新配置 Prism Central VM 主機的 IP 位址,那麼 PE 叢集便必須要重新註冊和加入 PC 管理平台。

事實上,在 AOS 5.5 版本之前,管理人員可以在 PE 管理介面中,直接執行取消註冊至 PC 管理平台的工作任務。然而,從 AOS 5.5 版本開始和後續版本中,有關 RBAC 角色存取控制、應用程式管理、微分段安全性原則、PSS 自助式服務……等,改為由 PC 管理平台統一組態設定和管理,一旦 PE 執行取消註冊的動作後,這些特色功能除了無法使用之外,相關的組態設定內容也將會自動刪除,即便後續再次註冊加入也必須重新組態設定才行,所以官方便將此功能刪除,以便降低和避免發生意外取消註冊的動作。有關 PE 叢集取消註冊的詳細資訊,請參考 Nutanix KB-4944KB-9736 知識庫文章內容。

首先,請透過 SSH 連線至 PE 叢集中任一台 CVM 主機,執行「cluster status」指令,確保所有叢集服務運作中並且健康狀態良好,請執行「ncli multicluster remove-from-multicluster external-ip-address-or-svm-ips=10.10.75.30 username=admin password='<Your_Password>' force=true」指令,將 PE 叢集從 PC 管理平台中取消註冊,接著執行「ncli multicluster get-cluster-state」指令,確認 PE 叢集取消註冊是否完成,此時在 PE 管理介面中,Prism Central 區塊狀態退回之前 Not registered(如圖 18 所示)。

圖 18、將 PE 叢集從 PC 管理平台中取消註冊

接著,分別在 PE 叢集和 PC 管理平台中,執行叢集資料清理的動作。首先,請在 PE 叢集的 CVM 主機中,執行「ncli cluster info」指令,查詢 Cluster UUID 並複製後,SSH 登入至 PCVM 主機中,執行「python /home/nutanix/bin/unregistration_cleanup.py uuid」指令,將 PC 管理平台中,有關 PE 叢集的資料進行清理的動作,系統將顯示「Successfully completed cleanup actions for cluster」資訊。

同樣的,請在 PCVM 主機中,執行「ncli cluster info」指令,查詢 Cluster UUID 並複製後,在 PE 叢集的 CVM 主機中,執行「python /home/nutanix/bin/unregistration_cleanup.py uuid」指令,將 PE 叢集中,有關 PC 管理平台的資料進行清理並停止同步資料的動作(如圖 19 所示)。

圖 19、清理 PE 叢集中有關 PC 管理平台的資料

值得注意的是,從新版 pc.2024.1 和 AOS 6.8 版本開始,當 PE 叢集取消註冊並退出 PC 管理平台後,PE 叢集將會自動進入「黑名單(blacklisted)」狀態,並且無法再次註冊到同一台或不同台 PC 管理平台中,主要原因在於從 Prism Central 2024.1 版本開始,新增「PE 退役(PE Decommissioning)」機制,倘若希望能再次恢復成可註冊狀態,必須連絡 Nutanix 技術支援才能解決,詳細資訊請參考 Nutanix KB-15679 知識庫文章





結語

透過本文的深入剖析和實作演練後,相信管理人員除了理解 Prism Element 叢集,和 Prism Central 管理平台之間的差異之外,也實際操作部署和註冊 Prism Central 管理平台,並在需要時也能夠取消註冊 Prism Central 管理平台。

Kubernetes Summit 2024 | 站長開講

$
0
0


活動簡介

Kubernetes Summit 2024一場匯集雲原生技術領域最頂尖專家和開發者的盛會。在這裡,您將有機會與來自世界各地的技術先驅一起探索 Kubernetes 的最新動態和創新應用。本次峰會將涵蓋一系列精彩的論壇演講,由業界知名的講者分享雲原生技術方面的深刻見解和豐富經驗。

此外還規畫多場實戰工作坊,您將有機會深入學習 Kubernetes 的實際應用,並通過實作練習來鞏固您的技能。還有展攤區域將展示最新的產品和技術,讓您近距離接觸行業的前沿。 無論您是 Kubernetes 的新手還是資深專家,這都是一個不容錯過的機會。來自各行各業的專業人士將在此聚集,共同交流、學習和成長。我們期待您的參與,一起開啟雲原生技術的新篇章。





活動資訊

日期:   2024 年 10 月 23 - 24 日 (三 - 四)
時間:   09:00 - 17:00
議程:   大會議程表
報名:   報名購票






站長議程

在本次大會中,站長有場 90 分鐘的「Azure Kubernetes Service with GitOps」體驗工作坊,詳細資訊請參考大會網站。



活用 vCenter 內建功能,備份還原預因應災難事件 | 網管人 225 期

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 225 期 - 2024 年 10 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

隨著企業和組織歷經數位轉型變革過程,營運服務也從過去實體主機工作負載,轉換為虛擬化基礎架構,改為運作在 VM 虛擬主機當中,或是將營運應用程式容器化,甚至建構在容器化基礎之上的 Serverless 架構。

在 VMware vSphere 虛擬化架構中,無論是管理 VM 虛擬主機和容器等工作負載,或是組態設定 vSS 標準虛擬網路、vDS 分佈式虛擬網路、vSphere vMotion 線上遷移工作負載、vSphere HA 高可用性機制、vSAN HCI 超融合環境……等,管理人員都可以透過 vCenter Server 集中式管理平台,達成有效管理和組態設定的工作任務。雖然,vCenter Server 管理平台發生故障事件而停止運作時,並不會影響到線上運作的 VM 虛擬主機和容器等工作負載,並且 vSphere HA 高可用性機制仍持續運作中。

然而,一旦 vCenter Server 管理平台發生故障並停止服務後,管理人員便無法有效管理 vSphere 虛擬化架構,無論是組態設定或是進階的 vMotion 線上遷移工作負載……等工作任務,都將因為 vCenter Server 管理平台故障而停擺。

因此,官方持續為 vCenter Server 打造各種新功能或增強功能,目的就是提升 vCenter Server 管理平台的 SLA 等級。舉例來說,針對 vCenter Server 臭蟲修正 / 版本更新 / 版本升級造成的停機時間,便透過 vCenter Reduced Downtime Upgrade(RDU)新功能,讓vCenter管理平台,在執行安全性更新或版本升級時,能夠將停機時間最大化縮短,在最新的vSphere 8 Update 3 版本中,甚至能將版本更新或升級作業程序的停機時間限縮在 5 分鐘之內(如圖 1 所示)。

圖 1、vCenter Reduced Downtime Upgrade(RDU)機制說明示意圖

此外,一旦 vCenter Server 遭遇重大災難事件導致故障無法服務時,雖然可以透過先前完成的備份立即進行還原作業,但是仍有可能因為時間差的關係,導致還原後的 vSphere 基礎架構產生環境混亂的問題,舉例來說,管理人員設定「每天凌晨 2 點」為 vCenter 執行排程備份,但是 vCenter 在下午 4 點發生災難事件,即便立即為 vCenter 執行還原的工作任務,但是從凌晨 2 點到下午 4 點這段期間,整個 vSphere 基礎架構中,仍有許多事件和各項工作負載的統計資料,已經寫入到 vCenter 資料庫中,因此復原後的 vCenter 管理平台,將會遺失這段期間的事件和工作負載統計資料。

因此,在新版 vSphere 8 版本中,推出「分散式鍵值儲放區」(Distributed Key-Value Store,DKVS)機制(如圖 2 所示)。簡單來說,當 vCenter 管理平台發生災難時,這段期間發生的各項事件和工作負載統計資料,也將會儲存在 vSphere 叢集中所屬的 ESXi 節點主機內。

一旦 vCenter 管理平台完成還原作業重新上線後,將會與 vSphere 叢集中所屬的 ESXi 節點主機進行通訊,將災難發生至還原作業期間的事件和工作負載統計資料取回,讓 vCenter 管理平台能夠迅速恢復正常運作,並取得 vSphere 叢集和 ESXi 節點主機的最新資訊。


圖 2、Enhanced Recovery of vCenter 運作架構示意圖





實戰 – vCenter Server 8 備份和還原

雖然,市場上已經有許多備份軟體廠商,推出針對 vCenter 備份還原的產品。但是,對於 IT 預算不多的小型企業和組織來說,即便只是備份軟體授權的費用,都讓原本就不足的 IT 預算雪上加霜。

因此,本文中將剖析和實戰演練,透過 vCenter 內建的備份和還原機制,針對 vCenter 進行排程定期備份的工作任務,並模擬演練故障損壞事件發生時,如何透過平時的排程備份立即進行還原,讓 vCenter 管理平台能在最短時間內恢復正常運作。

vCenter 支援兩種備份機制,第一種為「映像檔方式」(Image-Based),針對整台 vCenter 虛擬主機進行備份,市場上的備份軟體便是採用這種備份方式。第二種,為「檔案方式」(File-Based),將 vCenter 管理平台中組態設定備份後,當災難發生時進行還原作業,在本文實戰演練小節中便是採用此方式。

值得注意的是,倘若企業和組織有為 vCenter 管理平台,建立「增強型鏈接模式」(Enhanced Linked Mode,ELM)運作環境的話,那麼建議管理人員應採用檔案方式進行備份,而非使用映像檔方式備份。

其主要原因在於,增強型鏈接模式運作環境中,多台 vCenter 同時運作並互相同步及複製資料,但採用映像檔方式備份時,會針對 vCenter 進行即時快照,一旦還原後可能會發生還原後的 vCenter 狀態,與其它 vCenter 之間不同導致 SSO Domain Data 發生衝突,因此建議管理人員在 ELM 運作環境中,應採用本文實戰演練的檔案方式進行備份和還原作業。



主動備份 vCenter 管理平台

在開始執行自動化排程備份之前,建議管理人員先嘗試主動備份一次,確保備份工作任務能夠順利執行並完成。事實上,雖然是內建的備份機制,但是官方仍不斷增強其功能,舉例來說,在過去舊版 vSphere 6.5 時,備份和還原機制僅支援 FTPS、HTTPS、SCP 通訊協定,在 vSphere 6.7U2 版本時,則額外新增支援 SFTP、NFSv3、SMBv2 通訊協定。

值得注意的是,採用 FTPS 通訊協定時僅支援 Explicit 模式,採用 HTTPS 通訊協定時必須在網頁伺服器上啟用 WebDAV 功能。此外,透過 HTTP Proxy 傳輸備份資料時,則僅支援採用 FTPS 和 HTTPS 通訊協定。

在本文中,將採用 SMB 通訊協定進行主機備份的工作任務。首先,在提供 SMB 通訊協定的備份伺服器中,已經建立名稱為「vCenter_Backup」資料夾,以便屆時存放 vCenter 備份資料,並開啟資料夾分享及權限設定,確保稍後主動備份 vCenter 的工作任務能夠順利完成。

前置作業完成後,請登入 vCenter Server Management(Port 5480)管理介面,登入後依序點選「Backup > Activity > Backup Now」,在彈出的 Backup Now 視窗中,請在 Backup location 欄位中,填入 SMB 通訊協定搭配剛才準備的備份資料夾路徑,本文實作環境為「smb://backup.lab.weithenn.org/vCenter_Backup」,在 Backup server credentials 欄位,填入儲存備份檔案的「Backup_Admin」管理帳號和密碼,確認無誤後按下 START 鈕,系統便立即進行單次主動備份任務(如圖 3 所示)。

圖 3、鍵入備份伺服器中存放備份的資料夾路徑及管理者資訊

主機備份後的檔案大小及花費時間,與 vCenter 管理平台的運作狀態、事件、工作項目、組態設定……等有關,備份任務會在剛才指定的備份資料夾中,依序建立 vCenter 的 FQDN 資料夾,以及 vCenter 版本和備份日期及時間子資料夾(如圖 4 所示)。

圖 4、執行主動備份 vCenter 管理平台工作任務



排程備份 vCenter 管理平台

相對於單次執行的主動備份,對於企業和組織來說,組態設定排程時間,讓系統能夠自動定期備份 vCenter Server 管理平台,才是有效的備份解決方案。值得注意的是,目前系統內建的排程備份機制,僅支援組態設定一個排程,尚未支援組態設定多個排程同時執行。

登入 vCenter Management 管理介面後,依序點選「Backup > Backup Schedule > Configure」,在彈出的排程備份視中,在 Backup location 欄位填入通訊協定 SMB,以及備份伺服器的 FQDN 和備份資料夾路徑,在 Backup server credentials 欄位,填入具備備份資料夾寫入權限的使用者帳號和密碼。

在 Schedule 下拉式選單中,有 Daily/Weekly/Custom 選項可供選擇,其中 Custom 是指選擇每週的某幾天進行備份作業,在本文中組態設定每天凌晨 2 點進行備份作業,在 Encrypt backup 欄位,倘若管理人員希望為備份檔案進行加密時,請鍵入兩次加密密碼即可。

在 Number of backups to retain 欄位中,選擇「Retain all backups」項目時,系統將會保留所有的備份檔案,選擇「Retain last backups」項目,則是設定要保留的備份檔案份數,本文實作環境選擇保留最近 14 天的備份檔案,確認無誤後按下 Create 鈕即完成排程備份設定(如圖 5 所示)。

一旦排程備份機制設定完成後,在 Backup Schedule 區塊將會顯示剛才的組態設定內容,當組態設定的排程時間到達後,系統便會觸發並自動執行排程備份的工作任務,屆時在下方的 Activity 區塊,也可以看到備份任務的執行結果。

圖 5、組態設定排程自動備份機制



備份 vDS 分佈式虛擬交換器

在中大型的企業和組織中,由於 vSphere 叢集中 ESXi 節點主機數量較多,通常便會部署「分佈式虛擬交換器」(vSphere Distributed Switch,vDS),那麼建議管理人員,應該也要將 vDS 分佈式虛擬交換器組態設定匯出,以便後續需要時可以匯入或還原 vDS 組態設定,否則有可能在還原 vCenter 管理平台之後,遭遇 vDS 分佈式虛擬交換器組態設定遺失的問題,詳細資訊請參考  VMware KB 2034602  知識庫文章內容。

請在 vCenter 管理介面中,依序點選「Inventory > Networking > Distributed Switch >Actions > Settings > Export Configuration」項目,在彈出的 Export Configuration 視窗中,有兩種匯出選項可供選擇,採用「Distributed switch and all port groups」選項時,將會匯出 vDS 分佈式虛擬交換器,以及所有 Port Groups 組態設定,採用「Distributed switch only」選項的話,則僅會匯出 vDS 分佈式虛擬交換器的組態設定,至於下方描述區塊可依管理人員需求進行填寫,確認無誤後按下 OK 鈕即可(如圖 6 所示)。

圖 6、備份 vDS 分佈式虛擬交換器和所有 Port Groups 組態設定

此時,瀏覽器將會自動下載名稱為 backup.zip 的壓縮檔案,內容便是選擇匯出 vDS 分佈式虛擬交換器組態設定項目。後續,管理人員便能依據需求,進行「匯入」或「還原」vDS 分佈式虛擬交換器組態設定的動作。



備份 vCHA 高可用性環境

事實上,以檔案方式備份 vCenter 管理平台的機制,目前尚未完整支援 vCHA(vCenter High Availability)高可用性運作環境(如圖 7 所示),但是管理人員仍然能夠針對 vCenter 進行備份的工作任務,並且在 vCHA 叢集架構發生重大災難事件時快速還原和重建。

圖 7、vCHA(vCenter High Availability)高可用性環境運作架構示意圖

簡單來說,當企業或組織為 vCenter 管理平台,建立 vCHA 高可用性機制運作環境時,執行備份工作任務時,系統僅會備份  vCenter 主要節點(Active Node),而不會備份被動節點(Passive Node),以及見證節點(Witness Node)。

因此,當 vCHA 高可用性運作環境發生災難事件時,管理人員必須在執行還原工作任務之前,先將 vCHA 高可用性環境整個關閉,包括主動節點和被動節點及見證節點,當還原工作任務執行完畢後,vCenter 管理平台會處於單機運作環境,屆時管理人員再透過 GUI 圖形介面,重新部署 vCHA 高可用性環境即可,相關詳細資訊請參考  VMware KB 60229KB 2147014KB 2147038KB 2147046  知識庫文章內容。



還原 vCenter Server

雖然,已經組態設定排程時間定期備份,仍建議管理人員應該定期確認備份檔案,是否能夠順利執行還原任務,順便在演練過程中建構和撰寫 SOP 文件,一旦災難事件真正發生時,需要快速執行還原任務時便不會手忙腳亂。值得注意的是,還原任務為驗證還原檔案是否有效時,管理人員可以在還原任務執行時,將 vCenter 主機的虛擬網路線拔除,即可避免和現有運作中的 vCenter 管理平台,發生 IP 位址衝突的情況。

vCenter 管理平台還原程序共分為兩個階段(如圖 8 所示),第一個階段將會部署一台新的 vCenter Server 虛擬主機,第二個階段則是透過先前備份資料,將組態設定和相關資料傳輸至新部署的 vCenter 虛擬主機中。在執行還原任務時有個主要限制,當 vCenter 主機採用哪個版本的 ISO 映像檔安裝時,就必須使用該版本的 ISO 映像檔執行還原任務才行,例如,採用 vCenter 8.0 U2 安裝和部署,便需要使用 vCenter 8.0 U2 的 ISO 映像檔,執行整個還原工作任務才行。

圖 8、vCenter 管理平台還原任務工作流程示意圖

事實上,整個 vCenter 的還原工作任務,跟部署 vCenter 管理平台類似,請掛載 vCenter ISO 映像檔後,執行「vcsa-ui-installer/win32/installer.exe」檔案,在彈出的精靈對話視窗中,點選「Restore」項目以進入還原工作流程。

在 Restore – Stage 1 : Deploy vCenter Server 還原工作流程中,前 2 個步驟為簡介和使用者授權條款,在 3. Enter Backup details 畫面中,請於 Location 欄位中填入先前儲存備份檔的路徑,以及可存取備份檔路徑權限的使用者帳號和密碼。值得注意的是,備份檔路徑必須是包含「backup-metadata.json」的路徑,本文實作環境填入的備份路徑為「smb://backup.lab.weithenn.org/vCenter_Backup/vCenter/sn_vcenter8.lab.weithenn.org/S_8.0.2.00100_20240817-180007_」(如圖 9 所示)。

圖 9、填入備份檔案存放路徑和具備存取權限的使用者帳號及密碼

在 4. Review backup information 頁面中,系統會再次檢查鍵入的備份檔案存放路徑是否正確,倘若鍵入的路徑不正確,或 backup-metadata.json 檔案已損毀的話,在這個步驟中將會出現錯誤訊息並停止還原程序。

在 5. vCenter Server deployment target 頁面中,請鍵入要將新的 vCenter 虛擬主機,部署至哪一台 ESXi 主機中,本文實作環境為「mgmt-esxi.lab.weithenn.org」,並鍵入具備管理權限的使用者帳號和密碼(如圖 10 所示)。

圖 10、指定還原後的 vCenter 要部署在哪台 ESXi 主機中

在 6. Set up target vCenter Server VM 頁面中,請鍵入新部署的 vCenter 虛擬主機名稱,本文實作為「vCenter8」,以及組態設定 root 管理員帳號密碼。值得注意的是,倘若故障損壞的 vCenter 仍處於 Power On 開機狀態時,管理人員應將其 Power Off 並修改 vCenter 虛擬主機名稱,例如,本文實作環境將原有 vCenter 虛擬主機名稱,修改為「vCenter8-retired」,否則系統在進行檢查作業時,將會發現 vCenter 虛擬主機名稱已存在而停止還原程序(如圖 11 所示)。

圖 11、新部署的 vCenter 虛擬主機名稱和原有 vCenter 名稱相同發生衝突

在 7. Select deployment size 頁面中,管理人員可以視需求選擇不同的 vCenter 部署規模。倘若,一開始部署 vCenter 時選錯規模,或是隨著時間演進不斷擴大,導致原有 vCenter 部署規模不足以因應時,管理人員也可以在備份後執行還原作業,並在此步驟中重新選擇部署較大的 vCenter 規模,本文實作採用「Small」規模(如圖 12 所示)。

圖 12、選擇 vCenter 主機的部署規模大小

在 8. Select datastore 頁面中,請選擇放置 vCenter 虛擬主機的儲存資源。值得注意的是,倘若管理人員不勾選「Enable Thin Disk Mode」選項時,那麼新部署的 vCenter 虛擬硬碟格式,將會採用「Thick」模式進行部署,請確保儲存資源空間足夠才行,舉例來說,本文實作環境選擇「Small」規模大小時,儲存空間至少要大於「694GB」才行。

在 9. Configure network settings,請鍵入 vCenter 虛擬主機網路組態。首先,在 Network 欄位的部份,會顯示 vSS 及 vDS 虛擬網路 Port Group,但是在 vDS 分佈式虛擬網路交換器的部份,下拉選單中僅會顯示「暫時綁定」(Ephemeral binding)的 Port Group,一般常用「靜態綁定」(Static binding)的 Port Group 並不支援,有關暫時綁定和靜態綁定的詳細資訊,請參考 VMware KB 1022312 知識庫文章內容。在本文實作環境中,選擇使用「Backup-vNetwork」的 Port Group,而 FQDN 為「vcenter8.lab.weithenn.org」,固定 IP 位址為「10.10.75.30」(如圖 13 所示)。

圖 13、鍵入 vCenter 虛擬主機網路組態設定

在 10. Ready to complete stage1 頁面中,請再次檢查還原項目和設定值內容是否正確,確認無誤後按下 Finish 鈕,便立即執行第一階段的還原工作任務,完成後系統將會提醒管理人員,可以登入 vCenter Server Management(Port 5480)管理介面(如圖 14 所示)。

圖 14、vCenter 管理平台第一階段還原任務完成

在第二階段的還原工作流程中,系統會將備份檔案中組態設定和相關內容,複製到新部署的 vCenter 主機中。請在 2. Backup details 步驟中,再次檢視備份檔案路徑是否正確,倘若備份時有搭配加密機制時,此步驟中必須鍵入加密密碼。

倘若,還原的 vCenter 主機處於 ELM 增強型鏈接模式時,系統將會要求提供 SSO(Single Sign-On)認證資訊,確保還原後的 vCenter 管理平台,能夠和其它台 vCenter 主機繼續通訊和同步。

在 3. Ready to complete,再次檢查還原組態設定是否正確,系統提醒倘若原有的 vCenter 主機仍運作中,請關閉它避免發生 IP 位址衝突的問題,確認無誤後按下 Finish 鈕,便立即執行第二階段的還原任務,成功後系統將提醒管理人員,可以登入 vCenter Server(Port 443)管理介面(如圖 15 所示)。

圖 15、vCenter 管理平台第二階段還原任務完成



還原 vDS 分佈式虛擬交換器

原則上,在 vCenter 管理平台故障期間,管理人員若無針對 vSwitch 虛擬交換器進行異動的話,那麼 vCenter 管理平台還原後,無須針對 vDS 分佈式虛擬交換器,進行匯入或還原作業。除非有任何異動或發生損壞時,管理人員才需要透過先前的 vDS 分佈式虛擬交換器備份進行還原作業。

倘若,vDS 分佈式虛擬交換器整個遺失,請在 vCenter 管理介面中,依序點選「Inventory > Networking > Datacenter > Actions > Distributed Switch > Import Distributed Switch」,按下 Browse 鈕選擇先前的匯出檔案 backup.zip,倘若管理人員希望保留 vDS 和 Port Group 的 ID,請勾選「Preserve original distributed switch and port group identifiers」選項(如圖 16 所示)。

圖 16、匯入先前良好的 vDS 分佈式虛擬交換器組態設定

在 2. Ready to complete,再次檢視內容正確無誤後,按下 Finish 鈕便立即執行,匯入 vDS 分佈式虛擬交換器組態設定的動作,匯入動作完成後,便可以看到 vDS 分佈式虛擬交換器恢復運作(如圖 17 所示)。

圖 17、成功還原先前設定好的 vDS 分佈式虛擬交換器

倘若,vDS 分佈式虛擬交換器仍存在,但是部份 Port Group 遺失或損壞,請在 vCenter 管理介面中,依序點選「Inventory > Networking > Distributed Switch > Actions > Settings > Restore configuration」,按下 Browse 鈕選擇先前的匯出檔案 backup.zip,並依據需求僅還原 vDS 分佈式虛擬交換器,或 vDS 分佈式虛擬交換器並包含所有 Port Group 選項(如圖 18 所示)。

圖 18、還原 vDS 分佈式虛擬交換器和所有 Port Group

在 2. Ready to complete,再次檢視內容正確無誤後,按下 Finish 鈕便立即執行,還原 vDS 分佈式虛擬交換器和所有 Port Group 的動作,還原動作完成後,即可看到 vDS 分佈式虛擬交換器和 Port Group 恢復正常運作。



重建 vCHA 高可用性機制

如前所述,在 vCHA 高可用性環境中,備份機制僅會備份 vCenter 主要節點,請在還原任務執行成功後,重新建構 vCHA 高可用性叢集環境即可。有關建構 vCHA 高可用性叢集環境詳細資訊,請參考本刊 【第 214 期 - 部署 vCHA 機制因應災難,可容錯移轉營運不中斷】 內容。





結語

透過本文的深入剖析和實戰演練後,管理人員應該已經理解,透過 vCenter 管理平台內建的備份還原機制,便可以輕鬆達到排程備份和還原等工作任務,無須額外採購第三方備份軟體,並且在發生災難事件時快速還原至正常運作狀態,滿足 IT 預算原本就不足的中小型企業或組織的需求。

.NET Conf Taiwan 2024 | 站長開講

$
0
0


什麼是 .NET Conf?

.NET Conf 是 .NET 社群的年度重要活動,微軟 .NET 團隊以及 .NET Foundation 將於 11 月份舉辦 .NET Conf 線上活動,連續三天現場直播 .NET 相關議程,介紹最新技術與其應用,.NET 8.0 也即將在 .NET Conf 發布!

為了讓台灣開發人員也能彼此交流 .NET 技術與心得,台中最大微軟技術社群 STUDY4 將於 12/14 - 15 舉辦為期兩天的 .NET Conf Local Event,邀請台灣開發人員共襄盛舉。

這次 .NET Conf 活動有什麼?

社群技術議程中,會與台灣的開發人員一起探討 .NET 最新技術與其相關應用,您將可以學習到最新的 .NET、ASP.NET Core、Blazor、C#...等開發技術,除此之外,還安排了雲端與多元的開發技術議程。無論您是初學者、轉換跑道者、還是資深的技術工程/資料分析師,這裡皆有適合您的議程,讓我們共同學習、提出問題與講師交流,藉此精進您的開發技能。 身為開發者的您,千萬別錯過 12/14 - 15 這場為期兩天的開發盛會!

.NET 可以做甚麼?

您可以使用 .NET 開發技術來建置各種平台和裝置應用,舉凡 Web、Mobile、Desktop、Games、Service 和 Libraries,.NET 都是實現您創意的最佳平台!
  • Desktop
  • Web
  • Cloud
  • Mobile
  • Gaming
  • IoT
  • AI





活動資訊

日期:   2024 年 12 月 14 - 15 日 (六 - 日)
時間:   09:00 - 17:00
議程:   大會議程表
報名:   報名購票





站長議程

在本次大會中,站長有場 40 分鐘的「LLM 初體驗 - Running Microsoft Phi-3 locally」議程,在議程中,將說明和實際展示,如何快速將 Microsoft 推出的開放式大型語言模型 Phi-3,在本地端電腦上運作,即便沒有 GPU 資源的桌機或筆電 (有當然更好!),也都可以運作 Phi-3 開放式大型語言模型,讓手邊沒有 GPU 資源又想體驗 LLM 大型語言模型威力的 IT 人員,都能輕鬆體驗 Phi-3 的威力,其它詳細資訊請參考大會網站。



WebConf Taiwan 2024 | 站長開講

$
0
0


活動簡介

WebConf Taiwan 是一個聚集網頁技術愛好者和專家的年度盛會,讓大家一起探索網頁技術的演進和未來發展趨勢。過去幾年,網路世界變化迅速,我們將在這次研討會上回顧網頁技術的演變歷程,了解那些改變遊戲規則的關鍵時刻。

除了回顧過去,WebConf Taiwan 更專注於未來。我們會討論如何利用人工智慧和機器學習來改善使用者體驗,以及行動優化和響應式設計在現代網頁開發中的重要性。還有最新的業界趨勢分享,幫助企業把握未來發展方向,保持競爭優勢。

這將是一個充滿創意和靈感的活動,讓你與來自各地的網頁技術專業人士互動交流,共同探討未來的技術創新和可能性。

WEB DEVELOPMENT

包含 Frontend、Backend、DevOps、技術管理等相關議題。將深入探討各種 Web 技術的最新趨勢、過往發展,以及如何透過這些技術來提升網站或應用程式的品質、效能與安全性。

UI/UX DESIGN

本屆科技年會將探討 UI/UX 設計的最新趨勢,包括使用者界面設計、使用者體驗優化、人機互動設計等議題,以深入探討如何打造出引人入勝的用戶體驗,提升產品的價值和競爭力。





活動資訊

日期:   2024 年 12 月 27 - 28 日 (五 - 六)
時間:   09:00 - 17:00
議程:   大會議程表
報名:   報名購票





站長議程

在本次大會中,站長有場 45 分鐘的「DevOps, GitOps, and AIOps」議程,在議程中,將讓與會人員了解,SRE 的基本功,透過建構自助式服務,解決 Day 1 Operations 工作任務,將常態性或重複性的工作任務自動化,舉凡 VM 虛擬主機的部署,或是容器服務的調度……等,同時也將半自動的 IaC 基礎架構及程式碼服務,提升為全自動的 GitOps 流程,進而處理 Day 2 Operations 的工作任務,例如,營運服務的生命週期、監控、修補臭蟲……等,甚至整合 Event-Driven 事件驅動機制,達到主動式或被動式自動回應機制。 此外,將說明 AIOps 除了幫助團隊偵測潛在問題並做出反應之外,事實上AIOps 系統並無法取代經驗豐富的 IT 系統管理員和其他營運團隊成員,其它詳細資訊請參考大會網站。



開箱 Win Server 2025 實戰雙節點工作群組叢集 | 網管人 226 期

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 226 期 - 2024 年 11 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

隨著 Microsoft Ignite 2023Windows Server Summit 2024 大會的舉辦,雖然 Windows Server 2025 仍處於技術預覽版本階段,但是隨著幾場大會下來,相信市場也逐漸對即將推出的 Windows Server 2025 興趣漸增。

首先,是針對 「熱修補」(Hotpatching)的增強,企業和組織透過最新的熱修補技術,執行安全性更新安裝作業時,將會直接針對 Windows Server 伺服器中,記憶體內部運作的系統程序進行程式碼修補的動作,不僅主機的運作不受干擾,其它運作的執行程序和服務也無須停止,並且修補完畢後的 Windows Server 也無須重新啟動,順利達成安全性更新和修補的目的,且不影響企業和組織的 SLA 服務等級協議。

在 Windows Server 2022 版本時代,只有運作在 Azure 公有雲環境中,並使用 Windows Server 2022 Datacenter : Azure Edition 版本才能支援熱修補功能(如圖 1 所示)。

圖 1、Windows Server 2022 熱修補功能示意圖

現在,在最新 Windows Server 2025 版本中,將具備 Windows Server Hotpatching for everyone 機制。簡單來說,待 Windows Server 2025 正式推出後,無論採用 Standard 或 Datacenter 版本,都可以直接使用熱修補功能,讓企業和組織在地端資料中心運作的 Windows Server 2025,可以從過去每個月進行安全性更新重新啟動,也就是一年要重新啟動主機次數為 12 次情況下,減少為每季重新啟動一次一年 4 次即可(如圖 2 所示),有效提升企業和組織營運服務的 SLA 服務等級協議。

圖 2、主機啟用熱修補功能後,只要每季重新啟動一次即可





Windows Server 2025 亮眼功能

事實上,Windows Server 2025 不僅將過往既有功能增強,還推出許多亮眼特色功能,舉例來說,在新版 Windows Server 2025 中,針對 NVMe 儲存裝置進行效能最佳化,並且還降低 CPU 工作負載,重點是企業和組織無須更換原有伺服器或 NVMe 儲存裝置,只要將原有的作業系統由 Windows Server 2022,升級為最新的 Windows Server 2025 版本即可。

在官方的效能測試資料中可以看到,原本在 Windows Server 2022 環境中的 NVMe 儲存裝置,在採用「diskspd.exe -r4k -b4k -t8 -o64 -d60 -Suw #0」壓力測試條件下,儲存效能達到「1.1M IOPS」,同樣的硬體配置下,升級為 Windows Server 2025 版本後,儲存效能達到「1.86M IOPS」,直接提升「70%」的儲存效能(如圖 3 所示)。

圖 3、Windows Server 2025 最佳化 NVMe 儲存效能示意圖



智慧便捷的版本升級機制

過去,提到 Windows Server 版本升級,管理人員可能就會眉頭一皺而裹足不前。現在,Windows Server 版本升級,已經提供像 Windows 10 升級至 Windows 11 的快速體驗,企業和組織在 Windows Server 2022 版本中,只要透過 Windows Update 更新,便可以直接升級版本至 Windows Server 2025(如圖 4 所示),即便企業或組織有數量眾多的 Windows Server 主機,也只要搭配 CAU 更新機制即可。

圖 4、透過 Windows Update 將 Windows Server 2022 升級至 2025 版本



不斷進化的 Hyper-V 虛擬化平台

雖然,在市場上大家已經不再比較虛擬化平台規格和運作規模,然而微軟一直沒有停止 Hyper-V 虛擬化平台的進化腳步。事實上,在微軟許多公開服務都採用 Hyper-V 虛擬化平台為基礎,例如,Azure 公有雲、Xbox 服務、Azure Stack Family、Containers with Hyper-V Isolation……等。

過去在 Hyper-V 容錯移轉叢集架構中,一旦叢集中的成員伺服器,在硬體伺服器方面有 CPU 世代差異時,管理人員必須人為介入進行操作,為叢集中的每一台成員主機,組態設定 CPU 相容模式才行。

現在,最新 Windows Server 2025 版本中,直接支援 「處理器動態相容」(Dynamic Processor Compatibility) 機制(如圖 5 所示),管理人員無須人為介入進行組態設定,系統將會自動啟用處理器動態相容性機制,Hyper-V VM 虛擬主機在不同成員伺服器主機之間,進行 Live Migration 線上遷移時,只要遷移至新世代的硬體伺服器成員主機上,便能立即提升運算效能並享有新世代 CPU 的特色功能。

圖 5、CPU 處理器動態相容性機制示意圖

隨著科技不斷進行加上 AI 人工智慧的加持,企業和組織對於大型 VM 虛擬主機的需求不斷增長。現在,Hyper-V 虛擬化平台主機層級方面,可支援高達 2,048 Logical Processors,和 4PB(5-level pagin)256TB(4-level paging)記憶體空間,在 VM 虛擬主機層級方面,也支援高達 2,048 vCPU 和 240TB vMemory 的虛擬主機,在官方實際展示的一張工作管理員截圖中,可以看到這台採用 Gen2 的 Hyper-V 虛擬主機,具備 1,792 vCPU 和 29.7TB vMemory 運算資源(如圖 6 所示)。

圖 6、一台具備 1,792 vCPU 和 29.7TB vMemory 的大型 VM 虛擬主機



GPU-P 圖形處理共享機制

在 AI 浪潮的推波助瀾下,企業和組織除了使用公有雲的 AI 服務之外,也考慮在地端資料中心內建置具備 GPU 圖形運算資源,以便自行訓練或微調屬於企業和組織自已的 AI 人工智慧模型。在 Windows Server 2022 版本中,開始支援「GPU 集區離散裝置指派」(GPU Pools with Discrete Device Assignment)運作架構,將硬體伺服器中的硬體 GPU 加入至 GPU 集區內,當 GPU 集區機制建立完成後,將特定的 VM 虛擬主機指派到 GPU 集區中,而非傳統一對一或者一對多的指派單個 GPU,後續即便容錯移轉叢集的成員伺服器發生災難事件時,系統將自動移轉並重新啟動 VM 虛擬主機,系統會在重新啟動時自動尋找,並加入至 GPU 集區內可用的 GPU 圖形運算資源,無須管理人員手動為 VM 虛擬主機再次指派 GPU 對應關係(如圖 7 所示)。

圖 7、GPU Pools with Discrete Device Assignment 運作架構示意圖

但 GPU Pools with DDA 的缺點在於,VM 虛擬主機無法手動執行 Live Migration 線上遷移,並且屬於 GPU 專用而非共享架構,所以能真正使用到 GPU 圖形處理的 VM 虛擬主機數量不多。因此,在 Windows Server 2025 版本中,將新增支援「GPU 分割」(GPU Partitioning,GPU-P)機制,透過 SR-IOV 單一根 I/O 虛擬化機制,為每台 VM 虛擬主機提供硬體支援,並只能存取其專用的 GPU 圖形處理資訊,並透過安全硬體分割機制,防止其它未經授權的 VM 虛擬主機存取 GPU 圖形處理資源,達成讓多台 VM 虛擬主機同時共用實體 GPU 圖形處理資源(如圖 8 所示)。

圖 8、Windows Server 2025 新增支援共享式 GPU Partitioning 圖形處理機制





實戰 – 雙節點工作群組叢集

在實戰演練小節中,將部署和建立雙節點工作群組叢集。然而,在開始組態設定之前,管理人員應先了解什麼是「工作群組叢集」(Workgroup Cluster),以及它和傳統的容錯移轉叢集有哪些不同之處,同時必須注意哪些部署準則和後續維護事項,才能讓工作群組叢集順利且穩定的運作。

事實上,工作群組叢集,為 Windows Server 2016 版本中新增的特定容錯移轉叢集組態類型,在工作群組叢集運作架構中,成員伺服器處於工作群組中並且不加入 Active Directory 樹系網域環境,然而運作環境中仍需要 DNS 名稱解析服務(如圖 9 所示)。

圖 9、工作群組叢集運作架構示意圖

因此,工作群組叢集的適用情境,通常為企業和組織中小型分公司或據點,希望在沒有 Active Directory 網域服務的情況下,仍可提供身份識別服務和管理,且能夠執行容錯移轉叢集服務,達成降低硬體維護和工作負載之外,同時維持身份識別高安全性,並且讓應用程式保持高可用性。

工作群組叢集必須滿足下列前置作業條件,才能滿足正式支援工作群組叢集的部署準則:
  • 工作群組叢集中的所有成員伺服器,必須運作相同版本的 Windows Server 才行,例如,都是 Windows Server 2025。
  • 所有成員伺服器必須處於工作群組環境中,不能加入任何 Active Directory 網域環境。倘若,先前曾經加入過 Active Directory 網域環境,即便已經退出網域環境至工作群組中,也必須重新命名電腦名稱並重新啟動主機,確保成員伺服器移除 Active Directory 快取。
  • 工作群組叢集環境中,仍必須具備集中式儲存資源,提供給所有成員伺服器使用,舉例來說,必須有儲存空間直接存取(S2D)超融合環境、SAN 儲存資源、SMB 3.0 儲存資源 …… 等。
  • 工作群組叢集仍需要組態設定仲裁機制,確保工作群組叢集具備高可用性,支援的仲裁類型包括,雲端見證、磁碟見證、USB 見證 …… 等。

值得注意的是,工作群組叢集並非支援所有類型的工作負載,所以企業和組織在部署建置前必須正確評估,確保營運服務是否在工作群組叢集支援的工作負載清單中。下列為企業和組織常見的叢集服務,以及工作群組叢集是否支援該叢集服務的說明:
  • Hyper-V VMs: 從 Windows Server 2025 版本開始,正式支援工作群組叢集 Hyper-V 虛擬化環境工作負載,並且支援「線上遷移」(Live Migration)工作群組叢集中的 VM 虛擬主機,至其它台成員伺服器繼續運作,且遷移過程中不會發生任何中斷和停機時間。
  • SQL Server Availability Groups: 從 Windows Server 2016 至最新的 Windows Server 2025,工作群組叢集皆支援網域獨立的 SQL 可用性群組工作負載。
  • File Servers: 因為驗證問題,所以工作群組叢集「不支援」檔案伺服器叢集服務。
  • SQL Server Always On: 工作群組叢集「不支援」,採用「容錯移轉叢集執行個體」(Failover Cluster Instance,FCI)方式,建立的 SQL Server Always On 高可用性工作負載。



安裝 Windows Server 2025

在本文實作環境中,將安裝和部署三台 Windows Server 2025 主機(如圖 10 所示),其中二台將建構雙節點的工作群組叢集環境,另一台擔任集中式 SMB 儲存資源的角色,至於運作環境中已經具備 DNS 名稱解析服務。

圖 10、安裝和部署 Windows Server 2025 主機



採用一致的系統管理員帳戶

在工作群組叢集運作架構中,所有成員伺服器必須採用相同且一致的系統管理員帳戶及密碼,並且系統管理員帳戶必須加入「本機 Administrators 群組」才行,在本文實作環境中,採用系統預設的 Administrator 系統管理帳號,已經滿足部署條件,所以無須額外的組態設定作業。

值得注意的是,倘若採用的系統管理員帳戶,並非建置系統時內建的系統管理員帳戶,而是額外新增的系統管理員帳戶時,除了確保加入本機 Administrators 群組之外,還必須組態設定啟用「LocalAccountTokenFilterPolicy」才行,管理人員可以採用兩種方式進行啟用。

第一種方式,透過開啟 Registry Editor 後,切換至「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System」路徑後,新增 DWORD(32-bit)值,名稱為「LocalAccountTokenFilterPolicy」而值為「1」後,按下確認鈕進行新增即可(如圖 11 所示)。

圖 11、透過 Registry Editor 啟用 LocalAccountTokenFilterPolicy

第二種方式,管理人員直接執行 PowerShell 指令「New-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy -Value 1」新增機碼值即可達成啟用的目的。



新增主要 DNS 尾碼

雖然,運作環境中已經具備 DNS 名稱解析伺服器,然而成員伺服器因為處於工作群組環境,在預設情況下並不會自動帶入 DNS 尾碼,所以必須手動幫每一台成員伺服器組態設定 DNS 尾碼。

請依序點選「Settings > System > About > Advanced System Settings > Computer Name > Change > More」項目,在 Primary DNS suffix of this computer 欄位,鍵入 DNS 尾碼「lab.weithenn.org」後按下 OK 鈕(如圖 12 所示),系統會提示必須重新啟動主機才能套用生效。

圖 12、為所有成員伺服器組態設定 DNS 尾碼



新增 WinRM 遠端管理信任主機

由於工作群組叢集中,並沒有 Active Directory 網域環境,所以必須針對所有成員伺服器,組態設定 WinRM 遠端管理機制,將成員伺服器互相設定為受信任的主機。同樣的,管理人員可以採用兩種方式進行組態設定。

第一種方式,鍵入 gpedit.msc 開機本機群組管理原則編輯器後,依序點選「Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management(WinRM)> WinRM Client > Trusted Hosts」,在 Trusted Hosts 視窗中點選至 Enabled 項目,然後在 TrustedHostsList 欄位中,鍵入成員伺服器主機名稱為信任主機,多筆主機名稱之間採用逗號進行分隔,確認無誤後按下 OK 鈕即可(如圖 13 所示)。

圖 13、透過本機群組管理原則編輯器,組態設定 WinRM 遠端管理信任主機清單

第二種方式,管理人員直接執行 PowerShell 指令「Set-Item WSMan:\localhost\Client\TrustedHosts -Value "node01,node02"」,在 WinRM Security Configuration 系統回應訊息中,請管理人員按下 Y 鍵,確認新增 WinRM 遠端管理信任主機清單,接著再次執行「Get-Item WSMan:\localhost\Client\TrustedHosts」指令,確認 WinRM 遠端管理信任主機是否套用生效。



安裝 Hyper-V 角色和容錯移轉叢集功能

在本文實作環境中,將會在工作群組叢集中運作 Hyper-V 虛擬化平台,並建立 VM 虛擬主機運作相關服務。請在所有成員伺服器中,為主機安裝 Hyper-V 和容錯移轉叢集功能,請在啟動伺服器管理員後,依序點選「Manage > Add Roles and Features > Role-based or feature-based installation > Node01 > 勾選Hyper-V > 勾選 Failover Clustering」,由於安裝 Hyper-V 伺服器角色後需要重新啟動主機,請勾選「Restart the destination server automatically if required」選項後,按下 Install 鈕進行安裝作業(如圖 14 所示)。

圖 14、所有成員伺服器安裝 Hyper-V 角色和容錯移轉叢集功能

管理人員也可以在 PowerShell 指令視窗中,執行「Install-WindowsFeature –Name Hyper-V,Failover-Clustering –IncludeManagementTools」指令,進行 Hyper-V 角色和容錯移轉叢集功能的安裝作業,在重新啟動主機後,執行「Get-WindowsFeature –Name Hyper-V,Failover-Clustering」指令,確認安裝作業是否成功。



SMB 檔案共用伺服器

在本文實作環境中,SMB 主機將安裝檔案伺服器角色,擔任 Node01 和 Node02 雙節點工作群組叢集中的儲存資源角色。請在 SMB 主機開啟伺服器管理員,依序點選「Manage > Add Roles and Features > Role-based or feature-based installation > SMB.lab.weithenn.org > File and Storage Services > File and iSCSI Services > File Server」項目,為 SMB 主機安裝檔案伺服器角色。

安裝作業完成後,在伺服器管理員中,依序點選「File and Storage Services > Shares >Tasks > New Share」項目,在彈出視窗中首先選擇「SMB Share - Applications」項目為分享類型,在 Share location 區塊中,選擇預設的「C :」即可,在 Share name 欄位中鍵入「VMs」,在下方可以看到,系統將預設使用「C:\Shares\VMs」路徑,以及遠端路徑「\\SMB\VMs」為分享路徑(如圖 15 所示),後續將存放 Node01 和 Node02 建立的 VM 虛擬主機。

圖 15、組態設定 SMB 檔案分享名稱和路徑

在 Other Settings 視窗中,採用系統預設值即可,在 Permissions 視窗中請按下 Customize permissions 鈕,在彈出自訂權限視窗中,首先按下「停用繼承」(Disable inheritance)鈕,再按下「Convert inherited permissions into explicit permissions on this object.」,以便將繼承的權限轉換成此物件中的明確權限,確保 Administrators 群組,以及 SYSTEM 和 CREATOR OWNER 具備「完全控制」(Full Control)權限即可。



執行叢集驗證測試

在正式建立工作群組叢集之前,建議先執行叢集驗證測試,確保通過所有叢集驗證測試,以便稍後建立工作群組叢集時,可以順利建立不會遭遇非預期的錯誤。

請在 Node01 或 Node02 主機中,在伺服器管理員視窗中的 Tools 選項清單內,開啟 Failover Cluster Manager,在容錯移轉叢集管理員視窗中,依序點選「Failover Cluster Manager > Management > Validate Configuration」,在 Select Servers or a Cluster 視窗中,鍵入 Node01 和 Node02 主機的 FQDN 名稱後,按下 Add 鈕加入至伺服器清單中(如圖 16 所示)。

圖 16、將 Node01 和 Node02 主機加入至伺服器清單中

在 Testing Options 測試清單頁面中,選擇系統預設值「Run all tests」執行所有驗證測試項目,在系統執行叢集驗證測試結果中,請確保 Node01 和 Node02 主機,皆通過所有叢集驗證測試項目(如圖 17 所示),倘若有任何驗證測試項目發生警告或失敗的情況時,請管理人員務必判斷並修正問題後,再次執行並通過叢集驗證測試,管理人員也可以透過 PowerShell 指令「Test-Cluster -Node node01.lab.weithenn.org,node02.lab.weithenn.org」,執行叢集驗證測試的工作任務。

圖 17、執行叢集驗證測試工作任務



建立工作群組叢集

順利通過叢集驗證測試作業後,便可以放心建立工作群組叢集,請在容錯移轉叢集管理員視窗中,依序點選「Failover Cluster Manager > Management > Create Cluster」,同樣的在 Select Servers 視窗中,將 Node01 和 Node02 主機加入至成員伺服器清單內,在 Access Point for Administering the Cluster 頁面中,鍵入工作群組叢集的名稱,本文實作環境為「wg-cluster」,而叢集固定 IP 位址則是「10.10.75.15」(如圖 18 所示)。

圖 18、組態設定工作群組叢集名稱和固定 IP 位址

在 Confirmation 視窗中,系統會顯示工作群組叢集的組態設定資訊,確認無誤後按下 Next 鈕繼續,系統便會自動執行建立工作群組叢集的動作,然後在 Summary 視窗中顯示部署結果,管理人員也可以按下 View Report 鈕查看詳細資訊(如圖 19 所示),或按下 Finish 鈕完成。

圖 19、查看部署工作群組叢集的詳細資訊

同樣的,管理人員也可以透過 PowerShell 指令「New-Cluster –Name wg-cluster –Node node01.lab.weithenn.org,node02.lab.weithenn.org –AdministrativeAccessPoint DNS –StaticAddress 10.10.75.15」,達成建立和部署工作群組叢集的工作任務(如圖 20 所示),並且執行 PowerShell 指令「Get-Cluster」和「Get-ClusterResource」,確認和檢查工作群組叢集相關資訊。

圖 20、順利部署工作群組叢集



建立檔案共用見證

根據微軟官方的最佳建議作法,當容錯移轉叢集中成員伺服器數量為「偶數」時,便應該組態設定「仲裁」(Quorum)或稱「見證」(Witness),以便容錯移轉叢集發生災難事件,導致成員伺服器停止運作或中斷連線時,仲裁見證機制便可以讓容錯移轉叢集能繼續正常運作。

值得注意的是,採用檔案共用見證機制時,倘若是未加入 Active Directory 網域的叢集環境時,則組成容錯移轉叢集的成員伺服器,必須至少是 Windows Server 2019 或更新版本,並且採用的 SMB 版本至少要 2.0 或更新版本。

請先切換至 SMB 主機,採用跟剛才一樣的作法,建立給工作群組叢集使用的 SMB 檔案共用見證,在建立時同樣採用「SMB Share - Applications」分享類型,在 Share location 區塊中,選擇預設的「C :」即可,在 Share name 欄位中鍵入「Witness」,在下方可以看到,系統將預設使用「C:\Shares\Witness」路徑,以及遠端路徑「\\SMB\Witness」為分享路徑,後續便存放工作群組叢集的仲裁見證資訊。

切換回 Node01 或 Node02 主機中,在容錯移轉叢集管理員視窗中,依序點選「wg-cluster.lab.weithenn.org > More Actions > Configure Cluster Quorum Settings」,在選擇仲裁類型視窗中選擇「Select the quorum witness」選項,在選擇使用的仲裁方式視窗中,選擇「Configure a file share witness」,在檔案共用路徑欄位中,鍵入剛才於 SMB 主機建立的「\\SMB\Witness」遠端分享路徑,確認無誤後系統便自動為工作群組叢集,組態設定及建立檔案共用見證機制,確保工作群組叢集遭遇災難事件時,能夠繼續正常運作(如圖 21 所示)。

圖 21、為工作群組叢集組態設定及建立檔案共用見證機制





結語

透過本文的深入剖析和實戰演練後,相信管理人員除了理解最新 Windows Server 2025,有哪些亮眼特色功能外,並實戰演練工作群組叢集並加上檔案共用見證機制,讓小型企業和組織,即便在沒有 Active Directory 網域環境的情況下,也能輕鬆建構容錯移轉叢集運作環境。

Announcing NCA & NCP-MCI v6.10 - Get Certified for Free with Limited-Time Offer | Nutanix

$
0
0


簡介


在 Nutanix 認證架構中共有四個等級,分別是 Associate, Professional, Master, Expert,這次開放 Associate 和 Professional 相關課程和考試卷。






NCA v6.10 Certification

對於 Nutanix Certified Associate (NCA) 認證有興趣的朋友,可以透過 Nutanix Hybrid Cloud Fundamentals (NHCF) | NCA 6.10 Learning Plan 課程學習後去應考。






NCP-MCI v6.10 Certification







注意事項

Data Encryption and Key Management | Nutanix

$
0
0


簡介

本文為擷取 Data Encryption and Key Management | The Nutanix Cloud BibleAOS Security 6.10 - Data-at-Rest Encryption 文件內容中,針對 Nutanix 提供的資料加密部份進行整理。

圖、Nutanix Cluster 加密架構示意圖



Data Encryption

在討論資料加密時,通常會有下列兩種方式 (In-transit、At-rest),針對資料層級進行加密的方式:

In-transit: 針對兩方之間的傳輸資料進行加密,例如,透過網路傳送資料。在 Nutanix 環境中,便是透過軟體加密方式,在 Nutanix Cluster 中保護 RF 資料複寫時進行加密。
  • 軟體式加密 (FIPS-140-2 Level-1 / AES-256),從 Nutanix AOS 5.5開始支援。
  • 採用 AHV 時,支援 Cluster Level、VM Level、VG Level 加密,有關支援 VM Level 和 VG Level 加密的部份,請參考 Prism pc.2024.2 - Storage Policy Based Encryption 文件內容。
    • Nutanix 建議採用 Cluster Level 加密,以避免造成額外的工作負載和管理開銷。
    • 一旦在 Cluster Level 或 Container Level 啟用加密機制後,便「無法停用」加密機制!! 即便停止或重新啟動 Nutanix Cluster 也沒用。
    • 資料複寫至「另一個 Cluster」時,並「不會加密」,所以必須為每個叢集啟用加密功能。
  • 採用 ESXi, Hyper-V 時,同時支援 Cluster Level 和 Container Level 加密。
圖、Data Encryption - Enabled (cluster level)

At-rest: 針對靜態資料進行加密,例如,儲存在裝置中的資料。在 Nutanix 環境中,透過整合實體儲存裝置的 Self-Encrypting Drives (SED) 功能,達到靜態資料加密的目的。
  • SED 硬體式加密 (FIPS-140-2 Level-2),支援  Cluster Level 加密。
  • 當資料寫入磁碟機時,會自動進行加密,當讀取資料時會進行解密,儲存裝置中的晶片組會控制加密和解密過程,系統效能不受影響並且不依賴於系統軟體。
  • 在初始化設定時,SED 會建立一個唯一的隨機金鑰,用於在資料寫入期間加密並在讀取時解密資料,資料加密金鑰 (Data Encryption Key,DEK),可以確保儲存裝置中的資料始終加密,因為每次寫入資料或讀取資料時,都需要 DEK 對資料進行加密和解密才行,倘若 DEK 不可用的話,便無法存取 SED 內的資料,導致儲存裝置內的資料都無法使用。
圖、用於 SED 儲存裝置的 DEK 加密金鑰



Native Software-based Encryption

Nutanix 軟體加密提供原生的 AES-256 資料靜態加密,它可以跟任何符合 KMIP 或 TCG 的外部 KMS 伺服器,例如 Vormetric、SafeNet……等進行互動,也可以使用 Nutanix 從 5.8 版本開始支援的原生 KMS。同時,整合 Intel AES-NI 進行資料加解密時,能夠最小化軟體加密對效能的影響。

當資料寫入時(OpLog 和 Extent Store),資料在寫入磁碟之前,會在Checksum Boundary 時進行加密,然後將加密資料複寫到遠端的 CVM 中 (RF 複寫)。原則上,軟體式加密機制並不會影響進階功能,例如,Deduplication, Compression, Zero Block Suppression,因為資料加密是在這些進階功能之後才執行。

圖、Data Encryption - Transform Application



SED Based Encryption

SED 資料加密的工作原理,是將儲存裝置分成「Strips」,當 Nutanix 叢集啟動時,將會呼叫 KMS 伺服器取得解鎖儲存裝置的金鑰,為了確保安全性,叢集上不會快取任何金鑰,一旦發生 Cold Boot 和 IPMI Reset 事件時,節點會需要 Callback KMS 伺服器以解鎖儲存裝置,至於 CVM Soft Resatrt 則不會發生這種情況。

圖、Data Encryption - SED

圖、儲存裝置啟用 SED 加密



Key Management (KMS)

Nutanix 支援 Local Key Manager (LKM),也就是將 LKM 服務分佈在每台 Nutanix 節點中,然後在 CVM 上運作,以簡化管理,但是仍然支援外部 KMS。

目前,Nutanix 加密方式中支援下列三種類型的金鑰:
  • Data Encryption Key (DEK): 用於加密「資料」的金鑰。
  • Key Encryption Key (KEK): 用於加密「 DEK」的金鑰。
  • Master Encryption Key (MEK): 用於加密「KEK」的金鑰。
圖、Data Encryption - Key Management

Nutanix Hybrid Cloud Fundamentals (NHCF) | Module 1

$
0
0


簡介

趁著有免費考試卷的機會,就順便再讀一下 Nutanix Hybrid Cloud Fundamentals (NHCF) | NCA 6.10 Learning Plan 線上課程去應考吧。下列為本章節的個人重點整理。





Module 1 - Introduction to HCI, Nutanix, and Prism

Nutanix Hybrid Cloud Fundamentals (NHCF) 是入門課程,可以幫助你熟悉 Nutanix 叢集的特色功能 (Features)和運作元件 (Components)。



Understanding Hyperconverged Infrastructure

傳統的三層式架構中,包括,獨立的儲存設備和儲存網路及硬體伺服器,不但無法支援現代商業和企業應用的快速發展,反而成為一種障礙。這些基礎架構製造出資源孤島,阻礙了變革和進步。在採購、部署和管理的每一過程中,這些資源孤島都會帶來影響,例如,新專案需要多個團隊的批准、IT 資源需求必須提前三到五年進行預測,以及鎖定和授權成本壓縮了本來就不多的預算。

因此,企業 IT 團隊尋求能以公有雲服務,例如,AWS、Azure、GCP……等的速度和營運效率,向內部客戶提供地端資料中心的服務部署方法。

值得注意的是,這些雲端公司及一些全球最大的網路公司,早在市場面臨傳統基礎架構的限制之前,就已經開發出分散式系統技術,滿足其可擴展性、可靠性和營運效率的需求,這也就催生出 HCI 超融合基礎架構。

圖、Comparing Three-tier Architecture and HCI Infrastructure



An Introduction to Nutanix

Nutanix 提供統一混合多雲管理的單一平台。Nutanix 雲平台整合了運算、虛擬化、儲存、網路、安全及容器,簡化了企業 IT 環境的日常管理,並從私有雲擴展到公有雲,例如,AWS 和 Microsoft Azure。

透過在業界標準的 x86 伺服器上運行 Nutanix 軟體,企業能夠以相對較小的部署開始,並根據需要逐步擴展每個節點(伺服器)。每個節點包括搭載 Intel 或 AMD 硬體的 x86 處理器,配備  SSD 和 HDD。

單一的 Nutanix 叢集可以擴展至與超融合叢集相同的規模。不同的硬體平台可滿足各種計算和儲存需求。Nutanix 軟體對硬體具有廣泛的相容性,並且可以在 Dell、Lenovo、Cisco、HPE……等多家硬體供應商的硬體上運作。

圖、Characteristics of the Nutanix Cloud Platform



What is the Nutanix Cloud Platform?

Nutanix 解決方案包括下列解決方案,詳細資訊請參考 Nutanix Cloud Platform Software Options

圖、Nutanix Cloud Platform

圖、Nutanix Cloud Platform Layers



The Core Components of the Nutanix Solution

AOS Storage、AHV Virtualization、Prism (PE / PC) 組成整個 Nutanix 解決方案的核心。
  • AOS Storage: High performance storage, Resilient and secure storage, Flexible and scalable cloud infrastructure。
  • AHV Virtualization: Ease of management, Native security, Low operational costs, Exceptional performance。
  • Prism: 1-click management simplicity, Automate operations, Optimize resources and cost。

圖、Core components of the Nutanix solution



Introduction to Nutanix Prism

了解 Nutanix 管理平台 Prism 又區分為 Prism Element (PE) 和 Prism Central (PC) 兩種。簡單來說,通常管理單一叢集就採用 PE,而管理多個叢集時就用 PC,但細節的部份仍有不同。

圖、Prism 包含 PE 和 PC

如何登入 PE 管理介面,詳細資訊可以參考 Prism 6.10 - Logging Into the Prism Element Web Console 文件內容。原則上,開啟瀏覽器鍵入 Cluster VIP 位址搭配 Port 9440 即可,順利登入後即可看到 Prism Element Home Dashboard。

圖、Prism Element Home dashboard

值得注意的是,預設情況下,登入 PE 管理介面的 admin 帳號的密碼,將會在「60 天」後過期,管理人員可以透過指令進行修改,詳細資訊請參考 Prism 6.10 - Cluster Management 文件內容。

圖、 PE 管理介面 admin 帳號的密碼,預設 60 天後過期

原則上,登入 PC 管理介面,跟登入 PE 管理介面類似,詳細資訊請參考 Prism pc.2024.2 - Logging Into Prism Central 文件內容。Prism Element 與 Prism Central 的首頁儀表板滿足了不同的叢集監控需求。Prism Element 提供即時且強大的監控體驗,方便快速獲取概要和詳細資訊。而 Prism Central 除了具備 Prism Element 的所有功能外,還提供高度自訂的監控體驗,可以根據特定需求進行調整。此外,Prism Central 是唯一能夠從單一位置監控多個叢集的介面。

相較於 Prism Element,Prism Central 還包含更多管理功能,例如,在 VM 虛擬主機管理方面,Prism Central 除了 Prism Element 的功能外,還可以啟用或禁用效能測量、異常檢測、將 VM 虛擬主機加入目錄、運行 Playbook、管理類別……等。因此,即使是管理單一叢集,也建議使用 Prism Central 以利使用進階特色功能。

圖、Capabilities of Prism Central and Prism Element



Understanding Nutanix Pulse

預設情況下,系統會啟用 Nutanix Pulse 功能,以便向 Nutanix Insights 服務提供診斷系統資訊。原則上,這些診斷數據在背景中無干擾地收集,對系統效能影響極小,以便自動檢測問題並簡化故障排除。

初次登入 Prism 或升級後,系統會檢查是否啟用 Pulse。如果未啟用,系統會提示您啟用 Pulse。
一旦啟用 Pulse 後,預設每天將叢集配置的摘要電子郵件發送到 Nutanix 支援伺服器,這些收集的資訊,將會透過 HTTPS(443 埠)使用 TLS 1.2 發送到 insights.nutanix.com和指定的電子郵件地址。收集的資訊如下,詳細資訊請參考 Information collected by Pulse (KB 2232) :
  • System alerts.
  • System tasks.
  • System logs.
  • System configuration.
  • Performance metrics.
  • Current Nutanix software version.
  • Nutanix processes and Controller VM (CVM) information.
  • Hypervisor details such as type and version.



Performing Initial Cluster Setup

下列為 Nutanix 叢集建構完成後,初始的組態設定建議:










Nutanix Hybrid Cloud Fundamentals (NHCF)

  • (本文) Module 1 - Introduction to HCI, Nutanix, and Prism
  • Module 2 - Hardware and Storage Concepts
  • Module 3 - AHV Networking Fundamentals
  • Module 4 - Image Management Fundamentals
  • Module 5 - VM Management Fundamentals
  • Module 6 - Data Protection and DR Fundamentals
  • Module 7 - Cluster Monitoring Fundamentals
  • Module 8 - Understanding Licensing and Performing Upgrades
Viewing all 591 articles
Browse latest View live