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

NET::ERR_CERT_INVALID | Prism Element | Nutanix CE

October 12, 2023, 3:00 pm
$
0
0

 



Question: 無法進入 Prism Element 登入介面？

在 CVM 主機上，確認 Prism Element 管理介面 (Port 9440) 已經 Listen。然而，使用 Google Chrome 或 Microsoft Edge 嘗試登入 Prism Element 管理介面時，卻顯示「NET::ERR_CERT_INVALID」的警告訊息，並且展開 Advanced 也沒有略過的按鈕可以繼續？






Answer:

嘗試開啟 Microsoft Edge IE Mode試試，詳細資訊請參考 Microsoft Edge 中的 Internet Explorer 模式 - Microsoft 支援服務 文章內容。


啟動 Microsoft Edge IE Mode 之後，可以順利看到 Prism Element 登入介面。


但是，登入後發現有些區塊無法順利顯示或一直顯示載入中，但就是無法順利載入。


後來發現比較正確的作法 (適用於 Google Chrome和 Microsoft Edge)。請在錯誤網頁中空白處，直接敲打鍵盤上的「thisisunsafe」(舊稱為 badidea) 💩，即可順利載入這個不安全的網頁，並看到 Prism Element 登入畫面 😅。


順利登入後，看到完整載入且順利顯示的 Prism Element 管理介面。


↧
Search

透過 Cloud Run 部署網站 - Task5 | GSP659

October 16, 2023, 3:00 pm
$
0
0

 


簡介

在本文實作練習中，將會透過 Deploy Your Website on Cloud Run | Google Cloud Skills Boost 主題，學習如何在 GCP 雲端環境中，如何透過 Cloud Run (Serverless) 技術，部署和管理組織和企業的網站。
在上一篇文章中，除了重新部署  Docker 容器映像檔之外，更嘗試採用不同的 Concurrency 數值。在本文中，將會實作如何更新網站內容，並且重新建構和部署  Docker 容器映像檔。下圖為本文實作環境的 Cloud Run 運作架構示意圖：






Task 5、更新網站內容

一旦企業和組織的網站正式上線後，不可能萬年不變，而是因應各種專案的需求而必須變更網站內容。在本文實作環境中，將模擬新的網站內容檔案「index.js.new」已經上傳，只需要重新命名為「index.js」即可。

請執行「cd ~/monolith-to-microservices/react-app/src/pages/Home」和「mv index.js.new index.js」指令，切換路徑後重新命名檔案。接著，執行「cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js」指令，再次確認新的網站內容是否正確，確認內容真的更新 React 元件。


請執行「cd ~/monolith-to-microservices/react-app」和「npm run build:monolith」指令，建立 React 應用程式並複製到公用目錄中，完成網站內容更新的動作後，必須重新建構 Docker 容器映像檔並推送到 Artifact Registry。


同樣的，更新內容後執行「cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag us-central1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:2.0.0」指令，重新建構 Docker 容器映像檔並給予「2.0.0」的版本標籤。






透過 Cloud Run 部署網站 - 系列文章

↧
↧

Network Port Diagram | Nutanix

October 18, 2023, 4:00 pm
$
0
0

 



簡介

在本文中，將會提供 Nutanix 安裝中相關運作元件，例如，CVM、AHV、Prism……等，之間互相溝通時會使用到的網路通訊埠資訊。




Network Port Diagram for AHV

圖片來源： Third-Party Platforms ANY - Network Requirements | Nutanix





Network Port Diagram for VMware ESXi

圖片來源： Third-Party Platforms ANY - Network Requirements | Nutanix





Network Port Diagram for Microsoft Hyper-V

圖片來源： Third-Party Platforms ANY - Network Requirements | Nutanix




↧

透過 Cloud Run 部署網站 - Task6 | GSP659

October 23, 2023, 3:00 pm
$
0
0

 


簡介

在本文實作練習中，將會透過 Deploy Your Website on Cloud Run | Google Cloud Skills Boost 主題，學習如何在 GCP 雲端環境中，如何透過 Cloud Run (Serverless) 技術，部署和管理組織和企業的網站。
在上一篇文章中，更新 NodeJS 網站內容後，重新建構和部署  Docker 容器之外，並更新版本標籤為 2.0.0。本文為此系列文章的最後一篇，將會實作如何在不干擾使用者的情況下，更新網站內容。下圖為本文實作環境的 Cloud Run 運作架構示意圖：






Task 6、零停機情況下更新網站內容

事實上，在 Cloud Run 運作架構中，會將每個部署動作視為新版本，每當建構和部署新版本並上線後，系統便會自動將使用者請求流量，重新導向至新版本。

同時，在預設情況下，系統將會分配新版本 100%的 Inbound 網路流量。但是，管理人員可以透過「路由」(Routes) 機制，組態設定不同百分比的 Inbound 網路流量，將不同的網路流量分配給不同的運作版本。

請執行「gcloud run deploy monolith --image us-central1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:2.0.0 --region us-central1」指令，重新部署服務至新版本。

重新部署服務的動作執行完成後，請執行「gcloud run services describe monolith --platform managed --region us-central1」指令，驗證部署是否已經更新完成。接著，執行「gcloud beta run services list」指令，條列出服務資訊及 URL 網址。


此時，可以直接點選 URL 網址，可以看到網站的主要頁面文字已經順利修改 (更新至新版本)。


透過這個線上實作環境，相信可以讓企業和組織的管理人員，能夠理解如何使用 Cloud Run 運作環境，來輕鬆管理企業和組織的網站。同樣的，在完成實作練習結束前，記得確認是否通過所有的檢查程序，才能確保獲得這個實作課程的積分。






透過 Cloud Run 部署網站 - 系列文章

↧

.NET Framework 4.8 was installed, but a reboot is required | AzStackHCISandbox

October 25, 2023, 3:00 pm
$
0
0

 



Question: .NET Framework 4.8 was installed, but a reboot is required.

最近 (2023 年 5 月 31 之後)，倘若你有嘗試透過 microsoft/AzStackHCISandbox | GitHub部署 Azure Stack HCI 超融合環境時，那麼應該會在執行 New-AzSHCISandbox.ps1過程中，在執行 chocolateyInstaller.psm1時，發生 .NET Framework 4.8 was installed, but a reboot is required錯誤而停止。






Answer:

簡單來說，因為在 2023 年 5 月 31 日之後，Chocolatey 更新至 2.0.0版本所導致的問題。詳細資訊請參考：

因此，請在執行 New-AzSHCISandbox.ps1 部署作業之前，修改內容中有關安裝 Chocolatey 的指令內容。請將第 2543 行內容，從原本的「Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))」修改為「Set-ExecutionPolicy Bypass -Scope Process -Force; Invoke-WebRequest -Uri 'https://chocolatey.org/install.ps1' -OutFile 'install.ps1'; .\install.ps1 -ChocolateyDownloadUrl "https://community.chocolatey.org/api/v2/package/chocolatey/1.4.0"」後，存檔離開即可。然後，再次執行 New-AzSHCISandbox.ps1 部署作業，即可順利繼續執行下去。


當然，經過 2 小時左右，Azure Stack HCI + SDN 的 AzStackHCISandbox 環境，便自動且順利的部署完成。😁


↧
↧

AHV Node Architecture | Nutanix

October 27, 2023, 11:42 am
$
0
0

 



簡介

AHV 是原生 Nutanix Hypervisor，它是建構在 CentOS KVM 基礎之上，並提供 HA, Live Migration, IP 位址管理…等功能。此外，AHV 也是 Microsoft Server Virtualization Validation Program 的一部份，也通過驗證可以運作 Microsoft OS 和應用程式。





AHV Node Architecture

在 AHV 運作架構中，CVM (Controller VM)會是 VM 虛擬主機的方式，運作在 AHV Node 當中，並且透過 PCI Passthrough 的方式，直接連接到底層 SCSI Controller 及 SSDH/HDD 儲存裝置。簡單來說，CVM 會直接存取底層儲存裝置，而非透過 Hypervisor 去存取，這樣的直接存取方式可以讓儲存效能更佳，而不會受到 Hypervisor 所影響。





KVM Architecture

在 KVM 運作架構中，有下列三個核心運作元件：
  • KVM-kmod： KVM 核心模組。
  • Libvirtd：用於管理 KVM, QEMU, Daemon 的 API。在整體運作架構中，AOS 和 KVM/QEMU 之間的通訊就是透過 Libvirtd 進行溝通。
  • Qemu-kvm：在 AHV 虛擬化運作架構中，便是透過 Qemu-kvm 機制提供硬體輔助虛擬化機制。





Configuration Maximums and Scalability

下列 Configuration Maximums資料，為 AHV 20220304.10013 and AOS 6.6 的數值：
  • Maximum cluster size: 32
  • Maximum vCPUs per VM: Number of physical cores per host
  • Maximum memory per VM: 4.5TB or available physical node memory
  • Maximum virtual disk size: 9EB* (Exabyte)
  • Maximum VMs per host: N/A – Limited by memory
  • Maximum VMs per cluster: N/A – Limited by memory
在 vDisk 方面，為何可以最大支援至 9 EB？ 主要原因在於，AHV 和 VMware ESXi / Microsoft Hyper-V 的運作架構不同，所有儲存資源都是以 SCSI Block Devices 的方式，直接傳遞給 VM 虛擬主機，所以 AOS 可以提供多大的虛擬磁碟，那麼 VM 虛擬主機就可以使用多大的 vDisk。
↧

實戰部署 AKS EE 小硬體資源打造容器叢集 | 網管人第 213 期

October 28, 2023, 11:39 pm
$
0
0

 



網管人雜誌

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





本文目錄






前言

在過去微軟的 Kubernets 容器叢集運作架構中，無論是 Azure 公有雲環境中的 AKS（Azure Kubernetes Service），或是整合超融合運作架構的 AKS-HCI，都是一開始就必須部署完整，並具備高可用性的 Kubernetes 容器叢集環境，然而對於硬體資源不多的邊緣運算環境來說，這些完整的 AKS 解決方案硬體需求太過龐大並不適合。因此，微軟在 2023 年 3 月正式推出 AKS EE（Edge Essentials）的 GA 版本 ，便是滿足邊緣運算以及小型運作環境的容器叢集解決方案。

簡單來說，AKS EE 是簡化版的 Kubernetes 部署環境，並且能夠運作在硬體資源少的邊緣運算環境中，同時支援運作 Linux 和 Windows 容器（如圖 1 所示），以便滿足不同的容器工作負載需求。

圖 1、AKS EE 運作架構示意圖
圖片來源： 關於 AKS Edge Essentials - AKS hybrid | Microsoft Learn





AKS EE 硬體需求和網路架構

原則上，AKS EE 的硬體需求極低，然而在建構和部署 AKS EE 容器叢集環境之前，仍建議管理人員應該預先確認，使用的主機作業系統以及硬體資源，是否支援並滿足建構和部署 AKS EE 運作環境，軟硬體需求如下：
  • 主機作業系統版本：支援 Windows 10/11 IoT Enterprise、Windows 10/11 Pro/Enterprise、Windows Server 2019、Windows Server 2022 版本作業系統，並建議採用最新的 22H2 版本。
  • CPU 處理器：至少 2 個 CPU，時脈建議至少為 1.8GHz 。屆時，若需要將建立的 AKS EE 叢集，連線至 Azure Arc 雲端環境，以及實作 GitOps 自動化機制時，則至少需要 4 個 CPU 。
  • 實體記憶體：至少 4 GB，並保留 2.5GB 可用記憶體空間。屆時，若需要將建立的 AKS EE 叢集，連線至 Azure Arc 雲端環境，並實作 GitOps 自動化機制時，則至少需要 8GB 並保留 4.5GB 可用記憶體空間。
  • 磁碟空間：至少 14GB 可用儲存空間。
  • Kubernetes 版本：支援最新版本的 K8s 和 K3s 。
  • 網路外掛程式：在 K8s 環境中支援 Calico，在 K3s 環境中支援 Flannel 。

在 AKS EE 容器叢集運作架構中，會為每個節點主機建立 VM 虛擬主機，舉例來說，Linux 節點主機將會採用由微軟客製化後的 Linux 發行版本 CBL-Mariner，而 Windows 節點主機則採用 Windows Server 2022 Datacenter Server Core 版本，並且 AKS EE 叢集將會管理 VM 虛擬主機的生命週期、組態設定、安全性更新（如圖 2 所示）。

圖 2、AKS EE 容器叢集環境，同時支援部署 Linux 和 Windows 節點主機
圖片來源： 關於 AKS Edge Essentials - AKS hybrid | Microsoft Learn

在 AKS EE 容器叢集網路環境方面，將會採用 Hyper-V 網路堆疊架構進行連接，舉例來說，建構 K8s 或 K3s 容器叢集環境中，系統將會自動建立 Hyper-V Internal 類型的 vSwitch 虛擬交換器，並且部署的 Linux 和 Windows 節點主機，預設便會連接至此 vSwitch 虛擬交換器，以便進行通訊作業。

在 AKS EE 單一主機容器叢集環境中，預設情況下，實體主機的 IP 位址將為 192.168.0.1，而部署的 Linux 節點主機兼 Kubernetes 控制平台，則會指派 192.168.0.2 的 IP 位址，當部署 Windows 節點主機時則指派 192.168.0.3 的 IP 位址（如圖 3 所示），而服務 IP 位址的第一個 IP 位址則是 192.168.0.4，當然也會透過 NAT 轉譯機制，讓 Linux 和 Windows 節點主機能夠透過實體主機網路，連線至網際網路環境，以便下載容器印象檔進行部署容器工作負載的動作。

圖 3、AKS EE 單一主機容器叢集網路環境示意圖
圖片來源： AKS Edge Essentials 網路功能 - AKS hybrid | Microsoft Learn

倘若，企業和組織後續需要部署多節點 AKE SS 容器叢集時，由於多個節點主機之間必須能夠順利通訊，將會改為採用 Hyper-V External 類型的 vSwitch 虛擬交換器，達到跨主機節點對節點的通訊任務。此外，由於節點主機之間是透過 External 類型的 vSwitch 虛擬交換器進行通訊，所以不需要進行 NAT 位址轉譯的動作（如圖 4 所示）。

圖 4、AKS EE 多節點主機容器叢集網路環境示意圖
圖片來源： AKS Edge Essentials 網路功能 - AKS hybrid | Microsoft Learn





實戰 – 部署 AKS EE 單一主機容器叢集

部署 Azure VM 虛擬主機（Option）

原則上，只要採用上述支援的硬體需求主機，便能建構和部署 AKS EE 叢集。倘若，企業和組織內並沒有多餘的主機可供建立測試環境，那麼可以考慮在 Azure 雲端環境中，建立支援巢狀虛擬化技術的 VM 虛擬主機，並採用上述支援的作業系統即可進行部署和測試。值得注意的是，採用支援巢狀虛擬化技術的 Azure VM 虛擬主機，建構和部署 AKS EE 叢集環境，僅適用於開發人員測試用途，並不適合真正用於營運環境。

在選擇 Azure VM 虛擬主機 Size 時，通常採用 D 或 E 系列即可支援巢狀虛擬化技術。然而，建議管理人員在選擇 Azure VM Size 之前，應該先確認是否支援巢狀虛擬化技術，避免後續實作時發生錯誤而必須重新建立測試主機。舉例來說，本文選擇 Standard_E4d_v5 的 VM 虛擬主機，可以看到此系列 VM 虛擬主機有支援巢狀虛擬化功能（如圖 5 所示）。

圖 5、確認選擇的 Azure VM Size 支援巢狀虛擬化功能
圖片來源： Edv5 與 Edsv5 系列 - Azure虛擬機器 - Azure Virtual Machines | Microsoft Learn

值得注意的是，由於 Azure Gen2 虛擬主機新增支援許多安全性機制，所以安全性類別預設會選擇為「Trusted launch virtual machines」選項，以便使用 Secure Boot 和 vTPM……等安全性機制。然而此舉，卻會使巢狀虛擬化功能無法正常運作，因此請記得將 Security Type 改選為「Standard」（如圖 6 所示），才能讓 Azure Gen2 虛擬主機正確支援巢狀虛擬化功能。詳細資訊請參考 Azure VM 的可信啟動 - Azure Virtual Machines | Microsoft Learn官方文件說明。

圖 6、採用 Gen2 時必須選擇 Security Type 為 Standard 才能支援巢狀虛擬化功能



安裝 AKS Edge Essentials

在 AKS EE 運作架構中，支援 主流的 K8s和 更精簡的 K3s，管理人員可以視需求部署其中一個。值得注意的是，採用 K3s 時則 CNI 網路外掛程式將會採用 Flannel，若採用 K8s 時則會改為採用 Calico 。在本文中，將會以部署 K3s 容器叢集為例。

此外，雖然 AKS EE 運作架構，同時支援 K8s 和 K3s 容器叢集環境，但請勿同時安裝 K8s 和 K3s，倘若想要測試不同的容器叢集環境，必須先將現有安裝的 AKS EE 版本移除並重新啟動後，再嘗試安裝另一個版本的容器叢集環境。

由於，AKS EE 容器叢集環境，同時支援 Linux 和 Windows 擔任節點主機，然而預設的 K8s 或 K3s 安裝程式，僅包含 Linux 節點主機相關檔案。因此，為了能夠部署 Windows 節點主機，必須額外下載 Windows 節點主機檔案（AksEdgeWindows-1.2.414.0.zip），以便後續能夠部署 Windows 容器。

