转载

DockOne微信分享（五十一）：基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系

【编者的话】以传统的两地三中心容灾体系为基础，将Docker（应用引擎）、Ceph（统一存储）、Mesos（分布式资源调度）这三大主流技术栈，与大二层网络，光纤传输技术结合在一起，实现新一代的三地三中心容灾体系。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办，来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享，4月7日之前购票只需338元，欢迎感兴趣的同学抢购。

容灾体系架构构想

在设计这个容灾体系架构的时候，我将传统的两地三中心的概念进行了升级，从上图中大家可以看出，其实是一个三地三中心三活的架构。如果不从经济角度考虑，需要在三地之间架设或者租用运营商的裸光纤。在超过3KM以外的距离多模光纤已经存在比较大的损耗，因此可以采用单模裸光纤，将光束以极小的角度打入光纤中，进行长距离高质量的传输。

在分布式资源调度层，Mesos只是作为分布式资源调度，应用的调度交给各种执行框架去做，包括对于如何做到应用的多活高可用，我觉得在这个架构中，只是提供了应用多活的链路、存储、资源调度多活，对于各种应用多活架构都是开放的，都可以在Schedule兼容的情况下进行部署。

最后在应用负载这一块，我选择了负载轮询的方式。其实说实话在这个层面我没有想的特别明白，我所讲的负载轮询是事务处理的负载轮询，就是访问接入是在数据中心A1 A2 A3的，当进行事务操作的时候以一组长连接为颗粒度进行负载轮询。这样设计的目的，是最大程度的避免事务的冲突和数据的瞬时海量并发，当然对于数据并发其实可以使用队列数据库来解决，但是我觉得从底层的机制上需要这种负载轮询的机制来解决。

容灾体系技术框架

DockOne微信分享（五十一）：基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系

如之前所说，在设计这个容灾体系的时候，我将两地三中心的概念进行了提升，变成了三地三中心。这样做的原因是当前的光纤传输技术的提升，目前在240KM内是单模裸光纤可以达到10Gb/s的带宽，这已经达到了正常数据中心在汇聚层甚至是核心层设计的带宽。因此，通过DMDW收发设备的转换，可以完全实现在物理层的传输速度上跨地域进行数据的无差别传输。

在统一存储层面，在三个数据中心中分别设立了OSD群和monitor群，在现有体系构想下每个数据中的OSD群包含n个OSD节点，3个monitor节点，这样从三个中心的角度来看，就存在三个OSD群域和9个基于PAXOS服务选举的monitor服务集群.考虑到三中心的的OSD数量规模以及在进行CRUSH算法的数据分布式中的效率，建议设置6副本的模式，即在每个数据中心都存在2个同一个数据的副本。为了保证写操作的效率，可以将最小副本数设置2,这样只要完成2副本的写操作就会返回写成功。这样通过CRUS算法规则的设置，可以保证6副本会平均分布在三个数据中心，在完成最小副本数据的写操作时候也可以保证是写在两个不同的数据中心的。

关于CRUSH算法规则的设置可以看 CURSH算法规则。

同样在Mesos这一层面也是分为slave群和master群，对于master群来说还是建议每个数据中心采用3个master节点，这样一共9个master节点通过ZooKeeper服务选举来实现多节点的高可用，slave节点可以当成一个统一的集群池，不需要区分不同的数据中心，因为这一层面的高可用是通过PaaS执行框架来实现的，在Mesos层没有必要去考虑，Mesos就是作为最底层的通用的资源调度平台。

在Docker层，容器镜像作为应用运行的实例，被PaaS执行框架通过Mesos进行调度，在跨数据中心的体系下，需要解决镜像仓库数据一致性和网络的问题。对于镜像仓库数据一致性，我认为有两个方案可以采取，一个是在三个数据中心部署三个镜像仓库，但是镜像仓库对外提供服务可以通过服务代理来进行，也可以继续使用ZooKeeper进行服务选举，这样做的好处就是做到镜像仓库服务的高可用，但是这样也就意味着肯定有两个数据中心的镜像服务是通过远程来获取的，这无疑会增大数据中心间的数据传输压力。另一个方案就是在正常情况下各个数据中心部署的Docker默认是使用自己本地的镜像仓库的，在本地镜像仓库出现问题的时候自动切到next repository server,这种方式我认为是比较好的一种方式，既保证了镜像仓库的高可用性，也可以最大程度减少对珍贵的网络资源的占用。

在容器的网络层面，容器网络面临的最大问题就是跨宿主机通信的问题，而且在我设计的容灾体系中更是变成了跨数据中心通信的问题。因此我认为使用大二层的Vxlan可以很好的解决这一问题。Vxlan的基本原理就是使用UDP来封装TCP数据包，也就是隧道封装技术。其实目前主要的容器网络解决方案如Weave、Fennel也是采用这样的方法。

相关的原理和实现方法，感兴趣的可以参考这篇文章： Vxlan实现原理。

容灾体系的技术选型

DWDM

DWDM就是所谓密集波分复用（Dense Wavelength Division Multiplexing）技术，指的是一种光纤数据传输技术，这一技术利用激光的波长按照比特位并行传输或者字符串行传输方式在光纤内传送数据。这里简单介绍一下一个关键设备就是OXC，这技术架构图里也提到了这个设备。

