前言

昨天參加 Kubernetes in Azure 活動,通常在體驗 Azure 公有雲的活動中會拿到 Azure Pass 以便快速體驗 Azure 公有雲相關功能特色。但有些地方需要注意,否則在實作的過程中很容易遇到問題,以下就記錄一下昨天遇到然後當場解掉的問題吧 💪





申請 Microsoft 帳號

建議為 Azure Pass 申請新的 Microsoft 帳號,後續測試完畢或錢燒完或時間到 (一般來說 Azure Pass 會提供 USD $1001 個月試用期),也可以直接把這個 Microsoft 帳號刪除。

請連結至 https://signup.live.com/ 進行申請 Microsoft 帳號的動作:

圖、申請 Microsoft 帳號





透過 Azure Pass 啟用 Azure 訂閱帳戶

簡單來說,在你申請好 Microsoft 帳號之後,主辦單位會給你「Azure Pass Promo Code」此時,便可以連結至  Microsoft Azure Pass 網站進行啟用及開通 Azure 訂閱帳戶的動作。值得注意的是,應該了解及避免下列狀況:

  • 使用過 Azure Free Free Account 的 Microsoft 帳號無法使用 Azure Pass。
  • 曾經使用過 Azure Pass 的 Microsoft 帳號無法再次開通。
  • 避免使用 MSDN 訂閱帳戶來開通 Azure Pass。
  • Azure Pass 會有建立 5 台 VM 虛擬主機的限制。


有關透過 Azure Pass 啟用 Azure 訂閱帳戶的動作,官方已經有詳細說明就不重新造輪子了:
圖、透過 Azure Pass 啟用 Azure 訂閱帳戶





Azure CLI 指令 az acr login / create / repository 有問題?

在嘗試執行 Azure CLI 相關指令時 (例如,az acr login / create / repository) 都會有一堆錯誤訊息,其中關鍵錯誤訊息是「'bool' object has no attribute 'rstrip'」,根據錯誤訊息找到這篇討論 az acr login error: AttributeError: 'bool' object has no attribute 'rstrip' · Issue #5303 · Azure/azure-cli

簡單來說,剛好採用的是有問題的 Azure CLI 2.0.24 版本而導致的,只要下載最新的 Azure CLI 2.0.25 版本即可解決。

圖、最新 Azure CLI 2.0.25 版本可順利執行 az acr repository 指令





Azure Pass 訂閱帳戶無法使用所有的 Azure 資料中心?

在昨天的實作過程中,當透過 Azure CLI 指令嘗試建立 Kubernetes 叢集時,卻出現下列錯誤訊息,表示無法建立 Kubernetes Agent VM?
C:\> az acs create --orchestrator-type kubernetes --resource-group RG-US-West --name k8scluster --generate-ssh-keys --agent-count 1
Deployment failed. Correlation ID: e415a0f4-f9de-4882-8ed0-d60e46cf87a7. {
  "error": {
    "code": "BadRequest",
    "message": "The VM Size of Master, Agent is not allowed in your subscription in location 'westus'. Master VM Size 'Standard_D2_v2' is available in locations: eastus, westeurope, southeastasia. Agent VM Size 'Standard_D2_v2' is available in locations: eastus, westeurope, southeastasia."
  }
}


從上述訊息很容易得知,你指定的 Azure 資料中心並不支援建立 Kubernetes Agent VM,請你改為指定採用 eastus, westeurope, southeastasia 這 3 個資料中心即可。

圖、Azure Pass 訂閱帳戶此例僅適合建立指定的 3 個 Azure 資料中心





Azure Pass 訂閱帳戶無法建立 Kubernetes 叢集?

再調整為允許建立的 Azure 資料中心後,再次透過 Azure CLI 指令嘗試建立 Kubernetes 叢集時,又是出現一大堆的錯誤訊息 (但忘了抓畫面 😝),根據錯誤訊息找到這篇討論 az acs create fails on provisioning microsoft.network · Issue #1309 · Azure/azure-cli

簡單來說,因為使用的 Azure Pass 訂閱帳戶「沒有」透過 ARM Portal 建立過 VM 或其它資源,導致相關資源 (Network, Storage, Compute) 都還沒有註冊所以發生錯誤。你可以嘗試透過 ARM Portal 建立 1 台 VM 虛擬主機後再刪除,或者是執行下列 Azure CLI 指令註冊相關資源後,便應該可以順利建立 Kubernetes 叢集:
C:\>az provider register --namespace Microsoft.Network
Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Network'

C:\>az provider register --namespace Microsoft.Compute
Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Compute'

C:\>az provider register --namespace Microsoft.Storage
Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Storage'


圖、註冊相關資源後,即可順利建立 Kubernetes 叢集

圖、註冊相關資源後,即可順利建立 Kubernetes 叢集





關閉測試用途 Microsoft 帳戶

當測試完畢或 Azure Pass 額度用完 (錢燒完) 或試用時間到期 (一般來說 Azure Pass 會提供 USD $100 及 1 個月試用期),便可以直接把這個測試用途的 Microsoft 帳號刪除

圖、關閉測試用途 Microsoft 帳戶





其它參考資源


網管人雜誌

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





文章目錄

前言
vSAN 6.6.1 增強功能
實戰 vSAN 2 Node 叢集架構
          vSAN ESXi 6.5 硬體需求
          建立資料中心及叢集
          建立 vDS 分散式交換器
          叢集啟用 vSAN 軟體定義儲存機制
          佈署 Witness 見證機制
          高可用性測試
結語





前言

在 VMware 官方打造 SDDC 軟體定義資料中心的願景中,負責 SDS 軟體定義儲存解決方案的角色便是 VMware vSAN(Virtual SAN)。簡單來說,企業及組織只要透過 VMware vSAN 軟體定義儲存技術,便可以將多台安裝 ESXi 虛擬化平台 x86 實體伺服器中,所有「本機硬碟」(LocalHardDisk)儲存空間匯整後(例如,NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等),建構出高可用性高效能的共享儲存資源集區。

在 VMworld 2017 大會上,負責 VMware vSAN 解決方案的 Duncan Epping 技術長,所主講的 Top 10 things to know about vSAN 議程中,開宗明義便提到 VMware vSAN 為「Object-Based Storage」(如圖 1 所示),並且每個「物件」(Object)都會包含多個「元件」(Component),同時採用「儲存原則」(Storage Policy)來管理分散的儲存資料。

