Schlagwort: openQRM

Kategorien
Services

openQRM 5.1 ist verfügbar: OpenStack und Eucalyptus haben einen ernsthaften Konkurrenten

openQRM Projektmanager Matt Rechenburg hatte mir Ende Juli schon einige neue Features von openQRM 5.1 verraten. Jetzt ist das endgültige Release mit weiteren Funktionen veröffentlicht worden. Das Gesamtbild sieht wirklich vielversprechend aus. Zwar lässt die Überschrift im ersten Moment vermuten openQRM wäre etwas vollkommen Neues, was nun versucht OpenStack oder Eucalyptus den Rang abzulaufen. Das ist bei weitem nicht so. openQRM existiert bereits seit 2004 und hat im Laufe der Jahre eine große Funktionsvielfalt aufgebaut. Das Open-Source Projekt aus Köln geht in der Masse leider etwas unter, weil die Marketing-Maschinen hinter OpenStack und Eucalypts auf Hochtouren laufen und deren Lautsprecher um ein Vielfaches größer sind. Dabei muss sich openQRM vor beiden nicht verstecken. Im Gegenteil, mit der Version 5.1 hat das Team um Rechenburg noch einmal kräftig an Funktionen zugelegt und insbesondere die Benutzerfreundlichkeit erhöht.

Die neuen Funktionen in openQRM 5.1

Auch openQRM-Enterprise sieht in dem Hybrid Cloud Modell eine wichtige Bedeutung für die Zukunft der Cloud. Aus diesem Grund wurde openQRM 5.1 mit einem Plugin für die Unterstützung der Amazon Web Services (AWS), Eucalyptus Cloud und Ubuntu Enterprise Cloud (UEC) erweitert, um mit diesen drei Cloud Infrastrukturen eine Hybrid Cloud aufzuspannen. Damit bindet openQRM sowohl AWS als auch Eucalyptus und UEC als weitere Ressourcen-Anbieter für Rechenleistung und Speicherplatz ein und ist damit in der Lage Public Cloud Infrastrukturen als auch lokale virtuelle Maschinen zu verwalten. Damit erhalten Administratoren die Möglichkeit anhand von openQRM ihren Endnutzern über ein Cloud-Portal z.B. Amazon AMIs transparent bereitzustellen und über Nagios den Zustand der virtuellen Maschinen zu überwachen.

Eine weitere neue Funktionalität ist die sehr enge Integration von Puppet, mit der Endnutzer lokale virtuelle Maschinen ebenso wie Public Cloud Infrastrukturen mit personalisierten, verwalteten Software-Stacks bestellen können. Die wohl beste technische Erneuerung ist das Berücksichtigen des High-Availability Konzepts der Amazon Web Services. Fällt eine Amazon EC2-Instanz in einen Fehlerzustand, wird automatisch eine neue gestartet. openQRM 5.1 ist dabei sogar in der Lage, den Ausfall einer gesamten Amazon Availability Zone (AZ) zu kompensieren. Sollte eine AZ nicht mehr erreichbar sein, wird die entsprechende EC2-Instanz in einer anderen Availability Zone derselben Region gestartet.

openQRM-Enterprise baut die Open-Source Lösung openQRM konsequent um Cloud-übergreifende Verwaltungslösungen aus, um seinen Kunden damit zu ermöglichen, flexibel über die Grenzen ihrer eigenen IT-Kapazitäten hinweg zu wachsen, so CEO Matt Rechenburg.

Neben technischen Erweiterungen wurde ebenfalls viel Wert auf die Benutzerfreundlichkeit gelegt. Die Benutzeroberfläche für den Administrator wurde in openQRM 5.1 vollständig überarbeitet. Damit wird für eine bessere Übersichtlichkeit und Benutzerführung gesorgt. Auch das Dashboard, als zentrale Anlaufstelle hat davon stark profitiert, indem alle Informationen, wie der Status des Rechenzentrums, auf einen Blick angezeigt werden.

Für die openQRM Enterprise Edition wurden ebenfalls neue Funktionen vorgestellt. Dazu gehört ein neues Plugin für die rollenbasierte Zugriffsrechteverwaltung, die eine feingranulare Einstellung von Berechtigungen für Administratoren innerhalb des gesamten openQRM-Systems erlaubt. Damit lassen sich komplette Unternehmenstopologien auf openQRM-Rollen abbilden, um Administratoren, die im Unternehmen nur für die Virtualisierung zuständig sind, auf die Verwaltung und Bereitstellung virtueller Maschinen einzuschränken.

Weitere Erneuerungen in openQRM 5.1 sind eine verbesserte Unterstützung der Virtualisierungstechnologie KVM, indem nun ebenfalls GlusterFS für KVM-Volumes genutzt werden kann. Zudem werden VMware Technologien ab sofort besser unterstützt. Das bedeutet, dass sich nun auch bestehende VMware ESX Systeme verwalten, sowie lokale oder über das Netzwerk startbare VMware ESX Maschinen installieren und verwalten lassen.

openQRM macht einen großen Schritt nach vorne

Zwar existiert openQRM bereits deutlich länger am Markt als OpenStack oder Eucalyptus. Dennoch ist der Bekanntheitsgrad beider Projekte größer. Das liegt vorwiegend an den großangelegten Marketing-Aktivitäten sowohl von der OpenStack Community als auch von Eucalyptus. Technologisch und Funktional muss sich openQRM aber keinesfalls verstecken. Im Gegenteil, openQRMs Funktionsumfang ist um ein Vielfaches mächtiger als der von OpenStack oder Eucalyptus. Wo sich die beiden ausschließlich auf das Thema Cloud konzentrieren, liefert openQRM zudem eine vollständige Data Center Management Lösung inklusive.

Auf Grund der langen Historie hat openQRM in den vergangenen Jahren viele neue und wichtige Funktionen erhalten. Allerdings ist dadurch ebenfalls ein wenig der Überblick verloren gegangen, was die Lösung überhaupt im Stande ist zu leisten. Wer jedoch verstanden hat, dass sich openQRM aus den ineinander integrierten Bausteinen „Data Center Management“, „Cloud-Backend“ und „Cloud-Portal“ zusammensetzt, wird erkennen, dass ihm die Open-Source Lösung, insbesondere beim Aufbau von Private Clouds, einen Vorsprung gegenüber OpenStack und Eucalyptus ermöglicht. Speziell der Bereich Data Center Management darf für den Aufbau einer Cloud nicht vernachlässigt werden, um den Überblick und die Kontrolle über seine Infrastruktur zu behalten.

Mit der Version 5.0 wurde bereits damit begonnen die Strukturen zu schärfen und die einzelnen Funktionen zu Workflows zusammenzufassen. Dieses wurde durch das Release 5.1 noch einmal besser herausgearbeitet. Die neue Optik und Aufteilung des openQRM-Backends wurde vollständig überarbeitet, wirkt aufgeräumter und dadurch übersichtlicher in der Handhabung und wird alle Kunden positiv überraschen.

Die Erweiterung um die Hybrid-Cloud Funktionalität ist ein wichtiger Schritt für die Zukunft von openQRM. Das Ergebnis der Rackspace 2013 Hybrid Cloud Umfrage hat gezeigt, dass 60 Prozent der IT-Entscheider die Hybrid Cloud als Hauptziel vor Augen haben. Dabei wollen bzw. haben ebenfalls 60 Prozent ihre Applikationen und Workloads aus der Public Cloud abgezogen. 41 Prozent haben angegeben die Public Cloud teilweise verlassen zu wollen. 19 Prozent wollen die Public Cloud sogar vollständig verlassen. Die Gründe für den Einsatz einer Hybrid Cloud anstatt einer Public Cloud sind eine höhere Sicherheit (52 Prozent), mehr Kontrolle (42 Prozent) sowie eine bessere Performance und höhere Zuverlässigkeit (37 Prozent). Zu den Top Vorteilen, von denen Hybrid Cloud Nutzer berichten, gehören mehr Kontrolle (59 Prozent), eine höhere Sicherheit (54 Prozent), eine höhere Zuverlässigkeit (48 Prozent), Kostenvorteile (46 Prozent) und eine bessere Performance (44 Prozent).

openQRM orientiert sich dabei nicht überraschend am aktuellen Public Cloud Marktführer Amazon Web Services. Damit lässt sich die Cloud-Infrastruktursoftware ebenfalls in Kombination mit Eucalyptus und anderen Amazon kompatiblen Cloud-Infrastrukturen nutzen, um eine massiv skalierbare Hybrid-Cloud Infrastruktur aufzubauen. Dabei setzt openQRM auf sein bewährtes Plugin-Konzept und bildet Amazon EC2, S3 und Eucalyptus genau so ab. Amazon und Eucalyptus werden, neben eigenen Ressourcen aus einer privaten openQRM Cloud, damit zu einem weiteren Ressourcen Provider, um schnell und unkompliziert mehr Rechenleistung zu erhalten.

Zu den absoluten Killerfeatures gehören meiner Ansicht nach das automatische Applications Deployment mittels Puppet, mit dem End-Nutzer sich bequem und automatisiert EC2 Instanzen mit einem vollständigen Softwarestack selbst bereitstellen können, sowie die Berücksichtigung der Amazon Availability Zone übergreifenden High-Availability Funktionalität, die von vielen Cloud-Nutzern aus Unwissenheit immer wieder vernachlässigt wird. Aber auch die verbesserte Integration von VMware Technologien wie ESX Systemen sollte nicht unbeachtet bleiben. Schließlich ist VMware noch die führende Virtualisierungstechnologie am Markt. Damit erhöht openQRM ebenfalls seine Attraktivität, um als Open-Source Lösung zur Steuerung und Kontrolle von VMware Umgebungen eingesetzt zu werden.

Technologisch und Funktional ist openQRM auf einem sehr guten Weg in die Zukunft. Es muss allerdings mehr in die Öffentlichkeitsarbeit und das Marketing investiert werden.

Kategorien
News

Hosted Private Cloud – Open-Source Cloud Computing mit openQRM

Unternehmen haben die Vorteile der Flexibilisierung der eigenen IT-Infrastruktur erkannt. Dennoch hat die jüngste Vergangenheit die Bedenken bestärkt, den Weg in die Public Cloud aus Gründen des Datenschutzes und der Informationssicherheit zu meiden. Es sind daher Alternativen gefragt. Mit der Private Cloud wäre eine gefunden. Wären dazu nicht hohe Vorabinvestitionen in eigene Hard- und Software notwendig. Ein Mittelweg besteht in der Nutzung einer Hosted Private Cloud. Diese Form der Cloud wird mittlerweile von einigen Providern angeboten. Es besteht aber ebenfalls die Möglichkeit, selbst den Aufbau und den Betrieb zu übernehmen. Dieser INSIGHTS Report zeigt, wie dieses mit der Open-Source Cloud Computing Infrastrukturlösung openQRM möglich ist.

Hosted Private Cloud – Open-Source Cloud Computing mit openQRM by René Büst

Kategorien
Insights @en

Building a hosted private cloud with the open source cloud computing infrastructure solution openQRM

Companies have recognized the benefits of the flexibility of their IT infrastructure. However, the recent past has reinforced the concern to avoid the path to the public cloud for reasons of data protection and information security. Therefore alternatives need to be evaluated. With a private cloud one is found, if this would not end in high up-front investments in own hardware and software. The middle way is to use a hosted private cloud. This type of cloud is already offered by some providers. However, there is also the possibility to build it up and run themselves. This INSIGHTS report shows how this is possible with the open source cloud computing infrastructure solution openQRM.

Why a Hosted Private Cloud?

Companies are encouraged to create more flexible IT infrastructure to scale their resource requirements depending on the situation. Ideally, the use of a public cloud is meeting these requirements. For this no upfront investments in own hardware and software are necessary. Many companies dread the way into public cloud for reasons of data protection and information security, and look around for an alternative. This is called private cloud. The main advantage of a private cloud is to produce a flexible self-service provisioning of resources for staff and projects, such as in a public cloud, which is not possible by a pure virtualization of the data center infrastructure. However, it should be noted that investments in the IT infrastructure must be made to ensure the virtual resource requirements by a physical foundation for building a private cloud.

Therefore, an appropriate balance needs to be found that allows a flexible resource obtaining for a self-service, but at the same time must not expect any high investment in the own infrastructure components and without to waive a self-determined data protection and security level. This balance exists in hosting a private cloud at an external (web) hoster. The necessary physical servers are rented on a hoster who is responsible for their maintenance. In order to secure any physical resource requirements, appropriate arrangements should be made with the hoster to use the hardware in time. Alternatives include standby server or similar approaches.

On this external server-/storage-infrastructure the cloud infrastructure software is then installed and configured as a virtual hosted private cloud. For example, according to their needs this allows employees to start own servers for software development and freeze and remove them after the project again. For the billing of the used resources, the cloud infrastructure software is responsible, which provides such functions.

