驗(yàn)收easystack escloud云平臺運(yùn)維手冊

1、1.1.1rootnode-1NovaNova計算虛擬檢化查組service-list件狀態(tài)#nova根據(jù)輸出，查看 Se 是否存在 down 的情況，如果沒有證明整個集群工作正常。如果有 down 的情況需及時進(jìn)行處理。Nova 服務(wù) down 掉，不會影響虛機(jī)運(yùn)行， 但對相關(guān)物理機(jī)上的虛機(jī)操作會有影響（如開關(guān)機(jī)，遷移等等）?？蓢L試重啟相應(yīng)服務(wù)。1.2 Nova 常用命令列出可用的實(shí)例nova list -all-tenantnovalist-all-tenant-hostnode-4.tld查看實(shí)例詳細(xì)信息nova show testvm01列出可用的 flavornova flavor-

2、list定制 flavor，flavor name=test500 flavornova flavor-create test500 500 512 1 2id=500ram=512Mbcpu=2創(chuàng)建一個vm實(shí)例先獲取 flavor idnova flavor-list |grep 500獲取 image id glance image-list獲取網(wǎng)絡(luò) id neutron net-list創(chuàng)建 vm 實(shí)例 testvm01nova boot -image f911dbae-aaee-4969-8b99-c535d6e18eaa -flavor test500 -nic net-id=b21

3、a53d6-b4c0-4e49-ac78-50a8d66c310f testvm01注釋：-image 后面加鏡像 UUID，使用 glance image-list 查看-flavor 后面加 flavor 的 UUID，使用 nova flavor-list 查看，也可以新建 flavor-nic net-idsubnet后面加網(wǎng)絡(luò) UUID，使用 neutron net-list 查看， 主要是 net，部署-availability-zone 如果不指定由 nova-scheduler 根據(jù)策略自動指定主機(jī)部署，默認(rèn)是 nova。可以通過 zone_name:node-name 將虛擬

4、機(jī)部署到指定的主機(jī)上面，比如：ernal_Zone:node-11.tld前面是 zone 名稱，后面是宿主機(jī)的主機(jī)名先查看未分配 ip，然后分配 floating ip 到實(shí)例先獲取未使用的 floating ip 地址neutron floatingip-list然后獲取 nova 的 idnova list將指定的 floating ip 指定分配給指定的 novanova floating-ip-asste 8919cdf8-25c3-4488-b9ee-fa9580e49b5034創(chuàng)建一個實(shí)例的快照獲取實(shí)例的名稱 testvm01nova list創(chuàng)建實(shí)例的快照 testvm01_s

5、1nova image-create testvm01testvm01_s1啟動/關(guān)閉/刪除一個實(shí)例獲取實(shí)例的 idnova通過指定實(shí)例 id 啟動實(shí)例nova start 3f84a737-e26b-4cee-a5d9-ff44d9458172通過指定實(shí)例關(guān)閉實(shí)例listgnova stop 3f84a737-e26b-4cee-a5d9-ff44d9458172通過指定實(shí)例 id 刪除實(shí)例nova delete 3f84a737-e26b-4cee-a5d9-ff44d9458172Nova 常見問題Nova 服務(wù)相關(guān)問題A.Compute服務(wù)down Nova-cert，nova-put

6、e 服務(wù)。nova 服務(wù)分布在控制節(jié)點(diǎn)和計算節(jié)點(diǎn)上。 其中控制節(jié)點(diǎn)上有consoleauth，nova-scheduler，nova-conductor， 計算節(jié)點(diǎn)上只有其中控制節(jié)點(diǎn)上 nova 服務(wù) down 掉的幾率不大。 計算節(jié)點(diǎn)pute 服務(wù) down 掉時，先 檢 查 相 應(yīng) 節(jié) 點(diǎn) 的 網(wǎng) 絡(luò) 連 接 ， 確 認(rèn) 管 理 網(wǎng) 絡(luò) 正 常 。網(wǎng)絡(luò)檢查正常后，可嘗試 ssh 至問題節(jié)點(diǎn)， /etc/init.duterestart 來嘗試重啟pute 服務(wù)。 此操作不會影響正在運(yùn)行的虛機(jī)。注：導(dǎo)致pute down 的原因還有可能是 ceph不可、rabbitmq 有異常、ntp 時間

7、不同步等原因，一般云時 ， 根 據(jù) /var在運(yùn)行過程中，這些條件不會觸發(fā)，當(dāng)出現(xiàn)異常puog日志信 息定位 問題。B.Compute服務(wù)無法重啟us有時會在重啟pute 服務(wù)后，可執(zhí)行/etc/init.dute來確認(rèn)服務(wù)是否正常啟動。 如果現(xiàn)實(shí)有 progress is not rugnning butx is running.則服務(wù)正常。file exist 的 報 錯 。 此 時 需 要 刪 除再次重啟即可。 如果還有問題，請檢查系統(tǒng)/vaute.文件，rsyslog 服務(wù)，一般出現(xiàn)這種情況，都是由于系統(tǒng) rsyslog 服務(wù)卡死，先重啟 rsyslog 服務(wù)后，再檢查 compute

