使用 Azure Front Door 和备用入口解决方案的高可用性实施指南

Azure Front Door 旨在为外部客户和Microsoft的内部属性提供出色的复原能力和可用性。 虽然 Front Door 的体系结构满足或超过大多数生产工作负荷的需求，但必须承认没有分布式系统无法幸免于故障。

本文提供了有关实现 Azure 流量管理器的简要分步说明，以便在罕见的 Front Door 服务中断期间从 Front Door 手动故障转移到备用 CDN 或应用程序网关 WAF。 它补充了任务关键型 Web 应用程序的全局路由冗余指南中的指导意见。

在 CDN 和 Web 应用程序体系结构中实现高可用性（HA）的行业内存在多个策略。 本文中概述的方法重点介绍一种简单的手动“应急故障转移模式”，使客户能够在中断期间快速重定向流量，并在确认服务运行状况后无缝地将路由还原回 Front Door。

本文还包括有关在生产环境中实现高可用性 (HA) 模式、建立健康监测和创建运行手册以支持持续的准备状态的指南。

关键操作差异

本指南介绍了两个经过验证的架构，使用 Azure Traffic Manager 提供自动故障转移。 下表总结了需要注意的关键操作差异：

生产环境的注意事项

为生产工作负荷实现高可用性体系结构时，请考虑以下最佳做法和重要说明：

• 不要将主要 Azure 流量管理器配置为自动故障转移： Azure 流量管理器运行状况探测仅源自位于美国的 Azure 区域。 因此，当探测 Front Door 终结点（或使用任何广播路由的任何 CDN）时，这些基于美国的探测几乎总是会到达美国 POP，使非美国 POP 的运行状况不受验证。 这可以防止流量管理器基于任播 CDN（例如 Front Door）的真实全局健康状况，自动在 Azure Front Door 和另一个入口服务之间进行故障转移。 因此，对于需要从多个地理位置进行运行状况验证的全局工作负荷，禁用加权路由和监视的手动故障转移比自动化的基于运行状况的路由提供了更可靠的控制。

• 证书： 如果当前使用的是 Front Door 管理的认证，则必须迁移到 BYO 证书。 通过使用自己的证书，无论流量遵循哪个入口路径，都可以使 TLS 证书保持一致。 确保 TLS 证书与 Azure Front Door 兼容。 有关详细信息，请参阅 在 Azure Front Door 自定义域上配置 HTTPS 和 Azure Front Door 的 TLS 加密。

• 请务必首先在非生产环境中提前测试故障转移程序。

• Traffic Manager 不支持在 DNS 区域顶点（根域）展平 CNAME 记录：如果您需要在顶点使用 Traffic Manager，则必须使用支持别名记录或类似机制的 DNS 提供商。 Azure DNS 是这样的 DNS 提供程序。

• 使用短 DNS TTL（300 - 600 秒）并监视 DNS TTL 传播时间。

• 安全： 使用网络安全组（NSG）/ACL 加强应用网关的安全（允许必要的平台范围和入站应用端口），并确保所有入口路径的源安全。 有关详细信息，请参阅 为应用程序网关配置网络安全组。 虽然应用程序网关 WAF 可缓解 HTTP/L7 攻击，但 NSG 仅提供数据包筛选，并且不会防范卷或协议级别 （L3/L4） DDoS 攻击。 所有 Azure 公共终结点都受益于作为基础的、始终开启的 Azure 平台 DDoS 保护，旨在保护 Azure 基础结构，但不包括工作负载特定的调优、遥测、成本保护或可用性保证。 对于生产和任务关键型工作负荷，请考虑使用 Azure DDoS 网络保护来保护应用程序网关公共 IP。 有关详细信息，请参阅 Azure DDoS 防护定价 。

• 记录 Front Door 和故障转移解决方案之间的 WAF 规则差异。

• 编辑本指南中列出的示例命令，以便根据您的环境定制这些命令，从而实现自动化和运行手册的目的。

• 建立明确的 Runbook，并测试故障切换和故障恢复流程。

• 为所有终结点配置全面的监视和警报。

• 在故障转移期间验证备用入口解决方案的功能。

• 在所有平台上测试证书续期流程。

• 定期验证故障转移终结点是否保持正常运行（建议进行季度测试）。

