Versionshinweise zu VMware Virtual SAN 6.1

|

Aktualisiert am: 14. OKTOBER 2015

VMware Virtual SAN 6.1 | 10. September 2015 | ISO-Build 3029758

Ü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.1 enthält die folgenden neuen Funktionen und Verbesserungen:

  • Ausgeweitete Cluster: Virtual SAN 6.1 unterstützt ausgeweitete Cluster, die sich über zwei geografisch getrennte Standorte erstrecken, um Daten vor Site-Ausfällen und dem Verlust der Netzwerkverbindung zu schützen.

  • VMware Virtual SAN Witness Appliance 6.1 ist ein virtueller Zeugenhost, der als virtuelle Appliance bereitgestellt wird. Seine Funktionsweise entspricht einem ESXi-Host, der als Zeugenhost für einen ausgeweiteten Virtual SAN-Cluster konfiguriert ist. Sie können das OVA-Paket für Virtual SAN Witness Appliance 6.1 von der VMware Virtual SAN-Download-Website herunterladen.

  • Neues Datenträgerformat. Virtual SAN 6.1 unterstützt Upgrades auf das neue virtuelle Datenträgerformat 2.0 über den vSphere Web Client. Hierbei handelt es sich um ein auf Virsto-Technologie gestütztes protokollbasiertes Dateisystem, das die Verwaltung hoch skalierbarer Snapshots und Klone pro Virtual SAN-Cluster ermöglicht.

  • Hybrid- und All-Flash-Konfigurationen. Virtual SAN 6.1 unterstützt Hybrid- und All-Flash-Cluster. Um einen All-Flash-Cluster zu konfigurieren, klicken Sie unter Virtual SAN Festplattenverwaltung (Verwalten > Einstellungen) auf Neue Festplattengruppe erstellen, und wählen Sie bei Kapazitätstypen die Option Flash. Wenn Sie Festplattengruppen beanspruchen, können Sie Flash-Geräte sowohl für Kapazität als auch für Cache auswählen.

  • Verbessertes Upgrade-Verfahren. Direkte Upgrades von Virtual SAN 5.5 und 6.0 auf Virtual SAN 6.1 werden unterstützt.

  • Virtual SAN 6.1 umfasst einen integrierten Health Service (Integritätsdienst), der die Clusterintegrität überwacht und das Diagnostizieren und Beheben von Problemen mit dem Virtual SAN-Cluster ermöglicht. Der Virtual SAN Health Service bietet mehrere Möglichkeiten zur Überprüfung von Hardwarekompatibilität, Netzwerkkonfiguration und -vorgängen, erweiterte Konfigurationsoptionen sowie Überprüfungen des Zustands von Speichergeräten und der Integrität von Virtual SAN-Objekten. Wenn der Health Service Integritätsprobleme erkennt, löst er vCenter-Ereignisse und -Alarme aus. Zum Anzeigen der Integritätsprüfungen für ein Virtual SAN-Cluster klicken Sie auf Überwachen > Virtual SAN > Integrität.

  • Virtual SAN überwacht die Integrität von SSD-Laufwerken und Magnetfestplatten. Fehlerhafte Geräte werden durch Unmounten proaktiv isoliert. Graduelle Fehler einer Virtual SAN-Festplatte werden erkannt, um das Gerät zu isolieren, bevor der Überlastungsschwellenwert innerhalb des betroffenen Hosts und des gesamten Virtual SAN-Clusters erreicht wird. Bei Erkennung eines fehlerhaften Geräts wird auf jedem Host ein Alarm generiert. Wenn ein fehlerhaftes Gerät automatisch nicht gemountet wird, wird ein Ereignis generiert.

Frühere Versionen von Virtual SAN

Die Funktionen und bekannten Probleme von Virtual SAN 6.0 sind in den Versionshinweisen beschrieben. Versionshinweise für Virtual SAN 6.0 sind an folgenden Speicherorten verfügbar:

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

Hinweis: Die Verwendung von VMware Upgrade Manager (VUM) zur gleichzeitigen Aktualisierung von Hosts kann unter Umständen dazu führen, dass der Zeugenhost parallel zu einem der Datenhosts in einem ausgeweiteten Cluster aktualisiert wird. Konfigurieren Sie VUM 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.

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.1 finden Sie in der Dokumentation Maximalwerte für die Konfiguration.

