Azure 虚拟机基线体系结构

本文提供了 Azure 虚拟机上部署的工作负荷的基础参考体系结构。

此体系结构假设的示例工作负荷是一个面向 Internet 的多层 Web 应用程序，该应用程序部署在单独的虚拟机 (VM) 集上。 VM 预配为 Azure 虚拟机规模集部署的一部分。 此体系结构可用于以下方案：

• 专用应用程序。 这些应用程序包括内部业务线应用程序或商用现货解决方案。
• 公共应用程序。 这些应用程序是面向 Internet 的应用程序。 此体系结构不适用于高性能计算、任务关键型工作负荷、受延迟或其他专用用例影响很大的应用程序。

此体系结构的主要关注点不是应用程序。 相反，本文提供了配置和部署应用程序与之交互的基础结构组件的指南。 这些组件包括计算、存储、网络和监视组件。

此体系结构可作为基础结构即服务 (IaaS) 托管工作负荷的起点。 有意将数据层排除在本指南之外，以保持重点关注计算基础结构。

文章布局

体系结构	设计决策	Well-Architected Framework 方法
▪ 体系结构图 ▪ 工作负荷资源 ▪ 支持资源 ▪ 用户流	▪ VM 设计选择 ▪ 磁盘 ▪ 网络 ▪ 监视 ▪ 更新管理	▪ 可靠性 ▪ 安全性 ▪ 成本优化

体系结构

下载此体系结构的 Visio 文件。

有关这些资源的信息，请参阅相关资源中列出的 Azure 产品文档。

组件

此体系结构由适用于工作负荷资源和工作负荷支持资源的多个 Azure 服务组成。 以下部分描述了每个资源的服务及其角色。

工作负荷资源

• Azure 虚拟机作为应用程序的计算资源分布在各个可用性区域。 出于说明目的，使用了 Windows 和 Linux VM 的组合。

  灵活编排模式下的 Azure 虚拟机规模集用于预配和管理 VM。

  示例应用程序可以分为两个层，每个层都需要自己的计算。

  • 前端运行 Web 服务器并接收用户请求。
  • 后端运行另一台充当 Web API 的 Web 服务器，公开在其中执行业务逻辑的单个终结点。

  前端 VM 附加了数据磁盘 (Premium_LRS)，可用于部署无状态应用程序。 作为其操作的一部分，后端 VM 将数据保存到 Premium_ZRS 本地磁盘。 这种布局可以扩展为包含一个数据库层，用于存储来自前端和后端计算的状态。 该层不在此体系结构的范围之内。

• Azure 虚拟网络为所有工作负荷资源提供专用网络。 网络被划分为多个子网，作为隔离边界。

• Azure 应用程序网关是将请求路由到前端服务器的入口点。 所选 SKU 包括集成的 Azure Web 应用程序防火墙 (WAF)，以增强安全性。

• 内部 Azure 负载均衡器将流量从前端层路由到后端服务器。

• Azure 负载均衡器标准 SKU 使用三个公共 IP 地址为 VM 提供出站 Internet 访问。

• Azure Key Vault 存储用于端到端传输层安全性 (TLS) 通信的证书。 它还可用于应用程序机密。

工作负荷支持资源

• Azure Bastion 通过安全协议提供对 VM 的操作访问权限。

• Application Insights 从应用程序收集日志和指标。 由于应用程序不是此体系结构的重点，因此实现并没有介绍日志收集。

• Log Analytics 是从 Azure 资源和 Application Insights 收集日志和指标的监视数据接收器。 存储帐户作为工作区的一部分进行预配。

用户流

有两种类型的用户与工作负荷资源交互：工作负荷用户和操作员。 针对这些用户的流程如前面的体系结构图所示。

工作负荷用户

1. 用户使用应用程序网关的公开公共 IP 地址访问网站。

2. 应用程序网关接收 HTTPS 流量，使用外部证书解密数据以进行 WAF 检查，并使用内部通配符证书重新加密数据以传输到前端。

3. 应用程序网关平衡各前端 VM 之间的流量，并将请求转发到前端 VM。

4. 所选的前端 VM 使用负载均衡器的专用 IP 地址而不是任何单个 VM 的 IP 与后端 VM 通信。 此通信也使用内部通配符证书进行加密。

5. 后端 VM 使用内部证书解密请求。 后端处理请求后，将结果返回给前端，前端将结果返回到应用程序网关，最后将结果返回用户。

操作员

此体系结构中的 VM 可能需要操作员直接访问，但我们建议通过自动化尽量减少远程访问，并对访问进行监视。 访问可能适用于故障维修情况、故障排除或自动化部署过程的一部分。 此体系结构没有用于控制平面访问的公共 IP。 Azure Bastion 充当无服务器网关，使操作能够通过 SSH 或 RDP 访问 VM。 此设置可确保安全高效的访问管理。

1. 操作员登录到 Azure 门户 或 Azure CLI。
2. 操作员访问 Azure Bastion 服务并远程连接到所需的 VM。

VM 设计选择

在选择 SKU 时，务必要明确基线性能预期。 若干特征会影响决策过程，包括：

• CPU、内存和磁盘每秒输入/输出操作 (IOPS)。
• 处理器体系结构。
• 操作系统 (OS) 映像大小。

例如，如果要从需要 Intel 处理器计算机的本地环境迁移工作负荷，请选择支持 Intel 处理器的 VM SKU。

有关支持的 VM SKU 的信息，请参阅 Azure 中虚拟机的大小。

启动

