可用区

注意

本节提供关于可用区功能的部署和管理员用户使用信息。有关可用区的最终用户信息，请参阅 用户指南。

可用区是云的逻辑抽象，对最终用户可见，无需了解物理基础设施即可对云进行分区。它们可用于根据任意因素（例如位置（国家/地区、数据中心、机架）、网络布局和/或电源）对云进行分区。

注意

不应假定可用区映射到故障域，并且本身不提供固有的高可用性 (HA) 优势。

可用区并未在数据库中建模；相反，它们是通过将特定的元数据信息附加到 聚合 来定义的。将此特定元数据添加到聚合后，该聚合将从最终用户角度可见，从而允许用户将实例调度到特定的主机集合，即属于该聚合的主机。在比较可用区和主机聚合时，还需要注意一些额外的差异

  • 一台主机可以属于多个聚合，但它只能属于一个可用区。

  • 默认情况下，即使主机不属于聚合，它也属于默认可用区。可以使用 default_availability_zone 配置选项来配置此默认可用区的名称。

    警告

    在请求中使用默认可用区名称很容易出错。由于用户可以看到可用区列表，因此他们无法知道默认可用区名称（当前为 nova）是由于主机属于其 AZ 元数据键设置为 nova 的聚合，还是因为至少有一台主机不属于任何聚合。因此，强烈建议用户永远不要通过指定名为 nova 的显式 AZ 来请求启动实例，并且强烈建议操作员不要将 AZ 元数据设置为聚合的 nova。这可能会导致一些问题，因为实例 AZ 信息显式地附加到 nova，这可能会在主机移动到另一个聚合或用户想要迁移实例时破坏进一步的移动操作。

    注意

    可用区名称不得包含 :，因为它被管理员用户用来指定在服务器创建中启动实例的主机。有关更多信息，请参见 使用可用区选择主机。

    注意

    不允许在可用区之间移动实例。如果将主机添加到聚合或从聚合中删除主机会导致实例在可用区之间移动，包括移动到或从默认 AZ，则该操作将被拒绝。管理员应首先从主机中释放实例，然后才能移动主机。

此外，其他服务，例如 网络服务 和 块存储服务，也提供可用区功能。但是，这些服务中这些功能的实现方式差异很大。有关其实现方式的更多信息，请参阅这些其他服务的文档。

带有 Placement 的可用区

为了使用 placement 来尊重可用区请求，必须存在与您分配为可用区的 nova 主机聚合的成员资格和 UUID 匹配的 placement 聚合。使用聚合元数据键来控制此功能。从 28.0.0 (Bobcat) 开始，这是将实例调度到可用区的唯一方法。

$ openstack --os-compute-api-version=2.53 aggregate create myaz
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| availability_zone | None                                 |
| created_at        | 2018-03-29T16:22:23.175884           |
| deleted           | False                                |
| deleted_at        | None                                 |
| id                | 4                                    |
| name              | myaz                                 |
| updated_at        | None                                 |
| uuid              | 019e2189-31b3-49e1-aff2-b220ebd91c24 |
+-------------------+--------------------------------------+

$ openstack --os-compute-api-version=2.53 aggregate add host myaz node1
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| availability_zone | None                                 |
| created_at        | 2018-03-29T16:22:23.175884           |
| deleted           | False                                |
| deleted_at        | None                                 |
| hosts             | [u'node1']                           |
| id                | 4                                    |
| name              | myagg                                |
| updated_at        | None                                 |
| uuid              | 019e2189-31b3-49e1-aff2-b220ebd91c24 |
+-------------------+--------------------------------------+

$ openstack aggregate set --property availability_zone=az002 myaz

移动服务器的影响

有几种方法可以将服务器移动到另一个主机：撤离、调整大小、冷迁移、实时迁移和卸架。移动操作通常会通过调度器来选择目标主机。

在 API 微版本 2.68 之前，使用较旧的 openstackclient (pre-5.5.0) 和 novaclient，可以指定目标主机，并且请求会强制服务器跳转到该主机，从而绕过调度器。只有撤离和实时迁移可以强制绕过调度器并将服务器移动到指定主机，即使如此，也强烈建议不要强制绕过调度器。

  • 使用强制主机进行实时迁移（适用于较旧的 openstackclients(pre-5.5.0)

$ openstack server migrate --live <host> <server>

  • 不强制进行实时迁移

$ openstack server migrate --live-migration --host <host> <server>

