Oct 172016
 

目前Kolla 3.0 Newton版本,马上就要发布,巴塞罗那峰会马上就要举行,讨论下一个版本Ocata如何开发。那么这里我就对kolla提出以下自己的期望,同时也希望参与社区开发的九州云同事全力去推进。

真正参与OpenStack社区项目开发,不仅仅要了解当前版本项目完成的那些功能,还需要知道项目在未来,下一个版本的重点在哪里,用户最需要的功能,能不能实现。

OpenStack基金会计划明年把OpenStack峰会拆分成两个会议,用户和开发者,不同的时间点举行。开发峰会,就在版本发布的时候举行。用户大会,会再晚两个月。用Ocata为例,发布周期  Ocata 2月24号发布,开发者大会PTG(Project Teams Gathering)发布后马上举行,用户大会在五月份。

Ocata详细的发布时间 https://releases.openstack.org/ocata/schedule.html

这样1年4个季度,都会有会议参加,都会有报道的热点。

meeting

社区的思路也就是版本发布后,厂商2个月,就可以交出产品。

 

CloudKitty+Telemetry验证

在Newton版本里,九州云同事付出了很大努力,基本把组件都已经集成到Kolla里。那么其实还是有很多工作要去做,监控,计量,计费。确保可以做到真正生产可用。

目前Telemetry还有一个新组件,panko,event功能,还没有集成到kolla里,这块也和计费密切相关。

Ceilometer,目前支持Collectd来收集服务器的数据信息,传输到gnocchi,gnocchi把数据存放在Ceph的对象存储中,通过grafana来做数据的展示,利用aodh来做报警。

 

Barbican安全秘钥管理

OpenStack进入企业,那么大家对安全关注程度比以往都要高,那么如何把Barbican用起来,就是解决用户对安全的关心。

在Newton版本里,Barbican也已经集成到Kolla里,并且有开发者在逐步的整合到其他项目里,keystone,Magnum等。后续可以在cinder加密上,也真正用起来。

Barbican还有一个子项目 astellan,需要集成到kolla里,那么这是Ocata版本要做的事情。

Ironic和Bifrost

这就是裸机管理的功能,在Newton版本,intel投入的大量的精力去开发,不过目前看到的情况,还不能完全跑起来,还需要在Ocata版本进行大量的bug修复。

kolla要解决一个问题就是如何装操作系统,这样就能很好帮助用户解脱出来。

Ocata版本,一定要确保Ironic真正能用起来。

日志

Newton版本是采用heka来做日志收集,在Ocata版本需要替换掉,那么这个工作量还是比较大的。确保所有项目的的docker日志都能收集,并且能通过kibana实现很好的展示,这是我们要去努力实现的。

另外grafana也是支持日志的展示,如何结合。这是一个需要投入精力去完善的问题。

 

Tick 监控

Kolla是基于容器去部署OpenStack,采用的监控的方案和手段,其实和以往有很多不同。以前监控OpenStack服务,现在变成监控容器。

这是基于influxdb的一套监控体系,非常酷

tick-stack-grid

基本功能,其实已经集成到Kolla里,不过要想真正跑起来,还是需要Ocata版本努力。

TICK-Stack

 

Ceph集成验证

当前Ceph的块设备在OpenStack和Kolla已经得到了很好的验证,那么对象存储和文件,其实还是没有经历考验。今天和朋友开玩笑,下次搞Ceph聚会,就要给大家展示一下Kolla集成Ceph的文件,对象和块设备的功能。

对象存储主要还是gnocchi的监控数据,也是一个比较有价值的考验。

专门请教的豪迈,Cephfs在manila上基本是没法玩,还没有可行的方案,实现原生的多租户。所以一年内也就可以不需要考虑manila

计算节点自动疏散功能

这个功能,其实vmware用户一直提的需求,当一个节点挂掉后,上面的虚拟机自动疏散到其他节点上。OpenStack一直都没有真正好好解决这个自动的问题。

Kolla的Newton版本已经集成了所有和该功能相关的组件,到底用什么方式来实现,我们好好验证一下,在Ocata版本,交出一个满意的答案。

Virtual Machine High Availability (VMHA) service

这个是vmware用户经常问的问题,虚拟机如何自动实现所谓的HA。

实现这个,目前有三种方案,http://docs.openstack.org/ha-guide/instance-ha.html

需要好好评估一下,选择一种代价最小的方案来实施。大家要分清楚计算节点的疏散功能和vm的HA功能,是完全两个概念。VM的HA,类似vmware的FT功能的实现。

下面这个方案,在OpenStack峰会上有介绍。

https://github.com/openstack/masakari

ha

 

项目集成

