【嘉宾校正】马绍文:云计算需要什么样的SDN控制器

我今天的演讲题目是云计算需要什么样的SDN控制器

从这张独角兽公司($1B)发展图谱上看到,从2011到2014,初创公司很难达到独角兽的标准。但是2014年开始到今天,两年时间云计算 ,SDN风起云涌,大量采用,更多公司可以借助云平台很快实现财富积累,创新速度更快。举一个简单的例子,三个月之前日本公司收发布了新的精灵宝贝游戏,不需要任何的新设备,采用云平台,这个游戏很快在全球被1亿用户下载,同时公司马上能从用户收到更多钱。这在没有云平台的时代是无法想象的。

传统Ops运营模式下,运营商/客户采购路由器、交换机,防火墙,一次配置之后,可能半年到一年不会改变。但是新的云运营模式,需要全网转去DevOps模式才能适应云计算。

DevOps能帮助客户在物理网络之上创建一个虚拟化的网络。App能够更快的部署在全球网络上,更灵活的做网络的变更。怎么去维护管理这个虚拟化的网络,需要一个SDN控制器帮忙。

从JUNIPER的角度来看,传统我们关注五大产品线,CPE/Access/Edge/Core/DC。 从2016年开始我们的核心和边缘路由器赢得了国际上很多Tier1/Tier2运营商和OTT客户。比如6个顶级OTT客户中的五个(Google/Facebook/Twitter/Amazon/Apple)均采用了我们的最新核心路由器PTX。关于传统物理设备Underlay的管理。我们提供了一个广域网控制器北极星(North Star)去管它。对于在Underlay网络之上的Overlay,我们看来有三大区域会采用NFV做虚拟化。 第一区域在CPE侧,现在非常热门的一个话题SDWAN,传统的设备用X86的CPU 的小型服务器替代传统多个DPI/FW/Router设备,单一设备通过云控制器来管理,实现企业CPE设备的转型和创新。SDWAN全球大概有30多家初创公司。 第二区域会在BNG/PE侧有很多虚拟化的需求,比如说我做优化Video Cache/DPI等等。 在DC里面虚拟化的功能就更多了比如vEPC/vFW等等。 怎么管理虚拟化网络。Juniper推出了Contrail SDN控制器。 现在网路中有一个端到端的物理underlay我们采用North Star,对于Overlay网络控制我们采用Contrail. 所以现在的网络管理分了两层,每一层都有自己的SDN 控制器把它管理起来。

很多人问两个SDN控制器怎么搞?可以看一下最成功的SDN公司Google。关于Google的网络架构可以参考著名的三篇论文。Google在2006年开始引入了很多网络创新。很多创新是基于交换机架构的创新。这10年间Google引入了三个SDN Controller。在2010年引入了主机TCP/IP栈BwE流量控制器,在2011年引入B4做广域网控制。在2014年引入仙女座(Andromeda)做虚拟化控制器。其中对于广域网SDWAN 的控制相当于Juniper的North Star SDN控制器。对于云计算虚拟化的Andromeda控制器就相当于我们Juniper的Contrail Cloud云计算SDN控制器。 我们没有做,也没有必要去做控制TCP协议栈的控制器。因为我们无法控制用户的主机

我们把业界常见的SDN控制器大致分为三类,可能不是很准确,很多控制器有新的进展:
1. 关注路由器WAN的控制器
a. 控制100+路由器节点
b. 采用标准路由协议BGP/PCEP/Segment Routing etc
2. 关注数据中心交换机的控制器
a. 控制1000+路由器节点
b. 在两个TOR交换机之间创建VTEP tunnel
c. 采用Openflow等方式
3. 关注Cloud的控制器
a. 控制10,000+虚拟路由器/虚拟交换机,vRouter/vSwitch
b. 不再主要管理路由器/交换机。在hypervisor层面管控(vRouter/OVS)
c. 采用BGP/XMPP/OVSDB,创建vPE EVPN/L3VPN网络

针对这三种SDN控制器,我们先讲讲最重要的Cloud控制器


Google采用仙女座(Andromeda)控制器来进行网络虚拟化,管理虚机和Docker。在数据中心的每一个Server上创建一个虚拟的VMM(虚机管理系统),通过GRE来虚拟多个不同的VPN,把VM/Dockers映射到不同的虚拟网络。 每个VMM可以提供Load balance/DDos/ACL/VPN能力。