openQRM Cloud

Basically, an openQRM Cloud can be used for the construction of a public and private cloud. This completely based on openQRM’s appliance model and offers fully automated deployments that can be requested by cloud users. For this openQRM Cloud supports all the virtualization and storage technologies, which are also supported by openQRM itself. It is also possible to provide physical systems over the openQRM Cloud.

Based on the openQRM Enterprise Cloud Zones, a fully distributed openQRM Cloud infrastructure can also be build. Thus, several separate data centers may be divided into logical areas or the company topology can be hierarchically and logically constructed safely separated. Moreover openQRM Enterprise Cloud Zones integrates a central cloud and multilingual portal including a Google Maps integration, so an interactive overview of all sites and systems is created.

Structure of the reference environment

For the construction of our reference setup a physical server and multiple public IP addresses are required. There are two options for installing openQRM:

  • Recommended: Configuration of a private class C subnet (192.168.xx/255.255.255.0) in which openQRM is operated. openQRM required an additional public IP address for access from the outside.
  • Option: Install openQRM in a virtual machine. In this variant openQRM controls the physical server and receives the virtual machines from the physical host for subsequent operations of the cloud.

For the assignment of public IP addresses cloud NAT can be used in both scenarios. This openQRM Cloud function will translate the IP addresses of the private openQRM Class C network into public addresses. This requires pre-and post-routing rules on the gateway / router using iptables, configured as follows:

  • iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o br0 -j MASQUERADE
  • iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
  • o More information on pre-and post-routing with iptables can be found at http://www.karlrupp.net/en/computer/nat_tutorial

For the configuration of complex network environments, the IP management plugin is recommended. This enterprise plugin allows to set any network- and IP address configurations for the managed servers. In the openQRM Cloud, it also provides a mapping of networks to cloud users and groups and also supports the automated VLAN management.

In addition, two bridges are needed:

  • One of the public interface with a public IP address.
  • One for the private interface dpe for which DHCP is configured.

The data in the cloud are later stored in the local storage of the physical server. For this purpose, there are two variants:

Recommended:

  • KVM-Storage LVM Deployment (LVM Logical Volume Deployment)
  • Requires one or more dedicated LVM volume group (s) for the virtual machines. For more complex setups a central iSCSI target or a SAN is recommended.

Option:

  • KVM-Storage BF Deployment (blockfile deployment)
  • Create a directory on the Linux server as
    • /var/lib/kvm-storage/storage1
    • /var/lib/kvm-storage/storage2

      • (The storage directories can be set arbitrarily on the plugin configuration.)

  • For more complex setups, a central NAS for the configured mount points should be used.

At the end iptables must be configured according to the rules above and the desired own safety. After that the installation of openQRM follows. Packages for popular Linux distributions are available at http://packages.openqrm.com. After openQRM has been installed and initialized the configuration follows.

Basic configuration of openQRM

The first step after initialization is editing the „/usr/share/openqrm/plugins/dns/etc/openqrm-plugin-dns.conf“, by changing the default value to the own domain.

Configure domain for the private network
# please configure your domain name for the openQRM network here!
OPENQRM_SERVER_DOMAIN=“oqnet.org“

After that we activate and start the plug-ins via the web interface of the openQRM server. The following plugins are absolutely necessary for this:

DNS Plugin

  • Used for the automated management of the DNS service for the openQRM management network.

DHCPD

  • Automatically manages the IP addresses for the openQRM management network.

KVM Storage

  • Integrates the KVM virtualization technology for the local deployment.

Cloud-Plugin

  • Allows the construction of a private and public cloud computing environment with openQRM.

Further additional plugins are recommended:

Collectd

  • A monitoring system including long-term statistics and graphics.

LCMC

  • Integrates the Linux Cluster Management Console to manage the high availability of services.

High-Availability

  • Enables automatic high availability of appliances.

I-do-it (Enterprise Plugin)

  • Provides an automated documentation system (CMDB).

Local server

  • Integrates existing and locally installed server with openQRM.

Nagios 3

  • Automatically monitors systems and services.

NoVNC

  • Provides a remote web console for accessing virtual machines and physical systems.

Puppet

  • Integrates Puppet for a fully automated configuration management and application deployment in openQRM.

SSHterm

  • Allows secure login via a web shell to the openQRM server and integrates resource

Plugins which offer more comfort in the automatic installation of virtual machines as cloud templates are:

Cobbler

  • Integrates cobbler for automated deploying of Linux system in openQRM.

FAI

  • Integrates FAI for the automated provisioning of Linux systems in openQRM.

LinuxCOE

  • Integrates LinuxCOE for the automated provisioning of Linux systems in openQRM.

Opsi

  • Integrates Opsi for the automated provisioning of Windows systems in openQRM.

Clonezilla/local-storage

  • Integrates Clonezilla for the automated provisioning of Linux and Windows systems in openQRM.

Basic configuration of the host function for the virtual machines

Case 1: openQRM is installed directly on the physical system

Next, the host must be configured to provide the virtual machines. For that an appliance type KVM Storage Host is created. This works as follows:

  • Create appliance
    • Base > Appliance > Create
  • Name: e.g. openQRM
  • Select the openQRM server itself as resource
  • Type: KVM Storage Host

This gives openQRM the information that a KVM storage is to be created on this machine.

Case 2: openQRM is installed in a virtual machine running on the physical system

Using the „local server“ plugin the physical system is integrated into openQRM. To this the „openQRM-local-server“ integration tool is copied from the openQRM server on the system to be integrated, e.g.

scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server [ip-address of the physical system]:/tmp/

After that, it is executed on the system to be integrated:

ssh [ip-address of the physical system]: /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q [ip-address of the openQRM server] -i br0 [-s http/https]

(In this example „br0“ is the bridge to the openQRM management network.)

The integration via „local server“ creates in openQRM automatically:

  • a new resource
  • a new image
  • a new kernel
  • a new appliance from the sub-components above

Next, the appliance of the currently integrated physical system must be configured to provide the virtual machines. For this the appliance is set as type KVM Storage Host. That works as follows:

  • Edit the appliance
    • Base > Appliance > Edit
  • Type: Set KVM Storage Host

This gives openQRM the information that a KVM storage is to be created on this machine.

Basic configuration of the storage function

Now, the basic configuration of the storage follows. For this purpose, a storage object of a desired type is created. This works like this:

  • Create storage
    • Base > Components > Storage > Create
    Case 1, select the resource of the openQRM server
  • Case 2, select the resource of the integrated physical system
  • Name: e.g. KVMStorage001
  • Select deployment type
    • This depends on the selected type at the beginning: KVM-Storage LVM deployment or directory (KVM-Storage BF deployment)

Preparation of virtual machine images

In order to provide virtual machine (VM) later over the cloud portal as part of finished products, an image for a VM must first be prepared. This works as follows:

  • Creating a new virtual machine with a new virtual disk and install an ISO image on it.
    • Plugins > Deployment > LinuxCOE > Create Templates
    • The created images are automatically stored in an ISO pool which each virtual machine within openQRM can access.

Subsequently a base for the master template is created. This serves as a basis to provide users a product over the order process.

  • Create a new appliance
    • Base > Appliance > Create
  • Create a new resource
    • KVM-Storage virtual machine
      • Create a new VM
      • Make settings
      • Select an ISO image
      • Create
    • Select created resource
  • Create a new image
    • Add image as KVM-Storage volume
    • Select KVM-Storage
    • Select volume group on KVM-Storage
    • Add a new logical volume
    • Select an image for the appliance
    • Edit to set a password (The previously chosen password of the ISO is overridden.)
  • Select kernel
    • From the local disk
    • (LAN boot is also possible)
  • Start appliance
    • The automatic installation can now be tracked over VNC.
    • Further adaptations can be done itself.
    • Please consider
      • Misc > Local-Server > Help >Local VMs („Local-Server for local virtual machines “)

Cleaning up

The created appliance can now be stopped and deleted afterwards. The important point was to create an image that can be used as a master template for the cloud.

The created image using the appliance includes the basic operating system which was created from the ISO image.

Configuration of the openQRM Cloud

We have now finished all preparations to start configuring the openQRM cloud. We find the necessary settings at „Plugin > Cloud > Configuration > Main Config“. All parameters which are adapted here have a direct impact on the behavior of the whole cloud.

Basically an openQRM Cloud can be run with basic settings. Depending on the needs and the own specific situation, adaptations can be make. The area “description” in the right column of the table are helpful.

However, there are parameter which are need to consider regardless of the own use case. These are:

Automatic provisioning (auto_provision)

  • Determines if systems are automatically provisioned by the cloud or if an approval of a system administrator is needed.

Provisioning of physical systems (request_physical_systems)

  • This parameter defines if besides virtual machines even physical hosts can be provisioned by the cloud.

Cloning of images (default_clone_on_deploy)

  • By default the cloud rolls out copies (clones) of an image.

High-availability (show_ha_checkbox)

  • Enables to operate the openQRM cloud including the high-availability of the provided resources.

Billing of the used resources (cloud_billing_enabled)

  • openQRM has an extensive billing system to determine own prices for all resources to get a transparent overview of the running costs.

Cloud product manager (cloud_selector)

  • Enables the product manager to provide users various resources over the cloud portal.

Currency for the settlement of resources (cloud_currency)

  • Determines the local currency with which the resources are to be settled.

Exchange ratio for resources in real currency (cloud_1000_ccus)

  • Determines how many 1000 CCUS (Cloud Computing Units) correspond to a previously fixed real currency.

Resource allocation for groups (resource_pooling)

  • Determines from which host an appointed user group receive their virtual machines.

Creating products for the openQRM Cloud

To provide our users the resources over the cloud portal we have to create products first which define the configuration of a virtual machine. The settings for that we find at „Plugin > Cloud > Configuration > Products“.

The “Cloud product management” is used to create various products which users can choose later to build own virtual machines itself over the cloud portal. Products which are available for us are:

  • Number of CPUs
  • Size of local disks
  • Size of RAM
  • Kernel type
  • Number of network interfaces
  • Pre-installed applications
  • Virtualization type
  • If a virtual machine should be high-available

Over the status line by using +/- each product can be activated or deactivated to show or hide it for the user in the cloud portal.

Please note: Products which are deactivated but are still active within a virtual machine continue to be billed.

To create a new CPU product we select the “CPU” tap and define in the area “Define a new CPU product” our wanted parameter.

The first parameter defines how many CPUs (cores), here 64, our product should have. The second parameter determines the value of the product and how many costs occur per hour during its use. In this example, 10 CCUs per hour for 64 CPUs occurs.

With the arrow keys the order on how the single products are displayed in the cloud portal can be determine. The default value is above one.

Please note: In the cloud portal standard profiles in the sizes „small“, „medium“ and „big“ exist. According to the order the profiles are automatically be determined under the respective products. That means that “small” is always the first value, “medium” the second and “big” the third.

openQRM also allows to order virtual machines with pre-configured software stacks. For this openQRM uses Puppet (Plugins > Deployment > Puppet). Thus, for example, it is possible to order the popular LAMP stack.

If we have configured our product portfolio, it’s the user’s turn to order virtual machines. This is done via the cloud portal.

openQRM Cloud-Portal

To create a new virtual machine (VM) we click on the tap “New”. An input mask follows on which we can create our
VM based on the products the administrator has determined and approved in the backend.

We choose the profile “Big” and a LAMP server. Our virtual machine now consists of the following products:

  • Type: KVM-Storage VM
  • RAM: 1 GB
  • CPU: 64 cores
  • Disk: 8 GB
  • NIC: 1

In addition the virtual machine should be “high-available”. This means, if the VM fails, automatically a substitute machine with exactly the same configuration is started to work on with.

For this configuration we will have to pay 35 CCUs per hour. This is equivalent to 0.04 euros per hour or € 0.84 per day or € 26.04 per month.

If we want to order the virtual machine we select “send”.

Below the tap “Orders” we see all current and past orderings we have made with our user. The status “active” in the first column shows that the machine is already started.

Parallel to this we receive an e-mail including the ip-address, a username and a password, we can use to log into the virtual machine.

The tap “Systems” confirms both information and shows further details of the virtual machine. In addition we have the opportunity to change the systems configuration, pause the virtual machine or to restart. Furthermore the login via a web-shell is possible.

If the virtual machine is not needed any more it can be paused. Alternatively it is possible that the administrator disposes this due to an inactivity of the system or at a specific time.

Creating a virtual machine with the „Visual Cloud Designer“

Besides the “ordinary” way of building a virtual machine, the openQRM Cloud portal enables the user to do that conveniently via drag and drop. Here the „Visual Cloud Designer“ helps, which can be find behind the tap „VCD“.

