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 ;)
[^] # Re: faisable mais peut se faire plus simplement
Posté par NeoX . En réponse au message idée de redondance de VMs, est-ce faisable. É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 ;)