網管人雜誌

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





文章目錄

前言
管理工具新體驗 - Project Honolulu
          Honolulu 運作架構
          Honolulu 管理主機支援的作業系統
實戰演練 – 建構 Honolulu 管理主機
          安裝全新 Windows Server 2016 Server Core 主機
          安裝 Project Honolulu 管理工具
          管理單台 Windows Server 主機
          管理容錯移轉叢集
          管理 HCI 超融合基礎架構
結語





前言

在商業數位化的浪潮下,企業及組織為持續擴大服務範圍的廣度及深度,不斷在資料中心內新增伺服器數量,以便提供各式各樣的應用程式或服務給使用者。雖然,管理 Windows Server 在一般使用者眼中,不過就是透過 GUI 圖形化介面搭配滑鼠進行管理而已,然而熟知 Windows Server 管理程序的 IT 人員知道事實並非如此。

舉例來說,為了管理 Windows Server 的各項裝置所以需要開啟裝置管理員、希望查看系統工作負載需要開啟工作管理員 / 資源監視器 / 效能監視器、處理資料夾及檔案的搬移或複製作業需要開啟檔案總管……等。

此外,除了這些 Windows Server 本機端的管理工具之外,管理人員也可以透過多項遠端管理工具,例如,伺服器管理員(Server Manager)、Windows PowerShell CIM、WMI(Windows Management Instrumentation)、WinRM(Windows Remote Management)、RSAT(Remote Server Administration Tools)……等達成遠端管理的目的。

儘管,管理人員可以在內部資料中心內建立 System Center 運作架構,或是在 Microsoft Azure 公有雲環境中建立 OMS(Operations Management Suite)監控解決方案,達成遠端管理及監控 Windows Server 主機的目的。但是,對於中小型的運作規模來說,建立 System Center 或 OMS 管理及監控解決方案來說,不管是在 IT 預算方面或硬體資源的準備方面來說都太過龐大。

因此,在幾年前的 Ignite 2015 年度技術大會上,Powershell 指令工具的發明人 Jeffrey Snover,便在 Ignite 2015 大會上正式宣佈推出,採用 HTML 5 Web-Based 的 GUI 圖形化管理工具稱為 SMT(Server Management Tools)

管理人員可以透過 SMT 管理工具輕鬆管理「無周邊伺服器」(Headless Server),例如,Windows Server 2016 Server Core 以及 Nano Server,並提供檢視運作效能、執行程序、系統服務、事件檢視器、伺服器角色及功能……等管理事務。
有關 SMT 管理工具的詳細資訊,請參考本刊第 127 期 - 用圖形化 RSMT 遠端工具極精簡伺服器維運超順手

圖 1、透過 SMT 管理工具遠端管理 Nano Server





管理工具新體驗 - Project Honolulu

雖然,SMT 管理工具有著方便易用,並且能夠輕鬆管理 Windows Server Core 及 Nano Server 主機的優點,同時還能夠管理 Microsoft Azure 公有雲環境的 Windows Server 主機,以及透過企業及組織地端的 SMT Gateway 主機進行介接,進而管理地端資料中心內 Windows Server 主機,達到混合雲環境管理的目的。

但是,多數管理人員對於 SMT 管理工具的主要抱怨是,SMT 管理工具「只能」佈署在「Microsoft Azure 公有雲環境」當中,也就是說 SMT 管理工具並無法在完全「無網際網路」的環境當中,達到管理 Windows Server 的目的。

因此,在收集眾多 Windows Server 管理人員的操作體驗意見反應後,微軟在 Ignite 2017 大會上正式宣佈推出,新的管理工具操作體驗計劃稱為「Project Honolulu」。簡單來說,其實 Project Honolulu 管理工具是由 SMT 管理工具演化而來,但是已經能夠在完全無網際網路的運作環境當中,達到管理 Windows Server 主機的目的。當然,倘若能夠接觸網際網路的話也能夠與 Microsoft Azure 公有雲環境協同運作。
微軟官方也在部落格中正式發佈,只能在 Microsoft Azure 公有雲環境運作的 SMT 管理工具,將會在 2017 年 6 月 30 日正式除役。
圖 2、In-Box 管理工具新體驗- Project Honolulu



Honolulu 運作架構

由於先前 SMT 管理工具必須運作在 Microsoft Azure 公有雲環境中,同時現代化管理工具都採用 HTML 5 設計架構,所以微軟在收集眾多管理人員的意見反應後,推出能夠在企業及組織內部資料中心內運作無須連接至網際網路,並且只要採用支援 HTML 5 的瀏覽器便能連接至 Project Honolulu 管理介面。

