导读

虽然大多数VMware工作负载可以轻松迁移到云端，但由于应用程序相互依赖、数据驻留要求或时间限制等原因，一些工作负载需要保留在本地。参加本次会议，了解亚马逊云科技混合和边缘服务（如Amazon Outposts和Amazon Local Zones）如何让您能够就地迁移并按照自己的节奏实现现代化。深入探讨使用Outposts的各种迁移路径，以及可用于简化和加速向云端过渡的迁移工具和计划。

演讲精华

以下是小编为您整理的本次演讲的精华。

亚马逊云科技 re:Invent 2024会议由亚马逊云科技混合计算解决方案产品管理负责人Thwiker先生主持开幕。他深入探讨了促使客户考虑将工作负载从VMware迁移到亚马逊云科技的驱动因素。一个重要因素是VMware最近被Broadcom收购，导致许可证成本大幅上涨，迫使客户重新评估现有的VMware部署。此外，客户还希望减轻在传统平台上运行工作负载的风险，并整合组织内不同的系统。

此外，Thwiker先生强调了可持续发展的日益重要性，客户旨在通过过渡到高效的基于云的基础架构来减少碳足迹。并购活动也发挥了作用，因为亚马逊云科技为整合此类企业行为导致的不同系统提供了无缝解决方案。从技术角度来看，客户寻求加强安全态势、提高可扩展性和可靠性，并最终摆脱管理基础设施和数据中心的负担。

正如Thwiker先生所强调的，迁移到亚马逊云科技的真正价值主张是提供弹性和恢复能力，而无需客户直接管理底层基础设施。亚马逊云科技旨在解放客户免于基础设施管理的复杂性，使他们能够更高效地为最终用户交付应用程序和价值。

在考虑从VMware迁移到亚马逊云科技时，Thwiker先生概述了两条主要途径。第一条涉及过渡到云区域，提供了几种选择。客户可以利用提升和转移迁移，这是将VMware工作负载直接移动到Amazon Elastic Compute Cloud (EC2)实例的成熟做法。或者，他们可以将工作负载重新部署到容器化环境或托管数据库。对于那些寻求更全面转型的客户，可以选择使用现代云原生技术(如无服务器计算)重新构建应用程序。此外，VMware Cloud on 亚马逊云科技为需要更多时间评估长期战略的客户提供了临时解决方案。

第二条途径面向具有特定需求的客户，例如需要极低延迟、高性能或严格数据主权的工作负载。在这种情况下，Amazon Outposts提供了在客户本地数据中心内扩展亚马逊云科技云的解决方案。Outposts将亚马逊云科技基础设施和服务直接引入客户场所，使他们能够利用云的优势，同时在现场保留工作负载。

对于时间有限的客户，例如即将到期的VMware许可证续期，Thwiker先生建议采用提升和转移方法，先迁移工作负载，然后优化或现代化。这个过程包括进行评估以快速发现现有工作负载、在亚马逊云科技内建立登陆区域，并执行提升和转移迁移。一旦进入亚马逊云科技，客户就可以根据业务策略优化工作负载。Thwiker先生举例说明了成功执行大规模迁移的客户，如Mead在六周内重新托管了3，300台服务器，而3M则在24个月内迁移了2，200个应用程序。

或者，对于寻求全面迁移策略与长期目标保持一致的客户，Thwiker先生概述了完整的迁移方法。该方法首先进行评估，以确立迁移的业务案例和总体拥有成本(TCO)。随后，动员阶段涉及创建登陆区域、制定详细计划并提升客户IT人员的技能。迁移本身利用亚马逊云科技工具和服务，如果需要，还可以在过渡期间对应用程序进行现代化。虽然这种方法需要更多时间，但它通过与客户的战略目标保持一致，为长期带来价值。

在讨论Outposts解决方案时，Thwiker先生解释说，它将亚马逊云科技基础设施和服务作为托管服务引入客户的数据中心。Outposts提供三种形式:常规42U机架、2U服务器和1U服务器，全部与亚马逊云科技区域基础设施配置相同。客户可以选择直接将应用程序重新托管到Outposts上，重新部署到容器化环境(如EKS(Elastic Kubernetes Service)或ECS(Elastic Container Service))，或利用托管数据库(如Amazon Relational Database Service (RDS))。这种方法允许客户将工作负载迁移到Outposts，同时考虑他们的长期计划，为评估应用程序的理想最终状态提供了时间。

