构建高度可扩展的纯IPv6云主机

本文介绍了如何使用商用服务器之间的纯 IPv6 通信构建新的高度可扩展的云托管解决方案，以及我们所面临IPv6协议会有哪些问题，同时，该如何处理这些问题以支持超过1000万的活跃用户。

为什么我们决定运行一个纯IPv6的网络？

在 Hostinger 中，我们关注很多创新性技术，所以我们决定运行一个基于 IPv6 名为 Awex 的新项目。该项目除了前端（面向用户端）服务在双栈环境中运行外，其他服务全程都只应用纯IPv6协议运行。

架构

我并不想深究文章的细节内容，但我还是会描述关于构建这个架构所需的关键组件。

我们正在使用 pods 技术。一个 pod 就是一个利用 anycast（任播）技术共享相同的VIP（虚拟网络协议）地址的集群，可以并行处理HTTP / HTTPS请求。每个拥有数百个节点的 pod 集群，可以分散处理用户的请求而不会造成单一节点的饱和。利用 BGP（边界网关协议） 和 ECMP（等价多路径路由） 进行并行化，并同时采用弹性散列来避免分流。因此，每个边缘节点都会运行一个 BGP（边界网关协议）守护进程来通告 VIP 到 ToR（架顶式）交换机的过程。作为 BGP 守护进程，我们使用单个IPv6会话来运行 ExaBGP 脚本并来通告两种协议（IPv4 / IPv6）。BGP会话在服务器引导阶段自动配置。根据服务器的角色不同，公告也不同，包括每个节点的 /64 前缀和许多纵向的 VIP。/64前缀是专门为容器委派的。每个边缘节点运行大量的容器，并且在其他节点和内部服务之间相互通信。

每个边缘节点都使用 Redis 作为从属副本来获取特定应用程序的上游，因此每个上游都有数千个容器（IPv6）作为跨越各个节点之间的列表。这些庞大的列表使用 consul-template 实时生成。其中边缘节点具有许多公共的 IPv4（512）和全局的

IPv6（512）地址。想知道为什么吗？原因就是为了处理 DDoS（拒绝服务攻击） 攻击。我们使用 DNS（域名系统） 来随机化 A/AAAA 以作为对客户的响应。客户端将它的域名指向我们的 CNAME 记录，并被命名为route，而这个记录又被我们名为 Razor 的定制服务随机化。我们将在后续的帖子中讨论 Razor 服务。

网络设备

首先，对于 ToR 交换，我们决定使用 OpenSwitch 平台，它是一个相当年轻的，但又不失趣味和前途的社区项目。我们在实验室测试了这个操作系统几个月，甚至为 OpenSwitch 做了一些修改，比如说这个 patch 补丁。其中有一些bug，虽然大部分都最终被修复，但并不像我们所需要的那样快。所以，我们推迟了一段时间 OpenSwitch 的实验，并尝试在 Cumulus 平台 开发。顺便说一句，我们仍然在测试 OpenSwitch 中，因为我们打算在不久的将来使用它。

Cumulus 允许我们有一个完全自动化的网络，在这里我们重新配置诸如 BGP 邻居，上游，防火墙，网桥等元素。变得不同的是，例如，如果我们添加一个新节点，Ansible 将通过查看 LLDP 属性自动 Chef 清单中的更改，并为特定交换机重新生成网络配置。如果我们要添加一个新的 BGP 上游或防火墙规则时，我们只需要创建一个到我们 GitHub 仓库的pull请求即可，所有的事情都会自动完成，其中包括语法检查和生产变更的部署。每个节点都使用 Clos 拓扑连接到单个10GE接口。

我们在这个过程中遇到的问题

• 定义 IPv6 地址的格式不同：有的服务在（[2001:dead:beef::1]）中使用方括号来封装IPv6地址，有的则在（2001:dead:beef::1）不使用方括号封装，那么最好办法是使用方括号，像这样（[2001::dead::beef::1::::1]），（::ffff:<ipv4>）。
• 与 IPv6 协议不兼容的库：例如，Sensu 监控框架不支持 IPv6 协议，所以我们要选择 Prometheus 监控框架。
• 思科 IOS 错误：我们无法使用单个 IPv6 iBGP（IPv6 内部边界网关协议）会话去处理这两个协议，因为思科包括链接本地地址与全局作为下一跳。有两个选项可以排除链路本地地址：使用专用 AS 或回送接口作为更新源。我们需移动到每个机架的私人 AS 号码。
• MTU 问题：像接收队列丢失。我们在 VMWare ESXi 节点上运行了许多内部服务，因此在实验室启动项目之后，我们在接收端看到了很多内容。经过深入调查，我们发现这个数据丢失的原因是使用了比预期更大的 MTU（最大传输单元） 尺寸（1518 + 22）所导致的。在默认情况下，NIC 的大小为 MTU 的1500 + 额外的基础标题，其中包括了以太网标题，校验和以及.1Q。那么，首先，我尝试改进接收队列的环形缓冲区，但它只需很短的时间就已经溢出了 - 因为它们填满的速度太快了，主要是 vmxnet3 驱动程序不能足够快地消耗应用它们。我登录到 ESXi 主机，并检查任何客户机的 vmxnet3 统计信息：# of pkts dropped due to large hdrs:126。发现这里有大量的报头丢失，所以我决定在一个 vmxnet3驱动程序中进行 hook（钩子）操作，并执行vmxnet3_rx_error()函数，看看在缓冲区长度中正在排队

的是什么。这实在令人失望，因为缓冲区大小仅有54字节，甚至不是 IPv4 或 IPv6 数据包。缓冲区中只是一些 VMWare 的基础标题。最后，通过调整在 ESXi 上运行的节点的 MTU ，我们终于能够处理所有数据包而不会丢失它们。

经验教训

• 对于更大的基础架构，IPv6协议更可接受，更具可扩展性。
• 有很多工具、服务和库，它们部分支持或完全不支持IPv6。
• 相较于IPv4，IPv6允许我们更精细地去定义和控制地址空间。
• IPv6具有更好的性能，即使其包头高于IPv4。但它没有碎片，没有校验和，没有NAT（网络地址转换）。
• 没有IPv6是一种缺陷，而不仅仅只是一个功能的缺失。
• 我们已经爱上了IPv6。