Project Honolulu 管理工具承接 SMT 管理工具的易用性,只要至微軟評估中心,下載 Project Honolulu 管理工具 MSI 安裝執行檔後,只要執行 MSI 安裝執行檔並組態設定 Listen Port 即可。簡單來說,Project Honolulu 管理工具擁有下列容易建構及使用的功能特色:
  • 透過 Remote PowerShellWMI over WinRM(Port 5985)運作機制,即可快速納管 Windows Server 主機,被管理的 Windows Server「無須」安裝任何代理程式即可管控,達到「無代理程式」(Agentless)的運作架構。
  • 管理介面採用「HTML 5」架構,所以現代化瀏覽器即可輕鬆使用 Project Honolulu 管理工具。
  • 安裝 Project Honolulu 管理工具的管理主機,「無須」組態設定 IIS 網頁伺服器只要安裝 MSI 執行檔即可提供 Web Server 服務。
圖 3、Project Honolulu 管理工具運作架構示意圖



Honolulu 管理主機支援的作業系統

管理人員可以將 Project Honolulu 管理工具,安裝在 Windows 10、Windows Server 2012 / 2012 R2、Windows Server 2016、Windows Server version 1709 等作業系統版本。值得注意的是,倘若希望 Honolulu 管理主機擔任「Honolulu Gateway」的角色時,只能將 Project Honolulu 管理工具安裝在 Windows Server 2016,以及 Windows Server version 1709 作業系統版本才能支援。

此外,雖然 Project Honolulu 管理工具支援安裝在 Windows Server 2012 / 2012 R2 作業系統。但是,Windows Server 2012 / 2012 R2 主機,必須要先額外安裝 WMF(Windows Management Framework) 運作元件(最新版本為 WMF 5.1),屆時才能順利採用 PowerShell 遠端管理機制,納管 Windows Server 2016 及 Nano Server 主機。下列為 WMF 5.1 所包含的更新功能項目:

  • 包含 Windows Server 2016 所發佈的 PowerShell、WMI(Windowsd Management Instrumentation)、WinRM(Windows Remote Management)、SIL(Software Inventory Logging)。
  • 新增 PowerShell Cmdlet,例如,本機使用者、本機群組、Get-ComputerInfo、安裝 JEA(Just Enough Administration)模組、增強 Pull Server 安全性機制……等。
  • 軟體套件管理機制,新增支援容器、CBS 安裝程序、EXE-Based 安裝程序、CAB 軟體套件……等。
  • 增強 Windows PowerShell DSC(Desired State Configuration)除錯機制。

安裝 WMF 5.1 運作元件之前,請先確保 Windows Server 2012 / 2012 R2 主機,已經安裝 .NET Framework 4.5.2 或更高版本,否則安裝後將會發生關鍵功能運作失敗的情況。
原則上,建議採用 1 台全新安裝的 Windows Server 來擔任 Project Honolulu 管理主機,倘若現有運作環境無法新增 1 台全新主機擔任 Honolulu 管理主機的話,則應避免採用 Exchange Server、Skype Server、Lync Server、System Center 2012 R2 Service Management Automation 伺服器擔任 Honolulu 管理主機,因為 WMF 5.1 運作元件安裝在這些伺服器應用程式主機時將會發生衝突的意外情況。

圖 4、Project Honolulu 管理主機佈署模式示意圖





實戰演練 – 建構 Honolulu 管理主機

目前,Honolulu 管理工具仍在「技術預覽」(Technical Preview)階段,所以還無法完全取代傳統的 MMC(Microsoft Management Console)管理工具,但是已經能夠支援絕大部分的 Windows Server 管理事務。下列為目前 Honolulu 管理工具支援管理 Windows Server 的各項功能:
  • 顯示硬體資源使用率。
  • 憑證管理。
  • 事件檢視器。
  • 檔案總管。
  • Windows 本機防火牆。
  • 本機使用者帳號及群組。
  • 網路功能組態設定。
  • 查看及終止執行程序,以及建立執行程序傾印(Dump)。
  • 登錄(Registry)編輯工具。
  • 管理 Windows 系統服務。
  • 啟用及停止伺服器角色或伺服器功能。
  • 管理 Hyper-V VM 虛擬主機及 vSwitch 虛擬網路交換器。
  • 管理儲存資源。
  • 管理及組態設定 Windows 安全性更新。



安裝全新 Windows Server 2016 Server Core 主機

