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

網管人 201 期 - 實作 Hyper-V 2019,善用 WAC 遠端管理

$
0
0


網管人雜誌

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





本文目錄






前言

隨著新版 Windows Server 2022 雲端作業系統的發佈,依照過往版本釋放的步調來看,應該過一陣子後便會發佈,伺服器虛擬化平台版本且可免費使用的 Hyper-V Server 2022。然而,管理人員應該已經發現,在微軟官方網站上,似乎找不到任何有關 Hyper-V Server 2022 的相關資訊。

事實上,過去的 Hyper-V Server 主要用途,為企業和組織地端資料中心的伺服器虛擬化平台,然而在整個虛擬化平台的規劃設計方面,並沒有考慮到現代化應用和混合雲的需求,這也正是為何微軟推出 Azure Stack HCI版本,以便符合企業和組織打造伺服器虛擬化、容器、超融合、混合雲……等需求。
有關 Azure Stack HCI 規劃設計和運作架構的詳細資訊,請參考本刊雜誌「第 195 期第 187 期第 183 期」內容。
因此, 微軟已經說明,傳統用於地端資料中心單純提供伺服器虛擬化的 Hyper-V Server 產品,最後一代的版本便是 Hyper-V Server 2019,其主要支援日期至 2024 年 1 月,而延伸支援則至 2029 年 1 月(如圖 1 所示),目的就是讓原本使用 Hyper-V Server 的企業和組織,能有更多時間過渡到 Azure Stack HCI平台。

圖 1、Hyper-V Server 2019 主要支援和延伸支援到期日

對於不熟悉 Hyper-V 虛擬化技術的管理人員可能會有疑問,採用 GUI 圖形介面的 Windows Server 2022 或 2019 並啟用 Hyper-V 角色,和本文介紹的 Hyper-V Server 2019 之間有哪些差異? 簡單來說,Windows Server 支援許多特色功能和伺服器角色,而 Hyper-V Server 2019 則僅專注於 Hyper-V 虛擬化功能。

對於 Windows Server 效能調校熟悉的管理人員應知,倘若希望 Windows Server 能夠進一步提升運作效能時,可以採用僅文字介面進行操作的 Server Core 模式。主要原因在於,去除 GUI 圖形介面的 Server Core 模式,除了整體運作效能大幅提升之外,在安全性更新數量方面將會「減少 40% - 60%」,連帶提升主機整體安全性。

相較於 Server Core 模式來說,Hyper-V Server 2019 則是更為精簡的版本,因為在 Hyper-V Server 2019 伺服器虛擬化平台中,僅支援 Hyper-V 伺服器角色,不支援安裝其它伺服器角色,例如,IIS、DNS、DHCP……等,也因為這樣的特性所以最適合用於運作 Hyper-V 伺服器虛擬化平台。

此時,管理人員可能會擔心,精簡版本的 Hyper-V Server 2019,在硬體裝置支援方面是否會有不足的情況產生? 簡單來說,Hyper-V Server 中已經內建 Windows Server Driver Model,因此只要能夠安裝 Windows Server 的硬體伺服器,也能順利安裝 Hyper-V Server 並正確識別所有硬體裝置。

雖然,Hyper-V Server 伺服器虛擬化平台,為可免費使用的 Hypervisor 虛擬化平台,然而在虛擬化功能方面,與啟用 Hyper-V 角色的 Windows Server 則完全相同,完整支援即時遷移(Live Migration)、儲存即時遷移(Storage Live Migration)、儲存複寫(Storage Replica)……等虛擬化進階功能(如圖 2 所示)。

圖 2、延展式叢集啟用儲存複寫機制示意圖

值得注意的是,所謂企業和組織可以「免費」使用 Hyper-V Server,是指 Hyper-V Hypervisor 虛擬化平台的部份,然而其上運作的 VM 虛擬主機客體作業系統,倘若為 Windows Server 或其它需要軟體授權的 Linux 作業系統,則仍需要購買作業系統軟體授權才行。





實戰演練 – Hyper-V Server 2019

原則上,Hyper-V Server 2019 的安裝流程,與管理人員安裝 Windows Server 流程相同。當管理人員下載 Hyper-V Server 2019 映像檔後,將 ISO 製作成可開機 USB 隨身碟,或透過硬體伺服器 IPMI Virtual Media 功能,將 ISO 映像檔掛載成為硬體伺服器光碟機後,即可進行 Hyper-V Server 2019 的安裝作業(如圖 3 所示)。

圖 3、Hyper-V Server 2019 安裝流程和 Windows Server 相同

當 Hyper-V Server 2019 安裝完成後,首次登入 Hyper-V Server 時,系統將會要求設定 Administrator 管理者密碼,順利登入 Hyper-V Server 後,整個操作體驗其實和 Server Core 版本相同,也就是不支援 GUI 圖形介面僅支援文字管理介面,登入系統後將會自動開啟二個視窗,分別是 Cmd 命令提示字元和 Server Configuration Tool(如圖 4 所示)。

圖 4、Hyper-V Server 2019 登入後僅支援文字模式操作



查詢 Hyper-V Server 軟體授權資訊

再次提醒管理人員,所謂可免費使用 Hyper-V Server,是指 Hyper-V 虛擬化平台的部份,而 VM 虛擬主機倘若運作需要軟體授權的作業系統時,仍然需要購買相關軟體授權才行。

管理人員可以在登入畫面中,切換到 Cmd 命令提示字元視窗,鍵入「slmgr.vbs -dli」或「slmgr.vbs -dlv」指令即可查詢,從查詢結果可以看到,安裝好的 Hyper-V Server 在軟體授權狀態方面,License Status 欄位值為 Licensed 也就是已授權狀態(如圖 5 所示)。

圖 5、可免費使用的 Hyper-V Server 伺服器虛擬化平台



攻擊面小安全性高的 Hyper-V Server

由於 Hyper-V Server 僅專注於提供 Hyper-V 伺服器虛擬化功能,並且拿掉 GUI 圖形介面僅剩文字介面,因此在預設情況下開啟的網路連接埠數量更少,所以能達到遭受惡意攻擊面縮小安全性提升的好處。

請切換至 Cmd 命令提示字元視窗,鍵入「netstat -nao」指令並配合工作管理員,查詢使用該通訊連接埠相對應的 PID 程序(如圖 6 所示),即可得知 Hyper-V Server 預設啟用的執行程序情況。下列為相關通訊連接埠號說明:
  • TCP 135、49665、49666 / UDP 123、5353、5355: svchost.exe(Windows Services 主機處理程序)
  • TCP 139、445、5985、47001 / UDP 137、138: System(NT Kernel & System)
  • TCP 2179: vmms.exe(VM 虛擬主機管理服務)
  • TCP 49664: wininit.exe(Windows啟動應用程式)
  • TCP 49667: services.exe(服務及控制站應用程式)
  • TCP 49669: lsass.exe(本機安全性認證處理程序)
圖 6、Hyper-V Server 2019 預設開啟的通訊連接埠號



Hyper-V Server 基礎設定

預設情況下,當 Hyper-V Server 主機啟動完成後,將會自動啟動 DHCP Client 網路功能,嘗試尋找所處區域網路中,是否有 DHCP 伺服器派發 IP 位址和相關網路組態。

同時,管理人員也可以透過內建的 Server Configuration Tool,透過文字互動方式組態設定 Hyper-V Server 網路組態。本文實作環境中,將組態設定 Hyper-V Server 主機,採用「10.10.75.19」固定 IP 位址,並且指定 DNS 伺服器 IP 位址為「10.10.75.10」。

首先,請在 SConfig 視窗中,鍵入數字「8」選擇「Network Settings」項目,進入文字互動設定頁面後,系統會條列出本機所有的網路卡,倘若有配置多張網路卡時,請透過網路卡的「Index# ID」,選擇指定的實體網路卡進行網路組態設定。

本文實作環境中,Hyper-V Server 主機僅配置一張網路卡,請依序鍵入「1 > 1 > S > 10.10.75.19 > 255.255.255.0 > 10.10.75.254」,組態設定固定 IP 位址、子網路遮罩、預設閘道。接著,鍵入「2 > 10.10.75.10」組態設定 DNS 伺服器 IP 位址。最後鍵入數字「4」,即可回到 SConfig 主選單。

在電腦名稱的部份,預設情況下系統會自動採用「WIN- 亂數」的命名規則,然而預設亂數的電腦名稱,通常不具識別性也不符合企業或組織的主機命名規則。管理人員需要變更 Hyper-V Server 主機的電腦名稱時,請在 SConfig 視窗中,鍵入數字「2」選擇「Computer Name」項目,鍵入「HV2019」新電腦名稱,此時系統將會彈出視窗,提醒管理人員必須重新啟動主機才能套用生效,按下「Yes」鈕便立即重新啟動主機,當 Hyper-V Server 順利重新啟動後,登入後即可發現新的電腦名稱已經套用生效(如圖 7 所示)。

圖 7、變更 Hyper-V Server 電腦名稱



Hyper-V Server 加入網域環境

原則上,Hyper-V Server 主機,必須加入 Windows AD 網域後,才能建構 Hyper-V 高可用性容錯移轉叢集並實作進階功能,例如,Live Migration 即時遷移……等。倘若,企業和組織只是希望透過 Hyper-V Server 主機,單純運作 VM 虛擬主機並且不需要相關進階功能時,則無須加入 Windows AD 網域環境。

即便管理人員選擇不將 Hyper-V Server 加入 Windows AD 網域環境,那麼也應該保持良好的管理習慣,請避免使用預設的 Administrator 管理帳號,進行 Hyper-V Server 主機的日常維護工作,而是新增其它管理者帳號後,將預設 Administrator 管理帳號停用,以降低遭受惡意攻擊的機會,例如,知道預設管理帳號為 Administrator 之後,剩下就是透過暴力密碼猜測工具破解管理員密碼了。

請在 SConfig 視窗中,鍵入數字「3」選擇「Add Local Administrator」項目,鍵入新的管理者帳號,本文實作為「Weithenn」,當新增管理者帳號名稱輸入完畢後,系統將彈出管理密碼設定視窗,請鍵入二次管理者密碼,此時系統將會自動把新增的管理者帳號,加入至 Administrators 管理者群組內。

請切換至 Cmd 命令提示字元視窗中,鍵入「net user Weithenn」指令,查詢剛才新增的管理者帳號 Weithenn,在 Local Group Memberships 欄位,是否顯示為「Administrators」管理者群組的成員(如圖 8 所示)。

圖 8、新增管理者帳號 Weithenn 並確認已加入 Administrators 管理者群組

此時,請登出 Hyper-V Server 主機,改為採用剛才新增的管理者帳號 Weithenn 登入。確認管理者帳號新增完成,並且能夠順利登入並管理 Hyper-V Server 主機後,即可將預設 Administrator 帳號,進行「停用」(Disable)的動作。

請在 Cmd 命令提示字元視窗中,鍵入「net user Administrator /ACTIVE:NO」指令停用帳號,然後再次鍵入「net user Administrator」指令,查詢預設的 Administrator 管理帳號資訊,可以看到「Account active」欄位值為「No」,表示成功停用預設 Administrator 管理者帳號。

在本文實作環境中,將 Hyper-V Server 主機加入「lab.weithenn.org」網域環境。請在 SConfig 視窗中,依序鍵入「1 > D > lab.weithenn.org > lab.weithenn.org\Administrator > 網域管理者密碼」,加入 lab.weithenn.org 網域環境,此時系統將會彈出視窗,提醒管理人員必須重新啟動主機才能套用生效,按下「Yes」鈕便立即重新啟動主機,當 Hyper-V Server 順利重新啟動後,即可採用網域帳號登入進行管理作業(如圖 9 所示)。

圖 9、使用網域帳號登入 Hyper-V Server 進行管理作業

由於加入網域後,預設情況下,Hyper-V Server 主機將會自動啟用,並且套用「Domain」網卡防火牆規則。因此,預設情況下區域網路中的其它主機,並無法 ping 到 Hyper-V Server 主機,管理人員可以透過「Set-NetFirewallProfile」的 PowerShell 指令,或是透過 SConfig 允許回應 ping 的防火牆規則,當然後續也可以透過 WAC(Windows Admin Center)管理工具調整防火牆規則。
預設防火牆規則為「阻擋進入」(Block Inbound),「允許流出」(Allow Outbound)網路封包。
請在 SConfig 視窗中,鍵入數字「4」,選擇「Configure Remote Management」項目,鍵入數字「3」,選擇「Configure Server Response to Ping」項目,並於彈出視窗按下「Yes」鈕,即可允許 Hyper-V Server 主機回應 ping 封包。



電源設定為高效能

預設情況下,Windows Server 主機的電源設定為「平衡」(Balanced),即便是 Hyper-V Server 也不例外,然而這樣的預設值,可能造成屆時其上運作的 VM 虛擬主機,必須等待一小段時間,待 Hyper-V Server 提升電源和運算能力後,才能夠快速回覆使用者請求,導致使用者會感覺到 VM 虛擬主機運作上卡卡的。

因此,管理人員應該將 Hyper-V Server 主機,在硬體伺服器的 BIOS/UEFI 設定中,將電源管理項目中調整至「Max Performance」設定值,然後登入 Hyper-V Server 主機中,透過「powercfg /setactive」指令取得「Power Scheme GUID」後,將 Hyper-V Server 主機的電源設定,調整為「高效能」(High Performance),確保在硬體伺服器層級和 Hyper-V Server 作業系統層級相互搭配的情況下,發揮主機最大化的運算效能(如圖 10 所示)。

圖 10、調整 Hyper-V Server 電源設定至高效能



其它 SConfig 選項

原則上,在 SConfig 組態設定選項中,其它選項因為功能直覺且設定簡單,便不再細項逐一操作。請參考下列其它組態設定選項功能描述:
5) Windows Update Settings: 組態設定 Windows 安全性更新方式。
6) Download and Install Update: 是否立即下載和安裝 Windows 安全性更新。
7) Remote Desktop: 啟用 RDP 遠端桌面連線功能。
9) Date and Time: 組態設定系統日期和時間。
10) Telemetry settings: 組態設定遙測機制等級。
11) Log Off User: 執行使用者登出。
12) Restart Server: 執行主機重新啟動。
13) Shut Down Server: 執行關機作業。
14) Exit to Command Line: 離開 Server Configuration Tool 模式,回到命令提示字元。

此外,當管理人員不小心,將 Hyper-V Server 內命令提示字元和 SConfig 視窗都關閉時,只要按下「Ctrl + Alt + Delete」組合鍵,選擇「Task Manager」開啟工作管理員,在工作管理員視窗中,點選「File > Run new task」後,鍵入「cmd」即可開啟命令提示字元,鍵入「powershell」即可開啟 PowerShell 指令視窗,鍵入「sconfig」即可開啟 Server Configuration Tool 設定視窗。



WAC 遠端管理 Hyper-V Server

一旦 Hyper-V Server 主機基礎設定完成後,後續的管理維護通常會透過遠端連線處理。然而,在過去需要遠端管理 Hyper-V Server 主機之前,必須先在 Hyper-V Server 主機處理「遠端存取權限」、「信任主機清單」、「啟用遠端管理」……等,才能夠透過伺服器管理員或 Hyper-V 管理員,或是 RSAT 遠端管理工具,遠端連線並管理 Hyper-V Server 主機。

現在,管理人員可以透過 WAC(Windows Admin Center)管理工具,即能以內建的 Remote PowerShell,以及 WMI over WinRM(Port 5985)遠端管理連線機制,快速納管 Windows Server 和 Hyper-V Server 主機,並且納入管理的 Hyper-V Server 無須安裝任何代理程式,達到「無代理程式」(Agentless)的現代化管理運作架構。

請在 WAC 管理工具中,依序點選「All Connections > Add > Servers > Add」項目,鍵入 Hyper-V Server 主機電腦名稱,本文實作環境為「HV2019」,此時系統便立即透過 WMI over WinRM(Port 5985)機制,探索及發現遠端 Hyper-V Server 主機(如圖 11 所示)。

圖 11、透過 WAC 管理工具納管遠端 Hyper-V Server 主機

成功透過 WAC 管理工具納管 Hyper-V Server 主機後,預設將會切換到左邊的「Overview」項目,在該項目中可以快速一覽 Hyper-V Server 主機的資訊,包括,電腦名稱、網域環境、作業系統版本,硬體資訊……等,甚至還有 CPU 處理器、記憶體使用量、乙太網路頻寬使用……等效能圖表。

點選左邊的 Firewall 項目,除了方便的針對 Hyper-V Server 主機,調整網卡防火牆設定檔之外,針對防火牆的「進入」(Incoming)和「流出」(Outgoing)等網路流量,也可以非常方便調整規則內容,以及防火牆規則的啟用和停用甚至是刪除或新增等作業(如圖 12 所示)。

圖 12、透過 WAC 管理工具遠端管理 Hyper-V Server 防火牆規則

原則上,透過 WAC 管理工具,非常容易針對遠端的 Hyper-V Server 進行維護管理作業(如圖 13 所示),舉凡,檔案或資料夾分享、查詢系統事件、安裝驅動程式、管理使用者和群組、效能檢視器、管理系統服務……等,甚至還能結合 Microsoft Azure 公有雲服務,例如,屆時可以整合 Azure Backup 機制,將地端的 VM 虛擬主機備份至 Azure 公有雲……等。

圖 13、透過 WAC 管理工具 RDP 遠端連線至 Hyper-V Server

簡單來說,WAC 管理工具結合過往多項管理工具的優點,例如,整合伺服器管理員系統組態的部份,整合 RSAT 遠端管理工具僅支援部份組態設定,整合 Hyper-V 管理員僅支援虛擬化管理作業。因此,管理人員透過簡單直覺的管理介面,能夠全方位管理遠端 Hyper-V Server 伺服器虛擬化平台,以及其上運作的 VM 虛擬主機。

首先,請在 WAC 管理工具中,依序點選「Virtual Switches > New」項目後,填入 Hyper-V vSwitch 虛擬交換器名稱,本文實作環境為「VMs-vSwitch」,在 vSwitch 虛擬交換器類型方面,可以直接選擇「External」類型,以便與 Hyper-V Server 主機實體網路環境溝通,選擇需要套用的乙太網路卡,倘若 Hyper-V Server 主機僅有一張網路卡時,請記得勾選「Allow management OS to share these network adapters」項目,以便透過同一張網路卡管理 Hyper-V Server,確認組態設定內容無誤後按下 Save 鈕即可(如圖 14 所示)。

圖 14、透過 WAC 管理工具建立 Hyper-V vSwitch 虛擬網路交換器

在建立 VM 虛擬主機之前,管理人員可以透過 PowerShell 的「Get-VMHostSupportedVersion」指令,查詢 Hyper-V Server 2019 伺服器虛擬化平台,支援哪些 VM 虛擬主機安裝的客體作業系統。在本文實作環境中,Hyper-V Server 2019 最多支援至「9.0」的 VM 虛擬主機設定版本(如圖 15 所示)。

圖 15、查詢 Hyper-V Server 2019 支援的 VM 虛擬主機設定版本

簡單來說,VM 虛擬主機設定版本,和屆時 VM 虛擬主機內安裝的客體作業系統版本支援度有關,舉例來說,當 VM 虛擬主機安裝 Windows Server 2016 作業系統時,只需要「8.0」版本即可支援,倘若安裝較新的 Windows Server 2019 作業系統時,則必須採用「9.0」版本才能支援(如圖 16 所示),至於最新的 Windows Server 2022 作業系統,則是建議採用最新的「10.0」版本,確保 VM 虛擬主機和 Hyper-V 虛擬化平台完整結合,達到運作效能最佳化。

圖 16、Hyper-V 伺服器虛擬化平台支援的 VM 虛擬主機設定版本一覽表

與傳統 Hyper-V 管理員工具相比,透過 WAC 管理工具更能得到許多管理優勢。首先,點選進入 Virtual Machines 項目後,在右邊「Summary」頁籤項目中,可以看到 Hyper-V Server 主機,VM 虛擬主機整體工作負載狀態,包括,VM 虛擬主機運作狀態(運作中、關機、封存、暫停)、近期發生的系統事件、CPU 處理器使用率、記憶體工作負載……等資訊,甚至會顯示前十名使用最多 CPU 和記憶體運算資源的 VM 虛擬主機。

