使用 Ansible 库存进行扩展

https://blueprints.launchpad.net/tripleo/scaling-with-Ansible-inventory

通过直接将新的主机定义添加到 Ansible 库存，而无需增加 <Role>Count 参数，应该可以扩展现有的部署。

问题描述

目前，要扩展部署，需要更新 Heat 堆栈。堆栈更新反映了每个角色的新的期望节点数量，然后这些数量在生成的 Ansible 库存中表示。然后，在执行 ansible-playbook 时，config-download 过程使用库存文件来对每个节点执行软件配置。

使用新的期望节点数量更新 Heat 堆栈带来了一些扩展方面的挑战。Heat 会为每个节点创建一组资源。随着部署中节点数量的增加，Heat 需要管理的资源也越来越多。

随着堆栈大小的增长，必须通过软件配置调整 Heat，或通过增加引擎工作器进行水平扩展。但是，水平扩展 Heat 工作器只能在一定程度上有所帮助，因为最终需要扩展其他服务工作器，例如数据库、消息传递或 Keystone 工作器进程。越来越多的扩展工作器进程会导致额外的物理资源消耗。

随着堆栈大小的增加，Heat 的性能也会开始下降。随着节点数量的增加，堆栈操作完成所需的时间越来越长。堆栈操作时间通常会达到数小时，这通常超出了典型维护窗口的范围。

很难预测 Heat 会进行哪些更改。通常，除了扩展到新节点之外，不需要任何更改。但是，未预期的模板更改或用户在忘记传递环境文件方面的错误，给扩展操作带来了额外的、不必要的风险。

提议的变更

概述

拟议的更改将允许用户通过新的 Heat 参数直接将新的节点定义添加到 Ansible 库存，从而将服务扩展到这些新节点。不需要更改 <Role>Count 参数。

将新节点添加到 Ansible 库存时，需要最少的一组数据。目前，这包括 TripleO 角色以及每个角色使用的每个网络上的 IP 地址。

使用此方法只能扩展已经定义的角色。定义新角色仍然需要完整的 Heat 堆栈更新，该更新定义了新角色。

一旦将新节点添加到库存中，就可以使用 config-download 目录重新运行 ansible-playbook，将软件服务扩展到新节点上。

由于在扩展时不需要增加 Heat 堆栈中的节点数量，因此如果需要为新节点进行裸机配置，那么这项工作取决于 nova-less-deploy 工作

https://specs.openstack.org/openstack/tripleo-specs/specs/stein/nova-less-deploy.html

一旦通过上述工作将裸机配置迁移出 Heat，就可以在将其直接添加到 Ansible 库存之前，使用新的工作流程配置新节点。

由于直接添加到 Ansible 库存的新节点仍然会从为 overcloud 网络定义的子网范围内消耗 IP 地址，因此需要让 Neutron 了解这些分配，以避免 IP 地址重叠。这可以通过 tripleo-heat-templates 中的一个新接口来完成，该接口允许指定额外的节点库存数据。该参数将称为 ExtraInventoryData。模板将负责处理该输入并创建适当的 Neutron 端口，以对应于数据中指定的 IP 地址。

当使用 tripleo-ansible-inventory 生成库存时，它将像今天一样查询 Heat，但也会分层包含 ExtraInventoryData 指定的额外库存数据。生成的库存将是部署中所有节点的统一视图。

ExtraInventoryData 可以是 Heat 的 get_file 函数消耗的文件列表，以便部署者可以按文件组织其库存数据。

替代方案

此更改主要针对解决围绕 Heat 堆栈操作的扩展问题。替代方法包括使用 undercloud minions

https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/undercloud_minion.html

Multi-stack/split-controlplane 也通过将部署分解为更小、更易于管理的堆栈来解决这个问题

https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/distributed_compute_node.html

这些替代方案与此处提出的解决方案互补，并且所有这些解决方案可以结合使用以获得最大的好处。

直接操作库存数据

另一种替代方案是不使用模板中的任何新接口，例如前面提到的 ExtraInventoryData。用户可以直接更新库存文件，或将库存文件放到指定位置（因为 Ansible 可以将目录用作库存源）。

这种方法的缺点是需要另一个工具来创建关联的 Neutron 端口，以避免 IP 地址重叠。它也可能是一个手动步骤，虽然这容易出错。

这种方法的优点是它将完全消除堆栈更新操作作为扩展的一部分。在某些方面，不进行任何堆栈操作是有吸引力的，因为有可能忘记环境文件或其他用户错误（过时的模板等）。

安全影响

IP 地址和主机名可能存在于用户管理的模板中，这些模板具有 ExtraInventoryData 的值，但这与今天的情况没有区别。

升级影响

升级过程需要知道并非所有节点都表示在 Heat 堆栈中，而有些节点仅表示在库存中。只要存在一个一致的接口来获取单个统一的库存（如现在存在），这不应该成为问题。

对库存的统一视图进行任何更改都应在接口的实现中进行（tripleo-ansible-inventory），以便现有工具继续使用包含部署中所有节点的库存。

其他最终用户影响

用户可能需要管理额外的环境文件来获取额外的库存数据。

性能影响

扩展操作期间的性能应该得到改善。

但是，应该注意的是，Ansible 也将面临扩展方面的挑战。虽然此更改不会直接引入这些新的挑战，但它可能会更快地暴露这些挑战，因为它绕过了 Heat 的扩展挑战。

例如，仅仅将数百或数千个新节点直接添加到 Ansible 库存并不意味着扩展操作会成功。它可能会暴露其他工具（例如 playbook 和角色任务或 Ansible 本身）中的新的扩展挑战。

其他部署者影响

由于该提案旨在与 nova-less-deploy 保持一致，因此如果删除部署，所有节点（无论是否为 Heat 所知）都将被取消配置。

如果使用预配置节点，则删除 Heat 堆栈的行为不会发生任何变化，因为删除 Heat 堆栈实际上不会“取消部署”任何软件。该提案不会改变这种行为。

开发人员影响

如果需要，开发人员可以通过完全绕过 Heat 堆栈更新来更快地测试扩展，或者使用 ExtraInventoryData 接口。

实现

负责人

主要负责人

James Slagle <jslagle@redhat.com>

工作项

  • 添加新参数 ExtraInventoryData

  • 添加 Heat 处理 ExtraInventoryData

    • 创建 Neutron 端口

    • 添加堆栈输出

  • 更新 tripleo-ansible-inventory 以从添加的堆栈输出中获取

  • 更新 HostsEntry 以使其通用

依赖项

  • 取决于 nova-less-deploy 工作，用于在 Heat 之外进行裸机配置。如果使用预配置节点，则不依赖 nova-less-deploy。

  • 所有从 Heat 传出的部署配置都需要是每个角色的通用配置。这项工作的大部分内容是在 Train 中完成的，但是应该进行审查。例如，HostsEntry 数据仍然是静态的，Heat 正在计算节点列表。此数据需要移动到 Ansible 模板。

测试

目前 CI 中没有测试扩展，但是有了此更改，也许可以进行测试。

需要更新手动测试计划和其他测试自动化，以测试使用 ExtraInventoryData 进行扩展。

文档影响

需要添加 ExtraInventoryData 的文档。

该功能还应完全解释，以便让用户和部署者了解节点可能表示在 Heat 堆栈中的变化。

参考资料