OXC是下一代光通迅的路由交换机。在全光网络中的主要功能包括：提供以波长为基础的连接功能，光通路的波长分插功能，对波长通路进行疏导以实现对光纤基础设施的最大利用率，实现在波长、波长组和光纤级上的保护和恢复。OXC设置于网络上重要的汇接点，汇集各方不同波长的输入，再将各路信号以适当的波长输出。目前在电信运营商都在逐步的升级替换成OXC，很快就会进入全光网时代。

在目前的商用单模光纤传输技术中，在240KM以内的单模裸光纤可以达到10Gb/s的带宽。如果需要传输更远的距离则需要一些中继设备，这样的话传输带宽就有所损耗，不过随着后续的技术发展，肯定会可以达到更远的记录和更大带宽，所以这也是在设计容灾体系中更多的是考虑异地双活而不是同城双活，因为在基础硬件设施允许的情况下，异地双活更具有价值。

Vxlan

Vxlan是由VMware和思科提出的标准，使用了L2oUDP的封装方式，支持16M的tenant ID，主要的与其他的技术不同的是通过OVS来实现大二层网络隧道的起点和终点，隧道的封装在服务器内部的Vswitch就已经打好，然后将物理网络当作大的IP背板加以穿透，大二层范围可以跨DC。以期达到快速部署，灵活创建虚拟化网络的目的。

思科最先提出和推广的是自己的OTV技术，这个技术的是思科在自己的交换机做了修改后实现的，简答来说就是隧道本端的OTV模块会将需要跨越数据中心传输的二层帧完整地打包到一个三层数据包中，然后通过路由交付到对端OTV模块进行处理，再隧道对端的OTV模块经过处理后解析出封装在三层数据包中的源MAC 目的MAC以及所要传输的数据包。这种方式是接触交换机的背板转发能力和解析能力来进行的，性能比较有保障。

VMware作为一家软件厂商，没有自己的硬件网络设备，于是VMware就通过自己的Vswitch来支持实现这种MAC in UDP的数据封装,通过IP的多播技术经过路由来实现跨数据中心通信的目的。具体的在前面的一篇链接中也提到，使用OVS是可以模拟实现大二层网络的。但是从实际使用来说，这种基于OVS的技术还是没有完全的成熟，在性能和稳定性上是存在一定的隐患的。不过，现在SDN这么火爆的情况下，可以相信这是最有前途的解决方案。

需要详细的了解Vxlan的技术可以参考 Vxlan的实现实验。

关于思科的解决方案介绍可以参考思科解决方案。

Ceph

在这个容灾体系中，统一存储Ceph与Docker结合解决容器存储甚至解决跨数据中心数据一致性的问题都是核心的问题，在构想这个容灾体系的时候我的想法是能够将Docker 的rootfs和volume跑在统一存储Ceph集群上，这也是我选择将Ceph作为面向宿主机提供统一存储服务的原因。在之前一篇腾讯游戏的文章提到了Ceph RBD Graph Driver他们说他们已经完成了这一驱动的开发，将rootfs挂载到RBD结合大二层网络实现容器的带IP飘移。但是他们提交给Docker社区后没有被社区接受。在持久化存储方面可以Docker通过volume driver的方式可以对接Ceph，从而实现容器持久化数据卷的功能，也能轻易实现容器的迁移，但是目前Docker官方还是没有正式支持虽然在一些开源项目已经有了解决方案。

因为Ceph目前作为最主流的统一存储解决方案，所以似乎Ceph在对容器存储的支持没有太多动力，我觉得解决容器持久化存储途径不光是要从容器出发，还要从Ceph项目主动的做一些匹配。因此在这个容灾体系中，在Docker支持将rootfs挂载到RBD上之前，我建议还是使用宿主机的本地存储，至于持久化存储可以使用Ceph挂载到宿主机上的文件目录。

Docker &Mesos

Mesos的选型我觉得需要根据所选用的执行框架，尤其是非Mesosphere生态的执行框架，需要考虑Mesos对执行框架的兼容性，还有就是对Docker版本的支持，不过这个不是很重要，Mesos和Docker的合作还是比较紧密的。

Docker在1.9版本中加入了很多的新特性来解决网络和存储的问题，其中在网络层面就使用了OVS（Open Vswitch）和VXLAN隧道进行实现，这样完全可以使用OVS的兼容性来实现跨数据中心的大二层网络。不过建议，使用专业的大二层网络的OVS解决方案替代Docker1.9中的OVS。关于Docker与Ceph RBD融合的问题我乐观的认为在Docker2.0版本这个问题应该会得到解决，因为这是Docker进入2.0阶段的一个里程碑，为了更快速的发展和在实际生产中得到应用，这个问题是要必须解决的。

容灾体系存在的问题和可能的解决方案

在这个容灾体系中使用了大二层网络，但是在大二层应用中有一个很致命的问题就是大二层网络风暴的问题，因为Vxlan技术主要是借助IP多播技术来进行类二层交换的，那么就不可避免的引起网络重启后的网络风暴。大家可以想象三个双活数据中心的上万个容器实例同时发起ARP广播引起的网络风暴是多么的可怕，根据传统网络的情况预估，可以瞬间将三个双活数据中心的网络压垮。

关于这个问题的解决方案，我的想法就是通过SDN的Controller来抑制和屏蔽大规模的启动风暴，如通过策略进行区域性的启动。这个问题供大家讨论。