Bekannte Probleme

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

    Problemumgehung: Fügen Sie dem Zeugenhost die Festplattengruppe nach der Konfiguration des ausgeweiteten Clusters manuell hinzu.

    1. Klicken Sie im Virtual SAN-Cluster auf Verwalten > Einstellungen > Festplattenverwaltung, und wählen Sie den Zeugenhost aus.

    2. Klicken Sie auf das Symbol Neue Festplattengruppe erstellen, und wählen Sie als Kapazitätstyp Flash aus.

    3. Klicken Sie auf OK.
  • 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

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

    Problemumgehung: Um diesen HA-Konfigurationsfehler zu beheben, starten Sie den Host neu, und konfigurieren Sie HA neu.

    • Navigieren Sie zur Ansicht der Hosts und Cluster, und wählen Sie den Cluster aus. Klicken Sie auf Verwalten > vSphere HA.

    • Zum Beheben des Fehlers bei der Aufgabe „Agent aktivieren“ navigieren Sie zur Clusteransicht und aktivieren den Virtual SAN-Statusdienst neu. Navigieren Sie zur Ansicht der Hosts und Cluster, und wählen Sie den Cluster aus. Klicken Sie auf Verwalten > Virtual SAN > Integrität und dann auf Wiederholen.

  • Bei einem Fehler in einer rollierenden Site eines großen ausgeweiteten Clusters (beispielsweise 15:15:1), in dem die einzelnen Knoten in einer Fehlerdomäne nacheinander fehlschlagen (wobei zwischen jedem Fehler einige Sekunden liegen), ist der Zugriff auf VMs möglicherweise nicht mehr möglich oder VMs verwaisen bzw. werden nicht mehr erkannt
    Beachten Sie zum Vermeiden dieses Problems die optimalen Vorgehensweisen für das Arbeiten in einem großen Cluster:

    • Bevor Sie eine bevorzugte Site zwecks Wartung abschalten, konfigurieren Sie zunächst die sekundäre Site als bevorzugte Site und warten Sie ungefähr eine Minute, bis die Änderungen wirksam werden.

    • Bevor Sie alle Knoten in der bevorzugten Site gleichzeitig abschalten, konfigurieren Sie zunächst die sekundäre Site als bevorzugte Site und warten Sie ungefähr eine Minute, bis die Änderungen wirksam werden.

    • Nachdem Sie einen Host abgeschaltet haben, warten Sie jeweils ein bis zwei Minuten, bis Sie den nächsten Host abschalten.

    Problemumgehung: Schalten Sie den ursprünglichen Host wieder online. Wenn Sie den ursprünglichen Host nicht mehr online schalten können, verwenden Sie das Tool zur Wiederherstellung. Einige der letzten Datentransaktionen, die beim Auftreten des Fehlers gerade ausgeführt wurden, gehen dann jedoch möglicherweise verloren.

  • 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. Beachten Sie, dass Sie bei Verwendung von Multi-Byte-Unicode-Zeichen den Grenzwert von 256 Byte eventuell mit weniger als 256 Zeichen erreichen.

    Problemumgehung: Keine.

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

    Problemumgehung: Installieren Sie das VIB zur Integritätsprüfung manuell auf dem Host. Informationen dazu finden Sie in Verwalten von VMware Virtual SAN.

  • 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 Integritätsprü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.

    Problemumgehung: Navigieren Sie zur Ansicht der Hosts und Cluster, klicken Sie auf Verwalten > Einstellungen > Virtual SAN > Integrität und dann auf Wiederholen.

  • 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 Benutzerfreundlichkeit und zur HCL-Datenbank herzustellen, wenn der Cluster keinen direkten Internetzugriff hat.

    Problemumgehung: Keine

  • Nach einer Veränderung der Einstellungen für vCenter HTTP-Port und Zertifizierung werden Virtual SAN-Integritätsprüfungen möglicherweise nicht ordnungsgemäß ausgeführt
    Der Virtual SAN-Integritätsdienst verwendet den HTTP-Standardport 443 und eine Nicht-Root-Leseberechtigung für die Zertifikatsdatei (/etc/vmware-vpx/ssl/rui.crt und /etc/vmware-vpx/ssl/rui.key). Wenn Sie den Standardport oder das Zertifikat so ändern, dass die Nicht-Root-Leseberechtigung nicht mehr besteht, erkennt der Virtual SAN-Integritätsdienst die Änderung nicht, und die Integritätsprüfungen werden nicht ordnungsgemäß ausgeführt.

    Problemumgehung: Legen Sie für die Porteinstellung und die Zertifikatsberechtigung die Standardwerte fest.

  • 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 offline geschaltet wird 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 DVS-Konfiguration
    Das OVA-Paket des Virtual SAN-Zeugenhosts von VMware bietet keine Unterstützung für die DVS-Netzwerkkonfiguration (Distributed Virtual Switch).

    Problemumgehung: Verwenden Sie einen virtuellen Legacy-Switch.

  • Neu: Fehlfunktion des Virtual SAN Health Service bei Abänderung der Einstellungen für HTTPS-Port und Zertifizierung ausgehend von den Standardwerten
    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: Vergewissern Sie sich, dass für den Virtual SAN Health Service die Standardwerte für HTTPS-Port und Zertifizierung verwendet werden.