OVH Community, votre nouvel espace communautaire.

Répartition sur 2 serveurs SYS


bbr18
10/06/2016, 10h29
Vous êtes partis sur une discussion certes très intéressante mais pas en rapport avec la question posée, il s'agit de serveurs SYS, ils n'ont pas ces fonctionnalités ^^

sich
09/06/2016, 17h30
Intéressant de savoir qu'une nouvelle infra pour l'IP LB est en préparation.
Sera t'il possible via l'API de filtrer les IP client sur l'IP LB directement ?

Je m'explique, j'ai fail2ban qui tourne et en cas d'attaque je ne peux pas bloquer l'ip source.... Vu que le serveur ne voit que l'IP du balancer... J'ai pas mal de sites qui utilisent cloudflare, par conséquent via l'API de cloudflare je peux bloquer à la source, mais ce n'est pas toujours possible pour les scans en direct sur l'IP ou pour les sites qui n'utilisent pas cloudflare...
Par conséquent l'usage de l'API pour bloquer des IP directement sur l'IP LB ça serait vraiment très pratique.

AlexR
09/06/2016, 17h15
Bonjour,

Je tiens à apporter quelques précisions quant-au fonctionnement de l'IP Load Balancing.

Il y a maintenant plus d'un mois nous avons eu effectivement un incident sur cette offre qui a duré plus d'une journée. Cela a donc naturellement impacté nombre de nos clients. Nous nous excusons pour la gêne occasionnée, cela nous a d'ailleurs convaincu de sortir une nouvelle version de l'IP Load Balancing basée sur une autre Infrastructure.

Nous nous sommes décidé sur une Infra basée principalement sur de l'HAProxy avec derrière nos différents équipements pour améliorer la scalabilté des requêtes ainsi que l'anti-DDOS. Pour plus d'informations à ce sujet je vous invite à vous inscrire sur la Mailing List créée pour l'occasion : iplb@ml.ovh.net. (iplb-subscribe@ml.ovh.net pour s'inscrire)

Pour le fonctionnement de l'ancienne IPLB (toujours disponible pour le moment) voici quelques détails techniques :

Nous utilisons la technologie Anycast, cela signifie que si vous avez des backends au sein de différents datacentres alors la répartition par poids n'est plus prise en compte. Ce qu'il se passe c'est que les visiteurs sont automatiquement redirigés vers le backend le plus proche d'eux géographiquement.
De même, si votre site utilise l'HTTPS alors sachez que le certificat SSL devra obligatoirement se trouver sur l'IPLB. Ce pour une raison simple : si l'ACE (IPLB) n'a pas la connaissance du certificat alors elle sera dans l'incapacité de déchiffrer et de renvoyer les requêtes. A ce sujet d'ailleurs, sachez que toute la connexion ne se fait pas de bout en bout, la config sur les backends doit être en HTTP classique, pas sur le port 443. Nous avons nos guides où nous expliquons ce principe :

https://docs.ovh.com/display/public/...load+balancing

Enfin, pour ce qui est des IP Failover sur VPS cela n'est plus très exact désormais. Oui, maintenant vous pouvez migrer des IP failover VPS vers d'autres services, en revanche cela n'est possible que pour les VPS 2016. Vous ne pourrez pour le moment faire cette opération que depuis l'API via /vps/ip/move.

Cordialement, Alexandre R.
Technicien Support IT Cloud

mantex
09/06/2016, 11h32
Citation Envoyé par passetemps
2 jours d'indisponibilités en suivant tu appelles cela comment ? Mon monitoring a constaté plus souvent l'IP en défaut pendant notre mois d'essai que UP. J'ai testé le LB il y a 3 ou 4 ans j'ai fuit à l'époque, je restesté il y a 1 an sur Graveline, catastrophique le système plante sans raison et pas de nouvelle de la part d'OVH, au téléphone j'ai même eu un admin qui m'a confirmé qu'il y avait beaucoup de problème avec. Tu étais peut être sur une plage d'IP qui n'a pas eu de problème ou tu ne t'est pas rendu compte du problème. Jette un œil sur Twitter c'est aussi édifiant.
Oui moi aussi j' ai été impacté, sur le gros down qu' il y a eu il y a quelques temps, j' ai modifié les entrées dns des domaines pour bypasser l ' ip failover et ça refonctionné quelques heures après. J' ai d' ailleurs mis en place une procédure simple pour switcher rapidement (ttl à 3600) vers une autre zone ( merci Gandi ) tous les dn concernés en une fois si cela devait se reproduire.

Citation Envoyé par passetemps
Ceci dit pour répondre à un autre message une solution a base d'Apache avec 2 VPS 2 IP FO (je sais pas si le FO est possible sur VPS moi j'utilise des serveurs physiques) la solution revient à environ 2 heures pour tout configurer et environ 40 euros HT / mois.
Non les FO sur les vps ne sont pas déplaçables , hélas, par contre éligible au nasHA depuis quelques temps et ça c'est une bonne nouvelle.

