Jan 232017
 

这是今年第一份kolla的月报,1月26号,OpenStack将要发布Ocata版本的B3。由于OpenStack的发布周期调整,对于Ocata版本来说,变得很特别,整个开发周期,也就只有4个月左右。2月3日就标记RC1,2月24日,正式发布。

对于Kolla这种部署项目,OpenStack TC (技术委员会)要求是Ocata版本发布后2周,也就是3月10号发布。所以Kolla Ocata版本,4.0,将会在3月10号发布。

https://releases.openstack.org/ocata/schedule.html

对于Kolla来说,Ocata版本还需要进行Repo的拆分,把Kolla拆分成Kolla和Kolla-ansible。这也是为了日后的发展需求,不过Repo拆分,肯定也会影响开发的进展,CI需要重新构建,这都是会影响开发的进度的。

整个Ocata版本,贯穿老外的圣诞节,中国的春节。项目的很多设想,和实际进展,其实是差距比较大的。不过对于Kolla来说,在Ocata版本,取得的进展,其实是远远超过Kolla的PTL的预计。

这是Kolla Offical项目 Ocata版本到2017年1月23日的数据(包括kolla, kolla-ansible, kolla-kubernetes),大家看底下的数据,不用仅仅关注第一,还有很多很有价值的信息。

Kolla项目的Independent的贡献比例非常高,很可能是所有OpenStack项目里最高。大家要留意others的比例,这个比例越高,能很好说明这个项目的活跃度,参与度。

Snap1

irc0继续竞选PTL

1月份其实还是项目的PTL竞选,irc0,代表intel担任在Ocata版本担任PTL,目前已经在申请下一个版本的PTL,当选应该问题不大。不过后续,他如何兑现他的诺言,找intel要300台机器来给Kolla做测试,这个是需要他好好考虑的。

在Ocata版本里,Intel其实是投入了不少人手参与Kolla的开发,贡献了很多很有价值的功能。

  1. Opendaylight
  2. dpdk

尤其是DPDK,对kolla项目未来发展,还是非常有帮助的。预计在Ocata版本merge,问题不大,这个就不需要怀疑。

Kolla优化

在Ocata版本里,Kolla要解决掉上次100台机器测试所遇到的问题。

部署一次Kolla,需要30分钟,却发现修改配置,也差不多需要同样的时间,当规模大的时候,变得不可接受。

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

工作量很大,不过必须在3月10号发布前完成。这基本是Ocata版本的一个重点。

另外一个端口检查的优化。以前是安装kolla的时候,会把所有的项目要求的条件都检查一遍,这样导致很浪费时间,现在是把检查放到每个项目里,只有你启用该项目,才会对条件进行检查,这样更加合理。这个代码重构,已经全部完成。

 

Ironic

对于Kolla来说,如何应对初始化的操作系统安装,其实大家都在解决这个问题。利用ironic,是一个思路。不过罗马不是一日建成的。Kolla的ironic,先要能用起来。

经过张雷同学的努力,目前ironic inspector已经修复,可用。这是一个令人振奋的feature,很多人已经着急的不得了。下一步,就是解决ironic的多租户问题,目前ironic支持多租户的网络,对你交换机是有要求的,只支持Cisco,华为的等有限几款交换机,不过幸运的是,我实验的交换机支持,所以Kolla的ironic支持多租户,应该是问题不大。

Panko

Telemetry项目,包括Ceilometer,aodh,Panko,Gnocchi,目前Ceilometer项目的拆分功能,已经进行最后的阶段。很多以前ceilometer的功能,都会去掉,你只能使用aodh和panko。

目前Kolla的Panko,在朱冰兵同学的努力下,已经merge。到目前为止Cloudkitty+Telemetry一整套组件,全部merge。另外包括Grafana,Collectd的组件,Kolla也已经集成。后续我们需要的是解决前端展示的问题。

