当发现你的OpenStack虚拟机网络有问题,不妨先试一下这16个步骤

1. Security Group全部打开,这是最基本的,但是很多人容易忘记

 

其实遇到过无数这种场景了,Debug了半天网络问题,各种手段都用上了,最后发现安全组竟然没有打开。

 

 

 

 

2. 通过界面查看虚拟机的log,也可以在compute节点上查看console.log文件,看看里面是否有DHCP获取IP成功的日志

 

在界面上可以看控制台日志

 

 

在compute节点上可以查看

 

/var/lib/nova/instances/6323a941-de10-4ed3-9e2f-1b2b25e79b66/console.log

 

如果没有日志,则说明image有问题

 

在grub里面

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=ttyS0

 

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0“

 

update-grub

 

3. 如果虚拟机连不上DHCP Server,则需要准备一个不使用metadata server,而是用用户名密码可以登录的image

 

这种Image很好做,自己动手做一个就可以了,启动镜像后去掉cloud-init相关配置,然后设置一个默认的用户名密码。

 

4. 通过VNC登录

 

 

5. 如果VNC登录不进去,说明VNC配置的有问题,方法一重新配置VNC

 

 

VNC Proxy的功能:

  • 将公网(public network)和私网(private network)隔离

  • VNC client运行在公网上,VNCServer运行在私网上,VNC Proxy作为中间的桥梁将二者连接起来

  • VNC Proxy通过token对VNC Client进行验证

  • VNC Proxy不仅仅使得私网的访问更加安全,而且将具体的VNC Server的实现分离,可以支持不同Hypervisor的VNC Server但不影响用户体验

 

VNC Proxy的部署

  • 在Controller节点上部署nova-consoleauth 进程,用于Token验证

  • 在Controller节点上部署nova-novncproxy 服务,用户的VNC Client会直接连接这个服务

  • Controller节点一般有两张网卡,连接到两个网络,一张用于外部访问,我们称为public network,或者API network,这张网卡的IP地址是外网IP,如图中172.24.1.1,另外一张网卡用于openstack各个模块之间的通信,称为management network,一般是内网IP,如图中10.10.10.2

  • 在Compute节点上部署nova-compute,在nova.conf文件中有下面的配置

  • vnc_enabled=True

  • vncserver_listen=0.0.0.0 //VNC Server的监听地址

  • vncserver_proxyclient_address=10.10.10.2 //nova vnc proxy是通过内网IP来访问vnc server的,所以nova-compute会告知vnc proxy用这个IP来连接我。

  • novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html //这个url是返回给客户的url,因而里面的IP是外网IP

 

VNC Proxy的运行过程:

  1. 一个用户试图从浏览器里面打开连接到虚拟机的VNC Client

  2. 浏览器向nova-api发送请求,要求返回访问vnc的url

  3. nova-api调用nova-compute的get vnc console方法,要求返回连接VNC的信息

  4. nova-compute调用libvirt的get vnc console函数

  5. libvirt会通过解析虚拟机运行的/etc/libvirt/qemu/instance-0000000c.xml文件来获得VNC Server的信息

  6. libvirt将host, port等信息以json格式返回给nova-compute

  7. nova-compute会随机生成一个UUID作为Token

  8. nova-compute将libvirt返回的信息以及配置文件中的信息综合成connect_info返回给nova-api

  9. nova-api会调用nova-consoleauth的authorize_console函数

  10. nova-consoleauth会将instance –> token, token –> connect_info的信息cache起来

  11. nova-api将connect_info中的access url信息返回给浏览器:http://172.24.1.1:6080/vnc_auto.html?token=7efaee3f-eada-4731-a87c-e173cbd25e98&title=helloworld%289169fdb2-5b74-46b1-9803-60d2926bd97c%29

  12. 浏览器会试图打开这个链接

  13. 这个链接会将请求发送给nova-novncproxy

  14. nova-novncproxy调用nova-consoleauth的check_token函数

  15. nova-consoleauth验证了这个token,将这个instance对应的connect_info返回给nova-novncproxy

  16. nova-novncproxy通过connect_info中的host, port等信息,连接compute节点上的VNC Server,从而开始了proxy的工作

 

6. 如果VNC登录不进去,还有一个方法,使用自己的VNC Client,通过compute物理节点的IP地址登陆

qemu-system-x86_64 有参数 -vnc 0.0.0.0:5

 

就可以通过compute node的ip地址进入

 

 

7. 通过ovs-vsctl show和brctl来查看,各个网卡和bridge之间关系是否正确,tunnel之间是否能够通,网卡是否都处于up的状态

 

 

 

