Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins 200To utiles qui seront accédés en mode fichiers (NFS, CIFS). - Il faudrait que l'on puisse disposer d'une redondance permettant de pallier à la panne d'un ou plusieurs disques ou d'un noeud. - Il est acceptable d'avoir une interruption de service pour redémarrer le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de petits fichiers (plus de 400 millions de fichiers de moins de 128ko). - A noter que pour convenance du service, les systèmes hôtes seront sous Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
J'ai regardé les divers projets pour cette problématique (et n'en utilise aucun actuellement), est :
glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, mais pas trop Ceph est, je trouve, beaucoup plus intéressant (mieux fait, au niveau de la conception, de ce que tu peux en faire etc etc). Cependant, c'est peut-être un peux trop jeune pour s'en servir massivement (enfin, vu que des gens utilisent butterfs en production, pourquoi pas ..)
Je me demande si une solution plus classique ne serait pas envisageable (surtout si tu utilises zfs / mdadm) : export des nodes en iscsi, construction d'un raid (ou raid-like) par dessus Évidement, cela signifie que tu as un point d'entrée unique au système En cas de perte d'un node, tu peux le remplacer et reconstruire le raid En cas de perte du maître, tu devrait pouvoir déplacer l'ensemble des points de montages sur une autre machine, avec l'IP
À tester;
On 12/12/2014 12:14, Jerome LE TANOU wrote:
Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins
200To utiles qui seront accédés en mode fichiers (NFS, CIFS).
- Il faudrait que l'on puisse disposer d'une redondance permettant de
pallier à la panne d'un ou plusieurs disques ou d'un noeud.
- Il est acceptable d'avoir une interruption de service pour redémarrer
le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de
petits fichiers (plus de 400 millions de fichiers de moins de 128ko).
- A noter que pour convenance du service, les systèmes hôtes seront sous
Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
Ceph commence a marcher plutot bien, plusieurs Cloudproviders europeens sont en production avec et le code est activement developpe. Il est je pense plus flexible que glusterfs.
Le 12/12/14 12:32, frsag@jack.fr.eu.org a écrit :
J'ai regardé les divers projets pour cette problématique (et n'en utilise aucun actuellement), est :
glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, mais pas trop Ceph est, je trouve, beaucoup plus intéressant (mieux fait, au niveau de la conception, de ce que tu peux en faire etc etc). Cependant, c'est peut-être un peux trop jeune pour s'en servir massivement (enfin, vu que des gens utilisent butterfs en production, pourquoi pas ..)
Je me demande si une solution plus classique ne serait pas envisageable (surtout si tu utilises zfs / mdadm) : export des nodes en iscsi, construction d'un raid (ou raid-like) par dessus Évidement, cela signifie que tu as un point d'entrée unique au système En cas de perte d'un node, tu peux le remplacer et reconstruire le raid En cas de perte du maître, tu devrait pouvoir déplacer l'ensemble des points de montages sur une autre machine, avec l'IP
À tester;
On 12/12/2014 12:14, Jerome LE TANOU wrote:
Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins
200To utiles qui seront accédés en mode fichiers (NFS, CIFS).
- Il faudrait que l'on puisse disposer d'une redondance permettant de
pallier à la panne d'un ou plusieurs disques ou d'un noeud.
- Il est acceptable d'avoir une interruption de service pour redémarrer
le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de
petits fichiers (plus de 400 millions de fichiers de moins de 128ko).
- A noter que pour convenance du service, les systèmes hôtes seront sous
Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
Bonjour,
On 12/12/2014 12:32 PM, frsag@jack.fr.eu.org wrote:
glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, mais pas trop
C'est un peu ça oui. Pour avoir utilisé GlusterFS pendant un temps certain en production, c'est extrêment chaotique avec des situations où GlusterFS refuse purement et simplement de fonctionner sans messages d'erreurs d'aucune sorte nul part.
Sans compter des applications qui finissent en D sur le GluterFS sans vraiment de raisons connues. Ce qui grève fortement les performances et la stabilité de l'ensemble.
À noter également l'incompatibilité entre le NFS server utilisé par la distribution et celui de GlusterFS (si si) qui peut mener à de sacrés sketchs lorsque vous exportez du NFS hors de GlusterFS.
Bref, autant dire que les backups ont servi plusieurs fois...
Je déconseille fortement en production.
On 12/12/2014 12:14, Jerome LE TANOU wrote:
Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins
200To utiles qui seront accédés en mode fichiers (NFS, CIFS).
- Il faudrait que l'on puisse disposer d'une redondance permettant de
pallier à la panne d'un ou plusieurs disques ou d'un noeud.
- Il est acceptable d'avoir une interruption de service pour redémarrer
le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de
petits fichiers (plus de 400 millions de fichiers de moins de 128ko).
- A noter que pour convenance du service, les systèmes hôtes seront sous
Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
Bonjour,
J'ai testé GlusterFS en production, ce fus une très mauvaise expérience. Ceph était beaucoup plus stable même si j'ai eu quelques trucs bizarres. Au final on utilise ce bon vieux NFSv4 qui est le plus mauvais niveau performance, mais le plus stable ...
Aujourd'hui, si possible, je pense que je partirais sur une solution très différente, par exemple à base d'elasticsearch qui est ultra-stable, performant, scalable, un bonheur pour les sysadmins, mais qui nécessite plus d'adaptation coté application.
Greg
Le 12 décembre 2014 13:21, Pierre Schweitzer pierre@reactos.org a écrit :
Bonjour,
On 12/12/2014 12:32 PM, frsag@jack.fr.eu.org wrote:
glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, mais pas trop
C'est un peu ça oui. Pour avoir utilisé GlusterFS pendant un temps certain en production, c'est extrêment chaotique avec des situations où GlusterFS refuse purement et simplement de fonctionner sans messages d'erreurs d'aucune sorte nul part.
Sans compter des applications qui finissent en D sur le GluterFS sans vraiment de raisons connues. Ce qui grève fortement les performances et la stabilité de l'ensemble.
À noter également l'incompatibilité entre le NFS server utilisé par la distribution et celui de GlusterFS (si si) qui peut mener à de sacrés sketchs lorsque vous exportez du NFS hors de GlusterFS.
Bref, autant dire que les backups ont servi plusieurs fois...
Je déconseille fortement en production.
On 12/12/2014 12:14, Jerome LE TANOU wrote:
Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins
200To utiles qui seront accédés en mode fichiers (NFS, CIFS).
- Il faudrait que l'on puisse disposer d'une redondance permettant de
pallier à la panne d'un ou plusieurs disques ou d'un noeud.
- Il est acceptable d'avoir une interruption de service pour redémarrer
le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de
petits fichiers (plus de 400 millions de fichiers de moins de 128ko).
- A noter que pour convenance du service, les systèmes hôtes seront sous
Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
-- Pierre Schweitzer pierre@reactos.org System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour.
J'ai effectivement pu constater des bugs sur glusterfs, particulièrement sur des environnements web répliqués. Les serveurs partaient en sucette fréquemment. Cette histoire de NFS qui est assez pénible aussi.
Actuellement je bench une solution articulée autour de DRDB en primary/primary avec un filesystem OCFS2 par dessus (monté sur les 2 serveurs bien sur).
Mis a part un bug de désynchro insolvable de DRBD (en 8.3, migré en 8.4 via les backports) pas de réels problèmes, les deux semblent fait pour s'entendre à la perfection.
Je ne peux pas vraiment tester les perfs en écriture, le lien DRBD étant monté au travers un VPN IPsec "de pauvre" (100Mbps en pointe).
Pierre.
Le 12/12/2014 13:37, Greg a écrit :
Bonjour,
J'ai testé GlusterFS en production, ce fus une très mauvaise expérience. Ceph était beaucoup plus stable même si j'ai eu quelques trucs bizarres. Au final on utilise ce bon vieux NFSv4 qui est le plus mauvais niveau performance, mais le plus stable ...
Aujourd'hui, si possible, je pense que je partirais sur une solution très différente, par exemple à base d'elasticsearch qui est ultra-stable, performant, scalable, un bonheur pour les sysadmins, mais qui nécessite plus d'adaptation coté application.
Greg
Le 12 décembre 2014 13:21, Pierre Schweitzer <pierre@reactos.org mailto:pierre@reactos.org> a écrit :
Bonjour, On 12/12/2014 12:32 PM, frsag@jack.fr.eu.org <mailto:frsag@jack.fr.eu.org> wrote: > glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". > J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, > mais pas trop C'est un peu ça oui. Pour avoir utilisé GlusterFS pendant un temps certain en production, c'est extrêment chaotique avec des situations où GlusterFS refuse purement et simplement de fonctionner sans messages d'erreurs d'aucune sorte nul part. Sans compter des applications qui finissent en D sur le GluterFS sans vraiment de raisons connues. Ce qui grève fortement les performances et la stabilité de l'ensemble. À noter également l'incompatibilité entre le NFS server utilisé par la distribution et celui de GlusterFS (si si) qui peut mener à de sacrés sketchs lorsque vous exportez du NFS hors de GlusterFS. Bref, autant dire que les backups ont servi plusieurs fois... Je déconseille fortement en production. > > On 12/12/2014 12:14, Jerome LE TANOU wrote: >> Bonjour, >> >> - Nous souhaitons mettre un oeuvre une solution de stockage d'au moins >> 200To utiles qui seront accédés en mode fichiers (NFS, CIFS). >> - Il faudrait que l'on puisse disposer d'une redondance permettant de >> pallier à la panne d'un ou plusieurs disques ou d'un noeud. >> - Il est acceptable d'avoir une interruption de service pour redémarrer >> le service en cas de panne majeure dans la limite de 4H. >> >> - A noter qu'actuellement nos utilisateurs utilisent énormément de >> petits fichiers (plus de 400 millions de fichiers de moins de 128ko). >> - A noter que pour convenance du service, les systèmes hôtes seront sous >> Debian. >> >> Au vue des différents articles, documentations que nous avons consulté, >> nous penchons vers le choix de GlusterFS. >> Toujours à la suite de nos lectures, nous pensons partir sur une >> implémentation en "Distributed Replicated Volume" basée sur 2 briques >> (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) >> composées chacune d'au moins 2 noeuds (voire 4). >> >> Bien entendu, avant d'investir et de partir en production nous allons >> maquetter cela. >> Toutefois, on se dit que plusieurs d'entre nous ont surement testés cela >> voire même mis en oeuvre ce type de solution et pourraient nous faire >> gagner du temps voire nous suggérer d'autres implémentations. >> >> Du coup, comme vous l'avez surement compris nous sommes intéressé pour >> tout retour sur l'utilisation de GlusterFS, notamment sur les choix que >> vous avez pu faire. >> De même nous serions intéressé pour avoir des retours sur un couplage >> GlusterFS et ZFS. >> >> Si vous avez également des retours heureux sur d'autres systèmes de >> stockage distribué qui pourraient satisfaire nos besoins, nous sommes >> intéressés. >> >> Merci d'avance. >> >> Jérôme LE TANOU > > -- Pierre Schweitzer <pierre@reactos.org <mailto:pierre@reactos.org>> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
----- Mail original -----
De: "Pierre DOLIDON" sn4ky@sn4ky.net À: frsag@frsag.org Envoyé: Vendredi 12 Décembre 2014 14:30:01 Objet: Re: [FRsAG] Vos retours sur le stockage distribué / Glusterfs ?
Bonjour.
J'ai effectivement pu constater des bugs sur glusterfs, particulièrement sur des environnements web répliqués. Les serveurs partaient en sucette fréquemment. Cette histoire de NFS qui est assez pénible aussi.
Actuellement je bench une solution articulée autour de DRDB en primary/primary avec un filesystem OCFS2 par dessus (monté sur les 2 serveurs bien sur).
J'ai du DRDB actif/actif avec GFS2 dessus. L'arrêt d'une machine, voulu ou non implique invariablement un split brain qu'il faut résoudre manuellement !
J'ai par ailleurs une architecture avec GlusterFS en Distributed Replicated Volume. Je dois dire que ce n'est pas beaucoup mieux et que lorsque ça marche on n'y touche plus !
Je louche très fortement sur Ceph qui est en comparaison beaucoup plus stable (le début du développement de Ceph date de 2004). Je n'ai pas du tout testé CephFS dont la brique FS n'est pas supportée au delà d'un seul noeud (pour le moment).
Notez que lors de mes essais (avec du vieux matériel datant de 2005) Ceph a été performant avec des tailles de bloc importantes de l'ordre de 4Mo et 30x moins bon avec des tailles de bloc de 4ko.
A bientôt,
Olivier DELHOMME.
Quelqu'un a testé ca ?
Je suis tombé dessus lorsque j'ai refait un tour du web la dernière fois sur "distribued file system", et j'avoue que c'est pariel, si je m'en tiens au site internet et la présentation, je me dis que mes soucis de stockage sont enfin terminés (belle utopie :) )..
Sinon, j'ai aussi la partie stockage d'openstack à tester (mais j'ai peur d'avance..) . OVH n'a plus de soucis avec hubic depuis qu'ils ont basculé là-dessus d'après les bruits de couloir :)
je dérive un peu par rapport à ton besoin initial mais bon, une fois qu'on a un bon système clusterisé qui encaisse des To sur des To sans crainte... tu mets un point d'entrée NFS quelque part et t'es tranquille...
Le 12 décembre 2014 15:49, Olivier DELHOMME < olivier.delhomme@mines-paristech.fr> a écrit :
Bonjour,
----- Mail original -----
De: "Pierre DOLIDON" sn4ky@sn4ky.net À: frsag@frsag.org Envoyé: Vendredi 12 Décembre 2014 14:30:01 Objet: Re: [FRsAG] Vos retours sur le stockage distribué / Glusterfs ?
Bonjour.
J'ai effectivement pu constater des bugs sur glusterfs, particulièrement
sur
des environnements web répliqués. Les serveurs partaient en sucette fréquemment. Cette histoire de NFS qui est assez pénible aussi.
Actuellement je bench une solution articulée autour de DRDB en primary/primary avec un filesystem OCFS2 par dessus (monté sur les 2 serveurs bien sur).
J'ai du DRDB actif/actif avec GFS2 dessus. L'arrêt d'une machine, voulu ou non implique invariablement un split brain qu'il faut résoudre manuellement !
J'ai par ailleurs une architecture avec GlusterFS en Distributed Replicated Volume. Je dois dire que ce n'est pas beaucoup mieux et que lorsque ça marche on n'y touche plus !
Je louche très fortement sur Ceph qui est en comparaison beaucoup plus stable (le début du développement de Ceph date de 2004). Je n'ai pas du tout testé CephFS dont la brique FS n'est pas supportée au delà d'un seul noeud (pour le moment).
Notez que lors de mes essais (avec du vieux matériel datant de 2005) Ceph a été performant avec des tailles de bloc importantes de l'ordre de 4Mo et 30x moins bon avec des tailles de bloc de 4ko.
A bientôt,
Olivier DELHOMME.
Liste de diffusion du FRsAG http://www.frsag.org/
Quelqu'un a testé ca ?
Je suis tombé dessus lorsque j'ai refait un tour du web la dernière fois sur "distribued file system", et j'avoue que c'est pariel, si je m'en tiens
Perso j'utilise GlusterFS, facile à implémenter, permet aussi bien de faire du filesystem distribué que répliqué, ou dans le style "RAID 10", possibilité de faire un point de montage (comme nfs) avec plusieurs adresses IP, ce qui permet donc de rebooter les noeuds un après l'autre sans coupure de connexion ou de production.
amicalement,
Le 12/12/2014 16:04, Christophe Casalegno (Digital Network) a écrit :
... possibilité de faire un point de montage (comme nfs) avec plusieurs adresses IP, ce qui permet donc de rebooter les noeuds un après l'autre sans coupure de connexion ou de production.
Bonjour,
Le stack NFS intégré à GlusterFS m'a semblé aussi peu fiable que de balader une vIP entre les noueds avec des reexports en NFS "natif" sans conf...
En revanche (je l'ai calqué d'un gros exemple d'ailleurs, avec l'option "nfs.disable on" sur tous les volumes GlusterFS), avoir le /var/lib/nfs repliqué sur un volume gluster, et n'avoir qu'un serveur NFS tournant à la fois sur une vIP (downé/uppé par keepalived) s'est révélé nettement plus fiable, les clients basculent proprement, au pire avec 2 secondes de latence... jusqu'à hier où un client avec du AuFS temporaire (le temps de déplacer les données du local au nfs) m'a pété entre les mains alors que je mettais en place la solution définitive (il semble qu'on se soit tapé un vieux bug de charge en NFS-server)
Je ne suis pas certain que la root cause du souci soit gluster, ayant écarté la partie NFS de Gluster pour sa version native (exportant le montage local) et l'ayant trituré, rsyncé avec violence, iozone-benché dans tous les sens pendant des semaines.
Bon, c'était hier, aujourd'hui, pas touch, on verra la semaine prochaine pour downer proprement les services et éviter l'étape AuFS qui n'avait pour but que d'interchanger le montage à la volée pour ne pas impacter la prod, tant pis.
JaXX./.
Quelqu'un a testé ca ?
Je suis tombé dessus lorsque j'ai refait un tour du web la dernière fois sur "distribued file system", et j'avoue que c'est pariel, si je m'en tiens
Perso j'utilise GlusterFS, facile à implémenter, permet aussi bien de faire du filesystem distribué que répliqué, ou dans le style "RAID 10", possibilité de faire un point de montage (comme nfs) avec plusieurs adresses IP, ce qui permet donc de rebooter les noeuds un après l'autre sans coupure de connexion ou de production.
amicalement,
+1 J'utilise en prod GlusterFS 3.3 avec du BTRFS et le NFS de GlusterFS (en TCP) depuis 18 mois en distribué répliqué + Géo-réplication. Stockage de disque VM et petit fichier (site web, emails). Comme pour chaque système, il faut ce faire la main pour gérer les problèmes ... (9 mois de test avant la mise en production pour tester la stabilité et la gestion des incidents) La 3.5.0 au mois d'avril avait des pb de performance et d'occupation RAM, je n'ai pas testé depuis.
Hello, chez nous on a mis Glusterfs en place avec 3 clients. 1 succes complet et 2 fails. La seule raison du probleme. Acces concurrent au meme fichier. Glusterfs a beaucoup de mal avec les acces concurrents au meme fichier.
Dans les 2 cas de fail l'archi était extrement simple 2 nodes en replication. Mais nous avions 2 points d'entrée et des situations regulieres ou 2 machines tentaient d'écrire le meme fichier.
Dans le cas de succes nous avions un cluster de 5x2 nodes en replication mais avec un seul point d'entrée, zero panne ou erreurs alors que nous avions plus de 50To de musique dessus pour le client.
Concernant Ceph, cela semble tres prometteur mais la demande concerne de l'acces fichier NFS/CIFS donc POSIX je suppose et CephFS est bien indiqué dans sa doc comme n'étant pas production ready.
Cordialement
Le 13 décembre 2014 01:34, Maisonneuve Informatique <contact> < contact@maisonneuve-info.fr> a écrit :
Quelqu'un a testé ca ?
Je suis tombé dessus lorsque j'ai refait un tour du web la dernière fois sur "distribued file system", et j'avoue que c'est pariel, si je m'en tiens
Perso j'utilise GlusterFS, facile à implémenter, permet aussi bien de faire du filesystem distribué que répliqué, ou dans le style "RAID 10", possibilité de faire un point de montage (comme nfs) avec plusieurs adresses IP, ce qui permet donc de rebooter les noeuds un après l'autre sans coupure de connexion ou de production.
amicalement,
+1 J'utilise en prod GlusterFS 3.3 avec du BTRFS et le NFS de GlusterFS (en TCP) depuis 18 mois en distribué répliqué + Géo-réplication. Stockage de disque VM et petit fichier (site web, emails). Comme pour chaque système, il faut ce faire la main pour gérer les problèmes ... (9 mois de test avant la mise en production pour tester la stabilité et la gestion des incidents) La 3.5.0 au mois d'avril avait des pb de performance et d'occupation RAM, je n'ai pas testé depuis.
Liste de diffusion du FRsAG http://www.frsag.org/
RBD pipe NFS: http://ceph.com/docs/master/rbd/rbd/
On 13/12/2014 12:11, Sébastien FOUTREL wrote:
Concernant Ceph, cela semble tres prometteur mais la demande concerne de l'acces fichier NFS/CIFS donc POSIX je suppose et CephFS est bien indiqué dans sa doc comme n'étant pas production ready.
Cordialement
Tant qu'à faire du distribué avec beaucoup de petits fichiers: LUSTRE.
Le 13 décembre 2014 13:27, frsag@jack.fr.eu.org a écrit :
RBD pipe NFS: http://ceph.com/docs/master/rbd/rbd/
On 13/12/2014 12:11, Sébastien FOUTREL wrote:
Concernant Ceph, cela semble tres prometteur mais la demande concerne de l'acces fichier NFS/CIFS donc POSIX je suppose et CephFS est bien indiqué dans sa doc comme n'étant pas production ready.
Cordialement
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." - Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
----- Mail original -----
De: "RegisM" regis.frsag@tornad.net À: "Olivier DELHOMME" olivier.delhomme@mines-paristech.fr Cc: "Pierre DOLIDON" sn4ky@sn4ky.net, "French SysAdmin Group" frsag@frsag.org Envoyé: Vendredi 12 Décembre 2014 15:58:04 Objet: Re: [FRsAG] Vos retours sur le stockage distribué / Glusterfs ?
Quelqu'un a testé ca ?
Je suis tombé dessus lorsque j'ai refait un tour du web la dernière fois sur "distribued file system", et j'avoue que c'est pariel, si je m'en tiens au site internet et la présentation, je me dis que mes soucis de stockage sont enfin terminés (belle utopie :) )..
Je n'ai pas testé. Dans le principe, il y a toujours une différenciation metadata et données ce qui peut potentiellement être un goulot d'étranglement.
Sinon, j'ai aussi la partie stockage d'openstack à tester (mais j'ai peur d'avance..) . OVH n'a plus de soucis avec hubic depuis qu'ils ont basculé là-dessus d'après les bruits de couloir :)
Openstack se couple apparemment très bien avec Ceph... (mais c'est pas pour du système de fichier "classique" /home de 200 To !)
je dérive un peu par rapport à ton besoin initial mais bon, une fois qu'on a un bon système clusterisé qui encaisse des To sur des To sans crainte... tu mets un point d'entrée NFS quelque part et t'es tranquille...
Je me pose la question de xtreemfs over rbd (Ceph)...
@+,
Olivier.
Le 12 décembre 2014 15:49, Olivier DELHOMME < olivier.delhomme@mines-paristech.fr> a écrit :
Bonjour,
----- Mail original -----
De: "Pierre DOLIDON" sn4ky@sn4ky.net À: frsag@frsag.org Envoyé: Vendredi 12 Décembre 2014 14:30:01 Objet: Re: [FRsAG] Vos retours sur le stockage distribué / Glusterfs ?
Bonjour.
J'ai effectivement pu constater des bugs sur glusterfs, particulièrement
sur
des environnements web répliqués. Les serveurs partaient en sucette fréquemment. Cette histoire de NFS qui est assez pénible aussi.
Actuellement je bench une solution articulée autour de DRDB en primary/primary avec un filesystem OCFS2 par dessus (monté sur les 2 serveurs bien sur).
J'ai du DRDB actif/actif avec GFS2 dessus. L'arrêt d'une machine, voulu ou non implique invariablement un split brain qu'il faut résoudre manuellement !
J'ai par ailleurs une architecture avec GlusterFS en Distributed Replicated Volume. Je dois dire que ce n'est pas beaucoup mieux et que lorsque ça marche on n'y touche plus !
Je louche très fortement sur Ceph qui est en comparaison beaucoup plus stable (le début du développement de Ceph date de 2004). Je n'ai pas du tout testé CephFS dont la brique FS n'est pas supportée au delà d'un seul noeud (pour le moment).
Notez que lors de mes essais (avec du vieux matériel datant de 2005) Ceph a été performant avec des tailles de bloc importantes de l'ordre de 4Mo et 30x moins bon avec des tailles de bloc de 4ko.
A bientôt,
Olivier DELHOMME.
Liste de diffusion du FRsAG http://www.frsag.org/
Testé il y a 3 ans, GlusterFS n'a jamais passé le cap de la maquette chez moi. Sur le papier, c'est l'outil parfait dont tout le monde rêve, en réalité, c'est un gros bouzin qui n'en fait qu'a sa tête à base de surcouche applicative plus opaque les unes que les autres...
par exemple à base d'elasticsearch
Comment ca se passe la réplication et reconstruction sur de gros volumes de données comme ce qu'il veut traiter ? Parceque c'est plus adapté pour de la donnée flat/json que du fichier...
Dans le même genre, J'avais envie de monter un lab avec du couchdb (qui gère les attachements/medias avec le document JSON) mais j'ai lu (1 fois :) que sur la syncrho avec bcq de gros attachements ca s'effondre... Les "clusters NOSQL" sont super pour la simplicité de mise en oeuvre mais pas forcément adapté à du binaire..
Le 12 décembre 2014 13:37, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
J'ai testé GlusterFS en production, ce fus une très mauvaise expérience. Ceph était beaucoup plus stable même si j'ai eu quelques trucs bizarres. Au final on utilise ce bon vieux NFSv4 qui est le plus mauvais niveau performance, mais le plus stable ...
Aujourd'hui, si possible, je pense que je partirais sur une solution très différente, par exemple à base d'elasticsearch qui est ultra-stable, performant, scalable, un bonheur pour les sysadmins, mais qui nécessite plus d'adaptation coté application.
Greg
Le 12 décembre 2014 13:21, Pierre Schweitzer pierre@reactos.org a écrit :
Bonjour,
On 12/12/2014 12:32 PM, frsag@jack.fr.eu.org wrote:
glusterfs ne m'a pas donné l'impression d'être un projet "qui a classe". J'ai plutôt eu l'impression d'avoir une paire de script, qui marchent, mais pas trop
C'est un peu ça oui. Pour avoir utilisé GlusterFS pendant un temps certain en production, c'est extrêment chaotique avec des situations où GlusterFS refuse purement et simplement de fonctionner sans messages d'erreurs d'aucune sorte nul part.
Sans compter des applications qui finissent en D sur le GluterFS sans vraiment de raisons connues. Ce qui grève fortement les performances et la stabilité de l'ensemble.
À noter également l'incompatibilité entre le NFS server utilisé par la distribution et celui de GlusterFS (si si) qui peut mener à de sacrés sketchs lorsque vous exportez du NFS hors de GlusterFS.
Bref, autant dire que les backups ont servi plusieurs fois...
Je déconseille fortement en production.
On 12/12/2014 12:14, Jerome LE TANOU wrote:
Bonjour,
- Nous souhaitons mettre un oeuvre une solution de stockage d'au moins
200To utiles qui seront accédés en mode fichiers (NFS, CIFS).
- Il faudrait que l'on puisse disposer d'une redondance permettant de
pallier à la panne d'un ou plusieurs disques ou d'un noeud.
- Il est acceptable d'avoir une interruption de service pour redémarrer
le service en cas de panne majeure dans la limite de 4H.
- A noter qu'actuellement nos utilisateurs utilisent énormément de
petits fichiers (plus de 400 millions de fichiers de moins de 128ko).
- A noter que pour convenance du service, les systèmes hôtes seront
sous
Debian.
Au vue des différents articles, documentations que nous avons consulté, nous penchons vers le choix de GlusterFS. Toujours à la suite de nos lectures, nous pensons partir sur une implémentation en "Distributed Replicated Volume" basée sur 2 briques (qui seront hébergées sur 2 sites distants interconnectés en 10Gbps) composées chacune d'au moins 2 noeuds (voire 4).
Bien entendu, avant d'investir et de partir en production nous allons maquetter cela. Toutefois, on se dit que plusieurs d'entre nous ont surement testés
cela
voire même mis en oeuvre ce type de solution et pourraient nous faire gagner du temps voire nous suggérer d'autres implémentations.
Du coup, comme vous l'avez surement compris nous sommes intéressé pour tout retour sur l'utilisation de GlusterFS, notamment sur les choix que vous avez pu faire. De même nous serions intéressé pour avoir des retours sur un couplage GlusterFS et ZFS.
Si vous avez également des retours heureux sur d'autres systèmes de stockage distribué qui pourraient satisfaire nos besoins, nous sommes intéressés.
Merci d'avance.
Jérôme LE TANOU
-- Pierre Schweitzer pierre@reactos.org System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Testé il y a 3 ans, GlusterFS n'a jamais passé le cap de la maquette chez moi. Sur le papier, c'est l'outil parfait dont tout le monde rêve, en réalité, c'est un gros bouzin qui n'en fait qu'a sa tête à base de surcouche applicative plus opaque les unes que les autres...
Même retour ici. Ma préference va à Ceph dans la catégorie des FS distribués.
Bonjour,
Nous utilisons GlusterFS en production ici. Pas vraiment de souci en version 3.3 (par contre grosse galère a mettre a jour de 3.2 a 3.3) mais on sens bien qu'il ne faut pas trop le pousser. Pour des serveurs web répliqués, sur de petits volumes pas de souci, par contre pour répliquer nos cours en ligne sur Moodle, on sens bien qu'on est à la limite.
Cordialement,
Le 12/12/2014 15:23, Denis Fondras a écrit :
Testé il y a 3 ans, GlusterFS n'a jamais passé le cap de la maquette chez moi. Sur le papier, c'est l'outil parfait dont tout le monde rêve, en réalité, c'est un gros bouzin qui n'en fait qu'a sa tête à base de surcouche applicative plus opaque les unes que les autres...
Même retour ici. Ma préference va à Ceph dans la catégorie des FS distribués. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'ai essayé GlusterFS et j'ai eu une mauvaise expérience donc je ne peux pas vraiment te le conseiller
Par contre j'ai tenté MooseFS (http://www.moosefs.org/) il était pas hyper performant sur les petit fichiers mais ça convenait relativement bien pour notre utilisation à l'époque et je n'ai pas eu de grosses surprises
Ceph je n'ai pas pu testé en profondeur mais j'ai fort entendu parler ça bouge beaucoup de ce coté donc je te conseillerai de bien le regardé également
Voila pour mon retour
Bonsoir,
2014-12-12 15:56 GMT+01:00 Sebastien Caps sebastien.caps@guardis.com:
Par contre j'ai tenté MooseFS (http://www.moosefs.org/) il était pas hyper performant sur les petit fichiers mais ça convenait relativement bien pour notre utilisation à l'époque et je n'ai pas eu de grosses surprises
Je confirme. MooseFS est en prod chez nous depuis 3 ou 4 ans : aucun incident, ça "juste marche". Même en cas de panne sur un des disques ou sur tout un noeud de stockage. Par contre ce n'est pas vraiment fait pour les petits fichiers (les metadata explosent vite en taille, et tout est stocké en RAM). Niveaux i/o en effet ce n'est pas ultime, mais pour du backup c'est juste merveilleux.
Fabien
On Fri, Dec 12, 2014 at 07:40:06PM +0100, Fabien Germain wrote:
Bonsoir,
2014-12-12 15:56 GMT+01:00 Sebastien Caps sebastien.caps@guardis.com:
Par contre j'ai tenté MooseFS (http://www.moosefs.org/) il était pas hyper performant sur les petit fichiers mais ça convenait relativement bien pour notre utilisation à l'époque et je n'ai pas eu de grosses surprises
Je confirme. MooseFS est en prod chez nous depuis 3 ou 4 ans : aucun incident, ça "juste marche". Même en cas de panne sur un des disques ou sur tout un noeud de stockage. Par contre ce n'est pas vraiment fait pour les petits fichiers (les metadata explosent vite en taille, et tout est stocké en RAM). Niveaux i/o en effet ce n'est pas ultime, mais pour du backup c'est juste merveilleux.
Un peu plus de 2 ans ici, pour un archivage (2 ou 3 copies). Je confirme, les metadata sont rapides (backup via rsync, et c'est plutôt bon). Par contre on va maintenant expérimenter le changement de serveur de métadata qui est un peu plein 14GO sur 16GO de RAM... et la montée de version en 2.x.
Info total avail trash trash reserved reserved all fs all chunk regular version RAM used space space space files space files objects directories files chunks copies chunk copies 1.6.27 14 GiB 59 TiB 10 TiB 0 B 0 0 B 0 39618596 2068979 36302527 35880569 91983226 91983226
All chunks state matrix (counts 'regular' hdd space and 'marked for removal' hdd space : switch to 'regular') goal valid copies 0 1 2 3 4 5 6 7 8 9 10+ all 0 - - - - - - - - - - - 0 1 - - - - - - - - - - - 0 2 - - 15658481 - - - - - - - - 15658481 3 - - - 20222088 - - - - - - - 20222088 4 - - - - - - - - - - - 0 ... 10+ - - - - - - - - - - - 0 all 1+ 0 0 15658481 20222088 0 0 0 0 0 0 0 35880569 - missing (0) / - endangered (0) / - undergoal (0) / - stable (35880569) / - overgoal (0) / - pending deletion (0) /
Tru
-
Christophe Casalegno (Digital Network) -
Denis Fondras -
Fabien Germain -
frsag＠jack.fr.eu.org -
Greg -
Jean-Marie Verdun -
Jerome LE TANOU -
Julien (JaXX) Banchet -
Maisonneuve Informatique <contact> -
Méhdi Denou -
Olivier DELHOMME -
Pierre DOLIDON -
Pierre Schweitzer -
RegisM -
Sebastien Caps -
sylvain Costard -
Sébastien FOUTREL -
Tru Huynh