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。
配置項較少，主要是要權衡配置什麼樣的後端驅動，來存儲 token，一般是 SQL 資料庫，也可以是 memcache。sql 可以持久化存儲，而 memcache 則速度更快，尤其是當用戶要更新密碼的時候，需要刪除所有過期的 token，這種情況下 SQL 的速度與 memcache 相差很大很大。
包括兩個部分，glance-api 和 glance-registry，：
workers = 2
glance-api 處理請求的子進程數量，如果配置成 0，則只有一個主進程，相應的配置成 2，則有一個主進程加 2 個子進程來並發處理請求。建議根據進程所在的物理節點計算能力和雲平臺請求量來綜合確定。
api_limit_max = 1000
與 nova 中的配置 osapi_max_limit 意義相同
limit_param_default = 1000
一個響應中最大返回項數，可以在請求參數中指定，默認是 25，如果設置過短，可能導致響應數據被截斷。
在私有雲平臺的體系架構中， OpenStack 依賴一些底層軟體，如虛擬化軟體，虛擬化管理軟體和 Linux 內核。這些軟體的穩定性以及性能關係著整個雲平臺的穩定性和性能。因此，這些軟體的版本選擇和配置調優也是網易私有雲開發中的一個重要因素。
在網易私有雲平臺中，我們選用的是 Linux 內核兼容最好的 KVM 虛擬化技術。相對於 Xen 虛擬化技術，KVM 虛擬化技術與 Linux 內核聯繫更為緊密，更容易維護。選擇 KVM 虛擬化技術後，虛擬化管理驅動採用了 OpenStack 社區為 KVM 配置的計算驅動 libvirt，這也是一套使用非常廣泛，社區活躍度很高的一套開源虛擬化管理軟體，支持 KVM 在內的各種虛擬化管理。
另一方面，網易採用開源的 Debian 作為自己的宿主機內核，源使用的是 Debian 的 wheezy 穩定分支，KVM 和 libvirt 採用的也是 Debian 社區 wheezy 源裡面的包版本：
qemu-kvm 1.1.2+dfsg-6+deb7u3libvirt-bin 0.9.12
在內核的選型方面，我們主要考慮如下兩方面的因素：
綜合上述因素的考慮，我們選擇了 Debian 社區的 Linux 3.10.40 內核原始碼，並且打開了 CPU/mem/blkio 等 cgroup配置選項以及 user namespace 等 namespace 選項，自己編譯了一個適配網易私有雲的 Linux 內核。從使用情況來看，選擇上述版本的OpenStack 底層依賴軟體後，網易私有雲運行還比較穩定，我們後續還會適時的對這些軟體進行更新。
在網易私有雲的穩定性得到了保障之後，我們開始了性能方面的調優工作。這一方面，我們參考了 IBM 公司的一些 優秀實踐，在 CPU、內存、I/O 等方面做了一些配置方面的優化。整體而言，網易私有雲在注重穩定性的基礎上，也會積極借鑑業界優秀實踐來優化私有雲平臺的整體性能。
為了保障雲主機的計算能力，網易私有雲開發了 CPU QoS 技術，具體來說就是採用 cfs 的時間片均勻調度，外加 process pinning 的綁定技術。
參考 IBM 的分析，我們了解到了 process pinning 技術的優缺點，並且經過測試也驗證了不同綁定方式的雲主機間的性能存在較大的差異。比如，2 個 VCPU 分別綁定到不同 numa 節點的非超線程核上和分配到一對相鄰的超線程核上的性能相差有 30%~40%(通過 SPEC CPU2006 工具測試)。另一方面，CPU0 由於處理中斷請求，本身負荷就較重，不宜再用於雲主機。因此，綜合上面的因素考慮以及多輪的測試驗證，我們最終決定將 0-3 號 CPU 預留出來，然後讓雲主機在剩餘的 CPU 資源中由宿主機內核去調度。最終的 CPU 配置如下所示（libvirt xml 配置）：
<vcpu placement='static' cpuset='4-23'>1</vcpu><cputune> <shares>1024</shares> <period>100000</period> <quota>57499</quota></cputune>
內存配置優化內存配置方面，網易私有雲的實踐是關閉 KVM 內存共享，打開透明大頁：
echo 0 > /sys/kernel/mm/ksm/pages_shared echo 0 > /sys/kernel/mm/ksm/pages_sharing echo always > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
經過 SPEC CPU2006 測試，這些配置對雲主機 CPU 性能大概有 7%左右的提升。
1）磁碟 I/O 的配置優化主要包含如下方面：
KVM 的 disk cache 方式：借鑑 IBM 的分析，網易私有雲採用 none 這種 cache 方式。
disk io scheduler：目前網易私有雲的宿主機磁碟調度策略選用的是 cfq。在實際使用過程中，我們發現 cfq 的調度策略，對那些地低配置磁碟很容易出現 I/O 調度隊列過長，utils 100% 的問題。後續網易私有雲也會借鑑 IBM 的實踐，對 cfq 進行參數調優，以及測試 deadline 調度策略。
磁碟 I/O QoS：面對日漸突出的磁碟 I/O 資源緊缺問題，網易私有雲開發了磁碟 I/O QoS，主要是基於 blkio cgroup 來設置其 throttle 參數來實現。由於 libvirt-0.9.12 版本是在 QEMU 中限制磁碟 I/O，並且存在波動問題，所以我們的實現是通過 Nova 執行命令方式寫入到 cgroup 中。同時我們也開發並向 libvirt 社區提交了 blkiotune 的 throttle 接口設置 patch（已在 libvirt-1.2.2 版本中合入）來徹底解決這個問題。
2）網絡 I/O 的配置優化
我們主要是開啟了 vhost_net 模式，來減少網絡延時和增加吞吐量。
OpenStack 也是一個後端系統服務，所有系統運維相關的基本準則都適用，這裡簡單的提幾點實際運維過程中根據遇到的問題總結的一些經驗：
免費訂閱「CSDN雲計算（左）和CSDN大數據（右）」微信公眾號，實時掌握第一手雲中消息，了解最新的大數據進展！
CSDN發布虛擬化、Docker、OpenStack、CloudStack、數據中心等相關雲計算資訊， 分享Hadoop、Spark、NoSQL/NewSQL、HBase、Impala、內存計算、流計算、機器學習和智能算法等相關大數據觀點，提供雲計算和大數據技術、平臺、實踐和產業信息等服務。