Dec 292017
 

最近朋友给别人介绍我是做OpenStack,对方提了一句,如何用一句话告诉我OpenStack是什么。

我想OpenStack就是AWS公有云的开源实现。功能可以满足企业私有使用。

接下来我就要给朋友深入介绍一下OpenStack的技术相关内容,对方是Python开发者,我就努力写一篇OpenStack的介绍文章,让技术人员可以快速了解OpenStack。

起源

在2010年的时候,AWS当时在国外已经是风生水起。当时云计算的老二,Rackspace,觉得无法和AWS继续拼下去。那么就决定联合多家一起搞一个OpenStack,和AWS PK一下。

Nova是美国宇航局内部的IaaS项目,就是一个用python写的IaaS管理平台,不过维护的成本很高,所以美国宇航局和Rackspace达成共识,就把nova项目交出来,大家一起搞OpenStack项目。

Rackspace拿出自己的对象存储产品进行开源,就是swift。项目在2010年7月份成立。

对于swift来说,确实是从Rackspace生产环境拿下了的代码,支撑过10个PB的对象存储代码。不过在OpenStack的后续发展中,swift,并不是必须的,因为很多企业,也根本用不上。那么后续我就基本不会提到swift这个组件。

开发原则

  1. 所有的项目,都是必须用python开发
  2. 采用apache 2.0 的license
  3. 项目间是松耦合,这个是必须的
  4. 各个组件只提供管理功能,(swift是一个例外)。例如nova,他是管理hyperv,glance管理镜像,存储是什么,是可以选择。
  5. 自动化测试,强大的ci,代码需要review,原则上需要一个项目两位core同意才能merge
  6. 全局的requirements,各个项目都必须遵守,这就避免软件依赖的冲突。
  7. 发布周期,就是1年2个版本,定期发布。
  8. 全部功能API

OpenStack是全球最大的python的项目,也应该是最大的公开的CI,CD项目。

对于OpenStack项目来说,每个项目结构是差不多

  1. api服务,对外提供api服务
  2. server,完成相关的工作,可能会拆分多个服务
  3. 每个项目都有client端

OpenStack项目介绍

OpenStack目前官方管理项目其实不少,未来管理OpenStack项目,官方也自己开发了一些工具,成立了一些项目。不过对用户能用到,真正目前能用的项目,其实是不多的。我就介绍几能用的项目

Nova

最早的nova,其实是一个具备基本功能的IaaS平台,能管理计算,存储和网络。不过这个并不符合OpenStack当初的设计理念。所以就对nova项目进行拆分。

到了现在nova项目,就管理hyper-v,其实在真实场景下,基本都是kvm的天下,剩下的别的hyper-v,基本都是市场行为。

Nova,更多的是intel,红帽的天下,很多硬件,kvm的特性,都加入到nova上。

nova对应AWS的EC2,很多术语都是来自AWS,

目前OpenStack的nova开发,其实已经进入稳定的阶段,已经很难有更大的突破,更多的是在虚拟机迁移等上面做点工作。

Keytone

这是提供身份验证的项目,那么他本身对外只是提供api接口,通过底下调用各个组件来实现身份验证,例如mysql,ldap,AD来实现身份验证。

作为keystone,还有一个很重要的功能,所有openstack服务的endpoint,就是告诉用户,你访问的服务的地址。这个有点类似现在的微服务,不过就是在微服务里,服务是自动注册。对于OpenStack来说,各个服务,需要手工注册到keystone上,并且创建服务的账号。

对于nova来说,就是需要在keystone注册一下,告诉用户,nova的服务的地址是什么。这样就可以使用相关服务。

keystone是OpenStack所有服务的入口。

Glance

镜像管理,创建虚拟机的镜像,都是通过这个项目来管理。功能其实还是比较单一。未来加快虚拟机的创建,大家想到的就是把glance的存储和虚拟机的存储合并在一起,这样创建虚拟机的时候,直接做一个link,这样就创建出来一个虚拟机。所谓的秒级创建,就是差不多这个意思。

