1.4 OpenStack的架构

在学习OpenStack的部署和运维之前，我们应当熟悉其架构和运行机制。OpenStack作为一个开源、可扩展、富有弹性的云操作系统，其架构设计主要参考了亚马逊的AWS云计算产品，通过模块的划分和模块间的功能协作，设计的基本原则如下。

（1）按照不同的功能和通用性划分不同的项目，拆分子系统。

（2）按照逻辑计划、规范子系统之间的通信。

（3）通过分层设计整个系统架构。

（4）不同功能子系统间提供统一的API接口。

1.4.1 OpenStack的概念架构

OpenStack的概念架构（Concept Architecture）如图1-7所示。此图展示了OpenStack云平台各模块（仅给出主要服务）协同工作的机制和流程。

OpenStack通过一组相关的服务提供一个基础设施即服务（IaaS）的解决方案。这些服务以虚拟机为中心。虚拟机主要是由Nova、Glance、Cinder和Neutron 4个核心模块进行交互的结果。Nova为虚拟机提供计算资源，包括vCPU、内存等。Glance为虚拟机提供镜像服务，安装操作传统的运行环境。Cinder提供存储资源，类似传统计算机的磁盘或卷。Neutron为虚拟机提供网络配置，以及访问云平台的网络通道。

云平台用户（开发者与运维人员，甚至包括其他OpenStack组件）在经Keystone服务认证授权后，通过Horizon或REST API模式创建虚拟机服务。创建过程包括利用Nova服务创建虚拟机实例，虚拟机实例采用Glance提供的镜像服务，然后使用Neutron为新建的虚拟机分配IP地址，并将其纳入虚拟网络中，之后再通过Cinder创建的卷为虚拟机挂载存储块。整个过程都在Ceilometer模块的资源监控下，Cinder 产生的卷（Volume）和 Glance 提供的镜像（Image）可以通过 Swift 的对象存储机制进行保存。

Horizon、Ceilometer、Keystone 提供访问、监控、身份认证（权限）功能，Swift 提供对象存储功能，Heat实现应用系统的自动化部署，Trove用于部署和管理各种数据库，Sahara提供大数据处理框架，而Ironic提供裸金属云服务。

云平台用户通过nova-api等来与其他OpenStack服务交互，而这些OpenStack服务守护进程通过消息总线（动作）和数据库（信息）来执行API请求。

消息队列为所有守护进程提供一个中心的消息机制，消息的发送者和接收者相互交换任务或数据进行通信，协同完成各种云平台功能。消息队列将各个服务进程解耦，所有进程可以任意分布式部署，协同工作在一起。目前RabbitMQ是默认的消息队列实现技术。

SQL 数据库保存了云平台大多数创建和运行时的状态，包括可用的虚拟机实例类型，正在使用的实例、可用的网络和项目等。理论上，OpenStack可以使用任一支持SQL-Alchemy的数据库。

1.4.2 OpenStack的逻辑架构

要设计、部署和配置OpenStack，管理员必须理解其逻辑架构（Logical Architecture）。图1-8所示的逻辑架构描述的是OpenStack服务各个组成部分以及各组件之间的逻辑关系（仅列出最通用的服务和组件）。

OpenStack包括若干称为OpenStack服务的独立组件。所有服务均可通过一个公共的身份服务进行身份验证。除了那些需要管理权限的命令，每个服务之间均可通过公共API进行交互。

每个 OpenStack 服务又由若干组件组成，包含多个进程。所有的服务至少有一个 API 进程，用于侦听 API 请求，对这些请求进行预处理，并将它们传送到该服务的其他组件。除了认证服务，实际工作是由具体的进程完成的。

至于一个服务的进程之间的通信，则使用AMQP消息代理。服务的状态存储在数据库中。部署和配置OpenStack云时，可以从几种消息代理和数据库解决方案中进行选择，如RabbitMQ、MySQL、MariaDB和SQLite。

