Autohébergement + IP failover

Bonsoir à tous,

Je vais faire partie des heureuses personnes qui va être fibrée, cela va me permettre possiblement de proposer des services auto-hébergé alors que jusque là je ne pouvais l’envisageais avec de l’adsl qui n’est pas stable en plus.
A voir en fonction aussi de la connexion une fois en place.

J’avais une question à laquelle je n’ai pas vu de réponse.
Si on s’autohéberge, il peut y avoir de nombreux cas où l’on peut avoir d’interruption de service : coupure électrique, problème réseau ou de connexion… (peut etre moins avec la fibre je ne sais pas).

Du coup je me disais que je voulais mettre en place un serveur externe avec un failover, mais pour cela il faut une ip (ipv4 et ipv6) fiable et un serveur juste pour faire cette fonctionnalités là.

Est-ce que vous avez mis cela en place ?
Comment ?

Merci de vos retours :wink:

Pour ma part, j’auto héberge des services derrière un fibre Free depuis ~3 ans, avant ~1 ans ADSL Free et ~4/5 ans derrière un ADSL orange. Voilà de mémoire les problèmes que j’ai eu (du plus ancien au plus récent) :

  • Prises CPL TP-Link qui plantent, obligé de débrancher/rebrancher ~6h de down à chaque fois
  • Arbre qui tombe sur la ligne Orange, coupé deux jours
  • Carte mère du Dell Poweredge 2900 qui grille, remplacement compliqué, indisponibilité ~6 mois
  • Congestion sur un switch de desserte Free fibre optique (le soir de ~17h à 23h, ~100 ko/s, 400ms de latence, pendant 2 mois) → dur d’accéder aux services à ce moment
  • Coupures électriques de ~1h parfois plusieurs fois par jour, parfois pas du tout, pendant l’installation du chauffage urbain en bas de chez moi. Ça a duré quelques mois aussi.
  • Free change mes adresses IPs que je pensais fixes suite à un changement d’architecture de leur réseau, obligé de retrouver la nouvelle IP et éditer les DNS, ~6h de downtime

Donc d’expérience, que ce soit la fibre ou l’ADSL, pour moi ça ne change pas grand chose, et oui quoi qu’il arrive il y a des problèmes et du downtime. x)

Est ce que tu penses à quelque chose comme une IP flottante ? Comment comptes-tu faire pour les données ? Et pourquoi ne pas simplement changer les DNS quand tu rencontres ce problème ? Quitte à mettre un TTL un peu court pour que la propagation se fasse vite ? Sinon, pour éviter d’avoir un serveur, les FAI associatifs (comme Grifon à Rennes) proposent des VPN/tunnels avec de l’IPv4/IPv6 publique, ça ne pourrait pas te convenir ? Où est ce que tu cherches en plus un système avec détection de panne pour changer automatiquement la configuration ?

Bonjour,

Je fais ma minute chiante. @quentin, je ne te vise pas particulièrement, c’est plutôt une remarque générale. Mais le terme de « propagation » (très répandu) pour parler du DNS n’est pas approprié. Le DNS ne se propage pas comme un virus, par contre une requête DNS va rester en cache chez le client le temps du ttl. Donc il ne faut pas attendre que le DNS se propage, mais attendre que les caches soient vidés pour qu’une requête soit à nouveau faite. Voilà, j’ai fini avec ma minute chiante. Merci de m’avoir lu :slight_smile:

1 « J'aime »

Sinon je rejoins ce que dis @quentin, j’ai fait de l’auto-hébergement derrière ma ligne ADSL pendant quelques temps. Je suis maintenant passé sur un serveur dédié depuis 2018 en datacenter et je ne regrette pas ma décision. En plus de bénéficier cette fois d’une vraie connexion, j’ai la tranquillité d’esprit d’avoir du matériel qui peut être vite remplacé, de ne jamais avoir de souci de connexion.
Je vais prochainement avoir également la fibre, je vais donc l’utiliser comme solution secondaire (sauvegarde…) mais je continuerai d’héberger mes services depuis un serveur dédié (même plusieurs en fait).

Au Retzien on est auto-hébergé, on a 3 serveurs / 2 sites (maison/cave) 2 lien VDSL sur site et 1 lien fibre sur l’autre site. Du coup si jamais y’a gros plantage VDSL ou Fibre on déplace les serveurs de l’autre côté (c’est pas encore arrivé)
Du coup moi je te dirais bien : trouve toi un voisin / copain chaud pour t’héberger en cas de crash box/connexion non loin de chez toi pour démarrer…

