加入收藏 | 设为首页 | 会员中心 | 我要投稿 应用网_阳江站长网 (https://www.0662zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长资讯 > 传媒 > 正文

Tungsten Fabric如何支撑大规模云平台

发布时间:2020-02-25 23:06:08 所属栏目:传媒 来源:业界供稿
导读:至顶网网络与安全频道 02月24日 综合消息: MTU的值设置多少合适呢?现在最佳实践是设置到9000。 其实OpenFlow只是一个概念,从这几年SDN的发展来看,它并没有成为一个事实的标准。 大规模云平台对SDN的要求,第一是网络基础架构要可扩展,第二是控制器可扩展,

Tungsten Fabric用到的数据库,都是最近8年才有的,比如分布式数据库的Cassandra、Zoo Keeper、RabbitMQ,在架构上是高可用、可扩展的,具体能扩展到多大的量,还是要看代码实现。反过来看Neutron,本质就是一个数据库,记录了所有的信息,把所有的流表下发下去。

Tungsten Fabric如何支撑大规模云平台

Tungsten Fabric的数据平面主要是通过vRouter来做转发,vRouter agent在user namespace的进程,安排控制器基于XMPP连接拿到一些信息,再下发到kernel的转发平面。这里提供了二层隔离和三层隔离的功能,如果说同一个网络的虚拟机,接在同一个vRouter下面,双方的通信就在这里完成。不同租户的网络虚拟机,接了不同的VRF、Routing instance,也是不能通信的。

vRouter内置了很多网络功能,比如DNS。Tungsten Fabric的DNS会根据主机的DNS配置来解析,如果遇到问题,可以检查一下主机的DNS有没有问题。DHCP应答也在这里,Neutron就不一样,专门有一个DHCP agent跑在一个节点上,OVS在大规模情况下,如果接了超过1500个接口,基本上就会出现丢包,并且经常出问题。

Security Group在OVS的实现是通过和linux bridge关联的iptables实现的,而在vRouter就是通过内置的ACL功能实现。Network Policy就是一个分布式的防火墙。Floating IP也是在vRouter做了一个NAT出去。

这里多谈一下Link-Local,它的场景是什么?作为一个云服务商,要向客户提供NTP服务、ATP、YUM源、等公共服务。怎么让虚拟机在虚拟网络内访问到一个公共服务呢?一种方式是把这些网络的路由打通,因为需要一个VTEP出口,通过cloud gateway把公共路由导进去,这样带来一个问题,所有ATP流量、下载流量都要通过cloud gateway,流量会跟大。Tungsten Fabric提供一个Link-Local的模式,就是一个169.254的地址,在网络标准里只有一跳。在OpenStack虚拟机或AWS虚拟机里面,metadata服务就是通过169.254提供的。本机没有这个路由,到网关上对地址做一层NAT,本机的NAT就会访问到配置的Link-Local映射,继而访问到内部的服务。

在没有增强的前提下,实测Neutron的OVS VXLAN的性能(只做MTU的优化),最多达到两个千兆的性能。而vRouter在不做任何优化的前提下,能达到七、八千兆的性能。当然也可以利用DPDK、Smart NIC来做优化,或者利用SR-IOV的透传功能。

Tungsten Fabric如何支撑大规模云平台

再来看看Tungsten Fabric的Packet交互。无论是同网段还是不同网段,虚拟机之间的交互,都是在vRouter层面转发的,不会经过一个集中式的gateway。所以在虚拟机之间的数据交互层面,是没有单点的。

Tungsten Fabric如何支撑大规模云平台

另外一个比较重要的场景是SNAT。在OpenStack里面,如果虚拟机接了一个vRouter,可以通过vRouter的SNAT功能去访问external的网段。Tungsten Fabric本身其实不提供SNAT,但也实现了SNAT功能,通过NS router(跑在计算节点的一个IP tables)做一个SNAT的转发,如果虚拟机要访问一个非本网关的网络,先到gateway,转发后,再通过vRouter连接external的网络。这里NS router的创建,需要OpenStack nova的scheduler来配合。

对于每一个网络,都会有一个router去做转发,如果量太大,瓶颈可能就在NS router这里,但不会影响其它的网络。

Tungsten Fabric如何支撑大规模云平台

只要不在云内,都可以叫外网,要出外网有两种方式:第一种是Floating IP,在vRouter做了一个NAT,把NAT后的IP通过MPLS over GRE的隧道,发布到Cloud Gateway的某个VRF里面,和外网通信。

Tungsten Fabric如何支撑大规模云平台

第二种外部互联的场景,假如要提供一个云服务,可以针对不同的运营商做不同的flouting IP,如果做L3 VPN或L2 VPN的专线接入服务,可以通过cloud gateway接入到不同的MPLS网络,再把虚拟网络路由到相应的VRF,整个就都连通了。这也是Tungsten Fabric强大的地方,MPLS VPN是和传统的网络天然互联互通的。

Tungsten Fabric如何支撑大规模云平台

跨集群的互联,或者叫多云互联,主要有两种模式。

第一种是基于控制器之间的互联,把VPN、网络和接口的信息,通过控制器之间建立EBGP连接来传输,这种方案叫Federation。

两边的vRouter只要三层可达就可以,比如一边的B1要访问另一边的B3,两边是不同的控制器和VPN,MPLS VPN有个route target,一边export一边import,路由表看到另一边的路由,进行路由信息交互,从而建立二层或者三层连接。Federation的方案是在控制器层面实现的,比较适合于同一个地域,同一个数据中心,有比较近的连接的情况。

Tungsten Fabric如何支撑大规模云平台

第二种模式是通过cloud gateway之间的互联,把网络的不同VRF,在cloud gateway之间建立EBGP邻居,手动配置去import或export不同的RT,实现跨云的连接。需要注意的是,两边是不同的集群,IP地址管理不一样的,分配地址的时候,要避免IP地址的重叠。

Tungsten Fabric如何支撑大规模云平台

最后,和Neutron OVS进行对标的话,Tungsten Fabric可以说是完胜的。

基础网络方面,Tungsten Fabric可以扩展,Neutron OVS目前只能用二层网络,无论集中式还是分布式,floating IP下沉到计算节点这一层,目前的组件里都没有成熟的BGP方案,能够把floating IP发布到边界网关,OVS DVR和边界网关只能通过二层连接。

对比架构方面,Tungsten Fabric是可扩展的,3个节点性能不够,可以扩展到5个节点。Neutron OVS虽然是一个高可用架构,通过MySQL集群实现数据库高可用,通过K8s实现API高可用,但计算逻辑不是分布式的,严重依赖RabbitMQ。如果使用DVR模式,每个计算节点要部署四个agent,带来更多的topic,对RabbitMQ的性能是很大的挑战,只要出现一个RabbitMQ宕机或网络抖动,会马上执行集群恢复机制,导致RabbitMQ很快死掉。

(编辑:应用网_阳江站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读