VM 通常需要启动，这是准备和优化 VM 以运行应用程序的过程。 常见的启动任务包括安装证书、配置远程访问、安装包、优化和强化 OS 配置，以及格式化和装载数据磁盘。 重要的是要尽可能实现启动过程的自动化，这样应用程序就能在 VM 上启动，而不会出现延迟或需要人工干预。 以下是有关自动化的建议：

• 虚拟机扩展。 这些扩展是通过基础结构即代码 (IaC) 部署管理的 Azure 资源管理器对象。 这样，任何故障都会被报告为部署失败，您可以对其采取相应措施。 如果没有满足启动需求的扩展，请创建自定义脚本。 建议通过 Azure 自定义脚本扩展运行脚本。

  以下是一些其他扩展，可用于在 VM 上自动安装或配置功能。

  • Azure Monitor 代理 (AMA) 从来宾 OS 收集监视数据，并将其传送到 Azure Monitor。
  • Azure 自定义脚本扩展（Windows、Linux）版本 2 下载脚本并在 Azure 虚拟机 (VM) 上运行。 此扩展对于自动化部署后配置、软件安装或任何其他配置或管理任务非常有用。
  • Azure 密钥保管库虚拟机扩展（Windows、Linux）通过检测更改和安装相应的证书来自动刷新存储在密钥保管库中的证书。
  • 当 Azure 虚拟机扩展集进行自动滚动升级时，具有虚拟机规模集的应用程序运行状况扩展非常重要。 Azure 依靠对单个实例的运行状况监视来执行更新。 还可以使用该扩展来监视规模集中每个实例的应用程序运行状况，并使用自动实例修复来执行实例修复。
  • Microsoft Entra ID 和 OpenSSH（Windows、Linux）与 Microsoft Entra 身份验证相集成。 现在可以将 Microsoft Entra ID 用作核心身份验证平台和证书颁发机构，使用 Microsoft Entra ID 和基于 openSSH 证书的身份验证通过 SSH 连接到 Linux VM。 此功能使你能够使用 Azure 基于角色的访问控制 (RBAC) 和条件访问策略来管理对 VM 的访问。

• 基于代理的配置。 Linux VM 可以使用在 Azure 提供的各种 VM 映像上通过 cloud-init 提供的轻型本机 Desired State Configuration。 配置通过你的 IaC 项目进行指定和版本控制。 另一种方法是自带配置管理解决方案。 大多数解决方案都遵循声明性优先的启动方法，但也支持自定义脚本以实现灵活性。 热门选择包括适用于 Windows 的 Desired State Configuration、适用于 Linux 的 Desired State Configuration、Ansible、Chef、Puppet 等。 所有这些配置解决方案都可以与 VM 扩展配对，以获得两全其美的体验。

在参考实现中，所有启动都是通过 VM 扩展和自定义脚本完成的，包括用于自动格式化和装载数据磁盘的自定义脚本。

请参阅 Well-Architected Framework：RE:02 - 自动化设计建议。

VM 连接

为了实现 VM 与特定虚拟网络中的其他设备之间的专用通信，需要将 VM 的网络接口卡 (NIC) 连接到虚拟网络的一个子网中。 如果 VM 需要多个 NIC，请注意每种 VM 大小都定义了最大 NIC 数量。

如果工作负荷需要在虚拟网络中 VM 之间进行低延迟通信，请考虑 Azure VM NIC 支持的加速网络。 有关详细信息，请参阅加速网络的优点。

具有灵活编排的虚拟机规模集

作为虚拟机规模集的一部分，虚拟机通过灵活编排进行调配。 虚拟机规模集是用于满足业务需求的 VM 的逻辑分组。 分组中的 VM 类型可以相同，也可以不同。 你可以使用标准 Azure VM API 和命令来管理计算机、网络接口和磁盘的生命周期。

灵活编排模式有助于大规模操作，并帮助做出精细的缩放决策。

需要进行容错域配置来限制物理硬件故障、网络中断或电源中断的影响。 通过规模集，Azure 可将实例均匀分布到各个容错域中，以便针对单个硬件或基础结构问题进行复原。

建议将容错域分配卸载到 Azure，以实现最大限度的实例分布，从而增强复原能力和可用性。

磁盘

若要运行 OS 和应用程序组件，则需要将存储磁盘连接到 VM。 请考虑将临时磁盘用于 OS，并将托管磁盘用于数据存储。

Azure 在性能、多功能性和成本方面提供了一系列选项。 对于大多数生产工作负荷，请从高级版 SSD 开始。 你的选择取决于 VM SKU。 支持高级版 SSD 的 SKU 在资源名称中包含一个 s，例如 Dsv4 而不是 Dv4。

有关包含容量、IOPS 和吞吐量等指标的磁盘选项的详细信息，请参阅磁盘类型比较。

选择磁盘时要考虑磁盘特征和性能预期。

• VM SKU 限制。 磁盘在所连接的 VM 中运行，这些 VM 具有 IOPS 和吞吐量限制。 确保磁盘不会限制 VM 的限制，反之亦然。 选择磁盘大小、性能和 VM 功能（核心、CPU、内存），确保以最佳方式运行应用程序组件。 避免过度预配，否则会影响成本。

• 配置更改。 你可以在 VM 运行时更改某些磁盘性能和容量配置。 但是，许多更改可能需要重新预配并重新生成磁盘内容，从而会影响工作负荷可用性。 因此，请仔细规划磁盘和 VM SKU 的选择，以尽量减少可用性影响和返工。

