求索阁

近年新型技术不断涌现，容器、AI、区块链、SDN等技术应接不暇，很多搞OpenStack的开始转向研究其他技术，OpenStack的活跃度也确实没有前几年高了。最近更是频频一些诸如某某技术取代OpenStack、某某公司放弃OpenStack、OpenStack陷入中年危机等PR或者文章出现，很多人开始担忧OpenStack的前途。作为折腾OpenStack也有5年多，既是OpenStack Developer，也是OpenStack User，也谈谈我自己的看法。

这几年大家都在提去IOE，讲自主可控，我认为未来数据中心基础设施中的计算资源发展趋势将是X86+KVM+开源云如OpenStack/Kubernetes，这也是很多传统IT公司自主可控最有效最快的途径。OpenStack的强势在于IaaS，我认为这一块已经做得挺好了，至少可以用起来了，足够满足用户的资源集中式纳管、资源分布式调度与分配等大多数功能需求。Nova、Neutron、Cinder越来越稳定，功能也完善了很多。

若站在用户的角度以及产品的角度，现在OpenStack的外围系统如管理界面、监控系统、日志系统、部署工具等确实做得不是那么完善，但我认为这都是无可厚非的。外围系统企业都有自己的一套标准和规范，社区不可能做出一个能契合所有企业需要的工具，更做不了拿来即用、开箱即用的企业一体化方案，OpenStack也从来没有这么说过。社区提供了开放的API让企业很易于集成现有外围系统或者开源工具，如puppet、logstash、pacemaker、haproxy等。

那些很难定标准的东西开源做不了，否则就必然绑死在一家或者少数家之上。比如OpenStack高可用，假定社区决定使用pacemaker做，很多公司肯定又不愿意，为什么要用pacemaker，万一pacemaker出现问题，又有一堆人吐槽OpenStack这不好，那不好，这不可靠、那不稳定、就是不靠谱。我们现在生产环境还有一套OpenStack使用pacemaker实现虚拟机高可用，内存泄露的问题一直没有解决，吃完内存吃swap，不得不定时重启。因此社区这个做不了，但在文档中有关于使用pacemaker实现OpenStack高可用的介绍作为参考，这已经足够了。

我认同UNIX的设计理念，所谓Do one thing，and do it well。Linux中没有哪个命令或者工具能够解决你的所有问题，但组合起来可以，管道是一个很强大的功能，OpenStack的API就像管道。之前有人吐槽Linux为什么没有一个标准的IDE，集开发、编译、调试、打包，我当时辩论说没有这个必要，暂且不说集成这么多工具会有多臃肿，做出的样子就一定能够保证所有挑剔用户喜欢吗？所以Linux目前也没有一款标准的所谓官方的IDE，但目前存在很多开源的以及厂商开发的IDE，这其中很多工具底层都离不开vim、gcc、gdb，比如DevC++。OpenStack就好比现在的Linux kernel，永远不要指望OpenStack做成ALL in一体化方案，帮你做个镜像装在U盘一键部署几千节点，帮你监控所有系统，帮你处理各类日志，还要厂商干嘛，毕竟OpenStack社区不是公司，不要拿OpenStack当乙方，更不是苦力。不要说社区，就人的本性来说，谁都更想做核心功能，而不愿意做那些吃力不讨好的东西。

关于OpenStack稳定性问题，很多人没有区分根源是底层故障还是平台故障。之前在解决客户问题中遇到很多故障，发现其实很多都是由于底层网络、存储、中间件（消息队列、数据库）引起的。在一些老版本OpenStack中，可能会由于Nova丢消息导致虚拟机一直卡在一个状态或者Nova与Cinder卷状态不一致导致卸不了盘，新版本OpenStack平台本身改善了很多。加上OpenStack各个组件基本都可以实现AA高可用，比如API服务通过LB实现实例冗余、RPC服务本身就支持多实例部署，新版本中cinder-volume也支持通过分布式锁实现AA高可用，在使用共享存储前提下nova-compute挂了虚拟机也可以触发疏散迁移实现虚拟机HA。再加上监控系统保障，真正OpenStack平台本身无缘无故出现挂掉的概率其实并不大，即使OpenStack某些服务挂掉了，在底层存储和网络正常的情况下，基本不会影响业务运行。换句话说，保证OpenStack平台的稳定性，首先需要保证底层存储、网络的稳定性。存储不稳定可以换商业存储，ovs不稳定可以用Linux Bridge，甚至可以用硬件SDN替换Neutron整个核心只保留API，总之哪个觉得不行，就换一个自己觉得招架得住的，OpenStack没有绑定，允许你自由组合，前期规划中技术选型很重要。大家经常拿Vmware和OpenStack的稳定性做对比，很多人都说Vmware很稳定，OpenStack就是问题多。暂且不说OpenStack和Vmware对比是否合理，想想比较的时候底层硬件是否相当呢？为Vmware花了多少钱，配的都是Netapp、EMC商业存储，OpenStack用的是开源免费的Ceph存储。在前几年Ceph还不是很稳定的时候，经常会出现集群不可用的问题，很多人就归咎于OpenStack的问题。