由於 Project Honolulu 管理主機,在屆時的應用情境中僅會透過支援 HTML 5 瀏覽器連接至 Honolulu 管理介面。所以,在本文實作環境中,安裝 1 台全新乾淨的 Windows Server 2016 Server Core 主機,以便充份利用精簡且僅有文字介面、效能良好、啟動系統服務較少、開啟連接埠較少、安全性更新較少的 Windows Server 2016 Server Core 版本,來擔任 Project Honolulu 管理主機的角色。

安裝好全新乾淨的 Windows Server 2016 Server Core 主機後,除了基本的系統組態設定如 IP 位址、時區及系統時間、電腦名稱、加入網域……等之外,並且透過「powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c」PowerShell 指令,將 Windows Server 2016 Server Core 主機電力選項調整為「High Performance」。最後,執行「Remove-WindowsFeature -Name FS-SMB1 -Restart」指令,將 Windows Server 2016 Server Core 主機中,預設安裝的 SMB v1 伺服器功能移除並且重新啟動主機以便套用生效。
在最新 Windows 10 Fall Creators Update 版本,以及 Windows Server version 1709(RS3)版本中,預設已經不會安裝 SMB v1 伺服器功能。詳細資訊請參考 Microsoft KB 4034314 知識庫文章。
圖 5、組態設定 Windows Server 2016 Server Core 主機電力選項為 High Performance



安裝 Project Honolulu 管理工具

將下載的 Project Honolulu 管理工具 MSI 安裝執行檔(HonoluluTechnicalPreview1709-20016.msi),複製到 Windows Server 2016 Server Core 主機後,開啟命令提示字元切換至存放 Project Honolulu 管理工具 MSI 安裝執行檔路徑,執行 Honolulu 管理工具安裝作業。

值得注意的是,在安裝 Honolulu 管理工具過程中,將會請管理人員指定 Honolulu 管理工具屆時提供網頁服務的「連接埠號」「SSL 憑證」。在本文實作環境中,組態設定採用 443 連接埠號及自我簽署的 SSL 憑證,企業及組織也可以考慮採用企業內部的 SSL 憑證。此外,倘若是在 Windows 10 安裝 Honolulu 管理工具的話,管理人員若在安裝過程中未額外指定連接埠號,那麼預設情況下將會採用 6516 連接埠號提供 Honolulu 管理介面服務。
採用 Honolulu 管理工具自我簽署的 SSL 憑證時,預設將於「60 天」後該 SSL 憑證便會過期。
圖 6、安裝 Honolulu 管理工具並指定 HTML 5 管理介面連接埠號

安裝完畢後,請在 Honolulu 管理主機上切換至 PowerShell 指令模式,執行「Get-Service ServerManagementGateway | Format-List」指令,可以看到安裝 Honolulu 管理工具後將會在 Windows Server 2016 Server Core 主機上,新增 1 項名稱為「ServerManagementGateway」的系統服務,並且運作狀態為「執行中」(Running)

圖 7、Honolulu 管理工具安裝完畢後自動新增至系統服務

現在,可以開啟支援 HTML 5 的瀏覽器連接至 Honolulu 管理頁面,並且搭配安裝 Honolulu 管理工具過程中指定的連接埠號即可,順利連接 Honolulu 管理頁面後系統將會彈出使用者身分認證視窗,請鍵入 Honolulu 管理主機權限的使用者帳號及密碼即可順利登入。值得注意的是,原則上 Honolulu 管理頁面支援任何 HTML 5 的瀏覽器連接,目前僅測試 Microsoft Edge、Google Chrome 瀏覽器能夠順利連接及使用 Honolulu 管理頁面,其它支援 HTML 5 技術的瀏覽器則尚未進行完整測試。

採用不支援 HTML 5 技術的瀏覽器連接 Honolulu 管理頁面,例如,IE(Internet Explorer)瀏覽器嘗試連接 Honolulu 管理頁面時,將會出現 Project Honolulu 不支援此瀏覽器的錯誤訊息。

圖 8、使用不支援 HTML 5 技術的瀏覽器將無法使用 Honolulu 管理工具



管理單台 Windows Server 主機

Honolulu 管理工具不僅能夠管理 Windows Server 主機,即便是 Hyper-V Server 免費虛擬化平台也能夠被 Honolulu 管理工具納管。下列便是 Honolulu 管理工具,支援管理的 Windows Server 作業系統版本:

  • Windows Server 2016 標準版及資料中心版。
  • Windows Server 2012 / 2012 R2 標準版及資料中心版。
  • Microsoft Hyper-V Server 2016 免費虛擬化平台版本。
  • Microsoft Hyper-V Server 2012 / 2012 R2 免費虛擬化平台版本。

