Forum Linux.général Serveur de secours - effectuer la transition

Posté par  .
Étiquettes : aucune
4
20
avr.
2012

Bonjour,

J'ai un serveur perso (debian, x86), qui gere en gros mes mails et d'autre petites choses, chez moi, sur ma connection ADSL.
Comme cette derniere n'est pas d'un fiabilité absolue, j'envisage de mettre un petit serveur de secours chez mes parents (c'est un dockstar, une toute petite chose genre plug-computer, en arm).
Le dns de mon domaine est externalisé, géré par OVH. Je me suis donc dis qu'il suffisait que je renseigne les IPs de mes deux serveurs pour que si ma connection ADSL ou mon serveur tombe, le dockstar prenne le relai.

Se pose la question de la synchronisation des données. Pour l'instant, un rsync envoie le /home de mon serveur principal vers le dockstar toutes les heures. Le dockstar est donc a peu près à jour, et capable de prendre le relai.

Mon probleme est, comment gérer la remise en route du serveur principal. J'avais pensé à:
- quand le serveur principal tombe, le dockstar arrete les rsync (pour eviter un ecrasement au redemarrage du serveur principal), et spamme le serveur principal de message indiquant qu'il a pris la main
- quand le serveur principal redemarre/redevient dispo, éteindre postfix partout
- effectuer la synchro (les mails sont stockés en maildir, donc je peux me contenter de ne garder que les fichiers les plus recents)
- reactiver postfix, reactiver les rsyncs.

Mais ca me semble en vrai un peu compliqué à mettre en place, il va me falloir faire des pings et des "ssh serveurprincipal touch unfichier" dans tous les sens, pour verifier que c'est bien le serveur et pas la connection qui est down, etc… Et tout ca sans vraiment avoir l'occasion de tester avant de le faire "grandeur nature".

J'ai envisagé de faire du clustering, mais d'une part, ca me semble un peu overkill, et d'autre part, avec des installations et des archis differentes sur mes 2 serveurs, je sens venir les maux de tête.

Est-ce que quelqu'un a déjà fait ce genre de chose ? Des idées de solution elegante ?

  • # pas de solution pour tout mais un debut

    Posté par  . Évalué à 5.

    pour les emails faut jouer du MX

    MX 1 chez toi
    MX 2 chez tes parents

    le serveur chez tes parents etant reglé pour accepter les emails @tondomaine
    et pour les transmettre à serveurcheztoi.

    par definition, si moi, je veux envoyer un email @tondomaine
    ca va tenter sur MX 1, si ca repond, MX1 prend l'email, tout va bien.
    s'il ne repond pas, ca va essayer sur MX2, mx2 prend l'email, et le stocke jusqu'au retour du serveur chez toi.

    pour les autres services, ca depend de ce qu'ils sont.
    tu peux regarder du coté de DRDB pour les systemes de fichiers distribués (maitre-esclave)
    avec heartbeat par exemple pour detecter que servercheztoi est down/injoignable et basculer le disque DRDB en maitre sur le serveur de tes parents.

    heartbeat peut faire la meme chose avec les autres services, mais apres va falloir jouer du DNS dynamique pour dire que www.tondomaine.com va sur l'IP de tes parents au lieu de celle de chez toi.

    • [^] # Re: pas de solution pour tout mais un debut

      Posté par  . Évalué à 1.

      Merci de cette réponse. Pour les MX, c'était déjà ce qui était prevu. Je viens de me rendre compte que la même chose n'était malheuresement pas possible pour les enregistrements de type A, mais c'est pas critique, je n'ai qu'a déclarer un backup.mondomaine.tld
      DRBD, ca sera pour la prochaine fois que je mets jour mon serveur et mes disques (avec l'encryption, d'ailleurs), j'ai pas trop envie de tout migrer. Mais je le garde precieusement de coté.
      Heartbeat correspond bien a ce que je veux, je n'avais pas vu qu'on pouvait l'utiliser seul (le projet linux-HA m'avait l'air d'un gros truc tout-en-un). Reste a savoir s'il fera la différence entre "ma connexion est morte" et "la connexion de l'autre serveur est morte". Je n'ai l'impression d'avoir vu un parametre de ce style, je verrais bien en testant.

Suivre le flux des commentaires

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