8、 服務(wù)。注：rsyslog 出現(xiàn)異常時，除了導(dǎo)致pute 有異常之外，還有可能會導(dǎo)致neutron 的一些服務(wù)異常，如 neutron-dhcp-agent、neutron-l3-agent，解決的方法是確保 rsyslog 服務(wù)正常，之后再重啟有故障的服務(wù)。1.3.2 虛擬機(jī)操作問題A .部署，遷移，調(diào)整虛機(jī)失敗有時，由于某些原因，虛機(jī)在遷移，修改大小后報錯，虛機(jī)狀態(tài)為”error”， 可用下列命reset-令回-active復(fù)其狀機(jī)態(tài)uuidnovae nova-conductor.lognova-scheduler.log 如果都沒問題，則檢查相應(yīng)計算節(jié)點(diǎn)上的puog。B. 創(chuàng)建虛擬機(jī)失

9、敗創(chuàng)建虛擬機(jī)是一個復(fù)雜的操作，涉及到 openstack 很多的服務(wù)。當(dāng)用戶提交創(chuàng)建虛擬機(jī)的請求時，請求首先會到達(dá) nova-api 服務(wù)，nova-api 會用戶的請求，隨后調(diào)用pute 完成虛擬機(jī)的創(chuàng)建工作。在創(chuàng)建虛擬機(jī)的過程中，pute 會調(diào)用glance 獲取鏡 像，調(diào)用 neutron 創(chuàng)建網(wǎng)卡，調(diào)用 cinder 掛載 volume，調(diào)用 ceph 創(chuàng)建系統(tǒng)盤。任何一個步驟失敗都會導(dǎo)致虛擬機(jī)創(chuàng)建失敗，所以，在排除虛擬機(jī)創(chuàng)建失敗時，需要了解 openstack 的總體架構(gòu)，熟悉 nova 創(chuàng)建虛擬機(jī)的流程，然后根據(jù)虛擬機(jī)的狀態(tài)及 nova 服務(wù)的日志判斷創(chuàng)建虛擬機(jī) 的操作執(zhí)行到哪步失

10、敗了。創(chuàng)建虛擬機(jī)的過程中調(diào)度失敗故障描述: 執(zhí)行虛擬機(jī)創(chuàng)建操作之后，很長時間虛擬機(jī)還在“創(chuàng)建中”。虛擬機(jī)創(chuàng)建的過程中，需要 nova-scheduler 服務(wù)確定在哪個物理服務(wù)器上運(yùn)行剛剛創(chuàng)建的虛擬機(jī)，如果 nova-scheduler 服務(wù)不響應(yīng)調(diào)度任務(wù)，則虛擬機(jī)可能一直處于scheduling 狀態(tài)。# source /root/openrc# nova show （注意：虛擬機(jī) uuid 要用具體虛擬機(jī)的 uuid 替換）如上圖所示，有幾個關(guān)鍵的字段可以幫助下：判斷具體的原因。這幾個關(guān)鍵字段的含義如字段字段含義Sus在瀏覽器里面，用戶看到的狀態(tài)。sus 是虛擬機(jī)task_se、vm_se

11、、er_se 綜合起來的結(jié)果。OS-EXT-STS:task_senova 管理服務(wù)正在對虛擬機(jī)執(zhí)行的操作。如果為-，則表示沒有人在管理此虛擬機(jī)。OS-EXT-SRV-ATTR:host虛擬機(jī)所在宿主機(jī)的 hostname。如果為-，則表示虛擬機(jī)還沒有確定，一般在剛創(chuàng)建虛擬機(jī)的過程中，調(diào)度器還沒有完成調(diào)度時會顯示為該狀態(tài)。如果 OS-EXT-STS:task_se 為scheduling， 而且 OS-EXT-SRV-ATTR:host 為-，則表示還在等待調(diào)度程序確定運(yùn)行虛擬機(jī)的宿主機(jī)。由此可以判斷 nova-scheduler服務(wù)出問題了。如果調(diào)度沒有問題，或者沒有可用的宿主機(jī)，調(diào)度程序都

12、會很快返回，不會一直停留在scheduling的狀態(tài)。解決問題出現(xiàn)上面的故障有兩種可能性，一種是整個集群沒有可用的 nova-scheduler 實(shí)例；另一種是 nova-scheduler 服務(wù)出問題了。對此，首先要查看整個集群是否有 nova- scheduler 服務(wù)在運(yùn)行。查看方法如下：Nova service-list | grep scheduler整個集群至少需要一個 nova-scheduler 實(shí)例處于up狀態(tài)。需如果集群中至少有一個nova-scheduler 實(shí)例的狀態(tài)是up的，就需要查看查看 nova-scheduler 的日志來進(jìn)一步確定原因了。到控制節(jié)點(diǎn)上，查看/v

13、ar/log/nova/scheduler 日志。tail -f /var/log/nova/schedulernova-scheduler 服務(wù)不能正常工作最常見的一個原因是連不上 RabbitMQ 服務(wù)，或者能連上就是不消費(fèi)隊列中的消息。為此需要查看消息隊列中 nova-scheduler 服務(wù)未消費(fèi)的消息數(shù)目。具體方法是在控制節(jié)點(diǎn)上執(zhí)行下面令：如上圖所示，上面令輸出的第二列是隊列未消費(fèi)的消息數(shù)量，第一列是隊列的名稱。nova-scheduler 服務(wù)使用的隊列名稱是以scheduler開頭，每個 nova-scheduler 會兩個隊列，一個是 scheduler.server-xx 表