对于Cloudkitty项目,他是通过调用Aodh,Panko来实现计费功能,目前国内对Cloudkitty项目关注度很高,也已经有两位项目的Core,希望可以在Ocata版本给大家带来一个惊喜。

NTP服务

Ceph存储的故障,估计20%都是因为时间没同步造成的,所以NTP服务就显得很重要。对于Kolla来说,如何解决时间同步的问题呢?

Kolla的设计理念,我的理解就是不对目标机器进行任何的修改。甚至包括NTP服务。目前Kolla考虑把ntp也放到Docker里,为理想而奋斗。

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

张雷同学负责,我很放心。

多Region和Cell V2支持

欧洲原子能机构,应该是OpenStack最大的科研用户,他们就是通过Cell的功能,实现大规模的支持,OpenStack的Cell的功能,其实都是他们在帮忙完善。目前Kolla已经在积极支持Cell v2。后续如果他们可以采用Kolla来部署OpenStack,真的是一个重大利好。

多Region,也已经在日程中,对于Kolla来说,实现代价不大。就看时间进度安排。

 

Big Tent项目

对于一个OpenStack部署工具来说,对OpenStack支持数量,质量,是一个用户重要考虑的指标。目前已经Merge的项目

  1. Karbor
  2. Designate

在Master开发的项目有

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

可以这样说,Kolla所有需要集成的项目,都已经在Master里,这次Ocata版本,会不会全部都Merge,这是一个很大的悬念,大家就密切关注把。

Ocata版本上面的项目开发,其实和以往有很大的不同,我邀请各个项目的Core或PTL帮忙review,这次Dragonflow的马力同学,Zaqar的王飞龙,Zun的Hongbin Lu,Karbor的华为团队,都参与的Kolla的项目的review,大大提高的Kolla的项目的代码质量。

我同事曹威同学负责Dragonflow项目,得到马力同学的大力支持。在实现过程中,还发现Dragonflow放2个bug,目前马力同学在修复中。只有大家在社区里密切合作,才能把OpenStack做的更加强大。

Jan 032017
 

在我看来,目前的OpenStack的部署工具,已经很完备了,尤其是Kolla,至少可以满足我提出的各种需求。那么在部署安装的问题解决后,我们其实对日后的如何用好OpenStack。就需要做一下研究。

我这里整理一下我所关注和思考的问题,其实也是OpenStack交付给用户,我们要回答的问题。

CPU和内存超分比例

经常有人问我,一台机器可以虚拟出多少台虚拟机。对于这个问题,我的答案永远都是:It depends。完全取决于你,从1个到100,都是可能的。

OpenStack默认的cpu超分比例是16:0,内存是1.5:0。那么生产环境是如何配置呢?

这个需要我们认真考虑,不同的OpenStack使用场景,确实区别很大。对于开发环境,16倍的超分比例,很可能也跑的很好。内存也是可以超分。

目前看到的生产环境中,稳妥的做法是4:0超分比例,内存不超分,这样的做法比较多。

这里面要简单介绍一下KVM计算cpu超分的计算方式

一颗物理cpu,是12Core,超线程,那么就是24Core,如果我们不做任何的超分,1.0,那么就是24个Core,创建4core的虚拟机,可以创建6个。

如果我在参数里设置的cpu超分比例是4.0,那么就有24*4=96core,对于4core的虚拟机,我就可以创建出24个。

CPU和内存预留

对于计算节点的cpu和内存,需要保留多少,尤其现在超融合架构下,保留多少比较合适,都是比较争议的问题,不同的软件版本,不同的硬件条件。

对于超融合架构,采用ssd,以前是需要专门做cpu的预留和绑定,不过现在好像很少人谈及这个问题。

不过一般习惯,大家都是内存保留4G,现在内存比较便宜,4G内存跑计算节点各种服务,问题不大。

CPU的预留多少给主机使用,这个参数,很多环境下都不设置,不做任何的保留。

Flavor

