不自量力の Weithenn

網管人雜誌

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

文章目錄

1、前言
2、VSAN 6.1 新功能概要
延伸叢集（Stretched Cluster）
  支援 2 Nodes 運作架構
  整合 vSphere Replication 及 SRM
  支援 SMP-FT
  支援 Microsoft WSFC 及 Oracle RAC
  支援 DIMM / NVMe SSD
  新式 On-Disk 格式
  健康狀態檢查外掛程式
  整合 vRealize Operations
3、VSAN 延伸叢集最佳實務建議
  見證主機（Witness Host）
  網路環境需求
  ESXi Host 與 VM 虛擬主機
  傳統叢集 vs 延伸叢集
4、結語

1、前言

在 2014 年 3 月時，VMware 官方正式釋出 vSphere 5.5 Update 1 版本，同時宣佈在此版本中的 vSphere 開始內建 VMware Virtual SAN 1.0的版本。

隔年 2015 年 3 月時，隨著最新版本 VMware vSphere ESXi 6.0 的發佈，與 VMware vSphere Kernel 整合的 VSAN（Virtual SAN）技術，也從先前 VSAN 1.0 版本（原訂新版本為 VSAN 2.0），直接與 vSphere 最新版本對齊成為 VSAN 6.0版本。

目前，最新的 VSAN 6.1 版本為 2015 年 9 月時推出，此版本當中的重要特色功能如下：

延伸叢集（Stretched Cluster）： 突破傳統的 VMware Cluster 限制，能夠建立延伸叢集以同步複寫資料至不同地點的兩個站台之間。
支援 2 Nodes VSAN 運作架構：支援 2 Nodes VSAN 運作架構，以便企業或組織在遠端 IT 伺服器機房中，部署高可用性且具成本效益的「超融式（Hyper-Converged）」解決方案。
整合 vSphere Replication 及 SRM：可以在延伸叢集運作架構當中，整合 vSphere Replication 及 SRM 特色功能提供異地備援機制。
支援 SMP-FT：支援 vSphere 6.0 版本當中，VM 虛擬主機需要多顆 vCPU 並啟用 FT（Fault Tolerance）的 SMP-FT 機制。
支援 Microsoft WSFC 及 Oracle RAC：支援 Microsoft WSFC（Windows Server Failover Clustering），以及 Oracle RAC（Real Application Clusters）等應用程式高可用性機制。
支援 DIMM / NVMe SSD：支援 DIMM-Based 的 SSD 固態硬碟，提供小於 5 us 的資料寫入延遲時間，並且也支援新式的 NVMe SSD 固態硬碟。
新式 On-Disk 格式：在舊有的 VSAN 版本中為 1.0，現在則採用新式的 2.0 格式。
健康狀態檢查外掛程式（Health Check Plug-in）：有效協助管理人員進行硬體、韌體、驅動程式相容性檢查、網路即時診斷機制…等，同時能夠確保整個 VSAN 叢集內所有進階組態設定的一致性。
整合 vRealize Operations：透過 VSAN Management Pack，便能與 vRealize Operations 整合在一起，提供管理人員對於 VSAN 叢集及運作狀態進行更進一步的監控作業。
支援 Docker / Containers：現在，VSAN Datastore 資料儲存區，也可以支援 Docker/Containers 運作機制。

圖 1、Virtual SAN 6.1 新功能概要示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

2、VSAN 6.1 新功能概要

首先，VSAN（Virtual SAN）是由 VMware 所發展「軟體定義儲存（Software-Defined Storage，SDS）」技術，它能夠將多台 x86 伺服器上的「本機儲存資源（Local Storage）」，串連起來變成一個伺服器彼此之間共享的儲存空間，同時透過多台 x86 伺服器上的 SSD 固態硬碟快速存取特性，提升 VSAN 整體運作環境的資料 I/O 效能，然後以一般機械式硬碟大容量的儲存空間來儲存資料。

SDS 軟體定義儲存的一個關鍵因素，就是提供以原則為方式的儲存管理機制（Storage Policy-Based Management，SPBM）。事實上，在 vSphere 5.0版本時，就已經導入到 VMware Storage Profile 儲存管理概念當中，並且在 vSphere 5.5版本時成為關鍵性的特色功能，也是 VMware 達成軟體定義儲存的關鍵。

透過 SPBM 及 vSphere API 機制，將儲存資源抽象化並整合為資源池之後，便能提供 vSphere管理人員佈建 VM 虛擬主機的能力，佈建的機制包含效能、可用性、儲存服務（精簡配置、壓縮、複本…等）。然後，針對不同的 VM 虛擬主機服務等級，採用不同的 VM 虛擬主機儲存原則（VM Storage Policy），進行 VM 虛擬主機的佈建動作，也就是透過 SPBM 儲存管理機制，將 VM 虛擬主機進行適當的擺放。

VSAN 已經深度整合在 vSphere 當中，並具備 SPBM 儲存管理機制，因此佈建後的 VM 虛擬主機，隨著時間及服務項目的增長，工作負載與資料 I/O 都逐漸成長而不敷使用時，只需要套用新的 VM 虛擬主機儲存原則之後，無須 vSphere 管理人員手動介入，便會在背景自動執行且無縫式的調整完畢（相較於傳統儲存設備，管理人員必須人為介入，為 VM 虛擬主機掛載及卸載虛擬磁碟…等手動作業）。

圖 2、VMware VSAN 軟體定義儲存概念示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

延伸叢集（Stretched Cluster）

從 VSAN 6.1版本開始，正式支援「延伸叢集（Stretched Cluster）」運作架構。現在，管理人員可以在兩個不同的地理位置或站台之間，建立 VSAN 延伸叢集運作架構以便在這兩個站台之間同步彼此的資料，有效解決過去傳統 VMware Cluster 單一站台失敗的問題。

在過去傳統 VMware Cluster 運作架構中，若是發生大規模的故障損壞事件（例如，機房電力非預期斷電、人為操作疏失…等），或是遭遇到天然災害（例如，颱風、洪水、地震...等），造成企業或組織當中主要資料中心停止服務時，倘若平時並沒有做好異地資料同步及備援的工作時，將會嚴重影響企業及組織的 RPO（Recovery Point to Object）及 RTO（Recovery Time to Object）。

現在，透過 VSAN 延伸叢集機制，在平台除了可以透過 VMware vMotion及 vSphere DRS機制，進行兩地站台之間工作負載自動平衡的作業之外，在發生單一站台大規模的故障損壞事件時，也可以整合原有的 VMware vSphere HA機制來進行因應，有效提升企業或組織整體的 RPO 及 RTO 表現。

圖 3、VMware VSAN 延伸叢集（Stretched Cluster）運作架構示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

支援 2 Nodes 運作架構

從 VSAN 1.0版本開始，在 VSAN 的運作架構中一直以來節點主機的最小需求為「3 Nodes」，才可以建置 VSAN Cluster。(請注意!!在VSAN 1.0版本當中，VSAN Cluster 規模最多支援至 32台 Nodes。在 VSAN 6.0、6.1版本當中，VSAN Cluster 規模最多支援至 64台 Nodes)。

現在，最新版本的 VSAN 6.1版本當中，為了因應 ROBO（Remote Office / Branch Office）需求，也就是企業或組織當中遠端辦公室或分支辦公室的小型儲存資源需求。因此，管理人員可以在各分支辦公室中建立「2 Nodes」的 VSAN Cluster，然後在母公司以 1 台 vCenter Server 統一進行管理。

圖 4、VMware VSAN ROBO 運作架構示意圖

圖片來源： VMware Blog – VMware Virtual SAN ROBO Edition

整合 vSphere Replication 及 SRM

現在，在新式的 VSAN 延伸叢集運作架構當中，原有的 vSphere Replication 及 SRM（Site Recovery Manager）異地備援機制，也已經可以跟新式的 VSAN 延伸叢集協同運作，讓企業或組織不會因為採用新式的 VSAN 延伸叢集運作架構，而失去原有異地備援機制的彈性。

圖 5、VMware VSAN 延伸叢集與 vSphere Replication 及 SRM 協同運作架構示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

支援 SMP-FT

從 vSphere 6.0 版本開始，啟用「FT（Fault Tolerance）」特色功能的 VM 虛擬主機，其 vCPU的數量最多可以支援至「4 vCPU」，也就是「SMP-FT（Multi-Processor Fault Tolerance）」運作機制。(請注意!! 必須採用 ESXi Enterprise Plus 授權版本才能支援至最大 4 vCPU，若採用的是 ESXi Standard / Enterprise授權版本的話，那麼最多只能支援至 2 vCPU 而已。)

但是，在 VSAN 6.0 版本中並無法與 vSphere 6.0 當中的 SMP-FT 機制協同運作。現在，最新的 VSAN 6.1版本已經能夠與 SMP-FT 機制協同運作，順利運作 4 vCPU的 VM 虛擬主機。

圖 6、VMware VSAN 與 SMP-FT 機制協同運作示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

支援 Microsoft WSFC 及 Oracle RAC

此外，在 VSAN 6.1運作環境中運作的 VM 虛擬主機，現在也完全支援 Microsoft 及 Oracle 叢集技術。簡單來說，現在運作於 VSAN Datastore 的 VM 虛擬主機，可以順利建構 Microsoft WSFC（Windows Server Failover Clustering）及 Oracle RAC（Real Application Clusters）等叢集架構，達成 Application Level 的高可用性機制，以便補足 Host Level 高可用性機制 SMP-FT 的不足。

事實上，在 VSAN 6.0 版本時也有支援 Oracle RAC 高可用性機制，但是有較多的相關限制及注意事項，詳細資訊請參考 VMware KB 2121181，至於 Microsoft WSFC 的部分，詳細資訊請參考 VMware KB 1004617。

圖 7、VMware VSAN Datastore 支援 VM 虛擬主機建立 Microsoft WSFC 及 Oracle RAC

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

支援 DIMM / NVMe SSD

過去，在 VSAN 1.0 及 6.0 版本當中，擔任資料「讀取（Read）/寫入（Write）」快取角色的 SSD固態硬碟部分，支援採用 SAS / SATA / PCIe 介面的 SSD 固態硬碟。現在，最新的 VSAN 6.1版本當中，支援兩種更快的傳輸介面分別是「NVMe（Non-Volatile Memory Express）及ULLtraDIMM」。

在 NVMe SSD固態硬碟的部分，透過此新式通訊介面可以提供 VSAN 更佳的運作效能，在VMware 官方的測試結果當中，可達每台 VSAN Node「10 萬 IOPS」，也就是在 32 Nodes 的 VSAN Cluster 運作架構中，提供高達「320 萬 IOPS」的儲存效能。

