Azure Stack設計哲學之物理架構探秘

LeandraHQPO 7年前發布 | 30K 次閱讀 分布式/云計算/大數據 Windows Azure

Azure Stack 作為微軟最新的混合云產品，在整個軟件架構和基礎設施層面結合了原生的 Azure 技術與最新的 Windows Server 2016 軟件定義數據中心（Software Define Data Center, SDDC）。

由于作為 Azure Stack 云平臺的管理者，我們有機會深入系統內部一探究竟，從這款混合云產品來分析 Azure 在構建云基礎設施層面都采用了哪些先進技術和值得借鑒的思想。

本文將從 Azure Stack 的一體機集成系統入手，對 Azure Stack 的物理架構、產品架構和系統架構進行簡要分析。希望通過分析可以讓我們在未來使用 Azure Stack 進行集成開發、混合應用設計、獨立應用開發時能夠更貼合 Azure Stack 的設計哲學。

本文將主要介紹其硬件架構及邏輯架構，并通過在最新版 Azure Stack Development Kit 中的實踐來逐步了解其基礎設施層面的細節。希望通過本文你能夠解決如下疑問：

  1. Azure Stack 是什么？
  2. Azure Stack 為什么采用集成系統（Integrated System）?
  3. Azure Stack Development Kit 的邏輯架構是如何設計的？

什么是 Azure Stack

這是個很有意思的問題，自 Azure Stack 在 2014 年公布以來，來自不同渠道的聲音都對微軟即將正式發布的這個云平臺給予極大的關注。但即使在即將發布（2017 年年中正式發布）的今天，也很少有人能完全講明白 Azure Stack 到底是什么。我們先簡單的聊一些背景知識。

最早的時候，微軟通過 System Center 2012 suite 提出了其私有云（或企業內部云）的概念。這一軟件套件通過 System Center App Controller 提供了在用戶環境快速部署相關資源的能力。它通過一個基于 Silverlight 的 Web 接口，允許用戶部署模板和服務資源。然后用戶的部署請求將直接傳遞至 System Center Virtual Machine Manager（VMM）處執行。這樣的設計方便了租戶申請資源但對于管理員而言卻難以管理。

2013 年 10 月，與 System Center R2 同步推出了一個免費的私有云平臺門戶軟件 Windows Azure Pack（WAP）。在 WAP 的設計中吸取了很多 Azure 的特色，比如與 Azure 經典門戶一致的使用體驗、自服務的業務提供方式、多租戶管理等，同時還提供了三個基本的 PaaS 服務：WebSite As a Service，Database As a Service 以及 Service Bus。很多人開始覺得 WAP 將會是一個將 Azure 部署在自己數據中心的工具。但是，本質上 WAP 只是一個門戶，真正的虛擬化服務和云平臺的管理還是基于 System Center 和 Windows Server，WAP 通過一層 Service Management Rest API 接口與下層的管理系統打通。在模板、通信接口、運行環境中上 WAP 和 Azure 還是有較大差異。尤其隨著 Azure 從經典門戶逐步遷移至新的 ARM 門戶，WAP 似乎與 Azure 越走越遠，但毫無疑問 WAP 的體系依然是一款性價比頗高的私有云產品。

微軟在 2015 年的 Ignite 大會上公布了 Azure Stack 系統并在隨后 2016 年 2 月，微軟釋出了 Azure Stack 的第一個技術預覽版（TP1），標志著一款與 Azure 具有一致性用戶體驗、一致性開發接口、無縫的資源遷移的混合云產品的誕生。下面綜合筆者參加西雅圖培訓和與微軟 Azure Stack 工程師、微軟主要合作伙伴以及其它競爭對手交流的觀點，對現在流行的幾種主要觀點做簡單分析。

Azure Stack 是微軟又一款私有云產品

