openstack之nova-conductor工作原理及常见问题处理

openstack之nova-conductor工作原理及常见问题处理

一、简介

1. 概念

1. Nova和Swift是OpenStack最早的两个组件。Nova包括控制节点和计算节点。

   • Nova: 负责虚拟机的管理和调度。
   • Swift: 提供对象存储服务。

2. 计算节点通过Nova Compute创建虚拟机，使用libvirt调用KVM虚拟机。Nova之间的通信通过RabbitMQ队列进行。

   • Nova Compute: 负责处理计算资源的虚拟机生命周期。
   • libvirt: 管理和监控虚拟化技术（如KVM）的API库。
   • RabbitMQ: 消息队列系统，用于不同组件之间的通信。

3. Nova位于OpenStack架构的核心位置，其他服务和组件（如Glance、Cinder、Neutron等）为其提供支持。此外，Nova本身的架构也较为复杂。

   • Glance: 提供虚拟机镜像服务。
   • Cinder: 提供块存储服务。
   • Neutron: 提供网络连接服务。

2. 作用

1. Nova是OpenStack最核心的服务模块，负责管理和维护云计算环境中的计算资源，管理整个云环境中虚拟机的生命周期。

   • 计算资源管理: 包括CPU、内存等资源的分配和调度。
   • 生命周期管理: 包括虚拟机的创建、启动、停止、重启、销毁等操作。

2. Nova作为OpenStack的计算服务，维护和管理网络与存储资源，提供计算服务。

   • 网络管理: 与Neutron合作，提供虚拟机的网络连接。
   • 存储管理: 与Cinder和Swift合作，提供虚拟机的持久化存储。

3. 体系结构

二、组件

1. nova-api

• 功能: 实现RESTful API功能，是外部访问Nova的唯一途径。接收外部请求，并通过消息队列将请求发送给其他服务组件，同时兼容EC2 API，可以用EC2管理工具对Nova进行管理。

2. nova-scheduler

• 功能: 决策虚拟机创建在哪个主机（计算节点）上。调度步骤包括：

  • 过滤（filter）: 过滤出可以创建虚拟机的主机。

    

  • 计算权值（weight）: 根据权重大小进行分配，默认根据资源可用空间进行权重排序。

    

3. nova-compute

• 功能: 负责虚拟机的生命周期管理，创建并终止虚拟机实例的后台程序hypervisor API。

4. nova-conductor

• 功能: 计算节点访问数据的中间件，连接nova-compute服务和数据库，消除对数据库的直接访问。

5. nova-api-metadata

• 功能: 从实例中接收元数据请求，通常在nova-network安装时使用多宿主模式运行。

6. nova-placement-api

• 功能: 跟踪每个计算资源提供者的库存和使用情况。

7. nova-consoleauth

• 功能: 用于控制台的授权验证，授权控制台代理提供的用户令牌，确保控制台代理正常工作。

8. Queue

• 功能: 在守护进程之间传递消息的中心，通常使用RabbitMQ，也可以使用其他基于AMQP的消息队列，例如ZeroMQ。

三、工作流程

1. 用户通过RESTful API向Keystone获取认证信息。
2. Keystone认证用户请求，成功后生成token返回。
3. 用户通过RESTful API向nova-api发送创建虚拟机请求（携带token）。
4. nova-api向Keystone发送认证请求，验证token。
5. Keystone验证token，返回认证结果和角色权限。
6. nova-api检查创建虚拟机参数的有效性，并与数据库通信。
7. 初始化新建虚拟机的数据库记录。
8. nova-api通过rpc.call向nova-scheduler请求资源（Host ID）。
9. nova-scheduler侦听消息队列，获取请求。
10. nova-scheduler查询数据库中的计算资源，通过调度算法选定主机。
11. nova-scheduler更新虚拟机对应的物理主机信息。
12. nova-scheduler通过rpc.cast向nova-compute发送创建虚拟机请求。
13. nova-compute从消息队列获取请求。
14. nova-compute通过rpc.call向nova-conductor请求虚拟机信息。
15. nova-conductor获取请求消息。
16. nova-conductor查询虚拟机信息。
17. nova-conductor从数据库获取虚拟机信息。
18. nova-conductor将虚拟机信息发送到消息队列。
19. nova-compute从消息队列获取虚拟机信息。
20. nova-compute通过Keystone的RESTful API获取认证token，请求glance-api获取镜像。
21. glance-api验证token，返回结果。
22. token验证通过，nova-compute获取镜像信息。
23. nova-compute通过Keystone的RESTful API获取认证token，请求neutron-server获取网络信息。
24. neutron-server验证token，返回结果。
25. token验证通过，nova-compute获取网络信息。
26. nova-compute通过Keystone的RESTful API获取认证token，请求cinder-api获取持久化存储信息。
27. cinder-api验证token，返回结果。
28. token验证通过，nova-compute获取持久化存储信息。
29. nova-compute根据instance信息调用虚拟化驱动创建虚拟机。

