OSCAR (Open Source Cluster Application Resources), ensemble de composants logiciels nécessaires à l'installation, l'administration et l'utilisation de cluster, vient de passer en version 4.1.
L'une des principales caractéristiques de OSCAR est d'offrir un mécanisme de paquet (paquets OSCAR) qui étend la notion de gestion de paquets traditionnelle (par exemple la gestion de paquets RPM ou DEB) au niveau de la grappe, afin de faciliter l'installation et la maintenance des clusters.
OSCAR a pour objectif d'être multi-distributions et multi-architectures. Les distributions actuellement supportées sont RedHat 9, Fedora Core 2, Red Hat Entreprise Linux 3 et Mandrake 10. Un portage sur Debian/Sarge est en cours. Au niveau des architectures, les processeurs IA32 et IA64 sont actuellement supportés. A noter également que la version actuelle est fondée sur SIS (suite logicielle regroupant Systeminstaller, Systemconfigurator et Systemimager), une solution similaire à Clic, mécanisme d'installation de noeuds de cluster intégrés dans la distribution pour cluster de Mandriva. L'évolution d'OSCAR tend vers la modularité avec notamment à terme la possibilité d'utiliser différent systèmes d'installation (par exemple SIS, Clic, KickStart ou FAI).
Pour finir, OSCAR permet entre autre d'installer automatiquement MPI (mpich ou lam), Torque, ganglia, etc.
L'une des principales caractéristiques de OSCAR est d'offrir un mécanisme de paquet (paquets OSCAR) qui étend la notion de gestion de paquets traditionnelle (par exemple la gestion de paquets RPM ou DEB) au niveau de la grappe, afin de faciliter l'installation et la maintenance des clusters.
OSCAR a pour objectif d'être multi-distributions et multi-architectures. Les distributions actuellement supportées sont RedHat 9, Fedora Core 2, Red Hat Entreprise Linux 3 et Mandrake 10. Un portage sur Debian/Sarge est en cours. Au niveau des architectures, les processeurs IA32 et IA64 sont actuellement supportés. A noter également que la version actuelle est fondée sur SIS (suite logicielle regroupant Systeminstaller, Systemconfigurator et Systemimager), une solution similaire à Clic, mécanisme d'installation de noeuds de cluster intégrés dans la distribution pour cluster de Mandriva. L'évolution d'OSCAR tend vers la modularité avec notamment à terme la possibilité d'utiliser différent systèmes d'installation (par exemple SIS, Clic, KickStart ou FAI).
Pour finir, OSCAR permet entre autre d'installer automatiquement MPI (mpich ou lam), Torque, ganglia, etc.
Site OSCAR (1543 hits)
SIS (378 hits)
CLIC/Mandriva (555 hits)
> Lire la dépêche (20 commentaires, moyenne: 1,3).
Vous avez demandé le commentaire #568468.