因為有前面產品 Azure Pack，尤其是在 Azure Pack 中也存在跟多家硬件嘗試一起構建 Cloud Platform System（CPS）的集成系統，使得很多人在最初都認為 Azure Stack 的一體機就是微軟下一代的私有云產品，是用來替代 Azure Pack。我們在對 Azure Stack 技術預研的初期階段也存在類似的困惑，為此咨詢了很多微軟的技術人員和 Azure Pack 的實際使用者。下圖描述了 CPS 和 Azure Stack 一體機在定位和需求上的差異，在此不展開說明。兩者有著不同的市場定位，短期內 Azure Stack 也不會替代 Azure Pack（CPS）的地位。

(點擊放大圖像)

Azure Stack可以部署在自己數據中心

基于對 Azure Stack 與 Azure 一致性接口及體驗的認識，也自然有一些人認為 Azure Stack 是把 Azure 部署在自己的數據中心。包括在 Azure Stack 早期的官方宣傳中也經常以“Azure Stack -- Put Azure into Your Own Datacenter”來介紹。但這畢竟只是一個形象的說明，實際上 Azure 一個集群動輒上千個節點是沒法輕易部署在用戶自己數據中心的。同樣在底層的支撐技術層面，Azure Stack 使用了最新的 Windows Server 2016 及其相關特性，這與 Azure 使用的技術也是不同的。所以 Azure Stack 更應該被當作是 Azure inspired ，一個云基礎設施。

Azure Stack 是 Azure 眾多 Region 中一個

2017 年 7 月 10 日，Azure Stack 產品 GA，在當天發布的產品白皮書中，對 Azure Stack 的最新定位為“Azure Stack: An extension of Azure”。相信這也是對 Azure Stack 經過這么久時間接受市場檢驗之后的最終定義。從生態上看，將 Azure Stack 作為 Azure 的一個個邊緣節點， 來擴展 Azure 的能力跟業務領域；從技術上，由于采用一致的 ARM 接口，對于 Azure Stack 的開發、部署、監控與操作 Azure 的多個 region 是一致的。于此同時，又滿足了用戶在上面一點中期望將 Azue 部署在自己數據中心的訴求。

Azure Stack 物理架構

在前面幾篇 Azure Stack 系列文章中，我們已經介紹過 Azure Stack 將以一體機 / 集成系統的方式銷售。我們先從提供一體機方案的一家供應商入手來了解這款新的混合云產品的物理架構，如下圖所示為 Lenovo 即將推出的新一代 Azure Stack 一體機方案中 4-8 個節點的硬件系統圖（更多詳情可以訪問聯想官網）。

(點擊放大圖像)

進一步參見如下示意圖，Azure Stack 的一體機中包含的主要硬件有每個機柜一個 BMC 交換機、兩臺架頂交換機（Top of Rack，ToR）、4-12 個超融合服務器節點（截至 GA 一個集群的最大容量為 12 個節點）以及一臺 1U 的生命周期管理節點（Hardware Lifecycle Host, HLH）。

(點擊放大圖像)

在硬件架構上，隨著超融合架構的日益成熟，其實很多私有云平臺也會采用類似的架構，甚至可以把所有資源集成在 3 臺甚至 2 臺服務器上承載，在部署方面也有類似單獨拿出一臺節點來進行部署包的分發，后續可以直接作為服務節點提供服務。拋開這些通用的設計哲學，我們來重點關注如下幾個方面的內容。

生命周期管理節點

在最初的 Azure Stack 硬件系統設計階段，Azure Stack 的物理拓撲里面沒有單獨拿出一個節點來作為生命周期節點，但需要占用超融合服務器中的一個物理節點，由于后續的更新、維護都會用到這個節點，所以本質上這個節點是無法完全用于提供計算資源的。在聯想給出的集成系統中通過一臺 1U 的 System x3550 M5 來實現管理節點，主要提供對硬件資源的管理（包括軟件部署和固件、軟件更新），主要搭載了如下服務：

  • 一臺部署虛擬機，提供前期軟件包的分發及部署服務
  • 聯想的管理軟件虛機 Lenovo Xclarity，提供硬件監控和管理服務

