6年！我对赖以挣小钱渡日的OpenStack淌过的河...

6年！我对赖以挣小钱渡日的OpenStack淌过的河...

成都-子凡 云技术之家 云技术之家

微信号 cloudtech1024

功能介绍 传播新技术，关注云计算、大数据、虚拟化、AI、安全、区块链、物联网、云运维、存储、分布式、OpenStack、SDN、Ceph等前沿领域发展，分享资讯、经验、技术、坚持干货。

昨天

看了世民的《8年！我在OpenStack路上走过的坑。。。》 一文，作为从2012年从E开始使用OpenStack的相对老手，我倒是想和一篇文章，谈一下这6年多的时间对于OpenStack使用的感受与认识，但因眼光与视野有限，所论之处，见仁见智，各有千秋，只为一时兴致所至，花开八朵。

 

我从modem时代开始弄计算机、网络与软件，在大家无法想像的时点，1991年，当3+/Novell网络兴起时，已开始使用TCP/IP, 对这种无中心节点的通信方式深感好奇；1993年底就使用Frame Relay（帧中继）方式配合当时正在建设之中的中国第一个数据通信局（上海）以加拿大新桥（new bridge）及北电设备为基础通过网桥及中央核心路由器完成了上海本地200家证卷公司与上海证卷交易所之间的网络互通互联，后又在深圳通过背对背基带64K Modem 自建微波+专线的DDN线路完成了深圳本地200家左右证卷公司与深交所间的网络联连接，......

 

我的一些从业背景

2012年2月我离开外企后想弄自己的东西，不再想给假详鬼子打工，不再想代理其他人的东西从贸易中挣钱，于是一个好的机会，在2012年5月我发现了OpenStack，并耐着性子努力在2012年8月开始建设中国第一个使用OpenStack建设的200台服务器的小型公有云系统（包含基于OpenStack API的运营门户软件开发）-成都艾普宽带云系统，并于2013年3月开始公测。当我发出同时创建100台windows服务器、100台linux服务器而系统表现良好后，高兴得不得了；只可惜后期因为中国通信行业中的运动员与裁判员集于一身的特点，这个云系统因缺乏IP地址等资源而无法持续运营下去，在2014年底左右不得不关闭。后来在四川本地又实施了接近10余个小的OpenStack工程, 也获得了许多实践经验，而本地大工程都是大公司拿走了，一直没有机会再弄一个大一点的工程。

 

话题一：OpenStack的设计和实施所需的基础

我想说出我的第一个观点：OpenStack系统的设计与实施者需要具备较深厚的技术与工程经验积累，虽然每个纵向技术领域不 一定极为深入，但宽度要足够。

 

早期我参与国内OpenStack技术群观察许多人提出的问题时，就发现了一个现象：许多OpenStack系统的设计与实施者出身为软件人员，虽然容易理解OpenStack的代码，但对传统的系统集成工程经验不足，导致投产后的OpenStack系统问题较多。网上的许文章都充满了对OpenStack“坑”的描述，一些“坑”确是OpenStack代码本身Bug所致，但另一些则来源于对一些基础知识的缺乏所至，比如对Linux系统本身、KVM本身等等不够熟悉的原因。

 

虽然可以参考网上各个安装指导的方法装起一套OpenStack系统，但如果没有这些基础，后期根本没有能力运维，说到底OpenStack只是一套资源调度管理软件系统，它是构建在服务器、操作系统、虚拟化、网络、存贮、冗余、容错、数据库、消息队例、监控........等等各纵向知识之上的，没有这些扎实的基础，很多人可以搭出一个可以运行的OpenStack系统，但必然会碰到各种“坑”，就是说，大部分“坑”源自于我们对云平台本身涉及到的方方面面基础知识的不足所致，与OpenStack无关。

 

《OpenStack部署实践》第一、二版出版后，一些读者来邮件索要电子档，希望能够容易复制其中的命令或脚本代码便于安装时不用再敲一次，我都没有给，直至出版社本身提供电子档。究其原因是，如果你喜欢或真打算弄明白OpenStack,那么最好还是把所涉及的基础知识都打好了，否则只能是玩玩或搭一个实验环境，而没有能力处理生产环境。

 

话题二：OpenStack的三种应用模式

第二个我想指出的是，OpenStack的应用模式问题。

看起来很简单的一个问题，但许多应用者并没有完全理清它，我就在这里帮助理清一下。在我的眼中，OpenStack有三种应用模式：虚拟化应用模式、私有云应用模式及公有云应用模式。

 

1.虚拟化应用模式

