本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
設定API閘道DNS容錯移轉的自訂健全狀況檢查 API
您可以使用 Amazon Route 53 運作狀態檢查,控制從次要區域中主要API閘道API AWS 區域 到一個閘道的DNS容錯移轉。這可以幫助緩解發生區域問題時的影響。如果您使用自訂網域,則可以執行容錯移轉,而不需要用戶API端變更端點。
當您針對別名記錄選擇評估目標 Health 全狀況時,只有當區域中的API閘道服務無法使用時,這些記錄才會失敗。在某些情況下,您自己的 API Gateway APIs 可能會在此之前遇到中斷。若要直接控制DNS容錯移轉,請為API閘道設定自訂 Route 53 健全狀況檢查APIs。在此範例中,您會使用可協助操作員控制DNS容錯移轉的 CloudWatch 警示。如需設定容錯移轉時的詳細範例和其他考量事項,請參閱使用 Route 53 建立災難復原機制
必要條件
若要完成此程序,您必須建立並設定以下資源:
如需如何為網域名稱建立 Route 53 容錯移轉DNS記錄的詳細資訊,請參閱 Amazon Route 53 開發人員指南中的選擇路由政策。如需如何監控 CloudWatch 警示的詳細資訊,請參閱 Amazon Route 53 開發人員指南中的監控 CloudWatch 警示。
步驟 1:設定資源
在此範例中,您可以建立下列資源來設定網域名稱的DNS容錯移轉:
-
API兩APIs合一的閘道 AWS 區域
-
API兩個中具有相同名稱的閘道自訂網域名稱 AWS 區域
-
API將閘道連線APIs至自訂網域名稱的API閘道API對應
-
路由 53 個網域名稱的容錯移轉DNS記錄
-
次要區域中的 CloudWatch 警報
-
根據次要區域的 CloudWatch 警報進行 53 號 Route 53 健康狀態檢查
首先,請確定您擁有主要和次要區域中的所有必要資源。次要區域應包含警示和運作狀態檢查。如此一來,您就不必依賴主要區域來執行容錯移轉。如需建立這些資源的 AWS CloudFormation 範本,請參閱primary.yaml
和secondary.yaml
。
重要
容錯移轉至次要區域之前,請確定所有必要的資源都可用。否則,您將API無法為次要區域的流量做好準備。
步驟 2:啟動容錯移轉至次要區域
在下列範例中,待命區域會接收 CloudWatch 測量結果並起始容錯移轉。我們使用自訂指標,需要操作員介入才能啟動容錯移轉。
aws cloudwatch put-metric-data \
--metric-name
Failover
\--namespace
HealthCheck
\--unit
Count
\--value
1
\--region
us-west-1
將測量結果資料取代為您設定之 CloudWatch 警示的對應資料。
步驟 3:測試容錯移轉
調用您的API並驗證您是否從次要區域獲得響應。如果您在步驟 1 中使用範例範本,回應會在容錯移轉後從 {"message": "Hello from the primary Region!"}
改為 {"message": "Hello from the secondary Region!"}
。
curl
https://my-api.example.com
{"message": "Hello from the secondary Region!"}
步驟 4:傳回主要區域
若要返回主要區域,請傳送使健康狀態檢查通過的 CloudWatch 量度。
aws cloudwatch put-metric-data \
--metric-name
Failover
\--namespace
HealthCheck
\--unit
Count
\--value
0
\--region
us-west-1
將測量結果資料取代為您設定之 CloudWatch 警示的對應資料。
調用您的API並驗證您是否從主要區域獲得回應。如果您在步驟 1 中使用範例範本,回應會從 {"message": "Hello from the secondary Region!"}
改為 {"message": "Hello from the primary Region!"}
。
curl
https://my-api.example.com
{"message": "Hello from the primary Region!"}
後續步驟:自訂和定期測試
此範例示範設定DNS容錯移轉的一種方法。您可以將各種 CloudWatch 指標或HTTP端點用於管理容錯移轉的健全狀況檢查。定期測試容錯移轉機制,以確保正常運作,並且操作員熟悉您的容錯移轉程序。