• 本指南使用从 PowerShell 中执行的 Azure CLI 示例命令。

• 在继续作之前，请查看 任务关键型 Web 应用程序的全局路由冗余。

方案 1：流量管理器故障转移：Front Door 到应用程序网关 WAF

此基于 DNS 的负载均衡解决方案使用多个 Azure 流量管理器配置文件。 在 Azure Front Door 出现可用性问题的可能性不大的情况下，Azure 流量管理器通过应用程序网关 WAF 重定向流量。 主要流量管理器负责在 Front Door（主）和指向多区域应用程序网关实例的嵌套二级流量管理器之间进行路由。 在 Front Door 故障期间，流量被手动切换到具有 WAF 保护的区域性应用程序网关部署。

流量流（正常作）： 用户→ DNS 查询→主流量管理器（加权/始终提供路由）→ Front Door（优先级 1）→源服务器。

流量流（前端路由器故障）： 用户→ DNS 查询→主流量管理器（加权/始终服务路由）→次级流量管理器（优先级模式）→应用网关→源服务器。

预部署：Front Door 与 应用网关

请务必了解 Front Door 与应用程序网关 WAF 之间的功能差异，以防使用应用程序网关 WAF 不提供的任何功能。 以下两个表提供了概述。

功能差异

WAF 差异

Recommendations

• 由于必须为每个 WAF 维护不同的规则集，因此请使用 Front Door 规则集作为基线。 创建一个应用程序网关规则集，该规则集与 Front Door 规则集尽可能接近。

• 单独和独立测试应用程序网关 WAF。

• 记录这两个平台的所有自定义排除项。

• 定期审核规则集以保持一致性。

• 请专门遵循 Azure 应用程序网关基础结构配置 中的网络指南。 确保执行以下操作：

  • 网络规划： 下面是虚拟网络和子网要求：

    • 子网大小调整（按区域）：

      • 最小值：/27（32 个地址）

      • 建议：/24（256 个地址）用于自动扩展和无中断维护

      • 公式：（最大实例 * 10） + 5 个 Azure 保留 IP

      • 示例：20 个最大实例→ （20 * 10） + 5 = 205 个 IP →使用/24

    • 保护应用程序网关：

      • 应用程序网关的专用子网（无其他资源）

    • 入站功能允许：

      • 来自 Internet 的 443/80（或特定源范围）

      • 来自 GatewayManager 的 65200-5535 （应用程序网关 v2）

      • Azure负载均衡器

    • 阻止其他入站。 不要阻止必要的出站互联网连接

    • 将 ASG 用于后端分段和最小特权规则

关键实现步骤

步骤 1：准备先决条件

• 使用自定义域和 BYO 证书配置的 Azure Front Door。

• 降低您的 CNAME 的 DNS TTL，以便 Front Door 能够以最低时间配置服务流量。

• 有权创建虚拟网络、应用程序网关和流量管理器的 Azure 订阅。

• Azure Key Vault 中的 SSL/TLS 证书或可用于上传。

• 可从 Azure 虚拟网络访问的源服务器。

步骤 2：部署应用程序网关（区域 1）

1. 为应用程序网关创建网络基础结构。 有关详细信息，请参阅应用程序网关基础结构配置。

2. 创建托管标识并授予 Key Vault 访问权限。 有关详细信息，请参阅使用 Key Vault 证书实现 TLS 终止。

   注释

   应用程序网关需要使用私钥的 PFX 格式的 SSL/TLS 证书。 证书必须可从 Azure Key Vault 访问或直接上传。 使用 Front Door 使用的相同证书来确保 TLS 行为一致。

3. 创建 WAF 策略。 有关详细信息，请参阅 为应用程序网关创建 Web 应用程序防火墙策略

4. 使用 HTTPS 和 WAF 创建应用程序网关。 有关详细信息，请参阅 配置具有 TLS 终止的应用程序网关。

5. 配置后端主机标头。 有关详细信息，请参阅 排查应用程序网关中的后端运行状况问题

