Comment exécuter WordPress sur 2 VM pour une haute disponibilité

10

Microsoft Azure exige que les applications utilisent deux instances sur plusieurs centres de données afin de respecter leur contrat de niveau de service "haute disponibilité" et de garantir que vos sites ne soient pas soumis à une maintenance de routine. Ils vous indiquent même quelles paires de centres de données ne feront jamais l'objet de maintenance en même temps.

C'est très bien, mais comment le feriez-vous facilement pour une application telle que WordPress avec une base de données MySQL sur le même ordinateur virtuel? Je ne suis pas étranger à l'équilibrage de charge entre deux ordinateurs virtuels, mais la configuration de la réplication de la base de données m'échappe. Nous ne voudrions pas de deux versions des données qui pourraient être désynchronisées. La réplication MySQL semble nécessiter une configuration maître-esclave qui ne parviendrait pas à 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!

    
posée Yaron 13.07.2015 - 21:35

1 réponse

9

La mauvaise nouvelle: le noyau de base open source de Wordpress émet pas mal de suppositions quant à son exécution sur un seul serveur (wp-content, téléchargements d’utilisateur et bibliothèque multimédia pour en nommer quelques-uns)

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

Fondamentalement, vous allez répondre aux préoccupations suivantes:

  • Équilibrage de la charge du trafic entre deux (ou plus) serveurs Web / applications Wordpress "front-end". Pas trop difficile, car Wordpress est principalement 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 adresses IP pour vos serveurs d’applications - 1 ensemble se connectera au sous-réseau routable via Internet (même si, espérons-le, il est protégé par un pare-feu non décrit ci-dessous) et les deux autres sur un sous-réseau DIFFERENT isolé de l'autre réseau et contient les instances du serveur de base de données, mais le schéma de base est semblable à celui-ci:
                     /-- (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(Public IP) 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 futures demandes sont routé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 Mise en cluster de sessions Zend Server , par exemple).

  • Gestion des connexions administrateur SI vous autorisez certains utilisateurs à se connecter au serveur principal pour gérer le contenu (comme ci-dessus).

  • Choisir un système de base de données également hautement disponible. Inutile d’avoir deux serveurs frontaux si votre base de données tombe en panne, tout le système est en panne. Vous devrez exploiter la réplication maître / esclave MySQL via ClearDB ou modifier WordPress via un plugin pour exploiter SQL Server afin que vous puissiez utiliser ses systèmes de clustering natifs . Cela signifie que vous aurez besoin d'au moins 4 VM si vous souhaitez gérer vous-même la couche de base de données (2 x applications et 2 x bases de données). 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 garantir un basculement fiable & Pour protéger la sécurité du système, un troisième réseau est utilisé pour connecter les deux nœuds de la base de données via un canal privé séparé des autres réseaux de communication utilisés par les serveurs d'applications pour communiquer avec la base de données & les serveurs d'applications utilisent pour communiquer avec le monde extérieur.

  • Activation du regroupement de connexions pour optimiser les performances et la fiabilité des connexions à la base de données de votre serveur d'applications.

  • Exploiter un plug-in de mise en cache tel que W3 Total Cache ou Super Cache pour réduire la charge sur les serveurs frontaux.

Les guides suivants expliquent comment vous pouvez relever chacun des défis ci-dessus. Il existe plusieurs manières de gérer chacune d'elles dans Azure. Vous devez donc décider comment vous voulez attaquer chaque défi, puis gérer les contraintes que chacun de ces choix impose lorsque vous travaillez dans la pile.

réponse donnée Bryan 'BJ' Hoffpauir Jr. 20.07.2015 - 20:23

Lire d'autres questions sur les étiquettes