第 3 章 云控制器设计和云系统管理

第 3 章 云控制器设计和云系统管理

OpenStack 被设计成可大规模水平扩展,这意味着所有服务都可以分布式铺开。然而,为了简化本指南,我们决定利用云控制器这个概念,针对具有核心性质的服务进行讨论。云控制器只是一个概念上的简化。在现实世界中,你得为云控制器设计高可用的架构,这样如果有任何节点发生故障,其他节点将会接管它的任务。在现实中,云控制器的任务分布在多个节点上。

云控制器为 OpenStack 的部署提供了中央管理系统。一般来说,云控制器管理认证系统,并通过消息队列将消息发送给所有系统。

对很多部署方式而言,云控制器是一个单独的节点,但是为了获得高可用性,你需要将一些相关因素考虑在内,我们将在本章对此进行介绍。

云控制器为云系统管理以下服务。

  • 数据库

    追踪用户和实例的当前信息。一般来说,每项服务对应一个数据库实例管理。

  • 消息队列服务

    所有 AMQP(高级消息队列服务协议)的消息通过队列代理,按照次序接收和发送。

  • 连接器服务

    代理那些对于数据库的请求。

  • 身份管理服务的认证和授权

    此服务指示了对特定的云资源,哪些用户可以执行哪些操作。当然,配额管理存在于所有服务中。

  • 镜像管理服务

    为云系统存储并提供镜像,并管理每个镜像的元数据信息。

  • 调度器服务

    决定优先使用哪些资源,例如:基于算法逻辑在实例启动的地方展开服务。

  • 用户面板

    为用户使用 OpenStack 云服务提供一个基于 Web 的前端。

  • API端点

    为每一项服务提供 REST API 访问,在这里 API 端点的目录是由身份服务来管理的。

在我们的例子中,云控制器上有一批 nova-* 组件,它们:呈现了云系统的全局状态;与各种服务,比如认证服务通信;在数据库中维护云系统相关的信息;通过消息队列与所有计算节点和存储程序通信;提供 API 访问。运行在云控制器上的每一项服务,都可以拆分到不同的节点上来保障其扩展性或可用性。

再如另外一个例子,你可以使用一对服务器组成一个云控制器组合——一个主用,一个备用——冗余节点提供一组特定的相关服务,例如:

  • 用于 API 访问的前端 Web 站点、用于选择在哪个计算节点上运行实例的调度器、身份服务和控制面板;

  • 数据库和消息队列服务器(例如 MySQL、RabbitMQ);

  • 用于镜像管理的镜像服务。

在了解有关控制云系统的种种设计方案后,你可以阅读更多有关进一步注意事项的内容,以便做出设计决策。

3.1 硬件注意事项

你也许希望根据自己运行的云系统的大小和类型,进一步指定云控制器所用的硬件;不过实际上,云控制器可以与计算节点使用一样的硬件。

也可以使用虚拟机来运行云控制器管理的所有或部分服务,例如消息队列。在本指南中,我们假定所有服务都直接在云控制器上运行。

表 3-1 包含了决定云控制器硬件规模时常见的注意事项。

表3-1:云控制器硬件规模注意事项

注意事项

展开

需要同时运行多少实例

据此设定数据库服务器的规模;如果同时有很多实例向云控制器汇报状态,或者需要计算能力来决定在哪里部署新的实例,那么就要扩展使用多个云控制器

需要同时运行多少计算节点

确保你的消息队列能够成功处理请求,并相应调整规模

多少用户访问 API

如果多个用户发出多重请求,要确保云控制器的 CPU 可以承担这样的负载

有多少用户使用控制面板(而非 REST API)

控制面板比 API 发起的请求要多;因此如果控制面板是你的用户的主要接口,请相应地添加更多 CPU

你的云系统同时运行多少 nova-api 服务

你需要根据每项 nova-api 服务的核心来决定云控制器的规模

一个实例需要运行多长时间

出于所有 API 查询和调度的需要,启动和删除实例不仅发生在计算节点上,同时也发生在控制器节点上

认证系统是否对外验证

外部系统,例如轻量级目录访问协议(LDAP)或 Windows 活动目录(Active Directory),要求在云控制器和外部认证系统之间进行网络连通;同时要确保云控制器有足够的 CPU 能力满足这些请求

3.2 服务的分隔

在我们的例子中,所有中心服务都运行在一个位置上;因此,将服务分隔到不同的物理服务器上,通常是一个不错的做法。表 3-2 是部署场景和相关说明的列表。

表3-2:部署场景

场景

说明

swift-proxy 服务器上运行 glance-* 服务

使用此种部署方式,对象存储代理服务器上有足够的空闲 I/O 资源,而 glance 的镜像传输部分会得益于物理硬件带来的高性能,以及与对象存储后端之间的良好的连通性

运行一个专用的中央数据库服务器