在一體機的集成方案中， 對于硬件部分的監控是不受 Azure stack 軟件來直接監管的，而把這部分能力和服務交付給了各個硬件服務商，因為一方面硬件服務商更熟悉自己的硬件配置及固件管理方式，另外多家硬件廠商在前期已經擁有自己成熟的硬件管理系統。這也是在一體機設計中需要考慮的很重要的一點。關于近期即將發布 Azure Stack 一體機的三家硬件廠商的對比可以參考我們上一篇推出的 Azure Stack 系列文章。下面簡單列出 Lenovo XClarity 在 Azure Stack 一體機方案中的主要功能點供參考：

  • 自動發現和監控管理節點，超融合節點和交換機
  • 固件更新和合規執行
  • 基于預定模式的配置管理
  • 裸機部署操作系統和 hypervisor
  • 通過 SNMP、syslog、Email 進行外部報警及通知
  • 與管理節點的安全連接，基于 NIST 800-131A/ FIPS 140-2 加密標準
  • 通過 REST API 集成到現有的更高級管理系統，如云自動化和業務流程工具，提供廣泛的外部可見性和硬件資源控制

特別地，HLH 節點本身沒有提供高可用的方案，也沒有必要采用高可用方案，理論上部署結束之后 HLH 節點是可以關閉的，當然為了監控和未來升級的需求建議保持運行狀態。

規模及擴展

Tips：在 Azure Stack GA 階段初期，只支持一個 Region 一個 Scale Unit 的 Azure Stack 集群配置和三種規模集群配置，即 4 個節點，8 個節點和 12 個節點。而且特別說明的一點是在這個階段不支持集群的擴展功能，比如購買了 4 個節點的集群部署系統，無法通過額外添加四個節點來擴展集群規模。Tips 中提到的規模限制僅限于 Azure Stack GA 階段，實際上在擴展性方面，Azure Stack 采用了與 Azure 一致的規模擴展架構，本質上每個 Azure Stack 的 region 等價于 Azure reigon，原則上可以無限擴展。本節我們將通過幾個概念來描述 Azure Stack 的規模及擴展方式。如下圖所示為 Azure Stack 在擴展性方面的架構及幾個主要的概念示意圖：

(點擊放大圖像)

Scale Unit

在 Azure Stack 中，一個 Scale Unit 定義為一組計算、存儲和網絡資源的集合（服務器節點集合），代表一個獨立的擴展單元、一個 Azure 的故障域和一組完全同構的硬件設備集合。一個 Azure Stack Region 可以包括一個或多個 Scale Unit。

注意：在 Azure Stack 中一個 Scale Unit 與一個 Windows Server 2016 的 Failover Cluster 一一對應，組成一個完整的故障域。

Region

雖然 Azure Stack 在 GA 階段只支持一個 region，但并不代表 Azure Stack 在技術架構上不支持多個 region，而更多的是處于穩定性的考慮人為做的限定。region 在 Azure Stack 中的概念與 Azure 中一致，代表同一地理位置的物理資源的集合。

在最近發布的 Azure Stack Development Kit 中，可以通過 Azure Stack tools 的如下命令來設定自己 Azure Stack 的集群地理位置及 region 名稱：

$EnvironmentName = "AzureStackAdmin"
$directoryName = "<





 >.onmicrosoft.com"
$credential = Get-Credential
$latitude = '12.972442'
$longitude = '77.580643'
$regionName = 'local'
Set-AzsLocationInformation -Region $regionName -Latitude $latitude -Longitude $longitude

Azure Stack 多 region 的設計為業務架構設計帶來一定的靈活性，但在設計過程中也需要更多的考慮如下幾方面內容：

  1. 網絡時延：尤其業務對象需要跨越多個 region 時，需要充分考慮網絡延時帶來的不利影響，同時可以利用 Azure 的 CDN 和 Traffic Manager 來實現就近提供服務的能力；

  2. 數據同步問題：需要考慮數據的一致性、可用性并保證一定的用戶體驗不受太大影響；

  3. 另外還需要注意，很多 Azure Stack 的服務與 region 獨立的，比如每個 region 都會有獨立的應用市場、基于角色的權限控制、資源組、配合、服務、計劃等。

