Metadata Service 架构详解 - 天天5分钟玩转 OpenStack（165）

下面是 Metadata Service 的架构图，本节咱们详细讨论各个组件以及它们之间的关系。

nova-api-metadata

nova-api-metadata 是 nova-api 的一个子服务，它是 metadata 的提供者，instance 能够经过 nova-api-metadata 的 REST API 来获取 metadata 信息。

nova-api-metadata 运行在控制节点上，服务端口是 8775。

经过进程 ID 13415 查看该启动程序。

咱们这个环境是 devstack，nova-api-metadata 的程序名称就是 nova-api，nova-api-metadata 与常规的 nova-api 服务是合并在一块儿的。不过在 OpenStack 的其余发行版中可能有单独的 nova-api-metadata 进程存在。

nova.conf 经过参数 enabled_apis 指定是否启用 nova-api-metadata。

osapi_compute 是常规的 nova-api 服务，metadata 就是 nova-api-metadata 服务。

neutron-metadata-agent

nova-api-metadata 在控制节点上，走 OpenStack 内部管理网络，instance 是没法经过 http://controller_ip:8775 直接访问 metadata service 的，由于网络不通。

那怎么办呢？

答案是：借助 neutron-metadata-agent。

neutron-metadata-agent 运行在网络节点上。instance 先将 metadata 请求发给 neutron-metadata-agent，neutron-metadata-agent 再将请求转发到 nova-api-metadata。

这里还有个问题须要解释清楚：instance 如何将请求发送到 neutron-metadata-agent？

实际上 instance 是不能直接与 neutron-metadata-agent 通讯的，由于 neutron-metadata-agent 也是在 OpenStack 内部管理网络上的。不过好在网络节点上有另外两个组件，dhcp agent 和 l3 agent，它们两兄弟与 instance 能够位于同一 OpenStack network 中，这样就引出了下一个组件： neutron-ns-metadata-proxy。

neutron-ns-metadata-proxy

neutron-ns-metadata-proxy 是由 dhcp-agent 或者 l3-agent 建立的，也运行在网络节点。更精确的说法是：运行在网络节点的 namespace 中。

若是由 dhcp-agent 建立，neutron-ns-metadata-proxy 就运行在 dhcp-agent 所在的 namespace 中；若是由 l3-agent 建立，neutron-ns-metadata-proxy 就运行在 neutron router 所在的 namespace 中。“neutron-ns-metadata-proxy” 中间的 ns 就是 namespace 的意思。neutron-ns-metadata-proxy 与 neutron-metadata-agent 经过 unix domain socket 直接相连。

这样整个链路就打通了：

1. instance 经过 neutron network（Project 网络）将 metadata 请求发送到 neutron-ns-metadata-proxy。

2. neutron-ns-metadata-proxy 经过 unix domain socket 将请求发给 neutron-metadata-agent。

3. neutron-metadata-agent 经过内部管理网络将请求发送给 nova-api-metadata。

可能你们对于 neutron-ns-metadata-proxy 还会有些疑虑：既然 dhcp-agent 和 l3-agent 均可以建立和管理 neutron-ns-metadata-proxy，使用的时候该如何选择呢？

简单的说：各有各的使用场景，而且两种方案能够共存。你们不用担忧，后面咱们会经过例子详细讨论。

Metadata Service 的架构已经讨论清楚了，下一节将经过实践加深理解。