Clustering

Runecast Academy Serie 1 - Teil 9. Clustering

Was verstehen wir also unter Clustering? Clustering ist die Zusammenlegung der Ressourcen in Ihrem Rechenzentrum. Nehmen wir an, Sie haben zehn Server mit jeweils 2 CPUs und 12 Kernen pro CPU und 512 GB RAM pro Server. Sie haben nun 240 CPU-Kerne und 5 TB RAM zu Ihrer Verfügung! Dies ist eine vereinfachte Betrachtungsweise, da keine einzelne VM mehr Rechenleistung verbrauchen kann als die auf einem einzelnen Host verfügbaren Ressourcen, aber sobald Sie diese Ressourcen zusammenlegen, können Sie einige coole Sachen machen.

Was ermöglicht das Clustering?

Wir sind froh, dass Sie gefragt haben! Wie wir oben angedeutet haben, bringt Clustering die lustigen Unternehmens-Tools auf den Tisch. Werfen wir einen Blick darauf, was das bedeutet.

Ressourcenpools

Ressourcenpools sind ein Konstrukt, das es Ihnen ermöglicht, die soeben zusammengefassten Ressourcen in das Konstrukt eines Clusters aufzuteilen. Sie können sie verwenden, um den Zugriff auf verfügbare Ressourcen für bestimmte VMs zu priorisieren. Am einfachsten kann man sich diese als eine Reihe von Torten vorstellen. Der oberste Kuchen ist der Cluster, und wenn Sie keine weiteren Ressourcenpools erstellen, haben alle VMs gleichen Zugriff auf die verfügbaren Ressourcen im Cluster. Wenn es zu einem Ressourcenkonflikt kommt (wenn die Nachfrage nach einer oder mehreren Ressourcen größer ist als der verfügbare Ressourcenpool), sind alle VMs gleichermaßen betroffen. Mit diesem Konstrukt können Sie CPU und RAM aufteilen und auch Ressourcenpools ineinander verschachteln.

Zwei Dinge gilt es zu beachten... Ressourcenpools und VMs sollten keine Geschwister in der Hierarchie sein, da dies unbeabsichtigte Folgen haben kann. Außerdem können und sollten Ressourcenpools nicht verwendet werden, um VMs auf dieselbe Weise zu organisieren, wie Sie es mit Ordnern tun würden. Verwenden Sie dafür Ordner, und seien Sie nicht dieser Typ.

vMotion

Noch heute erinnern wir uns an das erste Mal, als wir vMotion in Aktion sahen. Für diejenigen unter Ihnen, die noch nichts von vMotion gehört haben, ist es im Grunde genommen Magie. Sie ermöglicht es Ihnen, eine VM, die auf einem Host läuft, über ein Netzwerk auf einen anderen Host zu verschieben, ohne diese VM ausschalten zu müssen. Heutzutage ist das eine Selbstverständlichkeit (Mindestanforderung für den Markteintritt), aber früher war das der Hammer. Es bedeutete, dass wir, wenn wir einen Host für ein Patching herunterfahren oder sogar den Host komplett ersetzen mussten, dies problemlos tun konnten. Es bedeutet auch, dass wir die Infrastruktur, die die Umgebung unterstützt, skalieren können, wenn unsere Arbeitslasten dies erfordern.

Während in der Vergangenheit der Cluster die Grenze für vMotion-Aktionen darstellte, können sie jetzt zwischen Clustern und sogar zwischen Rechenzentren durchgeführt werden.

HA

HA steht für High Availability, nicht zu verwechseln mit FT (Fault Tolerance). Hochverfügbarkeit überwacht die Hosts in einem Cluster und startet nach dem Ausfall eines Host-Servers die VMs, die auf diesem Host liefen, an anderer Stelle im Cluster neu.

Was aber, wenn Ihre vCenter Server Appliance eine dieser Maschinen auf dem ausgefallenen Host ist? Kein Problem! 

Zur Erstellung eines HA-Clusters muss vCenter einen Agenten (FDM oder "Fault Domain Manager") auf jedem Host im Cluster bereitstellen. Sobald dies abgeschlossen ist, findet ein Wahlprozess zwischen den Hosts selbst statt. Das FDM-Modul (auch als VIB oder VMware Installable Bundle bezeichnet) überwacht aktiv die Verfügbarkeit der Hosts im Cluster. Wenn ein Host als ausgefallen gilt, werden die VMs, die auf dem ausgefallenen Host liefen, an anderer Stelle im Cluster neu gestartet. Und das Beste daran? Selbst wenn sich vCenter Server auf dem ausgefallenen Host befindet, funktioniert dies ohne Probleme.

Ihre VMs haben also immer noch eine kleine Ausfallzeit. Dennoch wird der Dienst schnell wieder aufgenommen, anstatt darauf zu warten, dass Ihr Überwachungstool feststellt, dass eine Reihe von VMs und ein Host nicht mehr verfügbar sind, und jemandem ein Ticket zur Untersuchung zuweist.

Zwei Dinge sind bei HA zu beachten... da die VM nicht sauber heruntergefahren wurde, ist es möglich, dass einige zusätzliche Dinge geschehen müssen, wie z.B. eine Dateisystemprüfung. Zweitens erfordert HA irgendeine Art von gemeinsamem Speicher, da ein überlebender Host sofortigen Zugriff auf die Dateien haben muss, aus denen die VM besteht.