6. 验证应用程序网关

   # Get Application Gateway public IP
   $APPGW_IP = az network public-ip show `
       --name $APPGW_PIP_NAME_R1 `
       --resource-group $RESOURCE_GROUP `
       --query ipAddress -o tsv
   Write-Host "Application Gateway IP: $APPGW_IP"
   
   # Test Application Gateway directly (SkipCertificateCheck because cert is for domain, not IP)
   Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck
   

   预期结果： StatusCode 200。 如果收到 502 Bad Gateway 错误，请确保已启用后端 HTTP 设置 --host-name-from-backend-pool true。

步骤 3：配置 WAF 策略设置（可选）

步骤 4：创建流量管理器体系结构以支持应用程序网关 WAF 终结点

1. 创建辅助“性能模式”流量管理器，如方案 1 图中所示。 有关详细信息，请参阅 创建流量管理器配置文件

   单区域配置：

   • 路由方法：优先级
   • 终结点：单一应用程序网关公共 IP 地址

   多区域配置：

   • 路由方法：性能（将用户路由到最接近正常的应用程序网关）
   • 终结点：多个跨区域的应用程序网关公共 IP 地址
   • 终结点位置：为每个终结点指定 Azure 区域（性能路由所需的）

   配置：

   设置	价值	注释
   路由方法	性能（多区域）或优先级（单区域）	性能优化多区域的延迟
   协议	HTTPS	通过 HTTPS 验证应用程序网关运行状况
   端口	443	标准 HTTPS 端口
   路径	/health 或 /index.html	必须与应用网关后端健康探测路径匹配
   TTL	300 秒	平衡 DNS 查询负载和响应能力

2. 创建主要“加权模式 Always Serve”流量管理器，如方案 1 图中所示。 有关详细信息，请参阅 创建流量管理器配置文件

   这两个终结点的配置：

   设置	价值	注释
   路由方法	加权	允许通过终结点状态进行手动控制（已启用/禁用）
   重量	100
   协议	HTTPS	验证 SSL/TLS 终结点所必需的
   端口	443	标准 HTTPS 端口
   路径	/index.html	选择用于运行状况检查的轻量级端点
   TTL	300 秒	DNS TTL - 较低的值可实现更快的故障切换，但会增加 DNS 查询
   运行状况检查	始终为流量提供服务	不启用运行状况检查

   终结点特定的配置：

   主终结点：

   • 名称： endpoint-afd-primary

   • 类型： 外部终结点

   • 目标： Front Door 终端主机名（例如 myapp-12345.z01.azurefd.net）

   • 终结点状态： 启用

   • 自定义标头：Host=$CUSTOM_DOMAIN （Front Door 必须路由到更正自定义域）

   • 运行状况检查： 始终为流量提供服务（禁用运行状况检查）

   

   辅助终结点：

   • 名称： endpoint-appgw-secondary

   • 类型： 外部终结点

   • 目标： 次级流量管理器 FQDN （例如 myapp-appgw.trafficmanager.cn）

   • 终结点状态： 禁用

   

3. 验证流量管理器运行状况

   # Check endpoint health status
   az network traffic-manager profile show `
       --name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "{ProfileStatus:profileStatus, MonitorStatus:monitorConfig.profileMonitorStatus, Endpoints:endpoints\[\].{Name:name, Target:target, Priority:priority, Status:endpointMonitorStatus}}"
   

   预期结果： 这两个终结点都应显示 Status: Online。 如果终结点显示 Degraded 或 CheckingEndpoint，请等待 1-2 分钟以完成健康探测。

步骤 5：将 DNS CNAME 更新到流量管理器并验证更新

1. 更新 DNS CNAME 记录以指向 主 流量管理器，而不是直接指向 Front Door。

   领域	旧值	新值
   名称/主机	www	www （无更改）
   值/指向	Front Door 端点主机名	$ATM_DNS_NAME.trafficmanager.cn

2. 验证 Traffic Manager 解析（等待 DNS 传播完成后再进行测试）

   DNS 传播通常需要 5-10 分钟，但全局最多可能需要 48 小时。 监视传播进度并测试 HTTPS 连接：

   # Verify Traffic Manager profile is resolving
   nslookup "$ATM_DNS_NAME.trafficmanager.cn"
   

   预期结果： 应返回 Front Door 终结点的一个或多个 IP 地址。

   # Check DNS from different resolvers
   nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS
   
   # Test HTTPS connectivity
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
   

   预期结果： StatusCode 200

