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

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

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

在Hostinger，我们关心很多创新技术，所以我们决定运行一个名为Awex的新项目，它基于这个协议。只有前端（面向用户）的服务在双栈环境中运行 — 其他的东西都是仅用于IPv6的西向流量。

结构体系

在这篇文章中我不想详细介绍，但是我会描述构建这个架构所需的关键组件。

我们正在使用pod。pod是与anycast共享相同的VIP（虚拟IP）地址的集群，可以并行处理HTTP/HTTPS请求。每个pod中的上百个节点可以同时处理用户的请求而不会充满单个节点。我们使用BGP和ECMP进行并行处理，并使用弹性散列来避免流量分散。因此，每个边缘节点都运行一个BGP守护进程来宣告虚拟地址到ToR交换机的跳转。作为BGP守护进程，我们正在运行ExaBGP程序并使用单个IPv6会话来宣告两种协议（IPv4 / IPv6）。BGP会话在服务器引导步骤中自动配置。宣告根据服务器的角色而不同，包括每个节点的 /64前缀和许多南北流量的VIP。 /64前缀是专门为容器所设计使用的。每个边缘节点运行大量的容器，并在其他节点和内部服务之间相互通信。

每个边缘节点都使用Redis作为从属副本来获取特定应用程序的上行数据流，因此每个上行数据流都有数千个容器（IPv6）作为跨越节点之间的列表。这些巨大的列表是使用consul-template程序实时生成的。边缘节点具有许多公共IPv4（512）和全球IPv6（512）地址。想知道为什么？为了处理DDoS攻击。我们使用DNS来随机返回 A/AAAA 记录以回应客户端请求。客户将他的域名指向我们命名为 route 的CNAME记录，而这个记录又反过来被我们的名为Razor的客户服务随机返回记录。我们将在后面的帖子中讨论Razor服务。

网络设备

首先，对于ToR交换机，我们决定使用OpenSwitch，这是一个相当年轻的，但是一个有趣和有前途的社区项目。我们在实验室中测试了几个月这个操作系统，甚至为OpenSwitch贡献了一些修改，就像这个补丁。它有一些程序错误，其中大部分最终都修复了，但并不是我们所需要的那么快。所以，我们对有关OpenSwitch的实验推迟了一段时间，并给了Cumulus一个尝试。顺便说一句，我们仍然在实验室中测试OpenSwitch，因为我们计划在不久的将来使用它。

Cumulus允许我们在重新配置如BGP邻居，上行数据流，防火墙，网桥等元素的变化上有一个完全自动化的网络，。例如，如果我们添加一个新节点，Ansible将自动地通过查看LLDP（链路层发现协议）属性而分辨出Chef清单中的更改， 并为特定交换机重新生成网络配置。如果我们要添加一个新的BGP（边界网关协议）上行数据流或防火墙规则，我们只需要创建一个到我们的GitHub仓库的拉取请求，所有的事情都会自动完成，包括检查语法和部署生产中的变更。每个节点都使用Clos拓扑连接到单个10GE的接口。

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

• 定义IPv6地址的格式的不同：有的服务在一个括号内封装IPv6地址（ [2001:dead:beef::1] ），有的则不使用（ 2001:dead:beef::1 ），而最好的是（[2001::dead::beef::1::::1]）,（::ffff:<ipv4>）。
• 与IPv6协议不兼容的库：例如，Sensu监控框架不支持IPv6，所以我们搬到了Prometheus。
• 思科IOS的错误：我们无法使用单个 IPv6 iBGP 会话来处理两个协议，因为思科包括全局链路链接的本地地址作为下一跳。有两个选项可以排除链路本地地址：使用专用AS或回送接口作为更新源。我们的每个机架都移到了私人AS号上。
• MTU问题：比如接收队列的丢失。我们在VMWare ESXi节点上运行了许多内部服务器，因此在实验室启动项目之后，我们在接收端看到了很多的丢包。经过深入调查，我们发现这些丢包是由于比预期（1518 + 22）的大得多的MTU（最大传输单元）数值。默认情况下，NIC（网络接口卡）的MTU大小为1500 加上额外隐含的头部，包括以太网头部，校验和及第一个队列。首先，我尝试改变接收队列的环形缓冲区，但是仅仅在短时间内是足够的，因为它们被装满得太快了，并且vmxnet3的驱动程序不能足够快地清空它们。我登录到ESXi主机，并检查任何客户机的vmxnet3统计信息：# of pkts dropped due to large hdrs:126。有很多的头部丢失了，所以我决定挂起一个 vmxnet3 驱动程序，并检查vmxnet3_rx_error() 来看看在队列中的缓冲区长度有多大。这实在令人失望，因为缓冲区大小为54字节，甚至不及一个IPv4或IPv6数据包的大小。这只是一些VMWare隐含头部。最后，通过调整在ESXi上运行的节点的MTU数值，我们能够在不丢包的情况下处理所有数据包。

得到的教训

• 对于更大的基础设施，IPv6协议更可接受，更具可扩展性。
• 有很多不支持IPv6的工具，服务和库 - 部分或完全不支持。
• IPv6使我们能够比IPv4更精细地定义和控制地址空间。
• IPv6具有更好的性能，即使它的数据包的头部高于IPv4。没有碎片，没有校验和，没有NAT（网络地址转换）。
• IPv6的较少使用是一个缺陷，而不仅仅是一个缺失的功能。
• 我们爱上了IPv6。