Using the slider on the left below „Cloud Components” it is possible to scroll between the products. Using the mouse allows to assemble the „Cloud Appliance“ (virtual machine) in the middle with the appropriate products.

Our virtual machine „Testosteron“ we assembled in this case with KVM-Storage, Ubuntu 12.04, 64 CPUs, 1024 MB Ram, 8 GB disk, one NIC, and software for a webserver and the high-availability feature.

With one click on “Check Costs”, openQRM tells us that we will pay 0.03 EUR per hour for this configuration.

To start the ordering process for the virtual machine we click “request”. We get the message that openQRM starts rolling out the resource and we will receive further information into our mailbox.

The e-mail includes, as described above, all access data to work with the virtual machine.

In the cloud portal under “systems” we already see the started virtual machine.

Creating a virtual machine with the „Visual Infrastructure Designer“

Besides the provisioning of single virtual machines the openQRM cloud portal also offers the opportunity to provide complete infrastructures consisting of multiple virtual machines and further components, at one click.

Thus, we use the „Visual Infrastructure Designer“. This can be found in the cloud portal behind the tap “VID”.

Using the “VID” it is possible to build and deploy a complete WYSIWYG infrastructure via drag and drop. For this purpose, it is necessary to create ready profiles with pre-configured virtual machines at first, which include for example webserver, router or gateways. These can be deployed afterwards.

Kategorien
Insights

Aufbau einer Hosted Private Cloud mit der Open-Source Cloud Computing Infrastrukturlösung openQRM

Unternehmen haben die Vorteile der Flexibilisierung der eigenen IT-Infrastruktur erkannt. Dennoch hat die jüngste Vergangenheit die Bedenken bestärkt, den Weg in die Public Cloud aus Gründen des Datenschutzes und der Informationssicherheit zu meiden. Es sind daher Alternativen gefragt. Mit der Private Cloud wäre eine gefunden. Wären dazu nicht hohe Vorabinvestitionen in eigene Hard- und Software notwendig. Ein Mittelweg besteht in der Nutzung einer Hosted Private Cloud. Diese Form der Cloud wird mittlerweile von einigen Providern angeboten. Es besteht aber ebenfalls die Möglichkeit, selbst den Aufbau und den Betrieb zu übernehmen. Dieser INSIGHTS Report zeigt, wie dieses mit der Open-Source Cloud Computing Infrastrukturlösung openQRM möglich ist.

Warum eine Hosted Private Cloud?

Unternehmen sind angehalten ihre IT-Infrastruktur zu flexibilisieren, um ihren Ressourcenbedarf je nach Situation zu skalieren. Der Idealfall stellt hierbei die Nutzung einer Public Cloud dar. Dabei sind keine Vorabinvestitionen in eigene Hard- und Software notwendig. Viele Unternehmen scheuen, aus Gründen des Datenschutzes und der Informationssicherheit, jedoch den Weg in die Public Cloud und schauen sich nach einer Alternative um. Diese nennt sich Private Cloud. Der Hauptvorteil einer Private Cloud besteht dabei in der flexiblen Self-Service Bereitstellung von Ressourcen für Mitarbeiter und Projekte wie in einer Public Cloud, die durch eine reine Virtualisierung der Rechenzentrumsinfrastruktur nicht möglich ist. Jedoch ist für den Aufbau einer Private Cloud zu beachten, dass Investitionen in die eigene IT-Infrastruktur geleistet werden müssen, um den virtuellen Ressourcenbedarf durch einen physikalischen Unterbau zu gewährleisten.

Daher muss ein geeigneter Mittelweg gefunden werden, der einen flexiblen Ressourcenbezug über einen Self-Service ermöglicht, aber zugleich keine hohe Investitionskosten in eigene Infrastrukturkomponenten erwartet und ohne auf ein selbst festgelegtes Datenschutz und -sicherheitsniveau verzichten zu müssen. Dieser Mittelweg besteht im Hosting einer Private Cloud bei einem externen (Web)-Hoster. Die notwendigen physikalischen Server werden über einen Hoster angemietet, der für deren Wartung zuständig ist. Um auch den etwaigen physikalischen Ressourcenbedarf zu sichern, sollten mit dem Hoster entsprechende Absprachen getroffen werden, um die Hardware sehr zeitnah nutzen zu können. Mögliche Alternativen wären Standby-Server oder ähnliche Ansätze.

Auf dieser externen Server-/Storage-Infrastruktur wird anschließend die Cloud-Infrastruktursoftware installiert und zu einer virtuellen gehosteten Private Cloud konfiguriert. Diese erlaubt es Mitarbeitern zum Beispiel je nach Bedarf eigene Server für die Softwareentwicklung zu starten, einzufrieren und nach Beendigung des Projekts wieder zu entfernen. Für die Abrechnung der jeweilig genutzten Ressourcen sorgt die Cloud-Infrastruktursoftware, die über solche Funktionen entsprechend verfügen muss.

openQRM Cloud

Grundsätzlich kann eine openQRM Cloud für den Aufbau einer Public als auch Private Cloud genutzt werden. Diese basiert komplett auf openQRMs Appliance Modell und bietet vollständig automatisierte Deployments die von Cloud Nutzern angefragt werden können. Dazu unterstützt eine openQRM Cloud alle Virtualisierungs- und Speichertechnologien, die auch von openQRM selbst unterstützt werden. Es besteht darüber hinaus die Möglichkeit, physikalische Systeme über die openQRM Cloud bereitzustellen.

Auf Basis der openQRM Enterprise Cloud-Zones lässt sich darüber hinaus eine vollständig verteilte openQRM Cloud Infrastruktur aufbauen. Damit können mehrere voneinander getrennte Rechenzentren in logische Bereiche aufgeteilt oder zum Beispiel die Unternehmenstopologie hierarchisch und logisch sicher voneinander getrennt aufgebaut werden. Zudem integriert openQRM Enterprise Cloud-Zones ein zentrales und mehrsprachiges Cloud-Portal inkl. einer Google Maps Integration, wodurch ein interaktiver Überblick über sämtliche Standorte und Systeme entsteht.

Aufbau der Referenzumgebung

Für den Aufbau unseres Referenz-Setups werden ein physikalischer Server und mehrere öffentliche IP-Adressen benötigt. Für die Installation von openQRM bestehen zwei Möglichkeiten:

  • Empfohlen: Ein privates Class C Subnetz (192.168.x.x/255.255.255.0) konfigurieren in welchem openQRM betrieben wird. openQRM benötigt dann zusätzlich eine öffentliche IP-Adresse für den Zugang von außen.
  • Option: openQRM in einer virtuellen Maschine installieren. Bei dieser Variante steuert openQRM den physikalischen Server und bezieht die virtuellen Maschinen für den späteren Betrieb der Cloud von dem physikalischen Host.

Für die Zuordnung der öffentlichen IP Adressen kann in beiden Szenarien Cloud-NAT eingesetzt werden. Diese openQRM Cloud Funktion übersetzt die IP Adressen des privaten openQRM Class C Netzwerk in öffentliche Adressen. Dies erfordert Post- und Pre-Routing Regeln, die auf dem Gateway/Router mittels IPTables wie folgt konfiguriert werden:

Für die Konfiguration komplexer Netzwerkumgebungen ist das IP-Management Plugin zu empfehlen. Dieses Enterprise Plugin erlaubt es beliebige Netzwerk- und IP-Adress-Konfigurationen für die verwalteten Server vorzunehmen. In der openQRM Cloud bietet es zudem eine Zuordnung von Netzwerken zu Cloud Benutzergruppen und unterstützt darüber hinaus das automatisierte VLAN Management.

Weiterhin werden zwei Bridges benötigt:

  • Eine für die öffentliche Schnittstelle mit einer öffentlichen IP-Adresse.
  • Eine für die private Schnittstelle dpe für die DHCP konfiguriert ist.

Die Daten der Cloud werden später auf dem lokalen Speicher des physikalischen Servers gespeichert. Hierfür bieten sich zwei Varianten:

Empfohlen:

  • KVM-Storage LVM Deployment (LVM Logical Volume Deployment)
  • Benötigt eine oder mehrere dedizierte LVM Volume Group(s) für die virtuellen Maschinen. Für komplexere Setups empfiehlt sich ein zentrales iSCSI Target oder ein SAN zu verwenden.

Option:

  • KVM-Storage BF Deployment (Blockfile Deployment)
  • Erstellen eines Verzeichnis auf dem Linux-Server unter z.B.
    • /var/lib/kvm-storage/storage1
    • /var/lib/kvm-storage/storage2

      • (Die Storage Verzeichnisse lassen sich über die Plugin Konfiguration beliebig einstellen)

  • Für komplexere Setups empfiehlt sich ein zentrales NAS für die konfigurierten Mountpoints zu verwenden.

Am Ende muss IPTables entsprechend der oben genannten Regeln und der gewünschten eigenen Sicherheit konfiguriert werden. Im Anschluss erfolgt die Installation von openQRM. Pakete für die gängigen Linux Distributionen liegen unter http://packages.openqrm.com. Nachdem openQRM installiert und initialisiert wurde folgt dessen Konfiguration.

Basis-Konfiguration von openQRM

Der erste Schritt nach der Initialisierung ist das Editieren der „/usr/share/openqrm/plugins/dns/etc/openqrm-plugin-dns.conf“, indem der Standardwert auf die eigene Domain geändert wird.

Domain für das private Netzwerk konfigurieren:
# please configure your domain name for the openQRM network here!
OPENQRM_SERVER_DOMAIN=“oqnet.org“

Es folgt das Aktivieren und Starten der Plugins über die Weboberfläche des openQRM-Servers. Die folgenden Plugins sind dazu zwingend erforderlich:

DNS Plugin

  • Dient der automatisierten Verwaltung des DNS Service für das openQRM Management-Netzwerk.

DHCPD

  • Verwaltet automatisch die IP-Adressen für das openQRM Management-Netzwerk.

KVM Storage

  • Integriert die KVM Virtualisierungstechnologie für das lokale Deployment.

Cloud-Plugin

  • Ermöglicht den Aufbau einer Private und Public Cloud Computing Umgebung mit openQRM.

Zu den weiteren empfohlenen Plugins gehören:

Collectd

  • Ein Monitoring-System inkl. Langzeitstatistiken und Graphiken.

LCMC

  • Integriert die Linux Cluster Management Console zur Verwaltung der Hochverfügbarkeit einzelner Services.

High-Availability

  • Ermöglicht eine automatische Hochverfügbarkeit der Appliances.

I-do-it (Enterprise Plugin)

  • Bietet eine automatische Systemdokumentation (CMDB).

Local server

  • Integriert bestehende und lokal installierte Server mit openQRM.

Nagios 3

  • Überwacht automatisch Systeme und Services.

NoVNC

  • Bietet eine remote Web-Konsole für den Zugriff auf virtuelle Maschinen und physikalische Systeme.

Puppet

  • Integriert Puppet für ein vollständig automatisiertes Konfigurationsmanagement und Applikationsdeployment in openQRM.

SSHterm

  • Ermöglicht die sichere Anmeldung über eine Web-Shell an den openQRM-Server und integrierte Ressourcen.

Zu den Plugins die mehr Komfort bei der automatischen Installation von virtuellen Maschinen als Cloud Templates bieten gehören:

Cobbler

  • Integriert Cobbler für das automatisierte Bereitstellen von Linux System in openQRM.

FAI

  • Integriert FAI für das automatisierte Bereitstellen von Linux System in openQRM.

LinuxCOE

  • Integriert LinuxCOE für das automatisierte Bereitstellen von Linux System in openQRM.

Opsi

  • Integriert Opsi für das automatisierte Bereitstellen von Windows System in openQRM.

Clonezilla/local-storage

  • Integriert Clonezilla für das automatisierte Bereitstellen von Linux und Windows System in openQRM.

Basis-Konfiguration der Host-Funktion für die virtuellen Maschinen

Fall 1: openQRM ist direkt auf dem physikalischen System installiert

Als Nächstes muss der Host konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird eine Appliance vom Typ KVM Storage Host erstellt. Man geht dazu wie folgt vor:

  • Appliance erstellen
    • Base > Appliance > Create
  • Name: z.B. openQRM
  • Als Ressource den openQRM Server selbst auswählen
  • Typ: KVM Storage Host

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Fall 2: openQRM ist in einer VM installiert, die auf dem physikalischen System läuft

Mittels des „local-server“ Plugins wird das physikalische System in openQRM integriert. Dazu wird das „openqrm-local-server“ Integrations-Tool vom openQRM Server auf das zu integrierende System kopiert z.B.

scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server [IP-Adresse des physikalischen Systems]:/tmp/

Danach wird es auf dem zu integrierenden System ausgeführt:

ssh [IP-Adresse des physikalischen Systems]: /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q [IP-Adresse des openQRM Server] -i br0 [-s http/https]

