云计算平台OpenStack和Ceph更配哦




 

背景介绍

首先说明下写这篇文章的背景

某厂的云计算项目始于2012年,当时的OpenStack才刚刚起步,而我那时候还在老东家HW搞底层虚拟化平台(Xen及关联的qemu、libvirt等),连OpenStack都没听说过,只知道eucalyptus这个玩意儿(是我们开发的虚拟化平台的上层客户),听说最多的是VMware和aws,稍微扯远了,回到OpenStack项目,当时某厂也在调研各种云平台和虚拟化技术,由于某厂属于互联网公司(至少他们自己这么认为),自认为还有一些技术实力(即使现在没有,也是可以从其他厂里挖墙脚嘛),所以肯定不会考虑商业平台比如VMware,或者其他公有云、私有云解决方案提供商(或者说托管云),全部使用开源组件,构建自己的云计算平台是基本要求。

据说当时云管理平台方面对比了OpenStack、cloudstack、eucalyptus等主流云平台,底层虚拟化平台主要对比了Xen和KVM(说实话开源的虚拟化技术也没有其他的了),最终选择了OpenStack+KVM技术,目前看来还是十分明智的,对比其他云平台,要么半死不活、要么作价卖掉,只有OpenStack发展势头愈发迅猛(当然很多人认为目前容器技术如docker有取而代之的趋势,但我并太认同,二者的适用场景明显不太一样,后续有时间再开一个页面详细叙述吧),底层虚拟化技术Xen也日暮西山,支持的开源大厂也寥寥无几,基本可以忽略了,KVM借力Linux内核,已经逐步被各种企业厂商接受。

从上面的背景描述可以看出,某厂的领导还是很有眼光的,毕竟都是技术出身一步一步做到领导职位的,这点我还是相当佩服的。

某厂云平台演进介绍

OpenStack+KVM,很完美的搭配,凡事都有个演进过程,某厂也不例外,OpenStack Essex版本是第一个上线版本,当时还没有cinder、neutron这两大组件,只有最基础的计算服务nova组件,很多人都认为云计算服务重要性(难度)排名为:网络40%、存储40%,计算只占20%,我也是很赞同这个观点的,但是前提是计算服务已经稳定下来的情况下,如果计算服务还有一堆问题没解决,其他两大服务就别想玩好,从运维方面来说,云计算三分开发七分运维,也符合442这种重要性或者难度排名。

又扯远了,当时主要用了keystone、glance、nova服务,包含nova-network,没有用nova-volume(cinder服务的前身),而是自己开发的一套块存储服务,对象存储用的也是某厂自己已有的服务,这里主要讨论块存储这部分的演进过程。

刚开始的时候某厂的块存储是模仿aws的EBS服务来构建的,而不是为了搭配nova-volume,这一决定给后续整个云平台的发展带来了较大的障碍,列举出来有如下几个潜在问题:

  1. api不兼容nova-volume以及后续的cinder,毕竟是aws的EBS风格,跟OpenStack完全不搭边
  2. 架构不合理,由基本完全不懂云计算存储的传统专家构建,当然并不是说他们的技术不牛逼,只是跟云计算平台所期望的存储系统的需求有很多不匹配的地方,后面我会详细说明具体有哪些问题
  3. 技术人员断层,由一个主要的存储专家来全面负责(从隔壁厂重金挖墙脚过来的,当然后面隔壁厂即将上市前,又被挖了回去,据说不止这一个,还顺便挖了很多墙角,导致某厂损失惨重,我恶意猜测可能是报复行为吧,某厂也没办法,毕竟码农也不傻,钱多钱少还是分得清的),其他人都是刚毕业的小弟(人员几经变动、人来人往,后来只剩下俩人),导致后续群龙无首,存储系统发展缓慢,几乎陷入停滞状态,只能做基本的维护和bug修复,新功能基本没技术、没人力去开发(有人可能会问,为啥不继续招人甚至挖墙脚?我们可以设想一下,如果你老板或者技术经理,项目组很缺人,你是招一个刚毕业的应届生呢还是技术熟手或者专家?肯定是后者,应届生的培养周期太长,极有可能看到你项目没前途就提早闪人了,挖专家的话,让一个专家去接手一个半死不活,并且即使做好了,绩效也不归他,毕竟不是你设计构建的,搞砸了,领导嘴上可能不说,但心里肯定鄙视你啊,一个堂堂专家,我们重金挖来,连一个简单的系统都搞不定,至少认为你的能力不如前一个设计这个系统的那个专家牛逼啊,人家都能设计出来,你维护都搞不定。。。呵呵了吧)

