VMware DRS und HA: Mit den richtigen Regeln zur höheren Verfügbarkeit

VMware HA und DSR können die Performance und Verfügbarkeit virtueller Umgebungen spürbar erhöhen – wenn sie richtig konfiguriert sind.

VMwares Distributed Resource Scheduler (DRS) und High Availability (HA) bilden die beiden Eckpunkte von VMwares...

Produktfamilie zum Management virtueller Umgebungen. VMware DRS nutzt vMotion für die leistungs- und zuverlässigkeitssteigernde Lastverteilung von Servern über mehrere Hosts hinweg, während VMware High Availability virtuelle Maschinen (VMs) im Fall eines Serverver-Ausfalls neu startet.

Beide Features sind seit einigen Versionen Teil von ESX/ESXi und sind effektive Produkte, auf die Administratoren sich zu verlassen gelernt haben. Das bedeutet aber noch lange nicht, dass auch jeder das volle Potenzial dieser Lösungen ausschöpft. Die Regeln für beide weisen bemerkenswerte Überschneidungen auf, weshalb man nicht sagen kann, dass ein Produkt das andere erübrige. Vielmehr wird man für das effektive Management eher beide Produkte benötigen.

In diesem Artikel werfen wir einen Blick auf einige Aspekte, mit deren Hilfe Sie Leistung und Verfügbarkeit ihrer Umgebung verbessern können.

VMware DRS optimiert die Leistung

Während VMware DRS zur Leistungserhaltung zwar die ausgleichende Lastverteilung einsetzt, achtet das Tool dennoch nicht auf die Anzahl virtueller Maschinen pro Host. Deshalb ist ein Szenario denkbar, in dem Sie von drei online gestellten ESXi-Hosts zwei gänzlich ohne VMs und den dritten mit 30 VMs betreiben. 

Treten auf dem exemplarischen Host mit 30 VMs weder Leistungsprobleme noch Ressourcenkonflikte auf, so wird DRS keine einzige VM migrieren. Natürlich wäre aber eine Verteilung der 30 VMs auf alle drei Hosts eine wesentlich bessere Vorkehrung gegen den potenziellen Ausfall eines Hosts. DRS nimmt eine solche Anpassung auf Basis der VM-Anzahl aber wie gesagt nicht vor. Allerdings können Sie DRS mit sorgfältig eingesetzten Regeln ein wenig Unterstützung bieten.

Beginnen wir mit den beiden Schlüsselkategorien für das Erstellen von HA- und DRS-Regeln: Zu trennende VMs und zusammenzuhaltende VMs.

VMs zu separieren wirkt sehr einfach, auch die Vorteile liegen auf der Hand. Haben Sie beispielsweise zwei Active-Directory-Controller oder Print-Server, so werden Sie diese zur Schadensminimierung bei einem Host-Ausfall in aller Regel auf zwei unterschiedlichen Hosts betreiben wollen. 

Mit anwachsenden Umgebungen wird die Sache mit dem einfachen Separieren allerdings ein wenig komplexer. Geben Sie vor, bestimmte VMs voneinander zu trennen, so tun Sie dies für gewöhnlich zur Erzielung eines Ausfallschutzes. Separieren Sie nun aber die VMs auf zwei Hosts, die wiederum im selben physischen Rack untergebracht sind, mögen Sie sich vor reinen Host-Ausfällen geschützt haben. Ein Ausfall des Racks, beispielsweise in der Strom- oder Netzwerkversorgung, bringt Sie jedoch unverändert in Not.

An genau dieser Stelle setzt die Überlegung an, dass eine bevorzugte („preferred“) anstelle einer zwingenden („required“) Hardwarezuweisung für VMs von Vorteil ist. So können die VMs nach Maßgabe der Trennungsregeln auf festgelegten Hosts betrieben werden, gleichzeitig wird aber auch für den Fall eines Rack-Ausfalls vorgesorgt.

„Preferred“ statt „required“: Hardwarezuweisung für virtuelle Maschinen

Die Vorteile des Trennens von VMs auf bevorzugte Hardware zeigen sich in Blade-Server-Umgebungen noch viel deutlicher. Denn ein Chassis- oder Rack-Fehler kann aufgrund der viel höheren Dichte von VMs pro Blade-Rack vernichtende Ausmaße für eine virtualisierte Umgebung annehmen. 

Auch wenn beim Entwurf virtualisierter Umgebungen meist Konsolidierung und Leistung im Vordergrund stehen, darf der Aspekt der Fehlertoleranz keinesfalls vernachlässigt werden. Bei Blade-Systemen kann das beispielsweise mit sich bringen, die Anzahl von Blade-Modulen in einem Rack zu verringern, um die gewünschten HA- und DRS-Regeln besser zu unterstützen.

