什么是Docker?

关于Docker是什么,有个著名的隐喻:集装箱。但是它却起了个“码头工人”(docker的英文翻译)的名字。这无疑给使用者很多暗示:“快来用吧!用了Docker,就像世界出现了集装箱,这样你的业务就可以随意的、无拘无束的运行在任何地方(Docker公司的口号:Build,Ship,and Run Any App,Anywhere),于是码头工人就基本都可以下岗了。”但是人们往往忽略了一个问题,隐喻的好处是方便人理解一个不容易理解的概念,但并不能解释其概念本身。

互联网技术行业的一大特点是,这里的绝大多数事物并不像现实生活那么具体,在这个行业中我们所接触的绝大多数概念都是抽象的、不具体的。所以现实生活中很多可笑的事情在互联网技术行业就不仅变的不可笑,反而可能很严肃。就比如,现实生活中你是几乎不可能看见两个神经正常的成年人争论到底是锤子更好还是螺丝刀更好这个问题的。而在我们这个行业,你可以很容易的被卷入到底是java好?还是php好?还是js好?或者类似的语言之争中。当然除了语言,其它的软件工具之争也比比皆是,比如经典的还有vim vs emacs。

由于不具体和抽象,就需要隐喻来给投资人解释其价值,毕竟投资人大多数是外行嘛。至于docker到底是“集装箱”还是“码头工人”并不重要,即使这两个概念本质上冲突了都不重要,很少有人会去真的思考集装箱的出现导致码头工人几乎绝迹。只要能让大家明白docker是个重要的、有价值的、划时代的工具,骗到投资人的钱就足够了。也很少有投资人去考究集装箱的发明人到底有没有因此赚到钱?以及为什么没赚到钱?只要概念能忽悠人就行了。当然这个概念顺便也忽悠了所有懒得思考的技术工程师。

吐了一大段槽之后,回到我们的正题,docker到底是什么?既然大家喜欢集装箱这个隐喻,那么我们也不妨先来看看集装箱的本质。大家应该基本都理解集装箱是怎么改变世界的吧?在集装箱之前,货物运输没有统一的标准方式进行搬运,于是铁路、公路、海洋等各种运输之间,需要大量的人力作为货物中转,效率极低,而且成本很高。集装箱出现之后,世界上绝大多数的货物运输都可以放到这个神奇的箱子里,然后在公路、铁路、海洋等所有运输场景下,这个箱子都可以不用变化形态直接可以承运,而且中间的中转工作,都可以通过大型机械搞定,效率大大提升。从此全球化开始,商业的潜力被进一步挖掘……牛逼之处我就不多说了,可是这个箱子为什么这么神奇呢?答案其实也就在上面的描述中,无非就是两个字:标准。

是的!标准!标准!标准!重要的事情说三遍。

因为规范了集装箱的大小和尺寸的规格标准,于是相应的船舶、卡车、列车才能按照规格制造出来使联运成为可能,所有的运输中转的自动化工具才能被设计建造出来并且高效的使用,才可以极大的提高效率,提升自动化水平,以至于码头工人才会失业。集装箱本身是一个产品,而这个产品无非就是“标准化”的这个概念穿上了马甲,马甲可以有红的、绿的、蓝的、花的,但是大小规格必须都一样。现实世界中的事实显而易见,就是这么简单。那么docker呢?

按照这个思路,docker其实跟集装箱一样,或者说它想跟集装箱一样,成为穿着马甲的“标准化”。这样开发工程师就可以把它们开发出来的bug们放到“集装箱”里,然后运维人员就可以使用标准化的操作工具去运维这些可爱的bug们。于是实现了“海陆联运”,就好像运维工程师根本不需要了解其运维的软件架构而开发工程师也并不需要了解其软件运行的操作系统一样……

这就是docker的实质:穿着马甲的标准化。docker的发明人根据自己运维PAAS平台的经验,重新思考了自己的工作,将PAAS平台的devops工作从各个角度标准化了一下,将系统底层实现的cgroup、namespace、aufs|device mapper等技术集成在一个使用镜像方式发布的工具中,于是形成了docker。观察docker形成的思考过程,其实就是作者针对他所运维的场景如何做自动化运维的思考,大家可以参见其演讲的ppt:http://www.slideshare.net/jpetazzo/docker-automation-for-the-rest-of-us?from_action=save。这个演讲的名字就跟自动化运维相关:Docker: automation for the rest of us 。那么Docker的实质是什么?在我看来就是个针对PAAS平台的自动化运维工具而已。众所周知(当然如果你不知道,那么我来告诉你):自动化运维的大前提就是标准化。

如果你正好是一个运维工程师而且你正感觉你的运维环境一团糟,麻烦请你思考一下这是为什么?你是不是正在运维着一个使用php、java、C#甚至C/C++等用各种语言编写的应用都在运行的环境里?这个环境是不是因为某种历史原因,使你的操作系统运行着各个版本的内核甚至还有windows?即使是同样语言编写的业务也运行着不同版本的库?你的整个系统环境是不是甚至找不出来两台硬件、操作系统、库版本以及语言版本完全一样的环境?于是你每次遇到问题都要去排查到底那个坑到底在那里?从网络、内核到应用逻辑。你每次遇到产品升级都要在各种环境上做稳定性测试,发现不同的环境代码crash的原因都不尽相同。你就像一个老中医一样去经历各种疑难杂症,如果遇到问题能找到原因甚至都是幸运的,绝大多数情况是解决了但不知道原因和没解决自动好了也不知道原因。于是你们在一个特定的公司的环境中积累着“经验”,成为你们组新手眼中的大神,凭借历经故障养成的条件反射在快速解决不断发生的重复问题,并故弄玄虚的说:这就是工作经验。因为经验经常是搞不清楚原因时的最后一个遮羞布。当别人抱怨你们部门效率低的时候,你一般的反应是:”you can you up,no can no 逼逼!“

我花了这么多口舌吐槽运维,无非就是想提醒大家”运维标准化的重要性“这一显而不易见的事实。标准化了,才能提高效率。标准化了,才能基于标准建设属于你们系统的自动化运维。那么我们再来看看docker是怎么做的?

