分布式系统迁移Docker云

栏目: 编程工具 · 发布时间: 7年前

内容简介:分布式系统迁移Docker云

前言

“只要站在风口,猪也能飞起来”,这碗心灵鸡汤不知道激励了多少英雄豪杰踏上寻风口之路。而现如今,Docker这阵龙卷风呼啸来袭,更让众人生起迎风而上、直冲云霄的欲望。为了找到这风口,腾讯数据平台部开始全面拥抱docker,基于多年的大数据集群管理经验,倾力打造DockerOnGaia云平台(简称Gaia云),并动员将数平自身的核心系统全面接入Gaia云。

Lhotse系统作为先锋部队,经过一段时间的改造-验证-灰度,目前现网已经完全接入、稳定运营。本文旨在分享Lhotse接入Gaia云的一些实践经验,抛砖引玉,期待更多的系统加入队伍,一起在 Docker 云中探索前行。

背景介绍

Lhotse是一个大数据任务调度系统,从架构上看是典型的Master-Agent分布式架构,如下图所示,作为调度核心的Base统筹分配任务,交由对应类型的Runner执行:

分布式系统迁移Docker云

到目前为止,Lhotse线上支持68种Runner,分别对应68种不同的任务类型,集群总机器数将近200台。面对这种复杂多样的系统环境,Lhotse接入Gaia云的核心诉求是自动化,通过自动化来降低系统管理复杂度、提高运维效率。自动化运维可以总结为两点:

机器操作取代人工操作——将复杂枯燥的工作(比如资源分配、程序部署)交给云平台处理。

通用实现取代重复实现——云平台将一些通用性的基础工作(比如进程监控、自动拉起)抽象成标准化服务,不必重复造轮子。

除了自动化之外,Gaia云带来的另一个核心点是透明化。它在应用的不同阶段有不同的含义:

在应用部署阶段,指的是机器集群的透明化。集群规模、机器分布、机器规格等因素对用户来说都是透明的,成群的服务器被Gaia封装成了一台超级计算机。

在应用运行阶段,指的是实例状态/资源使用/历史事件/系统日志的透明化。通过Gaia封装的API或者web portal,应用的一切运行动态尽在掌握,透明公开。

下面我们将分别从部署、调度、容错、灰度升级、扩缩容及服务发现六个纬度,来讨论Gaia云如何为Lhotse带来自动化与透明化。

部署

Lhotse部署遇到的最大难点在于,每个类型的Runner所依赖的运行环境都有差异。例如,Pig Runner需要机器上预装PigClient、Hadoop,而Compute Runner需要预装PLC。极端的情况是,68种Runner对应68种不同的运行环境,要在200台机器里交叉部署,并且保证各个运行环境完整一致、相互不受影响,这对运维来说是极大的挑战。

对症下药,Gaia云给我们开出Docker这一药方,带来了如下功效:

环境一致:将软件运行环境(包括程序包、软件依赖、配置文件等)镜像化后,无论在哪台机器运行,只要镜像相同,容器启动后的运行环境总是一致的。

环境隔离:在同一台机器运行的多个容器,其运行环境(比如,软件版本与配置)相互隔离、不受干扰。

版本管理:每次软件升级可重新构建镜像,通过镜像tag来管理标注不同的版本,方便灰度、回滚。

快速部署:将软件部署到新的机器,仅需获取镜像这一步操作,无需拷贝、安装、配置等一系列过程。

现在,Lhotse的部署流程已经完全Docker化:我们将每个Base/Runner及其运行环境build成一个Docker镜像,push到Gaia云的Registry;每次启动Base/Runner容器时,Gaia自动从Registry pull最新的镜像。整个部署过程如下图所示:

分布式系统迁移Docker云

调度

有了自动化部署,我们可以方便地将Base/Runner发布到集群的任意机器。但接下来的问题是,选择哪台机器在什么时候运行哪个程序——这是调度要解决的问题。

以前,Lhotse集群的调度都是人工静态处理,资源分配粒度只能到机器级别。这导致调度工作量大,资源利用率却不高。如下两图分别展示了各个Runner机器的CPU与内存利用率(横坐标表示Runner类型编号,纵坐标表示利用率数值):

分布式系统迁移Docker云

分布式系统迁移Docker云

现在,得益于Gaia云强大的调度能力,Lhotse已经告别了人工资源分配的时代,完全实现调度的自动化。Gaia的调度能力主要体现在两个方面:

资源分配粒度精细到CPU与内存级别。Lhotse可以根据每个Runner的资源需求来设定具体的CPU个数、内存值。目前,Gaia正在规划支持磁盘、网络带宽等其他资源,实现更精细化的调度。

集群公平地与其他租户共享(租户可以是不同的系统,也可以是同一个系统内的不同模块)。目前,Lhotse与Hermes系统共享集群,如下图所示,在Gaia中通过树形队列来抽象租户层次:Lhotse与Hermes作为顶级租户,根据它们不同的资源需求(Lhotse偏向CPU密集,Hermes偏向memory密集)按比例瓜分集群资源。在Lhotse租户内部,Base租户与Runner租户根据同样的调配逻辑来瓜分Lhotse的资源。这种层级化的多租户资源调配,既实现了资源的最大化利用,也保证了资源共享的公平性、可控性。

分布式系统迁移Docker云

容错

如前文所言,Lhotse的Runner多达68种,任何一个Runner出错,都有可能影响大批的调度任务。因此,对于每个Runner的监控及出错处理至关重要。

