Red Hat
Unsere Demoumgebung


Der erste Grundstein:

Hochverfügbare Virtualisierungsumgebung auf Basis von Open Source Technologien Red Hat Virtualization (RHEV)

Heute möchte ich, hoffentlich kurz, eine Installationanleitung und ein paar Gedanken zu unserem RHEV Cluster verfassen. Die Grundidee war eine hochverfügbare Virtualisierungsstruktur zu installieren und dann nach und nach unternehmenswichtige Dienste hinzu zu installieren (Windows Server, DNS-Sever, Cloudforms, PXE Boot etc. )

Dazu werden regelmäßig immer kleine Artikel erscheinen, die Gedanken und Anleitungen enthalten. Ziel dieser Artikel ist, Ihnen darzulegen, dass Unternehmen mit Open-Source Technologien unternehmenskritische Infrastrukturen aufbauen und betreiben können. Gerade in Rechenzentren findet man immer mehr Linux und Open-Source. Der Vorteil der offenen und standardisierten Software ist auf der einen Seite der Preis, und auf der anderen Seite die Integrationsfähigkeit und die Offenheit. Wir werden Ihnen hier die verschiedenste Lösungen beschreiben und hoffen auf Ihre Rückmeldung. Schreiben Sie uns gerne an, wenn Sie mehr über die Lösungen erfahren möchten. ( redhat@also.com )


Die ersten Gedanken, die man sich machen muss:

Der RHEV – Manager.

Genau wie bei VMWare gibt es hier einen Manager, den Kopf des Ganzen. Dieser steuert die Hypervisoren, speichert die Datenbanken und verwaltet den ganzen Cluster. Dieser RHEV-Manager kann auf externer Hardware installiert werden oder als VM innerhalb des RHEV Verbundes. Generell kann man sagen, wenn es nur ein Physikalischer Hypervisor ist, sollte man aus Failover-Gründen den Manager extern installieren. Sobald zwei oder mehr Server zum Einsatz kommen und man ein funktionierendes Backup hat, kann man ihn beruhigt in einer VM installieren.

Die Hypervisoren:

Dort haben wir zwei Möglichkeiten. Man kann eine Standard Red Hat Enterprise Linux 6 oder 7 Installation (RHEL) nehmen oder einfach eine RHEV-H Version. Beides hat Vor- und Nachteile.

Wenn wir eine RHEL Installation verwenden, haben wir alle vorhandenen Standard-Tools und Programme zur Verfügung. D.h. ich habe meine normalen Log Files und kann per YUM (Paketmanager) auch alle beliebigen Applikationen installieren, was ich z.B. zum Monitoren benötige. Eben eine „normale“ RHEL Installation, die durch zusätzlich installierte Pakete zum „Hypervisor“ wird. Der klare Nachteil ist allerdings, dass man hierfür eine verfügbare RHEL Subscription haben muss, da es natürlich ein vollwertiges OS ist.

Der RHEV-H ist eine abgespeckte RHEL Version, die eben nur als Hypervisior dienen kann. Sehr vergleichbar mit dem ESX. Ich habe nur minimale Einstellungsmöglichkeiten (IP Adresse, FQDN etc.) und Vorteile wie das Nachinstallieren von Programmen / Tools oder ein „vollwertiges OS“ habe ich einfach nicht. Aber der große Vorteil: Ich benötige keine weitere Subscription und er erfüllt seinen Job. In meiner Testumgebung, die später noch weiter in den Vordergrund rückt, habe ich 1x RHEL 6, 1x RHEL 7 und ein RHEV H zu Demozwecken installiert, Da natürlich auch solche „Misch Hypervisoren” im Cluster möglich sind. Wichtig ist, zu verstehen, dass diese recht „dumm“ sind. Der Kopf des Ganzen ist und bleibt der RHEV – M. Die Hypervisoren sind reine „Muskelkraft“.

Der Storage, Anforderungen bilden die Lösung:

Auch hier haben wir viele Möglichkeiten und Wege, die Idee umzusetzen. Wichtig ist hierbei, zu verstehen, was man genau haben möchte. Es kann praktisch sein und ausreichend schnell. Oder sehr schnell und nur ausreichend praktikabel. Generell gilt beim Storage – desto schneller und sicherer, umso teurer wird die Lösung. Die beste Lösung wäre natürlich, einen externen Storage aufzusetzen, diesen auf andere Hardware spiegeln und zusätzlich eine Backup Lösung einzubauen. Dann haben wir hohe Ausfallsicherheit, hohe Geschwindigkeiten und hohe Kosten. Für Unternehmen, wo diese Lösung überdimensioniert ist wäre vielleicht der Weg interessant, den ich gegangen bin. Natürlich haben Sie die Möglichkeit, fast jegliche Storage Arten anzubinden. Auch können Sie die in den Hypervisoren verbauten Platten als Storage freigeben. In meiner Umgebung ist der RHEV-M auf einer älteren Workstation installiert. Diese Maschine hat 2x 1 TB Platten, die als RAID 1 eingerichtet sind, was bedeutet, ich habe 1 TB Platz zur Verfügung. 200 GB gebe ich dem RHEV-M und 800 GB weise ich dem Cluster als Storage zu (NFS-Share). Das Ganze wird per Shell Script noch auf ein externes NAS gesichert. Allerdings sind bei der Storage Anbindung keine Grenzen gesetzt. Dort können Sie Ihre bevorzugte Storage Lösung umsetzen. Damit die Live Migration von VM´s trotzdem schnell ist, sind die 3 Server untereinander per 10 GB Bond verbunden.

Die Architektur – Bildlich dargestellt:

Dieses bisher beschriebene Setup ist hier nochmal dargestellt.


Die Vorbereitung

Da der Manager die ganze Verwaltung unseres Clusters übernimmt, sollte er nicht zu klein ausfallen. Jede Datenbank-Operation wird vom RHEV-M übernommen.

Gerade bei der Festplatte sollte nicht gespart werden. Wenn die Umgebung über eine längere Zeit wächst und dann feststellt wird, dass die Datenbank zu groß geworden ist, kann das eine längere „Down-Time“ verbunden mit erhöhten Wartungskosten zur Folge haben. Natürlich wird eine 1Gb/s Netzwerkkarte benötigt.

Als Grundlage für den RHEV-M wird ein Red Hat Enterprise Linux Server verwendet. Führen Sie, wie gewohnt, eine ganz normale Installation durch. Anschließend werden über den Subscription-Manager zusätzlich Channel hinzugefügt. Diese Channel werden benutzt, um Installationspakete herunter zu laden und später um Updates einzupflegen.

Die Channels:

  • # rhel-x86_64-server-6
  • # rhel-x86_64-server-supplementary-6,
  • # rhel-x86_64-server-6-rhevm-3.4
  • # jbappplatform-6-x86_64-server-6-rpm

Ein paar Worte zum DNS Dienst:

DNS ist für die Umgebung essentiell. RHEV benötigt für die Kommunikation mit dem RHEV-H (RHEV-Host) und dem RHEV-M einen funktionierenden DNS Server. Bevor Sie die Installation beginnen, stellen Sie sicher, dass Ihr DNS Dienst wie erwartet läuft. Gleichzeitig ist auch ein NTP-Server sehr hilfreich. Viele RHEV Komponenten kommunizieren über SSH, welches sehr sensibel gegenüber Zeitunterschieden reagiert. Durch den NTP-Server werden die Zeiten vereinheitlicht und so werden signifikante Zeitunterschiede vermieden.

Um später auf das Webfrontend zuzugreifen, benötigen Sie gängige Browser ( Supportet wird der Internet Explorer und Mozilla Firefox ). Für den visuellen Zugriff benötigen Sie einen VNC Viewer oder einen Spice Client - das hängt davon ab, welches Protokoll Sie später verwenden wollen. Im nächsten Schritt starten wir die Installation.

Haben Sie Fragen zu unserer Demoumgebung, oder dürfen wir Ihnen eine Livedemo geben? Sprechen Sie mich an.


Ihr Ansprechpartner bei ALSO:

Matthias Juchhoff

Product Manager
Tel: +49 2921 99-5594
Matthias.Juchhoff@also.com