[ English | 日本語 | Deutsch | Indonesia ]

容量规划和扩展

基于云的应用程序通常请求更多的离散硬件（横向扩展），而不是传统应用程序，后者需要更大的硬件来扩展（纵向扩展）。

OpenStack 被设计为横向可扩展的。与其切换到更大的服务器，不如采购更多的服务器并简单地安装配置相同的服务。理想情况下，您应该在功能上完全相同的服务（例如，计算节点或 nova-api 节点）的组之间进行扩展和负载均衡，这些服务通过消息总线进行通信。

确定云的可扩展性

确定您的云的可扩展性以及如何改进它需要在许多变量之间取得平衡。没有一个解决方案能够满足所有人的可扩展性目标。但是，跟踪一些指标会有所帮助。您可以在 OpenStack 中定义称为“flavor”（风味）的虚拟硬件模板，这将影响您的云扩展决策。这些模板定义了 RAM 中的内存大小、根磁盘大小、可用临时数据磁盘空间量以及 CPU 核心的数量。

OpenStack 默认的 flavor 如下表 表. OpenStack 默认 flavor 所示。

表. OpenStack 默认 flavor

名称

虚拟核心

内存

磁盘

临时

m1.tiny

1

512 MB

1 GB

0 GB

m1.small

1

2 GB

10 GB

20 GB

m1.medium

2

4 GB

10 GB

40 GB

m1.large

4

8 GB

10 GB

80 GB

m1.xlarge

8

16 GB

10 GB

160 GB

起点是您的云的核心数量。通过应用一些比例，您可以收集有关

  • 您期望运行的虚拟机 (VM) 数量，((超额承诺 比例 × 核心数) / 每个实例的虚拟核心数)

  • 需要多少存储空间 (flavor 磁盘大小 × 实例数量)

您可以使用这些比例来确定支持您的云所需的额外基础设施。

以下是一个使用比例来收集预期 VM 数量以及所需存储信息的示例。以下数字支持 (200 / 2) × 16 = 1600 个 VM 实例，并需要 80 TB 的存储空间用于 /var/lib/nova/instances

  • 200 个物理核心。

  • 大多数实例的大小为 m1.medium（两个虚拟核心，50 GB 的存储空间）。

  • 默认 CPU 超额承诺比例 (cpu_allocation_ratio 在 nova.conf 文件中) 为 16:1。

注意

无论超额承诺比例如何，实例都不能放置在任何物理节点上，该节点的原始（预超额承诺）资源少于实例 flavor 所需的资源。

但是，您需要考虑的不仅仅是核心数量来估计 API 服务、数据库服务器和队列服务器可能遇到的负载。您还必须考虑您的云的使用模式。

例如，比较支持托管 Web 托管平台的云与为开发项目运行集成测试的云，后者每次代码提交都会创建一个 VM。在前者，创建 VM 的繁重工作仅每隔几个月发生一次，而后者则对云控制器施加持续的重负载。您必须考虑您的平均 VM 生命周期，因为数量越大通常意味着对云控制器的负载越小。

除了 VM 的创建和终止之外，您还必须考虑用户访问该服务的影响，尤其是在 nova-api 及其关联的数据库上。列出实例会收集大量信息，并且鉴于用户运行此操作的频率，拥有大量用户的云可以显著增加负载。即使他们不知道，也可能发生这种情况。例如，在浏览器中打开 OpenStack 仪表板的实例选项卡每 30 秒刷新一次 VM 列表。

在考虑这些因素之后，您可以确定您需要的云控制器核心数量。通常，一个具有八个核心和 8 GB RAM 的服务器足以支持最多一个机架的计算节点——在上述注意事项下。

您还必须考虑用户 VM 性能的关键硬件规格，以及预算和性能需求，包括存储性能（主轴/核心）、内存可用性（RAM/核心）、网络带宽硬件规格（Gbps/核心）以及整体 CPU 性能（CPU/核心）。

提示

有关指标跟踪的讨论，包括如何从您的云中提取指标，请参阅 OpenStack Operations Guide。

添加云控制器节点

您可以通过添加节点来促进云的横向扩展。添加计算节点很简单，因为它们很容易被现有安装拾取。但是，在设计高度可用的集群时，您必须考虑一些重要事项。

云控制器节点运行多个不同的服务。您可以安装仅使用消息队列内部通信的服务——nova-scheduler 和 nova-console 在新服务器上进行扩展。但是，其他关键部分需要更多关注。