此外,由 VMware vSAN 所建構的共享儲存資源集區中,還能夠直接運作 VM 虛擬主機及容器等工作負載,因此企業及組織在建構 VMware vSAN 軟體定義儲存環境後,便能同時解決建置「運算 / 儲存」2 大資源的難題,這也是目前非常熱門的「超融合式架構」(Hyper-Converged Infrastructure,HCI)應用情境。

圖 1、VMware vSAN Object-Based Storage 運作示意圖





vSAN 6.6.1 增強功能

在 2017 年 4 月時,VMware 官方正式推出最新第 6 代 VMware vSAN 6.6 並且新增 23 項特色功能,緊接著在 VMworld 2017 舉辦前夕於 2017 年 7 月推出 VMware vSAN 6.6.1 增強版本,同時在此增強版本中再新增 3 項特色功能:

  • 整合 VMware Update Manager: 在過去的 vSAN 版本當中,管理人員倘若需要針對 vSAN 叢集進行版本升級作業時,除了必須確保 vSAN 叢集整體升級程序,以及確認 vSAN 硬體相容性(例如,SAS、SATA、NVMe…… 等)之外,執行版本升級作業時還必須要管理人員手動處理才行。現在,Update Manager 可以針對 vSAN 運作環境提出建議,它可以掃描 vSAN 叢集和 vSAN 節點主機之後,建議相關安全性更新、修補程式、擴充功能 …… 等,並且會驗證 vSAN 節點主機是否符合及支援 vSAN HCL 規範。值得注意的是,vSAN 運作環境必須要能連接至網際網路,Update Manager 才能順利產生各項建議,倘若 vSAN 叢集是透過 Proxy 代理伺服器連接至網際網路時,那麼 vSAN 運作環境則可以產生修補程式及升級建議,但是將無法進行主要版本升級作業。
  • 運作效能診斷: 針對 vSAN 叢集及 vSAN 節點主機進行運作效能基準線測試,例如,最大吞吐量、最小延遲時間、時間範圍……等,系統將會檢測出運作效能是否有任何問題,並且提出修復運作效能問題的操作步驟,同時提供運作效能圖表以便管理人員能夠深入了解效能表現情況(如圖 2 所示)。此外,管理人員還可以透過 HCI Bench 這個 API Level 的效能診斷機制,進一步查詢效能診斷的詳細資訊。值得注意的是,必須加入 CEIP 客戶體驗改善計畫,並且啟用 vSAN Performance Service 機制之後才能使用此特色功能。
  • 儲存設備可維護性: 過去的 vSphere 運作環境中,當採用 RAID 控制器的 ESXi 主機硬碟發生問題時,便能透過驅動損壞硬碟 LED 燈亮的方式快速找出故障損壞硬碟。但是,驅動損壞硬碟 LED 燈亮的方式在過去的 vSAN 運作環境中,因為「不」支援 HBA 或 Pass-Throuth 控制器而無法順利使用。現在,驅動損壞硬碟 LED 燈亮的方式已經支援 HBA 或 Pass-Throuth 控制器,所以當 vSAN節點主機硬碟發生問題時管理人員便能快速找出故障損壞硬碟。舉例來說,在 HPE DL G9 / ML G9 系列的伺服器便已經正式支援此功能。

圖 2、vSAN效能診斷示意圖





實戰 vSAN 2 Node 叢集架構

事實上,在第 3 代 vSAN 6.1 版本的運作環境中,便已經支援「2 Node」的 vSAN 節點主機建構 vSAN 叢集的運作環境,這種小型的 vSAN 軟體定義儲存運作架構,非常適合企業及組織中分公司或小型運作環境時使用。

雖然,vSAN 6.1 支援 2 台 vSAN 節點主機的叢集運作架構,但是仍至少需要配置「1 台」昂貴的 10 Gbps 網路交換器才行,然而卻僅使用到該台 10 Gbps 網路交換器 2 ~ 4 個連接埠而已,倘若考慮避免發生 SPOF 單點失敗情況時,則需要配置「2 台」10 Gbps 網路交換器才行,並且每台 10 Gbps 網路交換器仍只會用到 1 ~ 2 個連接埠而已,這對於建置分公司或小型 vSAN 運作規模的整體 IT 預算來說無疑加重負擔。

第 5 代 vSAN 6.5 版本開始,正式支援在 2 Node vSAN 叢集運作架構中,2 台 vSAN 節點主機可以直接透過「交叉式纜線」(Crossover Cables)的方式互相連接(如圖 3 所示),無須像過往舊版 2 Node vSAN 運作環境中,必須透過 10 Gbps 網路交換器才能進行 vSAN 節點主機的資料交換作業。

因此,當企業及組織在建置分公司或小型 vSAN 運作環境時,無須再被迫採購昂貴的 10 Gbps 網路交換器,所以能有效降低分公司或小型 vSAN 運作規模的整體 IT 預算,根據 VMware 官方分析調查的結果顯示此舉可以有效降低約「20 %」的投資成本。

在組態設定部分,根據 VMware 官方的最佳作法建議,當 vSAN 叢集當中的節點主機透過交叉式纜線互相連接之後,在 vSAN 節點主機網路流量規劃的部分,應該要將「vSAN 儲存流量」「vMotion 遷移流量」分開在不同的 10 Gbps 纜線進行傳輸,以避免儲存或遷移流量互相干擾的情況發生,舉例來說,倘若 2 台 vSAN 節點主機正透過 vSAN 儲存流量網路大量同步資料狀態的情況下,此時又剛好執行 vMotion 線上遷移機制大量移動 VM 虛擬主機的話,那麼有可能會增加 10 Gbps 的網路延遲時間及工作負載。

此外,有關 vSAN 節點主機網路流量規劃方面除了將儲存及遷移流量分開之外,也應該要組態設定為互相備援機制以便故障情況發生時,能夠有另 1 個 10 Gbps 纜線進行網路流量的容錯移轉。
VMware 官方建議,當 vSAN 運作架構採用「Hybrid」儲存組態時,在儲存網路流量的部分至少規劃 1 Gbps 網路頻寬,當 vSAN 運作架構採用「All-Flash」儲存組態時,在儲存網路流量的部分必須要規劃 10 Gbps 網路頻寬。

