控制平面控制疏散 - 進階異地同步備份復原模

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

控制平面控制疏散

第一個模式使用資料平面作業來防止在受影響的可用區域中執行工作,以減輕事件的影響。但是,您可能使用的架構不使用負載平衡器,或者設定每台主機健康狀態檢查是不可行的。或者,您可能想要透過 Auto Scaling 或正常工作排程,防止將新容量部署到受影響的可用區域。

為了解決這兩種情況,需要控制平面動作來更新資源的配置。該模式適用於任何可更新網路組態的服務,例如 EC2 自動擴展、Amazon ECS、Lambda 等。它需要為每個服務編寫代碼,但業務邏輯遵循標準模式。程式碼應由回應事件的運算子在本機執行,以減少所需的相依性。腳本邏輯的基本流程如下圖所示。

顯示撤離可用區域的控制平面更新圖表

控制平面更新以撤除可用區域

  1. 指令碼會列出指定類型的所有資源,例如自動擴展群組、ECS 服務或 Lambda 函數,並從資源資訊擷取其子網路。支援的資源取決於指令碼已設定為支援的資源。

  2. 它會將每個子網路的可用區域名稱與其作為輸入參數提供的對應可用區域識別碼進行比較,判斷應移除哪些子網路。

  3. 資源的網路組態會更新,以移除已識別的子網路。

  4. 更新的詳細資訊會記錄在 DynamoDB 資料表中。可用區域 ID 會儲存為分割索引鍵並且資源 ARN 或名稱存儲為排序鍵。已移除的子網路會儲存為字串陣列。最後,資源類型也被存儲並用作哈希鍵全球次要指數(GSI).

因為步驟四會記錄所做的更新,所以當您準備好復原時,這個方法也可以輕鬆復原,如下圖所示。

顯示從可用區域撤離中復原的控制平面更新的圖表

控制平面更新以從可用區域撤離中恢復

恢復步驟:

  1. 查詢 GSI 以取得針對指定可用區域中指定類型的每個資源移除子網路 (如果未指定所有可用區域)。

  2. 描述 DynamoDB 查詢中找到的每個資源,以取得其目前的網路組態。

  3. 將目前網路組態中的子網路與從 DynamoDB 查詢擷取的子網路結合在一起。

  4. 使用新的子網路集更新資源的網路組態。

  5. 成功完成更新後,請從 DynamoDB 表格中移除記錄。

此一般化模式可防止將工作路由傳送至受影響的可用區域,並防止在該處部署新容量。以下是如何針對不同服務完成此操作的範例。

每個服務都會對組態更新做出不同的反應。例如,亞馬遜 ECS 將遵循更新後的服務部署組態並觸發新任務的滾動部署或藍/綠部署。

對於某些工作負載,這些更新可能會過快地將工作轉移到正常運作的可用區 雖然設定為靜態穩定以防止故障 (在剩餘可用區域中預先佈建足夠的容量以處理受影響的可用區域的工作),但您也可能想要逐漸從受影響的可用區域逐步淘汰容量。

如果您計劃更新 Auto Scaling 群組的網路組態,該群組是具有跨區域負載平衡功能之負載平衡器的目標群組殘疾人,請遵循此指導。

「自動縮放」會使用其對此變更做出反應可用性區域重新平衡邏輯。它會在其他可用區域中啟動執行個體,以符合您所需的容量,並在您移除的可用區域中終止執行個體。不過,負載平衡器會繼續在每個可用區域中平均分割流量,包括您從 ASG 移除的可用區域,同時終止執行個體。這可能會導致該可用區域的剩餘容量失效,直到所有執行個體在該處成功終止為止。這與中描述的相同問題可用區域獨立關於停用跨區域負載平衡時的可用區域不平衡。為了防止這種情況發生,您可以:

這有助於確保在執行個體開始終止之後,流量不會傳送到您移除的可用區域。