闭源vs开源

上面第三点又扯远了,但确实是很现实的问题,我相信也是很多其他厂遇到的问题,为啥会出现这种困境?我个人理解其中一个原因就是自己设计了一个闭源系统,并且人员储备不足(或者说来不及储备,带头大哥就被隔壁厂挖走了。。。跟隔壁老王有一拼了。。。),后面招人维护或者改进会更加难上加难,上面第三点也简单描述了一些原因。假设换成使用的是业界主流开源系统,这种情况肯定会大有不同,毕竟码农也想给自己贴金,以期提高卖身价钱,如果是一个闭源系统,你做的再好、再牛逼,也只是服务于一个很小的范围(某个厂的内部、某个厂的特定客户,除非你能做到微软、VMware这种世界一流的平台),想要用这种系统来作为跳槽的垫脚石,目标公司的认可度肯定大打折扣,至少很少有机会被其他厂主动挖墙脚,主动和被动看起来结果差不多,但是待遇就不一样了,一个让你自己提要求、一个是让你不敢提要求。

但是换做开源系统,你贡献的一个bug修复,一个小功能,都可能让全世界的所有使用该系统的厂家受益,你的名字也会被全世界关心这个bug或者功能的码农关注甚至膜拜,这对码农(一般都是宅男,没机会被世人关注,只能躲在阴暗角落里偷偷的边抹泪边码代码)来说是非常难得扬名立万的机遇,如果能成为某个流行的开源系统的重要代码贡献者、甚至核心开发人员,基本可以与金榜题名相比了,对码农来说简直可以说是无上荣耀,足以光宗耀祖,养家糊口更是不在话下,带领全家奔小康也是小菜一碟、信手拈来、稀松平常!各种公司都会在各种场合通过各种方式向你伸出橄榄枝,想要挖你过去,待遇足以让你心动。

采用流行开源系统还有一个好处,人员储备几乎可以不用太过担心,毕竟一抓一大把搞这方面的人,想找核心贡献者很难(这要看你敢不敢开价了),想找入门级、熟练级的肯定不难,稍加指导即可给你卖力干活了,他们也没有后顾之忧,毕竟自己的能力没有断层,还是延续专长的方向,即使在你这混不下去,还可以凭自己的本事找到合适的接盘厂,不至于家里老婆孩子喝西北风。

其他开源的好处就不多说了,已经扯得远的没边了。。。

首次改进

一开始的时候,挂卸载卷操作是云硬盘服务组,通过自己在计算节点上的agent调用libvirt接口来做的,也就是用户挂卸载卷都是云硬盘组单独处理的,云硬盘还要调用nova接口查询虚拟机状态,计算服务nova等根本不清楚也不参与这个流程,然后各种并发问题、虚拟机迁移问题等等就接踵而来,靠云硬盘服务肯定搞不定,靠nova服务也不行,因为他管不到云硬盘。想想都觉得不靠谱。

后来在计算服务组相关开发的推动下,改为使用nova的挂卸载卷接口来执行操作,好了很多,毕竟nova控制了这个流程,虽然多加了一部分云硬盘的驱动代码来跟云硬盘api交互,还对nova本身的代码做了一些改动,维护有点困难,至少某些功能可以做起来了,大部分问题也解决掉了,虽然创建删除卷等操作还是要调用云硬盘api,顺便说了下,为了适配这个改动,云硬盘还开发了一个代理程序,用于接口转换,让上层用户平滑过渡。