首先,标准化就要有标准化的文档规范,要定义系统软件版本等一系列内容。规范好了之后,大家开始实施。但是在长期运维的过程中,很可能出现随着系统的发展,文档内容已经过时了,工程师又来不及更新文档的问题。怎么解决?docker给出的答案是:用dockerfile。dockerfile就是你的文档,并且用来产生镜像。要改变docker镜像中的环境,先改dockerfile,用它产生镜像就行了,保证文档和环境一致。那么现实是,有多少在使用docker的人是这样用的?你们是不是嫌这样麻烦,于是干脆直接在线docker commit产生镜像,让文档跟现场环境又不符了?或者我还是太理想,因为你们压根连文档都没有?

其次,标准化要有对应用统一操作的方法。在现实中,即使你用的是php开发的应用,启动的方式都可能不尽相同。有用apache的,有用nginx的,还有用某种不知名web容器的,甚至是自己开发web容器的。如果操作范围扩大到包含java等其它语言,或数据库等其它服务,那么操作方式更是千奇百怪。虽然UNIX操作系统早就对此作了统一的规范,就是大家常见的把启动脚本防盗/etc/rc.d中,SYSV标准中甚至规定了启动脚本该怎么写,应该有哪些方法。但是绝大多数人不知道,或者知道了也不这么做,他们习惯用./start作为自己业务启动的唯一标准。甚至./是哪个目录可能都记不住。于是docker又给出了解决方案:我压根不管你怎么启动,你自己爱咋来咋来,我们用docker start或run作为统一标准。于是docker start可以启动一个apache、nginx、jvm、mysql等等。有人病垢docker的设计,质疑它为什么设计上一个容器内只给启动一个进程?这就是原因:人家压根不是为了给你当虚拟机用的,人家是为了给启动生产环境的进程做标准化的!

第三,为了维护生产环境的一致性和配置变更的幂等,docker创造性的使用了类似git管理代码的方式对环境镜像进行管理。于是:
你想做库版本升级吗?更新个镜像吧!
你想做php、java的版本升级吗?更新个镜像吧。
好方便!太爽了!
等等……神马?你想改变apache配置文件中的一个字段?做个新镜像升级吧!
你的php代码写错了一行要改个bug?做个新镜像升级吧……
在一群人吐血三升之后,于是有人出了个主意。唉,其实后两种需求没必要这么麻烦,有一种软件叫做puppet、chef、salt、ansible、rsync……
于是我们要在docker中启动一个puppet。
什么?你要用ansible?好吧,我们来看看怎么在docker中启动一个sshd?
我有个计划任务要跑,起个crontab可以么?

你的docker是不是就这么变成了“虚拟机”的?

不过请注意:我并不是说docker不好,只是你是否真的评估了它标准话的方式是不是适合你的业务场景?锤子是用来砸钉子的,但是你非要用它来砸手指,我也没什么办法。

作为一个工程师,而且是受过专业训练的工程师,总是想设计出一套工具满足所有场景需求。因为工程师所受的思维训练是:你越是解决了更普遍的问题,你所创造的价值就越大。但是请搞清楚,这个任务一般是由标准委员会来完成的,每个工程行业都会有这么个组织来做这件事情。当然,不排除商业公司的产品可以深刻影响标准制定的情况。那么我们这些工程师最大的价值是什么?摆正自己的位置,看清自己的问题,帮组所在的企业进一步提高效率,提高竞争力。每个企业都有其历史和当前特点,就运维工作来讲,根据企业的实际情况找到其标准化的最经济有利方式才是我们这些受聘用的职业工程师的核心价值。软件选型要要因地制宜,而不是跟风炒作。当然,如果你的核心价值是想要站在“技术前沿”,打算一直引领技术潮流,做一个出没于各大技术交流会的新技术吹牛逼者,并以此抬高自己身价的话,那我的话自然是对你不适用的。(说这话可能会得罪很多人,我要解释一下:对于那些真诚的想要分享自己技术,希望为社区发展做贡献的人,我是怀着深深的敬意的!谢谢你们!)对待新技术,大多数工程师的状态是:测试是为了上线的,测试出的问题都是要解决的而不是用来评估的,不上线就没有工作成果。我认为工程师对待新技术应有得态度是:激进的用新技术新方法来做线下测试,认真的总结评估测试流程和结果和现有环境的异同,保守谨慎的评估决策新技术是否在业务上大规模使用。

docker是银弹么?真的能像集装箱那样改变世界么?我的看法当然不是。即使集装箱,也不能解决一些特殊的运输问题,比如大型飞机零部件的运输,或者小件零散商品的运输。如果说云计算行业真的要出现集装箱的话,那么首先这个行业要被几大云计算厂商瓜分完毕,市场成熟之后才有可能。为什么?因为让一个应用可以在任何地方跑的需求,主要应该来自云的用户,他们可能为了稳定性考虑既租用了阿某云,又租用了腾讯云(纯广告,自己所在的公司,所以请勿吐槽),还可能为了海外市场还用了某马逊云。这时用户会有需求说,我想要这些云的环境标准一致,以便我的应用可以在哪朵云上都能跑(Build,Ship,and Run Any App)。而现在,云计算市场刚刚起步,群雄逐鹿,正是差异化发展争夺用户的时候。出了云计算厂商外,其它公司的IT环境都不一样,标准化要求也就不可能一样。那么你觉得docker这个标准可能适合所有人么?

如果你用过了docker,并且还觉得它非常合适你的环境,那么我希望你能回答这几个问题:
你的docker是用docker file产生的镜像还是直接docker commit?
你的docker里面跑了多少个进程?
你的docker是当虚拟机用的么?
那么你用的是docker么?

最后,送大家一个段子,希望能博你一笑。

