Events

HCI-Testreihe, Teil 4

HCI-Plattform von Red Hat

17. Januar 2020, 06:00 Uhr   |  Von Christoph Lange.

HCI-Plattform von Red Hat

RHHI-V von Red Hat stellt einen ausfallsicheren Cluster-Verbund als Hyper-Converged Infrastructure (HCI) bereit. LANline hat im vierten Teil der Testreihe die Softwarelösung unter die Lupe genommen.

Der Linux-Spezialist Red Hat hat mit Red Hat Hyperconverged Infrastructure for Virtualization (RHHI-V) eine HCI-Lösung entwickelt, die Standard-Server-Hardware in einen hochverfügbaren Compute-, Storage- und Network-Cluster verwandelt. RHHI-V verwendet in Version 1.6 den Red Hat Virtualization Host 4.3 als Server-Virtualisierungsplattform und die Lösung Red Hat Gluster Storage 3.4 für eine ausfallsichere Bereitstellung der lokalen Speicherressourcen der Cluster-Nodes.

Als Einsatzszenarien für RHHI-V sieht Red Hat unter anderem Zweigstellen von größeren Unternehmen, die damit eine von der Zentrale unabhängige, ausfallsichere IT-Infrastruktur erhalten. Für Service-Provider bietet Red Hat mit RHHI-C eine eigene Lösung an, die OpenStack mit Ceph-Storage auf hyperkonvergenten Systemen verbindet. Größere Unternehmen können zudem die konvergente Plattform Open-Shift Container Storage 3 (OCS3) nutzen.

Die von LANline getestete RHHI-V-Lösung benötigt für eine hochverfügbare Konfiguration mindestens drei physische Server und skaliert in 3-Node-Schritten derzeit auf bis zu zwölf Server pro Cluster. Für sehr kleine Außenstellen, die keine Hochverfügbarkeit benötigen, ist es zudem möglich, die RHHI-V-Software auf einem einzigen Server zu installieren. In kleineren Umgebungen sollte jeder Server über mindestens zwölf CPU-Cores, 64 GByte RAM, 48 TByte lokalen Plattenspeicher und zwei Netzwerkkarten verfügen. Die Installation ist aber auch auf Systemen mit weniger Cores möglich. Für den LANline-Test verwendeten wir drei Dell PowerEdge T640 Server, die mit je einer Intel-Xeon-10-Core-CPU, 64 GByte RAM und sechs SAS-10k-Disks mit einer Raw-Kapazität von 3,3 TByte sowie einer SAS-15k-Disk für das Red-Hat-Betriebssystem ausgerüstet waren.

Vorbereitung der Installation

Die Verwaltung der von den Cluster-Nodes bereitgestellten Ressourcen erfolgt über eine spezielle Hosted-Engine-VM. Diese VM wird automatisch hochverfügbar konfiguriert und kann auf jedem Knoten des Clusters laufen. Für die Kommunikation der Cluster-Nodes und der darauf laufenden VMs kommen ein Frontend-Management-Netzwerk und außerdem ein Back-end-Storage-Netzwerk mit mindestens 10-GBit/s-Ethernet zum Einsatz.

Als lokalen Datenspeicher empfiehlt Red Hat aus Leistungsgründen den Einsatz von SSDs. Falls man aus Kostenerwägungen HDDs nutzt, lässt sich ein SSD-Laufwerk als LVM-Cache (Logical Volume Manager) hinzufügen, um die Datenzugriffe zu beschleunigen. RHHI-V lässt sich sowohl auf Servern mit per HBA angebundenen JBOD-Disks als auch auf Systemen mit RAID-Controllern und RAID-5- oder RAID-6-Konfiguration installieren. Die RAID-Controller müssen über einen batteriegepufferten Write-Cache verfügen.

Unabhängig von der physischen Disk-Konfiguration stellt RHHI-V die Redundanz der Daten im Cluster-Verbund sicher, indem es jeden Datenblock standardmäßig per Replikation immer auf mehrere Nodes schreibt. Der Administrator kann vorgeben, dass RHHI-V die Daten auf alle drei Nodes verteilt oder nur zwei Datenkopien erstellt und der dritte Node lediglich die zugehörigen Metadaten speichert. Mit dem Typ Distributed Volume lassen sich Daten zudem auch ohne Redundanzkopie auf nur einem Laufwerk ablegen.