• 临时 OS 磁盘。 将 OS 磁盘预配为临时磁盘。 仅当 OS 文件需要持久保存时，才使用托管磁盘。 避免使用临时磁盘来存储应用程序组件和状态。

  临时 OS 磁盘的容量取决于所选的 VM SKU。 确保 OS 映像磁盘大小要小于 SKU 的可用缓存或临时磁盘。 你可以将剩余空间用于临时存储。

• 磁盘性能。 根据峰值负载来预配磁盘空间很常见，但这样可能会导致资源利用不充分，因为大多数工作负荷都不会达到峰值负载。

  监视工作负荷的使用模式，注意峰值或持续的高读取操作，并在选择 VM 和托管磁盘 SKU 时考虑这些模式。

  你可以通过更改性能层或使用某些托管磁盘 SKU 中提供的突发功能来按需调整性能。

  虽然超量预配可减少突发需求，但也可能会导致你为未使用的容量买单。 理想情况下，合并这两个功能即可获得最佳结果。

• 微调工作负荷的缓存。 根据应用程序组件使用情况为所有磁盘配置缓存设置。

  主要执行读取操作的组件不需要高磁盘事务一致性。 这些组件可以从只读缓存中受益。 需要高磁盘事务一致性的写入密集型组件通常会禁用缓存。

  如果 VM 崩溃，使用读写缓存可能会导致数据丢失，因此不建议在大多数数据磁盘方案中使用读写缓存。

在此体系结构中：

• 所有 VM 的 OS 磁盘都是临时磁盘，并且位于缓存磁盘上。

  前端 (Linux) 和后端 (Windows Server) 中的工作负荷应用程序可以容忍单个 VM 故障，并且都使用较小的映像（约 30 GB）。 这些属性使它们有资格使用作为 VM 本地存储（缓存分区）的一部分创建的临时 OS 磁盘，而不是保存在远程 Azure 存储资源中的持久 OS 磁盘。 这种情况不会产生 OS 磁盘的存储成本，还能通过提供较低的延迟和缩短 VM 部署时间来提高性能。

• 每个 VM 都有自己的高级 SSD P1 托管磁盘，从而可提供适用于工作负荷的基本预配吞吐量。

网络布局

此体系结构在单个虚拟网络中部署工作负荷。 网络控制是此体系结构的重要组成部分，并在安全 部分进行了介绍。

此布局可与企业拓扑集成。 该示例显示在Azure 登陆区域中的虚拟机基线体系结构中。

虚拟网络

初始网络布局决策之一与网络地址范围相关。 请记住在容量规划阶段的预期网络增长。 网络应该足够大才能维持增长，而这可能需要额外的网络构造。 例如，虚拟网络应具有可容纳缩放操作产生的其他 VM 的容量。

相反，调整地址空间的大小。 过大的虚拟网络可能会导致利用不充分。 值得注意的是，一旦创建虚拟网络，就无法再修改地址范围。

在此体系结构中，地址空间会被设为/21，这是基于预计增长做出的决定。

子网划分注意事项

在虚拟网络中，子网是根据功能和安全要求进行划分的，如下所述：

• 一个用于托管作为反向代理的应用程序网关的子网。 应用程序网关需要一个专用子网。
• 用于托管内部负载均衡器的子网，以便向后端 VM 分发流量。
• 用于托管工作负荷 VM 的子网，一个用于前端，一个用于后端。 这些子网是根据应用程序的层来创建的。
• Azure Bastion 主机的子网，用于方便对工作负荷 VM 的操作访问。 根据设计，Azure Bastion 主机需要一个专用子网。
• 用于托管为通过 Azure 专用链接访问其他 Azure 资源而创建的专用终结点的子网。 虽然这些终结点并非必须要使用专用子网，但我们还是建议使用。

与虚拟网络类似，子网的大小必须合理。 例如，你可能想要应用灵活编排支持的 VM 最大限制，以满足应用程序的缩放需求。 工作负荷子网应能满足这一限制。

另一个需要考虑的用例是 VM OS 升级，这可能需要使用临时 IP 地址。 正确调整大小可确保将类似的资源进行分组，以便通过网络安全组 (NSG) 将有意义的安全规则应用于子网边界，从而提供所需的分段级别。 有关详细信息，请参阅安全性：分段。

入口流量

两个公共 IP 地址会被用于入口流。 一个地址会被用作反向代理的应用程序网关。 用户使用该公共 IP 地址进行连接。 反向代理会将入口流量负载均衡到 VM 的专用 IP。 另一个地址用于通过 Azure Bastion 进行操作访问。

下载此体系结构的 Visio 文件。

出口流量

此体系结构使用标准 SKU 负载均衡器，该均衡器包含从 VM 实例定义的出站规则。 之所以选择负载均衡器，是因为它具有区域冗余功能。

下载此体系结构的 Visio 文件。

此配置让你可以使用负载均衡器的公共 IP 为 VM提供出站 Internet 连接。 出站规则允许显式定义源网络地址转换 (SNAT) 端口。 这些规则允许通过手动端口分配来缩放和优化此功能。 根据后端池大小和 frontendIPConfigurations 的数量手动分配 SNAT 端口可以帮助避免 SNAT 耗尽。

建议根据后端实例的最大数量来分配端口。 如果添加的实例超过允许的剩余 SNAT 端口数量，则可能会阻止虚拟机规模集的扩展操作，或者新 VM 将无法获得足够的 SNAT 端口。

按实例计算端口，比如：Number of front-end IPs * 64K / Maximum number of back-end instances。

你还可以使用其他选项，例如部署连接到子网的 Azure NAT 网关资源。 另一个选项是将 Azure 防火墙或其他网络虚拟设备与自定义的用户定义路由 (UDR) 一起用作通过防火墙的下一个跃点。 该选项会显示在 Azure 登陆区域中的虚拟机基线体系结构中。