圖 3、2 台 vSAN 節點主機透過交叉式纜線連接後,網路流量規劃的組態配置示意圖

此外,從第 5 代 vSAN 6.5 版本開始,新增「見證網路流量」(Witness Traffic)分離的特色功能,解決在 2 台 vSAN 節點主機之間必須建立及維護靜態路由的組態設定,有效降低 vSAN 叢集運作架構的複雜度,同時在安全性方面也能得到改善,因為 vSAN 儲存網路流量與 WAN 見證網路流量現在能夠完全分離了。

值得注意的是,負責 vSAN 叢集運作架構的見證虛擬設備(vSAN Witness Appliance),「不得」運作在 2 台 vSAN 節點主機之上以避免誤判的情況發生。同時,一般來說 2 台 vSAN 節點主機的小型運作架構,通常是運作在企業及組織的分公司或遠端辦公室當中,所以分公司或遠端辦公室若有透過 WAN 網路與主要資料中心連接時,那麼管理人員可以考慮將見證虛擬設備運作在主要資料中心內,除了節省建置第 3 台 ESXi 主機以便運作見證虛擬設備之外,也能達到將見證虛擬設備運作在主要資料中心內達到統一管理的目的(如圖 4 所示)。

圖 4、支援將 vSAN 見證虛擬設備運作在主要資料中心內的運作架構示意圖



vSAN ESXi 6.5 硬體需求

在建構 vSAN 軟體定義儲存叢集架構時,值得注意的部分主要在於硬體組態配置,舉例來說,倘若管理人員希望在測試環境嘗試建構 vSAN 叢集架構時,那麼 ESXi 主機的記憶體資源至少需要「8 GB」才行。

此外,在建構正式營運環境的 vSAN 叢集架構時,倘若採用 vSAN Ready Node 的話則無須擔心硬體組態配置,若是自行規劃時則必須要注意除了安裝 ESXi Hypervisor 採用傳統的 RAID 之外,其它由 vSAN 軟體定義儲存所管理的儲存裝置,必須要採用 HBA 控制器(Passthrough 或 RAID 0 Mode)機制才行(如圖 5 所示),這是初次建置 vSAN 叢集架構時,管理人員最容易忽略的部分。

圖 5、自行配置 vSAN 節點主機硬體組態參考架構



建立資料中心及叢集

當管理人員安裝好 vCenter Server 及 ESXi 主機後,首先請建立「資料中心」(Datacenter)接著建立「叢集」(Cluster),但是先「不要」針對建立的叢集啟用 vSAN 功能。

值得注意的是,在目前 vCenter Server 的主要管理工具,分別支援 vSphere Web Client(Flash-Based)vSphere HTML Client(HTML5-Based)

雖然,VMware 官方已經宣佈後續版本的操作介面,將採用全新開發且操作更為順利的 vSphere HTML Client,然而即便目前最新的 vSphere 6.5 update1 版本中,vSphere HTML Client 仍僅支援「部分」功能而非全功能組態設定,舉例來說,在建立「叢集」(Cluster)時 vSphere HTML Client 操作介面,便無法啟用 vSAN 特色功能且後續在叢集操作介面中也無法進行管理(如圖 6 所示)。
在 2017 年 8 月 25 日時,VMware 在官方部落格中正式宣佈下一版 vSphere 當中,將會以 vSphere HTML Client 為主要管理工具,同時在下一版 vSphere 當中將不會再有 vSphere Web Client 管理工具。詳細資訊請參考 VMware vSphere Blog - Goodbye,vSphere Web Client!

圖 6、建立 vSAN 用途的資料中心及叢集

順利建立 vSAN 用途的資料中心及叢集之後,請將完成硬體配置的 2 台 ESXi 主機加入至叢集當中,順利加入叢集後請先確認 ESXi 主機,是否擁有足夠建立 vSAN 軟體定義儲存的硬體配置。如圖 7 所示,在本文實作環境中 2 台 ESXi 主機,除了安裝 ESXi Hypervisor 的儲存裝置之後,還額外配置「3 個」100 GB 空間大小的 SSD 固態硬碟。

圖 7、每台 vSAN 節點主機皆額外配置 3 個 100 GB 容量的 SSD 固態硬碟



建立 vDS 分散式交換器

在剛才建立 vSAN 用途的叢集時,建議先不要啟用 vSAN 特色功能的主要原因在於,我們尚未組態設定好 vSAN 節點主機的網路組態。同時,在 vSAN 網路環境規劃建議作法當中,針對 vSAN 網路環境建議採用「vDS 分散式網路交換器」(vNetwork Distributed Switch)為佳。

現在,請為 vSAN 節點主機組態設定 vDS 分散式網路交換器,下列分別說明採用 vSphere Web Client 及 vSphere HTML Client 這 2 項管理工具時,如何建立 vDS 分散式網路交換器:

  • vSphere Web Client: 請依序點選【首頁 > 網路功能 > 網路 > Distributed Switch > 新增 Distributed Switch】。
  • vSphere HTML Client: 請依序點選【功能表 > 網路功能 > Datacenter > 動作 > Distributed Switch > 新增 Distributed Switch】。


在彈出的新增 Distributed Switch 視窗中,首先請指定建立的 vDS 分散式網路交換器名稱及位置,在本文實作環境中 vDS 分散式網路交換器名稱為「vSAN-DSwitch」,接著選擇 vDS 分散式網路交換器版本,因為本文實作環境中並沒有新舊版本混合的 ESXi 主機所以選擇採用最新「6.5.0」版本,最後在設定組態頁面中,除了連接埠群組名稱改為「vSAN-DPortGroup」之外其餘採用系統預設值即可(如圖 8 所示)。

圖 8、建立 vDS 分散式網路交換器及連接埠群組

順利新增 vDS 分散式網路交換器及連接埠群組之後,請將 vSAN 節點主機中用於 vSAN 儲存流量的網路卡,加入至剛才所建立的 vDS 分散式網路交換器及連接埠群組當中:

  • vSphere Web Client: 請依序點選【網路功能 > vCenter Server > 網路 > Distributed Switch > 新增和管理主機】。
  • vSphere HTML Client: 請依序點選【網路功能 > vSAN-Dswitch > 網路 > 動作 > 新增和管理主機】。


