Versionshinweise zu VMware vSAN 7.0 Update 2

VMware vSAN 7.0 Update 2 | 9. März 2021 | Build 17630552

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten
VMware vSAN Community
Upgrades für diese Version
Einschränkungen
Bekannte Probleme

Neuigkeiten

vSAN 7.0 Update 2 enthält die folgenden neuen Funktionen und Verbesserungen:

Ohne Kompromisse skalieren

HCI Mesh. HCI Mesh ermöglicht es vSAN-Clustern, Kapazität für reine vSphere-Rechencluster oder nicht HCI-basierte Cluster freizugeben. Sie können auch Speicherregeln für die empfohlene Datenplatzierung angeben, um einen kompatiblen Datenspeicher zu finden. Die Skalierbarkeit für einen einzelnen Remote-vSAN-Datenspeicher wurde auf 128 Hosts erhöht.
Verbesserungen für den vSAN-Dateidienst. Der vSAN-Dateidienst unterstützt jetzt Stretched Cluster-Bereitstellungen und Cluster mit zwei Knoten. Die Skalierbarkeit wird auf 64 Hosts und 100 Freigaben pro Cluster erhöht.
Verbesserungen für Stretched Cluster. Ein Stretched Cluster kann jetzt bis zu 20 Hosts auf jeder Site enthalten. DRS Awareness für Stretched Cluster bietet eine konsistentere Leistung in Failback-Situationen.
vSAN über RDMA. vSAN über RDMA liefert eine höhere Leistung und ermöglicht Ihnen bessere VM-Konsolidierungsverhältnisse.
Verbesserte Plattformleistung. Verbessert die NUMA-Awareness der Plattform, um die Leistung zu steigern.

Steigerung von Infrastruktur und Datensicherheit

vSphere Native Key Provider. vSAN unterstützt den vSphere Native Key Provider für integrierte Verschlüsselung.
Verschlüsselung in Übertragung begriffener Daten für vSAN-Dateidienst. Zu den Sicherheitsverbesserungen für den Dateidienst gehört die Unterstützung der Verschlüsselung in Übertragung begriffener Daten, wenn der Dateidienst zusammen mit der Verschlüsselung in Übertragung begriffener vSAN-Daten aktiviert ist.
Verschlüsselung in Übertragung begriffener Daten für gemeinsam genutzten Zeugen. vSAN 7.0 Update 2 unterstützt die Verschlüsselung in Übertragung begriffener Daten für gemeinsam genutzte Zeugenhosts.

Vorgänge vereinfachen

vLCM-Verbesserungen. vLCM unterstützt jetzt Firmware-Updates für ausgewählte Hitachi UCP HC-Server, neben der bestehenden Unterstützung für ausgewählte Dell EMC-, HPE- und Lenovo-Server. vLCM kann vSphere with Tanzu-Cluster aktualisieren, die mit NSX-T-Netzwerken konfiguriert sind. Darüber hinaus wurde die Skalierbarkeit auf 400 von vLCM verwaltete Hosts innerhalb eines einzigen vCenter Servers erhöht.
Verbesserungen bei der vSAN-Verwaltung und -Überwachung. Es stehen mehr Tools zur Verfügung, um Ihre Umgebung zu analysieren und schnell die Ursachen von Problemen und Möglichkeiten zur Behebung zu identifizieren. Zu den Erweiterungen gehören proaktives Kapazitätsmanagement, Netzwerkdiagnose, Einblicke in die wichtigsten Performancefaktoren und der Integritätsprüfungsverlauf.
Ungeplante Fehlerbehandlung. vSAN 7.0 Update 2 enthält eine verbesserte Datenhaltbarkeit, um ungeplante Host-, Festplatten- oder Netzwerkausfälle zu tolerieren, indem zusätzliche Haltbarkeitskomponenten zum Zeitpunkt des Ausfalls erstellt werden.
Dateidienst-Snapshots. vSAN 7.0 Update 2 vereinfacht die Sicherung von Dateifreigaben mit Snapshot-Unterstützung und APIs, die Anbietern von Sicherungs- und Wiederherstellungssoftware Integrationen in den vSAN-Dateidienst ermöglichen.
Proaktive vSphere-HA-Unterstützung. vSAN unterstützt jetzt proaktive HA, die Hardwareprobleme erkennt und proaktive Schritte unternehmen kann, um Hosts in den Wartungsmodus zu versetzen.
VMFS6-Dateisystemunterstützung. Eine neu erstellte VM auf dem vSAN-Datenspeicher hat ein VMFS6-Dateisystem auf dem VM-Namespace-Objekt, wenn es sich bei der Objektformatversion um 14 handelt. Sie können SEsparse-Snapshots mit der VM verwenden.
Effiziente VMDK-Verschiebungen. Wenn Sie ein VMDK zwischen zwei Verzeichnissen auf demselben vSAN-Datenspeicher mithilfe der Browserbenutzeroberfläche oder API des vSphere-Datenspeichers (VirtualDiskManager.moveVirtualDisk) verschieben, werden nur die VMDK-Deskriptordatei und die Objektmetadaten aktualisiert. Dieser Vorgang ist schneller, weil das VMDK, das die vSAN-Objektdaten sichert, nicht kopiert wird.

VMware vSAN Community

Über die vSAN Community-Website können Sie Feedback abgeben und Hilfe zu Problemen anfordern, die bei der Verwendung von vSAN auftreten.

Upgrades für diese Version

