投递人 itwriter 发布于 2018-09-14 16:43 原文链接 [收藏] « »

云计算,云计算,OpenStack,AWS,CloudStack

  2010 年 10 月,OpenStack 发布了第一个版本;上个月,发布了它的第 18 个版本 Rocky。几年前气氛火爆,如今却冷冷清清。Rocky 版本宣布后,OpenStack 群里也就出现了几篇简短的翻译过来的文章。圈子里也不时飘出“OpenStack 是不是死了?”“谁谁谁又把全部 OpenStack 替换成 Kubernetes”了这种消息。这到底是为什么才短短几年却出现如此转折呢?作为一个 OpenStack 用户,在这篇文章里,我会从用户视角,反思在过去的八年里,它到底走了一条怎样的路;我也会试着展望从现在起的八年之后,OpenStack 会过得好不好,甚至还在不在。 

  我们是怎样的一个用户?

  我们作为 HH 集团云平台团队的一部分,在集团内搭建了如下图所示的基础云平台:

集团 OPenStack

  其主要特征如下:

  计算:支持 KVM、ESXi 和裸金属服务器等三个资源池。

  网络:采用 Neutron + VLAN + OVS 实现了虚拟网络。

  存储:采用 Ceph 和 SAN 实现了块存储,采用 Ceph 实现了对象存储。

  区:在两个城市三个机房部署了 3 个区域,每个区域内划分资源池,资源池内再按机架划分可用区。三个层级都用户都可见,可按需选择。另外,我们还尝试搞过一个小型公有云区域。

  功能:利用了 Mitaka 版本中的 Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic 等组件。

  管理:采用自研云管理平台管理多个区域。

  容器云平台:基于 Kubernetes 的容器云平台运行在自己管理的物理机上。

  团队:最多时候 8 个人的 OpenStack 研发团队,3 个人的运维团队。

  一些感受:

  总得来说运行的还蛮好,我们在技术和产品选型、研发、运维等方面都做得不错,团队非常给力,研发周期较短,迭代快速。现在它支撑着集团大大小小几百套系统,而且很稳定,运维压力已经比较小了。在此,我也要感谢并肩战斗过的小伙伴们。

  也出现过一些稳定性问题:比如 Neutron VR 偶尔会自动切换(我们还有一个小型公有云环境,采用 Neutron + VR + OVS 架构);KVM 虚拟机偶尔自动重启甚至宕机等;KVM 对 windows 的支持比较差,偶尔出现莫名其妙的问题,比如磁盘脱机、蓝屏、无法启动等。

  监控组件、日志组件很不健全,都需要我们自己大改或者从零搭建。

  除了核心模块,其它模块几乎都是半拉子工程。以 Trove 为例,我们花了不少时间,几乎重写了一半的代码,也就实现了最基本的数据库实例的创建和管理功能。

  OpenStack 离公有云需求的差距实在太远。

  OpenStack 的定位和对标到底该是什么?

  OpenStack 社区在 2010 年提出的原始使命是『提供一个满足公有云和私有云需求的开源的云计算平台』。那个时候,私有云还没什么参照物,因此可以认为最早的时候 OpenStack 的使命就是做开源的 AWS。这真是一个宏伟的目标,多么让人激动人心啊,甚至搞得 VMware 和 AWS 的心里都泛起了层层涟漪!然而,从 2014 年起的用户调查结果看,OpenStack 做不了公有云,私有云才是 OpenStack 的主战场,因为两种私有云环境加起来有 80%,而公有云的比率在 2017 年才 12%,而且是在不断萎缩。因此,说 OpenStack 的实际定位是在私有云,这个毋庸置疑。

OP 私有云

  企业私有云环境中,VMware 是真正的老大。因此,OpenStack 这要做私有云的目标,说好听点,要向 VMware 学习;说难听点,就是要替代掉 VMware。而 VMware vSphere 提供的只是虚拟化环境,因此 OpenStack 对标的对象我认为应该是 『VMware 的虚拟化功能』+『AWS 的 Cloud 功能,主要是云 API』。但是,因为一开始 OpenStack 对标的是 AWS,而 AWS 是公有云不是私有云,这就导致了后来很多问题的出现,下文会仔细道来。 

  『VMware 虚拟化』+『AWS Cloud 功能』这两部分中,因为一开始 OpenStack 就是对标 AWS 的,因此 『Cloud』部分应该说做得还是很不错的,或者说克隆的不错。这从用户调查的『为什么组织会选择 OpenStack?』部分的答案中也能看出来,即开放平台和 API 的标准化是第一业务驱动力。 

hangye-op3.jpg

  那『VMware 虚拟化』对标部分的情况又如何呢?来看一下 VMware vSphere 和 OpenStack 基础功能的对比:

hangye-op11.jpg

