下面是 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 的架构已经讨论清楚了，下一节将通过实践加深理解。

本文转自CloudMan6 51CTO博客，原文链接:http://blog.51cto.com/cloudman/1908277