工程师:“嘿!有人发明了一个叫做集装箱的东西,这东西一定可以使运输成本大大下降!甚至改变世界!”
用户:“好兴奋!这东西可以运输我的波音787客机么?“
工程师:“额。。不能整个运,需要拆开再运,因为我们要符合集装箱的标准……”
用户:“那这东西可以运输我的空客380嘛?”
工程师:“额。。我们讨论的是同一件事情。”
用户:“不行是嘛?那不能改造一下集装箱让它可以运嘛?”
工程师:“额。。。这不仅仅是我们的问题,要到达运输目的地还要经过铁路,公路,他们可能也无法……”
用户:“真的不能改造集装箱么?可这东西是以后的发展方向啊!未来的世界都是应该是集装箱运输的!”
工程师:“额……”
老板:“嗯!这东西说不定真的是未来的发展方向!我们一定要实现用集装箱运输这些飞机!工程师们,你们赶紧去攻克这些技术难题,早日可以实现我们用户的特殊需求!让集装箱可以达到我们的业务要求!快去吧!加油啊!”
工程师:“额……”

您的支持是我持续写下去的动力,所以本文无耻的接受捐赠。如果你觉得值得,请刷下面二维码,捐赠九毛九。

mm_facetoface_collect_qrcode_1465221734716

我为什么一定要“咬文嚼字”

咬文嚼字,是一个成语,含贬义,用来形容过分地斟酌字句。多指死扣字眼而不注意精神实质。当然它还有一个近义词,叫做字斟句酌。当然,对比一下就会发现,字斟句酌就并不含贬义。好吧好吧,我又开始咬文嚼字了。

事情的起因是昨天跟一个同事讨论问题(实际上是我在理解他的需求)的时候,同事问我为什么这么咬文嚼字呢?关于这件事情,我们可以先从另一个故事说起:

《吕氏春秋》里有一段,讲孔子周游列国,曾因兵荒马乱,旅途困顿,三餐以野菜果腹,大家已七日没吃下一粒米饭。

一天,颜回好不容易要到了一些白米煮饭,饭快煮熟时,孔子看到颜回掀起锅盖,抓些白饭往嘴里塞,孔子当时装作没看见,也不去责问。

饭煮好后,颜回请孔子进食,孔子假装若有所思地说:我刚才梦到祖先来找我,我想把干净还没人吃过的米饭,先拿来祭祖先吧!

颜回顿时慌张起来说:不可以的,这锅饭我已先吃一口了,不可以祭祖先了。

孔子问:为什么?

颜回涨红脸,嗫嗫地说:刚才在煮饭时,不小心掉了些染灰在锅里,染灰的白饭丢了太可惜,只好抓起来先吃了,我不是故意把饭吃了。

孔子听了,恍然大悟,对自己的观察错误,反而愧疚,抱歉地说:我平常对颜回已最信任,但仍然还会怀疑他,可见我们内心是最难确定稳定的。弟子们大家记下这件事,要了解一个人,还真是不容易啊!

针对这个故事,原文的评论是这样说的:

“所谓知人难,相知相惜更难。逢事必从上下、左右、前后各个角度来认识辨知,我们主观的了解观察,只是真相的千分之一,单一角度判断,是不能达到全方位的观照的!

当你要对一个人下结论的时候,想想:真的你所看到的才是事实吗?还是你只从一个面,一个点,去观察一个人呢?

大多数的人根本不了解对方的立场与困难的时候,就已经给了对方下评语了,更何况是在有利益冲突下的场合。

现今的人们拥有高学历高知识,却往往过度仰赖高知识,而忘了让自己在智慧上成长。很多事信者恒信,不信者恒不信,要客观地跳出成见,才有机会接近真相。连孔圣人也会对自己最信任的弟子起疑心,更何况我们呢?

我们是不是也常常因为亲眼所见、亲耳所闻,对他人产生了某种印象,从而为他人打上某种标签呢?孔圣人可以当下就用智慧,轻易了解真相,消除误会,可是我们呢?

有多少人,因为自己的亲眼所见,尤其是亲密关系里,从此耿耿于怀,甚至怀恨在心……可悲的是,到死都不知道,其实是自己看错了

两个人交流时,其实是六个人在交流:你以为的你,你以为的他,真正的你;他以为的他,他以为的你,真正的他。你想,这里边会有多少误会,会有多少误解?你总在和你以为的他交流,你知道真正的他的想法吗?”

当然,这是一个比较典型的心灵鸡汤文,写的是一些比较典型的“真理”型感悟。但是其背后透露出来的信息确实值得分析的。我们真的要像原文评论说的那样要在“智慧上成长”,“客观地跳出成见,才有机会接近真相”么?如果真的去“逢事必从上下、左右、前后各个角度来认识辨知”,先不谈我们要付出多大的成本,等你成功的接近了真相,你能接受么?还拿原文的例子说,颜回可能确实是因为灰把米饭弄脏了而先吃了几口,这可能只是原因之一,但是更主要的原因难道不是因为他饿么?如果不饿为啥不能把脏的丢掉?至于孔子更是个心机婊好吧!你家颜徒弟这么忠心耿耿的人,在你眼里连先吃口米饭的权利都没有,还要拐着弯的试探人家,这种人我就不明白为啥我国人竟会把他当作圣人?估计是他心眼太多,而这正符合了我国人的传统文化。

扯远了,说回来。我比较认同的是最后一段的说明:看上去的两个人的沟通,实际上是六个人的沟通。你以为的你,他以为的你和真实的你在跟你以为的他、他以为的他和真实的他在沟通。

人和人的协作其实是一件非常困难的事情,因为信息不对等会产生很多猜忌、疑惑、瞧不起、看不上、嫉妒等等会影响协作的情绪,所谓的人心隔肚皮呀!所以资本主义很聪明的发明了契约这一约束条件。所有的沟通、合作、服务都可以通过一份文件的发布而达成协议,成为契约。大家所需要做的事情就是咬文嚼字,或者叫做字斟句酌。无论多少人的合作,大家只要在词语所表达的概念上达到一致,相互之间明白对方是用某个词语的时候其含义是什么,并把它确定下来,就可以形成一致。否则,就不能形成一致,英文中表达没有形成一致的词语更加直接,叫做not on the same page,咱俩压根没翻到同一页上。