Juniper的Contrail控制器也实现类似功能。

Contrail基本的设计思想是把每个数据中心Server的Hypervisor里面虚拟化出来一个vRouter

多个VM/Docker会连接到这个vRouter的不同的Tenent VRF。同时vRouter之间采用GRE/UDP/VXLAN做外层隧道, 采用内层标签来标识不同的VRF。 vRouter相当于传统L3VPN和EVPN的一个vPE功能。vPE用户侧不再接入CE设备,而是为VM/Docker提供连接性。
简单的来讲,如果客户有一万台Server,部署了Contrail之后,
1.Contrail控制器相当于传统的路由器控制平面,承担计算Overlay拓扑,数据通道Tunnel建立等工作。相当于传统VPN的RR。
2.数据中心的Leaf/Spine交换机提供IP Clos无阻塞交换,相当于一个虚拟的交换矩阵,为控制器和vRouter之间提供背板交换。
3.vRouter/vSwitch跟controller建立控制关系,vRouter之间建立数据tunnel。每个vRouter相当于传统路由器的一个板卡。
4.部署了Contrail之后,一万台Server的vRouter变成了一个大的虚拟化的路由器(Network as a Router), 为数万的VM/Docker提供多租户隔离的类似VPN网络的连通性。

有了这个Contrail Cloud SDN控制器下的数据中心网络。客户通过Openstack/Kubernets的GUI创建的VM/Docker的IP地址,RT/RD信息网络VRF信息被vRouter传送回Contrail控制器,并且分发到其他的所有vRouter,实现数据中心之内的互联。并且Contrail可以通过BGP协议发送更新到MX DC GW路由器,刚刚创建的VM/Docker马上会被客户从外界Internet访问。实现大规模数据中心的云化部署。

有了Contrail Cloud SDN控制器,也非常容易做NFV的业务编排(Services Chaining),我们给每个VNF的接口分配一个唯一的MPLS标签。如果要访问不同的物理或者虚拟化的VNF,只要找到对端的IP地址,并且携带这个MPLS标签,数据流量就会很容易的按照业务编排在不同的VM和VNF之间实现业务链的编排。

Contrail有很多业务的创新,比如最早支持Kubernets, BGPasService等等。 还拿Google举个例子。Google网络中大部分MicroService是用Container部署的,很少有VM的应用。Google在一片文章里提到,每个用户开始一个浏览器访问google 搜索,Google的后台会有70个micro-service。每个星期在Google全球数据中心里,大概有2 Billion的Container创建和销毁。Google开发了Kubernets去部署全球的Container。但是Kubernets的开发者偏向APP应用层,在网络层面使用了简单的Proxy来做Container的互联。不太适用于大规模的Container部署。

Contrail在2014年支持Kubernets,适用我们自己的Contrail vRouter替代Kubernets里面的Proxy,实现完整的VPN功能。我们的很多客户已经采用了Kubernets+Contrail来实现,比如LITHIUM用来实现SaaS,提供VM/Container/AWS Hybrid Cloud之间的资源自动调配。相关视频客户已经在2015年7月Post在Youtube上了。还有另一个客户TCP Cloud也采用Kubernets+Contrail实现Smart City/IOT。去检测停车场/街灯的各类信息(temp, CO2, humidity, doppler )并且连接标准树莓Pi的IOT GW.

运营商转型的一个重点是要实现Telco Cloud,运营商的云化。


传统运营商建网思路是以连接性为目的,买路由器,传输设备,提供管道,连通性。网络架构基本不具备智能。

为了应对新业务的出现,很多业界Tier1 SP转变思路实现以超小(Micro),Ultra Low Latency数据中心为网络建设的重点。比如为应对VR/Health Care/自动驾驶等业务的低延时,大数据量应用(自动驾驶汽车需要视频识别,可能每秒钟产生1Gbps的流量),必须要建设全分布式,超小型数据中心更加靠近终端用户。比如在北京的很多街道要部署微小的数据中心以知道自动驾驶汽车。

