Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans : - NFS début des années 2000 vite abandonné - lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs - DRBD limité à 2 serveurs - GlusterFS sympa sur le papier mais pas performant - CephFS que j'adore mais le coût initial en serveur n'est pas adapté à toutes les architectures - inotify / rsync et dérivé en mode bidouillage - cluster de php fpm déportés du serveur web mais nécessite que le code php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste - Syncthing qui tournerait sur les front web pour se synchroniser mutuellement mais quid de la performance et du délai de synchronisation? - FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Hello,
Petite question, quel est ta fréquence lecture / écriture dessus ?
Car j’ai moi même un petit cluster Ceph de (164TO) je suis environ a 18 euros le TO (replica 2) avec des machines de 4 disques SAS sans avoir le journal ceph sur SSD, Coté performances c’est plutôt bon de mon coté surtout en read.
-- Cordialement, Corentin BONNETON
Le 17 mai 2016 à 17:02, Wallace wallace@morkitu.org a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
C'est équilibré, les sources et fichiers sont lus mais en écriture y a des logs d'application qui contre balance. Ton infra Ceph tu le fais sur quel matériel pour avoir ce coût?
Le 17/05/2016 17:18, Corentin Bonneton a écrit :
Hello,
Petite question, quel est ta fréquence lecture / écriture dessus ?
Car j’ai moi même un petit cluster Ceph de (164TO) je suis environ a 18 euros le TO (replica 2) avec des machines de 4 disques SAS sans avoir le journal ceph sur SSD, Coté performances c’est plutôt bon de mon coté surtout en read.
-- Cordialement, Corentin BONNETON
Le 17 mai 2016 à 17:02, Wallace <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
Re :)
Je loue du matos chez ovh, j’utilise plutôt la gamme FS après a voir selon tes besoins etc mais il y a moyen de faire des trucs vraiment cool avec ceph :D
-- Cordialement, Corentin BONNETON
Le 17 mai 2016 à 17:37, Wallace wallace@morkitu.org a écrit :
C'est équilibré, les sources et fichiers sont lus mais en écriture y a des logs d'application qui contre balance. Ton infra Ceph tu le fais sur quel matériel pour avoir ce coût?
Le 17/05/2016 17:18, Corentin Bonneton a écrit :
Hello,
Petite question, quel est ta fréquence lecture / écriture dessus ?
Car j’ai moi même un petit cluster Ceph de (164TO) je suis environ a 18 euros le TO (replica 2) avec des machines de 4 disques SAS sans avoir le journal ceph sur SSD, Coté performances c’est plutôt bon de mon coté surtout en read.
-- Cordialement, Corentin BONNETON
Le 17 mai 2016 à 17:02, Wallace < mailto:wallace@morkitu.orgwallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/ http://www.frsag.org/
On 2016-05-17 17:02, Wallace wrote:
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
Dans JOB-1, on utilisait FreeBSD ZFS + export en NFS et ca marchait pas mal avec une dizaine de serveurs en client. Si c'est du site en wordpress par exemple, utiliser des plugins S3 pour les publications d'assets et le faire pointer vers son propre cluster swift.
Il te faut mieux definir tes usages: - fichiers relativement statique (code, css ...) qui se depose sur un FTP et ensuite distribué (rsync) vers tes differents serveurs - fichiers uploadés par les utilisateurs/administrateurs, alors pourquoi pas coder un truc a base de TahoeFS ?
Hope this helps.
A ma connaissance il n'existe pas de solution magique, et je crois que tu as cité un peu toutes manières de faire. Honnêtement pour un site web relativement simple j'en resterais à une solution simple avec l'arborescence du site synchronisé avec csync2, et du cache partagé ou pas.l La clé dans ce genre de petit projet vient de bien faire comprendre au client comment bien découper son arborescence (static, dynamique, cache). Après plus de soucis.
--
Raphael Mazelier
Le 17/05/2016 à 17:02, Wallace a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 17/05/2016 17:50, raf a écrit :
A ma connaissance il n'existe pas de solution magique, et je crois que tu as cité un peu toutes manières de faire. Honnêtement pour un site web relativement simple j'en resterais à une solution simple avec l'arborescence du site synchronisé avec csync2, et du cache partagé ou pas.l
Tu as de l'expérience prod avec csync2, ça semble plus carré que les bricolages avec inotify et rsync que j'ai manipulé en 2008.
La clé dans ce genre de petit projet vient de bien faire comprendre au client comment bien découper son arborescence (static, dynamique, cache). Après plus de soucis.
Disons qu'il y a un très gros travail d'évangélisation que je fais depuis 4 ans déjà, pas évident, ils sont fermés à l'évolution.
Le 17/05/2016 à 20:02, Wallace a écrit :
Tu as de l'expérience prod avec csync2, ça semble plus carré que les bricolages avec inotify et rsync que j'ai manipulé en 2008.
Yep ca juste marche et c'est très simple. Évidement ça marche d'autant mieux que le client va pas faire le boulet à déployer deux versions différentes sur les deux webs.
La clé dans ce genre de petit projet vient de bien faire comprendre au client comment bien découper son arborescence (static, dynamique, cache). Après plus de soucis.
Disons qu'il y a un très gros travail d'évangélisation que je fais depuis 4 ans déjà, pas évident, ils sont fermés à l'évolution.
A ce point ? mème nos clients les plus réfractaire au changement, nous avons réussi à leur faire appliquer quelques bonnes pratiques.
Le 18/05/2016 15:18, raf a écrit :
Le 17/05/2016 à 20:02, Wallace a écrit :
Tu as de l'expérience prod avec csync2, ça semble plus carré que les bricolages avec inotify et rsync que j'ai manipulé en 2008.
Yep ca juste marche et c'est très simple. Évidement ça marche d'autant mieux que le client va pas faire le boulet à déployer deux versions différentes sur les deux webs.
Oui comme pour inotify on donne accès qu'à un seul serveur considéré comme master.
La clé dans ce genre de petit projet vient de bien faire comprendre au client comment bien découper son arborescence (static, dynamique, cache). Après plus de soucis.
Disons qu'il y a un très gros travail d'évangélisation que je fais depuis 4 ans déjà, pas évident, ils sont fermés à l'évolution.
A ce point ? mème nos clients les plus réfractaire au changement, nous avons réussi à leur faire appliquer quelques bonnes pratiques.
La théorie du "ça marche on touche pas" fait des miracles en immobilisme. Le souci c'est que l'équipe technique n'a aucun poids en interne, c'est le marketing qui dicte et donc tout est fait à l'arrache, impossible pour eux de prendre du recul pour faire les choses bien et par exemple faire des mises à jour ou évoluer...
Bonjour,
Si l'application peut être adapté, une évolution ces dernières années avac le Cloud, c'est le stockage Objet. - S3 chez Amazon - OpenStack Swift (chez OVH et tout Cloud basé sur OpenStack) Ceph avec rados gateway permet de faire du Swift Certaines baie le propose maintenant (EMC Isilon)
Je ne connais pas, mais en cherchant deux minutes des alternatives de stockage objet plus simple, je suis tombé là dessus : https://minio.io/ Par le développeur de GlusterFS.
Le 17/05/2016 à 17:02, Wallace a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
On Tue, May 17, 2016 at 05:02:46PM +0200, Wallace wrote:
- GlusterFS sympa sur le papier mais pas performant
GlusterFS est pas performant, mais en activant APCu et OPCache, ça marche pas mal du tout. L'astuce étant de mettre stat à 0 pour APCu, après c'est sûr que pour mettre à jour le code il faut relancer PHP ce qui n'est pas super pratique, mais bon ..
Bonjour à tous,
Nous avons monté pour le ccfd Terre solidaire un petit cluster Ceph/Proxmox de deux serveurs Xeon de base + une petite machine Atom pour avoir le quorum. Deux disque de 1To par Xeon pour les osd's. Le tout avec une réplication par 4 (ceinture et bretelles) avec 2 cartes réseau bondées en round-robin coté Ceph.
Pas cher, sûr et performant.
Internet'ment vôtre,
Guillaume Digicube sas www.digicube.fr
Le 17/05/2016 17:02, Wallace a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
j'ai aussi testé toute ces solutions et finalement je suis resté sur l'architecture de départ : 2 serveurs NFS v4 avec Nginx, réplication entre les 2 via drbd.
Les écritures (uploads) se font directement du serveur PHP sur le NFS. Les lectures sont proxyfié : [ Nginx --> proxy_pass ] --> [ nginx --> disque dur direct ]
Par contre, j'ai du virer Apache qui gère très mal les problèmes d'accès au NFS.
Le 17 mai 2016 à 17:02, Wallace wallace@morkitu.org a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
On Tuesday 17 May 2016 17:02:46 Wallace wrote:
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté
à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le
code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
Depuis la version 9, DRBD gère jusqu'à 16 noeuds. https://www.drbd.org/en/doc/users-guide-90/s-multi-node
Par contre, je ne l'ai pas encore testé. Donc, je ne sais pas ce que ça vaut au niveau perf ou facilité d'administration. -- Xavier
Depuis la version 9, DRBD gère jusqu'à 16 noeuds. https://www.drbd.org/en/doc/users-guide-90/s-multi-node
Par contre, je ne l'ai pas encore testé. Donc, je ne sais pas ce que ça vaut au niveau perf ou facilité d'administration.
Je me trompe peut-être mais pour moi c'est pas encore en stable, j'ai testé un peu il y a quelques semaines et ça a pas encore l'air d'être ça. Rien que monter le cluster est pas simple, ça crache des erreurs non documentées dans tout les sens via dbus ou python, et quand j'ai été essayer d'avoir des infos sur IRC on m'a dit de surtout pas le mettre en prod, y a des gens qui ont à priori perdu des données il y a pas si longtemps avec. J'attendrais d'être sûr que ce soit bien stable moi !
J'avais oublié de précisé qu'il s'agit de deux VM et qu'il n'y a pas de budget pour des serveurs physiques ou vm supplémentaire. Autre point les 2 vm front web sont en IP v6 only, seul les load balancer en amont sont dual stack. Si le pourquoi vous viens à l'esprit, on économise les IP v4 publiques d'une et on a banni tout usage d'IP v4 privée et depuis c'est un bonheur de gérer les firewall, que du filtrage et plus de NAT.
Le fait d'être en IPv6 only nous a par contre exclu de la solution glusterfs qui depuis janvier se traîne un méchant bug qui fait que les hosts ne se voient pas.
Je retiens pour tester les solutions suivantes :
- csync2 qui me semble pas mal mais je pense que les accès concurrentiels en écriture que le client aura cacher dans son code donnera des fichiers inconsistants (oui le fichier de log codé en dur sans qu'on soit au courant) - tenter un cephs avec tous les composants sur les front web mais je ne suis pas partisan de mettre autant de couche logiciel sur le même OS - partir sur du DRBD et OC2FS, ça juste marchera et si besoin de monter à trois front web, on proposera une autre solution - offrir au client une vm qui exportera du NFS, pour moi comme pour l'équipe ça va être back to 2000, des lustres qu'on a plus utilisé cette solution, on ne sait même pas si ça marche en IPv6 only
Merci à tout ceux qui m'ont répond en privé avec des FS que je ne connaissais pas, pour en faire profiter tout le monde, Anthony m'a envoyé ces vidéos http://webcast.in2p3.fr/events-tutojres_le_stockage_distribue de conférences sur le stockage distribué à grande échelle, très intéressant à la pause déjeuner :)
Le 17/05/2016 17:02, Wallace a écrit :
Bonjour à tous,
Pour faire des clusters web avec espace de fichiers partagés j'ai utilisé pas mal de technique depuis plus de 15 ans :
- NFS début des années 2000 vite abandonné
- lun partagée en iscsi et oc2fs testé jusqu'à 9 serveurs
- DRBD limité à 2 serveurs
- GlusterFS sympa sur le papier mais pas performant
- CephFS que j'adore mais le coût initial en serveur n'est pas adapté à
toutes les architectures
- inotify / rsync et dérivé en mode bidouillage
- cluster de php fpm déportés du serveur web mais nécessite que le code
php ne doive pas manipuler de fichiers
Le souci c'est qu'avec toutes ces solutions j'ai un beau panel pour m'adapter mais cela ne suffit pas. Là j'ai un cas concret où j'ai 2 serveurs front web Nginx / PHP-FPM où les mêmes sites doivent être servis MAIS le client ne veut pas et n'a pas les moyens d'avoir un partage correct genre Ceph. Je sais que la solution doit pouvoir monter à 3/4 serveurs web si la charge augmente pendant la saisonnalité du client ce qui écarte la réplication DRBD qui fait très bien son boulot en dual master pour 2 serveurs.
J'ai comme piste
- Syncthing qui tournerait sur les front web pour se synchroniser
mutuellement mais quid de la performance et du délai de synchronisation?
- FineFS mais le projet semble ne plus être maintenu
Du coup je sèche, avez-vous une idée de nouvelle façon de faire? Par avance merci pour vos expériences.
Liste de diffusion du FRsAG http://www.frsag.org/
-
Corentin Bonneton -
Denis Fondras -
Gilles Mocellin -
Greg -
Guillaume Esnault -
Kevin Lemonnier -
raf -
Thomas Pedoussaut -
Wallace -
Xavier Claude