Toute entreprise rentable nécessite une haute disponibilité. Les sites Web et les blogs ne sont pas différents, car même les petites entreprises et les particuliers exigent que leurs sites restent en ligne pour conserver leur réputation.
WordPress est, de loin, le CMS le plus populaire au monde, alimentant des millions de sites Web, des plus petits aux plus grands. Mais comment pouvez-vous vous assurer que votre site Web reste en ligne. Plus précisément, comment puis-je m'assurer que l'indisponibilité de ma base de données n'aura pas d'impact sur mon site Web ?
Dans cet article de blog, nous montrerons comment réaliser le basculement de votre site Web WordPress à l'aide de ClusterControl.
La configuration que nous utiliserons pour ce blog utilisera Percona Server 5.7. Nous aurons un autre hébergeur qui contiendra l'application Apache et Wordpress. Nous n'aborderons pas la partie haute disponibilité de l'application, mais c'est aussi quelque chose que vous voulez vous assurer d'avoir. Nous utiliserons ClusterControl pour gérer les bases de données afin d'assurer la disponibilité et nous utiliserons un troisième hôte pour installer et configurer ClusterControl lui-même.
En supposant que le ClusterControl est opérationnel, nous devrons y importer notre base de données existante.
Importation d'un cluster de base de données avec ClusterControl
Accédez à l'option Importer un serveur/base de données existant dans l'assistant de déploiement.
Nous devons configurer la connectivité SSH car c'est une exigence pour que ClusterControl être capable de gérer les nœuds.
Nous devons maintenant définir quelques détails sur le fournisseur, la version, l'utilisateur root l'accès, le nœud lui-même et si nous voulons que ClusterControl gère la récupération automatique pour nous ou non. C'est tout, une fois le travail réussi, un cluster de la liste vous sera présenté.
Pour configurer l'environnement hautement disponible, nous devons exécuter quelques d'actes. Notre environnement sera composé de...
- Paire maître - esclave
- Deux instances ProxySQL pour le fractionnement en lecture/écriture et la détection de la topologie
- Deux instances Keepalived pour la gestion des adresses IP virtuelles
L'idée est simple :nous allons déployer l'esclave sur notre maître afin d'avoir une deuxième instance vers laquelle basculer en cas de défaillance du maître. ClusterControl sera responsable de la détection des pannes et assurera la promotion de l'esclave en cas d'indisponibilité du maître. ProxySQL gardera la trace de la topologie de réplication et redirigera le trafic vers le bon nœud - les écritures seront envoyées au maître, quel que soit le nœud dans lequel il se trouve, les lectures peuvent être envoyées uniquement au maître ou réparties entre le maître et les esclaves . Enfin, Keepalived sera colocalisé avec ProxySQL et fournira un VIP auquel l'application pourra se connecter. Ce VIP sera toujours attribué à l'une des instances ProxySQL et Keepalived le déplacera vers la seconde, en cas de défaillance du nœud ProxySQL "principal".
Ayant dit tout cela, configurons cela en utilisant ClusterControl. Tout cela peut être fait en quelques clics. Nous allons commencer par ajouter l'esclave.
Ajout d'un esclave de base de données avec ClusterControl
Nous commençons par choisir la tâche "Ajouter un esclave de réplication". Ensuite, on nous demande de remplir un formulaire :
Nous devons choisir le maître (dans notre cas, nous n'avons pas vraiment ont de nombreuses options), nous devons transmettre l'adresse IP ou le nom d'hôte du nouvel esclave. Si nous avions des sauvegardes précédemment créées, nous pourrions en utiliser une pour provisionner l'esclave. Dans notre cas, ce n'est pas disponible et ClusterControl provisionnera l'esclave directement à partir du maître. C'est tout, le travail démarre et ClusterControl effectue les actions requises. Vous pouvez surveiller la progression dans l'onglet Activité.
Enfin, une fois la tâche terminée avec succès, l'esclave doit être visible sur le liste des clusters.
Nous allons maintenant procéder à la configuration des instances ProxySQL. Dans notre cas, l'environnement est minimal donc, pour simplifier les choses, nous allons localiser ProxySQL sur l'un des nœuds de la base de données. Ce n'est cependant pas la meilleure option dans un environnement de production réel. Idéalement, ProxySQL serait soit situé sur un nœud séparé, soit colocalisé avec les autres hôtes d'application.
L'endroit pour commencer le travail est Gérer -> Loadbalancers.
Ici, vous devez choisir où le ProxySQL doit être installé, passer les informations d'identification administratives et ajoutez un utilisateur de base de données. Dans notre cas, nous utiliserons notre utilisateur existant car notre application WordPress l'utilise déjà pour se connecter à la base de données. Nous devons ensuite choisir les nœuds à utiliser dans ProxySQL (nous voulons à la fois le maître et l'esclave ici) et faire savoir à ClusterControl si nous utilisons ou non des transactions explicites. Ce n'est pas vraiment pertinent dans notre cas, car nous allons reconfigurer ProxySQL une fois qu'il sera déployé. Lorsque cette option est activée, le fractionnement en lecture/écriture ne sera pas activé. Sinon, ClusterControl configurera ProxySQL pour le fractionnement lecture/écriture. Dans notre configuration minimale, nous devrions sérieusement réfléchir si nous voulons que la séparation lecture/écriture se produise. Analysons cela.
Les avantages et les inconvénients de lire/écrire Spit dans ProxySQL
Le principal avantage de l'utilisation de la séparation lecture/écriture est que tout le trafic SELECT sera réparti entre le maître et l'esclave. Cela signifie que la charge sur les nœuds sera inférieure et que le temps de réponse devrait également être inférieur. Cela semble bien, mais gardez à l'esprit qu'en cas de défaillance d'un nœud, l'autre nœud devra être en mesure de gérer tout le trafic. Il ne sert à rien de mettre en place un basculement automatisé si la perte d'un nœud signifie que le deuxième nœud sera surchargé et, de facto, indisponible également.
Il peut être judicieux de répartir la charge si vous avez plusieurs esclaves - perdre un nœud sur cinq a moins d'impact que d'en perdre un sur deux. Peu importe ce que vous décidez, vous pouvez facilement modifier le comportement en accédant au nœud ProxySQL et en cliquant sur l'onglet Règles.
Assurez-vous de regarder la règle 200 (celle qui intercepte toutes les instructions SELECT ). Sur la capture d'écran ci-dessous, vous pouvez voir que le groupe d'hôtes de destination est 20, ce qui signifie que tous les nœuds du cluster - le fractionnement en lecture/écriture et la montée en charge sont activés. Nous pouvons facilement désactiver cela en modifiant cette règle et en changeant le groupe d'hôtes de destination à 10 (celui qui contient le maître).
Si vous souhaitez activer la séparation lecture/écriture, vous pouvez facilement faites-le en modifiant à nouveau cette règle de requête et en redéfinissant le groupe d'hôtes de destination sur 20.
Maintenant, déployons le deuxième ProxySQL.
Pour éviter de passer à nouveau toutes les options de configuration, nous pouvons utiliser le "Importer la configuration " et choisissez notre ProxySQL existant comme source.
Lorsque ce travail sera terminé, nous devons encore effectuer la dernière étape de configuration de notre environnement. Nous devons déployer Keepalived sur les instances ProxySQL.
Déployer Keepalived sur les instances ProxySQL
Ici, nous avons choisi ProxySQL comme type d'équilibreur de charge, passé les deux instances ProxySQL pour Keepalived à installer sur et nous avons tapé notre interface VIP et réseau.
Comme vous pouvez le voir, nous avons maintenant toute la configuration en place et prête. Nous avons un VIP de 10.0.0.111 qui est attribué à l'une des instances ProxySQL. Les instances ProxySQL redirigeront notre trafic vers les nœuds MySQL back-end appropriés et ClusterControl gardera un œil sur l'environnement en effectuant un basculement si nécessaire. La dernière action que nous devons entreprendre est de reconfigurer Wordpress pour utiliser l'adresse IP virtuelle pour se connecter à la base de données.
Pour ce faire, nous devons éditer wp-config.php et remplacer la variable DB_HOST par notre adresse IP virtuelle :
/** MySQL hostname */
define( 'DB_HOST', '10.0.0.111' );Conclusion
A partir de maintenant, Wordpress se connectera à la base de données en utilisant VIP et ProxySQL. En cas de défaillance du nœud maître, ClusterControl effectuera le basculement.
Comme vous pouvez le voir, un nouveau maître a été élu et ProxySQL pointe également vers nouveau maître dans le groupe d'hôtes 10.
Nous espérons que cet article de blog vous donnera une idée de la façon de concevoir un environnement de base de données hautement disponible pour un site Web Wordpress et de la façon dont ClusterControl peut être utilisé pour déployer tous ses éléments.