目前在Big tent底下的项目,还剩下10个没有集成到Kolla里,里面的项目的成熟度,不少项目其实还没有达到可用的情况。相信在Otaca版本,可用把能用的项目都集成到kolla里。很多工作已经在进行中.

  1. Designate (DNS service)  (九州云朱冰兵同学负责)
  2. Dragonflow (海云捷迅马力同学)
  3. Freezer (Backup, Restore, and Disaster Recovery service) (九州云曹威同学负责)
  4. Karbor (Data Protection Orchestration Service)
  5. Searchlight (Search service) (麒麟李英俊同学,目前已经完成,merge)
  6. Solum (Software Development Lifecycle Automation service)  (九州云曹威同学负责)
  7. Tacker (NFV Orchestration service)  (老外已经在进行中,九州云的同事们会积极推进)
  8. Trove (Database service) (九州云朱冰兵同学负责)
  9. Vitrage (RCA (Root Cause Analysis) service)
  10. Zaqar (Message service)

我也希望联系国内上面项目的开发者,帮忙一起把项目放到Kolla里,真正做到想用啥就enable一下就可以。

剩下3个服务,看看最终谁来完成。

等Ocata版本发布,我们回顾一下,看看我们的成果如何。

Oct 062016
 

OpenStack的Newton版本,10月6号正式发布,作为安装部署工具,发布时间延迟2周,也就是10月21日。目前Kolla已经进入Bug修复阶段。

概述

Kolla的Newton版本的整个开发过程,我算是全程跟踪,九州云的5位同事积极参与Kolla社区开发,在Jeffrey Zhang,zhubingbing两位同事的积极和大力推动下,把下面的项目的Merge到Kolla里。

  1. rally
  2. tempest
  3. Barbican
  4. Sahara
  5. Telemetry(aodh,gnocchi,Mongodb的HA)
  6. Cloudkitty

在项目整合到Kolla里,如何帮助各种配置是最优,那么其实是需要各个项目的开发者支持和帮忙的,这次在Barbican项目的Merge,就得到大唐高鸿数据的朋友大力支持。

在OpenStack的Big Tent底下,目前应该有57个项目,有一部分是OpenStack管理项目,真正需要Kolla去集成的项目,应该也就是32个项目。

已经集成的22个项目

  1. Barbican (Key Manager service)
  2. Cinder (Block Storage service)
  3. Cloudkitty (Rating service)
  4. Congress (Governance service)
  5. Glance (Image service)
  6. Heat (Orchestration service)
  7. Horizon (Dashboard)
  8. Ironic (Bare Metal service)
  9. Keystone (Identity service)
  10. Kuryr
  11. Magnum (Container Infrastructure Management service)
  12. Manila (Shared File Systems service)
  13. Mistral (Workflow service)
  14. Murano (Application Catalog service)
  15. Neutron (Networking service)
  16. Nova (Compute service)
  17. Rally (Benchmark service)
  18. Sahara (Data Processing service)
  19. Senlin (Clustering service)
  20. Swift (Object Storage service)
  21. Telemetry (Telemetry service)
  22. Watcher (Infrastructure Optimization service)

目前只剩下下面10个项目没有集成

  1. Designate (DNS service)
  2. Dragonflow
  3. Freezer (Backup, Restore, and Disaster Recovery service)
  4. Karbor (Data Protection Orchestration Service)
  5. Searchlight (Search service)
  6. Solum (Software Development Lifecycle Automation service)
  7. Tacker (NFV Orchestration service)
  8. Trove (Database service)
  9. Vitrage (RCA (Root Cause Analysis) service)
  10. Zaqar (Message service)

预计在下一个版本,基本都可以实现全部覆盖。上面这些项目,国内都是有Core和开发者,不仅仅关心自己项目的代码,还需要关心项目如何让用户更加简单用起来。我也在积极联系国内各个项目的Core和开发者,希望他们可以挺身而出,帮助Kolla完成项目的整合。

希望1年后,大家应该也就不需要再关注安装OpenStack项目的问题,把精力放在如何利用OpenStack提升企业竞争力上。

Stable

在Mitaka版本里,Kolla下面的项目,其实已经经过我的严格测试,达到生产可用。所以我认为在Newton版本,已经进入稳定的状态。

Keystone

对于Keystone,启用了Fernet tokens,可以提高性能。

Glance

很多用户提出,让glance存储,可以实现NAS。

Nova

不少功能和NFV相关,日常和用户相关的功能,应该已经很稳定。

Cinder

目前已经支持lvm作为后端存储。

Neutron

支持L3 HA,DVR,并且还support Service Function Chaining in Neutron。

Horizon

很多项目的Dashboard都是以Horizon的插件提供,kolla目前已经支持各个项目的Dashboard集成。

Heat

目前OpenStack各个项目都会调用Heat来完成相应的功能,

 

成熟

所谓成熟项目,完全是根据我自己的主观来判断,简单点说,也就是我要求我的团队,在Newton版本把下面这些功能用起来,真正投入到生产使用。

Telemetry

