Information about OpenStack Image (Glance) component and also how to manage images

In continuation to our previous blogs on Components of OpenStack today we are going to learn about next OpenStack Component which is: Image (glance) and we are also going to learn about managing the images in the OpenStack.

So let’s start with Image (Glance):-

The OpenStack Image (Glance) is an image service scheme which offers services like finding, listing, recovering images related to disk and server for users which can upload as well as find data resources which can be used with extra services. It includes images as well as definitions of metadata.

It is a central warehouse for all the images which are virtual. The OpenStack Image (Glance) component uses RESTful API which permits questioning of virtual machine image metadata and also the recovering of real images.

Users can save these Virtual Machine images obtained via Glance in different types of locations such as starting from simple file systems to the OpenStack Swift Project which is an example of object storage systems.

For introducing new instance the images present in the Glance are stored as “Templates”. The Image (Glance) has been designed as a standalone project which is required for organizing huge sets of VM images. It also offers consecutive solutions for the management of cloud disk images. Image (Glance) also takes shots of uninterrupted instances required for taking the backup of virtual machines along with their different states.

Following are the components of the Image (glance):

• glance-API: – It receives API calls for finding, recovering and storing the images.
• glance-registry: – The storing, processing and recovering of metadata information related to images are done by this component.
• database: – The image metadata is stored by this component.
• storage repository: – This component combines with other external OpenStack components like regular file systems, for image storage uses HTTP and Amazon S3, etc.

• glance-API, which accepts API, calls for image discovery, retrieval, and storage.
• Glance-registry, which stores, processes, and retrieves metadata information for images.
• database, which stores image metadata.

As mentioned earlier the Image (Glance) receives API requests for images from the users or from the components of Nova and then stores it in the simple file systems or in the object storage service like Swift or maybe in some other storage warehouse or repository.

Following back end stores are supported by the Image (Glance) service:

• File system:- By default the Glance service stores the VM images in the back end simple file system as mentioned earlier. This back end records image files into the individual file system.
• Object Storage: – This back end store service is available for storing objects.
• Block Storage: – This block storage service is available for storing the blocks.
• VMware: – This is an ESX/ESXi or vCenter server target system.
• S3: – As mentioned earlier this is an Amazon S3 service.
• HTTP: – As mentioned earlier, using this storing Image service can read the VM images using HTTP which are present on the internet. The HTTP store is read-only service.
• RADOS Block Device (RBD): – This storing is used for storing images present inside the Ceph storage cluster with the help of Ceph’ RBD interface.
• Sheepdog: – It is a distributed storage system for QEMU/KVM.
• GridFS: – This stores images with the help of MongoDB.

Let’s learn about the architecture of Glance: –

As discussed earlier, Image (glance) accepts RESTful API requests for server and it has client-server architecture. The user requests are received via RESTful API and then it waits for authentication from Keystone. The Domain controller of Glance handles all the inner processes that are split into layers and each and every layer applies their own functions. The communication layer between outside storage back ends and the Glance or between the simple file systems is Glance store and it offers consistent interaction for accessing. Every component in the system can access SQL central database which is used by Glance.

Following components are present in the Glance architecture:

• Client: – The component client is an application which utilizes a Glance server.
• REST API: – Trough REST the Glance functionality can be exposed.
• Database Abstraction Layer (DAL): – The communication between Glance and Databases is combined with this application programming interface.
• Glance Domain Controller: – The major Glance functionalities like database connections, policies, notifications and authorization are implemented by this middleware.
• Glance Store: – The co-ordinations between the Glance and the other data stores are organized by this component.
• Registry Layer: – It is an operational layer and it also organizes safe communication between the domain and the Database Abstraction Layer with the help of different services.

Definitions of Metadata:

As discussed earlier Image (Glance) holds a metadefs catalog which offers the OpenStack community a way for determining various metadata key names programmatically as well as determining the correct values which can be implemented to the resources of OpenStack.

It is important to keep in mind that whatever we are talking here is simply just about a catalog i.e. as mentioned earlier the keys and the values will not perform anything until implemented to every OpenStack resources with the help of the APIs or with the help of the client tools which are offered by the facilities accountable for OpenStack resources.

The relationship between the Image service and the metadefs service is not so special. The Image service API or the client tools are used for applying the keys and values to the images which are defined in the metadefs service and it is similar to the various other OpenStack services.

Following Design Principles are used for writing the Image (Glance) project:

• Architecture is component based: You can immediately add new activities.
• High availability: rise to more critical workloads.
• Fault tolerance: separate tasks prevents overflowing failures.
• Recoverability: errors must be easily identified, corrected and fixed.
• Open standard: – source deployment for an API which is community driven.

How to manage images in the VM:

The roles are assigned to the users by the cloud operator and these roles decide who will upload and handle the images. The cloud operator may limit the uploading and the handling of the images only to the cloud administrators or cloud operators.

The OpenStack image creates command is used for uploading the images or users can also use the Image service API. For managing the image the OpenStack client which offers methods for listing and deleting images, setting and deleting image metadata and for creating images of the constantly streaming requests or shots or the types of backups.

It is important to note that once you upload an image it is not possible to modify it.

We will discuss how to list or get the details for the image, how to create or modify an image, how to create an image with the help of ISO image and how to troubleshoot the creation of an image in our next blog.

That’s all for today! I hope you find this information helpful. If you have any questions regarding today’s article you can comment it in the comment section below. See you soon with another interesting article.

People also read: