Tags: vSphere, Load Balancing, Cluster, Hochverfügbarkeit
DRS sorgt im Cluster zwar für eine ausgeglichene Lastverteilung, ignoriert aber bei der Platzierung von VMs andere Aspekte. Das gilt etwa für die Verfügbarkeit von VMs oder die Performance von Anwendungen, die aus mehreren VMs bestehen. Admins können jedoch über Regeln bestimmte Platzierungen erzwingen.
Vorstellbar ist durchaus ein Szenario, in dem ein DRS-Cluster aus 3 ESXi-Hosts besteht, von denen zwei überhaupt keine VMs ausführen, während der dritte 20 VMs hostet. Solange es nämlich auf dem Server mit den 20 VMs zu keinerlei Leistungsproblemen oder Ressourcenkonflikten kommt, wird DRS je nach Migrationsschwellenwert und Default-Einstellungen keine VMs verschieben.
Regeln zur Steuerung des DRS-Verhaltens
In Hinblick auf vSphere HA und den Schutz einzelner VMs gegen einen Host-Ausfall wäre es aber besser, VMs auf die anderen Hosts im Cluster zu verteilen. DRS sah lange Zeit keine Möglichkeit zur zahlenmäßig gleichen Verteilung von VMs vor, und erst in neueren Versionen gibt es dafür die Option VM-Verteilung. Aber unabhängig davon kann man das Verhalten von DRS auch durch explizite Regeln beeinflussen.
Die entsprechenden Optionen dazu finden sich im Cluster-Hauptmenü in den Abschnitten VM/Host-Gruppen und VM/Host-Regeln. Die hier definierbaren Regeln betreffen nicht nur vSphere DRS, sondern auch HA, weil beide Features einander beeinflussen.
Unter VM/Host-Regeln können Sie mit einem Klick auf den Knopf Hinzufügen solche Regeln erstellen, die bestimmen, wie die im unteren Teil des Dialogfelds aufgenommenen virtuellen Maschinen sich zueinander verhalten sollen, wenn DRS eine vMotion-Operation zwecks Load-Balancing als notwendig erachtet.
VMs auf einem Host zusammenhalten
Hierbei sind grundsätzlich Szenarien vorstellbar, in denen zwei (oder mehrere) VMs, die häufig direkt miteinander interagieren, aus Latenz- oder anderen technischen Gründen besser gemeinsam auf dem gleichen Host laufen ("Virtuelle Maschinen zusammenhalten").
Sie profitieren dann u. a. von Shared-Memory bzw. allgemein von der direkten Kommunikation bestimmter virtueller Hardware über das Host-Memory.
Ein weiteres Beispiel hierfür wäre ein Frontend-Webserver, der mit einer Backend-Datenbank große Datenströme unterhält. Operieren beide im selben vLAN, dann läuft auch der Netzwerkverkehr intern über den gleichen Host, was wiederum den physischen Netzwerk-Traffic entlastet.
VMs auf mehrere Hosts verteilen
Auch für das Trennen bestimmter VMs ("Separate virtuelle Maschinen") sind Gründe vorstellbar. So könnte man etwa zwei virtuelle Domänen-Controller immer separieren, um eine bessere Verfügbarkeit zu erreichen. Ebenso denkbar wäre, zwei besonders Last- oder I/O-Intensive VMs (etwa SQL-Server und Exchange) möglichst auf separaten Hosts zu betreiben.
Ferner kann man mit dem Regeltyp "Virtuelle Maschinen zu Hosts" erzwingen, dass die hier angegebenen virtuellen Maschinen immer auf einem bestimmten Host ausgeführt werden sollen, weil dieser etwa für sie die besten Voraussetzungen bietet.
Gruppen über Regel verknüpfen
Um eine VM-zu-Host-Regel umzusetzen, benötigt man zuvor je eine VM- bzw. Host-Gruppe. Diese werden im gleichnamigen Menü VM-Host-Gruppen eingerichtet. In der Abbildung wurde eine Gruppe für Hosts erstellt, die mit einer XEON E5-CPU ausgestattet sind. Die Gruppe enthält aktuell nur einen Host.
Danach erstellt man eine VM-Gruppe für alle virtuellen Maschinen, die von einem Host mit einer solchen CPU besonders profitieren.
Auf Basis dieser beiden Gruppen lässt sich dann eine VM-to-Host-Regel erstellen, welche die Beziehung zwischen VMs und Hosts definiert.
Dringlichkeit von Regeln
Allerdings wird es mit zunehmender Anzahl von VM-Affinitäts-, Anti-Affinitäts- und VM-zu-Host-Regeln für DRS immer schwieriger, überhaupt noch DRS-Empfehlungen unter Berücksichtigung dieser Vorgaben umzusetzen.
Daher bietet die VM-zu-Host-Regel zwischen den beiden Auswahllisten für die VM-Gruppe und die Host-Gruppe eine weitere Liste, mit der man die Dringlichkeit der Regelbeachtung beeinflussen kann. Diesem Zweck dienen die Kriterien "Muss …", "Sollte ...", "Darf nicht …" oder "Sollte nicht …".
Eine affinitive Sollte-Regel oder eine anti-affinitive Sollte-Nicht-Regel gibt DRS im Ernstfall mehr Spielraum, die Regel doch zu brechen. So lassen sich VMs im Normalbetrieb auf Basis solcher Trennungsregeln auf festgelegten Hosts betreiben, zugleich ist aber auch ein gewisser Schutz beim Ausfall eines Racks gewährleistet.
Gerade bei Blade-Servern ist das Trennen von VMs nach bevorzugter Hardware besonders wichtig, denn hier kann ein Chassis- oder Rack-Fehler aufgrund der deutlich höheren Dichte von VMs pro Blade-Rack beträchtliche Folgen haben.
Zusammenspiel von DRS und HA
Vielleicht vermisst der eine oder andere Nutzer eine noch bis vSphere 6.0 im Web Client vorhandene Option, mit der sich beim Erstellen von DRS-Regeln das DRS-Verhalten in Bezug auf HA konfigurieren ließ.
Mit der UI-Option HA must respect VM anti-affinity rules during failover bzw. HA should respect VM to Host affinity rules during failover konnte man in vSphere 6.0 die Fähigkeit von vSphere-HA steuern, VM-Host-Affinity oder VM-VM-Anti-Affinity-Regeln zu respektieren.
Dass diese Option in vSphere 6.5 nicht mehr auftaucht, liegt aber schlicht daran, dass vSphere HA jetzt versucht, diese Regeln standardmäßig zu beachten, da dies das Verhalten ist, welches offenbar die meisten Kunden ohnehin bevorzugten.
Man sollte aber Folgendes beachten: Kann vSphere HA eine solche Regel aus welchen Gründen auch immer nicht respektieren, werden VMs trotz Verletzung der Regel neu gestartet, da es sich um nicht obligatorische Regeln handelt und vSphere die Verfügbarkeit über die Compliance stellt.
Möchte man dieses Verhalten deaktivieren, so dass sich HA bei einem Failover nicht um diese Regeln kümmert, dann geht das über eine der erweiterten Optionen:
das.respectVmVmAntiAffinityRules = false
oder
das.respectVmHostSoftAffinityRules = false
Beide Parameter stehen per Default auf true.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- vSphere mit Tanzu auf Basis von vSphere-Networking (Distributed vSwitch) einrichten
- VMs bei Absturz des Gast-OS über vSphere HA Application Monitoring neu starten
- VMware vSphere: Hyperkonvergente Cluster einrichten, VMs hochverfügbar machen, Last verteilen mit DRS
- vSphere vMotion: LACP und Distributed vSwitch
- vSphere Proactive HA, Quarantäne-Modus und DRS mit vFlash
Weitere Links