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


11

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.

Requis dur chaged de Linux et gratuit à un plus.
dpb

Réponses:


5

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


Chris, merci pour la réponse. Je pense que DFS est à peu près ce que je recherche, bien que sous Windows. Certainement quelque chose à étudier.
dpb

DFS ne fonctionne pas au niveau du bloc. Le service de réplication n'est pas transactionnel sur la base de fichiers.
vérifie

4

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.


Merci pour la réponse Evan, j'ai mis à jour ma question avec les données que vous demandiez. Je suis intéressé par votre idée unison / rsync, mais je ne vois pas très bien comment l'aspect dynamique serait géré. (Je n'ai pas beaucoup d'expérience avec Unison, seulement rsync).
dpb

@dpb: Je n'obtenais pas le sens de cette exigence dans votre édition d'origine. Microsoft DFS-R ne le fera pas non plus. Le comportement de récupération à la demande va exiger quelque chose d '"actif" dans le système de fichiers pour intercepter les demandes de lecture pour les talons de fichiers qui n'ont pas leurs données locales mises en cache, aller chercher les données et effectuer la lecture. Je ne connais aucun système de fichiers géographiquement distribué avec ce comportement - qui ressemble plus à un HSM.
Evan Anderson

Pour ceux qui n'ont aucune idée de moi: en.wikipedia.org/wiki/Hierarchical_storage_management . Merci encore @Evan. Je ne suis pas aussi intéressé à réorganiser l'emplacement de stockage sous-jacent de manière dynamique que de le choisir initialement de manière dynamique. Je pense que HSM semble très cool, mais la partie cool est assez exagérée pour ce que je fais.
dpb

3

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.


1
Consultez également CodaFS: en.wikipedia.org/wiki/Coda_%28file_system%29
blank3

1

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.


Merci @James, c'est presque exactement ce que je recherche. Je ne suis pas intéressé par l'espace de noms munged au niveau supérieur (attribuer des répertoires particuliers à un pool OST), mais peut-être que ce serait OK. Il est au moins bon de savoir quel est le cas d'utilisation et la limitation de Lustre. Merci encore!
dpb

1

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.


Merci @Kyle, je ne connaissais pas UnionFS, avec la mise en cache agressive, NFS pourrait être une bonne solution pour cela. Je pense que cela pourrait devenir plus difficile à entretenir à mesure que le nombre de sites augmente, mais je vais y réfléchir avant de décider.
dpb

0

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.

Idée intéressante, mais je ne pense pas que cela donnerait à mon application quoi que ce soit par rapport à d'autres systèmes de fichiers distribués. (lustre, glusterfs, etc.). Merci d'avoir posté ...
dpb

0

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


0

Vérifiez sur chironfs .

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


0

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)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.