經驗借鑑

一、環境準備

1. 準備：

      兩臺虛擬機器，第一臺（hostname:devstack）充當控制、網路、計算節點（allinone），第二臺（hostname:devstack-com）充當計算節點。記憶體為8G、磁碟100G全部掛在/下，便於開發。安裝Centos Linux release 7.2.1511，選擇最簡安裝。OpenStack版本將對齊社群Master分支，目前即為開發中Queen版。

2. 網絡卡配置：

eth0  -  模擬業務網  -  (192.168.0.0/24)  ;   eth1  -  模擬管理網  -  (10.134.1.0/24)  ;  eth2  -  模擬外網  -  (10.254.4.0/24)

devstack         -  eth0：192.168.0.156 、eth1：10.134.1.156 、eth2：10.254.4.156

devstack-com -  eth0：192.168.0.157 、eth1：10.134.1.157 

3. 整體規劃如下：

二、自動化安裝（step by step）

1. 配置國內base源：

[[email protected] ~]# cd /etc/yum.repos.d/ ; wget http://mirrors.163.com/.help/CentOS7-Base-163.repo

2. 安裝git工具：

[[email protected]

k ~]# yum install git -y

3. clone原始碼：

[[email protected] ~]# cd /home ; git clone https://github.com/openstack-dev/devstack.git

4. 建立stack使用者：

[[email protected] /home]# /home/devstack/tools/create-stack-user.sh

5. 修改配置檔案：

控制、網路、計算複用節點配置：

說明：HOST_IP為該節點的管理IP、密碼均使用123456最簡密碼。

注： 此配置規劃了將使用的外網網段，即FLOATING_RANGE、Q_FLOATING_ALLOCATION_POOL、PUBLIC_NETWORK_GATEWAY三個欄位配置。若未規劃，可將NEUTRON_CREATE_INITIAL_NETWORKS置為False，可以搭建完成後手動配置。

計算節點配置：

注：此配置中的PLACEMENT_SERVICE_HOST經測試為生效，由於目前Nova程式碼master版本缺少Placement配置會報異常，導致Nova-compute不能正常啟動，即在安裝出錯後，得手動配置，在後面 （7.啟動安裝） 處會詳細說明。

6. 更改檔案使用者：

[[email protected] ~]# chown -R stack:stack /home/devstack/

7. 啟動安裝：

控制、網路、計算複用節點（devstack節點）：

[[email protected] ~]# su stack

[[email protected] devstack]$ cd /home/devstack/ ; ./stack.sh

到這裡，devstack節點安裝就完成了。區別於rdo的rpm包安裝，devstack是原始碼安裝。因為要install大量的python依賴，控制節點安裝在2小時左右。

計算節點（devstack-com節點）：

[[email protected] devstack]$ cd /home/devstack/ ; ./stack.sh

報錯，發現n-cpu服務並未啟動，可在/etc/nova/nova-cpu.conf中新增如下配置：

執行： [[email protected] ~]# systemctl restart [email protected] ， 即可完成安裝。

8. 其餘問題：

1）調整業務網：安裝完發現，業務網走的還是管理網路，

options: {df_default="true", in_key=flow, local_ip="10.134.1.156", out_key=flow, remote_ip="10.134.1.157"}

但實際規劃的是192.168.0.0/24網路做業務網，這裡需要調整/etc/neutron/plugins/ml2/ml2_conf.ini檔案：

重啟服務：systemctl restart [email protected] ，即可。

現在利用ovs-vsctl show命令可觀察到：

options: {df_default="true", in_key=flow, local_ip="192.168.0.156", out_key=flow, remote_ip="192.168.0.157"}

2）手動建立網路：如果之前devstack節點的配置檔案中， NEUTRON_CREATE_INITIAL_NETWORKS設為False，預設不會建立網路，要手動建立：

使用admin租戶、admin使用者： # source /home/devstack/openrc admin admin

建立外部網路： # neutron net-create ext-net --provider:network_type flat --provider:physical_network public --shared --router:external

建立外部子網：# neutron subnet-create ext-net 10.254.4.0/24 --name ext-subnet --allocation-pool start=10.254.4.205,end=10.254.4.215 --gateway 10.254.4.254

使用demo租戶、demo使用者： # source /home/devstack/openrc demo demo

