在3月21日由OpenStack中国用户组主办的OpenStack Meetup活动上,UnitedStack运维团队负责人,同时也是OpenStack社区核心开发者的余兴超分享了多年运维OpenStack服务的经验和体会。本文根据余兴超演讲的部分内容整理而成,主要包含OpenStack在实际服务运维工作中所遇到的具体挑战,以及统一运维的具体策略。
持续集成(CI)和持续交付(CD)是OpenStack运维工程师们所面临的两大课题。其中,持续集成是保证整个研发团队的开发进度保持同步,其目的是消除由于集成问题引起的项目延期;持续集成的最后一公里是交付,所谓交付,也就是将代码最终部署到线上环境,转变成生产环境中提供服务的软件。
六大挑战困扰OpenStack持续运维
要实现持续集成和持续交付的目标对于UnitedStack的运维团队是一项异常艰巨的任务。具体说来,运维的挑战来自以下六个方面。
项目和服务众多的问题。这其中包含了Nova(计算)、Glance(镜像)、KeyStone(识别)、Neutron(网络)等常规的OpenStack的服务组件,也有UnitedStack内部开发的一系列服务,例如Placebo(面板)、Kiki(消息通知)、Ticket(计费)、Gringotts(API中间件 )等等。另外,还需要管理一系列的基础服务,例如消息队列、数据库、负载均衡、高可用软件等。
服务软件包的依赖复杂度。比方说,计算服务Nova的软件包的线上运营需要安装13个相关的Nova包、163个相关依赖包,同时还要升级9个相关的依赖包。大多数依赖包都有非常严格的版本要求。
配置文件和选择繁多。还是以Nova为例,仅Nova.conf就有835个配置选项,算上注释,大约有1700多行。
OpenStack灵活的架构带来的运维挑战。OpenStack可以将某些功能和后端驱动抽象为独立的Filter和Plugin。比方说,你可以选择用Nova-Network还是Neutron来构建SDN,可以选择用Ceph还是Sheepdog作为Cinder backend,还可以选择KVM还是Xen作为Nova-compute的Hypervisor。
私有Patch太多。事实上,UnitedStack的服务运维团队对于私有Patch的态度是非常谨慎的。我们会尽量把Patch提交到社区,即便未提交的社区,也会尽可能地不去破坏Patch的代码逻辑,即便不得不进行修改,也会尽可能地保持代码的可维护性。但即便如何,运维的难度依然很大,目前UnitedStack团队运维的很多服务的私有Patch都超过了100个,例如Keystone、Ceph和Neutron。
这些坑都趟过了,等着你的还有OpenStack各个项目版本频繁变更带来的运维陷阱。这也是由社区和我们自己的研发结构所决定的。大家都知道,每隔6个月,OpenStack社区的各个项目都会发布新的版本。UnitedStack的服务版本更新则穿插其间,过去的半年时间,我们每个月平均上线2.6个新项目。回顾UnitedStack过去32周的线上环境软件包版本的变更次数,我们发现,版本变更始在过去的半年多的时间里保持了相当高的变更频率,其中由两周的变更次数超过了70次。
“四个统一”实现运维自动化
越是复杂和多变的系统,就越需要统一的运维规范和框架。而这里说的统一是指统一的框架、统一的工具、统一的处理流程,以及统一的接口。
统一的框架
在UOS 1.0版本开发时,UnitedStack活力四射的工程师们开发了很多项目,编程语言也是多种多样,Java、Python、Ruby都有,持久化后端有的用SQL,有的用NoSQL,消息队列有的用RabbitMQ,有的用ZeroMQ。我们的运维团队很快就Hold不住这些大神们了。我们也曾经尝试过制定相关的开发规定,但是无法起到实际的约束作用。最后,还是由运维团队牵头,制定了名为BoneDragon的统一的开发框架。这一框架是用Python语言编写的,可以一键生成项目的基础开发框架,包含标准化的API模块、数据库模块和测试用例。BoneDragon框架已经开源,并且发布到GitHub上。
统一的工具
UnitedStack已经建立了一套由统一的工具构成的持续交付系统工作流程。统一的工具组由PSRForge(包管理系统)、Puppet(配置管理系统)、Ansible (任务编排系统)和Jenkins(自动构建系统)组成。它们覆盖的软件打包、任务编排上线、任务部署、部署验证任务的完整流程。
其中,包管理系统PSRForge是我们自行开发的,因为当时我们没有找到合适的开源项目。我们的团队目前维护着大概230个软件包。包管理系统共分为三个子系统,分别是Spec管理系统、软件包自动构建系统和软件仓库管理系统。
配置管理系统是OpenStack服务持续交付工具链的核心组件。在谨慎的调研和考量后,我们选择了Puppet作为配置管理工具。在此我想强调的是,没有任何一个工具是万能的,既然选择使用一个工具,运维团队必须清晰地明确它的能力和局限。拿Puppet来说,它非常适合做软件包的安装、配置文件的管理、服务状态的管理、命令的执行等;但它也有一些天然的短板,比方说不太适合做源代码的管理、依赖包的管理,也不太适合做服务的初始化操作、服务状态的监控和恢复,以及节点间的依赖管理。
因为Puppet缺少任务编排能力,因此我们一直在寻找一个工具,可以达到我们的期望。任务编排系统我们最终选择使用的是Ansible。在此之前,我们陆续使用过Dispatcher、ClusterShell和Mcollective 。其中,Dispatcher是我们基于SSH+ini配置文件自行编写的,后来我们发现开源项目ClusterShell同样是基于SSH,并且功能十分完善。后来我们转向Mcollective,这是Puppet Lab专门收购的一款配置管理工具,后来放弃Mcollective的主要原因是它的架构过重,同时是用Ruby语言编写的,而统一一直是我们追求的目标。Ansible目前在UnitedStack的运维效果我们是比较满意的,它的优势体现在无代理、基于yaml的配置文件,并且可用于集群的任务编排。
Jenkins是目前业内运用最为广泛的自动构建系统。目前,UnitedStack所有重复性的工作,比如执行单元测试、集成测试、构建软件包等工作必须以Jenkins的job形式出现,这样使得打包和测试工作自助化,也是我们实现自动化运维的前提。目前,UOS的各项目单元测试、UOS各项目打包、Doctor集成测试、UOS环境构建和清理已经全部在Jenkins平台完成。
统一的流程
在高速运转的持续交付流水线中,流程的统一举足轻重,这也就意味着流程的制定是非常关键的,要既合理,又尽量简单。目前,我们使用的流程包括软件包管理、线上服务变更、软件发布周期管理、部署逻辑代码提交、公共库变更等等。
我个人觉得非常值得分享的是我们的持续打磨的OpenStack跨大版本升级流程。我们是从2011年的Diablo版本开始接触OpenStack,期间经历了数次的大版本升级,至今已经总结出了相对成熟的大版本升级的具体流程。
在研发端,研发团队需要确认项目的upstream Base,也就是确认版本的合并点;然后,完成私有patch的合并工作;第三,给出依赖库的版本变更列表,放入requirements项目中;第四,给出配置选项的变更列表;第五,给出数据库schema的变更版本,以方便部署是的检查。
在部署端,我们首先需要更新SPEC、SOURCES文件,制作新版本软件包;然后更新puppet-xxx module,合并私有patch;接下来在开发环境上线进行调试,并且打上预发布版本号,在测试环境上线,同时需要通过集成测试。
线上的变更是需要特别谨慎的,稍有不慎就会有意外事件的发生。在版本最终上线前,开发团队需要给出线上业务变更单,说明业务变更内容,可能造成的影响,执行流程,回滚流程等;涉及公共库变更的,需要所有相关人员确认;业务的变更流程已预先制定完成,则必须借助工具自动执行。你只能与命令行工具做交互,输入Yes or No,但不能输入任何命令。
统一的接口
在UnitedStack,我们的自研项目和OpenStack项目都提供了统一的API,我们也有自己的命令行工具(UOS CLI)对一些资源操作进行封装和简化,这些前提使得我们的自动化测试工作变成可能。
以此为基础,我们构建起名为Doctor的健康检查服务。Doctor服务主要的功能包括,诊断UOS所有的服务是否正常;恢复UOS所有的服务至正常状态;收集UOS服务的错误日志和相关的系统信息。
下图是创建volume snapshot操作失败后的反馈,Doctor服务会描述操作的执行时间、执行过程、故障发生的步骤、服务的错误日志等,都会详细地展示并说明。
本文转载自infoQ
网友评论