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-fr...@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 <pie...@reactos.org> a écrit
> :
>
>> Bonjour,
>>
>> On 12/12/2014 12:32 PM, fr...@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 <pie...@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/
>
>
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à