Anweisungen für Upgrades von vSAN finden Sie in der Dokumentation zu VMware vSAN 7.0.

Hinweis: Vor der Durchführung des Upgrades überprüfen Sie die aktuellste Version des VMware-Kompatibilitätshandbuchs, um zu überprüfen, ob die neueste vSAN-Version für Ihre Plattform verfügbar ist.

vSAN 7.0 Update 2 ist eine neue Version, die ein vollständiges Upgrade auf vSphere 7.0 Update 2 erfordert. Führen Sie folgende Aufgaben durch, um das Upgrade abzuschließen:

1. Führen Sie ein Upgrade auf vCenter Server 7.0 Update 2 durch. Weitere Informationen finden Sie unter Versionshinweise zu VMware vSphere 7.0 Update 2.
2. Führen Sie ein Upgrade der Hosts auf ESXi 7.0 Update 2 durch. Weitere Informationen finden Sie unter Versionshinweise zu VMware vSphere 7.0 Update 2.
3. Führen Sie ein Upgrade des vSAN-Festplattenformats auf Version 14.0 durch. Wenn Sie das Upgrade vom Festplattenformat der Version 3.0 oder höher durchführen, ist keine Evakuierung der Daten erforderlich (nur ein Update der Metadaten).
4. Aktualisieren Sie FSVM, um neue Dateidienstfunktionen wie Stretched Cluster-Unterstützung, Snapshot-Unterstützung und Verschlüsselung in Übertragung begriffener Daten zu aktivieren.

Hinweis: vSAN hat das Festplattenformat Version 1.0 in vSAN 7.0 Update 1 eingestellt. Festplatten, die das Festplattenformat Version 1.0 ausführen, werden nicht mehr von vSAN erkannt. vSAN blockiert das Upgrade über vSphere Update Manager, die ISO-Installation oder esxcli auf vSAN 7.0 Update 1. Um diese Probleme zu vermeiden, führen Sie ein Upgrade der Festplatten, auf denen das Festplattenformat Version 1.0 ausgeführt wird, auf eine höhere Version durch. Wenn Sie über Festplatten der Version 1 verfügen, werden Sie durch eine Integritätsprüfung auf ein Upgrade der Festplattenformatversion aufmerksam gemacht.

Die Version 1.0 des Festplattenformats weist keine Leistungs- und Snapshot-Verbesserungen auf, und erweiterte Funktionen wie Prüfsumme, Deduplizierung und Komprimierung sowie Verschlüsselung werden nicht unterstützt. Weitere Informationen zur vSAN-Festplattenformat-Version finden Sie im Knowledgebase-Artikel 2148493.

Aktualisieren des Datenträgerformats für Hosts mit begrenzter Kapazität

Während des Upgrades des vSAN-Datenträgerformats von Version 1.0 oder 2.0 wird eine Evakuierung der Festplattengruppen durchgeführt. Die Festplattengruppe wird entfernt und auf Version 14.0 des Festplattenformats aktualisiert. Anschließend wird die Festplattengruppe dem Cluster wieder hinzugefügt. Wählen Sie bei Zwei-Knoten- oder Drei-Knoten-Clustern bzw. bei Clustern, deren Kapazität nicht zum Verlagern aller Festplattengruppen ausreicht, im vSphere Client die Option Verringerte Redundanz zulassen aus. Sie können für ein Upgrade des Datenträgerformats auch den folgenden RVC-Befehl verwenden: vsan.ondisk_upgrade --allow-reduced-redundancy

Wenn Sie verringerte Redundanz zulassen, sind Ihre VMs während des Upgrades nicht geschützt, da bei dieser Methode die Daten nicht auf die anderen Hosts im Cluster evakuiert werden. Alle Datenträgergruppen werden entfernt, das Datenträgerformat wird aktualisiert und die Datenträgergruppen werden wieder zum Cluster hinzugefügt. Alle Objekte bleiben mit verringerter Redundanz verfügbar.

Wenn Sie während des Upgrades auf vSAN 7.0 Update 2 Deduplizierung und Komprimierung aktivieren, können Sie Verringerte Redundanz zulassen im vSphere Client auswählen.

Einschränkungen

Informationen zu maximalen Grenzwerten für die Konfiguration von vSAN 7.0 Update 2 finden Sie in der Dokumentation Maximalwerte für die Konfiguration.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

vSAN-Probleme

vSAN-Probleme

Das Löschen von Dateien in einer Dateifreigabe wird möglicherweise nicht in der vSAN-Kapazitätsansicht angezeigt.
Die zugeteilten Blöcke werden möglicherweise nicht sofort wieder an den vSAN-Speicher zurückgegeben, nachdem alle Dateien gelöscht wurden. Daher kann es einige Zeit dauern, bis die zurückgewonnene Speicherkapazität in der vSAN-Kapazitätsansicht aktualisiert wird. Wenn neue Daten in dieselbe Dateifreigabe geschrieben werden, werden diese gelöschten Blöcke möglicherweise wiederverwendet, bevor sie an den vSAN-Speicher zurückgegeben werden.

Wenn die Aufhebung der Zuordnung aktiviert und die vSAN-Deduplizierung deaktiviert ist, wird der Speicherplatz möglicherweise nicht wieder für vSAN freigegeben, es sei denn, es werden 4 MB ausgerichteter Speicherplatz im VDFS freigegeben. Wenn die Aufhebung der Zuordnung aktiviert und die vSAN-Deduplizierung aktiviert ist, wird der von VDFS freigegebene Speicherplatz mit einer Verzögerung wieder für vSAN freigegeben.