云

Azure Stack 通過統一的 ARM 層封裝，將所有 region 的資源有效整合，對外提供統一的門戶和認證管理體系。

超融合節點的限制

在公布的 GA 一體機方案中，對超融合節點進行了比較強的約束，在同一個 scale unit 中的所有超融合節點必須采用完全相同的配置，包括一致的 CPU、一致的內存、硬盤存儲配置、網絡接口配置等。這個限制主要來自于 Azure Stack 一體機方案對全生命周期管理尤其是不停止業務升級的一種折中。

在 Azure Stack 的升級方案中，將采用 service fabric 中 Update Domain 的設置，升級過程中將按照 Update Domain 中的配置，一個節點一個節點的升級，節點升級過程中，節點承載的業務將遷移到其它節點中，直到所有節點更新完畢，整個系統升級結束，中間任意節點失敗將回滾至升級前狀態。筆者的理解是完全同質的硬件環境會更加有利于這個過程的開展，但并非完全是一個必要條件，后續隨著 Azure Stack 開發的日趨完善，在同一個 scale unit 中采用不同的硬件配置也并非沒有可能。

硬件廠商綁定

值得關注的一點是 Azure Stack 一體機方案目前依托五家廠商來承載，雖然在上文提到在一個 scale unit 中無法混合搭配物理硬件（即使是同一家廠商的也必須嚴格一致），那么在整個 Azure Stack 集群中是否可以同時采用多家的硬件？答案是肯定可以混合，但存在一定的限制，而且這種混合無法出現在 GA 階段。

不同硬件廠商平臺產品融合的層面在 region 層面，即來自不同廠商的 Azure Stack 集群通過 region 隔離。如下圖所示，為跨 scale unit 的網絡連線圖，在一個 region 中，sacle Unit 中的聚合交互及需要連接到另一個 scale unit 中的兩臺 ToR 交換機，以便實現資源負載的均衡。為了實現跨 scale unit 的數據備份及故障域設置，需要通過聚合交換機連接來自兩個 scale unit 的 ToR 交換機，而如果采用不同硬件廠商的物理硬件導致兩個 scale unite 無法共享同一個聚合交換機（同一個 region 中的網絡交換機必須匹配以便于相互連接）。而兩個 region 之間的聯通不存在這個問題，所以是 GA 以后一段時間內容硬件混合部署的一種可行方案。

(點擊放大圖像)

超融合的集成系統解決方案

如下圖所示為 Azure Stack 的另一家一體機提供商 HPE 的面向云基礎設施提供的系統結構變遷。經歷了從傳統 IT 到超融合集成系統的變遷。

(點擊放大圖像)

為什么要在 Azure Stack 中采用一體機的策略，主要有如下幾方面原因：

  1. 全生命周期管理的需求。上文已經反復論述，為了實現云平臺的全生命周期管理需要對軟硬件都具有高度的可控性及大量的集成測試；
  2. 新產品的時機。Azure Stack 的發布日期已經經歷了一次 6 個月的跳票，這一方面也表明在 Microsoft 將其作為一個完整，穩定和可靠的產品發布之前，需要做大量的工作。 他們沒有時間和資源來驗證不同的硬件組件，彼此的互操作性和保證它是穩定的，而不會中斷整個系統進度；
  3. 新技術對新的硬件存在一定的依賴。比如 SDS 中內存直接讀取技術；超融合的硬件配置也存在一定的依賴；
  4. 過往的經驗教訓。WAP 在不限定物理資源環境部署過程遇到了諸多用戶反饋的問題，增加了部署的難度和對運維人員技能的要求。所以才有了基于 Azure Pack 的 CPS 一體機方案，Azure Stack 的落地借鑒了 Azure Pack 的經驗教訓；
  5. 提供更新補丁更有針對性。因為更新不止針對軟件，如果 OEM 供應商發布固件更新、BIOS 更新或對硬件的任何更新，Microsoft 都希望確保升級過程盡可能順利，并且補丁 / 固件在測試中已經被預先驗證， 為了做到這一點，Microsoft 需要對硬件廠商設置一些限制，以確保它們能夠維護硬件的控制；
  6. 簡化部署和運維自動化。提供給你一個盒子，你只要連連線，上電。

