Release Notes

Tabelle 11. Bekannte Probleme (fortgesetzt)
Problemnummer Funktionsbereich Beschreibung Workaround
LDAP/AD finden Sie im Dokument
„Authenticate Directory Service“
unter www.solveonline.emc.com/
solve/home/74.
VPLEX-37787 UI Die LDAP/AD-Konfiguration im Metro Node ist
nicht abwärtskompatibel.
Entfernen Sie vor dem Upgrade
von 7.0/7.0 P1 auf 7.0.1 die
vorhandene LDAP/AD-Konfiguration
und konfigurieren Sie sie nach dem
Upgrade auf 7.0.1 neu. Informationen
zum Entfernen und Konfigurieren von
LDAP/AD finden Sie im Dokument
„Authenticate Directory Service“
unter www.solveonline.emc.com/
solve/home/74.
VPLEX-38097 CLI Für <director>/ports/<port>::sfp-status
zeigt die CLI den Wert
DIAG_PAGE_CHECKSUM_FAILED an.
Ignorieren Sie diesen Parameter und
den SFP-Status. Dieses Konzept gilt
nicht für die Metro Node-Plattform.
VPLEX-38208 Systemkonfiguration Wenn „collect-diagnostics“ ausgeführt
wird und ein „system_config“-Vorgang
durchgeführt wird, der die Konfigurationsdatei
(SCIF) aktualisiert, wird der „collect-
diagnostics“-Prozess neu gestartet und
die System-Tar-Datei fehlt in der
Ausgabedatei .tar.gz. Die System-Tar-Datei
wird nicht erzeugt.
Vermeiden Sie Änderungen an der
Systemkonfiguration, während „collect-
diagnostics“ ausgeführt wird. Wenn
in der „collect-diagnostics“-Datei
nach einer „system_config“-Änderung
Schlüsseldateien fehlen, führen Sie zum
Abrufen der fehlenden System-Tar-
Datei entweder „collect-diagnostics“
komplett neu aus oder führen Sie nur
den neuen „collect-diagnostics“-Teil der
Erfassung mit dem Linux-Befehl „curl
-X POST“ (www.localhost:9007/vplex/
diag/collect-jobs) erneut aus.
VPLEX-38239 Systemkonfiguration In seltenen Fällen kann ein Metro Node-
Director nicht gestartet werden, wenn er
auf eine Benutzereingabe mit CBL0009:
Backplane connector is not
connected wartet.
Starten Sie den Director neu. Dies
behebt das Problem, da festgestellt
wurde, dass es sich um ein falsch
negatives Ergebnis handelt, wenn
BIOS/POST prüft, ob eine interne
Verbindung innerhalb des Gehäuses
vorhanden ist.
Erwartetes Verhalten
In diesem Abschnitt wird das erwartete Verhalten in Metro Node beschrieben.
● System-Volumes wie Metadaten und Protokollierungs-Volumes werden auf Thin Devices unterstützt. Metro Node ist für
Systemvorgänge jedoch von diesen Volumes abhängig. Alle Extents sollten vorab zugewiesen werden, um zu verhindern, dass kein
Speicherplatz mehr vorhanden ist.
● Während die Cluster in Kontakt sind, verhindert Metro Node, dass dasselbe Speicher-Volume auf jedem Cluster beansprucht wird.
Wenn die Cluster jedoch partitioniert sind, kann Metro Node nicht verhindern, dass dasselbe Storage Volume auf beiden Clustern
beansprucht wird. Wenn Metro Node dies erkennt, wird in diesem Fall ein Call Home gesendet. Dieses Problem sollte sofort nach der
Erkennung behoben werden.
● Wenn eine Komponente eines verteilten Geräts in einer Consistency Group nicht integer und für eine Neuerstellung gekennzeichnet
ist, können Sie die nicht integre Komponente entfernen. Eine verteilte Consistency Group erfordert verteilte Gerätemitglieder mit zwei
Elementen. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
1. Verwenden Sie den Befehl attach mirror, um eine neue Spiegelung an die integre Komponente anzuhängen.
2. Trennen Sie die alte, nicht integre Spiegelung.
● Wenn die Metadatennutzung auf einem Cluster 90 % überschreitet, löst Metro Node ein Call-Home-Event aus. Wenn die
Metadatennutzung auf dem anderen Cluster 8 Stunden nach dem ersten Cluster auch 90 % überschreitet, löst Metro Node kein
Call-Home-Event aus. Dies liegt am Design und tritt in Metro-Node-Metro-Konfigurationen auf.
12
Versionshinweise