下載完成後，請將 K3s 安裝程式和解壓後的 Windows 節點主機檔案，放置在同一個資料夾內或路徑中，並以系統管理員身份開啟 PowerShell，然後執行「msiexec.exe /i AksEdge-k3s-1.25.8-1.2.414.0.msi ADDLOCAL=CoreFeature,WindowsNodeFeature」指令（如圖 7 所示），安裝 K3s 容器叢集並準備進行混合部署。

圖 7、安裝 AKS EE K3s 容器叢集運作環境相關檔案

安裝完成後，請先執行「Import-Module AksEdge」指令，將 AKS EE 的 PowerShell 模組載入系統中，然後執行「Get-Command -Module AKSEdge | Format-Table Name, Version」指令，確保 AKS EE 的 PowerShell Cmdlet 模組載入成功（如圖 8 所示）。

圖 8、確認 AKS EE 的 PowerShell Cmdlet 模組載入成功

執行「Install-AksEdgeHostFeatures」指令，系統將會進行驗證程序，確保 AKS 主機是否安裝並啟用 Hyper-V、SSH、電源設定……等，倘若系統偵測到主機並未安裝和相關組態設定時，將會進行安裝和啟用等工作任務，並且在完成後提示管理人員應該重新啟動主機（如圖 9 所示）。重新啟動後，可以再次執行指令，倘若主機已經滿足所有驗證程序，便不會顯示任何警告或錯誤訊息，並且在結尾顯示「True」訊息。

圖 9、確認 AKS 主機是否安裝並啟用 Hyper-V、SSH、電源設定



部署 AKS EE K3s 容器叢集

部署 AKS EE 容器叢集的方式，是先透過指令建立 JSON 組態設定檔案，然後再執行指令搭配客製化後的 JSON 組態設定檔案，進行 AKS EE 容器叢集的部署作業。

首先，請執行「New-AksEdgeConfig -DeploymentType SingleMachineCluster -NodeType LinuxAndWindows -outFile .\aksedge-config.json | Out-Null」PowerShell 指令，產生名稱為「aksedge-config.json」的 JSON 組態設定檔案。

其中 -NodeType參數，支援使用「Linux、Windows、LinuxAndWindows」參數值，值得注意的是，由於 Kubernetes 控制平面是採用 Linux 所撰寫的，所以部署的第一台節點主機必須為 Linux 節點才行。

下列為 aksedge-config.json組態設定檔案內容中，相關重要參數的描述說明：
  • DeploymentType： 此參數為定義 AKS EE 部署類型，本文實作組態設定為SingleMachineCluster 。
  • Init.ServiceIPRangeSize： 預設值為 0，表示建立沒有服務 IP 範圍的容器叢集，屆時運作的容器工作負載，系統將不會配置服務 IP 位址，管理人員必須手動使用 Get-AksEdgeNodeAddr 指令，確認節點主機的 IP 位址。本文實作環境調整為 10，表示為 Kubernetes 容器叢集服務配置 10 個服務 IP 位址。
  • Network.NetworkPlugin： 預設值為 flannel，這是採用 K3s 容器叢集的 CNI 預設值。倘若管理人員安裝的是 K8s 容器叢集，請將此參數值預設值將為 calico 。
  • LinuxNode.CpuCount： 預設值為 4，表示部署 Linux 節點主機時將會配置 4vCPU 。
  • LinuxNode.MemoryInMB： 預設值為 4096，表示部署 Linux 節點主機時將會配置 4GB vMemory 記憶體空間。
  • LinuxNode.DataSizeInGB： 預設值為 10，表示部署 Linux 節點主機時將會配置 10GB vDisk 虛擬磁碟空間。
  • WindowsNode.CpuCount： 預設值為 2，表示部署 Windows 節點主機時將會配置 2vCPU 。
  • WindowsNode.MemoryInMB： 預設值為 4096，表示部署 Windows 節點主機時將會配置 4GB vMemory 記憶體空間。

依照上述說明和建議修改 JSON 組態設定檔案內容後，即可執行「New-AksEdgeDeployment -JsonConfigFilePath .\aksedge-config.json」指令，執行 AKE EE K3s 容器叢集的部署作業。本文實作環境花費 10 分鐘，成功建構 AKS EE K3s 容器叢集，並且部署 Linux 和 Windows 節點主機（如圖 10 所示）。

圖 10、成功建構 AKS EE K3s 容器叢集並部署 Linux 和 Windows 節點主機



驗證叢集運作情況

部署 K3s 容器叢集和節點主機成功後，在正式部署容器之前，管理人員應先驗證容器叢集運作情況，避免屆時遭遇非預期的錯誤。

由於，預設情況下系統僅安裝 Hyper-V PowerShell Cmdlet，管理人員可以手動安裝 Hyper-V 管理員伺服器功能，以方便檢查和驗證 Linux 及 Windows 節點主機運作情況，以及 vSwitch 虛擬交換器等相關組態設定。

安裝完成後，開啟 Hyper-V 管理員中的虛擬交換器管理員，可以看到系統已經自動建立一個名稱為「aksedgesw-int」的 vSwitch 虛擬交換器，並且連接類型為「Internal Only」，同時使用「192.168.0.1」的 IP 位址，同時在 Hyper-V 管理員中，可以看到二台 VM 虛擬主機，名稱分別為「aksee-lab01-ledge」和「aksee-lab01-wedge」，就是剛才系統所部署的 Linux 和 Windows 節點主機（如圖 11 所示），並且使用「192.168.0.2」和「192.168.0.3」IP 位址。

圖 11、確認 Linux 和 Windows 節點主機運作正常

管理人員也可以透過 kubectl 指令，檢查並確認 K3s 容器叢集，以及 Linux 和 Windows 節點主機是否運作正常，請在 PowrShell 指令視窗中，執行「kubectl get nodes -o wide」指令，可以查看 Linux 和 Windows 節點主機運作資訊，執行「kubectl get pods -A -o wide」指令，可以查看 K3s 容器叢集控制平面運作資訊（如圖 12 所示）。

圖 12、透過 kubectl 指令確認 K3s 容器叢集和節點主機運作情況



部署 Linux 容器和應用程式

首先，部署 Linux 容器和應用程式，在本文實作環境中，將採用微軟的 azure-vote-front容器映像檔為範例，這個展示用的容器映像檔存放在微軟公開的 ACR（Azure Container Registry）當中，並且在部署的 linux-sample.yaml當中，預設已經指定 nodeSelector 為 linux，也就是將會部署在 Linux 節點主機當中。

這個投票範例應用程式，是由 .NET 撰寫的前後端而成的應用程式，其中後端採用的是 Key-Value 儲存的 Redis 。管理人員要執行部署作業也很簡單，只要在 PowerShell 指令視窗中，執行「kubectl apply -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/linux-sample.yaml」指令，系統將會解析 linux-sample.yaml 檔案內容，並且執行部署作業和建立定義的 Kubernetes 物件，此時將會看到系統建立「azure-vote-back」和「azure-vote-front」容器叢集服務的資訊。

接著執行「kubectl get pods -o wide」指令，確認部署的容器是否已經為運作狀態，請查看 STATUS 欄位狀態，倘若狀態為 ContainerCreating 時，請稍等幾分鐘待運作狀態轉換為 Running 時，即表示容器已經順利啟動並正常運作中。

由於此範例投票程式，在 linux-sample.yaml 檔案中，已經定義為 azure-vote-front 前端容器，部署 Kubernetes LoadBalancer 負載平衡服務，所以管理人員可以透過「kubectl get services」指令，確認服務 IP 位址是否已經套用生效，請查看 EXTERNAL-IP 欄位，這個欄位一開始會顯示為 Pending，稍待一小段時間後便會顯示服務 IP 位址，本文實作環境為 192.168.0.4（如圖 13 所示）。

圖 13、部署 Linux 投票範例容器和應用程式

在本文實作環境中，Linux 投票範例應用程式的服務 IP 位址為 192.168.0.4，請開啟瀏覽器並鍵入 IP 位址，即可連線至 Linux 投票範例應用程式頁面（如圖 14 所示），可以點選 Cats 或 Dogs 鈕進行投票，或按下 Reset 鈕將投票結果進行重置。

圖 14、連線至 Linux 投票範例應用程式頁面

值得注意的是，倘若先前部署 K3s 容器叢集時，在 aksedge-config.json 組態設定檔案內容中，並未指定 -ServiceIPRangeSize 參數的服務 IP 位址範圍時，那麼管理人員必須採用「Get-AksEdgeNodeAddr -NodeType Linux」指令，查詢 Linux 節點主機的 IP 位址，搭配容器的 Listen Port 才能順利連線至 Linux 投票範例應用程式頁面。

在本文實作環境中，查詢後得知 Linux 節點主機的 IP 位址為「192.168.0.2」，而前端容器 Linux 投票範例應用程式的通訊埠為 30241，所以開啟瀏覽器並鍵入 IP 位址加通訊埠「https://192.168.0.2:30241」（如圖 15 所示），便能順利連線 Linux 投票範例應用程式頁面。

圖 15、透過 Linux 節點主機連線 Linux 投票範例應用程式頁面

測試 Linux 節點主機正常運作，並可以順利部署 Linux 容器及應用程式後，即可執行「kubectl delete -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/linux-sample.yaml」指令，將剛才所部署的 Linux 投票範例應用程式，以及部署的 Kubernetes 服務及負載平衡機制移除。



部署 Windows 容器和應用程式

在部署 Windows 容器和應用程式方面，將會部署 ASP .NET 範例應用程式，在部署的 win-sample.yaml當中，預設已經指定 nodeSelector 為 windows，表示屆時 Windows 容器將會部署在 Windows 節點主機中。

請在 PowerShell 指令視窗中，執行「kubectl apply -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/win-sample.yaml」指令，系統將會解析 win-sample.yaml 檔案內容，並且執行部署作業和建立定義的 Kubernetes 物件，此時將會看到系統建立名稱為「sample」的容器叢集服務資訊。

執行「kubectl get pods -o wide」指令，確認部署的 Windows 容器是否已經為運作狀態，請查看 STATUS 欄位狀態，倘若狀態為 ContainerCreating 時，請稍等幾分鐘待運作狀態轉換為 Running 時，即表示容器已經順利啟動並正常運作中。值得注意的是，由於 ASP .NET 容器映像檔空間較大，必須視主機的網際網路連線頻寬而定，所以 Windows 容器必須要一些時間才能轉換為運作中的狀態，管理人員可以在指令結尾加上「--watch」參數即時觀察容器運作狀態，本文實作環境 Windows 容器下載到順利運作共花費 9 分 45 秒。

確認 Windows 容器順利運作後，執行「kubectl get services」指令，可以看到由於範例 Windows 容器的 Kubernetes 服務類型為「NodePort」，所以系統並不會透過服務 IP 位址進行派發的動作，請執行「Get-AksEdgeNodeAddr -NodeType Windows」指令，查詢 Windows 節點主機的 IP 位址，搭配容器的 Listen Port 才能順利連線至 Windows 範例應用程式頁面（如圖 16 所示）。

圖 16、部署 Windows 容器和範例應用程式

在本文實作環境中，可知 Windows 節點主機的 IP 位址為「192.168.0.3」，而 Windows 容器範例應用程式的通訊埠為 30082，所以開啟瀏覽器並鍵入 IP 位址加通訊埠「https://192.168.0.3:30082」，便能順利連線 Windows 範例應用程式頁面（如圖 17 所示）。

圖 17、查看 Windows 範例應用程式頁面

同樣的，測試 Windows 節點主機正常運作，並可以順利部署 Windows 容器及應用程式後，即可執行「kubectl delete -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/win-sample.yaml」指令，將剛才所部署的 Windows 容器範例應用程式，以及部署的 Kubernetes 服務及 NodePort 機制移除。



查看容器資源耗用情況

當 Linux 和 Windows 節點主機上，運作數量越來越多的容器時，管理人員可以透過部署 Metrics-Server 容器，快速查詢所有容器的資源耗用情況。

請執行「kubectl apply -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/metrics-server.yaml」指令，系統將會解析 metrics-server.yaml 檔案內容，並且執行部署作業和建立定義的 Kubernetes 物件，此時將會看到系統建立名稱為「metrics-server」的系統容器服務資訊。

執行「kubectl get pods -A」指令，查看系統中所有容器包括系統用容器，接著執行「kubectl top pods -A」指令，即可條列出所有容器的工作負載和資源耗用情況（如圖 18 所示）。

圖 18、查看系統中所有容器的工作負載和資源耗用情況

倘若，需要移除 Metrics-Server 容器時，請執行「kubectl delete -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/metrics-server.yaml」指令，即可將剛才所部署的 Metrics-Server 容器，以及部署的 Kubernetes 服務及相關物件移除。



移除 K3s 容器叢集和節點主機

至此，管理人員已經初步體驗部署 K3s 容器叢集，Linux 和 Windows 節點主機，以及 Linux 和 Windows 範例容器和應用程式。倘若，希望移除 K3s 容器叢集測試環境，改為部署 K8s 容器叢集之前，請先依照順序將相關工作負載和節點主機移除，最後才移除容器叢集。

首先，倘若仍有容器和應用程式運作時，請使用「kubectl delete -f」指令，搭配部署時使用的 YAML 檔，將已經部署運作的容器和應用程式進行移除，使用「kubectl get pods -o wide」指令，確認目前已經沒有容器運作中，使用「kubectl get pods -A -o wide」指令，可以看到僅剩系統用途的容器運作中（如圖 19 所示）。

圖 19、移除目前系統中運作的容器工作負載

執行移除節點主機的動作，在本文實作環境中，雖然同時擁有 Linux 和 Windows 節點主機，但是 K3s 容器叢集的控制平台，是由 Linux 節點主機同時擔任，所以僅能先移除 Windows 節點主機，或是同時移除 Linux 和 Windows 節點主機，不能僅移除 Linux 節點主機。

執行「kubectl get nodes」指令，可以看到目前有 Linux 和 Windows 節點主機正在運作中，執行「Remove-AksEdgeNode -NodeType Windows」指令，僅先移除 Windows 節點主機，待節點主機移除動作完成後，再次執行「kubectl get nodes」指令，可以看到目前系統中僅剩 Linux 節點主機（如圖 20 所示）。

圖 20、僅先執行移除 Windows 節點主機的動作

現在，管理人員可以放心執行「Remove-AksEdgeDeployment」指令，將包含 Kubernetes 叢集控制平面的 Linux 節點主機移除，值得注意的是，由於移除包含控制平面的 Linux 節點主機後，系統會同時將相關組態設定移除，舉例來說，剛才建立 K3s 容器叢集並部署 Linux 和 Windows 節點主機時，建立的 NAT Object 以及 Internal Only 的 vSwitch 虛擬交換器，也會同步進行移除的動作（如圖 21 所示）。

圖 21、刪除包含 Kubernetes 叢集控制平面的 Linux 節點主機

最後，至新增移除程式視窗中，將一開始安裝的「AKS Edge Essentials – K3s」應用程式移除，並且重新啟動主機後，即可安裝另一個類型的容器叢集，例如，K8s 。





結語

透過本文的深入剖析和實作演練後，管理人員除了理解 AKS Edge Essentials 運作架構和特色功能之外，也實作演練建構 K3s 容器叢集，部署 Linux 和 Windows 節點主機，並部署 Linux 和 Windows 容器及應用程式，讓中小企業或組織的 IT 管理人員，能夠用最小的硬體資源即可建構和部署容器環境。
↧

Networking Architecture | Nutanix

October 29, 2023, 6:28 pm
$
0
0

 



簡介

在 Nutanix 運作架構中，AHV 主機便是利用 OVS (Open vSwitch)，來達成連接和管理 VM 虛擬主機的虛擬網路部份。OVS 虛擬網路可以透 Prism 或 ACLI 進行組態設定。下列為 OVS 虛擬網路機制運作架構示意圖：
圖片來源： AHV Architecture | The Nutanix Bible




 

OVS 運作元件

針對上述的 OVS 架構圖中，可以看到幾個重要的運作元件或術語。



OVS (Open vSwitch)

OVS (Open vSwitch)是結合 Linux 核心實作的開源軟體交換器，並可以在伺服器虛擬化環境中運作。在預設情況下，OVS 虛擬網路交換器的運作機制，類似於 Layer 2 功能的虛擬網路交換器 (MAC Address)。 OVS 支援許多網路交換器主流功能，例如，VLAN Tagging、LACP (Link Aggregation Control Protocol)、Port Mirroring、QoS (Quality of Service)……等，每台 AHV Host 會運作一個 OVS 執行個體，多個 OVS 整合之後，將會組成一個邏輯上的虛擬網路交換器，以便後續管理和組護虛擬網路環境。



Bridge

預設情況下，AHV Host 會建立一個名稱為 virbr0的 Native Linux Bridge，以及一個名稱為 br0的 OVS Bridge 。其中，virbr0 負責 CVM 和 AHV Host 之間 Management 和 Storage 網路流量，而其它 Storage、AHV Host、VMs……等網路流量便是由 br0 負責。



Port

Port 是 Bridge 中的邏輯結構，並且負責處理 AHV Host、VM 虛擬主機、實體網路卡的連接作業。其中，br0 負責連接和存取 AHV Host，Tap Ports 則是 VM 虛擬主機虛擬網卡連接存取使用，VXLAN Port 用於 Acropolis 提供 IP 位址管理功能，Bonded Ports則是提供 NIC Teaming 機制，以便將 AHV Host 的多個實體網路卡整合的機制。



Bond

預設情況下，系統會自動建立 br0-up的 Bonding 介面，一般為了方便識別通常會重新命名為 bond0。此外，Bond 建立後，支援多種網路流量負載平衡演算法，例如，Active-Backup、Balance-SLB、Balance-TCP等，當然 LACP 也支援但必須配合實體網路交換器的設定。值得注意的是，在安裝期間未指定使用的負載平衡演算法 (bond_mode) 時，預設將會採用 Active-Backup演算法。



