首次揭秘AWS网络长成史：工程是取舍的艺术

简介：本文来自AWS公司前Principal Network Engineer-Justin Pietsch。

I've done some part of almost all aspects of networking at Amazon. Some while we were small and some to help Amazon to get really big. I've done most aspects of Networking at a large e-commerce / cloud network. Routing protocols, load balancing, network management tools, lots of oncalls, etc

With a small team I designed the networks that brought commodity/white-box networking to Amazon that also led to how we build, scale, and operate our current giant datacenter networks. This inluded network design, selecting network ASICS and other device properties, and designed management infrastructure for a very big network. I started the software team that owns the router software. I designed much of the overall approach to management and even built some of the software. I think deeply about how to design networks so that they are buildable and operable. I used to own all Load Balancers at Amazon, mostly focused on keeping up with capacity growth. Thankfully that was a long time ago. I've done things like capacity management, at various times of our journey, when we were blind making dataless decisions and adding some amount of data and analysis. Luckily we've hired professionals to do a much more thorough job. Depending on how you count, I believe the Amazon/AWS datacenter networks are the largest in the world. I've been a key part in making that possible. I've spent a lot of time understand how our network impacts Amazon applications and vice-versa.

大伙儿常说，网络太复杂了，需要变得更简单一些，我当然相信这一点。我认为工程师搭建了如此复杂的网络，却没有充分考虑到随着时间的推移，运营这些网络会有多困难。原因有很多：有些人相信供应商的炒作，喜欢酷炫的东西，业务需求复杂的功能，或者前期没有为增长做好计划等等。网络越复杂，就越难运维，越脆弱，也越难做出改变。一切都取决于你能在多长时间内运营好你的网络。一个网络很复杂并不意味着它是错误的。记住，engineering is the art of tradeoffs，工程是取舍的艺术，所以带来复杂性的领域值得研究，看看如何使事情变得更好(参阅：谷歌从软件定义网络SDN走向应用定义网络ADN)。

我想，通过我所经历的简化网络的例子可能会有所帮助。通常情况下，当你在考虑权衡取舍并想简化网络时，你必须与网络使用方进行讨论。你必须衡量运维这些功能的复杂性，并想想是否有更好的方法来实现。参与讨论的人或者公司/文化不同时，你都会得到不同的答案，但关键是要做分析，明白取舍。

L2/VLAN

2002年底当我开始在Amazon工作时，我们有两个基于L2和VLAN的数据中心，有三个主要网络：网站、数据库和企业网。数据中心的每台主机都有两个网卡，根据主机的用途，连接到这三个网络中的两个上。我没有参与这些设计，我想当时的想法是让数据库网络上的数据库主机远离互联网，他们在数据库和公司网络上，但不在网站上；网站主机在网站和数据库上，但不在企业网上。我不记得是如何为这些网络上的主机分配vlan了，大概率可能取决于它们在哪个负载平衡器上。这是我特别反感的一种复杂性；伪安全并没有真正让事情变得更安全，而是让你觉得更安全，让其他事情变得更复杂。然而，这并不容易改变。仅仅因为我不喜欢，认为有更好的方法，并不意味着我们可以做出改变，改变需要时间和行动。

在2000年初，负载均衡几乎完全是基于L2的，至少在Amazon是这样的。这就意味着，LB需要成为相关设备的默认网关。如果我没记错，如果一个主机需要和一个服务对话时，当这个服务的主机在同一个VLAN下，那么他们就不能成功对话，这个服务需要被移到另一个VLAN下。这使得多服务变得很麻烦，需要网络团队知道什么软件在什么主机上。如果可以避免的话，你永远不希望网络团队夹在软件运行的中间。

如你所料，这带来大量的故障和运营噩梦。难以为继也很难扩展规模，我想现在大多数人都知道远离L2和VLAN以及生成树，但在2000年初却不这样，这就是为什么我们都抛弃了L2+VLAN。

也许你听说过Amazon著名的 2-pizza团队（注：即每个内部团队都应该足够小，小到可以用两个披萨喂养）。这个概念有点被夸大了，因为它几乎从来没有那么正式或固定，但它是真实的，文化是使团队可以（而且确实）风暴出尽可能多的不同服务，为客户创建他们需要的东西。这一切都导致了软件服务的爆炸性增长，每个服务都以无人真正理解或明白的方式与其他软件服务进行互动。