在彈出的新增和管理主機視窗中,於選取工作頁面中請選擇「新增主機」項目,在選取主機頁面中按下「新增主機」鈕後將 2 台 vSAN 節點主機依序加入,在管理實體介面卡頁面中請將 vSAN 節點主中,配置用於 vSAN 儲存流量傳輸用途的網路卡加入,請點選相關網路卡後點選「指派上行」鈕,將選定的 vSAN 儲存流量傳輸用途網路卡,指派為 vSAN-Dswitch Uplink

在管理 VMkernel 網路介面卡頁面中,請先點選「位於此交換器上」然後按下「新增介面卡」鈕,選擇採用「vSAN-DPortGroup」連接群組,並且勾選「vSAN」項目以便啟用 vSAN 儲存流量,最後指派 vSAN 用途的 VMkernel IP 位址即可(如圖 9 所示)。
此操作步驟若採用新式 vSphere HTML Client 管理工具時,僅能新增管理網路介面卡無法同時新增 VMkernel 網路介面卡。

圖 9、指派 vSAN 儲存流量用途的網路卡並組態設定 VMkernel Port

完成指派 vSAN 儲存流量用途的實體網路卡及 VMkernel Port 之後,請再次確認是否指派完成且正確無誤(如圖 10 所示),以避免稍後為叢集啟用 vSAN 特色功能時發生不可預期的錯誤。

圖 10、再次確認 vSAN 儲存流量用途實體網路卡及 VMkernel Port 指派完成且正確無誤



叢集啟用 vSAN 軟體定義儲存機制

現在,請透過 vSphere Web Client 管理工具,為 vSphere 叢集啟用 vSAN 軟體定義儲存機制,請依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > vSAN > 一般 > 設定】,在彈出的設定 vSAN 視窗中,由於我們尚未組態設定 vSAN Witness 見證機制,所以在容錯網域與延伸叢集的組態設定中請採用「不設定」選項,稍後我們便會組態設定 vSAN Witness 見證機制。
新式 vSphere HTML Client 管理工具,尚未支援為 vSphere 叢集啟用 vSAN 軟體定義儲存機制。
接著,在網路驗證頁面中,由於剛才已經正確指派及組態設定 vSAN 儲存流量網路卡及 VMkernel Port,所以將會順利通過 vSAN 網路驗證機制。如圖 11 所示,在宣告磁碟頁面可以看到我們為 vSAN 節點主機所配置的 3 個 100 GB SSD 固態硬碟,請將 1 個 SSD 固態硬碟宣告為「快取層」(Cache Tier),另外 2 個 SSD 固態硬碟宣告為「容量層」(Capacity Tier)

圖 11、宣告 vSAN 節點主機儲存裝置為快取層及容量層

最後,完成為 vSphere 叢集啟用 vSAN 軟體定義儲存機制,此時系統將會執行更新 vSAN 組態、在 vSAN 叢集中建立磁碟群組、將磁碟新增至 vSAN……等動作。當順利為 vSphere 叢集啟用 vSAN 軟體定義儲存機制後,可以看到在網路模式的部分採用新式「單點傳播」處理 vSAN 儲存流量(如圖 12 所示),而非舊有的「多點傳播」

圖 12、順利為 vSphere 叢集啟用 vSAN 軟體定義儲存機制



佈署 Witness 見證機制

在 2 Node 的 vSAN 叢集架構中,必須要佈署 Witness 見證機制才能確保可用性。管理人員請在 vSphere Web Client 管理工具中,依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > 容錯網域與延伸叢集】選項後,可以看到目前 vSAN 叢集容許「0 個主機故障」(如圖 13 所示),表示 vSAN 叢集尚未具備高可用性。
倘若,vSAN 叢集當中具備「3 台」vSAN 節點主機時,那麼即便沒有佈署 Witness 見證機制,也能容許「1 台」主機發生故障損壞仍能正常運作,簡單來說便是已經具備高可用性。

圖 13、目前 vSAN 叢集尚未具備高可用性

現在,請為 vSAN 叢集佈署 Witness 見證機制,值得注意的是運作見證虛擬設備的 ESXi 主機必須具備 2 項條件,第 1 項條件是該台 ESXi 主機「不能」加入至 vSAN 叢集當中,第 2 項條件則是該台 ESXi 主機「必須」要能接觸得到 vSAN 儲存網路。

完成見證虛擬設備 ESXi 主機的基本組態設定後,請依序點選【動作 > 部署 OVF 範本】進行佈署見證虛擬設備的動作。在本文實作環境中,採用的見證虛擬設備運作規模為「Tiny」,所以 ESXi 主機必須提供 2 vCPU 及 8GB vRAM 虛擬硬碟資源給它,此外見證虛擬設備管理用途的 IP 位址為「10.10.75.33」,接觸 vSAN 儲存網路的 IP 位址則是「192.168.75.33」
採用新式 vSphere HTML Client 管理工具,在佈署見證虛擬設備的過程中並不會組態設定管理者密碼,所以必須佈署完成後組態設定管理者密碼才能順利啟動見證虛擬設備。

佈署及組態設定見證虛擬設備後,請將見證虛擬設備加入 vSphere Datacenter 當中,順利加入後可以發現見證虛擬設備與一般 ESXi 主機的圖示顏色不同(如圖 14 所示)。

圖 14、將見證虛擬設備加入 vSphere Datacenter 當中

現在,請依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > vSAN > 容錯網域與延伸叢集 > 設定】,在彈出的設定 vSAN 延伸叢集視窗中,組態設定慣用容錯網域為「10.10.75.31」vSAN 節點主機,而次要容錯網域為「10.10.75.32」vSAN 節點主機。

接著,在選取見證主機頁面中,選擇我們完成佈署及組態設定的 vSAN 見證虛擬設備「10.10.75.33」,在為見證主機宣告磁碟頁面中採用系統預設值即可。順利為 vSAN 叢集啟用 Witness 見證機制後,可以看到容錯網域由先前容許「0 個主機故障」變更為「1 個容錯網域故障」(如圖 15 所示)。

圖 15、為 2 Node vSAN 叢集架構啟用 Witness 見證機制



高可用性測試

順利建構 2 Node vSAN 節點主機搭配 Witness 見證機制後,現在 vSAN 叢集已經具備高可用性機制,請為 vSAN 叢集「啟用 vSphere HA」高可用性機制,以便其中 1 台 vSAN 節點主機發生故障損壞事件時,其上運作的 VM 虛擬主機能夠自動在另 1 台存活的 vSAN 節點主機上重新啟動。