Service Chain

預設情況下，所有的網路流量都會轉送到 AHV Service Chaining 的 Packet Processor。目前，有兩種 Service Chaing 運作模式分別是 Inline和 Tap，其中 Inline Packet Processor當網路封包經過 OVS 時會進行攔截，並且可以修改/允許/拒絕網路封包，常見的應用類型為防火牆或網路負戴平衡。而 Tap Packet Processor則是，在網路封包進入時會檢查及讀取封包內容，常用的應用類型為 IDS/IPS/網路監控。

圖片來源： AHV Architecture | The Nutanix Bible

事實上，所有類型的 Service Chain，都是在 Flow - Microsegmentation 規則之後，並且當網路封包離開 OVS 之前完成，在網路堆疊中是在 br.nf 內完成這段處理。

圖片來源： AHV Architecture | The Nutanix Bible


↧
Search

The term kubectl is not recognized as the name of a cmdlet | AKS

November 1, 2023, 3:00 pm
$
0
0

 



Question: The term kubectl is not recognized as the name of a cmdlet

在 Windows Server 2022 建立 AKSEE (Azure Kubernetes Service Edge Essentials)環境後，嘗試執行 kubectl get nodes -o wide指令時，系統卻顯示 The term kubectl is not recognized as the name of a cmdlet訊息，表示找不到 kubectl 指令？






Answer:

簡單來說，kubectl 指令沒有加入到系統環境變數中，或因為什麼緣故被拿掉後沒有加回去。所以，只要把 kubectl 指令路徑加回系統環境變數中即可。

方法 1，直接使用 PowerShell 指令的方式，將 kubectl 指令路徑加回系統環境變數中。首先，執行「$Env:Path += ";C:\Program Files\AksEdge\kubectl\"」指令，接著執行「Get-ChildItem Env: | Where-Object {$_.name -eq "Path"} | Format-Table -Wrap」指令進行確認。


方法 2，使用 GUI 圖形操作的方式，將 kubectl 指令路徑加回系統環境變數中。


現在，應該可以順利執行 kubectl get nodes -o wide 指令。


↧
↧

Modern Web Conference 2023 | 站長開講

November 2, 2023, 8:52 am
$
0
0

 



活動簡介

這個世界曾經用石器形塑、曾經用銅器、鐵器形塑，然後蒸氣、電力加速了世界的變貌，而今我們站在一個新世界，軟體技術鑄造的世界。以 ChatGPT 之名的生成式 AI 撼動了世界的支柱，身為技術開發者，在混沌的無限可能中，有讚歎者、有疑懼者、有冒險者、有獲利者。

人是萬物的尺度，新的技術給了開發者如魔法詠咒般的強大力量時，開發者終究要回答的是，我們要如何應用所有的技術打造出一個更好的世界？

這個回答也許會很長、也許要會很久，MWC將匯集台灣技術開發者的能量一起思考，也邀請你一起加入。





活動資訊

日期：   2023 年 11 月 08 日 (三) ~ 11 月 09 日 (四)
時間：   09:00 - 17:00
地點：   POPOP Taipei 瓶蓋工廠台北製造所
報名：   報名購票
議程：   大會議程表
講者：   講者陣容
共筆：   Modern Web Conference 2023 共筆








實戰工作坊

在本次大會實戰工作坊中，站長規劃 90 分鐘的「GitOps | 以 A/B 測試為例」實戰工作坊，顧名思義參與的朋友們，你可以在短短 90 分鐘之內實作體驗，以 GitHub 中 Git Webhook 機制，搭配 Ansible Playbook 建立 GitOps 自動化機制，並帶領與會人員實際部署 Nginx 容器，以及 A/B Testing 環境。

你可能會說，我還不熟悉也不太寫 Ansible Playbook，沒問題! 在實戰工作坊中，也會跟大家說明和實際展示，如何透過在今年 RedHat Summit 2023 大會上，最新發佈的 Ansible Lightspeed with IBM watsonx Code Assistant 技術預覽版，簡單來說就是透過生成式 AI 機制，幫助你撰寫  Ansible Playbook。

參與站長體驗工作坊的朋友，請參考下列事項並預先準備一下，否則可能會造成體驗不佳的情況： 😏






↧

Storage I/O Path | AHV Host

November 7, 2023, 2:01 am
$
0
0

 



簡介

無論是 VMware ESXi 或 Microsoft Hyper-V 虛擬化平台，都是採用「傳統儲存堆疊」(Traditional Storage Stack)，為上層 VM 虛擬主機工作負載提供儲存資源和儲存效能。然而，Nutanix 作法則不同，是把底層所有儲存裝置都當成「原始 SCSI 區塊裝置」 (Raw SCSI Block Devices)，提供上層 VM 虛擬主機工作負載存資源和儲存效能，這種作法可以提供較輕量的「儲存 I/O 路徑」(Storage I/O Path) 及最佳化。

事實上，管理人員無須手動進行組態設定，因為每台 AHV 主機在預設情況下，都會執行一個「iSCSI 重新導向器」(iSCSI Redirector)，它的功能是透過 NOP 指令定期檢查整個叢集中 Stargate 的運作情況。





iSCSI Multi-pathing 機制

iSCSI Multi-pathing - Normal State

原則上，QEMU 會組態設定 iSCSI Redirector 導向運作情況良好的 Stargate (通常會是本機 Stargate，也就是 Local Stargate)，並建議採用 Controller 的類型是「virtio-scsi」，其實就是下圖中「綠色實線連到 Local Stargate」的部份。

值得注意的是，採用 virtio-scsi 儲存控制器後，採用的是新式的 Linux 發行版本，原則上都支援 virtio 控制器，倘若採用的是 Windows 作業系統時，則必須要安裝 Nutanix Guest Tools，以便提供 virtio 控制器驅動程式給 Windows。(你應該不會想要採用 IDE 儲存控制器吧？)

圖片來源： How Nutanix AHV Works | Book of AHV | The Nutanix Bible



iSCSI Multi-pathing - Local CVM Down

倘若，AHV 主機內的 Stargate 發生故障時，例如，CVM 故障導致無法回應 NOP OUT command 時，那麼 iSCSI Redirector 將會把本機 Stargate 標記為「不健康」(Unhealthy) 狀態， 所以當 QEMU 執行 iSCSI Login Retries 的動作時，系統便會將 iSCSI Login 重新導向至另一個健康狀態的遠端 Stargate (Remote Stargate)。

圖片來源： How Nutanix AHV Works | Book of AHV | The Nutanix Bible


 

iSCSI Multi-pathing - Local CVM Back Up

當 CVM 恢復運作後，由於 Stargate 也同步恢復並開始回應 NOP OUT command 時，那麼系統將會暫停並刪除所有連線至遠端的 iSCSI Sessions，並且 QEMU 會再次執行 iSCSI Login Retries 的動作，並重新導向至 Local Stargate。

圖片來源： How Nutanix AHV Works | Book of AHV | The Nutanix Bible




↧

.Net Conf 2023 Taiwan | 站長開講

November 12, 2023, 6:00 pm
$
0
0

 



活動簡介

什麼是 .NET Conf？ .NET Conf 是 .NET 社群的年度重要活動，微軟 .NET 團隊以及 .NET Foundation 將於 11 月份舉辦 .NET Conf 線上活動，連續三天現場直播 .NET 相關議程，介紹最新技術與其應用，.NET 8.0 也即將在 .NET Conf 發布！為了讓台灣開發人員也能彼此交流 .NET 技術與心得，台中最大微軟技術社群 STUDY4與 Build School將於 12/09 - 10 舉辦為期兩天的 .NET Conf Local Event，邀請台灣開發人員共襄盛舉。

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





活動資訊

日期：   2023 年 12 月 09 日 (六) ~ 12 月 10 日 (日)
時間：   09:10 - 17:20
地點：   台大社會科學院
報名：   報名購票
議程：   大會議程表
講者：   講者陣容
共筆：   .Net Conf 2023 Taiwan 共筆





站長議程

在本次大會中，Weithenn 將會說明在現今物聯網 (IoT) 和邊緣運算 (Edge Computing) 應用環境中，通常都是使用非常微型的硬體裝置，舉例來說，硬體裝置的記憶體可能就只有 8GB 或 16GB。此外，企業或組織的管理人員，雖然能夠針對硬體資源低的邊緣裝置運作單一應用的容器，但是必須自行打造和管理容器平台、版本、更新、維護……等作業，一旦數量過多時便會造成企業或組織管理人員的嚴重負擔。

在 Weithenn 本次「AKSEE (Azure Kubernetes Service Edge Essential) 超輕量容器平台」議程中，將為與會人員簡介說明，如何部署超輕量級的 AKSEE (Azure Kubernetes Service Edge Essential) 容器平台，以便快速部署和應用於物聯網和邊緣運算環境中，並實際展示和實作演練，如何選擇整合 K8s 或 K3s 的 Kubernetes 平台，以及實際部署雲原生的 Linux 容器和 Windows 容器。






↧

DevFest Taipei 2023 | 站長開講

November 19, 2023, 12:24 am
$
0
0

 



活動簡介

DevFest 是由 Google 開發者社群 (GDG)主辦的年度技術大會。DevFest 是全球性的活動，每年在全球各地舉辦，涵蓋的技術領域廣泛，包括 Android、Web、雲端、機器學習等。DevFest 的目的在於促進開發者交流和分享，幫助開發者學習新技術、建立人脈，並了解 Google 最新的開發者工具和技術。

DevFest 是開發者社群中一個重要的活動。它為開發者提供了一個學習新技能、與其他開發者交流和建立社群的機會。活動通常包括演講、工作坊、互動活動和其他形式的學習。DevFest 也提供與 Google 工程師和其他開發者交流的機會。以下是 DevFest 的一些主要特點：
  • 全球性：DevFest 在全球各地舉辦，為開發者提供了一個與世界各地的開發者交流的機會。
  • 多元化：DevFest 的內容涵蓋了各種技術主題，為開發者提供了一個學習新技能的機會。
  • 社群驅動：DevFest 由 GDG 社群主辦，反映了社群的需求和興趣。





活動資訊

日期：   2023 年 12 月 16 日 (六)
時間：   08:00 - 17:00
地點：   國立臺灣大學共同教學館
報名：   報名購票
議程：   大會議程表
講者：   講者陣容





站長開講

在本次大會中，站長的議程為「App Modernization - GKE 容器平台 101」，議程中除了簡介 GKE (Google Kubernetes Engine) 容器平台之外，將會展示在 GCP 中如何建立 GKE  叢集，以及部署容器和應用程式，讓與會人員能夠快速理解，雲端原生及現代化應用程式的生命週期和部署流程。


↧
↧

部署 vCHA 機制因應災難，可容錯移轉營運不中斷 | 網管人 214 期

November 19, 2023, 3:08 am
$
0
0

 



網管人雜誌

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





本文目錄






前言

在 VMware vSphere 虛擬化架構中，vCenter Server 在虛擬化架構中的重要性不言而喻，雖然 vCenter Server 發生災難事件時，ESXi 主機上運作的 VM 虛擬主機或容器等工作負載，並不會因此受到影響，然而管理人員將無法進行其它管理任務，例如，無法線上遷移 VM 虛擬主機、無法再部署 VM 虛擬主機或容器……等。

過去，vCenter Server 高可用性解決方案中，最簡單的方式為採用 VM 虛擬主機的方式，部署 vCenter Server 管理平台，並且運作在獨立且啟用 vSphere HA 的 vSphere 管理叢集，一旦底層 ESXi 虛擬化主機發生災難事件時，便能依靠 vSphere HA 高可用性機制，將 vCenter Server 主機重新啟動，繼續運作在其它仍然存活的 ESXi 虛擬化主機上。

現在，管理人員可以透過建構及部署 vCHA（vCenter High Availability）機制，搭配原有的 vSphere HA 高可用機制，讓 vCenter Server 的整體 SLA 能夠更加提升。在 vCHA 高可用性機制運作架構中，將會由「Active、Passive、Witness」這 3 種不同角色所組成，當 vCHA 高可用性機制建構完成後，便會形成「Active-Passive」的容錯移轉機制。下列，為不同角色成員主機負責的工作任務及功能：
  • Active Node： 使用 vCenter Server 對外服務 IP 位址，並啟用 vCenter Server 系統服務，除了透過 HA Network 同步資料至 Passive Node 之外，也同時和 Witness Node 保持通訊。
  • Passive Node： 運作 vCenter Server 備援主機，透過 HA Network 不斷接收 Active Node 主機，所傳送過來的變更內容和狀態，當 Active Node 發生災難事件時，自動接手 vCenter Server IP 位址，並啟動 vCenter Server 系統服務。
  • Witness Node： 擔任 vCHA 高可用性架構中仲裁者角色，一旦 Active Node 或 Passive Node 主機，發生網路分區或網路中斷隔離事件時，能夠有效避免發生「腦裂」（Split-Brain）的情況。





vCHA 部署模式

建構及部署 vCHA 高可用性機制時，管理人員可以採用「自動」（Automatic）或「手動」（Manual）模式。這兩種部署模式最大的差別在於，採用「自動」模式部署 vCHA 高可用性機制時，系統將會透過 vCenter HA 精靈互動的方式，自動建立和組態設定 Passive Node 及 Witness Node 主機。

採用「手動」模式時，則必須由管理人員手動將 Active Node 主機，進行複製的動作後再組態設定 Passive Node 及 Witness Node 主機。



vCHA 軟體需求

在建構和部署 vCHA 高可用性機制前，請管理人員確保採用的 vCenter Server 和 ESXi 版本，支援 vCHA 高可用性機制並符合最低硬體資源需求。
  • ESXi 虛擬化平台： 至少為 ESXi 6.0 或更新版本，並且 vSphere 叢集建議至少有 3 台 ESXi 成員主機，以便每個 vCHA 角色運作在不同 ESXi 成員主機以確保高可用性，並建議為 vSphere 叢集啟用 vSphere DRS 負載平衡機制。
  • vCenter Server： 至少為 vCenter Server 6.5 或後續版本，為了滿足 vCHA 高可用性機制的基本 RTO 需求，部署的 vCSA 規模大小至少要採用「Small」或更大規模，支援部署在「VMFS、NFS、vSAN Datastore」等儲存資源中。
  • 軟體授權： 建構 vCHA 高可用性機制，雖然運作 3 台不同角色的 vCenter Server，但僅需要「1 套」vCenter Server Standard 軟體授權即可。值得注意的是，採用 vCenter Server Foundation 或 vCenter Server Essentials 版本，不支援建構 vCHA 高可用性機制。



vCHA 網路需求

在 vCHA 高可用性運作架構中，至少應規劃兩種不同用途的網路環境，分別是「管理網路」（Management Network）和「vCenter 高可用性網路」（vCenter HA Network）。

首先，管理網路除了管理用途之外，平時為 Active Node 主機使用 vCenter Server IP 位址，災難事件發生時，Passive Node 接手後容錯移轉的 vCenter Server IP 位址。

在 vCenter 高可用性網路的部份，主要用途為資料庫和組態設定同步作業，以及主機互相偵測是否存活的「心跳」（Heartbeats），舉例來說，當 vCHA 高可用性機制建構完成後，Active Node 和 Passive Node 主機之間，將會不斷同步 PostgreSQL 資料庫內容和運作狀態等資訊。

值得注意的是，根據 VMware 最佳建議作法，vCenter 高可用性網路必須小於「10 ms」延遲時間的網路環境。倘若，Active Node 和 Passive Node 主機之間，網路環境無法達到資料同步的基本要求時，將會導致兩台主機之間的 PostgreSQL 資料庫內容不一致，並且 vCHA 高可用性機制會退化為「非同步」狀態，導致出現非預期的錯誤或容錯移轉失敗的情況（如圖 1 所示）。

圖 1、vCHA 高可用性網路必須小於 10 ms 延遲時間網路環境示意圖
圖片來源： VMware vSphere Blog - vCenter High Availability Deep Dive





實戰演練 - vCHA 高可用性機制

理解 vCHA 高可用性機制基礎架構和最佳作法後，便開始進行 vCHA 高可用性機制的實作演練。值得注意的是，雖然管理人員可以在任何時間啟用 vCHA 高可用性機制，然而根據 VMware 最佳建議作法，應該在離峰時間再啟用 vCHA 高可用性機制比較妥當。

主要原因在於，當啟用 vCHA 高可用性機制時，系統會立即執行 Active Node 和 Passive Node 兩台主機之間，PostgreSQL 資料庫同步作業，倘若 Active Node 處於工作負載高峰期的話，有可能導致 Passive Node 的 PostgreSQL 資料庫無法即時同步完成，導致屆時 vCHA 高可用性機制發生非預期的錯誤。



部署 vCenter Server 管理平台

根據 VMware 最佳建議作法，管理人員應該為 vCenter Server 高可用性機制，準備 3 台 ESXi 虛擬化平台，分別部署 vCenter Server 至其中 1 台 ESXi 虛擬化平台，另外 2 台 ESXi 虛擬化平台，屆時則分別運作備援角色的 Passive Node 主機，以及見證角色的 Witness Node 主機（如圖 2 所示）。

圖 2、vCHA 高可用性運作架構示意圖
圖片來源： vCenter HA架構概觀 | VMware Docs（vmware.com）

此外，在部署 vCenter Server 管理平台時，至少要採用「Small」或更大的部署規模大小，否則屆時將無法順利啟用 vCHA 高可用性機制。在最新的 vCenter Server 8 U1 版本，和過去舊版的 vCenter Server 相較之下需要更多的硬體資源，舉例來說，Small 部署規模大小，需要 4 vCPUs、21GB vMemory、694GB vStorage 硬體資源才行（如圖 3 所示）。

