背景
OpenStack Havana 的配置項成百上千，大部分配置項都是可以使用默認值的，否則光是理解這么多的配置項的含義就足以讓運維人員崩潰，尤其是對那些并不熟悉源碼的運維人員來說 更是如此。下文將列舉若干網易私有云中較關鍵的配置項，并解釋它們如何影響到服務的功能，安全性，以及性能等問題。
Nova 關鍵配置
my_ip = 內網地址
此項是用來生成宿主機上的 nova metadata api 請求轉發 iptables 規則，如果配置不當，會導致虛擬機內部無法通過 169.254.169.254 這個 IP 獲取 ec2/OpenStack metadata 信息；生成的 iptable 規則形如：
-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT \ --to-destination ${my_ip}:8775
它另外的用途是虛擬機在 resize、cold migrate 等操作時，與目的端宿主機進行數據通信。該項的默認值為宿主機的外網 IP 地址，建議改為內網地址以避免潛在的安全風險。
metadata_listen = 內網地址
此項是 nova-api-metadata 服務監聽的 IP 地址，可以從上面的 iptables 規則里面看出它與 my_ip 的配置項有一定的關聯，保持一致是最明智的選擇。
novncproxy_base_url = vncserver_proxyclient_address = ${private_ip_of_compute_host} vncserver_listen = ${private_ip_of_compute_host} novncproxy_host = ${private_ip_of_host}
我們僅在部分節點上部署 novncproxy 進程，并把這些進程加入到 HAProxy 服務中實現 novnc 代理進程的高可用，多個 HAProxy 進程使用 Keepalived 實施 HAProxy 的高可用，對外只需要暴露 Keepalived 管理的虛擬 IP 地址即可：
這種部署方式好處是：
1）實現 novnc 代理服務的高可用
2）不會暴露云平臺相關節點的外網地址
3）易于 novnc 代理服務的擴容
但也有不足：
1）虛擬機都監聽在其所在的計算節點的內網 IP 地址，一旦虛擬機與宿主機的網絡隔離出現問題，會導致所有虛擬機的 VNC 地址接口暴露出去
2）在線遷移時會遇到問題，因為 VNC 監聽的內網 IP 在目的端計算節點是不存在的，不過這個問題 nova 社區已經在解決了，相信很快就會合入 J 版本。
resume_guests_state_on_host_boot = true
在 nova-compute 進程啟動時，啟動應該處于運行狀態的虛擬機，應該處于運行狀態的意思是 nova 數據庫中的虛擬機記錄是運行狀態，但在 Hypervisor 上該虛擬機沒有運行，在計算節點重啟時，該配置項具有很大的用處，它可以讓節點上所有虛擬機都自動運行起來，節省運維人員手工處理的時間。
api_rate_limit = false
不限制 API 訪問頻率，打開之后 API 的并發訪問數量會受到限制，可以根據云平臺的訪問量及 API 進程的數量和承受能力來判斷是否需要打開，如果關閉該選項，則大并發情況下 API 請求處理時間會比較久。
osapi_max_limit = 5000
nova-api-os-compute api 的最大返回數據長度限制，如果設置過短，會導致部分響應數據被截斷。
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ImagePropertiesFilter, JsonFilter, EcuFilter, CoreFilter
nova-scheduler 可用的過濾器，Retry 是用來跳過已經嘗試創建但是失敗的計算節點，防止重調度死循環；AvailabilityZone 是過濾那些用戶指定的 AZ 的，防止用戶的虛擬機創建到未指定的 AZ 里面；Ram 是過濾掉內存不足的計算節點；Core 是過濾掉 VCPU 數量不足的計算節點；Ecu 是我們自己開發的過濾器，配合我們的 CPU QoS 功能開發的，用來過濾掉 ecu 數量不足的計算節點；ImageProperties 是過濾掉不符合鏡像要求的計算節點，比如 QEMU 虛擬機所用的鏡像不能在 LXC 計算節點上使用；Json 是匹配自定義的節點選擇規則，比如不可以創建到某些 AZ，要與那些虛擬機創建到相同 AZ 等。其他還有一些過濾器可以根據需求進行選擇。
running_deleted_instance_action = reap
nova-compute 定時任務發現在數據庫中已經刪除，但計算節點的 Hypervisor 中還存在的虛擬機（也即野虛擬機審計操作方式）后的處理動作，建議是選擇 log 或者 reap。log 方式需要運維人員根據日志記錄找到那些野虛擬機并手工執行后續的動作，這種方式比較保險，防止由于 nova 服務出現未知異常或者 bug 時導致用戶虛擬機被清理掉等問題，而 reap 方式則可以節省運維人員的人工介入時間。
until_refresh = 5
用戶配額與 instances 表中實際使用量的同步閾值，也即用戶的配額被修改多少次后強制同步一次使用量到配額量記錄
max_age = 86400
用戶配額與實際使用量的同步時間間隔，也即距上次配額記錄更新多少秒后，再次更新時會自動與實際使用量同步。
眾所周知，開源的 nova 項目目前仍然有很多配額方面的 bug 沒有解決，上面兩個配置項可以在很大程度上解決用戶配額使用情況與實際使用量不匹配的問題，但也會帶來一定的數據庫性能開銷，需要根據實際部署情況進行合理設置。
計算節點資源預留
vcpu_pin_set = 4-$
虛擬機 vCPU 的綁定范圍，可以防止虛擬機爭搶宿主機進程的 CPU 資源，建議值是預留前幾個物理 CPU，把后面的所有 CPU 分配給虛擬機使用，可以配合 cgroup 或者內核啟動參數來實現宿主機進程不占用虛擬機使用的那些 CPU 資源。
cpu_allocation_ratio = 4.0
物理 CPU 超售比例，默認是 16 倍，超線程也算作一個物理 CPU，需要根據具體負載和物理 CPU 能力進行綜合判斷后確定具體的配置。
ram_allocation_ratio = 1.0
內存分配超售比例，默認是 1.5 倍，生產環境不建議開啟超售。
reserved_host_memory_mb = 4096
內存預留量，這部分內存不能被虛擬機使用
reserved_host_disk_mb = 10240
磁盤預留空間，這部分空間不能被虛擬機使用
service_down_time = 120
服務下線時間閾值，如果一個節點上的 nova 服務超過這個時間沒有上報心跳到數據庫，api 服務會認為該服務已經下線，如果配置過短或過長，都會導致誤判。
rpc_response_timeout = 300
RPC 調用超時時間，由于 Python 的單進程不能真正的并發，所以 RPC 請求可能不能及時響應，尤其是目標節點在執行耗時較長的定時任務時，所以需要綜合考慮超時時間和等待容忍時間。
multi_host = True
是否開啟 nova-network 的多節點模式，如果需要多節點部署，則該項需要設置為 True。
Keystone
配置項較少，主要是要權衡配置什么樣的后端驅動，來存儲 token，一般是 SQL 數據庫，也可以是 memcache。sql 可以持久化存儲，而 memcache 則速度更快，尤其是當用戶要更新密碼的時候，需要刪除所有過期的 token，這種情況下 SQL 的速度與 memcache 相差很大很大。
glance
包括兩個部分，glance-api 和 glance-registry，：
workers = 2
glance-api 處理請求的子進程數量，如果配置成 0，則只有一個主進程，相應的配置成 2，則有一個主進程加 2 個子進程來并發處理請求。建議根據進程所在的物理節點計算能力和云平臺請求量來綜合確定。
api_limit_max = 1000
與 nova 中的配置 osapi_max_limit 意義相同
limit_param_default = 1000
一個響應中最大返回項數，可以在請求參數中指定，默認是 25，如果設置過短，可能導致響應數據被截斷。
