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

[站長開講] Microsoft Hyper-V 伺服器虛擬化實戰班

$
0
0

前言

在本課程中,我們將帶領你建置及管理 Microsoft Hyper-V 伺服器虛擬化平台,包括,建置 WSFC 容錯移轉叢集、實作即時遷移(Live Migration)、儲存即時遷移(Live Storage Migration)、無共用儲存即時遷移(Shared-Nothing Live Migration)、快速遷移(Quick Migration)……等



課程日期




課程內容

高可用性及高效能虛擬化平台架構規劃實務

  • 如何規劃所要採用的 x86 實體伺服器規格
  • CPU 中央處理器指令集的選擇
  • Memory 記憶體的選擇
  • NVMe/SSD/SAS/NL-SAS/SATA 硬碟種類的選擇與 IOPS 規劃
  • RAID Card 的選擇與 RAID 模式規劃
  • Network 網路環境的規劃

建置容錯移轉叢集環境

  • 選擇儲存資源(DAS / NAS / SAN)
  • 安裝與設定 Windows Server 2019 Hyper-V 角色
  • 建立 WSFC 容錯移轉叢集

計畫性及非計畫性停機解決方案

  • 即時遷移(Live Migration)
  • 儲存即時遷移(Live Storage Migration)
  • 無共用儲存即時遷移(Shared-Nothing Live Migration)
  • 快速遷移(Quick Migration)

VM 虛擬主機進階管理

  • 客體服務(Integration Services)
  • 加強的工作階段 (Enhanced Session Mode)
  • VM 軟體授權自動啟用(AVMA)
  • 虛擬磁碟線上擴充和縮小(Disk Online Extend / Shrink)
  • 儲存資源 IOPS 品質控制(Storage QoS)
  • 備份及還原(Export / WSB)
  • 應用程式監控(VM Monitoring)
  • 主機反關聯性(Anti-Affinity)
  • 叢集共用磁碟區快取(CSV Cache)

異地備援方案

  • Hyper-V 複本代理人(Hyper-V Replica)
  • 測試容錯移轉
  • 計畫性容錯移轉
  • 非計畫性容錯移轉
  • 延伸複寫

叢集感知更新

  • 叢集節點維護模式(Maintenance Mode)
  • 叢集感知更新(CAU)
  • 匯出叢集感知更新報表

實戰 Azure Stack HCI 20H2 超融合叢集

$
0
0


前言

過去,建立 S2D 超融合環境建構過程,完全需要透過 PowerShell 指令進行建構和檢查運作環境及狀態,舉例來說,從 S2D 超融合環境的前置作業、組態設定虛擬交換器和虛擬網路環境、建構容錯移轉叢集、整合儲存資源、啟用 S2D(Storage Spaces Direct)超融合技術……等,因此即便是熟悉 PowerShell 指令的管理人員,至少也需要花費數小時才能完成整個建置作業,所以讓許多對於 PowerShell 不熟悉的管理人員望之卻步。

過去,企業和組織希望建構微軟的 HCI 超融合叢集運作環境時,必須採用 Windows Server 2016 或 Windows Server 2019 雲端作業系統。然而,微軟發現企業和組織已經開始逐漸將工作負載進行遷移,或是直接改為採用在雲端環境中運作。

因此,在 Microsoft Inspire 2020大會上,微軟發佈新一代的 HCI 超融合雲端作業系統「Azure Stack HCI」。此時,管理人員肯定會有疑惑,新一代的 Azure Stack HCI 和 Windows Server 2019 作業系統中,建置後的 HCI 超融合叢集運作環境有哪些差異? 簡單來說,新一代的 Azure Stack HCI 是專為 HCI 超融合環境進行重新設計,並且針對 Azure 公有雲環境進行深度整合。







Cluster Creation 新增特色功能

自從 Microsoft Ignite 2019 大會上,發表並實際展示透過 WAC(Windows Admin Center)管理平台,採用新增的「叢集建立延伸模組」(Cluster Creation Extension)特色功能,幫助管理人員在 WAC 圖形化管理介面中,以多階段工作流程的方式帶領管理人員,將過去需要執行大量 PowerShell 的繁複工作流程,在 WAC 圖形化管理介面中完成建置 S2D 超融合運作環境的工作任務。

最新版本的 「叢集建立延伸模組」(Cluster Creation Extension)已經於日前發佈,本文實作環境的 Cluster Creation Extension 版本為「1.465.0」。那麼,我們來看看這個新的 GA 版本支援或新增哪些亮眼功能。




支援 RDMA 組態設定

現在,新版 Cluster Creation Extension 在建立 Azure Stack HCI 超融合叢集的工作流程中,已經完整支援 RDMA (iWARP 或 RoCE v2)特色功能。同時,還能在工作流程中,組態設定 RDMA 進階組態。




支援 Stretch Cluster

此外,企業和組織期待已久的「延伸叢集」(Stretched Cluster)特色功能,也在新一代的 Azure Stack HCI 開始支援。因此,企業和組織現在可以透過延伸叢集特色功能,例如,在二棟不同建築物之間,建立 Azure Stack HCI 超融合運作環境並啟用延伸叢集功能,無論採用「Active-Passive」或「Active-Active」運作模式,都能讓營運服務達成更高的可用性和彈性。




整合 OCM Extensions 更新機制

當管理人員採用通過 Azure Stack HCI 驗證程序的硬體伺服器時,那麼在建構 Azure Stack HCI 超融合叢集的過程中,Cluster Creation 會透過 OEM Extensions 機器,檢查是否有適用於目前硬體伺服器的相關更新,例如,Firmware 或 Drivers……等。






實戰 Azure Stack HCI 20H2 超融合叢集

在本文實作環境中,總共建立四台主機,前二台主機採用 Windows Server 2019 作業系統,第一台主機擔任 DC 網域控制站的角色(網域名稱為「lab.weithenn.org」),另一台主機擔任 Windows Admin Center 管理平台的角色,另外二台主機則採用新版 Azure Stack HCI 20H2 雲端作業系統,並擔任 HCI 超融合叢集中節點主機的角色。


首先,在第一個階段 Get Started 內,於 1.1 Check the prerequisites 頁面中,系統提示相關前置作業資訊,例如,建議為 WAC 管理平台執行註冊至 Azure 的動作,屆時便可以透過 Azure Portal 輕鬆管理 Azure Stack HCI 超融合叢集,HCI 叢集節點主機必須採用 Azure Stack HCI 雲端作業系統,稍後的組態設定流程必須具備本機 Administrators 群組的權限才行……等,建議管理人員再次檢視是否符合相關條件,避免稍後的部署作業發生非預期的錯誤。


在 1.2 Add servers 頁面中,請鍵入HCI叢集節點主機的管理者帳號及密碼,然後鍵入 HCI 叢集節點主機的 FQDN 主機名稱,分別是「HCI-Node01 和 HCI-Node02」搭配網域名稱後按下 Add 鈕進行檢查,通過系統檢查作業後再按下 Next 鈕繼續下一個組態設定流程。接下來,便是加入網域、安裝伺服器角色和功能、檢查是否安裝最新安全性更新。





因為,本文實作環境為 Nested Virtualization,所以在檢查硬體伺服器 Firmware 和 Drivers 更新時便無法獲得任何更新,然後檢查是否需要重新啟動 Azure Stack HCI 節點主機。



在第二階段則是 Azure Stack HCI 節點主機的網路環境組態設定,首先偵測每台 Azure Stack HCI 節點主機的網路卡數量和連線情況,接著組態設定管理用途網路和虛擬交換器、VMs 虛擬主機用途網路和虛擬交換器、儲存用途網路和虛擬交換器……等。




同樣的,因為本文實作環境為 Nested Virtualization,所以在 RDMA 組態設定頁面時便出現無法支援的情況。最後,組態設定 VMs 虛擬主機用途網路和虛擬交換器、儲存用途網路和虛擬交換器。



順利建構 Azure Stack HCI 叢集和啟用 Storage Spaces Direct 超融合技術後,便可以直接在 WAC  管理介面中,查看和管理 Azure Stack HCI 超融合叢集。


關於站長 (2020 年自我審視)

$
0
0



關於本站

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





Weithenn 摸索 IT 世界回顧:






2021 年