8. 如果从虚拟机的虚拟网卡到DHCP Server的网卡一路都是配置正确的,则需要查看br-tun上ovs-ofctl dumpflows查看flows规则,是否对包的改写正确,是否有正确的规则

 

9. 通过VNC登录进去后,就可以通过命令行运行dhclient,来重启连接DHCP Server, 从compute节点上的网卡和bridge,一个个进行tcpdump,看到底哪个网卡或者bridge没有收到包,收到的包里面的VLAN ID等是否正确

 

10. 如果VM能从DHCP Server获得IP,则好事成了一半,接下来换一个有cloud-init的image,看metadata server能够连接成功,能够注入key,也是通过console.log来看

 

11. 如果metadata server不能连接成功,就需要顺着metadata server的整个流程,一个一个模块看,看每个模块的log,端口是否正确,是否收到请求,也可以在VM里面用curl来模拟metadata server的请求

 

 

openstack里的metadata,是提供一个机制给用户,可以设定每一个instance 的参数。比如你想给instance设置某个属性,比如主机名。

 

Instance访问metadata server http://169.254.169.254

 

metadata的一个重要应用,是设置每个instance的ssh公钥。

 

获取metadata的api接口是:

 

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key 

 

这个IP地址,在 openstack 是不存在的。为什么可以获取到metadata呢?

 

这是由于Amazon的原因,最早metadata是亚马逊提出来的,参见:http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

 

后来很多人给亚马逊定制了一些操作系统的镜像,比如 ubuntu, fedora, centos 等等,而且将里面获取 metadta 的api地址也写死了。所以opentack为了兼容,保留了这个地址169.254.169.254。

 

然后通过iptables nat映射到真实的api上:

 

iptables -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 16.158.166.197:8775 

 

nova如何区分到底是哪个虚拟机请求metadata?采取的方法是在HTTP头部识别是哪个虚拟机。

 

 

 

一个虚拟机访问169.254.169.254的流程如下:

 

(1) 虚拟机发出请求

 

  • 虚拟机启动时会访问169.254.169.254

  • 数据包会直接发送到虚拟机的默认网关172.71.71.1

  • 默认网关在network node上,qr-XXXXX

 

(2) namespace中的iptables

 

  • 因为使用了namespace,在network node上每个namespace里都会有相应的iptables规则和网络设备。

  • iptables规则中,会把目的地址169.254.169.254的数据包,重定向到本地端口9697

 

ip netns exec qrouter-5a74908c-712c-485c-aa9f-6c1e8b57e3e1 iptables -t nat -nvL

 

(3) namespace-metadata-proxy

 

启用namespace场景下,对于每一个router,都会创建这样一个进程。该进程监听9697端口,其主要功能:

 

1、向请求头部添加X-Forwarded-For和X-Neutron-Router-ID,分别表示虚拟机的fixedIP和router的ID

2、将请求代理至Unix domain socket(/var/lib/neutron/metadata_proxy)

 

 

(4) Neutron-metadata-agent

 

  • network node上的metadata agent监听/var/lib/neutron/metadata_proxy:

  • 该进程的功能是,根据请求头部的X-Forwarded-For和X-Neutron-Router-ID参数,向Neutron service查询虚拟机ID,然后向Nova Metadata服务发送请求(默认端口8775),消息头:X-Forwarded-For,X-Instance-ID、X-Instance- ID-Signature分别表示虚拟机的fixedIP,虚拟机ID和虚拟机ID的签名。

 

 

12. 如果metadata server能够连接成功,key成功注入,下一步需要从namespace里面看是否能够ping通,能够ssh

 

 

13. 如果namespace里面能够成功,则在network节点上,ping floating ip和ssh,是否能够成功,如果不成功,看br-ex的网卡是否添加正确,是否配置了ip,路由表是否正确,namespace里面floating ip的iptables规则是否添加正确

 

14. 在network节点上能够ssh到floating ip,则需要从其他节点上ssh,如果不成功,可能br-ex的网址配置有问题,很可能是br-ex添加的物理网卡不是混合状态,也可能是路由配置有问题,对于floating ip所在的网段,不指向network节点

 

15. 如果floating ip能够成功,则需要进去VM里面运行apt-get update,如果不可以,看能否ping通openstack里面的gateway(10.0.0.1),然后看能否ping通物理网络环境的gateway(16.158.XXX.1)

 

16. 看DNS Server是否配置正确,是否能够ping通,如果能,apt-get update运行成功

 

欢迎关注微信公众号

 

posted @ 2018-03-09 21:01 popsuper1982 阅读(...) 评论(...) 编辑 收藏