前言
日前舉行的 VMworld 2016 - US已經落幕，其中 Duncan Epping已經將他在大會上演講的議程 STO7605 及 INF8036 簡報釋出，有興趣的朋友可以參考看看。STO7605 簡報
INF8036 簡報
STO7605 簡報
INF8036 簡報
↧
VMworld 2016 - STO7605 及 INF8036 簡報
STO7605 簡報
INF8036 簡報
↧
128 期 - 看懂伺服器新授權模式，正確評估精省採購
網管人雜誌
本文刊載於 網管人雜誌第 128 期 - 2016 年 9 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。前言
隨著 Windows Server 2016 及 System Center 2016 產品，即將於 9/26 ~ 9/30 於美國 Ignite 2016大會舉辦時正式公佈，台灣也預計於 10 月 10 日當週正式進行產品發表，以及產品的 Product Launch 和 Roadshow 等相關活動。雖然，Windows Server 2016 及 System Center 2016 為開發人員及IT專業人員提供許多耳目一新的功能，但是在軟體授權的部分則與過去的 Windows Server 2012 R2 及 System Center 2012 R2 有所不同，值得企業及組織的IT管理人員注意。
授權機制更動
首先，在 Windows Server 2012 R2及 System Center 2012 R2時，授權模式為「處理器架構（Processor Based）」，舉例來說，採購 1 套 Windows Server 2012 R2 軟體授權將具備「2 顆 CPU 處理器」的使用權利，完全不用考慮處理器運算核心（Core）的部分。現在，在 Windows Server 2016及 System Center 2016 產品中，授權模式則改為「實體核心架構（Core Based）」。雖然，每 1 套 Windows Server 2016 軟體授權仍然具備「2 顆 CPU 處理器」的使用權利，但是每顆 CPU 處理器只有「8 個實體核心（8 Cores）」的使用權利，一旦採用的實體伺服器處理器運算核心超過「16 個實體核心（16 Cores）」時，將需要額外的核心授權（Core Pack），每 1 套核心授權為 2 個實體核心（1 Core Pack = 2 Cores）。
舉例來說，企業或組織欲採購 Intel Xeon E5-2600v4雙路硬體伺服器，倘若採購的 CPU 處理器為 E5-2609 v4、E5-2620 v4或 E5-2667 v4時，因為每顆 CPU 處理器的實體核心為 8 Cores，因此每台硬體伺服器只要採購 1 套 Windows Server 2016 軟體授權即可。
舊有 Intel E5-2600 v2系列處理器中，E5-2640、E5-2650、E5-2667 為實體核心 8 Cores 產品。倘若是 Intel E5-2600 v3系列處理器，則 E5-2630、E5-2640、E5-2667 為實體核心 8 Cores 產品。
然而，若是採購的 CPU 處理器為 E5-2650 v4 時，因為每顆 CPU 處理器的實體核心為 12 Cores，每台硬體伺服器的總核心數為 24 Cores，因此每台硬體伺服器除了要採購 1 套 Windows Server 2016 軟體授權之外（核心數使用權利 16 Cores），還要額外購買 4 套核心授權（4 Core Pack = 8 Cores）才行。
Windows Server 2016 及 System Center 2016 產品，將會依照「實體核心（Physical Core）」進行軟體授權而非「邏輯處理器（Logical Processor）」。因此，在硬體伺服器 BIOS 中開啟「超執行緒（Hyper-Threading，HT）」功能，並不會影響軟體授權。
正確評估判斷核心數量
因此，企業或組織若是新採購硬體伺服器的話，則可以直接參考選購的 CPU 處理器規格，挑選實體核心 8 Cores 的處理器，屆時便無須再額外購買核心授權。倘若，是資料中心內原有安裝 Windows Server 2012 R2 作業系統硬體伺服器的話，則可以直接開啟工作管理員查看 CPU 項目中「核心項目」欄位即可，或是透過微軟的免費資產清點工具 MAP（Microsoft Assessment and Planning），快速收集及清點資料中心內每台硬體伺服器的核心數量。有關微軟免費資產清點工具 MAP的架設及使用說明，請參考第 107 期網管人雜誌內容。
圖 1、透過工作管理員快速判斷硬體伺服器運算核心數量
此外，過去 Windows Server 2012 R2 標準版及資料中心版本在特色功能方面一模一樣。現在，在 Windows Server 2016 版本中則有所不同，舉例來說，倘若需要使用微軟新一代 SDS 軟體定義儲存技術（Storage Spaces Direct，S2D），或者是 SDN 軟體定義網路技術時，則必須要購買 Windows Server 2016 資料中心版本才行。
↧
↧
128 期 - 最新 VMware Host Client 直接管理單台 ESXi 主機
網管人雜誌
本文刊載於 網管人雜誌第 128 期 - 2016 年 9 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言VMware Host Client 管理工具
VMware Host Client 系統需求
管理 ESXi 主機
主機電源管理原則
指派軟體授權
安裝更新
管理服務
加入 Active Directory 網域
時間同步
管理 VM 虛擬主機
管理 vSwitch 虛擬網路
結語
前言
目前，許多企業及組織的資料中心內，已經建置 VMware vSphere 虛擬化平台。值得注意的是，倘若企業及組織的資料中心內仍有 vSphere ESXi 5.0 及 5.1 虛擬化平台版本的話，那麼應該著手準備升級虛擬化平台版本至 ESXi 5.5，或者是最新版本的 ESXi 6.0。事實上，VMware vSphere 5.0 及 5.1 虛擬化產品，在 2011 年 8 月便正式「GA（General Availability）」。根據 VMware Lifecycle Product Matrix 文件指出，VMware vSphere 5.0 及 5.1 版本的虛擬化產品，包含 vSphere ESXi 5.0 / 5.1 以及 vCenter Server 5.0 / 5.1……等版本，都將於「2016 年 8 月 24 日」進入「終止支援（End Of Support，EOS）」，因此企業或組織應儘快進行版本升級的動作。
圖 1、VMware vSphere 虛擬化產品生命週期表
對於採用 VMware vSphere 5.0 / 5.1 虛擬化版本的管理人員來說，應該仍習慣採用原有的 vSphere C# Client 管理工具（或稱 vSphere Desktop Client / vSphere Legacy Client / vSphere Client for Windows）。因為，在 vSphere 5.0 / 5.1 版本運作環境中，VMware 所力推的新版 vSphere Web Client管理工具，不管是在操作反應速度上或操作介面友善度上，相較於原有的 vSphere C# Client 管理工具，在使用者操作體驗上都有一段不小的差距。
圖 2、新式 vSphere Web Client 管理工具操作介面
因此，許多 vSphere 管理人員一直持續使用舊有的 vSphere C# Client 管理工具，來管理企業及組織的整個 VMware vSphere 虛擬化基礎架構。這也是為什麼 VMware 官方，雖然在 vSphere 5.0 推出新的 vSphere Web Client 管理工具後，便曾經宣佈之後的版本不會再有 vSphere C# Client 管理工具，同時相關進階功能也都只有 vSphere Web Client 管理工具才能進行組態設定。
但是，後續的結果是不管 vSphere 5.1、5.5、6.0 版本，VMware 官方都仍繼續釋出 vSphere C# Client 管理工具，這表示有眾多的 vSphere 管理人員並無法順利拋開舊有 vSphere C# Client 管理工具，轉而擁抱新的 vSphere Web Client 管理工具。
有關舊有 vSphere C# Client 及新式 vSphere Web Client 管理工具，2 種 VMware vSphere 虛擬化管理工具的功能性差異詳細資訊，請參考 VMware KB 2095050。
造成如此結果的主要原因，是因為新式的 vSphere Web Client 管理工具，必須在 vCenter Server 及 vSphere Web Client 服務正常運作的情況下，才能夠順利使用 vSphere Web Client 管理工具。倘若，是「單機」ESXi 主機的運作環境或 vCenter Server 無法正常運作時，那麼新式的 vSphere Web Client 管理工具便無法進行管理作業。反觀舊有的 vSphere C# Client 管理工具，即便只有單台 ESXi 主機或 vCenter Server 無法正常運作時，都仍然能夠進行 ESXi 主機的管理作業。
圖 3、舊有 vSphere C# Client 管理工具操作介面
VMware Host Client 管理工具
雖然，舊有的 vSphere C# Client 管理工具，在管理單台 ESXi 主機上具有便利性。不過最被管理人員所垢病的便是它的安裝程式，vSphere 管理人員必須先找 1 台管理主機（必須能夠接觸網際網路），然後下載及安裝 vSphere C# Client 安裝程式（約 350 MB），之後才能執行 vSphere C# Client 管理工具。因此，之前在 VMware Lab – Flings 網站中，便有了 ESXi Embedded Host Client計畫，它是以 HTML5及 Javascript技術撰寫而成的管理工具，希望能夠具有 vSphere C# Client 管理工具的便利性（管理單台 ESXi 主機），同時也具備 vSphere Web Client 管理工具方便性（透過瀏覽器即可管理 ESXi 主機）。
使用上也非常方便，只要至 VMware Lab – Flings 網站下載 ESXi Embedded Host Client 的 VIB 檔案，然後上傳至 ESXi 5.x 及 6.x 主機進行安裝作業之後，後續便可以輕鬆透過瀏覽器連結至 ESXi 主機進行管理作業。
圖 4、ESXi Embedded Host Client 管理工具操作示意圖
日前，最新的 VMware vSphere 6.0 Update 2（簡稱 6.0 U2）版本，已經於 2016 年 3 月時正式推出，除了相關增強功能及修正之外，還新增了名稱為「VMware Host Client」的管理工具。其實，便是將 VMware Labs 當中的 ESXi Embedded Host Client 管理工具，直接移植到 ESXi 6.0 Update 2 版本當中。
因此，vSphere 管理人員安裝好 ESXi 6.0 Update 2 虛擬化平台之後，開啟瀏覽器並在網址欄鍵入「https://<FQDN or IP of host>/ui」，便可以透過內建的 VMware Host Client 機制，連線至單台 ESXi 主機進行管理作業，而無須額外安裝舊有的 vSphere C# Client 管理工具。
圖 5、VMware Host Client 管理工具操作示意圖
同時，VMware 官方在 2016 年 5 月份時，再次於 VMware vSphere Blog 中正式宣告，在下一版本的 vSphere 當中，將不會再出現舊有的 vSphere C# Client 管理工具。同時，在 VMware Lab – Flings 網站中，還有另一個重要的測試項目稱之為「vSphere HTML5 Web Client」，主要原因在於目前的 vSphere Web Client 管理工具採用的技術底層為「Flash」，除了造成運作效能較為低落之外，也可能導致其它安全性風險。因此，VMware 計畫未來將以 HTML5 及 Javascript為技術底層所打造的 vSphere HTML5 Web Client管理工具，取代現有以 Flash 為底層的 vSphere Web Client 管理工具。
根據 VMware 官方統計，在建置 VMware vSphere 虛擬化運作環境的企業及組織，已經有多達 40% 的企業及組織，下載及使用 vSphere HTML5 Web Client 管理工具，在內部的 VMware vSphere 虛擬化運作環境中。
圖 6、vSphere HTML5 Web Client 管理工具操作示意圖
VMware Host Client 系統需求
再次提醒，VMware Host Client 為用來連線及管理「單台」ESXi 主機的管理工具，它與 vSphere Web Client 管理工具不同，它無法連線 vCenter Server 及同時管理多台 ESXi 主機。因此，僅在單機 ESXi 運作環境或 vCenter Server 無法運作時才使用。它所具備的管理功能如下：- 管理單台 ESXi 主機。
- 部署及管理 VM 虛擬主機。
- 建立及管理網路交換器。
- 建立及管理資料存放區。
由於 VMware Host Client 採用 HTML 5 技術所開發，原則上只要開啟瀏覽器在網址列鍵入「http://ESXi-Hostname/ui」或「http://ESXi-IP-Address/ui」，即可透過 VMware Host Client 管理 ESXi 主機。但是，必須確保所採用的瀏覽器支援 HTML 5技術才行，支援的瀏覽器及版本資訊如下：
- Google Chrome： 25 或之後的版本。
- Mozilla Firefox： 15 或之後的版本。
- Internet Explorer： 10 或之後的版本。
- Safari： 5.1 或之後的版本。
- Opera： 12 或之後的版本。
管理 ESXi 主機
預設情況下，VMware Host Client 管理介面便支援多國語系，但是一開始預設登入管理介面的語系，則取決於管理主機瀏覽器的語系，舉例來說，管理主機的語系為正體中文時，那麼登入 VMware Host Client 管理介面便會採用正體中文介面。倘若，管理人員希望調整 VMware Host Client 管理介面語系的話，只要點選上方帳戶名稱在下拉選單中依序點選「用戶端設定 > 語言設定」即可選擇語系。
圖 7、調整 VMware Host Client 管理介面操作語系
此外，預設情況下 VMware Host Client 管理介面，只要閒置「15 分鐘」後便會自動登出管理介面，倘若希望調整自動登出的閒置時間設定，請點選上方帳戶名稱在下拉選單中依序點選「用戶端設定>應用程式逾時」，依據需求選擇「15 分鐘、30 分鐘、1 小時、2 小時、關閉」等選項即可。
因此，透過 VMware Host Client 管理介面，管理人員便可以輕鬆以瀏覽器直接管理單台 ESXi 主機的系統組態，舉例來說，管理人員可以將 ESXi 主機進入維護模式、關機、重新啟動、設定鎖定模式……等。那麼，就讓我們一一介紹如何透過 VMware Host Client 管理介面，管理單台 ESXi 主機及其上運作的 VM 虛擬主機。
主機電源管理原則
事實上，企業或組織導入虛擬化平台技術，除了希望能夠將硬體伺服器進行整併之外，另一個關鍵因素便是資料中心的電力節省，同時採用不同的實體伺服器及相關週邊配件也將導致不同的電力損耗，實體伺服器採用的硬碟種類及轉速、網路卡、風扇……等，也都將影響整體的電力損耗數值。除了硬體伺服器本身硬體元件的電力損耗外，VMware vSphere ESXi 虛擬化平台的電源設定，也會影響硬體伺服器整體的運作效能及電力損耗情況。預設情況下，VMware vSphere ESXi 虛擬化平台的電源設定為「平衡」，也就是 ESXi 主機將會自動在運作效能及電力損耗之間取得平衡點。
ESXi 主機提供 5 項電源管理原則，倘若硬體伺服器不支援電源管理機制，或是硬體伺服器在 BIOS 組態設定中，指定主機作業系統無法管理電源時，ESXi 主機將會自動採用「不受支援」的電源設定。下列為 ESXi 主機 CPU 電源管理原則：
因此，倘若希望在 ESXi 主機上運作的 VM 虛擬主機擁有高效能表現，那麼應該要將電源計劃調整為「高效能」，請登入 VMware Host Client 管理介面後，依序點選「管理 > 硬體 > 電源管理 > 變更原則」選擇至「高效能」項目。順利變更 ESXi 主機的電源原則後，同時會觸發實體伺服器的 Intel Turbo Boost 或 AMD Core Performance Boost 硬體加速技術，讓實體伺服器維持在最佳效率狀態（詳細資訊請參考 VMware KB 1018206）。
圖 8、變更 ESXi 主機電源原則
指派軟體授權
預設情況下，安裝 ESXi 主機時將自動採用「評估模式」，也就是「60 天全功能」試用版本。請登入 VMware Host Client 管理介面後，依序點選「管理 > 授權 > 指派授權」填入「授權金鑰」即可。值得注意的是，倘若 ESXi 主機在評估模式運作 60 天後仍未指派正式的軟體授權時，那麼 ESXi 主機將會「中斷」與 vCenter Server 之間的連線，所有已開啟電源的 VM 虛擬主機仍可繼續運作，但是 VM 虛擬主機一旦關機後便無法開啟電源，同時也無法變更組態設定。
圖 9、為 ESXi 主機指派軟體授權
安裝更新
過去，要安裝 VIB 或是 ESXi 主機的安全性更新 metadata.zip 檔案時，安裝流程便是上傳至 ESXi 主機的 Datastore 之後，開啟 ESXi 主機的 SSH 服務然後透過 SSH 客戶端軟體（例如，putty），連線至 ESXi 主機後鍵入相關指令，執行安裝 VIB 或安全性更新 metadata.zip 檔案。現在，管理人員可以輕鬆透過 VMware Host Client 的管理介面，幫 ESXi 主機安裝 VIB 或安全性更新 metadata.zip 檔案。舉例來說，目前我們使用的 ESXi 主機版本為「6.0 Update 2（Build 3620759）」，但 VMware 官方已經又釋出最新的安全性更新「ESXi600-201605001（Build 3825889）」。
圖 10、下載 ESXi 6.0 最新安全性更新
請將下載 ESXi 6.0 最新安全性更新 ESXi600-201605001.zip 檔案，將檔案解壓縮後上傳至 ESXi 主機 Datastore，並確認 metadata.zip 的儲存路徑。
圖 11、將 ESXi 6.0 最新安全性更新檔案上傳
接著在 VMware Host Client 管理介面中，請先將 ESXi 主機進入維護模式然後依序點選「管理 > 套件 > 安裝更新」，在彈出的安裝更新視窗中，鍵入剛才 ESXi 6.0 最新安全性更新 metadata.zip 的存放路徑，此實作環境中，metadata.zip 的存放路徑為「/vmfs/volumes/datastore1/ESXi600-201605001/metadata.zip」後，按下 Update 鈕即可。
圖 12、鍵入 ESXi 6.0 最新安全性更新 metadata.zip 的存放路徑
按下 Update 鈕後，系統將彈出警告視窗表示倘若此台 ESXi 主機受到 VMware Update Manager 管理，那麼執行這個更新動作之後可能會導致此台 ESXi 主機變為不符合標準，詢問您是否繼續，請按下繼續鈕執行安裝最新安全性更新的動作。安裝完畢後請將 ESXi 主機重新啟動，當 ESXi 主機再次啟動後便可以看到 Build 號碼由先前的「3620759」，更新為最新的「3825889」版本。
圖 13、順利為 ESXi 主機安裝最新安全性更新
管理服務
在 VMware Host Client 管理介面中，請依序點選「管理 > 服務」便可以針對 ESXi 主機相關服務，進行「啟動、停止、重新啟動」等管理動作。此外，你也可以在「動作」下拉選單中，針對服務所要採取哪種「原則」，舉例來說，倘若希望 ESXi 主機在啟動後便自動啟動 SSH 服務的話，那麼在原則中便選擇至「隨主機一起啟動和停止」即可。
圖 14、管理系統服務及啟動原則
加入 Active Directory 網域
預設情況下，ESXi 主機的管理者帳戶名稱為「root」，倘若企業及組織當中只有幾台 ESXi 主機的話，每當要新增管理者帳號或變更管理者密碼時，管理人員可能還可以應付。但是，倘若企業及組織虛擬化運作環境中有多台 ESXi 主機時，除了多台 ESXi 主機必須同步管理者帳戶名稱及密碼的挑戰外，還可能會導致未授權存取的組態問題等安全性風險。因此，企業及組織可以將 ESXi 主機加入至 Windows Active Directory 網域環境中，而無須再建立及維護 ESXi 主機的本機使用者帳戶，同時還可以透過 Active Directory 網域環境輕鬆達成 SSO 單一登入機制。
請在 VMware Host Client 管理介面中，依序點選「管理 > 安全性和使用者 > 驗證 > 加入網域」，在彈出的加入網域視窗中請依序填入 Active Directory 網域環境資訊，然後按下加入網域鈕即可。同時，當 ESXi 主機順利加入 Active Directory 網域環境之後，將會自動把系統服務「lwsmd」也就是「Active Directory Service」服務自動啟動，因此系統服務的狀態將從先前的已停止轉變為「執行中」。
圖 15、順利將 ESXi 主機加入 Active Directory 網域環境
預設情況下，若只鍵入網域名稱的話，那麼 ESXi 主機順利加入 Active Directory 網域環境後，電腦帳戶將會建立在預設的「Computers」容器中。倘若，你希望 ESXi 主機的電腦帳戶建立在指定的 OU 組織時，便可以在網域名稱後加入 OU 組織名稱，舉例來說，希望將 ESXi 主機的電腦帳戶加入「IT」的 OU 組織時，請鍵入「vdi.weithenn.org/IT」即可。
當鍵入的 Active Directory 網域環境資訊正確，同時網域管理者帳戶也順利通過身分驗證機制時，那麼 ESXi 主機便會順利加入 Active Directory 網域環境中。此時，可以切換至 DC 網域控制站查看是否順利建立 ESXi 主機電腦帳戶，以及是否新增 DNS 正向及反向解析記錄。
圖 16、ESXi 主機加入網域後，順利建立電腦帳戶及 DNS 正向及反向解析記錄
順利將 ESXi 主機加入 Active Directory 網域環境後，在 DC 網域控制站中請建立 ESXi 主機的預設管理群組「ESX Admins」，之後只要加入 ESX Admins 群組的使用者帳號，便具備 ESXi 主機的管理權限。倘若，你希望能夠修改 ESXi 主機的預設管理群組名稱的話，請在 VMware Host Client 管理介面中，依序點選「管理 > 進階設定」找到「Config.HostAgent.plugins.hostsvc.esxAdminsGroup」項目，按下編輯選項後鍵入希望更改的 ESXi 主機預設管理群組名稱，同時修改此名稱後必須重新啟動 ESXi 主機才能套用生效。
圖 17、採用 Active Directory 網域環境中 ESX Admins 群組成員帳戶登入管理 ESXi 主機
時間同步
事實上，即便採用相同型號及等級的硬體伺服器，當上線運作一段時間之後每台硬體伺服器的系統時間，多少都會有些許的誤差產生，原因在於硬體伺服器中負責計算時間的晶體震盪元件（Crystal Oscillator），在製造過程中或多或少都會有一點點些許誤差，而正因為這些極小的誤差導致所震盪出來的頻率無法完全精準，因此導致硬體伺服器運作一段時間後造成時間誤差的主因。因此，管理人員應該為每台 ESXi 主機組態設定 NTP 時間同步機制，以避免 ESXi 主機發生災難事件時無法透過事件及記錄的時間點，精準找出發生災難的時間點阻礙故障排除作業。請在 VMware Host Client 管理介面中，依序點選「管理 > 時間和日期 > 編輯設定」，在彈出的編輯時間組態視窗中，你可以手動設定 ESXi 主機系統時間，或採用 NTP 時間同步機制並且指定 NTP 伺服器，此實作環境中指向 2 台 NTP 伺服器，1 台是內部網域的 DC 網域控制站（dc.vdi.weithenn.org），另 1 台則是網際網路上國家時間與頻率標準實驗室，所提供的 NTP 時間伺服器（time.stdtime.gov.tw）。
圖 18、組態設定 ESXi 主機 NTP 時間同步機制
在 Active Directory 網域環境中，預設情況下 DC 網域控制站便同時擔任 NTP 時間伺服器的角色。因此，ESXi 主機可以直接將 NTP 時間伺服器位址指向至 DC 網域控制站。
管理 VM 虛擬主機
當然，在單機 ESXi 主機的運作環境下管理人員可以建立 VM 虛擬主機，或者透過 OVF / OVA 檔案來部署 VM 虛擬主機，或者可以註冊現有的 VM 虛擬主機。但是，倘若管理人員希望執行某些 VM 虛擬主機進階功能，例如，vSphere vMotion 線上遷移機制……等，那麼就必須要建置 vCenter Server，同時透過 vSphere Web Client 才能進行管理及執行 vSphere vMotion 線上遷移機制。
圖 19、在單台 ESXi 主機上建立及管理 VM 虛擬主機
管理 vSwitch 虛擬網路
同樣的，在單台 ESXi 主機的運作環境下，管理人員可以管理及建立「標準型虛擬網路交換器（vNetwork Standard Switch，vSS）」，並且組態設定 Port Group 或 VMkernel Port 等虛擬網路。但是，倘若管理人員希望管理及建立「分佈式虛擬網路交換（vNetwork Distributed Switch，vDS）」的話，那麼就必須要建置 vCenter Server 並透過 vSphere Web Client 才能進行管理作業。
圖 20、管理單台 ESXi 主機上 vSwitch 虛擬網路交換器
結語
透過本文的說明及實作，相信讀者已經了解到新式 VMware Host Client 管理工具，所具備的方便性及便利性，能夠在 vCenter Server 及 vSphere Web Client 無法順利運作時，達到管理單台 ESXi 主機的目的。小型企業在使用免費版本的 VMware vSphere Hypervisor 時，也可以無須額外安裝 vSphere C# Client 管理工具，只要透過瀏覽器即可立即進行管理單台 ESXi 主機的任務。
↧
129 期 - 微軟最新軟體定義儲存，公有雲端立馬實作S2D
網管人雜誌
本文刊載於 網管人雜誌第 129 期 - 2016 年 10 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言S2D 簡介
S2D 支援的部署模式
S2D 硬體需求
S2D in Azure實戰演練
建立用於 S2D 的 vNet 虛擬網路
建立用於 S2D 的儲存體帳戶
建立 S2D 環境 DC 網域控制站
建立 S2D-Node 成員伺服器
建立 S2D 容錯移轉叢集
啟用 Storage Spaces Direct 機制
建立 vDisk 及 Volume
建立 SOFS 檔案分享資源
結語
前言
在上個月（9/26 ~ 9/30）時，微軟在 Ignite 2016 年度技術大會上正式發佈 Windows Server 2016，以及 System Center 2016 產品。在玲瑯滿目的眾多新功能當中，相信不少 IT 人員對於「軟體定義儲存（Software-Defined Storage，SDS）」技術的部分應該越越欲試，它是由 Windows Server 2012 R2 當中的「Storage Space」技術演化而來，並且在 Windows Server vNext 開發時期時稱之為「Storage Spaces Shared Nothing」，在 Windows Server 2016當中則正式稱為「Storage Spaces Direct（S2D）」。
圖 1、Storage Spaces Direct 運作架構示意圖
但是，企業或組織的 IT 管理人員可能苦無手邊沒有相關硬體資源可以進行測試而苦惱。本文，將實作演練透過 Microsoft Azure 公有雲環境，輕鬆建立 S2D 運作環境，讓 IT 管理人員無須準備任何硬體伺服器，即可實作微軟最新一代軟體定義儲存技術 S2D。
S2D 簡介
簡單來說，最新 Windows Server 2016 當中的 S2D 軟體定義儲存技術，與舊版 Windows Server 2012 R2 的 Storage Spaces 技術，最大不同在於它可以將多台硬體伺服器的「本機硬碟（Local Disk）」串聯後整合成一個巨大的儲存資源池。
圖 2、S2D軟體定義儲存技術支援本機硬碟運作架構示意圖
S2D 支援的部署模式
那麼我們來看看 S2D 軟體定義儲存技術支援哪些部署模式，以避免往後實作時發生觀念混亂的情況。在 S2D 技術中支援兩種部署模式：- 超融合式（Hyper-Converged）。
- 分類（Disaggregated）。
倘若，企業或組織希望採用「超融合式（Hyper-Converged）」部署模式，也就是將「運算（Compute）、儲存（Storage）、網路（Network）」等資源，全部都「整合」在一起並將 Hyper-V 及 S2D 技術都運作在「同一個」容錯移轉叢集環境中。那麼，屆時 VM 虛擬主機應該直接運作在 CSV 叢集共用磁碟，而非運作在 SOFS（Sacle-Out File Server）共享路徑，同時也能省去針對檔案伺服器存取及權限的部份進行組態設定，這樣的部署方式適合用於「中小型」規模的運作架構。
圖 3、S2D 超融合式部署模式運作示意圖
如果，企業或組織採用「分類（Disaggregated）」部署模式的話，那麼將會把「運算（Compute）、儲存（Storage）、網路（Network）」等資源「分開」管理，也就是將 Hyper-V 及 S2D 技術都運作在「不同」的容錯移轉叢集環境中，這樣的部署方式則適合用於「中大型」規模的運作架構。
圖 4、S2D 分類部署模式運作示意圖
請注意，在 Microsoft Azure 公有雲環境上，Windows Server 2016 主機「不支援」啟用 Hyper-V 伺服器角色。因此，在 Microsoft Azure 公有雲環境中的 S2D 軟體定義儲存技術，只能建立及使用 SOFS 檔案共享機制。
S2D 硬體需求
倘若，企業或組織的 IT 管理人員，希望在內部資料中心建置 S2D 軟體定義儲存技術的話。下列便是建立 S2D 軟體定義儲存技術時，建議採用的硬體規格及需求清單：- 叢集節點： 最少必須由 2 台叢集節點組成，最多支援至 16 台叢集節點。
- CPU / Memory： 每台叢集節點，建議至少採用 Dual-Socket CPU（Intel Xeon E5 v3 Family）及 128 GB 記憶體。
- 硬碟控制器： 每台叢集節點，必須採用 SATA Connected 或 SAS HBA Connected 硬碟控制器，不支援採用內建的 ACHI Controller 硬碟控制器，或是 RAID Controller 磁碟陣列卡。
- 硬碟數量： 每台叢集節點，最少應該使用 2 顆 SSD 固態硬碟及 4 顆機械式硬碟，並且採用下列搭配方式：
NVMe + SAS 或 SATA HDD。
SAS 或 SATA SSD + SAS 或 SATA HDD。
- 網路卡： 每台叢集節點，最少應具備 1 Port 10GbE 網路卡，並且必須支援 RDMA 特色功能（RoCE、iWARP），目前支援的網路卡廠商有 Mellanox（CX3-Pro）、Chelsio（T5）、Avago/Emulex（Skyhawk）……等。
S2D in Azure實戰演練
建立用於 S2D 的 vNet 虛擬網路
那麼，讓我們開始在 Microsoft Azure 公有雲建立 S2D 運作環境吧。登入 Microsoft Azure Portal 入口網站後，依序點選「新增 > 網路 > 虛擬網路」，請在選取部署模型下拉選單中選擇至「資源管理員」項目後按下建立鈕，在建立虛擬網路視窗中依序填入下列資訊後按下建立鈕：- 名稱： 請填入用於 S2D 運作環境的 vNet 虛擬網路名稱，本文實作環境為「EA-vNet-S2D」。
- 位址空間： 請填入此 vNet 虛擬網路的 IP 位址空間，本文實作環境為「10.10.0.0/16」。
- 子網路名稱： 請填入此 vNet 虛擬子網路的名稱，本文實作環境為「S2D-Node」。
- 子網路位址範圍： 請填入此 vNet 虛擬子網路的 IP 位址空間，本文實作環境為「10.10.75.0/24」。
- 訂用帳戶： 請選擇採用的 Azure 訂閱帳戶名稱。
- 資源群組： 此 vNet 虛擬網路要加入新建的資源群組，或加入至現有的資源群組當中。本文實作環境為建立新的資源群組，並且名稱為「RG-S2D」。
- 位置： 此 vNet 虛擬網路及資源群組所要部署的位置，本文實作環境挑選離台灣最近的資料中心「東亞」。
圖 5、建立資源群組及 vNet 虛擬網路
建立用於 S2D 的儲存體帳戶
順利建立用於 S2D 架構的虛擬網路環境後，接著建立用於 S2D 架構的儲存資源。請在 Azure Portal 入口網站中，依序點選「新增 > 資料+儲存體 > 儲存體帳戶」，在建立儲存體帳戶視窗中依序填入下列資訊後按下建立鈕：- 名稱： 請填入用於 S2D 運作環境的 Blob 儲存體帳戶名稱，本文實作環境為「eablobs2d」。
- 部署模型： 請選擇 Blob 儲存體帳戶所採用的部署類型，本文實作環境搭配新式的 vNet 儲存網路，而非傳統的 vNet 虛擬網路。因此，選擇採用「資源管理員」部署類型。
- 帳戶種類： 考量到後續此 Blob 儲存體帳戶，仍有可能整合 Blob、檔案、資料表與佇列，所以選擇採用「一般用途」帳戶種類。
- 效能： 選擇此 Blob 儲存體帳戶的效能選項，考量屆時 Azure VM 虛擬主機運作效率，因此選擇採用「進階」效能選項。
- 複寫： 選擇此 Blob 儲存體帳戶的複寫方式，預設情況下採用進階效能選擇的 Blob 儲存體帳戶，將自動採用「本地備援儲存體（LRS）」。
- 訂用帳戶： 請選擇採用的 Azure 訂閱帳戶名稱。
- 資源群組： 此 vNet 虛擬網路要加入新建的資源群組，或加入至現有的資源群組當中。本文實作環境採用剛才新建立的資源群組「RG-S2D」。
- 位置： 此 vNet 虛擬網路及資源群組所要部署的位置，本文實作環境挑選離台灣最近的資料中心「東亞」。
圖 6、建立 Blob 儲存體帳戶
建立 S2D 環境 DC 網域控制站
首先，請建立 1 台 Azure VM 虛擬主機（採用 Windows Server 2016 TP5 作業系統），以便擔任屆時 S2D 運作環境的 DC 網域控制站。請在 Azure Portal 入口網站中，依序點選「新增 > Marketplace > 虛擬機器 > Windows Server > Windows Server 2016 Technical Preview 5」，在選取部署模型下拉選單中選擇至「資源管理員」項目後按下建立鈕，在建立虛擬機器視窗中依序填入下列資訊後按下建立鈕：- 名稱： 請填入此台 Azure VM 虛擬主機的名稱，本文實作環境為「S2D-DC」。
- VM disk type： 選擇此台 Azure VM 虛擬主機的磁碟種類，考量屆時 Azure VM 虛擬主機運作效率，因此選擇採用「高階（SSD）」選項。
- 使用者名稱： 請鍵入此台 Azure VM 虛擬主機預設管理者帳號名稱，本文實作環境為「Weithenn」。
- 密碼： 請鍵入此台 Azure VM 虛擬主機預設管理者密碼。
- 確認密碼： 請再次鍵入此台 Azure VM 虛擬主機預設管理者密碼，以確認 2 次管理者密碼皆鍵入相同無誤。
- 訂用帳戶： 請選擇採用的 Azure 訂閱帳戶名稱。
- 資源群組： 此 vNet 虛擬網路要加入新建的資源群組，或加入至現有的資源群組當中。本文實作環境採用剛才新建立的資源群組「RG-S2D」。
- 位置： 此 vNet 虛擬網路及資源群組所要部署的位置，本文實作環境挑選離台灣最近的資料中心「東亞」。
圖 7、建立 Azure VM 虛擬主機
請注意，本文在撰寫時 Azure 公有雲的 Makeplace 當中，仍僅提供 Windows Server 2016 TP5技術預覽版本。因此，倘若你採用如同本文的建置方式，則建置好的 S2D 軟體定義儲存資源，應該僅使用於測試或研發環境而非線上營運環境。接著，在選擇 VM 虛擬主機規模大小的視窗中，選擇此 VM 虛擬主機的運作規模。本文實作環境中選擇採用「DS1 標準」的 VM 虛擬主機規模後，請按下「選取」鈕。
圖 8、選擇 Azure VM 虛擬主機採用的規模大小
建立 Azure VM 虛擬主機的第 3 個步驟，選擇此台 VM 虛擬主機採用的儲存體帳戶、vNet 虛擬網路……等資訊，請依序選擇下列相關資訊後按下確定鈕：
- 儲存體帳戶： 請選擇此台 Azure VM 虛擬主機採用的儲存體帳戶，本文實作環境選擇剛才建立的「eablobs2d」儲存體帳戶。
- 虛擬網路： 請選擇此台 Azure VM 虛擬主機採用的 vNet 虛擬網路，本文實作環境為選擇剛才建立的「EA-vNet-S2D」虛擬網路。
- 子網路： 請選擇此台 Azure VM 虛擬主機採用的 vNet 虛擬網路子網段，本文實作環境選擇剛才建立的「S2D-Node（10.10.75.0/24）」虛擬子網路。
- 公用 IP 位址： 啟用此台 Azure VM 虛擬主機採用 Public IP 位址，以便屆時可由網際網路透過 RDP 遠端桌面連線進行管理，本文實作環境定義名稱為「S2D-DC-PIP」。
- 網路安全性群組： 定義此台 Azure VM 虛擬主機的防火牆規則，預設情況下只會開啟「RDP（TCP / 3389）」防火牆輸入規則，本文實作環境定義名稱為「S2D-DC-NSG」。
- 擴充功能： 選擇 Azure VM 虛擬主機是否安裝其它擴充功能，例如，Microsoft Antimalware。本文實作環境未選擇安裝任何擴充功能。
- 可用性設定組： 在 Azure 公有雲環境中的 VM 虛擬主機，倘若需要可用性則需要建立可用性設定組。考量後續 S2D 運作環境的可用性，應該要建立 2 台 DC 網域控制站，因此建立名稱為「AS-S2D-DC」的可用性設定組。
- 監控： 是否針對 VM 虛擬主機啟用監控機制，預設情況下便會為 VM 虛擬主機啟用監控機制。
- 診斷儲存體帳戶： 將 Azure VM 虛擬主機的診斷資料寫入至儲存體帳戶中，本文實作環境定義名稱為「eablobs2ddiag」。
圖 9、組態設定 Azure VM 虛擬主機選擇性功能
在建立 Azure VM 虛擬主機的最後步驟中，確認相關資訊無誤後便可以按下確定鈕，執行建立 Azure VM 虛擬主機的動作。
圖 10、建立 Azure VM 虛擬主機
當 Azure 公有雲環境的 VM 虛擬主機部署完成後，便可以準備將這台單機 VM 虛擬主機提升為 DC 網域控制站。值得注意的是，與「內部部署（On-Premise）」DC 網域控制站不同的地方，需要建立「額外」的資料磁碟來儲存 AD 資料庫、記錄檔及 SYSVOL。請在 Azure Portal 管理介面中，依序點選「S2D-DC > 設定 > 磁碟 > 連結新項目」，在連結新磁碟視窗中依序填入及點選填入下列資訊後按下建立鈕：
- 名稱： 請鍵入 S2D-DC 虛擬主機新增的資料磁碟名稱，本文實作環境為「S2D-DC-Database-Disk」。
- 類型： 因為此資料磁碟僅用於儲存 AD 資料庫、記錄檔及 SYSVOL，因此採用預設的「標準」類型即可。
- 大小： 此資料磁碟儲存空間大小，本文實作環境為「10 GiB」。
- 位置： 指定將此新增的資料磁碟，存放至先前所建立的「eablobs2ddiag」Blob 儲存體當中。
- 主機快取： 由於儲存 AD 資料庫、記錄檔及 SYSVOL 等資料，並不適合使用主機快取機制因此請選擇至「無」。
圖 11、為 S2D-DC 新增資料磁碟以便存放 AD 資料庫、記錄檔及 SYSVOL
完成建立及掛載空的資料磁碟後，便可以將該資料磁碟進行「初始化（Initialize）」及「格式化（New Volume）」的動作。值得注意的是，存放 AD 資料庫、記錄檔及 SYSVOL 的分割區，檔案系統必須採用「NTFS」才行，並不支援採用新式的「ReFS」檔案系統。
預設情況下，Windows Server 2016 主機掛載的資料磁碟，將會採用新式的「ReFS」檔案系統進行分割區格式化的動作。
最後，預設情況下 Azure VM 虛擬主機會採用「動態」IP 位址，但這樣可能會影響 DC 網域控制站的運作，因此請為 S2D-DC 虛擬主機設定採用「靜態」IP 位址。請依序點選「S2D-DC > 設定 > 網路介面 > IP configurations > ipconfig1」，在 ipconfig1 視窗中請在指派區由預設的動態選擇至「靜態」，然後按下儲存圖示即可。
圖 12、為 S2D-DC 虛擬主機指派使用固定 IP 位址
之後便可以如同內部部署方式，將 S2D-DC 虛擬主機提升為 DC 網域控制站（本文實作網域名稱為 s2d.weithenn.org）。值得注意的是，在提升成為 DC 網域控制站的過程中，記得將 AD 資料庫、記錄檔及 SYSVOL 的分割區指向至剛才新增的資料磁碟（本文實作環境為 F 槽）。
圖 13、將 AD 資料庫、記錄檔及 SYSVOL 指向至新增的資料磁碟 F 槽
當 S2D-DC 成功擔任 DC 網域控制站後，記得以網域管理員身分登入 S2D-DC 主機，然後開啟 DNS 管理員將預設的 Forwarders 設定刪除。然後，回到 Azure Portal 頁面中，為 S2D 使用的 vNet 虛擬網路指定採用的 DNS 伺服器。在本文實作環境中，為「EA-vNet-S2D」虛擬網路指定的 DNS 伺服器為「S2D-DC（10.10.75.4）」。
圖 14、為 vNet 虛擬網路指定使用的 DNS 伺服器 IP 位址
建立 S2D-Node 成員伺服器
在本文實作環境中，我們建立「3 台」S2D-Node 成員伺服器，分別命名為「S2D-Node01、S2D-Node02、S2D-Node03」。由於建立 S2D-Node 虛擬主機的操作步驟，與剛才建立 S2D-DC 虛擬主機大致相同因此便不再贅述。唯一不同的部分是每台 S2D-Node 成員伺服器，屆時將會新增「3 顆」資料磁碟，因此在 VM 虛擬主機規模大小視窗中，選擇採用「DS2標準」的運作規模。順利部署 3 台 S2D-Node 成員伺服器後，請幫每台 S2D-Node 主機新增「3 顆」資料磁碟，並且加入剛才所建立的「s2d.weithenn.org」網域環境。
圖 15、將 3 台 S2D-Node 成員主機加入 s2d.weithenn.org 網域環境
建立 S2D 容錯移轉叢集
請使用伺服器管理，為 3 台 S2D-Node 成員主機安裝「容錯移轉叢集」伺服器功能，或使用 PowerShell 指令一次幫 3 台主機進行安裝伺服器功能的動作。
圖 16、使用 PowerShell 指令，快速幫 3 台 S2D-Node 成員主機安裝容錯移轉叢集伺服器功能
接著，請開啟容錯移轉叢集管理員建立 S2D 容錯移轉叢集，或使用 PowerShell 指令快速建立 S2D 容錯移轉叢集。本文實作環境中，指定 S2D 容錯移轉叢集名稱為「S2D-Cluster」，而容錯移轉集的固定 IP 位址為「10.10.75.10」。
圖 17、使用 PowerShell 指令，建立 S2D 容錯移轉叢集
順利建立 S2D 容錯移轉叢集後，便可以開啟容錯移轉叢集管理員確認相關運作狀態是否正常，例如，叢集核心資源是否正確進行組態設定作業，並且運作狀態為「線上（Online）」。
圖 18、確認 S2D 容錯移轉叢集運作狀態正確無誤
啟用 Storage Spaces Direct 機制
在啟用 S2D（Storage Spaces Direct）機制之前，先確認是否可以看到加入 S2D 叢集中所有 S2D-Node 主機的磁碟數量。舉例來說，本文實作環境中每台 S2D-Node 叢集節點掛載 3 顆磁碟，因此應該看到總數「9 顆」磁碟才正確。請使用 PowerShell 指令「Get-PhysicalDisk」，確認 S2D 叢集中磁碟總數量。
圖 19、使用 PowerShell 指令確認 S2D 叢集中磁碟總數量
因為，此 S2D 軟體定義儲存運作環境為 Azure 公有雲的 VM 虛擬主機，所以磁碟的「媒體類型（MediaType）」判定為「UnSpecified」，因此在我們建立 S2D 機制時，執行的 PowerShell 指令「Enable-ClusterS2D」必須加上額外參數處理，例如，停用 S2D 的快取模式及略過自動組態設定機制。
圖 20、執行 PowerShell 指令 Enable-ClusterS2D 建立 S2D 軟體定義儲存環境
因為在剛才執行 Enable-ClusterS2D 指令時，我們略過自動組態設定機制，所以必須手動執行「New-StoragePool」指令，建立 S2D 的 Storage Pool 部分。也就是將 3 台 S2D-Node 共 9 顆磁碟串聯成 1 個大的儲存資源池。
圖 21、執行 PowerShell 指令建立 S2D Storage Pool
順利建立好 S2D Storage Pool 之後，我們就可以處理剛才磁碟 MediaType 的問題了。請執行 PowerShell 指令「Get-StorageSubsystem」，將剛才磁碟 MediaType 判斷為 UnSpecified 的部分，手動指定為「HDD」。
圖 22、手動指定磁碟的 MediaType 為 HDD
建立 vDisk 及 Volume
現在，我們可以放心在 S2D 叢集運作環境中，分別建立具備 2 份鏡像資料（2-Way Mirror），以及 3 份鏡像資料（3-Way Mirror）的 vDisk 及 Volume。在下列執行的 PowerShell 指令「New-Volume」中，我們將會分別建立名稱為「2Way-vDisk」以及「3Way-vDisk」的 S2D 叢集共用磁碟，同時這個 S2D Volume 將會採用最新的「ReFS」檔案系統。
圖 23、建立 2 份及 3 份鏡像資料的 vDisk 及 Volume
建立 2 份鏡像資料的 vDisk 倘若指派的空間為 10 GB，那麼實際佔用的儲存空間將為 20 GB，建立 3 份鏡像資料的 vDisk 則佔用的儲存空間為 30 GB。鏡像資料將由 S2D 機制的演算法進行管理，實際上使用以及看到的儲存空間仍為 10 GB。
順利建立 2 份及 3 份鏡像資料的 vDisk 及 Volume 之後，在容錯移轉叢集管理員中當然也可以順利看到 Storage Disk 等相關資訊。
圖 24、透過容錯移轉叢集管理員管理介面，查看 S2D Storage Disk 資訊
建立 SOFS 檔案分享資源
最後，請為 3 台 S2D-Node 叢集節點主機安裝「檔案伺服器」角色，並且新增高可用性檔案伺服器角色，在本文實作環境中名稱為「S2D-SOFS」。接著，便可以新增 SOFS 檔案分享資源並且設定資料夾的存取權限，在本文實作環境中建立的分享資料夾名稱為「Share」，組態設定完畢後便可以開啟檔案總管，嘗試放入測試檔案至 S2D 所建立的 SOFS 分享資料夾。
圖 25、測試能否順利放入測試檔案至 S2D 所建立的 SOFS 分享資料夾
結語
透過本文的說明及實作演練，即使手邊沒有相關硬體資源可供利用的 IT 管理人員，也可以透過 Microsoft Azure 公有雲，輕鬆建立及測試微軟新一代 S2D 軟體定義儲存技術。↧
VMware Free Hypervisor 相關限制
前言
舊版的 vSphere Free Hypervisor 有著相關限制，例如，實體記憶體僅支援至 32GB。目前，新版 vSphere Hypervisor 6.0已經放寬相關限制 (實體記憶體已經不再限制容量)，下列為限制資訊：Management
- 技術支援： 必須額外購買 Per Incident Support。
- vSphere Free Hypervisor 無法被 vCenter Server 所納管。
Physical Server
- CPU / Cores： 無限制 (1、2、4 或以上)。
- Logical CPU： 480。
- Memory： 無限制 (最低 4GB 或以上)。
Virtual Machine
- vCPU： 8。
- vRAM： 未載明。
參考來源
↧
↧
[站長開講] 私有雲規劃與建置 - VMware 實務班
課程簡介
- 了解建置私有雲運作環境時對於實體的 網路、儲存、交換器…等設備該如何進行規劃，並且會帶來何種影響。
- 了解在規劃私有雲環境時應該如何針對虛擬網路、儲存、交換器…等，將網路流量統一集中或者依服務類型進行切割，同時導入流量管控機制以達成網路與頻寬最佳利用率。
- 了解在規劃私有雲環境時對於何種使用情境，適合採用哪種儲存設備類型如 DAS、NAS、SAN。
課程資訊
時間： 每週六 09:00 ~ 12:00、13:30 ~ 16:30地點：國立臺北商業大學 (臺北市中正區濟南路一段321號)
日期： 2016/11/12 ~ 2016/12/17
網址： 私有雲規劃與建置 VMware 實務班
↧
VMware vSphere 6.5 新功能簡介
前言
在 2016 年 10 月 18 日，VMware 官方正式宣佈推出最新 vSphere 6.5虛擬化平台解決方案，此版本中包含新增內建安全性以及可運作任何應用程式的通用應用程式平台。同時，最新發佈的「VMware Cloud Foundation」、「VMware Cloud on AWS」等，也都是採用最新 vSphere 6.5 版本所建構。那麼，讓我們來看看最新 vSphere 6.5 虛擬化平台解決方案，提供哪些新增特色功能以及管理體驗。極簡化的管理體驗
最新 vSphere 6.5 解決方案，將 vCSA (vCenter Server Appliance)打造成 vSphere 環境的基本建構。現在，vCSA 有效整合 Host Management、vSphere Update Manager、High Availability……等，與舊有的 vCSA 相較下支援的運作規模「超過 2 倍」運作效能「提升 3 倍」。
在 vSphere 6.5 版本中，導入「REST-based APIs for VM Management」管理機制，讓企業及組織的管理人員能夠透過簡單的 API 進行管理及維運作業。此外，過去 vSphere Web Client 管理工具是以 Flash-based為主。現在，新版 vSphere 6.5 的 vSphere Web Client 管理工具改為採用「HTML5-based」技術。
內建安全性
在新版 vSphere 6.5 當中，新增「VM-Level Disk Encryption」機制以便保護 VM 虛擬主機中的機敏資料。同時，此加密機制整合原有的 vSphere Storage Policy Framework 及 Encrypted vMotion 機制，讓 VM 虛擬主機具有可移動性同時不失資料安全性。同時，為了防止 VM 虛擬主機遭受 RootKit 等攻擊行為，新版 vSphere 6.5 支援「Secure Boot Model」，以防止未經授權的運作元件被載入，進而影響到 VM 虛擬主機的安全性。此外，在新版 vSphere 6.5 當中增強「Audit-Quality Logging」機制，提供更多使用者身分認證資訊，讓 IT 管理人員可以更深入了解「誰」做了「什麼事情」。
通用的應用程式平台
新版 vSphere 6.5 運作環境中，將更全面支援傳統及新世代應用程式，包括 Hadoop、Spark、Machine Learning、HPC……等。同時，在新版 vSphere 6.5 中更新增「vSphere Integrated Containers」技術，讓開發人員 (Dev)及維運人員 (Ops)能夠更容易使用容器技術。在 vSphere 6.5 版本中的容器技術是由下列 3 個運作元件所組成：- Engine： 提供 Core Container Run-time。
- Harbor： 提供 Enterprise Registry for Container Images 機制。
- Admiral： 提供開發團院 Container 管理的 Portal 入口網站。
參考資源
↧
實作 Hyper-V Nested Virtualization
前言
在 Hyper-V 虛擬化化平台舊版本中，要實作出 Nested Virtualization環境非常困難。現在，Windows Server 2016 直接內建支援「Nested Virtualization in Windows Server Hyper-V」機制，往後 IT 管理人員建置 Lab 環境將更方便了。簡單來說，在舊版的 Hyper-V 虛擬化平台當中僅支援 Level 0、Level 1這樣的運作架構。
現在，可以在 Hyper-V Hypervisor (Level 1) 當中，再產生出一層 Guest Hypervisor (Level 2) 並且能夠運作 Guest OS，甚至 Level 2 的 VM 虛擬主機還能再次產生出一層 Guest Hypervisor (Level 3)並運作 Guest OS。
下列為目前 Hyper-V Nested Virtualization 的環境需求及相關限制：
- 實體主機 CPU 必須支援 Intel VT-x 及 EPT硬體輔助虛擬化技術，作業系統必須採用 Windows 10 年度更新版 (Enterprise, Professional, Education) 或 Windows Server 2016 (Standard, Datacenter)。
- 必須為擔任 Guest Hypervisor 的 VM 虛擬主機啟用 vCPU Virtualization Extensions 功能。
- 必須為擔任 Guest Hypervisor 啟用 MAC Address Spoofing功能，否則屆時建立的 Guest OS 網路連線會發生不通的情況。
- 必須為擔任 Guest Hypervisor 採用第 2 世代及 8.0版本格式的 VM 虛擬主機。
- 必須要停用 VM 動態記憶體功能，同時為 VM 虛擬主機執行 Runtime Memory Resize 的動作時會失敗。
實作 Hyper-V Nested Virtualization
首先，我們可以看到在 Level 1的 Hyper-V Host 中，所建立的 VM 虛擬主機採用 Coreinfo檢查後可以發現，目前的 VM 虛擬主機「尚未感知」到母體的虛擬化功能。同時，當你嘗試為 VM 虛擬主機 (準備擔任 Guest Hypervisor) 安裝 Hyper-V 伺服器角色時，將會發現無法順利安裝。
請在 Level 1 的 Hyper-V Host 中，執行下列指令將 Hyper-V Host 的硬體輔助虛擬化技術「傳遞」給 VM 虛擬主機 (此實作該 VM 的名稱為 WS2016-Nested，當然前提是 Hyper-V Host支援 Intel VT-x / EPT硬體輔助虛擬化技術)。但是，請先將準備擔任 Guest Hypervisor 的 VM 虛擬主機關機，倘若 VM 虛擬主機未關機的話，稍後執行 vCPU Virtualization Extensions 的動作時，將會發生 PowerShell 指令執行失敗的情況。
順利將擔任 Guest Hypervisor 的 VM 虛擬主機關機後，便可以執行 PowerShell 指令「Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true」，為 Guest Hypervisor 的 VM 虛擬主機 (此實作中名稱為 WS2016-Nested)啟用「vCPU Virtualization Extenstions」的功能。
此時，重新將擔任 Guest Hypervisor 的 VM 虛擬主機 (WS2016-Nested) 開機後，再度使用 Coreinfo檢查後可以發現，目前已經可以「感知」到 Hyper-V Host 所傳遞過來的硬體輔助虛擬化技術。當然，也就可以順利安裝 Hyper-V 伺服器角色了。
至此，我們完成為 Level 1 的 VM 虛擬主機啟用 Guest Hypervisor 功能。記得，啟用 MAC Address Spoofing 功能，否則屆時建立的 Guest OS 網路連線會發生不通的情況。
下列為 Hyper-V Nested Virtualization 巢狀虛擬化實作階層說明：
Level 1 (實體伺服器、Hyper-V Hypervisor、Guardhost01)
Level 2 (Guest Hypervisor、WS2016-Nested)
Level 3 (Guest OS、WS2016)
同樣的組態設定方式，我們可以為 Level 3 的 VM 虛擬主機啟用 Guest Hypervisor 功能，建立出 Level 4 的 VM 虛擬。
下列為 Hyper-V Nested Virtualization 巢狀虛擬化實作階層說明：
Level 1 (實體伺服器、Hyper-V Hypervisor、Guardhost01)
Level 2 (Guest Hypervisor、WS2016-Nested)
Level 3 (Guest Hypervisor、WS2016)
Level 4 (Guest OS、WS2016-Inner)
參考資源
↧
vCenter Server 6.5 新功能簡介
前言
在本篇文章當中，我們將介紹在 vSphere 6.5版本當中全新打造的 vCSA(vCenter Server Appliance)，除了在安裝方式簡化、管理工具 vSphere Web Client 改採「HTML5-based」技術之外，新版的 vCSA 也支援下列特色功能：- vCenter Server 平台遷移
- 增強 vCSA 管理功能
- vCSA 原生 HA(High Availability) 機制
- 內建備份/還原機制
vCenter Server 平台遷移
拜雲端運算風潮所賜，在企業或組織當中早已經建立 vCenter Server 管理平台。或許，IT 管理人員可能希望嘗試使用 vCSA，但是目前所管理的 vSphere 虛擬化運作環境中，已經採用安裝於 Windows Server 作業系統的 vCenter Server。事實上，VMware 官方早已經推出 vCenter Server 平台遷移工具，最新的遷移版本為 vCenter Server Migration Tool: vSphere 6.0 Update 2m，同時在新版遷移工具中支援遷移的目標對象為「Windows vCenter Server 5.5、6.0」。因此，即便企業及組織已經建立最新的 Windows vCenter Server 6.0，仍可以透過 vCenter Server 遷移工具將 vCenter Server 管理平台遷移至最新的 vCSA 6.5 版本中。此外，新版的 vCenter Server 遷移工具支援更細緻的遷移選項：
- Configuration
- Configuration、Events、Tasks
- Configuration、Events、Tasks、Performance Metrics
增強 vCSA 管理功能
在過去，當企業或組織需要建置 VUM (VMware Update Manager)時，只能直接安裝在 Windows vCenter Server 或獨立的 Windows Server 主機中，並無法將 VUM 安裝在 vCSA 當中。現在，最新版本的 vCSA 6.5 已經具備 VUM 的功能，倘若你已經遷移運作環境至 vCSA 6.0 的話，那麼升級至最新 vCSA 6.5 版本時，遷移程序將會自動轉換 vCenter Configuration、Inventory、Alarm Data 等組態設定及統計數據。新版 vCSA 6.5 在管理功能上也增強許多。現在，可以直接在 vCSA 管理介面中查看 CPU、記憶體、網路、資料庫、磁碟空間……等使用情況，有效改善過去 vCSA 欲查看這些硬體資源使用情況時必須依賴 CLI 指令的情況。
vCSA 原生 HA(High Availability) 機制
在最新版本的 vCSA 6.5 當中，VMware 官方為 vCSA 打造原生 HA(High Availability) 機制，這個 HA 機制是由「Active、Passive、Witness」成員節點所組成。當 vCenter HA Cluster 某個成員節點發生災難事件時 (例如，擔任 Active 角色的成員節點主機發生硬體故障)，便會觸發 vCenter HA 機制。目前，vCSA HA 機制的 RTO預計為「5 分鐘」，當然實際上必須視底層硬體資源的工作負載情況而定。
內建備份/還原機制
新版 vCSA 也同時內建「備份 / 還原」功能，讓管理人員可以直接透過 VAMI 或 API 的方式備份 vCenter Server 及 PSC (Platform Services Controller)，不管 PSC是採用「Embedded」或「External」的運作模式都支援。同時，當 VUM和 Auto Deploy採用「Embedded」也可以同步進行備份作業。此外，備份好的資料可以選擇透過 SCP、HTTP(s)、FTP(s)等通訊協定傳輸備份資料至儲存設備中。vSphere Web Client 管理工具
過去 vSphere Web Client 管理工具，最被管理人員垢病的就是採用「Adobe Flex 平台 - Adobe Flash-based」技術，除了管理介面操作速度不理想之外，Flash 也常常有安全性問題的疑慮。但是，在新版 vCSA 6.5 當中仍持續改進相關機制直到退役為止 (後續將由 HTML 5-based打造的管理工具接手)：
- 預設檢視模式為 Inventory Tree。
- 原本「Manage」頁籤改名為「Configure」。
- 移除「Related Objects」頁籤，並多出「Hosts、VMs、Datastores、Networks」等頁籤。
- 管理介面運作效能改進 (VM 虛擬主機匯總功能並非舊版 50 VMs而是 5,000 VMs)。
- 管理介面將即時更新電力狀態、工作任務……等 (舊版必須手動更新更面)。
vSphere Client 管理工具
現在，新版 vCSA 6.5 的 vSphere Client 管理工具，也已經內建由「HTML 5-based」技術所打造 vSphere Client 管理工具，管理人員只要開啟瀏覽器後鍵入「http://<vCenter_FQDN>/ui」即可連結。同時，VMware 官方除了正常的 vCenter Server 發行週期之外，也會定期更新 vSphere Client 管理工具版本 (有關管理單台 ESXi 的 vSphere Host Client 管理工具詳細資訊，請參考站內文章 128 期 - 最新 VMware Host Client 直接管理單台 ESXi 主機)。
參考資源
↧
↧
vSphere 6.5 Security 新功能簡介
前言
在新一代 vSphere 6.5 虛擬化平台中，針對「安全性」(Security)的部分新增許多特色功能。同時，在兼顧安全性的同時又不失「管理」(Management)及「自動化」(Automation)等特性，如此一來才會讓企業及組織能夠順利及樂意使用這些安全性功能。VM Encryption
雖然，加密 VM 虛擬主機的機敏資料是多年來一直在進行的事情，但每個解決方案都有不足或造成困擾的部分。在最新 vSphere 6.5 虛擬化平台中，我們希望能夠解決這個問題。加密的對象將針對「VM Home Files (VMX, Snapshot…etc)」以及「VMDK 虛擬磁碟」都會進行加密。並且，當「資料 I/O」從VM 虛擬主機的 vHBA 虛擬磁碟控制器出來時，再傳送到「Kernel Storage Layer」之前就會進行加密的動作。透過 VM Encryption 加密機制可以獲得的優點如下：
1. 加密行為是發生在「Hypervisor 層級」而非 VM 虛擬主機層級，所以 Guest OS 及 Datastore 類型不會是影響加密的因素。
2. 加密機制是透過「原則」(Policy)來進行部署及管理作業。簡單來說，不管 VM 虛擬主機採用哪種 Guest OS 都可以進行加密。
3. 由於加密機制是在 Hypervisor 層級，所以不必監控 VM 虛擬主機是否有運作加密機制，同時「加密金鑰」(Key)也不會儲存在 VM 虛擬主機的記憶體當中。
4. 加密金鑰的管理作業是採用業界標準的「KMIP 1.1」，其中 vCenter Server 就是 KMIP Client 也是 KMIP 1.1 Key Manager。同時，管理人員也可以選擇 VM Keys 不要儲存在 vCenter Server 中。
5. 在 vSphere 6.5 當中 VM Encryption，採用 CPU 指令集中的「AES-NI」來進行加密的動作。此舉，可以有效降低 ESXi 主機的工作負載。
vMotion Encryption
針對 vMotion 傳輸流量進行加密的要求其實已經很長一段時間，現在開始於新一代 vSphere 6.5 虛擬化平台中正式提供此功能。此外，在這個版本中的「vMotion Encryption」並非加密網路所以無須管理憑證或其它網路組態設定。加密是針對「每台 VM」層級，當 VM 虛擬主機啟用 vMotion Encryption 機制後，倘若針對該 VM 虛擬主機進行 vMotion 線上遷移作業時，vCenter Server 將會「隨機產生」(Randomly Generated) 1個「One time 256-bit Key」(請注意，此加密金鑰並不會採用 vCenter Server Key Manager 產生)。
除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」，所以當進行 VM 虛擬主機 vMotion 線上遷移作業時，將會打包「256-bit Key 加上 64-bit 隨機數」在「2 台 ESXi 主機」之間，以確保兩端之間通訊所傳輸的資料無法被惡意人士所複製。
支援 Secure Boot
在新一代 vSphere 6.5 虛擬化平台中，同時支援「ESXi Hypervisor」及「VM 虛擬主機」啟用「安全啟動」(Secure Boot)機制。ESXi - Secure Boot
當管理人員為 ESXi 主機啟用 Secure Boot 機制後，在 UEFI Firmware 中將會針對 ESXi Kernel 進行數位簽章的動作，確保只有通過安全認證的模組或 VIB 軟體套用包才能被啟動及使用。值得注意的是，當 ESXi 主機啟用 Secure Boot 機制後，只能在 ESXi 主機上安裝由 VMware 所簽署的 VIB (vSphere Installation Bundle)套件包，其它 VIB 套件包則是無法強制進行安裝的。
VM - Secure Boot
首先，不管 VM 虛擬主機採用的是 Windows 或 Linux 作業系統，只要針對 VM 虛擬主機使用「EFI」後便可以勾選啟用 Secure Boot 機制。同樣的，當 VM 虛擬主機啟用 Secure Boot 機制之後，那麼只能安裝「通過簽署」的驅動程式。
增強的日誌機制
在過去 vSphere 的日誌機制，一直專注於故障排除的部分而未包含「安全」或「IT 操作」的部分。現在，可以得到詳細的日誌並透過 Syslog 機制，將 vCenter Server 的日誌傳送到 Vmware Log Insight。舉例來說，假設有台 VM 虛擬主機原本 vRAM 為 6GB，然後我們為它增加「4 GB」的 vRAM 空間此時便可以在日誌中看到相關資訊，或者是 VM 原本連接的 vSwitch 為 PCI 異動至「Non-PCI」 也將會詳細記錄下來。
自動化
後續，將會看到自動化作業的相關文件，例如，透過 PowerCLI達到針對 VM 虛擬主機自動化加密及解密、針對大量 VM 虛擬主機同時啟用 Secure Boot 安全啟動機制、針對 VM 虛擬主機啟用 vMotion Encrypted……等。同時，這些自動化指令碼範例也將會上傳至 GitHub 中。參考資源
- VMware vSphere Blog - What's new in vSphere 6.5: Security
- 進階加密指令集和安全金鑰構成 Intel® 資料保護技術 (Intel® Data Protection Technology)
- Intel Software - INTRODUCTION TO INTEL AES-NI AND INTEL SECURE KEY INSTRUCTIONS
- Intel - Advanced Encryption Standard Instructions (AES-NI)
- Intel AES-NI Ecosystem (March 2013 update)
↧
vSphere 6.5 Storage 新功能簡介
前言
在目前主流的 vSphere 5.5 及 6.0 版本當中，所採用的 VMFS 檔案系統版本為「5」。在最新 VMware vSphere 6.5 版本當中則採用「VMFS 6」，下列便是 VMFS 6 的新增功能項目：- 支援 4K Native Drives in 512e運作模式。
- 預設採用 SE Sparse格式的虛擬磁碟，以便自動化執行空間回收機制。
- 最大支援 512個儲存裝置及 2,000路徑 (舊版為 256 個儲存裝置及 1,024 路徑)。
- CBRC (View Storage Accelerator) 空間由舊版的最大 2 GB 提升為 32 GB。
支援 4K Native Drives in 512e 運作模式
新式硬碟 (理論上 2011 年 1 月起出廠的硬碟) 的進階格式為「4K Byte Sector」而非舊有的「512 Byte Sector」。因此，從 vSphere 6.5 版本開始支援由 512e 模擬 4K 的方式運作。但是 Virtual SAN 6.5目前仍僅支援 512e 運作模式，相信後續版本便有可能全面支援 4K Byte Sector。有關 4K / 512 Byte Sector 的相關資訊請參考 FAQ: Support statement for 512e and 4K Native drives for VMware vSphere and vSAN (2091600)。
預設採用 SE Sparse 虛擬磁碟格式
在最新版本 vSphere 6.5 當中採用的 VMFS 6檔案系統，預設情況下便會採用「SE Sparse」虛擬磁碟格式。有關 SE Sparse 虛擬磁碟格式的功能說明，請參考：- VMware White Paper – VMware Horizon 6 Storage Considerations
- CormacHogan.com - vSphere 5.1 Storage Enhancements - Part 2: SE Sparse Disks
- VMware End-User Computing Blog - Space Efficient Virtual Disks
事實上，這是基於「VAAI Unmap」運作機制並且已經運作一段時間了。簡單來說，就是空白的儲存空間可以被回收並釋放回儲存設備當中，在先前舊版 vSphere 的運作環境中，通常需要管理人員手動執行相關指令來執行空間回收的動作。現在，只要透過 GUI 圖形化操作介面即可達成。
如果，你還是習慣使用「esxcli」指令處理的話，那麼可以執行下列指令： (下列範例中 Datastore 名稱為 sharedVmfs-0)
esxcli storage vmfs reclaim config get -l sharedVmfs-0
Reclaim Granularity: 1048576 Bytes
Reclaim Priority: low
也可以透過「esxcli」指令將儲存層級調整為「High」：
esxcli storage vmfs reclaim config set -l sharedVmfs-0 -p high
最大支援 512 個 LUN 儲存裝置及 2,000 路徑
過去，在舊版 vSphere 運作環境中最大僅支援「256 個 LUN 儲存裝置」及「1,024 路徑」。現在，最新版本 vSphere 6.5運作環境中擴大支援至「512 個 LUN 儲存裝置」及「2,000 路徑」。CBRC aka View Storage Accelerator
在過去 CBRC (在 VDI 運作環境中稱之為 View Storage Accelerator) 最大僅支援至「2 GB」。現在，最新版本 vSphere 6.5 運作環境中擴大支援至「32 GB」。有關 CBRC 快取機制的相關資訊請參考站內文章：
參考資源
- Yellow Bricks - vSphere 6.5 what's new - VMFS 6 / Core Storage
- VMware End-User Computing Blog - Space Efficient Virtual Disks
- VMware White Paper - SEsparse in VMware vSphere 5.5
- CormacHogan.com - vSphere 5.1 Storage Enhancements - Part 2: SE Sparse Disks
- Microsoft 的 Windows 4K 磁區硬碟的支援政策
- Seagate - 先進格式 4K 磁區硬碟機轉換
↧
VMware vSphere 6.5 攻略 - 系列文章
前言
在 VMware VMworld 2016 大會上，由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出，並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈，同時提供相關新版產品映像檔的下載。站長將不定期撰寫相關新功能簡介文章：
【簡介】
【vCenter Server】
【Security】
【Storage】
↧
130 期 - 詳解實體及虛擬網路架構，完美實作 VSAN 環境
網管人雜誌
本文刊載於 網管人雜誌第 130 期 - 2016 年 11 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言實體網路基礎架構
Leaf-Spine 網路架構
建立多路徑路由環境
IP MultiCast
網路安全性
實體網路卡配置
虛擬網路架構
vSwitch 虛擬網路交換器
VMkernel Port
停用流量管控機制
NIC Teaming
Jumbo Frames
Switch Discovery Protocol
結語
前言
在 VMware 所擘劃的 SDDC 軟體定義資料中心願景中，在 SDC 軟體定義運算的部分由 vSphere ESXi 虛擬化平台擔綱，而在 SDN 軟體定義網路的部分為 NSX 虛擬化平台解決方案，在 SDS 軟體定義儲存的部分，便是由 VMware Virtual SAN（簡稱 VSAN）負責。
圖 1、VMware SDDC 軟體定義資料中心願景
簡單來說，透過 VMware VSAN 技術便能夠將多台 x86 實體伺服器中，配置於實體伺服器的「本機硬碟（Local Hard Disk）」串連起來，進而將叢集當中所有叢集節點主機的儲存資源整合起來，成為一個巨大的儲存資源池並且能夠互相共用。
同時，為了提供足以運作大型運作規模的軟體定義儲存資源，因此 VSAN 支援採用「Hybrid」儲存資源運作架構，將快取資料存放於快閃式儲存（例如，SSH / NVMe）中，至於儲存資料則放於一般機械式硬碟內。倘若，需要更高的儲存效能則可以建置「All-Flash」運作架構，也就是連同資料儲存空間的部分也交由一般的 SSD 固態硬碟負責。
圖 2、VSAN 運作架構示意圖
目前，VMware VSAN 最新釋出為 6.2 版本（第 4 代 VSAN），除了原有加強監控 IOPS 效能及健康狀況外，同時也推出重複資料刪除與壓縮 、EC 編碼技術和 QoS 品質管控機制。在本文中，我們將從實體網路環境至 vSphere 虛擬化環境，深入剖析最佳規劃設計準則及相關組態設定建議，以便幫助企業及組織的管理人員打造高可用效高效能的 VSAN 運作環境。
圖 3、VSAN 版本演進及功能進化示意圖
實體網路基礎架構
在資料中心網路基礎架構中，傳統網路環境採用「Access-Aggregation-Core」的 3 層式架構，以便處理資料中心內「南 - 北（North - South）」的網路流量，同時為了避免網路環境發生「迴圈（Looping）」的情況，通常會啟用 STP（Spanning Tree Protocol）機制防止網路環境發生迴圈的情況，但也等同於將網路的整體頻寬限制在 50 %。然而，隨著虛擬化及雲端運算不斷的發展，現代化資料中心的網路架構已經改為採用架構簡單 、 可擴充性 、 高網路頻寬 、 容錯機制和 QoS 網路流量管控的「Leaf-Spine」2 層式架構。不管採用哪一種網路環境及基礎架構，在 VMware VSAN 運作環境中皆支援舊式的 3 層式網路架構或新式的 2 層式網路架構。
圖 4、 傳統 3 層式架構（Access-Aggregation-Core）與新式 2 層式架構（Leaf-Spine）示意圖
Leaf-Spine 網路架構
VMware VSAN 為 SDS 軟體定義儲存解決方案，所以在 VSAN 叢集中每台 ESXi 成員主機便是 1 台儲存資源節點主機，因此每台儲存資源節點主機之間將會有高速資料傳輸的需求（東 - 西向網路流量），應該要保持網路傳輸極低的延遲時間，否則將會造成 VSAN 儲存效能上的問題。此外，在網路頻寬的規劃上也非常重要，舉例來說，VSAN 儲存網路環境建議採用 10 Gbps 網路頻寬環境，雖然 1 Gbps 網路環境也能運作但是將會造成 VSAN 儲存效能上的問題，因為在 1 Gbps 網路環境中假設重建儲存空間為 12 TB 時，那麼儲存資源節點主機之間的資料同步作業將需要 24 小時以上。
即便規劃 10 Gbps 網路頻寬環境搭配 Leaf-Spine 網路架構，後續在規劃 VSAN 叢集時也必須考量實務上儲存資源節點主機的放置及環境。舉例來說，如圖 5 所示可以看到為 10 Gbps 網路頻寬的 Leaf-Spine 網路架構，機櫃 1 中為編號 1 ~ 16 儲存資源節點主機而機櫃 2 為編號 17 ~ 32 儲存資源節點主機，倘若只是單純將這 32 台儲存資源節點主機建立 1 個 VSAN 容錯網域的話，那麼屆時在儲存資源節點主機之間的溝通網路頻寬，將會因為比例（4：1）的關係有可能只達到 2.5 Gbps 的水準。
因此，建議在這樣的運作環境中建立 3 個 VSAN 容錯網域（Fault Domains），假設每台儲存資源節點主機原始儲存空間為 10 TB，當設定 FTT = 1 時將會有 6 TB 空間用於保護 VM 虛擬主機，在這種情況下將會有 4/3（也就是 30 Gbps 可以進行重建資料的動作），並且在沒有發生磁碟資源爭奪的情況下只需要 26 分鐘即可完成，即便重建資料儲存空間達 12 TB 並且頻寬少到 10 Gbps，那麼重建時間也僅需要 156 分鐘即可完成。
圖 5、VMware VSAN 採用 Leaf-Spine 網路架構示意圖
建立多路徑路由環境
目前，許多企業或組織已經在資料中心網路環境內，建立 STP 機制以防止網路環境發生迴圈的情況，同時在 Layer 2 網路環境內也應建立 ECMP（Equal-Cost Multi-Path routing）、SPB（Shortest Path Bridging）或 TRILL（Transparent Interconnection of Lots of Links）……多路徑路由或最短路徑等機制。同樣的，在 VMware VSAN 運作環境中皆支援這些網路拓撲基礎架構，重要的是必須良好規劃設計 VSAN 叢集中 ESXi 成員主機的「東 - 西」向網路。根據 VMware 官方最佳作法，在 VSAN 叢集同一個容錯網域內的 ESXi 成員主機之間，除了確保東西向網路具備低延遲網路時間之外，在實體交換器的部分應該採用「交換機堆疊」（Switch Stack）的運作架構，以滿足高可用性及網路頻寬輸送量的需求。
圖 6、ECMP 多路徑路由運作示意圖
IP MultiCast
簡單來說「IP 多點傳送」（IP Multicast）機制，是可以「1 對多」或「多對多」的 IP 網路通訊技術。一般來說，會建議將 VSAN 運作環境建立於 Layer 2網路環境中，以便降低複雜度及管理成本。倘若，將 VSAN 運作環境建立於 Layer 3網路環境時，那麼實體網路一定要建立 IP Multicast 機制。在 IP 多點傳送運作環境中，使用的 IP 多點傳送位址稱為「多點傳送群組」（Multicast Group，MG）。同時，在預設情況下當 VSAN 叢集建立時，預設便會自動分配 IP 多點傳送位址給節點主機，預設的 VSAN 多點傳送群組位址為「224.1.2.3」，而 VSAN 多點傳送群組代理程式位址為「224.2.3.4」。
請注意! 倘若希望調整預設的 VSAN 多點傳送群組位址，或是 VSAN 多點傳送群組代理程式位址的話，請參考 VMware KB 2075451文件內容即可進行調整。
在 VSAN 叢集運作環境中，叢集節點主機透過 VMkernel Port 以 IP 多點傳送機制，透過 IGMP（Internet Group Management Protocol）互相傳送 Metadata 以及加入或離開 VSAN 叢集等資訊，同時在叢集節點主機之間也是透過 IP 多點傳送機制，互相偵測對方是否存活。
在預設情況下，VSAN 叢集將會採用 IGMP v3版本進行「交涉」（Negotiate）的動作，倘若網路環境不支援 IGMP v3 的話，那麼就會採用 IGMP v2進行交涉的動作。VMware 最佳作法，建議在 Layer 3 網路環境中採用一致的 IGMP 版本即可。
在 VSAN 叢集運作環境中，倘若叢集節點主機之間需要跨越多個子網路時，便需要採用 PIM（Protocol Independent Multicast）機制，並且支援 4 種模式以便因應不同的應用情境，PIM-DM（PIM Dense Mode）適用於 1 對多環境，PIM-SM（PIM Sparse Mode）同樣適用於 1 對多環境，當 Layer 3 網路環境僅支援 IGMP v2 時便建議採用此模式，Bi-PIM（Bidirectional PIM）適用於多對多環境，PIM-SSM（PIM Source-Specific Multicast）適用於多對多環境，且完全支援 IGMP v3 環境中使用。
圖 7、Layer 3 網路環境 PIM-SSM 運作機制示意圖
Layer 2 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 2 網路環境時，下列為 Layer 2 網路規劃建議假設採用 VLAN ID 1，並且 IGMP Querier 運作於網路交換器上而非路由器。值得注意的是，務必確認實體網路交換器支援 IGMP v2 或 IGMP v3（例如，Cisco Nexus 交換器支援 IGMP v3，而 Brocade VDX 交換器僅支援 IGMP v2）。
圖 8、 運作於 Layer 2 網路環境的 VSAN 架構示意圖
Layer 3 網路規劃建議
當你決定將 VSAN 架構運作於 Layer 3 網路環境時，表示屆時 VSAN 叢集節點主機之間將有 Layer 3 設備（例如，L3 網路交換器或路由器）。同時，因為必須針對每個 Layer 3 分區送出請求，所以 IGMP Querier 必須是預設閘道，並且必須具備多點傳送群組的成員資格以便執行加入及更新 PIM 的動作。
圖 9、 運作於 Layer 3 網路環境的 VSAN 架構示意圖
網路安全性
與其它 IP 儲存網路流量一樣，在 VSAN 儲存網路中儲存資源節點主機之間的流量並「沒有加密」。因此，在規劃設計 VSAN 儲存網路時，應該規劃獨立且安全的 VLAN 網段進行 VSAN 儲存流量隔離。倘若，管理人員需要更高的安全性，那麼可以在更高運作層級中進行資料加密的動作即可，舉例來說，可以在 VM 虛擬主機的客體作業系統中執行資料加密工作任務。實體網路卡配置
下列為 VSAN 叢集運作環境中，為每台 ESXi 主機規劃設計實體網路卡時的配置建議：- 至少配置 1 個專屬於 VSAN 儲存流量的實體網路卡。建議配置 2 個或以上實體網路卡，以便達到 VSAN 儲存流量負載平衡及容錯移轉機制。
- 建議將 VSAN 儲存流量（VMkernel Port），在 Layer 2 層級以 VLAN 隔離以維持基本網路安全性。倘若，需要與其它網路流量共用（例如，VM 虛擬主機 、vSphere vMotion……等），那麼務必要搭配 NIOC（Network I/O Control）網路流量頻寬管控機制。
- 在 Hybrid VSAN 運作架構中，若採用 1 Gbps 網路頻寬則必須規劃多個且專屬的實體網路卡，建議改為採用 10 Gbps 網路頻寬環境。
- 在 All Flash VSAN 運作架構中，倘若採用 SATA SSD 固態硬碟時仍可採用 10 Gbps 網路頻寬環境，倘若採用 SAS、NVMe、PCIe 或 Ultra DIMM 等快閃儲存資源時，建議採用 25 Gbps 或 40 Gbps 網路頻寬環境（甚至 100 Gbps 也支援）。
虛擬網路架構
了解 VSAN 運作架構中實體網路環境的部分後，接下來我們將 VSAN 叢集的規劃設計重點轉移到 vSphere 虛擬化環境中，我們將依序討論 vSwitch 虛擬網路交換器和 VMkernel Port，然後再深入至 NIC Teaming 負載平衡機制及交換器探索機制的部分。vSwitch 虛擬網路交換器
在 VSAN 運作環境中，支援「標準型交換器」（vNetwork Standard Switch，vSS）或「分散式交換器」（vNetwork Distributed Switch，vDS）。VMware 最佳作法，建議管理人員採用 vDS 分散式交換器，主要原因是 vSS 並不支援相關進階管理功能，並會增加企業及組織在管理 VSAN 運作環境中的營運成本，舉例來說，vSS 不支援 LBT（Load Based Teaming）負載平衡機制 、LLDP（Link Layer Discovery Protocol）交換器環境探索機制 、NIOC（Network IO Control）網路流量管控機制……等。請注意! 有關 vSS 標準型交換器及 vDS 分散式交換器，這兩種虛擬化網路交換器的功能差異詳細說明，請參考 VMware KB 1010555文件內容。
圖 10、vDS 分散式交換器啟用 NIOC 網路流量管控示意圖
值得注意的是，當 vDS 分散式交換器啟用 NIOC 網路流量管控機制後，共有 3 種管控流量的方式分別是「共用率值」（Share）、「保留」（Reservation）、「限制」（Limit）。VMware 最佳作法，考量網路頻寬整體使用率及管理方便度和靈活性，建議採用共用率值的方式進行網路頻寬的管控動作。只要在 vSphere Web Client 管理介面中，依序點選「首頁 > 網路功能 > vDS Switch > 管理 > 資源配置」項目，即可針對網路流量進行頻寬管理的組態設定。
此外，如果 VM 虛擬主機有啟用 vSphere FT 高可用性機制的話，那麼也請將 vSphere FT 網路流量的共用率值提升，因為 vSphere FT 為「延遲時間敏感」（Latency-Sensitive）類型的網路流量，倘若發生網路頻寬不足的情況將會造成受保護的 VM 虛擬主機，發生非預設的運作錯誤。
圖 11、vDS 分散式交換器啟用 NIOC 網路流量管控機制
VMkernel Port
完成 vSwitch 虛擬網路交換器的規劃後，接著便是新增 VMkernel Port 來處理 VSAN 儲存流量。基本上，ESXi 虛擬化平台上所有類型的流量，都會透過 VMkernel Port 服務類型的組態設定後進行傳送，並且在 VMkernel Port 當中除了 ESXi 主機的管理網路流量之外，還有其它類型的網路流量。舉例來說，VMkernel Port 還負責 vSphere vMotion、iSCSI、NAS/NFS、VSAN、vSphere Replication 及 vSphere FT……等網路流量。在舊版 vSphere 5.5時，VMkernel Port 網路流量類型只有 4 種。在新版 vSphere 6.0運作環境中，VMkernel Port 網路流量則細分為 7 種，其實是將原本歸納於管理流量的相關網路流量，再細分後拆出來成為獨立的網路流量，分別是佈建流量、vSphere Replication 流量、vSphere Replication NFC 流量。
其中，「佈建流量」負責處理 VM 虛擬主機「複製」（Cloning）、「冷遷移」（Cold Migration），以及建立「快照」（Snapshot）時所產生的網路流量，同時當採用的儲存資源若未支援 VAAI（VMware vSphere Storage APIs Array Integration）硬體卸載功能時，產生的佈建網路流量將會更為明顯。
請注意! 有關 VAAI 硬體卸載功能的詳細資訊，請參考 VMware KB 1021976。
「vSphere 複寫流量」項目，則是負責處理 ESXi 主機傳輸複寫資料至 vSphere Replication 虛擬設備時使用，「vSphere 複寫 NFC 流量」項目，負責處理 vSphere Replication 虛擬設備從網路環境複製檔案，至 ESXi 主機 Datastore 儲存資源之間的網路流量。
請依序執行下列操作步驟，即可透過 vSphere Web Client 管理工具建立 VMkernel Port，並加入至現有的 vSwitch 虛擬網路交換器中：
1. 在本文實作環境中，請開啟瀏覽器鍵入網址 https://vcenter.vdi.weithenn.org:9443/vsphere-client，鍵入管理者帳號密碼後便能透過 vSphere Web Client 管理工具，連接至 vCenter Server 執行個體。
2. 依序點選「首頁 > 主機和叢集」項目後，點選準備建立 VMkernel Port 的 ESXi 主機。
3. 依序點選「管理 > 網路功能 > VMkernel 介面卡」項目後，按下「新增網路」圖示。此時，管理畫面將會彈出新增網路精靈視窗。
4. 在選取連線類型視窗中，請點選「VMkernel 網路介面卡」項目後，按下一步鈕。
5. 在本文實作環境中，我們要將 VSAN 用途的 VMkernel Port 加入至現有的 vDS 分散式交換器中，因此選擇「選取現有網路」項目後按下瀏覽鈕，選擇要將 VMkernel Port 加入至哪個連接埠群組內（本文實作環境中，vDS 分散式交換器名稱為 Dswitch，而連接埠群組名稱為 DPortGroup），請按下一步鈕繼續組態設定程序。
6. 在連接埠內容頁面中，請於啟用服務設定區塊中勾選「Virtual SAN 流量」項目，以便為此 VMkernel Port 啟用 VSAN 儲存流量，請按下一步鈕繼續組態設定程序（如圖 12 所示）。
7. 在 IPv4 設定頁面中，請為 VMkernel Port 指定採用 DHCP 動態取得 IPv4 位址，或選擇採用靜態 IPv4 設定，手動為 VMkernel Port 指定 IP 位址及子網路遮罩等網路資訊。建議為每台 VSAN 叢集節點主機設定固定的 IPv4 位址，請按下一步鈕。
8. 在即將完成頁面中，檢視 VMkernel Port 組態設定內容正確無誤後，按下完成鈕系統便立即於剛才選定的 vDS 分散式交換器，以及所屬的連接埠群組中建立 VMkernel Port 並啟用 VSAN 儲存流量功能。
圖 12、建立 VSAN 用途的 VMkernel Port 並勾選啟用 VSAN 流量項目
請注意! 倘若 VSAN 用途的 VMkernel Port 網段，與 ESXi 主機的管理網路不同（採用不同預設閘道及 DNS 伺服器 IP 位址），那麼便需要建立及採用非預設值的 TCP/IP 堆疊。有關建立 VSAN 用途的 VMkernel Port 及 TCP/IP 堆疊的詳細資訊，請參考 VMware KB 2058368文件內容。
停用流量管控機制
在 VMware VSAN 軟體定義儲存的網路環境中，VSAN 不管採用 vSS 標準型交換器或 vDS 分散式交換器，都必須與 ESXi 主機的實體網路卡（在 vSphere 環境中稱為 Uplink）進行關聯，以便屆時其上運作的 VM 虛擬主機能夠透過 Uplink 與實體網路環境溝通。預設情況下，在 vSphere 虛擬化環境中所有的 Uplink 都會啟用「流量管控」（Flow Control）機制。因為，在乙太網路環境運作架構中，倘若 ESXi 主機不堪網路流量沈重的工作負載時，將會送出「暫停封包」（Pause Frames），以便通知在網路流量發送端暫時停止網路傳輸。
但是，在 VSAN 運作環境中已經內建「壅塞管理」（Congestion Management）機制，能夠有效防止因為網路流量爆發而產生壅塞的情況，或者是因為快取及緩衝機制所導致的壅塞。因此，VMware 官方最佳作法為建議將 VSAN 叢集中所有 ESXi 成員主機，組態設定 VSAN 用途的 VMkernel Port「停用」（Disable）Flow Control 機制，以避免與內建的壅塞管理機制互相干擾。
請注意! 有關如何在 VSAN 叢集節點主機中，組態設定 VMkernel Port 停用 Flow Control 機制的詳細資訊，請參考 VMware KB 1013413文章內容。
NIC Teaming
在 VSAN 運作架構中啟用 NIC Teaming 功能後，若採用「Port ID」、「Source MAC」、「IP Hash」等原則時，其實僅具備高可用性（容錯移轉）特色並沒有負載平衡功能。VMware 最佳作法，當採用 vDS 分散式交換器時能夠使用特殊 NIC Teaming 機制，也就是「LBT（Load Based Teaming）」的負載平衡機制，啟用後將會每隔 30 秒偵測實體網路卡流量並進行流量負載平衡作業。
圖 13、LBT（Load Based Teaming）負載平衡機制運作示意圖
圖 14、將 NIC Teaming 負載平衡機制調整為 LBT 模式
請注意! 有關 NIC Teaming 負載平衡及容錯移轉機制的詳細資訊，請參考 VMware KB 2006129、KB 1004048文件內容。
Jumbo Frames
VSAN 運作架構中支援 Jumbo Frames，但是並非運作 VSAN 環境的必要條件。在 VMware 的測試結果中，發現 Jumbo Frames 機制可以減少 CPU 使用率並提高輸送量，但是因為 vSphere 已經使用 TCP Segmentation Offload（TSO）及 Large Receive Offload（LRO）機制，所以 Jumbo Frames 的幫助其實是有限的。請注意! 有關 TSO 及 LRO 的詳細資訊，請參考 VMware KB 2055140文件內容。
VMware 最佳作法，建議採用現有的 MTU/Frame Size 即可。也就是說倘若企業及組織的資料中心內已經啟用 Jumbo Frames 機制，那麼 VSAN 用途的網路環境也請啟用 Jumbo Frames。倘若資料中心並沒有啟用 Jumbo Frames，那麼不必單獨為 VSAN 網路特地啟用 Jumbo Frames。
圖 15、在 vSphere 運作環境中啟用 Jumbo Frames 機制
Switch Discovery Protocol
在 vSphere 虛擬化網路環境中，偵測實體網路環境探索協定分別支援 CDP（Cisco Discovery Protocol）及 LLDP（Link Layer Discovery Protocol）。值得注意的是，採用 vSS 標準型交換器僅支援 CDP，採用 vDS 分散式交換器才支援 CDP/LLDP。同時，VMware 最佳作法為不管採用 CDP 或 LLDP 皆請開啟傳送及接受模式。
圖 16、啟用 LLDP 探索通訊協定並啟用傳送及接受模式
結語
透過本文的說明及實作，從實體網路環境到 vSphere 虛擬化網路環境，相信企業或組織的 IT 管理人員只要遵從 VMware 官方的最佳作法及建議進行設計規劃，便能建構出高可用性、高效能並具備靈活性的 VSAN 軟體定義儲存環境。↧
↧
[站長開講] VMware vSphere 建置與維護實作進階班
課程簡介
- 了解建置私有雲運作環境時對於實體的 網路、儲存、交換器…等設備該如何進行規劃，並且會帶來何種影響。
- 了解在規劃私有雲環境時應該如何針對虛擬網路、儲存、交換器…等，將網路流量統一集中或者依服務類型進行切割，同時導入流量管控機制以達成網路與頻寬最佳利用率。
- 了解在規劃私有雲環境時對於何種使用情境，適合採用哪種儲存設備類型如 DAS、NAS、SAN。
- 熟悉及實作各種儲存設備種類及特性，以規劃出高可用性儲存架構。
- 實作虛擬化環境網路傳輸高可用性機制 NIC Teaming、Failover。
- 實作虛擬化環境 SAN 儲存傳輸高可用性機制 MPIO。
- 實作虛擬化環境上運作的 VM 虛擬主機，其效能最佳化調校以及主機安全性調整。
- 實作 VMware vSphere 虛擬化技術相關機制及運作原理，如 vMotion、HA (High Availability)、FT(Fault Tolerance)…等，並實作出可擴充性及高可用性虛擬化環境。
課程資訊
時間： 四、五、一、二、三 (09:10 ~ 17:20)地點： 中華電信學院 (新北市板橋區民族路168號)
日期： 2016/11/17、11/18、11/21、11/22、11/23
網址： VMware vSphere 建置與維護實作進階班
↧
131 期 - Hyper-V 虛擬平台放利多 Unix-Like 運作也能通
網管人雜誌
本文刊載於 網管人雜誌第 131 期 - 2016 年 12 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言在 Hyper-V 虛擬化平台上運作 Unix-Like
什麼是 Hyper-V 整合服務？
Unix-Like虛擬主機整合服務
CentOS 虛擬主機安裝整合服務
FreeBSD 虛擬主機安裝整合服務
結語
前言
談到微軟作業系統，某些 IT 人員便認為在作業系統的部分一定是只有 Windows。雖然，Windows 偶爾有推出與開放源始碼整合的相關服務，但使用者通常仍覺得整合程度有限，但是這樣的狀況自從微軟 CEO Satya Nadella 上任並喊出 Microsoft Love Linux 之後便一一被打破，甚至最新推出的 Windows Server 2016 作業系統，還能夠原生執行 Container 容器技術。
同時，不光是地面上企業及組織的相關技術支援 Linux，就連微軟公有雲 Azure 也支援 Linux 作業系統的 VM 虛擬主機及相關服務，根據微軟的內部統計目前在 Azure 公有雲的 VM 虛擬主機工作負載當中，有 1/3 是運作 Linux 作業系統另外 2/3 才是運作 Windows 作業系統。
同時在 2016 年 3 月，微軟已經釋出 SQL Server on Linux 的封閉預覽測試版本，並宣佈預定於2017 年 Q2將正式推出。屆時，在 Linux 作業系統中也可以安裝 Microsoft ODBC Driver for SQL Server，以便 Linux 作業系統能夠順利存取 SQL Server 資料庫服務。
圖 1、SQL Server on Linux 的封閉預覽測試版本
在 2016 年 4 月，微軟在 Build 開發者大會上正式宣佈，從 Windows 10（Build 14316）作業系統版本開始，將在 Windows 作業系統核心中加入子系統（Windows Subsystem for Linux），以便在 Windows 作業系統中能夠原生支援 Linux 使用者模式，這與舊有透過 Cygwin 模擬的方式完全不同。現在，你可以直接在 Windows 作業系統中原生執行 Ubuntu Bash、apt-get、git……等。
圖 2、運作 Ubuntu 原生 Bash 指令碼環境在 Windows 作業系統中
在 2016 年 8 月，微軟也宣佈自家的 PowerShell 指令碼工具正式 Open Sourced。現在，可以在多種 Linux 作業系統（例如，Ubuntu 14.04、Ubuntu 16.04、CentOS 7、OS X 10.11……等）中，直接透過 GitHub 下載安裝後運作 PowerShell 指令碼環境。
圖 3、在 CentOS 作業系統中運作 PowerShell 指令碼環境
在 Hyper-V 虛擬化平台上運作 Unix-Like
在 Hyper-V 虛擬化平台上運作 VM 虛擬主機，倘若客體作業系統採用 Windows 時相信 IT 管理人員應該不陌生，舉例來說，在 Windows Server 的部分支援 SBS 2011、2008 SP2、2008 R2、2012、2012 R2 以及最新版本的 Window Server 2016，至於 Desktop 的部分則支援 Vista SP2、7 SP1、8.1 及最新版本的 Windows 10。
那麼，倘若在 Hyper-V 虛擬化平台中要運作 Unix-Like 作業系統（例如，Linux 及 FreeBSD）時，哪些 Unix-Like 版本才有支援？倘若採用不支援的 Unix-Like 作業系統時是否無法運作在 Hyper-V 虛擬化平台上？Hyper-V 虛擬化平台能否運作 Unix（例如，AIX、HP-UX）或者是 Max OS X？
簡單歸納來說，Hyper-V 虛擬化平台無法運作 Unix 及 Max OS X。同時，當採用未支援的 Unix-Like 作業系統版本時，將會因為無法安裝「整合服務」（Integration Service），除了導致運作於 VM 虛擬主機當中的 Unix-Like 作業系統，無法針對相關虛擬硬體裝置安裝驅動程式與 Hyper-V 虛擬化平台進階功能整合之外，也將會影響 VM 虛擬主機的運作效能。
圖 4、Hyper-V 虛擬化平台是否能運作 Unix 及 Unix-Like 作業系統判斷流程示意圖
什麼是 Hyper-V 整合服務？
事實上，不管採用哪一種虛擬化平台都會需要幫其上運作的 VM 虛擬主機安裝適當的 Tools，以使其上運作的 VM 虛擬主機能夠與虛擬化平台進行最緊密的結合（例如，虛擬裝置驅動程式最佳化……等），舉例來說，倘若採用 VMware vSphere 虛擬化平台便需要幫 VM 虛擬主機安裝 VMware Tools，而 Citrix XenServer 虛擬化平台便需要幫 VM 虛擬主機安裝 Xen Tools。
在 Microsoft Hyper-V 虛擬化平台上，則是需要幫其上運作的 VM 虛擬主機安裝「整合服務」（Integration Services），安裝整合服務完畢後在驅動程式部份將會針對 IDE、SCSI、網路 、視訊 、滑鼠 …… 等方面進行最佳化，而在客體服務方面則會整合作業系統關閉（Shutdown）、時間同步化（Time Synchronization）、資料交換（Key/Value Exchange）、活動訊號（Heartbeat）、線上備份（Volume Shadow copy Service，VSS）……等機制，以期 VM 虛擬主機與 Microsoft Hyper-V 虛擬化平台不管是在效能運作上，或者是虛擬裝置驅動程式最佳化方面都能進行完美的結合。
圖 5、Hyper-V運作元件架構示意圖
Unix-Like 虛擬主機整合服務
倘若，您的 VM 虛擬主機安裝「Windows作業系統」的話，那麼在VM虛擬主機的Console視窗中可以直接執行插入整合服務安裝光碟的動作。當安裝「Linux 作業系統」如 RHEL / CentOS 時，Hyper-V 虛擬化平台雖然也支援「Emulated / Specific」2 種虛擬裝置，但是若需要發揮 Linux 作業系統最佳效能，建議您使用 Hyper-V Specific Devices並配合安裝「LIS（Linux Integration Services）」，也就是專供 Linux 使用的整合服務映像檔並進行安裝才能達到效能最佳化。
專供 Linux 作業系統使用的 LIS 整合服務映像檔，目前最新版本為 4.1您可至 Microsoft Download Center 下載「Linux Integration Services Version 4.1 for Hyper-V」，所下載整合服務映像檔名稱為「LinuxIC-4.1.2-2.iso」。
圖 6、下載專供 Linux 作業系統使用的 LIS 整合服務映像檔
LIS 4.1 for Hyper-V 整合服務，支援的 Linux 版本以 RHEL / CentOS為例的話是 5.2 ~ 5.11、6.0 ~ 6.8、7.0 ~ 7.2，並且可以應用在多種Hyper-V虛擬化平台版本上，例如，Hyper-V 2.0（Windows Server 2008 R2）、Hyper-V 3.0（Windows 8 / 8.1 Pro、Windows Server 2012 / 2012 R2）以及最新的 Windows 10 和 Windows Server 2016。
最新的 LIS 4.1版本中，除了原有整合服務的特色功能之外還支援下列 5 項新增功能：
- Hyper-V Sockets。
- 記憶體熱新增及移除。
- SCSI WWN。
- lsvmbus 指令。
- 反安裝 LIS 整合服務指令碼。
安裝整合服務後的Linux虛擬主機，將具備核心（Core）、網路（Networking）、儲存（Storage）、記憶體（Memory）、視訊（Video）、其它（Miscellaneous）……等特色功能或最佳化效能：
核心（Core）
- 整合式關機： 透過此功能，在開啟的VM Console視窗中便能為客體作業系統執行關機的動作，而無須登入至客體作業系統手動進行關機。
- 時間同步處理： 確保VM虛擬主機能夠與Hyper-V主機保持時間同步。
- 準確時間： 整合 Windows Server 2016 準確時間功能，改善主應用程式與時間同步處理的精確度，能夠將時間誤差值縮短在 1 毫秒的範圍內。
- 多處理器支援： 支援組態配置 VM 虛擬主機多顆 vCPU 虛擬處理器，達到真正使用 Hyper-V主機多顆 CPU 處理器進行 SMP 平行運算。
- 活動訊號： 以便 Hyper-V 虛擬化平台能夠偵測及追蹤 VM 虛擬主機運作狀態。
- 整合式滑鼠支援： 滑鼠功能將可正常運作於 VM 虛擬主機的 Console 視窗中，以及自動在Hyper-V 虛擬化平台中正常切換。
- Hyper-V 特定儲存裝置： 使 VM 虛擬主機擁有高效能及最佳化的 IDE/SCSI 儲存介面卡，有效提升工作負載能力。
- Hyper-V 特定網路裝置： 使 VM 虛擬主機擁有高效能及最佳化的 Network Controller 介面卡，有效提升工作負載能力。
網路（Networking）
- Jumbo Frame： 可設定 MTU 數值大於 1500 bytes 以增加網路效能。
- VLAN Tagging 及 Trunking： 支援單一 VLAN ID 或多個 VLAN ID Trunking 網路環境。
- 即時遷移： 讓 VM 虛擬主機支援即時遷移（Live Migration）、無共用儲存即時遷移（Shared Nothing Live Migration）、Hyper-V複本（Hyper-V Replica）…… 等進階功能。
- 靜態 IP 導入： 當 Hyper-V 主機執行複本容錯移轉之後，因為已經複寫 VM 虛擬主機靜態 IP 位址，所以能夠確保網路工作負載能在發生容錯移轉事件後無縫繼續運作。
- vRSS 虛擬接收端調整： 將 VM 虛擬主機虛擬網路卡的工作負載，平均分散到 VM 虛擬主機中的多個 vCPU 虛擬處理器。
- TCP 分割和總和檢查碼卸載： 在傳輸網路數據時，從 VM 虛擬主機的 vCPU 虛擬處理器到 Hyper-V 主機的 vSwitch 虛擬網路交換器之間，進行資料分割及總和檢查碼的動作。
- LRO 大型接收卸載： 透過將多個封包彙總為更大的緩衝區，以便提升高網路頻寬流入的傳輸量，進而降低 CPU 運算資源的開銷。
儲存（Storage）
- VHDX 調整大小： 系統管理員可以隨時因應需求，線上調整 VM 虛擬主機的 VHDX 磁碟空間。
- vHBA 虛擬光纖通道： 讓 VM 虛擬主機能夠感知原生光纖通道裝置，進而支援及使用虛擬光纖通道功能。
- VM 虛擬主機即時備份： 讓 VM 虛擬主機能夠在運作中的情況下進行備份作業。
- TRIM： 當應用程式不再需要磁碟空間時，協助執行磁碟空間回收的動作。
- SCSI WWN： Storvsc 驅動程式將會擷取連接埠和連接至 VM 虛擬主機的全球名稱（WWN），以便建立適當的 sysfs 檔案。
記憶體（Memory）
- PAE 核心支援： 在 Linux 作業系統中透過 PAE 技術，可以讓 32 位元核心存取超過 4 GB 的記憶體位址空間。舉例來說，舊版的 RHEL 5.x 必須個別在核心中啟用 PAE 功能，而較新版的 RHEL 6.x 則核心已經預先啟用 PAE 功能。
- MMIO： 協助 JeOS（Just Enough Operating Systems）與 Hyper-V 主機實體記憶體區塊進行對應的動作。
- 記憶體熱新增及移除： 提供 VM 虛擬主機在運作狀態中，線上動態增加及移除記憶體空間的機制。
- Ballooning： 活化 Hyper-V 主機記憶體空間，以便渡過記憶體空間暫時不足的因應機制。
視訊（Video）
- 特定視訊裝置： 提供 VM 虛擬主機高效能及高解析的視訊介面卡，但是此裝置並不提供增強的工作階段模式及 RemoteFX 功能。
其它（Miscellaneous）
- KVP（Key-Value Pair）Exchange： 取得 VM 虛擬主機在資料方面讀取（Read）/ 寫入（Write）等資訊。
- NMI 非遮罩式插斷： 協助 VM 虛擬主機當中的客體作業系統，因為應用程式漏洞而發生的崩潰情況，再主機重新啟動後有機會分析導致系統發生崩潰的原因。
- 客體與主機進行檔案複製： 透過客體服務讓 VM 虛擬主機與 Hyper-V 主機之間，在進行檔案複製作業時無須透過網路介面卡進行傳輸。
- lsvmbus 指令： 透過此指令可以獲得 Vmbus 的相關資訊。
- Hyper-V Sockets： 透過載入 Hyper-V Sockets 核心模組，讓 VM 虛擬主機與 Hyper-V 主機之間建立專屬的通訊通道。
- PCI Passthrough： 將安裝於 Windows Server 2016 主機上的 PCI Express 裝置，例如，網路介面卡、GPU 顯示卡……等，以直接傳遞的方式指派給 VM 虛擬主機使用。
那麼在 Hyper-V 虛擬化平台上所運作的 Linux 作業系統，哪種發行套件及版本分別支援上述說明的功能呢，舉例來說，採用新版 CentOS 7.0 雖然核心中已經支援 Hyper-V 裝置最佳化，但是仍無法使用 vRSS 功能，必須要採用更新的 CentOS 7.1 或 7.2 版本才支援，在 Ubuntu Server 也是一樣的情況，你會發現 Ubuntu 12.04 並不支援 vRSS 功能，必須使用新版本的 Ubuntu 14.04、16.04 或 16.10 才支援。
為了避免不必要的篇幅，在此便不將 Hyper-V 虛擬化平台所支援 Linux 發行套件及版本其所對應的功能逐一說明，有興趣的讀者不妨直接瀏覽 Microsoft 官方網站查詢及核對所支援的特色功能項目：
圖 7、RHEL / CentOS 版本及特色功能對應表
CentOS 虛擬主機安裝整合服務
當管理人員為 VM 虛擬主機，安裝舊版 RHEL / CentOS「5.2 ~ 5.8、6.0 ~ 6.3（32 或 64 位元）」時，那麼必須要為 RHEL/CentOS 客體作業系統安裝「Linux Integration Services Version 4.1 for Hyper-V」整合服務。
其它較新版本 RHEL / CentOS「5.9 ~ 5.11、6.4 ~ 6.8、7.0 ~ 7.2（32 或 64 位元）」，因為官方已經直接在該版本的 Linux 核心當中，直接內嵌 Hyper-V 相關虛擬裝置驅動程式。
因此，當 VM 虛擬主機安裝這些新版本的 RHEL/CentOS 客體作業系統版本後，其實可以無須再額外安裝 LIS 4.1 整合服務。除非，你希望使用 LIS 4.1 整合服務所提供的新增功能，例如，在預設情況下 CentOS 7.2 版本內建的整合服務，並未支援 SCSI WWN、lsvmbus 指令、Hyper-V Sockets 等功能。
那麼，當我們為 VM 虛擬主機安裝新版 CentOS 7.2 客體作業系統後，登入 CentOS 客體作業系統鍵入相關指令「uname -a、cat /etc/redhat-release、cat /var/log/dmesg | grep Vmbus」，便可以看到目前採用的 Linux 核心版本為「3.10.0-327.e17.x86_64」，採用的 CentOS 版本為「7.2.1511」，至於 Hyper-V 整合服務所使用的 hv_vmbus 版本則為「3.0」。
圖 8、CentOS 7.2 客體作業系統版本資訊，以及內建的 Hyper-V LIS 整合服務資訊
接著，我們從 Hyper-V 虛擬化平台方面，透過 Hyper-V 管理員來驗證此台 VM 虛擬主機是否真的已經支援整合服務了。首先，點選安裝 CentOS 7.2 的 VM 虛擬主機後，在下方 Hyper-V 管理員「摘要」頁籤中，可以看到活動訊號欄位的顯示結果為「良好（無應用程式資料）」，表示 Hyper-V 虛擬化平台可以正確偵測到VM虛擬主機運作狀態。
切換到「記憶體」頁籤後，您可以看到記憶體需求及記憶體狀態欄位為「1036 MB、確定」，表示 Hyper-V 虛擬化平台的動態記憶體功能，與目前 CentOS 客體作業系統已經順利協同運作了。
請注意! 倘若採用舊版 Windows Server 2012 虛擬化平台版本的話，則「尚未」支援 Linux 作業系統動態記憶體功能，必須採用 Windows Server 2012 R2 或新版 Windows Server 2016 虛擬化平台版本，才正式支援動態記憶體功能。
切換到「網路功能」頁籤中，你會看到在狀態欄位的部分顯示結果為「良好（VMQ 作用中）」，表示 CentOS 客體作業系統已經採用內建的整合服務，為 VM 虛擬主機所指派使用的虛擬網路介面卡，安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。
圖 9、新版 CentOS 7.2 已經內建 LIS 整合服務
倘若，你希望測試新版 LIS 4.1 整合服務中 lsvmbus 指令及 Hyper-V Sockets 功能的話，那麼便需要為 CentOS 7.2 安裝 LIS 4.1 整合服務。請為 VM 虛擬主機掛載剛才下載的 Linux Integration Services Version 4.1 for Hyper-V 整合服務映像檔 LinuxIC-4.1.2-2.iso，準備為 CentOS 7.2 作業系統安裝整合服務。
圖 10、為 VM 虛擬主機掛載 LIS 整合服務映像檔
順利掛載 LIS 整合服務映像檔之後，回到 CentOS 7.2 虛擬主機 Console 畫面，請依序鍵入指令「mount /dev/cdrom /media、cd /media/CentOS72、./install.sh」，執行掛載光碟機資源、切換到適合安裝的整合服務 CentOS 版本路徑、安裝整合服務等動作。
圖 11、為 CentOS 7.2 安裝新版 LIS 4.1 整合服務
當新版 LIS 4.1 整合服務安裝完畢後，請將 CentOS 7.2 客體作業系統重新啟動並卸載 LIS 整合服務映像檔。當 CentOS 7.2 客體作業系統重新啟動完畢後，便可以透過「/sbin/modinfo hv_vmbus」指令查看 hv_vmbus 版本，可以從指令執行結果中看到已經採用最新「4.1.2-2」版本。此外，如同剛才所說明的我們可以使用新版 LIS 4.1 整合服務中的「lsvmbus」指令，來查看相關虛擬裝置的 Vmbus ID 資訊。
圖 12、確認 CentOS 客體作業系統，是否採用最新的 hv_vmbs 4.1.2-2 版本
目前有個已知問題值得注意，倘若安裝 CentOS 客體作業系統的 VM 虛擬主機有啟用「安全開機」功能的話，那麼在安裝新版 LIS 4.1 整合服務後必須將安全開機功能「停用」，否則將會發現 CentOS 客體作業系統無法正常啟動或啟動後直接進入安全模式。
FreeBSD 虛擬主機安裝整合服務
雖然，FreeBSD 也是 Unix-Like 作業系統，但是 FreeBSD 的系統核心與 Linux 完全不同。同樣的，微軟官方也採用與 LIS 整合服務同樣的方式，讓運作於 Hyper-V 虛擬化平台中的 FreeBSD 虛擬主機，能夠支援及使用 Hyper-V Specific Devices 高效能虛擬裝置機制，此機制稱之為「BIS（BSD Integration Services）」。
圖 13、微軟開發人員協同 FreeBSD 團隊開發 BIS 整合服務，讓系統核心支援 Hyper-V 虛擬化平台
倘若運作舊版 FreeBSD 8.4、9.1 ~ 9.3的話，必須透過 FreeBSD Ports 套件管理機制，安裝「/head/emulators/hyperv-is」套件即可。在 2012 年 5 月 10 日時，Microsoft TechNet Blog發表一篇 FreeBSD Support on Windows Server Hyper-V文章，內容便說明 Microsoft 以及合作夥伴 NetApp、Citrix 將在 BSDCan 2012 大會上，正式發表 FreeBSD 核心支援 Hyper-V 虛擬裝置驅動程式。
因此，倘若採用的是 FreeBSD 10.x或最新版本的 FreeBSD 11，因為在 FreeBSD 核心中已經支援 BIS 整合服務，所以便無須再透過 FreeBSD Ports 套件管理機制進行安裝作業。
請注意，目前 Hyper-V 虛擬化平台中的 FreeBSD，仍無法採用「第二世代」格式的 VM 虛擬主機，同時 BIS 整合服務功能性的部分與 LIS 整合服務相較之下較少，舉例來說，動態記憶體功能尚未完全支援運作。
同樣的，在建立第一世代格式的 VM 虛擬主機並安裝最新版本 FreeBSD 11 之後，我們可以切換到 Hyper-V 管理員視窗中，確認 FreeBSD 虛擬主機的 BIS 整合服務是否順利運作。首先，切換到「摘要」頁籤中，可以看到活動訊號欄位的顯示結果為「良好（無應用程式資料）」，表示Hyper-V虛擬化平台可以正確偵測到VM虛擬主機運作狀態。
切換到「記憶體」頁籤中，您可以看到記憶體需求及記憶體狀態欄位為「空白」，這是因為BIS 整合服務機制尚未支援 Hyper-V 虛擬化平台的動態記憶體功能所致。切換到「網路功能」頁籤中，你會看到在狀態欄位的部分顯示結果為「良好（VMQ 作用中）」，表示 FreeBSD 客體作業系統已經透過 BIS 整合服務，為 VM 虛擬主機所指派使用的虛擬網路介面卡，安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。
圖 14、新版 FreeBSD 11 已經內建 BIS 整合服務
順利登入 FreeBSD 11 系統後，可以發現系統已經順利辨識到網路介面卡（代號為 hn0），查看系統開機訊息可知 hn0 網路卡為「Hyper-V Network Interface」，也就是已經採用最佳化效能的 Hyper-V Specific Network Adapter，接著鍵入指令「ls /boot/kernel | grep hv」查看 FreeBSD 模組存放資料夾內容可知，協同 Hyper-V 虛擬化平台運作的相關模組檔案也已經存在。
倘若，VM 虛擬主機組態配置傳統網路介面卡時，將網路介面卡代號將為「de0」並模擬「Digital 21140A Fast Ethernet 100 Mbps」網路卡。
圖 15、順利辨識並載入 Hyper-V Specific Network 網路介面卡及相關模組
鍵入指令「dmesg | grep vmbus0」查詢 FreeBSD 開機訊息內容，你會看到 FreeBSD 透過內建的 BIS 整合服務，已經順利載入 Hyper-V 虛擬化平台協同運作的相關服務，例如，Heartbeat、KVP、Shutdown、Time Synch……等服務。
圖 16、FreeBSD 透過內建的 BIS 整合服務載入 Hyper-V 相關客體服務
結語
透過本文的說明及實作演練，當企業及組織的 IT 管理人員需要在 Hyper-V 虛擬化平台上運作 Unix-Like 作業系統時，便能夠正確為 Unix-Like 作業系統採用 LIS / BIS 整合服務，以便確保運作於 Hyper-V 虛擬化平台上的 Unix-Like 作業系統，能夠擁有最佳的工作負載及最大化的運作效能。
↧
VMware Taiwan vForum 2016 簡報開放下載
前言
日前 (2016.12.8)，在 Taiwan 舉辦的 VMware Taiwan vForum 2016議程簡報已經開放下載了，有興趣的朋友可以參考看看。簡報下載
主題演講
- be_Tomorrow 邁向未來
- 預見多雲時代的競爭優勢
- 掌握企業行動力，加速數位轉型
- HPE Dev/Ops 自動化資料中心平台
分會場 1、軟體定義資料中心
- 用戶經驗分享：雲端維運管理全面新進化
- 下一世代之軟體定義資料中心解決方案
- 雲端基礎一切在我： Cloud Foundation 與 vSphere 6.5 產品分享
- 針對混合雲的 Veeam 可用性平台
- 雲端管理儲存新概念
- 關鍵業務入雲最佳實務： VMware vCloud Suite 究極秘笈
分會場 2、軟體定義儲存
- 用戶經驗分享： 校園雲端虛擬化及儲存環境應用
- 讓你擁有一手「軟體定義儲存 (SDS)」解決方案的好牌
- 再次驅動儲存轉型 VMware vSAN 6.5
- Supermicro 整合 VMware vSAN 解決方案
- 創新儲存價值，帶動資料管理新視野
- vSAN 高可用設計與超高效能實測報告
分會場 3、軟體定義網路及安全
- 用戶經驗分享： 透過軟體定義網路，加速金融數位化
- 從真實案例看混合雲資安挑戰與實務
- VMware 軟體定義網路技術暨網路虛擬化的發展趨勢
- VMware 和 Arista 攜手建立資料中心安全防護
- 決戰物聯網，不要當標靶
- VMware 微分段方案與傳統網路安全方案的比較，以及維運機制介紹
分會場 4、多雲維運與自動化
- 用戶經驗分享： 跨越私有雲的挑戰 - 研究單位 IaaS 服務案例分享
- 傳統架構與互聯網架構的融合之路
- 多雲時代的部署自動化與管理 (Cross-Cloud Service)
- 輕鬆駕馭雲端自動化，打造高效整合 IT 環境
- 建置符合營運關鍵應用需求的高效能軟體定義資料中心
- 運用 vRealize Operations 打造全方位的企業關鍵服務監控儀表板 (Management as a Service)
分會場 5、行動終端應用
- 用戶經驗分享： 三軍總醫院戮力推動醫療資訊行動化同時，強化行動裝置管理分享 AirWatch 之應用
- 新一代以 VM 為核心的自動化部署與平行 I/O 處理平台
- 『駭』客任務的終結者： 第三平臺上的行動裝置管理就該這麼做
- Commvault - 打造全方位的資訊管理平台
- 在虛擬環境及混合雲端中確保系統持續運作的秘訣
- 鋪天蓋地 – VMware 全面防護企業終端應用解決方案
分會場 6、Cloud Native
↧
SSD 固態硬碟的選擇及規劃
前言
自從 Windows Server 2016 推出後，大家對於 S2D (Storage Spaces Direct)軟體定義儲存技術一直非常有興趣。甚至，微軟也推出 Project Kepler-47的輕量型 OEM S2D 解決方案，讓分公司或小型運作環境也能夠享有 S2D 軟體定義儲存技術的好處。本文，將討論在 Windows Server 2016 中的 S2D 軟體定義儲存解決方案中，佔有舉足輕重地位的儲存裝置「SSD 固態硬碟」。SSD 固態硬碟基礎知識
眾所周知 SSD 固態硬碟具有「資料讀寫壽命」的問題，隨著資料不斷大量的讀取及寫入後即便只是簡單的資料讀取都會有壽命成本的問題，在 SSD 固態硬碟運作環境中這個現象稱之為「讀取干擾 (Read Disturb)」。下列，為常見的 4 種 SSD 固態硬碟類型：- SLC： 1 bit per Cell (100,000 or more Write)。
- MLC： 2 bits per Cell (10,000 ~ 20,000)。
- TLC： 3 bits per Cell (> 1,000)。
- QLC： 4 bits per Cell (> 100)。
因此，正確的規劃及選擇 SSD 固態硬碟便更顯現其重要性。那麼，我們來看看 SSD 固態硬碟的存取行為，一般情況下會透過「FTL (Flash Translation Layer)」連接到 NAND Flash 快閃記憶體的內部控制器。同時，FTL 具備下列 2 項機制：
- 儲存資料時會一起儲存「ECC (Error Correcting Codes)」，當需要恢復資料時便會透過 ECC 機制進行復原的動作。
- 具備「Over-Provisioning」機制以便超額提供儲存空間。事實上，NAND 是無法直接寫入資料的，必須經過「P/E (Program/Erase)」的處理流程後才能進行寫入資料，每個「Page」的空間最小可達「16 K」。同時，NAND 不會重複寫入同個 Page，然後 FTL 持續追蹤及更新 Erased Pages，並且合併重新寫入的資料區塊以及所對應的 Re-Written Logical Blocks，最終的結果就是 Over-Provisioning。
簡單來說，「NAND Flash SSD」是個複雜且動態的運作環境，必須要整合多項機制才能確保儲存資料的可用性。同時，隨著儲存密度不斷增加的情況下維持資料可用性的難度相形提高，目前為透過「緩衝區 (Buffers)」機制來處理這個部分。同時消費者等級與伺服器等級的 SSD 固態硬碟，在資料可用性的保護機制上也有所不同 ：
- 在「消費者等級」SSD 固態硬碟當中，透過「Volatile Cache」及「電池 (Battery)」機制以確保不會因為意外失去電源而導致資料遺失。
- 在「伺服器等級」SSD 固態硬碟當中，則透過「電容 (Capacitor)」以提供電源保護機制。
「舊式企業級 SSD」(Older Enterprise-Grade SSD)，具備可拆卸及更換的「內建電池」提供電源保護機制。
「新式企業級 SSD」(Newer Enterprise-Grade SSD)，則是使用「電容 (Capacitor)」也就是下圖中 3 顆黃色顆粒裝置以便提供電源保護機制。
那麼，倘若在 S2D 軟體定義儲存的運作環境當中採用「消費者等級 SSD 固態硬碟」時會發生什麼事？ 下列，便是採用 1TB SATA SSD (5 年保固)消費者等級的 SSD 固態硬碟進行實驗：
- QD32 4K Read： 95,000 IOPS
- QD32 4K Write： 90,000 IOPS
- 資料儲存耐用性： 185 TB
根據上述消費者等級的 SSD 固態硬碟效能數據及資料儲存耐用性，我們來估算一下這樣的消費者等級 SSD 固態硬碟其「DWPD (Device Writes per Day)」數值：
- 185 TB / (365 days x 5 years = 1825 days) = ~ 100 GB writable per day
- 100 GB / 1 TB total capacity = 0.10 DWPD
首先，透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試：
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Su -D -L -d1800 -Rxml Z:\load.bin
可以看到測試長度為「30 分鐘」，但是從測試數據中可以看到在資料存取不到「3 分鐘」之後 IOPS 突然「下降 10,000 IOPS」，這對於消費者等級的 SSD 固態硬碟來說是非常正常的現象。因為 FTL 已經用完預設準備給 NAND 的寫入空間了，所以導致資料存取速度變得非常的慢，因為整個資料存取動作已經中斷並且必須重新準備。
同樣的工作負載，再次透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試，但是加上「Write-Through」的動作 (參數 -Suw)，讓整個 NAND 的延遲時間及 FTL/Buffer真正顯現出來。從下圖中可以看到，IOPS 效能數據的結果非常差：
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Suw -D -L -d1800 -Rxml Z:\load.bin
結論
因此，在 Windows Server 2016 所建構的 S2D 軟體定義儲存環境中，應該選擇及採用具備「Non-Volatile Write Cache」及「Enterprise-Grade SSD」特性的企業級 SSD 固態硬碟。那麼，該如何確認選擇的企業級 SSD 固態硬碟支援「Non-Volatile Write Cache」機制？- 在 DataSheet 中看到「PLP (Power Loss Protection)」字眼，例如，Samsung SM863、Toshiba HK4E…等。
- 在 DataSheet 中看到「Enhanced Power Loss Data Protection」字眼，例如，Intel S3510、S3610、S3710、P3700…等。
參考資源
↧
↧
Red Hat Forum Taipei 2016 簡報開放下載
前言
日前 (2016.12.15)，在 Taiwan 舉辦的 Red Hat Forum Taipei 2016 議程簡報已經開放下載了，有興趣的朋友可以參考看看。簡報下載
【KeyOnte - 主題演講】
【分堂議程 - 主軸 A】
- 企業級 Container 應用
- Microsoft + Red Hat – 完整的混合雲需求解決方案
- 藉由 Red Hat Management Portfolio 實現數位轉型
- Lenovo 定義未來趨勢 - 朝雲端機房邁進
- 為何軟體定義儲存對您的 IT 策略非常關鍵
【分堂議程 - 主軸 B】
↧
132 期 - 安全可用性全面提升 vSphere 6.5 新版本亮點多
網管人雜誌
本文刊載於 網管人雜誌第 132 期 - 2017 年 1 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言vCenter Server 功能再進化
安全性
vMotion 流量加密
高可用性機制
DRS 自動負載平衡機制再增強
儲存功能增強
支援 4K Native Drives in 512e 運作模式
預設採用 SE Sparse 虛擬磁碟格式
LUN 可擴充性
CBRC 讀取快取空間支援至 32 GB
網路功能增強
增強 Nested ESXi 運作效能
VMkernel Port 可配置不同預設閘道
實戰 VM 虛擬主機加密機制
組態設定金鑰管理伺服器
建立加密原則
VM 虛擬主機套用加密原則
結語
前言
在 VMware VMworld 2016 大會上，由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出，並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈，同時提供相關新版產品映像檔的下載。
圖 1、新版 VMware vSphere 6.5 打造 SDDC 軟體定義資料中心願景
當然，每次只要新版本的發佈相關硬體資源支援度便會再次提升。在下列表格當中，我們條列出目前許多企業及組織仍使用的主流版本 vSphere 5.5 及 vSphere 6.0，以及最新版本 vSphere 6.5 在支援度上有哪些再提升的部分（詳細資訊請參考 VMware KB 1003497）。
請注意，倘若企業或組織仍使用舊版 vSphere ESXi 5.0 / 5.1以及 vCenter Server 5.0 / 5.1版本的話，那麼已經於「2016 年 8 月 24 日」進入「終止支援（End Of Support，EOS）」，因此企業或組織應儘快進行版本升級的動作。
vCenter Server 功能再進化
拜雲端運算風潮所賜，在企業或組織當中早已經建立 vCenter Server 管理平台。或許，IT 管理人員可能希望嘗試使用 vCSA，但是目前所管理的 vSphere 虛擬化運作環境中，已經採用安裝於 Windows Server 作業系統的 vCenter Server。事實上，VMware 官方早已經推出 vCenter Server 平台遷移工具，最新的遷移版本為 vCenter Server Migration Tool： vSphere 6.0 Update 2m，同時在新版遷移工具中支援遷移的目標對象為「Windows vCenter Server 5.5、6.0」。因此，即便企業及組織已經建立最新的 Windows vCenter Server 6.0，仍可以透過 vCenter Server遷移工具將 vCenter Server 管理平台遷移至最新的 vCSA 6.5 版本中。此外，新版的 vCenter Server 遷移工具支援更細緻的遷移選項：
- Configuration。
- Configuration、Events、Tasks。
- Configuration、Events、Tasks、Performance Metrics。
同時，在最新版本的 vCSA 6.5 當中，VMware 官方為 vCSA 打造原生 HA（High Availability）機制，這個 HA 機制是由「Active、Passive、Witness」成員節點所組成。當 vCenter HA Cluster 某個成員節點發生災難事件時（例如，擔任 Active 角色的成員節點主機發生硬體故障），便會觸發 vCenter HA 機制。目前，vCSA HA 機制的 RTO 預計為「5 分鐘」，當然實際上必須視底層硬體資源的工作負載情況而定。
圖 2、vCenter HA 及 PSC HA 協同負載平衡運作架構示意圖
安全性
雖然，加密 VM 虛擬主機的機敏資料是多年來一直在進行的事情，但每項解決方案都有不足或造成困擾的部分。在最新 vSphere 6.5 虛擬化平台中希望能夠解決這個問題，加密的對象將針對「VM Home Files（VMX，Snapshot…等）」以及「VMDK 虛擬磁碟」。同時，加密的動作是當「資料 I/O」從 VM 虛擬主機的 vHBA 虛擬磁碟控制器出來時，再傳送到「Kernel Storage Layer」之前就會進行加密的動作。vMotion 流量加密
針對 vMotion 傳輸流量進行加密的要求其實已經很長一段時間，現在開始於新一代 vSphere 6.5 虛擬化平台中正式提供此功能。此外，在這個版本中的「vMotion Encryption」並非加密網路所以無須管理憑證或其它網路組態設定。加密是針對「每台 VM 虛擬主機」層級，當 VM 虛擬主機啟用 vMotion Encryption 機制後，倘若針對該 VM 虛擬主機進行 vMotion 線上遷移作業時，vCenter Server 將會「隨機產生」（Randomly Generated）1 個「One time 256-bit Key」（請注意，此加密金鑰並不會採用 vCenter Server Key Manager 產生）。
除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」，所以當進行 VM 虛擬主機 vMotion 線上遷移作業時，將會打包「256-bit Key 加上 64-bit 隨機數」在「2 台 ESXi 主機」之間，以確保兩端之間通訊所傳輸的資料無法被惡意人士所複製。
在組態設定部分提供下列 3 種 vMotion Encryption 設定值：
- Disabled： 停用 vMotion Encryption 機制。
- Opportunistic： 預設值，當來源端及目的端 ESXi 主機都支援 vMotion Encryption 機制時，在執行 vSphere vMotion 時將會加密傳輸流量，倘若有任何一方不支援便不會加密 vSphere vMotion 傳輸流量。
- Required： 來源端及目的端 ESXi 主機都必須支援 vMotion Encryption 機制，倘若有任何一方不支援便無法順利執行 vSphere vMotion 線上遷移機制。
圖 3、為 VM 虛擬主機組態設定加密 vSphere vMotion 遷移流量
高可用性機制
在新版 vSphere 6.5 環境當中增加「vSphere HA Orchestrated Restart」機制，當 ESXi 主機發生故障損壞事件觸發 vSphere HA 高可用性機制時，能夠依照管理人員指定的啟動順序，依序將 VM 虛擬主機啟動以便應用程式能夠正常重新啟動。
圖 4、觸發 vSphere HA 高可用性機制時，依序啟動 VM 以便應用程式能夠正常重新啟動
DRS 自動負載平衡機制再增強
在過去的 vSphere 運作環境中，在 DRS 自動化負載平衡演算法機制是採用「標準差模型」（Standard Deviation Model）的方式運作。現在，新版 vSphere 6.5 運作環境中除了原本標準差模型運作之外，更加入「成對計算」（Pairwise Calculation）機制，以便更容易在 VMware Cluster 內計算 ESXi 主機及 VM 虛擬主機的工作負載，達到更佳的負載平衡機制。同時，在 vSphere DRS 的組態設定內容中也增加 3 個最常使用的進階功能，以便管理人員能夠更進一步的管控 vSphere DRS 負載平衡機制：
- 均勻分佈虛擬機器： 啟用後，將盡力在 VMware Cluster 的 ESXi 成員主機之間，讓 VM 虛擬主機的工作負載能夠達到最大限度的負載平衡。
- 已取用記憶體與作用中記憶體的對照： 啟用後，將以 Active Memory 25% 的記憶體空間當成主要指標，以便盡量避免 VMware Cluster 運作環境中發生 Memory 過度使用的情況。
- CPU 過度分配： 在 VMware Cluster 層級中套用 vCPU： pCPU 的最大使用比率，一旦到達組態設定的比例後便無法啟動 VM 虛擬主機，有效避免許多 VM 虛擬主機同時啟動（例如，VDI 虛擬桌面環境），造成 CPU 資源嚴重超用的情況。
圖 5、vSphere DRS 組態設定內容中新增 3 個最常使用的進階功能
儲存功能增強
在目前主流的 vSphere 5.5 及 6.0版本當中，所採用的 VMFS 檔案系統版本為「VMFS 5」。在最新 VMware vSphere 6.5版本當中，可以使用 VMFS 6 新版檔案系統，下列便是 VMFS 6 檔案系統的新增功能項目：- 支援 4K Native Drives in 512e 運作模式。
- 預設採用 SE Sparse 格式的虛擬磁碟，以便自動化執行空間回收機制。
- LUN 可擴充性最大支援至 512 個 LUN 及 2,000 路徑。
- CBRC 讀取快取空間由舊版的最大 2 GB 提升為 32 GB。
圖 6、新版 vSphere 6.5 運作環境中，支援最新 VMFS 6 檔案系統
支援 4K Native Drives in 512e 運作模式
簡單來說，新一代的新式硬碟（2011 年 1 月起出廠的硬碟）採用的進階格式為「4K Byte Sector」而非舊有的「512 Byte Sector」。因此，從 vSphere 6.5 版本開始支援由 512e 模擬 4K 的方式運作，以便配合實體硬碟特性增強整體運作效能。值得注意的是 Virtual SAN 6.5 目前仍僅支援 512e 運作模式，相信後續版本便有可能全面支援 4K Byte Sector，有關 4K / 512 Byte Sector 的相關資訊請參考 VMware KB 2091600。
圖 7、4K / 512 Byte Sector 資料讀取及寫入示意圖
圖片來源： Seagate –先進格式 4K 磁區硬碟機轉換
預設採用 SE Sparse 虛擬磁碟格式
在過去舊版 vSphere 運作環境中，只有透過 VMware Horizon「連結複製」（Linked Clone）技術，所部署的 VM 虛擬主機虛擬磁碟能夠採用「SE Sparse（Space-Efficient Sparse Virtual Disks）」虛擬磁碟格式，以便達成 VM 虛擬主機中因為使用者建立資料又刪除資料時產生的空白資料區塊能夠自動回收的目的。倘若，在伺服器虛擬化環境中則必須管理人員，手動執行相關指令才能執行空白資料區塊佔用空間回收的動作。現在，新版 vSphere 6.5運作環境中當採用 VMFS 6檔案系統後，預設情況下便採用 SE Sparse 虛擬磁碟格式，讓採用「精簡佈建」（Thin Provision）的 VM 虛擬主機，能夠在使用者刪除 VM 虛擬主機內相關資料後，自動執行空白資料區塊佔用空間回收的動作。
圖 8、SE Sparse 儲存空間自動回收運作示意圖
LUN 可擴充性
在目前 vSphere 6.0版本運作環境中，儲存資源 LUN 的最大支援數量為「256」路徑為「1,024」，雖然這樣的儲存資源支援度已經可以因應非常大的運作規模。但是，在新版 vSphere 6.5運作環境中，將儲存資源 LUN 的最大支援數量再次推升至「512」路徑為「2,000」。CBRC 讀取快取空間支援至 32 GB
早從 VMware vSphere ESXi 5.0 版本開始，便原生支援 ESXi Host Caching 機制「CBRC（Content-Based Read Cache）」，此快取機制是從實體伺服器中切出一塊實體記憶體空間（最大支援至 2 GB），以便降低 ESXi 儲存資源的 Read I/O Requests 工作負載。現在，最新版本 vSphere 6.5運作環境中，CBRC 讀取快取空間最大支援至「32 GB」，透過實體記憶體快速存取的特性，有效讓 ESXi 儲存資源的 Read I/O Requests 工作負載降至更低。(有關 CBRC 讀取快取的詳細運作機制，請參考網管人雜誌第 94 期「設定 VMware 內建快取機制，加速虛擬桌面環境效能」文章內容。)
圖 9、新版 vSphere 6.5 運作環境中 CBRC 讀取快取空間最大支援至 32 GB
網路功能增強
在新版 vSphere 6.5 當中網路功能增強的部分，例如，VMkernel 能夠支援 2M Page、VMKAPI 鎖定功能增強以便提升 vDS 分散式交換器可擴展性、健康狀態檢查機制升級……等。同時，除了運作效能提升外對於管理功能也同步增強，舉例來說，在過去舊版 vSphere 運作環境中當需要為 VM 虛擬主機配置 SR-IOV 網路卡時，必須管理人員介入手動為指定的 VM 虛擬主機配置 SR-IOV 網路卡，現在則可以在 VM 虛擬主機中如同增加其它虛擬裝置一樣新增 SR-IOV 網路卡。
圖 10、為 VM 虛擬主機組態配置 SR-IOV 網路卡
增強 Nested ESXi 運作效能
在過去 vSphere 舊版運作環境中，虛擬網路交換器 vSwitch 的設計是每個 vNIC 連接埠僅支援「單一 Unicast MAC 位址」，所以在 Nested ESXi 運作環境中必須「啟用」Promiscuous Mode，那麼 Nested ESXi 的網路功能才能順利運作。但是，此舉也同時造成 vSwitch 將所有流量都傳送到 Nested ESXi 主機中，這會導致不必要的網路封包也都傳送至 Nested ESXi 主機，造成「CPU 高使用率」及「網路效能低落」的情況。現在，在新版 vSphere 6.5 運作環境中 vSwitch 具備 MAC 學習功能，所以僅會轉送相關的網路封包給 Nested ESXi 主機，因此可以明顯提升 Nested ESXi 主機運作效能。
圖 11、在建立客體作業系統時選擇版本 VMware ESXi 6.5 以便建立 Nested ESXi
VMkernel Port 可配置不同預設閘道
在過去舊版 vSphere 運作環境中，vSphere vMotion、vSphere DRS、iSCSI……等進階服務只能共同使用「單一預設閘道」。雖然，可以透過額外新增「靜態路由」的方式，解決不同服務採用不同預設閘道的問題，但是過多的靜態路由會造成管理上的麻煩。現在，新版 vSphere 6.5運作環境中，可以針對不同的 VMkernel Port 指定採用「不同預設閘道」。因此，管理人員無須再為不同服務必須採用不同預設閘道及額外新增靜態路由而苦惱，同時也因為無須再額外新增靜態路由同步讓 ESXi 主機的運作效能提升。
實戰 VM 虛擬主機加密機制
那麼就讓我們來實戰 VM 虛擬主機加密機制的組態設定部分吧。簡單來說，當加密機制運作環境準備妥當之後，只需要進行下列 4 項操作步驟即可為 VM 虛擬主機建立加密機制，以便保護 VM 虛擬主機當中的機敏資料：- 將金鑰管理伺服器加入至 vCenter Server 管理平台當中。
- 建立加密原則。
- 為現有 VM 虛擬主機套用加密原則，或為新建立的 VM 虛擬主機啟用加密原則。
- 為套用加密機制的 VM 虛擬主機進行解密。
組態設定金鑰管理伺服器
首先，請透過 vSphere Web Client 管理工具登入 vCenter Server 管理平台後，依序點選「首頁 > vCenter 詳細目錄清單 > 資源 > vCenter Server」，接著在右方管理介面中依序點選「管理 > 金鑰管理伺服器 > 新增伺服器」項目。
圖 12、準備新增金鑰管理伺服器並加入 vCenter Server 管理平台
在彈出的新增 KMIP 伺服器視窗中，請依序在相關欄位填入運作環境資訊：
- 金鑰伺服器叢集： 因為運作環境中尚未有任何金鑰管理伺服器，所以選擇預設值建立新叢集即可。
- 叢集名稱： 請鍵入金鑰管理伺服器叢集名稱，此實作環境為 Key MGMT Server Cluster。
- 伺服器別名： 請鍵入金鑰管理伺服器容易記憶的名稱，此實作環境為 KeyServer。
- 伺服器位址： 請鍵入金鑰管理伺服器 FQDN 或 IP 位址，此實作環境為 kms.vsphere.weithenn.org。
- 伺服器連接埠： 請鍵入金鑰管理伺服器服務連接埠號碼，此實作環境為預設的 5696。
圖 13、鍵入金鑰管理伺服器運作環境資訊
當 vCenter Server 順利與金鑰管理伺服器連線後，將會自動彈出信任憑證視窗請按下「Trust」鈕即可。順利新增金鑰管理伺服器後，請將這台金鑰管理伺服器設定為叢集中的預設值，請點選 Key MGMT Server Cluster項目後按下「將叢集設定為預設值」，並於彈出的視窗中按下「是」鈕即可。
圖 14、將這台金鑰管理伺服器設定為叢集中的預設值
組態設定完畢後，便可以看到 Key MGMT Server Cluster 項目結尾多出「（預設值）」字樣。同時，請確認金鑰管理伺服器的「連線狀態」以及「憑證狀態」是否正常運作中。
圖 15、確認金鑰管理伺服器的「連線狀態」以及「憑證狀態」是否正常運作中
建立加密原則
請依序點選「首頁>原則和設定檔>虛擬機器儲存區原則>建立虛擬機器儲存區原則」。此時，將會彈出建立新的虛擬機器儲存區原則視窗，首先在名稱與說明頁面中請於名稱欄位鍵入此儲存加密原則的名稱（此實作環境中，我們鍵入的名稱為 VM Encryption Policy），在原則結構頁面中採用預設值即可。在一般規格頁面中，請勾選「使用虛擬機器存放區原則中的一般規則」項目後按下「新增元件」鈕後選擇「加密」項目。
圖 16、在虛擬機器儲存區原則中準備新增加密原則
此時，頁面中將出現「加密 > 自訂 > 提供者」項目，然後請在新增規格下拉式選單中選擇至「vmcrypt」項目，並於出現的 Allow I/O filters before encryption欄位下拉式選單中保持預設值「False」即可。
圖 17、在虛擬機器儲存區原則中新增加密原則
在規則集頁面中，請確認「使用儲存區原則中的規則集」項目並未勾選即可。然後在儲存區相容性頁面中，選擇採用相容的 Datastore 儲存區即可。最後，在即將完成頁面中再次檢視組態設定內容無誤後，按下完成鈕即可。當系統建立好加密原則之後，在虛擬機器儲存區原則中便會看到剛才所新增的「VM Encryption Policy」加密原則。
圖 18、順利新增用於 VM 虛擬主機的加密原則
VM 虛擬主機套用加密原則
順利將用於保護 VM 虛擬主機內機敏資料的加密建立後，請依序點選「首頁 > vCenter 詳細目錄清單 > 虛擬機器 > 新增虛擬機器」。此時，將會彈出新增虛擬機器視窗，在選取建立類型頁面中此實作環境選擇「建立新的虛擬機器」項目。
圖 19、建立新的 VM 虛擬主機並準備套用加密原則
在選取名稱和資料夾頁面中，請鍵入 VM 虛擬主機名稱（此實作環境為 Secret-VM），然後選擇此台 VM 虛擬主機所要存放的目標 DataCenter 或資料夾即可。在選取運算資源頁面中，請選擇此台 VM 虛擬主機所要存放的目標 Cluster 或 ESXi 主機即可。在選取儲存區頁面中，請於虛擬機器儲存區原則下拉式選單中，選擇至剛才所建立的「VM Encryption Policy」加密原則項目，並確認所採用的 Datastore 儲存原則通過相容性檢查作業。
圖 20、為新建立的 VM 虛擬主機選擇套用加密原則
在選取相容性頁面中，請於相容下拉式選單中選擇「ESXi 6.5 及更新版本」項目，確保此台 VM 虛擬主機採用最新虛擬硬體版本 13，以便屆時能夠順利使用加密機制保護 VM 虛擬主機中的機敏資料。
圖 21、為建立的 VM 虛擬主機選擇採用最新虛擬硬體版本 13
在選取客體作業系統頁面中，請選擇 VM 虛擬主機所採用的客體作業系統以及版本即可。在自訂硬體頁面中，首先於虛擬硬體頁面中你會看到 Encryption 欄位顯示為「VM files are encrypted」，表示預設安裝客體作業系統的虛擬磁碟已經受到加密保護。倘若，管理人員為此台 VM 虛擬主機新增其它虛擬硬碟時，那麼也可以展開新增硬碟項目後在虛擬機器儲存區原則下拉式選單中，為新增的虛擬磁碟套用加密機制。
圖 22、為 VM 虛擬主機額外新增的虛擬磁碟套用加密機制
然後，請點選虛擬機器選項頁籤後，展開下方 Encryption 項目將 Encryption vMotion 下拉式選單中選擇至「Required」項目，確保此台 VM 虛擬主機在執行 vSphere vMotion 線上遷移期間，所有傳輸的記憶體狀態及相關網路流量是有進行加密的，避免遭受惡意人士監聽相關流量後引發資安事件或造成安全性風險。
圖 23、為 VM 虛擬主機組態設定加密 vSphere vMotion 遷移流量
在即將完成頁面中，再次檢視組態設定內容無誤後按下完成鈕即可。至此，VM 虛擬主機便順利套用加密原則，即便整台 VM 虛擬主機或虛擬磁碟（VMDK）直接被惡意人士複製後帶走，那麼也無法查看 VM 虛擬主機當中所儲存的機敏資料。
結語
透過本文的說明及實作相信讀者已經了解，在新版的 vSphere 6.5 當中舊有的功能增強部分，以及新增的特色功能機制，能夠幫助企業及組織建立更靈敏、高可用性、高安全性的雲端運算環境。↧
深入剖析 S2D Storage Pool
前言
自從 Windows Server 2016 推出後，大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。本文，將要深入探討在 S2D 軟體定義儲存運作環境中「Storage Pool」的功能改進：- 每個 Storage Pool 最大支援「416 Drives」及 「1 PB Raw Capacity」，同時最佳建議是「One pool per Cluster」。
- 執行「Enable-ClusterS2D」指令啟用 S2D 功能時，會自動建立 Storage Pool 並且把「合格的儲存裝置」(例如，未格式化過的磁碟) 加入到 Storage Pool 當中。同時，當加入新的 S2D 儲存節點時 (Scale-Out) 也會自動把相關的儲存裝置加入到 Storage Pool 當中，當儲存裝置發生故障時會自動退出並從 Storage Pool 當中移除。
- 透過 S2D PM「Cosmos Darwin」撰寫的 PowerShell，可以輕鬆幫助你了解 Storage Pool 及儲存裝置空間的使用情況。
混亂的開始 (Resiliency, Slabs, Striping)
讓我們先從 3 Nodes的 S2D 運作架構，每台 S2D Node 具備「2 x 800GB NVMe」以及「4 x 2TB SATA SSD」開始談起。
什麼是 Resiliency？
舉例來說，當我們建立「1 TB - 2WayMirror」的 Volume 時，這表示在「不同 Server、不同 Drives」必須維護共「2 份」副本資料，以便 1 份資料損壞時另 1 份仍然可用。所以，雖然建立 1TB Volume 但實際會佔用 2 TB空間，這樣的行為稱之「Footprint on the Pool」。
什麼是 Slabs？
在建立的 1 TB Volume儲存空間中，系統將會把它拆解成眾多的「Slab」並且每個 Slab 大小為「256 MB」(在 Windows Server 2016 技術預覽版本時稱為 Extent 大小為 100 MB) 。因此，倘若建立 1 TB Volume儲存空間的話便會拆解成「4,000 Slabs」。
什麼是 Striping？
當我們採用 2-Way Mirror的方式建立 Volume 並且拆解成眾多 Slab 之後，「每個 Slab」將會建立「2 份副本」，然後透過 S2D 演算法分別存放在「不同 Server, 不同 Drives」當中。
因此，原則上眾多 Slabs 將會「平均且分散」的儲存到不同 Server 不同 Drives 當中。同時，預設情況下 Cluster 當中至少會有 5 個 Drive 儲存「Pool Metadata」以便後續「同步」(Synchronized)及「修復」(Repaired)等作業。此外，即便儲存的 Pool Metadata 都遺失，也不會影響 S2D 的部署及運作。
S2D 這樣設計的目的為何？
效能考量
將 Volume 拆解成眾多 Slab 然後平均分散放置到多個儲存媒體時，這樣可以提供「資料讀寫」的效益同時可以使用多個儲存媒體，以期「最大化 IOPS & I/O Throughput」。因此，S2D 的 2-Way Mirror 機制與傳統的 RAID-1 並不相同。提升資料安全性
當「儲存裝置」發生故障時，原有儲存的資料副本將會在其它位置進行重建，這個行為稱之為「修復」(Repairing)並執行下列 2 項操作步驟：修復步驟1、從「存活」的資料副本中讀取 (讀取單位為 Bytes)：
- 想像一下，假設 S2D 沒有把 Volume 拆解成眾多 Slab 的話，那麼當 1TB Volume 副本所在的硬碟損壞時，採用的若是機械式硬碟要進行上述修復程序的第 1 項時，光是讀取 1TB Bytes 資料這個動作，可想而知整個資料重建程序將會非常緩慢!!
- 回到 S2D 的運作架構，有顆機械式硬碟損壞裡面存放一堆 Slab，但是這些 Slab 存活的資料副本是分佈在「不同機械式硬碟」中，有的可能在 Drive03、Drive15、Drive17……等。
- 重點就是，這個重建的動作可以同時使用到「多顆」機械式硬碟而非「單顆」機械式硬碟!!
修復步驟2、在其它位置寫入「新的」資料副本，以取代遺失的資料副本：
- 原則上，只要哪裡有儲存空間就往哪裡寫。但是，機械式硬碟損壞的那台伺服器就會不再放置重新的資料副本。
- 簡單來說，透過 Volume 打散成 Slab 的機制，不但提升資料安全性讓故障事件發生時「Resync」的等待時間縮短。
考量 Reserve Capacity
簡單來說，在你所建立的 Storage Pool 當中，應該要「預留」一些額外的儲存空間而不要都用盡!! 舉例來說，當機械式硬碟故障進行資料副本的修復程序時，才有緩衝的儲存空間可供使用。這個概念有點類似 HDD Hot Spare但在實際運作上又有點不同。強烈建議要預留空間，但就算沒有預留儲存空間 S2D 還是能正常運作，只是當「故障事件」發生時倘若沒有預設儲存空間的話將會影響修復速度。
自動建立儲存集區及重新負載平衡
當 S2D 叢集當中加入新的 S2D Node 時，會自動將 Slab 資料副本自動負載平衡到新的 S2D Node 當中，這個動作稱之為「最佳化」(Optimizing)或「重新平衡」(Re-Balancing)。例如，在本文 S2D Cluster 中原本只有 3 Nodes 現在加入第 4 台 Node，只要鍵入「Add-ClusterNode -Name <Name>」PowerShell 指令即可。
順利將第 4 台 Node加入後，「一開始」該 Node 的儲存裝置的使用空間還是空的。
預設情況下，經過「30 分鐘後」 S2D 將會「自動」執行「重新平衡」(Re-Balancing)的動作，但隨著運作規模大小將會需要不同的時間 (例如，幾小時)。倘若，你不希望等待 S2D 自動執行的話，可以手動執行「Optimize-StoragePool -FriendlyName "S2D*"」的 PowerShell 指令讓 S2D 立即執行重新平衡的動作，並且透過「Get-StorageJob」查看重新平衡的工作進度。
因此，當重新平衡作業執行完畢後，可以看到前 3 台 Node 的使用空間「下降」，因為平均且分散放置到第 4 台 Node 的儲存空間。
小結
- 建立 S2D 的 Storage Pool 之後，無須再針對 Storage Pool 進行調整 (例如，新增 HDD、刪除 HDD……等)或額外再建立 Pool。
- 建立的 Volume 會拆解成眾多 Slabs，然後平均分散到不同 Server / 不同 Drives。
- 最好在 S2D Storage Pool 當中「預留」儲存空間，以便故障事件發生時能夠更快的進行修復作業。
- 當 S2D 建立的 Storage Pool 加入新的 Node 時，會「自動」進行重新平衡的動作，保持資料副本平均分散到不同 Server / 不同 Drives 的原則。
- 你可以透過「Get-StoragePool S2D*」、「Get-StoragePool S2D* | Get-PhysicalDisk」查看 S2D Storage Pool 相關資訊。
- Written by Cosmos Darwin (MIT License) - Show-PrettyPool.ps1
- Written by Cosmos Darwin (MIT License) - Show-PrettyPool-Simplified.ps1
參考資源
↧