14、示這個實(shí)例運(yùn)行在server-xx 上面；另一個是 scheduler_fanout_xx 這個隊列是用來接收調(diào)度服務(wù)的廣播消息。如果這些隊列中的消息數(shù)量一致大于零，就表示隊列中的消息沒有人消費(fèi)?？赡苁蔷W(wǎng)絡(luò)連接，也可能是 nova- scheduler 服務(wù)本身。對于這種情況，可以重啟下 所有的 nova-scheduler 實(shí)例看看問題是否能得到解決。具體如下：/etc/init.d/openstack-nova-scheduler restart創(chuàng)建虛擬機(jī)過程中報 NoValidHost執(zhí)行虛擬機(jī)創(chuàng)建操作之后，虛擬機(jī)的狀態(tài)沒有變?yōu)椤斑\(yùn)行中”，而是變?yōu)榱恕板e誤”，用 nova show 查看

15、虛擬機(jī)狀態(tài)，發(fā)現(xiàn)關(guān)鍵字 NoValidHost登錄控制節(jié)點(diǎn)，執(zhí)行下面 # source /openrc# nova show 令顯示虛擬機(jī)的詳細(xì)信息：（虛擬機(jī) UUID 是創(chuàng)建失敗的虛擬機(jī)的 UUID）如上圖所示，關(guān)鍵信息是 fault 字段中包含了 No valid host was found 這樣的信息。如果出現(xiàn)這類關(guān)鍵信息，可以參考下面的解決辦法。上面的錯誤信息是 nova-scheduler 服務(wù)返回的，表明上的意思是沒有可用的宿主機(jī)，也就是說請求的資源太多了，現(xiàn)在集群中沒有哪個宿主機(jī)有那么多資源，所以請求失敗。由于 nova-scheduler 會封裝為了確定確切的原因，可以通過如

16、下pute 所遇到的錯誤，所以上面的消息不一定準(zhǔn)確。令來查看整個集群的資源占用情況。#+nova hypervisor-ss+|+Property|Value |+|+count current_workload disk_available_least free_disk_gb free_ram_mblocal_gb local_gb_used memory_mb memory_mb_used running_vms vcpusvcpus_used|2| 01226|1702| 43522| 100|204801802|64002|5|1144|+上面令可以顯示集群總體的資源使用情況。相關(guān)字

17、段的含義如下：字段名稱字段含義memory_mb所有宿主機(jī)內(nèi)存總量memory_mb_used已經(jīng)分配給虛擬機(jī)的內(nèi)存總量；openstack 允許內(nèi)存復(fù)用比大于一，所以，這個值可能比 memory_mb 還大vcpus所有宿主機(jī)中 cpu 數(shù)量（總線程）已分配的虛擬機(jī)的 vcpus 總量；openstack 允許 CPU 復(fù)用比大于一，所以，這個值可能比 vcpus 還大vcpus_usedrunning_vms已經(jīng)創(chuàng)建的虛擬機(jī)的總數(shù)，包括關(guān)機(jī)狀態(tài)的虛擬機(jī)以及命令；nova hypervisor-shownode-x.tld 來查看單臺服務(wù)器的使用情況。如果集群系統(tǒng)不夠用了，上面統(tǒng)計的已經(jīng)分配

18、給虛擬機(jī)的 vcpus & 內(nèi)存應(yīng)該都比較高。否則的話，有可能是pute 上某些操作執(zhí)行失敗了。默認(rèn)情況下，調(diào)度器會嘗試三次，在不同的宿主機(jī)上運(yùn)行虛擬機(jī)，如果都失敗，也會報 No valid host 的錯誤。 pute 創(chuàng)建虛擬機(jī)失敗可能有很多原因，可能是調(diào)用 ceph 創(chuàng)建系統(tǒng)盤失敗，也可能是調(diào)用 neutron 創(chuàng)建網(wǎng)卡失敗，也可能是 虛擬化層的錯誤。對于這種情況，需要進(jìn)一步查看pute 及相關(guān)服務(wù)的日志確定具體的原因。具體方法如下：# catpuog | grep -v INFO |grep -v AUDIT | less的情況，強(qiáng)行部署虛機(jī)。 可在其實(shí)，也可以不使用某些 filter

19、， 如忽略掉內(nèi)存/etc/nova/nova.conf文件中修改下列配置：創(chuàng)建虛擬機(jī)過程中申請內(nèi)存失敗執(zhí)行虛擬機(jī)創(chuàng)建操作之后，虛擬機(jī)的狀態(tài)沒有變?yōu)椤斑\(yùn)行中”，而是變?yōu)榱恕板e誤”，用 nova show 查看虛擬機(jī)狀態(tài)，發(fā)現(xiàn)關(guān)鍵字 Cannot allocate memory.由于 openstack 允許的內(nèi)存復(fù)用比是可配置的，而且可以大于 1，所以，有的時候物理機(jī)的可用內(nèi)存可能所剩無幾，但是 nova-scheduler 可能仍然會將虛擬機(jī)調(diào)度到該物理機(jī)運(yùn)行。當(dāng)pute 調(diào)用底層的虛擬化組件運(yùn)行虛擬機(jī)時，虛擬化組件可能會因?yàn)樯暾埐坏阶銐虻膬?nèi)存而失敗。如果是這種原因?qū)е铝藙?chuàng)建虛擬機(jī)失敗，那么在

