Versionshinweise zu VMware vSAN 8.0 Update 2

VMware vSAN 8.0 Update 2 | 21. September 2023 | ISO-Build 22380479 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

In diesen Versionshinweisen werden die neuen Funktionen von VMware vSAN 8.0 Update 2 vorgestellt und Informationen zu bekannten Problemen bereitgestellt.

Neuigkeiten

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

• Disaggregierter Speicher

  Verbesserte Topologien für Disaggregation mit vSAN Express Storage Architecture bringen Funktionsparität für vSAN OSA und vSAN ESA.

  vSAN ESA unterstützt Stretched Cluster in einer disaggregierten Topologie. vSAN ESA unterstützt Disaggregation bei der Verwendung von vSAN Stretched Clustern. Zusätzlich zur Unterstützung verschiedener Stretched-Cluster-Konfigurationen optimiert vSAN auch die Netzwerkpfade für bestimmte Topologien, um die Leistungsfähigkeit von Stretched-Cluster-Konfigurationen zu verbessern.

  Unterstützung von Disaggregation in Clustern mit mehreren vCenter Servern. vSAN 8.0 Update 2 unterstützt Disaggregation in Umgebungen mit mehreren vCenter Servern bei Verwendung von vSAN ESA. Dies ermöglicht vSphere- oder vSAN-Clustern, die von einem vCenter Server verwaltet werden, die Nutzung der Speicherressourcen eines vSAN-Clusters, der von einem anderen vCenter Server verwaltet wird.

  Adaptiver vSAN ESA-Schreibpfad für disaggregierten Speicher. Disaggregierte Bereitstellungen profitieren von den Leistungsvorteilen eines neuen adaptiven Schreibpfads, der zuvor in vSAN 8.0 Update 1 für standardmäßige ESA-basierte Bereitstellungen eingeführt wurde. VMs, die auf einem vSphere- oder vSAN-Cluster ausgeführt werden und Speicher von einem anderen vSAN ESA-Cluster nutzen, können von dieser Funktion profitieren. Die adaptive Schreibpfadtechnologie in einer disaggregierten Umgebung hilft Ihren VMs, einen höheren Durchsatz und eine geringere Latenz zu erzielen, und zwar automatisch in Echtzeit und ohne jegliche Interaktion des Administrators.

• Verbesserungen der Kernplattform

  Integrierte Dateidienste für cloudnative und herkömmliche Arbeitslasten. vSAN 8.0 Update 2 unterstützt vSAN-Dateidienste auf der vSAN Express Storage Architecture. Dateidienst-Clients können von den Leistungs- und Effizienzverbesserungen profitieren, die vSAN ESA bietet.

  Optimierungen des adaptiven Schreibpfads in vSAN ESA. vSAN ESA führt einen adaptiven Schreibpfad ein, der dem Cluster hilft, Daten schneller zu erfassen und zu verarbeiten. Diese Optimierung verbessert die Leistung für Arbeitslasten, die hohe E/A für ein einzelnes Objekt (VMDK) erfordern, und verbessert auch die Gesamtleistung des Clusters.

  Erhöhte Anzahl von VMs pro Host in vSAN ESA-Clustern (bis zu 500/Host). vSAN 8.0 Update 2 unterstützt bis zu 500 VMs pro Host-VM auf vSAN ESA-Clustern, sofern die zugrunde liegende Hardware-Infrastruktur dies unterstützt. Jetzt können Sie NVMe-basierte Hochleistungs-Hardwareplattformen nutzen, die für die neueste Generation von CPUs mit hoher Kerndichte optimiert sind, und mehr VMs pro Host konsolidieren.

  Neues ReadyNode-Profil und Unterstützung für leseintensive Geräte für vSAN ESA. vSAN ESA kündigt die Verfügbarkeit neuer ReadyNode-Profile an, die für kleine Datencenter und Edge-Umgebungen mit geringeren Gesamthardwareanforderungen pro Knoten entwickelt wurden. Mit dieser Version wird auch die Unterstützung für leseintensive Speichergeräte eingeführt.

  vSAN ESA-Unterstützung für tiefe erneute Schlüsselerstellung (deep rekey). vSAN-Cluster, die die Verschlüsselung ruhender Daten verwenden, können eine tiefe erneute Schlüsselerstellung durchführen. Bei der tiefen erneuten Schlüsselerstellung werden die verschlüsselten Daten, die auf einem vSAN-Cluster gespeichert sind, mit dem alten Verschlüsselungsschlüssel entschlüsselt und mit neu ausgegebenen Verschlüsselungsschlüsseln erneut verschlüsselt, bevor sie auf dem vSAN-Cluster gespeichert werden.