有了契约,所有的协作都可以用服务化(SLA)的方式提供给别人,而理解别人和让别人理解自己变得在协作中不再那么重要。于是整个现代文明都建立在契约这个基石之上。互联网文化更是如此:所有通信都要有协议,所有服务都应以API(应用程序接口)的方式形成标准,所有合作都要在细节点上达成一致,形成契约,才能判断结果。这正是我国传统文化所缺少的,所以在我看来,梁山好汉、唐僧师徒都不是好的团队。他们一盘散沙似的基于信任领会精神而非契约形式的管理,能成功只是小概率事件。

日常工作中我们会见到无数人与人之使用的名词和其背后的含义并不一致的情况,就拿我从事的云计算行业来说,当有人说云计算的时候,一些人认为亚马逊的aws是云计算,另一些人则认为百度网盘是云计算。这还只是比较浅显的概念。当说到Linux时,有人认为说的是操作系统,而另一些人认为说的是个内核(kernel)。当有人说他想要个IAAS时,实际上他想要的是个PAAS,当他说想要的是个PAAS时,实际上他描述的功能则更像个SAAS。虚拟化这个词是什么意思?容器是不是虚拟化技术?docker是不是一种容器?虚拟化技术到底好处在哪里?这些在技术上有着明确定义的概念,却成了“工程师”眼中的哈姆雷特,一百个人眼里可能有两百个样子。你别觉得我是在开玩笑,一百个人眼里怎么可能有两百个样子?因为有一部分“客户”自己其实并不知道自己所说的名词倒是是什么意思,等工程师把他自己的理解的东西拿出来展示给“客户”之后,客户突然发现这不是他要的。其实根据上面两个人沟通实际上是六个人沟通的场景来看,一百个人眼里有两百个样子的“哈姆雷特”还真是算是幸运的情况了。

那么这个世界上就没有能不去咬文嚼字的合作么?当然有,当你和你身边的同事共事了多年,你们已经建立了基本一致的三观外加“技术观”,或者你们能充分明白对方观念里的某一个概念是什么意思的时候,那么你们的团队就应该不太需要咬文嚼字似的管理和协作了。到那时候,领会精神才是有效概念。所以我们才会看到,唐僧团队打磨了多年才能取得真经,梁山好汉即使打磨了多年,最后还是很多人不能理解松江为什么非要招安。

著名管理大师彼得德鲁克的名言是:管理是把事做对,而领导力则是做对的事(Management is doing things right; leadership is doing the right things.)。细究管理学的书籍的话,你会发现几乎任何一本都在告诉你,当别人交给你任务时你要问:为什么?什么时候?这还只是简单的提醒,更加标准的方式是至少要问清楚以下这7个问题:谁(who)?什么(what)?为什么(why)?何时(when)?在哪(where)?如何(how)?多少(how much)?如果交代事情的人没告诉我们这些,那么我们就要问清楚,以保证我们能把事情做对!如果交代事情的人描述事情的时候使用了一些名词,那么我更加建议大家去问清楚这些名词要表达的意思是不是你理解的意思?即使这些名词好像是大家都知道的。否则辞典为什么这么有用?

于是我们再回到同事跟我讨论问题(我试图理解他的需求)的场景,还有人会认为我咬文嚼字是多余的么?

Linux的IO调度

Linux的IO调度

Zorro] icon

Hi,我是Zorro。我的公众账号是:Linux系统技术。欢迎大家关注,我会不定期在这里更新文章,欢迎来一起探讨。
我的微博地址,有兴趣可以来关注我呦。

您的支持是我持续写下去的动力,所以本文无耻的接受捐赠。如果你觉得值得,请刷下面二维码,捐赠九毛九。

mm_facetoface_collect_qrcode_1465221734716

Email: mini.jerry@gmail.com

QQ: 30007147

今天我们来谈谈:

Linux的IO调度

IO调度发生在Linux内核的IO调度层。这个层次是针对Linux的整体IO层次体系来说的。从read()或者write()系统调用的角度来说,Linux整体IO体系可以分为七层,它们分别是:

  1. VFS层:虚拟文件系统层。由于内核要跟多种文件系统打交道,而每一种文件系统所实现的数据结构和相关方法都可能不尽相同,所以,内核抽象了这一层,专门用来适配各种文件系统,并对外提供统一操作接口。
  2. 文件系统层:不同的文件系统实现自己的操作过程,提供自己特有的特征,具体不多说了,大家愿意的话自己去看代码即可。
  3. 页缓存层:负责真对page的缓存。
  4. 通用块层:由于绝大多数情况的io操作是跟块设备打交道,所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备,对上提供统一的Block IO请求标准。
  5. IO调度层:因为绝大多数的块设备都是类似磁盘这样的设备,所以有必要根据这类设备的特点以及应用的不同特点来设置一些不同的调度算法和队列。以便在不同的应用环境下有针对性的提高磁盘的读写效率,这里就是大名鼎鼎的Linux电梯所起作用的地方。针对机械硬盘的各种调度方法就是在这实现的。
  6. 块设备驱动层:驱动层对外提供相对比较高级的设备操作接口,往往是C语言的,而下层对接设备本身的操作方法和规范。
  7. 块设备层:这层就是具体的物理设备了,定义了各种真对设备操作方法和规范。

有一个已经整理好的Linux IO结构图,非常经典,一图胜千言:

Linux IO协议栈框架图

我们今天要研究的内容主要在IO调度这一层。它要解决的核心问题是,如何提高块设备IO的整体性能?这一层也主要是针对机械硬盘结构而设计的。众所周知,机械硬盘的存储介质是磁盘,磁头在盘片上移动进行磁道寻址,行为类似播放一张唱片。这种结构的特点是,顺序访问时吞吐量较高,但是如果一旦对盘片有随机访问,那么大量的时间都会浪费在磁头的移动上,这时候就会导致每次IO的响应时间变长,极大的降低IO的响应速度。磁头在盘片上寻道的操作,类似电梯调度,如果在寻道的过程中,能把顺序路过的相关磁道的数据请求都“顺便”处理掉,那么就可以在比较小影响响应速度的前提下,提高整体IO的吞吐量。这就是我们问什么要设计IO调度算法的原因。在最开始的时期,Linux把这个算法命名为Linux电梯算法。目前在内核中默认开启了三种算法,其实严格算应该是两种,因为第一种叫做noop,就是空操作调度算法,也就是没有任何调度操作,并不对io请求进行排序,仅仅做适当的io合并的一个fifo队列。

