当Instagram在2012年加入Facebook时，我们迅速构建了大量的Facebook基础设施集成点，以加快产品开发并使社区更安全。我们最初通过使用临时端点在Facebook网络服务之间高效传递来构建这些集成。然而，我们发现这种方法有点笨拙，限制了我们使用Facebook内部服务的能力。从2013年4月开始，我们开始将Instagram的后端从AmazonWebServices(AWS)大规模迁移到Facebook的数据中心。这将简化与其他内部Facebook系统的集成，并允许我们充分利用为管理大规模服务器部署而构建的工具。迁移的主要目标是在过渡期间保持网站的完整服务，避免影响功能部署，并尽量减少基础架构级别的更改以避免操作复杂性。起初迁移看起来很简单：在Amazon的弹性计算云(EC2)和Facebook的数据中心之间建立安全连接，然后逐个迁移服务。简单的。不仅。这种简单迁移的主要障碍是Facebook的私有IP空间与EC2的私有IP空间之间的冲突。我们只有一条路：首先迁移到Amazon的虚拟私有云(VPC)，然后使用AmazonDirectConnect迁移到Facebook。Amazon的VPC提供了必要的扩展寻址以避免与Facebook的私有网络发生冲突。我们被这项任务吓倒了；EC2上运行着数以千计的实例，每天都有新的实例出现。为了最大限度地减少停机时间和操作复杂性，在EC2和VPC中运行的实例必须看起来来自同一网络。AWS不提供共享安全组的方法，也不提供桥接私有EC2和VPC网络的方法。这两个专用网络进行通信的唯一方法是使用公共地址空间。所以我们用Python开发了Neti——一个由Hadoop的官方子项目ZooKeeper提供支持的动态IP数据包过滤系统守护进程。Neti提供安全组功能，为运行在EC2和VPC中的每个实例提供单独的地址。它管理着数以千计的本地NAT和每个实例的过滤规则，允许使用单独的、平面的“覆盖”地址空间进行安全通信。NAT规则选择源实例和目标实例之间最有效的路径。VPC与EC2实例通信使用公网，内部通信使用私网。这对我们的应用程序和后端系统是透明的，因为Neti在每个实例上应用了适当的IP数据包过滤系统。将构成Instagram堆栈的各种组件从EC2迁移到VPC环境只用了不到三周的时间，这让我们相信如果没有Neti，它会花费更长的时间。在此过程中没有发生重大服务停机，我们很快意识到这是有史以来最快的VPC规模迁移。随着VPC迁移完成并且我们的实例在兼容的地址空间中运行，Instagram已准备好开始完成向Facebook数据中心的迁移。围绕EC2构建的工具集已经存在多年，用于管理Instagram的生产系统，包括配置管理脚本、用于供应的Chef（“厨师”），用于从应用程序部署到数据库主推广Fabric的广泛操作任务。此工具集为EC2所做的假设不再适用于Facebook环境。为了让我们的配置工具更便携，Instagram专用软件现在运行在Facebook数据中心服务器上的Linux容器(LXC)中。Facebook提供构建基础系统的工具，Chef在容器中运行以安装和配置Instagram特定软件。为了提供跨越EC2和Facebook数据中心的基础架构，我们当前的Chef食谱（“Chef'sRecipe”）讨论了一种新逻辑，允许它们支持Facebook内部使用的CentOS平台以及EC2中使用的Ubuntu。用于基本任务的EC2特定命令行工具，例如在Chef“knife”工具中枚举正在运行的主机和配置支持，已被同一工具取代。该工具被设计为一个抽象层，它提供与EC2中使用的工具类似的工作流程，从而减少人员压力并简化向新环境的技术过渡。在工具和环境到位后的两周内，我们完成了Instagram生产基础设施从VPC到Facebook数据中心的迁移。这个阶段性的工作实现了项目开始时设定的主要目标，取得了巨大的成功。此外，在规划和执行迁移的阶段，该团队交付了近两倍的主要功能，例如InstagramDirect和我们的用户群。我们坚持我们的目标意图，即尽量减少变化，因此过渡对我们的工程团队来说基本上是透明的。回顾这个历时一年的项目的一些关键要点：规划最小的变化以支持新环境，并避免“趁我们还在这里”的诱惑。有时，疯狂的想法会奏效——Neti就是一个证明。投资构建你的工具；执行如此大规模的迁移，最需要的是一个意想不到的曲线球。重用团队熟悉的概念和工作流，以避免向团队传达变更的复杂性。这是多个团队和许多个人贡献者的共同努力。在接下来的几周内，我们将更深入地了解这一迁移工作，密切关注这一领域。英文原文：MigratingFromAWStoFB翻译自：http://www.oschina.net/translate/migrating-aws-fb