DNS 解析

Azure DNS 会被用作所有解析用例的基础服务，例如解析与工作负荷 VM 关联的完全限定域名 (FQDN)。 在此体系结构中，VM 使用虚拟网络配置（即 Azure DNS）中设置的 DNS 值。

Azure 专用 DNS 区域会被用于解析对用于访问命名专用链接资源的专用终结点的请求。

监视

此体系结构具有一个与工作负荷实用工具分离的监视堆栈。 重点主要放在数据源和集合方面。

指标和日志在各种数据源中生成，从而在各种高度提供可观测性见解：

• 底层基础结构和组件会被考虑，例如 VM、虚拟网络和存储服务。 Azure 平台日志提供有关 Azure 平台中的操作和活动的信息。

• 应用程序级别提供对系统上运行的应用程序的性能和行为的见解。

Log Analytics 工作区是建议的监视数据接收器，用于从 Azure 资源和 Application Insights 收集日志和指标。

此图显示了基线的监视堆栈，其中包含从基础结构和应用程序收集数据的组件、数据接收器以及用于分析和可视化的各种消耗工具。 实现会部署某些组件，例如 Application Insights、VM 启动诊断和 Log Analytics。 为展示仪表板和警报等扩展性选项，还会描述其他组件。

下载此体系结构的 Visio 文件。

基础结构级别监视

此表链接到 Azure Monitor 收集的日志和指标。 可用警报有助于在影响用户之前主动解决问题。

Azure 资源	指标和日志	警报
应用程序网关	应用程序网关指标和日志说明	应用程序网关警报
Application Insights	Application Insights 指标和日志记录 API	Application Insights 警报
Azure Bastion	Azure Bastion 指标
密钥保管库	密钥保管库指标和日志说明	密钥保管库警报
标准负载均衡器	负载均衡器日志和指标	负载均衡器警报
公共 IP 地址	公共 IP 地址指标和日志说明	公共 IP 地址指标警报
虚拟网络	虚拟网络指标和日志参考	虚拟网络警报
虚拟机和虚拟机规模集	VM 指标和日志参考	VM 警报和教程
Web 应用程序防火墙	Web 应用程序防火墙指标和日志说明	Web 应用程序防火墙警报

有关收集指标和日志的成本的详细信息，请参阅 Log Analytics 成本计算和选项以及 Log Analytics 工作区的定价。 工作负荷的性质以及收集指标和日志的频率和数量对指标和日志收集成本有着很大的影响。

虚拟机

启用 Azure 启动诊断后，可通过收集串行日志信息和截图来观察 VM 在启动时的状态。 在此体系结构中，可以通过 Azure 门户和 Azure CLI vm boot-diagnostics get-boot-log 命令来访问这些数据。 数据由 Azure 管理，你无法控制或访问底层存储资源。 但是，如果业务需求要求进行更多控制，则可以预配自己的存储帐户来存储启动诊断。

VM 见解提供了一种监视 VM 和规模集的有效方法。 它从 Log Analytics 工作区收集数据，并为性能数据趋势提供预定义的工作簿。 可以按每个 VM 查看这些数据，也可以跨多个 VM 聚合这些数据。

应用程序网关和内部负载均衡器在发送流量之前，使用运行状况探测来检测 VM 的终结点状态。

网络

在此体系结构中，日志数据是从参与流的多个网络组件收集的。 这些组件包括应用程序网关、负载均衡器和 Azure Bastion。 它们还包括网络安全组件，例如虚拟网络、NSG、公共 IP 地址和专用链接。

托管磁盘

磁盘指标取决于工作负荷，需要混合使用关键指标。 监视应结合这些视角来隔离 OS 或应用程序吞吐量问题。

• Azure 平台视角表示了指明 Azure 服务的指标，而与连接到它的工作负荷无关。 磁盘性能指标（IOPS 和吞吐量）可单独查看，也可汇总查看所有 VM 附加磁盘的性能指标。 使用存储 IO 利用率指标来排除故障或对潜在的磁盘上限发出警报。 如果使用突发来优化成本，则应监视额度百分比指标，以确定进一步优化的机会。

• 来宾 OS 视角表示工作负荷操作员可以查看的指标，而不考虑基础磁盘技术。 建议对附加磁盘上的关键指标（例如使用的逻辑磁盘空间）以及 OS 内核对磁盘 IOPS 和吞吐量的视角提供 VM 见解。

应用程序级监视

即使参考实现不使用，出于扩展目的，也请将 Application Insights 作为应用程序性能管理 (APM) 进行预配。 Application Insights 从应用程序收集数据，并将这些数据发送到 Log Analytics 工作区。 它还可以将来自工作负荷应用程序的数据可视化。

应用程序运行状况扩展会被部署到 VM，以监视规模集中每个 VM 实例的二进制运行状况状态，并在必要时使用规模集自动实例修复来执行实例修复。 它会测试与应用程序网关和内部 Azure 负载均衡器运行状况探测相同的文件，以便检查应用程序是否响应。

更新管理

VM 需要定期更新和修补，以免削弱工作负荷的安全态势。 建议自动和定期进行 VM 评估，以便及早发现和应用修补程序。

基础结构更新

Azure 会定期更新其平台，以改善虚拟机的主机基础结构的可靠性、性能及安全性。 此类更新包括修补托管环境中的软件组件、升级网络组件或停用硬件等。 有关更新流程的详细信息，请参阅 Azure 中的虚拟机维护。

