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 Lifecycle Product Matrix

對於採用 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 Blog – Introducing the vSphere Host Client Fling

日前，最新的 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 vSphere Blog – Goodbye vSphere Client for Windows（C#）– Hello HTML5

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 主機的任務。

繼續閱讀 >>

[站長開講] Community Open Camp

活動影片及講義 (2016/9/14 更新)

本次活動的錄影已經陸續上線，當天沒空參加的朋友可以補一下進度了。

• Channel 9 - Community Open Camp 2016 (所有議程影片)
• Channel 9 - Community Open Camp 2016 - Unix-like workloads on Hyper-V (站長議程)

此次活動另一個難忘的經驗，是接受由美國 Channel 9 團隊來訪並邀約採訪，與主持人全程英文隨性問答聊天 :)

• Channel 9 - Community Open Camp 2016 - Interview with Weithenn Wang

活動簡介

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 號)
• 報名： 活動報名

活動內容

• 活動議程
• 講者介紹

繼續閱讀 >>

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-2600 v4 雙路硬體伺服器，倘若採購的 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 資料中心版本才行。

繼續閱讀 >>

VMworld 2016 - STO7605 及 INF8036 簡報

前言

日前舉行的 VMworld 2016 - US 已經落幕，其中 Duncan Epping 已經將他在大會上演講的議程 STO7605 及 INF8036 簡報釋出，有興趣的朋友可以參考看看。


STO7605 簡報

INF8036 簡報

繼續閱讀 >>

127 期 - 用圖形化 RSMT 遠端工具，極精簡伺服器維運超順手

網管人雜誌

本文刊載於 網管人雜誌第 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 主機的硬體資源監控及管理的目的。

繼續閱讀 >>