圖 3、vCenter Server 至少採用 Small Size 才能啟用 vCHA 高可用性機制

值得注意的是，部署 vCenter Server 管理平台時，在 vCenter Server Configuration 頁面中，請在 SSH Access 欄位，將預設值 Deactivated 調整為 Activated，組態設定 vCenter Server 啟用 SSH Access 功能，確保 vCHA 高可用性機制屆時能順利啟用。

倘若，管理人員在部署 vCenter Server 管理平台時，忘記為 vCenter Server 啟用 SSH Access 功能的話，請在啟用 vCHA 高可用性機制之前，登入 vCenter Server 管理介面（Port 5480），依序點選「Access > Access Settings > Edit」，啟用「Activate SSH Login」項目，進行啟用 SSH Access 功能的動作（如圖 4 所示）。

圖 4、確保 vCenter Server 啟用 SSH Login 功能



新增 vCenter HA Network 虛擬網路環境

在本文實作環境中，規劃 vCHA 管理用途網路的網段為「10.10.75.0/24」，而 vCHA 高可用性用途網路的網段為「192.168.75.0/24」，同時組態設定這兩個不同的虛擬網路環境，分別採用不同的 vSwitch 虛擬網路交換器，以及不同的實體網路卡，以避免 SPOF 單點失敗的情況發生。

登入 vCenter Server 管理介面後，依序點選「ESXi Host > Configure > Networking > Virtual Switches > Add Networking > Virtual Machine Port Group for a Standard Switch > New standard switch」，選擇專屬用於 vCenter 高可用性網路的實體網路卡，本文實作環境為「vmnic1」。

在 Connection Settings 視窗中，於 Network Label 欄位填入名稱「vCHA Heartbeat」，這個新增的 vSwitch 虛擬網路交換器及 Port Group，便是負責 vCHA 架構中高可用性用途的虛擬網路（如圖 5 所示）。由於，採用的是 vSS 虛擬網路交換器，因此請依序為 3 台 ESXi 主機新增 vCHA Heartbeat 虛擬網路。

圖 5、新增專用於 vCHA 架構中高可用性用途的虛擬網路



啟用 vCHA 高可用性機制

前置作業準備完畢後，請在 vCenter Server 管理頁面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Set Up vCenter HA」項目，準備正式啟用 vCHA 高可用性機制（如圖 6 所示）。系統也在下方提醒管理人員，請預先建立 vCenter HA Network，並且準備 Heartbeat 用途的固定 IP 位址，這些前置作業已經完成，管理人員可以放心按下 Set Up vCenter HA 鈕。

圖 6、準備部署並啟用 vCHA 高可用性機制

在 1. Resource Settings 頁面中，請按下「BROWSE」選擇剛才新增專用於 vCenter 高可用性虛擬網路的「vCHA Heartbeat」，並勾選「Automatically create clones for Passive and Witness nodes」項目。

接著，分別為擔任備援角色的 Passive Node 主機，以及見證角色的 Witness Node 主機選擇運作環境，請點選 Passive Node 區塊中的 Edit，選擇將備援主機部署至「vcha02.lab.weithenn.org」虛擬化平台，而 Witness Node則部署至「vcha03.lab.weithenn.org」虛擬化平台。值得注意的是，Witness Node 在 vNetwork 虛擬網路的部分，只要選擇 vCHA HA Network 即可無須管理網路。

在本文實作環境中，vCHA 運作架構的 3 台 VM 虛擬主機，都統一存放在 vSAN 超融合儲存資源當中，倘若企業或組織因為預算的關係，無法建立集中式的儲存資源時，即便是採用 ESXi 本機儲存資源，也同樣支援啟用和運作 vCHA 高可用性機制（如圖 7 所示）。

圖 7、組態設定 vCHA 高可用性機制，管理網路和高可用性網路及儲存資源

在 2. IP Settings 頁面中，管理人員必須組態設定 Active Node、Passive Node、Witness Node，這 3 台主機在 vCHA 高可用性網路中使用的 IP 位址，本文實作環境依序為「192.168.75.31、192.168.75.32、192.168.75.33」（如圖 8 所示）。

圖 8、組態設定 vCHA 同步和互相偵測的專屬網路 IP 位址

一旦完成組態設定作業後，系統將會自動執行複製和建立的工作任務，分別在剛才組態設定的 ESXi 主機當中，部署 Passive Node 及 Witness Node 主機，組態設定 vCenter HA Cluster 之後，vCHA 高可用性機制便準備完畢，運作模式將會呈現「Enabled」且運作狀態為「Healthy」。

值得注意的是，剛部署好 vCHA 高可用性機制時，會看到「PostgreSQL replication is not in progress」錯誤訊息，並且運作狀態為「Degraded」，這是因為 Active Node 和 Passive Node 主機之間，才剛開始執行 PostgreSQL 資料庫的複寫作業所導致，只要稍待幾分鐘等 PostgreSQL 複寫作業執行完畢後即可（如圖 9 所示）。

圖 9、剛開始執行 PostgreSQL 資料庫的複寫作業所導致的錯誤訊息

PostgreSQL 資料庫完成後，可以看到 VM 虛擬主機名稱「vCenter8」，目前擔任 Active Node 角色 IP 位址為「192.168.75.31」，並且這台 vCenter8 虛擬主機同時使用「10.10.75.30」IP 位址，也就是運作環境中唯一的 vCenter Server IP 位址，而「vCenter8-Passive」虛擬主機，則是擔任 Passive Node 角色 IP 位址為「192.168.75.32」，「vCenter8-Witness」虛擬主機，負責 Witness Node 角色 IP 位址為「192.168.75.33」（如圖 10 所示）。

圖 10、順利建構和啟用 vCHA 高可用性機制



手動觸發 vCHA 容錯移轉機制

成功啟用 vCHA 高可用性機制後，管理人員可以「手動」測試 vCHA 容錯移轉機制，測試 Active Node 和 Passive Node 角色進行切換，確保擔任備援角色的主機能夠順利接手並繼續運作，以便屆時災難真的發生時能夠順利進行容錯移轉。

事實上，在 vCHA 高可用性運作架構中，針對不同的資料屬性採用不同的同步方式，確保 Active Node 和 Passive Node 主機運作狀態一致。首先，在 vCenter Server 資料庫的部分，採用內嵌的「PostgreSQL 資料庫」，並直接透過 PostgreSQL 資料庫原生「複寫」（Replication）機制，確保 Active Node 及 Passive Node 主機資料庫同步和內容一致，當災難事件發生時，便不會有資料遺失的情況發生（RPO=0）。

至於其它 vCenter Server 組態設定檔內容的部分，則使用 Linux 作業系統中原生的「Rsync」複寫機制，即可確保 Active Node 及 Passive Node 主機組態設定檔內容一致，當災難事件發生時，便不會有組態設定檔內容不一致的問題。

請在 vCenter Server 管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA」項目，然後點選「Initiate Failover」鈕，在彈出的 Initiate vCenter HA failover 視窗中，VMware 建議除非有特殊情況，否則請勿勾選 Force the failover to start immediately without waiting 選項。

主要原因在於，強制且立即執行容錯移轉的動作，很有可能造成 Active Node 和 Passive Node 之間資料尚未同步完成，卻強制執行切換角色和接手 vCenter 服務動作，導致資料遺失或發生非預期的錯誤。確認進行容錯移轉的動作後，請按下 INITIATE FAILOVER 鈕即可（如圖 11 所示）。

圖 11、準備手動執行 vCHA 容錯移轉的動作

開始執行 vCHA 容錯移轉動作後，由於 Passive Node 必須接手 vCenter Server 管理介面，以及相關的系統服務，例如，Appliance Management Service、Content Library Service…… 等，所以將會有短暫幾分鐘停止服務的空窗期，管理人員可以嘗試持續偵測 vCenter Server 的 IP 位址，例如，10.10.75.30 。在本文實作環境中，容錯移轉動作執行之後，大約掉了 10-13 個 ping ICMP 網路封包後，便能再次 ping 到 vCenter Server 的 IP 位址。

經過幾分鐘的容錯移轉程序後，管理人員便能重新連接至 vCenter Server 管理介面，可以看到原本的「vCenter8」虛擬主機，目前改為擔任 Passive Node角色 IP 位址為「192.168.75.31」，而「vCenter8-Passive」虛擬主機，改為擔任 Active Node 角色 IP 位址為「192.168.75.32」，並且這台 vCenter8-Passive 虛擬主機，同時接手使用「10.10.75.30」的 vCenter Server IP 位址，至於 Witness Node 角色主機和 IP 位址則維持不變（如圖 12 所示）。

圖 12、原本的 Passive Node 角色主機順利接手 Active Node 角色和 vCenter Server IP 位址



災難演練 vCHA 容錯移轉機制

目前，vCenter8-Passive 虛擬主機，擔任 Active Node 角色，並運作在「vcha02.lab.weithenn.org」的 ESXi 虛擬化平台上，直接將 ESXi 虛擬化平台關機，實際模擬災難事件發生並影響到 Active Node 角色，再次確認 vCHA 高可用性機制能否「自動」進行容錯移轉作業。

同樣的，當災難事件發生時，Passive Node 將會自動接手 vCenter Server 管理介面的 IP 位址，並且啟動相關的系統服務，因此會有幾分鐘無法服務的空窗期。

經過幾分鐘的容錯移轉程序後，管理人員便能重新連接至 vCenter Server 管理介面，可以看到「vCenter8」虛擬主機，重新擔任 Active Node角色 IP 位址為「192.168.75.31」，並接手「10.10.75.30」的 vCenter Server IP 位址，而「vCenter8-Passive」虛擬主機，由於套用 VM/Host Rule，所以並不會在其它台 ESXi 虛擬化平台上重新開機，至於 Witness Node 角色主機和 IP 位址則維持不變（如圖 13 所示）。

圖 13、實際模擬 Active Node 底層 ESXi 虛擬化平台發生災難事件





vCHA 高可用性機制的維運管理

確保不同角色運作在不同台 ESXi 主機

至此，已經順利建構及部署 vCHA 高可用性機制，並且成功驗證 vCHA 容錯移轉機制，能夠手動和自動進行切換。值得注意的是，根據 Vmware 最佳建議作法，在企業和組織的正式營運環境中，應搭配啟用 vSphere Cluster DRS 規則，確保擔任 Active、Passive、Witness 角色的這 3 台 VM 虛擬主機，能夠各自分散並運作在「不同台」ESXi 虛擬化平台上，以避免災難事件發生時，因為角色運作在同一台 ESXi 虛擬化平台上，而喪失了 vCHA 高可用性的保護機制。

請在 vCenter Server 管理介面中，依序點選「Cluster > Configure > Configuration > VM/Host Rules > Add」項目，在彈出的 Create VM/Host Rule 視窗中填入規則名稱，本文實作名稱為「Separate vCHA Roles」，在 Type 下拉式選單中選擇至「Separate Virtual Machines」項目，按下 Add 鈕加入 Active、Passive、Witness 角色主機，以便此規則套用生效後，擔任 Active、Passive、Witness 角色的主機，不會運作在同一台 ESXi 主機上（如圖 14 所示）。

圖 14、新增 VM 虛擬主機分隔規則，確保 vCHA 不同角色主機不會運作在同一台 ESXi 主機上



vCHA 進入維護模式

當 vCenter Server 需要進行相關維運工作時，為了避免系統誤判導致觸發 vCHA 容錯移轉機制，管理人員可以在維運工作執行之前，先將 vCHA 高可用性機制進入「維護模式」（Maintenance Mode）。

請依序點選「vCenter Server > Configure > Settings > vCenter HA > Edit」項目，在彈出的 Edit vCenter HA 視窗中選擇「Maintenance Mode」項目。此時，在管理介面中將看到 vCenter HA 運作模式，由原本的 Enabled 轉換為「Maintenance」，同時系統資訊也提醒「Automatic failover is not allowed. Manual failover is allowed」，表示自動切換機制已經停用，但管理人員仍然能夠手動切換（如圖 15 所示）。

下列為組態設定 vCHA 高可用性機制時，三種不同的運作模式分別有哪些影響：
  • Enable vCenter HA： 啟用 vCHA 高可用性，此時 Active Node 和 Passive Node 之間的 PostgreSQL 資料庫，將會自動進行複寫作業，管理人員除了可以手動執行切換作業之外，發生災難時系統將會自動進行容錯移轉作業。
  • Maintenance Mode： 維護模式，PostgreSQL 資料庫保持複寫作業，也可以手動執行切換作業，但目前 vCHA 機制處於維護模式，所以不會自動執行容錯移轉作業，以避免發生誤判的情況。
  • Disable vCenter HA： 停用模式，PostgreSQL 資料庫不會執行複寫作業，管理人員也無法手動執行切換，系統也不會自動進行容錯移轉作業，通常用於讓 vCenter Server 恢復單台運行時使用。

圖 15、組態設定 vCHA 高可用性機制進入維護模式



不同災難事件 vCHA 如何因應

最後，管理人員部署 vCHA 高可用性機制後，必須了解當發生各種不同的災難事件時，例如，伺服器硬體、實體網路環境……等，在發生什麼災難的情況下，才會觸發 Passive Node 接手 Active Node 服務，以及 vCenter Server 的 IP 位址。

下列，為列舉當發生各種不同的災難事件時，vCHA 高可用性機制將如何因應：
  • Active Node 發生災難時： 只要 Passive Node 與 Witness Node 之間能夠正常通訊，那麼 Passive Node 將會接手 Active Node 角色，相關系統服務和 vCenter Server IP 位址，同時回應 vSphere Client 的操作請求。
  • Passive Node 發生災難時： 只要 Active Node 與 Witness Node 之間能夠正常通訊，則 Active Node 繼續保持原有角色，繼續回應 vSphere Client 的操作請求。
  • Witness Node 發生災難時： 只要 Active Node 與 Passive Node 之間能夠正常通訊，則 Active Node 繼續保持原有角色，繼續回應 vSphere Client 的操作請求。同時，Passive Node 將會偵測 Active Node 是否正常運作，以便再次發生災難事件時，能夠自動進行容錯移轉角色切換作業。
  • 主機發生網路隔離行為： 當單台主機發生網路中斷事件時，在經過間歇性網路故障偵測程序，並且所有重試機制都執行完畢後，系統便會將該台角色主機判定為隔離狀態，一旦主機進入隔離狀態後，系統將會把該台主機所有服務停止。舉例來說，倘若 Active Node 被判定為隔離狀態後，那麼 Active Node 將會停止所有服務，以及使用的 vCenter Server IP 位址，確保 Passive Node 能夠順利接手為 Active Node 角色，並繼續回應 vSphere Client 的操作請求（如圖 16 所示）。
  • 多台節點發生故障： 原則上，vCHA 高可用性機制只能因應「單台」角色主機發生故障，無法因應「多台」角色主機同時發生故障。舉例來說，實體網路交換器發生嚴重災難事件，導致 Active、Passive、Witness 這 3 台主機無法互相通訊，此時 vCHA 高可用機制將無法正常運作，因為在 vCHA 高可用性機制的設計中，並無法容許同時發生多項故障。

圖 16、原本的 Active Node 發生網路隔離後 Passive Node 接手





結語

透過本文的深入剖析及實作演練，管理人員已經理解最新 vCenter Server 8 U1 版本中，vCHA 高可用性機制及運作架構，並且根據 VMware 官方提出的最佳建議作法，即可輕鬆為企業和組織，建構出高可用性並具備靈活應用的 vCenter Server 管理平台。
↧

免費體驗 HCI 超融合叢集，實作資料中心防火牆 | 網管人 215 期

December 30, 2023, 8:15 pm
$
0
0

網管人雜誌

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





本文目錄






前言

在企業和組織的資料中心內，即便已經導入伺服器虛擬化和容器等現代化工作負載，倘若未整合 SDN 軟體定義網路環境時，那麼對於內部網路惡意攻擊的防護能力勢必薄弱。主要原因在於，傳統的防火牆的運作機制，為過濾及處理內部資料中心與網際網路之間的網路連線，也就是大家熟悉的「南 - 北」（North-South）向網路流量。

然而，隨著時間推移而不斷進化的惡意攻擊，一旦企業或組織的內部資料中心，只要有一台主機被攻陷進而開始感染鄰居主機時，此時傳統防火牆便無法阻擋這種「東 - 西」（East-West）向惡意攻擊類型（如圖 1 所示）。

圖 1、東西向網路惡意攻擊示意圖
圖片來源： Attack modeling for finding and stopping lateral movement | Microsoft Security Blog





資料中心防火牆

在 Azure Stack HCI 超融合環境中，一旦建構「資料中心防火牆」（Datacenter Firewall）功能後，管理人員便能針對虛擬化環境的工作負載，建構軟體式網路封包過濾機制。簡單來說，資料中心防火牆將會透過邏輯和虛擬網路當中，透過 ACL 存取控制清單來進行網路封包過濾的目的（如圖 2 所示）。

圖 2、資料中心防火牆運作概念示意圖
圖片來源： Azure Stack HCI 上的資料中心防火牆 - Training | Microsoft Learn

對於企業或組織中的管理人員或使用者來說，資料中心防火牆能夠提供下列管理和防護機制：



標籤分段安全性機制

在傳統網路架構中，由於防火牆是座落在保護南北向網路流量的位置，所以能夠有效阻擋來自網際網路的惡意攻擊。然而，一旦惡意攻擊穿越保護南北向網路流量的防火牆時，例如，透過社交攻擊引誘內部使用者點選釣魚信件……等，那麼傳統防火牆便無法阻擋新型態的惡意攻擊，例如，一旦感染內部主機後，惡意攻擊便透過 Port 80、443 控制受感染的主機，並嘗試感染其它內部主機（如圖 3 所示）。

