Partage / accueil entre centres de données


15

J'ai deux serveurs, placés dans des centres de données en Hollande et en France. Les deux exécutent Debian Wheezy. Je dois partager / rentrer entre eux, avec de bonnes performances. Il y a quelque 300 utilisateurs sur les serveurs, environ 30 d'entre eux devraient pouvoir avoir des processus actifs sur un serveur donné à un moment donné, chacun ayant des lectures de 50 kbit et et des écritures de 20 kbit / seconde, avec des pics courts autour de 2000 kbit / s lecture. mesures avec iotop sur le stockage local. J'ai beaucoup de petits fichiers, environ 500 000 au total et j'ai besoin d'une latence aussi faible que possible. Le ping entre les serveurs est de 17 ms et la connexion peut atteindre environ 20 à 30 Mo / s lors de l'utilisation de scp et wget. Il semble qu'il devrait y avoir beaucoup de bande passante disponible pour que cela fonctionne aussi, mais ...

Ce que j'ai vérifié jusqu'à présent: sshfs: il semblait que ses performances étaient meilleures que nfs, mais il a changé de façon aléatoire les autorisations des fichiers en root, ce qui a provoqué le crash de l'application.

nfs: moyen de ralentir, d'essayer le noatime et un tas d'autres options, mais il reste lent, même lorsque seuls quelques processus sont actifs.

drbd: 5 heures de travail sans issue, quand j'ai réalisé que je ne pouvais pas vraiment monter le système de fichiers sur les deux systèmes :-(

glusterfs: Avoir une copie locale de toutes les données semblait vraiment prometteur, mais l'accès aléatoire aux fichiers est vraiment lent et après un certain temps, cela devient incroyablement lent et se bloque presque. noatime n'aide pas.

nfs encore: Toujours lent.

Pleurer dans le clavier: Aucune amélioration du tout.

Quoi essayer ensuite? Chacun des essais ratés a pris une soirée ou peut-être plus au cours de la dernière semaine, et j'aimerais vraiment que la prochaine méthode fonctionne. Et oui, il est crucial que les systèmes de fichiers soient partagés entre les deux serveurs.

Merci pour toutes nouvelles idées sur ce problème.


6
"Pleurer dans le clavier: Aucune amélioration du tout." OK, ça me donne un +1.
ceejayoz

Vous aurez probablement besoin de glusterfs ou de ceph. Un système de fichiers distribué. En outre, vous pouvez monter drbd plusieurs fois, mais une seule lecture-écriture, et c'est quand même une mauvaise idée effrayante.
Sirex

J'ai essayé glusterfs, et même si cela fonctionne très bien avec de gros fichiers, il devient vraiment lent lors de la lecture ou de l'écriture de petits fichiers. Cela semble être un problème commun avec glusterfs, et je n'ai pas pu trouver de solution. Je vais regarder Ceph. L'avez-vous essayé vous-même l'avez essayé?
user3850506

3
Monter le même périphérique de bloc et le même système de fichiers, même RO sur un système différent est mauvais juju, sauf si le pilote du système de fichiers comprend que le périphérique de bloc de support peut changer arbitrairement à tout moment. Le périphérique de bloc pourrait changer et invalider complètement le cache d'inode et le VFS serait heureux de lire des données qui ne sont plus là où vous le pensiez. Les systèmes de fichiers compatibles avec les disques partagés comme GFS2 et veritas peuvent le faire sur DRBD ou sur n'importe quel disque de type SAN. Je ne peux pas dire avec certitude que les performances de votre petit fichier seront acceptables.
Andrew Domaszek

Réponses:


2

Il existe quelques solutions possibles à cela:

  1. Vous pouvez opter pour un stockage en bloc répliqué comme DRBD (ou MARS comme mentionné ci-dessus), mais vous devez configurer un système de fichiers de cluster au-dessus du stockage en bloc. Ces systèmes de fichiers pourraient être GFS2 ou OCFS2 qui sont tous deux disponibles dans le noyau Debian afaik. DRBD peut gérer primaire / primaire et vous pouvez le monter sur les deux serveurs en même temps. Mais si vous le faites avec un système de fichiers standard, un serveur ne connaît pas l'autre et vous détruiriez votre système de fichiers en quelques secondes. Un système de fichiers de cluster sur le dessus gérerait la communication et le verrouillage afin que les deux nœuds puissent écrire dans le même bloc.

  2. Utilisez un système de fichiers distribué pour / home. Vous trouverez une liste de ces systèmes de fichiers sur http://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems . Mais méfiez-vous et choisissez judicieusement. Ils ne peuvent pas tous faire de la magie et ont tous leurs inconvénients. Gluster est un tel système de fichiers. Pour certains systèmes, vous pourriez avoir besoin de plus de deux nœuds seulement.

  3. S'il ne doit pas être répliqué en temps réel et qu'une synchronisation de fichiers presque en temps réel serait suffisante, alors jetez un œil à BitTorrent Sync ( http://www.getsync.com/ ), Dropbox ou alternatives. Chaque serveur a son propre / home, mais les modifications sont répliquées sur la base de fichiers sur l'autre serveur.


1
rsync ftw 123456
dmourati
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.