Cinder

这是OpenStack的存储管理,目的就是管理卷。存储可以是Ceph,也是可以商业存储。

以前aws的玩法是:创建虚拟机,系统盘是固定大小,你可以选择通过EBS,也就是OpenStack的cinder,创建一块硬盘,挂载到虚拟机里。

由于系统盘是存放机器本地盘里,会导致不少问题,例如无法迁移,机器挂掉,数据就丢失,用户比较爱在系统盘里存放数据等。

那么大家就想到,把系统盘,也放到存储上,这就所谓 boot from volume。这样就可以搞定虚拟机的迁移。

目前主流就是用Ceph作为存储。这样虚拟机可以实现迁移。

Neutron

这是OpenStack管理网络的项目。对于网络厂商来说,这个项目是比较要命的,和存储厂商的态度是完全不一样的。neutron实现的功能,就是让用户可以自己创建网络,router,这就是所谓SDN。

其实aws在2010年以前就实现这个功能,OpenStack,其实是一致到2015年,这个功能才算是能用。目前来说,已经算是可用。在100个节点的环境下,还是能顶住的。

网络上,大家玩的最多的就是负载均衡,那么对neutron来说,这个他是不管的,交给另外一个项目来实现。

Horizon

这就是OpenStack的Dashboard,UI。目前是用python开发的,前端的用户体验很差,后来改成用js开发,目前也在调整中。

Horizon上的功能,仅仅是部分的OpenStack功能,不少功能,没有在UI上实现。需要命令行下通过client进行操作。

以前openstack每个项目都有一个client端,后来进行了合并,就一个客户端,openstack-client。你就可以在上面利用命令行去管理各个项目。

消息队列和数据库

对于OpenStack来说,项目间的通讯,我的理解就是通过api,消息队列来进行的。OpenStack目前大家使用的基本就是mysql和rabbitmq。

对OpenStack来说,压力最大的是消息队列。所有的虚拟机,创建,删除,都是要经过消息队列的。

OpenStack的规模,其实目前最主要的局限就是消息队列的承载能力。

部署架构

其实目前OpenStack的部署架构基本都是一样的。基本上就是通过3个控制节点,把服务都装在上面实现HA,这点上,其实和K8s,也是非常相像。

目前主流的HA实现方式,就是haproxy+keeplive来实现。

部署工具

对于openstack来说,所谓产品,其实基本就是一套部署工具。2017年的时候,其实目前的部署工具,就剩下那么几个。

  1. kolla ,把openstack组件容器化后,通过ansible来进去编排和配置管理
  2. 红帽产品,通过kolla的docker镜像,采用puppet来实现编排和配置管理

openstack的复杂性,升级,其实单纯靠OpenStack自身,或者操作系统厂商,代价是很高的。最后发现必须利用容器,才能彻底解决问题。

kolla就是目前最好的OpenStack部署工具。

Dec 032017
 

Kolla第一个真正意义上可以在生产部署的版本Ocata版本发布以后,经过半年多的验证,其实这次11月份的OpenStack峰会上,其实也体现出来,越来越多用户在尝试和测试。

Ocata版本

由于Kolla,是一个开源的项目,他支持CentOS,Ubuntu,source和二进制的部署方式,采用不同的方式,你可能面对的问题是不一样的。那么对于我来说,或者国内来说,

Kolla Ocata Source+CentOS 7.4 + Dcoker CE =Perfect

这个组合应该应该了很多客户生产的验证。可以这样说,Kolla生产中稳定性,可靠性的所有的问题。都已经彻底解决。

一个系统的稳定,可靠,真的不是靠拍胸口来证明的。需要生产环境下的长期压力测试,

这样说吧,现在对付100个节点的OpenStack群集规模,已经是可以轻松面对。

kolla控制节点扩容

