Website-Suche

Installation von RHEV-Clustering und RHEL-Hypervisoren – Teil 5


In diesem Teil werden wir einige wichtige Punkte im Zusammenhang mit unserer RHEV-Serie besprechen. In Teil-2 dieser Serie haben wir die Bereitstellung und Installation von RHEV Hypervisor besprochen. In diesem Teil besprechen wir andere Möglichkeiten zur Installation von RHEV Hypervisor.

Der erste Weg erfolgte durch die Verwendung von dediziertem RHEVH, das von RedHat selbst angepasst wurde, ohne dass Änderungen oder Änderungen seitens des Administrators erforderlich waren. Im anderen Fall verwenden wir einen normalen RHEL-Server [Minimale Installation], der als RHEV-Hypervisor fungiert.

Schritt 1: RHEL-Hypervisor zur Umgebung hinzufügen

1. Installieren Sie den abonnierten RHEL6-Server [Minimale Installation]. Sie können Ihre virtuelle Umgebung erweitern, indem Sie einen zusätzlichen abonnierten RHEL6-Server hinzufügen. [Minimale Installation] fungiert als Hypervisor.

Spezifikation der virtuellen Maschine
OS: RHEL6.6 x86_64
Number of processors: 2
Number of cores : 1
Memory : 3G
Network : vmnet3
I/O Controller : LSI Logic SAS
Virtual Disk : SCSI
Disk Size : 20G
IP: 11.0.0.7
Hostname: rhel.mydomain.org

und stellen Sie sicher, dass Sie die Option Virtualisierung in den VM-Prozessoreinstellungen aktiviert haben.

Hinweis: Stellen Sie sicher, dass Ihr System die Redhat-Kanäle abonniert und auf dem neuesten Stand ist. Wenn Sie nicht wissen, wie Sie den Redhat-Abonnementkanal abonnieren, können Sie dies lesen den Artikel Red Hat Subscription Channel aktivieren.

Tipp: Um Ihre Ressourcen zu schonen, können Sie einen der beiden derzeit aktiven Hypervisoren herunterfahren.

2. Um Ihren Server in einen Hypervisor umzuwandeln {als Hypervisor zu verwenden}, müssen Sie möglicherweise den RHEVM-Agenten darauf installieren.

yum install vdsm

Nachdem die Paketinstallation abgeschlossen ist, gehen Sie zur RHEVM-Weboberfläche, um sie hinzuzufügen.

3. Im Gegensatz zum RHEVH-Hypervisor können Sie den RHEL-Hypervisor auf eine Weise von RHEM aus hinzufügen, indem Sie die Root-Anmeldeinformationen des RHEL-Hypervisors verwenden. Wechseln Sie also von rhevm WUI zur Registerkarte Hosts und klicken Sie auf Neu.

Geben Sie dann wie gezeigt Ihre Host-Informationen ein.

Ignorieren Sie als Nächstes die Power-mgmt-Warnung und schließen Sie den Vorgang ab. Warten Sie dann einige Minuten und überprüfen Sie den Status des neu hinzugefügten Hosts.

Weitere Informationen zum Hinzufügen eines RHEL-basierten Hosts finden Sie in der offiziellen RHEV-Dokumentation von RedHat.

Schritt 2: RHEV-Clustering verwalten

Clustering in RHEV beschreibt eine Gruppe von Hosts desselben CPU-Typs, die sich denselben Speicher teilen [z. B. über Netzwerk] und zur Ausführung einer bestimmten Aufgabe verwenden [z. B. Hohe Verfügbarkeit ]

Clustering bringt im Allgemeinen viele zusätzliche Aufgaben mit sich. Sie können sich den Artikel ansehen, der erklärt, was Clustering ist und welche Vor- und Nachteile es hat.

Der Hauptvorteil des Clusterings in RHEV besteht darin, die Migration virtueller Maschinen zwischen Hosts, die zum selben Cluster gehören, zu ermöglichen und zu verwalten.

Wie migrieren virtuelle Maschinen zwischen Hosts?

RHEV hat zwei Strategien:

1. Live-Migration
2. Hohe Verfügbarkeit

1. Live-Migration

Live-Migration wird in unkritischen Situationen verwendet, was bedeutet, dass im Allgemeinen alles einwandfrei funktioniert, Sie jedoch einige Lastausgleichsaufgaben ausführen müssen (z. B. haben Sie festgestellt, dass ein Host von einer virtuellen Maschine über eine andere geladen wird). Also, Sie Möglicherweise wird eine virtuelle Maschine live von einem Host auf einen anderen migriert, um einen Lastausgleich zu erreichen.

Hinweis: Es gibt keine Unterbrechung für Dienste, Anwendungen oder Benutzer, die während der Live-Migration in der VM ausgeführt werden. Live-Migration wird auch als Neuzuweisung von Ressourcen bezeichnet.

Die Live-Migration kann manuell oder automatisch gemäß vordefinierter Richtlinie durchgeführt werden:

  1. Manuell: Erzwingen Sie die Auswahl des Zielhosts und migrieren Sie die VM dann manuell über WUI dorthin.
  2. Automatisch: Verwenden einer der Cluster-Richtlinien zur Verwaltung der Live-Migration entsprechend der RAM-Nutzung, CPU-Auslastung usw.

Wechseln Sie zur Registerkarte Cluster, wählen Sie Cluster1 aus und klicken Sie auf Bearbeiten.

Wechseln Sie von den Fensterregisterkarten zur Registerkarte Clusterrichtlinie.

