網管人雜誌

本文刊載於 網管人雜誌第 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 運作架構之外,還能夠幫助進行基礎架構的組態設定故障排除作業,以便管理人員能夠在運作架構發生警告或錯誤時,在最短時間內排除問題讓企業或組織的線上服務,能夠在快速恢復原有的良好運作狀態。

網管人雜誌

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

文章目錄

1、前言
2、Microsoft OMS 概觀
3、建立 OMS 工作區
          透過 OMS 網站建立 OMS 工作區
          透過 Azure Portal 建立 OMS 工作區
4、開始使用 OMS 工作區
          新增 OMS 解決方案套件
          選擇資料收集連接方式
          指定資料收集類型
5、建立 OMS 監控作業
          為 Azure VM 虛擬主機啟用 OMS 監控機制
          為企業內部實體主機或 VM 啟用 OMS 監控機制
          OMS 儀表板
          新增解決方案套件
          行動監控
6、結語


1、前言

公有雲(Public Cloud)運作環境成熟之賜,讓原本習慣於私有環境的 IT 運作架構發生重大的改變。舉例來說,以往企業或組織習慣將官方網站,擺放於內部自建的資料中心或 IDC 代管中心,然後採購硬體伺服器並租用網際網路頻寬,再聘請開發人員及網站前端後端人員...等,最後打造出精美且多功能的官方網站。

但是,現在有了成熟的公有雲運作環境之後,企業或組織在公有雲環境中建立 PaaS 類型的 Web 網站服務之後,只要操心官方網站內容的維護即可,底層硬體伺服器、網際網路頻寬、網路穩定性...等完全不需要操心。同時,根據 IDC 的統計調查結果顯示,預估在 2016 年時 IT 公有雲服務規模將達到 980 億美元

圖 1、2016 年全球 IT 公有雲服務總收入預估 

當企業或組織開始嘗試在公有雲環境中建立各項服務之後,便會自然而然與企業內部環境(On-Premise)結合,形成混合雲(Hybrid Cloud)的運作環境。舉例來說,以往企業或組織在備份資料時,可能將資料備份於磁帶櫃或儲存陣列設備中,現在可以將資料加密後備份至雲端儲存體當中。同時,根據 IDC 的統計調查結果可以得知,企業或組織的 IT 運作環境將日趨混合雲型態的運作架構。

圖 2、IT 服務預算比例預估(現在、2 年後) 
圖片來源:IDC Cloud Track Survey

然而,以往在企業或組織內部運作環境當中,IT 管理人員所建置的 SCOM(System Center Operation Manager)監控機制,僅針對企業內部環境的各種應用服務及設備的健康情況。對於公有雲及混合雲的各項監控需求便無法精確的進行監控,因此 IT 管理人員需要更靈活的監控機制。

本文將說明及實作,如何透過 Microsoft OMS(Operations Management Suite),達到全面監控公有雲及混合雲運作環境。此外,Microsoft OMS 不只能針對微軟自家公有雲 Azure 進行監控,它也支援異質的公有雲環境如 AWS(Amazon Web Services)進行監控作業。

圖 3、Microsoft OMS(Operations Management Suite)運作架構示意圖 


2、Microsoft OMS 概觀

Microsoft OMS 是專門為了混合式架構的運作環境而設計。它可以監控及管理 Azure 公有雲環境、企業內部的 Windows Server 及 Linux Server,此外對於異質平台例如 AWS 公有雲環境,及企業內部所建立的 VMware、OpenStack 等虛擬化環境,也都能夠進行管理及監控作業。

事實上,Microsoft OMS 並非僅能進行監控作業而已,它還具備下列各項特色功能:

  • 日誌分析(Log Analytics): 為企業或組織的內部資料中心,收集並儲存分析 Windows Server 及 Linux Server 的日誌檔案,或是 Azure 及 AWS 等公有雲環境中相關日誌資料。最後,達到以單一工具全面監控伺服器的工作負載,並提供最佳做法以便協助 IT 管理人員在最短時間內發現並解決問題。
  • IT 自動化(IT Automation): 協助 IT 管理人員,透過 Windows PowerShell 及 Runbook 等工具,達成企業或組織內部資料中心建立 / 監控 / 管理 / 部署等作業。
  • 備份與復原(Backup and Recovery): 整合公有雲儲存資源,為企業或組織提供災難復原機制。當企業或組織遭遇災難事件時,可以快速從雲端環境進行資料復原,或將內部工作負載轉移至雲端環境中繼續運作。
  • 混合雲安全性(Security and Compliance): 透過收集、儲存、分析伺服器的日誌資料,了解伺服器是否需要進行安全性更新,或審查整體安全性稽核事件,以達到身份識別及修復資訊安全風險的目的。


3、建立 OMS 工作區 

建構 Microsoft OMS 運作環境,首先必須要建立「OMS 工作區(OMS WorkSpace)」。目前,IT 管理人員可以有 2 種方式來建立 OMS 工作區:

  • 透過 Microsoft Operations Management Suite 網站建立 OMS 工作區。
  • 透過 Azure Management Portal 建立 Operational Insights 工作區。

目前,Azure Portal 當中有分為 New Azure Portal 採用 ARM(Azure Resource Manager)進行管理,以及 Old Azure Portal 也就是 Azure Management Portal,採用 Azure Service Management 進行管理。此外,在 Azure Management Portal 中的 Operationsl Insights 為 OMS 的舊稱。
建立 OMS 工作區之後,便可以新增各種「解決方案(Solutions)」,接著為伺服器安裝 OMS 代理程式或者與企業內部 SCOM 整合連接,最後便可以透過單一的 OMS 平台進行管理及監控作業。如下圖所示,便是整個 OMS 管理平台的建構流程:

圖 4、Microsoft OMS 管理平台建構流程示意圖 


透過 OMS 網站建立 OMS 工作區

請開啟瀏覽器連結 OMS 網站,按下免費試用連結至 OMS 申請頁面後,以 Microsoft 帳戶或 Office 365 帳戶進行登入。