圖 3、傳統南北向網路防火牆無法有效阻擋新世代的惡意攻擊行為

在建構的 SDN 軟體定義網路環境中，即可透過「標籤分段」（Tag based Segmentation）的安全性機制，阻擋東西向惡意攻擊網路流量。簡單來說，在每一台 VM 虛擬主機的前方，都有一台軟體式防火牆進行防護，所以能夠輕易阻擋東西向的惡意攻擊，舉例來說，許多 VM 虛擬主機處於同一個 VLAN 網路環境，雖然其中一台遭受惡意攻擊成功，但卻無法感染同一個網段中的其它 VM 虛擬主機（如圖 4 所示）。

圖 4、標籤分段安全性機制有效阻擋東西向惡意攻擊示意圖
圖片來源： Tag based Segmentation with Azure Stack HCI - Microsoft Community Hub

在管理上，由於標籤分段的組態設定中，可以直接打上標籤或網段，所以管理人員可以輕鬆透過組態設定方式，為 VM 虛擬主機進行防護。舉例來說，管理人員可以組態設定兩個標籤，分別是 Web App 和 IoT App ，並且組態設定這兩個標籤之間的網路流量不可互通，即可達成防護的目的（如圖 5 所示）。

圖 5、組態設定標籤或網段進行東西向網路防護工作任務
圖片來源： Tag based Segmentation with Azure Stack HCI - Microsoft Community Hub





實戰 – 在 Azure Stack HCI 實作資料中心防火牆

過去，企業或組織想要在地端資料中心內，部署 Microsoft HCI 超融合及 SDN 軟體定義網路環境時，對於中大型企業或組織來說，在 IT 預算和管理人力都充足的情況下，可以採用任何想要的部署方式。然而，對於 IT 人力和預算原本就不足的中小企業或組織來說，無論選擇哪種部署方式，想要評估和體驗 HCI 及 SDN 技術，就顯得有些距離和吃力。

由於，企業或組織的資料中心內，或許沒有部署 Azure Stack HCI 超融合環境。因此，在實戰演練小節中，將在 Azure 公有雲環境中，透過 Hyper-V 巢狀式虛擬化技術部署 Azure Stack HCI 超融合環境，讓 IT 管理人員在無須準備任何硬體設備的情況下，便能夠實作及體驗，在 Azure Stack HCI 超融合環境中部署資料中心防火牆。



部署支援巢狀式技術的 Azure VM

首先， IT 管理人員必須擁有 Azure 訂閱帳號，並選擇支援巢狀式技術的 VM 虛擬主機。倘若， IT 管理人員並沒有 Azure 訂閱帳號時，可以註冊 Azure 免費體驗訂閱帳號後，將免費訂閱帳號 升級為「隨用隨付」（Pay-as-you-go），便能取得 USD 200 美金的額度，後續記得實作完成後關閉和刪除建立的雲端資源，便能夠在免費額度的情況下實作本文環境。

在選擇 VM 虛擬主機的部份，只要參考該系列的 VM 虛擬主機功能頁面，確認支援「巢狀虛擬化」（Nested Virtualization）功能即可，舉例來說，本文實作採用 Ev5 系列的 VM 虛擬主機（如圖 6 所示）。

圖 6、確認採用的 VM 虛擬主機規則支援巢狀虛擬化功能
圖片來源： Ev5 和 Esv5 系列 - Azure 虛擬機器 | Microsoft Learn

值得注意的是，最新的 Gen2 VM 映像檔，支援更多安全性功能，並且預設採用「Trusted launch virtual machines」選項，但是採用此預設值之後，反而會讓巢狀虛擬化功能喪失（如圖 7 所示）。因此，倘若是手動建立 Azure VM 虛擬主機的管理人員，必須在建立的過程中，一旦採用 Gen2 VM 映像檔時，記得在 Security Type 下拉式選單中，從預設值改為選擇「Standard」項目即可。

圖 7、採用 Gen 2 映像檔時，預設值並不支援啟用巢狀虛擬化功能

為了方便管理人員快速部署 Azure Stack HCI 超融合環境，請瀏覽評估 Azure Stack HCI 頁面，在部署 Azure VM頁面中，按下頁面中的 Deploy to Azure鈕，系統將會自動開啟新頁面至 Azure Portal 介面，請管理人員依據需求調整下列項目（如圖 8 所示）：
  • Subscription： 選擇使用的 Azure 訂閱帳戶，本文實作為「Weithenn Labs - MSDN」。
  • Resource Group： 選擇存放 VM 虛擬主機和雲端資源的資源群組，採用新增的「RG-AzSHCI-Lab」。
  • Region： 選擇使用的 Azure 資料中心，採用「東亞」（East Asia）資料中心。
  • Custom Rdp Port： 組態設定連線至 VM 虛擬主機的 RDP 遠端桌面連線埠，採用預設值 3389 。
  • Virtual Machine Name： 此台 VM 虛擬主機的電腦名稱，組態設定電腦名稱為「AzSHCILabHost」。值得注意的是，電腦名稱超過 15 個字元或包含特殊符號的話，後續的部署工作任務將會發生錯誤導致部署失敗。
  • Virtual Machine Size： 選擇部署 VM 虛擬主機採用的規格大小，採用 Standard_E20s_v4 。
  • Data Disk Size： 組態設定每個資料硬碟的大小，採用預設值 256GB ，屆時系統將會以 256GB x8 顆進行組合，屆時 VM 虛擬主機將會看到 2TB 空間大小的儲存空間。
  • Admin Username： 組態設定登入 VM 虛擬主機的管理帳號，本文實作為 Weithenn 。
  • Admin Password： 組態設定登入 VM 虛擬主機的管理密碼。值得注意的是，這裡的管理密碼僅鍵入一次，因此請務必注意不要打錯字，避免稍後無法 RDP 登入 VM 虛擬主機的情況。
  • Auto Shutdown Status： 是否啟用自動關機機制，本文將自動關機組態設定停用，避免影響實作。
圖 8、在 Azure 公有雲環境中，快速部署 Azure Stack HCI 超融合環境

確認無誤後，按下「Review + create」鈕，便立即進行部署 Azure Stack HCI 超融合環境的工作任務。當系統檢查無誤出現「Validation Passed」訊息後，按下 Create 鈕立即部署 Azure Stack HCI 超融合環境，在本文環境中花費「55 分鐘」順利部署完成。

值得注意的是，部署作業完成後，管理人員會發現無法 RDP 連線至 VM 虛擬主機 ？簡單來說，因為安全性考量，所以系統已經將 RDP 連線（Port 3389）進行阻擋導致無法連線。只要在 Azure Portal 頁面中，進入 VM 虛擬主機頁面，點選「Settings > Networking > Inbound port rules」，可以看到系統自動將 RDP Port 3389 連線規則設定為「Deny」，只要修改為「Allow」允許放行即可順利連線。



一鍵部署 Azure Stack HCI + SDN 環境

順利登入後，由於主機時區採用標準的 UTC 格林威治時間，請調整為適合且習慣的「UTC + 08 :00 - Taipei」台北時區。此外，開啟磁碟管理員，可以發現系統已經組態設定好 2TB 大小的磁碟空間，並且指派「V :」磁碟機代號。

原則上，只要點選二下桌面上「New-AzSHCISandbox.ps1」圖示，系統便會開始自動部署 HCI + SDN 運作環境，並建立三台 VM 虛擬主機，分別是 AzSMGMT 的 DC 網域控制站，以及 AzSHOST1 和 AzSHOST2 超融合節點主機，並且花費大約 2 小時左右的時間即可自動部署完成（如圖 9 所示）。

圖 9、花費 2 小時時間自動部署 HCI + SDN 運作環境



Windows Admin Center 管理平台

部署作業完成後，桌面上會出現名為「AdminCenter」的 RDP 連線捷徑，這是連線至 AzSMGMT 主機使用，預設情況下，管理者帳號為「Contoso\Administrator」密碼為「Password01」。

由於， AzSMGMT 為管理用途主機，登入後可以看到許多管理工具捷徑，請點選桌面上 Windows Admin Center 捷徑，並採用同樣的預算管理帳號及密碼即可登入。

登入 WAC 管理平台後，預設情況下將自動進行更新作業。可以看到，更新後採用最新的 WAC v2306 版本，以及 WAC 所有使用到的擴充模組，包含本次實作中主要使用的 SDN 軟體定義網路擴充模組。點選右上角齒輪圖示，點選 Gateway 下的 Extensions 項目，即可查看 SDN 軟體定義網路擴充模組及版本（如圖 10 所示）。

圖 10、查看 WAC 及 SDN 軟體定義網路擴充模組及版本

在 WAC 主要頁面中，請依序點選「All connections > Cluster Manager > Add」項目，在 Add cluster 頁籤中 Cluster name 欄位，鍵入預設的 HCI 超融合叢集名稱「AzStackCluster.contoso.com」，待系統正確辨別叢集名稱後，按下 Add 鈕即可順利連線至 HCI 超融合叢集（如圖 11 所示），並看到 HCI 超融合叢集的各種工作負載資訊。

圖 11、連線至預設的 HCI 超融合叢集



啟用 SDN 軟體定義網路基礎架構

此時，在 WAC 管理介面中，可以發現在 Networking 項目下，卻僅 Virtual switches 和 SDN Infrastructure 等兩個項目，請點選 SDN Infrastructure 項目，系統將會自動安裝 RSAT-NetworkController 伺服器功能管理工具，並自行安裝 SDN 網路控制器的 REST 憑證，待 SDN Infrastructure 頁面出現「SDN infrastructure was detected and validated」訊息時，請按下 Continue 鈕。

待一段時間後，系統將彈出 Connect to Network Controller 視窗，請管理人員鍵入 SDN 網路控制器主機名稱，鍵入「nc01.contoso.com」後，按下 Continue 鈕後，便會連結至 SDN 網路控制器，同時系統提示連線後按下 F5 鍵，以便重新載入 WAC 管理介面。

一旦順利重新載入 WAC 管理頁面後，便能看到 Networking 項目下，多了許多 SDN 軟體定義網路管理項目，包括， Virtual switches、Route tables、Network security groups…… 等（如圖 12 所示）。

圖 12、順利啟用 SDN 軟體定義網路基礎架構



註冊 Azure Stack HCI 超融合環境

值得注意的是，必須註冊 Azure Stack HCI 超融合環境後，才能順利建立 VM 虛擬主機，並給予高可用性角色，否則系統將會顯示 VM 虛擬主機建立成功，但是無法給予高可用性角色（如圖 13 所示），所以只能在單台 Azure Stack HCI 主機中看到 VM 虛擬主機，而無法在 Azure Stack HCI 超融合叢集中，看到 VM 虛擬主機。

圖 13、未註冊的 Azure Stack HCI 叢集無法建立高可用性 VM 虛擬主機

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

回到原有對話視窗中，可以發現多了 Connect to Azure AD 的訊息，並顯示 Azure AD Tenant ID ，在 Azure AD Application 中，可以選擇 Create New 或 Use Existing 選項後按下 Connect 鈕，順利連接至 Azure AD 環境後，按下 Sign in to Azure 選項中的 Sign in 鈕，即可將此台 WAC 註冊至指定的 Azure 訂閱帳戶和 Azure AD 環境中。

回到 Dashboard 頁面，點選 Azure Arc 中 Azure Stack HCI registration 連結，由於剛才已經通過驗證程序，所以系統將會直接嘗試註冊 Azure Stack HCI 叢集，並啟用 Azure Arc 管理機制。此時，可以切換至 Azure Portal 頁面，查看 Azure AD 中是否順利將 WAC 主機註冊，切換至「Azure Arc > Infrastructure > Azure Stack HCI」，是否出現 Azure Stack HCI 叢集，且狀態顯示為 Connected ，確保和地端的 WAC 管理平台已經連線成功。

確認連線成功後，請切換回 WAC 管理平台視窗，系統顯示成功註冊資訊，而 Azure Arc 區塊中的 Status 狀態資訊，也從原先的紅色錯誤的 Not yet registered ，變更為綠色打勾的 Connected 狀態（如圖 14 所示）。

圖 14、成功註冊 Azure Stack HCI 超融合叢集



建立邏輯網路

在 WAC 管理介面中，依序點選「Networking > Logical networks > New」項目，首先在 Logical network Name 欄位，填入邏輯網路名稱此實作為「VM-Logical-Network」，然後點選下方 Logical subnet 的 Add 鈕，同樣的，在新增邏輯網段視窗中，依序填入邏輯網段名稱、VLAN ID、網段資訊，預設閘道、DNS……等資訊，以及是否套用「網路安全群組」（Network Security Group，NSG），再次點選下方邏輯網段 IP Pool 的 Add 鈕，在新增邏輯網段 IP Pool 視窗中，依序填入邏輯網段 IP Pool 名稱、開啟的 IP 位址、結束的 IP 位址，確認無誤後按下 Add 鈕兩次，最後按下 Submit 鈕即可建立邏輯網路（如圖 15 所示）。

圖 15、建立給 VM 虛擬主機工作負載使用的邏輯網路



建立 VM 虛擬主機並套用邏輯網路

在建立 VM 虛擬主機時，可以在網路項目中，組態設定 VM 虛擬主機使用剛才所建立的邏輯網路，在 VM 虛擬主機安裝完成後，安裝 IIS 網頁伺服器服務，以便稍後測試 NSG 網路安全群組功能。如圖所示，可以看到 VM 虛擬主機使用邏輯網路指派的「192.168.1.101」IP 位址（如圖 16 所示）。

圖 16、VM 虛擬主機順利使用邏輯網路



建立 NSG 規則並套用至 VM 虛擬主機

請在 WAC 管理介面中，依序點選「Networking > Network security groups > Inventory > New」項目，在彈出視窗中請填入 NSG 規則名稱後，按下 Submit 鈕建立 NSG 名稱。

建立完成後，進入該 NSG 規則，在 Network security rule 區塊中按下 New 鈕，在視窗中便是 NSG 安全性原則的組態設定（如圖 17 所示）：
  • Name： 填入 NSG 規則名稱，本次實作為 WebApp-80 以利識別。
  • Priority： NSG 規則的執行順序 ID，預設情況下，NSG 安全性原則採用「先進先出」（First-In First-Out，FIFO），所以順序 ID 數值越小則優先權越高。
  • Type： 針對「流入」（Inbound）或「流出」（Outbound）的網路流量進行管控。
  • Protocol： 針對何種通訊協定進行管控，支援 TCP、UDP、ICMPv4、ICMPv6、Http 等通訊協定，倘若管理人員不確定哪種通訊協定時，可以選擇 All 過濾所有通訊協定。
  • Source： 針對「來源」（Source）網路流量進行管控，可以採用 Any 過濾所有來源網路，或是指派過濾特定的來源 IP 位址或 IP 網段，或者是服務標籤進行過濾。
  • Source Port Range： 針對來源端的通訊埠區段進行過濾，倘若需要針對所有的通訊埠時，可以採用「*」萬用字元，表示針對來源端的所有通訊埠進行過濾。
  • Destination： 針對「目的地」（Destination）網路流量進行管控，可以採用 Any 過濾所有目的地網路，或是指派過濾特定的目的地 IP 位址或 IP 網段，或者是服務標籤進行過濾。由於，需要測試能否阻擋東西向網路流量，所以選擇針對剛才的 VM 虛擬主機 IP 位址「192.168.1.101」進行過濾。
  • Destination Port Range： 針對目的地的通訊埠區段進行過濾，倘若需要針對所有的通訊埠時，可以採用「*」萬用字元，表示針對來源端的所有通訊埠進行過濾，為了測試能否阻擋東西向網路流量，所以選擇針對剛才 VM 虛擬主機的 IIS 網頁伺服器服務， Port 80 進行過濾。
  • Actions： 一旦網路封包符合 NSG 安全性原則的過濾規則時，系統要如何處理該網路封包，可以採用「放行」（Allow）或「阻擋」（Deny），為了測試能否阻擋東西向網路流量，所以選擇符合過濾結果時為 Deny 進行阻擋。
  • Logging： 是否啟用日誌功能，以便記錄此 NSG 安全性原則過濾規則的日誌內容。
圖 17、建立 NSG 安全性原則中的網路封包過濾規則

現在，請回到 VM 虛擬主機的網路組態設定，將剛才建立的 NSG 安全性原則進行套用的動作（如圖 18 所示）。然而，可能會發生套用失敗的情況，原因在於 VM 虛擬主機必須在關機的狀態下，才能套用 NSG 安全性原則，順利套用後請將 VM 虛擬主機開機。

圖 18、為 VM 虛擬主機套用 NSG 安全性原則

現在，可以看到 VM 虛擬主機的 IIS 網頁伺服器服務，仍然正常運作當中。然而，從其它外部主機卻無法再存取 IIS 網頁伺服器服務，即便外部主機和 VM 虛擬主機處於同一個網段，仍無法順利存取 IIS 網頁伺服器服務，NSG 安全性原則順利運作，能夠輕易阻擋東西向網路流量（如圖 19 所示）。

圖 19、NSG 安全性原則順利運作過濾東西向網路流量





結語

透過本文的深入剖析和實作演練後，相信管理人員已經理解傳統防火牆的缺點，以及部署 SDN 軟體定義環境後，透過 NSG 安全性原則便能輕鬆阻擋傳統防火牆，所無法阻擋的東西向網路流量。同時，透過免費的 Azure 訂閱或花費少許費用，即便是 IT 預算不足的小型企業或組織，在沒有任何硬體設備的情況下，也能立即實際操作並體驗 HCI 超融合叢集，以及整合 SDN 軟體定義網路環境。
↧
Search