Wählen Sie die Richtlinie evenly_distributed aus. Mit dieser Richtlinie können Sie den maximalen Schwellenwert für die CPU-Auslastung auf dem Host und die zulässige Zeit für die Auslastung vor dem Start der Live-Migration konfigurieren.

Hinweis

Wie gezeigt, habe ich den maximalen Schwellenwert auf 50 % und die Dauer auf 1 Minute konfiguriert.

Dann OK und wechseln Sie zur Registerkarte „VM“.

Wählen Sie Linux vm [Zuvor erstellt] aus, klicken Sie dann auf Bearbeiten und überprüfen Sie diese Punkte.

1. Auf der Registerkarte „Host“: Überprüfen Sie, ob die manuelle und automatische Live-Migration für diese VM zulässig ist.

2. Auf der Registerkarte „HA“: Überprüfen Sie den Prioritätsgrad Ihrer virtuellen Maschine. In unserem Fall ist das nicht sehr wichtig, da wir nur mit einer VM spielen. In großen Umgebungen ist es jedoch wichtig, Prioritäten für Ihre VMs festzulegen.

Starten Sie dann die Linux-VM.

Zunächst verwenden wir die Manuelle Live-Migration. Die Linux-VM läuft jetzt auf rhel.mydomain.org.

Führen wir den folgenden Befehl über die VM-Konsole aus, bevor wir mit der Migration beginnen.

ls -lRZ / 

Wählen Sie dann Linux VM aus und klicken Sie auf Migrieren.

Wenn Sie die Option „Automatisch“ auswählen, prüft das System den Host mit der höchsten Verantwortung als Ziel gemäß der Cluster-Richtlinie. Wir werden dies ohne Eingreifen des Administrators testen.

Nachdem Sie also manuell ausgewählt und das Ziel ausgewählt haben, klicken Sie auf „OK“, gehen Sie zur Konsole und überwachen Sie den ausgeführten Befehl. Sie können auch den VM-Status überprüfen.

Möglicherweise müssen Sie Aufgabenereignisse überwachen.

Nach ein paar Sekunden werden Sie eine Änderung im VM-Hostnamen feststellen.

Ihre VM wurde manuell erfolgreich live migriert!!

Versuchen wir es mit der automatischen Live-Migration. Unser Ziel ist es, dass die CPU-Auslastung auf dem rhevhn1-Host 50 % überschreitet. Wir werden dies tun, indem wir die Last auf der VM selbst erhöhen. Schreiben Sie also von der Konsole aus diesen Befehl:

dd if=/dev/urandom of=/dev/null

und überwachen Sie die Auslastung des Hosts.

Nach einigen Minuten übersteigt die Auslastung des Hosts 50 %.

Warten Sie einfach noch ein paar Minuten, dann startet die Live-Migration automatisch, wie gezeigt.

Sie können auch die Registerkarte „Aufgaben“ überprüfen und nach kurzer Wartezeit wird Ihre virtuelle Maschine automatisch live auf den rhel-Host migriert.

Wichtig: Stellen Sie sicher, dass einer Ihrer Hosts über mehr Ressourcen verfügt als der andere. Wenn die beiden Hosts hinsichtlich der Ressourcen identisch sind. VM wird nicht migriert, da es keinen Unterschied gibt!!

Hinweis: Wenn Sie den Host in den Wartungsmodus versetzen, wird die Live-Migration automatisch aktiviert und VMs werden auf andere Hosts im selben Cluster ausgeführt.

Weitere Informationen zu VM-Migrationen finden Sie unter Migrieren virtueller Maschinen zwischen Hosts.

Hinweis: Live-Migration zwischen verschiedenen Clustern wird nicht offiziell unterstützt, außer in einem Fall, den Sie hier überprüfen können.

2. Hohe Verfügbarkeit

Im Gegensatz zur Live-Migration wird HA zur Abdeckung kritischer Situationen und nicht nur zur Lastverteilung verwendet. Der allgemeine Abschnitt besagt, dass Ihre VM ebenfalls auf einen anderen Host migriert wird, allerdings mit Ausfallzeit beim Neustart.

Wenn in Ihrem Cluster ein Host ausfällt, nicht betriebsbereit ist oder nicht reagiert, kann Live Migration Ihnen nicht weiterhelfen. HA schaltet die virtuelle Maschine aus und startet sie auf einem anderen aktiven Host im selben Cluster neu.

Um HA in Ihrer Umgebung zu aktivieren, müssen Sie über mindestens ein Energieverwaltungsgerät [z. B. Netzschalter] in Ihrer Umgebung.

Leider ist uns das in unserer virtuellen Umgebung nicht möglich. Weitere Informationen zu HA in RHEV finden Sie unter „Improving Uptime with VM High Availability“.

Denken Sie daran: Live-Migration und Hochverfügbarkeit funktionieren mit Hosts im selben Cluster mit demselben CPU-Typ und verbunden mit gemeinsam genutztem Speicher.

Abschluss:

Wir erreichten den Höhepunkt unserer Serie, als wir eines der wichtigen Merkmale des RHEV-Clusterings besprachen, wie wir es beschrieben hatten, und seine Bedeutung. Außerdem haben wir den zweiten Typ [Methode] zur Bereitstellung von RHEV-Hypervisoren besprochen, die auf RHEL [mindestens 6.6 x86_64] basieren.

Im nächsten Artikel werden wir in der Lage sein, einige Vorgänge auf virtuellen Maschinen durchzuführen, wie z. B. Snapshots, Versiegelung, Klonen, Exportieren und Pools.