一般开始的时候,很少考虑Flavor该如何设置,不过真正使用起来,Flavor问题其实很多,因为一旦Flavor有虚拟机使用,你就无法删除和修改,如果你对flavor做任何操作,都会导致虚拟机产生各种问题。

OpenStack默认初始化的Flavor,在实际中应该做调整。

目前OpenStack支持 专门租户设置特别flavor,所以我们建议生产环境,设置2个flavor

  1. 4core+8G内存
  2. 8Core+16G内存
  3. 1Core+2G内存

第三个flavor,主要目的是测试使用。日常用户使用2个flavor,应该就足够了。这个其实也需要考虑主机的内存,到底多少是最合适。

如果机器是512G内存,16G内存的虚拟机,可以创建32个,减掉系统保留内存啥,30个虚拟机是没啥问题的。

对于core来说,我们就需要240个Core,如果一个cpu是15个Core,超分比例是4,那么就基本够用。从成本角度,15个Core的cpu很贵,通常12Core的cpu,比较合算。

镜像

这个就很重要,不过过去来讲,私有云的镜像制作都很不正规,导致很多问题。

一个linux的OpenStack镜像,其实是需要做很多工作,用户用起来,才会感觉好用。

  1. 上传镜像,必须指定内存和硬盘的最小要求,这样可以避免很多用户出错
  2. 上传qcow2,转换成raw格式,
  3. 只提供最小化安装的linux镜像(centos 7.2,centos 7.3,Ubuntu 16.04)
  4. 集成qemu agent
  5. 关闭selinux
  6. 不设置wap分区
  7. 加快ssh速度,设置ssh不用dns
  8. 指定源,加快速度
  9. 可以设置密码

对于OpenStack特殊服务,例如ironic,sahara,trove,其实还需要特殊的定制的镜像。

镜像上传,只能让管理员上传。

租户和计费

很多情况下,为了方便,创建用户,都分配管理员权限,导致很多管理问题。还是要求一个租户,一个用户对应。这样好管理。不能那么随意。

对于租户,计费系统要启用,这样才能了解到资源是如何消耗掉的。

Jan 022017
 

这是酷威第四次保养,估计是经济形势的原因,亦庄的港龙店已经关门,所以也就只能尝试别的店进行维修保养。这次选择来广营店(汇杰伟业)来进行保养。

以前北京有6家克莱斯勒的4s店,买车是在亚运村的安源店,保养是在亦庄港龙,海淀中进百旺,这次是来广营的汇杰伟业。最近由于港龙退出北京市场,新增加一家店冀东通,不过环境很差,我到那边就感觉不好就去汇杰伟业。

这家店还是很大,不过就是好像暖气不足。不然其实是很不错的。应该比我去的其他几家店都要大,包括停车场。

这次保养的公里数是3万六,离上次保养,开了一万公里。主要是春节期间打算回趟广州,估计要跑6千公里,稳妥起见,还是保养一次,就当检查一遍,再出门。

维修费用

  1. 机油滤清器     83元元
  2. 合成机油5w-20 1L   83*5=415元
  3. 酷威空气滤清器      236元
  4. 空调滤芯               124元

合计858元。相比我以前的几次保养,其实配件价格都要低一些。

不过这里工时费就有点贵。

换空滤,空调滤芯,工时费2工时,220,加上保养工时费2.2工时,220,工时费是:440。

总费用:1298元。

比上次保养大概贵了100 多一点。在中进百旺那边,换滤芯工时费是22元。不可能什么都是最便宜,整体来说,都是还是可以接受。

作为一个汽车维修专业毕业的人士,很多事情,都是可以理解和接受,还很明白啊。

Dec 292016
 

一眨眼孩子已经上小学,马上第一个学期就完毕了。所以在年底来临前,记录一下。

每次写这个都会看看半年前写的文章,真的是需要记录。

 

基本情况

  • 身高:126
  • 体重:50斤

感觉真的长大了。

小学生

在北京上小学,孩子的接送,肯定都是一个大问题。这次老婆不上班,回家专门接送孩子,中午孩子去小学周围的小饭桌,也算是解决了上学的问题。

