在 中路由控制的最佳實務 ARC

在災難復原 (DR) 案例中，使用存取 AWS 和執行復原任務的簡單方法，將系統相依性降至最低。建立 DR 任務專用的IAM長期憑證，並安全地將憑證存放在內部部署實體安全或虛擬文件庫中，以在需要時存取。透過 IAM，您可以集中管理安全登入資料，例如存取金鑰，以及存取 AWS 資源的許可。對於非 DR 任務，我們建議您繼續使用聯合存取，並使用 AWS AWS 單一登入等服務。

若要ARC使用復原叢集資料平面 在 中執行容錯移轉任務API，您可以將ARCIAM政策連接至使用者。如需進一步了解，請參閱 Amazon Application Recovery Controller (ARC) 中的身分型政策範例。

對於您可能需要在容錯移轉機制中變更DNS的記錄，特別是檢查運作狀態的記錄，使用較低的TTL值是適當的。將 TTL 設定為 60 或 120 秒是此案例的常見選擇。

DNS TTL （存留時間） 設定會告知DNS解析程式在請求新的記錄之前快取記錄的時間。當您選擇 時TTL，您會在延遲和可靠性之間做出權衡，以及對變更的回應能力。由於記錄TTL較短，DNS解析程式會更快地注意到記錄的更新，因為 TTL指定他們必須更頻繁地查詢。

如需詳細資訊，請參閱在 Amazon Route 53 的最佳實務中選擇DNS記錄TTL的值。 DNS

當您使用路由控制從一個路由到 AWS 區域 另一個路由時，Amazon Application Recovery Controller (ARC) 用來移動應用程式流量的機制是DNS更新。此更新會導致所有新連線被導向至受損的位置。

不過，具有預先存在開放連線的用戶端可能會繼續對受損位置提出請求，直到用戶端重新連線為止。為了確保快速復原，建議您限制用戶端保持連線至端點的時間。

如果您使用 Application Load Balancer，您可以使用 keepalive選項來設定連線持續的時間。如需詳細資訊，請參閱 Application Load Balancer 使用者指南中的HTTP用戶端持續運作期間。

根據預設，Application Load Balancer 會將HTTP用戶端保持連線持續時間值設定為 3600 秒或 1 小時。我們建議您降低值，以符合應用程式的復原時間目標，例如 300 秒。當您選擇HTTP用戶端保持運作持續時間時，請考慮此值是在一般情況下更頻繁重新連線、可能影響延遲，以及更快速地將所有用戶端移離受損的 AZ 或區域之間切換。

我們建議您將ARC區域叢集端點的本機副本保留在書籤中，或儲存在用來重試端點的自動化程式碼中。在故障事件期間，您可能無法存取某些API操作，包括未託管在極可靠資料平面叢集上的ARCAPI操作。您可以使用 DescribeClusterAPI操作列出ARC叢集的端點。

路由控制提供五個區域性端點，以確保高可用性，即使處理故障也一樣。若要實現完全恢復能力，請務必具有可視需要使用所有五個端點的重試邏輯。如需搭配 使用程式碼範例的相關資訊 AWS SDK，包括嘗試叢集端點的範例，請參閱 使用 的應用程式復原控制器程式碼範例 AWS SDKs。

使用ARC資料平面 API，透過 ListRoutingControls操作檢視您的路由控制和狀態，並更新路由控制狀態，以透過 UpdateRoutingControlState操作重新導向容錯移轉的流量。您可以使用 AWS CLI （如這些範例所示） 或使用其中一個 撰寫的程式碼 AWS SDKs。 ARC 提供極高的可靠性，資料平面API中的 會容錯移轉流量。建議您使用 API，而不是在 中變更路由控制狀態 AWS Management Console。

連線至 的其中一個區域叢集端點ARC，以使用資料平面 API。如果端點無法使用，請嘗試連線至另一個叢集端點。

如果安全規則封鎖路由控制狀態更新，您可以繞過它進行更新並容錯移轉流量。如需詳細資訊，請參閱覆寫安全規則以重新路由流量。

使用ARC路由控制定期測試容錯移轉，從主要應用程式堆疊容錯移轉到次要應用程式堆疊。請務必確保您新增的ARC結構與堆疊中的正確資源相符，而且一切都如您預期般運作。您應該ARC在為環境設定 之後進行測試，並繼續定期進行測試，以便您的容錯移轉環境做好準備，之後才能遇到需要次要系統快速啟動和執行的故障情況，以避免使用者停機。