使用 Azure Front Door 及替代入口解決方案的高可用性實作指南

Azure Front Door 設計旨在為外部客戶及 Microsoft 內部屬性提供卓越的韌性與可用性。 雖然 Azure Front Door 的架構滿足或超越大多數生產工作負載的需求，但沒有任何分散式系統能避免失敗。

本文提供高層次、逐步的說明，說明如何實作 Azure Traffic Manager 在罕見的 Azure Front Door 服務中斷時，手動從 Azure Front Door 切換到替代內容傳遞網路（CDN）或 Azure Application Gateway 網頁應用防火牆（WAF）。 它補充了 關於任務關鍵網路應用的全域路由冗餘指引。

業界存在多種策略，旨在實現 CDN 與網頁應用架構的高可用性（HA）。 本文所述的方法著重於直接的手動「應急」容錯移轉模式。 客戶可利用此模式在停電期間快速重新導向流量，並在確認服務健康後無縫恢復路由回 Azure Front Door。

本文亦包含在生產環境中實施 HA 模式、建立健康監控，以及建立支援持續準備的操作手冊的指引。

主要操作差異

本指南介紹兩種經過驗證的架構，利用 Traffic Manager 提供自動故障轉移。 下表總結了需考慮的主要操作差異：

層面 Scenario 1 （Azure Front Door + Application Gateway） 情境 2 （Azure Front Door + 其他 CDN）
故障轉移目標 次要流量管理器實例及多個應用閘道實例。 僅有一個其他 CDN 端點。
容錯移轉期間的快取 否。 Application Gateway 不會快取。 是的。
地理分布 兩個特定的 Azure 區域。 其他 CDN 的全球邊緣網路。
WAF 保護 Azure Web Application Firewall（一致性規則集）。 其他 CDN 的 WAF（規則集不同）。
待命期間的成本 固定的運算成本。 應用程式閘道即使在閒置時收費：容量極低的WAF_v2每月約 200-400 美元。 這取決於 CDN 供應商的定價。

生產環境的考量

當你為生產工作負載實作 HA 架構時，請考慮以下最佳實務與重要注意事項：

  • 請勿設定主要的流量管理員執行個體來進行自動容錯移轉。

    Azure Traffic Manager 的健康探測只來自美國的 Azure 區域。 對於 Azure Front Door 端點（或任何使用 anycast 路由的 CDN）探測器，這些美國探測器幾乎總是能到達美國 POP 伺服器，且未驗證非美國 POP 伺服器的健康狀況。 這種情況會阻止流量管理員根據任一傳播 CDN (例如 Azure Front Door) 的真實全域運作狀況，在 Azure Front Door 和其他入口服務之間自動容錯移轉。

    對於需要多個地理位置健康情況驗證的全域工作負載，手動容錯移轉 (停用加權路由和監控) 比自動化健康路線規劃更可靠。

  • 如果你目前使用 Azure 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 防護的定價。

  • 記錄 Azure Front Door 與故障轉移解決方案之間的 WAF 規則差異。

  • 我們不建議這些 HA 架構使用 Azure Private Link，因為其他 CDN 平台無法存取 Azure Front Door 中由 Private Link 整合保護的來源。

    此外，應用閘道還需要額外的虛擬網路與私有端點配置，才能抵達私有來源。 Application Gateway 無法使用 Azure Front Door 的原生 Private Link 功能。

    對於使用Azure Front Door及其他CDN供應商的生產環境，考慮使用替代且與CDN無關的來源安全控制，以強制執行原始信任，當你無法使用私有連結或 X‑Azure‑FDID 驗證時。 這些控制可能包括基於憑證的起源驗證（HMAC 或簽署 URL）、互惠 TLS（mTLS）、自訂起源標頭，以及 IP 位址過濾。

  • 請編輯本指南中列出的範例指令，使其更適合你的自動化和執行手冊環境。

  • 建立明確的操作手冊。 測試故障轉移及故障復原程序。

  • 為所有端點配置全面的監控與警示。

  • 在容錯移轉至替代輸入解決方案期間，請驗證功能是否正常。

  • 測試所有平台的憑證更新流程。

  • 定期驗證故障轉移端點是否仍能正常運作。 我們建議每季檢測一次。

  • 本指南使用了 PowerShell 執行的 Azure CLI 範例指令。

  • 在繼續之前，請先檢視關鍵 任務網路應用程式的全域路由冗餘。

案例 1：流量管理員從 Azure Front Door 容錯移轉至 Application Gateway WAF

