RabbitMQ无法新建连接问题处理过程记录




症状描述

客户反馈无法云平台VNC控制台窗口一直处于loading状态,无法打开

定位过程

  1. 首先查看nova-api服务是否正常,nova list正常
  2. 查看nova service-list输出,所有服务在线
  3. 使用nova get-vnc-console获取云主机vnc链接,超时无法获取

初步找到控制台窗口无法打开的原因,继续分析问题,

  1. 查看云主机所在节点的nova-compute服务,一切正常
  2. 查看nova-compute日志,没有收到创建vnc链接请求(vnc控制台链接是在云主机所在计算节点生成的,因为要查询云主机qemu进程创建的vnc server端口号,创建完成后要把token和端口号对应关系保存到nova-consoleauth进程,nova-consoleauth进程会根据配置项决定把对应关系保存到进程内存还是memcache服务,之前处理过一次控制节点内存不足导致token保存失败的问题,这次也先查了下nova-consoleauth日志,没有发现类似情况)
  3. 查看nova-api节点日志,发现收到了请求但没有返回
  4. 打开nova-api和nova-compute的debug日志继续分析
  5. 发现nova-api一直在尝试连接到RabbitMQ,一直卡在connecting,没有connected日志

找到更进一步的问题原因,继续分析问题,

  1. 首先重启nova-api服务,试验下能否恢复,发现启动进程时可以连接到MQ,但获取vnc链接时问题仍然存在
  2. 通过rabbitmqctl命令行查看queue和exchange情况,也没发现异常,云主机节点的compute队列也有
  3. 重启MQ服务,试验能否恢复,重启后发现vnc链接获取命令恢复正常,页面打开控制台窗口正常

问题解决但没找到原因,于是继续观察,等了大概2分钟,再次尝试打开vnc控制台窗口,发现老问题还在,一直loading,继续分析问题,

  1. 查看MQ服务器日志,发现异常,
    =WARNING REPORT==== 25-Oct-2017::10:35:48 ===
    file descriptor limit alarm set.
    
    ********************************************************************
    *** New connections will not be accepted until this alarm clears ***
    ********************************************************************

    发现问题根本原因,文件句柄数量超出限制,google搜索这个错误,发现了解决方法,https://my.oschina.net/moooofly/blog/678513

  2. 首先修改MQ节点物理机文件句柄数量配置(增加如下两行):
    $ cat /etc/security/limits.conf  | grep nofile
    * soft nofile 262144
    * hard nofile 262144
  3. ulimit -n也修改成65536
  4. 重启RabbitMQ,rabbitmqctl status命令查看限制,发现不生效:
     {file_descriptors,
         [{total_limit,924},
          {total_used,525},
  5. 按照搜索结果中的提示执行:rabbitmqctl stop,rabbitmq-server -detached,再次查看,发现句柄数限制已修改
  6. 尝试web打开vnc窗口,发现恢复正常,nova-api和nova-compute日志正常connected到MQ
  7. 等待几分钟仍然正常,问题解决
  8. 尝试修改安装部署脚本,发现先修改系统句柄数配置再安装MQ,仍然无法修改MQ句柄限制
  9. 继续google,查看到RabbitMQ官方文档,https://www.rabbitmq.com/install-rpm.html,有如下描述:
    Controlling System Limits on Linux
    
    RabbitMQ installations running production workloads may need system limits and kernel parameters tuning in order to handle a decent number of concurrent connections and queues. The main setting that needs adjustment is the max number of open files, also known as ulimit -n. The default value on many operating systems is too low for a messaging broker (eg. 1024 on several Linux distributions). We recommend allowing for at least 65536 file descriptors for user rabbitmq in production environments. 4096 should be sufficient for most development workloads.
    
    There are two limits in play: the maximum number of open files the OS kernel allows (fs.file-max) and the per-user limit (ulimit -n). The former must be higher than the latter.
    
    With systemd (Recent Linux Distributions)
    
    On distributions that use systemd, the OS limits are controlled via a configuration file at /etc/systemd/system/rabbitmq-server.service.d/limits.conf, for example:
    
    [Service]
    LimitNOFILE=300000

    据此修改后正常。