OpenStack的八年之痒

2010年10月，OpenStack发布了第一个版本；上个月，发布了它的第18个版本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我的的运维团队。

一些感觉：

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

• 也出现过一些稳定性问题：好比Neutron VR 偶尔会自动切换（咱们还有一个小型公有云环境，采用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。而 VMware vSphere 提供的只是虚拟化环境，所以 OpenStack 对标的对象我认为应该是 『VMware的 虚拟化功能』+『AWS的 Cloud 功能，主要是云API』。可是，由于一开始 OpenStack 对标的是 AWS，而AWS 是公有云不是私有云，这就致使了后来不少问题的出现，下文会仔细道来。 

 『VMware 虚拟化』+『AWS Cloud 功能』这两部分中，由于一开始OpenStack 就是对标AWS的，所以 『Cloud』部分应该说作得仍是很不错的，或者说克隆的不错。这从用户调查的『为何组织会选择OpenStack？』部分的答案中也能看出来，即开放平台和API的标准化是第一业务驱动力。 

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

VMware 功能	描述	相应的OpenStack功能
vMotion	可使运行中的虚拟机从一台物理服务器实时迁移到另外一台物理服务器，它实现了零停机时间和连续可用的服务。vSphere 6.0 支持跨数据中心的vMotion。	能够利用 KVM live migration 功能实现虚拟的实时迁移，可是须要结合第三方工具。
DRS（分布式资源调度）	跨资源池不间断地监控利用率，并根据反映业务须要和不断变化的优先级的预约义规则，在多台虚拟机之间智能地分配可用资源。	不支持。
分布式电源管理（DPM）	DPM提供了经过动态调整群集容量来匹配虚拟机资源需求，以达到节省电力的目的，DPM自动整合虚拟机到较少的ESXi主机上，并对必定周期内资源利用率低的多于ESXi主机执行断电，若是资源需求增长，ESXi主机从新通电回到群集，虚拟机从新分配到群集内全部可用的ESXI主机上。	不支持。
HA	持续监控资源池中的全部物理服务器，并重启受服务器故障影响的虚拟机。还能够监控和检测虚拟机的“客户操做系统”故障，并在用户指定的间隔后自动启动虚拟机	不支持。
FT	经过建立和维护等同于主虚拟机并可在发生故障切换时替换主虚拟机的辅助虚拟机来为虚拟机提供连续可用性	不支持。
vShield	VMware 安全虚拟设备套件	Neutron 的安全组和防火墙实现了 vShield 的部分功能
vDS（分布式虚拟交换机）	让用户能够从一个集中界面为整个数据中心设置虚拟机访问交换，从而简化虚拟机网络链接。	Neutron 利用 OVS 实现了部分功能
Storage API		Cinder
SRM	站点灾难恢复	有Freezer 项目，但尚不足以进入生产环境。

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

大账篷模式的问题到底在哪？

2015年，OpenStack 社区开始使用『大账篷』模式。该模式把OpenStack项目分红两大类：核心项目和非核心项目。核心项目只有六个，其他都是非核心项目。

 

根据我的理解，我简单地对这个图的一些问题作下说明：

1. 六个核心服务发展得确实不错，可是问题依然很多。

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

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 用户调查报告：

 

• 可是这些服务在实际的生产环境中部署的案例却很是少，并且是愈来愈少：

 

（备注：图中的数字是百分比）

• 那究竟是什么缘由致使这些新服务叫好不叫座呢？我认为有几个缘由：

（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这样的开源云平台一样的结局，那就是还未真正兴起就开始真正凋零。

 

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

 

可是，遗憾的是，从如今的状况看，OpenStack应该是走在第一条路上，也许这就是不少人认为OpenStack快死掉了甚至已经死掉了的缘由吧。 

我对OpenStack的感情 

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

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

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

 

谢谢您的阅读，欢迎关注个人我的公众号：

 

在个人微信公众号上发表文章后，一天以后的阅读状况以下：

因此也庆祝一下本人第一篇阅读过万的公众号文章。：）

再对比一下在博客园的阅读量和点赞数，我有几点感觉：

• 网站式博客在公众号面前的竞争力已经很弱了。移动端的阅读量已经占据绝大多数。
• 博客园的文章更多聚焦前端技术，以及较传统的软件开发技术，好比.Net 这种。
• 微信公众号粉丝人数由于这篇文章增加了800多人，而博客园上粉丝只增长了2人。
• 博客园的运营模式也许在新形势下须要有从新思考了。