Synchronisation bidirectionnelle en temps réel d'une grande arborescence de fichiers entre deux serveurs Linux distants


21

Par grande arborescence de fichiers, je veux dire environ 200k fichiers, et en croissance constante. Cependant, un nombre relativement faible de fichiers sont modifiés au cours d'une heure donnée.

Par bidirectionnel, je veux dire que des changements peuvent se produire sur l'un ou l'autre serveur et doivent être poussés sur l'autre, donc rsync ne semble pas approprié.

Par distant, je veux dire que les serveurs sont tous deux dans des centres de données, mais géographiquement éloignés les uns des autres. Actuellement, il n'y a que 2 serveurs, mais cela peut s'étendre avec le temps.

En temps réel, il est acceptable qu'il y ait un peu de latence entre la synchronisation, mais l'exécution d'un cron toutes les 1-2 minutes ne semble pas correcte, car une très petite fraction des fichiers peut changer dans une heure donnée, et encore moins une minute.

EDIT : Cela fonctionne sur les VPS, donc je pourrais être limité sur les types de choses au niveau du noyau que je peux faire. De plus, les VPS ne sont pas riches en ressources, donc je préfère les solutions qui nécessitent beaucoup de RAM (comme Gluster?).

Quelle est la meilleure approche / la plus "acceptée" pour y parvenir? Cela semble être un besoin commun, mais je n'ai pas encore trouvé d'approche généralement acceptée, ce qui était surprenant. (Je cherche la sécurité des masses. :)

J'ai rencontré lsyncd pour déclencher une synchronisation au niveau du changement de système de fichiers. Cela semble intelligent mais pas super commun, et je suis un peu confus par les différentes approches de lsyncd. Il n'y a que lsyncd avec rsync, mais il semble que cela puisse être fragile pour la bidirectionnalité car rsync n'a pas de notion de mémoire (par exemple, pour savoir si un fichier supprimé sur A doit être supprimé sur B ou s'il s'agit d'un nouveau fichier sur B qui doit être copié dans A). lèvresync semble être juste une implémentation lsyncd + rsync, non?

Ensuite, il y a l'utilisation de lsyncd avec csync2 , comme ceci: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Je penche vers cette approche, mais csync2 est un peu excentrique, bien que j'en ai fait un test réussi. Je suis surtout préoccupé par le fait que je n'ai pas pu trouver beaucoup de confirmation communautaire de cette méthode.

Les gens ici semblent beaucoup aimer Unison, mais il semble qu'il ne soit plus en cours de développement actif et il n'est pas clair qu'il dispose d'un déclencheur automatique comme lsyncd.

J'ai vu Gluster mentionné, mais peut-être exagéré pour ce dont j'ai besoin?

MISE À JOUR: fyi- J'ai fini par utiliser la solution originale que j'ai mentionnée: lsyncd + csync2. Cela semble fonctionner assez bien, et j'aime l'approche architecturale consistant à réunir les serveurs de manière très lâche, afin que chaque serveur puisse fonctionner indéfiniment de manière autonome, quelle que soit la qualité de la liaison entre eux.


Quels types de changements devez-vous gérer? Création, suppression, modification d'EG.
sciurus

Vous attendez-vous également à des conflits? Le même fichier peut-il être modifié sur les deux serveurs?
sciurus

Toutes les modifications: création, suppression, modification. Il existe un potentiel de conflits, mais ils devraient être rares. Cela ne me dérangerait pas si je reçois simplement une alerte sur un conflit que je dois ensuite résoudre manuellement.
dlo

Réponses:


5

DRBD en mode double primaire avec un proxy est une option.


Le proxy ne semble être ni open source ni gratuit, non? Je ne suis pas sûr de comprendre la conséquence de ne pas avoir de proxy en mode asynchrone: pendant un temps d'arrêt prolongé, s'il n'y a pas de proxy, le [petit?] Tampon de sortie pourrait se remplir et nous perdrions la synchronisation? Est-ce difficile de s'en remettre?
dlo

Voir ma réponse ci-dessus. Je ne pense pas que le proxy soit la chose dont vous avez besoin. Même pendant un petit temps d'arrêt, le drbd-meta-device marquera les blocs "sales" et les transférera une fois la connexion rétablie. Je pense que la principale différence entre le proxy et le mode asynchrone est que le mode asynchrone utilise une mémoire tampon maximale de certains Mo. Après cela, il se synchronise avant de remplir à nouveau le tampon. Le proxy permet de manière appropriée un plus grand tampon (nécessaire si vous avez une grande latence ou pouvez écrire beaucoup plus rapidement localement qu'à distance).
Nils