目前内核中默认的调度算法应该是cfq,叫做完全公平队列调度。这个调度算法人如其名,它试图给所有进程提供一个完全公平的IO操作环境。它为每个进程创建一个同步IO调度队列,并默认以时间片和请求数限定的方式分配IO资源,以此保证每个进程的IO资源占用是公平的,cfq还实现了针对进程级别的优先级调度,这个我们后面会详细解释。

查看和修改IO调度算法的方法是:

[zorro@zorrozou-pc0 ~]$ cat /sys/block/sda/queue/scheduler 
noop deadline [cfq] 
[zorro@zorrozou-pc0 ~]$ echo cfq > /sys/block/sda/queue/scheduler

cfq是通用服务器比较好的IO调度算法选择,对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适应,尤其是IO压力集中在某些进程上的场景。因为这种场景我们需要更多的满足某个或者某几个进程的IO响应速度,而不是让所有的进程公平的使用IO,比如数据库应用。

deadline调度(最终期限调度)就是更适合上述场景的解决方案。deadline实现了四个队列,其中两个分别处理正常read和write,按扇区号排序,进行正常io的合并处理以提高吞吐量.因为IO请求可能会集中在某些磁盘位置,这样会导致新来的请求一直被合并,可能会有其他磁盘位置的io请求被饿死。因此实现了另外两个处理超时read和write的队列,按请求创建时间排序,如果有超时的请求出现,就放进这两个队列,调度算法保证超时(达到最终期限时间)的队列中的请求会优先被处理,防止请求被饿死。

不久前,内核还是默认标配四种算法,还有一种叫做as的算法(Anticipatory scheduler),预测调度算法。一个高大上的名字,搞得我一度认为Linux内核都会算命了。结果发现,无非是在基于deadline算法做io调度的之前等一小会时间,如果这段时间内有可以合并的io请求到来,就可以合并处理,提高deadline调度的在顺序读写情况下的数据吞吐量。其实这根本不是啥预测,我觉得不如叫撞大运调度算法,当然这种策略在某些特定场景差效果不错。但是在大多数场景下,这个调度不仅没有提高吞吐量,还降低了响应速度,所以内核干脆把它从默认配置里删除了。毕竟Linux的宗旨是实用,而我们也就不再这个调度算法上多费口舌了。

CFQ完全公平队列

CFQ是内核默认选择的IO调度队列,它在桌面应用场景以及大多数常见应用场景下都是很好的选择。如何实现一个所谓的完全公平队列(Completely Fair Queueing)?首先我们要理解所谓的公平是对谁的公平?从操作系统的角度来说,产生操作行为的主体都是进程,所以这里的公平是针对每个进程而言的,我们要试图让进程可以公平的占用IO资源。那么如何让进程公平的占用IO资源?我们需要先理解什么是IO资源。当我们衡量一个IO资源的时候,一般喜欢用的是两个单位,一个是数据读写的带宽,另一个是数据读写的IOPS。带宽就是以时间为单位的读写数据量,比如,100Mbyte/s。而IOPS是以时间为单位的读写次数。在不同的读写情境下,这两个单位的表现可能不一样,但是可以确定的是,两个单位的任何一个达到了性能上限,都会成为IO的瓶颈。从机械硬盘的结构考虑,如果读写是顺序读写,那么IO的表现是可以通过比较少的IOPS达到较大的带宽,因为可以合并很多IO,也可以通过预读等方式加速数据读取效率。当IO的表现是偏向于随机读写的时候,那么IOPS就会变得更大,IO的请求的合并可能性下降,当每次io请求数据越少的时候,带宽表现就会越低。从这里我们可以理解,针对进程的IO资源的主要表现形式有两个,进程在单位时间内提交的IO请求个数和进程占用IO的带宽。其实无论哪个,都是跟进程分配的IO处理时间长度紧密相关的。

有时业务可以在较少IOPS的情况下占用较大带宽,另外一些则可能在较大IOPS的情况下占用较少带宽,所以对进程占用IO的时间进行调度才是相对最公平的。即,我不管你是IOPS高还是带宽占用高,到了时间咱就换下一个进程处理,你爱咋样咋样。所以,cfq就是试图给所有进程分配等同的块设备使用的时间片,进程在时间片内,可以将产生的IO请求提交给块设备进行处理,时间片结束,进程的请求将排进它自己的队列,等待下次调度的时候进行处理。这就是cfq的基本原理。

当然,现实生活中不可能有真正的“公平”,常见的应用场景下,我们很肯能需要人为的对进程的IO占用进行人为指定优先级,这就像对进程的CPU占用设置优先级的概念一样。所以,除了针对时间片进行公平队列调度外,cfq还提供了优先级支持。每个进程都可以设置一个IO优先级,cfq会根据这个优先级的设置情况作为调度时的重要参考因素。优先级首先分成三大类:RT、BE、IDLE,它们分别是实时(Real Time)、最佳效果(Best Try)和闲置(Idle)三个类别,对每个类别的IO,cfq都使用不同的策略进行处理。另外,RT和BE类别中,分别又再划分了8个子优先级实现更细节的QOS需求,而IDLE只有一个子优先级。

另外,我们都知道内核默认对存储的读写都是经过缓存(buffer/cache)的,在这种情况下,cfq是无法区分当前处理的请求是来自哪一个进程的。只有在进程使用同步方式(sync read或者sync wirte)或者直接IO(Direct IO)方式进行读写的时候,cfq才能区分出IO请求来自哪个进程。所以,除了针对每个进程实现的IO队列以外,还实现了一个公共的队列用来处理异步请求。

