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

  • 来源: 上海热线   2020-02-24/19:09 访问量:
  • Leaf就是架顶式交换机,下面是子网,不同机架用不同子网,上层通过三层网关路由做通信,最主要的就是Leaf Spine之间三层怎么交互。瞻博网络有个文档介绍IP CLOS的白皮书,对OSPF、ISIS、BGP进行了控制平面上的对比,最佳建议是用eBGP来做交互。

    Tungsten Fabric的本质是基于MPLS VPN的SDN。原来的VPN是解决多个site之间的互联,控制平面是BGP协议。到了数据中心里面,云之间的互联,一个物理机可以看做一个site,不同物理机之间借助VPN建立不同的隧道来打通,这就是Tungsten Fabric的本质。不同之处在于控制平面,Tungsten Fabric用的是集中式的控制器并通过XMPP协议控制vRouter的路由表。

    简单看一下Tungsten Fabric的功能架构,在多云支持上,包括VMware、OpenStack容器、BMS;网络功能上,二层网络、三层网络、DHCP、DNS、QoS、防火墙、LB等都是支持的。

    在部署的时候,控制器主要分为两种节点,一种是Analytics Cluster分析节点,主要做流的可视化。另外一种Controller节点用来控制网络,分为Configuration和Control Node,前者提供API,对接Neutron等云管平台,API通过创建一个pod,在Configuration上记录数据库,转换成相应的IF-MAP,控制器通过XMPP命令在vRouter上创建相应的接口,再把接口信息传给不同的vRouter或外部网关及硬件设备,控制器核心协议是BGP协议。

    控制器在整个Tungsten Fabric里就是一个router reflector,把所有的二层接口、MAC接口信息,三层路由信息全部存在这里,分发到不同的vRouter上面。对于云内的vRouter,用XMPP推送,对于云外的Gateway等,通过BGP推送。

    其中,NETCONF协议不是用来推送路由信息的,主要用于和网络硬件设备的一些配置下发。比如Tungsten Fabric中增加一个BMS服务器接入到Tungsten Fabric管理的虚拟网络,Tungsten Fabric中的Device Manager会通过NETCONF将VLAN接口的配置和下发到TOR交换机,通过NETCONF建立接口。然后Tungsten Fabric控制器再通过OVSDB协议或EVPN-VXLAN协议去配置相应的VLAN-VXLAN的桥接网关。如果需要把虚拟网络扩展到Gateway,NETCONF也会帮助创建相应的Routing instance配置。路由层面的交换信息,还是通过BGP来实现。

    TF中文社区3月Meetup活动,将聚焦Tungsten Fabric与K8s的集成,由重量级嘉宾分享Tungsten Fabric与K8s的部署和实践,详细演示操作过程,并解答关于Tungsten Fabric和K8s的一切问题。关注“TF中文社区”公众号,后台点击“会议活动-Meetup”领取。

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

    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的Packet交互。无论是同网段还是不同网段,虚拟机之间的交互,都是在vRouter层面转发的,不会经过一个集中式的gateway。所以在虚拟机之间的数据交互层面,是没有单点的。

    另外一个比较重要的场景是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这里,但不会影响其它的网络。

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

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

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

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

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

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

    最后,和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很快死掉。

    另外,在转发平面上,Open vSwitch的性能没有vRouter好;Tungsten Fabric的网络功能更丰富,而Neutron的Octavia等原生LBaaS组件也有待成熟;多云互联方面Tungsten Fabric基于MPLS VPN;和网络设备的交互方面,Neutron只有ironic的networking generic switc driver,Tungsten Fabric支持BGP、NETCONF、EVPN-VXLAN等,基于标准的协议,涵盖了瞻博网络、思科、华为、锐捷等厂商的设备。

    今天就先分享到这里。谢谢大家!

    本次演讲及TF中文社区“2020第一次Meetup”活动资料,请在“TF中文社区”公众号后台点击“会议活动-Meetup”领取。

    ---------------------------------------------------------

    免责声明:

    1.本文援引自互联网,旨在传递更多网络信息,仅代表作者本人观点,与本网站无关。

    2.本文仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。

    上一页 1 2下一页

    评论 {{userinfo.comments}}

    {{money}}

    {{question.question}}

    A {{question.A}}
    B {{question.B}}
    C {{question.C}}
    D {{question.D}}
    提交

    驱动号 更多