The host field becomes more complex.

The host attribute of the volume in openstack is discussed.

Under the impression, the host value of the community H version for volume represents the host configuration item corresponding to the cinder-volume service. The default value is the hostname of GuestOS. For example, if cinder-volume on board A Creates A volume V, the host of V is. At the same time, the host value is used as the topic forwarded by rpc, that is, the cinder-scheduler component has different host units for differentiation, and the scheduling determines the specific host, and then sends the message. This method is similar to the nova module. The nova-schedute is also distinguished by the host where the nova-compute is located. However, cinder also supports the host field to carry the backend storage name, that is, "[email protected]". See the following code:

If CONF. enabled_backends: for backend in CONF. enabled_backends: host = "% [email protected] % s" % (CONF. host, backend) server = service. service. create (host = host, service_name = backend) launcher. launch_server (server)

That is, a host can be connected to multiple different storage backends. The host names are "[email protected]" and [email protected, then, start an independent cinder-volume to match. I think nova can also play like this. In theory, a single host can also have multiple hypervisors, and multiple nova-compute instances can be run at the same time, this is also the meaning of the node field in the compute_nodes table.

There is A very serious problem here, because rpc message forwarding relies on the host field of the volume. If many volumes have been created on board A, unfortunately, board A is down and cannot be recovered for A long time! In this way, the entire data center is not dumpfounded. All the volumes originally created by A cannot be attached or deleted. To avoid such a terrible situation, you can modify it so that multiple cinder-volume services can connect to the same backend storage and unify the host field. In this way, even if some of the boards are down, other normal boards can also process rpc messages sent by cinder-api. It is equivalent to converting the communication model between cinder-schedume and cinder-volume into a communication model similar to cinder-api to cinder-scheduler, called load balancing.

Of course, this change relies on the state Independence of cinder-volume, which also brings some other incompatibility issues, but it should not be a problem, the sum is also lighter than the above problems. I don't know how the community looks at this issue.

Let's take a look at Juno, which is also the startup script of cinder-volume:

If CONF. enabled_backends: for backend in CONF. enabled_backends: CONF. register_opts ([host_opt], group = backend) backend_host = getattr (CONF, backend ). host = "% [email protected] % s" % (backend_host or CONF. host, backend) server = service. service. create (host = host, service_name = backend) launcher. launch_service (server)

A little changed: version J supports setting host values for specific backend domains rather than uniform values in configuration items. This is a little more flexible than version H.

For example, I can play like this. On the LVM board at the backend, cinder. conf is configured as follows:

Enabled_backends = lvm [lvm] host = lirenke

Then when cinder-volume is up, the result is as follows:

This is as expected. Then I try to create a volume. After the volume is successfully created, the host should also be [email protected] According to the H version. However:

The strange thing happened. Why is "# LVM_iSCSI" added later. What fields does rpc use topic? I don't know, so I can only look at the J version source code.

Originally, the J version introduced the concept of pool, that is, the storage pool. A cinder-volume domain can have multiple pools, that is, the relationship between a backend and a pool is one-to-many. Resource reporting must be reported by pool rather than the original host. Further, the host_state object unit stored in cinder-scheduler is changed to the pool.

The complete host name (the host attribute of the volume object) is: [email protected] # pool

View the rpc topic that cinder-schedted sends to cinder-volume. The backend level is used, that is, the string before the '#', such as "[email protected]". For the pool name selection, use the volume_backend_name configuration item in the LVM code. The default value is LVM_iSCSI. If a driver does not have a default value, _ pool is used as the name.

In the Scheduling module, use the following methods:

Hosts = self. host_manager.get_all_host_states (elevated)

The returned object is not the previous HostState object, but the PoolState object. The host attribute of the PoolState object has been specially processed, the actual host value is combined with the pool name, so the host attribute value of the volume object refreshed to the database is changed to host # pool_name. This is why the volume host attribute I created is "[email protected] # LVM_iSCSI ".

Note that in the database query API method such as volume_get_all_by_host, the initial hostname is passed in, and fuzzy processing is performed during implementation, that is, the lirenke is passed in, [email protected] **, [email protected] ** # ** will also be detected, without affecting the normal logic.

The three concepts of host, backend, and pool are confusing, and flexibility is indeed increased. But does not this solve the above serious HA problem? It seems that the solution can be solved. The same principle can allow two cinder-volume to take the same host, the same backend, and different pools, but this is actually strongly related to the implementation of the backend storage driver, the implementation of the framework gives the driver some flexibility and does not allow all backend configurations.

First, we have discussed this. The flexibility of its hiding needs further understanding and practice. In short, the host field becomes more complex.

The host field becomes more complex.