OpenStack以前各个项目里,做的最差应该就是Ceilometer。可以这样理解,基本上是不可用。大概2年前,Ceilometer的PTL退任,专门搞了一个gnocchi的项目,用来存放Ceilometer的数据,大大提高了该项目的可用性。Ceilometer项目也改名为Telemetry,目前已经拆分成4个项目。

  1. Ceilometer (收集数据)
  2. gnocchi (监控数据)
  3. aodh (报警)
  4. panko (event)

另外还依赖Mongodb

gnocchi后端存储可以是对象存储,可以是ceph和swfit。对于用户来说,应该大家都直接选择Ceph,不会再另外再折腾一套swift来做存储。

Ceilometer作为数据收集,并且支持插件机制,可以通过colletcd来收集计算节点的各种信息。目前我了解的情况,Ceilometer基本可以收集我们需要的所有监控信息,包括IPMI的数据。

Panko是在Newton独立出来,event依赖elasticsearch,目前发布了1.0版本,还没有集成到Kolla里,这是比较遗憾的事情。只能等到下一个版本。

gnocchi的数据,还可以通过grafana来做展示。kolla已经集成grafana。后续如何更好展示和整合,需要验证。

CloudKitty

这是OpenStack的计费模块,根据社区,真的已经有用户在使用,非常难得。目前CloudKitty已经可以通过gnocchi来取数据进行计费工作。

其实对于私有云的计费功能的重要性,很多人都没有意识到。没有计费,你应该很难解决资源滥用的问题。无法了解平台的真实使用情况。

目前Kolla里的CloudKitty,功能基本是可用,九州云的同事,也基本验证过。同时社区的开发者中也有真正的客户在使用。

Ironic and Bifrost

Ironic,实现物理机器的管理,最终目标就是做到把物理机器当做虚拟机来管理。那么他至少要解决3个问题

  1. 多租户
  2. cinder 挂volume
  3. 安全组

那么在Newton版本,ironic终于支持了多租户功能,这也是我要重点测试的功能。

有一个很现实的问题,OpenStack平台的操作系统,如何安装,能不能也使用ironic来搞定。据说Mirantis也已经在做这个的验证和测试。Bifrost,其实就是一个单机版本的ironic,不依赖keystone。他可以完成kolla的裸机部署的问题。

Intel付出的很大的努力,让kolla支持Bifrost。要真正用起来,估计还是需要修不少bug。相信10月21号,Ironic可以做到真正跑起来。

Magnum

OpenStack的Docker项目,COE管理工具。在Mitaka版本已经集成,不过有bug一直没有跑起来。在Newton版本,bug已经修复,就等着大家去验证。

目前Newton,已经不需要依赖OpenStack的Lbaas的服务。

Sahara

OpenStack下目前项目很多,真正成熟的项目其实不多,Sahara算是为数不多,大家都比较认同,比较成熟的项目。在Newton版本里,已经集成Sahara,大家可以在上面体验如何玩大数据。

要把Sahara用起来,其实还是需要做不少工作,如cpu的Pin功能,镜像的制作等。后续真的要和搞大数据的玩家一起,争取把一个job跑起来。

Rally

这是OpenStack做功能和性能测试的项目,其实我的用途就是用来提供验收报告。搭建好一套OpenStack,功能是否都是正常的,其实大家都心里没底气的。如何证明平台的功能,性能都是满足预期,那么就需要一套自动化测试工具,不仅仅是功能,还能对性能进行测试。

目前Rally已经可以支持对vm的磁盘性能进行测试。在网络的性能测试中,我们需要用到另外一个工具Shaker或者vmtp。目前vmtp,已经集成到Kolla里。

Rally的深入使用,是需要大力的精力,目前很多项目都提供该项目的Rally脚本,来验证该项目的性能。

技术预览

下面这些项目都是非常对OpenStack应该都是非常有价值,我们需要投入精力去研究和关注

Barbican

这是OpenStack秘钥管理的项目,和安全密切相关。目前Magnum,Cinder volume加密,keystone,都可能使用到。

随着OpenStack进入企业,安全就是必不可少的一个话题。目前国内大唐高鸿数据投入人手在该项目的开发,这次kolla的集成Barbican,我同事也麻烦了很多次大唐的弟兄,帮忙解决了很多问题。

目前Barbican还有一个子项目 astellan,刚刚推出,还没有集成到kolla里,后续还需要麻烦大唐的朋友指导一下。

Watcher

这个项目很新,不过Kolla已经集成,这其实应该是项目开发者,积极推动的结果。

其实我也没测试过。不过我们经常讲故事,如何实现系统的自动优化,如何实现系统的自愈功能,那么这些功能,都是需要监控,根据经验做出调整,那么这应该就是watcher想要去做的事情。

大家可以通过Kolla,很简单的装起来,体验一下。

Senlin

