Openstack云操作系統(tǒng)介紹

1、Openstack云操作系統(tǒng)介紹21整體架構(gòu)2計(jì)算組件運(yùn)維34存儲組件運(yùn)維網(wǎng)絡(luò)組件運(yùn)維5認(rèn)證和鏡像運(yùn)維3OpenStack 簡單視圖4OpenStack架構(gòu)概覽 5控制節(jié)點(diǎn)服務(wù)及高可用實(shí)現(xiàn)6控制節(jié)點(diǎn)服務(wù)與HA78云操作系統(tǒng)單數(shù)據(jù)中心部署圖9部署網(wǎng)（PXE）：自動(dòng)化部署工具通過該網(wǎng)絡(luò)部署物理機(jī)操作系統(tǒng)和云操作系統(tǒng)其他組件管理網(wǎng)（mgmt）：云操作系統(tǒng)計(jì)算、網(wǎng)絡(luò)、存儲、認(rèn)證等服務(wù)間通過該網(wǎng)絡(luò)互相調(diào)用；虛擬主機(jī)通過該網(wǎng)絡(luò)將業(yè)務(wù)IO寫入磁盤存儲網(wǎng)（storage）：分布式存儲中各個(gè)磁盤之間通過該網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)副本的同步私網(wǎng)（private）：虛擬主機(jī)的東西向流量通過該網(wǎng)絡(luò)進(jìn)行通信業(yè)務(wù)網(wǎng)（app）：虛擬主

2、機(jī)的南北向流量通過該網(wǎng)絡(luò)與數(shù)據(jù)中心內(nèi)其他系統(tǒng)進(jìn)行通信IPMI網(wǎng)絡(luò)：物理主機(jī)帶外管理接口，為了配置計(jì)算節(jié)點(diǎn)/混合節(jié)點(diǎn)的hostha，需要連通控制節(jié)點(diǎn)的mgmt網(wǎng)絡(luò)（或者pxe，或者storage）和計(jì)算/混合節(jié)點(diǎn)的ipmi接口網(wǎng)絡(luò)。1011分布式存儲架構(gòu)12131415161整體架構(gòu)2計(jì)算組件運(yùn)維34存儲組件運(yùn)維網(wǎng)絡(luò)組件運(yùn)維5認(rèn)證和鏡像運(yùn)維17Nova架構(gòu)18設(shè)置環(huán)境變量rootnode-1 # source openrc19Nova組件狀態(tài)檢查rootnode-1 # nova service-list根據(jù)輸出，查看State是否存在down的情況，如果沒有證明整個(gè)集群工作正常。如果有down

3、的情況需及時(shí)進(jìn)行處理。 Nova服務(wù)down掉，不會影響虛機(jī)運(yùn)行， 但對相關(guān)物理機(jī)上的虛機(jī)操作會有影響（如開關(guān)機(jī)，遷移等等）。可嘗試重啟相應(yīng)服務(wù)。20Nova常用命令列出可用的實(shí)例 nova list -all-tenantnova list -all-tenant -host node-4.domain.tld21Nova常用命令rootnode-1 # nova show testvm0122Nova常用命令列出可用的flavorrootnode-1 # nova flavor-list定制flavor，flavor name=test500 flavor id=500 ram=512Mb

4、 cpu=2rootnode-1 # nova flavor-create test500 500 512 1 223Nova常用命令-創(chuàng)建虛機(jī)-image 后面加鏡像UUID，使用glance image-list查看-flavor 后面加flavor的UUID，使用nova flavor-list查看，也可以新建flavor-nic net-id 后面加網(wǎng)絡(luò)UUID，使用neutron net-list查看，主要是net，部署subnet-availability-zone 如果不指定由nova-scheduler根據(jù)策略自動(dòng)指定主機(jī)部署， 默認(rèn)是nova?？梢酝ㄟ^zone_name:no

5、de-name將虛擬機(jī)部署到指定的主機(jī)上面，比如：Internal_Zone:node-11.domain.tld前面是zone名稱，后面是宿主機(jī)的主機(jī)名24先獲取flavor id: nova flavor-list |grep 500獲取image id: glance image-listNova常用命令-創(chuàng)建虛機(jī)25Nova常用命令獲取網(wǎng)絡(luò) id: neutron net-list創(chuàng)建vm 實(shí)例testvm01nova boot -image f911dbae-aaee-4969-8b99-c535d6e18eaa -flavor test500 -nic net-id=b21a53d

6、6-b4c0-4e49-ac78-50a8d66c310f testvm0126啟動(dòng)/關(guān)閉/刪除一個(gè)虛機(jī)獲取實(shí)例的id: nova list通過指定實(shí)例id啟動(dòng)實(shí)例nova start 3f84a737-e26b-4cee-a5d9-ff44d9458172通過指定實(shí)例關(guān)閉實(shí)例nova stop 3f84a737-e26b-4cee-a5d9-ff44d9458172通過指定實(shí)例id刪除實(shí)例nova delete 3f84a737-e26b-4cee-a5d9-ff44d945817227Nova常見問題-服務(wù)相關(guān)A. Compute服務(wù)down nova服務(wù)分布在控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)上。 其中

7、控制節(jié)點(diǎn)上有Nova-cert，nova-consoleauth，nova-scheduler，nova-conductor， 計(jì)算節(jié)點(diǎn)上只有nova-compute服務(wù)。其中控制節(jié)點(diǎn)上nova服務(wù)down掉的幾率不大。 計(jì)算節(jié)點(diǎn)nova-compute服務(wù)down掉時(shí)， 先檢查相應(yīng)節(jié)點(diǎn)的網(wǎng)絡(luò)連接，確認(rèn)管理網(wǎng)絡(luò)正常。網(wǎng)絡(luò)檢查正常后，可嘗試ssh至問題節(jié)點(diǎn)，/etc/init.d/openstack-nova-compute restart 來嘗試重啟nova-compute服務(wù)。 此操作不會影響正在運(yùn)行的虛機(jī)。28Nova常見問題-服務(wù)相關(guān)B .Compute服務(wù)無法重啟 在重啟nova-co

