Forum Linux.général Résolu - Recherche solution SIMPLE pour monter un cluster FailOver

Posté par  . Licence CC By‑SA.
Étiquettes :
1
11
mai
2015

Bonjour,

Je suis à la recherche, comme l'indique le titre, d'une solution simple pour monter un cluster FailOver

L'idée est relativement simple :

  • j'ai trois serveurs : un en production / deux de secours
  • le serveur de production écoute plusieurs adresses IP (une par site Internet)
  • s'il vient à y avoir un soucis sur le serveur de production, un des serveurs de secours doit :
  • ajouter une règle (ip rule add) si elle n'existe pas
    • ajouter une route (ip route add) si elle n'existe pas
    • monter les adresses IP des sites Internet
    • envoyer une requête arping vers le routeur de l'hébergeur pour prendre en compte le changement de machine

J'ai donc créé un script pour me simplifier ces opérations en cas de bascule manuelle.
Je cherche maintenant la solution pour automatiser cette tâche en cas de soucis.

J'ai regardé 'HeartBeat' mais il ne semble plus maintenu et est un peu lourd pour exécuter un simple script.

J'ai regardé le couple Corosync + Pacemaker : il est également trop lourd pour exécuter un simple script et me semble bien mal documenté. J'ai trouvé un blog d'une personne expliquant comment créer une ressource permettant d'exécuter un script mais il ne livre pas l'exemple du dit script. Hors, les codes retours attendus ne sont pas super simples à prendre en main selon l'état dans lequel on se trouve et le comportement est assez bizarre entre le test (ocf-tester) et l'exécution automatique.

Je suis en train de regarder KeepAlived mais j'ai pas l'impression que ce soit la solution la plus adaptée. Il permet bien l'exécution de scripts mais il me semble que c'est une fonction "bonus" donc j'en arriverais à un usage "détourné" du produit.

Est-ce que quelqu'un aurait une solution simple mais efficace pour ce soucis ?
Je n'ai pas besoin de synchronisation DRBD etc : juste lancer un script avec des arguments de manière simple et efficace.

Pour la partie réseau, j'ai deux cartes réseaux :

  • une qui a une adresse IP publique propre au serveur
  • une qui peut porter un bloc d'IP publiques mais également des IP locales

Les serveurs sont physiquement distants puisque dans plusieurs datacentres. Je compte donc utiliser les IP locales pour la communication du cluster.

