前言

前言

除了技术特点以外,OpenStack 吸引我的地方是,它是如何被创造出来的,这么庞大而复杂的系统又是如何采用社区开发模式管理的。而更重要的是,如果我们从 OpenStack 本身吸收了很多东西,我们又能为 OpenStack 的推广与应用做些什么呢?

思来想去,我们可能没有能力对 OpenStack 的核心代码作出贡献,但可以为更好地应用 OpenStack 作出贡献,即是说,如果我们将验证环境或生产环境中获得的各类测试性经验用一本书的形式分享出来,那么这对于 OpenStack 初学者或打算使用 OpenStack 云系统帮助企业降低支出的 IT 人员来说是一件好事。

特别是,当我亲耳听到许多不太缺钱的大型企业 IT 人员在为商业虚拟化软件高昂的成本而忧心时,这种愿望就更为强烈。开源、开放、免费的 OpenStack 系统难道不是很多企业更好的选择吗?如同今天当企业内部把应用部署在开放的 Linux 系统上时,难道还有人会对这种选择产生质疑吗?

当 OpenStack 支持 EMC、NetApp、IBM、华为等专业厂商的存储系统后,我就感觉到,很多企业使用 OpenStack 作为虚拟化或云系统的时间不远了。

当然,如同早期大家担忧将应用软件部署到 Linux 上行不行一样,OpenStack 各组件也有一个软件的成熟过程,只是这种成熟过程可能要比大家想象得快,如我在 2012 年 3 月学习的是 E 版,而 2013 年 10 月就发布 H 版了。

这里我试图整理一些材料,让读者了解 OpenStack 是在什么样的机制下创造出来的。同时,也给出企业所关心的开放、开源软件的质量与安全性方面的资料供读者参考。

OpenStack的由来

OpenStack的发展历史