您应该对用户面向的服务（例如仪表板、nova-api 或对象存储代理）进行负载均衡。使用任何标准的 HTTP 负载均衡方法（DNS 轮询、硬件负载均衡器或软件，例如 Pound 或 HAProxy）。仪表板的一个注意事项是 VNC 代理，它使用 WebSocket 协议——L7 负载均衡器可能难以处理。另请参阅 Horizon 会话存储。

您可以配置一些服务，例如 nova-api 和 glance-api，通过更改其配置文件中的标志来使用多个进程，从而使它们能够在同一机器上的多个核心之间共享工作。

提示

MySQL 负载均衡有多种选择，并且支持的 AMQP 代理具有内置的集群支持。有关如何配置这些以及许多其他服务的更多信息，请参阅 Operations Guide。

隔离您的云

当用户出于数据存储的法律考虑、地震断层线的冗余或低延迟 API 调用而需要不同的区域时，需要隔离您的云。它可以按cells（单元）、regions（区域）、availability zones（可用区）或host aggregates（主机聚合）进行隔离。

每种方法都提供不同的功能，可以最好地分为两组

  • Cells 和 regions，它们隔离整个云并导致运行单独的 Compute 部署。

  • Availability zones 和 host aggregates，它们仅仅划分单个 Compute 部署。

表. OpenStack 隔离方法 提供了 OpenStack Compute 当前提供的每种隔离方法的比较视图。

表. OpenStack 隔离方法

Cells

区域

可用区

Host aggregates

使用

在保持单个 API endpoint 的同时，分片和扩展计算部署。

不协调的独立区域，每个区域都有单独的 API endpoint。

您 nova 部署内的逻辑分离，用于物理隔离或冗余。

为了调度具有共同特征的一组主机。

示例

一个具有多个站点，您可以在“任何地方”或特定站点上调度 VM 的云。

一个具有多个站点，您将 VM 调度到特定站点并希望共享基础设施的云。

一个单站点云，其设备由单独的电源供电。

调度到具有受信任硬件支持的主机。

开销

每个 Cell 包含具有重叠功能的实例服务。

每个区域都有一个不同的 API endpoint。每个区域都有一个完整的 nova 安装。

nova.conf 的配置更改。

nova.conf 的配置更改。

共享服务

Keystone, nova-api

Keystone

Keystone, 所有 nova 服务

Keystone, 所有 nova 服务

Cells 和 regions

OpenStack Compute Cells 旨在允许以分布式方式运行云，而无需使用更复杂的技术，或对现有的 nova 安装进行侵入式操作。云中的主机被划分为称为Cells 的组。Cells 配置为树形结构。顶级 Cell（“API cell”）有一个运行 nova-api 服务的宿主机，但没有 nova-compute 服务。 nova-compute 运行在子 Cell 中。每个 Cell 都有自己的消息队列和数据库服务。

这允许使用单个 API 服务器来控制对多个计算安装的访问，方法是使用多个 Cells。有关更多文档，请参阅 Nova Cells V2 Layout。

与拥有单个 API endpoint 不同，regions 具有单独的 API endpoint，从而实现更离散的分离。希望在多个站点上运行实例的用户必须显式选择一个区域。但是，不需要运行新服务的额外复杂性。

OpenStack 仪表板 (horizon) 可以配置为使用多个 regions。这可以通过 AVAILABLE_REGIONS 参数进行配置。

Availability zones 和 host aggregates

您可以使用 availability zones、host aggregates 或两者来划分 nova 部署。这两种方法都以类似的方式配置和实现。

Availability zone

这使您能够将 OpenStack 计算主机组织成逻辑组，并提供与其他可用区的物理隔离和冗余形式，例如通过使用单独的电源或网络设备。

您在每个服务器的本地定义指定计算主机所在的可用区。可用区通常用于标识具有共同属性的一组服务器。例如，如果您的数据中心中的某些机架位于单独的电源上，您可以将这些机架中的服务器放在自己的可用区中。可用区还可以帮助分离不同类型的硬件。

当用户配置资源时，他们可以指定希望在其上构建实例的可用区。这允许云用户确保他们的应用程序资源分布在不同的机器上，以在发生硬件故障时实现高可用性。

Host aggregates zone

这使您能够将 OpenStack Compute 部署划分为逻辑组，以进行负载均衡和实例分配。您可以使用主机聚合来进一步划分可用区。例如，您可以使用主机聚合来划分可用区，以划分共享通用资源（例如存储和网络）或具有特殊属性（例如受信任的计算硬件）的主机组。

主机聚合的常见用途是为 nova-scheduler 提供信息。例如，您可以使用主机聚合来分组共享特定 flavor 或镜像的主机组。