Thwiker先生还讨论了亚马逊云科技优化和许可证评估(OLA)服务，该服务对客户环境进行全面评估，提供许可证和基础设施优化建议，并就迁移过程中处理工作负载许可证提供指导。

接下来，亚马逊云科技的主要解决方案架构师、边缘计算专家Brian Daugerty上台讨论了用于VMware迁移的各种工具和服务。他着重介绍了三大主要产品:亚马逊云科技 Elastic Disaster Recovery Service (DRS)、Amazon Application Migration Service (MGN)和第三方迁移工具。

正如Brian Daugerty所解释的，DRS旨在创建试点灾难恢复解决方案。它使客户能够暂存工作负载、持续更新它们，并在主数据中心发生故障时快速故障转移到备份环境。DRS提供了灵活性，支持从本地服务器(虚拟或裸机)迁移到亚马逊云科技区域或Outposts，以及在Outposts、区域和其他云提供商之间进行迁移。

DRS通过持续数据同步来促进提升和转移操作，直到客户启动最终迁移和切换。它不会对源虚拟机或系统施加重大依赖关系，因为它可以安装并与任何Windows或Linux环境一起使用。此外，DRS高度可自动化，一旦建立了迁移路径，就可以最小化对专门技能的需求。

Brian Daugerty演示了使用DRS的典型云迁移场景，从包含源实例的受保护区域开始。在激活DRS并在源和目标区域(例如通过VPC对等或传输网关)之间建立连接后，将在源工作负载上安装DRS代理。这些代理将注册到DRS服务，并启动将源卷的块级复制到目标区域的暂存子网。DRS在此过程中管理复制服务器的创建和扩展。

一旦卷被复制，DRS就会维护持续的块级复制，并为恢复目的提供时间点快照。发生灾难时，客户可以启动故障转移，根据复制的数据在恢复子网中创建恢复实例。之后也可以在解决初始问题后进行故障回复。

对于Outposts迁移，Brian Daugerty解释说，DRS需要在Outposts机架上使用Amazon Elastic Block Store (EBS)和Amazon Simple Storage Service (S3)。该过程包括部署Outposts机架、通过Outposts本地网关将其与本地网络集成，并启用本地服务器与Outposts子网之间的路由。

在源VMware虚拟机上安装DRS代理，注册到DRS服务并启动从本地工作负载到Outposts机架上暂存子网中的EC2实例的块级复制。完全复制后，客户可以创建快照并执行切换测试或最终迁移到Outposts迁移子网，从而将实例从VMware环境移动到Outposts机架。

Brian Daugerty指出，在使用Outposts时，客户需要考虑迁移期间和时间点快照的额外EBS和S3存储需求。此外，某些网络模式(如客户拥有的IP寻址)不支持将DRS迁移到Outposts。

第二个讨论的工具是Amazon Application Migration Service (MGN)，这是一个全面的解决方案，用于将工作负载从各种源迁移到亚马逊云科技区域。MGN与DRS共享一些底层技术，但与Amazon Migration Hub集成更紧密，Migration Hub是一种构建全面迁移策略的解决方案，涉及多个利益相关方和合作伙伴。

Brian Daugerty演示了使用MGN的迁移过程，从源数据中心开始。在亚马逊云科技控制台中创建MGN服务并定义暂存、复制和迁移子网后，客户建立源网络与亚马逊云科技区域之间的连接(通过互联网或直连连接)。在源工作负载上安装MGN代理，启动将卷的块级复制到复制子网。

MGN管理复制服务器的创建和扩展，一旦卷被复制，客户就可以执行测试、测试切换，并最终执行完全切换到迁移子网。MGN还提供了启动模板，允许客户为复制实例和迁移实例定义所需的配置。

对于使用MGN进行Outposts迁移的过程略有不同。由于MGN是为迁移到亚马逊云科技区域而设计的，客户会启动源实例和卷的切换到区域。随后，将从切换卷创建Amazon Machine Image (AMI)，然后可用于在Outposts机架上部署新实例。这种方法为已经在使用MGN进行其他云迁移的客户提供了熟悉的迁移体验。

