Der Host-Setup-Dialog führt den Tab "Hosted Engine" auf. Dort fragt das Tool den Punkt "Choose hosted engine Deployment action" ab. Das ist leider etwas verwirrend formuliert. Der RHV-Anfänger denkt sich an dieser Stelle: Warum soll ich die Hosted Engine deployen, ich habe ja bereits eine und wählt den Default-Wert "none", anstatt "deploy". Hinter dieser Frage verbirgt sich aber eine andere Funktion.

Wählen Sie hier "deploy", installiert RHV die nötigen Tools wie etwa pacemaker zum Verwalten der Hosted-Engine-VM auf diesem RHV-Knoten. Nur Hypervisor-Nodes mit "deploy" können die Hosted Engine betreiben. Das dumme hieran ist: Die Funktion lässt sich nicht einfach nachträglich zu einem bestehenden Hypervisor hinzufügen. Wer einen Hypervisor ohne Hosted-Engine-Tools aufrüsten will, muss ihn erst leerräumen und in den Maintenance Mode versetzen. Dann startet das RHVM-Deployment-Tool eine Neuinstallation des Knotens mit Hosted-Engine-Tools.

In der Praxis wird ein RHV-Architekt einen Cluster aus drei bis fünf Hypervisor-Knoten mit eigenen Storage-Volumes einrichten, der für administrative VMs und Funktionen reserviert bleibt. Nur die Hypervisor-Knoten dieses Clusters erhalten die Hosted-Engine-Rolle zugewiesen. Für die Integration des RHV-Managers in ein Benutzerverzeichnis kommen Sie leider nicht um ein paar Dialoge auf der Kommandozeile herum. Angemeldet als "root" auf der Shell der RHV-M-VM geben Sie folgendes Kommando ein:

ovirt-engine-extension-aaa-ldapsetup

Dieses führt Sie per Menü in wenigen Schritten durch die Integration in einen der unterstützten Verzeichnisdienste. Mit der Directory-Integration erlaubt RHV dann bestimmten Gruppen oder Usern aus dem Verzeichnis, auf das Admin- und User-Portal zuzugreifen, Maschinen zu erstellen oder zu verwalten. RHV unterstützt mehrere Verzeichnisverbindungen gleichzeitig, sodass verschiedene Datacenter oder Cluster ihre Zugriffsrechte aus unterschiedlichen Directories beziehen.


Der Cluster legt auch die Basisparameter für Ressourcen und Overcommitment fest. Traditionell arbeitet RHV sehr konservativ: Es startet nur VMs mit so vielen virtuellen CPU-Kernen, wie im Cluster tatsächliche CPU-Kerne zur Verfügung stehen. Ebenso erlaubt RHV per Default kein Memory Overcommit. Diese Settings lassen sich ebenso anpassen wie NUMA-Beschränkungen. Bei letzterem achtet RHV darauf, dass virtuelle CPUs und RAM innerhalb einer NUMA-Zone eines Prozessors bleiben, um eine hohe Performance zu erzielen. Die Cluster-Einstellungen legen auch die Parameter für KSM (Kernel Same Page Merging, eine Art RAM-Deduplizierung) und Affinity Labels fest. Mit Hilfe der Labels lassen sich gekennzeichnete VMs gezielt auf passenden Cluster-Nodes ausführen. Zudem unterstützt der Cluster Affinity Groups, um bestimmte VMs auf den gleichen oder zwingend auf getrennten Nodes auszuführen. Die Migration Policy legt fest, wie aggressiv RHV laufende Maschinen von Host-zu-Host verschiebt, um eine homogene Cluster-Auslastung zu gewähren.

Neben den offensichtlichen Einstellungen offeriert ein RHV-Cluster auch eine Reihe erweiterter Optionen, die sich nicht direkt in der GUI zeigen. RHV verfügt beispielsweise über "Migration Policies". Diese legen unter anderem die Timeouts für das Verschieben laufender VMs fest. Simple VMs kommen mit den Standardeinstellungen klar. Aber immer öfter kommen Maschinen mit viel RAM und viel Aktivität im RAM (etwa In-Memory-Datenbanken) an die Grenzen. Diese Systeme brauchen vor allem in der zweiten Phase der Live-Migration (Phase 1: Snapshot der laufenden Maschine und Kopie des RAM-Snapshots, Phase 2: Stopp der VM, zweiter Snapshot, Übertragung der Differenz zwischen Snapshot 1 und 2) der Maschine mehr Zeit. RHV erlaubt Ihnen, eigene Migration Policies zu erstellen und diese nicht nur einem Cluster, sondern individuell einzelnen Maschinen zuzuweisen.

Seite 2: Installation von RHV

Im dritten Teil erklären wir, was beim laufenden Betrieb von RHV wichtig ist und stellen eine hyperkonvergente Variante für kleine Umgebungen vor. In der ersten Folge des Workshops gingen wir auf die Grundlagen von RHV ein und erklärten die architektonischen Unterschiede zu vCenter.

<< Vorherige Seite

Seite 2 von 2

dr/ln/Max Lessel