| 以下内容已屏蔽图片优化访问速度 |
|---|
|
1. Security Group全部打开，这是最基本的，但是很多人容易忘记 其实遇到过无数这种场景了，Debug了半天网络问题，各种手段都用上了，最后发现安全组竟然没有打开。 [IMG] 2. 通过界面查看虚拟机的log，也可以在compute节点上查看console.log文件，看看里面是否有DHCP获取IP成功的日志 在界面上可以看控制台日志 [IMG] 在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登录 [IMG] 5. 如果VNC登录不进去，说明VNC配置的有问题，方法一重新配置VNC [IMG] 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=[IMG]//这个url是返回给客户的url，因而里面的IP是外网IP VNC Proxy的运行过程： 一个用户试图从浏览器里面打开连接到虚拟机的VNC Client 浏览器向nova-api发送请求，要求返回访问vnc的url nova-api调用nova-compute的get vnc console方法，要求返回连接VNC的信息 nova-compute调用libvirt的get vnc console函数 libvirt会通过解析虚拟机运行的/etc/libvirt/qemu/instance-0000000c.xml文件来获得VNC Server的信息 libvirt将host, port等信息以json格式返回给nova-compute nova-compute会随机生成一个UUID作为Token nova-compute将libvirt返回的信息以及配置文件中的信息综合成connect_info返回给nova-api nova-api会调用nova-consoleauth的authorize_console函数 nova-consoleauth会将instance –> token, token –> connect_info的信息cache起来 nova-api将connect_info中的access url信息返回给浏览器：[IMG]port等信息，连接compute节点上的VNC Server，从而开始了proxy的工作 6. 如果VNC登录不进去，还有一个方法，使用自己的VNC Client，通过compute物理节点的IP地址登陆 qemu-system-x86_64 有参数 -vnc 0.0.0.0:5 就可以通过compute node的ip地址进入 [IMG] 7. 通过ovs-vsctl show和brctl来查看，各个网卡和bridge之间关系是否正确，tunnel之间是否能够通，网卡是否都处于up的状态 [IMG] 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的请求 [IMG] openstack里的metadata，是提供一个机制给用户，可以设定每一个instance 的参数。比如你想给instance设置某个属性，比如主机名。 Instance访问metadata server [IMG]openstack 是不存在的。为什么可以获取到metadata呢？ 这是由于Amazon的原因，最早metadata是亚马逊提出来的，参见：[IMG]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头部识别是哪个虚拟机。 [IMG] 一个虚拟机访问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 [IMG] (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） [IMG] (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的签名。 [IMG] 12. 如果metadata server能够连接成功，key成功注入，下一步需要从namespace里面看是否能够ping通，能够ssh [IMG] 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运行成功 |