vCLS 叢集服務卡住免驚，手動撤退模式重新部署 | 網管人 216 期

January 26, 2024, 7:45 pm
$
0
0


網管人雜誌

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





本文目錄






前言

最初的 vSphere 8 版本在 2022 年 10 月發佈，經過六個月後發佈 vSphere 8 Update 1 版本，最新的 vSphere 8 Update 2 版本，則是在 2023 年 VMware Explore 大會中正式發佈（如圖 1 所示）。事實上，管理人員可以察覺，即便 VMware 每六個月便發佈新版本，然而每一版更新並非僅是功能增強或臭蟲更新，反而包含許多新增特色功能。在本文中，將逐一剖析各項亮眼特色功能，並且實戰演練最新發佈的 vCLS 撤退機制，讓企業和組織的管理人員，能夠更輕鬆管理 vCLS 叢集服務。

圖 1、隨著 VMware Explore 2023 大會發佈的最新 vSphere 8 U2 版本
圖片來源： vSphere 8 U2 Now Available - VMware vSphere Blog





vSphere 8 U2 亮眼特色功能

減少新版升級停機時間

在 VMware 運作架構中，許多特色功能或進階功能，都圍繞在 vCenter Server 管理平台中。然而，只要是軟體產物便需要進行安全性更新、臭蟲修補、版本升級……等，一旦 vCenter 執行安全性更新、臭蟲修補、版本升級等工作任務時，便會處於離線狀態從而產生「停機時間」（Downtime）。

雖然，vCenter 管理平台產生停機時間時，對於上層的 VM 虛擬主機或容器等工作負載，並不會造成營運服務中斷或無法運作的情況，但此時因為 vCenter 處於離線狀態，而無法執行許多進階功能。

因此，在最新 vSphere 8 U2 版本中，將 vSphere+ 雲端環境的 vCenter 更新機制（如圖 2 所示），下放到地端 vCenter 管理平台中，以便減少 vCenter 因為更新而造成的停機時間，那麼 vSphere+ 雲端和原有地端環境更新機制有什麼不同之處呢？

圖 2、vSphere+ 雲端環境的 vCenter 更新機制流程示意圖
圖片來源： What's New in vSphere 8 U2? | Reduced Downtime Upgrade | VMware

簡單來說，vSphere+ 更新機制的重點為「遷移」（Migration-Base），在更新動作執行時，先部署新的 vCenter，並將原有 vCenter 的資料和組態設定配置，複製到新部署的 vCenter 當中，其實這樣的機制類似於地端 vCenter 跨大版本升級作業。

然而，這之間的主要差別在於，新舊 vCenter 資料和組態設定複製階段期間，原有 vCenter 的所有服務仍正常運作，管理人員仍能透過 vCenter，執行相關進階特色功能並管理虛擬化基礎架構，整個流程中唯一會發生 vCenter 停機的時間點，就是資料和組態設定複製階段完成後，原有 vCenter 停止服務，由新部署的 vCenter 接手並啟動服務，原則上來說通常在五分鐘之內完成，這和過往地端 vCenter 的停機時間相比大量減少許多。

新式更新機制共有如下五個步驟，並且管理人員也可以在實際更新期間，查看工作任務的執行進度（如圖 3 所示）：
1. 掛載 ISO 映像檔：將準備部署新版本的 vCenter ISO 映像檔進行掛載。值得注意的是，這個 ISO 映像檔是完整的安裝 ISO 映像檔，而非安全性更新或修補臭蟲的 ISO 映像檔。
2. 檢查備份：系統將檢查和確認，原有運作中的 vCenter 管理平台，是否已經執行備份工作任務。
3. 更新外掛程式：系統將在原有 vCenter 管理平台中，更新 vCenter 生命週期服務，以便後續部署新的 vCenter 管理平台，這也是更新機制對於原有 vCenter 的唯一變更。
4. 組態設定新的 vCenter：針對新部署的 vCenter 進行組態設定，包括，VM 虛擬主機名稱、臨時的 root 管理帳號密碼、臨時的 vNetwork 虛擬網路設定……等，管理人員可以選擇繼承原有 vCenter 組態設定，也可以選擇自行組態設定。預設情況下，新部署的 vCenter，將會繼承原有 vCenter 的 root 管理帳號密碼和網路身份驗證。
5. 升級與執行切換：一旦新部署的 vCenter 複製和組態設定完畢，並且兩台 vCenter 都保持正常運作狀態時，管理人員便能決定何時執行切換作業，原則上可以立即執行切換 vCenter 的工作任務，也可以排程設定一天後或一週後都可以。值得注意的是，切換期間原有 vCenter 停止服務，新部署的 vCenter 接手並啟動服務，通常還是未產生五分鐘之內的停機時間。

圖 3、新式 vCenter 更新機制操作畫面示意圖
圖片來源： What's New in vSphere 8 U2? | Reduced Downtime Upgrade | VMware



可靠的網路組態設定復原機制

無論企業和組織，針對 VMware 虛擬化基礎架構部署多少高可用性機制，在面對意外的災難事件時，仍有可能需要最後一道防線「備份 / 還原」。然而，執行備份作業時，通常也僅是針對當時的資料和組態設定進行備份，但是備份作業完成後，仍然會有其中工作任務執行，例如，新增 / 修改 / 刪除 VM 虛擬主機，新增 / 修改 / 刪除 vNetwork 虛擬網路……等。

因此，雖然管理人員在遭遇意外災難事件後，選擇最接近的備份時間點進行還原後，仍然需要處理這些備份後至災難發生期間的組態設定值，舉例來說，備份作業完成後，新增 / 修改 / 刪除 vNetwork 虛擬網路，還原後則仍需要管理人員手動處理這些 vNetwork 的異動作業。

現在，最新 vSphere 8 U2 版本中，將「分散式鍵值儲存」（Distributed Key-Value Store）機制擴充，包含 vSphere 和 NSX 中的 vDS 分散式虛擬網路交換器組態設定。因此，當災難發生並執行還原作業後，在 vSphere 叢集中 ESXi 主機的最新 vDS 分散式虛擬網路交換器組態設定資訊，將會自動被推送到還原後的 vCenter 資料庫內（如圖 4 所示），所以管理人員便無須於還原作業後，手動更新 vDS 分散式虛擬網路交換器組態設定。

圖 4、vCenter 可靠網路組態設定復原機制運作流程示意圖
圖片來源： What's New in vSphere 8 U2? | Reliable Network Configuration Recovery | VMware



最佳化放置 GPU 工作負載

企業和組織為了因應這波 AI 浪潮，紛紛在虛擬化環境中部署 vGPU 環境，以便加快 ML 機器學習和 LLM 大型語言模型的訓練和調校。雖然，在透過 vGPU 機制，可以有效將 2、4、8 個 vGPU 圖形運算資源，分配給 VM 虛擬主機使用，甚至最新 vSphere 8 U2 版本，可以支援最大指派 16 個 vGPU 圖形運算資源給 VM 虛擬主機，以便最大化使用 GPU 資源並縮短 AI 模型的訓練和調校時間。

然而，和過往 VM 虛擬主機會碰到的資源碎片問題相同，環境中配置不同資源大小的 vGPU 虛擬主機時，這種情況便更容易發生，一旦發生資源碎片的問題時，便可能造成雖然整體 vSphere 叢集，還有足夠的 vGPU 資源，但是新部署的 vGPU 虛擬主機卻無法使用並順利啟動。

舉例來說，運作環境中有三台 ESXi 虛擬化平台，每台 ESXi 共有四個實體 GPU 圖形運算資源，並且每台 ESXi 虛擬化平台上，已經分別運作一台配置 2 vGPU 虛擬主機。此時，新的專案需要一台配置 4 vGPU 虛擬主機，雖然整體 vSphere 叢集仍有 6 vGPU 圖形運算資源，但是並沒有任何一台 ESXi 虛擬化平台，擁有足夠運作一台 4 vGPU 虛擬主機的圖形運算資源（如圖 5 所示）。此時，這台新增部署的 4 vGPU 虛擬主機，便會處於等待放置狀態且無法開機運作。

圖 5、實體 GPU 圖形運算資源碎片問題示意圖
圖片來源： Improving VM Placement to Servers to Optimize Your GPU Usage in VMware vSphere 8 U2 | VMware

因此，在新版 vSphere 8 U2 版本中，新增 GPU 最佳化放置機制，以便解決實體 GPU 圖形運算資源碎片問題。舉例來說，上述 GPU 資源碎片問題發生時，管理人員只需要組態設定 vSphere 叢集中，新增「VgpuVmConsolidation = 1」進階功能參數，系統便會將 vGPU 資源大小相同的 VM 虛擬主機，遷移到同一台 ESXi 虛擬化平台上，同時搭配「LBMaxVmotion = 1」進階功能參數，還可以避免 ESXi 虛擬化平台，觸發執行多次 vGPU 虛擬主機 vMotion 遷移事件。更多最佳化放置 vGPU 圖形運算資源，進階功能參數的詳細資訊，請參考 VMware KB88271、KB66813知識庫文章。

因此，一旦管理人員將上述二項進階功能參數，組態設定至 vSphere 叢集時，系統便會遷移組態定2 vGPU 虛擬主機，到同一台 ESXi 虛擬平台上，從而空出完整支援 4 vGPU 虛擬主機的資源，讓新增部署的 4 vGPU 虛擬主機，能夠成功放置並順利開機運作（如圖 6 所示），以便充分利用 vSphere 叢集中的 GPU 圖形運算資源。

圖 6、最佳化放置 vGPU 圖形運算資源示意圖
圖片來源： Improving VM Placement to Servers to Optimize Your GPU Usage in VMware vSphere 8 U2 | VMware



VM 虛擬主機最新虛擬硬體版本 v21

在每一版的 VM 虛擬主機虛擬硬體版本中，除了擴充原有支援限制之外，也同步新增支援各種硬體，以便因應各種現代化工作負載。在最新 vSphere 8 U2 版本中，開始支援最新 VM 虛擬硬體版本 v21（如圖 7 所示）。

圖 7、最新 VM 虛擬硬體版本 v21 增強或新增功能示意圖
圖片來源： What's New in vSphere 8 U2? | More Vroooom for your VM with Hardware Version 21 | VMware

在最新 VM 虛擬硬體 v21 版本中，增強或新增支援 VM 虛擬主機虛擬硬體項目如下：
  • 每台 VM 虛擬主機，支援組態設定最多使用 16 vGPU 圖形運算資源。
  • 每台 VM 虛擬主機，支援組態設定最多 4 個 vNVMe 儲存控制器，每個 vNVMe 儲存控制器支援掛載 64 個 vNVMe 儲存裝置，總共支援掛載 256 個 vNVMe 儲存裝置。
  • 針對 Windows 11 和 Windows Server 2022 客體作業系統，新增支援 NVMe 1.3 。
  • 在 WSFC 容錯移轉叢集運作架構中，新增支援 NVMe 儲存裝置。
  • 支援安裝最新的 RHEL 10、Oracle Linux 10、Debian 13 和 FreeBSD 15 的客體作業系統。



VM 服務正式支援 Windows 虛擬主機

在前一版 vSphere 8 U1 版本中，新增支援「VM 服務」（VM Service）機制，並支援從內容庫部署自訂的 Linux VM 虛擬主機。

在最新 vSphere 8 U2 版本中，VM 服務正式支援 Windows VM 虛擬主機（如圖 8 所示）。因此，管理人員或開發人員，可以透過 kubectl 指令部署 Windows VM 虛擬主機到命名空間，並且搭配標準的 SysPrep 格式的自定義檔案，客製化企業和組織需要的 Windows VM 虛擬主機運作環境。

圖 8、VM 服務正式支援 Windows VM 虛擬主機運作示意圖
圖片來源： What's New in vSphere 8 U2? | Windows VM Support for VM Service | VMware



NSX ALB 負載平衡機制成為主流

事實上，VMware 官方宣佈從 NSX-T Data Center 3.2.0 版本開始，過往的 NSX-T LB（Load Balancer）負載平衡機制將被棄用，並在後續的新版本將完全從內建清單中刪除。

因此，從 NSX 4.x 版本開始，或 vSphere with Tanzu 中的 Supervisor Cluster 運作環境，都建議使用 NSX ALB（Advanced Load Balancer）負載平衡機制（如圖 9 所示），取代過往且已經棄用的 NSX-T LB 負載平衡機制，以便更容易整合及維護管理，vSphere vDS 分散式虛擬網路交換器和網路堆疊。

圖 9、NSX ALB（Advanced Load Balancer）負載平衡機制運作示意圖
圖片來源： What's New in vSphere 8 U2? | Expanding NSX Advanced Load Balancer Support | VMware





實戰演練 – vCLS 叢集服務撤退模式

在過去 vSphere 7 U1 版本中，VMware 官方正式發佈 vCLS（vSphere Clustering Services）特色功能，為原本的 vSphere 叢集服務，新增建立「分佈式控制平面」（Distributed Control Plane）的第一個版本，以便將 vSphere 叢集服務和 vCenter 進行脫勾（如圖 10 所示）。

圖 10、vCLS 叢集服務運作架構示意圖
圖片來源： vSphere 7 U1 – vSphere Clustering Service（vCLS）– VMware vSphere Blog

在 vSphere 基礎架構中，一旦 vCenter 管理平台發生災難事件時，上層運作的 VM 虛擬主機和容器等工作負載，雖然不會受到任何影響並持續正式運作，但是管理人員也因為 vCenter 的損壞，而無法對 VM 虛擬主機和容器等工作負載進行任何的管理任務。

然而，在 vCenter 管理平台尚未恢復期間，雖然  vSphere HA（High Availability）高可用性，仍然能夠正常運作，但是 vSphere vMotion 線上遷移機制，或自動化遷移機制的  vSphere DRS（Distributed Resource Scheduler）……等其它機制，都將因為 vCenter 故障而無法運作。

這就是為什麼，VMware 官方推出 vCLS 叢集服務，讓 vSphere 叢集服務與 vCenter 脫勾，一旦 vCLS 叢集服務部署完成並正確運作後，當 vCenter 發生災難事件時，因為 vCLS 叢集服務會在 vSphere 叢集中，建立一至三台的 vCLS VM 虛擬主機，所以即便有部份 vCLS VM 虛擬主機受到影響，仍然能夠在 vCenter 尚未恢復時，讓自動化遷移 vSphere DRS 等進階功能繼續運作。詳細資訊請參考 VMware KB80472 知識庫文章。

在本小節中，將實戰演練舊版 vSphere 7 U3，手動執行「vCLS 撤退模式」（vCLS Retreat Mode），以及最新 vSphere 8 U2 版本中，新增圖形介面輕鬆操作 vCLS 撤退模式特色功能。



舊版 vCLS 叢集服務缺點

原則上，vCLS 叢集服務會讓原有 vSphere 叢集服務更穩定，並且和自動化遷移機制 vSphere DRS 互相協作配合。然而，有時可能因為某些因素或臭蟲，導致自動化遷移機制 vSphere DRS 無法正常運作，舉例來說，即便管理人員啟用 vSphere DRS，但是可能會發現 vSphere DRS 並沒有正常運作，不會自動化將 VM 虛擬主機遷移至其它工作負載低的 ESXi 虛擬化平台。

此外，也因為自動化遷移機制 vSphere DRS 無法正常運作，所以當災難事件發生觸發 vSphere HA 時，也將因為 vSphere DRS 最佳工作負載放置機制失效，雖然 vSphere HA 能夠順利把受影響的 VM 虛擬主機，重新在其它存活的 ESXi 虛擬化平台上開機，但是可能會產生工作負載放置極度不平均的狀態。詳細資訊請參考 VMware KB91891、KB79892知識庫文章。



如何刪除舊版 vCLS

由於在舊版 vCLS 叢集服務運作環境中，預設所有的 vCLS VM 虛擬主機，是由「vSphere 叢集服務」（vSphere Cluster Service）所管理，因此當管理人員嘗試干預 vCLS VM 虛擬主機時，系統便會跳出警告資訊，說明無須管理人員介入，而是由 vSphere 叢集服務自動管理 vCLS VM 虛擬主機（如圖 11 所示）。

圖 11、舊版 vCLS 叢集服務，管理人員無法管理 vCLS VM 虛擬主機

然而，一旦發生 vCLS 叢集服務在運作上有臭蟲的情況發生時，此時由於管理人員無法介入管理 vCLS VM 虛擬主機，所以便會無法徹底執行，將 vCLS VM 虛擬主機刪除後重新部署的動作，以便嘗試修復 vCLS 叢集服務臭蟲的情況。

此時，可以嘗試手動組態設定 vCenter 管理平台，將所有納管的 vSphere Cluster 都進入「撤退模式」（Retreat Mode），達到刪除所有 vSphere Cluster 內的 vCLS VM 虛擬主機的目的，然後再重新部署 vSphere Cluster 內的 vCLS VM 虛擬主機。
請注意! 除非出現 vCLS 叢集服務出現臭蟲或運作失敗的情況，否則管理人員不應隨意組態設定撤退模式。

在刪除 vCLS VM 虛擬主機之前，確認目前 vCLS VM 虛擬主機的情況，請依序點選「VMs and Templates > vCLS > VMs」項目，即可看到目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊（如圖 12 所示）。

圖 12、目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊

請在 vCenter 管理介面中，點選希望刪除 vCLS VM 虛擬主機的 vSphere Cluster 後，查看 URL 內中間關鍵字「domain-c + <數字>」，舉例來說，本文實作環境為「domain-c8」（如圖 13 所示）。值得注意的是，這個數值必須正確，假設稍後組態設定撤退模式時填錯數值，將會造成 vpxd 服務啟動失敗。