许多人将OpenStack的虚拟化应用模式与私有云应用模式给混淆，这也是许多用户或同仁对OpenStack一直颇有微辞的之处。我对vmware不是很熟悉，整个过程中也没有深入地去摸它的内部核心，但我觉得OpenStack的虚拟化应用模式应该与vmware 的基本模式相差不大。我在分析用户应用后，在许多小系统中均采用这种部署模式，它强大而稳定。

 

对于生产环境来说，这一应用模式的核心要点有三：

虚拟机网关指向交换机 Neutron 不需要L3服务，仅提供DHCP服务，DHCP可以冗余部署； 使用Linux Bridge而不是OVS

 

去年，由HH集团投资的一家外地的云计算公司承建的一个成都本地云计算项目因为一些原因中间商找到我这里，说那个系统不好用，磁盘IO差，而且与该公司合作关系不太好，看能不能重建。我看了一下那个系统的部署模式，是一个典型业界鼓吹的那种模式：

 

三个控制节点运行控制及网络服务（包括L3） Ceph 超融合 使用ovs 所有虚拟机均在rbd卷中

 

我最后重建了这个系统，仅仅使用了我所说的OpenStack虚拟化应用模式，存贮部分既使用了服务器本地磁盘也使用了卷，只是我使用了GlusterFS,因为这个系统基本上后期很难大规模扩容。

 

模式当然是一件事情，仁者见仁，智者见智。但核心的问题是，你有没有深入地去了解这个系统上层应用是什么样的？这个系统上层需要运行Hadoop之类的大数据存贮及分析业务，当然还有少量的的Mysql之类，应用模式也是传统的B/S三层架构, 应用仍在虚拟机中运行，短期内不会封装到docker 中。

 

如果hadoop集群三个虚拟机都运行在ceph rbd卷中，你想想，磁盘IO如何能好？

 

说到底，OpenStack的优势就在于开放与灵活，一个云系统如何设计与部署与上层业务应用类型密切相关。比如人们将ceph osd 部署到OpenStack计算节点中视为超融合，那么如果我根据上层承载的业务应用及运行模式将cinder-volume 服务部署到计算节点中算不算超融合？如果打算用一套技术方案来适应不同的业务场景，自然到处是“坑”。

 

OpenStack的虚拟化应用模式配合商业存贮，它的稳定性与性能，可以满足大部分企业的应用要求，具体情况具体分析，应该可以替换80%企业用户的vmware虚拟化平台，即企业不再需要进一步购买或扩容vmware.

 

我走到美国时，发现绝大多数美国人都在使用本国汽车，不知是否与爱国有关; 看世界杯时，也看到法国队都穿自己国家品牌的服装上场奋斗。而当我看到中兴被美国政府罚款4-10亿美元时，就在想，这什么事呀，我们这些天天加班加点工作的人弄了半天给美国政府缴了一堆一钱，凭哈？为什么我们的企业还这么乐不思蜀地每年送这么多钱给vmware，你真的需要vmware 百分之百的功能才能满足你的应用要求吗还是只是想找一个心理依靠？ 甚至我还听说到一些大企业每年买vmware的费用上亿？我们中国人就那么...xxx....?

 

是的，OpenStack 已有的功能虽然不一定能百分之百满足一些特定应用要求，但二次开发完成可以做到呀，而且这会省多少钱呀，就算要请专业服务团队支持，每年要付服务费，有什么不行？用vmware不是每年也要付许多服务费吗？

 

OpenStack缺少vMotion等功能，但如果需要确实可以二次开发来实现它，这是其一；其二，如果你上层的应用都部署到k8s中，那么依靠k8s的机制，通常情况下，你根本就不需要vMotion功能。

 

很多人对此仍会有不解，OpenStack的稳定性行吗？不是有很多坑吗？当你了解之后就会明白，OpenStack只是一个资源调度管理软件，虚拟机创建好后，它的稳定性保障是由Linux与Kvm来确保的，数据安全是由商业存贮保障的。只有你怀疑Linux及KVM虚拟化机制的稳定性如何时，你的问题才会成立。

 

之所以使用ceph,是因为你的钱不够，如果钱够用买一些商业存贮系统，为什么要用ceph?

 

倒过来说，如果你拿几十万投资的OpenStack+Ceph与几百万投资Vmware+Netapp/EMC系统去比较功能、稳定性、性能等等，不是自找倒霉吗？难道网上还能有更好的对OpenStack的评论吗？要比，至少服务费应该收vmware费用的一半才行吧？要比，至少也应该是国产组合，如OpenStack+华为/华三/浪潮存贮模式，以长我等喜欢OpenStack等等同仁的爱国志气。
 

