Azure Stack 设计哲学之物理架构探秘

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 = "<<yourdirectoryname>>.onmicrosoft.com"
$credential = Get-Credential
$latitude = '12.972442'
$longitude = '77.580643'
$regionName = 'local'
Set-AzsLocationInformation -Region $regionName -Latitude $latitude -Longitude $longitude</yourdirectoryname>

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

感谢江柳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。