nova.conf中的配置項含義

osapi_max_limit = 5000

nova-api-os-compute api 的最大返回數據長度限制，如果設置過短，會導致部分響應數據被截斷。

resume_guests_state_on_host_boot=True

db_state = instance.power_state
drv_state = self._get_power_state(context, instance)
expect_running = (db_state == power_state.RUNNING and
                  drv_state != db_state)

LOG.debug('Current state is %(drv_state)s, state in DB is '
          '%(db_state)s.',
          {'drv_state': drv_state, 'db_state': db_state},
          instance=instance)

if expect_running and CONF.resume_guests_state_on_host_boot:
    LOG.info(_('Rebooting instance after nova-compute restart.'),
             instance=instance)

這個選項會使實例在物理機重啓時，在nova-compute啓動時重新啓動。

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 資源。

if CONF.vcpu_pin_set is None:
    self._vcpu_total = total_pcpus
    return self._vcpu_total

看代碼（nova/virt/libvirt/driver.py）可知，不設置的話，默認是使用所有物理cpu核。

cpu_allocation_ratio = 4.0 (修改後重啓nova-scheduler生效)

物理 CPU 超售比例，默認是 16 倍，超線程也算作一個物理 CPU，需要根據具體負載和物理 CPU 能力進行綜合判斷後確定具體的配置。

cpu_allocation_ratio_opt = cfg.FloatOpt('cpu_allocation_ratio',
        default=16.0,
        help='Virtual CPU to physical CPU allocation ratio which affects '
             'all CPU filters. This configuration specifies a global ratio '
             'for CoreFilter. For AggregateCoreFilter, it will fall back to '
             'this configuration value if no per-aggregate setting found.')

看代碼（nova/scheduler/filters/core_filters.py）可知，默認超分16倍，所以，要想不超分，需顯式在nova.conf中設置爲1.0

ram_allocation_ratio = 1.0 (修改後重啓nova-scheduler生效)

內存分配超售比例，默認是 1.5 倍，生產環境不建議開啓超售。

ram_allocation_ratio_opt = cfg.FloatOpt('ram_allocation_ratio',
        default=1.5,
        help='Virtual ram to physical ram allocation ratio which affects '
             'all ram filters. This configuration specifies a global ratio '
             'for RamFilter. For AggregateRamFilter, it will fall back to '
             'this configuration value if no per-aggregate setting found.')

看代碼（nova/scheduler/filters/ram_filter.py）可知,默認超分1.5倍，所以，要想不超分，需顯式在nova.conf中設置爲1.0

reserved_host_memory_mb = 4096 (修改後重啓nova-compute生效)

內存預留量，這部分內存不能被虛擬機使用

resource_tracker_opts = [
    cfg.IntOpt('reserved_host_disk_mb', default=0,
               help='Amount of disk in MB to reserve for the host'),
    cfg.IntOpt('reserved_host_memory_mb', default=512,
               help='Amount of memory in MB to reserve for the host'),
    cfg.StrOpt('compute_stats_class',
               default='nova.compute.stats.Stats',
               help='Class that will manage stats for the local compute host'),
    cfg.ListOpt('compute_resources',
                default=['vcpu'],
                help='The names of the extra resources to track.'),
]

看代碼（nova/compute/resource_tracker.py）可知，默認保留512MB。但是實際發現這個值只有在不超分的情況下才起作用，在超分的情況下，給所有虛擬機加壓，內存用量會達到物理機內存的值，並沒有體現出給物理機預留的效果，此時會出現oom，從而導致物理機內核選擇一個最耗內存的虛擬機進程將其殺死，虛擬機關閉。

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，如果設置過短，可能導致響應數據被截斷。

OpenStack 底層依賴軟件版本、配置以及性能調優

虛擬化技術選型

在私有云平臺的體系架構中， 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+deb7u3
libvirt-bin  0.9.12

內核選型

在內核的選型方面，我們主要考慮如下兩方面的因素：

