數據平面控制疏散

您可以實作多種解決方案，以使用僅限資料計劃的動作執行可用區域疏散。本節將介紹其中的三個以及您可能想要選擇另一個的用例。

使用上述任何解決方案時，您必須確保剩餘可用區域中有足夠的容量，以處理您要轉離的可用區域負載。最有彈性的方法是在每個可用區域中預先佈建所需的容量。如果您使用三個可用區域，您將擁有 50% 的所需容量來處理每個區域中部署的尖峰負載，如此一來，單一可用區域的遺失仍會保留所需容量的 100%，而不必依賴控制平面來佈建更多。

此外，如果您使用 EC2 Auto Scaling，請確保您的 Auto Scaling 群組 (ASG) 在輪班期間不會擴展，以便在班次結束時，群組中仍有足夠的容量來處理客戶流量。您可以確保 ASG 的最低所需容量能夠處理您目前的客戶負載，以達到這個目的。您也可以在指標中使用平均值，而不是 P90 或 P99 等離群值的百分位數量，協助確保 ASG 不會意外擴展。

在輪班期間，不再為流量提供服務的資源應該具有非常低的使用率，但其他資源會增加其對新流量的使用率，從而保持平均水平相當一致，這將阻止擴展行動。最後，您也可以使用目標群組健全狀況設定ALB和NLB，以指定具有健全狀況主機的百分比或計數的 DNS 容錯移轉。這樣可防止流量路由到沒有足夠健全主機的可用區域。

路線 53 應用程式復原控制器 (ARC) 中的區域移位

可用區域疏散使用的第一個解決方案53 號公路弧的區域轉移。此解決方案可用於使用 NLB 或 ALB 作為客戶流量輸入點的請求/回應工作負載。

當您偵測到可用區域已受損時，您可以使用 Route 53 ARC 啟動區域轉移。一旦此作業完成且現有的快取 DNS 回應過期，所有新要求都只會路由至剩餘可用區域中的資源。下圖顯示了區域偏移的工作原理。在下圖中，我們有一個 Route 53 別名記錄www.example.com指向my-example-nlb-4e2d1f8bb2751e6a.elb.us-east-1.amazonaws.com。會針對可用區域 3 執行區域轉移。

區域移位

在此範例中，如果主要資料庫執行處理不在可用區域 3 中，則執行區域轉移是達到第一個疏散結果所需的唯一動作，以防止在受影響的可用區域中處理工作。如果主節點位於可用區域 3，則如果 Amazon RDS 尚未自動容錯移轉，則您可以與區域轉移協調執行手動啟動的容錯移轉 (確實依賴於 Amazon RDS 控制平面)。本節中所有資料平面控制的解決方案都是如此。

您應該使用 CLI 命令或 API 啟動區域轉移，以最大程度地減少啟動撤離所需的依賴關係。疏散過程越簡單，它就越可靠。特定的命令可以存儲在本地 runbook 中，隨時待命的工程師可以輕鬆訪問。區域轉移是疏散可用區域的最優選和最簡單的解決方案。

Route 53 ARC

第二個解決方案使用 Route 53 ARC 的功能手動指定特定 DNS 記錄的健康狀態。此解決方案具有使用高可用性 Route 53 ARC 群集數據平面的好處，使其能夠恢復多達兩個不同的損害AWS 區域。它具有額外費用的權衡，並且需要一些額外的 DNS 記錄配置。若要實作此模式，您需要建立別名記錄可用性區域特定的 DNS 名稱由負載平衡器 (ALB 或 NLB) 提供。這顯示在下表中。

表 3：為負載平衡器的區域 DNS 名稱設定的路由 53 別名記錄

路由策略: 加權 名稱: www.example.com 类型:A（別名） Value (值)：us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com 重量:100 評估目標健康: 真

路由策略：加權 名稱: www.example.com 類型: A（別名） 值： us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com 重量: 100 評估目標健康狀況： true

路由策略：加權 名稱: www.example.com 類型: A（別名） 值： us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com 重量: 100 評估目標健康狀況： true

對於這些 DNS 記錄中的每一個，您都需要設定與路由 53 ARC 相關聯的路由 53 健康狀態檢查路由控制。當您要啟動可用區域撤離時，請將路由控制狀態設定為Off。AWS建議您使用 CLI 或 API 執行此操作，以便將啟動可用區域撤離所需的相依性降至最低。作為最佳做法，您應該保留 Route 53 ARC 叢集端點的本機副本，以便在需要執行疏散時不需要從 ARC 控制平面擷取這些端點。

