前言

前言

自本书第1版(基于Grizzly版)出版后,OpenStack 又获得了长足的发展,并已成为开源云计算平台的首选系统,技术体系也已发展至Kilo版。

相较于原来的几个开源平台系统,OpenStack基金会与Apache 2.0许可这两个重要元素对OpenStack的成功仍功不可没,在进一步展开之前,我们仍有必要回顾一下这两个重要因素。

OpenStack 基金会

OpenStack是NASA和Rackspace合作研发的,以Apache许可证授权的项目,并且是一个自由软件和开放源代码的项目。

NASA与Rackspace的合作决定了OpenStack开始时由Rackspace管理。但在2011年,为了能像Linux一样,更好地发展OpenStack,Rackspace联合部分成员成立了OpenStack基金会,并将OpenStack商标及相关社区管理交给了OpenStack基金会。基金会第一批白金成员包括AT&T、Ubuntu、HP、IBM、Nebula、Rackspace、Red Hat及SUSE这8个业界重量级成员。由于基金会相对独立,这样OpenStack才不受Rackspace的约束而获得更好的发展。OpenStack基金会中的技术委员将负责管理整个OpenStack项目的开发管理工作,而核心的开发者主要来源于基金会中各个成员以及分布在全球各个地区的软件人员力量。

自由软件之Apache 2.0许可、GPL许可

开源软件需要解决的最大问题是如何处理某个使用者使用开源软件来完成个人或商业目标的情况,即这其中所包含的版权与收益处理问题。当一个软件开发者打算将自己写的代码开源时,通常可以选择两个重要的自由软件许可——GPL许可与Apache许可。Linux采用了GPL(General Public License)许可,而Android及OpenStack则采用Apache 2.0许可,这两个许可的差异如下所示。

  • GPL许可:GPL保护下的软件版权属于开发者本人,软件产品受国际相关版权法保护。GPL允许其他用户对软件原作者的软件进行复制或扩散,并且在更改之后再发行自己的软件,但新的软件发行时也必须置于GPL许可下,必须公布源代码,用户不得对其进行其他附加的限制。在GPL下,不存在“盗版”。但用户不能将软件据为己有,比如申请软件产品“专利”等,因为这将侵犯GPL版权。

  • Apache 2.0许可:Apache 2.0许可下的源代码,商业软件可以任意使用,且对修改后的软件不需要再次开放源代码,只需要提及代码的原出处就可以了。意即,在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改。

GPL具备极强的传染性,比如软件人员在Linux基础上开发了一个新的软件代码后,新的代码仍受GPL限制,即仍需要以GPL开放源代码,贡献回Linux,这样Linux本身就发展得越来越好,功能也就越来越多。

虽然很多厂商都基于Apache 2.0 许可下的Android开发了很多新产品,但Android核心的更新版本仍由Google负责整理与发布。同样,OpenStack不同的版本也由OpenStack基金会整理与发布;同时,社区与厂商新包装的应用对核心的要求也不断返回OpenStack基金会技术委员会,并进一步促使更强大功能的新版本推出。而为了支持这些新版本的推出,OpenStack基金会的成员又同时提供了足够的人力与财力维持基金会的正常运作。因此,Apache 2.0许可下的OpenStack在推动技术创新的同时,核心维护者与应用厂商亦达到了“共赢”的局面。

如上所述,OpenStack基金会与Apache 2.0 许可这两个关键因素使得OpenStack的发展有效地在技术与商业利益之间获得了平衡,推动了整个行业对OpenStack的最终认可。

在向各类用户介绍OpenStack时,许多客户都经常问一个问题,开源的系统安全吗?可靠吗?

对于安全性来说,虽然这个问题有更多的含义需要揭示,但由于“开源软件的源代码是公开的,公众可以揭开代码的信息” 这个原因,而使得:

  • 软件源代码若有质量方面的问题,则更易于被发现并且被修正;

  • 软件源代码中无法隐藏安全秘密,安全漏洞易于被更快地发现与修正。

因此,从信息安全的角度来看,相较于商业软件,OpenStack至少没有一个可能的超级后门,安全性要高一些。

系统可靠性与稳定性则来自于Linux系统本身的能力,它与如何部署OpenStack有着密切的关系。虽然站在这个角度来说,客户需要一个专业的技术服务商来提供支持,但用户所付出的技术支持费用也仅是采购传统商业软件的几分之一而已。特别是当用户需要传统商业的厂商同时提供云管理平台(非虚拟化平台)、SDN网络、云存储等几个部分时,OpenStack的费效比则更高。

