OpenStack大規模部署優化之二：穩態優化

OpenStack在架構設計上是松耦合解耦架構，天生支持橫向擴展；但真正在大規模部署過程中，仍有好多因素決定其部署規模。本文從穩態方面總結分享原生OpenStack支撐大規模(千節點量級)部署的優化思路 OpenStack隨著計算節點規模增大，計算節點上的各服務的agent個數會隨之增加，比如nova-compute、neutron-agent、ceilometer-agent等。在穩態下，由於個agent存在周期性任務，隨著這些agent的增加，主要是周期任務會對系統造成壓力，優化點如下。

調整MQ連接數，降低MQ壓力

問題描述：OpenStack各服務內部通信都是通過RPC來交互，各agent都需要去連接MQ；隨著各服務agent增多，MQ的連接數會隨之增多，最終可能會到達上限，成為瓶頸 解決思路1：調整各Agent的RPC連接池大小；連接池默認大小為30，假如有1000個計算節點，nova-compute所需的MQ連接數上限總數就是3W，所以在真正部署過程中，需要對此值進行權衡優化；對應參數如下：

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

解決思路2：提升MQ連接數上限；MQ的連接數取決於ulimit文件描述符的限制，一般預設值為1024，對於MQ伺服器來說此值偏小，所以需要重新設置linux系統中文件描述符的最大值，設置方法具體如下。 （1）通過rabbitmqctl命令查看rabbitmq當前支持的最大連接數

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

（2）通過ulimit查看當前系統中文件描述符的最大值

[root@local~]# ulimit -nn1024n

（3）調整最大值 方式1：在rabbitmq啟動腳本中增加ulimit -n 10240，修改rabbitmq進程的文件描述符最大值 方式2：修改/etc/security/limits.conf文件中的如下配置

user soft nofile 10240nuser hard nofile 10240n

方式3：修改/etc/sysctl.conf文件，增加如下配置項

fs.file-max=10240n

優化周期任務，減少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]n# Seconds between nodes reporting state to datastore (integer value) nreport_interval=10n

解決思路2：對MQ進行分庫處理，不同服務採用不同的MQ

優化周期任務，減少資料庫壓力

問題描述：穩態下各agent存在一些周期任務周期調用資料庫操作，nova-compute資料庫操作是通過RPC到nova-conductor進行，隨著計算節點增多，資料庫以及nova-conductor壓力會隨之增大 解決思路1：優化周期任務周期，同上；當然在上報心跳的周期也可以採用memcache存儲後端，直接減少不必要的資料庫調用，配置項如下

# This option specifies the driver to be used for the servicegroup service. n# ServiceGroup API in nova enables checking status of a compute node. When a n# compute worker running the nova-compute daemon starts, it calls the join API n# to join the compute group. Services like nova scheduler can query the n# ServiceGroup API to check if a node is alive. Internally, the ServiceGroup n# client driver automatically updates the compute worker status. There are n# multiple backend implementations for this service: Database ServiceGroup driver n# and Memcache ServiceGroup driver. # Possible Values: n# * db : Database ServiceGroup driver n# * mc : Memcache ServiceGroup drivernservicegroup_driver = mcn

解決思路2：調整nova-conductor對應的worker數目，支撐大規模場景，對應參數如下

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

推薦閱讀：