Devstack作为开发OpenStack必不可少的辅助环境搭建工具,其重要性不言而喻,但是由于网络上的原因,在使用中总是出现各种各样的问题,而且也不是所有人对使用上的细节非常清晰,所以想用这篇Blog总结一下在三年多的使用过程中的心得,来帮助将要走进OpenStack开发的志愿者们。下一篇博客我将为大家介绍Devstack的源代码,以及扩展插件的开发方法。

本篇Blog主要介绍以下几个实用场景:

  • 如何利用Devstack构建一套完美的开发环境
  • 提高Devstack安装成功率的方法
  • Devstack的实用技巧
  • 各种场景下的配置和注意事项

本篇博客提到的所有方法均在2015年9月4日使用stable/kilo branch得到验证,后续版本请持续关注本博客。

在程序运行时给代码加补丁的方法被称为Monkey Patch,这种方式多见于脚本类语言中(Dynamic Programming Languages),例如: Ruby/Python等。国内很多人翻译为猴子补丁,但是为什么叫猴子补丁而不叫老虎补丁、狮子补丁呢?

估计刚刚看到这个表述的开发人员可能很难理解到底这是什么意思,其实Monkey Patch本与猴子无关,这个词原来为Guerrilla Patch,这样看着好像能明白一些了,游击队嘛,神出鬼没的,好像和运行状态打补丁这个功能贴近点了,但是为什么又变成猴子了。原来老外们都是很顽皮的,他们喜欢一些玩笑式的表述,就像很多技术的文档中一样。在英文里,Guerrilla和Gorilla读音是几乎一样的,Gorilla当什么讲呢?大猩猩。但是大猩猩有点吓人,所以干脆换成了大猩猩的近亲——猴子。就这样Monkey Patch形成了。

当然这并不是这个词的唯一解释,还有一种解释是说由于这种方式将原来的代码弄乱了(messing with it),在英文里叫monkeying about(顽皮的),所以叫做Monkey Patch。这种描述应该是和Monkey Test有异曲同工之妙。但是无论这个词从哪里来,我们只要正确理解Monkey Patch的含义就好了。

相同的表述还有Duck Typing,描述的是动态类型的一种风格。

最近一直在忙着搞Ceph存储的优化和测试,看了各种资料,但是好像没有一篇文章把其中的方法论交代清楚,所以呢想在这里进行一下总结,很多内容并不是我原创,只是做一个总结。如果其中有任何的问题,欢迎各位喷我,以便我提高。

优化方法论

做任何事情还是要有个方法论的,“授人以鱼不如授人以渔”的道理吧,方法通了,所有的问题就有了解决的途径。通过对公开资料的分析进行总结,对分布式存储系统的优化离不开以下几点:

1. 硬件层面

  • 硬件规划
  • SSD选择
  • BIOS设置

2. 软件层面

  • Linux OS
  • Ceph Configurations
  • PG Number调整
  • CRUSH Map
  • 其他因素

Devstack在Kilo版本中发生了一些变化,其中一个commit(279cfe75198c723519f1fb361b2bff3c641c6cef)的就是优化默认启动的程序,尽量减小对硬件的要求。如果不修改默认的配置进行安装,会产生一些问题,例如VNC无法打开,Heat模块没有加载等。这里给出一个个人比较常用的localrc,供大家参考。该配置在Ubuntu 14.04 Server LTS进行了测试。

OpenStack Kilo版本已经于2015年4月30日正式Release,这是OpenStack第11个版本,距离OpenStack项目推出已经整整过去了5年多的时间。在这个阶段OpenStack得到不断的增强,同时OpenStack社区也成为即Linux之后的第二大开源社区,参与的人数、厂商众多,也成就了OpenStack今天盛世的局面。虽然OpenStack在今年经历了Nebula的倒闭,但是随着国内的传统行业用户对OpenStack越来越重视,我们坚信OpenStack明天会更好。

OpenStack Kilo版本的完整翻译版本可见:https://wiki.openstack.org/wiki/ReleaseNotes/Kilo/zh-hans

OpenStack Kilo版本的翻译工作由我和我的同事裴莹莹(Wendy)共同完成,翻译校对工作由裴莹莹完成。如果翻译有任何问题,请各位多多指正。

Why

我想有以下有几个原因促使我写这篇Blog:

  • 很多人开始OpenStack之旅是从Ubuntu开始,但是却没有一篇文章系统的介绍如何将修改后的代码重新编译回DEB包。
  • 如果我们采用源代码直接安装的方式对OpenStack模块进行管理,一致性很难保证,难以维护。
  • Debian类系统的打包看起来比RPM包复杂很多。

Who

谁需要看这篇文章呢?

  • 不了解如何编译DEB包
  • 想把修改过的OpenStack源代码重新发布,供内部使用
  • 希望改变直接维护源代码

当然,如果您已经是这方面的高手,欢迎给我指正我Blog中的不足,十分感谢。

L3层Agent的低可靠解决方案

当前,你可以通过多网络节点的方式解决负载分担,但是这并非高可靠和冗余的解决方案。假设你有三个网络节点,当你创建新的路由时,会自动的将新路由规划和分布在这三个网络节点中的一个上。但是,如果一个节点坏掉,上面运行的所有路由将无法提供服务,路由转发也无法正常进行。在Neutron的IceHouse版本中,没有提供任何内置的解决方案。

译者注:OpenStack虚拟机级别的HA是在企业私有云中必须提及的话题,换句话说如果没有此机制,很多企业级用户根本不会考虑使用OpenStack+开源云平台的解决方案。这一点也得益于VMware等大公司孜孜不倦、持之以恒、长年累月的对用户的洗脑,这样的洗脑让用户觉得一些VMware的功能成为了“云”的标准(HA/FT/DRS/DPM等)。个人认为,OpenStack这部分功能的缺失也直接的阻碍了OpenStack进入中国行业用户的步伐,记得在夏天的时候,华为曾经为社区提供了一个HA的解决方案(用C语言实现),打算贡献给社区,但是经过社区激烈的讨论,终于不了了之。

在我所经历的私有云项目中,也尝试了一些虚拟机级别的HA解决方案,我的个人观点是,如果将OpenStack作为一个项目,可以不提供HA,但是作为产品,必须要提供HA的解决方案(私有云)。这篇文章中提到HA实现的过程,也恰恰是我们在实际中遇到的状况,下面让我们来看一看OpenStack社区是如何设想实现该问题的。感谢 @陈沙克 微博提供的资料。