The companies or contributors of hypervisor products or projects are usually the main contributor of compute virtualization drivers. It is easy to add a custom driver that implements one part or all of the features abstracted by the compute service, which is available via the compute API.
Libvirt
The libvirt in Linux is an abstraction library to access and manage the virtual machines and containers in a Linux server and their network and storage
configuration. It supports multiple technologies: KVM/QEMU, Xen, VirtualBox, VMware ESX, Hyper-V, OpenVZ, LXC, etc.
This is the default driver used by OpenStack and the most popular one for the kernel-based virtual machine/quick emulator (KVM/QEMU) virtualization. One of the pro arguments is managing the virtual machines regardless of the
weaknesses, especially given how it is mainly designed for KVM/QEMU, and some features provided by other virtualization technologies might be hidden by this abstraction layer. Hopefully other virtualization technologies are directly supported using their own Nova drivers.
VMware
Using VMware in OpenStack allows you to enjoy the advantages of both
technologies: virtualization features for VMware and management/standard APIs for OpenStack.
VMware provides a great virtualization technology that provides the following: High Availability (HA); the ability to automatically reboot an instance on a full working hardware when an issue is detected by the hypervisor. In the
marketed world of VMware, the “HA” is more branded as “fault tolerance.” Fault tolerance (the live migration without restart of an instance on a working host when a host is down).
Distributed Resource Scheduler (DRS), the smart dispatching of the running instances depending of the resources usage in real time.
For storage you can directly use the VMware datastore technology in Cinder and Glance, allowing you to manage all of your blocks using the standard block storage APIs.
STORAGE
The concept of object storage (named Swift in OpenStack) can be quite
complicated to understand for an application developer when you are using a local file system to store all of the static medias (e.g. images, videos, music, etc.) and documents created and used by your application. But this is often one of the main steps to horizontally scale an application that uses these medias.
Good examples are the traditional content management systems (CMS) and blog engines that by default store locally all of the medias uploaded using the web application. This transition to an object storage infrastructure for any application is not always easy to realize since the code often needs to be partially rewritten to support this new storage system. It needs to be re-written because an application needs to change the way it accesses files (objects), for instance accessing local files in a hard drive is not the same as accessing objects using a REST API.
There are advantages for switching to object storage:
You don’t have to worry about the total space size; this is the job of the infrastructure provider, and an object storage service like Swift easily scales horizontally.
You can split objects into multiple small blocks and the size of an object can almost be unlimited.
You can store an unlimited number of objects in a single container or bucket of objects.
The replication of the objects is done at the infrastructure level; it can even be done across multiple infrastructure regions.
Here are some potential blocking design and implementation points when you want to switch an application using a local file system to an object storage service:
You can access your objects only using HTTP(s), but this can be great when the clients of your application are already using the HTTP protocol: you can
provide access to an object without having to download it in your application server.
Object storage is not a file system and should not be used like one. One of the worst examples is to try to match an existing file system hierarchy when developing an application using an application. In many use cases, the
hierarchy logic should be on the application-side and the object storage should only contain the object data (blobs). The best example of this bad usage is
renaming (moving) objects in OpenStack Swift. Since the dispatching of the objects across the storage infrastructure is based on a hash of the object name, the object will be copied between two servers and deleted from the source server. Moreover renaming a virtual directory (in fact an object with a mime- type specific to a directory) means renaming each object of the directory.
Introducing OpenStack Swift
The Swift service (OpenStack’s object storage) provides all of the OpenStack projects with a HTTP REST API, allowing the processing of all the common operations on a stored object using the standard HTTP design and features to manage the resources (see Figure 2.5).
Figure 2.5
This project is horizontally scalable, distributed and highly available by design with different main components:
Swift proxy server: this service dispatches the HTTP requests accessing the different objects to all the backend nodes. This component can be easily scaled since the positions of an object in an infrastructure are determined by hashing its name and finding its position using a ring algorithm.
Swift account server: this service is responsible for storing the listing of the containers in the different existing accounts.
Swift container server: this is similar to the account server, but responsible for listing the objects in a container.
Swift object server: this is a storage backend installable on a physical host that provides an internal object storage API to manage the objects stored on the local server.
All of these components must be replicated and can be horizontally replicated to infinity (see Figure 2.6).
Figure 2.6