(réécrite et réaffectée suite à une purge de compte)
Quelques liens sur les initiatives de haute disponibilité sous les systèmes à noyau Linux.
Aller plus loin
- Kimberlite (lien cassé) (31 clics)
- sgi Linux FailSafe (14 clics)
- Linux High Availibility (58 clics)
- Linux Virtual Server (27 clics)
# et oui pasbill...
Posté par Gloo . Évalué à 6.
http://www.linuxfr-france.org.invalid/article/cel/SICOMOR/Haute_disponibilite(...)
Là tu as un ensemble de lien sur l'avancement des projets. C'est fou, comme le libre avance en 1 an, n'est-ce pas ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et oui pasbill...
Posté par GP Le (site web personnel) . Évalué à 0.
Le site linux HA existait aussi d'ailleurs.
C'est genant, les gens qui recherche ma, parce que apres ils disent que mon OS cherie ne sait rien faire ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et oui pasbill...
Posté par GP Le (site web personnel) . Évalué à -7.
Le site linux HA existait aussi d'ailleurs.
C'est genant, les gens qui recherche mal, parce que apres ils disent que mon OS cherie ne sait rien faire ;)
[^] # Re: et oui pasbill...
Posté par Gloo . Évalué à -3.
[^] # Re: Merci
Posté par Anonyme . Évalué à -1.
[^] # Re: De rien mais...
Posté par Gloo . Évalué à -2.
# Différentes facons de voir la haute disponibilité
Posté par Anonyme . Évalué à 10.
- Kimberlite ressemble au HACMP d'IBM : quand un des deux noeuds "tombe", le deuxième reprend les services assurés par le premier. C'est une architecture classique d'un cluster assymetrique dans la mesure où chacun des deux noeud a ses applications préférées. Un noeud reprend toutes les applis seulement s'il se retrouve tout seul.
- LVS permet surtout de faire du Load-Balancing, mais il reste un "single point of failure" : le serveur maitre, le point d'entrée du cluster. Je crois savoir que si le serveur maitre tombe, un serveur esclave en reprendra les fonctions. Quelu'un peut confirmer ?
- MOSIX, qui n'est pas cité ici, permet d'associer un multitude de machines (identiques de préférence) afin de ne voir qu'un seul noeud (et une seul adresse IP). Il s'agit plutot de faire sun serveurs d'applications, mais la migration de process avec leur contexte est géré. Ce type de cluster est dit symmetrique : on ne sait pas sur quel noeud va être lancé un process.
- Un peu de pub chauviniste : Alinka Orange. Cette solution serait basée sur LVS, mais je n'en suis pas sûr.
Quelqu'un dans la salle aurait t'il eut à étudier les différentes sulotions disponibles pour linux ? Existerait t'il un comparatif des solutions ? Certaines solutions serait t'elles mieux adaptées à certaines applications ?
De par mon expérience, les serveurs mis en haute diponibilité sont souvent des serveurs de base de données. Dans la mesure où il s'agirait d'Oracle sur un linux, quelle serait la meilleure solution ?
[^] # Re: Différentes facons de voir la haute disponibilité
Posté par Jerome Demeyer . Évalué à 3.
Beuh! -1
[^] # Re: Différentes facons de voir la haute disponibilité
Posté par loopkin . Évalué à 10.
Je connais plutôt piranha, qui est la version RedHat de LVS. Le principe est ultra simple pour le fail-over: tout simplement le serveur maitre et l'esclave se "baladent" l'IP à laquelle tu accèdes en fonction de la disponiblité du ou des services considérés sur les machines. Il y a une connexion entre le maitre et l'esclave, plus un heartbeat périodique... et quand le "coeur" du maitre ne bat plus, l'esclave démarre l'interface sur l'IP en question, et le service est alors rendu par lui au lieu du maitre. C'est en fait très proche du HACMP d'IBM. Est-ce que ça répond à ta question ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Différentes facons de voir la haute disponibilité
Posté par Anonyme . Évalué à 6.
Par contre dans le cas de LVS il y a effectivement une adresse virtuelle que toutes les machines du cluster partagent.
C'est à cette adresse (+ numero de port) que les clients accèdent.
Le répartiteur de charge "dispatche" quant à lui les requetes sur les "serveurs reels".
C'est ce répartiteur de charge qui est le maillon faible (Tu sors ! :)).
Il suffit pourtant de rajouter un repartiteur identique au premier mais qui ne soit actif que dans la cas d'une défaillance du premier pour assurer la disponibilté du serveur virtuel.
Bref LVS assure le load balancing, et il suffit de rajouter une couche pour assurer la haute dispo.
Est ce que Failsafe fonctionne avec un modèle répartiteur de charge / serveurs ?
[^] # Re: Différentes facons de voir la haute disponibilité
Posté par Ghislain Seguy . Évalué à 4.
# question x25
Posté par franck villaume (site web personnel) . Évalué à 9.
Ma question n'est pas innocente puisque je suis administrateur de cluster HA et que je cherche à pouvoir faire des propositions d'évolutions à mon client pour passer sous Linux.
Merci d'avance.
[^] # Re: question x25
Posté par Stephane Pion . Évalué à 7.
Je me suis orienté d'abord vers les cartes Sangoma, qui ont l'air bien supporté. Le seul revendeur (à ma connaissance) en france est une boite parisienne du nom de Ercom
J'ai du, pour des problèmes de marché, changer mon fusil d'épaule.
Je me suis orienté vers les cartes X.25 AT-FUT-D de Thalès [1] (Ex Dassault AT). J'ai pas encore eu le temps de voir en détail.
C'est basé sur les Streams SYSV. Ils utilisent l'implémentation linux LiS [2]. Le driver est prévu pour le 2.2.14 et ne fonctionne pas sur machine multipro, mais je crois qu'ils en on développé un nouveau. On n'a pas les sources du driver, et pas les sources de la lib XTI/TLI qui est fournie avec la carte.
Sinon, Dassault a visiblement un forte expérience Unix, contrairement à Eicon qui parait-il fournirait des drivers linux pour ses cartes X.25
La carte embarque un OS et du code qui gère le protocole X.25 jusqu'au niveau 3, je crois.
La configuration se fait à travers une interface texte à la ncurses.
Stéphane
[1]http://www.idatys.thomson-csf.com/telecoms/c_file.htm(...)
[2]http://www.gcom.com/(...)
[^] # Re: question x25
Posté par pabr . Évalué à 4.
http://www.farsite.co.uk/(...)
[^] # Re: question x25
Posté par franck villaume (site web personnel) . Évalué à -1.
Je vais pouvoir creuser tout ça.
[^] # Re: question x25
Posté par bad sheep (site web personnel) . Évalué à 1.
[^] # Re: question x25
Posté par Olivier Jeannet . Évalué à 2.
J'avais été voir le stand EICON (qui est une marque reconnue) à la Linux Expo, ils supportent Linux mais je ne sais pas si tous leurs drivers sont avec les sources. Je leur ai fait la remarque (peut-être naïve) que j'avais du mal à imaginer les secrets industriels d'un driver X25, pas vraiment une techno récente, et que je ne comprenais pas pourquoi ils ne donnaient pas les sources.
# Et les singes ?
Posté par Nico . Évalué à 8.
Ceci permet de faire à la fois du Load Balancing et Haute Disponibilité.
Les schemas sont assez biens fait et permettent de comprendre assez vite les differentes architectures possibles. Toutefois, la doc technique/install n'est pas complete à mon gout.
Surtout au niveau parametrage des interfaces reseau. On s'emmele vite fait les pinceaux.
A essayer tout de meme.
Nico
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et les singes ?
Posté par Nico . Évalué à -1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
# Attention noyau 2.4.12 sorti
Posté par loopkin . Évalué à -2.
il s'agit d'une nouvelle extrêmement importante, mais hélas uniquement visible dans la petite boiboite "Autres" sur linuxFR(3), et dans la petite boiboite noyau en bas.
[^] # PROPAGANDA !!!!
Posté par Anonyme . Évalué à -2.
http://linuxfr.org/2001/10/11/5388,0,0,0,1.php3(...)
# Pour info
Posté par matiasf . Évalué à 1.
http://ha.redhat.com/(...)
# Stabilité de kimberlite ?
Posté par pierre Westeel . Évalué à 2.
Est-ce que quelqu'un utilise ce soft en production ? Vaut mieux avoir des avis avant de lacher le serveur sur le net ;)
Autre chose: kimberlite utilise les rawdevices, j'ai lu quelque part qu'il y avait un bug quand on utilise les rawdevices avec le support big mem ( > 1G ).
Est-ce que c'est toujours vrai pour les derniers kernels ?
Il existe une autre solution pour la haute disponibilité avec un disque SCSI partagé : lifekeeper:
http://www.steeleye.com/products/linux/(...)
mais bon, c'est un produit commercial :(
[^] # Re: Stabilité de kimberlite ?
Posté par Olivier Jeannet . Évalué à 1.
Quel type de montage (physique) disque utilises-tu ?
# Mosix est une solution de cluster "transparent"
Posté par Anonyme . Évalué à 7.
Mosix est une solution de cluster "transparent".
Toutes les applications binaires Linux peuvent
tourner sous Mosix sans modification et en étant
répartie sur les machines du cluster en fonction
de leur charge.
En un mot: génial. Et cette solution est testée et reconnue depuis plusieurs années:http://www2.physics.ox.ac.uk/datagrid/ukhepgridtestbed/talks/dave%2(...)
[^] # Re: Mosix est une solution de cluster "transparent"
Posté par Anonyme . Évalué à 2.
Un hébergeur (comptes utilisateurs, ftp, apache, bdd, mail,...) a-t-il des avantages à utiliser mosix plutôt que LVS?
Merci d'avance pour la réponse.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.