(in diesem Beispiel ist „br0“ die Bridge zum openQRM Management Netzwerk)

Die Integration mittels „local-server“ erstellt in openQRM automatisch:

  • eine neue Ressource
  • ein neues Image
  • einen neuen Kernel
  • eine neue Appliance aus den obigen Subkomponenten

Als Nächstes muss die Appliance des gerade integrierten physikalischen Systems konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird die Appliance als Typ KVM Storage Host eingestellt. Man geht dazu wie folgt vor:

  • Appliance editieren
    • Base > Appliance > Edit
  • Typ: KVM Storage Host einstellen

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Basis-Konfiguration der Storage-Funktion

Nun folgt die grundsätzliche Konfiguration des Storage. Hierzu wird ein Storage Objekt von einem selbst gewünschten Typ erstellt. Dazu geht man wie folgt vor:

  • Storage erstellen
    • Base > Components > Storage > Create
    Im Fall 1, die Ressource des openQRM Servers auswählen
  • Im Fall 2, die Ressource des integrierten physikalischen Systems auswählen
  • Name: z.B. KVMStorage001
  • Deployment-Typ wählen
    • hängt vom zu Beginn gewählten Typ ab: KVM-Storage LVM Deployment oder Verzeichnis (KVM-Storage BF Deployment)

Vorbereitung eines Images für virtuelle Maschinen

Um später über das Cloud-Portal virtuelle Maschinen (VM) als Teil fertiger Produkte bereitzustellen, muss zunächst ein Image für eine VM vorbereitet werden. Das funktioniert wie folgt:

  • Erstellen einer neuen virtuellen Maschine mit einer neuen virtuellen Festplatte und auf dieser ein ISO installieren.
    • Plugins > Deployment > LinuxCOE > Create Templates
    • Die hier erstellten Images werden automatisch in einem ISO-Pool, der für alle virtuellen Maschinen innerhalb von openQRM verfügbar ist, abgelegt.

Anschließend folgt das Erstellen einer Basis für ein Mastertemplate. Dieses dient als Grundlage, um später den Anwendern ein Produkt über die Cloud anhand eines Bestellvorgangs bereitzustellen.

  • Erstellen einer neuen Appliance
    • Base > Appliance > Create
  • Erstellen einer neuen Ressource
    • KVM-Storage Virtual Machine
      • Neue VM anlegen
      • Einstellungen vornehmen
      • ISO Image auswählen
      • Erstellen
    • Erstellte Ressource auswählen
  • Neues Image erstellen
    • Image als KVM-Storage Volume hinzufügen
    • KVM-Storage auswählen
    • Volume Group auf KVM-Storage auswählen
    • Neues Logical Volume hinzufügen
    • Image für die Appliance auswählen
    • Editieren, um damit ein Passwort zu setzen. (Damit wird das zuvor gewählte Passwort des ISO Image überschrieben.)
  • Kernel auswählen
    • von der lokalen Festplatte
    • (LAN Boot wäre ebenfalls möglich)
  • Appliance starten
    • die automatische Installation kann nun über VNC verfolgt werden.
    • Weitere Anpassungen können nun selbst vorgenommen werden.
    • Und folgendes beachten
      • Misc > Local-Server > Help >Local VMs („Local-Server für Lokale Virtuelle Maschinen“)

Aufräumen

Die erstellte Appliance kann nun gestoppt und anschließend gelöscht werden. Entscheidend hier war, dass wir uns ein Image erstellt haben, das für die Cloud als Mastertemplate genutzt werden kann.

Das über die Appliance erstellte Image enthält das Basis Betriebssystem welches aus dem ISO-Image installiert wurde.

Konfiguration der openQRM Cloud

Wir haben nun alle Vorbereitungen abgeschlossen, um mit der Konfiguration der openQRM Cloud zu beginnen. Die Einstellungen dafür finden wir unter „Plugin > Cloud > Configuration > Main Config“. Sämtliche Parameter, die hier angepasst werden, haben einen direkten Einfluss auf das Verhalten der gesamten Cloud.

Grundsätzlich lässt sich eine openQRM Cloud mit den Standardparametern betreiben. Je nach Bedarf und der eigenen speziellen Situation müssen Anpassungen erfolgen. Hilfreich dazu ist der Bereich „Beschreibungen“ in der rechten Spalte der Tabelle.

Es existieren jedoch einzelne Parameter, die unabhängig von dem eigenen Anwendungsfall in Betracht gezogen werden sollten. Dazu gehören:

Automatische Provisionierung (auto_provision)

  • Legt fest, ob Systeme automatisch durch die Cloud bereitgestellt werden oder ob zunächst eine Freigabe durch den Administrator notwendig ist.

Provisionierung physikalischer Systeme (request_physical_systems)

  • Mit diesem Parameter lässt sich definieren, ob neben virtuellen Maschinen auch physikalische Host über die Cloud bereitgestellt werden sollen.

Klonen der Images (default_clone_on_deploy)

  • Die Cloud rollt standardmäßig Kopien (Klone) eines Images aus.

Hochverfügbarkeit (show_ha_checkbox)

  • Ermöglicht den Betrieb der openQRM Cloud inklusive Hochverfügbarkeit der bereitgestellten Ressourcen.

Abrechnung der genutzten Ressourcen (cloud_billing_enabled)

  • openQRM verfügt über ein umfangreiches Abrechnungssystem, mit dem für sämtliche Ressourcen eigene Preise festgelegt werden können, um einen transparenten Überblick zu den laufenden Kosten zu erhalten.

Cloud Produkt Manager (cloud_selector)

  • Aktiviert den Produkt-Manager, mit dem den Nutzern verschiedene Ressourcen über das Cloud-Portal bereitgestellt werden können.

Währung zur Abrechnung der Ressourcen (cloud_currency)

  • Legt die Landeswährung fest, mit der die Ressourcen abgerechnet werden sollen.

Umrechnungsfaktor für Ressourcen in reale Währung (cloud_1000_ccus)

  • Legt fest, wie viel 1000 CCUS (Cloud Computing Units) in einer zuvor festgelegten realen Währung entsprechen sollen.

Ressourcenzuordnung für Gruppen (resource_pooling)

  • Legt fest, von welchem Host eine bestimmte Benutzergruppe ihre virtuellen Maschinen erhalten darf.

Produkte für openQRM Cloud anlegen

Um unseren Nutzern Cloud Ressourcen über das Cloud-Portal bereitzustellen, müssen vorab Produkte ausgewählt werden, welche über die Konfiguration einer virtuellen Maschine bestimmen. Die Einstellungen dafür nehmen wir unter „Plugin > Cloud > Configuration > Products“ vor.

Unter der „Cloud Produkt Verwaltung“ lassen sich verschiedene Produkte erstellen, die später unter dem Cloud-Portal von dem Nutzer eigenständig zu vollständigen virtuellen Maschinen zusammengebaut werden können. Zu den Produkten die uns dabei zur Verfügung stehen gehören:

  • Anzahl der CPUs
  • Größe der lokalen Festplatte
  • Größe des Arbeitsspeichers
  • Der Typ des Kernel
  • Die Anzahl der der Netzwerkkarten
  • Vorinstallierte Applikationen
  • Typ der Virtualisierung
  • Ob eine virtuelle Maschine hochverfügbar sein soll

Über die Statuszeile können mit +/- die jeweiligen Produkte aktiviert bzw. deaktiviert werden und damit dem Nutzer im Cloud-Portal angezeigt oder vor ihm versteckt werden.

Bitte beachten: Produkte die deaktiviert werden, aber noch innerhalb von virtuellen Maschinen aktiv sind, werden weiterhin abgerechnet.

Um nun ein neues CPU Produkt zu erstellen wählen wir den Reiter „CPU“ und bestimmen in dem Bereich „Hinzufügen eines CPU Produkts“ unsere gewünschten Parameter.

Der erste Parameter bestimmt, wie viele CPUs (Kerne), hier 64, unser Produkt haben soll. Über den zweiten Parameter legen wir fest, welchen Wert dieses Produkt hat und wie viele Kosten entsprechend während seiner Nutzung pro Stunde entstehen. In diesem Beispiel entstehen Kosten von 10 CCUs pro Stunde für 64 CPUs.

Anhand der Pfeiltasten lässt sich die Reihenfolge bestimmen, wie die einzelnen Produkte im Cloud-Portal angezeigt werden. Der Default-Wert ist der an obiger Stelle.

Bitte beachten: Im Cloud-Portal existieren Standard-Profile in den Größen „Small“, „Medium“ und „Big“. Die Profile werden automatisch entsprechend der Reihenfolge unter den jeweiligen Produkten bestimmt. Das bedeutet Small nimmt immer den ersten Wert, Medium den Zweiten und Big den Dritten.

openQRM erlaubt es ebenfalls, die virtuellen Maschinen mit vorkonfigurierten Softwarestacks zu bestellen. Dazu greift openQRM auf Puppet (Plugins > Deployment > Puppet) zurück. Damit ist es möglich zum Beispiel den bekannten LAMP-Stack zu bestellen.

Haben wir unsere Produktpalette fertig konfiguriert, ist der Nutzer an der Reihe, sich seine virtuellen Maschinen zu bestellen. Das erfolgt über das Cloud-Portal.

openQRM Cloud-Portal

Für das Erstellen einer neuen virtuellen Maschine (VM) klicken wir im Reiter auf „Neu“. Es
erscheint die Eingabemaske, in der wir unsere VM anhand der Produkte, die der
Administrator im Admin-Backend festgelegt und freigegeben hat, erstellen können.

Wir entscheiden uns für das Profil „Gross“ und einem LAMP-Server. Unsere virtuelle Maschine besteht damit aus den folgenden Produkten:

  • TYP: KVM-Storage VM
  • RAM: 1 GB
  • CPU: 64 Kerne
  • Festplatte: 8 GB
  • Netzwerkkarte: 1

Darüber hinaus soll diese virtuelle Maschine „Hochverfügbar“ sein. Das bedeutet, wenn diese ausfallen sollte, wird automatisch eine Ersatzmaschine mit exakt derselben Konfiguration hochgefahren, mit der man weiterarbeiten kann.

Für diese Konfiguration werden uns Kosten in Höhe von 35 CCUs pro Stunde entstehen. Das entspricht 0,04Euro pro Stunde bzw. 0,84Euro pro Tag oder 26,04Euro pro Monat.

Wollen wir die virtuelle Maschine bestellen, wählen wir „absenden“.

Unter dem Reiter „Aufträge“ sehen wir alle aktuellen und vergangenen Bestellungen, die wir mit unserem Benutzer getätigt haben. Der Status „active“ in der ersten Spalte zeigt, dass die Maschine bereits hochgefahren ist.

Parallel dazu erhalten wir eine E-Mail mit der IP-Adresse, einem Benutzernamen und Passwort, über die wir uns an der virtuellen Maschine anmelden können.

Der Reiter „Systeme“ bestätigt uns beide Informationen noch einmal und zeigt weitere Informationen zu der virtuellen Maschine. Darüber hinaus haben wir die Möglichkeit, Änderungen an der Systemkonfiguration vorzunehmen, die virtuelle Maschine in den Ruhezustand zu setzen oder neu zu starten. Weiterhin ist der Login über eine Web-Shell möglich.

Die virtuelle Maschine kann, wenn sie nicht mehr benötigt wird pausiert werden. Alternativ besteht die Möglichkeit, dass der Administrator dieses zum Beispiel anhand einer Inaktivität des Systems oder zu einer bestimmten Uhrzeit veranlasst.

Virtuelle Maschine mit dem „Visual Cloud Designer“ erstellen

Neben dem „gewöhnlichen“ zusammenbauen einer virtuellen Maschine, ermöglicht das openQRM Cloud-Portal es dem Benutzer, dieses bequem per Drag-and-Drop zu erledigen. Dabei hilft der „Visual Cloud Designer“, der unter dem Reiter „VCD“ zu finden ist.

Mit dem Schieberegler unter „Cloud Components“ lässt sich zwischen den Produkten auf der linken Seite hin und her scrollen. Mit der Maus lässt sich die „Cloud Appliance“ (virtuelle Maschine) in der Mitte mit den entsprechenden Produkten bestücken.

Unsere virtuelle Maschine „Testosteron“ haben wir in diesem Fall also mit einem KVM-Storage, Ubuntu 12.04, 64 CPUs, 1024 MB Ram, 8 GB Festplatte, einer Netzwerkkarte, Software für einen Webserver und mit der Eigenschaft Hochverfügbarkeit ausgestattet.

Mit einen Klick auf „Check Costs“, sagt uns openQRM, dass wir für diese Konfiguration 0,03 EUR pro Stunde bezahlen würden.

Um den Bestellvorgang für die virtuelle Maschine zu starten klicken wir auf „Request“. Wir erhalten die Meldung, dass openQRM mit dem Ausrollen der Ressource beginnt und wir weitere Informationen im Postfach haben.

