引言
在我之前的博客中，我介绍了如何使用Infoblox Universal DDI™在AWS上通过Cloud WAN部署Anycast DNS。该设计展示了企业如何通过将集中式Infoblox管理与AWS的全球网络骨干网相结合，构建全球可用且具有弹性的DNS结构。
如承诺的那样，在第二部分中，我们将重点转向Microsoft Azure。与我合作的许多客户都运营混合或多云环境，我看到的常见模式是，在AWS中遇到的相同DNS挑战也出现在Azure中。随着他们在多个Azure区域扩展，相同的需求依然存在：
- 确保在任何地方都有一致的DNS解析
- 实现自动化的弹性和故障转移（即无需静态路由变通方案）
- 保持整体设计操作简单且可扩展
随着组织现代化应用程序并采用分布式架构，这些需求变得更加紧迫。DNS位于网络功能的核心，Anycast是一种经过验证的方式，可在全球范围内提供低延迟解析和高可用性。
本文介绍了如何使用Azure Virtual WAN作为骨干网，在Azure中部署Infoblox NIOS-X和Anycast DNS。我构建的实验室镜像了AWS设计，但使用了Azure原生的Azure Virtual WAN功能。这为我们提供了清晰的多区域路由、自动路由传播和内置弹性，无需额外的网络构造。
为什么Azure Virtual WAN是关键
在深入设置之前，重要的是要强调为什么Azure Virtual WAN是此架构的骨干。传统的Azure中心和分支设计依赖于手动VNet对等或自定义VPN/ExpressRoute链路来互连区域。这可以工作，但在涉及Anycast路由时，规模扩大后很快就会变得复杂。Azure Virtual WAN提供了一个基于策略的托管全局传输骨干，简化了区域间连接、路由和扩展。它消除了在VNet和中心之间进行复杂手动对等的需要，为企业提供了一种统一的方式来安全高效地在Azure区域之间路由流量。以下是配置Virtual WAN时涉及的高级概述：
- 部署单个Azure Virtual WAN作为全局构造
- 在该Azure Virtual WAN下创建区域虚拟中心
- Microsoft使用其全球骨干网自动连接中心
- 中心之间的路由传播是原生发生的
- VNet连接到最近的中心，路由表和标签以结构化方式控制传播
此模型非常适合Anycast DNS。每个区域可以通过其本地中心通告相同的Anycast地址，Azure Virtual WAN自动将该路由分发到所有其他中心和VNet。无需IPsec隧道，无需手动边界网关协议（BGP）路由表更新，无需中心对等维护。这正是DNS所需的全球骨干网。
实验室拓扑
实验室包括两个区域：
- 德国中西部
- 法国中部
在每个区域中，我部署了：
- 托管两个NIOS-X设备的共享服务VNet
- 带有测试虚拟机（VM）的分支VNet
- 作为单个全局Azure Virtual WAN一部分的虚拟中心
Anycast IP是10.100.100.10/32。每对NIOS-X设备将此地址通告给其本地中心。由于每个区域通告相同的Anycast地址，我们依赖Azure Virtual WAN的动态路由来确保流量始终流向最近的NIOS-X实例。
图1. 通过Azure Virtual WAN互连的德国中西部和法国中部的高级拓扑
在Azure中部署Infoblox NIOS-X
此设计的基础是在多个Azure区域的共享服务VNet中部署Infoblox NIOS-X设备。这些设备充当环境的DNS服务器，并通过Universal DDI门户进行集中管理。部署遵循标准的Azure VM工作流，并使用Infoblox加入令牌进行无缝注册和管理。
部署步骤：
- 使用适当的Azure Marketplace映像，在每个目标区域的共享服务VNet中部署NIOS-X虚拟机
- 在初始化期间应用加入令牌，确保设备自动注册到Universal DDI门户
- 通过确认新的NIOS-X实例出现在Universal DDI门户的"配置→服务器"下，验证上线
图2. Universal DDI门户显示NIOS-X设备已注册并在线（配置→服务器）
为什么这很重要：此自动上线工作流消除了手动注册步骤，并确保新设备在跨区域时在Universal DDI中一致可见，减少了部署时间和人为错误的机会。
Azure Virtual WAN中心、VNet连接和路由表
骨干是单个Azure Virtual WAN，每个区域有一个中心。
- 德国中心：10.110.0.0/22
- 法国中心：10.110.4.0/22
每个共享服务VNet和分支VNet使用虚拟网络连接连接到区域中心。
为了保持路由结构化，我每个中心使用了两个路由表：
- 用于中心和共享服务连接的默认路由表
- 用于应用程序VNet的自定义分支路由表
这种分离使我们能够更好地控制哪些路由传播到工作负载，并确保Anycast路由仅分发到需要的地方。由于Azure Virtual WAN自动跨区域同步中心路由，无需在德国和法国中心之间配置任何手动对等。与传统设计相比，这是一个重大的操作胜利。
图3. Azure Virtual WAN概述显示在单个Azure Virtual WAN下部署的两个区域中心，一个在德国中西部，一个在法国中部。此全球骨干是区域间连接和Anycast路由传播的基础。
图4. Azure Virtual WAN配置显示在德国中西部和法国中部区域建立到中心的虚拟网络连接。每个区域都有一个共享服务VNet和一个分支VNet连接到其各自的中心。
与Azure Virtual WAN中心的BGP对等
Azure Virtual WAN中心具有原生BGP支持。这显著简化了设置。在每个中心中，我创建了两个eBGP对等，一个用于共享服务VNet中的每个NIOS-X设备。
德国中心示例：
- Azure Virtual WAN中心ASN：65515，IP：10.110.0.133和10.110.0.134
- NIOS-X1 ASN：64581，IP：10.104.0.4
- NIOS-X2 ASN：64582，IP：10.104.1.4
一旦配置，中心与两个设备建立BGP会话。每个NIOS-X设备通告10.100.100.10/32 Anycast前缀，该前缀出现在中心的有效路由表中，下一跳类型为HubBGPConnection。Azure Virtual WAN自动将此路由传播到法国中心和所有关联的分支路由表。分支使用自定义分支路由表，确保它们接收Anycast地址，并可以使用其最近的中心解析DNS。
图5. 德国中西部虚拟中心的BGP对等视图显示配置了唯一ASN的两个NIOS-X对等。两个对等都处于已配置状态，表明BGP会话已建立，并且Anycast路由正在通告到中心。
在Infoblox中配置Anycast DNS
连接就绪后，我们在Universal DDI中启用了Anycast DNS。
必须在Infoblox门户中为每个NIOS-X设备执行以下步骤：
- 在"配置→服务部署→协议服务"下启用DNS服务
- 在"配置→网络→Anycast"下创建Anycast配置
- 创建Anycast服务并将其与DNS关联
- 配置BGP对等以将Anycast路由通告到Azure Virtual WAN骨干
图6. Universal DDI启用DNS服务（配置→服务部署→协议服务→创建服务→DNS）
图7. Universal DDI Anycast配置（网络→Anycast→创建Anycast配置）
图8. Universal DDI Anycast服务创建（配置→服务部署→协议服务→创建服务→Anycast）
图9. Universal DDI Anycast服务的BGP对等配置
图10. Universal DDI Anycast IP显示绿色/活动
验证
我们在两个Azure区域验证了端到端设计，以确保Anycast DNS通过Azure Virtual WAN无缝工作。
执行的检查：
- 从NIOS-X学习的路由在跨区域的Azure Virtual WAN路由表中可见
- NIOS-X设备与虚拟中心路由器之间建立了BGP会话
- Anycast IP 10.100.100.10/32通过Azure Virtual WAN在两个区域之间传播
- 来自分支VNet的DNS查询成功通过两个区域的Anycast IP解析
图11. 德国中西部中心、分支路由表中的有效路由，显示通过BGP学习的Anycast地址10.100.100.10/32
图12. 法国中部中心、分支路由表中的有效路由，显示通过BGP学习的Anycast地址10.100.100.10/32
图13. 德国中西部中心的BGP对等配置显示NIOS-X设备与Azure Virtual WAN中心路由器对等
图14. 法国中部中心的BGP对等配置显示NIOS-X设备与Azure Virtual WAN中心路由器对等
图15. 德国中西部分支VNet中的VM，显示成功ping通Anycast IP 10.100.100.10并通过Anycast进行DNS解析
图16. 法国中部分支VNet中的VM，显示成功ping通Anycast IP 10.100.100.10并通过Anycast进行DNS解析
为什么这很重要：此验证确认Anycast DNS在跨区域时无缝运行，路由由Azure Virtual WAN处理，弹性由BGP提供。
结论
此实验室演示了如何在Azure中部署Infoblox Universal DDI和NIOS-X，以在多个区域之间提供基于Anycast的弹性DNS结构。通过与Azure Virtual WAN集成，企业可以利用单一的、基于策略的骨干网，使DNS在全球可达、高度可用，并且在规模上操作更简单。
结果不仅仅是改进的DNS解析。它代表了一种现代的、云原生的网络架构，支持企业在敏捷性、安全性和全球覆盖方面的目标，同时保留了传统本地部署的经过验证的设计原则。
实验室和Terraform代码
为了帮助您快速入门，我已发布构建此实验室中使用的Azure Virtual WAN基础的完整Terraform项目。
存储库包括部署多区域中心和分支拓扑、Virtual WAN中心、路由表和BGP连接所需的所有配置。
GitHub存储库：Infoblox-UDDI-and-Azure-vWAN-Terraform-Lab
部署基础设施后，您可以按照本博客中概述的步骤配置NIOS-X、启用DNS服务、分配Anycast IP，并与Azure Virtual WAN中心建立BGP会话。
这使读者能够轻松端到端复制完整的实验室环境，并在自己的订阅中试验Azure上的Anycast DNS。
免责声明
本博客中演示的配置和架构基于实验室验证的场景。它们旨在用于测试和教育目的。客户应根据自己的网络设计、冗余和操作要求审查、测试和调整配置。