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 +.