Die E-Mail enthält wie bereits oben beschrieben, sämtliche Zugangsdaten, um mit der virtuellen Maschine zu arbeiten.

Im Cloud-Portal unter „Systeme“, sehen wir dann auch bereits die gestartete virtuelle Maschine.

Virtuelle Maschine mit dem „Visual Infrastructure Designer“ erstellen

Neben der Bereitstellung einzelner virtueller Maschinen bietet das openQRM Cloud-Portal zudem die Möglichkeit, vollständige Infrastrukturen, bestehend aus mehreren virtuellen Maschinen und weiteren Komponenten, mit einem Klick bereitzustellen.

Dafür greifen wir auf den „Visual Infrastructure Designer“ zurück. Dieser ist im Cloud-Portal unter dem Reiter „VID“ zu finden.

Über den „VID“ lässt sich per Drag and Drop eine vollständige WYSIWYG Infrastruktur zusammenbauen und direkt ausrollen. Hierzu müssen anhand des „VCD“ oder auf normalem Weg jedoch zunächst fertige Profile mit vorkonfigurierten virtuellen Maschinen z.B. Webserver, Router, oder Gateways erstellt werden, die anschließend provisioniert werden können.

Kategorien
Kommentar

VMware ist NICHT der Technologie-Enabler der Cloud

In einem vor kurzem erschienen Interview hat sich ein VMware Mitarbeiter zu der für mich sehr vagen und fragwürdigen Aussage „VMware ist der Technologie-Enabler der Cloud, und ich sehe derzeit keinen anderen.“ hinreißen lassen. Ohne VMware zu nahe treten zu wollen, klingt dieser Satz für mich schon sehr stark nach Selbstüberschätzung und gleicht einem Realitätsverlust. Es steht außer Frage, dass VMware der König der Virtualisierung ist, aber zu behaupten dass im Cloud-Umfeld nichts ohne sie funktionieren würde, ist schon sehr anmaßend.

Reality distortion field

Steve Jobs hat es entwickelt, das „Reality distortion field„. Die Eigenschaft jemanden davon überzeugen zu können, was überhaupt nicht stimmt und die Fakten so zu verdrehen, dass es am Ende so aussieht, als ob es seine eigene Idee war. Zum Glück behauptet VMware nicht, dass sie das Cloud Computing erfunden hätten, das wäre dann kein Realitätsverlust, sondern Größenwahn.

Virtualisierung ist kein Cloud Computing

Es ist schon sehr anmaßend zu behaupten, man sei der Technologie-Gott der Cloud. Man überlege mal was VMware tatsächlich als Basis für die Cloud liefert. Es ist die Virtualisierung, also der Hypervisor. Natürlich, Virtualisierung ist eine der wichtigsten Grundlagen für die Cloud. Aber es gehört viel mehr dazu, um die virtuellen Ressourcen zu provisionieren und zu nutzen.

Bleiben wir beim Hypervisor, ist nicht abzustreiten, dass VMware der Marktführer ist. Hier machen sie einen guten Job. Man sollte dennoch nicht vergessen das die Amazon Web Services und Rackspace den Open-Source Hypervisor XEN einsetzen. Die HP Cloud verlässt sich genau so wie die Google Compute Engine auf KVM.

Die echten Player im Cloud Computing Markt setzen also eben nicht auf VMware. Daher kann von VMware als Technologie-Enabler der Cloud überhaupt keine Rede sein.

Darüber hinaus sollte man nicht die vielen anderen Technologie-Anbieter wie openQRM, OpenStack, CloudStack, Eucalyptus, Microsoft usw. vergessen, die Unternehmen dabei helfen Infrastrukturen für die Public als auch Private Cloud aufzubauen. VMware ist sicherlich ein Anbieter, der mittlerweile auch versucht sein Stück vom Kuchen in der Cloud abzubekommen. Aber unterm Strich sind sie auch nur einer von vielen und müssen sich wie jeder andere tagtäglich behaupten.

–

Ich weiß das ich mir mit diesem Artikel keine Freunde bei VMware machen werde. Aber so eine untragbare Behauptung kann ich nicht einfach so im Internet stehen lassen, tut mir leid VMware!

Kategorien
Management

Professionelle Open-Source Lösungen für die eigene Cloud

Ich hatte vor längerer Zeit in dem Artikel „Die eigene Cloud bauen mit… – CloudWashing par excellence!“ die leichtfertige Aussage eines Journalisten kritisiert, dass man auf einfache Weise eine eigene Cloud Umgebung aufbauen kann. Das dem so nicht ist und worauf zu achten ist, habe ich in dem Artikel ebenfalls erläutert. Dennoch existieren natürlich Lösungen, die dabei helfen, eine eigene Cloud aufzubauen. Tatsächlich gibt es derzeit aber nur fünf Open-Source Lösungen, die für den professionellen Aufbau von Cloud Computing Umgebungen eingesetzt werden sollten. Dazu gehören openQRM, Eucalyptus, OpenStack, CloudStack und OpenNebula.

Grundlegendes! Bitte lesen!

Viele Unternehmen entscheiden sich vermehrt für den Aufbau einer eigenen (Private) Cloud, um die Kontrolle über Ressourcen, Daten, Sicherheit usw. zu behalten. Richtig ist, dass eine eigene Cloud die Agilität eines Unternehmens verbessert und die Systeme bis zu einem gewissen Grad skalieren können. Allerdings sollte sich ein Unternehmen immer bewusst machen, das die Skalierbarkeit einer eigenen Cloud einem manuellen Prozess gleicht. Bei diesem muss in Echtzeit auf Ressourcenengpässe durch das eigene Personal reagiert werden, indem weitere Hardwarekomponenten in Form von Speicherplatz, Arbeitsspeicher oder Rechenleistung nachgerüstet werden. Für jede virtuelle Instanz wird schließlich auch die physikalische Hardware benötigt. Neben Hardware- und Softwareressourcen sind Tools zum Echtzeit-Monitoring der Umgebung daher unerlässlich.

Hardware, Hardware, Hardware

Eine eigene Cloud bedarf also Unmengen an physikalischen Ressourcen um den Wunsch nach Flexibilität und quasi unendlichen virtuellen Ressourcen zu befriedigen. Heißt im Umkehrschluß daher für Unternehmen mit einer eigenen Cloud: Investieren, das eigene Rechenzentrum umbauen und Cloud-fähig zu machen.

Es ist ein Irrglaube, wenn man denkt, dass der Aufbau einer eigenen Cloud impliziert, sich anschließend nicht mehr um die Hochverfügbarkeit der eigenen Infrastruktur (physikalische Maschinen, virtuelle Maschinen, Master-Slave-Replikation, Hot-Standby, etc.) kümmern zu müssen. Das macht dann ja schließlich die Cloud alleine.

Konfigurieren, Skripte, Intelligenz

Eine Cloud funktioniert nicht von alleine. Sie muss entwickelt und mit Intelligenz ausgestattet werden. Das gilt für den Aufbau einer Private Cloud genau so wie für die Nutzung eines Public Cloud Angebots (im Falle von IaaS). Dazu müssen Skripte geschrieben, womöglich Software neu entwickelt werden, die auf der Cloud verteilt läuft. Weiterhin ist es wichtig, die Whitepaper des Anbieter zu lesen, KnowHow(!) aufzubauen und zu verstehen, wie die Cloud arbeitet, um sie für die eigenen Bedürfnisse nutzen zu können. Eine weitere Möglichkeit besteht natürlich darin, sich (zusätzlich) von Profis beraten zu lassen. Das ist bei der Nutzung einer eigenen Cloud nicht anders. Wenn eine virtuelle Maschine A ein Problem hat, dann kann sie plötzlich nicht mehr erreichbar sein, wie jeder normale physikalische Server nun einmal auch. Nun könnte man denken: “Dann nehme ich als Backup für virtuelle Maschine A halt noch eine virtuelle Maschine B dazu!” Und dann? Man könnte nun denken, dass die virtuelle Maschine B automatisch die Aufgaben der virtuelle Maschine A übernimmt. So einfach ist das aber nicht! Skripte müssen vorab dafür sorgen, dass die virtuelle Maschine B die Aufgaben von virtuelle Maschine A übernehmen soll, wenn diese plötzlich nicht mehr erreichbar ist. Auch die virtuelle Maschine B muss dafür zunächst vorbereitet werden. Dazu kann z.B. der eigentliche (wichtige) Inhalt der virtuelle Maschine A inkl. aller Konfigurationen etc. in einem zentralen Speicher und nicht auf dem lokalen Speicher abgelegt werden. Anschließend muss ein Skript dafür sorgen, dass die virtuelle Maschine B automatisch mit den Konfigurationen und allen Daten aus dem lokalen Speicher hochgefahren wird, wenn die virtuelle Maschine A nicht mehr verfügbar ist.

Virtuelles Rechenzentrum

Die Cloud gibt uns im Bereich Infrastructure as a Service letztendlich nur die Möglichkeit, aus einem quasi unendlich großen Pool von Ressourcen die (unendliche) Anzahl an Ressourcen zu dem Zeitpunkt zu bekommen, wenn wir sie benötigen. Wir erhalten von der Cloud somit ein eigenes hochskalierbares virtuelles Rechenzentrum. Das bedeutet aber im Umkehrschluss für den Betreiber einer Cloud (Private, Public), dass er ebenfalls die Menge an physikalischen Ressourcen vorhalten muss, damit die angefragten virtuellen Ressourcen jederzeit bereitgestellt werden können und damit immer ausreichend Ressourcen für die Nutzer zur Verfügung stehen.

Open-Source Lösungen für den Aufbau einer eigenen Cloud

openQRM

openQRM ist eine Open Source Cloud Computing Plattform für die Verwaltung von Rechenzentren und skalierbaren IT-Infrastrukturen und ist aktuell in der Version 5.0 verfügbar. Mittels einer zentralen Managementkonsole kann die Administration von physikalischen Servern ebenso vorgenommen werden wie von virtuellen Maschinen, wodurch Rechenzentren voll automatisiert und höchst skalierbar betrieben werden können. Neben einer offenen API und einem SOAP Web Service für die nahtlose Integration der eigenen Geschäftsprozesse, unterstützt openQRM alle bekannten Virtualisierungstechnologien und bietet die Möglichkeit für transparente Migrationen von „P-to-V“, „V-to-P“ und „V-to-V“.

openQRM verfügt des Weiteren über ein integriertes Storage-Management, mit dem anhand des Snapshot-Verfahrens Serversysteme dupliziert werden können. Die Snapshots ermöglichen eine dynamische Anpassung des Speicherplatzes, bieten einen persistenten Cloud-Speicher und erlauben ein Backup/Restore der Server sowie deren Versionierung.

Mit der „N-zu-1“ Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Dabei spielt es keine Rolle, ob physikalische oder virtuelle Maschinen eingesetzt werden!

Benefits auf einem Blick

Virtualisierung

openQRM unterstützt alle gängigen Virtualisierungstechnologien darunter VMWare, Citrix XenServer und KVM und bietet die Möglichkeit der Migration von P-to-V-, V-to-P- und V-to-V für physikalische Server als auch virtuelle Maschinen.

Storage

openQRM verfügt über ein zentralisiertes Speichersystem mit integriertem Storage Management, welches alle bekannten Storage-Technologien unterstützt. Dazu gehören u.a. Netapp, Equallogic, NFS, iSCSI ZFS und proprietäre auf LVM basierende Storage-Typen, für eine flexible und schnelle Duplizierung von Serversystemen.

Zentrales Management

openQRM verschmilzt die Welt von Open Source mit der von kommerziellen Produkten. Mit einer zentralen Managementkonsole sind alle Funktionen zur Administration von Rechenzentren, System- und Service-Überwachung, Hochverfügbarkeit und automatisierter Bereitstellung vorhanden.

Funktionen

Hardware/Software Isolation

openQRM isoliert die Hardware (physikalische Server, virtuelle Maschinen) vollständig von der Software (Server Images). Dabei ist die eigentliche Hardware eine „Computing Resource“ und kann dadurch jederzeit durch eine andere Hardware ersetzt werden, ohne dass die Software (Server Image) neu konfiguriert werden muss.

Unterstützung für verschiedene Virtualisierungs-Technologien

Mit VMWare, Xen, KVM und dem Citrix XenServer unterstützt openQRM eine viehlzahl an virtuellen Maschinen und kann dieses transparent verwalten und migrieren. Neben der System-Migration von physikalischen Servern zu virtuellen Maschinen (P-to-V) können Systeme ebenfalls von virtuellen Maschinen zu physikalischen Servern (V-to-P) migriert werden. Darüber hinaus besteht die Möglichkeit ein System von einer Virtualisierungstechnologie zu einer anderen Virtualisierungstechnologie (V-to-V) zu verschieben.