8、mpute服務(wù)后，可執(zhí)行/etc/init.d/openstack-nova-compute status 來確認(rèn)服務(wù)是否正常啟動(dòng)。 如果現(xiàn)實(shí)pid xxxx is running. 則服務(wù)正常。 有時(shí)會有 progress is not rugnning but pid file exist 的報(bào)錯(cuò)。 此時(shí)需要?jiǎng)h除 /var/run/nova/nova-compute.pid 文件， 再次重啟即可。 如果還有問題，請檢查系統(tǒng)rsyslog服務(wù)，一般出現(xiàn)這種情況，都是由于系統(tǒng)rsyslog服務(wù)卡死，先重啟rsyslog服務(wù)后，再檢查compute服務(wù)。29Nova常見問題-虛機(jī)操作問題A .部

9、署，遷移，調(diào)整虛機(jī)失敗有時(shí)，由于某些原因，虛機(jī)在遷移，修改大小后報(bào)錯(cuò)，虛機(jī)狀態(tài)為”error”， 可用下列命令恢復(fù)其狀態(tài)nova reset-state -active這種問題出現(xiàn)的可能性有很多， 需要分析相應(yīng)的log。 分析日志的順序?yàn)榭刂乒?jié)點(diǎn)上的nova-api.log- nova-conductor.log-nova-scheduler.log 如果都沒問題， 則檢查相應(yīng)計(jì)算節(jié)點(diǎn)上的nova-compute.log。30Nova常見問題-虛機(jī)操作問題B. 創(chuàng)建虛擬機(jī)失敗 創(chuàng)建虛擬機(jī)是一個(gè)復(fù)雜的操作，涉及到openstack很多的服務(wù)。 當(dāng)用戶提交創(chuàng)建虛擬機(jī)的請求時(shí)，請求首先會到達(dá)nova

10、-api服務(wù)，nova-api 會記錄用戶的請求，隨后調(diào)用nova-compute完成虛擬機(jī)的創(chuàng)建工作。在創(chuàng)建虛擬機(jī)的過程中，nova-compute會調(diào)用glance獲取鏡像，調(diào)用neutron創(chuàng)建網(wǎng)卡，調(diào)用cinder掛載volume，調(diào)用ceph創(chuàng)建系統(tǒng)盤。 任何一個(gè)步驟失敗都會導(dǎo)致虛擬機(jī)創(chuàng)建失敗，所以，在排除虛擬機(jī)創(chuàng)建失敗的問題時(shí)，需要了解openstack的總體架構(gòu)，熟悉nova創(chuàng)建虛擬機(jī)的流程，然后根據(jù)虛擬機(jī)的狀態(tài)及nova服務(wù)的日志判斷創(chuàng)建虛擬機(jī)的操作執(zhí)行到哪步失敗了。31Nova常見問題-虛機(jī)創(chuàng)建失敗創(chuàng)建虛擬機(jī)的過程中調(diào)度失敗故障描述: 執(zhí)行虛擬機(jī)創(chuàng)建操作之后，很長時(shí)間虛擬機(jī)還

11、在“創(chuàng)建中”。虛擬機(jī)創(chuàng)建的過程中，需要nova-scheduler服務(wù)確定在哪個(gè)物理服務(wù)器上運(yùn)行剛剛創(chuàng)建的虛擬機(jī)，如果nova-scheduler服務(wù)不響應(yīng)調(diào)度任務(wù)，則虛擬機(jī)可能一直處于scheduling狀態(tài)。# source /root/openrc# nova show 32Nova常見問題-虛機(jī)創(chuàng)建失敗字段含義status在瀏覽器里面，用戶看到的狀態(tài)。status是虛擬機(jī)task_state、vm_state、power_state綜合起來的結(jié)果。OS-EXT-STS:task_statenova管理服務(wù)正在對虛擬機(jī)執(zhí)行的操作。如果為-，則表示沒有人在管理此虛擬機(jī)。OS-EXT-SRV

12、-ATTR:host虛擬機(jī)所在宿主機(jī)的hostname。如果為-，則表示虛擬機(jī)還沒有確定，一般在剛創(chuàng)建虛擬機(jī)的過程中，調(diào)度器還沒有完成調(diào)度時(shí)會顯示為該狀態(tài)。如果OS-EXT-STS:task_state為scheduling， 而且 OS-EXT-SRV-ATTR:host 為-，則表示還在等待調(diào)度程序確定運(yùn)行虛擬機(jī)的宿主機(jī)。由此可以判斷nova-scheduler服務(wù)出問題了。如果調(diào)度沒有問題，或者沒有可用的宿主機(jī)，調(diào)度程序都會很快返回，不會一直停留在scheduling的狀態(tài)。33Nova常見問題-虛機(jī)創(chuàng)建失敗解決方法出現(xiàn)上面的故障有兩種可能性，一種是整個(gè)集群沒有可用的nova-sched

13、uler實(shí)例；另一種是nova-scheduler服務(wù)出問題了。對此，首先要查看整個(gè)集群是否有nova-scheduler服務(wù)在運(yùn)行。查看方法如下：nova service-list | grep scheduler 整個(gè)集群至少需要一個(gè)nova-scheduler實(shí)例處于up狀態(tài)。需如果集群中至少有一個(gè)nova-scheduler實(shí)例的狀態(tài)是up的，我們就需要查看查看nova-scheduler的日志來進(jìn)一步確定原因了。到控制節(jié)點(diǎn)上，查看/var/log/nova/scheduler 日志。tail -f /var/log/nova/scheduler34Nova常見問題-虛機(jī)創(chuàng)建失敗 no

14、va-scheduler服務(wù)不能正常工作最常見的一個(gè)原因是連不上RabbitMQ服務(wù)，或者能連上就是不消費(fèi)隊(duì)列中的消息。為此需要查看消息隊(duì)列中nova-scheduler服務(wù)未消費(fèi)的消息數(shù)目。具體方法是在控制節(jié)點(diǎn)上執(zhí)行下面的命令： nova-scheduler服務(wù)使用的隊(duì)列名稱是以scheduler開頭，每個(gè)nova-scheduler會監(jiān)聽兩個(gè)隊(duì)列，一個(gè)是 scheduler.server-xx 表示這個(gè)實(shí)例運(yùn)行在 server-xx 上面；scheduler_fanout_xxxxx 這個(gè)隊(duì)列是用來接收調(diào)度服務(wù)的廣播消息。如果這些隊(duì)列中的消息數(shù)量一致大于零，就表示隊(duì)列中的消息沒有人消費(fèi)。對