以前,Lhotse通过自定义脚本来监控Runner进程,在发现错误的情况下自动重启或拉起。这种方式存在两点弊端:一是监控脚本本身也需要维护;二是只能做本机重启,无法跨机重试,对于机器挂掉的情况无能为力。

现在,借助Gaia云的自动容错机制,Lhotse从单机容错上升为集群容错,主要体现在两个层面:

自动重试,包括本地重试和跨机重试。Gaia云对于机器宕机、进程异常退出、OutOfMemory等异常都可以做到自动重试告警,且重试次数可以自行设定,本地重试优先于跨机重试。对于有本地上下文信息的Runner,可以设定较高的本地重试次数,以尽量保证效率。

自动屏蔽,即黑名单机制。当机器失败达到预设的次数,将被推上黑名单,在一定的时间内对调度屏蔽,以尽量降低出错的影响,且对业务来说是透明的。

灰度升级

为了保证任务高并发和系统高可用,Lhotse每个Base/Runner应用需要运行多个实例,在Gaia云中分别由Applicaiton和Instance来抽象:向Gaia提交Application时,可以指定Docker镜像、Instance个数以及其他相关配置,如下图表示了一个Runner应用的部署抽象:

分布式系统迁移Docker云

在这种部署/运行模型下,对应用做灰度升级非常方便,只需选择新版本的Docker镜像,reload待升级的Instance:

分布式系统迁移Docker云

既然可以将v1.0的实例reload成v2.0,当然也可以将v2.0的实例reload成v1.0。前者是升级,后者是回退。得益于Docker的镜像管理特性,应用在Gaia云中的升级与回退本质上是同类的操作。

扩缩容

按需弹性分配资源是云计算的核心理念,扩缩容自然成为云平台的标配特性之一。在Gaia云中,扩缩容一个应用非常方便,只需选择相应的Docker镜像与实例个数,rampup待扩缩容的Application:

分布式系统迁移Docker云

在实际运维中,Lhotse已经多次通过Gaia来扩容Runner,得益于Docker带来的快速部署/启动能力,可以轻松实现秒级扩容。

目前,尽管扩缩容过程是自动化执行的,但操作还需要人工进行触发。实际上,作为一个任务调度系统,Lhotse任务负载的时间分布实际上是有规律、可预估的(通过监控数据发现,有相当一部分Runner的任务负载都在某种程度上遵循着二八定律,即有20%的时间处于高峰期,承受成倍于其他时间的负载)。下面两图分别展示了两种Runner连续三天的任务负载分布,可以看到,负载高峰通常是在凌晨某个时段。

分布式系统迁移Docker云

分布式系统迁移Docker云

Lhotse Runner 100负载分布

因此,Lhotse扩缩容是可以基于时间/负载等因素来自动触发的。Gaia云根据业务系统的需求,正在规划自动扩缩容的方案,后续Lhotse将保持跟进,第一时间验证测试。

服务发现

从前文的架构图上可以看到,Lhotse内部最基本的通讯路径是——Runner向Base上报心跳。在静态分配资源时代,Runner通过配置文件写死IP来发现Base。这种方式在动态分配资源的Gaia云中显然是不可行的,需要新的服务发现机制。它要满足两个需求:

自动注册/更新地址——当服务实例发生迁移或者新的服务实例部署时,需要对地址列表做自动更新。

自动负载均衡——当有服务有多个实例时,需要自动将访问请求分配到某一个实例。

Gaia云为此采纳了基于“Etcd-Confd-HAProxy”的服务发现架构:Etcd作为服务地址的存储中心,HAProxy作为服务访问的代理(负载均衡)中心,Confd则是连接前两者的纽带,实现地址列表的自动更新(具体实现可以参考《构建一个高可用及自动发现的Docker基础架构-HECD》)。基于这种服务发现机制,Runner发现Base的过程如下图所示:

分布式系统迁移Docker云

总结

本文分享了Lhotse系统接入Gaia云,实现自动化运维的实践经验: 通过部署、调度、扩缩容自动化,释放了人工运维的压力;通过容错、灰度升级、服务发现自动化,避免了重复造轮子。

当然,天下没有免费的午餐,要享受Gaia云带来的自动化,对于老的系统可能会有一定的改造成本。比如,Lhotse在迁移过程中对代码做了全面梳理,把所有写死IP的代码做了改造。不过,Lhotse的经验表明,这样的系统改造基本不涉及关键模块(比如数据存储、组件通讯、任务执行等),工作量相对不大。另外值得一提的是,在接入过程中,Gaia云根据业务系统的特点不断地演进平台特性,尽可能地降低老系统的迁移成本。

作为第一个抵达风口的“猪”,Lhotse乘风而起,扶摇直上云端里,吹响了全民拥抱Docker云的号角,并且会继续探索前行,为大部队点灯开道。与此同时,我们也期望Gaia云持续优化完善,提供舒适的云环境,让我们沉浸其中、欲罢不能。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

大规模Web服务开发技术

大规模Web服务开发技术

伊藤直也、田中慎司 / 李剑 / 电子工业出版社 / 2011-7 / 59.00元

Hatena是日本最大的Web服务提供商之一,它提供的服务包括关键字(类似于维基百科)、博客、相册等。《大规模Web服务开发技术》由伊藤直也、田中慎司所著,内容主要来自Hatena为学生们举行的暑期实习的课程,内容涵盖广泛,介绍了性能优化、分布式、算法、系统架构等各个方面,甚至还介绍了硬件的经济成本,是运维工程师们必不可少的参考书。书中还包括几个算法实习课题,介绍了压缩算法、全文搜索等算法的实现方......一起来看看 《大规模Web服务开发技术》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

MD5 加密
MD5 加密

MD5 加密工具