接著,在建立新工作區頁面中於各項欄位填入相關資訊,例如,工作區名稱(Workspace Name)...等。值得注意的部分是,目前 OMS 工作區支援的資料中心僅「美國東部(East US)」 及「西歐(West Europe)」,相關資訊確認無誤後按下 Create 鈕即可建立 OMS 工作區。

圖 5、透過 OMS 網站建立 OMS 工作區


透過 Azure Portal 建立 OMS 工作區 

若你已經擁有 Azure 訂閱帳戶,也可以登入 Azure Management Portal 入口網站,通過身分驗證程序順利登入後,請依序點選「Operationsl Insights > 建立工作區」,然後在相關欄位中填入建立 OMS 工作區的資訊後,按下建立工作區圖示即可建立 OMS 工作區。

值得注意的部分是,在建立 OMS 工作區時可以指定的收費階層欄位,共有 3 種方案可供選擇分別是「免費(Free)、標準(Standard)、高階(Premium)」,這 3 種收費階層對於每日收集的資料量,以及資料保留期間都有所不同,請依運作環境規模選擇適當的方案。

圖 6、透過 Azure Management Portal 建立 OMS 工作區


4、開始使用 OMS 工作區

當 OMS 工作區建立完成後,便可以登入 Microsoft OMS 網站。順利登入 OMS 網站後,因為我們尚未組態設定 OMS 收集任何資料,所以你可以看到目前的 OMS 儀表板中並沒有任何資料,只有 OMS Twitter 的最新資訊。接下來,只要透過 3 個簡單的設定步驟,即可開始進行伺服器的收集、儲存、分析等作業。

圖 7、登入 OMS 工作區,準備進行初始化作業


新增 OMS 解決方案套件

若 IT 管理人員有使用 SCOM 監控機制的話,對於 SCOM 中提供的「管理套件(Managment Pack,MP)」 應該不陌生,在 SCOM 運作環境中透過各項 MP 管理套件的強大功能,可以輕鬆為 SCOM 強化各項應用服務監控能力。同樣的運作概念,在 OMS 當中稱之為「解決方案套件(Solution Pack,SP)」。

在 OMS 入口網站中,按下「Get Started」 之後便能連結至解決方案套件頁面,進行初始化設定程序的第 1 個步驟,預設情況下會自動載入「日誌搜尋(Log Search)」 解決方案套件。

同時,也將自動勾選 6 項解決方案套件,分別是無須整合 Azure 公有雲環境的惡意軟體評估(Malware Assessment)、系統更新評估(System Update Assessment)、組態變更追蹤(Change Tracking),以及需要整合 Azure 公有雲環境的 Azure 災害復原服務(Azure Site Recovery)、備份(Backup)、自動化(Automation)等。

這些 OMS 解決方案套件,可以立即勾選後馬上新增也可以後續再進行新增的動作,確認目前要載入的 OMS 解決方案套件項目後,便可以按下「Add selected Solutions」 鈕,然後繼續下一個 OMS 初始化程序。

圖 8、新增預設提供的 OMS 解決方案套件


選擇資料收集連接方式

點選「Connect Sources」 頁籤之後,便可以看到目前 OMS 所支援的 3 種資料收集方式,分別是:

  • Servers Connected
  • MGMT Groups Connected
  • Storage Account Connected


Servers Connected」 的資料收集方式,是幫企業或組織當中內部運作的 Windows 或 Linux 伺服器,安裝 OMS 代理程式後進行資料收集作業。倘若是在 Azure 公有雲環境中運作的 VM 虛擬主機,可以透過 Portal 的方式直接為 VM 虛擬主機安裝及啟用 OMS 代理程式。

此資料收集方式,可以針對 Azure VM 虛擬主機,或是企業及組織在內部運作環境中並沒有建置 SCOM 監控機制的情況下,直接為內部運作的 Windows 或 Linux 伺服器進行監控作業。

若企業或組織內部已經建構好 SCOM 監控機制時,便可以透過「MGMT Groups Connected」 的資料收集方式,直接將地端的 SCOM 監控資訊與雲端的 OMS 管理平台進行整合連結,無須為地端的 Windows 或 Linux 伺服器逐台安裝 OMS 代理程式。

最後,企業或組織可以將 Windows 或 Linux 伺服器,各種事件記錄或是網站的 IIS 日誌儲存至 Azure 雲端儲存體當中,然後透過「Storage Accounts Connected」 資料收集方式,讓 OMS 管理平台讀取及分析 Azure 雲端儲存體當中所儲存的各種日誌。
事實上,在 OMS 管理介面中已經可以看到預計將會支援 AWS 儲存體(例如,S3)。
圖 9、目前 OMS 所支援的 3 種資料收集方式


指定資料收集類型

最後,請點選「DATA」 頁籤,便可以指定 OMS 所要收集的日誌資料類型。目前,OMS 支援 6 種日誌資料來源,分別是 Windows 事件日誌、Windows 效能計數器、Linux 效能計數器、IIS 日誌、自訂欄位、Syslog。

舉例來說,IT 管理人員希望監控 Windows 伺服器中,有關硬體事件(Hardware Event),便可以點選 Windows Event Logs 項目後,輸入資料收集關鍵字 Hardware 後,便可以勾選想要收集的事件等級,例如,錯誤(Error)、警告(Warning)、資訊(Information)...等。最後,便可以按下 Save 進行組態設定存檔的動作。

圖 10、指定 OMS 所要收集的事件類型及事件等級


5、建立 OMS 監控作業

順利建立 OMS 工作區,以及新增各項解決方案套件並指定資料收集方式及類型後,便可以為 Azure 公有雲環境的 VM 虛擬主機,或者企業及組織內部的實體主機或 VM 虛擬主機,啟用及安裝 OMS 代理程式(或稱為 Microsoft Monitor Agent),或者是與企業內部的 SCOM 進行整合的動作,便可以在 OMS 管理平台中進行統一監控的動作。


