微博基于Docker容器的混合云迁移实战

陈飞

微博研发中心技术经理及高级技术专家。2008年毕业于北京邮电大学,硕士学位。毕业后就职华为北研。2012年加入新浪微博,负责微博Feed、用户关系和微博容器化相关项目,致力于Docker技术在生产环境中的规模化应用。2015年3月,曾在QClub北京Docker专场分享《大规模Docker集群助力微博迎接春晚峰值挑战》。

一、为什么要采用混合云的架构

在过去很长的时间内,大部分稍大些的互联网系统包括微博都是基于私有体系的架构,可以在某种程度理解成私有云系统。混合云,顾名思义就是指业务同时部署在私有云和公有云,并且支持在云之间切换。实际上“为什么要采用混合云”这个问题,就等于“为什么要上公有云”。我们的考虑点主要有四个方面

业务场景

随着微博活跃度的提升,以及push常规化等运营刺激,业务应对短时极端峰值挑战,主要体现在两个方面:

  • 时间短,业务需要应对分钟级或者小时级。
  • 高峰值,例如话题经常出现10到20倍流量增长。

成本优势

对于短期峰值应对,常规部署,离线计算几个场景,我们根据往年经验进行成本对比发现公有云优势非常明显

效率优势

公有云可以实现5分钟千级别节点的弹性调度能力,对比我们目前的私有云5分钟百级别节点的调度能力,也具有明显优势。

业界趋势

“Amazon首次公布AWS业绩:2014年收入51.6亿美元,2015年1季度AWS收入15.7亿美元,年增速超40%。”“阿里巴巴旗下云计算业务阿里云营收6.49亿元,比去年同期增长128%,超越亚马逊和微软的云计算业务增速,成为全球增速最快的云计算服务商。”

我们预计未来产品技术架构都会面临上云的问题,只是时间早晚问题。

安全性

基于数据安全的考虑,我们现阶段只会把计算和缓存节点上云,核心数据还放在私有云;另外考虑到公有云的技术成熟度,需要支持在多个云服务直接进行业务灵活迁移。

基于上述几点考虑,我们今年尝试了以私有云为主,公有云为辅的混合云架构。核心业务的峰值压力,会在公有云上实现,业务部署形态可参考下图

下面介绍介绍技术实现。整体技术上采用的是Docker Machine + Swarm + Consul的框架。系统分层如下图

二、跨云的资源管理与调度

跨云的资源管理与调度(即上图中的pluto部分)的作用是隔离云服务差异,对上游交付统一的Docker运行环境,支持快速弹性扩缩容及跨云调度。功能上主要包括:

  • 系统初始化
  • 元数据管理
  • 镜像服务
  • 网络
  • 云服务选型
  • 命令行工具
  • 其他

系统界面如下图:

系统初始化

最初技术选型时认为Machine比较理想,仅需要SSH通道,不依赖任何预装的Agent。我们也几乎与阿里云官方同时向Docker Machine社区提交了Driver的PR,然后就掉进了大坑中不能自拔。

例举几个坑:

  • 无法扩展,Machine的golang函数几乎都是小写,即内部实现,无法调用其API进行功能扩展。
  • 不支持并发,并发创建只能通过启动多个Machine进程的方式,数量多了无法承载。
  • 不支持自定义,Machine启动Docker Daemon是在代码中写死的,要定义Daemon的参数就非常ugly。

目前我们采用的是Puppet的方案,采用去Master的结构。配置在GitLab上管理,变更会通过CI推送到pluto系统,然后再推送到各实例进行升级。在基础资源层面,我们目前正在进行大范围基础环境从CentOS 6.5升级到CentOS 7的工作。做这个升级的主要原因是由于上层基于调度系统依赖Docker新版本,而新版本在CentOS 6.5上会引发cgroup的bug,导致Kernel Panic问题。

元数据的管理

调度算法需要根据每个实例的情况进行资源筛选,这部分信息目前是通过Docker Daemon的Label实现的,这样做的好处是资源和调度可以Docker Daemon解耦。例如我们会在Daemon上记录这个实例的归属信息:

—label idc=$provider #记录云服务提供商
—label ip=$eth0 #记录ip信息
—label srv=$srv #记录所属业务
—label role=ci/test/production…

目前Docker Daemon最大的硬伤是任何元数据的改变都需要重启。所以我们计划把元数据从Daemon迁移到我们的系统中,同时尝试向社区反馈这个问题,比如动态修改Docker Daemon Label的接口(PR被拒,官方虽然也看到了问题,但是比较纠结是否要支持API方式),动态修改registry(PR被拒,安全因素),动态修改Docker Container Expose Port(开发中)。

镜像服务

为了提升基础资源扩缩容的效率,我们正在构建虚机镜像服务。参考Dockerfile的思路,通过描述文件定义定义虚机的配置,支持继承关系,和简单的初始化指令。通过预先创建好的镜像进行扩缩容,可以节省大约50%的初始化时间。

描述文件示意如下:
centos 7.0:
– dns: 8.8.8.8
– docker:
– version: 1.6
– net: host
meta:
– service: $SRV
puppet:
– git: git.intra.weibo.com/docker/puppet/tags/$VERSION
entrypoint:
– init.sh

不过虚机镜像也有一些坑,例如一些云服务会在启动后自行修改一部分配置,例如router, dns, ntp, yum等配置。这就是上面entrypoint的由来,部分配置工作需要在实例运行后进行。

网络

网络的互联互通对业务来说非常关键,通常来说有三种方案:公网,VPC+VPN,VPC+专线。公网因为性能完全不可控,而且云服务通常是按照出带宽收费,所以比较适合相互通信较少的业务场景。VPC+VPN实际链路也是通过公网,区别是安全性更好,而且可以按照私有云的IP段进行网络规划。专线性能最好,但是价钱也比较好,且受运营商政策影响的风险较大。

网络上需要注意的是包转发能力,即每秒可以收发多少个数据包。一些云服务实测只能达到10万的量级,而且与CPU核数、内存无 关。也就是说你花再多的钱,转发能力也上不去。猜测是云厂商出于安全考虑在虚机层面做了硬性限制。我们在这上面也中过枪,比如像Redis主从不同步的问题等等。建议对于QPS压力比较重的实例进行拆分。

云服务选型

我们主要使用的是虚机和软负载两种云服务。因为微博对缓存服务已经构建一套高可用架构,所以我们没有使用公有云的缓存服务,而是在虚机中直接部署缓存容器。

虚机的选型我们重点关注CPU核数,内存,磁盘几个方面。CPU调度能力,我们测试总结公有云是私有云的1.2倍,即假设业务在私有云上需要6个核,在公有云上则需要8个。

内存写入速度和带宽都不是问题,我们测试发现甚至还好于私有云,MEMCPY的带宽是私有云的1.2倍,MCBLOCK是1.7倍。所以内存主要考虑的是价钱问题。

磁盘的性能也表现较好,顺序读写带宽公有云是私有云的1.4倍,随机写是1.6倍。唯一要注意的是对于Redis这种业务,需要使用I/O优化型的虚机。

以上数据仅供参考,毕竟各家情况不一样,我们使用的性能测试工具:sysbench, mbw, fio,可自行测试。

CLI客户端(命令行工具)

为了伺候好工程师们,我们实现了简单的命令行客户端。主要功能是支持创建Docker容器(公有云或私有云),支持类SSH登陆。因为我们要求容器本身都不提供SSH(安全考虑),所以我们是用Ruby通过模拟docker client的exec命令实现的,效果如下图:

其他方面

跨域的资源管理和调度还有很多技术环节需要处理,比如安全,基础设施(DNS、YUM等),成本核算,权限认证,由于这部分通用性不强,这里就不展开了。

三、容器的编排与服务发现