这是IBM腾启明发起的项目。据说目前移动江苏研究院已经把该项目用起来。要投入点精力去研究,看看能帮助我们解决那些实际生产中的问题。

能不能解决vm自动疏散。我是希望aodh发出报警,Senlin去干活。

Murano

以前大家对该项目关注度其实很高,因为大家都觉得App Store应该可以考他来实现。不过后续Docker出现,也就给项目蒙上阴影。

目前Murano对Docker的支持,也比较有限。有几个比较要命的问题,安装的源,和rabbitmq的安全问题。

https://github.com/openstack/glare

glare是一个刚刚发起的项目,来解决应用的安装的二进制包的问题。

Mistral

国内企业很关心审批的流程,那么这个工作流的项目,是否可以解决这个问题呢?我也想调研一下。

Swift

swift其实有两层含义

  1. swift的api接口
  2. swift的一套对象存储产品,包括api和底层的存储

其实全球来说,swift的使用量都不是太多,对象存储,大家都倾向用Ceph来实现。那么Ceph的Swift接口,目前应该还没完成,还需要做点工作。

Manila

这算是一个vm as service的一个案例,如果有客户有需求,是可以去挑战一下。如果你希望使用manila对接CephFS,估计你会有点失望。

Kuryr

实现OpenStack容器的网络功能,要走的路应该还很长,尤其是刚刚换了老大,PTL。

Congress

实现policy,我其实也没搞懂具体是干啥,只能慢慢研究。和watcher类似,都是提供给运维人员使用。

Oct 042016
 

自从自己维护blog以后,基本一个月内,都会出现1,2次这种错误,以前解决的办法很简单,就是把虚拟机重启一下就可以。经常是网友在微信,qq,微博提醒我blog挂掉。

Error establishing a database connection

刚好国庆期间碰上,就顺便提高一下自己的运维能力,看看具体的原因。

tail /var/log/mariadb/mariadb.log

看到大概的错误

161004 11:21:05 InnoDB: Fatal error: cannot allocate memory for the buffer pool
161004 11:21:05 [ERROR] Plugin 'InnoDB' init function returned error.
161004 11:21:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
161004 11:21:15 [Note] Plugin 'FEEDBACK' is disabled.
161004 11:21:16 [ERROR] Unknown/unsupported storage engine: InnoDB
161004 11:21:16 [ERROR] Aborting

其实我也能猜到,肯定是数据库的内存使用有啥问题。

有错误,其实就是利用google,基本就有答案

http://www.webtrafficexchange.com/solved-mysql-crash-fatal-error-cannot-allocate-memory-buffer-pool

我使用的青云的虚拟机,swap分区,就是1G,所以应该也不需要创建。

编辑 /etc/my.cnf,

[mysqld]
innodb_buffer_pool_size=64M

重启mysql

systemctl restart mariadb

查看swap内存使用

# free -m
              total        used        free      shared  buff/cache   available
Mem:            993         431         386           6         175         424
Swap:          1023           0        1023

查看一下启动日志

[root@chenshake mariadb]# tail /var/log/mariadb/mariadb.log 
161004 20:42:46 InnoDB: Initializing buffer pool, size = 64.0M
161004 20:42:46 InnoDB: Completed initialization of buffer pool
161004 20:42:46 InnoDB: highest supported file format is Barracuda.
161004 20:42:46  InnoDB: Waiting for the background threads to start

密切关注一下后续的效果如何。

Aug 172016
 

Newton版本,应该是10月8号发布。作为部署的工具,Kolla,发布日期在10月20号左右。那么这次发布会带来哪些新的变化。

8月4号到8月底,Kolla团队进行134节点的测试,整个测试过程都做了记录

安装操作系统过程:https://github.com/osic/ref-impl/blob/master/documents/bare_metal_provisioning.md

测试过程:https://review.openstack.org/#/c/352101/11/doc/scale-testing.rst

测试用例:https://review.openstack.org/#/c/352101/ 主要是通过Rally来测试

基本上是把Kolla项目的BP整理一遍。Kolla项目,国内的OpenStack社区开发同行,其实参与积极性是很高的,我们一起好好推动Kolla的发展,顺便把公司的产品也搞好。

OpenStack目前大帐篷管理下的项目,应该是56个,数量也在不停变化,项目包括管理,安全等。真正需要Kolla去集成的项目,对用户有使用价值的,应该不超过30个。Kolla目前应该基本覆盖了大帐篷管理下的全部项目。

OpenStack projects are governed by the OpenStack Technical Committee.

http://governance.openstack.org/reference/projects/index.html

每个项目的详细信息

https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

9月1日,更新当前进度

9月15日,更新进度,也算是最后的更新。

 

Core项目

Keystone

对于keystone来说,有两个比较重要的,一个是ldap认证,这个已经merge,配置就可以实现,对于企业级来说,这个功能,还是需要的。https://review.openstack.org/#/c/340141/