二次改进

后来的后来,也就是平台上线近两年后,云硬盘和计算服务的开发已经对这种模式吐槽到不行了,这个时候的cinder服务也已经发展到了Havana版本(某厂的其他服务也已经升级到这个版本),社区对cinder的稳定性也逐步认可,也经过了其他厂的验证,某厂也开始考虑把云硬盘服务接入过来,作为cinder的一种后端存储方案,为此开发了专用的cinder driver,基本也就是把之前的nova里面的驱动改吧改吧挪到cinder里面,这样nova服务关于卷的操作就完全兼容了OpenStack社区实现,基本不需要做任何改动(除了部分功能增强,这部分跟这次改进没有联系),为后续nova服务的顺利升级、新功能的支持打下了良好基础。

经过这次改进,计算服务和存储服务的交互就只集中在cinder服务的一个驱动模块了,大大简化了沟通难度,后续两个服务各司其职,架构清晰,有什么要求只要给存储后端提需求即可,cinder服务成了需求方,功能开发更加顺利(之前还要两个服务讨论清楚怎么分工,怎么合作),沟通成本大降。

改完之后,所有的问题都集中在了存储后端本身,各种云计算服务的基础功能,比如从云硬盘启动虚拟机(或者叫从块设备启动虚拟机,boot from volume),在线迁移虚拟机,云硬盘快照,从快照恢复虚拟机,等功能都需要云硬盘后端提供技术支持,但很遗憾,这些都不能做到。所以就面对第三次改进还是直接更换技术方案的严峻问题。

三次改进vs更换存储方案

如何改进

首先要把各种功能补齐,下面列举一些:

  1. 快照功能必须要有吧,你真的难以想象,一个云硬盘服务,上线运行了快两年了,都不支持快照功能,这是有多么的让人无法接受。。。
  2. boot from volume,从云硬盘启动虚拟机,这已经是云计算必备功能了吧
  3. 随虚拟机迁移供,包括离线、在线两种,离线方式比较简单,支持起来没难度,已经搞定,在线迁移对后端存储要求较高,必须做到完全共享存储才有可能,虽然KVM支持带本地存储的在线迁移,但跨节点拷贝这么大的数据量对网络IO、cpu、磁盘IO都是严重考验,其他虚拟机肯定或多或少的受到影响,迁移时间也会很长,虚拟机停服时间也会相应拉长,但目前后端存储还做不到完全共享,方案都还没想出来,据说是因为卷的位图是放在挂载卷所在节点的内存盘里面,两个节点没办法共享,需要跟虚拟机一起迁移过去,但是位图的迁移时机,以及位图迁移过程中如何限制虚拟机访问存储都是大难题,总不能在qemu迁移虚拟机结束后,还要先不恢复虚拟机的运行,通知存储系统迁移位图,等位图迁移过去,再恢复虚拟机的运行吧?先不说在qemu中调用存储系统api实现通知他们迁移位图的难度和架构的猥琐程度,但这一流程的耗时和迁移位图所需要的时间加起来,估计都要上一分钟了吧?还不如带本地存储的在线迁移快。。。

