VNX: Client disconnessi dal server CIFS durante l'aggiornamento del checkpoint interno

Directory di grandi dimensioni
Nasdirtool conferma che i file system di produzione interessati contengono più directory con oltre 500.000 file in un'unica directory

Dall'output di nasdirtool:.....

/root_vdm_5/Applications/Appstorage/Images,95616,1458761 <=== 95 MB di dimensioni e 1,4 milioni di file
/root_vdm_6/Production/SubDirectory2/REP,150731,2104554 <=== 150 MB di dimensioni e 2,1 milioni di file



Alcuni client CIFS vengono disconnessi dal server CIFS VNX durante l'aggiornamento dei checkpoint interni utilizzati per la replica sull'array lato origine.

Altri client CIFS e NFS su altre share funzionano normalmente.

È possibile osservare frequentemente un elevato utilizzo della CPU sul data mover, a seconda delle dimensioni del contenuto delle directory, l'utilizzo della CPU del data mover può raggiungere il 100%.  


[nasadmin@VNX-CS0 tmp]$ server_stats server_2 -i 60
server_2 CPU Rete Rete dVol dVol
Timestamp Util In Out Read Write
% KiB/s KiB/s KiB/s KiB/
s 10:41:25 99 16123 62578 61912 28048
10:42:25 98 4242 63170 62433 9793
10:43:25 99 2935 46987 48618 8918
10:44:25 99 7499 45901 46373 13019
10:45:25 99 4564 47836 48018 9625
10:46:25 98 3973 52316 52167 9035
10:47:25 98 9777 60167 55127 16238
10:48:25 97 18513 76583 70269 26258
10:49:25 98 11885 43789 43595 17238
10:50:25 99 17868 55491 52966 21029
10:51:25 99 8171 43491 43013 11961
10:52:25 99 8835 50947 50328 13369


Un'acquisizione di rete effettuata durante l'incidente ha mostrato che le comunicazioni TCP dal client al server funzionavano correttamente, ma il server CIFS non ha risposto al client specifico che ha riscontrato il problema a livello di protocollo SMB, causando un timeout del client.

Il file system lato origine in uso per la replica contiene directory che superano i 500.000 file in un'unica directory. Come documentato nelle note di rilascio di EMC VNX OE for File, il superamento di 500.000 file in una singola directory comporterà problemi di prestazioni.

Dal registro del data mover vengono registrati i seguenti eventi durante il problema:

2016-08-12 12:58:40: SMB: 6: [VDM2] Quota:getFsAndLock per il thread 1SMB415 interrotto (client WINCLIENT01 disconnesso)
2016-08-12 12:58:49: SMB: 6: [VDM2] Quota:getFsAndLock per thread 1SMB034 interrotto (client WINCLIENT02 disconnesso)

2016-08-12 13:09:29: SMB: 6:[VDM2] Quota:getFsAndLock per thread 1SMB356 interrotto (client WINCLIENT03 disconnesso)
2016-08-12 13:09:29: SMB: 6: [VDM2] Quota:getFsAndLock per thread 1SMB358 interrotto (client WINCLIENT04 disconnesso)



Il registro del data mover mostra che il problema corrisponde a un aggiornamento

del checkpoint di replica interno Esempio di normale pausa rapida del FS per l'aggiornamento dei checkpoint su questo array
lato origine 2016-08-19 12:33:39: 26042826752: SVFS: 6: pause() richiesto su fsid:1103
2016-08-19 12:33:39: 26042826752: SVFS: 6: pausa fatta su fsid:1103
   
In questo caso qualche operazione sta ritardando la pausa
2016-08-19 12:42:36: 26042826752: SVFS: 6: pause() richiesto su fsid:1103
...
2016-08-19 12:45:17: 26041909248: SMB: 6: [VDM2] Quota:getFsAndLock per thread 1SMB396 interrotto (client WINCLIENT01 disconnesso)
2016-08-19 12:45:26: 26041909248: SMB: 6:[VDM2] Quota:getFsAndLock per il thread 1SMB478 interrotto (client WINCLIENT02 disconnesso)
...
2016-08-19 13:00:47: 26041909248: SMB: 6: [VDM2] Quota:getFsAndLock per thread 1SMB298 interrotto (client WINCLIENT03 disconnesso)
2016-08-19 13:00:52: 26042826752: SVFS: 6: Pausa eseguita su FSID:1103

La pausa di aggiornamento del checkpoint interno lato origine sopra mostra un comportamento non normale. È stato eseguito un errore forzato per confermare il motivo per cui la pausa richiedeva così tanto tempo e l'analisi del file di dump di errore grave ha confermato che il file system contiene directory con milioni di file in un'unica directory.

È necessario creare una nuova struttura di sottodirectory nel file system di produzione. I file nelle directory problematiche devono essere distribuiti tra le nuove directory in modo da non superare i 500.000 file in una singola directory. Le directory originali problematiche devono quindi essere eliminate dall'amministratore VNX.

   

Linee guida/specifiche	Valore massimo testato	Commento
Numero di file per directory	500,000	Il superamento di questo numero causerà problemi di prestazioni.