本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
控制平面控制疏散
第一個模式使用資料平面作業來防止在受影響的可用區域中執行工作,以減輕事件的影響。但是,您可能使用的架構不使用負載平衡器,或者設定每台主機健康狀態檢查是不可行的。或者,您可能想要透過 Auto Scaling 或正常工作排程,防止將新容量部署到受影響的可用區域。
為了解決這兩種情況,需要控制平面動作來更新資源的配置。該模式適用於任何可更新網路組態的服務,例如 EC2 自動擴展、Amazon ECS、Lambda 等。它需要為每個服務編寫代碼,但業務邏輯遵循標準模式。程式碼應由回應事件的運算子在本機執行,以減少所需的相依性。腳本邏輯的基本流程如下圖所示。

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

控制平面更新以從可用區域撤離中恢復
恢復步驟:
-
查詢 GSI 以取得針對指定可用區域中指定類型的每個資源移除子網路 (如果未指定所有可用區域)。
-
描述 DynamoDB 查詢中找到的每個資源,以取得其目前的網路組態。
-
將目前網路組態中的子網路與從 DynamoDB 查詢擷取的子網路結合在一起。
-
使用新的子網路集更新資源的網路組態。
-
成功完成更新後,請從 DynamoDB 表格中移除記錄。
此一般化模式可防止將工作路由傳送至受影響的可用區域,並防止在該處部署新容量。以下是如何針對不同服務完成此操作的範例。
-
拉姆達-更新功能虛擬私人雲端組以移除指定可用區域中的子網路。
-
自動縮放群組—從 ASG 組態移除子網路這將取代剩餘可用區域中的該容量。
-
亞馬遜 ECS—更新 ECS 服務虛擬私人雲端組態以移除子網路。
-
亚马逊 EKS— 申請污點
至受影響可用區域中的節點,以收回現有的網繭,並防止在該處排程其他網繭。
每個服務都會對組態更新做出不同的反應。例如,亞馬遜 ECS 將遵循更新後的服務部署組態並觸發新任務的滾動部署或藍/綠部署。
對於某些工作負載,這些更新可能會過快地將工作轉移到正常運作的可用區 雖然設定為靜態穩定以防止故障 (在剩餘可用區域中預先佈建足夠的容量以處理受影響的可用區域的工作),但您也可能想要逐漸從受影響的可用區域逐步淘汰容量。
如果您計劃更新 Auto Scaling 群組的網路組態,該群組是具有跨區域負載平衡功能之負載平衡器的目標群組殘疾人,請遵循此指導。
「自動縮放」會使用其對此變更做出反應可用性區域重新平衡邏輯。它會在其他可用區域中啟動執行個體,以符合您所需的容量,並在您移除的可用區域中終止執行個體。不過,負載平衡器會繼續在每個可用區域中平均分割流量,包括您從 ASG 移除的可用區域,同時終止執行個體。這可能會導致該可用區域的剩餘容量失效,直到所有執行個體在該處成功終止為止。這與中描述的相同問題可用區域獨立關於停用跨區域負載平衡時的可用區域不平衡。為了防止這種情況發生,您可以:
-
始終首先執行可用區域疏散,以便流量僅在剩餘的可用區域中分割
-
指定DNS 容錯移轉的最小健全目標計數以符合該可用區域所需的最低目標計數。
這有助於確保在執行個體開始終止之後,流量不會傳送到您移除的可用區域。