本书特点与章节安排

相较于第1版的内容,除了保留与更新了相关章节外,本书主要增加了虚拟桌面、Neutron与SDN、分布式存储、Swift对象存储、Hadoop弹性集群、Heat与Ceilometer组件、Docker、VMware与OpenStack镜像互转等新内容,即本书涉及云计算、SDN网络、云存储以及云平台上层应用等几个部分,对于读者充分理解OpenStack或整个云计算体系帮助更大。

同样,我们建议本书的读者仍需要有一定的网络与虚拟化基础。由于本书仍强调实践过程,所以并没有加入足够的基础理论内容,这一方面仍需要读者去补充。

第1章简要介绍了PXE这种最基本的操作系统安装技术,对于安装大规模系统有着较好的参考价值,保留本章的原因是许多读者对CentOS 的Kickstart 熟悉,但对Ubuntu Preseed机制不太熟悉。这里我们提供了Ubuntu 14.04 自动安装的Preseed样本,便于读者校正自己的脚本。

第2章的要点在于介绍最让人迷惑的网络部分。因为通常情况下,搞OpenStack的人员多是软件人员,对网络的理解一直都不太足够,所以这一章重点介绍了涉及的网络部分知识,理解了网桥、VLAN、VXLAN、GRE等重要原理,对于后期部署OpenStack的nova-network或Neutron Open vSwitch 有重要帮助。网络知识的不足,可能造成云系统的流量模式不合理而致使云系统性能达不到满意的程度,这也是困扰OpenStack开发人员的一个重要问题。第2版中,我们增加了网络空间的基础操作,以方便理解Neutron网络组件的基本原理。

第3章重点介绍了OpenStack的基本控制服务安装方法。之所以将基本控制服务安装独立成章,原因是这样在后期安装各种网络模式时,我们仅需要更换配置文件内容即可,无需重复阐述。

第4章以nova-network作为基本部署模式,讲述了小企业如何在最小的两台服务器环境下运行OpenStack,这样小企业就可以享受OpenStack带来的灵活与扩展能力,而无需花费太多费用。

第5章主要介绍了OpenStack桌面虚拟化。桌面虚拟化一直是OpenStack缺少的一项基本功能,本章给出了具体的示例。本章内容与第4章合起来,即可以为中小企业提供一个服务器与桌面虚拟化于一体的平台,即企业完全可以用OpenStack替换国外昂贵的商业软件。

第6章介绍了Neutron 组件的安装及VLAN、VXLAN和GRE这3种模式的网络配置方法,同时也给出了Kilo版本提供的分布式虚拟路由(DVR)功能。

第7章介绍了Neutron与SDN网络。这里我们以Neutron与Arista交换机融合为例展示了SDN架构下的融合模式及能力。对于企业私有云来说,本章有着较高的价值,可以减少云系统的运维工作量。

第8章介绍了分布式存储系统,主要介绍了MooseFS、GlusterFS以及Ceph这3种系统的基础安装与调试,以便于理解后续章节与Cinder组件的融合。

第9章介绍了另一个吸引人的话题,即中央存储与虚拟机动态迁移。这里我们以Netapp为例介绍了虚拟机热迁移的配置方法。

第10章介绍了Cinder卷存储管理组件的基本安装以及与Netapp、GlusterFS与Ceph等后端存储系统的融合配置方法。Cinder强大的开放能力也是传统商业软件厂商所无法比拟的,特别是与GlusterFS、Ceph等分布式存储系统的连接能力。

第11章介绍了Swift对象存储组件的安装过程。配合一些免费的客户端软件,它可以为企业内部建设云盘系统,可以解决目前企业员工普遍将数据存储于公网所带来的安全隐患。

第12章涉及当下最热的话题——Docker。本章介绍了Docker的基础,并以Docker挂载Ceph RBD磁盘卷为例展示了Docker在持久性数据卷方面的进展。同时,也介绍了OpenStack与Docker融合的几种方法,并以目前较为成熟的nova-docker为例展示了OpenStack与Docker的融合实例。此外,也简要介绍了OpenStack社区正在孵化的管理容器——Magnum组件。