現在,運作在 vSAN 叢集當中的 VM 虛擬主機,預設情況下儲存物件和元件將會分別存放在 2 台 vSAN 節點主機中(如圖 16 所示)。

圖 16、VM 虛擬主機儲存物件將會分別存放在 2 台 vSAN 節點主機中

即便其中 1 台 vSAN 節點主機,因為安全性更新需要重新啟動,或是伺服器硬體元件發生故障損壞事件(如圖 17 所示),在 vSAN 叢集當中的 VM 虛擬主機仍然能夠正常運作提供服務達到高可用性的目的。

圖 17、其中 1 台 vSAN 節點主機故障損壞 VM 虛擬主機仍能正常運作





結語

透過本文的說明及實作相信讀者已經了解,在最新 vSAN 6.6.1 版本當中新增哪些特色功能,同時本文也進行 2 Node vSAN 叢集搭配 Witness 見證機制的運作架構實戰演練,期望能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。

前言

最近幾天大家關心的話題之一,相信就是 CPU Speculative Execution 漏洞議題,大家紛紛討論此次 CPU 漏洞造成的影響,並且這個漏洞不光影響一般企業或使用者,即便是雲端大廠 AWS, Azure, GCP 也都造成影響。相關資訊請參考下列連結:

Windows ServerWindows Client 的部分,則請參考微軟相關文章:




檢查是否更新完成

如果,你已經更新 BIOS / Firmware 及 Windows OS 相關更新後,該如何快速確認已經更新完畢,以便阻擋 CPU Speculative Execution 漏洞攻擊行為? 微軟已經發佈新的 SpeculationControl 的 PowerShell 模組幫助你檢查,請以「系統管理員」身份執行 PowerShell 後鍵入「Install-Module SpeculationControl」指令即可進行安裝。

圖、安裝 SpeculationControl 的 PowerShell 模組

安裝完畢後,便可以執行「Get-SpeculationControlSettings」指令進行檢查,如下圖所示目前受檢查的主機皆尚未安裝 BIOS / Firmware 及 Windows OS 相關更新。

圖、尚未安裝 BIOS / Firmware 及 Windows OS 相關更新

請安裝硬體的 BIOS / Firmware 相關更新,至於 Windows OS 的部分以 Windows 10 來說便需要安裝 KB4056892 安全性更新。

圖、為 Windows 10 安裝 KB4056892 安全性更新

安裝完畢並重新啟動主機後,再次執行「Get-SpeculationControlSettings」指令進行檢查,如下圖所示可以看到相關防護機制皆已啟動完成。

圖、更新完成並再次檢查後可發現相關防護機制皆已啟動完成

倘若,僅安裝 Windows OS 的相關更新但是硬體的 BIOS / Firmware 未更新的話,那麼執行檢查的結果可能如下圖所示:

圖、硬體 BIOS / Firmware 未更新的檢查結果

網管人雜誌

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





文章目錄

前言
Azure Pack vs Azure Stack
          Azure Stack 管理 Azure Pack
實戰 Azure Pack on Windows Server 2016
          Windows Azure Pack 佈署架構
          佈署 Azure Pack 運作架構
結語





前言

在雲端運算、AI 人工智慧、ML 機器學習……等議題的推波助瀾之下,不管是傳統產業或科技產業的各種產業類別,每家企業或組織當中的商務流程或多或少都會使用到雲端服務業者建立的服務,或者由企業或組織的 IT 團隊在內部資料中心自建私有雲環境。

從 RightScale 最新的雲端運算發展趨勢調查結果顯示,在公有雲(Public Cloud)的部分已經從 2015 年 88 % 上升至 2017 年的 89 %,至於私有雲的部分則是從 2015 年 63 % 上升至 2017 年的 72 %。此外,隨著公有雲及私有雲技術不斷成熟且比例逐漸上升的情況下,連帶也讓企業及組織導入混合雲(Hybrid Cloud)的比例,由 2015 年 58 % 上升至 2017 年的 67 %,最終企業或組織採用雲端運算技術的比例也從 2015 年的 93 % 上升至 2017 年的 95 %(如圖 1 所示)。

圖 1、2017 年企業及組織採用雲端運算技術比例

首先,在「公有雲」的部分,Microsoft Azure 公有雲的入口網站在 2015 年 12 月之前,一直以來都是採用 ASM(Azure Service Management)的管理模式(如圖 2 所示),並且是以「服務」為單位進行分類及運作。
目前,企業及組織仍然可以瀏覽 https://manage.windowsazure.com 網址,結合 Azure 訂閱帳戶登入 Azure ASM Portal 公有雲環境進行管理及佈署,然而除非是新版 ARM Portal 無法提供的服務,否則並不建議仍採用舊有的 ARM Portal 進行管理作業。
圖 2、舊有 Azure 入口網站,採用 ASM(Azure Service Management)管理模式

在「私有雲」的部分,倘若企業及組織希望在內部資料中心內,建立類似 Microsoft Azure 雲端運作基礎架構及環境的話,那麼也可以透過 WAP(Windows Azure Pack),結合 Windows Server 2012 R2 Hyper-V + System Center 2012 R2 自行打造私有雲環境(如圖 3 所示)。

此外,當企業在內部資料中心透過 WAP 整合 Hyper-V 及 System Center,建構內部私有雲環境中也可以整合相關機制,達到建構「混合雲」運作環境的目的,舉例來說,可以在 WAP 中建構 ADFS 同盟服務與 Azure AD 協同運作,達成混合雲運作環境中使用者身分驗證的目的。

圖 3、企業及組織透過 Windows Azure Pack 建立私有雲運作架構

2015 年 12 月之後,在「公有雲」的部分微軟推出新版入口網站並採用 ARM(Azure Resource Manager)管理模式,只要於 Azure ARM Portal 入口網站中(如圖 4 所示),使用 Azure 訂閱帳戶即可登入,並且逐步提供將舊有 Azure ASM 公有雲環境遷移至 ARM 環境的方式。同時,Azure 後續推出的新版雲端服務,也大部分僅在 Azure ARM Portal 入口網站中,才能夠進行佈署及管理作業。
目前,企業及組織只要瀏覽 https://portal.azure.com 網址,結合 Azure 訂閱帳戶即可登入 Azure ARM Portal 公有雲環境進行管理及佈署作業。
圖 4、新版 Azure 入口網站,採用 ARM(Azure Resource Manager)管理模式

