基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系之大二层网络


基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系解决方案目前是没有在生产环境中进行实施的,因为这还是一个正在研发中的解决方案,之所以分享出来是想把它做成一个解决方案开源项目,供大家参考和讨论,也请大家提出自己的想法和意见以便更好的完善这一解决方案。

大二层简介

在TCP/IP协议栈中,标准的将IP协议分为七层,物理层、数据链路层、网络层、传输层、会话层、表示层、应用层,数据链路层在七层模型中处于第二层,一般被称为二层。而所谓的大二层网络其实就是大范围二层网络的简称,我查找了很多资料发现这种解释还是比较准确的。当然相对应的也有大三层网络,但是在新一代的网络架构中,随着核心交换机性能的提高和承载能力的提高,简化网络模型是一个新的趋势,也就是所说的扁平化网络,去掉传统网络模型中的汇聚层。

因此大二层网络在运营商、互联网厂商得到大量的应用,我们公司有一个云工程事业部主要做面向运营商和互联网厂商的项目,其中上海电信项目现在已经逐步的在使用思科的ACI来做自己的大二层网络,我也和我们的云工程事业部的同事进行了沟通和交流。

大二层被提出和逐步得到应用,就会遇到一些不可避免的问题,那就是如何在大二层网络解决二层网络与生俱来的广播风暴和环路问题。利用传统的STP(生成树协议)和Vlan技术很显然已经无法解决这些问题了,为了解决这些必须解决的问题一批技术被发明创造出来。如:网络设备虚拟化技术(堆叠技术)、L2 over L3、Overlay(这是今天晚上分享的重点),接下来就和大家先聊聊这三种技术,诠释一下容灾体系在大二层网络的技术选型思路。

大二层技术实现

网络设备虚拟化技术(堆叠):这个技术是目前比较常见的技术模式,不管是不是大二层网络,大多被用来做网络的冗余和数据链路的冗余。这种技术说白了就是将多台网络设备虚拟成一台大的网络设备,网络设备之间的南北向接口都是双上联的,结合数据链路技术可以完美的将物理上多路径、多设备冗余的设备和链路虚拟成一个逻辑上线性网络拓扑,那么我们刚刚谈到的二层网络的环路问题就没有了,因为在逻辑上根本就不存在任何的环路。这就是物理上冗余、逻辑上单一的思想,既保证了网络的冗余高可用又可以很好的解决环路问题,环路的问题解决了,所谓的广播风暴也就不复存在了。

L2 over L3:大家肯定都是知道所谓的广播风暴只会存在于二层网络中,在三层网络层面是没有任何的广播风暴的,原因就是二层的数据转发采用了简单傻瓜式的MAC地址转发,而在三层的网络中数据的转发是采用了智能的路由来转发的。之所以当初在设计二层网络时采用简单傻瓜式的MAC地址转发取决于很多的历史因素,如网络设备的性能、实际的需求等。那么在如今面临大二层网络的环路问题的时候,自然的想到了三层路由数据转发的模式,就是能不能在二层也使用这个种智能的基于路由的数据转发模式,这也是L2 over L3的核心思想。但是这样做的话问题就出现了,那就是当前的TCP/IP协议在二层是不支持拓扑发现的,如果要实现上述思想的话必须要进行二层协议的改造。目前被IETF接受的协议是TRILL协议,这个协议是在原始以太帧外面封装一下TRILL帧,然后在正常的封装以太网帧,(这里和Overlay中的Vxlan技术思路上是比较一致的),在TRILL帧头中有一个Nickname来进行标示以便被TRILL交换机识别转发以及计算转发路径。

Overlay技术:Overlay技术其实就是用隧道或者协议封装的方式,将二层的数据帧进行封装形成逻辑上的隧道或者胶囊,Overlay技术中数据的传输技术不用修改现有的网络模式,只需要在两个端点加上封装和解封装的网络设备即可。我们所说的逻辑上的隧道其实就是GRE技术,而逻辑上的胶囊就是Vxlan技术。这个两种技术是目前Overlay技术体系中比较常用的,GRE技术是点对点的隧道技术,这种技术实现起来比较简单,就相当于两台主机间的网线直连,在少量的需要进行Overlay技术通信的场景来说还是可以介绍的,如CISCO就提出了基于GRE的同城双活数据中心解决方案,对于大量的相互之间通信的场景就会遇到传统网络没有交换机的尴尬。因此就提出了可以通过交换机进行数据交换的技术,这里面包括Vxlan、NVGRE等。

在上次的分享中,我也详细的介绍了关于Vxlan的发展历史和相应的技术实现原理,这次在这里就不一一的介绍了。总的来讲,Vxlan采用的是Mac in UDP的方式,这是对数据帧进行封装,我形象的把这个称为“胶囊”。从源主机发出的数据包会在VTEP中进行VXLAN帧头的封装(这个和TRILL技术中的nickname是一样的,只不过后面的转发机制是不一样的),在完成封装后会被自动的封装在UDP数据包中,然后就是使用在最外层使用当前网络的IP或者MAC作为外层的封装,之后就在当前的网络中进行正常的传输。这其实就是将需要传输的以太网数据帧当成被传输的数据,封装在UDP中进行数据的传输。这样在目的端的VTEP设备会类似于解析TCP/IP数据包一样,逐层的解封装,不过在解析到VXLAN header时,会根据类似VLAN的转发规则一样进行数据的转发,这样整个的数据转发都是在控制平面的,都是进行有规则的转发。

