Architecture trois tiers scalable
Salut, Je travaille actuellement à la conception d'une architecture en trois tiers qui devra être scalable. * Architecture logique simplifiée : ----------- | Clients | ----------- ---------- | | DNS RR | REST HTTP (GET, POST, XML dans le BODY) ---------- | ------------------------- | Cluster des services | ------------------------- | | ------------------ --------------- | NoSQL cluster | | DFS cluster | ------------------ --------------- |________________| NoSQL peut être Cassandra ou Hbase ou éventuellement mongodb ou couchdb. DFS (Distributed File System) comme PVFS2, XtreemFS, HDFS. * Architecture physique simplifiée : Ça n'aura échapper à personne c'est une architecture SOA distribuée comme on en trouve chez Google, Facebook, Amazon et compagnie :) 1) Routage des requêtes HTTP clients : Elle est effectuée par les serveurs DNS sur des critères comment la géolocalisation, la disponibilité, la charge des serveurs de services. Je suis preneur d'information et de retour d'expérience sur toute implémentation de ce type de serveur DNS (REST étant stateless, autant en profiter pour éviter de mettre en place du load balancing sur la couche de transport, c'est tellement mieux et plus simple sans :)) 2) Cluster de services : Leur boulot est de satisfaire les requêtes des clients via du REST HTTP, de les filtrer un peu également si besoin (authentification et ACL par HMAC-SHA1, HMAC-MD5, etc.), de faire du push en XML si besoin. C'est pas du distribué au sens strict du terme (mais c'est pas loin, disons que les données nécessaires à la reprise d'une session ne sont pas réparties intelligemment entre les nœuds mais juste copiées sur chaque nœuds et les calculs sont locaux à un nœud), leur localisation sera différente pour éviter les SPoF. Le framework JBoss est pré-senti. Cette brique fonctionnelle représente la brique métier et implémente la couche d'abstraction nécessaire à la manipulation des données pour les clients (lecture, écriture, modification, le tout en fonction des types de données). Elle implémente de fait le worflow. Le type des échanges avec le dernier tiers seront dépendants du choix des logiciels qui vont le composer (MapReduce ou pas ?) ... Il sera composé de serveur relativement costaud (~20000 MIPS) et du périphérique blocs rapides et redondés. 2 Ethernet 1000BaseT. 3) Cluster de données/stockage : Pourquoi donc est ce que il y a du DFS et du NoSQL ? J'en suis pas bien sur moi même mais il y a des chances que des limitation de taille dans la partie NoSQL ne permette pas s'insérer directement une vidéo HD de 15 Go. Et suivant le choix du logiciel qui fait du NoSQL, il lui faudra un accès à un FS. Le type de cluster ici est composé de machines d'entrée de gamme avec un unique périphérique de type bloc le plus rapide possible (SSD), de trois cartes réseaux 1000BaseT si possible multiqueue (communication entre nœuds par trunking éventuel, communication avec le tiers supérieur). Les réseaux des communications internes aux cluster par type de nœuds seront dans un VLAN différent si sur même site physique. Le paradigme de fonctionnement des DFS est sensiblement le même : des nœuds pour maintenir les métadonnées et la distribution des calculs nécessaires pour la phase "gather" vers les nœuds qui hébergent les blocs qui composent un fichier pour le "servir", idem (ou presque) pour les écritures. Vu du tiers supérieur, c'est un FS, vu des nœuds NoSQL aussi. Pour les NoSQL distribués, je suis preneur de retour d'expérience et de conseils, j'ai zéro expérience avec contrairement à certains DFS (Column Families, Key Value / Tuple Store, Document Store, etc.) ... Cette partie fait du vrai distribué au sens strict (tout est repartie entre les nœuds, calcul aussi sur un DFS ou un NoSQL distribué digne de ce nom), scalable à souhait. rockscluster est pré-senti pour son administration et sa mise en place (réalisation de rool spécifique nécessaire). Le cœur de réseau sera de l'Ethernet 1000BaseT, j'ai pas encore creusé la question en détail ... * Les principes architecturaux : Règles d'or pour la HA : -> Répartition sur au moins deux sites des nœuds par type, le NoSQL et le DFS devra être capable de le gérer. -> Redondance des DNS internes et externes sur plusieurs AS pour les externes, primaires et secondaires. -> Cœur de réseau Ethernet redondée pour les communications locales et inter-tiers sur même site physique. Règle d'or pour la scalabilité des tiers 2 et 3 : -> Totalement distribué : calcul, stockage, etc. -> L'ajout de nœuds étend la capacité de calcul, de stockage, etc (pour le tiers 2, je la viole légèrement). -> Cœur de réseau Ethernet qui garantie du PPS (je dois encore calculer combien) Les attentes en temps de réponse sont très bas pour des tests unitaires fait en local, de l'ordre d'une seconde pour une écriture de 2Mo, et moins en lecture. Merci d'avance pour vos réponses. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Bonjour, Le 26/08/2010 23:45, Jerome Benoit a écrit :
Salut,
Je travaille actuellement à la conception d'une architecture en trois tiers qui devra être scalable.
et tu veux qu'on fasse tout ton travail :-P
3) Cluster de données/stockage :
Une fois de plus : Ceph http://ceph.newdream.net/ (et j'aimerais bien que quelqu'un fasse le 1er pas ! :) ) Une fois de plus: évitez (ou test et bench bien) GlusterFS.
Pour les NoSQL distribués, je suis preneur de retour d'expérience et de conseils, j'ai zéro expérience avec contrairement à certains DFS (Column Families, Key Value / Tuple Store, Document Store, etc.) ...
Sphinx : on a testé en prod, ça fonctionnait bien, et avec quelques K$ tu peux demander des nouvelles features au développeur russe, très efficace (1 semaine) et pas buggé. Grace a Sphinx on a divisé par 4 le nombre de serveurs nécessaires, et améliorer le temps de réponse par plus de 100 ! Pour améliorer encore les perfs, on a fait notre propre moteur: l'index est stocké en ram, full scan a chaque fois mais temps de réponse de fou, et ça ne consomme que du "bon" cpu. Prochaine étape: la même chose avec des cartes graphiques ou FPGA :) -- Greg
On 27/08/10 10:50, Greg wrote:
3) Cluster de données/stockage :
Une fois de plus : Ceph http://ceph.newdream.net/ (et j'aimerais bien que quelqu'un fasse le 1er pas ! :) )
sérieusement ? http://ceph.newdream.net/wiki/ "Ceph is under heavy development, and is not yet suitable for any uses other than benchmarking and review."
Une fois de plus: évitez (ou test et bench bien) GlusterFS.
Pour les NoSQL distribués, je suis preneur de retour d'expérience et de conseils, j'ai zéro expérience avec contrairement à certains DFS (Column Families, Key Value / Tuple Store, Document Store, etc.) ...
Sphinx : on a testé en prod, ça fonctionnait bien, et avec quelques K$ tu peux demander des nouvelles features au développeur russe, très efficace (1 semaine) et pas buggé. Grace a Sphinx on a divisé par 4 le nombre de serveurs nécessaires, et améliorer le temps de réponse par plus de 100 ! Pour améliorer encore les perfs, on a fait notre propre moteur: l'index est stocké en ram, full scan a chaque fois mais temps de réponse de fou, et ça ne consomme que du "bon" cpu. Prochaine étape: la même chose avec des cartes graphiques ou FPGA :)
ça fait partie des "NoSQL" Sphinx ? Les moteurs NoSQL, il vaut mieux savoir quelles données vont être manipulées avant de faire un choix (choix du type puis du soft). -- arnaud
Arnaud <shine@achamo.net> writes:
ça fait partie des "NoSQL" Sphinx ?
Non, c'est un indexateur, qui fait des requêtes au serveur SQL d'un côté et qui les stocke dans un format "optimisé" pour la récupération rapide. Typiquement, ça marche très très bien pour de la recherche fulltext sans avoir à ruiner MySQL. http://sphinxsearch.com/ -- Lucas
Le Fri, 27 Aug 2010 11:02:56 +0200, Arnaud <shine@achamo.net> a écrit :
Les moteurs NoSQL, il vaut mieux savoir quelles données vont être manipulées avant de faire un choix (choix du type puis du soft).
Des données de type "multimédia" (ahah, définition alakon™ quand tu nous tiens), un type qui veut rien ou tout dire. C'est vendredi et je suis nase mais en gros des BLOBs et leur métadonnées exprimés en XML et du XML (du texte donc encodé en UTF-8). a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
"Jerome Benoit" <jerome.benoit@grenouille.com> a écrit :
Des données de type "multimédia" (ahah, définition alakon™ quand tu nous tiens), un type qui veut rien ou tout dire. C'est vendredi et je suis nase mais en gros des BLOBs et leur métadonnées exprimés en XML et du XML (du texte donc encodé en UTF-8).
Métadonnées que tu veux utiliser pour des requêtes je suppose ? Parce que sinon tu peux peut-être te contenter du FS distribué. Certains gèrent les métadonnées nativement (par exemple S3), avec les autres utiliser de simples fichiers texte est une possibilité. Sinon, tout dépend du contenu de ton XML. Si tu ne le maitrises pas le plus simple sera probablement de prendre une base NoSQL orientée documents. Pour les blobs ça me semble une mauvaise idée de les stocker dans la base NoSQL. Presque toutes les gèrent mal et certaines ont des limites sur la taille des données pour éviter ce genre d'utilisation. Beaucoup n'ont pas de type binaire non plus, et le base64 n'est pas vraiment une solution. C'est typiquement le rôle d'un FS distribué de stocker les assets.
Le Fri, 27 Aug 2010 22:49:48 +0200, Pierre Chapuis <catwell@archlinux.us> a écrit :
"Jerome Benoit" <jerome.benoit@grenouille.com> a écrit :
Des données de type "multimédia" (ahah, définition alakon™ quand tu nous tiens), un type qui veut rien ou tout dire. C'est vendredi et je suis nase mais en gros des BLOBs et leur métadonnées exprimés en XML et du XML (du texte donc encodé en UTF-8).
Métadonnées que tu veux utiliser pour des requêtes je suppose ?
Et définir le schéma si je pars sur une dé-sérialisation du XML, oeuf de course.
Parce que sinon tu peux peut-être te contenter du FS distribué.
C'est ce que j'avais pensé faire pour mettre les BLOBs seulement et utiliser le NoSQL comme un index de hash par répertoire qui permet de retrouver rapidement la bonne version du BLOB. J'avais un htree à l'esprit plus exactement (comme dans ext{3,4}), le pb étant que le htree ne gère pas le versionning dans son design mais je peux réfléchir à comment le faire proprement.
Certains gèrent les métadonnées nativement (par exemple S3), avec les autres utiliser de simples fichiers texte est une possibilité.
Sinon, tout dépend du contenu de ton XML. Si tu ne le maitrises pas le plus simple sera probablement de prendre une base NoSQL orientée documents.
J'ai la maitrise du XML, c'est même un format standardisé pour certains la partie non métadonnées de BLOB.
Pour les blobs ça me semble une mauvaise idée de les stocker dans la base NoSQL. Presque toutes les gèrent mal et certaines ont des limites sur la taille des données pour éviter ce genre d'utilisation. > Beaucoup n'ont pas de type binaire non plus, et le base64 n'est pas vraiment une solution. C'est typiquement le rôle d'un FS distribué de stocker les assets.
Tu as raison et c'était mon idée première :) a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Fri, 27 Aug 2010 23:51:47 +0200, Jerome Benoit <jerome.benoit@grenouille.com> a écrit :
J'ai la maitrise du XML, c'est même un format standardisé pour certains la partie non métadonnées de BLOB. ^ sauf pour
-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Fri, 27 Aug 2010 10:50:02 +0200, Greg <greg-frsag@duchatelet.net> a écrit :
et tu veux qu'on fasse tout ton travail :-P
Du tout :) c'est une exposition pour une aide et retour d'expérience éventuel.
3) Cluster de données/stockage :
Une fois de plus : Ceph http://ceph.newdream.net/ (et j'aimerais bien que quelqu'un fasse le 1er pas ! :) ) Une fois de plus: évitez (ou test et bench bien) GlusterFS.
Je vais pas le faire ce premier pas vers ceph pour la simple et bonne raison que quand je vois les commit dans le repo git de Linus, le nombre de bugs corrigés est important le concernant et du bug lourd ou les nœuds ne reprennent pas leur activité, perdent de la data. C'est absolument pas envisageable pour un projet ou je n'ai pas de R&D dans la feuille de route.
Pour les NoSQL distribués, je suis preneur de retour d'expérience et de conseils, j'ai zéro expérience avec contrairement à certains DFS (Column Families, Key Value / Tuple Store, Document Store, etc.) ...
Sphinx : on a testé en prod, ça fonctionnait bien, et avec quelques K$ tu peux demander des nouvelles features au développeur russe, très efficace (1 semaine) et pas buggé. Grace a Sphinx on a divisé par 4 le nombre de serveurs nécessaires, et améliorer le temps de réponse par plus de 100 ! Pour améliorer encore les perfs, on a fait notre propre moteur: l'index est stocké en ram, full scan a chaque fois mais temps de réponse de fou, et ça ne consomme que du "bon" cpu. Prochaine étape: la même chose avec des cartes graphiques ou FPGA :)
Intéressant. Tu parles bien de çà : http://sphinxsearch.com/about.html ? C'est du distribué au sens strict ? a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le 27/08/2010 11:22, Jerome Benoit a écrit :
Du tout :) c'est une exposition pour une aide et retour d'expérience éventuel.
Je sais bien, et le sujet m'intéresse ;)
Intéressant. Tu parles bien de çà :
oui, à savoir qu'on ne s'en servait pas du tout en tant que fulltext.
C'est du distribué au sens strict ?
non: chaque noeud charge ses index en mémoire, il faut donc que le FS soit partagé ou que les index soient copiés. Ensuite tu peux répartir la charge sur chaque noeud selon les techniques habituelles. -- Greg
Le Fri, 27 Aug 2010 11:29:23 +0200, Greg <greg-frsag@duchatelet.net> a écrit :
C'est du distribué au sens strict ?
non: chaque noeud charge ses index en mémoire, il faut donc que le FS soit partagé ou que les index soient copiés.
Il gère donc en natif des écritures concurrentes sur un même index stocké sur un DFS ? L'estimation de la volumétrie des données + metadonnées en extrapolant un peu est de ~750 To.
Ensuite tu peux répartir la charge sur chaque noeud selon les techniques habituelles.
Ça franchement, çà me chiffonne, le load balancing sur la couche de transport est une hérésie (j'en ferais un article un jour "Layer 3 load balancing is evil" quand les jours feront 48 heures ou que je serais au chômage sans rien de mieux à faire :)). a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Il gère donc en natif des écritures concurrentes sur un même index stocké sur un DFS ?
Un des noeud, n'importe lequel, peut se charger de faire l'indexation et de générer les index. Ensuite tu peux demander à chaque noeud de faire un "rotate" qui vont charger les nouveaux index. Afin de limiter les IO, mieux vaut faire le rotate noeud après noeud. -- Greg
On Thu, 26 Aug 2010 23:45:22 +0200, Jerome Benoit <jerome.benoit@grenouille.com> wrote:
Pour les NoSQL distribués, je suis preneur de retour d'expérience et de conseils, j'ai zéro expérience avec contrairement à certains DFS (Column Families, Key Value / Tuple Store, Document Store, etc.) ...
Pour la famille de documents, à toi de voir en fonction de ce que tu veux stocker. Personnellement j'aime bien les structures de données qui ressemblent à des hashes (document stores). Concernant la scalabilité, si tu ne l'as pas encore fait, commence par lire http://jamesgolick.com/2010/3/29/most-nosql-dbs-are-not-scalable.html. Cassandra est "scalable" au sens où on l'entend en général, pour HBase je ne sais pas. MongoDB et CouchDB sont faits pour des échelles plus petites. J'ai aussi entendu du bien de Riak. Je travaille actuellement dans AWS donc je triche et j'utilise SimpleDB. Il faut aussi faire attention à la propriété fondamentale du NoSQL scalable : l'absence de consistence pure (propriétés AP du Théorème de Brewer : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem). En particulier, un bon nombre de bases de données de ce genre n'offrent pas d'option permettant de lire ses écritures. SimpleDB permet depuis quelques mois de choisir à la lecture entre AP (rapide et disponible) et CP (qualité des données) mais je ne connais pas de système libre qui offre cette option. Au passage, quelqu'un a testé ce que donne VoltDB (http://voltdb.com/) sous une charge conséquente en écriture ? -- Pierre 'catwell' Chapuis
Le Fri, 27 Aug 2010 18:43:04 +0200, Pierre Chapuis <catwell@archlinux.us> a écrit :
Cassandra est "scalable" au sens où on l'entend en général, pour HBase je ne sais pas. MongoDB
MongoDB vient d'avoir le sharding mais la manière donc çà a été implémenté me plait guère (en gros, c'est du scatter/gather sur des partitions de données qui se veut distribué que je trouve mal foutu, l'algo est vraiment naïf et il est correspond pas à ce que je veux).
et CouchDB sont faits pour des échelles plus petites.
Et couchdb fait du "shared nothing", çà correspond encore moins à mes besoins, la consistance est géré avec les pieds en plus :) C'est pour çà que j'ai les mis dans l'éventuel :)
J'ai aussi entendu du bien de Riak.
Tu peux élaborer ?
Je travaille actuellement dans AWS donc je triche et j'utilise SimpleDB.
Hum, c'est pas extrêmement cher mais je suis pas sur que çà colle au contexte d'outsourcer ce tiers.
Il faut aussi faire attention à la propriété fondamentale du NoSQL scalable : l'absence de consistence pure (propriétés AP du Théorème de Brewer : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem). En particulier, un bon nombre de bases de données de ce genre n'offrent pas d'option permettant de lire ses écritures. SimpleDB permet depuis quelques mois de choisir à la lecture entre AP (rapide et disponible) et CP (qualité des données) mais je ne connais pas de système libre qui offre cette option.
Si si Cassandra le fait : http://wiki.apache.org/cassandra/ArchitectureOverview Cassandra est le mieux pensé dans l'état de mes investigations mais certaines limitations comme la taille maximum de 2GB par colonne peut être gênante.
Au passage, quelqu'un a testé ce que donne VoltDB (http://voltdb.com/) sous une charge conséquente en écriture ?
Putaing, si çà marche vraiment comme annoncé, c'est la solution miracle ... /me a du code source à lire tiens :) Merci. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
On Fri, 27 Aug 2010 23:30:06 +0200, Jerome Benoit <jerome.benoit@grenouille.com> wrote:
Le Fri, 27 Aug 2010 18:43:04 +0200, Pierre Chapuis <catwell@archlinux.us> a écrit :
J'ai aussi entendu du bien de Riak.
Tu peux élaborer ?
Moi pas vraiment, ne l'ayant pas encore testée, mais elle a l'air d'avoir bonne presse, par exemple là : http://blog.mozilla.com/data/2010/05/18/riak-and-cassandra-and-hbase-oh-my/ C'est une implémentation de Dynamo, comme Cassandra, qui supporte Map/Reduce out of the box (sans Hadoop). Par rapport à Cassandra, elle m'a l'air plus simple à configurer et administrer (c'est peut-être juste une impression) et son modèle de données est moins bizarre (K/V store classique) et plus flexible (pour Cassandra il me semble qu'il redémarrer le cluster lors de certains changements de modèle).
Je travaille actuellement dans AWS donc je triche et j'utilise SimpleDB.
Hum, c'est pas extrêmement cher mais je suis pas sur que çà colle au contexte d'outsourcer ce tiers.
Non et je ne te le conseille pas : c'est très efficace si tous tes serveurs sont dans AWS mais les latences réseau sont mortelles sinon. N'imagine même pas ne pas avoir un lien rapide entre ton datastore et ton cluster si tu veux des perfs correctes.
Si si Cassandra le fait : http://wiki.apache.org/cassandra/ArchitectureOverview
Cassandra est le mieux pensé dans l'état de mes investigations mais certaines limitations comme la taille maximum de 2GB par colonne peut être gênante.
Ah merci je n'étais pas au courant, c'est bon à savoir. -- Pierre Chapuis
participants (5)
-
Arnaud -
Greg -
Jerome Benoit -
Lucas Bonnet -
Pierre Chapuis