Problemumgehung: Löschen Sie die Dateifreigaben, um den Speicher sofort wieder in vSAN freizugeben.
vSAN über RDMA kann aufgrund einer Netzwerküberlastung eine geringere Leistung erzielen
RDMA benötigt eine verlustfreie Netzwerkinfrastruktur ohne Überlastung. Wenn Ihr Netzwerk überlastet ist, können bestimmte große E/A-Arbeitslasten eine geringere Leistung als TCP aufweisen.

Problemumgehung: Beheben Sie alle Netzwerküberlastungsprobleme, die den OEM-Best Practices für RDMA folgen.
vCenter-VM-Absturz auf Stretched Cluster mit Verschlüsselung in Übertragung begriffener Daten
Die vCenter-VM stürzt möglicherweise auf einem vSAN Stretched Cluster ab, wenn sich die vCenter-VM auf vSAN mit aktivierter Verschlüsselung in Übertragung begriffener Daten befindet. Wenn alle Hosts einer Site ausgefallen sind und dann wieder eingeschaltet werden, kann die vCenter-VM abstürzen, nachdem die ausgefallene Site wieder in Betrieb genommen wurde.

Problemumgehung: Verwenden Sie das folgende Skript, um dieses Problem zu beheben: thumbPrintRepair.py
Die VM-Migration vom VMFS-Datenspeicher oder vSAN-Datenspeicher zum vSAN-Datenspeicher schlägt fehl
Wenn der inhaltsbasierte Lese-Cache (CBRC) aktiviert ist, kann es vorkommen, dass sVmotion oder xVmotion eine VM mit einem oder mehreren Snapshots nicht auf den vSAN-Datenspeicher migrieren können. Eine Fehlermeldung ähnlich der folgenden wird gegebenenfalls angezeigt: Der Vorgang wird für dieses Objekt nicht unterstützt.

Die folgenden Meldungen werden in „/var/log/vmware/vpxd/“ angezeigt

2021-01-31T17:12:27.477Z error vpxd[18588] [Originator@6876 sub=vpxLro opID=65ef3b53-01] [VpxLRO] Unexpected Exception: N5Vmomi5Fault12NotSupported9ExceptionE(Message is: The operation is not supported on the object.,
--> Fault cause: vmodl.fault.NotSupported
--> Fault Messages are:
--> (null)
--> )
-->

Problemumgehung: Konsolidieren Sie Snapshots oder löschen Sie alle Snapshots vor der Migration.
vSAN ermöglicht die Bereitstellung einer VM über lokale und Remotedatenspeicher hinweg.
vSphere verhindert nicht, dass Benutzer eine VM über lokale und Remotedatenspeicher in einer HCI Mesh-Umgebung bereitstellen. Beispielsweise können Sie eine VMDK auf dem lokalen vSAN-Datenspeicher und eine VMDK auf dem vSAN-Remotedatenspeicher bereitstellen. Dies wird nicht unterstützt, da vSphere HA mit dieser Konfiguration nicht unterstützt wird.

Problemumgehung: Stellen Sie nicht eine VM für den lokalen und den Remotedatenspeicher bereit.
Die Aufgabe zur Neuformatierung des Objekts wird nicht ausgeführt
Wenn nach einem Upgrade eine Neuformatierung von Objekten erforderlich ist, wird ein Integritätsalarm ausgelöst, und vSAN beginnt mit der Neuformatierung. vSAN führt diese Aufgabe stapelweise durch und ist abhängig von der Menge der im Cluster verfügbaren vorübergehenden Kapazität. Wenn die vorübergehende Kapazität den maximalen Grenzwert überschreitet, wartet vSAN auf eine Freigabe der vorübergehenden Kapazität, bevor mit der Neuformatierung fortgefahren wird. Während dieser Phase scheint die Aufgabe angehalten zu sein. Der Integritätsalarm wird gelöscht, und die Aufgabe wird ausgeführt, wenn vorübergehende Kapazität verfügbar ist.

Problemumgehung: Keine. Die Aufgabe funktioniert wie erwartet.
System-VMs können nicht ausgeschaltet werden
Mit der Veröffentlichung von vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 wird möglicherweise eine Reihe von System-VMs innerhalb des vSAN-Clusters platziert. Diese System-VMs können nicht von Benutzern ausgeschaltet werden. Dieses Problem kann sich auf einige vSAN Workflows auswirken, die im folgenden Artikel dokumentiert sind: https://kb.vmware.com/s/article/80877

Problemumgehung: Nähere Informationen zu diesem Problem finden Sie in KB 80483.
vSAN-Dateidienste können aufgrund einer alten vSAN-Datenträgerformat-Version nicht aktiviert werden.
vSAN-Dateidienste können nicht mit einer vSAN-Datenträgerformat-Version aktiviert werden, die älter ist als Version 11.0 (die Version des Datenträgerformats in vSAN 7.0).

Aktualisieren Sie die vSAN-Datenträgerformat-Version, bevor Sie den Dateidienst aktivieren.
Die Aufgabe zur Clusterstandardisierung schlägt möglicherweise in einem umfangreichen Cluster aufgrund von vSAN-Integritätstestproblemen im Netzwerk fehl.
Bei umfangreichen Clustern mit mehr als 16 Hosts können während des Host-Upgrades zeitweise Ping-Fehler auftreten. Diese Fehler können die Hoststandardisierung in vSphere Life Cycle Manager unterbrechen.