開啟 Microsoft Edge 或 Google Chrome 瀏覽器連接 Honolulu 管理頁面,順利通過使用者身份驗證程序登入 Honolulu 管理頁面後,首先 Honolulu 管理頁面會顯示導覽資訊,管理人員可以按下 Next 查看導覽資訊,或按下 Skip Tour 略過導覽資訊。

圖 9、通過使用者身份驗證程序登入 Honolulu 管理頁面

順利登入 Honolulu 管理頁面後,預設僅會看到 Honolulu 管理主機的主機名稱、運作狀態、登入的管理者帳號……等資訊。
目前,Honolulu 管理工具仍處於技術預覽階段,在 Honolulu 管理頁面「語系」(Language)的部分,現階段僅支援「英文」(English)
圖 10、查看 Honolulu 管理主機系統資訊

在 Honolulu 管理工具主要頁面中,請按下 All Connections 區塊下的「+Add」圖示,系統便會在 Honolulu 管理頁面中顯示 Add Connections 視窗,你可以看到共有 3 種連接選項分別是「Server、Failover Cluster、Hyper-Converged Cluster」

請選擇「Add Server Connection」選項,在 Add Server 鍵入希望納管的 Windows Server 主機名稱,在本文實作環境中鍵入的主機名稱為「s2d1.weithenn.org」,當 Honolulu 管理主機順利解析到鍵入的主機名稱後,便會顯示「Credentials Needed」資訊提示必須通過使用者身分驗證機制,請在下方鍵入具備 Windows Server 主機管理權限的使用者帳號及密碼,然後按下 Submit 鈕以便納管遠端 Windows Server 主機。
倘若,遠端 Windows Server 主機為工作群組或非網域主機時,那麼 Honolulu 管理主機必須組態設定 TrustedHosts 機制後,才能夠順利納管遠端 Windows Server 主機。
圖 11、透過 Honolulu 管理工具納管遠端 Windows Server 主機

此時,在 Honolulu 管理頁面納管的遠端 Windows Server 主機項目運作狀態欄位,將會進入「Waiting to Connect」狀態,當鍵入的使用者帳號及密碼通過遠端納管主機的身分驗證程序後,運作狀態欄位便會轉變為「Online」。此時,Honolulu 管理主機便可以開始管理遠端 Windows Server 主機,同時因為管理的是「單台」Windows Server 主機,所以在 Honolulu 管理頁面中上方解決方案列將會停留在「Server Manager」項目。

圖 12、透過 Honolulu 管理工具納管遠端 Windows Server 主機



管理容錯移轉叢集

Honolulu 管理工具,除了能夠管理「單台」Windows Server 主機之外,也能夠管理「容錯移轉叢集」(Failover Cluster)運作環境,並且將會連同所有叢集節點主機一併管控。

請在 Honolulu 管理工具主要頁面中,按下 All Connections 區塊下的「+Add」圖示,然後選擇「Add Failover Cluster Connection」選項,在 Add Cluster 欄位鍵入希望納管的容錯移轉叢集名稱,在本文實作環境中鍵入的容錯移轉叢集名稱為「S2D-Cluster.weithenn.org」,當 Honolulu 管理主機順利解析到鍵入的容錯移轉叢集名稱後,由於先前已經通過使用者身分驗證程序,並勾選後續所有連線階段都採用相同具備管理權限的使用者帳號及密碼,所以便直接通過使用者身分驗證程序。

預設情況下,Honolulu 管理工具會將納管的容錯移轉叢集中,所有容錯移轉叢集成員主機也一併加入至納管的主機清單中,請按下 Submit 鈕確認納管容錯移轉叢集及所有成員主機。

圖 13、透過 Honolulu 管理工具納管容錯移轉叢集及所有成員主機

同樣的,在 Honolulu 管理頁面納管的容錯移轉叢集及所有成員主機項目運作狀態欄位,將會進入「Waiting to Connect」狀態,當使用者帳號及密碼通過遠端納管容錯移轉叢集及所有成員主機的身分驗證程序後,運作狀態欄位便會轉變為「Online」。此時,Honolulu 管理主機便可以開始管理容錯移轉叢集及所有成員主機,同時因為管理的是「容錯移轉叢集」,所以在 Honolulu 管理頁面中上方解決方案列將會停留在「Failover Cluster Manager」項目。

