将风味数据从系统元数据移动到blob

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/nova/+spec/flavor-from-sysmeta-to-blob

目前风味数据以非效率的方式存储在system_metadata中，应该将其移动到实例对应的合适位置的blob中存储。这将有助于存储我们迫切需要的额外风味细节，例如extra_specs。

问题描述

目前，我们存储一些用于启动实例的风味属性在实例的system_metadata区域中。我们通过像这样命名空间化风味键来实现

键

值

instance_type_flavorid

‘foo’

instance_type_memory_mb

‘1024’

这意味着所有内容都被字符串化，并且每个键和值都限制在255个字符内。它也使得存储复杂的风味属性非常困难，例如extra_specs，这最近对于NUMA和PCI直通等事情变得越来越重要。如果无法将这些值与其余风味信息一起存储，则重新调度或迁移实例需要使用原始风味数据（存储在实例中）以及附加到风味上的当前值的组合。

最后，在调整大小操作期间，我们将所有这些数据的两个额外副本分别存储用于旧风味和新风味，全部在system_metadata中。由于system_metadata是单行键值布局，这意味着在调整大小期间，每个实例都会得到很多行。过去，这导致实例查询与system_metadata查询分离，因为与system_metadata连接的多实例查询会使已经很大的结果膨胀大约30倍。

用例

  • 作为操作员，我希望能够迁移我的实例，并使重新调度过程尊重我提供过的所有原始信息，例如CPU和NUMA布局以及PCI直通细节。

  • 作为操作员，我希望数据库查询高效，在带宽和延迟方面都是如此。连接大型表和执行多个查询会损害这一目标。

项目优先级

这个重构已经成为几个周期的项目重点，符合“稳定性”和“减少技术债务”这两个目标。

提议的变更

自从我们开始将风味数据存储在system_metadata中后不久，我们就一直在讨论将其移动到数据库中合适位置的JSON blob中。在Juno后期，我们添加了一个名为“instance_extra”的表，专门用于保存每个实例所需的其他JSON blob，这些blob在不同的时间需要。此规范建议向该表添加另一列“flavor”，我们将在其中存储初始启动时风味数据的JSON化副本。此外，我们将提供存储“old”和“new”风味，以方便调整大小操作。顶层结构如下所示

{'cur': { ... serialized Flavor object ... }
 'new': None,
 'old': None,
}

当风味存储在上述三个插槽之一中时，使用的格式将是序列化的NovaObject结果。这意味着数据库中的内容将被版本化，并且从数据库中反序列化它将像通过RPC接收它一样工作。

此更改的数据库迁移将简单地添加新列，但不会执行数据迁移。相反，从system_metadata到instance_extra的迁移将由对象层管理。对象代码将处理尊重system_metadata风味数据（如果存在），否则使用instance_extra中的新格式。在保存操作期间，system_metadata区域将被清除任何风味数据，此时实例将完全迁移。

备选方案

  • 我们可以继续做我们正在做的事情，向风味存储代码添加额外的技巧来保留我们需要的extra_specs的片段

  • 我们可以移动到持久化更多的request_spec结构，这必然包括风味数据，如这里所建议：https://review.openstack.org/#/c/125484/1。我的感觉是，当我们开始在内部建模更多作为任务时，我们将拥有更好的基础，并且此规范中选择的方法至少是一个值得的中间步骤。

数据模型影响

这将向instance_extra表添加一个新的TEXT列，并且数据将从system_metadata迁移到该列，因为实例被使用。

此外，需要编写一个工具来执行对不更改的实例的离线迁移，以允许操作员确保休眠实例也能获得数据迁移，而不仅仅是活动实例。

Instance对象将获得三个新属性：“flavor”、“old_flavor”和“new_flavor”。这些将在各种查询的“expected_attributes”参数中被尊重，并且将在适当的时候包含一个nova.objects.Flavor对象。

REST API 影响

此更改对用户不产生可见影响。

安全影响

无。

通知影响

无。

其他最终用户影响

无。

性能影响

在所有风味数据都从system_metadata移动出来后，我们可以考虑返回在查询实例时连接system_metadata。这将消除一次DB命中并可能提高延迟。

此外，对象层将支持风味数据的条件加载，允许需要system_metadata但不需要所有风味数据的代码请求更细粒度的响应。

其他部署者影响

部署者需要采取行动以确保休眠实例在删除支持system_metadata中风味的兼容性代码之前获得数据迁移。这应该可以在正在运行的部署的后台运行，因此操作员的影响主要是程序性的。

开发人员影响

对象层应该在很大程度上向普通开发人员隐藏复杂的迁移活动。但是，人们需要意识到，通过Instance.flavor对象访问实例的风味信息是未来必要的。

实现

负责人

主要负责人

danms

工作项

  • 清理现有的instance_extra接口以保持一致性，将pci_requests移动到Instance上的正确字段，等等。

  • 向instance_extra添加flavor列

  • 向Instance添加三个flavor字段

  • 修改Instance对象和instance_* DB API函数以处理与system_metadata中存储的风味的兼容性和迁移

  • 编写一个工具来在后台迁移不活动的实例，位于nova/tools目录中

依赖项

这主要是孤立的工作。但是，其他工作可能依赖于此。

测试

将提供涵盖在线数据迁移代码的单元测试，并且应该相对简单。此外，gate中的现有grenade测试应该涵盖现有实例的数据迁移情况，以及保证在Juno代码运行的计算节点上进行此迁移不会破坏计算节点。

文档影响

需要在发布说明中记录这一事实的一些文档。此外，需要将一些关于迁移休眠实例数据程序的文档集成到描述从Juno到Kilo的迁移的任何文档中。

参考资料