OVH Community, votre nouvel espace communautaire.

Ip fail over avec kimsufi?


phil
21/04/2014, 10h58
Salut

Pour répondre à tes points
2- Ah oui bien vu, je ne connaissais pas ce point. Ceci dit, SYS m'avait laissé l'impression que ce genre de service n'était réservé qu'aux dédiés OVH.
2 (bis) - exactement, je pense que tu souhaites un truc automatisé.
3- Ça dépend de la nature de ton site.

Je crois que le mieux est de te donner un exemple (le mien). J'héberge (entre autre) un wordpress avec un faible trafic. NewRelic me donne comme stats:
1- requêtes BDD: entre 30 et 60 ms
2- requêtes php: entre 300 et 600ms

Effectivement, je cache un maximum avec php5-fpm, memcache, "W3 Total Cache", etc. Et ça aide vraiment, en limitant les requêtes php car le contenu est fourni en statique par les caches. Mais le vrai contenu statique (css, images, scripts, etc.) est extrêmement faible. Un CDN va aider à deux titres:
1- Il décharge ton serveur de la fourniture du "vrai" contenu statique (css, images, medias, vidéos, etc.): gain de bande passante
2- Il fourni ces contenus au plus proches de tes utilisateurs=> temps de réponse très faible.
Dans mon cas, un CDN ne sert à rien. Le site est en français, honnêtement, le faible trafic vient de la France. Peu de contenu statique...
Je ne connais pas très bien le fonctionnement du CDN d'ovh, mais à mon avis, il ne cache pas le contenu dynamique mis en cache statique:
Lu sur http://www.ovh.com/fr/cdn/avantages.xml
3. - Les fichiers/pages demandés sont soit dynamiques, soit en dehors de vos règles de cache. Le CDN aiguille la requête vers votre serveur pour qu’il renvoie les contenus demandés à l’utilisateur.
Alors VPS ou pas VPS?
Je dirais que ton problème initial est que ton ancien VPS ne tenait pas la charge. J'imagine que vous avez pensé à l'upgrader avant de passer sur SYS ? Sinon, généralement, le problème avec des VMs viennent de leur nature:
1- Des châssis de lames
2- Un filer derrière qui porte le datastore: d'où d’éventuels pb. avec les accès disques pour une BDD.
3- Tu as de l'overhead CPU pour les requêtes
4- Cela permet de la mutualisation: d'où une sur-allocation possible de la part d'OVH, leur doc n'est pas super claire. Exemple, on met plus que 8 VMs à 2 cœurs sur une lame avec 16 cœurs.
5- Faut faire gaffe au vmotion automatique: Au taf on s'est déjà retrouvé avec les 4 VMs critiques du service sur la même lame (c'est con!)
6- Mais ça a beaucoup d'avantage, je ne dis surtout pas que la virtualisation c'est pourri !! :-)

En gros, le pb des VMs est que tu ne maîtrises pas tout à fait l'infra et les sur-allocations. C'est du vécu au taf, c'est très pénible. A mon avis, les VPS classiques sont sur-alloués, OVH semble plus garantir l'allocation des ressources pour les VPS clouds.

Pour revenir à ton cas:
Est-ce qu'un KS est mieux qu'un VPS... niveau I/O disque peut-être (mais fais des tests), niveau CPU et mémoire, clairement pas.

En fait tout dépend un peu de tes contenus fournis par tes sites. Je ne veux pas faire de la pub, je n'ai pas d'actions dedans, mais newrelic est assez sympa pour avoir une idée de ce qui consomme sur ton serveur. Ça peut être une bonne idée de tester quelques semaines pour se faire une idée. Ensuite à toi de voir quelle solution s'adapte le mieux à tes besoins et au moindre coût. Dans tous les cas, monte quelque chose qui est facilement scalable.

Good luck

Philippe

arnaud
18/04/2014, 08h24
Pour les problèmes que tu soulèves:

1- Les IP-Fo était vu comme une solution, ce n'est absolument pas un besoin
2- Les IP Load balancing sont dispo pour la gamme VPS : https://www.ovh.com/fr/solutions/ip-...cing/index.xml
2- Manuel, c'est moche en effet. Ta solution ou l'IP LB permet de le faire de manière automatique.
3- En quoi est-ce un problème?

