陈沙克

May 242017
 

由于五月份OpenStack举行峰会,也导致大家注意力集中在峰会,社区开发,放慢了步伐。

峰会kolla相关

相关视频,其实还没来得及浏览,不过我印象最深刻的,就是讨论OpenStack升级,这个话题以往其实是很少涉及。因为升级是一件不可复制的事情。

这次不仅仅讨论了升级,还关注到升级对用户的影响,如何实现无感知的升级。这个对于OpenStack占领企业市场,是非常关键的。

Rolling Upgrades- Performance Between OpenStack Deployed in VMs and Containers

https://www.youtube.com/watch?v=VxfPe6EbT0s

可以通过搜索,看到其他的kolla相关视频

https://www.openstack.org/videos/search?search=kolla

 

Relation of kubernetes  and OpenStack

http://superuser.openstack.org/articles/kubernetes-openstack-use-cases/

图确实让表达更加容易。

  1. OpenStack和K8s都是部署在裸机上
  2. OpenStack上部署K8s
  3. K8s上部署OpenStack

relation

在K8s上跑OpenStack的项目

k8s

在OpenStack上跑K8s项目

openstack

 

社区开发

其实OpenStack社区开发惯例,一个版本,分为3个节点,B1,B2,B3,后续就进入RC1。一个周期大概是45天,那么B3结束后,就基本不能做BP的开发,只能修复bug。

一般B1阶段,更多的是修复bug,B2,B3,才算是真正进入BP的开发。对于pike版本来说

  • B2:6月5号
  • B3:7月24号

版本正式发布是在8月底。大部分BP的merge,要在6,7月份。

Hyper-V

微软投资Cloud-base公司,进行OpenStack集成微软的Hyper-v的开发。为了让用户能把这个功能真正用起来。Cloud-base团队选择kolla,而且做了很多工作。

大家估计知道ansible目前是可以管理windows。kolla要集成Hyper-v,那么就需要对计算节点的Hyper-v进行配置,这时候ansible就可以发挥他的威力,直接ssh的方式,配置管理好hyper-v节点。

对我来讲,非常期待在9月份,我可以实现,在一个OpenStack集群的一个网络里,出现

  1. vmware虚拟机
  2. kvm虚拟机
  3. Docker (zun项目实现)
  4. 裸机(ironic)
  5. Hyper-v虚拟机

一起努力把。

Kolla-k8s

这其实也是峰会的热门话题。国内的热度也是很高。已经有朋友奉献了一篇文章,介绍如何使用kolla-k8s

部署文档

大家有空好好实践一下。我也在考虑做一个iso,推动一下Kolla-k8s的发展。

Apr 272017
 

OpenStack把峰会的时间改成五月份,其实是希望在峰会上,可以让厂商给用户展示和讲解当前新版本的情况。所以对于部署工具来说,这是一个非常繁忙的bug修复的阶段。

Ocata

Ocata 4.0.1发布

经过了1个多月的bug修复,Kolla在4月20号,发布了4.01的版本。不仅仅包括Kolla的bug修复,OpenStack的各个项目的bug修复,也都进行了更新。

Ocata版本,是2017年2月24日发布,到现在2个月的时间,经过了第一轮的bug修复,作为用户来说,已经可以进入测试的阶段。

对于kolla来说,后续的小版本升级,其实是非常简单的事情。

Ocata 社区版本

九州云,我所在的公司,正式对外发布一个Ocata社区版本,通过ISO发布,主要是方便国内的朋友,可以实现离线的安装,推动Kolla在国内的普及。ISO里面的镜像版本,就是Ocata 4.0.1。

Snap6

目前ISO放在百度网盘上,后续会在官方网站提供正式下载。

链接: https://pan.baidu.com/s/1c2KQryo 密码: rgkb

使用时候,注意看说明。

机器至少需要两块网卡
机器系统盘至少需要200G

allinone部署步骤

1、使用iso引导,选择 install centos7.3 and kolla 

可以使用tab键,修改ip地址和主机名,默认ip地址为10.99.0.2,主机名为control01

2、安装系统后,登录系统(root密码为99cloud),开始部署openstack,如下

kolla-ansible deploy

dashboard访问地址 http://10.99.0.2/
    username admin
    password 99cloud

总是有人问我一个问题,Kolla是否可以做到一键安装。我真的做到了。

ISO里,还包括一个Cobbler容器,大家可以通过Cobbler来装OpenStack节点或者通过ISO来安装,都是可以。

 

Pike

目前很多的功能,都在开发中,对于Kolla来说,都是出于一种完善的阶段。

SDN控制器

国内的SDN厂商,支持OpenStack版本都相对比较老。目前Kolla支持的两大SDN控制器

  1. Nsx
  2. OpenDaylight

这两个控制器的进度都非常不错。在pike版本实现Merge,问题不大。

OVS DPDK

这都是Intel在推动的项目,通过dpdk来提高网络的性能。在Ocata版本就已经提出,应该会在Pike版本实现merge。

https://review.openstack.org/#/q/status:open+project:openstack/kolla-ansible+branch:master+topic:bp/ovs-dpdk

其实我看过红帽启用DPDK的文档,真的非常复杂。希望kolla真的可以帮助Intel,大力推动dpdk的普及。

skydive

这是一个网络拓扑展示,排错的工具,非常酷。OpenStack的网络,越来越复杂,这个工具,应该可以帮忙。

devstack-two-nodes

很酷的一个项目

https://review.openstack.org/#/c/459995/

BigTent项目

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

目前Zun项目已经merge,当前还有bug,修复中。不过也算是很不错了。刚刚成立不到1年的项目,就已经merge到Kolla里。

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 »