虚拟机网络不通的场景和解决办法
openstack虚拟机网络不通场景和排查思路
总结下当遇到虚拟机获取不到IP地址或虚拟机网络不通的故障原因和排查思路。
content of tables
- 基本技巧
- 场景一:物理网络故障
- 场景二:neutron-dhcp-agent故障
- 场景三:openvswitch故障
- 经验总结
基本技巧
- 会抓包,排查网络问题非常重要与核心的技巧,通常使用tcpdump命令。
- 会对比,控制变量法是比较好用的运维手段,比方说:一个网络创虚拟机获不到IP,那其他网络有这个问题吗?相同网络在其他计算节点上有问题吗?等等。通过对比来缩小或者定位问题。
- 对openstack-neutron组件的架构要有一定了解。
物理网络故障
适用场景
尤其是新部署的openstack环境,会遇到上联交换机配置有问题的情况。运行一段时间的openstack环境多半不会遇到这个问题,除非交换机故障了。
排查方法
找到ovs对接外部网络的网桥br0
[root@server-91 ~ ]$ grep bridge_mappings /etc/neutron/plugins/ml2/openvswitch_agent.ini | grep -v '^#' bridge_mappings =physnet1:br0
通过bro网桥找到该计算节点SDN网卡(也叫业务网络网卡),可以看到SDN网络使用的是网卡bond2
[root@server-96 ~ ]$ ovs-ofctl show br0 OFPT_FEATURES_REPLY (xid=0x2): dpid:000060da833de085 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(bond2): addr:60:da:83:3d:e0:85 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(phy-br0): addr:32:ed:eb:89:b5:15 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br0): addr:60:da:83:3d:e0:85 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
给SDN网卡bond2配置子接口,用于测试
# 配置vlan类型的子接口bond2.3933,指定vlan_id为3933 ip link add link bond2 name bond2.3933 type vlan id 3933 # 将子接口设置为up并配置IP地址 ip link set bond2.3933 up ip a add 10.19.43.254/24 dev bond2.3933
通过子接口ping网关,测试SDN网络上联交换机是否放行3933的vlan
# 能ping通则说明交换机配置没问题,否则有问题 [root@server-96 ~ ]$ ping -I bond2.3933 10.19.43.1
neutron-dhcp-agent故障
适用场景
- 昨天neutron做过的变更?
- 这个neutron-dhcp-agent服务器节点昨天有过重启?
排查方法
查看neutron-dhcp-agent服务是否正常运行,如果有问题提可以尝试重启。正常运行情况:
[root@server-91 ~ ]$ systemctl status neutron-dhcp-agent ● neutron-dhcp-agent.service - OpenStack Neutron DHCP Agent Loaded: loaded (/usr/lib/systemd/system/neutron-dhcp-agent.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2018-03-20 10:07:32 CST; 5h 28min ago Main PID: 51456 (neutron-dhcp-ag) CGroup: /system.slice/neutron-dhcp-agent.service ├─13681 dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-f... ├─51456 /usr/bin/python2 /usr/bin/neutron-dhcp-agent --config-file /usr/share/neutr... ├─51472 sudo neutron-rootwrap-daemon /etc/neutron/rootwrap.conf ├─51473 /usr/bin/python2 /usr/bin/neutron-rootwrap-daemon /etc/neutron/rootwrap.con...
查看neutron-dhcp-agent服务日志是否报错
[root@server-91 ~ ]$ vim /var/log/neutron/dhcp-agent.log
排查dhcp的namespace网络问题,下面是正常情况
# 这个网络在openstack中的id:"0879fde8-02d6-443a-b370-a5168d81d415",网络的网关为:10.19.43.1 [root@server-91 ~ ]$ ip netns exec qdhcp-0879fde8-02d6-443a-b370-a5168d81d415 ping 10.19.43.1 PING 10.19.43.1 (10.19.43.1) 56(84) bytes of data. 64 bytes from 10.19.43.1: icmp_seq=1 ttl=255 time=0.662 ms 64 bytes from 10.19.43.1: icmp_seq=2 ttl=255 time=0.931 ms 64 bytes from 10.19.43.1: icmp_seq=3 ttl=255 time=0.613 ms ^C --- 10.19.43.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.613/0.735/0.931/0.141 ms
openvswitch故障
使用场景
- 计算节点是否有过重启?
- 计算节点的物理网络近期是否有过故障?
- neutron近期是否有过升级?
排查方法
查看neutron-openvswitch-agent服务是否正常运行,正常运行如下:
# 如果有报错 [[email protected] ~ ]$ systemctl status neutron-openvswitch-agent.service ● neutron-openvswitch-agent.service - OpenStack Neutron Open vSwitch Agent Loaded: loaded (/usr/lib/systemd/system/neutron-openvswitch-agent.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2018-02-28 17:35:36 CST; 2 weeks 5 days ago Main PID: 587 (neutron-openvsw) CGroup: /system.slice/neutron-openvswitch-agent.service
假设br0是ovs对接外部网络的网桥,查看br0是否有SDN网卡的port
# 查看 [root@server-96 ~ ]$ ovs-ofctl show br0 OFPT_FEATURES_REPLY (xid=0x2): dpid:000060da833de085 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(bond2): addr:60:da:83:3d:e0:85 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(phy-br0): addr:32:ed:eb:89:b5:15 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br0): addr:60:da:83:3d:e0:85 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
手动添加bond2作为br0的端口
ovs-vsctl add-port br0 bond2
流表问题
假设br0是ovs对接外部网络的网桥,br-int是ovs内部网桥,网络外部vla_id:3933 内部vlan_id:1
正常流表应该长这个样子# br0负责将内部vlan转换为外部vlan,即1==>3933,对应的流表如下;idle_age表示流表空闲时间,也就是说有流量就会刷新idle_age为0 [root@server-96 ~ ]$ ovs-ofctl dump-flows br0 | grep "3933" cookie=0x906858904127f7ac, duration=1724236.477s, table=0, n_packets=72337, n_bytes=9383557, idle_age=0, hard_age=65534, priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:3933,NORMAL # br-int负责将外部vlan转换为内部vlan。即3933==>1,对应的流表为 [root@server-96 ~ ]$ ovs-ofctl dump-flows br-int | grep "3933" cookie=0x0, duration=20534.346s, table=0, n_packets=172821, n_bytes=221816841, idle_age=0, priority=3,in_port=1,dl_vlan=3933 actions=mod_vlan_vid:1,NORMAL
流表的手动添加:假设br-int上未发现关于3933的流表,执行添加命令:
ovs-ofctl add-flow br-int "table=0,priority=3,in_port=1,dl_vlan=3933,actions=mod_vlan_vid:1,NORMAL"
经验总结
如果一个新人问你:
“xxx服务起不来了,你遇到过没?怎么处理的啊?”
“虚拟机连不上了,你遇到过没?怎么处理的啊?”
“虚拟机创建失败了,你遇到过没?怎么处理的啊?”
......
对于一个运维的老司机来讲,他不会告诉你怎么怎么做就好了,因为他也不能确定问题出来哪里。他的回答经常是“看日志!” 。没错,这个回答是最准确的也是最中肯的。
所谓运维经验丰富无非就是经过时间的考验与洗礼后,他们更加熟悉环境,更加有从着手,接触过的场景更多,内心更加自信,执行效率更高。
有过一定运维经验的同学都明白一个道理:“同样的故障现象,原因可能是五花八门的”。老司机不会妄下断论,他们会考虑故障发生之前环境的变动情况(前两天是否做过neutron的变更?前几天是否有过物理服务器重启?前几天是否有过类似的故障?等等),同时他们也会查看日志,然后找到原因,最后解决问题。
虚拟机网络不通的问题是常见现象,针对排查思路做如下总结:
- 如果是正在部署云平台,考虑是否交换机配置有问题,可以通过绑定子接口的方式测试。
- 如果是正常运行的云平台突然出现了问题,考虑neutron相关服务问题(ovs、dhcp-agent等)。
- 如果是neutron服务的问题,通过看日志定位问题。
- 如果物理网络没问题,neutron服务没有问题,通过对dhcp的namespace、SDN网卡、ovs内的tap设备抓包的来定位。
- 定位到问题后可以通过调整交换机配置、重启服务、添加port、添加流表等方式解决问题。