Route 53 區域轉移的最佳做法 ARC - Amazon Route 53 Application Recovery Controller

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Route 53 區域轉移的最佳做法 ARC

我們建議在 Route 53 中使用區域轉移進行異地同步備份復原的最佳實務。ARC區域轉移通常會從即時應用程式中移除容量,因此在生產環境中使用時請務必小心。

主題

容量規劃和預先調整

確定您已規劃並預先調整規模或可以自動調整規模的足夠容量,以容納啟動區域轉移時強加在可用區域上的額外負載。使用復原導向架構,典型的建議是預先調整運算容量,以包含足夠的成長空間,以便在三個複本中的其中一個 (通常) 離線時為尖峰流量提供服務。

例如,當您針對單一負載平衡器資源啟動區域轉移時,會暫時從負載平衡器後方移除一個可用區域的容量。根據您啟動的區域轉移以及負載平衡器的設定方式而定,您必須確定已仔細規劃管理剩餘可用區域上增加的負載。

限制用戶端保持連線至端點的時間

當 Amazon Route 53 應用程式復原控制器將流量從損害轉移出來時,例如使用區域移位或區域自動切換,Route 53 ARC 用來移動應用程式流量的機制就是一項更新。DNSDNS更新會導致所有新的連線導向遠離受損位置。

但是,具有預先存在開啟連線的用戶端可能會繼續對受損位置發出要求,直到用戶端重新連線為止。為確保快速復原,建議您限制用戶端保持連線至端點的時間長度。

如果您使用應用程式負載平衡器,則可以使用keepalive此選項來設定連線持續的時間長度。如需詳細資訊,請參閱《應用 Application Load Balancer 使用者指南》中的用HTTP戶端保持活

根據預設,應用程式負載平衡器會將用HTTP戶端保持作用持續時間值設定為 3600 秒或 1 小時。我們建議您降低與應用程式復原時間目標內嵌的值,例如 300 秒。當您選擇用戶HTTP端 keepalive 持續時間時間時,請考慮這個值是一般而言,更頻繁地重新連線之間的折衷,這可能會影響延遲,並且更快速地將所有用戶端從受損的可用區域或區域移開。

事先測試開始區域偏移

透過啟動區域變更,定期測試從應用程式可用區域移出的流量。規劃並執行起始區域轉移 (最好在測試和生產環境中),作為定期容錯移轉測試的一部分,以便在發生災難時復原應用程式。定期測試是確保您已做好準備,並有信心在操作事件發生時緩解問題的關鍵部分。

確保所有可用區域的健康狀況良好並吸收流量

區域輪班的工作方式是將資源 (即應用程式複本) 標記為可用區域中的狀況不良。這表示,確保應用程式之負載平衡器中的目標通常狀況良好且主動在某個區域中的可用區域中接收流量至關重要。我們建議您使用儀表板來追蹤此情況,包括例如,針對狀況不良的目標和bytesProcessed 每個可用區域的「Elastic Load Balancing」測量結果。

考慮從第二個相鄰區域監控資源的健康狀態。這種方法的優點在於它可以更能代表您的最終用戶體驗,並且還可以降低應用程序和監視同時受到相同災難影響的風險(「共同命運」)。

使用資料平面API作業進行災難復原

若要在您需要快速復原應用程式時啟動區域移位,但幾乎沒有相依性,我們建議您在可能的情況下使用 AWS Command Line Interface 或API與區域移位動作搭配預先儲存的認證。您也可以在中啟動區域偏移 AWS Management Console,以便於使用。但是,當快速、可靠的復原至關重要時,資料平面作業是更好的選擇。如需詳細資訊,請參閱區域偏移API參考指南

僅暫時移動區域偏移的交通

區域轉移會暫時將流量從可用區域移開,以減輕損害。您應該在採取動作修正問題後,立即將應用程式的資源還原為服務。如此可確保您的整體應用程式恢復到原始的完全備援、彈性狀態。