Bonjour,
J’ai un projet de fin d’année dans lequel je dois assurer la haute disponibilité d’un serveur web Wordpress (BDD: MariaDB) avec un Debian.
Le serveur Wordpress est bien fonctionnel.
Je sais qu’il faut utiliser Heartbeat mais il faut sans doute utiliser des outils supplémentaires.
Pourriez-vous me dire lesquels utiliser et dans quel ordre ?
Bonjour,
regarde du coté de pacemaker, c’est fait pour ça et il gère tout.
Seule règle, ton serveur apache s’arrête et démarre via la commande pcs, mais surtout pas avec systemd ou quoique ce soit d’autre.
Tu as deux serveurs, chacun avec wordpress, apache et mariadb.
Il te suffit d’assurer une synchronisation des deux serveurs (une synchro des données mariadb et idem coté apache/wordpress.
Concernant wordpress je ne connais pas bien, je n’ai jamais aimé.
Un des points interessant peut être d’avoir le stockage des données sur un stockage partagé;
Merci pour ta réponse @Zargos, je vais regarder tout ça. Si j’ai un soucis ou une question, puis-je compter sur toi 
?
du mieux que je pourrais 
à minima un deuxième serveur, sinon ta haute disponibilité sera plus que virtuelle ^^
@Clochette 2 serveurs debian (un principale et un secondaire) les deux ayant la même config à quelques petites choses prêts.
SMB4 ou NFS ou un NAS avec présentation de LUN.
Dans ton cas, cherche du coté de SMB, NFS déjà.
Attention le système utilise un disque local. Seules les partitions de données sont partagées.
@Zargos donc il faut configurer MariaDB du coté serveur principal (Debian N°1) et du coté serveur secondaire (Debian N°2) pour que leurs données soit automatiquement stockées dans un fichier partagé.
J’ai tout bon pour l’instant ?
Te casse pas la tête à ce point, tu peux mettre en place une synchronisation de ta base donnée principale sur l’autre , et avoir un script rsync pour maintenir ton dossier web.
Pour ce qui est de gérer la bascule tu as plusieurs choix possible avec corosync/pacemaker, Heartbeat ou via un loadbalancer externe.
Le plus simple à mon sens est avec heartbeat.
Si maintenant tu recherche quelque chose de complexe et efficient en multimaster là les choix sont à revoir.
D’accord ça marche, merci
Toute fois attention à ce que l’on apelle le splitbrain, lorsque tu effectue une bascule sur le serveur qui servira d’esclave, le jour ou tu décide de rebasculer il te faudra exporter toute modification bdd/donnée web, vers le serveur principale et t’assurer que tout soit bien remis en ordre côté synchronisation.
Le splitbrain arrive lorsque tu commence à écrire sur le serveur 1, tu bascule suit à test/incident sur le sveur 2 sur lequel tu écrits à la suite, puis sans aucune vérificatuion tu recommence à écrire sur le serveur 1 sans avoir importé les données qui n’y sont pas.
Les synchro sont soit unidirectionnelle (les plus simple à mettre ne place) soit bidirectionnelle (casse tête à concevoir et mettre ne place).
Généralement pour le deuxième cas on passe sur de la gestion de cluster avec à minima 3 serveurs et un gros avantages à utilisaer du stockage partagé via un SAN.
Pour maintenir deux serveurs web dans un même lieux de fonctionnement identique pour la partie web (donnée) on peu s’appuyer sur du DRDB mais c’est complexe à mettre en place et audelà de 2 serveurs il est plus intéressent de paser sur du SAN.
Un cluster de base de données géré avec une réplication directe entre les deux bases de données ne marchera pas, car chaque base de donnée utilisera des ID internes différents.
Il faut utiliser un système de type DRBD avec, par exemple, Pacemaker gerer le cluster.
Pour DRBD:
DRBD (Distributed Replicated Block Device) est une solution de réplication de périphériques blocs via le réseau. Un périphérique bloc peut être une partition, un périphérique LVM, RAID logiciel, etc. La réplication se fait en continu et peut être synchrone ou asynchrone. Le module noyau est intégré désormais en standard au noyau depuis la version 2.6.33.
En fait il faut considérer DRBD come un RAID 1 à travers le réseau. Attention les performances de la réplication seront directement impacté par les performances du dit réseau.
mais bien sûr, Wordpress initie sa connexion sur une ip il a juste besoin de ça, ce type de réplication j’en utilise et maintient depuis un paquet d’année.
Quelle horreur à gérer du pacemaker avec du DRDB.
Non, Pacemaker ne gère que apache et mariadb, rien d 'autre.
la partie stockage est transparente et est gérée par DRBD.
Et ce n’est pas si difficile à configurer.
Oui mais ce n’est pas du cluster car ça ne fait que répartir la charge sur l’IP. Et ce n’est pas apache qui peut générer des erreurs mais la base de donnée.
J’aurai du rie écrire ET à la place avec du …
J’en ia passé du temps à gérer du DRDB et du Glusterfs, j’en ai passé du temps à les soutenir durant de vive interactions avec d’autre sysadmin … après j’ai fini utilisé d’autre outils et simplement revenu à çà, principes plus simples lorsque les autres ne sont pas nécessaires.
après je m’en lave les mains si tu veux le guider dans ton raisonnement fais comme tu le sent.
Fais moi rire et prouve moi par A plus B que tu ne peux pas faire une simple réplication de base de donnée mysql couplé avec un synchronisation des fichiers web ?
Ce n’est pas ce que j’ai dit
J’ai dit que sur un cluster, si tu ne clusterises pas les données de la base en faisant simplement une réplication de base, tu peux t’exposer à des risques en particulier liés à la gestion des transactions, mais aussi des ID internes des bases.
J’ai eu comme client le système de tri de la poste belge par exemple, qui du fait de la volatilité de la donnée et des nécessités de temps de réponse ne pouvait pas passer par une simple réplication de bases de données car des incohérences se créaient, et lors d’un incident sur la partie de prod il fallait que la bascule vers le second membre du cluster dispose des même données dans des délais très cours (de l’ordre des 10ms et moins). La réplication utilisée nécessitait un lien réseau avec un temps de latence de moins de 2ms avec une moyenne à 1ms.
Pour ce qui est du DRBD je ne saurais dire aussi bien que toi car je n’ai pas ton expérience sur cette techno. J’ai plutôt utilisé de la réplication de datastore à datastore ou des technologie de type FOM.
Donc pour du Wordpress on n’est bien d’accord, on n’en reviens à ce que j’ai proposé de rester au plus simple pour ce projet sur une base de deux serveurs avec un simple Wordpress à rendre hautement disponible (hautement disponible du pauvre mais fonctionnel).
On n’est aussi d’accord que mettre ne place du DRDB pour un simple Wordpress est tout aussi inutilement complexe par rapport à une simple réplication à coup de rsync avec une cron et un déclenchement manuel lors de maintenance sur le Wordpress en lui même.
PS : Attention à ne pas synchroniser les fichiers gérant la connexion à la base l’ip ne sera pas la même, mais ça reste juste le fichier de configuration wp-config.php.
Ceci dit ce que j’ai vu de DRBD n’est pas très complexe à configurer
mais je ne choisirais pas rsync pour faire de la synchro bi-directionnelle.
@Zargos @Clochette je vais regarder tout ça. j’ai eu des soucis avec mes VMs donc je refais ma config et je regarde tout ça .