OpenStack在架构设计上是松耦合解耦架构，天生支持横向扩展；但真正在大规模部署过程中，仍有好多因素决定其部署规模。本文从业务并发方面总结分享原生OpenStack支撑大规模(千节点量级)部署的优化思路；
在大规模并发业务过程中，主要是去除红绿灯（数据库行级锁）解决锁抢占问题，以及修多条高速公路(调整各组件进程数)最终提升各组件的处理能力
1、调整haproxy进程数，提升Loadbalance能力
问题描述：
在openstack部署过程中，通常采用haproxy作为前端负载均衡器，在大规模并发过程中，需要观察haproxy的CPU使用率，如果到达了100%，则需要进行优化
解决思路：
调整haproxy的进程数，支撑大规模并发，参数如下
global
nbproc 16 #进程个数
备注： haproxy 的配置文件由两部分组成：全局设定和对代理的设定，共分为五段：global，defaults，frontend，backend，listen。 配置文件格式 HAProxy的配置处理3类，主要参数来源： ——最优先处理的命令行参数; ——“global”配置段，用于设定全局配置参数； ——proxy相关配置段，如“defaults”、“listen”、“frontend”和“backend”； 参数详解： – nbproc <number>（global 配置段参数）：指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy； 默认只启动一个进程，鉴于调试困难等多方面的原因，一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式；
2、调整OpenStack各组件进程数，提升组件处理能力
问题描述:
在大规模业务并发过程中，各组件处理能力不足（可以观察进程对应cpu使用率，如果已经到100%，说明处理能力不足）
解决思路:
可以通过横向扩展组件或调整组件worker数来解决
3、数据库、MQ分库处理，提升性能
问题描述：
大规模并发过程中，业务处理会对数据库和MQ，造成比较大的压力，导致业务下发失败
解决思路：
对MQ和数据库进行分库处理，不同服务采用不同的库进行优化
4、优化数据库连接数，减少数据库连接总数
问题描述：
并发业务处理，需要连接数据库，并发度高的时候，提示数据库连接超过了上限
解决思路：
调整各组件的数据库连接数配置，取决于max_pool_size（连接池大小）和max_overflow（最大允许超出的连接数）
[database]
# Maximum number of SQL connections to keep open in a pool. (integer value)
max_pool_size=10
# If set, use this value for max_overflow with SQLAlchemy. (integer value)
max_overflow=10
5、采用缓存调度器驱动，提升虚拟机调度时间
问题描述：并发调度过程中，调度前都会去数据库读取主机信息，耗时长导致调度时间长
解决思路：采用缓存调度器，缓存主机信息，提升调度时间
#caching_scheduler which aggressively（有闯进地） caches the system state for better
scheduler_driver=caching_scheduler
备注： # The class of the driver used by the scheduler. This should be chosen from one # of the entrypoints under the namespace 'nova.scheduler.driver' of file # 'setup.cfg'. If nothing is specified in this option, the 'filter_scheduler' is # used. # Other options are: # * 'caching_scheduler' which aggressively caches the system state for better # individual（单个的）scheduler performance at the risk of more retries when running # multiple schedulers. “caching_scheduler”，它主动缓存系统状态，以获得更好的单个调度器性能，但在运行多个调度器时可能会有更多重试的风险 # * 'chance_scheduler' which simply picks a host at random. # * 'fake_scheduler' which is used for testing. # # Possible values: # * Any of the drivers included in Nova: # ** filter_scheduler # ** caching_scheduler # ** chance_scheduler # ** fake_scheduler # * You may also set this to the entry point name of a custom scheduler driver, # but you will be responsible for creating and maintaining it in your # setup.cfg # file. # (string value) # Deprecated group;name - DEFAULT;scheduler_driver #driver=filter_scheduler（默认值）
6、基于存储内部快速复制能力，缩短镜像创建卷的时间
问题描述:
单个虚拟机创建耗时长的点主要集中在镜像创建卷，在创建过程中，需要下载镜像，所以创建时间跟镜像大小以及网络带宽强相关
解决思路:
可以基于存储内部快速复制卷的能力，解决系统卷创建慢的问题，有以下三种方式
方式1：在cinder上对镜像卷进行缓存，openstack社区提供了缓存镜像卷的能力，核心思想，第一次创建卷的时候，在存储后端缓存对应的镜像卷，后续创建都是基于这个镜像卷复制一个新的卷。
方式2：glance后端对接cinder，镜像直接以卷的形式存在cinder上，这种方式，在镜像上传的过程中，直接以卷的形式存放，在从镜像创建的卷的过程中，直接走卷复制卷的能力。
这种方式可以解决首次发放慢的问题
方式3：基于存储的差分卷能力实现卷的快速创建，这一功能需要实现cinder volume中的clone_image方法，在这个方法里面，可以先缓存镜像快照，然后基于快照创建差分卷
7、采用rootwrap daemon方式运行命令，缩短nova/neutron等组件调用系统命令的时间
问题描述:
rootwrap 主要用来做权限控制。在openstack中，非root用户想执行需要root权限相关的命令时，用rootwrap来控制。
启动虚拟机过程中，会多次调用系统命令；调用命令时，会经过rootwrap命令进行封装，这个命令在每次允许过程中，都会加载命令白名单（允许nova组件执行命令的列表配置文件），
最终再调用实际命令运行，额外耗时100ms左右。
解决思路:
通过rootwrap daemon机制来解决，启动一个rootwrap daemon专门接受执行命令的请求，节省每次加载白名单的时间 nova-compute对应的rootwrap配置项：
[DEFAULT]
use_rootwrap_daemon=True
备注： # Start and use a daemon that can run the commands that need to be run with # root privileges（权限）. This option is usually enabled on nodes that run nova compute processes. # (boolean value) #use_rootwrap_daemon=false,默认为false [root@test nova]# pwd /etc/nova [root@test nova]# ls api-paste.ini logging.conf nova.conf policy.json release rootwrap.conf（该文件的配置内容如下:） [root@test nova]# [root@test nova]# cat rootwrap.conf |grep -v ^# |grep -v ^$ [DEFAULT] filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap exec_dirs=/sbin,/usr/sbin,/bin,/usr/bin,/usr/local/sbin,/usr/local/bin use_syslog=False syslog_log_facility=syslog syslog_log_level=ERROR [root@test nova]#
8、Qutoa无锁化优化，减少操作Quota时的耗时
问题描述：
openstack在Quota处理过程中，采用了数据库行级锁来解决并发更新问题，但在并发场景下，这个锁会导致耗时增加
解决思路：
由于在处理Quota过程中，先select再update，所以需要加锁（悲观锁）。针对这一点，可以通过带有where的update操作来实现更新，然后根据更新行数，判断是否更新成功（乐观锁）
9、调整nova-compute并发创建任务上限，提升组件的并发能力
问题描述：
nova-compute在并发创建虚拟机过程中，有并发任务限制（M版本默认值为10）
解决思路：
增大并发任务个数上限，对应参数为max_concurrent_builds
备注： # Limits the maximum number of instance builds to run concurrently（同时的） by nova-compute. #Compute service can attempt to build an infinite（无限的；无穷的） number of instances, if asked to do so. #This limit is enforced to avoid building unlimited instance concurrently on a compute node. #This value can be set per compute node. 限制由nova-compute并发运行的实例构建的最大数量。 如果被要求，Compute service可以尝试构建无限个实例。 执行此限制是为了避免在计算节点上并发地构建无限个实例。 这个值可以为每个计算节点设置。 # Possible Values: # # * 0 : treated as unlimited. # * Any positive integer representing maximum concurrent builds. # (integer value) # Minimum value: 0 #max_concurrent_builds=10
10、keystone采用PKI机制替换UUID方式，减少keystone压力
问题描述：
openstack api server在处理请求前会校验token是否合法，如果采用UUID token，则每次都会去keystone做校验
解决思路：
采用PKI方式，各api在本地通过证书来校验token是否合法
11、适当增大各组件token失效列表的缓存时间，可以减少keystone的压力
问题描述：
openstack api server在处理请求前会校验token是否合法，除了校验token是否过期，同时还校验token是否在token失效列表里面；
这个token失效列表会在本地缓存，如果过期，则会去keystone重新获取，在并发的时候，keystone会成为瓶颈点
解决思路：
适当增大各组件token失效列表的缓存时间
revocation_cache_time
备注： openstack的nova,cinder，neutron，glance其他服务有这个参数 # DEPRECATED: Determines the frequency at which the list of revoked（取消的） tokens is # retrieved from the Identity service (in seconds). A high number of revocation（取消；撤回） # events combined with a low cache duration may significantly reduce # performance. Only valid for PKI tokens（这个参数仅对pki认证有效）. This option has been deprecated in the # Ocata release and will be removed in the P release. (integer value) # This option is deprecated for removal since Ocata. # Its value may be silently ignored in the future. # Reason: PKI token format is no longer supported. #revocation_cache_time=10