NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

稳定性保障一号位的进击之旅

作者: |   17 浏览  | 

每个公司大概都有一个“稳定性保障一号位”,在不断翻车中持续进击。

当技术手段不足以提供确定性解法的时候,一般就需要祭出“压实主体责任”这最后的一招了,充分调动每个人在组织中的能动性,以达成目标。而设置“一号位”通常是压实主体责任的第一环。

在 IT 领域,稳定性保障一直属于最不具备“确定性解法”的 topic,防不胜防,大家的解法也是五花八门,你有你的张良计,我有我的过墙梯。奈何常在河边走,哪能不湿鞋。打脸来的太快,这怕是对负责稳定性保障的技术人心态的最好写照了。

此外,稳定性保障工作,低频、高危。平时不显山露水,但是一旦发生大故障,一号位首当其冲,如果功夫没有做在平时,那就是被架在火上烤,在接下来的稳定性整改运动中,基本可以引咎辞职了。

稳定性 case 的影响可大可小,对应的责任也可大可小,取决于:

1. 承载的业务的重要性
2. 故障时刻的损失程度
2. 舆论的传播面
3. 品牌的影响度
4. 法律法规和监管的要求
5. 公司管理制度的要求

因此,随着以上几个因素的不断变化,公司在某个阶段,对稳定性保障提出更高的要求,对一号位的要求也会有不同。但总体而言,一号位的职责总结如下。

## 稳定性一号位的职责是什么

1. 承担责任

也俗称“背锅”,稳定性既然是技术领域的重要工作,对业务产生着重大影响,那么结果不符合预期,一号位需要承担责任,这是完全说得通的,有压力才有动力。但承担责任不是目的,核心还是通过一号位的机制,将整个稳定性保障工作体系化的规划起来。

2. 制定合理的目标并确保目标可被分解和量化,让所有人参与进来

目标是否合理,体现在两个方面,一是稳定性目标是否和业务效果紧密挂钩,IT 系统是否稳定,是由其承载的业务是否正常来决定的,唯有如此,才能真正体现IT系统赋能业务支撑业务的本质价值,避免自嗨式目标、听不懂的目标;二是系统的稳定性,够用就好,目标过高,投入产出不成正比,要知道目标过高,每前进一小步,所花费的人力物力时间成本,会呈数量级放大。