Vor dem Setup von RHHI-V muss der Administrator entscheiden, ob er für eine effiziente Nutzung der Speicherressourcen die Thin-Provisioning-Funktion oder den Virtual Data Optimizer (VDO) nutzen will, der eine Deduplizierung und Komprimierung der gespeicherten Daten durchführt. Es ist bislang nicht möglich, beide Funktionen gleichzeitig einzusetzen. Für den LANline-Test verwendeten wir für die Volumes der Guest-VMs die Thin-Provisioning-Funktion.

LANline HCI-Testreihe
  1. Windows Server 2019 Storage Spaces Direct (S2D): Link
  2. VMware Virtual SAN (vSAN): Link
  3. DataCore One Hyperconverged Virtual SAN: Link
  4. Red Hat Hyperconverged Infrastructure (RHHI): Link

Damit das Setup alle beteiligten Systeme korrekt ansprechen kann, muss die DNS-Namensauflösung inklusive Reverse Look-up fehlerfrei funktionieren. IPv6 wird für RHHI-V bislang nur als Technology Preview mit begrenztem Support unterstützt. Um die Basis für den RHHI-V-Cluster zu erzeugen, installierten wir im ersten Schritt auf den drei physischen Servern das Linux-Betriebssystem Red Hat Enterprise Virtualization Host 4.3 (RHEV) und konfigurierten eine Netzwerkkarte für die Verbindung mit dem Testnetz. Für das OS verwendeten wir eine lokale SAS-15k-HDD. Die sechs Daten-Disks wurden noch nicht konfiguriert. Damit das RHHI-V-Setup sich vom ersten RHEV-Host aus mit den anderen Hosts verbinden kann, wird der Host-Key des ersten Hosts in der known_hosts-Datei aller drei Server hinzugefügt. Zudem muss der Administrator auf dem ersten Host ein Public- und Private-Key-Paar erzeugen und den Public-Key auf die anderen Hosts kopieren, damit der Setup-Wizard sich per SSH an den Hosts anmelden kann, ohne einen Benutzer und ein Passwort anzugeben.

Nachdem wir alle Vorarbeiten abgeschlossen hatten, starteten wir auf dem ersten Host den Wizard für das Setup von RHHI-V. Der Assistent ist in der Web-Management-Konsole der RHEV-Hosts enthalten, die sich in einem Web-Browser über den Port 9090 öffnen lässt. Bei den Volumes wählten wir die JBOD-Konfiguration und übernahmen die standardmäßig vorgeschlagenen drei Volumes Engine für die Management-VM, Data für die VM-Datenpartitionen und VMstore für die VM-OS-Partitionen. Der Administrator kann bei Bedarf an dieser Stelle weitere Volumes hinzufügen. Bei der Brick-Konfiguration wiesen wir pro Host jedem Volume eine eigene physische Disk (sdb, sdc, sdd) zu und aktivierten das Thin-Provisioning. Als wir das RHHI-V-Setup gestartet hatten, erschien relativ schnell eine Fehlermeldung, dass die von uns im Wizard angegebenen physischen Disks auf dem ersten Host nicht verfügbar seien.

P01_Kasten 1
©

Der Red-Hat-Support konnte die Ursache schnell herausfinden. Wir hatten den ersten Host vor dem Start des Wizards neugestartet. Dies hatte zur Folge, dass Red Hat die lokalen Disks automatisch als Multi-Path-Devices konfiguriert und der Wizard sie dadurch nicht mehr erkannt hat. Die Lösung bestand darin, das Multi-Pathing zu deaktivieren. Dafür wird in der Konfigurationsdatei /etc/multipath.conf unter dem Abschnitt blacklist der Eintrag devnode "*" hinzugefügt. Dann werden die Pfade mit dem Befehl multipath -F neu eingelesen. Diese Anpassung führten wir auf allen drei Hosts durch. Anschließend starteten wir das RHHI-V-Deployment neu. Diesmal erkannte der Assistent die Platten und das Gluster-Setup lief erfolgreich bis zum Ende durch.

Die Redeployment-Schaltfläche des Wizards erlaubt es beim Auftreten von Fehlern, die Konfigurationsdatei manuell zu editieren oder den Wizard neu zu beginnen. Es ist zudem möglich, eine bereits durchgeführte Konfiguration auf dem ersten Host mit dem Ansible-Playbook gluster_cleanup.yml komplett zu bereinigen.

Nachdem die Gluster-Konfiguration abgeschlossen war, öffneten wir den Wizard für die Erstellung der Hosted-Engine-VM. Sie benötigt mindestens vier GByte RAM und 2 vCPUs. Die Hosted Engine wird automatisch als hochverfügbare VM konfiguriert und in der Storage Domain hosted_storage platziert, in der sich keine anderen VMs befinden sollten. Im Assistenten sind nur wenige Daten wie Name, IP-Adresse und Administrator-Passwort einzugeben.

