Um optimale Fault Tolerance-Ergebnisse erzielen zu können, sollten Sie bestimmte Best Practices einhalten.

Mit den folgenden Empfehlungen für die Host- und Netzwerkkonfiguration lassen sich die Stabilität und Leistung Ihres Clusters verbessern.

Hostkonfiguration

Hosts, auf denen die primären und sekundären virtuellen Maschinen ausgeführt werden, sollten mit annähernd denselben Prozessorfrequenzen arbeiten, andernfalls könnte es sein, dass die sekundären virtuellen Maschinen häufiger neu gestartet werden. Plattform-Energieverwaltungsfunktionen, die sich nicht abhängig von der Arbeitslast anpassen (z. B. die Energiebeschränkung und erzwungene Niedrigfrequenzmodi zum Einsparen von Energie), können große Abweichungen der Prozessorfrequenzen verursachen. Falls sekundäre virtuelle Maschinen regelmäßig neu gestartet werden, deaktivieren Sie alle Energieverwaltungsmodi auf den Hosts, die fehlertolerante virtuelle Maschinen ausführen, oder stellen Sie sicher, dass alle Hosts im selben Energieverwaltungsmodus laufen.

Hostnetzwerkkonfiguration

Anhand der folgenden Richtlinien können Sie das Netzwerk Ihres Hosts konfigurieren, um Fault Tolerance mit verschiedenen Kombinationen von Datenverkehrstypen (z. B. NFS) und mehreren physischen Netzwerkkarten zu unterstützen.

  • Verteilen Sie jede Netzwerkkartengruppe über zwei physische Switches, um die L2-Domänenkontinuität für jedes VLAN zwischen den zwei physischen Switches zu gewährleisten.
  • Verwenden Sie deterministische Gruppierungsrichtlinien, um sicherzugehen, dass bestimmte Datenverkehrstypen eine Affinität mit einer bestimmten Netzwerkkarte (Aktiv/Standby) bzw. mit mehreren Netzwerkkarten (z. B. ID des virtuellen Quell-Ports) haben.
  • Paaren Sie Datenverkehrstypen dort, wo Aktiv/Standby-Richtlinien verwendet werden, um in einer Failoversituation die Auswirkungen zu minimieren, wenn beide Datenverkehrstypen eine vmnic teilen.
  • Konfigurieren Sie dort, wo Aktiv/Standby-Richtlinien verwendet werden, alle aktiven Adapter eines bestimmten Datenverkehrstyps (z. B. Fault Tolerance-Protokollierung) für denselben physischen Switch. Dies minimiert die Anzahl der Netzwerk-Hops und reduziert die Chancen, dass die Switch-zu-Switch-Links überbucht werden.
Hinweis: Der Datenverkehr für die Fault Tolerance-Protokollierung zwischen den primären und sekundären virtuellen Maschinen erfolgt unverschlüsselt und enthält Gastnetzwerk- und Storage I/O-Daten sowie die Speicherinhalte des Gastbetriebssystems. Dieser Datenverkehr kann vertrauliche Daten enthalten, wie z. B. Kennwörter im Klartext. Um zu verhindern, dass solche Daten preisgegeben werden, stellen Sie sicher, dass dieses Netzwerk gesichert ist, insbesondere gegen so genannte „Man-in-the-middle“-Angriffe. Verwenden Sie z. B. ein privates Netzwerk für den Datenverkehr für die Fault Tolerance-Protokollierung.

Homogene Cluster

vSphere Fault Tolerance kann in Clustern mit uneinheitlichen Hosts arbeiten, am besten funktioniert sie jedoch in Clustern mit kompatiblen Knoten. Wenn Sie Ihren Cluster erstellen, sollten alle Hosts über folgende Konfiguration verfügen:

  • Gemeinsamen Zugriff auf Datenspeicher, die von den virtuellen Maschinen verwendet werden.
  • Dieselbe Netzwerkkonfiguration für virtuelle Maschinen.
  • Dieselben BIOS-Einstellungen (Energieverwaltung und Hyper-Threading) für alle Hosts.

Führen Sie Übereinstimmung prüfen aus, um Inkompatibilitäten zu identifizieren und zu beheben.

Leistung

Verwenden Sie zur Erhöhung der Bandbreite, die für den Protokollierungsdatenverkehr zwischen primären und sekundären virtuellen Maschinen verfügbar ist, eine 10 Gbit-Netzwerkkarte und aktivieren Sie die Verwendung von Jumbo-Frames.

Sie können mehrere Netzwerkkarten für das Fault Tolerance-Protokollierungsnetzwerk auswählen. Indem Sie mehrere Netzwerkkarten auswählen, können Sie die Bandbreite mehrerer Netzwerkkarten nutzen, auch wenn nicht alle Netzwerkkarten für die Ausführung von Fault Tolerance reserviert sind.

Speichern von ISOs auf gemeinsam genutztem Speicher für einen unterbrechungsfreien Zugriff

Speichern Sie ISOs, auf die durch virtuelle Maschinen mit aktivierter Fault Tolerance zugegriffen wird, auf gemeinsam genutztem Speicher, auf den beide Instanzen der fehlertoleranten virtuellen Maschine zugreifen können. Wenn Sie diese Konfiguration verwenden, setzt die CD-ROM in der virtuellen Maschine auch bei einem Failover den normalen Betrieb fort.

Vermeiden von Netzwerkpartitionen

Eine Netzwerkpartition tritt ein, wenn bei einem vSphere HA-Cluster ein Fehler des Verwaltungsnetzwerks auftritt, der zur Folge hat, dass einige der Hosts von vCenter Server sowie voneinander isoliert werden. Weitere Informationen hierzu finden Sie unter Netzwerkpartitionen. Wenn eine Partition eintritt, wird der Schutz durch Fault Tolerance möglicherweise herabgestuft.

In einem partitionierten vSphere HA-Cluster mit Fault Tolerance kann sich die primäre virtuelle Maschine (oder ihre sekundäre virtuelle Maschine) in einer Partition befinden, die von einem primären Host verwaltet wird, der für die virtuelle Maschine nicht verantwortlich ist. Wenn ein Failover benötigt wird, wird eine sekundäre virtuelle Maschine nur dann neu gestartet, wenn sich die primäre virtuelle Maschine in einer Partition befunden hat, die von dem primären Host verwaltet wird, der für die virtuelle Maschine verantwortlich ist.

Um die Chancen zu verringern, dass bei Ihrem Verwaltungsnetzwerk ein Fehler auftritt, der zu einer Netzwerkpartition führt, befolgen Sie die Empfehlungen unter Empfohlene Vorgehensweisen für Netzwerke.

Verwenden von vSAN-Datenspeichern

vSphere Fault Tolerance kann vSAN-Datenspeicher verwenden, aber Sie müssen folgende Einschränkungen beachten:

  • Ein Mix aus vSAN und anderen Typen von Datenspeichern wird sowohl für primäre VMs als auch für sekundäre VMs nicht unterstützt.
  • vSAN-Metro-Cluster werden mit FT nicht unterstützt.

Um die Leistung und Zuverlässigkeit bei der Verwendung von FT mit vSAN zu erhöhen, werden auch folgende Bedingungen empfohlen.

  • vSAN und FT sollten getrennte Netzwerke verwenden.
  • Verwalten Sie primäre und sekundäre VMs in getrennten vSAN Fault Domains.