小孩对于上小学,还是比较期望,适应很快。比较享受在学校的过程。这倒是非常不错。

因为孩子嗓门大,所以体育老师让他当体育班长(我们以前叫体育委员),儿子积极性很高,体育课是周1到周4都有,所以每天都要整队。

作业肯定是家长最关心的事情。作业多少一般和学校传统有关,也和班主任有关。后南仓的传统就是作业很少,这次儿子还幸运,还碰上一位作业上的班主任。每天的作业,基本就1个小时就差不多。

现在的英语作业,倒是很幸福,有专门的app,对着英语教材,教小孩读,作业也是通过app来布置。真的是一个很大的变化。老师也是通过app来布置作业。

如果家长没有手机,孩子都无法完成作业。时代真的是变化了。

其实一直都希望孩子上学,可以真的做到,好好享受小学生这个过程,无忧无虑,快乐。

培训班

儿子在幼儿园的时候,就一直坚持没有上过培训班,仅仅参加幼儿园的下课后搞的培训,这样只是晚去一个小时接小孩。

其实上小学,我也没打算让孩子上什么补习班。本来有一个剑桥英语培训班,在学校里开班,让小孩放学,在他们教室上课,倒是很方便,不过后来过2个月,就取消。所以孩子也没有继续上所谓的英语培训课程。

也是巧合,今年通州有篮球的培训班,专门针对小孩,刚好在家门口。孩子刚好也感兴趣,也就给他报名,每周去练习打篮球。对于体育班长来说,打好篮球是必须的,也希望孩子可以一直打下去,1年,培训费用8k,不便宜啊。有专业的教练教,其实还是不错的,姿势练的很标准啊。

滑冰,北京冬奥会,通州也搞了几个冰场,有专门教练,教大家滑冰。还和学校联合,培养冰球队员。对我来说,让小孩玩玩冰球,也是好事情。现在小孩基本可以做到,每周去冰场滑冰,找教练教,现在已经用球刀来滑冰,不知道什么时候,可以穿上冰球服,来打几下。

让孩子多运动一下,多点爱好,以后可以玩的东西多一点,这是我的想法,肯定没有任何念头让他搞所谓的体育。

孩子现在还特别爱画画,每周二的美术课,都要带上一堆装备去画画。

生病

孩子班里,基本每天都有小孩请假,生病。估计也和北京的雾霾有关。还好,儿子也就咳嗽了一段时间后,也就基本没啥事情。1个学期下来,也就请了一天所谓病假,在家休息一下。

身体好,比啥都重要。

Dec 232016
 

还没有到月底,不过由于圣诞节的原因,社区的开发,在未来的1周内,基本会处于停止状态,所以这个时候做总结,时间也就比较合适。

Sam Yaple强势回归

大家如果看过我以前写的文章 Kolla的江湖 应该知道Sam是一个多么强悍的人物。这次Sam代表Rackspace,重新回归社区,真的是让整个Kolla开发社区都感到很兴奋。

这次Rackspace还派出文档的社区人员专门帮助完善Kolla的文档。

未来2个月内,大家应该就可以感受到很大的变化。

Sam这次回归,要力推Kolla-salt,这个应该会发生在下一个版本。在Ocata版本,Sam还是全力完善Kolla 和Kolla-ansible,帮助ansible变得更加强壮。

目前Sam在做Monasca项目,在Ocata版本merge,基本不会有任何悬念。目前Docker file已经Merge. Roles 正在进行中。Monasca,让大家对OpenStack监控多了一个选择。

Kolla掉电测试

这次Sam回来,给我们分享很多好的消息。以前OpenStack群集,遇到机房,机柜掉电,其实不是小概率的事情。一旦碰上,其实要把群集恢复正常,是需要很长时间和麻烦。

对于Kolla部署的OpenStack,如果整个群集掉电后,如何恢复呢。有啥启动顺序呢?其实我也一直想问这个问题