2

Plutôt que de synchroniser, pourquoi ne pas partager le même système de fichiers sur NFS?


2
NFS est horrible, tout simplement horrible. Tout serait mieux que NFS
AliGibbs

2
L'un des principaux points de la configuration multi-serveurs est le basculement / la redondance. Un serveur doit donc pouvoir continuer sans l'autre.
dlo

Vous auriez dû mentionner cela dans votre question alors - pas besoin de voter contre une réponse parfaitement raisonnable!
Bart B

fyi je ne l'ai pas dévalorisé - quelqu'un d'autre l'a fait. Mais oui, j'aurais dû le mentionner pour commencer.
dlo

@Bart: Eh bien - il a mentionné qu'il existe un accès simultané sur deux sites distants. Donc, même si vous installez HA-NFS, ce serait une mauvaise solution, car un côté souffrirait de latence pendant l'accès NFS. Et je n'ai pas non plus downvote. Mais je suis administrateur NFS depuis assez longtemps pour prendre en charge AliGibbs. : - /
Nils

2

Implémenter un système de fichiers distribué est probablement mieux que de le pirater avec des outils et des scripts, surtout si le cluster de serveurs va croître. Vous pourrez également mieux gérer un nœud tombé en panne.

Je ne pense pas que Gluster (ou AFS) soit exagéré du tout.


Gluster nécessite 1 Go de RAM? gluster.com/community/documentation/index.php/… ... Je suis également sur un VPS, donc je ne suis pas sûr de faire des changements au niveau du noyau dont AFS pourrait avoir besoin. Mais je commence à voir qu'un bon fs distribué est le meilleur chemin.
dlo

Oui, désolé, je n'ai pas remarqué plus tôt que vous utilisiez des hôtes VPS. Les empreintes de mémoire Gluster, à la fois serveur et client, ne sont pas petites et elles peuvent augmenter considérablement. DRBD semble plus approprié.

AFS est la voie à suivre.
Anthony Giorgio

2

Dans votre cas, je recommanderais une combinaison de DRBD en mode double primaire et de gfs ou ocfs.

L'inconvénient de DRBD en double primaire est qu'il s'exécutera en mode syncrone. Mais la vitesse d'écriture ne semble pas être importante ici non?

Une alternative à DRBD pourrait être un Soft-Raid1 utilisant plusieurs (2+) cibles iSCSI - mais je préférerais DRBD avec deux nœuds.


1
Le mode synchrone serait mauvais - je n'en ai pas besoin et je ne voudrais pas nuire aux performances car les serveurs sont connectés sur un WAN à travers les continents. Mais ne pouvez-vous pas avoir le double primaire en mode asynchrone?
dlo

J'utilise actuellement DRBD 8.3.5 - là, vous devez être en mode sync ("C") pour passer en mode primaire double. Je n'ai aucune expérience personnelle avec le proxy DRBD mais il semble être similaire à Veritas Volume Replicator - mais cela ne convient pas car vous voulez un accès en écriture des deux côtés. Le mode de synchronisation au niveau du bloc n'est peut-être pas aussi mauvais que vous le pensez - peut-être que gfs et / ou ocfs peuvent tamponner les écritures.
Nils

Je viens de vérifier un article allemand comparant GFS2 et OCFS2. D'après cela, au moins OCFS2 semble prendre en charge l'accès au système de fichiers en mémoire tampon. GFS2 est recommandé dans cet article car il est plus ancien. Voir la documentation RedHat sur GFS2 pour plus de détails sur GFS2 - il utilise également la mise en mémoire tampon - mais vous devez utiliser des répertoires différents pour les écritures simultanées pour obtenir les meilleures performances.
Nils

0

Comme démontré ci-dessus, de nombreuses solutions sont disponibles, chacune avec ses avantages et ses inconvénients.

Je pense que j'envisagerais de placer tout l'arbre sous contrôle de version ( Subversion , par exemple) et de vérifier / mettre à jour périodiquement à partir des deux serveurs dans les tâches cron.


0

Après avoir terminé quelque peu une quête concernant la même chose, je vais avec gluster. Cependant, je n'ai pas fait ou trouvé de tests de performances.

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.