当前内核已经实现了针对IO资源的cgroup资源隔离,所以在以上体系的基础上,cfq也实现了针对cgroup的调度支持。关于cgroup的blkio功能的描述,请看我之前的文章Cgroup – Linux的IO资源隔离。总的来说,cfq用了一系列的数据结构实现了以上所有复杂功能的支持,大家可以通过源代码看到其相关实现,文件在源代码目录下的block/cfq-iosched.c。

CFQ设计原理

在此,我们对整体数据结构做一个简要描述:首先,cfq通过一个叫做cfq_data的数据结构维护了整个调度器流程。在一个支持了cgroup功能的cfq中,全部进程被分成了若干个contral group进行管理。每个cgroup在cfq中都有一个cfq_group的结构进行描述,所有的cgroup都被作为一个调度对象放进一个红黑树中,并以vdisktime为key进行排序。vdisktime这个时间纪录的是当前cgroup所占用的io时间,每次对cgroup进行调度时,总是通过红黑树选择当前vdisktime时间最少的cgroup进行处理,以保证所有cgroups之间的IO资源占用“公平”。当然我们知道,cgroup是可以对blkio进行资源比例分配的,其作用原理就是,分配比例大的cgroup占用vdisktime时间增长较慢,分配比例小的vdisktime时间增长较快,快慢与分配比例成正比。这样就做到了不同的cgroup分配的IO比例不一样,并且在cfq的角度看来依然是“公平“的。

选择好了需要处理的cgroup(cfq_group)之后,调度器需要决策选择下一步的service_tree。service_tree这个数据结构对应的都是一系列的红黑树,主要目的是用来实现请求优先级分类的,就是RT、BE、IDLE的分类。每一个cfq_group都维护了7个service_trees,其定义如下:

struct cfq_rb_root service_trees[2][3];
struct cfq_rb_root service_tree_idle;

其中service_tree_idle就是用来给IDLE类型的请求进行排队用的红黑树。而上面二维数组,首先第一个维度针对RT和BE分别各实现了一个数组,每一个数组中都维护了三个红黑树,分别对应三种不同子类型的请求,分别是:SYNC、SYNC_NOIDLE以及ASYNC。我们可以认为SYNC相当于SYNC_IDLE并与SYNC_NOIDLE对应。idling是cfq在设计上为了尽量合并连续的IO请求以达到提高吞吐量的目的而加入的机制,我们可以理解为是一种“空转”等待机制。空转是指,当一个队列处理一个请求结束后,会在发生调度之前空等一小会时间,如果下一个请求到来,则可以减少磁头寻址,继续处理顺序的IO请求。为了实现这个功能,cfq在service_tree这层数据结构这实现了SYNC队列,如果请求是同步顺序请求,就入队这个service tree,如果请求是同步随机请求,则入队SYNC_NOIDLE队列,以判断下一个请求是否是顺序请求。所有的异步写操作请求将入队ASYNC的service tree,并且针对这个队列没有空转等待机制。此外,cfq还对SSD这样的硬盘有特殊调整,当cfq发现存储设备是一个ssd硬盘这样的队列深度更大的设备时,所有针对单独队列的空转都将不生效,所有的IO请求都将入队SYNC_NOIDLE这个service tree。

每一个service tree都对应了若干个cfq_queue队列,每个cfq_queue队列对应一个进程,这个我们后续再详细说明。

cfq_group还维护了一个在cgroup内部所有进程公用的异步IO请求队列,其结构如下:

struct cfq_queue *async_cfqq[2][IOPRIO_BE_NR];
struct cfq_queue *async_idle_cfqq;

异步请求也分成了RT、BE、IDLE这三类进行处理,每一类对应一个cfq_queue进行排队。BE和RT也实现了优先级的支持,每一个类型有IOPRIO_BE_NR这么多个优先级,这个值定义为8,数组下标为0-7。我们目前分析的内核代码版本为Linux 4.4,可以看出,从cfq的角度来说,已经可以实现异步IO的cgroup支持了,我们需要定义一下这里所谓异步IO的含义,它仅仅表示从内存的buffer/cache中的数据同步到硬盘的IO请求,而不是aio(man 7 aio)或者linux的native异步io以及libaio机制,实际上这些所谓的“异步”IO机制,在内核中都是同步实现的(本质上冯诺伊曼计算机没有真正的“异步”机制)。

我们在上面已经说明过,由于进程正常情况下都是将数据先写入buffer/cache,所以这种异步IO都是统一由cfq_group中的async请求队列处理的。那么为什么在上面的service_tree中还要实现和一个ASYNC的类型呢?这当然是为了支持区分进程的异步IO并使之可以“完全公平”做准备喽。实际上在最新的cgroup v2的blkio体系中,内核已经支持了针对buffer IO的cgroup限速支持,而以上这些可能容易混淆的一堆类型,都是在新的体系下需要用到的类型标记。新体系的复杂度更高了,功能也更加强大,但是大家先不要着急,正式的cgroup v2体系,在Linux 4.5发布的时候会正式跟大家见面。

我们继续选择service_tree的过程,三种优先级类型的service_tree的选择就是根据类型的优先级来做选择的,RT优先级最高,BE其次,IDLE最低。就是说,RT里有,就会一直处理RT,RT没了再处理BE。每个service_tree对应一个元素为cfq_queue排队的红黑树,而每个cfq_queue就是内核为进程(线程)创建的请求队列。每一个cfq_queue都会维护一个rb_key的变量,这个变量实际上就是这个队列的IO服务时间(service time)。这里还是通过红黑树找到service time时间最短的那个cfq_queue进行服务,以保证“完全公平”。

选择好了cfq_queue之后,就要开始处理这个队列里的IO请求了。这里的调度方式基本跟deadline类似。cfq_queue会对进入队列的每一个请求进行两次入队,一个放进fifo中,另一个放进按访问扇区顺序作为key的红黑树中。默认从红黑树中取请求进行处理,当请求的延时时间达到deadline时,就从红黑树中取等待时间最长的进行处理,以保证请求不被饿死。

这就是整个cfq的调度流程,当然其中还有很多细枝末节没有交代,比如合并处理以及顺序处理等等。


