OpenStack大规模部署优化之二:稳态优化

本文从稳态方面总结分享原生OpenStack支撑大规模(千节点量级)部署的优化思路
OpenStack随着计算节点规模增大,计算节点上的各服务的agent个数会随之增加,比如nova-compute、neutron-agent、ceilometer-agent等。
在稳态下,由于agent存在周期性任务,随着这些agent的增加,主要是周期任务会对系统造成压力,优化点如下:

1、调整MQ连接数,降低MQ压力
问题描述:
OpenStack各服务内部通信都是通过RPC来交互,各agent都需要去连接MQ;
随着各服务agent增多,MQ的连接数会随之增多,最终可能会到达上限,成为瓶颈
解决思路1:
调整各Agent的RPC连接池大小;连接池默认大小为30,假如有1000个计算节点,nova-compute所需的MQ连接数上限总数就是3W,
所以在真正部署过程中,需要对此值进行权衡优化;对应参数如下:

[default]
# Size of RPC connection pool. (integer value) 
# Deprecated group;name - DEFAULT;rpc_conn_pool_size
rpc_conn_pool_size=30 

解决思路2:
提升MQ连接数上限;MQ的连接数取决于ulimit文件描述符的限制,一般缺省值为1024,对于MQ服务器来说此值偏小,
所以需要重新设置linux系统中文件描述符的最大值,设置方法具体如下:
(1)通过rabbitmqctl命令,查看rabbitmq当前支持的最大连接数

[root@local~]#rabbitmqctl status
Status of node 'rabbit@192-168-0-15' [{pid,198721},
......
{file_descriptors,
[{total_limit,924},
{total_used,10},
{sockets_limit,829},
{sockets_used,10}]},
......
]

(2)通过ulimit查看当前系统中文件描述符的最大值

[root@local~]# ulimit -n
1024

(3)调整最大值
方式1:在rabbitmq启动脚本中增加ulimit -n 10240,修改rabbitmq进程的文件描述符最大值
方式2:修改/etc/security/limits.conf文件中的如下配置
user soft nofile 10240
user hard nofile 10240
方式3:修改/etc/sysctl.conf文件,增加如下配置项
fs.file-max=10240

2、优化周期任务,减少MQ压力
问题描述:
稳态下各agent存在一些周期任务周期性调用RPC,随着agent增多,RPC的次数会增多,MQ压力会增大
解决思路1:
优化周期性任务,对周期性任务的周期进行审视,在允许的情况下,可适当增大周期,减少MQ压力;
比如心跳上报周期,nova-compute默认10s上报一次心跳;nova对服务判断是否存活的时间,默认60s(取决于service_down_time);
在大规模场景下,可以调整report_interval为20s;在1000节点规模下,nova-compute心跳优化前为100次/s,优化后50次/s;对应参数如下

[default]
# Seconds between nodes reporting state to datastore (integer value) 
report_interval=10

解决思路2:对MQ进行分库处理,不同服务采用不同的MQ

3、优化周期任务,减少数据库压力
问题描述:
稳态下各agent存在一些周期性任务周期调用数据库操作,nova-compute数据库操作是通过RPC到nova-conductor进行,
随着计算节点增多,数据库以及nova-conductor压力会随之增大
解决思路1:
优化周期任务周期,同上;当然上报心跳的周期也可以采用memcache存储后端,直接减少不必要的数据库调用,配置项如下

# This option specifies the driver to be used for the servicegroup service. 
# ServiceGroup API in nova enables checking status of a compute node. When a 
# compute worker running the nova-compute daemon starts, it calls the join API 
# to join the compute group. Services like nova scheduler can query the 
# ServiceGroup API to check if a node is alive. Internally, the ServiceGroup 
# client driver automatically updates the compute worker status. There are 
# multiple backend implementations for this service: Database ServiceGroup driver 
# and Memcache ServiceGroup driver. # Possible Values: 
# * db : Database ServiceGroup driver 
# * mc : Memcache ServiceGroup driver
servicegroup_driver = mc--默认是数据库存储心跳时间,可以改成缓存的

解决思路2:
调整nova-conductor对应的worker数目,支撑大规模场景,对应参数如下

[conductor]
# Number of workers for OpenStack Conductor service. The default will be the 
# number of CPUs available. (integer value) 
workers=1

 转载  https://zhuanlan.zhihu.com/p/33255796

原文地址:https://www.cnblogs.com/potato-chip/p/13707097.html