2024-06-10 - Alex Song (Inspur IncloudOS)

本文档讨论了在 Inspur IncloudOS 云平台上管理 3000 个计算节点时遇到的延迟和超时问题。经过深入调查和优化，云平台的请求延迟和服务响应超时问题得到了缓解，满足了大规模场景下虚拟机并发创建和管理的需求。

问题描述

服务启动失败

  1. Nova-api 无法连接到数据库。

  2. Nova-api 无法创建线程。

  3. Rabbitmq 服务自动重启。

虚拟机并发创建失败

  1. Rabbitmq 消息过载

  2. 指定节点创建虚拟机

  3. Nova 等待端口创建超时

  4. Ovsdb 事务重复提交导致端口创建失败。

优化方法

  1. 增加数据库连接数和内存限制

我们通过增加数据库连接数 max_connections 和数据库内存限制 thread_cache_size，确保数据库服务正常启动，并且 OpenStack 服务可以申请到足够的数据库连接。

[DEFAULT]
max_connections = 100000
thread_cache_size = 10000

  1. 优化消息中间件 Rabbitmq 配置

Rabbitmq 服务自动重启。我们发现存在持续的 noproc 和 handshake_timeout 日志。通过调整最大连接数并增加握手时间配置，问题不再发生。

[DEFAULT]
maximum=20000

RabbitMQ 的最大连接数通过计算 nova 和 cinder 组件的连接数来估算。我们有 3000 个计算节点，3 个控制节点和 15 个 cinder-volume 节点，我们在控制节点上部署 rabbitmq 并使用主从模式，RabbitMQ 的总连接数接近 2w，因此我们将 RabbitMQ 配置设置为 2w。

  1. 减少 Rabbitmq 消息积压。

在 Nova-condutor 服务中等待消息确认的过程中，Rabbitmq 的连接未被释放，其他协程无法获取连接，导致消息积压。我们通过修改代码、调整消息超时机制和增加超时持续时间来降低消息积压的风险。

  1. 增加 Placement 返回的分配候选数量

失败的原因是 Nova 向 Placement 发送请求以获取 RP 列表，最大限制为 1000，并且环境中的计算节点数量超过 1000，一些主机将不会返回，导致调度失败。通过修改 nova scheduler 下的 max_placement_result 配置项来解决此问题。

[scheduler]
max_placement_result = 3000

我们尝试在一个请求中创建 3k 个实例，Placement 默认返回 1000 个分配候选，因此我们需要将限制增加到 3000。

  1. 解决端口创建超时问题

通过每个控制节点部署 10 个 relay SB 服务来更改 OVN SB 的部署方法，并且计算节点可以连接到单个 relay 服务以减少端口创建时间。在部署 SB relay 之前，每个 ovn SB 进程需要管理平均 600 多个连接，CPU 使用率通常为 100%，并且请求处理缓慢。添加 relay 后，每个 relay 进程处理大约 60 个连接，总 relay 进程设置为 10。经过测试，每个 relay 进程的 CPU 使用率较低，并且可以快速处理信息。

  1. 部署优化

我们修改了基于 OpenStack helm 的 Ansible 模块，以支持用户自定义配置，从而更方便地修改 OpenStack 配置参数。此外，我们优化了大规模场景下 Kubeapi 的负载均衡问题，调整了 Kubelet 客户端的长连接策略，使其随机重新连接，并确保所有管理节点的整体负载均衡。

优化性能

  1. 3000 个虚拟机并发创建的成功率是 100%。

  2. 查询 50000 个虚拟机耗时 562.44 毫秒。

3. 2000 个并发端口可以 100% 成功创建，平均每个端口的创建时间小于 0.2 秒。