hangye-op12.jpg

  从上表可以看出,大部分的 vSphere 的功能 OpenStack 都没有实现,或者只实现了一点。那结果只能是,OpenStack 不具备对 VMware 的替代能力,也就无法驱动用户去放弃 VMware 转向 OpenStack 了。

  大帐篷模式的问题到底在哪?

  2015 年,OpenStack 社区开始使用『大帐篷』模式。该模式把 OpenStack 项目分成两大类:核心项目和非核心项目。核心项目只有六个,其余都是非核心项目。

OpenStack

  根据个人理解,我简单地对这个图的一些问题做下说明:

  1、六个核心服务发展得确实不错,但是问题依然不少。

  一方面,如下面 2017 年 4 月的用户调查结果,前几个核心项目的使用率都超过了 90%。另一方面,用户对核心项目的吐槽一直没停止过,每年的用户调查报告中都有好几页记录着用户的槽点。

hangye-op5.jpg

  2、不管是对比 VMware 还是对比 AWS,OpenStack 核心服务的范围都太小了,导致它缺乏了一些必要的功能。我认为至少以下几个服务需要进入核心服务列表:

  编排服务 Heat:编排服务是云的基础性服务之一。一来用户可以通过编排服务自行创建和销毁云资源,二来很多二级服务可以通过提供编排模版的方式来提供给用户,三来可以与第三方云管平台和工具对接,从而培育其生态。

  监控服务 Ceilometer:一个云生产环境离不开一个强壮的监控服务。到目前为止,Ceilometer 项目都还问题重重,比如规模性问题、性能问题、功能覆盖问题等。

  裸机服务 Ironic:裸机在私有云中有很多的应用场景,比如运行数据库、大数据平台、容器平台等。如果 OpenStack 把 Ironic 做好了,那这就会成为与 VMware 相比的一大优势,同时还能成为一些需要利用裸机的应用的支撑平台。现在的 Ironic 项目,实在太重太复杂,与物理网络设备关联太深。但是,如果可以像 LINUX 的 kickstart 和 cobbler 一样,就灵活轻量多了,这个过程比如像 vmware 里物理机可以批量部署 ESXI,然后把 ESXI 纳管进来,就可以使用 VC 里的所有服务,这样的过程就比较合理了。

  日志服务:同监控服务一样,日志服务也是云平台的一个基础性服务,如同 AWS 的 CloudWatch 和所有项目都打通了一样。遗憾的是,到现在为止,OpenStack 都没有一个原生的日志服务项目。

  部署服务:部署对私有云很重要。OpenStack 需要一个提供象 Mirantis Fuel 这样的图形化一键部署工具的核心服务。

  3、OpenStack 社区把过多精力耗费在了一些看起来很有前途,但实际上却比较鸡肋的服务项目中,比如容器服务 Magnum、大数据服务 Sahara、数据库服务 Trove、容器化部署服务 Kolla。好吧,我晓得你可能有不同的看法,我不想争论,还是来看用户调查报告中的数据吧。

  一方面,用户对这些项目很感兴趣。我认为至少有三个原因,一来是人们对新事物都有好奇心,二来是 OpenStack 社区的大力宣扬,三是殷切期望。下面的数据来自 201704 用户调查报告:

hangye-op6.jpg

  但是这些服务在实际的生产环境中部署的案例却非常少,而且是越来越少:

hangye-op7.jpg

  (备注:图中的数字是百分比)

  那到底是什么原因导致这些新服务叫好不叫座呢?我认为有几个原因:

  (1)私有云和公有云对云平台需求的差异。

  下图是一个我认为比较典型的私有云环境:

私有云环境

  它具有几个特点:

  只有底层的物理机管理系统是统一的,而上面的多个平台是分离的。而公有云上,云平台是统一的。

  平台是分离的。这可能有几个原因,一是管理因素,每个平台往往由不同部门在管理和使用;二是运维因素,把平台都放在一起,运维团队搞不定这个单体平台的运维,必须分而治之;三是技术因素,私有云领域还没出现象 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 在青年时期就出现了中年危机呢? 

  我认为有如下几个原因。当然了,这肯定不是全部。

  (1)容器的出现,对 OpenStack 的冲击很大。但是,我们也要看到,容器的出现,并没有使得 VMware 和以 AWS 为代表的 IaaS 云服务商叫苦连天。OpenStack 该做的不是去抱怨『既生瑜,何生亮』,而应该是反思为什么 OpenStack 没能做好容器的底层架构。

  以 AWS 为例,它有两个容器相关项目,一个是它自研的 ECS,这是一个 Docker 容器管理服务,容器运行在 EC2 主机上。另一个是 EKS,是一个 Kubernetes 运行环境的创建和管理服务。AWS 为了支撑容器,主要做了几件事情:1. 创造了 amazon-ecs-cni-plugin 项目,使得容器可以很好地运行在 VPC 中。2. 打通了用户权限,用户可以使用 AWS 的账号登录到 Kubernetes 环境中。3. 实现了一套 Docker 容器管理服务,以及 K8S 管理节点。

  反观 OpenStack 对容器的支持,它主要做了几件事情,一是大张旗鼓搞 Magnum 项目,花很大力气做 K8S 环境的编排。另一个是有几个网络相关的项目,但是好像也没什么人在用。

  结果就是,在 OpenStack 环境中,K8S 环境的编排也没做好(当然了,要不要在私有云中做 K8S 集群的创建和管理,前面有过讨论),K8S 在 OpenStack 环境中也运行不好(因为针对 K8S 的网络、存储都没怎么搞好)。所以,我认为,是 OpenStack 没有及时为 K8S 做好支撑,才导致 K8S 和 OpenStack 的分离之势的。

  (2)社区没规划和控制好 OpenStack 的发展方向,在关键的发展阶段浪费了宝贵的时间和资源。前面讲过,OpenStack 社区没能做好自己的定位,并聚焦于基础性的核心服务,把底部做结实。相反,就像一个毛头小伙一样,年轻时不好好学习苦练内功却被外面的花花世界吸引,成天不务正业,到了成年时却发现没能培养其基本的竞争力。另外,在问题出现的时候,社区没能做到力挽狂澜,没能及时纠正发展方向。

  (3)部分 OpenStack 创业公司太浮躁,没能做好非常关键的产品研发和服务。在高峰时,一些创业公司们追求的是社区的贡献量,而不管贡献质量,甚至是刷贡献量;追求的是用户数量,不惜以低于成本价的方式,而不管项目能不能做成,用户会不会满意;追求的是 PR 文章和各种炒作,而没能认真地去做用户案例。总之,产品和服务没有做好,用户对 OpenStack 的口碑和信心没有树立起来。相对地,一些认认真真做产品的公司,其 OpenStack 云业务却发展得很好,这说明 OpenStack 其实是可以做好的,用户也是愿意用的。

  (4)很多客户,特别是大部分传统企业,实际上用 VMware 虚拟化就够了,不一定需要用云。公司的运维体系、资源交付体系,以及应用的研发、运行和设计架构,都还是虚拟化时代的那一套,因此 VMware 支撑现有应用也够了。这从 VMware 财报上其收入继续增长也能看出来。 因此,让这些客户从 VMware 转到 OpenStack 的动力能有多大,其实是个很大的问题。

  OpenStack 的未来到底会如何呢?

  个人认为 OpenStack 的未来会有两条路:

  一条是 OpenStack 只作为 KVM 虚拟机和 Ceph 存储卷的编排器而会走的路。这条路走下去,它会免不了走到和 CloudStack 这样的开源云平台同样的结局,那就是还未真正兴起就开始真正凋零。

hangye-op9.jpg

  另一条是 OpenStack 走 AWS 甚至 VMware 的道路,成为基础云、原生云和未来 Serverless 云的支撑平台。这种情况下,它的路会很长。

hangye-op10.jpg

  但是,遗憾的是,从现在的情况看,OpenStack 应该是走在第一条路上,也许这就是很多人认为 OpenStack 快死掉了甚至已经死掉了的原因吧。 

  我对 OpenStack 的感情 

  我对 OpenStack 有着挺深的感情。是它,让我认识了什么是云,云是怎么构建的、是如何运行的、是如何维护的等等。是从研究它开始,我开始从传统软件领域进入了云领域,我也开始了写博客的漫漫历程,也通过它结识了很多朋友。因此,当看到有人故意诋毁它,甚至对它落井下石时,心里很不是滋味。其实,我觉得不光是我,整个 IT 领域都应该感谢 OpenStack,它的出现大大加速了 IT 架构演进进程。

  前面的内容,也许喷的成分居多,但是,请理解我的心情,因为本来 OpenStakc 是可以发展得更好的,毕竟它曾经拥有过多么好的天时、地利和人和啊。从实际情况来看,如果企业有一个 OpenStack 研发团队,或者找了一个靠谱的外部供应商,而且规模不是特别大,业务不是那么复杂,还有几个给力的运维,OpenStack 私有云还是可以跑得挺好的。至少在国内,OpenStack 已经成为了自主可控的私有云云平台的主要代表之一,在各行各业发光发热。

  不管它的结局如何,OpenStack 都将在 IT 发展史上留下了浓墨重彩的一笔。 在此,我想感谢 OpenStack 项目、感谢 OpenStack 每一行代码和每一个文档、OpenStack 社区,和所有给 OpenStack 做过贡献的公司和人们。

 
来自: www.iyiou.com
找优秀程序员,就在博客园 收藏 新浪微博 分享至微信
标签: OpenStack

24小时阅读排行

    最新新闻

      相关新闻