Re: Optimisation de transfert entre Solaris et Linux

Startseite

Nachricht beantworten
Autor: olivieraj
Datum:  
To: guilde
Betreff: Re: Optimisation de transfert entre Solaris et Linux
Bonjour

Selon Yves Martin <ymartin59@???>:

> Bonjour,
>
> On me soumet un problème de transfert de fichiers anormalement long entre
> Linux
> (client scp) et Solaris (serveur ssh)
>
> Les transferts Solaris-Solaris fonctionnent en 4 secondes pour 10 Mo.
> Les transferts Solaris-Linux pour deux serveurs prennent plus de 20 secondes.
> Un troisième Linux n'a pas de problème (4s aussi).
>
> Tous les Linux sont identiques (hardware et soft) sous RedHat 4.
>
> L'infrastructure réseau est un casse-tête de firewall. Je soupçonne que le
> problème vienne d'un des firewalls qui introduirait une latence - peut-être
> des
> retry tcp ?
>
> Comment mettre en évidence le point de contention ?
> Existe-t-il des outils qui permettent d'analyser facilement la sortie de
> tcpdump
> sur un Linux sur ce point particulier (retry, problème d'autonégotation) ?
>
> Existent-ils des problèmes connus de transfert Linux/Solaris ?
> Des documentations sur l'optimisation de la pile TCP par /etc/sysctl.conf ?
>
> Merci d'avance pour toute piste ou méthode à appliquer


Je te conseille de lancer un transfert similaire entre un Solaris-Solaris et
un Solaris-Linux, en récupérant les traces tcpdump sur chacune des 4 machines.
Puis, utilise http://www.wireshark.org/ pour l'analyse graphique des données (ce
soft est capable d'ouvrir les fichiers de trace réseau de tcpdump), en comparant
ligne à ligne les paquets échangés.

Je vois 2 raisons pour un tel ralentissement dans la configuration
Solaris-Linux :
- L'une des deux machines veut faire de la résolution de DNS/DNSreverse lors de
l'établissement de la connexion. Et pour toutes sortes de raisons (mauvaise
configuration réseau des machines, serveur DNS éloigné, Firewall bloquant les
accès, etc...), cette connexion ne se fait pas, ou mal.

- Autre hypothèse : Les deux machines tentent d'utiliser le protocole "AUTH"
d'authentification (port TCP/113), mais ce port est filtré par un firewall. J'ai
eu par le passé ce genre de problème avec un serveur ProFTPD lancé depuis
XinetD. A cause d'une option "USERID" dans le "/etc/xinetd.d/*", le serveur
ProFTPD interrogeait le port 113 du client, lorsque celui-ci se connectait sur
le serveur. Or, le client avait ce port fermé (merci Netfilter, le FW de Linux),
et le serveur attendait un timeout d'une bonne dizaine de seconde avant de
continuer la connexion.

Cordialement,

                                          Olivier