bonjour,
Dominique Chabord wrote:
>>Peut-être que ceci peut vous intéresser ?
>>http://oss.missioncriticallinux.com/projects/kimberlite/overview.php
>>
>>
>
>En effet, kimberlite prétend gérer justement ce cas. Je n'en ai pas
>l'expérience. Il y a aussi le cluster HA de RedHat.
>
un autre probleme est soulevé tres justement dans la presentation de
kimberlite, celui de la mise en memoire des datas (pour optimiser les
acces disques). Et donc les datas dans un schema comme le mien seraient
à l'instant T reparties entre les memoires des real servers et des disques.
kimberlite resoud ca en montant/demontant le FS a chaque fois. Par
ailleurs il ne fait pas le load balancing des services parmi
les real servers. Je m'oriente donc vers un NAS ou un Linux dedié avec
NFS3...
Merci de vos avis, cela m'a aidé
daniel
>
>
>Salut,
>
>réponse rapide:
>
>le SCSI partagé nécessite des adapteurs qui le supportent et un controlleur
>RAID qui le supporte. Si cest le cas, ton architecture est possible sur le
>plan hardware.
>
>Pour le soft, heartbeat n'est pas capable de te fournir un partage au niveau
>fichier. En fait c'est ext3 qui ne le pertmet pas. Une solution serait
>OpenSSI, mais elle n'est pas encore fiabilisée. Le controleur RAID ne saura
>pas faire ce que tu veux. Il ne connait que des volumes.
>L'alternative est un accès par nfs et un basculement global du volume d'une
>machine à l'autre. Hartbeat implemente ca avec plus ou moins de bonheur.
>Pour sécuriser les accès il préconise une méthode appelée STONISH que je te
>laisse découvrir, mais qui n'emporte pas mon suffrage.
>
>Du coté du fonds de technologie de Shaman-X, nous avons une solution
>prototypée de gestion de SCSI partagée, sur laquelle nous pourrions
>re-travailler, ainsi que quelques astuces pour adapter le fonctionnement
>global pour plus de sécurité. Il y a aussi des solutions plus haut de gamme.
>
>Malheureusement, je suis en déplacement et n'ai pas accès à toutes nos docs
>ces jours ci.
>
>