點選「Inventory」選項,除了條列出每台 VM 虛擬主機概要資訊之外,例如,運作狀態、CPU 使用率、指派的記憶體空間、已經運作多少時間、心跳偵測狀態……等,也能針對「單台或多台」VM 虛擬主機進行維運管理作業,例如,多台 VM 虛擬主機重新啟動、關機、建立檢查點……等。

管理人員可以點選單台 VM 虛擬主機,更深入管理和探索 VM 虛擬主機,在預設頁面中可以看到 VM 虛擬主機的詳細資訊和效能圖表,其中效能圖表還包含儲存資源的 IOPS 和 Throughput,這二項效能圖表在傳統的 Hyper-V 管理員工具中並無法顯示。

在管理單台 VM 虛擬主機中,主要有四大項目,分別是 Connect、Power、Manage、Settings,其中點選 Connect 則會出現直接連線的 Connect,或是像操作 Azure VM 公有雲虛擬主機一樣的體驗,下載 RDP 設定檔後再進行遠端連線管理作業。

在 Power 項目中,則是管理 VM 虛擬主機的電力情況,包含,啟動、關機、斷電、儲存、重新啟動、暫停、恢復……等。在 Manage 項目中,除了支援複製、匯出、重新命令、刪除快照……等一般管理作業之外,點選 Move 則可整合 Hyper-V Server 進階功能 Live Migration 即時遷移,或是點選 Replicate using Azure Site Recovery 項目,整合 Azure ASR 機制進行 DR 異地備援作業。

最後,按下 Settings 項目,則是調整 VM 虛擬主機的原有組態設定值,包括,是否啟用動態記憶體、vCPU 虛擬處理器數量、是否啟用巢狀式虛擬化功能、是否啟用處理器相容性機制、啟用或關閉整合服務功能……等(如圖 17 所示)。

圖 17、調整 VM 虛擬主機整合服務項目





結語

透過本文的深入剖析和實戰演練後,相信管理人員已經知道 Windows Server、Hyper-V Server、Azure Stack HCI 之間的差異,同時透過 WAC 管理工具,能夠幫助管理人員輕鬆遠端連線管理 Hyper-V Server 伺服器虛擬化平台。

Windows Server Summit 2022

$
0
0

前言

微軟官方即將在 2022 年 12 月 6 日,舉辦線上的 Windows Server Summit 2022 活動,將會獲得有關 Windows Server 2022AutomanageWAC (Windows Admin Center)Azure ArcSystem Center 2022……等最新資訊。有興趣的朋友,可以透過下方網址進行報名:


活動議程和主軸

下列是本次 Windows Server Summit 2022 講者和議程主軸:
  • 了解最新 Windows Server 2022和 Azure 特色功能和範例展示。
  • 透過增強的多層保護機制確保您所管理主機的安全性。
  • 使用 AutomanageWAC (Windows Admin Center) 輕鬆管理雲端和地端伺服器,並整合至 Azure 雲端環境中。
  • 高效能和高彈性保護及管理混合雲及多雲環境。
  • 使用 Azure Arc在雲端和地端之間無縫運作應用程式。
  • 充分利用 System Center 2022中的多項管理功能。

網管人 202 期 - vCenter 7 內建備份利器,遇險即刻還原恢復運作

$
0
0


網管人雜誌

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





本文目錄  






前言

在 vSphere 虛擬化基礎架構中,擔任集組態設定、監控、管理、告警……等機制的 vCenter Server 管理平台,在整個 SDDC 軟體定義資料中心內的重要性不言而喻(如圖 1 所示)。因此,對於 vCenter Server 的備份和還原作業,管理人員應該審慎規劃並確實執行。 

圖 1、vCenter Server 管理平台功能示意圖

雖然,vCenter Server 遭遇災難事件導致無法正常運作時,運作於 vSphere 虛擬化架構上的工作負載,例如,VM 虛擬主機或容器……等,仍然能夠正常運作不受影響。然而,因為 vCenter Server 發生故障無法正常運作時,將會導致管理人員無法管理整個 vSphere 虛擬化架構,並且執行相關維運管理的工作任務,舉例來說,無法調整 VM 虛擬主機資源、無法執行 vMotion 線上遷移 VM 虛擬主機……等。

在市面上,已經有許多第三方軟體廠商,針對 vCenter Server 進行備份和還原的產品。然而,對於原本 IT 預算就不高的企業和組織來說,這一筆備份軟體開銷,無疑讓原本就稀少的 IT 預算雪上加霜。因此,在本文中,將說明和實戰演練,透過 vCenter Server 內建的備份和還原機制,對 vCenter 進行定期備份作業,並且模擬災難事件發生時,如何透過備份進行還原任務,讓 vCenter Server 管理平台,能夠在最短時間內恢復正常運作。





實戰 – vCenter Server 7 備份和還原

事實上,目前有兩種方式支援 vCenter 管理平台的備份任務,第一種稱之為「映像檔方式」(Image-Based),也就是針對整台 vCenter 虛擬主機進行備份,這也是市面上第三方軟體廠商採用的主流備份方式。

第二種,則是「檔案方式」(File-Based),將 vCenter 管理平台中相關組態設定進行備份後,在災難發生時進行還原作業,在本文實戰演練小節中便是採用此方式。

值得一提的是,當企業和組織為 vCenter 管理平台,建立「增強型鏈接模式」(Enhanced Linked Mode,ELM)運作環境後,建議管理人員應該採用本文介紹的檔案方式,為 vCenter 管理平台進行備份作業,而非使用映像檔方式備份。

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



手動備份 vCenter Server

雖然,是內建的備份機制,但是功能一點都不馬虎,除了無須安裝任何備份代理程式之外,特色功能也不斷增強和演進,舉例來說,在 vSphere 6.5 版本時,備份和還原機制支援的通訊協定僅有 FTP(s)、HTTP(s)、SCP,而在 vSphere 6.7U2 版本時,更額外新增支援 SFTP、NFSv3、SMBv2 通訊協定。
請注意,採用 FTPS 時僅支援 Explicit 模式,採用 HTTP(s)時必須在網頁伺服器上啟用 WebDAV,倘若透過 HTTP Proxy 傳輸備份資料時,僅支援採用 FTP(s)、HTTP(s)通訊協定。

在手動備份實戰演練中,模擬企業和組織已經建構完成 vSphere 虛擬化基礎架構,但是因為 IT 預算不足的關係,導致備份用途的 NAS 儲存設備必須下個年度才能採購,那麼在這段過渡期間該如何進行 vCenter 備份作業 ?在短期備份需求狀態下,可以為 ESXi 虛擬化平台配置一顆大容量硬碟,便可以透過 SFTP 的方式,將 vCenter 備份傳送至 ESXi 虛擬化平台中,並且在需要時進行還原作業。
請注意,這種方式僅適用於短期過渡的備份需求,並非長期備份解決方案,倘若災難事件發生時影響到儲存備份檔案的 ESXi 主機,屆時便無法進行 vCenter 還原作業。

首先,請為儲存 vCenter 備份的 ESXi 虛擬化平台,開啟 SSH 服務(Port 22)和防火牆允許規則。在 vCenter 管理介面中,依序點選「Datacenter > ESXi Host > Configure > System > Services > SSH」,點選 START 後,確保 Daemon 欄位從原本的「已停止」(Stopped),變更為「運作中」(Running)狀態(如圖 2 所示),並且確保 SSH 通訊協定在 Firewall 規則允許清單內。

圖 2、為 ESXi 主機啟動 SSH 服務並確定防火牆允許 SSH 流量通過

接著,透過 SSH Client 工具連線至 ESXi 主機,在本文實作環境中,執行 mkdir 指令建立用於儲存備份檔案的資料夾「vCenterFileBackup」,執行 pwd 指令確認路徑為「/vmfs/volumes/node01-backupdisk/vCenterFileBackup」。

請登入 vCenter Server Management(Port 5480)管理介面,登入後依序點選「Backup > Activity > Backup Now」,在彈出視窗中於 Backup location 欄位中,填入通訊協定為 SFTP 和 ESXi 主機的 FQDN 和 SSH 連接埠,最後搭配剛才的備份資料夾路徑,本文實作環境為「sftp://node0123.lab.weithenn.org:22//vmfs/volumes/node01-backupdisk/vCenterFileBackup」,在 Backup server credentials 欄位,填入儲存備份檔案的 ESXi 主機管理帳號 root 和密碼,確認無誤後按下 START 鈕便立即進行單次備份任務(如圖 3 所示)。

圖 3、鍵入備份 ESXi 主機資訊和備份資料夾路徑

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

圖 4、執行手動備份 vCenter Server 工作任務

值得注意的是,倘若採用 vCenter Server「7.0 U2d」版本的話,管理人員可能在執行 SFTP 備份作業時,遭遇到「General system error reported by backup server」的錯誤訊息,原因在於這個版本中的 curl 指令,在執行備份到 SFTP 目的端時會發生崩潰的情況導致備份失敗,管理人員可以考慮兩種解決方式。

第一種方式是,採用其它支援的通訊協定進行備份任務,例如,採用 NFS 或 SMB 。第二種方式,則是將 vCenter 更新至「7.0 U3d」版本即可解決此問題,本文實作環境採用最新的 7.0 U3g 版本,所以已經修復此問題並透過 SFTP 順利執行備份任務,相關詳細資訊請參考  VMware KB 85966 知識庫文章。

備份任務完成後,管理人員應該已經發現,由於預設高安全性的關係,當 ESXi 主機啟用 SSH 服務後,將會在 Summary 頁籤出現「SSH for the host has been enabled」訊息(如圖 5 所示),並且 ESXi 圖示會有警告符號產生,這些都是系統提醒管理人員,記得將 ESXi 主機啟動的 SSH 服務關閉,避免持續開啟 SSH 服務降低 ESXi 主機安全性,以及遭受惡意攻擊的機會。

圖 5、備份完畢後記得將 ESXi 主機啟動的 SSH 服務關閉



排程定期備份 vCenter Server

相對於手動備份這種短期過渡需求,對於企業和組織來說,排程時間定期備份 vCenter Server 管理平台,才是長期的備份解決方案。在本小節中,將為擔任備份用途的儲存設備開啟 SMB 通訊協定,儲存 vCenter 排程備份檔案。值得注意的是,目前排程備份機制一次只能設定一個排程,並未支援組態設定多個排程同時執行。

登入管理介面後,依序點選「Backup > Backup Schedule > Configure」,在彈出的排程備份視中,在 Backup location 欄位填入通訊協定 SMB,以及儲存設備 FQDN 和備份資料夾路徑,在 Backup server credentials 欄位,填入具備該備份資料夾寫入權限的使用者帳號和密碼,在 Schedule 欄位,支援採用每日和每週或每週的哪幾天進行備份,在 Encrypt backup 欄位的部份,倘若管理人員希望加密備份檔案時,請鍵入兩次加密密碼,在 Number of backups to retain 欄位中,選擇「Retain all backups」項目,將會保留所有的備份檔案,選擇「Retain last backups」項目,則是保留指定的備份檔案份數,本文實作環境選擇保留最後七天的備份檔案,確認無誤後按下 Create 鈕即完成排程備份設定(如圖 6 所示)。

圖 6、組態設定排程備份機制

排程備份機制設定完成後,在 Backup Schedule 區塊將會顯示剛才組態設定內容,而指定的排程時間後系統便會自動執行備份任務,並且在 Activity 區塊可以看到備份任務的執行結果(如圖 7 所示)。

圖 7、排程備份任務執行成功



備份 vDS 分佈式虛擬交換器

當企業和組織在 vSphere 虛擬化環境中,建立並部署「分佈式虛擬交換器」(vSphere Distributed Switch,vDS)時,建議管理人員也單獨將 vDS 分佈式虛擬交換器組態設定匯出,以便後續需要時可以匯入或還原 vDS 組態設定,否則有可能會在還原 vCenter 管理平台之後,遭遇到 vDS 分佈式虛擬交換器組態設定遺失的問題,相關詳細資訊請參考  VMware KB 2034602  知識庫文章。

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

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

此時,連結 vCenter 管理介面的瀏覽器,將會自動下載名稱為 Backup.zip 的壓縮檔案,便是剛才選擇 vDS 分佈式虛擬交換器組態設定項目。後續,便可以依據管理人員需求進行「匯入」或「還原」vDS 分佈式虛擬交換器組態設定。



備份 vCenter Server High Availability 環境

事實上,以檔案方式備份 vCenter Server,目前並無法完整支援 vCHA(vCenter High Availability)叢集環境(如圖 9 所示),但是管理人員仍然能夠進行備份任務,並且在 vCHA 叢集架構發生重大災難事件時快速還原和重建。

圖 9、vCHA(vCenter High Availability)叢集環境運作架構示意圖

因此,當企業或組織為 vCenter Server 建立 vCHA(vCenter High Availability)叢集環境時,雖然備份任務僅會備份  vCenter Server 主要節點(Active Node),一旦 vCHA 叢集環境發生災難事件時,管理人員只要在執行還原任務之前,先將 vCHA 叢集環境整個關閉,包含主動節點、被動節點和見證節點,當還原任務執行完畢後,vCenter Server 會處於單機運作環境,管理人員只要透過 GUI 圖形介面進行引導設定,重新建構 vCHA 叢集環境即可,相關詳細資訊請參考 VMware KB 60229KB 2147014KB 2147038KB 2147046知識庫文章。



還原 vCenter Server

養兵千日用在一時,即便已經組態設定排程定時備份,管理人員應該定期確認備份檔案,是否能夠順利執行還原任務。倘若,還原程序是用於驗證用途時,管理人員可以在還原 vCenter Server 時,將 vCenter 的虛擬網路拔除,即可避免和現有運作中的 vCenter 發生衝突的情況。

整個還原程序共分為兩個階段(如圖 10 所示),第一個階段將會部署一台新的 vCenter Server 虛擬主機,第二個階段則是透過先前備份資料,將組態設定和相關資料傳輸至新部署的 vCenter Server 虛擬主機中。值得注意的是,採用以檔案方式備份機制,在執行還原作業時有個限制,也就是 vCenter 採用哪個版本的 ISO 映像檔安裝,就必須用哪個版本的 ISO 映像檔執行還原作業才行,例如,採用 vCenter 7.0 U3g 安裝和部署,便需要使用 vCenter 7.0 U3g 的 ISO 映像檔執行還原作業才行。

圖 10、vCenter Server 還原任務工作流程圖

事實上,整個還原 vCenter Server 的工作任務,跟安裝部署 vCenter Server 時非常類似。請掛載 vCenter ISO 映像檔後,執行 vcsa-ui-installer/win32 資料夾內的 installer.exe 檔案,在彈出的安裝精靈視窗中,點選「Restore」項目以進入還原工作流程。

在第一階段的還原工作流程中,於 3. Enter Backup details 畫面,請於 Location 欄位填入先備儲存備份檔的路徑,以及可存取備份檔路徑權限的使用者帳號和密碼。值得注意的是,備份檔路徑必須是包含「backup-metadata.json」的路徑,本文實作環境填入的備份路徑為「smb://LAB-D/vCenterScheduleBackup/vCenter/sn_vcenter7.lab.weithenn.org/S_7.0.3.00800_20220911-084004_」(如圖 11 所示)。

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

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

在 5. vCenter Server deployment target,請鍵入要將新部署的 vCenter 虛擬主機,部署至哪一台 ESXi 主機,或另一台 vCenter 虛擬化環境中,並且鍵入具備管理權限的使用者帳號和密碼。在 6. Set up target vCenter Server VM,請鍵入新部署的 vCenter 虛擬主機名稱,本文實作為「vCenter7」,以及 root 管理員帳戶密碼。

值得注意的是,倘若故障損壞的 vCenter 仍然處於 Power On 開機狀態時,管理人員應將其關閉並且修改 vCenter 虛擬主機名稱,例如,本文實作環境將原有 vCenter 虛擬主機名稱,修改為「vCenter7-legacy」,否則系統在進行檢查作業時,將會因為發現 vCenter 虛擬主機名稱已存在而停止還原程序(如圖 12 所示)。

圖 12、準備還原的 vCenter 虛擬主機名稱和原有 vCenter 名稱發生衝突

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

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

在 9. Configure network settings,請鍵入 vCenter 虛擬主機網路組態,本文實作環境 FQDN 為「vcenter7.lab.weithenn.org」,而固定 IP 位址則是「10.10.75.20」。值得注意的是,在 Network 欄位的部份,倘若採用 vDS 分佈式虛擬網路交換器時,在下拉選單中僅會顯示「暫時綁定」(Ephemeral binding)的 Port Group,一般常用「靜態綁定」(Static binding)的 Port Group 並不支援所以不會顯示,或是管理人員也可以選擇使用 vSS 標準式虛擬網路交換器,在本文實作中選擇名稱為「Restore-vNet」的 Port Group(如圖 13 所示)。有關暫時綁定和靜態綁定的詳細資訊,請參考 VMware KB 1022312知識庫文章。

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

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

圖 14、第一階段 vCenter Server 還原任務成功

在第二階段的還原工作流程中,系統主要將備份檔案中組態設定和相關內容,複製到新部署的 vCenter Server 當中。

在 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 Server 還原任務成功



還原 vDS 分佈式虛擬交換器

原則上,倘若在 vCenter 管理平台故障損壞期間,管理人員並無針對 ESXi 進行 vSwitch 虛擬交換器進行異動的話,那麼當 vCenter 管理平台還原之後,無須針對 vDS 分佈式虛擬交換器,進行匯入或還原作業。倘若,有任何異動或損壞的話,管理人員可以透過先前的 vDS 分佈式虛擬交換器備份進行還原作業。

倘若 vDS 分佈式虛擬交換器整個遺失,請在 vCenter 管理介面中,依序點選「Home > Networking > Datacenter > 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 管理介面中,依序點選「Home > 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 高可用性叢集環境詳細資訊,請參考本刊【第 178 期 - 建立 vCHA 高可用性架構虛擬化總管中心永不停機】內容。





結語

透過本文的深入剖析和實作演練後,管理人員應該已經理解,透過 vCenter Server 管理平台內建備份還原機制,便可以輕鬆達成備份和還原工作任務,無須額外採購第三方備份軟體,即可保護 vSphere 虛擬化基礎架構中,角色至關重要的 vCenter 管理平台,並且在發生災難事件時快速恢復至正常運作狀態。

關於站長

$
0
0



關於本站

本網站所引用他人商標或圖示均屬該來源網站或其合法權利人所有,本站內容多為個人研究心得,其所寫之實作筆記內容多為參考網路上資料並實際操作後所記錄完成,歡迎分享網站內容並標示出處及作者但僅限於非商業用途連結,且禁止改作(若你重混、轉換本素材,或依本素材建立新素材,則你不得散布改作後的素材!!) [本網站內容受 創用 CC 授權 3.0保護],本網站若有任何地方侵犯到您權利的地方,請 Mail 給我 將會立刻處理謝謝您。





Weithenn 摸索 IT 世界回顧:




2023 年

1 月: 



2022 年

10 月: 

          (1) 擔任 Kubernetes Summit 2022 工作坊講師。


 

9 月: 

          (1) 擔任 DevOpsDays Taipei 2022 工作坊講師。



7 月: 


          (2) 擔任 Cloud Summit Taiwan 2022議程和工作坊講師



4 月: 

         (1) 擔任 SRE Conference 2022  議程講師。


2 月: 

         第 11 年 當選 VMware vExpert 2022 Awards Announcement 技術專家 VMware vExpert Information - Wei-Ren Wang






2021 年

11 月: 

         (1) 擔任 臺灣雲端大會 Cloud Edge Summit Taiwan 2021  議程講師。  

         (2) 擔任 DevOpsDays Taipei 2021 議程講師。 




7 月: 




3 月: 

         (1) 擔任 台北資策會 - VMware vCenter Server HA 高可用性實戰班   課程講師。  
         (2) 擔任 台北資策會 - Microsoft Hyper-V 伺服器虛擬化實戰班   課程講師。 
         (3) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。 


2 月: 

         第 10 年 當選 VMware vExpert 2021 技術專家 VMware vExpert Information - Wei-Ren Wang






2020 年

9 月: 

         擔任 Taiwan Cloud Edge Summit 2020議程講師。