圖 13、確認要刪除 vCLS VM 虛擬主機所在的 vSphere Cluster

複製完成後，請依序點選「vCenter > Configure > Settings > Advanced settings > Edit Settings」項目，在彈出的組態設定視窗中，請移至視窗最底部在 Name 欄位中，填入「config.vcls.clusters.domain-c8.enabled」，並在 Value 欄位填入「False」後，按下 Add 鈕新增組態設定，最後按下 Save 鈕套用生效。

原則上，在 30 秒之內系統便會自動執行刪除作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Initiate guest OS shutdown」和「Delete virtual machine」的刪除工作任務，完成後可以看到在 vSphere Cluster 內，所有的 vCLS VM 虛擬主機已經刪除完畢（如圖 14 所示）。

圖 14、系統自動刪除 vSphere Cluster 內所有 vCLS VM 虛擬主機

接著，便可以回到剛才的組態設定視窗，點選 Name 頁籤中的過濾關鍵字圖示，鍵入「vcls」關鍵字後，即可找到剛才新增的組態設定值，請將剛才新增的組態設定值中 Value 欄位，由原本的 False 修改為「True」後（如圖 15 所示），按下 Save 鈕套用生效。

圖 15、修改 Value 組態設定值重新部署 vCLS VM 虛擬主機

同樣的，在 30 秒之內系統便會自動執行重新部署作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務，重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機（如圖 16 所示）。

圖 16、系統自動重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機



新版直接支援 vCLS 撤退模式

原則上，只要是採用 vSphere 8.0 U2 之前的版本，即便是前一版的 vSphere 8.0 U1，都只能使用上述方法組態設定，刪除和重新部署 vCLS VM 虛擬主機。在最新 vSphere 8.0 U2 版本中（如圖 17 所示），直接支援組態設定 vSphere Cluster 進入撤退模式。

圖 17、最新 vSphere 8 U2 版本，直接支援 vSphere Cluster 撤退模式



新版重新部署 vCLS VM 虛擬主機

因此，在最新 vSphere 8.0 U2 版本中，同樣出現 vCLS VM 虛擬主機運作異常或臭蟲的情況時，管理人員可以透過 vCenter 管理介面，直接為所屬的 vSphere Cluster 組態設定 vCLS 撤退模式。

同樣的，在刪除 vCLS VM 虛擬主機之前，確認目前 vCLS VM 虛擬主機的情況，請依序點選「VMs and Templates > vCLS > VMs」項目，即可看到目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊（如圖 18 所示）。

圖 18、目前 vSphere 8 U2 Cluster 內 vCLS VM 虛擬主機資訊

請在 vCenter 管理介面中，依序點選「Cluster > Configure > vSphere Cluster Services > General > vCLS Mode > Edit vCLS Mode」項目，在彈出視窗中可以看到，預設情況下系統採用「System Managed」系統管理模式，當管理人員希望刪除 vCLS VM 虛擬主機時，請選擇至「Retreat Mode」撤退模式後，系統出現警告訊息再次提醒管理人員，應該在 vCLS 機制運作異常時才組態設定採用撤退模式，確認後按下 OK 鈕套用生效（如圖 19 所示）。

圖 19、選擇 Retreat Mode 撤退模式準備刪除 vCLS VM 虛擬主機

組態設定套用生效後，系統立即執行自動刪除作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Reconfigure cluster」、「Initiate guest OS shutdown」和「Delete virtual machine」的刪除工作任務，完成後可以在 vSphere Cluster 內看到，所有 vCLS VM 虛擬主機已經刪除完畢（如圖 20 所示）。

圖 20、系統自動刪除 vSphere Cluster 內所有 vCLS VM 虛擬主機

回到剛才 vCLS 模式組態設定視窗，改為選擇「System Managed」系統管理模式後，按下 OK 鈕套用生效。同樣的，系統立即自動執行重新部署作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Reconfigure cluster > Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務，重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機（如圖 21 所示）。

圖 21、系統自動重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機





結語

透過本文的深入剖析和實作演練後，除了理解最新 vSphere 8 U2 版本的亮眼技術之外，也實作演練舊版 vSphere 7，以及新版 vSphere 8 U2 的 vCLS VM 虛擬主機管理作業，讓企業和組織的 vSphere 叢集能夠更穩定，不受 vCenter 故障所影響。
↧

HTTP Status 500 - Internal Server Error | vCenter Server 7

February 3, 2024, 4:07 am
$
0
0


Question:

登入 vCenter Server (Port 443) 管理介面時，僅顯示「HTTP Status 500 - Internal Server Error」錯誤訊息，登入 vCenter Server (Port 5480) 後發現，有蠻多系統服務都無法啟動，嘗試手動啟動這些服務，例如，Content Library Service 都發生啟動失敗的情況？



根據 Component Manager services fail at starting Content Library Service | VMware KB2147891文章內容，SSH 到 vCenter Server 之後，嘗試執行「service-control --start --all」指令啟動服務，也是啟動失敗的情況。




Answer:

找了一些網路文章後，透過下列二個文章連結的總結，應該是 vCenter Server 相關憑證到期導致的情況：
再度 SSH 登入至 vCenter Server 後，執行「for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done」指令，發現是「MACHINE_SSL_CERT」憑證過期了!


知道問題的原因之後，參照下列 VMware KB 文件，重新產生憑證即可順利啟動 vCenter Server 所有系統服務，順利解決問題：
請執行「/usr/lib/vmware-vmca/bin/certificate-manager」指令後，選擇「8. Reset all Certificates > Y > Y」，然後根據系統提示填入相關憑證資訊，例如，Country, Name, Organization...etc。


順利執行 Reset all Certificates 的動作後，再次執行「service-control --start --all」指令，即可順利啟動 vCenter Server 所有系統服務。


↧
↧

Deploying Three-Node Cluster | Nutanix CE

February 15, 2024, 9:32 am
$
0
0


簡介

先前已經撰寫部署單台節點的 Nutanix Cluster，本文為部署「三台」節點主機的 Nutanix Cluster。因此，巢狀式虛擬化和基礎組態設定的部份便省略不提，有興趣的朋友請參考站內文章  Deploying Single Node Cluster | Nutanix CE。



變更三台 CVM 主機名稱

事實上，也可以建立 Nutanix Cluster 後再變更 CVM 主機名稱，但是屆時因為 Nutanix Cluster 已經成形並且運作中，就會導致同一時間一次只能變更「一台 CVM」的主機名稱，為了節省時間，所以在部署 Nutanix Cluster 之前，執行「sudo /usr/local/nutanix/cluster/bin/change_cvm_hostnamecvm-n01」指令變更 3 台 CVM 的主機名稱 (本文實作為 cvm-n01 / cvm-n02 / cvm-n03)。事實上，根據 KB 內容應該要 NTNX- 開頭，以及 -CVM 結尾，剛好試試沒有照建議後續會發生什麼事？ 😂 值得注意的是，變更 CVM 主機名稱後，必須重新啟動才能套用生效。



變更三台 CVM 時區

由於 Nutanix Cluster 還沒部署，所以剛才變更主機名稱後，系統自動重新啟動的腳本似乎有問題，那就連 CVM 時區變動後再一起關機吧。可以看到，預設情況下採用 UTC 格林威治時間，執行「sudo timedatectl set-timezone Asia/Taipei」指令後，將系統時區改成「Asia/Taipei」。


變更完成後，可以執行「cvm_shutdown -P now」指令關機，倘若無法順利關機的話，便執行「sudo shutdown -h now」指令關機。將 CVM 都關機後，AHV 也可以採用同樣的方式變更時區，然後執行關機作業。因為，本文是巢狀式環境，所以關機後將安裝的 ISO 映像檔卸載後再開機。



部署多節點 Nutanix Cluster

三台 AHV 開機，並且三台 CVM 運作正常後，先確認彼此之間是否都可以 ping 到對方主機，確保通訊順暢後，在隨便一台 CVM 主機執行「cluster -s 10.10.75.31,10.10.75.32,10.10.75.33 create」指令 (都是 CVM IP 位址)，部署多節點的 Nutanix Cluster。



多節點 Nutanix Cluster 部署完成後，執行「ncli cluster info」指令，可以查看 Nutanix Cluster 相關資訊，例如，Cluster version 就是 AOS 版本資訊，本文實作環境為 6.5.2。


在 Nutanix Cluster 運作環境中，可以在任一台 CVM 主機中，執行「allssh hostname」指令，就等同於在三台 CVM 主機上執行「hostname」指令。另外，執行「cluster status |grep -v UP」指令，可以看到目前 CVM: 10.10.75.32 主機，目前擔任 ZeusLeader 的角色。




登入 Prism Element 管理介面

現在，無論連線哪一台 CVM IP 位址的 Port 9440，都可以連線登入至 Prism Element 管理介面。登入後，可以看到目前 Nutanix Cluster 中共有三台主機。在預設的儀表板中，可以看到 AHV 的版本資訊。


倘若，想要查看相關版本，例如，下圖中 3、4、5，便分別是 AOS / NCC / LCM 的版本。


採用指令的方式，也可以查看系統版本的相關資訊，例如，執行「ncc health_checks hypervisor_checks ahv_version_check」指令，即可查詢到 AHV 版本。


當然，使用 LCM 也可以查到系統相關版本。


有關 Nutanix Cluster 的相關基礎設定，後續文章將會陸續出爐。
↧

探索/評估/測試三階段，試玩地端虛機遷移 Azure | 網管人 217 期

February 17, 2024, 3:18 am
$
0
0


網管人雜誌

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





本文目錄






前言

由於 VM 虛擬化技術，無論是地端資料中心或是公有雲環境，都會因為使用不同的伺服器虛擬化技術，導致 VM 虛擬主機的格式不相同，而無法輕易遷移至不同的伺服器虛擬化平台。

因此，企業或組織想將地端資料中心內的 VM 虛擬主機，遷移至 Azure 公有雲環境運作時，傳統作法便是在 Azure 公有雲環境中，部署全新安裝的 VM 虛擬主機，接著依照 VM 虛擬主機的屬性，將相關資料進行複寫後運作（如圖 1 所示）。

圖 1、Azure Migrate 遷移探索機制工作流程架構示意圖
圖片來源： Azure Migrate 設備 - Azure Migrate | Microsoft Learn

現在，透過 Azure Migrate 遷移機制，即可將地端資料中心內，VMware vSphere 伺服器虛擬化平台中的 VM 虛擬主機，經過「探索、評估、測試」等工作流程後，即可遷移至 Azure 公有雲環境繼續運作（如圖 2 所示）。
在 VMware 虛擬化環境中，Azure Migrate 設備可探索最多 10,000 台 VM 虛擬主機。
圖 2、VMware 環境無代理程式遷移架構示意圖
圖片來源： 使用 Azure Migrate 準備機器以進行無代理程式遷移 - Azure Migrate | Microsoft Learn





實戰 – 遷移 VMware VM 至 Azure 公有雲

在實戰演練小節，將會在地端資料中心 VMware 虛擬化平台中，透過 Azure Migration 遷移機制，逐步將一台安裝 Windows Server 2022 作業系統，並啟用 IIS 網頁伺服器的 VM 虛擬主機，遷移至 Azure 公有雲環境中運作。

由於遷移地端 VM 虛擬主機至 Azure 公有雲，將會使用到網路頻寬進行傳輸作業，為避免過多的等待時間，因此僅遷移一台 VM 虛擬主機為範例。目前，在地端 VMware 虛擬化平台中，運作一台名稱為 WS2022-IIS 的虛擬主機，該主機已經啟用 IIS 網頁伺服器服務（如圖 3 所示）。

圖 3、地端資料中心內 VM 虛擬主機並啟用 IIS 網頁伺服器服務



建立 Azure Migrate 專案

請登入 Azure Portal 管理介面，關鍵字搜尋「Azure Migrate」，並依序點選「Migration goals > Servers，databases and web apps > Create project」。

在 Create project 頁面，請選擇 Azure 訂閱帳戶，並填入 Azure Migrate 專案資訊後（如圖 4 所示），按下 Create 鈕建立 Azure Migrate 專案：
  • Subscription： 選擇使用的 Azure 訂閱帳戶。
  • Resource group： 選擇使用的資源群組。
  • Project： 鍵入即將建立的 Azure Migrate 專案名稱。
  • Geography： 選擇使用的地理位置。這個地理位置，用來儲存從地端資料中心內收集到的「中繼資料」（Metadata）。
圖 4、建立 Azure Migrate 專案



探索 VMware 虛擬化平台

事實上，Azure Migrate 遷移機制，將在地端資料中心 VMware 虛擬化平台中，導入 Azure Migrate Appliance 執行探索作業，並將 VMware 組態設定及運作效能等中繼資料，收集後傳送至 Azure 公有雲的 Azure Migrate 專案。

在開始執行遷移作業之前，必須先確保地端 VMware 虛擬化平台，屆時能順利跟 Azure 公有雲溝通，管理人員可以透過 Microsoft 下載中心，下載「MicrosoftAzureMigration.ova」，即可快速並逐一檢查 VMware 虛擬化平台是否符合條件，以便稍後能順利執行 探索 VMware 虛擬化平台  的工作任務。

請切換至 Azure Portal 管理介面，在 Azure Migrate 頁面依序點選「Migration goals > Servers，databases and web apps > Assessment tools > Azure Migrate: Discovery and assessment」項目後，請按下 Discover 鈕。

在 Discover 視窗中，詢問採用的虛擬化技術為何，在下拉式選單中共有三個選項，分別是 VMware vSphere、Hyper-V、實體主機或 AWX/GCP/Xen。在本文實作環境中，請選擇「Yes，with VMware vSphere Hypervisor」選項，選擇後將自動出現 Azure Migrate Appliance 資訊頁面。

在第 1 個 Generate project key 選項中，請提供稍後準備部署至地端資料中心內 Azure Migrate Appliance 的名稱，本文使用名稱為「AzureMA-VMware」，按下 Generate key 鈕即可產生金鑰，產生 Azure Migrate 專案金鑰的動作，需要花費幾分鐘的時間，當 OVA 部署作業完成後，必須要在 Azure Migrate Appliance 運作頁面中，填入這個隨機產生的專案金鑰才能完成註冊程序。

在第 2 個 Download Azure Migrate appliance 選項中，選擇下載「.OVA file」選項，直接下載 Azure Migrate Appliance 的 .OVA 檔案（12 GB），並匯入地端 VMware 虛擬化平台中，或是下載「.zip file」選項，使用 PowerShell 安裝程式指令碼，本文實作下載 OVA 檔案請按下 Download 鈕（如圖 5 所示）。

圖 5、產生 Azure Migrate 專案金鑰並下載 Azure Migrate Appliance 部署檔案

OVA 檔案下載完成，在開始執行 OVA 匯入作業之前，請先在 PowerShell 視窗中執行「CertUtil -HashFile .\ MicrosoftAzureMigration.ova SHA256」指令，確保使用 SHA256 驗證 OVA 檔案雜湊的完整性，避免下載到被竄改的檔案產生非預期的惡意攻擊或資安事件，確認無誤後即可切換至 vCenter Server 操作介面，執行匯入 OVA 檔案的工作任務。
OVA 檔案的正確 SHA256 雜湊值後十碼字元為 2D3A2F4723。

在地端資料中心內部署 Azure Migrate Appliance 之前，請先確保 VMware 虛擬化平台，能夠滿足部署條件，採用 Windows Server 2022 作業系統，將會自動配置 8 vCPU、32GB vMemory、80GB vDisk 磁碟空間。

在 vCenter Server 管理介面中，請依序點選「vCenter > Datacenter > Cluster > Actions > Deploy OVF Template」項目，在 Select an OVF template 彈出視窗中，請點選 Local file 並選擇剛才下載的 MicrosoftAzureMigration.ova 檔案後，按下 Upload Files 鈕進行上傳作業。

在 Select a name and folder 頁面中，請選擇要將 Azure Migrate Appliance，存放至哪個 VM 資料夾當中，本文存放至 Azure Migration Appliance 資料夾內，在 Select a compute resource 頁面中，選擇要部署至 Cluster 或哪一台 ESXi 虛擬化平台中，在 Review details 頁面中查看 Azure Migrate Appliance 資訊是否正確，在 Select storage 頁面中，選擇採用的 vDisk 格式和 Datastore 儲存資源，在 Select networks 頁面，選擇連接的 vNetwork 和 Port Group，最後在 Ready to complete 頁面中，再次確認相關組態設定是否正確，確認無誤後按下 Finish 鈕，正式執行匯入 Azure Migrate Appliance 的工作任務。

成功匯入並啟動 Azure Migrate Appliance 虛擬主機後，請先組態設定管理者密碼、時區、IP 位址……等基本設定，最重要的則是電腦名稱的部份，請採用剛才產生 Azure Migrate 專案金鑰的「AzureMA-VMware」，組態設定電腦名稱後重新啟動主機。

重新啟動完成後，點選桌面上的「Azure Migrate Appliance Configuration Manager」捷徑，系統將自動開啟瀏覽器連線使用 HTTPs 至 Port 44368，並進入至 Appliance Configuration Manager 初始化組態設定頁面，並且檢查及確認是否能夠連線存取 Azure 公有雲，以及檢查主機時間是否與網際網路時間同步，後續的探索作業才能正常運作（如圖 6 所示）。

圖 6、Appliance Configuration Manager 初始化組態設定頁面