• Erweiterte Vorgänge

  Von vSAN ESA vorgegebene Datenträgerbeanspruchung. vSAN ESA beinhaltet einen Prozess zur Vorgabe der Datenträgerbeanspruchung, der die Verwaltung der Speichergeräte in jedem Host in einem vSAN-Cluster weiter vereinfacht. Diese Funktion sorgt für Konsistenz beim Beanspruchen von Datenträgern während der ersten Bereitstellung und der Cluster-Erweiterung.

  Verbesserungen bei der Kapazitätsberichterstattung. Die Overhead-Aufschlüsselung in vSAN ESA-Speicherplatzberichten zeigt sowohl den ESA-Objekt-Overhead als auch den ursprünglichen Dateisystem-Overhead an.

  Verbesserte automatische Richtlinienverwaltung in vSAN ESA. Die verbesserte Funktion für die automatische Richtlinienverwaltung ermittelt, ob die Standard-Speicherrichtlinie angepasst werden muss, wenn ein Benutzer einen Host zu einem Cluster hinzufügt oder aus ihm entfernt. Wenn vSAN feststellt, dass die Standard-Speicherrichtlinie geändert werden muss, wird eine Warnung zur Integritätsprüfung ausgelöst. Sie können die Änderung mit einem einfachen Klick vornehmen, woraufhin vSAN den Cluster mit der neuen Richtlinie neu konfiguriert.

  Verbesserungen bei der Skyline Health-Standardisierung. vSAN Skyline Health hilft Ihnen, die Lösungszeiten zu verkürzen, indem es bereitstellungsspezifische Anleitungen zusammen mit präskriptiven Anleitungen zur Lösung von Problemen bietet.

  Schlüsselablauf für Cluster mit Verschlüsselung ruhender Daten. vSAN 8.0 Update 2 unterstützt die Verwendung von KMS-Servern mit einem Attribut für den Schlüsselablauf, mit dem ein Ablaufdatum für einen Key Encryption Key (KEK) zugewiesen wird.

  Verbesserungen bei den wichtigsten E/A-Beitragenden. vSAN-Leistungsdienst hat das Verfahren zum Auffinden von Leistungs-Hotspots über einen anpassbaren Zeitraum verbessert, um Sie bei der Diagnose von Leistungsproblemen zu unterstützen, wobei mehrere Arten von Quellen für die Analyse verwendet werden (VMs, Host-Datenträger usw.).

  E/A-Tripanalyse wird auf Zwei-Knoten-Clustern und Stretched Clustern unterstützt. vSAN 8.0 Update 2 hat die E/A-Tripanalyse verbessert, um Berichte zu Arbeitslasten in einem vSAN Stretched Cluster zu erstellen. Sie können nun feststellen, wo die Hauptquelle der Latenz in einem vSAN Stretched Cluster auftritt, sowie Latenzen in anderen Teilen des Stacks, die zur Gesamtlatenz der VM beitragen können.

  Einfachere Konfiguration für Zwei-Knoten-Cluster und Stretched Cluster. Mehrere neue Funktionen erleichtern die Verwaltung von Zwei-Knoten-Clustern und Stretched Clustern.

  • Konfiguration des Datenverkehrs von Zeugenhosts im vSphere Client.

  • Unterstützung für mittelgroße Zeugenhost-Appliances in vSAN ESA.

  • Unterstützung in vLCM zur Verwaltung des Lebenszyklus von gemeinsam genutzten Zeugenhost-Appliances.

• Cloudnativer Speicher

  CSI-Snapshot-Unterstützung für TKG-Dienst. Cloudnativer Speicher führt CSI-Snapshot-Unterstützung für den TKG-Dienst ein, wodurch K8s-Benutzer und Sicherungsanbieter in die Lage versetzt werden, Snapshots von dauerhaften Volumes auf TKGS zu erstellen.

  Datenmobilität von dauerhaften cloudnativen Volumes zwischen verschiedenen Datenspeichern. Mit dieser Version wird die integrierte Migration von dauerhaften Volumes zwischen Datenspeichern im vSphere Client eingeführt.

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 8.0 Update 2. 

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.

Hinweis: vSAN Express Storage Architecture ist nur für neue Bereitstellungen verfügbar. Sie können einen Cluster nicht auf vSAN ESA aktualisieren.

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

1. Führen Sie ein Upgrade auf vCenter Server 8.0 Update 2 durch. Weitere Informationen finden Sie unter Versionshinweise zu VMware vSphere 8.0 Update 2. 

