>
Je pensais à memcached (memcached - a distributed memory object caching system) qui propose une
table de hashage en RAM disponible simplement via le resau. Ca gère
aussi la réplication.
Waw, ah oui, fallait quye je teste ce machin là.
>Ben oui .... Tiens, j'ai mis du temps à voir que tu écrivais AUSSI dans
>le mail, je continue :
heing?
Bah c'est pas toi alors, j'ai pas répondu au bon mail ptêt, désolé.
Alexandre parlait d'un NFS d'une machine du cluster vers l'autre, pas
d'un serveur commun. Personnelement, j'aime pas l'idée d'un filer dans
un cluster, surtout que le web, c'est une majorité de lecture, pour un
petit peu d'écriture. Je parle de contenu, pas de cache. si tu commences
à redonder les serveurs web, puis ton NFS derrière, tu arrives à 4
machines, + le SQL. Mis à part si tu veux refaire slashdot en Spip, je
pense que le cluster pour Spip, c'est plutot pour la tolérance de panne.
Oui, je parlais bien tolérance de panne, avec un truc du style :
lb1 lb2
\ /
/ \
web1 web2 -- (nfs ou pas) --repli
> >
\ /
sql---repli
Avec un cluster mysql 5, tu pourras croiser aussi le sql aussi car la
répli à chaud temps réelle dans les deux sens est permise, je me demande
bien comment il gère les update/inserts mais ils annoncent ca comme
possible.
Si tu as effectivement une session qui n'est pas commune en nfs, il va
te falloir poser ton id de session ailleurs. Dans la bdd, c'est une
mauvaise idée à mon avis. Dans un cookie de session, pourquoi pas.
Après, une simple persistance au niveau du lb peut suffire, à condition
qu'il n'y ait pas de vol possible. Il en va de même pour le cookie.
je parlais des locks/cache/flush de Spip. J'aime pas NFS, d'ailleur,
mais c'est plus par ignorance.
Les locks de spip sont à peu prêt les mêmes qu'en nfs dans le sens ou ,
en nfs aussi, tu peux locker un fichier depuis un client, qui n'est pas
vu de l'autre. La différence est qu'un lock spip est plus facile a
enlever qu'un lock nfs 
non, je veux un cluster SIMPLE. 2 web, 1 SQL. Donc, pas de docroot
commun, pas de rsync, pas de NFS.
Quand tu remets ton serveur qui est tombé, il suffit d'appuyer sur le
bouton magique qui empeche Spip d'uploader du contenu, tu fais ton rysnc
over ssh ou avec rsyncd, et ensuite tu dévérouilles.
Mouai. L'autre cas simple, mais pas très secure , c'est le nfs croisé en
failover. web2 monte la docroot de web1. La docroot de web1 se
synchronise dans un répertoire prévu à cet effet. En cas de crash,
suffit de heartbeater le point de montage.
La même manip est à faire sur l'autre web bien sûr.
Mais dans le cas que tu évoques, oui, il manque quelque chose à spip ...
je sais pas, certains site de prestige et de forte fréquentation donne
des infos sur leur architecture, qui reste simple, et certains points
peuvent être considéré comme moins fragile, comme un routeur hard, sans
disque dur.
Oui et non. Un routeur et un switch, ca se redonde aussi. En fait, quand
on veut bien faire, on peut tout redonder (même les humains, private
joke avec Pif :-))
Il y a l'autre solution un peu violente qui consiste à mettre deux
machines synchronisés, mais qu'une seule bosse, avec un lien hearthbeat
(null modem + ethernet par exemple), et quand le frontal meurt, le
secondaire fait un arpspoof pour piquer l'adresse IP.
Ben oui, mais non. Généralement c'est plus le maître du noeud qui envoie
un gratuitous arp packet auprès du lien réseau (firewall/autre) qui le
relie à internet. Après, le maître du noeaud n'a pas à apprendre de
nouveau client, simplement il doit avoir une technique pour savoir que
le client en question est vivant ou pas (keepalived sur le lb si LVS,
cdagent sur le client si Resonate)
Bon le principal est qu'on est tombé d'accord sur ton point de vue
concernant un manque de SPIP, mais pas sur la solution
