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 上启动，而不会延迟或需要人工干预。 以下是有关自动化的建议：

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

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

  • Azure Monitor 代理 (AMA) 从来宾 OS 收集监视数据，并将其传送到 Azure Monitor。
  • Azure 自定义脚本扩展（Windows、Linux）版本 2 下载脚本并在 Azure 虚拟机 (VM) 上运行。 此扩展对于自动化部署后配置、软件安装或任何其他配置或管理任务非常有用。
  • Azure Key Vault 虚拟机扩展（Windows，Linux）通过检测更改并安装相应的证书，自动刷新存储在 Key Vault 中的证书。
  • 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 可以通过 cloud-init 在各种 Azure 提供的 VM 映像上使用轻量型的本机所需状态配置。 配置使用 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 的逻辑分组。 分组中的 VM 类型可以相同，也可以不同。 它们允许使用标准 Azure VM API 和命令管理计算机、网络接口和磁盘的生命周期。

灵活的业务流程模式有助于大规模操作，并帮助做出精细的扩展决策。

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

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

磁盘

若要运行 OS 和应用程序组件，请将存储磁盘附加到 VM。 请考虑对 OS 使用临时磁盘，为数据存储使用托管磁盘。

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

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

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

• VM SKU 限制。 磁盘在其连接的 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 指标
密钥保管库	密钥保管库指标和日志说明	Key Vault 警报
标准负载均衡器	负载均衡器日志和指标	负载均衡器警报
公共 IP 地址	公共 IP 地址指标和日志说明	公共 IP 地址指标警报
虚拟网络	虚拟网络指标和日志参考	虚拟网络警报
虚拟机和虚拟机规模集	VM 指标和日志参考	VM 警报和教程
Web 应用程序防火墙	Web 应用程序防火墙指标和日志说明	Web 应用程序防火墙警报

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

虚拟机

启动 Azure 启动诊断可通过收集串行日志信息和屏幕截图，观察 VM 在启动期间的状态。 在此体系结构中，可以通过 Azure 门户 和 Azure CLI vm boot-diagnostics get-boot-log command 命令访问该数据。 数据由 Azure 管理，你无权控制或访问基础存储资源。 但是，如果业务需求需要更多的控制，则可以配置自己的存储帐户来存储启动诊断。

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

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

网络

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

托管磁盘

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

• Azure 平台角度表示指示 Azure 服务的指标，而不考虑连接到它的工作负荷。 可以个别或同时查看所有 VM 连接磁盘的磁盘性能指标（IOPS 和吞吐量）。 使用存储 IO 利用率指标对潜在的磁盘上限进行故障排除或发出警报。 如果使用突发进行成本优化，请监视额度百分比指标，以确定进一步优化的机会。

• 来宾操作系统的角度表示工作负荷操作员将查看的指标，而不考虑基础磁盘技术。 对于附加磁盘的关键指标（例如，已用逻辑磁盘空间），以及 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 层应用程序