Apr 272017
 

如何把一个开源项目产品化,或者把OpenStack产品化,OpenStack社区版本,是不是一个产品,这种问题都是见仁见智。

做开源一个通病,就是一开始满腔热血,啥都想控制,觉得自己什么都能做,做的比别人更好。开源的商业模式,注定是一个持久战的过程,你只能选择一个领域突破,做到极致,你才有机会。

OpenStack的产品化,其实在国内很多人理解是对OpenStack进行定制,自己开发一个Dashbaord。不过这样做,你就注定你的OpenStack日后是无法升级,你的迭代成本是非常高的,开发一个版本的时间,至少是超过6个月,甚至1年。那么在这1年里,你对OpenStack的定制修改,很可能赶不上社区的进度。你所付出,要在市场上变现,变得越来越困难。

开源项目的产品化,注定是一个持续长久的过程。你真的要搞清楚你的上游是谁,你应该做什么,你那些是不应该碰,什么问题是你应该去解决,什么问题应该是交给上游来解决。如果你在客户面前承诺所有的问题,都能解决,那么结局其实是很惨的。

我的心目中的OpenStack产品,我的理解其实就是一套部署安装的工具,加上运维管理工具的结合,帮助用户解决部署安装,长期运维的问题。

我一直和用户强调,OpenStack并不是我的OpenStack,我希望可以变成你的OpenStack,也只有这样,你才会愿意投入人力,物力去深入了解,真正做到拥有OpenStack。

我想Kolla就和OpenStack其他部署工具类似,Fuel成为的Mirantis的产品,OpenStack-Ansible成为的Rackspace的产品,Kolla和这些工具有点不同的地方,他是社区驱动的项目,不受任何一家公司掌控,目前他也将要成为很多公司的产品。

那么下面就介绍一下Kolla一些和别家产品的完全不同的地方。因为大家都会说自己的产品,安全,可靠,标准化。

升级

在OpenStack进入企业,面临最大的障碍,就是升级。OpenStack社区和各个发行版,其实都做了很多的努力,其实还是有很多不如人意的地方。

对用户来讲,升级最好就是在线升级,升级时间尽量短。安装OpenStack的时间,用户并不太关注部署时间的长短。用户一定会关注升级所需要的时间。因为升级的时间越短,对业务影响才是最小,一旦升级失败,你还有足够时间回滚。

Kolla目前在安装,升级的过程,所需要的时间大概是30分钟。安装过程是30分钟,升级过程的时间也是30分钟。这应该是目前时间最短。有勇气给客户现场演示升级的,其实目前我理解,就是Kolla可以做到。

 

摆脱厂商锁定

以前这个话题,都是国外公司考虑的很多,现在国内的企业,也开始思考这个话题。对于OpenStack来说,他是完全开源的,但是你真正用起来,其实很多程度,是要依赖某个厂商来提供服务。那么不同厂商间的切换,要付出的代价,以前其实是很高的。

在OpenStack上,用户要有能力换掉底下的操作系统,上面的OpenStack的服务提供商。那么这点上,市场上的OpenStack部署产品,基本都是不具备这个特性。

Kolla,同时支持CentOS,Ubuntu,下一个版本Pike,还支持非X86架构的CPU,ARM下Debian跑OpenStack也不是问题。

各个操作系统厂商,为OpenStack做了很多工作,作为用户,是有选择权,使用过程中,还是可以进行切换。这一切都受益于容器的特性。

灵活和扩展性

很多厂商和用户交流的时候,非常强调设计,规划。但是用户的需求,也是很实在的。我使用Vmware的时候,我就是从一台机器开始,先来一个all in one。用的好,我再慢慢扩展。凭啥OpenStack一上线就要求3个控制节点,3个网络节点啥,还要求监控也是3个节点,一个虚拟机都没创建,就用了9台机器。

厂商的理由,当然就是为了可靠,但是用户在起步,验证阶段,是可以接受单点的部署,经过了一段时间验证,使用没问题,再去增加节点,提高可靠性。vmware就是这样做的,为啥OpenStack做不到呢?

这其实也是我们经常和客户交流的时候,客户的困惑。

