本篇文章未经允许,不得转载! 内容未分级,有可能会对部分读者造成不适,还请谅解。
继续标题党,分享经历过的案例.
未满十八岁请在监护人陪同下阅读~~~如感不适,请立即停止,用大量清水冲洗面部!
选择合适的工具
自动化的方向由你决定,而不是工具
近些年出现了很多运维或辅助运维工具,不胜枚举。
没有能力,也不愿意去归类和定义每一种运维工具,这里只是简单的罗列下:
1 2 3 4 5 6 7 8 9 |
cfengine chef puppet saltstack ansible func capistrano fabric ... |
有人说puppet、chef已经过时,是老一代的运维工具。saltstack和ansible才是自动化的未来。
只能说每种工具都有它自己的设计理念和适用场景。确定你的自动化运维方式,选择合适的工具。
puppet的强项在于配置状态的管理,灵活方便的DSL。
saltstack和ansible在实时批量操作方面都比较好,描述能力方面差与puppet
puppet,ansible我们都在用,puppet更多用在部署语义描述上,当然也有小范围的服务使用它进行配置状态维护;ansible更多是在偏临时类批量操作上,非常喜欢ansible的部署和使用方式,特别在批量操作方面很像度厂的lh系列工具。
1 2 3 4 5 6 7 8 9 |
lh全名是List Hosts,2006年tony赵老板用perl写的运维工具 mysql存储线上机器名,使用lh获取机器列表。 lh *-im-*-* 获取im产品线下所有分类、所有机房、所有编号的机器,支持各种筛选条件。 lhck 本质上就是for x in `lh $1`,然后执行ssh $x $2,但没这个简单,需要处理各种符号、并发合并、颜色显示、异常处理等等。需要依赖信任关系,不然每台机器都要输入密码 lhscp 同上 这套工具现在还在用,结合服务树进行服务器列表的获取,方便ops进行批量操作;比较适合每个产品线内小范围批量运维时使用,如果要对度厂所有机器进行批量信息获取,权限和并发度就有些不太合适了 ansible是lh系列的合集,支持模板定义,支持更多的功能。不过缺少并发操作的结果合并排序,这个小意思,很好改。ansible在web管理端和DSL方面也是很不错的,但是这块我们基本不需要。 |
命令行实时操作类工具,我们正在做的是和权限系统结合,使用个人账号,去掉信任关系或者主机密码这种验证方式。同时,提供状态保持的功能。
向左向右的思考
任何运维工具/系统,在使用/设计时需要把握一个度,划分出边界
例子1:数据备份系统
备份系统负责备份每个产品线需要备份的数据,配置每份数据的级别,其中包括:保存时间、副本数、获取路径、权限等
能够每天记录备份数据的情况(数量、大小)和成功率,如果有备份失败的数据则报警发给运维人员进行检查;能够方便的进行备份数据获取和恢复。
设计的时候采用集中化的备份任务配置和管理方式,所有备份任务都集中在web端配置,由中心端定时触发agent执行数据备份任务,然后备份数据到hadoop上。
统一化的备份任务调度,管理产品线机器上的备份任务启动、数据压缩传输,甚至连如何dump数据都接管起来。过度集中化、边界过大带来的问题也出现了:
- 产品线运维人员的任何调整,都可能导致备份任务失败,但备份任务对于产品线运维基本上属于黑盒,他们很难去处理。
- 当备份任务多,每天备份任务失败数量多时,数据备份运维需要很多的1线人员,每天协助定位原因,联系产品线运维处理备份失败的任务。失败的原因很多。
- 备份调度任务中心化,还需要额外考虑单点故障,导致所有备份任务无法执行
- 需要在WEB端配置调度任务,当新模块部署,服务迁移/机器变更的时候,需要运维人员在web端修改,无法联动
- 每台机器上需要有agent执行备份任务,还好有noah-agent
集中化的想法是很好的,但需要把握一个合理的度,在满足目标的前提下做减法。过度集中化,边界过大会导致系统复杂度较高,而且前置条件也会较多。
数据备份系统的重点主要放在备份数据的完整性和安全性,提供可以交付数据的工具,对已交付数据负责。根据备份策略进行合理的压缩、多副本和旧数据清理,提供清晰的数据备份状态查询:
- 用户在数据备份系统申请一个key,使用传输工具将数据备份到数据备份系统中,具体怎么dump数据、是否压缩/加密、备份时间点由用户决定
- 每天会发送备份任务列表。备份任务成功率,更多由产品线运维人员负责,除非传输工具或存储系统故障。
- 备份系统web提供key申请,包括产品线(空间配额用)、备份副本数、备份周期等
- 备份系统web更多是一个展示平台,查看备份数据的详细情况,产品线备份空间使用情况。
- 由于缺少集中化的备份任务调度,有可能在同一时间有大量数据传输,导致系统负载过大或不可用。
例子2: CT
又是CT……这次不是CT设计的问题,而是如何合理使用的问题。
注: 如果不清楚CT是什么东东,请翻阅章节1
- 同一台机器上的多个任务,用CT配置一个一个串起来
就不能写个脚本包一下吗?
- 当监控采集系统使用,每5秒调度一次进行某个项的监控
要么是监控系统太难用了,要么就是用户太爱CT了。 -_-|||
- 当supervisor使用,每秒钟运行,当程序异常退出时自动将程序启动。
当监控采集用就忍了,居然当supervisor用,还需要CT支持启动单实例的需求……各种方式、各种工具都能解决这个需求,偏偏用CT……
带来的问题就是ct-slave升级困难,ct必须在一个没有任务运行的时间段,最短的时候自升级。在产品线运维来不及修改和KPI的压力下,运维研发同学们居然把这个问题解决了……
把CT拆分成调度层和执行层,任意一个层可以随便升级,通过socket通信进行状态同步。
例子3: handoff
handoff是08年郑同学开发的一个运维工具,基于netfilter做的一个流量切换工具。
主要的应用场景是上游连接下游服务器,当下游服务器出现异常后,上游能够再不修改应用配置的情况下,通过系统层的IP地址重定向功能,将流量切到下游备份服务器上。
思路和设计很不错,在一些单点或跨部门服务调用上,的确起了很大的帮助。但是需要考虑的东西也很多:
- 上游连接多个下游,经常的流量切换,连运维人员也不知道具体流量切到那里
当然可以通过工具提供的接口,查询出发生切换的IP
- 需要对后端的主机和多个备机进行状态监控,保证切换能够提供正常服务的IP上
- 对于主机的监控是否需要支持语义级别的,而不是简单的ICMP或端口监控
- 上游连接多个下游时,上百条配置规则,下游服务调整(IP变更、服务上下线)都需要通知上游修改handoff hostlist配置
关联关系管理
随着服务的业务逻辑越来越多,服务之间呈现网状结构,关联关系复杂。
服务迁移、IP变更、文件改名、端口调整等等,都会引起上下游的服务的各种异常和报警。
如何能够清晰直观的管理服务之间的关联关系,方便服务调整、监控联动和问题排查,一直是运维工程师希望解决的第2大难题。
第1版
大概在7年前,大家的思路是一个WEB平台,人工记录服务直接的关系,然后能够很好的展现和查询:
- 服务之间的关联特别多,有数据的传输,socket访问等等
- 记录的最小粒度和维度是什么:
- 一个服务开放端口对外提供服务
- 同时有脚本将N个数据文件传输或生成到改服务的data目录下,供服务实时加载
- 一台主机上有多个服务
- 该台机器上有定时的crontab任务
- 该台提供ftp服务,供日志下载
- 是否区分飞线箭头方向
第1版关联关系管理系统,在匆忙中完成了,后续的问题也来了:
- 维度和粒度没明确,运维人员在WEB记录的时候,记录机器、服务、文件,机器又包含服务,服务又包含文件。自动绘制出来的关联关系图简直没办法看
- 服务变更太频繁,运维人员靠自觉性的方式去记录。好不容易整理完当前的关联关系,没过几周,已经与线上真实环境脱节
- 粒度和维度记录不统一,导致入库的数据也无法提供第三方系统使用
没过多久,这个系统就废掉了。
第2版
总结失败经验,靠人记录的方式是不可靠的,那就被动采集吧。
- 读取系统日志,分析scp和ftp日志,获取数据传输的关系
- 遍历部署的服务配置文件,得到上下游连接的IP,获得服务通信关系
感觉还不错,可是还是有很多问题:
- 信息相对比较全了,但这些信息只能用于人员查看,无法做为自动化调度的基础,杂音太多。
- 服务类型比较多,配置文件和格式五花八门,解析配置难度比较大
- 是记录历史上发生过的关联关系,但做减法很难。比如:有一个每周wget一次的数据和一次人工操作获取过的数据日志,这2条关系怎么记录? 定时清理?定时多长时间?
- 只知道A->B机器有数据传输,但无法对应到具体服务之间的关系
- 时效性较差
这样的关联关系管理,费时费力,数据仅仅只能供人去看,无法提供给第三方系统使用
第3版
关联关系简化一下,数据关系和通信关系,所有服务采用pub/sub的方式,这样可以在中心端获取服务之间的关系。
通信关系:
采用类似zookeeper、doozerd、etcd或confd这样的东东,做配置集中化管理,资源定位。
- 一个树状的服务接口,A服务启动后注册到com.xxx.yyy.A节点,B服务启动后注册到com.xxx.yyy.B节点
- A服务订阅B服务节点,当节点发生变更后,推送或拉取的方式获取最新的B服务所在IP:PORT
数据关系:
- 提供一个订阅中心,A任务/服务生产完数据注册到com.data.xyz123,B任务/服务订阅com.data.xyz123
- 当数据更新了,B任务通过拉取方式获取数据
- 如果要记录 任务A->数据->任务B 这样的关系,还需要做一些额外工作
- 不过数据获存储和权限等方面变的麻烦起来,需要考虑A任务任意迁移服务器对B任务透明
上下游的服务变更变的透明起来;程序配置也简单起来,至少不用写很多上下游IP地址。
其实很多公司都是这么做的,似乎有解了。不过改造和推行成本很大,需要提供很多语言版本的基础库。
但是否好用、够用,只有经历过的同学才深有体会。
配置管理也是如此,人工记录,流程保证? 外挂式采集,过滤分析? 集中式pub/sub,框架限制? 或者其他…..
PS:如果有人说,我要做ITIL,我要做ITIL配置管理,我要把程序的配置文件管理起来。 我只能心中默默的念道:我去年买了个表~~
13 Comments
占个座
做的很细,思路很好,谢谢分享。学习了!
有点东西出来了,加油!
#O V5
配置管理 DSL 边界 关联关系
话说程序的配置文件谁来管?
最好让研发自己解决,哈哈
哈哈,这不行啊,回避问题了啊!
这个不是吐槽……只是把经历过的,或者说踩过的坑、走过的弯路分享给大家而已。
数据备份、cron jobs、关联关系管理貌似还是没有万金油的通用方案,只能利用各种封装的个性化工具维持。。
请教关联关系管理第三版的问题,
•A服务订阅B服务节点,这一步是需要如何实现?
这些订阅关系的形成如何能避免第一版的手工缺陷和第二版的被动采集缺陷?
实现方式很多种,最简单的方式A服务配置B节点名称,定期查询,或者采用zk支持B节点变更消息推送的功能。
因为注册和查询都在中心端,可以知道到有哪些节点订阅过B服务
正痛苦的经历着……
好多方面啊。值得学习
以前我们做过一个基于syslog-ng的监测系统,
好处就是支持转发,snmp不会跨网。
最后卖给甲方了
一个一线工程师运维自动化的的血路历程啊