Replication - rsync - bascule automatique du trafic

[DenisL4]

Bonjour à tous !

Je cherche une solution et aussi des retours d'expérience sur une problématique.

Le contexte : une boutique en ligne avec beaucoup de références et pas mal de trafic. Elle est posée sur un dédié (serveur A) et dispose d'un duplicata sur un autre autre serveur dans un autre datacenter (serveur B). La synchro entre les 2 se fait par une replication MySQL Master/Master et un rsync (unidirectionnel pour le moment de A vers B). Je vous rassure j'ai aussi des backups en parallèle...

La problématique : quand le serveur A a un souci du genre Apache qui est planté ou MySQL qui ne répond plus ou ... J'aimerai que le trafic soit redirigé vers le serveur B sans manipulation humaine et avec une indisponibilité minimum.

Les pistes :

• un CDN, je ne vois pas l'intérêt ici

• une ip fail-over : ça va être dur car ce n'est pas le même datacenter et comment détecter la défaillance d'Apache par exemple pour permuter de A vers B tout seul ?

• un load-balancing : ce n'est pas une question de répartition de charge et idem comment permuter de serveur en automatique si Apache ne répond plus ?

Il existe surement une solution "simple" à mettre en oeuvre et c'est le genre de question qui ne doit pas être rare. Si je la pose c'est aussi pour connaître vos retours d'expérience sur ce sujet.

[janus57]

Bonjour,

Pour votre problématique c'est le load-balancing qui se rapproche le plus de vos critères vu qu'il est capable de faire la bascule automatique si les sondes sont bien configurés.

Cordialement, janus57

[DenisL4]

Bonjour,

Merci pour la réponse. C'est bien ce qu'il me semblait.
Vous en avez déjà mis en place ? Ou si vous avez des conseils ?
Merci

[janus57]

Bonjour,

En laboratoire oui mais chez OVH non, après à voir de voir ce que vous souhaitez exactement, mais là au niveau de vos caractéristiques c'est clairement un load-balancing en mode failover qui vous convient.

Cordialement, janus57

[TBC_Ly0n]

Bonjour,

Je propose une approche différente, dans la mesure où du moment que chaque composant est isolé, il est plus simple d'agir dessus et proposer des solutions pérennes et simples à maintenir.

Pour les bases de données : MariaDB 10.2 + Galera + ProxySQL

• Simple à mettre en oeuvre, il permet à tous les frontaux de détecter automatiquement la perte d'un ou plusieurs noeuds.
• Il faut au minimum trois serveurs Galera (la préco est à 5 pour limiter la perte de performances pendant un crash, un noeud se rendant indisponible pendant la synchro)
• En fonction du volume de la base, on se posera la question de la méthode de (re)construction.
• Les proxySQL seront installés sur les serveurs frontaux (préconisation Galera). Il est possible de les faire travailler "ensemble" au niveau de leur configuration (relativement récent)
• Attention à mettre les machines dans des datacenters avec une latence faible sous peine d'avoir des temps de réponse dégradés. En fonction de l'applicatif, ça peut avoir de fortes répercussions.

Pour les frontaux :

• Un CDN a l'avantage de transférer le travail de synchronisation à un prestataire extérieur. On peut alors se contenter de ne garder en local que le code applicatif et laisser tout le contenu "volatile" dans le CDN.
• En fonction des volumes d'écriture, il est aussi possible de se reposer sur une offre NAS. Les débits sont pas toujours follichons, avec différents outils de cache, on doit pouvoir atteindre quelque chose de raisonnable en termes de performances.
• Si le code évolue peu, des rsync réguliers peuvent solutionner le problème de synchro
• Pour une bascule automatique, il faut se reposer sur les IP Load Balancing. En Failover, ce serait à toi de gérer la bascule. Ca se fait, mais tant qu'à faire, autant se baser sur une infrastructure validée par quelqu'un d'autre :)

Quelques détails :

• La configuration des différents composants doit être sous contrôle : une modification sur un des serveurs doit être répliquée sur les autres. Soit automatiquement (Puppet, Chef, Rudder), soit manuellement (rsync, scripts...)
• Le paramétrage Master-Master n'empêche pas la corruption des binlogs et par voie de conséquence l'arrêt de la synchronisation, en particulier lors d'un crash brutal de la machine. Surtout, une machine dont la synchro a été interrompue ne doit plus être utilisée sous peine d'avoir des comportements incohérents. Elle doit d'abord être reconstruite.

A disposition pour affiner tout ça si nécessaire.
https://www.hebergement-pro.org/

[DenisL4]

Bonjour,

Merci pour toutes ces informations, c'est vraiment intéressant. On voit que tu connais le sujet.
Par contre côté budget ça risque de coincer (même si c'est de l'open source, le temps de travail est à prévoir)...
Est-ce qu'il existerait une solution de load balancing "simple" style : serveur A fonctionne selon mes sondes, j'envois sur A sinon sur serveur B ?
Je sais c'est très basique et cela sera amené par la suite à évoluer mais pour le moment ce serait déjà ça.

[JeanR]

Bonjour,

Si tu es chez OVH, ils ont une solution de loadbalancer
Tu pourra configurer tes 2 serveurs dessus, le A sera le master toujours actif et le B le backup actif en cas de défaillance du serveur A
Les sondes OVH sont basées sur les ports 80/443 ce qui te permettra de basculer automatiquement lorsque apache est coupé.
Le soucis que tu peux avoir c'est lorsque mysql est coupé, il faut que ton serveur réponde autre chose que 200 OK Erreur de connexion à la base de données sinon il n'y aura pas de bascule.

L'investissement pour cette mise en place est assez léger.

Il y a une solution avec l'ipfailover, il faut que tu mette tes serveurs et tes ipfailover dans un vrack, ensuite c'est toi qui gère les ip sur tes serveurs indépendamment de l'infra OVH.
Un keepalived, ucarp, heartbeat ou autre service du genre te permettra de basculer l'ip d'un serveur à l'autre automatiquement sans intervention humaine.
L'ip reviendra naturellement à sa place lorsque le service sera à nouveau disponible.

Bon courage

Captain Admin, Si ce n'est pas lui, qui vous sauvera ?

[TBC_Ly0n]

Sauf qu'il ne faut surtout pas revenir sur le serveur d'origine si la réplication entre les serveurs a sauté. C'est la limite de la réplication classique MySQL.

[JeanR]

Alors tu ne démarres pas apache automatiquement au démarrage du serveur et avant de le relancer tu remets la réplication en place.

[TBC_Ly0n]

Du coup, non seulement on n'est plus sur un mode automatique, mais en plus, il nécessite des actions humaines supplémentaires qu'il faudra documenter... et ne pas oublier de réaliser dans le bon ordre.

Autant dire que le jour J, ça risque de ne pas fonctionner comme attendu. C'est la limite de l'exercice dès qu'on souhaite monter des infrastructures redondantes.