事实上,客户规模10台和100台的设计,规划,不可能是一样的。当初10个节点的设计,当规模扩大到100个节点时候,进行架构的调整,是否可以实现呢?例如到了100个节点,需要把消息队列从控制节点拿走,单独部署?

对于Kolla容器化部署的OpenStack,实现上面的需求,其实是代价比较小的。

社区活跃度

选择一个开源项目,其实现在大家越来越成熟,不仅仅是项目的功能,还会关注他的社区状况。对于Kolla的社区来说,可以说是目前为止,OpenSttack最活跃的项目,前五名把。

kolla从成立到现在,2年半的时间,作为一个部署工具,其实已经覆盖90%的OpenStack项目。现在已经在支持非X86的架构的CPU,从这点上,你就可以看到社区的活跃度。

下面的图,是Kolla项目的全部Commit的分布图

Snap5

Mar 302017
 

3月份是Kolla的Ocata版本,4.0的发布时间。3月10号,是OpenStack官方指定的最后的项目发布时间。Kolla按期发布的Ocata版本,目前大家都可以进行测试。

我一向坚持吃自己狗食的原则,把我们的开发环境换成的Ocata版本,同时也触发了好几个OpenStack Ocata版本的Bug。

Kolla Ocata当前情况

这次我们对OpenStack的Ocata版本进行测试过程中,发现遇到的bug数量,其实有点超出我的预期。这个其实也和Nova项目在Ocata版本,改动比较大有关。目前Nova 15.0.0发布后,已经连续发布了2个小版本,估计后续还需要再发布版本,才能解决存在的问题。

经过了1个月的测试,其实明显的bug都已经修复。Kolla最新版本的Ocata,已经更新到nova的最新stable版本,

大家可以通过 国内的hub  https://hub.trystack.cn/  进行体验。

4月底前,应该可以真正推动生产使用的。

Pike版本看点

目前已经进入Pike版本的开发,对于Kolla-ansilbe来说,有不少工作是需要大家关注的

  1. Nsx集成,这是广州云宏的朋友在做,非常值得表扬,
  2. OpenDaylight集成,这是Intel在推动这个事情,那么在Pike版本应该可以完成
  3. snap,这是intel搞的一套完整的监控工具,数据会存储到influxdb,通过grafana来展示,https://github.com/intelsdi-x/snap,希望本周期可以完成,大大改善Kolla的监控

对于kolla-k8s,最大的看点,就是要交出一个1.0的版本。这是必须,生死攸关的时刻。只有这样,才能和Mirantis的Fuel ccp进行竞争。

 

Non X86支持

这个话题,其实问我的人很多,能不能支持国产操作系统,能不能支持国产cpu。

对于kolla来说,只需要操作系统支持Dcoker,如果是x86的cpu,那就基本没啥问题。

如果是非x86的cpu,那么就需要对OpenStack很多基础组件进行打包,例如arm,要跑OpenStack,PPC64,使用到的包,都需要重新进行编译。

目前社区有专门的公司在推进这个事情,ARM跑在Debian下。

相关资料

对于国产cpu来说,kvm的支持,估计都是一件很挑战的事情。如果能支持Dcoker,就很不容易了。

BigTent项目

  1. Dragonflow
  2. Monasca
  3. Zun
  4. Vitrage
  5. Zaqar

在我看来,Big Tent底下,就剩下5个项目需要Merge。当前其实都是在进行中,我也和开发者保持密切联系,希望这个版本可以真正来一个全家桶。

Mar 152017
 

CentOS7,网卡名字,采用consistent network device naming,简单的说,网络的名字,已经不是以前的eth0,eth1,你装系统前,你根本就不知道他叫啥名字。

这样的命名,好处就是你机器重启,增加pci设备,不会导致原来的设备名称发生改变。如果我们通过grub,修改内核的方式,改变回到以前的网卡命名,这种方式在新的设备里,会出现很多问题,你会发现每次重启机器,网卡名字都是会改变,一直都是在不停的变化,让你疯掉。

Continue reading »

Mar 112017
 

今晚刚好有台dell的730服务器,就顺便整理学习和记录一下。搞OpenStack,经常要对付各种硬件,一不小心,就会掉入某个坑里。方便日后查阅。

Snap2

Bios,iDRAC,Device 3部分,那么就截图记录一下。

Continue reading »