GlusterFS est-il un bon choix pour garder les serveurs Web synchronisés?

9

J'ai 2 serveurs Web, avec la possibilité d'avoir à ajouter plus de serveurs en cours de route. En ce moment, je garde ces serveurs synchronisés en utilisant lsyncd + csync2. Cela fonctionne bien en termes de performances car tous les fichiers sont sur les deux serveurs (aucun accès réseau requis pour ouvrir les fichiers localement), mais pas si bien dans d'autres cas.

Un exemple de ceci est si je supprime un fichier sur le serveur 1 et télécharge immédiatement un nouveau fichier sur le serveur 1 qui porte le même nom. Le fichier serait alors supprimé du serveur 2 entre-temps, entraînant la suppression du fichier nouvellement téléchargé sur le serveur 1 car le serveur 2 envoie l'événement de suppression au serveur 1 pour terminer le "cercle de mise à jour".

Je ne peux m'empêcher de penser qu'il doit y avoir une meilleure façon de garder les serveurs synchronisés. J'ai regardé GlusterFS, et je vois qu'une configuration où tous les fichiers sont répliqués sur tous les serveurs est déconseillée. Cependant, j'exécute des systèmes CMS comme Drupal sur ces serveurs. De tels systèmes CMS ouvrent souvent un certain nombre de fichiers, et je crains qu'un trafic réseau trop important pour mettre la main sur ces fichiers ne ralentisse les demandes.

Serait-ce une idée de chercher à remplacer lsyncd + csync2 par GlusterFS configuré pour répliquer tous les fichiers sur tous les nœuds, ou est-ce une mauvaise idée?

web-server replication glusterfs lsyncd csync2 sbrattla
la source
2
Je peux mal comprendre votre problème ici, mais pourquoi ne pas utiliser le stockage réseau partagé entre les serveurs?
mveroone
1
@Kwaio: je voudrais "mettre en miroir" tous les serveurs Web (à la fois les scripts et le contenu téléchargé par l'utilisateur) car cela évitera les temps d'arrêt si quelque chose ne va pas avec le serveur hébergeant le stockage partagé. En d'autres termes, je ne veux pas me fier à une configuration où tous les serveurs Web reposent à nouveau sur un seul stockage de fichiers.
sbrattla
Alors pourquoi pas un cluster de stockage réseau haute disponibilité?
mveroone
Bien sûr, mais qu'est-ce que cela implique? Matériel?
sbrattla
Je ne suis pas un spécialiste, mais cela signifie avoir votre stockage réseau en miroir dans une architecture maître-esclave sur 2 clusters, et un système qui commute en cas de défaillance du maître. La plupart des fournisseurs de périphériques de stockage en réseau ont des solutions pour cela, même si vous pouvez le construire vous-même avec des appliances linux, ce qui nécessiterait beaucoup de développement.
mveroone

Réponses:

2

BitTorrent Sync peut faire l'acte pour vous. Je l'utilise pour garder les fichiers synchronisés entre quelques serveurs internes de ma maison et cela fonctionne à merveille. L'autre chose à laquelle vous devrez penser est la base de données backend lorsque votre application utilise un CMS. Assurez-vous qu'il y a une réplication MySQL en cours, ou quelque chose de ce genre.

whiskykilo
la source
C'est intéressant. Comment BitTorrent Sync gère-t-il les conflits? Supposons que j'ai 5 serveurs Web et qu'un fichier soit mis à jour sur le serveur A. Ensuite, 2 secondes plus tard, le même fichier est mis à jour sur le serveur C avant que la modification sur A n'ait atteint C. Le logiciel dispose-t-il d'algorithmes pour configurer quel serveur gagne dans ces cas?
sbrattla
D'après ce que je comprends, BitTorrent Sync comparera la date / heure de modification sur les deux copies et ne gardera que la dernière, ce qui pourrait être idéal ou pourrait nuire au cas d'utilisation.
whiskykilo
1

Gluster résoudrait le problème que vous rencontrez, car il peut contenir les verrous, propager les modifications - supprimer le fichier sur tous les autres nœuds, mais il peut ajouter une latence supplémentaire qui peut être un problème pour un serveur Web. L'alternative suivante est DRBD + OCFS2 ou GFS, mais c'est probablement plus complexe car avec gluster vous utilisez le système de fichiers sous-jacent - il ne fonctionne pas au niveau du bloc, donc si les serveurs ne sont pas synchronisés, ce n'est pas trop difficile à réparer, les fichiers peuvent ne vous corrompez pas si facilement à cause de cerveaux séparés, etc ...

Nous l'utilisons pour un serveur de messagerie et il est assez lent pour les répertoires contenant beaucoup de fichiers. Vous devez absolument tout tester avant de déployer. Je teste actuellement le montage NFS car il fonctionne mieux pour les petits fichiers.

Jure1873
la source
1

GlusterFS est difficile à déployer. Pour les données Web, le niveau de synchronisation des fichiers comme Unison est beaucoup plus facile à déployer et à entretenir.

DRBD est une solution parfaite pour garder la synchronisation des données au niveau du bloc. Mais vous devez les formater dans un format spécial comme OCFS2 ou quelque chose de similaire.

truongtx
la source
GlusterFS n'est pas comme DRBD - il ne fonctionne pas au niveau du bloc, mais au niveau du fichier. Mais je suis convaincu que l'unisson est plus facile à déployer.
Jure1873
-3

Pourquoi n'utilisez-vous pas un outil comme une marionnette ? Écrivez une fois dans une source et une fois prêt, déployez-le sur les cibles en utilisant "marionnette" ou mcolletive. C'est bien documenté. Et vous pouvez facilement ajouter des serveurs plus tard si nécessaire.

Vous pouvez également compter sur des outils utilisant inotify, comme lsyncd, travaillant au niveau du noyau. Il surveille les modifications dans un dossier et déclenche une synchronisation. Mais si un outil dédié à la synchronisation de fichiers sur un cluster comme csync2 ne suffit pas, je ne sais pas ce que ce sera.

Juste pour être sûr, les modifications se produisent-elles également sur le serveur 2 ou uniquement sur le serveur 1?

Rosco
la source
3
Downvoted - Puppet n'est pas un bon moyen de garder les fichiers en synchronisation entre les serveurs. Il est cependant un outil génial pour la gestion de la configuration du serveur .
Craig Watson
Des modifications peuvent se produire sur n'importe quel serveur, car elles participent à une configuration à charge équilibrée. Les utilisateurs peuvent télécharger des fichiers sur n'importe quel serveur, et ce fichier doit par conséquent être disponible sur tous les serveurs à mesure que le trafic est réparti entre les serveurs.
sbrattla
1
Eh bien, dans ce cas, la marionnette n'est pas ce que vous voulez (mais quand même, @Craig Watson, un fichier est un fichier, une configuration ou HTML, c'est toujours un fichier). Je doute que GlusterFS soit prêt pour la production, donc si vous voulez vraiment quelque chose de sûr, vous feriez mieux d'utiliser un serveur NFS avec une haute disponibilité.
Rosco