2. Führen Sie ein Upgrade der Hosts auf ESXi 8.0 Update 2 durch. Weitere Informationen finden Sie unter Versionshinweise zu VMware vSphere 8.0 Update 2. 

3. Führen Sie ein Upgrade des vSAN-Datenträgerformats auf Version 19.0 durch. Wenn Sie das Upgrade vom Datenträgerformat 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 zu aktivieren und alle neuesten Updates zu erhalten.

Hinweis: vSAN hat das Datenträgerformat Version 1.0 in vSAN 7.0 Update 1 eingestellt. Datenträger, die das Datenträgerformat 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 Datenträger, auf denen das Datenträgerformat Version 1.0 ausgeführt wird, auf eine höhere Version durch. Wenn Sie über Datenträger der Version 1.0 verfügen, werden Sie durch eine Integritätsprüfung auf ein Upgrade der Datenträgerformatversion aufmerksam gemacht.

Die Version 1.0 des Datenträgerformats 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-Datenträgerformat-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 Datenträgergruppen durchgeführt. Die Datenträgergruppe wird entfernt und auf Version 17.0 des Datenträgerformats aktualisiert. Anschließend wird die Datenträgergruppe 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 Datenträgergruppen 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 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 8.0 Update 2 finden Sie in der Dokumentation Maximalwerte für die Konfiguration.

Bekannte Probleme

• Fehler beim Konsolidieren von VMDK von vRDM auf vSAN ESA-Cluster

  Dieses Problem kann auftreten, wenn Sie einen virtuellen Datenträger vom Typ vRDM verwenden, bei dem der Kompatibilitätsmodus auf Virtuell und der Datenträgermodus auf Abhängig festgelegt ist. Im vSAN ESA-Datenspeicher kann der entsprechende virtuelle Datenträger nicht im Snapshot-Löschvorgang konsolidiert werden, nachdem der Snapshot erstellt wurde. Dieses Problem kann dazu führen, dass der virtuelle Datenträger keinen neuen Snapshot erstellen kann.

  Keine.

• Verschlüsselungsvorgänge blockiert, wenn der native Schlüsselanbieter nicht gesichert ist

  Wenn Sie den nativen Schlüsselanbieter für die Verschlüsselung ruhender vSAN-Daten verwenden und der native Schlüsselanbieter nicht gesichert ist, schlagen verschlüsselungsbezogene Neukonfigurationsvorgänge möglicherweise mit der folgenden Meldung fehl: The KMS cluster {kmsCluster} is a Native Key Provider that is not backed up yet.

  Sichern Sie den nativen Schlüsselanbieter, bevor Sie die Verschlüsselung ruhender Daten aktivieren.

• Speicherrichtlinie muss wiederhergestellten VMs manuell zugewiesen werden

  Wenn Sie einen verknüpften Klon aus einer gelöschten VM wiederherstellen oder erstellen, weist vSAN nicht automatisch eine Speicherrichtlinie zu. Die neue VM verfügt über keine Speicherrichtlinie.

  Weisen Sie die Speicherrichtlinie manuell zu, nachdem Sie eine verknüpfte Klon-VM erstellt oder eine VM wiederhergestellt haben.

• Japanischer Text für Skyline Health wird falsch angezeigt, wenn Air-Gap auf vCenter angewendet wird

  Dieses Problem kann auftreten, wenn Air-Gap auf die vCenter-Netzwerkverbindung angewendet wird. Einige japanische Texte für Skyline Health werden falsch lokalisiert. Es wird möglicherweise eine Nachrichten-ID wie die folgende angezeigt: com.vmware.vsan.health.XXX

  Führen Sie die folgenden Schritte aus:

  1. Melden Sie sich per SSH am vCenter an.

  2. Öffnen Sie folgende Datei:/etc/vmware-vsan-health/cloudHealthResources/locale/ja/vsanhealthremediation.vmsg

  3. Suchen Sie nach dem Folgenden:vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des

  4. Führen Sie die beiden Zeilen wie unten gezeigt zu einer Zeile zusammen und speichern Sie die Datei.

  5. Starten Sie den vSAN Health Service neu: /usr/sbin/vmon-cli -r vsan-health

  Vorher:

  vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des=健全性テーブルに表示される

  vSAN の最適なデータストアのデフォルト ポリシーの「許容される障害の数」または「サイトの耐障害性」の構成 (あるいは両方) が推奨ポリシーと一致しません。

  Nachher:

  vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des=健全性テーブルに表示される vSAN の最適なデータストアのデフォルト ポリシーの「許容される障害の数」または「サイトの耐障害性」の構成 (あるいは両方) が推奨ポリシーと一致しません。