这种情况的一般情况是在聚合元数据中设置键值对，并在 flavor 的 extra_specs 元数据中匹配键值对。调度器筛选器中的 AggregateInstanceExtraSpecsFilter 将强制实例仅调度到聚合中定义相同键到相同值的宿主机上。

此概念的高级用法允许不同的 flavor 类型使用不同的 CPU 和 RAM 分配比例，以便高强度计算负载和低强度开发和测试系统可以共享同一个云，而不会使高使用系统饿死或浪费低利用率系统的资源。这可以通过在主机聚合中设置 metadata，并在 flavor 类型中匹配 extra_specs 来完成。

第一步是在聚合元数据中设置键 cpu_allocation_ratio 和 ram_allocation_ratio 为浮点值。筛选器调度器 AggregateCoreFilter 和 AggregateRamFilter 将在调度到聚合中的主机时使用这些值，而不是 nova.conf 中的全局默认值。在使用此功能时要小心，因为每个主机可以位于多个聚合中，但对于每种资源应该只有一个分配比例。您需要避免将主机放在为同一资源定义不同值的多个聚合中。

这是方程的第一部分。为了获得保证特定比例的口味类型，您必须在口味类型中设置 extra_specs，使其与您要在聚合中匹配的键值对相同。例如，如果您定义 extra_specs cpu_allocation_ratio 为“1.0”，那么该类型的实例将仅在元数据键 cpu_allocation_ratio 也定义为“1.0”的聚合中运行。在实践中，最好在聚合元数据中定义额外的键值对来匹配，而不是直接匹配 cpu_allocation_ratio 或 core_allocation_ratio。这可以提供更好的抽象性。例如，通过定义一个键 overcommit 并设置值“high”（高）、“medium”（中）或“low”（低），您可以调整聚合中的数值分配比例，而无需更改所有与它们相关的口味类型。

注意

以前，所有服务都有一个可用区。目前，只有 nova-compute 服务拥有自己的可用区。诸如 nova-scheduler、nova-network 和 nova-conductor 等服务始终跨越所有可用区。

当您运行以下任何操作时，这些服务将出现在它们自己的内部可用区 (CONF.internal_service_availability_zone) 中

  • openstack host list (os-hosts)

  • euca-describe-availability-zones verbose

  • openstack compute service list

内部可用区在 euca-describe-availability_zones (非详细模式) 中被隐藏。

CONF.node_availability_zone 已重命名为 CONF.default_availability_zone，仅由 nova-api 和 nova-scheduler 服务使用。

CONF.node_availability_zone 仍然有效，但已被弃用。

可扩展的硬件

虽然已经存在一些资源来帮助部署和安装 OpenStack，但确保您提前规划好部署非常重要。本指南假定您已为 OpenStack 云预留了一个机架，但也提供了有关何时以及扩展什么的建议。

硬件采购

“云”被描述为一个可以随意创建和终止服务器的易变环境。虽然这可能是真的，但这并不意味着您的服务器必须是易变的。确保您的云的硬件稳定且配置正确，意味着您的云环境将保持运行。

OpenStack 可以部署在任何受 OpenStack 兼容 Linux 发行版支持的硬件上。

硬件不必一致，但至少应具有相同类型的 CPU，以支持实例迁移。

建议与 OpenStack 一起使用的典型硬件是大多数硬件供应商备货的标准性价比高的产品。将您的采购划分为构建块（例如“计算”、“对象存储”和“云控制器”）并根据需要请求这些构建块应该很简单。或者，您拥有的任何满足性能要求和虚拟化技术的现有服务器很可能支持 OpenStack。

容量规划

OpenStack 被设计为以一种直接的方式增加规模。考虑到之前提到的注意事项，特别是关于云控制器的规模，应该能够根据需要采购额外的计算或对象存储节点。新节点不需要与现有节点具有相同的规格或供应商。

对于计算节点，nova-scheduler 将管理核心数和 RAM 的大小差异。但是，您应该考虑用户体验会随着不同的 CPU 速度而变化。在添加对象存储节点时，应指定一个 weight，以反映该节点的 capability。

监控资源使用情况和用户增长将使您能够了解何时采购。Operations Guide 中的 日志记录和监控 章节详细介绍了一些有用的指标。

老化测试

服务器硬件在其生命周期开始和结束时发生故障的可能性很高。因此，通过适当的老化测试来尝试触发早期阶段的故障，可以避免在生产中处理硬件故障。一般原则是对硬件进行极限测试。老化测试的示例包括运行 CPU 或磁盘基准测试几天。