Méthodologies pour tester les performances d'une liaison WAN

11

Nous avons une paire de nouvelles liaisons Ethernet 1 Gbit / s à routage divers entre des emplacements distants d'environ 200 miles. Le `` client '' est une nouvelle machine raisonnablement puissante (HP DL380 G6, double E56xx Xeons, 48 Go DDR3, paire R1 de 300 Go de disques SAS à 10 000 tr / min, W2K8R2-x64) et le `` serveur '' est également une machine suffisamment décente (HP BL460c G6 , double E55xx Xeons, 72 Go, paire R1 de 146 Go de disques SAS à 10 000 tr / min, HBA Emulex 4Gbps FC à double port lié à deux Cisco MDS9509, puis sur HP EVA 8400 dédié avec 128 disques FC de 450 Go à 15 000 tr / min, RHEL 5.3-x64).

En utilisant SFTP du client, nous ne voyons qu'environ 40 Kbps de débit en utilisant des fichiers volumineux (> 2 Go). Nous avons effectué des tests de serveur à `` autre serveur local '' et voyons environ 500 Mbps via les commutateurs locaux (Cat 6509s), nous allons faire de même côté client, mais c'est dans un jour ou deux.

Quelles autres méthodes de test utiliseriez-vous pour prouver aux fournisseurs de liens que le problème est le leur?

networking performance sftp

— Chopper3
source

J'aimerais également connaître une réponse à celle-ci. Nous allons installer notre ligne louée à 100 Mbits la semaine prochaine dans le courant :)

— Tom O'Connor

comme le dit user37899 - les résultats seraient appréciés.

— pQd

Les mises à jour? Je suis curieux de savoir comment celui-ci se révèle.

— Kyle Brandt

J'ai battu les fournisseurs de liens "assez mal" (ironiquement, ils font partie de la même organisation pour laquelle je travaille!) - ils ne nous sont pas encore revenus.

— Chopper3

1

Ah d'accord, et au fait, si vous pouvez comprendre pourquoi je reçois 7 votes pour serverfault.com/questions/134467/… et 1 pour cela, je voudrais savoir ;-)

— Kyle Brandt

10

Accorder un éléphant:
cela pourrait nécessiter un réglage, probablement pas le problème ici, comme le dit pQd. Ce type de lien est connu sous le nom de "Long, Fat Pipe" ou éléphant (voir RFC 1072 ). Comme il s'agit d'un gros tube gigabit parcourant une distance (la distance est vraiment le temps / la latence dans ce cas), la fenêtre de réception TCP doit être grande (voir le volume illustré TCP / IP 1, section Extensions TCP pour les images).

Pour déterminer ce que doit être la fenêtre de réception, vous calculez le produit de retard de la bande passante:

Bandwidth * Delay = Product

S'il y a une latence de 10 ms, cette calculatrice estime que vous voulez une fenêtre de réception d'environ 1,2 Mo. Nous pouvons faire le calcul nous-mêmes avec la formule ci-dessus:

echo $(( (1000000.00/.01)/8  )) 
12500000

Donc, vous voudrez peut-être exécuter un vidage de paquet pour voir si la mise à l'échelle de la fenêtre TCP (l'extension TCP qui permet des fenêtres plus grandes) se produit correctement pour régler cela une fois que vous avez déterminé quel est le problème majeur.

Window Bound:
Si c'est le problème, que vous êtes lié à la taille de la fenêtre sans mise à l'échelle, je m'attendrais aux résultats suivants si aucune mise à l'échelle de la fenêtre n'est en place et qu'il y a environ 200 ms de latence quelle que soit la taille du tuyau:

Throughput = Recieve Window/Round Trip Time

Donc:

echo $(( 65536/.2 ))
327680 #Bytes/second

Pour obtenir les résultats que vous voyez, il vous suffit de résoudre la latence, qui serait:

RTT = RWIN/Throughput

Donc (pour 40 Ko / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Veuillez vérifier mes mathématiques, et celles-ci n'incluent bien sûr pas tous les frais généraux de protocole / en-tête)

— Kyle Brandt
source

Vous savez que je me sentais un peu coupable de vous avoir «dépassé» temporairement sur le représentant l'autre semaine, et la raison en est à quel point vos réponses sont sacrément bonnes - et BOOM! vous utilisez même un shell pour faire vos calculs, pas le 1.5MB Mac Calculator.app que je fais! :) Merci.

— Chopper3

1

Vous avez aussi de bonnes réponses, et j'aime bien avoir quelqu'un dont je suis proche en tant que représentant, améliore un peu le jeu :-) Une rapide requête Google me rappelle que vous avez également répondu à mes questions: serverfault.com/questions/107263/ … . J'apprécie vraiment les utilisateurs actifs qui essaient de faire en sorte que cette communauté "se produise". Mais merci pour le complément!

