Basiquement, dans l'ordre, du plus proche du browser au plus éloigné :

Couche 1 : Load balancing :

Avec 500K vue/jour, un Pentium 4 avec IPVSadm saurait faire l'affaire

Couche 2 : Les frontaux web :

Des machines identiques, fut-ce t'elle Diskless ou non, avec l'apache/php/whatever the techno classique.

Pour ce qui est des contraintes :

- Les serveurs web doivent pouvoir partager les sessions. A voir avec l'appli web (genre stocker les sessions en db sur le SQL, dans un memcached caché sur le SQL, ou via un daemon sharedanced... etc).

- Pour ce qui est de la haute disponibilité :

-- Elle est aquise de fait sur la couche des frontaux web : Si un frontal web tombe, il doit sortir du cluster et le LVS doit l'oublier. Les performances sont amoindries, pas la disponibilité.

-- Pour le Load balancer, un jumeaux et un coup de heartbeat avec une IP Failover suffit.

-- Pour le SQL, de la replication master/slave ou master/master et un coup de heartbeat avec une IP Failover suffit.

-- Pour le NFS, de la réplication (Y'a un millions de techno la...ca va de drbd a la réplication de pauvre a coup de Rsync permanent), et du heartbeat, encore.

Avec ca on obtient du HA a tout les niveau, et une architecture relativement scalable au niveau des web. La scalabilité du Filer NFS et du SQL est une autre problématique apres...

La partie firewalling est plus que presque inutile a ce niveau la :

- Les loadbalancer doivent agir comme des routeurs et redistribuer la charge, pas de distinction de protocole ou quoi. Pas de raison de mettre un firewall a moins d'avoir des contraintes tres precises.

- Les seuls a avoir une ou des IP publique la dedans sont les load balancer. Ces memes IP publiquent se retrouveront sur la loopback des Frontaux web, pour la répartirion de charge.

- Tout le reste peut communiquer sur des ip privées, dans des VLAN privés.

- Si au milieu de ca on respecte les bases de sécurité d'avoir des services maintenus a jours, patchés, et rien d'ouvert qui n'ai pas un besoin express de l'etre, le firewall devant tout ca est a mon sens inutile.

- Au pire du pire, trois bout d'iptables et/ou de PF font l'affaire.

Quant aux variantes, on peut load balancer avec du varnish par exemple au lieu du LVS (Couche 7 au lieu de couche3), ce qui permettra d'éliminer facilement 95% des acces NFS, mais nécessite des configuration fine en fonctions des spécifités des codes applicatif derriere. C'est pas la meme vision des choses.

Dans le genre variantes aussi, on peut imaginer du HA assuré par des techno de virtualisation, on peut imaginer une "foret" de SQL ou sont réparties les bases, voit les tables, etc.

Le 13 mai 2011 à 17:01, frantishrek a écrit :

Le 13 mai 2011 16:13, Steven Le Roux <steven@le-roux.info> a écrit :
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :)

c'est :

- trop cher
- peu scalable
- pas distribué

A priori, au vu des réponses, cela semble l'orientation globale.
Si je résume, vous ne conseillez donc pas de disposer d'un espace
disque partagé à l'ensemble des applications.
Vous préconisez de stocker les applications sur chaque frontal ?

Aujourd'hui en 2011, il y a plein de bonnes choses pour faire une
belle archi web bien propre... hdfs, voldemort, reddis, varnish,
etc...

Je ne connais pas très bien ces technos. Ok pour conserver les
sessions avec des bases clé-valeur (voldemort, redis ou memcached)
mais quant est-il des données partagées dans le cas de plusieurs
frontaux webs ? C'est le rôle que peut jouer hdfs ?

Ton problème, c'est que c'est déjà developpé, et qu'ils ont pris un
modèle très peu distribuable (sql/oracle).

(sourire)

Tu n'as pas de coupure protocolaire sur ton archi ? genre reverse
proxy (haproxy par exemple), etc ? ça me semble dangereux ...

Je ne connais pas bien haproxy. Je ne suis pas sûre de bien comprendre.
L'objectif est de disposer d'une infra redondée avec un équipement dédié.

Merci pour la réponse. Grâce à ton message, j'ai appris plein de
nouveaux mots (redis, voldemort, hdfs) ;-)
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

---

Colin Brigato
colin@brigato.fr