高可用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