混合云管理问题，你解决了么？

微信邦

背景

近几年随着“互联网+”,“云+”等概念的出现，云化服务日益成熟，市场上涌入大量的企业开始将自身的服务云化，如中小型互联网企业，传统企业，金融企业等。但是完整的云化不是一个短期就能快速实现的目标，特别对于一些庞大的传统企业，或一些对数据安全高度敏感的金融企业，市场提出了一个新的需求：混合云方案。

混合云方案指融合公有云和私有云等多种云环境的服务管理解决方案，包括管理多种公有云环境、自建的国内外IDC私有云环境。而混合云管理平台需要提供的能力包含统一CMDB资产管理、统一的服务器密码管理、统一的变更发布、数据迁移、跨云容灾、监控等。

所有的操作类能力全都依赖于底层的平台命令通道和云厂商的接口对接，该文章将介绍织云是如何建设和使用命令通道解决混合云的服务器管理问题。

混合云管理的问题

“客户虐我千百遍，我待客户如初恋！”

TOB和TOC最大的不同在于TOB的客户就是上帝，而且上帝有很多个性化的问题和需求。在织云命令通道设计的时候参考了很多织云实际客户的问题和场景，总结下主要有以下几点问题：

1. 网络复杂度

混合云最大的问题之一就是网络复杂度，不同客户可能购买了不同的公有云，有些搭建了自己的IDC，甚至有些在一个云环境里还搭建了多个私有子网，所以往往会遇到集群网络不通，集群之间网络不通，网络上行和下行只有一边通，安全策略限制，通信协议限制等。

2. 网络带宽

有客户搭建了海外IDC，海外IDC只能通过香港，走宽带很小的公网访问回国内，当客户需要对目标集群做数据迁移或发布一个大的文件包时，宽带将是最大的限制。

3. 服务器多样性

有些传统企业使用Windows 2000+ubuntu 12.04,14.04,16.04+定制的centos......由于客户服务器种类比较多，对底层通道的兼容性要求非常高。

4. 需求灵活性

客户往往有多种不同的个性化需求，例如有客户需要监控tomcat，写java的客户需要定时监控java的gc，采集指定的业务日志等，所以在设计底层通道的agent时，需要有足够的灵活性。

解决方案

在设计方案之前，参考过比较热门的开源软件，如saltstack、ansible、puppet等；以及市场上同类型管理平台。都非常优秀，而且各有优点，但无法满足客户和织云的需求，在此不多做对比。

1

网络复杂度

A) 使用Master+Proxy+Agent模型

Agent通过Proxy与Master通信，用户只需要给1~N台能与Master通信的服务器即可，这是目前最有效且兼容性最好的管理方式。当Agent启动时Agent主动连接Master，握手成功之后与Master保持长连接，该方式对客户的网络要求较低而且安全，只要Proxy能主动访问公网Master即可。

B) Proxy支持横向和纵向扩展

Proxy横向扩展主要为了容灾，当某Proxy连不上时，Agent尝试使用剩余Proxy；

纵向扩展解决用户子网深度，例如海外客户：泰国->香港->织云。

混合云管理问题，你解决了么？

C) 使用HTTP/HTTP2.0做为通信协议

几年前做运维的时候体验过私有协议在某些用户网络的兼容性痛苦，深切认识到HTTP应该是目前兼容性最高的应用层通信协议。但为了安全起见，使用HTTP2.0（基于HTTPS）做为通信协议。

协议兼容性切换，当HTTP2.0连不上Master时，尝试切换为HTTP短连接做轮询。

D) 支持SSH协议下发

Proxy+Aent需要客户环境到织云Master的上行网络，但如果有客户只支持下行网络，命令通道还需要支持Master通过SSH协议访问到客户集群的Proxy（优先使用Proxy-Agent模式）

混合云管理问题，你解决了么？

2

网络带宽

A) 采用“CDN”模型

做为混合云管理，变更发布是一项高频操作，发布本质上是文件分发的问题，有着资源热点的特性，所以采用CDN模型是比较合适的模型。

织云CDN源节点能提供文件分片能力，同时在Proxy节点上部署缓存组件，任一文件分片只要经过Proxy节点的缓存将会在Proxy上缓存一段时间，这样发布的数据文件只会经过一次公网，大大节约了带宽。

混合云管理问题，你解决了么？

B) CDN+P2P架构

CDN方案解决了宽带限制问题，但如果目标集群有大量的服务器且需要分发一个很大文件包时，Proxy的宽带将会是瓶颈。

思路是采用P2P模型做数据分享，提高文件分发效率，P2P有几种模型，如中心化拓扑模型，DHT网络模型，全分布式非结构化拓扑模型，半分布式拓扑模型。考虑到如果在客户环境采用类DHT搜索会给客户网络造成大量的额外数据搜索，织云采用中心化拓扑模型，由Proxy做为源seeder和tracker，结合上上面的A方案，最终文件分发模型类似如下：

混合云管理问题，你解决了么？

3

服务器多样性

A) Agent跨平台且对环境零依赖

早期采用shell+python的方式管理目标服务器，但发现在不同linux操作系统，客户定制系统下兼容性很差，更别提windows了，根本原因是对底层操作系统有很强的依赖，例如用了很多shell命令，有些命令在精简版linux下没有；python本身部分库又依赖了底层操作系统lib库。

最终agent选用golang开发，golang支持跨平台编译，且编译出来的可执行文件对环境无依赖（不写C,Go），是最合适做为agent开发的语言

4

需求灵活性

A) 设计方案

使用golang的plugin插件+container容器的设计方案，通过生成so插件文件，在线热加载新的so文件：

混合云管理问题，你解决了么？

B) 请求命令字

UUID：设备唯一ID，定位一台服务器，由框架解析定位。

CMD：命令字，定位要调用的模块，由worker解析找到指定执行模块，可以通过在线更新插件添加新命令字。

Taskid：当前任务id，定位某次命令执行。

混合云管理问题，你解决了么？

C) 在线更新与热加载插件

当Agent需要更新时，使用在线更新功能：

1. 下发命令给旧Agent；

2. 安装并启动新Agent；

3. 新Agent与Master连接并完成握手（如果握手失败或启动失败，则由旧Agent中止更新）；

4. Master更新该服务器的下发连接，即断开Master->旧Agent下发通道，不再下发命令给的旧Agent，但仍需等待旧Agent完成回收；

5. 发送kill信号（不是kill -9强杀）给旧Agent等待现有任务完成并上报，此时旧Agent->Master长连接还在，仍能上报；

6. 旧Agent完成回收任务，发送EOF信号给Master，释放该长连接；

7. 在线更新完成。

混合云管理问题，你解决了么？

总结

随着市场对云化大趋势的日益认可，混合云管理也将会是这个时期的强需求，织云也一直在探索市场的最新动态，支撑着云化的市场需求。