本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # ARC 中路由控制的最佳實務 針對 ARC 中的路由控制，我們建議採用下列復原和容錯移轉準備的最佳實務。 **主題** + [確保專用、長期的 AWS 登入資料安全且隨時可存取](#RCBestPracticeCredentials) + [為涉及容錯移轉的 DNS 記錄選擇較低的 TTL 值](#RCBestPracticeLowerTTL) + [限制用戶端保持連線至端點的時間](#RCBestPracticeCurrentConnections) + [將五個區域叢集端點和路由控制 ARNs 加入書籤或硬式程式碼](#RCBestPracticeBookmarkEndpoints) + [隨機選擇其中一個端點以更新您的路由控制狀態](#RCBestPracticeRandomEndpoint) + [使用非常可靠的資料平面 API 來列出和更新路由控制狀態，而不是主控台](#RCBestPracticeUseDataPlane) **確保專用、長期的 AWS 登入資料安全且隨時可存取** 在災難復原 (DR) 案例中，使用存取 AWS 和執行復原任務的簡單方法，將系統相依性降至最低。建立專門用於 DR 任務[的 IAM 長期憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)，並將憑證安全地保存在現場部署實體安全或虛擬保存庫中，以在需要時存取 。透過 IAM，您可以集中管理安全登入資料，例如存取金鑰，以及存取 AWS 資源的許可。對於非 DR 任務，我們建議您繼續使用聯合存取，並使用 AWS [AWS Single Sign-On](https://aws.amazon.com/single-sign-on/) 等服務。 若要使用復原叢集資料平面 API 在 ARC 中執行容錯移轉任務，您可以將 ARC IAM 政策連接至使用者。如需詳細資訊，請參閱 [Amazon Application Recovery Controller (ARC) 中的身分型政策範例](security_iam_id-based-policy-examples.md)。 **為涉及容錯移轉的 DNS 記錄選擇較低的 TTL 值** 對於可能需要在容錯移轉機制中變更的 DNS 記錄，尤其是使用較低的 TTL 值檢查的運作狀態的記錄是適當的。在這種情況下，將 TTL 設為 60 秒或 120 秒是常見的選擇。 DNS TTL （存留時間） 設定會告知 DNS 解析程式在請求新的記錄之前快取記錄的時間。當您選擇 TTL 時，您可以權衡延遲和可靠性，以及對變更的回應能力。當記錄的 TTL 較短時，DNS 解析程式會更快地通知記錄更新，因為 TTL 指定他們必須更頻繁地查詢。 如需詳細資訊，請參閱 [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html) *DNS 最佳實務中的選擇 DNS 記錄的 TTL 值*。 **限制用戶端保持連線至端點的時間** 當您使用路由控制從一個路由到 AWS 區域 另一個路由時，Amazon Application Recovery Controller (ARC) 用來移動應用程式流量的機制是 DNS 更新。此更新會導致所有新連線被導向到受損的位置之外。 不過，具有預先存在開放連線的用戶端可能會繼續對受損位置提出請求，直到用戶端重新連線為止。為了確保快速復原，建議您限制用戶端保持連線至端點的時間。 如果您使用 Application Load Balancer，您可以使用 `keepalive`選項來設定連線持續的時間。如需詳細資訊，請參閱《Application Load Balancer 使用者指南》中的 [ HTTP 用戶端保持連線持續時間](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#http-client-keep-alive-duration)。 根據預設，Application Load Balancer 會將 HTTP 用戶端持續作用持續時間值設定為 3600 秒或 1 小時。我們建議您降低值，使其與應用程式的復原時間目標保持一致，例如 300 秒。當您選擇 HTTP 用戶端保持連線持續時間時，請考慮此值是在一般情況下更頻繁重新連線、可能影響延遲，以及更快速地將所有用戶端移離受損的可用區域或區域之間的取捨。 **將您的五個區域叢集端點和路由控制 ARNs 加入書籤或硬式程式碼** 建議您將 ARC 區域叢集端點的本機副本保留在書籤中，或儲存在用來重試端點的自動化程式碼中。在失敗事件期間，您可能無法存取某些 API 操作，包括未託管在極可靠資料平面叢集上的 ARC API 操作。您可以使用 [DescribeCluster](https://docs.aws.amazon.com/recovery-cluster/latest/api/cluster-clusterarn.html) API 操作列出 ARC 叢集的端點。 **隨機選擇其中一個端點以更新您的路由控制狀態** 路由控制提供五個區域端點，以確保高可用性，即使在處理故障時也是如此。為了實現完整的彈性，請務必具有可視需要使用所有五個端點的重試邏輯。如需搭配 AWS SDK 使用程式碼範例的資訊，包括嘗試叢集端點的範例，請參閱 [使用 AWS SDKs的應用程式復原控制器程式碼範例](service_code_examples.md)。 **使用非常可靠的資料平面 API 來列出和更新路由控制狀態，而不是主控台** 使用 ARC 資料平面 API，使用 [ListRoutingControls](https://docs.aws.amazon.com/routing-control/latest/APIReference/API_ListRoutingControls.html) 操作檢視您的路由控制和狀態，並使用 [UpdateRoutingControlState](https://docs.aws.amazon.com/routing-control/latest/APIReference/API_UpdateRoutingControlState.html) 操作更新路由控制狀態以重新導向容錯移轉的流量。您可以使用 AWS CLI [（如這些範例所示）](getting-started-cli-routing.control-state.md) 或使用其中一個 AWS SDKs 撰寫的程式碼。ARC 透過資料平面中的 API 提供極高的可靠性，以容錯移轉流量。建議您使用 API，而不是在 中變更路由控制狀態 AWS 管理主控台。 連線至其中一個區域叢集端點，讓 ARC 使用資料平面 API。如果端點無法使用，請嘗試連線至另一個叢集端點。 如果安全規則封鎖路由控制狀態更新，您可以略過它以進行更新並容錯移轉流量。如需詳細資訊，請參閱[覆寫安全規則以重新路由流量](routing-control.override-safety-rule.md)。 **使用 ARC 測試容錯移轉** 使用 ARC 路由控制定期測試容錯移轉，從主要應用程式堆疊容錯移轉至次要應用程式堆疊。請務必確保您新增的 ARC 結構與堆疊中的正確資源一致，而且一切都如您預期般運作。您應該在為您的環境設定 ARC 之後進行測試，並繼續定期測試，以便在遇到需要次要系統快速啟動和執行以避免使用者停機的故障情況之前，準備好您的容錯移轉環境。