用户经常质疑OpenStack的一个问题就是:在Vmware的环境下,我可以从一个节点开始使用,逐步增加节点。为啥OpenStack上来就需要3个控制节点呢?刚开始节点,我还不需要那么高可靠,我还打算周末关机省电呢?

简单来说,就是OpenStack群集的控制节点,能不能从1个扩展到3个。目前市场上,所有的部署工具,都是无法支撑的这个功能的。当年Fuel尝试了一下,也放弃了。

对于kolla来说,其实很简单,你部署第一个控制节点的时候,只需要设置好haproxy的IP,那么剩下的都是好办的。

从1个控制节点,增加到3个控制节点,从3个控制节点,扩展到5个控制节点,都是轻松面对。

OpenStack项目状况

Kolla基本集成了所有OpenStack项目,那么那些项目是可用的呢。我就整理一下把。方便大家测试,针对目前的Ocata版本

生产环境

  1. Nova (kvm)
  2. Neutron(L3HA)
  3. Cinder(Ceph)
  4. Glance(Ceph)
  5. Keystone (AD)
  6. Horizon
  7. Heat
  8. swift

上面这8个项目,应该算是经过了大量验证,已经达到完美的情况,应该来说,100个节点内,应该是轻松面对。

  1. Octavia,负载均衡项目,其实该项目也是可以生产使用,目前就是Horizon UI上有点逻辑问题,导致删除的功能不能正常,需要命令行下删除。他的架构,也是可以支撑大规模部署。VM As Service
  2. IRonic,裸机管理,这个功能其实目前是非常好用。包括多租户,都是支持。
  3. Sahara,大数据服务,功能都是正常的。
  4. Rally,部署完OpenStack,进行压力测试,这块我费了很多心思,也是可以很好支持。完全是可以玩起来。

OpenStack Big Tent底下,所谓官方项目,大概目前是60个左右,用户需要用到的项目大概有30多个,不过真正意义上,能投入生产,经过用户验证的,也就上面这12个项目。其实如果你去看红帽的OpenStack支持列表,也是差不多的。

可用项目

下面我整理一下大家可以关注的项目,或者需要大家去测试的项目,希望我们可以努力去完善。

  1. Barbican:密钥管理项目,很多项目的安全,cinder,sahara的数据加密,都是需要这个组件来完成。
  2. Designate:dns项目,由于OpenStack平台如果希望支持k8s,需要使用外部dns服务,受到大家重视,该项目也是可以好好测试,目前kolla里也是比较重视。
  3. Manila: Netapp和EMC一直都在支持,目前对Ceph集成,也在完善。值得去看看。也是因为K8s,再次受到重视。
  4. Mistral:工作流项目,目前例如tacker,都用它来做流程。kolla也是work。
  5. Magnum:部署k8s工具,这个工具,目前是可用,经过我们测试。
  6. kuryr:k8s网络相关,
  7. zun,容器管理项目,替代nova docker。
  8. Dragonflow: 华为,中兴都在玩,很难得的事情。

实验室

这些项目,一直都没真正意义跑起来,目前社区也存在严重问题,缺乏后续发展

  1. CloudKitty
  2. Congress
  3. Freezer
  4. Karbor
  5. Monasca
  6. Murano
  7. Searchlight
  8. Senlin
  9. Solum
  10. Tacker
  11. Telemetry(aodh,panko,ceilometer)
  12. Trove
  13. Vitrage
  14. Watcher
  15. Zaqar

上面15个项目,其实已经基本都没有全职的人员在干活,非常危险了。据说已经成为国内刷榜的重点地带。

Nov 022017
 

对于OpenStack社区来说,一般峰会开完前,大家都比较懒惰,处于休息状态。该干活的,都是开完峰会以后再做。

对于Kolla来说,倒是有不少东西可以说一下。

我最近搞OpenShift,发现K8s的其他公司,基本很难找到机会,因为红帽已经认定的方向,并且OpenShift挣了大钱,收入排第二位,操作系统第一位。