当然，没有100%稳定的系统，OpenStack已经是一个非常复杂的分布式系统了，并且涵盖的技术包括硬件、操作系统、网络、架构、分布式、虚拟化等庞大的技术生态，出现问题不可避免，需要有强大的运维水平保障。很多人说OpenStack太复杂，难运维，试问有哪个分布式系统可以做到不复杂、不难运维了，Hadoop、Spark哪个系统真正运维起来不脱层皮。运维OpenStack难的根本原因不是由于它本身做复杂了，而是它的性质决定的，作为IaaS解决方案，它要求运维人员的技能水平包括传统服务器、数据中心、分布式、虚拟化、网络架构、操作系统、自动化、数据库、高可用、消息队列等，传统的技术以及现代技术都有。高层服务如Trove还需要对数据库的运维非常了解。而其实很多hold不住OpenStack的运维人员或者实施人员，真的很难同时具备这些能力，往往懂操作系统的不懂网络，搞网络的不懂操作系统，懂网络的还有只懂underlay传统网络不懂overlay、不懂SDN的，就算好不容易找到一个既懂操作系统又懂网络的不懂底层虚拟化、不懂数据库，靠几个人根本不可能招架得住。不要觉得搞个DevStack或者参照网上教程部署个OpenStack就觉得OpenStack很简单，信心满满觉得一个人就能搞定OpenStack的所有事，真正出事的时候找不到头绪，是不是OpenStack平台的问题都确定不了，明明是底层网络故障或者存储挂了，看到一堆OpenStack服务ERROR了就说OpenStack真烂。真正要能hold得住OpenStack，必须靠多个团队协作运维与支持，大公司还好，很多小公司很难具备这么完备的运维团队，往往是一个人或者几个人就负责整个项目的沟通、实施交付、测试、运维等整个周期。至少国内就有一家大公司就做得还不错，自动化部署和自动化运维平台做得也很好，至少我们的环境到现在没有出现什么大的问题。

用户应该公平的对待和包容OpenStack，不应该持偏见态度，我遇到很多客户只要OpenStack出点问题就开始吐槽OpenStack不稳定、不靠谱，零容忍。但vcenter出点问题就感觉理所当然，毕竟有Vmware大公司背书，而又有谁替OpenStack背书？

另外谈谈OpenStack的一些其他IaaS+项目以及PaaS相关高级服务项目，如Trove、Magnum、Sahara，愿景和设计理念都是非常不错的，很有价值，扩展生态，更是体现了社区的开放心态、胸怀格局以及生态意识，而不是非得扬言替换谁拼得你死我活，只是有些项目进展的确实不是那么好 ，很多原因。用户认为是OpenStack做杂了，精力分散了，我认为人手不足（很多人转向容器、AI）以及用户刚需没那么聚焦（部署OpenStack一定会用虚拟机，但不一定要用容器和大数据）是很重要的两个原因，毕竟越到高层，可组合的方案就越多，用户就越分散，用的人越少，反馈得也越少，投入的开发人员也必然减少，OpenStack很多项目基本就是一两个人坚持在维护。

OpenStack从来没有承诺一定要做公有云超AWS，所以不要对着AWS的一点一点职责OpenStack，AWS多少团队做了多少年。OpenStack也没有承诺一定要做成私有云超Vmware。OpenStack能做成什么样，除了OpenStack自身提供一个核心，做成什么样，看公司的本事。我看国内就有好几家基于OpenStack做公有云做得也还不错的，也有公司基于OpenStack做私有云交付也不错的。不要指望OpenStack开箱就是一个公有云，打开就是一个私有云。

有人说社区没管好，功利性太强，Openstack 社区搞那个commits统计，搞得现在参与开源不是考虑技术本身，很多都是看那个数字。我认为“功利”是部分合理的，开源也需要公司支持和投入，排除个别几个做开源纯粹的geek，只为情怀，大多数公司都算kpi的，不是做慈善，得有利益驱动。确实有少数人投机取巧刷commit，但这毕竟少数，并不代表整个社区氛围。还有人说社区无休止的扯皮，OpenStack成员来自世界各地各大公司，扯皮的事不可避免，不说社区，就是公司这个个体，不也经常无休止扯皮，无休止开无意义的会议吗？

关于OpenStack的未来，我还是坚持乐观态度。虽然目前确实大不如从前活跃度高，但已经有大量客户在大规模使用，包括各行各业，如互联网、银行以及运营商，无论是私有云还是公有云，并且还在不断扩展新集群，不断在新部署，短期内不会有被完全取代的可能。它的发展趋势可能会像Linux一样，即便不再是饭桌上天天聊得火热的话题，也必将在IDC中处处存在它的身影。退一万步说，假如真的OpenStack如当年的CloudStack一样，逐渐被另一种IaaS解决方案xxxStack1、xxxStack2取代，OpenStack也将会存在于任何xxxStack中，就如UNIX系统一样，形体永远存在于Linux、BSD中。

另外对于我个人，由衷感谢OpenStack。从研一开始折腾OpenStack，通过OpenStack让我逐渐从一点都不通云计算的小白到现在对云计算有了些理解和认识，了解了云计算是如何运转和落地的。在OpenStack开发中，也学到了很多工程上的知识和技能，分布式系统组件之间如何通信，如何实现高可用，软件架构的设计理念等等。同时，也认识了很多云计算领域的先辈大牛们，向他们学到了很多技能。

本来原标题是《我为OpenStack正名》的，后来想想，正名这个词表达主观针对性太强了。毕竟一千个人眼中有一千个哈姆雷特，必然会有千万种不同的看法和争议，我认为没有绝对的谁对谁错，更没有正邪之分，大家站在不同的视角自然有不同的观点，不同的诉求。大家一块争论也是好事，多争几次，多发表各自的看法，说不定大家反而更理解对方了，也能让大家能从更多的维度去真正了解OpenStack，同时也可以暴露一些确实存在的一些问题。因此本文仅代表我个人的看法，不存在讨伐谁、正名谁这么一说。如果你也认同我的观点，请点上一赞，让我知道有人和我存在一样的看法。如果不认同，也欢迎在评论中讨论，碰碰撞撞，或许能碰出不一样的火花 .

作者：int32bit 写于2018.9.18