用户访问OpenStack有多种方法，可以通过由Horizon仪表板服务实现的基于Web的用户界面，也可以通过命令行客户端，或者通过浏览器插件或curl发送API请求。对于应用程序来说，可以使用多种软件开发工具包（Software Development Kit,SDK）。所有这些访问方法最终都要将REST API调用发送给各种不同的OpenStack服务。

在实际的部署方案中，各个组件可以部署到不同的物理节点上。OpenStack本身是一个分布式系统，不仅各个服务可以分布部署，服务中的组件也可以分布部署。这种分布式特性让OpenStack具备极大的灵活性、伸缩性和高可用性。当然，从另一个角度来看，这一特性也使OpenStack比一般系统复杂，学习难度也更大。

1.4.3 OpenStack组件之间的通信关系

OpenStack组件之间的通信关系，可分为以下4种类型。

1.基于AMQP

基于AMQP（Advanced Message Queuing Protocol，高级消息队列协议）进行的通信，主要是每个项目内部各个组件之间的通信，如 Nova 的 nova-compute 与 nova-scheduler 之间，Cinder 的cinder-scheduler 和cinder-volume之间。

虽然通过AMQP进行通信的大部分组件属于同一个项目，但是并不要求它们都安装在同一个节点上，这就大大方便了系统的水平（横向）扩展。管理员可以对其中的各个组件分别按照其负载进行水平扩展，使用不同数量的主机节点承载这些服务。

2.基于SQL的通信

通过数据库连接实现的通信大多用于各个项目内部，也不要求数据库和项目中的其他组件安装在同一节点上，可以分开安装，也可以专门部署数据库服务器，通过基于SQL的连接进行通信。

3.基于HTTP进行通信

通过各项目的API建立的通信关系基本都属于这一类，这些API都是RESTful Web API。最常见的就是通过Horizon仪表板或者命令行接口对各组件进行操作时产生的这种通信，然后就是各组件通过 Keystone 对用户身份进行认证时使用的这种通信。还有一些基于 HTTP 进行通信的情形，如nova-compute在获取镜像时对Glance API的调用、Swift数据的读写等。

4.通过Native API实现通信

这是OpenStack各组件和第三方软硬件之间的通信方式。例如，Cinder与存储后端之间的通信， Neutron的代理（即插件）与网络设备之间的通信，都需要调用第三方的设备或第三方软件的API，这些API被称为Native API，这些通信是基于第三方API的。

1.4.4 OpenStack的物理架构

OpenStack是分布式系统，必须从逻辑架构映射到具体的物理架构，将各个项目和组件以一定的方式安装到实际的服务器节点，部署到实际的存储设备上，并通过网络将它们连接起来，这就是OpenStack的物理部署架构。

OpenStack的部署分为单节点部署和多节点部署两种类型。单节点部署就是将所有的服务和组件都放在一个物理节点上，通常是用于学习、验证、测试或者开发。多节点部署就是将服务和组件分别部署在不同的物理节点上。一个典型的多节点部署如图1-9所示。常见的节点类型有控制节点（Control Node）、计算节点（Compute Node）、存储节点（Storage Node）和网络节点（Network Node），下面分别介绍这些节点类型。

1.控制节点

控制节点又称管理节点，安装并运行各种OpenStack控制服务，负责管理、节制其余节点，执行虚拟机建立、迁移、网络分配、存储分配等任务。OpenStack的大部分服务都是运行在控制节点上，通常包括以下服务。

（1）支持服务（Supporting Service）

• 数据库服务器，如SQL数据库。

• 消息队列服务，如RabbitMQ。

• 网络时间协议（Network Time Protocol,NTP）服务。

（2）基础服务

运行Keystone认证服务、Glance镜像服务、Nova计算服务的管理组件、Neutron网络服务的管理组件、多种网络代理（Networking agent）和Horizon仪表板。

（3）扩展服务

运行Cinder块存储服务、Swift对象存储服务、Trove数据库服务、Heat编排服务和Ceilometer计量服务的部分组件。这对于控制节点来说是可选的。

