網管人雜誌

本文刊載於 網管人雜誌第 126 期 - 2016 年 7 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。


文章目錄

前言
vSphere FT 運作架構
          運算資源(Compute)
          儲存資源(Storage)
          運作狀態(Runtime State)
          網路資源(Network)
          透明容錯移轉(Transparent Failover)
          啟用 vSphere FT 技術的注意事項
          最佳作法
          vSphere FT 效能測試
實作 vSphere FT 高可用性機制
結語


前言

VMware 虛擬化平台的最新版本 VMware vSphere 6.0,已經在 2015 年 3 月時正式發行。之後,在 2015 年 9 月時推出 VMware vSphere 6.0 Update 1(簡稱 6.0 U1),此版本中主要增強功能為 VAIO、停用 SSLv3 支援、支援 VSAN 6.0 Update 1 跨地理位置之叢集運作架構。

接著,在 2015 年 10 月時推出 VMware vSphere 6.0 Update 1a(簡稱 6.0 U1a)版本,並在 2016 年 1 月時推出 VMware vSphere 6.0 Update 1b(簡稱 6.0 U1b)版本,主要為修正虛擬化平台 ESXi 與 Active Directory 之間 Kerberos 通訊,以及低延遲 VM 虛擬主機會獨佔運算核心的修正。

現在,最新的 VMware vSphere 6.0 Update 2(簡稱 6.0 U2)版本,已經於 2016 年 3 月時正式推出,此版本當中的重要增強功能及修正如下(有關 VMware ESXi 6.0 Updtae 2 重要功能及修正的詳細資訊,請參考 VMware ESXi 6.0 U2 Release Notes):

  • 高速乙太網路: 從 ESXi 6.0 U2 版本開始,ESXi 虛擬化平台支援 25 Gbps 及 50 Gbps 乙太網路。
  • VMware Host Client: 採用 HTML 5 技術的 VMware Host Client(由 VMware Labs 當中的 Embedded Host Client 演化而來),可以用於連線管理「單台」ESXi 主機,例如,建立 VM 虛擬主機、調整虛擬網路、儲存資源……等。同時,VMware 也正式宣告舊有的 vSphere C# Client 將不會在下一版本的 vSphere 中出現。
  • VMware VSAN 6.2: 最新的 VMware Virtual SAN 6.2 版本,正式與 ESXi 6.0 Update 2 版本綁定在一起。因此,當企業及組織將底層虛擬化平台升級為 ESXi 6.0 U2 版本時,便能直接建構 VMware VSAN 6.2 軟體定義儲存運作環境。
  • VAIO 支援 IPv6 網路環境: 在純 IPv6 網路環境中,ESXi 6.0 U2 運作環境中的 VAIO(vSphere APIs for I/O Filtering)已經支援 VASA Provider。同時,也正式支援 VMIOF 1.0 與 1.1 版本。
  • 停止支援 AMD 部分處理器: 目前在 vSphere 5.x 版本中,支援的 AMD Opteron 12xx、22xx、82xx 系列處理器,從 vSphere 6.0 U2 開始將不再繼續支援。
  • VCSA 外部資料庫: 在未來的主要版本中,VMware 將不支援採用 Oracle 11g 和 12g 當成 VCSA(vCenter Server Appliance)的外部資料庫。
  • 修正 VXLAN 與 Netflow 問題: 在先前版本中,於 VXLAN 網路虛擬化運作環境內啟用 Netflow 功能時,可能導致 ESXi 發生 PSOD 的問題已經解決。
  • 新版 VMware Tools: 在 ESXi 6.0 U2 版本中 VMware Tools 將採用最新的 10.0.6 版本,並解決先前版本中在 IGMP 運作環境的問題。


當企業或組織將 vSphere ESXi 虛擬化平台,升級至最新的 ESXi 6.0 U2 版本之後。倘若,vCenter Server 與 vSphere Web Client 發生故障無法使用時,管理人員只需要透過內建的 VMware Host Client 機制,開啟瀏覽器並在網址欄鍵入「https://<FQDN or IP of host>/ui」,便可以連線至單台 ESXi 主機進行管理作業,而無須依靠必須額外安裝的舊有 vSphere C# Client。

圖 1、VMware Host Client 操作示意圖 


vSphere FT 運作架構

VMware vSphere FT(Fault Tolerance)運作機制,在於能夠提供 VM 虛擬主機中運作服務或應用程式高可用性,當運作在 ESXi 虛擬化平台上的 VM 虛擬主機啟用 vSphere FT 特色功能後,當原本所運作的 ESXi 虛擬化平台發生硬體故障事件時,那麼 vSphere FT 機制將會以類似 vSphere vMotion 的遷移技術,讓身處於另一台 ESXi 虛擬化平台上的次要 VM 虛擬主機立即接手,原有 VM 虛擬主機的服務及應用程式。

簡單來說,啟用 vSphere FT 機制後的 VM 虛擬主機,將能夠在「主機層級(Host Level)」的部分達到零停機時間(Zero Downtime)、零資料遺失(Zero Data Loss)、零連線遺失(Zero Connection Loss)的目的。

事實上,vSphere FT 的運作機制,就是在 VMware vSphere Cluster 當中的 2 台 ESXi 主機內,分別運作受到 vSphere FT 機制保護的 VM 虛擬主機,稱之為「主要 VM 虛擬主機(Primary VM)」以及「次要 VM 虛擬主機(Secondary VM)」。

這 2 台啟用 vSphere FT 機制的 VM 虛擬主機,一定會運作在叢集中「不同台」ESXi 虛擬化平台上。基本上,雖然次要 VM 虛擬主機是獨立的執行個體,有自己的 VM 虛擬主機檔案(包括 VMX 組態設定檔案、VMDK 虛擬硬碟檔案……等),但是它的運作狀態以及網路識別皆與主要 VM 虛擬主機相同。

值得注意的是,倘若企業或組織採用的是舊版 vSphere 4.x5.x 虛擬化平台的話,當 VM 虛擬主機啟用 vSphere FT 機制之後,在主要及次要 VM 虛擬主機之間將透過 VMware vLockstep 技術,採用「Record-Replay」資料同步方式。

圖 2、舊版 vSphere FT(Record-Replay)運作示意圖 

在最新版本 vSphere 6.0 虛擬化平台中,vSphere FT 的資料同步機制則改採「Fast Checkpointing」方式,它的運作機制是透過 xvMotion(Cross-vCenter vMotion),透過持續執行 Checkpoints(Multiple/Sec)的動作,以達成主要及次要 VM 虛擬主機之間,例如,儲存資源、運作狀態、網路……等資料同步作業,進而達到「透明容錯移轉(Transparent Failover)」的目的。

圖 3、新版 vSphere FT(Fast Checkpointing)運作示意圖 


運算資源(Compute)

首先,針對受 vSphere FT 機制保護的 VM 虛擬主機,在運算資源的部分倘若是採用舊版 vSphere 4.x 5.x 虛擬化平台的話,那麼啟用 vSphere FT 機制的 VM 虛擬主機,便僅能配置「1 vCPU」的虛擬處理器運算資源。但是,最新版本的 vSphere 6.0 啟用 FT 功能的 VM 虛擬主機,則可以配置「1、2、4 vCPU」虛擬處理器運算資源。

請注意,必須採用 vSphere 6.0 的 Enterprise Plus 軟體授權版本才支援 4 vCPU,若採用的是 StandardEnterprise 版本的話,啟用 vSphere FT 機制的 VM 虛擬主機則最多只能支援 2 vCPU


儲存資源(Storage)

在 VM 虛擬主機的儲存資源部分,倘若採用舊版 vSphere 4.x 5.x 虛擬化平台時,那麼啟用 vSphere FT 機制的 VM 虛擬主機,除了能有任何「快照(Snapshot)」之外,虛擬磁碟也僅能使用「EZT(Eager Zeroed Thick)」格式。

但是,最新版本的 vSphere 6.0 啟用 vSphere FT 功能的 VM 虛擬主機,除了 VM 虛擬主機能夠建立快照之外,在 VMDK 虛擬磁碟的部分則支援所有磁碟格式,也就是「Thin、Thick、EZT」3 種格式都支援。

當 VM 虛擬主機啟用 vSphere FT 機制進行保護後,那麼系統便會自動在 2 台 VM 虛擬主機之間,啟用 VMware vSphere Storage vMotion 機制,針對 VMDKs 虛擬磁碟進行資料初始化及同步作業,確保主要及次要 VM 虛擬主機擁有「相同」的資料內容及磁碟狀態。

值得注意的是,協同 vSphere FT 運作的 vSphere Storage vMotion 機制,僅在下列 3 種情境時才會觸發其運作機制:

  1. 當 VM 虛擬主機啟用 vSphere FT 機制時。
  2. 當受到 vSphere FT 機制保護的主要 VM 虛擬主機,其底層的 ESXi 虛擬化平台發生故障事件。此時,服務及應用程式由次要 VM 虛擬主機接手,並且轉換身份為主要 VM 虛擬主機,同時在另外存活的 ESXi 主機上建立次要 VM 虛擬主機時。
  3. 當啟用 vSphere FT 機制的 VM 虛擬主機,其運作狀態由 Powered-Off 轉變成 Power-On 時。


當 vSphere FT 機制觸發 vSphere Storage vMotion 機制,將主要及次要 VM 虛擬主機進行資料同步作業完成後,那麼系統便會確認主要及次要 VM 虛擬主機已經受到 vSphere FT 機制保護。此外,當資料同步作業完成後,後續主要及次要 VM 虛擬主機之間的資料同步機制,將會改為採用「鏡像 VMDK 寫入(Mirror VMDK Write)」的方式,以確保兩造之間資料仍維持同步狀態。

