OpenStack Metadata Service分析

一、为何Metadata Service

OpenStack Metadata Service 提供 instance 的配置信息（这些信息被统称为 metadata）。instance 启动时向 Metadata Service 请求并得到本身的 metadata，instance 的 cloud-init根据 metadata 完成个性化配置工做。

二、Metadata Service架构

nova-api-metadata

nova-api-metadata是nova-api的子服务，它是metadata的实际提供者，虚拟机的启动时，能够选择经过nova-api-metadata的REST API来获取metadata信息
nova-api-metadata服务运行在控制节点上，服务端口8775(能够经过nova的配置修改)

开启metadata服务

nova-api-metadata与nova-api服务是合并在一块儿的，能够经过nova.conf的enabled_apis配置来指定是否启用nova-api-metadata

neutron-metadata-agent

nova-api-metadata走管理网络，虚拟机走业务网络，因此虚拟机没法直接和nova-api-metadata进行通讯，在这个时候就须要借助到运行在网络节点上的neutron-metadata-agent服务。

在网络节点上运行两个组件 l3 agent和dhcp agent，他们会建立一个haproxy进程，运行在各自的namespace中，用来接收虚拟机发送的metadata请求，并将该请求经过Unix Domain Socket的方式转发给neutron-metadata-agent服务，再由neutron-metadata-agent转发给nova-api-metadata。

整个流程能够总结为：
a、instance将metadata请求发送给router或者dhcp agent建立的haproxy进程
b、haproxy进程经过Unix Domian Socket将请求发送给neutron-metadata-agent
c、neutron-metadata经过内部管理网络将请求发送给nova-api-metadata服务

三、L3 agent or DHCP agent

上述描述中提到，L3 agent和dhcp agent都可以建立haproxy进程，进而实现metadata请求的转发，那么两种方案该如何选择呢？

事实上，二者各有各的应用场景，甚至两种方案能够并存，下文将详细分析二者的区别。
说在前面，l3-agent 和 dhcp-agent 访问 metadata 的实现方法是不一样的。

对于 169.254.169.254：
a、l3-agent 用 iptables 规则来转发。
b、dhcp-agent 则是将此 IP 配置到本身的 interface 上。

四、L3 agent实现分析

建立一个网络test1，启用dhcp，暂时不链接到router，而后启动一个instance，而后观察instance的启动日志：

从上面的启动log中，咱们能够发现，intance从dhcp获取到ip地址以后，向169.254.169.254发送了request请求，可是20次均失败
那么169.254.169.254究竟是什么？

事实上，这个ip地址就是metadata service的ip地址，instance在启动的时候会向它发送metadata的请求。

如今咱们发现，instance请求是失败的，这个是为何呢？

上文提到，OpenStack经过L3 agent或者dhcp agent建立haproxy进程，进而实现metadata的转发，咱们首先检查下网络节点上的haproxy进程。

发现并无haproxy进程运行，这个也就解释了，为何instance会请求失败。可是究竟是哪里出了问题？

根本缘由是：默认状况下，haproxy进程由L3 agent来建立（dhcp agent则是关闭状态），因为当前test1网络并无挂载router上，因此没有建立haproxy进程。

建立router，并将test1挂载router上以后。咱们发现haproxy进程已经在网络节点启动。

重启instance test1，看会发生什么变化。

根据instance日志显示，虚拟机已经成功从169.254.169.254获取到了metadata。
这个过程当中到底发生了什么？

a、instance在启动以后，会向168.254.169.254的80端口发起metadata请求，根据
instance的路由能够发现，该请求会从instance的eth0发出，送往路由器上的qr-设备。

b、metadata请求到达路由，进入PREROUTING链，将目的地址为169.254.169.254，进入qr-口，目的port是80的请求，重定向到9697。

c、为何是9697？
由于router建立的haproxy进程正是监听在9697端口上

d、在后面就简单了：haproxy进程将请求经过Unix Domain Socket转发给neutron-metadata-agent，后者再经过管理网关转发给nova-api-metadata。

五、DHCP agent实现分析

OpenStack默认经过L3 agent管理metadata的实现，进而和nova-api-metadata通讯，可是并非全部的环境都有L3 agent，好比直接使用物理router的场景，这样场景如何实现metadata呢？

答案就是DHCP agent

a、打开dhcp agent的metadata功能
vim /etc/neutron/dhcp_agent.ini

重启dchp agent服务

b、检查网络节点上的haproxy进程状况，会发现开启dhcp功能的网络，会建立一个对应的haproxy进程，并将169.254.169.254配置在对应的dhcp port上。

c、重启instance，instance会向169.254.169.254的80端口发送metadata请求，根据instance内部路由，请求会到达dhcp_port端口上。

c、metadata请求到达dhcp的namespace，会被haproxy进程监听到（haproxy进程在dhcp namespace中监听80端口）

d、后面流程和L3 agent彻底相同：haproxy进程将请求经过Unix Domain Socket转发给neutron-metadata-agent，后者再经过管理网关转发给nova-api-metadata。

六、Instance 怎么得到本身的 Metadata

要从 nova-api-metadata 得到 metadata，须要指定 instance 的 id
而instance在启动的时候，是没法知道本身的id的，因此http请求中不会包含id，
instance id是neutron-metadata-agent添加进去的。对于L3 agent和DHCP agent
两种方案上实现又略有不一样，下文会针对二者进行说明。

获取metadata流程以下：
instance -> haproxy-> neutron-metadata-agent -> nova-api-metadata

L3 agent
a、haproxy进程接受到metadata请求，在转发给neutron-metadata-agent以前，会将ip和router id添加到http的head中。
b、neutron-metadata-agent接受到请求后，会查询instance的id，而后将instance id添加到http的head中，而后转发给nova-api-metadata。
c、nova-api-metadata响应请求到指定的instance。

DHCP agent
a、haproxy进程接受到metadata请求，在转发给neutron-metadata-agent以前，会将ip和network id添加到http的head中。
b、neutron-metadata-agent接受到请求后，会查询instance的id，而后将instance id添加到http的head中，而后转发给nova-api-metadata。
c、nova-api-metadata响应请求到指定的instance。

这样，无论 instance 将请求发给 l3-agent 仍是 dhcp-agent，nova-api-metadata 最终都能获知 instance 的 id，进而返回正确的 metadata。