Table of Contents
Now in continuation of our previous chapter on “Understanding OpenStack Networking Neutron Components And It’s concepts“, today we are going to discuss the new component of OpenStack which is “Block Storage (Cinder)”.
So before going into details, let’s first discuss what exactly is the Block storage (Cinder)?
A Block storage service for OpenStack is known as Cinder. It was developed for providing the resources like storage to the customer that utilizes the Compute (Nova) Project of OpenStack. For utilizing these resources either a Logical Volume Manager i.e. LVM or plugin drivers of storage are used.
In short, we can say that Cinder virtually manages the devices of block storage and also allows the customers to use API for requesting and using storage resources even if they don’t have any understanding of how their storage is implemented or how their storage is installed and also on which type of devices.
Cinder also virtually manages the Ironic bare metal hosts or containers or stuff like that. Cinder has some targets or Cinder wants to achieve some targets like:
Use of Cinder for the customers:
You can use Cinder for creating and managing the volumes with the help of Horizon UI, or using UI or using some command line tools like a python-cinder client or by using the REST API, as a customer.
You can use all the aspects of Cinder that are revealed through REST API. These aspects can be used for building more complex logic or for building automatization with the help of Cinder. This can be utilized immediately or through different Software Development Kits which stands for SDKs. You can use resources like Cinder API or Cinder micro version history for directly utilizing the Cinder API.
Now we are going to discuss how to install and manage the Cinder services:
You can configure Cinder independently with the help of auth-strategy = noauth configuration setting. But most of the times you may require to install minimum keystone identity service or some different OpenStack services.
We will discuss the installation of Cinder in the next blog.
For administrating the OpenStack Block storage cinder service, it is useful to grasp the number of concepts. At the time of configuring the Block storage Cinder service in OpenStack, it is important to make some decisions. The majority of choices conclude into two choices that are either: 1. Single node or 2. Multi-node installations.
We will discuss administrating Cinder in our next blog.
As discussed earlier, OpenStack Block Storage Cinder offers open source standards and it is developed for creating and managing services which offer constant storage of resources to virtual applications.
The OpenStack Block storage project has given a tag name called Cinder. The OpenStack Block Storage Cinder furnishes and handles Cinder volumes i.e. as block devices. Cinder also offers collation API i.e. Application Programming Interface for allowing the end users to demand and utilize the storage resources even if they don’t have any knowledge about its category or environment.
Under the normal circumstances, the block devices known as cinder-volume offers constant storage resources to the instances i.e. to the software component of a VM and a standalone instance of the operating system which is known as a guest virtual machine, which is handled by Compute software of OpenStack. You can also use Cinder as a stand-alone OpenStack service i.e. software-defined storage.
The OpenStack Block Storage Cinder enables the organizations which install it for making available the list of storage devices which are block-based and they have different features. For example, there can be a block storage volume which may offer high-performance alternatives for the data storage or there can be another block storage volume which may offer low-performance storage of the backup.
Cinder emphasizes the normal storage capacities like managing snapshot, replication and stuff like that. Despite that, as the OpenStack is an abstracting layer for the resource management, an end user may not be able to access the special aspects and functions of a specific block storage device or the system except the dealer offers these capacities via specific drivers.
Various storage devices like hard disks or the SSD’s can be found within the Cinder server nodes or they can be connected directly to the Cinder server nodes or they can also be situated inside the third party external storage devices. The Cinders’ plugin architecture can be used by the third party vendors for performing the required synchronization work for developing the drivers. The hypervisors are located at the back end path from the external storage devices to the OpenStack Compute (Nova) nodes can be either iSCSI or the NFS which stands for Network File System or the Fibre channel.
Above diagram represents the relationship between the Block Storage Cinder API, the Block Storage Cinder scheduler, Block Storage Cinder volume services and Block Storage Cinder Backup.
At first, the Block storage Cinder was called nova-volume and at that time it was a part of the OpenStack Compute project and Nova is its code word. The OpenStack Folsom released the OpenStack Block Storage project in the autumn of 2012.
The OpenStack Block Storage project team constantly manages the storage resources capacities, drivers and fixes the bugs which are developed for improving the performance, scalability, usability of the OpenStack Block Storage Cinder software service. The OpenStack Block Storage publishes important updates twice a year simultaneously with the other teams of the OpenStack project.
For serving as a back end for the OpenStack Block storage Cinder there are higher than 100 drivers which are available for authorizing the hardware devices and software devices, and public cloud storage. The catalog contains backup drivers, fiber channel zone manager drivers, and volume drivers.
The main Cinder driver is RBD i.e. Ceph RADOS Block Device as per the yearly survey by the OpenStack Foundation. There are other drivers like logical volume manager i.e. LVM for the Linux, Dell EMC, and SolidFire, etc.
For enabling drivers, the OpenStack Block Storage project team requires testing for becoming the part of the Cinder source code base. If the specific dealers are unable to suit the testing as well as reporting requirements then the OpenStack Block Storage project team signals the drivers as invalid. The team then eliminates the invalid drivers from the further Cinder release, if the dealer is unable to obey in spite of the warning.
Also read:-
As a web designer and web developer your experience must have reached to new height, right? Further, you need to…
In today's digital landscape, timing is everything. Whether you're a social media manager, business owner, or content creator, the success…
Are you a website owner? Maintaining the website is the prime concern for any website owner. Yes, it’s equally important…
If you’ve planned to launch a WordPress website, you might get a question, “How do I log in to WordPress?”…
As the demand for virtual private servers (VPS) continues to grow, businesses and individuals are faced with a crucial decision:…
View Comments