Problematique : un service (web/ftp...) tourne sur un serveur accessible sur une connexion internet (ligne spécialisé, turbo dsl, sdsl...) qui a une ip fixe IP_PRIMAIRE. Je cherche a mettre en place en backup via une liaison adsl par exemple qui aurait une ip fixe IP_SECONDAIRE. Ce que je cherche a faire est similaire a un load balancer mais les ip fixes differentes me pose probleme. A noter que c'est le cote backup qui m'interesse et pas le cote repartition de charge.
 
Les solutions que j'ai imaginé :
 
1) Round Robbin DNS :
 
Je definis un dns en tourniquet qui renvoit les ips fixes alternativement. Si la liaison primaire tombe, le dns renverra parfois la bonne ip (IP_SECONDAIRE) mais egalement parfois la mauvaise ip (IP_PRIMAIRE). Il y aura par ailleurs des problèmes avec les caches DNS je pense. Bref c pas top.
 
2) Passer par un ISP externe :
 
Je place une machine chez un isp externe a mon système. Cette isp me donnera par exemple un ip fixe IP_ISP. Je place sur cette ip une machine frontale qui agit comme un load balancer. Elle est au courant de l'etat de IP_PRIMAIRE et de IP_SECONDAIRE. Elle forwardera toutes les connexions vers la machine primaire sauf si défaillance auquel cas elle renvoit vers la machine secondaire. Cela dit ca me semble lourd à mettre en place et on déplace le problème chez la machine de l'isp, on a un point of failure à ce niveau là.  
 
3) Utilisation des SRV records sur le DNS :
 
Pour résumé un SRV record est un enregistrement DNS qui fonctionne similairement a un enregistrement MX. On lui attribue un numéro d'ordre (poids). Le client prend les serveurs dans l'ordre des poids et trouve le premier qui est valide. Le gros inconvénient, les enregistrements SRV ne sont supportés sur les produits M$ qu'a partir de windows 2000 et nous pouvons avoir des clients inférieurs.
 
Exemple dans une zone pour domaine.com

Avec cette config les clients qui supportent les SRV contacteront la machine principal.domaine.com mais si elle est down ce sera backup.domaine.com. Les clients qui ne supportens pas les SRV fonctionneront en tourniquet sur www.domaine.com avec les ips primaire et secondaire (cas n°1)
 
4) Backup du fournisseur :
 
Sur les solutions types LS, SDSL, TDSL, les fournisseurs propose un backup RNIS. On ajoute un module RNIS dans le routeur. En cas de chute du lien principal on bascule automatiquement sur le lien RNIS. Avantage, tout est automatique, on garde la meme ip fixe donc c'est transparent pour client. Deux inconvenients : la bande passante est inferieure a la ligne principale et si c'est le routeur qui crame on l'a dans l'os.
 
5) Un programme qui mettrait a jour la zone DNS :
 
A la facon des dns dynamique comme dyndns.org, je crée un programme qui connait l'etat des liaisons et met a jour la zone dns en fonction de pour avoir sur www.domaine.com toujours une ip valide. Il y aura comme en 1) le problème du cache DNS.
 
 
Voila pour l'instant les solutions que j'ai envisagées, qu'en pensez vous ? Est ce que certain parmi vous aurait une experience sur le sujet ?

 
 
ben alors ??    
 
ca inspire personne ?  

non.

ce tomik est un bide
dommache

pas vraiment mais disons que c'est un sujet quand même assez pointu et que tu as quasiment fais le tour des solutions  

moué
 
bon enfin si y a d'autres idées je suis preneur
 
ou si vous voulez débattre des précédentes

Salut Kikoune, je propose aussi mon idée, mais tu l'as connait déjà, vu qu'on en déjà pas mal discuté.
C'est eventuellement pour ceux qui penche dessus.
 
--
J'avais pensé à un serveur déporté chez un hebergeur, deux tunnels VPN, l'un pour le premier ISP, le deuxième pour l'ISP de backup.
 
 

 
Le serveur déporté est la «porte d'entrée» pour les services Web.
Quand un tunnel tombe, cela reprend sur l'autre.
Cette solution est assez simple à mettre en oeuvre (tout est relatif)
Qui plus est, au niveau du firewalling, je serais pas obligé d'ouvrir le port http/https (port fwd), mais juste d'ouvrir le port du tunnel pour seulement un serveur bien précis.
 
Dans le DNS, une seule IP, celle du serveur déporté.
Les données transitant entre les VPNs actifs et le serveur à l'autre bout.
 
Vous allez me dire : «Et si le serveur tombe ?»
 
Nous pouvons mettre un loadbalancer-hard devant.
 

 
Celui fera la dispatch sur «N» serveur avec chacun les «X» tunnels VPNs.
 