• hostAffinity-Richtlinienoption während des Upgrades verloren

  Wenn Sie ein Upgrade von vSAN 6.7 auf vSAN 8.0 durchführen, wird der Wert für die vCenter Server-Hostaffinität in falsegeändert.

  Problemumgehung: Legen Sie die Option für die Hostaffinität wieder auf „true“ fest, um die vSAN-HostLocal-Richtlinie für eine normale VM weiterhin zu verwenden.

• Dateidienst kann nicht aktiviert werden, wenn die vCenter Server-Internetverbindung deaktiviert ist

  Wenn Sie die vCenter Server-Internetverbindung deaktivieren, wird im Dialogfeld „Dateidienst aktivieren“ der Abschnitt „Dateidienst-Agent“ nicht angezeigt und Sie können OVF nicht auswählen.

  Problemumgehung: So aktivieren Sie die vCenter Server-Internetverbindung:

  1. Navigieren Sie zu Cluster > Konfigurieren > vSAN > Internetverbindung.

  2. Klicken Sie auf Bearbeiten, um das Dialogfeld „Internetverbindung bearbeiten“ zu öffnen.

  3. Aktivieren Sie das Kontrollkästchen Internetzugriff für alle vSAN-Cluster aktivieren und klicken Sie auf Übernehmen.

• Deaktivieren der Verschlüsselung auf vSAN ESA nicht möglich

  Nachdem Sie die Verschlüsselung ruhender Daten auf einem vSAN ESA-Cluster aktiviert haben, können Sie sie nicht mehr deaktivieren.

  Problemumgehung: Keine.

• Der vSAN-Dateidienst unterstützt keine NFSv4-Delegierungen

  Der vSAN-Dateidienst unterstützt NFSv4-Delegierungen in dieser Version nicht.

  Problemumgehung: Keine.

• Im Stretched Cluster kann ein Dateiserver ohne Affinität nicht neu verteilt werden

  In der Umgebung des vSAN-Dateidiensts mit Stretched Cluster kann ein Dateiserver ohne konfigurierten Affinitätsspeicherort nicht zwischen bevorzugten ESXi-Hosts und nicht bevorzugten ESXi-Hosts neu verteilt werden.

  Problemumgehung: Legen Sie den Affinitätsspeicherort des Dateiservers auf Bevorzugt oder Nicht-bevorzugt fest, indem Sie die Konfiguration der Dateidienstdomäne bearbeiten.

• Die Standardisierung von ESXi-Hosts in einem vSphere Lifecycle Manager-Cluster mit vSAN schlägt fehl, wenn vCenter-Dienste auf benutzerdefinierten Ports bereitgestellt werden

  Wenn vCenter Server-Dienste auf benutzerdefinierten Ports in einem Cluster mit vSAN, vSphere DRS und vSphere HA bereitgestellt werden, schlägt die Standardisierung von vSphere Lifecycle Manager-Clustern möglicherweise fehl. Dieses Problem wird durch einen vSAN-Fehler bei der Integritätsprüfung der Ressourcen verursacht. ESXi-Hosts können nicht in den Wartungsmodus wechseln, was zu einem Fehlschlagen von Standardisierungsaufgaben führt.

  Problemumgehung: Keine.

• Wenn der vSAN-Dateidienst aktiviert ist, schlagen DFC-bezogene Vorgänge, wie z. B. das Upgrade, die Aktivierung der Verschlüsselung oder die Dateneffizienz, möglicherweise fehl

  Wenn der Dateidienst aktiviert ist, wird auf jedem Host eine Agent-VM ausgeführt. Das zugrunde liegende vSAN-Objekt kann über mehrere Datenträgergruppen hinweg platziert werden. Wenn die erste Datenträgergruppe konvertiert wird, kann auf das vSAN-Objekt nicht mehr zugegriffen werden und die Agent-VM befindet sich in einem ungültigen Zustand. Wenn Sie versuchen, die VM zu löschen und eine neue VM erneut zu bereitstellen, schlägt der Vorgang aufgrund des ungültigen Zustands der VM fehl. Die Registrierung der VM wird aufgehoben, aber das Objekt, auf das nicht zugegriffen werden kann, ist dort noch vorhanden. Wenn die nächste Datenträgergruppe konvertiert wird, gibt es eine Vorabprüfung auf Objekte, auf die im gesamten Cluster nicht zugegriffen werden kann. Diese Prüfung schlägt für die DFC fehl, da nicht zugängliche Objekte der alten Agent-VM gefunden werden.

  Problemumgehung: Entfernen Sie die nicht zugänglichen Objekte manuell. 

  Wenn ein solcher Fehler auftritt, können Sie sehen, dass die DFC-Aufgabe fehlgeschlagen ist.

  1. Identifizieren Sie die nicht zugänglichen Objekte anhand der Fehlerinformationen der Fehleraufgabe.

  2. Um sicherzustellen, dass die Objekte zur Agent-VM gehören, überprüfen Sie die hostd-Protokolldatei und bestätigen Sie, dass die Objekte zum Objektlayout der VM gehören.

  3. Melden Sie sich beim Host an und verwenden Sie den Befehl /usr/lib/vmware/osfs/bin/objtool, um die Objekte manuell zu entfernen.

  Hinweis: Um dieses Problem zu vermeiden, deaktivieren Sie den Dateidienst, bevor Sie einen DFC-bezogenen Vorgang durchführen.

