Versionshinweise zu VMware Virtual SAN 6.2

|

Aktualisiert am: 24. Februar 2017

VMware Virtual SAN 6.2| 15. März 2016 | ISO Build 3620759

Ü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

Virtual SAN 6.2 enthält die folgenden neuen Funktionen und Verbesserungen.

  • Neu: Unterstützung für TLS. Unterstützung für TLS v1.0, TLS v1.1 und TLS v1.2 ist in vSphere 6.0 Update 3 und höheren Versionen standardmäßig aktiviert und kann konfiguriert werden. Informationen zum Konfigurieren von TLS v1.0, TLS v1.1 und TLS v1.2 finden Sie im VMware Knowledge Base article 2148819. For a list of VMware products supported for TLS v1.0 disablement and the use of TLS v1.1/v1.2, consult VMware-Knowledgebase-Artikel 2145796.

  • Deduplizierung und Komprimierung. Virtual SAN 6.2 unterstützt Deduplizierung und Komprimierung zur Vermeidung doppelter Daten. Auf diese Weise wird der Gesamtspeicherplatz gemäß Ihren Anforderungen verringert. Wenn Sie Deduplizierung und Komprimierung auf einem Virtual SAN-Cluster aktivieren, werden redundante Kopien von Daten in einer bestimmten Datenträgergruppe auf eine Kopie reduziert. Deduplizierung und Komprimierung stehen als clusterweite Einstellung auf allen All-Flash-Clustern bereit.

  • RAID 5- und RAID 6-Löschcodierung. Virtual SAN 6.2 unterstützt RAID 5- und RAID 6-Löschcodierung zur Verringerung des Speicherplatzes, der zum Schutz Ihrer Daten notwendig ist. RAID 5 und RAID 6 stehen als Richtlinienattribute für VMs in All-Flash-Clustern bereit. Sie können RAID 5 in Clustern mit mindestens vier Fehlerdomänen und RAID 6 in Clustern mit mindestens sechs Fehlerdomänen verwenden.

  • Software-Prüfsumme. Virtual SAN 6.2 unterstützt softwarebasierte Prüfsummen auf Hybrid- und All-Flash-Clustern. Das Richtlinienattribut für Software-Prüfsummen ist standardmäßig für alle Objekte im Virtual SAN-Cluster aktiviert.

  • Neues Datenträgerformat. Virtual SAN 6.2 unterstützt Upgrades auf das neue virtuelle Datenträgerformat 3.0 über den vSphere Web Client. Das Dateisystem bietet Unterstützung für neue Funktionen im Virtual SAN-Cluster. Die Version 3.0 des Datenträgerformats basiert auf einer internen Technologie zur Verwendung von 4K-Blockgrößen, die zwar gesteigerte Effizienz liefern, aber verringerte Leistung zur Folge haben können, wenn die E/A-Vorgänge des Gastbetriebssystems nicht an 4K angepasst sind. >

  • IOPS-Grenzwerte. Virtual SAN unterstützt IOPS-Grenzwerte, um die Anzahl der E/A-Vorgänge (Lesen/Schreiben) pro Sekunde für ein bestimmtes Projekt zu verringern. Wenn die Anzahl der Lese-/Schreibvorgänge den IOPS-Grenzwert erreicht, werden diese Vorgänge bis zum Ablauf der aktuellen Sekunde verschoben. Der IOPS-Grenzwert ist ein Richtlinienattribut, das auf jedes beliebige Virtual SAN-Objekt angewendet werden kann, einschließlich VMDK, Namespace usw.

  • IPv6. Virtual SAN unterstützt IPv4- oder IPv6-Adressen.

  • Speicherplatzanzeige. Die Virtual SAN 6.2-Kapazitätsüberwachung zeigt Informationen zum Virtual SAN-Datenspeicher (einschließlich des verwendeten und freien Speichers) an und stellt eine Übersicht zur Kapazitätsnutzung bestimmter Objekt- oder Datentypen bereit.

  • Integritätsdienst. Im Lieferumfang von Virtual SAN 6.2 befinden sich neue Integritätsprüfungen, mit denen Sie den Cluster überwachen und Probleme mit dem Cluster diagnostizieren und beheben können. Wenn der Virtual SAN-Integritätsdienst Integritätsprobleme erkennt, werden vCenter-Ereignisse und -Alarme ausgelöst.

  • Leistungsdienst. Im Lieferumfang von Virtual SAN 6.2 befinden sich Leistungsdienstüberwachungen mit Statistiken auf Cluster-, Host-, VM- und Datenträgerebene. Der Leistungsdienst sammelt und analysiert Leistungsstatistiken und zeigt die Daten in einem grafischen Format an. Sie können die Leistungsdiagramme zum Verwalten der Arbeitslast sowie zum Bestimmen von Problemursachen verwenden.

  • Write-Through-Arbeitsspeichercache. Virtual SAN 6.2 steigert die Leistung der virtuellen Maschine durch Verwendung eines Write-Through-Lesecaches, der sich auf dem Host befindet. Mit diesem Caching-Algorithmus werden die E/A-Leselatenz sowie die CPU- und Netzwerknutzung von Virtual SAN verringert.