Zum Abschluss des RHHI-V-Setups muss man noch das Gluster-Network einrichten und der zweiten Netzwerkkarte zuordnen. Da wir für unsere Testinstallation nur eine Netzwerkkarte konfiguriert hatten, fügten wir die Funktionen Migration und Gluster zum vorhandenen Management-Netzwerk hinzu.

RHHI-V-Management

Für die Verwaltung von RHHI-V-Clustern stehen dem Administrator mehrere Werkzeuge zur Verfügung. Die Hosted-Engine-VM verfügt über eine Web-basierte grafische Konsole, mit der sich die Compute-, Network- und Storage-Ressourcen des HCI-Clusters zentral verwalten lassen. Auch die Fencing-Policies für einen automatischen Neustart von Servern bei Host-Ausfällen lassen sich darüber steuern.

Wenn neue Nodes oder Laufwerke hinzukommen, kann der Administrator sie auch über die Web-basierte Management-Oberfläche der physischen Hosts konfigurieren. Der hier integrierte Gluster-Wizard ermöglicht es zum Beispiel, neue Volumes und neue Bricks anzulegen oder einen Cluster um drei weitere physische Hosts zu erweitern. Neue Volumes lassen sich alternativ auch über die Storage-Konfigurationsmenüs der einzelnen Hosts oder mittels spezieller Kommandozeilen-Tools wie gdeploy einrichten.

Zum Teil muss der Administrator in den grafischen Management-Konsolen ein wenig suchen, bis er den jeweils benötigten Menüpunkt gefunden hat. Ein neues Gluster-Volume muss man immer zunächst mit Disks von drei Nodes anlegen, um es dann im zweiten Schritt auf weitere Nodes ausdehnen zu können.

Einrichtung und Verwaltung von VMs

Um die Funktionen des RHHI-V-Clusters zu testen, installierten wir über die Hosted-Engine-Web-Konsole drei VMs mit Windows 2019, Windows 2016 und Ubuntu Linux. Im ersten Schritt konfiguriert der Administrator die VM-Hülle mit mindestens einer virtuellen Festplatte, einer Netzwerkkarte sowie der gewünschten RAM-Größe und vCPU-Anzahl. VMs lassen sich alternativ auch mit der VM-Portal-Web-Konsole erstellen und verwalten. Über die Schaltfläche Run Once kann der Administrator die Boot-Optionen für die VM wählen und ein virtuelles CD-Laufwerk mit der passenden Betriebssystem-ISO-Datei sowie ein virtuelles Floppy-Drive mit zusätzlich benötigten Treibern anbinden. Bei der Installation von Windows muss der Administrator im Setup-Dialog die Virtio-Treiber für den Storage-Controller hinzufügen. Wir verbanden deshalb die Windows-VMs mit einem virtuellen Diskettenlaufwerk, das diese Treiber enthielt.

Für den Zugriff auf die VM-Konsole installierten wir auf unserem Administrationsrechner die von Red Hat mitgelieferte Remote-Viewer-Konsole. Über die Konsole lässt sich auch die ISO-Datei des virtuellen CDROM-Laufwerkes anbinden und entfernen. Die ISO-Dateien muss der IT-Verantwortliche zuvor in eine Storage-Domain des Clusters hochladen, damit das System sie an die VMs anbinden kann. Die Installation der drei VMs verlief erfolgreich, und wir konnten auf die Windows-Server anschließend per RDP und auf das Ubuntu-System per Putty zugreifen. RHHI-V unterstützt auch Templates und zahlreiche Automatisierungs- und Workflow-Tools wie Red Hat Ansible, um VMs in größeren Stückzahlen automatisiert und standardisiert bereitzustellen.

Die Red-Hat-Virtualisierungsplattform beherrscht die marktüblichen Verfahren für einen möglichst unterbrechungsfreien Betrieb von VMs. So lassen sich VMs jederzeit im laufenden Betrieb auf andere Hosts verschieben. Eine automatische Lastverteilung zählt ebenfalls zum Funktionsumfang. Wird ein Host in den Wartungsmodus genommen, verschiebt RHHI-V die darauf laufenden VMs automatisch auf die anderen Cluster-Nodes. Wir hatten zuvor für eine VM eine Host Affinity Rule konfiguriert. Diese Regel sorgte dafür, dass die VM automatisch wieder auf diesen Host zurückverschoben wurde, nachdem wir den Wartungsmodus beendet hatten.

