OpenStack大規模部署優化之一：並發業務優化

OpenStack在架構設計上是松耦合解耦架構，天生支持橫向擴展；但真正在大規模部署過程中，仍有好多因素決定其部署規模。本文從業務並發方面總結分享原生OpenStack支撐大規模(千節點量級)部署的優化思路 在大規模並發業務過程中，主要是去除紅綠燈（資料庫行級鎖）解決鎖搶佔問題，以及修多條高速公路(調整各組件進程數)最終提升各組件的處理能力

調整haproxy進程數，提升Loadbalance能力

問題描述：在openstack部署過程中，通常採用haproxy作為前端負載均衡器，在大規模並發過程中，需要觀察haproxy的CPU使用率，如果到達了100%，則需要進行優化 解決思路：調整haproxy的進程數，支撐大規模並發，參數如下

globaln nbproc 16 #進程個數 n

調整OpenStack各組件進程數，提升組件處理能力

問題描述:在大規模業務並發並發過程中，各組件處理能力不足（可以觀察進程對應cpu使用率，如果已經到100%，說明處理能力不足） 解決思路:可以通過橫向擴展組件或調整組件worker數來解決

資料庫、MQ分庫處理，提升性能

問題描述：大規模並發過程中，業務處理會對資料庫和MQ，造成比較大的壓力，導致業務下發失敗 解決思路：對MQ和資料庫進行分庫處理，不同服務採用不同的庫進行優化

優化資料庫連接數，減少資料庫連接總數

問題描述：並發業務處理，需要連接資料庫，並發度高的時候，提示資料庫連接超過了上限 解決思路：調整各組件的資料庫連接數配置，取決於max_pool_size（連接池大小）和max_overflow（最大允許超出的連接數）

[database]n# Maximum number of SQL connections to keep open in a pool. (integer value) nmax_pool_size=10n n# If set, use this value for max_overflow with SQLAlchemy. (integer value) nmax_overflow=10n

採用緩存調度器，提升虛擬機調度時間

問題描述：並發調度過程中，調度前都會去資料庫讀取主機信息，耗時長導致調度時間長 解決思路：採用緩存調度器，緩存主機信息，提升調度時間

#caching_scheduler which aggressively caches the system state for better nscheduler_driver=caching_schedulern

基於存儲內部快速複製能力，縮短鏡像創建卷的時間

問題描述:單個虛擬機創建耗時長的點主要集中在鏡像創建卷，在創建過程中，需要下載鏡像，所以創建時間跟鏡像大小以及網路帶寬強相關 解決思路:可以基於存儲內部快速複製卷的能力，解決系統卷創建慢的問題，有以下三種方式 方式1：在cinder上對鏡像卷進行緩存 openstack社區提供了緩存鏡像卷的能力，核心思想，第一次創建卷的時候，在存儲後端緩存對應的鏡像卷，後續創建都是基於這個鏡像卷複製一個新的卷。

社區相關鏈接：http://docs.openstack.org/admin-guide/blockstorage-image-volume-cache.html

方式2：glance後端對接cinder，鏡像直接以卷的形式存在cinder上 這種方式，在鏡像上傳的過程中，直接以卷的形式存放，在從鏡像創建的卷的過程中，直接走卷複製卷的能力。這種方式可以解決首次發放慢的問題。

社區相關鏈接：https://specs.openstack.org/openstack/cinder-specs/specs/liberty/clone-image-in-glance-cinder-backend.html

方式3：基於存儲的差分卷能力實現卷的快速創建 這一功能需要實現cinder volume中的clone_image方法，在這個方法裡面，可以先緩存鏡像快照，然後基於快照創建差分卷

採用rootwrap daemon方式運行命令，縮短nova/neutron等組件調用系統命令的時間

問題描述:rootwrap 主要用來做許可權控制。在openstack中，非root用戶想執行需要root許可權相關的命令時，用rootwrap來控制。 啟動虛擬機過程中，會多次調用系統命令；調用命令時，會經過rootwrap命令進行封裝，這個命令在每次允許過程中，都會載入命令白名單（允許nova組件執行命令的列表配置文件），最終再調用實際命令運行，額外耗時100ms左右。 解決思路:通過rootwrap daemon機制來解決，啟動一個rootwrap daemon專門接受執行命令的請求，節省每次載入白名單的時間 nova-compute對應的rootwrap配置項：

[DEFAULT]nuse_rootwrap_daemon=Truen

社區相關鏈接：http://docs.openstack.org/admin-guide/compute-root-wrap-reference.html

Qutoa無鎖化優化，減少操作Quota時的耗時

問題描述：openstack在Quota處理過程中，採用了資料庫行級鎖來解決並發更新問題，但在並發場景下，這個鎖會導致耗時增加 解決思路：由於在處理Quota過程中，先select在update，所以需要加鎖（悲觀鎖）。針對這一點，可以通過帶有where的update操作來實現更新，然後根據更新行數，判斷是否更新成功（樂觀鎖）

社區相關鏈接：http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/lock-free-quota-management.html

調整nova-compute並發創建任務上線，提升組件的並發能力

問題描述：nova-compute在並發創建虛擬機過程中，有並發任務限制（M版本默認值為10） 解決思路：增大並發任務個數上線，對應參數為max_concurrent_builds

keystone採用PKI機制替換UUID方式，減少keystone壓力

問題描述：openstack api server在處理請求前會校驗token是否合法，如果採用UUID token，則每次都會去keystone做校驗 解決思路：採用PKI方式，各api在本地通過證書來校驗token是否合法

適當增大各組件token失效列表的緩存時間，可以減少keystone的壓力

問題描述：openstack api server在處理請求前會校驗token是否合法，除了校驗token是否過期，同時還校驗token是否在token失效列表裡面；這個token失效列表會在本地緩存，如果過期，則會去keystone重新獲取，在並發的時候，keystone會成為瓶頸點 解決思路：適當增大各組件token失效列表的緩存時間revocation_cache_time