Nach Ablauf der Vorabprüfung für die Standardisierung werden Warnungen für die folgenden vSAN-Integritätstests zurückgegeben:
- vSAN: Einfache (Unicast-)Konnektivitätsprüfung
- vSAN: MTU-Prüfung (Ping mit großem Paket)
Stellen Sie Warnungen für die vSAN-Integritätstests wieder her, wenn die Standardisierungsaufgabe abgeschlossen ist.
Hostfehler in Hotplug-Szenario, wenn das Laufwerk wieder eingesetzt wird
Beim Entfernen eines Laufwerks im laufenden Betrieb kann ein nativer VMware NVMe-Hotplug einen Hostfehler verursachen, wenn das NVMe-Laufwerk innerhalb einer Minute entfernt und wieder eingesetzt wird. Dies gilt sowohl bei vSphere als auch bei vSAN für jegliche neue oder vorhandene Wiedereinsetzung von Laufwerken.

Problemumgehung: Warten Sie nach dem Entfernen eines Laufwerks im laufenden Betrieb eine Minute, bevor Sie wieder ein neues oder das vorhandene Laufwerk einlegen.
Der letzte Host in einem Cluster kann nicht in den Wartungsmodus versetzt oder eine Festplatte oder Festplattengruppe entfernt werden
Vorgänge im Modus Vollständige Datenmigration oder Barrierefreiheit sicherstellen schlagen möglicherweise fehl, ohne dass eine Empfehlung zum Hinzufügen einer neuen Ressource gegeben wird, wenn sich nur ein Host im Cluster befindet und dieser Host in den Wartungsmodus wechselt. Dies kann auch auftreten, wenn nur eine Festplatte oder Festplattengruppe im Cluster vorhanden ist und diese Festplatte oder Festplattengruppe entfernt werden soll.

Problemumgehung: Bevor Sie den letzten verbleibenden Host im Cluster bei ausgewähltem Modus Vollständige Datenmigration oder Barrierefreiheit sicherstellen in den Wartungsmodus versetzen, fügen Sie einen anderen Host mit derselben Konfiguration zum Cluster hinzu. Bevor Sie die letzte verbleibende Festplatte oder Festplattengruppe im Cluster entfernen, fügen Sie eine neue Festplatte oder Festplattengruppe mit derselben Konfiguration und Kapazität hinzu.
Workflows zur Neukonfiguration von Objekten schlagen möglicherweise aufgrund fehlender Kapazität fehl, wenn eine oder mehrere Festplatten oder Festplattengruppen fast voll sind
vSAN-Neusynchronisierungen werden angehalten, wenn die Festplatten in Nicht-Deduplizierungs-Clustern oder Festplattengruppen in Deduplizierungs-Clustern einen konfigurierbaren Schwellenwert für die Pausierung der Neusynchronisierung bei vollem Festplattenspeicher erreichen. Dadurch wird vermieden, dass die Festplatten mit Neusynchronisierungs-E/A gefüllt werden. Wenn die Festplatten diesen Schwellenwert erreichen, beendet vSAN die Neukonfigurations-Workflows, wie z. B. EMM, Reparaturen, Neuverteilung und Richtlinienänderung.

Problemumgehung: Wenn an anderer Stelle im Cluster Platz verfügbar ist, wird durch die Neuverteilung des Clusters Speicherplatz auf den anderen Festplatten freigegeben, sodass nachfolgende Neukonfigurationsversuche erfolgreich durchgeführt werden können.
Nach der Wiederherstellung aus einem vollen Cluster können VMs den HA-Schutz verlieren
In einem vSAN-Cluster, auf dem Hosts mit 100 % vollen Festplatten vorhanden sind, haben die VMs möglicherweise eine ausstehende Frage und verlieren somit den HA-Schutz. Außerdem sind die VMs, die eine ausstehende Frage hatten, nach der Wiederherstellung aus dem Szenario mit vollem Cluster nicht HA-geschützt.

Problemumgehung: Führen Sie nach der Wiederherstellung aus dem Szenario mit vollem vSAN-Cluster eine der folgenden Aktionen aus:
- HA deaktivieren und erneut aktivieren
- HA neu konfigurieren
- VMs aus- und wieder einschalten
Ausschalten von VMs schlägt mit der ausstehender Frage fehl
Wenn eine VM eine ausstehende Frage hat, können Sie erst VM-bezogene Vorgänge durchführen, wenn die Frage beantwortet ist.

Problemumgehung: Versuchen Sie, Festplattenspeicher auf dem relevanten Volume freizugeben, und klicken Sie dann auf Wiederholen.
Wenn der Cluster voll ist, ändern sich die IP-Adressen der VMs entweder in IPv6 oder sind nicht mehr verfügbar
Wenn auf einem vSAN-Cluster eine oder mehrere Festplattengruppen 100 % der Kapazität erreichen, kann eine VM mit einer ausstehenden Frage vorliegen, die eine Benutzeraktion erfordert. Wenn die Frage nicht beantwortet und die Bedingung des vollen Clusters ignoriert wird, ändern sich die IP-Adressen der VMs möglicherweise in IPv6 oder sind nicht mehr verfügbar. Dadurch wird verhindert, dass Sie SSH für den Zugriff auf die VMs verwenden. Darüber hinaus wird verhindert, dass Sie die VM-Konsole verwenden, da die Konsole nach der Eingabe von root leer ist.

