本文介绍了在将多层基础结构即服务 (IaaS) 应用部署到 Azure 时高可用性 (HA) 和灾难恢复 (DR) 选项的决策树和示例。
体系结构
工作流
可用性集 (AS) 可在多个独立的硬件节点之间分布 VM，从而在数据中心内提供 VM 冗余和可用性。 一部分 VM 无论在计划内还是计划外停机期间依然保持运行，因此整个应用仍然可用且可操作。
可用性区域 (AZ) 是跨 Azure 区域内数据中心的独特物理位置。 每个 AZ 皆可访问一个或多个具有独立电源、冷却和网络功能的数据中心，每个启用 AZ 的 Azure 区域至少具有三个单独的 AZ。 区域内 AZ 的物理隔离可保护已部署的 VM 免受数据中心故障的影响。
决策流程图反映了 HA 应用应尽可能使用 AZ 这一原则。 由于数据中心在发生故障后具有复原能力，因此，HA 可跨区域，进而跨数据中心提供 99.99% 以上的 SLA。
不同应用层的 AS 和 AZ 并不一定位于同一数据中心。 如果应用延迟是主要问题，则应使用具有 AZ 和 AS 的邻近放置组 (PPG) 将服务共置在单个数据中心内。
组件
备选方法
作为使用 Azure Site Recovery 的区域 DR 的备选方法，如果应用可以本机复制数据，则可以使用热/冷备用服务器（例如仅适用于 DR 的拉伸群集）实现多区域 DR。 此备选方法未在示例中具体详述，但可以添加到任何解决方案中。 请注意，区域之间的复制是异步进行，预计会丢失一些数据。
或者，如果你有自己的数据复制技术，则可以使用该技术创建用于 DR 的区域内次要区域。 根据工作负载所在的区域，还可以使用 Azure Site Recovery 将项复制到备用区域。若要查看区域可用性并阅读关于此功能的更多信息，请参阅为 Azure 虚拟机启用局部区域间的灾难恢复。
多区域 HA 虽可行，但需要全局负载均衡器，例如 Front Door 或流量管理器。 有关详细信息，请参阅在多个 Azure 区域中运行 n 层应用程序以确保高可用性。
方案详细信息
多层或 n 层体系结构在传统的本地应用中很常见，因此在将本地应用迁移到云或在开发同时适用于本地和云的应用时，这些体系结构成为自然之选。 n 层体系结构通常作为 IaaS 应用实现，分为逻辑层和物理层，具有顶层 Web 层或演示层、中间业务层和数据层。
在 IaaS n 层应用中，每个层都在一组单独的 VM 上运行。 Web 层和业务层无状态，这意味着这些层中所有 VM 都可以处理对应层中的任何请求。 数据层包含复制的数据库、对象存储或文件存储。 如果一个 VM 发生故障，每层中的多个其他 VM 均可提供复原能力，且负载均衡器可在 VM 之间分配请求。
可以向池中添加更多 VM，以此横向扩展层，并使用虚拟机规模集自动横向扩展相同的 VM。 由于使用负载均衡器，因此可以在不影响应用运行时间的情况下横向扩展层。
如果 IaaS 应用的服务级别协议 (SLA) 要求 99% 以上的可用性，则可以将 VM 放置在可用性集、可用性区域和邻近放置组中，从而为应用配置高可用性。 所选择的 HA 和 DR 解决方案取决于所需的 SLA、延迟注意事项和区域 DR 要求。
可能的用例
- 将 n 层应用从本地迁移到云。
- 在本地和云中部署 n 层应用。
- 配置适用于 IaaS 应用的高可用性和灾难恢复。
此解决方案可用于任何行业，包括以下方案：
- 公共部门应用程序
- 银行业（金融业）
- 医疗保健
注意事项
AZ 并非在所有 Azure 区域都可用。
在生成解决方案之前，请确定要使用的部署选项。 尽管部署后可以从一个选项转为使用另一个，但并不轻松。 必须删除 VM，然后从底层托管磁盘重新创建 VM，此过程相当复杂。
请确保可以将应用程序映射到所选的解决方案。 许多应用层复原能力模式和设计超出了此决策树的范围。
三种情况可能会导致 Azure VM 重启：计划外硬件维护、意外停机和计划内维护。 有关这些事件以及降低其影响的 HA 最佳做法的详细信息，请参阅了解 VM 重启、维护与停机。
单个 VM
如果应用无需 99.9% 以上的可用性，则无需为其配置 HA，并且可以部署单个 VM。 可以使用虚拟机规模集自动横向扩展相同的 VM。 在不指定区域的情况下部署单个 VM，因此这些 VM 可分布于整个区域中。 如果使用 Azure 高级 SSD 盘，这些应用的 SLA 可达到 99.9%。
单个 VM 使用内置于所有 Azure 数据中心的默认服务修复功能。 对于可预测的故障，此功能通常使用实时迁移，但如果发生不可预测的事件，VM 可能会重新启动或不可用。
高可用性
如果应用需要 99.9% 以上的 SLA，则应对应用进行设计，以实现 HA。 尽可能使用 AZ，因为它们可提供数据中心容错功能。 可以使用 AS 代替 AZ，但由于 AS 无法容忍数据中心故障，因此使用 AS 会将可用性从 99.99% 降低至 99.95%。
AZ 通过快速故障转移功能在每层使用主动-主动、主动-被动或同时使用两种 HA 级别，适用于众多群集应用方案，比如 AlwaysOn SQL 群集。 由于跨区域网络具有低延迟特点，因此任何数据库管理系统 (DBMS) 节点之间都可以进行同步复制。 还可以跨区域运行拉伸群集配置，该配置具有更高的延迟并支持异步复制。
如要使用基于 VM 的群集仲裁程序（例如文件共享见证），请将其放置在第三个 AZ 中，以确保在任何一个区域发生故障时不会丢失仲裁。 或者，可以在另一个区域使用基于云的见证。
AZ 中所有 VM 都位于单个容错域 (FD) 和更新域 (UD) 中，这意味着它们共享公用电源和网络交换机，并且可以同时重新启动。 如果跨不同的 AZ 创建 VM，则 VM 会有效地分布在不同的 FD 和 UD 中，因此不会全部发生故障或同时重新启动。 如果希望拥有区域内冗余 VM 和跨区域 VM，则应将区域内 VM 放置在 PPG 的 AS 中，以确保它们不会全部立即重新启动。 即使对于目前并不冗余的单实例 VM 工作负载，仍可以选择使用 PPG 中的 AS，以实现今后增长并确保灵活性。
若要跨 AZ 部署虚拟机规模集，不妨考虑使用业务流程模式（目前为公共预览版），可允许将 FD 和 AZ 相结合。
借助具有区域内 PPG 的 AZ，Azure 可实现最低网络延迟，并且得益于多数据中心复原能力，SLA 至少为 99.99%。 尽可能在 VM 上使用加速网络。
利用此解决方案时，可能会发生如下情况：在一个区域的 VM 上运行的服务需要与另一区域中的服务进行交互。 例如，可能存在跨区域的主动-主动 Web 层和主动-被动数据库层。 某些请求会跨区域，从而造成延迟。 尽管跨区域延迟非常低，但若要确保尽可能低的延迟，请将应用层之间的所有网络通信保持在同一区域内。
延迟注意事项
除上述因素外，网络延迟还取决于已部署的 VM 之间的物理距离。 如果应用需要非常低的层间延迟，则可以将其部署到单个数据中心，并针对各层使用带有 AS 的 PPG。 请尽可能在 VM 上使用加速网络。 借助此方案，Azure 可实现最低网络延迟，SLA 可达 99.95%。
可以使用以下工具更好地了解各种方案的延迟条件：
- 若要测试 VM 之间的延迟，请参阅测试 VM 网络延迟。
- 若要测试区域之间的延迟，请使用 AvZone 延迟测试。 此测试有助于确定订阅延迟最低的逻辑区域。
- 若要测试 Azure 区域之间的延迟，请前往 http://www.azurespeed.com/。 在考虑区域之间的异步复制时，此定期更新的工具非常有用。
灾难恢复
对于 DR，应考虑可用性（应用在正常状况下持续运行的能力）和数据持续性（发生灾难时保留数据的能力）。
HA 故障转移应快速进行、不会丢失数据，且仅对服务产生有限影响。 相比之下，传统 DR 故障转移可能具有关联恢复时间目标 (RTO) 和恢复点目标 (RPO)且持续较长时间，并且是异步进行，可能会丢失数据。
可以将不同的可用性区域用于灾难恢复解决方案，从而利用可用性区域的优势来实现高可用性和灾难恢复。 可用性区域足够近，可与其他可用性区域建立低延迟连接（往返延迟小于 2 毫秒）。 不过，它们之间的距离又要足够远，从而降低本地故障或天气同时影响多个可用性区域的可能性。 对于关键任务工作负荷，除了使用多个可用性区域外，还应考虑使用多个区域的解决方案。
使用 Azure Site Recovery，可将 VM 复制到另一个 Azure 区域，以满足区域灾难恢复和业务连续性需求。 可以使用 Azure Site Recovery 在源区域中断的情况下恢复应用，或定期进行灾难恢复演练以确保满足合规性要求。
如果应用支持 Azure Site Recovery，则可视乎应用的严重程度，提供区域 DR 解决方案，以增强保护。 但是，跨区域、跨数据中心的 HA 本身可能足以提供保护，因为如果应用可以从数据中心故障中完全复原，便不应出现停机或数据丢失情况。
成本优化
在 AZ 中部署的 VM 无需额外费用， 但可能需要额外支付 AZ 间 VM 到 VM 的数据传输费用。 有关详细信息，请参阅带宽定价页。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- 肖恩·克鲁彻 | 高级顾问