為 Azure VM 虛擬主機啟用 OMS 監控機制

當你建立 OMS 工作區完成後,倘若要監控 Azure 公有雲環境中的 VM 虛擬主機時,只要登入 Azure Management Portal 後,依序點選「Operational Insights > OMS 工作區>伺服器」,便會看到 Azure VM 虛擬主機清單,請點選準備啟用及安裝 OMS 代理程式的 VM 虛擬主機後,點選下方「啟用 Opinsights」 圖示,系統便會自動幫指定的 VM 虛擬主機安裝及啟用 OMS 代理程式。

當 Azure VM 虛擬主機安裝及啟用 OMS 代理程式完成後,在 Azure Management Portal 中便可以看到,該 VM 虛擬主機在 Operational Insights 已啟用欄位從先前的否轉變為「」,而狀態欄位從先前的空值轉變為「作用中」。此時,便表示該台 Azure VM 虛擬主機已經安裝及啟用 OMS 代理程式完成。

圖 11、指定的 Azure VM 虛擬主機已經安裝及啟用 OMS 代理程式完成


為企業內部實體主機或 VM 啟用 OMS 監控機制

倘若在企業內部中並未建置 SCOM 監控機制,那麼也可以直接在實體主機或 VM 虛擬主機當中,安裝 OMS 代理程式後啟用 OMS 監控機制。請登入 OMS 網站後,切換至 Connected Sources 頁籤依主機作業系統類型,下載用於 Windows 或 Linux 作業系統的 OMS 代理程式,並記錄下方所列的 Workspace IDPrimary Key

圖 12、下載 OMS 代理程式並記錄 Workspace ID 及 Primary Key

值得注意的是,在為企業內部的實體主機或 VM 虛擬主機安裝 OMS 代理程式時,必須要填入剛才在 OMS 網站中下方所列的 Workspace ID 及 Primary Key,那麼企業內部主機中的 OMS 代理程式,才能正確將所收集到的資料狀態上傳至正確的 OMS 工作區當中。

圖 13、必須填入正確 Workspace ID 及 Primary Key 才能順利進行監控作業

此外,通常在企業或組織內部運作環境當中,實體主機或 VM 虛擬主機是在企業防火牆的保護中運作。因此,請記得在企業防火牆中開啟允許下列防火牆規則,以便 OMS 代理程式的資料流量能夠順利通過企業防火牆,傳送至位於雲端環境中的 OMS 管理平台當中:

  • *.ods.opinsights.azure.com : 443
  • *.oms.opinsights.azure.com : 443
  • ods.systemcenteradvisor.com : 443
  • *.blob.core.windows.net : 443


若企業內部已經建構 SCOM 監控機制的話,那麼便可以直接為 SCOM 與 OMS 進行整合連接的動作,那麼 OMS 便可以直接取得地端 SCOM 的監控資料,並呈現於 OMS 儀表板當中。

值得注意的是,若是建構的 SCOM 版本為 System Center 2012 SP1 的話,那麼至少必須要 Operations Manager UR7,並且安裝 OMS Connector for Operations Manager,才能順利與 OMS 整合連接。若 SCOM 版本為 System Center 2012 R2 的話,至少必須要 Operations Manager UR3,才能順利與 OMS 整合連接。

當 SCOM 運作環境符合 OMS 整合連接時,開啟 SCOM 主控台後依序點選「Administration > Operations Management Suite > Connection」 項目,便可以進行「Register to Operations Management Suite」 的動作,然後填入 Microsoft 帳戶及 OMS 工作區名稱,即可進行整合連接的動作。

圖 14、企業內部 SCOM 與雲端環境的 OMS 整合連接 


OMS 儀表板

當我們順利為 Azure 雲端環境的 VM 虛擬主機,或企業內部的實體主機及 VM 虛擬主機,安裝及啟用 OMS 代理程之作業之後。接著,便可以在 OMS 入口網站中看到相關的資料統計結果。

圖 15、OMS 儀表板

首先,我們可以點選左下角的「Usage」 項目,查看目前 OMS 資料收集所使用的流量情況。倘若,先前你在建立 OMS 工作區時,採用的是「免費(Free)」 方案的話,那麼一定要注意每日的資料流量限制為 500MB,若當日達到 500MB 資料量時 OMS 將會停止進行資料分析作業,同時所收集到的資料僅會保留 7 天而已。

若是採用標準或高階方案的話,則沒有每日收集資料量的限制,但「標準(Standard)」 方案的話資料收集的保留期間為 1 個月,而採用「高階(Premium)」 方案的資料保留期間則為 12 個月

圖 16、查看 OMS 資料量收集數據及 SLA 服務情況

回到 OMS 儀表板後,你可以點選各項解決方案套件內容,舉例來說,我們點選「組態變更追蹤(Change Tracking)」 項目,進入後可以看到此解決方案套件中有 5 個子項目,分別針對組態設定變更、軟體變更、應用程式變更、Windows 服務變更、組態變更追蹤查詢。

圖 17、查看組態變更追蹤(Change Tracking)解決方案套件內容

舉例來說,我們想再深入查看「軟體變更(Software Changes)」 子項目的內容,便可點選該子項目下方的 See all,便可以查看更詳細的軟體變更資訊,例如,每台被監控伺服器的主機名稱以及軟體變更數量,並且在操作介面中還支援直接將資料收集數據匯出 Excel(.csv)檔案格式,方便 IT 管理人員將相關數據自行客製化成其它報表格式。

圖 18、深入查看軟體變更(Software Changes)子項目的內容


新增解決方案套件

事實上,除了進行 OMS 初始化設定時,可以勾選預設的 6 項解決方案套件之外,OMS 仍持續不斷推出各式各樣的解決方案套件。

請在 OMS 入口網站中點選「Solutions Gallery」 圖示,便可以看到目前可以擴充 OMS 監控能力的各項解決方案套件,若該解決方案套件顯示為「Owned」,則表示該解決方案套件已經新增且正在使用中,若顯示為「Free」 則表示可以新增該解決方案套件,若顯示為「Coming Soon」 則表示該解決方案套件即將推出。