Les KS sont-il vraiment plus performant que tout les VPS?
KS: dual core max, max 4Go

Les VPS sur ces points là propose mieux. Classic 4, 8Go de ram,4 vCore.
Cloud 2 4Go de ram, 4vCore.

Après, il y a des solutions pour limiter la conso IO comme le cache opcode pour php, le cache de donnée.

Les quelques sites de eCommerce ne sont pas (encore) des sites à forts traffic .

Après, je cherche pas forcément une solution + "pro", mais une solution plus sure que ce qu'il y a actuellement (1 seul et unique SYS).
Après le SYS est surdimensionner par rapport au besoin actuel des sites (mauvaise évaluation de la conso des sites à la base).

Je n'ai aucune expérience aussi avec nginx. Si je plante le nginx, Il y a plus de sites du tout. Il y a moins de risque avec la configuration d'une IP LB.
Après si les pages mettent un peu plus de temps à être générer mais que le CDN fournit les contenu statiques plus rapidement. La sensation des visiteurs sera sensiblement la même.

phil
17/04/2014, 15h16
Salut

Pour le VPS, franchement non. Il faudrait que tu donnes plus de détail sur tes applicatifs, mais j'imagine que tu as du php, apache, mysql avec apache qui gère le contenu dynamique. Et peut-être du tomcat ou autre?

En gros:
- les accès BDD => consomme des i/o disk et du cpu
- les apaches (tomcat) exécutent les requêtes PHP => cpu/ram
- le nginx en RP : il ne fait que rediriger les requêtes http et cache le contenu statique => conso ultra faible

Concrètement
  • Tu ne veux pas mettre une BDD sur une VM !! Accès disques berk
  • Les requêtes back-end (php autre), ça va être moisi aussi sur une VM un peu chargée.



Dans ce que je te propose:
Le VPS porte un nginx qui consomme peu de ressource.
Le back-end tourne sur tes serveurs dédiés (SYS/KS)
C'est OVH qui te garanti l'uptime de ton VPS (ils ont du vmotion, du HA etc.) Leur uptime est imbattable et ils te garantissent un redémarrage en 5 min si panne hardware. Tu ne fera pas mieux avec une IP-FO, en plus le VPS cloud c'est pas des IP-FO...
Franchement, le nginx n'est pas prêts de saturer ta VMs à 2 coeurs, t'as bien vu l'exemple , c'est quand même impressionnant. Au pire, tu upgrades à 4.


Le problème avec ce que tu proposes:
1- Les IP des VPS cloud ne sont pas des IP-FO
2- Ya pas de mécanisme de load-balancing sur les VPS (sauf erreur ...)
2- une IP-FO c'est une bascule manuelle (c'est moche non ?)
3- le CDN infra, c'est sympa pour cacher les contenus statiques (media, images, etc.) au plus près de tes clients.


Remarque: je me suis peut-être trompé sur la nature de tes sites.
  • Si tu as des sites de streaming de films de cul, ok, ce que je t'ai dit est probablement faux => Go VPS et CDN Infra.
  • Si ce sont les requêtes back-end qui chargent ton serveur => Go installer un VPS avec nginx et mets le back-end sur ton SYS/KS


Bon c'est sûr, ça fait bidouille. Mais si tu veux des vrais LB, avec des vracks et plein de trucs + pro, ben il faut que monte en gamme...

Philippe

arnaud
17/04/2014, 10h07
Donc si je résume,

Pour la configuration que tu proposes, il faudrait. 1 VPS et 2 Serveurs.
Ici, le VPS ne risque pas d'être le goulot d'étranglement?
C'est celui qui a la plus petite configuration sur tout le point (ram, proc., bande passante).

Ne vaudrait-il pas mieux prendre 2 VPS (genre classis 4), une IP LB et un CDN infra?

Sur les 2 VPS, de l'apache avec synchronsation des fichiers et une configuration Mysql Master/Master.
Après, pour le cache et le load balancing ce serait au final fait par l'infra OVH.
ça ne serait pas plus efficace comme ça?