Problemumgehung: Keine.
Eine Festplattengruppe mit aktivierter Deduplizierung kann nicht entfernt werden, nachdem eine Kapazitätsfestplatte in den PDL-Zustand gewechselt hat
Wenn eine Kapazitätsfestplatte in einer Festplattengruppe mit aktivierter Deduplizierung entfernt wird oder sich ihre eindeutige ID ändert oder wenn das Gerät einen nicht behebbaren Hardwarefehler aufweist, wechselt es in den Status eines dauerhaften Geräteausfalls (PDL). Wenn Sie versuchen, die Festplattengruppe zu entfernen, wird möglicherweise eine Fehlermeldung angezeigt, die Sie darüber informiert, dass die Aktion nicht abgeschlossen werden kann.

Problemumgehung: Wenn eine Kapazitätsfestplatte entfernt wird oder sich die eindeutige ID ändert oder wenn das Gerät einen nicht behebbaren Hardwarefehler aufweist, warten Sie einige Minuten, bevor Sie versuchen, die Festplattengruppe zu entfernen.
Die vSAN-Integrität weist auf Nichtkonformität mit fehlgeschlagener ausstehender Richtlinie wegen Nichtverfügbarkeit hin
Bei einer Richtlinienänderungsanforderung bleibt der Objektintegritätsstatus von vSAN in einem Nichtkonformitätszustand mit Nichtverfügbarkeit. Dies liegt daran, dass es möglicherweise andere geplante Arbeiten gibt, die die angeforderten Ressourcen nutzen. vSAN plant diese Richtlinienanforderung jedoch automatisch neu, wenn Ressourcen verfügbar werden.

Problemumgehung: Die vSAN-Zeitraumprüfung behebt dieses Problem in den meisten Fällen automatisch. Andere in Bearbeitung befindliche Vorgänge verwenden jedoch möglicherweise verfügbare Ressourcen, selbst nachdem die Richtlinienänderung akzeptiert, aber nicht angewendet wurde. Sie können mehr Kapazität hinzufügen, wenn die Kapazitätsberichterstattung einen hohen Wert anzeigt.
In Deduplizierungsclustern tritt möglicherweise eine reaktive Neuverteilung nicht auf, wenn die Festplatten weniger als 20 % Speicherplatz angeben
Wenn in Deduplizierungsclustern die Festplatten auf dem Dashboard weniger als 20 % Speicherplatz angeben, startet die reaktive Neuverteilung möglicherweise nicht wie erwartet. Dies liegt daran, dass in Deduplizierungsclustern ausstehende Schreibvorgänge und Löschungen auch für die Berechnung der freien Kapazität berücksichtigt werden.

Problemumgehung: Keine.
TRIM/UNMAP-Befehle vom Gastbetriebssystem schlagen fehl
Wenn das Gastbetriebssystem versucht, die Rückforderung von Speicherplatz während der Online-Snapshot-Konsolidierung durchzuführen, schlagen die TRIM/UNMAP-Befehle fehl. Dieser Fehler verhindert, dass Speicherplatz freigegeben wird.

Problemumgehung: Versuchen Sie, den Speicherplatz zurückzugewinnen, wenn der Online-Snapshot-Vorgang abgeschlossen ist. Wenn nachfolgende TRIM/UNMAP-Vorgänge fehlschlagen, mounten Sie die Festplatte erneut.
Die Speicherplatzrückgewinnung durch SCSI TRIM/UNMAP geht verloren, wenn eine Online-Snapshot-Konsolidierung durchgeführt wird
Die Speicherplatzrückgewinnung durch SCSI TRIM/UNMAP-Befehle geht verloren, wenn Sie eine Online-Snapshot-Konsolidierung durchführen. Eine Offline-Snapshot-Konsolidierung wirkt sich nicht auf den SCSI-Unmap-Vorgang aus.

Problemumgehung: Fordern Sie den Speicherplatz zurück, wenn die Online-Snapshot-Konsolidierung abgeschlossen ist.
Hostfehler beim Konvertieren eines Datenhosts in einen Zeugenhost
Wenn Sie einen vSAN-Cluster in einen Stretched Cluster konvertieren, müssen Sie einen Zeugenhost bereitstellen. Sie können einen Datenhost in einen Zeugenhost konvertieren, müssen jedoch während des Vorgangs den Wartungsmodus mit vollständiger Datenmigration verwenden. Wenn Sie den Host mit der Option „Zugriff sicherstellen“ in den Wartungsmodus versetzen und ihn dann als Zeugenhost konfigurieren, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl.

Problemumgehung: Entfernen Sie die Festplattengruppe auf dem Zeugenhost und erstellen Sie dann die Festplattengruppe erneut.
Doppelte VM mit demselben Namen in vCenter Server, wenn der vorhandene Host während der Datenspeichermigration ausfällt
Wenn eine virtuelle Maschine mit Storage vMotion von vSAN auf einen anderen Datenspeicher, wie z. B. NFS, migriert wird und der Host, auf dem sich die VM befindet, im vSAN-Netzwerk einen Netzwerkfehler feststellt, der HA-Failover auslöst, wird die virtuelle Maschine in vCenter Server unter Umständen dupliziert.

Problemumgehung: Schalten Sie die ungültige VM aus und heben Sie ihre Registrierung bei vCenter Server auf.
Neukonfiguration von vorhandenem Stretched Cluster unter einem neuen vCenter Server führt zur Ausgabe einer Integritätsprüfungswarnung durch vSAN
Beim Neuerstellen eines aktuellen Stretched Clusters unter einem neuen vCenter Server wird die Integritätsprüfung des vSAN-Clusters rot dargestellt. Die folgende Meldung wird angezeigt: vSphere-Clustermitglieder stimmen mit vSAN-Clustermitgliedern überein