Azure Stack 單節點 PoC 系統邏輯

Azure Stack 的單節點 PoC 環境是熟悉和了解 Azure Stack 系統和功能架構最好的入口，我們本節將以 2017 年 7 月最新發布的 Azure Stack Development Kit（以下簡稱 DevKit）入手來進一步了解 Azure Stack 系統的物理架構組成，同時也簡要分析一下 Azure Stack 單節點 PoC 環境與多節點生產環境的主要差異。

Azure Stack 的邏輯架構

微軟官方文檔給出了 Azure Stack DevKit 的邏輯架構如下圖所示，在部署的操作系統 Windows Server 2016 之上通過 Hyper-V 虛擬化出 13 個虛擬機（圖中沒有標識出 AzS-SQL01）用來承載 Azure Stack 運行態的各項服務，可以通過在部署節點上運行 Hyper-V Manager 或 Failover Cluster 查看各虛擬機的運行狀態及對資源的需求。其中虛擬機實例 AzS-BGPNAT01 用來模擬交換機網絡，僅出現在單節點環境中，作為所有網絡流量的出 / 入口。如果希望將 Azure Stack 環境中的某個資源暴露在外部網絡可以方面的空間，可以在 AzS-BGPNAT01 上通過 Add-NetNatStaticMapping 配置一個 NAT，更多信息可以參考我前面寫過的博客（http://a-stack.com/VM-NAT-in-Azure-Stack-PoC/）。

(點擊放大圖像)

我們將各個虛擬機的功能簡單整理為下表：

(點擊放大圖像)

跟 TP3 版本相比，Azure Stack Development Kit 中，承載服務的虛擬機發生了一定的變化：

  1. 所有的虛機類型都變為 2016 Server Core；
  2. 所有機器名稱的前綴由 MAS- 變為 AzS-;
  3. 不再在初始階段提供測試用的 MAS-CON01 這臺機器；
  4. 提供更新服務的 MAS-SUS 機器也消失了。

查看系統底層基礎設施及資源

對基礎設施的管理可以在不同的層面展開，本文根據 DevKit 環境簡單介紹幾種，來更直觀的認識 Azure Stack 基礎設施層面的支撐。登陸 Azure Stack Development Kit 的部署環境，可以通過工具 Hyper-V Manager 查看所有虛擬機的運行狀況：

(點擊放大圖像)

另外也可以通過 Azure Stack 系統的管理員賬號登陸 https://adminportal.local.azurestack.external/, 在 More service-Region management，通過點擊側邊欄的 Infrastructure Resources-Capactiy 來查看系統的資源整體使用情況。

(點擊放大圖像)

進一步可以通過點擊 Infrastructure Resources -Infrastructure roles，可以查看各個基礎設施服務角色及其所在承載機器的位置。

(點擊放大圖像)

Portal 中僅列出了 Azure Stack 集群的部分基礎設施角色，想查看更多角色可以參考下文通過 Azure Stack Tools 來管理基礎設施資源。

在第二章我們分析過一個 sacle unit 等價于一個 Windows Server 的 Failover 集群，在 DevKit 環境中，我們可以通過 Failover Cluster Manager 來查看這個 Failover 集群的基本信息，如下圖所示，承載服務的虛擬機實例構成了 Failover 集群的角色，在多節點環境中每個集群角色將通過部署在多個故障域虛擬機共同承擔。處理上面提到的 13 個虛擬機角色，還有一個類型為 Scale-Out File Server（SOFS）共享存儲服務器 SU1FileServer 為基礎設施提供統一存儲資源池。