如果更新不需要重启，则会在主机更新时暂停 VM，或者将 VM 实时迁移到已更新的主机。 如果维护需要重新启动，则你会收到计划内维护通知。 Azure 还提供了一个时间窗口，你可以在方便时开始维护。 有关自我维护时段以及如何配置可用选项的信息，请参阅处理计划内维护通知。

某些工作负荷可能不能容忍 VM 死机或断开连接进行维护，哪怕只是几秒钟。 若要更好地控制所有维护活动，包括零影响和无重新启动更新，请参阅维护配置。 创建维护配置后，你可以选择跳过所有平台更新，等方便时再应用更新。 设置此自定义配置后，Azure 会跳过所有非零影响更新，包括无需重启的更新。 有关详细信息，请参阅通过维护配置管理平台更新。

操作系统 (OS) 映像升级

执行 OS 升级时，要有一个经过测试的黄金映像。 请考虑使用 Azure 共享映像库和 Azure Compute Gallery 发布自定义映像。 应制定一个流程，在每次发布者发布新映像时，以滚动方式升级一批实例。

在 VM 映像到达生命周期结束之前停用 VM 映像，以减少外围应用。

自动化流程应考虑到超量预配的额外容量。

可以使用 Azure 更新管理来管理 Azure 中 Windows 和 Linux 虚拟机的 OS 更新。Azure 更新管理器提供了一个 SaaS 解决方案，用于管理和控制跨 Azure、本地和多云环境的 Windows 和 Linux 计算机的软件更新。

来宾 OS 修补

Azure VM 提供自动 VM 来宾修补选项。 启用这项服务后，会定期对 VM 进行评估，并对可用的修补程序进行分类。 建议启用评估模式，以便对挂起的修补程序进行每日评估。 可以进行按需评估，但这不会触发应用修补程序。 如果未启用评估模式，请手动检测挂起的修补程序。

只有分类为严重或安全性的修补程序才会在所有 Azure 区域自动应用。 定义应用其他修补程序的自定义更新管理过程。

若要进行治理，请考虑需要在虚拟机规模集上自动修补 OS 映像。

自动修补会给系统带来负担，并且可能造成破坏，因为 VM 使用资源，并且可能在更新期间重启。 对于负荷管理，建议使用超量预配。 在不同的可用性区域中部署 VM，以避免并发更新，并为每个区域至少维护两个实例以实现高可用性。 同一区域中的 VM 可能会收到不同的修补程序，应随时间推移协调这些修补程序。

请注意与超量预配相关的成本的权衡。

运行状况检查是自动 VM 来宾修补过程的一部分。 这些检查验证修补应用程序是否成功，并检测问题。

如果实施应用修补程序的自定义流程，建议使用专用存储库作为修补程序源。 这样做可以更好地控制测试修补程序，以确保更新不会对性能或安全性产生负面影响。

有关详细信息，请参阅 Azure VM 的自动 VM 来宾修补。

可靠性

此体系结构使用可用性区域作为基础元素来解决可靠性问题。

在此设置中，单个 VM 绑定到单个区域。 如果发生故障，可以使用虚拟机规模集将这些 VM 轻松替换为其他 VM 实例。

此体系结构中的所有其他组件：

• 区域冗余，这意味着它们可以跨多个区域进行复制以实现高可用性，例如应用程序网关或公共 IP。
• 可在区域内复原，这意味着它们能够承受区域故障，例如 Key Vault。
• 跨区域或全局可用的区域或全局资源，例如 Microsoft Entra ID。

工作负荷设计应在应用程序代码、基础结构和操作中考量可靠性保证。 以下各节说明了一些策略，以确保工作负荷能够抵御故障，并能够在基础架构级别发生中断时进行恢复。

体系结构中使用的策略基于 Azure Well-Architected Framework 中给出的可靠性设计评审核对清单。 各部分都用该清单中的建议进行了注释。

由于未部署任何应用程序，因此应用程序代码中的复原能力超出了此体系结构的范围。 建议查看核对清单中的所有建议，并在工作负荷中采用这些建议（如果适用）。

根据用户流确定可靠性保证的优先级

在大多数设计中，都有多个用户流，每个流都有自己的一组业务需求。 并非所有这些流都需要最高级别的保证，因此建议将分段作为可靠性策略。 每个分段都可以独立管理，确保一个分段不会影响其他分段，并在每一层提供适当的复原能力级别。 这种方法还使系统具有灵活性。

在此体系结构中，应用层实现分段。 为前端层和后端层预配单独的规模集。 这种分离实现了每个层的独立扩展，允许基于其特定需求实现设计模式，并具有其他好处。

请参阅架构良好的框架：RE:02 - 识别和分级流的建议。

确定潜在的故障点

每个体系结构都容易出现故障。 通过故障模式分析练习，可以预测故障，并准备好缓解措施。 下面是此体系结构中的一些潜在故障点：

组件	风险	可能性	影响/缓解措施/备注	中断
Microsoft Entra ID	配置错误	中	Ops 用户无法登录。 无下游影响。 技术支持人员向标识团队报告配置问题。	无
应用程序网关	配置错误	中	在部署过程中发现配置错误。 如果这些错误发生在配置更新过程中，DevOps 团队必须回滚更改。 大多数使用 v2 SKU 的部署大约需要 6 分钟进行预配。 但是，根据部署类型的不同，可能需要更长的时间。 例如，跨多个具有多个实例的可用性区域的部署可能需要 6 分钟以上的时间。	完全
应用程序网关	DDoS 攻击	中	可能发生中断。 Microsoft 管理 DDoS（L3 和 L4）保护。 L7 攻击的潜在影响风险。	完全
虚拟机规模集	服务中断	低	如果存在触发自动修复的运行不正常的 VM 实例，则可能导致工作负荷中断。 依赖 Microsoft 进行修正。	潜在中断
虚拟机规模集	可用性区域中断	低	无效。 规模集作为区域冗余部署。	无