在「私有雲 / 混合雲」的部分,微軟為了提供給開發人員一致的程式編寫平台(只要內部編寫一次,上傳至公有雲環境中便可立即使用),並且同樣採用 Azure Resource Manager 管理模式,以便為 IT 管理人員提供一致的管理操作體驗平台。台灣微軟在 2017 年 8 月 30 日,正式宣佈與 Intel、HPE、Cisco、Dell、Lenovo 等業者合作推出 MAS(Microsoft Azure Stack)一體機,讓企業及組織可以在內部資料中心內部署 Azure Stack 服務(如圖 5 所示),也可以跟國內電信業務申請租用 Azure Stack 服務。
微軟在 2016 年 1 月推出 Azure Stack TP1 技術預覽版本,後續約每半年推出 TP2、TP3 技術預覽版本,最終於 2017 年 7 月推出正式版本。
圖 5、企業及組織透過 Microsoft Azure Stack 建立私有雲及混合雲環境





Azure Pack vs Azure Stack

雖然,微軟新一代的私有雲及混合雲平台為 MAS(Microsoft Azure Stack),然而對於中小型企業或組織來說,建置 MAS 私有雲及混合雲平台不管是軟體授權或硬體設備等費用皆所費不貲,並非一般中小型企業或組織所能夠負擔。此外,雖然微軟有提供「Azure Stack Development Kit」方案,讓企業及組織能夠自行下載建置 Azure Stack 在「單台」伺服器當中,但這樣的佈署及應用情境僅限於「研發 / 測試」環境。
佈署 Azure Stack Development Kit 的 x86 硬體伺服器,至少應具備 2 顆 CPU 處理器(16 個實體運算核心)和 128 GB 記憶體空間,及 4 顆至少 250 GB 儲存空間的硬體才能夠順利佈署 Azure Stack Development 運作環境。

那麼,對於中小型企業或組織來說,除了透過 Azure Stack 建立全方位的私有雲及混合雲平台之外,是否還有其它自行建構中小型的私有雲解決方案? 現在,微軟提供一般中小型企業或組織,無須專用硬體設備及其它額外的軟體授權,只要採用第一代的微軟私有雲平台 Azure Pack,並且整合 Windows Server 2016 及 System Center 2016 管理平台,便可以在內部資料中心內建構中小型的私有雲及混合雲解決方案。

事實上,在 Windows Server 2016 及 System Center 2016 正式發佈時,Azure Pack 並不支援與這 2 個產品進行整合,所以當時有種說法是 Azure Pack 私有雲平台,只能運作在 Windows Server 2012 R2 及 System Center 2012 R2 環境。其實,只要採用 Windows Azure Pack UR10 或後續版本,便能夠無縫與 Windows Server 2016 及 System Center 2016 整合(如圖 6 所示),並且使用 Windows Server 2016 新的特色功能,例如,Shielded VMs、SDN v2……等。

圖 6、採用 Windows Server 2016 建置的 Azure Pack 私有雲環境,主要支援可至 2022 年而延伸支援可至 2027 年

簡單來說,企業及組織倘若僅需要建立 IaaS 基礎架構即服務運作架構的話,那麼採用 Windows Azure Pack 建置私有雲平台便非常適合,並且可以使用內部資料中心內原有基礎架構資源進行建置即可,倘若需要全方位的私有雲及混合雲解決方案則應採用 Microsoft Azure Stack(如圖 7 所示)。值得注意的是,採用新一代的 Microsoft Azure Stack 混合雲平台,企業及組織必須採用特定服務供應商的硬體才能順利佈署及運作,而無法直接使用內部資料中心內原有基礎架構資源進行建置。

圖 7、Windows Azure Pack 與 Microsoft Azure Stack 運作架構示意圖

值得注意的是,雖然 Windows Azure Pack 與 Microsoft Azure Stack 這 2 種解決方案,都提供 IaaS 基礎架構即服務的運作架構,但是 Windows Azure Pack 底層是採用 ASM(Azure Service Management)管理模式,而 Microsoft Azure Stack 與現在 Azure 公有雲同樣採用 ARM(Azure Resource Manager)管理模式。

因此,在 Windows Azure Pack 與 Microsoft Azure Stack 提供給不同「租用戶」(Tenant),所需要的各項 IaaS 服務時仍然有些許不同,舉例來說,在新一代的 Microsoft Azure Stack 當中便是透過 Subscription、Offer、Plan、Service 等不同功能(如圖 8 所示),達到提供 IaaS 服務給租用戶的目的:

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

圖 8、Windows Azure Pack 與 Microsoft Azure Stack 提供租用戶 IaaS 服務的運作架構示意圖



Azure Stack 管理 Azure Pack

倘若,企業及組織在早期已經建置底層為 Windows Server 2012 R2,搭配 System Center 2012 R2 所搭建的 Windows Azure Pack 私有雲平台,隨著公司運作規模不斷擴增導入新一代 Microsoft Azure Stack 混合雲平台時,那麼原有的 Windows Azure Pack 私有雲平台,是否就無用武之地只能形成資源孤島?

答案當然是否定的,簡單來說企業及組織的 IT 管理團隊,只要在 Microsoft Azure Stack 混合雲平台中,安裝 Windows Azure Pack Connector 軟體套件後,便可以直接透過 Microsoft Azure Stack 混合雲平台,管理 Windows Azure Pack 的 IaaS 基礎架構即服務,但是 Windows Azure Pack 上運作的 VM 虛擬主機,則仍由原本的 SPF(Service Provider Foundation),以及 SCVMM(System Center Virtual Machine Manager)進行佈署的動作(如圖 9 所示)。
根據微軟官方建議,透過 Windows Azure Pack Connector 管理 Windows Azure Pack 環境,僅限於 Azure Stack Development Kit 所建構的研發測試環境,不建議用於 Microsoft Azure Stack 正式營運環境中。
圖 9、Windows Azure Pack Connector 運作架構示意圖





實戰 Azure Pack on Windows Server 2016

