Open Source im professionellen Einsatz
Linux-Magazin 12/2011
555

Abstraktion extrem

Ein gewisses Maß an Abstraktion gehört bei Cloudlösungen fest dazu. So ist es für den Endanwender, der eine virtuelle Maschine für einen bestimmten Zweck braucht, völlig irrelevant, woher der Speicher für diese VM kommt, auf welchen Festplatten innerhalb der Cloud seine Daten lagern und wie das Netzwerk funktioniert. Es zählt nur, ob die Cloud die erwartete Leistung bringt.

Open QRM führt die Abstraktion auch im Konfigurationsinterface ein. Zwar müssen Admins noch immer festlegen, an welchem Speicher eine mit Open QRM realisierte Virtualisierungslösung sich bedient und auf welchen Nodes die virtuellen Maschinen starten, aber das Open-QRM-Webinterface bietet dafür vielfältige Werkzeuge und eine eigene Logik.

Unter der Haube kombiniert der so genannte Storage Abstraction Layer alle zur Verfügung stehenden Storage-Devices zu einfachen Speicherpools. Er sorgt dafür, dass Programme und Werkzeuge innerhalb des Open-QRM-Universums stets mit den gleichen Befehlen auf Speicherplatz zugreifen können. Somit ist es letztlich egal, ob der Speicher-Zugriff auf ein per I-SCSI angebundenes SAN oder ein DRBD-Laufwerk auf einem Storage-Cluster erfolgt: In Open QRM sieht jeder Speicherplatz gleich aus, was gerade für die Automatisierungsfunktionen an Bedeutung gewinnt.

Die Abstraktion gilt übrigens nicht nur im Hinblick auf denStorage, sondern auch für virtuelle und echte Geräte. Alle Dienste in Open QRM betrachtet das Management-Center einfach als Ressourcen. Nicht-virtualisierte Systeme lassen sich mithin genauso als Ressource verwalten wie virtuelle Maschinen (siehe Abbildung 4).

Abbildung 4: Open QRM setzt verstärkt auf Abstraktion. Alles ist entweder ein Storage oder eine Ressource. Das zahlt sich schnell aus, vor allem beim automatischen Start abgestürzter VMs.

Bootservice

In unmittelbarem Zusammenhang mit der Steuerung von Computersystemen steht der Open-QRM-Bootservice. Der Dienst wirkt auf den ersten Blick wie eine Nebensache, ist aber eminent wichtig: Von ihm erfahren physikalische und virtuelle Systeme, welches System sie booten sollen. Indirekt sorgt er dafür, dass aus Systemen überhaupt erst Ressourcen im Open-QRM-Sinne werden. Der Bootservice wird aktiv, wenn auf einem System ein bestimmtes Software-Image deployt werden soll. Er erfüllt aber auch eine wichtige Rolle, wenn physikalische oder virtuellle Maschinen ein neues System booten sollen.

Fällt eine Instanz unter Open QRM aus, dann bleibt das dem eingebauten Monitoringsystem, einem internen Nagios 3 (Abbildung 5), nicht verborgen. Um dessen Konfiguration braucht der Admin sich nicht zu kümmern: Es landet zusammen mit Open QRM automatisch auf dem zentralen Server und ist für Open QRM gleich passend konfiguriert. Wesentlich angenehmer als bei einem reinen Nagios gestaltet sich das Hinzufügen neuer Hosts: Per Mausklick erweitern Admins die Konfiguration, sodass das Monitoring neue Hosts in Sekundenschnelle erfasst und überwacht.

Abbildung 5: Open QRM hat Nagios 3 eingebaut, nimmt aber dem Admin viel lästige Konfigurationsarbeit ab.

Aber Open QRM kann auch etwas unternehmen, wenn eine Ressource etwa nach dem Ausfall einer Hardwarekomponente nicht mehr funktioniert. Hier greift das Abstraktionsmodell: Nach Lage der Dinge reanimiert Open QRM die abgestürzte Ressource entweder auf anderer Hardware, wandelt sie unmittelbar in ein physikalisches System um oder – und das ist durchhaus beachtlich – bootet mittels IPMI (Intelligent Platform Management Interface, eine Schnittstellensammlung zur Wartung und Administration von Rechnern, [14]) einen zusätzlichen Server, um die Ressource dort zu starten (siehe Abbildung 6).

Abbildung 6: Hochverfügbarkeit im Webinterface einstellen, das kann nur Open QRM mit dem HA-Manager-Plugin. Wer das mit IPMI kombinieren will, braucht aber die Enterprise-Variante.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Cloud-HA

    Wer seine virtuellen Infrastrukturen in der Wolke kreisen lässt, muss sich darauf verlassen, dass die Triebwerke nicht versagen. Ob Public, Private oder Hybrid Cloud, es gibt immer Möglichkeiten, hohe Verfügbarkeit zu erreichen – aber in den Details unterscheiden sich die Angebote doch sehr.

  • Selbst gemachte Wolken

    Wozu für einen externen Service bezahlen, wenn die Server im eigenen Unternehmen genug Ressourcen für eine Cloud haben? Das Linux-Magazin untersucht Werkzeuge, die für private Wolken taugen.

  • Ubuntu: Open Stack statt Eucylyptus, Thunderbird statt Evolution?

    Glaubt man der Gerüchteküche, dann ändert sich in nächster Zeit bei Ubuntu noch einiges. Canonical hat bereits angekündigt, nicht mehr auf Eucalyptus als Cloud-Computing-Plattform zu setzen, sondern auf Open Stack, und die Entwickler auf dem Developer Summit scheinen sich eher für Thunderbird als für Evolution begeistern zu können.

  • Open-Stack-Workshop

    Dass Open Stack in aller Munde ist, bedeutet nicht, dass es überall installiert ist. Die für eigene Anwendungsfälle richtigen Komponenten auszuwählen und das Setup des Stapels erweisen sich als hochkomplex. Mit diesem Artikel startet ein dreiteiliger Workshop, der Admins fit für die Open-Stack-Praxis macht.

  • Wolkige Aussichten

    Für firmenweite Virtualisierung und fürs Cloud Computing: SLES 11 SP1, Univention UCS, Ubuntu Enterprise Cloud und Open QRM stellen sich einem Vergleich.

comments powered by Disqus

Ausgabe 10/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.