OpenQRM(open Qlusters Resource Manager) is an Open Source Data Center Management and Cloud Computing Platform. It is a fully community driven, Open-Source project backed up by main Sponsor openQRM Enterprise. It offers full automation of data centers and their scalable management.
Datacenters are custom and complex environments due to the number of involved subsystems like physical servers, virtual machines, different operating systems, network components, network configuration and network services like DNS and dhcpd plus a system- and service monitoring etc. and the complexity of each subsystem. OpenQRM aims at offering a centralized management of all these within a single administration console.
openQRM simplifies the complex tasks by using the concept of ‘breaking’ the datacenters into manageable subsystems. Each subsystem is separately implemented via. A plugin which provides the functionality to manage it. Then open QRM creates automated and generic interfaces between the different components via its completely plug-able software architecture. Actually the base server of openQRM is designed to just have a single function, to manage plugins.
openQRM has a unique architecture that unifies physical and virtual machine deployment within a single management console. openQRM integrates with all mainstream virtualization technologies and supports transparent P-to-V, V-to-P and also V-to-V migrations. The “plug-ability” of openQRM helps combine open-source and commercial third-party components for data center administration.
Working:
A server(Linux) consists of the following components :
-> (Linux) Kernel
-> kernel modules
-> Initial Ramdisk (initrd)
-> Root-filesystem
It is to be noted that all these components are files. Hence openQRM treats the systems as files. Hence it is recommended to use Modern Storage Systems.
In general, a small, initial ramdisk is used by Linux systems to pre-setup the init procedure by running /sbin/init. The initrd is responsible for finding and mounting the root-filesystem. openQRM uses this generic Linux mechanism in an enhanced way by making the process of finding and mounting the root-filesystem completely plug-able. In openQRM the storage-plugin helps the booting system within the initrd stage in mounting the root-filesystem. Since storage-types are plug-able in openQRM, any kind of external, remote storge devices can be used.
The following is the boot process of openQRM:
- Bios is configured to do a network-boot (PXE)
- System sends a PXE request and asks for an automated network-configuration via dhcp
- openQRM’s dhcpd-server answers the request and provides an ip-address
- System activates its network-configuration and reads its PXE-configuration from the openQRM server
- System downloads its operating system kernel and initial ramdisk (initrd)
- System executes the Operating System kernel and loads the initial ramdisk
- Within the ramdisk network-hardware is being automatically detected and initialized
- Having full network connection the system now downloads its full set of kernel modules
- Additional hardware-detection with all available kernel modules
- System gets configuration parameters from the openQRM server
By now hardware is detected and the network is fully initialized. The system can continue in two different ways now:
1. As idle, free server resource
OR 2. As an active, assigned resource acting as a service provider
In case the system is active assigned to a started appliance, the following steps are executed:
- The deployment type check and method of the server-image assigned to its appliance
- The image-deployment hook provided by specific storage-plugin is downloaded
- System executes “mount_root” function provided in the image-deployment hook
- The image-deployment hook mounts the server-image-location from the remote storage
- Kernel- and kernel-modules files are transferred to the root-filesystem mounted rw
- The openQRM-client is being installed on to the mounted root-filesystem
- The image-deployment hook re-mounts the server-image-location read-only
- System continues with regular init (running /sbin/init on the root-filesystem)
- During futher init procedure of the System, the openQRM-client is started
- Further plugin services are started
openQRM’s hardware detection uses “pcimodules”. The “pcimodules” command is available as a patch for the “pcituils” package and simply lists all needed kernel modules according the pci ids of the detected hardware. “pcimodules” hardware detection method on physical and virtual systems is found to detect much more hardware than the “hwsetup” utility.
Resource
A resource in openQRM is “everything which has a CPU and some memory”. Resources in openQRM have different types such as Physical Systems, Virtualization Host or Virtual Machine. According its type openQRM interfaces and communicates with the specific resource.
Kernel
Kernels in openQRM are Linux Operating System kernels which can be assigned to resources. This happens automatically through the appliance model through openQRM’s integrated, centralized network-boot-manager PXELINUX from the Syslinux project.
Image
An image (server-image) is located on a network-attached storage device (NAS or SAN) and contains a root-filesystem of an Operating system supported by openQRM. The image is completely self-contained and, via the appliance model it and in combination with a kernel can be started on any available (idle) resource. The server-image root-filesystem may be a minimal Operating system installation which is then further leveraged (e.g.via the Puppet integration) or it also can be a full installed completely pre-configured set of applications. An image can even be a snapshot of an existing server or a clone or copy of an an existing server-image.
Appliance
It represents one(or more) of the actual services which should be provided by the Datacenter. An appliance is the combination of a kernel, an (server-) image, a resource and service requirements plus service-level-agreements(SLA). With those informations openQRM then fully automates the management of the specific services running on the appliance’s server-image.
Storage
A storage component in openQRM consists of an integrated resource containing some kind of network-attachable storage (NAS or SAN). Storages in openQRM are providing the image-locations, meaning the place where server-images are stored and directly attached to resource as required. By creating a storage server openQRM then exactly knows how to interface with its specific storage technology and further allows automated management of the available storage space and volumes.
Migrations:
openQRM supports transparent P-to-V, V-to-P and also V-to-V migrations.
P-to-V Migration
Since resources are decoupled from their root-files-systems migration appliances from physical server to virtual machines is complete transparent and easy. The steps below outline how to exchange an appliance physical resource with a virtual one :
- stop the appliance
- edit the applinace
- change the “resource-type” from “Physical System” to a “Virtulization-type VM”
- select a new resource from the type “Virtulization-type”
- save the appliance
- start the appliance
The appliance will now start using the new, virtual resource as defined in the appliance configuration.
V-to-P Migration
This is similar to the P2V migration. The steps to migrate an appliance from a virtual machine to a physical system :
- stop the appliance
- edit the appliance
- change the “resource-type” to “Physical System”
- select a new resource from the type “Physical System”
- save the appliance
- start the appliance
The appliance now runs on a physical system.
V-to-V Migration
Using the same method appliances can be moved from one Virtualization type to another. Here the steps necessary for the migration :
- stop the appliance (Virtualization type A)
- edit the appliance
- change the appliance resource type from “Virtualization-VM” (type A) to “Virtualization-VM” (type B)
- select a new resource from “Virtualization-VM” (type B)
- save the apliance
- start the appliance
The appliance will now start using the new, virtual resource(Virtualization type B) as defined in the appliance configuration.
Requirements:
- Simple Proof-of-Concept Setup
- 1 Physical System dedicated for the openQRM Server
- VT CPU Extension (full Virtualization Support)
- A free partition dedicated for the server-image store (at least 20 GB)
- 1 GB Memory
- Basic Setup
- 3 Physical Systems (openQRM Server, Storage and Virtualization Host)
- VT CPU Extension (full Virtualization Support)
- A free partition dedicated for the server-image store (at least 100GB) on the system dedicated for the Storage Production Setup
- 4+N Physical Systems (2 for openQRM Server HA, N Storage and N Virtualization Hosts)
- VT CPU Extension (full Virtualization Support)
