Compartir a través de

Azure DNS 中的可靠性

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

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

灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件(例如自然灾害或部署失败)中恢复。 不管灾难的原因是什么,最好的补救措施就是一个定义全面且经过测试的 DR 计划,以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前,请参阅设计灾难恢复策略的建议

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

用于灾难恢复的 Azure DNS 故障转移解决方案使用标准的 DNS 机制通过故障转移复原到备份站点。 Azure DNS 手动故障转移解决方案与冷备用或指示灯方法一起使用时效果最佳。

由于 DNS 服务器不在故障转移或灾难区域内,因此不受任何故障时间影响。 只要操作员在灾难期间具有网络连接,就可以构建简单的故障转移方案,并且可以进行翻转。 如果解决方案已脚本化,必须确保运行脚本的服务器或服务也不受影响生产环境的问题影响。 此外,该区域的低 TTL 可防止解析程序长时间缓存长,从而允许客户访问 RTO 中的站点。 对于冷备用和指示灯方法,由于可能需要进行一些预热和其他管理活动,还应在翻转前留出足够长的时间。

注意

即使没有显式将虚拟网络对等互连,Azure 专用 DNS 区域也支持在跨 Azure 区域的虚拟网络之间进行 DNS 解析。 然而,所有虚拟网络都必须链接到专用 DNS 区域。

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

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

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

创建灾难恢复体系结构时,有以下两个技术现状:

  • 使用部署机制在主环境和备用环境之间复制实例、数据和配置。 这种类型的灾难恢复可通过 Microsoft Azure 合作伙伴设备/服务(例如 Veritas 或 NetApp)使用 Azure Site Recovery 在本机完成(请参阅 Azure Site Recovery 文档)。

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

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

设置灾难恢复和中断检测

用于灾难恢复的 Azure DNS 手动故障转移解决方案使用标准的 DNS 机制通过故障转移复原到备份站点。 Azure 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 区域的屏幕截图。

    图:在 Azure 中创建 DNS 区域

  2. 在此区域内,创建三条记录(例如,www.contoso.com、prod.contoso.com 和 dr.consoto.com),如下所示。

    创建 DNS 区域记录的屏幕截图。

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

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

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

    更新 CNAME 记录的屏幕截图。

    图:在 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 函数或在第三方监视应用程序内设置自动更新,甚至可以在本地设置。

后续步骤