如果我们事先考虑过，就会发现这个网络不可能长久地发挥作用。我们很多人都深受L2之害，也深受运营之苦，我们讨论来讨论去要让它更简单。我们怎样才能解开这个复杂的结呢？第一步是引入L4/L7负载均衡。我们需要负载均衡可以改写目标地址头，而不必是在中间环节。我们需要将负载平衡从网络架构中解耦，我们引进了一些新的LB，可以支持L4/L7的一些新的功能。将LB剥离不再作为默认网关，给了我们更多的灵活性。如果没有这种灵活性，我们就无法继续下去，但在当时，我们没有意识到这种重要性，只是知道我们的工作方式是不可行的。

这样就摆脱了大部分的L2需求，只是每个数据中心的主机还有两块网卡，需要连接两个网络。当主机进入网络时，取决于主机上运行的软件，要么需要定制的电缆，要么需要如VLAN一样的动态手段，无论哪种方式都需要在网络中进行主机配置。如果可以，没人希望网络影响到主机上运行的软件。我们是如何解决这个问题的呢？我们去找软件团队，讨论是否可以让一个网络中的一台主机只有一个网卡。由于Amazon.com的巨大变化，我们当时正在建立新的数据中心设计。2004年初，亚马逊将Amazon.com从西雅图数据中心转移到弗吉尼亚的数据中心。我们利用这一变化来清理网络。我们去除了数据库网络，只留下网站和企业网络，主机只能在一个网络上。当主机被订购时，很容易区分是来自网站还是企业需求，所以在物理设备入网时，对它们进行物理分配不再是一个大负担。通过了解企业真正需要来简化网络，这是一个理解取舍的例子。企业最初要求两个网卡可能是为了支持更好的安全性，但这并不是真的需求，反而带来运营的痛苦，从而导致了更多的故障。当然，在“辛苦”运营网络多年成为老手之后，更容易得出得出上述的论点。此时降低网络复杂性更容易理解。

万事俱备后，我们就可以把主机网络全部变成L3。这也意味着每个主机网络在交换机上几乎是一样的，然后我们可以自动配置所有的ToR交换机，这是在2005或2006年的事情。这种网络的简化对于即将到来的增长是必要的，尽管我们当时并不知道，当时只是我们中的一些人真的厌倦了讨厌的oncall。

负载均衡策略

另一个例子是关于2000年的负载均衡器，虽然我可以宣称成功，但事实上，结果并不是那么明确。负载均衡难搞，而网络部门肩负重任。软件团队希望可以有更复杂的流量路由，但我们却踢回了皮球。负载平衡非常复杂，我们不相信我们有能力跟上策略的变化并保持一切可用。最终，软件团队添加了一个代理层，他们在其中加入自己掌控的软件，以便在必要时引导流量。这给了他们想要的控制权，并与他们的其他开发工具包括部署相匹配。

我知道其他公司在他们的负载均衡中做了（可能仍然在做）复杂的流量路由。我们选择不这样做，这对我们来说是很好的结果了。部分原因是这种分离更符合亚马逊的文化，并允许关心流量路由的团队拥有自己的决定权，而不必依赖于要操心其他事物的网络团队。

基于商用芯片的路由器

在2009年，我们AWS网络部的几个人被要求规划如何使用商用芯片实现单芯片的路由器，而不仅仅是ToR交换机。最后，我们想用一个大型的3层CLOS设计来取代我们的汇聚网络。当我们在思考这样做的意义时，有几件事变得很清楚。我们将在一个数据中心内部署数百个（然后是数千个）这样的设备，这与我们以前几十个、有时小几百个设备非常不同。此时对规模的要求，包括后续增长目标变得非常明确，我们必须改变我们一直以来的网络方式，特别是关于管理和系统变更。

我们创建了一个配置生成系统，通过很少的操作就可以非常可靠地使每个设备都一样。这一系列的权衡意味着工程师们不再能够轻易尝试新的功能，相反，新的东西需要很长的时间来测试，然后再进入我们的软件系统。我们转向了一个配置生成系统，该系统在结构上是正确的，意味着如果配置来自生成系统，那么它被影响的可能性就很小。这种系统不太灵活，需要更长的时间来生成变更，但由于我们有大量的设备，我们认为这是保持一切一致的最好方法，这是必须的。

