# [OFF] Les solutions High Availability (HA)

## loopx

Bonjour, 

Dans le train, en revenant du boulot, je me suis dit qu'un petit tableau récapitulatif entre les différentes solutions HA pourrait être intéressant. Je voulais donc vous demander votre avis sur les différents systèmes HA disponible.

Pour ma part, je connais ces systèmes :

- virtualisation

- cluster

- content-switch

Pour moi, le meilleur, c'est la virtualisation qui :

- permet de n'avoir qu'un seul OS à gérer

- permet de conserver les paramètres réseaux

- permet d'ajouter une couche par dessus (cluster ou content-switch)

Pour le cluster :

- multiple OS à gérer

- directement lié au matos

- réclame des "fence device" (en Red hat du moins)

Pour le content switch :

- plusieurs os à gérer

- directement lié au matos

Voilà, c'est juste comme ça  :Smile: 

----------

## kwenspc

La virtualisation seule n'est pas une solution de HA. Ton host tombe, tout tombe. Faut combiner virtualisation et clustering (afin d'avoir plusieurs hosts). De fait dans ta liste la meilleure vraie solution de HA c'est le cluster. Et quand bien même cette solution fonctionne rarement seule (on fait appel à des layers ou content switch, tout dépend de l'infra).

----------

## loopx

Je sais pas ce que tu veux dire par "layers" ..

Sinon, la virtualisation sur une seule machine, ok, mais quand tu as 2 machines ... tu relances ta vm sur l'autre  :Smile:   et ca fait donc un HA  :Surprised: 

----------

## guilc

Merci kwenspc, je commençais à douter de mon archi  :Laughing: 

Effectivement, dans ta liste, la seule solution qui permette un peu de haute dispo, c'est le cluster.

- De la virtu sans cluster, c'est rien, du vent. Le seul intérêt étant de séparer de manière forte les services, éventuellement pouvoir dupliquer/déplacer une VM en 30s.

- Du content-switch, heu, il switche sur quoi le monsieur ??? C'est un outils dans une infra, rien de plus. Et encore, si c'est mal fait, ça introduit un SPOF de plus !

