Bonjour,
aujourd'hui pour le stockage centralisé de plusieurs 100ène de millions de fichiers, j'utilise 2 serveurs redondants NFSv4 (heatbeat), les serveurs clients montent leurs partitions sur un de ces 2 serveurs, le master heartbeat. Et ça marche très bien, les perfs sont convenables. Problème, en cas de coupure brutale (électrique) du serveur principale, les clients retentent de se connecter indéfiniment sans fermer la socket, du coup ils ne se connectent jamais sur le serveur secondaire qui est passé maitre. Les points de montages ne sont pas démontables, la seule solution parfois consiste à rebooter tous les serveurs clients :(
On trouve plusieurs explications de ce phénomène :
- http://serverfault.com/questions/20465/nfs-v4-ha-migration-and-stale-handles...http://serverfault.com/questions/20465/nfs-v4-ha-migration-and-stale-handles-on-clients - http://www.linux-ha.org/HaNFS http://www.linux-ha.org/HaNFS - http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg06267.htmlhttp://www.mail-archive.com/git-commits-head@vger.kernel.org/msg06267.html
RFC3530 section 3.1.1 states an NFSv4 client MUST NOT send a request twice on the same connection unless it is the NULL procedure. Section 3.1.1 suggests that the client should disconnect and reconnect if it wants to retry a request.
- http://bugzilla.linux-nfs.org/show_bug.cgi?id=6http://bugzilla.linux-nfs.org/show_bug.cgi?id=6
J'ai 2 solutions: essayer de trouver des bidouilles (sysctl -w net.ipv4.tcp_fin_timeout=10, synchro de /var/lib/nfs ...) ou trouver et migrer vers un système de fichiers distribué éprouvé.
GlusterFS est sexy sur le papier, mais en prod il est buggé, instable, et j'ai eu pas mal de comportements bizarres (fichiers présent sur certains serveurs). Et pourtant j'ai joué avec pendant quasiment 1 an avec 2 noeuds et 10 clients.
Ceph (http://ceph.newdream.net/) a l'air super prometteur mais super jeune... Je n'ai pas envie de perdre à nouveau du temps comme avec GlusterFS.
Il en existe d'autres: POHMELFS par exemple...
Si vous avez des retours d'expériences sur un de ces FS en environnement chargé (beaucoup d'IO) ça m'aiderait.
-- Greg
2010/7/18 Greg greg-frsag@duchatelet.net:
Bonjour,
<zip>
Greg
Bonjour, J'avoue que je ne me suis jamais lancé dans ce genre de travaux, mais quelques points me viennent à l'esprit :
* Dans une même phrase, j'ai rarement entendu système de fichier distribué sans entendre également DRBD dans celle-ci. Je ne l'ai pas testé ; peut être est elle déjà éliminée par le fait que tu demandes à avoir bcp d'IO. * Une solution pourrait être inspirée de LVS en mode DSR : les deux machines affichent la même IP, et le heartbeat active ou désactive le ARP announce/ignore de la machine en mode "slave", de manière à ce qu'elle ne réponde pas en ARP jusqu'à ce que l'autre ne réponde plus. Dès lors, tes clients vont demander en boucle jusqu'à ce que le cache ARP soit invalidé, qu'une nouvelle requête soit lancée, et ta machine secondaire annoncera tranquille sa MAC. Tu as alors un downtime d'une durée égale au cache arp, et tes clients ne sont pas rebootés. Il devrait également il y avoir moyen de jouer au niveau de BGP pour rerouter les packets vers le second noeud, avec une modification de la route dynamique via le heartbeat, mais ca commence à toucher à du réseau, et là, ca me dépasse :p
J'en profite pour squatter le thread à propos de NFSv4 : l'utilises tu sous Linux ? Est ce stable désormais ? La dernière fois que j'ai regardé, il y a un an, on m'a dit que seule l'implémentation sous BSD était potable.
Cordialement, Florian MAURY
2010/7/18 Florian MAURY pub-frsag@x-cli.com:
2010/7/18 Greg greg-frsag@duchatelet.net:
Bonjour,
<zip> > Greg
Bonjour, J'avoue que je ne me suis jamais lancé dans ce genre de travaux, mais quelques points me viennent à l'esprit :
- Dans une même phrase, j'ai rarement entendu système de fichier
distribué sans entendre également DRBD dans celle-ci. Je ne l'ai pas testé ; peut être est elle déjà éliminée par le fait que tu demandes à avoir bcp d'IO.
- Une solution pourrait être inspirée de LVS en mode DSR : les deux
machines affichent la même IP, et le heartbeat active ou désactive le ARP announce/ignore de la machine en mode "slave", de manière à ce qu'elle ne réponde pas en ARP jusqu'à ce que l'autre ne réponde plus. Dès lors, tes clients vont demander en boucle jusqu'à ce que le cache ARP soit invalidé, qu'une nouvelle requête soit lancée, et ta machine secondaire annoncera tranquille sa MAC. Tu as alors un downtime d'une durée égale au cache arp, et tes clients ne sont pas rebootés. Il devrait également il y avoir moyen de jouer au niveau de BGP pour rerouter les packets vers le second noeud, avec une modification de la route dynamique via le heartbeat, mais ca commence à toucher à du réseau, et là, ca me dépasse :p
J'en profite pour squatter le thread à propos de NFSv4 : l'utilises tu sous Linux ? Est ce stable désormais ? La dernière fois que j'ai regardé, il y a un an, on m'a dit que seule l'implémentation sous BSD était potable.
Cordialement, Florian MAURY
Je retire ce que j'ai dit que l'arp et l'annoncing... C'était n'importe quoi !
Nuit difficile, viens de me lever =)
Dsl :)
Florian MAURY
Bonsoir,
J'en profite pour squatter le thread à propos de NFSv4 : l'utilises tu
sous Linux ? Est ce stable désormais ? La dernière fois que j'ai regardé, il y a un an, on m'a dit que seule l'implémentation sous BSD était potable.
J'utilise la version 4.0 qui est stable, sur Debian Lenny, c'est en prod depuis 8 mois et je n'ai constaté aucun problème (contrairement à GlusterFS), mise à part celui évoqué par ce sujet.
Tu stockes quel genre de données ? taille ?
Car en fonction de ça, tu pourrais trouver ton bonheur là : http://hadoop.apache.org/
Pour les logs tu as Hive, pour du FS simple tu as HDFS, et pour designer des appli au dessus de tout ça, MapReduce te permet de sortir de bonnes perfs parmis des millions d'entrées clé/valeur.
Testé et éprouvé.
Le seul truc, c'est que ça jacte pas mal donc les switch en oversubscription tu peux les oublier.
Et même guiguiabloc en parle ;) http://blog.guiguiabloc.fr/index.php/2009/11/12/hadoop-doop-doop-doop/
Si tes données sont très légères, tu peux même les stocker dans zookeeper ;)
Dans la cas contraire, tu as des alternatives comme voldemort ou cassandra, mais encore une fois ça dépend de ce que tu veux stocker...
2010/7/18 Greg greg-frsag@duchatelet.net
Bonjour,
aujourd'hui pour le stockage centralisé de plusieurs 100ène de millions de fichiers, j'utilise 2 serveurs redondants NFSv4 (heatbeat), les serveurs clients montent leurs partitions sur un de ces 2 serveurs, le master heartbeat. Et ça marche très bien, les perfs sont convenables. Problème, en cas de coupure brutale (électrique) du serveur principale, les clients retentent de se connecter indéfiniment sans fermer la socket, du coup ils ne se connectent jamais sur le serveur secondaire qui est passé maitre. Les points de montages ne sont pas démontables, la seule solution parfois consiste à rebooter tous les serveurs clients :(
On trouve plusieurs explications de ce phénomène :
http://serverfault.com/questions/20465/nfs-v4-ha-migration-and-stale-handles...http://serverfault.com/questions/20465/nfs-v4-ha-migration-and-stale-handles-on-clients
http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg06267.htmlhttp://www.mail-archive.com/git-commits-head@vger.kernel.org/msg06267.html
RFC3530 section 3.1.1 states an NFSv4 client MUST NOT send a request twice on the same connection unless it is the NULL procedure. Section 3.1.1 suggests that the client should disconnect and reconnect if it wants to retry a request.J'ai 2 solutions: essayer de trouver des bidouilles (sysctl -w net.ipv4.tcp_fin_timeout=10, synchro de /var/lib/nfs ...) ou trouver et migrer vers un système de fichiers distribué éprouvé.
GlusterFS est sexy sur le papier, mais en prod il est buggé, instable, et j'ai eu pas mal de comportements bizarres (fichiers présent sur certains serveurs). Et pourtant j'ai joué avec pendant quasiment 1 an avec 2 noeuds et 10 clients.
Ceph (http://ceph.newdream.net/) a l'air super prometteur mais super jeune... Je n'ai pas envie de perdre à nouveau du temps comme avec GlusterFS.
Il en existe d'autres: POHMELFS par exemple...
Si vous avez des retours d'expériences sur un de ces FS en environnement chargé (beaucoup d'IO) ça m'aiderait.
-- Greg
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Le 18 juillet 2010 14:40, Steven Le Roux <steven+frsag@le-roux.infosteven%2Bfrsag@le-roux.info
a écrit :
Tu stockes quel genre de données ? taille ?
Que des petits fichiers: de quelques ko à moins de 1Mo. Ils sont énormément accédé en lecture. Une partie concerne les fichiers de cache avec durée de vie variable, d'une minute à un jour. Enfin j'ai environ 2Go en 6 fichiers.
Car en fonction de ça, tu pourrais trouver ton bonheur là : http://hadoop.apache.org/
Ca me parait un peu gros pour ce que je veux faire: je n'ai pas besoin de beaucoup de capa, mais de beaucoup d'inodes et de read IO. Je vais mettre cette solution dans les tiroirs, pour quand on aura doublé le traffic ;)
Salut,
Pour un projet de FS distribué à travers du WAN (une node à London et une à Madrid), j'ai tenté GlusterFS... Après quelques bugs vite corrigés par les dév, la situation est stable mais loin d'être performante... En fait, chaque node client écrit sur les nodes serveurs et attends que chaque écriture soit validée avant de passer à la suivante (Fonctionnement SYNCHRONE), bref, ça limite un max les IOs.... GlusterFS en mode mirror ne sait pas encore fonctionner en mode ASYNCHRONE, alors je vais devoir changer. Je vais passer à du NFS pour livrer les fichiers aux clients locaux et utiliser csync2 + incron (cron like basée sur évênement inotify). Ca simule un mode "asynchrone", c'est rapide en local via NFS, et la synchronisation des données se fera cryptée :)
a+
2010/7/18 Greg greg-frsag@duchatelet.net
Le 18 juillet 2010 14:40, Steven Le Roux <steven+frsag@le-roux.infosteven%2Bfrsag@le-roux.info
a écrit :
Tu stockes quel genre de données ? taille ?
Que des petits fichiers: de quelques ko à moins de 1Mo. Ils sont énormément accédé en lecture. Une partie concerne les fichiers de cache avec durée de vie variable, d'une minute à un jour. Enfin j'ai environ 2Go en 6 fichiers.
Car en fonction de ça, tu pourrais trouver ton bonheur là : http://hadoop.apache.org/
Ca me parait un peu gros pour ce que je veux faire: je n'ai pas besoin de beaucoup de capa, mais de beaucoup d'inodes et de read IO. Je vais mettre cette solution dans les tiroirs, pour quand on aura doublé le traffic ;)
-- Greg
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Le 18/07/2010 14:40, Steven Le Roux a écrit :
Tu stockes quel genre de données ? taille ?
Car en fonction de ça, tu pourrais trouver ton bonheur là : http://hadoop.apache.org/
Pour les logs tu as Hive, pour du FS simple tu as HDFS, et pour designer des appli au dessus de tout ça, MapReduce te permet de sortir de bonnes perfs parmis des millions d'entrées clé/valeur.
Testé et éprouvé.
Le seul truc, c'est que ça jacte pas mal donc les switch en oversubscription tu peux les oublier.
Et même guiguiabloc en parle ;) http://blog.guiguiabloc.fr/index.php/2009/11/12/hadoop-doop-doop-doop/
Si tes données sont très légères, tu peux même les stocker dans zookeeper ;)
Ta réponse me fait rebondir sur un autre sujet : je vais peut-etre avoir besoin de stocker quelques milliards d'objets de petite taille (~1ko), soit plusieurs tera octets de données. Memcached est très bien mais ça me couterait cher en RAM, il faut donc un système sur disque, et distribué toujours pour les mêmes problèmes de haute-dispo. Quels systèmes vous viennent à l'esprit ?
2010/7/19 Greg greg-frsag@duchatelet.net:
Ta réponse me fait rebondir sur un autre sujet : je vais peut-etre avoir besoin de stocker quelques milliards d'objets de petite taille (~1ko), soit plusieurs tera octets de données. Memcached est très bien mais ça me couterait cher en RAM, il faut donc un système sur disque, et distribué toujours pour les mêmes problèmes de haute-dispo. Quels systèmes vous viennent à l'esprit ?
Hello, Je vais dire un gros mot mais ... une base de données ? (ceci n'est pas un troll, ceci n'est pas un troll, ceci n'est pas un troll)
Après, pour éviter des index qui font des GB, tu peux faire du sharding, tout dépend les données et leur organisation.
Florian MAURY
2010/7/19 Greg greg-frsag@duchatelet.net
Le 18/07/2010 14:40, Steven Le Roux a écrit :
Tu stockes quel genre de données ? taille ?
Car en fonction de ça, tu pourrais trouver ton bonheur là : http://hadoop.apache.org/
Pour les logs tu as Hive, pour du FS simple tu as HDFS, et pour designer des appli au dessus de tout ça, MapReduce te permet de sortir de bonnes perfs parmis des millions d'entrées clé/valeur.
Testé et éprouvé.
Le seul truc, c'est que ça jacte pas mal donc les switch en oversubscription tu peux les oublier.
Et même guiguiabloc en parle ;) http://blog.guiguiabloc.fr/index.php/2009/11/12/hadoop-doop-doop-doop/
Si tes données sont très légères, tu peux même les stocker dans zookeeper ;)
Ta réponse me fait rebondir sur un autre sujet : je vais peut-etre avoir besoin de stocker quelques milliards d'objets de petite taille (~1ko), soit plusieurs tera octets de données. Memcached est très bien mais ça me couterait cher en RAM, il faut donc un système sur disque, et distribué toujours pour les mêmes problèmes de haute-dispo. Quels systèmes vous viennent à l'esprit ?
Voldemort :)
Memcached ça a effectivement de bonnes perfs mais la réplication est trop récente pour être utilisée en prod je trouve (je ne suis même pas sûr que ce soit totalement implémenté même), ce qui fait que tu te retrouves souvent avec un memcached par app/base. Voldemort te fournit une infra de stockage de donnée
Les perfs de voldemort sont comparables à celles de memcached. C'est un service comparable à Amazon Dynamo.
Par contre il faut le gérer côté applicatif et que tes données soient organisables en key/value.
Après dans le principe, la théorie avec le hashring, etc... est plus buvable que zookeeper avec son implémentation de paxos :) ( http://en.wikipedia.org/wiki/Paxos_algorithm) que je conseille de ne PAS lire ;)
--
Greg
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Le 19/07/2010 14:00, Steven Le Roux a écrit :
Ta réponse me fait rebondir sur un autre sujet : je vais peut-etre avoir besoin de stocker quelques milliards d'objets de petite taille (~1ko), soit plusieurs tera octets de données. Memcached est très bien mais ça me couterait cher en RAM, il faut donc un système sur disque, et distribué toujours pour les mêmes problèmes de haute-dispo. Quels systèmes vous viennent à l'esprit ?Voldemort :)
Désolé, j'ai abusé de la liste alors que comme souvent, certains sysadmin ont déjà rencontré le problème et fait un comparatif :
http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-s...
Parenthèse close ;)
Hello,
2010/7/18 Greg greg-frsag@duchatelet.net
GlusterFS est sexy sur le papier, mais en prod il est buggé, instable, et j'ai eu pas mal de comportements bizarres (fichiers présent sur certains serveurs). Et pourtant j'ai joué avec pendant quasiment 1 an avec 2 noeuds et 10 clients.
Ceph (http://ceph.newdream.net/) a l'air super prometteur mais super jeune... Je n'ai pas envie de perdre à nouveau du temps comme avec GlusterFS.
Dans le même style, mais qui est par contre déjà utilisable en production (contrairement à Ceph), tu as MooseFS (http://www.moosefs.org/) : filesystem distribué et redondant, c'est sexy. Les données sont réparties, et répliquées, sur x machines, et un serveur mfsmaster gère les métadonnées : Le SPOF dans cette infra c'est évidemment ce master qui contient les métadonnées... mais il est redondable (réplication en live sur un autre serveur, à la manière de MySQL). Et en cas de crash, tu bascules sur le slave avec Heartbeat. Le seul "hic" : c'est du userland, donc accès au filesystem via FUSE.
Fabien
-
Bedis 9 -
Fabien Germain -
Florian MAURY -
Greg -
Steven Le Roux -
Steven Le Roux