圖 19、新增 OMS 解決方案套件

舉例來說,此實作環境中希望能夠監控 AD 複寫狀態,便可以點選「AD Replication Status」 項目,了解此解決方案套件的功能說明,以及屆時呈現的儀表板範例,若符合你的運作環境監控需求便可以按下「Add」 鈕進行新增。

圖 20、新增 AD Replication Status 解決方案套件


行動監控

除了透過 OMS 入口網站進行監控管理作業之外,OMS 還提供 App 行動應用程式(支援 Windows Phone、iOS、Android),讓 IT 管理人員可以隨時隨地監控企業內部或雲端環境的運作狀態。只要在 App 商店搜尋關鍵字「Microsoft OMS」,即可進行安裝作業。

當 Microsoft OMS App 安裝完成後,首先會請你先登入建立 OMS 工作區的 Microsoft 帳戶,順利通過身分驗證程序後,將會請你選擇要進行查看的 OMS 工作區,你可以發現到與剛才在 OMS 入口網站的儀表板上,有著相同的使用者操作體驗。

圖 21、透過 Microsoft OMS App 隨時隨地查看監控狀態

同樣的,我們也再次深入查看「軟體變更(Software Changes)」 子項目的內容,與剛才在 OMS 入口網站的儀表板中一樣有著相同的使用者操作體驗,讓 IT 管理人員只要擁有智慧型行動裝置及連網能力,便能達到隨時 / 隨地 / 隨處監控的目的。

圖 22、與 OMS 入口網站儀表板擁有相同的使用者操作體驗


6、結語

透過本文的說明及實作演練,相信讀者已經了解到如何為企業或組織,監控 Azure 公有雲環境的 VM 虛擬主機,以及企業內部實體主機或 VM 虛擬主機或與內部 SCOM 整合連結,以便建立 Microsoft OMS 混合雲運作架構監控機制。同時,透過 OMS 不斷擴增的解決方案套件,將能有效幫助 IT 管理人員進行更全面的監控。

此外,透過安裝 Microsoft OMS App 行動應用程式,讓 IT 管理人員即時出門在外,只要有網路通訊便能輕鬆透過智慧型手機,監控企業或組織在雲端環境或企業內部的各項應用服務健康狀態。

前言

昨天晚上在微軟官方網站 TechNet Evaluation Center 上,正式釋出 Windows Server 2016 TP5 (Technical Preview 5)。同時,System Center 2016 TP5 也釋出了。同樣的,在 Windows Server 2016 當中仍維持 Standard 及 DataCenter 版本,功能簡述如下:

Windows Server 2016 Standard
  • Up to 2 VM's or Hyper-V containers
  • Unlimited Windows containers
  • New Nano Server deployment option for "just enough OS"
Windows Server 2016 Datacenter
  • Unlimited VM's and Hyper-V containers
  • Unlimited Windows containers
  • New Nano Server deployment option for "just enough OS"
  • Shielded VM's and Host Guardian Service
  • Storage features, including Storage Spaces Direct and Storage Replica
  • New networking stack



免費電子書

在 4/20 時 Microsoft Press blog 也釋出 Free ebook: Introducing Windows Server 2016 Technical Preview 免費電子書。



其它參考資源


書籍簡介

在本書中,我們將會指導你如何規劃及調校 VMware vSphere 5.x / 6.x 的基礎架構。我們將會為你提供相關的專業知識及操作技巧,以便引導你順利建構高可用性、高效能的 VMware vSphere 虛擬化基礎架構。同時,我們將會一步一步帶領你進行操作並輔以畫面截圖,這些資訊在原廠的產品手冊中是不可能找到的。

你將會學習到如何在企業級的運作環境中,組態配置及管理 ESXi 主機的 CPU、Memory、Networking、Storage…等各項資源。此外,你也將會學習到如何管理及調整 vSphere 運作環境,以及如何針對 vSphere 各項運作元件進行效能最佳化的調校技巧。

本書的主要價值,在於深入剖析以往最容易被 vSphere 管理人員忽視的效能議題,例如,CPU 排程機制與 NUMA 感知能力、VMM 排程機制、運算核心共享機制、虛擬記憶體回收機制、總合檢查碼卸載資訊、VMDirectPath I/O、儲存設備中的佇列、指令佇列、規劃及設計 vCenter Server、VM 虛擬主機及應用程式的效能規劃…等,超過 60 項實用的效能最佳化技巧。

誰適合閱讀此書

本書是針對具有 VMware 相關操作及管理經驗的技術人員,希望多加了解 vSphere 5.x、6.x 運作效能最佳化調校,以及希望能夠增進 VMware 系統管理技能的人而寫。


網路購書



你將會從本書中學習到:

  • 了解 VMM 排程機制、CPU 排程機制、NUMA 感知機制、HT 超執行緒核心共享機制…等,有關 CPU 運作效能的最佳化設計,同時幫助你快速找到效能瓶頸。 
  • 了解虛擬記憶體回收技術、監控 ESXi 主機的 Ballooning 運作狀態、Swapping 運作狀態…等,有關 Memory 空間規劃的最佳準則,同時幫助你找出佔用記憶體資源的兇手。
  • 了解 vSwitch 負載平衡機制、VMDirectPath I/O、NetQueue、NIOC 流量管控…等,有關 Networking 網路頻寬流量設計的最佳準則。 
  • 了解儲存設備佇列、DRS/SDRS 演算法、資源集區、SIOC 門檻值、DRS/SDRS 的 Affinity/Anti-Affinity 規則…等,有關 Storage 儲存效能的最佳化設計,同時幫你找出 IOPS 儲存資源的效能瓶頸。 
  • 了解 vSphere Cluster 的 Scale Up/Out 運作架構,以及 vSphere HA、vSphere FT、DPM…等,有關基礎運作架構高可用性、高擴充性的最佳化設計準則。



