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

背景

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

混合云方案指融合公有云和私有云等多种云环境的服务管理解决方案，包括管理多种公有云环境、自建的国内外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方案，最终文件分发模型类似如下：