本文件正在進行更新。在此期間，部分內容可能不準確。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
以失敗模式思考
設計高可用性應用程式或系統時，您必須考量哪些元件可能失敗、元件故障對系統的影響，以及您可以實作哪些機制來減輕或消除元件故障的影響。您的應用程式是在單一伺服器、單一機架還是單一資料中心上執行？ 當伺服器、機架或資料中心發生暫時性或永久性故障時，會發生什麼情況？ 當聯網等關鍵子系統或應用程式本身發生故障時，會發生什麼情況？ 這些是失敗模式。
在規劃 Outpost 和應用程式部署時，您應該考慮本節中的失敗模式。以下各節將說明如何減輕這些失敗模式，為您的應用程式環境提供更高層級的高可用性。
失敗模式 1：網路
Outpost 部署取決於與其父區域的彈性連線，以進行管理和監控。網路中斷可能由各種故障造成，例如操作員錯誤、設備故障和服務供應商中斷。當 Outpost 無法透過 Service Link 與區域通訊時，可能由一個或多個在網站上連接在一起的機架所組成，因此會被視為中斷連線。
備援網路路徑有助於降低中斷連線事件的風險。您應該映射應用程式相依性和網路流量，以了解中斷連線事件對工作負載操作的影響。規劃足夠的網路備援，以符合您的應用程式可用性需求。
在中斷連線事件期間，在 Outpost 上執行的執行個體會繼續執行，並可透過 Outpost Local Gateway （） 從內部部署網路存取LGW。如果本機工作負載和服務依賴 區域中的服務，則可能會受損或失敗。將請求 （例如 Outpost 上的啟動或停止執行個體）、控制平面操作和服務遙測 （例如 CloudWatch 指標） 會在 Outpost 與區域中斷連線時失敗。
失敗模式 2：執行個體
EC2 如果執行個體執行的伺服器發生問題，或執行個體遇到作業系統或應用程式故障，執行個體可能會受損或失敗。應用程式如何處理這些類型的故障取決於應用程式架構。單體應用程式通常會使用應用程式或系統功能進行復原，而模組化服務導向或微服務架構通常會取代失敗的元件，以維持服務可用性。
您可以使用 EC2 Auto Scaling 群組等自動機制，將失敗的執行個體取代為新的執行個體。執行個體自動復原可以重新啟動因伺服器故障而失敗的執行個體，前提是剩餘伺服器上有足夠的備用容量可用。
失敗模式 3：運算
伺服器可能會失敗或受損，而且可能需要因各種原因停止運作 （暫時或永久），例如元件故障和排程維護操作。Outposts 機架上的服務如何處理伺服器故障和損害，取決於客戶設定高可用性選項的方式。
您應該訂購足夠的運算容量來支援N+M可用性模型，其中 N是必要的容量，並且M是佈建來容納伺服器故障的備用容量。
失敗伺服器的硬體替換是全受管 AWS Outposts 機架服務的一部分。 AWS 主動監控 Outpost 部署中所有伺服器和網路裝置的運作狀態。如果需要執行實體維護， AWS 會安排時間造訪您的網站，以取代失敗的元件。佈建備用容量可讓您在故障的伺服器停止服務並取代時，讓工作負載持續執行。
失敗模式 4：機架或資料中心
機架故障可能是因為機架完全斷電，或由於環境故障，例如因洪水或地震對資料中心造成冷卻或實體損壞。在標準資料中心電源維護期間，資料中心配電架構的缺陷或錯誤可能會導致一個或多個機架或整個資料中心的電源中斷。
這些案例可以透過將基礎設施部署到同一校園或都會區中彼此獨立的多個資料中心樓層或位置來緩解。
使用這種方法搭配 AWS Outposts 機架時，需要仔細考慮應用程式如何建構和分佈，以便在多個不同的邏輯 Outpost 上執行，以維持應用程式的可用性。
失敗模式 5： AWS 可用區域或區域
每個 Outpost 錨定到 內的特定可用區域 （AZ） AWS 區域。錨定 AZ 或父區域中的故障可能會導致 Outpost 管理和可變性遺失，並可能會中斷 Outpost 和 區域之間的網路通訊。
與網路故障類似，AZ 或區域故障可能會導致 Outpost 與區域中斷連線。在 Outpost 上執行的執行個體會繼續執行，並可透過 Outpost Local Gateway （LGW） 從內部部署網路存取，如果它們依賴 區域中的服務，則可能會受損或失敗，如前所述。
若要減輕 AWS AZ 和區域故障的影響，您可以將多個 Outpost 分別部署到不同的 AZ 或區域。然後，您可以使用 AWS 許多類似的機制和架構模式，設計工作負載以在分散式多點部署模型中操作，這些機制和架構模式現在用於設計和部署。