Frühere Versionen von Virtual SAN

Die Funktionen und bekannten Probleme von Virtual SAN 6.0 und 6.1 werden in den Versionshinweisen beschrieben. Versionshinweise für Virtual SAN können unter den folgenden Links aufgerufen werden:

VMware Virtual SAN Community

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

Upgrades für diese Version

Anweisungen für das Upgrade von Virtual SAN finden Sie in der Dokumentation zu VMware Virtual SAN 6.2.

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

Während des Upgrades des Virtual SAN-Datenträgerformats wird eine Evakuierung der Datenträgergruppen durchgeführt. Dann wird die Datenträgergruppe entfernt und auf die Version 3.0 des Datenträgerformats aktualisiert. Anschließend wird die Datenträgergruppe dem Cluster wieder hinzugefügt. Bei Clustern mit zwei oder drei Knoten oder Clustern mit nicht ausreichender Kapazität müssen Sie zum Evakuieren aller Datenträgergruppen den folgenden RVC-Befehl verwenden, um das Datenträgerformat zu aktualisieren: 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. Es werden einfach alle Datenträgergruppen 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 Virtual SAN 6.2 Deduplizierung und Komprimierung aktivieren, können Sie Verringerte Redundanz zulassen im vSphere Web Client auswählen.

Verwenden von VMware Update Manager mit ausgeweiteten Clustern

Die Verwendung von VMware Update Manager zur gleichzeitigen Aktualisierung von Hosts kann unter Umständen dazu führen, dass der Zeugenhost gleichzeitig mit einem der Datenhosts in einem ausgeweiteten Cluster aktualisiert wird. Konfigurieren Sie VMware Update Manager zur Vermeidung von Problemen beim Upgrade nicht für die gleichzeitige Aktualisierung eines Zeugenhosts mit den Datenhosts in einem ausgeweiteten Cluster. Aktualisieren Sie den Zeugenhost erst, wenn alle Datenhosts erfolgreich aktualisiert wurden und den Wartungsmodus verlassen haben.

Überprüfen von Fehlern bei der Integritätsprüfung während des Upgrades

Während eines Upgrades des Virtual SAN-Datenträgerformats kann die Integritätsprüfung des physischen Datenträgers und der Metadaten zwischenzeitlich fehlschlagen. Diese Fehler können auftreten, wenn der Destaging-Prozess langsam ist. Dies wird wahrscheinlich dadurch verursacht, dass Virtual SAN physische Blockzuweisungen auf den Speichergeräten durchführen muss. Bevor Sie Maßnahmen ergreifen, überprüfen Sie den Status dieser Integritätsprüfung nach Abschluss des Zeitraums mit hoher Aktivität (beispielsweise bei mehreren Bereitstellungen virtueller Maschinen). Wenn die Integritätsprüfung weiterhin rot dargestellt wird, ist die Warnung gültig. Wenn die Integritätsprüfung grün dargestellt wird, können Sie die vorherige Warnung ignorieren. Weitere Informationen finden Sie im Knowledgebase-Artikel 2108690.

