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!
Réponses:
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:
/ - (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.
la source