Estrategia de solución de problemas para un rendimiento muy pobre de iSCSI / NFS

Tenemos un nuevo Synology RS3412RPxs que ofrece objetivos iSCSI a tres cajas de Windows 2008 R2 y NFS a una caja de OpenBSD 5.0.

Iniciar sesión en el RS3412 con ssh y leer / escribir tanto archivos pequeños como archivos de 6GB usando dd y varios bloques muestra un excelente rendimiento de E / S de disco.

Usando dd o iometer en los clientes iSCSI / NFS, alcanzamos hasta 20Mbps (eso no es un error tipográfico. Veinte Mbps). Esperábamos hacer un mejor uso de las múltiples NIC de Gbit en Synology.

Verifiqué el conmutador y la configuración del puerto NIC está establecida en gigabit, no en negociación automática. Lo hemos intentado con y sin Jumboframes sin diferencia. Verifiqué con ping que la MTU es actualmente 9000. Se han implementado dos actualizaciones de firmware.

Voy a intentar un enlace directo entre el objetivo iSCSI y el iniciador para descartar problemas de cambio, pero ¿cuáles son mis otras opciones?

Si rompo wireshark / tcpdump, ¿qué busco?

Como parece ser el tema común aquí, eche otro vistazo a la configuración de control de flujo en los conmutadores. Si el (los) conmutador (es) tienen estadísticas de contador Ethernet, fíjelas y vea si hay una gran cantidad de tramas de PAUSA de Ethernet. Si es así, ese es probablemente tu problema. En general, deshabilitar QOS en los conmutadores resuelve este problema.

Flujos como ese me sugieren que los diversos métodos de control de flujo TCP no funcionan correctamente. He visto algunos problemas con los núcleos de Linux que hablan con las versiones de Windows posteriores a Vista y obtienes rendimientos como ese. Tienden a aparecer bastante bien en Wireshark una vez que echas un vistazo.

La peor posibilidad absoluta es que el ack retrasado de TCP esté completamente roto y verá un patrón de tráfico que se ve así:

packet
packet
[ack]
packet
packet
[ack]

Lo resolví aplicando actualizaciones de controladores de NIC a los servidores de Windows. Las NIC inteligentes que vienen con algunos servidores (broadcom) a veces pueden fallar de maneras interesantes, y esta es una.

Un patrón de tráfico normal sería una gran cantidad de paquetes seguidos de un paquete Ack.

La otra cosa a tener en cuenta son los largos retrasos. Los valores sospechosos son .2 segundos y 1.0 segundos. Eso sugiere que un lado no está obteniendo lo que espera y está esperando que expire el tiempo de espera antes de responder. Combine el patrón de paquetes defectuosos anterior con un retraso de 200 ms para el ACK y obtendrá rendimientos de 1 MB / s.

Esos son los malos patrones de tráfico fáciles de notar.

No he trabajado con ese tipo de dispositivo NAS, así que no sé cuán modificable es arreglar lo que se encuentre.