• Das Hostprofil kann auf einem vSAN HCI Mesh-Computing-Host nicht extrahiert werden

  vSAN HCI Mesh-Computing-Hosts werden vom vSAN Hostprofil-Plug-In nicht unterstützt. Wenn Sie versuchen, das Hostprofil auf einem HCI Mesh-Computing-Host zu extrahieren, schlägt der Versuch fehl. 

  Problemumgehung: Keine.

• 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. 

• 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.

• 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 diesem KB-Artikel: https://kb.vmware.com/s/article/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).

  Problemumgehung: Führen Sie ein Upgrade der vSAN-Datenträgerformat-Version durch, bevor Sie den Dateidienst aktivieren.

• 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 ein Datenträger oder eine Datenträgergruppe 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 ein Datenträger oder eine Datenträgergruppe im Cluster vorhanden ist und dieser Datenträger oder diese Datenträgergruppe 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 Datenträger oder Datenträgergruppe im Cluster entfernen, fügen Sie einen Datenträger oder eine Datenträgergruppe mit derselben Konfiguration und Kapazität neu hinzu.

• Workflows zur Neukonfiguration von Objekten schlagen möglicherweise aufgrund fehlender Kapazität fehl, wenn eine oder mehrere Datenträger oder Datenträgergruppen fast voll sind

  vSAN-Neusynchronisierungen werden angehalten, wenn die Datenträger in Nicht-Deduplizierungs-Clustern oder Datenträgergruppen in Deduplizierungs-Clustern einen konfigurierbaren Schwellenwert für die Pausierung der Neusynchronisierung bei vollem Datenträgerspeicher erreichen. Dadurch wird vermieden, dass die Datenträger mit Neusynchronisierungs-E/A gefüllt werden. Wenn die Datenträger 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 Datenträgern 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 zu 100 % vollen Datenträger 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, Datenträgerspeicher 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 Datenträgergruppen 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 Datenträgergruppe mit aktivierter Deduplizierung kann nicht entfernt werden, nachdem ein Kapazitätsdatenträger in den PDL-Zustand gewechselt hat

  Wenn eine Kapazitätsdatenträger in einer Datenträgergruppe 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 Datenträgergruppe zu entfernen, wird möglicherweise eine Fehlermeldung angezeigt, die Sie darüber informiert, dass die Aktion nicht abgeschlossen werden kann.

  Problemumgehung: Wenn eine Kapazitätsdatenträger 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 Datenträgergruppe zu entfernen.

• In Deduplizierungsclustern tritt möglicherweise eine reaktive Neuverteilung nicht auf, wenn die Datenträger angeben, dass sie zu mehr als 80% belegt sind

  Wenn in Deduplizierungsclustern die Datenträger auf dem Dashboard angeben, dass sie zu mehr als 80% gefüllt sind, 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 den Datenträger 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ändige 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 Datenträgergruppe auf dem Zeugenhost und erstellen Sie dann die Datenträgergruppe 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 Datenträger 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 Datenträgerformats 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 Datenträgerformats 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 Datenträgerformats erneut.

• 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.

• Nach einem Failover des Stretched 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.

  Problemumgehung: Ignorieren Sie diese Warnung. Sie hat keinen Einfluss auf das Failover-Verhalten.

• Während der Netzwerkpartitionierung werden Komponenten auf der aktiven Site als nicht vorhanden angezeigt

  Während einer Netzwerkpartitionierung in einem aus zwei Hosts bestehenden oder vSAN-Stretched 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: A general system error occurred: Invalid fault. 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.

• 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:

  Firewall configuration has changed. Operation 'addIP4' for rule set vsanEncryption succeeded.

  Firewall configuration has changed. Operation 'removeIP4' for rule set vsanEncryption succeeded.

  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.

• 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 in diesem Artikel: https://kb.vmware.com/s/article/2130587.

• 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“.