2 votes

synchronisation en temps réel pour les serveurs de partage de fichiers

Je dirige un site de partage de fichiers, dont la popularité augmente rapidement.

Pour l'instant, mon application web est sur AWS elastic beanstalk, ce qui lui permet bien sûr de s'adapter parfaitement, mais mes fichiers sont actuellement tous servis à partir d'un seul boîtier dédié. La boîte commence à atteindre le maximum de sa connexion 1gbps, donc j'essaie de chercher comment faire évoluer le stockage des fichiers.

NB : J'ai également tous les fichiers synchronisés sur S3, mais il est beaucoup trop coûteux de les servir à partir de là en raison des frais de bande passante de S3. Ma boîte dédiée n'est pas mesurée.

Jusqu'à présent, j'ai entendu parler de DRBD et de Lsyncd, mais aucun ne correspond à ce que je recherche.

Tout conseil sur la meilleure configuration pour faire fonctionner plusieurs boîtes linux de stockage de fichiers en synchronisation en temps réel derrière un équilibreur de charge serait grandement apprécié.

P.S - il faut noter que mon scénario idéal est qu'ils soient tous synchronisés à tout moment, donc si un fichier est ajouté à une boîte, il est synchronisé sur toutes les boîtes. Idem lorsqu'un fichier est supprimé.

2voto

dsegleau Points 1460

GlusterFS est une excellente solution pour cela, tout comme Ceph. GlusterFS est plus facile à gérer et n'utilise pas la réplication de nœud à nœud comme méthode principale de réplication ou de distribution des données. Il peut effectuer une mise en miroir de 2n ou 3n briques, où une brique est simplement un système de fichiers sur un nœud. Un ensemble complet de briques est appelé un volume, et un volume est monté comme un partage NFS - à l'exception de l'écriture et de la lecture sur plusieurs nœuds plutôt que sur un seul.

Gluster monte et descend en flèche, et n'a pas de concept de nœud maître. Tous les noeuds participent de manière égale aux volumes dont ils sont membres. Ce sont les clients qui se connectent à GlusterFS qui sont responsables de la répartition des données sur tous les nœuds, plutôt que chaque nœud responsable de la réplication des données. De cette façon, vous n'avez pas besoin d'avoir d'énormes liaisons de backhaul mal dimensionnées.

Voici un bon guide étape par étape sur la façon de le mettre en place : https://www.digitalocean.com/community/tutorials/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers

La documentation de gluster vaut également la peine d'être lue : https://gluster.readthedocs.io/en/latest/

0 votes

Dans l'ensemble, c'est une bonne idée, bien que cela puisse devenir ... un peu compliqué si l'on veut répliquer sur de longues distances.

0 votes

OUI, car tout ce que vous utilisez pour la géo-réplication dans Gluster actuellement est un rsync créatif. Ce n'est pas exactement la méthode la plus rapide et la plus efficace.

0 votes

@MichaelHampton Soyez conscient que GlusterFS est pas destiné à être répliqué en lecture/écriture sur des liaisons WAN (c'est-à-dire avec une latence élevée et une faible fiabilité). Pour répliquer sur de longues distances, il fallait utiliser la géoreplication qui est une réplication en lecture seule effectuée via rsync.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X