510      技术社区[云栖]

《OpenStack实战》——第1章 介绍OpenStack 1.1OpenStack是什么

本节书摘来自异步社区《OpenStack实战》一书中的第1章，第1.1节，作者： 【美】V. K. Cody Bumgardner（V. K. 科迪•布姆加德纳）着，更多章节内容可以访问云栖社区“异步社区”公众号查看

第一部分 入门指南

本书的第一部分是对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处理器中。

最后更新：2017-05-31 17:31:30

  上一篇：  《OpenStack实战》——1.2　理解云计算和OpenStack

  下一篇：  《Docker容器：利用Kubernetes、Flannel、Cockpit和Atomic构建和部署》——导读