四、常用操作

1. 生命周期和虚拟机管理

• 虚拟机创建: 使用nova-api发送请求，nova-scheduler选择合适的计算节点，nova-compute创建虚拟机。
• 虚拟机删除: 通过nova-api发送删除请求，nova-compute删除虚拟机实例。
• 虚拟机重启: 通过nova-api发送重启请求，nova-compute重启虚拟机实例。

2. 云主机类型和安全组管理

• 云主机类型: 定义不同规格的虚拟机类型，如不同的CPU、内存和存储配置。
• 安全组管理: 通过定义安全组规则来控制虚拟机的网络访问。

3. 网络、浮动IP、密钥和配额管理

• 网络管理: 使用Neutron创建和管理虚拟网络，分配IP地址。
• 浮动IP: 分配浮动IP地址，使虚拟机能够通过外部网络访问。
• 密钥管理: 通过密钥对管理虚拟机的SSH访问。
• 配额管理: 设定每个用户或项目可以使用的资源上限，如虚拟机数量、CPU核数、内存大小等。

五、日常问题

1、异常现象

1、有时候后端底层数据库异常或者mq消息异常，均会导致如下问题：

   code 1003, Transaction error, need to rollback.closed connection:sql timeout con:MySqlConnection 

024-08-02 09:39:40.985 22 ERROR oslo_messaging.rpc.server InternalError: (pymysql.err.InternalError) (1003, u"Transaction error, need to rollback.closed connection:sql timeout con:MySQLConnection [id=14861, lastTime=1722561794223, lastWriteTime=1722561794243, lastReadTime=1722561794243, user=nova, schema=nova, old shema=nova, borrowed=true, fromSlaveDB=false, threadId=29095, charset=utf8, txIsolation=3, autocommit=false, attachment=[sql=SHOW VARIABLES LIKE 'sql_mode', commit:false], respHandler=io.mycat.backend.mysql.nio.handler.RollbackNodeHandler@488f88d6, host=node-0.svc-in.mysql-hfd0-afjw1w, port=3306, statusSync=null, writeQueue=0]")
2024-08-02 09:39:40.985 22 ERROR oslo_messaging.rpc.server
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool [req-9cb61e30-0185-4309-9dc5-f38bd391fed5 - - - - -] Exception during reset or similar
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool Traceback (most recent call last):
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/pool.py", line 636, in _finalize_fairy
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     fairy._reset(pool)
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/pool.py", line 776, in _reset
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     pool._dialect.do_rollback(self)
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py", line 2542, in do_rollback
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     dbapi_connection.rollback()
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py", line 772, in rollback
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     self._read_ok_packet()
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py", line 746, in _read_ok_packet
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     pkt = self._read_packet()
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py", line 981, in _read_packet
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     packet.check_error()
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py", line 393, in check_error
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     err.raise_mysql_exception(self._data)
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool   File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line 107, in raise_mysql_exception
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool     raise errorclass(errno, errval)
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool InternalError: (1105, u'receive rollback,but find backend con is closed or quit')
2024-08-02 09:39:41.746 22 ERROR sqlalchemy.pool.QueuePool

2、解决方案

• 需要先检查常规配置

解决 MySQL 事务超时和连接关闭错误

错误描述

错误日志表明在处理事务时发生了超时，导致连接关闭，事务需要回滚。这涉及多个层面，包括数据库配置、连接池配置以及应用程序代码。

可能的原因

1. MySQL 连接超时：由于长时间未使用，连接超时。
2. 事务超时：事务未在规定时间内完成。
3. 连接池配置不当：SQLAlchemy 连接池配置不当，导致连接管理问题。
4. 网络问题：网络不稳定，导致连接关闭。

解决方案

1. 检查和调整 MySQL 配置

1. 增加连接超时时间：

   SET GLOBAL wait_timeout = 28800;
   SET GLOBAL interactive_timeout = 28800;
   

2. 增加事务超时时间：

   SET GLOBAL innodb_lock_wait_timeout = 50;
   

2. 调整 SQLAlchemy 连接池配置

在 SQLAlchemy 中，可以配置连接池的参数以更好地管理连接。以下是一些可能的配置：

from sqlalchemy import create_engine