Problemumgehung: Gehen Sie wie folgt vor, um den Stretched Cluster zu konfigurieren.
1. Verwenden Sie SSH zur Anmeldung beim Zeugenhost.
2. Nehmen Sie die Festplatten auf dem Zeugenhost außer Betrieb. Führen Sie den folgenden Befehl aus: esxcli vsan storage remove -s "SSD UUID"
3. Erzwingen Sie, dass der Zeugenhost den Cluster verlässt. Führen Sie den folgenden Befehl aus: esxcli vsan cluster leave
4. Konfigurieren Sie den Stretched Cluster im neuen vCenter Server neu (Konfigurieren > vSAN > Fehlerdomänen & Stretched Cluster).
Upgrade des Festplattenformats schlägt fehl, während vSAN große Objekte neu synchronisiert
Wenn der vSAN-Cluster sehr große Objekte enthält, schlägt das Upgrade des Festplattenformats möglicherweise während der Neusynchronisierung der Objekte fehl. Eine Fehlermeldung ähnlich der folgenden wird gegebenenfalls angezeigt: Fehler beim Konvertieren von Objekt(en) im vSAN

vSAN kann das Upgrade erst durchführen, wenn die Objekte synchronisiert sind. Sie können den Status der Neusynchronisierung überprüfen (Überwachen > vSAN > Neusynchronisieren von Komponenten), um festzustellen, wann der Prozess abgeschlossen ist.

Problemumgehung: Warten Sie, bis keine Neusynchronisierung mehr aussteht, und versuchen Sie dann das Upgrade des Festplattenformats erneut.
Integritätsprüfung der Clusterkonsistenz schlägt während des Vorgangs zur tiefen erneuten Schlüsselerstellung fehl
Der Vorgang zur tiefen erneuten Schlüsselerstellung auf einem verschlüsselten vSAN-Cluster kann mehrere Stunden in Anspruch nehmen. Während der erneuten Schlüsselerstellung weist die folgende Integritätsprüfung unter Umständen auf einen Fehler hin: Konsistenz der Clusterkonfiguration. Bei der Prüfung der Clusterkonsistenz bleibt der Vorgang der tiefen erneuten Schlüsselerstellung unerkannt, sodass unter Umständen kein Fehler auftritt.

Problemumgehung: Testen Sie die Integritätsprüfung der vSAN-Clusterkonsistenz nach Abschluss des Vorgangs zur tiefen erneuten Schlüsselerstellung erneut.
Konfiguration des ausgeweiteten vSAN-Clusters geht nach Deaktivierung von vSAN auf dem Cluster verloren
Wenn Sie vSAN in einem Stretched Cluster deaktivieren, wird die Konfiguration des ausgeweiteten Clusters nicht beibehalten. Die Konfiguration des ausgeweiteten Clusters, des Zeugenhosts und der Fehlerdomäne geht verloren.

Problemumgehung: Konfigurieren Sie die Parameter des ausgeweiteten Clusters neu, wenn Sie den vSAN-Cluster erneut aktivieren.
Ausgeschaltete VMs werden während des Ersetzens eines Zeugenhosts als nicht zugriffsfähig angezeigt
Wenn Sie einen Zeugenhost in einem Stretched Cluster ändern, werden ausgeschaltete VMs für einen kurzen Zeitraum im vSphere Web Client als nicht zugriffsfähig angezeigt. Nach Abschluss des Vorgangs werden ausgeschaltete VMs als zugriffsfähig angezeigt. Alle ausgeführten VMs werden während des Prozesses als zugriffsfähig angezeigt.

Problemumgehung: Keine.
Hosts können nicht in den Wartungsmodus versetzt werden, wenn sie fehlerhafte Startmedien aufweisen
vSAN kann Hosts mit fehlerhaften Startmedien nicht in den Wartungsmodus versetzen. Die Aufgabe zum Wechseln in den Wartungsmodus schlägt unter Umständen mit einem internen vSAN-Fehler fehl, da Konfigurationsänderungen nicht gespeichert werden können. Es werden möglicherweise Protokollereignisse ähnlich der folgenden angezeigt: Verbindung zum Gerät xxx, welches das Boot-Dateisystem unterstützt, ging verloren.

Problemumgehung: Entfernen Sie Datenträgergruppen mithilfe der Option zur vollständigen Datenverlagerung manuell von allen Hosts. Versetzen Sie den Host anschließend in den Wartungsmodus.
Integritätsdienst funktioniert nicht, wenn auf dem vSAN-Cluster ESXi-Hosts mit vSphere 6.0 Update 1 oder früher ausgeführt werden
Der Integritätsdienst von vSAN 6.6 und höher funktioniert nicht, wenn auf dem vSAN-Cluster ESXi-Hosts mit vSphere 6.0 Update 1 oder früheren Versionen ausgeführt werden.