(點擊放大圖像)

在 DevKit 中 SOFS 構建在 Windows Server 的 Storage Space Direct（S2D）之上，向下將所有可用的物理磁盤整合為 Cluster Shared Volumes(CSV)，向上通過 SMB3 接口提供文件共享服務。在 DevKit 中構建了如下圖所示的 6 個 Share，來提供不同的功能。比如 SU1_VmTemp 主要用戶存儲虛擬機的臨時盤空間，SU1_ObjStore 用來保存 blob 提供的 PaaS 層存儲服務內容。

(點擊放大圖像)

在網絡方面，我們通過 Failover Cluster Manager 可以看到，DevKit 包括三個虛擬網絡，分別用于存儲、管理和部署。

(點擊放大圖像)

Azure Stack 單節點 PoC 與多節點生產環境的差異

  1. 功能：單節點測試環境通過一個物理節點實現了所有的基礎設施及 Tenant VM 資源，所有的 Tenant VM 都為單一節點，不存在 HA；
  2. 彈性：雖然支持鏡像存儲（mirrored storage）配置功能，但根據硬件環境限制配置為 Simple Space 模式；
  3. 網絡：BGPNAT 虛擬機僅存在單節點環境中，單節點環境中沒有實現或模擬 switch 的網絡鏈接，所以所有的消息流通過一個綁定的主機 NIC 和 BGPNAT VM 實現；

通過 Azure Stack調用 Infrastructure 接口

以下來自 InfoQ 對阿里云產品技術負責人李津的采訪整理。Docker 其實類似于早期的 LXC，是由 namespace 和 CGroup 兩個技術疊加出來的，但又不完全是。

在《Azure Stack 技術深入淺出系列 3》中我們介紹過 Azure Stack 目前一組開發工具 Azure Stack Tools 可以快速幫我們了解及構建針對 Azure Stack 的開發及集成工作。本節中我們將利用 Azure Stack Tools 中的 Azure Stack Infrastructure Administration 工具，來獲取 Azure Stack Develop Kit 基礎設施的一些基本信息。

首先下載并導入 AzureStack.Infra.psm1 模塊，參照 http://a-stack.com/Powershell-for-Azure-Stack/ 安裝并配置環境。可以通過命令 Get-AzsInfrastructureRole,Get-AzsInfrastructureRoleInstance 來分別查看基礎設施的 role 資源和承載 role 的虛擬機實例。

PS C:\Users\AzureStackAdmin\Documents\AzureStack-Tools-master> Get-AzsInfrastructureRole
Name              : Authorization service (Administrator)
ResourceId        : /subscriptions/70bd3f7c-6d34-4d20-87c3-82617b4301ab/resourceGroups/system.local/providers/Microsoft.Fabric.Admin/fabricLocations/local/in
                    fraRoles/Authorization service (Administrator)
ResourceName      : local/Authorization service (Administrator)
ResourceType      : Microsoft.Fabric.Admin/fabricLocations/infraRoles
ResourceGroupName : system.local
Location          : local
SubscriptionId    : 70bd3f7c-6d34-4d20-87c3-82617b4301ab
Tags              : {}
Properties        : @{Metadata=; Instances=System.Object[]}
...

總結

本文介紹了 Azure Stack 的物理架構，包括一體機的設計、可擴展的模式，同時分析了 Azure Stack 最新一代 PoC 環境 Development Kit 的邏輯架構，希望可以為基于 Azure Stack 的業務體系設計提供一定的幫助和指導。

本文系上海儀電集團旗下專研 Azure Stack 團隊的投稿，《Azure Stack 深入淺出系列》第七篇，已經授權 InfoQ 公眾號轉發傳播。如果對文章內容感興趣請聯系儀電（集團）有限公司 Azure Stack 技術支持團隊：gaoc@rc.inesa.com/niuhx@rc.inesa.com

 

來自：http://www.infoq.com/cn/articles/azure-stack-design-physical-architecture-exploration

 

 本文由用戶 LeandraHQPO 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！