IP LB NextGen Multi DC

Merci pour la réponse, je vais retenter cela, il me semble avoir configuré comme ça la première fois.
Bah, surement une erreur de ma part, j'y retourne, merci à vous :)

Je m'auto répond.

J'ai fais la config comme indiqué plus haut.
J'ai 3 serveurs, chacun déclaré sur sa zone.
3 backend, chacun déclaré sur sa zone et chacun pointant uniquement sur le serveur de sa zone.
Protocole http, port 80, suivi de session aucun, répartition least conn.
Et enfin 3 frontend, chacun sur sa zone, pointant sur le backend de sa zone, en http port 80.

Et quelque soit le serveur depuis lequel je test, j'arrive toujours sur le serveur de GRA....
Pour faire le test j'ai mis un fichier host.txt sur chaque vps et je fais un lynx -dump

Du coup que je fasse le test depuis BHS ; RBX ; GRA ; SBG ou ma connexion vdsl ovh c'est toujours le serveur de GRA qui répond.

Je vais patienter, même si aucune task n'est en cours, peut être que quelque chose doit se "propager" encore.... Mais j'ai un doute.

[EDIT]
Je précise, compte ovh : SY-4612 (le même que sur le forum) et ip-192.99.65.72
Mais bon, c'est que du labo donc c'est quand vous avez 5min
[/EDIT]

Salut,

Je suis aussi en phase de test de ce IP LB NextGen, la version classique ne répondant pas à mes besoins, c'est-à-dire, faire de la répartition de charge entre région (datacenter).

D'ailleurs au passage, c'est vraiment dommage de proposer du public cloud entre plusieurs DC sans possibilité d'avoir du vrai low lantency entre les DC. J'utilise un vRack mais j'ai tout de même 10ms en moyenne entre les 2 DC localisés en France. Sur AWS entre 2 zones d'une même région il n'y a aucune latence.

En l'état, il n'est pas possible je pense de spliter son infra sur 2 DC pour renforcer la HA... c'est fort dommage pour du cloud !

Bonne continuation.

Il me semble que l'ancienne IP LB pouvait faire du multi dc.... Je n'ai jamais essayé faut dire... Mais d'après la doc c'était faisable.
Bon le site dit bien que l'on peut ajouter des backends au cdn infrastructure mais en fait non... Pas toujours à jour entre la doc et la réalité :)

Je te confirme que non via l'ancien (actuel) IP LB, j'ai même eu confirmation du support technique à ce sujet.

Bonjour,

Je ne sais pas si vous avez fait des modifs.
Mais désormais depuis RBX ; GRA je pointe systématiquement sur GRA.
Depuis SBG je pointe sur SBG
Par contre depuis BHS je pointe sur .... SBG...

Je n'ai pas de serveurs dans d'autres DC pour faire d'autres tests par contre.

Hello,

Est-ce que le comportement actuel te conviens mieux?
On a fait quelques modifs

Christophe.

Merci !
Oui c'est impec comme ça.
Depuis BHS je pointe tjrs sur BHS.
Depuis SBG je pointe tjrs sur SBG.
Depuis GRA je pointe tjrs sur GRA
Depuis RBX je pointe soit sur GRA soit sur SBG

Est il prévu d'étendre l'infra IP LB et les Public Cloud sur les autres DC ? (Pologne et Asie notamment).
Pour le moment on ne peut commander qu'une seule sorte de serveurs là bas, et l'IP LB ne couvre pas ces DC.

En tout cas merci, l'IP LB fonctionne comme attendu maintenant !

Je vais pouvoir essayer de réfléchir à un système pour générer un certificat lets encrypt sur le backend et les frontend avec renouvellement auto et tout ce qui va avec...

C'est prévu :)
Pour le moment pas d'ETA mais ce sera certainement PL puis APAC dans un second temps.

Cool :)
Tant que j'y suis, il y'a un "bug" dans l'interface de gestion de l'IP LB NextGen via le panel OVH.
Quand on ajoute / édite un backend il y'a une liste de serveurs, mais cela ajoute toujours tous les serveurs....
Ce qui m'oblige à passer par l'API pour corriger ce point à chaque fois.

Bon au final ça marche via l'API, mais si je pouvais m'abstenir de passer par l'API juste pour ce point ça serait pas mal :)