对于OpenStack厂商来说,由于红帽犯了一些错误,内部斗争等原因,导致红帽的OpenStack没真正做起来,其实就是没给公司创造太多价值。这样OpenStack创业公司才能有口饭吃。

Ansible,Ceph,都是红帽的,cobbler也算是红帽的,kolla的PTL,也是红帽工程师。

OpenStack现在一年2个版本,大家都叫吃不消。K8s一年4个版本,红帽的OpenShift还在紧跟,这就是区别啊。

2年历程

2015年,也大概是10月份,我第一次见到Jeffrey zhang。也基本上从哪个时候,我们开始搞Kolla。

Jeffrey zhang  Kolla的第一个commit  https://review.openstack.org/#/c/242339/

遇到Jeffrey zhang,无论对我还是Kolla项目,都是一件非常幸运的事情。

可以这样说,因为Jeffrey Zhang,Kolla项目的成熟度,提前了至少半年时间。让Kolla在Mitaka版本,可以正式服务客户,同时也搞出全球第一个kolla的生产案例,一个规模非常不小的案例,53台超融合架构的环境,考验了Kolla灵活性,强壮性。

可以这样说,2015年4月份的时候,全球有能力落地kolla的,应该不会超过5个人。

 

Ocata版本

OpenStack的Newton版本,经过一年的时间,现在已经正式宣布退役,不再维护。那么对于Kolla来说,Newton版本退役,其实是甩掉了一个包袱。

因为kolla在Ocata版本进行了代码的拆分,kolla 和Kolla-ansible。导致都后续很难对Newton版本进行代码维护。

Ocata版本,也是非常特别,第一个改变发布时间的版本,从4月份发布,改成2月份发布。对于kolla来说,Ocata版本,是4.0的版本,这算是一个真正推向客户的版本。

从Mitaka版本到Ocata版本,整整一年的时间。用户也开始慢慢接受Kolla,OpenStack放到容器里跑。

经过了用户了大量测试和开发半年的维护,目前Ocata版本的Kolla,已经非常稳定。在Pike版本修复的bug,全部都回馈到Ocata版本。

其实我们在5月份,给用户上Ocata版本的Kolla的时候,也遇到不少所谓坑。不过这些坑,都已经填平。简单说

CentOS 7.4+Ocata的Kolla,就等于非常稳定,可以放到生产运行。

可以这样说,OpenStack以前任何一个新的版本,都没有Ocata普及的快。发布不到半年,用户已经达到相当的规模。

市场新闻

10月份OpenNFV发布了一个版本,Kolla被集成了一次。那么这也可以看到Kolla的优势。无论是SDN,NFV,最终交付给客户,以前都是非常复杂的,如果容器化后,结合Kolla,那会非常简单。

现在OpenNFV,OpenDaylight,官方的安装文档,都是用Kolla来集成,

红帽的Tripleo版本,也要全面转向kolla,使用kolla的镜像,不过他们还是用puppet来玩。不过这个太折腾。

kolla社区

相比别的OpenStack项目,kolla的热度是非常高的。有想法,追求的,还是很多的。

  1. Xen的支持
  2. 微软Hyper-v,也要容器化
  3. Prometheus,容器的监控
  4. Manila的CephFS支持

文档也在进一步完善。

FAQ

很多朋友都问我一个问题,甚至包括Kolla的社区开发者,我有没有留一手,在kolla上面。

是否留一手,道理很简单,是否会带来利益。如果留一手,你能获得更多的客户,那肯定会留一手。不过玩开源,想通过留一手来获取客户,其实是注定失败。没有客户会因为你留一手,给你单子。只会因为你留一手,丢失了一个kolla的潜在用户。

正确的玩法,就是让Kolla无比好用,大家用的很爽。根据长尾理论,总会有客户找你提供服务。

威力已经在发挥中。

Sep 252017
 

