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 

关于第二个题目，显然还必要一层转发，详细内容请看下一末节内容。

（编辑：湖南网）

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