區域服務 - AWS 故障隔離界限

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

區域服務

可用區域獨立性 (AZI) 能 AWS 夠提供區域服務,例如 Amazon EC2 和 Amazon EBS。區域服務是提供指定資源部署到哪個可用區域的能力的服務。這些服務在區域內的每個可用區域中獨立運作,更重要的是,在每個可用區域也會獨立失敗。這表示一個可用區域中的服務元件不會取得其他可用區域中元件的相依性。我們可以這樣做是因為區域服務具有區域資料平面。在某些情況下,例如 EC2,該服務還包括用於區域對齊操作的區域控制平面,例如啟動 EC2 執行個體。對於這些服務, AWS 還提供區域控制平面端點,以便於與服務互動。區域控制平面還提供區域範圍的功能,以及作為區域控制平面頂部的聚合和路由層。這顯示在下圖中。

此影像顯示具有區域隔離控制平面和資料平面的區域服務

區域隔離控制平面和資料平面的區域服務

可用區域讓客戶能夠操作比單一資料中心更具高可用性、容錯能力和可擴充性的生產工作負載。當工作負載使用多個可用區域時,客戶可以更好地隔離並避免影響單一可用區域實體基礎架構的問題。這有助於客戶建置跨可用區域備援的服務,如果架構正確,即使一個可用區域發生故障,仍可保持運作。客戶可以利用 AZI 建立高可用性和彈性的工作負載。在您的架構中實作 AZI 可協助您從隔離的可用區域故障中快速復原,因為您在一個可用區域中的資源可最小化或消除與其他可用區域中的資源互動。這有助於移除跨可用區域相依性,進而簡化可用區域疏散。如需建立可用區域撤離機制的詳細資訊,請參閱進階異地同步備份復原模式。此外,您可以遵循其自身服務 AWS 使用的一些相同的最佳作法,例如一次只將變更部署到單一可用區域,或者在可用區域中發生嚴重變更時,從服務中移除可用區域,以進一步利用可用區域。

靜態穩定性也是多可用區域架構的重要概念。您應該規劃使用多可用區域架構的故障模式之一是可用區域的遺失,這可能會導致可用區域的容量損失。如果您沒有預先佈建足夠的容量來處理可用區域的損失,這可能會導致剩餘的容量因目前的負載而不堪重負。此外,您將需要依賴用於替換損失容量的區域服務的控制平面,與靜態穩定的設計相比,可靠性較低。在這種情況下,預先佈建足夠的額外容量可協助您在不需要動態變更的情況下繼續正常作業,以防遺失容錯網域 (例如可用區域),從而保持靜態穩定。

您可以選擇使用跨多個可用區域部署的 EC2 執行個體 auto 動調整規模群組,根據工作負載的需求動態擴展和擴展。自動縮放功能適用於在數分鐘到數十分鐘內逐漸變化的使用情況。但是,啟動新的 EC2 執行個體需要時間,尤其是在執行個體需要啟動載入時 (例如安裝代理程式、應用程式二進位檔案或組態檔)。在此期間,您剩餘的容量可能會因目前的負載而不堪重負。此外,透過 auto 擴展部署新執行個體也依賴 EC2 控制平面。這提供了一個權衡:為了在單一可用區域遺失時保持靜態穩定,您需要在其他可用區域預先佈建足夠的 EC2 執行個體,以處理已從受損可用區域轉移出來的負載,而不是依賴 auto 擴展佈建新執行個體。不過,預先佈建額外容量可能會產生額外費用。

例如,在正常操作期間,假設您的工作負載需要六個執行個體來服務跨三個可用區域的客戶流量。為了在單一可用區域故障時保持靜態穩定,您需要在每個可用區域部署三個執行個體,總共九個執行個體。如果單一可用區域值的執行個體失敗,您仍然可以剩下六個,並且能夠繼續為客戶流量提供服務,而無需在故障期間佈建和設定新的執行個體。實現 EC2 容量的靜態穩定性需要額外的費用,因為在這種情況下,您會額外執行 50% 的執行個體。並非所有可預先佈建資源的服務都會產生額外費用,例如預先佈建 S3 儲存貯體或使用者。您將需要權衡實施靜態穩定性的任何權衡,以免超過工作負載所需的復原時間的風險。

AWS Local Zones 和 Outposts 使特定 AWS 服務的數據平面更接近最終用戶。這些服務的控制平面位於父區域中。在您建立本機區域或 Outposts 子網路的可用區域上,您的本機區域或 Outposts 執行個體將具有區域服務 (例如 EC2 和 EBS) 的控制平面相依性。他們也會依賴區域服務的區域控制平面,例如 Elastic Load Balancing (ELB)、安全群組和 Amazon Elastic Kubernetes Service (Amazon EKS) 受管 Kubernetes 控制平面 (如果您使用 EKS)。有關 Outposts 的其他特定信息,請參閱文檔以及支持和維護常見問題解答。使用 Local Zones 或 Outposts 時實現靜態穩定性,以幫助提高控制平面損傷或與父區域的網絡連接中斷的彈性。