[解决方案] 为 AWS Direct Connect 维护事件构建弹性，以缓解停机影响

**发布时间:** 2025-12-09 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/building-resiliency-for-aws-direct-connect-maintenance-events-to-mitigate-downtime/ --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 为 AWS Direct Connect 维护事件构建弹性，以缓解停机影响 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该文档详细阐述了如何为 **AWS Direct Connect** 构建高弹性的混合云网络架构，以有效应对 **计划内维护** 和 **突发性维护** 事件，从而最大限度地减少业务停机时间。该方案的核心目标是超越简单的 **冗余**（如主备连接），实现真正的 **弹性**（Resiliency），即具备准备、检测、响应、恢复和优化的完整能力。此方案主要面向对网络延迟和可用性有严苛要求的关键业务场景，例如金融交易平台或大型直播活动，其技术原理基于多层级的冗余设计、优化的BGP路由策略以及快速故障检测机制。 ## 架构实施最佳实践 1. **设计“最高弹性”拓扑 (Maximum Resilience Topology)** - 在至少两个独立的 **Direct Connect 站点** 部署连接，以实现地理位置级别的冗余。 - 在每个站点内，将连接端接到两个不同的物理设备终端上，以防范单点设备故障。 - *技术原理*：这种双层冗余结构（站点间冗余和站内设备冗余）能够抵御从单个端口故障到整个数据中心中断的多种故障场景。 2. **配置连接工作模式** - **主备模式 (Active/Passive)**：流量默认通过主连接，故障时自动切换至备用连接。此模式简单可靠，易于管理。 - **双活模式 (Active/Active)**：流量负载均衡到所有连接，提供更高的总带宽。 - *注意事项*：在双活模式下，必须进行精细的容量规划，确保单条连接的带宽足以承载故障时转移过来的全部流量，否则可能导致网络拥塞和性能下降。建议使用 **Amazon CloudWatch** 监控链路利用率。 3. **实施快速故障检测** - 在Direct Connect的虚拟接口（VIF）上启用 **双向转发检测 (BFD)**。 - *技术原理*：BFD能够将链路故障的检测时间从BGP默认的180秒Hold Time缩短至亚秒级。这对于突发性维护或意外中断至关重要，能极大减少因路由收敛缓慢导致的数据包丢失时间。 4. **主动验证与测试弹性** - 定期使用 **Direct Connect 故障转移测试 (Failover Test)** 功能，在可控的维护窗口内模拟链路中断，验证应用的表现和网络的切换行为。 - 周期性地（例如每季度）手动切换主备链路的角色，以确保备用路径的路由宣告和接收完全正常。 - 可使用 **Amazon CloudWatch Network Synthetic Monitor** 对连接进行主动的、端到端的监控。 ## 方案客户价值 - **保障业务连续性**：通过最高弹性架构，确保在计划内维护或意外故障期间，关键业务应用（如金融交易、实时流媒体）的连接不中断，将业务影响降至最低。 - **提升网络性能与可用性**：多站点、多设备的冗余设计消除了单点故障。当故障发生时，流量优先在同一站点内的备用链路上切换，避免了因跨地域切换而引入的额外网络延迟。 - **降低意外中断的损失**：启用BFD可将故障恢复时间从数分钟缩短至秒级，显著减少数据包丢失，保护TCP会话免受长时间中断的影响，从而快速恢复业务。 - **增强运维控制力与信心**：提供 **BGP Community** 标签等工具，允许客户在维护前主动、平滑地迁移流量。内置的故障转移测试功能让客户能够安全地验证其弹性部署，从而对架构的可靠性建立信心。 ## 涉及的相关产品 - **AWS Direct Connect**：构建私有、专线混合云连接的核心服务。 - **Amazon CloudWatch**：用于监控链路带宽利用率，设置告警，并通过Synthetic Monitor进行主动探测。 - **AWS Health Dashboard**：AWS用于发布和通知客户相关维护计划的官方渠道。 ## 技术评估 - **优势** - **策略完整性**：方案不仅提供了架构设计，还涵盖了流量管理（BGP Community）、快速检测（BFD）和主动验证（Failover Test）等多个层面，形成了一套完整的弹性保障体系。 - **维护过程优雅**：AWS在计划内维护中采用的流量迁移流程（先通过 **AS-Path Prepend** 降低路由优先级，等待60秒后再撤销路由）为客户网络提供了充足的收敛时间，设计非常周到。 - **技术先进性**：强调BFD的使用，解决了传统BGP网络在链路故障时收敛慢的痛点，是业界公认的最佳实践。 - **可验证性**：提供控制台内置的故障转移测试功能，极大地降低了弹性验证的门槛和风险，提升了方案的实用性和可信度。 - **局限与考量** - **成本与复杂性**：实现“最高弹性”架构至少需要4条物理专线和跨越两个站点的网络设备，这会显著增加网络部署的成本和管理复杂性。 - **责任共担模型**：方案的最终效果高度依赖于客户侧（或合作伙伴）对BGP、BFD的正确配置和容量规划。任何一环的配置失误都可能导致弹性失效。 - **容量规划挑战**：在双活模式下，客户必须持续监控流量并预留足够冗余带宽，这对网络团队的容量管理能力提出了更高要求。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 为 AWS Direct Connect 维护事件构建弹性以减少停机时间 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/building-resiliency-for-aws-direct-connect-maintenance-events-to-mitigate-downtime/](https://aws.amazon.com/blogs/networking-and-content-delivery/building-resiliency-for-aws-direct-connect-maintenance-events-to-mitigate-downtime/) **发布时间:** 2025-12-09 **厂商:** AWS **类型:** BLOG --- 对于依赖 [Amazon Web Services (AWS) Direct Connect](https://aws.amazon.com/directconnect/) 进行混合连接的组织而言，构建能够抵御计划内和计划外维护事件的弹性网络架构至关重要。当您的业务依赖于本地环境与 AWS 之间持续、可靠的连接时，了解如何为维护活动进行架构设计就变得至关重要。 这篇 300 级别的文章提供了高级技术深度，并假设您已熟悉 AWS Direct Connect 和 BGP 路由协议的基本概念并具备实践经验。如果您是 Direct Connect 的新手，请从 [Direct Connect 入门指南](https://aws.amazon.com/directconnect/getting-started/) 开始。 本文的主要学习成果包括： - 定义弹性 - 关于如何构建弹性网络以最大限度减少维护事件影响的描述性指导 - 优化当前网络的弹性状况 - Direct Connect 维护活动的类型 - 维护活动期间发生情况的概述 - 维护活动的沟通 - 为维护期间的弹性进行架构设计 - 为维护做准备 - 验证弹性 本博客文章中讨论的关于打造弹性的最佳实践指南，可以帮助您构建 Direct Connect 环境，以在计划内和突发维护活动期间最大限度地减少中断。 # 定义弹性 ## 1) 简介 在考虑弹性时，您必须明白弹性和冗余并不相同。拥有冗余 (redundancy)，例如一条主用和一条备用 Direct Connect 连接，并不一定等同于具备弹性 (resiliency)。尽管冗余 (备份系统) 有助于提升弹性，但弹性的范畴远不止冗余。真正的弹性包括准备和检测故障、在故障发生时有效响应、在故障或维护活动期间恢复并继续运营，以及从这些经验中学习，以确保生产工作负载在整个生命周期内都受到保护。 ## 2) 理解维护可能导致中断的场景 充分的网络弹性规划对于防止代价高昂的停机和业务中断至关重要。为了实施有效的保护措施，首先了解您的特定应用需求和业务要求非常重要。为了说明这一点，我们考虑两个假设的业务场景： - 场景 A：您正在举办一个具有全球影响力的关键直播活动，您组织的角色是为最终用户提供不间断的广播服务，且不产生任何性能问题。对于这种实时内容分发，如果未配置所需的弹性，任何潜在的中断或故障都可能造成重大的业务影响。 - 场景 B：您运营一个金融交易平台，低延迟和最高可用性至关重要。对于此场景，任何故障都必须限制在尽可能短的时间内。 ## 3) 实施最佳实践 您应该对故障和维护活动进行建模，以确定在这些场景下剩余的容量是否能让您安心运营。 例如，在场景 A 中，由于直播活动具有全球可见性，您可能无法容忍哪怕是短暂的中断，任何可能的中断都可能导致负面的客户体验。为确保有足够的弹性，您需要在每个位置考虑额外的连接组，以处理无缝的故障切换 (failover) 操作。同样，在场景 B 中，您需要考虑即使是故障引起的微小延迟增加所带来的影响，因为缺乏弹性可能会严重扰乱您的业务运营。因此，您需要在每个位置设置第二条线路，甚至可能需要第三条，以便在单条连接发生故障时提供运营上的保障，而不会因故障切换到第二个位置而冒着延迟增加的风险。 关键要点是，虽然冗余是弹性的重要组成部分，但具体的弹性要求是由您的应用和业务的独特需求驱动的。仔细分析这些要求对于设计一个适当弹性的架构至关重要。彻底了解您的特定弹性需求，使您能够反向设计出一个能够提供适当冗余和弹性水平的解决方案。这种量身定制的方法，而不是一刀切的解决方案，对于确保架构满足每个应用和业务的独特要求至关重要。 # Direct Connect 维护期间会发生什么？ Direct Connect 维护分为两种类型：计划内维护 (Planned Maintenance) 和紧急维护 (Emergency Maintenance)。要了解有关维护类型的更多信息，请参阅 [Direct Connect 维护文档](https://docs.aws.amazon.com/directconnect/latest/UserGuide/dx-maintenance.html)。 在对 Direct Connect 终端节点 (endpoint) 进行计划内维护期间，AWS 会分两个阶段将流量从受影响的终端节点上转移： 1. AS 路径前置 (AS-Path prepend): AWS 会向 BGP 路径属性中额外添加三个 AS 路径副本，这会使该路由的优先级降低。这样做是为了让您的网络能够对即将到来的路由撤销做出反应。在此阶段，Direct Connect 也会降低从您的本地网络设备接收到的、朝向 AWS 内部网络的路由的优先级。 2. 路由撤销 (Route withdrawal): 等待 60 秒后，AWS 会撤销通告给您本地网络设备的所有路由。这确保您的网络可以在维护活动开始前做出响应。在此阶段，Direct Connect 也会撤销从您的本地网络设备接收到的、朝向 AWS 内部网络的路由。在维护期间，除了设备重启时，您应该预期 BGP 会保持 up 状态。AWS 在维护期间会保持 BGP 对等体建立，但不进行路由交换，以便进行监控。 AWS 通过全面的预检查来捕获设备状态，以便在进行任何更改之前分析设备的状态。这些预检查包括流量检查，以确保在对终端节点实施更改之前，设备没有承载客户流量。 在维护窗口期间，网络终端节点会进行必要的更新，包括配置更改和系统维护，这可能会在系统处理这些更改并完成所需重启时导致暂时的连接中断。如果配置了备用路径，客户的流量将继续在备用路径上传输。当 AWS 将所有更改应用到终端节点后，会执行一系列后检查，并与预检查进行比较，以确保更改没有产生任何不希望的影响，并且设备已准备好恢复服务。 AWS 会以与之前描述的流量转移相反的顺序启动恢复操作，即我们首先通告一个优先级较低的路由，等待 60 秒后再通告首选路由。同样，此过程既适用于通告给您本地网络的路由，也适用于通告给 AWS 内部网络的路由。 AWS 会执行更多的后检查，以确保终端节点正在处理流量并且其运行符合预期。在维护窗口期间，流量会返回到该终端节点，在 AWS 发出完成通知之前，您会看到流量恢复。 当所有步骤完成后，AWS 会将更改标记为已完成，系统会通过 [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) 发出完成通知，告知您维护活动已结束。要了解维护通知的时间表，请访问 [AWS Direct Connect 维护](https://docs.aws.amazon.com/directconnect/latest/UserGuide/dx-maintenance.html#operations-maintenance-planned)。 对于仅影响终端节点某个组件的紧急维护，流量转移是不可行的。在这种情况下，您可以预期在维护事件期间连接会更突然地中断。 # 客户应如何为维护进行架构设计 为确保生产工作负载在计划内维护和计划外故障期间都能继续运行，Direct Connect 建议您根据最高弹性拓扑 (Maximum Resilience topology) 来配置连接。在这种方法中，您将连接分布在至少两个 Direct Connect 位置，并在每个 Direct Connect 位置内连接到两个独特的物理终端节点。 最高弹性拓扑的目标是为您的连接提供冗余和高可用性 (HA)。多样化的物理 Direct Connect 位置和终端节点意味着该架构降低了单点故障影响连接的风险。这有助于在计划内维护或计划外事件发生时维持业务连续性。 Direct Connect 的最高弹性拓扑提供了多层冗余，以在计划内维护和计划外故障期间保持连接。在每个 Direct Connect 位置内将双连接终止在不同的终端节点上，使得该架构能够确保单个终端节点的故障能将流量保持在本地的 Direct Connect 位置。这避免了因流量必须故障切换到第二个 Direct Connect 位置而可能产生的额外延迟。 在更严重的情况下，如果整个 Direct Connect 位置受到影响或损坏 (如图 1 所示)，您的工作负载可以无缝地切换到第二个 Direct Connect 位置。这为您提供了超越单个 Direct Connect 位置的弹性，提供了另一层冗余以防范大范围的故障。 最高弹性方法的关键好处是，它使您能够通过避免服务中断来维持业务连续性，即使面对终端节点故障或整个 Direct Connect 位置的故障。这种稳健的连接设计是推荐的最佳实践，以确保生产工作负载能够抵御各种潜在的故障场景。 **图 1** : Direct Connect 位置故障场景。此图显示了流量如何从一个发生故障的托管机房 (colocation) 自动故障切换到第二个 Direct Connect 位置，通过地理上多样化的路径保持连接。该架构展示了跨越两个位置的冗余连接，每个位置都有双终端节点以实现最高弹性。  *图 1: 托管机房 1 因意外问题发生故障* 您可以在两个托管机房中将您的 Direct Connect 连接配置为主/备 (active/passive) 或双活 (active/active) 模式。但是，在使用双活设置时必须特别小心，以避免在故障事件期间出现潜在的拥塞 (congestion) 问题。 在双活配置中 (如图 2 所示)，两个连接都在主动承载流量。虽然这提供了更多的总带宽容量，但这也意味着如果一个连接发生故障，剩余的连接必须能够处理全部流量负载而不会变得拥塞。为防止这种情况，您必须确保在故障场景下，双活链路上的使用率不超过剩余容量的可用带宽。超过幸存连接的带宽可能导致性能下降或服务中断。 成功配置双活连接需要仔细的监控和容量规划。您需要确保预置了足够带宽的连接，并持续评估使用情况，以避免在其中一条链路发生故障时出现拥塞。您可以配置 [Amazon CloudWatch alarms](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-cloudwatch.html) 来跟踪使用情况，并在使用率超过设定的阈值时获得实时通知。 **图 2** : 故障场景下的连接过载。此图显示了在双活配置中，容量规划不足如何在一条链路发生故障时导致拥塞。剩余的连接必须处理全部流量负载，如果容量规划不当，可能会导致性能下降。该图展示了故障切换到冗余站点的能力，以解决主连接组的拥塞问题。  *图 2: 故障切换到备用链路时发生链路过载* 当 AWS 网络中的故障或维护事件与您的网络或合作伙伴网络中的故障或维护事件同时发生时，您将从最高弹性设计中受益。这种架构使流量能够无缝地故障切换到第二个 Direct Connect 位置，如图 3 所示。 **图 3** : 并发维护场景处理。此架构图显示了当 AWS 和用户/合作伙伴的维护活动同时发生时，最高弹性拓扑如何保持连接。这显示了地理和终端节点多样性的重要性。  *图 3: AWS 路由器与合作伙伴或客户路由器上的并发维护* # 客户如何为维护做准备 如果您拥有一个架构良好、富有弹性的网络设计，那么在计划内的 Direct Connect 维护活动期间，您通常不需要采取任何预防性措施。在维护期间，AWS 不会从正在进行工作的终端节点承载客户流量，这会强制流量通过您剩余的连接传输。 在流量转移的第一阶段，您的终端节点仍然有一条有效路由以允许流量转发。这为您的网络提供了 60 秒的收敛时间，然后 AWS 才会最终从 Direct Connect 终端节点撤销路由。 一个弹性的网络设计可以帮助您避免在计划内维护期间发生中断。您可以避免计划内维护期间的中断。架构中内置的冗余连接和自动故障切换功能使得流量可以重新路由，而无需手动干预。这表明了从一开始就融入高可用性设计实践的好处。如果您投资了一个稳健、弹性的网络拓扑，那么您就可以在计划内维护事件中以最小甚至无影响的方式度过。 您可能希望在计划内维护之前控制流量在冗余 Direct Connect 连接之间的切换时间。为此，您可以使用本地优先级 BGP community (Local Preference BGP communities) 向 Direct Connect 终端节点发出信号，以更改应用于从您的终端节点学习到的路由的本地偏好值。这控制了 Direct Connect 如何将流量路由回您的本地网络。 例如，您可以在您选择的维护窗口期间，在计划的 Direct Connect 维护之前进行配置更改。这可能包括翻转您的主/备连接的优先级，或从双活设置过渡到主/备设置。这确保了计划进行维护的链路在预定工作开始前不承载流量。 采取这些步骤可以让您更好地控制流量，并避免在计划的 Direct Connect 维护活动期间发生中断。 对于无法进行流量转移且无法提前通知的计划外紧急维护，您可能会经历几分钟的数据包丢失。这种长时间的丢失可能是由于 Direct Connect 连接交付到您设备的方式所致，即在您的终端节点和 Direct Connect 终端节点之间放置了一个第 2 层设备，如交换机。 在这种情况下，到 Direct Connect 终端节点的链路故障不会在您的终端节点上复制。因此，您的 BGP 会话会一直保持 up 状态，直到 hold timer 超时，从而延迟了路由的检测和撤销。网络路径中这种延迟的收敛可能会延长服务中断时间。 为了在计划外紧急维护事件期间最大限度地减少数据包丢失，AWS 建议您为您的虚拟接口 (Virtual Interfaces) 配置双向转发检测 (BFD) (Bidirectional Forwarding Detection (BFD))，如 [Direct Connect 双向转发检测文档](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 中所述。 启用 BFD 可以提高您的终端节点和 Direct Connect 终端节点之间 BGP 会话的响应能力。与默认的 180 秒 BGP 会话超时相比，BFD 可以将故障检测时间缩短到亚毫秒级。这种快速的故障检测使 BGP 能够迅速拆除会话并撤销路由，从而实现更快的网络收敛。 如果没有 BFD，延迟的 BGP 会话拆除可能导致链路故障时几分钟的数据包丢失。通过将检测时间从分钟缩短到秒，BFD 可以帮助您的工作负载在计划外故障或紧急维护期间更快地从失败的 TCP 会话中恢复。 实施此 BFD 配置是推荐的最佳实践，以减轻延迟收敛的影响，并在计划外的 Direct Connect 事件期间最大限度地减少服务中断。 # 用户如何建立对其弹性状况的信心？ Direct Connect 连接的共享性质凸显了验证您的弹性状况的重要性。 链路的一端由 AWS 拥有，另一端由您 (或通过 Direct Connect 合作伙伴) 拥有，因此对端到端连接的完整配置和行为的可见性天生就较少。这种缺乏完全透明度的情况可能会对网络在故障或维护事件期间的反应产生一些不确定性。 为了解决这个问题，最佳实践是您定期在批准的维护窗口期间通过切换流量来测试您的冗余连接。这使得应用所有者能够验证功能和性能，确保即使在使用备用链路时，一切也能按预期继续工作。 您可以使用 AWS community 的本地优先级来控制流量如何路由回您。一个推荐的方法是在计划内维护期间，每季度翻转一次冗余连接的主/备状态。这可以充分检验备用链路，并验证 AWS 和您双方的路由交换和接受是否正确。或者，您可以使用 AWS 控制台中的 [Direct Connect 故障切换测试](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilience_failover.html) 对您的连接进行定期的故障切换测试。 您还可以使用 [Amazon CloudWatch Network Synthetic Monitor](https://aws.amazon.com/cloudwatch/) 为您的 Direct Connect 连接提供主动监控。 主动验证您的弹性，可以让您对 Direct Connect 设置的可靠性更有信心，尽管连接具有共享性质。定期测试有助于在真正的故障或维护场景影响生产工作负载之前，识别并解决任何潜在问题。 共享所有权模型表明，您需要积极主动地确保您的 Direct Connect 架构的弹性。定期验证是减轻这种共享连接模型固有风险的关键一步。 # 结论 在本文中，我们演示了 AWS Direct Connect 维护的工作原理，以及如何在计划内和紧急维护活动期间为您的网络构建弹性。实施最高弹性拓扑，跨多个 Direct Connect 位置建立连接，配置 BFD 以实现更快的故障检测，并定期测试您的故障切换能力，这些都有助于确保您的关键工作负载在计划内维护窗口和意外事件期间保持连接。这反过来又支持了您的业务连续性要求。 请记住以下关键要点： - 采用最高弹性架构，每个位置至少有两个 Direct Connect 连接 - 启用 BFD 将故障检测时间从分钟级缩短到秒级 - 定期测试您的冗余连接以验证您的弹性状况 - 在设计适当的弹性时，考虑您的具体业务需求 要了解有关 Direct Connect 最佳实践的更多信息，请访问 [Direct Connect 文档](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 或浏览我们的 [网络与内容分发频道](https://aws.amazon.com/blogs/networking-and-content-delivery/) 获取更多资源。 ## 关于作者  Harold Lotz 是 AWS 的一名高级网络开发工程师。他拥有超过二十年的网络经验，支持全球所有 AWS Direct Connect 基础设施的运营和设计，帮助我们为客户提供最高的安全和安保标准。  Mandar Sawant 是一名高级解决方案架构师，在 AWS 核心网络服务方面拥有丰富的经验，帮助客户设计符合良好架构 (Well-Architected) 的解决方案。他对网络技术充满热情，热爱创新并帮助解决复杂的客户问题。Mandar 拥有密苏里大学堪萨斯城分校的计算机网络硕士学位。Mandar 常驻西雅图，喜欢户外摄影。 <!-- AI_TASK_END: AI全文翻译 -->