基于DockerMesosCeph全新技术栈的三地三中心容灾体系

Posted 2021-04-24 分布式实验室

容灾体系架构构想

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

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

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

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

容灾体系技术框架

如之前所说，在设计这个容灾体系的时候，我将两地三中心的概念进行了提升，变成了三地三中心。这样做的原因是当前的光纤传输技术的提升，目前在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实现原理（http://tonybai.com/2016/02/15/understanding-docker-multi-host-networking/）。

容灾体系的技术选型

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的实现实验（http://blog.csdn.net/freezgw1985/article/details/16354897）。

关于思科的解决方案介绍可以参考思科解决方案（http://wenku.it168.com/d_001129531.shtml）。

Ceph

在这个容灾体系中，统一存储Ceph与Docker结合解决容器存储甚至解决跨数据中心数据一致性的问题都是核心的问题，在构想这个容灾体系的时候我的想法是能够将Docker 的rootfs和volume跑在统一存储Ceph集群上，这也是我选择将Ceph作为面向宿主机提供统一存储服务的原因。在之前一篇腾讯游戏的文章（http://www.infoq.com/cn/articles/how-tencent-game-use-docker）提到了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来抑制和屏蔽大规模的启动风暴，如通过策略进行区域性的启动。这个问题供大家讨论。

Q&A

Q：您这个框架中使用的PaaS执行框架具体是什么？

A：这个是开放的，可以是马拉松也可以Kubernetes，这个都没有具体的限定的。因为我觉得这两个都是比较的执行框架。

Q： Docker的兴起是否会影响OpenStack云计算的地位会和OpenStack竞争，共存？OpenStack工程师如何面对Docker技术的兴起？Unikernel发展趋势能否取代Docker？

A：竞争肯定是有的，但是共存也是存在的，我认为这是一个灰度的。我觉得OpenStack工程师要拥抱Docker，其实我的主要工作就是向客户设计基于OpenStack的私有云解决方案。Unikernel技术的对手不是Docker，是容器。具体是否会取代，我觉得不一定。

Q：Vxlan具体怎么实现？是核心交换机旁挂大二层设备吗？另外超远距离，比如北京上海这么做会有什么问题？我们现在遇到延迟问题比较大。

A：VxLan的实现在Vswitch中通过对每次TCP包的UDP封装，Vswitch是在每个宿主机上的。北京到上海的话，就需要通过光纤中继，这会损耗一定的传输带宽，这么远距离的传输只能等待光传输技术的发展以及在应用层面进行弥补。不过在应用层去弥补这不是很好的方案。

Q：ZK集群的部署是怎样？有做哪些调优么？另外网络方面有做哪些监控么？

A：主要是根据实际的请求时延对TIMEOUT进行修改，网络方面的监控是通过专业的安全设备进行。

Q： 那个数据中心部署3机Mesos master，所有数据中心共享一个ZK集群，难道这个ZK集群如何在多数据中心部署，还有因为网络延时导致slave掉了后，或者executor挂了后怎么处理孤儿容器？

A：ZK是每台Master节点上的，由于使用了大二层网络，所以所有的ZK就相当于在同一个局域网内部署的。对于孤儿容器，是Kill掉然后替换的。

Q：请问在你们设计的方案中通常建议用户租用几条裸纤来实现三地三中心，同时考虑过租用长距离裸纤给用户带来的长期运维成本吗？

A：恩，这是个好问题，我在准备这次分享的时候也在考虑这个问题。这个设计方案的前提是客户有这样的需求，需要支付这样的成本去实现。从技术的角度，双纤是性能与经济性的平衡点。

Q：请问关于事务处理的负载轮询，如果使用长连接，如何保证每个连接负载是均匀的，同时这里的事务是指存储层的还是应用层的，如果是应用层是如何保证事务的？

A：这个确实比较难，可以采用类似于一致性哈希环的思想，就是尽可能多的将轮询环进行分割，这样长连接就会尽可能的均衡分配。负载轮询是在应用层面进行轮询的。

Q：你们这套架构上生产环境了吗？Ceph是强一致性的，6个副本延迟会不会大？六个副本是不是有点浪费存储空间？大规模写入的时候IO会不会是瓶颈（Ceph 先写Journal，再写磁盘）？另外，你们是全SSD吗？

A：这套架构没有上生产环境。这是我们公司做的一个前瞻性方案设计研究。在Ceph的副本配置中，有一个最小副本数，可以先设置一个最小副本数实现快速的写操作。之所以6副本，主要是防止避免过度频繁的数据读切换。在这种方案下，建议全部是SSD，当然也可以有选择性的使用SAS。

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