OpenStack Queens控制节点基础组件配置：MariaDB、RabbitMQ与Memcached实战

1. 动手之前的基线检查Queens版本控制节点的前置条件写这一篇之前先交代背景这是OpenStack Queens环境搭建系列的第二篇第一篇里已经完成了基础系统配置、网络规划、主机名设置和OpenStack软件源准备。如果你是从这篇才开始跟着做那得先把前置条件补齐不然装到一半会发现各种奇怪的问题——比如服务起不来、节点之间连不上、yum安装报错这些大部分不是软件本身的问题而是源头没准备好。先说版本。Queens是OpenStack的第17个发行版对应RDO源的pike/queens时代用的是Python 2为主、部分组件开始切Python 3的过渡期。现在用Queens的同学要么是学校实验课还在沿用老教材要么是生产环境里历史遗留的私有云平台需要复现和维护还有一部分是想通过老版本理解OpenStack架构演进的人。不管哪种情况有一点必须接受Queens已经停止维护yum源里的包不会再有更新所以安装时一定要把软件源固定好不要混用更新版本的源。控制节点要装的三件套——MySQL实际用MariaDB、RabbitMQ、Memcached是整个OpenStack的控制平面底座。它们分别解决的问题是数据库负责存所有组件的状态和配置信息消息队列负责各服务之间的异步通信比如计算节点要把虚拟机创建结果告诉控制节点Memcached负责缓存Keystone的token和各组件的短期数据减轻数据库压力。这三者装不好后面Nova、Neutron、Horizon装得再漂亮也是白搭。下面是我建议在动手前逐项确认的环境基线主机名控制节点主机名建议就叫controller执行hostnamectl set-hostname controller然后确认cat /etc/hostname显示的是controller。/etc/hosts解析三台节点控制、计算、网络看你规划的IP和主机名必须互相能解析。这个坑我踩过RabbitMQ在集群模式或某些组件回调时会反解主机名解析不了直接卡死。软件源确认已经配置好RDO Queens源和EPEL源。Queens的base源已经归档如果你用的是官方源地址注意替换为vault/archive地址否则yum install会报404。防火墙与SELinux实验环境建议直接清空防火墙规则或放行必要端口SELinux置为permissive。如果非要开防火墙至少放行3306、5672、11211这三个端口后面我会给出具体端口规则。提示我见过很多人在这一步卡住其实不是OpenStack的问题而是因为系统初始环境不干净。装之前建议先yum update -y把系统补丁打齐再重启一次确保内核和依赖库一致。这样做能在后面省下大量排查时间。另外Queens时代的组件对系统时间非常敏感尤其是Keystone的Fernet token和数据库连接。控制节点一定要配好NTP时间同步否则后面跑起来会间歇性出现401、token过期之类的诡异报错。这个不属于本篇主题但我在实际部署时都会先顺手做掉。时间同步确认命令很简单chronyc sources -v或ntpq -p看到有输出的源就行。别在这上面偷懒我后面会专门写一篇排错文章讲时间不同步导致的连环故障。还有一个容易忽略的是Python环境。Queens组件在CentOS 7上主要依赖Python 2.7系统默认就有但如果你之前装过别的版本的Python或者动过系统的Python软链接那后续所有组件安装都可能炸。一个快速检查是python --version和python2 --version如果输出异常先把系统Python恢复默认。2. MariaDBMySQL安装字符集、监听地址和初始化操作一个不能少2.1 为什么OpenStack用MariaDB而不是MySQL很多人会问这个问题。Queens官方文档里写的依赖是MySQL或MariaDB但RDO源里直接提供的是MariaDB因为CentOS 7本身的数据库默认就是MariaDB。从实际使用来看MariaDB在兼容MySQL协议的同时性能、GTID复制、线程池等方面都有优化OpenStack各组件通过PyMySQL驱动连接完全透明。这里有个技术点是连接驱动。控制节点装完数据库后还需要给OpenStack各组件提供Python连接MySQL的驱动包。Queens版本里这个包叫python2-PyMySQL注意是Python 2版本不要装成python3-PyMySQL否则一些老组件会用它连不上或报模块找不到。安装命令如下yum install -y mariadb-server python2-PyMySQL装完之后先别急着启动先把配置文件搞定再启动否则后面还要重启好几次服务。2.2 openstack.cnf块配置文件的三个关键参数MariaDB的主配置文件是/etc/my.cnf它会include/etc/my.cnf.d/目录下所有.cnf文件。OpenStack官方给出的方案是新建/etc/my.cnf.d/openstack.cnf把OpenStack特有的配置单独放这样不会污染系统默认配置后期也好维护。我的推荐配置如下[mysqld] bind-address 192.168.100.10 default-storage-engine innodb innodb_file_per_table on max_connections 4096 collation-server utf8_general_ci character-set-server utf8这里挑几个逐个解释。bind-address这个必须设置为控制节点的管理网IP而不是127.0.0.1。因为后面Nova、Neutron这些组件的服务可能在控制节点上也可能分布在其他节点它们要通过网络访问数据库。如果写成127.0.0.1只有本机能连其他节点全拒。default-storage-engine innodbOpenStack各组件建表时有些没显式指定引擎如果默认是MyISAM会出现表级锁竞争、不支持事务等问题。InnoDB支持行级锁和事务对OpenStack这种频繁并发读写的场景更合适。innodb_file_per_table on让每个表独立表空间文件避免共享表空间无限膨胀后续针对单个大表做优化或者删除表也更方便。character-set-server utf8和collation-server utf8_general_ci这个必须盯死。如果数据库默认字符集不是UTF-8OpenStack组件存中文字符串比如云主机名称、描述信息时会报编码错误甚至直接写入乱码。我遇到过最坑的是Keystone存项目描述时乱码最后排查到数据库字符集上整库重建才解决。max_connections 4096OpenStack的组件数量多、每个组件的并发连接数也高。Queens默认的151连接数在控制节点上很容易被打满出现“Too many connections”错误。调高到4096是官方推荐值也够普通生产环境用。2.3 初始化数据库与安全加固配置文件写好后启动服务并设置开机自启systemctl enable mariadb systemctl start mariadb systemctl status mariadb确认服务状态是active (running)之后执行安全初始化脚本mysql_secure_installation这个脚本会一步一步问你是否设置root密码、是否移除匿名用户、是否禁止root远程登录、是否删除test数据库。我建议全部选yes特别是“禁止root远程登录”那项。OpenStack各组件的数据库账号都是单独创建的root只留本机操作权限就够了减少暴露面。有一点要注意CentOS 7的MariaDB安装后root默认是空密码直接mysql -uroot就能进。设置root密码时别用太复杂的特殊字符。为什么这么说因为后面会写一个/etc/my.cnf.d/openstack.cnf之类的静态配置有些组件连接数据库的密码是明文写在配置文件里的如果密码里带了、#、$等特殊符号解析配置时经常出问题你会花很长时间排查“为什么密码明明对就是连不上”的诡异问题。如果非用不可至少得注意连接串里的转义和引号处理。2.4 验证数据库服务记住一个原则每装完一个服务当场验证别攒到后面一起排错。验证MySQL的第一件事是确认字符集已经生效mysql -uroot -p SHOW VARIABLES LIKE character%; SHOW VARIABLES LIKE collation%;正常输出应该是character_set_server | utf8collation_server | utf8_general_ci。如果还是latin1说明配置文件没生效检查一下/etc/my.cnf.d/目录是否被主配置include。第二件事确认监听地址已经改成控制节点IPnetstat -tlnp | grep 3306输出中监听地址应该是你的管理网IP而不是0.0.0.0或127.0.0.1。如果显示127.0.0.1说明bind-address没生效重启一次mariadb服务再看。第三件事测试远程连接。在另一台节点或同一台用管理网IP执行mysql -uroot -p -h 192.168.100.10如果报错Access denied只说明密码不对如果报错Cant connect那就要检查防火墙端口3306是否放行、bind-address是否配好。这一步卡住不要急着跳过去因为后续几乎每个组件的数据库初始化都要通过网络连接数据库。注意Queens时期的组件配置数据库连接时connection字段通常写成mysqlpymysql://username:passwordcontroller:3306/dbname这种格式这里的controller会通过/etc/hosts解析到管理网IP所以hosts解析的重要性在这个环节就体现出来了。3. RabbitMQ消息队列的用户体系与权限分配3.1 控制节点上的消息总线角色先理解RabbitMQ在OpenStack里的角色。Nova的调度器要把创建云主机的任务发给计算节点Neutron要把网络配置变更通知到各个agent这些都不是同步调用的而是通过消息队列异步分发。RabbitMQ就是这套消息总线。如果RabbitMQ挂了整个OpenStack的控制平面基本瘫痪各组件之间完全失联。装RabbitMQ的命令很简单yum install -y rabbitmq-server启动并设置开机自启systemctl enable rabbitmq-server systemctl start rabbitmq-server启动后先不要配置让系统把默认的vhost和guest用户建好然后我们在此基础上加OpenStack专用用户。3.2 创建OpenStack用户与vhostRabbitMQ默认有个guest用户这个用户默认只能在localhost访问生产环境一般删掉或改密码。OpenStack不用guest而是建议创建一个专用用户比如叫openstack密码同样注意别带特殊字符。rabbitmqctl add_user openstack RABBIT_PASS rabbitmqctl set_permissions openstack .* .* .*第一行创建用户第二行授权。三个.*分别对应configure、write、read权限意思是这个用户对RabbitMQ里的所有资源拥有全部操作权限。OpenStack各组件连接时会在消息队列里创建自己的队列、交换器、绑定如果权限不够会出现各种“connection closed”或“NOT_ALLOWED”的报错。补充一个概念RabbitMQ里也有vhost。默认vhost是/OpenStack的所有组件默认都连这个vhost。如果你的平台划分了多个租户或部门可以为不同的OpenStack项目建独立的vhost隔离消息但实验环境不推荐徒增复杂度。验证用户是否创建成功用rabbitmqctl list_users输出中看到openstack即成功。3.3 配置文件的调整与内存限制RabbitMQ默认配置在/etc/rabbitmq/目录。Quenns版本一般不需要改太多但我在实践中发现两个值得做的小调整。第一个是允许guest用户在非本机登录。如果你不想为OpenStack创建专门的用户非要沿用guest必须新建一个/etc/rabbitmq/rabbitmq.config把loopback_users设为空列表。但我强烈不建议这样做guest用户太容易被暴力破解或误操作单独账号管理和审计都更清晰。第二个是内存限制。RabbitMQ有个特性默认当系统内存使用达到40%阈值时会开始阻塞生产者连接防止OOM。但在实验环境或者内存较小的控制节点上这个阈值经常被误触发导致消息收发卡顿。我一般通过新建/etc/rabbitmq/rabbitmq-env.conf来限制RabbitMQ能用的内存和端口RABBITMQ_NODE_PORT5672 RABBITMQ_NODE_IP_ADDRESS0.0.0.0这里端口5527是AMQP协议默认端口监听地址设为0.0.0.0表示允许所有网卡访问。如果你的控制节点有多个网卡也可以指定管理网IP但我发现设为0.0.0.0在排错时更省心因为不用纠结哪个网卡地址正确。内存限制的进阶配置可以写[ {rabbit, [ {vm_memory_high_watermark, 0.4} ]} ].这段Erlang语法配置会让RabbitMQ在系统内存使用率达到40%时才触发阻塞。如果你控制节点内存只有2GB建议把阈值降到0.3否则系统其他服务可能先出问题。3.4 模拟消息收发验证RabbitMQ装完不能只看服务状态最直接的验证方式是发布一个测试消息再消费它。系统自带了rabbitmqadmin工具如果没装可以用yum install rabbitmqadmin或者从管理插件里获取但我更推荐用Python的方式做端到端验证因为这个方式和OpenStack各组件实际调用方式最接近yum install -y python2-pika然后写一个最小测试脚本# test_rabbit.py import pika credentials pika.PlainCredentials(openstack, RABBIT_PASS) parameters pika.ConnectionParameters( controller, 5672, /, credentials) connection pika.BlockingConnection(parameters) channel connection.channel() channel.queue_declare(queuetest_queue) channel.basic_publish( exchange, routing_keytest_queue, bodyHello OpenStack RabbitMQ) print( [x] Sent test message) connection.close()执行后如果打印出[x] Sent test message说明用户认证、网络连接、vhost访问、消息投递全部正常。如果你不想额外装pika库也可以直接用rabbitmqadmin publish exchangeamq.default routing_keytest_queue payloadtest效果一样。提醒RabbitMQ的日志默认在/var/log/rabbitmq/排错时先看日志。最常见的问题是epmd进程没起来或者节点名解析失败。RabbitMQ在节点启动时会用主机名做节点标识比如rabbitcontroller如果hosts解析不正确启动会报错或无法建立集群。4. Memcached为Keystone token和组件缓存提速4.1 为什么需要MemcachedOpenStack各组件的运行过程中有大量“读多写少、写后短时间即可失效”的数据。最典型的是Keystone认证产生的token每个API请求都要校验token如果每次都查数据库数据库压力会非常大。Memcached把这些高频访存数据放在内存里极大降低数据库查询量。除了tokenNova的nova-consoleauth、Neutron的某些状态缓存、Horizon的会话缓存也都会用到Memcached。所以它虽然轻量在架构里不可或缺。安装命令yum install -y memcached python-memcachedpython-memcached是Python连接Memcached的客户端库Keystone、Nova等组件都是通过它来读写缓存。有些组件还需要sasl支持或python-pymemcacheQueens版本里还是以python-memcached为主。4.2 配置监听地址和缓存大小Memcached的配置文件在/etc/sysconfig/memcached注意它不是一个.conf文件而是系统服务的环境变量定义文件。默认内容大致是这样PORT11211 USERmemcached MAXCONN1024 CACHESIZE64 OPTIONS-l 127.0.0.1,::1这里需要重点改的是OPTIONS的监听地址。默认只监听本机回环地址但如果你的控制节点上所有OpenStack组件都在同一台机器本机访问没问题如果后续计算节点也要连接Memcached例如某些版本的Nova配置了memcached作为缓存后端那就要把监听地址改成控制节点的管理网IPOPTIONS-l 192.168.100.10,::1我实际部署时会把CACHESIZE从64调大到128或256。理由很简单OpenStack环境里有组件数量多某些大规格云主机的元数据、镜像缓存、token列表都会占用内存64M在真实使用中很容易被占满触发内存淘汰策略导致明明刚写入的token瞬间被清掉客户端报401。实验环境64M勉强够用生产建议至少256M起步。修改完重启服务systemctl restart memcached systemctl enable memcached4.3 验证Memcached读写验证Memcached最直接的方法是用memcached-tool查看统计信息或者用telnet手动操作一个key。先看统计memcached-tool 192.168.100.10:11211 stats正常输出包含curr_items、total_items、bytes等字段。如果连不上要么是端口没监听要么是防火墙没放行11211要么是memcached用户没有权限。用telnet做读写验证CentOS 7默认有telnet客户端没有就yum install -y telnettelnet 192.168.100.10 11211 set test_key 0 60 5 hello STORED get test_key VALUE test_key 0 5 hello END quit如果返回STORED说明写入成功能GET到同样的值说明缓存读写正常。这一步用telnet完成了从网络层到应用层的完整验证。4.4 和后续组件的配置衔接装完Memcached后后面装Keystone、Nova、Horizon时配置文件里会有一项memcached_servers controller:11211或者CACHES_URL memcached://controller:11211指的就是这里。如果你的Memcached监听配置没生效后面这些服务可能启动正常但一访问就报错或严重变慢。还有一个细节Keystone在Queens版本里默认使用Fernet tokentoken本身不存数据库但token的撤销列表revocation list有时会缓存到Memcached里。如果Memcached挂了即使Fernet token本身没问题撤销列表的校验也会失败导致合法token被拒绝。这也是为什么我总强调Memcached虽然看起来不起眼但它直接影响认证链路的稳定性。5. 三件套联动验证像OpenStack组件一样访问它们三个服务各自装完、各自验证完不代表整条链路通了。真实环境里OpenStack组件不是单独访问某一个服务而是同时依赖这三个。所以我会在装完三件套后做一次联动验证把自己编写的测试脚本模拟成Nova或Neutron的访问行为同时操作数据库、消息队列和缓存。5.1 数据库连通性测试脚本写一个Python脚本模拟Nova组件通过PyMySQL连接MySQL并执行简单查询# test_mysql.py import pymysql conn pymysql.connect( hostcontroller, port3306, userroot, passwordRABBIT_PASS, dbmysql ) cur conn.cursor() cur.execute(SHOW DATABASES) for row in cur.fetchall(): print(row) conn.close()如果这一步报错Access denied或Cant connect先单独排除MySQL的问题再往下走。注意OpenStack组件连接数据库时用的是mysqlpymysql连接串所以PyMySQL驱动必须安装好这一节在2.1里已经强调过。5.2 消息队列权限确认用上面3.4节的pika脚本再走一遍确认用户openstack的权限没有问题。这里我想补充一点经验RabbitMQ的授权是“资源级”的你给openstack配了.*的权限后它在所有vhost下都可以创建队列和交换器。某些OpenStack组件比如Neutron的某些agent会创建以组件名命名的队列例如q-agent-notifications如果权限不足界面或日志里会出现channel error一类的提示。所以权限一定要给够。检查队列是否创建成功rabbitmqctl list_queues看到有队列输出说明有客户端在正常使用消息队列。5.3 三件套端口与服务状态一览以下是我排查时常用的检查清单一张表看全服务端口配置文件关键检查命令常见失败原因MariaDB3306/etc/my.cnf.d/openstack.cnfmysql -uroot -p -h controller没设bind-address、3306端口被防火墙挡、密码特殊字符RabbitMQ5672/etc/rabbitmq/rabbitmq-env.confrabbitmqctl list_usershosts解析失败、guest未授权、epmd冲突Memcached11211/etc/sysconfig/memcachedmemcached-tool 192.168.100.10:11211 statsOPTIONS没改监听地址、CACHESIZE太小对应防火墙放行规则如果你没关防火墙firewall-cmd --permanent --add-port3306/tcp firewall-cmd --permanent --add-port5672/tcp firewall-cmd --permanent --add-port11211/tcp firewall-cmd --reload5.4 高频故障与排查经验老规矩把我在实际部署中最常踩的几个坑列一列MySQL远程连不上。先netstat -tlnp | grep 3306看监听地址再用mysql -uroot -p -h 192.168.100.10测试最后检查防火墙。顺序不要搞反别一上来就查防火墙很多时候是bind-address写错。RabbitMQ启动正常但连不上。打开/var/log/rabbitmq/rabbitcontroller.log重点关注connection refused和access_refused。如果日志里有hostname resolution相关报错百分百是hosts解析问题。Memcached存储但取不出来。这种情况先看有没有内存淘汰memcached-tool stats里的evictions字段会记录被淘汰次数。如果curr_items接近CACHESIZE且evictions不为0说明缓存空间不够调大CACHESIZE。服务之间时间不同步。这个前面提到了但值得重复数据库连接、Keystone token验证、RabbitMQ的某些心跳机制都对时间敏感三件套装完后建议统一用chronyc sources确认。密码特殊字符。我特别强调过很多次但每次部署都有人踩。配置文件里密码带会被URL解析器截断带#会被MySQL配置解析成注释。最稳妥的做法是所有服务密码只用字母和数字长度控制在12到16位。这不算安全意识薄弱而是OpenStack的配置文件解析方式对特殊字符不友好非要用特殊字符就得额外处理转义徒增麻烦。6. 这套底座搭完之后下一步该干什么三件套就绪后的下一步通常是装Keystone认证服务。因为OpenStack的所有组件第一个要对接的就是Keystone而Keystone又依赖MySQL和Memcached。所以你会发现这三件套不只是“基础软件安装”它们是整个控制平面的数据通道、通信通道和缓存通道先有通道才有上层建筑。我在实际项目里惯用的做法是装完三件套后不等全部组件配好先写一个综合检查脚本把数据库连通性、消息队列认证、缓存读写三项打包在一起一键输出结果。这一步能让你在后续安装过程中遇到问题时有明确的排查起点——先确认底座是好的再怀疑上层组件配置。最后再分享一个心得很多人装OpenStack失败不是因为技术难而是因为安装步骤太碎、太多一旦出错就容易陷入“到处都一样烂”的困境。我的建议是每一步都当场验证、当场记录用一张表格管理所有服务的连接参数和密码。这样即便哪一天某个服务挂了你也能迅速定位是哪个环节出了问题而不是从头到尾云里雾里地重新检查一遍。