En tout cas merci pour ton aide, ça permet de réfléchir à des solutions que je n'aurais pas pu envisager quelque mois plus tôt.
Si j'avais eu conscience de ces problématique et solutions plus tôt, le choix de la solution d'hébergement n'aurait surement pas été les mêmes.

phil
16/04/2014, 18h59
Re

Je viens de tomber sur cet article sur le site de nginx. En gros les gars expliquent
In our company we use Nginx as a reverse proxy, serving HTTPS to the client while getting the content via HTTP from the multiple backends. We have two virtual machines "connected" with VRRP to one cluster, acting as a frontend for about 80 Tomcat servers (and some IIS, Apache/PHP ...), each with one or more applications.
Bon, tu n'auras pas de VRRP avec les VPS OVH mais en gros ils ont 2 machines virtuelles en actif passif avec comme conf:
Hypervisor: VMware ESXi
VM: 4x CPU (load: 0.15), 768 MByte RAM (used: <10%), 4 GByte HD
Base system: Ubuntu 12.04.4/precise
Working horse: Nginx 1.4.5-1+precise0 (ppa:nginx/stable)
Ils n'indiquent pas clairement le nombre de req. par seconde, mais ça te donne une idée de ce que peux encaisser une telle configuration. Les concepts nécessaires à ta config restent les mêmes que ceux décrits la dedans, sauf que ta VM traiterait les requêtes http et https.

Tu peux ensuite aussi configurer nginx pour cacher les requêtes vers du contenu statique (images, .css, etc.). Généralement, je monte le cache sur un ramdisk. C'est brutal, mais c'est imbattable, surtout que le point fort de nginx est de servir le contenu statique rapidement et à faible coût. Et en plus, le disque des VMs OVH est très probablement hébergé sur un datastore monté en NFS, donc les accès disques sont bof à la base.

Philippe

phil
15/04/2014, 17h46
Le problème des KS et des IP FO... Oles a annoncé le mois dernier des IP FO pour les KS, et au final ne l'a pas fait. Et OVH se tate toujours pour mutualiser les managers...

Mais aujourd'hui, sauf erreur de ma part et c'est difficile d'y comprendre quelque chose:
  • pas de ipfo pour les nouveaux KS
  • ipfo pas transférable entre un vieux KS qui en dispose et un SYS


Ceci dit, si tu as seulement 2 sites, au pire 4 ou 5... Il est toujours possible de mettre un TTL de 1h (voir plus court) sur les DNS et de basculer manuellement les dits DNS si besoin. C'est crado, ça met une bonne 1h a se propager, mais ça marche. Pour l'avoir testé quand je suis passé de KS à SYS, les FAI semblent respecter le TTL que tu fournis dans ta config dns.

Pour l'exploitation des serveurs... Faut voir comment vous êtes organisés. Mais de toutes façons, un jour ou l'autre un serveur va tomber en rade, tu vas avoir une galère sur une BDD, etc... Et si tu es le seul en charge de l'exploitation, sauf si tu pars en vacances en antarctique...


A la limite, ce que je peux te suggérer, c'est de prendre un VPS. Si si!! (va voir les trucs clouds parce que tu as plusieurs ip par serveur, sinon prend la gamme vps classic). Exemple:
  • 1 VPS -- Nginx en RP/LB
  • 1 SYS avec apache backend et BDD en maître
  • 1 KS avec apache en back-end et BDD en esclave

Et les apaches sont configurés pour se connecter à la BDD maitre. La BDD esclave se synchro en lecture. Bon je connais pas super bien les BDD donc il existe probablement des système de cluster plus subtils. Une recherche vite fait me pointe vers HA Proxy (chapitre 7!!) mais honnêtement, à toi d'étudier la question et surtout si l'applicatif derrière le supporte sans corrompre tes BDD !

