If you take a look at the OpenStack architecture, you will recognize well-known elements that are familiar from cloud providers and virtualization solutions. However, these are deliberately more general. For example, there is not the term "virtual disk," "iSCSI Lun," or "Elastic Block Store," just volume .

A volume provides block storage. Whether it is storage from a SAN, a disk image file or even a physical disk, from the point of view of the OpenStack API, it is irrelevant. The technology behind it is transparent. In this way you can reach that the actual resources in both the private or in the public cloud can lie.

Such use cases can be solved, for example, by using a global namespace from the Red Hat Storage solution. This allows storage systems to scale independently of dedicated storage hardware. Background of today's OpenStack implementation is the focus on software-based services such as network services and storage services.


The basic architecture of OpenStack

Of course, in the end a penetration must be possible. So the user has to have control over which I / O performance and which resilience a volume can offer. But first of all, it is important that the user can request resources with one and the same API as a volume both in his in-house virtualization system and in a public cloud provider.

Anyone who is previously familiar with virtualization solutions such as VMware will find the Object Store as a new element. This is a global storage that can be used by all users of the Hybrid Cloud. The use is limited only by access rights. This memory is addressed via an HTTP or HTTPS API that follows the REST principles. To ensure fast access, the object store can be kept redundantly in several locations, which at the same time ensures fail-safety.

A volume is different in that it is always operated in the immediate vicinity of the computing hardware, so that the speed matches that of local hard disk. In most cases, a volume is used by only one computing instance, while files in the object store can be accessed by many users at the same time.

Finally, an image is a bootable operating system that can be booted on a computing resource without the need for fixed computing resources such as the number of CPUs or amount of memory. The boot disk does not exist, as one might suspect as a volume, but in the object store. Only when it is assigned to an instance is it copied to a volume before it is started. In this way, an image for all users is available, if the access authorization allows it.

The key to a successful implementation of OpenStack is the proper creation of images and the configuration of the application to run on the cloud. The philosophy of OpenStack is that applications scale horizontally. That means that applications can move physical and virtual hardware and between private cloud and public cloud providers without being dependent on specialized hardware. For example, the high availability is to be solved directly in the application and in the services of the application, instead of relying on special infrastructure services such as cluster solutions. As an added value you get for it easily scaling applications that can scale up and down with the needs of users.

Choose the right operating system

The solution to this problem starts with the selection of the operating system. So you should under no circumstances use an OS that is offered by a particular cloud provider, such as Amazon Linux. Instead, you should look for an operating system that offers full OpenStack support and whose images are executable by different cloud providers. Red Hat Linux (RHEL) is designed from the ground up to create OpenStack images that load necessary drivers for virtual or physical hardware after booting and are universally executable.

Another factor is the maintainability of the operating systems. In closed-cloud systems, applications are often implemented as appliance images. This is convenient because the images do what you expect them to do right after booting. However, the operator of the application itself must take care of the maintenance of the operating system.

With OpenStack there are better options. It is recommended to configure only a few basic images, which are always kept up-to-date with security updates. The actual application should always be retrieved from the Object Store if possible. A script can then make necessary adjustments in the operating system configuration files and reload required components. This is the easiest way to implement automatic release management of an application.

Anyone familiar with proprietary virtualization systems is accustomed to using virtual hard disk files for data storage. In an OpenStack implementation one should refrain from doing so. Scaling should always be achieved through additional computing resources (virtual or real servers) and not by adding more virtual CPUs or virtual memory. This means that volumes should be considered as temporary or instance-local storage as much as possible. Everything that needs to be stored persistently belongs in the object store, where it is available to all instances.