Vollautomatische Nagios-Konfiguration

openQRM unterstützt die vollautomatische Konfiguration von Nagios mittels „nmap2nagios-ng“. Damit wird das gesamte openQRM Netzwerk analysiert und auf Basis der Informationen eine Nagios-Konfiguration erstellt. Anschließend werden alle Services auf allen Systemen überwacht.

Integriertes Storage-Management

openQRM organisiert die Serversysteme wie Dateien und nutzt zur Verwaltung moderne Storagesysteme anstatt lokaler Festplatten. Mittels Logical Volume Managern (LVM) und deren Snapshot-Verfahren können Server-Templates auf schnellen Wege dupliziert werden.

„Sollen z.B. 10 neue Server ausgerollt werden, kann so einfach ein bestehendes Server-Image 10 mal dupliziert und die „Clone“ direkt zum Deployment bereitgestellt werden.“

Mit diesem Konzept steht ein zentrales Backup/Restore sowie die Möglichkeit von Hot-Backups ohne Downtime zur Verfügung.

openQRM unterstützt folgende Storage-Typen:

  • NFS (NAS)
  • iSCSI (iSCSI SAN)
  • Aoe/Coraid (AOE SAN)
  • NetApp (iSCSI SAN)
  • Local-disk (Übertragung von Server-Images auf lokale Festplatten)
  • LVM-Nfs (NFS auf LVM2, erlaubt schnelles Cloning)
  • LVM-iSCSI (iSCSI auf LVM2, erlaubt schnelles Cloning)
  • LVM-Aoe (Aoe auf LVM2, erlaubt schnelles Cloning)
  • Equallogic (iSCSI SAN)
  • ZFS (iSCSI SAN)

Hochverfügbarkeit und „N-to-1“-Fail-Over!

Mit der „N-zu-1“ Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Unabhängig davon, ob physikalische oder virtuelle Maschinen eingesetzt werden.

„Um zum Beispiel 10 hochverfügbare Spezialsysteme zu betreiben benötigt man normalerweise weitere 10 „Stand-By“-Systeme. Mit openQRM jedoch benötigt man nur einen einzigen „Stand-By“-Server, der im Fehlerfall eines der 10 Spezialsysteme benutzt wird. Das heißt, man kann 9 „stromfressende“, nicht ausgelastete Server einsparen. Perfekt für „Green IT“.

Des Weiteren können physikalische Server virtuelle Maschinen als „Hot Stand-By“ nutzen und lassen sich im Notfall in eine virtuelle Maschine migrieren.

Fertige Server-Templates

Mittels dem „Image-Shelf“-Plugin stellt openQRM bereits fertige Server Templates zur Verfügung. Dazu gehören Linux Distributionen wie Debian, Ubuntu, CentOS und openSuse. Des Weiteren können mit dem Plugin eigene Server Templates auf unterschiedliche Weise (lokal, http, https, ftp) bereitgestellt werden.

Unterstützung verschiedenster Deployment-Methoden

Mit openQRM können Server von jeder Art von Storage gestartet werden. Zusätzlich können die Server Templates von einem Storage-Typ zu einem anderen übertragen werden, dabei kann noch entschieden werden, ob die Server Templates auf einem physikalischen Server oder in einer virtuellen Maschine gestartet werden sollen.

Unterstützung verschiedener OS-Distributionen

Es stehen bereits vor-konfigurierte openQRM-Server Pakete für Debian, Ubuntu und CentOS zur Verfügung. Ein openQRM-Server kann aber alle gängigen Linux Distributionen verwalten.

Cloud-Selector

Mit dem Cloud-Selector kann der Cloud Administrator seine Cloud Produkte wie z.B. Prozessoren, Speicher, Festplattengröße oder den Typ der virtuellen Maschine auswählen und deren Preise festlegen.

Kostenrechner im Cloud-Portal

Die Cloud-Computing-Unit (CCU) kann einer regulären Währung (z.b. USD oder Euro) zugewiesen werden. Mit dem Kostenrechner werden die stündlichen, täglichen und monatlichen verbrauchten Kosten für eine Cloud Appliance berechnet.

Private Cloud Images

Mit der „Private Cloud Image“-Funktion können Cloud Benutzer eigene Server Templates anlegen und verwalten.

Volle SSL-Unterstützung

Der openQRM-Server arbeitet in einem vollständig SSL-verschlüsselten Bereich und unterstützt verschiedene Serverarchitekturen wie i386 und x86_64.

Ich möchte hier noch anmerken, dass es sich bei der openQRM Enterprise um einen deutschen Anbieter aus dem Bereich des Cloud Computing handelt!

Eucalyptus

Beim Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems (Eucalyptus) handelt es sich um eine Open Source Software Infrastruktur zum Aufbau von skalierbaren Utility Computing bzw. Cloud Computing Umgebungen für spezielle Clustersysteme oder einfachen miteinander verbundenen Arbeitsplatzrechnern.

Eucalyptus wurde als ein Forschungsprojekt am Computer Science department an der University of California Santa Barbara entwickelt und wird mittlerweile von der Eucalyptus Systems Inc. vermarktet. Die Software wird aber weiterhin als Open Source Projekt gepflegt und weiterentwickelt. Die Eucalyptus Systems Inc. bietet darüber hinaus lediglich weitere Dienstleitungen und Produkte sowie einen professionellen Support rund um Eucalyptus an.

Folgende Funktionen stellt Eucalyptus bereit:

  • Kompatibilität mit den Schnittstellen zu Amazon EC2 und S3 (SOAP und REST).
  • Unterstützung aller Virtual Machines die auf einem Xen Hypervisor oder einer KVM ausgeführt werden.
  • Administrationstools für die System- und Benutzerverwaltung.
  • Die Möglichkeit mehrere Cluster für eine Cloud zu konfigurieren, wobei jeder einzelne Cluster über eine private interne IP-Adresse verfügt.

Architektur

Eucalyptus besteht aus fünf zusammenarbeitenden Hauptkomponenten um den angeforderten Cloud Service bereit zu stellen. Die Kommunikation zwischen den Komponenten erfolgt über gesicherte SOAP Nachrichten mittels WS-Security.

Cloud Controller (CLC)

Der Cloud Controller dient innerhalb einer Eucalyptus Cloud als Hauptkomponente für die Verwaltung des gesamten Systems und stellt den Administratoren und Benutzern einen zentralen Zugriffspunkt bereit. Die Kommunikation aller Clients mit dem Eucalyptus System erfolgt ausschließlich nur über den Cloud Controller anhand der auf SOAP oder REST basierenden API. Der Cloud Controller ist dafür zuständig, alle Anfragen zu der richtigen Komponente weiterzuleiten, diese zu sammeln und die Antwort der Komponente anschließend wieder zu dem Client zurück zu senden. Der Cloud Controller ist somit die öffentliche Schnittstelle einer Eucalyptus Cloud.

Cluster Controller (CC)

Der Cluster Controller ist innerhalb des Eucalyptus Systems für die Verwaltung des virtuellen Netzwerks zuständig. Der Cloud Controller erhält alle Anfragen auf Basis seiner SOAP oder REST Schnittstellen. Der Cloud Controller erhält alle Informationen über die vorhandenen Node Controllers des Eucalyptus Systems und ist für die Kontrolle des Lebenszyklus jedes einzelnen verantwortlich. Er leitet alle Anfragen an die Node Controller mit verfügbaren Ressourcen weiter um damit virtuelle Instanzen zu starten.

Node Controller (NC)

Ein Node Controller steuert das Betriebssystem und den zugehörigen Hypervisor eines Rechners (Node) im Eucalyptus System. Auf jeder physikalischen Maschine die eine durch den Cluster Controller instantiierte virtuelle Instanz auf Grund einer Anfrage beherbergt, muss eine Instanz eines Node Controller vorhanden sein.

Walrus (W)

Walrus ist für die Zugriffsverwaltung auf den Speicherdienst innerhalb eines Eucalyptus Systems zuständig. Walrus erhält die Anfragen über seine SOAP oder REST Schnittstelle.

Storage Controller (SC)

Der Storage Controller verwaltet den Speicherdienst innerhalb eines Eucalyptus Systems und verfügt über eine Schnittstelle zu Amazon’s S3 Dienst. Der Storage Controller arbeit in Verbindung mit Walrus und wird für die Speicherung und den Zugriff auf die Images der Virtual Machines, die Kernel Images, die RAM Disk Images und die Daten der Benutzer verwendet. Die Images der Virtual Machines können rein privat oder öffentlich zugänglich gemacht werden und können dabei komprimiert und verschlüsselt gespeichert werden. Die Images werden lediglich entschlüsselt, wenn ein Node eine neue virtuelle Instanz starten muss und dazu einen Zugriff auf das Image benötigt.

Das Clustersystem

Ein Eucalyptus System vereint und verwaltet Ressourcen von Single-Cluster als auch Multi-Cluster Systemen. Dabei besteht ein Cluster aus einer Gruppe von Rechnern, die alle mit dem selben LAN verbunden sind. Zu jedem Cluster kann wiederum einer aber auch mehrere Node Controller gehören, die für die Verwaltung der Instantiierung und Beendigung der virtuellen Instanzen verantwortlich sind.

Ein Single-Cluster besteht aus mindestens zwei Maschinen. Auf dem einen werden der Cluster Controller, der Storage Controller und der Cloud Controller ausgeführt, auf dem anderen der Node Controller. Diese Art der Konfiguration ist vor allem für Experimente und schnelle Konfigurationen geeignet. Die dargestellte Konfiguration könnte ebenfalls auf einer einzigen Maschine implementiert werden. Allerdings ist dafür eine äußerst leistungsstarke Hardware notwendig!

Bei einem Multi-Cluster wird jede Komponente (CC, SC, NC, und CLC) auf einer separaten Maschine ausgeführt. Dies sollte die bevorzugte Art und Weise sein das Eucalyptus System zu konfigurieren, wenn damit ernsthaft gearbeitet werden soll. Mit einem Multi-Cluster kann zudem die Performance erhöht werden, indem einem Controller die passende Maschine zugewiesen wird. Zum Beispiel sollte der Cloud Controller auf einer Maschine mit einer schnellen CPU ausgeführt werden. Im Allgemeinen bringt die Entscheidung für einen Multi-Cluster eine höhere Verfügbarkeit, sowie eine bessere Lastverteilung und eine optimierte Verteilung der Ressourcen über alle Cluster. Das Clusterkonzept ist vergleichbar mit dem Konzept der Verfügbarkeitszonen der Amazon EC2. Dabei werden die Ressourcen über mehrere Verfügbarkeitszonen hinweg verteilt, damit ein Fehler in einer Zone nicht die Anwendung beeinträchtigt.

Eucalyptus und die Ubuntu Enterprise Cloud

Bei der Ubuntu Enterprise Cloud (UEC) handelt es sich um eine Open Source Initiative von Ubuntu, um auf eine einfachere Art und Weise skalierbare Cloud Infrastrukturen auf Basis von Eucalyptus bereitzustellen und diese zu konfigurieren.

Mit der Ubuntu Enterprise Cloud können Public Clouds erstellt werden, welche Amazon’s EC2 infrastructure nutzen. Es können damit aber genau so gut Private Clouds entwickelt werden, die auf der eigenen Infrastruktur im eigenen Rechenzentrum hinter der eigenen Firewall gehostet werden.

Vorteile von Eucalyptus

Bei Eucalyptus handelt es sich um eine Umgebung für Cloud Services, mit der Public Clouds auf Amazon’s EC2 Infrastruktur bzw. Private Clouds im hauseigenen Rechenzentrum erstellt werden können. Die grundlegenden Vorteile sollen hier noch einmal kurz aufgeführt werden:

  • Open Source und Entwicklung
    Eucalyptus wurde geschaffen, um die Kommunikation und Forschung von Cloud Computing Plattformen zu fördern. Der Quellcode ist frei verfügbar, was es ermöglicht die Plattform so zu erweitern, damit sie den eigenen Anforderungen entspricht. Eucalyptus wird zunehmend weiterentwickelt. Darüber hinaus ist die Aufnahme und Integration von Funktionswünschen und Verbesserungsvorschlägen sehr schnell.
  • Community
    Eucalyptus verfügt über eine große Community die gerne bereit ist einander zu helfen. Über die Foren kann schnell Kontakt zu anderen Benutzern aufgenommen und Hilfe bezogen werden.
  • Public Cloud
    Eucalyptus funktioniert einwandfrei auf Amazon’s EC2 Framework und kann damit als Public Cloud eingesetzt werden.
  • Private Cloud
    Eucalyptus kann auf der eigenen Infrastruktur im eigenen Rechenzentrum hinter der eigenen Firewall als Private Cloud eingesetzt werden. Dadurch ist die Kontrolle bzgl. der Sicherheit und der gesamten Umgebung in der eigenen Hand.
  • Portabilität
    Auf Grund der Kompatibilität von Eucalyptus mit Amazon’s EC2 API sowie der Flexibilität von Eucalyptus, können Anwendungen ohne großen Aufwand von einer Cloud in die andere migriert werden. Darüber hinaus besteht die Möglichkeit des Aufbaus von Hybrid Clouds, indem eine Private Cloud mit einer Public Cloud erweitert bzw. kombiniert wird.
  • Qualitativ durch Tests
    Durch den Einsatz von Eucalyptus in Ubuntu’s Enterprise Cloud findet tagtäglich ein weltweiter realer Test auf Basis von mehr als tausend Server-Instanzen statt.
  • Kommerzieller Support
    Neben den Foren der Eucalyptus Community kann natürlich auch auf einen kommerziellen Support zurückgegriffen werden.

