不太完整，後續待補充
1. Nova關鍵參數調優：
#建議值是預留前幾個物理 CPU，把後面的所有 CPU 分配給虛擬機使用
vcpu_pin_set
#cat /proc/cpuinfo裏面的邏輯核數，再x16就是你能夠分配給虛擬機的。內存也是類似
cat /proc/cpuinfo | grep "cpu cores" | uniq
#物理 CPU 超售比例，默認是 16 倍，超線程也算作一個物理 CPU，需要根據具體負載和物理 CPU 能力進行綜合判斷後確定具體的配置
cpu_allocation_ratio = 4.0
#內存分配超售比例，默認是 1.5 倍，生產環境不建議開啓超售。
ram_allocation_ratio = 1.0
#內存預留量，這部分內存不能被虛擬機使用
reserved_host_memory_mb = 4096
#磁盤預留空間，這部分空間不能被虛擬機使用
reserved_host_disk_mb = 10240
#服務下線時間閾值，默認60，如果一個節點上的 nova 服務超過這個時間沒有上報心跳到數據庫，api 服務會認爲該服務已經下線，如果配置過短或過長，都會導致誤判。
service_down_time = 120
#調用超時時間，由於 Python 的單進程不能真正的併發，所以 RPC 請求可能不能及時響應，尤其是目標節點在執行耗時較長的定時任務時，所以需要綜合考慮超時時間和等待容忍時間。
rpc_response_timeout = 300 RPC
2. keystone關鍵參數調優：
主要是用來來存儲 token，一般是 SQL 數據庫，也可以是 memcache。sql 可以持久化存儲，而 memcache 則速度更快，尤其是當用戶要更新密碼的時候，需要刪除所有過期的 token，這種情況下 SQL 的速度與 memcache 相差很大很大。
3. glance關鍵參數調優：
glance-api.conf
#與nova配置中的osapi_max_limit意義相同;最大返回數據長度限制，如果設置過短,會導致部分響應數據被截斷。
api_limit_max = 1000
#一個響應中最大返回項數，可以在請求參數中指定，默認是 25，如果設置過短，可能導致響應數據被截斷。
limit_param_default = 1000
4. openstack底層依賴軟件版本、配置以及調優
1.虛擬化技術選型
我們選用的是 Linux 內核兼容最好的 KVM 虛擬化技術。相對於 Xen 虛擬化技術，KVM 虛擬化技術與 Linux 內核聯繫更爲緊密，更容易維護。選擇 KVM 虛擬化技術後，虛擬化管理驅動採用了 OpenStack 社區爲 KVM 配置的計算驅動 libvirt，這也是一套使用非常廣泛，社區活躍度很高的一套開源虛擬化管理軟件，支持 KVM 在內的各種虛擬化管理。
2.CPU配置優化
CPU0 由於處理中斷請求，本身負荷就較重，不宜再用於雲主機。因此，綜合上面的因素考慮以及多輪的測試驗證，最終是要將 0-3 號 CPU 預留出來，然後讓雲主機在剩餘的 CPU 資源中由宿主機內核去調度。
3.內存配置優化
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
4.IO配置優化
磁盤IO調優KVM 的 disk cache 方式：借鑑 IBM 的分析，採用 none 這種 cache 方式
5.網絡IO調優
我們主要是開啓了 vhost_net 模式，來減少網絡延時和增加吞吐量
5. 使用卷創建實例報錯的故障
did not finish being created even after we waited 241 seconds or 61 attempts. A its status is downloading.
即使等待了241秒或61次嘗試，仍無法完成創建。 其狀態爲下載中。
OpenStack創建實例提示失敗的具體原因如下：
解決辦法
在計算節點上的nova.conf中有一個控制卷設備重試的參數：block_device_allocate_retries，可以通過修改此參數延長等待時間。
該參數默認值爲60，這個對應了之前實例創建失敗消息裏的61 attempts。我們可以將此參數設置的大一點,例如：180。這樣Nova組件就不會等待卷創建超時，也即解決了此問題。
然後重啓計算節點服務
openstack-config --set /etc/nova/nova.conf DEFAULT block_device_allocate_retries 180
systemctl restart libvirtd.service openstack-nova-compute.service
6. 虛擬機初始放置策略
Packing： 虛擬機儘量放置在含有虛擬機數量最多的主機上
Stripping: 虛擬機儘量放置在含有虛擬機數量最少的主機上
CPU load balance：虛擬機儘量放在可用core最多的主機上
Memory load balance：虛擬機儘量放在可用memory 最多的主機上
Affinity : 多個虛擬機需要放置在相同的主機上
AntiAffinity: 多個虛擬機需要放在在不同的主機上
CPU Utilization load balance：虛擬機儘量放在CPU利用率最低的主機上
6. 監控和優化策略
https://www.sohu.com/a/101312934_116235
7. openstack虛擬機發放速度優化
https://blog.csdn.net/halcyonbaby/article/details/59800925
8. 虛擬機刪除後停在deleting無法正常刪除的方法
https://www.cnblogs.com/nakky/p/7427560.html
9. cinder卷和ceph塊設備無法刪除
OpenStack常見的22個問題彙總
https://blog.csdn.net/caiyqn/article/details/107642771
#刪除無法刪除的卷，用命令改變卷的狀態，然後刪除
cinder reset-state <volume> --state available
cinder delete <volume>
#刪除殭屍卷的方法
查看當前存在的卷
[root@controller ~]# openstack volume list
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
| 4776c96c-df64-4c40-85e8-28f96f878d8c | | in-use | 1 | Attached to ade2352c-6e91-4a5c-b481-6776a04e0eae on /dev/vdb |
+--------------------------------------+------------------+-----------+------+---------------------------------------------------------------+
登陸數據庫
use cinder;
select找到出錯的數據
select id, status, display_name from volumes where id='4776c96c-df64-4c40-85e8-28f96f878d8c';
修改數據庫記錄狀體
update volumes set deleted=1 where id='4776c96c-df64-4c40-85e8-28f96f878d8c';