建立租戶網路：# neutron net-create demo-net

建立租戶子網：# neutron subnet-create demo-net 192.168.1.0/24 --name demo-subnet --gateway 192.168.1.1

建立租戶路由：# neutron router-create demo-router

子網接入路由：# neutron router-interface-add demo-router demo-subnet

子網設定閘道器：# neutron router-gateway-set demo-router ext-net

3） cell對映：

社群在O版後，nova引入了cellv2並強制使用，當新增計算節點後，要對映至所屬cell中，執行

# nova-manage cell_v2 discover_hosts --verbose

9. 升級與重灌：

1. 升級devstack程式碼：

# cd /home/devstack/ ; git pull

2. 升級元件程式碼（以nova為例）：

# cd /opt/stack/nova/ ; git pull

注意需要重啟nova相關服務，db或者api_db有修改的話，需要把資料庫拉至最新：

# nova-manage db sync

# nova-manage api_db sync

# systemctl restart [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

3. 重灌：

# cd /home/devstack/ ; ./unstack.sh     停止服務

# cd /home/devstack/ ; ./clean.sh         刪除已有資料

# cd /home/devstack/ ; ./stack.sh         重新安裝

4. 所有元件升級：

最好的方式就是重灌，並建議刪除/opt/stack下所有元件原始碼，重新clone安裝依賴

三、環境確認、測試

1. 服務狀態確認

Keystone: 服務內部沒有mq通訊，執行# openstack project list ， 有顯示即正常。

Nova： 執行# nova service-list ， 檢視各服務state是否為up。

Neutron： 執行# neutron agent-list ， 檢視alive是否為:-)

Cinder：執行# openstack volume service list ，檢視各服務state是否為up

Glance：服務內部沒有mq通訊，執行#glance image-list ， 有映象顯示即正常。

Horizon：本地登陸http://10.134.1.156/dashboard，若本地不通管理網，使用elinks  http://10.134.1.156/dashboard 檢查

2. 建立虛機測試

1. 使用demo租戶、demo使用者

# source /home/devstack/openrc demo demo

2. 建立本地虛機：

# nova boot test --flavor 1 --image cirros-0.3.4-x86_64-disk --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07

3. 建立卷虛機：

# nova boot test-vol --flavor 1 --block-device source=image,id=58aa7836-eabb-431c-9247-5787680e6f46,dest=volume,size=1,bootindex=0,shutdown=remove --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07

4. 檢視虛機狀態，直至active：

# nova list

5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11

573961c6-354a-439a-a665-7058e3bc98bb | test-vol | ACTIVE | - | Running | demo-net=192.168.1.4

5. 登陸vnc進行進一步檢視：

# nova get-vnc-console test novnc

novnc | http://10.134.1.156:6080/vnc_auto.html?token=23df2caf-095a-4c00-9933-5cefd0fb47d8

3. 網路狀態確認

1. 外網連通訊檢測，最簡單的方法就是，從本地去ping，netns中qrouter的qg口：

# ip netns exec qrouter-f8d0e07a-bc9f-4642-9892-9711b94c3410 ip a | grep 10.254

inet 10.254.4.210/24 brd 10.254.4.255 scope global qg-63090b03-08

# ping 10.254.4.210

2. 外網snat確認:

通過ns登陸虛擬機器 # ip netns exec qdhcp-89070a3f-1c28-480a-8db6-c59376b0ed07 ssh [email protected]，若無法登陸，請放通安全組。

# ping 10.254.4.156

3. floatingip dnat確認：

建立floatingip：# neutron floatingip-create ext-net

繫結floatingip：# neutron floatingip-associate 3f9ecd27-e8c1-429e-a77a-d00af3c3bcaf 28e76da8-9fd6-4d55-b2c9-4b9c1b419c87

5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11, 10.254.4.208

# ping 10.254.4.208

4. 遷移/熱遷移確認：

1. hosts解析，stack使用者需要互信，這些是devstack不會做的，自己手動配置下，具體方法就不說了

2. 登陸dashboard進行測試，觀察resize後flavor的變化，live-migrate後host的變化，一般都是OK的

四、開發除錯技巧

1. 檢視安裝服務

新版本的devstack用systemd取代了screen來啟動服務

# systemctl | grep devstack

