控制平面架构¶
OpenStack 被设计为可大规模水平扩展，这使得所有服务都可以被广泛地分布。然而，为了简化本指南，我们决定讨论更中心化的服务，使用云控制器的概念。云控制器是一种概念上的简化。在实际世界中，您需要设计一个云控制器的架构，使其具有高可用性，以便任何节点发生故障时，另一个节点可以接管所需的任务。实际上，云控制器任务分布在多个节点上。
云控制器为 OpenStack 部署提供中央管理系统。通常，云控制器管理身份验证并通过消息队列向所有系统发送消息。
对于许多部署，云控制器是一个单一节点。但是，为了实现高可用性，您需要考虑一些因素，我们将在本章中介绍这些因素。
云控制器管理云的以下服务
- 数据库
跟踪用户和实例的当前信息，例如，在数据库中，通常每个服务管理一个数据库实例
- 消息队列服务
所有 高级消息队列协议 (AMQP) 消息都根据队列代理接收和发送
- 调度服务
代理请求到数据库
- 身份管理认证和授权
指示哪些用户可以在某些云资源上执行哪些操作；配额管理分布在各个服务中，但是认证
- 镜像管理服务
存储和提供带有元数据的镜像，用于在云中启动
- 调度服务
指示首先使用哪些资源；例如，根据算法分散实例的启动位置
- 用户仪表盘
为用户提供基于 Web 的前端，以使用 OpenStack 云服务
- API 端点
提供每个服务的 REST API 访问，API 端点目录由身份服务管理
对于我们的示例，云控制器包含一组 nova-* 组件，这些组件代表云的全局状态；与身份验证等服务通信；在数据库中维护有关云的信息；通过队列与所有计算节点和存储 工作节点 通信；并提供 API 访问。运行在指定云控制器上的每个服务都可以分解为单独的节点，以实现可扩展性或可用性。
例如，您可以使用成对的服务器作为集体的云控制器——一个活动，一个待机——为提供给定相关服务的冗余节点，例如
用于 API 请求的前端 Web、用于选择启动实例的计算节点的调度器、身份服务和仪表盘
数据库和消息队列服务器（例如 MySQL、RabbitMQ）
用于镜像管理的镜像服务
现在您已经了解了控制云的各种设计，请阅读更多关于进一步的考虑因素，以帮助您做出设计决策。
硬件考虑因素¶
云控制器的硬件可以与计算节点相同，尽管您可能希望根据您运行的云的大小和类型进一步指定。
也可以使用虚拟机来管理云控制器管理的所有或某些服务，例如消息队列。在本指南中，我们假设所有服务都直接在云控制器上运行。
表. 云控制器硬件尺寸考虑因素 包含在为云控制器设计确定硬件尺寸时需要审查的常见考虑因素。
考虑因素 |
影响 |
|---|---|
将同时运行多少个实例？ |
相应地调整数据库服务器的大小，如果许多实例将同时报告状态并且启动新实例的调度需要计算能力，则扩展到多个云控制器。 |
将同时运行多少个计算节点？ |
确保您的消息队列能够成功处理请求并相应地调整大小。 |
将有多少用户访问 API？ |
如果许多用户发出多个请求，请确保云控制器的 CPU 负载能够处理它。 |
将有多少用户访问仪表盘与直接通过 REST API 访问？ |
仪表盘发出许多请求，甚至比 API 访问更多，因此如果您的仪表盘是用户的首要界面，请添加更多的 CPU。 |
您为您的云运行多少个 |
您需要为每个服务配置一个核心的控制器大小。 |
单个实例运行多长时间？ |
启动实例和删除实例对计算节点要求很高，对控制器节点也有很高的要求，因为所有 API 查询和调度需求。 |
您的身份验证系统是否也验证外部系统？ |
外部系统，例如 轻量级目录访问协议 (LDAP) 或 Active Directory 需要云控制器与外部身份验证系统之间的网络连接。 此外，请确保云控制器具有足够的 CPU 功率来跟上请求。 |
服务分离¶
虽然我们的示例将所有中央服务放在单个位置，但将服务分离到不同的物理服务器上是可能的，实际上通常是一个好主意。表. 部署场景 是我们看到的一些部署场景及其理由。
场景 |
理由 |
|---|---|
在 |
此部署认为对象存储代理服务器上的备用 I/O 足够，并且镜像交付部分受益于在物理硬件上运行并与它正在使用的对象存储后端具有良好的连接性。 |
运行中央专用数据库服务器。 |
此部署使用中央专用服务器来为所有服务提供数据库。这种方法简化了操作，通过隔离数据库服务器更新，并允许为故障转移轻松创建从属数据库服务器。 |
为每个服务运行一个 VM。 |
此部署在运行 KVM 的服务器上运行中央服务。为每个服务（ |
使用外部负载均衡器。 |
此部署在其组织中有一个昂贵的硬件负载均衡器。它在不同的物理服务器上运行多个 |
一个总是出现的问题是是否要虚拟化。一些服务，例如 nova-compute、swift-proxy 和 swift-object 服务器，不应虚拟化。但是，控制服务器通常可以被愉快地虚拟化——性能损失通常可以通过简单地运行更多服务来抵消。
数据库¶
OpenStack Compute 使用 SQL 数据库来存储和检索有状态信息。MySQL 是 OpenStack 社区中流行的数据库选择。
数据库丢失会导致错误。因此，我们建议您集群数据库以使其具有容错能力。配置和维护数据库集群是在 OpenStack 之外完成的，并由您选择在云环境中使用的数据库软件决定。MySQL/Galera 是基于 MySQL 的数据库的一个流行选择。
消息队列¶
大多数 OpenStack 服务使用消息队列相互通信。例如，Compute 通过消息队列与块存储服务和网络服务通信。此外，您可以选择为任何服务启用通知。RabbitMQ、Qpid 和 Zeromq 都是消息队列服务的流行选择。通常，如果消息队列失败或无法访问，集群将停止并最终进入只读状态，信息会卡在发送最后一条消息的点上。因此，我们建议您集群消息队列。请注意，集群消息队列可能是许多 OpenStack 部署中的一个痛点。虽然 RabbitMQ 具有本机集群支持，但有报告称在大型规模上运行时存在问题。虽然其他队列解决方案可用，例如 Zeromq 和 Qpid，但 Zeromq 不提供有状态队列。Qpid 是 Red Hat 及其衍生产品的消息传递系统。Qpid 没有本机集群功能，需要补充服务，例如 Pacemaker 或 Corsync。对于您的消息队列，您需要确定您愿意接受的数据丢失程度，以及是否使用 OpenStack 项目的能力来重试多个 MQ 主机以应对故障，例如 Compute 的能力。
调度服务¶
在 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 进程的实例，无论是在同一服务器上还是跨多个服务器上。
应用程序编程接口 (API)¶
所有公共访问，无论是直接的、通过命令行客户端的还是通过基于 Web 的仪表盘的，都使用 API 服务。请在 OpenStack 云的开发资源 处找到 API 参考。
您必须选择是否要支持 Amazon EC2 兼容性 API，或者只支持 OpenStack API。在运行这两种 API 时，您可能会遇到一个问题，即在引用镜像和实例时体验不一致。
例如，EC2 API 使用包含十六进制的 ID 来引用实例，而 OpenStack API 使用名称和数字。 同样，EC2 API 倾向于依赖 DNS 别名来联系虚拟机，而 OpenStack 通常列出 IP 地址。
如果 OpenStack 没有正确设置，用户由于只有不正确的 DNS 别名而无法联系其实例的情况很容易发生。 尽管如此，EC2 兼容性可以帮助用户迁移到您的云。
与数据库和消息队列一样，拥有多个 API 服务器 是件好事。可以使用传统的 HTTP 负载均衡技术来实现高可用的 nova-api 服务。
扩展¶
《API 规范》定义了 OpenStack API 的核心操作、功能和媒体类型。客户端始终可以依赖于此核心 API 的可用性，并且实施者始终需要完全支持它。严格遵守核心 API 要求允许客户端在与同一 API 的多个实现交互时依赖于最低限度的功能。
OpenStack 计算 API 具有可扩展性。扩展会向 API 添加超出核心定义的功能。通过对核心 API 进行扩展，可以实现新功能、MIME 类型、操作、状态、标头、参数和资源的引入。这允许在无需更改版本的情况下在 API 中引入新功能，并允许引入特定于供应商的利基功能。
调度¶
调度服务负责确定虚拟机或块存储卷应该在哪个计算或存储节点上创建。调度服务从消息队列接收这些资源的创建请求，然后开始确定资源应该驻留在哪个节点的流程。通过将一系列用户可配置的过滤器应用于可用的节点集合来完成此过程。
目前有两个调度器：nova-scheduler 用于虚拟机和 cinder-scheduler 用于块存储卷。两个调度器都可以水平扩展，因此，为了高可用性或对于非常大或高调度频率的安装，您应该考虑运行每个调度器的多个实例。所有调度器都侦听共享消息队列，因此不需要特殊的负载均衡。
镜像¶
OpenStack 镜像服务由两部分组成：glance-api 和 glance-registry。前者负责镜像的交付；计算节点使用它从后端下载镜像。后者维护与虚拟机镜像关联的元数据信息，并需要数据库。
glance-api 部分是一个抽象层，允许选择后端。目前，它支持
- OpenStack 对象存储
允许您将镜像存储为对象。
- 文件系统
使用任何传统文件系统将镜像存储为文件。
- S3
允许您从 Amazon S3 获取镜像。
- HTTP
允许您从 Web 服务器获取镜像。您不能使用此模式写入镜像。
如果您有 OpenStack 对象存储服务，我们建议将其用作存储镜像的可扩展位置。您还可以使用具有足够性能的文件系统或 Amazon S3——除非您不需要通过 OpenStack 上传新镜像的能力。
仪表盘¶
OpenStack 仪表盘 (horizon) 为各种 OpenStack 组件提供基于 Web 的用户界面。仪表盘包括一个用于用户管理其虚拟基础设施的终端用户区域，以及一个用于云操作员管理整个 OpenStack 环境的管理员区域。
仪表盘实现为一个 Python Web 应用程序，通常在 Apache httpd 中运行。因此，只要它可以通过网络访问 API 服务器（包括其管理端点），您可以像对待任何其他 Web 应用程序一样对待它。
网络注意事项¶
由于云控制器处理如此多的不同服务，因此它必须能够处理撞击它的流量量。例如，如果您选择将 OpenStack 镜像服务托管在云控制器上，则云控制器应能够以可接受的速度支持传输镜像。
作为另一个例子，如果您选择使用单主机网络，其中云控制器是所有实例的网络网关，那么云控制器必须支持在您的云和公共互联网之间传输的所有流量。
我们建议您使用快速网卡，例如 10 GB。您还可以选择使用两个 10 GB 网卡并将它们绑定在一起。虽然您可能无法获得完全绑定的 20 GB 速度，但不同的传输流使用不同的网卡。例如，如果云控制器传输两个镜像，则每个镜像使用不同的网卡并获得完整的 10 GB 带宽。
