VRRP et question réseau

Posté par Henry-Nicolas Tourneur (site web personnel) le 27 juillet 2009 à 14:14.

Étiquettes : aucune

juil.

2009

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 le 27 juillet 2009 à 22:57. Évalué à 3.

Je ne suis pas sûr que cela soit une réponse très pertinente mais:

Tu peux regarder du coté de heartbeat, plus particulièrement de http://www.linux-ha.org/STONITH .
- [^] # Re: heartbeat
  
  Posté par PLuG le 29 juillet 2009 à 00:23. Évalué à 1.
  
  si si c'est pertinent, mais c'est une autre approche.
  
  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 le 28 juillet 2009 à 01:28. Évalué à 1.

Hello,

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) le 28 juillet 2009 à 11:01. Évalué à 1.
  
  Non non, les priorités sont bien différentes.
  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 le 28 juillet 2009 à 02:23. Évalué à 2.

Je pense que le mieux est (en fonction du nombre d'interfaces évidemment) de faire un bonding 802.3ad avec 2 interfaces sur les firewall pour les connecter aux 2 switches.

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) le 28 juillet 2009 à 11:30. Évalué à 1.
  
  Quand tu parle de 802.3ad tu parle en faill over ou bien en laod balancing ?
  
  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) le 28 juillet 2009 à 15:22. Évalué à 2.
    
    Si j'ai bien compris le 802.3ad, ça permet de réunir diverses liens comme un seul et unique lien, ce qui permet de faire à la fois du "load balancing" et du "failover". Dans le sens où tous les liens disponibles vont être utilisés pour communiquer. Mais ce protocole ne fonctionne pas si les liens sont sur des switchs différents.
    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 le 29 juillet 2009 à 23:26. Évalué à 2.
      
      Etienne a bien résumé le problème du LB sur des switches différents. De toutes manières, il n'y a pas d'intérêt à faire du load-balancing ici : il s'agit juste de limiter le risque de bascule intempestive. Donc fail-over.
- [^] # Re: 802.3ad, stp, tout ça...
  
  Posté par nodens le 29 juillet 2009 à 23:28. Évalué à 2.
  
  Tu peux utiliser utiliser la méthode STONITH (Shoot The Other Node In The Head), chère à keepalived
  
  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 le 28 juillet 2009 à 19:04. Évalué à 0.

Enfin, sur le principe... après il y a plusieurs façons de faire.

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.