7 月: 

         (1) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。 
         (2) 第 9 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang



4 月: 

         (1) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。
         (2) 擔任 Taiwan Global Azure 2020議程講師。




3 月: 

         (1) 擔任 台中資策會 - Microsoft Azure IaaS 實戰班 課程講師。
         (2) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。
         (3) 第 9 度當選 VMware vExpert 2020 技術專家 VMware vExpert Information - Wei-Ren Wang


         (4) 擔任 2020 儲存趨勢論壇 (StorTrends 2020) 議程講師。



2 月: 

         地球村走一回,今年插旗的國家是 葡萄牙之旅



1 月: 

          (1) 擔任 台中資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。
          (2) 和 VMware Taiwan 共同舉辦第一次 Taiwan VMUG (VMware User Group) 聚會






2019 年

12 月: 

         擔任 VMware vForum Taiwan 2019議程講師。



11 月: 

         擔任 OpenInfra Days Taiwan 2019議程講師。



10 月: 

         擔任 Cloud Native Forum 2019 議程講師。



9 月: 

         (1) 擔任 Dell Technologies Forum 2019議程講師。


         (2) 擔任 Kubernetes Summit 2019 議程講師。


7 月: 

        (1) 第 8 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang


        (2) 擔任 聖約翰科大 - ABC 高科技人工智慧碩士學分班業界講師。

        (3) 完成人生中 第 19 本 著作 (英文翻譯書) VMware vSAN 6.7 U1 Deep Dive 中文版



6 月: 

        (1) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。

        (2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

        (3) 地球村走一回,今年插旗的國家是 波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)


5 月: 

         擔任 Cloud & Edge Summit 2019議程講師。


3 月: 

         (1) 第 8 度當選 VMware vExpert 2019 技術專家 VMware vExpert Information - Wei-Ren Wang,在 2018 年全球共有 1,731 位 VMware vExpert (Taiwan 共 5 位獲選)


         (2) 擔任 Windows Server 2019 成就多雲資料中心現代化議程講師。






2018 年

10 月: 

         (1) 首度當選 VMware vExpert PRO 技術專家 VMware vExpert Information - Wei-Ren Wang,這是由 2018 年全球 1536 位 VMware vExpert 2018 成員中再度選出 46 位獲選為 vExpert PRO。


         (2) 擔任 Acer / Microsoft - Tech 2019 New Future - Windows Server 2019議程講師。



9 月: 

         (1) 擔任 台灣微軟 Windows Server 高峰會 - 認識 Windows Server 2019 超融合架構 議程講師。



         (2) 擔任網管人主辦 2018 企業資安實務策略論壇 - 拒絕成為馬奇諾防線 - Windows Security Hardening議程講師。



8 月: 

         擔任 OpenInfra Days Taiwan 2018 - Openstack Containerization - Deploy OpenStack in Minutes議程講師。



7 月: 

        第 7 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang



6 月: 

         擔任 iThome Kubernetes Summit 2018 - OpenFaaS on Kubernetes - 1 分鐘建構好你的 Serverless 平台議程講師。



4 月: 

         (1) 擔任 聖約翰科技大學雲端,人工智慧,物聯網暨大數據之生態與展望,產品行銷策略技術與管理」課程的業師,與該校 40 位老師/教授分享我在 SDDC 軟體定義資料中心的一些經驗談。

         (2) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。


5 月: 

         (1) 擔任 iThome Cloud Summit 2018 - 打造 VM / Container / Serverless 三位一體的軟體定義資料中心 議程講師。


         (2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

         (3) 擔任 國立台北商業大學 - Microsoft S2D - HCI 超融合規劃與建置實務班講師。


3 月: 

         (1) 與台灣微軟合作,錄製 六分鐘學會在 Azure VM 中啟用巢狀虛擬化 Nested Virtualization影片,幫助您實際操作了解如何在 Azure VM 啟用巢狀虛擬化技術。


         (2) 擔任 Serverless All-Star 研討會講師。



2 月: 

         第 7 度當選 VMware vExpert 2018 技術專家 VMware vExpert Information - Wei-Ren Wang,在 2018 年全球共有 1,536 位 VMware vExpert (Taiwan 共 5 位獲選)






2017 年

12 月: 

        (1) 擔任 國立台北商業大學 - 私有雲規劃與建置實務班 - Hyper-V 課程講師。

        (2) 擔任 法務部 - Windows Server Container 教育訓練課程講師。

        (3) 網管人雜誌專訪 軟體定義儲存也要嚴選,東森得易購導入微軟 S2D


        (4) 擔任 Dell/Microsoft - IT 未來新能量 研討會講師。

        (5) 出版人生中 第 18 本 著作 (英文翻譯書) Windows Server 容器技術


10 月: 

        (1) 擔任 國立台北商業大學 - Docker 容器技術實務應用班 課程講師。

9 月: 

        (1) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。

        (2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

        (3) 擔任 DevOpsDays Taipei 2017 - 打造 Infrastructure Agility: Mode 2 的基石 - SDS 軟體定義儲存 議程講師。


8 月: 

        (1) 擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲規劃與建置之最佳化調校實務班課程講師。

        (2) 首度當選 VMware vExpert 2017 - VSAN,這是由全球 1514VMware vExpert 2017成員中再度選出 vExpert VSAN,2017 年全球只有 74位獲選。


        (3) 出版人生中 第 17 本 著作 (個人著作) 微軟 S2D 軟體定義儲存技術實戰


7 月: 

        (1) 第 6 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang


        (2 ) 擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲之SDS軟體定義儲存實務班  課程講師。

        (3) 出版人生中 第 15、16 本 著作 (英文翻譯書) VMware vSphere 6 企業級專家手冊


6 月: 

        擔任 iThome Cloud Summit 2017 - Bimodal IT 打造 SDDC 軟體定義資料中心 議程講師。

4 月: 

        擔任 國立臺北商業大學 - 私有雲規劃與建置 Hyper-V 實務班 課程講師。

3 月: 

        擔任 打造 Infrastructure Agility Mode 2 的基石 – Docker / Container 議程講師。

2 月: 

         第 6 度當選 VMware vExpert 2017 技術專家,VMware vExpert Information - Wei-Ren Wang






2016 年

11 月: 

       (1)  擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

       (2)  擔任 中華電信學院 - VMware vSphere 建置與維護實作進階班 講師。

8 月: 

        (1) 擔任 資策會 - VMware vSphere ESXi 桌面虛擬化實戰課程講師。

        (2) 擔任 Community Open Camp活動講師。


7 月: 

        (1) 第 5 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang


        (2) 擔任 105 年度資訊應用服務人才培訓計畫 - 企業私有雲之規劃與建置 (實務班、進階班) - 以 Microsoft Hyper-V 為例  課程講師。

        (3) 擔任 財團法人中興工程顧問社 VMware Horizon VDI 虛擬桌面 內部教育訓練講師。

6 月: 

         (1) 出版人生中 第 14 本 著作 (英文翻譯書) Hyper-V 最佳實踐:快速建置虛擬化解決方案。    


         (2) 擔任 聖約翰科技大學 - VMware 虛擬化技術培訓課程 講師。

4 月: 

          出版人生中 第 13 本 著作 (英文翻譯書) VMware vSphere 最佳化效能調校


5 月: 

         擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

3 月: 

         (1) 貢獻多篇技術文章至 Microsoft TechNet 技術文件庫
                Windows Server vNext 新技術預覽
                WDS 部署服務
                Microsoft SDS 軟體定義儲存技術
                Microsoft 資料保護最後一哩 Storage Replica
                新世代伺服器 Nano Server

          (2) 與 TechNet 台灣部落格 合作,撰寫 Windows Server 2016 攻略連載文章:
               [Network] Windows Server 2016 攻略 (七) - 新世代虛擬網路交換器 SET ( Switch Embedded Teaming )
               [Network] Windows Server 2016 攻略 (八) - SDN 軟體定義網路

2 月: 

          (1) 第 5 度當選 VMware vExpert 2016技術專家,VMware vExpert Information - Wei-Ren Wang


          (2) 與 TechNet 台灣部落格 合作,撰寫 Windows Server 2016 攻略連載文章:
               [Storage] Windows Server 2016 攻略 (四) - SDS 軟體定義儲存
               [Storage] Windows Server 2016 攻略 (五) - 資料備援新選擇 Storage Replica
               [Storage] Windows Server 2016 攻略 (六) - 儲存資源品質管控機制 Storage QoS

1 月: 

          與 TechNet 台灣部落格 合作,撰寫 Windows Server 2016 攻略連載文章:
               [Compute] Windows Server 2016 攻略 (一) - 新世代虛擬化平台 Hyper-V
               [Compute] Windows Server 2016 攻略 (二) - 為雲端而生的極簡平台 Nano Server
               [Compute] Windows Server 2016 攻略 (三) - 整合雲端元素的容錯移轉叢集





2015 年

11 月: 

          出版人生中 第 12 本 著作 (英文翻譯書) Active Directory 環境的 PowerShell 活用指南


10 月: 

          (1) 與 MSDN 部落格合作翻譯 微軟正式宣布推出 PowerShell DSC for Linux Version 1.1 以及新的 Linux 資源文章。

          (2) 出版人生中 第 11 本 著作 (英文翻譯書) 實戰 Azure 混合雲|基礎架構 x 高可用性 x 災難復原


9 月: 

         (1) 擔任 資策會 Hyper-V 虛擬化實戰系列課程講師。

         (2) 於 Microsoft Techdays Taiwan 2015 舉辦期間,擔任 3場(ITM305、ECI309、ECI303) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2015


7 月: 

        (1) 與 Channel 9 Taiwan 合作「深入探討網路儲存及災難備援議題」線上課程,進行字幕及簡報的翻譯及審校。

        (2) 與 Channel 9 Taiwan 合作「充分使用 Open Source 加速解決方案」線上課程,進行字幕及簡報的翻譯及審校。

        (3) 與 Channel 9 Taiwan 合作「使用 Azure 優化工作負載架構和管理能力」線上課程,進行字幕及簡報的翻譯及審校。

        (4) 第 4 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang


6 月: 

         擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2015) 講師。


5 月: 

          (1) 擔任 微軟 EMS 全方位企業雲端解決方案 講師。


          (2) 受邀 iThome 雜誌採訪,分享 全面透視虛擬環境網路效能的瓶頸觀點。

          (3) 擔任 104 年度資訊應用服務人才培訓計畫 - 企業私有雲實戰講堂 - 以 VMware 為例  課程講師。

          (4) 貢獻 虛擬化環境導入評估工具 MAPStorage Space 存放集區、 Azure RemoteApp 應用程式虛擬化  等文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

          (5) 與 TechNet 部落格合作翻譯 針對軟體定義資料中心而生的 - 新世代儲存機制 、企業級虛擬化及新世代應用程式平台 文章。

          (6) 出版人生中 第 10 本 著作 (技術審校書) SDN 軟體定義網路


4 月: 

          (1) 出版人生中 第 9 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 叢集雲端架構實戰 (高級篇)


        (2) 與 Channel 9 Taiwan 合作「建立 Microsoft Azure IaaS 雲端基礎建設」線上課程,進行字幕及簡報的翻譯及審校。

2 月: 

          第 4 度當選 VMware vExpert 2015VMware vExpert Information - Wei-Ren Wang






2014 年

12 月: 

          貢獻 MVMC 2.0Windows Server 2012 R2 運作模式切換 文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

11 月: 

          出版人生中 第 8 本 著作 (英文翻譯書) VMware Virtual SAN 管理手冊


9 月: 

          於 Microsoft Techdays Taiwan 2014 舉辦期間,擔任 四場(PCIT306、DCIM309、PCIT305、DCIM402) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2014MVA - TechDays Taiwan 2014


8 月: 

          貢獻 Windows Server 2012 升級至 2012 R2 文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

7 月: 

          (1) 出版人生中 第 7 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 虛擬化環境實戰 (初級篇)

          (2) 第 3 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang


          (3) 擔任 北區農會電腦共用中心 - VMware / Hyper-V 伺服器及桌面虛擬化基礎 內部教育訓練講師。

6 月: 

          (1) 擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2014) 講師。
               當天所有議程簡報 2014 台灣微軟 IT 管理高峰會簡報下載

          (2) 參加 Microsoft 主辦雲端戰士團,獲得 2014 年第三屆金翅級認證
               當天活動新聞訊息 自由電子報 3C科技 - 台灣微軟匯聚雲端戰士團


          (3) 擔任 文藻外語大學 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

5 月: 

          (1) 擔任 集英信誠 - 與大師對談技術論壇講師。
               當天所有議程簡報 與大師對談活動簡報
               當天我的議程簡報 VMware 及 Hyper-V最佳虛擬化平台硬體規劃

          (2) 受邀擔任 雙和區資訊組長研習 - HyperV 3.0 R2 新功能研討研習 講師。

4 月: 

          (1) 擔任 春源鋼鐵 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

          (2) 第 3 度當選 VMware vExpert 2014VMware vExpert Information - Wei-Ren Wang

       
          (3) 貢獻 Windows Server 2012 R2 虛擬桌面部署建議文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

3 月: 

          (1) 貢獻 Windows Server 2012 R2 - Hyper-V 10 大特色功能Windows Server 2012 R2 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

          (2) 擔任 2014 微軟技術關卡破解日 講師。
               當天所有議程錄影 Channel 9 - MVP 微軟技術關卡破解日
               當天議程錄影及簡報 虛擬化平台最佳選擇 - Windows Server 2012 R2 Hyper-V 新功能展示



2 月: 

          貢獻 Windows Server 2012 R2 - 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任





2013 年

12 月: 

         (1) 擔任 雙和區資訊組長研習 - Hyper-V 3.0與 VMware vSphere 5.5 虛擬化新功能比較講師。

         (2) 擔任 元智大學 - 雙 V 駭客,架設高可用的服務主機 (Hyper-V 上午場)(VMware 下午場)研習活動講師。


11 月: 

          (1) 出版人生中 第 6 本 著作 (英文翻譯書) 打造雲端工作站 VMware View 5 建置與維護


          (2) 擔任 威盛電子 - Windows Server 2012 R2 虛擬化平台最佳選擇 內部教育訓練講師。

          (3) 貢獻 Windows Server 2012 即時遷移文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

          (4) 擔任 102學年度全國大專校院 - 資訊行政主管研討會 - 淡江大學軟體雲建置實例分享議程講師,當天議程簡報 淡江大學軟體雲建置實例分享(PDF)

          (5) 擔任 VMware 桌面虛擬化及軟體雲應用研討會講師,當天議程簡報 虛擬桌面最佳化調校


10 月: 

          (1) 擔任 艾鍗學院 - 職訓課程 - 網管工程師類 - 私有雲與虛擬化系統工程師養成班講師。

          (2) 貢獻 Microsoft Virtual Machine Converter文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

9 月: 

          於 Microsoft Techdays Taiwan 2013舉辦期間,擔任 虛擬化平台最佳選擇: Windows Server 2012 R2 (Hyper-V 3.0 R2) vs VMware vSphere 5.1 及進行Vmware 無痛移轉之工具及建議議程講師。當天活動錄影及簡報 Channel 9 - Techdays Taiwan 2013


8 月: 

          (1) 擔任 雙和區資訊組長研習 - 虛擬化應用與基礎電腦病毒安全防護 (A場)(B場)講師。

          (2) 擔任 特新光電 - Windows Server 2008 R2 教育訓練 內部教育訓練講師。

7 月: 

          (1) 第 2 度當選 Microsoft MVP - Virtualization Virtual Machine 項目 Microsoft MVP Profile - Wei-Ren Wang


          (2) 貢獻 Windows Server 2012 MPIO 文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

6 月: 

          (1) 第 2 度當選 VMware vExpert 2013VMware vExpert Information - Wei-Ren Wang


          (2) 擔任 雙和區資訊組長研習 - VMware vSphere/Microsoft Hyper-V 虛擬化技術平台之 CentOS Webmin 應用講師。

          (3) 受邀採訪並刊登於 商業週刊第1334期 - 這家公司 讓微軟恨、林百里愛

5 月: 

          (1) 出版人生中 第 5 本 著作 (個人著作) 24 小時不打烊的雲端服務-專家教你用 Windows Server 2012 Hyper-V3.0 實戰虛擬化技術


          (2) 擔任 2013 微軟 MVP 實戰課程日講師。
                當天議程簡報Hyper-V 3.0 實戰 - 打造你的完美伺服器虛擬化平台
                當天活動簡報台灣微軟 - 研討會與活動簡報下載 - 微軟實戰課程日
                當天活動錄影台灣微軟 - 實戰課程日回顧篇

4 月: 

          (1) 擔任 第二屆 - 虛擬化戰士 Hyper-V 3.0 培訓計畫助教。

          (2) 貢獻 Hyper-V 2.0 文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

          (3) 貢獻 Hyper-V 3.0 文章至 Microsoft TechNet 文件庫,Microsoft TechNet Library - 王偉任

3 月: 

          擔任 Microsoft TechNet - 邁向雲端虛擬化的全方位攻略 - Hyper-V 與 VMware 大不同課程講師。
          當天議程簡報Hyper-V 與 VMware 大不同
          當天議程錄影Hyper-V 與 VMware 大不同 (上)Hyper-V 與 VMware 大不同 (下)

1 月: 

          擔任 WebConf Taiwan 2013講師,當天議程簡報無廢話 DRBD + Heartbeat 實戰,當天議程錄影無廢話 DRBD + Heartbeat 實戰WebConf Taiwan 2013 懶人包WebConf Taiwan 2013 Day 1 - 活動照片WebConf Taiwan 2013 Day 2 - 活動照片






2012 年

12 月:

          (1) 擔任 雙和區資訊組長研習 - Windows Server 2012 新功能技術研討講師。

          (2) 出版人生中 第 4 本 著作 (技術審校書) MySQL+PHP初心者的學習殿堂:資料庫×動態網頁設計實務養成(附CD)


11 月:

          (1) 擔任 板橋區資訊組長研習 - VMware vSphere ESXi 5.1 實作講師。

          (2) 擔任 Acer Infrastructure & Virtualization 技術會議 內部教育訓練講師。

          (3) 受邀採訪並刊登於 網管人雜誌 第 81 期 資訊這條路 ─ 從無到有十年苦功 王偉任嶄露頭角

9 月: 

          (1) 出版人生中 第 3 本 著作 (技術審校書) 世界連在一起,搜尋引擎的核心秘密


          (2) 受邀推薦 iThome 2012 年 iT 人必看的好書 - 系統與網路管理類

          (3) 於 Microsoft Techdays Taiwan 2012舉辦期間,在 Windows Server 2012 攤位擔任 問專家



8 月: 

          (1) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server Blog - 部份文章審校

          (2) 參加 Windows Server 2012 (Hyper-V 3) 好文比賽獲得 分享獎

7 月: 

          (1) 當選 Microsoft MVP - Virtualization Virtual Machine項目 Microsoft MVP Profile - Wei-Ren Wang


          (2) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server 2012 實戰影片審校

6 月: 

          (1) 擔任 雙和區資訊組長研習 - Hyper-V Server 2008 R2 進階技術研習講師。

          (2) 跟 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Microsoft Technet Blog - 文章審校

5 月: 

          (1) 擔任 雙和區資訊組長研習 - FreeNAS 進階技術研習講師。

          (2) 出版人生中 第 2 本 著作 (技術審校書) 企業級的網路安全架構:終極防駭技術大剖析


4 月: 

          (1) 擔任 雙和區資訊組長研習 - CentOS HA 高可用性進階技術研習講師。

          (2) 成為 台灣第 1 位獲選 VMware vExpert 殊榮的人 VMware vExpert Information - Wei-Ren Wang,並受邀採訪刊登於 VMware VMTN Blog: vExpert Spotlight: Wei-Ren Wang


3 月: 

          (1) 擔任 雙和區資訊組長研習 - VMware vSphere ESXi 進階技術研習講師。

          (2) 參加 Microsoft 所主辦的虛擬化戰士團,獲得 2012 年第一屆金翅級認證,微軟伺服器虛擬日 V-Day 虛擬化戰士頒獎典禮






2011 年

12 月:

          (1) 出版人生中 第 1 本著作 24小時不打烊的雲端服務:專家教你用 CentOS 架設萬年不掛的伺服器。感謝大家熱情支持,此著作已經登上 博客來 2012 年度排行榜 - 電腦類 TOP 50


