Bonjour à tous,
Récemment inscrit à la liste, je sollicite votre aide pour un problème NFS, voici le contexte:
Nous possédons deux environnements (Production et Préproduction): sur chaque environnement se trouvent deux serveurs: un serveur de base de données et un serveur web.
Les serveurs web de chaque environnement récupèrent des données importées sur un serveur via NFS, les deux serveurs WEB sont en tout point identiques (Hardware et Software).
Mon problème est le suivant:
Nous perdons la connexion entre le serveur de Préproduction et le serveur NFS de manière aléatoire, ce problème n'a jamais été relevé jusqu’à ce jour sur le serveur de Production. Les 2 environnements et le serveur NFS sont sur deux réseaux différents, un FireWall autorisant les connexions sur le port 2049 et 111. Les flux mis en place sont les mêmes pour la Prod et la Préprod. Voici la configuration:
*Serveur WEB:*
*OS* -> RedHat 2.6.18-164.11.1.el5
*/etc/fstab* -> 192.168.X.X:/var/ftp/AExporter /usr/local/AExporter nfs soft,intr,rsize=32768,wsize=32768,nosuid,tcp 0 0
*netstat* -> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2950/portmap tcp 0 0 0.0.0.0:624 0.0.0.0:* LISTEN 2986/rpc.statd tcp 0 0 0.0.0.0:56120 0.0.0.0:* LISTEN - (NFS)
*nfsstat* -> Client rpc stats: calls retrans authrefrsh 10662 8543 0
Client nfs v3: null getattr setattr lookup access readlink 0 0% 2492 23% 103 0% 711 6% 5254 49% 0 0% read write create mkdir symlink mknod 0 0% 296 2% 398 3% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 103 0% 0 0% 0 0% 0 0% 3 0% 5 0% fsstat fsinfo pathconf commit 1292 12% 4 0% 0 0% 0 0%
*Serveur NFS:* * * *OS* -> RedHat 2.6.18-164.11.1.el5
*netstat* -> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN - (NFS) tcp 0 0 0.0.0.0:614 0.0.0.0:* LISTEN 3403/rpc.mountd tcp 0 0 0.0.0.0:650 0.0.0.0:* LISTEN 3012/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2976/portmap tcp 0 0 0.0.0.0:57118 0.0.0.0:* LISTEN - (NFS)
*nfsstat* -> Server nfs v3: null getattr setattr lookup access readlink 12 0% 121471 39% 14426 4% 47336 15% 50741 16% 0 0% read write create mkdir symlink mknod 11461 3% 19404 6% 21118 6% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 14423 4% 0 0% 0 0% 0 0% 188 0% 835 0% fsstat fsinfo pathconf commit 5331 1% 18 0% 0 0% 209 0%
L'erreur qui nous est remontée est la suivante: "kernel: nfs: server 192.168.X.X not responding, timed out" Cette erreur ne concerne que le serveur WEB de préproduction
L'analyse que nous avons mené jusqu'à présent nous indique un problème de session (tcpdump effectué au niveau du firewall):
Le client essai bien de contacter le serveur ( tcp syn sur port 2049 ) 192.168.X.X 192.168.X.X TCP 784 > nfs [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=277750420 TSER=0 WS=7 784 nfs
Le paquet arrive bien sur le serveur 192.168.X.X 192.168.X.X TCP 784 > nfs [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=277750420 TSER=0 WS=7 784 nfs
Le serveur envoie sont paquet en retour ( ACK ) afin d'etablir la session tcp 2 0.000007 192.168.X.X 192.168.X.X TCP [TCP ACKed lost segment] nfs > 784 [ACK] Seq=1 Ack=2049758058 Win=501 Len=0 TSV=1624483218 TSER=1589620550 SLE=0
mais ce paquet n'arrive pas au client.
Il faut savoir que ce montage NFS fonctionne la majorité du temps (C'est pourquoi je ne pense pas à un problème de config client) et que ces pertes de connexion concernent uniquement le serveur de Préproduction (c'est pourquoi je ne pense pas a un problème de configuration serveur).
En ce qui concerne la config du FireWall, les serveurs de Prod et Préprod appartiennent au même groupe qui est autorisé à communiquer avec le serveur NFS sur les ports 2049 et 111.
Merci pour vos lumières.
Cordialement,
David
Salut,
Le 1 févr. 2011 à 11:16, David Le Meur a écrit :
Bonjour à tous,
Récemment inscrit à la liste, je sollicite votre aide pour un problème NFS, voici le contexte:
[...]
netstat -> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2950/portmap tcp 0 0 0.0.0.0:624 0.0.0.0:* LISTEN 2986/rpc.statd tcp 0 0 0.0.0.0:56120 0.0.0.0:* LISTEN - (NFS)
[...]
L'erreur qui nous est remontée est la suivante: "kernel: nfs: server 192.168.X.X not responding, timed out" Cette erreur ne concerne que le serveur WEB de préproduction
L'analyse que nous avons mené jusqu'à présent nous indique un problème de session (tcpdump effectué au niveau du firewall):
Moi je vois 2 choses :
- tcp - firewall
Et accessoirement serveur de préproduction...
Je ne sais pas quel type de firewall tu as, mais je pencherais a un firewall qui fait sont garabage collector et qui vire ses connections TCP idle...
Essayes de passer en UDP et voir si ça résous ton pb... Ou mieux fais en sorte qu'il n'y ai pas de firewall (temporairement) entre ton env de préprod et ton serveur NFS...
Xavier
Bonjour,
On 01/02/11 11:21, Xavier Beaudouin wrote:
Je ne sais pas quel type de firewall tu as, mais je pencherais a un firewall qui fait sont garabage collector et qui vire ses connections TCP idle...
+1 pour le firewall.
La table ip_conntrack qui sature (auquel cas, ça devrait être indiqué dans le syslog) ou un réglage iptables qui limite le nombre de connexions (iptables -L -v -n mettra p-e ça en évidence).
Merci pour vos réponse,
Le FireWall que nous utilisons est un boitier Fortinet, ce qui me parait étrange c'est que la config est scrupuleusement identique sur le serveur de prod et que cela fonctionne, au niveau du firewall la config actuellement en place autorise pourtant bien la connexion entre le serveur de prod et le serveur NFS.
Je vais tout de même investiguer dans ce sens, merci encore pour votre aide.
Je vous ferai un retour sur les solutions proposées
David
Le 1 février 2011 11:26, Olivier Le Cam <Olivier.LeCam@crdp.ac-versailles.fr
a écrit :
Bonjour,
On 01/02/11 11:21, Xavier Beaudouin wrote:
Je ne sais pas quel type de firewall tu as, mais je pencherais a un
firewall qui fait sont garabage collector et qui vire ses connections TCP idle...
+1 pour le firewall.
La table ip_conntrack qui sature (auquel cas, ça devrait être indiqué dans le syslog) ou un réglage iptables qui limite le nombre de connexions (iptables -L -v -n mettra p-e ça en évidence).
-- Olivier
Liste de diffusion du FRsAG http://www.frsag.org/
On Tue, Feb 01, 2011 at 11:40:15AM +0100, David Le Meur wrote:
On 01/02/11 11:21, Xavier Beaudouin wrote:
Je ne sais pas quel type de firewall tu as, mais je pencherais a un
firewall qui fait sont garabage collector et qui vire ses connections TCP idle...
+1 pour le firewall.
J'ajouterais également que la preproduction travaille surement moins que la prod avec de grand creux d'activité. Ceci expliquerais le problème sur la preprod et pas la prod. Ceci n'est evidemment pas du vécu ... :D
La table ip_conntrack qui sature (auquel cas, ça devrait être indiqué dans le syslog) ou un réglage iptables qui limite le nombre de connexions (iptables -L -v -n mettra p-e ça en évidence).
-- Olivier
Yann
Merci à tous pour vos réponses,
J'ai actuellement passé les connexions en UDP, un reboot du serveur a été fait. Ce problème étant actuellement solutionné par un reboot, je ne peux vous dire si cette modification à corrigé mon problème. Si le passage en UDP ne corrige pas ce problème, Je testerai alors une connexion sans Firewall. Je vous tiendrai informé de la suite des évènements.
Merci encore
Cordialement,
David
Le 1 février 2011 12:16, Yann Verry yann@verry.org a écrit :
On Tue, Feb 01, 2011 at 11:40:15AM +0100, David Le Meur wrote:
On 01/02/11 11:21, Xavier Beaudouin wrote:
Je ne sais pas quel type de firewall tu as, mais je pencherais a un
firewall qui fait sont garabage collector et qui vire ses connections
TCP
idle...
+1 pour le firewall.
J'ajouterais également que la preproduction travaille surement moins que la prod avec de grand creux d'activité. Ceci expliquerais le problème sur la preprod et pas la prod. Ceci n'est evidemment pas du vécu ... :D
La table ip_conntrack qui sature (auquel cas, ça devrait être indiqué
dans
le syslog) ou un réglage iptables qui limite le nombre de connexions (iptables -L -v -n mettra p-e ça en évidence).
-- Olivier
Yann
Linux, une histoire de vi ou de more --. . . -.- ....- . ...- . .-. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Tue, 2011-02-01 at 11:21 +0100, Xavier Beaudouin wrote:
Essayes de passer en UDP et voir si ça résous ton pb... Ou mieux fais en sorte qu'il n'y ai pas de firewall (temporairement) entre ton env de préprod et ton serveur NFS...
J'aurai également conseillé de passer en udp. Il est en général très compliqué et très chiant de firewaller du NFS ...
Cordialement.
Le 01/02/2011 11:41, Alexandre Legrix a écrit :
J'aurai également conseillé de passer en udp. Il est en général très compliqué et très chiant de firewaller du NFS ...
Pas avec NFSv4, d'ailleurs la version 4 est vivement conseillée pour une utilisation en TCP. Donc v4 TCP ou v3 UDP.