目标设置不合理,首先是对自己的业务、IT 现状认识不全面,没有深入去思考,其次是盲目攀比,听闻坊间传说几个9,就随手拍脑袋,比他再高一个点!关于稳定性目标,可以延伸阅读[《服务稳定性保障的五大误解》](https://mp.weixin.qq.com/s/G8W2cqVKqT2AlZxWWXU0Rw)。

承担责任,也是一个技术活,要讲究方式方法,不是死扛硬抗,个人英雄主义。制定了目标,要有机制拆解到 IT 系统的各个技术参与方并且清晰的量化,确保参与方都能使上劲。具体可以参考[《SLO新解,一种行之有效的故障处理方法》](https://mp.weixin.qq.com/s/dA-7o-7wv0x24pDf0TXJag)。

3、确定预算

撇开成本谈保障工作,属于无源之水无本之木。稳定性保障一号位,在定好目标之后,接下来就是要确定和锁定预算。预算不单纯指直接负责稳定性保障任务的 headcount,也包括公司对于资源使用率要求、架构升级专项任务的预算、行业先进工具引入的费用预算、业务研发团队在稳定性工作上的参与度等等。

在一个大的组织,在年度预算开启前,确定好上面这些工作,是非常有挑战和考验稳定性保障一号位的综合能力。

4、建立技术保障体系

实际上是通过建立工具体系,做好两个事情:
- 不断提高稳定性保障的“确定性”:
>> 提高确定性的过程,就是不断兑现承诺、提升信心的过程,比如稳定性保障团队是否能在业务和用户感知之前发现问题,是否能给出故障解决的预期时间,能快速准确的评估故障的影响面,有行之有效的故障止损预案等。
- 不断降低稳定性保障工作的“门槛”:
>>要承认,现阶段处理故障,对工程师的经验要求太高了,既要有扎实的 troubleshooting 的能力,有强大的抗压能力,对各种工具平台熟练使用,还要对整体系统的架构、细节都非常熟悉,这就决定了这样富有经验的工程师总是很稀缺,难以批量培养,甚至于一旦离职或者转岗,容易出现青黄不接的现象。那么能不能把这些经验形成方法论,沉淀到工具中,形成套路,降低门槛就显得至关重要。

当然,随着微服务和云原生架构的更多采用,带来敏捷和高效的同时,使得整个IT系统的复杂度成数量级的上升,这与我们所追求的“确定性”、“低门槛”背道而驰。

1. 系统越来越复杂,以至于无法清晰的定义什么是真的故障,无法定义,那就更谈不上准确、及时的发现故障了,稳定性保障工作,直接输在了起跑线;
2. 数据量越来越大,信息过载的问题变得格外突出,技术团队在有限的时间里,无法有效、准确的提取关键信息,导致贻误战机,造成巨大的业务损失;
3. 稳定性保障,在整个行业范围,缺乏有效的方法论沉淀和产品化抽象,导致故障处理的各个环节,高度依赖工程师个体的经验,不具备复制性,难以持续改进,俗话讲,缺乏套路,门槛太高;

所以,如何通过技术手段,结合数据、流程,形成一套行之有效的稳定性保障打法,应对上面的挑战,所有的一号位共勉。

十年前,我从毕业到百度、小米、滴滴,从保障一个服务、到保障一个业务、再到保障全平台,scope 在变化,但是职责未变、初心未改。直到今天创立快猫星云,仍然是希望通过打造最好的Flashcat平台,为整个行业做出力所能及的贡献。

如果你有观点和解法,欢迎添加我的微信 laiweivic 探讨交流。

关于快猫星云

快猫星云,一家云原生智能运维科技公司,秉承着让监控分析变简单的初心和使命,致力于打造先进的云原生监控分析平台,结合人工智能技术,提升云原生时代数字化服务的稳定性保障能力。

快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。夜莺监控是一款开源云原生监控分析系统,采用 All-In-One 的设计,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力,已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

夜莺监控,由滴滴开发和开源,并于 2022 年 5 月 11 日,捐赠予中国计算机学会开源发展委员会(CCF ODC),为 CCF ODC 成立后接受捐赠的第一个开源项目。

快猫星云产品介绍

- 一分钟视频介绍: https://flashcat.cloud/videos/flashcat.mp4
- Flashcat平台PPT: https://sourl.cn/G5iZCT
- Flashcat官网:https://flashcat.cloud
- 在线体验demo: http://demo.flashcat.cloud

服务挂了,学费交了,掌握这6点就值了!

作者: |   22 浏览  | 

办公区里此起彼伏的短信声、手机铃声,IM群里铺天盖地的消息,人人都在问,什么情况?服务挂了吗?有没有人在上线?。。这是在线服务挂了的日常一幕。

目前没有哪家企业敢承诺自己的服务肯定不会宕机,强如谷歌、亚马逊、微软的服务也不时有宕机的新闻传出。服务稳定性保障是一个系统而复杂的工程,有越来越多的技术关注在这个领域,以期提高稳定性保障工作的确定性。

对于做稳定性保障的同学来说,在众多稳定性保障方案和技术的选择中,不但要选对,更要避免选错用错,避免做无用功甚至适得其反。查理芒格说,如果知道我会死在哪里,我将永远不会去那个地方。今天就来聊聊那些稳定性保障工作可能的死亡地带,以资参考,如有谬误欢迎交流指正。

① 把日常排障和故障处理混为一谈

日常排障和故障处理是两个非常相似其实又有巨大区别的场景。但在谈到方案时很多人往往对它们不加区分,认为自己所用的方案和技术在这两个场景里是通用的(当然更有可能是没有意识到这是两个场景)。

这两个场景有什么区别呢?

最大的区别就在于日常排障是一个非紧急,以追查技术上的根因为主要目标的场景,而故障处理则是一个紧急,以服务的快速止损为主要目标的场景。

典型的日常排障,如追查个别用户请求失败的原因、追查某个模块响应时间变长的原因、追查个别程序实例崩溃的原因等等,这些异常以不影响全局的个例和局部问题为主。可能通过trace、通过程序堆栈分析、通过火焰图、通过代码分析等手段,最后查出是某个程序的代码bug,或某个机器的硬件性能问题等。

而服务故障则表现为相当比例的用户无法正常使用服务、大面积的服务宕机。这个场景里要追求的是服务的尽快止损恢复,需要争分夺秒,越快越好。要做到这一点,就不能按日常排障的思路来了。首先要做的是故障的特征分析和事件分析,基于特征和事件来确定一个止损方案,比如流量调度、比如重启服务、比如回滚上线、比如扩容、比如降级、比如摘除异常实例等等。这些操作都不必知道根因就可以执行,而且只要故障特征或关键事件对症,止损效果会立马显现。

当然,也存在这样的case,在故障中这些手段都用尽了仍然起不到止损的效果,这时候就不得不去深入排查技术上的根因,但这应该是最后不得以而为之。而且一旦走到这一步通常大事故已经酿成。

其实在稳定性保障中,日常排障和巡检一样,都属于故障预防,可以避免小问题和隐患引发事故。而故障处理则处在稳定性保障中最紧迫的位置。如果一开始就按日常排障的思路去做故障处理,那就好比医生用保健品来挽救将死的病人,药可能有用,但时间等不起。

基于这样的差异,日常排障更多的是关注在个别请求个别实例这样的点上,而故障处理则需要更多的从全局从面上去分析故障的特征和关键事件。

这两个场景可以共用的工具和方法很多,主要是不能把它们的优先级用反了。

更重要的是,当大家都把注意力聚集在排障和根因上时,是不是更应该想想,如何从全局上对故障的特征分析和事件分析做一些事情?

② 预案过多

想要抢在故障升级前恢复服务,确定了故障的特征或关键事件后就需要有预案来应对。但问题也在于有些服务的预案可能过多了,真到要用时可能不知道该用哪一个,光决策就花去很长时间,而终于选中一个却又执行不成功。

这个问题的关键可能在于缺乏预案建设的核心思路,只是漫无目的的打补丁。

我印象最深刻的预案是一招鲜:多活切流,以及围绕这个核心预案所做的预案集合。

这个预案集合的建设思路是:

要让多活切流能发挥作用,就必须控制所有异常的出现都是局部性的,不能所有多活单元里同时出现异常;
要做到第1点,首先要做好的就是变更和线上操作的灰度控制和灰度策略。而像机器/容器异常、网络异常,这些天然就是大概率出现在局部,不会多个单元同时出现;
再有,要让多活切流能够随时操作,还要保障好单元间的n+1资源冗余,以便切流时不至于容量不足;
为了平衡n+1的资源冗余和成本,就要做好服务降级,以便可以降低冗余,如果切流操作需要发生在高峰期,就可以先降级后切流;
以上工作做好,基本上80%以上的故障都可以在早期得到快速止损,不至于升级为大事故。

这个预案建设有几个重要特点:

核心预案(多活切流)操作简便、生效快;
思路和原则清晰,既有利于预案建设和维护,又有利于决策执行,甚至可以做到自动执行;
当然,不同服务的情况要具体分析,比如有的业务多活都没有,或多活建设很困难,不敢随时切流,那就需要另辟思路了。核心是要有核心预案和主线思路,那种预案建到哪算哪,像给服务不停打补丁的方案,迟早兜不住。

③ 用报警的多少来感知服务的异常和严重程度

老司机们也许会会心一笑,曾几何时,甚至是现在,有多少团队还是靠这个来发现服务故障的?

这个做法的问题显而易见,要么容易遗漏重要的报警,要么容易遗漏导致事故的隐患。这种模式也只有天天浸淫在某个服务中的老司机能够勉强玩转,因为他们可能瞄一眼就知道每个报警的轻重,但一旦换人立马玩完。

有两种方法解决这个问题,一个是研发或直接引入一个报警降噪的事件中心。另一个是要从海量的指标和报警中抽象出北极星指标,让大家的注意力首先集中在少量的关键指标上,具体做法历史文章中有介绍 SLO新解,一种行之有效的故障处理方法

两种方法同时使用当然最好。

④ 执迷于依赖关联关系来做故障定位

这是一个长期以来被持续追求,却又收效甚微的方向。

分析起来可能的原因有二:

在现有的基础技术上,服务的关联关系获取和更新难度都很高,也缺少打通各个环节的命名规范;
这个事情可能陷入了一个悖论:服务复杂才需要这样的关联信息来做问题定位,但复杂的服务真画出关联往往是一团乱麻,而不是一颗清晰的树。而如果服务比较简单,那其实也都用不着把它的关联画出来了;
我愿意相信这个方向能有走出悖论真正开花结果的一天,但如果一个服务着急解决眼前的问题,这个方向可能一时半会还帮不上大忙。

⑤ 把宝都押在智能化上

自从AlphaGo打败李世石以来,大家就开始期待智能化能够推动运维领域的变革。但目前为止业界在AI智能运维方向上,还鲜有有说服力的案例。针对时序数据趋势的智能预测和异常检测,大概可以算是比较接近智能化的一个实现。

在服务稳定性保障上,大家期望智能化能够解决的最大问题是智能定位问题(虽然和前面的问题一样,要定位个什么结果出来大家未必想得足够明白),这个方向已有无数的尝试和努力。

但要实现智能化,一个很重要的前提是输入数据的正确性和标准化。而目前基础设施参差不齐、运维报警全凭手动配置,80%、90%的报警可能都是误报。想要在这样的基础上产生智能,大概跟要在垃圾堆里挖出矿来差不多。

我也愿意相信这个方向会迎来真正变革的一天,但短期内不能寄予过高的期望,至少不能把解决问题的重心都押在这上面。

⑥ 过于依赖个人能力

能够在故障处理中从容应对,在别人还没反应过来的时候就把故障解决了的老员工是企业的宝贝。

但问题是这个宝贝不会一直留住在一个岗位上(离职/转岗/升职/休假。。)。

不知道是不是幸存者偏差,据笔者多年的观察,一个核心技术人员的离岗,通常意味着紧接而来的一场大事故。这个准确率简直比天气预报准多了!

原因其实也很明显,这个岗位所需的各种信息、各种服务定位止损经验都存在这个员工的脑子甚至是肌肉记忆里,别人无法复制或在短时间内重建这些信息。当老员工离开时,如果这个岗位不能把他的经验留下,那很不幸,这个服务很高概率要靠一场事故来重建保障体系。

所以,有没有办法把一个老员工的经验留下,融入到这个服务里,或者让新来的人能无缝获取?

这个工作似乎很有挑战,但却很值得尝试。现在有一些产品能够预置故障处理的最佳实践,并将老司机的经验通过配置的方式沉淀到产品中,让这个经验可复制。也许智能化真正到来之前,这是更值得探索的方向。

关于快猫星云

快猫星云,一家云原生智能运维科技公司,秉承着让监控分析变简单的初心和使命,致力于打造先进的云原生监控分析平台,结合人工智能技术,提升云原生时代数字化服务的稳定性保障能力。

快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。夜莺监控是一款开源云原生监控分析系统,采用 All-In-One 的设计,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力,已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

夜莺监控,由滴滴开发和开源,并于 2022 年 5 月 11 日,捐赠予中国计算机学会开源发展委员会(CCF ODC),为 CCF ODC 成立后接受捐赠的第一个开源项目。

快猫星云产品介绍

- 一分钟视频介绍: https://flashcat.cloud/videos/flashcat.mp4
- Flashcat平台PPT: https://sourl.cn/G5iZCT
- Flashcat官网:https://flashcat.cloud
- 在线体验demo: http://demo.flashcat.cloud

alternative 命令学习与多版本 jdk 安装

作者: |   2,601 浏览  | 

alternative 命令用于管理系统上多个提供相同功能的软件包。如 jre mta editor 等。

当系统中有多个 editor 软件安装时,alternative 系统指定其中一套软件(包括相应的 man page)供用户使用。
如 editor 我们有vim nano gedit ed 等可供选择,相应地,有对应的 man page
下文我们将通过实际安装一个 alternative 命令来体会该命令的强大之处。

alternative 命令

该命令需要root 权限运行

看起来 –install 分支较为复杂一些,其他分支看名字就能猜出意思来。

首先,我们想看一下目前系统中安装了哪些 alternatives, 不过遗憾的是,该命令没有 –list 参数。
通过man alternatives,发现系统安装的 alternatives 都在 /var/lib/alternatives/ 下面。检查一下,发现里面有三个文本文件

看起来系统安装了这三个 alternatives
我们来看看links 到底是什么

看起来,links 指向了 /usr/bin/elinks
检查一下,确实是这样的。

下面我们将安装一个叫 editor 的alternative。 editor命令放在 /usr/local/bin/ 下面

这时运行 /usr/local/bin/editor  就可以直接打开 vim 了

但是看起来man page仍然不生效

我们通过安装 slave alternatives 来解决这个问题

试试 man editor

大功告成
当然,我们也可以安装另一个 editor 的候选并设置一个较低的优先级。

在机器上用RPM 装多个版本的JDK

从上面的页面下载所需版本的jdk
对于jdk6,需要先解开bin包,再安装里面的所有rpm包。
会得到一个jdk的包和很多sun-javadb-*的包
将这些包都传到yum repo,然后更新repo索引。
在机器上运行:
就可以看到传到yum repo上的所有jdk版本

见图

5291ead1-b43b-4806-be47-6c3c7fbfb8d8

从jdk1.8起,包的命名方式竟然改了。
把jdk 1.6 1.7 1.8都装上
检查 java 链接

看起来这个链接不属于任何包。

我们安装之前学习的 alternatives 来管理多个版本的jdk
我们以jdk为名字来管理上面的java/javac/javadoc/javaws/…的链接

看起来版本已经是正确的了
然后,再更新下相关联的j* 程序的链接
看起来下面的包都需要做一下alternatives 链接

用一个脚本解决:

上面的脚本同时解决了 JAVA_HOME 环境变量的配置。

这应该就是安装多版本JDK的正确姿势了。

PS: 根据实际的安装经验,jdk1.8的RPM已经自行安装 alternatives,不需要运行上面的脚本了。

参考:

http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7-on-fedora-centos-red-hat-rhel/

noops.me

作者: |   5,064 浏览  | 

0a1fe77d2a09953c14e6620031ff2d89

9ae23f43209694f7ab60cca12a4bc656

cbbe903d5acfd20d92110acf4157eb9a

No Ops

我们团队对外的博客是NoOps.me,我们的运维理念是:Ops Make No Ops,希望把运维的日常工作尽可能的自动化起来,减少手工运维操作。做为一个运维人员,没有人愿意每天重复那些繁琐的运维操作;更没有人愿意每天处于高度紧张的精神状态,随时准备应对线上故障。

我们的目标是打造一个技术型、学习型的团队,通过新技术的研究,学习分享提升整个团队的技术影响力,使我们的运维工作更加高效。提供类似SaaS、DaaS、PaaS、IaaS的服务,一层层的向上封装。最终使研发人员能够在运维体系的架构下自助的进行资源申请、服务部署、运行监控和容灾备份,提供稳定、高效和安全的互联网服务。使我们的运维人员能有更多的精力参与到运维自动化体系的建设中,能有更多的精力投入到业务架构设计和性能优化中。

研发能力

做为运维人员,首要的任务是保证服务稳定高效的运行,7*24为用户提供互联网服务。由于互联网业务的特点,往往是研发周期短、功能不断迭代、文档不全、规模发展快速。那么对于运维人员在技能方面就有很高的要求,除过操作系统、网络、硬件、开源软件应用等基础要求外,还需要强调运维人员的研发能力。

一方面,运维人员具备研发能力可以快速上手研发人员交付的线上服务。充分理解程序的功能逻辑,才能提前发现隐患,给出合理的运维建议。在优化方面才能有的放矢,而不是查找网上资料,按照前人经验不断的调“试”。我们甚至希望每位运维工程都是产品架构师,能够对业务服务的系统架构进行合理性规划和改进。

另一方面,运维人员具备研发能力也能更直接有效的把运维经验形成工具和平台,更有效的推进服务运维的自动化。在运维人员,特别是应用运维人员招聘中,我们更关注是否具备研发能力。国内很多从事互联网运维的人员在研发能力方面都相对薄弱,大多属于操作维护类。所以在某国内大型互联网公司中,运维部中校招人员占比90%,招聘最基本的要求就是具备研发能力、掌握至少一种脚本语言,熟悉数据结构。另外做为运维人员,除了考虑研发能力和知识全面性之外,我们还会重点关注动手能力。

和一些公司的运维团队不同,我们虽然也有运维平台研发团队,但更多的工具和平台研发工作是由运维人员负责。专职的平台研发人员很多没有接触过运维,不清楚运维人员真正的需求和痛点,通用的平台不能满足所有运维人员的需求,专项的平台又很难在需求功能上达到平衡。以前经常遇到平台研发和运维相互指责的情况,平台研发认为运维不配合他们的工作,运维认为平台研发不懂运维需求。

我们的平台研发团队主要负责最基础的核心功能和UI研发,运维人员参与需求收集和设计评审,比如服务管理平台的服务树和权限的需求讨论和模型设计。而运维人员负责监控系统、部署系统、环境初始化以及各种的日常运维工具的研发。拿部署系统举例,运维人员负责了build模块、客户端、控制端的研发工作,平台研发人员负责Web界面的研发。

平台研发理念

如运维平台章节介绍的那样,我们在运维平台的设计中,提供各种API接口给运维或研发人员使用,他们根据自己的运维场景封装成个性化的工具或平台。以前涉及到服务器装机、改名、重启等操作都需要系统工程师负责,应用运维工程师发单让系统工程师操作。系统工程师将这部分工作形成自动化,提供API给服务管理平台。服务管理平台基于服务树和权限模型,提供给应用运维工程师使用,应用运维工程师能够对有权限的服务器进行一系列基础操作。渐渐的应用运维工程师将这部分权限开放给研发人员,研发人员也可以使用。同理,对于服务器资源申请、模块部署、监控添加都交给研发人员去使用。

运维人员除了平台研发和维护外,能够将精力放到其他更重要的事情上,避免了繁琐的沟通,工作效率也提升了。Hadoop研发人员使用资产信息提供的API,服务器的分布、交换机的参数、机柜的分布,能够更方便的调度和决策数据如何存储,避免由于机柜级别故障导致的服务受损。部署系统使用监控系统提供的API进行运行状态查询和监控项添加,在每台服务器部署前暂停监控,部署完成后启动服务、更新监控,判断监控正常后继续下一台部署工作,做到部署动作与监控状态的联动。

学习与分享

我们需要具备研发能力的优秀运维人员来帮助业务提升稳定性,但优秀的人才都不愿长期从事繁琐的操作类事务,不仅需要给予他们研发项目提升技术能力,也需要给予他们“有趣的事情”,研究新的技术。在工作时间上,尽量给员工买时间、投资源,在不影响业务稳定的前提下,投入20%~40%在项目研发和新技术研究上。

比如Https网站的SSL运算会消耗大量的CPU资源,工程师在经过研究后提出了采用类GPU的方式,用硬件加速卡来进行RSA运算,同时又对Nginx进行代码优化充分发挥硬件加速卡的性能,提升了服务质量还降低了资源成本。这样做的目的不仅能使我们的运维工作越来越出色,还能帮助我们看清未来的方向。比如虚拟化、Docker的研究帮助我们更好的进行服务部署,对大数据的研究帮助我们识别网络4/7层攻击行为。

我们鼓励工程师多学习、多交流,也希望团队是一个开放型的团队,能够把我们遇到的问题,好的经验分享出来,帮助个人、帮助团队、帮助行业共同成长,这也是我们写这本书的目的。

开源软件使用

在开源运维软件方面,我们保持着跟随不盲目的心态。任何一款开源软件,我们必须做到掌握到代码级别的能力,和运维公司内部的产品一样,不仅能很好的使用开源软件,还能够动手分析和解决遇到的问题。不重复造轮子,但对开源软件的使用,也要清楚认识我们使用它的场景。

我们使用了Puppet、Ansible、Zabbix、God、Docker、Mesos、Etcd等等,Puppet在部署工具的第一版,我们仅仅用它的DSL做部署行为的语法解析和执行,并没用到它的客户端和服务端配置管理功能。有服务管理平台提供的服务树和权限模型,不需要再单独维护Puppet的服务器列表。

Ansible主要使用它对服务器进行临时性的批量操作执行。我们每台服务器上已经有一个超级Agent,不希望引入太多有执行逻辑的Agent,所以我们选择使用Ansible和SSHD进行交互。同时,我们改造Ansible和服务树结合,工程师可以使用个人帐号很方便的对有权限的服务器,进行临时批量的任务执行。

Etcd主要用来做LVS的Real Server注册,Real Server上新增Nginx启动后往Etcd注册状态,LVS实时读取列表更新本机的配置文件并Reload。

监控最早也是使用Zabbix,和服务树结合进行监控和报警策略的管理,随后由于开源监控系统无法满足需求,才开始研发自己的监控系统。

小结

最后,真的很痛恨Operator这个称呼,我们目标是提供各种运维自动化平台或工具,让研发自助式的完成产品运行发布所需要的各种动作,No Ops!

小米监控系统开源

作者: |   9,494 浏览  | 

详细请移步: http://open-falcon.com/
github地址:https://github.com/xiaomi/open-falcon

Highlights and features

  • 数据采集免配置:agent自发现、支持Plugin、主动推送模式
  • 容量水平扩展:生产环境每秒50万次数据收集、告警、存储、绘图,可持续水平扩展。
  • 告警策略自发现:Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动作。
  • 告警设置人性化:支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期,支持告警合并。
  • 历史数据高效查询:秒级返回上百个指标一年的历史数据。
  • Dashboard人性化:多维度的数据展示,用户自定义Dashboard等功能。
  • 架构设计高可用:整个系统无核心单点,易运维,易部署。

SSD阵列卡方案优化:考虑使用RAID 50替代RAID 10

作者: |   11,922 浏览  | 

大家都知道SSD成本比较高,而不少用户在考虑可用性时都会选用RAID 10作阵列,这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本,因此最近一直在研究性价比更高的RAID 50,它提供了接近RAID 10的可用性并且接近RAID 5的成本,像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。

 

为了能够直观了解不同RAID类型下的故障可用性,我们首先做个简单的可用性分析(以8盘RAID 10的同等容量作对比):

RAID 50中:4块盘组成单组RAID 5,然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50

ssd_r50_r10_01b

案例分析:

  • 第1块盘的容错概率都是100%,可见磁盘阵列最基本的能力就是容错,然而不同级别的阵列能够提供的数据保护能力也是不同的;
  • 从第2块盘开始除了RAID 6能够提供100%的故障可用性以外,其他包括RAID 10在内都不能提供完美的解决方案。同时我们可以发现RAID 5的容错能力是四者中最差的,但是要达到同样容量所需要的盘数量也是最少的,如果故障运维较为及时的话RAID 5是一个性价比较高的方案,不然在第一块盘故障后至阵列修复期间如果发生第二块盘故障就会导整个阵列故障(数据全部丢失),这就是风险所在;
  • RAID 6当然是较为可靠的方案,但是它要牺牲两块盘的容量并且性能也较差(后面有性能测试说明),所以要权衡性能和可用性;
  • 当然重点还是RAID 10和50:我们发现50在第二块盘故障时的可用概率和10比较接近,由于上述案例中只有两组RAID 5因此只能提供至最多两块盘的容错,如果RAID 5的组数量更多的话能够容错的盘数也将更多,且可用概率也会更高。

我们以9块盘RAID 50(3组RAID 5)为例作分析(达到相同容量的RAID 10需要12块盘):

ssd_r50_r10_02

再以12块盘RAID 50(4组RAID 5)为例作分析(达到相同容量的RAID 10需要16块盘):

ssd_r50_r10_03
上面对比中RAID  50已经能够容忍第3甚至第4块盘的故障,只是可用性相比RAID 10低了些,但是两者都不能达到完美的100%,所以权衡可用性和成本RAID 50还是有相当大的优势。

 

接下来看看性能,为了能够很好地分析性能,我们沿用了第一组对比方案的作性能分析:

ssd_r50_r10_04

 随机读分析:

  • 理论上认为R10性能最好,真实测试数据显示4K、8K数据块下R5、R50、R6的性能都要优于R10;
  • 当数据块增大到16K、32K时,R10的多盘优势才被逐渐体现出来。

随机写分析:

  • 4K由于R50、R5由于有大量校验计算一定程度上影响了性能,但随着数据块逐渐增大,盘数量的优势也显现出来。当数据块达到和超过8K时,R50性能全面超越了R10;
  • R10由于存在R1的写同步问题,因此只有4块盘在支撑并发写,随着数据块的增大,R50和R5的多盘性能优势开始发挥。

混合随机读写分析:

  • 得益多盘和无校验计算,混合读写R10领先;R50其次,和R10相差27%,性能也较为接近,R5和R50性能为线性关系,R6性能最差。

顺序读分析:

  • 由于不存在校验计算,顺序读性能基本上由盘的数量决定;R50和R10性能也较为接近,同盘数的R6和R50性能相当,而盘数较少的R5性能相对前三者要弱一些,符合预期。至于为何R10性能无法线性增加,主要是因为阵列卡本身的性能限制。

顺序写分析:

  • 顺序写R5被优化得最好;R50由于需要同时计算两次校验因此损失了一些性能,和R10性能相当,当数据块达到512K时,多盘优势进一步体现出来了,拉开了与R10的差距;R6由于校验和计算的实现较为复杂,顺序写性能也是最差的。

 

再来看看这些阵列方案的性能和容错特性:

ssd_r50_r10_05

性能测试结论:

  • 性能测试显示,相同容量的R50和R10性能接近:其中小块文件的随机读R50要全面好于R10,随机写4K虽然R50和R10差距在28%,但是块增大后R50要全面优于R10。顺序读写方面,R50和R10十分接近。
  • 容错方面,R50接近R10:第二块盘容错率R50十分接近R10,两者相差30%。R10的优势主要是在有一定的概率提供第三、甚至第四块磁盘的容错率,但是考虑到并非100%容错,因此从容错角度来看R50虽然和R10有一些差距,但也已体现出较好的容错率,至少优于R5。而且R50搭配灵活,甚至可以指定3组R5以达到最大3块磁盘的容错;
  • 成本方面,R50有很大优势:按这个配置计算R50只有R10的3/4。

 

总结:

RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性,具有较好的整体性价比优势,所以考虑使用RAID 50替换RAID 10把!

SSD优化案例:读策略优化和中断多核绑定

作者: |   5,100 浏览  | 

没有开场白,直接切主题!各位把这篇当成是报告来阅读吧:

应用IO模型:大量读线程同时访问多块SSD,请求均为4KB随机读,并且被请求的数据有一定间隔连续性;

服务器硬件配置:LSI SAS 2308直连卡 + 8块SSD

优化前应用QPS:27K

第一轮优化:读策略优化

通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB,进一步观察iostat情况:

preopt_iostat

观察到每块SSD的rMB/s十分高,平均已经达到了250MB/s+,初步判断是由于read_ahead_kb的设置影响了应用的读效率(即预先读取了过多不必要的数据)。遂将read_ahead_kb设置为0,观察iostat情况如下:

preopt_iostat_rak0

而应用QPS却下降至25K!

分析原因:由于之前有预读功能存在,因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后,所有的读访问均通过随机读实现,一定程度上加重了SSD的访问压力(可以观察到之前%util大约在60~80%之间波动,而预读改成0之后%util则在80~90%之间波动)

 

尝试16K预读

通过IO模型了解到每次请求的数据大小为4KB,因此将read_ahead_kb设置为16KB进行尝试,结果QPS由25K猛增到34K!

观察iostat情况如下:

preopt_iostat_rak16

%util降了不少,而且通过rrqm/s可以发现出现了一部分读合并的请求,这说明优化确有成效。

此时CPU_WA也由原来的平均30%下降到20%,这说明处理器等待IO的时间减少了,进一步验证了IO优化的有效性。

 

第二轮优化:直连卡中断多核绑定

考虑到SSD的随机读写能力较强(通过上面的iostat可以发现),在多盘环境下每秒产生的IO请求数也已接近100K,了解到LSI SAS 2308芯片的IOPs处理极限大约在250K左右,因此判断直连卡控制芯片本身并不存在瓶颈。

其实我们担心更多的是如此大量的IO请求数必定会产生庞大数量的中断请求,如果中断请求全部落在处理器的一个核心上,可能会对单核造成较高的压力,甚至将单核压力打死。因此单核的中断请求的处理能力就有可能成为整个IO系统的瓶颈所在,于是我们通过mpstat观察每个核心上的中断数:

mpstat_preopt

可以发现第二个核心中断数已经达到了十分恐怖的80K!再来观察实际的处理器核心压力情况,为了能够更加直观地了解,我们用了比较准确的i7z工具来观察:

i7z_preopt

果然不出所料,Core 1的Halt(idle)已经到了1,充分说明第二个核心确实已经满载。

那么通过观察/proc/interrupt的情况再来进一步验证我们的假设,:

inter

我们截取了片段,可以发现mpt2sas0-misx的大部分压力都集中在了CPU 1上,并且我们发现直连卡模式是支持多队列的(注意观察irq号从107至122,mpt2sas驱动总共有16个中断号),因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上(这里就不再赘述有关多核绑定的原理,有兴趣的同学可以百度搜索以上命令的含义):

smp

随后我们惊奇地观察到应用的QPS由34K再次猛增至39K!

通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上:

mpstat_after

并且CPU_WA也由平均20%下降到15%,io wait被进一步优化!

 

优化总结:

  • 通过以上两个优化方法将应用的QPS由27K优化至39K,并且处理器的iowait由30%下降至15%,优化收效显著;
  • SSD的优化要根据实际的应用IO模型和设备的理论极限值进行综合考虑,同时还要考虑到各个层面的瓶颈(包括内核、IO策略、磁盘接口速率、连接控制芯片等)。