On Thu, Mar 17, 2005 at 10:02:31AM +0100, Jean Jacques wrote:
Je me demandais si certains ou certaines d'entre vous avaient d�j�
exp�riment�s l'installation et l'administration de serveur web
(apache,php,mysql) en cluster.
Le mot cluster est vague. De plus, suivant l'application, les besoins
seront diff�rents.
Trois exemples:
1. un petit site de vente avec le catalogue g�n�r� en HTML
statiquement une fois par jour, interface de commande en Perl sur
SGBD PostgreSQL
2. site compl�tement dynamique: aucun composant statique
3. site � haute fiabilit�
Dans le cas 2, on conseillerait, pour de bonnes performances, de rendre
une grande partie du site statique. En effet on voit bien que dans le
cas 1, la plupart des op�rations sont des consultations (ratio 1%
probablement). Et en g�n�ral le catalogue est mis � jour une fois par
jour ou une fois par mois. Ce ne sont que dans de rares cas o� une
configurabilit� maximale est d�sir�e pour l'utilisateur qu'il faut
absolument passer par du dynamique.
En s�parant la partie `dynamique' (rarement utilis�e) de la partie
statique (fortement utilis�e), on peut alors d�couper le `serveur WWW'
en plusieurs parties:
1. la partie qui sert des fichiers statiques
-> serveur Apache simple
-> proxy/cache agressifs �ventuels (Squid)
2. la partie qui effectue effectivement un traitement utile
-> serveur Apache d'application (Perl, mod_perl, etc)
3. la partie qui effectue le stockage
-> serveur de fichiers (NAS)
-> serveur de blocs (SAN)
-> SGBD
(certains nomment cela le mod�le 3 tiers)
Chacune de ces parties peut �tre impl�ment�e par plusieurs machines:
c'est trivial pour la partie 1, c'est relativement facile pour la partie
2 d�s lors que l'application est bien �crite (p.ex. transactions, pas de
stockage local; on reporte le probl�me sur la partie 3).
Pour la partie 3 c'est plus difficile, et il faut s�parer les cas:
cas 1: haute fiabilit�
cas 2: haute performance
(les deux cas peuvent �tre combin�s).
Si l'application est bien faite, on aura simplement besoin de haute
fiabilit�. Si l'application charge �norm�ment le stockage, il se peut
que de la redondance soit n�cessaire.
Pour la fiabilit� on utilise des m�canismes de synchronisation �
diff�rents niveaux.
A ma connaissance il n'existe pas encore, en libre, d'impl�mentation
SGBD offrant la haute fiabilit� *et* la performance ainsi que des
fonctionnalit�s avanc�es comme proc�dures stock�es et transaction.
Le plus approchant est de renoncer � ces fonctionnalit�s en partie 3
et de les impl�menter en partie 2 (avec diff�rentes fa�ons de faire un
moniteur transactionnel). C'est dommage car SQL est bien connu et bien
ma�tris�, et que ces couches transactionnelles ne le sont pas encore.
Enfin, il s'agira de consid�rer OpenPBS ou Mosix dans la mesure o� un
`cluster' de calcul est d�sir�.
L'id�e c'est de r�cup�rer plein de vieux pc, d'en faire un cluster
afin de cr�er un serveur assez puissant.
Puissant pour quoi faire est donc la prochaine question.
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