Brian Daugerty接着讨论了第三方迁移工具，重点介绍了亚马逊云科技与合作伙伴Sirrus Data的合作，后者提供了Sirrus Migrate Cloud解决方案。这种多源、多目标迁移工具支持任意到任意的迁移，包括直接从本地VMware环境迁移到Outposts，无需通过区域或在Outposts机架上使用S3。

Sirrus Migrate Cloud平台与亚马逊云科技无缝集成，允许客户通过亚马逊云科技访问密钥和密码或IAM角色提供访问权限。在源虚拟机上安装代理并将其注册到Sirrus Data SaaS平台后，客户可以使用YAML定义或通过用户界面定义迁移操作。

Sirrus Data平台随后在Outposts机架上创建辅助代理，通过TCP直接从本地VMware环境传输数据到Outposts子网，利用Outposts本地网关进行路由。客户可以通过SaaS平台监控迁移进度并批准最终切换，届时平台将在Outposts机架上创建目标实例，调整迁移卷以实现EC2可启动性，并将其附加到新实例。Sirrus Migrate Cloud还提供了RESTful API，用于与GitOps管道集成。

Brian Daugerty总结了三种迁移途径:对于已经在使用DRS并将其迁移到具有S3的Outposts的客户;对于熟悉MGN并将其迁移到区域或Outposts的客户;以及对于直接从本地迁移到Outposts而无需通过区域的第三方工具，如Sirrus Migrate Cloud。

为了说明重新平台化迁移场景，Brian Daugerty分享了一个来自南美的大型银行客户的例子。由于一个庞大的主机数据库为其银行应用程序提供后端支持，该客户部署了多个Outposts机架来满足将工作负载保留在本地的需求。

虽然该客户已将部分基础设施现代化为在VMware上运行的Kubernetes，但他们仍然有虚拟机提供队列服务和其他需要低延迟访问主机数据库的应用程序服务。为了实现现代化并更好地与其亚马逊云科技环境集成，该客户将基于Kubernetes的应用程序重新平台化到Outposts上的Amazon Elastic Kubernetes Service (EKS)。他们还将之前在虚拟机上运行的队列和其他应用程序服务容器化并重新平台化，使其能够与迁移的工作负载一起在Kubernetes上运行。这种Outposts部署提供了访问主机数据库所需的低延迟，同时允许客户利用亚马逊云科技服务并与更广泛的亚马逊云科技环境集成。

接下来，来自英美烟草公司(BAT)的Claudio Keist分享了他们的云之旅以及将他们的第一家工厂迁移到Amazon Outposts的经历。BAT是一家在180多个国家开展业务、拥有超过52，000名员工的全球公司，已从事烟草业务超过120年，并致力于在新类别如电子烟、现代口腔产品和加热烟草产品等领域提供创新产品。

Claudio提供了BAT云之旅的背景信息，该之旅始于大约10年前，当时将非关键、非工厂工作负载迁移到云端。然而，当与他们全球约50家工厂接触时，每家工厂至少有一个数据中心，他们都遇到了反对意见，原因是担心机器控制系统的延迟要求、不适合云端的遗留应用程序以及某些地点的互联网连接不可靠。

在两年前的一次与亚马逊云科技团队的服务评审会议上，Claudio讨论了这些挑战，亚马逊云科技提出了他们的Outposts解决方案作为适合BAT工厂的潜在选择。在向BAT的云和数据中心主管介绍了这一想法并获得赞同后，Claudio被任命为项目经理，负责领导该项目并确保其成功，因为这将是该组织的一项关键和战略性举措。

BAT选择了一家他们有影响力和可管理项目的工厂。经过多轮对话和解决疑虑后，该工厂同意继续进行，但要求从他们最关键的系统Manufacturing Execution System (MES)开始迁移。如果MES迁移成功，他们将有信心迁移其他系统;但如果迁移失败，他们将把Outposts硬件退还给亚马逊云科技，并保持现有设置。

Claudio概述了MES系统架构，它是基于Windows并在VMware上运行的。它包括一个迁移到Outposts的Microsoft SQL集群，由于Outposts的限制，对其进行了一些修改以利用SQL Always On而不是共享存储。该架构还包括两个Windows Failover Cluster，一个用于应用程序，另一个用于机器集成器。