— Kyle Brandt

Moi aussi, il n'y a rien que j'aime plus que de savoir que nous avons aidé quelqu'un qui se sentait seul avec un problème frustrant - à part le fromage bien sûr. Cela dit, je déteste quand nous recevons aussi des questions mal formées, avez-vous entendu ma question sur SO podcast 82? a obtenu un t-shirt SF gratuit aussi!

— Chopper3

J'écoute la plupart des podcasts mais j'ai raté celui-là, j'y reviendrai (probablement ce week-end).

— Kyle Brandt

Désolé pour ce pQd, j'ai en fait toujours lu votre pseudo comme PDQ comme dans PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40kbps est très faible [au point que je soupçonne des convertisseurs de média défectueux / une discordance de duplex [mais vous avez du gigabit donc il n'y a pas de place pour le half duplex!] Etc.]. il doit y avoir des pertes de paquets ou une gigue très élevée.

iperf est le premier outil qui me vient à l'esprit pour mesurer le débit disponible. courir d'un côté

iperf -s

et d'autre part:

iperf -t 60 -c 10.11.12.13

Ensuite, vous pouvez échanger les rôles client / serveur, utiliser -d pour duplex, etc. exécuter mtr entre les deux machines avant le début du test et voir quelles pertes de latence / paquets vous avez sur la liaison inutilisée, et comment changent-elles pendant le transfert de données.

vous aimeriez voir: une très petite gigue et aucune perte de paquets jusqu'à ce que le lien soit saturé à 90% de sa capacité.

iperf pour * nix et gagnez , lisez ici et ici à ce sujet.

mtr pour * nix et gagner .

— pQd
source

Nous savons que le lien est composé de 6 liens 1000-base-zx, donc il y a forcément une latence introduite par tout ce qui se répète, mais je suis quand même surpris que vous soyez à quel point il est bas, excellent conseil sur la chose iperf par le façon, j'avais totalement oublié qu'il existait!

— Chopper3

veuillez poster vos résultats!

— The Unix Janitor

1

tracepath peut vous montrer des problèmes de routage entre les deux sites.

iperf, ttcp et bwping peuvent vous fournir des informations utiles.

savez-vous comment ce lien de 1 Go est provisionné? pontez-vous ou routez-vous sur ce lien? Quel est votre SLA pour le lien? vous pourriez être façonné par votre fournisseur de liens?

si vous n'obtenez que 40 Ko, alors il y a un problème grave, êtes-vous sûr que ce n'est pas un lien de 1 Mo plutôt qu'un lien de 1 Go / s. Vous constaterez probablement que la vitesse du lien n'est pas ce que vous en pensez :-)

— Le concierge Unix
source

Merci pour votre réponse, c'est une liaison fibre monomode pontée multi-segments dédiée, il n'y a pas du tout de forme impliquée car c'est juste L2 jusqu'au bout - oh et j'espère que ce n'est pas une liaison 1Mbps, pas avec l'argent que ça coûte :)

— Chopper3

1

si votre pontage vers votre réseau local, c'est-à-dire aucun routage nulle part, les diffusions réseau gaspilleront la capacité de la liaison, c'est vrai pour 1 Go, ce sera une petite fraction, mais un service réseau qui se comporte mal pourrait aplatir la liaison. Je suppose que ces ponts sont hors de votre contrôle. Ces commutateurs peuvent être surchargés ou subir une latence très élevée. Une latence élevée signifie une faible bande passante.

— The Unix Janitor

@ user37899 - une latence élevée ne signifie pas nécessairement une faible bande passante, mais nécessite un réglage ... de toute façon - combien de latence pouvez-vous obtenir sur 200 miles - si les choses vont bien - pas plus de 3-10 ms. arp [ou autre] diffusé sur la liaison gigabit représente probablement une très petite fraction de la capacité totale disponible.

— pQd

1

Si vous avez des diffusions réseau se produisant à un niveau tel qu'elles affectent les performances de la liaison, je soupçonne que vous auriez eu des problèmes de performances internes bien avant que cette nouvelle ligne n'arrive et que vous l'auriez remarqué.

— joeqwerty

@pQd je parlais en fait d'une tempête de diffusion.

— The Unix Janitor

0

RFC 2544 ou Y.156sam

Ce sont des tests de réseau qui sont effectués pour prouver le SLA par le transporteur. IPERF et similaires ne sont pas des méthodes de test réseau vérifiables.

— Ansel Gaddy
source