提到调度就离不开发现,Swarm是基于Consul来做节点发现的。Consul采用raft协议来保证server之间的数据一致性,采用gossip协议管理成员和传播消息,支持多数据中心。Consul集群中的所有请求都会重定向到server,对于非leader的server会将写请求转发给leader处理。

Consul对于读请求支持3种一致性模式:

  • default :给leader一个time window,在这个时间内可能出现两个leader(split-brain情况下),旧的leader仍然支持读的请求,会出现不一致的情况。
  • consistent :完全一致,在处理读请求之前必须经过大多数的follower确认leader的合法性,因此会多一次round trip。
  • stale :允许所有的server支持读请求,不管它是否是leader。

我们采用的是default模式。

除了Swarm是基于Consul来做发现,业务直接也是通过Consul来做发现。我们服务采用Nginx来做负载均衡,开源社区的方案例如Consul Template,都需要进行reload操作,而reload过程中会造成大量的失败请求。我们现在基于Consul实现了一个nginx-upsync-module。

Nginx仅需在upstream配置中声明Consul集群即可完成后端服务的动态发现
upstream test {
# fake server otherwise ngx_http_upstream will report error when startup
server 127.0.0.1:11111;
# all backend server will pull from consul when startup and will delete fake server
consul 127.0.0.1:8500/v1/kv/upstreams/test update_timeout=6m update_interval=500ms strong_dependency=off;
upstream_conf_path /usr/local/nginx/conf/upstreams/upstream_test.conf;
}

这个模块是用C语言实现的,效率已经经过线上验证,目前验证在20W QPS压力没有问题。而且这个模块代码已经开源在Github上,也欢迎大家提Issue:https://github.com/weibocom/nginx-upsync-module

下图是我们做的几种方案的性能对比:

当然我们的RPC框架motan也会支持Consul,实现机制同样也是利用Consul的long polling机制,等待直到监听的X-Consul-Index位置发生变化,这个功能已经在我们内网验证通过,不过由于依赖整个motan框架,所以目前还没有开源。

Consul的监控

由于Consul处于系统核心位置,一旦出现问题会导致整体所有集群失联,所以我们对Consul做了一系列保障措施,其中所有Consul Server节点监控指标如下

Leader节点监控指标如下图

Consul的坑

除了使用不当导致的问题之外,Consul Server节点通信通道UDP协议,偶发会出现server不停被摘除的现象,这个问题官方已在跟进,计划会增加TCP的通道保证消息的可靠性。

容器调度

容器调度基于Swarm实现,依赖Consul来做节点发现(话说Swarm才刚刚宣布Production Ready)。容器调度分为三级,应用-应用池-应用实例,一个应用下有多个应用池,应用池可以按机房和用途等来划分。一个应用池下有多个Docker容器形式的应用实例。

我们利用Swarm的Filter机制,实现了适应业务的调度算法。整个调度过程分为两步:主机过滤:指定机房、内存、CPU、端口等条件,筛选出符合条件的主机集合;策略选择:对符合条件的主机集合进行打分,选择出最合适的主机,在其上创建容器以部署应用。调度子系统Roam实现了批量的容器调度与编排。

业务调度

容器调度是于业务无关,具体串联起资源管理,容器调度,发现等系统,完成业务容器最终跨云部署的是我们的JPool系统。JPool除了完成日常的业务容器上线发布之外,最重要的是完成动态扩缩容功能,使业务实现一键扩容、一键缩容,降低快速扩容成本。一次扩容操示意图如下

围绕这调度和发现,需要很多工具的支撑:

例如为了使业务接入更加方便,我们提供了自动打包工具,它包括代码打包、镜像打包的解决方案,支持svn、gitlab等代码仓库,业务仅需要在工程中定义pom.xml和Dockerfile即可实现一键打包代码,一键打包镜像,过程可控,接入简单。

我们还对Docker的Registry,我们进行了一些优化,主要是针对混合云跨机房场景,提供跨机房加速功能,整个服务架构如下:

四、混合云监控体系

微博体系在经历了多年的IT建设过程后,已经初步建立了一套完整的信息化管理流程,极大地提升了微博业务能力。同时微博开展了大量的IT基础设施建设(包括网络、机房、服务器、存储设置、数据库、中间件及各业务应用系统等)。

针对于混合云体系,我们提供了一套完整的监控告警解决方案,实现对于云上IT基础架构的整体监控与预警机制,最大程度地保证了微博体系能够稳定地运行在混合云体系上,不间断地为用户提供优质的服务。监控告警解决方案实现了四个级别上的监控与预警:

  • 系统级监控
  • 业务级监控
  • 资源级监控
  • 专线网络监控

系统级监控

混合云体系支持的系统级监控(与新浪sinawatch系统的对接)包括:CPU,磁盘,网卡,IOPS,Load,内存

业务监控

混合云体系集成了目前微博业务监控平台Graphite,自动提供了业务级别(SLA)的实时监控与告警。所有的配置与操作都是系统自动完成的,不需要用户进行额外的配置操作。

业务级别的监控包括:

  • JVM监控: 实时监控堆、栈使用信息、统计gc收集时间、检查JVM瓶颈等。
  • 吞吐量监控: 实时监控业务系统吞吐量(QPS或TPS)。
  • 平均耗时监控: 实时监控业务系统接口的平均耗时时间。
  • 单机性能监控: 实时监控单台服务器的各种业务指标。
  • Slow监控: 监控服务器集群,实时显示当前业务系统中最慢的性能瓶颈。

资源监控

混合云体系集成了目前微博资源监控平台sinadsp,自动提供了对各种底层资源的实时监控与告警。所有的配置与操作都是系统自动完成的,不需要用户进行额外的配置操作。

具体的监控指标包括:命中率,QPS/TPS,连接数,上行/下行带宽,CPU,内存。

五、前进路上遇到的那些坑

需要注意的坑,实际在各部分中都有提及。今天分享的主要内容就是这些了,当然业务上云,除了上面这些工作之外,还存在很多技术挑战要解决。比如跨云的消息总线,缓存数据同步,容量评估,流量调度,RPC框架,微服务化等。

Q&A

Q1 : 为什么选Consul?看中有对比Zookeeper、etcd,尤其是etcd?

我们有对比etcd和consul,主要还是看重了consul基于K-V之外额外功能,比如支持DNS,支持ACL。另外etcd不对get request做超时处理,Consul对blocking query有超时机制。

Q2 : 上面提到的方案主要是Java体系, 对于其他语言(php, nodejs, golang)体系系统的是否有很好的支持(开发、测试、发布部署、监控等)?

已经在开始php的支持。其实容器化之后,所有语言都是适用的。

Q3 : Docker registry底层存储用的是什么,怎么保障高可用的?

底层使用的Ceph,前端无状态,通过DNS做跨云智能解析,加速下载。

Q4 : Consul temple reload nginx时为什么会造成大量请求失败呢,不是graceful的吗?

是graceful的,在QPS压力较大的情况下,由于需要进行大量重连,过程中会产生较多失败请求。

Q5 : 刚才提到的调度系统是自己开发的?还是基于开源改的?
是基于Swarm二次开发的。

Q6 : 容器跨主机通信是host网络吗?

对,目前线上采用的是host网络。
Q7 : Ceph IO情况怎么?高IO的是不是不太适合用Ceph?
针对Registry场景Ceph IO是可以胜任的。不过Ceph暂时还没有宣布Production Ready,所以对于极端业务场景,请谨慎。

内容来源:高可用架构公众号ArchNotes

未经允许不得转载:氢网 » 微博基于Docker容器的混合云迁移实战

支付宝扫码打赏 微信打赏

欢迎点击上方按钮对我打赏

分享到:更多 ()

评论 抢沙发

评论前必须登录!