現在,企業及組織只要準備好 Windows Server 2016 及 System Center 2016,便可以著手建置 Windows Azure Pack 運作環境,提供使用者自助式入口網站和各式各樣的雲端服務(如圖 10 所示):

  • 入口網站: 在 Portal 入口網站的部分共有 2 種類型,第 1 種是針對管理人員入口網站(Admin Portal),以便組態設定雲端資源、使用者帳號、租用戶方案、配額、定價。第 2 種則是針對租用戶入口網站(Tenant Portal),以便租用戶使用者可以在自助式入口網站中,進行雲端服務(例如,VM 虛擬主機)的佈署、監控、管理服務。
  • 服務管理 API: 透過 REST API 提供客製化整合案例,例如,自訂入口網站以及租用戶資源計費系統。
  • VM 虛擬主機雲端: 提供 Windows 及 Linux 虛擬主機 IaaS 基礎架構即服務,包括 VM 虛擬主機範本、調整運作規模、VM 虛擬主機的虛擬網路環境 …… 等。
  • 網站雲端: 提供 ASP .NET、PHP、Node.js 等可擴充的 Web 應用程式服務,建構 PaaS 平台即服務的運作環境。
  • 資料庫雲端: 提供 SQL Server 和 MySQL 資料庫執行個體服務,建構 DbaaS 資料庫即服務搭配網站雲端使用。
  • 服務匯流排雲端: 在分散式應用程式之間提供可靠訊息服務。
  • 自動化: 將其他自訂服務整合至運作架構中,包括 Runbook 及執行環境……等。

請注意,Windows Azure Pack Web Sites 雲端服務,僅「支援」底層採用 Windows Server 2012 R2 時才能順利運作,並「不支援」佈署在底層為 Windows Server 2016 的作業系統平台。同時,Windows Azure Pack Web Sites v2 雲端服務,主流支援服務至 2017 年 7 月 11 日,而延伸支援服務至 2022 年 7 月 12 日。
圖 10、Windows Azure Pack 運作架構及特色功能示意圖



Windows Azure Pack 佈署架構

POC 測試驗證架構
在整個 Windows Azure Pack 運作架構當中,可以依照企業或組織的需求及運作規模大小,決定採用的 Windows Azure Pack 佈署架構,舉例來說,倘若企業及組織只是想要快速建構 Windows Azure Pack 運作環境,進行 POC 概念性驗證以便評估是否要正式佈署 Windows Azure Pack 時,便可以採用「Windows Azure Pack 快速佈署架構」(如圖 11 所示),將 Windows Azure Pack 的必要運作元件安裝在「同 1 台」主機上即可。

圖 11、Windows Azure Pack 快速佈署架構示意圖


小型規模運作架構
順利評估 Windows Azure Pack 特色功能滿足企業需求後,倘若只需要佈署小型規模的 Azure Pack 運作架構時,那麼最簡單的佈署方式便是將「相關角色拆分」在不同的主機上運作即可,此時 IT 管理人員可以參考及採用「Windows Azure Pack 基本分散式佈署架構」(如圖 12 所示),以避免不同角色在同 1 台主機上資奪硬體資源,造成屆時使用 Azure Pack 雲端服務時不良的操作體驗。

圖 12、Windows Azure Pack 基本分散式佈署架構示意圖


中型規模運作架構
隨著企業及組織的商業模式不斷擴增,企業內部使用 Windows Azure Pack 自助式入口網站,以及相關雲端服務的使用者人數不斷增加的情況下,只是單純將 Azure Pack 運作角色拆分在不同主機上運作,可能已經無法滿足使用者對於服務快速回應及高可用性的需求。

此時,除了將 Azure Pack 運作角色拆分在不同主機上運作之外,也為不同的運作元件加入「負載平衡」(Load Balance)「容錯移轉叢集」(Failover Cluster)機制,IT 管理人員可以參考及採用「Windows Azure Pack 小型分散式佈署架構」(如圖 13 所示),以便平時可以有多台主機一同分散工作負載,即便某台擔任同個運作角色的主機發生故障損壞事件時,也能由其它存活的主機繼續回應使用者請求的雲端服務,滿足使用者對於 Azure Pack 雲端服務的高可用性需求。

圖 13、Windows Azure Pack 小型分散式佈署架構示意圖


大型規模運作架構
當企業內部使用 Windows Azure Pack 自助式入口網站,以及雲端服務的使用者人數不斷增加,甚至企業以成本利潤中心的概念,提供雲端服務給不同部門別並進行計價的動作。因此,除了服務快速回應及高可用性的需求之外,也必須因應專案數量暴發或大型促銷這種工作負載急增的需求。

此時,除了將 Azure Pack 運作角色拆分在不同主機上運外,以及剛才加入的「負載平衡」(Load Balance)及「容器移轉叢集」(Failover Cluster)機制之外,所有運作角色規模的擴充也必須更容易更即時才能夠因應,IT 管理人員可以參考及採用「Windows Azure Pack 可擴充分散式佈署架構」(如圖 14 所示),以便平時可以有多台主機一同分散工作負載,當專案數量暴發或大型促銷導致工作負載急增時,也能夠快速為每個運作角色擴充運作規模,以便滿足使用者對於雲端服務的快速回應和高可用性需求。

圖 14、Windows Azure Pack 可擴充分散式佈署架構示意圖



佈署 Azure Pack 運作架構

了解 Windows Azure Pack 特色功能及佈署架構後,在開始建立 Azure Pack 運作架構及進行組態設定作業之前,我們先了解在 Azure Pack 運作架構中,需要建置的角色共有 Windows AD 網域環境(DNS / DHCP / Certificate Authority / Service Accounts)、Hyper-V 虛擬化平台、SCVMM 管理平台、Azure Pack Admin Portal、Azure Pack Tenant Portal、SPF……等。

雖然建置 Windows Azure Pack 基礎架構,在相關伺服器角色上並沒有絕對的先後順序,不過在建構基礎架構時卻有相關的工法可供遵循,接下來我們將簡介本文整個 Windows Azure Pack 基礎架構的安裝及設定流程:

1. 建立 Windows AD(Active Directory)網域環境及相關服務帳戶和群組。
2. 安裝及組態設定 Hyper-V 虛擬化平台(Hyper-V、Storage、Failover Cluster)。
3. 安裝及組態設定 SQL Server 資料庫。
4. 安裝及組態設定 SCVMM(System Center Virtual Machine Manager)虛擬化管理平台。
5. 安裝及組態設定 SPF(Service Provider Foundation),以便擔任 VMM 及 WAP 之間溝通的橋樑。
6. 安裝及組態設定 WAP(Windows Azure Pack),以便提供管理人員及租用戶入口網站。