Open Nebula

OpenNebula ist ein Open Source Virtual Infrastructure Manager mit dem aus vorhandenen Rechenzentren jede Art von Cloud Computing Umgebung aufgebaut und bereitgestellt werden kann. In erster Linie dient OpenNebula als Tool zur Verwaltung der virtualisierten Infrastruktur des eigenen Rechenzentrums bzw. der eigenen Cluster, also der eigenen Private Cloud.

Darüber hinaus ist OpenNebula in der Lage Hybrid Clouds aufzubauen, also die eigene lokale Infrastruktur mit einer Public Cloud Infrastruktur zu verbinden/kombinieren, um die Skalierbarkeit der eigenen Umgebung noch weiter zu erhöhen. OpenNebula verfügt zusätzlich über spezielle Schnittstellen für die Verwaltung von virtuellen Maschinen, Speicherplatz und des Netzwerks von Public Clouds.

Funktionen

Private Cloud Computing

  • Internal Interfaces for Administrators and Users
    Mit einer Unix ähnlichen Kommandozeile und einer XML-RPC API kann der Lebenszyklus der virtuellen Maschinen und physikalischen Server verwaltet werden. Weitere Administrationsmöglichkeiten bietet die libvirt API.
  • Steuerung
    Die Verwaltung der Arbeitslast und Zuweisung der Ressourcen kann nach bestimmten Regeln wie z.B. der aktuellen Auslastung automatisch vorgenommen werden. Des Weiteren wird der Haizea VM-based lease manager unterstützt
  • Virtualisierungsmanagement
    Es existieren Konnektoren für Xen, KVM und VMware, sowie einem generischen libvirt Konnektor für weitere Virtual Machine Manager. Die Unterstützung von Virtual Box ist in Planung.
  • Image Management
    Es sind Funktionen für den Transfer und das Clonen von Virtual Machine Images vorhanden.
  • Netzwerk Management
    Es lassen sich isolierte virtuelle Netze festlegen um virtuelle Maschinen miteinander zu verbinden.
  • Service Management
    Unterstützung von Multi Tier Services bestehend aus Gruppen von miteinander verbundenen virtuellen Maschinen und deren Auto Konfiguration während des Boot Vorgangs.
  • Sicherheit
    Die Verwaltung der Benutzer wird durch den Administrator der Infrastruktur vorgenommen.
  • Fehlertoleranz
    Eine persistente Datenbank dient zum Speichern aller Informationen der Hosts und virtuellen Maschinen.
  • Skalierbarkeit
    Tests zeigten bisher, das OpenNebula mehrere hundert Server und virtuelle Maschinen verwalten kann.
  • Installation
    Die Installation erfolgt auf einem UNIX Cluster Front-End ohne das weitere Services benötigt werden. OpenNebula wird mit Ubuntu 9.04 (Jaunty Jackalope) ausgeliefert.
  • Flexibilität und Erweiterbarkeit
    Die Architektur, Schnittstellen und Komponenten sind offen, flexibel und erweiterbar. Dadurch kann OpenNebula mit jedem aktuellen Produkt aus dem Bereich Virtualisierung, Cloud Computing oder Management Tool für Rechenzentren integriert werden.

Hybrid Cloud Computing

  • Cloud Plugins
    Konnektoren für Amazon EC2 und ElasticHosts.
  • Zusammenschluss
    Unterstützung für den gleichzeitigen Zugriff auf mehrere Remote-Clouds.
  • Erweiterbarkeit
    Modulare Konzepte für die Entwicklung neuer Konnektoren.

Public Cloud Computing

  • Cloud Schnittstellen für Benutzer
    Implementierung einer Teilmenge der Amazon EC2 Query API und der OGF OCCI API
  • Erweiterbarkeit
    Die OpenNebula Cloud API ermöglicht die Implementierung neuer/weiterer Cloud Schnittstellen.

OpenStack

OpenStack ist ein weltweites Gemeinschaftsprojekt von Entwicklern und Cloud Computing Spezialisten, die das Ziel verfolgen eine Open Source Plattform für den Aufbau von Public und Private Clouds zu entwickeln. Das Projekt wurde initial von der Nasa und Rackspace gegründet und will Anbietern von Cloud Infrastrukturen ein Werkzeug in die Hand geben, mit dem sie unterschiedliche Arten von Clouds ohne großen Aufwand auf Standard Hardwarekomponenten aufbauen und bereitstellen können.

Der gesamte OpenStack Quellcode ist frei verfügbar und unterliegt der Apache 2.0 Lizenz. Dadurch ist jeder in der Lage auf dieser Basis seine eigene Cloud zu entwickeln und ebenfalls Verbesserungen in das Projekt zurückfließen zu lassen. Der Open Source Ansatz des Projekts soll zudem die Entwicklung von Standards im Bereich des Cloud Computing weiter fördern, Kunden die Angst vor einem Vendor Lock-in nehmen und ein Ecosystem für Cloud Anbieter schaffen.

OpenStack besteht derzeit aus insgesamt sechs Kernkompenten und wird stetig weiterentwickelt. OpenStack Compute, OpenStack Object Storage und OpenStack Image Service, OpenStack Identity, OpenStack Dashboard und OpenStack Networking.

Man muss sich allerdings darüber im Klaren sein, dass es sich bei OpenStack um kein fertiges Produkt handelt, das sofort einsatzfähig ist, sondern um einzelne Teilprojekte die selbst ineinander integriert und für die eigenen Bedürfnisse angepasst werden müssen. Es gibt aber mittlerweile fertige OpenStack Installationsroutinen von Mitgliedern des OpenStack Projekts.

OpenStack Compute

OpenStack Compute dient dem Aufbau, Bereitstellen und Verwalten von großen Virtual Machine Clustern, um auf dieser Basis eine redundante und skalierbare Cloud Computing Plattform zu errichten. Dazu stellt OpenStack Compute diverse Kontrollfunktionen und APIs zur Verfügung, mit denen Instanzen ausgeführt und Netzwerke verwaltet werden sowie die Zugriffe der Nutzer auf die Ressourcen gesteuert werden können. OpenStack Compute unterstützt zudem eine große Anzahl von Hardwarekonfigurationen und sieben Hypervisor.

OpenStack Compute kann bspw. Anbietern dabei helfen Infrastructure Cloud Services bereitzustellen oder IT-Abteilungen ermöglichen ihren internen Kunden und Projekten Ressourcen bei Bedarf zur Verfügung zu stellen. Zudem können große Datenmengen (Big Data) mit Tools wie Hadoop verarbeitet werden oder Web Anwendungen entsprechend ihrer Ressourcenbedürnisse bedient werden.

OpenStack Object Storage

Mit OpenStack Object Storage können auf Basis von standardisierten Servern redundante und skalierbare Object Storage Cluster mit einer Größe von bis zu 1 Petabyte aufgebaut werden. Dabei handelt es sich nicht um ein Dateisystem und ist nicht für das Speichern von Echtzeitdaten ausgelegt, sondern für das langfristige Speichern von statischen Daten gedacht, die bei Bedarf abgerufen oder aktualisiert werden können. Gute Anwendungsbeispiele für OpenStack Object Storage sind das Speichern von Virtual Machine Images, Photos, E-Mails, Backupdaten oder Archivierung. Da der Object Storage dezentral verwaltet wird, verfügt er über eine hohe Skalierbarkeit, Redundanz und Beständigkeit der Daten.

Die OpenStack Software sorgt dafür, dass die Daten auf mehrere Speicherbereiche im Rechenzentrum geschrieben werden, um damit die Datenreplikation und Integrität innerhalb des Clusters sicherzustellen. Die Storage Cluster skalieren dabei horizontal, indem weitere Knoten bei Bedarf hinzugefügt werden. Sollte ein Knoten ausfallen, sorgt OpenStack dafür, dass die Daten von einem aktive Knoten repliziert werden.

OpenStack Object Storage kann von Anbietern genutzt werden, um einen eigenen Cloud Storage bereizustellen oder die Server Images von OpenStack Compute zu speichern. Weitere Anwendungsfälle wären Dokumentenspeicher, eine Back-End Lösung für Microsoft SharePoint, eine Archivierungsplattform für Logdateien oder für Daten mit langen Aufbewahrungsfristen oder einfach nur zum Speichern von Bildern für Webseiten.

OpenStack Image Service

Der OpenStack Image Service hilft bei der Suche, Registrierung und dem Bereitstellen von virtuellen Maschinen Images. Dazu bietet der Image Service eine API mit einer Standard REST Schnittstelle, mit der Informationen über das VM Image abgefragt werden können, welches in unterschiedlichen Back-Ends abgelegt sein kann, darunter OpenStack Object Storage. Clients können über den Service neue VM Images registrieren, Informationen über öffentlich verfügbare Images abfragen und über eine Bibliothek ebenfalls darauf zugreifen.

Der OpenStack Image Service unterstützt eine Vielzahl an VM Formaten für private und öffentliche Images, darunter Raw, Machine (kernel/ramdisk, z.B. AMI), VHD (Hyper-V), VDI (VirtualBox), qcow2 (Qemu/KVM), VMDK (VMWare) und OVF (VMWare).

OpenStack Identity

Der OpenStack Identity Service stellt eine zentrale Authentifizierung über alle OpenStack Projekte bereit und integriert sich in vorhandene Authentifizierungs-Systeme.

OpenStack Dashboard

Das OpenStack Dashboard ermöglicht Administratoren und Anwendern den Zugang und die Bereitstellung von Cloud-basierten Ressourcen durch ein Self-Service Portal.

OpenStack Networking

OpenStack Networking ist ein skalierbares und API basierendes System für die Verwaltung von Netzwerken und IP-Adressen.

CloudStack

CloudStack wurde ursprünglich von Cloud.com entwickelt. Nach der Übernahme durch Citrix Systems im Jahr 2011 wurde Citrix zum Hauptsponsor von CloudStack. Die Open-Source Cloud Plattform basiert auf Java und hilft beim Aufbau und der Verwaltung von skalierbaren Infrastrukturen. Zu den aktuell unterstützten Hypervisorn gehören VMware, Oracle VM, KVM, XenServer und die Xen Cloud Platform. Neben einer eigenen RESTful API implementiert CloudStack ebenfalls die Amazon EC2 und S3 APIs sowie VMwares vCloud API. Die Cloud-Infrastruktur kann entweder über die Web-Oberfläche, einer Kommandozeile oder die API konfiguriert und verwaltet werden.

CloudStack besteht aus fünf Kernkomponenten. Der Compute Controller verwaltet die Rechenleistung, der Network Controller steuert das virtuelle Netzwerk und der Storage Controller ist für die Speicherverwaltung des BlockStorage zuständig. Alle drei Komponenten haben direkten Kontakt mit der physikalische Hardware. Auf diesen Komponenten setzt die CloudStack Orchestration Engine auf, die für den Aufbau, die Steuerung und Verwaltung der CloudStack Infrastruktur verantwortlich ist. Über der Orchestration Engine befindet sich als letzte Komponente die CloudStack API, die mit der Web-Oberfläche, Kommandozeile oder über REST interagiert und die Befehle an die Orchestration Engine weitergibt.

Citrix Systems ist nicht das einzige bekannte Unternehmen, was CloudStack unterstützt. Weitere Supporter des CloudStack Projekts sind RightScale, PuppetLabs, Juniper Networks, Enstratus, TrendMicro, Intel und Equinix.

Bildquelle: ©Gerd Altmann / PIXELIO

Kategorien
Analysen

"Infrastructure-as-a-Platform" mit mehr Komfort in die Cloud

