Système HA sur Public Cloud

[NicolasV64]

Bonjour à tous,

Je possède une machine dans le Public Cloud de type B2-15 située à GRA5. Suite à la perte d'une autre machine lors de l'incendie à Strasbourg, je souhaite mettre en place un server clone dans un autre data center. Je souhaitais entreprendre les actions suivantes:

• Commander une deuxième instance dans un autre Data Center
• Dupliquer la première instance vers la deuxième
• Mettre en place un système de clone en temps réel (ou le délai le plus court possible) de la première instance vers la deuxième via le LAN d'OVH
• Configurer un failover si la première instance tombe

Auriez-vous des conseils sur la faisabilité de cela ou existe-t-il un meilleur moyen d'atteindre l'objectif recherché? Je suis assez novice dans la gestion serveur et sous Linux donc veuillez pardonner mon ignorance.

Je vous remercie pour votre aide.

[TTY]

Ce que vous voulez, c'est de la haute disponibilité.

Et ça ce n'est pas simple, encore plus si vous débuter dans l'admin systeme.
Je ne fait pas ce genre de prestations, mes clients n'étant pas prêt à dépenser plus que quelques cacahuètes pour leurs hébergements. Mais je jette qq idées / pistes :

• Il faudra configurer les 2 serveurs de BDD en master / slave.
• La syncho fichier peut se faire via Rsync (over SSH si vous n'avez pas de VLAN attachés à vos instances)
• Pour le watch dog et le changement d'IP failover là on rentre un peu plus dans le bricolage mais vous pourrez sûrement le faire via l'API d'OVH (pas sur je pratique pas).

Pourquoi ne pas chercher une offre haute disponibilité "toute faite" avec un load balancer par ex ?
Il doit bien y avoir ce genre de chose dans l'univers pubic/private cloud d'OVH ou ailleurs.

Nul doute que d'autres sysadmin plus capé que moi comme @JeanR, @Sich ou @janus57 (désolé pour les "ping") pourront apporter plus de détails.

[janus57]

Bonjour,

Pour le coup ce serait bien de savoir à quoi sert le serveur car selon ce qui tourne dessus il peut y avoir plusieurs scénarios.

Et soit vous voulez de la HA (donc du synchrone pour moi).
Soit vous voulez un RPO/RTO bas (genre quelques heures).

Car après selon le besoin on pourrait pousser plus loin et avoir la solution de repli chez un autre prestataire que OVH pour avoir une vrai indepence vis-à-vis de OVH.
Vous avez évoqué Strasbourg mais il y a également eu les cas où OVH avait planté leur réseau.

Donc voilà tout est une question du besoin réel et du service qui tourne sur le serveur.

Cordialement, janus57

[Sich]

comme tu dis ce genre de solution peut vite devenir très complexe selon ce que l'on veut faire.
Et le coût peut exploser avec.

Idem je ne propose plus ce genre d'offres car le surcoût n'est généralement pas justifié (malgré un incendie chez ovh).

Comme dit @janus57 il faut savoir ce que fait le serveur.
Mais aussi ce que l'on veut.

Pour ce que j'en ai compris c'est + de la reprise sur incident rapide que de la HA.

Donc faudrait déjà bien définir le besoin (reprise sur incident, HA, load balancing) et les services derrière...

[JeanR]

Bonjour,

Plus on est proche du temps réel et avec de bonnes performances, plus le cout d'infrastructure va grossir.
- On peut faire une sauvegarde toutes les heures vers un autre serveur et prévoir une réplication d'ip manuelle
- On peut organiser un rsync avec incron par exemple toutes les 5 minutes ou à chaque modification d'un fichier
- On peut mettre en place un système de fichier répliqué en temps réel mais dont les performances sont liées au réseau et à la puissance des disques.

Les instances publiques cloud sont plutot prévu pour des besoins ponctuels lorsqu'un trafic augmente rapidement ou qu'une puissance de calcul sur du court terme est demandé.
Dans le cas d'un besoin constant, je conseille de vous diriger vers des serveurs dédiés qui permettront de gagner en prix/performance.
Avec 2 serveurs on commence à faire des choses intéressantes, avec 3 on organise mieux les évènements.

Bon courage
Captainadmin

[NicolasV64]

Bonjour à tous,

Je vous remercie déjà pour votre précieux retour.

Le serveur fait actuellement tourner une application web que j'ai développée en Laravel+VueJS (PHP/JS) et qui est utilisée par environ 100 à 300 utilisateurs. J'ai installé Virtualmin et configurer 2 serveurs virtuels (dev/prod) que je synchronise via Github.

Vu le nombre grossissant d'utilisateurs et les différentes modifications effectuées dans la configuration du serveur, je souhaiterai effectivement de la HA pour que (1) les utilisateurs puissent toujours accéder au service et que (2) si un des serveurs tombent je puisse copier celui toujours debout et que je ne doive pas refaire une configuration de 0 comme j'ai du faire suite à SBG.

Le prix mensuel de l'infrastructure nécessaire pour cela n'est pas un frein mais je souhaite mettre en place quelque chose qui colle au besoin et qui ne soit pas démesuré.

J'ai fait une demande de devis auprès d'OVH pour travailler avec un conseillé qui me guiderait dans cette mise en place afin que j'améliore mon niveau de ce côté-là mais si d'autres personnes sont prêtes à me proposer leurs services, n'hésitez pas à m'envoyer une offre.

[Sich]

Au niveau pro je pense que @JeanR doit pouvoir te proposer quelque chose.
Perso je ne fais pas.

Donc tu définis bien un besoin de HA, pas seulement de la reprise sur incident.

Il y a une base de données derrière ?

Typiquement pour la partie fichiers on va avoir un storage centralisé.
ça peut être un cluster CEPH maison ou alors une solution OVH : https://www.ovhcloud.com/fr/storage-solutions/

Pour la BDD il faut partir sur un cluster, donc 3 serveurs mini.
Et assurer la répartition des requêtes par les frontaux.

Ce qui peut être fait éventuellement c'est 3 serveurs frontaux, qui ont chacun leur SGBD.
Les frontaux "montent" les fichiers du stockage centralisé.
Et les bdd sont en cluster.

Donc si 1 serveur tombe, ça continue de tourner.

Mais là on va être sur une solution sur 1 DC...
Le multi DC risquerait d'effondrer les performances car la latence joue un rôle très important dans ce genre d'infra.

Faudrait voir le fonctionnement exact de l'appli pour pouvoir faire des propositions + simple éventuellement.

[NicolasV64]

Bonjour à tous,

Suite à une discussion en PM, la solution suivante m'a été proposée:

• 1 IP Failover sur laquelle je redirige tous mes DNS.
• 1 VPS de type Comfort (1 Gbit/s) qui sert de Load Balancer assignée à cette IP.
• 3 Dedicated Servers de type Advance-1 dans 3 DCs différents sur chacun desquels tourne Galera Cluster pour la réplication des DBs ainsi que GlusterFS pour la synchronisation des fichiers.

Si le VPS tombe, j'en commande un nouveau et je réinstalle le script du LB et je lui assigne l'IP. Si un des DS tombent, j'en commande un nouveau et reconfigure Galera + GlusterFS pour prendre en compte le nouveau serveur.

Que pensez-vous de cette architecture? Après quelques recherches de mon côté, j'ai relevé les questions suivantes:

• GlusterFS ne semble pas le plus performant pour la copie de beaucoup de fichiers de petite taille, hors j'utilise NPM et j'ai plusieurs packages installés, ce qui engendre un dossier node_modules avec beaucoup de petits fichiers. Cela sera-t-il un problème au niveau de la latence? Existe-t-il une alternative plus adaptée aux petits fichiers?
• Galera Cluster semble rencontrer certains problèmes lorsque les tables des bases de données n'ont pas de clés primaires, hors certaines de mes tables pivots n'en possède pas. Je pourrais en ajouter sans trop de difficultés mais savez-vous s'il existe une autre solution ne nécessitant pas de changer toutes les DBs?

Je suis conscient que cette solution n'est pas tout à fait de la HA car il y a un risque de panne si le VPS tombe. Mais si la reprise sur incident est aussi rapide et simple que commander un nouveau VPS et faire quelques configurations, cela me conviendrait.

Je vous remercie pour votre aide.

Cordialement,
Nicolas V.

[Sich]

2 choses :
- Au lieu de prendre un VPS qui fait load balancer je prendrai un load balancer (OVH / Cloudflare) pour faire le job.
- Monter un cluster galera sur 3 dcs différents demande selon moi des tests avant mise en prod, car pour valider une transaction elle doit être enregistrée sur les 3 noeuds...
Or vu qu'ils seront tous dans un DC != ça va impliquer des problèmes de latence. Peut être que ce ne sera pas trop invalidant, d'où le besoin de faire des tests.

[janus57]

Bonjour,

Que pensez-vous de cette architecture? Après quelques recherches de mon côté, j'ai relevé les questions suivantes:

si pour les 3DCs vous parlez de GRA/RBX/SBG, je dirais que c'est une mauvaise idée à cause de la latence RBX<->SBG & GRA<->SGB (au dessus de 10ms).

Je ne sais pas comment un cluster galera valide les données sur les nœuds, mais une latence de 10ms sur de l'écriture, cela peut très vite faire mal aux perfs.

Perfo je me limiterais à GRA/RBX qui déjà là à 2ms de latence ce qui commence à être limite (selon les docs applicatifs).

Cordialement, janus57

[Sich]

Le soucis d'une infra sur 2 DC c'est en cas de coupure de lien entre les 2 DC pour déterminer le "quorum majoritaire".
ça fait lgtps que je n'ai pas fais de cluster galera.
Mais normalement en cas de déco entre des noeuds, ceux qui peuvent se parler doivent représenter la majorité du cluster de base pour se dire "ok, on est majoritaire, c'est nous qui sommes les bons en ligne".
En cas de rupture de lien entre les 2 dcs, il y aura le même nbr de noeuds sur chaque DC, possible que les 2 clusters vont se considérer comme "master" et ça va être un beau bordel à la resynchro.

Sinon sur un tel cluster il faut que tous les noeuds aient validé une transaction (delete / update / insert) pour passer à la suite...
Avec 10ms et bcp d'opérations ça commence à piquer sévère sur les perfs...

[NicolasV64]

Bonjour à tous,

De ce que je lis, mettre en place un système HA sur plusieurs DCs est quelque chose de compliqué et cela risque de fortement impacter sur les performances. Si je reviens sur un système plus simple, je pourrais:

• Commander une IP.
• Prendre 2 DS Adv-1 dans 2 DCs différents, on défini un Master et un Slave.
• J'assigne l'IP commandée au DS Master et je configure une copie toutes les 5 minutes vers le Slave via RSync comme proposé par @JeanR.

Si le DS Master tombe, je redirige l'IP commandée vers le Slave qui devient Master et je le copie vers un nouveau Slave que je commande. Si le DS Slave tombe, je commande un nouveau et je copie le Master.

Du coup, on se retrouve plus avec une solution de reprise rapide sur incident car il y a juste à assigner l'IP configurée au niveau des DNS vers le serveur toujours debout et commander un nouveau 2ème DS. Dans ce cas là, il n'y a pas d'impact sur les performances vu qu'on dialogue toujours avec le Master qui toutes les 5 minutes poussent les modifications vers le Slave et devient sa copie conforme.

Est-ce un scénario cohérent? Merci encore pour vos interventions.

[JeanR]

Bonjour,

Si tu assignes une plage d'adresse ip dans un vrack et que tes serveurs sont aussi dans le vrack, tu peux automatiser la bascule de ton ip.
Ca marche bien avec de la virtualisation et une bascule automatique des environnements d'un serveur à l'autre.

La copie est cohérente mais attention à bien suivre car c'est au moment ou l'on bascule que l'on sait réellement si le slave fonctionne correctement.
Il faut superviser aussi cette partie.

Bonne journée