Equilibrage des flux TCP

Le
Emmanuel
Bonsoir,

J'ai un gros problème d'équilibrage de charge sur mon réseau.
Voilà la topologie :

[Serveur]--[Switch 1]--[Switch 2]--[Client 2]
|
[Client 1]

Le serveur est un serveur de base de données sous Debian/Sarge
Les clients sont des XP
Le switch 1 est un NetGear GSM7352S (48p/Gbit)
Le switch 2 est un Netgear FS750T2 (48p/100Mb)

Le serveur est connecté en Gb
Le client 1 aussi
Le lien entre les switchs et le lien du client 2 sont à 100Mb

Mon problème est le suivant :
Quand Client2 établit une connexion au serveur et commence à lire de
données, celles-ci partent plus vite du serveur que ce que le client
n'accepte (normal vu la diff de vitesse des liens).
Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose et que la connexion TCP fait un slow
restart.
Le client 1 ne connait, quant à lui aucun pb de performance.


Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).

Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs
serveurs et +++ clients.

Merci d'avance pour vos lumières.

Manu
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mathieu Goutelle
Le #876282
Bonsoir,

Dans l'article écrit :
Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).


Sur un LAN, je doute que ce soit ça qui plombe les performances :
compte tenu du délai d'aller-retour très court, la dynamique de TCP
doit être très bonne. En plus, que vous fassiez de la limitation de
débit au niveau du serveur ou dans le switch (parce que c'est ce qu'il
se passe, hein), il y aura à un moment ou à un autre des paquets perdus
et donc un TCP slow start.

Sincèrement, je pencherais plus pour un problème sur la machine cliente
qui n'arrive pas à suivre... Pour s'en assurer, il suffirait de faire
un test à la iperf entre serveur et client et vérifier que vous obtenez
un très grosse part de 100Mbit/s (genre 95). Si oui, c'est votre
application cliente qui ne suit pas ou un problème de disque sur le
client.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - http://www.cadichonne.net/

kurtz le pirate
Le #876278
In article Emmanuel
Bonsoir,

J'ai un gros problème d'équilibrage de charge sur mon réseau.
Voilà la topologie :

[Serveur]-----[Switch 1]-----[Switch 2]-----[Client 2]
|
[Client 1]

Le serveur est un serveur de base de données sous Debian/Sarge
Les clients sont des XP
Le switch 1 est un NetGear GSM7352S (48p/Gbit)
Le switch 2 est un Netgear FS750T2 (48p/100Mb)

Le serveur est connecté en Gb
Le client 1 aussi
Le lien entre les switchs et le lien du client 2 sont à 100Mb

Mon problème est le suivant :
Quand Client2 établit une connexion au serveur et commence à lire de
données, celles-ci partent plus vite du serveur que ce que le client
n'accepte (normal vu la diff de vitesse des liens).
Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose et que la connexion TCP fait un slow
restart.
Le client 1 ne connait, quant à lui aucun pb de performance.


Je voudrais savoir s'il y a moyen de paramétrer mes switchs, mon serveur
et/ou mes clients pour permettre de réguler le traffic sans aller
jusqu'au débordement de buffer (le slow restart plombe les performances).

Bien sûr, le cas présenté ici est isolé, dans la vraie vie j'ai plusieurs
serveurs et +++ clients.

Merci d'avance pour vos lumières.

Manu


il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?

normalement, ce genre de chose est bien géré au niveau couches réseau.


--
klp

Emmanuel
Le #878102
"kurtz le pirate"
il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?

normalement, ce genre de chose est bien géré au niveau couches réseau.


--
klp


Merci à tous pour votre aide.

Ce n'est pas l'établissement de connexion qui pose problème.
Le protocole, c'est de la base de données (c'est un serveur Hyper File).
J'ai fait des captures avec wireshark et je constate tjs le même phénomène :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30
et 50% de trames
IP en plus de ce que le client acquitte, du coup ils sont de plus en plus
déphasés.
Au bout d'un certain temps, j'ai carément un paquets de trames qui
disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui
plombe tout.
Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.

Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un
débit de env. 50Mbps entre le serveur
et les clients du switch 2. ça me semble bas.

Manu

Mathieu Goutelle
Le #878101
Bonsoir,

Dans l'article écrit :
une fois que le serveur et un client dialoguent, le serveur envoie
entre 30 et 50% de trames IP en plus de ce que le client acquitte, du
coup ils sont de plus en plus déphasés. Au bout d'un certain temps,
j'ai carément un paquets de trames qui disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow
restart qui plombe tout.


Il ne plombe pas tout : il fait son boulot ! ;-)
Comme ton serveur tente d'envoyer à plus de 100 Mbit/s, il faut bien
que quelque chose le limite et ce quelque chose, c'est TCP qui réagit à
une perte de paquets.

Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et
j'ai un débit de env. 50Mbps entre le serveur et les clients du
switch 2. ça me semble bas.


Je suis d'accord : tu devrais au moins faire du 80-90 avec iperf, sans
trafic concurrent.

Tu peux regarder les compteurs du switch, pour voir si tu n'as pas trop
d'erreurs. S'il y a des erreurs, regarde au niveau du cablâge ou des
cartes. Essaie aussi d'augmenter sur les clients surtout le buffer TCP
(http://psc.edu/networking/projects/tcptune/). Vois aussi du côté de
SACK (Selective Acknowledgement) car je ne sais pas si c'est activé par
défaut sous Windows.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - http://www.cadichonne.net/

Elekaj34
Le #878100
"kurtz le pirate"
il faudrait avoir des précisions sur le "client2 etablit une connexion"
et le "commence a lire" : c'est du ftp ? http ? autre ?

normalement, ce genre de chose est bien géré au niveau couches réseau.


--
klp


Merci à tous pour votre aide.

Ce n'est pas l'établissement de connexion qui pose problème.
Le protocole, c'est de la base de données (c'est un serveur Hyper File).
J'ai fait des captures avec wireshark et je constate tjs le même phénomène :
une fois que le serveur et un client dialoguent, le serveur envoie entre 30
et 50% de trames
IP en plus de ce que le client acquitte, du coup ils sont de plus en plus
déphasés.
Au bout d'un certain temps, j'ai carément un paquets de trames qui
disparaissent dans le switch 2
et le client emet alors un TCP-Out of order. Il s'ensuit le slow restart qui
plombe tout.
Comme tous les clients du switch 2 ont ce pb, le réseau s'effondre.

Sinon, pour répondre à Mathieu, j'ai fait une mesure avec iperf et j'ai un
débit de env. 50Mbps entre le serveur
et les clients du switch 2. ça me semble bas.

Manu




J'ai eu il y a quelques temps le même problème que toi. Le remplacement
du switch a résolu le problème.

De plus, il arrive (mais c'est très rare) que l'utilisation de switch de
marque différentes pose problème (par ex netgear et 3com ne semblent pas
faire de copinage).

Cordialement,

Elekaj


Pascal Hambourg
Le #878099
Salut,


Au bout d'un certain temps, la quantité émise par le serveur est telle que
le buffer du switch 2 explose


Il n'y a pas un mécanisme de contrôle de flux au niveau ethernet
(802.3x) censé empêcher ça ?

Publicité
Poster une réponse
Anonyme