参考文档：
- Install-guide：https://docs.openstack.org/install-guide/
- OpenStack High Availability Guide：https://docs.openstack.org/ha-guide/index.html
- 理解Pacemaker：http://www.cnblogs.com/sammyliu/p/5025362.html
二十一．一些问题
1. kvm实例获取不到dhcp地址
1）现象
- 使用vmware vsphere搭建的openstack环境，控制/计算节点分离；
- 通过dashboard控制台下发kvm实例时，实例不能获取ip地址。
2）分析
-
控制/计算节点分离时，计算节点生成的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控制节点
-
观察kvm实例启动日志，发现实例主动发起的dhcp请求（dhcp request，属于udp 68）；
-
同时在网络控制节点的相关网卡抓包（通过"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）环境
- 使用vmware vsphere搭建的openstack环境，控制/计算节点均为虚拟机；
- Openstack环境下，设置kvm虚拟机基于vlan通信，宿主机上行到交换机的端口做trunk，并已放行通信vlan；
- 在相同子网（vlan）不同计算节点生成两台实例，各自已获得相同子网的ip，且已形成vm_vif---tapxxx---brqxxx---ethx.vlan_id---ethx---switch_port的逻辑关系。
2）现象
上述环境中的两台实例不能互相ping通，通过tcpdump抓包观察，具体表现为：
-
两台实例发出的arp request包（首包），通过vm_vif---tapxxx---brqxxx---ethx.vlan_id---ethx，但在switch_port上未抓到包；
-
在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个安全选项设置：
- 混杂模式：vSphere知道所有接入vss/vds的接口mac地址，不需要根据数据包的源mac来更新mac与port的映射，所以vss/vds不具备mac学习功能(与传统交换机不同)。混杂模式未开启时，如果目标mac不属于该vss/vds，那么vss/vds将丢弃该数据包；vss/vds开启混杂模式时，所属的port将收到vss/vds上vlan策略所允许的所有流量。
- MAC地址更改：设置为拒绝时，若vm的接口mac地址被更改，与vm的.vmx配置文件中的地址不一致，则所有进入该接口的数据帧都会被丢弃。
- 伪传输：设置为拒绝时，若vm发送的数据包源mac地址与当前适配器的mac地址不一致，该数据包会被丢弃。
结论：
- 由于kvm实例的vif是通过桥接的方式直接与外部通信，其源mac直接暴露到宿主机网卡，但vmware vsphere默认设置vss/vds的"伪传输"选项为"拒绝"，导致从kvm虚拟机发送的数据包在宿主机的"物理"网卡上即被丢弃。
-
加入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"信息。
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）分析
上述现象分两个纬度：
- 如果cinder-volume运行在active/active模式，不同的客户端请求会通过前端haproxy（取决于负载方式）分配到不同的后端cinder-volume服务器，由于cinder-volume是有状态的服务，会导致在2号cinder-volume服务器上没有在1号cinder-volume服务器创建的volume的状态，导致volume无法删除；
- 如果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