3. 监视 Front Door

   DNS 切换后，主动监视以下 Azure Front Door 指标：

   • 请求计数：应保持一致（流量不会下降）

   • 响应时间：应保持在正常范围内

   • 错误率：4xx/5xx 错误不应增加

   • 源运行状况：后端运行状况应保持联机状态

步骤 6：测试故障转移过程

1. 模拟前端入口故障（手动故障转移到应用程序网关）

   # Manual failover to Application Gateway
   # Disable Front Door endpoint
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Enable secondary Traffic Manager endpoint (Application Gateway)
   az network traffic-manager endpoint update `
       --name "endpoint-appgw-secondary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Verify Traffic Manager endpoint status
   az network traffic-manager endpoint list `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
       --output table
   
   # Flush DNS cache (Windows)
   ipconfig /flushdns
   
   # Verify DNS resolution (should now point to Secondary Traffic Manager → Application Gateway)
   nslookup $CUSTOM_DOMAIN
   
   # Test - should now work via Application Gateway
   curl --head https://$CUSTOM_DOMAIN/
   

   注释

   DNS TTL 会影响故障转移时间。 TTL 为 60 秒，客户端最多可能需要 60 秒才能看到更改。 使用nslookup验证解析是否指向应用程序网关。

2. 故障切换回前端门禁系统

   # Re-enable Front Door endpoint
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Disable Application Gateway (via Secondary Traffic Manager)
   az network traffic-manager endpoint update `
       --name "endpoint-appgw-secondary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Verify endpoint status
   az network traffic-manager endpoint list `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
       --output table
   
   # Flush DNS cache (Windows)
   ipconfig /flushdns
   
   # Verify DNS resolution (should now point back to Front Door)
   nslookup $CUSTOM_DOMAIN
   
   # Test - should now work via Front Door
   curl --head https://$CUSTOM_DOMAIN/
   

3. 验证当前路由

   # Check which endpoint is serving traffic
   nslookup $CUSTOM_DOMAIN
   
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head | Select-Object -ExpandProperty Headers
   

   注释

   响应标头可帮助标识服务终结点：

   • Front Door 包括 x-azure-ref 标头。
   • 通过应用程序网关的流量可能包括 Server: Microsoft-IIS 或类似的流量。

方案 2：流量管理器故障转移：Front Door 到备用 CDN

此解决方案使用一个具有加权或始终服务路由的单一流量管理器配置文件，以便可以在 Front Door 和备选 CDN 之间手动切换流量。

主终结点： Azure Front Door 自定义域终结点。

辅助终结点： 备用 CDN 终结点。

流量流（正常作）： 用户→ DNS 查询→流量管理器（加权路由/始终提供路由）→ Azure Front Door（优先级 1）→源服务器。

流量路径（Front Door 故障）： 用户 → DNS 查询 → 流量管理器（加权路由/始终可用路由）→ 备用 CDN（优先级 2）→ 源服务器。

关键实现步骤

步骤 1：准备先决条件

使用以下方法配置备用 CDN 提供程序：

• 使用自定义域和 BYO 证书配置的 Azure Front Door。

• 备用 CDN 帐户。

• 降低您的 CNAME 的 DNS TTL，以便 Front Door 能够以最低时间配置服务流量。

• Front Door 和备用 CDN 都可以访问源服务器。

• 能够修改 DNS 记录的自定义域

步骤 2：配置备用 CDN

使用以下方法配置备用 CDN 提供程序：

• 使用自定义域设置 CDN 区域/属性。

• 配置源服务器（与 Front Door 后端池相同）。

• 上传 BYO SSL/TLS 证书： （Front Door 中使用的相同证书）。

• 复制缓存规则： 配置 CDN 缓存规则以匹配 Front Door 行为（缓存持续时间、查询字符串处理等）

• 启用类似的功能： 设置缓存设置、控制标头和压缩设置以匹配 Front Door 配置。

• 如果 CDN 提供程序提供 WAF 功能（尝试匹配 Front Door WAF 策略），请设置 WAF 规则。

• 配置自定义域以匹配 Front Door 自定义域（例如 www.contoso.com）。

