

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

# Outposts 機架維護
<a name="outpost-maintenance"></a>

在[共同的責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)下， AWS負責執行 AWS服務的硬體和軟體。這適用於 AWS Outposts，就像對 AWS區域一樣。例如， AWS會管理安全修補程式、更新韌體和維護 Outpost 設備。 AWS也會監控 Outposts 機架的效能、運作狀態和指標，並判斷是否需要任何維護。

**警告**  
如果底層的磁碟機故障，或者如果執行個體停止、休眠或終止，執行個體儲存體磁碟區上的資料就會遺失。為了防止資料遺失，建議您將執行個體儲存體磁碟區上的長期資料備份到持久性儲存，例如 Amazon S3 儲存貯體、Amazon EBS 磁碟區或內部部署網路中的網路儲存裝置。

**Topics**
+ [更新聯絡詳細資訊](#outpost-owner-update)
+ [硬體維護](#outpost-hardware-maintenance-events)
+ [韌體更新](#outpost-firmware-updates)
+ [網路設備維護](#outpost-network-equipment-maintenance)
+ [電源和網路事件的最佳實務](#outpost-power-network-events)

## 更新聯絡詳細資訊
<a name="outpost-owner-update"></a>

如果 Outpost 擁有者變更，請聯絡具有新擁有者名稱和聯絡資訊的 [AWS 支援中心](https://console.aws.amazon.com/support/home#/)。

## 硬體維護
<a name="outpost-hardware-maintenance-events"></a>

如果 在伺服器佈建程序期間或在 Outposts 機架託管執行的 Amazon EC2 執行個體時AWS偵測到硬體發生無法修復的問題，我們會通知執行個體擁有者受影響的執行個體已排定淘汰。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的《[執行個體淘汰](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html)》。

Outpost 擁有者和執行個體擁有者可以共同解決問題。執行個體擁有者可以停止並啟動受影響的執行個體，將其移轉至可用的容量。執行個體擁有者可以在方便時停止並啟動受影響的執行個體。否則， 會在執行個體淘汰日期AWS停止和啟動受影響的執行個體。如果 Outpost 上沒有額外的容量，執行個體會繼續處於已停止狀態。Outpost 擁有者可以嘗試釋放已使用的容量或要求 Outpost 的額外容量，以便完成移轉。

如果需要硬體維護， AWS將聯絡 Outpost 擁有者，確認AWS安裝團隊造訪的日期和時間。Outpost 擁有者與AWS團隊交談後，只要兩個工作天就可以排定造訪。

當AWS安裝團隊抵達現場時，他們會取代運作狀態不佳的主機、交換器或機架元素，並將新的容量上線。他們不會在現場執行任何硬體診斷或維修。如果他們更換了主機，就會移除並銷毀 NIST 相容的實體安全金鑰，進而有效地銷毀任何可能保留在硬體上的資料。如此即可確保不會有任何資料離開您的站點。如果他們更換了 Outpost 網路裝置，當該裝置從站點移除時，網路組態資訊可能會出現在裝置上。此資訊可能包括 IP 地址和 ASN，這些項目是用來建立虛擬介面，以設定本機網路徑或返回區域的路徑。

## 韌體更新
<a name="outpost-firmware-updates"></a>

更新 Outpost 韌體通常不會影響 Outpost 上的執行個體。在極少數情況下，我們需要重新啟動 Outpost 設備才能安裝更新，您會收到在該容量上執行之任何執行個體的執行個體淘汰通知。

## 網路設備維護
<a name="outpost-network-equipment-maintenance"></a>

在不影響正常 Outpost 操作和流量的情況下，執行 Outpost 網路裝置 (OND) 的維護。如果需要進行維護，則會從 OND 轉移流量。您可能會注意到 BGP 公告中的暫時變更 (例如在前面加上 AS-Path)，以及 Outpost 上行鏈路之流量模式中的相應變更。在 OND 韌體更新時，您可能會注意到 BGP 震盪。

建議您將客戶網路設備設定為接收來自 Outpost 的 BGP 公告，而不變更 BGP 屬性，並啟用 BGP 多路徑/負載平衡以獲得最佳傳入流量。在本機閘道字首前面加上 AS-Path，以在需要維護時從 OND 轉移流量。客戶網路應優先使用 Outpost 中 AS-Path 長度為 1 的路由，而不是 AS-Path 長度為 4 的路由。

客戶網路應向所有 OND 公告具有相同屬性的等量 BGP 字首。Outpost 網路負載預設會平衡所有上行鏈路之間的傳出流量。Outpost 端使用了路由政策，可在需要維護時從 OND 轉移流量。此流量轉移需要所有 OND 上的客戶端都有等量 BGP 字首。如果客戶網路需要維護，建議您在前面加上 AS-Path 以暫時從特定上行鏈路轉移流量。

## 電源和網路事件的最佳實務
<a name="outpost-power-network-events"></a>

如AWS Outposts客戶[AWS服務條款](https://aws.amazon.com/service-terms/)中所述，Outposts 設備所在的設施必須符合最低[電力](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-requirements.html#facility-power)和[網路](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-requirements.html#facility-networking)需求，以支援 Outposts 設備的安裝、維護和使用。只有在電源和網路連線不中斷時，Outposts 機架才能正確運作。

### 電源事件
<a name="outpost-power-events"></a>

完全停電時，AWS Outposts存在資源可能無法自動恢復服務的固有風險。除了部署備援電源和備用電源解決方案之外，建議您事先執行下列動作，以減輕某些最壞情況的影響：
+ 使用 DNS 架構或機架外負載平衡變更，以受控方式將您的服務和應用程式從 Outpost 設備移出。
+ 以循序增量方式停止容器、執行個體和資料庫，並在還原時使用相反的順序。
+ 測試服務的受控移動或停止計畫。
+ 備份關鍵資料和組態，並將其儲存在 Outpost 之外。
+ 將停電的停機時間降至最低。
+ 避免在維護期間重複切換電源供應 (關開關開)。
+ 在維護時段內允許額外的時間來處理意外情況。
+ 透過傳達比一般所需更寬的維護時段時間範圍來管理使用者和客戶的期望。
+ 電源還原後，在 [AWS 支援Center](https://console.aws.amazon.com/support/home#/) 建立案例，請求驗證 AWS Outposts和相關服務正在執行。

### 網路連線事件
<a name="outpost-network-events"></a>

您的 Outpost 與AWS區域或 Outposts 主區域之間的服務連結連線，通常會在網路維護完成後，自動從上游企業網路裝置或任何第三方連線提供者網路中可能發生的網路中斷或問題中復原。在服務連結連線中斷期間，您的 Outpost 操作僅限於本機網路活動。

Outposts 上的 Amazon EC2 執行個體、本機閘道和 Amazon EBS 磁碟區將繼續正常運作，並且可以透過本機網路在本機存取。同樣地，Amazon ECS 工作者節點等AWS服務資源會繼續在本機執行。不過，API 可用性將會降低。例如，執行、啟動、停止和終止 APIs可能無法運作。執行個體指標和日誌將在本機繼續快取長達 7 天，並在連線傳回時推送至 AWS區域。超過 7 天的中斷連線可能會導致指標和日誌遺失。

 如需詳細資訊，請參閱《[AWS Outposts 機架常見問答集](https://aws.amazon.com/outposts/rack/faqs/#Support_.26_maintenance)》頁面上的《*當我的設施網路連線中斷，會發生什麼情況*》問題。

如果服務連結因為現場電源問題或網路連線中斷而關閉， Health 儀板表會傳送通知給擁有 Outpost 的帳戶。您和 都AWS無法隱藏服務連結中斷的通知，即使預期會中斷。如需詳細資訊，請參閱《 指南》中的《AWS Health**[Health 儀板表 入門](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)》。

如果計畫的服務維護會影響網路連線，請採取下列主動步驟來限制潛在問題情況的影響：
+ 如果您的 Outposts 機架透過網際網路或公有 Direct Connect 連線至父AWS區域，則在計劃維護之前擷取追蹤路由。具備有效 (網路維護前) 的網路徑和有問題 (網路維護後) 的網路徑來識別差異將有助於進行疑難排解。如果您將維護後問題呈報至 AWS或 ISP，您可以包含此資訊。

  擷取下列項目之間的 trace-route：
  + 位於 Outpost 位置的公有 IP 地址，以及 `outposts.{{region}}.amazonaws.com` 傳回的 IP 地址。以父{{區域}}的名稱取代AWS區域。
  + 父區域中任何具有公有網際網路連線的執行個體，以及位於 Outpost 位置的公有 IP 地址。
+ 如果網路維護在您的控制下，請限制服務連結的停機時間。在維護程序中加入驗證網路是否已復原的步驟。
+ 如果網路維護不在您的控制下，請監控與宣布維護時段相關的服務連結停機時間，如果服務連結未在宣布的維護時段結束時恢復上線，請及早向負責計畫網路維護的一方呈報。

### Resources
<a name="outpost-power-network-resources"></a>

以下是一些監控相關資源，這些資源可確保 Outpost 在計畫或意外的電源或網路事件發生之後正常運作：
+ AWS部落格[監控 的最佳實務AWS Outposts](https://aws.amazon.com/blogs/mt/monitoring-best-practices-for-aws-outposts/)涵蓋 Outposts 特有的可觀測性和事件管理最佳實務。
+ AWS適用於 [Amazon VPC 網路連線的部落格偵錯工具](https://aws.amazon.com/blogs/networking-and-content-delivery/debugging-tool-for-network-connectivity-from-amazon-vpc/)說明 *AWSSupport-SetupIPMonitoringFromVPC* 工具。此工具是一份 AWS Systems Manager 文件 (SSM 文件)，可在您指定的子網路中建立 Amazon EC2 監視器執行個體並監控目標 IP 地址。該文件會執行 Ping、MTR、TCP 路由追蹤和路徑追蹤診斷測試，並將結果儲存在 Amazon CloudWatch Logs 中，以便在 CloudWatch 儀表板中視覺化 (例如延遲、封包遺失)。對於 Outposts 監控，監控執行個體應位於父AWS區域的一個子網路中，並設定為使用其私有 IP 監控一或多個 Outpost 執行個體 （這將提供封包遺失圖表和AWS Outposts父AWS區域之間的延遲。
+ AWS部落格[部署 AWS Outposts的自動化 Amazon CloudWatch 儀表板AWS CDK](https://aws.amazon.com/blogs/compute/deploying-an-automated-amazon-cloudwatch-dashboard-for-aws-outposts-using-aws-cdk/)，說明部署自動化儀表板所涉及的步驟。
+ 如果您有疑問或需要更多資訊，請參閱《AWS Support 使用者指南》**中的《[建立支援案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)》。