1 « J'aime »

Merci pour vos retours.

En fais je pensais effectivement avoir par exemple un serveur dédié pas forcément très puissant mais assez pour un lien de secours.
Une réplication entre mon serveur auto hébergé et le serveur dédié.
Mais là où je me posais des questions c’est comment mettre en place le basculement lorsque qu’il y a un problème car même si je mets un haproxy sur un des 2 serveurs, si c’est celui là qui tombe il n’y a plus d’accès.
Un 3ème serveur serait une solution mais j’aurais tjs un risque et prendre juste un serveur meme tout petit juste pour cela je trouvais cela moyen

Effectivement la solution des dns serait une des possibilités, surtout pour les pannes que je détecte ou les maintenances programmés, là je pensais plus quand je ne suis pas là, au boulot par exemple et que je ne peux pas intervenir, ou la nuit…

La solution d’avoir tout en serveur dédié est certes plus souple au niveau monitoring matérielle mais n’empêche pas justement le problématique, ou alors il faut avoir justement de multiples serveurs avec un systeme d’ip failover (ovh https://www.ovhcloud.com/fr/bare-metal/ip/ ou scaleway https://www.scaleway.com/fr/dedibox/adresse-ip/ en propose ) mais limité à un hébergeur.

Je me demandais donc si il existait ce genre de service, pas à prix démentielle, et non limité à un hébergeur en particulier.

Oui c’est aussi une solution, il faudrait trouver et pouvoir faire switcher quand il y a un problème.

Mais après je prends peut etre pas le probleme par le bon bout et il y a peut etre d’autres solutions

1 « J'aime »

Pour faire de l’IP failover directement, tu dois contrôler le routage dans ton réseau. Tu ne peux donc pas faire ça chez toi directement ou à travers plusieurs fournisseurs de services.

Par contre tu peux l’émuler avec un tunnel / VPN qui porte une IPv4/v6 publique (comme chez Grifon). Dans ce cas, une des deux machines se connecte au tunnel/VPN, si elle crash, tu lances le tunnel/VPN sur l’autre et c’est transparent.

Si tu veux faire le changement automatiquement, une façon de faire serait d’utiliser un logiciel de VPN/tunnel qui puisse détecter si un client est déjà connecté. Si oui, alors c’est que l’autre serveur est up. Sinon, il se connecte dessus et donc c’est bon aussi.

On notera pourtant que tu te retrouves toujours avec un point de défaillance : ton fournisseur de tunnel/VPN.

Si ce n’est pas acceptable, tu peux imaginer que tes serveurs puissent modifier les entrées DNS automatiquement. Par exemple ton serveur de backup pourrait décider de changer les DNS pour lui si il n’arrive plus à ping ton serveur primaire et vice-versa.

Cette solution qui parait simple à pourtant une faiblesse : si tes deux serveurs sont toujours fonctionnels chacun de leur côté mais qu’ils ne peuvent plus communiquer entre eux (par exemple une erreur de peering de la part d’un FAI, ça arrive tous les ~6 mois d’expérience). Et bien dans ce cas ils vont tous les deux penser que l’autre est down et se battre pour mettre à jour ton DNS. Bienvenue dans le monde des partitions réseaux et du système distribué, il existe des solutions mais il te faut au moins 3 serveurs.

Sinon, imaginons que tu ne sois pas contraint sur les applications, tu pourrais juste laisser ton client choisir sur laquelle des deux IP il veut se connecter. Par exemple, si ton service utilise le champs SRV de DNS et pas A ou AAAA, tu peux enregistrer directement dans DNS un serveur primaire et un serveur secondaire. Un exemple sur Wikipedia.

1 « J'aime »

Merci bcp pour ces informations, c’est très intéressant aussi bien la partie VPN, je n’avais pas pensé à un usage de ce type que la partie DNS.

Je sais très bien qu’il n’y a pas de service infaillible.
Surtout qu’en plus, plus il y a de redondance, plus les couts peuvent s’envoler.

Par contre c’est vrai que maintenant que je vais être fibré, je me disais que je pouvais essayer de fournir à l’avenir un service plus pérenne… d’où mes questionnement :wink:

En fait c’est un truc qu’on est plusieurs à penser en ce moment, de fournir un service pérenne depuis chez soit !

Tout d’abord, je pense au projet ACIDES et plus particulièrement à hepto :

hepto vise à faciliter l’hébergement au domicile, en permettant à plusieurs individus ou structures, domiciliés séparément mais disposant de connexions à Internet de qualité, de mettre en commun leurs ressources pour construire et exploiter un cluster d’hébergement unique, avec des propriétés de résilience suffisantes pour héberger les services et données de particuliers.

Et pour nous, en parallèle de hepto, on a des objectifs assez communs :

La gestion de ces pannes, c’est aussi ce qui rend la vie compliquée aux hébergeurs indépendants. Entre incompréhension des utilisateurs quand un service est hors ligne et sueurs froides pour les administrateurs, ça n’a rien de marrant. Et c’est très chronophage. Notre objectif est donc de construire des solutions d’hébergements qui peuvent résister à ces pannes.

Pour le moment, notre conclusion c’est qu’on veut construire un cluster geo-distribué avec un moyen de répliquer les données à travers internet tout en gérant les problématiques réseau que tu as évoqué. On a commencé à développer plusieurs projets dont le plus avancé est du stockage d’objet nommé garage.

Notre avis, c’est que les outils disponibles ne sont pas conçus pour nos besoins et qu’à vouloir les utiliser on souffre de dépendance au sentier.

L’idée est que des particularités historiques, justifiées à une époque mais qui ont cessé d’être optimales ou rationnelles, peuvent perdurer parce que les changer impliquerait un coût ou un effort trop élevé à un moment, alors que ce changement pourrait être payant à long terme.

Que ce soit ACIDES ou notre infrastructure, on essaye de s’extraire de cette dépendance en redéveloppant les bons outils. À ce jour, rien n’est encore 100% opérationnel facilement. Le code tourne en prod mais tout est très expérimental. Après, si des gens ici sont intéressés pour tester et faire des retours voire donner un coup de main, on prend (par exemple sur garage !). Mais c’est un problème complexe pour le moment.

Merci pour toutes ces informations.
Je ne sais pas elles avaient déjà été posté sur le forum, je suppose que oui il est vrai que mes recherches nos correspondaient peut être pas à cela à la base.
Je vais essayer de regarder tout cela à tête reposé mais dans tous les cas ça va dans le bon sens et cela m’intéresse.

1 « J'aime »

Auto-hébergement pour moi (COMPUTEL: https://www.computel.fr/2019/07/07/la-quincaillerie/) avec 2 fibres: free + OVH

J’utilise MPTCProuter pour créer un lien redondant avec les 2 fibres, pour cela j’ai un petite dedibox avec une IPFO sur laquelle tourne la VM externe de MPTCProuter, qui communique avec une VM sur un serveur chez moi.
Avantage secondaire: c’est un IP « datacenter » qui est vue de l’extérieur et pas résidentielle. Invconvénient: le routage logiciel limite la bande passante (300-500Mbps environ), mais suffit amplement.

Pour le reste, très peu de coupures sur ces fibres, finalement je ne les remarque pas vue la redondance :wink:

Mes serveurs fonctionnent en cluster proxmox, les VM et CT sont répliqués entre les serveurs, tout est stocké sur du ZFS redondé + backup (zfs send/recv) quotidien sur un serveur allumé uniquement pendant le temps du backup qui vient se servir sur les autres (sens unique pour la sécu).

Onduleur (de récup) sur une des deux alims des serveurs + sur tout le matériel mono alim (en fait uniquement la freebox, mon switch ethernet est double alim lui aussi).

Stats de dispo:

https://stats.uptimerobot.com/l561VToKXn

Merci également pour ce retour.
Actuellement vu que j’ai une connexion ADSL capricieuse, j’ai un failover en 4G via un routeur ER-X.
J’avais hésité à l’époque entre cela et MPTCRouter.

Il faut que je regarder un peu à nouveau cela.

Dans tous les cas toutes ses solutions sont intéressantes.

Merci pour le partage

En ce moment : on à un problème de four qui fait sauter les plombs !
Le serveur redémarre 2 à 3 fois par jour !

Sinon : juste remarque : soit tu fait du payant, et donc : oui, cela vaut le coup de redonder. De tout de façon : tu va pas faire de la GTR 4heures etc … si ? Si oui : cela doit être cher !

Mais pour du gracieux ou BeerWare : tu assure les sauvegardes, tu ne va pas assurer un GTR ?

J’ai 4 serveurs : celui à la maison sert pour la famille, les amis et le perso.

Effectivement, je ne compte pas faire de GTR.
Malgré tout, je voulais essayer de monter un service le plus stable possible, car c’est une chose de se faire ses propres petits serveurs perso pour ses propres sites, les copains et la famille.
ça en est une autre de proposer des services à d’autres, surtout si c’est dans le but d’être un CHATONS et de proposer des alternatives aux GAFAM…
Et donc le but de ces questions et échanges pour voir quoi mettre en place, mettre le curseur au bon niveau.

1 « J'aime »

Pour revenir parmi toutes les solutions possibles, est-ce qu’il y a l’un d’entre vous qui a essayer DRDB (https://fr.wikipedia.org/wiki/DRBD).
Cela à l’air intéressant pour un serveur dédié et par exemple un serveur auto-héberger en backup.
Je verrais cela avec les disques en RAID DRDB + partition BTRFS avec snapshot (donc sauvegarde sur un autre serveur local des snapshop de la partie système et vm).
Vous en pensez quoi ?
Tous vos retours sont les bienvenues

@ManchotManosquin le chaton Chapril utilise drbd.

Notre schéma est avec deux hyperviseurs qui se dupliquent l’un l’autre, dans l’idée de réduire le temps de reprise en cas d’incident grave (car remonter des To des backups peut parfois être long et fastidieux). Ce schéma est inspiré de celui de l’infra de prod de l’April depuis ~2016.

Précisément, les partitions accueillant les images des machines virtuelles sont dupliquées en utilisant drbd. La duplication est faite d’un serveur vers l’autre, et donc c’est une duplication croisée. La duplication ne remplace pas la sauvegarde mais donne une chance d’avoir une continuité de service plus facile en cas d’incident.

Globalement on en est satisfait: ça fonctionne bien, c’est fiable, pas trop complexe. On a rarement eu à dénouer des problèmes. On a eu une fois à tourner « sur un seul serveur » et on a compris que passer de 2xNGo à 1xNGo de RAM exige le sens du sacrifice. :slight_smile:

Dans les points d’amélioration, note setup complique les démarrage et exige une intervention manuelle au démarrage des hyperviseurs. Mais je suppose que ça pourrait être évité en travaillant un peu.

Coté perfs ça a un coût tout à fait raisonnable (c’est pas là qu’on perd le plus je pense).

(Je précise que les deux serveurs sont dans la même baie, reliés avec un câble réseau dédié.)

Chez ARN on utilise aussi drbd avec un câble réseau direct entre les 2 serveurs (il nous sert aussi pour coordonner l’hyperviseur ganeti), idéalement il faut séparer les 2.

Je suis sceptique sur le fait que ça marche bien à distance… Perso, si je me posais ce genre de question, je chercherais d’autres technos (que je connais pas, ceph etc.).

Pour détailler, chacun de nos VPS dispose de disques lvm qui sont synchronisés chacun avec un drbd séparé.

Une année on a eu des soucis sur les VPS de stockage car les disques durs de stockages semblaient trop sollicités. A l’époque, j’ai fait diverses tentatives d’optimisation. On a finalement réglé le soucis en fournissant à chaque VPS un petit disque de 15G SSD (raid6+drbd), les systèmes des VPS n’étant plus sur la partie stockage, ça fonctionne beaucoup mieux au niveau IO.

Toutefois, il n’est pas rare de voir des drbd en inconsistance/synchro et parfois ça prend un peu de temps à se remettre, donc si il y a panne d’un des 2 serveurs pile à ce moment là, le VPS ne pourra pas être basculé sans perte (voir sera perdu).

Dans le même genre, une fois, on a eu une grappe raid 5 SSD qui a recopier des erreurs d’un des disques, et du coup ça s’est retrouvé sur l’autre grappe de l’autre serveur car recopié par drbd (cauchemar). Ce jour là, on a perdu 2 VPS à cause de ce trucs (ce fut la seule fois), sans parler qu’il a fallu remonter un nœud pour l’hyperviseur et notre setup est assez complexe (bgp, ucarp, ganeti, ipset en ipv4 et ipv6…).

Ceci dit, je viens de me souvenir qu’il y a le mode C de drbd, qui permet de synchro quand on le souhaite (par exemple une fois toutes les 24h), ça peut être un plan.

Ne pas négliger non plus le monitoring, pour ça comme pour le reste.