迁移低于 1 Gbps 的托管连接以使用 亚马逊云科技 Transit Gateway — 第 1 部分

作者: Mahesh Beri | 202 3 年

简介

这篇博客将介绍将 亚马逊云科技 Di rect Connect 托管连接低于 1 Gbps 的现有混合连接架构迁移到 亚马逊云科技 T ransit Gateway 的推荐迁移方法。 它将为您提供目标架构以及有关如何从现有状态迁移的分步规范性指导。

您可以从迁移中获得的主要好处是:

  • 规模 — 如果您今天没有使用Transit Gateway,它将允许您使用Transit Gateway将混合连接无缝扩展到大量 VPC。
  • 简化的混合连接 -无需使用自定义网络结构,例如传输 VPC,这些结构通常用于速度低于 1 Gbps 的传输网关连接。

客户一直要求在低于 1 Gbps 的托管连接上使用传输虚拟接口(传输 VIF)。该解决方案允许将这些连接与 Transit Gateway 进行本地集成。

自 2022 年 8 月推出 扩展连接速度支持 以来 ,您现在可以以低于 1 Gbps 的速度连接到公交网关。在此次发布之前,您必须至少有 1 Gbps 的直接连接才能本地连接到 Transit Gateway。现在,当您使用Transit Gateway和Direct Connect时,您可以实现无缝连接,并且在不需要更高速度的连接时,这是一个经济实惠的选择。

迁移场景

在两种常见的迁移场景中,客户可以从使用直接连接和传输网关中受益:

  1. 使用低于 1 Gbps 的 Direct Connect 托管连接但不使用传输网关的现有架构
  2. 使用直接连接、传输网关和传 输 VPC 进行混合连接的现有架构

这篇文章(第 1 部分)描述了场景 1 的迁移方法。在随后的文章( 第 2 部分 )中,我们将介绍迁移场景 2。

高级方法

这种迁移方法包括删除现有的私有 VIF(私有虚拟接口),并在现有的 Direct Connect 连接上创建新的传输 VIF(传输虚拟接口)。

如果您想最大限度地减少迁移期间的混合连接停机时间,请在现有设置中配置冗余的 Direct Connect 连接。然后,分阶段进行迁移。首先,删除私有 VIF 并在被动连接上创建新的传输 VIF,接下来对主动连接重复此过程。在可能的情况下,将新的公交 VIF 配置与旧的私有 VIF 配置相同。

这篇文章假设你使用弹性 Direct Connect 连接构建了架构,其中一个 Direct Connect 连接是主动的(或主连接),另一个是被动的(或辅助的)。我们假设主直接连接和辅助直接连接的容量相同。例如,两者都是 500 Mbps 的托管连接。

迁移到公交网关

下图显示了场景 1 的示例连接架构,该客户使用低于 1 Gbps 的 Direct Connect 托管连接而不是使用 Transit Gateway。它显示了两个托管的 Direct Connect 连接、私有 VIF、BGP 对等详细信息以及本地和 亚马逊云科技 之间的路由传播。

Diagram showing the existing connectivity using two hosted Direct Connect connections active-passive

图 1 使用两个托管的 Direct Connect 连接的现有连接(主动/被动)

迁移分为三个阶段。

第 1 阶段:建立直接连接-在辅助直接连接上为测试 VPC 提供连接

下图显示了现有网络部署的高级示意图。接下来的下图显示了中间阶段 1,使用第二个 Direct Connect 连接和测试 VPC 的新传输网关建立了连接。

Figure showing the Initial State of Hosted Direct Connect Connections with Direct Connect Gateway

图 2 初始状态:使用直接连接网关的托管直接连接连接(主动-被动)

中间阶段提供了一种机制,用于在将生产 VPC 迁移到新架构之前,通过测试 VPC 验证新架构使用传输网关的情况。

Figure showing the Intermediate Stage 1 of Hosted Direct Connect Connections (active-active) with Test VPC using Transit Gateway

图 3 中间阶段 1:使用传输网关与测试 VPC 的托管直接连接连接(主动-主动)