順利納管容錯移轉叢集後,管理人員應該已經發現在 Tools 工具項目相較於剛才管理「單台」Windows Server 主機較少,你可以點選「Virtual Machines > Inventory」項目後,便可以直接查看在容錯移轉叢集當中,所有 VM 虛擬主機的工作負載情況,例如,運作狀態、運作在哪台容錯移轉叢集成員主機上、是否已經具備容錯移轉叢集高可用性角色、CPU 工作負載、記憶體工作負載……等資訊。

圖 14、透過 Honolulu 管理工具查看容錯移轉叢集中所有 VM 虛擬主機工作負載情況



管理 HCI 超融合基礎架構

在新一代 Windows Server 2016 雲端作業系統當中,支援將 Hyper-V 虛擬化技術及 S2D(Storage Spaces Direct)軟體定義儲存技術整合,把「運算」及「儲存」資源同時整合,也就是目前新興熱門的「超融合基礎架構」(Hyper-Converged Infrastructure,HCI)應用方式。Honolulu 管理工具,除了能夠管理單台 Windows Server 主機及容錯移轉叢集之外,也支援管理 HCI 超融合基礎架構。
Honolulu 管理工具,僅支援由 Windows Server 2016 RS3 及後續版本,所建構的 HCI 超融合基礎架構。
請在 Honolulu 管理工具主要頁面中,按下 All Connections 區塊下的「+Add」圖示,然後選擇「Add Hyper-Converged Cluster Connection」選項,在 Add a Hyper-Converged Cluster 欄位鍵入希望納管的 HCI 超融合基礎架構叢集名稱,在本文實作環境中鍵入的容錯移轉叢集名稱為「S2D-Cluster.weithenn.org」,當 Honolulu 管理主機順利解析到鍵入的 HCI 超融合基礎架構叢集名稱後,由於先前已經通過使用者身分驗證程序,並勾選後續所有連線階段都採用相同具備管理權限的使用者帳號及密碼,所以便直接通過使用者身分驗證程序。

同樣的,Honolulu 管理工具會將納管的 HCI 超融合基礎架構叢集中,所有叢集成員主機也一併加入至納管的主機清單中,請按下 Add 鈕確認納管 HCI 超融合基礎架構叢集及所有成員主機。

圖 15、透過 Honolulu 管理工具納管 HCI 超融合基礎架構叢集及所有成員主機

在 Honolulu 管理頁面納管的 HCI 超融合基礎架構叢集及所有成員主機項目運作狀態欄位,將會進入「Waiting to Connect」狀態,當使用者帳號及密碼通過遠端納管 HCI 超融合基礎架構叢集及所有成員主機的身分驗證程序後,運作狀態欄位便會轉變為「Online」。此時,Honolulu 管理主機便可以開始管理 HCI 超融合基礎架構叢集及所有成員主機,同時因為管理的是「HCI 超融合基礎架構」,所以在 Honolulu 管理頁面中上方解決方案列將會停留在「Hyper-Converged Cluster Manager」項目。

