Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to understand the Metadata Service architecture. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Nova-api-metadata

Nova-api-metadata is a sub-service of nova-api. It is the provider of metadata. Instance can obtain metadata information through nova-api-metadata 's REST API.

Nova-api-metadata runs on the control node and the service port is 8775.

View the launcher through the process ID 13415.

Our environment is the program name of devstack,nova-api-metadata, that is, nova-api,nova-api-metadata is merged with regular nova-api services. However, there may be separate nova-api-metadata processes in other distributions of OpenStack.

Nova.conf specifies whether nova-api-metadata is enabled by the parameter enabled_apis.

Osapi_compute is a regular nova-api service, and metadata is a nova-api-metadata service.

Neutron-metadata-agent

Nova-api-metadata in the control node, through the OpenStack internal management network, instance can not directly access metadata service through http://controller_ip:8775, because the network is blocked.

What are we going to do?

The answer is: with neutron-metadata-agent.

Neutron-metadata-agent runs on network nodes. Instance first sends the metadata request to neutron-metadata-agent,neutron-metadata-agent and then forwards the request to nova-api-metadata.

Here's another question to explain: how does instance send requests to neutron-metadata-agent?

In fact, instance cannot communicate directly with neutron-metadata-agent, because neutron-metadata-agent is also on the internal management network of OpenStack. Fortunately, there are two other components on the network node, dhcp agent and L3 agent, and their brothers and instance can be in the same OpenStack network, which leads to the next component: neutron-ns-metadata-proxy.

Neutron-ns-metadata-proxy

Neutron-ns-metadata-proxy is created by dhcp-agent or l3-agent and also runs on network nodes. To put it more precisely: run in the namespace of the network node.

If created by dhcp-agent, neutron-ns-metadata-proxy runs in the same namespace as dhcp-agent; if created by l3-agent, neutron-ns-metadata-proxy runs in the same namespace as neutron router. The ns in the middle of "neutron-ns-metadata-proxy" means namespace. Neutron-ns-metadata-proxy is directly connected to neutron-metadata-agent through unix domain socket.

In this way, the whole link is open:

1. Instance sends the metadata request to neutron-ns-metadata-proxy through neutron network (Project network).

2. Neutron-ns-metadata-proxy sends the request to neutron-metadata-agent through unix domain socket.

3. Neutron-metadata-agent sends the request to nova-api-metadata through the internal management network.

You may also have some doubts about neutron-ns-metadata-proxy: since both dhcp-agent and l3-agent can create and manage neutron-ns-metadata-proxy, how to choose when using it?

To put it simply: each has its own usage scenario, and the two schemes can coexist.

The above is the editor for you to share how to understand the Metadata Service architecture, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.