Je vous remercie d'avance.

  • # Keepalived

    Posté par  . Évalué à 2. Dernière modification le 11 mai 2015 à 17:26.

    Salut,

    J’ai eu une problématique légèrement différente, j’ai utilisé keepalived. C’est sur un réseau privé pour un démonstrateur, donc pas d’IP publiques (donc d’achat de plage…).

    Nous avons un certains nombres de serveurs (n que je prendrais == 3). Les trois serveurs répondent aux requêtes pour répartir la charge. Chaque serveur a une IP à lui : ip1, ip2, ip3. Ensuite, chaque serveur à n - 1 ip virtuelle, soit 2 dans notre cas. (ipv1.1, ipv1.2, ipv2.1, ipv2.2, ipv3.1 et ipv3.2). Ces adresses sont donnée à keepalived en le configurant pour que ipv1.1 soit maître sur le serveur 1, puis secondaire sur le serveur 2 et enfin tertiaire sur le serveur 3. La deuxième adresse du serveur 1 ipv1.2 est maître sur le serveur 1, mais secondaire sur le serveur 3 et tertiaire sur le serveur 2. Ainsi de suite pour les autres adresses virtuelle.

    Une configuration DNS pour faire tourner l’adresse (serveur.chezmoi) en round robin sur les n × (n - 1)(6 ici) IP virtuelles.

    De cette manière, si le serveur 2 tombe, le serveur1 répondra aux requêtes ipv1.1, ipv1.2, ipv2.1 et le serveur 3 répondra aux requêtes ipv3.1, ipv3.2, ipv2.2.

    Cette solution réparti la charge en plus d’assurer la tolérance aux pannes, mais demande beaucoup d’IP.

    De ce que je comprends de ton besoin, une seule IP virtuelle devrait suffire. Si le premier tombe, le second répondra.

    • [^] # Re: Keepalived

      Posté par  . Évalué à 1.

      Bonsoir,

      Je te remercie pour ta réponse mais nos deux cas ne m'ont pas l'air comparables et ta solution me parait bien compliquée pour ce que je veux faire :-/

      Dans mon cas :

      • plusieurs IP publiques sur plusieurs de ces 3 serveurs : une seule machine doit être master à la fois
      • plusieurs serveurs qui écoutent la même IP (la solution technique de mon hébergeur ne permet pas ce genre de chose)
      • je ne peux rien faire niveau DNS : UNE adresse IP = UN site ou UN service selon ce qui se trouve derrière
      • la machine qui reçoit les connexions est déjà un répartiteur de charge donc je n'ai pas besoin de ce type de fonctionnalités

      Dans l'idéal, le soft que je cherche dirait :

      • telle machine est maître
      • telle machine est esclave
      • telle machine est esclave
      • le maître tombe (non joignable par aucun des deux slaves) : un des esclave est élu maître
      • à partir du moment où il est élu maître, il exécute un script

      S'il y a en plus une notion de votant uniquement (un peu comme un ReplicaSet MongoDB) c'est encore mieux car je pourrais déclarer 2 ou 3 arbitres supplémentaires pour répartir le risque.

      • [^] # Re: Keepalived

        Posté par  . Évalué à 3.

        ce que tu cherches, c'est exactement le fonctionnement de keepalived.

        3 machines sur le reseaux, discutant en reseau privé, meme avec une seule carte reseau.

        les IPs publiques sont dans le pool de keepalived,
        tu definies des poids pour chaque machine,
        tu as donc une machine master, une machine slave1 et une slave2.

        et si tu es "gourmand" tu peux meme jouer des ponderations pour ventiler tes services sur les 3 serveurs, chacun avec ses IPs,
        mais etant configué en slave sur les autres.

        exemple :
        ServeurA : Master sur siteA,siteB,siteC, Slave sur SiteD,SiteE,SiteF
        ServeurB : Master sur SiteD, Slave sur siteA,SiteB, SiteC, SiteE,SiteF
        Serveur C : Slave sur SiteA,SiteB,SiteC,SiteD,SiteE,SiteF

        le probleme qui vient ensuite et que resoud corosync, c'est la synchro des données (code html,php, base de données) entre les 3 serveurs.

        • [^] # Re: Keepalived

          Posté par  . Évalué à 1.

          Bonjour,

          Je te remercie pour ta réponse.

          Je viens de finir quelques tests avec KeepAlived sur 3 nœuds : effectivement il est bien plus simple que Heartbeat ou le couple ( Corosync + Pacemaker) et semble répondre au besoin très simplement.

          Par contre, je bloque quand même sur quelque chose de simple : j'ai un pare-feu iptables sur chaque nœud qui autorise toutes les connexions en sortie mais limite les protocoles autorisés en entrée (exemple : http + https).
          Je n'ai rien configuré pour KeepAlived et il fonctionne quand même : pourquoi ?
          Peut-être que je me trompe mais cela signifie qu'une personne mal intentionnée pourrait, en ayant trouvé le mot de passe, s'incruster dans mon cluster KeepAlived ?!

          • [^] # Re: Keepalived

            Posté par  . Évalué à 2.

            keepalived utilise du broadcast pour se signaler sur le reseau,
            ce sont les trames "VRRP" si je ne me trompe pas.

            tout comme le ping est une trame ICMP.

            DOnc oui, quelqu'un qui ecoute sur ton reseau, pourrait se faire passer pour master en emettant à son tour les trames, mais seulement à condition de trouver le bon mot de passe à envoyer dans le broadcast

            • [^] # Re: Keepalived

              Posté par  . Évalué à 1.

              C'est vraiment bizarre car j'avais trouvé ceci :
              http://www.armetiz.info/keepalived-configuration-firewall/?PageSpeed=noscript

              On voit bien une configuration iptables pour autoriser la communication. Moi je n'ai rien autorisé et ça fonctionne. Bizarre non ?
              Je veux bien ouvrir le protocole vrrp mais pour telle et telle machine source pas plus ;-)

              • [^] # Re: Keepalived

                Posté par  . Évalué à 2.

                oui mais non.

                avec le parefeu tu vas juste interdire à une machine de recevoir le flux
                ou à ta machine d'emettre le flux.

                mais VRRP/keepalived c'est du broadcast,
                du moment que ca sort de la machine master, ca arrose les machines du reseau.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.