Natürlich gibt es auch Gründe, VMs auf demselben Host halten zu wollen. Ideal ist dies beispielsweise für VMs, die regelmäßig untereinander kommunizieren. Ein perfekter Kandidat für ein solches Szenario ist ein Frontend-Webserver, der mit einem Backend-Datenbankserver erhebliche Datenströme unterhält. Befinden sich beide im selben vLAN, so kann der Netzwerkverkehr intern auf demselben Host ablaufen, womit der physische Netzwerk-Traffic enorm entlastet wird.

Zugegebenermaßen stellt dies wiederum für HA-Regeln ein Problem dar – wo aber liegt das Problem, wenn beide Server ausfallen? Sind die Server voneinander abhängig, so ist es bei einem Ausfall unwichtig, wenn einer von beiden weiter läuft. Ein Problem zweier VMs auf einem Host ist aber möglicherweise die falsche Reihenfolge, in der sie gestartet werden könnten. Dem kommen Sie zuvor, indem Sie die VMs in einer vApp organisieren, wodurch Sie die Startreihenfolge und etwaige Verzögerungen festlegen können.

Während der prioritären Startreihenfolge von VMs viel Aufmerksamkeit zukommt, sind auch nicht-automatisch neu zu startende VMs eine valide und überlegenswerte Option. Test- und Entwicklungsserver könnten etwa beim initialen Starten ausgelassen werden, um Ressourcen für zusätzliche Produktions-VMs freizuhalten.

VMware High Availability erlaubt Ihnen auch die Übersteuerung von Ressourceneinschränkungen. Praktisch bedeutet dies, dass eine VM dann nicht gestartet wird, wenn ein Cluster nicht über ausreichende Ressourcen verfügt, um das erfolgreiche Starten dieser VM gewährleisten zu können. Übersteuern Sie nun eine solche Ressourceneinschränkung, so wird die VM trotzdem gestartet, auch wenn sie aufgrund der Ressourcenknappheit unter Leistungseinbußen leiden mag.

Test- und Entwicklungs-VMs nicht neu zu starten stellt zwar zusätzliche Ressourcen bereit, durch das Übersteuern einer entsprechenden Ressourceneinschränkung werden sie aber dennoch gestartet. Sie mögen dann langsamer laufen, in manchen Fällen ist dies jedoch besser, als wenn sie gar nicht laufen.

Sichern Sie Ihre HA- und DRS-Regeln durch Dokumentation

Innerhalb der HA- und DRS-Konfigurationsbildschirme steht Ihnen kein einfacher Weg zum Export der Regeln oder zur Konfiguration zur Verfügung. Das hat zur Folge, dass ein kritischer Teil Ihrer Infrastruktur völlig undokumentiert bleibt. Kaum jemand geht davon aus, solche Regeln jemals zu verlieren. Tatsächlich ist der einzige Weg dazu neben dem absichtlichen Löschen der Regeln die komplette Deaktivierung von HA und DRS. Und wer würde das schon tun?

Unglücklicherweise passiert das öfter, als Sie denken mögen. In zwei ganz unterschiedlichen Fällen habe ich selber schon sogar zertifizierte VMware-Fachleute beobachtet, die VMware DRS/HA auf einem Cluster deaktiviert haben. 

Statt Host-Monitoring abzuwählen und von DRS auf manuellen Modus zu wechseln, deaktivierten sie die HA- und DRS-Kontrollkästchen in den Cluster-Einstellungen, womit beide Features komplett vom Server entfernt werden. Natürlich gibt es bei diesem Vorgehen einen ausdrücklichen warnenden Dialog. Würde er doch nur gelesen werden.

Wenngleich dieses Vorgehen nicht für Neustarts bei Gästen oder Hosts sorgt, löscht es jede einzelne Ihrer HA- und DRS-Regeln, Ressourcenpools eingeschlossen. Anders als in anderen Anwendungen gibt es hier natürlich auch keine Zurück-Schaltfläche – die Regeln sind zu diesem Zeitpunkt schlicht für immer verschwunden.

Es sei denn, Sie haben sich die Zeit genommen, diese zu dokumentieren. Ein solches Vorkommnis mag Ihnen heute unwahrscheinlich erscheinen. Tritt es aber ein, könnte Ihnen ein Arbeitsblatt mit den Regeln für die Separation von VMs, HA-Startprioritäten und Ressourcenpool-Einstellungen den Hals retten.

Über den Autor:
Brian Kirsch ist an der Milwaukee Area Technical College ein IT-Architekt und -Ausbilder. Sein Hauptfokus liegt dabei auf Virtualisierung im Bereich Storage. Seit über 15 Jahren arbeitet er in der IT-Branche – mit VMware-Produkten beschäftigt er sich seit über sieben Jahren. Er verfügt über mehrere Bescheinigungen, unter anderem von Microsoft, CommVault, VMware and EMC. Seit 2012 ist er Mitglied beim VMUG Global Board of Directors.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im April 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über VMware

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close