RecoverPoint for Virtual Machine: Schleifen der Konsistenzgruppe zwischen dem Init- und dem Fehlerstatus in einer Skalierungsumgebung
Summary: RecoverPoint for Virtual Machine: Schleifen der Konsistenzgruppe zwischen dem Init- und dem Fehlerstatus in einer Skalierungsumgebung
Symptoms
Konsistenzgruppenschleife zwischen dem Start- und Fehlerstatus in einer Skalierungsumgebung
führt dazu, dass die Datenreplikation nicht verfügbar ist (DRU).
In den Protokollen gefundene Symptome
: ESX-Splitter-Protokolle:
Die folgenden Protokolle weisen darauf hin, dass das Lesen von /vmfs/volumes/vsan:5xxxxxxxxxx-dxxxxxxxxxxxxxxxxxx fehlgeschlagen ist, sodass alle RPVS-Volumes im VSAN entfernt werden.
spl_esx_discover_RPvStorage_clusters_in_datastore: Fehler beim Lesen des Verzeichnisses /vmfs/volumes/vsan:5xxxxxxxxxxxx-dxxxxxxxxxxxx, zurückgegeben mit dem Status Timeout
update_rpvs_db: LUN 1 was not scanned on last device view Update
RPVS_ClusterLuns_removeLunInfo: called for LUN=1 (Name RPVS_Lun00001.vmdk). Cluster-ID=2xxxxxxxxxxxx
update_rpvs_db: LUN 12 wurde bei der letzten Aktualisierung
der Geräteansicht nicht gescannt RPVS_ClusterLuns_removeLunInfo: LUN=12 aufgerufen (Name RPVS_Lun00012.vmdk). Cluster-ID = 2xxxxxxxxxxx
update_rpvs_db: LUN 13 wurde bei der letzten Aktualisierung der Geräteansicht nicht gescannt ...
* Der RPVS-Erkennungsprozess ist erfolgreich, daher werden alle RPVS-Volumes wieder hinzugefügt:
parse_vmdk_file: aufgerufen mit Datei /vmfs/volumes/vsan:5xxxxxxxxxx/RPvStorage/4xxxxxxxxxxx/RPVS_Lun00001.vmdk
parse_vmdk_file: capacity=12000000, thinLun=0, flat_filename=RPVS_Lun00001-flat.vmdk, rawguid=0x6xxxxxxxxxxxx
RPVS_ClusterLuns_addLunInfo: LUN 1, Cluster 4xxxxxxxxxxxxxxxx hinzugefügt parse_vmdk_file: aufgerufen mit Datei /vmfs/volumes/vsan:5xxxxxxxxx-dxxxxxxx/RPvStorage_23d5fb88838940xxx_010/RPVS_Lun00012.vmdk parse_vmdk_file: capacity = 524288000, thinLun = 0, flat_filename = RPVS_Lun00012-flat.vmdk, rawguid=0x6xxxxxxxxxxxxxxx RPVS_ClusterLuns_addLunInfo: LUN 12, Cluster 2xxxxxxxxxxxxxxx
hinzugefügt * Protokoll, das darauf hinweist, dass der RPVS-Erkennungsprozess lange Zeit in Anspruch genommen hat
CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 32585607 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 33277695 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 35834242 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 36488014 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 37767728 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 49355575 Mikrosekunden, Anzahl Befehle in der Warteschlange: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), Laufzeit 109257427 Mikrosekunden, Anzahl Befehle in der Warteschlange: 19
Betroffene alle RP4VM-Versionen
Cause
ESX-Splitter sucht alle t_rpvsDiscoveryPeriodicTimerInterval nach RPVS-Volumes (Journal und Repository) (Standard: 30) Sekunden.
Der Scan erfolgt durch Lesen von /vmfs/volumes/ und Durchlaufen jedes darin befindlichen Verzeichnisses nach RPVS_LunXXXXX.vmdk
. Ein RPVS-Volume befindet sich in /vmfs/volumes/<datastore>/<cluster=id>/. In einer VSAN-Umgebung befindet sie sich in /vmfs/volumes/vsan:<vsan-id>/<cluster=id>/
. Wenn das Lesen eines Verzeichnisses in /vmfs/volumes/ fehlschlägt (Timeout, vorübergehender Fehler usw.), werden alle RPVS-Volumes aus dem ausgefallenen Verzeichnis entfernt.
Wenn der RPVS-Ermittlungsprozess RPVS_LunXXXXX.vmdk erfolgreich liest und findet, werden die entsprechenden RPVS-Volumes in allen nachfolgenden Ausführungen wieder hinzugefügt.
Dies ist der Grund, warum die CGs zwischen Error und Init schleifen.
Das Problem wird noch größer, wenn eine große Anzahl von Hosts im VSAN gleichzeitig Verzeichnisse unter /vmfs/volumes/ liest.
Resolution
Aktualisieren Sie auf jedem ESX-Host im Cluster den Splitter-Anpassungswert von t_rpvsDiscoveryPeriodicTimerInterval
auf einen zufälligen Wert zwischen 180 und 600 Sekunden und starten Sie kdriver neu.
ESX Splitter Tweak finden Sie unter
/etc/kdriver/tweak/tweak.params.splitter oder /etc/config/emc/rp/kdriver/tweak/tweak.params.splitter.
Lösung:
Dell EMC Engineering untersucht dieses Problem derzeit. Es wird noch an einer dauerhaften Lösung gearbeitet. Wenden Sie sich an das Dell EMC Kundensupportcenter oder Ihren Servicemitarbeiter, um Unterstützung zu erhalten und geben Sie die Lösungs-ID an.