Mesos在传统金融企业的生产实践
Posted 高效运维
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Mesos在传统金融企业的生产实践相关的知识，希望对你有一定的参考价值。
编者按：平安科技的Mesos + Marathon 平台，目前已经很好地应用于生产环境如平安金管家等，共有两个集群，每个集群内存6TB+，都可以跑3000-4000个容器。本文为作者在4月23日数人云技术沙龙的分享实录。如转载请保留本文所有内容。
大家好！今天我分享的主题是《Mesos在传统金融企业的实践》。我是来自平安科技的陈秋浩，现在我的身份是Padis平台的项目经理，全面统筹并参与Padis平台的开发和运营，致力于容器云技术在平安的落地。
1、Padis平台的成长史
这里有一个关键词叫Padis，Padis是PingAn Distribution平安分布式平台的缩写。Padis是平安科技自己研发的、基于Docker技术的分布式的PaaS平台。简要特点如下：
底层基于Mesos + Marathon。
实现应用容器的创建、运行、快速缩容扩容、故障自愈。
自创容器动态独立IP功能，每个容器都有一个与传统三层网络打通的IP，满足传统的环境应用和容器应用做无缝调用。
软负载容器可根据应用容器的增删做动态调整。
平台自动化运维包括域名解析，CMDB自动录入，以及监控运维平台的自动配置。
Padis的LOGO是一棵树，我今天要讲的是Padis平台的成长史，怎么从种子到落地生根，到茁壮成长，到开花结果。
2、落地生根：从docker到Mesos+Marathon
关于Padis落地的机缘，大家看这个图。有没有觉得很熟悉？
2014年的曾经，我们和研发部门有着很深的情谊。直到有一天他找我说，新项目启动了，你必须帮我快速交付一套环境，期限是一个小时之内。
所以我们间友谊的小船说翻就翻了，因为他不知道我们要搭一套环境要做什么事情，我们要装OS、中间件，要配负载平衡，还要做域名解析等等。
还有另外一个场景，2014年的曾经，我们跟业务的运营也是唇齿相依的好伙伴。
直到有一天他找我说，还有一个月我们就双12了，我们系统会从8个实例扩容到50个实例，你得开始帮我做搭建扩容，所以：
我们的友谊小船又说翻就翻了。
因为，我们加班做扩容的时候，一是环境搭建步骤要do it again and again，二是要协调保证扩容的应用和原有的应用要保持高度一致，以免产生新的生产问题。
所以说，IT运维是高危行业，每时每刻都会有翻船掉入大海的危险。最重要的是可能我们还不会游泳。
我们需要一件救生衣来拯救我们，而那件救生衣就是Docker。
2014年，容器技术发展火爆，Docker的模板化可以把OS和中间件打包成镜像发布出来，甚至也可以把我们的应用打包到容器里，保证在每个主机上跑起来的容器的运行环境一样。
Docker也有它的便携性，不管是在物理机，还是虚拟机，只要我装了Linux，都可以在上面无差别地运行Docker应用。
2015年初，我们开始在开发环境小范围地引入了Docker，考虑到用户（研发人员）可能比较小白，对Docker的命令行操作不太熟悉，我们使用了Github的DockerUI项目：
可以通过页面的方式来管理HOST上面的Docker的大部分操作，相对方便一点。
我们把它平安化，做出单机版的Docker管理网页。这样，新上的OS都会做这样的标准化：装上Docker的服务，还有DockerUI的镜像。
同时我们自己也修复了原DockerUI里的一些bug，添加了镜像提交的功能。
因为DockerUI的定位是在一台主机上管理容器相关的操作，并没有涉及到仓库的查询、下载镜像等功能，所以我们自己在平安的DockerUI里把这部分仓库管理的功能也加上去了。
当然，单机版的Docker有一定的局限性。
首先，容器没有集群概念，虽然创建了两个容器，两个容器虽然跑的是相同的应用包，但是并没有被关联起来。如果跨主机，容器之间不能通信。
其次，没有一个好的、健康的检查机制，当容器故障了无法自动恢复。
另外，直接把Docker底层管理操作暴露给小白用户，他们的学习成本是比较高的，而且他们对Docker的底层管理和实现并不关心，他们关心的是你能不能交付给我一个较为完整的环境。
也就是说我们现在有了一件救生衣，但这件救生衣随时可能漏气，所以友谊的小船还是可能说翻就翻的。
这个时候我们希望有一个集群化的东西，有很多的救生衣，把所有的救生衣放在一起做成一个救生艇，最后我们就引进Mesos + Marathon。
3、修枝除杂：改造MM框架，使之适应平安传统应用
第二个阶段先说一下Mesos + Marathon优势。
首先，DCOS可以把数据中心里的所有的服务器全部集合起来变成一个集群，IT运维人员可以像操作一个OS一样来管理这个集群，自由地分配CPU、内存的资源来跑应用的容器。
其次，容器应用集群化，可以针对同样类型的应用集群做到快速缩容扩容。
第三，健康检查方式，可以定义容器应用的健康检查条件，可以是TCP，也可以是HTTP，只要是检查到应用有问题的时候，它会再重新启一个新的容器。
第四，支持条件约束，我们常常有监管上的要求，比如寿险和产险的应用不能放在同一个物理机上，Mesos有条件约束，帮我们实现业务隔离，还可以设定条件，比如同个应用的实例需要分配在不同的物理机上来实现物理上的高可用。
第五，支持事件订阅，所有的实例启停，应用缩容扩容消息都可以通过HTTP推送到我自己订阅的服务上。
第六，有很多的扩展功能，像Mesos-DNS和Mesos-LB。
选定底层框架、在和应用结合的时候我们发现一个很致命的问题：平安的传统应用对IP是很依赖的。
平安的标准应用经过差不多10年的沉淀，每一个应用实例基本上都会绑一个自己的IP。但是我们在容器里用的是Docker0，一个私网的IP，是不能跟外界通信。
但如果把平安的应用放在Docker里会怎么样？
在这个例子里，我们的应用A没法继续调下去了，因为我们的三层网络里，10.1.1.1和docker0私网的172.17.0.4是不通的。
如果容器里我们能做到独立IP，给每个容器都添加一个跟内部的网络相通的IP，我们的整个框架就可以用起来。
我们还有一些独立IP的需求，比如说我有两个容器应用，应用之间是需要做组播的。因为容器出docker0的时候去会做NAT，做完NAT以后这个组播就不成立，两个容器应用间没办法通过组播通信。
除了平台之间的容器要互通外，我们的容器还得和传统环境应用的IP做直接通讯。
此外，传统的用户是希望像管理虚拟机一样管理容器，希望容器有自己的IP，通过这个IP SSH登录到这个容器里，他可以查日志，或做一些自己的操作。
Docker早期、还有MM框架早期，是没法满足容器独立IP的需求的。
一直到2015年的11月，Docker 1.9发布，正式支持overlay网络，支持跨主机网络模块的通讯，当然，这个方案是对底层的网络是有一个要求的。
基于此，2016年1月，Marathon也发布了0.14的版本，开始支持一容器一IP（IP-per-task），就是独立IP的概念。
我们在2015年初期就启动了这个项目，在2015年3月份我们Padis平台自己研发了network模块，支持平台级的应用容器独立IP功能。
我来简单介绍下network模块的实现原理，我们的平台有一个消息驱动中心，可以获知Mesos + Marathon框架下每个容器的添加、删减或重启，它都能够对获取到任务信息做出响应。
通过Ansible模块，一个自动调用模块，可以把所有添加、删除IP全部做到自动化。
具体怎么把IP加上去也很简单，我们基于Docker的bridge模式，有两种方案可以选，可以用Linux bridge或者OpenVSwitch，把指定网段的IP加入到容器里面，实现了容器与传统环境应用兼容与互通。
区别在于，Linux bridge只能添加跟slave host同个VlAN的IP。而用户OpenVSwitch可以指定添加任意的VLAN的IP。
下面是一个例子，现在有一个Mesos主机，首先会在这个主机上添加bridge，把主机网卡，可以是物理机的，也可以是虚拟机的，把这个网卡加入bridge里面，bridge配上原本的管理IP。
在启容器的时候，在容器里面再启一个新的网卡，会在OS上面建一个成对的虚拟子接口，把它加入到bridge里面，这个时候10.1.3.1和10.3.1.10就实现了互通，同理可以做到不停地往主机上面加容器，整个集群都可以用这个框架来做。
这张图有六个IP，这六个IP都是互通的。这样就实现满足了最开始说的，平安的传统应用所依赖的IP功能的需求。
同时，我们平台对各个IP的分配也有一些规则上的限定。
首先，由平台管理IP池，IP有三种状态，一是已分配给应用，二是未分配给应用，三是永不分配的保留IP。我的IP一旦分配给某个应用以后，除非用户说我这个IP不用了，我要把对应的IP实例缩容删除，这个IP才会回收到IP池里，再提供给别的应用做分配。
这样做是为了防止IP如果一重启的话，有可能被别的实例使用到的风险。在传统金融企业里会有很多防火墙的需求，防火墙一般是针对应用的单个IP开的，如果IP变了，可能防火墙要重新开，需要再做一次自动化。
其次，某一个应用实例发生重启或故障以后，平台会自动在新实例所在Slave Host完成添加IP的动作。当然，事前我们就在旧的主机上把虚拟接口删了，防止IP会发生冲突。
通过这种方式，搞定了容器独立IP的需求，我们接下来还会面临更多的挑战。
Mesos-DNS和Mesos-LB就不再适用，因为Mesos的方案是基于NAT的模式做的，而我们自己实现了独立IP的功能，所以它提供的便利服务我们现在是用不到的。
我们DNS是通过平台消息驱动中心和平安内部的DNS做自动化对接，每扩容或缩容一个实例的时候，都会自动对独立的IP做DNS解析。
负载均衡，传统金融企业用的很多是F5，现在也有很多LVS、Haproxy。我们平台有多种方案给用户做选择，可以做硬件的F5，还有软件LVS、Haproxy。
但对后台的容器应用来说，每一次扩容或缩容，对应的负载均衡后端配置也会自动更新，用户不需要再人工修改配置文件。
下面我着重讲一下Padis平台的软负载均衡。软负载均衡和应用其实是一样的，都是运行的容器。Haproxy、LVS服务都是跑在MM框架上的一个Docker应用。
Mesos + Marathon本身就有高可用的功能，发生故障的时候可以帮你再启一个，还可以帮你快速做扩容。
针对LVS有两个概念，一是前端，二是后端。
对LVS（DR模式）来说，它的后端就是应用容器，当使用LVS做负载均衡，平台会自动地对每个容器做这些常规操作：“把VIP加到loopback网卡上，禁用arp announce等。”
LVS的前端是负载均衡容器，容器里面还集成了quagga，它是一个软件路由器，通过它发送OSPF的协议，解决LVS单点的问题，传统的LVS的架构是一主一倍，单点提供服务。
我们用quagga以后，用OSPF做动态路由，最多同时有8个LVS同时提供服务，高效解决高并发场景。具体的原理大家可以看一下PPT里面的链接。
4、本固枝荣：扩展平台自动化功能
我们解决了刚需，即容器拥有独立IP，平安的传统应用也能跑在Mesos + Marathon的框架下，平台的基本需求已经差不多满足了。
下面就进入到第三阶段，更多自动化的集成。
首先是CMDB的集成。Mesos + Marathon动态化的设计，使得其框架本身CMDB的支持很弱，甚至说是没有。
Padis平台自带CMDB的功能，提供一个网页入口给到用户做信息查询，应用管理等常规操作。
另外平安内部也有另外一个很庞大完善的公共CMDB，本平台也通过自动化对接的方式，每扩容或缩容一个实例，都会把它的IP信息更新到公共CMDB信息里。
其次，我们也同时做了运维监控平台自动化。这个监控是多维度的：
应用的性能监控，这个是基于Zabbix做的。
Marathon和Mesos本身组件的性能监控，通过调用各自组件API，取得metrics后入库做的监控。
针对整个Mesos集群里所有的每一台主机的CPU和内存做实时的监控。
第三，自动化做了日志集中管理对接。传统应用的日志是写在本地的，我们没有对应用上层做出改造，我们是通过修改底层平台的方法来做到对应用透明的。
在启动容器的时候，分配共享存储并将其挂载到容器里。应用的日志还是以文件的形式写在这个共享存储中。
而在另外一个地方，该共享存储也可以接入平安内部的ELK日志管理平台，帮业务运营同事做日志的Access、活跃度等分析统计，同时可以自定义一些报警的关键字，进行日志报警知会。
第四，其他一些功能的加入。比如说WebSSH、一键环境克隆，还有NAS存储挂载等功能，在Padis平台上都只是需要简单配置就可以自动实现。
这个图是整个平台的架构，大家可以看一下。
中间有一个Resource Manage和Schedule Framework，资源管理就是Mesos，上面的资源调度框架是Marathon。
我们的平台只是集成、使用了很小的一部分，其他的都是我们自己根据平安内部的需求所自定义开发的，里面会有其他的一些，像CMDB、监控、自动化操作等模块。
5、开花结果：平台实践成果简单介绍
最后简单介绍一下我们平台实践的成果。截止到现在，我们生产环境有两个网络区域，一是内网ServerFarm，还有一个是公网DMZ web，这两个Mesos集群里都是接近1000 CPU CORE，6TB+内存的集群，每个集群都可以跑3000-4000个容器。
平安的很多重要的渠道应用已经在很多生产环境上使用了，像平安WiFi、平安金管家、平安任意门等等。
下面简单介绍一下平安金管家的保本基金抢售活动，是在股市较为波动的行情下推出的一个3年收益率18%的保本基金，还是有一定的吸引力的。
通过我们的Padis平台，底层的应用实例很快从8×8变成50×50。而负载均衡使用的就是前面说的LVS cluster框架，因为他们自己业务评估可能有几万，实际压测的时候确实没什么压力。
当然我们自己觉得这个框架压测几十万、上百万都没问题。抢售活动购买最低限额是100元，最开始抢购的一分钟销售达到1亿。
我们的DevOps实践也基于这个平台，通过我们搭建的一套CI集群，开发和测试人员自助在集群上面搭了1000多套应用环境，数量还是比较多的。
最后给大家隆重推荐一本书，叫《PaaS实现与运维管理 基于Mesos + Docker+ELK的实战指南》。作者是平安科技基础架构部系统软件技术领域的负责人余何。这本书的撰写和Padis平台的建设是同步执行的，是Padis平台从无到有、最终能落地开花的指导思想，推荐给想学习PaaS技术，自建并运维PaaS平台的小伙伴们阅读。
数人云
将应用弹性做到极致
对了，点击下文的“阅读原文”链接即可下载本次分享PPT。请笑纳
以上是关于Mesos在传统金融企业的生产实践的主要内容，如果未能解决你的问题，请参考以下文章