控制节点一般只需要一个网络端口用于通信和管理各个节点。

2.计算节点

计算节点是实际运行虚拟机的节点，主要负责虚拟机的运行，为用户创建并运行虚拟机，为虚拟机分配网络。通常包括以下服务。

（1）基础服务

Nova计算服务的Hypervisor（虚拟机管理器）组件，提供虚拟机的创建、运行、迁移、快照等各种围绕虚拟机的服务，并提供API与控制节点对接，由控制节点下发任务。默认计算服务使用的Hypervisor是KVM。

网络插件代理，用于将虚拟机实例连接到虚拟网络中，通过安全组为虚拟机提供防火墙服务。

（2）扩展服务

Ceilometer计量服务代理，提供计算节点的监控代理，将虚拟机的情况反馈给控制节点。

虚拟机可以部署多个计算节点，一个计算节点至少需要两个网络端口，一个与控制节点进行通信，受控制节点统一调配；另一个与网络节点及存储节点进行通信。

3.存储节点

存储节点负责对虚拟机的外部存储进行管理等，即为计算节点的虚拟机提供持久化卷服务。这种节点存储需要的数据，包括磁盘镜像、虚拟机持久性卷。存储节点包含Cinder和Swift等服务，可根据需要安装共享文件服务。

块存储和对象存储可以部署在同一个存储节点上，也可以分别部署块存储节点和对象存储节点。不论采用哪种方式，都可以部署多个存储节点。

最简单的网络连接存储节点只需要一个网络接口，直接使用管理网络在计算节点和存储节点之间进行通信。而在生产环境中，存储节点最少需要两个网络接口，一个连接管理网络，与控制节点进行通信，接受控制节点下发的任务，受控制节点统一调配；另一个专门的存储网络（数据网络），与计算节点和网络节点进行通信，完成控制节点下发的各类数据传输任务。

4.网络节点

网络节点可实现网关和路由的功能，它主要负责外部网络与内部网络之间的通信，并将虚拟机连接到外部网络。网络节点仅包含Neutron服务，Neutron负责管理私有网段与公有网段的通信，以及管理虚拟机网络之间的通信拓扑，管理虚拟机上的防火墙等。

网络节点通常需要3个网络端口，分别用来与控制节点进行通信、与除控制节点外的计算节点和存储节点之间的通信、外部的虚拟机与相应网络之间的通信。

网络节点根据虚拟网络选项来决定要部署的服务和组件，它有两种选择，一种是提供者网络（Provider Networks，又译为供应商网络），另一种是自服务网络（Self-service Networks），这两种网络所需的组件如图1-10所示。

（1）提供者网络

选择提供者网络选项，将以最简单的方式部署 OpenStack 网络服务，它使用基本的二层（网桥/交换机）服务和虚拟局域网（Virtual Local Area Network,VLAN）分段。它实质上是将虚拟网络桥接到物理网络，并依靠物理网络基础设施提供的三层（路由）服务。另外，还需一个动态主机配置协议（Dynamic Host Configuration Protocal,DHCP）服务为虚拟机实例提供IP地址信息。

OpenStack用户需要了解底层网络基础设施的更多信息来创建虚拟网络，以精确匹配基础设施。

提示

提供者网络不支持自服务（私有）网络、三层路由服务，以及像 LBaaS（负载平衡服务）和FWaaS（防火墙服务）这样的高级服务。如果要使用这些特性，应选择自服务网络选项。

（2）自服务网络

选择自服务网络选项，会在提供者网络的基础上增加三层（路由）服务，这样才能够使用像VXLAN这样的覆盖分段方法。它实质上是通过NAT将虚拟网络路由到物理网络。另外，该选项将提供像LBaaS和FWaaS这样的高级服务。

OpenStack无须了解数据网络的底层基础设施即可创建虚拟网络。如果配置相应的二层插件，这也会包括VLAN。

在提供者网络架构中，所有实例均可直接连接到提供者网络。在自服务（私有）网络架构中，实例可以连接到自服务或提供者网络。自服务网络可以完全在OpenStack环境中或者通过外部网络使用NAT方式提供某种级别的外部网络访问。

