Metadata Service Architecture-5 minutes a day to play OpenStack (165)

Here is the architecture diagram of the Metadata Service, which we discuss in detail about the individual components and their relationships.

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274089063731.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921527761066434.jpg "style=" border:0px;float:none; "/>

Nova-api-metadata

Nova-api-metadata is a sub-service of NOVA-API, which is the provider of metadata, and instance can get nova-api-metadata information through metadata's REST API.

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

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274089056571.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921528371099315.jpg "style=" border:0px;float:none; "/>

View the startup program through the process ID 13415 .

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274117025052.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921528587047536.jpg "style=" border:0px;float:none;/>

Our environment is Devstack,nova-api-metadata's program name is  nova-api , Nova-api-metadata is merged with the regular NOVA-API service. However, there may be separate  nova-api-metadata   Process exists.

nova.conf through parameters  enabled_apis   Specifies whether to enable Nova-api-metadata.

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274600065994.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921529232083927.jpg "style=" border:0px;float:none; "/>

Osapi_compute is a regular NOVA-API service,metadata is the Nova-api-metadata service.

Neutron-metadata-agent

Nova-api-metadata on the control node, go to the OpenStack internal management network, instance is unable to directly access the metadata service through http://controller_ip:8775, because the network does not pass.

What about that?

The answer is: with Neutron-metadata-agent.

The neutron-metadata-agent is running on a network node. Instance first sends the metadata request to neutron-metadata-agent,neutron-metadata-agent and forwards the request to nova-api-metadata.

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274516033316.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921529412004957.jpg "style=" border:0px;float:none; "/>

Here's another question that needs to be clarified: how instance send requests to neutron-metadata-agent?

In fact, instance is not able to communicate directly with Neutron-metadata-agent, because Neutron-metadata-agent is also on the OpenStack internal management network. Fortunately, however, there are two other components on the network node, the DHCP agent and the L3 agent, whose two brothers and instance can be located 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. More precisely, it runs in the namespace of the network node.

If created by Dhcp-agent, Neutron-ns-metadata-proxy runs in the namespace where Dhcp-agent is located, and if created by L3-agent, The Neutron-ns-metadata-proxy is running in the namespace where neutron router is located. "Neutron-ns-metadata-proxy" in the middle of the  ns   is The meaning of namespace. Neutron-ns-metadata-proxy and Neutron-metadata-agent are connected directly through the UNIX domain socket.

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921274692006919.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921529599058676.jpg "style=" border:0px;float:none;/>

This way the entire link is opened:

1. Instance sends metadata requests to neutron-ns-metadata-proxy through the neutron Network (Project networks).

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

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

There may be some doubts about Neutron-ns-metadata-proxy: since both Dhcp-agent and l3-agent can create and manage neutron-ns-metadata-proxy, how do you choose to use it?

Simply put: Each has its own usage scenarios, and the two schemes can coexist. Let's not worry, we'll discuss it in detail in the following example.

The architecture of the Metadata Service has been discussed, and the next section will deepen understanding through practice.

650) this.width=650; "Title=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170314-1489480541786069813.png "src=" http://7xo6kd.com1.z0.glb.clouddn.com/ Upload-ueditor-image-20170319-1489921529840054756.jpg "style=" border:0px;margin:0px;padding:0px;float:none; Height:auto; "/>

Metadata Service Architecture-5 minutes a day to play OpenStack (165)