2016年基于EVPN VXLAN的局域网SDN技术发端以来,在短短的三年来,已经取得了巨大的成功,如果某家网络方案供应商对该方案支持不完善,将会被排挤出主流圈子,而在大型数据中心或园区网络项目中,SDN的需求也逐渐成为必选项。
但是,SDN技术并不是万能的,它的规格和特性也是有一定限制的。
我们先看较为简单的数据中心场景。
让我们回到那张看了无数次的图——分布式任意播网关。
它的硬件实现实际上如下图:
我们注意到,这个图中,有3个子网,每个子网中,任意一个VM都有可能迁移到任意一个交换机下。
这台交换机在封装VXLAN数据包的时候,需要解决两个问题:
- 对于同网段转发,如红色的VM 10.10.10.110向10.10.10.120发送数据包的时候,TOR如何确定,目的主机在哪,将二层以太网数据包封装进入哪个VXLAN隧道呢?
- 对于跨网段转发,如红色的VM 10.10.10.110向10.10.20.110发送数据包的时候,TOR如何确定,目的主机在哪,将三层以太网数据包封装进哪个L3 VNI的三层转发VXLAN隧道呢?
第一个问题的答案是,查找MAC表项。远端主机的MAC表项可以通过EVPN学习得到。这会使得TOR交换机需要学习到,该交换机配置的所有子网内所有的虚拟机的MAC表项。
第二个问题的答案是,查找FIB表项。和第一个问题一样,FIB表项来自EVPN学习。由于虚拟机的特点,难以实现路由表项的合并,FIB表项一定是以主机路由的形式存在。因此,TOR交换机还需要学习该交换机配置的租户内,除自己所在网段之外,其他网段所有的虚拟机的FIB表项。
除了FIB表项以外,交换机内部还有一个表项,叫做NH(Next-Hop),指的是下一跳。每台TOR上的每个子网和每条VXLAN隧道,都需要占用一条该表项。
此外,对于对称IRB的情况,TOR交换机需要学习自己下面所有VM的ARP表项。这个数量不大。
让我们做一个简要的估算:
假设一个中等规模的数据中心,有2000台服务器,虚拟化比例为1:50,共100K虚机。
100K虚机需要每台TOR支持100K以上的MAC表项,100K以上的FIB表项。每台TOR还需要支持约1K的ARP表项。
再让我们看看常见的TOR交换机规格——
目前市面主流的TOR交换机采用Broadcom StrataXGS Trident2 或Trident3芯片实现,它的规格是:
芯片 | MAC | FIB | ARP |
---|---|---|---|
TD3 | 288K | 360K | 272K |
TD2 | 288K | 256K | 208K |
那么,不是可以轻松满足要求吗?
且慢!
BCM StrataXGS在9代以后引入了一个新特性—智能表项技术。它在芯片内部实现了一个UFT(Unified Forwarding Table)表项,可以根据需要分配给MAC/FIB/ARP等资源。我们看到的规格是可达最大值——也就是将UFT全部分配给一个表项的时候的值。如果将UFT均衡分配,MAC/FIB/ARP表项并不能达到最大值。
况且,由于IPv6即将出现,对表项的需求更多。这一定会导致TOR的表项不够用。
因此,我们在规划1K以上服务器的数据中心的时候,需要通过OpenStack的AZ等特性,限定虚拟机迁移的范围,不要让每台TOR下属的服务器,都部署多个租户的业务。