FT

Wie im vorherigen Abschnitt erwähnt, steht FT für Fault Tolerance (Fehlertoleranz). Wenn vMotion wie Magie wirkt, dann ist FT so etwas wie Voodoo. Es startet eine zweite, identische VM auf einem anderen Host, und diese VM wird über ein spezielles FT-Logging-Netzwerk im Gleichschritt gehalten. Wenn der Host mit der primären VM ausfällt, läuft das Gastbetriebssystem einfach weiter (und wird zur neuen primären VM), und eine neue sekundäre VM wird auf einem anderen Host hochgefahren. Wie Sie sich vorstellen können, kann dies ein Werkzeug sein, um die Dinge am Laufen zu halten, wenn die Hardware ausfällt. Es ist jedoch nicht ohne Vorbehalte. Da eine zweite VM zur gleichen Zeit laufen muss, verdoppelt sich der Ressourcenverbrauch. Außerdem ist ein dediziertes Fehlertoleranznetzwerk erforderlich, und die Anzahl der vCPUs sowie die Anzahl der FT-VMs pro Host ist begrenzt. Schließlich sind mehrere vSphere-Funktionen nicht mit Fault Tolerance kompatibel, z. B. Snapshots, Verschlüsselung und mehr.

‍

DRS

DRS ist der Distributed Resource Scheduler, der zum Ausgleich von Arbeitslasten zwischen Hosts in einem Cluster verwendet wird. Er nutzt vMotion (und als solches ist ein vMotion-Netzwerk erforderlich), um Arbeitslasten von einem Host zu einem anderen zu migrieren, und zwar in Übereinstimmung mit einer Reihe von Algorithmen, die in das Produkt integriert sind. Wenn Sie DRS auf einem Cluster aktivieren, legen Sie eine Automatisierungsstufe fest. Diese Stufe kann Manuell sein (dann gibt DRS Empfehlungen, wohin eine Arbeitslast verschoben werden sollte). Die nächste Stufe ist Teilautomatisiert (DRS wählt beim Einschalten automatisch einen Host aus, auf dem eine VM ausgeführt werden soll, gibt dann aber Empfehlungen, wohin sie verschoben werden soll). Schließlich (und am häufigsten verwendet) gibt es Fully Automated (DRS gleicht Arbeitslasten automatisch aus, ohne dass ein menschliches Eingreifen erforderlich ist). Darüber hinaus ist ein Migrationsschwellenwert verfügbar. Durch die Anpassung des Migrationsschwellenwerts können Sie DRS so einstellen, dass es nicht ständig Workloads vMotion-verschiebt (da der Vorgang der vMotion zu Leistungseinbußen bei einigen Workloads führen kann, ist es am besten, dies auf ein Minimum zu beschränken.

vSAN

Obwohl vSAN nicht in der regulären vSphere-Lizenz enthalten ist, handelt es sich um eine coole Technologie, die auch das Clustering nutzt. Für Uneingeweihte: vSAN nutzt den in jedem ESXi-Host vorhandenen lokalen Speicher und erstellt einen Speicherpool. Dieser Storage wird dann allen Hosts im Cluster zur Verfügung gestellt, auch wenn einige Hosts selbst keinen Storage bereitstellen. vSAN ist eine wichtige Komponente von VMware Cloud on AWS, VMware Cloud Foundation und den VxRail-Angeboten von Dell EMC und als solche ein wichtiger Akteur im Bereich HCI (HyperConverged Infrastructure) - laut IDC hat VMware HCI einen Marktanteil von 41,1%. Wenn Sie mehr über vSAN erfahren möchten, besuchen Sie doch den VMware-Blog Virtual Blocks.

Zusammenfassung

Damit ist dieses Kapitel so gut wie abgeschlossen. Wir hoffen, dass wir Ihnen nun etwas mehr Klarheit darüber verschafft haben, was wir mit dem Begriff "Cluster" meinen und welche coolen Funktionen Ihnen damit zur Verfügung stehen. Sie können alle Arten von Ressourcen zusammenfassen und Ressourcenpools verwenden, um diese Ressourcen aufzuteilen und bei Bedarf zu priorisieren. Sie können auch DRS nutzen, um Arbeitslasten über die Hosts in einem Cluster hinweg auszugleichen und so den Noisy Neighbour-Effekt zu umgehen. Wenn all diese Tools richtig eingerichtet sind und funktionieren, kann Ihr SDDC gewissermaßen selbstheilend sein - mit HA und FT werden Ihre Workloads bei Hostausfällen automatisch wiederhergestellt, und DRS wird eingesetzt, um die Workloads auf die verfügbaren Ressourcen zu verteilen und so die beste Leistung zu erzielen. 

Das war's für dieses Kapitel. Besuchen Sie uns beim nächsten Mal, wenn wir uns mit Automatisierung, CLIs und Entwicklerschnittstellen befassen! Wir hoffen, dass Sie dieses Kapitel oder die Runecast Academy hilfreich fanden, und freuen uns über jedes Feedback. Sprechen Sie uns auf Twitter an!

‍