我们采取的一个有争议的做法是，（几乎）所有对这些设备的变更都是对设备进行全面的配置替换和重新启动。同样，我们必须权衡利弊。每次变更都要重启会增加变更的时间，也会增加设备或链路无法恢复的风险。当你有那么多设备时，它还需要软件来管理整个过程。另一方面，需要计算和编码的流程减少了，而且我们无需在NOS中的bug发生状态变化时进行作业。我认为这是一个非常棒的决定，但这是我的想法，我有我的偏见。权衡利弊后，我们确实付出了代价，这并不是没有坏处的好事。

我们所做的另一件事（我指的是团队，我与这部分无关，但它非常有效和重要）是为了方便上线推出了一个完全装配好的网络设备的机架。我们把设备的数量增加了10倍，把电缆的数量增加了10倍，把所有的东西都打包到一个小机架上。我们规划了电缆线束和布线方案，并与系统集成商合作，方便机架上的网络设备可以随时插入。这种物理硬件的集成对于项目和网络的成功以及我们跟上AWS增长的能力是非常重要的。换句话说，选择使用ToR风格的设备进行汇聚的后果之一就意味着更多的电缆和设备，因此我们不得不设计一个解决方案来处理我们之前没有担心过的物理复杂性问题。（参阅：Facebook首个亚洲数据中心离不开的网络神器）

虚拟网络

在这篇文章的第一部分，有一个关于从网络中移除L2的部分。我们做了一个一致的L3网络。随着时间的推移，特别是由于EC2的出现，我们不得不将网络虚拟化重新加入到网络中。因为运维和扩展网络很麻烦，我们坚持认为虚拟网络发生在主机上。当EC2首次推出时（我想现在叫EC2 classic），网络很简单，没有办法选择自己的地址，但你可以将你的网络与其他人隔离。后来它被VPC取代，VPC是一个更复杂的多租户网络虚拟化。这些都不在路由器上，因此我们可以处理可能有数百万租户和数百万主机的规模。这意味着物理网络对虚拟网络一无所知，可以独立扩展，这对AWS来说是必要的。当然，代价是主机上有很多复杂的软件。我希望这种方式可以更容易地用于更多的网络，我不喜欢数据中心的EV**，但如果你在数据中心需要虚拟网络，就没有很多选择。

为Region添加BGP

有时你必须增加复杂性。操作的易用性至关重要，但您还必须考虑可用性。

Amazon和AWS在每个地区都有多个数据中心（可用区）。最初在2004年，当我们第一次为Amazon.com在一个地区做两个数据中心时，这些数据中心都很小，所以我们只是继续在这些数据中心内和之间使用OSPF。随着时间的推移，增量越来越多。我们在区域之间使用BGP，但在一个区域内则全部使用OSPF。这更容易操作，但没有满足我们向客户承诺的隔离性。我们在OSPF中的bug影响了整个区域，变更中的错误破坏了整个区域链接。然后我们决定必须在可用区之间添加BGP和它更复杂的策略。这是一个漫长而复杂的过程，因为这时很多业务已经运行，我们不能为了完全转向BGP将Amazon.com和AWS关闭几天。增加BGP确实带来了更多的可用区域，但代价是大量的工作和更复杂的政策管理。（参阅：BGP算个P！AWS最爱原来是OSPF）

结论

网络的复杂性通常是有原因的，有时甚至是好的出发点。作为一名工程师，你需要思考这些原因的含义以及如何权衡。你需要充分了解软件系统中正在发生的事情，以便知道在哪里/如何进行取舍。当你的网络和需求随着时间的推移而发生变化时，要考虑如何使事情变得更简单。当你注意到有物故障，有事难改变，有人半夜给你打电话时，想想如何使网络更简单。始终要考虑如何使网络运行得更好，如何使它更可用，以及如何跟上必要的变化。这些事情可能会相互PK。例如，你可以增加功能使网络更加复杂，这样无论业务向哪个方向发展，你都能做好准备，但这通常会使保持网络正常运行变得更加困难，然后如果有意料之外的事情发生，那么在计划之外进行变更就更加困难。权衡利弊。更简单和更少的特性通常更容易随时间变化，但您必须平衡其他需求，如可用性或业务需求。

这里的经验教训并非适用于所有人。首先如上所述L2的使用率已经不是很高；其次，在Amazon跟上业务规模成了最重要的事情，我们有软件团队来解决一些问题，所以我们不得不做出一些对其他人来说不值得的取舍。（更多AWS运维文化参阅：北美FAAG四巨头网络运维私享会）