您的支持是我持续写下去的动力,所以本文无耻的接受捐赠。如果你觉得值得,请刷下面二维码,捐赠九毛九。

mm_facetoface_collect_qrcode_1465221734716


CFQ的参数调整

理解整个调度流程有助于我们决策如何调整cfq的相关参数。所有cfq的可调参数都可以在/sys/class/block/sda/queue/iosched/目录下找到,当然,在你的系统上,请将sda替换为相应的磁盘名称。我们来看一下都有什么:

[root@zorrozou-pc0 zorro]# echo cfq > /sys/block/sda/queue/scheduler
[root@zorrozou-pc0 zorro]# ls /sys/class/block/sda/queue/iosched/
back_seek_max  back_seek_penalty  fifo_expire_async  fifo_expire_sync  group_idle  low_latency  quantum  slice_async  slice_async_rq  slice_idle  slice_sync  target_latency

这些参数部分是跟机械硬盘磁头寻道方式有关的,如果其说明你看不懂,请先补充相关知识:

back_seek_max:磁头可以向后寻址的最大范围,默认值为16M。

back_seek_penalty:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的。

以上两个是为了防止磁头寻道发生抖动而导致寻址过慢而设置的。基本思路是这样,一个io请求到来的时候,cfq会根据其寻址位置预估一下其磁头寻道成本。首先设置一个最大值back_seek_max,对于请求所访问的扇区号在磁头后方的请求,只要寻址范围没有超过这个值,cfq会像向前寻址的请求一样处理它。然后再设置一个评估成本的系数back_seek_penalty,相对于磁头向前寻址,向后寻址的距离为1/2(1/back_seek_penalty)时,cfq认为这两个请求寻址的代价是相同。这两个参数实际上是cfq判断请求合并处理的条件限制,凡事复合这个条件的请求,都会尽量在本次请求处理的时候一起合并处理。

fifo_expire_async:设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的,cfq在调度的时候一般情况都会优先处理同步请求,之后再处理异步请求,除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时,cfq会优先检查是否有异步请求超时,就是超过fifo_expire_async参数的限制。如果有,则优先发送一个超时的请求,其余请求仍然按照优先级以及扇区编号大小来处理。

fifo_expire_sync:这个参数跟上面的类似,区别是用来设置同步请求的超时时间。

slice_idle:参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间,目的是提高机械硬盘的吞吐量。一般情况下,来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好,所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率,因为固态硬盘没有磁头寻址这个概念,所以在这样的设备上应该设置为0,关闭此功能。

group_idle:这个参数也跟上一个参数类似,区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下,如果我们沿用slice_idle的方式,那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话,那么直到这个cgroup的配额被耗尽,同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下,我们可以将slice_idle = 0而group_idle = 8。这样空转等待就是以cgroup为单位进行的,而不是以cfq_queue的进程为单位进行,以防止上述问题产生。

low_latency:这个是用来开启或关闭cfq的低延时(low latency)模式的开关。当这个开关打开时,cfq将会根据target_latency的参数设置来对每一个进程的分片时间(slice time)进行重新计算。这将有利于对吞吐量的公平(默认是对时间片分配的公平)。关闭这个参数(设置为0)将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的。

我们已经知道cfq设计上有“空转”(idling)这个概念,目的是为了可以让连续的读写操作尽可能多的合并处理,减少磁头的寻址操作以便增大吞吐量。如果有进程总是很快的进行顺序读写,那么它将因为cfq的空转等待命中率很高而导致其它需要处理IO的进程响应速度下降,如果另一个需要调度的进程不会发出大量顺序IO行为的话,系统中不同进程IO吞吐量的表现就会很不均衡。就比如,系统内存的cache中有很多脏页要写回时,桌面又要打开一个浏览器进行操作,这时脏页写回的后台行为就很可能会大量命中空转时间,而导致浏览器的小量IO一直等待,让用户感觉浏览器运行响应速度变慢。这个low_latency主要是对这种情况进行优化的选项,当其打开时,系统会根据target_latency的配置对因为命中空转而大量占用IO吞吐量的进程进行限制,以达到不同进程IO占用的吞吐量的相对均衡。这个开关比较合适在类似桌面应用的场景下打开。

target_latency:当low_latency的值为开启状态时,cfq将根据这个值重新计算每个进程分配的IO时间片长度。

quantum:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中,超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效。

slice_sync:当一个cfq_queue队列被调度处理时,它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为:time_slice = slice_sync + (slice_sync/5 * (4 – prio))。这个参数对同步请求有效。

slice_async:这个值跟上一个类似,区别是对异步请求有效。

slice_async_rq:这个参数用来限制在一个slice的时间范围内,一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关。

CFQ的IOPS模式

我们已经知道,默认情况下cfq是以时间片方式支持的带优先级的调度来保证IO资源占用的公平。高优先级的进程将得到更多的时间片长度,而低优先级的进程时间片相对较小。当我们的存储是一个高速并且支持NCQ(原生指令队列)的设备的时候,我们最好可以让其可以从多个cfq队列中处理多路的请求,以便提升NCQ的利用率。此时使用时间片的分配方式分配资源就显得不合时宜了,因为基于时间片的分配,同一时刻最多能处理的请求队列只有一个。这时,我们需要切换cfq的模式为IOPS模式。切换方式很简单,就是将slice_idle=0即可。内核会自动检测你的存储设备是否支持NCQ,如果支持的话cfq会自动切换为IOPS模式。

另外,在默认的基于优先级的时间片方式下,我们可以使用ionice命令来调整进程的IO优先级。进程默认分配的IO优先级是根据进程的nice值计算而来的,计算方法可以在man ionice中看到,这里不再废话。

DEADLINE最终期限调度