2.私有云应用模式

私有云应用模式许多企业很少会用到，你看一下有多少国内用户使用vmware 的cloud模式就知道这个比率了。而OpenStack一些评论也与此有关，因为一些企业本来简单地使用OpenStack虚拟化模式就可以满足要求，但一些服务商上来就给弄了一套私有云模式，用户使用起来麻烦，大多技术服务商也陷到“坑”中。

 

所谓的私有云部署模式是指：虚拟机提供的服务必须通过浮动IP对外提供，虚拟机自身的固定IP仅用于内部通信。

 

技术服务商陷到“坑”中的原因是，仍按官方文档将Neutron L3服务运行在独立的网络节点中或更简单地像我看到的北京那家公司那样，直接将L3服务放到了三台服务器中处理（这样可以节省控制节点的服务器数量）。这一模式也是Mirantis 的软件部署模式。

 

这种模式真跑起来时，当整个流量压力大、同时有性能要求时，问题一堆，而且运维起来极为麻烦。它的原因是，基于服务器Linux 操作系统运行的Neutron L3服务一是代码时间短、成熟度不够高；二是高性能、高压力下基于服务器内运行的L3类软件稳定性远远无法与传统的交换机与路由器相较。

 

解决这个问题唯一的方法是：将Neutron L3功能转移到传统路由器/交换机中运行，且通过路由器/交换机本身的集群能力提供网络服务冗余。这一解决方案我已在2017年北京OpenStack大会上做过演讲，我这里就卖个关子，不再说解决方案了，而且以前多次OpenStack meetup时也提到了此点。

 

当然，如果暂时这方面的技术问题无解，一些技术商仍可以考虑使用nova-network直接解决l3/dhcp分散问题而不使用看起来高大上的neutron+DVR，那会带来更多麻烦。

 

目前许多OpenStack技术服务商都没有这个能力，也因此至使应用OpenStack系统私有云模式时碰到了许多问题，并把这些问题归结于OpenStack自身，这是不对的，本身上冤枉了OpenStack。

 

作为技术服务商来说，这个问题不解决，最好不出去混，否则就是给用户和自己挖“坑”。如果为了艰难的生活而必须出去混，最好使用我提到的OpenStack虚拟化模式，让用户与自己都放心且也免除了因为自己学艺不精的原因乱写关于“坑”的文章，而染污了八杆子打不着的OpenStack的名声。

 

3.公有云模式

除了2012年弄的艾普宽带云系统外，根本没机会再碰到了，所以就不再讨论了。

 

话题三：关于OpenStack与Kubernetes的关系

对了，是关于OpenStack的发展与K8s的问题，就是世民文章中提到的OpenStack的发展与容器等方面的问题。

 

我们谈到OSI网络协议时，都知道有七层协议；谈到http协议时，知道它是封装在TCP中；谈到云计算时，都知道有IAAS/PAAS/SAAS三个层面。提到k8s时，我们会认为它实际上处于PAAS层面。

 

我们看到了OpenStack社区做了一堆关于K8s的工作，甚至那个基于Kuyr/Heat组件的解决方案看起来都不错，但说实话到现在为止，我从未在实验环境中做过关于这些组件的测试，原因是我认为生产系统根本不可能使用这么复杂的技术，根本无法运维；同时，反过来你也可以看到k8s社区也在做一些设法接管网络与存贮等方面的工作，这很正常，各种路子如同雨后春笋一样蓬勃发展，这样才好。

 

但问题是，我们要有自己的主张，特别是针对生产环境应该如何处理OpenStack与K8s的问题。我的观点以前也写过文章表述过，记得那篇文章名字是 《OpenStack与K8s融合：丑陋但朴实无华》，核心是，通常情况下将K8s运行到OpenStack 虚拟机中，k8s是PAAS, OpenStack是IAAS, IAAS 管理计算、网络与存贮系统，OpenStack不做PAAS方面的事，K8s也不做IAAS方面的事，各自发挥优势互相补足。

 

docker的精华是“一次封包、随地运行”，K8s的精华在于随业务变化，弹性管理docker，k8s/docker 本身的优势并不是“比OpenStack能够更好地管理网络、更好地管理存贮”。所以如果你打算从OpenStack的外围组件中寻找与K8s融合的最好方式之前，千万别忘了这个基础。

 

另外，在我看来，使用OpenStack组件管理K8s集群也只是一个美好的愿望，如同水中月那样华而不实。当你真正建设k8s系统用于生产环境时，你就会发现，如果OpenStack一样，你仍是要对K8s系统做许多调整，如解决iptables在大数量Service后对整体性能的影响、解决自动化服务暴露问题等等，因此就算有一个OpenStack组件能自动地部署了k8s系统，它也仅具备实验室环境的价值，而对生产环境来说，部署好的k8s系统基本上没有价值。

 