passetemps
08/06/2016, 16h17
Citation Envoyé par mantex
Cependant ils ne faut pas généraliser des problèmes particuliers et autres événements qui peuvent arriver sur n' importe quel service managed et le forum n'est qu' un baromètre subjectif. IL faut rappeler que des gens postent ici quand leur partition / est full. Est ce la faute d' OVh , non bien sur.
2 jours d'indisponibilités en suivant tu appelles cela comment ? Mon monitoring a constaté plus souvent l'IP en défaut pendant notre mois d'essai que UP. J'ai testé le LB il y a 3 ou 4 ans j'ai fuit à l'époque, je restesté il y a 1 an sur Graveline, catastrophique le système plante sans raison et pas de nouvelle de la part d'OVH, au téléphone j'ai même eu un admin qui m'a confirmé qu'il y avait beaucoup de problème avec. Tu étais peut être sur une plage d'IP qui n'a pas eu de problème ou tu ne t'est pas rendu compte du problème. Jette un œil sur Twitter c'est aussi édifiant.

Ceci dit pour répondre à un autre message une solution a base d'Apache avec 2 VPS 2 IP FO (je sais pas si le FO est possible sur VPS moi j'utilise des serveurs physiques) la solution revient à environ 2 heures pour tout configurer et environ 40 euros HT / mois.

mantex
08/06/2016, 15h55
Oui , Octave à annoncé les routeurs Cisco (ACE) utilisés jusqu' a présent vont être abandonnés.

Cependant ils ne faut pas généraliser des problèmes particuliers et autres événements qui peuvent arriver sur n' importe quel service managed et le forum n'est qu' un baromètre subjectif. IL faut rappeler que des gens postent ici quand leur partition / est full. Est ce la faute d' OVh , non bien sur.

Tout n' est pas mauvais donc. IPloadBalancing une solution à moindre côut facilement déployable pour faire de la haute dispo, cela évite notamment d' avoir à gérer des serveurs pour faire de la répartition "homemade" via Haproxy. Ce ne sont pas les mêmes compétences engagées et donc pas les mêmes côuts.

Effectivement moi aussi un des mes clients a été impacté il y a quelques semaines maintenant par le problème sur l' IPLB , mais en même j' ai une autre infra qui tourne depuis plus de 2 ans avec IPLB qui elle tourne sans aucun problème et à permis à l' époque de monter cette infra rapidement.

Il faut bien garder en tête que ce n' est parce que je suis impacté à 100% par un problème sur un service que tout 100% des clients utilisant ce service le sont. Si c'est le cas OVH fait en sorte que ça ne reproduise plus. J' ai pu observer depuis plus de 10 ans et des dizaines de machines administrées plus tard que c' était bien le cas, sinon je serai parti à la concurrence.

Nous faisons pour la plupart des métiers techniques, les problèmes à résoudre sont notre quotidien , ne pas y apporter de solution n' est pas digne d' un professionnel responsable.

MB.

sich
08/06/2016, 15h53
Pour ma part en plusieurs mois d'utilisation je reconnais avoir eu 2x des problèmes. A chaque fois coupure intermittente de l'accès aux serveurs pendant 2 à 3H. Heureusement pour moi à des heures creuses.