值得注意的是，倘若由別台主機開啟瀏覽器，連線至 Azure Migrate Appliance 虛擬主機的 Port 44368 時，必須先鍵入主機的管理者帳號和密碼，通過使用者身份驗證程序後，才能看到 Appliance Configuration Manager 初始化組態設定頁面。

在初始化組態設定頁面，於 1. Set up prerequisites 階段中，第 3 個步驟 Check latest updates and register appliance 中，請將剛才產生的 Azure Migrate 專案金鑰填入後，按下 Verify 鈕進行驗證程序，通過驗證程序後系統將會顯示「Azure Migrate project key has been verified.」訊息。接著，系統自動執行更新服務，確保所有服務更新至最新版本，原則上這個自動更新作業需要 5 分鐘，更新作業完成後，系統將彈出視窗提醒重新整理頁面，以便載入自動更新後的新版本。

自動更新工作任務完成後，必須將 Azure Migrate Appliance 註冊至 Azure Migrate 專案中，請按下 Login 鈕複製主機裝置代碼，搭配 Azure 訂閱帳戶進行登入作業程序，系統會提示順利登入 Microsoft Azure PowerShell 環境，接著系統將會顯示正在執行 Azure Migrate Appliance 初始化註冊程序，系統提示這個初始化註冊程序需要 10 分鐘，一旦初始化註冊程序完成後，便能點選 View details 查看詳細的登入資訊（如圖 7 所示）。

圖 7、鍵入 Azure Migrate 專案金鑰執行自動更新並初始化註冊程序

在第 4 個步驟中，系統提示必須下載 VMware Virtual Disk Development Kit 6.7.0 EP1 壓縮檔，解開後複製至 Azure Migrate Appliance 主機中，「C:\Program Files\VMware\VMware Virtual Disk Development Kit」資料夾中，然後回到 Appliance Configuration Manager 初始化組態設定頁面，按下 Verify 鈕進行驗證程序（如圖 8 所示）。

圖 8、檢查主機是否安裝 VMware Virtual Disk Development Kit

在 2. Manage credentials and discovery sources 頁面中，首先第 1 個步驟，需要提供地端 VMware 虛擬化平台的管理資訊，請按下 Add credentials 鈕，在視窗中請依序填入下列 VMware 主機或叢集的管理者帳號及密碼，以便系統稍後使用這個管理者憑證執行探索伺服器或叢集的動作（如圖 9 所示）：
  • Source type： vCenter Server，選擇這個使用者身份驗證設定檔適用的來源類別。
  • Friendly name： vCenter8，組態設定使用者身份驗證設定檔名稱。
  • Username： Administrator@lab.weithenn.org，管理者帳號。
  • Password： WeithennAMA$1688，管理者密碼。
圖 9、新增連線 vCenter 8 Server 管理平台的使用者身份驗證設定檔

在第 2 個步驟中，按下 Add discovery source 鈕，在彈出視窗中鍵入 vCenter Server 的 IP 位址或 FQDN 完整名稱，以便連線至地端資料中心 VMware 虛擬化平台，一旦使用者身份驗證成功後，在 Status 狀態欄位便會顯示 Validation successful 訊息（如圖 10 所示），倘若管理者帳號密碼錯誤，或是無法連線至 vCenter Server Port 443 時，便會發生驗證失敗的情況：
  • Discovery source： vCenter Server，選擇稍後執行探索任務的來源。
  • IP Address/FQDN： vcenter8.lab.weithenn.org，組態設定 vCenter Server 連線 IP 位址或 FQDN。
  • Port： 443，連線 vCenter Server 管理平台的 Port number。
  • Map credentials： vCenter8，選擇使用的身份驗證設定檔。
圖 10、成功連線至 vCenter Server 管理平台

在第 3 個步驟中，管理人員可以提供其它使用者驗證資訊，以便稍後執行軟體清查和無代理程式相依性分析，總共支援 4 種使用者驗證資訊，分別是 Domain Credentials、Linux （Non-domain）、Windows（Non-domain）、SQL Server Authentication，舉例來說，準備遷移的 Windows Server 主機未加入網域環境，即可建立 Windows（Non-domain）的使用者驗證設定檔。現在，請按下最下方的 Start Discovery 鈕，系統便開始執行偵測和探索程序，在本文實作環境中，系統提示需要 16 分鐘即可完成探索程序（如圖 11 所示）。

圖 11、開始執行偵測和探索程序

當系統完成探索 VMware 主機或和叢集環境後，由於執行探索程序時，系統將會取得 VMware 主機中繼資料，屆時便會將探索完成的資料，顯示在 Azure Portal 入口網站當中。預設情況下，探索和偵測每台 VMware 主機大約需要花費 2 分鐘時間，並且每隔 12 小時會自動執行一次軟體清查作業，之後才會顯示在 Azure Portal 入口網站。

此外，在軟體清查期間，將會透過剛才所新增的伺服器認證逐一探索指定的 VMware 主機或叢集，並針對無代理程式相依性分析進行驗證。當探索和偵測作業完成後，系統會在 vCenter Server 主機的 Status 欄位狀態，從先前的 Validation successful 狀態改為 Discovery Initiated 狀態，在 Start Discovery 鈕旁，顯示探索完成的 Discovery has been successfully initiated 訊息，並提醒管理人員可以前往 Azure Portal 入口網站，查看詳細的探索資訊。



評估遷移至 Azure 公有雲

請在 Azure Portal 入口網站中，依序點選「Azure Migrate > Migration goals > Servers，databases and web apps > Assessment tools > Assess > Azure VM」項目，評估是否能將進行地端 VM 虛擬主機，遷移至 Azure 公有雲環境（如圖 12 所示）。

圖 12、評估地端 VM 虛擬主機是否能遷移至 Azure 公有雲環境

在第一階段 Basics 頁面中，評估類型下拉選單請選擇「Azure VM」項目，而探索來源下拉選單請選擇「Servers discovered from Azure Migrate appliance」項目，確保要進行評估的 VM 虛擬主機，是從地端的 Azure Migrate appliance 執行探索任務而來（如圖 13 所示）。

圖 13、建立準備遷移地端 VM 虛擬主機的評估作業

管理人員可以查看評估組態設定內容是否符合需求，倘若需要調整組態設定內容時，可以點選 Assessment settings 旁的 Edit，以便符合遷移需求：
  • Target location： 選擇要將 VM 虛擬主機遷移至哪個 Azure 資料中心，本文實作為 Southeast Asia。
  • Storage type： 選擇遷移的 Azure VM 虛擬主機，採用哪種虛擬硬碟類型，管理人員可依據 IOPS 儲存效能進行選擇，本文實作選擇 Premium SSD 和 Standard SSD 等級的虛擬硬碟類型。
  • Savings options（Compute）： 選擇採用的節省費用選項，可以採用 1 年或 3 年的 Azure 保留資源方案，或者是 1 年和 3 年的 Azure 節省費用方案，管理人員可依據 VM 虛擬主機的效能和工作負載，考量後選擇適合的節費方案即可。
  • Sizing criteria： 選擇採用效能為主或依照地端部署進行評估作業。
  • Performance-based： 採用效能為主進行評估作業時，系統會根據探索作業中收集到的 VM 虛擬主機效能資料進行評估，採用的 Azure VM 規模大小和 IOPS 儲存效能，並且選擇 Performance history 效能歷史資料週期，例如，1 天、1 週、1 個月，以及 Percentile utilization 使用率百分比，例如，50%-99%，預設值為 95%。
  • As on-premises： 直接使用 VM 虛擬主機的組態設定，選擇和 Azure VM 規模大小和 IOPS 儲存效能相近的規格。
  • VM series： 選擇採用的 Azure VM 規模和系列，例如，僅考量價格便宜的 A 和 B 系列，或僅考量記憶體最佳化的 E 和 M 系列的規模大小，預設值為選取所有適用的 VM 系列。
  • Offer/Licensing program： 選擇 Azure 付費方案，例如，個人使用的 Pay-As-You-Go，或企業授權 EA 支援方案。
  • Currency： 選擇 Azure 訂閱帳戶中，支付費用的貨幣，預設值為 US Dollar （ $ ）。
  • VM uptime： 填入屆時 Azure VM 的運作時間，預設為每個月 31 天，每天 24 小時。
  • Already have a Windows Server license： 選擇是否已經具備 Windows Server 軟體授權。
  • Security： 預設選擇為遷移後的 VM 虛擬主機，安裝 Microsoft Defender for Cloud。

在 2. Select servers to assess 頁面中，請在評估名稱欄位填入評估作業名稱和群組名稱，本文實作範例中，由於針對地端 IIS 網頁伺服器進行遷移，使用「VMware-IIS-AzureMigration」為評估名稱，以「Group-IIS-VMs」為群組名稱，勾選欲進行評估作業的地端 VM 虛擬主機（如圖 14 所示）。在 3. Rreview + create assessment 頁面中，再次檢視組態設定值內容，確認無誤後按下 Create assessment 鈕，系統立即進行 Azure VM 的評估和遷移工作任務。

圖 14、建立評估作業名稱和群組，並勾選準備評估的地端 VM 虛擬主機

一旦評估作業完成後，點選 Assessment Tools 區塊內的「Overview」選項，可以看到目前評估的 VM 虛擬主機數量為 1 台（如圖 15 所示），點選 Manage 下的 Assessments 選項，將會顯示遷移至 Azure VM 虛擬主機的建議評分，建議評分從最低的 1 顆星到最高的 5 顆星，評分越高代表遷移至 Azure 公有雲環境的可行性越高。

圖 15、查看地端 VM 虛擬主機評估作業結果

點選評估名稱在 Overview 頁面中，可以看到遷移至 Azure 環境的成本估算和概要資訊，點選左側 Azure readiness 項目，可以看到根據各項效能資料的分析後，遷移至 Azure 公有雲環境環境，只需採用「Standard_D1_v2」的 Azure VM 規模大小即可。值得注意的是，在先前評估作業中，選擇採用地端選項時，這裡便會建議採用「4 vCPU / 16GB vRAM」規格的 Azure VM 規模大小。

點選左側的 Cost details 項目，可以看到分析及建議採用的 Azure VM 規模大小，每月花費估算成本為多少費用，當評估的 VM 虛擬主機數量眾多時，可以按下 Export assessment 鈕，將評估作業結果匯出為 Excel 檔案（如圖 16 所示）。

圖 16、查詢遷移至 Azure 公有雲後各項建議和成本估算



無代理程式遷移

事實上，針對地端 VMware 虛擬化環境的遷移作業，提供二種遷移方式，分別是「無代理程式」（Agentless）和「代理程式」（Agent-Based）。在本文實作中，將採用無代理程式的方式，來遷移地端 VM 虛擬主機，但是在遷移過程期間無須在 VM 虛擬主機內，安裝任何代理程式即可達到，而這種方式通常也更符合企業和組織的需求。

請在 Azure Migrate 頁面中，點選 Migration tools 內的 Discover 項目。首先，選擇「Yes，with VMware vSphere Hypervisor」項目，在詢問複寫方式時選擇「Using agentless replication」，由於已經部署 Azure Migration Appliance，所以選擇「Scale-out an existing primary appliance」即可，並選擇部署好的「AzureMA-VMware」。在產生遷移專案金鑰時，加上擴充 Azure Migration Appliance 的名稱後，按下 Generate key 鈕產生專案金鑰後，即可按下 Download 鈕，下載 Azure Migration Scale-Out Appliance （如圖 17 所示）。

圖 17、產生並下載 Azure Migration Scale-Out Appliance

下載解壓縮執行「AzureMigrateInstaller.ps1」後，在 PowerShell 視窗中顯示互動對話內容，管理人員依照環境回答，即可順利部署 Azure Migration Scale-Out Appliance，例如，採用的虛擬化技術、採用的 Azure 公有雲環境……等（如圖 18 所示）。在初始化頁面中，由於跟之前組態設定 Azure Migration Appliance 的步驟非常類似，所以便不再贅述，重點在於成功註冊至 Azure 公有雲環境即可。

圖 18、安裝和部署 Azure Migration Scale-Out Appliance



複寫至 Azure 公有雲

請在 Azure Portal 入口網站中，點選 Migration tools 中的 Replicate 項目，在 Specify intent 頁面中採用預設值即可，進入新的頁面，在 1.Basics 頁面中選擇 Yes，with Vmware vSphere 選項，並選擇剛才部署的 Azure Migration Scale-Out Appliance，在 2.Virtual machines 頁面中，選擇先前建立的「Group-IIS-VMs」群組，並勾選本文實作複寫的「IIS-WS2022」VM 虛擬主機。

在 3. Target settings 頁面中，選擇使用的 Azure 訂閱帳戶、資源群組、儲存體帳戶、虛擬網路……等資訊，以便屆時儲存複寫地端 VM 虛擬主機時的相關資訊。在 4. Compute 頁面中，填入 Azure VM 名稱、VM Size、OS Type……等資訊。在 5. Disks 頁面中，選擇地端 VM 虛擬主機中，需要複寫到 Azure VM 的磁碟。在 6. Tags 頁面中，填入名稱和值等 Tag 設定以便後續管理作業。最後，再次檢視組態設定是否正確無誤，確認後按下 Replicate 鈕執行複寫作業（如圖 19 所示）。

圖 19、複寫地端 VM 虛擬主機至 Azure 公有雲環境

開始執行複寫工作任務後，可以在 Azure Portal 入口網站，看到複寫資料的進度百分比（如圖 20 所示），或是地端 vCenter管理介面 Recent Tasks 中，看到重新組態設定 VM 虛擬主機，建立 VM 虛擬主機快照……等。

圖 20、複寫地端 VM 虛擬主機至 Azure 公有雲環境



遷移測試

一旦複寫完成後，在正式遷移到 Azure 公有雲運作之前，管理人員可以先執行測試遷移，以便確定遷移後 VM 能夠順利在 Azure 公有雲環境中正常運作。

請按下 Test Migration 鈕，選擇 Azure VM 在遷移後所要使用的 Azure 虛擬網路，一旦測試遷移運作後，會看到 Azure VM 尾碼有「-Test」字樣，便是測試遷移的 Azure VM 虛擬主機，確認 Azure VM 運作正常時，選擇 Clean up test migration 即可（如圖 21 所示）。

圖 21、測試遷移並清除測試遷移 VM 虛擬主機



遷移至 Azure 公有雲

現在，可以放執行遷移地端 VM 虛擬主機至 Azure 公有雲的動作。請勾選複寫 VM 虛擬主機清單中，確認進行遷移的 VM 虛擬主機後，按下 Migrate 鈕，並選擇「關閉」（Shutdown）地端 VM 虛擬主機，以避免在遷移期間資料不同步的情況發生。

當遷移狀態轉換為 planned failover finished 時，便是遷移程序執行完畢。確認能夠正常運作並看到 IIS 網頁後（如圖 22 所示），記得按下 Stop replication 停止複寫程序，讓複寫資源可以釋放給其它 VM 虛擬主機使用。此外，倘若需要 Public IP 進行存取的話，也僅需要建立 Public IP 後與 VM 虛擬主機進行關聯即可。

圖 22、順利將地端 VM 虛擬主機遷移至 Azure 公有雲繼續運作





結語

透過本文的深入剖析和實作演練後，除了理解 Azure Migrate 運作原理和架構之外，透過實作演練的方式，讓企業或組織能夠評估，地端資料中心內的 VMware VM 虛擬主機，是否能夠遷移並正確運作在 Azure 公有雲環境中。
↧

Cluster name and external ip address | Nutanix CE

February 19, 2024, 1:30 pm
$
0
0


簡介

預設情況下，當 Nutanix Cluster 運作後，叢集名稱 (Cluster Name) 為「Unnamed」，並且沒有 External IP 位址。有關建構 Nutanix Cluster 的內容，請參考下列二篇站內文章：

本文，將參考下列二篇官網文章，說明如何組態設定這二個叢集組態：



查看 Cluster 組態設定和相關資訊

管理人員可以執行「ncli cluster status」、「ncli cluster info」、「ncli cluster version」等指令，查看 Cluster 組態設定和相關資訊。舉例來說，執行 ncli cluster info 指令，即可看到目前的 Cluster 名稱為預設的「Unnamed」。






組態設定 Cluster Name 和 External IP Address

執行「ncli cluster edit-params new-name=ntnx-cluster」指令，組態設定 Cluster 名稱為「ntnx-cluster」，屆時的 FQDN 將為 ntnx-cluster.lab.weithenn.org。


目前，管理人員可以從任一台 CVM IP 位址，連線至 Prism Element 管理介面，可以執行「ncli cluster set-external-ip-address external-ip-address="10.10.75.20"」指令，組態設定 Cluster 的 External IP 位址為「10.10.75.20」，之後就統一使用這個 Cluster External IP 位址即可。


在連線 Prism Element 管理介面之前，可以使用「nc -vz 10.10.75.20 9440」指令，確認 Cluster External IP 位址已正確運作。


現在，即可使用 Cluster External IP 位址 (10.10.75.20)，或剛才組態設定的 Cluster Name (ntnx-cluster.lab.weithenn.org)，連線至 Prism Element 管理介面。



順利登入 Prism Element 管理介面後，可以看到剛才組態設定的 Cluster Name 已正確顯示。此外，可以看到 Critical Alters 有些待解決的問題，在之後的文章會逐一說明並解決。


事實上，也可以直接點選 Cluster Name 進行組態設定，當然也可以順便填入 Cluster FQDN 名稱。


但是，目前 AHV / CVM 的 DNS Server 尚未組態設定，所以嘗試儲存組態設定時系統告知問題且無法儲存後，在下一篇文章便會說明如何組態設定 AHV / CVM 的 DNS Server，屆時再組態設定和儲存即可。


↧
Viewing all 591 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>