本書導讀

  • 《第 1 章、CPU 效能規劃》,本章內容將深入剖析 VMM 排程機制、CPU 排程機制、快取感知、超執行緒核心共享機制、Ready Time (%RDY)…等議題。
  • 《第 2 章、Memory 效能規劃》,本章內容將深入剖析虛擬記憶體回收機制、如何正確規劃 VM 虛擬主機記憶體、監控 Host Ballooning 運作狀態、了解 Swapping 運作狀態…等議題。
  • 《第3章、Networking效能規劃》,本章內容將深入剖析 vSwitch 負載平衡機制、考量是否選用總和檢查碼卸載機制、VMDirectPath I/O、NetQueue、在 Multicast 網路環境中採用 SplitRx 模式、規劃 vMotion 使用多張網路卡、NIOC 網路流量管控機制…等議題。
  • 《第 4 章、規劃 DRS, SDRS, Resource Control》,本章內容將深入剖析 DRS 演算法準則、Resource Pool 準則、考量 SIOC 門檻值、Profile Driven Storage、SDRS、Affinity / Anti-Affinity 規則…等議題。
  • 《第 5 章、規劃 vSphere Cluster》,本章內容將深入剖析如何垂直或水平擴充叢集規模、使用 FT(Fault Tolerance) 的注意事項、應用程式監控機制、DPM、Host Affinity / Anti-Affinity 規則…等議題。
  • 《第 6 章、Storage 效能規劃》,本章內容將深入剖析如何規劃用於各種工作負載的 vSphere 儲存資源,如何規劃及設計出最佳效能的 iSCSI、FC 儲存設備,以及考量使用 VAAI 以提升儲存效能…等議題。
  • 《第 7 章、vCenter 及 vCenter 資料庫最佳效能規劃》,本章內容將深入剖析如何規劃你的 vCenter Server、具備容錯機制的 vCenter、具備高可用性的 Auto Deploy、vCenter SSO 及如何進行部署…等議題。
  • 《第 8 章、VM 虛擬主機及應用程式效能規劃》,本章內容將深入剖析 VM 虛擬主機正確的系統時間、考量 Virtual NUMA 機制、VM SWAP 檔案存放位置最佳建議…等議題。

前言

微軟新世代 Windows Server 2016 雲端作業系統,在 2014 年 10 月 1 日時正式發佈第一版的「技術預覽(Technical Preview,TP1)」版本,接著在 2015 年 5 月發佈 TP2 技術預覽版本、2015 年 8 月發佈 TP3 技術預覽版本。最新版本,則是在 2015 年 11 月時所發佈的 TP4 技術預覽版本。

系列文章

站長與 TechNet 台灣部落格 合作,撰寫 Windows Server 2016 攻略連載文章將分為 Compute / Storage / Network 三大主題 (共 8 篇文章):

【Compute】


【Storage】


【Network】


網管人雜誌

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

文章目錄

1、前言
2、VDI 大型架構規劃
          硬體資源架構規劃
          軟體資源架構規劃
3、VDI 虛擬桌面佈建效能測試
4、結語


1、前言

VMware 的 VDI 桌面虛擬化解決方案,從早期 2008 年開始發行的 VMware View Manager 3 版本,經過多年的演變已經是非常成熟的解決方案,最新穩定版本為 2015 年 9 月發佈的 VMware Horizon 6.2,除了相關特色功能不斷增強之外對於其它非 Windows 作業系統,例如,Linux 也不斷提升支援度。

隨著 VMware 軟體定義儲存技術 VSAN(Virtual SAN)不斷發展,新版的 VMware Horizon 也能整合最新版本的 Virtual SAN 6.1 一起協同運作,擔任 VDI 虛擬桌面的儲存資源。那麼,讓我們來看看 VMware Horizon 6.2 版本,以及在 2015 年 12 月推出的 VMware Horizon 6.2.1 修正版本中,有哪些重要的特色功能:

  • 支援 Windows 10: 支援 Windows 10 作業系統為 VDI 虛擬桌面,同時 Horizon Client 應用程式及 Smart Card 裝置也都支援。
  • 支援 RDS Desktops: View Composer 伺服器角色及 Linked Clones 機制,現在都可以管理及支援 RDS Desktops,同時 vDGA 及 GRID vGPU 等 3D 繪圖機制也能與 RDS Desktops 整合。
  • 單向 AD 信任: 支援「單向 AD 信任網域」機制,有效解決 VDI 虛擬桌面與 Windows AD 網域環境的信任關係,無須像舊版一樣讓 View Connection Server 處於外部網域環境中。
  • 支援 Virtual SAN 6.1: 支援以 vSphere 6.0 環境搭建的 All-Flash VSAN 運作架構,同時也支援以 vSphere 6.0 U1 版本搭建的 Stretched Cluster 運作架構,提供更大的高可用性及彈性。
  • 整合 Access Point: 提供 DMZ Gateway 與 View Connection Server 之間的連線,讓使用者方便從網際網路透過 Smart Card 驗證機制,便能輕鬆連接至 VDI 虛擬桌面。同時,也支援「聯邦資訊處理標準(Federal Information Processing Standards,FIPS)」機制,以提供更高的安全性。
  • 3D 繪圖機制增強: 除了支援 NVIDIA 的 vSGA、vDGA、vGPU 之外,現在採用 AMD GPU 顯示卡也可以運作 vSGA、vDGA 等 3D 繪圖機制,並且也支援 4K 解析度螢幕(3840 x 2160)。
  • Linux 桌面支援度增強: 支援剪貼簿及 Smart Card 重新導向及 SSO 單一簽入機制之外,採用 RHEL 7.1 及 Ubuntu 14.04 等新版 Linux 作業系統時,將可支援 NVIDIA GRID vGPU、vSGA 等 3D 繪圖機制。

圖 1、VMware Horizon 6 系統運作架構示意圖


2、VDI 大型架構規劃

本文,將說明及建議當企業或組織需要規劃 VDI 大型運作架構時,不論在硬體伺服器規格或 VMware Horizon 管理用途角色方面,應該如何規劃才能達到最佳運作效能並有效提升使用者操作體驗。