20、虛擬機(jī)狀態(tài)、pute 的日志、libvirt 的日志中都會相關(guān)的錯誤。所以，還是比較好定位。查看pute 的日志，可以看到類似的錯誤。具體操作如下：5792957c-7935-422a-bd72-7da744c731cb Cannot set up guest memory pc.ram:Cannot allocate memory2015-12-08 14:16:22.726 117355 TRACE5792957c-7935-422a-bd72-7da744c731cbpute.manager instance:如果有這種日志，就可以確定是因?yàn)閯?chuàng)建虛擬機(jī)失敗的原因是內(nèi)存。如果創(chuàng)建虛擬機(jī)因?yàn)?/p>

21、內(nèi)存而失敗，需要檢查是不是虛擬機(jī)所請求的內(nèi)存太大了。如果不是，可能是因?yàn)榧簝?nèi)存使用率已經(jīng)比較高了。這時候，需要檢查所有計算節(jié)點(diǎn)的內(nèi)存占用情況。如果總體內(nèi)存占用比價高，就需要空閑的資源，或者進(jìn)行擴(kuò)容了。另外如果創(chuàng)建出來的虛擬機(jī)如果都是運(yùn)行比較耗內(nèi)存的業(yè)務(wù)，最好將內(nèi)存的復(fù)用比調(diào)低。具體的方法是修改計算節(jié)點(diǎn)的配置文件，調(diào)整 DEFAULT section 下面的 ram_allocation_ratio，將其設(shè)置為 1.0 或者更低（因?yàn)槠渌?wù)也需要消耗內(nèi)存）。具體如下：# cat /etc/nova/nova.confDEFAULTram_allocation_ratio = 1.0修改完配置

22、之后，還需要重啟pute 才能生效。C. 虛擬機(jī) live-migration 無法完成如何遷移虛機(jī)：1. 確定要遷移的虛機(jī)，nova show 獲取虛機(jī)的 uuid，虛機(jī)所在的計算節(jié)點(diǎn)，虛機(jī)的名字（比如 instance-0000004c）。2.3.4.找一個可以遷移上去的計算節(jié)點(diǎn)。在 dashboard 上做熱遷移。在虛機(jī)原來的計算節(jié)點(diǎn)上執(zhí)行如下命令查看遷移的進(jìn)度，比如下面是遷移一個 128G 內(nèi)存的虛機(jī)，可以看到剛開始 Memory remaining: 127.994 GiB。rootnode-7 #Job type: Time elapsed:virsh domjobinfo ins

23、tance-00000183Unbounded7803 ms8.961 MiBData prosed:Data remaining:127.994 GiB128.008 GiB 8.961 MiB127.994 GiB128.008 GiB 1106263810.305 MiBDa Memory MemoryMemoryotal:prosed:remaining:total:Constant pages: Normal pages:Normal data:Expected downtime:30ms一直使用上面命令查看 Memory remaining，如果虛機(jī)內(nèi)存變化太快，Memoryrem

24、aining 基本會減少到幾百兆左右以后，一直上下浮動，這樣的話，虛機(jī)都遷移不完，這時，使用命令 virsh suspend 將虛機(jī)暫停一下，那么虛機(jī)在幾秒之內(nèi)就很快遷移完成。這樣的話，虛機(jī)暫停的時間就可以控制在幾秒內(nèi)。對業(yè)務(wù)也就只有幾秒鐘的影響。 上面的 128G 內(nèi)存虛機(jī)在 12 分鐘遷移完成。如果遷移時間太長，會導(dǎo)致 nova 更新虛機(jī)遷移后的狀態(tài)超時，這時需要手動更新nova 數(shù)據(jù)庫。Nova reset-s e -active -e use nova; update instanwhere uuid=set node=,host=1.3.3 VNC 常見問題為方便用戶登錄和管理虛擬機(jī)

25、，openstack 提供了 vnc服務(wù)，用戶通過瀏覽器就可以虛擬機(jī)的終端，為用戶的管理提供了很大的方便。由于 vnc服務(wù)也是要多個服務(wù)相互協(xié)作才能完成，此外還和虛擬機(jī)的狀態(tài)也有關(guān)系，所以也比較容易出問題。用戶通過瀏覽器虛擬機(jī)的過程大致如下：1. 瀏覽器給 nova-api 發(fā)送請求，獲取虛擬機(jī)的 console 的 URLa. 請求首先到達(dá) nova-api，nova-api 再轉(zhuǎn)給puteb.pute 調(diào)用底層的虛擬化接口，獲取 vnc server 的地址和端，并生產(chǎn)一個隨機(jī)的 token，并通過 nova-consoleauth 對 token 進(jìn)行。一個 URL 返回給瀏覽c.put

26、e 將 vnc server 的連接地址和 token 組器。2. 瀏覽器獲取 console URL 之后，連接 nova-novncproxy 服務(wù)，建立 websocket 連接a.b.c.瀏覽器連接 nova-novncproxy 獲取靜態(tài)文件、css 文件、jsjs連接到 nova-novncproxy 建立 websocket 連接nova-novncproxy 收到 websocket 連接之后，會連接 nova-consoleauth 驗(yàn)證用戶的 token，如果 token 有效，nova-consoleauth 會返回 vnc server 的連接地址和端口。d. Nova

