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.
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
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.
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
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).
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.
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.
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
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.
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).
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.
D’où mon utilisation de ZFS, de ses snapshots (pour revenir en arrière), de ses send/recv de snapshots pour garder une copie distante avec persistance de snapshots… mais aussi du cache multi-niveaux (RAM, SSD, puis HDD), de la compression, du chiffrement, de zed pour le monitoring, etc.
Merci pour vos retours instructif.
Il faut donc que je revois peut être mon idée de base de mettre un drdb entre un dédié et un auto-hébergement du à la latence ou du moins que je fasse des tests.
Ce qui est intéressant est aussi de voir et comprendre les problèmes rencontrés comme certains ont exposés car c’est là que l’on se rend compte réellement de la fiabilité de notre installation.
Pour ZFS ou BTRFS, c’est un peu similaire et je dois dire que j’ai pris l’habitude du BTRFS mais il y a les même fonctionnalités de snapshot, de sauvegarde distance et persistantes…après je ne parle de mon expérience que pour des pc locaux ou petits serveurs.
Par contre pour les cache multi-niveaux je n’ai pas tout à fait compris…
Oui du CEPH ou autre techno sont certainement plus opportune quand on a les moyens de déployé le nombre de serveur nécessaire pour ce genre d’infrastructure.
C’est la toute la réalité entre des service proposé, certains sont capables de mettre des moyens pseudo professionnel, d’autre non ou avec le temps en mutualisant, grandissant.
La difficulté justement des chois, des bons niveaux de service par rapport à ce que l’on veut proposer.
Très intéressant pour ma part, merci pour ces échanges
ZFS permet d’avoir plusieurs niveaux de caches utiles quand on a un mix SSD+HDD:
ARC: celui en RAM (pour lectures ET écritures) avec deux logiques combinées, conserver les données récemment utilisées (LRU) + celles fréquemment utilisées (MFU) ce qui évite de vider le cache sur la lecture d’un paquet de gros fichiers
L2ARC: cache en lecture typiquement mis sur un SSD qui va compléter l’ARC, et est maintenant persistant entre reboot depuis ZFS 2.0.x
ZIL: un cache dédié à l’écriture… typiquement aussi sur SSD qui permet deux choses: sécuriser les écritures rapidement sans attendre que ça soit stocké dans le pool de disques + permettre de mieux réorganiser les données avant leur écriture définitive dans le pool, ce qu’on ne peut pas faire quand il faut écrire tout de suite sur les disques pour rendre la main au niveau applicatif.
Il y a même la possibilité de dédier un disque (plus exactement un vdev) plus rapide que d’autres dans le pool pour y stocker en priorité certaines données comme les metadata.
C’est très facile à mettre en oeuvre et totalement transparent à l’usage.
BTRFS est très bien en desktop, ZFS va bien plus loin et est plus adapté sur de plus grosses config multi-disques sur un serveur.
zfs à l’air très puissant, mais pour ma part , c’est l’inconnue.
Aurais-tu un tuto assez basique pour expliquer sa mise en place ?
Sur du proxmox, est-ce ce qu’il y a de mieux ( hormis CEPH, mais overkill ) ?