另外一个就是fernet token。

https://blueprints.launchpad.net/kolla/+spec/keystone-fernet-token

已经merge

Nova

目前nova来说,已经是比较完善。后续估计需要做的是NFV的特性的东西。

https://blueprints.launchpad.net/kolla/+spec/kernel-hugepage-config

这个功能估计就需要下一个版本。

Glance

没啥变化,Glance分出一个项目Glare,专门提供特殊的源的服务,目前在开发中,希望通过这个项目,可以完善各种app store的安装问题。

Cinder

Cinder的问题,就是插件的问题,如果我要支持别的厂商的存储,如何玩。或者同时支持多个存储。

cinder的backup功能,我测试过,基本是正常。就是缺乏UI来实现管理。

Cinder底层的Ceph部署,已经支持外部Ceph的整合,这算是一个很大的进步。

Neutron

Neutron目前对OVS和linux bridge,支持都是非常不错的。vlan和vxlan,都是没问题的。

Neutron的3个插件,vpn,firewall,lbaas,目前lbaas已经完成,vpn正在进行中

https://blueprints.launchpad.net/kolla/+spec/neutron-vpnaas-agent

service function chaining with neutron,这是非常热门的话题,也是PTL重点关注,非常有希望merge

https://blueprints.launchpad.net/kolla/+spec/enable-networking-sfc-support

已经merge

ovs dpdk https://blueprints.launchpad.net/kolla/+spec/ovs-dpdk 代码提交,不过应该还是有问题。

opendaylight集成 https://blueprints.launchpad.net/kolla/+spec/opendaylight-support

我能做的,就是好好测试。

swift

这个没做测试,并且swift api,支持Ceph的功能还没实现,这个需要下一个版本。已经有bp

https://blueprints.launchpad.net/kolla/+spec/swift-ceph-backend

基础项目

这其实是我的的分类,提供给别的项目进行互相调用。对于用户来说,可能用的不多。

Tempest

不知道为啥,Tempest项目居然不是大帐篷底下管理的项目,不过这个项目的重要性,只要搞OpenStack开发的人都知道,专门做功能测试的。

目前Kolla已经可以支持Tempest。你装完OpenStack,可以直接使用Tempest来进行测试,非常方便。

Horizon

其实从我角度来说,Horizon也应该是Core项目,对于kolla来说,要解决最大的问题,就是各个项目的Dashboard,如何放进去,因为是Docker,就不是那么简单了。

对于我们搞OpenStack,解决这个问题,倒是简单,对于社区,要比较高雅的解决这个问题,还是比较麻烦的。

Newton版本,已经对Horizon的缓存设置做了优化,希望速度更快一点。

Heat

现在Heat的地位,在OpenStack里,还是非常高的。很多项目都需要调用它。用户用的不多。其实我认为Heat也是应该进入Core里。

Kolla项目的PTL,以前就是Heat的PTL,所以Heat集成,就完全没有任何障碍。

Desigate

Dns服务,这个大家其实关注度不高,不过现在重要性慢慢在提高。各个项目代码里,都在集成他。变得非常关键。

  1. Trove
  2. sahara
  3. murano

这种项目里,其实都需要用到dns服务。目前Kolla也已经在积极推进

https://blueprints.launchpad.net/kolla/+spec/ansible-designate

没有merge,只能等待下一个版本。

Barbican

这个项目,其实很少人知道。也是非常关键,和安全相关。秘钥管理。设计项目是keystone和Magnum。还有cinder的卷的加密,也是需要这个项目来存放。

这是Kolla的PTL重点关注的内容。代码已经提交,大家密切关注。非常高兴的是国内有朋友玩这个,在关键的时候帮忙解决不少技术的问题。

https://blueprints.launchpad.net/kolla/+spec/barbican-ansible

已经merge

功能项目

这些项目,都是为了给用户实现某个功能。

Telemetry

这是OpenStack争议最大的项目,以前名字是Ceilometer,现在已经改名,分为3个组件

  1. ceilometer 收集数据
  2. gnocchi (聚合数据)
  3. aodh (报警服务) (merge)

另外还需要依赖MongoDB,gnocchi,可以使用grafana来展示数据。

对于Kolla来说,Newton 版本,相关组件的代码都已经完成,等待merge。这也是一个工作量非常庞大的活啊。

把这几个项目调试通过,整合好,也不容易。需要做很多工作。也是重点。

全部merge

Cloudkitty

这是计费项目,Telemetry结合,实现计费的功能。这个项目还没有看到成果案例,目前只有一家公司在开发,不过从代码上看,还是很积极,从gnocchi来取数据计费。

我一直认为,在私有云,也是非常需要计费的功能。

https://blueprints.launchpad.net/kolla/+spec/cloudkitty

已经merge

Murano