建構 Windows AD 網域環境
在 Windows Azure Pack 的運作架構中,由於有多個運作角色之間必須協同運作,同時在系統管理思維當中應該要針對每個角色建立服務角色。因此,請在建立好 Windows AD 網域環境後,預先建構後續各項運作角色會使用到的服務帳戶,例如,用於 SQL Server 服務帳戶為 SQL-SVC、用於 SFP 服務帳戶為 SPF-SVC、用於 VMM 服務帳戶為 VMM-SVC……等(如圖 15 所示)。

圖 15、建立相關服務帳戶及群組


建構 Hyper-V 虛擬化平台
建構 Hyper-V 虛擬化平台,並且整合容器錯移轉叢集運作機制以便提供高可用性(如圖 16 所示)。屆時,當使用者登入租用戶入口網站後,執行佈署 VM 虛擬主機的動作時,底層 VMM 管理平台便會將 VM 虛擬主機佈署至 Hyper-V 虛擬化平台中。

此外,除了傳統 SAN 儲存資源之外,也可以整合 Windows Server 2016 當中的 S2D(Storage Spaces Direct)軟體定義儲存技術,用來擔任 Hyper-V 虛擬化平台儲存資源。

圖 16、建構高可用性 Hyper-V 虛擬化平台


建構 SQL Server 資料庫
本文實作環境採用 SQL Server 2016 擔任 SCVMM、SPF 資料庫,在正式營運環境中建議 WAP 使用的資料庫,也就是提供租用戶 DBaaS 資料庫即服務的部分,應該要與 SCVMM 及 SPF 使用的基礎架構資料庫分開。

值得注意的是,在安裝 SQL Server 2016 的過程中,於 Feature Selection 頁面中至少要勾選「Database Engine Services」功能項目,在 Server Configuration 頁面中,請將 SQL Server Agent 及 SQL Server Database Engine 項目的帳戶名稱,調整為在 DC 網域控制站當中針對 SQL Server 建立的服務帳戶,並且將啟動類型調整為「Automatic」,至於定序的部分採用預設的「SQL_Latin1_General_CP1_CI_AS」即可(如圖 17 所示)。

圖 17、安裝 SQL Server 2016 資料庫


建構 SCVMM 管理平台
本文實作環境中,採用 System Center 2016 Virtual Machine Manager 擔任虛擬化管理平台,值得注意的是,在安裝 SCVMM 之前必須先安裝「Windows ADK for Windows 10,version 1607」軟體套件,至於安裝選項只要勾選「Deployment Tools」「Windows Preinstallation Environment(Windows PE)」即可(如圖 18 所示)。

圖 18、安裝 System Center 2016 Virtual Machine Manager 虛擬化管理平台

此外,因為 SCVMM 的資料庫並非採用本機 SQL Server Express,所以也必須先安裝 SQL 工具 Native ClientCommand Line Utilities,並且安裝完畢後必須重新啟動 SCVMM 主機,否則稍後 SCVMM 安裝程序也會提醒必須重新啟動才能繼續安裝程序。同時,SCVMM 安裝過程中,便會連線至指定的 SQL Server 中建立名稱為「VirtualManagerDB」的資料庫(如圖 19 所示)。

圖 19、至指定的 SQL Server 中建立 VirtualManagerDB 資料庫


建構 SPF 以便介接 VMM 及 WAP
事實上,在 Windows Azure Pack 的運作架構中,當管理人員或租用戶登入 WAP 入口網站後進行的任何動作,並非直接與底層的 SCVMM 虛擬化管理平台互動,而是透過 SPF 擔任 WAP 與 SCVMM 之間溝通的橋梁(如圖 20 所示),舉例來說,當租用戶登入 WAP 入口網站後進行 VM 虛擬主機的佈署作業時,便是透過 SPF 中介與 SCVMM 互動,至於各種資源使用量監控的部分也是透過 SPF 中介與 SCOM 進行互動。

圖 20、安裝 SPF 中介溝通角色

值得注意的是,SPF 角色可以跟 SCVMM 主機安裝在同一台也可以獨立一台,並且安裝檔案在 System Center Orchestrator ISO 內,並且在 SPF 安裝過程中將會連線至指定的 SQL Server 中建立名稱為「SCSPFDB」的資料庫(如圖 21 所示)。

圖 21、至指定的 SQL Server 中建立 SCSPFDB 資料庫


建構 WAP 入口網站
只要下載並執行 Web Platform Installer(本書實作環境為 5.0 版本),點選至 Products 搜尋關鍵字 Windows Azure Pack,便會找到安裝 Windows Azure Pack 相關運作元件及角色等項目。倘若,你希望佈署「Windows Azure Pack 快速架構」,也就是所有運作元件及角色都在同 1 台主機時,那麼請搜尋「Windows Azure Pack:Portal and API Express」項目並進行安裝作業即可(如圖 22 所示)。

圖 22、安裝及佈署 Windows Azure Pack 快速架構

接著請在 WAP 主機開啟瀏覽器,鍵入網址 https://localhost:30101 進行建立 WAP 資料庫的動作,完成後將會在 WAP 資料庫中,看見許多以「Microsoft.MgmtSvc」名稱開頭所建立的資料庫(如圖 23 所示)。

圖 23、WAP 初始化並建立 WAP 資料庫

完成 WAP 初始化並建立 WAP 資料庫之後,便可以連結網址 https://localhost:30091 進入管理者入口網站(Admin Portal),建立 VM Clouds、Plans、租用戶使用者帳號……等。最後,租用戶便可以登入使用者入口網站(Tenant Portal),並且看到管理人員所給予的建立相關雲端資訊的項目(如圖 24 所示)。

圖 24、租用戶登入使用者自助式入口網站





結語

透過本文的說明及實作演練,相信讀者已經完全了解 Windows Azure Pack 的運作元件及佈署架構,以及如何建置 Windows Azure Pack 運作環境。在後續實戰文章中我們也將會討論及實作演練,Windows Azure Pack 整合 Windows Server 2016 特色功能,例如,Shielded VMs、SDN v2……等。