27、-novncproxy 建立 websocket 到 vnc server 的端口轉(zhuǎn)發(fā)，一旦端口轉(zhuǎn)發(fā)建立起來，用戶就可以在瀏覽器里面登陸虛擬機(jī)了。如果pute 服務(wù)有問題，第一步就會失敗，獲取不了 console URL；如果websocket 建立失敗，有可能是虛擬機(jī)關(guān)機(jī)了，也有可能是配置不對，也有可能是 nova-novncproxy 服務(wù)出問題了。具體的排查見下文。A. 獲取 console URL 失敗故障描述獲取 console URL 是 VNC 登陸虛擬機(jī)時要完成的第一個操作，如果這步出錯，那么VNC 登錄虛擬機(jī)肯定會出錯。如果遇到 VNC 登陸不了虛擬機(jī)查是否能夠獲取 cons

28、ole URL。，排查的第一步就是檢問題定位為了確定 VNC 登陸虛擬機(jī)失敗是不是無法獲取 console URL，只需要登錄集群控制節(jié)點(diǎn)，然后執(zhí)行下面令就可以知道。# source /openrc# nova get-vnc-console novnc如果命令執(zhí)行的結(jié)果如下：那說明獲取虛擬機(jī)的 console URL 沒有問題，是其他導(dǎo)致不能登錄虛擬機(jī)，需要參考下面的文檔繼續(xù)進(jìn)行排查。如果上面令執(zhí)行結(jié)果如下：ERROR (CntException): The server has either erred or is incapable ofperforming the requested

29、operation. (HTTP 500)那表示獲取虛擬機(jī)的 console URL 失敗了。問題解決如果不能獲取 console URL，需要先通過 nova show 查看虛擬機(jī)所在的宿主機(jī)，然后查看對應(yīng)宿主機(jī)的pute 服務(wù)的日志，根據(jù)服務(wù)日志進(jìn)行后續(xù)的排查。普遍解決方法：可在三個控制節(jié)點(diǎn)上，均重啟 nova-api,nova-consoleauth 和 nova-novncproxy 服務(wù)。/etc/init.d/openstack-nova-api/etc/init.d/openstack-nova-consoleauth/etc/init.d/openstack-nova-novn

30、cproxyrestart restartrestart之后，可在控制節(jié)虛點(diǎn)機(jī)上uuid執(zhí)行novnc#novaget-vnc-console會直接獲取到控制臺的 ip 地址，直接輸入至瀏覽器，即可打開該虛機(jī)控制臺。1.3.4 Hos配置修改控制結(jié)點(diǎn)配置文件rootnode-1 easystack# vi /etc/easystack/ DEFAULTuse_rpc=Falsedebug = False.conflog_file = inspectors ganglia action_map將虛機(jī)遷移/var/log/nova/hagent.log=,ganglia#先檢測，再檢測s = ga

31、nglia:evacuate#hanglia檢測失效，則觸發(fā) evacuate 動作，#warn_inspectors=ipmi#warn_action_maps=ipmi:livemigratecheck_erval = 5on_shared_storage = TrueAuthusername整 passwordauth_url=admin#admin如果修改，記得調(diào)=adminproject_idganglia= admingmetad_host = gmetad_port =max_reported_8651erval = 20 #測試可以用 20，生產(chǎn)環(huán)境需要調(diào)大如 60，提高判斷率

32、packet_count = 1wait_deadline = 3#調(diào)大 提高判斷準(zhǔn)確性，3# 調(diào)大 提高判斷準(zhǔn)確性,10ipmidefault_vendor = Dell retry_timeout=60mand_erval=5#IPMI 可能誤判，默認(rèn)不使用conf_file_path = /etc/easystack/ipmi.confmax_log_erval=3600warn_checke_methods=single_bine=aller重起服務(wù)resource restart easystack-用 ps -ef |grep確認(rèn)進(jìn)程存在，此進(jìn)程只在三臺控制節(jié)點(diǎn)的其中一臺hagen

33、thagenthagent此 HA 只在宿主機(jī) down 機(jī)，或者網(wǎng)絡(luò)線路斷開的情況下，正常如果網(wǎng)絡(luò)經(jīng)常抖動則容易出現(xiàn)問題，不建議配置在生產(chǎn)環(huán)境。1.3.5A.其為某 些余常用機(jī)為 其操掛掛 載作，載狗 ，配加掛 載置介密 方 式 如紹狗下 ：虛應(yīng) 用 需 要有 1.2.時加 密首先，通過 nova list命令， 找到需要掛載加 密狗的虛機(jī)， 以及 其 uuid其次通過 nova show 命令，得到虛機(jī)所在的物理機(jī)，及其 instance-name如 上 圖 ， 該 虛 機(jī) 在node-5 上 ，instance_name為 instance-00000413. 將加密狗插到 node-5

34、 上， ssh 至 node-5 ， 執(zhí)行 virshlist -all存install， 根據(jù)instance_name確上 ，lsusb認(rèn)安 裝命虛usbutils機(jī)包查是否在。4.5.在使node-5用。詢Yum插usbutils令，上的加密狗上圖 中， Aladdin KnowledgeSystem即為 加密 狗。 記住ID 0529:00036.編輯生成usb_device.xml文件#vimusb_device.xmlvendor7.id即 為掛id的 前 半載部，product加id為 后 半 部 。密狗usb_device.xml#virshDeviceattach-devic