为了解决Outposts上缺乏本地Windows Failover Cluster支持的问题，BAT实现了一个PowerShell脚本，该脚本会调用区域中的API来在主动节点失败时将IP地址从主动节点移动到被动节点。虽然这引入了对故障转移的互联网连接依赖性，但保持了所需的高可用性功能。

在Web服务层，BAT用Application Load Balancer (ALB)和一个Lambda函数来监控Web服务器健康状况，替换了Windows Network Load Balancer (NLB)。这是必需的，因为Outposts不支持NLB使用的粘性会话(尽管在亚马逊云科技区域中是支持的)。

Claudio强调了通过Outposts迁移实现的显著简化，将多个硬件支持、VMware许可、备份许可和磁带管理合同整合为一个单一的Amazon Outposts协议，并纳入他们现有的企业协议。网络设置基本保持不变，支持从本地供应商转移到亚马逊云科技的云支持。总体而言，BAT通过这次迁移实现了45%的成本节省。

Claudio接着分享了该项目的几个经验教训:

1.           订购:亚马逊云科技需要关于数据中心地板、承重能力、电缆布线、冷却系统和互联网连接的详细信息来下订单Outposts，这可能需要一些时间来收集。

2.           交付和安装:Outposts机架完全组装在一个笼子中运送，需要适当的空间并遵守亚马逊云科技对谁可以处理硬件的限制。此外，工程师可能需要接受安全培训才能在工厂数据中心工作。

3.           协作:提前制定计划并与所有利益相关方社会化，记录承诺，并让应用程序所有者参与进来至关重要。

4.           连接性:与亚马逊云科技、网络团队、网络安全团队和云团队进行研讨会，了解Outposts要求、网络设计以及使用BGP (Border Gateway Protocol)在Outposts和本地网络之间进行路由是必要的。

5.           沟通:拥有专门的项目经理对于24/7工厂运营至关重要，可以让不同团队和时区的利益相关方参与进来。

6.           限制:了解应用程序要求和亚马逊云科技限制对于适当规划很重要。

7.           网络测试:在Outposts设置期间而不仅仅是在迁移期间进行端到端网络测试，有助于避免在用户验收测试(UAT)期间出现问题。

8.           负载均衡:彻底了解现有负载均衡器和目标亚马逊云科技负载均衡器的要求和功能是必需的，以解决潜在的挑战。

9.           迁移方法和工具:提前定义迁移方法和工具至关重要。BAT最初在使用Amazon MGN时遇到了问题，因为它需要在Outposts上使用S3，而他们没有。解决方法是将工作负载迁移到区域，创建AMI，然后部署到Outposts，从而增加了迁移时间和成本。

10.       工作负载放置:并非所有本地工作负载都需要迁移到Outposts，有些可以直接迁移到亚马逊云科技区域，这取决于它们的要求。

11.       IP寻址:准备好新的IP地址范围并解决潜在的子网迁移挑战是必要的，因为同一子网不能同时存在于本地和Outposts环境中。

尽管存在挑战，但BAT从Outposts迁移中实现了几个关键好处:

1.           基础设施即服务:无需管理硬件，可专注于核心业务运营，而亚马逊云科技负责基础设施。

2.           简化扩展:扩展Outposts容量非常简单，新需求可在几周内得到满足，而采购本地硬件则需要数月时间。

3.           一致的管理体验:单一供应商、控制台和工具集，用于管理云端和Outposts环境。

4.           降低成本和复杂性:整合供应商、合同和工具，实现45%的成本节省。

5.           弹性:Outposts基础设施专为关键任务工作负载而设计，内置冗余。

6.           基于云的备份和灾难恢复:Outposts备份会自动存储在云端，实现快速的基于云的灾难恢复。

7.           无缝迁移工作负载:利用亚马逊云科技迁移工具，无需重新安装应用程序即可迁移工作负载

Claudio Keist总结了他的演讲，强调了利用前面讨论的亚马逊云科技迁移工具成功将BAT的工作负载无缝迁移到Amazon Outposts。尽管遇到了一些挑战，但迁移使BAT能够将其关键的工厂系统过渡到现代的基于云的基础设施，同时解决了其本地依赖和要求。