9月份,是OpenStack的Pike版本发布的时间。对于Kolla这次发布来说,也已经发布了pike的版本,整体肯定都是可用的,不过不少小问题,慢慢修复。

如果大家想测试和学习kolla,我还是建议用Ocata版本,这个版本,在过去半年里,已经修复了大量的bug。除非你真的想玩特别新的功能和能折腾。

目前社区已经进入Queens版本开发,对于Kolla来说,未来有什么可以期待和关注呢?

对于kolla-ansible来说,已经步入一个基本的稳定阶段。不过还是有很多细节可以完善。

kolla-ansible容器化

这个其实大家很少关注,不过当你去升级OpenStack的时候,还是会有点不方便。如果我们把kolla ansible也容器化,其实就真的很爽。

对于Ocata版本的kolla ansible,和Pike版本的kolla ansible,他们的requirement是不一样的。还是可能导致一点问题。解决的办法,就是把kolla ansible也容器化。

跨版本升级

kolla需要对跨版本的升级,做更多的测试,尤其是Ocata版本,直接升级到Queens版本。这样可以很好解决用户面临频繁升级的问题。

我相信对于kolla来说,实现的代价应该不大。需要做的就是大家参与去测试。

 

Masakari

这个项目推出已经有至少2年,实现一个用户非常关注的功能,VMHA。就是一个计算节点出现故障后,上面的虚拟机进行疏散到别的节点上。

这个功能最难的地方,就是如何判断节点出现故障,误判,很容易导致vm的脑裂,出现更加严重的故障。

目前大家都是通过zabbix的监控来实现。不过OpenStack社区是通过Masakari项目来实现,目前该项目在申请加入Big tent,那么放到kolla里,也是呼声很高。

替代Devstack

在OpenStack开发过程中,是否能用kolla来替换Devstack。这个真的是一个非常好的想法。其实当年OpenStack ansible,也是有同样的想法,只是没真正实现。

目前kolla社区已经逐步把项目提供dev模式,让开发者可以用kolla来搭建开发环境,在上面进行开发。

性能优化

和Mirantis的Fuel相比,至少有两个地方的性能还是有差距的。

  1. fernet token
  2. Run RabbitMQ with HiPE

参考资料 https://www.mirantis.com/blog/best-practices-rabbitmq-openstack/

需要把这两个功能都启用起来。在大规模部署上,会有很大改善。

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

Fernet,是需要我们好好测试,这个功能,主要还是因为容器化后,需要好好处理一下才行。

解决遗憾

其实在8月份的月报里,我也已经提到了Pike版本的遗憾,那么这些遗憾,其实应该都是可用在Queens版本,进行很好的补救。

Pike版本遗憾

Big Tent项目,我们就继续努力,实现全家桶。对于Queens版本,我期望各个项目能真正的跑起来。

Aug 272017
 

kolla的7月份月报没写,其实也不是偷懒,主要还是因为社区的开发工作,都在进行中,没太多的更新。8月份,可以说是Kolla的Pike版本交付的重要时候。正式版本应该会在9月15号前发布。

这个月的月报,其实也可以作为Kolla的Pike版本的Release Note。

下面我就把Kolla和Kolla-ansible在Pike版本完成的工作,做一个总结。

Continue reading »

Jul 282017
 

其实大家都知道,我4月份发布了一个kolla的Ocata的ISO,经过了快3个月的完善,基本现在已经是一个最终的版本。

链接: https://pan.baidu.com/s/1F_kI8ZjQDJRgn45_Lw1RPw 密码: gba2

还是放在网盘里,大家下载就可以。

下面我就整理一下,这个ISO,我所做的改进工作。

经常有朋友问这个iso是用什么工具制作,这里就统一回复:Fedora的工具pungi,来制作的。该工具真的很强悍,非常方便。

另外这个iso,你用U盘启动的时候,可能会遇到兼容性的问题。所以建议把这个ISO,在linux下用DD的命令到U盘,这样的兼容性是最好的。这个兼容性和机器有密切关系。

