openstack 8年！我在OpenStack路上走过的坑。。。

2010年10月，OpenStack发布了第一个版本；上个月，《洛基》第18版上映。前几年大气热，现在冷清了。洛基版公布后，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的云功能，主要是云API”’。但是由于OpenStack最初针对的是AWS，而AWS是公有云，不是私有云，这就导致了后来的很多问题，下面会详细说明。

在“VMware虚拟化”和“AWS云功能”两个部分中，由于OpenStack最初是针对AWS的，所以“云”部分应该说做得很好，或者说克隆得很好。这是来自用户调查“机构为什么选择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 APICinder SRM 站点灾难恢复 有Freezer 项目，但尚不足以进入生产环境。

从上表可以看出，大部分的vSphere功能，OpenStack，还没有实现，或者只实现了一点点。结果只能是OpenStack没有取代VMware的能力，不能驱使用户放弃VMware而转向OpenStack。

大帐篷模式有什么问题？

2015年，OpenStack社区开始使用“大帐篷”模式。该模型将OpenStack项目分为核心项目和非核心项目两类。核心项目只有6个，其余都是非核心项目。

根据我个人的理解，我将在此图中简要说明一些问题:

六个核心服务发展得确实不错，但是问题依然不少。 一方面，如下面2017年4月的用户调查结果，前几个核心项目的使用率都超过了90%。另一方面，用户对核心项目的吐槽一直没停止过，每年的用户调查报告中都有好几页记录着用户的槽点。

不管是对比VMware 还是对比AWS，OpenStack核心服务的范围都太小了，导致它缺乏了一些必要的功能。我认为至少以下几个服务需要进入核心服务列表： 编排服务Heat：编排服务是云的基础性服务之一。一来用户可以通过编排服务自行创建和销毁云资源，二来很多二级服务可以通过提供编排模版的方式来提供给用户，三来可以与第三方云管平台和工具对接，从而培育其生态。 监控服务Ceilometer：一个云生产环境离不开一个强壮的监控服务。到目前为止，Ceilometer 项目都还问题重重，比如规模性问题、性能问题、功能覆盖问题等。 裸机服务 Ironic：裸机在私有云中有很多的应用场景，比如运行数据库、大数据平台、容器平台等。如果OpenStack把Ironic做好了，那这就会成为与VMware相比的一大优势，同时还能成为一些需要利用裸机的应用的支撑平台。现在的Ironic项目，实在太重太复杂，与物理网络设备关联太深。但是，如果可以像LINUX的kickstart和cobbler一样，就灵活轻量多了，这个过程比如像vmware里物理机可以批量部署ESXI，然后把ESXI纳管进来，就可以使用VC里的所有服务，这样的过程就比较合理了。 日志服务：同监控服务一样，日志服务也是云平台的一个基础性服务，如同AWS 的CloudWatch和所有项目都打通了一样。遗憾的是，到现在为止，OpenStack都没有一个原生的日志服务项目。 部署服务：部署对私有云很重要。OpenStack需要一个提供象 Mirantis Fuel 这样的图形化一键部署工具的核心服务。 OpenStack社区把过多精力耗费在了一些看起来很有前途，但实际上却比较鸡肋的服务项目中，比如容器服务Magnum、大数据服务 Sahara、数据库服务 Trove、容器化部署服务Kolla。好吧，我晓得你可能有不同的看法，我不想争论，还是来看用户调查报告中的数据吧。 一方面，用户对这些项目很感兴趣。我认为至少有三个原因，一来是人们对新事物都有好奇心，二来是OpenStack社区的大力宣扬，三是殷切期望。下面的数据来自201704 用户调查报告：

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

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

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

下图是我认为的典型私有云环境:

它有几个特点:

只有底层的物理机管理系统是统一的，而上面的多个平台是分离的。而公有云上，云平台是统一的。 平台是分离的。这可能有几个原因，一是管理因素，每个平台往往由不同部门在管理和使用；二是运维因素，把平台都放在一起，运维团队搞不定这个单体平台的运维，必须分而治之；三是技术因素，私有云领域还没出现象AWS和阿里云这种能把这几个平台纳管在一起的统一云平台；四是在某些企业里限于等保和安全的需要，某个大业务需要独占资源池。 除了基础云平台是在虚拟机级别实现多租户外，其它平台往往只是在管理平台层面实现了多租户，或者业务层面自己实现了多租户，而下面是一个或几个大的资源池。

在私有云环境和公有云环境中，这些服务是以非常不同的方式创建和管理的。在公共云环境中，由于多租户的需求，云提供商需要提供这些服务的创建和管理服务，以便用户可以自己创建、管理和销毁这些环境。但是在私有云中，并没有那么多需求，需要反复创建和破坏这些服务的运行环境。所以在OpenStack中实现容器平台和大数据平台自动创建和销毁服务的需求并没有那么强烈，甚至可以认为是虚假需求。对于这些新的应用，OpenStack的使命应该是在自己的平台上“运行良好”，而不是“创造良好的运行环境”。