La grande idée d'un tel montage:
  1. ton VPS en en HA parce que hébergé sur des sytèmes vmware/cloud ou autre d'OVH => dans la pratique tu auras un uptime excellent et tu n'es pas trop soumis aux pannes de matos.
  2. un nginx en RP, sauf à avoir un trafic de malade en SSL, ça reste léger. Étudie ton système, mais à mon avis ce sont les requêtes en php et mysql qui consomment le plus.
  3. En plus tu peux arriver à un système super bien sécurisé parce que ton seul serveur en point d'entré est le nginx, et ton SYS et KS n'acceptent de discuter qu'entre eux et le nginx (sauf pour l'admin of course!!).


Voilà, c'est la meilleure idée que j'ai. Si t'as bien configuré ton cluster de BDD, normalement, une requête client va arriver sur le nginx en frontal, être load-balancée sur un des apaches qui fera des requêtes sur son HA Proxy local qui pointera vers une des deux BDD tant qu'elle reste up.
  1. En nominal, tu es sûr et certain qu'à n'importe quel moment ton backup est fonctionnel
  2. Tes BDD devraient être répliquées proprement
  3. Si ton SYS se plante, le KS reprend la charge (voir la config healthcheck du nginx).
  4. t'as même pas besoin d'IP FO à 2€ l'unité !
  5. ton système est scalable


Caveat emptur: Encore une fois, je ne suis pas un pro de la base de données. Je te garanti juste que la partie VPS/nginx/apache fonctionnera et fonctionnera bien. Si tu corromps tes BDD avec mes conseils, c'est ton problème

Philippe

arnaud
15/04/2014, 15h02
Merci pour la réponse.

Il y a déjà un SYS en place qui accueille maintenant les 2 sites de eCommerce qui était auparavant sur 1 VPS chacun.
Ce même SYS sera aussi amené à accueillir d'autres sites.

Pour la première idée, si les KS n'ont pas d'IP FO, ça va pas le faire. Et je crains une diminution de perfs de passer du SYS à 2 KS (48Go de RAM contre 8).

Pour la 2ème idée, c'est bien sur à mettre en place. Si ça tombe en rade quand je suis au boulot, ça se fait.
Mais si ça tombe en rade pendant que je suis en vacances, en camping, à la plage le téléphone rester au camping. C'est difficilement reparti dans la journée.

Par contre si un PCA correct est mise en place, on peut accepter une petite dégradation de performance le temps de pouvoir tout remettre en place est déjà plus acceptable.

Pour le serveur prêt à rentrer en action, il faut jouer un scénario de test au même titre que tu joue ton scénario de PRA en VM.

Après, la réplication temps réel de la BDD et la synchronisation des fichiers des sites web, c'est un autre soucis.

Donc en gros, je prends une (ou plusieurs) IP FO sur le SYS. Après la vrai question est de savoir si le SYS tombe en rade s'il y a moyen de faire la bascule sur un KS ou si c'est obligatoirement sur un SYS.

La solutions des 2 SYS peut-être envisageable. La différence de budget entre deux E32-1 et un W35-3 + un PS-17 n'est au final pas si énorme.

Il y aura juste le mois de mise en place qu'il va falloir placer (3 serveur + 2 frais d'installation).

Merci pour cette réponse qui m'as fait pas mal cogiter.

phil
15/04/2014, 12h00
Salut

Non les IP FO ne passent pas d'un JS vers un SYS, si tu disposes d'un KS avec IP FO ...

Par contre, il y a beaucoup de chose faisables tout dépend du budget (of course). D'après ce que tu expliques, j'ai l'impression que 2 SYS ca fait trop.


1ère idée: pourquoi pas plutôt 2 KS ?
Si vous partez d'un VPS, les gains de perfs seront toujours au rendez-vous.
Par contre, il faut bien une IP-FO et avec tous les changements de politique commerciale d'ovh sur ce sujet.. Heu je ne sais plus du tout si c'est encore possible. Mais je ne crois pas, l'idée d'OVH est de forcer toute utilisation professionnelle vers SYS...
Sinon, à défaut d'IP-FO il faut modifier à la main les DNS et attendre que les dites modifs se propagent dans le réseau ~24h

