高可用OpenStack（Queen版）集羣-17.一些問題

參考文檔：

1. Install-guide：https://docs.openstack.org/install-guide/
2. OpenStack High Availability Guide：https://docs.openstack.org/ha-guide/index.html
3. 理解Pacemaker：http://www.cnblogs.com/sammyliu/p/5025362.html
4. Ceph: http://docs.ceph.com/docs/master/start/intro/

二十一．一些問題

1. kvm實例獲取不到dhcp地址

1）現象

1. 使用vmware vsphere搭建的openstack環境，控制/計算節點分離；
2. 經過dashboard控制檯下發kvm實例時，實例不能獲取ip地址。

2）分析

1. 控制/計算節點分離時，計算節點生成的kvm實例會經過dhcp向neutron網絡控制節點（含dhcp-agnet，metadata-agent，l3-agnet等服務）的dhcp-agent（dnsmasq提供）獲取ip，kvm實例獲取ip地址流程以下（vlan網絡）：

   計算節點（instance_vif---vifyyy---brqyyy---ethy.vlan_id---ethy）---（ethx--- ethx.vlan_id---brqxxx---vifxxx---dnsmasq_vif）neutron控制節點

2. 觀察kvm實例啓動日誌，發現實例主動發起的dhcp請求（dhcp request，屬於udp 68）；

3. 同時在網絡控制節點的相關網卡抓包（經過"brctl show"可查詢到相關網卡）：

   # 對接dnsmasq_vif的網卡； # dnsmasq收到dhcp廣播並回復了dhcp offer（udp 67）
   [root@controller01 ~]# tcpdump -i tap004b787f-9b -ne port 67 or 68

   # 網橋； # 網橋收到dhcp廣播，正常轉發到dnsmasq，且收到dnsmasq回覆的dhcp offer
   [root@controller01 ~]# tcpdump -i brq91e78b9c-cf -ne port 67 or 68

   # 物理網卡（帶tag）； # 物理網卡收到dhcp廣播，正常轉發到網橋，但並未收到應該從網橋轉發過來的dhcp offer
   [root@controller01 ~]# tcpdump -i eth3.3092 -ne port 67 or 68

   證實從網橋到物理網卡的轉發有問題。

3）緣由

iptables默認規則下，在forward表中有一條鏈：

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

即：iptables默認不轉發數據包，且阻斷後回覆消息"icmp-host-prohibited"。

4）解決方案

# 在neutron網絡控制節點，刪除禁止轉發的默認規則
[root@controller01 ~]# iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited

# 同時在neutron網絡控制節點，修改iptables規則文件，註釋禁止轉發的默認規則
[root@controller01 ~]# vim /etc/sysconfig/iptables #-A FORWARD -j REJECT --reject-with icmp-host-prohibited
 ps：常規狀況下儘可能不要隨意重啓iptables服務；若是重啓了iptables服務，須要重啓neutron-linuxbridge-agent服務，從新向iptables注入neutron相關轉發規則。

2. 相同子網不一樣計算節點的兩臺kvm實例不能ping通

1）環境

1. 使用vmware vsphere搭建的openstack環境，控制/計算節點均爲虛擬機；
2. Openstack環境下，設置kvm虛擬機基於vlan通訊，宿主機上行到交換機的端口作trunk，並已放行通訊vlan；
3. 在相同子網（vlan）不一樣計算節點生成兩臺實例，各自已得到相同子網的ip，且已造成vm_vif---tapxxx---brqxxx---ethx.vlan_id---ethx---switch_port的邏輯關係。

2）現象

上述環境中的兩臺實例不能互相ping通，經過tcpdump抓包觀察，具體表現爲：

1. 兩臺實例發出的arp request包（首包），經過vm_vif---tapxxx---brqxxx---ethx.vlan_id---ethx，但在switch_port上未抓到包；

2. 在switch上針對vlan_id設置vlanif，從switch主動ping兩臺實例（swith是外部環境，需提早設置安全組，容許外部環境ping內部主機），arp request包（首包）到達kvm虛擬機，且kvm實例的arp reply包正常回到ethx接口，但在switch_port上未抓到arp reply包。

           證實計算節點宿主機的"物理"接口與switch之間的通訊有問題。

3）緣由

環境是基於vmware vsphere搭建的，其vss/vds有3個安全選項設置：

1. 混雜模式：vSphere知道全部接入vss/vds的接口mac地址，不須要根據數據包的源mac來更新mac與port的映射，因此vss/vds不具有mac學習功能(與傳統交換機不一樣)。混雜模式未開啓時，若是目標mac不屬於該vss/vds，那麼vss/vds將丟棄該數據包；vss/vds開啓混雜模式時，所屬的port將收到vss/vds上vlan策略所容許的全部流量。
2. MAC地址更改：設置爲拒絕時，若vm的接口mac地址被更改，與vm的.vmx配置文件中的地址不一致，則全部進入該接口的數據幀都會被丟棄。
3. 僞傳輸：設置爲拒絕時，若vm發送的數據包源mac地址與當前適配器的mac地址不一致，該數據包會被丟棄。