此 VDI 大型運作架構中 VDI 使用者數量為 960 位,其中以 Linked-Clone 機制建立的 VDI 虛擬桌面有 700 台,而 RDSH 機制所承載的虛擬桌面則為 260 台。只要根據本文的 VDI 參考建議進行規劃,即可規劃出 700 台 VDI 虛擬桌面只要花費 60 分鐘即可佈建完畢,並且當擔任儲存資源的 Virutal SAN 節點主機發生故障損壞事件時,只要花費 2 分鐘時間即可復原 VDI 虛擬桌面連線的運作架構。

圖 2、大型 VDI 運作架構效能測試參考數據


硬體資源架構規劃

有鑑於運作數量龐大的 VDI 虛擬桌面,因此在硬體資源架構的規劃上將會分開管理以避免互相影響,在 VMware Horizon 的運作架構中,每一個「View Pod」最大可以支援多達 10,000 位使用者或工作階段(Session)。

因此,在本文的架構中只要一個 View Pod 即可承載,但是在 View Pod 當中會將 VMware Horizon 架構內擔任管理角色的主機,例如,vCenter Server、Connection Server、Composer Server 等運作在「Management Block」,而屆時的 960 台 VDI 虛擬桌面則運作在「Desktop Block」當中。

圖 3、大型 VDI 運作架構 View Pod 及 Block 規劃示意圖

Management Block 硬體伺服器規劃
在 Management Block 運作架構中,需要二台實體伺服器以避免發生故障損壞事件時產生 SPOF 單點失敗的問題,每台實體伺服器應配置 2 顆 CPU 處理器,並且建議採用 Intel Xeon E5 家族且至少 8 核心以上,記憶體的部分則至少應配置 256 GB,以及配置 1 張 2 Port 的 10 Gbps 網卡

雖然,在 View Pod 的運作架構中可支援多達 10,000 台 VDI 虛擬桌面主機,但是「每一台」vCenter Server、View Connection Sever、View Security Server,建議管理的 VDI 虛擬桌面主機數量為 2,000 台比較適當,主要是為了效能以及操作時間上的考量。

此外,單台 Worksspace vApp 便可以承載 30,000 使用者,單台 vRealize Operations Manager vApp 便能承載 10,000 VDI 虛擬桌面主機,單台 App Volumes Manager Server 便能承載 10,000 使用者。但是,在管理主機方面為了避免發生 SPOF 單點失敗的問題,因此每台管理主機至少都建立 2 台以達成負載平衡及容錯備援機制。

圖 4、View Management Block 運作架構規劃示意圖

Desktop Block 硬體伺服器規劃
在 Desktop Block 運作架構中,除了 vCenter Server 與 Management Block 分開之外,也建立二個不同的 Cluster。首先,Virtual SAN Cluster 負責 700 台 VDI 虛擬桌面的部分由 7 台實體伺服器組成,每台實體伺服器配置 2 顆 CPU 處理器,並且建議採用 Intel Xeon E5 家族且至少 12 核心以上,記憶體的部分則至少應配置 256 GB,以及配置 1 張 2 Port 的 10 Gbps 網卡

此外,這 7 台實體伺服器將會建立 Virtual SAN 運作環境,以便擔任 700 台 VDI 虛擬桌面的儲存資源(每台 VDI 虛擬桌面配置 1 vCPU、2 GB RAM),所以每台伺服器還配置了 1 顆 400GB SSD 以及 6 顆 600GB SAS 硬碟。

圖 5、Virtual SAN Cluster 硬體伺服器配置建議

RDSH Cluster 的部分,負責提供屆時 260 RDSH 虛擬桌面工作階段,並且需要二台實體伺服器以避免發生故障損壞事件時產生 SPOF 單點失敗的問題,每台實體伺服器應配置 2 顆 CPU 處理器,並且建議採用 Intel Xeon E5 家族且至少 8 核心以上,記憶體的部分則至少應配置 256 GB,以及配置 1 張 2 Port 的 10 Gbps 網卡。此外,因為 RDSH Cluster 內的叢集節點主機,屆時將存放 AppVolumes AppStacks 等資料,所以每台伺服器還配置了 2 張 1.6TB PCIe SSD。

圖 6、View Desktop Block 運作架構規劃示意圖


軟體資源架構規劃

整體運作的硬體資源架構規劃完成後接著規劃軟體資源的部分,在 VMware Horizon 的運作架構中,需要建置的角色共有 ESXi 虛擬化平台、vCenter Server,除此之外還需要 Windows AD 網域環境、View Connection Server、View Composer Server、WorkSpace、vRealize Operations...等。

圖 7、軟體資源規劃架構示意圖

vCenter Server
在線上營運環境中,VMware 官方建議應該將擔任管理任務的 VM 虛擬主機,以及擔任 VDI 虛擬桌面的 VM 虛擬主機,分別建置「不同台」vCenter Server 分開進行管理,除了避免運作架構(例如,虛擬網路)複雜化之外,在管理思維上也可以避免 SPOF 單點失敗的影響,舉例來說,若管理 VDI 虛擬桌面環境的 vCenter Server 發生故障損壞事件,短期之間難以修復的話可以先讓管理環境的 vCenter Server 暫時接手管理作業。

此外,雖然每台 vCenter Server 可以管理最多 1,000 ESXi 主機及 10,000 台 VM 虛擬主機,但是有鑑於組態配置及高可用性管理需求,最佳建議為每台 vCenter Server 管理數量 2,000 台 VDI 虛擬桌面。這樣的管理規模大小,建議為 vCenter Server 配置的資源如下:

  • 作業系統: Windows Server 2012 R2
  • vCPU: 4 vCPU
  • vRAM: 24 GB
  • Storage: 100 GB