1 月: 

         Coming Soon...。





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 界工作。

    網管人 180 期 - vSphere 7 Update 1 開發維運需求一次滿足

    $
    0
    0


    網管人雜誌

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





              vSphere with Tanzu
              vCLS 運作架構





    前言

    VMware 全新的 vSphere 7 解決方案,在 2020 年 3 月正式發佈同時內建 Kubernetes 叢集環境,並在 2020 年 10 月正式推出 vSphere 7 Update 1更新版本。雖然,vSphere 7 Update 1 看似小版本更新,然而在這個 Update 1 版本中,除了原有運作規模大幅成長之外,也增強和新增許多特色功能。

    首先,在 vSphere 叢集運作規模方面,vSphere 7 版本中「單台」ESXi 虛擬化平台,實體記憶體空間最大支援至「16 TB」,而新版 vSphere 7 Update 1 則一舉拉升至「24 TB」,在 vSphere 叢集支援 ESXi 成員主機數量部份,也從原有的「64 台」提升為「96 台」,至於 vSphere 叢集運作 VM 虛擬主機的數量,也從原有「6,400 台」大幅提升為「10,000 台」。
    請注意,vSAN 叢集仍維持最多支援「64 台」vSAN 成員主機的運作規模。

    同時,在 VM 虛擬主機運作規模方面,在 vSphere 7 版本中「單台」VM 虛擬主機的 vCPU 數量最多支援至「256 vCPU」,在 vSphere 7 Update 1 版本中提升至「768 vCPU」,在 vRAM 虛擬記憶體方面,也從原有最大支援從「6 TB」大幅提升為「24 TB」(如圖 1 所示)。

    圖 1、vSphere 7 Update 1 Monster VM 運作規模示意圖





    vSphere 7 Update 1 亮眼特色功能

    vSphere with Tanzu

    在新版 vSphere 7 發佈時,企業和組織可以採用 VCF(VMware Cloud Foundation),因為它包含 vSphere、NSX、vSAN、vRealize、SDDC Manager 等私有雲管理工具組合,讓企業和組織可以同時輕鬆打造傳統 VM 虛擬主機,以及新世代工作負載的容器和應用程式。

    現在,最新發佈的 vSphere 7.0 Update 1,讓 TKG(Tanzu Kubernetes Clusters)可以直接和企業與組織資料中心內,已經建構好的 vDS(vSphere Distributed Switch)分佈式虛擬交換器連接,並且搭配由 HAProxy所提供的負載平衡機制後,便可無須導入 NSX 軟體定義網路解決方案,也能夠建構 vSphere with Tanzu 容器管理平台。
    vSphere with Tanzu 舊稱,便是 vSphere 7.0 版本所推出的 vSphere 7 with Kubernetes。

    首先,由於「K8s 控制平面」(Kubernetes Control Plane)已經嵌入 vSphere 核心當中,並且每台 ESXi 虛擬化管理平台內,皆已部署 K8s 代理程式(稱之為 Spherelets),由眾多 ESXi 成員主機建構的 Kuberntes 叢集稱之為「Supervisor Cluster」,並且每台 ESXi 成員主機便是擔任 Kubernetes Worker Nodes 的角色。所以,在 vDS 分佈式虛擬交換器組態設定的部份,只要確保 vCenter Server 管理平台和 K8s 控制平面之間能夠通訊即可(如圖 2 所示)。

    圖 2、vSphere with Tanzu 正式支援 vDS 分佈式虛擬交換器

    然而,因為環境中沒有導入 NSX 軟體定義網路的話,表示沒有 NSX 內建負載平衡機制幫忙引導容器和相關流量,此時可以導入 TKG 正式支援的第一個負載平衡器「HAProxy」(如圖 3 所示),部署的方式也非常容易只要導入 OVF 即可。
    請注意 ! 目前 vSphere Pod ServiceRegistry Service,仍須導入 NSX 軟體定義網路解決方案才行。
    圖 3、部署 HAProxy 流量負載平衡器

    當管理人員規劃完成,並且組態設定 HAProxy 使用的負載平衡 VIPs 位址,以及 TKG 叢集節點所需的 IP 位址之後,便能啟用 vSphere with Tanzu 特色功能,在啟用頁面中可以看到環境中並沒有導入 NSX-T 軟體定義網路解決方案,而是選擇 vCenter Server Network(如圖 4 所示),也就是採用 vDS 分佈式虛擬交換器搭配 HAProxy 負載平衡器。

    圖 4、採用 vDS 分佈式虛擬交換器搭配 HAProxy 負載平衡器搭建 TKG 容器執行環境



    vLCM 生命週期管理員再升級

    vLCM(vSphere LifeCycle Manager)為 vSphere 7 版本新增特色功能,但是僅針對 vSphere 和 vSAN 提供基本支援,其它 VMware 產品如 NSX-T 便無法支援。

    現在,全新推出的 vSphere 7.0 Update 1 版本中,增強 vLCM 生命週期管理員功能,除了全面支援原有的 vSphere 和 vSAN 之外,包括,安全性更新、版本升級、整合韌體……等。現在,連 NSX-T 也同樣支援。舉例來說,部署的 NSX Manager 可以透過 vLCM API 應用程式開發介面,管理 NSX-T 運作環境生命週期,包括,安裝、組態設定、運作、升級……等維護項目(如圖 5 所示)。

    圖 5、vLCM 生命週期管理員功能全面升級並支援 NSX-T 運作環境



    AMD SEV-ES 安全加密虛擬化

    在 2019 年 8 月時,VMware 官方正式宣佈 vSphere 支援 AMD EPYC 處理器。同時,在新版 vSphere 7.0 Update 1 中,全面支援「安全加密虛擬化 - 加密狀態」(Secure Encrypted Virtualization – Encrypted State,SEV-ES)機制,幫助企業和組織從底層硬體直接防堵 Spectre 和 Meltdown 等,令人困擾的硬體底層漏洞。

    或許,管理人員會有這樣的疑惑,為何 ESXi 和 VM 虛擬主機已經具備隔離的特性,舉例來說,VM Runtime 和 Guest OS 客體作業系統,其實是運作在由 ESXi 虛擬化平台所建構的「沙箱」(Sandbox)隔離環境中(如圖 6 所示),為何還需要底層硬體伺服器的安全性保護機制呢?

    圖 6、VM Runtime 和 Guest OS 客體作業系統運作在 ESXi 提供的沙箱隔離環境

    簡單來說,VM Runtime 和 Guest OS 運作的沙箱隔離環境其實是軟體式的,然而當 Guest OS 客體作業系統需要硬體資源時,其實還是會透過 ESXi 虛擬化平台,向底層發出使用硬體資源的請求,倘若底層硬體未進行加密保護機制的話,那麼受到侵入感染的 Hypervisor,便能夠讀取或修改底層硬體資源中,VM 虛擬主機存放於底層硬體處理器或記憶體內的機敏資料。

    因此,透過 SEV-ES 安全加密虛擬化保護機制搭配加密金鑰,即便 Hypervisor 受到侵入感染之後,也將因為沒有加密金鑰,而無法讀取或修改底層硬體資源中 VM 虛擬主機的機敏資料,搭配原有的 VM Runtime 和 Guest OS 沙箱隔離環境保護機制,幫助企業和組織達到雙重保護效果機敏資料不外洩。
    請注意 ! 第一代 AMD EPYC 處理器僅支援「15」個加密金鑰,第二代 AMD EPYC 處理器則擴充支援至「500」個加密金鑰。



    針對大型工作負載最佳化的 vSphere vMotion

    事實上,在新版 vSphere 7 版本中,已經重構 vSphere vMotion 即時遷移機制,並在 vSphere 7 Update 1 再度增強,以便企業和組織運作大型工作負載,例如,SAP HANA、Epic Operational Databases、InterSystems Cache、IRIS……等大型規模怪獸等級的 VM 虛擬主機時,能夠有效縮短即時遷移的作業時間,並避免「切換時間」(Switch-Over Time)或稱「擊暈時間」(Stun-Time),對大型規模應用程式造成的影響。

    在舊版 vSphere 6.7時,採用「Stop-Based Trace」機制,針對執行即時遷移的 VM 虛擬主機,停止「所有」vCPU 執行任何客體作業系統發出的請求指令,執行追蹤作業完成後再讓 VM 虛擬主機恢復運行。雖然,這樣的即時遷移機制對於中小型規模的 VM 虛擬主機效果很好,造成的停止時間也僅僅幾百「微秒」(microseconds),然而對於大型規模的 VM 虛擬主機則不然,因為 vCPU 數量越多的情況下,停止和恢復作業所需花費的時間越長,有可能導致 VM 虛擬主機內的應用程式發生中斷事件。

    新版 vSphere 7 Update 1,採用「Loose Trace」機制(如圖 7 所示),針對執行即時遷移的 VM 虛擬主機,僅會停止「單一」vCPU 執行任何客體作業系統發出的請求指令,其它 vCPU 則繼續執行客體作業系統發出的請求指令,所以在即時遷移期間對於 VM 虛擬主機的效能影響最小,同時不會造成應用程式發生中斷事件。

    圖 7、新舊版本 vSphere vMotion 即時遷移頁面追蹤技術示意圖

    「頁面追蹤」(Page Tracing)資料區塊大小的部份,舊版的 vSphere 6.7 採用「4 KB」小型資料區塊,傳輸即時遷移的 VM 虛擬主機 vRAM 虛擬記憶體空間,同樣的對於中小型規模的 VM 虛擬主機效果很好,然而對於大型規模的 VM 虛擬主機來說,除了容易造成 vMotion 即時遷移時間過長之外,也會影響大型應用程式的運作。

    新版 vSphere 7 Update 1,採用「Large Trace」機制(如圖 8 所示),並且改為採用「1 GB」資料區塊,傳輸即時遷移的 VM 虛擬主機 vRAM 虛擬記憶體空間,同時搭配其它最佳化機制,例如,Bitmap、Switch-Over、Large Page Handling……等。

    圖 8、新舊版本頁面追蹤資料區塊大小示意圖

    首先,在 VMware 官方測試環境中,為 VM 虛擬主機配置「72 vCPU 和 1 TB vRAM」虛擬硬體資源,應用程式工作負載的部份則是採用 Oracle 資料庫,並且搭配 Hammer DB 模擬工作負載,可以看到舊版 vSphere vMotion 的即時遷移機制,和重構與最佳化之後的新版 vSphere vMotion 相較之下,新版 vSphere vMotion 除了更快遷移完成之外,在即時遷移和切換恢復期間的 Oracle 資料庫,整體的 Commits 數量都優於舊版的 vSphere vMotion(如圖 9 所示)。

    圖 9、舊版和重構及最佳化的新版 vSphere vMotion 即時遷移測試結果

    事實上,VMware 官方除了針對剛才大型 VM 虛擬主機進行測試之外,也針對一般企業和組織中典型的 VM 虛擬主機,例如,「12 vCPU 和 64 GB vRAM」,甚至測試超大型的 Monster VM 虛擬主機,配置「192 vCPU 和 4 TB vRAM」硬體資源,同樣也採用 Oracle 資料庫和 Hammer DB 模擬工作負載。如圖 10 所示,可以看到不管哪種規格的 VM 虛擬主機,重構及最佳化的新版 vSphere vMotion 即時遷移機制,都有「2 ~ 11 倍」的提升,甚至超大型的 Monster VM 虛擬主機更達到「19 倍」的效能提升。

    圖 10、重構及最佳化的新版 vSphere vMotion 即時遷移提升數倍效能





    實戰 vCLS(vSphere Clustering Services)

    vCLS(vSphere Clustering Services),為最新 vSphere 7 Update 1 的新增特色功能。這是 VMware 官方,嘗試將 vSphere 叢集服務和 vCenter Server 進行脫勾,為 vSphere 叢集服務建立「分佈式控制平面」(Distributed Control Plane)的第一個版本。

    熟悉 vSphere 基礎架構的管理人員便知,當 vSphere 基礎架構中 vCenter Server 發生故障損壞事件時,其上運作的 VM 虛擬主機和容器等相關工作負載,並不會受到影響且能夠持續運作,然而管理人員也將因為 vCenter Server 損壞,而無法針對 VM 虛擬主機和容器等工作負載進行管理作業。

    此外,在 vCenter Server 故障損壞期間,ESXi 虛擬化平台中的 vSpehre HA Agent 仍然能夠正常運作,確保 ESXi 虛擬化平台若不幸同時發生故障損壞事件時,能夠透過 vSphere HA 高可用性機制,自動將 VM 虛擬主機和容器等工作負載,重新啟動在 vSphere 叢集中,其它仍然存活的 ESXi 虛擬化平台中繼續運作。

    對於小型 vSphere 基礎架構來說,這樣的高可用性機制已經足夠。但是,對於中大型的 vSphere 基礎架構來說就顯得不足,舉例來說,因為 vCenter Server 發生故障損壞事件時,原本能夠將 VM 虛擬主機和容器等工作負載,自動進行遷移的vSphere DRS(Distributed Resource Scheduler)機制便無法運作。

    雖然,管理人員可以整合 vSphere HA(High Availability)vCHA(vCenter Server High Availability)高可用性機制,確保 vCenter Server 管理平台能夠在最短時間內復原上線,繼續擔任 vSphere 基礎架構管理平台的重任。然而,諸如 vSphere DRS、Storage DRS 等 vSphere 叢集服務,仍然圍繞在 vCenter Server 管理平台身上。

    因此,VMware 官方打造出 vCLS 叢集服務,讓 vSphere 叢集服務和 vCenter Server 管理平台能夠脫勾。簡單來說,在新版 vSphere 7 U1 建構的 vSphere 叢集環境中,當 vCenter Server 管理平台發生故障損壞事件時,透過 vCLS 叢集服務能夠讓 vSphere DRS 等 vSphere 叢集服務,不因 vCenter Server 管理平台故障而停擺並且持續運作



    vCLS 運作架構

    在 vCLS 叢集服務的運作架構中(如圖 11 所示),將會在 vSphere 叢集中建立「1 ~ 3 台」vCLS VM 虛擬主機,這個特殊的 VM 虛擬主機,稱為「System VMs」或「Agent VMs」。
    vCLS VM 虛擬主機數量,取決於 vSphere 叢集中 ESXi 成員主機數量,當 ESXi 成員主機只有 1 台時則建立 1 台 vCLS VM 虛擬主機,當 ESXi 成員主機只有 2 台時則建立 2 台 vCLS VM 虛擬主機,當 ESXi 成員主機為 3 台或 3 台以上時建立 3 台 vCLS VM 虛擬主機。
    圖 11、vCLS 叢集服務運作架構示意圖

    值得注意的是,vCLS VM 虛擬主機並非一般典型的 vSphere VM 虛擬主機,而是 VMware 官方透過 Photon OS 運作的客製化 VM 虛擬主機,使用非常少的硬體資源,並且必須採用或升級至 vCenter Server 7 Update 1 版本,系統才會在 vSphere 叢集中自動部署 vCLS VM 虛擬主機。下列為 vCLS VM 虛擬主機所使用的硬體資源列表:
    • 1 vCPU(Reservation 100MHz)
    • 128 vRAM(Reservation 100MB)
    • 2 GB vDisk(Thin Provision)
    • No Ethernet Adapter
    vCLS VM 虛擬主機沒有配置網路卡如何互相溝通? 因為,vCLS VM 虛擬主機為透過 VMCI 和 vSOCKET 介面,與底層的 vSphere ESXi Hypervisor 進行溝通,所以無須配置 vNIC 虛擬網路卡。

    此外,倘若 vSphere 叢集建立時,尚未建構共享儲存資源時,那麼系統便會將 vCLS VM 虛擬主機,部署在 ESXi 成員主機的本地端儲存資源當中,後續管理人員也可以透過 Storage vMotion,將 vCLS VM 虛擬主機的儲存資源,線上儲存遷移至支援高可用性機制的共享儲存資源中。



    部署 vCLS VM 虛擬主機

    當 vSphere 基礎架構運作環境時,只要採用或升級至 vCenter Server 7 Update 1 版本後,將會發現只要建立 vSphere 叢集後,系統便會依序自動執行「Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務(如圖 12 所示),也就是執行自動化部署 vCLS VM 虛擬主機的動作。
    即便 vSphere 叢集尚未啟動 vSphere DRS 進階功能,系統仍然會自動部署 vCLS VM 虛擬主機的動作。
    圖 12、系統自動部署 vCLS VM 虛擬主機

    管理人員可以在 Cluster 層級中,隨時查看 vCLS 運作的健康狀態。登入 vCenter Server 管理介面後,依序點選「vCenter Server > Datacenter > Cluster > Summary」項目,展示「Cluster Services」項目後,即可從「Cluster Service health」欄位看到目前的 vCLS 健康狀態(如圖 13 所示)。如下所示,便是 vCLS 的三種健康狀態和說明:
    • Healthy : 健康情況良好。在 vSphere 叢集中,至少有一台 vCLS VM 虛擬主機正常運作中,並且為了確保 vCLS VM 虛擬主機的高可用性,系統將會依據 vSphere 叢集中 ESXi 成員主機數量,最多部署 3 台 vCLS VM 虛擬主機。
    • Degraded : 已降級。在 vSphere 叢集中,發生至少一台 vCLS VM 虛擬主機未正常運作,當系統重新部署 vCLS VM 虛擬主機,或是重新啟動 vCLS VM 虛擬主機時,vCLS 叢集健康情況便會處於此狀態。
    • Unhealthy: 不健康。當 vCLS 控制平台無法使用,並且導致 DRS 自動化負載平衡機制被跳過時,vCLS 叢集健康情況便會處於此狀態。
    有關 vSphere Cluster Service 的健康情況詳細說明,請參考 VMware KB 79892文件。
    圖 13、管理人員可隨時查看 vCLS 健康狀態

    由於,vCLS VM 虛擬主機的特殊性,所以當管理介面切換至管理人員常用的「Hosts and Clusters」模式時,並無法看到部署的 vCLS VM 虛擬主機,必須切換至「VMs and Templates」模式,才會在「vCLS」資料夾下,看到已經部署並運作中的 vCLS VM 虛擬主機。

    同時,vCLS VM 虛擬主機的部署和維運管理作業,是由系統中的 vSphere Cluster Services 自動化進行,完全無須管理人員介入。所以,當管理人員切換到任意一台 vCLS VM 虛擬主機時,即可看到提示訊息,說明 vCLS VM 虛擬主機的「資源使用、電力狀態、健康狀態」,由 vSphere Cluster Services 進行維護管理(如圖 14 所示),並且在 Notes 中說明 vCLS VM 虛擬主機的詳細資訊。

    圖 14、查看 vCLS VM 虛擬主機相關資訊

    因此,倘若管理人員嘗試編輯 vCLS VM 虛擬主機時,系統便會跳出警告訊息,提示管理人員無須人為介入(如圖 15 所示),因為 vCLS VM 虛擬主機將由 vSphere Cluster Services 進行維運管理作業。

    圖 15、系統提示管理人員無須人為介入 vCLS VM 虛擬主機的維運管理作業

    在 vCLS VM 虛擬主機生命週期管理的部份,由 vSphere EAM(ESX Agent Manager)維護管理(如圖 16 所示)。因此,當使用者嘗試刪除或關閉 vCLS VM 虛擬主機電源時,vSphere EAM 將會執行自動「開機」(Power On)或「重新建立」(Re-Create)的動作。

    圖 16、vCLS VM 虛擬主機生命週期由 vSphere EAM 負責維護管理



    vCLS 高可用性測試

    如前所述,vCLS VM 虛擬主機由 vSphere Cluster Services 進行維運管理作業,所以管理人員可以手動測試 vCLS VM 虛擬主機的高可用性。首先,測試強制關閉 vCLS VM 虛擬主機電源,查看將會發生什麼情況,請點選 vCLS VM 虛擬主機後,依序點選「Power > Power Off」項目,強制關閉 vCLS VM 虛擬主機電源,同樣的當管理人員嘗試強制關閉 vCLS VM 虛擬主機電源時,系統也會出現警告資訊,並建議管理人員參考 VMware KB 79892文件內容。

    管理人員將會發現,手動強制關閉 vCLS VM 虛擬主機電源後,系統偵測到 vCLS VM 虛擬主機電源狀態的異動,在「10 秒鐘」之後自動執行「Power On」將 vCLS VM 虛擬主機自動開機(如圖 17 所示)。

    圖 17、手動強制關閉 vCLS VM 虛擬主機電源 10 秒後系統自動開機

    在本文實作環境中,vSphere 叢集中共有三台 ESXi 成員主機,因此系統分別在每台 ESXi 成員主機中,部署一台 vCLS VM 虛擬主機。管理人員可以測試,當 vCLS VM 虛擬主機所在的 ESXi 成員主機,進入「維護模式」(Maintenance Mode)時,vCLS VM 虛擬主機將會如何運作。

    在目前 vSphere 叢集運作環境中,名稱為「vCLS(3)」的 vCLS VM 虛擬主機,運作在名稱為「esxi7-n03.lab.weithenn.org」的 ESXi 成員主機中,當 ESXi 成員主機進入維護模式後,可以看到系統自動將「vCLS(3)」vCLS VM 虛擬主機,遷移至「esxi7-n02.lab.weithenn.org」ESXi 成員主機上繼續運作(如圖 18 所示)。
    目前,vSphere DRS 版本中的「反關聯性規則」(Anti-Affinity Rules),並不適用於 vCLS VM 虛擬主機。因此,當 ESXi 成員主機離開維護模式後,管理人員必須手動遷移 vCLS VM 虛擬主機至原本的 ESXi 成員主機中。
    圖 18、ESXi 成員主機進入維護模式後,vCLS VM 虛擬主機自動遷移後繼續運作

    值得注意的是,若 vCLS VM 虛擬主機,採用的儲存資源為 ESXi 成員主機的「本地儲存資源」時,當 ESXi 成員主機進入維護模式時,則 vCLS VM 虛擬主機將會執行「Power Off」關機作業,並且在 ESXi 成員主機離開維護模式時,自動執行「Power On」開機作業。
    因為 ESXi 成員主機進入維護模式時,僅會針對採用共享儲存資源的工作負載,進行遷移「運算資源」的動作,而不會同時遷移工作負載的「運算和儲存資源」。

    最後,測試當管理人員強制刪除 vCLS VM 虛擬主機後,系統是否會執行生命週期維護管理作業,執行重新部署和開機運作等工作任務。請先針對名稱為「vCLS(1)」的 vCLS VM 虛擬主機,強制執行關閉電源的動作,緊接著執行「Delete from Disk」的刪除作業。
    在 vSphere 叢集中的工作負載,必須處於「關機」(Power Off)狀態才能執行刪除的工作任務。

    從系統工作任務清單中可以看到,當管理人員手動刪除 vCLS VM 虛擬主機後,在「30 秒鐘」之後執行 vCLS VM 虛擬主機生命週期維護管理作業,自動執行重新部署、組態設定、開機等工作任務(如圖 19 所示),而重新部署 vCLS VM 虛擬主機的新名稱為「vCLS(4)」,並且運作在原本「esxi7-n01.lab.weithenn.org」的 ESXi 成員主機中。

    圖 19、系統自動執行 vCLS VM 虛擬主機生命週期維護管理作業





    結語

    透過本文的深入剖析和實作演練後,相信管理人員已經了解到重磅更新的 vSphere 7.0 Update 1 版本,除了增強原有特色功能之外,更推出同時滿足企業和組織內 Dev 和 Ops 人員需要的功能,例如,Ops 維運人員無須費心導入 NSX-T 軟體定義網路,採用原有的 vDS 分佈式交換器,即可打造出滿足 Dev 開發人員的容器執行環境。

    Insiders Preview - Windows Server 2022

    $
    0
    0


    前言

    Windows Server 2022 (Windows Server Preview Build 20287),已經於 2021 年 1 月 27 日正式發佈。有興趣嘗鮮的朋友,只要申請加入 Windows Insider Program for Windows Server 計劃即可下載。



    下載 Windows Server 2022 ISO 檔

    登入 Windows Insider Preview Downloads頁面後,可以看到有多種格式可供管理人員選擇,包含 ISO、VHDX、Language Pack、Windows Admin Center v2012。





    安裝 Windows Server 2022

    本文使用 Windows Server 2019 Hyper-V 環境,建立 Generation 2的 VM 虛擬主機後,順利安裝 Windows Server 2022。安裝過程中,可以分別採用的試用 Standard、Datacenter 版本的授權金鑰如下:(請注意,這版的 Windows Server Preview 將在 2021 年 10 月 31 日過期)
    • Standard:MFY9F-XBN2F-TYFMP-CCV49-RMYVH
    • Datacenter: 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67


    安裝後,確認目前的 Windows Server 2022 版本資訊。





    安裝 Windows Admin Center v2012

    安裝最新版本的 Windows Admin Center Preview - Build 2012 (2020 年 12 月版本),不過安裝完畢後,在 WAC 管理介面查看版本資訊時,仍然顯示 WAC v2009 (2020 年 9 月) 版本。




    What's New and Next for Windows Server

    有興趣了解更多有關 Windows Server 2022 新版特色功能的朋友,可以搶先看看這個 Video (17 分鐘 55 秒)。下列是該 Video 提到的特色功能:
    • Storage Migration Service Update
    • NetApp Migration
    • DFSN Migration
    • Azure Cloud Tiering Integration
    • SMB compression with 20H2 (包含 Demo)
    • SMB over QUIC (包含 Demo)


    修復 Sudo Buffer Overflow 漏洞 (CVE-2021-3156)

    $
    0
    0


    前言

    簡單來說,近期 Sudo出現 Buffer Overflow 漏洞 (CVE-2021-3156),相關報導如下:



    修復 Sudo Buffer Overflow 漏洞

    本文,將以 CentOS 7.9版本為例。首先,檢查目前的 Sudo 版本資訊。


    你可以下載 RedHat 官方提供的檢查工具,或者採用 Sudo 官網提供的檢測方式,查看執行「sudoedit -s /」的指令執行結果。從下圖可以看到,採用 RedHat 檢查工具,可以看到結果是「This sudo version is vulnerable.」,而採用 Sudo 官方提供的檢測方式得到的結果是「sudoedit: /: not a regular file」,這二種檢查的結果都表示這台主機的 Sudo 套件尚未修復。


    你可以採用 YUM 的方式「yum -y update」去更新套件 (包含 sudo),若是主機無法連外網的朋友,也可以到 CentOS Mirror Site去下載「sudo-1.8.23-10.el7_9.1.x86_64.rpm」套件進行修復。完成修復的動作後,再次執行即可發現順利修復。

    網管人 181 期 - 微軟超融合雲端作業系統 Azure Stack HCI 開箱

    $
    0
    0


    網管人雜誌

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










    前言

    在 2020 年的 Microsoft Inspire 2020 大會  上,微軟首度發佈新一代的 HCI 超融合雲端作業系統「Azure Stack HCI」,相信管理人員肯定會產生疑惑,新一代 Azure Stack HCI 和 Windows Server 2019 作業系統,所建置的 HCI 超融合叢集運作環境有何不同 ?簡單來說,新一代的 Azure Stack HCI 超融合雲端作業系統,是專為 HCI 超融合環境進行重新設計(如圖 1 所示),並且針對 Azure 公有雲環境進行深度整合。

    圖 1、Azure Stack HCI 運作架構示意圖





    Azure Stack HCI 亮眼新功能

    首先,企業和組織期待已久的「自動容錯移轉延伸叢集」(Stretched Cluster for Automatic Failover)特色功能,便在新一代 Azure Stack HCI 超融合叢集架構中開始支援。因此,企業和組織可以透過自動容錯移轉延伸叢集功能,在兩座資料中心之間,建立並啟用延伸叢集功能的 Azure Stack HCI 超融合運作環境,透過採用「Active-Passive」或「Active-Active」運作模式(如圖 2 所示),幫助企業或組織的營運服務達到高可用性和彈性。
    請注意,自動容錯移轉延伸叢集功能僅支援 Azure Stack HCI,透過 Windows Server 2019 部署的 HCI 超融合環境並不支援。
    圖 2、自動容錯移轉延伸叢集 Active-Passive 和 Active-Active 運作架構示意圖

    由於,Azure Stack HCI 更精簡且重新設計後少掉許多舊有包袱,因此在執行磁碟區的「修復」(Repair)「重新同步」(Resync)時也獲得大幅度的改善。根據微軟官方的測試結果,同樣的運作環境和工作負載情況,與傳統 Windows Server 2019 HCI 超融合環境相較下,新一代的 Azure Stack HCI 重新同步時間將會「減少 4-5 倍」之多(如圖 3 所示)。

    圖 3、重新設計的 Azure Stack HCI 在修復和重新同步時效能大幅提升

    除了每月定期安全性更新之外,原則上每一年 Azure Stack HCI 便對釋出新功能版本,以便企業和組織可以不斷推進並享有各式亮眼特色功能。舉例來說,目前最新版本為 Azure Stack HCI 20H2,其中「20H2」版本的表示方式為「Second half of 2020」,也就是 2020 年下半年發佈的版本,而下一版便為 Azure Stack HCI 21H2(如圖 4 所示)。

    圖 4、Azure Stack HCI 版本更新原則和支援週期





    實戰 – 部署 Azure Stack HCI 超融合叢集

    在本文實作環境中,總共建立四台主機,前二台主機採用 Windows Server 2019 作業系統,第一台主機擔任 DC 網域控制站的角色(網域名稱為「lab.weithenn.org」),另一台主機擔任 Windows Admin Center 管理平台的角色,另外二台主機則採用新版 Azure Stack HCI 20H2 雲端作業系統,並擔任 HCI 超融合叢集中節點主機的角色。
    在開始建構 HCI 超融合運作環境之前,建議為四台主機安裝最新安全性更新後再開始建構,避免建置過程中遭遇非預期的錯誤。



    部署 Azure Stack HCI 20H2 雲端作業系統

    過去,採用 Windows Server 2019 作業系統建置 HCI 超融合環境時,僅使用眾多伺服器角色和功能當中的其中幾項而已。但是,新一代的 Azure Stack HCI 20H2 雲端作業系統(如圖 5 所示),則是重新設計且高度客製化的新版雲端基礎平台,同時只專注於提供 Azure Stack HCI 超融合叢集功能,並移除其它非必要的伺服器角色和功能,舉例來說,其它 Windows Server 應用中常見的 Web Server(IIS)、DFS Replication、iSCSI Target Server、Remote Desktop Services……等,都不存在於 Azure Stack HCI 雲端作業系統當中。
    此外,從安裝映像檔的檔案大小也可知兩者的差別,Windows Server 2019 的 ISO 映像檔大小為「4.93 GB」左右,而 Azure Stack HCI 的 ISO 映像檔僅為「2.9 GB」大小。
    圖 5、安裝新一代的 Azure Stack HCI 20H2 雲端作業系統

    安裝完成後,系統將會出現命令提示字元視窗,提醒管理人員必須變更 Administrator 管理員帳號密碼,完成密碼變更作業後,將會出現「伺服器組態設定工具」(Server Configuration Tools,Sconfig)視窗,方便管理人員執行基本的伺服器組態設定作業,例如,組態設定 IP 位址、變更電腦名稱、加入網域環境……等(如圖 6 所示)。
    事實上,微軟已經著手重新設計和客製化新的組態設定管理工具,屆時將取代目前預設的 Sconfig 伺服器組態設定工具,以便提供給管理人員更佳的使用者操作體驗。
    圖 6、Azure Stack HCI 20H2 登入後自動開啟伺服器組態設定工具

    為二台 HCI 超融合叢集節點主機,組態設定 IP 位址「10.10.75.21 和 10.10.75.22」,以及電腦名稱「HCI-Node01 及 HCI-Node02」。在儲存裝置部份,每台 HCI 叢集節點主機除了作業系統硬碟之外,額外配置「4 顆」300GB 的 SSD 固態硬碟(如圖 7 所示),以便屆時採用「All-Flash」類型建立 HCI 超融合叢集,並且這二台 HCI 叢集節點主機都加入「同一個」Windows AD 網域。

    圖 7、每台 HCI 叢集節點主機額外配置 4 顆 300GB 的 SSD 固態硬碟



    部署 Windows Admin Center 管理平台

    在 WAC(Windows Admin Center)管理主機的部份,完成基本的伺服器組態設定後加入「lab.weithenn.org」網域環境,並安裝最新版本「Windows Admin Center version 2009」(如圖 8 所示)。
    請注意,所謂 WAC v2009 版本並非 2009 年所發佈的 WAC 產品版本,而是指 2020 年 09 月所發佈的版本,微軟在發佈公告中也提醒大家正確的唸法為「Twenty oh-nine」。
    圖 8、採用最新發佈的 Windows Admin Center v2009 版本

    事實上,在最新的 WAC v2009 版本中,除了針對 VM 虛擬主機的管理功能不斷增強,例如,線上遷移儲存資源(Live Storage Migration)、親和性和反親和性規則(Affinity / Anti-Affinity Rules)……等之外,也開始支援部署和管理新版容器工具,舉例來說,透過 WAC 管理平台為內部資料中心內的 Windows Server 安裝 Docker 容器服務,支援經常使用的 Windows 容器映像檔,並且無須進行標記和鍵入容器映像檔名稱即可下載使用。

    在開始部署之前,請先確保 WAC 管理平台已經安裝「叢集建立延伸模組」(Cluster Creation Extension),確保支援部署和管理 HCI 超融合叢集。請於登入 WAC 管理介面後,依序點選「Settings > Gateway > Extensions > Installed extensions」項目,鍵入關鍵字「Cluster」後,點選「Cluster Creation(Preview)」項目,即可看到 Cluster Creation 延伸模組和相關資訊(如圖 9 所示),本文實作環境採用最新的「1.373.0」版本。

    圖 9、確認 WAC 管理平台已經安裝叢集建立延伸模組



    準備部署 HCI 超融合叢集

    回到 WAC 主要管理介面中,依序點選「All connections > Add > Server Clusters > Create new」項目,進入精靈互動模式準備部署 HCI 超融合叢集。

    首先,在 Choose the cluster type 頁面中,系統詢問管理人員準備部署哪種類型的叢集,分別有傳統的「Windows Server」叢集和「Azure Stack HCI」超融合叢集,在本文實作環境中請點選「Azure Stack HCI」項目。

    接著,在 Select Server Locations 選項中,系統詢問 HCI 超融合叢集的部署類型,分別是所有 HCI 叢集節點都在同一站台的「All servers in one site」,或者是分散在不同站台的「Servers in two sites」。在本文實作環境中,請點選所有 HCI 叢集節點都在同一站台的「All servers in one site」選項(如圖 10 所示)。
    倘若,後續管理人員要實作「自動容錯移轉延伸叢集」進階功能時,則請選擇「Servers in two sites」項目。
    圖 10、選擇部署 HCI 超融合叢集並且所有 HCI 叢集節點都處於同一站台



    部署 Azure Stack HCI 超融合叢集 – Get Started

    進入部署 Azure Stack HCI 超融合叢集組態設定流程後,透過叢集建立延伸模組的自動化組態設定流程,將會帶領管理人員在精靈互動模式中,輕鬆完成「Get Started > Networking > Clustering > Storage > SDN」五個階段。

    首先,在第一個階段 Get Started 內,於 1.1 Check the prerequisites 頁面中,系統提示相關前置作業資訊,例如,建議為 WAC 管理平台執行註冊至 Azure 的動作,屆時便可以透過 Azure Portal 輕鬆管理 Azure Stack HCI 超融合叢集,HCI 叢集節點主機必須採用 Azure Stack HCI 雲端作業系統,稍後的組態設定流程必須具備本機 Administrators 群組的權限才行……等,建議管理人員再次檢視是否符合相關條件,避免稍後的部署作業發生非預期的錯誤。

    在 1.2 Add servers 頁面中,請鍵入 HCI 叢集節點主機的管理者帳號及密碼,這個管理者帳號必須具備「Local Administrators Group」的身份和權限,然後鍵入 HCI 叢集節點主機的 FQDN 主機名稱,分別是「HCI-Node01 和 HCI-Node02」搭配網域名稱後按下 Add 鈕進行檢查(如圖 11 所示),通過系統檢查作業後再按下 Next 鈕繼續下一個組態設定流程。

    圖 11、新增 HCI 叢集節點主機並通過系統驗證程序

    在 1.3 Join a domain 頁面中,鍵入「lab.weithenn.org」網域管理者帳號,由於我們在基礎設定的前置作業中,已經將 HCI 超融合叢集節點主機加入網域,否則在此設定步驟中系統將會執行加入網域的動作,請按下 Apply changes 鈕讓系統進行檢查作業,當狀態列為「Changes applied」通過系統檢查程序後,即可按下 Next 鈕繼續下一個組態設定流程。

    在 1.4 Install features 頁面中,系統將會檢查 HCI 超融合叢集節點主機,是否安裝建構 Azure Stack HCI 超融合叢集所需的伺服器角色和功能。由於,在前置作業中僅進行基礎設定和加入網域,因此檢查結果為「Not installed」尚未安裝相關伺服器角色和功能,請按下 Install features 鈕,為 HCI 超融合叢集節點主機安裝所需的伺服器角色和功能,等待幾分鐘後順利安裝所需的伺服器角色和功能後,狀態改變為「Installed」後即可按下 Next 鈕繼續下一個組態設定流程。
    此步驟將會安裝 Data Deduplication、Hyper-V、BitLocker Drive Encryption、Data Center Bridging、Failover Clustering、Active Directory module for Windows PowerShell、Hyper-V Module for Windows PowerShell 等伺服器角色和功能。

    在 1.5 Install updates 頁面中,系統將會檢查 HCI 超融合叢集節點主機,是否安裝最新的安全性更新,以避免稍後建構 Azure Stack HCI 超融合叢集時,遭遇到非預期的系統錯誤或臭蟲導致部署失敗。由於,前置作業中已經為 HCI 超融合叢集節點主機安裝最新安全性更新,否則請按下 Install updates 鈕安裝最新安全性更新。

    在 1.6 Solution updates 頁面中,倘若採用的 HCI 超融合叢集節點主機伺服器供應商,有提供 WAC 管理平台延伸模組時便會安裝和檢查更新,例如,Dell EMC OpenManage Integration、Lenovo XClarity Integrator……等。

    由於,在 1.4 Install features 組態設定步驟中所安裝的伺服器角色和功能,例如,Hyper-V 伺服器角色,需要重新啟動主機後才能套用生效。因此,在 1.7 Restart servers 頁面中,可以看到二台 HCI 超融合叢集節點主機,檢查後的 Status 欄位值為「Restart needed」,請按下 Restart servers 鈕執行重新啟動和套用生效的工作任務。
    重新啟動 HCI 超融合叢集節點主機時,可以看到狀態列的變化為「Restarting > Verifying > Ready」。



    部署 Azure Stack HCI 超融合叢集 – Networking

    在 2.1 Verify network adapters 頁面中,系統將會檢查每一台 HCI 超融合叢集節點主機的網路組態,為稍後部署 HCI 超融合叢集虛擬交換器和虛擬網路環境做準備。

    在 2.2 Select management adapters 頁面中,請選擇每台 HCI 超融合叢集節點主機,用於「管理」(Management Network)用途的網路卡,並且按下「Apply and test」鈕進行套用生效和測試作業,在本文實作環境中選擇「二張」網路卡並建立網路卡小組,以便管理用途網路流量具備「負載平衡和容錯移轉」(Load Balancing and FailOver,LBFO)的高可用性機制,完成套用和測試作業程序後,可以發現系統自動建立網路卡小組「vEthernet(Management)」,並將相關網路卡名稱變更為「Management」以利識別(如圖 12 所示)。

    圖 12、指派每台 HCI 超融合叢集節點主機用於管理用途的網路卡

    在 2.3 Define networks 頁面中,管理人員可以看到 HCI 超融合叢集節點主機中,其它網路卡的網路資訊,包括,IP 位址、網路遮罩、MAC 位址、VLAN ID……等。值得注意的是,運作環境中實體交換器有啟動 Jumbo Frame 機制時,請此頁面中下方展開 Advanced 項目,在 Jumbo packet size 欄位中填入適合的 MTU 數值。同樣的,請按下「Apply and test」鈕進行套用生效和測試作業,當 Statue 欄位值為「Passed」通過測試程序後,按下 Next 鈕繼續下一個組態設定流程。
    預設情況下,未啟用 Jumbo Frame 機制的 Jumbo packet size 欄位值為 1514

    在 2.4 Virtual switch 頁面中,請管理人員選擇符合運作環境的虛擬交換器架構,系統將會為每一台 HCI 超融合叢集節點主機,建立 vSwitch 虛擬網路交換器。在本文實作業環境中,同樣規劃二張網路卡用於「VM 虛擬主機」網路流量,而另外二張網路卡則規劃為「S2D 儲存資源」網路流量,所以選擇「Create two virtual switches」項目(如圖 13 所示),分別建立二台不同用途的 vSwitch 虛擬網路交換器,以便分別處理 VM 虛擬主機和 S2D 儲存資源網路流量。

    圖 13、建立 HCI 超融合叢集環境 vSwitch 虛擬網路交換器

    此外,在 Azure Stack HCI 超融合叢集環境中,並非建立傳統的 Hyper-V vSwitch 虛擬網路交換器,展開下方 Advanced 子項目後,可以看到系統預設已經勾選「Use switch-embedded teaming」選項,表示稍後建立支援 RDMA 卸載功能的「SET(Switch-Embedded Teaming)」虛擬網路交換器。



    部署 Azure Stack HCI 超融合叢集 – Clustering

    在 3.1 Validate cluster 頁面中,系統在建構 Azure Stack HCI 超融合叢集之前,執行「叢集驗證」(Cluster Validation)的動作,確保每台 HCI 超融合叢集節點主機符合各項運作需求,避免稍後建立 HCI 超融合叢集時發生非預期的錯誤。

    請按下 Validate 鈕執行叢集驗證作業,系統將會彈出啟用 CredSSP 驗證機制的說明,請按下 Yes 鈕進行啟用並執行叢集驗證的動作。倘若,發生無法順利執行驗證機制,並得到「The WinRM client cannot process the request.」的錯誤訊息時,管理人員可以在 HCI 超融合叢集節點主機上,手動執行「Enable-WSManCredSSP -Role "Server"」PowerShell 指令,待部署完成後再進行停用的動作即可。

    當叢集驗證工作任務經過幾分鐘完成檢查作業後,管理人員可以按下 Download report,下載容錯移轉叢集驗證報告查看檢查作業細項(如圖 14 所示)。

    圖 14、通過叢集驗證工作程序並查看檢查作業細項

    在 3.2 Create cluster 頁面中,請於 Cluster name 欄位鍵入 HCI 超融合叢集名稱,本文實作名稱為「HCI-Cluster」,展示 Advanced 子項目後,在 Networks 的部份保持預設值「Use all networks」即可,在 IP addresses 選擇「Specify one or more static addresses」項目,然後鍵入 HCI 超融合叢集固定 IP 位址,本文實作為「10.10.75.30」按下 Add 鈕,然後按下「Create cluster」鈕執行建立容錯移轉叢集的動作,經過幾分鐘作業時間後系統顯示順利建立容錯移轉叢集。
    此時,在 DC 網域控制站當中,將會建立名稱為「HCI-Cluster」的叢集電腦帳戶,並且新增 DNS 正反解位置。



    部署 Azure Stack HCI 超融合叢集 – Storage

    在 4.1 Clean drives 頁面中,將每台 HCI 超融合叢集節點主機中的儲存資源進行整合。值得注意的是,倘若 HCI 超融合叢集節點主機中的儲存裝置,已經被「宣告」(Claimed)為使用狀態,例如,硬碟初始化為 GPT 格式、硬碟格式化為 NTFS 檔案系統...…等。

    屆時,這些已經宣告使用狀態的儲存裝置,便無法整合加入至 HCI 超融合叢集的儲存資源當中。因此,系統提醒管理人員再次確認儲存裝置未進行宣告,倘若管理人員無法確認儲存裝置是否為乾淨狀態的話,請按下「Erase drives」鈕執行儲存裝置內容清空的動作。

    在 4.2 Verify drives 頁面中,將會檢查每台 HCI 超融合叢集節點主機中,可用於 HCI 超融合叢集的儲存裝置,在本文實作環境中,正確檢查出每台 HCI 超融合叢集節點主機,額外配置的「4 顆」300GB SSD 固態硬碟。

    在 4.3 Validate Storage 頁面中,針對儲存裝置是否能加入 HCI 超融合叢集的儲存資源進行驗證,驗證作業完成後可以按下 Download report,查看容錯移轉叢集報表中,針對 Storage Spaces Direct 的驗證檢查細項(如圖 15 所示)。

    圖 15、通過 HCI 超融合叢集儲存資源驗證程序並查看驗證報表內容

    在 4.4 Enable Storage Spaces Direct 頁面中,請按下「Enable」鈕執行啟用 Storage Spaces Direct 機制,在原有 Windows Server 容錯移轉叢集架構中整合儲存資源,啟用成為 Azure Stack HCI 超融合叢集架構。同樣的,經過幾分鐘作業時間後,順利啟用 Storage Spaces Direct 技術,管理人員可以下載報表檔案查看詳細資訊(如圖 16 所示)。

    圖 16、HCI 超融合叢集建構完成



    部署 Azure Stack HCI 超融合叢集 – SDN

    HCI 超融合叢集最後部署階段,可以直接將「網路控制器」(Network Controller),部署在 HCI 超融合叢集最後部署階段中,打造出「軟體定義網路環境」(Software Defined Networking,SDN)。由於,文章篇幅的關系便暫不建立 SDN 軟體定義網路環境,所以請按下「Skip」略過定義和部署網路控制器的動作。

    至此,Azure Stack HCI 超融合叢集已經部署完成。同時,在 WAC 管理介面 All connections 清單中,已經自動出現 HCI-Cluster 超融合叢集,點選後即可開始透過 WAC 管理 Azure Stack HCI 超融合叢集。

    現在,管理人員便可以透過 WAC 管理平台,看到 HCI 超融合叢集的各種使用率和工作負載情況,包括,HCI 叢集節點主機數量、儲存裝置數量、運作的 VM 虛擬主機數量、HCI 叢集整體 CPU/Memory/Storage 工作負載情況、IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率……等(如圖 17 所示)。

    圖 17、透過 WAC 管理平台查看和管理 HCI 超融合基礎架構



    關閉 CredSSP 通訊協定

    由於,剛才建立 Azure Stack HCI 叢集過程中,我們為每一台 HCI 叢集節點主機,啟用有安全性疑慮的 CredSSP 通訊協定。現在,Azure Stack HCI 叢集已經部署完成,我們可以停用每台 HCI 叢集節點主機的 CredSSP 通訊協定,降低主機安全性風險。

    請在 Windows Admin Center 管理頁面中,點選 All connections 內的個別的 HCI 叢集節點主機,在 Overview 項目中即可看到「Disable CredSSP」鈕(如圖 18 所示),按下後當系統成功停用 CredSSP 通訊協定後該按鈕便會消失。

    圖 18、停用每台 HCI 叢集節點主機的 CredSSP 通訊協定



    CAU 自動化部署安全性更新

    在 Azure Stack HCI 超融合叢集環境中,管理人員可以透過「叢集感知更新」(Cluster-Aware Updating,CAU)機制,輕鬆為 Azure Stack HCI 超融合叢集部署安全性更新機制。請點選左側的「Updates」項目,準備透過 CAU 叢集感知更新機制,為 Azure Stack HCI 超融合叢集進行安全性更新。

    按下「Check for updates」鈕,系統將會檢查每台 HCI 叢集節點主機作業系統層級的安全性更新,接著檢查硬體伺服器的安全性更新,確認進行安裝作業後按下「Install」鈕即可,每台 HCI 叢集節點主機,便會依序執行「Fetching Status > Waiting > Scanning > Staging > Installing > Succeeded」等動作(如圖 19 所示),管理人員可以透過「Update Status」欄位狀態,了解每台 HCI 叢集節點主機部署安全性更新的狀態。
    倘若,得到「cloudn't configure cluster aware updates」的錯誤訊息,管理人員可能忘記給予 HCI-Computer 叢集電腦帳戶,在 DC 網域控制站所處的 OU 中具備「建立電腦物件」(Create Computer Objects)的權限,詳細資訊請參考 Microsoft KB 288935
    圖 19、透過 CAU 機制為 HCI 叢集節點主機部署安全性更新





    結語

    透過本文的深入剖析及實作演練,管理人員只要透過 WAC 管理平台,即可輕鬆部署新一代 Azure Stack HCI 超融合叢集,同時後續的維運和管理也都可以透過 WAC 管理平台完成,幫助原本 IT 人員編制便不多的中小型企業,能夠有更佳的部署和管理體驗。

    部署 vRealize Operations Manager 後,如何移除?

    $
    0
    0


    前言

    近期,因為需要評估 vROps (vRealize Operations Manager),對於 vSphere 叢集和 vSAN 超融合叢集的分析和統計,所以部署了 vROps 在測試環境中。

    部署作業完成後,順利在 vCenter Server 管理介面中,透過 vRealize Operations within vCenter 機制,直接看到 vROps 輕量級儀表板 (如下圖所示)。


    然而,當測試完畢該如何移除它? 倘若,只是把部署的 vROps Instance 關機的話,那麼本來的頁面內容,會變成無法和 vROps Instance 溝通的錯誤訊息 (如下圖所示)。




    移除 vCenter Server 中 vROps Plug-ins

    下列便是在 vCenter Server 管理介面中,移除 vROps Plug-ins 的方式。詳細資訊,請參考 VMware KB 1025360 - Cannot remove or disable unwanted plug-ins from vCenter Server and vCenter Server Appliance知識庫文章內容。

    首先,連結到「https://vCenter_Server/mob」網址,例如,本文實作環境「https://vcenter.lab.weithenn.org/mob」,通過使用者身份驗證後,在 ServiceInstance 頁面中點選「content」。


    進入後,點選「ExtensionManager」。


    在 ExtensionManager 頁面中,首先檢查在 Properties 內,是否看到 extensionList 內有「com.vmware.vrops」項目,確認有的話,按下 Methods 內的「UnregisterExtension」。


    在彈出的頁面中,鍵入要取消的 Plug-ins 名稱,本文實作環境為「com.vmware.vrops」(請注意! 舊版名稱為 com.vmware.vcops),詳細請參考 VMware KB 1025360 - Cannot remove or disable unwanted plug-ins from vCenter Server and vCenter Server Appliance 知識庫文章內容。

    鍵入完成後,按下「Invoke Method」後,系統會回傳成功的訊息「void」(表示成功移除)。


    倘若,系統移除不成功的話,便會出現「NotFound」且「Unset」的回傳值,例如,VMware KB 1025360 - Cannot remove or disable unwanted plug-ins from vCenter Server and vCenter Server Appliance 知識庫文章內容,寫的是舊版名稱為 com.vmware.vcops


    成功移除後,回到 ExtensionManager 頁面,可以看到 extensionList 內原本的「com.vmware.vrops」項目,恢復成準備部署的「com.vmware.vrops.install」項目。


    順利完成移除的動作後,回到 vCenter Server 管理介面中,再次點選 vRealize Operations 頁面,便會看到頁面內容已經變成可以按下 INSTALL 鈕的部署畫面。



    [站長開講] VMware vCenter Server HA 高可用性實戰班

    $
    0
    0


    活動資訊

    日期: 2021 年 4 月 24 日 ~ 4 月 25 日
    時間: 09:00 ~ 17:00
    地點: 台北資策會 (台北市復興南路一段 390 號 3 樓)
    報名: 資策會課程 - VMware vCenter Server HA高可用性實戰班



    課程大綱

    vCenter Server HA 高可用性架構規劃

    • vCenter Server HA 運作架構
    • Active / Passive / Witness 角色
    • vCenter Server HA 軟硬體需求
    • vCenter Server HA 部署模式
    • vCenter Server HA 虛擬網路流量規劃
    • vCenter Server HA 最佳建議作法

    建構 vCenter Server HA 高可用性實作環境

    • Nested VMs / vSphere in a box

    組態設定 vCenter Server HA 虛擬網路

    • 管理網路(Management Network)
    • vCenter 高可用性網路(vCenter HA Network)

    建置 vCenter Server HA 高可用性環境

    • 部署第一台 vCenter Server(Active Node)
    • 建立 vCenter HA Passive Node 和 Witness Node
    • vCenter Server HA 容錯移轉

    vCenter Server HA 維運管理

    • 容錯移轉類型(Automatic / Manual)
    • vCenter Server HA 維護模式(Maintenance Mode)
    • vCenter Server HA 重新啟動
    • vCenter Server HA 備份和還原
    • 調整 vCenter Server HA 規模大小

    [站長開講] Microsoft Hyper-V 伺服器虛擬化實戰班

    $
    0
    0

     


    前言

    在本課程中,我們將帶領你建置及管理 Microsoft Hyper-V 伺服器虛擬化平台,包括,建置 WSFC 容錯移轉叢集、實作即時遷移(Live Migration)、儲存即時遷移(Live Storage Migration)、無共用儲存即時遷移(Shared-Nothing Live Migration)、快速遷移(Quick Migration)……等



    課程日期




    課程內容

    高可用性及高效能虛擬化平台架構規劃實務

    • 如何規劃所要採用的 x86 實體伺服器規格
    • CPU 中央處理器指令集的選擇
    • Memory 記憶體的選擇
    • NVMe/SSD/SAS/NL-SAS/SATA 硬碟種類的選擇與 IOPS 規劃
    • RAID Card 的選擇與 RAID 模式規劃
    • Network 網路環境的規劃

    建置容錯移轉叢集環境

    • 選擇儲存資源(DAS / NAS / SAN)
    • 安裝與設定 Windows Server 2019 Hyper-V 角色
    • 建立 WSFC 容錯移轉叢集

    計畫性及非計畫性停機解決方案

    • 即時遷移(Live Migration)
    • 儲存即時遷移(Live Storage Migration)
    • 無共用儲存即時遷移(Shared-Nothing Live Migration)
    • 快速遷移(Quick Migration)

    VM 虛擬主機進階管理

    • 客體服務(Integration Services)
    • 加強的工作階段 (Enhanced Session Mode)
    • VM 軟體授權自動啟用(AVMA)
    • 虛擬磁碟線上擴充和縮小(Disk Online Extend / Shrink)
    • 儲存資源 IOPS 品質控制(Storage QoS)
    • 備份及還原(Export / WSB)
    • 應用程式監控(VM Monitoring)
    • 主機反關聯性(Anti-Affinity)
    • 叢集共用磁碟區快取(CSV Cache)

    異地備援方案

    • Hyper-V 複本代理人(Hyper-V Replica)
    • 測試容錯移轉
    • 計畫性容錯移轉
    • 非計畫性容錯移轉
    • 延伸複寫

    叢集感知更新

    • 叢集節點維護模式(Maintenance Mode)
    • 叢集感知更新(CAU)
    • 匯出叢集感知更新報表

    網管人 182 期 - 啟用原生檔案服務 vSAN 也能運作 NFS/SMB

    $
    0
    0


    網管人雜誌

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










    前言

    在 2020 年 4 月 VMware 官方發佈全新 vSAN 7 版本,在 2020 年 10 月時推出最新「vSAN 7 Update 1」版本。或許,一般對於 Update 1 版本的認知僅是小版本的更新,然而 vSAN 7 Update 1 版本,則是除了增強原有特色功能之外,同時新增許多亮眼的特色功能。
    本文因篇幅關係,僅說明部份亮眼特色功能,詳細資訊請參考 VMware vSAN 7.0 Update 1 Release Notes
    事實上,VMware vSAN 超融合基礎架構,已經不僅僅是企業和組織內部資料中心的主要基礎架構,更是 SDDC 軟體定義資料中心願景和 VCF(VMware Cloud Foundation)的主要基礎架構。現在,無論是地端的 SDS 軟體定義儲存,或是混合 SDC 和 SDS 的 HCI 超融合基礎架構,甚至是各大公有雲供應商,例如,Amazon AWX、Microsoft Azure、Google GCP、IBM Cloud……等,都已經支援原生 vSAN 超融合基礎架構,達成串接公有雲和私有雲形成更具彈性的混合雲運作環境(如圖 1 所示)。

    圖 1、VMware 雲端核心基礎架構 vSphere 和 vSAN 運作架構示意圖





    vSAN 7 Update 1 亮眼特色功能

    事實上,根據 VMware 官方壓力測試數據的結果顯示,最新的 vSAN 7 Update 1 版本,除了下列說明的亮眼特色功能之外,與舊有的 vSAN 6.7 Update 3 版本相較之下,整體儲存效能提升約「30 %」之多,這表示企業和組織無須更換原有硬體,只要升級至新版 vSAN 7 Update 1 運作環境,即可享有儲存效能提升 30% 的好處。



    vSAN HCI Mesh

    在過去的 vSAN 叢集架構中,雖然可以透過 Scale-UpScale-Out方式擴充 vSAN 叢集規模,或者整合 vSAN iSCSI Target 機制,提供 vSAN 儲存資源給其它工作負載使用。然而,管理人員更希望 vSAN 叢集之間的儲存資源能夠彼此共享互助,以便其上運作的 VM 虛擬主機和容器等工作負載,能夠更容易在 vSAN 叢集之間無縫遷移。

    現在,全新的 vSAN 7 U1 版本,便新增 vSAN 叢集分佈式機制稱之為「超融合網狀」(HCI Mesh)架構。簡單來說,在多個 vSAN 叢集運作架構下,每個 vSAN 叢集不僅能夠使用自身建構的本地端 vSAN Datastore,還能夠掛載和使用其它 vSAN 叢集的 vSAN Datastore 儲存資源(如圖 2 所示)。
    請注意,在 vSAN 7 U1 版本中,HCI Mesh 機制僅支援最多串連「16」個 vSAN 叢集,並且每個 vSAN 叢集支援最多掛載「5」個遠端 vSAN Datastore 儲存資源。
    圖 2、新版 vSAN 7 U1 HCI Mesh 運作架構示意圖



    vSAN DPp 資料持續性平台

    vSAN「資料持續性平台」(Data Persistence platform,DPp),支援在 Kubernetes 容器平台的 vSphere Supervisor 叢集中,部署第三方軟體和工作負載並原生支援儲存物件複寫和保護機制(如圖 3 所示)。

    圖 3、vSAN DPp 資料持續性平台運作架構示意圖

    簡單來說,即便管理人員採用「FTT=0」的 vSAN 儲存原則進行部署,仍然不影響部署工作負載的可用性,真正達到「無共享」(Shared-Nothing)儲存資源的目標(如圖 4 所示)。

    圖 4、vSphere Shared Nothing Storage 運作架構示意圖

    舉例來說,現代化應用程式中有許多工作負載的儲存資源,都是透過本地端儲存資料後,透過分散式架構進行資料的複寫和壓縮……等,例如,MinIO Object Storage、NoSQL Database……等。此時,管理人員便可以透過 vSAN Direct 機制(如圖 5 所示),讓工作負載不要使用傳統的 vSAN Datastore,而是適用於現代化應用程式的「vSAN-D」Datastore 儲存資源。

    圖 5、vSAN Direct 運作架構示意圖



    同時支援 NFS 和 SMB 檔案共享

    過去,企業或組織若希望 vSphere 運作環境能夠支援 NFS 檔案共享時,唯一的解決方案便是採用 Storage VM 提供 NFS 檔案共享機制(如圖 6 所示)。在前一版 vSAN 7 版本中,vSAN 叢集已經透過「原生檔案服務」(Native File Services),支援 NFS 檔案共享機制,並採用 Photon OS 架構運作「檔案服務虛擬主機」(File Service VM,FSVM),除了有效解決過去 Storage VM 提供 NFS 檔案共享機制的缺點之外,同時提升 NFS 檔案共享效能並降低 vSphere ESXi 工作負載。

    圖 6、傳統 Storage VM 提供 NFS 檔案共享機制有許多缺點

    現在,最新的 vSAN 7 U1 版本,除了原有支援的 NFS v3NFS v4.1通訊協定外,新增支援 SMB v2.1SMB v3通訊協定。簡單來說,無論是 Windows 主機和 Linux 主機或容器,都能夠輕鬆透過 NFS 或 SMB 檔案共享機制,掛載使用並運作於高效能和高可用性的 vSAN Datastore 儲存資源之上(如圖 7 所示)。
    在 vSAN 7 版本中,每個 vSAN 叢集最多支援運作「8」台 File Service 虛擬主機。最新 vSAN 7 U1 版本,則支援每個 vSAN 叢集最多運作「32」台 File Service 虛擬主機。
    圖 7、最新 vSAN 7 Update 1 原生檔案服務運作架構示意圖



    共享 vSAN Witness

    在 vSAN 叢集運作架構中,當 vSAN 叢集的節點主機數量為小型規模的「2」台時,管理人員必須額外部署「vSAN 見證主機」(vSAN Witness Host),以避免小型規模的 vSAN 叢集發生「腦裂」(Split-Brain)的情況。然而,當企業或組織有許多分公司或辦事處時,可能會建構許多小型規模的 vSAN 叢集,並部署同等數量的 vSAN 見證主機,形成無謂的資源閒置和浪費的情況。

    因此,新版 vSAN 7 U1 版本中,小型規模的 vSAN 叢集可以共同使用,由總公司建置單一且具備高可用性的 vSAN 見證主機即可,無須再為每個小型規模的 SAN 叢集建構獨立的 vSAN 見證主機(如圖 8 所示)。
    在新版 vSAN 7 U1 中,單一 vSAN 見證主機最多支援「64」個小型規模 vSAN 叢集。
    圖 8、新版 vSAN 7 U1 版本中,支援 2-Node vSAN 叢集共用單一 vSAN 見證主機



    儲存資源可用率增加

    在 vSAN 叢集架構中,除了 VM 虛擬主機和容器等工作負載使用的儲存物件之外,vSAN 叢集的各項操作,例如,重新負載平衡 vSAN 節點主機儲存資源、重新配置 vSAN 儲存原則、受損儲存物件重建工作任務、vSAN 節點主機之間儲存物件重新同步……等,皆會佔用儲存空間。

    因此,在過去的 vSAN 叢集架構中,將會針對這些 vSAN 叢集維運操作步驟預留「25 – 30 %」的儲存空間,並且這個預留空間是「固定」(Fixed)且無法進行任何變更。
    固定不可變更的預留空間稱之為「寬限儲存空間」(Slack Space)

    新版 vSAN 7 U1 版本中,除了將這個預留空間,從過去固定不可變更調整為「可變」(Varies)之外(如圖 9 所示),並拆解為「操作預留」(Operations Reserve,OR)「主機重建預留」(Host reBuild Reserve,HBR),更在 vSAN 叢集中針對儲存堆疊進行最佳化,達到最大化程度縮小儲存預留空間的目的。

    圖 9、新版 vSAN 7 U1 將固定不可變改為視情況變動的預留儲存空間機制

    此外,管理人員可以依據 vSAN 叢集規模和專案需求,直接透過 vSphere 管理介面調整 OR 操作預留和 HBR 主機重建預留儲存空間比率(如圖 10 所示)。下列,則是 VMware 官方依據不同 vSAN 叢集規模,預設採用的儲存空間比率和總預留儲存空間比率:
    • 4台 vSAN 叢集節點主機: 10 % OR + 25 % HBR30 %總預留儲存空間比率)
    • 6台 vSAN 叢集節點主機: 10 % OR + 17 % HBR27 %總預留儲存空間比率)
    • 7台 vSAN 叢集節點主機: 10 % OR + 13 % HBR23 %總預留儲存空間比率)
    • 12台 vSAN 叢集節點主機: 10 % OR + 8 % HBR18 %總預留儲存空間比率)
    • 18台 vSAN 叢集節點主機: 10 % OR + 6 % HBR16 %總預留儲存空間比率)
    • 24台 vSAN 叢集節點主機: 10 % OR + 4 % HBR14 %總預留儲存空間比率)
    • 32台 vSAN 叢集節點主機: 10 % OR + 3 % HBR13 %總預留儲存空間比率)
    • 48台 vSAN 叢集節點主機: 10 % OR + 2 % HBR12 %總預留儲存空間比率)
    • 64台 vSAN 叢集節點主機: 10 % OR + 2 % HBR12 %總預留儲存空間比率)
    圖 10、組態設定 OR 操作預留和 HBR 主機重建預留儲存空間比率





    實戰 vSAN 7 原生檔案服務

    現在,新版 vSAN 7 U1 已經支援提供 SMBv2.1 和 SMBv3檔案共享機制,除了提供給 Windows 主機和 Linux 主機和容器進行檔案共享儲存資源外,同時整合企業和組織內的 Active Directory 進行身份驗證(如圖 11 所示)。
    請注意,vSAN 7 版本僅支援 NFSv3 和 NFSv4.1 檔案服務,必須採用最新 vSAN 7 U1版本才支援 SMBv2.1 和 SMBv3 檔案服務。
    圖 11、最新版本 vSAN 原生檔案服務,同時支援 NFS 和 SMB 協定運作架構示意圖



    啟用 vSAN 原生檔案服務

    在本文實作環境中,在 vSAN 叢集內共部署 3 台 vSAN 叢集節點主機,並完成 vDS 分佈式虛擬交換器的組態設定(如圖 12 所示),確保屆時 3 台 vSAN 節點主機之間 vSAN Traffic 儲存流量交換。同時,在相關前置作業完成後,於 vSAN 叢集中啟用 vSAN 超融合功能,以便將 3 台 vSAN 節點主機的本機儲存裝置,彙整成為高效能和高可用性的 vSAN Datastore 儲存資源。

    圖 12、用於 vSAN 叢集環境的 vDS 分佈式虛擬交換器組態設定示意圖

    確認 vSAN 叢集和超融合功能正常運作後,請依序點選「vSAN Cluster > Configure > vSAN > Services > File Service > Enable」項目,系統便會彈出組態設定原生檔案服務精靈的對話視窗。
    在組態設定畫面中,系統再次提醒管理人員繼續下一個操作步驟之前,應先確認是否已經準備好運作環境,例如,固定 IP 位址、DNS 名稱解析、AD 網域環境……等。
    在 File service agent 頁面中,選擇採用「Automatic Approach」預設值項目,並且勾選「Trust the certificate」選項(如圖 13 所示),以便 vCenter Server 能夠直接前往 VMware 官方,下載最新穩定版本的檔案服務代理程式,並於下載完成後部署至 vSAN 叢集中的每一台 vSAN 節點主機。

    值得注意的是,採用自動下載檔案服務代理程式選項時,一旦管理人員按下 Next 鈕之後,vCenter Server 便會立即至 VMware 官網下載檔案服務代理程式,並在下方 Task Panel 顯示下載進度,工作進度名稱為「Download vSAN File Service OVF」。
    倘若,vCenter Server 無法接觸網際網路,則管理人員必須預先下載好 vSAN File Service OVF,並改為選擇「Manual Approach」項目,以手動的方式上傳檔案服務代理程式。
    圖 13、採用自動前往 VMware 官方下載最新穩定版本的檔案服務代理程式

    在 Domain 頁面中,管理人員必須提供 vSAN 檔案服務的相關資訊,例如,本文實作環境中檔案服務網域名稱為「vsanfs」、而 DNS 名稱解析伺服器的 IP 位址為「10.10.75.10」、DNS 尾碼為「lab.weithenn.org」、勾選「Active Directory」項目啟用 AD 身份驗證機制、AD 網域名稱、網域管理員帳號和密碼……等資訊(如圖 14 所示)。

    圖 14、組態設定 vSAN 檔案服務的網域相關資訊

    在 Networking 頁面中,管理人員必須選擇屆時部署檔案服務代理程式,所要使用的 SMB 檔案共享網路環境 vDS Port Group,點選 Network 欄位下拉式選單,選擇本文實作環境採用的「SMB Network」,並鍵入子網路遮罩「255.255.255.0」和預設閘道「10.10.75.254」(如圖 15 所示)。

    圖 15、組態設定檔案服務代理程式使用的 SMB 檔案共享網路環境 Port Group

    在 IP Pool 頁面中,管理人員必須鍵入檔案服務代理程式所要使用的 IP 位址資源池,在 VMware 最佳建議作法中,建議為 vSAN 叢集中的每一台 vSAN 節點主機,額外配置專用於 SMB 檔案共享服務 IP 位址資源池,並建議採用連續的 IP 位址。在本文實作環境中,鍵入第一筆 IP 位址「10.10.75.31」後,按下「Lookup DNS」確保能夠正確進行 DNS 名稱解析,然後按下「AutoFill」系統將依序遞增 IP 位址,並再次按下 Lookup DNS 鈕確保新加入的 IP 位址能夠順利進行 DNS 名稱解析(如圖 16 所示)。
    選項中「Primary」的 IP 位址,表示屆時將負責 NFS/SMB 主要重新導向介面,將檔案共享服務網路流量,重新導向至不同台 vSAN 節點主機的檔案服務代理程式。
    圖 16、組態設定檔案服務代理程式所要使用的 IP 位址資源池

    在 Review 頁面中,再次檢視所有組態設定內容正確無誤後按下 Finish 鈕,系統便立即進行檔案服務代理程式的部署作業。一旦部署工作任務完成後,在 vSAN 叢集中的每一台 vSAN 節點主機上,便會運作一台「vSAN File Service Node」的虛擬主機(如圖 17 所示),採用的客體作業系統為「VMware Photon OS」,並由 vSphere ESX Agent Manager 所管理。
    管理人員可以觀察到,因為有 3 台 vSAN 節點主機所以部署 3 台 vSAN File Service Node,並且系統將會優先部署 Primary 的 vSAN 節點主機,接著建立快照後再複製並部署至其它台 vSAN 節點主機。
    圖 17、系統自動化部署 vSAN File Service Node 虛擬主機



    檢查檔案服務健康狀態

    順利部署 vSAN File Service Node 虛擬主機後,在組態設定 SMB 檔案共享機制之前,請先在管理介面中依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health > File Service > Infrastructure Health」項目,確認 vSAN 叢集檔案服務的基礎架構系統服務健康狀態,例如,部署的 vSAN File Service Node、VDFS 服務、根目錄檔案系統、檔案服務負載平衡機制……等(如圖 18 所示)。

    圖 18、檢查 vSAN 叢集檔案服務的基礎架構系統服務健康狀態

    接著,點選「File Service > File Server Health」項目,檢查 vSAN 叢集檔案服務中,檔案服務網域名稱是否正確,NFS 和 SMB 檔案共享服務是否運作正常、根目錄檔案系統是否能正常存取……等(如圖 19 所示)。

    圖 19、檢查 vSAN 叢集檔案服務健康狀態



    建立 SMB 檔案共享機制

    確認 vSAN 檔案服務皆運作正常後,請在管理介面中依序點選「vSAN Cluster > Configure > vSAN > File Shares」項目後,按下「Add」準備新增 SMB 檔案共享機制。

    在本文實作環境中,SMB 檔案共享網路名稱為「smb-share」,在通訊協定的部份由於 vSAN 7 U1 版本,已經同時支援 NFS 和 SMB 檔案共享機制,所以記得通訊協定選擇至「SMB」項目,在 vSAN 儲存原則的部份採用「vSAN Default Storage Policy」預設值。同時,管理人員可以啟用 SMB 檔案共享儲存空間限制,本文實作組態設定觸發儲存空間警告的臨介值為「5 GB」,並且限制最大儲存空間為「10 GB」(如圖 20 所示)。

    圖 20、組態設定 SMB 檔案共享網路名稱和儲存空間警告並限制最大儲存空間

    在 Review 頁面中,再次檢視所有組態設定內容是否正確無誤,確認無誤後按下 Finish 鈕,立即執行 SMB 檔案共享的工作任務。當 SMB 檔案共享機制建立完成後便能看見相關資訊,後續管理人員也可以依照專案需求,隨時調整套用的 vSAN 儲存原則,以及儲存空間警告和儲存空間限制臨界值(如圖 21 所示)。

    圖 21、SMB 檔案共享機制建立完成



    掛載 SMB 檔案共享儲存資源

    那麼,從 Windows 主機端該如何掛載 SMB 檔案共享儲存資源 ?管理人員可以從管理介面中,點選本文實作的 SMB 檔案共享資源項目後,按下 SMB export path 欄位的「Copy Path」圖示,系統便會自動複製 SMB 檔案共享資源掛載路徑至主機的剪貼簿內。

    請在 Windows 主機端開啟檔案總管後,依序點選「This PC > Map network drive」項目,在 Folder 欄位貼上剛才複製的 SMB 檔案共享路徑,本文實作環境為「\\vsan-fs01.lab.weithenn.org\vsanfs\smb-share」後,按下 Finish 鈕即可(如圖 22 所示)。

    圖 22、掛載 SMB 檔案共享儲存資源



    測試警告和儲存空間限制機制

    接著,測試先前組態設定的 SMB 檔案共享儲存空間警告和最大儲存空間限制機制,在本文實作環境中觸發儲存空間警告的臨介值為「5 GB」,而最大儲存空間限制為「10 GB」。首先,在 Windows 主機端,透過檔案總管複製 7.53 GB 的測試檔案過去,然後切換至 SMB 檔案共享管理介面中,可以看到已經觸發儲存空間警告,並且距離最大儲存空間限制的門檻也已達「75 %」使用率(如圖 23 所示)。

    圖 23、查看 SMB 檔案共享儲存空間警告和儲存空間限制資訊

    由於,仍然未達到 SMB 檔案共享最大儲存空間限制 10 GB,所以 Windows 主機端仍然能夠寫入檔案,然而當我們寫入資料達到最大儲存空間限制 10 GB 門檻時,嘗試再寫入資料時便會出現錯誤訊息,並且無法再繼續寫入任何資料(如圖 24 所示)。

    圖 24、寫入資料達到最大儲存空間限制 10 GB 時便無法再寫入任何資料

    此時,切換至 vSphere 管理介面,依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health」項目,可以看到「File Service > Share health」子項目出現黃色警告訊息,原因便是 SMB 檔案共享儲存資源達到最大儲存空間限制(如圖 25 所示)。
    管理人員可以擴充 SMB 檔案共享最大儲存空間限制,或者刪除 SMB 檔案共享儲存資源中不必要的檔案,那麼 SMB 檔案共享便會再次恢復健康狀態。
    圖 25、透過 Skyline Health 健康偵測機制,查看 SMB 檔案共享儲存資源健康情況

    此外,管理人員也可以直接查看 SMB 檔案共享的儲存效能資訊,例如,Throughput、IOPS、Latency……等(如圖 26 所示),確保提供給 Windows 主機端最佳使用者操作體驗。

    圖 26、查看 SMB 檔案共享的儲存效能資訊

    值得注意的是,目前在 vSphere 管理介面中,無法直接查看 SMB 客戶端存取資訊,例如,哪些 Windows 主機存取 SMB 檔案共用資源、哪些網域使用者帳號進行存取、開啟哪些 SMB 儲存資源內的檔案……等。請在剛才複製 SMB 檔案共用的視窗中,按下 MMC command 欄位的複製圖示,接著在 Windows 主機端中的命令提示字元內執行,即可透過 Windows 主機的 MMC 查看相關資訊(如圖 27 所示)。

    圖 27、透過 MMC 指令查看 SMB 檔案共用資源存取資訊



    測試 vSAN 檔案服務高可用性

    由於,SMB 檔案共享儲存資源為運作在 vSAN 叢集之上的應用服務,所以如同運作在 vSAN Datastore 內受保護的工作負載一樣,除了享有 vSAN 叢集提供的高效能之外同樣兼具高可用性。

    在 vSphere 管理介面中可以看到,目前建立的「smb-share」檔案共享儲存資源中,系統自動指派「vsan-smb01.lab.weithenn.org」主機負責,將此台 vSAN 節點主機直接斷電以便模擬故障損害的情境,同時測試 SMB 檔案共享儲存資源的可用性。

    在管理介面中依序點選「vSAN Cluster > Monitor > vSAN > Virtual Objects > Affected inventory objects > File Shares」項目後,點選 SMB 檔案共享儲存資源「smb-share」,按下「View Placement Details」,即可看到 SMB 檔案共享儲存資源物件,分佈在 vSAN 叢集中哪些 vSAN 節點主機上(如圖 28 所示)。

    圖 28、查看 SMB 檔案共享儲存資源物件分佈情況

    當 vSAN 節點主機「vsan-smb01.lab.weithenn.org」斷電後,再次查看 SMB 檔案共享儲存資源物件分佈情況,可以發現原本由「vsan-smb01.lab.weithenn.org」主機負責的儲存物件,狀態由先前健康良好的「Active」轉變為「Absent」(如圖 29 所示)。
    一旦 vsan-smb01.lab.weithenn.org 主機修復後回到 vSAN 叢集中,系統將會自動執行受損儲存物件的修復作業,或者 60 分鐘後自動由其它 vSAN 節點主機接手重建相關儲存物件。
    圖 29、原本由 vsan-smb01.lab.weithenn.org 節點主機負責儲存的物件狀態轉變為 Absent

    此外,我們切換到「smb-share」檔案共享儲存資源頁面,可以看到原本由「vsan-smb01.lab.weithenn.org」負責 SMB 檔案共享服務,因為發生斷電故障損壞情況後,系統改為指派由「vsan-smb02.lab.weithenn.org」vSAN 節點主機,接手負責 SMB 檔案共享服務(如圖 30 所示)。
    當然,在 vsan-smb01 節點主機故障損壞期間,Windows 主機端仍然能夠正常存取 SMB 檔案共享儲存資源。
    圖 30、由 vSAN 節點主機 vsan-smb02.lab.weithenn.org 接手 SMB 檔案共享服務





    結語

    透過本文的深入剖析和實作演練後,讀者已經了解全新 vSAN 7 U1 版本新增哪些亮眼特色功能,同時建構 vSAN 7 U1 超融合叢集後,不僅提供企業和組織運作 VM 虛擬主機和容器等各項應用之外,只要為 vSAN 叢集啟用原生檔案服務之後,便能立即提供企業和組織常用的 NFS 和 SMB 檔案共享服務,並且無須再額外採購硬體儲存設備節省寶貴的 IT 預算。

    [站長開講] VMware vSphere 伺服器虛擬化實戰班

    $
    0
    0


    課程日期




    課程大綱

    VMware vSphere 伺服器虛擬化平台硬體規劃最佳建議作法

    VMware vSphere 伺服器虛擬化實作環境建置

    • Nested VMs / vSphere in a box

    建置 VMware vSphere 伺服器虛擬化平台

    • 建立 Windows Server 網域控制站和 DNS 名稱解析伺服器
    • 建立 iSCSI Storage 儲存伺服器
    • 安裝及管理 vSphere ESXi 7 虛擬化平台
    • 安裝及管理 vCenter Server 7 管理平台
    • 納管 vSphere ESXi 伺服器虛擬化平台
    • 建立 vSphere 資料中心和叢集(Datacenter / Cluster)

    建置 VMware vSphere vNetwork 虛擬網路環境

    • 建立和管理 vSS (vNetwork Standard Switch)
    • 建立和管理 Port Group
    • 建立和管理 Network Policy
    • 建立和管理 VMkernel Port
    • 建立和管理 NIC Teaming

    VM 虛擬主機管理

    • 虛擬磁碟線上擴充和縮小(Disk Online Extend / Shrink)
    • 記憶體熱新增(Memory Hot Add)
    • CPU 熱新增(CPU Hot Add)
    • 升級虛擬硬體版本(Upgrade VM Hardware version)
    • 限制 VM 虛擬主機網路和儲存資源(Network / IOPS)

    計畫性停機解決方案

    • 線上即時遷移(vSphere vMotion / DRS)
    • 儲存即時遷移(Storage vMotion / Storage DRS)
    • 無共用儲存即時遷移(vMotion Enhancements)

    非計畫性停機解決方案

    • 高可用性(vSphere HA / Fault Tolerance)

    網管人 183 期 - WAC 管理混合雲工作負載輕鬆部署 K8s 叢集及容器

    $
    0
    0


    網管人雜誌

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










    前言

    隨著新一代的 HCI 超融合雲端作業系統「Azure Stack HCI」發佈,微軟官方也不斷增強 Azure Stack HCI 基礎架構,並且支援更多運作環境的整合運用。事實上,原有的 HCI 超融合叢集環境,主要運作的工作負載是以 VM 虛擬主機為主,當企業和組織需要運作容器時,管理人員可以在 Linux 或 Windows 虛擬主機當中,部署 Docker 或其它容器引擎達到運作和管理數個容器的目的,然而這樣的運作情境,通常僅適用於少量容器工作負載的情況,例如,研發和測試環境。

    因此,考量企業和組織的正式營運環境,管理人員需要真正的容器管理調度平台,以便快速啟動 Linux 及 Windows 容器,同時能夠自動化管理容器的生命週期和自動延展,而 Kubernetes 則是目前所公認最佳的容器管理調度平台。

    隨著 Azure 公有雲環境上,AKS(Azure Kubernetes Service)容器服務的成熟,微軟官方決定為管理人員提供一致的操作管理體驗,將 Azure 公有雲環境上的 AKS 容器服務,落地運作在 HCI 超融合叢集環境中(如圖 1 所示)。
    微軟官方也預告,後續將會有更多 Azure 公有雲服務,支援落地運作在 HCI 超融合叢集中。
    圖 1、Azure Stack HCI 超融合叢集支援 AKS 容器服務示意圖

    企業和組織的管理人員,除了方便將營運服務的容器化工作負載達成一致性之外,打包客製化好的 Linux 或 Windows 容器映像檔,無須進行任何更改即可隨時部署於 Azure 公有雲環境,以及地端資料中心內建構的 HCI 超融合叢集環境中,達到真正混合雲部署和管理工作負載的目的。

    管理人員可以透過 PowerShell 指令進行管理,也可以採用 WAC(Windows Admin Center)管理平台,達到部署和管理 AKS 容器服務和容器工作負載的目的。當管理人員需要建立 Kubernetes 叢集時,只要在 WAC 管理介面中按下 Add 新增按鈕,即可看到支援部署 Kubernetes 叢集的選項(如圖 2 所示)。
    請注意,目前 AKS on Azure Stack HCI 仍然處於「公開預覽」(Public Preview)狀態。
    圖 2、透過 WAC 管理平台部署 Kubernetes 叢集





    AKS on Azure Stack HCI 儲存架構

    在 Kubernetes 叢集運作架構中,管理人員已經知道「Pod」是最小的工作負載運算資源單位,每個 Pod 可以包含 1 個或多個容器化的應用程式,而「持續性磁碟區」(Persistent Volumes)則是 Kubernetes 叢集中,容器使用儲存資源的基本單位,當 Pod 裡運作的容器需要儲存資源時,Kubernetes 叢集便會執行調度任務讓容器存取持續性磁碟區儲存資源。

    事實上,為了達成支援各類儲存供應商,將儲存資源提供給 Kubernetes 叢集中的容器使用,在 Kubernetes 叢集中提供「容器儲存介面」(Container Storage Interface,CSI)機制,以便儲存供應商能夠撰寫各類 CSI 驅動程式,進而讓 Kubernetes 叢集能夠透過 CSI 機制存取外部儲存資源,舉例來說,在 Azure 公有雲環境的 AKS 容器服務中,當 Kubernetes 叢集內的容器需要存取儲存資源時,AKS 容器服務的控制平台,便會自動安裝二個 CSI 驅動程式「azureDisk」和「azureFile」,其中 azureDisk 用於存取 Azure Disks,而 azureFile 則用於存取 Azure Files 儲存資源。

    了解 AKS 容器服務的持續性磁碟區儲存資源之前,先說明 Azure Stack HCI 超融合儲存基礎架構(如圖 3 所示),以幫助管理人員逐步了解 HCI 超融合叢集,如何將高效能高可用性的儲存資源,轉換成為持續性磁碟區儲存資源給容器工作負載使用。下列為傳統 VM 虛擬主機,使用 HCI 超融合叢集儲存資源的步驟:

    1. 採用通過 Azure Stack HCI 硬體認證的 x86 硬體伺服器,部署和建構 Azure Stack HCI 超融合叢集。
    2. Azure Stack HCI 節點伺服器之間,透過 10Gb、25Gb、40Gb、50Gb、100Gb……等高速乙太網路互相連接,以便 HCI 超融合叢集節點主機之間快速交換和同步資料區塊。
    3. 每台 Azure Stack HCI 節點伺服器,都將貢獻本機端的 NVMe、SSD、HDD 儲存裝置,並整合 S2D(Storage Spaces Direct)技術後,進而匯整成為高效能和高可用性的巨大儲存資源。
    4. 順利匯整儲存資源之後,管理人員依據需求切割出 VM 虛擬主機需要的「磁碟區」(Volume)儲存資源,包括,定義磁碟區的容錯等級和儲存空間大小……等資訊。
    5. 在 HCI 超融合叢集中運作的 VM 虛擬主機,於部署 VM 虛擬主機的過程中,建立 VHDX 虛擬硬碟時指向並掛載至剛才所建立的磁碟區。
    6. 運作於 HCI 超融合叢集上層的 VM 虛擬主機,掛載 VHDX 虛擬硬碟的儲存資源成功後,便可以在 HCI 超融合叢集內,不同的 HCI 節點主機之間進行各種資源的線上遷移。

    圖 3、Azure Stack HCI 超融合儲存基礎架構示意圖

    了解 VM 虛擬主機存取 HCI 超融合叢集的儲存資源方式後,接著進一步了解 Kubernetes 叢集中,擔任 Worker 角色的節點主機(VM 虛擬主機)如何掛載儲存資源,並透過 Kubernetes 叢集調度機制整合 CSI 容器儲存介面,提供儲存資源給予 Pod 內的容器使用(如圖 4 所示)。下列為 Kubernetes 叢集調度 HCI 超融合叢集儲存資源,掛載後給予 Pod 和容器使用的步驟:

    7.在 HCI 超融合叢集中,運作的 Kubernetes Controller 主機接收到儲存請求,例如,調度和部署新的Pod。
    8. Kubernetes Controller 主機將接收到的儲存請求,轉送至 Kubernetes Worker 節點主機中的「msvhd CSI」驅動程式,這個 msvhd CSI 驅動程式在先前部署 AKS 容器服務時,系統便會自動為 Kubernetes Worker 節點主機完成安裝。
    9. Kubernetes Worker 節點主機透過 msvhd CSI 驅動程式,向底層 HCI 超融合叢集中所有的 HCI 節點主機送出儲存資源請求。
    10.接收儲存資源請求的 HCI 節點主機,建立 VHDX 虛擬硬碟並執行附加和掛載的動作,提供給剛才提出儲存資源請求的 Kubernetes Worker 節點主機。
    11. Kubernetes Worker 節點主機,感知到附加的 VHDX 虛擬硬碟之後進行儲存裝置格式化,倘若為 Linux Worker 節點主機便採用 EXT4 檔案系統進行格式化,若是 Windows Worker 節點主機則採用 NTFS 檔案系統進行格式化。
    12.儲存裝置格式化程序完成後,Kubernetes Worker 節點主機將獲得的儲存資源掛載至 Pod,以便 Pod 內部運作的容器得以使用掛載完成的儲存資源。

    圖 4、Kubernetes Worker 節點主機,附加和掛載 HCI 超融合叢集儲存資源示意圖





    實戰 – 部署 AKS on Azure Stack HCI

    在 Azure 公有雲環境中使用 AKS 容器服務時,雖然管理人員可以透過 Azure Portal 操作介面,管理 Kubernetes 的「控制平面」(Control Plane)基礎架構,但是控制平面和容器化應用程式的底層基礎架構,則是運作在 Azure 公有雲環境所管理的 VM 虛擬主機中運作,管理人員並無法碰觸和進行管理(如圖 5 所示)。

    圖 5、在 Azure 公有雲環境中,使用 AKS 容器服務運作架構示意圖

    那麼,在 HCI 超融合叢集中運作的 AKS 容器服務,和 Azure 公有雲環境中運作的 AKS 容器服務有何不同 ?簡單來說,企業和組織必須全面管理整個 AKS 容器服務基礎架構,包括 AKS 容器服務的控制平台和容器化應用程式,都會以 VM 虛擬主機的方式運作在 HCI 超融合叢集當中(如圖 6 所示)。

    圖 6、在 HCI 超融合叢集中,部署 AKS 容器服務運作架構示意圖



    安裝 Azure Kubernetes Service 擴充模組

    在本文實作環境中,總共建立四台主機,一台主機採用 Windows Server 2019 作業系統,擔任 DC 網域控制站並建立名稱為「hci.weithenn.org」的網域環境,並且啟動 DNS 及 DHCP 伺服器的角色,另一台主機採用 Windows 10 Enterprise 20H2 版本,擔任 Windows Admin Center 管理平台角色,其它二台主機採用最新版本的 Azure Stack HCI 20H2 雲端作業系統,擔任 HCI 超融合叢集中節點主機角色。

    WAC(Windows Admin Center)管理主機的部份,完成基本的系統組態設定後加入「hci.weithenn.org」網域環境,並安裝最新版本「Windows Admin Center version 2009」。但是,登入 WAC 管理介面後,管理人員會發現在可安裝擴充模組的頁面中,並沒有「Azure Kubernetes Service」項目可供點選安裝?
    請注意! 必須採用 Windows 10擔任 WAC 管理平台角色,因為採用 Windows Server 2019 安裝 WAC 之後,屆時將會因為採用伺服器運作的 WAC Gateway 模式,導致部署 AKS 容器服務失敗的情況。

    出現這個情況的主要原因在於,落地 HCI 超融合叢集的 AKS 容器服務處於公開預覽狀態,所以管理人員必須先至 AKS on Azure Stack HCI 預覽註冊  頁面,完成註冊的動作後下載包括「.nupkg」的檔案,也就是適用於 WAC 擴充模組的 NuGet 套件,然後將 .nupkg 檔案儲存於 WAC 管理主機或 SMB 共用資料夾中。本文實作環境將下載後的 .nupkg 檔案,儲存於 WAC 管理主機的「C:\AKS-on-HCI-Lab」資料夾內。

    接著,在 WAC 管理介面中依序點選「Settings > Gateway > Extensions > Feeds > Add」項目,在彈出新增套件視窗路徑中貼上剛才儲存 .nupkg 的檔案路徑,順利載入新增的 NuGet 套件路徑後,回到可安裝擴充模組頁面中即可看到「Azure Kubernetes Service」項目,請按下 Install 鈕進行 AKS 容器服務擴充模組的安裝程序(如圖 7 所示)。

    圖 7、安裝適用 WAC NuGet 套件中的 AKS 容器服務擴充模組



    部署 Azure Kubernetes Service 管理叢集

    當 AKS 容器服務擴充模組安裝完成後,回到 HCI 超融合叢集管理介面中,將會看到多出 Azure Kubernetes Service 項目。值得注意的是,在開始部署 Azure Kubernetes Service 管理叢集之前,必須確保已經將 HCI 超融合叢集,註冊並連結至 Azure 公有雲環境(如圖 8 所示),否則稍後將無法順利部署 Azure Kubernetes Service 管理叢集。

    圖 8、確認 HCI 超融合叢集已經註冊和連結至 Azure 公有雲環境

    點選 Azure Kubernetes Service 項目後,按下 Set Up 鈕準備部署 Azure Kubernetes Service 管理叢集。在部署階段 1 先決條件頁面中,可以看到系統提醒管理人員前置作業相關注意事項,包括確認 HCI 超融合叢集已經註冊和連結至 Azure 公有雲環境,以及可用儲存空間和虛擬網路環境等資訊(如圖 9 所示)。

    圖 9、準備部署 Azure Kubernetes Service 管理主機

    在部署階段 2 系統檢查頁面中,請鍵入 HCI 超融合叢集的管理者帳號和密碼,系統會預先檢查 WAC 管理平台,是否已經正確註冊和連結至 Azure 公有雲環境,同時檢查 WAC 管理主機的儲存空間是否足夠存放,稍後下載 Azure Kubernetes Service 管理叢集的安裝映像檔,最後檢查 HCI 超融合叢集的系統組態設定,包括記憶體資源和 CSV 叢集共用磁碟區儲存空間是否足夠……等(如圖 10 所示)。

    圖 10、檢查 WAC 管理主機和 HCI 超融合叢集系統組態設定

    在部署階段 3 主機組態設定頁面中,請組態設定 AKS 容器服務的管理叢集名稱,選擇存放 AKS 管理叢集主機的 CSV 叢集共用磁碟區,以及所要採用的 vSwitch 虛擬網路交換器,最後則是負載平衡器的組態設定(如圖 11 所示)。
    請注意,屆時運作和承載容器的 Linux 及 Windows Workers 節點主機,也會採用此步驟中所選擇的 vSwitch 虛擬網路交換器。
    圖 11、組態設定 AKS 管理主機的叢集名稱和 vSwitch 虛擬網路交換器

    在部署階段 4 Azure 註冊頁面中,系統將會彈出視窗請管理人員鍵入準備使用的 Azure 訂閱帳戶,通過身份驗證程序後,便會顯示該 Azure 訂閱帳戶所能使用的 Azure 訂閱項目(如圖 12 所示)。

    圖 12、鍵入使用的 Azure 訂閱帳戶並選擇欲採用的 Azure 訂閱項目

    在部署階段 5 檢視和建立頁面中,再次檢視相關組態設定內容確認無誤後,按下 Next 鈕便開始執行部署 Azure Kubernetes Service 管理主機的動作。在本文實作環境中,部署 AKS 管理叢集和相關主機的動作,花費 56 分鐘才完成(如圖 13 所示)。

    圖 13、成功部署 Azure Kubernetes Service 管理叢集和相關主機

    現在,管理人員可以看到 AKS 管理叢集的相關概要資訊,例如,本文採用的 Kubernetes 版本為「v1.18.8」。值得注意的是,切換到「Compute > Virtual machines」項目,管理人員將會看到系統已經自動建立二台 VM 虛擬主機,並且這二台 VM 虛擬主機名稱中關鍵字分別為「Control-Plane」和「Load Balancer」,這二台 VM 虛擬主機便是負責 AKS 管理叢集中控制平面的部份。

    此外,當管理人員查看這二台 VM 虛擬主機的內容時,將會發現作業系統名稱為「Common Base Linux Mariner」(如圖 14 所示)。簡單來說,它是一個開放源始碼的 Linux 發行版本,剛才部署 AKS 容器服務時,系統自動執行下載和部署的動作,有興趣更深入了解的管理人員請參考 GitHub – Microsoft/CBL-Mariner: Linux OS for Azure 1P services and edge appliances內容。

    圖 14、負責 AKS 容器服務控制平面機制的 VM 虛擬主機,採用 Common Base Linux Mariner 作業系統



    部署 Kubernetes 叢集

    順利部署 AKS 容器服務管理叢集後,便可以接著部署 Kubernetes 叢集。管理人員可以在 WAC 首頁依序點選「Add > Kubernetes Cluster(Preview)> Create new」項目,或是在剛才 AKS 容器服務概要資訊頁面中,依序點選「Kubernetes Clulsters > Add Cluster」項目即可。

    首先,在部署階段 1 先決條件頁面中,可以看到系統提醒管理人員部署 Kubernetes 叢集注意事項。在部署階段 2 基本設定頁面中,請管理人員鍵入部署 Kubernetes 叢集的相關組態設定,例如,是否與 Azure Arc 進行整合、Kubernetes 叢集名稱……等(如圖 15 所示)。值得注意的是,在尚未通過 AKS 容器管理叢集身份驗證程序前,將會發現無法選擇 Kubernetes 叢集主要管理主機規格,必須待通過身份驗證程序後,才能調整 Kubernetes 叢集主要管理主機規格大小。
    在公開預覽期間,雖然無法調整 Kubernetes 叢集管理節點主機數量,但管理人員可以調整管理主機的規格大小。
    圖 15、鍵入部署 Kubernetes 叢集的相關組態設定

    在部署階段 3 節點主機集區頁面中,管理人員可以組態設定新增 Windows 或 Linux 節點主機數量。在部署階段 4 網路組態頁面中,管理人員可以定義 Kubernetes 叢集中,Pod 和 Kubernetes 叢集服務的 IP 位址範圍,以及負載平衡器、網路原則、HTTP 應用程式路由……等資訊(如圖 16 所示)。
    在 AKS 容器服務公開預覽期間,僅能新增一台 Windows 節點主機和一台 Linux 節點主機。
    圖 16、組態設定 Kubernetes 叢集虛擬網路環境

    在部署階段 5 整合儲存資源頁面中,系統將顯示 Kubernetes 叢集 CSI 容器儲存介面所要使用的儲存資源,以及持續性磁碟區的種類為固定或動態。在部署階段 6 檢視和建立頁面中,請管理人員再次檢視組態設定內容,確認無誤後按下 Create 鈕立即執行部署 Kubernetes 叢集的動作,在本文實作環境中,系統花費 9 分鐘時間順利部署 Kubernetes 叢集(如圖 17 所示)。

    圖 17、順利部署 Kubernetes 叢集

    現在,管理人員可以在 AKS 概要資訊頁面中,看到剛才部署的 Kubernetes 叢集健康情況以及採用的版本。同時,切換到「Compute > Virtual machines」項目,管理人員將會看到系統已經自動部署二台 VM 虛擬主機,並且這二台 VM 虛擬主機名稱中關鍵字也有「Control-Plane」和「Load Balancer」,這二台 VM 虛擬主機便是負責剛才部署 Kubernetes 叢集中控制平面的部份。

    此外,管理人員也可以在 PowerShell 視窗中使用「kubectl get」指令,查詢 Kubernetes 管理叢集的系統相關資訊(如圖 18 所示)。

    圖 18、查詢 Kubernetes 管理叢集的系統相關資訊



    部署 Linux 節點主機

    由於,剛才在部署 Kubernetes 叢集時為了加速部署速度,並沒有選擇額外部署 Linux 或 Windows節點主機。因此,當管理人員透過「Get-AksHciCluster」指令,查詢 Kubernetes 叢集時,可以發現僅部署控制平台,尚未部署 Linux 或 Windows 節點主機(如圖 19 所示)。

    圖 19、查詢 Kubernetes 叢集系統主機資訊

    管理人員透過 PowerShell 指令「Set-AksHciClusterNodeCount」,搭配參數「-linuxNodeCount 1」,指定 Kubernetes 叢集立即部署一台 Linux 節點主機(如圖 20 所示)。部署作業完成後,再次透過「Get-AksHciCluster」指令,即可查詢到 Kubernetes 叢集已經部署一台 Linux 節點主機。

    圖 20、指定 Kubernetes 叢集立即部署一台 Linux 節點主機



    部署 Linux 容器和應用程式

    現在,管理人員可以透過 YAML 檔定義運作指定的容器映像檔。在本文實作環境中,將部署 Azure 投票應用程式(azure-vote.yaml),這個 Azure 投票應用程式的前端介面採用 Python / Flask 技術,而資料元件的部份則採用 Redis,有興趣深入了解的管理人員請參考 GitHub - Azure-Samples/azure-voting-app-redis: Azure voting app used in docs.內容。

    完成「http://azure-vote.yaml」的 YAML 檔案內容後,執行「kubectl apply -f azure-vote.yaml」指令,立即部署「azure-vote-front」和「azure-vote-back」應用服務至 Kubernetes 叢集(如圖 21 所示)。部署完成後,可以查看 Kubernetes 叢集的 deployment、pods、service 狀態,其中「EXTERNAL-IP」欄位中的 IP 位址,便是透過使用者存取 Azure 投票應用程式的 IP 位址。
    請注意! 剛開始執行部署作業時,EXTERNAL-IP 欄位將為「pending」狀態,待部署完成且正確連接負載平衡器後,系統才會顯示可供使用者存取應用程式的 IP 位址。
    圖 21、部署 Azure 投票應用程式至 Kubernetes 叢集

    現在,使用者可以透過瀏覽器存取 Azure 投票應用程式,本文實作環境 IP 位址為「10.10.75.104」(如圖 22 所示),使用者可以隨意投票或按下 Reset 鈕清除投票結果。

    圖 22、使用者透過瀏覽器存取 Azure 投票應用程式



    調整 Pod 運作規模

    順利部署 Azure 投票應用程式後,管理人員可以隨時依照使用者存取和 Pod 工作負載情況,隨時線上調整「azure-vote-front」和「azure-vote-back」服務的運作規模。

    舉例來說,目前僅分別部署一個 Pod 來運作 azure-vote-front 和 azure-vote-back 工作負載,管理人員可以搭配參數「scale --replicas=5」,將指定的 Pod 數量從原本的「1 個」提升數量為「5 個」,也可以透過參數「scale --replicas=3」,將指定的 Pod 數量從提升後的「5 個」降低數量為「3 個」(如圖 23 所示)。

    圖 23、調整 Kubernetes 叢集內 Pod 運作規模





    結語

    透過本文的深入剖析及實戰演練,管理人員只要透過 WAC 管理平台,即可在企業和組織地端資料中心內的 Azure Stack HCI 超融合叢集中,輕鬆部署 AKS 容器服務和控制平面基礎架構,以及 Kubernetes 叢集和 Linux 與 Windows 節點主機,達成快速建構和部署 Kubernetes 叢集及容器應用程式的目標。

    [站長開講] DevOpsDays Taipei 2021

    $
    0
    0


    活動簡介

    DevOpsDays Taipei是由臺灣在地技術社群發起,結合社群、企業共同舉辦之年度 DevOps 盛會。DevOpsDays 由 DevOps 之父 Patrick Debois 發源自比利時,經過全球社群的共同響應,如今在全球,每年皆有多個城市舉辦以城市掛名的 DevOpsDays。

    根據 iThome 的報導,不論是國內外的知名企業例如台積電、金士頓、趨勢科技、國泰金控等皆早已擁抱 DevOps,引領企業持續改善、邁向新一波的 IT 數位轉型。DevOps 作為同時蘊含技術與文化轉型雙主軸的 IT 熱門關鍵字,其影響力已不僅是 IT 圈內人人皆知,更擴展至企業組織的各個層面。 

    DevOpsDays Taipei 2021 即將在 2021/5/28 於臺北文創盛大舉辦,Agile Community.tw、DevOps Taiwan Community、HashiCorp User Group Taipei 以及 iThome 再次攜手合作,期盼再創屬於臺灣在地的 DevOps 高峰盛會。





    活動資訊

    • 日期:   2021 年 5 月 28 日 (星期五)
    • 時間:   09:00 ~ 17:00
    • 地點:   臺北文創大樓
    • 報名:   活動報名





    議程內容



    Microsoft AI Fundamentals 免費學習課程和 AI-900 認證考試

    $
    0
    0


    前言

    對於「人工智慧」(Artificial Intelligence,AI) 技術有興趣,但是卻又苦於沒有學習資源的朋友。那麼,不妨考慮看看「Microsoft AI Fundamentals」線上免費學習課程。

    首先,假設你對於微軟有哪些雲端技術以及相關學習資源的各種面向,可以參考如下圖的 Microsoft Azure 認證海報,可以了解相關的 Microsoft Azure 基礎知識、基於角色的和專業認證……等資訊。






    Microsoft Certified

    目前,主流的微軟雲端認證有哪些? 透過下圖的 Microsoft Azure 認證類別海報,可以概略了解哪些技術方向,例如,Azure、Microsoft 365、Dynamics 365、Power Platform……等 ,和哪些認證考試代號 (如果你有興趣考照的話 😎)。






    Microsoft AI Fundamentals 線上學習資源

    想要應考 AI-900 認證考試,或是單純想了解 Microsoft Azure AI 技術的朋友,可以直接透過 Microsoft Learn 線上免費學習資源,學習 Microsoft AI 入門課程:





    AI-900 認證考試

    對於 Microsoft AI 基礎認證 (考試代號 AI-900) 有興趣的朋友。目前,台灣微軟在「2021 年 5 月 7 日」有舉辦免費的「AI-900 免費考照快閃班」,除了能夠線上學習 Microsoft AI 技術課程(英文講者,並且有中文字幕)。同時,還贈送 AI-900 認證考試免費考試卷 (價值 USD 75) 的機會。

    當你順利通過 AI-900 認證考試後,便能得到一張閃亮亮的認證。證明,你有 Microsoft AI 技術的基礎概念。站長,也不免俗的去考了一下 AI-900 的認證考試,在準備考試的過程中能夠順便了解 Microsoft AI 技術和原理。



    [站長開講] 臺灣雲端大會 Cloud Edge Summit Taiwan 2021

    $
    0
    0


    活動簡介

    過去一年,我們深陷於此生少見的動盪、驚惶和焦慮;原本大家害怕在疫情籠罩下,地表上一切都被按下無盡的休止符,豈料疫情不僅沒有拖慢我們的步伐,還注入數位轉型催化劑,觸動許多企業營運模式的翻轉,連帶開啟全球商業新競局。

    顯而易見,現今處在競局領先群的許多企業,普遍能展現又快又準的決策力和執行力,來自於他們懂得利用雲端與邊緣運算資源,一步到位駕馭先進數位科技,得以花費最低的成本與時間代價,不斷進行「選題、驗證、放大(或放棄)」的試錯循環,加速實現最小可行產品(MVP),進而加速佈建到全球市場,也加速輾壓了商業對手。

    新的一年,疫情依舊、轉型持續,讓我們再次擁抱雲邊科技,建立豐沛的數位力,力求守穩變局、突圍致勝!

    精彩內容,不容錯過,即刻報名「2021 iThome 臺灣雲端大會」!





    活動資訊

    • 日期:   2021 年 7 月 28 日 (星期三)
    • 時間:   08:00 ~ 16:30
    • 地點:   台北國際會議中心
    • 報名:   活動報名





    議程內容


    網管人 184 期 - 輕量級 vROps 儀表板監控 vSAN 效能

    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    當企業和組織建構完 vSphere 虛擬化基礎架構後,隨著內部專案數量和人員不斷成長之外,企業對外營運服務的類型也不斷改變,舉例來說,從過去僅提供網站服務,轉變為目前還必須提供智慧型手機 App 應用……等。

    對於內部 vSphere 虛擬化基礎架構來說,各種工作負載和類型也不斷增加,從過去單純的 VM 虛擬主機運作無高可用性的應用程式,到多台 VM 虛擬主機協同建構高可用性應用程式,轉變成目前新興流行的容器和微服務……等。

    因此,負責資料中心維運管理的 IT 人員,倘若沒有一套功能完整且具備高彈性和支援度高的系統協助時,那麼當企業和組織的營運服務發生問題時,只能透過各種系統內建陽春的監控服務,搭配管理人員的經驗判斷來進行故障排除作業,倘若管理人員經驗不足或問題牽涉範圍太廣泛時,都會無謂增加故障排除時間,不僅影響使用者操作體驗,更可能擴大影響企業和組織的公共形象及營運收入。

    舉例來說,企業營運服務建構在 vSphere 虛擬化基礎架構之上,搭配上層運作的 VM 虛擬主機或容器內的各種應用程式而成,那麼當營運服務發生問題時,到底是 vSphere 虛擬化基礎架構發生問題所導致,例如,CPU、Memory 運算資源不足、Storage 儲存資源不足、Network 網路資源不足……等,還是上層 VM 虛擬主機或容器內的作業系統故障,又或者是最上層的應用程式崩潰所導致?

    此時,倘若有一套監控工具,能夠將企業營運服務的各項節點,透過視覺化的方式展示出來(如圖 1 所示),那麼當企業營運服務發生各種狀況時,管理人員便能透過視覺化儀表板的輔助,快速找出問題並進行故障排除作業,讓營運服務能夠在最短時間內恢復正常。

    圖 1、VMware vRealize Operations Cloud 應用程式監控架構示意圖

    然而,有些管理人員或許覺得 VMware vRealize Operations 監控工具,功能性太過複雜架構太過龐大,中小型企業和組織可能無須這些繁雜的功能和監控項目。此時,管理人員可以考慮採用本文的解決方案,在本文中將深入剖析和實作演練,輕量級的 vRealize Operations 監控工具,並且它能夠直接整合至 vCenter Server 管理介面中,無須離開 vCenter Server 管理平台便能查看分析和統計數據,協助管理人員快速判斷問題並進行故障排除作業。





    實戰 vRealize Operations within vCenter

    過去,當管理人員建構 vSAN 超融合叢集環境後,在沒有導入其它分析和監控方案時,通常僅能採用 vCenter Server 管理平台中,內建的效能監控工具察看 vSAN 超融合叢集的健康情況和工作負載(如圖 2 所示)。接下來,將實際部署和組態設定 vRealize Operations within vCenter監控機制,讓 vRealize Operations 的分析和統計結果,直接整合在 vCenter Server 管理介面中,透過簡化後的 vRealize Operations 效能和工作負載儀表板,幫助管理人員察看 vSAN 超融合叢集的各種效能資訊和運作情況。
    後續我們將 vRealize Operations 簡稱為「vROps」。
    圖 2、透過 vCenter Server 內建工具,察看 vSAN 超融合叢集環境健康情況



    部署 vROps 環境需求

    事實上,與部署 vCenter Server 管理平台類似的概念,管理人員可以部署不同規模大小的 vROps 執行個體,以便因應不同規模大小的 vSphere 叢集和 vSAN 超融合叢集。下列為部署不同規模大小 vROps 執行個體的硬體資源需求:
    • 超小型(Extra Small):需要 2 vCPU 和 8 GB vRAM 硬體資源,最多支援 350 個物件和 100 個客戶端代理程式。
    • 小型(Small):需要 4 vCPU 和 16 GB vRAM 硬體資源,最多支援 6,000 個物件和 300 個客戶端代理程式。
    • 中型(Medium):需要 8 vCPU 和 32 GB vRAM 硬體資源,最多支援 68,000 個物件和 1,200 個客戶端代理程式。
    • 大型(Large): 需要 16 vCPU 和 48 GB vRAM 硬體資源,最多支援 200,000 個物件和 2,500 個客戶端代理程式。
    • 超大型(Extra Large): 需要 24 vCPU 和 128 GB vRAM 硬體資源,最多支援 320,000 個物件和 2,500 個客戶端代理程式。
    有關不同規模大小 vROps 硬體資源需求,以及各項支援數據的詳細資訊,請參考 VMware KB 2093783KB 82344知識庫文章內容。

    同時,在部署 vROps 之前建議先了解整體的基本運作架構,以及各項運作元件之間所使用的通訊協定,和使用的連線通訊埠(如圖 3 所示),避免屆時部署完成後因為防火牆未允許相關協定和連線通訊埠,造成相關運作元件之間無法通訊導致錯誤,或發生未預期的錯誤情況而無法順利運作。

    圖 3、vROps 各項運作元件通訊協定和連線通訊埠示意圖



    vCenter Server 中的 vROps 儀表板

    事實上,在過去 vROps 版本中,管理人員必須離開 vCenter Server 管理平台,額外登入 vROps 專屬的管理介面,並且順利通過使用者身份驗證機制之後,才能夠登入 vROps 查看各項效能監控數據和工作負載情況。

    現在,由於新版 vCenter Server 管理介面,已經全面支援採用 Clarity Framework 打造的 HTML 5 管理介面,所以 VMware 官方也針對管理人員經常需要監控的 vSphere 和 vSAN 叢集,將 vROps 輕量級儀表板功能,直接下放至 vCenter Server 管理介面中(如圖 4 所示),幫助管理人員輕鬆查看效能數據和工作負載等健康情況。

    圖 4、vRealize Operations within vCenter 運作架構示意圖

    此時,管理人員應該會有疑問,倘若在 vCenter Server 管理介面中,能夠透過 vROps 輕量級儀表板,直接看到 vSphere 和 vSAN 叢集的工作負載和健康情況。那麼,還需要購買完整功能的 vROps 軟體授權嗎? 這兩者之間有何不同?

    簡單來說,vROps 輕量級儀表板和完整功能的 vROps,這兩者之間最大的差別在於,vRealize Operations within vCenter 只提供「六個」輕量級儀表板,並且這些儀表板僅提供「深入解析」(Insights),而不會提供任何「執行」(Actions)的操作,例如,故障排除和修復……等(如圖 5 所示)。
    企業和組織必須採用完整版本的 vRealize Operations,例如,vRealize Operations Advanced 或 Enterprise 版本,才能支援「執行」(Actions)的操作。
    圖 5、簡介 vRealize Operations within vCenter

    現在,管理人員應該對於如何購買適當的 vROps 軟體授權感到好奇。那麼,針對下列常見的應用情境進行說明以便讀者理解:
    • 購買 vRealize Operations 軟體授權:無論購買哪種版本的 vROps(Standard,Advanced,Enterprise 或 vCloud Suite)軟體授權,都可以直接使用 vRealize Operations within vCenter 輕量級儀表板。值得注意的是,在六個輕量級儀表板中有三個是針對 vSAN 叢集所設計,所以環境中倘若沒有 vSAN 超融合叢集環境時,相關儀表板將不會顯示任何數據資訊。
    • 購買 vSAN 軟體授權:僅購買 vSAN Advanced 和 Enterprise 軟體授權,在初期 vROps 部署作業完成後,享有「60 天」使用 vROps 完整功能的權限,經過 60 天試用期後可選擇額外購買 vROps 軟體授權,或僅使用 vRealize Operations within vCenter 輕量級儀表板(如圖 6 所示),但僅支援深入解析而不支援任何執行操作。
    • 同時購買 vROps + vSAN 軟體授權: 購買 vROps Standard + vSAN 軟體授權時,僅額外支援「1 個」針對 vSAN 叢集的進階儀表板。購買 vROps Advanced/Enterprise + vSAN 軟體授權時,則額外支援「4 個」針對 vSAN 叢集的進階儀表板。
    圖 6、vRealize Operations within vCenter 與完整 vROps 軟體授權功能示意圖



    部署 vROps 執行個體

    登入 vCenter Server 管理介面中,依序點選「Home > vRealize Operations > Install」項目,系統便會自動彈出部署 vROps 執行個體的互動精靈視窗。在 Installation Mode 頁面中,可以選擇兩種不同部署 vROps 的方式,選擇「Online Install」項目時(如圖 7 所示),稍後 vCenter Server 將會透過 Internet 網際網路,連線至 VMware 官方自動下載 vROps 安裝印象檔。倘若,vCenter Server 無法連線至 Internet 網際網路時,管理人員必須預先至 VMware 官網下載 vROps 安裝印象檔後,選擇「Offline Install」項目,並點選剛才預先下載的 vROps 安裝印象檔即可進行部署作業。

    圖 7、採用線上安裝或離線安裝方式部署 vROps 執行個體

    在 vCenter Details 頁面時,請依序鍵入 vCenter Server 管理平台的 IP 位址,以及 vCenter Server 的管理帳號和密碼,當連線和使用者驗證資訊鍵入完畢後,請按下 TEST CONNECTION鈕,系統將依據鍵入的 vCenter Server 資訊,進行連線通訊和使用者身份驗證的動作,連線成功後系統將會回傳「Connection to vCenter Server is validated successfully.」的資訊(如圖 8 所示)。
    未成功通過 vCenter Server 使用者身份驗證機制,將無法繼續至下一個 vROps 部署流程。

    圖 8、成功通過連線通訊和使用者身份驗證至 vCenter Server 管理平台

    在 Environment Details 頁面中,請鍵入稍後即將部署 vROps 的 VM 虛擬主機名稱、選擇使用的資料中心、vSphere 叢集或 vSAN 超融合叢集、屆時運作的 ESXi 虛擬化平台、部署規模大小、Datastore 儲存區資源、vSwitch 虛擬交換器和連接的 Port Group……等(如圖 9 所示)。
    在選擇 Datastore 儲存區資源時,倘若目標 Datastore 儲存區可用空間小於「200 GB」時,系統將會出現 Datastore 儲存區資源不足的警告訊息。

    圖 9、鍵入部署 vROps 的 VM 虛擬主機名稱,並選擇採用哪些相關硬體資源

    在 Network Details 頁面中,鍵入部署 vROps 的 VM 虛擬主機網路組態設定,本文實作環境中,採用的靜態 IP 位址為「10.10.75.30」(如圖 10 所示),並且已經在運作環境中的 DNS 名稱解析伺服器內,建立「vrops.lab.weithenn.org」的 A Record 名稱解析記錄。

    圖 10、鍵入部署 vROps 的 VM 虛擬主機網路組態設定

    在 Adapter Instance Details 頁面中,倘若屆時 vROps 執行個體要取得監控數據的 vCenter Server 管理平台,和剛才步驟二中鍵入負責部署 vROps 作業的 vCenter Server 不同台時,那麼可以在此階段中,額外鍵入其它台 vCenter Server 使用者身份驗證資訊。否則,只要勾選「Monitor the same vCenter Server in Step 2」選項(如圖 11 所示),即可直接採用剛才已經成功通過的 vCenter Server 使用者身份驗證資訊,並繼續下一個 vROps 部署流程。

    圖 11、指定 vROps 執行個體要取得監控數據的 vCenter Server 管理平台

    在 Summary 頁面中,再次檢視組態設定內容,確認無誤後按下 INSTALL 鈕便立即執行部署作業,並且在 vCenter Server 管理頁面中,系統將顯示「Installation of vRealize Operations in progress !」資訊。經過一段時間下載 vROps 安裝印象檔並部署完成後,重新整理 vCenter Server 管理頁面,便能順利在 vCenter Server 管理頁面中,直接看到 vROps 輕量級儀表板(如圖 12 所示)。

    圖 12、直接在 vCenter Server 管理頁面中,看到 vROps 輕量級儀表板



    vCenter 中六個 vROps 輕量級儀表板

    現在,管理人員在 vCenter Server 管理介面中,已經可以直接看到 vROps 輕量級儀表板。預設情況下,切換至 vRealize Operations 頁面時,將會顯示六個 vROps 輕量級儀表板中的「vCenter Overview」項目。

    管理人員,可以點選右方「Quick Links」下拉式選單,便會發現六個 vROps 輕量級儀表板項目可供切換。簡單來說,儀表板有兩個大項目,分別是著重於「vCenter」和「vSAN」超融合環境,每個大項目內共有三個 vROps 輕量級儀表板,分別是「Overview、Cluster View、Alerts」(如圖 13 所示)。

    圖 13、切換不同的 vROps 輕量級儀表板項目

    那麼,我們來看看這六個 vROps 輕量級儀表板項目,如何幫助管理人員快速得知 vCenter Server 管理平台,以及 vSAN 超融合環境整體的工作負載和健康狀態。


    vCenter – Overview 儀表板

    在 vCenter Server Overview 儀表板中,管理人員可以快速且一目瞭然了解整體健康情況。首先,在 Are there any Issues 區塊中,倘若系統有任何錯誤或告警資訊都會在此呈現,並且管理人員可以點選後,了解這個錯誤或告警資訊的詳細內容以及嚴重程度。在「Are Clusters configured for HA」和「Are Clusters Workload Balanced」區塊中,可以快速看到 vSphere 叢集,是否已經啟用 HA 高可用性機制和 DRS 負載平衡特色功能。

    上述這幾個項目,雖然管理人員可以在傳統 vCenter Server 管理介面中查詢得知,但是必須個別項目逐一查看和確認才行,長期累積下來無形間也浪費不少時間。此外,在這個儀表板中有二個項目,是傳統 vCenter Server 管理介面無法得知的,一個是「What is Operating System distribution ?」,直接將 vCenter Server 管理平台中,所有 VM 虛擬主機中作業系統的類型進行統計和分類。另一個是「What can be Reclaimed ?」,提醒管理人員在 vSphere 叢集中,有多少的硬體資源其實是閒置且無謂浪費的,管理人員應該想辦法回收這些閒置的寶貴資源,達到節省費用的目的(如圖 14 所示)。
    管理人員可以快速回覆主管,通過回收這些閒置的寶貴硬體資源,可為公司節省多少有形的 IT 預算開支。

    圖 14、vCenter Server Overview 儀表板


    vCenter – Cluster View 儀表板

    在 vCenter Cluster View 儀表板中,與剛才 vCenter Server Overview 儀表板類似,但是整體資訊會著重在「vSphere 叢集」的部份。倘若,vCenter Server 管理多個 vSphere 叢集時,可以點選「CHANGE CLUSTER」切換至不同的 vSphere 叢集。

    同樣的,系統在儀表板中提醒管理人員在 vSphere 叢集中,有多少硬體資源是被閒置可進行回收的部份,特別的是在「Time remaining before Capacity runs out」項目中,將依據目前 vSphere 叢集總體硬體資源,以及各項工作負載的成長趨勢進行分析和判斷後,提醒管理人員各項硬體資源仍可以支應多久的時間,有效幫助管理人員在來年 IT 預算的評估判斷和採購計畫(如圖 15 所示)。
    請注意,管理人員應該隨時查看評估結果,因為 vROps 每隔一段時間,便會將工作負載的成長趨勢和總體硬體資源進行開銷估算,所以評估結果將會隨時變動。
    圖 15、vCenter Cluster View 儀表板


    vCenter – Alerts 儀表板

    在 vCenter Server Alerts 儀表板中,直接條列所有的告警資訊,並且依照嚴重程度和顏色進行排序,例如,最嚴重的 Critical 層級便採用最顯眼的紅色。當管理人員要查看和條列不同嚴重程度的告警資訊時,只要點選該層級項目即可。同時,預設情況下,將會直接顯示「Warning」層級的告警資訊。

    因此,當管理人員在時間有限的情況下,可以優先挑選需要被立即解決的問題,例如,點選 Critical 或 Immediate 層級,然後閱讀系統提供的告警資訊後進行故障排除作業,在告警資訊欄位中「Triggered On」項目(如圖 16 所示),便是在 vSphere 叢集中發生問題的 VM 虛擬主機名稱,至於每項告警資訊欄位最後的「Open in vRealize Operations」連結圖示,則會另開新視窗至 vRealize Operations Manager 登入頁面,提供更進一步的問題分析和故障排除建議及補救措施。

    圖 16、vCenter Server Alerts 儀表板


    vSAN – Overview 儀表板

    在 vSAN Overview 儀表板中,與 vCenter Server Overview 儀表板非常類似,但著重在 vSAN 超融合環境的相關資訊中,包括,Disk IOPs 和 Disk Throughput 儲存效能表現,以及是否啟用進階特色功能,例如,Compression 壓縮技術。
    倘若,vCenter Server 所管理的環境中,並沒有 vSAN 超融合叢集時,那麼 vSAN 項目的三個儀表板便不會顯示相關分析和統計數據。

    過去,在傳統的 vCenter Server 管理介面中,管理人員很難查詢到「vSAN 元件」(vSAN Component)數量的總體使用情況,舉例來說,新版的 vSAN 環境可以透過 Skyline Health 機制逐一查看,舊版的 vSAN 環境則無法在 vCenter Server 管理介面中查看到,必須 SSH 連線至每一台 vSAN 叢集節點主機中,透過指令「esxcli vsan debug limit get」才能查詢 vSAN 元件的使用數量。

    現在,在 vSAN Overview 儀表板中,直接在「What is the Component Limit ?」區塊中,顯示 vSAN 元件數量的使用情況。在本文實作環境中,可以看到在 vSAN 超融合叢集中,共有六台 vSAN 叢集節點主機,每台主機最多支援「9,000」個 vSAN 元件,所以此 vSAN 超融合叢集最多支援「54,000」個 vSAN 元件,目前已經使用「9,512」個 vSAN 元件,剩餘「44,488」個 vSAN 元件(如圖 17 所示)。
    有關 vSAN 元件的相關詳細資訊,請參考 VMware KB 2146130KB 2108912KB 67712知識庫文章內容。

    圖 17、vSAN Overview 儀表板


    vSAN – Cluster View 儀表板

    在 vSAN Cluster View 儀表板中,提供與 vSAN Overview 儀表板類似的資訊,但是整體更著重在 vSAN 超融合叢集的層面,舉例來說,在「What is remaining Capacity ?」區塊中,提供 vSAN 超融合叢集儲存資源空間的使用情況。同樣的,當 vCenter Server 管理多個 vSAN 超融合叢集時,可以點選「CHANGE CLUSTER」切換至不同的 vSAN 超融合叢集。

    在 vSAN 超融合叢集儲存效能的部份,除了原有的 Disk IOPs 和 Disk Throughput 之外,更增加「磁碟延遲時間」(Disk Latency),和「讀取寫入延遲時間」(Read Latency / Write Latency)圖表(如圖 18 所示),除了方便管理人員了解工作負載情況之外,更可以判斷企業和組織內營運服務的資料讀寫趨勢,方便日後選擇相關解決方案時進行最佳化,舉例來說,倘若發現讀取延遲時間增加造成營運服務回應變慢時,便可以考慮導入資料「讀取快取」(Read Cache)機制,讓資料讀取延遲時間降低提升營運服務回應速度。

    圖 18、vSAN Cluste View 儀表板


    vSAN – Alerts 儀表板

    在 vSAN Alerts 儀表板中,與 vCenter Server Alerts 儀表板相同功能,直接條列所有的告警資訊並依照嚴重程度和顏色排序(如圖 19 所示)。同時,點選「Open in vRealize Operations」連結圖示,另開新視窗至 vRealize Operations Manager 登入頁面,提供更進一步的問題分析和故障排除建議及補救措施。
    vRealize Operations Manager 登入頁面,在預設情況下,管理帳號為「admin」管理密碼為「Vmware@123」。

    圖 19、vSAN Alerts 儀表板



    完整功能的 vRealize Operations Manager

    管理人員應該已經察覺到,vROps 輕量級儀表板能提供「深入解析」(Insights),而無法提供更進階的操作,舉例來說,在完整功能的 vRealize Operations Manager 儀表板中,已經內建更深入解析的「Heavy Hitter VMs」儀表板(如圖 20 所示),管理人員可以從儀表板中得知,哪些 VM 虛擬主機在使用 CPU 和 Memory 運算資源非常吃重,哪些 VM 虛擬主機使用過多的 IOPS 儲存資源,哪些 VM 虛擬主機使用過量的 Network 網路資源。

    圖 20、Heavy Hitter VMs 儀表板

    除了故障排除建議和抓取耗損硬體資源的 VM 虛擬主機之外,完整功能的 vRealize Operations Manager,還提供工作負載效能最佳化的各項建議,幫助管理人員無須尋找和閱讀大量效能最佳化文件,便可以輕鬆得到 VMware 官方的各項最佳化建議(如圖 21 所示)。

    圖 21、vRealize Operations Manager 提供工作負載效能最佳化的各項建議





    結語

    透過本文的深入剖析和實作演練後,管理人員已經了解完整功能 vRealize Operations Manager,和 vROps 輕量級儀表板兩者之間的差異。因此,即便企業和組織僅有 vSAN 超融合叢集環境和軟體授權的情況下,也能透過 vROps 輕量級儀表板的各項分析和統計數據,有效管理 vSAN 超融合叢集環境。

    [站長開講] VMware vCenter Server HA 高可用性實戰班 (全新 vSphere 7 課程)

    $
    0
    0

     



    課程日期

    日期: 2021 年 8 月 14 日 ~ 8 月 15 日
    時間: 09:00 ~ 17:00
    地點: 台北資策會 (台北市復興南路一段 390 號 3 樓)
    報名: 資策會課程 - VMware vCenter Server HA高可用性實戰班



    課程大綱

    vCenter Server HA 高可用性架構規劃

    • vCenter Server HA 運作架構
    • Active / Passive / Witness 角色
    • vCenter Server HA 軟硬體需求
    • vCenter Server HA 部署模式
    • vCenter Server HA 虛擬網路流量規劃
    • vCenter Server HA 最佳建議作法

    建構 vCenter Server HA 高可用性實作環境

    • Nested VMs / vSphere in a box

    組態設定 vCenter Server HA 虛擬網路

    • 管理網路(Management Network)
    • vCenter 高可用性網路(vCenter HA Network)

    建置 vCenter Server HA 高可用性環境

    • 部署第一台 vCenter Server(Active Node)
    • 建立 vCenter HA Passive Node 和 Witness Node
    • vCenter Server HA 容錯移轉

    vCenter Server HA 維運管理

    • 容錯移轉類型(Automatic / Manual)
    • vCenter Server HA 維護模式(Maintenance Mode)
    • vCenter Server HA 重新啟動
    • vCenter Server HA 備份和還原
    • 調整 vCenter Server HA 規模大小

    網管人 185 期 - 實戰巢狀式虛擬化,打造容器高規隔離保護

    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    在過去的微軟 Hyper-V 虛擬化平台中,一直遲遲未支援深受管理人員喜愛的巢狀式虛擬化技術。直到 Windows Server 2016 版本時,微軟的 Hyper-V 虛擬化平台便開始內建支援「巢狀式虛擬化」(Nested Virtualization)運作環境,除了方便管理人員建構研發和測試環境之外,更重要的是將巢狀式虛擬化和 Windows「容器」(Container)技術進行整合。
    在過去的 Windows Server 版本中,非常難以實作出巢狀式虛擬化環境,即便實作成功後微軟官方也不支援該運作環境。

    在典型的 Linux 容器運作環境中,在 Linux 主機上層運作的容器透過命名空間、資源控制和執行程序隔離的方式,讓多種不同服務的容器同時運作在同一台 Linux 主機上,並且上層運作的容器和底層的 Linux 主機共用相同的系統核心。在 Windows 容器技術中,採用隔離模式為「執行程序」(Process)時,便是和典型的 Linux 容器環境大致相同(如圖 1 所示)。

    圖 1、採用執行程序隔離模式的 Windows Server Container 運作架構示意圖

    雖然,採取執行程序隔離模式時具有一定強度的安全性,然而對於強度高度安全性和完全隔離需求的企業和組織來說可能不足。因此,微軟透過巢狀式虛擬化搭配 Windows 容器技術,發展出相容性更佳且高度安全性的「Windows Hyper-V Container」技術(如圖 2 所示)。簡單來說,採用隔離模式為「Hyper-V」的容器,將會運作在微軟高度客製化和組態最佳化的特殊 VM 虛擬主機中,每個容器皆可以安全且完整的使用 VM 虛擬主機核心,充分為不同的容器之間提供硬體層級的隔離機制。

    圖 2、Windows Hyper-V Container 運作架構示意圖





    巢狀式虛擬化環境需求

    在開始實作巢狀式虛擬化技術之前,管理人員必須先確保運作環境滿足相關條件,後續才能順利在 Hyper-V 虛擬化平台中,為運作的 VM 虛擬主機啟用巢狀式虛擬化技術。

    首先,在 Hyper-V 虛擬化平台的硬體伺服器方面,必須採用支援「Intel VT-x 和 EPT」硬體輔助虛擬化技術的 CPU 處理器,並且 Hyper-V 虛擬化平台的伺服器版本,至少要採用「Windows Server 2016」或後續版本,建立的 VM 虛擬主機組態設定版本必須為「8.0」或後續版本。
    採用 AMD Ryzen/EPYC 處理器的硬體伺服器,必須採用 Windows OS build number「19636」或後續版本,並且採用「9.3」VM 虛擬主機組態版本,才能支援啟用巢狀式虛擬化技術。有關 AMD CPU 處理器支援巢狀式虛擬化的詳細資訊,請參考微軟官方說明 Microsoft Tech Community - AMD Nested Virtualization Support
    值得注意的是,啟用巢狀式虛擬化技術後的第二層 VM 虛擬主機,在 vNetwork 虛擬網路組態設定方面,與一般正常的第一層 VM 虛擬主機有所不同。目前,Hyper-V 虛擬化平台支援兩種不同的作法,分別是「MAC 位址欺騙」(MAC Address Spoofing)「網路位址轉譯」(Network Address Translation,NAT)

    當管理人員能夠碰觸和管理 Hyper-V 虛擬化平台時,例如,企業和組織在內部資料中心內,建立的 Hyper-V 虛擬化平台便建議採用 MAC 位址欺騙方式(如圖 3 所示),讓第二層 VM 虛擬主機的網路封包,能夠在 vSwitch 虛擬交換器進行路由。當管理人員無法碰觸 Hyper-V 虛擬化平台時,例如,公有雲環境,建議採用 NAT 網路位址轉譯的方式,在第一層 VM 虛擬主機中建立 NAT vSwitch 虛擬交換器,幫助第二層 VM 虛擬主機的網路封包進行路由。

    圖 3、啟用 MAC 位址欺騙機制,以便啟用巢狀式虛擬化的 VM 虛擬主機網路封包能夠進行路由

    此外,建議第二層 VM 虛擬主機應「停用」動態記憶體功能。因為,第二層 VM 虛擬主機即便啟用動態記憶體功能,除了記憶體空間不會動態調整和變動之外,管理人員在第二層 VM 虛擬主機運作時,倘若嘗試調整記憶體空間大小時將會遭遇失敗,必須將第二層 VM 虛擬主機關機後才能調整記憶體空間大小。





    巢狀式虛擬化運作架構

    在過去 Hyper-V 虛擬化平台尚未支援巢狀式虛擬化技術時,一旦硬體伺服器安裝並啟用 Hyper-V 虛擬化功能後,Hyper-V 虛擬化平台中的 Hypervisor 虛擬化管理程序,將會完全掌控底層硬體伺服器的「虛擬化擴充功能」(Virtualization Extensions),並且防止其它軟體和上層 VM 虛擬主機內的客體作業系統使用,所以管理人員便無法在第一層主機的作業系統中,安裝和啟用 Hyper-V 虛擬化功能(如圖 4 所示)。

    圖 4、舊版 Hyper-V 虛擬化平台不支援巢狀式虛擬化

    現在,只要採用 Windows Server 2016 或後續版本,安裝並啟用 Hyper-V 虛擬化功能後,Hyper-V Hypervisor 虛擬化管理程序,便支援向上層 VM 虛擬主機公開並傳遞底層硬體輔助虛擬化技術。所以,第一層的 VM 虛擬主機內的客體作業系統,便能順利感知底層公開並傳遞而來的硬體輔助虛擬化技術,進而安裝和啟用 Hyper-V 虛擬化功能並建立第二層 VM 虛擬主機(如圖 5 所示),達成巢狀式虛擬化運作架構,也就是 VM 虛擬主機內可以再產生 VM 虛擬主機。
    事實上,當 VM 虛擬主機採用 Windows 10 年度更新版本時,如同 Windows Server 2016 版本一樣,支援接收底層傳遞的硬體輔助虛擬化技術,達成巢狀式虛擬化運作架構。
    圖 5、新版 Hyper-V 虛擬化平台完全支援巢狀式虛擬化





    實戰 – Azure VM 啟用巢狀式虛擬化

    在過去,企業和組織通常僅在內部資料中心內,組態設定和啟用 Hyper-V 虛擬化平台支援巢狀式虛擬化,然而從 Microsoft Build 2017 年大會中,微軟官方便正式宣佈 Azure 公有雲環境,新增「Dv3 和 Ev3」規模的 VM 虛擬主機,簡單來說這兩種新增的 VM 虛擬主機規模,支援啟用巢狀式虛擬化技術(如圖 6 所示)。

    圖 6、Azure VM 虛擬主機支援巢狀式虛擬化運作架構示意圖

    因此,管理人員即便在地端資料中心內,沒有額外的硬體資源情況下,無須準備任何硬體伺服器和網路交換器,也能透過建立 Azure VM 虛擬主機並啟用巢狀式虛擬化技術,輕鬆建構研發和測試環境,例如,建構 Azure Stack HCI、AKS on Azure Stack HCI……等,HCI 超融合叢集和 Kubernetes 叢集運作環境。



    建立 Dv3 或 Ev3 的 Azure VM 虛擬主機

    在本文實作環境中,建立一台「Standard D16s v3」(16 vCPU、64 GB vRAM)規模的 VM 虛擬主機,採用的客體作業系統為「Windows Server 2019 Datacenter」版本,在這樣的 VM 虛擬主機規模環境下,每小時大約花費新台幣「23 元」(如圖 7 所示)。

    圖 7、部署 Standard D16s v3 規模的 VM 虛擬主機

    此外,我們額外建立一台「Standard A8 v2」(8 vCPU、16 GB vRAM)規模的 VM 虛擬主機,同樣採用「Windows Server 2019 Datacenter」客體作業系統版本,以便稍後與 Standard D16s v3 規模 VM 虛擬主機進行對照了解差異。



    啟用巢狀式虛擬化技術

    首先,登入不支援巢狀式虛擬化技術的 Standard A8 v2 規模 VM 虛擬主機,雖然採用支援巢狀式虛擬化技術的 Windows Server 2019 客體作業系統,然而在嘗試安裝 Hyper-V 伺服器角色時,便會發現系統在檢查程序執行完畢後,便會出現「The processor does not have required virtualization capabilities」的錯誤訊息(如圖 8 所示)。

    圖 8、無法順利安裝和啟用 Hyper-V 伺服器角色

    此時,管理人員可以透過 Coreinfo工具,檢查主機 CPU 處理器的各項指令集和硬體輔助虛擬化支援情況,此工具下載完畢並解壓縮之後,無須執行安裝程序即可直接在命令提示字元視窗中執行,請鍵入「coreinfo64.exe -v」指令,立即檢查在 Standard A8 v2 規模的 VM 虛擬主機中,CPU 處理器型號,以及是否擁有 Intel VT-x 及 EPT 硬體輔助虛擬化功能,從檢查結果中可以看到,Standard A8 v2 規模 VM 虛擬主機,並沒有獲得底層 Hyper-V 虛擬化平台傳遞的硬體輔助虛擬化功能,因此才會導致安裝和啟用 Hyper-V 伺服器角色時失敗(如圖 9 所示)。

    圖 9、Standard A8 v2 規模 VM 虛擬主機,沒有支援相關硬體輔助虛擬化功能

    同樣的情況,透過 Coreinfo工具檢查 Standard D16s v3 規模的 VM 虛擬主機時,從檢查結果中可以看到,Standard D16s v3 規模的 VM 虛擬主機,確實獲得底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化功能(如圖 10 所示),因此管理人員可以放心安裝和啟用 Hyper-V 伺服器角色。

    圖 10、Standard D16s v3 規模 VM 虛擬主機,獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能



    建立 NAT vSwitch 虛擬交換器

    在前述「巢狀式虛擬化環境需求」小節中已經說明,由於在 Azure 公有雲環境中,管理人員無法碰觸到 Azure 公有雲基礎架構中底層的 Hyper-V 虛擬化平台。因此,必須建立 NAT vSwitch 虛擬交換器,以便稍後建立的第二層 VM 虛擬主機,能夠透過這個第一層 Hypervisor 虛擬化管理程序,所建立的 NAT vSwitch 虛擬交換器進行網路封包的路由。

    在本文實作環境中,建立的 NAT vSwitch 虛擬交換器名稱為「NestedVM-NATSwitch」,屆時負責進行網路位址轉譯處理的 IP 網段為「10.10.75.0/24」,並且第二層 VM 虛擬主機指向的預設閘道 IP 位址為「10.10.75.1」。

    請在順利安裝和啟用 Hyper-V 伺服器角色的 Azure VM 虛擬主機中,開啟 PowerShell 指令視窗並鍵入「New-VMSwitch -Name "NestedVM-NATSwitch" -SwitchType Internal」指令,以便建立給屆時第二層 VM 虛擬主機使用的 NAT vSwitch 虛擬交換器。

    接著,執行「New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet(NestedVM-NATSwitch)"」指令,建立第二層 VM 虛擬主機使用的預設閘道 IP 位址「10.10.75.1」。最後,執行「New-NetNat -Name " NestedVM-NATSwitch" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"」,指定 NAT 網路位址轉譯處理的 IP 網段為「10.10.75.0/24」。

    上述建立 NAT vSwitch 虛擬交換器的動作完成後,分別執行「Get-VMSwitch」、「Get-NetIPAddress -IPAddress 10.10.75.1」、「Get-NetNat」指令,確認剛才組態設定內容是否正確無誤(如圖 11 所示)。

    圖 11、檢查 NAT vSwitch 虛擬交換器組態設定內容



    建立第二層 VM 虛擬主機

    在前述「巢狀式虛擬化環境需求」小節中已經說明,管理人員必須確認 Hyper-V 虛擬化平台中,稍後建立的第二層 VM 虛擬主機組態設定版本支援「8.0」或後續版本,屆時才能順利為第二層 VM 虛擬主機啟用巢狀式虛擬化功能。

    在本文實作環境中,Hyper-V 虛擬化平台為 Windows Server 2019 版本,請在 PowerShell 指令視窗中執行「Get-VMHostSupportedVersion」指令,確認目前 Hyper-V 虛擬化平台支援哪些 VM 虛擬主機組態設定版本,再次執行並加上參數「-Default」,查詢預設建立 VM 虛擬主機時採用哪個 VM 虛擬主機組態設定版本,在本文實作環境中將會採用最新的「9.0」VM 虛擬主機組態設定版本(如圖 12 所示)。
    有關 VM 虛擬主機組態設定版本的詳細資訊,例如,必須採用 5.0 組態設定版本,才能支援 Windows Server 2012 R2 客體作業系統……等,請參考 Microsoft Docs – Supported Virtual Machine Configuration versions文章內容。
    圖 12、查詢 Hyper-V 虛擬化平台支援的 VM 虛擬主機組態設定版本

    接著,透過 Hyper-V 管理員工具建立第二層 VM 虛擬主機,值得注意的是在「巢狀式虛擬化環境需求」小節中已經強調過,請勿為第二層 VM 虛擬主機啟用動態記憶體功能,倘若建立 VM 虛擬主機的過程中不慎啟用,那麼可以在建立 VM 虛擬主機後組態設定視窗中進行取消。此外,在第二層 VM 虛擬主機虛擬網路卡的部份,連接至剛才建立的「NestedVM-NATSwitch」NAT vSwitch 虛擬交換器(如圖 13 所示),並且之後採用「10.10.75.0/24」的 IP 位址,並將預設閘道指向至「10.10.75.1」,那麼第二層 VM 虛擬主機的網路封包便能順利路由,也就是可以順利接觸網際網路。

    圖 13、第二層 VM 虛擬主機,停用動態記憶體功能並連接至 NAT vSwitch 虛擬交換器

    在為第二層 VM 虛擬主機開機並安裝客體作業系統之前,還必須為第二層 VM 虛擬主機的 vCPU 處理器,執行啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能的動作,屆時第二層 VM 虛擬主機才能正確接收到,由底層 Hyper-V 虛擬化平台所公開和傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。

    請在 PowerShell 指令視窗中執行「Set-VMProcessor -VMName Level2-VM -ExposeVIrtualizationExtensions $true」指令,為名稱為「Level2-VM」的第二層 VM 虛擬主機,啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能的動作,順利啟用後請再次確認,「ExposeVirtualizationExtensions」欄位值是否為「True」確保啟用的工作任務已套用生效(如圖 14 所示)。
    請注意,第二層 VM 虛擬主機必須在「關機」(Power Off)狀態,才能啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能,倘若處於「開機」(Power On)狀態時指令執行將會遭遇失敗。
    圖 14、為第二層 VM 虛擬主機啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能

    順利為第二層 VM 虛擬主機安裝客體作業系統後,管理人員同樣可以透過 Coreinfo工具,檢查第二層 VM 虛擬主機,是否獲得底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化功能。同樣的,從檢查結果中可以看到,第二層 VM 虛擬主機確實獲得底層 Hyper-V 虛擬化平台,向上傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化功能(如圖 15 所示),當然管理人員也能為第二層 VM 虛擬主機,順利安裝和啟用 Hyper-V 伺服器角色。

    圖 15、第二層 VM 虛擬主機順利獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能



    建立第三層 VM 虛擬主機

    至此,我們已經從一開始建立 Azure VM 虛擬主機(擔任第一層 VM 虛擬主機的角色),進而為第二層 VM 虛擬主機啟用巢狀式虛擬化技術,讓管理人員只需要一台 Azure VM 虛擬主機,即可透過巢狀式虛擬化技術,產生許多第二層 VM 虛擬主機,建構企業和組織需要的研發和測試環境。

    或許,有管理人員可能有這種想法,既然第二層 VM 虛擬主機已經獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能,那麼是否能建立第三層或第四層甚至第五層 VM 虛擬主機呢? 答案是肯定的,只要第三層、第四層、第五層的 VM 虛擬主機,能夠滿足巢狀式虛擬化環境需求,那麼便可以達到 VM 虛擬主機再產生 VM 虛擬主機的目標。
    請注意,雖然底層的硬體輔助虛擬化功能可以層層傳遞上去,但是每多出一層 Hyper-V 虛擬化層級時,整體的儲存效能便會下降,所以越上層的 VM 虛擬主機儲存效能將會越發低落。
    如圖 16 所示,名稱為「NestedVM-Level1」的第一層 VM 虛擬主機,為一開始建立的 Azure VM 虛擬主機,而名稱為「Level2-VM」則是啟用巢狀式虛擬化的第二層 VM 虛擬主機,名稱為「Level3-VM」的 VM 虛擬主機,則是由第二層 VM 虛擬主機在啟用巢狀式虛擬化技術後,再產生的第三層 VM 虛擬主機。

    圖 16、在 Azure VM 虛擬主機中透過巢狀式虛擬化,建立第三層 VM 虛擬主機

    事實上,可以看到第三層 VM 虛擬主機,仍然正確獲得底層傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化功能,所以可以再建立「第四層」VM 虛擬主機,甚至再建立「第五層」VM 虛擬主機,這部份就留給有興趣的管理人員繼續實作下去吧。



    建構 HCI 超融合與 K8s 容器環境

    在現代化敏捷基礎架構的浪潮下,企業和組織建構 HCI 超融合叢集和 Kubernetes 容器叢集環境的需求不斷升高。然而,管理人員在眾多廠商推出的產品中,又該如何簡單的搭建 PoC 概念性驗證環境,確保選擇的解決方案符合公司的需求並且能夠解決遭遇的痛點。

    舉例來說,管理人員希望搭建微軟 Azure Stack HCI 超融合叢集運作環境,在最小雙節點的運作架構中,除了至少需要準備二台通過驗證並支援 Azure Stack HCI 的硬體伺服器之外,每台硬體伺服器至少要配置 2 顆 SSD 固態硬碟、4 顆 HDD 機械式硬體、1 張 10GbE 網路卡,此外也必須準備至少 1 台 10GbE 網路交換器和 10GbE 線材,才能夠建構 Azure Stack HCI 超融合叢集運作環境。

    在一般情況下,企業和組織要擁有對應的硬體伺服器和相關零組件配置相對困難。此時,管理人員便可以透過巢狀式虛擬化技術,在地端資料中心內以一台硬體伺服器,建立多台第二層 VM 虛擬主機並啟用巢狀式虛擬化機制,進而搭建 Azure Stack HCI 超融合叢集運作環境。
    有關搭建 Azure Stack HCI 超融合叢集環境的詳細作法,請參考本刊「 第 181 期 - 微軟超融合雲端作業系統 Azure Stack HCI 開箱」技術專欄內容即可。

    倘若,企業和組織在地端資料中心內,沒有多餘並且符合巢狀式虛擬化技術的硬體伺服器時,更可以直接在 Azure 公有雲環境中,選擇支援巢狀式虛擬化技術的 Azure VM 虛擬主機,輕鬆搭建 Azure Stack HCI 超融合叢集環境,甚至是 AKS on Azure Stack HCI 的 Kubernetes 容器叢集環境。
    有關搭建 AKS on Azure Stack HCI 容器叢集環境的詳細作法,請參考本刊「第 183 期 - AKS on Azure Stack HCI 實戰部署」技術專欄內容即可。





    結語

    透過本文的深入剖析及實戰演練,相信管理人員已經了解 Hyper-V 虛擬化平台中,內建支援的巢狀式虛擬化技術所帶來的強大功能,不僅能夠提供容器更高的隔離安全性,同時在企業和組織內部資料中心硬體資源不足時,借助 Auzre 公有雲環境輕鬆建構研發和測試環境。

    Photon 3 執行 tdnf repolist 總是錯誤 ?

    $
    0
    0


    前言

    最近,有個測試需求要在環境中使用 VMware Flings - vSAN Performance Monitor,將 vSAN Performance Monitor 導入 VMware 基礎架構並完成系統開機後,發現採用的是 VMware Photon OS 3作業系統。

    簡單來說,這是 VMware 打造的 Minimal Linux Container Host 系統,相關參考資訊如下:


    Question

    順利開機後,在執行 tdnf 指令更新 Repository 時卻怎麼也無法成功執行,並出現下列錯誤訊息,嘗試各種可能的解決方式後,看來已經不是主機的網路問題或是 Proxy 設定上的問題?
    Refreshing metadata for: 'VMware Photon Linux 3.0( x86_64)'
    curl#60: Peer certificate cannot be authenticated with given CA certificates 
    Error: Failed to synchronize cache for repo 'VMware Photon Linux 3.0( x86_64)' from 'https://dl.bintray.com/vnware/photon_release_3.0_x86_64' 
    Disabling Repo: 'VMware Photon Linux 3.0( x86_64)' 
    Refreshing metadata for: 'VMware Photon Linux 3.0( x86_64) Updates' 
    curl#60: Peer certificate cannot be authenticated with given CA certificates 
    Error: Failed to synchronize cache for repo 'VMware Photon Linux 3.0( x86_64) Updates' from 'https://dl.bintray.com/vnware/photon_updates_3.0_x86_64' 
    Disabling Repo: 'VMware Photon Linux 3.0( x86_64) Updates' 
    Refreshing metadata for: 'VMware Photon Extras 3.0( x86_64) ' 
    curl#60: Peer certificate cannot be authenticated with given CA certificates 
    Error: Failed to synchronize cache for repo 'VMware Photon Extras 3.0( x86_64)' from 'https://dl.bintray.com/vnware/photon_extras_3.0_x86_64' 
    Disabling Repo: 'VMware Photon Extras 3.0( x86_64)' 
    No package photon-repos available
    Error (1011): No match ing packages




    Answer

    最後,找到了下面二篇文章解決疑惑。簡單來說,舊有的 Bintray Repository (dl.bintray.com)已經在 2020 年 11 月 25 日正式退役了,必須要將 Repository 位址改成新的 packages.vmware.com才行。
    依據 VMware KB 文章,切換到 Repository 路徑下執行指令進行更換後,後續便能順利執行 tdnf repolist、tdnf makecache、tdnf update......等指令。
    cd /etc/yum.repos.d/
    cat ./!(photon-iso.repo) | grep baseurl
    sed  -i 's/dl.bintray.com\/vmware/packages.vmware.com\/photon\/$releasever/g' photon.repo photon-updates.repo photon-extras.repo photon-debuginfo.repo
    cat ./!(photon-iso.rpo) | grep baseurl 



    Viewing all 591 articles
    Browse latest View live


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