結論：

1. 因爲kvm實例的vif是經過橋接的方式直接與外部通訊，其源mac直接暴露到宿主機網卡，但vmware vsphere默認設置vss/vds的"僞傳輸"選項爲"拒絕"，致使從kvm虛擬機發送的數據包在宿主機的"物理"網卡上即被丟棄。
2. 加入bridge網橋的宿主機網卡自動進入promiscuous mode，並進入forwarding state (可使用dmesg查看)，但vmware vsphere默認設置vss/vds的"混雜模式"選項爲"拒絕"，也會致使丟包

4）解決方案

設置vss/vds安全選項中的"混雜模式"與"僞傳輸"參數爲"接受"，

3. 打開實例console失敗

1）現象

經過dashboard實例---控制檯，打開實例console失敗。

報錯：Failed to connect to server(code: 1006)

2）分析

# 查看觀察vnc日誌，日誌文件/var/log/nova/nova-novncproxy.log
[root@controller01 ~]# tailf /var/log/nova/nova-novncproxy.log

實例console是經過vnc打開的，訪問horizon dashboard後，nova控制節點將請求定向到實例所在計算節點tcp 5900端口，即kvm服務監聽端口，如這裏實例位於172.30.200.41(compute01)節點，但默認計算節點的tcp 5900端口未打開，返回"handler exception: [Errno 113] EHOSTUNREACH"信息。

參考：https://ask.openstack.org/en/question/520/vnc-console-in-dashboard-fails-to-connect-ot-server-code-1006/

3）解決方案

# 放開全部計算節點的tcp 5900端口；如無必要，不要隨意重啓iptables服務； # 同時更新/etc/sysconfig/iptables文件，以避免服務重啓後端口實效
[root@compute01 ~]# iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT

4. 經過dashboard建立的實例被刪除後，實例掛載的volume不能刪除

1）現象

經過dashboard建立的實例，在刪除實例後，對應綁定的volume不會自動刪除。

2）分析

建立實例與建立並掛載volume是獨立的步驟（經過cli方式的"nova boot"啓動實例時，不指定"--block-device"選項，不會掛載已建立的持久性存儲），理論上建立的實例是有臨時存儲；而volume只是dashboard在建立實例的同時建立的，而後將volume掛載到實例。因此在刪除實例時，持久性存儲volume不會同步刪除。

持久性存儲volume不會同步被刪除的好處在於，若是volume存有重要數據，經過新啓動的實例還可被掛載。

因此是否容許volume隨實例一塊兒建立須要根據實際環境肯定。

在dashboard中建立實例時，是否同步刪除volume是可選項，以下：

3）解決方案

# 取消288~296行註釋； # 變動’create_volume’的默認值「True」爲「False」，即建立實例的同時不一樣步建立volume並掛載
288 LAUNCH_INSTANCE_DEFAULTS = { 289     'config_drive': False, 290     'enable_scheduler_hints': True, 291     'disable_image': False, 292     'disable_instance_snapshot': False, 293     'disable_volume': False, 294     'disable_volume_snapshot': False, 295     'create_volume': False, 296 }

5. 建立的卷不能刪除

1）現象

在客戶端A建立volume成功後，在客戶端B不能刪除；或者運行在active/standby模式的cinder-volume服務故障切換後，在原客戶端不能刪除volume。

2）分析

上述現象分兩個緯度：

1. 若是cinder-volume運行在active/active模式，不一樣的客戶端請求會經過前端haproxy（取決於負載方式）分配到不一樣的後端cinder-volume服務器，因爲cinder-volume是有狀態的服務，會致使在2號cinder-volume服務器上沒有在1號cinder-volume服務器建立的volume的狀態，致使volume沒法刪除；
2. 若是cinder-volume運行在active/standby模式，能夠避免上述問題，但只是治標；若是active服務故障，致使故障切換，standby服務升active，原active服務建立的volume狀態不會同步到新active服務器，也會致使volume沒法刪除。

3）解決方案

# 後端使用共享存儲時，建議將cinder-volume部署在控制節點，並運行在active/standby（經過pacemaker實現）模式的同時，在cinder-volume配置的deafault字段，設置主機名標識符，使volume狀態同步； # 主機自定義名標識； # 集羣中cinder-volume所在主機都須要設置； # 理論上，設置主機名標識後，cinder-volume可運行在active/standby或active/active模式
[root@compute01 ~]# vim /etc/cinder/cinder.con
[DEFAULT] host = node-volume # 驗證； # 原host的」state」會」down」，新啓動的host名同配置文件中的host參數
[root@controller01 ~]# openstack volume service list