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

# 考慮失敗模式
<a name="thinking-in-terms-of-failure-modes"></a>

設計高可用性應用程式或系統時，您必須考量哪些元件可能失敗、元件故障對系統的影響，以及應用程式 [RPO/RTO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 目標，以及您可以實作哪些機制來緩解或消除元件故障的影響。您的應用程式是在單一伺服器、單一機架或單一資料中心執行？ 當伺服器、機架或資料中心發生暫時性或永久故障時，會發生什麼情況？ 當聯網等關鍵子系統或應用程式本身發生故障時，會發生什麼情況？ 這些是失敗模式。

 規劃 Outpost 和應用程式部署時，您應該考慮本節中的失敗模式。以下各節將說明如何緩解這些失敗模式，為您的應用程式環境提供更高水準的高可用性。

## 失敗模式 1：網路
<a name="failure-mode-1-network"></a>

 Outpost 部署取決於與其父區域的彈性連線，以進行管理和監控。網路中斷可能由各種故障造成，例如操作員錯誤、設備故障和服務提供者中斷。當 Outpost 無法透過 Service Link 與區域通訊時，可能包含在網站中連接在一起的一或多個機架。

 備援網路路徑有助於降低中斷連線事件的風險。您應該映射應用程式相依性和網路流量，以了解中斷連線事件對工作負載操作的影響。規劃足夠的網路備援，以符合您的應用程式可用性需求。

 在中斷連線事件期間，在 Outpost 上執行的執行個體會繼續執行，並可透過 Outpost Local Gateway (LGW) 從內部部署網路存取。如果本機工作負載和服務依賴 區域中的服務，可能會受損或失敗。將請求 （例如在 Outpost 上啟動或停止執行個體）、控制平面操作和服務遙測 （例如，CloudWatch 指標） 在 Outpost 與區域中斷連線時將會失敗。CloudWatch 指標會在您的 Outpost 上於本機進行多工緩衝處理，短暫中斷網路連線，並在重新建立服務連結連線時，傳送至 區域以供檢閱。

## 失敗模式 2：執行個體
<a name="failure-mode-2-instances"></a>

 如果 Amazon EC2 執行個體執行的伺服器發生問題，或執行個體遇到作業系統或應用程式故障，則 Amazon EC2 執行個體可能會受損或失敗。應用程式如何處理這些類型的故障取決於應用程式架構。單體應用程式通常會使用應用程式或系統功能進行復原，而模組化服務導向或[微服務](https://aws.amazon.com/microservices)架構通常會取代失敗的元件，以維持服務的可用性。

您可以使用 Amazon EC2 Auto Scaling 群組等自動化機制，將失敗的執行個體取代為新的執行個體。執行個體自動復原可以重新啟動因伺服器故障而失敗的執行個體，前提是剩餘伺服器上有足夠的備用容量，而且服務連結仍然連線。

## 失敗模式 3：運算
<a name="failure-mode-3-compute-and-storage-servers"></a>

 伺服器可能會失敗或受損，而且可能需要因各種原因而停止運作 （暫時或永久），例如元件故障和排程維護操作。Outposts 機架上的服務如何處理伺服器故障和損害，會有所不同，並且取決於客戶如何設定高可用性選項。

 您應該訂購足夠的運算容量來支援`N+M`可用性模型，其中 `N` 是必要的容量，而 `M` 是佈建來因應伺服器故障的備用容量。

 故障伺服器的硬體替換是全受管 AWS Outposts 機架服務的一部分。 AWS 主動監控 Outpost 部署中所有伺服器和聯網裝置的運作狀態。如果需要執行實體維護， AWS 會安排時間造訪您的網站，以取代失敗的元件。佈建備用容量可讓您在運作狀態不佳的伺服器停止服務並取代時，保持工作負載彈性，避免主機故障。

## 失敗模式 4：機架或資料中心
<a name="failure-mode-4-racks-or-data-centers"></a>

 機架故障可能是因為機架的電力完全耗盡，或環境故障，例如因洪水或地震對資料中心造成冷卻或實體損壞。在標準資料中心電源維護期間，資料中心電源分佈架構的不足或錯誤可能會導致一個或多個機架或整個資料中心的電源中斷。

 這些案例可以透過將基礎設施部署到同一個校園或都會區中彼此獨立的多個資料中心樓層或位置來緩解。

 採用此方法搭配 AWS Outposts 機架時，需要仔細考慮應用程式如何建構和分佈，以跨多個不同的邏輯 Outpost 執行，以維持應用程式的可用性。

## 失敗模式 5： AWS 可用區域或區域
<a name="failure-mode-5-aws-availability-zone-or-region"></a>

 每個 Outpost 錨定到 內的特定可用區域 (AZ) AWS 區域。錨點 AZ 或父區域中的故障可能會導致 Outpost 管理和可變性遺失，並可能中斷 Outpost 和 區域之間的網路通訊。

 與網路故障類似，AZ 或區域故障可能會導致 Outpost 與區域中斷連線。在 Outpost 上執行的執行個體會繼續執行，並可透過 Outpost Local Gateway (LGW) 從內部部署網路存取，如果它們依賴 區域中的服務，則可能會受損或失敗，如前所述。

 若要減輕 AZ AWS 和區域故障的影響，您可以將多個 Outpost 分別部署到不同的 AZ 或區域。然後，您可以使用許多類似的[機制和架構模式，設計工作負載以在分散式多點部署模型中操作，這些機制和架構模式](https://docs.aws.amazon.com/whitepapers/latest/fault-tolerant-components/high-availability-building-blocks.html)是您目前用來設計和部署的 AWS 。

在 上執行的服務控制平面 AWS Outposts 位於其錨定的區域中，在 Amazon EC2 和 Amazon EBS 等區域服務以及 Amazon RDS、Elastic Load Balancing 和 Amazon EKS 等區域服務上產生相依性。在 Outposts 中，應用程式可以在[靜態穩定性](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html)的概念下部署，以協助改善彈性以控制平面受損。