请参阅架构良好的框架：RE:03 - 执行故障模式分析的建议。

可靠性目标

若要做出设计决策，务必计算可靠性目标，例如工作负荷的复合服务级别目标 (SLO)。 这样做需要了解体系结构中使用的 Azure 服务提供的服务级别协议 (SLA)。 工作负荷 SLA 不得高于 Azure 保证的 SLA。 仔细检查每个组件，包括 VM 及其依赖项、网络和存储选项。

下面是一个示例计算，其中主要目标是提供近似复合 SLO。 虽然这是一个粗略的指导原则，但得出的结论应类似。 除非对体系结构进行了修改，否则不应为同一流获得更高的最大复合 SLO。

操作流

组件	SLO
Microsoft Entra ID	99.99%
Azure Bastion	99.95%

复合 SLO：99.94% | 每年停机时间：0d 5h 15m 20s

应用用户流

组件	SLO
应用程序网关	99.95%
Azure 负载均衡器（内部）	99.99%
使用高级存储的前端 VM（复合 SLO）	99.70%
使用高级存储的后端 VM（复合 SLO）	99.70%

复合 SLO：99.34% | 每年停机时间：2d 9h 42m 18s

在上述示例中，包括 VM 的可靠性和依赖项，例如与 VM 关联的磁盘。 与磁盘存储关联的 SLA 会影响整体可靠性。

计算复合 SLO 时存在一些挑战。 请务必注意，不同的服务层级可能附带不同的 SLA，其中通常包括设置可靠性目标的财务支持的保证。 最后，体系结构的某些组件可能没有定义 SLA。 例如，就网络而言，NIC 和虚拟网络没有自己的 SLA。

必须明确定义业务需求及其目标，并将其纳入计算中。 了解组织施加的服务限制和其他约束。 与其他工作负荷共享订阅可能会影响 VM 可用的资源。 允许工作负荷使用可用于 VM 的核心数有限。 了解订阅的资源使用情况可以帮助更有效地设计 VM。

请参阅架构良好的框架：RE:04 - 定义可靠性目标的建议。

冗余

此体系结构对多个组件使用区域冗余。 每个局部区域由一个或多个数据中心组成，这些数据中心配置了独立的电源、散热系统和网络。 在不同的区域中运行实例可以保护应用程序免受数据中心故障的影响。

• 虚拟机规模集分配指定数量的实例，并将它们均匀分布在可用性区域和容错域中。 此分配通过最大传播功能实现，我们建议这样做。 跨容错域分散 VM 实例可确保不会同时更新所有 VM。

  考虑一个场景，其中有三个可用性区域。 如果有三个实例，每个实例都被分配到不同的可用性区域，并放置在不同的容错域中。 Azure 保证在每个可用性区域中一次只更新一个容错域。 但是，可能存在这样一种情况，即跨三个可用性区域托管 VM 的所有三个容错域同时更新。 所有区域和域都会受到影响。 每个区域中至少有两个实例在升级期间提供缓冲区。

• 托管磁盘只能附加到同一区域中的 VM。 其可用性通常会影响 VM 的可用性。 对于单单区域部署，可将磁盘配置为冗余，以承受区域故障。 在此体系结构中，数据磁盘在后端 VM 上配置了区域冗余存储 (ZRS)。 它需要恢复策略来充分利用可用性区域。 恢复策略是重新部署解决方案。 理想情况下，可以在备用可用性区域中预先预配计算，以便从区域故障中恢复。

• 区域冗余应用程序网关或标准负载均衡器可以使用单个 IP 地址将流量路由到跨区域的 VM，从而确保即使发生区域故障也能保持连续性。 这些服务使用运行状况探测来检查 VM 可用性。 只要区域中的一个区域仍可正常运行，即使其他区域可能出现故障，路由也会继续。 但是，与区域内路由相比，区域间路由的延迟可能更高。

  此体系结构中使用的所有公共 IP 都是区域冗余的。

• Azure 提供区域复原服务，以提高可靠性，例如 Key Vault。

• Azure全局资源始终可用，并且可以在必要时切换到另一个区域，例如基本身份提供者 Microsoft Entra ID。

请参阅架构良好的框架：RE:05 - 设计冗余的建议。

缩放策略

为了防止服务级别降级和故障，请确保可靠的缩放操作。 水平缩放工作负荷（横向扩展）、垂直缩放（纵向扩展）或组合使用这两种方法。 使用 Azure Monitor 自动缩放预配足够的资源来支持应用程序的需求，而不会分配超出所需的容量并产生不必要的成本。

通过自动缩放，可以根据不同的事件类型（例如时间、计划或指标）定义不同的配置文件。 基于指标的配置文件可以使用内置指标（基于主机）或更详细的指标（来宾内 VM 指标），这些指标需要安装 Azure Monitor 代理来收集。 每个配置文件都包含横向扩展（增加）和横向缩减（减少）的规则。 请考虑基于设计配置文件探索所有不同的缩放方案，并评估它们是否存在可能导致一系列相反缩放事件的潜在循环条件。 Azure Monitor 将尝试通过等待冷却时间来缓解这种情况，然后再次扩展。

尽管灵活模式下的 Azure 虚拟机规模集支持异构环境，但不支持自动缩放多个配置文件。 如果计划对一种以上类型的 VM 使用自动缩放，请考虑创建不同的规模集来单独管理它们。