第13章介绍了用于构建云系统上层弹性集群的Heat与Ceilometer组件。这里重点说明了如何结合使用Heat与Ceilometer使得集群可以动态扩展与伸缩,读者从中可以看到Heat组件在业务编排方面的能力。

第14章介绍了用于创建弹性Hadoop平台的Sahara组件。由于本书编写时,Sahara还没有提供Kilo下的安装包,因此我们以Icehouse为例说明了安装方法。

第15章介绍了OpenStack与VMware间虚拟机镜像的互转过程,这里我们以CentOS、Ubuntu以及Windows这3种虚拟机为例说明双向互转过程。本章的意义在于,企业完全可以以OpenStack为基础建设第二平台,并完全与已有的VMware平台间的虚拟机互迁。

本书不同于其他书的地方在于,它利用了许多图示,并增加了许多原理讲解,使读者能更好地理解一些关键的概念与原理,从而达到“不仅知道怎样安装,而且还知道为什么”这样的目标。

我的目标很简单,在Apache 2.0许可的情况下,使用OpenStack这种开源、开放、免费的云系统,为企业节省大量资金。虽然企业需要支付给专业的OpenStack技术服务实体一些顾问与运维费用,才能更好地部署云系统,但这个费用要远远低于企业购买商业虚拟化软件的花销。

我相信OpenStack对企业的价值,只是这种价值需要广为人知、广为人用。

致谢

我本人从2012年3月份刚开始学习OpenStack时,是看着北京-YZ(董斌)、陈沙克以及上海梁博的博客文章开始学习安装的,并在这个过程中得到了他们的支持,他们无私的分享不知对多少后学者有很大帮助,我对此久久难忘。此外,在GlusterFS的学习过程中,也经常得到北京刘爱贵的指点,在此表示感谢。

有人问我,你为什么还要写书,难道你喜欢写书? 或者说,是不是因为可以出名才写书?也有人和我聊天后就买了许多书,以为这样可以帮助我,因为他们觉得每买一本我就能赚点钱。

为什么呢?

因为我喜欢OpenStack,只有这一个原因。为什么喜欢呢?因为它有价值,它可以让企业节省许多成本。如果企业充分认识到此点,OpenStack将是他们私有云系统或第二虚拟化平台的不二之选。我经常对外人说,我的乐趣是看到许多企业用OpenStack建设私有云或虚拟化平台。

信立讯科技的工程师陈焱帮助我做了许多章节的测试与校正工作,在此也表示感谢。

当然,毋庸置疑的是,北京图灵文化发展有限公司也为本书的细节文字校正做出很多努力。

如果说感谢,不知道还要逐一感谢多少在我刚开始学习OpenStack时帮助过我的人,在此,我仅向愿意分享知识并在技术群内热心帮助后学者的人员表示感谢!

OpenStack中国社区技术群

在这里,我也介绍一下OpenStack中国社区的几个技术群,希望这些群能为后学者提供帮助。

  • OpenStack中国社区部署群:145923072。

  • OpenStack 中国社区开发群:202265873。

  • OpenStack 中国社区培训群:257479608。

  • OpenStack 中国社区综合群:11315737。

另外,中国社区的两个网站经常会提供一些有价值的内容,读者也可以上去看看:www.openstack.cnwww.openstack.org.cn

读者亦可就本书中的某些问题直接与我联系,我将尽可能提供帮助,我的邮箱为153757896@qq.com。

本书的基础参考资料

本书各章节的基础参考资料为OpenStack官网的文档为http://docs.openstack.org/,书中不再一一说明。

目录

  • 前言
  • 第 1 章 OpenStack基本操作系统环境的PXE自动部署
  • 第 2 章 OpenStack与网络
  • 第 3 章 OpenStack基本控制服务多点部署
  • 第 4 章 nova-network多机部署及企业应用
  • 第 5 章 OpenStack桌面虚拟化
  • 第 6 章 OpenStack Neutron 网络服务
  • 第 7 章 Neutron与SDN融合
  • 第 8 章 分布式存储系统
  • 第 9 章 OpenStack中央存储及虚拟机动态迁移
  • 第 10 章 Cinder卷服务
  • 第 11 章 Swift存储系统部署
  • 第 12 章 OpenStack与Docker
  • 第 13 章 Heat与弹性集群伸缩
  • 第 14 章 Sahara与弹性Hadoop集群
  • 第 15 章 OpenStack与VMware虚拟机迁移