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> 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/