vSphere Cluster
在此次的 VDI 大型運作架構中,將規劃建立 3 個 vSphere Cluster 並分別由 2 台 vCenter Server 進行管理,第 1 個 vSphere Cluster 為「Management」,此 Cluster 由 2 台 ESXi 主機組成並且運作所有擔任管理任務的VM虛擬主機,並且此 Cluster 必須啟用「vSphere HA」及「DRS」機制,以維持管理用途的 VM 虛擬主機負載平衡及服務高可用性。

第 2 個 vSphere Cluster 為「Desktop」,此 Cluster 由 7 台 ESXi 主機組成並且運作 700 台 VDI 虛擬桌面主機,規劃每台 ESXi 主機將運作 100 台 VDI 虛擬桌面主機,值得注意的是此 Cluster 只啟用「DRS」機制進行負載平衡機制即可。不建議啟用 vSphere HA 高可用性機制的原因在於,每台 ESXi 主機已經都運作 100 台 VDI 虛擬桌面主機,倘若啟用 vSphere HA 機制當某台 ESXi 主機發生故障損壞情況時,將會造成其它 ESXi 主機的工作負載瞬間加重,因此在此 Cluster 當中並不建議開啟 vSphere HA 機制。

第 3 個 vSphere Cluster 為「RDSH」,此 Cluster 由 2 台 ESXi 主機組成並且運作 260 RDSH 虛擬桌面工作階段,同時在這個 Cluster 當中「不啟用」vSphere HA 高可用性及 DRS 負載平衡機制。

ESXi 主機 – CPU 使用率估算
有經驗的管理人員對於每台 ESXi 主機,應該已經好奇是否能夠順利運作 100 台 VDI 虛擬桌面,讓我們來看看承載 100 台 VDI 虛擬桌面這預估數字是怎麼來的。首先,我們為每台 VDI 虛擬桌面配置 1 vCPU,並且使用 350 MHz 的 CPU 運算資源,同時預估 vCPU 額外負載為 10%。

在 ESXi 主機的部分總共有 7 台實體伺服器,每台伺服器配置 2 顆 CPU 處理器且每顆處理器擁有 12 顆運算核心,每個運算核心的時脈為 2.7 GHz,所以每顆 CPU 擁有 32.4 GHz 的運算能力,每台 ESXi 主機擁有 64.8 GHz 的運算能力,然後扣除 ESXi 運作 Virtual SAN 的額外負載 10 % 之後,保留 80 % 的運算能力也就是「46.65 GHz」。因此,每台 ESXi 主機在 CPU 運算能力方面的使用率,可以運作這樣的 VDI 虛擬桌面超過 100 台。

圖 8、ESXi 主機 – CPU 使用率估算

ESXi 主機 – Memory 使用率估算
同樣的,我們預計每台 VDI 虛擬桌面,運作 Windows 7 作業系統(32 位元)及使用 1920x1600 解析度,並且配置 2 GB 記憶體空間,每台 VDI 虛擬桌面的 vRAM 額外負載為 41 MB,未設定「Memory Reservation」記憶體空間預先保留機制。

在 ESXi 主機的部分總共有 7 台實體伺服器,每台伺服器配置 256 GB 記憶體空間,扣除運作 100 台 VDI 虛擬桌面所需記憶體空間 204 GB,以及 ESXi 運作 Virtual SAN 的額外負載 5 GB 之後,保留 80 % 的記憶體使用率之後,每台 ESXi 主機在記憶體方面的使用率,可以運作這樣的 VDI 虛擬桌面超過 100 台。

圖 9、ESXi主機 – Memory 使用率估算

ESXi 主機 – 虛擬網路規劃
有鑑於要管理的 ESXi 主機數量不少,因此並不適合使用標準型交換器 vSS(vNetwork Standard Switch),建議採用分佈式交換器 vDS(vNetwork Distributed Switch),否則將會造成營運管理上很大的負擔,舉例來說,在本文的運作架構中共有 11 台 ESXi 主機,當需要變更某個虛擬交換器名稱時,在 vDS 環境中只要修改一次即可,但在 vSS 環境中就必須要修改 11 次(逐台修改)。

此外,在每台 ESXi 主機上皆配置 1 張 2 Port 的 10 Gbps 網路卡,分別連接到不同台實體網路交換器上,以避免網路卡或網路交換器發生故障損壞事件造成 SPOF 單點失敗的問題,並且規劃出「四種」依不同網路流量的 Port Group,以便搭配 vDS 當中的 NIOC(Network I/O Control)網路流量管控機制,同時也便於管理人員掌握各種網路流量的傳輸情況以利故障排除作業。

  • Management: ESXi 主機的管理流量。
  • VMNet: 管理用途的 VM 虛擬主機對外流量,以及 VDI 虛擬桌面對外提供服務的流量。
  • Storage: Virtual SAN 儲存網路傳輸流量。
  • vMotion: 用於 vSphere vMotion 線上即時遷移 VM 虛擬主機的傳輸流量。

圖 10、針對不同用途的網路流量規劃出四種 Port Group

View – Connection / Security Server
在 Horiozn 運作架構中 Connection Server,為負責擔任「代理人(Broker)」的角色,在平常運作時 VDI 虛擬桌面透過「代理程式(Agent)」,隨時將目前的運作狀況回報給 Connection Server,如此一來 Connection Server 便能得知每台 VDI 虛擬桌面的狀態,例如,桌面目前狀態為可用、更新中、重開機中...等。

Security Server 的部分因為會直接接觸到網際網路來的 VDI 連線需求,所以會置放於「非軍事區 DMZ(Demilitarized Zone)」,並且此台主機不會加入 Windows AD 網域中,同時視連線需求在第一道防火牆中開啟相關連接埠號,舉例來說,開啟 Port 443 以允許 HTTPs 流量通過,開啟 Port 4172 以允許 PCoIP 流量通過。詳細的防火牆連接埠號,請參考 VMware KB 102676620619131027217 及相關文件。

