The role of OpenStack's metadata

Non-management is the private cloud and public cloud, especially the public cloud, when the virtual machine is created, the user needs to configure the virtual machines, such as: Host name (hostname), key, service, etc., in OpenStack, these configuration information is divided into two categories: metadata and user data. Metadata mainly includes some common properties of the virtual machine itself, such as hostname, network configuration information, SSH login key, etc., the main form is the key value pair. User data mainly includes some commands, scripts, and so on. User data is delivered through a file and supports a variety of file formats, including gzip compressed files, shell scripts, cloud-init profiles, and more. Although metadata and user data are not the same, the mechanism by which OpenStack provides these two kinds of information to a virtual machine is consistent, except that the virtual machines are treated differently when they get the information. So the following unification is described by Matadata.

A. User data mechanism:

1) in the custom Script source drop-down list, you can choose the direct input or executable script file, this example is the image of Ubuntu when loading as the operating system to the Ubuntu Default user's password to Ubuntu, can be used as no way to use SSH on the key to connect this virtual host, Using console to manipulate virtual host scenarios

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/75/8E/wKioL1Y8QdPQLVrQAAEv8tj5v0Q147.jpg "title=" The script modifies the password. jpg "alt=" wkiol1y8qdpqlvrqaaev8tj5v0q147.jpg "/>

2) such as CentOS or Redhat, you can directly use the root user, set the password:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/75/8F/wKioL1Y8RguA_N5RAAFXMfn5H_I045.jpg "title=" Create the virtual host root password. jpg "alt=" wkiol1y8rgua_n5raafxmfn5h_i045.jpg "/>

Two. Metadata mechanism

In OpenStack, virtual machines get Metadata information in two ways: Config Drive and Metadata RESTful service. Below we only introduce and analysis to metadata.

Metadata RESTful Services

OpenStack provides a restful interface that allows virtual machines to obtain metadata information through the REST API. The component that provides the service is: Nova-api-metadata. Of course, to complete the request from the virtual machine to the network node and corresponding, only the Nova-api-metadata service is not enough, in addition to work together to complete the task of the service also: Neutron-metadata-agent and Neutron-ns-metadata-proxy. Below we will analyze how they work together as virtual machines to provide metadata services.

Neutron-metadata-agent

Neutron-metadata-agent runs on the network node and is responsible for forwarding the received metadata request to nova-api-metadata. Neutron-metadata-agent gets the virtual machine and tenant ID, which is added to the HTTP header of the request. Nova-api-metadata will get metadata based on this information.

Nova-api-metadata

Nova-api-metadata initiates a restful service that handles the REST API requests sent by the virtual machine. Take the appropriate information from the HTTP header of the request, obtain the virtual machine ID, then read the virtual machine's metadata information from the database and return the result.

neutron-ns-metadata-proxy

Neutron-ns-metadata-proxy also runs on network nodes. In order to solve the problem of network segment and tenant virtual segment duplication, OpenStack introduces the network namespace. Both the routing and DHCP servers in the Neutron are in their own separate namespaces. Because the virtual machine acquires metadata requests that are routed and DHCP servers as network exits, it is necessary to connect the requests across the network namespace by neutron-ns-metadata-proxy the different network namespaces. Neutron-ns-metadata-proxy uses HTTP technology on top of UNIX domain sockets to implement HTTP request forwarding between different network namespaces. and add the ' X-neutron-router-id ' and ' x-neutron-network-id ' information in the request header so that the neutron-metadata-agent can identify the virtual machine that sent the request and get the ID of the virtual machine.

Figure 3.Metadata Request sending process

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/75/91/wKiom1Y8R5GxEJqyAABvR-GP4eo803.jpg "title=" Metadata.png "alt=" Wkiom1y8r5gxejqyaabvr-gp4eo803.jpg "/>

As shown in 3, the approximate process for the virtual machine to get metadata is that the request is sent to Neutron-ns-metadata-proxy, where Router-id and Network-id are added to the request, and then the request is made via the UNIX Domian socket was forwarded to Neutron-metadata-agent, based on Router-id, Network-id and IP in the request, to obtain the port information, to get Instance-id and Tenant-id join request, the final request was forwarded to nova- Api-metadata, which uses Instance-id and Tenant-id to obtain the metadata of the virtual machine, returns the corresponding.

Above we analyzed the process of forwarding requests between services, then there is only one problem, the whole route to get metadata is smooth: How does the virtual machine send the request to Neutron-ns-metadata-proxy?