答案是,你不需要做任何东西,把机器开机,所有服务会自动修复,不需要做任何的操作。这就是传说中的所谓自愈功能。

我是听青云的Richard讲通过机器人,如何实现系统自愈故事长大的,这次在kolla看到如此强悍的功能,真的比较激动。

Fluentd替换Heka

由于heka项目已经不维护,所以Kolla社区要替换,经过讨论,决定使用Fluentd 来替换Heka.

Kolla的Heka,其实是在Mitaka版本,由Mirantis推动实现的,不过后续由于公司原因,也就基本不完善,也导致目前Kolla的日志(Kibana,Elasticsearch, Heka) 有很多需要改进和完善。

这次Fluentd替换Heka,Kolla社区定的目标就是实现用户无感知的替换。九州云的朱冰兵同学把这个任务承接下来,同时得到国内的日志厂商Loginsight 杨志斌同学大力支持,专业的事情,真的要专业人士帮忙。你真的会发现,我们眼里的难点,他们感觉so easy。

目前替换工作的验证,已经基本完成,基本做到无缝升级。后续会邮件里讨论什么时候实现Merge,后续还是有不少体力活需要去完成。

后续还有2项工作,我希望可以完成

  1. 完成Kibana和Elasticsearch 5.x的升级
  2. Kibana图制作

这次得到国内日志专业厂商Loginsight朋友帮忙,应该是可以进展更快。

Kolla是希望做到OpenStack开箱即用,这个目标其实已经基本实现,同时也希望可以做到周边的运维工具,也是可以开箱即用,这个真的需要努力去实现。

Ceph的Swift API

现在OpenStack很多项目,涉及备份的,都会依赖Swift,那么其实是swift api,例如Karbor,Freezer,Trove等项目。用了Ceph,还需要折腾一套swift存储,是很麻烦的事情。

这次九州云的江军波同学,把Ceph的Swift API功能加上,让世界变得更加美好。其实如果能把S3接口也加上,那就更好。

Horizon插件

OpenStack项目的UI,基本都是Horizon的插件形式添加,目前Kolla社区已经决定把所有的插件UI都merge到Horizon的Docker里,这个工作基本已经完成。日后大家装各个项目,UI就会自动加载到Horizon里,比较方便。

 

Big Tent项目

我做了一个统计,目前Big Tent底下,有60个项目,Kolla需要去实现部署的36个。目前已经merge 27,动工的8个。

上个月进行的Kolla项目拆分,导致DNS项目Designate遗留,需要重新提交。不过也是好事,在重新提交过程中,由于Sam的回归,其实发现了Designate以前其实存在很多问题,目前在根据Sam的意见进行整改。

目前在Master中,已经Merge的项目

  1. Tacker (NFV项目)
  2. Octavia (Neutron的负载均衡实现)

Tacker(NFV)和负载均衡,都是用户关注度很高的功能,这次总算实现了。

正在开发的项目有

  1. Designate
  2. Freezer
  3. Karbor
  4. Monasca
  5. Zaqar
  6. Zun

以上6个项目,都在积极推进中,在Ocata版本Merge,基本问题不大。

计划动工的项目

  1. Dragonflow
  2. Vitrage

难度最大的肯定是Dragonflow项目,目前已经得到海云捷迅的马力同学大力支持,和九州云的曹威同学一起联合完成,努力在Ocata版本实现Merge

Vitrage,目前让九州云陈星同学负责,同时也希望中兴参与Vitrage开发的朋友多多支持。

目前就剩下一个项目 Tricircle (Networking automation across Neutron service) 华为的级联OpenStack项目,还没有进行中。

Dec 082016
 

怎么让OpenStac镜像k更加好用,这是我一直都想去解决的问题。我想整理一下我的需求,后续让同事跟进,把这些问题都彻底解决。

于CentOS和Ubuntu,其实都有有官方镜像,默认的官方镜像,其实还是非常不错,也比较流行,那么这些官方镜像,我们直接拿来使用,其实还是有不少问题,在一些特别环境下。