再说下性能问题,或者说用户体验问题,主要是指打快照耗时、快照恢复耗时、从云硬盘虚拟机启动等操作的耗时:

  1. 打快照,完成后要上传到某厂自己的对象存储服务,即使内网万兆再快,第一次快照是全量的,可能上百G的数据量,可想而知,要多久能完成,这还不包括云硬盘存储后端生成快照文件的时间,即便是后续的增量快照,如果一个几百G的卷,隔三差五的打个快照,增量部分也不止1分钟能搞定吧
  2. 快照恢复卷,要先从对象存储下载到存储节点,把数据恢复到生成的卷,几百G这种大小的卷,你自己可以算下下载耗时和恢复耗时
  3. 为了支持从云硬盘启动,后端存储开发了延迟加载数据功能,也就是虚拟机启动过程中,需要哪些硬盘上的存储数据块,后端就给他从对象存储上下载哪些数据块,而不是一开始就全部下载好,在一定程度上加快虚拟机启动速度,这个技术难度还是有点大的,先不说一开始经常发生的虚拟机crash、蓝屏问题(后来基本都解决了,也真不容易),但是实际效果还是不尽如人意,启动时间还是比较长,至少不能跟其他公有云厂商相提并论

更换方案

上面吐槽了太多某厂的存储方案,下面简单看下其他采用OpenStack云平台的厂商是怎么解决这些槽点的,据我了解,主要有如下几种方案:

  1. 最简单的采用NFS,适用于小规模部署场景
  2. 高大上的SAN,适用于土豪厂商
  3. 开源块存储系统如sheepdog、glusterFS等,适用于中小规模场景
  4. 开源统一存储方案Ceph

我在此推荐统一存储方案Ceph,理由如下:

  1. NFS不适合大规模部署
  2. SAN太贵,也浪费计算节点上的存储资源,虽然你可以配合从刀片服务器(不配存储盘),但是很多互联网公司也不会考虑,主要是说出去丢人啊,总感觉只有技术实力低下的公司才会去买。。。(这点纯属个人YY)
  3. 开源块存储系统,用户体验不友好,各种操作都比较耗时,主要原因还是数据拷贝量太大,网络数据包的零拷贝一直以来都是大家改进网络IO性能的一大方向,内存数据拷贝尚且追求零拷贝,更何况硬盘数据的拷贝
  4. Ceph统一存储就几乎可以做到硬盘数据的零拷贝,当然我这里指的是正常的打快照、从快照恢复卷、从卷启动虚拟机等场景

Ceph也不是完美无缺,从各个渠道你可以得知,它也是各种性能、功能问题缠身,但我想强调的是,他是主流开源技术,尤其是配合OpenStack,简直是绝配,一个系统搞定三种存储方式(文件、块、对象),尤其是数据零拷贝这一优势,对系统的压力大减,用户体验改进十分明显。有人说10个OpenStacker9个Cepher,虽然有点夸张,但是至少表明这是一种趋势。

Ceph我也没有深入研究过,但就是对他莫名的感兴趣,想尝试一番,可以这么说,他对我的吸引力已经超出了docker。

下面列出一些我看到的Ceph的文章,供大家参考:

切换方案的代价

最后在罗嗦几句,如果某厂从自研方案切换到Ceph,要付出哪些代价?

  1. 先验证分析Ceph功能上是否满足需求
  2. 接入cinder、nova、glance这些OpenStack服务,原生支持,不需要改动
  3. 部署测试环境,测试性能是否满足需求
  4. 如果满足需求,两种存储系统测试环境并存,共同提供服务,验证可靠性、稳定性等,cinder支持多种存储后端并存在一套云平台中并同时提供服务
  5. 离线生产环境上线,也是并存方案,进一步验证和优化
  6. 真正上线到在线生产环境,并逐步淘汰自研方案,甚至两种一直共存,原系统只维护,停止开发
  7. 即使Ceph出问题,还可以使用原来的自研方案提供云硬盘服务

切换带来的好处显而易见,上面的槽点都能一一解决,而且是不费吹灰之力。。。

其实云硬盘服务的开发人员也是支持切换到Ceph的,谁不想跟着开源潮流走?谁想费时费力的开发半年,做出来一套很矬的系统,还不如开源实现来的好?

只是某厂的领导们还没下决心做这件事情,怕风险太大,砸了云计算平台的招牌,这也是可以理解的,但通过上面的切换流程,其实风险没那么大的。