RecoverPoint per macchina virtuale: Ciclo del consistency group tra lo stato di inizializzazione e lo stato di errore in un ambiente di scalabilità

N/D

Consistency group che passa dallo stato di inizializzazione a quello di errore in un'ambiente

di scalabilità causando la replica dei dati non disponibile (DRU).

I sintomi riscontrati nei registri:

Registri dello splitter ESX:

i registri riportati di seguito indicano che la lettura di /vmfs/volumes/vsan:5xxxxxxxxxxxx-dxxxxxxxxxxxxxxx non è riuscita, pertanto tutti i volumi RPVS nella VSAN verranno rimossi.    

spl_esx_discover_RPvStorage_clusters_in_datastore: impossibile leggere la directory /vmfs/volumes/vsan:5xxxxxxxxx-dxxxxxxxxxxxxxx, restituita con stato Timeout

update_rpvs_db: la LUN 1 non è stata analizzata all'ultimo aggiornamento
della visualizzazione del dispositivo RPVS_ClusterLuns_removeLunInfo: chiamato per lun=1 (nome RPVS_Lun00001.vmdk). ID cluster=2xxxxxxxxxxxx
update_rpvs_db: la LUN 12 non è stata analizzata nell'ultimo aggiornamento
della visualizzazione del dispositivo RPVS_ClusterLuns_removeLunInfo: chiamato per lun=12 (nome RPVS_Lun00012.vmdk). ID cluster = 2xxxxxxxxxxx
update_rpvs_db: la LUN 13 non è stata analizzata durante l'ultimo aggiornamento della visualizzazione del dispositivo...    

 * Il processo di rilevamento RPVS ha esito positivo, quindi tutti i volumi RPVS vengono aggiunti nuovamente:    
 
parse_vmdk_file: chiamato con file /vmfs/volumes/vsan:5xxxxxxxxxxxxxxxx/RPvStorage/4xxxxxxxxxxxx/RPVS_Lun00001.vmdk
parse_vmdk_file: capacity=12000000, thinLun=0, flat_filename=RPVS_Lun00001-flat.vmdk, rawguid=0x6xxxxxxxxxxxxxxx
RPVS_ClusterLuns_addLunInfo: aggiunta LUN 1, cluster 4xxxxxxxxxxxxxxxxxxx parse_vmdk_file: richiamato con file /vmfs/volumes/vsan:5xxxxxxxxxxxxxx-dxxxxxxxxxxxxxxxx/RPvStorage_23d5fb88838940xxx_010/RPVS_Lun00012.vmdk parse_vmdk_file: capacity=524288000, thinLun=0, flat_filename=RPVS_Lun00012-flat.vmdk, rawguid=0x6xxxxxxxxxxxx RPVS_ClusterLuns_addLunInfo: aggiunta LUN 12, cluster 2xxxxxxxxxxxxxxx


* Registro indicante che il processo di rilevamento RPVS richiede molto tempo        

CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 32585607 microsecondi, comandi num in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 33277695 microsecondi, num comandi in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 35834242 microsecondi, num comandi in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 36488014 microsecondi, comandi num in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 37767728 microsecondi, comandi num in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 49355575 microsecondi, comandi num in coda: 11 CommandExecuterBase_v_handleCommands_i: cmd 0x417fdde35040, cmd-execute>(CommandRPVSDiscovery), tempo di esecuzione 109257427 microsecondi, comandi num in coda: 19

Interessata tutte le versioni di RP4VM

Lo splitter ESX esegue la scansione del volume RPVS (journal e repository) ogni t_rpvsDiscoveryPeriodicTimerInterval (impostazione predefinita: 30) secondi.    
La scansione viene eseguita leggendo /vmfs/volumes/ e attraversando ogni directory al suo interno, alla ricerca di RPVS_LunXXXXX.vmdk
Un volume RPVS risiede in /vmfs/volumes/<datastore>/<cluster=id>/. In un'ambiente VSAN, risiede in /vmfs/volumes/vsan:<vsan-id>/<cluster=id>/
Se la lettura di una qualsiasi directory all'interno di /vmfs/volumes/ non riesce (timeout, errore temporaneo e così via), tutti i volumi RPVS nella directory con errori vengono rimossi.    
In tutte le esecuzioni successive, se il processo di rilevamento rpvs riesce a leggere e trovare RPVS_LunXXXXX.vmdk, i volumi RPVS corrispondenti verranno aggiunti nuovamente.          
Questo è il motivo per cui i CG vanno in loop tra Error e Init.      
Il problema si amplifica quando un numero elevato di host nella VSAN legge contemporaneamente le directory in /vmfs/volumes/.

Soluzione alternativa:

In ogni host ESX nel cluster, aggiornare il valore di modifica dello splitter di t_rpvsDiscoveryPeriodicTimerInterval
a un valore casuale compreso tra 180 e 600 secondi e riavviare kdriver.
ESX Splitter Tweak è disponibile all'indirizzo
/etc/kdriver/tweak/tweak.params.splitter o /etc/config/emc/rp/kdriver/tweak/tweak.params.splitter.  

Risoluzione:

Dell EMC Engineering sta attualmente esaminando questo problema. Non è ancora disponibile una correzione permanente. Contattare Dell EMC Customer Support Center o un responsabile del servizio per assistenza e riportare l'ID di questa soluzione.