sudo dd if=/hd/iso/ocata.iso of=/dev/sdb bs=1M

安全更新

我们采用的操作系统是CentOS 7.3,不过最近安全更新很多,尤其内核级别的,那么我们这次把所有的软件全部都update的最新,打上所有的内核补丁,这也是我们为啥iso的命名也是采用日期的原因。

这次更新,经过了绿盟的漏洞扫描测试,效果还是非常好的。

由于Kolla是采用Docker来部署OpenStack,对于所有的节点,我们其实只需要最小化安装,装上Docker就可以。但是最近部署,还是遇到内核的漏洞,经过升级才解决。

国内很多OpenStack厂商,自己搞的OpenStack版本,自己维护一个repo,用户根本无法进行安全维护,这其实也是一个很大的问题。

Chrony服务

默认最小化安装,也会把Chrony服务装上,由于Kolla已经把Chrony服务的容器,需要把Chrony服务删除掉。这样避免维护时候,产生误操作。

对于一个群集来说,时间同步是一个非常重要的事情。Ceph要求所有节点时间差异不能超过50毫秒。所以对于kolla的部署来说,你必须把Kolla里的Chrony服务启用。这是一个非常关键的地方。

安装包调整

以前管理容器的服务,都是要进入容器里,再运行相关命令。为了方便,我们在节点上也装上相关的包,例如ovs等,这样在操作系统上,直接运行ovs相关命令就可以。

这样的方便,其实也带来一定潜在风险。那么如何在易用和安全上平衡。那么同事提出了一个好办法,不需要在操作系统装相关软件。通过系统的alias来实现。

这个功能,其实就后续交给ansible来完成。对于OpenStack节点来说,我们就仅仅最小化安装,加上Docker和一些网络的测试工具。

对于部署节点,我们装了一下日常需要使用到的包,例如ansible访问windows节点需要的,我们把测试工具Shaker工具,通过rpm包的方式,直接装在部署节点上,这样可以方便测试。

 

Kolla

这里其实包括kolla和kolla-ansible。我们已经把版本更新到当前最新的版本。你使用iso安装完以后,会在根目录下看到一个 文件夹 kolla-ansible-4.0.3.dev36。dev36,很多用户误解成是开发版本,其实不是,表示4.03发布后的36个commit。

目前Kolla社区对Ocata版本进行精心的维护,把所有当前Master的bug都会回馈到Ocata版本里。

这次发布,我们修复了一个非常严重的bug

https://bugs.launchpad.net/kolla/+bug/1703078

大家可以好好看看。这算是kolla真正生产部署的最后一个难点,我们搞定了。

大家会发现把Kolla-ansible放到root的目录下,大家可以直接进入该目录运行命令就可以。相关的python依赖已经装上。

这次其实还修复了Sahara的一个bug。这个版本的ISO,Sahara是可用的。

 

All in One

注意事项
 
机器至少需要两块网卡
机器系统盘至少需要200G
 
allinone部署步骤
 
1、使用iso引导,选择 install centos7.3 and kolla 
 
可以使用tab键,修改ip地址和主机名,默认ip地址为10.99.0.2,主机名为control01
 
2、安装系统后,登录系统(root密码为99cloud),开始部署openstack,如下
 
/root/kolla-ansible-4.0.3.dev36/tools/kolla-ansible deploy
 
dashboard访问地址 http://10.99.0.2/
    username admin
    password 99cloud

iso里有一个说明 all in one的安装。

装完后,你是需要对OpenStack的环境进行初始化。我以前的文档,其实介绍过,我这里就不重复。

http://www.chenshake.com/kolla-installation/#i-3

这个iso,其实单节点仅仅是一个演示,也是可以安装多节点的。我给客户生产部署,也是使用这个ISO,不需要有任何疑问。

多节点的安装,其实很简单。大家如果搞过rdo的多节点,其实都是差不多。