Amazon Web Services 网络的规模为全球 69 个地区的 22 个区域：美国、欧洲、亚洲、非洲和澳大利亚。 每个区域最多包含 8 个数据中心 - 数据处理中心。 每个数据中心都有数千或数十万台服务器。 网络的设计方式考虑了所有不太可能出现的中断情况。 例如，所有区域彼此隔离，可达性区域相距数公里。 即使切断电缆，系统也会切换到备份通道，信息丢失也将相当于几个数据包。 Vasily Pantyukhin 将讨论该网络构建的其他原则以及它的结构。
瓦西里·潘秋欣 最初在 .ru 公司担任 Unix 管理员，在大型 Sun Microsystem 硬件上工作了 6 年，并在 EMC 宣扬以数据为中心的世界 11 年。 它自然地演变成私有云，然后转移到公共云。 现在，作为一名 Amazon Web Services 架构师，他提供技术建议以帮助在 AWS 云中生活和开发。
在AWS三部曲的前一部分中，Vasily深入研究了物理服务器和数据库扩展的设计。 Nitro 卡、基于 KVM 的定制管理程序、Amazon Aurora 数据库 - 有关所有这些内容，请参阅材料“” 阅读上下文或观看 演讲。
本部分将重点关注网络扩展，这是 AWS 中最复杂的系统之一。 从扁平网络到虚拟私有云的演变及其设计、Blackfoot 和 HyperPlane 的内部服务、嘈杂邻居的问题，以及最后 - 网络、主干和物理电缆的规模。 关于这一切都在削减之下。
免责声明：以下所有内容均为 Vasily 的个人观点，可能与 Amazon Web Services 的立场不一致。
网络扩展
AWS 云于 2006 年推出。 他的网络相当原始——具有扁平结构。 私有地址范围对于所有云租户来说都是通用的。 启动新虚拟机时，您意外收到此范围内的可用 IP 地址。
这种方法很容易实现，但从根本上限制了云的使用。 特别是，开发将地面专用网络与 AWS 中的专用网络相结合的混合解决方案相当困难。 最常见的问题是 IP 地址范围重叠。
虚拟私有云
事实证明，云计算很受欢迎。 现在是时候考虑可扩展性以及数千万租户使用它的可能性了。 网络扁平化成为一大障碍。 因此，我们思考如何在网络层面隔离用户，让他们能够独立选择IP范围。
当您想到网络隔离时，您首先想到的是什么？ 当然 VLAN и VRF - 虚拟路由和转发.
不幸的是，它没有起作用。 VLAN ID 只有 12 位，仅提供 4096 个隔离段。 即使是最大的交换机也最多可以使用 1-2 个 VRF。 将 VRF 和 VLAN 结合使用只给我们带来了几百万个子网。 这对于数千万租户来说肯定是不够的，每个租户都必须能够使用多个子网。
我们也根本无力购买所需数量的大型盒子，例如从思科或瞻博网络购买。 有两个原因：它太贵了，我们不想受到他们的开发和补丁政策的摆布。
只有一个结论——制定自己的解决方案。
2009 年我们宣布 VPC - 虚拟私有云。 这个名字一直沿用至今，现在许多云提供商也使用它。
VPC是一个虚拟网络 SDN （软件定义网络）。 我们决定不在 L2 和 L3 级别发明特殊协议。 该网络在标准以太网和IP 上运行。 对于通过网络传输，虚拟机流量被封装在我们自己的协议包装器中。 属于租户VPC的ID。
听起来很简单。 然而，还有一些严峻的技术挑战需要克服。 例如，在何处以及如何存储有关映射虚拟 MAC/IP 地址、VPC ID 和相应物理 MAC/IP 的数据。 在 AWS 规模上，这是一个巨大的表，应该能够以最小的访问延迟运行。 对此负责 地图服务，它在整个网络中以薄层形式传播。
在新一代机器中，封装是由 Nitro 卡在硬件级别执行的。 在较旧的实例中，封装和解封装是基于软件的。
让我们弄清楚它的一般情况是如何工作的。 我们先从L2级别开始。 假设我们在物理服务器 10.0.0.2 上有一个 IP 为 192.168.0.3 的虚拟机。 它将数据发送到位于 10.0.0.3 上的虚拟机 192.168.1.4。 生成 ARP 请求并将其发送到网络 Nitro 卡。 为简单起见，我们假设两个虚拟机位于同一个“蓝色”VPC 中。
映射将源地址替换为自己的地址，并将 ARP 帧转发到映射服务。
映射服务返回通过 L2 物理网络传输所需的信息。
ARP 响应中的 Nitro 卡将物理网络上的 MAC 替换为 VPC 中的地址。
传输数据时，我们将逻辑 MAC 和 IP 包装在 VPC 包装器中。 我们使用适当的源和目标 IP Nitro 卡通过物理网络传输所有这些内容。
包的目的地物理机将执行检查。 这对于防止地址欺骗的可能性是必要的。 该机器向映射服务发送一个特殊请求并询问：“我从物理机 192.168.0.3 收到了一个发往蓝色 VPC 中 10.0.0.3 的数据包。 他合法吗？
映射服务检查其资源分配表并允许或拒绝数据包通过。 在所有新实例中，Nitro 卡中都嵌入了额外的验证。 即使在理论上也是不可能绕过它的。 因此，欺骗其他 VPC 中的资源是行不通的。
接下来，数据被发送到目标虚拟机。
映射服务还充当逻辑路由器，用于在不同子网中的虚拟机之间传输数据。 一切在概念上都很简单，我不会详细说明。
事实证明，当传输每个数据包时，服务器都会转向映射服务。 如何应对不可避免的延误？ 缓存当然了
美妙之处在于您不需要缓存整个巨大的表。 物理服务器托管来自相对较少数量的 VPC 的虚拟机。 您只需要缓存这些VPC的信息即可。 在“默认”配置下将数据传输到其他 VPC 仍然不合法。 如果使用 VPC 对等功能，则有关相应 VPC 的信息会另外加载到缓存中。
我们整理了数据到VPC的传输。
黑脚
如果需要将流量向外传输，例如传输到互联网或通过VPN传输到地面，该怎么办？ 在这里帮助我们 黑脚 — AWS 内部服务。 它是由我们的南非团队开发的。 这就是为什么该服务以生活在南非的企鹅命名。
Blackfoot 解封装流量并对其进行所需的操作。 数据按原样发送到互联网。
使用 VPN 时，数据将被解封装并重新封装在 IPsec 中。
使用 Direct Connect 时，流量会被标记并发送到适当的 VLAN。
超平面
这是一个内部流量控制服务。 许多网络服务需要监控 数据流状态。 例如，当使用 NAT 时，流量控制必须确保每个 IP:目标端口对都有唯一的出站端口。 在平衡器的情况下 美国职业棒球大联盟 - 网络负载均衡器，数据流应始终定向到同一目标虚拟机。 安全组是一个状态防火墙。 它监视传入流量并隐式打开传出数据包流的端口。
在AWS云中，传输延迟要求极高。 这就是为什么 超平面 对整个网络的性能至关重要。
Hyperplane 构建在 EC2 虚拟机上。 这里没有魔法，只有狡猾。 诀窍在于这些是具有大内存的虚拟机。 操作是事务性的并且专门在内存中执行。 这使您可以实现仅数十微秒的延迟。 使用磁盘会扼杀所有生产力。
Hyperplane 是一个由大量此类 EC2 机器组成的分布式系统。 每个虚拟机的带宽为 5 GB/s。 在整个区域网络中，这提供了令人难以置信的太比特带宽并允许处理 每秒数百万个连接.
HyperPlane 仅适用于流。 VPC数据包封装对其来说是完全透明的。 此内部服务中的潜在漏洞仍会阻止 VPC 隔离被破坏。 以下级别负责安全。
吵闹的邻居
还有一个问题 吵闹的邻居 - 吵闹的邻居。 假设我们有 8 个节点。 这些节点处理所有云用户的流量。 一切似乎都很好，负载应该均匀分布在所有节点上。 节点非常强大，很难使其过载。
但我们构建的架构甚至是基于不太可能的场景。
低概率并不意味着不可能。
我们可以想象一种情况，一个或多个用户会产生过多的负载。 所有 HyperPlane 节点都参与处理此负载，其他用户可能会遇到某种性能影响。 这打破了云的概念，租户之间没有能力相互影响。
如何解决邻居吵闹的问题？ 首先想到的是分片。 我们的 8 个节点在逻辑上分为 4 个分片，每个分片有 2 个节点。 现在，吵闹的邻居只会打扰所有用户的四分之一，但会极大地打扰他们。
让我们以不同的方式做事。 我们将只为每个用户分配 3 个节点。
诀窍是将节点随机分配给不同的用户。 在下图中，蓝色用户与其他两个用户（绿色和橙色）之一的节点相交。
对于 8 个节点和 3 个用户，噪声邻居与其中一个用户相交的概率为 54%。 蓝色用户正是以这种概率影响其他租户。 同时，也只是其负载的一部分。 在我们的示例中，这种影响至少在某种程度上不会对每个人都明显，但只有三分之一的用户会注意到。 这已经是一个很好的结果了。
将相交的用户数量
概率（百分比）
0
18%
1
54%
2
26%
3
2%
让我们更接近现实 - 让我们以 100 个节点和 5 个节点上的 5 个用户为例。 在这种情况下，没有任何节点相交的概率为 77%。
将相交的用户数量
概率（百分比）
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
在实际情况中，由于超平面节点和用户数量巨大，嘈杂的邻居对其他用户的潜在影响很小。 这个方法称为 混合分片 - 洗牌分片。 它最大限度地减少了节点故障的负面影响。
许多服务都是基于 HyperPlane 构建的：网络负载均衡器、NAT 网关、Amazon EFS、AWS PrivateLink、AWS Transit Gateway。
网络规模
现在我们来谈谈网络本身的规模。 2019 年 XNUMX 月，AWS 在以下地区提供服务： 22个地区，还有 9 个正在计划中。
- 每个区域包含多个可用区。 全世界有 69 个。
- 每个可用区由数据处理中心组成。 总共不超过8个。
- 该数据中心拥有大量服务器，有些甚至多达300万台。
现在让我们对所有这些进行平均，相乘并得到一个令人印象深刻的数字，反映了 亚马逊云规模.
可用区和数据中心之间有许多光纤链路。 在我们最大的区域之一，铺设了 388 个通道，专门用于 AZ 之间的通信以及与其他区域的通信中心（转运中心）的通信。 总的来说，这让人疯狂 5000太比特.
Backbone AWS 专为云构建并优化。 我们在渠道上构建它 100 GB/秒。 我们完全控制他们，除了中国的地区。 流量不与其他公司的负载共享。
当然，我们并不是唯一拥有私有骨干网络的云提供商。 越来越多的大公司正在走这条路。 这得到了独立研究人员的证实，例如来自 .
该图显示内容提供商和云提供商的份额正在增长。 正因为如此，骨干提供商的互联网流量份额不断下降。
我将解释为什么会发生这种情况。 以前，大多数 Web 服务都可以直接从 Internet 访问和使用。 如今，越来越多的服务器位于云端并可以通过 加 - 内容分发网络。 要访问资源，用户只能通过互联网到达最近的 CDN PoP - 存在点。 最常见的是它位于附近的某个地方。 然后，它离开公共互联网，通过私人骨干网飞越大西洋，直接访问资源。
我想知道如果这种趋势持续下去，10年后互联网会发生什么变化？
物理渠道
科学家们尚未弄清楚如何提高宇宙中的光速，但他们在通过光纤传输光的方法方面取得了巨大进展。 我们目前使用 6912 光缆。 这有助于显着优化其安装成本。
在某些地区我们必须使用特殊电缆。 例如，在悉尼地区，我们使用带有防白蚁特殊涂层的电缆。
没有人能免受麻烦，有时我们的经脉会受到损害。 右边的照片显示了美国一个地区的光缆被建筑工人撕裂的情况。 此次事故仅丢失了13个数据包，这令人惊讶。 再说一遍——只有13岁！ 系统立即切换到备用通道 - 秤正在工作。
我们快速了解了亚马逊的一些云服务和技术。 我希望您至少对我们的工程师必须解决的任务规模有一些了解。 就我个人而言，我觉得这非常令人兴奋。
这是 Vasily Pantyukhin 关于 AWS 设备的三部曲的最后一部分。 在 部分描述服务器优化和数据库扩展，并在 — 无服务器功能和 Firecracker。
上 XNUMX 月，Vasily Pantyukhin 将分享亚马逊设备的新细节。 他 关于亚马逊的故障原因和分布式系统的设计。 24月XNUMX日还是有可能的 票价好，然后付款。 我们在HighLoad++等你，快来聊聊吧！
来源： habr.com