mais quand le serveur1 tombe, les VMs qui sont dessus aussi.
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.
# Emplacement du VPN, routage
Posté par cg . En réponse au message idée de redondance de VMs, est-ce faisable. É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.