Forum Linux.debian/ubuntu Keepalived / VRRP et question réseau

Posté par (page perso) .
Tags : aucun
1
27
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 . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.