Forum Linux.debian/ubuntu failover services entre sites distants sous debian

Posté par .
Tags : aucun
1
12
juin
2009
Bonjour à tous,
je dois mettre en place une solution de failover sur une application critique composée d'un serveur web/applicatif (debian/appli java) et un serveur de base de données (debian/mysql).
Le système doit pouvoir palier tout type de panne :
- en cas de coupure réseau (au niveau du des élements actifs du réseau local, du datacenter lui-même)
- en cas de panne système/hardware
- plantage de l'applicatif - point le plus probable :(
- attaque nucléaire, extraterrestre ou autre - mais je pense pouvoir gérer ce dernier point... :D

Pour cela je dispose d'une unique machine hébergé dans un autre data-center (donc dans un réseau différent).

1- ma première problématique : Faire du failover sur des réseaux différents uniquement via ethernet...

2- Le deuxième problème est que le système à rendre résistant aux pannes est déjà en prod...

3- Qu'à terme il est possible que je doive également implémenter du load balancing sur l'applicatif...

ça fait 2 jours que je suis dessus... la tête dans le guidon je surchauffe et me perds un peu... :(
et je ne vois toujours pas de solution...
si vous pouviez me faire partager votre expérience ou me donner quelques pistes (ou solutions :D, je suis pas contre !)
d'avance merci de votre soutien...
  • # drdb / heartbeat / ...

    Posté par (page perso) . Évalué à 2.

    drdb / heartbeat / channel bonding / ...

    Système - Réseau - Sécurité Open Source

    • [^] # Re: drdb / heartbeat / ...

      Posté par . Évalué à 1.

      merci nono14...
      cependant, ôtes moi ces doutes qui me tiraillent....
      - heartbeat ne nécéssite-t-il pas une liaison série ? dans mon cas, ce n'est pas envisageable...
      - le channel bonding assure une redondance d'interface réseau sur même machine non ?
      peut-être je me trompais-je, et dans ce cas je ne suis pas contre quelques ressources webesque qui rectifient mon ignorance en la matière... ;)
      • [^] # Re: drdb / heartbeat / ...

        Posté par (page perso) . Évalué à 1.

        -heartbeat peut fonctionner par ethernet
        -oui ( http://linux.developpez.com/bonding/ )

        Système - Réseau - Sécurité Open Source

        • [^] # Re: drdb / heartbeat / ...

          Posté par . Évalué à 1.

          merci merci je me plonge dedans tout de suite :)
          • [^] # Re: drdb / heartbeat / ...

            Posté par . Évalué à 1.

            bon oki, pour heartbeat en ethernet... autant pour moi...
            par contre - je suis un boulet... je l'avoue -
            le channel bonding entre "interfaces de réseaux distants"
            ben je comprends toujours pas comment on fait.... 8(
            si t'as 2 minutes pour m'expliquer ou un lien magique à destination des neuneus... :D
            • [^] # Re: drdb / heartbeat / ...

              Posté par (page perso) . Évalué à 1.

              Le channel bonding est bien conçu pour la redondance d'interface réseau.

              Ensuite c'est ip qui prend le relais.C'est le rôle des routeurs ( bgp/ospf) d'assurer
              que tout va bien.

              La magie en informatique ça n'existe pas. :-;

              Système - Réseau - Sécurité Open Source

  • # 2 datacenter separés = 2 plan IP separé

    Posté par . Évalué à 2.

    ca va pas etre simple question routage tout ca

    en tout cas pas en temps reel

    deja regarde pour monter ta nouvelle machine avec l'appli et la base de données
    faire en sorte que ca marche bien

    ensuite reflechis à la synchro entre la machine de prod et le backup (failover)

    ensuite tu pourras essayé de faire une bascule en automatique (peut-etre au niveau des DNS) le jour ou cela tombe en panne
    • [^] # Re: 2 datacenter separés = 2 plan IP separé

      Posté par . Évalué à 1.

      merci NeoX !!! je me sens moins seul... ça fait du bien...

      une nouvelle install de l'appli/donnée ne devrait (je préfère au conditionnel) pas poser de pb
      pour la synchro, je pensais à du simple rsync ou de l'unison et de la replication mysql pour les bases...

      qt à la solution dns failover, le pb, c'est la latence de propagation de la mise à jour...
      même avec un ttl faible... on ne peut pas espérer des résultats fantastiques...
      l'interruption si il y en a une... doit être minimale... et sachant que c'est une appli qui concernent des clients des 4 coins de la planète... j'ai du écarter cette solution... :(
      • [^] # Re: 2 datacenter separés = 2 plan IP separé

        Posté par . Évalué à 2.

        si ton probleme est là latence DNS

        il faut alors que tu regardes les solutions à base d'IP virtuelle

        ta machine en prod dispose d'une IP "vraie"
        et d'une ip virtuelle

        la machine backup interroge le service afin de savoir si la prod est en route
        sinon, elle reprend cette ip virtuelle

        cette solution fonctionne tres bien dans un meme datacenter car le routage vers cette ip virtuelle ne change pas (ma machine ici par exemple parlera touours au meme routeur pour acceder à ton datacenter, donc la bascule est transparente)

        par contre entre 2 datacenters ?
        je crains qu'il faille jouer avec les routeurs pour dire que finalement cette ip virtuelle ne se trouve plus dans ce datacenter...
        et si tu joue avec les tables de routages, tu auras aussi un temps de propagation

        enfin, je dis ca dans le cas ou les 2 datacenters sont dissocié l'un de l'autre
        si tu as un lien permanent et "interne" à ton reseau entre les 2 datacenters
        la problematique ne se pose presque plus
        • [^] # Re: 2 datacenter separés = 2 plan IP separé

          Posté par . Évalué à 1.

          les 2 datacenters sont bien dissociés l'un de l'autre... :(
          et il n'y a pas à priori possibilité d'avoir de liaison privée entre les 2...
        • [^] # Re: 2 datacenter separés = 2 plan IP separé

          Posté par (page perso) . Évalué à 1.

          Oui le protocole Vrrp utilisé dans certaines solutions n'est pas routable, de plus il fonctionne sur le perte de lien entre les deux machines (si le backup ne reçoit plus de signal du master, il devient lui même master) donc ce n'est pas envisageable par Internet.

          C'est valable pour Ucarp ou keepalived par exemple
    • [^] # Re: 2 datacenter separés = 2 plan IP separé

      Posté par (page perso) . Évalué à 5.

      >>>ca va pas etre simple question routage tout ca

      >>>en tout cas pas en temps reel

      C'est là qu'on se dit que certaines technos propriétaires sont bien foutues, je pense au Cluster VMS
      Après le 11 Septembre, aux US, ils envisageaient des Clusters VMS sur 800 Kms de distance (le max vu la latence maximum du protocole Cluster (60-07 sous Ethernet) justement en cas d'attaque nucléaire sur New York par exemple, avoir de la redondance immédiate (juste une Cluster transition, de l'ordre de 1 minute, c'est paramétrable)

      >>>ensuite reflechis à la synchro entre la machine de prod et le backup (failover)
      Dans un Cluster à la VMS, toutes les machines (prod et backup) ont les mêmes données, il n'y a rien à faire.
      C'est un sacré avantage par rapport à tous les plans de reprise/de continuité d'activité, dans lesquels on se rend compte un peu tard qu'on a oublié un truc ou un autre.

      Dans l'incendie du Crédit Lyonnais, il y avait des machines(3 de mémoire) boulevard des Italiens (Paris 2 ème) et les machines de secours chez GSI à Suresnes.
      L'incendie a eu lieu le week-end, et ca a coûté très cher à certains traders qui avaient parié que le Crédit Lyonnais ne pourrait pas honorer ses positions le lundi matin. Pas de souci, toutes les données étaient là.

      Le 11 septembre, le seul Cluster Vms qui n'a pas survécu avait ses machines dans les 2 tours (boulette)...tous les autres ont repris sans perte de données.

      Le libre propose des choses proches, je ne sais pas où en sont les projets OpenSSI, OpenMosix ou Kerrighed.

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

  • # voir avec ton fai ?

    Posté par . Évalué à 2.

    Je pense que si tu veux une bascule totalement transparante entre tes deux machines la solution se trouve au niveau de ton opérateur.
    Comme dit dans un poste précédent , la modif du dns va prendre du temp a se propager. Il reste donc le déplacement de l'ip entre tes deux machines. Pour que le routage fonctionne il faut que le routage de ton ip publique soit modifié ...

    Entre solution : un reverse proxy/faillover (clusterisé) de préference chez un opérateur ...

    A mon avis pas de solution miracle à bas cout...
    • [^] # Re: voir avec ton fai ?

      Posté par . Évalué à 1.

      avoir la main sur le routage de l'ip publique ou la faire modifier...
      je sais pas dans quelle mesure c'est possible de négocier....

      un reverse proxy... effectivement, c'est une piste à laquelle je n'avais pas songée...
      merci, je sors ma pelle et je creuse la question ;)
      • [^] # Re: voir avec ton fai ?

        Posté par . Évalué à 1.

        Si tu heberges toi meme on reverse proxy tu restes vulnérable à une perte de ton DC. A une époque je bossais avec orange qui proposait ce service ( à travers des appliance RP clusterisée, je me souviens plus du nom) ...
  • # Commentaire supprimé

    Posté par . Évalué à 2.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Commentaire supprimé

      Posté par . Évalué à 2.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Architecture possible

        Posté par (page perso) . Évalué à 2.

        >Supposons que tu ais 5 incidents par mois càd 25 minutes de mode dégradé (réponse 1
        >fois sur 2 car 2 ip's retournées par le DNS) cela donne un uptime, à la louche, de 99,94%.
        >As-tu vraiment besoin de mieux que ça ?

        >Si c'est le cas, je te souhaite bon courage...

        C'est le problème courant: combien est-tu prêt à mettre pour ton PRA/HA
        sachant que rien n'est magique et que la solution "ultime" est souvent a base
        de BGP et d'un lien privé d'interconnection entre tes deux sites pour la synchro.

        Et que tu ne bascule pas ce genre d'archi avant moins de 20min d'interruption.

        Si tu a besoin de plus et si ton problème est lié à l'application il est beaucoup plus
        efficace et moins cher de disposer d'une archi HA sur le même datacenter (et garder
        une archi "PRA" sur un autre datacenter si besoin).

        Le HA en local se fait très bien, a base de VRRP/Keepalive souvent il permet des reprises
        de services <1s (+délai de détection, et attention au flapping).

        Le PRA en distant permet de se prémunir des derniers "risques"

Suivre le flux des commentaires

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