système de fichiers en miroir sur quelques serveurs

13

Je cherche une solution pour mettre en miroir ou répliquer un répertoire (ou un système de fichiers) sur quelques serveurs Linux. La solution idéale serait celle qui permet à tous les serveurs d'accéder en lecture-écriture. Je veux également qu'il soit résilient, si l'un des serveurs tombe en panne, le repos devrait toujours fonctionner sans perdre de données.

J'ai cherché des solutions:

DRBD : réplications au niveau bloc, semble un peu exagéré;
lsyncd : semble très simple, mais j'ai des doutes sur les performances;
GlusterFS : semble que ce serait une bonne correspondance, je n'ai pas encore compris comment fonctionne exactement le mode de réplication. Aura-t-il les caractéristiques dont j'ai besoin?

N'importe quelles autres suggestions sont les bienvenues.

— vartec
source

Envisagez-vous une configuration de partage rien ou allez-vous connecter tous les serveurs au même SAN backend?

— HampusLi

logiquement, il ne partageait rien (physiquement, c'est EC2 avec EBS).

— vartec

6

La première question que je poserais est celle-ci: voulez-vous que cela soit répliqué sur deux serveurs ou plus puis sur deux serveurs? Pour deux serveurs j'irais avec DRDB, pour trois ou plus j'irais avec gluster.

Si la latence d'E / S n'est pas une préoccupation critique, j'irais avec gluster. Il est assez facile à installer et pourrait clairement faire ce dont vous aviez besoin. Tout ce que vous avez à faire est de créer un serveur gluster servant les fichiers sur les trois boîtiers, puis de faire en sorte que chaque boîtier agisse comme un client gluster montant les fichiers.

DRDB va être compliqué de travailler en mode maître <-> maître avec 3 serveurs ou plus. Vous devez configurer une configuration basée sur l'anneau et je ne le recommanderais pas. Cependant, pour deux serveurs, DRDB est fantastique. Master <-> Le mode Master n'est pas compliqué à configurer et vous n'avez rien à apprendre sur le système de fichiers.

lsycd est idéal pour une configuration maître / esclave, mais vous ne semblez pas vouloir cela.

Ceph est encore assez nouveau, la dernière fois que j'ai vérifié, il n'avait même pas encore de support fsck. Je préfère baser mon infrastructure sur quelque chose de plus stable.

Lustre est un produit fantastique pour les déploiements à grande échelle, mais vous devez configurer le battement de cœur et le basculement pour le serveur mds ou son va avoir un seul point de défaillance. Étant donné le nombre limité de serveurs dont il parle, je soupçonne sa surpuissance dans ce cas.

— n8whnp
source

Au début, je vais commencer avec seulement 2 serveurs par cluster, mais je veux avoir l'option d'avoir plus de 2 serveurs pour la montée en puissance; La configuration plus brillante que vous décrivez, gérerait-elle l'un des serveurs en panne? serait-il facile d'ajouter un serveur supplémentaire?

— vartec

2

Que diriez-vous de Ceph ou de Lustre ?

— Chopper3
source

Luster prend-il en charge Ubuntu Server? Je vérifie Ceph maintenant, merci pour la suggestion.

— vartec

Extrait du wiki de ceph: "Ceph est en cours de développement intensif et ne convient pas encore à d'autres utilisations que l'analyse comparative et la révision." Ceph.newdream.net/wiki

— Jeff Busby

2

Vous devriez vous pencher sur OpenAFS - c'est un système de fichiers principalement distribué qui permet à plusieurs copies de données d'exister réparties sur le cluster et tout le monde peut lire / écrire sur le FS en même temps.

Il possède également un tas d'autres fonctionnalités utiles (bonne authentification, cryptage sur le câble, mise en cache locale intégrée sur les clients, client Windows natif, portable sur de nombreuses versions d'Unix, etc.)

C'est un peu lourd à installer, cependant.

— chris
source

même question qu'avec NFS: "autorise plusieurs copies". D'accord, mais est-ce qu'il s'occupe réellement de synchroniser ces copies?

— vartec

Oui. Et il est possible, bien que gênant, de récupérer de la perte du maître principal. Mais il est trivial d'avoir plusieurs écrivains et les blocs résultants stockés sur plusieurs hôtes.

— chris

La clé pour comprendre OpenAFS est qu'il s'agit d'un système de gestion du cache - il y a un espace de noms (IE, un seul "fichier" existe) mais il y a des copies en cache du fichier partout et un protocole pour s'assurer que toutes les copies en cache sont cohérentes . Si vous perdez le maître, vous pouvez transformer l'une des copies en cache en maître, mais ce n'est pas l'idéal d'être dans cette situation.

— chris

1

NFS peut également fonctionner correctement, selon vos besoins.

— LSD
source

AFAIK, NFS ne fournit pas de moyen de monter des serveurs répliqués, mais pas la réplication elle-même. Mais je n'utilise pas NFS depuis longtemps, alors peut-être que cela a changé. Pourriez-vous créer un lien vers des documents NFS décrivant une telle configuration?

— vartec

Un moyen au-dessus de ma tête serait de répliquer les répertoires sur plusieurs serveurs nfs, dont l'un a un vip principal, et de migrer le vip sur les serveurs si l'un tombe en panne. Ou round robin dns peut-être. NFS lui-même peut ne pas faire tout ce dont vous avez besoin, mais en conjonction avec les services de cluster Heartbeat ou Red Hat, c'est peut-être ce dont vous avez besoin. Je ne suis pas sûr que la question d'origine contenait toutes les exigences. Vous pouvez même effectuer une rsync sur un tas de serveurs, disons toutes les heures environ, pour une solution vraiment rapide et facile.

— lsd

Ignorez la partie sur rsync. Il ferait la réplication, mais c'est principalement pour les configurations en lecture seule, ce qui ne correspond pas à vos besoins. Je voulais modifier mon commentaire ci-dessus, mais cela ne me laisserait pas.

— lsd

1

Faire en sorte que cela fonctionne avec DRBD va être vraiment difficile - le problème n'est pas que n8whnp semble penser un problème concernant la réplication multidirectionnelle (vous faites simplement toutes les bandes de nœuds dans un jeu de miroirs), mais c'est un contrôle de concurrence - vous '' d besoin d'exécuter un système de fichiers de cluster au-dessus de la mise en miroir au-dessus de DRBD.

lsyncd est encore pire car il n'y a pas de solution pratique pour le contrôle de la concurrence.

Je recommanderais une solution de type AFS (AFS, OpenAFS) comme solution ouverte, stable et mature. Je resterais à l'écart du lustre depuis qu'Oracle l'a fermé. Je ne connais pas trop les glusterfs, mais comme il repose sur un stockage distribué plutôt que répliqué, je vous recommande de regarder attentivement son comportement en mode split-brain (AFS OTOH est conçu pour fonctionner en mode déconnecté).

— symcbean
source