Bonjour,
J'aurai une question par rapport au schéma suivant :
http://niconux.be/files/network.png
Donc dans cette topologie on utilise keepalived (VRRP) et conntrackd sur les deux firewalls qui sont des boxs Debian.
Cette configuration est testé en laboratoire et marche assez bien à une exception près :
Si le trunk entre les deux switches tombe (normalement le lien est redondant) alors le slave va passer en master mais le master ne va pas se mettre en fault. J'ai donc à ce moment deux masters.
Il se trouve que les serveurs derrière ces firewall sont tous en ethernet bonding avec l'option arp_ip_target du module en question. Cela veut dire qu'ils vont tous continuer à utiliser la même interface car ils auront toujours un firewall master directement connecté sur leur switch. Par contre si je n'ai plus qu'un seul firewall actif, les serveurs vont automatiquement migrer sur le bon switch.
La ou cela devient beaucoup plus embêtant, c'est dans le cas ou le traffic à destination d'un serveur se retrouve sur un switch et devrait passer sur le second (donc par le trunk) car l'interface active du serveur serait branchée sur le second switch.
En fait ce que je voudrais c'est éviter d'avoir deux master en même temps. Quelqu'un a une idée sur une manière propre de réaliser cela ?
Merci d'avance,
# heartbeat
Posté par geb . Évalué à 3.
Tu peux regarder du coté de heartbeat, plus particulièrement de http://www.linux-ha.org/STONITH .
[^] # Re: heartbeat
Posté par PLuG . Évalué à 1.
Ce que tu cherche a éviter s'appele "split brain" en technologie cluster (les 2 sont actifs) et cela arrive parce que le protocole/la méthode pour que les 2 nodes du clusters négocie leur état ne fonctionne plus, du coup comme ils ne se "voient" plus l'un/l'autre ils deviennent master tous les deux.
En réseau en général on s'en fou un peu. Par exemple si un switch dégage, que le routeur connecté dessus devienne master n'est pas grâve puisque les machines ne pourront pas le joindre (a cause de la panne du switch).
Par contre en technologie de cluster c'est gravissime, l'application devient active des deux cotés et les données peuvent être complètement détruites (montage d'un même filesystème en ecriture par les deux nodes simultanément, ...). Du coup pour les clusters, la méthode est de rendre ce "protocole" de communication entre les deux clusters vraiment fiable, impossible de le faire tomber en panne.
Heartbeat implémente ça, en multipliant les liaisons (reseau, séries, ...) entre tes deux machines. Dans ton cas avec des parefeux, tu pourrais utiliser plusieurs cartes réseau connectées sur plusieurs switchs eux même reliés entre eux avec plusieurs trunks ... et ajouter une liaison série "au cas ou". La cela devient autement improbable de passer en "split brain".
# differentes prio
Posté par stillbsd . Évalué à 1.
C'est bien ton cas -> http://marc.info/?t=121335384300002&r=1&w=2 ?
J'aurais aussi conseillé d'avoir des priorités différentes sur les noeuds.
2 switches, c'est chiant finalement :-(
[^] # Re: differentes prio
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
Ce que je veut c'est d'éviter que les noeuds se retrouvent master simultanément dans le cas ou ils sont isolés (car trunk coupé). Notez aussi que c'est improbable que ça arrive vu que ce lien sera redondant, mais bon...
# 802.3ad, stp, tout ça...
Posté par nodens . Évalué à 2.
Avec une communauté lacp entre les switches, et un peu de spanning tree, ça évite les boucles, et ça devrait résoudre ton souci : avoir à la fois le trunk (2 liens) et l'interface connectée à l'autre switch qui tombe, ça devient vraiment improbable. Tu as plus de chance de voir les deux switches ou les deux firewall cramer en même temps.
Tu peux utiliser utiliser la méthode STONITH (Shoot The Other Node In The Head), chère à keepalived pour t'assurer de n'avoir qu'un master à la fois : tu fais un script qui tombe les interfaces frontales de l'autre firewall (ou désactive les ports du switch...) quand tu passe master si tu arrive toujours à le joindre par une autre interface, et tu l'appelles quand tu passe en état "master".
Il y a sûrement d'autres méthodes, et je suis sûr qu'on peut imaginer d'autres scénarios catastrophe, c'est toujours la m*** quand on mélange L2 / L3 et qu'on veut être redondant.
[^] # Re: 802.3ad, stp, tout ça...
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
Parce-que en load balancing sur du multi chassi, d'après mes renseignement ça ne marchera pas avec un switch pure level 2 cisco (y faudrait un switch layer 3).
[^] # Re: 802.3ad, stp, tout ça...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Il est possible de le faire sur plusieurs switchs si ceux-ci peuvent être empilés en une seul entité logiques et finalement fonctionner comme un seul et unique switch. Mais généralement les possibilités d'assembler des switchs en une entité logique est propre au fabricant.
Donc à priori sur le schéma proposé, il n'est pas possible d'utiliser le 802.3ad.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 802.3ad, stp, tout ça...
Posté par nodens . Évalué à 2.
[^] # Re: 802.3ad, stp, tout ça...
Posté par nodens . Évalué à 2.
Je voulais évidemment dire : « chère à heartbeat ». Ma langue a fourché. (et ici, il ne s'agit donc pas d'autosatisfaction récursive mais de contrôle qualité ;-) )
# Shoot The Other Node In The Head
Posté par Bruno Muller . Évalué à 0.
Voir par exemple http://www.linux-ha.org/STONITH
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.