openstack之nova-conductor工作原理及常见问题处理
这里写目录标题
-
- openstack之nova-conductor工作原理及常见问题处理
-
- 一、简介
-
- [1. 概念](#1. 概念)
- [2. 作用](#2. 作用)
- [3. 体系结构](#3. 体系结构)
- 二、组件
-
- [1. nova-api](#1. nova-api)
- [2. nova-scheduler](#2. nova-scheduler)
- [3. nova-compute](#3. nova-compute)
- [4. nova-conductor](#4. nova-conductor)
- [5. nova-api-metadata](#5. nova-api-metadata)
- [6. nova-placement-api](#6. nova-placement-api)
- [7. nova-consoleauth](#7. nova-consoleauth)
- [8. Queue](#8. Queue)
- 三、工作流程
- 四、常用操作
-
- [1. 生命周期和虚拟机管理](#1. 生命周期和虚拟机管理)
- [2. 云主机类型和安全组管理](#2. 云主机类型和安全组管理)
- [3. 网络、浮动IP、密钥和配额管理](#3. 网络、浮动IP、密钥和配额管理)
- 五、日常问题
-
- 1、异常现象
- 2、解决方案
- [3、优化 Nova 和 MySQL 之间安全通道](#3、优化 Nova 和 MySQL 之间安全通道)
-
-
- [1. 关闭集群新建入口](#1. 关闭集群新建入口)
- [2. 确认 VIP(虚拟 IP)所在节点](#2. 确认 VIP(虚拟 IP)所在节点)
-
- [3. 停止备节点的 Nova-Conductor 服务](#3. 停止备节点的 Nova-Conductor 服务)
- [4. 清理 RabbitMQ 消息队列](#4. 清理 RabbitMQ 消息队列)
- [5. 启动 VIP 节点上的 Nova-Conductor 服务](#5. 启动 VIP 节点上的 Nova-Conductor 服务)
- [6. 观察 Nova-Conductor 日志](#6. 观察 Nova-Conductor 日志)
- [7. 重启 Nova-API 服务](#7. 重启 Nova-API 服务)
- [8. 等待 2-3 分钟](#8. 等待 2-3 分钟)
- [9. 灰度恢复备节点的 Nova-Conductor 服务](#9. 灰度恢复备节点的 Nova-Conductor 服务)
-
- 总结
一、简介
1. 概念
-
Nova和Swift是OpenStack最早的两个组件。Nova包括控制节点和计算节点。
- Nova: 负责虚拟机的管理和调度。
- Swift: 提供对象存储服务。
-
计算节点通过Nova Compute创建虚拟机,使用libvirt调用KVM虚拟机。Nova之间的通信通过RabbitMQ队列进行。
- Nova Compute: 负责处理计算资源的虚拟机生命周期。
- libvirt: 管理和监控虚拟化技术(如KVM)的API库。
- RabbitMQ: 消息队列系统,用于不同组件之间的通信。
-
Nova位于OpenStack架构的核心位置,其他服务和组件(如Glance、Cinder、Neutron等)为其提供支持。此外,Nova本身的架构也较为复杂。
- Glance: 提供虚拟机镜像服务。
- Cinder: 提供块存储服务。
- Neutron: 提供网络连接服务。
2. 作用
-
Nova是OpenStack最核心的服务模块,负责管理和维护云计算环境中的计算资源,管理整个云环境中虚拟机的生命周期。
- 计算资源管理: 包括CPU、内存等资源的分配和调度。
- 生命周期管理: 包括虚拟机的创建、启动、停止、重启、销毁等操作。
-
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。
三、工作流程
- 用户通过RESTful API向Keystone获取认证信息。
- Keystone认证用户请求,成功后生成token返回。
- 用户通过RESTful API向nova-api发送创建虚拟机请求(携带token)。
- nova-api向Keystone发送认证请求,验证token。
- Keystone验证token,返回认证结果和角色权限。
- nova-api检查创建虚拟机参数的有效性,并与数据库通信。
- 初始化新建虚拟机的数据库记录。
- nova-api通过rpc.call向nova-scheduler请求资源(Host ID)。
- nova-scheduler侦听消息队列,获取请求。
- nova-scheduler查询数据库中的计算资源,通过调度算法选定主机。
- nova-scheduler更新虚拟机对应的物理主机信息。
- nova-scheduler通过rpc.cast向nova-compute发送创建虚拟机请求。
- nova-compute从消息队列获取请求。
- nova-compute通过rpc.call向nova-conductor请求虚拟机信息。
- nova-conductor获取请求消息。
- nova-conductor查询虚拟机信息。
- nova-conductor从数据库获取虚拟机信息。
- nova-conductor将虚拟机信息发送到消息队列。
- nova-compute从消息队列获取虚拟机信息。
- nova-compute通过Keystone的RESTful API获取认证token,请求glance-api获取镜像。
- glance-api验证token,返回结果。
- token验证通过,nova-compute获取镜像信息。
- nova-compute通过Keystone的RESTful API获取认证token,请求neutron-server获取网络信息。
- neutron-server验证token,返回结果。
- token验证通过,nova-compute获取网络信息。
- nova-compute通过Keystone的RESTful API获取认证token,请求cinder-api获取持久化存储信息。
- cinder-api验证token,返回结果。
- token验证通过,nova-compute获取持久化存储信息。
- 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
python
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 事务超时和连接关闭错误
错误描述
错误日志表明在处理事务时发生了超时,导致连接关闭,事务需要回滚。这涉及多个层面,包括数据库配置、连接池配置以及应用程序代码。
可能的原因
- MySQL 连接超时:由于长时间未使用,连接超时。
- 事务超时:事务未在规定时间内完成。
- 连接池配置不当:SQLAlchemy 连接池配置不当,导致连接管理问题。
- 网络问题:网络不稳定,导致连接关闭。
解决方案
1. 检查和调整 MySQL 配置
-
增加连接超时时间:
sqlSET GLOBAL wait_timeout = 28800; SET GLOBAL interactive_timeout = 28800;
-
增加事务超时时间:
sqlSET GLOBAL innodb_lock_wait_timeout = 50;
2. 调整 SQLAlchemy 连接池配置
在 SQLAlchemy 中,可以配置连接池的参数以更好地管理连接。以下是一些可能的配置:
python
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 的示例:
python
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 服务。
bash
# 在备节点上停止 nova-conductor
sudo docker stop nova-conductor
4. 清理 RabbitMQ 消息队列
清理消息队列中的残留消息,确保消息队列处于干净状态。
bash
# 清理 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 服务。
bash
# 在 VIP 节点上启动 nova-conductor
sudo docker start nova-conductor
6. 观察 Nova-Conductor 日志
持续观察 Nova-Conductor 日志,确保服务正常运行,没有异常错误。
bash
# 查看 nova-conductor 日志
tail -f /var/lib/docker/volumes/kolla_logs/_data/nova/nova-conductor.log
7. 重启 Nova-API 服务
在 VIP 节点上重启 Nova-API 服务,将缓冲刷到 Memcache 中。
bash
# 重启 nova-api 服务
sudo docker restart nova-api
8. 等待 2-3 分钟
等待 2-3 分钟,确保缓冲数据正确写入 Memcache 中。
9. 灰度恢复备节点的 Nova-Conductor 服务
逐步恢复其他两个备节点的 Nova-Conductor 服务。每次恢复一个节点,并观察其日志,确保没有异常错误。
bash
# 在备节点上启动 nova-conductor
sudo docker start nova-conductor
总结
通过以上步骤,确保 Nova 和 MySQL 之间的安全通道正常,解决由于 Nova-Conductor 引起的连接问题:
- 关闭集群新建入口。
- 确认 VIP 所在节点。
- 停止备节点的 Nova-Conductor 服务。
- 清理 RabbitMQ 消息队列。
- 启动 VIP 节点上的 Nova-Conductor 服务。
- 观察 Nova-Conductor 日志。
- 重启 Nova-API 服务。
- 等待 2-3 分钟。
- 灰度恢复备节点的 Nova-Conductor 服务。
通过这些步骤,可以有效解决由于 Nova-Conductor 引起的连接问题,确保 OpenStack 集群的稳定运行。