Kolla其实在mitaka版本已经集成,不过因为Horizon集成的问题,一直都没用起来。Newton版本,解决掉Horizon的插件问题,

目前Murano提供了一个app 列表,有专门针对CI CD的。这个也是非常值得去测试的内容。

Murano一个功能,就是提供docker的app store,这个功能据说还不是很完善。

Ironic

裸机,物理机器是管理,这个是非常热门的项目,Newton版本里,ironic实现了多租户的管理。

Kolla在Mitaka版本就已经支持ironic,国内有朋友在测试。

目前kolla社区考虑安装操作系统,采用ironic的单机版本Biforst来实现

https://blueprints.launchpad.net/kolla/+spec/bifrost-support

PTL希望尽快合并,可以很好去做134个节点的测试工作。

bifrost已经merge。

Magnum

就是OpenStack管理COE的项目,非常热门。不过目前Kolla上的Magnum还是有bug,无法跑起来,这个是要去重点修复。并且希望可以和barbican进行对接,实现秘钥管理。

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

积极修复中,确保Newton版本可以使用。

Sahara

在红帽的发行版里,Sahara是获得正式支持,也就说明这个项目比较成熟。代码也已经提交。

https://blueprints.launchpad.net/kolla/+spec/sahara-role

我个人非常希望这个早日merge,目前Sahara是可以实现和ironic进行对接。Mirantis的Fuel已经产品化。这个调试通过的工作量不小。

已经merge。

Senlin

这个项目是IBM腾启明发起,那么我也非常希望kolla可以实现,好好研究一下这个项目。目前中国移动已经在使用。

https://blueprints.launchpad.net/kolla/+spec/senlin-container

代码已经提交。就看是否能merge。

已经merge

Trove

数据库服务,现在Iaas已经在逐步往paas层发展,提供各种服务。那么数据库服务应该是刚需。就是目前这个项目成熟度不高。

代码已经提交 https://blueprints.launchpad.net/kolla/+spec/ansible-trove

有时候也真的是用的人多,才有机会完善。

没有

Manila

kolla在Mitaka版本就实现支持Manila,不过没有测试。相信也很难支持Cephfs。

要跑起来,估计还是需要做不少工作,修复各种bug。

Watcher (Infrastructure Optimization)

这个项目很新,在Newton里,Kolla已经支持,这倒是不错。希望可以通过Kolla,让更多人了解这个项目的先进性。

Rally

代码已经提交,等待merge。

已经merge。

Mistral (Workflow service)

知道这个项目,是因为孔令贤是这个项目的Core。具体用途,真的不太清楚。很少看到介绍。

Mitaka版本,就已经支持。目前有bug,正在修复中,希望可以在Newton版本玩起来。

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

Solum

这是给开发者提供Docker作为开发工具的项目。目前九州云的曹威同学在推动

https://blueprints.launchpad.net/kolla/+spec/solum-support

没有merge

Freezer

这是提供备份服务的项目。该项目的开发进度不算是很理想,参与人不多。而且项目的难度也不小。目前Kolla还没有考虑,没有提BP。

Congress (Governance service)

https://blueprints.launchpad.net/kolla/+spec/enable-congress-container

没理解是做什么用途,不过社区代码已经提交,等待review。

已经merge。

Zaqar (Message service)

消息队列服务,在Newton版本是无法实现支持,只能等下一个版本去实现。

Searchlight (Search service)

我了解的这是给Horizon提供搜索服务的一个项目。目前麒麟的李英俊在推动

https://blueprints.launchpad.net/kolla/+spec/searchlight

网络

Kuryr

这是OpenStack专门解决容器的网络问题的项目,不过很可惜,到目前为止还没有支持keytone V3.

Kolla社区已经做了大量的工作 https://blueprints.launchpad.net/kolla/+spec/kuryr-docker-plugin

里面集成的内容很多。包括consul,etcd,都有。

目前最新的进展,Kuryr社区马上要支持keystone V3,Kolla的PTL非常希望merge这个项目。

已经merge。

Tacker (NFV Orchestration service)

九州云大师兄龚永生已经提交BP,等着他去实现这个功能。

https://blueprints.launchpad.net/kolla/+spec/tacker-support

Dragonflow

海云捷迅的马力同学,也提交的BP,正在做。

https://blueprints.launchpad.net/kolla/+spec/dragonflow

 

监控和日志

对于Kolla来说,所谓监控,变成了容器的监控,在容器的世界里,监控的方案就太多。不像传统的OpenStack监控,就只有Nagios和Zabbix。监控的项目都是OpenStack以外的项目。

ELK

社区在Mitaka版本,把Logstash换成了Heka,不过目前Heka已经不再更新,社区希望的是寻找一个Go开发的手机端。

不过不管怎么说,节点上所有的容器的日志收集,都是比较完整的。目前就是Kibana的图,没有实现默认配置。这个我在考虑一下,如何把Fuel上的Kibana图放到Kolla上的Kibana。