Vxlan技术在三地三中心体系中的应用


如上图,我画了一个简单的网络示意图,整个部署组网是依据思科的ACI解决方案来进行设计的。图中的网络设备只是用来示意,相关的数量可能存在一定的偏差。在思科ACI体系中SPIN相当于一个总的Vxlan ARP的查询服务器和数据转发的核心交换机,在leaf层面的交换机就是一个个VETP,数据包的封装在这里进行,在进行封装前会询问相应VXLAN ID对应的承载网络的信息,之后进行相应的外层目的IP/MAC的封装。在完成封装后,就会发给相对应的SPINE,SPINE会根据已有的转发规则进行数据的转发,在数据包到达目的VTEP后进行解封装的过程。在这一过程中,如果有新的或者未知的VXLAN ID相对应的信息,SPINE会在所有的SPINE之前进行查询,以避免进行大范围的ARP广播。APIC是思科ACI的控制器,可以根据实际的需求配置和下发不同的策略。

在这种场景下,我们可以很容易的理解下面这张图。在这张图中,所有的容器其实是连接在同一个巨大的逻辑交换机上的,根据二层的知识我们知道在同一个Vxlan内的容器是可以带IP地址迁移和变动的,因为对于这个巨大的交换机来说就是在不同的端口之间进行迁移而已。这是实现容器在三个数据中心之间进行带IP飘移的一个很重要的前提条件。

三地三中心容灾体系中Vxlan组网设计

在Vxlan的组网设计中,上图也是比较经典的组网设计模型。在这个模型中基础网络骨干和叶子两层架构即spine-leaf架构,spine层和Leaf之间纯IP的网络,通过IP的多链路负载均衡,可以实现低收敛比甚至无阻塞。虽然大二层网络实现了一个统一的巨大的二层交换网络,但是在实际的生产应用中还是需要三层交换进行业务服务的访问的,这就是涉及到网关部署的问题。

网关部署和传统的网络架构是一样的,有三种不同的部署模式,一种模式是网关设备独立部署,做到基础网络和网关相分离,基础网络只做二层的数据转发,网关负责处理不同子网和交换设备南北向的流量。另外一种模式是网关部署在SPINE交换机上,这种模式下其实就是将SPINE当成传统网络中的三层交换机,既可以进行二层的数据交换也可以进行三层的路由交换。最后一种是将网关部署在leafe上,这样做的目的是可以减少网关流量的路径,可以最快的进行三层的路由交换。

三种模式分别都有不同的适用场景,第一种模式很显然是将路由交换和二层数据转发分离,这种模式比较适合用于大量进行同vxlan内的数据交换业务,第二种模式其实就是省钱模式,二层三层用同一个套网络设备,这种模式一般适用于一些中小型数据中。第三种模式主要是为了减少路由交换的流量路径,当需要进行跨vxlan域的交换时直接可以就近的在leafe层完成路由交换,这种模式比较使用于东西向流量比较大的场景中。在本次方案中,我选择的是一种网关独立部署模式,因为在三地三中心的场景下南北向流量和东西向流量都会有比较大的压力,对SPINE的查询和转发压力也比较大的,因此采用网关独立部署的模式。如下图所示:

在VTEP实现层面可以将VTEP部署在leaf层交换机也可以使用OVS来实现,不过在本次方案我使用的是leaf层交换机作为VTEP,这做的目的主要是考虑到性能和稳定性的问题。在网络的控制平面,使用思科的ACI解决方案中的APIC作为整个大二层网络的控制平面,这种集中式的网络控制平面模式可以使控制器具备全局的网络感知能力,能够更全面的管理和控制整个网络。

Q&A

Q:请教下Overlay性能和稳定性如何,适合大规模生产应用吗?你是全部的Overlay吗?
A:我接触的思科ACI是可以实现在大规模生产应用的,在整个方案中使用的全部是Overlay网络。

Q:请问,你所说的Swarm发布的网卡,是物理网卡还是虚拟网卡?
A:不是Swarm发布的,是Docker1.9的一个新的网卡特性,在Docker 里面使用docker network -help可以看到。

Q:请问Overlay使用的是物理交换机还是虚拟交换机?
A:在本方案中使用的是物理交换机,VTEP是部署在leaf层的物理交换机上的。当然也可以使用OVS来作为VTEP,不过这样在性能和稳定性不如物理交换机。

Q:请问通过Docker Network创建的网桥怎样可以让OVS发现并控制?
A:当Docker Network为容器创建新的网卡接口后,通过脚本自动的挂载到OVS的网桥上。对网络的管理是是在更宏观的层面进行的,换句话说实在调度框架层面进行的,调度框架会根据自己的需求将需要的网络配置发给APIC,APIC会下发相应的网络配置策略。

 
来源:Docker


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

登录后才可以评论

SDNLAB君 发表于16-05-09
0