本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
中的區域轉移最佳實務 ARC
我們建議在 中使用區域移位進行多可用區域復原的下列最佳實務ARC。區域轉移通常會從即時應用程式中移除容量,因此在生產中使用它們時請務必小心。
主題
- 容量規劃和預先擴展
確保您已規劃 ,且已預先擴展或 可以自動擴展足夠的容量,以適應啟動區域轉移時對可用區域施加的額外負載。使用復原導向的架構時,一般建議是預先擴展運算容量,以便在您的其中一個 (通常) 三個複本離線時,包含足夠的總空間來提供尖峰流量。
例如,當您啟動單一負載平衡器資源的區域轉移時,一個可用區域的容量會暫時從負載平衡器後方移除。根據您開始的區域輪班以及負載平衡器的設定方式,您必須確定已仔細規劃管理剩餘可用區域增加的負載。
- 限制用戶端與端點保持連線的時間
-
例如,當 Amazon Application Recovery Controller (ARC) 使用區域移位或區域自動移位將流量移離障礙時,ARC使用 來移動應用程式流量的機制即為DNS更新。DNS 更新會導致所有新連線被導向至受損位置之外。
不過,具有預先存在開放連線的用戶端可能會繼續針對受損位置提出請求,直到用戶端重新連線為止。為了確保快速復原,建議您限制用戶端保持連線至端點的時間。
如果您使用 Application Load Balancer ,您可以使用
keepalive
選項來設定連線的持續時間。如需詳細資訊,請參閱 Application Load Balancer 使用者指南中的HTTP用戶端保持連線持續時間。根據預設,Application Load Balancer 會將HTTP用戶端保持連線持續時間值設定為 3600 秒或 1 小時。建議您降低值,以符合應用程式的復原時間目標,例如 300 秒。當您選擇HTTP用戶端保持連線持續時間時,請考慮此值是在一般更頻繁重新連線、可能影響延遲,以及更快速地將所有用戶端移離受損的 AZ 或區域之間交換。
- 事先測試開始區域偏移
透過啟動區域轉移,定期測試從應用程式可用區域移出的流量。規劃和執行啟動區域轉移,最好在測試和生產環境中,作為在發生災難時復原應用程式之定期容錯移轉測試的一部分。定期測試是確保您準備好並有信心在發生操作事件時緩解問題的關鍵部分。
- 確保所有可用區域都運作良好並接收流量
區域轉移的運作方式是將資源,也就是應用程式複本,標示為在可用區域中運作狀態不佳。這表示,請務必確保應用程式負載平衡器中的目標整體運作狀態良好,並主動在區域中的可用區域中接收流量。我們建議您使用儀表板來追蹤此狀況,包括例如 Elastic Load Balancing 指標,用於運作狀態不佳的目標和bytesProcessed 每個可用區域。
請考慮監控來自第二個相鄰區域的資源運作狀態。這種方法的優點是它可以更代表您的最終使用者體驗,而且也可以降低應用程式和監控同時受到相同災難 ("共享命運") 影響的風險。
- 使用資料平面API操作進行災難復原
若要在需要快速復原應用程式時啟動區域轉移,只要相依性極少,我們建議您使用 AWS Command Line Interface 或 API搭配區域轉移動作,並盡可能使用預先存放的憑證。您也可以在 中啟動區域轉移 AWS Management Console,以方便使用。但是,當快速、可靠的復原至關重要時,資料平面操作是更好的選擇。如需詳細資訊,請參閱區域輪班API參考指南 。
- 僅暫時移動具有區域轉移的流量
區域轉移會暫時將流量移離可用區域,以減輕損害。您應該在採取動作修正問題後,立即將應用程式的資源還原至服務。這可確保您的整體應用程式還原至其原始完全冗餘的彈性狀態。