性能监控

目前社区的方案是

https://blueprints.launchpad.net/kolla/+spec/performance-monitoring

采用telegraf,influxdb ,grafana来实现。这个在积极开发中,应该是可以merge。是当前的重点。

另外一个方案 sensu https://blueprints.launchpad.net/kolla/+spec/sensu

  1. Sensu Client to collect checks and metrics
  2. RabbitMQ for transport
  3. Sensu Server to receive, evaluate, alarm and write metrics to InfluxDB
  4. Uchiwa as a Dashboard to Sensu
  5. InfluxDB to store metrics 6. Grafana to dashboard metrics

已经merge。

Jul 292016
 

现在的孩子真的很幸福,估计也是因为我小时候啥玩具都没有。所以也就特别舍得给他买玩具。

陪孩子玩得多,他的玩具我基本都记住了。

买玩具,其实简单,关键是谁陪孩子装起来。儿子还是很幸福的,他姥爷是这方面高手。据说很多家庭还需要在外面花钱请人陪孩子拼乐高。

Continue reading »

Jul 272016
 

2016年OpenStack中国峰会,最大的一个感受,就是厂商都在做容器化OpenStack。这已经是一个不可逆转的势头。

  1. Mirantis的Fuel也要实现容器化OpenStack
  2. Canonical的Ubuntu OpenStack,通过LXD实现容器化
  3. Rackspace通过LXC实现容器化OpenStack,已经投入生产
  4. 红帽已经开始验证OpenStack计算节点的容器化。

国内的厂商。其实应该都在做,公开的就是海云捷迅,九州云,麒麟三家。

对于容器公司来说,可以选择很多方式来玩,搞OpenStack是一件锦上添花的事情。对于OpenStack厂商来说,搞容器,可是生死攸关的事情。

技术实现

容器化的OpenStack实现,其实都差不多,就看各家谁更加彻底,更加优雅,更加安全。所谓彻底,就是完全对操作系统是免疫的,把容器删掉后,操作系统就好像没操作过一样。

一般来说都是

  1. build各种服务的docker 镜像。
  2. 利用工具进行编排,对镜像分发,把镜像启动起来。

有些厂商仅仅是把控制节点容器化。对于kolla项目来说,是把OpenStack和周边项目全部容器化

  1. ceph
  2. qemu
  3. libvirt

这些都容器化,甚至在讨论NTP服务,也需要进行容器化。

Kolla项目 https://github.com/openstack/kolla

厂商把OpenStack容器化,会带来哪些好处呢?

升级

这个其实大家都可以想到,容器最大的特点,就是升级。企业使用OpenStack,最大的一个顾虑,就是升级。尤其在OpenStack1年两个版本下,不断的有新的功能的需求的情况下,如果不能升级,其实是很痛苦。尤其在企业的迅速发展的过程中。

容器化的OpenStack,升级有多么简单呢?其实就是删掉容器,换上新的容器,用户基本是无感知的状态下完成。

升级子所以很困难,有一个很现实的原因,线上环境,很难模拟,升级验证测试很难进行。当采用容器化以后,我们很容易模拟出一个线上环境,进行升级测试,升级失败,回滚。其实这些都做的很漂亮。

灵活

以前厂商的解决方案,都是3个控制节点,如果我希望增加到5个控制节点,或者把控制节点某个服务单独部署,那么这个基本是很难完成的任务。

以前厂商都厂商把OpenStack的各个服务放到虚拟机里,这样部署灵活性提高不少。但是虚拟机还是很重,面对客户千百万化的需求,就有点无能为力。

举一个例子

企业基本节点,我规模很小,可能就只有几台机器,这时候,我可能不需要控制节点高可用,我就需要1个控制节点,管理机柜计算节点。

随着时间的发展,希望扩大规模,控制节点变成高可用。

规模进一步扩大,我就需要把消息队列单独出来部署,解决性能的问题。

这种需求,很实在,OpenStack厂商也在努力满足企业的这些需求,其实Mirantis的Fuel,已经在很多程度,满足了企业这种需求,不过代价很大。

对于容器化的OpenStack,就变得很简单,无非就是调整各个节点的容器分布,编排的问题。控制节点是3个,还是五个,rabbitmq放在什么位置,根本就不是问题。

配置管理

OpenStack过去使用最广的配置管理工具是Puppet,对于企业用户来说,这个是很难掌控的。其实在国内,就算是互联网公司,负责Puppet的运维人员离职,其实都是很难招聘回来相应的人员。

对于OpenStack厂商来说,要想完全掌控Puppet,还是很困难的。更别说,要满足各种灵活的需求。

配置管理工具,其实Salt和Ansible,是python开发,比较易用,不过在OpenStack的生态圈里,不如puppet强大,很难超越Puppet。