在整个会议中，演讲者全面阐述了将具有本地依赖性的VMware工作负载迁移到亚马逊云科技的驱动力、途径、工具和真实世界经验。会议强调了亚马逊云科技提供的灵活性，通过Amazon Outposts和一系列迁移服务和工具，满足了不同客户的需求。

Mayor Thwiker的开场白阐述了客户考虑从VMware迁移的商业和技术动机。这些驱动力包括不断上涨的许可成本、管理遗留平台的风险、整合分散系统、提高可持续性、促进并购活动、增强安全性和可扩展性，以及专注于交付应用程序而非管理基础设施的愿望。

讨论的两条主要迁移途径是过渡到云区域或利用Amazon Outposts进行本地部署。对于云路径，选择范围从无缝迁移到EC2，到重新部署到容器或托管数据库，再到使用云原生技术重新架构，或将VMware Cloud部署在亚马逊云科技上作为临时步骤。Outposts解决方案将亚马逊云科技基础设施和服务直接引入客户的数据中心，使工作负载能够保留在本地，同时受益于亚马逊云科技的云功能。

Brian Daugerty深入介绍了可用的迁移工具和服务，包括亚马逊云科技 Elastic Disaster Recovery Service (DRS)用于持续数据复制和故障转移、Amazon Application Migration Service (MGN)用于全面的迁移规划和执行，以及第三方工具如Sirrus Migrate Cloud用于直接从本地迁移到Outposts。

DRS提供了从各种源环境迁移到亚马逊云科技区域或Outposts的灵活性，具有持续数据同步和故障转移功能。MGN与Amazon Migration Hub紧密集成，提供了全面的迁移体验，包括评估、规划和执行阶段。第三方工具如Sirrus Migrate Cloud能够直接从本地VMware环境迁移到Outposts，无需通过区域或在Outposts上需要S3。

Brian Daugerty还分享了一个来自南美的大型银行客户的真实案例，该客户部署了多个Outposts机架以满足主机数据库后端的低延迟要求。该客户将基于Kubernetes的应用程序重新部署到Amazon Elastic Kubernetes Service (EKS) on Outposts，并将其他应用程序服务容器化，使他们能够在保持必要的低延迟访问主机数据库的同时实现现代化。

Claudio Keist来自英美烟草公司(BAT)的案例研究提供了他们将第一家工厂迁移到Amazon Outposts的详细过程。尽管最初由于延迟、遗留应用程序和连接性问题而持怀疑态度，但BAT决定继续将其关键的制造执行系统(MES)迁移到Outposts进行概念验证。

Claudio介绍了所需的架构变更，如迁移到SQL Always On、使用PowerShell脚本调整Windows Failover Clustering，以及用Application Load Balancer (ALB)和Lambda函数替换Network Load Balancer (NLB)进行健康监控。迁移简化了BAT的IT环境，降低了45%的成本，并实现了一致的云管理、可扩展性、备份和灾难恢复能力。

Claudio分享了整个项目中宝贵的经验教训，涵盖了订购和交付物流、协作和沟通策略、网络设计和测试、负载均衡考虑因素、迁移工具选择(包括使用MGN时在Outposts上需要S3的要求)、工作负载放置决策以及IP寻址挑战等方面。

尽管存在复杂性，但BAT从Outposts迁移中获得了显著的好处，包括基础设施即服务、简化扩展、一致的管理体验、降低成本和复杂性、内置弹性、基于云的备份和灾难恢复，以及能够成功进行无需重新安装应用程序的无缝迁移。

本次会议全面概述了将具有本地依赖性的VMware工作负载迁移到亚马逊云科技的动机、途径、工具和真实世界经验。它强调了亚马逊云科技提供的灵活性和解决方案范围，使客户能够选择符合其特定需求的方法，无论是过渡到云区域还是利用Amazon Outposts进行本地部署。

通过演讲者分享的见解和来自英美烟草公司的详细案例研究，本次会议展示了亚马逊云科技致力于在客户的云迁移之旅中提供支持，提供必要的工具、服务和专业知识，以应对迁移关键任务工作负载的复杂性，同时解决本地依赖性和要求。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。