網管人雜誌

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

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 主機的硬體資源監控及管理的目的。

活動資訊

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



課程大綱

VMware 虛擬化平台最佳硬體規劃
虛擬化實作環境建置(Nested VMs)
建置 VMware 虛擬化平台
  • 安裝及管理 vCenter Server、ESXi
建置 VMware Horizon View 桌面虛擬化環境
  • 安裝及管理 View Composer Server
  • 安裝及管理 View Connection Server
  • 安裝及管理 View Security Server
VDI 虛擬桌面管理
  • 安裝及設定 Master Image
  • 利用 Lined-Clone 大量部署VDI虛擬桌面
  • 建立 VDI 虛擬桌面資源池
使用者設定檔管理
  • 設定 View Persona Management
  • 設定 Windows 漫遊使用者設定檔
連結 VDI 虛擬桌面
  • 介紹 Thin Client、Zero Client
  • 安裝 VMware View Client(支援 PC/NB、Android、iOS)
  • 以瀏覽器連結 VDI 虛擬桌面
  • 介紹虛擬列印(Virtual Printing)

說明

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



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


參考


網管人雜誌

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


文章目錄

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


前言

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

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

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

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


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

圖 1、VMware Host Client 操作示意圖 


vSphere FT 運作架構

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

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

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

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

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

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

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

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


運算資源(Compute)

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

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


儲存資源(Storage)

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

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

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

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

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


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

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

運作狀態(Runtime State)

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

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


網路資源(Network)

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

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

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

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


透明容錯移轉(Transparent Failover)

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

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

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

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


啟用 vSphere FT 技術的注意事項

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

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



最佳作法

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

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

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

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

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

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

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


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

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

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


vSphere FT 效能測試

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

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

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

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


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

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

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


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

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

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

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


實作 vSphere FT 高可用性機制

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

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

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

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

圖 14、勾選 Fault Tolerance logging 項目

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

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

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

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

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

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


結語

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

活動簡介

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


    活動資訊




    活動內容





    活動影片及講義

    Coming Soon...

    網管人雜誌

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

    文章目錄

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



    前言

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

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

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


    Microsoft Azure Stack 概觀

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

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

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


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

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


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

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

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

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


    MAS POC 運作架構

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

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

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

    圖6、Microsoft Azure Stack POC 運作架構


    部署 MAS 的前置作業 

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

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

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


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

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

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

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

    圖7、建立 Microsoft Azure AD 帳戶


    安裝 MAS TP1 混合雲平台

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    登入 MAS 入口網站

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

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

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


    提供 IaaS 服務

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

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

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

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

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

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

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


    建立租用戶使用者帳號

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

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

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

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

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

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

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

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

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

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


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

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


    結語

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