35、eattached sucsfullyB.虛live-migration擬機(jī)遷移應(yīng) 用 。nova為遷移 ， 遷 移 過 程 中 ， 不 會 影 響Novamigrate 為冷遷移，虛機(jī)為關(guān)機(jī)狀態(tài)的遷移虛擬機(jī)無法單向熱遷移：node-2 是控制節(jié)點(diǎn)，node-1 和 node-4 是僅存的計算+節(jié)點(diǎn)， node-3 和 node-5 已經(jīng)移除。從 node-1 遷移虛機(jī)到 node-4 正常，但是云主機(jī)從 node-4 遷移到node-1 報錯，無法完成遷移。以下是node-1 的 CPU 型號和版本，可以看出是E5-2620v3以下是node-4的CPU型號，是E5-2620v2版本從上面兩

36、圖可以看出，兩臺服務(wù)器的 CPU 型號一致，但是 CPU 版本不一樣，這樣導(dǎo)致云主機(jī)從 V3 遷移到 V2 版本正常，但是 V2 的云主機(jī)可能無法遷移到 V3 的宿主機(jī)中。還有一種情況，會導(dǎo)致遷移失敗。在 compute 日 志 中 ， 會 看 到如 下 報 錯：error:ernal error Attempt to migrate guest to the same host 00020003-0004-0005-處理方法是：查看兩個節(jié)點(diǎn)的 system-uuid 是否一樣，如果一樣需要修改 libvirt 的配置文件?？梢酝ㄟ^如下令查看：rootcontroller1 # dmideco

37、de -s system-uuid查看 /etc/libvirt/libvirtd.conf 中的 host_uuid 發(fā)現(xiàn)該行被注釋，將該注釋去掉，并需要對 host_uuid 的值進(jìn)行修改。在兩臺機(jī)器上分別用 cat /proc/sys/kernel/random/uuid的值。的值來替換原來 host_uuid2.2.CinderCinder塊管理查1組件狀態(tài)檢rootnode-1 # cinder service-list查看 Se 列是否存在 down 的情況，如果存在需要及時進(jìn)行相應(yīng)處理。2.2 Cinder 常用命令1. 列出正在運(yùn)行的 cinder service，查看狀態(tài)ci

38、nder service-list2. 創(chuàng)建一個 volume，顯示名稱 testvol01,大小 1Gbcinder create -display-name testvol01 13:掛載一個 volume 到一個 vm 實(shí)例獲取 volume idcinder list獲取實(shí)例 id nova list將指定的 volume id 掛載到指定的 vm 實(shí)例 id 上novavolume-attachauto4:從 vm 實(shí)例卸載一個 volume獲取 volume idcinder list獲取實(shí)例 idnova list將指定的 volume id 從指定的 vm 實(shí)例 id 上卸載n

39、ova volume-detach 5:刪除 volume獲取 volume id cinder list刪除指定 volume id 的 volumecinder delete b3c3c099-16c6-43a2-a17f-d0fc5dcf26916. 改變 volume 大小cinderb3c3c099-16c6-43a2-a17f-d0fc5dcf2691extend7. 改變 volume 狀態(tài)CinderCinder常見相問題題服list務(wù)關(guān)問檢查方法 cinder-service相關(guān)報錯：服務(wù)狀態(tài)為downCinder 服務(wù)僅存在于控制節(jié)點(diǎn)上， 服務(wù) down 掉

40、的幾率很小。如果配置多個 ceph 集群，則 cinder 不 能 通 過 service 方 式 重 啟 ， 需 通 過命 令 重 啟 。Cinder 服務(wù) down 掉，不影響正在運(yùn)行的虛機(jī)，也不影響已掛載的云硬盤， 會影響新云硬盤的創(chuàng)建和掛載2.3.2 云硬盤掛載，刪除相關(guān)問題由于云硬盤掛載和卸載操作設(shè)計到 nova 和 cinder 兩個項(xiàng)目，需要兩個項(xiàng)目執(zhí)行一系列操作，因此很難實(shí)現(xiàn)事務(wù)操作，所以如果云硬盤掛載或卸載操作執(zhí)行到中途失敗，就容易造成 nova、cinder、libvirt 三個地方云硬盤的掛載信息不一致。在修復(fù)云硬盤狀態(tài)不一致時，應(yīng)以硬盤的實(shí)際掛載狀態(tài)為準(zhǔn)，修復(fù)前，先檢查

41、硬盤的實(shí)際掛載狀態(tài)，然后確定 nova 和 cinder 該如何修復(fù)。因?yàn)橛脩艨赡芤呀?jīng)掛載了硬盤，并卸載可能會影響用戶的數(shù)據(jù)。數(shù)據(jù)了，冒然A. 確定并修復(fù) libvirt 中云硬盤的掛載狀態(tài)修復(fù)云硬盤狀態(tài)不一致大致分三步走，第一步是確定云硬盤的實(shí)際掛載狀態(tài)。為此，首先要通過nova show確定虛擬機(jī)所在的宿主機(jī)，然后，通過 libvirt工具 virsh 確定云硬盤的掛載狀態(tài)。具體命令如下：令行# virshmand -hmp $(ps -ef | grep | grep -oinstance-0-9a-f8 | head -1) info block再執(zhí)行下面令，看看 libvirt 中虛

