Industrialisez vos bases de données MySQL avec PXC et ClusterControl
De nombreux outils en entreprise sont conçus pour fonctionner avec les bases de données MySQL : applications PHP, Java, sites web, e-commerce, CMS et CRM open source, etc. Certaines de ces applications sont critiques dans votre système d’information et leur panne pourrait pénaliser lourdement votre activité.
Il est courant de mettre en place de solides clusters Oracle ou Microsoft SQL Server qui sont accompagnés de puissantes interfaces de gestion, de déploiement et de monitoring.
Alors qu’en est-il avec MySQL ?
Nous allons vous présenter dans cet article les outils pour exploiter de puissants clusters MySQL actif/actif, multi-maîtres et tolérants aux pannes avec Percona XtraDB Cluster ou PXC (https://www.percona.com/software/mysql-database/percona-xtradb-cluster), l’implémentation du système open source Galera Cluster (http://galeracluster.com) et comment industrialiser la gestion, l’automatisation, le déploiement et le monitoring avec la solution commerciale ClusterControl (http://severalnines.com/product/clustercontrol).
Qu’est-ce que Percona XtraDB Cluster (Galera Cluster) ?
Percona XtraDB Cluster est un système de réplication de bases de données synchrones et multi-maîtres. Il permet à un client MySQL standard de lire et d’écrire sur n’importe quel nœud du cluster. Son utilisation est donc transparente pour les applications. Il est également possible de tolérer une panne sur n’importe quel nœud sans interruption de service et sans nécessité d’appliquer de procédure de failover manuelle complexe : le cluster est en mesure de se reconstruire seul et automatiquement.
Comment se fait la réplication des données entre les nœuds ?
Un cluster Galera consiste en un nombre impair de serveurs MySQL (ou MariaDB, Percona server, etc.) ; le cluster nécessite trois nœuds au minimum pour assurer le quorum (https://fr.wikipedia.org/wiki/Quorum) .
La réplication est basée sur la certification des écritures : un write-set ne contient pas uniquement les enregistrements à répliquer mais inclut également toutes les informations sur les locks qui ont été gardées par la base de données pendant la transaction. Chaque transaction est considérée committée après que chaque nœud du cluster a certifié l’avoir appliquée. La synchronisation chiffrée avec SSL est tout à fait possible et supportée.
Architecture de la solution
Comment fonctionne la tolérance aux pannes ?
Les connexions MySQL des applications se font vers un load-balancer TCP (Haproxy, F5, Cisco, etc.). On utilise généralement deux load-balancers pouvant partager automatiquement une virtual-IP afin d’assurer la haute disponibilité et ne pas créer un nouveau SPOF (https://fr.wikipedia.org/wiki/Point_individuel_de_d%C3%A9faillance). Le load-balancer répartit ensuite les différentes connexions MySQL (lecture ou écriture) vers les nœuds du cluster. Cette répartition peut se faire classiquement avec round-robin ou d’autres algorithmes de répartition.
La détection de panne des nœuds par le load-balancer est faite au travers d’un check HTTP sur un port dédié présenté par chaque nœud et qui s’assure que ce dernier est en bonne santé, qu’il est synchronisé avec le cluster et qu’il n’est pas read-only.
En cas de défaillance d’un nœud, le load-balancer pourra donc automatiquement le sortir du pool de load-balancing et ainsi assurer la continuité de fonctionnement de l’application.
Après une panne, comment remonter le nœud défaillant dans le cluster ?
Là aussi tout est automatique. Lorsque le nœud sera à nouveau visible par les deux autres nœuds restants, ces derniers auront déterminé que le troisième nœud n’est plus aussi avancé (grâce à leur supériorité numérique, décidée par le quorum). Un transfert de données (incrémental si coupure temporaire ou complet si le nœud a été réinstallé ) va donc automatiquement être réalisé vers ce nœud afin de remettre ses données au même niveau que les nœuds restants du cluster. Pendant toute cette opération, le nœud est considéré comme non synchronisé et ne fait donc pas partie du pool de load-balancing. Après re-synchronisation, le load-balancer ré-ajoute automatiquement le nœud MySQL à son pool de load-balancing : le cluster est alors réparé.
Un cluster PXC est-il moins performant qu’un nœud MySQL seul ?
La réplication des écritures est faite de manière synchrone, une transaction n’est validée qu’après écriture sur chacun des nœuds du cluster. Un cluster PXC est donc aussi rapide en écriture que le plus lent de ses nœuds. Si les trois nœuds sont correctement dimensionnés, la vitesse en écriture est environ 10% plus lente qu’un serveur MySQL standalone, ce qui représente d’excellentes performances pour ce type de système synchrone.
La lecture, quant à elle, est aussi rapide que sur un serveur MySQL standalone car elle n’est opérée que sur un seul nœud.
Est-ce que cela fonctionne avec de la virtualisation ?
Oui tout à fait. Nous avons déployé avec succès de nombreux clusters en production sur des environnements VMware. Nous utilisons également KVM pour nos environnements d’essai. La détection de panne est assez sensible, et nous recommandons d’utiliser PXC sur un environnement virtualisé très performant, à défaut d’utiliser des machines physiques.
Est-il possible de répartir les nœuds sur plusieurs sites physiques ?
C’est possible et même recommandé, à condition d’avoir une solide connexion entre les sites. La répartition classique est d’avoir deux nœuds sur un site et le troisième sur l’autre site.
Est-ce 100% compatible avec une application existante basée sur MySQL classique ?
La connexion à des nœuds PXC via l’infrastructure de load-balancers est totalement transparente pour les applications et/ou clients MySQL standards. Il y a tout de même quelques limitations à prendre en compte lors de la phase d’analyse préliminaire :
- Les clés primaires générées automatiquement (auto-increment) ne sont plus successives afin d’éviter les collisions
- La réplication MyISAM est encore au stade expérimental sur PXC 5.6
- Les requêtes MySQL de lock (lock table, get_lock(), etc.) ne sont pas supportées
- Plus d’informations ici : https://www.percona.com/doc/percona-xtradb-cluster/5.6/limitation.html
Quels sont les avantages et fonctionnalités de Percona XtraDB Cluster ?
- Vrai multi-master : lectures et écritures sur n’importe quel nœud à n’importe quel moment
- Réplication synchrone : pas de lag de réplication sur un nœud esclave, donc pas de perte de données en cas de crash d’un nœud
- Couplage fort : tous les nœuds ont exactement les mêmes données, aucune divergence de données n’est possible
- Multi-threaded slave : architecture multi-thread pour de meilleures performances et pour répondre à tout type de charge
- Failover automatique : pas d’opération manuelle pour récupérer un nœud, pas d’utilisation de VIP
- Hot standby : pas de downtime en cas de perte d’un nœud
- Provisioning de nœud automatique : il n’est pas nécessaire de transférer manuellement la base de données sur un nouveau nœud
- Transparent pour les applications : pas de modification nécessaire des applications
- Pas nécessaire de séparer les écritures et les lectures
- Les accès aux nœuds sont load-balancés
Qu’est-ce que ClusterControl ?
Percona XtraDB Cluster n’est pas « livré » avec une interface de gestion permettant d’assister l’administrateur dans ses tâches d’administration classique : monitoring du cluster, gestion des nœuds MySQL mais aussi des load-balancers, etc. Pour cela nous recommandons la solution commerciale ClusterControl de la société Severalnines : http://www.severalnines.com/product/clustercontrol (Clever Net Systems est partenaire et revendeur officiel en Suisse).
Quelles sont les fonctionnalités de ClusterControl ?
Les fonctionnalités de ClusterControl sont nombreuses :
- Déploiement automatisé de clusters et de nœuds
- Déploiement de load-balancers HAProxy
- Management de nœuds : start, stop, maintenance, ajout de nœuds, etc.
- Monitoring : nœuds, base de données, slow queries, requêtes, performances, plugins externes (Nagios, Zabbix, Pagerduty, etc.)
- Operations reporting & analytics
- Réparation et récupération de cluster
- Gestion de la configuration centralisée (my.cnf, etc.)
- Alarmes et notifications e-mails
- Gestion des backups : planification, backups full, incrémentaux, etc.
- Gestion des utilisateurs, schémas, etc.
- Gestion sécurisée : ACL, LDAP, SSL
- Support : SLA 24*7*365, Remote Login, etc.
Il est possible d’utiliser ClusterControl avec des serveurs MySQL standalone ou pour gérer des clusters actif/passif de type master/slave.
Que se passe-t-il si ClusterControl tombe en panne ? Est-ce un SPOF ?
ClusterControl n’est pas un SPOF, le cluster est totalement autonome, même en cas de panne de ClusterControl.
Quelle est l’expérience de Clever Net Systems sur ces technologies ?
Nous avons eu l’occasion ces dernières années de procéder au déploiement en production d’une dizaine de clusters PXC dans de prestigieuses sociétés de Suisse romande afin d’assurer la haute disponibilité et la haute performance d’applications basées sur MySQL. Notre retour d’expérience est excellent, et cette solution est considérée comme mature et efficace. Alors pour toute demande d’informations, n’hésitez-pas, contactez-nous !
Pour découvrir nos articles de blog techniques à propos de PXC et ClusterControl, c’est ici :
– https://www.clevernetsystems.com/troubleshooting-a-clustercontrol-mysql-pxc-cluster/
– https://www.clevernetsystems.com/troubleshooting-a-clustercontrol-mysql-pxc-cluster-part-2/
– https://www.clevernetsystems.com/password-change-in-clustercontrol/
– https://www.clevernetsystems.com/upgrading-percona-xtradb-cluster-to-v5-6/