Telco Cloud架构,把分布式的端局(CO)变成数据中心,可以支持虚拟化,网络分片等应用。同时运营商天然有足够的分布式端局CO资源提供Telco Cloud的机房设施。把传统端局改造为大中小型数据中心,把网络引入智能,能够使得运营商提供跟OTT一样的甚至更好服务IOT/5G的最新应用的云平台。
Telco Cloud的一个重点就是如何管理全分布式的数据中心,很多Tier1 US/EMEA客户采用我们Juniper的Contrail来部署VNF实现网络虚拟化。比如Telco Cloud里面实现vPGW,vSGW,vFW,vOLT等等。

Juniper Contrail客户大致分三类,其中运营商Telco Cloud的应用比如AT&T, DT等等,还有NTT/Orange采用Juniper的SDWAN/vCPE解决方案。

Controller Less EVPN/VXLAN 云部署


很多企业用户网络规模不大,业务模式简单,不太想采用复杂的网络SDN控制器,但是还需要进行Cloud部署。对于这类需求客户,Juniper提供了另外一种简化版本的无控制器(Controller Less)的Cloud部署方式。具体思路如下图:

对于一个普通的采用EVPN/VXLAN的数据中心,
1.可以预先用Juniper的OpenClos或者Network Director进行Leaf/Spine交换机的EVPN/VXLAN的PE-PE部分自动部署。利用Ansible实现TOR交换机的EVPN BGP部分自动配置。
2.Juniper扩展了Openstack的ML2 Neutron Plugin,采用Openstack的GUI去配置VM/Container,网络等等
3.插件(plugin)提供EVPN/VXLAN的PE-CE侧的配置。每当部署新的VM/Container, Juniper EVPN/VXLAN插件能够在TOR交换机上自动部署EVI/BD并且携带MAC和IP地址的绑定关系。
4.TOR交换机通过普通的BGP EVPN来传递MAC地址到整个数据中心的相同租户网络。
这种新的Openstack EVPN/VXLAN插件在今年9月份已经支持,同时我们还提供Security GW相应的Neutron 插件。我们有一些客户已经采用了这种方式来部署轻量级的云应用。

关于WAN SDN


时间关系我们不能介绍更多细节,有机会我们单独来讲讲WAN SDN, 采用BGP-LU,Segment Routing等协议实现SDN 2.0. 主要思想是把网络边缘智能化选路,网络核心保持最简无状态Stateless,提供超大规模APP链路优化需求。

还是回头说说Google B4 WAN SDN控制器,根据公开资料,B4在2011年开始做了很多调整来实现广域网流量调度。比如B4的转发节点采用Openflow+定制化ISIS Firepath路由协议指导转发。流量工程需要控制主机Host的流量调度,完全没有RSVP-TE隧道。采用集中Global流量调度控制器等等。总之B4控制器无法适用除了Google之外的其他网络。无法帮助运营商和企业客户进行广域网流量调度。

为了在现有运营商网络架构上,兼容各厂家设备,Juniper推出了North Star(北极星)广域网控制器。完全采用标准BGP/PECP/Segment Routing和Telemetry协议来实现类似B4的网络优化效果。
这里想重点强调一下Telemetry和Analytic。SDN控制器的两个主要的功能,首先能够下发指令,其次需要感知网络状态。传统的设备采用SNMP感知网络流量情况,可能需要5分钟时间才能采集到相应数据。采用芯片级别的Telemetry可以提供10ms间隔的流化数据。有了相应网络状态数据,通过机器学习,人工智能来检测网络异常变化,并提供应对措施。

总结


今天我介绍是业界最成功的SDN企业Google,采用三个不同的SDN控制器来进行云计算部署,并且提供广域网优化。 但是Google有强大的研发实力,可以定制化云主机VMM管理软件,定制化DCI交换机,定制化路由协议。但是Google的云计算网络部分不适用于第二家公司,也不适用于运营商和企业客户。我们Juniper作为厂商来讲,不光能够提供路由器/交换机/安全产品,同时我们提供两个SDN控制器来帮助管理Overlay(Contrail)和Underlay(North Star)网络。

对于运营商/OTT/企业用户来讲,采用我们标准化的Cloud SDN控制器,可以很容易的部署私有云/公有云/混合云等各类应用,并且帮助客户实现Telco cloud的网络转型。我们在全球有很多成功案例。希望能帮助更多中国客户 。
这就是我今天的演讲,非常感谢大家!


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18197.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-12-08
2