迁移步骤:

  • 步骤 1: 创建新的传输网关。此处使用的 ASN 应与本地和 Direct Connect Gateway 中使用的 ASN 不同。
  • 步骤 2: 创建新的直接连接网关(在图中显示为直接连接网关 2)。使用与现有直接连接网关 1 相同的 ASN。
  • 步骤 3: 复制私有虚拟接口 2 的配置。你可以使用 desc ribe-virtual-inter faces CLI 命令来执行此操作。要捕获的关键信息如下。您可以在步骤 5) 中重复使用此方法来减少路由器配置的更改。
    1. VLAN
    2. 客户 ASN
    3. 客户对等 IP
    4. 亚马逊云科技 对等 IP
    5. BGP
    6. 身份验证密钥
  • 步骤 4: 删除私有虚拟接口 2(在直接连接连接 2 上)。
  • 步骤 5: 创建新的传输虚拟接口,选择 Direct Connect 连接 2 并指定步骤 3 中收集的确切配置参数)。如果一切设置正确,则传输虚拟接口将显示状态为可用,BGP 状态显示为已启动。这将是无缝的,无需更改本地路由器配置。但是,如果您更改了任何虚拟接口配置,则可以随时从传输 VIF 控制台页面下载新的路由器配置,并相应地更改路由器配置。例如,如果您在配置传输 VIF 时为直接连接网关 2 使用不同的 ASN、不同的 VLAN、不同的 亚马逊云科技/客户对等 IP 或不同的 BGP 身份验证密钥,请重新配置路由器。
  • 步骤 6: 将专线网关 2 与传输网关连接。
  • 步骤 7:在允许的前缀中 指定要从本地访问的测试 VPC CIDR。
  • 步骤 8: 验证与 Direct Connect 附件关联的 Transit Gateway 路由表是否包含本地路由。例如,上述本地 CIDR 192.168.0.0/24 填充在传输网关路由表中。验证本地路由器是否正在收到来自直接连接连接 2 的测试 VPC CIDR 10.2.0.0/24 的路由通告。这确认了传输网关和本地路由器之间存在 IP 可访问性。
  • 步骤 9: 取消测试 VPC 与专线网关 1 的关联。请注意,这会从测试 VPC 中删除本地连接。
  • 步骤 10: 将传输网关连接到测试 VPC。验证与 Transit Gateway 中的测试 VPC 关联的关联路由表是否包含来自本地网络的路由。检查来自测试 VPC 的路由是否在与直接连接连接关联的路由表中。
  • 步骤 11: 修改测试 VPC 路由表并添加路由,以便通过 Transit Gateway 向本地网络发送流量。将 192.168.0.0/24 添加到目的地为传输网关的 VPC 路由表中。这将恢复从测试 VPC 到本地的连接,现在使用传输网关和直接连接。

由于测试 VPC 只能通过直接连接连接 2 进行访问,因此直接连接连接 2 成为流量进出测试 VPC 的主动路径。请注意,在迁移的中间阶段,主直接连接连接没有备用的 Direct Connect 连接。

下图显示了详细的中间状态 1 架构,其中包含更新的虚拟接口配置、BGP 对等详细信息以及本地和 亚马逊云科技 上更新的路由。

Figure showing the Intermediate stage 1 of Hosted Direct Connect Connections (active-active) with Test VPC using Transit Gateway

图 4 中间阶段 1:使用传输网关与测试 VPC 的托管直接连接连接(主动-主动)

第 2 阶段:构建传输网关/直接连接-为生产 VPC 提供连接

此阶段将涉及对生产 VPC 进行一些相同的 Direct Connect 连接更改。

Figure showing the Intermediate Stage 2 of Hosted Direct Connect connections with Test VPC and Production VPC both using Transit Gateway.

图 5 中间阶段 2:使用传输网关与测试 VPC 和生产 VPC 的托管直接连接连接。

迁移步骤:

  • 在专线网关关联的允许前缀中指定生产 VPC CIDR。
  • 对每个生产 VPC 重复步骤 9-11。

与本地的生产 VPC 连接现在将使用传输网关和直接连接连接。

在此期间,生产 VPC 只能通过 Direct Connect 连接 2 进行访问。这使其对来自生产 VPC 的流量处于活动状态。在此中间阶段,没有待机的 Direct Connect 连接。

第 3 阶段:使用 Transit Gateway 迁移到主动/被动连接

在第三阶段,也是最后阶段,我们重新建立主要的直接连接连接,将其连接到 Transit Gateway,并让所有 VPC 将其用作主要的 Direct Connect 连接,将第二个直接连接恢复为被动角色。

Figure showing the Final State of Hosted Direct Connect Connections with Transit Gateway and Direct Connect Gateway

图 6 最终状态:与传输网关和直接连接网关的托管直接连接连接

在 Direct Connect 连接 1(主连接)上重复第 1 阶段的步骤 3)至 5)。两个 Transit VIF 均处于活动状态后,将使用本地路由器上的原始 BGP 首选项。对于所有进出本地的流量,直接连接连接 1 变为活动状态,直接连接连接 2 变为被动状态。最后,验证客户网关上是否从主动和被动 Direct Connect 连接正确接收了所有 VPC CIDR 范围。

下图显示了包含更新的虚拟接口配置、BGP 对等详细信息以及本地和 亚马逊云科技 中更新的路由的最终架构。

Figure showing the Final State of Hosted Direct Connect connections (active-passive) with all VPC using Transit Gateway

图 7 最终状态:使用传输网关与所有 VPC 的托管直接连接连接(主动-被动)

结论

在这篇文章中,我们研究了一种迁移模式,该模式将Direct Connect以下 1 Gbps 的托管连接与传输网关集成在一起。这将允许您使用 Transit Gateway 将混合连接从本地扩展到大量 VPC。

我们从私有 VIF、Direct Connect Gateway、虚拟网关架构迁移到使用 Transit VIF、Direct Connect Gateway 和公交网关的架构,同时最大限度

下一篇文章 (本 系列的第 2 部分)中,我们将介绍如何迁移使用 Transit VPC 的现有环境。

作者简介

Sameer Kumar Headshot1.jpg

Mahesh Beri

Mahesh Beri 是亚马逊网络服务的首席解决方案架构师。他与印度的大型企业金融服务客户合作,帮助他们加快云采用之旅。