SDN及云计算平台中的网络性能优化

2020-10-26 16:00:03 云杰通信 103

SDN及云计算平台中的网络性能优化

  对于云计算网络的用户来说,他们看不到SDN,但这并不代表他们没有享受到SDN带给他们的好处。现在大多数公有云平台的用户都是自助服务的,他们自己创建虚机,自己创建虚拟网络,自己创建虚拟路由器,自己创建防火墙等,谁在底层支撑着这些动作的顺利执行呢?是SDN架构!没有SDN,就没有这一切!SDN的最高境界就是用户在享受着SDN带来的便利却并没有意识到自己使用了SDN。

  云计算网络目前还处于发展的初级阶段,为了支持多租户网络和支持VM的可移动性,网络虚拟化被广泛使用,包括基于VLan的、基于VxLan和基于GRE的。

  目前绝大多数网络都使用虚拟交换机(vSwitch)作为网络的边缘,最著名的就是Nicira公司发起的开源虚拟交换机项目OVS。之所以vSwitch 被大量用作网络虚拟化的边缘,跟VMware等软件公司的大力推动密不可分,这涉及到他们的利益,也涉及到网络的控制权之争:究竟是数据中心的系统运维团 队控制虚拟网络还是网络运维团队控制虚拟网络?以Cisco为代表的传统硬件厂商极力反对VMware的这种做法,理由包括网络可视化(Network Visibility)以及性能都是大问题,特别是性能问题。

  但反对归反对,很多云计算网络的管理员有了先入为主的思维模式,如果有人让他 们切换到使用物理交换机,他们会普遍提出一堆问题,包括以下几个很典型的:会不会被锁定到特定的厂商身上?物理交换机能有虚拟交换机那么灵活满足各种需求 吗?我能像控制虚拟交换机那样方便地控制物理交换机吗?会不会增加网络成本?

  尽管如此,很多人确实也都同意,使用虚拟交换机,例如OVS,确实有很多性能问题,这是使用物理交换机的方案最吸引人的地方,顺带着还有可扩展性(云管理平台要控制的虚拟网络节点太多)。所以现在问题就变成了:我知道使用物理交换机有这样的好处,但你怎样解决上述顾虑?

  其实OpenStack的Neutron plugin机制特别是最新版(Havana)引入的ML2 plugin已经给出了答案。前面讲过,Neutron向上提供了一套标准的编程接口,这套接口独立于任何虚拟或者物理的交换机。对管理员来说,根本不需 要关心底下用的是谁的交换机,虚拟的还是物理的。对于数据中心系统研发部门的工程师来说,他们可以通过plugin机制引入多种交换机,虚拟的或者物理 的,前提是这些交换机必须能支持Neutron向上提供出那些API来,如果无法支持,自然就不会出现在我的采购列表里面,而支持了之后,如果以后因为某 些原因想换掉了,也很简单,只要换用另外一个交换机的plugin就可以了。这样第一个厂商锁定问题就没有了。特别是Havana版本引入的ML2 plugin机制,允许一个OpenStack域内同时支持多种交换机的plugin。这样只要管理员愿意,甚至都可以有的节点使用虚拟交换机,有的节点 使用物理交换机,而且可以是不同厂家的,唯一的前提就是这些交换机必须支持通用的Neutron API,这是北向接口标准化的好处。

  第二个问题,物理交换机能有虚拟交换机那么灵活满足各种需求吗?

  其实对于特定的场景,这是个很隐蔽的伪命题。一提到灵活性,谁都想要,而且最好是无限灵活。但 如果有人问管理员,我可以满足你的场景中所有的实际需求,但无法提供任意不受约束的灵活性,你要任意灵活的话,需要付出代价,你要不要?我相信绝大多数理 性的管理员都不会要求任意灵活,因为超过需求之外的灵活,是无意义的,而你要为这些无意义的事情付出代价。另外,在有了SDN的机制,交换机可以向上提供 编程接口而不是命令行之后,特别是有了OpenFlow之后,一些交换机特别是为SDN优化过的交换机已可以满足绝大多数甚至全部云计算网络的需求了。退 一步说,不能满足需求的交换机,根据上面第一点,不会进入采购列表。

  第三个问题,我能像控制虚拟交换机那样方便地控制物理交换机吗?在 SDN控制与转发分离的架构下,管理员通过云平台控制的永远都是直接的北向接口,那是与设备无关的。设备的差异性都被底层的实现给屏蔽掉了,如前所述,只 要底层设备能够提供足够的南向接口,通过换不同的plugin,OpenStack就可以控制不同的交换机,包括物理交换机。

  第四个问题, 会不会增加我的网络成本?无论哪种方案,TOR交换机总是需要的。现在并不需要增加新的交换机设备,而只是要让原来的TOR交换机支持SDN方式或者换用 能支持SDN的交换机充当TOR。当然,客户都有保护已有投资的需要,往往不想把现有设备替换掉,这也没关系,前面讲过,OpenStack Neutron ML2的架构允许网络中有的网络节点是虚拟交换机,有的是物理交换机,所以想保护已有投资就变得很简单了,只需要在新增节点上用云平台来控制SDN物理交 换机就行了,原有的节点仍然是控制虚拟交换机,这样就可以让整个网络平滑引入物理交换机作为云平台控制的网络节点。

  前面讲这么多,其实主要是想要说明,如果云计算网络管理员想要从虚拟交换机切换到物理交换机的话,是很容易做到的,不会有什么损失。但接下来网络管理员马上就会问:为什么要切换?有什么好处?答案有多个,主要的两点是网络可视化和网络性能。

  网络可视化的问题相对好分析,容易理解。因为如果在Hypervisor上做了Tunnel封装,报文送到TOR交换机上时,交换机已经看不到用户原始报文了,物理网络就很难对原始报文做统计和应用各种策略。而如果Tunnel封装在TOR上面做,则没有这个问题。

  而对于性能问题大家的看法可能各异,大体可分为三类:第一类是觉得没有什么性能问题;第二类是觉得有,但还可以忍受;第三类是觉得已到了影响业务、无法忍受 的地步了。我相信他们讲的都是他们所看到的事实,为什么结果迥异?我分析过,基本上前面两类,要么是仍然处于试验阶段,还没有大业务的压力,要么是已正式 部署,但网络规模不大或者网络内的业务流量压力不大,当然我也不排除有的人技术能力特别牛,把性能优化到了极致。而第三类,则是已经有很大业务量部署在生 产网络中了,或者是用充分的测试手段模拟过实际的业务。第三类的典型例子就是国内的云服务提供商UCloud,他们有大量实际用户(很多是游戏客户)租用 了他们的公有云网络,业务量很大。和AWS等云计算平台一样,网络处理会占用计算资源,带宽损耗也很大。

  另外一个云服务提供商 99Cloud也曾经做过这样的实验:先是用iPerf进行大流量测试,使用vSwitch带宽大概能到800多MB,后来在iPerf发包的同时,用迅 雷下载模拟实际网络流量,带宽马上降到了500多MB,有高达300MB的带宽被损耗掉了。所以结论就是,虚拟交换机肯定有性能问题,需要优化。就算是对 于那种技术特别牛,能将软件优化做到极致的人,他也无法否认,你再怎么优化,网络处理也要占用计算资源,而按道理网络只是工具,计算才是核心价值。

  前面是定量测试,下面我们来进行一些理论分析。现在服务器的性能这么强劲,还有网卡加速,为什么虚拟交换机还有性能问题?我分析主要有以下几个原因。

  vSwitch做Tunnel加封装和解封装时,报文在内存中的移动和拷贝会影响性能。

  网卡中的TSO是可以对TCP报文进行分片加速的,但一旦vSwitch给报文加了VxLan或者GRE Tunnel,网卡一看不是TCP报文,就不会进行分片加速了。这对性能损耗也比较大。

  软件中的流表查找消耗比较大,特别是在流表数量比较大,TCP短连接比较多的时候。