engine = create_engine(
    'mysql+pymysql://user:password@host/dbname',
    pool_size=10,           # 池中保持的连接数
    max_overflow=20,        # 当池中连接数用完时，可以额外创建的连接数
    pool_timeout=30,        # 等待获取连接的超时时间（秒）
    pool_recycle=3600,      # 连接在池中保持的最长时间（秒）
    pool_pre_ping=True      # 每次获取连接前测试连接是否可用
)

3. 在代码中增加异常处理和重试逻辑

在应用程序代码中，添加异常处理逻辑，以便在发生错误时进行回滚和重试。例如，使用 Python 和 SQLAlchemy 的示例：

from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
from sqlalchemy.exc import SQLAlchemyError

# 创建数据库引擎
engine = create_engine('mysql+pymysql://user:password@host/dbname')
Session = sessionmaker(bind=engine)

def execute_transaction():
    session = Session()
    try:
        # 开始事务
        session.begin()

        # 执行你的SQL操作
        # session.execute("YOUR SQL QUERY HERE")

        # 提交事务
        session.commit()
    except SQLAlchemyError as e:
        # 出现错误，回滚事务
        session.rollback()
        print(f"Transaction error: {e}")
        # 根据需要在这里添加重试逻辑
    finally:
        session.close()

execute_transaction()

4. 优化 SQL 查询

• 确保查询高效，避免长时间运行。
• 使用索引优化查询。
• 避免长时间占用数据库连接。(这个是触发本问题的主要原因，很多长链接)

但是对于线上环境该问题若不及时解决会导致各个api异常，最终集群请求处于崩塌状态。
如下是临时解决该问题的办法：

3、优化 Nova 和 MySQL 之间安全通道

在 OpenStack 中，Nova-Conductor 是 Nova 和数据库之间的安全通道。当 Nova 和 MySQL 之间出现问题时，首先需要确保 Nova-Conductor 服务正常运行。以下是详细的优化步骤：

1. 关闭集群新建入口

为了防止新请求进入集群，首先关闭集群的新建入口。

2. 确认 VIP（虚拟 IP）所在节点

确保你知道 VIP 当前在哪个节点上运行。VIP 是高可用配置中的关键，通常在控制节点之间切换。

3. 停止备节点的 Nova-Conductor 服务

在三个控制节点的集群中，先停止备节点的 Nova-Conductor 服务。

# 在备节点上停止 nova-conductor
sudo docker stop nova-conductor

4. 清理 RabbitMQ 消息队列

清理消息队列中的残留消息，确保消息队列处于干净状态。

# 清理 RabbitMQ 消息队列
rabbitmqctl  list_queues  | egrep 'reply|cinder|conduct|compute' | awk '{ print $1}'  | xargs -P 30  -I {} rabbitmqctl purge_queue {}

5. 启动 VIP 节点上的 Nova-Conductor 服务

在 VIP 所在的节点上启动 Nova-Conductor 服务。

# 在 VIP 节点上启动 nova-conductor
sudo docker  start nova-conductor

6. 观察 Nova-Conductor 日志

持续观察 Nova-Conductor 日志，确保服务正常运行，没有异常错误。

# 查看 nova-conductor 日志
tail -f  /var/lib/docker/volumes/kolla_logs/_data/nova/nova-conductor.log

7. 重启 Nova-API 服务

在 VIP 节点上重启 Nova-API 服务，将缓冲刷到 Memcache 中。

# 重启 nova-api 服务
sudo docker  restart nova-api

8. 等待 2-3 分钟

等待 2-3 分钟，确保缓冲数据正确写入 Memcache 中。

9. 灰度恢复备节点的 Nova-Conductor 服务

逐步恢复其他两个备节点的 Nova-Conductor 服务。每次恢复一个节点，并观察其日志，确保没有异常错误。

# 在备节点上启动 nova-conductor
sudo docker start nova-conductor

总结

通过以上步骤，确保 Nova 和 MySQL 之间的安全通道正常，解决由于 Nova-Conductor 引起的连接问题：

1. 关闭集群新建入口。
2. 确认 VIP 所在节点。
3. 停止备节点的 Nova-Conductor 服务。
4. 清理 RabbitMQ 消息队列。
5. 启动 VIP 节点上的 Nova-Conductor 服务。
6. 观察 Nova-Conductor 日志。
7. 重启 Nova-API 服务。
8. 等待 2-3 分钟。
9. 灰度恢复备节点的 Nova-Conductor 服务。

通过这些步骤，可以有效解决由于 Nova-Conductor 引起的连接问题，确保 OpenStack 集群的稳定运行。