Stratégie de dépannage pour de très mauvaises performances iSCSI / NFS

Nous avons un nouveau Synology RS3412RPxs qui offre des cibles iSCSI à trois boîtiers Windows 2008 R2 et NFS à un boitier OpenBSD 5.0.

La connexion au RS3412 avec ssh et la lecture / écriture de petits fichiers et de 6 Go à l'aide de dd et de différentes tailles de blocs montrent d'excellentes performances d'E / S sur le disque.

En utilisant dd ou iometer sur les clients iSCSI / NFS, nous atteignons jusqu'à 20 Mbps (ce n'est pas une faute de frappe. Vingt Mbps). Nous espérions un peu mieux utiliser les multiples cartes réseau Gbit dans le Synology.

J'ai vérifié que la configuration du commutateur et du port NIC est définie sur gigabit, et non sur la négociation automatique. Nous avons essayé avec et sans Jumboframes sans aucune différence. J'ai vérifié avec ping que le MTU est actuellement 9000. Deux mises à jour du firmware ont été déployées.

Je vais essayer un lien direct entre la cible iSCSI et l'initiateur pour exclure les problèmes de commutation, mais quelles sont mes autres options?

Si je casse wireShark / tcpdump, que dois-je rechercher?

Comme cela semble être le thème commun ici, jetez un autre regard sur les paramètres de contrôle de flux sur le (s) commutateur (s). Si le ou les commutateurs ont des statistiques de compteur Ethernet, examinez-les et voyez s'il existe un grand nombre de trames de PAUSE Ethernet. Si c'est le cas, c'est probablement votre problème. En général, la désactivation de QOS sur le ou les commutateurs résout ce problème.

Des flux comme celui-ci me suggèrent que les différentes méthodes de contrôle de flux TCP ne fonctionnent pas correctement. J'ai vu quelques problèmes avec les noyaux Linux parlant avec les versions Windows post-Vista et vous obtenez des débits comme ça. Ils ont tendance à apparaître assez bien dans Wireshark une fois que vous y jetez un coup d'œil.

La pire possibilité absolue est que l'acquittement différé TCP soit complètement rompu et vous verrez un modèle de trafic qui ressemble à:

packet
packet
[ack]
packet
packet
[ack]

J'ai résolu celui-ci en appliquant les mises à jour du pilote NIC aux serveurs Windows. Les cartes réseau intelligentes fournies avec certains serveurs (Broadcom) peuvent parfois échouer de manière intéressante, et celle-ci en est une.

Un modèle de trafic normal serait un grand nombre de paquets suivis d'un paquet Ack.

L'autre chose à rechercher est de longs retards. Les valeurs suspectes sont de 0,2 seconde et 1,0 seconde. Cela suggère qu'un côté n'obtient pas ce qu'il attend et attend qu'un délai expire avant de répondre. Combinez le mauvais modèle de paquet ci-dessus avec un retard de 200 ms pour l'ACK et vous obtenez des débits d'un énorme 1 Mo / s.

Ce sont les mauvaises configurations de trafic faciles à remarquer.

Je n'ai pas travaillé avec ce type de périphérique NAS, donc je ne sais pas comment il est possible de réparer tout ce qui est trouvé.