• 穩定性：在開發私有云平臺的一開始，穩定性就是網易私有云開發的一大基本原則。我們採用 Debian Linux 版本，相對來說，Debian 的原生內核無疑更爲穩定。這也是我們最開始的一個選擇。
• 功能需求：在網易的定製開發中，爲了保證虛擬機的服務性能，我們開發了 CPU QoS 技術和磁盤 QoS，它依賴底層的 CPU 和 blkio cgroup 支持。因此，我們需要打開內核中的 cgroup 配置選項。另一方面，網易私有云綜合各方面考慮，將支持 LXC 這種容器級別的虛擬化，除了 cgroup 外，LXC 還依賴 Linux 內核中的 namespace 特性。

綜合上述因素的考慮，我們選擇了 Debian 社區的 Linux 3.10.40 內核源代碼，並且打開了 CPU/mem/blkio 等 cgroup 配置選項以及 user namespace 等 namespace 選項，自己編譯了一個適配網易私有云的 Linux 內核。從使用情況來看，選擇上述版本的 OpenStack 底層依賴軟件後，網易私有云運行還比較穩定，我們後續還會適時的對這些軟件進行更新。 

配置優化

在網易私有云的穩定性得到了保障之後，我們開始了性能方面的調優工作。這一方面，我們參考了 IBM 公司的一些 優秀實踐，在 CPU、內存、I/O 等方面做了一些配置方面的優化。整體而言，網易私有云在注重穩定性的基礎上，也會積極借鑑業界優秀實踐來優化私有云平臺的整體性能。

CPU 配置優化

爲了保障雲主機的計算能力，網易私有云開發了 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%左右的提升。

I/O 配置優化

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 模式，來減少網絡延時和增加吞吐量。

運維經驗

使用經驗

• 開源軟件 bug 在所難免，但是新版本比舊版本會好用很多，尤其是對於 OpenStack 這種正在迅速成長壯大的開源軟件來說更是如此，這一點在我們使用過 Essex、Folsom 和 Havana 版本後深有體會，所以建議各種 OpenStack 用戶能及時的跟進社區版本，與社區保持同步。
• 不要輕易的對社區版本進行各類所謂的功能性能方面的"優化"，尤其是在沒有與社區專家交換意見之前，千萬不要輕易下手，否則此類"優化"極有可能演變成故障點或者性能瓶頸點，最終可能導致無法與社區同步，畢竟一個公司或團隊（尤其是小公司、小團隊）的能力和知識儲備，是很難與社區成百上千的各類專家相提並論的。
• 多參考各類大型公司分享的部署架構方案，儘量不要自己閉門造車，尤其是對於開源軟件來說，各類公司、團隊的使用場景千差萬別，各種周邊組件也是應有盡有，多參考業界實踐是最好的方式。
• 一些細節實現可能有很多途徑，但每種方式都有優缺點，需要經過充分的論證、分析、測試驗證後，才能考慮部署到生產環境使用。
• 所有的部署方案、功能設計都要考慮到平滑升級問題，即使你得到的信息是升級時可以停服，仍然要儘量避免這種情況，因爲停服的影響範圍很難界定。

運維準則

OpenStack 也是一個後端系統服務，所有系統運維相關的基本準則都適用，這裏簡單的提幾點實際運維過程中根據遇到的問題總結的一些經驗：

• 配置項默認值與實際環境不匹配可能導致各種問題，尤其是網絡相關配置與硬件有很強的關聯性，生產環境和開發環境硬件異構，導致部分默認值在生產環境不適用。應對準則：每個版本都必須在與線上硬件相同的環境測試過才能上線。
• 做好容量規劃，已分配的配額量要小於雲平臺總容量，否則會出現各種問題，導致運維開發耗費很多不必要的精力去定位分析問題。
• 配置項過多容易出錯，需要與開發人員一起仔細覈對，上線時首先要通過 puppet 的 noop 功能驗證改動是否正確後，才能真正上線。
• 網絡規劃要提前做好，如固定 IP、浮動 IP、VLAN 數量等，網絡擴容難度和風險都比較大，所以提前規劃好是最保險的，一個原則是大比小好，多比少好。
• 網絡隔離要做好，否則用戶網絡安全沒辦法保證。
• 信息安全問題要重視，這個是老生常談的問題了，每個平臺都有相同問題，但還是要重視再重視，一旦出現安全漏洞，所有虛擬機都面臨嚴重威脅。

頂

0