11 月:

          (1) 擔任 慶聯有線電視 - HP/Dell/IBM 伺服器及 CentOS 作業系統基礎設定 內部教育訓練講師。

          (2) 受邀推薦 iThome 2011 年 IT 好書 100 - 系統與網路管理類





2010 年

10 月:

          受邀採訪並刊登於 iThome 第 480 期 iT 人甘苦談 ─ 架 Wiki 做筆記,IT 人分享學習心得

5 月:

          遇見了 VMware vSphere 虛擬化技術的良師 Johnny





2007 年

3 月:

          想開了!! 開始到世界各地走走,開始記錄遊山玩水的點點滴滴。





2003 年

8 月: 

          第 2 份工作中,遇見 Clive開始接觸 FreeBSD便一腳陷入惡魔的世界 (BSD Committer TW 之一 Clive 的電腦世界回顧與展望)。

4 月:

          第 1 份工作時,在 Bruce 的鼓勵下考取生平第一張證照 CCNA。





2002 年

11 月:

          網路工程師班結訓後,第一份工作學習到有關 Cisco、3Com 網路設備...等技術 ,並且創立本站。

8 月:

          懷著一份對電腦世界的興趣及崇拜,因而參加網路工程師班,並認識了良師 George 及益友 Mandy、Tony...等技術同好。

