《OpenStack实战》——1.3 关联OpenStack及其控制的计算资源

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

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和网络类似。

图1-7　OpenStack管理块（虚拟机）存储

图1-7从基础虚拟机资源管理展望的角度展示了其全貌。OpenStack可以管理很多厂商提供的存储解决方案，包括来自Ceph、戴尔（Dell）、EMC、惠普（HP）、IBM和NetApp等厂商的方案。与hypervisor和网络组件一样，OpenStack提供灵活切换存储厂商和技术的能力，并且不需要改变客户端的配置。

2．对象存储
虽然OpenStack不是一个用于块存储（用来启动虚拟机）的存储阵列，但它天生拥有提供对象存储的能力。与在物理硬件上运行Linux的支持版本不同，OpenStack提供分布式对象存储集群时并不需要其他软件。这种存储类型可以用来存放卷备份，也通常用来存放大量可以被分割成二进制对象的数据。图1-8展示了一个基本的对象服务器部署，当然这些都包含在OpenStack环境中。

图1-8　OpenStack提供基于对象的（API）存储

对象存储不是必须在同一地点。事实上，节点（代理节点和存储节点）可以在多个不同的地点，互为冗余。

对象存储传统的用法是存储那些被应用访问的数据，如被用户的应用程序使用的一个文档或文件。在OpenStack环境中，对象存储有几种用法。例如，使用对象存储作为虚拟机镜像的仓库。这样并不是说虚拟机直接使用了这些存储，它们只是通过这个存储系统维护的数据被提供出来。这样做是合理的，因为这个提供过程不需要对随机数据的低延时访问。对象存储还会用来备份一个现有的虚拟机的快照，用于长期保存备份。

1.3.4　OpenStack和云专业术语
OpenStack是一个用来构建云的框架，可以构建公有云和私有云。除了公有云和私有云的定义，还有“即服务”的云定义。OpenStack是什么即服务呢？OpenStack是多个即服务云的基础。

假如你对为自己的企业提供一个类似于AWS供应虚拟机和存储资源感兴趣，那么OpenStack可以认为是基础设施即服务（Infrastructure as a Service，IaaS）。在这种场景下，用户具有提供给个人的直接访问的虚拟机，并由用户直接管理。虽然构成云的物理组件对用户是隐藏的，但是可以直接访问它们。OpenStack的职责是控制为最终用户提供基础设施的资源。

现在假设你的云用户不能对基础设施直接访问，用户只能访问由OpenStack提供和支持的应用编排功能。在这种场景下，OpenStack可以认为是平台即服务（Platform as a Service，PaaS）的后端提供者。底层的物理和虚拟基础设施组件对用户是隐藏的。想象一下这样的场景，一个开发团队需要一个独立的应用环境（应用层部署在IaaS上）来进行软件测试。通过云编排，OpenStack可以用来作为部署测试平台的后端提供者。

现在假设你的公司通过使用OpenStack提供的基础设施即服务（IaaS）或平台即服务（PaaS）为客户提供一种服务。在这种场景下，OpenStack服务作为软件即服务（Software as a Service，SaaS）的后端组件。你可以看到，OpenStack可以用作云计算多个层面的基础组件。

现在你对OpenStack可以做什么和如何做有了更深的理解，是时候介绍OpenStack各个组件是如何工作的了。1.4节将会介绍OpenStack各个独立组件和它们在整个框架中的作用。