圖 4、vSphere FT 機制保護 VM 虛擬主機服務及應用程式示意圖 

運作狀態(Runtime State)

受到 vSphere FT 機制保護的 VM 虛擬主機,首先必須確保在 vSphere Cluster 運作架構中,所有的 ESXi 主機都已經規劃專屬且高速的 FT Network(建議採用 10 Gbps 網路環境),以便 vSphere FT 運作機制能夠將主要 VM 虛擬主機的運作狀態(包括,記憶體狀態、執行程序狀態……等),透過專屬且高速的 FT Network 傳送至次要 VM 虛擬主機。

因此,當主要 VM 虛擬主機所處的底層 ESXi 主機發生故障事件時,次要 VM 虛擬主機能夠瞬間接手原有主要 VM 虛擬主機提供的所有服務及應用程式。


網路資源(Network)

在網路資源的部分,受到 vSphere FT 機制保護的 VM 虛擬主機,也會結合底層 ESXi 主機的網路虛擬化機制,以便次要 VM 虛擬主機接手原有主要 VM 虛擬主機服務或應用程式時,不會發生資料遺失或連線遺失的情況。

當 ESXi 主機發生故障事件觸發 vSphere FT 機制後,系統將會以類似 vSphere vMotion 遷移技術,除了保留主要 VM 虛擬主機的 MAC 位址之外,當次要 VM 虛擬主機接手主要 VM 虛擬主機所有服務及應用程式後,此時次要 VM 虛擬主機除了轉換角色為主要 VM 虛擬主機之外,也會發送「ARP」封包通知實體網路交換器更新 MAC 位址,讓原本使用者的網路連線能夠順利且無縫的轉移到接手的 VM 虛擬主機中。

因此,受到 vSphere FT 機制保護的 VM 虛擬主機,在發生故障事件時接手服務及應用程式的過程,並不會導致使用者資料遺失或連線中斷的情況。

圖 5、規劃專屬且高速的 vSphere FT 網路頻寬 


透明容錯移轉(Transparent Failover)

vSphere FT 與 vSphere HA 高可用性機制不同的地方在於,當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時,受到 vSphere HA 高可用性機制所保護的 VM 虛擬主機,會從 Cluster 中其它存活的 ESXi 主機上「重新啟動」,因此 VM 虛擬主機上所運作的服務或應用程式,大約會發生 2 ~ 5 分鐘的中斷時間(實務上,必須視共用儲存設備的運作效能及工作負載情況而定)。

反觀 vSphere FT 高可用性機制,因為平時主要及次要 VM 虛擬主機之間,已經透過 Fast Checkpointing 技術將 2 台主機之間進行資料同步作業。因此,當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時,雖然主要 VM 虛擬主機故障損壞無法提供服務,但是次要 VM 虛擬主機將會立即接手所有服務及應用程式,並且將角色由「次要(Secondary)」轉變成為「主要(Primary)」。

同時,在其它 ESXi 主機上再建立 1 台新的次要 VM 虛擬主機,並將目前的資料透過 vSphere Storage vMotion 機制進行資料同步,所以在 VM 虛擬主機的服務及應用程式接手期間,並沒有任何中斷時間(Zero Downtime)、資料遺失(Zero Data Loss)、連線遺失(Zero Connection Loss)等情況發生。

圖 6、vSphere FT 高可用性機制沒有任何中斷時間、資料遺失、連線遺失等情況發生 


啟用 vSphere FT 技術的注意事項

雖然,相較於 vSphere HA 來說 vSphere FT 高可用性機制提供更即時的保護,但是仍有下列限制以及注意事項必須考量:

  • 啟用 vSphere FT 機制的 VM 虛擬主機,最多僅支援至 4 vCPU64 GB Memory,這樣的 VM 虛擬主機運作規模並無法承受大型虛擬化架構的工作負載。
  • 啟用 vSphere FT 機制的 VM 虛擬主機,vCPU 及 vRAM 虛擬資源將會重置為「保留(Reservation)」狀態且無法更改,虛擬磁碟也無法增加或刪除。
  • vSphere FT 高可用性機制,主要是因應 ESXi 主機發生硬體故障事件(Host Level),而無法因應 VM 虛擬主機當中運作的服務或應用程式發生的軟體故障事件(Application Level)。
  • vSphere FT 機制無法因應主機進行更新或修復作業,所產生的停機時間。
  • 啟用 vSphere FT 機制後,除了多出 1 台次要主機增加資源消耗之外,由於 2 台主機之間會有大量且頻繁的同步資料行為,因此需要規劃專屬且高速 10 Gbps 的 VMkernel 網路環境。



最佳作法

啟用 vSphere FT 高可用性機制之後,除了 2 台 VM 虛擬主機之間會有頻繁的資料同步之外,對於 VM 虛擬主機的工作負載也會有些許的影響,透過下列所建議的最佳作法,將能有效提升 VM 虛擬主機的運作效能表現。

避免 Large Packet Loss
不管採用的是舊版 ESXi 4.x、5.x 或新版 ESXi 6.0 虛擬化平台,當 VM 虛擬主機使用 VMXNET3 虛擬網路卡時,倘若在網路頻寬發生突發性爆增網路流量時,有可能會發生大型封包遺失的情況。主要發生的原因在於,預設情況下 VMXNET3 虛擬網路卡的收送緩衝區空間較小所導致。

詳細資訊請參考 VMware KB 2039495KB 1010071

因此,建議啟用 vSphere FT 功能的 VM 虛擬主機,應該要將預設的緩衝區空間進行調整。請登入 VM 虛擬主機當中的 Windows 作業系統之後,依序點選「開始 > 控制台 > 裝置管理員 >  vmxnet3 > 內容 > 進階」後點選「Small Rx Buffers」項目,預設值為 512 請調整至最大值為「8192」。

圖 7、調整 Small Rx Buffers 至最大值 8192

接著,點選「Rx Ring #1」項目後,預設值為 1024 請調整至最大值為「4096」。

圖 8、調整 Rx Ring #1 Size 至最大值 4096


必要更新(Patch ESXi600-201504401-BG)
此外,當 VM 虛擬主機(作業系統版本 Windows XP 及後續版本),並且採用 vSphere ESXi 6.0 虛擬化平台,以及搭配最新的虛擬硬體版本 11.0。倘若,發現啟用 vSphere FT 高可用性機制後,VM 虛擬主機的工作負載明顯下降時,那麼請確認是否已經安裝 Bugfix 更新「Patch ESXi600-201504401-BG」,以避免因為未修正此臭蟲而導致運作效能降低。

值得注意的是,安裝完此 Bugfix 之後 ESXi 主機必須重新啟動才能套用生效。

詳細資訊請參考 VMware KB 2111975KB 2111976


vSphere FT 效能測試

相信許多 IT 管理人員,對於 VM 虛擬主機啟用 vSphere FT 高可用性機制後,對於 VM 虛擬主機的工作負載有多大影響應該很好奇。接下來,將針對啟用 vSphere FT 高可用性機制的 VM 虛擬主機,在運算資源(CPU)、儲存資源(Disk)、網路資源(Network)等 3 方面,分別觀察其運作效能表現。

運算效能測試 
此運算效能測試環境中,採用 Linux 核心編譯(Kernel Compile)進行測試,這是原有的 CPU 及 MMU 工作負載並且同時執行並行的執行程序,此測試工作負載將會針對磁碟進行一些資料的讀取及寫入行為,但是並不會產生網路流量。

如下圖所示,你可以看到當 VM 虛擬主機啟用 vSphere FT 機制後,雖然進行核心編譯工作負載的時間有一段差距,但是隨著 VM 虛擬主機配置的 vCPU 虛擬處理器數量增加,則之間的落差也逐漸縮小,當配置最大 4 vCPU 時差距縮小至只相差 7 秒鐘而已。

圖 9、運算效能(數值越小越佳)- VM 虛擬主機啟用及停用 vSphere FT 機制效能測試 


儲存效能測試 
在儲存效能測試的部分,採用 IOMeter 這個通用的 I/O 效能測試工具,分別採用 2 KB、64 KB 的區塊大小,針對啟用及停用 vSphere FT 機制的 VM 虛擬主機,進行儲存效能的工作負載測試。

如下圖所示,你可以看到工作負載的測試結果幾乎相差無幾,甚至某些測試條件下啟用 vSphere FT 機制的 VM 虛擬主機,在儲存效能表現上反而更佳。

圖 10、儲存效能(數值越大越佳)- VM 虛擬主機啟用及停用 vSphere FT 機制效能測試 


網路效能測試 
在網路效能測試的部分,採用 Netperf 這個通用的網路效能測試工具,分別針對 1 Gbps、10 Gbps 網路環境,啟用及停用 vSphere FT 機制的 VM 虛擬主機,進行網路效能的工作負載測試。

從測試結果中可以看到,在 1 Gbps 網路環境時工作負載的測試結果幾乎相差無幾。值得注意的是,在 10 Gbps 網路環境時開啟 vSphere FT 機制的 VM 虛擬主機,在網路封包的「接收(Receive)」部分效能表現不佳。

圖 11、1 Gbps 網路效能(數值越大越佳)- VM 虛擬主機啟用及停用 vSphere FT 機制效能測試

圖 12、10 Gbps 網路效能(數值越大越佳)- VM 虛擬主機啟用及停用 vSphere FT 機制效能測試 


實作 vSphere FT 高可用性機制

