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

# 數據平面控制疏散
<a name="data-plane-controlled-evacuation"></a>

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

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

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

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

## 路線 53 應用程式復原控制器 (ARC) 中的區域移位
<a name="zonal-shift-in-route-53-application-recovery-controller-arc"></a>

 可用區域疏散使用的第一個解決方案[53 號公路弧的區域轉移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)。此解決方案可用於使用 NLB 或 ALB 作為客戶流量輸入點的請求/回應工作負載。

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

![顯示區域偏移的圖表。](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/zonal-shift.png)


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

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

## Route 53 ARC
<a name="route-53-arc"></a>

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

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


|  |  |  | 
| --- |--- |--- |
|  **路由策略**: 加權 <br /> **名稱:** `www.example.com` <br /> **类型**:`A`（別名） <br /> **Value (值)**：`us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量**:`100` <br /> **評估目標健康**: 真  |  **路由策略：**加權 <br /> **名稱:** `www.example.com` <br /> **類型:** `A`（別名） <br /> **值：**` us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量:** `100` <br /> **評估目標健康狀況：** `true` |  **路由策略：**加權 <br /> **名稱:** `www.example.com` <br /> **類型:** `A`（別名） <br /> **值：**` us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量:** `100` <br /> **評估目標健康狀況：** `true` | 

 對於這些 DNS 記錄中的每一個，您都需要設定與路由 53 ARC 相關聯的路由 53 健康狀態檢查[路由控制](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.html)。當您要啟動可用區域撤離時，請將路由控制狀態設定為`Off`。AWS建議您使用 CLI 或 API 執行此操作，以便將啟動可用區域撤離所需的相依性降至最低。作為[最佳做法](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html)，您應該保留 Route 53 ARC 叢集端點的本機副本，以便在需要執行疏散時不需要從 ARC 控制平面擷取這些端點。

若要將使用此方法時的成本降至最低，您可以在單一建立單一 Route 53 ARC 叢集和健康狀態檢查AWS 帳戶和[與其他人共用健康檢查AWS 帳戶](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-cross-account-health-checks/)在您的組織中。當您採用這種方法時，您應該使用[可用區域識別碼](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)(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`。您將使用健康檢查 ID`0385ed2d-d65c-4f63-a19b-2412a31ef431`設置了該資源記錄。

## 使用自我管理的 HTTP 端點
<a name="using-a-self-managed-http-endpoint"></a>

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

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

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

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

![顯示多種工作負載類型的圖表都可以使用 HTTP 端點解決方案](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/http-endpoint-solution.png)


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

### 使用 Amazon S3
<a name="using-amazon-s3"></a>

 這種模式最初是在這裡提出的[部落格文章](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)適用於多區域災難復原。您可以使用相同的模式進行可用區域撤離。

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

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


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
|  **健康檢查類型**:<br /> 監視端點 <br /> **Protocol (通訊協定)**：`HTTPS`<br /> **識別碼**:`dddd-4444` <br /> **網址**:`https://{{bucket-name}}.s3.us-east-1.amazonaws.com/use1-az1.txt ` |  **健康檢查類型**: <br /> 監視端點 <br /> **Protocol (通訊協定)**：`HTTPS`<br /> **識別碼**:`eeee-5555 `<br /> **網址**:` https://{{bucket-name}}.s3.us-east-1.amazonaws.com/use1-az3.txt ` |  **健康檢查類型**: <br /> 監視端點 <br /> **Protocol (通訊協定)**：`HTTPS`<br /> **識別碼**:`ffff-6666 `<br /> **網址**:`https://{{bucket-name}}.s3.us-east-1.amazonaws.com/use1-az2.txt ` |  ←  |  健康檢查  | 
|  ↑  |  ↑  |  ↑  |   |   | 
|  **路由策略**: 加權 <br /> **名稱:** `www.example.com` <br /> **类型**:`A`（別名） <br /> **Value (值)**：`us-east-1b.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量**:`100` <br /> **評估目標健康**:`true`  |  **路由策略：**加權 <br /> **名稱:** `www.example.com` <br /> **類型:** `A`（別名） <br /> **Value (值)**：`us-east-1a.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量:** `100` <br /> **評估目標健康狀況：** `true` |  **路由策略：**加權 <br /> **名稱:** `www.example.com` <br /> **類型:** `A`（別名） <br /> **Value (值)**：`us-east-1c.load-balancer-name.elb.us-east-1.amazonaws.com`<br /> **重量:** `100` <br /> **評估目標健康狀況：** `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`。

![顯示使用 Amazon S3 做為路線 53 運作狀態檢查目標的圖表](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/s3-for-route53-health-check.png)


### 使用 API 閘道和動態支援
<a name="using-api-gateway-and-dynamodb"></a>

 這種模式的第二個實現使用[亞馬遜 API 閘道](https://aws.amazon.com/api-gateway/) [休息 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)。該 API 配置了[服務整合](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-integration-types.html)傳送至 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 運作狀態檢查目標的圖表](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/apigw-ddb-route53-health-checks.png)


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

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

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

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

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

 發送推送通知的第二種方式是長壽WebSocket連接。亞馬遜 API 網關可用於提供[WebSocketAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html)消費者可以在以下情況下連接並接收消息[由後端發送](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-data-from-backend.html)。用一個WebSocket，執行個體都可以執行定期提取，以確保連線狀態良好，並接收低延遲推送通知。