究其原因，我认为与早期的OpenStack的使命有关，因为OpenStack一开始就想做开源的AWS，OpenStack的服务看起来会像AWS服务的样子。问题是OpenStack从来没有关注过私有云和公有云的区别，或者说没有能力关注，因为参考AWS在OpenStack中实现另一套服务相对容易。而且在OpenStack蓬勃发展的时候，开一个新项目是一件很光荣的事情，会发布很多PR稿。

那我们为什么不应该在这些项目上浪费那么多时间，或者社区不应该走错方向？

还是OpenStack的定位没有明确和及时纠正。面对这些不断出现的新应用，OpenStack到底该做什么？是一门心思搞好自己的一亩三分地，同时满足它们对自己的需求，实现对它们的良好支撑，还是不管如何都要去插一腿呢？我认为本来应该选择的是前者，但社区实际上选择的是后者。 这些应用的原生部署工具更好。OpenStack上的对应项目，从一开始就做不好这些应用的环境的创建和管理，随着这些应用的新版本发布，差距只会越来越大，到最后只留下一些既没人维护也没有用户的半拉子项目。 OpenStack 社区中这些项目基本上都是不能进入生产环境的半拉子工程，而且改动成本相当高。以我们使用Trove为例，在修改了几乎一半的代码后，也就实现了基本的数据库实例创建和管理功能，离实际生产需求还有不小的差距。 OpenStack 对 AWS 的学习只停留在『形』的表面，而没有学到『神』。尽管AWS 上有一百多个服务，但是，我们看到的是AWS 扎扎实实地把基础服务做好。举几个例子吧。区块链现在很火是吧，AWS 上目前却只提供了 CloudFormation 模板让用户自己去编排运行区块链的云资源；Kubernetes 现在也很火是吧，但AWS 却连管理K8S集群的界面都不提供。

OpenStack应该对这些新应用持什么样的态度和做法？我觉得应该是两点:

以不变应万变，做好这些新应用的运行基础架构环境，使得这些服务可以良好地运行在由OpenStack管理的虚拟机/物理机、网络和存储中。 做好Heat服务，象AWS一样提供好模版，在用户需要的时候，管理员使用这些模版把这些环境编排出来，然后交给普通用户使用即可。

为什么OpenStack在青年时期会出现中年危机？

我觉得有几个原因。当然，这肯定不是全部。

容器的出现对OpenStack的影响很大。但是我们也要看到，容器的出现并没有导致以AWS为代表的VMware和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 的分离之势的。

社区未能规划和控制OpenStack的发展方向，在关键的开发阶段浪费了宝贵的时间和资源。如前所述，OpenStack社区未能很好的定位自己，专注于基础核心服务，使得底层稳固。相反，就像一个年轻人，年轻的时候不好好学习，好好练习，却被外面的世界吸引，整天不干活，到了成年，却发现自己根本培养不了自己的竞争力。另外，出现问题时，社区未能及时扭转局面，纠正发展方向。

有些OpenStack创业公司太浮躁，做不好关键产品研发和服务。巅峰时期，有些创业公司追求的是社区的贡献，不管贡献的质量，甚至贡献；追求的是用户数量，不管项目能不能做，用户会不会满意；追求PR文章和各种炒作，却没有认真做用户案例。总之，产品和服务做得不好，用户对OpenStack的口碑和信心都没有建立起来。相反，一些认真做产品的公司的OpenStack云业务发展的非常好，说明OpenStack可以做的很好，用户也愿意使用。

很多客户，尤其是大部分传统企业，实际上是使用VMware进行虚拟化的，不一定需要云。公司的运维体系、资源交付体系、应用R&D、运维设计架构在虚拟化时代还是一样的，VMware支持现有应用就够了。这可以从其财务报告中的VMware收入持续增长看出。所以这些客户从VMware转到OpenStack的动机其实是个大问题。

OpenStack的未来如何？

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

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

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

可惜从目前的情况来看，OpenStack应该是走在第一条路上。也许这就是为什么很多人认为OpenStack奄奄一息，甚至死亡。

我对OpenStack的感受

我对OpenStack有很深的感情。它让我知道了什么是云，云是如何构建的，云是如何运行的，云是如何维护的等等。从学习它开始，我就开始从传统的软件领域进入云领域，也开始了写博客的漫漫征途，通过它结交了很多朋友。所以，看到有人故意诋毁它，甚至向它扔石头，是非常不愉快的。其实我觉得不光是我，整个IT界都应该感谢OpenStack，它的出现大大加速了IT架构的演进。

以上内容大部分可能会被喷，但请理解我的心情，因为OpenStakc本来可以发展的更好。毕竟它曾经有过这么好的时间，地点，人。根据实际情况，如果企业有一个OpenStack R&D团队，或者找到一个可靠的外部供应商，并且规模不是特别大，业务也没有那么复杂，并且有几个强大的运维，那么OpenStack私有云仍然可以很好的运行。至少在国内，OpenStack已经成为自主可控的私有云平台的主要代表之一，在各行各业发光发热。

无论IT如何收场，OpenStack都会在IT发展史上留下浓墨重彩的一笔。在此，我要感谢OpenStack项目，感谢OpenStack的每一行代码和每一份文档，感谢OpenStack社区，感谢所有为OpenStack做出贡献的公司和人。

作者简介:

云爱好者和实践者刘世民是微信官方账号和科技博客的博主。