6 月:

          憲兵退伍,連主要分割區是什麼東東也不知的人不自量力的想進入所謂的 IT 界工作。

    網管人 203 期 - 熱修補更新系統免重啟,地端建雲版虛機也能享用

    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    過去,時常困擾企業和組織的難題之一,便是安全性更新的安裝時機和重新啟動主機的問題。雖然,微軟已經盡力將安裝更新後重新啟動主機的次數減少,然而對於企業和組織的營運服務來說,每次重新啟動主機的動作,都可能造成營運服務產生中斷時間,但是不安裝安全性更新又會讓主機暴露在高資安風險當中。

    此外,對於 IT 預算及管理人員充足的大型企業來說,每項重要服務都有建立高可用性和容錯移轉叢集機制,因此更新後重新啟動主機的動作,並不會對營運服務造成任何中斷影響。然而,對於 IT 預算和管理人員本就不多的中小型企業來說,每次安裝安全性更新後重新啟動主機的動作,便會中斷運作中的營運服務。

    同時,有可能在管理人員不足的情況下,並未測試和檢查安全性更新是否有任何影響時,在貪圖方便的情況下冒然為營運服務主機直接安裝更新時,有可能因為更新導致營運服務啟動失敗,或產生其它非預期性的錯誤,造成營運服務停止而導致企業和組織更多的損失,或者索性不更新避免營運服務中斷,但是主機卻反而遭受惡意攻擊的新聞也時有所聞。

    因此,微軟在 2021 年 6 月時,推出 「熱修補」(Hotpatch)的「公開預覽」(Public Preview)版本,並在 2022 年 2 月時推出熱修補的 「正式發行」(General Availability,GA)版本。簡單來說,透過最新的熱修補技術(如圖 1 所示),執行安全性更新安裝作業時,將會直接針對 Windows Server 伺服器中,記憶體內部運作的系統程序進行程式碼修補的動作,不僅主機的運作不受干擾,同時其它運作的執行程序和服務也無須停止,並且修補完畢後的 Windows Server 也無須重新啟動,順利達成安全性更新和修補的目的,且不影響企業和組織的「服務等級協議」(Service Level Agreement,SLA)

    圖 1、熱修補 Code Flow 運作架構示意圖

    在 Hotpatch 熱修補 GA 展示影片中,可以看到二台 VM 虛擬主機,皆採用 Windows Server 2022 Azure Edition 版本,左側主機採用傳統 Windows Update,右側主機採用最新的熱修補技術,並且在安裝安全性更新的同時,還進行檔案複製作業,以便證明熱修補技術在進行更新作業時,也絲毫不影響主機的運作,可以看到右側主機在「51 秒」時,已經安裝好二個安全性更新,而左側主機仍在處理第一個安全性更新,並且安裝進度僅到 13.4%(如圖 2 所示),並且傳統 Windows Update 安裝完畢後,系統會提示必須重新啟動主機才能套用生效。

    圖 2、傳統 Windows Update 機制和最新熱修補技術更新比較

    值得注意的是,最新的 Hotpatch 熱修補技術,在傳統的 Windows Server 2022 Standard 或 Datacenter 版本中並未支援,必須採用 Windows Server 2022 Datacenter : Azure Edition版本才能支援。此外,提醒企業和組織的管理人員,倘若有整合新的特色功能時務必確認採用的版本是否支援,舉例來說,Azure 擴充網路、透過 QUIC 的 SMB……等,這幾項最新技術都必須採用 Azure Edition 版本才能支援(如圖 3 所示)。

    圖 3、Windows Server 2022 版本功能差異比較表

    此時,管理人員可能會問,那麼企業和組織的地端資料中心,是否也能運作 Windows Server 2022 Datacenter : Azure Edition 版本 ?答案是可以的,只要採用 Azure Stack HCI 21H2 和後續版本,那麼便可以透過 「Azure 權益」(Azure Benefits)機制,建立 VM 虛擬主機,並安裝 Windows Server 2022 Datacenter : Azure Edition 作業系統,運作在地端資料中心內的 Azure Stack HCI 超融合基礎架構中。

    簡單來說,管理人員只要在 Azure Stack HCI 21H2 環境中,啟用 Azure 權益機制後,系統將會在 AzSHCI 叢集環境中,為每台 AzSHCI 叢集節點主機啟動 HciSvc 服務,並且啟動後的 HciSvc 服務,會至 Azure 公有雲取得通過簽署的憑證,並將憑證存放在 AzSHCI 叢集節點主機記憶體保護區內,屆時將透過 Azure 平台驗證服務,讓 AzSHCI 叢集環境中的 VM 虛擬主機,以為自己運作在 Azure 公有雲環境中。

    因此,當管理人員在 AzSHCI 叢集內建立 VM 虛擬主機,並安裝 Windows Server 2022 Datacenter : Azure Edition 作業系統後,當 Azure Edition 作業系統執行自我驗證機制,驗證所處環境是否為 Azure 公有雲環境時,HciSvc 服務將會傳遞不可路由的 REST 端點,給予 AzSHCI 叢集環境中運作的 VM 虛擬主機進行存取,此時 HciSvc 服務便會將剛才儲存在記憶體保護區內憑證進行回應,讓 VM 虛擬主機以為自己運作在 Azure 公有雲環境中,但實際上 VM 虛擬主機則是運作在,企業和組織地端資料中心內的 AzSHCI 叢集(如圖 4 所示)。

    圖 4、地端 Azure Stack HCI 叢集啟用 Azure 權益機制運作架構示意圖





    熱修補運作機制

    事實上,熱修補的運作方式,為針對 Windows Update 最新累積更新建立基準線,累積更新一般來說包含所有安全性和品質更新,而且安裝後需要重新啟動主機才能套用生效,而熱修補則是以無須重新啟動主機的更新為基礎,並將基準線以新的累積更新後定期更新。

    因此,當使用熱修補機制後,VM 虛擬主機將具備更高的可用性(較少的重新啟動主機次數),以及更快速的更新作業(較小型的安裝套件,且無須重新啟動的程式),同時達到安裝最新安全性更新的目的。

    當熱修補機制,建立具備 Windows Update 最新累積更新的基準線之後,負責熱修補技術的團隊將會定期發行,例如,基準線建立月份的第二個星期二。接著,熱修補機制將無須重新啟動的安全性更新,每三個月定期使用最新的累積更新來重新整理計劃性基準線。基準線有兩種類型,分別是「計畫性基準線」(Planned Baselines)和「非計劃性基準線」(Un-planned Baselines)
    • 計劃性基準線: 定期發行,並在兩者之間發行適用於熱修補的安全性更新。計畫性基準線包含該月份最新累積更新中的所有更新,並且安裝後需要重新啟動主機才能套用生效。如圖 5 所示,從範例排程中可以看到,日曆年度中共有五個計劃性基準線版本,以及八個熱修補安全性更新版本。
    • 非計劃性基準線: 一旦有重大事件,必須立即發行安全性更新時,例如,Zero-Day 修補程式……等,並且無法快速發行熱修補時,便會啟動非計劃性基準線。一旦發行非計劃性基準線之後,將會以該月份的非計劃性基準線取代熱修補版本。事實上,非計劃性基準線也包含該月份的最新累積更新中的所有更新,並且安裝後需要重新啟動主機才能套用生效。如圖 5 所示,在範例排程說明中,共有兩個非計劃性基準線版本,這些月份將會取代當月的熱修補版本。
    圖 5、熱修補技術安全性更新發行版本、計劃性基準線、非計劃性基準線示意圖





    實戰 – 部署支援熱修補的 Azure VM 虛擬主機

    了解熱修補運作架構和機制之後,在本小節中將實戰演練,如何在 Azure 公有雲環境中,建立支援熱修補機制的 Azure VM 虛擬主機。

    事實上,在 Windows Server 2022 Datacenter: Azure Edition 版本中,仍然有區分為容易操作和管理的,GUI 圖形介面「桌面體驗」(Desktop Experience)模式,以及著重整體效能僅支援文字介面的「伺服器核心」(Server Core)模式。

    當管理人員需要部署 Azure Edition 版本,並且體驗相關特色功能時,請先參考官方說明文件,確保所採用的 VM 虛擬主機印象檔,支援所需要的特色功能(如圖 6 所示)。舉例來說,由於熱修補機制,是透過直接在記憶體中修補需要更新的程式碼,需要花費大量的開發時程,所以目前僅 Server Core 模式支援,但微軟官方已經說明,熱修補機制的預計目標為,支援所有 GUI 圖形模式的 Windows 作業系統,不僅是 Windows Server 連客戶端 Desktop 版本也將支援熱修補機制。

    圖 6、不同 Azure Edition 版本印象檔,支援的特色功能清單

    首先,請登入 Azure Portal 管理畫面,在部署 VM 虛擬主機時,請於 Image 欄位選擇目前支援熱修補機制的印象檔。請注意,倘若選擇尚未支援的印象檔版本,將無法順利為 VM 虛擬主機,註冊和啟用熱修補機制,並且系統也會提醒目前支援熱修補機制的印象檔名稱(如圖 7 所示)。

    圖 7、選擇未支援的印象檔時,將無法為 VM 虛擬主機註冊和啟用熱修補機制

    因此,在 Azure Portal 畫面 Basics 頁籤中,請確保管理人員選擇正確的 VM 印象檔版本,目前支援熱修補機制的印象檔版本,為「Windows Server 2022 Datacenter : Azure Edition Core - Gen2」(如圖 8 所示),其它欄位設定值管理人員依照管理習慣進行設定即可。

    圖 8、選擇目前支援熱修補機制的 VM 虛擬主機印象檔

    一旦管理人員選擇到,正確支援熱修補機制的 VM 虛擬主機印象檔時,預設情況下系統將會自動為 VM 虛擬主機,註冊熱修補機制,管理人員也可以在部署階段中,切換到「Management」頁籤,查看 Guest OS updates 下的「Enable hotpatch」欄位,是否已經自動勾選(如圖 9 所示),確保即將部署的 VM 虛擬主機已經啟用熱修補機制,並且在 Patch orchestration options 下拉選單中,也自動選擇「Azure-orchestrated」選項。
    倘若部署時忘記啟用,管理人員也可以在日後為 VM 虛擬主機註冊並啟用熱修補機制。
    圖 9、確認部署的 VM 虛擬主機啟用熱修補機制



    組態設定單台 VM 熱修補機制

    當 VM 虛擬主機部署作業完成後,管理人員可以在 Azure Portal 的 VM 虛擬主機管理頁面中,點選左側選單「Operations > Updates」項目,便會看到針對該台 VM 虛擬主機熱修補機制的管理方式。目前,支援三種方式進行安全性更新,分別是 Hotpatch、Update Management Center、Automation,管理人員可以依據管理習慣進行挑選(如圖 10 所示)。

    圖 10、支援三種方式管理 VM 虛擬主機更新機制

    首先,點選「Go to Hotpatch」項目,進入單台 VM 虛擬主機的熱修補機制管理頁面,管理人員可以按下「Check for updates」進行更新檢查,檢查後系統將會回報此台 VM 虛擬主機的更新情況。倘若,管理人員在部署 VM 虛擬主機時,忘記勾選啟用熱修補技術的話,此時看到的 Hotpatch status 欄位狀態,便為「停用中」(Disabled)(如圖 11 所示)。

    圖 11、部署 VM 虛擬主機時未啟用熱修補機制

    此時,請點選上方 Update settings 項目,在 Change update settings 中,於 Update settings to change 下拉式選單中,可以看到三個選項:
    • Periodic assessment: 指定主機每 24 小時進行自動評估作業。
    • Hotpatch: 指定主機使用熱修補機制進行安全性更新作業,並且安裝安全性更新後無須重新啟動主機,同時在安裝更新期間運作中的應用程式和服務也無須停止。
    • Patch orchestration: 指定主機採用傳統 Windows Update 方式,自動或手動方式進行安全性更新安裝作業,或是針對啟用 Azure Arc 機制的伺服器,透過 Azure Orchestration 機制進行安全性更新安裝作業。

    在本文實作環境中,勾選「Hotpatch」項目,並且勾選下方 Enable Hotpatch 項目後按下 Next 鈕,在 Machines 頁面中,勾選本台 VM 虛擬主機後按下 Next 鈕,在 Review and change 頁面中,確認無誤後按下 Review and change 鈕即可套用生效(如圖 12 所示)。

    圖 12、為單台 VM 虛擬主機啟用熱修補機制

    此時,可以看到 Hotpatch status 欄位值,從原本的已停用轉變成「已啟用」(Enabled),點選 See details 可以看到,Enablements status 欄位為 Enabled,表示 VM 虛擬主機已經順利啟用熱修補機制,而 Readiness status 欄位為 Unknown,表示主機尚未接收到相關的熱修補安全性更新(如圖 13 所示),後續待微軟釋出熱修補的安全性更新時,系統將會自動於離峰時間進行安裝並且無須重新啟動主機。

    圖 13、順利為單台 VM 虛擬主機啟用熱修補機制



    管理和設定多台 VM 啟用熱修補機制

    剛才的操作步驟,僅能針對「單台」VM 虛擬主機進行操作,倘若企業和組織中有「多台」Azure VM 虛擬主機時,可以透過「更新管理中心」(Update Management Center)進行管理。在更新管理中心介面中,可以看到目前的 VM 虛擬主機數量,同時企業和組織可以針對更新需求進行下列條件的過濾:
    • Subscription: 針對訂閱帳戶進行過濾,預設將會選取所有訂閱帳戶。
    • Resource Group: 針對資源群組進行過濾,預設選取所有資源群組。
    • Resource Type: 針對資源種類進行過濾,支援已經啟用 Azure Arc 機制的主機,以及 Azure VM 虛擬主機,預設選取所有資源種類。
    • Location: 針對 Azure 資料中心進行過濾,預設選取所有 Azure 資料中心。
    • OS: 針對 VM 虛擬主機客體作業系統過濾,支援 Linux 和 Windows 作業系統,預設選取所有作業系統。

    在本文實作環境中,針對其中一個「Weithenn Labs - MSDN」這個訂閱帳戶中,名稱為「RG-EastAsia-Hotpatch」的資源群組,並且 VM 虛擬主機為「Windows」作業系統進行過濾,從 Overview 頁面中可以看到,過濾後的 VM 虛擬主機數量、安全性更新方式、安全性更新狀態……等資訊(如圖 14 所示)。

    圖 14、透過更新管理中心組態設定多台 VM 虛擬主機安全性更新機制

    舉例來說,管理人員想要確保所有支援熱修補的 VM 虛擬主機,皆啟用熱修補機制的話,請點選「Manage > Machines > Select all > Update settings」,此時系統同樣開啟 Change update settings 畫面,選擇「Hotpatch」項目和勾選下方 Enable Hotpatch 項目,在 Machines 頁面中,系統已經發現勾選的 VM 虛擬主機中,有包含尚未支援熱修補機制的 VM 虛擬主機,管理人員可以先全選所有 VM 虛擬主機後,再勾選「Update selection to remove unsupported resource」項目,即可自動排除未支援 Hotpatch 機制的 VM 虛擬主機(如圖 15 所示),在 Review and change 頁面中,確認無誤後按下 Review and change 鈕,即可一次大量啟用 VM 虛擬主機熱修補機制。

    圖 15、自動排除未支援熱修補機制的 VM 虛擬主機



    管理多台 VM 安全性更新

    原則上,在 Azure 公有雲環境中,已經啟用熱修補機制的 VM 虛擬主機,將會自動安裝安全性更新並且無須重新啟動主機,而未支援熱修補機制的 VM 虛擬主機,系統預設值將會自動安裝最新安全性更新。

    同時,管理人員也可以很方便的透過更新管理中心,一次查看所有 VM 虛擬主機的更新狀態組態設定,並且一次為大量 VM 虛擬主機執行檢查、套用、安全更新……等動作。在本文實作環境中,可以看到目前三台主機皆有安全性更新需要安裝,其中二台主機已啟用熱修補機制,另一台則採用傳統 Windows Update 的預設值,總共有 9 個安全性更新可進行安裝(如圖 16 所示)。

    圖 16、透過安全管理中心一覽大量 VM 虛擬主機的安全性更新情況

    首先,切換到「Manage > Machines」頁面,勾選 Select all 項目選取所有 VM 虛擬主機後,選擇「Check for updates > Access now」,確保所有 VM 虛擬主機再次檢查安全性更新情況。檢查完成後,在每台 VM 虛擬主機的 Update status 欄位,將會顯示該台 VM 虛擬主機有多少安全性更新需要安裝,管理人員可以交由系統機制在適當時間自動安裝,或是立即幫所有 VM 虛擬主機安裝安全性更新。

    確認要為所有 VM 虛擬主機立即安裝更新,請按下「One-time update > Install Now」,在 Machines 頁面中,勾選希望立即安裝更新的 VM 虛擬主機,倘若選單中未顯示時可按下 Add Machine 手動加入,值得注意的是目前僅支援一次最多部署「20 台」VM 虛擬主機的更新作業,在 Updates 頁面中,管理人員可以針對安全性更新的類別、KB 號碼、更新釋出時間……等進行過濾(如圖 17 所示),舉例來說,按下 Include update classification 後,可以僅勾選 Critical Updates 和 Security Updates 這二項進行更新,確認後按下 Next 鈕。

    圖 17、確認為 VM 虛擬主機立即安裝哪些安全性更新

    在 Properties 頁面中,管理人員可以在 Reboot options 下拉式選單中,選擇主機重新啟動的選項,分別支援「在必要時重新啟動」(Reboot if required)、「永不重新啟動」(Never reboot)、「一律重新啟動」(Always reboot),至於維護時間則是指定允許安裝更新的時間,支援的上限時間為「235」分鐘,最後在 Review + install 頁面中,確認組態設定無誤後按下 Install 鈕即可。

    待所有 VM 虛擬主機完成安裝更新作業後,回到安全管理中心的 Overview 頁面,即可看到所有主機的安全性更新狀態(如圖 18 所示)。當然,管理人員需要的話,可以點選 Update installation status 中,安全性更新的相關數字,進一步查看每台主機安裝哪些安全性更新和更新細節資訊。

    圖 18、透過安全管理中心一覽所有主機安全性更新狀態





    結語

    透過本文的深入剖析和實作演練後,管理人員應該已經理解 Hotpatch 的運作架構和機制,以及實務上如何在 Azure 公有雲環境中,部署支援熱修補機制的 Windows Server 2022 虛擬主機,並同時管理單台和多台 Azure VM 虛擬主機的安全性更新,無論是支援或不支援熱修補機制的 VM 虛擬主機,都可以透過安全管理中心進行管理,除了有效節省企業和組織管理人員的時間成本之外,更確保主機具備最新安全性更新,減少被網際網路惡意攻擊的機會降低資安風險。

    網管人 204 期 - vSphere 8 全新功能開箱, 試玩 UDT 快速冷移機

    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    在 2022 年 VMware Explore 大會上,VMware 官方正式發佈最新 vSphere 8 版本。同時,從 vSphere 8 版本開始,VMware 官方採用新的版本發佈模型,分別稱為「初始可用性」(Initial Availability,IA)「通用可用性」(General Availability,GA),簡單來說,新的版本發佈方式和 vSphere+ 雲端服務版本將保持一致。

    首先,當 VMware 官方發佈 RC 和 RTM 發佈之後,將會採用和 GA 相同測試品質和發佈標準的流程,在「2 週」之後發佈 IA 版本,接著在「4 - 6 週」之後發佈 GA 版本,而無須像過去必須等待「6 個月」之久,才能取得帶有新功能和增強功能的版本(如圖 1 所示)。

    圖 1、RC、RTM、IA 和 GA 版本發佈週期示意圖





    vSphere 8 亮眼特色功能

    新世代傳輸架構 DPU 和 DSE

    在過去虛擬化基礎架構中,管理人員已經很熟悉各種資源的規劃和調度,例如,負責運算資源的 CPU 和 Memory、負責圖形運算的 GPU。同時,隨著 AI 人工智慧和 ML 機器學習的興起,許多管理人員應該已經發現到,底層負責傳輸大量資料的網路資源也必須跟上,才能讓各項資源的整合與整體服務之間相得益彰,這項新技術稱之為「資料處理單元」(Data Processing Unit,DPU)(如圖 2 所示)。

    圖 2、企業和組織資料中心除了原有的 CPU/GPU 資源之外,現在也需要 DPU 資源

    目前,DPU 以 SmartNIC 的型態推出(如圖 3 所示),它的外型雖然和 PCIe 介面卡相同,但是 SmartNIC 內含 ARM CPU 處理器,和支援編譯功能的加速器,並且通常配置 10Gb 到 100Gb 的多個通訊埠,以及一個用於管理用途的乙太網路通訊埠,最重要的是 SmartNIC 有個本地端儲存資源,提供管理人員安裝軟體,例如,將 ESXi 虛擬化管理程序安裝於其中。
    目前,NVIDIA、AMD、Pensado、Intel、Dell、HPE……等廠商,皆有推出 SmartNIC 產品。
    圖 3、SmartNIC 運作架構示意圖

    現在,我們已經知道 SmartNIC 能夠整合高效能的網路介面進行資料傳輸,那麼安裝在 x86 硬體伺服器上的 SmartNIC,以及 x86 硬體伺服器上原有的工作負載,例如,NSX Service、vSAN Data Servies……等,如何無縫並且有效的卸載至 SmartNIC 上,這便是我們接下來所要討論的 Project Monterey(如圖 4 所示)。

    圖 4、Project Monterey 運作架構示意圖

    簡單來說,在最新 vSphere 8 版本中,推出的「分佈式服務引擎」(Distributed Services Engine,DSE)特色功能(如圖 5 所示),就是剛才所提到的 Project Monterey 正式版本。現在,管理人員可以在 vSphere 8 運作架構中,直接在 DPU 上安裝另一個 ESXi 執行程序,讓上層的 ESXi 專心處理運算的工作負載即可,而 NSX 及 vSAN Data 網路傳輸作業的部份,則直接卸載給底層 DPU 上的 ESXi 處理,讓上層的 ESXi 能夠處理和承載更多的 VM 虛擬主機和容器。

    圖 5、vSphere DSE 分佈式服務引擎運作架構示意圖

    值得注意的是,企業和組織除了配置 DPU 硬體介面卡之外,必須搭配最新的 vDS 虛擬分佈式交換器「8.0」的版本和 NSX 服務,並且在新增 vDS 分佈式交換器時,組態設定採用的 DPU 廠商(如圖 6 所示),才能順利將工作負載卸載到底層的 DPU 上,並且不會增加任何 ESXi 的 CPU 運算資源開銷。

    圖 6、選擇 DPU 技術以便卸載網路服務至 DPU



    整合 GPU 和 NIC 裝置

    透過最新的「裝置群組」(Device Group)機制,讓連接在同一個 PCIe Switch 的 GPU 和 NIC 裝置,除了支援原有廠商所提供的「互連」(Interconnect)機制之外,不同的裝置之間可以透過裝置群組機制整合在一起,並且提供給上層運作的 VM 虛擬主機使用,有效減少管理人員手動處理的流程和時間(如圖 7 所示)。

    圖 7、裝置群組機制運作示意圖

    因此,透過裝置群組整合後的單一裝置,對於 VM 虛擬主機來說同樣只是新增一個單一 PCI Device 即可,並且配置裝置群組的這樣的 VM 虛擬主機,仍然支援 DRS VM Placement 機制,以及 vSphere HA 高可用性機制。

    當管理人員為 VM 虛擬主機配置裝置群組時,在新增 PCI Device 作業流程中,系統將會顯示已經裝置群組後的狀態,如圖 8 所示,第一個 PCI 裝置便是二個 GPU 透過 NVLink 所組合,第二個 PCI 裝置則是 GPU 整合 NIC 的裝置。

    圖 8、為 VM 虛擬主機新增裝置群組後的 PCI Device



    彈性化虛擬硬體裝置 DVX

    在過去的版本中,一旦組態設定 VM 虛擬主機使用 DirectPath I/O 直連機制時,可以得到完全使用底層硬體裝置效能的好處,然而這個直連機制的副作用,便是導致 VM 虛擬主機喪失某些 vSphere 特色功能,舉例來說,這樣的 VM 虛擬主機無法執行 vSphere vMotion 進行遷移,也無法被 vSphere DRS 自動執行調度作業,更無法被 vSphere HA 高可用性機制所保護,此外也無法針對 VM 虛擬主機進行暫停作業,和針對 vMemory 記憶體及 vDisk 虛擬硬碟進行快照。

    現在,最新的 vSphere 8 版本中,推出「虛擬裝置擴充模組」(Device Virtualization Extensions,DVX),是基於 Dynamic DirectPath I/O 技術之上,並為裝置廠商提供新的運作框架和 API。因此,底層的 ESXi 安裝 DVX 驅動程式,上層的 VM 虛擬主機使用支援 DVX 機制的虛擬裝置,達成高效能使用底層硬體的目的,同時又能保有 vSphere 特色功能,例如,透過 vSphere DRS 自動執行調度作業,並被 vSphere HA 高可用性機制所保護(如圖 9 所示)。

    圖 9、DVX 虛擬裝置擴充模組運作流程示意圖



    TKG 2.0 和 vSphere Zone

    事實上,在 vSphere 7 版本時,便加入 vSphere with Tanzu 新特色功能,也就是將原有 vSphere 叢集,重新建構為支援容器工作負載的 Kubernetes 叢集,讓 ESXi 虛擬化平台成為 Kubernetes 容器平台的 Worker 節點,並在 ESXi 上直接運作容器 Pod。

    同時,也推出支援有雲和公有雲部署的 TKG(Tanzu Kubernetes Grid),也就是支援企業和組織在地端資料中心內部署的 TKGs(Tanzu Kubernetes Grid Service for vSphere),以及部署至公有雲的 TKGm(Tanzu Kubernetes Grid Multi-Cloud)

    現在,最新的 vSphere 8 版本中,重新整合為統一的 Kubernetes 容器平台,無論是部署到地端資料中心或公有雲,都是採用同一套的 TKG 2.0 版本,並且加入新的「vSphere Zone」隔離機制,支援跨越多個 vSphere 叢集進行整合,以便獲得最大的可用性和資源,搭配來自 Cluster API 開放源始碼中的 ClusterClass 宣告機制,以便能夠管理人員能夠決定將容器部署成跨 vSphere 叢集,或是在各自的 vSphere 叢集中互相隔離工作負載(如圖 10 所示)。

    圖 10、TKG 2.0 和 vSphere Zone 運作架構示意圖



    vCenter 智慧型復原 DKVS

    對於 vSphere 基礎架構有管理經驗的人來說,一定知道整個 vSphere 運作架構的組態設定和統計資料,都是儲存在 vCenter Server 管理平台當中。雖然,統一式的集中管理有其優勢,然而碰上災難事件時卻有可能會產生盲點。

    舉例來說,管理人員定期在「每天凌晨 3 點」為 vCenter Server 執行備份作業,但是 vCenter Server 卻在晚上 8 點時發生災難事件,此時即便立即為 vCenter Server 執行備份復原作業,但是從凌晨 3 點到晚上 8 點之間,仍然發生許多事件和各項工作負載的統計資料,因此復原後的 vCenter Server 管理平台,將會遺失這段期間的事件和統計資料。

    在最新 vSphere 8 版本中,推出「分散式鍵值儲放區」(Distributed Key-Value Store,DKVS)機制,這項機制的設計原理,在於當 vCenter Server 管理平台發生災難時,事實上這段期間發生的事件和統計資料,也都儲存在 ESXi 主機當中。

    因此,當 vCenter Server 管理平台進行災難復原後,與 vSphere 叢集中的眾多 ESXi 節點主機進行溝通,並將災難發生至上次備份時間期間的事件和統計資料取回,讓 vCenter Server 管理平台能夠迅速恢復,並且取得 vSphere 叢集和 ESXi 節點主機的最新資訊(如圖 11 所示)。

    圖 11、DKVS 分散式鍵值儲放區運作架構示意圖



    vMMR v2 增強記憶體監控機制

    在 vSphere 虛擬化基礎架構中,對於工作負載的記憶體使用量和監控機制,一直是 VMware 努力增強和改進的方向,以便能夠承載更多的工作負載於 vSphere 架構中。從 vSphere 7 U3 版本開始,推出「vSphere 記體體監控和修復」(vSphere Memory Monitoring and Remediation,vMMR)機制。

    現在,最新 vSphere 8 版本中,將原有 vMMR 記體體監控和修復增強至 vMMR v2版本(如圖 12 所示),透過更智慧的記憶體監控和修復機制,有效增強 vSphere DRS 自動化調度工作負載,讓 VM 虛擬主機和容器等工作負載,能夠在最佳化的 DRS 調度決策中得到最充足的資源,確保 VM 虛擬主機和容器內的營運服務得到最佳效能和各項資源。

    圖 12、vMMR v2 記體體監控和修復管理畫面示意圖



    vMotion Notifications 敏感型應用程式專用 

    在過去的 vSphere 版本中,雖然 vMotion 線上遷移機制,能夠滿足絕大多數應用程序的需求,並且在遷移過程中和遷移後,對於應用程式都是無縫且透過的遷移,並不會對應用程式造成任何影響。

    然而,對於某些「時間敏感應用程式」(Time-Sensitive Application)、VoIP、叢集服務等,可能會產生不良的影響,舉例來說,可能在執行 vMotion 遷移期間導致 VoIP 掉線,或者是觸動到叢集服務的心跳機制,導致引發容錯移轉叢集切換的動作。

    因此,在 vSphere 8 版本中推出「vMotion 通知」(vMotion Notifications)機制,能夠針對這些特定的應用程式進行通知後才遷移,確保應用程式準備完畢後才進行遷移的動作。下列為 VM 虛擬主機執行 vMotion 通知時的執行步驟(如圖 13 所示):
    1. 管理人員為 VM 虛擬主機執行 vMotion 線上遷移。
    2. VM 虛擬主機中的應用程式,收到 vMotion 遷移程序開始執行的通知。
    3. 應用程式開始準備 vMotion 遷移作業。
    4. 應用程式發送「確認」(Acknowledgement)訊息,給 vMotion 遷移程序確認可以開始執行遷移作業。
    5. 系統透過 vMotion 機制線上遷移 VM 虛擬主機至別台 ESXi 節點主機。
    6. 應用程式收到 vMotion 遷移程序通知遷移作業已完成。

    圖 13、vSphere vMotion Notification 遷移流程示意圖

    值得注意的是,預設並不會為 VM 虛擬主機啟用 vMotion 通知機制,因為必須要為應用程式進行改寫的動作才行。此外,啟用 vMotion 通知機制的 VM 虛擬主機,也將無法透過 vSphere DRS 進行自動化調度,僅能由管理人員手動觸發進行 vMotion 遷移作業。





    實戰 – vSphere vMotion UDT 傳輸機制

    在過去的 vSphere 版本中,不斷增強和提升 vSphere vMotion 線上遷移的能力,讓企業和組織在需要遷移運作中的 VM 虛擬主機工作負載時,無論是遷移運算資源的 vSphere vMotion,或是遷移儲存資源的 vSphere Storage vMotion 機制,都能以最快的速度完成線上遷移作業,避免 VM 虛擬主機中的營運服務產生任何卡頓甚至中斷的情況。

    然而,有些管理人員可能發現,透過 vSphere vMotion 機制線上遷移運作中的 VM 虛擬主機時,確實能夠在最短時間內遷移完成,倘若是遷移「關閉」(Power Off)的 VM 虛擬主機,尤其是配置大容量儲存空間時,那麼遷移時間將需要很長時間,甚至同樣的遷移情境,將 VM 虛擬主機「開機」(Power On)後進行遷移,反而遷移時間縮短許多,為何會有這種遷移時間差異的情況出現 ?

    主要原因在於,「線上遷移」(Hot Migration)的執行程序、I/O 同步機制、傳輸效能,都與「離線遷移」(Cold Migration)不同所導致,舉例來說,VM 虛擬主機運作中執行遷移時採用的 Hot Migration,將會採用最佳化後的「多執行緒」(Multi-Thread),與 ESXi 節點主機的多核心協同運作,傳輸效能最高可達 80Gbps

    反觀 VM 虛擬主機關閉時執行遷移採用的 Cold Migration,採用的則是「網路文件複製」(Network File Copy,NFC)通訊協定,並且採用「單執行緒」(Single-Thread),僅使用 ESXi 節點主機的單顆核心進行運算,傳輸效能最高僅能到達 1.3Gbps(如圖 14 所示)。
    請注意,VM 虛擬主機帶有快照時,即便執行 Hot Migration 線上遷移作業,也會自動改為採用 NFC 通訊協定進行資料傳輸。
    圖 14、vSphere vMotion 與 NFC 通訊協定和傳輸效能比較表



    UDT 傳輸機制

    在新版 vSphere 8 當中,採用「統一資料傳輸」(Unified Data Transport,UDT)機制,來處理 Cold Migration 遷移的 VM 虛擬主機傳輸作業。一旦 VM 虛擬主機關閉並且觸發 Cold Migration 遷移作業時,系統將會以原有的 NFC 通訊協定為「控制通道」(Control Channel),而「資料傳輸」(Data Transfer)的部份則會改採 vSphere vMotion 通訊協定,以便提升傳輸效能和傳輸速度節省大量時間。

    值得注意的是,有些管理人員會忽略 ESXi 節點主機的 VMkernel Port 組態設定,進而造成傳輸速度上異常緩慢,舉例來說,管理人員並未將 ESXi 節點主機的傳輸流量類型隔開,將 Management 和 vMotion 流量類型混用,而一般來說 Management 管理網路可能只有 1Gbps 的傳輸速度,因此執行 Migration 遷移作業時便導致傳輸效率不彰。

    又或者是,已經將實體網路和 ESXi 節點主機的傳輸流量類型隔開,但是在組態設定上卻忽略 VMkernel Port 的部份,未將原有共用 Management 網路的 vMotion 取消勾選,造成 Migration 遷移作業時仍舊使用 Management 慢速網路進行傳輸(如圖 15 所示)。

    圖 15、在 Management 慢速管理網路中啟用 vMotion 傳輸流量類型

    當管理人員執行 Migration 遷移作業時,系統如何判斷使用的遷移網路 ?舉例來說,執行 Hot Migration 時將會使用 vMotion Network,而使用 Cold Migration 時則會使用 Management Network(如圖 16 所示),管理人員也可以使用此方式,確認組態設定和實體網路的規劃是否一致,確保 Migration 遷移作業執行時,網路傳輸能夠如同規劃般順利執行並快速傳輸完畢。

    圖 16、Hot Migration 和 Cold Migration 使用傳輸網路流程圖



    採用傳統 NFC 的 Cold Migration

    在實戰演練小節中,採用最新的 vSphere 8 IA 版本,搭配最新的 vCenter Server 8.0(Build 20519528)管理平台,在 UDT 傳輸測試流程的 VM 虛擬主機,則是配置 2 vCPU、8 GB vRAM、50 GB Thick Provision Eager Zeroed 類型的虛擬硬碟(如圖 17 所示)。

    圖 17、測試新式 UDT 傳輸機制的 VM 虛擬主機配置

    首先,在此實作中率先測試使用傳統 NFC 通訊協定進行 Cold Migration,針對這樣的 VM 虛擬主機配置將其關機之後進行遷移,觀察將會花費多少傳輸時間。

    目前,測試的「UDT-TestVM」虛擬主機運作於 Node02 節點主機上,在 vCenter 管理介面中,依序點選「UDT-TestVM > Actions > Migrate」,在彈出的 Migration 互動視窗中,選擇「Change both compute resource and storage」選項後,按下 Next 鈕繼續 Cold Migration 流程(如圖 18 所示)。

    圖 18、針對關機中的 VM 虛擬主機,執行 Cold Migration 遷移作業

    在 2. Select a compute resource 頁面中,選擇要將 UDT-TestVM 虛擬主機運算資源,遷移至虛擬化基礎架構中哪一台 ESXi 主機,在本文實作環境中選擇「node01.lab.weithenn.org」,並確認下方相容性檢查結果為「Compatibility checks succeeded.」後按下 Next 鈕。

    在 3. Select storage 頁面中,選擇要將 UDT-TestVM 虛擬主機儲存資源,遷移至虛擬化基礎架構中哪一個 Datastore 中,在本文實作環境中選擇「Node01-datastore」,此時在下方相容性檢查結果,將會警告管理人員「This can lead to lower network copy throughput.」,目前的傳輸網路吞吐量不佳的警告訊息,但是仍然能夠按下 Next 鈕繼續遷移流程。

    在 4. Select networks 頁面中,選擇 UDT-TestVM 虛擬主機虛擬網路,是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組,在本文實作環境中採用預設值即可。最後,在 5. Ready to complete 頁面中,確認相關資訊無誤後按下 Finish 鈕,便立即執行 NFC 通訊協定的 Cold Migration 遷移作業。

    此時,可以在 vCenter 管理介面下方 Recent Tasks 區塊,看到 Cold Migration 遷移作業的執行進度,或是切換到「Cluster > Monitor > Tasks and Events > Tasks」,查看更詳細的 Cold Migration 遷移作業內容,從結果中可以看到此次採用傳統 NFC 通訊協定的遷移作業花費「6 分 12 秒」(如圖 19 所示)。

    圖 19、採用傳統 NFC 通訊協定執行 Cold Migration 遷移作業所花費的時間



    使用新式 UDT 的 Cold Migration

    在使用新式 UDT 機制進行 Cold Migration 遷移之前,必須先為來源端和目的端的 ESXi 節點主機,針對 VMkernel Port 進行組態設定,才能確保稍後使用 Cold Migration 遷移作業時,使用新式的 UDT機制,而非傳統的 NFC通訊協定進行資料傳輸。

    請在 vCenter 管理介面中,依序點選「ESXi Host > Configure > Networking > VMkernel adapters > Edit」,在 VMkernel Port 組態設定視窗中,勾選「Provisioning」項目後按下 OK 鈕(如圖 20 所示)。

    圖 20、在 VMkernel Port 組態設定視窗中勾選 Provisioning 項目

    確保來源端和目的端的 ESXi 節點主機,都已經為遷移網路的 VMkernel Port 啟用「Provisioning」類型後,同樣的遷移情境,此時的 UDT-TestVM 虛擬主機,將從剛才的 Node01 遷移回 Node02,並觀察遷移作業時間與剛才傳統的 NFC 通訊協定有何不同。

    請在 vCenter 管理介面中,依序點選「UDT-TestVM > Actions > Migrate」,在彈出的 Migration 互動視窗中,選擇「Change both compute resource and storage」選項後,按下 Next。在 2. Select a compute resource 頁面中,選擇要將 UDT-TestVM 虛擬主機運算資源,遷移至虛擬化基礎架構中哪一台 ESXi 主機,在本文實作環境中選擇「node02.lab.weithenn.org」,並確認下方相容性檢查結果無誤後按下 Next 鈕。

    在 3. Select storage 頁面中,選擇要將 UDT-TestVM 虛擬主機儲存資源,遷移至虛擬化基礎架構中哪一個 Datastore 中,在本文實作環境中選擇「Node02-datastore」,此時在下方相容性檢查結果,並不會像剛才實作 NFC 通訊協定時產生警告訊息,而是通過相容性檢查的「Compatibility checks succeeded.」訊息(如圖 21 所示),請按下 Next 鈕繼續遷移流程。

    圖 21、選擇儲存資源時順利通過系統相容性檢查作業

    在 4. Select networks 頁面中,選擇 UDT-TestVM 虛擬主機虛擬網路,是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組,在本文實作環境中採用預設值即可。最後,在 5. Ready to complete 頁面中,確認相關資訊無誤後按下 Finish 鈕,便立即執行採用新式 UDT 機制的 Cold Migration 遷移作業。

    同樣的,在 vCenter 管理介面下方 Recent Tasks 區塊,看到 Cold Migration 遷移作業的執行進度,或是切換到「Cluster > Monitor > Tasks and Events > Tasks」,查看更詳細的 Cold Migration 遷移作業內容,從結果中可以看到改採新式 UDT 機制的遷移作業僅花費「39 秒」便遷移完成(如圖 22 所示)。

    圖 22、改採新式 UDT 機制的遷移作業僅花費 39 秒便遷移完成





    結語

    透過本文的深入剖析和實作演練後,相信管理人員對於最新 vSphere 8 的亮眼特色功能,已經有更深一層的認識和理解。同時,在實作演練小節中,實作最新 vSphere 8 中支援的新式 UDT 機制,讓關機中卻有遷移需求的 VM 虛擬主機,同樣達到快速遷移的目的有效縮短資料傳輸時間。

    VMware vSphere 8 攻略 - 系列文章

    $
    0
    0


    簡介

    在 2022 年 VMware Explore 大會上,VMware 官方正式發佈最新 vSphere 8 版本。同時,從 vSphere 8 版本開始,VMware 官方採用新的版本發佈模型,分別稱為「初始可用性」(Initial Availability,IA)「通用可用性」(General Availability,GA),簡單來說,新的版本發佈方式和 vSphere+ 雲端服務版本將保持一致。後續,站長也將不定期針對最新 VMware vSphere 8 版本,各種亮眼特色功能進行深入剖析和實戰演練。 




    網管人技術專欄

    Failed to deploy OVF package. ThrowableProxy.cause

    $
    0
    0


    Question:

    最近有需求,在二個不同 Region 的 vCenter Server,需要把 VM 從 Region-A 部署到 Region-B,最簡單的方式就是在 Region-A 的 vCenter Server,把 VM 關機後執行 Export OVF Template的動作,然後切換到 Region-B 的 vCenter Server,執行 Deploy OVF Template的動作即可。

    想不到這種一塊小蛋糕的動作,在執行 Deploy OVF Template 的動作時,居然發生「Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred: Transfer failed: The OVF descriptor is not available.」的錯誤訊息 (如下圖所示),無法順利部署 OVF Template?




    Answer:

    參考 Solved: Failed to deploy OVF package. throwableProxy.cause... - VMware Technology Network VMTN 論壇的討論串。雖然,本文實作環境是 vCenter 7.0 U2,而討論串內是 6.7.0 版本,不過實作後能成功解決問題。

    簡單來說,在執行 Deploy OVF Template 的動作時,直接選擇 ESXi node 或本文環境的 vSAN Node 後,再執行 Deploy OVF Template 的動作便可順利部署成功。



    升級至最新 vSphere 8 (模擬練習動手玩)

    $
    0
    0


    簡介

    對於最新版本 vSphere 8 的眾多亮眼新功能,不知道你是否也躍躍欲試? 苦於沒有環境實作,或是擔心不熟升級至 vSphere 8 版本的工作流程?

    現在,你可以透過 vSphere Simulation Library,快速練習升級至最新 vSphere 8 版本的工作流程。如下圖所示,可以看到目前共有五個模擬練習項目:




    怎麼練習?

    練習方式非常簡單,舉例來說,首先模擬練習 Upgrade to vCenter 8 (Stage 1) 升級流程,點選該區塊的 View ISM Demo即可,接著只要看畫面和相關說明,並點選「橘色框」 即可繼續。


    接著,就像你準備升級至 vCenter Server 8 的階段 1 流程一樣,放入 vCenter ISO 印像檔,然後選擇「Upgrade」。


    後續的流程,依據指示並按相對應的「橘色框」 即可繼續,並且完整的模擬演練升級至 vCenter Server 8 的階段 1 流程。


    完成模擬練習後,只要關閉並另開新的 Upgrade to vCenter 8 (Stage 2)練習即可。


    同樣的,依據指示並按相對應的「橘色框」 即可繼續,並且完整的模擬演練升級至 vCenter Server 8 的階段 2 流程。


    再來,挑選一種你習慣升級 vSphere Cluster 和 ESXi 的方式,例如,Upgrade a vSphere cluster to vSphere 8 using Baselines練習。


    依據指示並按相對應的「橘色框」 ,建立新版 vSphere 8 的升級版本基準線。


    準備將原有的 vSphere Cluster 和 ESXi 7.0.3 環境,進行版本升級的動作。


    順利將 vSphere Cluster 和 ESXi 7.0.3,升級成最新 vSphere Cluster 和 ESXi 8.0.0 版本。


    在手邊沒有資源建環境,卻又想練習時,vSphere Simulation Library 確實是個不錯的參考資源,有興趣的朋友不妨試試。 😁

    Add-AppxPackage: Deployment failed with HRESULT: 0x80073CF3

    $
    0
    0


    Question:

    GitHub - Microsoft / Terminal 網站上,下載最新版本的 Windows Terminal v1.16.1026並嘗試安裝時,得到「Add-AppxPackage: Deployment failed with HRESULT: 0x80073CF3」的錯誤訊息 (如下圖所示):




    Answer:

    簡單來說,從錯誤訊息中可以看到,系統提示必須要安裝 C++ Runtime Framework for Desktop Bridge (Microsoft.VCLibs.140.00.UWPDesktop)套件才行,下載完成先安裝 C++ Runtime Framework 套件後,即可順利安裝Windows Terminal,安裝完成後無須重新啟動主機,即可在開始選單中發現新增的Windows Terminal。


    vSphere 8 - vMotion Notifications

    $
    0
    0

    簡介

    在過去的 vSphere 版本中,雖然 vMotion 線上遷移機制,能夠滿足絕大多數應用程序的需求,並且在遷移過程中和遷移後,對於應用程式都是無縫且透過的遷移,並不會對應用程式造成任何影響。

    然而,對於某些「時間敏感應用程式」(Time-Sensitive Application)、VoIP、叢集服務等,可能會產生不良的影響,舉例來說,可能在執行 vMotion 遷移期間導致 VoIP 掉線,或者是觸動到叢集服務的心跳機制,導致引發容錯移轉叢集切換的動作。
    • vMotion Notifications 功能影片說明區間為 32:21~35:55





    vMotion Notifications 運作機制

    因此,在 vSphere 8 版本中推出「vMotion 通知」(vMotion Notifications)機制,能夠針對這些特定的應用程式進行通知後才遷移,確保應用程式準備完畢後才進行遷移的動作。值得注意的是,預設並不會為 VM 虛擬主機啟用 vMotion 通知機制,因為必須要為應用程式進行改寫的動作才行。此外,啟用 vMotion 通知機制的 VM 虛擬主機,也將無法透過 vSphere DRS 進行自動化調度,僅能由管理人員手動觸發進行 vMotion 遷移作業。


    下列為 VM 虛擬主機執行 vMotion 通知時的執行步驟:
    1. 管理人員為 VM 虛擬主機執行 vMotion 線上遷移。
    2. VM 虛擬主機中的應用程式,收到 vMotion 遷移程序開始執行的通知。
    3. 應用程式開始準備 vMotion 遷移作業。
    4. 應用程式發送「確認」(Acknowledgement)訊息,給 vMotion 遷移程序確認可以開始執行遷移作業。
    5. 系統透過 vMotion 機制線上遷移 VM 虛擬主機至別台 ESXi 節點主機。
    6. 應用程式收到 vMotion 遷移程序通知遷移作業已完成。




    vMotion Notifications Demo

    來看看 VMware 官方實際展示 vMotion Notifications 機制運作的效果。




    學習資源

    網管人 205 期 - 部署微軟 AzSHC I超融合,精省單機叢集享最高彈性

    $
    0
    0

     


    網管人雜誌

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




    本文目錄

    前言
    Azure Stack HCI 22H2 特色功能
              Hyper-V 即時移轉增強無交換器架構
              儲存體複本壓縮
              磁碟區格式轉換
              Network ATC v2
    實戰 – Single-Node Azure Stack HCI Cluster
              基礎設定
              建立容錯移轉叢集並啟用 S2D 技術
              註冊單台 AzSHCI 叢集
              將固定磁碟區轉換為精簡佈建磁碟區
    結語




    前言

    在過去的 Azure Stack HCI 超融合基礎架構版本中,叢集節點的主機數量最少必須要「2 台」才行。然而,在 微軟 Build 2022 大會上,正式發佈「Azure Stack HCI Single-Node」解決方案,打破過去版本最少 2 台叢集節點主機的限制,現在企業和組織只要花費「1 台」節點主機的預算,便能在小型零售店或分公司,運作靈活性和高彈性高效能的 Azure Stack HCI 超融合架構,並且依照專案成長和商務需求,也能逐步將 Azure Stack HCI 超融合叢集擴充至最多「16 台」節點主機的運作架構。

    後續將 Azure Stack HCI 超融合基礎架構,簡稱為 AzSHCI 。


    為何微軟會推出 AzSHCI 單台版本,主要在於聽取各方使用者的意見,希望能夠以更少的硬體設備,更低的 IT 預算,具備同樣高彈性擴充的目的,並且單台和多台超融合版本具備同樣的特色功能,例如,Azure BenefitsAVD 虛擬桌面AKS 容器服務……等。


    目前,主流的 x86 伺服器硬體供應商,皆有提供支援單台 AzSHCI 版本的伺服器,管理人員在導入之前可以至 Azure Stack HCI Catalog 網站,查詢企業和組織慣用的 x86 伺服器中,哪些型號支援單台 AzSHCI 版本(如圖 1 所示),在本文撰寫期間共有 224 台 x86 伺服器,支援建構單台 AzSHCI 環境。


    圖 1、透過 AzSHCI Catalog 網站,查詢支援單台超融合的 x86 伺服器


    值得注意的是,單台 AzSHCI 版本僅支援採用單一儲存裝置,例如,NVMe 或 SSD 的 All-Flash 運作架構,不支援採用混合式儲存裝置,例如,NVMe+SSD、NVMe+HDD、SSD+HDD……等。此外,僅支援採用 Azure Stack HCI 作業系統建置單台 AzSHCI 環境,不支援使用 Windows Server 上的 Storage Spaces Direct 技術建構單台超融合環境。


    微軟 Ignite 2022 大會中,正式發佈將於 2023 年開始,提供由微軟設計和支援,專為 Azure Stack HCI 環境打造的「Azure Stack HCI Pro 2」硬體伺服器(如圖 2 所示),僅具備 2U 高度半深的外型尺寸,且產生的噪音低於 60 dBA,因此非常適合部署在零售、製告、醫療保健……等邊緣運作場所。


    圖 2、專為 Azure Stack HCI 超融合環境打造的 Pro 2 硬體伺服器




    Azure Stack HCI 22H2 特色功能

    在 Azure Stack HCI 22H2 版本中,除了將原有特色功能增強之外,也新增不少亮眼特色功能,例如,儲存體複寫壓縮、Network ATC v2、Hyper-V 即時移轉……等。



    Hyper-V 即時移轉增強無交換器架構

    在過去的 AzSHCI 版本中,在小型規模「2 – 3 台」叢集節點主機運作架構時,企業和組織為了節省 IT 預算,經常會採用「無交換器」運作架構,也就是僅「南 - 北」(South-North)向網路流量需要網路交換器,而「東 - 西」(East-West)向網路流量則無須配置網路交換器(如圖 3 所示)。


    圖 3、Azure Stack HCI 無交換器運作架構示意圖


    雖然,能夠有效節省整體建置預算,並且降低初始網路組態的設定複雜度。但是,管理人員應該會發現,屆時嘗試透過 Hyper-V 即時遷移,線上移轉運作中的 VM 虛擬主機時,相較於使用網路交換器的運作架構來說,無交換器的 Hyper-V 即時遷移「網路延遲」(Network Latency)時間較高。


    新版 AzSHCI 22H2 版本中,已經完全解決採用無交換器運作架構時,Hyper-V 即時遷移網路延遲的問題,讓小型規模的 AzSHCI 環境,擁有更快速更穩定的 Hyper-V 即時遷移效能。



    儲存體複本壓縮

    在最新的 AzSHCI 22H2 版本中,針對儲存體複本技術開始支援壓縮功能,達成 「儲存體複本壓縮」(Storage Replica Compression)機制。簡單來說,建立儲存體複本群組的方式無須任何變更,只要建立時加上「-EnableCompression」參數即可,例如,「New-SRGroup -EnableCompression」。


     一旦啟用壓縮機制之後,系統將會在儲存體複本壓縮來源端將需要複寫傳送的資料,進行壓縮、網路傳輸至目的端、目的端解壓縮……等(如圖 4 所示)。由於,複寫資料壓縮後,將會產生較少的網路封包但傳輸相同的複寫資料量,所以能提供較高的資料傳送量和較低的網路頻寬使用率,進而降低企業和組織在網路頻寬上成本。


    圖 4、儲存體複本運作架構示意圖


    值得注意的是,倘若管理人員在建立儲存體複本群組時,未指定啟用壓縮技術的話,那麼系統預設便不會啟用壓縮技術並自動設定為「停用」(Disabled)狀態,後續必須額外組態設定啟用壓縮技術才行,例如,額外執行 Set-SRGroup -Compression $true指令。



    磁碟區格式轉換

    在過去的 AzSHCI 版本中,建立的磁碟區格式都為「固定」(Fixed)格式,雖然可以得到最佳化儲存效能,但是在整體儲存資源空間的使用率上則缺乏彈性,舉例來說,管理人員建立 1TB 儲存空間的超融合磁碟區,然後在這個 1TB 儲存空間中,即便 VM 虛擬主機工作負載僅使用掉 100GB 的儲存空間,對於整體儲存資源空間的使用率來說,還是佔用 1TB 的儲存空間。


    現在,最新的 AzSHCI 22H2 版本中,除了支援建立「精簡佈建」(Thin Provision)磁碟區之外,也支援將現有的固定格式磁碟區,轉換為新式的精簡佈建磁碟區。簡單來說,採用精簡佈建磁碟區之後,系統將會轉換並傳回在磁碟區中未使用的儲存空間回到儲存集區,以便系統提供給其它磁碟區使用,並且在磁碟區新增或移除資料時,磁碟區的儲存空間也將動態隨之增加和減少,確保儲存集區空間的使用彈性(如圖 5 所示)。


    圖 5、固定和精簡佈建格式磁碟區儲存空間使用率示意圖



    Network ATC v2

    在最新 AzSHCI 22H2 版本中,針對 Network ATC 有多項功能增強和新特色功能,協助管理人員無論是在初期部署 AzSHCI 環境,或是後續的持續管理和叢集擴充,有助於簡化管理成本並得到更高的可靠性。


    過去,在建構 AzSHCI 環境之前,必須先組態設定並配置適合的網路卡,加入至 SET(Switch-Embedded Teaming)當中擔任成員網路卡,然而舊版本中必須依賴管理人員手動檢查和驗證,確保採用相同網路卡製造商、型號、傳輸速度的網路卡進行綁定作業,倘若管理人員不小心疏忽仍能進行綁定作業,但有可能造成屆時 AzSHCI 環境不穩定,舉例來說,管理人員將 10Gb 和 40Gb 網路混用,這將造成 AzSHCI 環境網路傳輸不穩定(如圖 6 所示)。


    圖 6、系統檢查出欲加入綁定的成員網路卡傳輸速度不一致,所以中斷 SET 綁定作業


    現在,透過「網路對稱」(Network Symmetry)特色功能,當管理人員準備將網路卡加入 SET 進行綁定作業時,系統將會針對網路卡製造商、硬體型號、傳輸速度等三項進行檢查,確保一致後才能將指定的網路卡加入至 SET 當中擔任成員網卡,並自動完成綁定作業(如圖 7 所示)。


    圖 7、系統檢查網路卡製造商、硬體型號、傳輸速度是否一致後,才建立 SET 並進行綁定


    在過去舊版中,系統預設會配置給 AzSHCI 環境中,擔任儲存資源網路卡 APIPA 位址,也就是 169.254.x.x 的 IP 位址,但這種自動配置方式並不理想。因此,在最新 AzSHCI 22H2 版本中,提供「IP 位址自動指派」(Automatic IP Assignment),除了自動指派 IP 位址之外,還會自動處理網路卡屬性配置、組態設定「資料中心橋接」(Data Center Bridging,DCB)、檢查是否需要建立 vSwitch 虛擬網路交換、倘若檢查後需要便自動建立 vSwitch 虛擬網路交換、將實體網路卡和建立的 vSwitch 虛擬網路交換綁定、分配 VLAN……等動作(如圖 8 所示)。


    圖 8、Network ATC 部署主機網路功能示意圖


    在過去舊版中,建立 AzSHCI 環境時,系統預設指派給容錯移轉叢集的網路,都是「Cluster Network <數字>」的命名規則,然而這樣的命名規則並沒有意義,通常需要管理人員手動重新命名。現在,透過 Network ATC 部署和定義網路組態設定時,系統得知如何使用網路卡和網路環境,並透過新式的「叢集網路命名」(Cluster Network Naming)機制處理,所以能更恰當的為叢集網路進行命名,讓管理人員容易得知哪些網路用於運算資源,哪些網路用於儲存資源。




    實戰 – Single-Node Azure Stack HCI Cluster

    首先,請下載最新 Azure Stack HCI 22H2 印象檔版本,在本文實作環境中,準備一台 DC 網域控制站,網域名稱為「lab.weithenn.org」,而 AzSHCI 主機除了作業系統硬碟之外,額外配置四個 1TB SSD 固態硬碟,屆時為超融合儲存集區的儲存空間,AzSHCI 安裝程序和傳統 Windows Server 安裝程序非常類似(如圖 9 所示),安裝作業完成後系統將自動彈出命令提示字元視窗,並提醒管理人員設定 Administrator 管理者密碼,完成管理者密碼設定之後,便自動進入「伺服器組態設定工具」(Server Configuration Tools,SConfig)互動設定視窗。


    圖 9、安裝最新 Azure Stack HCI 22H2 版本作業系統



    基礎設定

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


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


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


    基礎設定完成後,首先確認額外配置的四個 1TB SSD 固態硬碟,AzSHCI 主機是否能夠順利識別,確保稍後建立超融合儲存集區時,能夠順利將 SSD 固態硬碟加入至儲存集區內。請使用「Get-PhysicalDisk | Sort-Object -Property Size」PowerShell 指令,檢查 AzSHCI 主機儲存裝置,並確保四個 1TB SSD 固態硬碟的 CanPool 欄位值為「True」,表示儲存裝置能夠加入超融合儲存集區中(如圖 11 所示)。


    圖 11、確保 AzSHCI 主機能夠順利識別四個 1TB SSD 固態硬碟


    執行「Install-WindowsFeature」PowerShell 指令,安裝建構 AzSHCI 環境時,必要的伺服器角色和功能,例如,DCB 資料中心橋接(Data-Center-Bridging)、容錯移轉叢集(Failover-Clustering)、Hyper-V 虛擬化、檔案伺服器(FS-FileServer)……等(如圖 12 所示),待安裝程序完成後系統提醒必須重新啟動主機才能套用生效,請鍵入「Restart-Computer」指令即可重新啟動主機。


    圖 12、為 AzSHCI 主機安裝必要的伺服器角色和功能



    建立容錯移轉叢集並啟用 S2D 技術

    在本文撰寫期間,最新的 WAC(Windows Admin Center)2110.2版本,仍尚未支援部署和組態設定「單台」AzSHCI 環境,因此在部署 AzSHCI 的 1.2 Add servers 階段時,系統便會顯示警告,必須要「2 - 16」台節點主機才支援部署作業(如圖 13 所示)。


    圖 13、最新的 WAC 2110.2 版本,仍尚未支援部署單台 AzSHCI 環境


    因此,管理人員在現階段,必須使用 PowerShell 指令執行部署單台 AzSHCI 的動作,微軟官方也已經說明,後續 WAC 的版本將會盡快支援部署單台 AzSHCI 環境。請執行 PowerShell 指令「New-Cluster -Name <Cluster_Name> -Node <Node_Name> -NoStorage -StaticAddress <Cluster_IP_Address>」,在本文環境中容錯移轉叢集名稱為「HCI-Cluster」,節點主機名稱為「AzSHCI」,而容錯移轉叢集 IP 位址則是「10.10.75.30」,值得注意的是必須加上「-NoStorage」參數。


    順利建立容錯移轉叢集後,接著執行 PowerShell 指令「Enable-ClusterStorageSpacesDirect -CacheState Disabled」,啟用 Storage Spaces Direct 技術並停用儲存體快取機制,啟用完成後將會產生 EnableClusterS2D 報表檔案,後續可以透過 WAC 管理平台查看報表內容,最後執行「Get-StoragePool」指令,可以看到系統已經透過 S2D 技術,將四個 1TB SSD 固態硬碟整合為 4TB 的儲存集區(如圖 14 所示)。


    圖 14、建立容錯移轉叢集,啟用 S2D 技術並停用儲存體快取機制



    註冊單台 AzSHCI 叢集

    雖然,目前最新版本的 WAC 管理平台尚未支援部署單台 AzSHCI 叢集,然而一旦建立完成後,管理人員同樣能透過 WAC 管理平台,輕鬆管理和組態設定 AzSHCI 叢集以及後續工作負載,例如,建立磁碟區、VM 虛擬主機、AKS 容器平台……等。


    登入 WAC 管理平台後,請依序點選「Add > Add or create resources > Server Clusters > Add」,在 Add Cluster 欄位中鍵入「HCI-Cluster」叢集名稱,系統便會自動掃描和探索到此超融合叢集(如圖 15 所示)。


    圖 15、新增叢集名稱為 HCI-Cluster 的超融合叢集


    順利登入後,同樣可以透過 WAC 管理平台,看到 AzSHCI 超融合叢集的各種使用率和工作負載資訊,包括,超融合叢集節點主機數量和資訊、儲存裝置數量和資訊、管理 VM 虛擬主機、超融合叢集 CPU/Memory/Storage 資源使用資訊、IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率……等(如圖 16 所示)。


    圖 16、透過 WAC 輕鬆管理 AzSHCI 環境


    請為建立的 AzSHCI 叢集進行註冊的動作,後續便能導入 Azure Monitor 監控機制、享有 Azure Benefits 權益、建置 AKS 容器平台……等並達成混合雲運作架構。


    在註冊 AzSHCI 叢集之前,必須先將此台 WAC 管理平台註冊至 Azure 公有雲環境中,請點選 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 鈕(如圖 17 所示),即可將此台 WAC 註冊至指定的 Azure 訂閱帳戶和 Azure AD 環境中。


    圖 17、將此台 WAC 註冊至指定的 Azure 訂閱帳戶和 Azure AD 環境中


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


    圖 18、準備註冊 AzSHCI 叢集和 Azure Arc 管理機制


    開始註冊流程後,系統會彈出 CredSSP 視窗,請管理人員鍵入連結至 AzSHCI 叢集時,使用的 CredSSP connection 的使用者帳號和密碼,通過使用者身份驗證程序後,管理人員可以手動開啟另一個視窗,登入 Azure Portal 中的 Resource Group,可以看到會自動建立剛才指定的「RG-SoutheastAsia-AzSHCI」資源群組,進入後在 Resources 區塊中,可以看到註冊了名稱為「HCI-Cluster」的超融合叢集,進入後可以看到 AzSHCI 主機,並啟用 Azure Arc 管理機制(如圖 19 所示)。


    圖 19、註冊 AzSHCI 叢集和 Azure Arc 管理機制成功


    順利透過 Azure Portal,確認 AzSHCI 叢集和 Azure Arc 管理機制註冊完成後,切換回 WAC 管理平台視窗,可以發現顯示成功註冊資訊,而 Azure Connection 區塊中的 Status 狀態資訊,也從原先的紅色錯誤Not yet registered,變更為綠色打勾Connected狀態(如圖 20 所示)。


    圖 20、成功透過 WAC 管理平台註冊 AzSHCI 叢集



    將固定磁碟區轉換為精簡佈建磁碟區

    現在,管理人員可以直接透過 WAC 管理平台,為單台 AzSHCI 叢集建立新式的精簡佈建磁碟區,以供後續 VM 虛擬主機或檔案伺服器……等工作負載使用。


    值得注意的是,雖然 AzSHCI 叢集已全面支援精簡佈建磁碟區,但預設情況下系統仍會採用並部署「固定」( Fixed )磁碟區,管理人員可以在 WAC 管理介面中,依序點選「Settings > Settings > Storage > Storage Spaces and pools > Storage Pool > Default Provisioning Type」,由原本的 Fixed 選擇至「Thin」選項後,按下 Save 鈕即可將預設值修改為採用精簡佈建磁碟區(如圖 21 所示)。



    圖 21、調整 AzSHCI 叢集預設部署精簡佈建磁碟區


    倘若,管理人員忘記調整預設值,並且在建立磁碟區時忘記選擇採用精簡佈建磁碟區時,該如何將固定磁碟區轉換為精簡佈建磁碟區,讓我們快速進行磁碟區轉換作業。首先,請在 WAC 管理介面中,依序點選「Storage Volumes > Inventory > Create」,在 Create Volume 視窗中,請於 Name 欄位鍵入磁碟區名稱,本文實作為「VMs-ThinVolume」,在 Resiliency 下拉式選單中,選擇資料容錯等級「Two-way mirror」,或管理人員依據需求選擇更高的資料容錯等級,在 Size on SSD 中鍵入要建立的磁碟區大小和 GB 或 TB,確認無誤後按下 Create 鈕即可,可以看到採用固定磁碟區加上 Two-way Mirror,所以佔用 2TB 的儲存空間(如圖 22 所示)。

    部署磁碟區時,管理人員可以在對話視窗中將 More Options 展開,在 Provisioning Type 中選擇「Thin」選項,即可指定使用精簡佈建磁碟區。

    圖 22、建立固定大小磁碟區


    由於 WAC 管理平台尚未支援轉換磁碟區作業,請切換至 PowerShell 視窗,首先執行「Get-StorageTier」指令,確認 VMs-ThinVolume 磁碟區使用固定大小類型,然後執行「Set-StorageTier -ProvisioningType Thin」將磁碟區類型由原本的固定大小變更為「精簡佈建」磁碟區。


    雖然已經成功改變磁碟區類型,然而 ReFS 檔案系統,只會在掛載時辨識磁碟區類型。因此,在多叢集節點的 AzSHCI 環境中,只要將磁碟區的擁有節點轉移由別台叢集節點接手即可,而單台 AzSHCI 環境因為沒有其它節點,所以必須透過「Stop-ClusterReousrce 和 Start-ClusterReousrce」指令,手動停止再啟動叢集資源,所以運作其中的工作負載將會遭遇存取中斷的情況,建議管理人員應該在維護期間執行此轉換作業(如圖 23 所示)。


    圖 23、將固定大小磁碟區轉換為精簡佈建磁碟區


    此時,再次查看磁碟區資訊,可以看到 Used 欄位由先前的 2.04TB 降低為「114GB」,而 Available 欄位由先前的 1.96TB 提升為「3.89TB」(如圖 24 所示)。


    圖 24、精簡佈建磁碟區大幅提升儲存空間可用資源



    結語

    透過本文的深入剖析和實作演練後,相信管理人員除了理解最新 Azure Stack HCI 22H2版本特色功能之外,也了解如何建構和部署單台 Azure Stack HCI 超融合叢集,並將固定大小磁碟區轉換為精簡佈建磁碟區。

    WSL on Windows Server 2022 系列文章

    $
    0
    0

     


    簡介

    簡單來說,最近需要在 Windows Server 2022 上面安裝 WSL (Windows Subsystem for Linux),所以就開始玩吧。透過下面影片,可以幫助你快速理解 WSL 的功能用途:





    選擇 WSL 1 或 WSL 2?

    因為時間演進的關係,除非有特殊需求,否則就選擇新版的 WSL 2 使用即可。因為新版的WSL 2運作架構,從原有的底層 Windows 核心管理和提供資源,改為整合 Hyper-V 虛擬化技術,但管理人員無須管理傳統 Hyper-V VM 虛擬主機,例如,vNetwork 虛擬網路、vSwitch 虛擬交換器……等組態設定,即可輕鬆建立和運 作Linux 執行個體。


    此外,新版本的 WSL 2 運作環境,可以在 Windows 系統上執行 ELF64 Linux ,達到增強檔案系統效能,並新增系統呼叫相容性。雖然,WSL 2 新的運作架構,將會改變 Linux 二進位檔與 Windows 電腦硬體的互動方式,但是仍然可以提供與舊版 WSL 1 相同的操作體驗。透過下列影片,快速了解新版 WSL 2 的特色功能:





    WSL 1 和 WSL 2 運作架構

    對於 WSL 1 和 WSL 2 運作架構有興趣的朋友,可以先參考下列 WSL1/2 運作架構圖的差異。



    有興趣了解 WSL1/2 運作架構差異的朋友,可以觀看 Microsoft Build 2019 大會中,BRK3068 - The new Windows subsystem for Linux architecture: a deep dive 議程內容。





    參考資源




    WSL on Windows Server 2022 系列文章

    Windows Server 2022 安裝 WSL2

    $
    0
    0


    Windows Server 2022 安裝 WSL 2

    在過去的版本中,WSL 1 和 WSL 2 運作環境,主要支援運作在 Windows 10 和 Windows 11 客戶端作業系統中,終於在 2022 年 5 月時,微軟官方正式發佈最新的 WSL 2 運作環境,正式支援運作在最新 Windows Server 2022 雲端作業系統中。


    在安裝 WSL 2 之前,必須確保運作 Windows Server 2022 的主機,在伺服器硬體底層已經啟用硬體輔助虛擬化技術,並確保主機支援安裝和運作 Hyper-V 虛擬化技術,並且確認已經安裝 KB-5014021 安全性更新


    由於,本文實作環境運作在 Hyper-V Nested VM 中,所以建立好 Windows VM 之後,記得給予硬體輔助虛擬化功能,確保 Windows Server 2022 VM 支援 Hyper-V 虛擬化技術。


    安裝 Windows Server 2022 完成,並安裝最新安全性更新後,系統資訊如下。


    由於,WSL 2 已經正式支援 Windows Server 2022,因此安裝上非常方便,只要在 PowerShell 指令視窗中鍵入「wsl --install」指令後,系統便會自動執行相關動作,例如,啟用必要的 WSL 和虛擬主機選擇性元件、下載並安裝最新 Linux 核心、將 WSL 2 組態設定為預設值、安裝預設的 Ubuntu Linux 發行版本……等,待安裝作業完成後,系統會提示必須重新啟動主機確保套用生效。


    預設情況下,重新啟動後登入 Windows Server 2022 系統時,便會自動下載和執行 Ubuntu Linux 執行個體,當系統成功啟動 WSL 運作環境,並運作 Ubuntu Linux 執行個體之後,第一個動作便是要求管理人員為這個 Ubuntu Linux 執行個體,組態設定登入的管理者帳號及密碼,鍵入管理者帳號及二次確認密碼後,便順利登入 Ubuntu Linux 作業系統。


    後續,當你離開這個 Ubuntu Linux,需要再重新開啟視窗時,可以在開始功能表上最近新增的應用程式清單中找到。


    安裝 Windows Terminal 工具,以方便後續同時操作多個 WSL 運作的 Linux 執行個體。因為是 Windows Server 2022 系統,所以可以直接採用內建的 Edge 瀏覽器,瀏覽 GitHub - Microsoft/Terminal頁面,選擇下載最後穩定版本,本文實作環境為「Windows Termianl v1.16.1026」版本,下載 C++ Runtime Framework for Desktop Bridge (Microsoft.VCLibs.140.00.UWPDesktop)套件,以便稍後能夠順利安裝 Windows Terminal,否則會發生「0x80073CF3」錯誤。


    都下載完成後,使用「Add-AppxPackage -Path」指令,搭配 Windows Terminal  和 C++ Runtime Framework for Desktop Bridge (Microsoft.VCLibs.140.00.UWPDesktop)存放路徑即可,安裝完成後即可看到開始選單中的 Windows Terminal ,並且新增時也可以快速開啟剛才在 WSL 環境中建立的 Ubuntu Linux。




    參考資源




    WSL on Windows Server 2022 系列文章





    忘記 WSL 執行個體密碼時,如何重置?

    $
    0
    0


    組態設定 WSL Linux 管理者帳號及密碼

    預設情況下,安裝 WSL 並重新啟動後,順利登入 Windows Server 2022 系統時,便會自動下載和執行 Ubuntu Linux 執行個體,當系統成功啟動 WSL 運作環境,並運作 Ubuntu Linux 執行個體之後,第一個動作便會要求管理人員為這個 Ubuntu Linux 執行個體,組態設定登入的管理者帳號及密碼,鍵入管理者帳號及二次確認密碼後,便順利登入 Ubuntu Linux 作業系統。


    事實上,關於初始設定 Linux 管理者帳號和密碼時,有下列二點注意事項:

    • 每個 WSL Linux 執行個體中,管理者帳號和密碼是各自獨立互不影響,並且跟 Windows 系統管理者帳號及密碼無關
    • 初始設定管理者帳號和密碼完成後,後續啟動 WSL Linux 執行個體時便會自動登入,並且這個帳號自動加入並具備 sudo 權限




    忘記密碼怎麼辦?

    隨著年紀增長,金魚腦的情況也越發嚴重,可能因為安裝完畢後太久沒用忘記,又或者是鍵盤有問題一直打不出正確密碼……等 👴。


    雖然,在 Linux 作業系統中,透過 passwd 指令可以變更使用者密碼,然而是前提在你知道「原有」密碼時的情況下,才能順利變更使用者密碼。😏 




    重置 WSL Linux 管理密碼

    首先,開啟 Windows Terminal 工具,方便我們直接在 PowerShell 和 Ubuntu Linux 之間切換。倘若,你的 WSL 運作環境中,已經建立多個 Linux 執行個體的話,可以先透過「wsl --list --verbose」指令,確認目前運作哪些 Linux 執行個體。


    在本文實作環境中,目前僅運作 Ubuntu Linux 執行個體,所以直接使用「wsl -u root」指令,即可直接進入重置流程,順利進入 Ubuntu 後執行「passwd weithenn」指令,變更 Weithenn 使用者的管理密碼,完成後鍵入「exit」離開。然後,切換到 Ubuntu Linux 執行個體,可以發現密碼已經順利更改。



    那麼如果有「多個」Linux 執行個體時,如何指定要變更哪個 Linux 執行個體的管理密碼? 透過「wsl --list --verbose」指令,確認 Linux 執行個體的 NAME 欄位後,使用「wsl -u root」指令,搭配你要變更管理密碼的名稱即可,例如,「wsl -d Ubuntu -u root」指令即可。





    參考資源




    WSL on Windows Server 2022 系列文章




    檢查、管理、更新 WSL

    $
    0
    0

    檢查 WSL 版本

    執行「wsl --version」指令,讓系統執行檢查 WSL 相關運作元件的版本資訊。





    檢查 WSL 運作狀態

    執行「wsl --status」和「wsl --list --verbose」指令,查詢預設採用的 Linux 發行版本和 WSL 版本,以及查詢目前 WSL 運作環境中安裝和運作哪些 Linux 執行個體。




    更新 WSL 版本

    在本文實作環境中,可以看到原本採用的 WSL 版本為「1.0.3」版本,管理人員可以執行「wsl --update」指令,預設將會至 Microsoft Store 網站,確認是否有更新的 WSL 版本。在本文實作環境中,可以看到有「1.1.3」新版本可供更新,於是系統自動執行版本更新工作任務。


    待更新作業完成後,再次執行系統便說明已經為最新版本。此外,管理人員也可以加上「--web-download」參數,改為從 GitHub 網站確認是否有更新的 WSL 版本。




    查看其它指令

    執行「wsl --help」指令,系統將會顯示 WSL 相關指令以及可用參數。




    參考資源




    WSL on Windows Server 2022 系列文章


    網管人 206 期 - 實戰 vCenter Converter 跨平台虛機實機互轉

    $
    0
    0


    網管人雜誌

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






    本文目錄

    前言





    前言

    2022 年 2 月時,VMware 官方正式說明在產品下載清單中,已經將舊版 vCenter Converter 版本徹底移除,主要原因在於最後一版的 vCenter Converter 發佈於 2018 年 5 月,並且官方支援至 2019 年 12 月就已經正式結束,所以基於 vSphere 虛擬化環境中,整體工作負載的安全性和穩定性考量,便正式將舊版 vCenter Converter 版本移除。

    然而,在當時的移除說明中,卻有補充說明 vCenter Converter 更新版本的開發工作已經在進行當中,但是並未承諾正式發佈的時間,僅說明屆時推出的 vCenter Converter 更新版本,除了具備安全性和穩定性之外,也將支援新世代版本的 vSphere 虛擬化平台。

    幸運的是,經過半年之後 VMware 在社群論壇中,發佈更新的 vCenter Converter Beta 版本後,立即在一週內便獲得超過 1,500 名使用者註冊,並且在 2022 年 10 月發佈 vCenter Converter 6.3 正式版本,和過去舊版相同的便是支援「實體機轉虛擬機」(Physical to Virtual,P2V)、「虛擬機轉虛擬機」(Virtual to Virtual,V2V)……等特色功能,並且支援主流 vSphere 7 虛擬化平台,以及最新 Windows Server 2022 Hyper-V 虛擬化平台進行轉換作業(如圖 1 所示)。

    圖 1、VMware vCenter Converter 運作架構示意圖





    vCenter Converter 運作架構

    來源端主機為 Windows 作業系統時

    在 vCenter Converter 運作架構中,便是透過「熱複製」(Hot Cloning)技術,將運作中的來源端 Windows 主機,線上即時複製傳輸資料至 vSphere 虛擬化平台,以及重新組態設定後完成轉換作業。

    vCenter Converter 支援轉換,安裝在實體機或 VM 虛擬主機中的 Windows 作業系統,支援的版本為客戶端的 Windows 8.1,10,11,以及伺服器端的 Windows Server 2012,2012R2,2016,2019,2022 版本。

    在開始執行轉換作業之前,請先確保 vCenter Converter 主機、來源端 Windows 主機、目的端 vSphere 虛擬化平台之間,已經開啟並允許相關防火牆連接埠網路流量能夠通行,請開啟 TCP Port 139,443,445,902,9089、UDP Port 137,138,詳細資訊請參考 VMware KB 1010056知識庫文章內容。

    值得注意的是,來源端 Windows 主機使用 NetBIOS 的話,則無須允許 TCP Port 445 通過防火牆,倘若未使用 NetBIOS 的話,則無須允許 TCP Port 139、UDP Port 137,138 通過防火牆。

    當轉換的來源端主機為 Windows 作業系統時,將會執行三個轉換程序。首先,擔任 vCenter Converter 角色的主機,將會為來源端主機準備 P2V 或 V2V 轉換作業,並在準備過程中透過取得的管理者帳號及密碼,為來源端主機 Windows 作業系統中,安裝 Converter Standalone Agent 代理程式,以便屆時能夠針對來源端主機的磁碟分割區,進行快照後執行資料傳輸作業(如圖 2 所示)。

    圖 2、轉換來源端主機為 Windows 作業系統時,第一個轉換程序工作任務

    第二個轉換程序工作任務,vCenter Converter 主機將會連線至目的端 vSphere 虛擬化平台,並透過取得的 vCenter Server 管理權限,建立和註冊 VM 虛擬主機,並且觸發來源端主機的代理程式,將來源端主機的磁碟分割區進行快照後,複製並傳輸到目的端主機當中(如圖 3 所示)。

    值得注意的是,倘若「啟動」代理伺服器模式,則傳輸流量將會先回到 vCenter Converter 主機,再傳送至目的端主機,若是「停用」代理伺服器模式,則傳輸流量則會直接從來源端主機傳送至目的端主機。

    圖 3、第二個轉換程序工作任務,來源端建立磁碟區快照後傳輸至目的端

    第三個轉換程序工作任務,當資料傳輸作業完成之後,代理程式將會安裝 VM 虛擬主機作業系統所需要的相關驅動程式,並且執行客製化組態設定,例如,V2V 轉換作業完成後,將來源端主機中的代理程式移除……等(如圖 4 所示)。

    圖 4、轉換作業最後工作任務,安裝相關驅動程式和客製化組態設定



    來源端主機為 Linux 作業系統時

    vCenter Converter 支援轉換,安裝在實體機或 VM 虛擬主機中的 Linux 作業系統,支援的發行版本為 CentOS 6.x/7.x、RHEL 6.x/7.x、Ubuntu 14.04/16.04 。

    與轉換 Windows 作業系統不同,當轉換的來源端主機為 Linux 作業系統時,僅會執行二個轉換程序,主要差別在於轉換 Windows 作業系統時,vCenter Converter 主機會在來源端主機安裝代理程式,而轉換 Linux 作業系統時,則不會在來源端主機安裝任何代理程式。

    在開始執行轉換作業之前,請先確保 vCenter Converter 主機、來源端 Linux 主機、目的端 vSphere 虛擬化平台之間,已經開啟並允許相關防火牆連接埠網路流量能夠通行,請開啟 TCP Port 22,443,902,詳細資訊請參考 VMware KB 1010056知識庫文章內容。

    第一個轉換程序工作任務,首先擔任 vCenter Converter 角色的主機,透過流程中取得的 SSH 連線管理者帳號及密碼,確認能夠與來源端主機通訊後,透過 vCenter Converter 主機內包含的 ISO 印象檔,在目的端 vSphere 虛擬化平台中,部署一台「輔助轉換虛擬主機」(Helper Virtual Machine),以便在稍後的轉換過程中擔任中介容器的角色(如圖 5 所示)。

    圖 5、SSH 連線來源端主機並在目的端部署輔助轉換虛擬主機

    輔助轉換虛擬主機順利部署並啟動後,將會透過 SSH 連線至來源端主機,並將管理人員選擇要轉換的磁碟區進行複製傳輸作業,當磁碟區資料傳輸作業完成後,執行重新組態設定工作任務,當轉換程序完成後,vCenter Converter 主機便會在目的端 vSphere 虛擬化平台中,關閉和刪除輔助轉換虛擬主機(如圖 6 所示)。

    圖 6、執行來源端主機磁碟區資料傳輸和重新組態設定作業



    支援的虛擬化平台版本

    在最新版本的 vCenter Converter 運作架構中,支援轉換來源端的企業等級虛擬化平台版本,為 Hyper-V 2012 R2,2016,2019,2022,使用者等級的虛擬化版本,則支援 Hyper-V 10,11、VMware Workstation 16.x 和 VMware Fusion 12.x 。

    至於支援轉換目的端的 vSphere 虛擬化平台,則是 vSphere 6.5,6.7,7.0 版本。雖然,官方並未條列支援最新的 vSphere 8.0 版本,但是本文實戰演練小節中,採用的便是最新 vSphere 8.0 版本,並且順利完成 Windows Server 2022 虛擬化平台中,VM 虛擬主機的轉換作業。





    實戰 – V2V 轉換 Hyper-V 虛擬主機

    在實戰演練小節中,來源端為 Windows Server 2022 Hyper-V 虛擬化環境,在 Hyper-V 虛擬化環境中,已經部署並運作一台 Windows Server 2022 作業系統的 VM 虛擬主機,該 VM 虛擬主機已經安裝和啟用 IIS 網頁伺服器,並且加入至「lab.weithenn.org」網域環境,至於 VM 虛擬主機連接的 Hyper-V 虛擬交換器名稱為「VMs-vSwitch」(如圖 7 所示)。

    圖 7、Hyper-V 虛擬化平台中的 VM 虛擬主機

    目的端則是最新的 vSphere 8.0 虛擬化環境,稍後便是將 Hyper-V 虛擬化環境的 VM 虛擬主機,透過 vCenter Converter 的「熱複製」(Hot Cloning)技術,將運作中的 VM 虛擬主機,線上即時複製並傳輸至 vSphere 虛擬化平台。



    V2V Hot Cloning – Windows Server 2022

    在本文實作環境中,於 Windows 10 主機中,安裝最新發佈的 vCenter Converter 6.3.0 版本。開啟 vCenter Converter 工具後,按下 Convert machine 鈕,在彈出的精靈對話視窗中於 Source System 頁面,首先請選擇準備轉換的來源端主機為開機中或是關機中,以及遠端主機為 Windows 或 Linux 作業系統,或是準備轉換的主機為本機系統。
    vCenter Converter 支援安裝在 Windows 8.1/10/11,和 Windows Server 2012/2016/2019/2022 作業系統,不支援安裝在 Linux 作業系統。

    在本文實作環境中,準備轉換 Hyper-V 虛擬化平台內運作中的 VM 虛擬主機,因此請選擇「Powered On」和「Remote Windows machine」項目,並在下方來源端主機資訊中,填入主機名稱和管理者帳號及密碼,本文實作主機名稱為「ws2022-web01」,管理者帳號為「lab.weithenn.org\Administrator」,確認無誤後按下「View source details」,此時 vCenter Converter 主機將會嘗試連結來源端主機(如圖 8 所示)。
    倘若連結來源端主機失敗,請確認相關是否開啟並允許相關防火牆連接埠。
    圖 8、vCenter Converter 主機連接至準備轉換作業的來源端主機

    一旦連結來源端主機成功後,將會出現 vCenter Converter Standalone 代理程式部署選項,因為在轉換過程中必須為來源端主機安裝代理程式,所以讓管理人員選擇當轉換作業成功時,要如何處理代理程式,管理人員可以選擇轉換作業成功後自動移除代理程式,或是之後由管理人員手動移除代理程式,本文實作選擇「Automatically uninstall the files when import succeeds」項目,選擇完畢後系統便會為來源端主機安裝 vCenter Converter Standalone 代理程式。

    順利為來源端主機安裝代理程式後,便會顯示來源端主機的詳細資訊,包括作業系統版本、記憶體空間、網路卡資訊、系統分割區……等,確認無誤後按下 Next 鈕進入下一個步驟。

    在 Destination System 頁面中,Destination type 下拉式選單中,選擇 VMware Infrastructure virtual machine 項目,表示目的端為 vSphere 虛擬化環境,倘若要目的端為 VMware Workstation 或 Fusion 客戶端虛擬化環境時,請選擇其它項目。

    在下方目的端主機資訊中,請填入主機名稱和管理者帳號及密碼,本文實作主機名稱為「vcenter8」,管理者帳號為「Administrator@lab.weithenn.org」,確認後按下 Next 鈕便會連接至 vCenter Server 管理平台,成功連結後將會出現憑證資訊,確認後便進入下一個轉換作業程序。

    在 Destination Virtual Machine 頁面中,將會顯示來源端主機的 FQDN 名稱,以及剛才連結成功的 vCenter Server 管理平台,請管理人員選擇要將轉換後的 VM 虛擬主機,放置於哪個儲存容器當中,本文實作環境放置於名稱為「V2V-VMs」的資料夾內(如圖 9 所示)。

    圖 9、將屆時 V2V 轉換後的 VM 虛擬主機存放於 V2V-VMs 資料夾內

    在 Destination Location 頁面中,首先選擇轉換後的 VM 虛擬主機,要運作在哪個 vSphere Cluster 和 ESXi 虛擬化平台中,右側上方的 Datastore 下拉式選單中,則是選擇 V2V 轉換後的 VM 虛擬主機,所要使用的 Datastore 儲存資源,右側下方的 Virtual machine version 下拉式選單中,為選擇 V2V 轉換後的 VM 虛擬主機,使用的 VM 虛擬主機虛擬硬體版本,本文實作環境中採用最新的 ESXi 8 虛擬化平台,所以選擇採用最新的「Version 20」版本(如圖 10 所示)。

    圖 10、選擇 V2V 轉換後的 VM 虛擬主機運算和儲存資源及虛擬硬體版本

    在 Options 頁面中,可以針對 V2V 轉換後的 VM 虛擬主機內容進行調整,舉例來說,來源端的 VM 虛擬主機,原本配置 2 vCPU 和 8GB vRAM,但是在此頁面中卻變成僅配置 1 vCPU 和 1GB vRAM,管理人員便能按下 Edit 進行組態設定修改作業。

    值得注意的是,VM 虛擬主機連接的 vSwitch 虛擬交換器組態設定,原本來源端 VM 虛擬主機,在 Hyper-V 虛擬化環境中連接至「VMs-vSwitch」,但是在 vSphere 虛擬化環境中並沒有這個名稱的 vSwitch 虛擬交換器,在本文實作中便將來源端 VM 虛擬主機,改為連接至 vSphere 虛擬化環境中,名稱為「V2V-vNetwork」的連接埠群組,並且採用和 vSphere 虛擬化平台深度結合的「VMXNET3」網路卡控制器(如圖 11 所示)。

    圖 11、選擇連接的 vSwitch 虛擬交換器連接埠群組和網路卡控制器類型

    在 Advanced options 選項中,管理人員可以啟用其中的資料同步設定,在 V2V 轉換作業完成後,由於轉換期間來源端主機的各項資料,有可能發生新增 / 修改 / 刪除等情況,啟用資料同步機制可以在 V2V 轉換作業完成後,觸發資料同步設定。此外,還可以設定 V2V 轉換作業完成後,是否要將來源端主機關機,或是目的端主機自動開機,以及安裝 VMware Tools……等動作,管理人員可以依據運作環境需求自行調整(如圖 12 所示)。

    圖 12、組態設定 V2V 轉換作業完成後,自動幫 VM 虛擬主機安裝 VMware Tools

    在 Summary 頁面中,檢查各項組態設定值是否正確無誤,確認後按下 Finish 鈕,系統便立即開始執行 V2V 轉換作業。在 vCenter Converter 工具視窗中,點選下方的 Task progress 頁籤,可以看到 V2V 轉換作業的詳細資訊,同時也可以看到轉換進度和系統預估剩餘的轉換時間(如圖 13 所示)。

    圖 13、開始 V2V 轉換作業並查看相關資訊

    此時,管理人員也可以同步切換至 vCenter Server 管理介面,點選下方的 Recent Tasks 頁籤,可以看到 vCenter Converter 主機,已經透過剛才鍵入的 vCenter Server 管理者帳號密碼資訊,連接至 vCenter Server 管理平台,並且新增和註冊 V2V 虛擬主機(如圖 14 所示)。

    圖 14、vCenter Converter 順利新增和註冊 V2V 虛擬主機

    經過一段轉換和傳輸時間之後,V2V 轉換作業順利完成,管理人員可以點選 Summary 頁籤,查看 V2V 轉換時來源端 Hyper-V 虛擬主機資訊,以及 V2V 轉換後目的端 vSphere 虛擬主機資訊,和自訂重新組態設定的部份,例如,V2V 轉換成 vSphere 虛擬主機後,系統直接安裝 VMware Tools 並顯示完成工作任務(如圖 15 所示)。

    圖 15、順利完成 V2V 轉換作業



    測試 V2V 虛擬主機能否正常運作

    一般情況下,即便 V2V 轉換完成後,也不應該冒然直接將轉換後的 vSphere 虛擬主機開機,舉例來說,在本文實作環境中,Hyper-V 虛擬化平台中的 VM 虛擬主機仍開機中,倘若直接將 vSphere 虛擬化平台中的 VM 虛擬主機開機,那麼將會發生 IP 位址和電腦名稱衝突的情況。

    此外,因為 VM 虛擬主機運作在不同的虛擬化平台,所以網路卡類型也重新組態設定過,所以網路卡 MAC 位址也將會不同,所以立即將來源主機直接關機的話,將會發現目的端主機發生問題,主要原因在於底層網路交換器和路由器,必須重新學習這個新出現的網路卡 MAC 位址,在學習到之前都很有可能發生網路連線不正常的情況。

    因此,建議先將轉換後的 vSphere VM 虛擬主機,設定將網路卡連線功能取消,確認 VM 虛擬主機是否能夠順利開機、VMware Tools 是否正確運作、IIS 網頁伺服器服務是否正常運作……等。請在 vCenter 管理介面中,點選該台 VM 虛擬主機並且編輯設定,在 Virtual Hardware 頁籤中展開 Network Adapter 選單,取消勾選「Connect At Power On」選項後,按下 OK 鈕套用生效(如圖 16 所示)。

    圖 16、取消勾選 Connect At Power On 選項,停用 VM 虛擬主機網路卡

    順利開機後,雖然已經將 VM 虛擬主機網路卡功能停用,但仍能採用 lab.weithenn.org 網域管理者帳號登入,主因在於 V2V 轉換作業剛完成,尚能透過網域登入快取機制順利登入系統,成功登入系統後請確認相關系統組態設定是否正常,VMware Tools 服務是否啟動,以及本文實作的 IIS 網頁伺服器服務是否正常啟動。

    請開啟命令提示字元,鍵入「netstat -na | find ":80"」指令,檢查 IIS 網頁伺服器服務是否 Listen TCP Port 80,然後開啟瀏覽器在網址列鍵入「http://localhost/」,透過連結 Loopback 的方式查看 IIS 網頁內容(如圖 17 所示)。

    圖 17、檢查 IIS 網頁伺服器服務是否 Listen TCP Port 80 並查看 IIS 網頁內容

    回到 vCenter 管理介面中,可以看到 VM 虛擬主機作業系統版本順利辨識,並且 VMware Tools 運作正常(如圖 18 所示),雖然 IP 位址顯示 169.254.x.x,主因便是我們停用 VM 虛擬主機網路卡連線導致,確認 VM 虛擬主機連接的 vSwitch 連接埠群組,以及相關組態內容無誤後,便可以將 VM 虛擬主機關機。

    圖 18、透過 vCenter 管理介面確認 VM 虛擬主機組態設定

    確認 V2V 轉換後的 VM 虛擬主機運作無誤後,便可以在安排的維護時間中,將來源端 Hyper-V 虛擬化平台中的 VM 虛擬主機關機,將 vSphere 虛擬化平台中的 VM 虛擬主機開機,倘若希望能夠減少底層網路交換器和路由器,重新學習 VM 虛擬主機的 MAC 位址時間,可以重新組態設定 VM 虛擬主機 MAC 位址。

    舉例來說,本文實作環境來源端 Hyper-V 虛擬化平台 VM 虛擬主機,其 MAC 位址為「00:15:5D:4B:24:00」,在 vCenter 管理介面中,點選該台 VM 虛擬主機並編輯設定,在 Virtual Hardware 頁籤中展示 Network adapter 選單,勾選「Connect At Power On」選項後,在 MAC Address 欄位,將預設值 Automatic 改為「Manual」,然後鍵入 MAC 位址「00:15:5D:4B:24:00」,確認無誤後按下 OK 鈕套用生效(如圖 19 所示)。

    圖 19、啟用網路卡連線功能並設定 MAC 位址

    成功開機並順利登入後,可以看到這台 VM 虛擬主機,除了能順利透過 DC 網域控制站,查詢 DNS 記錄之外,也能透過 FQDN 順利連接 IIS 網頁伺服器服務(如圖 20 所示)。

    圖 20、V2V 轉換後的 VM 虛擬主機,重新回到企業網路繼續服務

    至此,V2V 轉換作業順利完成,將原本運作於 Hyper-V 虛擬化平台中的 VM 虛擬主機,轉換為 vSphere 虛擬化平台的 VM 虛擬主機後繼續運作。



    IP 位址已被 Hyper-V Network Adapter 佔用?

    倘若,管理人員發現 IP 位址變成 DHCP 自動取得,嘗試組態設定回原有的固定 IP 位址時,Windows 作業系統卻出現資訊提示視窗,說明組態設定的固定 IP 位址,已經被先前的 Microsoft Hyper-V Network Adapter 虛擬網路卡所使用(如圖 21 所示)。

    圖 21、系統顯示原有固定 IP 位址已被先前的 Hyper-V 網路卡所使用

    雖然,可以按下 Yes 鈕強制設定,但也將為系統埋下日後不穩定的因素,那麼該如何解決這個問題 ?請管理人員開啟裝置管理員,並展開 Network Adapters 選項後,將會發現系統並沒有顯示,剛才說明的 Microsoft Hyper-V Network Adapter,請點選上方「View > Show hidden devices」後,再次查看便會顯示 Microsoft Hyper-V Network Adapter,請點選右鍵選擇「Uninstall device」,讓系統移除這個裝置,因為這台 VM 虛擬主機已經完全運作在 vSphere 虛擬化平台中,不再需要 Hyper-V 虛擬網路卡(如圖 22 所示)。

    圖 22、移除 Microsoft Hyper-V Network Adapter 網路卡





    結語

    透過本文的深入剖析和實作演練後,相信管理人員除了理解 vCenter Converter 的運作原理之外,透過實作演練的過程,也可以有效幫助管理人員,將實體主機或其它虛擬化平台的 VM 虛擬主機,透過 P2V 或 V2V 轉換作業後,運作於企業或組織內的 vSphere 虛擬化平台中。

    Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred

    $
    0
    0


    Question:

    最近有個需求,因為建立新的 vSAN Cluster 超融合叢集,通常在正式上線之前我會進行壓力測試,確保每個硬體元件,例如,SSD、Storage Controller……等。因為,過去我曾經遇過 SSD 應該有 5 萬 IOPS 的表現,但實際壓測後確發現只有 2 萬 IOPS的情況,所以若沒有壓測的話是很難發現這種效能落差的情況。

    但是,在匯入 Cisco HxBench Controller VM程序中,進度大約 9x% 時便會出現如下圖的錯誤訊息。「Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred: Transfer failed: IO error during transfer: java.io.EOFException




    Answer:


    但是,在我的實作環境中,其實是在匯入 Cisco HxBench Controller VM 程序中,我已經手動為 Controller VM 設定「固定 IP 位址」了,卻忽略把下方的 IP type 選擇為「Staic IP」,而保留預設值的「DHCP」才造成這個問題。

    Network diagnostic mode is enabled more than 24 hours

    $
    0
    0


    Question:

    最近,透過 Skyline Health 檢查 vSphere 運作架構健康情況時,系統出現「Network diagnostic mode」項目的警告訊息,狀態內容是「Network diagnostic mode is enabled more than 24 hours (74 hours). The network diagnostic mode is only use for troubleshooting,...」(如下圖所示)。




    Answer:

    簡單來說,後來發現有其它管理人員,在透過 vSAN Proactive Tasks 的 Network Performance Test 項目進行網路頻寬測試作業時,將「Enable network diagnostic mode」的選項打勾,但是在測試作業完成後並沒有關閉,所以才造成這個系統警告訊息。


    此時,只要依序點選「vSAN Cluster > Configure > vSAN > Services > Performance Service > Edit」,將 Network diagnostic mode 的設定值調整為「Disabled」即可關閉。


    A vCenter Single Sign-On service error occurred

    $
    0
    0


    Question:

    由於,先前已經組態設定 vCenter Server 整合 Windows AD SSO (Single Sign-On)機制,所以都可以採用 Windows AD 帳號登入 vCenter Server 並進行管理作業。但是,今天卻發現無法使用 Windows AD 帳號登入,並一直提示登入的使用者帳號或密碼有問題 (當然,帳號和密碼是沒問題的!! 😅)

    使用預設的 Administrator@vsphere.local管理帳號登入,發現如下圖所示的錯誤訊息以及錯誤資訊「A vCenter Single Sign-On service error occurred」。




    Answer:

    經過檢查後,發現在本文實作環境中,是因為 LDAPs 的憑證過期所導致的,所以只要重新組態設定 vCenter Single Sign-On Identity Source using LDAP with SSL即可。

    值得注意的是,無法在原有的 Identity Source 中直接更新 LDAPs 憑證,而必須刪除掉原有項目後再新增即可套用生效,嘗試在原有項目更新 LDAPs 憑證的話,便會遭遇到如下圖的錯誤訊息。


    Viewing all 591 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>