Die Zukunft der Unternehmens-IT liegt im X-as-a-Service. Vor allem Infrastructure-as-a-Services ermöglichen den schnellen Zugriff auf Rechen- und Speicher-Ressourcen und erfreuen sich immer größerer Beliebtheit. Was jedoch vielen Angeboten fehlt ist die sogenannte „Convenience“, also die bequeme Konfiguration der Infrastruktur. Der Hamburger Managed Hosting Anbieter internet4YOU geht neue Wege und erfindet den Bereich „Infrastructure-as-a-Platform (IaaP)„. Vor allem für kleine- und mittelständische Unternehmen, die nicht über das notwendige IT-Know-How verfügen, um sich Standard IaaS Ressourcen zusammenzubauen, ist IaaP ein sehr interessanter Ansatz.

Infrastructure-as-a-Platform – Die Einfachheit zählt

Was den meisten IaaS-Lösungen fehlt, ist der komfortable Zugriff auf Ressourcen, mit denen sich virtuelle Infrastrukturen aufbauen lassen. Dabei handelt es sich in der Regel um Services von Cloud Anbietern der ersten Generation, wie bspw. den Amazon Web Services. Hier erfolgt der Zugriff über eine API, um damit die virtuellen Maschinen zu steuern und sämtliche Infrastrukturkomponenten und Services miteinander interagieren zu lassen. Graphische Verwaltungs-/ Konfigurationsoberflächen sind nur mit einem sehr kleinen Funktionsumfang vorhanden. Instanzen lassen sich zwar starten, stoppen und herunterfahren, für die Konfiguration einer komplexen Infrastruktur ist aber Expertenwissen sowie umfangreiches Know-How mit paralleler Programmierung usw. erforderlich.

Und das ist der entscheidende Faktor. Der gewöhnliche Cloud Nutzer ist kein Cloud Computing Experte und muss bzw. sollte es auch nicht sein. Er kennt sich nicht mit den Themen aus, die eine Cloud überhaupt zu einer Cloud machen. Das ist für ihn auch nicht notwendig, er will die „Blackbox“ schließlich nur für seine Zwecke nutzen. Darüber hinaus hat er nicht das Interesse oder gar die Zeit, sich mit den oft komplexen Systemen und Prozessen auseinanderzusetzen und diese zu erlernen. In der Regel erwartet der durchschnittliche Cloud Nutzer eine in sich stimmige und integrierte Plattform, auf der er sich seine notwendigen IT-Ressourcen zusammenbauen kann, die er über einen bestimmen Zeitraum für seine Zwecke benötigt.

Es gibt keine offizielle Definition von Infrastructure-as-a-Platform. Ursprünglich stammt der Begriff von ScaleUp Technologies. Dabei handelt es sich um eine eigenständige Tochter von internet4YOU, die Lösungen für den Aufbau und die Verwaltung von Cloud Infrastrukturen anbietet. Neben internet4YOU respektive ScaleUp Technologies bieten auch Anbieter wie Profitbricks und Zimory aber auch Open-Source Lösungen wie openQRM die Möglichkeiten einer IaaP.

Infrastructure-as-a-Platform gehört die Zukunft

Neben dem einfacheren Zugriff auf die Ressourcen, bündeln Infrastructure-as-a-Platform Lösungen insbesondere verschiedene IaaS Ressourcen wie Rechenleistung, Speicherplatz, Netzwerkkomponenten usw. und ermöglichen Unternehmen damit den Aufbau eines eigenen Rechenzentrum on-Demand, also ein „Data-Centre-as-a-Service“ (DCaaS).

Bereits etablierte Cloud Computing Anbieter – der ersten Generation – müssen damit beginnen in diesem Bereich aufzuholen und ihren bestehenden und neuen Kunden mehr Convenience bieten, mit der diese die Infrastrukturen bequemer nutzen können und während der Konfiguration zudem weniger Zeit und Expertenwissen benötigen. Denn insbesondere IT-Abteilungen von kleinen- und mittelständischen Unternehmen werden in Zukunft auf diesen Komfort achten.

Bildquelle: ©Gerd Altmann / PIXELIO

Kategorien
News

openQRM 5.0 erscheint mit überarbeiteter Benutzeroberfläche und neuem Dual-Lizenzmodell

Wie bereits Anfang Juni hier auf CloudUser angekündigt, hat die openQRM Enterprise GmbH mit openQRM 5.0 die nächste Generation ihrer Infrastructure-as-a-Service- (IaaS) und Cloud Computing Management Lösung veröffentlicht. Zudem wird ein neues duales Lizenzmodell präsentiert, das es Unternehmen ermöglicht, professionellen Support aus erster Hand zu erhalten und damit ihre Investitionen in eine Open-Source Datacenter-Management-Plattform langfristig zu sichern.

openQRM 5.0 erscheint mit überarbeiteter Benutzeroberfläche und neuem Dual-Lizenzmodell

Komplett neue Benutzeroberfläche

openQRM 5.0 wurde weitgehend umgeschrieben, wobei nicht nur äußerliche Änderungen an dem IaaS- und Cloud-Builder vorgenommen wurden. Neben der Umstellung der graphischen Benutzeroberfläche auf das Model-View-Controller-Konzept wurden zudem alle openQRM-Plugins neu geschrieben und mit weiteren Funktionen ausgestattet. Als weitere Erneuerung steht nun ein komplett neues Cloud-Portal zur Verfügung, sowie Postgres als weitere Backend-Datenbank neben MySQL.

openQRM 5.0 wurde darüber hinaus so erweitert, dass alle weltweit möglichen Sprachen unterstützt werden können. Als Standardsprachen unterstützt openQRM 5.0 ab sofort Englisch und Deutsch, das Cloud-Portal zusätzlich noch Spanisch, Niederländisch, Französisch und Italienisch.

Um den Administrator zu zeigen, welche Aktionen das System aktuell im Hintergrund durchführt, hat openQRM 5.0 eine Statusanzeige für „Active Events“ erhalten, die der Admin jederzeit einsehen kann.

Neben der webbasierten Benutzeroberfläche bietet openQRM 5.0 dem Nutzer nun auch einen vollwertigen Kommandozeilen-Client, mit dem die Management-Plattform innerhalb einer Terminal-Sitzung kontrolliert oder mit weiteren Anwendungen integriert werden kann.

Alle weiteren Erneuerungen befinden sich im Change-Log zu openQRM 5.0 unter http://www.openqrm-enterprise.com/de/ueber-openqrm/changlog-50.html.

Dual-Lizenzmodell für professionellen Support

Mit openQRM 5.0 ändert sich aufgrund verstärkter Nachfrage der Kunden das Lizenzmodell. Neben der bereits vorhandenen Open-Source-Version (GPL 2.0) können Unternehmen zusätzlich eine Enterprise-Version erwerben. Diese bietet neben erweiterten, unternehmensrelevanten Funktionen, ebenfalls professionellen Support durch die openQRM Enterprise GmbH.

In den letzten Jahren vermehrten sich die Anfragen von Kunden nach professionellem Support und Enterprise-Lizenzen, aber vor allem nach weiteren Feature-Wünschen. Darüber hinaus ist die Anzahl der Support-Anfragen angestiegen. Aus diesem Grund hat sich die openQRM Enterprise GmbH dafür entschieden das Lizenzmodell zu ändern, um diesen Anfragen weiterhin professionell gerecht zu werden. Professionelle Anwender erhalten mit der neuen Enterprise-Version somit ein kommerziell lizensiertes Produkt, inklusive der damit einhergehenden Investitions- und Updatesicherheit, Produktgewährleistung und professionellem Support. Kunden mit bestehenden Serviceverträgen (SLA) werden automatisch von der neuen Version profitieren und erhalten alle nötigen Lizenzen für openQRM Enterprise 5.0.

Die Community-Version von openQRM 5.0 wird von der Änderungen ebenfalls profitieren. Die freie Version von openQRM 5.0 erscheint wie bislang auch unter der GPLv2-Lizenz und wird weiterhin stetig verbessert werden. Zudem will die openQRM Enterprise GmbH die Qualität der Dokumentation, HowTos und Videos – auf welche die Community kostenlos Zugriff erhalten wird – fortlaufend steigern.

Weitere Informationen zur Community- und Enterprise-Version von openQRM 5.0 und deren Unterschiede sind auf http://openqrm-enterprise.com/products-service/version-comparison.html zu finden.

Kategorien
News

openQRM gibt erste Informationen zur neuen Version 5.0 bekannt

Lange haben wir von den Kölner Jungs um Projekt Manager Matt Rechenburg und ihrer Cloud- und Automatisierungssoftware openQRM nichts mehr gehört. (Immer diese NDAs mit denen ich geknebelt werde…) Heute gab es dann aber ein erstes Lebenszeichen. Wie Matt auf dem openQRM Blog schreibt, wird openQRM 5.0 voraussichtlich am 01. August 2012 erscheinen und ein echtes Mayor Release werden. Neben der vollständigen Überarbeitung der Benutzeroberfläche, soll sich die User-Experience erheblich verbessern.

openQRM Projekt Manager Matt Rechenburg

Neben dem Tausch der Framestruktur gegen einen vollständig objektorientieren Model-View-Controller (MVC) Ansatz, bietet das MVC-Konzept nun ebenfalls den Zugriff über eine Restful API sowie die Möglichkeit der Nutzung unterschiedlicher Landessprachen. Zunächst wurden nur Englisch und Deutsch übersetzt. Weitere Sprachen sind aber bereits in Arbeit. Weiterhin wurde das openQRM Cloud Portal vollständig überarbeitet und wird in sechs unterschiedlichen Sprachen (EN/DE/ES/NL/FR/IT) verfügbar sein. Im Backend wird in Zukunft ebenfalls die Postgres Datenbank unterstützt. Aktueller Standard ist MySQL.

„Auf Grund dieser großen Überarbeitung von openQRM mussten wir jedes openQRM Plugin einzeln anpassen. Man kann sich vorstellen, dass dies viel Entwicklungszeit gekostet hat und weiterhin kosten wird, um sicherzustellen, für die Nutzer die beste openQRM Erfahrung aller Zeiten zu entwickeln.“, so Matt.

Aktuell arbeitet das Team an der Überarbeitung der letzten Plugins. Nachdem alles fertiggestellt, ist wird der Stand des Programmcodes eingefroren, damit die Q&A Phase mit der Community starten kann.

Das openQRM 5.0 Release wird für den 01. August 2012 erwartet und wird, wie bereits die Version 4.9, von der openQRM Enterprise GmbH gesponsert.

Kategorien
News

openQRM bringt Clonezilla, Cobbler, FAI, LinuxCOE und Opsi in die Cloud

openQRM beendet seinen nächsten Meilenstein und führt in seiner dritten Phase nun die Deployment-Methode „install-from-template“ ein.

Nachdem openQRM mit der Version 4.x 2008/2009 vollständig neu entwickelt wurde, fokussierten sich die Entwickler zunächst auf die Methode („network-deployment“), mit der flexibel und dynamisch neue Systeme aus unterschiedlichen Speichertechnologien gestartet werden konnte. In der zweiten Phase wurde das „local-deployment“ hinzugefügt, mit dem virtuelle Maschinen bequem in bereits bestehende virtuelle Umgebungen integriert werden kann. openQRM ist nun in der ditten Phase angekommen und führt die Methode „install-from-template“, insbesondere für lokal installierte Systeme, ein.

Mit dieser dritten Deployment-Methode stellt openQRM nun alle möglichen Provisionierungsmechanismen innerhalb einer einzigen Managementkonsole bereit. Um die neue „install-from-template“ Funktion einzuführen, wurde das „openQRM Appliance Model“ erweitert, das nun erlaubt, openQRM dynamisch mit weiteren neuen Technologien für das lokale Deployment wie Cobbler, FAI, Opsi, usw. zu erweitern.

Folgende Technologien stehen bereits als Plugins für openQRM zur Verfügung:

  • Clonezilla – Ermöglicht die lokale Provisionierung via Disk-Imaging (Klonen des Festplatten-Inhalts). Verfügbar für Windows und Linux.
  • Cobbler – Linux Installation Server für die schnelle Einrichtung von Netzwerkinstallationsumgebungen.
  • FAI – Bei FAI handelt es ich um ein nicht interaktives System für die Installation, Anpassung und Verwaltung von Linux Systemen und Softwarekonfigurationen auf Rechnern und virtuellen Maschinen.
  • LinuxCOE – Das HP Linux Common Operating Environment (LinuxCOE) ist ein weltweites Programm für die Provisionierung und dem Lebenszyklusmanagement von Linux Systemen.
  • Opsi – Opsi ist ein Open Source Client Management System für Windows Clients und basiert auf einem Linux Server.

Da openQRM so entworfen wurde, um als ein abstrahiertes Modell eines Rechenzentrums zu dienen, sind alle oben genannten Funktionen in der openQRM Cloud wiederzufinden. Dies bedeutet, dass openQRM als eine Middleware genutzt werden kann, um vorhandene Umgebungen und Technologien wie Cobbler, FAI, LinuxCOE und Opsi für das Cloud Computing zu nutzen.