deadline调度算法相对cfq要简单很多。其设计目标是,在保证请求按照设备扇区的顺序进行访问的同时,兼顾其它请求不被饿死,要在一个最终期限前被调度到。我们知道磁头对磁盘的寻道是可以进行顺序访问和随机访问的,因为寻道延时时间的关系,顺序访问时IO的吞吐量更大,随机访问的吞吐量小。如果我们想为一个机械硬盘进行吞吐量优化的话,那么就可以让调度器按照尽量复合顺序访问的IO请求进行排序,之后请求以这样的顺序发送给硬盘,就可以使IO的吞吐量更大。但是这样做也有另一个问题,就是如果此时出现了一个请求,它要访问的磁道离目前磁头所在磁道很远,应用的请求又大量集中在目前磁道附近。导致大量请求一直会被合并和插队处理,而那个要访问比较远磁道的请求将因为一直不能被调度而饿死。deadline就是这样一种调度器,能在保证IO最大吞吐量的情况下,尽量使远端请求在一个期限内被调度而不被饿死的调度器。

DEADLINE设计原理

为了实现上述目标,deadline调度器实现了两类队列,一类负责对请求按照访问扇区进行排序。这个队列使用红黑树组织,叫做sort_list。另一类对请求的访问时间进行排序。使用链表组织,叫做fifo_list。

由于读写请求的明显处理差异,在每一类队列中,又按请求的读写类型分别分了两个队列,就是说deadline调度器实际上有4个队列:

  1. 按照扇区访问顺序排序的读队列。
  2. 按照扇区访问顺序排序的写队列。
  3. 按照请求时间排序的读队列。
  4. 按照请求时间排序的写队列。

deadline之所以要对读写队列进行分离,是因为要实现读操作比写操作更高的优先级。从应用的角度来看,读操作一般都是同步行为,就是说,读的时候程序一般都要等到数据返回后才能做下一步的处理。而写操作的同步需求并不明显,一般程序都可以将数据写到缓存,之后由内核负责同步到存储上即可。所以,对读操作进行优化可以明显的得到收益。当然,deadline在这样的情况下必然要对写操作会饿死的情况进行考虑,保证其不会被饿死。

deadline的入队很简单:当一个新的IO请求产生并进行了必要的合并操作之后,它在deadline调度器中会分别按照扇区顺序和请求产生时间分别入队sort_list和fifo_list。并再进一步根据请求的读写类型入队到相应的读或者写队列。

deadline的出队处理相对麻烦一点:

  1. 首先判断读队列是否为空,如果读队列不为空并且写队列没发生饥饿(starved < writes_starved)则处理读队列,否则处理写队列(第4部)。
  2. 进入读队列处理后,首先检查fifo_list中是否有超过最终期限(read_expire)的读请求,如果有则处理该请求以防止被饿死。
  3. 如果上一步为假,则处理顺序的读请求以增大吞吐。
  4. 如果第1部检查读队列为空或者写队列处于饥饿状态,那么应该处理写队列。其过程和读队列处理类似。
  5. 进入写队列处理后,首先检查fifo_list中是否有超过最终期限(write_expire)的写请求,如果有则处理该请求以防止被饿死。
  6. 如果上一步为假,则处理顺序的写请求以增大吞吐。

整个处理逻辑就是这样,简单总结其原则就是,读的优先级高于写,达到deadline时间的请求处理高于顺序处理。正常情况下保证顺序读写,保证吞吐量,有饥饿的情况下处理饥饿。

DEADLINE的参数调整

deadline的可调参数相对较少,包括:

[root@zorrozou-pc0 zorro]# echo deadline > /sys/block/sdb/queue/scheduler
[root@zorrozou-pc0 zorro]# ls /sys/block/sdb/queue/iosched/
fifo_batch  front_merges  read_expire  write_expire  writes_starved

read_expire:读请求的超时时间设置,单位为ms。当一个读请求入队deadline的时候,其过期时间将被设置为当前时间+read_expire,并放倒fifo_list中进行排序。

write_expire:写请求的超时时间设置,单位为ms。功能根读请求类似。

fifo_batch:在顺序(sort_list)请求进行处理的时候,deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中,不会产生是否超时的检查,也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾,当饥饿时间需要尽可能的符合预期的时候,我们可以调小这个值,以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量,但是会导致处理饥饿请求的延时变长。

writes_starved:这个值是在上述deadline出队处理第一步时做检查用的。用来判断当读队列不为空时,写队列的饥饿程度是否足够高,以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候,deadline并不会立即对写请求进行处理,而是给相关数据结构中的starved进行累计,如果这是第一次检查到有写请求进行处理,那么这个计数就为1。如果此时writes_starved值为2,则我们认为此时饥饿程度还不足够高,所以继续处理读请求。只有当starved >= writes_starved的时候,deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的,这个值越大,则写请求越被滞后处理,越小,写请求就越可以获得趋近于读请求的优先级。

front_merges:当一个新请求进入队列的时候,如果其请求的扇区距离当前扇区很近,那么它就是可以被合并处理的。而这个合并可能有两种情况,一个是向当前位置后合并,另一种是向前合并。在某些场景下,向前合并是不必要的,那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并,设置为0关闭。

NOOP调度器

noop调度器是最简单的调度器。它本质上就是一个链表实现的fifo队列,并对请求进行简单的合并处理。调度器本身并没有提供任何可疑配置的参数。

各种调度器的应用场景选择

根据以上几种io调度算法的分析,我们应该能对各种调度算法的使用场景有一些大致的思路了。从原理上看,cfq是一种比较通用的调度算法,它是一种以进程为出发点考虑的调度算法,保证大家尽量公平。deadline是一种以提高机械硬盘吞吐量为思考出发点的调度算法,尽量保证在有io请求达到最终期限的时候进行调度,非常适合业务比较单一并且IO压力比较重的业务,比如数据库。而noop呢?其实如果我们把我们的思考对象拓展到固态硬盘,那么你就会发现,无论cfq还是deadline,都是针对机械硬盘的结构进行的队列算法调整,而这种调整对于固态硬盘来说,完全没有意义。对于固态硬盘来说,IO调度算法越复杂,额外要处理的逻辑就越多,效率就越低。所以,固态硬盘这种场景下使用noop是最好的,deadline次之,而cfq由于复杂度的原因,无疑效率最低。


您的支持是我持续写下去的动力,所以本文无耻的接受捐赠。如果你觉得值得,请刷下面二维码,捐赠九毛九。

mm_facetoface_collect_qrcode_1465221734716