soit 2 serveurs de VMs et conteneurs LXC
Aujourd'hui les 2 serveurs ont des IPs Publiques, et les VMs/LXC aussi.
mais quand le serveur1 tombe, les VMs qui sont dessus aussi.
Malheureusement je ne peux pas basculer la VM sur le serveur2 car l'IP publique ne suivra pas (pas le meme hébergeur)
Pensez vous possible de faire un truc du genre
1°) mettre les VMs/LXC sur un reseau privé
2°) si ca existe, relier les 2 serveurs par un VPN qui expose le reseau privé à plat, ainsi peu importe sur quelle serveur physique se trouve la VM, elle est joignable par son IP privée
3°) configurer sur chaque serveur physique une VM/LXC reverse proxy/load balancer qui prendrait les IPs publiques des VMs, et enverrait vers l'IP privée.
4°) configurer les 2 IPs publiques des 2 reverses dans le DNS de mon service www.domain.tld
5°) activer la replication des VMs, ou juste restaurer la VM sur l'autre serveur en cas de panne du premier
on aurait alors un truc du genre
/ -> IP1 publique de www.domain.tld -> reverse1 ---> vpn -> ip privée www.domain.tld
Client |
\ -> IP2 publique de www.domain.tld -> reverse2 ---/et en cas de bascule
/ -> IP1 publique de www.domain.tld -> reverse1 ---\
Client |
\ -> IP2 publique de www.domain.tld -> reverse2 ----> vpn -> ip privée www.domain.tld
# faisable mais peut se faire plus simplement
Posté par romain11 . Évalué à 2. Dernière modification le 14 mars 2021 à 08:29.
Ca me parait tout à fait possible, en revanche si il n'y a que deux backend autant ne pas utiliser de reverse ou de VPN avec une VM qui bascule sur l'IP2 dans le DNS en cas de problème :
www.domain.tldrésoud vers IP1 publique + IP2 publiqueSi il y a >2 backend la partie VPN est imaginable mais pas indispensable non plus (les reverses sur chacune des 2 IP publique pouvant tapper dans les IPs publiques des backend qui ont accès au net, en particuler sr les backend on peut utiliser un port dédié et n'autoriser les connexions que depuis les IPs de reverses.)
Dans toute ces configuration la redondance est basé sur le DNS failover, notons que les clients gèrent avec plus ou moins de bonheur le fait qu'un fqdn soit résolu en plusieurs IPs (parfois le fallback sur la 2nde IP prend >=5s, voire plus, voire jamais (vieux? java) mais est a priori correctement supporté par les navigateur)
Cf par exemple la discussion https://serverfault.com/questions/60553/why-is-dns-failover-not-recommended
[^] # Re: faisable mais peut se faire plus simplement
Posté par NeoX . Évalué à 2.
je me rend compte que mon schema n'est pas toutafais ma pensée.
le VPN ne servirait que pour joindre la VM quand elle est de l'autre coté.
en mode normal
Client -> IP publique1 -> Reverse -> IP Privée ->VM/Serveur1
en mode "panne ou VM déplacée pour nécessité de ressources"
Client -> IP publique1 -> Reverse -> IP Privée -> VPN -> VM/Serveur2
mais j'aime bien ton idée que ce soit les reverse proxy qui gèrent entre eux la redondance
si je comprend bien
IP publique -> Reverse proxy -> Backend1/IP privée locale + Backend2/Ip publique de l'autre reverse
quand la VM locale disparait, le reverse proxy/load balancer, balance le flux sur l'autre IP publique, qui proxyfie sur sa VM Locale (en fait la VM qui a été déplacée)
on evite la couche VPN, la VM garde la meme IP privée entre les elements du cluster de serveur physique et peut donc facilement migrer d'un serveur à l'autre
bon ben y a plus qu'à faire une maquette de tout ca ;)
# Emplacement du VPN, routage
Posté par cg . Évalué à 2. Dernière modification le 12 mars 2021 à 22:11.
Bonsoir,
et aussi le VPN, non, d'après ton schéma ?
Il faudrait un schéma plus précis, qui indique quel matériel porte quel composant (IP publique, endroit du NAT s'il y en a, reverse proxy, serveur d'application, VPN…).
Admettons que le serveur1 reste disponible, que le VPN est toujours ok, et que la VM soit relancée sur l'autre datacenter. Tu vas sans doute avoir un problème de routage : l'IP de ta VM 10.1.1.34 est maintenant de l'autre côté du VPN !
Il faut alors avoir prévu de monter un VPN qui travaille au niveau 2, avec un seul subnet qui se propage par le VPN, y compris les adresses MAC (exemple avec OpenVPN).
Un montage de VPN plus classique fonctionne avec du routage (niveau 3), auquel cas il faut pouvoir modifier le routage dynamiquement sur les VMs.
Pour finir, comme tu as exactement 2 serveurs dans ton exemple, en cas de problème réseau entre les deux serveurs, tu peux être victime d'un split-brain, c'est à dire que chaque serveur croit que l'autre est mort, et va prendre le rôle de l'autre. Un sacré bazar en perspective !
La solution du round-robin DNS proposée plus haut fonctionne plus ou moins bien selon les désirs du client qui y accède… Ça dépanne bien, c'est gratuit et c'est simple. Par contre tu ne maîtrise pas quelle IP va être choisie ! Pour le resolv.conf, l'ordre est respecté, mais dans le cas où 2 IPs sont en round-robin (C'est à dire 1 nom, 2 IPs), ben le serveur DNS va renvoyer les IPs dans un ordre différent à chaque fois. Donc tes services doivent tourner sur les deux serveurs… Et se synchroniser s'il y a une base de données par exemple :p.
J'avais vu il y a quelques temps une bibliotèque Javascript nommée Resilient qui implémente la haute disponibilité côté client. Bien sûr, ça ne fonctionne que dans le cas où tu maîtrises le client, ce n'est pas un mécanisme normalisé. Mais j'avais trouvé l'approche originale.
Bref, ce n'est pas impossible, mais il faut quelques composants en plus, qui peuvent eux-même tomber en panne :p.
[^] # Re: Emplacement du VPN, routage
Posté par NeoX . Évalué à 2.
pour l'instant 2 serveurs physiques et 3Vms avec tout le monde en IP publique sans NAT (firewall sur les machines directement)
l"idée finale dans ma tete, c'est vraiment
2 serveurs physiques (IP publique pour le management)
2 nouvelles VMs, reverse proxy qui porteront les IPs publiques et qui vont envoyer vers les 3VMs existantes qui seront passées en IPs privées
Helas oui, je sais que y a du routage à faire,
et c'était là ma question, savoir si un VPN qui fait du L2 existait, pour n'avoir qu'un seul range reseau privé,et donc une seule interface sur les VMs
mais si ca n'existe pas, je peux mettre 2 reseaux privés sur les VMs 192.168.1.x et 192.168.2.x
sur le physique 1 le reverse 1 tente de joindre la VM sur 192.168.1.x et sur 192.168.2.x (et ne trouvera jamais 2.x), et sur l'infra 2 le reverse renvoie sur 192.168.2.x et ne trouvera jamais 192.168.1.x
Le reverse aura donc besoin d'un lien vers l'autre reverse pour trouver la VM quand elle a bougée, et permettre que le RR DNS fonctionne tout le temps.
et ca peut etre un VPN qui route entre les 2 emplacements physiques, comme on a 2 reseaux, ca peut fonctionner.
[^] # Re: Emplacement du VPN, routage
Posté par cg . Évalué à 1.
Alors, je pense que OpenVPN en mode bridge fait exactement ce que tu veux.
Tu peux en plus mettre des TTLs très courts sur ton DNS, en faisant des mises à jour dynamiques quand une des VMs tombe. Les navigateurs Web s'en sortiront très bien avec ça. Les applis qui cachent à l'infini les résolutions DNS (Java, par défaut), beaucoup moins bien.
Ça me rappelle qu'on avait un truc de ce genre à un ancien boulot sur une infra : un réseau niveau 2 entre deux site distants de 300km, avec des VMs qui pouvaient migrer d'un site à l'autre (pas à chaud si je me souviens bien). La migration fonctionnait bien, mais par contre le routage dans la VM utilisait toujours la gateway du site d'origine (il y avait une gateway par site pour sortir sur Internet sans faire 300km, on devait aller la modifier à la main), et niveau firewall il fallait tout bien prévoir en double pour que la VM puisse travailler normalement en cas de migration. Au final, ce n'était pas tellement pratique, et grande source de confusion pour tout ceux qui manipulent peu le routage (comme moi à cette époque).
Bon courage pour ta maquette alors !
[^] # Re: Emplacement du VPN, routage
Posté par NeoX . Évalué à 2.
ton idée de TTL sur le DNS me fait penser que je peux scripter la mise à jour du DNS
je pourrais alors simplement avoir un reseau privé
et quand la VM devient dispo sur ce reseau privé le reverse proxy execute un script qui met à jour le DNS pour signaler que la VM est derriere son IP publique et plus à l'ancien emplacement.
# VXLAN
Posté par NeoX . Évalué à 2.
on m'a récemment parlé de VXLAN
apparemment l'idée c'est d'avoir le meme LAN derriere chaque serveur/reverse
d'avoir une sorte de vpn entre les deux, qui fait un pont L2 entre les sorties de machines
on a alors
Machine1 sur LAN -> reverse1/passerelleVPN <-internet -> passerelleVPN/reverse2 -> Machine2 sur LAN
M1 et M2 peuvent se parler sans notion de routage
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.