Einschränkungen

Bei einer All-Flash-Konfiguration unterstützt Virtual SAN eine Schreibpuffer-Cachegröße von maximal 600 GB pro Datenträgergruppe.

Informationen zu weiteren maximalen Grenzwerten für die Konfiguration von Virtual SAN 6.2 finden Sie in der Dokumentation Maximalwerte für die Konfiguration.

Behobene Probleme

  • Beim Aktualisieren auf Virtual SAN 6.1 wird folgende Fehlermeldung angezeigt: Kein Zugriff auf Agent-Offline-Paket
    Dieser Fehler tritt unter Umständen auf, wenn Sie von Virtual SAN 6.0 mit aktivierter Statusprüfung auf Virtual SAN 6.1 aktualisieren. Während des Upgrades wird das Integritätsprüfungs-VIB ersetzt und der zugehörige Dienst vorübergehend angehalten. In manchen Fällen wird von der Integritätsprüfung eine Fehlermeldung erzeugt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn Sie einen als Zeugen zu verwendenden Host in einem Virtual SAN-Cluster platzieren und den Host dann aus dem Cluster verschieben, wird die Integritätsprüfungs-VIB aus dem Host entfernt
    Wenn Sie einen ESXi-Host aus dem Virtual SAN-Cluster verschieben, wird die zugehörige Integritätsprüfungs-VIB entfernt. Handelt es sich bei dem Host also um einen Zeugen für den Cluster, wird der Installationsstatus des Zeugen rot dargestellt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bei einem Fehler in einer rollierenden Site eines großen ausgeweiteten Clusters (wie zum Beispiel 15:15:1), in dem die einzelnen Knoten in einer Fehlerdomäne nacheinander fehlschlagen (wobei einige Sekunden zwischen jedem Fehler liegen), ist der Zugriff auf VMs möglicherweise nicht mehr möglich oder sie werden nicht mehr erkannt (verwaisen)

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, eine All-Flash-Datenträgergruppe auf einem Zeugenhost für den ausgeweiteten Cluster zu konfigurieren, schlagen fehl
    Der Versuch, einen Zeugenhost mit einer All-Flash-Datenträgergruppe zu einem ausgeweiteten Cluster hinzuzufügen, schlägt fehl und dem Host wird keine Datenträgergruppe hinzugefügt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Durch Hinzufügen eines Hosts zu einem Virtual SAN-Cluster wird ein Installationsprogrammfehler ausgelöst
    Wenn Sie einen ESXi-Host zu einem Cluster mit aktiviertem HA und Virtual SAN-Integritätsdienst hinzufügen, tritt möglicherweise aufgrund einer Racebedingung bei der VIB-Installation mindestens einer der beiden folgenden Fehler auf:

    • In der Taskansicht schlägt die Aufgabe „vSphere HA wird konfiguriert“ möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl: Der vCenter Server-Agentendienst konnte nicht installiert werden. Unbekannter Installationsprogrammfehler

    • Die Aufgabe „Agent aktivieren“ schlägt möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl: Der Vorgang kann nicht abgeschlossen werden. Weitere Informationen finden Sie im Ereignisprotokoll.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bekannte Probleme

    • Datenträger können nicht beansprucht werden, wenn Virtual SAN deaktiviert ist
      Wenn Sie Datenträger beanspruchen und Datenträgergruppen erstellen, bevor Sie Virtual SAN auf dem Cluster aktivieren, schlägt der Vorgang fehl.

      Problemumgehung: Aktivieren Sie Virtual SAN auf dem Cluster, bevor Sie Datenträger beanspruchen und Datenträgergruppen erstellen.

    • Nach der Aktivierung von Virtual SAN 6.2 über esxcli funktioniert die automatische Beanspruchung von Datenträgern nicht
      Wenn Sie Virtual SAN 6.2 über esxcli aktivieren, funktioniert die automatische Methode zur Beanspruchung von Datenträgern nicht.

      Problemumgehung: Verwenden Sie den vSphere Web Client zum Konfigurieren der automatischen Beanspruchung von Datenträgern. Sie können auch die manuelle Methode zum Beanspruchen von Datenträgern verwenden.

    • Hostupgrade schlägt aufgrund von unzureichendem Speicherplatz auf der Locker-Partition fehl
      Upgrade ist mit folgender Meldung in der Datei /var/log/esxupdate.log fehlgeschlagen:

      Failed to create temporary DB dir: [Errno 28] No space left on device: '/locker/packages/var/db/locker/profiles.new' filename = /locker/packages/var/db/locker

      In der Datei /var/log/vobd.log werden unter Umständen folgende Ereignisse angezeigt:

      2016-02-23T11:50:16.095Z: [VfatCorrelator] 676355748510us: [vob.vfat.filesystem.full] VFAT volume mpx.vmhba32:C0:T0:L0:8 (UUID 55e71deb-2f773c48-5dda-a0369f56dd20) is full. (585696 sectors, 0 free sectors)

      2016-02-24T17:13:00.037Z: [VisorfsCorrelator] 782119690921us: [vob.visorfs.ramdisk.full] Cannot extend visorfs file /vsantraces/vsantraces--2016-02-24T17h12m27s256.gz because its ramdisk (vsantraces) is full. 2016-02-24T17:13:00.037Z: [VisorfsCorrelator] 782119691022us: [esx.problem.visorfs.ramdisk.full] The ramdisk 'vsantraces' is full. As a result, the file /vsantraces/vsantraces--2016-02-24T17h12m27s256.gz could not be written.

      Problemumgehung: Löschen Sie die GZ-Dateien von Virtual SAN Observer aus der Locker-Partition und wiederholen Sie das Upgrade.

      1. Melden Sie sich bei der ESXi Shell an und überprüfen Sie den Speicherverbrauch in der Locker-Partition unter /locker/vsantraces/

      2. Verwenden Sie den Befehl df -h, um alle zu 100 Prozent genutzten VFAT-Partitionen anzugeben. Beispiel:

        df -h
        Filesystem Size Used Available Use% Mounted on
        vfat 249.7M 202.5M 47.3M 81% /vmfs/volumes/68a04eea-90716418-ba59-6dc3297f0ef8
        vfat 249.7M 202.4M 47.3M 81% /vmfs/volumes/6f065ae4-88f03302-b4c6-c0b765c07ff8
        vfat 285.8M 285.7M 112.0K 100% /vmfs/volumes/55e71deb-2f773c48-5dda-a0369f56dd20
        -------------------------------

      3. Entfernen Sie die Virtual SAN Observer-Protokolle mit der Dateierweiterung .gz aus der Locker-Partition auf dem Host (/locker/vsantraces/). Beispiel: vsanObserver--YYYY-MM-DDTxxhyymzzs.gz

      4. Wiederholen Sie das Hostupgrade.

    • Überprüfung der Richtlinieneinhaltung und Standardisierung schlägt fehl, wenn ein 6.0 Update 1-Hostprofil auf einen 6.0 Update 2-Host mit konfigurierter Virtual SAN-vmknic angewendet wird
      Wenn Sie den Host von ESXi 6.0 Update 1 auf ESXi 6.0 Update 2 aktualisieren und dann das Hostprofil anwenden, schlägt es fehl und folgende Fehlermeldung wird angezeigt: Unerwarteter Fehler beim Aktualisieren der Aufgabenkonfigurationsspezifikation: 'IPProtocol'

      Problemumgehung: Sie können den Host auf 6.0 Update 2 aktualisieren und das Hostprofil aus dem aktualisierten Host extrahieren, um eine 6.0 Update 2-Version des Hostprofils zu erhalten.

      Sie können das Hostprofil auch bearbeiten und das bearbeitete Hostprofil auf den aktualisierten Host anwenden.

      1. Klicken Sie mit der rechten Maustaste auf das Hostprofil und wählen Sie das Menü Hostprofile exportieren aus. Das Hostprofil wird als VPF-Datei exportiert.

      2. Verwenden Sie einen Texteditor, um die VPF-Datei zu öffnen und alle Instanzen des folgenden Texts zu löschen:

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IPv4</value></parameter>

        Ersetzen Sie den Text durch folgenden Text:

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IP</value></parameter>

      3. Importieren Sie das geänderte Hostprofil und wenden Sie es auf Hosts an, die ESXi 6.0 Update 2 ausführen.

    • Nach Failover und Neustart eines Master-Knotens zeigt der SPBM-Übereinstimmungsstatus ungültige Ergebnisse an
      Nach mehreren Virtual SAN-Knotenfehlern zeigt die SPBM (Storage Policy-based Management) den Übereinstimmungsstatus einer virtuellen Maschine unter Umständen fälschlicherweise als Nicht anwendbar an. Dieses Problem kann auftreten, wenn sowohl der Master- als auch der Sicherungsknoten fehlschlagen. Es wird durch eine Abfolge automatischer Übereinstimmungsabfragen verursacht, die von der SPBM als Reaktion auf den Fehler ausgelöst werden. Da diese Übereinstimmungsabfragen zusätzliche Last auf dem System erzeugen, kann es bei neuen Übereinstimmungsabfragen zu einer Zeitüberschreitung kommen oder es werden ungültige Ergebnisse zurückgegeben.

      Problemumgehung: Warten Sie, bis alle automatisch initiierten Übereinstimmungsabfragen abgeschlossen sind. Alle neuen Übereinstimmungsabfragen geben gültige Ergebnisse zurück.

    • Der Assistent „Neue VM-Speicherrichtlinie erstellen“ zeigt falsche Bezeichnungen für Regeln an
      Wenn Sie den Assistenten „Neue VM-Speicherrichtlinie erstellen“ öffnen, um eine Richtlinie basierend auf Virtual SAN-Datendiensten zu definieren, wird in den zum Beschreiben der Richtlinienregeln verwendeten Bezeichnungen unter Umständen ein interner Bezeichner anstelle einer benutzerfreundlichen Bezeichnung angezeigt. So kann beispielsweise vsan.capabilitymetadata.propertymetadata.summary.replicaPreference.label anstelle von Anzahl der Festplatten-Stripes pro Objekt angezeigt werden.

      Problemumgehung: Melden Sie sich beim vSphere Web Client ab und wieder an.

    • Auf der Seite „Neusynchronisieren von Komponenten“ im vSphere Web Client werden keine Neusynchronisierungsaktivitäten angezeigt, wenn auf den Hosts verschiedene Versionen der ESXi-Software ausgeführt werden
      Beim Upgraden von Hosts in einem Virtual SAN-Cluster werden auf bestimmten Hosts unter Umständen verschiedene Versionen der ESXi-Software ausgeführt. Auf einigen Hosts wird beispielsweise ESXi 6.0 Update 1 und auf anderen ESXi 6.0 Update 2 ausgeführt. Während dieser Phase des Upgrades werden auf der Seite „Neusynchronisieren von Komponenten“ im vSphere Web Client unter Umständen keine Neusynchronisierungsaktivitäten angezeigt, die im Cluster auftreten.

      Problemumgehung: Zum Überwachen der Neusynchronisierungsaktivität während Hostupgrades verwenden Sie den RVC-Befehl vsan.resync_dashboard.

    • Neue Richtlinienregeln werden auf Hosts mit älteren Versionen der ESXi-Software ignoriert
      Dieses Problem tritt unter Umständen auf, wenn Sie zwei oder mehr Virtual SAN-Cluster verwenden, wobei auf einem Cluster die aktuelle Software und auf einem anderen Cluster eine ältere Version der Software ausgeführt wird. Der vSphere Web Client zeigt Richtlinienregeln für die aktuelle Virtual SAN-Software an. Diese neuen Richtlinien werden aber auf den älteren Hosts nicht unterstützt. RAID-5/6 (Löschcodierung) – Kapazität wird beispielsweise auf Hosts unter 6.0U1 oder früherer Software nicht unterstützt. Sie können die neuen Richtlinienregeln konfigurieren und auf alle VMs und Objekte anwenden. Diese werden jedoch auf Hosts, auf denen die ältere Version der Software ausgeführt wird, ignoriert.

      Problemumgehung: Keine

    • Die Konsolidierung von Snapshots schlägt während des Upgrades unter Umständen fehl
      Während des Upgrades des Virtual SAN-Datenträgerformats von Version 2.0 auf Version 3.0 schlägt die Konsolidierung von Snapshots unter Umständen fehl. In der Spalte Konsolidierung erforderlich im vSphere Client wird angegeben, dass die VM Konsolidierung benötigt. Zur Vermeidung dieser Situation führen Sie die Konsolidierung von Snapshots entweder vor dem Aktualisieren des Datenträgerformats aus oder warten, bis das Upgrade abgeschlossen ist.

      Problemumgehung: Wenn die Konsolidierung von Snapshots fehlschlägt, führen Sie den Vorgang nach der Aktualisierung des Datenträgerformats durch.

    • Objekte des Snapshot-Arbeitsspeichers werden in der Übersicht zur Kapazitätsnutzung des Virtual SAN Capacity-Monitors nicht angezeigt.
      Bei VMs vor Hardwareversion 10 befindet sich der Snapshot-Arbeitsspeicher unter Vmem-Objekte in der Übersicht zur Kapazitätsnutzung.

      Problemumgehung: Erstellen Sie zur Anzeige von Objekten des Snapshot-Arbeitsspeichers in der Übersicht zur Kapazitätsnutzung VMs mit der Hardwareversion 10 oder höher.

    • Der Virtual SAN-Leistungsdienst ist deaktiviert, wenn Sie die auf das Stats-Datenbankobjekt angewendete Speicherrichtlinie löschen
      Wenn Sie die auf den Leistungsdienst angewendete Speicherrichtlinie löschen, zeigt der vSphere Web Client die folgende Meldung an: Der Leistungsdienst ist deaktiviert.

      Problemumgehung: Führen Sie die folgenden Schritte durch, um die gelöschte Speicherrichtlinie wiederherzustellen oder um mithilfe von RVC-Befehlen eine vorhandene Speicherrichtlinie auf das Stats-Datenbankobjekt des Leistungsdiensts anzuwenden:

      1. Melden Sie sich beim vCenter Server mithilfe von SSH an und greifen Sie auf die Bash-Shell zu.

      2. Führen Sie den folgenden Befehl aus, um sich beim vCenter-Konto anzumelden:

        rvc localhost

      3. Führen Sie den folgenden Befehl aus, um eine Speicherrichtlinie auf das Stats-Datenbankobjekt anzuwenden:

        vsan.perf.stats_object_setpolicy -o <policy> <cluster>

      Beispiel:

      vsan.perf.stats_object_setpolicy -o "/localhost/VSAN-DC/storage/vmprofiles/Virtual SAN Default Storage Policy" MyCluster

    • Die auf der Seite „VM-Übersicht“ angegebene Speicherauslastung scheint nach dem Upgrade auf Virtual SAN 6.2 größer zu sein
      In früheren Versionen von Virtual SAN handelte es sich bei dem für die VM-Speicherauslastung angegebenen Wert um den Speicherplatz, der von einer einzelnen Kopie der Daten verwendet wurde. Wenn der Gast beispielsweise 1 GB in ein schnell bereitgestelltes Objekt mit zwei Spiegeln geschrieben hat, wurde 1 GB als Speicherauslastung angezeigt. In Virtual SAN 6.2 wird im Feld „Speicherauslastung“ der tatsächlich verwendete Speicherplatz angezeigt, einschließlich aller Kopien der Daten. Wenn der Gast also 1 GB in ein schnell bereitgestelltes Objekt mit zwei Spiegeln schreibt, werden 2 GB als Speicherauslastung angezeigt. Die angegebene Speicherauslastung auf bestimmten VMs erscheint nach dem Upgrade auf Virtual SAN 6.2 größer, der tatsächliche verbrauchte Speicherplatz hat sich aber nicht erhöht.

      Problemumgehung: Keine

    • 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 ausgeweiteten Cluster und dann wieder hinaus führt zu einer Fehlkonfiguration des Clusters
      Wenn Sie den Zeugenhost in einem Virtual SAN-fähigen vCenter-Cluster platzieren, werden Sie in einem 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 Virtual SAN-Cluster und konfigurieren Sie den ausgeweiteten 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
      Wird die Netzwerkverbindung zwischen der bevorzugten oder sekundären Site in einem Virtual SAN-Cluster und den anderen Sites unterbrochen, werden die VMs, die auf der Site ohne Netzwerkverbindung ausgeführt werden, nicht auf der anderen Daten-Site neu gestartet. Folgender Fehler wird unter Umständen angezeigt: vSphere HA-Failover einer virtuellen Maschine fehlgeschlagen.

      Dies ist das erwartete Verhalten für Virtual SAN-Cluster.

      Problemumgehung: Wählen Sie keinen HA-Taktsignal-Datenspeicher aus, während Sie vSphere HA auf dem Cluster konfigurieren.

    • Nicht gemountete Virtual SAN-Datenträger und -Datenträgergruppen werden im vSphere Web Client im Feld „Betriebsstatus“ als gemountet angezeigt
      Nachdem die Virtual SAN-Datenträger oder -Datenträgergruppen mit dem Befehl esxcli vsan storage disk group unmount oder vom Virtual SAN 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“.

    • Beim Upgrade des Datenträgerformats werden Datenträger nicht in Virtual SAN angezeigt
      Beim Upgrade des Datenträgerformats werden Datenträger, die bereits aus dem Cluster entfernt wurden, in Virtual SAN möglicherweise nicht ordnungsgemäß angezeigt. Auch auf der Benutzeroberfläche wird der Versionsstatus möglicherweise als mixed angezeigt. Dieses Anzeigeproblem tritt in der Regel nach dem manuellen Unmounten mindestens eines Datenträgers vom Cluster auf. Der Aktualisierungsvorgang wird hierdurch nicht beeinflusst. Nur die gemounteten Datenträger werden überprüft. Nicht gemountete Datenträger werden ignoriert.
    • Problemumgehung: Keine

    • Der Name der Virtual SAN-Fehlerdomäne ist länger als 256 Zeichen
      Wenn Sie versuchen, einen Fehlerdomänennamen mit mehr als 256 Byte in vSphere Web Client zuzuweisen, zeigt das System einen Fehler an: Ein angegebener Parameter war falsch: faultDomainInfo.name. Wenn Sie Multi-Byte-Unicode-Zeichen verwenden, können Sie den Grenzwert von 256 Byte mit weniger als 256 Zeichen erreichen.

      Problemumgehung: Keine.

    • Alle Virtual SAN-Cluster verwenden dieselben externen Proxy-Einstellungen
      Alle Virtual SAN-Cluster verwenden dieselben externen Proxy-Einstellungen, auch wenn Sie den Proxy auf der Clusterebene festlegen. Virtual SAN verwendet externe Proxys, um eine Verbindung zu Support Assistant, zum Programm zur Verbesserung der Kundenzufriedenheit und zur HCL-Datenbank herzustellen, wenn der Cluster keinen direkten Internetzugriff hat.

      Problemumgehung: Keine

    • Beim Virtual SAN-Integritätsdienst tritt eine Fehlfunktion auf, wenn die Standardwerte des vCenter HTTP- oder HTTPS-Ports und der Zertifizierungseinstellungen geändert werden
      Der Virtual SAN-Integritätsdienst unterstützt ausschließlich den HTTPS-Standardport 443 und das Standardzertifikat unter /etc/vmware-vpx/ssl/rui.crt und /etc/vmware-vpx/ssl/rui.key. Wenn Sie den Standardport oder das Zertifikat ändern, kann der Virtual SAN-Integritätsdienst nicht ordnungsgemäß ausgeführt werden. Sie erhalten unter Umständen den Statuscode 400 (Ungültige Anforderung) oder eine abgelehnte Anforderung.

      Problemumgehung: Verwenden Sie für die HTTP- und HTTPS-Einstellungen des Virtual SAN-Integritätsdiensts die Standardwerte.

    • Der Multicast-Leistungstest der Virtual SAN-Integritätsprüfung kann auf einem Virtual SAN-Netzwerk nicht ausgeführt werden
      In bestimmten Fällen kann der Multicast-Leistungstest je nach Routing-Konfiguration der ESXi-Hosts nicht auf dem Virtual SAN-Netzwerk ausgeführt werden.

      Problemumgehung: Verwenden Sie das Virtual SAN-Netzwerk als einzige Netzwerkeinstellung für die ESXi-Hosts und führen Sie den Multicast-Leistungstest für das Netzwerk basierend auf dieser Konfiguration durch.

      Wenn ESXi-Hosts über mehrere Netzwerkeinstellungen verfügen, können Sie auch die in diesem Beispiel aufgeführten Schritte durchführen. Angenommen, Virtual SAN wird im Netzwerk 192.168.0.0 ausgeführt.

      1. Binden Sie die Multicast-Gruppenadresse auf jedem Host an dieses Netzwerk:

        $ esxcli network ip route ipv4 add -n 224.2.3.4/32 -g 192.168.0.0?

      2. Überprüfen Sie die Routing-Tabelle

        $ esxcli network ip route ipv4 list
        default      0.0.0.0          10.160.63.253  vmk0       DHCP
        10.160.32.0  255.255.224.0    0.0.0.0        vmk0       MANUAL
        192.168.0.0  255.255.255.0    0.0.0.0        vmk3       MANUAL
        224.2.3.4    255.255.255.255  192.168.0.0    vmk3       MANUAL

      3. Führen Sie den proaktiven Multicast-Netzwerkleistungstest aus und überprüfen Sie das Ergebnis.

      4. Stellen Sie die Routing-Tabelle nach Abschluss des Tests wieder her:

        $ esxcli network ip route ipv4 remove -n 224.2.3.4/32 -g 192.168.0.0

    • Wenn die bevorzugte Site isoliert wird, ist der Zugriff auf VMs in einem ausgeweiteten Cluster nicht mehr möglich und eine Verbindung kann nur noch zum Zeugenhost hergestellt werden
      Wenn die bevorzugte Site nicht mehr verfügbar ist oder die Netzwerkverbindung zur sekundären Site und zum Zeugenhost unterbrochen wird, bildet die sekundäre Site einen Cluster mit dem Zeugenhost und führt die Speichervorgänge fort. Dies kann dazu führen, dass die Daten auf der primären Site mit der Zeit veralten. Wenn die bevorzugte Site erneut eine Verbindung zum Zeugenhost, nicht aber zur sekundären Site herstellt, verlässt der Zeugenhost den Cluster, in dem er sich befindet, und bildet einen Cluster mit der bevorzugten Site. Auf bestimmte VMs kann dann nicht mehr zugegriffen werden, da sie keinen Zugriff auf die aktuellen Daten in diesem Cluster haben.

      Problemumgehung: Bevor Sie eine erneute Verbindung zwischen der bevorzugten Site und dem Cluster herstellen, kennzeichnen Sie die sekundäre Site als bevorzugte Site. Nach erneuter Synchronisierung der Sites können Sie die Site markieren, die Sie als bevorzugte Site verwenden möchten.

    • Das OVA-Paket des Virtual SAN-Zeugenhosts bietet keine Unterstützung für interne DVS-Konfiguration
      Das OVA-Paket des VMware Virtual SAN-Zeugenhosts bietet keine Unterstützung für die DVS-Netzwerkkonfiguration (Distributed Virtual Switch).

      Problemumgehung: Verwenden Sie einen virtuellen Legacy-Switch.