Forum Linux.général problème de dialogue entre 2 clients d'un même server NFS

Posté par  .
Étiquettes : aucune
-1
17
mar.
2012

Bonjour;
Je poste cette question au cas où un expert NFS connaitrait ce problème.
J'ai le schéma suivant (non modifiable, postulat):
Un 1er client NFS C1 écrit un fichier sur un server NFS S.
Un 2eme client NFS du même server S1 va "consommer" ce fichier pour le traiter...
C1, C2 & S sont des machines linux qui toutes implémenent NFS V3 uniquement (nfs V2 et V4 ont été déactivés).
Le problème est le suivant: parfois C2 "ne voie pas" que C1 a posté un fichier.
Ou, il le voie avec 30 ou 60 secondes de retard (sur un lan à 1Gb)
Ou, si C2 a vu le fichier et le détruit (notion de synchro..), C1 ne voit pas la disparition demandée par C2.
Bref, ce processus, même s'il fonctionne "un peu", a énormément de lacunes. 1 fois sur 100, il sera en défaut.
J'ai changé beaucoup de paramètres (mode de transport en tcp, flags de cache actimo en tout genre, flag sync…. etc..), j'ai toujours des échecs ou des retards…

Est-ce qu'un expert pourrait m'expliquer ce qui se passe dans ce mode rarissime et bien sûr, sur quels paramètres agir pour avoir 100% de réussite.

