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