[gull] serveur web et clustering

Jean Jacques jean-jacques at duclaux.net
Mon Mar 21 10:14:02 CET 2005


Bonjour,

Avant tout merci beaucoup pour cette réponse et explications détaillées. 
Je continue aussi à chercher sur internet et je vais tenter de préparer 
un petit récapitulatif pour ceux ou celles que celà interesse.

Afin de préciser ma demande je vais essayer de définir ce que j'entends 
par "puissant".

Par puissant j'entends un système *modulaire* qui peux supporter 
différents types de sites web:
   
    -blogs collaboratif très dynamiques (1 publication toutes les 30 min)
    -sites entièrements statiques en xhtml+css avec des montées en 
charges brèves mais importantes (exemple 10 000 hits en 30 minutes) 
(haute performance)
    -Dans le cas ou un serveur subit une panne matérielle qu'un autre 
poste prenne le relais (haute fiabilité)

Concernant la fiabilité, je n'ai pas bien compris le passage suivant "

Pour la fiabilité on utilise des mécanismes de synchronisation à
différents niveaux."

Est ce qu'il serait possible d'avoir quelques explications supplémentaires ?

Par avance merci,


Jean-Jacques


Marc SCHAEFER wrote:

>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
>gull at lists.alphanet.ch
>http://lists.alphanet.ch/mailman/listinfo/gull
>
>  
>




More information about the gull mailing list