HA oscar ou openssi
Je veux mettre en place une solution HA :
2 Serveurs: 1 principal / 1 secours
Si le principal tombe en panne le serveur de secours prend le relais et ceci sans perte de données.L'utilisateur ne peut seulement s'apercevoir que d'un léger ralentissement.
Je lorgne actuellement sur OpenSSI qui étant une solution SSI me pemet de switcher automatiquement mes services sur le noeud cluster en cas de panne.Il me permet via DRBD de répliquer en temps réél mes données sur le noeud de secours .
Si le serveur principal est out , le noeud de secours prend automatiquement le relais (sans intervention humaine)
Je pense qu'HA-Oscar est basé sur le même principe (je parle ici uniquement de la partie HA) .La question que je me pose :
Quelle réelle différence (le + ou le -) y a t il entre les deux solutions dans mon cas ?
http://www.paulla.asso.fr
[^]Re: HA oscar ou openssi
Je pense qu'avec HA-OSCAR tu auras par exemple le choix de configurer ton service de HA en active-active ou active-passive (je crois me souvenir que ce genre de configuration est maintenant possible avec la nouvelle version de HA-OSCAR, mais j'ai essayé sans succés d'en trouver la confirmation) alors qu'avec OpenSSI tu n'auras pas trop le choix.
Bref, je pense que tu auras plus de souplesse/facilité de configuration avec HA-OSCAR qui est spécialisé pour le type de problème que tu as.
Autre point : actuellement dans OpenSSI, si le serveur du cluster (headnode) tombe, le système n'est pas dans un état cohérent.
J'espère que cela apportera un élément de réponse. :-)
[^]Re: HA oscar ou openssi
Hello,
Heartbeat (de Linux-HA) fait également du actif-passif ou du actif-actif. Tiens, je me demande si HA-Oscar ne l'utilise pas directement.
Néanmoins, un problème se pose avec la réplication des données par DRBD: seul un serveur sur les deux peut monter les partitions sur les volumes DRBD. Dans ces conditions, un SGBD en HA ne peut être posé que sur un serveur. Par contre, on peut très bien envisager de panacher les services HA , tout dépend de la réplication des données.
Ah les clusters (High Avaibility ou High Perfs) ! Une fois qu'on y a gouté, on ne peut plus s'en passer...
[^]Re: HA oscar ou openssi
Cohérent il sera : tu peux te permettre de cloner ton serveur maitre:
1) tu boot le clone via pxe : il devient un simple noeud du cluster
2) si tu as configurés les replis de données sur une (ou plusieurs) partition(s) non montées de ce noeud [partitions utlisées par le système cloné] lors de l'arret du serveur maitre, le noeud prend la relève :
Pas de perte de datas , pas d'arret de services , un nouveau serveur maitre parfaitement disponible.
Je ne vois pas d'incohérence un niveau du cluster ...
http://www.paulla.asso.fr
[^]Re: HA oscar ou openssi
> Autre point : actuellement dans OpenSSI, si le serveur du cluster (headnode) tombe, le système n'est pas dans un état cohérent.
Ayant une problématique similaire à la sienne, je profite de ton passage par ici pour te poser la question à propos d'OpenMosix. Esc-ce que la perte d'un noeud du cluster conduit aussi à un état incohérent? Si oui, quelle solution existe-t-il pour un SGBDR (au hasard PostgreSQL) en cluster?
Merci d'avance pour ta réponse éclairée. ;)
[^]Re: HA oscar ou openssi
Pour openMosix, le cluster est définitivement dans un état incohérent si un noeud tombe (même un noeud de calcul). Ils ont un mécanisme de dépendance assez restrictif entre les noeuds qui ne permet pas le retrait d'un noeud.
Il ne faut pas oublier que openMosix vise le HPC pur (ie la performance) et absolument pas la haute disponibilité (c'est pourquoi pas mal de gens ne concidèrent pas openMosix comme un vrai SSI).
Pour le SGBDR, je ne pense pas qu'un SSI actuel offre une solution adéquate. Par contre, OpenSSI et Kerrighed travaillent clairement sur la problèmatique des systèmes de fichiers pour cluster et on peut donc espérer des solutions (au moins partielles) dans les prochaines versions.
A noter qu'une nouvelle version de Kerrighed et de OpenSSI sont disponibles depuis quelques heures/jours (Kerrighed 1.0.2 et OpenSSI 1.9).
Les liens :
http://www.kerrighed.org/(...)
http://www.openssi.org/(...)
[^]Re: HA oscar ou openssi
> Pour le SGBDR, je ne pense pas qu'un SSI actuel offre une solution adéquate.
C'est bien dommage parce que les SGBD en clusters coûtent très très cher, et le matériel haut de gamme aussi (octo proc par ex.) et que dans ce genre de config la HA implique de doubler le nombre de machines, ce qui en fait des solutions prohibitives dans bien des cas.
> A noter qu'une nouvelle version de Kerrighed et de OpenSSI sont disponibles depuis quelques heures/jours
Merci pour cette info, je vais aller y jeter un oeil.
Bonne journée/semaine.
[^]Re: HA oscar ou openssi
J'ai utilise Heartbeat http://www.linux-ha.org(...) avec DRDB http://www.drbd.org(...) pour la replication de donnes et Monit http://www.tildeslash.com/monit/(...) pour controler les daemons, ca marche plutot bien et une fois qu'on a compris le principe c'est pas trop long a mettre en place.
Si le serveur principal part en vrille le serveur de secours prens la releve quelque secondes apres. J'ai configure linux en lecture seule, seule la partition replique est en ecriture ainsi qu'un ramdisk pour /var donc comme ca je minimise les risque de corruption de l'OS en cas de reboot ou crash.