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

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、解决方案
          • [解决 MySQL 事务超时和连接关闭错误](#解决 MySQL 事务超时和连接关闭错误)
          • 错误描述
          • 可能的原因
          • 解决方案
            • [1. 检查和调整 MySQL 配置](#1. 检查和调整 MySQL 配置)
            • [2. 调整 SQLAlchemy 连接池配置](#2. 调整 SQLAlchemy 连接池配置)
            • [3. 在代码中增加异常处理和重试逻辑](#3. 在代码中增加异常处理和重试逻辑)
            • [4. 优化 SQL 查询](#4. 优化 SQL 查询)
        • [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. 概念
  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 
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 事务超时和连接关闭错误
错误描述

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

可能的原因
  1. MySQL 连接超时:由于长时间未使用,连接超时。
  2. 事务超时:事务未在规定时间内完成。
  3. 连接池配置不当:SQLAlchemy 连接池配置不当,导致连接管理问题。
  4. 网络问题:网络不稳定,导致连接关闭。
解决方案
1. 检查和调整 MySQL 配置
  1. 增加连接超时时间

    sql 复制代码
    SET GLOBAL wait_timeout = 28800;
    SET GLOBAL interactive_timeout = 28800;
  2. 增加事务超时时间

    sql 复制代码
    SET 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 引起的连接问题:

  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 集群的稳定运行。

相关推荐
一点媛艺2 小时前
Kotlin函数由易到难
开发语言·python·kotlin
姑苏风2 小时前
《Kotlin实战》-附录
android·开发语言·kotlin
奋斗的小花生3 小时前
c++ 多态性
开发语言·c++
魔道不误砍柴功3 小时前
Java 中如何巧妙应用 Function 让方法复用性更强
java·开发语言·python
闲晨3 小时前
C++ 继承:代码传承的魔法棒,开启奇幻编程之旅
java·c语言·开发语言·c++·经验分享
老猿讲编程4 小时前
一个例子来说明Ada语言的实时性支持
开发语言·ada
Chrikk5 小时前
Go-性能调优实战案例
开发语言·后端·golang
幼儿园老大*5 小时前
Go的环境搭建以及GoLand安装教程
开发语言·经验分享·后端·golang·go
canyuemanyue5 小时前
go语言连续监控事件并回调处理
开发语言·后端·golang
杜杜的man5 小时前
【go从零单排】go语言中的指针
开发语言·后端·golang