[gull] serveur web et clustering

[Jean Jacques]

Je continue les recherches, je viens de trouver une article excellent ici :

http://lea-linux.org/leapro/dispo.html


Salutations ,

JJ

Jean Jacques wrote:

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