在创建或删除 VM 实例时，请考虑其他方面，如启动、正常关闭、安装工作负荷及其所有依赖项，以及磁盘管理。

有状态工作负荷可能要求对需要驻留在工作负荷实例之外的托管磁盘进行额外管理。 设计工作负荷，以便在缩放事件下进行数据管理，以实现工作负荷数据的一致性、同步性、复制和完整性。 对于这些方案，请考虑将预填充的磁盘添加到规模集。 对于使用缩放来防止访问数据时出现瓶颈的用例，请规划分区和分片。 有关详细信息，请参阅自动缩放最佳实践。

请参阅架构良好的框架：RE:06 - 设计可靠缩放策略的建议。

自我修复和可恢复性

在虚拟机规模集中启用自动实例修复，以便自动从 VM 故障中恢复。 将应用程序运行状况扩展部署到 VM，以支持检测无响应的 VM 和应用程序。 对于这些实例，会自动触发修复操作。

请参阅架构良好的框架：自我修复和自我保护的建议。

安全性

此体系结构说明了 Azure Well-Architected Framework 中给出的安全设计评审核对清单中提供的一些安全保证。 各部分都用该清单中的建议进行了注释。

安全性不仅指技术控制措施。 建议遵循整个核对清单，了解安全性支柱的运营方面。

细分

• 网络分段。 工作负荷资源放置在虚拟网络中，该虚拟网络提供与 Internet 的隔离。 在虚拟网络中，子网可用作信任边界。 将处理事务所需的相关资源合并到一个子网中。 在此体系结构中，虚拟网络基于应用程序逻辑分组以及用作工作负荷一部分的各种 Azure 服务的用途划分为子网。

  子网分段的优点是，可以在控制进出子网的流量的外围设置安全控制措施，从而限制对工作负荷资源的访问。

• 标识分段。 为不同的身份分配不同的标识，仅赋予足以执行其任务的权限。 此体系结构使用 Microsoft Entra ID 管理的标识来分段对资源的访问。

• 资源分段。 应用程序按层划分为单独的规模集，这可确保应用程序组件不会被并置。

请参阅架构良好的框架：SE:04 - 构建分段策略的建议。

标识和访问管理

建议使用 Microsoft Entra ID 对用户和服务进行身份验证和授权。

访问 VM 需要一个用户帐户，由 Microsoft Entra ID 身份验证控制，并由安全组提供支持。 此体系结构通过向所有 VM 部署 Microsoft Entra ID 身份验证扩展提供支持。 建议人类用户在其组织的 Microsoft Entra ID 租户中使用其企业标识。 此外，请确保不要跨职能共享任何基于服务主体的访问。

工作负荷资源（如 VM）通过使用分配给其他资源的托管标识来进行身份验证。 这些基于 Microsoft Entra ID 服务主体的标识自动管理。

例如，Key Vault 扩展安装在 VM 上，这些扩展会启动具有证书的 VM。 在此体系结构中，应用程序网关、前端 VM 和后端 VM 使用用户分配的托管标识来访问 Key Vault。 这些托管身份在部署期间进行配置，并用于针对 Key Vault 进行身份验证。 Key Vault 上的访问策略配置为仅接受来自先前托管身份的请求。

基线体系结构混合使用系统分配和用户分配的托管标识。 访问其他 Azure 资源时，需要使用这些标识才能将 Microsoft Entra ID 用于授权目的。

请参阅架构良好的框架：SE:05 - 标识和访问管理的建议。

网络控制措施

• 入口流量。 工作负荷 VM 不会直接公开到公共 Internet。 每个 VM 都有一个专用 IP 地址。 工作负荷用户使用应用程序网关的公共 IP 地址进行连接。

  通过与应用程序网关集成的 Web 应用程序防火墙可提供更高的安全性。 它具有检查入站流量并可以采取适当措施的规则。 WAF 跟踪 Open Web Application Security Project (OWASP) 漏洞，防范已知的攻击。

• 出口流量。 除了 VM 子网上的出站 NSG 规则之外，没有对出站流量实施控制措施。 建议所有出站 Internet 流量都流经单个防火墙。 此防火墙通常是组织提供的中央服务。 该用例显示在 Azure 登陆区域中的虚拟机基线体系结构中。

• 东-西向流量。 通过应用精细安全规则来限制子网之间的流量。

  网络安全组 (NSG) 的作用是根据 IP 地址范围、端口和协议等参数限制子网之间的流量。 应用程序安全组 (ASG) 分别部署在前端和后端 VM 上。 它们与 NSG 一起使用，以筛选传入和传出 VM 的流量。

• 操作流量。 我们建议通过 Azure Bastion 提供对工作负荷的安全操作访问，这样就不需要公共 IP。 在此体系结构中，该通信通过 SSH 进行，Windows 和 Linux VM 都支持这种通信。 对于这两种类型的 VM，通过使用相应的 VM 扩展，将 Microsoft Entra ID 与 SSH 集成。 通过该集成，支持通过 Microsoft Entra ID 对操作员的标识进行身份验证和授权。

  或者，使用单独的 VM 作为一个跳转盒，部署到其自己的子网，在其中安装所选的管理员和故障排除工具。 操作员通过 Azure Bastion 主机访问跳转盒。 然后，他们从跳转盒登录到负载均衡器后面的 VM。

  在此体系结构中，使用了 NSG 规则保护操作流量以限制流量，并在 VM 上启用了实时 (JIT) VM 访问。 Microsoft Defender for Cloud 的此功能允许对所选端口进行临时入站访问。

  为了增强安全性，请使用 Microsoft Entra Privileged Identity Management (PIM)。 PIM 是 Microsoft Entra ID 中的一项服务，可用于管理、控制和监视对组织中重要资源的访问。 PIM 提供基于时间和基于审批的角色激活，以降低所关注资源上出现的访问权限过度、不必要或滥用的风险。