42、擬機(jī)的配置文件和它是否一致：# virsh domblklist $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1)上面的例子顯示：虛擬機(jī)在 libvirt 中和實(shí)際的掛載狀態(tài)是一致的，虛擬機(jī)有四塊硬盤，分別是 vda, vdb, vdd 和 vde，均為 ceph 設(shè)備。如果不一致，需要 dump 一份虛擬機(jī)的配置，看配置文件中哪部分是多余的。舉個例子：# virsh dumpxml $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1)如上所示，一個 .之間的內(nèi)容就是一個塊設(shè)備的所有

43、配置信息，可以將其保持到一個單獨(dú)的文件中，然后通過 virsh attach-device 或命令來動態(tài)的掛載或卸載這個塊設(shè)備。如下：virsh detach-device# cat vde.xmlhosthost port=6789/port=6789/a019a901-70e6-4e74-b44e-5bdfbf9ba4bc=0 x0000 bus=0 x00 slot=0 x08# virsh detach-device $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1) vde.xml確定并修復(fù)完 libvirt 的狀態(tài)之后，就可以

44、開始修復(fù)云硬盤在 nova 的狀態(tài)了。B. 修復(fù) nova 中云硬盤的狀態(tài)nova 服務(wù)會將虛擬機(jī)的掛載的云硬盤信息在一張單獨(dú)的表里面，這的名稱是block_device_map，表結(jié)構(gòu)如下：其中比較關(guān)鍵字段的含義如下：source_type：掛載之前的類型destination_type：掛載之后的類型connection_info：連接信息；虛擬機(jī)通過這些信息就可以掛載硬盤了deleted：是否有效instance_uuid: 云硬盤掛載到哪個虛擬機(jī)了如果掛載有問題，或者中途失敗，connection_info 字段為空。在 nova 中修復(fù)云硬盤的狀態(tài)很簡單，只需要修改上面這個表，將沒有

45、掛載成功的云硬盤對于的信息標(biāo)記為 deleted就可以了。也就是說，只需要修改 deleted 字段。如下： update block_device_mapset deleted=x where id=x;修改完數(shù)據(jù)庫，通過 nova show 看到的虛擬機(jī)的狀態(tài)，結(jié)果應(yīng)該不再顯示對應(yīng)的硬盤處于掛載狀態(tài)了。修復(fù)完 nova 中的狀態(tài)之后，就要修復(fù)云硬盤在 cinder 中的狀態(tài)了。C. 修復(fù) cinder 中云硬盤的狀態(tài)cinder 中使用了兩個表來云硬盤的狀態(tài)和掛載信息。分別是volumes和volume_attaent。volumes 的表結(jié)構(gòu)如下：volumes 表attach_s了所有

46、的云硬盤的基本信息。其中sus 表明了目前所處的狀態(tài)，us 表明了云硬盤正在執(zhí)行的操作。在 cinder 中修復(fù) volume 的狀態(tài)要修改這個表。將云硬盤為未掛載，具體如下： update volumes set sxx;us=available, attach_sus=detached whereid=這樣，就可以修復(fù)云硬盤在 cinder 中的狀態(tài)。修復(fù)完成之后，云硬盤在三個地方的狀態(tài)就是一致的了。2.3.3環(huán)境介紹MultiBackend配置一個 controller 節(jié)點(diǎn)，一個 compute 節(jié)點(diǎn)兩個 OSD目標(biāo)： 創(chuàng)建云硬盤時，可選擇使用不同池1. 創(chuàng)建新的 rbd poolce

47、ph cephcephosd osdosdpool poolpoolcreate testp 128 128set testpset testpmin_size 1size 12. 獲取當(dāng)前 crushmapceph osd getcrushmap -ocrush.mapcrushtool -d crush.map -o crush.txt3. 修改 crush.txt# begin tunable tunable tunable tunable # devi devicedevicecrush map choose_local_tries 0 choose_local_fallback_tr

48、ies choose_total_tries 50chooseleaf_descend_once 10osd.0osd.1# typestype type type type type type type type type typetype0123456789osd host chassis rack rowpdu podroomdenterregion10 root#可以看出，crushmap 為樹形結(jié)構(gòu)，根節(jié)點(diǎn)為type10 root ， 葉節(jié)點(diǎn)為這段保持默認(rèn)即可。type 0 osd ，依次向下。 后面的配置實(shí)際上都是在描述這個樹。host node-6 id -2# weight 0

49、.250 alg straw# do not change unnesarilyhash itemitem0 # rjenkins1osd.0osd.1weightweight0.1900.060root defaultid -1# weight 0.250 alg straw#do not change unnesarilyhash 0 # rjenkins1#item node-6 weight 0.250item osd.0 weight 0.190root testpool id -3 alg straw hash 0item osd.1 weight 0.060#以上三行是在對節(jié)點(diǎn)進(jìn)

50、行描述。 簡單解釋以下， 首先定義了一個 node-6， 類型是 host，這個 host 下有兩個 OSD， 分別是 osd.0 和 osd.1。 然后這個 host 屬于 root default 下。由于希望將兩個 osd 分開定義，所以將 root default 下的成員改成了只有 osd.0，又單獨(dú)定義了一個 root testpool， 成員只有 osd.1。 # rulesrule replicated_ruleset ruleset 0type replicated min_size 1max_size 10step stepsteptake default choosele

