zoukankan      html  css  js  c++  java
  • 虚拟机网络不通的场景和解决办法

    openstack虚拟机网络不通场景和排查思路

    总结下当遇到虚拟机获取不到IP地址或虚拟机网络不通的故障原因和排查思路。


    content of tables

    1. 基本技巧
    2. 场景一:物理网络故障
    3. 场景二:neutron-dhcp-agent故障
    4. 场景三:openvswitch故障
    5. 经验总结

    基本技巧

    • 会抓包,排查网络问题非常重要与核心的技巧,通常使用tcpdump命令。
    • 会对比,控制变量法是比较好用的运维手段,比方说:一个网络创虚拟机获不到IP,那其他网络有这个问题吗?相同网络在其他计算节点上有问题吗?等等。通过对比来缩小或者定位问题。
    • 对openstack-neutron组件的架构要有一定了解。

    物理网络故障

    适用场景

    尤其是新部署的openstack环境,会遇到上联交换机配置有问题的情况。运行一段时间的openstack环境多半不会遇到这个问题,除非交换机故障了。

    排查方法

    1. 找到ovs对接外部网络的网桥br0

      [root@server-91 ~ ]$ grep bridge_mappings /etc/neutron/plugins/ml2/openvswitch_agent.ini | grep -v '^#'
      bridge_mappings =physnet1:br0
      
    2. 通过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
      
    3. 给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
      
    4. 通过子接口ping网关,测试SDN网络上联交换机是否放行3933的vlan

      # 能ping通则说明交换机配置没问题,否则有问题
      [root@server-96 ~ ]$ ping -I bond2.3933 10.19.43.1
      

    neutron-dhcp-agent故障

    适用场景

    • 昨天neutron做过的变更?
    • 这个neutron-dhcp-agent服务器节点昨天有过重启?

    排查方法

    1. 查看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...
      
    2. 查看neutron-dhcp-agent服务日志是否报错

      [root@server-91 ~ ]$ vim /var/log/neutron/dhcp-agent.log
      
    3. 排查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近期是否有过升级?

    排查方法

    1. 查看neutron-openvswitch-agent服务是否正常运行,正常运行如下:

      # 如果有报错
      [root@server-96.2.nansi.polex.io ~ ]$ 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
      
    2. 假设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
      
    3. 手动添加bond2作为br0的端口

      ovs-vsctl add-port br0 bond2
      
    4. 流表问题

      假设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的变更?前几天是否有过物理服务器重启?前几天是否有过类似的故障?等等),同时他们也会查看日志,然后找到原因,最后解决问题。

    虚拟机网络不通的问题是常见现象,针对排查思路做如下总结:

    1. 如果是正在部署云平台,考虑是否交换机配置有问题,可以通过绑定子接口的方式测试。
    2. 如果是正常运行的云平台突然出现了问题,考虑neutron相关服务问题(ovs、dhcp-agent等)。
    3. 如果是neutron服务的问题,通过看日志定位问题。
    4. 如果物理网络没问题,neutron服务没有问题,通过对dhcp的namespace、SDN网卡、ovs内的tap设备抓包的来定位。
    5. 定位到问题后可以通过调整交换机配置、重启服务、添加port、添加流表等方式解决问题。
  • 相关阅读:
    项目实战9—企业级分布式存储应用与实战MogileFS、FastDFS
    项目详解4—haproxy 反向代理负载均衡
    项目实战4—HAProxy实现高级负载均衡实战和ACL控制
    项目实战2.1—nginx 反向代理负载均衡、动静分离和缓存的实现
    zabbix设置报警通知
    zabbix创建触发器
    zabbix的启动和关闭脚本
    zabbix监控第一台服务器
    zabbix的源码安装
    Linux命令之乐--iconv
  • 原文地址:https://www.cnblogs.com/mauricewei/p/8610343.html
Copyright © 2011-2022 走看看