15、于這種情況，可以重啟下 所有的 nova-scheduler 實(shí)例看看問題是否能得到解決。/etc/init.d/openstack-nova-scheduler restart35Nova常見問題-虛機(jī)創(chuàng)建失敗創(chuàng)建虛擬機(jī)過程中報(bào)NoValidHost執(zhí)行虛擬機(jī)創(chuàng)建操作之后，虛擬機(jī)的狀態(tài)沒有變?yōu)椤斑\(yùn)行中”，而是變?yōu)榱恕板e(cuò)誤”，用 nova show 查看虛擬機(jī)狀態(tài)，發(fā)現(xiàn)關(guān)鍵字 NoValidHost登錄控制節(jié)點(diǎn)，執(zhí)行下面的命令顯示虛擬機(jī)的詳細(xì)信息：# source /openrc# nova show （虛擬機(jī)UUID是創(chuàng)建失敗的虛擬機(jī)的UUID）如上圖所示，關(guān)鍵信息是 fault 字段中包含

16、了 No valid host was found 這樣的信息。如果出現(xiàn)這類關(guān)鍵信息，可以參考下面的解決辦法。36Nova常見問題-虛機(jī)創(chuàng)建失敗上面的錯(cuò)誤信息是nova-scheduler服務(wù)返回的，表明上的意思是沒有可用的宿主機(jī)，也就是說請求的資源太多了，現(xiàn)在集群中沒有哪個(gè)宿主機(jī)有那么多資源，所以請求失敗。由于nova-scheduler會封裝nova-compute所遇到的錯(cuò)誤，所以上面的消息不一定準(zhǔn)確。為了確定確切的原因，可以通過如下的命令來查看整個(gè)集群的資源占用情況。字段名稱含義memory_mb所有宿主機(jī)內(nèi)存總量memory_mb_used已經(jīng)分配給虛擬機(jī)的內(nèi)存總量；openstac

17、k允許內(nèi)存復(fù)用比大于一，所以，這個(gè)值可能比 memory_mb 還大vcpus所有宿主機(jī)中cpu數(shù)量（總線程） vcpus_used已分配的虛擬機(jī)的vcpus總量；openstack允許CPU復(fù)用比大于一，所以，這個(gè)值可能比 vcpus 還大running_vms已經(jīng)創(chuàng)建的虛擬機(jī)的總數(shù)，包括關(guān)機(jī)狀態(tài)的虛擬機(jī)37Nova常見問題-虛機(jī)創(chuàng)建失敗以及命令；nova hypervisor-show node-x.domain.tld 來查看單臺服務(wù)器的使用情況。 如果集群系統(tǒng)不夠用了，上面統(tǒng)計(jì)的已經(jīng)分配給虛擬機(jī)的 vcpus & 內(nèi)存應(yīng)該都比較高。否則的話，有可能是nova-compute上某些操作執(zhí)

18、行失敗了。默認(rèn)情況下，調(diào)度器會嘗試三次，在不同的宿主機(jī)上運(yùn)行虛擬機(jī)，如果都失敗，也會報(bào) No valid host 的錯(cuò)誤。具體錯(cuò)誤，可以查看scheduler.logrootnode-1 # tail -f /var/log/nova/nova-scheduler.lognova-compute創(chuàng)建虛擬機(jī)失敗可能有很多原因，可能是創(chuàng)建系統(tǒng)盤失敗，也可能是調(diào)用neutron創(chuàng)建網(wǎng)卡失敗，也可能是 虛擬化層的錯(cuò)誤。對于這種情況，需要進(jìn)一步查看nova-compute及相關(guān)服務(wù)的日志確定具體的原因。具體方法如下：# cat /var/log/nova/compute.log | grep -v I

19、NFO | grep -v AUDIT | less38Nova常見問題-虛機(jī)遷移nova live-migration 為在線遷移，遷移過程中，網(wǎng)絡(luò)幾乎不會中斷Nova migrate 為冷遷移，虛機(jī)為關(guān)機(jī)狀態(tài)的遷移39Nova相關(guān)日志文件控制節(jié)點(diǎn)：/var/log/nova/api.log/var/log/nova/conductor.log/var/log/nova/scheduler.log計(jì)算節(jié)點(diǎn) ：/var/log/nova/compute.log/var/lib/nova/instance 401整體架構(gòu)2計(jì)算組件運(yùn)維34存儲組件運(yùn)維網(wǎng)絡(luò)組件運(yùn)維5認(rèn)證和鏡像運(yùn)維41Neutron

20、架構(gòu)42Neutron狀態(tài)檢查檢查Neutron servicerootnode-1 # neutron agent-list重點(diǎn)查看alive列的狀態(tài)是否正常，L3 agent和DHCP agent至少要有一個(gè)正常。43Neutron狀態(tài)檢查檢查l3-agent的namespace從上面的狀態(tài)可以看到l3-agent在node-1，所以在node-1上查看namespacerootnode-1 # ip netnsrootnode-1 # ip netns exec qrouter-95e6d480-7607-477e-a11a-67ca68604619 ip a環(huán)境中如果沒有啟用L3-ro

21、uter， 無需檢查。44Neutron狀態(tài)檢查查看dhcp-agent的namespace在node-1上查看namespacerootnode-3 # ip netns exec qdhcp-xxxxxx ip a可以看到一個(gè)tap設(shè)備，ip是dhcp的IP。如果虛機(jī)分配不到IP，請檢查dhcp服務(wù)是否正常。45rootnode-3 # ps aux | grep dhcpNeutron狀態(tài)檢查46rootnode-3#cat /var/lib/neutron/dhcp/3344c78a-d5a8-419c-bbc6-60424bf0ef14/hostNeutron狀態(tài)檢查如果正常這個(gè)ho