但是,在管理 HCI 超融合基礎架構頁面中,管理人員將會發現 Honolulu 管理頁面顯示「The target cluster must use Windows Server,Semi-Annual Channel,at least for now」訊息。主要原因在於,現階段的 Honolulu 管理工具只能管理「Windows Server 2016 RS3 及後續版本的 HCI 超融合基礎架構,而本文實作環境中的 HCI 超融合基礎架構採用 Windows Server 2016(version 1607,所以便出現無法顯示工作負載的資訊。
Windows Server 2016(version 1709版本中,並不支援建構及啟用 S2D(Storage Spaces Direct)特色功能,預計在下一代版本 Windows Server 2016(version 1803版本中,便會重新支援建構及啟用 S2D HCI 超融合基礎架構特色功能。詳細資訊,請參考 Microsoft Docs - Release Notes - Important Issues in Windows Server,version 1709
圖 16、透過 Honolulu 管理工具查看 HCI 超融合基礎架構





結語

透過本文的說明及實作演練,相信讀者已經完全了解 Project Honolulu 運作元件和佈署架構,以及如何建置 Honolulu 管理主機和運作環境,最後透過 Honolulu 管理主機輕鬆管理單台 Windows Server 主機,或是容錯移轉叢集和成員主機。

前言

MAS(Microsoft Azure Stack),是微軟專為新世代混合雲運作架構所設計的雲端平台,並且微軟在 DEVintersection 2017 Orlando大會上,由 PowerShell 之父 Jeffrey Snover 介紹 MAS 混合雲平台,在經過 2 個月之後微軟於 2017 年 7 月正式發佈 MAS 混合雲平台。





那麼,接下來站長將不定期針對 Azure Stack Development Kit 深入剖析各項特色功能:

【簡介】






【佈署】




【基本概念】




【ASDK - IaaS】




【官方資源】


前言

本文為整理 Microsoft Ignite 2017 大會當中,有關 Azure Stack 的議程影片。






Microsoft Ignite 2017 - Azure Stack









Azure Stack Development Kit 攻略系列文章


前言

在前一篇 實戰 Azure Stack Development Kit on Azure 文章中,我們已經順利在 Azure 公有雲環境中建立 ASDK 混合雲平台。然而,當我們測試完畢想要打掉環境時,卻會發現當時所建立的 Azure AD 網域 (weithennmas.onmicrosoft.com) 無法刪除? 本文,便說明如何刪除。





無法刪除 Azure AD 網域 (weithennmas.onmicrosoft.com)?

當我們測試完畢想要打掉環境時,卻會發現當時所建立的 Azure AD 網域 (weithennmas.onmicrosoft.com) 無法刪除?



查看後,會發現共有 18 個在 ASDK 佈署作業時便會註冊的應用程式,但是進入到每個註冊應用程式的頁面後,都會發現「刪除」鈕是灰色無法刪除?



此時,只要點選「資訊清單」,然後在編輯資訊清單中將「availableToOtherTenants」的值由原本的 true 修改為「false」後按下「儲存」



當資訊清單組態設定儲存完畢後,便會發現「刪除」鈕可點選並刪除由 ASDK 佈署程序所註冊的應用程式。



再次嘗試刪除測試 ASDK 混合雲平台的 Azure AD 網域 (weithennmas.onmicrosoft.com),便可以發現順利通過檢查並執行刪除 Azure AD 網域的動作。







Azure Stack Development Kit 攻略系列文章


前言

MAS(Microsoft Azure Stack),是微軟專為新世代混合雲運作架構所設計的雲端平台。下列為 Azure Stack Vision 影片簡介:



微軟在 DEVintersection 2017 Orlando大會上,由 PowerShell 之父 Jeffrey Snover 介紹 MAS 混合雲平台,在經過 2 個月之後微軟於 2017 年 7 月正式發佈 MAS 混合雲平台:


目前,企業及組織要佈署Azure Stack混合雲平台時,倘若是用於「正式營運環境」的話,建議採用 Azure Stack Integrated Systems 解決方案。簡單來說,用於正式營運環境的 Azure Stack 運作架構,其最小規模的運作架構設計原則為「1、1、4 ~ 12」,分別是「1 Region」、「1 Scale Unit」、「4 ~ 12 Nodes」


倘若是用於「研發測試環境」的話,建議採用 ASDK(Azure Stack Development Kit)解決方案。簡單來說,ASDK 解決方案會將 Azure Stack 所有功能、元件、角色以及運作環境,都部署在「1 台」實體伺服器當中進行運作,所以適合企業及組織在評估初期試用 Azure Stack 混合雲平台,以及導入後期用於研發測試環境中。






Microsoft Azure Stack Development Kit 運作架構及硬體需求

原則上,只要採用通過 Windows Server 2012 R2 硬體認證的伺服器即可,詳請參考 Azure Stack Development Kit deployment prerequisites | Microsoft Docs

開始實戰佈署 ASDK(Azure Stack Development Kit)混合雲平台吧 ! 本文採用 ASDK 佈署方式進行實作,也就是只要 1 台實體伺服器便能佈署 Azure Stack 混合雲平台並且實作所有功能。下列為  ASDK 運作架構,詳請參考 Microsoft Azure Stack Development Kit architecture | Microsoft Docs,並在佈署前用 TechNet Deployment Checker for Azure Stack Development Kit 工具檢查一下。

圖、Azure Stack Development Kit 運作架構示意圖





建立 AAD(Azure Active Directory) 環境

目前,在佈署 Azure Stack 混合雲平台時,必須搭配 AAD(Azure Active Directory)ADFS(Active Directory Federation Services)身份驗證機制才行。

在本文實戰環境中,採用 AAD(Azure Active Directory)身份驗證機制,建立的網域名稱為「weithennmas.onmicrosoft.com」,並建立網域使用者帳號「mas-admin」後,指派目錄角色為「全域管理員」以便具備管理者權限。

圖、建立 weithennmas.onmicrosoft.com 的 Azure AD 網域

圖、新增 weithennmas.onmicrosoft.com 網域管理帳號





Azure Portal 建立 Windows Server 2016 DataCenter VM

由於,手邊並沒有一台至少 16 Cores / 128 GB 記憶體的硬體伺服器讓我安裝及測試 ASDK,所以就把腦筋動到 Azure 環境建立了 😈。簡單來說,採用支援 Nested Virtualization in AzureDv3 或 Ev3 規模的 VM 虛擬主機,就可以完成本文的實作環境了。
【免責聲明】請注意,本文只是為了測試上方便的實作筆記。此實作方式並不被任何微軟官方所支援。

圖、Nested Virtualization in Azure

首先,登入 Azure Portal 建立 Windows Server 2016 DataCenter VM,主要是下列設定:
  • VM Name: MAS-Host
  • Size: 標準 E16s v3

圖、新增 E16s v3 系列 VM 虛擬主機

並且,額外新增「256 GB、1 TB」的資料磁碟,以便屆時建立的巢狀式 VM 虛擬主機,能夠符合 ASDK 混合雲平台對於磁碟空間的要求。MAS-Host 佈署完畢之後,新增給屆時 MAS-VM (安裝 ASDK 的 Nested VM) 需要的硬碟 (參考 ASDK 硬體需求):








MAS-Host 基礎設定

登入 MAS-Host 之後,將剛才新增給稍後用於 MAS-VM 的硬碟初始化及格式化採用 NTFS、256GB (M:) /  1TB (N:)
  • 256GB (M:) 稍後 MAS-VM 用來放 OS Diks CloudBuilder.vhdx
  • 1TB (N:) 稍後 MAS-VM 用來放 Data Disk 250GB *4


接著進行下列基礎設定:
  • Computer Name: MAS-Host
  • TimeZone: UTC + 8

安裝 Hyper-V Role
Add-WindowsFeature Hyper-V -IncludeManagementTools -Restart

安裝完 Hyper-V Role 重新啟動後,在 MAS-Host (Azure VM) 中建立 NAT Switch,以便屆時 MAS-VM (Azure VM 的 Nested VM) 能夠出 Internet (因為 MAS-Host 的上層是 Azure 無法用 MAC Address Spoofing 來處理,詳請參考 133 期 - 實作 Hyper-V 巢狀虛擬化測試研發效率大提升)。
New-VMSwitch -Name "MAS-NATSwitch" -SwitchType Internal
New-NetNat -Name "MAS-VMsNAT" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"
Get-NetAdapter "vEthernet (MAS-NATSwitch)" | New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24








下載 Azure Stack Development Kit

透過 Azure Stack Development Kit Downloaders 開始下載 (放到暫存的 D: Azure Temp Volume 即可)。


執行 AzureStackDevelopmentKit.exe 即可解開出 CloudBuilder.vhdx (大約 21.6 GB),倘若想保留 CloudBuilder.vhdx 記得複製到 C:\ 不然 Azure VM 關機/重新啟動 D: 就清空了 😆。







在 MAS-Host (Azure VM) 中建立 MAS-VM (Nested VM)

待 MAS-Host (Azure VM) 基礎設定及環境準備好之後,便可以準備建立 MAS-VM (Nested VM),以下是 MAS-VM 的組態設定 Generation 2, 14 vCPU, 112640 MB (110GB) vRAM Static, MAS-NATSwitch

MAS-VM OS Disk: M:\CloudBuilder.vhdx,並且擴充為 240 GB,因為使用 CloudBuilder.vhdx  開機後預設 C: 為 120 GB, 但 ASDK 硬體需求 OS 需要 200 GB 以上,並記得將 CloudBuilder.vhdx 調整為開機磁碟。


MAS-VM Data Disk: N:\Data01 ~ 04.vhdx (Dynamic, 每個 250 GB)


MAS-VM 啟用 MAC address spoofing (因為是 Azure VM > Nested VM 的架構,這樣屆時長出來的 AzS-BGPNAT01 虛擬主機就可以直接對外),現在 MAS-Host 是 MAS-VM 的上層,所以啟用 MAC Address Spoofing 就可以讓 MAS-VM 長出來的 Nested VM (AzS-BGPNAT01) 出 Internet。詳請參考 133 期 - 實作 Hyper-V 巢狀虛擬化測試研發效率大提升)。這個部分一定要處理好,一開始實作時就是這邊沒處好,屆時 MAS-VM 在安裝 ASDK 時就會一直錯誤或 BSOD


Disable MAS-VM 的 Time Synchronization


假設硬碟空間不太足夠的話,請把 MAS-VM 關機選項調整為 Save -> Shutdown,這樣 MAS-Host Hyper-V 才不會把 VM 儲存成 .bin (Memory 大小) 然後塞爆硬碟。


最後,為 MAS-VM 啟用 Nested VM 機制。
Set-VMProcessor -VMName MAS-VM -ExposeVirtualizationExtensions $true
Get-VMProcessor -VMName MAS-VM | fl ExposeVirtualizationExtensions







MAS-VM 基礎設定

完成 MAS-VM 的 Nested VM 功能啟用後便可以啟動,預設跑完 Sysprep 然後組態設定下列項目:

  • IE Enhanced Security ConfigurationOff (不然等一下要打 AAD 帳號會有麻煩,稍後連 ASDK Admin/User Portal 也麻煩)
  • TimeZoneUTC + 8
  • Power OptionsHigh Performance
  • C: 記得 Extend 成剛才擴充後的 240GB,另外那 4 顆 250GB 不要動它們
  • Computer NameMAS-VM  (不可以叫 AzureStack 否則安裝會出錯)
  • IP Address10.10.75.241  (使用剛才 MAS-NATSwitch 的網段 10.10.75.0/24)
  • Subnet mask255.255.255.0
  • Default Gateway10.10.75.1  (使用剛才 MAS-NATSwitch 指定的 Gateway)
  • Prefered DNS server: 8.8.8.8   (時會被取代為 192.168.200.224 (AzS-DC01)
  • Firewall:Disabled
  • 確認可 ping 8.8.8.8 (出 Internet)






MAS-VM 佈署 ASDK

佈署前看一下 ASDK Release Notes 以免踩到雷,例如,ASDK Build 20180103.2 在佈署時要指定 Time Server (IP Address) 才行。環境都了解後,準備執行下列 PowerShell 開始佈署 ASDK:

  • ASDK 佈署程序會把過程寫入到 C:\CloudDeployment\Logs
  • 指定屆時 BGP VM 使用 10.10.75.240 (因為 MAS 架構中都透過 BGP VM 對外存取)
  • 記得是要跑 InstallAzureStackPOC.ps1 才會跑 DeploySingleNode.ps1, 若是跑 InstallAzureStack.ps1 就變成跑 DeployMultiNode.ps1
  • 開始佈署前,解析 tw.pool.ntp.org 的 NTP Server IP 位址,這次實作為 61.216.153.105。


執行下列 PowerShell 開始 ASDK 安裝程序,首先會請你指定 AdminPassword 為屆時網域管理者密碼,例如,網域管理者帳號 AzureStack.local\AzureStackAdmin
cd C:\CloudDeployment\Setup
.\InstallAzureStackPOC.ps1 -InfraAzureDirectoryTenantName weithennmas.onmicrosoft.com -NATIPv4Subnet 10.10.75.0/24 -NATIPv4Address 10.10.75.240 -NATIPv4DefaultGateway 10.10.75.1 -TimeServer 61.216.153.105 -Verbose



系統會自動測試,剛才所設定的 NATIPv4Address (10.10.75.240) 是否真的沒在使用。


詢問 AAD 的管理帳密時,預設情況下稍後的 Phase 0 - Step PhysicalMachineAndInitialConfiguration.12,會檢查安裝 ASDK 的主機是否為 Virtual Machine 若是則安裝作業停止。因為剛才的安裝程序中,已經將 Microsoft.AzureStack.Solution.Deploy.CloudDeployment.1.0.626.22.nupkg 解開,所以請修改 C:\CloudDeployment\Roles\PhysicalMachines\Tests\BareMetal.Tests.ps1 內容,讓安裝程序允許 VM 也能佈署,請將 if (-not $isVirtualizedDeployment) 修改成 ​if ($isVirtualizedDeployment) 3 筆要取代 (預設若偵測為 VM 則無法繼續安裝)。


完成修改後,再鍵入 AAD 的管理帳密。


Step PhysicalMachineAndInitialConfiguration.12 - Validate Physical Machines,剛才若未修改 BareMetal.Tests.ps1 內容,讓安裝程序允許 VM 也能裝的話這裡就會錯誤然後安裝停止。


理論上經過 5 ~ 6 小時之後,完成 Step 302 並顯示 COMPLETE: Action 'Deployment' 訊息就佈署完畢了。






Azure Stack Administration Portal 

完成 ASDK 佈署作業後,連結 https://adminportal.local.azurestack.external 網址即可瀏覽 Azure Stack Administration Portal






Azure Stack User Portal 

完成 ASDK 佈署作業後,連結 https://portal.local.azurestack.external 網址即可瀏覽 Azure Stack User Portal






參考資源






Azure Stack Development Kit 攻略系列文章