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