Système de fichiers géographiquement distribué avec localité préférée

Je crée une application qui doit distribuer un serveur de fichiers standard sur quelques sites via un WAN. Fondamentalement, chaque site doit écrire un grand nombre de fichiers divers de taille variable (certains dans la plage de 100 Mo, mais la plupart sont petits), et l'application est écrite de sorte que les collisions ne soient pas un problème. J'aimerais avoir un système qui réponde aux qualifications suivantes:

1. Chaque site peut stocker des fichiers dans un "espace de noms" partagé. Autrement dit, tous les fichiers s'affichent dans le même système de fichiers.
2. Chaque site n'enverrait pas de données sur le WAN à moins que cela ne soit nécessaire. C'est-à-dire qu'il y aurait un stockage local de chaque côté du WAN qui serait "fusionné" dans le même système de fichiers logique.
3. Linux et gratuit ($$$) est un plus

Fondamentalement, quelque chose comme un partage NFS central répondrait à la plupart des exigences, mais il ne permettrait pas aux données écrites localement de rester locales. Toutes les données des côtés distants du WAN seraient copiées localement tout le temps.

J'ai examiné Luster et j'ai effectué avec succès des tests avec lui, mais il semble distribuer les fichiers de manière assez uniforme sur le stockage distribué. J'ai fouillé dans la documentation et je n'ai rien trouvé qui "préfère" automatiquement le stockage local au stockage distant. Même quelque chose qui allait avec le stockage à latence la plus faible serait bien. Cela fonctionnerait la plupart du temps, ce qui répondrait aux exigences de cette application.

Quelques réponses à quelques questions posées ci-dessous:

• Nœuds de serveur: 2 ou 3 pour démarrer. Chaque serveur aurait des dizaines de clients de lecture / écriture simultanés se connectant.
• La topologie WAN est entièrement maillée et fiable. (grande entreprise, le coût n'est pas aussi limitatif que les formalités administratives)
• Basculement client: en fait, je n'avais pas pensé à faire basculer les clients (principalement parce que notre application actuelle ne le fait pas sur un seul site). Je supposais que la réponse pratique était que les serveurs de chaque site géographiquement distribué devraient être des points de défaillance uniques pour les clients qu'ils desservent. Cependant, si vous pensez à quelque chose de spécifique ici, je pense que ce serait tout à fait pertinent pour la discussion.
• Roll-my-own: J'ai pensé à rsync / unison, mais j'aurais besoin d'un peu de logique pour faire en sorte que la partie "dynamique" de ce travail fonctionne de manière transparente. C'est-à-dire que le fichier semble être local, mais n'est récupéré que sur demande.
• MS-DFS: Cela semble certainement être quelque chose que je devrais examiner. Mon principal problème serait potentiellement incertain quant à la configuration / fiabilité / performance du serveur NFS sous Windows, car de nombreux clients se connectant sont des clients NFS.

Honte à l'exigence Linux. C'est exactement ce que fait Windows DFS. Depuis 2003 R2, il le fait également au niveau du bloc.

Quelques questions:

• Combien de nœuds "serveurs" pensez-vous avoir à participer à ce truc?

• Quelle est la topologie de la connectivité WAN? Hub and Spoke, Full Mesh? Est-il fiable?

• Vous attendez-vous à ce que les clients basculent vers un serveur géographiquement non local en cas de défaillance du serveur local?

Windows DFS-R ferait certainement ce que vous recherchez, mais pour certains coûts de licence potentiellement élevés.

Vous dites que les collisions ne sont pas un problème et que vous n'avez pas besoin d'un gestionnaire de verrouillage distribué, vous pouvez donc le faire avec des outils utilisateur tels que rsync ou Unison et simplement exporter le corpus de fichiers résultant avec NFS vers les clients locaux. C'est moche, et il faudrait gérer l'assemblage d'une sorte de système pour gérer la génération d'une topologie de réplication et réellement exécuter les outils de l'espace utilisateur, mais ce serait certainement bon marché en raison du coût des licences.

Avez-vous pensé à AFS ?

Le système de fichiers Andrew (AFS) est un système de fichiers en réseau distribué qui utilise un ensemble de serveurs approuvés pour présenter un espace de nom de fichier homogène et transparent à l'emplacement à tous les postes de travail clients.

Si je comprends bien, la plupart des développements récents sont à l'origine du projet OpenAFS .

Je ne peux pas prétendre être suffisamment familier avec le projet pour savoir si la fonctionnalité "localité préférée" est disponible, mais sinon cela semble être un bon ajustement.

Avez-vous regardé les piscines OST à Luster?

Ce ne sera pas automatique, mais avec les pools OST, vous pouvez attribuer des répertoires / fichiers à des OST / OSS spécifiques - essentiellement une allocation de stockage basée sur des règles, plutôt que le round-robin / striping par défaut entre les OST.

Vous pouvez donc configurer un répertoire par site et attribuer ce répertoire aux OST locaux pour ce site, ce qui dirigera toutes les E / S vers les OST locaux. Ce sera toujours un espace de noms global.

Il y a beaucoup de travail à faire pour améliorer le Lustre sur les connexions WAN (serveurs de mise en cache locaux et autres choses du genre), mais tout est toujours en cours de développement intensif AFAIK.

Peut-être que NFS mais avec Cachefs sur les serveurs d'applications accomplira votre part de votre objectif. Si je comprends bien, tout ce qui est écrit ira toujours au serveur central, mais au moins les lectures pourraient finir par être mises en cache localement. Cela pourrait potentiellement prendre beaucoup de retard sur les lectures en fonction de vos modèles d'utilisation.

En outre, mabye UnionFS mérite d'être étudié. Avec cela, je pense que chaque emplacement serait une exportation NFS, puis vous pourriez utiliser UnionFS à chaque emplacement pour que tous les autres montages NFS de l'emplacement apparaissent comme un seul système de fichiers. Je n'ai pas d'expérience avec cela cependant.

Vous pouvez regarder dans DRBD pour répliquer les disques. http://www.drbd.org/ . Il s'agit d'une solution Linux haute disponibilité qui vient de faire son entrée dans le noyau.

Cependant, cela a certaines limites:

1. Seuls deux nœuds peuvent être configurés
2. Le WAN peut être trop peu fiable pour que DRBD reste robuste.

Si vous voulez rester simple, jetez un œil à rsync, résout beaucoup de problèmes et pouvez être scripté.

Vérifiez sur chironfs .

Peut-être qu'il peut faire ce que vous voulez, sur la base du système de fichiers.

Btsync est une autre solution avec laquelle j'ai une bonne expérience. Il utilise le protocole BitTorrent pour transférer les fichiers, donc plus vous avez de serveurs, plus la synchronisation des nouveaux fichiers est rapide.

Contrairement à la solution basée sur rsync, il détecte lorsque vous renommez les fichiers / dossiers et les renomme sur tous les nœuds au lieu de supprimer / copier.

Vos clients btsync peuvent ensuite partager les dossiers sur un réseau local.

Le seul inconvénient que j'ai trouvé (par rapport à MS DFS) est qu'il ne détectera pas de copie de fichier local. Au lieu de cela, il l'interprétera comme un nouveau fichier et téléchargé vers tous les pairs.

Jusqu'à présent, btsync semble être la meilleure solution de synchronisation et il peut être installé sur les appareils Windows, Linux, Android et ARM (par exemple NAS)