C'est vrai que ce n'est pas terrible, mais le service gère très bien les redirections / ajout-suppression de nodes et le tout pour une dizaine d'euro...

Certes quand on mets en place un load balancing ce n'est pas pour avoir des problèmes de coupures, mais toujours est il que le rapport qualité / prix reste à la hauteur...

Mettre en place son propre load balancing demande un budget bien plus conséquent.

passetemps
08/06/2016, 15h09
Citation Envoyé par sich
- Comment gérer la répartition d'un serveur à l'autre ?
Pour ma part j'ai une IP Load Balancing de chez OVH. Fonctionne très bien en règle générale. Jusqu'à 16 hosts derrière. Probablement pas compatible avec les serveurs SYS.
non l'IP LB made in OVH est une catastrophe ce service est une honte et ne fonctionne pas bien du tout. En témoigne les nombreuses plaintes sur ce forum et sur les listes de diffusion. Je sais par contre qu'ils sont en train de préparer un nouveau système de LB pour replacer l'existant.

mantex
07/06/2016, 18h52
Tout à fait @sich , c'est de la tolérance au panne qui assez rare sur Mysql , mais le problème de charge se situe souvent sur les frontaux à cause de php . L' objectif est alors de taper moins souvent sur le sql via les caches, voir de ne pas l' utiliser (ex les sessions ) qui vont être fréquentes sur un site à fort traffic. La répartition mysql ne sera alors nécessaire.

mais @asmrct peux tu nous en dire plus sur ton applicatif ?


NB : Prestashop permet nativement de faire du master/slave depuis la version 1.4 du plus loin que je me souvienne.

sich
07/06/2016, 18h36
Oui, mais là c'est de la tolérance de panne et pas de l'équilibrage de charge.
Toujours utile toutefois.

J'ai trouvé pour Wordpress par exemple il existe le plugin HyperDB qui gère ce genre de problématique justement.
Cela permet de très facilement mettre en place une répartition de la charge, vu qu'une réplication master/slave est tout de même plus simple à mettre en oeuvre et à réparer en cas d'accident qu'un cluster multi maitre.

mantex
07/06/2016, 18h18
Cela peut être aussi un mode "failover" simple , si/quand le master tombe toutes les X ans ou pour les maintenances , cela permet une solution de continuité de service simple et rapide .

sich
07/06/2016, 18h14
Par contre dans le cas d'archi master / slave je présume qu'il faut adapter l'applicatif... Ou alors un moyen de redirect les requests en lecture seule vers le slave et les autres vers le master ?
Car dans le cas d'un site qui n'est pas programmé dans cette configuration le scénario master/slave n'est pas possible.

mantex
07/06/2016, 18h07
Ouoi bien sur avec un couple de serveurs mysql ( master/slave) , c'est un type d' archi à 4 serveurs minimum.

A noter que les vps sont éligibles à l' iploadbalancing pour faire du débordement de traffic à moindre coût.

sich
07/06/2016, 17h55
le nas sera ok pour les fichiers, pas pour la bdd par contre.
Mais pour les fichiers c'est parfait oui.

mantex
07/06/2016, 17h43
Bonjour,

IL y a aussi la possibilité de prendre des serveurs de la gamme OVH et un nasHA pour partager en NFS les données entre les frontaux, la solution iploadbalancing repartira les requêtes entre les frontaux.

Avec ce type d' archi j ' arrive à absorber 10k sessions simultanées.

TBC_Ly0n
07/06/2016, 15h00
Bonjour,