至此,相信你已經了解 vSphere FT 的運作架構、相關注意事項以及最佳作法。建議你應該再參考 VMware KB 1013428KB 1008027,以便了解啟用 vSphere FT 技術的相關 FAQ 及其它注意事項。

事實上,一切條件準備妥當後啟用 vSphere FT 高可用性機制非常簡單。首先,請先確認 Cluster 已經「啟用 vSphere HA(Turn on vSphere HA)」功能。

圖 13、確認 Cluster 啟用 vSphere HA 功能

接著,在規劃用於 vSphere FT 網路的 VMkernel Port 中,確認勾選「Fault Tolerance logging」項目,表示此 VMkernel Port 負責屆時 2 台 VM 虛擬主機之間資料同步用。

圖 14、勾選 Fault Tolerance logging 項目

然後,在 vSphere Web Client 管理介面中,點選欲啟用 vSphere FT 高可用性機制的 VM 虛擬主機,依序點選「Actions > All vCenter Actions > Fault Tolerance > Turn On Fault Tolerance」,接著選擇 VM 虛擬主機檔案要存放的 Datastore 及 ESXi Host 即可順利啟用。

當 vSphere FT 機制啟用時,此時原本的 VM 虛擬主機便會轉換成為「主要」VM 虛擬主機的角色,同時系統便會自動在剛才你所選擇的 ESXi 主機上建立「次要」VM 虛擬主機,並觸發 vSphere Storage vMotion 機制同步 2 台 VM 虛擬主機之間的資料。

由 vSphere FT 機制所觸發的 vSphere Storage vMotion 動作,將會在背景自動運作在 Recent Tasks 視窗中並不會看到此項工作任務。

當主要及次要 2 台 VM 虛擬主機完成資料同步作業後,此時主要 VM 虛擬主機圖示將由「淡藍色」轉變成為「深藍色」,並且點選該 VM 虛擬主機的「Summary」頁籤後,將會看到多出 Fault Tolerance 區塊,並且在 Fault Tolerance Status 欄位看到為「Protected」。

此時,便可以確認 vSphere FT 機制已經順利啟用,並且在此實作環境中可以看到次要 VM 虛擬主機運作在「esxi02.weithenn.org」主機上。

圖 15、VM 虛擬主機順利啟用 vSphere FT 高可用性機制


結語

透過本文的說明,相信讀者已經了解到 vSphere FT 高可用性機制,能夠在無須建置複雜的高可用性運作環境(相較之下,建構 Windows Failover Cluster 較為複雜),便能幫助企業或組織保護 VM 虛擬主機的服務及應用程式保持高可用性。

活動簡介

