浅谈大规模分布式运维系统设计

问题导读：
1、Qingcloud P2P机器人社区的功能
2、分布式系统设计方案
3、P2P的设计重要吗？




                                                                                前几天在一个微信群中大家讨论云平台设计的时候，谈起了Qingcloud的P2P机器人社区的设计，今天我们就从Qingcloud的P2P机器人社区谈起。

1. Qingcloud P2P机器人社区的功能

从Qingcloud创始人Richard及其他人员的技术演讲资料来看，Qingcloud的P2P机器人社区功能可以总结在下面的图中,主要为基于P2P的组管理功能，资源分配算法， 故障检测和自动化处理以及正在开发的基于ML的规则系统。

1）基于P2P的组管理功能
资料中提到Qingcloud使用SMP和IGMP协议来做邻居节点探测， 当某个节点失效时其他节点能够得到通知同时运行在失效节点上的负荷会自动有其他节点自动分担。我们总结出三个关建词分别为：成员发现，事件通知，负荷分担。
2）资源分配算法
资源分配算法（placement policy）主要是用来解决公有云或私有云中一个虚拟机在首次创建和后续重启时虚拟机运行在集群中得哪个Hypervisor的问题，qingcloud提到他们会根据Hypervisor的负载， Hypervisor节点的credit（可以认为是一个健康状态的统计量化指标）以及物理主机上线时间等因素来综合决定。很多系统都有类似的模块设计，如OpenStack设计了专门的resource scheduler组件，而CloudStack及其增强版ZStack中有allocator来完成这个功能。 资源分配算法一般被抽象为一个线性优化或者背包算法， 实践上会设计成过滤和排序两个阶段， 甚至有的系统如Platform Resource Scheduler和OpenNebula都设计了DSL规则语言来形式化描述这些规则和过程。 Qingcloud则创新地将Hypervisor的故障信息和资产生命周期引入了这个决策的过程。
3）故障预测和自动化处理
这个其实才是大家最关心的问题， Qingcloud资料表明当前它们应该也是基于经验的做了很多precondition检查系统，即认为编写了很多检查脚本（如检查网络配置，网络状态等）， 当满足某些条件时触发预定义的Trigger自动执行处理操作。另外Qingcloud还使用了real-time stream data analysis技术（即流式处理处理）对很多监控数据做了分析，并接入整体系统。 这些功能覆盖传统的性能采集，告警产生（包括事件告警和数据告警），巡检系统（主要做各种预定义的检查工作）以及一个任务执行系统。 这是一个典型的负反馈控制系统的设计，qingcloud创新地将所有功能用新技术重新实现， 并引入了大数据处理的技术和思维。
最后一点就是机器学习， 具体做什么已经不重要，我们可以认为Qingcloud会保存系统运行的各种数据，通过各种算法的运用最终来使上述的过程更加智能和有效，当前还更多是靠人的经验积累，将传统ITIL中知识库build到了软件工具中。

2. 参考系统架构

笔者以前的工作一直在做分布式系统， 包括大规模Web， HPC，网格，云平台和大数据系统平台。接触了并设计开发过类似的系统，下面给出一个参考设计（PS，申请过专利，请大家不要简单copy，呵呵）。

主要包括以下几个部分
1） 集群管理
此处我们选择Gossip来做组管理。Gossip算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了 Gossip的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。 在采用Gossip的系统中加入有的节点因宕机而重启或有新节点加入，经过一段时间后，这些节点的状态也会与其他节点达成一致。Gossip可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。 但Gossip的缺点也很明显，冗余通信会对网路带宽、CPU资源造成很大的负载。
从网上流传的资料来看， AWS的集群管理使用的就是Gossip协议， 实际开发实现中也有很多开源软件实现了这个算法，如Serf等。
2） 监控采集/健康巡检系统
这个系统主要为一个周期性的Cron任务执行引擎和一个任务管理系统， 外加集成各种采集工具做实际的数据监采集。 Cron任务执行有很多实现，简单的可以使用Linux系统自带的Crond服务， 或者使用Java开源实现Quantz实现管理接口。 任务管理系统可以简单地实现一个中心控制节点，当然也可以采用负载均衡模式（建议使用CDH分布式哈希来做任务管理，这是Web系统做分布式的经典玩法）。下图是采用了CDH类似系统的参考架构，不解释。


3）规则引擎
规则引擎实现了触发器Trigger的功能，可以考虑接入其他告警事件系统。我们自己实际设计中clone了AWS的Autoscaling中的设计， 提供事件触发、手动触发、时间触发以及按照某种规则对数据经过计算处理后条件触发等功能。

4） 任务执行引擎
任务引擎可以设计为一个Master-Slave模型， 需要能够稳定可靠等执行各种预定义的任务和及时任务。你可以从Apache Mesos， Hadoop YARN中裁剪出任务执行部分来使用，当然直接用也可以。

其他的部分就是基于BigData的大数据处理平台，可以使用Hadoop， Storm和Sprk来搭建做各种监控数据的全量存储，流处理/批处理等操作，当然也可以使用各种机器学习算法。
这个系统最重要的其实是在系统运维过程中积累的经验和教训，以及相应地处理方法。 这些东西在传统ITIL和ITSM系统中就是知识库， 此处就是各种Checker和Aciton的集合。

3. 思考与实践
在微信群类讨论的过程中，我提出一个问题“P2P的设计重要吗”，ZStack的创始人Frank同样有这个问题。我们认为，在小规模和系统初始架构时就考虑这样的设计有点太重了，不适合创业公司采用。 Qingcloud据说是Richard在IBM时已经实践过类似的系统，可以比较容易地采用。

实践中可以根据人力和团队熟练掌握的技术从上图中找出一个来用，我们自己实际采用的就是简单地Master-Slave主从架构设计， 未来会根据需要向P2P架构演进。

最后而且最重要的是给我的团队打个广告，请大家转发时不要删掉。天云SkyForm云平台经过3个版本的开发和实际项目部署应用，具备完整的虚拟化服务管理及IT资源监控、告警功能，正式进入产品化阶段。天云软件正在进行Docker及各种公有云接入的开发，同步研发运维平台、高级资源调度及分析系统以增强SkyForm云平台功能达到可管理、可运营的目标（上图列出了部分重点技术及系统功能），配合SkyForm Application Platform，SkyForm HPC Platform等产品最终覆盖云平台的建设，云应用开发，系统维护，优化以及再投资决策等整个生命周期管理。

cloud123这个微信公众号会不定期分享一些云、大数据相关的内容，我的个人微信为yueshi123_jiakun（qq：5668764）, 欢迎大家一起交流云、大数据技术。

资料来源：cloud123