【OpenStack】metadata在OpenStack中的使用(一)

声明:

本博客欢迎转发,但请保留原作者信息!

新浪微博:@孔令贤HW

博客地址:http://blog.csdn.net/lynn_kong

内容系本人学习、研究和总结,如有雷同,实属荣幸!


版本:Grizzly master分支 2013.6.17
部署:三节点(controller + network + compute)
网络类型:vlan

之前的一篇blog中碰到了虚拟机访问169.254.169.254的问题,在F版中,会在网络节点上做NAT转换,直接访问nova的metadata服务,但这种方法,在使用namespace时就不生效了,因为namespace支持IP地址重叠,这样nova就无法区分到底是哪个虚拟机请求metadata。

该问题在G版得到解决,blueprint在此。采取的方法是在HTTP头部识别是哪个虚拟机。同时,G版在Quantum中加入了两个服务:namespace metadata proxy和metadata agent。一个虚拟机访问169.254.169.254的流程如下图:
【OpenStack】metadata在OpenStack中的使用(一)_第1张图片

在细讲流程之前,估计很多人并不清楚metadata的作用和由来。不懂的童鞋看这里。


1、虚拟机发出请求

虚拟机启动时会访问169.254.169.254获取一些内容。这个从我之前出错的日志中就可以看出来:
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: http error [404]

在虚拟机内部访问169.254.169.254,看一下都有什么:

ubuntu@ubuntu-test:~$ curl http://169.254.169.254/2009-04-04/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
kernel-id
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
ramdisk-id
那么这些内容是如何获取到的?因为虚拟机内部没有特殊的路由,所以数据包会直接发送到虚拟机的默认网关,而默认网关是在network node上。虚拟机的网卡信息如下:

ubuntu@ubuntu-test:~$ ip -4 address show dev eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 10.1.1.2/24 brd 10.1.1.255 scope global eth0
虚拟机的路由信息:

ubuntu@ubuntu-test:~$  ip route
default via 10.1.1.1 dev eth0  metric 100 
10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.2

2、namespace-metadata-proxy

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

-A quantum-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697
-A quantum-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j ACCEPT
虚拟机默认网关设备信息的地址信息,可以看到虚拟机网关的IP(10.1.1.1):

root@network232:~# ip netns exec qrouter-b147a74b-39bb-4c7a-aed5-19cac4c2df13 ip addr show qr-f7ec0f5c-2e
12: qr-f7ec0f5c-2e:  mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:81:9c:69 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global qr-f7ec0f5c-2e
    inet6 fe80::f816:3eff:fe81:9c69/64 scope link 
       valid_lft forever preferred_lft forever
iptables规则中,会把目的地址169.254.169.254的数据包,重定向到本地端口9697,那么看一下network node上,在该端口的监听进程:

root@network232:~# ip netns exec qrouter-b147a74b-39bb-4c7a-aed5-19cac4c2df13 netstat -nlpt | grep 9697
tcp        0      0 0.0.0.0:9697            0.0.0.0:*               LISTEN      13249/python
进程号13249,看一下这个进程:

root@network232:~# ps -f --pid 13249 | fold -s -w 85 
UID        PID  PPID  C STIME TTY          TIME CMD
root     13249     1  0 16:30 ?        00:00:00 python 
/usr/bin/quantum-ns-metadata-proxy 
--pid_file=/var/lib/quantum/external/pids/b147a74b-39bb-4c7a-aed5-19cac4c2df13.pid 
--router_id=b147a74b-39bb-4c7a-aed5-19cac4c2df13 --state_path=/var/lib/quantum 
--metadata_port=9697 --debug --verbose 
--log-file=quantum-ns-metadata-proxyb147a74b-39bb-4c7a-aed5-19cac4c2df13.log 
--log-dir=/var/log/quantum
可能很多人想知道,这个进程从何而来,解释这个问题,可能要贴点代码:

    def _spawn_metadata_proxy(self, router_info):
        def callback(pid_file):
            proxy_cmd = ['quantum-ns-metadata-proxy',
                         '--pid_file=%s' % pid_file,
                         '--router_id=%s' % router_info.router_id,
                         '--state_path=%s' % self.conf.state_path,
                         '--metadata_port=%s' % self.conf.metadata_port]
            proxy_cmd.extend(config.get_log_args(
                cfg.CONF, 'quantum-ns-metadata-proxy-%s.log' %
                router_info.router_id))
            return proxy_cmd

        pm = external_process.ProcessManager(
            self.conf,
            router_info.router_id,
            self.root_helper,
            router_info.ns_name())
        pm.enable(callback)
可见,启用namespace场景下,对于每一个router,都会创建这样一个进程。该进程监听9697端口,其主要功能:
1、向请求头部添加X-Forwarded-For和X-Quantum-Router-ID,分别表示虚拟机的fixedIP和router的ID
2、将请求代理至Unix domain socket(/var/lib/quantum/metadata_proxy)

3、Quantum Metadata Agent

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

root@network232:~# netstat -lxp | grep metadata
unix  2      [ ACC ]     STREAM     LISTENING     46859    21025/python        /var/lib/quantum/metadata_proxy
root@network232:~# ps -f --pid 21025 | fold -s 
UID        PID  PPID  C STIME TTY          TIME CMD
quantum  21025     1  0 16:31 ?        00:00:00 python 
/usr/bin/quantum-metadata-agent --config-file=/etc/quantum/quantum.conf 
--config-file=/etc/quantum/metadata_agent.ini 
--log-file=/var/log/quantum/metadata-agent.log
该进程的功能是,根据请求头部的X-Forwarded-For和X-Quantum-Router-ID参数,向Quantum service查询虚拟机ID,然后向Nova Metadata服务发送请求(默认端口8775),消息头:X-Forwarded-For,X-Instance-ID、X-Instance-ID-Signature分别表示虚拟机的fixedIP,虚拟机ID和虚拟机ID的签名。

4、Nova Metadata Service

Nova的metadata service是随着nova-api启动的,会同时启动三个服务:ec2, osapi_compute, metadata。虚拟机访问169.254.169.254的返回内容,其实就是metadata服务向nova-conductor查询后,返回给network node的metadata agent,再由metadata agent返回给metadata proxy,然后返回给虚拟机的。

root@controller231:~# netstat -nlpt | grep 8775
tcp        0      0 0.0.0.0:8775            0.0.0.0:*               LISTEN      1714/python     
root@controller231:~# ps -f --pid 1714
UID        PID  PPID  C STIME TTY          TIME CMD
nova      1714     1  0 16:40 ?        00:00:01 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf





你可能感兴趣的:(openstack)