此种部署方式使用一个专用的中央数据库服务器向所有服务器提供数据库服务。通过隔离数据库服务器的更新,简化操作,同时可以轻松创建从库来实现故障切换功能

每项服务运行一个虚拟机

此种部署方式,在一组运行 KVM(基于内核的虚拟机)的服务器上运行中心服务;为每一项服务(nova-scheduler、rabbitmq、数据库等)创建一个专用的虚拟机——这样可以辅助部署进行扩展,因为管理员能够根据虚拟机的负载对分配给每个虚拟机的资源进行分配(在安装过程中,你可能还无法很好地理解这些负载的高低)

使用外部负载均衡器

在此种部署的结构中,有一个价格昂贵的硬件负载均衡器。此部署在不同的实体服务器上运行多个 nova-apiswift-proxy 服务器,并使用负载均衡器来在这些服务器之间进行切换

是否进行虚拟化是你在部署时经常要做出的选择。一些服务,例如 nova-computeswift-proxyswift-object 服务器,不应该进行虚拟化。但是控制服务器一般都要进行虚拟化——虚拟化造成的性能损失,可以通过运行更多服务进行弥补。

3.3 数据库

OpenStack 计算服务使用 SQL(结构化查询语言)数据库存储和检索状态信息。在 OpenStack 社区中,MySQL 是一个流行的数据库选择。

数据库损失会引起误差;因此我们建议你将数据库组成集群,使其可以容错。配置和维护数据库集群在 OpenStack 系统外进行,并取决于你的云环境使用的数据库软件。MySQL/Galera 是一款流行的基于 MySQL 的数据库选择。

3.4 消息队列

大多数 OpenStack 服务之间使用消息队列进行通信。例如,计算服务通过消息队列与块存储服务和网络服务通信。你也可以有选择地对任何服务启用通知功能。RabbitMQ、Qpid 和 0mq 都是流行的消息队列服务。一般来说,如果消息队列故障或无法访问,集群就会停止服务并终止于只读状态,信息卡在最后一个消息发送的地方。因此我们建议你将消息队列集群化。要知道对很多 OpenStack 部署而言,集群化的消息队列是一个难题。虽然 RabbitMQ 具备原生的集群化支持,但是大规模运行它的时候,就会发生故障。虽然也有其他的消息队列解决方案可用,例如 0mq 和 Qpid,但是 0mq 并不提供状态化队列。Qpid 是 Red Hat 及其衍生版使用的消息系统。Qpid 并不具有原生集群化的能力,因此需要借助其他补充的服务,例如 Pacemaker 或 Corsync。对于你的消息队列,你需要决定自己能接受何种级别的数据丢失,以及一旦发生故障,是否让 OpenStack 项目重试多个 MQ 主机,例如计算服务就可以这么做。

3.5 向导服务

在之前的 OpenStack 版本中,所有 nova-compute 服务都需要直接访问云控制器上的数据库。对安全性和性能而言,这是一个问题。对于安全性,如果一个计算节点被破解,那么攻击者就能够访问数据库。对于性能,nova-compute 对数据库的请求是单线程且阻塞式的。这就造成了性能瓶颈,因为数据库请求是串行处理而非并行处理的。

通过充当 nova-compute 服务的代理,向导服务解决了上述两个问题。现在 nova-compute 无需直接访问数据库,它只需要连接 nova-conductor 服务,而 nova-conductor 服务则代表 nova-compute 访问数据库。由于 nova-compute 不再直接访问数据库,安全问题就解决了。另外,nova-conductor 是非阻塞式服务,因此可以并行处理所有来自计算节点的请求。

 如果你在云环境中使用了 nova-network 和多主机网络,则 nova-compute 依然需要直接访问数据库。

nova-conductor 服务支持水平扩展。如需将 nova-conductor 配置为高可用且高容错,只需要在同一台服务器上或跨多个服务器运行更多的 nova-conductor 进程实例即可。

3.6 应用程序接口(API)

所有公共访问都要使用 API 服务,无论是通过命令行客户端直接访问还是通过基于 Web 的控制面板进行访问。你可以在 http://api.openstack.org/ 页面上查看 API 参考资料(API References)。

你需要选择你的部署是否同时支持 Amazon EC2 兼容性 API,还是仅支持 OpenStack API。如果同时支持两种 API,那么在使用镜像和实例的时候,你就要注意两者之间的不一致。

例如,EC2 API 引用的实例使用含有 16 进制信息的 ID,而 OpenStack API 使用名称和数字。类似地,EC2 API 倾向于依靠 DNS(域名服务器)别名连接虚拟机,而 OpenStack 通常使用 IP 地址列表。

如果 OpenStack 的构建方式有误,那么仅仅 DNS 别名有错,用户就无法连接实例。尽管如此,EC2 兼容性可以帮助用户迁移到你的云系统中。