這裡c-開頭的就是cinder服務，g-開頭的就是glance服務，keystone即keystone服務，n-即nova服務，q-即neutron服務，placement-api即nova-placement服務，dstat是以dstat命令為基礎的監控，etcd是分散式儲存服務、作為cinder的分散式鎖。

所有守護程序服務都可以在/etc/systemd/system/下找到對應檔案，即可找到入口及對應引數。

2. 檢視日誌

新版本devstack不再記錄日誌在/var/log 或 /opt/stack/log下，轉而使用journalctl來代替：

# journalctl -a --unit [email protected] | grep XXX 這個相當於之前的 # cat /var/log/nova/nova-compute.log | grep XXX

# journalctl -f --unit [email protected]   這個相當於之前的 # tail -f /var/log/nova/nova-compute.log

3. 斷點除錯

由於目前devstack中很多服務都是依賴httpd啟動的，傳統的關閉守護服務，利用命令啟動加pdb斷點除錯已不再試用，這裡使用社群官方推薦的remote-pdb，即：

from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace()   取代之前的   import pdb ; pdb.set_trace()

之後重啟服務即可，呼叫對應api後進入斷點，利用telnet或nc -t命令即可進行除錯。

4. 綜合分析、善用git

這裡以nova為例，比如在Pike版本排程中，提出了基於Placement的Allocation candidates策略，即CPU、MEM、DISK過濾不再經過nova中的對應filter，而是傳送rest請求給Placement服務，利用sql語句（不加以orm封裝的）來直接過濾，得出候選主機。當然，Placement服務還在開發中，我們選擇配置driver=caching_scheduler來遮蔽它，不過在目前（2017/12/20）的nova程式碼中，貌似行不通.......

1、問題復現：

修改nova.conf中的driver = filter_scheduler，改為driver = caching_scheduler，重啟[email protected]服務，再啟動一個虛機，發現ERROR。

2、問題定位：

檢視日誌：# journalctl -a --unit [email protected] | grep ERROR

發現：ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/manager.py", line 152, in select_destinations

           ERROR oslo_messaging.rpc.server allocation_request_version, return_alternates)

           ERROR oslo_messaging.rpc.server UnboundLocalError: local variable 'allocation_request_version' referenced before assignment

根據Traceback，定位問題發生在scheduler服務中，出錯程式碼為/opt/stack/nova/nova/scheduler/manager.py第152行

3、閱讀程式碼，進一步定位：

85 def select_destinations(self, ctxt, request_spec=None,

...................................

119        alloc_reqs_by_rp_uuid, provider_summaries = None, None

120        if self.driver.USES_ALLOCATION_CANDIDATES:

121            res = self.placement_client.get_allocation_candidates(resources)

122            if res is None:

123                # We have to handle the case that we failed to connect to the

124                # Placement service and the safe_connect decorator on

125                # get_allocation_candidates returns None.

126                alloc_reqs, provider_summaries, allocation_request_version = (

127                        None, None, None)

128            else:

129                (alloc_reqs, provider_summaries,

130                            allocation_request_version) = res

...................................

150        selections = self.driver.select_destinations(ctxt, spec_obj,

151        instance_uuids, alloc_reqs_by_rp_uuid, provider_summaries,

152        allocation_request_version, return_alternates)

發現只有當self.driver.USES_ALLOCATION_CANDIDATES為true時，才能得到allocation_request_version，否則該變數就不存在！！！

3、斷點除錯，確認問題：

在/opt/stack/nova/nova/scheduler/manager.py中插入斷點：

119        alloc_reqs_by_rp_uuid, provider_summaries = None, None

120        from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace()

121        if self.driver.USES_ALLOCATION_CANDIDATES:

安裝remote-pdb ： # pip install remote-pdb ； 重啟[email protected]服務：systemctl restart [email protected]；再次建立虛機

執行 # nc -t 127.0.0.1 4444 進入斷點，進行簡單除錯：

發現caching_scheduler確實是不使用Allocation candidates策略的，引入allocation_request_version是引發這一問題的元凶。

4、利用git查詢程式碼歷史：

# git annotate /opt/stack/nova/nova/scheduler/manager.py

# git log

作者：Remy_XL
連結：https://www.jianshu.com/p/8d2b2637f3d4
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。