在 ULLtraDIMM SSD 固態硬碟的部分，此項技術是透過伺服器的「記憶體插槽（Memory DIMM Slots）」，達成「< 5 us」非常低的資料寫入延遲時間，並且可以最大化空間密度（All Flash 運作架構 VSAN 運作節點，單台空間最大可達 12 TB）。

圖 8、ULLtraDIMM SSD 固態硬碟特色功能示意圖

圖片來源： SINA SDC - New Fundamental Data, Storage and Device Technologies

新式 On-Disk 格式

在 VSAN 1.0 版本，也就是採用 vSphere 5.5的虛擬化平台運作架構，在這樣的運作架構中On-Disk 格式版本同樣為「1.0」。但是，新的 VSAN 6.1版本當中的 vSphere 6.x 虛擬化平台，已經轉換為 Virsto 技術的日誌型式檔案系統，來因應 VSAN 叢集高可擴充性、快照、複寫管理等需求。因此，你可以透過 vSphere Web Client 管理介面，將 On-Disk 磁碟格式線上升級為「2.0」版本。

圖 9、VSAN 6.1 版本 On-Disk 格式版本升級示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

此外，在 VSAN 節點主機當中硬碟宣告的部分，在 VSAN 6.0 時若採用 All-Flash 運作架構時，管理人員只能採用 CLI 指令的方式，手動指定採用的 Flash 裝置為「Capacity Tier」。現在，在 VSAN 6.1 版本當中，你在 vSphere Web Client 的管理介面中，便可以直接指定該硬碟是「Cache Tier 或 Capacity Tier」或者宣告該硬碟並非是 VSAN 的儲存資源。

圖 10、VSAN 6.1 可以管理介面中指定硬碟所擔任的儲存資源層級

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

健康狀態檢查外掛程式

在 VSAN 6.1 版本當中，管理人員可以在 vSphere Web Client 管理介面當中，查看 VSAN 組態設定、叢集、資料、網路、硬碟...等健康狀態。此健康狀態檢查外掛程式包含下列檢查項目：

硬體相容性檢查：檢查 x86 伺服器底層的硬體類型、韌體、驅動程式相容性檢查…等，以協助管理人員在進行建置 VSAN 運作架構之前，確認目前所使用的 x86 伺服器硬體是否適合建置。
硬體診斷：偵測在 VSAN 運作架構中是否存在硬體問題，例如，儲存設備的健康情況、VSAN節點的網路連接情況、ESXi Host 及 VSAN Cluster 的組態配置...等。
組態配置管理：確保在 VSAN Cluster 運作架構中，每台 VSAN 叢集節點的組態配置是否一致。
主動測試機制：提供管理人員隨時針對 VSAN Cluster 及運作元件進行測試作業。
VM 虛擬主機建立測試：測試在 VSAN Cluster 當中是否能順利建立 VM 虛擬主機。
多點傳播效能測試： VSAN Cluster 當中的叢集節點，採用「多點傳播（Multicast）」進行溝通及資料傳輸作業，此項測試可以提供 VSAN 叢集節點之間多點傳播的網路環境健康情況。
儲存資源效能測試：針對 VSAN Cluster 在大量 I/O 工作負載的情況下，VSAN 叢集節點的運作穩定性。

圖 11、VSAN 6.1 健康狀態檢查外掛程式管理介面

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

整合 vRealize Operations

事實上，在 vCenter Operations 5.8版本（vRealize Operations 舊稱）時，便開始支援 VSAN但並不完全，舉例來說，並無法看到 VSAN Datastore 的 Disk I/O。因此，在 VSAN 舊版的運作環境中，VMware 官方建議採用 RVC（Ruby vSphere Console）工具，來協助監控及分析 VSAN 運作狀態。

現在，在 VSAN 6.1新版本中，已經可以透過 VSAN Management Pack for vRealize Operations，讓 vRealize Operations 可以完整支援及監控 VSAN 運作環境，舉例來說，支援針對 VSAN Cluster環境的「監控 / 告警 / 通知」、針對 VSAN 叢集節點進行「CPU / Memory / Network」等效能監控、針對 VSAN 儲存資源進行容量的「規劃 / 預測 / 監控」...等。

圖 12、VSAN Management Pack for vRealize Operations 管理介面示意圖

