OVH Community, votre nouvel espace communautaire.

IP Load Balancing : des retours d'expérience ?


starouille
18/05/2014, 00h10
Je n'utilise pas memcache donc no idea. Il me semblait que ça gérait les sticky sessions et que du coup ça poserais pas de problèmes.. même si ça répond pas à l’interrogation, car en cas de bascule le problème se produira.

pour les probe, ça dépend. l'ICMP me va bien (j'estime que c'est le mieux car pour moi l'IP LB n'a pas a être trop intelligent, fonctionner sur des couches plus basses c'est mieux). L'http ça sent pas forcément bon (je sens bien le coup ou si tu ton serveur renvoit une erreur 500, ça continue d'être ok pour le backend. ). Et l'autre c'est pour du scripting home-made.. surement plus précis mais autant lancer ses backend le faire (via haproxy etc..).

Comme je l'avais dit, je vois ça plutôt comme de l'anycast qu'un vrai Load balancer où ça reste très "boite noire" donc difficile à gérer.

xoros
17/05/2014, 15h54
Bonjour et merci pour se retour d'expérience.

Oui, je me doute que le but n'est pas de toucher à la config tous les 4 matins, et dans tous les cas mes backends sont des HAProxy, donc je peux jouer en aval. Le truc c'est que, après avoir passé quelques jours sur un autre paramétrage, quand je suis revenu tester l'IP LB, ben ça partait en erreur, hors j'avais toujours mon backend SBG configuré dessus. Il a fallu que je l'enlève et le remette pour que ça refonctionne.

Hier, après avoir envoyé ce post, je me suis retrouvé avec un des backends (toujours Strasbourg...) ne fonctionnant plus. Il a fallu, au bout d'une heure de downtime, que je fasse un dernier test avant d'ouvrir un ticket d'incident, et, bien sûr, là ça a marché. Du coup je n'ai pas pu leur remonter l'incident. (et comme j'interviens pour le compte d'un client, avant de leur laisser de potentielles factures de 20€ ou plus, je veux être sûr de mon coup avant déposer un ticket. Même si c'est justifié, pas sûr qu'ils apprécient)

Pour ce qui est du backup backend, de ce que ça a l'air d'en dire :Main backend ip, must be in the same zone as the backup. Et comme j'ai une machine à Rbx et l'autre à Sbg, j'imagine que ça ne peut pas me servir :-P

Pour les probes, pensez-vous que ce serait plus réactif avec quel mode ?

Et (parce que oui, j'abuse :-D !) pour ma question subsidiaire, avez-vous une idée ?

Merci encore pour votre réponse.

starouille
16/05/2014, 17h19
Citation Envoyé par xoros

Tout d'abord, je trouve que c'est particulièrement mou du genou. En effet, chaque demande prend d'une trentaine de secondes à plus d'une minute pour s'exécuter. Ce qui, dans les cas d'urgence, est énorme.
Le but de l'ip LB n'est pas de changer toute sa conf tout le temps, mais d'avoir un système en HA. Une fois que c'est configuré. Tu peux même mettre des IP de backend en "backup" et non en load balancing (pas testé cette fonction encore)

Je n'ai pas testé les poids, pas de retour d'xp pour moi.

Perso je n'ai pas passé en prod, mais ça marche bien en dev sur l'http.

L'https je suis un peu déçu, je voulais du full ssl ( 443 -> IP LB -> 443 -> backend), pour de la souplesse de de la facilité (avec cloudflare en full ssl au dessus). bien sur ça ne rend pas l'usage impossible (faudrait passer en flexible ssl et renvoyer vers l'https en fonction des variables envoyées des front).. mais j'ai la flemme pour le moment j'ai pas eu le courage de modifier pour ça.

Après les probe sont peut être un peu lents, 30secondes ça me semble beaucoup trop. Au final, c'est un ACE évolué et peut être pas une vraie IP anycast. Même si c'est pas mal.

Je crois qu'ovh est ouvert à pas mal de feedback dessus.

Si le full SSL arrive, je passe en prod direct ^^.

xoros
16/05/2014, 16h04
Bonjour.

Je suis en train de faire des tests pour un client sur une archi redondée multi DC.

J'ai pris une IP LB, et j'aimerai savoir pour ceux qui s'en servent s'ils ont les mêmes galères que moi avec l'API ou pas.

Tout d'abord, je trouve que c'est particulièrement mou du genou. En effet, chaque demande prend d'une trentaine de secondes à plus d'une minute pour s'exécuter. Ce qui, dans les cas d'urgence, est énorme.

Ensuite, ça gère les poids affectés comme moi je vole. Mal. Par exemple, je donne le poids par défaut (8) à mon serveur backend à Roubaix, et je colle 100 pour mon backend à Strasbourg. Ben quoi qu'il arrive, il va toujours sur Roubaix. J'ai testé depuis plusieurs IP (des machines chez des clients un peu partout en France), ben rien à faire, je vais toujours sur Roubaix... Alors ok, je suis tout seul dessus, donc peut-être qu'il estime qu'il n'y a pas assez de trafic pour Loadbalancer, mais, du coup, cette histoire de poids ne marche pas.

Ensuite, de temps en temps, ben ça merde. Là, en ce moment, je fais des tests de sessions partagées sur mes 2 serveurs. Et comme quoi qu'il arrive je suis toujours redirigé vers Roubaix, pour pouvoir tester correctement, je suis obligé de supprimer le backend Roubaix pour aller sur le backend Strasbourg. Bon ben là, c'est planté. A savoir que le backend est configuré, l'IP appelée directement fonctionne (et m'affiche mon petit test PHP), mais quand j'appelle l'IP LB, ben.. rien.

La seule solution que j'ai trouvée, c'est de supprimer le backend et le remettre. Et là ça remarche... Donc tant que je fais ça en étant devant, c'est pas (trop) grave, mais si je veux développer des scripts de gestion automatique de mes backends, et bien je suis cuit.

Donc c'est que moi ? Ou il vous arrive à vous aussi ce genre de galère ?

Merci d'avance pour vos retours.

Code:
GET /1.0/ip/loadBalancing/ip-87.98.x.x/backend HTTP/1.1
Host: api.ovh.com
.../...
Code:
HTTP/1.1 200 OK
Access-control-allow-origin:
*
Cache-control: no-cache
Content-type: application/json; charset=utf-8
Date: Fri, 16 May 2014 13:52:33 GMT
X-ovh-queryid: FR.ws-2.x.x.x
[
  "91.121.x.x"
]
Et :

Code:
La connexion a échoué

Firefox ne peut établir de connexion avec le serveur à l'adresse 87.98.x.x.
Question subsidiaire : quelqu'un a réussi à faire fonctionner correctement ses sessions avec 2 serveurs memcache ?