5.节点的组合

OpenStack是一个松散耦合系统，具有弹性的设计和部署，上述节点可以根据需要进行整合。

可以从控制节点中分出一个专门的API节点，API节点去除Neutron服务之外的管理控制服务（如Nova、Glance、KeyStone等）。API节点又可以与网络节点合二为一。

数据库服务器和消息队列协议可以部署在控制节点（或 API 节点）上，也可以运行于网络节点上。Glance、Keystone、Cinder服务可以在API节点上运行，也可以在网络节点上运行，还可以在控制节点上运行。既可以创建单独的认证节点来运行Keystone服务，还可以创建单独的镜像节点来运行Glance服务。

提示

cinder-api与cinder-scheduler需要在同一节点上运行，共用同一配置文件；nova-api、nova-scheduler、nova-novncproxy服务应在同一节点上运行，共用相同的配置文件。

存储节点可以合并到某个计算节点上。

nova-compute与Neutron（openswitch、neutron-openvswitch-agent）服务必须在一个节点上运行，否则虚拟机实例无法获得网络分配。

1.4.5 OpenStack的物理网络类型

OpenStack的物理部署就是将承载不同服务的物理节点通过物理网络进行连接，从而使各个服务在云平台上协同工作。这里所讲的是主机节点之间的物理网络连接，而不是OpenStack网络服务中的虚拟网络。OpenStack环境中的物理网络配置往往包括以下类型。

1.公共网络（Pulic Network）

公共网络通常使用由电信运营商提供的公共IP地址。

2.外部网络（External Network）

数据中心 Intranet用于为虚拟机分配浮动的 IP地址，让 Internet用户能够访问该网络上的 IP地址。

3.管理网络（Management Network）

管理网络提供OpenStack各个组件之间的内部通信，以及API访问端点（Endpoint）。为安全考虑，该网络必须限制在数据中心内，也就是说，IP 地址通常只能在数据中心内部访问。这是一个单独的网络，确保系统管理和监控访问域虚拟机网络分离，以防止来自用户虚拟机网络的监听和攻击，保证云平台的安全性。

4.API网络

API网络用于为用户提供OpenStack API。实际上这不是一个单独的网络，而是包含在外部和内部网络中。API的端点（Endpoint）包括公共URL（Uniform Resource Locator，统一资源定位符）和内部URL，前者包含的是外部网络的IP 地址，后者包含的是管理网络的IP地址。为简单起见，提供给内外网络访问的API的公共URL和内部URL相同，而只给内部网络访问的API使用内部URL。

5.数据网络（Data Network）

数据网络可以细分为以下网络类型。

（1）项目（租户）网络（Tenant Network）：又称虚拟机（Virtual Machine,VM）网络，提供虚拟机在计算节点之间，以及计算节点和网络节点之间的通信。同样这也是数据中心的内部网络。

（2）存储访问网络（Storage Access Network）：访问存储的网络。

（3）存储后端网络（Storage Backend Network）：如Ceph和Swift集群用于后端数据复制的网络。

它们可以合为一种，也可以从性能方面考虑分离出一种或几种作为单独的网络。

6.硬件管理网络

除了以上网络类型，往往还有各种功能网络，包括IPMI网络、PXE网络、监控网络等，这些可以称为硬件管理网络。大型数据中心通常会建立单独的硬件管理网络。

上述网络，除公共网络和外部网络之外，都可以统称为OpenStack内部网络。这些网络类型可以根据需要灵活组配。管理网络与硬件管理网络可以合并为一个管理网络；API网络与外部网络也可以合二为一，通常这两个网络都是为外部用户提供服务的；管理网络与存储网络也可以合并到一起，因为管理网络流量很少；外部网络、API网络和数据网络也可以合并，以减少路由器物理设备，降低网络的复杂度；当然也可以将所有网络类型合并成一个网络，用于OpenStack的原型验证或开发测试。