容器化后的OpenStack,配置管理工具,或者编排的工具,就很多选择,ansible,slat,K8S,都是可以支持。你就不需要受ruby的折磨。

其实这也是大大降低企业掌控OpenStack难度。

操作系统厂商依赖

厂商都在宣传所谓没有厂商绑定。其实你用了红帽的OpenStack,要想换到Ubuntu下,不是不可能,其实肯定很痛苦。如果要换成Suse,难度就更高。

各种配置管理工具,其实都是依赖发行版的包管理。国内的银行其实都使用Suse。但是社区的Puppet工具不支持Suse。或者我希望玩的项目,操作系统发行版没有提供包,怎么办?

容器化的OpenStack。其实理论上,可以跑在任何支持容器的操作系统上。内核的版本高,无非就是性能更好一点。其实你只需要做点测试,就可以实现这种跨操作系统的部署。

容器里,可以使用rpm包,Deb包,也是可以跑源码安装,这样其实对于操作系统厂商来说,基本就没任何的依赖。不受制操作系统厂商。

 

软件依赖

OpenStack项目的增多,软件互相依赖的问题,越来越严重。因为OpenStack很多项目是需要使用外部项目,例如Ceph,他的依赖很可能和OpenStack组件的依赖产生冲突。

这种问题,可以解决,但是解决,没任何的意义和技术含量,很让技术人员抓狂。其实发行版都在投入大量的精力去解决各个软件包的互相依赖的问题。

容器化的OpenStack,很好的解决了这个问题。

部署时间

在生产环境中,部署时间1个小时,和一天,其实区别不大,毕竟部署是一次性的工作。对于测试来说,就完全不一样。如果我10分钟可以完成一次部署,可以测试验证的东西,和几个小时才能完成一次的部署,差异还是很大的。

容器化OpenStack,大大加快了部署的时间,通常10分钟,就可以完成一次完整功能的部署,验证OpenStack各种新功能的代价,就大大减少。

显得简单

OpenStack在企业的实际使用中,都是抱怨太复杂,这其实也是因为OpenStack,松耦合,功能强大,同时也让用户感觉很复杂。尤其在出现错误的时候,很无奈。

容器化后,用户感觉OpenStack各个组件,就类似累积木一样,搭建起来,可以根据自己的需求,选择哪个模块。感觉自己是可控的。你可以很方便的装上某个模块,不满意,删掉。背后的复杂的逻辑,社区已经帮你完善。

遇到问题,寻求帮助,也显得简单很多。因为大家容器里的东西都是一样的,无非就是外面的配置文件。

也只要让企业感觉自己可以掌控OpenStack,这样OpenStack才会大量的进入企业的IT系统。这个时候,无论是采用外包还是自己运维。

计算节点HA

如果实现计算节点挂掉后,上面的虚拟机自动在别的节点启动起来。这个问题解决的办法,其实有很多,解决的难点,就在于我如何判断这台节点真的挂掉。因为虚拟机的迁移的东西,是很大的,必须很小心。也很容易造成误判。

海云捷迅提出一个使用consul的解决方案,就是一个容器里做健康检查的组件,放到openstack计算节点,类似peer to peer,互相检查。

当容器化的OpenStack后,那么就可以利用容器强大社区,各种的实现方式,第一时间知道节点失效。肯定你也是可以使用consul来解决这个问题,更加直接。

 

监控和日志分析

OpenStack一直都在完善自己的监控日志分析。不过进展并不太好。容器化的OpenStack,面临的监控,日志的问题,和以前的OpenStack有很大差异。

不过不得不承认,容器的世界里,这方面非常完善,太多选择,可以帮助你解决监控和日志分析的问题。

可以利用强大的Docker社区,来完善OpenStack短板的地方。

 

创新

容器化后的OpenStack,其实带来很多意想不到的创新和变化。很多以前很炫的概念,慢慢走向现实。

OpenStack一个版本的发行周期大概是分为B1,B2,B3,每个阶段大概45天,后续就发布RC,正式版本。

以往OpenStack公司都是等到一个版本正式发布后,进行打包,测试,验证,经过3个月和半年,正式对外发布。那么这种发布周期,其实已经有点跟不上OpenStack的步伐。例如Mitaka版本发布的时候,红帽的Liberty版本才正式对外发布。

能不能做到,OpenStack一边开发,发行版也在同步进行打包,测试呢?其实在OpenStack发展初期,有人提出这样的建议,不过对操作系统厂商来说,代价太大,不愿意去做。

有了容器化以后,完全不需要依赖操作系统的打包,我可以根据自己的需求,进行build image,测试,这样我的产品的发布周期,就会大大缩短。

总结

OpenStack上的很多问题,都是可以解决,只是解决起来很费劲,容器化,解决就显得很优雅。有强大的Docker社区,你解决问题的方法,方式就更多。