适用对象：
NoSQL
MongoDB
Cassandra
Gremlin
表
Azure Cosmos DB 在高可用性配置方面与许多其他 Azure 服务不同。 Azure Cosmos DB 帐户配置为多区域设置，主动在选定区域间进行数据复制，而不是依赖客户为了增强恢复能力而部署的次级实例。 在发生区域性服务中断期间，可以启动故障转移（脱机区域）到另一个区域来维护可用性。
当 Azure Cosmos DB 帐户故障转移时，服务名称保持不变。 如果公共终结点用于连接，系统仍可以通过同一 DNS 解析访问服务，而不考虑其故障转移状态。 即使只有一个区域或一部分服务受到中断的影响，DNS 解析也能无缝地运行。 这种内置的复原能力减少了 Azure Cosmos DB 所需的业务连续性和灾难恢复（BCDR）任务数。
对于使用专用终结点的客户，需要其他配置来确保故障转移支持。 本文档提供了多区域 Azure Cosmos DB 帐户的示例体系结构，该帐户使用专用终结点来保护网络，并详细介绍不同 BCDR 方案的必要步骤。
示例体系结构
此体系结构利用主要区域和次要区域来支持故障转移方案的主动/主动和主动/被动。 每个区域都包含一个网络，其中部署了 Azure Cosmos DB 帐户和其他工作负荷解决方案。 多区域 Azure Cosmos DB 帐户在这两个区域中都有专用终结点，以确保无缝连接。 此设置允许应用程序连接到最近的专用终结点，从而优化性能，同时在故障转移事件期间保持复原能力。
这两个专用终结点不能对同一终结点使用相同的专用 DNS 区域。 因此，每个区域都有自己的专用 DNS 区域。 每个区域都连接到该特定区域的中心网络。 此设计利用 DNS 转发器方案 提供解析。 因此，无论访问专用终结点的虚拟机（VM）区域如何，都有一个本地终结点可用于连接到 Azure Cosmos DB。 对于源自数据中心的连接，VPN 连接将建立到相应区域中的中心网络。
对于 DNS 解析，每个数据中心将配置条件转发以选择两个 DNS 解析器服务器集之一，确保解析到最近的网络位置以优化连接性能。
体系结构概念
Azure Cosmos DB 支持 每个帐户的多个专用终结点，使你能够跨不同的虚拟网络创建区域分布式终结点。 例如，每个区域中都有一个 Azure Cosmos DB 专用终结点，每个终结点都独立提供来自其各自虚拟网络的流量。
在传统的中心辐射型拓扑中，由于专用 DNS 区域限制，此设置不太常见，每个区域只能包含每个 DNS 名称的一条记录。 将专用终结点链接到专用 DNS 区域后，其他区域中的任何其他终结点都必须使用 单独的专用 DNS 区域 以避免 DNS 冲突。
此外，Azure Cosmos DB 专用终结点不是区域绑定的。 可以在一个区域中部署专用终结点，以访问托管在不同区域中的 Azure Cosmos DB 帐户，从而启用灵活的网络配置。
为了确保正确解析，每个区域都应有自己的特定于区域的专用 DNS 区域映射到本地终结点。 此设置允许各个区域内的资源正确引导流量。 虽然在 Azure Cosmos DB 帐户所在的同一区域中部署专用终结点通常是成本与延迟优化的首选，但支持多区域专用终结点对于高可用性和区域故障转移方案至关重要，即使一个区域不可用，也可确保持续进行专用访问。
故障转移方案
此拓扑支持以下方案，每个方案都有自己的 DNS 故障转移注意事项。
| Scenario | Description | DNS 注意事项 |
|---|---|---|
| 场景 1 - Azure Cosmos DB 故障转移 | 主要区域内的服务中断需要 Azure Cosmos DB 切换到次要区域。 | 无需更改 |
| 方案 2 - 其他服务故障转移 | 服务中断会影响主要区域的其他服务，但 Azure Cosmos DB 不需要故障转移。 | 如果中断影响主要区域中托管的 DNS 服务器，则需要将本地的条件转发器更新到次要区域。 |
| 方案 3 - 整个区域中断 | 重大服务中断会影响多个服务，这要求 Azure Cosmos DB 和其他服务进行故障转移。 | 需要将本地 DNS 中的条件转发器更新到次要区域。 |
| 方案 4 - 多写入配置 | Azure Cosmos DB 和其他服务跨多个区域在主动/主动配置中运行。 | 无需更改 |
方案 1：Azure Cosmos DB 故障转移
在这种情况下，Azure Cosmos DB 帐户出现问题，需要将其故障转移到次要区域。 由于 Azure Cosmos DB 旨在实现高可用性，因此区域停机并不常见，但仍应做好应对停机的计划。
触发 Azure Cosmos DB 强制故障转移（脱机区域） 时，它会故障转移到次要区域，网络路由保持不变。 无需修改 DNS，每个区域将继续使用其本地专用终结点与 Azure Cosmos DB 通信。 故障转移后（脱机区域）– 服务将如图所示地运行：
主区域再次正常运行后，Azure Cosmos DB 帐户会故障回复，还原原始写入区域，而无需对网络配置进行任何更改。
方案 2：其他服务故障转移
在此方案中，问题不在于 Azure Cosmos DB 帐户，而是连接到 Azure Cosmos DB 帐户的服务，例如应用程序服务、虚拟机或容器。 这些服务需要按照各自的灾难恢复计划切换到次要地区。
例如，虚拟机可以使用 Azure Site Recovery 提前复制工作负荷，而可以使用 CI/CD 管道或平台原生缩放功能将应用程序服务重新部署到次要区域。
服务在次要区域中处于活动状态后，即可立即通过本地区域专用终结点连接到 Azure Cosmos DB。 Azure Cosmos DB 无需进行任何更改即可支持此功能，这些终结点已预配，允许从多个区域无缝访问。
如果有通过 VPN 连接的本地网络，只要通过集线器进行的 DNS 解析保持正常，连接就会继续。 但是，如果中心的 DNS 基础结构受到影响（例如，由于 VM 或 DNS 服务中断），则可能需要重新配置本地 DNS 转发器以指向次要区域的 DNS 解析程序，直到主要区域还原为止。
故障转移后，次要区域中的服务将按如下所示运行：
还原主要区域后，可以故障回复服务，并且可以还原本地系统的任何临时 DNS 更改。
方案 3：整个区域中断
在这种情况下，区域中断严重，Azure Cosmos DB 帐户和依赖应用程序服务必须故障转移到次要区域。
此故障转移遵循与前两种方案类似的组合模型：Azure Cosmos DB 帐户故障转移到其次要写入区域，并在次要区域中重新部署或激活 Azure 服务（例如 Web 应用、VM 或容器）。 主要区域实际上不可正常运行，但体系结构可确保服务继续从次要区域运行，且中断最少。
与前面的情况一样，如果主中心网络无法处理 DNS 解析，例如由于 DNS 基础结构中断，则应暂时更新本地条件 DNS 转发器，以使用次要区域中的解析程序来维护专用终结点连接。
故障转移后，体系结构的运作状况如下所示：
还原主要区域后，可以故障回复工作负荷，本地 DNS 设置可以还原到其原始配置。
方案 4：多写入配置
在此方案中，Azure Cosmos DB 配置为多区域写入，允许它同时接受多个区域中的写入。 一个区域发生中断，影响本地应用程序服务，但由于其分布式性质，Azure Cosmos DB 在全球仍可用。
由于多写入帐户有自己的区域读取/写入终结点，因此不需要 Azure Cosmos DB 故障转移。 应用程序只需轻松故障转移到另一个处于活动状态的区域，其中服务保持运行，并且可以通过区域专用终结点继续读取和写入 Azure Cosmos DB。 此方案中的关键行为：
- 无需 Azure Cosmos DB 故障转移 - 其他区域将继续无缝地处理写入操作。
- 应用程序服务（例如，应用服务、AKS 或 VM）在备用区域中恢复或扩容。
- 区域专用终结点已预配，无需 DNS 更改即可立即建立连接。
- 只要本地客户端的 DNS 转发器可以解析为有效的专用终结点，本地客户端就可以继续运行。 如果失败区域中的 DNS 服务受到影响，它们应暂时指向活动区域中的 DNS 解析程序。
主要区域恢复后，应用程序服务可以根据需要进行回切。 无需对 Azure Cosmos DB 进行更改。 平台会继续按配置在所有写入区域复制数据。
