跨单元格调整大小¶
历史上，调整大小和冷迁移服务器已被明确限制在服务器已经存在的同一单元格内。跨单元格调整大小功能允许配置 nova 以允许跨单元格调整大小和冷迁移服务器。
完整的设计细节在Ussuri 规范中，并且有一个视频来自峰会演讲，提供了一个高级概述。
用例¶
在 nova 部署中，除了扩展数据库和消息队列之外，还有许多理由使用多个单元格。单元格还可以用于按硬件代和功能分片部署。在按硬件代分片时，为每个单元格设置主机聚合并将风味映射到聚合是自然而然的。然后，当需要退役旧硬件时，部署者可以提供新的风味并要求用户在某个截止日期之前调整到新的风味，这将在底层将他们的服务器迁移到具有较新硬件的新单元格。管理员也可以在维护窗口期间将服务器冷迁移到新单元格。
需求¶
要启用跨单元格调整大小功能，必须满足以下条件。
最低计算版本¶
所有计算服务必须升级到 21.0.0 (Ussuri) 或更高版本，并且不得在upgrade_levels.compute中固定到较旧的 RPC API 版本。
策略配置¶
策略规则 compute:servers:resize:cross_cell 控制谁可以执行跨单元格调整大小或冷迁移操作。默认情况下，该策略会为所有用户禁用该功能。不需要微版本来选择加入该行为，只需通过策略检查即可。因此，建议首先仅允许某些用户能够执行跨单元格调整大小或冷迁移，例如通过将规则设置为 rule:admin_api 或其他规则用于测试团队，但不用于普通用户，直到您确信可以支持该功能为止。
计算驱动程序¶
不需要特殊的计算驱动程序实现来支持该功能，它建立在调整大小和搁置/取消搁置期间使用的现有驱动程序接口之上。但是，只有 libvirt 计算驱动程序在 nova-multi-cell CI 作业中具有集成测试。
网络¶
网络 API 必须公开 Port Bindings Extended API 扩展，该扩展是在 Neutron 的 13.0.0 (Rocky) 版本中添加的。
通知¶
事件的类型及其有效负载保持不变。与同单元格调整大小的主要区别在于，在某些情况下，发布者 ID 可能不同，因为某些事件是从调度服务而不是计算服务发送的。例如，对于同单元格调整大小，instance.resize_revert.start 通知是从源计算主机在 finish_revert_resize 方法中发送的，但对于跨单元格调整大小，相同的通知是从调度服务发送的。
显然，发送通知的消息队列对于源单元格和目标单元格来说将是不同的，假设它们使用单独的传输。
实例操作¶
名为 resize、confirmResize 和 revertResize 的整体实例操作与同单元格调整大小相同。但是，构成这些操作的事件对于跨单元格调整大小将是不同的，因为事件名称是根据参与操作的计算服务方法生成的，而跨单元格调整大小涉及不同的方法。这对于在跨单元格调整大小操作失败时进行分类非常重要。
调度¶
默认情况下启用 CrossCellWeigher。当调度请求允许从另一个单元格中选择计算节点时，该称重器默认情况下会优先选择源单元格中的主机而不是来自另一个单元格的主机。但是，可以使用 filter_scheduler.cross_cell_move_weight_multiplier 配置选项来配置此行为，例如，如果您想在调整大小或冷迁移时清空旧单元格。
代码流程¶
最终用户体验应该不会改变，即状态转换。成功跨单元格调整大小的服务器将进入 VERIFY_RESIZE 状态，然后用户可以使用正常的 confirmResize 和 revertResize 服务器操作 API 来确认或撤销调整大小的服务器。
在底层，与传统的同单元格调整大小相比，存在一些差异
没有计算服务之间的交互。一切都由 (super) 调度服务同步 编排。这使用了
long_rpc_timeout配置选项。(super) 调度服务中的编排任务负责在操作开始时在目标单元格数据库中创建实例及其相关记录的副本，在回滚或确认/撤销调整大小后删除它们，以及更新 API 数据库中的
instance_mappings表记录。非卷备份的服务器会将它们的根磁盘上传到镜像服务作为临时快照镜像，就像在 shelveOffload 操作期间一样。在目标单元格中的目标主机上完成调整大小后，将使用该快照镜像来启动客户机，然后将删除该快照镜像。
序列图¶
以下图表是 21.0.0 (Ussuri) 版本时的最新图表。
调整大小¶
这是将服务器置于 VERIFY_RESIZE 状态的调用序列。
确认调整大小¶
这是在确认 或删除 VERIFY_RESIZE 状态中的服务器时的调用序列。
撤销调整大小¶
这是在撤销 VERIFY_RESIZE 状态中的服务器时的调用序列。
限制¶
已知代码中尚未支持以下内容
具有连接端口的实例，这些端口具有 带宽感知 资源提供程序分配。如果服务器具有此类端口，Nova 将回退到同单元格调整大小。
在主要选择的主机失败
prep_snapshot_based_resize_at_dest调用时，重新调度到同一目标单元格中的替代主机。
这些可能无法工作，因为它们尚未通过集成测试进行验证
具有连接的 PCI 设备的实例。
具有 NUMA 拓扑的实例。
其他限制
与服务器关联的 config drive（如果有的话）将在目标单元格中的目标主机上重新生成。因此，如果服务器使用 个性化文件 创建，则会丢失这些文件。但是，这与 撤离 具有 config drive 的服务器时的情况相同，此时源主机和目标主机不在共享存储上，或者在具有 config drive 的服务器上搁置和取消搁置时的情况相同。如果需要，可以重建调整大小的服务器以重新获得个性化文件。
可以
配置的_poll_unconfirmed_resizes定期任务，该任务可以自动确认目标主机上待处理的调整大小，可能不支持跨单元格调整大小，因为这样做需要向 API 进行 上行调用 以确认调整大小并清理源单元格数据库。
故障排除¶
超时¶
配置一个 服务用户，以防用户令牌超时，例如在快照和下载大型服务器镜像期间。
如果日志中出现 MessagingTimeout 错误，请检查 long_rpc_timeout 选项，查看它是否足够高，尽管默认值（30 分钟）应该足够了。
从故障中恢复¶
驱动操作的调度任务具有回滚功能，因此操作的每个部分都可以在后续任务失败时回滚。
需要记住的是，API DB 中的 instance_mappings 记录是实例“存在”的权威，API 将去那里显示实例在 GET /servers/{server_id} 调用或对服务器执行的任何操作（包括删除它）中。
因此，如果调整大小失败并且目标单元格中存在实例及其相关记录的副本，则任务应自动删除它们，但如果未删除，则可以从不在 instance_mappings 表中的单元格中硬删除记录。
如果实例处于 ERROR 状态，请检查源计算服务和目标计算服务中的日志，查看是否有需要手动恢复的内容，例如卷附件或端口绑定，并检查 (super) 调度服务日志。假设卷附件和端口绑定正常（当前指向正确的主机），则尝试硬重启服务器以使其恢复到 ACTIVE 状态。如果失败，您可能需要 在源主机上重建 服务器。请注意，在确认调整大小或确认调整大小本身失败之前，客户机磁盘不会从源主机中删除，因此如果在确认之前出现问题，则应仍然可以重建实例。