此外,VMware 官方的最佳建議為,每台 View Connection Server 及 View Security Server 管理數量 2,000 台 VDI 虛擬桌面。同時,為了達成服務的負載平衡及高可用性考量,在本文規劃環境中將建置 4 台 View Connection Server 及 2 台 View Security Server,每台主機的建議配置資源如下:

  • 作業系統: Windows Server 2012 R2
  • vCPU: 4 vCPU
  • vRAM: 16 GB
  • Storage: 50 GB

圖 11、View Connection / Security 運作架構示意圖

View – Composer Server
在 Horiozn 運作架構中 Composer Server,提供的「連結複製(Linked Virtual Machine Clones)」機制,它會為每個 VM 虛擬主機建立「唯一指標(Unique Pointers)」,因此每台 VM 虛擬主機所佔用的空間只有「差異」的部份而以,與 Master Image 佔用空間相較之下通常可以減少 50 ~ 70 % 的空間大小。

圖 12、VDI 虛擬桌面範本運作機制示意圖

當您將 VDI 虛擬桌面架構中,相關伺服器角色安裝及設定完成後,便可以登入 Horizon View Administrator 管理介面(安裝完 Connection 伺服器角色後便具備),新增 vCenter 及 Composer 伺服器資訊,以利後續 VDI 虛擬桌面的佈建作業。登入管理介面後,請依序點選「View 組態 > 伺服器 > vCenter Server > 新增」,在彈出的新增 vCenter Server 視窗中,填入 vCenter 伺服器管理者資訊。

預設情況下,進階設定內的並行作業設定值為「20、50、12、8」,但在本文的規劃運作架構中建議更改為「30、50、30、30」,以達成一開始所預估的目標佈建 700 台 VDI 虛擬桌面只要花費 60 分鐘即可部署完畢。

圖 13、準備進行 vCenter 及 Composer 匹配作業

最後,在儲存空間設定頁面中,記得勾選「回收虛擬機器磁碟空間」或「啟用 View 儲存加速器」等功能。從 VMware vSphere 5.0 版本開始,便支援 ESXi Host Caching 機制「CBRC(Content-Based Read Cache)」,是 VMware vSphere 內建的「讀取快取」機制,並且從舊版 VMware View 5.1 版本便開始支援及整合此功能,當然最新版本的 Horizon 6.2 也支援整合將底層的 ESXi Host Caching CBRC 機制整合進來,稱之為「View 儲存加速器(View Storage Accelerator)」特色功能。

圖 14、每台負責運作 VDI 虛擬桌面的 ESXi 主機,都應啟用 View 儲存加速器機制

View – App Volumes
透過 App Volumes 機制可以有效整合,使用者端所使用的應用程式、資料檔案、環境設定並整合 Windows AD 網域環境,達成快速佈建企業或組織常用的應用程式至 VDI 虛擬桌面當中,並且除了整合 VDI 虛擬桌面之外,也可以整合 RDSH 工作階段。

圖 15、App Volumes 運作架構示意圖

值得注意的是,在本文大型 VDI 運作架構下,因為必須針對數量龐大的 VDI 虛擬桌面進行操作,因此建議修改 App Volumes Manager 的 VM 組態重新設定的逾期時間,請登入 App Volumes Manager 主機,建立新的環境變數名稱為「CV_RECONFIG_TIMEOUT」,並且指定「600」秒的組態重新設定逾期時間(若未重新指定,預設值為 300 秒)。設定後請重新啟動 App Volumes Manager 服務,以便新指定的 VM 組態重新設定逾期時間能夠套用生效。

圖 16、重新指定 VM 組態重新設定逾期時間為 600 秒

Windows AD 網域
以往在建構 vSphere 伺服器虛擬化環境時,可以選擇要或不要建置 Windows AD 網域環境。但是,當你需要建構 Horizon VDI 虛擬桌面環境時,因為 VDI 虛擬桌面通常採用 Windows 作業系統,因此「必須」要建置 Windows AD 網域環境,以便透過 Windows AD 網域的網域控制站 DC(Domain Controller),來達成使用者「驗證(Authentication) / 授權(Authorization)」的機制。

在本文實作環境中,額外建立 HorizonView-Test OU 容器,並且於其下再建立 Virtual Desktops、RDSH Servers 等二個子 OU 容器,以便存放 VDI 虛擬桌面及 RDSH 的電腦帳戶,以及針對不同虛擬桌面特色客製化而成的 GPO 群組原則。

圖 17、Windows AD 網域 OU 容器規劃示意圖


3、VDI 虛擬桌面佈建效能測試

經過上述硬體伺服器及 Horizon 軟體運作元件的適當規劃後,接著我們透過 View Planner 效能測試工具,來驗證在 Virtual SAN 儲存資源中佈建 700 台 Linked-Clone 的 VDI 虛擬桌面的運作情況。

在 Desktop Cluster 當中,將透過 View Composer Server 佈建 700 台 Windows 7(32 位元)的 VDI 虛擬桌面,每台 ESXi 成員主機將會佈建 100 台 VDI 虛擬桌面。首先,View Composer Server 將會在 Virtual SAN Datastore 中建立 24 GB 的 Replica Base Image,接著透過 Linked-Clone 機制大量產生 VDI 虛擬桌面,並且加入 Windows AD 網域當中,最後透過 Agent 通知 View Connection Server 狀態為可用(可進行連接),整個效能測試的結果一共花費「60 分 54 秒」。

圖 18、在 Virtual SAN 儲存資源中佈建 700 台 VDI 虛擬桌面的測試數據


4、結語

透過本文的說明,從硬體伺服器的資源配置到 Horizon 軟體元件的角色規劃,相信讀者已經了解到如何規劃及建置大型 VDI 運作架構,同時整合 VSAN 軟體定義儲存技術,提供數量龐大的 VDI 虛擬桌面當儲存資源,仍然能夠在佈建時快速完成部署作業。

因此,透過本篇文章的說明及實務建議,希望能夠協助讀者建置完整的 VDI 虛擬桌面運作架構,以便有效管理上百上千台 VDI 虛擬桌面,同時方便企業或組織進行 VDI 環境的導入評估及測試作業。