若要將使用此方法時的成本降至最低，您可以在單一建立單一 Route 53 ARC 叢集和健康狀態檢查AWS 帳戶和與其他人共用健康檢查AWS 帳戶在您的組織中。當您採用這種方法時，您應該使用可用區域識別碼(AZ-識別碼) (例如，use1-az1) 而非可用區域名稱 (例如，us-east-1a）用於您的路由控件。因為AWS將實體可用區域隨機對應至每個區域的可用區域名稱AWS 帳戶，使用 AZ-ID 可提供一致的方式來參考相同的實體位置。當您啟動可用區撤離時，請說use1-az2，每個路線 53 記錄集AWS 帳戶應確保他們使用 AZ-ID 對應來為每個 NLB 記錄配置正確的健康狀態檢查。

例如，假設我們有一個 Route 53 健康狀態檢查與 Route 53 ARC 路由控制項相關聯use1-az2，其識別碼為0385ed2d-d65c-4f63-a19b-2412a31ef431。如果在不同AWS 帳戶想要使用此健康檢查，us-east-1c已對應至use1-az2，您將需要使用use1-az2健康檢查記錄us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com。您將使用健康檢查 ID0385ed2d-d65c-4f63-a19b-2412a31ef431設置了該資源記錄。

使用自我管理的 HTTP 端點

您也可以透過管理指出特定可用區域狀態的 HTTP 端點來實作此解決方案。它可讓您根據 HTTP 端點的回應，手動指定可用區域何時運作狀況不佳。此解決方案的成本低於使用 Route 53 ARC，但比區域轉移昂貴，並且需要管理額外的基礎架構。它具有針對不同場景更加靈活的好處。

該模式可用於 NLB 或 ALB 架構以及 Route 53 健康狀態檢查。它也可用於非負載平衡架構，例如服務探索或佇列處理系統，其中工作者節點會執行自己的健康狀態檢查。在這些情況下，主機可以使用後台線程，在該線程中定期使用其 AZ-ID 向 HTTP 端點發出請求（請參閱附錄 A — 取得可用區域識別碼 有關如何找到這個的詳細信息）並收到有關可用區域運行狀況的響應。

如果可用區域已宣告為健康狀況不佳，則有多個選項可用於如何回應。他們可能會選擇不通過來源 (例如 ELB、Route 53 或服務探索架構中的自訂健康狀態檢查) 進行外部健康狀態檢查，以使這些服務看起來不健康。他們也可以在收到要求時立即回應錯誤，以允許用戶端退回並重試。在事件導向架構中，節點可能會故意無法處理工作，例如故意將 SQS 訊息傳回佇列。在中央服務計劃在特定主機上工作的工作路由器架構中，您也可以使用此模式。在選取 Worker、端點或儲存格之前，路由器可以檢查可用區域的狀態。在使用的服務探索架構中AWS Cloud Map，您可以通過在請求中提供過濾器來發現端點，例如 AZ-識別碼。

下圖顯示如何將此方法用於多種類型的工作負載。

多種工作負載類型都可以使用 HTTP 端點解決方案

有多種方法可以實現 HTTP 端點方法，其中兩種方法接下來概述。

使用 Amazon S3

這種模式最初是在這裡提出的部落格文章適用於多區域災難復原。您可以使用相同的模式進行可用區域撤離。

在這個案例中，您會為每個區域 DNS 記錄建立 Route 53 DNS 資源記錄集，就像53 號公路弧上述情況以及相關的健康狀態檢查。不過，對於此實作，而不是將健康狀態檢查與 Route 53 ARC 路由控制項產生關聯，而是將它們設定為使用端點並反轉以防止 Amazon S3 中的損害意外觸發撤離。健康檢查被考慮健康當對象不存在時不健康當對象存在時。此設定如下表所示。

表 4：針對每個可用區域使用 Route 53 健康狀態檢查的 DNS 記錄組態

健康檢查類型: 監視端點 Protocol (通訊協定)：HTTPS 識別碼:dddd-4444 網址:https://bucket-name.s3.us-east-1.amazonaws.com/use1-az1.txt	健康檢查類型: 監視端點 Protocol (通訊協定)：HTTPS 識別碼:eeee-5555 網址: https://bucket-name.s3.us-east-1.amazonaws.com/use1-az3.txt	健康檢查類型: 監視端點 Protocol (通訊協定)：HTTPS 識別碼:ffff-6666 網址:https://bucket-name.s3.us-east-1.amazonaws.com/use1-az2.txt	←	健康檢查
↑	↑	↑
路由策略: 加權 名稱: www.example.com 类型:A（別名） Value (值)：us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com 重量:100 評估目標健康:true	路由策略：加權 名稱: www.example.com 類型: A（別名） Value (值)：us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com 重量: 100 評估目標健康狀況： true	路由策略：加權 名稱: www.example.com 類型: A（別名） Value (值)：us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com 重量: 100 評估目標健康狀況： true	←	頂層、均勻加權別名 A 記錄指向 NLB AZ 特定端點

讓我們假設可用區us-east-1a已對應至use1-az3在我們有一個工作負載的帳戶中，我們要執行可用區撤離。針對為建立的資源記錄集us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com會關聯測試 URL 的健康檢查https://bucket-name.s3.us-east-1.amazonaws.com/use1-az3.txt。當您想要啟動可用區域撤離use1-az3，上傳名為的檔案use1-az3.txt使用 CLI 或 API 連接到值區。該文件不需要包含任何內容，但它確實需要公開，以便 Route 53 健康檢查可以訪問它。下圖演示了這個實現被用來撤離use1-az3。

使用亞馬遜 S3 作為路線 53 運行狀態檢查的目標

使用 API 閘道和動態支援

這種模式的第二個實現使用亞馬遜 API 閘道 休息 API。該 API 配置了服務整合傳送至 Amazon DynamoDB，其中會儲存每個使用中可用區域的狀態。此實作比 Amazon S3 方法更靈活，但需要建置、操作和監控更多基礎設施。它也可以用於 Route 53 健康狀態檢查，以及個別主機執行的健康狀態檢查。

如果您將此解決方案與 NLB 或 ALB 架構搭配使用，請以與上述 Amazon S3 範例相同的方式設定 DNS 記錄，但變更運作狀態檢查路徑以使用 API 閘道端點並提供AZ-ID在網址路徑中。例如，如果 API 閘道配置了自訂網域az-status.example.com，完整的請求use1-az1會看起來像https://az-status.example.com/status/use1-az1。當您想要啟動可用區域撤離時，可以使用 CLI 或 API 建立或更新 DynamoDB 項目。該項目使用AZ-ID作為它的主鍵，然後有一個名為的布爾屬性Healthy用於表示 API 網關如何響應。以下是 API 閘道組態中用來決定此項目的範例程式碼。

#set($inputRoot = $input.path('$'))
#if ($inputRoot.Item.Healthy['BOOL'] == (false))
    #set($context.responseOverride.status = 500)
#end

如果屬性是true（或不存在），API 網關使用 HTTP 200 響應運行狀態檢查，如果它是假的，它會以 HTTP 500 進行響應。此實作如下圖所示。

使用 API 閘道和 DynamoDB 做為路由 53 運作狀態檢查的目標

在此解決方案中，您需要在 DynamoDB 前面使用 API 閘道，以便可以公開存取端點，並將請求 URL 操作為GetItem動態支援的請求。如果您想要在要求中包含其他資料，此解決方案也會提供彈性。例如，如果您想要建立更精細的狀態 (例如每個應用程式)，您可以設定健全狀況檢查 URL，以在路徑中提供應用程式 ID，或查詢字串也與 DynamoDB 項目相符。

可用區域狀態端點可集中部署，以便跨越多個健康狀態檢查資源AWS 帳戶所有人都可以使用可用區域健康狀態的相同一致性檢視 (確保您的 API 閘道 REST API 和 DynamoDB 表被調整以處理負載)，並且不需要共用 Route 53 運作狀態檢查。

該解決方案也可以擴展到多個AWS 區域使用亞馬遜全球表以及每個區域中 API 閘道 REST API 的副本。這樣可以防止此解決方案依賴於單一區域，並提高其可用性。您可以跨三個或五個區域部署解決方案，並使用大多數端點的結果來確保仲裁，每個區域查詢可用區域健全狀況。這允許在全域資料表中最終一致地複寫更新，以及減輕可能導致端點無法回應的損失。例如，如果您使用五個區域，而三個端點將可用區域報告為狀況不良，則一個端點會將可用區域報告為狀況良好，而一個端點沒有回應，您可以選擇將可用區域視為狀況不良。你也可以創建一個53 號路線計算健康檢查使用n 的米計算以執行此邏輯來判斷可用區域健全狀況。

如果您要為個別主機建置解決方案，以做為判斷其 AZ 健康狀態的機制，作為替代提供運作狀態檢查的提取機制，您可以使用推送通知。一種方法是使用您的消費者訂閱的 SNS 主題。當您想要觸發斷路器時，請將訊息發佈至 SNS 主題，指出哪個可用區域受損。這種方法使得與前者的權衡。它不需要建立和操作 API 閘道基礎結構，以及執行容量管理。它也可能提供可用區域狀態的更快速整合。不過，它會移除執行隨機查詢的能力，並依賴於SNS 傳遞重試政策以確保每個端點都會收到通知。它還需要每個工作負載或服務建立一種接收 SNS 通知並對其採取行動的方式。

例如，啟動的每個新 EC2 執行個體或容器都需要在啟動期間使用 HTTP 端點訂閱主題。然後，每個執行個體都需要實作在傳送通知的此端點上偵聽的軟體。此外，如果執行個體受到事件影響，則可能不會收到推播通知並繼續執行工作。而透過提取通知，執行個體就會知道其提取要求是否失敗，並且可以選擇要採取的動作來回應。

發送推送通知的第二種方式是長壽WebSocket連接。亞馬遜 API 網關可用於提供WebSocketAPI消費者可以在以下情況下連接並接收消息由後端發送。用一個WebSocket，執行個體都可以執行定期提取，以確保連線狀態良好，並接收低延遲推送通知。