2ème idée: scripts de back-up/restore
Moi je te conseillerai de faire un script de restauration de votre serveur (voir ce post) accompagné d'un backup quotidien ou plus selon les besoins.
  • Une restauration se fait en 30 min max (reformatage, récup des back-ups etc.)
  • Tu peux recréer un testbed sur une VM en local. Utile pour qualifier tout changements avant mise en prod

Par contre
  • L'espace de backup FTP de SYS est limité à 100 Go
  • il faut régulièrement tester/faire évoluer le script à chaque changement majeur sur la prod.
  • en fait c'est un PRA. Mais vu les moyens dont vous disposez, c'est peut-être la bonne solution.


A propos de l'idée d'avoir un serveur de backup prêt à rentrer en action... Ça ne marche jamais vraiment. Sois sûr qu'il y a toujours des évolutions de config, des modifs qui n'ont pas été suivies, des mises à jour foirées et hasard, le jour où tu as besoin du backup, rien ne marche et tu passes 1/2 journée minimum de débug pour tout relancer. C'est pour ça, je ne suis jamais trop partisan d'un système actif/passif mais plutôt actif/actif..

3ème idée
Si vous avez assez de thunes pour 2 serveurs identiques avec IP-FO... Dans ce cas montez tout en double. Exemple sur 2 serveurs:
2 nginx pour le reverse-proxy/load-balancer en frontal en actif passif
2 apache pour le back-end en actif/actif (déclarés dans le pool des nginxs)
2 MySQL actif/passif. L'actif porte l'IPFO auquel se connecte les apaches. Le passif est en esclave et réplique le maître.

Vu ce que propose SYS (pas de vrack etc.) c'est ce qui ce rapproche le plus d'une solution pro.
En cas de crash du serveur maitre, basculez les FO avec modif de la config de la BDD esclave pour la passer en maître. Au moins tu es sûr que l'apache passif fonctionne. Le nginx pas trop de risque, il ne servait que de RP/LB, la base de donnée... Ça devrait...
Autre avantage d'une telle solution, elle est scalable. Par exemple, tu peux séparer sans trop de difficultés les BDD sur un cluster de serveurs dédié. Tu peux rajouter autant de serveurs apaches que tu veux dans le pool. Normalement, les nginx devraient encaisser une belle charge avant qu'ils deviennent insuffisants. Bref, le jour où les nginx saturent, c'est le moment de payer une solution OVH pro avec des vrais load-balancers etc.

Philippe

arnaud
15/04/2014, 09h26
Bonjour,

à la base je suis développeur, mais je dois aussi m'occuper de l'hébergement des sites de e-Commerce de ma boite.

On est donc parti sur un SYS histoire d'avoir des sites réactifs et de prévoir les futurs montées en charge.
(les changements de VPS à SYS a fait énormément de bien au perf des sites).

Donc on a un beau SYS qui fait tourné les sites. Le truc, c'est qu'il n'y a qu'un seul serveur.

Il est donc temps de penser à un mettre en place PCA, PRA.

Donc pour le PCA, je pensais mettre en place un PS-17 (KIMSUFI) qui serait un serveur backup du SYS et qui devrait être prêt à rentrer en action s'il y a un problème avec le SYS.
Il sera aussi utilisé pour fournir des fichiers statiques pour les sites (pseudo CDN) tant que le SYS fonctionne correctement.

Donc d'après ce que j'ai compris, pour mettre en place ça correctement, j'aurais besoin d'IP fail over.
Ma question est donc de savoir si on peut mettre en place une (un?) IP fail over qui puisse faire la bascule SYS -> KIMSUFI le temps de remettre le SYS sur pied.

Je me doute bien d'un ip fail over SYS / SYS ne pose pas de soucis, mais c'est pas tout à fait le même budget.

N'ayant jamais touché les ip fail over, je ne souhaite pas partir sur des dépenses qui ne permettrait pas de faire ce qui est souhaité.
De même, si pas possible de faire ip fail over SYS/KS, faut que j'arrive à justifier la différence de budget qui n'est pas négligeable.

Merci d'avance pour vos réponses.

PCA: Plan de Continuité de l'Activité
PRA: Plan de Reprise de l'Activité