22、st文件里會有虛機(jī)的mac地址和分配的IP的記錄，當(dāng)dhcp服務(wù)出問題時(shí)，不會影響現(xiàn)有虛機(jī)運(yùn)行， 只會造成新建虛機(jī)無法獲取IP地址，同時(shí)無法寫入主機(jī)名和密碼。47Neutron常用命令neutron net-list查看所有子網(wǎng)neutron subnet-list查看所有路由器neutron router-list查看所有網(wǎng)絡(luò)48編輯子網(wǎng)Neutron常用命令創(chuàng)建路由器,名稱 es_hr_routerneutron router-create es_hr_router49連接路由器到外網(wǎng)先獲取router名稱neutron router-list然后獲取外網(wǎng)名稱public_netneutr

23、on net-external-list連接路由器es_hr_router到外網(wǎng)public_netneutron router-gateway-set es_hr_router public_net再次確認(rèn)路由器已經(jīng)連接至外網(wǎng)neutron router-listNeutron常用命令50命令行創(chuàng)建l2網(wǎng)絡(luò)在控制節(jié)點(diǎn)上，執(zhí)行如下命令：#創(chuàng)建net,vlan為421neutron net-create net_421 -provider:network_type=vlan -provider:physical_network=physnet2 -provider:segmentation_id

24、=421#其中，net_421為此net的名字，網(wǎng)絡(luò)類型為vlan， segmentation_id為vlan號。#創(chuàng)建子網(wǎng)neutron subnet-create -name subnet_421 -disable-dhcp -no-gateway -allocation-pool start=,end= -host-route destination=/0, nexthop=0 net_421 /27#其中，subnet_421位子網(wǎng)名字，禁用了dhcp，no-gateway參數(shù)指明不使用默認(rèn)的l3. Allocation-pool為地址池， nexthop指明下一跳至網(wǎng)關(guān)， 此子網(wǎng)屬于

25、net_421 /27網(wǎng)絡(luò)下。5152Neutron常見問題Neutron服務(wù)相關(guān)問題檢查方法 neutron-agent list相關(guān)報(bào)錯(cuò)：A. 控制節(jié)點(diǎn)服務(wù)狀態(tài)異常在控制節(jié)點(diǎn)(HA環(huán)境)任意節(jié)點(diǎn)執(zhí)行crm status命令檢查部分neutron服務(wù)狀態(tài)，正常狀態(tài)顯示如下圖，沒有failed，沒有stopped，這里pacemaker監(jiān)控四個(gè)neutron服務(wù)：neutron-openvswitch-agent、neutron-metadata-agent、neutron-dhcp-agent和neutron-l3-agent(純L2環(huán)境忽略，也可以移除不再監(jiān)控)，這時(shí)不需要任何處理。53N

26、eutron常見問題如果服務(wù)異常，node-3的neutron-openvswitch-agent異常stopped了。同時(shí)會伴有failed error，此時(shí)需要手動(dòng)干預(yù)。以node-3上的neutron-openvswitch-agent服務(wù)異常為例，需要ssh到node-3，先source openrc，然后執(zhí)行crm resource cleanup p_neutron-openvswitch-agent稍等一下，stopped和failed會被清理掉，依次處理其他問題，直至服務(wù)恢復(fù)正常。54Neutron常見問題如果在云平臺異常的情況下，有服務(wù)在三個(gè)節(jié)點(diǎn)全部down，則不會再crm

27、status中再顯示，即不被pacemaker管理，這是需要使用crm source list查看。如圖，crm status已經(jīng)看不到mysql狀態(tài)了，使用crm resource list可以看到mysql已經(jīng)在三個(gè)控制節(jié)點(diǎn)全stopped了55Neutron常見問題 如果使用crm status看不到全部四個(gè)neutron服務(wù)則使用crm resource list看一下是不是已經(jīng)全部stopped了。如果出現(xiàn)這種情況則需要在任意控制節(jié)點(diǎn)執(zhí)行crm resource restart p_mysql 這個(gè)時(shí)間可能會長一點(diǎn)，等啟動(dòng)完成再使用crm status查看，如圖則為恢復(fù)正常，如果沒有

28、恢復(fù)則需要查看相關(guān)log：/var/log/neutron/dhcp-agent.log、/var/log/neutron/metadata-agent.log、/var/log/neutron/openvswitch-agent.log、/var/log/neutron/l3-agent.log以及/var/log/neutron/server.log具體問題具體分析。 除了以上外，控制節(jié)點(diǎn)還有一個(gè)neutron-server服務(wù)沒有被pacemaker管理，可以直接使用service neutron-server status查看其狀態(tài)，顯示running狀態(tài)即服務(wù)正常。Neutron-s

29、erver服務(wù)一般很少出問題，但此服務(wù)嚴(yán)重依賴rsyslog，在默認(rèn)情況下控制節(jié)點(diǎn)rsyslog server指向roller，這是如果roller長時(shí)間不通或?qū)е聄syslog服務(wù)down，從而引發(fā)neutron-server異常，此時(shí)網(wǎng)絡(luò)其他服務(wù)也會出現(xiàn)異常，需要重啟rsyslog服務(wù)，然后重啟neutron-server以及其他服務(wù)即可恢復(fù)。56Neutron常見問題計(jì)算節(jié)點(diǎn)openvswitch服務(wù)down如圖這里我們主要看計(jì)算節(jié)點(diǎn)的neutron服務(wù)，在計(jì)算節(jié)點(diǎn)的neutron服務(wù)只有一個(gè)：neutron-openvswitch-agent，alive一欄顯示全為笑臉則表示服務(wù)正常。

30、下圖中，node-6的neutron-openvswitch-agent服務(wù)掛了，則需要重啟?？梢栽诳刂乒?jié)點(diǎn)遠(yuǎn)程查看node-6的neutron-openvswitch-agent服務(wù)并重啟，本次看到的查看node-6的服務(wù)是running的，但是誤報(bào)了，有時(shí)候是缺失failed了。57Neutron常見問題這個(gè)問題出現(xiàn)，我們需要先查看控制節(jié)點(diǎn)CPU和內(nèi)存使用率，這里只有node-6異常，表示控制節(jié)點(diǎn)正常，可以確認(rèn)下。一般引起該服務(wù)異常是計(jì)算節(jié)點(diǎn)內(nèi)存或者CPU負(fù)載。我們登錄到node-6看一下。先使用free g看一下內(nèi)存，果然free為3g了，我們看其實(shí)大部分內(nèi)存都被cache了。這個(gè)時(shí)候可

