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