Getting the core components of OpenStack comb (4) - Cinder articles
Foreword
In Nova project about the article, I mentioned this a Nova-Volume subproject, which is the predecessor of the current OpenStack project in the Cinder.
This article explains the various components immediately prior to the introduction Cinder project (block storage) relevant theoretical knowledge in one of the core components of OpenStack. We were introduced from this:
A brief concept and effect Cinder
Storage concept 1.1
Cinder OpenStack project is provided to the virtual machine instance Nova data items may be achieved by the persistent storage service block, formerly sub Nova-Volume Nova project. Basic knowledge of relevant unclear store may not understand this "block" is what that means. Simple Take, for example, block storage can be understood as our notebook hard drive can be a mechanical hard drive or solid state drive, this we should be familiar Kazakhstan.
So, what then is stored. Store name suggests, is to store data information, such as on the real life of the Treasury, lockers, storage box and so on; also stored as actual examples of these, like, have their own type of way, this article is intended to block about the OpenStack storage theory, classification and storage of way do not specifically described.
The role of 1.2cinder project
In OpenStack, the storage management is one of its three core resources and, therefore, to understand the role of storage needs.
-
It provides data for the virtual machine instance Nova project implemented by persistent storage services;
-
Block storage provides the management infrastructure Volumes to go, and is responsible for its snapshot and types of management;
- cinder by plug-in API interface provides access to the storage backend;
Block storage service is usually mounted in the form of a storage volume to a virtual machine up, provide access to different storage resources through a unified API interface, storage client, without worrying about the underlying storage drive.
II Discussion block storage, storage and file system objects stored
OpenStack cluster memory is usually divided into blocks of storage, storage and file system storage objects. The following briefly the concept of the three.
Storage 2.1
End block storage device is the storage volumes (Volume) iSCSI SAN or the like through the storage protocol and mount a virtual machine partition and format, and then to mount the implementation of local storage file systems.
2.2 file system storage
It is stored in a file system via NFS or CIFS (Samba) and other network file system protocol remote file system is mounted to a storage system in the local implementation.
2.3 Object Storage
In contrast, objects stored on the implementation and use of block and file storage systems are different, the object is a method for providing storage access data stored in a REST API implementation.
OpenStack generally, the memory block is the most used data storage implementation. Then introduce the main components of the project constitutes Cinder.
Third, the main component storage block
This section describes the major components of the project Cinder.
3.1Cinder-fire
Cinder-api WSIG is a type of application service, which is mainly responsible for receiving row block store client API request or order from Horizon, while responsible for requesting the identity authentication client (program implemented by Keystone).
Cinder-api After receiving the client request, according to the scheduling result storage backend Cinder-scheduler, the request will be routed to the corresponding API to run Cinder-volume backend storage and services.
3.2Cinder-scheduler
Cinder-scheduler, and Nova-scheduler function is similar, Cinder-scheduler is Cinder project backend Volumes service scheduler. When Cinder-api receives a client request, Cinder-scheduler service will be responsible for routing API.
The planning strategy configured by the user, Cinder-api request may take the form of each storage node polling Volume RR routes and services running, may be used to implement more sophisticated and FilterScheduler intelligent filtering policy backend storage nodes. In Cinder configuration, FilterScheduler is the default, the backend storage nodes may be implemented scheduling policy based on the custom filter Capacity, Availability Zone, Volume Types, Capabilities or users via FilterScheduler configuration.
3.3Cinder-volume
Cinder Cinder-volume project is really to provide block storage and different storage drive plug-in management services. OpenStack operation Volume, and finally to the cinder-volume it is done.
Cinder-volume service by interacting with AMQP Cinder-scheduler, the rear end of the operations of the respective storage drives its management, real-time performance and capacity parameters passed to Cinder-scheduler, in order to Cinder-scheduler schedules these parameters according to the storage node . Further, Cinder-volume interact with the different backend storage drive by the drive architecture.
3.4Cinder backup
Cinder-backup is a block storage volumes (Volumes) provide backup service to backup Volumes, you need to provide backup storage drive implementation, currently more common backup storage backend provided by Swift. And Cinder-volume similar, Cinder-backup also by Driver (driver) in the form of plug-in architecture of interaction with different back-end storage backup.
3.5MESSAGE QUEUE
Cinder between the different components of internal service project to perform message interaction by Queue. Cinder in communication between the respective service illustrated in Figure 17 through the message queue:
3.6 Database
Cinder have some data need to be stored in the database, the database is generally used is MySQL.
Fourth, the block storage basic structure
Next, to understand how the basic structure of Cinder, as shown below:
We can Cinder service projects linked by understanding the architecture diagram and other services. Users Horizon project a Web visual interface client or command line client Cinder-api interacts authentication service authenticates the user Cinder-api by Keystone passed, then the MQ message queue and Cinder-volume communications, Cinder-volume with a variety of back-end storage drive plug-in management provided by the volume provider, and the relevant information into the database for storage.
These are the interaction between the Cinder project description schema corresponding services and other service projects, a section will be explained below internal cinder each interaction principles and processes through an example.
Fifth, the block storage internal components Works
Assume that the user needs to create a disk space, or a storage volume. So inside the cinder workflow is as follows:
1, the user sends a request to create a new volume to Cinder-api;
2, Cinder request the necessary processes (e.g., response and verification), thus placing the information to a Message Queue to the volume created Cinder-scheduler;
3, Cinder-scheduler algorithm performs a corresponding receiving the information, select a relatively appropriate nodes in the storage node group;
4, then went Cinder-scheduler is stored in a message queue allows the storage node to be selected to create the volume information;
5, Cinder-volume storage node is receiving the information selected, then the volume created by the drive and the corresponding volume provider.
The process may be shown by the following flow chart:
Six, Cinder project summary
For Cinder project, first understand its role in the OpenStack role in providing that kind of service. Also understand the basic architecture and the corresponding workflow. This article describes Cinder generally these, of course, Cinder projects related to the specific use and the introduction of plug-in here is not to continue in-depth, and friends who are interested can check out the relevant information.
Thank you for reading!