在紅帽資深顧問Marko Myllynen撰寫的這篇博文中，我們將探索九個OpenStack配置和優化選項，幫助您的工作負載實現所要求的性能、可靠性和安全性。
無論OpenStack云管理員在您的云環境中啟用了什么功能，某些優化可在客機內進行。然而，更先進的選項要求提前啟用，而且可能需要特殊的主機能力。這意味著本文介紹的許多選項取決于管理員如何配置云環境，或者可能在某些租戶中不可用，因為這些選項是為某些用戶組預留的。關于本主題的更多信息可見紅帽文檔門戶和紅帽OpenStack鏡像服務綜合指南。同時，上游OpenStack文檔也提供了一些額外指導準則。
對于在任何OpenStack環境中運行的任何虛擬機，需要對以下配置進行評估。這些變更沒有負面影響，而且即使未使用，一般也可以安全地啟用。
0
1 鏡像格式：QCOW還是RAW？
OpenStack存儲配置是云管理員的一個實施選項，而租戶通常無法完整看到。存儲配置也可能隨著時間推移而變化，而無需管理員明確通知，因為他/她通過不同的規范而在配置中增加了容量。
在OpenStack上創建新實例時，該實例基于Glance鏡像。兩種最常見并且推薦使用的鏡像格式是QCOW2和RAW。QCOW2鏡像（來自 QEMU Copy On Write）的體積更小。以擁有一塊100 GB磁盤的服務器為例，RAW格式的鏡像如果格式化為QCOW2格式，其大小可能僅10 GB。無論哪種格式，在通過 virt-sysprep(1)和virt-sparsify(1)將鏡像上傳到Glance之前都需要進行處理。
QCOW2的性能取決于系統管理程序內核和格式版本，最新版本為QCOW2v3（有時稱為QCOW3），比先前的QCOW2性能更優秀，與RAW格式基本相同?？傮w來講，我們假設RAW的整體性能更好，盡管在運行方面存在缺陷（例如缺乏快照），或者上傳或引導時間增加（由于體積更大）。最新的紅帽OpenStack Platform版本自動采用更新的QCOW2v3格式（得益于最近的RHEL版本），而且該版本可以檢查并且利用 qemu-img(1)在RAW和更老/更新的QCOW2鏡像間進行轉換。
OpenStack實例可以從本地鏡像或者遠程卷中引導。這意味著：
根據一般經驗，極少使用的鏡像應以QCOW2格式存儲在Glance中，但對于經常用于創建新事例（在本地存儲）的鏡像，或者用于創建卷支持的事例的鏡像，使用RAW能夠提供更好的性能，盡管有時初始引導時間更長（Ceph支持的系統除外，原因是它采用了邊寫入邊復制的方法）。最后，任何實際的建議都依賴于云管理員所選擇的OpenStack存儲配置。
0
2 通過鏡像額外屬性進行性能調整
從Mitaka版本起，OpenStack允許Nova自動優化計算主機上的某些libvirt和KVM屬性，目的是更好地執行客機中的特定OS。要向Nova提供客機OS信息，只需定義以下Glance鏡像屬性：
此外，至少在目前，為了保證使用更新和更具擴展能力的virtio-scsi超虛擬化SCSI控制器取代舊的virt-blk，需要明確設置以下屬性：
支持的所有鏡像屬性在紅帽文檔門戶和其他CLI選項中列出。
0
3 為Cloud-init做好準備
“Cloud-init” 是用于云實例早期初始化的程序包，用于配置基本信息，例如分區/文件系統大小和SSH密鑰。
您要保證已經在Glance鏡像中安裝了cloud-init和cloud-utils-growpart程序包，而且相關服務將在引導時執行，以允許執行針對OpenStack VM的 “cloud-init” 配置。
許多情況下可以接受默認配置，但也有許多定制選項可以使用。
0
4 啟用QEMU客機代理
在Linux主機上，建議安裝并啟用QEMU客機代理，以允許正常關機和（將來）需要快照時客機文件系統的自動凍結，這是一致備份的必要操作：
為了提供必需的虛擬設備，并且在需要時使用文件系統凍結功能，需要為Glance鏡像定義以下屬性：
0
5 從客機故障狀態恢復
全面的實例故障恢復、高可用性和服務監控需要采用分層的方法。在下文中，我們列出了僅可用于客機內的選項（可視為最內層）。最常用的實例故障恢復機制有：
從內核癱瘓狀態恢復
從客機掛起狀態恢復（不一定涉及到內核癱瘓/錯誤）
在極少發生的客機內核癱瘓的情況下，kexec/kdump將捕獲內核vmcore，用于提供進一步分析和客機重新引導。如果不需要vmcore，通過設置錯誤內核參數，例如“panic=1”，內核可以在癱瘓后按照指令重新引導。
為了在發生其他意外行為后對實例進行重新引導，例如某個閾值的高負荷，或者在沒有內核錯誤時的整個系統鎖定，可以使用watchdog服務。以下屬性需要對Glance鏡像或Nova Flavor而定義。
然后，在客機內安裝與配置watchdog程序包，最后啟用該服務：
根據默認設置，watchdog檢測到內核癱瘓和整個系統鎖定。例如，如何在watchdog功能檢查過程中添加健康監控腳本。
0
6 調試內核
調試Linux代碼的最簡單方式是使用 “tuned” 工具。這種服務可根據所選的檔案配置幾十個系統參數，對于OpenStack，它是“虛擬客機”。對于NFV工作負載，紅帽提供了一組NFV調試檔案，用于簡化網絡密集型虛擬機的調試。
在您的Glance鏡像中，建議安裝所要求的程序包，在引導時啟用服務，然后激活首選的檔案。您可以在將鏡像上傳到Glance之前編輯鏡像，也可以作為cloud-init配置的一部分：
0
7 通過VirtIO多隊列增強網絡能力
客機內核virtio驅動程序是標準RHEL/Linux內核程序包的一部分，并且自動啟用，而不需要根據需要進一步配置。對于特定的Windows版本，Windows客機也應使用官方virtio驅動程序，用于顯著提高網絡和磁盤IO性能。
然而，在Linux內核和用戶空間組件中網絡程序包處理方面，最新的發展提供了大量用于調試或繞開virtio驅動程序的額外選項。下文列出了一種virtio設備模型。
網絡多隊列（或者叫virtio-net多隊列）方法實現了并行數據包處理，這樣能夠隨著客機可用vCPU數量而線性擴展，從而實現傳輸速度的顯著提高，特別是對于vhost-user。
由于OpenStack Admin配置了帶有支持組件的虛擬化主機（至少OVS 2.5 / DPDK 2.2），這一功能可由OpenStack Tenant通過需要網絡多隊列的這些Glance鏡像中的以下屬性啟用：
在從該鏡像完成初始化的客機中，可通過以下命令檢查并更改NIC通道設置：
另外有一個開放RFE，用于實施多隊列激活，這是內核中的默認功能。
0
8 客機的其他雜項調試
毫無疑問，規模適當的實例僅包含最少的程序包，并且僅運行所需的服務。特別需要注意的是，安裝并啟用irqbalance服務可能是一種很好的做法，盡管這并非在所有情況下都絕對有必要，但該服務的開銷最低，并且應該在SR-IOV設置中使用。
即使在KVM上采用隱性設置，明確添加內核參數no_timer_check是一種很好的做法，這可以避免定時設備出現問題。分別使用PERSISTENT_DHCLIENT=yes和NOZEROCONF=yes啟用永久DHCP客戶端，并禁用網絡配置中的zeroconf路徑有助于避免網絡極端狀況的問題。
根據默認設置，客機MTU設置一般都能夠正確地調整，但在堆棧的所有級別使用正確的MTU對于實現最高網絡性能至關重要。在配有10G（以及更快）NIC的環境中，這一般意味著要使用MTU高達9000的Jumbo Frames，同時考慮可能的VXLAN封裝。
0
9 改善您接入實例的方式
盡管某些純粹主義者可能考慮在純云原生實例中以不兼容的方式運行SSH，尤其是在自動擴展的生產工作負載中，但我們絕大多數人仍然依賴優秀的舊有SSH來執行配置任務（例如通過Ansible）以及維護和故障排除（例如，在軟件故障后提取日志）。
SSH daemon應避免DNS查詢，目的是加快建立SSH連接。對于這一要求，考慮在/etc/ssh/sshd_config 中采用UseDNS no，并向/etc/sysconfig/sshd增加OPTIONS=-u0。如果未使用Kerberos，可以考慮設置GSSAPIAuthentication no。如果實例頻繁地互相連接，也可以考慮ControlPersist / ControlMaster選項。
一般來說，遠程SSH接入和采用Horizon通過控制臺接入對于大多數情況已經足夠。在開發階段，從Nova計算主機直接通過控制臺接入也可能很有幫助，要做到這一點，需啟用[email protected]，允許根據需要通過向 /etc/securetty添加ttyS1 而通過ttyS1進行根接入，然后利用virsh console –devname serial1從Nova計算主機接入客機控制臺。
我們希望您通過本篇博文發現增強OpenStack實例性能的新方式。