31、以釋放一下cache占用的內(nèi)存，操作如下：echo 1 /proc/sys/vm/drop_caches #不建議使用3/etc/init.d/openstack-ceilometer-compute restart/etc/init.d/openstack-nova-compute restart #這兩個(gè)服務(wù)長期運(yùn)行容易假死且占用大量內(nèi)存，建議每個(gè)月重啟一次這個(gè)時(shí)候也建議檢查下所有節(jié)點(diǎn)的可用內(nèi)存以及CPU負(fù)荷。釋放內(nèi)存后的如圖58Neutron常見問題Neutron Server無法啟動(dòng)的原因分析 其一，neutron-server異常failed(neutron-server服務(wù)異常會引

32、起控制節(jié)點(diǎn)其他網(wǎng)絡(luò)服務(wù)異常)，無法正常start的情況，此類情況需要優(yōu)先檢查rsyslog狀態(tài)(如果該服務(wù)異常則優(yōu)先解決該問題)，查看CPU負(fù)載和可用內(nèi)存(必須保證CPU負(fù)載和內(nèi)存有資源可用)，如果問題依舊存在，可查看/var/log/neutron/server.log定位具體問題; 其二，由于內(nèi)存消耗、CPU負(fù)載異常導(dǎo)致neutron相關(guān)服務(wù)failed或者假死，需要手動(dòng)重啟相關(guān)服務(wù)，有時(shí)候會出現(xiàn)progress is not running but pid file exist，需要查看CPU負(fù)載和內(nèi)存占用情況(優(yōu)先處理)，確認(rèn)沒有問題執(zhí)行rm /var/run/neutron/neut

33、ron-openvswitch-agent.pid，然后重啟看一下，如果問題依舊存在則查看/var/log/neutron/下相關(guān)服務(wù)的log定位具體問題； 其三，當(dāng)控制節(jié)點(diǎn)crm status出現(xiàn)failed action時(shí)，通常需要登陸相關(guān)節(jié)點(diǎn)使用crm resource cleanup 重啟相關(guān)服務(wù)，如果無法正常啟動(dòng)，或者啟動(dòng)不久又failed，需要確認(rèn)該節(jié)點(diǎn)CPU負(fù)載和內(nèi)存占用情況，持續(xù)ping檢查網(wǎng)絡(luò)是否出現(xiàn)偶爾中斷或者高延遲的情況，查看/var/log/neutron下相關(guān)log定位具體原因。 其四，rabbitmq服務(wù)異常會引起網(wǎng)絡(luò)服務(wù)及云平臺服務(wù)不穩(wěn)定，此時(shí)問題會比較嚴(yán)重，但對

34、純l2的環(huán)境已有的虛機(jī)無影響，此時(shí)需要停止在dashboard上的創(chuàng)建刪除等操作，然后使用crm resource stop p_rabbitmq-server先停止該服務(wù)，這個(gè)時(shí)間會比較長，一般十幾分鐘或者二十分不等，然后start該服務(wù)，提示啟動(dòng)成功需要等待幾分鐘才會出現(xiàn)在crm status中，所以不用反復(fù)重啟。不用直接使用restart時(shí)間會更長，或者卡住。 59Neutron常見問題檢查rabbitmq的方法可以參考rabbitmq模塊，命令如下：crm statusrabbitmqctl cluster_statusrabbitmqctl list_queues | sort k2

35、n其五，服務(wù)異常且不能重啟，不能使用neutron命令，有可能會是keystone或者mysql集群異常導(dǎo)致，需要根據(jù)neutron log定位具體問題，如果是keystone(一般極少出問題)或者mysql(異常斷電容易引起mysql異常)引起請參考相關(guān)模塊排查?？偨Y(jié)：釋放內(nèi)存的方法前文已經(jīng)提過；控制節(jié)點(diǎn)一般占用內(nèi)存較多的服務(wù)是mysql和mongoDB，清理方法請參考相關(guān)模塊；計(jì)算節(jié)點(diǎn)占用內(nèi)存較多的是ceilometer-agent和nova-compute服務(wù)，重啟即可釋放。60Neutron常見問題運(yùn)行中的虛機(jī)IP丟失狀況是運(yùn)行著的虛機(jī)突然不通了，通過console查看，發(fā)現(xiàn)網(wǎng)卡沒有了

36、IP地址，或者有兩個(gè)ip地址，一個(gè)是原地址，一個(gè)是169.x.x.x，一般是獲取不到地址才分配的，而且169.x.x.x是優(yōu)先的，也就是在兩個(gè)地址都存在的情況下，元地址不可用。這種情況基本是由于DHCP租期到期，在獲取IP地址的時(shí)候由于網(wǎng)絡(luò)異常，或者超時(shí)引起，解決這個(gè)問題的方法有兩個(gè)：其一，虛機(jī)獲取IP之后，手動(dòng)將網(wǎng)卡配置成固定IP；其二，默認(rèn)DHCP租期為86400s，可以修改為十年，即可避免此問題。61Neutron常見問題案例：虛機(jī)floating ip無法ping通問題產(chǎn)生原因： 某日凌晨1:00左右,node-1上的系統(tǒng)負(fù)載達(dá)到80%，crm獲取Neutron服務(wù)狀態(tài)超時(shí), 導(dǎo)致cr

37、m嘗試重啟Neutron服務(wù)，由于負(fù)載太高,服務(wù)異常. 導(dǎo)致該節(jié)點(diǎn)上的l3-agent無法工作。node-3上, crm啟動(dòng)openvswitch agent后, 服務(wù)又被人為手動(dòng)啟動(dòng), 導(dǎo)致有兩個(gè)進(jìn)程同時(shí)存在, 發(fā)生沖突。 部分租戶的router沒有成功綁定l3-agent. 判斷是由于crm檢測neutron狀態(tài)超時(shí), 印發(fā)router遷移. 遷移的目標(biāo)控制節(jié)點(diǎn)又由于負(fù)載太高導(dǎo)致router沒有正常啟動(dòng)成功.所以問題產(chǎn)生原因主要是負(fù)載高導(dǎo)致的crm不正常工作，其次是手動(dòng)啟動(dòng)了crm管理的服務(wù)這兩個(gè)原因造成的。62Neutron常見問題針對問題的處理方法：改動(dòng)1： 原來crm監(jiān)控neutro