由OpenStack管理计算、网络及存贮，k8s运行在租户的虚拟机中，通过处理网络路由实现互通或隔离是一个针对企业环境较为实际的解决方案。

 

话题四：关于OpenStack核心与非核心组件

第四个问题，关于OpenStack核心和非核心组件。

OpenStack目前好象有近53个组件，而我基本上只用6个核心组件为用户部署系统，如果你使用ceph一样，最好只用rbd,这是它的核心；使用glusterfs最好只用文件方式复制而不是条带复制。即，对于开源软件来说，最好只使用它的最核心功能，核心功能原则上是有保障的。我完全可以理解人们对其它组件的失望，而问题在于，你根本不需要使用那些东西，用了，踩了“杭”是你的问题，而不是它的问题，因为本来这些东西都不是很完善，如同我们国内99clould与华为分别做的freezer与karbor那样，你试着按文档装一下就明白，文档写得非常不严谨，或者说不好，你又怎么能期望其他的呢？备份吗，难道rsync/ceph-backup 简单地不能满足？数据库备份？算了，你为了备份而冻结了数据库服务器，业务应用就无法连续来，还是要求业务应用部署时采用集群吧。

 

是的，以OpenStack 6个核心组件为基础配合其它的简单解决方案或稍复杂的二次开发完合可以满足应用要求了，大多数情况下，不需要其它的组件，踩了“坑”是你的问题，不是OpenStack的。

 

话题五：关于OpenStack对企业的价值

第五个问题：看起来有这么多“杭”的OpenStack对企业的价值是什么？

如同世民文章中提到的一些疑惑那样，如果单纯地从技术角度你会困惑此点，即生瑜何生亮？用vmware不就可以完全解决问题了？只是世民还是弄OpenStack的，还是通过心虚地远瞻前景告诉大家要用OpenStack.

 

之所以手握OpenStack面对Vmware信心不足，原因是好钢暂未用到地方。对于企业来说，如果你为企业讲解OpenStack能节省成本，企业愿意试试；但如果企业认识到OpenStack能增加产能，则企业必会坚决使用。

 

我个人认为，粗看起来，企业对IT的需要求可以分为两个阶段：一是通过vmware+netapp/emc 等标准虚拟化解决方案搭建ERP/CRM核心系统解决企业内部生产制造问题；二是即将面临的物联网平台问题。

 

当许多企业，特别是制造类企业，当大家认识到企业在外运行的设备数据是资产并且通过对这些数据资产进行分析而可以进一步地提高用户产能或优化产品设计时，企业均会考虑建设物联网平台，以收集企业已销售设备的运行数据。而由于这个业务本身的弹性较大，对虚拟机、存贮等要求量都较大，再使用vmware及商业存贮成本与收益的对比就不成比例。这个时候，OpenStack开源、开放、灵活、低成本的价值就会被大家所认识。而且大数据业务本身集群具备的复制能力、业务应用运行在k8s下自动冗余处理的机制也使得在企业物联网平台中，vmware的vMotion那些价值显得不重要，甚至不需要。

 

简单地说，OpenStack用于帮助企业降低成本时，它的价值并不明显，但若要能用于帮助企业在物联网平台方面创造更多收益，那么OpenStack是当仁不二之选，意即，物联网平台中，根本不需要Vmware.

 

话题六：其它？

还有什么话题？

国内OpenStack服务商的业态？我没有资格提到这个，我无法体验到那些拿了投资的公司在经营上的麻烦。我确实参与到系统集成类生意很多年，但如果弄OpenStack变成像在1993年卖Hub/95年卖交换机/97年卖路由器/...., 那样只是换汤不换药地仍做着系统集成生意，只是把Hub换成OpenStack然后再开发定制一些用户软件，那么前途可危。原因是系统集成的生意规模天然地受“关系”限制，做不了很大且每年都没命地奔波新项目才能让公司获得好发展，做了多少年根基仍然不稳；同时由于OpenStack开源而且基本功能可以满足80%的企业用户要求，依据2/8法则意味着，业界公司只有向20%大用户提供定制化软件服务才能得以发展，用户群的数量限制也会对公司未来发展前景产生影响。

 

出路如何，还需要探索。

 

关于我

我？我是谁？成都-子凡（微信：bai_tang1968），不得不做OpenStack专业服务以挣点小钱渡日之人，当然要说点OpenStack好话了，否则我如何生存？