OpenStack虚拟机如何获取metadata

我们发现，169.254.169.254其实是配在网卡tap1332271e-0d的一个虚拟IP。虚拟机能够访问169.254.169.254这个地址也就不足为奇了。需要注意的是，本文的metadata转发配置是通过dhcp-agent实现的，如果是l3-agent，则169.254.169.254是通过iptables转发。

我们能够访问curl http://169.254.169.254，说明这个地址肯定开放了80端口:

# netstat -lnpt 
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      11334/haproxy 
tcp        0      0 10.0.0.66:53            0.0.0.0:*               LISTEN      11331/dnsmasq 
tcp        0      0 169.254.169.254:53      0.0.0.0:*               LISTEN      11331/dnsmasq 
tcp6       0      0 fe80::f816:3eff:feb3:53 :::*                    LISTEN      11331/dnsmasq 

从输出中看，所在的环境除了开启了DHCP服务(53端口)，确实监听了80端口，进程pid为11334/haproxy。

我们看到haproxy这个进程就可以猜测是负责请求的代理与转发，即OpenStack虚拟机首先会把请求转发到DHCP所在namespace的haproxy监听端口80。

问题又来了，DHCP所在的namespace网络仍然和Nova Metadata是不通的，那haproxy如何转发请求到Nova Metadata服务呢，我们下一节介绍。

3.3 Metadata请求第二次转发

前面我们介绍了OpenStack虚拟机访问http://169.254.169.254会被转发到DHCP所在namespace的haproxy监听的80端口中。但是，namespace中仍然无法访问Nova Metadata服务。

为了研究解决办法，我们首先看下这个haproxy进程信息:

cat /proc/11334/cmdline | tr '' ' ' 
haproxy -f /opt/stack/data/neutron/ns-metadata-proxy/2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a.conf 

其中2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a.conf配置文件部分内容如下:

listen listener 
    bind 0.0.0.0:80 
    server metadata /opt/stack/data/neutron/metadata_proxy 
    http-request add-header X-Neutron-Network-ID 2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a 

我们发现haproxy绑定的端口为80，后端地址为一个文件/opt/stack/data/neutron/metadata_proxy。后端不是一个IP/TCP地址，那必然是一个UNIX Socket文件:

# ll /opt/stack/data/neutron/metadata_proxy 
srw-r--r-- 1 stack stack 0 Jul  1 13:30 /opt/stack/data/neutron/metadata_proxy 

因此我们得出结论，haproxy进程会把OpenStack虚拟机Metadata请求转发到本地的一个socket文件中。

UNIX Domain Socket是在socket架构上发展起来的用于同一台主机的进程间通讯（IPC），它不需要经过网络协议栈实现将应用层数据从一个进程拷贝到另一个进程，有点类似于Unix管道(pipeline)。

问题又来了:

• 我们从haproxy配置看，监听的地址是0.0.0.0:80，那如果有多个网络同时都监听80端口岂不是会出现端口冲突吗？
• socket只能用于同一主机的进程间通信，如果Nova Metadata服务与Neutron dhcp-agent不在同一个主机，则显然还是无法通信。

第一个问题其实前面已经解决了，haproxy是在虚拟机所在网络的DHCP namespace中启动的，我们可以验证:

# lsof -i :80 
COMMAND   PID  USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME 
haproxy 11334 stack    4u  IPv4 65729753      0t0  TCP *:http (LISTEN) 
# ip netns identify 11334 
qdhcp-2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a 

关于第二个问题，显然还需要一层转发，具体内容请看下一小节内容。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!