38、n agents是檢查neutron agents的進(jìn)程來判斷neutron agents服務(wù)是否正常，如果進(jìn)程不在或檢查出問題，就會重啟neutron agents。目前看neutron agents的進(jìn)程基本不太可能被kill掉，除非人為手動(dòng)kill，而crm監(jiān)控出現(xiàn)問題時(shí)，一般是負(fù)載太高，crm使用ps命令檢查超時(shí)導(dǎo)致。 我們的改動(dòng)是crm對neutron agents的監(jiān)控永遠(yuǎn)返回ture。如果用戶發(fā)現(xiàn)進(jìn)程不在，需要啟動(dòng)時(shí)，需要用crm啟動(dòng)。需要修改crm配置文件（/usr/lib/ocf/resource.d/es /neutron-agent-dhcp, /usr/lib/ocf/

39、resource.d/es/neutron-agent-l3, /usr/lib/ocf/resource.d/es/neutron-agent-ovs, /usr/lib/ocf/resource.d/es/neutron-agent-metadata）搜索monitor()，將這個(gè)方法的return 0注釋，return 0下面語句打開注釋。過一會crm會檢測到進(jìn)程沒有啟動(dòng)，便自動(dòng)啟動(dòng)。等進(jìn)程起來后，把配置文件再改回去。改動(dòng)2：將l3的auto reschedule功能關(guān)閉，目前l(fā)3的auto reschedule依賴于mysql，rabbitmq。如果系統(tǒng)負(fù)載高，不穩(wěn)定時(shí)，很容易導(dǎo)致re

40、schedule，而在負(fù)載高時(shí)的 reschedule又容易失敗，所以建議將l3的auto reschedule關(guān)閉，如果當(dāng)一個(gè)控制節(jié)點(diǎn)斷電或死機(jī)，需要用戶手動(dòng)去reschedule。63Neutron常見問題在好的控制節(jié)點(diǎn)執(zhí)行命令：for i in neutron router-list-on-l3-agent | grep | | tail -n +2 | awk print $2; do neutron l3-agent-router-remove $i; neutron l3-agent-router-add $i; donerootnode-1 # neutron router-li

41、st-on-l3-agent 261b8276-a31e-4e71-9dd0-bffb44a6098564dhcp,metadata相關(guān)問題虛擬機(jī)無法獲取DHCP服務(wù)(此時(shí)虛機(jī)也無法正常注入主機(jī)名和密碼)其一，檢查控制節(jié)點(diǎn)DHCP服務(wù)是否正常，如果有failed需要參考前文解決該問題，然后重啟或者重建該虛機(jī)。65其二，確認(rèn)三個(gè)控制節(jié)點(diǎn)namespace都存在dhcp，先確認(rèn)問題網(wǎng)絡(luò)的UUID，然后參考下圖命令檢查，如果顯示三個(gè)則為正常，如果只有一臺或者兩臺控制節(jié)點(diǎn)上存在則為異常，通常為rabbitmq異常引起，參考rabbitmq模塊解決該問題，然后重啟DHCP服務(wù)crm resource r

42、estart p_neutron-dhcp-agent，再次查看應(yīng)該問題會解決。dhcp,metadata相關(guān)問題66其三，可能是物理網(wǎng)絡(luò)不通引起。如果是之前創(chuàng)建的網(wǎng)絡(luò)運(yùn)行正常，新建的虛機(jī)無法獲取IP地址，或者新建的網(wǎng)絡(luò)不通，則需要檢查private網(wǎng)絡(luò)物理線路是否正常可用，物理交換機(jī)對應(yīng)端口是否配置正常，或者是否有修改過配置。 其四，rabbitmq服務(wù)異常造成dhcp服務(wù)異常，引起新建虛機(jī)無法正常獲取IP，跟第二條類似，第二條是創(chuàng)建網(wǎng)絡(luò)時(shí)DHCP服務(wù)沒有及時(shí)正確的創(chuàng)建，本條是之前網(wǎng)絡(luò)正常，但新建虛機(jī)無法正常獲取IP，參考rabbitmq模塊檢查并處理該問題其五，查看控制和該計(jì)算節(jié)點(diǎn)ipta

43、bles是否應(yīng)用了dhcp規(guī)則，如果沒有需要手動(dòng)添加。 其六，port bind failed，新建虛機(jī)偶爾發(fā)生無法獲取DHCP，經(jīng)過以上排查發(fā)現(xiàn)所有服務(wù)都正常，nova show 發(fā)現(xiàn)bind failed，查看log有rpc timeout的報(bào)錯(cuò)，此時(shí)可能是rabbitmq或者neutron或者網(wǎng)絡(luò)超時(shí)導(dǎo)致，偶發(fā)現(xiàn)象，很少見。具體原因需要查看neutron log確認(rèn)。dhcp,metadata相關(guān)問題67總結(jié)：正常情況下虛機(jī)都可以獲取到IP，獲取不到的情況不多見，有時(shí)候問題也不是很好排查，大概是以上幾個(gè)思路。另外可以通過tcpdump逐級網(wǎng)絡(luò)設(shè)備，來判斷問題所在。首先，通過虛機(jī)的uuid

44、和ip， 找到相應(yīng)的port uuid。然后，到相應(yīng)的計(jì)算節(jié)點(diǎn)上，通過ip a命令，可以找到所有的網(wǎng)絡(luò)設(shè)備，其中虛機(jī)對應(yīng)的tap設(shè)備，qbr設(shè)備，qvb，qvo設(shè)備的名稱均為tap，可用grep找到。dhcp,metadata相關(guān)問題68之后，可以在虛機(jī)中，執(zhí)行dhclient命令，來發(fā)送廣播包，嘗試獲取dhcp地址?？梢栽诟鱾€(gè)設(shè)備上執(zhí)行tcpdump，來看是否能收到廣播包，來判斷問題所在。也可以去dump dhcp server上的tap設(shè)備，需要先到相應(yīng)的namespace下，如tap設(shè)備，均在dhcp的namespace中。如下圖:Ip netns exec dhcp-xxxxxx tc

