本文介绍了如何在商用服务器之间使用纯IPv6通信构建新的高度可扩展的云托管解决方案,我们面临的IPv6协议有哪些问题,以及我们如何解决这些问题以处理超过1000万活跃用户。
在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的接口。
[2001:dead:beef::1]
),有的则不使用( 2001:dead:beef::1
),而最好的是([2001::dead::beef::1::::1]
),(::ffff:<ipv4>
)。 # of pkts dropped due to large hdrs:126
。有很多的头部丢失了,所以我决定挂起一个 vmxnet3
驱动程序,并检查vmxnet3_rx_error()
来看看在队列中的缓冲区长度有多大。这实在令人失望,因为缓冲区大小为54字节,甚至不及一个IPv4或IPv6数据包的大小。这只是一些VMWare隐含头部。最后,通过调整在ESXi上运行的节点的MTU数值,我们能够在不丢包的情况下处理所有数据包。