• 与平台即服务 (PaaS) 服务的专用连接。 VM 与 Key Vault 之间使用专用链接通信。 此服务需要专用终结点，这些终结点位于单独的子网中。

• DDOS 防护。 请考虑在应用程序网关和 Azure Bastion 主机公开的公共 IP 上启用 Azure DDoS 防护，以检测威胁。 DDoS 防护还通过 Monitor 提供警报、遥测和分析。 有关详细信息，请参阅 Azure DDoS 防护：最佳做法和参考体系结构。

请参阅架构良好的框架：SE:06 - 有关网络和连接的建议。

加密

• 传输中的数据。 用户与应用程序网关公共 IP 之间的用户流量使用外部证书进行加密。 应用程序网关与前端 VM 之间的流量，以及前端 VM 和后端 VM 之间的流量使用内部证书进行加密。 这两个证书都存储在 Key Vault 中：

  • app.contoso.com：客户端和应用程序网关用于保护公共 Internet 流量的外部证书。
  • *.workload.contoso.com：基础结构组件用于保护内部流量的通配符证书。

• 静态数据。 日志数据存储在附加到 VM 的托管磁盘中。 这些数据在 Azure 上使用平台提供的加密自动加密。

请参阅架构良好的框架：SE:07 - 有关数据加密的建议。

机密管理

下载此体系结构的 Visio 文件。

Key Vault 提供对机密（包括 TLS 证书）的安全管理。 在此体系结构中，TLS 证书存储在 Key Vault 中，并在预配过程中通过应用程序网关和 VM 的托管标识检索。 初始设置后，这些资源仅在刷新证书时访问 Key Vault。

VM 使用 Key Vault VM 扩展自动刷新受监视的证书。 如果在本地证书存储中检测到任何更改，扩展将从 Key Vault 检索并安装相应的证书。 该扩展支持证书内容类型 PKCS #12 和 PEM。

请参阅架构良好的框架：SE:09 - 有关保护应用程序机密的建议。

成本优化

必须在考虑成本限制的情况下满足工作负荷需求。 体系结构中使用的策略基于 Azure Well-Architected Framework 中给出的成本优化设计评审核对清单。 本部分介绍用于优化成本的一些选项，并对核对清单中的建议进行了注释。

组件成本

选择针对工作负荷进行优化的 VM 映像，而不是使用常规用途映像。 在此体系结构中，为 Windows 和 Linux 选择了相对较小的 VM 映像，每个映像大小为 30 GB。 使用较小的映像，带有磁盘的 VM SKU 也较小，从而降低了成本，减少了资源消耗，加快了部署和启动时间。 一个好处是由于减少了外围面积而增强了安全性。

实现具有大小限制的日志轮换是另一种节省成本的策略。 它允许使用小型数据磁盘，从而降低成本。 此体系结构的实现使用 4 GB 磁盘。

使用临时 OS 磁盘还可以节省成本并提高性能。 这些磁盘被设计为使用你已经付费的 VM 资源，因为它们安装在随 VM 预配的缓存磁盘上。 它消除了与传统永久性磁盘相关的存储成本。 由于这些磁盘是临时磁盘，因此没有与长期数据存储相关的成本。

请参阅架构良好的框架：CO:07 - 有关优化组件成本的建议。

流成本

根据流的关键性选择计算资源。 对于设计用于承受不确定长度的流量，请考虑使用采用虚拟机规模集灵活业务流程模式的现成 VM。 此方法对于在低优先级 VM 上托管低优先级流有效。 此策略支持成本优化，同时仍能满足不同流的要求。

请参阅架构良好的框架：CO:09 - 有关优化流成本的建议。

缩放成本

如果主要成本驱动因素是实例数，那么通过增加 VM 的大小或提高性能来纵向扩展性价比更高。 这种方法可以在以下几个方面节省成本：

• 软件许可。 较大的 VM 可以处理更多工作负荷，从而可能减少所需的软件许可证数量。
• 维护时间：VM 数量更少、规模更大可以降低运营成本。
• 负载均衡：减少 VM 可以降低负载平衡的成本。 例如，在此体系结构中，有多层负载均衡，例如前端有应用程序网关，中间有内部负载均衡器。 如果需要管理的实例数量增加，负载平衡成本会增加。
• 磁盘存储。 如果存在有状态应用程序，则更多的实例需要附加更多的托管磁盘，从而增加存储成本。

请参阅架构良好的框架：CO:12 - 有关优化缩放成本的建议。

运营成本

自动 VM 来宾修补可降低手动修补的开销和相关维护成本。 这一操作不仅有助于使系统更加安全，而且还优化了资源分配，从而可提高整体成本效益。

请参阅架构良好的框架：CO:13 - 有关优化人员时间的建议。

部署此方案

GitHub 中提供了此参考体系结构的部署。

相关资源

有关特定 Azure 服务的详细信息，请参阅产品文档：

• Azure 虚拟机
• Azure 虚拟机规模集
• Azure 虚拟网络
• Azure 应用程序网关 Standard_v2
• Azure 负载均衡器
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

下一步

查看显示数据层选项的 IaaS 参考体系结构：

• Azure 上使用 SQL Server 的 Windows N 层应用程序