多可用区支持¶

https://blueprints.launchpad.net/blazar/+spec/multi-freepools

支持多个可用区，并允许用户在知晓可用区的情况下预留主机和实例。

问题描述¶

Blazar 管理 freepool 中注册的主机以进行预留。 freepool 目前不考虑 Nova 的可用区 (az)。所有主机都属于一个 freepool，并且可以从 Nova 中的不同可用区选择为预留选择的主机。此外，用户在创建预留时无法指定预留的主机/实例所属的可用区。

用例¶

用户希望在单个可用区中预留实例以部署软件集群。
用户希望由于可用区的位置原因，在特定可用区中预留主机。

提议的变更¶

此 BP 允许用户在主机预留和实例预留中指定可用区。如果用户在其请求中指定了可用区，Blazar 将选择属于指定可用区的主机。否则，Blazar 将像往常一样选择主机。有关 API 变更的详细信息，请阅读 Rest API 影响部分。

当操作员通过创建主机 API 注册主机时，Blazar 会记录主机所属的原始可用区信息。可用区信息来自 Nova 的服务列表 API。

为了向后兼容，此 BP 在 utils.openstack.nova.py 中引入了一个新的配置，“az_aware”。如果为 False，Blazar 将像以前一样处理预留请求。如果为 True，Blazar 将跟踪每个主机的可用区。

备选方案¶

多 freepool 方法¶

Blazar 管理多个 freepool，每个 freepool 与每个可用区一一映射。然后，如果需要，用户在预留资源时指定一个 freepool。

这种方法也可以支持多个可用区。但是，Blazar 需要引入新的 API 集来创建可用区和 freepool 之间的一对一映射。该 API 集增加了额外的任务，即操作员在调用创建主机 API 之前定义映射。

ComputeExtraCapability 方法¶

操作员将可用区信息定义为 ComputeExtraCapability，以启用用户在创建预留时指定可用区。

这种方法的优点是不需要更改 Blazar 的 API 和配置，因为操作员只需调用现有的 API 来创建 extra_capability 键值对。

缺点是，如果 Blazar 自动将可用区信息存储到 ComputeExtraCapability，这不是一个好的存储位置，因为 ComputeExtraCapability 是一个用于存储操作员指定数据的表，而 ComputeHost 是一个用于存储 Blazar 查询数据的表。

数据模型影响¶

在 ComputeHost 表中添加一个 availability_zone 列。此列存储主机所属的可用区。

ALTER TABLE computehosts ADD
    availability_zone VARCHAR(255) AFTER status;

从 Pike 升级到更高版本时，该列将被赋值为 NULL。

REST API 影响¶

URL: POST /v1/leases
- physical:host 中的 hypervisor_properties 和 virtual:instance 中的 resource_properties 支持查询 availability_zone 键。

请求示例

{
  "name": "instance-reservation-1",
  "reservations": [
    {
      "resource_type": "virtual:instance",
      "vcpus": 4,
      "memory_mb": 4096,
      "disk_gb": 10,
      "amount": 5,
      "affinity": False,
      "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]"
    },
    {
      "resource_type": "physical:host",
      "min": 3,
      "max": 4,
      "hypervisor_properties": "[]",
      "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]"
    }
   ],
  "start": "2020-05-17 09:00"
  "end": "2020-05-17 10:00",
  "events": []
}

响应示例

{
  "leases": {
    "reservations": [
      {
        "id": "reservation-id",
        "status": "pending",
        "lease_id": "lease-id-1",
        "resource_id": "resource_id",
        "resource_type": "virtual:instance",
        "vcpus": 4,
        "memory_mb": 4096,
        "disk_gb": 10,
        "amount": 5,
        "affinity": False,
        "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]",
        "created_at": "2017-05-01 10:00:00",
        "updated_at": "2017-05-01 11:00:00",
      }],
   ..snippet..
  }
}

URL: GET /v1/leases
URL: GET /v1/leases/{lease-id}
URL: PUT /v1/leases/{lease-id}
URL: DELETE /v1/leases/{lease-id}
- 更改与 POST /v1/leases 相同

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

超visor 属于的原始可用区名称仅通过 Blazar API 可见。 Nova 根据主机聚合的元数据返回可用区名称，Blazar 将 blazar_* 可用区名称设置为主机预留的聚合。这导致用户需要调用 Blazar 主机详细信息 API 才能知道“availability_zone”键中可用的可用区值。

在大多数情况下，只有管理员才能在 Nova 中配置可用区。管理员/云提供商/云部署者会告知最终用户可用区名称列表。因此，上述影响对最终用户的影响较小。

性能影响¶

无

其他部署者影响¶

在升级 Blazar 时，availability_zone 列将填充为 NULL。如果部署者将 az_aware 标志设置为 True，他们需要在升级后重新创建 Blazar 的 freepool 中注册的所有主机，以将可用区信息存储到 computehost 表中。如果主机用于主机预留，Blazar 在部署者升级 Blazar 时无法找到原始可用区信息。

如果部署者通过 Nova API 将主机移动到另一个可用区，则部署者需要通过 Blazar 主机创建 API 重新创建主机，以将新的可用区应用于 Blazar DB。该信息仅在 Blazar 主机创建 API 中自动注册。

开发者影响¶

无

实现¶

负责人¶

主要负责人: muroi-masahito
其他贡献者: 无

工作项¶

在 computehosts 表中添加 availability_zone 列
在创建主机 API 中实现 availability_zone 支持
在 blazarclient 中支持 availability_zone 标志

依赖项¶

无

测试¶

单元测试

文档影响¶

API 参考

参考资料¶

无

历史记录¶

修订版¶
发布名称	描述
Queens	引入
Rocky	重新提出

多可用区支持