We will first analyze the requests sent by the virtual machines. Since metadata was first proposed by Amazon, the metadata service was established at the address of 169.254.169.254:80,openstack. So the virtual opportunity sends a MEDTADATA request to 169.254.169.254:80. So how is this request sent out of the virtual machine? Currently Neutron has two ways to solve this problem: sending requests through router and sending requests over DHCP.

Sending requests via router

If the virtual machine is located subnet connected to the router, then the message sent to 169.254.169.254 will be sent to router. As shown in 4, Neutron forwards the message to port 9697 by adding iptables rules in the router's network namespace, and Neutron-ns-metadata-proxy listens on the port, so the message is Neutron-ns-metada Ta-proxy access to the above-mentioned post-processing and forwarding processes.

Figure 4.router Iptables rules for the network namespace

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/75/91/wKiom1Y8SNTyPMxTAAEmEMw0484828.jpg "style=" float: none; "title=" Ip_netns.png "alt=" Wkiom1y8sntypmxtaaememw0484828.jpg "/>

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/75/8F/wKioL1Y8StGgMVdzAAEQhfe1yz4197.jpg "title=" router _proxy.png "alt=" Wkiol1y8stggmvdzaaeqhfe1yz4197.jpg "/>

Figure 5: Monitoring the Neutron-ns-metadata-proxy service on port 9697

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/75/8F/wKioL1Y8S7yCJ5FFAAc6TvP4_N8465.jpg "title=" Neutron_ns_metadata_proxy.png "alt=" Wkiol1y8s7ycj5ffaac6tvp4_n8465.jpg "/>

Circle Red Circle is in a separate network namespace view, below you can see there are three network namespaces, the same as the Qrouter in Figure 4

Sending requests through DHCP

If the virtual machine is located on a subnet that is not connected to any router, then the request cannot be forwarded through router. At this point Neutron forwards the metadata request through the DHCP server. The DHCP service sets the static route for the virtual machine through the DHCP protocol option 121来. As shown in Figure 6, the 10.0.0.3 is the IP address of the DHCP server. By looking at the static route table of the virtual machine, we can find that the message sent to 169.254.169.254 is sent to 10.0.0.3, which is the DHCP server.

Figure 6: Static routing table in a virtual machine

650) this.width=650; static route table "Src=" Http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_ in "alt=" virtual machine Openstackmeta/index3988.png "width=" 550 "style=" Margin:0px;padding:0px;border:0px;font-size:13px;vertical-align: Baseline;font-family:arial, Sans-serif;line-height:15px;white-space:normal;background-color:rgb (255,255,255); "/ >

In addition to view the DHCP server IP configuration information, found that the DHCP server is configured with two IP, one of which is 169.254.169.254. Similar to router, Neutron initiates a neutron-ns-metadata-proxy service that listens on port 80 in the DHCP network namespace, thus entering the process of processing and forwarding requests.

Figure 7.DHCP IP configuration of the server

650) this.width=650; "alt=" Figure 7:dhcp the IP configuration of the server "src=" Http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_ Openstackmeta/index4150.png "width=" 554 "style=" Margin:0px;padding:0px;border:0px;font-size:13px;vertical-align: Baseline;font-family:arial, Sans-serif;line-height:15px;white-space:normal;background-color:rgb (255,255,255); "/ >

Figure 8: Check if the metadata service is normal

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/75/8F/wKioL1Y8TSzhX_NWAACzXFnLlQ4798.jpg "title=" Curl.png "alt=" wkiol1y8tszhx_nwaaczxfnllq4798.jpg "/> This diagram indicates normal

summary: To ensure that the virtual host and metadata services to communicate properly, First mirror needs to install Cloud-init, of course, each service is also normal, often appear l do not connect metadata service, usually the port of the virtual host is not normal, you can use the reconstruction to troubleshoot, the hostname of the METADATA-DHCP is defined when the virtual host is created, There must be a key in force to ensure the existence of Cloud-init,

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/75/92/wKiom1Y8TxGClN8IAAGtJtJIZr0677.jpg "title=" Host name. jpg "alt=" wkiom1y8txgcln8iaagtjtjizr0677.jpg "/>

Reference URL: http://www.ibm.com/developerworks/cn/cloud/library/1509_liukg_openstackmeta/index.html

This article is from the "Lucky Dog" blog, make sure to keep this source http://703356.blog.51cto.com/693356/1710354

The role of OpenStack metadata