這個基於 DNS 的負載平衡解決方案使用多個 Azure Traffic Manager 設定檔。 在 Azure Front Door 極不可能發生可用性問題時，流量管理員會透過應用程式閘道 WAF 重新導向流量。 主要的 Traffic Manager 實例會在 Azure Front Door（主門）與巢狀的次要 Traffic Manager 實例之間路由流量，該實例指向多區域應用閘道實例。 在 Azure Front Door 中斷服務期間，以手動方式將流量切換至具有 WAF 保護的區域性應用程式閘道部署。

圖中顯示流量管理員，其利用加權路由傳送至 Azure Front Door，並且包含一個巢狀流量管理員設定檔，其中使用效能路由將流量傳送至位於兩個區域的應用閘道執行個體。

  • 流量 (正常操作)：使用者→ DNS 查詢→主要流量管理員執行個體 (加權/永續服務路由) → Azure Front Door (優先權 1) → 原始伺服器。

  • 流量流（Azure Front Door 失效）：使用者→ DNS 查詢→主要流量管理器實例（加權/始終服務路由）→次要流量管理實例（優先模式）→應用閘道→原始伺服器。

預部署：Azure Front Door vs. Application Gateway

了解 Azure Front Door 與 Application Gateway WAF 之間的功能差異非常重要，以防使用到 Application Gateway WAF 所未提供的功能。 以下表格提供概述。

這很重要

這個解決方案假設你目前正在使用 Azure Front Door 來服務跨多個區域或全球的流量。 在此設計中，後續步驟引入一個次要流量管理器實例，該實例在主要流量管理實例與區域應用閘道實例間進行效能路由。

這種做法是必要的，因為 Azure Front Door 是一個全球性的 Layer-7 服務。 次要的 Traffic Manager 實例實際上取代了 Azure Front Door 中基於全局延遲的路由，作為全球負載平衡層。 因此，Traffic Manager 能保留延遲優化的用戶路由，以滿足地理分散的受眾需求。

鑑於此架構轉變，您必須評估全球流量模式，並在有意義使用者量的區域部署應用閘道實例，以確保最佳效能與韌性。

功能差異

