Forum général.cherche-logiciel Réplication de fichiers entre sites

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
1
juil.
2014

Bonjour,

Lecteur de linuxfr depuis plus de 10 ans, je me décide enfin à créer un compte en espérant avoir des pistes pour des soucis rencontrés dans mon entreprise.
En gros, on est dans une architecture tout microsoft, ce que je n'ai pas eu le pouvoir de changer jusque là. Mais là je pourrais peut être glisser un pied dans la porte, car il y a des dysfonctionnements importants.
L'entreprise a 3 sites avec des gros besoin de partage de fichiers (bureautique, plans, simulations 3D) par projet. Sur chaque projet, il est possible que des personnes de plusieurs sites soient impliquées, et elles doivent pouvoir accéder aux fichiers (en lecture et écriture) de façon rapide.
Jusqu'ici nous utilisions la réplication Microsoft DFS: pour chaque projet, le dossier correspondant était mis en réplication sur les serveurs des sites concernés, c'est à dire que tout fichier enregistré sur le serveur d'un site, est immédiatement copié vers les serveurs des autres sites. Suite à différents problèmes (peut être lié au volume de données: environ 500 Go dans des centaines de milliers de fichiers), ça merde grave et on voudrait remplacer ce système. La question: par quoi?
On nous propose de passer dans un environnement virtualisé (Citrix ou VMware), ce qui centraliserait le stockage des fichiers.
Qu'est ce que le monde du libre pourrait proposer comme solution? Notamment en restant dans le principe de la réplication de fichiers entre sites?

  • # a voir

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

    La taille des tuyaux vs le delta de volume de données à transferer

    En gros tu cherches un système de fichier distribué mono / multi master.

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

    • [^] # Re: a voir

      Posté par  . Évalué à 1.

      La taille des tuyaux est certes limitante (connexions ADSL). Mais au quotidien ça fonctionnait jusqu'ici, c'est la reprise après un crash qui pose problème (voir plus bas)
      Au niveau du delta à transférer c'est difficile à dire car le système actuel ne permet pas de monitorer les volumes transférés.
      Le site principal comprend 25 utilisateurs environ, les sites secondaires 10 et 5 utilisateurs. Certains travaillent sur de la bureautique avec des fichiers pas trop gros, mais d'autres sur des infographies et d'autres sur des calculs numériques (ces derniers stockent des fichiers binaires de plusieurs centaines de mégas et peuvent les modifier plusieurs fois dans la journée).

      • [^] # Re: a voir

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

        Il faudrait avoir une idée si la bande passante est à 100%, donc le goulet d'étranglement.

        Entre un transfert de fichier complet et la différence ( delta:seule les parties modifiées ) ça joue énormement sur la quantité de données à transférer.

        A prendre en compte la fréquence et taille des fichiers en question / temps de synchronisation.

        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

        • [^] # Re: a voir

          Posté par  . Évalué à 1.

          Oui… ça fait un moment que j'aimerais avoir des réponses à ces questions, mais pas trouvé de moyen de les obtenir.

        • [^] # Re: a voir

          Posté par  . Évalué à 3.

          Il faudrait avoir une idée si la bande passante est à 100%, donc le goulet d'étranglement.

          Je ne sais pas si DFS fait du delta de fichier mais pour appuyer le propos, j'ai entendu le cas de réplication d'image vmware avec rsync qui passait plus de temps à calculer le diff que le transfert de fichier complet aurait nécessité.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: a voir

      Posté par  . Évalué à 1.

      Aussi d'après ce que je sais des systèmes de fichiers distribués, leur objectif est légèrement différent puisqu'ils permettent de créer un espace de stockage sur plusieurs serveurs. La réplication est une des fonctionnalités proposées, soit de façon synchrone (impossible si les transferts entre serveurs ne sont pas très rapides) soit de façon asynchrone mais dans ce cas le serveur distant ne propose pas d'accès en modification aux utilisateurs (le serveur distant propose juste de la redondance). Le côté asynchrone et multimaster est plus compliqué car il faut gérer les potentiels conflits entre fichiers, non?

      • [^] # Re: a voir

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

        oui, mais c'est géré.

        Je ne sais pas si un admin passe dans le coin, mais mettre un serveur linux sur chaque site, chaque serveur est utilisé au travers d'un partage réseau. Les serveur Linux sont reliés par un système de fichiers distribué, il faut encore trouver le bon. Le mieux est d'en prendre un orienté résistance au panne et non performance.

        Sinon, pour des fichiers pas trop gros, git, c'est bien.

        "La première sécurité est la liberté"

        • [^] # Re: a voir

          Posté par  . Évalué à 1.

          +1 pour GIT

          Ma vie :

          comme il est dans un environnement hostile :), SVN avec tortoiseSVN c'est plutot pas trop mal, la courbe d'apprentissage est assez rapide, pour les gens.

          adopté dans mon entreprise, le serveur est hebergé avec une grosse connections avec tous les clients en adsl. C'est assez resistant au coupure de transfert.

          Dès qu'un client GIT pour windows secretaire proof arrive, je passe a git.

          • [^] # Re: a voir

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

            TortoiseGit ?

            Il faudrait surtout un client avec un processus codé dedans. J'ai toujours autant de mal avec les fonctions un peu avancé des gestionnaires de version. Alors une secrétaire….

            "La première sécurité est la liberté"

            • [^] # Re: a voir

              Posté par  . Évalué à 1.

              TortoiseGit est utilisable, mais ça s'arrête là.
              De manière générale, mes expérience de git sous windows n'ont pas été satisfaisantes (problèmes d'encodage et de fins de lignes, notamment).

              Mais bon, il n'y à pas que git (même si c'est aussi celui que j'utilise) en VCS décentralisé: il y à aussi mercurial, bazaar (bien que ce dernier ne soit plus maintenu de mémoire), fossil…

              Par contre, je suis d'accord pour le fait qu'un VCS décentralisé pourrait être une solution, encore qu'il faudra dans ce cas former les utilisateurs à pousser leurs modif, et à tirer avant de commencer à bosser sur un projet, hors le facteur humain n'est jamais négligeable.

  • # regarde les solutions citées

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

    dans
    http://linuxfr.org/forums/linux-redhat/posts/replication-wiki-dokuwiki

    Et comme dit précédemment, cela dépendra surtout du débit de tes tuyaux et de la quantité de données à propager.

    ウィズコロナ

    • [^] # Re: regarde les solutions citées

      Posté par  . Évalué à 5.

      Et pour agrandir la liste: GlusterFS. Il me semble que c'est le genre de problématique qu'il est censé résoudre.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Ça merde grave, mais où ?

    Posté par  . Évalué à 10.

    Il te faut d'abord déterminer d'oû vient de le problème. Sinon ta solution de remplacement ne fera peut-être pas mieux.

    D'expérience, DFS fonctionne très bien, y compris sur de gros volumes de données et de nombreux fichiers. Donc si ça coince avec DFS, ça coincera probablement avec autre chose.
    Une fois que tu auras déterminé d'où vient le problème (c'est souvent très difficile), peut-être que DFS sera ok, peut-être qu'une autre solution sera meilleure. Mais sans cela, inutile de t'embarquer dans un changement. Ça te sera reproché si ça ne fonctionne pas mieux.

    • [^] # Re: Ça merde grave, mais où ?

      Posté par  . Évalué à 2.

      En fait au quotidien ça marche pas trop mal (un des reproches que j'aurais à faire tout de même est que c'est très difficile à auditer: impossible de connaître les volumes de données transférés par jour, etc…)
      Mais là, suite à un crash du serveur principal (volume contenant les données détruit et refait à partir d'un backup), ça a été la catastrophe pour reprendre la réplication sur la base des fichiers existants. Il a fallu plusieurs semaines pour revenir à un état fonctionnel. Je ne suis pas suffisamment technique pour donner plus d'explication, et les personnes en charge du support n'ont pas d'explication non plus. En tout cas ils ont dû faire intervenir le support de Microsoft à plusieurs reprises pour corriger des problèmes très pointus…

      Donc ça donne envie de changer, mais en effet, il faut être sûr que le remplaçant marche mieux. C'est pour ça que je cherche à élargir mes sources d'informations en venant ici, pour avoir des pistes à explorer.

      • [^] # Re: Ça merde grave, mais où ?

        Posté par  . Évalué à 1.

        mettre une passerelle/proxy linux entre le serveur et les clients pour avoir des jolies stat sur le reseau

        avec iftop, etc …

  • # FRS ou DFRS

    Posté par  . Évalué à 1.

    Quelle version de DFS utilises-tu ? FRS ou DFRS

    Si ta racine DFS a été créée sous Windows Server 2000/2003, il est possible qu'elle utilise toujours le protocole FRS. Dans ce cas le passage en DFSR devrait améliorer la situation.
    DFSR est disponible à partir de Windows Server 2003 R2.

    • [^] # Re: FRS ou DFRS

      Posté par  . Évalué à 1.

      Je ne sais pas (je précise que ce n'est pas moi qui suis en charge de la maintenance de l'infra, on a un prestataire pour ça). Où peut on voir ça?

      • [^] # Re: FRS ou DFRS

        Posté par  . Évalué à 2.

        Tu vas à la racine DFS et tu tapes dans une console dir /h
        si il y a un répertoire DfsrPrivate c'est que tu utilises DFSR

        • [^] # Re: FRS ou DFRS

          Posté par  . Évalué à 1.

          Ah OK, alors pas besoin d'aller vérifier, je connais bien ces répertoires DfsrPrivate donc je suis en DFSR
          Merci

  • # j'ai du mal à comprendre...

    Posté par  . Évalué à 2.

    …c'est à dire que tout fichier enregistré sur le serveur d'un site, est immédiatement copié vers les serveurs des autres sites.

    donc ca fonctionne fichier par fichier

    Suite à différents problèmes (peut être lié au volume de données: environ 500 Go dans des centaines de milliers de fichiers),

    sauf si tu modifies des milliers de fichier à chaque usage, ca ne devrait pas poser de souci

    ils sont si gros que ca les fichiers ?
    tu synchronises avec quel type de connexion entre les sites ?

    • [^] # Re: j'ai du mal à comprendre...

      Posté par  . Évalué à 1.

      La synchro se fait via des connexions ADSL.

      Dans un site il y a 25 utilisateurs, dans un autre 10 et dans un autre 5. Donc il peut y avoir plusieurs fichiers modifiés en peu de temps, y compris des fichiers de plusieurs centaines de mégas (voir un autre commentaire plus haut).
      Mais ce qui pose problème c'est surtout la reprise après un crash (voir plus haut aussi), qui ne donne pas confiance dans la résilience du système en cas d'incident futur.

      • [^] # Re: j'ai du mal à comprendre...

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

        quel débit les tuyaux ? taille de fichier ?

        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

        • [^] # Re: j'ai du mal à comprendre...

          Posté par  . Évalué à 1.

          Il y a une majorité de fichiers de quelques mégas mais aussi des fichiers de plusieurs centaines de mégas modifiés tous les jours.
          Le débit est limitant surtout sur les sites distants avec des débits ADSL classiques du type que tout le monde a à la maison, genre 30M/3M mais ça c'est une valeur théorique, vu que c'est de l'ADSL. Après pour le débit réel que j'atteins entre mes sites, je n'ai pas de valeur.

          • [^] # Re: j'ai du mal à comprendre...

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 02 juillet 2014 à 13:11.

            Faudrait faire un test avec iperf par exemple.

            Monitorer l'usage de la bp avec cacti par exemple.

            C'est certain, une bande passante de 300ko/s pour transferer des fichiers de centaines de Mo, tu peux avoir des problèmes de convergence et avec un débit non symétrique.

            Il y a un gros soucis d'architecture.

            Où sont les données physiquement / tuyaux non symétriques, débit trop faible.

            Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

          • [^] # Re: j'ai du mal à comprendre...

            Posté par  . Évalué à 3.

            tout est dit :
            ADSL et fichiers de plusieurs MEGAs

            ton ADSL est par definition Assymétrique.
            ton debit montant (du bureau vers l'exterieur) , en France, est donné pour 1024Kbps = 128Ko/s

            un fichier de 1Mo mettra donc 8 sec pour etre envoyé, en utilisant toute la bande passante dispo, en suppossant que le serveur soit tout seul sur la ligne, et que le protocole soit bien fait.

            je te laisse faire les calculs pour des fichiers de plusieurs Mo x plusieurs utilisateurs…

          • [^] # Re: j'ai du mal à comprendre...

            Posté par  . Évalué à 3.

            Tu peux demander à transformer tes lignes ADSL en SDSL pour avoir un débit symétrique.

            • [^] # Re: j'ai du mal à comprendre...

              Posté par  . Évalué à 1.

              Oui, on se doute bien depuis longtemps que les débits sont un peu justes… mais jusqu'au crash serveur, le débit était suffisant. C'est vraiment en situation de reprise après catastrophe qu'on est coincés (et encore, pas spécialement pour transférer des fichiers, mais juste pour que le système analyse les fichiers de tous les côtés et se rende compte qu'il est synchro).
              Mais le tarif des connexions symétriques à débit garanti a plusieurs fois causé le refus de ma hiérarchie. ça se fera uniquement si c'est démontré que c'est absolument indispensable.

              • [^] # Re: j'ai du mal à comprendre...

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

                l'adsl ça fonctionne bien car sur le web on consomme plus de données que l'on en envoie, donc dés qu'on fait du partage de fichiers en lecture écriture, c'est pas la bonne technique, le sdsl est fait pour interconnectés plusieurs sites…

                Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

              • [^] # Re: j'ai du mal à comprendre...

                Posté par  . Évalué à 2.

                mais jusqu'au crash serveur […] C'est vraiment en situation de reprise après catastrophe qu'on est coincés

                bah, avec n'importe quelle solution en cas de crash, il y aura des verifications sur la machine en elle meme,
                puis entre les machines.

                le debit peut alors avoir son importance pour l'echange d'information entre les sites

              • [^] # Re: j'ai du mal à comprendre...

                Posté par  . Évalué à 4.

                En cas de crash, ce ne serait pas plus simple de repartir sur une synchronisation complète avec une machine maître et des clients sans données au départ. En plus si cette dernière est sur une ligne qui un bon upload, ça peut se faire assez vite.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: j'ai du mal à comprendre...

                  Posté par  . Évalué à 1.

                  Rétrospectivement, peut-être. Mais le problème est qu'il faut que les gens des sites distants puissent accéder aux données (au moins en lecture seule) pendant la phase de transfert (et 500 Go au débit qu'on a, ça peut prendre un moment).

                  • [^] # Re: j'ai du mal à comprendre...

                    Posté par  . Évalué à 3.

                    Sinon, ce n'est pas imaginable de déplacer toutes les machines (au même endroit pour faire la synchro après crash) ?

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: j'ai du mal à comprendre...

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

                Oui, on se doute bien depuis longtemps que les débits sont un peu justes… mais jusqu'au crash serveur, le débit était suffisant. C'est vraiment en situation de reprise après catastrophe qu'on est coincés

                Je ne connais pas les technos évoquées, donc mes propos sont à prendre avec des pincettes.
                Mais intuitivement, je dirais qu'avant le crash, le système n'avait à échanger des informations que sur les quelques fichiers ayant été modifiés récemment (et lesdits fichiers, bien sûr !).
                Après le crash, peut-être que le système tente un check sur l'ensemble des fichiers. Et dans ce cas, la bande passante est clairement insuffisante, et le tout mettra des semaines à reprendre un comportement acceptable, s'il y arrive…

  • # Bon courage

    Posté par  . Évalué à 3. 

    En gros, on est dans une architecture tout microsoft

    Si ils sont en tout Microsoft, la transition sera longue, pénible et non valorisante. Pire, les répercussions financières ne seront pas visible à court terme. Le seul point positif sera l'expertise que tu aura acquise, a la fois sur Microsoft et sur Linux.

    Si il y a une réelle volonté de tout changer dans cette boite, et que tu as couvert tes arrières, fonce.

    Sinon, change de boite, maintenant.

    • [^] # Re: Bon courage

      Posté par  . Évalué à 2.

      ça c'est le genre de réponse que je craignais même si je sais que dans le fond c'est vrai (pour la première partie).
      Pour la seconde partie, en fait moi je fais pas de technique, on a une boîte d'infogérance pour faire ça. Je suis la personne "qui s'y connaît" dans l'entreprise. Mon rôle est de "gérer" le sous-traitant et d'éclairer ma direction sur les choix à faire (la boîte externe nous conseille, mais exceptionnellement je suis venu parler de mes problèmes ici pour essayer d'élargir l'horizon). Ça ne m'occupe pas 100% du temps, j'ai du vrai travail intéressant à côté, donc non, je vais pas partir ;) même s'il n'y a pas de volonté de sortir du tout Microsoft si pas de retour rapide.

Suivre le flux des commentaires

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