PassagerDuCirque a écrit 15 commentaires

Pourquoi? En fait je ne suis pas développeur, donc je ne connais pas bien ces outils, mais je me demande si ce n'est pas une bonne opportunité de les utiliser. Peut être que la réponse est non, dans ce cas pas de problème, je passe mon chemin.
Ce qui me fait penser que ça a un intérêt, c'est que la liste des modules de phabricator (https://secure.phabricator.com/applications/), par exemple, comprend plein de trucs qui ne sont pas spécifiques au dev et qui m'intéressent.
Alors, est-ce que j'ai un intérêt à utiliser une bonne forge, plutôt qu'un produit plus généraliste comme freedcamp par exemple.

On ne fera pas d'export systématique au format xml ou texte, par contre.

Oui, c'est exactement ce qui s'est passé.

Si, j'ai eu la même idée en lisant ton message. A prendre en compte pour le prochain crash…

ç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.

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).

Je ne peux qu'être d'accord avec ça mais ce n'est pas moi qui détiens les cordons de la bourse.

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.

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

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.

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

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?

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.

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?

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).

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.