特徵 / 功能 Azure Front Door 應用程式閘道
核心架構與功能
服務範圍 全球服務 區域服務
OSI 層 第7層（應用層） 第7層（應用層）
負載平衡層級 跨地區 在區域或虛擬網路內
部署模型 單一全域實例 每個區域的實例
後端範圍 任何公開端點（Azure 或外部端點），以及所選的 Private Link 端點 虛擬網路中任何公開端點（Azure 或外部）、私有 IP 位址，以及 Kubernetes Pods
內容邊緣快取 Yes 否
網路架構 Microsoft 全球邊緣網路採用 Anycast 技術 Azure 區域部署（不使用 anycast）
配置差異
路徑模式語法 /path/* 或完全相符的 /path 正則表達式模式、路徑圖
WAF 規則集 預設規則集（OWASP）、機器人管理規則集、HTTP DDoS 規則集 預設規則集（OWASP）、機器人管理規則集、HTTP DDoS 規則集
健康探針評估 路由延遲 + 系統健康狀況 僅顯示健康狀況
後端選擇 根據優先權、權重、延遲 循環配置、Cookie 相依性
路由規則
路徑型路由 ✓ 是 ✓ 是
模式比對 精確相符路徑、萬用字元路徑（/*）、不區分大小寫、萬用字元必須由 / 前置。 支援的 URL 路徑圖、基於路徑的規則、正則表達式模式
主機導向路由 ✓ 多重前端主機 ✓ 多站點主機
URL 重寫 靜態路徑到靜態路徑（經典） URL 路徑重寫
路由方法 優先權、權重、延遲 負載感知以優化延遲*、加權*、會話黏著性（*可用於容器應用閘道）
路由功能
規則引擎/重寫規則 包含條件與動作的規則集 用條件和動作重寫規則集
路徑模式中的正則表達式 在對應模式中不支援 支援來自PCRE
標頭與請求操作
標頭重寫 ✓ 請求與回應標頭 ✓ 請求與回應標頭
標頭值字元限制 沒有書面紀錄的限制 重寫規則中最多 1,000 個字元
主機標頭重寫 ✓ 支援 ✓ 支持（無法重寫至外部網域）
伺服器變數 ✓ 支援 ✓ 支援
標頭模式匹配 具有模式的條件 正則表達式模式匹配
安全功能
WAF 可用性 ✓ 選配（高級等級） ✓ 可選（WAF 層）
L3/4 DDoS 防護 ✓ 內建 經由 Azure DDoS 防護服務
SSL/TLS 政策 ✓ 可配置 ✓ 可配置
端對端 SSL ✓ 支援 ✓ 支援
私人連結支援 ✓ 高級等級 ✓ V2 層級
WAF 自訂規則 ✓ 支援 ✓ 支援

WAF 的差異

Azure Front Door 應用程式閘道
Microsoft 預設規則集（DRS）2.1 OWASP 核心規則集（CRS）3.2 或 4.0
規則編號：949xxx 系列 規則編號：9xxxxx 系列
Azure Front Door WAF（DRS）：檢查請求正文的前128 KB 應用閘道 WAF（CRS 3.2+）：最高可進行 2 MB 檢查;4 GB 檔案上傳;執法與檢查可獨立配置

Recommendations

  • 因為你必須為每個 WAF 維持不同的規則集，建議使用 Azure Front Door 的規則集作為基準。 建立一套盡可能接近 Azure Front Door 規則集的 Application Gateway 規則集。

  • 分別且獨立測試應用閘道 WAF。

  • 記錄兩個平台的所有自訂排除事項。

  • 定期稽核規則集以確保一致性。

  • 請遵循 Azure Application Gateway 基礎設施配置中的網路指引。 務必執行以下虛擬網路與子網路的要求：

    • 請依區域使用以下子網大小：

      • 最小值：/27 (32 個位址)

      • 建議：/24（256 個地址）用於自動縮放和不中斷維護

      • 公式：（最大實例數 * 10） + 5 個 Azure 保留 IP

      • 範例：最多 20 個實例 → （20 * 10）+ 5 = 205 個 IP → 使用 /24

    • 為了達到最佳安全性，請使用專用子網作為應用閘道（不使用其他資源）。

    • 確保入站連線允許：

      • 網際網路 (或特定來源範圍) 的 443/80

      • 65200-5535 來自 Azure Gateway Manager（Application Gateway v2）

      • Azure Load Balancer

    • 封鎖其他入站連線。 不要封鎖必須的外接網路連線。

    • 使用應用程式安全群組來進行後端分段和最小權限規則。

關於容量規劃與自動擴展策略，請參閱 Azure Application Gateway v2 架構最佳實務。

主要實施步驟

步驟一：提供先決條件

  • Azure Front Door 已設定自訂網域並取得 BYO 憑證。

  • 降低 CNAME 記錄的 DNS TTL 值，以便 Azure Front Door 能夠以最低時間設定提供流量服務。

  • Azure 訂閱需要具備建立虛擬網路、應用程式閘道實例以及流量管理器實例的權限。

  • Azure Key Vault 中的 SSL/TLS 憑證或可上傳。

  • Origin 伺服器可從 Azure 虛擬網路存取。

這很重要

如果你目前使用 Azure Front Door 管理的憑證，必須先遷移到 BYO 憑證才能實施此解決方案。 Azure Front Door 管理的憑證無法匯出並安裝到其他 CDN 上。 欲了解更多資訊，請參閱「在 Azure Front Door 自訂網域上配置 HTTPS」。

步驟 2：在第一區域部署應用閘道

  1. 建立應用閘道的網路基礎架構。 如需詳細資訊，請參閱應用程式閘道基礎結構設定。

  2. 建立一個受管理身份並授權金鑰庫存取權。 如需詳細資訊，請參閱使用 Key Vault 憑證終止 TLS。

    應用閘道需要以 PFX 格式提供帶有私鑰的 SSL/TLS 憑證。 憑證必須能從 Key Vault 存取或直接上傳。 使用與 Azure Front Door 相同的憑證來確保 TLS 行為一致。

  3. 建立 WAF 原則。 欲了解更多資訊，請參閱 「為應用閘道建立 WAF 政策」。

  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 certificate is for domain, not IP)
Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck

    預期結果為狀態代碼200。 如果你遇到「502 Bad Gateway」，請確保後端 HTTP 設定已 --host-name-from-backend-pool true 啟用。

步驟 3：設定 WAF 政策設定（可選）

預設情況下，WAF 會以偵測模式建立。 預防模式會主動阻擋惡意請求。 在正式環境中啟用預防模式前，請徹底測試。

評估您的全球流量模式，並在有意義的使用者量區域部署應用閘道實例。 如果你在多個區域部署 Application Gateway，對每個額外區域（例如美國西部 2 區）重複步驟 2 和 3。 使用不同的虛擬網路位址空間（10.2.0.0/16、10.3.0.0/16 等）以及區域特定的變數後綴（R2、R3 等）。

步驟 4：建立流量管理器架構以支援應用閘道 WAF 端點

  1. 在此情境下，依照前面圖中的說明建立效能模式的次要 Traffic Manager 實例。 欲了解更多資訊，請參閱 建立流量管理員個人檔案。

    對於單一區域配置，請參考以下細節：

    • 路由方式：優先權。
    • 端點：單一應用閘道的公共 IP 位址。

    對於多區域配置，請參考以下細節：

    • 路由方式：效能（將使用者導向最近的健康應用閘道實例）。
    • 端點：跨區域的多個應用閘道公有 IP 位址。
    • 端點位置：每個端點的 Azure 區域（效能路由所必需）。

    請使用以下設定：

    Setting 價值觀 註釋
    路由方式 效能 （多區域）或 優先權 （單一區域） 效能 優化多區域配置的延遲。
    通訊協定 HTTPS 透過 HTTPS 驗證應用程式閘道的健康狀況。
    通訊埠 443 標準 HTTPS 埠。
    路徑 /health 或 /index.html 必須與應用閘道後端健康探測的路徑相匹配。
    TTL 300秒 平衡 DNS 查詢負載與響應速度。

    備註

    預設情況下，Azure 公用 IP 的應用程式閘道沒有設定 DNS 名稱。 你必須直接在 Traffic Manager 端點使用公共 IP 位址，而不是 DNS 名稱。 該 --endpoint-location 參數是性能路由所必需，以實現地理路由。

  2. 建立主要加權/永續服務的流量管理員執行個體，如前文圖例所示。 欲了解更多資訊，請參閱 建立流量管理員個人檔案。

    對於兩個端點，請使用以下配置：

    Setting 價值觀 註釋
    路由方法 加權 允許透過端點狀態（啟用或停用）手動控制。
    重量 100  
    通訊協定 HTTPS 驗證 SSL/TLS 端點所必需的。
    通訊埠 443 標準 HTTPS 埠。
    路徑 /index.html 選擇輕量級端點進行健康檢查。
    TTL 300秒 DNS TTL。 較低的值能加快故障切換速度，但會增加 DNS 查詢的次數。
    健康狀態檢查 始終提供流量服務 不要啟用健康檢查。

    這些配置是針對主要端點專屬的：

    • 類型： 外部端點

    • 名稱： endpoint-afd-primary

    • 完全限定網域名稱（FQDN）或 IP 位址：Azure Front Door 端點的主機名稱（例如 myapp-12345.z01.azurefd.net）

    • 啟用端點：已選中（啟用）

    • 自訂標頭設定：Host=$CUSTOM_DOMAIN (Azure Front Door 需要路由到正確的自訂網域)

    • 健康狀態檢查：一律提供流量 (停用健康狀態檢查)

    在 Azure 入口網站新增 Traffic Manager 主要端點的設定截圖。

    這些配置是次級端點專屬的：

    • 類型： 外部端點

    • 名稱：endpoint-appgw-secondary

    • 完全限定網域名稱（FQDN）或 IP 位址：次要流量管理器 FQDN（例如myapp-appgw.trafficmanager.net）

    • 啟用端點：已清除（停用）

    新增 Traffic Manager 次要端點的設定截圖。

  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 更新為流量管理器並驗證更新

警告

以下步驟將將你的生產流量直接從 Azure Front Door 導向到 Traffic Manager，並可能造成服務影響。 在你繼續之前：

  • 先在非生產環境測試這些步驟。 例如，暫時修改非生產工作站的本地 hosts 檔案，將自訂網域解析至流量管理器端點。 此修改允許驗證而不影響即時流量。
  • 在你做更改前至少 24 小時，將你的 DNS CNAME TTL 降到最低值（例如 60-300 秒）。
  • 如果可能，請在人流稀少時段規劃維修時段。
  • 準備好回滾程序以備不時之需。

  1. 更新你的 DNS CNAME 紀錄，讓它指向主要的 Traffic Manager 實例，而不是直接指向 Azure Front Door。

    領域 舊值 新值
    姓名/主持人 www www （無變化）
    價值/指向 Azure Front Door 端點的主機名稱 $ATM_DNS_NAME.trafficmanager.net

  2. 驗證流量管理員解析：

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

    測試應該會回傳 Azure Front Door 端點的 IP 位址。

  3. 等 DNS 傳播，然後測試 HTTPS 連線。 DNS 傳播通常需 5-10 分鐘，但全球可能長達 48 小時。

    # 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

    此測試應回傳狀態代碼200。

  4. DNS 切換後，請積極監控以下 Azure Front Door 的指標：

    • 請求次數：請求數量應保持一致，流量不應減少。

    • 反應時間：應維持在正常範圍內。

    • 錯誤率：4xx/5xx 錯誤不應增加。

    • 原始健康狀況：後端健康狀況應維持 Online。

步驟 6：測試故障轉移程序

  1. 模擬 Azure Front Door 失效（手動切換至 Application Gateway）：

    # Manual failover to Application Gateway
# Disable Azure 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 instance and Application Gateway)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Application Gateway
curl --head https://$CUSTOM_DOMAIN/

    備註

    DNS TTL 會影響故障轉移時間。 TTL 為 60 秒，客戶端可能需要長達 60 秒才能看到變化。 使用 nslookup 驗證解析是否指向應用程式閘道。

  2. 容錯回復至 Azure Front Door：

    # Re-enable Azure 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 Azure Front Door)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Azure 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

    回應標頭有助於識別服務端點：

    • Azure Front Door 包含x-azure-ref標頭。
    • 通過應用閘道的流量可能會包含 Server: Microsoft-IIS 或類似的資訊。

案例 2：流量管理員從 Azure Front Door 容錯移轉到另一個 CDN

這個解決方案使用單一的 Traffic Manager 組態設定檔，並採用加權/始終為您服務的路由策略，讓您可以手動在 Azure Front Door 與其他 CDN 之間切換流量。

Azure Front Door 與另一個 CDN 之間流量管理器路由圖。

  • 主要端點：Azure Front Door 自訂域端點。

  • 次要終點：替代CDN終點。

  • 流量 (正常操作)：使用者 → DNS 查詢 → 流量管理員 (加權/永續服務路由) → Azure Front Door (優先權 1) → 原始伺服器。

  • 流量 (Azure Front Door 故障)：使用者 → DNS 查詢→流量管理員 (加權/永續服務路由) → 替代 CDN (優先權 2) → 原始伺服器。

主要實施步驟

步驟一：提供先決條件

請將您的次要 CDN 供應商配置如下：

  • Azure Front Door 設定了自訂網域和 BYO 憑證。

  • 一個替代的 CDN 帳號。

  • 降低 CNAME 記錄的 DNS TTL 值，以便 Azure Front Door 能夠以最低時間設定提供流量服務。

  • 可以供 Azure Front Door 和其他 CDN 存取的來源伺服器。

  • 一個可以修改 DNS 紀錄的自訂網域。

這很重要

如果你目前使用 Azure Front Door 管理的憑證，必須先遷移到 BYO 憑證，才能實施這個 HA 解決方案。 Azure Front Door 管理的憑證無法匯出並安裝到其他 CDN 上。 欲了解更多 BYO 憑證的資訊與設定說明，請參閱「在 Azure Front Door 自訂網域上配置 HTTPS」。

步驟 2：設定替代 CDN

設定您的次要 CDN 供應商：

  • 使用你的自訂網域來設定 CDN 區或屬性。

  • 設定 Origin 伺服器的方式和你設定 Azure Front Door 後端池一樣。

  • 上傳 BYO SSL/TLS 證書。 這張證書就是你在 Azure Front Door 用過的那個。

  • 設定 CDN 快取規則以符合 Azure Front Door 的行為。 例如，設定快取時長與查詢字串處理。

  • 設定快取設定、控制標頭及壓縮設定，確保與你的 Azure Front Door 組態相符。

  • 如果 CDN 供應商提供 WAF 功能，請設定 WAF 規則。 嘗試配合 Azure Front Door 的 WAF 原則。

  • 設定一個自訂網域以符合你的 Azure Front Door 自訂網域（例如， www.contoso.com）。

  • 記錄 CDN 邊緣的主機名稱以供流量管理器設定（例如， your-site.cdn.provider.net）。

步驟 3：建立流量管理員個人檔案

請套用以下設定來建立流量管理設定檔。 欲了解更多資訊，請參閱 建立流量管理員個人檔案。

Setting 價值觀 註釋
路由方法 加權 允許透過端點狀態（啟用或停用）手動控制。
重量 100 當建立流量管理員設定檔和兩個端點時，請輸入 100。
通訊協定 HTTPS 驗證 SSL/TLS 端點所必需的。
通訊埠 443 標準 HTTPS 埠。
路徑 /index.html 選擇輕量級端點進行健康檢查。
TTL 300秒 DNS TTL。 較低的值能加快故障切換速度，但會增加 DNS 查詢的次數。

步驟 4：配置流量管理器端點

在 Traffic Manager 設定檔中建立兩個端點。

主要端點（Azure Front Door）請使用以下設定：

  • 類型： 外部端點

  • 名稱： endpoint-afd-primary

  • 完全限定網域名稱（FQDN）或 IP 位址：Azure Front Door 端點的主機名稱（例如 myapp-endpoint-12345.z01.azurefd.net）

  • 體重： 100

  • 啟用端點：初始已選中（啟用）

  • 自訂標頭設定： Host=$CUSTOM_DOMAIN （需要此設定使 Azure Front Door 能夠正確導向至自訂網域）

  • 健康狀態檢查：一律提供流量 (停用健康狀態檢查)

在 Azure 入口網站新增 Traffic Manager 主要端點的設定截圖。

備註

這個 --custom-headers "Host=$CUSTOM_DOMAIN" 參數對 Azure Front Door 端點來說非常重要。 沒有它，Azure Front Door 可能無法正確將請求導向你的自訂網域設定。 這是 Azure Traffic Manager 支援的功能。

請將以下配置用於次要端點（替代 CDN）：

  • 類型： 外部端點

  • 名稱：endpoint-cdn-secondary

  • 完全限定網域名稱（FQDN）或 IP 位址：CDN Edge 的主機名稱（例如 myapp.cdn.net）

  • 體重： 100

  • 啟用端點：待機模式初期已清除 (停用)

在 Azure 入口網站新增 Traffic Manager 次要端點的設定截圖。

步驟 5：將 DNS CNAME 更新為流量管理器並驗證更新

警告

以下步驟將將你的生產流量直接從 Azure Front Door 導向到 Traffic Manager。 在你繼續之前：

  • 先在非生產環境測試這些步驟。
  • 在你做更改前至少 24 小時，將你的 DNS CNAME TTL 降到最低值（例如 60-300 秒）。
  • 如果可能，請在人流稀少時段規劃維修時段。
  • 準備好回滾程序以備不時之需。

  1. 更新你的 DNS CNAME 紀錄，讓它指向 Traffic Manager，而不是直接指向 Azure Front Door：

    領域 舊值 新值
    姓名/主持人 www www （無變化）
    值/指向 Azure Front Door 端點的主機名稱 $ATM_CDN_DNS_NAME.trafficmanager.net

    DNS 傳播通常需 5-10 分鐘，但全球可能長達 48 小時。

  2. 確認 Traffic Manager 解析。 等 DNS 傳播，然後測試 HTTPS 連線。

    # Verify Traffic Manager profile is resolving
nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"
# Expected result: Should return IP address of Azure 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: Status code 200

  3. DNS 切換後，請積極監控以下 Azure Front Door 的指標：

    • 請求次數：請求數量應保持一致，流量不應減少。

    • 反應時間：應維持在正常範圍內。

    • 錯誤率：4xx/5xx 錯誤不應增加。

    • 起源健康：後端健康應保持 Online。

步驟 6：測試故障轉移程序

  1. 手動切換到替代的 CDN：

    # Failover: Disable Azure 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.net"

# Test HTTPS access
curl --head https://$CUSTOM_DOMAIN/

  2. 容錯回復至 Azure Front Door：

    # Failback: Enable Azure 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 Front Door 自訂網域問題)，這些警示應會觸發手動容錯移轉。

我們建議以下監控解決方案用於生產環境：

  • Azure Monitor 工作簿：追蹤流量管理器查詢、Azure Front Door 請求及應用閘道健康狀況。 欲了解更多資訊，請參閱 工作簿概覽。

  • 由外而內監控以偵測全域 Azure Front Door 問題：實作由外而內的全域合成監測解決方案 (如 Catchpoint 或 ThousandEyes) 監控端點。 像 WebPageTest 這類服務提供免費替代方案，但全球可見度有限。

  • Application Insights 可用性測試：使用多區域 HTTP 檢查。 欲了解更多資訊，請參閱 Application Insights 可用性測試。

  • DNS 監控：透過 DNSPerf、Pingdom 或 Uptime.com 驗證 CNAME 解析鏈與 TTL 傳播。

  • 憑證監控：使用 Qualys SSL Labs 的 SSL Server Test 來分析伺服器設定。

  • Last updated on