45、pdump -i tapxxxxxx -nne port 67 or port 68 dhcp,metadata相關(guān)問題69虛機(jī)可以獲取IP地址，但是無法正常注入主機(jī)名和密碼dhcp,metadata相關(guān)問題其一，虛機(jī)可以獲取到IP證明網(wǎng)絡(luò)是ok的，由于獲取metadata是由cloudinit完成的，這個(gè)過程在虛機(jī)啟動(dòng)的時(shí)候獲取，所以先查看console log，如果虛機(jī)啟動(dòng)過程沒有cloudinit，或者cloudinit啟動(dòng)失敗，則是cloudinit沒有正常運(yùn)行。如果是其他報(bào)錯(cuò)，我們繼續(xù)排查。通常如果主機(jī)名和密碼注入失敗在虛機(jī) 啟動(dòng)過程在console界面會看到報(bào)錯(cuò)如下圖:70其二，虛

46、機(jī)啟動(dòng)過程中cloudinit通過private網(wǎng)絡(luò)向neutron metadata請求元數(shù)據(jù)，所以要檢查neutron的metadata服務(wù)正常運(yùn)行，如圖是正常運(yùn)行狀態(tài)，如果alive顯示xxx，則需要手動(dòng)重啟該服務(wù)，并檢查為什么掛了。其三，元數(shù)據(jù)請求是一個(gè)neutron-ns-metadata-proxy的進(jìn)程響應(yīng)，在不同的場景下metadata-proxy可能會起在router或者dhcp空間下。如果只是建了一個(gè)網(wǎng)絡(luò)沒有關(guān)聯(lián)路由，這時(shí)neutron-ns-metadata-proxy會起在DHCP空間內(nèi)，虛機(jī)獲得54的路由，這時(shí)可以正常獲?。蝗绻藭r(shí)該網(wǎng)絡(luò)關(guān)聯(lián)路由，再新建虛機(jī)還是會走5

47、4路由向DHCP獲取元數(shù)據(jù)，這時(shí)會獲取不到，然后報(bào)錯(cuò)，這時(shí)需要重啟neutron-dhcp-agent服務(wù)，在路由的空間里會起neutron-ns-metadata-proxy服務(wù)，這時(shí)虛機(jī)會通過默認(rèn)路由向路由獲取元數(shù)據(jù)，不走54了。71其四，跟上一條反過來，如果創(chuàng)建的網(wǎng)絡(luò)關(guān)聯(lián)了路由那么neutron-ns-metadata-proxy會起在路由下，虛機(jī)啟動(dòng)通過默認(rèn)路向路由申請?jiān)獢?shù)據(jù)，dhcp空間沒有此服務(wù)；如這時(shí)路由拿掉了，需要重啟neutron-dhcp-agen服務(wù)來更新，使neutron-ns-metadata-proxy在dhcp空間內(nèi)啟動(dòng)并下發(fā)54路由。總結(jié)：這個(gè)問題一般是由網(wǎng)絡(luò)改

48、動(dòng)引起，可以通過重啟neutron-dhcp-agent和neutron-metadata-agent兩個(gè)服務(wù)來解決。72ovs相關(guān)問題查看ovs配置在控制節(jié)點(diǎn)執(zhí)行，ovs-vsctl show73ovs相關(guān)問題74手動(dòng)創(chuàng)建ovs-bondovs-vsctl add-br br-ovs-bond2ovs-vsctl add-br br-roller#創(chuàng)建一個(gè)bond，包括物理網(wǎng)卡eth0和eth1ovs-vsctl add-bond br-ovs-bond2 bond2 eth0 eth1#br-roller和br-ovs-bond2之間互相添加端口ovs-vsctl add-port br-

49、roller br-roller-br-ovs-bond2ovs-vsctl set Interface br-roller-br-ovs-bond2 type=patch options:peer=br-ovs-bond2-br-roller ovs-vsctl add-port br-ovs-bond2 br-ovs-bond2-br-rollerovs-vsctl set Interface br-ovs-bond2-br-roller type=patch options:peer=br-roller-br-ovs-bond2#使用ip link命令將三個(gè)網(wǎng)橋狀態(tài)設(shè)置為upip lin

50、k set up dev br-ovs-bond2ip link set up dev br-roller ovs相關(guān)問題75擴(kuò)展private vlan 部署時(shí)，為private網(wǎng)絡(luò)指定了一個(gè)范圍。 在dashboard創(chuàng)建網(wǎng)絡(luò)時(shí)（或命令行創(chuàng)建，不指定segmentation_id時(shí)），neutron會自動(dòng)從這個(gè)范圍中按順序取一個(gè)，當(dāng)所有vlan均用完時(shí)，創(chuàng)建網(wǎng)絡(luò)會失敗。 這時(shí)需要修改這個(gè)vlan范圍。 修改步驟很簡單:修改控制節(jié)點(diǎn)上的ml2_conf.ini修改physnet2的range即可。 修改完成后重啟neutron服務(wù)。761整體架構(gòu)2計(jì)算組件運(yùn)維34存儲組件運(yùn)維網(wǎng)絡(luò)組件運(yùn)維5認(rèn)

51、證和鏡像運(yùn)維77Cinder架構(gòu)78Cinder組件狀態(tài)檢查rootnode-1 # cinder service-list 根據(jù)輸出，查看State是否存在down的情況，如果沒有證明整個(gè)集群工作正常。如果有down的情況需及時(shí)進(jìn)行處理。Cinder服務(wù)down掉，不會影響虛機(jī)運(yùn)行， 只影響云硬盤的掛載操作，可嘗試重啟相應(yīng)服務(wù)。79Cinder常用命令列出所有已創(chuàng)建的云硬盤cinder list -all-tenant80創(chuàng)建一個(gè)volume，顯示名稱testvol01,大小1Gbcinder create -display-name testvol01 1Cinder常用命令81掛載一個(gè)v

