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
pgp965c5Vo9PU.pgp
Description: PGP signature
_______________________________________________ FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