很多用户都是拿上传的镜像修改完,转成镜像,其实我一向不喜欢这种方式,这样做,应该会有不少隐患。所以我希望在镜像上传前,可以做更多的定制。

也是在私有云领域里,用户对镜像的需求。

镜像磁盘大小

这个CentOS官方镜像默认是8G,Ubuntu默认是3G,通过镜像带的磁盘扩大的软件,其实是可以在创建,resize的时候,调整硬盘的大小。

现在公有云默认的linux磁盘大小是20G,40G,系统盘是不能调整大小的。这其实也是有利用提高性能,在创建的过程中,不需要调整硬盘大小,加快创建速度。

windows的镜像大小是60G。

所以在实际中,公司内部私有云,我希望所有的镜像默认的磁盘大小都是60G,这样其实也好管理,同时在大部分情况下,都是不需要增加磁盘,就可以满足需求。

另外还是要有工具,在镜像上传前,调整系统盘大小。

需要强调的是,在OpenStack上传镜像的时候,一定要填写上对硬盘和内存的最小要求,这样可以避免用户创建虚拟机的出错。

操作系统版本

由于我们经常遇到不少软件是需要指定版本,才能跑起来,所以我们镜像要写上os的版本号。建议

  1. centos 6.5
  2. CentOS 6.8
  3. Ubuntu 12.04.x
  4. Ubuntu 14.04.X
  5. Ubuntu 16.04.x

centos 6.5的镜像,就只能自己单独制作。其他镜像,可以下载官方镜像,进行定制修改。

操作系统的源

要对操作系统的源进行定制。指向国内的源,阿里,中科大等目前速度非常不错的源。同时如果有必要,也是可以指向内网的源。让运维人员可以修改镜像里的源。

调整磁盘大小

在公有云的场景下,其实系统盘,是不允许调整大小。不过这个需求,在企业私有云里其实是很旺盛。默认OpenStack也是支持磁盘扩大。

所以我们需要在确保镜像是支持磁盘大小的调整。对于不同的linux,装的包是有点不一样。

http://xcodest.me/centos-root-partition-auto-grow.html 

启动速度

优化虚拟机的启动速度,其实还是很有意义的。这里面最需要处理的就是cloud init。

http://xcodest.me/cloud-init-cause-vm-boot-slow.html

尤其在没有联网的环境下,会导致虚拟机启动速度很慢。

镜像的密码

作为服务商,肯定会建议用户采用秘钥登录,但是现实中,用户都是把虚拟机设置root的密码,做快照,生成新的镜像。

centos和ubuntu,默认的登录的用户名也是不一样。

我倾向是都改成root账号

如果我采用密钥登录,会出现一个尴尬的情况,就是控制台无法登录。

我考虑是,给镜像的root设置一个密码。同时也是可以在上传镜像前,把root的密码修改成自己需要的。

同时ssh的设置,也需要做些调整。默认是不允许root登录,密码登录。

如果虚拟机创建的时候,设置了root密码,那么就覆盖了默认的密码。这时候,是允许root的远程登录的。

vnc设置

vnc其实是比较消耗资源,如何在vnc不使用的情况下,自动退出,这个其实是需要考虑的。在私有云使用里,因为vnc没有关闭,导致最终资源消耗过大,是一个场景的问题。

解决这个问题,可以从镜像入手。

SSH优化

默认ssh访问,是需要请求dns,所以需要在ssh的配置文件里,设置

UseDNS no

定制包安装

在实际中,用户经常会提出要安装linux的桌面,开发环境的镜像,这样方便,这些需求太多,所以有一种办法,让工程师,可以直接操作镜像,把需要的组件安装好,再上传镜像。

事实上,OpenStack后续很多项目,sahara,murano,trove,都涉及镜像的定制。都是使用disk-image-builder 工具,可以好好深入研究一下。

https://github.com/openstack/diskimage-builder