Le refresh sur les task est moyen aussi. Il faut sortir du menu "Sunrise" puis y revenir pour avoir une mise à jour ... Du coup pareil j'ai toujours une fenêtre sur l'API pour voir où ça en est.

C'est vraiment mineur puisque l'API fonctionne bien, c'est juste si vous avez quelqu'un qui y jette un oeil de temps à autre

[EDIT]
Un autre point, je ne vois pas comment faire en sorte que le backend parle au serveur en https....
Je fais frontend en https port 443 avec le certificat ssl et je coche SSL.
Je définis le backend où je mets port 443 aussi, mais la communication backend > serveur se fait tjrs en http sans SSL vu que j'ai des requêtes http et par conséquent des erreurs...
Il me semble que frontend en ssl, puis backend sur le port 80 ça fonctionne... Mais j'aimerai rester en ssl tout le long..
Je vais essayer de configurer le backend en TCP au lieu de HTTP....
[/EDIT]

Je répond pour la partie SSL.
En fait il faut configurer le backend sur port 443, le lier au serveur, puis une fois le lien créer il faut éditer le lien via l'API et cocher la case SSL.
Et du coup la communication backend > server se fait bien sur le port 443 en https.

J'ai commencé aussi à tester le IP Loadbalancer NextGen, je suis un peu perplexe fasse à l'interface de config, c'est un peu confus. Je me demande s'il est possible de faire gérer du HTTPS sans avoir à ajouter nos certificats SSL au niveau du LB et laisser gérer le SSL par les backends.

L'interface on s'y fait quand on a assimilé le principe de fonctionnement, mais il faut avoir l'API à côté car l'interface ne fait pas tout.
Comme par exemple quand on crée ou configure un backend via l'interface ça lie forcément tous les serveurs. Impossible également de configurer un backend pour utiliser SSL sans passer par l'API.

Concernant les certificats SSL à ce jour il faut envoyer les nôtres obligatoirement.

Mais dans l'ensemble le service fonctionne bien.

Je m'en sers en frontal d'un cluster de 3 nodes qui traite de nombreux visiteurs (on est monté à 16k visiteurs en ligne en même temps au niveau max).
Je m'en sers également, plus comme un test, pour gérer 3 petits VPS dans plusieurs DC (SBG,BHS,GRA) qui font office de frontaux web comme un mini CDN. Suite aux dernières modifs d'OVH les visiteurs sont envoyés directement sur le DC le plus proche et c'est bien pratique. Sur cette config j'ai uploadé mes certificats SSL (2 pour le moment) et j'ai du SSL du client au serveur final. Sans soucis là aussi.

Il faut faire abstraction de l'interface qui n'est pas finalisée, car le service en lui même est fiable et fonctionne bien.

A voir ce que ça sera facturé quand ça ne sera plus considéré comme "beta".

Le problème de devoir ajouter les certificats au niveau du LB c'est qu'on ne peut exploiter "facilement" une solution telle que Let's Encrypt.

C'est aussi chiant quand on automatise son infra avec un outil tel que saltstack dans notre cas, il faudra coder un module pour exploiter l'api de OVH afin de configurer le LB.

Oui je sais, j'ai la même problématique....
Je suis entrain de réfléchir à comment gérer ça en automatique....
Je pense qu'il faut rediriger les requêtes letsencrypt (de validation) vers un serveur bien précis, puis à dispatcher le certificat sur les différentes nodes du cluster et sur l'IP LB....

Mais en même temps si OVH propose une solution basée sur lets encrypt ça reviendra au même, car le certificat sera généré chez OVH, et il faudra de toute façon le récupérer pour le déployer sur les backends....
Ce qui est pénible également c'est que let's encrypt ne propose que des certificats de 3 mois... Du coup obligé d'automatiser la gestion des certificats.

Oui, on utilise Let's Encrypt que sur certains domaines spécifiques pas sur nos domaines principaux ... déjà parce que Let's Encrypt ne supporte pas les certificats wildcard ce qui est bien embêtant.

Est-ce que tu as tester de faire du SSL offloading avec le LB nextgen ? Cela peut être intéressant comme possibilité, on fait souvent ça sur nos infra.

Il est possible de poser le certificat ssl sur le load balancer et d'interroger le serveur en http, si c'est la question posée.
Ainsi il "suffit" de poser le certificat sur le LB et pas sur les nodes.
Par contre il faut toujours gérer la mise à jour des certificats sur le LB.