web-dev-qa-db-fra.com

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

Microsoft Azure exige que les applications utilisent deux instances sur plusieurs centres de données pour atteindre leur "haute disponibilité" SLA et vous assurer que vos sites ne sont pas en panne pour la 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 feriez-vous cela facilement en pratique pour une application comme WordPress avec une base de données MySQL sur le même ordinateur virtuel? Je ne suis pas étranger à l'équilibrage de la 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!

mysqlhostingamazoncloudscale
11
Yaron

The Bad News: La base de base open source de Wordpress émet pas mal de suppositions sur son exécution sur un seul serveur (wp-content, téléchargements d'utilisateurs 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 serveurs Web/applications Wordpress "front-end" (ou plus). 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 se trouveront 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) 
 (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 la 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 Zend Server Session Clustering , par exemple).

  • Gestion des connexions administrateur SI vous laissez certains utilisateurs se connecter au système dorsal pour gérer le contenu (comme ci-dessus).

  • Choisir un système de base de données ALSO 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 plug-in 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 ordinateurs virtuels si vous en avez besoin. 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)/

  • NOTE- Pour assurer un basculement fiable et protéger la sécurité du système, un sous-réseau réseau THIRD est généralement utilisé pour connecter les deux nœuds de base de données 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 que 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 de base de données de votre serveur d'applications.

  • Exploiter un plugin Caching tel que W3 Total Cache ou Super Cache pour réduire la charge sur les serveurs frontaux.

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

10
Bryan 'BJ' Hoffpauir Jr.