谈谈OpenStack的八年之痒.docx
- 文档编号:1070577
- 上传时间:2022-10-16
- 格式:DOCX
- 页数:12
- 大小:493.16KB
谈谈OpenStack的八年之痒.docx
《谈谈OpenStack的八年之痒.docx》由会员分享,可在线阅读,更多相关《谈谈OpenStack的八年之痒.docx(12页珍藏版)》请在冰豆网上搜索。
谈谈OpenStack的八年之痒
谈谈OpenStack的八年之痒
2010年10月,OpenStack发布了第一个版本;上个月,发布了它的第十八个版本Rocky。
几年前气氛火爆,如今却冷冷清清。
Rocky版本宣布后,OpenStack群里也就出现了几篇简短的翻译过来的文章。
圈子里也不时飘出『OpenStack是不是死了?
』『谁谁谁又把全部OpenStack替换成Kubernetes了』这种消息。
这到底是为什么才短短几年却出现如此转折呢?
作为一个OpenStack用户,在这篇文章里,我会从用户视角,反思在过去的八年里,它到底走了一条怎样的路;我也会试着展望从现在起的八年之后,OpenStack会过得好不好,甚至还在不在。
我们是怎样的一个用户?
我们作为HH集团云平台团队的一部分,在集团内搭建了如下图所示的基础云平台:
其主要特征如下:
·计算:
支持KVM、ESXi和裸金属服务器等三个资源池。
·网络:
采用Neutron+VLAN+OVS实现了虚拟网络。
·存储:
采用Ceph和SAN实现了块存储,采用Ceph实现了对象存储。
·区:
在两个城市三个机房部署了3个区域,每个区域内划分资源池,资源池内再按机架划分可用区。
三个层级都用户都可见,可按需选择。
另外,我们还尝试搞过一个小型公有云区域。
·功能:
利用了Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等组件。
·管理:
采用自研云管理平台管理多个区域。
·容器云平台:
基于Kubernetes的容器云平台运行在自己管理的物理机上。
·团队:
最多时候8个人的OpenStack研发团队,3个人的运维团队。
一些感受:
·总得来说运行的还蛮好,我们在技术和产品选型、研发、运维等方面都做得不错,团队非常给力,研发周期较短,迭代快速。
现在它支撑着集团大大小小几百套系统,而且很稳定,运维压力已经比较小了。
在此,我也要感谢并肩战斗过的小伙伴们。
·也出现过一些稳定性问题:
比如NeutronVR偶尔会自动切换(我们还有一个小型公有云环境,采用Neutron+VR+OVS架构);KVM虚拟机偶尔自动重启甚至宕机等;KVM对windows的支持比较差,偶尔出现莫名其妙的问题,比如磁盘脱机、蓝屏、无法启动等。
·监控组件、日志组件很不健全,都需要我们自己大改或者从零搭建。
·除了核心模块,其它模块几乎都是半拉子工程。
以Trove为例,我们花了不少时间,几乎重写了一半的代码,也就实现了最基本的数据库实例的创建和管理功能。
·OpenStack离公有云需求的差距实在太远。
OpenStack的定位和对标到底该是什么?
OpenStack社区在2010年提出的原始使命是『提供一个满足公有云和私有云需求的开源的云计算平台』。
那个时候,私有云还没什么参照物,因此可以认为最早的时候OpenStack的使命就是做开源的AWS。
这真是一个宏伟的目标,多么让人激动人心啊,甚至搞得VMware和AWS的心里都泛起了层层涟漪!
然而,从2014年起的用户调查结果看,OpenStack做不了公有云,私有云才是OpenStack的主战场,因为两种私有云环境加起来有80%,而公有云的比率在2017年才12%,而且是在不断萎缩。
因此,说OpenStack的实际定位是在私有云,这个毋庸置疑。
企业私有云环境中,VMware是真正的老大。
因此,OpenStack这要做私有云的目标,说好听点,要向VMware学习;说难听点,就是要替代掉VMware。
而VMwarevSphere提供的只是虚拟化环境,因此OpenStack对标的对象我认为应该是『VMware的虚拟化功能』+『AWS的Cloud功能,主要是云API』。
但是,因为一开始OpenStack对标的是AWS,而AWS是公有云不是私有云,这就导致了后来很多问题的出现,下文会仔细道来。
『VMware虚拟化』+『AWSCloud功能』这两部分中,因为一开始OpenStack就是对标AWS的,因此『Cloud』部分应该说做得还是很不错的,或者说克隆的不错。
这从用户调查的『为什么组织会选择OpenStack?
』部分的答案中也能看出来,即开放平台和API的标准化是第一业务驱动力。
那『VMware虚拟化』对标部分的情况又如何呢?
来看一下VMwarevSphere和OpenStack基础功能的对比:
从上表可以看出,大部分的vSphere的功能OpenStack都没有实现,或者只实现了一点。
那结果只能是,OpenStack不具备对VMware的替代能力,也就无法驱动用户去放弃VMware转向OpenStack了。
大帐篷模式的问题到底在哪?
2015年,OpenStack社区开始使用『大帐篷』模式。
该模式把OpenStack项目分成两大类:
核心项目和非核心项目。
核心项目只有六个,其余都是非核心项目。
根据个人理解,我简单地对这个图的一些问题做下说明:
1.六个核心服务发展得确实不错,但是问题依然不少。
一方面,如下面2017年4月的用户调查结果,前几个核心项目的使用率都超过了90%。
另一方面,用户对核心项目的吐槽一直没停止过,每年的用户调查报告中都有好几页记录着用户的槽点。
1.不管是对比VMware还是对比AWS,OpenStack核心服务的范围都太小了,导致它缺乏了一些必要的功能。
我认为至少以下几个服务需要进入核心服务列表:
·编排服务Heat:
编排服务是云的基础性服务之一。
一来用户可以通过编排服务自行创建和销毁云资源,二来很多二级服务可以通过提供编排模版的方式来提供给用户,三来可以与第三方云管平台和工具对接,从而培育其生态。
·监控服务Ceilometer:
一个云生产环境离不开一个强壮的监控服务。
到目前为止,Ceilometer项目都还问题重重,比如规模性问题、性能问题、功能覆盖问题等。
·裸机服务Ironic:
裸机在私有云中有很多的应用场景,比如运行数据库、大数据平台、容器平台等。
如果OpenStack把Ironic做好了,那这就会成为与VMware相比的一大优势,同时还能成为一些需要利用裸机的应用的支撑平台。
现在的Ironic项目,实在太重太复杂,与物理网络设备关联太深。
但是,如果可以像LINUX的kickstart和cobbler一样,就灵活轻量多了,这个过程比如像vmware里物理机可以批量部署ESXI,然后把ESXI纳管进来,就可以使用VC里的所有服务,这样的过程就比较合理了。
·日志服务:
同监控服务一样,日志服务也是云平台的一个基础性服务,如同AWS的CloudWatch和所有项目都打通了一样。
遗憾的是,到现在为止,OpenStack都没有一个原生的日志服务项目。
·部署服务:
部署对私有云很重要。
OpenStack需要一个提供象MirantisFuel这样的图形化一键部署工具的核心服务。
1.OpenStack社区把过多精力耗费在了一些看起来很有前途,但实际上却比较鸡肋的服务项目中,比如容器服务Magnum、大数据服务Sahara、数据库服务Trove、容器化部署服务Kolla。
好吧,我晓得你可能有不同的看法,我不想争论,还是来看用户调查报告中的数据吧。
· 一方面,用户对这些项目很感兴趣。
我认为至少有三个原因,一来是人们对新事物都有好奇心,二来是OpenStack社区的大力宣扬,三是殷切期望。
下面的数据来自201704用户调查报告:
·但是这些服务在实际的生产环境中部署的案例却非常少,而且是越来越少:
(备注:
图中的数字是百分比)
·那到底是什么原因导致这些新服务叫好不叫座呢?
我认为有几个原因:
私有云和公有云对云平台需求的差异。
下图是一个我认为比较典型的私有云环境:
它具有几个特点:
·只有底层的物理机管理系统是统一的,而上面的多个平台是分离的。
而公有云上,云平台是统一的。
·平台是分离的。
这可能有几个原因,一是管理因素,每个平台往往由不同部门在管理和使用;二是运维因素,把平台都放在一起,运维团队搞不定这个单体平台的运维,必须分而治之;三是技术因素,私有云领域还没出现象AWS和阿里云这种能把这几个平台纳管在一起的统一云平台;四是在某些企业里限于等保和安全的需要,某个大业务需要独占资源池。
·除了基础云平台是在虚拟机级别实现多租户外,其它平台往往只是在管理平台层面实现了多租户,或者业务层面自己实现了多租户,而下面是一个或几个大的资源池。
私有云环境中和公有云环境中,这些服务(其实应该称为应用服务,与基础服务分开来)的创建和管理方式迥然不同。
在公有云环境中,因为多租户需求,云供应商需要提供这些服务的创建和管理服务,使得用户自行创建、管理和销毁这些环境。
但是,私有云中,并没有那么多需求,需要反复地创建和销毁这些服务的运行环境。
因此,在OpenStack中实现容器平台、大数据平台的自动化创建和销毁服务这种需求不那么强烈,甚至可以认为是伪需求。
针对这些新应用,OpenStack的使命首先应该是让它们在自身平台上『运行好』,而不是『把运行环境创建好』。
究其原因,我认为这和早期OpenStack的使命有关,因为一开始OpenStack是想做成开源的AWS,自然AWS的服务长什么样子,OpenStack的服务就长成什么样子。
问题是,对于私有云和公有云的区别,OpenStack一直没有重视,或者没能力重视,因为参照AWS的各个服务在OpenStack中再实现一套,相对来说是比较容易的。
而且,在OpenStack红火的时候,能开一个新的项目,是多么荣耀的事情啊,PR稿都会发好多。
那为什么不应该在这些项目上浪费那么多时间,或者社区不该带错方向呢?
·还是OpenStack的定位没有明确和及时纠正。
面对这些不断出现的新应用,OpenStack到底该做什么?
是一门心思搞好自己的一亩三分地,同时满足它们对自己的需求,实现对它们的良好支撑,还是不管如何都要去插一腿呢?
我认为本来应该选择的是前者,但社区实际上选择的是后者。
·这些应用的原生部署工具更好。
OpenStack上的对应项目,从一开始就做不好这些应用的环境的创建和管理,随着这些应用的新版本发布,差距只会越来越大,到最后只留下一些既没人维护也没有用户的半拉子项目。
·OpenStack社区中这些项目基本上都是不能进入生产环境的半拉子工程,而且改动成本相当高。
以我们使用Trove为例,在修改了几乎一半的代码后,也就实现了基本的数据库实例创建和管理功能,离实际生产需求还有不小的差距。
·OpenStack对AWS的学习只停留在『形』的表面,而没有学到『神』。
尽管AWS上有一百多个服务,但是,我们看到的是AWS扎扎实实地把基础服务做好。
举几个例子吧。
区块链现在很火是吧,AWS上目前却只提供了CloudFormation模板让用户自己去编排运行区块链的云资源;Kubernetes现在也很火是吧,但AWS却连管理K8S集群的界面都不提供。
那OpenStack对这些新型应用到底该有什么样的态度和做法呢?
我认为应该是两点:
·以不变应万变,做好这些新应用的运行基础架构环境,使得这些服务可以良好地运行在由OpenStack管理的虚拟机/物理机、网络和存储中。
·做好Heat服务,象AWS一样提供好模版,在用户需要的时候,管理员使用这些模版把这些环境编排出来,然后交给普通用户使用即可。
为什么OpenStack在青年时期就出
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 谈谈 OpenStack 八年