本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Outposts 机架 maintenance
<a name="outpost-maintenance"></a>

这适用于区域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 Support Center](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-compliant 物理安全密钥，从而有效地粉碎硬件上可能残留的所有数据。如此可确保没有数据离开您的站点。如果要更换 Outpost 网络设备，则当设备从站点移走时，其上可能会存在网络配置信息。这些信息可能包括 IP 地址和 ASN，它们用于建立虚拟接口以配置通往本地网络或返回区域的路径。

## 固件更新
<a name="outpost-firmware-updates"></a>

更新 Outpost 固件通常不会影响您的 Outpost 上的实例。在极少数情况下，我们需要重启 Outpost 设备才能安装更新。对于使用该容量运行的任何实例，您将收到相应的实例停用通知。

## 网络设备维护
<a name="outpost-network-equipment-maintenance"></a>

Outpost 网络设备 (OND) 的维护不会影响 Outpost 的常规运营和流量。如果需要维护，则流量将从 OND 转移出去。您可能会注意到 BGP 通告的临时变化（例如 AS-Path 预先发布），以及 Outpost 上行链路上的流量模式也发生了相应的变化。发生 OND 固件更新时，您可能会注意到 BGP 抖动。

我们建议您将客户网络设备配置为在不更改 BGP 属性的情况下接收 Outposts 的 BGP 广告，并启用 multipath/load BGP 平衡以实现最佳的入站流量。 AS-Path prepending 用于本地网关前缀，以便在需要维护时将流量从 OND 转移出去。客户网络应该更喜欢从 Outposts 出发的 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-based 或机架外的负载平衡更改，以受控的方式将您的服务和应用程序从 Outposts 设备上移出。
+ 以有序的增量方式停止容器、实例和数据库，并在恢复服务时使用相反的顺序。
+ 测试受控地移动或停止服务的计划。
+ Back-up 关键数据和配置，并将其存储在 Outposts 之外。
+ 尽可能减少停电时间。
+ 在维护期间，避免重复开关电源（关-开-关-开）。
+ 在维护时段内留出额外时间来处理意外情况。
+ 通过传达比您通常需求更长的维护时段来管理用户和客户的期望。
+ 恢复供电后，在 Cent [AWS Supporter](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 可用性将降低。例如，运行、启动、停止和终止 API 可能不起作用。实例指标和日志将继续在本地缓存长达 7 天，并在连接恢复后推送到该AWS区域。断开连接超过 7 天可能会导致指标和日志丢失。

 有关更多信息，请参阅 [AWS Outposts 机架常见问题](https://aws.amazon.com/outposts/rack/faqs/#Support_.26_maintenance)页面上的以下问题：*当我的设施的网络连接中断时会发生什么？*。

如果由于现场电源问题或网络连接中断而导致服务链路中断，则会向拥有 Outposts 的账户Health Dashboard发送通知。即使预计会出现中断，您也AWS无法抑制服务链路中断的通知。有关更多信息，请参阅 *AWS Health 用户指南*中的[开始使用 Health Dashboard](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 地址。{{region}}替换为父AWS区域的名称。
  + 父区域中具有公共互联网连接的实例和 Outpost 位置上的公有 IP 地址。
+ 如果网络维护由您掌控，请限制服务链路的停机时间。在维护过程中加入一个步骤，以验证网络是否已恢复。
+ 如果网络维护不由您掌控，请监控与通告的维护时段相关的服务链路停机时间。如果在通告的维护时段结束时服务链路还未恢复，请尽早上报给负责计划网络维护的一方。

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

以下是一些与监控相关的资源，可以确保 Outpost 在发生计划内或计划外的电力或网络事件后正常运行：
+ AWS博客[监控最佳实践AWS Outposts涵盖了Out](https://aws.amazon.com/blogs/mt/monitoring-best-practices-for-aws-outposts/) posts特有的可观察性和事件管理最佳实践。
+ [Amazon VPC 网络连接调试工具AWS](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
+ [部署自动化 Amazon CloudWatch 控制面板以供AWS Outposts使用的AWS](https://aws.amazon.com/blogs/compute/deploying-an-automated-amazon-cloudwatch-dashboard-for-aws-outposts-using-aws-cdk/)博客AWS CDK描述了部署自动控制面板所涉及的步骤。
+ 如果您有任何疑问或需要更多信息，请参阅 *AWS 支持用户指南*中的[创建支持案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)。