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/