Problemumgehung: Fügen Sie einem vSAN-Cluster der Version 6.6 oder höher keine ESXi-Hosts mit vSphere 6.0 Update 1 oder früheren Versionen hinzu.
Nach einem Failover des ausgeweiteten Clusters erhalten VMs auf der bevorzugten Site folgende Warnung: Failover fehlgeschlagen
Wenn die sekundäre Site in einem Stretched Cluster fehlschlägt, kommt es zu einem Failover der VMs auf die bevorzugte Site. VMs, die sich bereits auf der bevorzugten Site befinden, registrieren unter Umständen folgende Warnung: Failover fehlgeschlagen. Ignorieren Sie diese Warnung. Sie hat keinen Einfluss auf das Failover-Verhalten.

Problemumgehung: Keine.
Während der Netzwerkpartitionierung werden Komponenten auf der aktiven Site als nicht vorhanden angezeigt
Während einer Netzwerkpartitionierung in einem aus 2 Hosts bestehenden oder ausgeweiteten vSAN-Cluster zeigt der vSphere Web Client unter Umständen eine Ansicht des Clusters aus der Perspektive einer nicht aktiven Site an. Unter Umständen werden aktive Komponenten auf der primären Site als nicht vorhanden angezeigt.

Problemumgehung: Verwenden Sie RVC-Befehle, um den Status der Objekte im Cluster abzufragen. Beispiel: vsan.vm_object_info
Bestimmte Objekte sind nach einer erzwungenen Reparatur inkompatibel
Nach dem Durchführen einer erzwungenen Reparatur wurden bestimmte Objekte unter Umständen nicht repariert, da die Zugehörigkeit der Objekte während des Prozesses an einen anderen Knoten übertragen wurde. Die erzwungene Reparatur kann sich für diese Objekte verzögern.

Problemumgehung: Wiederholen Sie die erzwungene Reparatur, nachdem alle anderen Objekte repariert und neu synchronisiert wurden. Sie können warten, bis die Objekte von vSAN repariert werden.
Wenn Sie einen Host von einem verschlüsselten Cluster zu einem anderen verschlüsselten Cluster verschieben und anschließend wieder zum ursprünglichen Cluster, schlägt der Vorgang fehl
Wenn Sie einen Host von einem verschlüsselten vSAN-Cluster zu einem anderen verschlüsselten vSAN-Cluster verschieben und anschließend wieder zum ursprünglichen verschlüsselten Cluster, schlägt der Vorgang möglicherweise fehl. Eine Meldung ähnlich der folgenden wird gegebenenfalls angezeigt: Ein allgemeiner Systemfehler ist aufgetreten: Ungültiger Fehler. Dieser Fehler tritt auf, da vSAN nicht erneut Daten auf dem Host mit dem ursprünglichen Verschlüsselungsschlüssel verschlüsseln kann. Nach kurzer Zeit stellt vCenter Server den ursprünglichen Schlüssel auf dem Host wieder her und alle nicht gemounteten Datenträger im vSAN-Cluster werden in den gemounteten Zustand versetzt.

Problemumgehung: Starten Sie den Host neu und warten Sie, bis alle Datenträger wieder gemountet wurden.
Ungleichgewicht im Stretched Cluster nach der Wiederherstellung einer Site
Wenn Sie eine fehlgeschlagene Site in einem Stretched Cluster wiederherstellen, werden Hosts auf der fehlgeschlagenen Site manchmal über einen langen Zeitraum nacheinander zurückmigriert. Bestimmte Hosts werden von vSAN gegebenenfalls überlastet, wenn mit der Reparatur der nicht vorhandenen Komponenten begonnen wird.

Problemumgehung: Stellen Sie alle Hosts in einer fehlgeschlagenen Site zusammen innerhalb eines kurzen Zeitraums wieder her.
VM-Vorgänge schlagen aufgrund von HA-Problemen mit Stretched Clustern fehl
Bestimmte Ausfallszenarien in Stretched Clustern können unter Umständen Auswirkungen auf bestimmte VM-Vorgänge wie vMotion oder das Einschalten einer VM haben. Zu diesen Ausfallszenarien gehören ein teilweiser oder kompletter Ausfall einer Site oder ein Ausfall des Hochgeschwindigkeitsnetzwerks zwischen den Sites. Dieses Problem wird verursacht durch die Abhängigkeit von VMware HA bei normalen Vorgängen in ausgeweiteten Cluster-Sites.

Problemumgehung: Deaktivieren Sie vSphere HA, bevor Sie vMotion ausführen und VMs erstellen oder einschalten. Aktivieren Sie anschließend vSphere HA erneut.
Tiefe erneute Schlüsselerstellung kann nicht durchgeführt werden, wenn ein Unmounten einer Datenträgergruppe durchgeführt wird
vSAN führt zuerst eine flache und dann eine tiefe erneute Schlüsselerstellung durch. Die flache erneute Schlüsselerstellung schlägt fehl, wenn eine nicht gemountete Datenträgergruppe vorhanden ist. Der Vorgang der tiefen erneuten Schlüsselerstellung kann nicht beginnen.

Problemumgehung: Mounten Sie die nicht gemountete Datenträgergruppe erneut oder entfernen Sie sie.
Protokolleinträge geben an, dass die Firewallkonfiguration geändert wurde
Ein neuer Firewalleintrag wird im Sicherheitsprofil angezeigt, wenn die vSAN-Verschlüsselung aktiviert ist: vsanEncryption. Über diese Regel wird die direkte Kommunikation der Hosts mit dem KMS gesteuert. Wenn sie ausgelöst wird, werden Protokolleinträge zu /var/log/vobd.log hinzugefügt. Unter Umständen werden Meldungen ähnlich den folgenden angezeigt:

Firewallkonfiguration wurde geändert. Vorgang 'addIP4' für Regelsatz vsanEncryption erfolgreich.
Firewallkonfiguration wurde geändert. Vorgang 'removeIP4' für Regelsatz vsanEncryption erfolgreich.

Diese Meldungen können ignoriert werden.

Problemumgehung: Keine.
HA-Failover tritt nicht auf, nachdem die Option „Art des Datenverkehrs“ auf einer vmknic zur Unterstützung des Zeugenverkehrs aktiviert wurde
Wenn Sie die Option „Art des Datenverkehrs“ auf einer vmknic zur Unterstützung des Zeugenverkehrs festlegen, erkennt vSphere HA die neue Einstellung nicht automatisch. Sie müssen HA manuell deaktivieren und dann erneut aktivieren, damit die vmknic erkannt wird. Wenn Sie zuerst die vmknic und den vSAN-Cluster konfigurieren und dann HA auf dem Cluster aktivieren, wird die vmknic erkannt.

Problemumgehung: Deaktivieren Sie vSphere HA manuell auf dem Cluster und aktivieren Sie HA dann erneut.
iSCSI-MCS wird nicht unterstützt
Der vSAN-iSCSI-Zieldienst bietet keine Unterstützung für MCS (Multiple Connections per Session, mehrere Verbindungen pro Sitzung).

Problemumgehung: Keine.
Jeder iSCSI-Initiator kann iSCSI-Ziele erkennen
Der vSAN-iSCSI-Zieldienst ermöglicht jedem Initiator im Netzwerk die Erkennung von iSCSI-Zielen.

Problemumgehung: Sie können die ESXi-Hosts von iSCSI-Initiatoren isolieren, indem Sie sie in verschiedenen VLANs platzieren.
Nach dem Auflösen einer Netzwerkpartition schlagen bestimmte VM-Vorgänge auf verknüpften Klon-VMs unter Umständen fehl
Bestimmte VM-Vorgänge auf verknüpften Klon-VMs, die keine E/A innerhalb des Gastbetriebssystems erzeugen, schlagen unter Umständen fehl. Zu den Vorgängen, die gegebenenfalls fehlschlagen können, gehören das Erstellen von Snapshots oder das Anhalten der VMs. Dieses Problem kann auftreten, wenn eine Netzwerkpartition aufgelöst wird und auf den Namespace der übergeordneten Basis-VM noch nicht zugegriffen werden kann. Wenn auf den Namespace der übergeordneten VM zugegriffen werden kann, wird HA nicht darüber informiert, die VM einzuschalten.

Problemumgehung: Schalten Sie VMs aus und wieder ein, die E/A-Vorgänge nicht aktiv ausführen.
Ein Zeugenhost kann nicht in den Wartungsmodus versetzt werden
Wenn Sie versuchen, einen Zeugenhost in den Wartungsmodus zu versetzen, behält der Host den aktuellen Status bei und folgende Benachrichtigung wird angezeigt: Ein angegebener Parameter war nicht korrekt.

Problemumgehung: Wenn Sie einen Zeugenhost in den Wartungsmodus versetzen, wählen Sie die Option Keine Datenmigration aus.
Das Verschieben des Zeugenhosts in einen Stretched Cluster und dann wieder hinaus führt zu einer Fehlkonfiguration des Clusters
Wenn Sie den Zeugenhost in einem vSAN-fähigen vCenter-Cluster platzieren, werden Sie durch einen Alarm darauf hingewiesen, dass sich der Zeugenhost nicht im Cluster befinden darf. Wenn Sie den Zeugenhost jedoch aus dem Cluster entfernen, verbleibt der Cluster in einem falsch konfigurierten Status.

Problemumgehung: Verschieben Sie den Zeugenhost aus dem ausgeweiteten vSAN-Cluster, und konfigurieren Sie den Stretched Cluster neu. Weitere Informationen finden Sie im Knowledgebase-Artikel 2130587.
Wenn in einem Cluster mit einem HA-Taktsignal-Datenspeicher eine Netzwerkpartition vorhanden ist, werden VMs in der anderen Daten-Site nicht neu gestartet
Wenn die Netzwerkverbindung zwischen der bevorzugten oder sekundären Site in einem vSAN-Cluster und den anderen Sites unterbrochen wird, werden die VMs, die auf der Site ohne Netzwerkverbindung ausgeführt werden, auf der anderen Daten-Site nicht neu gestartet. Unter Umständen wird die folgende Fehlermeldung angezeigt: vSphere HA-Failover einer virtuellen Maschine fehlgeschlagen.

Dies ist das erwartete Verhalten für vSAN-Cluster.

Problemumgehung: Wählen Sie keinen HA-Taktsignal-Datenspeicher aus, während Sie vSphere HA auf dem Cluster konfigurieren.
Nicht gemountete vSAN-Datenträger und -Datenträgergruppen werden im vSphere Web Client im Feld „Betriebsstatus“ als gemountet angezeigt
Nachdem die vSAN-Datenträger oder -Datenträgergruppen mit dem Befehl esxcli vsan storage disk group unmount oder vom vSAN Device Monitor-Dienst in den nicht gemounteten Zustand versetzt wurden, wird im Feld „Betriebsstatus“ des vSphere Web Client fälschlicherweise der Wert Gemountet angezeigt, wenn die Datenträger ständig hohe Latenzen aufweisen.

Problemumgehung: Verwenden Sie zum Überprüfen des Datenträgerstatus das Feld „Integrität“ anstelle des Felds „Betriebsstatus“.