VNX: Clientes desconectados del servidor CIFS durante la actualización del punto de control interno

Directorios
grandesNasdirtool confirma que los sistemas de archivos de producción afectados contienen varios directorios con más de 500 000 archivos en un solo directorio

De la salida de nasdirtool:.....

/root_vdm_5/Applications/Appstorage/Images,95616,1458761 <=== 95 MB de tamaño y 1,4 millones de archivos
/root_vdm_6/Production/SubDirectory2/REP,150731,2104554 <=== 150 MB de tamaño y 2,1 millones de archivos



Algunos clientes CIFS se desconectan del servidor CIFS de VNX durante la actualización de los puntos de control internos que se usan para la replicación en el arreglo del lado de origen.

Otros clientes de CIFS y NFS en otros recursos compartidos funcionan con normalidad.

Con frecuencia, se puede observar una alta utilización de CPU en el administrador de transferencia de datos; según el tamaño del contenido de los directorios, la utilización de la CPU del administrador de transferencia de datos puede alcanzar el 100 %.  


[nasadmin@VNX-CS0 tmp]$ server_stats server_2 -i 60
server_2 CPU Red Red dVol dVol
Marca de tiempo Util In Out Read Write
% KiB/s KiB/s 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


Una captura de red tomada durante el incidente mostró que las comunicaciones TCP del cliente al servidor funcionaban correctamente, pero el servidor CIFS no respondía al cliente específico que experimentaba el problema en el nivel de protocolo SMB, lo que generaba un tiempo de espera agotado del cliente.

El sistema de archivos del lado de origen en uso para la replicación contiene directorios que superan los 500 000 archivos en un solo directorio. Como se documenta en las notas de la versión de EMC VNX OE for File, si se exceden los 500 000 archivos en un solo directorio, se producirán problemas de rendimiento.

En el registro del administrador de transferencia de datos, se registran los siguientes eventos durante el problema:

2016-08-12 12:58:40: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB415 abortado (cliente WINCLIENT01 desconectado)
2016-08-12 12:58:49: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB034 anulado (cliente WINCLIENT02 desconectado)

2016-08-12 13:09:29: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB356 abortado (cliente WINCLIENT03 desconectado)
2016-08-12 13:09:29: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB358 anulado (cliente WINCLIENT04 desconectado)



El registro del administrador de transferencia de datos muestra que el problema corresponde a una actualización

de punto de control de replicación interna Ejemplo de pausa rápida normal de FS para la actualización de punto de control en este arreglo
del lado de origen 2016-08-19 12:33:39: 26042826752: SVFS: 6: pause() solicitado el fsid:1103
2016-08-19 12:33:39: 26042826752: SVFS: 6: pausa realizada en fsid:1103
   
En este caso, alguna operación retrasa la pausa
2016-08-19 12:42:36: 26042826752: SVFS: 6: pause() solicitado en fsid:1103
...
2016-08-19 12:45:17: 26041909248: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB396 abortado (cliente WINCLIENT01 desconectado)
2016-08-19 12:45:26: 26041909248: SMB: 6: [VDM2] Cuota: getFsAndLock para el subproceso 1SMB478 anulado (cliente WINCLIENT02 desconectado)
...
2016-08-19 13:00:47: 26041909248: SMB: 6:[VDM2] Cuota:getFsAndLock para el subproceso 1SMB298 abortado (cliente WINCLIENT03 desconectado)
2016-08-19 13:00:52: 26042826752: SVFS: 6: pausa realizada en fsid:1103

La pausa de actualización del punto de control interno del lado de origen anterior muestra un comportamiento no normal. Se realizó un estado de alarma de fuerza para confirmar qué estaba causando que la pausa tomara tanto tiempo y el análisis del archivo de volcado de alarma confirmó que el sistema de archivos contiene directorios con millones de archivos en un solo directorio.

Se debe implementar una nueva estructura de subdirectorios en el sistema de archivos de producción. Los archivos en los directorios problemáticos deben distribuirse en los directorios nuevos para no exceder los 500,000 archivos en un solo directorio. A continuación, el administrador de VNX debe eliminar los directorios problemáticos originales.

   

Directriz/especificación	Valor máximo probado	Comentario
Cantidad de archivos por directorio	500,000	Si supera este número, se producirán problemas de rendimiento.