作者：[美]V. K. 科迪?布姆加德纳（V. K. Cody Bumgardner）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
OpenStack实战试读：
前言
我首次接触OpenStack是在2011年夏天，那时我就职于肯塔基大学（University of Kentucky）。我和我的同事兼好友Brent Salisbury被邀请参与一家财富50强技术公司关于产品研发项目的讨论。在会议期间，项目的执行发起人给了我们两个选择，使用现有的商业工具或者调研使用一个名为OpenStack的社区项目。自然结果是我们选择了调研我们一无所知的框架，就这样开始了我们的OpenStack之旅。这个开发项目没有任何产品产出，但与OpenStack的“不期而遇”却成为了我学术和职业生涯的转折点。Brent离开了肯塔基大学，与别人合办了一家创业公司，后来该公司被Docker收购了，于是他现在正就职于Docker公司。而我，走了与他不同的道路，从硕士变成博士并写了这本书。
在2013年年初，OpenStack的Grizzly版本跟当前的版本类似，但由于当时功能快速增加导致不稳定，让我们觉得在企业环境里，OpenStack还不能用于生产环境。虽然我没有冒险在企业里使用OpenStack，但研究计算是另一回事。作为研究生独立研究课程，我在研究计算时记录了使用OpenStack的案例、架构和策略。不止这样，我还描述了这个过程，最后在我们企业内部采用这个平台作为私有云。
我在原创的学术报告里使用图1来表示OpenStack在组件层面的分布式体现。我推测要烹饪一头大象，应该跟吃它一样，一次只能一块。在技术领域里，我们经常能接受技术分离作为一个组织的稳健做法——“我是存储人”或者“我是网络人”——但对很多人来说，首要任务就是只吃大象的一部分。在本书中，我会尽量将一些易懂的知识和新概念结合起来，让读者更容易理解。虽然可能你不想品尝大象的脚，但如果想成功地玩转云计算，最好在原理上知道它们是怎样工作的。
现在我写这个前言，刚好是Manning出版社的编辑第一次找我的两年后。当我开始这个项目时，还只有不到500名OpenStack贡献者，但现在已经有好几千名了。OpenStack不但成为了成长最快的开源社区之一，同时也被全球规模靠前的很多组织采用。更重要的是，至少对你来说，OpenStack现在已经足够成熟了，可以作为你的组织的私有云的基础。图1 这幅图来自于16世纪Maestro Martino写的Libro de Arte Coquinaria（关于烹饪艺术的书）致谢
没有我的博士导师兼好友Victor W. Marek教授的鼓励，就没有本书的出版。我有责任把这种鼓励和信心传递下去。
如果不是自己经历过，我无法想象出版一本书需要付出如此多的努力。这份努力是否能产生预期的结果将取决于读者，但毫无疑问，审稿人、编辑和其他贡献者都花费了大量时间来致力于打造一本高质量的书。通过我参与贡献和审阅其他作者的书，以及我现在写的这本书，我可以很肯定地说，Manning出版社为出版更好的书尽了最大的努力。我特别要感谢本书的策划编辑Susan Conant的孜孜不倦的工作，持续推进内容的改进。同时也要感谢出版人Marjan Bace以及编辑与生产团队的每一位成员，包括Mary Piergies、Cynthia Kane、Andy Carroll、Katie Tennant和幕后的所有工作人员。非常感谢Bill Bruns、Andy Hill、Michael Kidd、Jeff Lim和Fabrizio Soppelsa在本书编写期间帮忙做技术审阅。最后，还要感谢Andy Kirsch、Chris Snow、Fernando Rodrigues、Hafizur Rahman、Kosmas Chatzimichalis、Matt Harting、Mayur Patil、Michael Hamrah、Peeyush Maharshi和Toby Lazar，他们阅读本书初稿并提供了很多建议。
特别感谢我的妻子Sarah，感谢她照顾我们的两个孩子，同时理解和支持我出差、做研究生工作、编写这本书和其他各个方面，这些都是无私的。虽然论文、讲稿和书上都只有我的名字，但同样会带上我们共同拥有的姓。Sarah、Sydney和Jack，很抱歉没有花足够多的时间和精力陪伴你们。我希望，就像我以你们为傲一样，你们也以我为傲。我爱你们。关于本书
本书的主题是通过OpenStack来部署企业私有云。在本书中，我把私有云看成是企业内部的基础设施资源池，即基础设施即服务（Infrastructure as a Service，IaaS）。相反，公有云IaaS资源是由第三方服务提供商拥有和运营的。
从财务角度看，可以把私有云看成主要资产成本，而公有云通常是运营成本。很容易区别两者，在私有云部署中，不管实际使用量的大小，企业通常都要购买或者把在其他地方正常工作的基础设施挪过来使用。在公有云部署中，成本通常是跟直接的占用小时（开机或关机）数和通信开销有关。
组织采用私有云还是公有云通常与组织的IT职责的大小和规模有关。企业的IT部门负责为组织其他部门集中提供技术架构和资源，是使用私有云的“既得利益者”。一个多租户、充分编排的私有云为企业IT提供了非常高效的资源管理。在这方面，企业IT部门变成一个“云代理商”。相反，部门的IT单元通常缺乏数据中心设施和部署性价比高的私有云的人员。通常他们只有少量的资源需求，因此部门可以充分利用公有云资源。如果可以，部门也可以充分利用由他们的企业IT单元提供的私有云资源。基于工作负载同时使用私有云和公有云就是混合云架构了。
尽管云和想充分利用云的企业类型不同，但不同的云可以使用相同的技术来构建。虽然构建云资源的要素可以是相同的，但是使用形式和方式可以千变万化。
OpenStack是一个可以用来构建私有云和公有云的强有力的框架。从本质上讲，OpenStack为构建云的硬件和软件而抽象和提供了一组通用的API接口。这个框架提供了两个非常重要的东西：● 硬件和软件资源的抽象，这避免了特定组件的厂商锁定；● 一组通用的资源管理API接口，这可以实现连接的组件的完全编
排。
第一点从财务角度来看是非常好的，第二点是现代IT变革的关键。对于企业IT部门来说，OpenStack为云部署带来了相同水平的高效变革。为什么选这本书
本书希望通过一步步、自底向上的方式，为构建计算资源云提供指导。本书的目标读者包括打算部署OpenStack环境的研究人员、系统管理员和学生。阅读本书不需要有很好的技术基础，只要了解Linux的基本操作，本书的内容适合不同背景和技术能力的人群。同样，OpenStack适用于多种用例。
尽管不同的用例都使用相同的OpenStack框架，但不同服务提供商的私有云的要求和设计会有很大区别。企业都希望为企业内部提供私有资源云。这种类型的私有云不只是代表了一种额外的服务，更是代表了组织提供计算资源方式的一个转变。
本书由以下几部分组成：● 介绍自动化部署OpenStack单节点开发环境；● 通过一步步手动部署多节点环境来深入理解OpenStack；● 从IT运维角度来介绍私有云技术（OpenStack、Ceph、Juju等）
带来的影响；● 使用厂商提供的自动化部署和管理工具来部署生产级别的
OpenStack环境。
本书介绍的架构适合于从小规模（5个节点）到大规模（100个节点）企业的私有云部署。另外，第12章还会介绍如何在新构建的私有云上使用应用编排工具，如OpenStack Heat和Ubuntu Juju。
本书会让读者理解私有云技术、这些技术的部署和运维，以及云编排对传统IT角色的长期影响。本书会帮助读者更好地说服企业在其内部部署OpenStack私有云，同时帮助读者提高私有云方面的技能。本书的配置和操作脚本可以到GitHub下载：https://github.com/codybum/OpenStackInAction。
对读者而言，需要理解的最重要的一点是，OpenStack私有云不是另一种简单的虚拟化工具。OpenStack是充分利用现有的虚拟化工具来构建和管理云的框架。读者将会学到如何构建、部署和管理云。从技术层面来看，读者将会理解OpenStack各个组件和支持技术，特别是OpenStack计算、网络、块存储、Dashboard和API组件。内容路线图
本书划分为3个部分，第一部分（第1章～第4章）是入门指南，第二部分（第5章～第8章）深入介绍整个生态系统，第三部分（第9章～第12章）介绍在生产环境中如何使用OpenStack。
第1章介绍OpenStack云操作系统、开发这个框架的动机和OpenStack能为你的组织做些什么。
第2章将直接通过一个快速部署工具和最小化的基础设施来快速体验OpenStack。这个体验不只是演示OpenStack Dashboard的使用，还提供一个学习OpenStack框架时可以运行的模型。在第2章结尾，读者可以通过自己的OpenStack环境来创建虚拟机。
第3章会使用第2章构建的环境，介绍OpenStack命令行工具（CLI）。这一章介绍OpenStack的基本操作，如创建新租户（项目）、用户、角色和内部网络等。
第4章中，通过使用OpenStack来理解组件的功能和整个OpenStack框架里各个组件之间的交互。读者可以学到多种云设计方法，让自己可以准备自己的多节点部署。这一章还会介绍OpenStack组件是如何协同工作的，以及它们与厂商资源的关系。
第5章～第8章，每章分别深入介绍OpenStack的一个核心项目。这几章会带领读者进行多节点环境下的OpenStack手动部署。通过这几章，读者将会更好地理解在OpenStack生态里面它们是如何工作的。另外，这些手动部署工作将会带给读者宝贵的问题排查经验。
第9章介绍与生产环境中OpenStack部署相关的架构、组织和策略决策。第10章介绍Ceph存储的基本部署和操作。第11章会使用Fuel来进行OpenStack自动化高可用（HA）部署。最后，第12章会介绍通过OpenStack Heat和Ubuntu Juju进行云编排。谁应该读这本书
本书适合对使用OpenStack来构建私有云环境有兴趣的基础设施专家、工程师、架构师和技术支持人员阅读。本书对身为领导者和战略角色的人有一定的战略价值，其内容同时也适合技术型读者。阅读本书不需要有很好的技术基础，只要了解Linux的基本操作就可以。代码约定和下载
本书所有的代码都会用等宽字体与其他文本内容加以区分。代码注释伴随在很多代码清单中，突出重要的概念。在一些例子中，数字编号链接到代码清单后面的解释。
读者可以在Manning出版社的网站www.manning.com/books/openstack-in-action 和 https:// github.com/codybum/OpenStackInAction下载本书的示例代码。作者在线
本书包含一个可以免费访问的由Manning出版社运营的私有网络论坛，读者可以在这里发表对本书的评论，询问技术类问题，可以得到作者或者其他读者的帮助。可以通过www.manning.com/books/openstack-in-action访问这个论坛。这个网页提供了注册后如何访问这个论坛，可以获得哪些帮助，以及在论坛发表文字的规则。
Manning出版社为读者与读者之间、读者和作者之间的沟通提供了场所。但由于作者参与论坛讨论和解答问题是完全自愿的（无偿的），因此作者对在论坛解答读者问题不作任何承诺。我们建议读者向作者提出有挑战性的问题来激发作者的兴趣！当本书正式出版时，作者在线论坛和前面提到的文档都可以通过出版社网站访问。关于作者
Cody Bumgardner（http://codybum.com）有超过20年的IT行业的从业经验，在IT架构、软件开发、网络、研究、系统和安全领域扮演过技术、管理和销售角色。最近几年，作者主要专注于研究、实现和介绍云计算和计算经济学。他现在还是肯塔基大学计算机科学的博士生，专注于计算经济学和分布式资源管理。Cody现在还是一家公立大学的首席技术架构师（CTA）。作者作为首席技术架构师为就职的学校制定了一个5年的云计算战略和路线图。这个路线图概述了颠覆性的云技术，并给出了全体IT人员的相关转变。这个计划以企业OpenStack私有云部署为核心，支持超过4万个包括学术、研究和医疗卫生（学术）方面的用户。Cody主要负责OpenStack私有云、计算研究和云计算其他前沿技术的架构、账务建模、部署和长期战略规划。关于封面
本书封面上的图像的说明文字是“一位来自库唐斯的挤奶女工”。这张插图取自经Louis Curmer编辑并于1841年在巴黎出版的很多艺术家的作品汇集而成的作品集。这个作品集的名字是Les Français peints par eux-mêmes，翻译出来意思是“法国人眼中的自己”。每一幅图集都是精工细作并手工着色的，这些丰富多样的图集形象生动地提醒着，200多年前的文化是如何分隔在世界不同地区、城镇、乡村和居民区的。人与人之间相互独立，说着不一样的方言和语言。站在大街或者乡村小道上，从衣着打扮就很容易分清他们住在哪里、卖些什么、处于什么样的地位。
那时如此多元化的区域差异逐渐消失了，而从那时起衣服着装也开始变化。现在不同州的居民都很难辨认出来，更别说不同城镇和地区的了。也许我们以文化多元化换得了一个更加丰富多彩的个人生活，当然也是一个更加多变、快节奏的科技生活。
在一个科技类图书众多的时代，Manning以印有两个世纪以前丰富多样的地区生活的图书封面赞颂了计算机事业的创新性和自主精神，这些插图又将创新性和自主精神重新带回到我们的生活。第一部分 入门指南
本书的第一部分是对OpenStack框架的介绍：为什么要使用它和如何使用它。剖析OpenStack各个组件，解释它们与底层资源（计算、存储、网络等）的关系。这一部分将会带领你在单个节点上通过DevStack部署工具来部署OpenStack。同时这一部分内容还会帮你思考如何能将OpenStack用在你的环境中，并激发你对这个框架的兴趣，继续探索本书后面的部分，更深入地了解它是如何运作的。第1章 介绍OpenStack
本章主要内容● OpenStack和云生态系统● 选择OpenStack的理由● OpenStack可以为你和你的组织做些什么● OpenStack的核心组件
一二十年前，很多大型的计算机硬件公司都通过自己生产制造专门的处理器来保持竞争优势。但随着成本的上升，能制造出足够数量的芯片来保持盈利的公司越来越少。于是，专门生产芯片的厂商出现了，它们可以大规模生产通用处理器，并且大大降低了成本。从一开始的只有少数计算机芯片厂商“鼓吹”的基于英特尔x86指令集的标准化台式机和服务器平台，到最后形成了采用通用硬件的客户-服务器的市场格局。
在21世纪初的互联网风潮下，互联网快速发展，从而出现了大量大规模使用通用硬件的数据中心。虽然通用硬件设备强大且便宜，但它的架构就跟我们看到的台式机一样，不是按中心化管理的思想来设计的。没有现成的工具可以用来像管理资源池一样管理这些通用硬件设备。更糟糕的是，在那时，这些服务器缺少硬件管理的能力（辅助管理卡），看起来跟台式机一样。不像大型机和大型对称多处理结构（symmetric multiprocessing，SMP）的机器，这些通用服务器跟台式机一样，需要通过软件管理层来协调其他独立的资源。
在这个阶段，公共或者私有的组织在自己内部开发出很多管理框架来管理公共资源。图1-1展示了跨越多个数据中心的相互连接的资源池。通过管理框架，这些公共资源可以基于其可用性或者用户需求来灵活使用。不知道谁创造了这个术语，这种通过管理框架来灵活使用通用硬件设备的计算方式，可以说是拥有了资源“云”。图1-1 彼此互联的通用资源的云
在这个阶段，在很多商用或者开源的云管理软件之中，OpenStack是最为流行的一个。OpenStack提供了一个通用的平台来控制云计算里面的服务器（计算）、存储、网络，甚至应用资源。OpenStack可以通过基于Web的界面、命令行工具（CLI）和应用程序接口（API）来进行管理。这个管理平台不仅能管理这些资源，更妙的是它不需要你去选择特定硬件或者软件厂商。厂商特定组件可以轻松地被替换成通用组件，OpenStack为IT业界各类从业人员创造了价值。
一种更好理解OpenStack的方式是了解在亚马逊网站上购物的过程。用户登录亚马逊网站，然后购物，商品将会通过快递派送。在这种场景之下，一个高度优化的编排步骤是尽可能快并且以尽可能低的价格把商品买回家里。亚马逊成立12年后推出AWS（Amazon Web Services）。AWS把用户在亚马逊网站购买商品这种做法应用到了计算资源的交付上。一个服务器请求可能要花费本地IT部门几周的时间去准备，但在AWS上只需要准备好信用卡，然后点击几下鼠标即可完成。OpenStack的目标就是提供像AWS或者其他服务提供商一样水准的高效资源编排服务。
OpenStack是什么？● 对于云计算平台/系统/存储/网络管理员来说，OpenStack可以控
制多种类型的商业或者开源的软硬件，提供了位于各种厂商特定
资源之上的云计算资源管理层。磁盘和网络配置这些重复性手动
操作任务现在可以通过OpenStack框架来进行自动化管理。事实
上，提供虚拟机甚至上层应用的整个流程都可以通过使用
OpenStack框架进行自动化管理。● 对于开发者来说，OpenStack是一个在开发环境中可以像AWS一
样获得资源（虚拟机、存储等）的平台，还是一个可以基于应用
模板来部署可扩展应用的云编排平台。可以想象一下，通过
OpenStack框架，可以为应用提供基础设施（X虚拟服务器有Y容
量内存）和相应的软件依赖（MySQL、Apache2等）资源。● 对于最终用户来说，OpenStack是一个提供自助服务的基础设施
和应用管理系统。用户可以做各种事情，从简单的像AWS一样
提供虚拟机（VM），到构建高级虚拟网络和应用，这些都可以
在一个独立的租户（项目）内完成。租户，也就是我们所说的项
目，是OpenStack用来对资源分配进行隔离的方式。租户隔离了
存储、网络和虚拟机这些资源，因此，最终用户可以拥有比传统
虚拟服务环境更大的自由度。可以想象一下，最终用户被分配了
一定额度的资源，他们可以随时获得他们想要的资源。虚拟机和租户在本书中，虚拟机指的是模拟物理服务器的一个实例。与物理机一样，虚拟机执行相同的功能，从操作系统的角度来看，无法区分是运行在虚拟机还是物理机上。导致虚拟机被使用的原因多种多样，但大多数的虚拟化推动力可以归结为：以牺牲性能来获得通过软件对资源的灵活控制。从一个更高的角度来说，你可以认为OpenStack之于数据中心，就像操作系统之于服务器，都带来了相同水平的运行效率。读者将在本书多处看到租户这个词，在OpenStack里面这个词有特定含义。我们可以认为租户就是资源的配额限制集合，被虚拟机用来在逻辑上与不同租户互相隔离。例如，一个用户在租户A配错了网络，但租户B并不会受到影响。
OpenStack基金会拥有数以百计的官方企业赞助商，以及数以万计的覆盖130多个国家或地区的开发者组成的社区。像Linux一样，很多人将会被OpenStack吸引，作为其他商业产品的一个开源的替代品。但他们将会逐渐认识到，对于云框架来说，没有哪个云框架拥有OpenStack这样的服务深度和广度。也许更为重要的是，没有其他产品，包括商业或者非商业的，能被大多数的系统管理员、开发者或者架构师使用并为他们组织创造这么大的价值。1.1 OpenStack是什么
让我们来详述OpenStack作为管理、规定和利用云资源的框架的定义。OpenStack官方网站（www.openstack.org）这样描述这个框架：“创建私有云和公有云的开源软件。”接着是：“OpenStack软件是一个大规模云操作系统。”如果读者有服务器虚拟化的经验，也许读者会很快地得出这样不正确的结论：OpenStack只是提供虚拟机的另外一种方式。虽然虚拟机是OpenStack框架可以提供的一种服务，但这并不意味着虚拟机是OpenStack的全部。
图1-2展示了OpenStack通过其几个资源组件协调来提供公有云服务和私有云服务。如图所示，OpenStack没有取代资源提供者，它只是通过框架内部的控制点来简单地管理这些资源。图1-2 OpenStack是一个云操作系统
一个有经验的系统管理员也许会非常怀疑OpenStack是一个“云操作系统”的描述。OpenStack不像管理员通过启动盘引导启动几百台传统操作系统服务器那样，直接在裸设备上引导启动。相反，它通过对资源的管理，在云计算环境里共享操作系统的特性。
在OpenStack云平台上用户可以：● 充分利用物理服务器、虚拟服务器、网络和存储系统资源；● 通过租户、配额和用户角色高效管理云资源；● 提供一个对底层实现透明的通用的资源控制接口。
乍看之下，OpenStack确实不像是一个传统操作系统，但“云”同样不像传统计算机。我们必须回过头来重新考虑一个操作系统的根本作用。
最初，操作系统乃至硬件层面抽象语言（汇编语言）、程序都是用二进制机器码来编写的。然后传统操作系统出现了，允许用户不仅可以编写应用程序代码，还可以管理硬件功能。现在管理员可以使用通用的接口管理硬件实例，开发者可以为通用操作系统写代码，用户只需要学习一个用户交互接口即可。这样可有效地对底层硬件透明化，只需要操作系统是一样的。在计算机进化演变过程中，操作系统的发展和新操作系统的出现，给系统工程和管理领域带来了风险。
图1-3展示了现代计算系统的各个抽象的层次。图1-3 计算抽象的层次
毫无疑问，过去的一些开发者不想因为使用操作系统而失去了对硬件的直接控制，正如有些管理员不想因为服务器虚拟化而失去对底层硬件和操作系统的控制。在每次转变过程中，从机器码到汇编，再到虚拟层，我们一直没有失去对底层的控制；每次都是通过抽象手段简单标准化而已。我们仍然拥有高度优化的硬件，我们仍然拥有操作系统，只不过更常见的是我们拥有这些层面之间的硬件虚拟化层。
新的抽象层被广泛接受，通常是因为对标准实现优化的好处大于在这些层面上做（虚拟化）转换。也就是说，当整体计算资源的使用率能通过牺牲原生性能来得到很好的提升，那这一个层面的抽象就会被接受。这个现象可以通过中央处理器（CPU）的例子来清晰展现，这几十年，中央处理器都遵守相同的指令集，但它们内部的架构却发生了翻天覆地的变化。
大多数人想到中央处理器时，都没想到硬件层面的虚拟化和执行形式的变化，但事实就是这样。很多在x86处理器上执行的指令可以被处理器内部虚拟化，一些复杂的指令可以通过一系列更简单、更快速的指令来执行。指令层面优化的复杂度不在本书的讨论范围内，但很有必要去了解，即使是使用裸设备，即使是在处理器层面，也是应用到了某种形式的虚拟化。现在，与其关注失去了控制，不如想象一下，通过使用一个共同的框架来管理、监控和部署基础设施和应用的私有和公有云。只有向前迈出转变的步伐，才会真正领会OpenStack。数十年间CPU的抽象和虚拟化英特尔的x86指令集首次出现在1978年推出的英特尔8086处理器上，作为英特尔8080处理器的向后兼容替代品。x86指令集定义了一系列对处理器变化透明的汇编指令。从那以后，新的“处理器扩展特性”不断被添加进来，处理器时钟周期也不断提升，但已存在的指令依旧保留下来。随着更快的处理器需求的增长，因此产生了软件能在不同代处理器之间互操作的需求。CPU设计者需要对低级别抽象进行弹性优化，同时还要保留指令级别的兼容性（标准化）。设计者不用担心关于如何保持底层硬件一致的问题，这样他们可以在不同代处理器间极大地提升处理器的时钟速度。1995年，英特尔的奔腾Pro（Pentium Pro）处理器引入了微操作解码（micro-op decoding）这个概念。之前一个特定指令就是一个指令时钟周期，通过翻译这个指令为多个简单微指令，每个微指令就是一个指令时钟周期。除了微操作，奔腾Pro处理器还引入了指令的无序执行和内存的虚拟化（通过32位总线对36位内存进行寻址）来对处理器进行优化。但这些对开发者来说是完全抽象化的，允许相同的应用运行在不同厂商出品的不同代的处理器上。这种保持指令级别兼容性的方式依然使用在当前的x86_64处理器中。1.2 理解云计算和OpenStack
本书主要关注如何通过使用OpenStack来部署企业私有云。同时，我会把私有云描绘成其所在的组织内部拥有和管理的基础设施（虚拟机、存储等）资源池，也就是我们所说的基础设施即服务（Infrastructure as a Service，IaaS）。相反，公有云IaaS资源由第三方服务提供商拥有和运营，如亚马逊的AWS、微软的Azure等。本书的目标是帮你把公有云服务的简单和高效带到你的企业。经济考量：私有云与公有云从财务角度看，我们可以把私有云看成主要资本支出，公有云则是运营支出。这个区别很容易理解，在私有云部署时，你的组织要购买基础设施或者把在其他地方正常工作的基础设施挪过来使用。而在公有云中，成本直接与资源使用挂钩（使用才付费，不使用不付费），当然还有网络通信开销。
组织选择私有云还是公有云通常取决于使用资源的规模和组织内部IT部门的职责范围。企业IT部门的职责如果是集中为其他部门提供技术架构和资源供给，部署私有云更有利。一个多租户（数据、配置和用户管理在逻辑上是租户间隔离的）、完全实现编排的私有云可以让企业IT部门成为私有云代理。多租户和完全编排多租户指的是在云平台中以部门级别管理计算资源的能力。例如，一个市场营销部门可以分配一定比例的共享资源（X台虚拟机、Y容量的存储等），这个部门可以随意使用这些资源而不影响中心组织（回顾一下亚马逊购买模型）。同样，完全编排描述了应用程序依赖资源的分配能力。例如，一个会计应用程序和它的Web服务、数据库服务等依赖可以被程序化部署在一个环境里。因此，市场营销部门不只能在一个特定租户内管理它的资源，还能通过平台编排服务来部署基础设施（虚拟机）和应用程序（MySQL、Apache2、定制的应用程序等）。
相比之下，如果是部门中的IT单位，通常缺乏数据中心基础设施和部署高性价比的私有云的人员。由于他们相对小的资源需求，部门中的IT单位通常可以利用公有云资源，或者利用他们企业的IT部门提供的私有云资源。
如果基于工作负载同时使用私有云和公有云，那么这种结合使用称为混合云。公有云和私有云都是使用相同的技术来构建，不过虽然构建组件可能一样，但使用私有云和公有云的动机可能完全不同。例如，用户经常因为安全合规性原因而使用私有云。通常来说，下列这些工作负载会使用公有云：本质上是周期性的工作负载，或者需要一个对企业来说非常昂贵的全局规模的工作负载。
虽然本书主要介绍如何使用OpenStack构建私有云，但也有很多内容是介绍如何基于OpenStack的API来直接转换成公有云提供商的服务。抽象和OpenStack API
从根本上讲，OpenStack抽象和提供了一个通用的API接口来控制不同厂商提供的硬件和软件资源。这个框架提供了两个很重要的内容。● 硬件和软件的抽象，这样避免了所有特定组件的厂商锁定问题。
这是通过使用OpenStack管理资源来实现的，而不是直接通过厂
商组件。这样做的缺点是除了通用的必要功能外，并不是所有的
厂商功能都被OpenStack支持。● 一个通用的API管理所有资源，允许连接各个组件进行完全编排
服务。
第一点从财务角度来看是非常好的，第二点则是现代IT变革的关键。这有什么内幕呢OpenStack提供了可伸缩和被抽象的底层硬件的各种功能的支持。OpenStack（或者其他云框架）不能做到的是主动顺应你当前的技术实践。为了充分利用云计算的能力，你必须对当前的业务和架构实践进行相应的转变。如果你的架构标准是基于使用厂商提供的适当功能来对数据中心所有服务器实现某些功能，这样会与对厂商抽象的云部署冲突。如果你的业务实践只是按用户需求创建虚拟机，那你就没有抓住云自助服务的本质。如果最终用户的请求可以被高效自动化执行，或者用户可以自我供给资源，那你就是充分利用了云计算的能力。
1.3节将把OpenStack与其他相应技术（也许是你熟悉的）关联起来。1.3 关联OpenStack及其控制的计算资源
前面介绍了OpenStack能带来的好处，但它是如何工作的呢？也许，理解OpenStack是怎样工作的最简单的方式是把这个框架与企业环境内的常见技术关联起来。
在本节中，读者将会了解OpenStack是如何与它控制的基础资源（计算、存储、网络等）关联起来的。如你所见，OpenStack通常不提供实际意义上的资源，它只是简单控制这些低层次的资源。图1-4展示了OpenStack是如何管理资源的提供者的，它们轮流被虚拟机使用。图1-4 OpenStack资源管理模型
在接下来的小节里，读者将会看到关联特定资源组件的详情：服务器虚拟化，通过对hypervisor（虚拟机管理器）的控制；网络，通过对厂商提供的硬件和OpenStack服务的控制；块和对象存储，通过对厂商和OpenStack服务的控制。最后，我们会看到Openstack各个服务和常见的云术语的关联。如你所见，OpenStack是一个协调资源和服务的框架，而不关心有哪家底层技术厂商。1.3.1 OpenStack和hypervisor
hypervisor或者虚拟机监控器（Virtual Machine Monitor，VMM）是一种为虚拟机进行物理硬件仿真的管理软件。OpenStack不是一个hypervisor，但它确实控制着hypervisor的操作。OpenStack框架支持多种hypervisor，包括XenServer/XCP、KVM、QEMU、LXC、ESXi、Hyper-V、BareMetal和其他（可通过下列网址查看hypervisor的支持列表：https://wiki.openstack.org/wiki/HypervisorSupportMatrix）。读者可能对VMware ESX、VMware ESXi和Microsoft Hyper-V比较熟悉，因为这些是当前企业虚拟化市场主流的hypervisor。因为许可限制、成本和其他因素，OpenStack社区对这些商业hypervisor的支持要少于开源的hypervisor。
图1-5展示了OpenStack如何管理物理硬件上被hypervisor虚拟化的资源。在一个OpenStack集群内，OpenStack协调多个hypervisor资源和虚拟机的管理。图1-5 OpenStack管理着hypervisor
无论部署规模多大，大多数的个人和组织采用的hypervisor是XenServer或者KVM，它们也是支持最多功能的hypervisor。XenServer是思杰（Citrix）公司的产品，从严格意义上来说，它是开源的hypervisor，但商业支持通过思杰公司提供。KVM已经是Linux内核的一部分，因此，很多Linux发行版的维护者提供KVM的商业支持，包括红帽（Red Hat）、Ubuntu、SUSE等。你通过认证了吗 随着大量提供商开始设计基于OpenStack框架的公有IaaS服务，他们很快意识到自己的客户可能需要微软对运行在Windows主机上的hypervisor进行认证。当时，思杰公司的XenServer已经满足了认证条件，并通过了微软的认证过程。但是，尽管思杰公司有一个以CloudStack形式竞争的平台，很多组织还是使用了XenServer作为他们的OpenStack hypervisor。自从很多Linux发行厂商通过了微软的认证以后，现在可以完全支持Windows运行在KVM hypervisor上，包括那些被OpenStack控制的hypervisor上。
本书将采用基于内核的虚拟机（Kernel-based Virtual Machine，KVM）作为hypervisor。自2007年发布的Linux 2.6.20开始，KVM被并进Linux内核，完全被OpenStack支持。KVM还提供了半虚拟化，但需要操作系统原生支持，或者通过在虚拟操作系统镜像添加hypervisor特定驱动来进行支持。使用开源的hypervisor的传统问题是部署和维护它的学习曲线陡峭，经常需要拥有系统、网络和应用管理经验。幸运的是，在组织内部提供集中化支持的虚拟化资源，资源申请必须通过组织的网络、系统、安全和财务供给流程。通常用户有以下3种选择。● 使用社区代码，自给自足——社区维护的软件使用社区的支
持，自己负责部署的设计、开发和运维。● 使用社区代码，商业支持——社区维护软件使用厂商支持，你
和厂商或者只是厂商负责部署。● 使用社区项目的厂商分支，商业支持——使用厂商提供的软件
和支持，你通常只需要负责部署关联的运维和厂商管理。
虽然很多厂商提供OpenStack和KVM的商业支持，但很多为工作负载构建的内部云不需要商业支持或者认证，因此，用OpenStack支持没有购买商业支持的KVM也是很流行的做法。无论你如何部署和采用哪种支持方式，本书提供的材料都一样有用。Linux容器 最近，一些人对操作系统级别的虚拟化应用产生了浓厚的兴趣，而不是OpenStack实例提供的基础设施级别的虚拟化。操作系统级别的虚拟化可以在单一服务器上运行多个相互隔离的操作系统实例（容器）。但它不是hypervisor技术——它运行在系统级别，所有容器共享相同的内核。你可以把容器想象成在需要的地方提供虚拟的隔离，而没有全虚拟化的模拟开销。 目前最流行的两个操作系统级别的虚拟化项目是Docker（https://www.docker.com/）和Rocket（https://github.com/coreos/rkt）。 虽然容器是否比基础设施级别实例更适用于应用程序运行时传递还存在争议，但毫无疑问的是，基于容器的技术将会在构建云时广泛采用。1.3.2 OpenStack和网络服务
OpenStack不是一个虚拟交换机，但它确实管理多个物理、虚拟的网络设备和虚拟覆盖网络（overlay network）。不像OpenStack控制虚拟机控制器那样受限于hypervisor提供的服务，OpenStack直接提供网络服务，如DHCP、路由等。但与hypervisor管理类似，OpenStack对底层厂商技术透明，可以是商业或者开源的技术。
更重要的是，后端技术的改变，如从一种网络/厂商切换到另一种网络/厂商，并不需要客户端配置进行改动。对于涉及网络的大量专有的硬件、软件和用户接口，经常从一个厂商或者技术转换到另一个并非易事。通过OpenStack，这些接口都被OpenStack API抽象化了，如图1-6所示。图1-6 OpenStack管理网络
OpenStack可以管理多种类型的网络技术（实现机制），包括由Arista Networks、Cisco Nexus、Linux bridging和Open vSwitch（OVS）等提供的技术。在本书中，我们将使用OpenStack和OVS提供的网络服务。OVS是OpenStack部署中常被选择的一种，用户可以简单地在自己的环境里获得和复制，不需要特定硬件环境。除了网络实现机制，还有很多被OpenStack支持的网络类型（VLAN和各种隧道技术等），这些内容将会在第6章中详细介绍。1.3.3 OpenStack和存储
OpenStack不是一个存储阵列，至少应该不是你通常认为的存储那种形式。OpenStack没有从物理上提供被虚拟机使用的存储。
如果你曾经使用过文件共享（NFS和CIFS等），就会用过“基于文件”的存储。这种存储的类型很容易被人使用和被计算机访问，但它通常是另外一种存储类型的抽象：块存储。你可以认为操作系统或者文件系统是块存储的主要用户。
还有另外一种系统管理员可能不熟悉的存储类型：基于对象的存储。这种类型的存储通常是通过软件API（如GET /obj=xxx）接口进行访问。基于对象的存储是文件或块存储的更高层面的抽象，但没有后两者的限制。基于对象的存储可以很容易地在多个参与节点之间进行分布和复制。不像块存储那样需要被虚拟机快速访问，分布式的对象存储允许更大的延迟，将不能用作虚拟机的卷（volume，挂载到一个实例上的块设备）。通常做法是在创建时就指明使用对象存储来存放卷和镜像（包含操作系统）的备份。
下面首先介绍OpenStack是如何管理块存储的，然后介绍对象存储的相关内容。1．块存储
OpenStack现在没有为最终用户管理基于文件的存储。由图1-7可以看出，OpenStack管理块（虚拟机）存储与管理hypervisor和网络类似。
试读结束[说明：试读内容隐藏了图片]