La seule solution pour faire de la haute dispo (j'ai bien dit la SEULE), c'est que TOUT soit dupliqué. Si un seul élément de ton archi est non-redondant, pouf, un SPOF. Donc il est impossible de n'avoir qu'un seul host à gérer dans tous les cas.

Après, ton cluster, différentes manières de le gérer. avec du content switch / layer switching (ça fait en plus de la répartition de charge), avec juste du failover (dommage, y a en permanence un host qui sert à rien).

Au fait : content-switch == niveau 7, layer switch == niveau 2/3 (typiquement, LB HTTP vs LB TCP)

Pour ma part, je ne suis pas fan de virtualisation, l'archi que j'utilise est simple.

des VIP, du heartbeat pour la bascule du cluster, du haproxy pour le LB niveau 7/3 (suivant les services en LB), du DRBD pour la synchro disque. Et ça tourne comme une horloge. On peut rebooter tranquillou une machine sans couper le service (enfin, quelques secondes le temps de la bascule s'il faut bouger les VIP).

----------

## guilc

 *loopx wrote:*   

> Sinon, la virtualisation sur une seule machine, ok, mais quand tu as 2 machines ... tu relances ta vm sur l'autre   et ca fait donc un HA 

 

Ah oui, et la bascule, tu la fais à la main ? tu la synchronises comment ta VM quand le host qui héberge la VM a cramé le disque ? Avec les mimines ? Tu envoie le disque au labo pour récupérer les données de la VM que tu n'as pas synchronisée en temps réel ?

----------

## boozo

/off Pi'*ain ! Y'a au moins un mot par phrase que je ne comprends pas !  :Laughing: 

Vite de la doc en intraveineuses...  :Embarassed:  (au moins 2 lignes de + pour les niveaux de LB 5, 7, 2/3, 7/3)

naannn je ne suis pas un numéro

----------

## guilc

Roh   :Laughing: 

Glossaire :

- LB : load balancer. haproxy est un load balancer sous linux, le module ACE pour 6500 de cisco ou le CSS de cisco en sont aussi

- niveau 7, 3, 2... couches du modèle OSI ( http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI )

- VIP : virtual IP. Une adresse IP qu'on peut router sur différentes machines en focntion des contraintes de dispo http://fr.wikipedia.org/wiki/Virtual_Ip_Adress

- Pour le reste, je pense que google aide, mais sinon faut demander  :Smile: 

un LB de niveau 3 est un LB qui travaille au niveau TCP (sans savoir ce qu'il y a dedans)

un LB de niveau 7 travaille sur la couche applicative (typiquement HTTP). il va savoir lire les URL, ajouter des cookies, des headers HTTP, faire du filtrage d'URL, etc.. et rediriger le trafic sur une machine ou l'autre en fonction des URL (typiquement, suivant le vhost, aller sur un serveur HTTP différent derrière). Le content switching, c'est ça

Après, on peut en ajouter  :Smile: 

----------

## boozo

Naan pour ce soir çà va... je suis calmé !  :Mr. Green: 

*Uuups !* Savais bien que j'avais loupé quelques cours en réseaux :-$

Bizarre je connaissais quelques points malgré tout mais... comme çà, mis bout à bout, çà m'a tout retourné le bulbe tout d'une fois.... un petit moment de solitude sur l'instant quand même !

Merci pour les précisions et la clarté en tout cas   :Smile: 

Edit: d'autres ont du se garder de dire mais n'en pensaient pas moins - Lâches ! :p

----------

## man in the hill

Très intéressant ... Y en a qui s'amuse ... Prévoir c'est l'art de l'administration et j'admets que j'administre ds la précarité   :Twisted Evil:  .

----------

## loopx

 *guilc wrote:*   

> La seule solution pour faire de la haute dispo (j'ai bien dit la SEULE), c'est que TOUT soit dupliqué. Si un seul élément de ton archi est non-redondant, pouf, un SPOF. Donc il est impossible de n'avoir qu'un seul host à gérer dans tous les cas.
> 
> 

 

Ben, par exemple, on a 2 machines pour le proxy ; elle ne sont pas en cluster. C'est un content-switch qui se charge de répartir sur les 2 ou le seul host qui tourne encore. Ce content-switch est lui-même lié à un autre content-switch (via heartbeat) => cela est du HA, non ? On peut dire que nos proxy sont HA ?

```

workstation => CS1/CS2 => proxy1/proxy2 => internet ...

```

Maintenant, pour la virtualisation ... faut encore que je me renseigne, mais avec vSphere, doit y avoir moyen d'avoir un truc genre "ha" .. mais qu'est-ce que le "ha" exactement ? La reprise du service dans la seconde .. ou dans les quelques minutes ? ...

----------

## loopx

 *guilc wrote:*   

>  *loopx wrote:*   Sinon, la virtualisation sur une seule machine, ok, mais quand tu as 2 machines ... tu relances ta vm sur l'autre   et ca fait donc un HA  
> 
> Ah oui, et la bascule, tu la fais à la main ? tu la synchronises comment ta VM quand le host qui héberge la VM a cramé le disque ? Avec les mimines ? Tu envoie le disque au labo pour récupérer les données de la VM que tu n'as pas synchronisée en temps réel ?

 

 :Laughing: 

Soit tu fais du DRBD, soit tu fous l'image de la VM sur le SAN  :Wink: 

----------

## loopx

 *guilc wrote:*   

> un LB de niveau 7 travaille sur la couche applicative (typiquement HTTP). il va savoir lire les URL, ajouter des cookies, des headers HTTP, faire du filtrage d'URL, etc.. et rediriger le trafic sur une machine ou l'autre en fonction des URL (typiquement, suivant le vhost, aller sur un serveur HTTP différent derrière). Le content switching, c'est ça

 

Pas tout à fait d'accord .. mais pas certain non plus .. mon collègue me dit que nos content-switch travaillent en L3 et pas L7 ... On peut donc travailler avec autre chose que des URL pour faire du LB ... (maintenant, je peux pas en être certain ..)   :Rolling Eyes: 

----------

## kwenspc

Faut qu'il se renseigne ton collègue http://en.wikipedia.org/wiki/Multilayer_switch  :Wink: 

----------

## loopx

 *kwenspc wrote:*   

> Faut qu'il se renseigne ton collègue http://en.wikipedia.org/wiki/Multilayer_switch 

 

Oui ... il me dit que le modèle OSI n'existe pas .. c'est uniquement de la théorie ...   :Shocked: 

Mais bon, en effet, je pense que c'est pas du L3 mais du L4 (session) ...  :Smile: 

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> Mais bon, en effet, je pense que c'est pas du L3 mais du L4 (session) ... 

 

Le modèle OSI a beau être de la théorie (à moitié puisque les premières layer existes bel et bien) il se plante quand même en pensant qu'un content switch bosse en L3. En effet c'est L4.

----------

## kernelsensei

Bon, ça remonte un peu. Mais il y a quelques années j'avais mis un système en place avec OpenVZ (Serveur virtuel) + HeartBeat (pour la disponibilité) + synchro réseau.

En gros, ya 2 machines virtuelles identiques réparties sur 2 machines (hard) différente. Les partoches qui contiennent les machines virtuelles sont synchronisées via le réseau.

Quand une machine (hard) se gaufre, le système HeartBeat le détecte et lance un script sur la machine de backup qui monte la partoche avec les serveurs virtuels et les lance. Quand la machine principale revient à la vie, le serveurs de backup se coupe et les modifications sont synchronisées sur la machine principale.

Je n'ai plus les détails de la mise en place, mais je crois que j'avais suivi des Howtos sur le wiki de OpenVZ. Le système est intéressant, mais n'oublie pas de monitorer tes machines et de te faire envoyer des logs quand les serveurs "switchent", parce que le désavantage d'un système Haute Disponibilité, c'est que tes serveurs peuvent tomber en rade sans que tu t'en rendes compte au premier coup d'œil ^^.

----------

## loopx

 *kernelsensei wrote:*   

> Bon, ça remonte un peu. Mais il y a quelques années j'avais mis un système en place avec OpenVZ (Serveur virtuel) + HeartBeat (pour la disponibilité) + synchro réseau.
> 
> En gros, ya 2 machines virtuelles identiques réparties sur 2 machines (hard) différente. Les partoches qui contiennent les machines virtuelles sont synchronisées via le réseau.
> 
> Quand une machine (hard) se gaufre, le système HeartBeat le détecte et lance un script sur la machine de backup qui monte la partoche avec les serveurs virtuels et les lance. Quand la machine principale revient à la vie, le serveurs de backup se coupe et les modifications sont synchronisées sur la machine principale.
> ...

 

^^intéressant, mais ca m'a l'air fort bricolé tout ca. Ici, je dois respecter le Red Hat rulez ...  Sinon, ca prouve bien que le HA en virtuel, ca existe aussi, sans cluster  :Wink: 

Concernant la synchro des partoches ou se trouve les VM, tu utilisais quoi ? Un disque sur une 3ème machine, ou alors, de la réplication de disque (drbd .. j'essaie actuellement de l'activer sur du red hat) ?

----------

## kernelsensei

Comme dit, ça remonte pas mal, mais si je me souviens bien je m'étais inspiré de ce Howto

----------

## guilc

 *loopx wrote:*   

> Sinon, ca prouve bien que le HA en virtuel, ca existe aussi, sans cluster 

 

Heu, le monsieur devrait relire la définition de cluster. Parceque JUSTEMENT, il a un cluster de 2 machines là, cluster géré via heartbeat (tiens, bizarrement, c'est la même chose qu'on utilise avec des machines physiques...). Virtuel ou pas, les serveurs sont en cluster ici...

----------

## loopx

 *guilc wrote:*   

>  *loopx wrote:*   Sinon, ca prouve bien que le HA en virtuel, ca existe aussi, sans cluster  
> 
> Heu, le monsieur devrait relire la définition de cluster. Parceque JUSTEMENT, il a un cluster de 2 machines là, cluster géré via heartbeat (tiens, bizarrement, c'est la même chose qu'on utilise avec des machines physiques...). Virtuel ou pas, les serveurs sont en cluster ici...

 

C'est du "cluster" au niveau de l'hyperviseur, pas au niveau de la VM ...   :Laughing: 

----------

## guilc

Bon, j'arrête, j'ai l'impression de pisser dans un violon là...

2 machines hard == 2 hyperviseurs, tu peux tortiller du cul tant que tu veux, tu auras obligatoirement 2 hards à gérer, VM ou pas... Et une bascule à gérer entre les 2 hards sous-jacents à tes VM.

----------

## loopx

 *guilc wrote:*   

> Bon, j'arrête, j'ai l'impression de pisser dans un violon là...
> 
> 2 machines hard == 2 hyperviseurs, tu peux tortiller du cul tant que tu veux, tu auras obligatoirement 2 hards à gérer, VM ou pas... Et une bascule à gérer entre les 2 hards sous-jacents à tes VM.

 

Dernière question avant que certain ne finissent par se pisser dessus ... Peut-on considérer "vSphere" comme étant un "cluster" (propriétaire...) ? La définission d'un cluster n'étant pas très précise ...

----------

## truc

 *loopx wrote:*   

>  *guilc wrote:*   Bon, j'arrête, j'ai l'impression de pisser dans un violon là...
> 
> 2 machines hard == 2 hyperviseurs, tu peux tortiller du cul tant que tu veux, tu auras obligatoirement 2 hards à gérer, VM ou pas... Et une bascule à gérer entre les 2 hards sous-jacents à tes VM. 
> 
> Dernière question avant que certain ne finissent par se pisser dessus ... Peut-on considérer "vSphere" comme étant un "cluster" (propriétaire...) ? La définission d'un cluster n'étant pas très précise ...

 

J'me sens dans l'obligation d'intervenir car loopx ne semble pas réaliser que ses propos paraissent, pour le moins, déplacés...

Donc, loopx, j'n'ai rien contre toi, mais tu arrives et poses des questions sur un domaine que tu ne connais pas du tout, nous avons eu le droit à des interventions très constructives par certains, remarquées par d'autres. et malgré cela tu imposes tes idées comme si soudainement tu t'y connaissais et cerise sur le gateau tu te permets même de tourner en dérision les commentaires des personnes venant justement partager leur experience/savoir.

Donc, s'il te plait, décolle toi de l'écran, prends quelques minutes pour penser à la vie, le ciel, la nature, 'fin ce que tu veux, puis reviens si tu te sens mieux:)

----------

## guilc

J'avoue, j'étais un peu irrité aussi quand j'ai écrit mon message, d'où les expressions utilisées qui peuvent paraitre un tantiné agressives. Et je m'en excuse  :Rolling Eyes: 

----------

## kernelsensei

Merci pour cette intervention truc.

Effectivement loopx, dans cette discussion j'ai l'impression que tu ne maitrises pas vraiment le sujet sur lequel tu tiens des affirmations... 

La situation s'est un peu tendue, mais bon, rien de dramatique  :Smile:  Comme l'a dit truc, ya juste a respirer un bon coup  :Wink: 

----------

## loopx

Heu, j'avoue ne pas comprendre votre frustration .. je vais boire mon café et relire tout depuis le début ...

Il faut pas se mettre en rogne comme ca, c'est un forum, j'ai lu beaucoup et j'avais juste des questions. Forcément que je n'y connais rien, je ne serais pas venu voir ma communauté préférée sinon ...

EDIT: voilà, je viens de tout relire. Première chose, je trouve ca dommage que cette conversation soit suivie au 1er degré sans que l'on puisse dire un truc erroné. Deuxièmement, le forum est la pour aider les gens qui, justement, on des lacunes (je n'ai jamais eu ce comportement envers quelqu'un qui n'avais pas compris .. au contraire, je lui donne plus d'argument et je ne pisserais jamais dans un violon). Troisièmement, si je "fait des affirmations", c'est pour essayer de recouper mes connaissances avec les vôtres et surtout, ne pas faire confiance à 1 seule personne (d'ailleurs, un informaticien le sais très bien).

4: quand j'ai posé des questions avec affirmations, c'est pas pour me moquer, c'est pas pour dire que c'est faut, c'est uniquement pour comprendre avec le plus de précision possible. Or cela, bof, on me dit que, mais c'est tout, aucune précision ou plutôt, on n'a pas vraiment, écouté et cherché à comprendre pourquoi je revenais la dessus. La question reste posée : un système de virtualisation (2x hyperiseurs + heartbeat) .. je bouge du cul si tu veux, il y a un heartbeat oui, mais est-ce vraiment un HA ? Je ne parle pas de la machine physique, je parle de la/les machines qui sont présentes dans cet hyperviseur (et je le redis car visiblement, ca n'a pas été entendu). Donc la question, elle doit être prise au niveau de la VM (car imaginer, l'hyperviseur est installé depuis 5 ans .. qu'est-ce que je m'en fou de cet hyperviseur ? je parle des VM). Et pour moi, il est claire que si tu as un hyperviseur qui sais relancer tes VM (à la seconde ou après 1 minutes), c'est (peut être) du HA (mais encore une fois, aucune réponse à ce sujet). Personne n'a vraiment eu un argument pour me casser ces "affirmations" (dont kernelsensei à d'ailleurs parlé).

Pour ne rien arranger, je vais ajouter ceci : une technique de virtualisation (nouvelle visiblement, uniquement dispo chez VMware) consiste à faire tourner une même machine en "hot standby". Il y a réplication de la mémoire RAM de la VM sur l'hyperviseur A vers l'hyperviseur B qui héberge la même machine en "hot standby". Si la machine hyperiseur A plante ... bah, l'autre (en hot standby) prend la relève et continue la ou s'était arrêté la première. Est-ce que cela fonctionne vraiment, aucune idée, je n'ai jamais testé, c'est juste un truc que j'ai entendu parlé.

Alors, est-ce que cela vaut vraiment la peine de se frustré ainsi parce que "l'autre ne veux pas m'écouter!" ... ben non, voilà, non. Je ne comprend toujours pas vraiment pourquoi un tel emballement ridicule.

Ce thread peut être clôturé, j'ai mes réponses et, malgré tout, c'est moi qui devient frustré ; j'ai quand même obtenu réponse au principale question.

Merci, 

A bientot, peut être.

----------

## man in the hill

Salut,

Je compte mettre en place mon premier système ha avec des vm ...

@ Loopx:   j'aimerais savoir si tu as mis un système en place qui te satisfait ?

Le système à la kernelsensei m'intéresse avec :

- drbd sur la partition home ou je place mes vm

- heartbeat + script pour démarrer les vm sur le serveur secondaire

Petite ? : Est-ce drbd ne pompe pas trop de ressources réseaux et de ressources sur le serveur primaire pour copier les données sur le hard disk ?

Autre ? : Connaissez vous un prog qui me ferait de la sauvegarde temps réel d'un répertoire par ex vers disque externe ?

----------

## guilc

 *man in the hill wrote:*   

> Petite ? : Est-ce drbd ne pompe pas trop de ressources réseaux et de ressources sur le serveur primaire pour copier les données sur le hard disk ?

 

Bah ça dépend de tes débits d'écriture disques ça.

Pour le réseau, ça se bride dans la configuration, mais ça tient pas mal. Perso, je bride mes synchros à 300Mbits (sur du gigabit of course), drbd monte bien à ce débit (sans gêner).

Et pour les ressources sur le master, ça génère un peu d'iowait. Je tourne en général à 8% d'iowait (sur 400% : xeon quad) en utilisation nominale. Il "semblerait" que cela se règle et soit dû au tcp offloading et certains conseillent de le désactiver (cherche "DRBD TOE" dans google), mais cela n'a jamais rien changé dans mon cas.

 *Quote:*   

> Autre ? : Connaissez vous un prog qui me ferait de la sauvegarde temps réel d'un répertoire par ex vers disque externe ?

 

temps réel, pas vraiment (enfin, ce n'est pas ce qu'on appelle vraiment temps réel, mais de loin ça peut y ressembler) : un truc du genre lsyncd ou csync2, qui utilise inotify pour déclencher des rsync, ça marche plutôt bien. C'est comme ça que je fais un backup automatique du share bureautique

----------

## geekounet

 *guilc wrote:*   

>  *man in the hill wrote:*   Autre ? : Connaissez vous un prog qui me ferait de la sauvegarde temps réel d'un répertoire par ex vers disque externe ? 
> 
> temps réel, pas vraiment (enfin, ce n'est pas ce qu'on appelle vraiment temps réel, mais de loin ça peut y ressembler) : un truc du genre lsyncd ou csync2, qui utilise inotify pour déclencher des rsync, ça marche plutôt bien. C'est comme ça que je fais un backup automatique du share bureautique

 

J'appelle pas vraiment ça un backup, plutôt une simple réplication temps-réel, parce que si tu fais un rm -rf du répertoire en question, il le sera également sur le réplicat, pas bien pratique comme "backup"...  :Razz: 

----------

## guilc

 *geekounet wrote:*   

>  *guilc wrote:*    *man in the hill wrote:*   Autre ? : Connaissez vous un prog qui me ferait de la sauvegarde temps réel d'un répertoire par ex vers disque externe ? 
> 
> temps réel, pas vraiment (enfin, ce n'est pas ce qu'on appelle vraiment temps réel, mais de loin ça peut y ressembler) : un truc du genre lsyncd ou csync2, qui utilise inotify pour déclencher des rsync, ça marche plutôt bien. C'est comme ça que je fais un backup automatique du share bureautique 
> 
> J'appelle pas vraiment ça un backup, plutôt une simple réplication temps-réel, parce que si tu fais un rm -rf du répertoire en question, il le sera également sur le réplicat, pas bien pratique comme "backup"... 

 

Bah en fait, ca dépend : pour lsyncd, tu indiques toi-même les options de rsync, tu peux dire de pas faire le delete  :Wink: 

Ca ressemble à ça :

```
    <callopts>

      <option text="-Pvt%r"/>

      <option text="--delete"/>

      <option text="-T /tmp/"/>

      <option text="-e ssh"/>

      <option text="--bwlimit=50"/>

      <exclude-file/>

      <source/>

      <destination/>

    </callopts>

```

----------

