Azure DNS 中的可靠性

本文包含有关 azure DNS 跨区域灾难恢复和业务连续性 支持的详细信息。

跨区域灾难恢复和业务连续性

灾难恢复（DR）是指组织用来从高影响事件（例如自然灾害或导致停机和数据丢失的部署）中恢复的做法。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始创建灾难恢复计划之前，请参阅 有关设计灾难恢复策略的建议。

对于 DR，Azure 使用 共同责任模型。 在此模型中，Microsoft确保基线基础结构和平台服务可用。 但是，许多 Azure 服务不会自动复制数据，也不会从失败的区域回退到另一个已启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 在 Azure 平台即服务 (PaaS) 产品/服务上运行的大多数服务都提供支持 DR 的功能和指南。 可以使用服务特定的功能来支持快速恢复，从而帮助制定灾难恢复计划。

用于灾难恢复的 Azure DNS 故障转移解决方案使用标准的 DNS 机制切换到备份站点。 通过 Azure DNS 实现的手动选项与冷备用或引导灯方法结合使用时效果最佳。

由于 DNS 服务器位于故障切换或灾难影响区域之外，因此不会受到任何停机的影响。 只要操作员在灾难期间保持网络连接，并且能够执行切换，就可以设计一个简单的故障转移方案。 如果解决方案已脚本化，必须确保运行脚本的服务器或服务也不受影响生产环境的问题影响。 此外，该 DNS 区域较低的 TTL 可防止解析器长时间缓存，从而使客户能够在 RTO 规定的时间内访问该网站。 对于冷备用和微流量预热方案，由于可能需要进行一些预热及其他管理操作，因此在进行切换前还应预留充足的时间。

若要了解如何使用 Azure 门户创建 Azure 专用 DNS 区域，请参阅 快速入门：使用 Azure 门户创建 Azure 专用 DNS 区域。

若要使用 Azure 门户创建 Azure DNS 专用解析程序，请参阅 快速入门：使用 Azure 门户创建 Azure DNS 专用解析程序。

多区域地理位置中的灾难恢复

在构建灾难恢复架构时，有两个技术方面需要考虑：

• 使用部署机制在主环境和备用环境之间复制实例、数据和配置。 此类灾难恢复可以通过 Azure Site Recovery 原生完成，请参阅 Azure Site Recovery 文档，还可通过 Azure 合作伙伴设备/服务（如 Veritas 或 NetApp）完成。

• 开发一种将网络/Web 流量从主站点转移到备用站点的解决方案。 这种灾难恢复可通过 Azure DNS、Azure 流量管理器 (DNS) 或第三方全局负载均衡器实现。

本文重点介绍 Azure DNS 灾难恢复规划。

设置灾难恢复和故障检测

用于灾难恢复的 Azure DNS 手动故障转移解决方案使用标准的 DNS 机制通过故障转移复原到备份站点。 通过 Azure DNS 实现的手动选项在与冷备用或引导灯方法结合使用时效果最佳。

图：使用 Azure DNS 执行手动故障转移

为此解决方案做出了如下假设：

• 主终结点和辅助终结点使用不经常变化的静态 IP。 假设主站点的 IP 为 100.168.124.44，辅助站点的 IP 为 100.168.124.43。
• 主站点和辅助站点均有对应的 Azure DNS 区域。 假设主站点的终结点为 prod.contoso.com，备份站点的终结点为 dr.contoso.com。 此外，还有主应用程序的 DNS 记录 www.contoso.com。
• TTL 等于或低于组织中设定的 RTO SLA。 例如，如果企业将应用程序灾难响应 RTO 设置为 60 分钟，TTL 应短于 60 分钟，最好是越低越好。 设置 Azure DNS 手动故障转移的具体步骤如下：
  • 创建 DNS 区域
  • 创建 DNS 区域记录
  • 更新 CNAME 记录

1. 创建 DNS 区域（例如，www.contoso.com），如下所示：

   

   图：在 Azure 中创建 DNS 区域

2. 在此区域内，创建三条记录（例如 www.contoso.com、prod.contoso.com 和 dr.contoso.com），如下所示。

   

   图：在 Azure 中创建 DNS 区域记录

   在这种情况下，站点 www.contoso.com 的 TTL 为 30 分钟，远低于所述 RTO，并且指向生产站点 prod.contoso.com。 此配置适用于常规业务操作。 prod.contoso.com 和 dr.contoso.com 的 TTL 已设置为 300 秒或 5 分钟。 可以使用 Azure 监视服务（如 Azure Monitor 或 Azure 应用 Insights）或任何合作伙伴监视解决方案（例如 Dynatrace）。 甚至可以使用自行开发的解决方案来监视或检测应用程序级或虚拟基础结构级故障。

3. 检测到故障后，立即将记录值更改为指向 dr.contoso.com，如下所示：

   

   图：在 Azure 中更新 CNAME 记录

   在 30 分钟内，大多数解析程序都会刷新缓存的区域文件，任何指向 www.contoso.com 的查询都会重定向到 dr.contoso.com。 还可以运行下面的 Azure CLI 命令来更改 CNAME 值：

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   这一步可以手动执行，也可以自动执行。 若要手动完成，可以使用控制台或 Azure CLI。 Azure SDK 和 API 可用于自动更新 CNAME，无需手动干预。 可以通过 Azure Functions、在第三方监控应用程序中，甚至从本地环境中构建自动化。

后续步骤

• Azure 中的可靠性
• 详细了解 Azure 流量管理器。
• 详细了解 Azure DNS。