How to understand Cinder components

This article introduces you to Cinder components, the content is very detailed, interested friends can refer to, hope to be helpful to you.

We will explain the various sub-services of Cinder in detail.

Cinder-api

Cinder-api is the portal to the entire Cinder component, and all cinder requests are first processed by nova-api. Cinder-api exposes several HTTP REST API interfaces to the outside world. In keystone, we can query the endponits of cinder-api.

Click the drop-down arrow, and the list shows what cinder-api can do.

Cinder-scheduler

"when creating a Volume, cinder-scheduler selects the most appropriate storage node based on capacity, Volume Type, and other conditions, and then asks it to create a Volume."

There are a lot of this part. We'll discuss it separately next time.

Cinder-volume

Cinder-volume runs on the storage node, and the operation of OpenStack to Volume is finally handed over to cinder-volume. Cinder-volume itself does not manage real storage devices, which are managed by volume provider. Cinder-volume works with volume provider to manage the volume lifecycle.

Support for multiple Volume Provider through Driver architecture

The next question is: there are so many storage products and solutions (volume provider) on the market, how can cinder-volume cooperate with them?

This is the Driver architecture we discussed earlier. Cinder-volume defines a unified interface for these volume provider, and volume provider only needs to implement these interfaces to plug and play in the form of Driver into the OpenStack system. Here is a schematic diagram of the architecture of Cinder Driver:

We can see the Driver that already comes with a lot of volume provider in the OpenStack source code under the / opt/stack/cinder/cinder/volume/drivers/ directory:

Here LVM is the volume provider we use.

Periodically report the status of the storage node to the OpenStack

In the previous cinder-scheduler, CapacityFilter and CapacityWeigher are used, which are filtered by the free capacity of the storage node. So here's the question: how does Cinder know the free capacity of each storage node?

The answer is: cinder-volume reports to Cinder on a regular basis.

From the cinder-volume log / opt/stack/logs/c-vol.log, you can see that every once in a while, cinder-volume reports the resource usage of the current storage node.

Because the storage node is using LVM in our experimental environment, we can see in the log above that the storage node obtains the capacity usage information of LVM through the commands "vgs" and "lvs".

Implement volume lifecycle management

Cinder ultimately manages the life cycle of volume through cinder-volume, including volume's create, extend, attach, snapshot, delete, and so on, which we will discuss in detail later.

So much for sharing about Cinder components. I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.