Cette solution est un bon compromis, mais elle coute chère malheureusement.
 
Sinon, nous avons la solution du loadbalacing soft avec du Linux ou BSD.
Ca réduit les coûts du lb-hard.
 
Encore plus «sioux» ... mais franchement c'est iréalisable dans l'état actuelle des choses (possible théoriquement).
C'est de faire du routage spécifique au niveau des ISP.
Mais là, cela demanderait de contacter tout les ISPs du monde (au moins de France) pour leur demander d'appliquer une rêgle de routage sur leur routeurs principaux.
Et franchement : ca m'étonnerait qu'ils le fassent.
Même pour un gros client.
 
Voila les gens  
.. Kikoune, keep contact  

prae    
 
en fait ta solution c moin 2) mais en moins développé
 
modif de ton second schéma :
 

 
commentaires :
 
je rajoute que chaque serveur vpn doit avoir plusieurs tunnels sur le firewall.
 
dans ton schema, le load balancer connait l'etat des serveurs vpn (up/down) mais comment sait il si le tunnel derrière le serveur est up ?
 
avec la modif, le load balancer connait l'etat des serveurs vpn. il y aura donc toujours un serveur vpn valide. ensuite ce serveur vpn cherchera un tunnel valide parmi les disponibles.  
 
on rajoute un niveau de redondance en fait :
- 1er niveau le load balancer et les serveurs vpn
- 2nd niveau les liens multiples pour les tunnels
 
nota bene : j'ai rajouté un S à serveur derrière le firewall, vu que si tu blindes ton lien internet avant le firewall, faudra penser à redonder les serveur derrière mais bon tu connais mista "redondeur" prae  

Heu ... attend, c'est le même schéma là !  
Je vois pas comment le load balancer hard va connaitre l'état des liens VPN avec ton schéma  
 
Qui plus est, dans la précédente méthode, j'avais pensé à faire un script qui check le vpn x, le vpn y, le vpn z, etc...  
Si aucun n'est actif, automatiquement, il prend la décision de faire tomber la carte réseau (Heartbeat peut faire cela).
Donc, plus aucun problème pour connaitre l'état du VPN : si le serveur VPN est actif c'est que un de ses liens est encore actif.
 
Pour le serveur derrière, oui, enfin bon, ma problématique étant juste de joindre un serveur par tout temps (le nombre d'utilisateur est très peu conséquent ... mais il doit être toujours dispo)

en fait dans le schéma modifié, chaque serveur vpn avait des liens redondants vers le firewall. dans ton schéma il n'y en avait qu'un seul.
 
cela dit en coupant le eth du serveur vpn si plus de lien ca fonctionnerait bien mon truc complique unutilement

ouép ca va donner un round robbin mais comme on ne connait pas l'etat des liens, il se peut qu'on renvoit une adresse invalide

 
A ton avis, le "s" dans vpns veut dire quoi ?  
il peut y avoir «n» VPNs redondant  

ah ben oui
 
je croyais que c un mot fashion comme ceux que les jeunes emploient de nos jours dans leurs conversations... mais c vrai que "veupeuneusse" me paraissait etrange comme terme
 

 
Avoue que tu es stone !!!    
 

et un ptit up pour la route
 

Une solution pour connecter 2 opérateurs est un boitier dédié (style Linkproof de RADware) (et ainsi on évite aussi le BGP)
Par contre ça ne résouds pas le problème de DNS.
 
Surtout que lorsque tu as 2 opérateurs, il te faut alors 2 plages d'IP publiques (une plage routée par chaque FAI) si tu as des services hébergés (et donc 2 IP par serveur).
 
Mais se pose toujours le problème de DNS encore une fois quand un lien tombe.
 
Y aurait-il une solution miracle à ça ?

Ma question peut sembler idiote, mais pourquoi s'embêter à prévoir les pannes alors qu'on peut simplement payer pour un hébergement professionnel avec garantie de service, GTR et tout le brol ?
 
D'autre part, ça fait longtemps déjà que les ISPs français sont capables de déployer des solutions de backup bien plus conséquentes que le simple RNIS, il serait bon de les contacter avant toute chose pour connaitre les solutions qu'ils ont a proposer, non ?

Je sais pas si je tombe à coté mais ucarp : http://www.ucarp.org est peut être adapté à ton problème non ? (c'est fait pour la redondance, pas pour la répartition de charge)

Moi j'ai déjà monté qqc de similaire avec RNIS.
 
Un routeur possède la LS (ou la connexion ADSL) et un autre routeur possède le backup RNIS.
Protocole de routage dynamique ensuite (OSPF en général) et ça roule.
 
Mais bon dans ce cas précis je ne pense pas que ce soit la solution optimale.
 
Pour ça il te faudrait une machine genre Alteon en frontend qui dispatche ensuite.