• 记录流量管理器配置的 CDN 边缘主机名（例如 your-site.cdn.provider.net）。

步骤 3：创建流量管理器配置文件

应用以下配置以创建流量管理器配置文件。 有关详细信息，请参阅 创建流量管理器配置文件。

步骤 4：配置流量管理器的端点

使用以下配置在流量管理器配置文件中创建两个终结点：

主终结点（Front Door）：

• 名称：endpoint-afd-primary

• 类型：外部终结点

• 目标：Front Door 终结点主机名（例如 myapp-endpoint-12345.z01.azurefd.net）

• 重量：100

• 状态：启用（最初）

• 自定义标头：Host=$CUSTOM_DOMAIN（必需，以便 Front Door 路由到正确的自定义域）

• 运行状况检查：始终为流量提供服务（禁用运行状况检查）

Front Door 的自定义标头： 此参数 --custom-headers "Host=$CUSTOM_DOMAIN" 对于 Front Door 终结点至关重要。 如果没有，Front Door 可能无法正确将请求路由到自定义域配置。 它是 Azure 流量管理器支持的一项功能。

辅助终结点（备用 CDN）：

• 名称：endpoint-cdn-secondary

• 类型：外部终结点

• 目标：CDN 边缘主机名（例如 myapp.cdn.net）

• 重量：100

• 状态：已禁用（最初 - 备用模式）

步骤 5：将 DNS CNAME 更新到流量管理器并验证更新

1. 将 DNS CNAME 记录更新为指向流量管理器，而非直接指向 Front Door：

   领域	旧值	新值
   名称/主机	www	www （无更改）
   值/指向	Front Door 端点主机名	$ATM_CDN_DNS_NAME.trafficmanager.cn

   注释

   DNS 传播通常需要 5-10 分钟，但全局最多可能需要 48 小时。

2. 验证流量管理器解析： 等待 DNS 传播并测试 HTTPS 连接。

   # Verify Traffic Manager profile is resolving
   nslookup "$ATM_CDN_DNS_NAME.trafficmanager.cn"
   # Expected result: Should return IP address(es) of Front Door endpoint
   
   # Check DNS from different resolvers
   nslookup $CUSTOM_DOMAIN 8.8.8.8    # Google DNS
   
   # Test HTTPS connectivity
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
   # Expected result: StatusCode 200
   

3. 监视 Azure Front Door： DNS 切换后，主动监视以下 Azure Front Door 指标：

   • 请求计数：应保持一致（流量不会下降）。

   • 响应时间：应保持在正常范围内。

   • 错误率：4xx/5xx 错误不应增加。

   • 源运行状况：后端运行状况应保持联机状态。

步骤 6：测试故障转移过程

1. 手动切换到备用 CDN

   # Failover: Disable Front Door and enable CDN
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   az network traffic-manager endpoint update `
       --name "endpoint-cdn-secondary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Verify endpoint status
   az network traffic-manager profile show `
       --name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus, Target:target}"
   
   # Flush local DNS cache and verify resolution
   ipconfig /flushdns
   nslookup "$ATM_CDN_DNS_NAME.trafficmanager.cn"
   
   # Test HTTPS access
   curl --head https://$CUSTOM_DOMAIN/
   

2. 故障切换回前端门禁系统

   # Failback: Enable Front Door, Disable CDN
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   az network traffic-manager endpoint update `
       --name "endpoint-cdn-secondary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Verify
   az network traffic-manager profile show `
       --name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}"
   

监测

建议对生产环境使用以下监视解决方案：

• Azure Monitor 工作簿： 跟踪流量管理器查询、Front Door 请求、应用程序网关运行状况。 有关详细信息，请参阅 工作簿概述。

• 从外到内监控以检测全球 Front Door 问题： 实现全球外部综合监控解决方案（如 Catchpoint 或 ThousandEyes）来监视终端。 WebPageTest 等服务提供免费的替代方法，提供有限的全球可见性。

• Application Insights 可用性测试： 多区域 HTTP 检查。 有关详细信息，请参阅 可用性测试。

• DNS 监视： 通过 DNSPerf、Pingdom 或 Uptime.com 验证 CNAME 解析链和 TTL 传播。

• 证书监视： 有关详细信息，请参阅 SSL Labs Server 测试。