Plusieurs axes de réflexion :
  • séparer Apache de MySQL. Ca permettra d'avoir plus de RAM, donc, plus de capacité pour l'un et l'autre de travailler avec toute la RAM. Les deux adooooorent la RAM)
  • Tuner MySQL. Tuning-primer + mysqltuner.pl. c'est ma spécialité, le tuning MySQL.
  • Tuner Apache. On regardera le MPM le plus approprié aux flux. (prefork est le plus gourmand, il y en a bien d'autres), on virera les modules inutilisés... PHP-FPM avec des opcode cache peut grandement améliorer la situation surtout en cas de charge élevée.
  • Mettre en place un esclave MySQL qui s'occupera de ne faire que des lectures de données. Sur des flux majoritairement en lecture, on arrive à avoir d'excellentes performances et surtout d'avoir plusieurs esclaves ! Pour répartir les requêtes, soit on le fait dans le code, soit on le fait via MySQL-proxy.
  • Le cluster MySQL, le vrai est assez "chiant" à monter et à maintenir. J'aurais tendance à d'abord orienter vers une réplication et voir comment ça se comporte.
  • Pour multiplier les serveurs Apache, il faut voir la vitesse d'évolution des fichiers, et donc, la manière de synchroniser les fichiers. Les solutions ont été proposées, Unison, NFS, rsync, DRBD... DRBD est sympa, sur l'environnement OVH il faudra le configurer de manière plutôt permissive pour tolérer les micro-perturbations liées au réseau OVH.


De manière générale, dès qu'on commence à aller chercher de la haute disponibilité, on isolera les composants sur des serveurs dédiés, les mécanismes de réplication de données n'étant pas les mêmes.

sich
07/06/2016, 10h52
Perso j'ai une infra comme ça à base de public cloud. 3 SP-30 qui sont synchronisé en permanence.
Dans ton scénario tu dois te poser plusieurs questions :

- Comment gérer la répartition d'un serveur à l'autre ?
Pour ma part j'ai une IP Load Balancing de chez OVH. Fonctionne très bien en règle générale. Jusqu'à 16 hosts derrière. Probablement pas compatible avec les serveurs SYS.

- Comment assurer le suivi des sessions ?
De mon côté les sessions sont gérées via memcache. De plus l'IP LB d'OVH renvoie toujours un client sur le même serveur.

- Comment assurer la synchro des données ?
Pour ma part j'ai un cluster mysql pour la base de données. Ensuite j'ai un script unison qui se lance toutes les minutes pour synchroniser les fichiers.
Unison toutes les minutes étant amplement suffisant pour moi au vu de mes besoins. Si tu as besoin d'une synchro temps réel tu dois regarder du côté de drbd.
A noter que pour un cluster MySQL les tables MyIsam sont interdites.


Ensuite quand j'ai des pics de charge j'ajoute des instances public cloud derrière l'IP LB en ayant pris soin de synchroniser tout ça en amont.


Avant d'en arriver là as tu penser à prendre un CDN comme cloudflare ? Je présume que tu as un système de cache pour tous les utilisateurs non authentifié histoire de leur envoyé des fichiers html et ne pas avoir à tout recalculer à chaque fois.

Et quels sont tes points de saturation ? Bande passante ? cpu à cause de mysql ? Charge trop importante sur les disques car manque de cache quelque part ?


Sinon concernant la connexion entre les serveurs tu peux mettre en place un vpn. Pour ma part les miens sont connectés via tinc. Ensuite tu ouvres les ports uniquement sur le vpn et tout se passe bien.
Quand à la bande passante saturé entre tes serveurs ça ne devrait pas être le cas, sauf si tu dois synchroniser en permanence de gros fichiers qui changent tout le temps... Mais une synchro mysql ou même quelques fichiers images ne devraient pas saturer ta bande passante si facilement.

asmrct
07/06/2016, 10h31
Bonjour à tous,

Je m'occupe d'un site qui connaît de forts pics de charge lors de certains évènements sportifs dont il traite. J'avais envie de tenter une répartition de charge avec deux dédiés SYS, mais j'hésite entre deux configurations :

- Séparer avec un serveurs de fichiers et Apache d'un côté et un serveur MySQL de l'autre (ce qui signifie ouvrir une connexion distante MySQL, faille de sécu potentielle ?)

- Faire une répartition de charge en envoyant les visiteurs sur l'un ou l'autre serveur mais cela signifie de maintenir une synchro permanente entre les deux serveurs (fichiers et bdd) ce qui peut être un peu complexe à gérer, non ?

De plus il me semble que SYS ne propose pas de vRack, donc est-ce que je ne risque pas de bouffer ma bande passante en synchronisant les deux serveurs ?

Merci par avance pour vos retours,