Eine Storage-Migration ist ebenfalls möglich. Sie lässt sich über das Disk-Menü einer VM mit dem Move-Befehl starten. Wir verlagerten eine Test-VM im laufenden Betrieb von der Storage-Domain Data in die Domain Vmstore. Die Migration dauerte rund 15 Minuten.

VM-Snapshots

RHHI-V unterstützt auch Snapshots auf VM- und auf Volume-Ebene. Der Administrator kann zudem von einem VM-Snapshot einen Clone oder ein Template für das VM-Deployment erstellen. Der Snapshot lässt sich wahlweise mit oder ohne RAM-Inhalt erstellen.

Wir erstellten von einer VM an einem Abend einen Snapshot und setzten die VM am darauffolgenden Nachmittag auf den alten Snapshot-Stand zurück. Dazu fuhren wir die VM herunter und klickten in der RHHI-V-Konsole im VM-Snapshot-Menü zunächst die Schaltfläche Preview an. Damit lässt sich prüfen, ob der VM-Snapshot den gewünschten Systemzustand enthält. In den Event-Logs konnten wir sehen, dass die letzten Einträge vom Vorabend waren. Mit einem Klick auf Commit setzten wir die VM auf diesen Stand zurück. Die Erstellung einer Clone-VM funktionierte ebenfalls reibungslos und die neue VM ließ sich direkt hochfahren, sobald der Clone-Vorgang abgeschlossen war.

Für ein Disaster Recovery (DR) unterstützt RHHI-V eine Georeplikation zu einem entfernten Standort, die allerdings auf ein Volume beschränkt ist. Red Hat empfiehlt, das Volume mit den Datenpartitionen der VMs an den DR-Standort zu replizieren. Zusätzlich benötigt die Georeplikation ein Shared-Storage-Volume. Das Ziel-Volume muss von einem eigenen Red-Hat-Virtualization-Manager-System verwaltet werden und die Kommunikation muss bislang über IPv4 erfolgen.

Um die Datenredundanz zu testen, entfernten wir im laufenden Betrieb aus dem Host RHHIH2 die Festplatte, auf der eine Kopie des Data-Volumes lag. Der Disk-Ausfall hatte auf die auf dem Data-Volume gespeicherten VMs keinerlei Auswirkungen, da noch zwei Replika-Kopien vorhanden waren. Die VMs liefen ohne Unterbrechung weiter. Nachdem wir die Platte wieder eingeschoben hatten, konnten wir sie mit den anderen zwei Kopien synchronisieren.

Zum Abschluss testeten wir den Ausfall eines kompletten Hosts, indem wir den Server RHHIH3 über den Power-Button hart ausschalteten. Zuvor hatten wir bei zwei Windows-VMs in den VM-Einstellungen die Hochverfügbarkeitsoption aktiviert und sie auf dem RHHIH3 platziert. Beide VMs waren nach dem Ausschalten des Hosts zunächst nicht mehr verfügbar, wurden aber von RHHI-V nach etwa einer Minute auf einem der aktiven Hosts automatisch wieder hochgefahren. Nachdem wir den dritten Host wieder eingeschaltet hatten, wurde die VM, für die wir den RHHIH3 als bevorzugtes System konfiguriert hatten, nach wenigen Minuten wieder auf diesen Host zurückverschoben.

Die RHHI-V-Konsole hat sowohl beim Disk- als auch beim Host-Ausfall eine Warnmeldung angezeigt. Der Administrator kann für die verschiedenen Events eine Alarmierung per SNMP-Traps oder per E-Mail konfigurieren.

Fazit

Abgesehen von dem Multi-Path-Problem bei der Installation lief die HCI-Plattform stabil und zeigte auch bei den Ausfalltests keine Schwächen. Die Speicherkapazität lässt sich durch eine Erweiterung vorhandener Volumes oder durch die Anlage neuer Volumes mit zusätzlichen Disks sukzessive ausbauen. Host-Erweiterungen müssen aufgrund des verwendeten Datenredundanz-Verfahren jeweils mit drei zusätzlichen Nodes durchgeführt werden. Für die Verwaltung stehen leicht verständliche Web-Konsolen zur Verfügung.

Christoph Lange.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

Weniger ist manchmal mehr
HCI mit VMware  vSAN 6.7
HCI richtig implementieren

Verwandte Artikel

HCI

Red Hat