OpenStack 的发展与 Nebula 的 CEO Chris Kemp 有关。当他在美国宇航局艾姆斯研究中心(NASA's Ames Research Center)工作时发现,每当需要更大的计算能力时,中心就会购买更多的超级计算机,他想为什么不能像 Google 那样,用成本更加低廉的普通 PC 服务器构建一个具备庞大计算能力的资源池,然后分配给需要的人使用呢?于是 Kemp 和一些持有同样观点的人员就开始计划基于普通的 PC 服务器写一套统一管理与调度计算能力的软件系统。

与此同时,以提供 IaaS 见长的全球排名第二的公共云服务提供商 Rackspace 也打算用一套开放、开源的云系统软件管理众多服务器,以更好地提高资源利用率,降低客户与服务商的运营成本。

当 Kemp 成为 NASA 的 CTO 后,他注意到 Rackspace 与 NASA 都在寻求同样的东西,于是他们决定共同用 Python 写一套云管理软件,NASA 负责其中名为 Nova 的计算服务部分,而 Rackspace 则负责名为 Swift 的存储部分。于是,OpenStack 诞生了,并且在 2010 年 10 月负责镜像管理的 Glance 部件也加入了其中。于此同时,Kemp 放弃了 NASA 的工作,成为以私有云为目标的 Nebula 公司的创始人之一。

Rackspace的历史和愿景

1996 年,Richard Yoo 在美国得克萨斯圣安东尼奥的一间公寓中创建了小型的以互联网服务为目标的 Cymitar 网络系统公司,集中提供互联网接入及主机托管服务。1997 年,他与 Dirk Elmendorf 合作,重组了公司,将开发互联网应用作为核心业务,同时更名为 Cymitar 科技集团公司。随着公司的成长,Patrick Condon 于 1998 年加入了公司。巧合的是 3 位创始人均来自圣安东尼奥的 Trinity 大学。

虽然 Cymitar 公司的业务是以开发互联网应用为核心的,但 Richard 发现很多公司并不知道如何去托管并运行他们的应用,甚至没有愿望去介入到这些托管业务中。虽然他们的愿望是做应用软件开发而不是做主机托管业务,但他们又一直找不到机会将这些主机托管业务外包出去。最终,他们决定以经营主机托管业务为基础成立一家新公司。1998 年 10 月,Rackspace 成立了,Richard Yoo 担任 CEO 并得到了外部的财务基金支持,开始专注地经营主机托管业务。

与 NASA 的合作成果 OpenStack 成功后,Rackspace 于 2012 年宣布在自己的云平台上使用 OpenStack 技术,并开源自己的云平台 Rackspace Cloud。

目前,Rackspace 在全球拥有 10 个以上数据中心,管理超过 10 万台服务器,主要提供公有云、私有云、混合云以及云存储等业务。

OpenStack与OpenStack基金会

OpenStack 以 Apache 许可证授权,是一个开放源代码的自由软件项目。

NASA 与 Rackspace 合作时决定 OpenStack 由 Rackspace 管理。为了能像 Linux 那样更好地发展 OpenStack,Rackspace 联合部分成员于 2011 年成立了 OpenStack 基金会,并将 OpenStack 商标及相关社区的管理权交给了 OpenStack 基金会。由于基金会相对独立,这样 OpenStack 能够不受 Rackspace 更多的约束,从而获得更好的发展。OpenStack 基金会中的技术委员负责管理整个 OpenStack 项目的开发管理工作,而核心的开发力量主要来源于基金会中的成员以及分布在全球各个地区的软件人员。

自由软件许可协议Apache 2.0 和GPL

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

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

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

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

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

OpenStack的开放性

OpenStack 的开放性在于,它创造了一个框架标准和 API,用户可以以此为基础构建云计算解决方案,同时这些标准也与市场领导者 AWS 的系统兼容。

另外,由于 OpenStack 支持主流的 kvm、xen、vmdk 等镜像格式,所以客户可以更容易地将云中运行的虚拟机放到企业内部的 IT 环境中运行,而不用担心被云系统技术锁定。

OpenStack的代码质量与安全性

企业在应用 OpenStack 时面临的第一个问题是,OpenStack 可靠、安全吗?

虽然这个问题有更多的含义需要揭示,但由于“开源软件的源代码是公开的,公众可以揭开代码的信息”,因而软件源代码若有质量方面的问题,则更易于被发现并且被修正;软件源代码中无法隐藏安全秘密,安全漏洞易于被更快地发现与修正。

OpenStack在企业的应用模式

OpenStack 是为公共云系统而开发的,非常特别之处在于它提供了浮动 IP 机制,即灵活地使用有限的公网 IP 地址资源,且同时提供了 Flat、FlatDHCP、VLAN、GRE 等多种部署模式以及两种网络架构——nova-network 与 Quantum。

鉴于各类企业所拥有的 IT 资源情况,我们有如下建议。

  • 中小企业考虑以 nova-network 为主的 FlatDHCP 简单部署模式,这种模式需要的设备与人员管理成本最低。当然,如果放大投资,也可以直接考虑以 Quantum 为基础的网络架构。

  • 中大企业建议采用 VLAN 模式,网络组件可选择 nova-network 或 Quantum 模式。如果 IT 资源充足,建议采用 Quantum 网络部署模式,它可以很好地满足公司、部门二级架构。

  • 大型企业建议采用基于 Quantum 的 GRE 模式,它可以很好地满足集团、子公司、部门三级架构。

虽然建议如此,但这只是一个总体上的说明,每个企业在应用 OpenStack 时仍可以根据自己的实际情况灵活选用,比如虽然是中小企业,也可以直接选择基于 Quantum 的 GRE 模式,以获得更多的灵活性,而大型企业选择 nova-network 网络组件同样可以在一定程度上胜任运营要求。

另外一个需要企业考虑的问题是,很多企业只有单一或为数不多的动态或静态的公网 IP 地址,内网也通常采用 NAT 设备与技术访问外网。因此,在企业内建设 OpenStack 时,其为公有云系统准备的浮动 IP 往往会带来更大的复杂性,而单一的固定 IP 更适合用于企业内部管理与应用。

因此,在企业内部署 OpenStack 时,通常要对原有的标准部署模式进行调整,调整成不仅适于企业内部应用,而且能够简化管理与维护工作的模式。

本书特点

本书并不是一个简单的安装指导,也不是简单的官方文档的翻译或翻版,而是在其中包含了更多的信息,比如第 3 章的多点多主机 nova-network 部署,官方文档对这些内容都没有非常全面的讲述。

本书另一个重要的特点是讲了一些重要的、易于读者更好理解 OpenStack 原理的背景知识,特别是第 2 章,更有助于初接触或已经在运用 OpenStack 的人深化网络相关知识。而 OpenStack 适于小中大三类企业的应用模式均做了调整,将 OpenStack 原来针对的公共云部署模式转向企业内私有云应用,这主要是为了简化技术维护与管理工作,更适用于企业内网。

本书的第三个特点是书中的内容均来自于各种 OpenStack 部署实验与实践,通过本书提供的各类实验资料,读者可以很快地拥有灵活运用 OpenStack 的能力,比如第 8 章、第 9 章分别讲述了后端挂接 Nexenta 和 Ceph 的 Cinder 卷存储与基于 NFS、MFS 的虚拟机动态迁移方案,这对很多企业来说是非常有价值的。

当然,因为篇幅的限制,我们并没有完整介绍如何处理 OpenStack 系统控制服务、计算服务、网络服务以及存储服务的冗余处理问题,但我们将 RabbitMQ 部分单独列出来介绍,因为如果 RabbitMQ 服务中断了,那么整个 OpenStack 的控制服务与计算节点的联系会中断,整个云系统需要重启才行。

本书内容

第 1 章简要介绍了 PXE 这种最基本的 OpenStack 的操作系统安装技术。

第 2 章重点介绍了 OpenStack 涉及的网络知识,包括网桥、VLAN、GRE 等重要原理,这些内容对于后期部署 OpenStack 的 nova-network 或 Quantum Open vSwitch 有很大帮助。

第 3 章重点介绍了 OpenStack 的 nova-network 安装模式,让初学者容易了解与认识 OpenStack。这里并不是简单的 nova-network 基本部署,而是 multi_host 多点部署。

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

第 5 章主要以 VLAN 模式为基础介绍了 Quantum 的安装模式,而非官方文档中的 GRE 模式。对于很多不熟悉基本原理与概念的人来说,GRE 更容易让人困惑。

第 6 章介绍了适用于中型企业的经过调整的 nova-network 与 Quantum VLAN 模式,这种模式可以很好地与企业内部两层 VLAN 隔离,并通过三层路由完成全网沟通的网络模式融合,对很多企业有益处。

第 7 章介绍了适用于大型企业的 Quantum GRE 模式,它能充分支持集团、子公司、部门三级组织结构下的大型企业组织架构,并允许集团 IT 部门向子公司 IT 人员授权,允许子公司的 IT 管理人员自由地在子公司的范围内创建与实际物理环境相近的云网络架构。

阅读完前 7 章,许多企业的 OpenStack 开发人员至少已经可以选择一种模式部署企业的云系统了,只是此时虚拟机仍存储在计算节点本地的硬盘上,对于有经验的 VMware 或 Citrix 企业 IT 人员来讲,更希望能将虚拟机存放于中央卷存储系统或中央文件存储系统中,以充分使用企业已有的可靠的中央存储资源。

第 8 章介绍了 OpenStack 的存储服务 Cinder 部件,以及支持 Cinder 部件的后端的单点 iSCSI 存储系统 Nexenta 和分布式卷存储系统 Ceph。

第 9 章介绍了另一个吸引人的话题,即中央存储与虚拟机动态迁移。中央存储除了介绍以 NFS 模式为基础的 Nexenta 结构,还介绍了更为优秀的分布式文件存储系统 MFS。

第 10 章介绍了云服务的开放 EC2 接口,此接口允许外部人员使用标准的客户端工具直接操作云系统,而云管理员只需要控制每个租户的 CPU、内存、网络、存储配额即可。提供了 EC2 接口后,企业的云系统可以接受国际云相关技术人员的操作,这对于跨国的业务来说非常合适。

第 11 章介绍了 OpenStack 的云管理界面 VNC 以及更为优秀的适合虚拟桌面使用的、基于 Spice 协议的服务端与客户端。

第 12 章介绍了如何建立 RabbitMQ 的集群以及多点间镜像消息队列的处理方法,读者可以以此为基础建立起高可靠性与高性能的云消息队列架构。

第 13 章简述了在 G 版中还不成熟的云监控系统 Ceilometer 与自定义创建虚拟机的 HEAT 组件,以及目前还没有进入 OpenStack 核心组件的 Trove。

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

致谢

我从 2012 年 3 月开始学习 OpenStack,当时是按照北京-YZ(董斌)、陈沙克以及上海梁博的博客文章学习安装的,并在学习的过程中得到了他们的帮助。他们无私的分享不知帮助了多少后学者,我对此久久难忘,可能只有拥有这样的胸怀的人才能创建出 LVS 这样由中国人打造的开源软件。

上海 Daniel 对 Quantum+OVS 做了深入测试,并和我交换了经验,这些经验使得很多人在了解 nova-network 能力的同时也加深了对 Quantum 能力的了解。

OpenStack 中国社区(www.openstack.org.cn)与几个技术群的发起者王达夫博士更是对 OpenStack 在中国的应用推广作了很多贡献。程辉与杜玉杰为 OpenStack 在中国的推广作出的贡献也是有目共睹、令人钦佩的。

本书中所有的实验与实践采用的硬件服务器、网络环境均来自于四川省艾普网络股份有限公司,他们是在 2012 年 5 月开始用 OpenStack 系统建设公共云(www.ip66yun.cn)的中国第一家运营商,在此感谢以李嘉总裁为代表的艾普集团领导团队。在中国的电信环境下,他们付出了巨大努力,同时也把握着云业务的未来。

信立讯科技的工程师陈焱帮助我核实与校正了书中的一些细节,并提供了大量关于 MFS 的安装与测试信息。

当然,北京图灵文化发展有限公司也为本书作出了很多努力。

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

OpenStack中国社区技术群

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

  • OpenStack 中国社区部署群:145923072

  • OpenStack 中国社区开发群:202265873

  • OpenStack 中国社区培训群:257479608

  • OpenStack 中国社区综合群:11315737

读者亦可就本书中的某些问题直接与我联系,我将尽可能提供帮助,我的邮箱为 E-mail: zi_fan@21cn.com。

本书参考资料

本书的基础参考资料为 OpenStack 官网的文档(http://docs.openstack.org/),之后不再在各章节中声明。

目录

  • 前言
  • 第 1 章 OpenStack 基本操作系统环境的 PXE 自动部署
  • 第 2 章 OpenStack 与网络
  • 第 3 章 OpenStack nova-network 多主机部署
  • 第 4 章 OpenStack 中小企业应用部署
  • 第 5 章 OpenStack Quantum VLAN 部署模式
  • 第 6 章 满足中型企业的 OpenStack 部署模式
  • 第 7 章 大型企业的 OpenStack GRE 部署模式
  • 第 8 章 OpenStack 卷服务——Cinder
  • 第 9 章 OpenStack 中央存储及虚拟机动态迁移
  • 第 10 章 OpenStack EC2 接口与 Quota 分配
  • 第 11 章 OpenStack Web 管理界面与云虚拟桌面
  • 第 12 章 OpenStack RabbitMQ 冗余处理
  • 第 13 章 OpenStack 的新组件