En vous remerciant pour vos avis ou expériences éclairés

  • # Pas une parole d'expert, mais néanmoins une parole!

    Posté par  (site web personnel) . Évalué à 2.

    Dans la RFC de NTFS-3 j'ai trouvé ça:

    4.7 Synchronous modifying operations

   Data-modifying operations in the NFS version 3 protocol are
   synchronous. When a procedure returns to the client, the
   client can assume that the operation has completed and any
   data associated with the request is now on stable storage.

    Du coup j'ai une question: comment es-tu sûr que C2 cherche le fichier après que C1 l'ait posté, c'est-à-dire après que close soit terminé?

    • [^] # Re: Pas une parole d'expert, mais néanmoins une parole!

      Posté par  . Évalué à 0.

      Je reproduit l'erreur par un script en bash.
      En fait l'écriture par C1 d'un fichier, c'est un touch!
      Et une fois sur 10, le mécanisme échoue, dans mon script ou la vraie vie.
      Donc, il est fermé. On ne peut pas mettre en cause les hypothéses.
      J'ai tourné le pb dans tous les sens; le fichier est fermé et bien fermé!
      Tous les caches sont à 000 et c'est nok!
      La seule question, dans ce shéma C1 --> S --> C2 --> S --> C1
      c'est: qu'est-ce qui n'a pas marché?

      • [^] # Re: Pas une parole d'expert, mais néanmoins une parole!

        Posté par  (site web personnel) . Évalué à 3.

        En fait l'écriture par C1 d'un fichier, c'est un touch!

        Bon très bien, mais dans ce cas la question devient «comment es-tu sûr que C2 essaie de trouver ton fichier après que touch soit terminé?» Apparemment tu as deux machines, donc deux scripts bash, c'est ça?

        • [^] # Re: Pas une parole d'expert, mais néanmoins une parole!

          Posté par  . Évalué à 0.

          Non!
          D'abord, c'est pas "Apparemment tu as deux machines"!
          J'ai 3 machines, et c'est bien là la spècificité du problème.
          J'ai 2 clients, et un server.
          Et j'ai 1 seul script qui fait:
          C1> touch /S1_SHARE/F1
          C1> tempo paramètrable
          C1> ssh C2 ls /S1_SHARE/F1 > /tmp/res
          Et ensuite, soit je teste le $? du ssh , soit le contenu du /tmp/res par un grep, etc
          Il y a un grand nombre de façons de le faire!
          Et je compte le nombre de défauts, et je recommence en effaçant F1 par exemple depuis C1, mais il y a un grand nombre de cas où le pb apparait de manière incontestable.

          Mais, y a pire!
          Si je suis loggué sur C1
          et j'ouvre une 2eme Konsole sur C2 (via ssh ou telnet peu importe)

          depuis C1> je fais touch /S1SHARE/F1
          _Bon, là il est créé, c'est sûr!
          Et, depuis la console que je viens d'ouvrir sur C2
          C2> ls /S1_SHARE/F1
          1 fois sur 10 (ou plus ou moins, en général, quand ça commence à merder, c'est mort..)
          et bien, là depuis C2 je ne vois pas /S1_SHARE/F1

          • [^] # Re: Pas une parole d'expert, mais néanmoins une parole!

            Posté par  . Évalué à 1.

            Et si tu coupais le problème en deux, en regardant sur le serveur, histoire de voir si c'est la lecture ou l'écriture qui est mise en tampon ?

            • [^] # Re: Pas une parole d'expert, mais néanmoins une parole!

              Posté par  . Évalué à 0.

              C'est un essai qui a été fait; le fichier est bien présent sur le server.
              Et c'est logique car la 1ere étape est classique: C1 écrit sur S, ça , ça marche. C'est le modèle classique NFS client server.
              C'est après que ça se gâte. Comment est-que C2 est notifié du changement? Pourquoi le serait-t-il systématiquement.
              Ceci en plus est corroboré par le 2eme cas que je cite dans le post initial.
              Quand enfin C2 a réussi à voir le fichier, il fait un traitement très rapide, et détruit ce même fichier. Ce rm se passe bien entre C2 et S. Mais, C1 cette fois ne voit pas le fichier disparaitre et tout part en vrac.
              C'est la même situation que celle du début, mais inversée, et on a la même punition.

  • # Use of NFS considered harmful

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 17 mars 2012 à 12:11.

    Voilà une piste intéressante 

    e. Delayed Write Caching
In an effort to improve efficiency, many NFS clients cache writes. This means that they delay sending small writes to the server, with the idea that if the client makes another small write in a short amount of time, the client need only send a single message to the server.

Unix servers typically cache disk writes to local disks the same way. The difference is that Unix servers also keep track of the state of the file in the cache memory versus the state on disk, so programs are all presented with a single view of the file.

In NFS caching, all applications on a single client will typically see the same file contents. However, applications accessing the file from different clients will not see the same file for several seconds.

Workaround: It is often possible to disable client write caching. Unfortunately, this frequently causes unacceptably slow performance, depending on the application. (Applications that perform I/O of large chunks of data should be unaffected, but applications that perform lots of small I/O operations will be severely punished.) If locking is employed, applications can explicitly cooperate and flush files from the local cache to the server, but see the previous sections on locking when employing this solution.

    Source: http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html

    En résumé tu résoudrais ton problème en désactivant le disable client write caching au prix de performances intolérables. Je pense que la morale de l'histoire est qu'il ne faut pas utiliser NFS pour synchroniser des processus, mais une traditionnelle IPC (dans ton cas seules les sockets peuvent être considérées, j'opterai pour un seimple envoi de messages en UDP).

    • [^] # Re: Use of NFS considered harmful

      Posté par  (site web personnel) . Évalué à 2.

      Je pense que la première chose à faire serait d'examiner au niveau réseau ce qui se passe, histoire de vérifier si c'est bien le client C1 qui fait du write caching ou bien s'il envoi les données immédiatement et que quelque chose d'autre introduit le délai.

      Un espèce de howto qui donne une idée de comment débugguer des problèmes de NFS : http://bl0rg.krunch.be/nfs-perfs.html

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Use of NFS considered harmful

      Posté par  . Évalué à 0.

      Tous les caches sont déja à 0, ACTIMO aussi, au prix de perf's lamentables.
      Il ne s'agit pas de trouver une autre solution, il s'agit de réparer ou du moins de comprendre ce qui cloche dans celle-là!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.