圖片來源： VMware Documentation – What`s New : VMware Virtual SAN 6.1

3、VSAN 延伸叢集最佳實務建議

事實上，在 VSAN 1.0 版本時，許多管理人員便開始討論及嘗試實作「VSAN 延伸叢集（Stretched Cluster）」的可能性。現在，VSAN 6.1 版本正式支援此 Site Level 的高可用性機制，這也是 VSAN 6.1版本中最亮眼的特色功能。

圖 13、VMware VSAN 延伸叢集及整合主機運作架構示意圖

圖片來源： VMware 白皮書 – VSAN 6.1 Stretched Cluster Guide

見證主機（Witness Host）

那麼，在 VSAN 延伸叢集運作架構中，當其中一個站台發生重大故障損壞事件，導至該站台停止服務時系統是否何判斷的？若只是兩個站台之間發生網路中斷，但是兩個站台並沒有停止服務，此時會不會造成誤判產生「裂腦（Split-Brain）」的情況呢？

在 VSAN 6.1 的延伸叢集運作架構中，必須要在第三站台建立「見證主機（Witness Host）」，這台見證主機便是擔任兩個站台之間「仲裁（Quorum）」的角色，它可以是實體主機或 VM 虛擬主機，並且根據不同的運作架構規模大小，有不同的硬體需求建議：

小型規模（1 VMs ~ 10 VMs）

2 vCPU、8 GB vRAM
Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 15GB（1顆）
支援最多 750 見證元件

中型規模（10 VMs ~ 500 VMs）

2 vCPU、16 GB vRAM
Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 350GB（1顆）
支援最多 21,000 見證元件

大型規模（500 VMs以上）

2 vCPU、32 GB vRAM
Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 350GB（3顆）
支援最多 45,000 見證元件

網路環境需求

在 VSAN 延伸叢集運作架構當中，VSAN Cluster 及 VSAN Node 所處位置稱之為「資料站台（Data Sites）」，而見證主機所處位置則稱之為「見證站台（Witness Site）」。

在資料站台當中 VSAN Cluster 的 VSAN Node 彼此之間，採用「多點傳播（Multicast）」來傳輸中繼資料及運作狀態，以及採用「單點傳播（Unicast）」來傳輸資料 I/O 的部分。此外，資料站台與見證站台之間，則是透過「單點傳播（Unicast）」來互相進行溝通及存活偵測作業。

因此，在資料站台之間可以規劃採用「Layer 2 或 Layer 3」的網路環境彼此連接，並且網路延遲時間必須在「5 ms RTT（Round Trip Time）」以下才行，也就是說單向的網路延遲時間必須小於 2.5ms才行，並且網路頻寬建議至少採用「10 Gbps」。

在資料站台與見證站台之間則僅建議採用「Layer 3」網路環境，並且網路延遲時間不可以大於「200 ms RRT」，也就是單向網路延遲時間必須小於 100ms才行，並且網路頻寬建議至少採用「50 ~ 100Mbps」。

圖 14、VMware VSAN延伸叢集資料站台及見證站台的網路架構示意圖

圖片來源： VMware 白皮書 – VSAN 6.1 Stretched Cluster Guide

ESXi Host 與 VM 虛擬主機

值得注意的是，在 VSAN 延伸叢集運作架構當中，因為必須考量到其中一座資料站台完全下線的情況，因此 VMware 建議每座資料站台應僅運作 VM 虛擬主機總數的 50%即可，舉例來說，規劃的 VM 虛擬主機總數為 500台的話，那麼每座資料站台應僅運作 250 台 VM 虛擬主機即可，以便發生災難事件時另一座資料站台，可以完成承載所有的 VM 虛擬主機工作負載。

在 VSAN 延伸叢集當中 ESXi Host 的數量，最少數量的情況下為「3 台（1 + 1 + 1）」ESXi Host，也就是資料站台 A 運作 1 台 ESXi Host 資料站台 B 運作 1 台 ESXi Host，見證站台也運作 1 台ESXi Host。目前，在 VSAN 6.1 版本當中，最大的運作規模則建議為「31 台（15 + 15 + 1）」ESXi Host，也就是資料站台 A 運作 15 台 ESXi Host 資料站台 B 運作 15 台 ESXi Host，見證站台也運作 1 台 ESXi Host。

圖 15、VMware VSAN 3+3+1 延伸叢集運作架構示意圖

圖片來源： VMware 白皮書 – VSAN Stretched Cluster Performance and Best Practices

傳統叢集 vs 延伸叢集

最後，管理人員應該會好奇，在採用 VMware 傳統叢集來運作 VSAN 運作架構，以及新式的VSAN 延伸叢集架構，在 IOPS 儲存效能的表現上到底哪一種叢集比較出色。

在 VMware 官方測試結果當中可以得知，在採用 VMware 傳統叢集來運作 VSAN 運作架構時，由於是 VSAN Node 彼此在近端因此 IOPS 表現較好。當採用 VSAN 延伸叢集架構時，若資料站台之間的網路延遲時間為「1 ms」時，則 IOPS 相較於傳統叢集來說大約「降低20%」，若資料站台之間的網路延遲時間為「5 ms」時，則 IOPS 相較於傳統叢集來說大約「降低 35%」。

在資料「寫入延遲（Write Latency）」的部分，同樣的傳統叢集因為主機之間彼此在近端因此為「2.9ms」，而採用新式的 VSAN 延伸叢集架構時則分別是「4.9ms 及 7.7ms」，至於資料「讀取延遲（Read Latency）」的部分，兩種叢集架構的表現則是差不多的。

圖 16、VMware VSAN 傳統叢集與延伸叢集 IOPS 效能比較統計表

圖片來源： VMware 白皮書 – VSAN Stretched Cluster Performance and Best Practices

4、結語

透過本文的說明，相信讀者已經了解到最新的 VSAN 6.1 版本多了哪些特色功能，能夠幫助企業或組織提供更佳的高可用性機制。此外，在本文的後半部則給予 VSAN 6.1 新式延伸叢集架構的最佳實務建議，以便管理人員在前置作業流程時能夠注意相關細節，以便規劃出來的 VSAN 延伸叢集架構能為企業或組織提供最佳的運作彈性。

前言

簡單來說，如果你的實體伺服器是用傳統 BIOS的話，那麼使用 Windows 7 USB DVD Download Tool 工具，即可將開機及作業系統相關安裝檔案製作在 USB 隨身碟當中。

但是，如果你的實體伺服器是採用新式 UEFI 的話，那麼會發現用剛才 USB 製作工具所做出來的 USB 根本沒用，所以本篇筆記就出現了。簡單來說，要製作用於 UEFI系統的 USB 要注意下列事項：

USB 至少要 8GB (舉例來說，Windows Server 2016 TP4 的 ISO 映像檔已經 5GB 左右)
USB 必須要格式化為 FAT32檔案系統格式而非 NTFS。
USB 必須要採用 GPT而非傳統的 MBR。
複製 Windows ISO 映像檔內的檔案至 USB 當中，但是 install.wim會大於 4GB 而發生複製錯誤的情況，所以要使用 dism指令先切割成較小的檔案。

此 Bootable USB 製作方式，適用 Windows 版本如下：

Windows 8 / 8.1 / 10
Windows Server 2012 / 2012 R2 / 2016

實作步驟

首先，找一台 Windows 主機，依序鍵入下列指令處理 USB。值得注意的是，此次實作環境的 USB 是 16GB，倘若你的 USB 大於 16GB (例如，32GB) 的話，那麼在建立分割區時應該使用「create partition primary size=16000」，避免空間過大超過 FAT32 支援而執行指令失敗。

C:\> diskpart
DISKPART> list disk
DISKPART> select disk2
DISKPART> clean
DISKPART> convert gpt
DISKPART> create partition primary
DISKPART> format fs=FAT32 quick
DISKPART> assign letter=W
DISKPART> exit

完成上述設定並開啟「磁碟管理」之後，會發現 USB 已經格式化完成並使用 W:磁碟機代號。

此次實作環境為製作 Windows Server 2016 TP4 至 USB 當中，若直接複製 ISO 映像檔內的檔案時，會發生 install.wim 檔案太大而失敗的情況 (不管是用檔案總管或 xcopy 指令複製)。

此時，請先用 dism指令，將 install.wim檔案切割成較小的檔案時，FAT32 檔案系統便不會因為超過定址而發生複製失敗的情況了。假設，我已經先將 Windows Server 2016 TP4 ISO 映像檔，解壓縮後放到 C:\ISO 資料夾內，便可以執行如下指令切割 install.wim 檔案。

C:\> dism /split-image /imagefile:c:\iso\sources\install.wim /swmfile: c:\iso\sources\install.swm /filesize:3500 /checkintegrity

最後，就可以把 install.wim 檔案刪除 (留下剛才分割的 install.wsm、install2.wsm 即可)，然後利用檔案總管或指令「xcopy C:\iso\*.* /s /e /f W:\」。

網管人雜誌

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

文章目錄

1、前言
2、建立 Nano Server 映像檔
建立用於 VM 虛擬主機的 Nano Server
  建立用於實體主機的 Nano Server
  客製化 Nano Server 映像檔
3、本機管理 Nano Server
4、遠端管理 Nano Server
  伺服器管理員
  Windows PowerShell
  Windows PowerShell CIM
  Windows Remote Management
5、結語

1、前言

預計在 2016 年發佈，微軟新世代雲端作業系統 Windows Server 2016（先前開發代號為Windows Server vNext）當中，有項微軟針對雲端應用最佳化的極精簡伺服器版本「Nano Server」。它是在 Ignite 2015 年度技術大會上首度發表，也就是從 Windows Server 2016 TP2（第 2 版技術預覽版本）便開始新增的安裝選項。

簡單來說，在企業或組織當中的管理人員於先前的 Windows Server 版本當中，倘若希望能夠使用精簡的伺服器版本時可以採用「Server Core」版本，而 Nano Server 跟原有的 Server Core 運作概念相同，但是比起 Server Core 來說卻是更為精簡的版本。它沒有本地登入功能也不支援遠端桌面（RDP），同時也移除了非必要的運作元件，例如，GUI Stack、32 Bit（WOW64）、預設 Server Core 元件...等，並且僅支援 64 Bit 的應用程式、工具、代理程式。

此外，所有針對 Nano Server 必須透過 WMI、PowerShell、PowerShell DSC（Desired State Configuration）來進行遠端管理作業，或是透過 System Center 及其它管理工具。並且所有伺服器角色及功能也必須使用「部署映像服務與管理（Deployment Image Servicing and Management，DISM）」的方式來新增及安裝。

圖 1、Nano Server 運作架構示意圖

圖片來源： 2015 台灣微軟 IT 管理技術高峰論壇 – 下一代 Windows Server 2016 Hyper-V 虛擬化功能預覽

Nano Server 是以「雲端優先（Cloud-First）」為概念進行重構的伺服器版本，它支援運作「容器（Container）」環境（Windows Server Container 及 Hyper-V Container），並且支援多種程式語言，例如，C#、Java、Node.js、Python...等，同時也可以運作在「VM 虛擬主機（Virtual Machine）」、「實體伺服器（Physical Server）」環境中，並且運作 Hyper-V、SOFS（Scale-Out File Server）...等伺服器角色。

倘若將 Nano Server 與目前的 Windows Server 運作環境互相比較的話，不管是在磁碟佔用空間方面（Disk Footprint）、重大安全性更新數量（Important Bulletins）、重新啟動主機次數（Number of Reboots）、系統服務運作數量（Service Running）、核心記憶體佔用空間（Kernel Memory in Use）...等，相較於完整的 Windows Server 或 Server Core 都來得更為精簡。

圖 2、極精簡的伺服器版本Nano Server

圖片來源： Microsoft Ignite 2015 – Nano Server : The Future of Windows Server Starts Now

2、建立 Nano Server 映像檔

目前，最新版本的 Windows Server 2016 技術預覽版本為 TP4，其實在 TP4 版本之前要建立 Nano Server 是相對麻煩的。舉例來說，在 Windows Server 2016 TP2 及 TP3 版本時，Nano Server 映像檔是要額外下載的，並沒有內含在 Windows Server 2016 ISO 映像檔當中，並且建立 Nano Server 映像檔的 PowerShell，也必須額外至 TechNet Gallery下載才能方便建立，否則便要自行鍵入一大串的 PowerShell 指令才能產生 Nano Server 映像檔。

現在，在 Windows Server 2016 TP4 版本當中，除了 Nano Server 映像檔內含在 Windows Server 2016 ISO 映像檔之外，建立 Nano Server 映像檔的 PowerShell 也已經整合完成。並且，從 Windows Server 2016 TP4 版本開始，Nano Server 已經開始支援 DNS Server、IIS Server 等伺服器角色，以及 MPIO、VMM、SCOM、DSC、DCB、Windows Server Installer、WMI Provider...等伺服器功能。

此外，Windows Server 2016 TP4 版本中的 Nano Server，也多出了「Nano Server Recovery Console」特色功能，以便管理人員可以透過 Console 輕鬆查看及編輯 Nano Server 的網路組態設定，並且也可以進行關機及重新啟動 Nano Server 等管理動作。

Nano Server 可以運作在 Hyper-V 虛擬化平台中的 VM 虛擬主機，也可以運作在實體主機當中。接著，我們來實作如何建立出可運作於 VM 虛擬主機及實體主機的 Nano Server。

建立用於 VM 虛擬主機的 Nano Server

在本文的實作環境中，我們先為一台實體主機安裝 Windows Server 2016 TP4 版本，以便稍後掛載 Windows Server 2016 TP4 ISO 映像檔，並結合 PowerShell 指令及內建的 Nano Server Image 模組，建立可運作在 Hyper-V 虛擬化平台上的 VM 虛擬磁碟（VHD/VHDX）。

此外，在 Windows Server 2016 TP4 安裝過程時，請於安裝選項清單中選擇第二項，也就是結尾有 Desktop Experience 的安裝選項，才會是完整 GUI 圖形操作介面的 Windows Server 2016 TP4 運作環境。若選擇第一項的話則為指令介面的 Server Core 運作模式。

圖 3、為一台實體主機安裝 Windows Server 2016 TP4 版本

順利安裝 Windows Server 2016 TP4 版本後，請掛載 Windows Server 2016 TP4 ISO 映像檔，順利掛載後將會看到「NanoServer」子資料夾，進入後可以看到此實作所需要的「Convert-WindowsImage.ps1」及「NanoServerImageGenerator.psm1」指令碼檔案。請將整個 NanoServer 子資料夾複製到本機路徑，例如，C:\NanoServer。

圖 4、將 NanoServer 子資料夾複製到本機路徑

當你在深入查看 NanoServer 資料夾內容的話，便會發現到在 Packages 子資料夾中存放許多「.cab」檔案，這些檔案便是屆時幫 Nano Server 新增角色或功能時所需的檔案。此外，目前的 Nano Server 僅支援單一語系，所以僅會看到「en-us」子資料夾。

圖 5、Package 子資料夾存放新增伺服器角色及功能以及語系等所需檔案

請開啟 PowerShell 指令視窗，鍵入「cd C:\NanoServer」指令切換路徑至 Nano Server 資料夾當中，接著鍵入「Import-Module .\NanoServerImageGenerator.psm1」指令匯入 Nano Server 映像檔建立模組。

然後，便可以鍵入「New-NanoServerImage –MediaPath D:\ –BasePath .\Base –TargetPath '.\NanoImage\NanoVM.vhdx'–GuestDrivers –EnableRemoteManagementPort」指令，建立運作於VM虛擬主機（VHDX 虛擬硬碟檔）的 Nano Server。

下列為上述指令中，所用到的相關參數及功能說明：

–MediaPath：指定 Windows Server 2016 TP4 ISO 映像檔的根路徑。在本文的實作環境當中 ISO 映像檔的掛載路徑為「D 槽」。
–BasePath：指定 Nano Server 建立過程中，要將 Nano Server WIM 及 Packages 等相關檔案複製到何處存放。在本文實作環境中，將會存放於「C:\NanoServer\Base」路徑。
–TargetPath：指定建立 VM 虛擬主機「VHD / VHDX」虛擬硬碟檔的存放路徑。若屆時的 VM 虛擬主機為第一世代，則請建立 VHD虛擬硬碟檔（將為 MBR磁碟分割格式），若 VM 虛擬主機為第二世代請建立 VHDX虛擬硬碟檔（將為 GPT磁碟分割格式）。在本文實作環境中，因為 VM 虛擬主機為第二世代因此建立 VHDX 虛擬硬碟檔，並且將會存放於「C:\NanoServer\NanoImage\NanoVM.vhdx」。
–GuestDrivers：將 Nano Server 運作於 Hyper-V 虛擬化平台中的 VM 虛擬主機時，預先安裝相關的虛擬裝置驅動程式。
–EnableRemoteManagementPort：指定 Nano Server 預先開啟遠端管理 TCP Port 5985 連接埠，以便管理人員屆時能透過 WinRM（Windows Remote Management）的方式，進行 Nano Server 的遠端管理作業。

當上述建立運作於 VM 虛擬主機的 Nano Server 指令執行後，將會提示你鍵入屆時 Nano Server 的管理者密碼，鍵入完畢後便會開始建立內含 Nano Server 的 VHDX 虛擬硬碟檔。(事實上，New-NanoServerImage 建立指令，也可以在 Windows 8.1、10、Windows Server 2012 R2 作業系統中的 PowerShell 環境中執行。)

圖 6、建立運作於 VM 虛擬主機的 Nano Server

建立作業完成後，便可以在剛才建立指令中所指定的「C:\NanoServer\NanoImage」路徑下，發現用於運作 VM 虛擬主機的「NanoVM.vhdx」虛擬硬碟檔，你可以看到 Nano Server 真的非常的輕巧，此實作範例中所建立的虛擬硬碟檔僅佔用「612 MB」儲存空間而已。

圖 7、產生運作於 VM 虛擬主機的 Nano Server 僅佔用 612 MB 儲存空間而已

此時，你就可以在 Hyper-V 虛擬化平台中，建立第二世代的 VM 虛擬主機然後指定掛載剛才所產生的 NanoVM.vhdx 虛擬硬碟檔，順利啟動運作 Nano Server 的 VM 虛擬主機後，便可以看到 Nano Server 的登入畫面。請鍵入剛才建立過程中，所指定的 Nano Server 管理者密碼即可登入。

圖 8、Nano Server 登入畫面

建立用於實體主機的 Nano Server

事實上，建立運作於實體主機的 Nano Server 映像檔的操作步驟，與建立運作於 VM 虛擬主機的 Nano Server 流程類似。因此，重複操作步驟的部分便不再贅述，僅會說明差異及需要注意的地方。

同樣的，請你先將 Windows Server 2016 ISO 映像檔掛載，並將 NanoServer 子資料夾複製到本機路徑，然後匯入 NanoServerImageGenerator.psm1 模組即可。請鍵入「New-NanoServerImage –MediaPath D:\ –BasePath .\Base –TargetPath '.\NanoImage\NanoServer.vhd'–OEMDrivers –EnableRemoteManagementPort」指令。

讀者應該已經發現，產生用於實體主機 Nano Server 映像檔的指令，與 VM 虛擬主機 Nano Server 映像檔的指令大同小異，唯一不同的部分在於「–OEMDrivers」參數，也就是在建立此 Nano Server 映像檔時，載入與 Windows Server 2016 TP4 中 Server Core 版本相同的硬體裝置驅動程式，例如，網路卡、儲存控制器...等。

值得注意的是，屆時運作 Nano Server 的實體主機，若是採用「BIOS」的話那麼便應該要產生 .vhd檔案，倘若實體主機為新式的「UEFI」時則應該要產生 .vhdx檔案才行。

最後，便可以透過 WinPE 為實體主機開機後，複製剛才所建立的 NanoServer.vhd 至實體主機當中，然後採用下列 bcdedit 指令以便實體主機可以達成 Boot from VHD，順利將 Nano Server 運作在實體主機上。

bcdedit /copy {current} /d "Nano Server"
bcdedit /set {GUID} device vhd=[c:]\NanoServer\NanoServer.vhd
bcdedit /set {GUID} osdevice vhd=[c:]\NanoServer\NanoServer.vhd
bcdedit /set {GUID} path \windows\system32\boot\winload.exe

客製化 Nano Server 映像檔

透過上述二項實作建立 Nano Server 映像檔的練習後，相信讀者已經都會建立基本的 Nano Server 映像檔了。但是實務上，企業或組織運作環境當中並非是這麼單純的運作環境，舉例來說，通常主機至少必須給予固定 IP 位址、電腦名稱、加入網域...等。

接著，就讓我們來了解及實作如何客製化 Nano Server 映像檔。下列，便是列出在建立 Nano Server 映像檔可額外使用的相關參數及說明：

–ComputerName：指定 Nano Server 的電腦名稱。
–DomainName：指定 Nano Server 要加入的網域名稱。
–Ipv4Address：指定 Nano Server 的固定 IP位址。
–Ipv4SubnetMask：指定 Nano Server 的子網路遮罩。
–Ipv4Gateway：指定 Nano Server 的預設閘道。
–DriversPath：當預設的 OEM 驅動程式無法滿足時，可以指定 Nano Server 要額外載入的驅動程式路徑，所指定的驅動程式資料夾當中應該存在相關的 SYS 及 INF 檔案。此外，值得注意的是 Nano Server 僅支援 64 bit 的驅動程式。
–MaxSize：指定產生的 Nano Server 映像檔大小。
–ForAzure：當客製化後的 Nano Server 要運作於 Microsoft Azure 公有雲環境時，請使用此參數同時搭配「–GuestDrivers」及「–EnableRemoteManagementPort」參數即可。
–Compute：預先載入「Hyper-V 伺服器角色」至 Nano Server 當中。
–Clustering：預先載入「容錯移轉叢集（Failover Cluster）」伺服器功能，至 Nano Server 當中。
–Storage：預先載入「File Server」伺服器角色，以及其它儲存元件至 Nano Server 當中。
–Defender：預先載入「Windows Defender Antimalware」，以及預設的簽章檔案至 Nano Server 當中。
–ReverseForwarders：預先載入「應用程式相容性」功能特色，以便支援應用程式框架例如，Ruby、Node.js...等。
–Containers：預先載入「Windows Containers」功能特色至 Nano Server 當中。
–Packages Microsoft-NanoServer-DNS-Package：預先載入「DNS Server」伺服器角色，至 Nano Server 當中。
–Packages Microsoft-NanoServer-DSC-Package：預先載入「DSC（Desired State Configuration）」伺服器功能，至 Nano Server 當中。
–Packages Microsoft-NanoServer-IIS-Package：預先載入「IIS（Internet Information Server）」伺服器功能，至 Nano Server 當中。
–Packages Microsoft-NanoServer-SCVMM-Package：預先載入「SCVMM Agent」至 Nano Server 當中。
–Packages Microsoft-NanoServer-SCVMM-Compute-Package：規劃 Nano Server 啟用 Hyper-V 伺服器角色，並且希望透過 SCVMM 進行監控時，請勿使用上述介紹的「–Compute」參數為 Nano Server 預先載入 Hyper-V 伺服器角色。應該改為採用「–Packages Microsoft-NanoServer-Compute-Package」參數為 Nano Server 預先載入 Hyper-V 伺服器角色，並且搭配此項目參數達到以利屆時 SCVMM 進行監控。
–Packages Microsoft-NanoServer-NPDS-Package：預先載入「NPDS（Network Performance Diagnostics Service）」伺服器功能至 Nano Server 當中。
–Packages Microsoft-NanoServer-DCB-Package：預先載入「DCB（Data Center Bridging）」伺服器功能至 Nano Server 當中。

假設，當我們希望預先為 Nano Server 指定電腦名稱為「NanoTest01」時，便可以採用「-ComputerName NanoTest01」參數及參數值進行指定，同時搭配「Ipv4Address、Ipv4SubnetMask」參數及參數值，便可以為 Nano Server 預先指定固定 IP 位址及子網路遮罩。

圖 9、為 Nano Server 預先指定電腦名稱、固定 IP 位址、子網路遮罩

同樣的，如果屆時這台 Nano Server 要啟用「Hyper-V Containers」機制的話，那麼在建立 Nano Server 映像檔時，便可以加入「-Containers」及「-Compute」參數即可。

圖 10、為 Nano Server 預先載入 Hyper-V Containers 角色

3、本機管理 Nano Server

事實上，在先前的 Windows Server 2016 TP2、TP3 技術預覽版本當中，要針對 Nano Server 進行管理作業的話只能採用「遠端管理」的方式。現在，從 Windows Server 2016 TP4 版本開始，支援 Nano Server Recovery Console 特色功能，讓 Nano Server 的基礎管理作業變得相當簡單。

當 Nano Server 啟動並順利採用管理者帳號及密碼登入後，便可以看到 Nano Server Recovery Console畫面，在此管理畫面中你可以看到 Nano Server 的電腦名稱、工作群組或網域、作業系統版本、主機日期及時間、主機時區、網路組態資訊。

你可以使用「Ctrl + F6」組合鍵來重新啟動 Nano Server，或使用「Ctrl + F12」組合鍵關閉 Nano Server。或是透過「TAB 鍵」選取「Networking」項目，進行 Nano Server 的網路組態設定，或是選取「Firewall」項目進行防火牆規則的管理作業。

圖 11、Nano Server Recovery Console 管理畫面

當你進入 Networking項目後，便可以看到此台 Nano Server 的網路組態設定資訊，例如，IPv4、IPv6、DNS Server、預設閘道...等。在這個管理畫面中，你可以啟用或停用網路卡、編輯 IPv4 或 IPv6 位址內容、新增路由、切換為固定 IP 位址模式或採用 DHCP。

圖 12、Nano Server Recovery Console 網路組態設定管理畫面

當你進入 Firewall項目後，便可以看到此台 Nano Server 的防火牆規則清單，在這個管理畫面中，你可以快速且方便的啟用或停用指定的防火牆規則。

圖 13、Nano Server Recovery Console 防火牆規則管理畫面

4、遠端管理 Nano Server

了解 Nano Server 本機管理方式後，讀者應該可以了解到在實務上應該都會採用遠端管理的方式，來管理企業或組織當中的 Nano Server。你可以有多種方式遠端管理 Nano Server，例如，伺服器管理員（Server Manager）、Windows PowerShell、WMI（Windows Management Instrumentation）、Windows Remote Management。或者透過 Serial Cable 連接到 Nano Server 之後，再透過 EMS（Emergency Management Services）進行管理作業。

伺服器管理員

當你設定好 Nano Server 網路組態並加入網域環境後，便可以開啟「伺服器管理員（Server Manager）」，依序點選「All Servers > Add Servers > Active Directory」後鍵入 Nano Server 電腦名稱，將 Nano Server 加入至管理清單當中。

如果，Nano Server 並沒有加入網域的話，那麼請點選「All Servers > Add Servers > DNS」後鍵入 Nano Server 電腦名稱，將 Nano Server 加入至管理清單當中。但是，你將會發現無法取得該台 Nano Server 的 IP 位址，並且運作狀態為「Kerveros target resolution error」，此時請點選該台 Nano Server 後按下滑鼠右鍵選擇「Manage As」項目，然後於彈出的 Windows Security 視窗中鍵入 Nano Server 的管理者帳號及密碼，通過驗證程序後便會顯示該台 Nano Server 的 IP 位址，同時運作狀態也將轉變為「Online」。

圖 14、透過伺服器管理員遠端管理 Nano Server

Windows PowerShell

在你採用 Windows PowerShell 的方式遠端管理 Nano Server 之前，必須要先執行「Set-Item」指令將遠端的 Nano Server 的 IP 位址或電腦名稱，加入到管理主機當中的「Trusted Hosts」清單內。
Set-Item WSMan:\localhost\Client\TrustedHosts "<電腦名稱或IP位址>"

接著，便可以使用「Enter-PSSession」指令，連接至遠端的 Nano Server 進行 PowerShell 遠端管理作業。
Enter-PSSession -ComputerName "<電腦名稱或IP位址>" -Credential 電腦名稱\Administrator

倘若，你的 Nano Server 是運作在 Hyper-V 虛擬化平台中的 VM 虛擬主機，那麼你可以直接透過內建的 PowerShell Direct 功能，直接進行 PowerShell 遠端管理作業。
Enter-PSSession -VMName "<VM虛擬主機名稱>" -Credential電腦名稱\Administrator

Windows PowerShell CIM

你也可以透過 Windows PowerShell 啟動 CIM Session，以 WinRM（Windows Remote Management）的方式去執行 WMI 指令，達到遠端管理 Nano Server 的目的。

$ip = "<電腦名稱或IP位址>"
$cim = New-CimSession –Credential 電腦名稱\Administrator –ComputerName $ip
Get-CimInstance –CimSession $cim –ClassName Win32_ComputerSystem | Format-List *

Windows Remote Management

你也可以採用 WinRM 的方式，直接在遠端 Nano Server 上執行相關的管理動作。同樣的，在採用 WinRM 進行管理之前，必須先完成加入至本機 Trusted Hosts 的前置作業才行。

winrm quickconfig
winrm set winrm/config/client @{TrustedHosts="*"}
chcp 65001

接著，你就可以執行相關管理指令在遠端的 Nano Server 當中，下列範例指令將會執行「ipconfig」指令，列出遠端 Nano Server 的網路組態資訊。
winrs –r:< 電腦名稱或 IP 位址> -u:Administrator -p:<管理者密碼> ipconfig

5、結語

透過本文的說明及實作演練，相信讀者已經了解到在 Windows Server 2016 當中，如何為企業或組織建立精簡快速且效能良好的 Nano Server，同時在本文中也實作如何因應不同的需求，直接客製化出所需的 Nano Server，最後再說明如何進行本機及遠端管理 Nano Server 作業。

事實上，Nano Server 仍有許多進階功能值得探討，在後續的文章當中也將會讀者繼續深入剖析，例如，實戰 Nano Server 架構 Hyper-V Cluster、SOFS Cluster...等進階技術。

前言

微軟新世代 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】

關於本站

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

Weithenn 摸索 IT 世界回顧：

2002 年、2003 年、2007 年、2010 年
2011 年、2012 年、2013 年、2014 年、2015 年、2016 年

2002 年

6 月：

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

8 月：

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

11 月：

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

2003 年

4 月：

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

8 月：

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

2007 年

3 月：

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

2010 年

5 月：

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

10 月：

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

2011 年

11 月：

(1) 受邀擔任慶聯有線電視 - HP/Dell/IBM 伺服器及 CentOS 作業系統基礎設定內部教育訓練講師。
(2) 受邀推薦 iThome 2011 年 IT 好書 100 - 系統與網路管理類。

12 月：

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

2012 年

3 月：

(1) 受邀擔任雙和區資訊組長研習 - VMware vSphere ESXi 進階技術研習講師。
(2) 參加 Microsoft 所主辦的虛擬化戰士團，獲得 2012 年第一屆金翅級認證，微軟伺服器虛擬日 V-Day 虛擬化戰士頒獎典禮。

4 月：

(1) 受邀擔任雙和區資訊組長研習 - CentOS HA 高可用性進階技術研習講師。
(2) 成為 台灣第一位獲選 VMware vExpert 殊榮的人 VMware vExpert Information - Wei-Ren Wang，並受邀採訪刊登於 VMware VMTN Blog: vExpert Spotlight: Wei-Ren Wang。

5 月：

(1) 受邀擔任雙和區資訊組長研習 - FreeNAS 進階技術研習講師。
(2) 第 1 本技術審校書出版企業級的網路安全架構：終極防駭技術大剖析。

6 月：

(1) 受邀擔任雙和區資訊組長研習 - Hyper-V Server 2008 R2 進階技術研習講師。
(2) 跟 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Microsoft Technet Blog - 文章審校。

7 月：

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

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

8 月：

(1) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server Blog - 部份文章審校。
(2) 參加 Windows Server 2012 (Hyper-V 3) 好文比賽獲得分享獎。

9 月：

(1) 第 2 本技術審校書出版世界連在一起，搜尋引擎的核心秘密。

(2) 受邀推薦 iThome 2012 年 iT 人必看的好書 - 系統與網路管理類。
(3) 於 Microsoft Techdays Taiwan 2012舉辦期間，在 Windows Server 2012 攤位擔任問專家。

11 月：

(1) 受邀擔任板橋區資訊組長研習 - VMware vSphere ESXi 5.1 實作講師。
(2) 受邀擔任 Acer Infrastructure & Virtualization 技術會議內部教育訓練講師。
(3) 受邀採訪並刊登於網管人雜誌第 81 期資訊這條路 ─ 從無到有十年苦功王偉任嶄露頭角。

12 月：

(1) 受邀擔任雙和區資訊組長研習 - Windows Server 2012 新功能技術研討講師。
(2) 第 3 本技術審校書出版 MySQL+PHP初心者的學習殿堂：資料庫×動態網頁設計實務養成(附CD)。

2013 年

1 月：

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

3 月：

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

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 - 王偉任。

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

8 月：

(1) 受邀擔任雙和區資訊組長研習 - 虛擬化應用與基礎電腦病毒安全防護 (A場)、(B場)講師。
(2) 受邀擔任特新光電 - Windows Server 2008 R2 教育訓練內部教育訓練講師。

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。

10 月：

(1) 受邀擔任艾鍗學院 - 職訓課程 - 網管工程師類 - 私有雲與虛擬化系統工程師養成班講師。
(2) 貢獻 Microsoft Virtual Machine Converter文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

11 月：

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

(2) 受邀擔任威盛電子 - Windows Server 2012 R2 虛擬化平台最佳選擇內部教育訓練講師。
(3) 貢獻 Windows Server 2012 即時遷移文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。
(4) 擔任 102學年度全國大專校院 - 資訊行政主管研討會 - 淡江大學軟體雲建置實例分享議程講師，當天議程簡報 淡江大學軟體雲建置實例分享(PDF)。
(5) 擔任 VMware 桌面虛擬化及軟體雲應用研討會講師，當天議程簡報 虛擬桌面最佳化調校。

12 月：

(1) 受邀擔任雙和區資訊組長研習 - Hyper-V 3.0與 VMware vSphere 5.5 虛擬化新功能比較講師。
(2) 受邀擔任元智大學 - 雙 V 駭客，架設高可用的服務主機 (Hyper-V 上午場)、(VMware 下午場)研習活動講師。

2014 年

2 月：

貢獻 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 新功能展示。

4 月：

(1) 擔任春源鋼鐵 - VMware Horizon View 虛擬桌面內部教育訓練講師。
(2) 第 3 度當選 VMware vExpert 2014，VMware vExpert Information - Wei-Ren Wang。

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

5 月：

(1) 受邀擔任集英信誠 - 與大師對談技術論壇講師。
當天所有議程簡報與大師對談活動簡報。
當天我的議程簡報 VMware 及 Hyper-V最佳虛擬化平台硬體規劃。
(2) 受邀擔任雙和區資訊組長研習 - HyperV 3.0 R2 新功能研討研習講師。

6 月：

(1) 擔任台灣微軟 IT 管理技術高峰論壇 (MMS 2014) 講師。
當天所有議程簡報 2014 台灣微軟 IT 管理高峰會簡報下載。
(2) 參加 Microsoft 主辦雲端戰士團，獲得 2014 年第三屆金翅級認證。
當天活動新聞訊息自由電子報 3C科技 - 台灣微軟匯聚雲端戰士團。

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

7 月：

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

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

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

8 月：

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

9 月：

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

11 月：

第 2 本英文翻譯書出版 VMware Virtual SAN 管理手冊。

12 月：

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

2015 年

2 月：

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

4 月：

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

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

5 月：

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

(2) 受邀 iThome 雜誌採訪，分享全面透視虛擬環境網路效能的瓶頸觀點。
(3) 受邀擔任 104 年度資訊應用服務人才培訓計畫 - 企業私有雲實戰講堂 - 以 VMware 為例課程講師。
(4) 貢獻虛擬化環境導入評估工具 MAP、Storage Space 存放集區、 Azure RemoteApp 應用程式虛擬化等文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。
(5) 與 TechNet 部落格合作翻譯針對軟體定義資料中心而生的 - 新世代儲存機制、企業級虛擬化及新世代應用程式平台文章。
(6) 第 4 本技術審校書出版 SDN 軟體定義網路。

6 月：

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

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。

9 月：

(1) 受邀擔任資策會 Hyper-V 虛擬化實戰系列課程講師。
(2) 於 Microsoft Techdays Taiwan 2015 舉辦期間，擔任 3場(ITM305、ECI309、ECI303) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2015。

10 月：

(1) 與 MSDN 部落格合作翻譯微軟正式宣布推出 PowerShell DSC for Linux Version 1.1 以及新的 Linux 資源文章。
(2) 第 3 本 英文翻譯書出版實戰 Azure 混合雲｜基礎架構 x 高可用性 x 災難復原。

11 月：

第 4 本英文翻譯書出版 Active Directory 環境的 PowerShell 活用指南。

2016 年

1 月：

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

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

3 月：

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

其它

Weithenn PGP Keyid： 0xCD39063B
Weithenn Twitter： @weithenn
最有價值專家： Microsoft Hyper-V MVP、VMware vExpert
壁紙清單： CCNA, NSPA, JNCIA-JUNOS, JNCIA-ER, JNCIA-EX, JNCIA-Sec, MCP, MCSA, MCTS, MCITP, RHCT, RHCSA, RHCE, VSP4, VTSP4, VCP4, VSP5, VTSP5, VCP5-DCV, VCA-Cloud、VCA-DCV、VCA-WM、VCP-Cloud、VCP5-DT。

課程簡介

了解建置私有雲運作環境時對於實體的網路、儲存、交換器…等設備該如何進行規劃，並且會帶來何種影響。
了解在規劃私有雲環境時應該如何針對虛擬網路、儲存、交換器…等，將網路流量統一集中或者依服務類型進行切割，同時導入流量管控機制以達成網路與頻寬最佳利用率。
了解在規劃私有雲環境時對於何種使用情境，適合採用哪種儲存設備類型如 DAS、NAS、SAN。

課程資訊

時間： 每週六 09:00 ~ 12:00
地點：國立臺北商業大學 (臺北市中正區濟南路一段321號)
日期： 2016/03/12 ~ 2016/06/25
網址： 私有雲規劃與建置 VMware 實務班

網管人雜誌

本文刊載於網管人雜誌第 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 系統運作架構示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

2、VDI 大型架構規劃

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

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

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

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

硬體資源架構規劃

有鑑於運作數量龐大的 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 規劃示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 運作架構規劃示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 硬體伺服器配置建議

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

軟體資源架構規劃

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

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

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 使用率估算

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 使用率估算

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 1026766、2061913、1027217及相關文件。

此外，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 運作架構示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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

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

圖片來源： VMware Education – Horizon （with View） Fundamentals v6.0

當您將 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 運作架構示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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

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

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 容器規劃示意圖

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

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 虛擬桌面的測試數據

圖片來源： VMware 白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture

4、結語

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

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

書籍簡介

在本書中，我們將會指導你如何規劃及調校 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 系統管理技能的人而寫。

網路購書

天瓏網路書店： VMware vSphere 最佳化效能調校
博客來書籍館： VMware vSphere 最佳化效能調校
三民網路書店： VMware vSphere 最佳化效能調校
金石堂網路書店： VMware vSphere 最佳化效能調校
新絲路網路書店： VMware vSphere 最佳化效能調校
誠品網路書店： VMware vSphere 最佳化效能調校
PChome 24h 書店： VMware vSphere 最佳化效能調校

你將會從本書中學習到：

了解 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 檔案存放位置最佳建議…等議題。

前言

昨天晚上在微軟官方網站 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免費電子書。

其它參考資源

網管人雜誌

本文刊載於網管人雜誌第 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 公有雲服務總收入預估

圖片來源：IDC Worldwide and Regional Public IT Cloud Services 2012–2016 Forecast

當企業或組織開始嘗試在公有雲環境中建立各項服務之後，便會自然而然與企業內部環境（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）運作架構示意圖

圖片來源：2015 台灣微軟 IT 管理技術高峰論壇 – Microsoft OMS 跨平台雲端管理解決方案

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 管理平台建構流程示意圖

圖片來源：TechNet Library – 第一印象：開始使用 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 ID及 Primary 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 整合連接

圖片來源：TechNet OMS Blog – Why use OMS while SCOM is running

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 管理人員即時出門在外，只要有網路通訊便能輕鬆透過智慧型手機，監控企業或組織在雲端環境或企業內部的各項應用服務健康狀態。

網管人雜誌

本文刊載於網管人雜誌第 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 版本演進及新增功能示意圖

圖片來源： VMware Virtual SAN Overview

2、VSAN 運作架構

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

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

圖片來源： VMware Virtual SAN Overview

在儲存空間的運作架構中，支援採用「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 運作架構示意圖

圖片來源： VMware Virtual SAN Overview

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 重複資料刪除與壓縮技術運作示意圖

圖片來源： VMware vSphere Blog – Virtual SAN 6.2 Deduplication and Compression Deep Dive

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

預設情況下，重複資料刪除與壓縮技術為「停用（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）資料容錯機制

圖片來源： VMware 白皮書 – Virtual SAN 6.2 Space Efficiency Technologies

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

圖 8、FTT = 2 時，RAID-5 / RAID-6（Erasure Conding）資料容錯機制

圖片來源： VMware 白皮書 – Virtual SAN 6.2 Space Efficiency Technologies

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

書籍簡介

Windows Server 2012 R2及 Hyper-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 虛擬化環境。

活動簡介

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. 匯出叢集感知更新報表

課程簡介

雲端運算(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 轉換

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

網管人雜誌

本文刊載於網管人雜誌第 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 年雲端運算趨勢 – 混合雲佔有比例明顯上升

圖片來源： RightScale 2016 State of the Cloud Report

Microsoft Azure Stack 概觀

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

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

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

圖片來源： Microsoft Ignite 2015 – BRK2484 – Azure Consistent Service Delivery

熟悉 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 運作架構

圖片來源： Azure Stack Documentation – Microsoft Azure Stack POC Architecture

部署 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 Admin及 Tenant 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 階層關係示意圖

圖片來源： Azure Stack Documentation – Key features and concepts in Azure Stack

順利以 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」：

Basics：首先，你必須設定 VM 虛擬主機的電腦名稱，以及 Guest OS 的管理者帳號及密碼，同時選擇採用的訂閱名稱及資源群組名稱。
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 管理人員也可以自行建立不同大小的運作規模，以便租用戶挑選使用。
Setting：選擇所要採用的儲存體帳戶，以及這台 VM 虛擬主機所要採用的網路組態設定資訊。
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 公有雲服務的企業使用者來說，完全不需要適應新的操作介面及方式便可立即使用。

活動簡介

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。

活動資訊

日期： 2016 年 8 月 27 日 (星期六)
時間： 9:20 ~ 17:30
地點：中央研究院人文社會科學館 (台北市南港區研究院路 2 段 128 號)
報名：活動報名

活動內容

活動影片及講義

Coming Soon...

網管人雜誌

本文刊載於網管人雜誌第 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 操作示意圖

圖片來源： VMware vSphere Blog - vSphere 6.0 Update 2 - What's New

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.x及 5.x虛擬化平台的話，當 VM 虛擬主機啟用 vSphere FT 機制之後，在主要及次要 VM 虛擬主機之間將透過 VMware vLockstep 技術，採用「Record-Replay」資料同步方式。

圖 2、舊版 vSphere FT（Record-Replay）運作示意圖

圖片來源：VMware Blogs - Comparing Fault Tolerance Performance & Overhead Utilizing VMmark v1.1.1

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

圖 3、新版 vSphere FT（Fast Checkpointing）運作示意圖

圖片來源：VMware 白皮書- VMware vSphere 6 Fault Tolerance：Architecture and Performance

運算資源（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，若採用的是 Standard及 Enterprise版本的話，啟用 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 種情境時才會觸發其運作機制：

當 VM 虛擬主機啟用 vSphere FT 機制時。
當受到 vSphere FT 機制保護的主要 VM 虛擬主機，其底層的 ESXi 虛擬化平台發生故障事件。此時，服務及應用程式由次要 VM 虛擬主機接手，並且轉換身份為主要 VM 虛擬主機，同時在另外存活的 ESXi 主機上建立次要 VM 虛擬主機時。
當啟用 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 虛擬主機服務及應用程式示意圖

圖片來源：VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

運作狀態（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 網路頻寬

圖片來源：VMware vSphere Blog - vSphere 5 New Networking Features - Enhanced NIOC

透明容錯移轉（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 高可用性機制沒有任何中斷時間、資料遺失、連線遺失等情況發生

圖片來源：VMware Video - Enable vSphere Fault Tolerance for VMware vSphere

啟用 vSphere FT 技術的注意事項

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

啟用 vSphere FT 機制的 VM 虛擬主機，最多僅支援至 4 vCPU及 64 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 2039495、KB 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 2111975、KB 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 機制效能測試

圖片來源：VMware 白皮書 - VMware vSphere 6 Fault Tolerance：Architecture and Performance

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

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

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

圖片來源：VMware 白皮書 - VMware vSphere 6 Fault Tolerance：Architecture and Performance

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

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

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

圖片來源：VMware 白皮書 - VMware vSphere 6 Fault Tolerance：Architecture and Performance

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

圖片來源：VMware 白皮書 - VMware vSphere 6 Fault Tolerance：Architecture and Performance

實作 vSphere FT 高可用性機制

至此，相信你已經了解 vSphere FT 的運作架構、相關注意事項以及最佳作法。建議你應該再參考 VMware KB 1013428、KB 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 虛擬主機的服務及應用程式保持高可用性。

說明

每個軟體產品都有支援期間，還在使用 ESXi 5.0 / 5.1的企業及組織應該要注意了。根據 VMware Lifecycle Product Matrix內容可知，VMware vSphere ESXi 5.0 / 5.1虛擬化平台，即將於「2016/8/24」進入「EOS (End of Support)」。因此，還在使用 VMware vSphere ESXi 5.0 / 5.1 虛擬化平台的企業及組織應儘快升級。

值得注意的是，在將現有 VMware vSphere ESXi5.0 / 5.1虛擬化平台升級之前，應該先至 VMware Compatibility Guide網站查詢，目前使用的硬體伺服器是否支援 VMware vSphere ESXi 5.5 / 6.0虛擬化平台版本。

參考

活動資訊

日期：~~2016 年 8 月 20 ~ 21 日~~
時間： 09:00 ~ 17:00
地點： 資策會 (台北市大安區復興南路一段390號2,3樓，捷運大安站斜對面)
報名： ~~資策會課程 - VMware vSphere ESXi 桌面虛擬化實戰~~

課程大綱

VMware 虛擬化平台最佳硬體規劃
虛擬化實作環境建置（Nested VMs）
建置 VMware 虛擬化平台

安裝及管理 vCenter Server、ESXi

建置 VMware Horizon View 桌面虛擬化環境

安裝及管理 View Composer Server
安裝及管理 View Connection Server
安裝及管理 View Security Server

VDI 虛擬桌面管理

安裝及設定 Master Image
利用 Lined-Clone 大量部署VDI虛擬桌面
建立 VDI 虛擬桌面資源池

使用者設定檔管理

設定 View Persona Management
設定 Windows 漫遊使用者設定檔

連結 VDI 虛擬桌面

介紹 Thin Client、Zero Client
安裝 VMware View Client（支援 PC/NB、Android、iOS）
以瀏覽器連結 VDI 虛擬桌面
介紹虛擬列印（Virtual Printing）

網管人雜誌

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

文章目錄

前言
文字模式遠端管理 Nano Server
伺服器管理員
  Windows PowerShell
  Windows PowerShell CIM
  Windows Remote Management
RSMT 管理工具運作架構
安裝及部署 RSMT 管理工具
  建立 Server Management Tools Service
  部署 RSMT Gateway 主機
  連接地端 Nano Server
  管理地端 Nano Server
結語

前言

預計在今年 9 月份發表，微軟最新雲端作業系統 Windows Server 2016（一開始的開發代號為 Windows Server vNext），其中最重要的雲端基礎架構之一就是 Nano Server。事實上，在去年 Ignite 2015 年度技術大會時，便一同與 Windows Server 2016 TP2（第 2 版技術預覽版本），同步發表針對雲端應用最佳化的極精簡伺服器版本 Nano Server。

在 Windows Server 2016 TP2、TP3技術預覽版本時，倘若需要針對 Nano Server 進行管理作業的話，通常只能採用「遠端管理」的方式，因為 Nano Server 並沒有本機 Console 介面可進行管理作業。

但是，當微軟聽取大量 IT 管理人員針對 Nano Server 的測試結果及建議後，從 Windows Server 2016 TP4 版本開始，便新增 Nano Server Recovery Console特色功能，也就是說 Nano Server 安裝完畢並開機後，至少有簡單的 Console 管理介面，至少讓 Nano Server 的基礎組態設定作業變得簡單。現在，管理人員可以登入 Console 後進行 Nano Server 的電腦名稱、工作群組或網域、作業系統版本、主機日期及時間、主機時區、IP 位址、預設閘道……等系統及網路組態設定。

圖 1、Nano Server Recovery Console 管理畫面

文字模式遠端管理 Nano Server

當管理人員安裝好 Nano Server 之後，雖然可以透過 Nano Server Recovery Console，以互動的方式進行基本組態設定及管理作業。但是在後續管理及維運事務上，則必須採用遠端管理的方式來管理企業或組織當中的 Nano Server，舉例來說，當 Nano Server 需要新增或移除伺服器角色或功能時，那麼只能透過遠端管理的方式進行，因為本機的 Nano Server Recovery Console 並不支援新增移除伺服器角色及功能。

目前，Nano Server 支援的遠端管理方式包括，伺服器管理員（Server Manager）、Windows PowerShell、WMI（Windows Management Instrumentation）、Windows Remote Management…… 等方式進行遠端管理作業。

伺服器管理員

當管理人員安裝及設定好 Nano Server 網路組態之後，便可以在 Windows Server 2016 完整伺服器主機中，開啟「伺服器管理員（Server Manager）」並依序點選「All Servers> Add Servers> Active Directory」後，鍵入 Nano Server 電腦名稱以便將 Nano Server 加入至管理清單當中。

倘若，Nano Server 並沒有加入 Windows AD 網域環境的話，那麼請在伺服器管理員介面中依序點選「All Servers> Add Servers> DNS」後，鍵入 Nano Server 電腦名稱將 Nano Server 加入至管理清單內。

此時，管理人員可能會發現無法取得該台 Nano Server 的 IP 位址，並且運作狀態顯示為「Online - Access denied」，這是因為工作群組或未加入網域環境的 Nano Server 主機，在身分驗證方式的部分並非採用 Kerberos 所導致。

請在伺服器管理員介面中點選該台 Nano Server 後，按下滑鼠右鍵選擇「Manage As」項目，然後於彈出的 Windows Security 視窗中鍵入 Nano Server 的管理者帳號及密碼，通過身分驗證程序後便會順利顯示該台 Nano Server 的 IP 位址，同時運作狀態也將轉變為「Online – Performance counters not started」。

圖 2、透過伺服器管理員遠端管理 Nano Server

Windows PowerShell

當管理人員希望採用 Windows PowerShell 的方式遠端管理 Nano Server 之前，必須要先執行「Set-Item」指令，將遠端的 Nano Server 的 IP 位址或電腦名稱，加入到管理主機當中的「Trusted Hosts」信任清單內。

Set-Item WSMan:\localhost\Client\TrustedHosts "<Nano Server 的電腦名稱或 IP 位址>"

順利將遠端的 Nano Server 主機，加入至管理主機的信任清單當中後便可以使用「Enter-PSSession」指令，連接至遠端的 Nano Server 進行 PowerShell 遠端管理作業。

Enter-PSSession -ComputerName "<Nano Server 的電腦名稱或 IP 位址>" -Credential電腦名稱\Administrator

倘若，管理人員將 Nano Server 運作在 Hyper-V 虛擬化平台當中，那麼便可以直接透過內建的 PowerShell Direct 功能，直接採用 PowerShell 管理 Nano Server VM 虛擬主機。

Enter-PSSession -VMName "<VM 虛擬主機名稱>" -Credential 電腦名稱\Administrator

Windows PowerShell CIM

管理人員也可以透過 Windows PowerShell 啟動 CIM Session，採用 WinRM（Windows Remote Management）的方式執行 WMI 指令，達到遠端管理 Nano Server 的目的。

$ip = "<電腦名稱或 IP 位址>"
$cim = New-CimSession –Credential電腦名稱\Administrator –ComputerName $ip
Get-CimInstance –CimSession $cim –ClassName Win32_ComputerSystem | Format-List *

Windows Remote Management

當然管理人員也可以採用 WinRM 的方式，直接在遠端 Nano Server 上執行相關的管理動作。同樣的，在採用 WinRM 進行遠端管理作業之前，必須先將遠端 Nano Server 加入至本機 Trusted Hosts 的信任主機清單中才行，請執行下列指令：

winrm quickconfig
winrm set winrm/config/client @{TrustedHosts="Nano Server 的電腦名稱或 IP 位址"}
chcp 65001

接著，便能在遠端的 Nano Server 上執行相關管理指令，下列範例指令將會在遠端 Nano Server 上執行「ipconfig」指令，列出遠端 Nano Server 主機的網路組態資訊。

winrs –r:<Nano Server 的電腦名稱或 IP 位址> -u:Administrator -p:<管理者密碼> ipconfig

雖然，管理人員可以透過 WMI、PowerShell、PowerShell DSC（Desired State Configuration）、WinRM…… 等方式，針對 Nano Server 主機進行遠端管理作業。

但是，管理人員應該已經發現這些遠端管理機制或方式，都只能採用「指令（Command）」的方式進行，並沒有簡單的方式例如 GUI 圖形化介面，能夠方便管理人員進行 Nano Server 的遠端管理作業。接下來，將要介紹用來遠端管理 Nano Server 的利器，它是採用 HTML 5 技術撰寫而成的 GUI 圖形化介面管理工具，稱為 RSMT（Remote Server Management Tools）。

請注意!! 本文所介紹的 RSMT 遠端伺服器管理工具，與過去管理人員所熟知的 RSAT（Remote Server Administration Tools）遠端伺服器管理工具並不相同。

RSMT 管理工具運作架構

事實上，在 Ignite 2015 年度技術大會上，Powershell 發明人 Jeffrey Snover 便在大會上同步釋出一個管理工具，可以透過它來管理「無周邊伺服器（Headless Server）」，例如，Windows Server 2016 Server Core以及 Nano Server，此管理工具是採用 HTML 5 Web-Based的 GUI 圖形化管理工具，稱為 RSMT（Remote Server Management Tools）。

RSMT 遠端伺服器管理工具，可以針對 Server Core 及 Nano Server 提供下列管理機制：

檢視及調整系統組態設定。
檢視運作效能、執行程序、系統服務。
支援 Server Core 及 Nano Server 進行主機裝置管理作業。
檢視事件檢視器（Event Log）。
檢視伺服器角色及功能。
支援 PowerShell Console 視窗，以便進行遠端管理及自動化作業。

RSMT 管理工具在 2016 年 2 月時推出「公共預覽（Public Preview）」版本，並且 Server Management Tools Service 是運作在 Microsoft Azure 公有雲環境中。倘若，企業或組織想要採用 RSMT 管理工具，來管控內部運作的 Server Core 或 Nano Server 主機時，只要在內部建立 1 台 Server Management Tools Gateway主機，便可以透過這台 Gateway 主機，與 Azure 公有雲及內部伺服器溝通並進行管理作業。

值得注意的是，這台 Server Management Tools Gateway 主機，必須要能同時接觸到公共網際網路，以及內部運作的 Nano Server 才行。同時，在一般情況下，通常會將 Gateway 主機與內部 Nano Server 處於同一網段。

圖 3、RSMT 管理工具運作架構示意圖

圖片來源： TechNet Blog - Nano Server | Introducing Server management tools

Server Management Tools Gateway 主機，可以安裝在 Windows Server 2012 R2 或 Windows Server 2016 TP 作業系統中。值得注意的是，當安裝在 Windows Server 2012 R2 作業系統時，則必須要額外安裝 WMF 5.0（Windows Management Framework），屆時才能順利透過 PowerShell 管理 Windows Server 2016 TP 及 Nano Server。倘若，Gateway 主機安裝在 Windows Server 2016 TP 作業系統時，則無須額外安裝其它元件。

此外，建議管理人員應該採用全新的 Windows Server 2012 R2 作業系統，來擔任 Server Management Tools Gateway 主機。倘若，現有環境無法再新增一台全新主機擔任 RSMT Gateway 角色的話，則應該避免採用 Exchange Server、Skype Server、Lync Server、System Center 2012 R2 Service Management Automation 伺服器擔任 RSMT Gateway 角色，因為 WMF 5.0 元件無法安裝在這些伺服器應用程式的系統上。

下列為 WMF 5.0 所包含的更新功能項目：

Windows PowerShell。
JEA（Just Enough Administration）。
Windows PowerShell DSC（Desired State Configuration）。
Windows PowerShell ISE 整合式指令碼環境。
Windows PowerShell Web 服務（Management Odata IIS 擴充功能）。
Windows遠端管理（WinRM）。
WMI（Windowsd Management Instrumentation）。

安裝及部署 RSMT 管理工具

在 RSMT 的運作架構中，除了企業及組織內部必須要建立一台 Server Management Tools Gateway 主機，擔任 Azure 公有雲環境及內部運作環境的介接任務角色外，因為 Server Management Tools Service 是運作在 Microsoft Azure 公有雲環境當中，因此企業或組織必須要擁有一份 Azure 訂閱才行。

建立 Server Management Tools Service

請登入 Azure Portal 入口網站，依序點選「Marketplace > 管理 > 更多 > Server management tools（預覽）」項目，閱讀完此服務的說明後即可按下「建立」鈕，準備建立 Server Management Tools Service。

圖 4、準備建立 Server Management Tools Service

接著，將會出現建立伺服器管理工具連線視窗，請依序填入 RSMT 管理工具所需的相關資料，舉例來說，在「電腦名稱」欄位的部分，請填入屆時需要管理的 Nano Server 電腦名稱即可（此實作環境即命名為 NanoServer）。此外，目前因為 RSMT 管理工具還在預覽階段，因此在資料中心的部分目前僅支援「北歐、西歐、美國中部、美國東部」而已，相關資訊確認無誤後按下建立鈕便開始部署 RSMT 伺服器管理工具。

圖 5、部署 Server Management Tools Service

至此，RSMT 伺服器管理工具連線已經部署完畢，此時你可以在管理介面中看到，RSMT 伺服器管理工具連線尚未偵測到 Gateway 主機，所以顯示「未偵測到閘道」的藍色資訊列訊息。同時，在程式集設定區塊中，可以看到閘道的欄位顯示為「rsmt-gateway（狀態錯誤）」。

圖 6、RSMT 伺服器管理工具連線部署完畢

請點選「未偵測到閘道。按一下這裡以設定伺服器管理工具閘道」項目，此時將會自動帶出閘道組態設定視窗。首先，請選擇 RSMT Gateway 的更新方式，預設情況下將會採用「自動」的更新方式，建議管理人員採用自動更新方式，因為目前 RSMT 管理工具還在公共預覽階段，因為採用自動更新方式較為適宜。

接著，請按下「產生套件連結」鈕，此時便會自動產生 RSMT Gateway 主機所需要的安裝程式連結。然後，請切換至內部 RSMT Gateway 主機，下載及安裝 RSMT Gateway Service 執行檔。

圖 7、產生 RSMT Gateway 主機所需要的安裝程式連結

部署 RSMT Gateway 主機

順利下載 RSMT Gateway 主機所需要的安裝程式後，解開壓縮檔案你可以發現有「GatewayService.msi」安裝執行檔，以及「profile.json」組態設定檔。請將這 2 個檔案複製到 RSMT Gateway 主機，此實作環境採用 Windows Server 2016 TP5（Build Number 14300），擔任 RSMT Gateway 的角色並執行安裝作業。

圖 8、切換至 RSMT Gateway 主機安裝執行程式

安裝完畢後，開啟 RSMT Gateway 主機的系統服務，將會發現多出一項「Server Management Tools Gateway」服務，並且狀態為啟動中。

此時，查看 RSMT Gateway 主機的對外連線情況，將能發現 1 條與「*.store.core.windows.net」的 IP 位址，並且採用 HTTPs（TCP Port 443）通訊的連線資訊。因此，請確保 RSMT Gateway 主機對外連線的防火牆規則已經開啟。

圖 9、安裝後多出 Server Management Tools Gateway 系統服務

完成 RSMT Gateway 主機的部署作業後，請切換回 Azure Portal 入口網站並重新整理管理介面。此時，在程式集設定區塊中，可以看到閘道的欄位資訊從先前的「rsmt-gateway（狀態錯誤）」轉換為「rsmt-gateway（確定）」，表示 RSMT Gateway 主機已經與 Azure 公有雲環境正式介接完成。

同時，資訊也從先前的「未偵測到閘道」藍色資訊列，同步轉換成「按一下上方的管理命令以輸入系統管理認證」橘色資訊列訊息，表示已經可以準備管控企業或組織內部的 Nano Server 主機。

圖 10、RSMT Gateway 主機成功與 Azure Portal 建立連結

點選「rsmt-gateway（確定）」連結後，便可以看到目前 RSMT Gateway 主機，與 Azure 雲端環境連結成功。同時，在 Azure Portal 管理介面中，可以看到 RSMT Gateway 主機的運作狀態及相關資訊。

圖 11、在 Azure Portal 管理介面中查看 RSMT Gateway 主機運作資訊

連接地端 Nano Server

在 RSMT 管理介面按下管理身分圖示後，將會出現提示管理人員鍵入欲進行管理的 Nano Server 主機的管理者帳號及密碼，然後按下確定鈕即可。由於此次實作環境中，因為 Nano Server 主機並未加入 Windows AD 網域環境，因此身份驗證的方式不同於 Kerberos，必須要先採用 WinRM 指令設定 TrustedHosts 信任主機的連線方式，否則鍵入 Nano Server 主機管理者帳號及密碼後，將會得到下列錯誤畫面及訊息。

圖 12、Nano Server 未加入網域，必須在 RSMT Gateway 主機設定 TrustedHosts

由於此實作環境中 Nano Server 未加入網域環境，因此並沒有 DNS 名稱解析伺服器可以幫助我們進行名稱解析的動作。此外，對於工作群組或非網域成員主機的遠端連線管理作業，必須將遠端電腦（Nano Server）加入至來源端電腦（RSMT Gateway）的信任主機清單上才行。

請切換到 RSMT Gateway 主機，並且修改「C:\Windows\System32\drivers\etc\hosts」檔案內容，加入此實作的 NanoServer 名稱及 IP 位址（192.168.163.20）。然後，以 ping 指令確認是否能正確解析 Nano Server 主機的 IP 位址，確認能夠 ping 到及正確解析 Nano Server 主機的 IP 位址後，接著執行「winrm set winrm/config/client @{TrustedHosts="NanoServer"}」指令，將 Nano Server 主機加入至 RSMT Gateway 主機的信任主機清單當中。

圖 13、切換至 RSMT Gateway 主機建立 TrustedHosts 信任主機清單

此外，對於工作群組或非網域成員主機的遠端連線管理作業，因為 RSMT Gateway 主機的管理者帳號密碼，與 Nano Server 主機的管理者帳號密碼並不相同，因此對於非 Administrators 群組成員的系統管理員帳戶有 UAC 使用者帳戶控制的限制。

因此，請在 Nano Server 主機上執行「REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1」指令，以便可以正確採用本機管理者帳號及密碼進行管理登入的動作。

最後，倘若 RSMT Gateway 主機與 Nano Server 主機處於「不同 IP 網段」時，請於 Nano Server 主機上執行「NETSH advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow」指令，開啟 WinRM 遠端管理的防火牆規則。

圖 14、未加入網域環境的 Nano Server 主機，必須進行的額外設定

完成 RSMT Gateway 主機的遠端管理機制，以及 Nano Server 主機的額外設定作業後，便可以切換回 Azure Portal 入口網站管理頁面，按下「管理身分」圖示後鍵入 Nano Server 主機的管理者帳號及密碼。此時，便可以從 Azure Portal 管理頁面中，看到順利連接到地端的 Nano Server 主機，除了 CPU 及記憶體效能資訊外，按下「所有設定」連結還能看到其它相關的管理項目。

此時，在 RSMT Gateway 主機端查看網路連線情況，便可以看到連線至 Nano Server 主機的連線資訊（TCP Port 5985）。當然，在 Nano Server 主機上，也可以看到由 RSMT Gateway 主機端，連線至本機 TCP Port 5985 的連線資訊。

圖 15、RSMT 管理工具成功與地端 Nano Server 主機連接

管理地端 Nano Server

當地端的 Nano Server 主機順利與 Azure 雲端環境連接後，管理人員便可以很簡單的透過 Azure Portal 管理介面，針對地端的 Nano Server 主機進行管理作業。

首先，可以針對納管的 Nano Server 主機四大硬體資源使用率（CPU、Memory、Network、Storage）進行監控。但是，在儲存資源的部分，預設情況下並不會啟用儲存資源的監控機制，請按下「啟用磁碟衡量標準」後，在磁碟讀取和寫入視窗中依序按下「啟用 / 停用 > 是」之後，便同樣能夠很容易的監控 Nano Server 主機的儲存資源使用率。

現在，管理人員可以很容易的透過 RSMT 遠端伺服器管理工具，在 Azure 雲端環境監控地端 Nano Server 主機，在 CPU、Memory、Network、Storage 四大硬體資源方面的使用率。

圖 16、查看 Nano Server 四大硬體資源使用率

當管理人員需要針對 Nano Server 主機進行其它管理作業時，請按下「所有設定」連結，在設定視窗中可以看到一共分為支援與疑難排解、管理、工具、資源管理……等管理需求。舉例來說，目前實作環境中 Nano Server 主機並未加入 Windows AD 網域環境，倘若日後將此台 Nano Server 加入 Windows AD 網域環境後，便可以切換至「管理 > 電腦識別」項目後，鍵入此台 Nano Server 主機的連線管理資訊後，按下儲存鈕即可。

圖 17、調整 Nano Server 主機的遠端連線管理資訊

事實上，在 RSMT 管理介面上的每項管理項目都非常直覺，基本上與地端採用的「電腦管理」方式差異不大，舉例來說，點選「工具 > 處理程序」後便能立即看到 Nano Server 主機上的執行程序，這與 Windows Server 2016 GUI 運作環境中，開啟工作管理員的操作體驗是一致的，甚至管理人員也可以點選某個執行程序後，終止該處理程序。

圖 18、遠端管理 Nano Server 主機的執行程序

此外，當管理人員想要針對地端的 Nano Server 主機，執行 PowerShell 進行管理作業時，在 RSMT 管理介面中也可以輕鬆達成，請點選「工具 > PowerShell」項目，即可看到 PowerShell Console 視窗，並且能夠以 PowerShell 遠端管理地端的 Nano Server 主機。

圖 19、在 RSMT 管理介面中以 PowerShell 管理地端 Nano Server 主機

最後，倘若相關設定皆正確無誤，但是 RSMT 管理介面突然無法管理地端的 Nano Server 主機時（如圖 20 所示），請先檢查 RSMT Gateway 主機網路連線狀態，確認是否與 Nano Server 有 TCP Port 5985 的連線，若沒有的話可以嘗試把 RSMT Gateway主機上「Server Management Tools Gateway」系統服務重新啟動，便應該能夠解決這個突然無法連線的問題。

圖 20、重新啟動 RSMT Gateway 主機服務，以便解決突然無法連線的問題

結語

透過本文的說明及實作演練，相信讀者已經了解在新一代 Windows Server 2016 雲端作業系統中，如何為企業或組織打造精簡快速且雲端效能最佳化的 Nano Server 主機。同時，對於後續的維運管理作業中，倘若管理人員不習慣採用文字介面遠端管理 Nano Server 主機時，便可以採用本文所介紹的 RSMT 遠端伺服器管理工具，輕鬆達成 Nano Server 主機的硬體資源監控及管理的目的。