虽然在 5.5.3 中添加了对 openstackclient 的 ‘server evacuate’ 命令的支持，但它从未暴露强制撤离的能力，但以前可以使用 novaclient 实现。

  • 使用强制主机进行撤离

$ nova evacuate --force <server> <host>

  • 使用 novaclient 不强制进行撤离

$ nova evacuate

  • 使用 openstackclient 不强制进行撤离

$ openstack server evacuate --host <host> <server>

关于可用区，如果

  1. 服务器是在包含 availability_zone 参数的 POST /servers 请求中在特定区域创建的。

  2. 如果服务器创建请求不包含 availability_zone 参数，但 API 服务配置了 default_schedule_zone，那么默认情况下服务器将被调度到该区域。

  3. 卸架的服务器通过使用微版本 2.77 或更高版本的 POST /servers/{server_id}/action 请求指定 availability_zone 进行卸架。

  4. cinder.cross_az_attach 为 False，default_schedule_zone 为 None，服务器是在没有显式区域的情况下创建的，但具有预先存在的卷块设备映射。在这种情况下，如果卷区域与 default_availability_zone 不同，服务器将在与卷相同的区域创建。有关详细信息，请参见 资源亲和性。

如果服务器未在特定区域创建，则可以将其自由移动到其他区域。

资源亲和性

可以使用 cinder.cross_az_attach 配置选项来限制服务器和连接到服务器的卷位于同一可用区。

设置 cross_az_attach=False 的典型用例是在高性能计算集群中强制执行计算和块存储亲和性。

默认情况下，cross_az_attach 为 True，这意味着连接到服务器的卷可以位于与服务器不同的可用区。如果设置为 False，则在创建具有预先存在卷的服务器或将卷附加到服务器时，服务器和卷区域必须匹配，否则请求将失败。此外，如果 nova-compute 服务在服务器创建期间创建要附加到服务器的卷，它将请求在与服务器相同的可用区中创建这些卷，这必须存在于块存储 (cinder) 服务中。

如 移动服务器的影响 部分所述，强制将服务器移动到另一个区域也可能破坏与附加卷的亲和性。

注意

cross_az_attach=False 很少使用且未经过广泛测试，因此存在一些已知问题

使用可用区选择主机

我们可以将可用区与特定的主机和/或节点结合使用，以选择启动实例的位置。例如

$ openstack server create --availability-zone ZONE:HOST:NODE ... SERVER

注意

可以使用 ZONE、ZONE:HOST 和 ZONE::NODE。

注意

默认情况下，这是一个仅管理员操作，尽管您可以使用 policy.yaml 中的 os_compute_api:servers:create:forced_host 规则来修改此行为。

但是，如 之前 讨论的那样，以这种方式启动实例时，调度器过滤器不会运行。出于这个原因，这种行为被认为是遗留行为，并且从 2.74 微版本开始，现在可以显式地指定主机或节点。例如

$ openstack --os-compute-api-version 2.74 server create \
    --host HOST --hypervisor-hostname HYPERVISOR ... SERVER

注意

默认情况下，这是一个仅管理员操作，尽管您可以使用 policy.yaml 中的 compute:servers:create:requested_destination 规则来修改此行为。

这避免了显式选择可用区的需要，并确保调度器过滤器不会被绕过。

用法

创建可用区 (AZ) 是通过将元数据与 主机聚合 关联来完成的。因此，openstack 客户端提供了一种在一个命令中创建主机聚合并将其与 AZ 关联的能力。例如，要创建一个新的聚合，在创建过程中将其与 AZ 关联，并使用 openstack 客户端向其中添加主机，请运行

$ openstack aggregate create --zone my-availability-zone my-aggregate
$ openstack aggregate add host my-aggregate my-host

注意

虽然可以将主机添加到多个主机聚合，但无法将其添加到多个可用区。尝试将主机添加到与不同可用区关联的多个主机聚合会导致失败。

或者，您可以手动为现有的主机聚合设置此元数据。例如

$ openstack aggregate set \
    --property availability_zone=my-availability-zone my-aggregate

要列出所有主机聚合并显示有关特定聚合的信息，以便确定主机聚合属于哪个 AZ，请运行

$ openstack aggregate list --long
$ openstack aggregate show my-aggregate

最后，要将主机聚合与可用区分离，请运行

$ openstack aggregate unset --property availability_zone my-aggregate

配置

有关配置主机聚合和可用区的更多信息，请参阅 主机聚合。