Community Open Camp 由微軟 MVP 以及 Docker 、Laravel 台灣、R 、Python 等社群高手,即將於 2016 年 8 月 27 日星期六於中央研究院學術活動中心及人文社會科學館,帶給您一整天的實戰經驗分享。這次將由 22 位身經百戰的專家主講最熱門的技術議題與實戰的案例分享,包括從 Ansible 到 Docker、企業導入 Docker 經驗分享、給 PHP 開發者的 Visual Studio Code 指南、用 Python + Azure 做出你的聊天機器人、DevOps In OpenSource、利用微軟 IoT 打造專屬的環控機器人、Xamarin 跨平台原生 App 開發介紹,等等精彩的課程內容不但提升自己的技術競爭力,同時掌握最新的科技趨勢,歡迎您來參加 Community Open Camp


    活動資訊




    活動內容





    活動影片及講義

    Coming Soon...

    網管人雜誌

    本文刊載於 網管人雜誌第 125 期 - 2016 年 6 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

    文章目錄

    前言
    Microsoft Azure Stack 概觀
    MAS POC 運作架構
    部署 MAS 的前置作業
    安裝 MAS TP1 混合雲平台
    登入 MAS 入口網站
    提供 IaaS 服務
    建立租用戶使用者帳號
    利用 IaaS 服務建立 VM 虛擬主機
    結語



    前言

    拜「雲端運算(Cloud Computing)」技術成熟之賜,各種產業類別不管是傳統產業或科技產業,每家企業或組織當中的商務流程,或多或少都會使用到雲端服務業者建立的服務(例如,OneDrive、Gmail……等),或者由企業或組織在內部資料中心內自行建立私有雲環境。

    根據 RightScale 最新的雲端運算發展趨勢調查結果顯示,企業或組織採用雲端運算技術的比例從 2015 年的 93 % 上升至 95 %,在自建「私有雲(Private Cloud)」的部分則是從 63 % 提升為 77 %。此外,因為「公有雲(Public Cloud)」環境的成熟,加上自建私有雲的比例不斷提升,連帶讓「混合雲(Hybrid Cloud)」的佔有比例從 58 % 大幅上升至 71 %,並且佔有比例呈現年年不斷上升的趨勢。

    圖1、2016 年雲端運算趨勢 – 混合雲佔有比例明顯上升


    Microsoft Azure Stack 概觀

    MAS(Microsoft Azure Stack),是微軟專為新世代混合雲運作架構而設計的平台。簡單來說,雖然公有雲運作環境及技術都已經成熟,然而企業或組織對於將內部的機敏資料(例如,營運報表、顧客資料及採購習性……等),存放至公有雲環境時雖然已經將機敏資料加密後才上傳,但仍覺得機敏資料並非放在內部資料中心來得安心,但是審視內部資料中心時又發現缺少公有雲等級的靈活性或擴充性。

    現在,企業或組織可以透過 Microsoft Azure Stack 混合雲平台,自行打造出如同 Microsoft Azure 公有雲的靈活性及運作規模,但是這樣的高可用性、高靈活性的平台掌控權,可以完全由企業或組織的 IT 所管控,並且在需要時能夠輕鬆與公有雲介接達成混合雲的運作架構。

    圖2、MAS 混合雲平台提供與 Azure 公有雲一致的操作體驗


    熟悉 Microsoft Azure 公有雲操作環境的 IT 管理人員,對於 Azure 入口網站(Azure Portal)應該不陌生,早期為採用 Azure Service Management 的管理模式,只要瀏覽 https://manage.windowsazure.com 網址,並於登入畫面鍵入 Azure 訂閱帳戶資訊即可登入。事實上,在 Windows Server 2012 R2 的運作環境中,企業或組織也可以輕鬆自行打造私有雲平台稱之為 Microsoft Azure Pack,其入口網站及管理模式也是採用 Azure Service Management。

    圖3、舊有的 Microsoft Azure 入口網站採用 Azure Service Management 管理模式


    從 2015 年 12 月 2 日起,微軟宣佈新版的 Azure 入口網站正式啟用,它採用新式的 ARM(Azure Resource Manager)管理模式,只要瀏覽 https://portal.azure.com 網址,並於登入畫面鍵入 Azure 訂閱帳戶資訊即可登入。當然,為了讓習慣使用舊有入口網站的 IT 管理人員,能夠慢慢過渡到新的 Azure 入口網站操作模式,所以目前同一個 Azure 訂閱帳戶能夠同時使用新舊 Azure 入口網站。

    圖4、新式的 Microsoft Azure 入口網站採用 Azure Resource Manager 管理模式

    同樣的,為了提供給 IT 管理人員一致的管理操作體驗平台,以及開發人員一致的程式碼編寫平台(只要內部編寫一次,上傳至公有雲環境中便可立即使用),屆時企業或組織所自行打造的 MAS 混合雲平台,也同樣採用 Azure Resource Manager 管理模式。

    圖5、同樣採用 Azure Resource Manager 管理模式的 Microsoft Azure Stack 入口網站


    MAS POC 運作架構

    目前,MAS 混合雲平台仍處於「技術預覽(Technical Preview)」階段,並且在 2016 年 1 月時釋出 MAS TP1(Technical Preview 1)版本。由於目前 MAS TP1 仍為 POC 概念性驗證階段,因此可以將所有功能、元件、角色以及運作環境,都部署在「1 台」實體伺服器當中進行運作。

    下列為 MAS TP1 運作架構中,相關 VM 虛擬主機所擔任的角色及功能說明:

    • ADVM: 負責整個 MAS 運作環境的基礎架構,例如,Active Directory、DNS、DHCP……等。
    • ACSVM: 負責 ACS(Azure Consistent Storage)儲存資源服務,同時將與 SQLVM 協同運作。
    • MuxVM: 負責 SLB(Software Load Balancer)與 Network Multiplexing Service 等,有關網路流量負載平衡部分的運作機制。
    • NCVM: 透過「網路控制器(Network Controller,NC)」運作元件及機制,負責整個 MAS 運作環境中 SDN 軟體定義網路的部份。
    • NATVM: 負責整個 MAS 運作環境中 NAT(Network Address Translation)機制,以便處理所有 VM 虛擬主機的「流出(Outbound)」網路流量。
    • xRPVM: 負責整個 MAS 運作環境中,所有資源如 Compute / Network / Storage 等核心資源提供者(Core Resource Provider),同時將與 SQLVM 協同運作。
    • SQLVM: 負責承載 ACS / xRP 運作角色中需要資料庫服務的部分。
    • PortalVM: 負責建立 Azure Resource Manager 管理模式,以及運作 Microsoft Azure Stack 入口網站。
    • ClientVM: 提供 PowerShell、Vistual Studio 等相關開發工具,以便 IT 管理人員及開發人員進行測試及除錯作業。
    • Storage Service: 在 MAS TP1 版本中,搭配的 Windows Server 2016 TP4 作業系統,將會提供的儲存資源服務有 CS Blob Service(Microsoft Azure Consistent Storage Blob Service)、SOFS(Scale-Out File Server)、ReFS CSV(Resilient File System Cluster Shared Volume)、Virtual Disk、Storage Space、Storage Spaces Direct。

    圖6、Microsoft Azure Stack POC 運作架構


    部署 MAS 的前置作業 

    由於目前 MAS TP1 技術預覽版本中,採用 One-Node Deployment 運作架構,也就是只要 1 台實體伺服器,便可以安裝 MAS 混合雲平台並且實作所有功能。

    原則上,只要採用通過 Windows Server 2012 R2 硬體認證的伺服器即可。那麼,讓我們來看看這台實體伺服器的詳細硬體需求:

    • CPU 處理器: 採用 2 顆 CPU 處理器,總運算核心至少應有 12 Cores,但建議配置 16 Cores 運算核心比較理想。同時,必須支援硬體輔助虛擬化技術,例如,Intel VT-x / EPT 或 AMD AMD-V / NPT。
    • 記憶體空間: 至少應具備 96 GB 記憶體空間,但建議配置 128 GB 記憶體空間較為理想。
    • BIOS: 啟用硬體輔助虛擬化技術,以支援運作 Hyper-V 虛擬化平台。
    • 網路卡: 採用通過 Windows Server 2012 R2 硬體認證的網路卡即可,無須其它特殊功能。
    • 作業系統磁碟: 可採用 「1 顆」SSD 固態硬碟或 SAS / SATA 機械式硬碟,磁碟空間大小至少應有 200 GB。
    • 資料磁碟: 至少要有 「4 顆」SSD 固態硬碟或 SAS / SATA 機械式硬碟,磁碟空間大小至少應有 140 GB 但建議為 250 GB。這些磁碟空間,屆時將存放 Azure Stack POC 運作環境中的所有資料。值得注意的是,若採用混合硬碟類型時硬碟介面的格式必須一致才行,否則屆時安裝過程將會產生錯誤,舉例來說,若採用 SATA SSD 固態硬碟的話,那麼必須搭配 SATA 機械式硬碟才行。此外,目前尚未支援採用 SATADOM 及 NVMe SSD 固態硬碟。
    • 硬碟控制器: 建議採用 Simple HBA 硬碟控制器(例如,LSI 9300-8i),若採用 RAID HBA 硬碟控制器的話,那麼必須支援 「Pass-Through Mode」,或是可以針對「每顆硬碟」建立 「RAID-0」 才行,否則屆時將因為 MAS 的 SDS 軟體定義儲存技術,無法將資料磁碟建立成儲存資源而導致安裝失敗。


    當實體伺服器符合上述硬體需求後,便可以進入安裝 MAS 混合雲平台的階段了,但是在開始部署 MAS 運作環境之前還有幾個小細節值得注意。

    首先,在作業系統方面當安裝 Windows Server 2016 DataCenter TP4 之後,必須安裝 KB 3124262 更新以進行相關修正作業,並且這台 MAS 實體主機「」需要預先加入網域環境,屆時實體主機將會加入 ADVM 所建立的 「StackAzure.local」 網域環境中。

    此外,這台 MAS 實體主機網路環境的部分,請不要使用這些網段 「192.168.100.0/24、192.168.133.0/24、192.168.200.0/24」,因為這些網段必須保留給 MAS 運作環境中,相關運作元件及角色的 VM 虛擬主機使用。同時,這台 MAS 實體主機必須可以透過 Port 80、443,存取 graph.windows.net login.windows.net 網際網路站台。

    最後,你必須建立 Microsoft Azure AD 帳戶,以便屆時在 MAS 運作環境中能夠設定,例如,Clouds、租用戶使用者帳號、Tenant Plans、Quota……等。

    圖7、建立 Microsoft Azure AD 帳戶


    安裝 MAS TP1 混合雲平台

    當安裝 MAS 運作環境的前置作業準備完畢後,便可以連結至 Microsoft Azure 官方網站,下載 Microsoft Azure Stack POC TP1 安裝檔案,並存放至已經安裝好 Windows Server 2016 TP4 的 MAS 實體主機中,例如,C:\MAS 資料夾內。

    圖8、下載 Microsoft Azure Stack POC TP1 安裝檔案

    當你解開剛才所下載的 Microsoft Azure Stack POC.exe 安裝檔案後,便會看到稍後進行部署作業的 Azure Stack POC PowerShell 指令碼檔案,以及其它相關安裝檔案。

    圖9、解開 Microsoft Azure Stack POC.exe 安裝檔案

    請以「系統管理員身分」開啟 PowerShell 執行環境,切換至部署 Azure Stack POC 的 PowerShell 指令碼路徑,鍵入指令 「.\DeployAzureStack.ps1 -verbose」,開始安裝 Azure Stack POC 運作環境。

    首先,在安裝過程中將會跳出 「Please enter the password for the built-in administrator」 訊息。此時,請鍵入 MAS 運作環境的預設管理者密碼,你必須鍵入 2 次相同的管理者密碼以便通過驗證。

    接著,將會出現 「Please sign in to your Azure account in the Microsoft Azure sign in windows」 訊息。此時,請鍵入剛才登入 Microsoft Azure 訂閱帳戶,並且建立給 MAS 運作環境使用 Microsoft Azure AD 管理者帳號及密碼,通過使用者身分驗證程序後,將會列出該 Azure 訂閱帳戶中所有的 Azure AD 資訊,請選擇要用於 MAS 運作環境的 Azure AD 即可。

    圖10、鍵入 Microsoft Azure AD 管理者帳號及密碼

    選擇好用於 MAS 運作環境的 Azure AD 之後,可以看到系統執行 「Show-WapToken.ps1」 指令碼,並且顯示 Microsoft Azure Stack POC Deployment 安裝畫面。此時,你可以開啟 Azure 入口網站並登入 Azure 訂閱帳戶,切換到用於 MAS 運作環境的 Azure AD 後,可以看到在剛才的 MAS 安裝流程當中,已經分別建立 Service AdminTenant Admin 帳戶。

    圖11、MAS 安裝流程中自動建立的 Azure AD 帳戶

    當 MAS 部署流程順利開始後,首先你會發現實體主機重新啟動,此時便是 MAS 安裝程序為實體伺服器啟用 Hyper-V 角色,並加入 MAS 運作環境中由 ADVM 所建立的 「AzureStack.local」 網域環境。接著,便會依序建立 MAS 運作環境中相關的 VM 虛擬主機,例如,ACSVM、PortalVM、SQLVM……等。

    整體 MAS POC 運作環境的部署時間,將依 MAS POC 實體伺服器的硬體資源而定,並且在部署期間將會重新啟動數次,但是每當主機重新啟動並再次登入系統後,將會繼續出現 PowerShell 部署視窗,以便了解目前 MAS 的安裝進度,一旦 MAS 部署作業完畢後,最後便會看到 「Congratulations ! Microsoft Azure Stack POC is successfully deployed」 訊息,並且關閉 PowerShell 部署視窗。

    圖12、MAS POC 運作環境即將部署完成

    倘若,你在 MAS 部署期間遭遇錯誤而無法繼續安裝程序時,你可以切換至 「C:\ProgramData\Microsoft\AzureStack\Logs」 路徑,查看日誌檔案中詳細的錯誤訊息資訊以進行故障排除作業。

    舉例來說,筆者在初次安裝時遭遇到 「POCFabricInstaller failed because the following tasks failed: CreateCSV」 錯誤,並且導致整個 MAS 安裝部署程序停止。此時,切換至日誌檔案存放路徑後,查看以 「CreateCSV」 為開頭的日誌檔案閱讀詳細的錯誤資訊。

    在此次的實作環境中,由於 MAS POC 實體伺服器配置 SATADOM 儲存媒體,但目前 MAS POC 運作環境尚未支援,因此造成 MAS 在建立 SDS 軟體定義儲存資源時,無法將 SATADOM 儲存媒體納入管理,進而發生錯誤最後導致 MAS 部署作業停止。因此,開啟裝置管理員後將 SATADOM 裝置「停用」,然後再次執行「.\DeployAzureStack.ps1 -verbose」部署指令,便順利完成 MAS 環境的部署作業。

    圖13、遭遇錯誤導致 MAS 安裝部署程序停止


    登入 MAS 入口網站

    順利安裝 MAS POC 運作環境後,將會在桌面上看到 MAS 安裝程序所建立的 RDP 遠端桌面連線圖示(ClientVM.AzureStack.local.rdp),點選執行後將採用預設「AzureStack\AzureStackUser」使用者帳號登入,在使用者密碼欄位的部分,請鍵入在 MAS 安裝流程中所鍵入的預設管理者密碼。

    順利登入 ClientVM 環境中,請點選桌面上的 Microsoft Azure Stack POC Portal 圖示,此時將會開啟 Microsoft Edge 瀏覽器,並連結至 MAS 入口網站(https://portal.azurestack.local)。由於,目前尚未建立任何 MAS 環境中的租用戶使用者帳號,因此請鍵入此 MAS 環境的 Azure AD 管理者帳號及密碼,順利通過使用者身分驗證程序後,便可以看到 Microsoft Azure Stack 入口網站。

    圖14、登入 Microsoft Azure Stack 入口網站


    提供 IaaS 服務

    與 Microsoft Azure 公有雲同樣的租用戶服務概念,MAS 運作環境的管理人員,可以針對企業或組織的內部需求,規劃出各式各樣的 IaaS 服務。在 MAS 運作環境中,可以透過 Subscription、Offer、Plan、Service 等不同項目,提供不同「租用戶(Tenant)」所需的各項 IaaS 服務:

    • Subscription: 定義租用戶可以使用哪些 Offer、Plan、Service。
    • Offer: 可以使用哪些 Plan,例如,Plan-A 為 VM 資源而 Plan-B 為 Storage 資源。
    • Plan: 組態設定 Quota 機制,以便限制租用戶能使用的資源範圍,例如,限制只能建立 2 台 VM 虛擬主機、總共只能使用 10 vCPU 虛擬處理器及 16 GB vRAM 記憶體……等。
    • Service: 定義使用的應用程式及服務資源,例如,VM、SQL Server 資料庫、SharePoint……等。

    圖15、Subscription、Offer、Plan、Service 階層關係示意圖

    順利以 MAS 管理員身份登入後,依序點選 「New > Tenant Offers and Plans」 項目,即可建立屆時給予租用戶使用的訂閱及相關服務。一般來說提供的 IaaS 服務,都會勾選 「Storage、Compute、Network」 這 3 個 Provider 項目,或者 IT 管理人員可以依內部需求進行資源項目的勾選。

    圖16、建立 Plan、Offer、Subscription 項目

    值得注意的是,預設情況下建立好的 Plan 及 Offer 項目運作狀態為 「Private」,也就是只有 MAS 管理員才能看到,而租用戶登入後並無法看到 Plan 及 Offer,請點選 「Change State」 圖示將運作狀態調整為 「Public」,那麼租用戶登入後便可以訂閱並使用該 Plan 及 Offer。此外,若將運作狀態調整為 「Decommissioned」 的話,那麼表示已經訂閱的租用戶將不受影響,但是新的租用戶則無法進行訂閱的動作。

    圖17、將 Plan 運作狀態從 Private 調整為 Public


    建立租用戶使用者帳號

    當 MAS 管理人員順利建立好租用戶訂閱方案後,便可以著手建立租用戶使用者帳號,以便驗證租用戶登入後是否能夠順利使用相關資源。請登入 Microsoft Azure 訂閱,切換至 MAS 環境的 Azure AD 當中,在新增使用者類型下拉式選單中,請選擇至「您組織中的新使用者」項目,在使用者設定檔頁面中角色下拉式選單請選擇「使用者」項目即可。在此次實作環境中,我們建立名稱為 「Chris Lee」 的租用戶使用者帳號。

    圖18、建立租用戶使用者帳號

    接著,便可以使用此租用戶使用者帳號登入 MAS 入口網站,第一次登入時系統將會要求重新設定使用者密碼,順利登入 MAS 入口網站後,租用戶便可以按下 「Get a Subscription」 圖示進行訂閱的動作,在訂閱的內容中按下 「Select an offer」 項目,就可以看到剛才 MAS 管理人員所定義的 Offer 內容,最後便完成租用戶訂閱方案的動作。

    圖19、租用戶順利完成訂閱方案的動作

    倘若租用戶登入 MAS 入口網站點選 Get a Subscription 後,卻發現看不到任何訂閱方案時,請使用 MAS 管理者帳號登入,確認相關的 Offer / Plan 的運作狀態是否為 Public,若運作狀態為 Private 則租用戶便無法進行訂閱的動作。

    利用 IaaS 服務建立 VM 虛擬主機

    當租用戶順利完成訂閱方案的動作後,便可以馬上使用 IaaS 服務來建立 VM 虛擬主機。在預設情況下,MAS 運作環境已經建立 Windows Server 2012 R2 DataCenter 範本,你可以直接使用此 VM 虛擬主機範本,或者由 MAS 管理人員自行建立新的 VM 範本。此實作環境中,租用戶登入 MAS 入口網站後,請依序點選 「New > Compute > WindowsServer-2012-R2-Datacenter」 項目即可。

    圖20、準備利用 IaaS 服務建立 VM 虛擬主機

    接著,只要經過簡單的 4 個操作步驟即可部署 VM 虛擬主機,分別是 「Basics > Size > Settings > Summary」:

    1. Basics: 首先,你必須設定 VM 虛擬主機的電腦名稱,以及 Guest OS 的管理者帳號及密碼,同時選擇採用的訂閱名稱及資源群組名稱。
    2. Size: 預設情況下,MAS 已經建立好 2 種 VM 虛擬主機的運作規模,分別是 A1 Basic(1 Core、1.75 GB vRAM、2 Data Disk)以及 A2 Standard(2 Cores、3.5 GB vRAM、4 Data Disk)。當然,MAS 管理人員也可以自行建立不同大小的運作規模,以便租用戶挑選使用。
    3. Setting: 選擇所要採用的儲存體帳戶,以及這台 VM 虛擬主機所要採用的網路組態設定資訊。
    4. Summary: 最後,檢查這台 VM 虛擬主機的相關組態設定資訊是否正確無誤,確認後即可立即進行部署的動作。


    確認 VM 虛擬主機相關資訊無誤後,便可以按下 OK 鈕開始進行部署的動作,此時便可以在 MAS 入口網站中看到正在部署 VM 虛擬主機的訊息,部署作業完成後的 VM 虛擬主機,預設將會採用 192.168.133.x/24 網段的 IP 位址。

    圖21、透過 MAS 入口網站的 IaaS 服務部署 VM 虛擬主機


    結語

    透過本文的說明及實作演練,相信你已經了解 MAS 混合雲平台的強大功能,對於希望在內部資料中心建立私有雲及混合雲平台的企業或組織來說,建構 MAS 平台將能有效幫助 IT 管理人員及開發人員。同時,熟悉 Microsoft Azure 公有雲環境的 IT 管理人員,應該不難發現在 MAS 環境的使用者操作體驗,都跟 Azure 公有雲環境一模一樣,對於已經在使用 Azure 公有雲服務的企業使用者來說,完全不需要適應新的操作介面及方式便可立即使用。

    活動簡介

    Windows Server 2012(Hyper-V 3.0)已經大幅提升虛擬化平台整合能力。現在,Windows Server 2012 R2(Hyper-V 3.0 R2)功能更上一層樓,舉凡第二世代虛擬主機格式、AVMA 自動化授權啟用、線上擴充及縮小虛擬磁碟、Storage QoS…等功能強大應有盡有。

    你知道「」用建立容錯移轉叢集環境(Failover Cluster),也能夠達成VM虛擬主機線上遷移(Live Migration)、儲存即時遷移(Live Storage Migration)、無共用儲存即時遷移(Shared-Nothing Live Migration)…等功能嗎? 本課程除了將實作演練之外,同時深入剖析在企業或組織營運環境當中,該如何從無到有建置並導入Hyper-V虛擬化技術,協助你打造出最佳虛擬化平台。

    此外,下一代微軟雲端作業系統 Windows Server 2016 年底前即將推出,在本課程中也將帶領學員了解新的特色功能,例如,SDS 軟體定義儲存技術、SDN 軟體定義網路技術、Storage Replica 儲存複本技術…等。



    活動資訊

    時間: 每週六 09:00 ~ 17:00
    地點: 台中科技大學 (台中市北區三民路 91 號 2 樓)
    日期:       


    課程大綱

    實務班

    一、雲端運算模型
              1. x86 虛擬化技術
              2. 雲端運算三種服務類型、四種部署模型、五種服務特徵
              3. 虛擬化環境評估

    二、私有雲網路架構
              1. VM 虛擬主機通訊(Traffic)流量規劃及 QoS 流量限制
              2. VM 虛擬主機遷移(Migration)流量規劃
              3. VM 虛擬主機儲存(iSCSI Target、iSCSI Initiator)流量規劃
              4. SDN 網路虛擬化技術

    三、私有雲儲存架構
              1. 七種磁碟陣列(RAID)模式
              2. 三種類型的儲存設備 DAS、NAS、SAN(IP-SAN、FC-SAN)
              3. 如何選擇儲存設備、控制器、擴充櫃
              4. 如何計算儲存設備 IOPS 效能
              5. Storage Space Direct 儲存虛擬化技術

    四、Hyper-V 虛擬化平台及 VM 虛擬主機
              1. 運作模式切換(GUI / Server Core)
              2. 安裝與設定 Hyper-V 角色
              3. 管理虛擬網路
              4. 第二世代 VM 虛擬主機
              5. 虛擬磁碟種類、線上調整磁碟空間
              6. 客體服務
              7. 加強的工作階段
              8. VM 授權自動啟用
              9. 儲存資源 IOPS 品質控制
              10. 重複資料刪除
              11. 備份及還原(Export / WSB / Azure)

    五、計畫性停機解決方案
              1. 即時遷移(Live Migration)
              2. 儲存即時遷移(Live Storage Migration)
              3. 無共用儲存即時遷移(Shared-Nothing Live Migration)
              4. 跨版本即時遷移(Cross version Live Migration)

    進階班

    一、高可用性及高彈性的虛擬化架構規劃實務
              1. 如何規劃所要採用的 x86 實體伺服器規格
              2. CPU 中央處理器指令集的選擇
              3. Memory 記憶體的選擇
              4. NVNe / SSD / SAS / NL-SAS / SATA 硬碟種類的選擇與 IOPS 規劃
              5. RAID Card 的選擇與 RAID 模式規劃
              6. Network 網路環境的規劃

    二、建置容錯移轉叢集環境
              1. 選擇儲存資源(DAS/NAS/SAN)
              2. 建立容錯移轉叢集

    三、計畫性及非計畫性停機方案
              1. 即時遷移(Live Migration)
              2. 儲存即時遷移(Live Storage Migration)
              3. 無共用儲存即時遷移(Shared-Nothing Live Migration)
              4. 快速遷移(Quick Migration)

    四、VM 虛擬主機
              1. 應用程式監控(VM Monitoring)
              2. 主機反關聯性(Anti-Affinity)
              3. 叢集共用磁碟區快取(CSV Cache)

    五、異地備援方案
              1. Hyper-V 複本代理人
              2. 測試容錯移轉
              3. 計畫性容錯移轉
              4. 非計畫性容錯移轉
              5. 延伸複寫

    六、叢集感知更新
              1. 叢集節點維護模式(Maintenance Mode)
              2. 叢集感知更新(CAU)
              3. 匯出叢集感知更新報表

    書籍簡介

    Windows Server 2012 R2Hyper-V Server 2012 R2,都提供最好的 Hyper-V 虛擬化平台功能。在 Hyper-V 當中第 2 世代格式的 VM 虛擬主機,除了安全性增強之外啟動作業系統的時間更短,並且有效縮短 VM 虛擬主機安裝客體作業系統的時間,同時還能自動啟動客體作業系統軟體授權,同時在 2012 R2 版本當中,還有許多新增及增強的特色功能。在本書當中,我們將會教導你在實務應用上,有關 Hyper-V 最佳化組態設定及最佳建議作法,以便充分發揮 Hyper-V 虛擬化平台的高可用性、高擴充性、高效能。


    誰適合閱讀此書

    本書是針對具有 Hyper-V 基礎管理經驗,以及想深入了解 Hyper-V 細部功能的人而寫。

    如果,在你的測試環境中已經有 Hyper-V 虛擬化環境,現在你想要將測試的Hyper-V 虛擬化環境,轉移到正式的線上營運環境時,那麼這本書就是專為你而寫!!

    如果,你是 Hyper-V 的初學者那麼本書也值得你參考。但是,同時間你應該找一本 Hyper-V入門的書一同閱讀及實作。


    網路購書



    你將會從本書中學習到:

    • 透過 PowerShell 自動化機制,部署 Hyper-V 及 VM 虛擬主機。
    • 建立 HA 高可用性容錯移轉叢集解決方案。
    • 建立 Hyper-V 複本異地備援機制,以及 Azure Site Recovery 混合雲異地備援機制。
    • 深入剖析不同的儲存資源應用情境 (SAN、SOFS、Storage Spaces、MPIO、CSV、QoS、NTFS、ReFS......等),並針對 Windows Server 2012 R2 及 Hyper-V 儲存資源進行效能規劃及最佳建議作法。
    • 建立一個高效能且靈活運作的網路基礎架構,包括 vSwitch 虛擬網路交換器、網路卡小組、融合式網路、儲存網路、SMB Direct (RDMA)、IPAM……等。
    • 幫助你了解 Hyper-V 運作架構中,如何進行最佳化效能調校並測試運作效能。
    • 介紹 System Center 家族的各種角色及功能,以及如何透過 System Center 管理 Windows Server 及 Hyper-V 虛擬化環境。
    • 如何從舊版 Hyper-V 或其它 Hypervisors 虛擬化平台,遷移至最新版本的 Hyper-V 虛擬化環境。



    本書導讀

    • 《第 1 章、加速 Hyper-V 部署作業》,深入剖析 Hyper-V 主機理想的安裝方式,進而採用全自動化安裝的 VM 模組。
    • 《第 2 章、HA 高可用性解決方案》,深入討論有關 Hyper-V 容錯移轉叢集組態配置及最佳作法 。
    • 《第3章、備份及災難復原》,從備份 Hyper-V 主機及 VM 虛擬主機的方法開始,到 Hyper-V 複本以及如何針對 Hyper-V 進行災難復原。
    • 《第 4 章、Storage 效能規劃最佳作法》,深入剖析不同的儲存資源應用情境,對於Windows Server 2012 R2 及 Hyper-V 的影響。
    • 《第 5 章、Network 效能規劃最佳作法》,深入剖析不同的虛擬網路環境,對於Windows Server 2012 R2 及 Hyper-V 的影響。
    • 《第 6 章、Hyper-V 最佳化效能調校》,幫助你了解 Hyper-V 運作架構中,如何進行最佳化效能調校並測試運作效能。
    • 《第 7 章、透過 System Center 進行管理》,介紹 System Center 家族的各種角色及功能,以及如何透過 System Center 管理 Windows Server 及 Hyper-V 虛擬化環境。
    • 《第 8 章、遷移至 Hyper-V 2012 R2》,討論如何從舊版 Hyper-V 或其它 Hypervisors 虛擬化平台,遷移至最新版本的 Hyper-V 虛擬化環境。

    課程簡介

    雲端運算(Cloud Computing)風潮已經勢不可擋,但是您是否已經被市場上許多技術名詞搞得昏頭轉向,如 公有雲、私有雲、混合雲、軟體即服務SaaS、平台即服務PaaS、架構即服務IaaS…等,逐可見熟悉雲端運算架構及運作概念,同時具備虛擬化技術實戰經驗的專業人員,將是目前市場上企業及組織中最炙手可熱的人才。

    有鑑於此,本課程將由基礎雲端運算概念開始介紹,接著逐步深入至企業或組織打造私有雲環境時,從整體架構的底層也就是虛擬化架構,並以市場上虛擬化技術領導者 VMware vSphere為實作環境,一步一步帶領學員從無到有開始建置。



    課程資訊

    時間:  09:30 ~ 16:30
    地點: 聖約翰科技大學 - 新北市淡水區淡金路四段499號 (電資大樓 E408)
    日期: 2016/06/23、06/24、06/27
    網址:  VMware 虛擬化技術培訓課程




    課程大綱:

    一、雲端運算模型
    • x86 虛擬化技術
    • 雲端運算三種服務類型、四種部署模型、五種服務特徵
    • 虛擬化環境評估


    二、私有雲網路架構
    • VM 虛擬主機網路 (Traffic) 流量規劃及 QoS 流量限制
    • VM 虛擬主機遷移 (Migration) 流量規劃
    • VM 虛擬主機儲存 (iSCSI Target、iSCSI Initiator) 流量規劃
    • NSX 網路虛擬化技術


    三、私有雲儲存架構
    • 七種磁碟陣列 (RAID) 模式
    • 三種類型的儲存設備 DAS、NAS、SAN(IP-SAN、FC-SAN)
    • 如何選擇儲存設備、控制器、擴充櫃
    • 如何計算儲存設備 IOPS 效能
    • VMware VSAN軟體定義儲存技術


    四、了解 VMware vSphere 虛擬化技術
    • 了解 VMware vSphere Hypervisor 虛擬化平台
    • 了解 vNetwork (Virtual Network) 虛擬網路
    • 了解 vStorage (Virtual Storage) 虛擬儲存
    • 了解 vSwitch (Virtual Switch) 虛擬交換器
    • 了解 VM (Virtual Machine) 虛擬主機
    • 了解 NIC Teaming 網路負載平衡與容錯移轉機制
    • 了解 MPIO (Multipath I/O) 儲存負載平衡與容錯移轉機制
    • 了解 Nested Virtualization 巢狀式虛擬化架構


    五、VMware vSphere 虛擬化技術實作展示
    • 安裝 VMware vSphere ESXi 6虛擬化平台、導覽及初始化設定
    • 安裝 VMware vCenter Server 6管理平台、導覽及初始化設定
    • 建立虛擬網路環境vSwitch、VM Port Group、Network Policy、VMkernel Port
    • 建立及掛載虛擬儲存vStorage (NFS、SAN)
    • 建立、配置、管理VM虛擬主機
    • 建立VM虛擬主機範本及部署
    • VM虛擬主機磁碟空間線上擴充 (Disk Online Extend)
    • VM虛擬主機記憶體空間熱新增 (Memory Hot Add)
    • VM虛擬主機CPU 熱新增 (CPU Hot Add)
    • VM虛擬主機備份及還原
    • P2V 及 V2V 轉換

    這裡上課的學生真幸福啊,在茶水間就可以看到大海了 :)


    網管人雜誌

    本文刊載於 網管人雜誌第 124 期 - 2016 年 5 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

    文章目錄

    1、前言
    2、VSAN 運作架構
    3、VSAN 6.2 新功能
              重複資料刪除與壓縮
              啟用並觀察儲存空間節省資訊
              EC 編碼技術
              啟用 EC 編碼技術資料容錯機制
              QoS 服務品質管控
              組態設定 IOPS 儲存資源
              IOPS 效能監控服務
              開啟效能服務
              增強健康狀態監控
              安裝健康狀態監控服務
              如何進行故障排除作業
              主動式健康狀態測試
    4、結語


    1、前言

    VMware Virtual SAN(簡稱 VSAN),是 VMware 的「軟體定義儲存(Software-Defined Storage,SDS)」技術。簡單來說,透過 VSAN 技術便能夠將多台 x86 實體伺服器中,配置於實體伺服器的「本機硬碟(Local Hard Disk)」串連起來,進而將叢集當中所有叢集節點主機的儲存資源整合起來,成為一個巨大的儲存資源池並且能夠互相共用。

    VMware VSAN 最初版本,是在 2014 年 3 月時隨著 vSphere 5.5 Update 1 版本開始內建,也就是VMware VSAN 1.0 版本。接著在隔年,也就是 2015 年 3 月時隨著 vSphere 6.0 的發佈,直接與vSphere 最新版本對齊成為 VSAN 6.0 版本(原訂新版本為 VSAN 2.0)。

    半年後,於 2015 年 9 月時推出 VSAN 6.1 版本,其中最具代表性的功能便是「延伸叢集(Stretched Cluster)」,以及「支援 2 Nodes VSAN」運作架構。現在,第四世代的最新 VSAN 6.2 版本已經在 2016 年 2 月時推出,此版本當中的重要特色功能如下:

    • 重複資料刪除與壓縮: 能夠有效減少重複的資料區塊並進行壓縮的動作,最多可達 7 倍的儲存空間節省效率。
    • EC 編碼技術: 最多能夠讓儲存空間增加 2 倍,並且能夠讓資料靈活度維持不變,同時透過同位元資料保護技術,可以允許 1 或 2 個儲存元件故障損壞,所以也稱為 RAID 5 / RAID 6。
    • QoS 服務品質管控: 監控及管理每一台 VM 虛擬主機的 IOPS 儲存資源,避免部分 VM 虛擬主機暴增的儲存資源需求,影響到其它台 VM 虛擬主機的正常運作。
    • 支援 IPv6 網路環境: 支援 IPv4-Only、IPv6-Only、IPv4/IPv6-Both 的網路環境。
    • IOPS 效能監控: 可以針對不同的對象,例如,叢集、ESXi 主機、VM 虛擬主機…等,即時查看IOPS 儲存效能表現,便於管理人員找出效能瓶頸的元兇。
    • 增強健康狀態監控: 除了方便管理人員隨時監控 VSAN 運作健康狀態之外,同時幫助管理人員進行 VSAN 組態設定上的故障排除作業。

    圖 1、VMware Virtual SAN 版本演進及新增功能示意圖


    2、VSAN 運作架構

    VMware VSAN 軟體定義儲存技術,採用「原則 (Policy)」方式的儲存管理機制稱之為(Storage Policy-Based Management,SPBM)。透過 SPBM 及 vSphere API 機制,能夠將儲存資源抽象化並整合為資源池之後,提供給 vSphere 管理人員佈建 VM 虛擬主機的能力,同時針對不同的 VM 虛擬主機服務等級,採取不同的 VM 虛擬主機儲存原則,針對不同等級的 VM 虛擬主機進行佈建的動作。簡單來說,便是透過 SPBM 儲存管理機制,將 VM 虛擬主機的儲存資源擺放在適合的位置。

    圖 2、VMware VSAN 佈建 VM 虛擬主機運作概念示意圖

    在儲存空間的運作架構中,支援採用「Hybrid」儲存資源運作架構,也就是在「磁碟群組(Disk Group)」當中,採用 PCIe Flash / SSD / Ultra DIMM / NVMe 當成資料快取用途,在快取空間方面的比例為「30 % 寫入(Write)」以及「70 % 讀取(Read)」,在資料儲存空間方面則採用儲存空間大,但 I/O 效能較為普通的 SAS / NL-SAS / SATA 機械式硬碟即可。

    若是採用「All-Flash」儲存資源運作架構時,在資料快取的部份則與 Hybrid 運作架構有很大的差異,其中「100 % 寫入(Write)」資料快取部分,採用 PCIe Flash / SSD / Ultra DIMM / NVMe…等快閃記憶儲存資源負責,而「100 % 讀取(Read)」資料儲存部分,則是由一般的 SSD 固態硬碟負責。

    圖 3、VMware VSAN Hybrid / All-Flash 運作架構示意圖


    3、VSAN 6.2 新功能

    事實上,當企業或組織採用 VMware VSAN 軟體定義儲存技術,並建構 All-Flash 運作架構時,因為儲存空間相較於 Hybrid 運作架構來說更為寶貴。因此從 VSAN 6.2 版本開始,當企業或組織在建構 All-Flash 運作架構時,可以搭配「重複資料刪除與壓縮(Deduplication / Compression)」及「EC 編碼技術(Erasure Coding)」等儲存空間最佳化技術,以節省寶貴的快閃儲存資源空間並提高整體使用率。

    重複資料刪除與壓縮

    透過重複資料刪除與壓縮技術,最高可以幫 All-Flash 運作架構節省「7 倍」的儲存空間。簡單來說,當重複資料刪除與壓縮技術啟用後,資料區塊不斷寫入 VSAN 的快取層級時,系統便會檢視是否有重複的資料區塊,當發現相同內容的資料區塊時便會進行「重複資料刪除(Deduplication)」與「壓縮(Compress)」處理作業,然後移動到資料層級當中。

    在重複資料刪除的部分,VSAN 會以 4 KB Block Size 為單位進行處理,當重複資料區塊經過壓縮作業後,則會縮小成 2 KB Block Size 並儲存至資料層級當中。

    當然,儲存空間節省的比例在實務上,必須要視資料區塊重複比例資料類型而定,舉例來說,若是影音檔案(Video)的話,那麼重複資料刪除與壓縮的比例就會偏低,倘若是一般文件檔案(Document)的話,那麼節省空間的比例便會提升許多。

    圖 4、VMware VSAN 重複資料刪除與壓縮技術運作示意圖


    啟用並觀察儲存空間節省資訊

    預設情況下,重複資料刪除與壓縮技術為「停用(Disabled)」狀態,若要進行啟用的話操作步驟非常簡單,只要登入 vSphere Web Client 管理介面,依序點選「Cluster > Manage > Settings > Virtual SAN > General > Edit Settings」,在彈出的編輯 Virtual SAN 設定視窗中,在 Deduplication and compression 欄位下拉式選單中,選擇至「啟用(Enabled)」項目即可(如圖 5 所示)。

    值得注意的是,當你為 VSAN Cluster 啟用重複資料刪除與壓縮技術後,在 VSAN Cluster 當中的每台叢集節點主機當中,每個「磁碟群組(Disk Group)」都會重新進行格式化的動作,因此這可能需要花費相當長的一段時間。

    但是,在資料區塊重新格式化動作的執行期間,於 VSAN Cluster 當中運作的 VM 虛擬主機,並不會受到任何影響。此外,在目前的 VSAN 6.2 版本當中,「重複資料刪除」與「壓縮」這 2 個儲存空間最佳化機制,並無法單獨啟用只能一同啟用。

    圖 5、啟用重複資料刪除與壓縮技術

    同時,當 vSphere 管理人員為 VSAN Cluster 啟用重複資料刪除與壓縮技術後,那麼在 VSAN 的「物件空間保留區(Object space reservation)」的儲存原則,只能設定為「0 % 或 100 %」(預設值為 0 %)。

    在目前的 VSAN 6.2 版本當中,啟用重複資料刪除與壓縮技術後,便不允許物件空間保留區儲存原則設定為 1 % ~ 99 %

    當 VSAN Cluster 順利啟用重複資料刪除與壓縮技術,並且完成重新格式化的動作之後,那麼在 vSphere Web Client 管理介面中,便可以看到目前節省多少儲存空間以及空間節省倍數

    圖 6、查看節省多少儲存空間以及空間節省倍數


    EC 編碼技術

    在 VSAN 6.2 版本中,第 2 種儲存空間最佳化技術就是在 SPBM 儲存原則當中,加入新的「容錯方法(Fault Tolerance Method,FTM)」,讓 vSphere 管理人員可以選擇要採用的資料容錯方式。

    VSAN 6.2 版本以前,預設情況下將會採用「鏡像(Mirroring)」也就是 RAID-1 的資料容錯方式。現在,當企業或組織建構 All-Flash 運作架構後,可以選擇採用「EC 編碼技術(Erasure Coding)」,也就是 RAID-5 / RAID-6 的資料容錯方式。

    雖然,舊有的 RAID-1 在資料寫入效能方面更為出色,但是消耗的儲存空間更多。採用新式的 EC 編碼技術 RAID-5 / RAID-6 資料容錯機制,除了效能表現接近原有的 RAID-1 之外,在儲存空間方面最多可以「減少 50 %」的消耗,以充份節省寶貴的快閃儲存資源。

    在下列表格中,我們可以看到當 VSAN Cluster 採用不同的「容許的故障次數(Number of Failures to Tolerate,FTT)」儲存原則時,舊有的 RAID-1(Mirroring)以及新式的 RAID-5 / RAID-6(Erasure Coding),在儲存空間的消耗比例:


    因為 2 種資料可用性及可用空間的不同,因此對於 VSAN Cluster 當中叢集節點主機的數量,也會有最低主機數量要求及建議主機數量。下列表格,便是採用不同的容許故障次數儲存原則時,在 VSAN Cluster 當中分別需要的叢集節點主機數量:


    因此,當 vSphere 管理人員建構 All-Flash 運作架構,並且採用 RAID-5 / RAID-6(Erasure Conding)資料容錯機制時,當設定「容許故障次數 FTT = 1」儲存原則時,如圖 7 所示可以看到在 VSAN Cluster 當中,每台叢集節點主機當中都將包含 1 份「同位元(Parity)」,以便達成資料容錯運作架構。

    圖 7、FTT = 1 時,RAID-5 / RAID-6(Erasure Conding)資料容錯機制

    倘若希望得到更高的資料可用性時,可以設定「容許故障次數 FTT = 2」的儲存原則,如圖 8 所示可以看到在 VSAN Cluster 當中,每台叢集節點主機當中都將包含 1 份「同位元(Parity)」,但叢集節點主機數量必須至少 6 台,以便達成更高可用性的資料容錯運作架構。

    圖 8、FTT = 2 時,RAID-5 / RAID-6(Erasure Conding)資料容錯機制


    啟用 EC 編碼技術資料容錯機制

    同樣的,在 All-Flash 運作架構中,當 vSphere 管理人員在 VSAN Cluster 建立 SPBM 儲存原則時,只要在 Failure tolerance method 下拉式選單中,選擇至「RAID-5/6(Erasure Coding)-Capacity」項目(如圖 9 所示),即可採用新式的 EC 編碼技術達成資料高可用性及空間節省的目的。

    此外,在組態設定視窗當中你可以看到,倘若我們在 FTT 儲存原則欄位輸入數值「1」的話(也就是 FTT = 1),那麼當 VM 虛擬主機的虛擬磁碟的儲存空間為 100 GB 時,那麼在資料高可用性的情況下只會使用「133.33 GB」,若設定 FTT = 2 的話,那麼在資料高可用性的情況下則會使用「150 GB」的儲存空間。

    圖 9、在 All-Flash 運作架構中啟用新式的 EC 編碼技術


    QoS 服務品質管控

    在虛擬化平台當中,眾多 VM 虛擬主機將會共享同一個或多個儲存資源。然而,有時可能會發生部分 VM 虛擬主機,因為突然爆增的 IOPS 儲存需求,例如,報表主機平時可能只消耗 300 IOPS 儲存資源,但是在月底進行結算時由於大量的資料需要進行分析運算,可能爆增至消耗 6000 IOPS 的儲存資源。

    因此,在企業或組織的資料中心當中,將有可能因為部分 IOPS 儲存需求爆增的 VM 虛擬主機,造成所謂的「吵鬧鄰居(Noisy Neighbor)」現象。簡單來說,就是這幾台 IOPS 爆增的 VM 虛擬主機,因為大量消耗儲存資源進而導致影響其它 VM 虛擬主機的運作。

    在 VSAN 6.2 版本中,新增儲存資源 QoS 服務品質管控機制的 SPBM 儲存原則。透過 SPBM 儲存原則針對 VSAN 當中的「物件(Object)」,進行 IOPS 儲存資源的存取限制,以避免在 VSAN Cluster 運作環境當中的 VM 虛擬主機,發生吵鬧鄰居的現象。

    因為是針對 VSAN 物件進行 IOPS 儲存資源的限制,所以並非是以整台 VM 虛擬主機為單位,而是以「VMDK 虛擬磁碟」為單位,並且當 vSphere 管理人員設定並套用 SPBM 儲存原則後,並不會影響到線上 VM 虛擬主機的運作。


    組態設定 IOPS 儲存資源

    當 vSphere 管理人員希望針對 VSAN 物件,設定 IOPS 儲存資源管控機制時,只要在建立 VSAN SPBM 儲存原則時,在 IOPS limit for object 欄位中填入該物件的 IOPS 最大使用數值即可(如圖 10 所示)。

    值得注意的是,在 VSAN 6.2 版本當中 IOPS 計算的資料區塊大小基準為「32 KB」,不管是資料的「讀取」或「寫入」都採用同樣大小的資料區塊。倘若,在你的 VSAN Cluster 運作環境中,你將資料區塊大小設定為 64 KB 時,那麼若是設定 IOPS 為 200 IOPS 的話,則實際上該 VSAN 物件將僅會得到 100 IOPS 的儲存資源。

    圖 10、組態設定 VSAN 物件 IOPS 儲存資源


    IOPS 效能監控服務

    雖然,我們可以針對 VSAN 物件進行 IOPS 儲存資源管控,避免運作環境發生吵鬧鄰居的情況。但是,在過去的 VSAN 版本當中並沒有簡單的方式,能夠觀察到 VSAN Cluster 當中各項運作元件的 IOPS 儲存資源使用情況。

    現在,在 VSAN 6.2 版本當中,透過啟用「效能服務(Performance Service)」之後,便能夠在 vSphere Web Client 管理介面中,直接看到 VSAN Cluster、ESXi 主機、VM 虛擬主機、磁碟群組…等,各項運作元件的 IOPS 儲存資源使用情況。


    開啟效能服務

    vSphere 管理人員只要登入 vSphere Web Client 管理介面後,編輯 VSAN Cluster當中的組態設定,便可以「開啟(Turned On)」效能服務,開始收集 VSAN 各項運作元件的 IOPS 使用情況。

    值得注意的是,當你為 VSAN Cluster 啟用效能服務之後,所統計的 IOPS 儲存資源使用情況數據,並非儲存在 vCenter Server 資料庫當中,而是儲存在獨立的 VSAN 物件當中,並且根據收集的 IOPS 儲存資源資料量,此 VSAN 物件的儲存空間最大可至 255 GB

    圖 11、為 VSAN Cluster 啟用效能服務

    當 VSAN Cluster 順利啟用效能服務之後,便可以針對各項運作元件即時或選擇區間,查看 IOPS 儲存資源的使用情況。如圖 12 所示,便是查看 VSAN Cluster 內 ESXi 主機層級中,其上運作的 VM 虛擬主機整體 IOPS 儲存資源使用情況。

    圖 12、查看 ESXi 主機層級中 VM 虛擬主機整體 IOPS 儲存資源使用情況


    增強健康狀態監控

    在前一版 VSAN 6.1 時,便開始內建「健康狀態檢查外掛程式(Health Check Plug-in)」,能夠有效協助管理人員進行硬體、韌體、驅動程式相容性檢查、網路即時診斷機制…等,以便確保整個 VSAN Cluster 內所有進階組態設定的一致性。

    在目前最新 VSAN 6.2 版本當中,則是增強整個健康狀態監控機制,舉例來說,在 VSAN HCL 硬體相容性檢查項目中,除了能夠進行 VSAN Cluster 叢集節點的 HCL 硬體組態進行檢測之外,現在還能定期更新 HCL Database 內容,以便因應不斷更新的硬體伺服器規格。


    安裝健康狀態監控服務

    在 VSAN Cluster 運作環境中,安裝健康狀態監控服務也很簡單。首先,若採用的是 vCSA(vCenter Server Appliance)的話,那麼登入後只要使用「rpm -Uvh」指令搭配相對應版本的 RPM 檔案,然後執行「/usr/lib/vmware-vpx/vsan-health/health-rpm-post-install.sh」指令,即可完成安裝動作。

    若是採用 Windows vCenter Server 的話,則需要在安裝 MSI 檔案後,重新啟動「VMware Virtual Center Server」服務即可完成安裝動作。

    有關 vCenter Server 安裝健康狀態監控服務的詳細資訊,請參考 VMware KB 2109874

    安裝動作完成後,預設情況下 VSAN 健康狀態監控服務為「停用」狀態,此時只要登入 vSphere Web Client 管理介面,依序點選「Cluster > Monitor > Virtual SAN > Health」項目,然後點選「立即啟用(Enable now)」即可。

    預設情況下,啟用 VSAN 健康狀態監控服務後,系統將會每隔「60 分鐘」便進行檢查的動作。如果,你希望調整此預設組態的話,請依序點選「Cluster > Manage > Settings > Virtual SAN > Health」後,按下「Edit settings」鈕即可進行調整。
    圖 13、啟用 VSAN 健康狀態監控服務

    現在,你應該已經看到各種 VSAN 健康狀態監控項目,同時你可以展開每個監控項目,了解整個檢查作業的細項。值得注意的是,倘若是從舊版本的 VSAN 健康狀態監控服務升級上來的話,那麼應該要按下「Retest」鈕,讓 VSAN Cluster 能夠重新套用新的 VSAN 健康狀態監控版本,並且再次進行健康狀態檢查的動作。

    圖 14、查看 VSAN 健康狀態監控項目詳細資訊


    如何進行故障排除作業

    那麼,當 VSAN Cluster 健康狀態發生問題時,該如何進行故障排除作業呢? 首先,我們可以在偵測到健康狀態為「警告或錯誤」的項目,展開子項目後查看是哪個細項發生問題,如圖 15 所示我們可以看到,目前「Advanced Virtual SAN configuration in sync」子項目發生錯誤。

    此時,你可以先按下「Ask VMware」鈕,便會出現 VMware KB 資訊了解目前發生警告或錯誤的原因,以及如何進行故障排除作業。在此次實作環境當中,錯誤發生的原因是 VSAN Cluster 當中的 esxi04 叢集節點主機,因為「VSAN.ClomRepairDelay」的組態設定值,與 VSAN Cluster 其它叢集節點主機不同所導致。

    圖 15、透過 VSAN 健康狀態監控進行故障排除作業


    主動式健康狀態測試

    除了預設每隔 60 分鐘進行整體 VSAN Cluster 健康狀態測試之外,vSphere 管理人員也可以隨時進行「主動式健康狀態測試(Proactive health checks)」。在目前的 VSAN 6.2 版本中,支援 3 種主動式健康狀態測試項目:

    • VM 虛擬主機建立作業測試
    • Multicast 效能測試
    • Storage 效能測試


    vSphere 管理人員,只要登入 vSphere Web Client 管理介面後,依序點選「Cluster > Monitor > Virtual SAN > Proactive Tests」項目,然後點選希望進行主動式健康狀態測試的項目後,按下「綠色三角形」圖示即可進行主動測試作業。

    圖 16、進行主動式健康狀態測試


    4、結語

    透過本文的說明,相信讀者已經了解到最新的 VSAN 6.2 版本有哪些特色功能,能夠幫助企業或組織建構更高資料可用性,以及儲存資源的高可擴充性及靈活度。同時,我們可以看到針對 All-Flash 高階軟體定義儲存運作架構,也推出相對應的儲存空間最佳化機制,以便節省寶貴的快閃記憶體儲存資源。

    此外,增強的 VSAN 健康狀態監測機制,除了能夠有效幫助 vSphere 管理人員,掌管整個 VSAN Cluster 運作架構之外,還能夠幫助進行基礎架構的組態設定故障排除作業,以便管理人員能夠在運作架構發生警告或錯誤時,在最短時間內排除問題讓企業或組織的線上服務,能夠在快速恢復原有的良好運作狀態。