正如数据库和消息队列一样,使用多个 API 服务器通常是件好事。使用传统的 HTTP 负载均衡技术可以获得高可用的 nova-api 服务。

3.7 扩展

“API 标准”(API Specifications,参见 http://opsgui.de/NPFK1H)定义了 OpenStack API 的核心操作、功能和媒介类型。客户端依赖于此核心 API 的可用性,而 API 的实施者则需要维护其完整性。当与多个同 API 实现进行交互时,严格依照核心 API 使客户端能够以最低级别的功能性进行工作。

OpenStack 计算 API 是可扩展的。扩展可以为 API 添加核心以外的功能。新特性、MIME 类型、操作、状态、标题、参数和资源等的引进都可以通过向核心 API 添加扩展的方法实现。这就能够在不变更版本的情况下引进新特性,并能够引进供应商特有的功能。

3.8 调度

调度服务负责确定虚拟机或块存储卷应该创建在哪个计算节点或存储节点上。调度服务从消息队列中接收到这些资源的创建请求,然后开始确定合适的节点运行这些资源。这个过程是通过对可用的节点集合使用一系列用户可配置的过滤器来实现的。

目前有两种调度器:nova-scheduler 用于虚拟机,cinder-scheduler 用于块存储卷。两种调度器都能进行水平扩展,因此为实现高可用性,或者对于那些非常大的或高调度频率的安装,你应该考虑对每种调度器运行多个实例。调度器都监听共享的消息队列,因此无需专门的负载均衡。

3.9 镜像

OpenStack 镜像服务包含两个部分:glance-apiglance-registry。前者负责镜像传输,计算节点使用它从后端下载镜像;后者维护了与虚拟机镜像相关联的元数据,存储在数据库中。

glance-api 部分是一个抽象层,它支持多种后端(目前的支持项如下)。

  • OpenStack对象存储

    你能将镜像存储成对象。

  • 文件系统

    使用传统的文件系统,将镜像存储以文件方式存储。

  • S3

    你能够从 Amazon S3 上获取镜像。

  • HTTP

    你能够通过 Web 服务器获取镜像。此种方式无法写入镜像。

如果你已经有了 OpenStack 对象存储服务,我们建议你将它作为一个可扩展的地方来存储镜像。如果性能足够好,使用文件系统也可以;或者用 Amazon S3——除非你不需要通过 OpenStack 上传新镜像。

3.10 控制面板

OpenStack 控制面板(horizon)为各种 OpenStack 组件提供了一个基于 Web 的用户界面。控制面板包含一个终端用户区域,使用户管理他们的虚拟基础架构;还包括一个管理区,使云系统操作人员对 OpenStack 环境进行整体管理。

控制面板是一个 Python 的 Web 程序,通常运行在 Apache httpd(超文件传送协定常驻程式)中。因此,你可以像对待其他 Web 应用一样对待它,假设它能通过网络到达 API 服务器(包含它们的管理端点)。

3.11 认证及授权

支持 OpenStack 认证和授权系统的概念,源自易于理解和广泛使用的同类系统。用户使用凭据进行认证,他们可以是一个或多个组(称为“项目”或者“租户”,两者可互换)的成员。

例如,云系统管理员能够在云系统中列出所有实例,而用户仅能看到那些在他当前所在的组中的实例。资源配额,例如能够使用的核心数量、磁盘空间等,都与项目相关联。

OpenStack 身份服务(keystone)是提供认证决策和用户属性信息的关键,其他 OpenStack 服务正是依靠它来执行授权。在 policy.json 文件中设置规则。关于如何进行配置的详细信息,参见第 9 章。

身份服务支持多种认证决策和身份存储的插件,这些插件包括:

  • 内存中键值存储(一种简化的内部存储结构);

  • SQL 数据库(例如 MySQL 或者 PostgreSQL);

  • PAM(可插入认证模块);

  • LDAP(例如 OpenLDAP 或微软的活动目录)。

很多部署使用 SQL 数据库,然而对于那些需要对认证基础结构进行集成的部署而言,LDAP 也是一种流行的选择。

3.12 网络相关注意事项

由于云控制器需要处理如此多不同的服务,它必须能够很好地应对随之产生的网络流量。如果你选择在云控制器上运行 OpenStack 镜像服务,那么控制器就应该能以可接受的网速支持镜像传输。

如果你选择使用单主机网络连接,云控制器就是所有实例的网关,那么云控制器必须能够支持云系统与公共互联网之间通信的所有流量。

我们建议使用高速网卡,例如 10 Gbit/s 网卡。你可以将两个 10 Gbit/s 网卡捆绑在一起使用。虽然可能无法完全获得 20 Gbit/s 的绑定速度,但不同传送流量可以使用不同网卡。例如,如果云控制器传送两个镜像,那么每一个镜像使用不同的网卡且能够使用满 10 Gbit/s 的网络带宽。

目录