52、olume到一個(gè)vm實(shí)例獲取volume idcinder list獲取實(shí)例 idnova list將指定的volume id掛載到指定的vm 實(shí)例id上nova volume-attach autoCinder常用命令82刪除volume獲取volume idcinder list刪除指定volume id的volumecinder delete b3c3c099-16c6-43a2-a17f-d0fc5dcf2691改變volume大小cinder extend b3c3c099-16c6-43a2-a17f-d0fc5dcf2691 100Cinder常用命令83改變volume狀態(tài)Ci

53、nder常用命令84Cinder服務(wù)相關(guān)問題云硬盤掛載，刪除相關(guān)問題 由于云硬盤掛載和卸載操作設(shè)計(jì)到nova和cinder兩個(gè)項(xiàng)目，需要兩個(gè)項(xiàng)目執(zhí)行一系列操作，因此很難實(shí)現(xiàn)事務(wù)操作，所以如果云硬盤掛載或卸載操作執(zhí)行到中途失敗，就容易造成nova、cinder、libvirt三個(gè)地方云硬盤的掛載信息不一致。在修復(fù)云硬盤狀態(tài)不一致的問題時(shí)，應(yīng)以硬盤的實(shí)際掛載狀態(tài)為準(zhǔn)，修復(fù)前，先檢查硬盤的實(shí)際掛載狀態(tài)，然后確定nova和cinder該如何修復(fù)。因?yàn)橛脩艨赡芤呀?jīng)掛載了硬盤，并存儲數(shù)據(jù)了，冒然卸載可能會影響用戶的數(shù)據(jù)。A. 確定并修復(fù)libvirt中云硬盤的掛載狀態(tài)B. 修復(fù)nova中云硬盤的狀態(tài)C.

54、修復(fù)cinder中云硬盤的狀態(tài)85A. 確定并修復(fù)libvirt中云硬盤的掛載狀態(tài) 修復(fù)云硬盤狀態(tài)不一致的問題大致分三步走，第一步是確定云硬盤的實(shí)際掛載狀態(tài)。為此，首先要通過nova show確定虛擬機(jī)所在的宿主機(jī)，然后，通過libvirt的命令行工具virsh確定云硬盤的掛載狀態(tài)。具體命令如下：# virsh qemu-monitor-command -hmp $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1) info blockCinder服務(wù)相關(guān)問題86再執(zhí)行下面的命令，看看libvirt中虛擬機(jī)的配置文件和它是否一致：# vir

55、sh 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ī)的配置，看配置文件中哪部分是多余的。舉個(gè)例子：# virsh dumpxml $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1)Cinder服務(wù)相關(guān)問題87Cinder服務(wù)相關(guān)問題88如上所示，一個(gè) .之間的內(nèi)容就是一個(gè)塊設(shè)備的所有

56、配置信息，可以將其保持到一個(gè)單獨(dú)的文件中，然后通過 virsh attach-device 或 virsh detach-device 命令來動(dòng)態(tài)的掛載或卸載這個(gè)塊設(shè)備。如圖：確定并修復(fù)完libvirt的狀態(tài)之后，我們就可以開始修復(fù)云硬盤在nova的狀態(tài)了。Cinder服務(wù)相關(guān)問題89B. 修復(fù)nova中云硬盤的狀態(tài)nova服務(wù)會將虛擬機(jī)的掛載的云硬盤信息記錄在一張單獨(dú)的表里面，這張表的名稱是 block_device_mapping，表結(jié)構(gòu)如下：其中比較關(guān)鍵字段的含義如下：source_type：掛載之前的類型destination_type：掛載之后的類型connection_info：連

57、接信息；虛擬機(jī)通過這些信息就可以掛載硬盤了deleted：是否有效instance_uuid: 云硬盤掛載到哪個(gè)虛擬機(jī)了如果掛載有問題，或者中途失敗，connection_info 字段為空。在nova中修復(fù)云硬盤的狀態(tài)很簡單，只需要修改上面這個(gè)表，將沒有掛載成功的云硬盤對于的信息標(biāo)記為deleted就可以了。也就是說，只需要修改deleted字段。如下：mysql update block_device_mapping set deleted=xxxx where id=xxxx;Cinder服務(wù)相關(guān)問題90C. 修復(fù)cinder中云硬盤的狀態(tài)cinder中使用了兩個(gè)表來記錄云硬盤的狀態(tài)和掛

58、載信息。分別是 volumes 和 volume_attachment。volumes的表結(jié)構(gòu)如右圖：volumes表記錄了所有的云硬盤的基本信息。其中 status 表明了目前所處的狀態(tài)，attach_status 表明了云硬盤正在執(zhí)行的操作。在cinder中修復(fù)volume的狀態(tài)要修改這個(gè)表。將云硬盤為未掛載，具體如下：mysql update volumes set status=available, attach_status=detached where id=xxxxx;Cinder服務(wù)相關(guān)問題911整體架構(gòu)2計(jì)算組件運(yùn)維34存儲組件運(yùn)維網(wǎng)絡(luò)組件運(yùn)維5認(rèn)證和鏡像運(yùn)維92Glance

59、架構(gòu)93Keystone常用命令-Tenant相關(guān)命令查看Tenant/Project列表創(chuàng)建一個(gè)tenant，名字為tenant4labskeystone tenant-create -name tenant4labskeystone tenant-list94刪除一個(gè)tenant，刪除時(shí)需要指定tenant idkeystone tenant-delete 422452437d674e5ab81c73cda7bed81fKeystone常用命令95列出所有角色keystone role-list創(chuàng)建角色，角色名為hradminkeystone role-create -name hradm

60、inKeystone常用命令96將指定用戶HR01以指定角色hradmin（通過keystone role-list 獲得），加入指定tenant Porduction（通過keystone tenant-list獲得）keystone user-role-add -user HR01 -role hradmin -tenant Porduction_HRKeystone常用命令97刪除指定tenant Porduction中的指定用戶 HR01 的指定角色 hradmin （不是刪除用戶名）keystone user-role-remove -user HR01 -role hradmin