Comment exécuter WordPress sur 2 machines virtuelles pour une haute disponibilité

Microsoft Azure exige que les applications utilisent deux instances dans plusieurs centres de données afin d'atteindre leur SLA de «haute disponibilité» et de garantir que vos sites ne s'arrêtent pas pour une maintenance de routine. Ils vous indiquent même quelles paires de centres de données ne feront jamais l'objet d'une maintenance en même temps.

C'est bien beau, mais comment le feriez-vous facilement dans la pratique pour une application comme WordPress avec une base de données MySQL sur la même machine virtuelle? Je ne suis pas étranger à l'équilibrage de charge entre deux machines virtuelles, mais la configuration de réplication de la base de données m'échappe. Nous ne voudrions pas que deux versions des données soient désynchronisées. La réplication MySQL semble nécessiter une configuration maître-esclave qui échouerait à synchroniser les modifications apportées à la base de données maître si un utilisateur atterrissait sur l'instance esclave.

Suis-je en train de mal comprendre ce concept? Toute aide est très appréciée!

— Yaron
source

Pourquoi hébergeriez-vous WordPress sur Azure? Il existe un hébergement meilleur et moins cher pour WordPress. Océan numérique par exemple.

— Alexus

Alexus, ce n'est pas vraiment pertinent ici, mais nous avons une pile assez grande répartie sur l'infrastructure d'Azure, dont WordPress n'est qu'un composant. Azure est une plateforme fantastique et nous en sommes très satisfaits.

— Yaron

je t'ai eu. Vous devez faire ce que vous avez à faire :) J'aime aussi Azure pour la plupart de mes trucs .NET, mais j'ai toujours hébergé les sites WP séparément.

— Alexus

Yaron, avez-vous trouvé la réponse ci-dessous utile? Il a reçu 3 votes positifs jusqu'à présent, je voulais juste vérifier si vous avez trouvé un concept important manquant afin que je puisse le mettre à jour pour l'adresser à votre cas d'utilisation particulier.

— Bryan 'BJ' Hoffpauir Jr.

Merci beaucoup pour la réponse complète @ Bryan'BJ'Hoffpauir et désolé je n'ai pas eu le temps d'essayer de suivre vos instructions pour voir si elles fonctionnent avec notre implémentation. Je marque la réponse comme correcte et je communiquerai à nouveau si je rencontre des problèmes. Merci encore!!

— Yaron

La mauvaise nouvelle: la base open source de Wordpress fait quelques hypothèses sur l'exécution sur un seul serveur (contenu wp, téléchargements d'utilisateurs et bibliothèque multimédia pour n'en nommer que quelques-uns)

La bonne nouvelle: presque tous les fournisseurs de cloud (y compris Azure) ont des abstractions qui vous permettent de contourner ces limitations de conception.

Fondamentalement, vous répondrez aux préoccupations suivantes:

Équilibrage de la charge du trafic entre deux (ou plusieurs) serveurs Web / d'applications Wordpress «frontaux». Pas trop difficile, car Wordpress est surtout apatride, sauf si vous laissez les utilisateurs se connecter aux sites. Cela se fait via une combinaison de DNS et d'équilibreurs de charge. Vous aurez besoin de la prise en charge de 2 IP pour vos serveurs d'applications - 1 ensemble se connectera au sous-réseau qui est routable via Internet (bien que nous espérons qu'il soit protégé par un pare-feu non décrit ci-dessous) et les deux autres seront sur un sous-réseau différent qui est isolé de l'autre réseau et contient les instances du serveur de base de données, mais le plan de base est le même:

                     / - (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(IP publique) wp.domain.com          
                     \ - (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)

Gestion des sessions SI vous laissez les utilisateurs se connecter aux sites. Si tel est le cas, vous devrez vous assurer, lors de leur connexion au serveur 1, que toutes leurs demandes futures seront acheminées vers ce serveur (sessions persistantes) ou que le serveur auquel elles accèdent n'a pas d'importance car les sessions sont gérées via un autre mécanisme. (via Zend Server Session Clustering , par exemple).
Gestion des connexions administrateur SI vous laissez certains utilisateurs se connecter au back-end pour gérer le contenu (similaire à ci-dessus).
Choisir un système DB qui est également hautement disponible. Inutile d'avoir deux serveurs frontaux si le crash de votre base de données entraîne l'arrêt complet du système. Vous devrez tirer parti de la réplication MySQL maître / esclave via ClearDB ou modifier WordPress via un plugin pour tirer parti de SQL Server afin que vous puissiez utiliser ses systèmes de cluster natifs . Cela signifie que vous avez besoin d'au moins 4 VM si vous souhaitez gérer vous-même la couche DB (2 x App & 2 x DB). Voici à quoi cela pourrait ressembler:

               / - wp1.domain.com (10.0.1.1) \ --- / (10.0.1.3) db1.domain.com (10.0.2.3) \
         wp.domain.com X |           
               \ - wp2.domain.com (10.0.1.2) / --- \ (10.0.1.4) db2.domain.com (10.0.2.3) /

REMARQUE - pour assurer un basculement fiable et protéger la sécurité du système, un TROISIÈME sous-réseau réseau est généralement utilisé pour connecter les deux nœuds de base de données l'un à l'autre via un canal privé séparé des autres réseaux de communication que les serveurs d'applications utilisent pour communiquer avec la base de données et les serveurs d'applications utilisent pour communiquer avec le monde extérieur.
Activation du pool de connexions pour maximiser les performances et la fiabilité des connexions à la base de données de votre serveur d'applications.
Tirer parti d'un plug-in de mise en cache comme W3 Total Cache ou Super Cache pour minimiser la charge sur les serveurs frontaux.

Les guides suivants offrent des détails sur la façon dont vous pouvez relever chacun des défis ci-dessus. Il y a plusieurs façons de gérer chacun dans Azure, donc c'est à vous de décider comment vous voulez attaquer chaque défi, puis de gérer les contraintes imposées par chacun de ces choix lorsque vous montez et descendez la pile.

— Bryan 'BJ' Hoffpauir Jr.
source