51、afemitn 0 type osdrule testrule ruleset 1type replicated min size 1max size 10stepstep steptake testpoolchooseleaf emitn 0 type osd#這里是最后的 rule為 1， “step take將 step chooseleafset 配置， 默認(rèn)的 ruleset 是 0，新定義一個 rule，rule settestpool” 說明采取 root testpool 所定義的對應(yīng)關(guān)系。 注意需要n 0 type 這一項(xiàng)改為 OSD， 默認(rèn)為 host。重新編譯并應(yīng)用cru

52、shtool -c crush.txt -o crush.map ceph osd setcrushmap -i crush.map修改新 rbd pool 的 rulesetceph osd pool set testp crush_ruleset 16. 進(jìn)試dd if=/dev/zero of=testp.pool bs=1M count=20rados Ceph osdm(1,-p testp put testp.object testp.pool osd map testp testp.object33 pool testp (5) object testp.object - pg

53、5.24c133e (5.3e) - upp1) acting (1, p1)#可以看到，這個 object 全部寫入到了 osd.1 上。7. 添加 ceph 權(quán)限ceph auth list需要為 c#查看現(xiàn)限nt.volumes 這個用戶，添加對 testp 池 rwx 的權(quán)限ceph auth caps cnt.volumesallow r osd allow class-read object_prefixrbd_children, allow rwx pool=volumes, allow rwx pute, allow rwx pool=testp至此， ceph 配置已經(jīng)完成，

54、接下來配置 cinder8. 修改 controller 上的 cinder.confpool=backups,allowrx找到enabled_backends一項(xiàng)，取消注釋enabled_backends=osd1,osd2在末尾添加如下兩項(xiàng)osd1 volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_pool=volumesvolume_backend_name=osd1 rbd_user=volumes rbd_ceph_conf=/etc/ceph/ceph.conf rbd_flatten_volume_from_snapsh

55、ot=Falserbd_secret_uuid=a5d0dd94-57c4-ae55-ffe0-7e3732a24455 rbd_max_clone_depth=5osd2 volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_pool=testpvolume_backend_name=osd2 rbd_user=volumes rbd_ceph_conf=/etc/ceph/ceph.confrbd_flatten_volume_from_snapshot=Falserbd_secret_uuid=a5d0dd94-57c4-ae55-f

56、fe0-7e3732a24455rbd_max_clone_depth=59. 創(chuàng)建 cindoerosd1 osd2cinder cinder cinder cindercindertype-createtype-createtype-key osd1 set volume_backend_name=osd1type-key osd2 set volume_backend_name=osd2 extra-specs-list#查看是否成功10. 測試先嘗試用命令來創(chuàng)建 volumecinder cindercindercreate -volume_type osd1 -display_nam

57、e test1 1 create -volume_type osd2 -display_name test2 1list #查看在頁面上嘗試創(chuàng)建云硬盤，創(chuàng)建時可以選擇“類型”，下拉菜單中出現(xiàn) OSD1 和 OSD2，即為之前配置的不同池。用戶在使用時，可以從不同池中創(chuàng)建云硬盤，將其掛載到相應(yīng)的云主機(jī)上。 或者選擇 boot from volume， 直接在需要的池上創(chuàng)建虛機(jī)。 P.S配置完成后，用 cinder service-list 查看 cinder 服務(wù)狀態(tài)時，會發(fā)現(xiàn)出現(xiàn)了 osd1和 osd2 的 cinder_volume 服務(wù)，原本的 cinder_volume 服務(wù)狀態(tài)為 do

58、wn。修改數(shù)據(jù)庫的方式，將這一條 down 的消去，簡化客戶的管理?？梢酝ㄟ^use cinder;select * from servi delete from servi刪 除 后 ， 再 次 用;#查看該條的 idwhere id=X#刪除該條cinder service-list 查 看 服 務(wù) ， 就 全 部 正 常 了 。2.3.4 其余常用操作，配置介紹。A. 云硬盤無法掛載云 硬 盤 掛 載 時 ， 遇 到 報 錯 ， 日 志 中 有 “device is busy” 信 息 。這時需要去檢查 block_device_map下表，查詢目標(biāo)虛機(jī)的云硬盤掛載圖，如：從表中可見，該虛

59、機(jī)目前已掛載了 vdb vdd vde 三塊云硬盤。 再次掛載新云硬盤，執(zhí)行 nova volume-attach 命令時，cinder 會自動使用/dev/vdc 的設(shè)備名，但是表中有一條/dev/vdc 的錯誤掛載，并且狀態(tài)不為 deleted。 所以會報device。is解決方法有兩個：busy錯誤a)b)從表中刪除這條/dev/vdc 的手動在控制節(jié)點(diǎn)上執(zhí)行掛載命令，指定設(shè)備名為/dev/vdf 即可。B.從數(shù)據(jù)庫中刪除云硬盤有時會出現(xiàn)云硬盤已經(jīng)刪除，但是在頁面上依舊可見的情況，這時需要手動將其從數(shù)據(jù)庫中刪除。 主要就是刪除 volumes 表和 volume_admin_metada

60、ta 中的數(shù)據(jù)：use cinder;select selectdeletewhere deleted=1 from volumes;* from volume_admin_metadata;from volume_admin_metadata where volume_id = 0d09c6f5-9cc1-478f-91d7-287a45c66330; delete from volumes where id=0d09c6f5-9cc1-478f-91d7-287a45c66330;C.QOS-針對虛機(jī)系統(tǒng)盤和 cinder 云硬盤的帶寬和 IOPS 進(jìn)行限速最終效果，在 libvirt x