Nous avons récemment écrit plusieurs blogs sur la manière dont différents fournisseurs de cloud gèrent le basculement de base de données. Nous avons comparé les performances de basculement dans Amazon Aurora, Amazon RDS et ClusterControl, testé le comportement de basculement dans Amazon RDS, ainsi que sur Google Cloud Platform. Bien que ces services offrent d'excellentes options en matière de basculement, ils peuvent ne pas convenir à toutes les applications.
Dans cet article de blog, nous passerons un peu de temps à analyser les avantages et les inconvénients de l'utilisation des solutions DBaaS par rapport à la conception manuelle d'un environnement ou à l'aide d'une plate-forme de gestion de base de données, comme ClusterControl.
Mise en œuvre de bases de données à haute disponibilité avec des solutions gérées
La principale raison d'utiliser les solutions existantes est la facilité d'utilisation. Vous pouvez déployer une solution hautement disponible avec basculement automatisé en quelques clics seulement. Il n'est pas nécessaire de combiner différents outils, de gérer les bases de données à la main, de déployer des outils, d'écrire des scripts, de concevoir la surveillance ou toute autre opération de gestion de base de données. Tout est déjà en place. Cela peut réduire considérablement la courbe d'apprentissage et nécessite moins d'expérience pour mettre en place un environnement hautement disponible pour les bases de données ; permettant pratiquement à tout le monde de déployer de telles configurations.
Dans la plupart des cas avec ces solutions, le processus de basculement est exécuté dans un délai raisonnable. Cela peut être extrêmement rapide comme avec Amazon Aurora ou un peu plus lent comme avec les nœuds SQL de Google Cloud Platform. Pour la majorité des cas, ces types de résultats sont acceptables.
L'essentiel. Si vous pouvez accepter 30 à 60 secondes d'indisponibilité, vous devriez pouvoir utiliser n'importe quelle plate-forme DBaaS.
Les inconvénients de l'utilisation d'une solution gérée pour la haute disponibilité
Bien que les solutions DBaaS soient simples à utiliser, elles présentent également de sérieux inconvénients. Pour commencer, il y a toujours un élément de verrouillage du fournisseur à prendre en compte. Une fois que vous avez déployé un cluster dans Amazon Web Services, il est assez difficile de migrer hors de ce fournisseur. Il n'existe pas de méthode simple pour télécharger l'ensemble de données complet via une sauvegarde physique. Avec la plupart des fournisseurs, seules les sauvegardes logiques exécutées manuellement sont disponibles. Bien sûr, il existe toujours des options pour y parvenir, mais il s'agit généralement d'un processus complexe et chronophage, qui peut malgré tout nécessiter un certain temps d'arrêt.
L'utilisation d'un fournisseur comme Amazon RDS comporte également des limitations. Certaines actions ne peuvent pas être facilement réalisées, ce qui serait très simple à réaliser sur des environnements déployés de manière entièrement contrôlée par l'utilisateur (par exemple, AWS EC2). Certaines de ces limitations ont déjà été abordées dans d'autres blogs, mais pour résumer, aucun service DBaaS ne vous offre le même niveau de flexibilité que la réplication standard basée sur MySQL GTID. Vous pouvez promouvoir n'importe quel esclave, vous pouvez réasservir chaque nœud sur n'importe quel autre... pratiquement toutes les actions sont possibles. Avec des outils comme RDS, vous êtes confronté à des limitations induites par la conception que vous ne pouvez pas contourner.
Le problème réside également dans la capacité à comprendre les détails des performances. Lorsque vous concevez votre propre configuration hautement disponible, vous vous familiarisez avec les problèmes de performances potentiels qui peuvent apparaître. D'un autre côté, RDS et les environnements similaires sont à peu près des "boîtes noires". Oui, nous avons appris qu'Amazon RDS utilise DRBD pour créer un cliché instantané du maître, nous savons qu'Aurora utilise un stockage partagé et répliqué pour mettre en œuvre des basculements très rapides. C'est juste une connaissance générale. Nous ne pouvons pas dire quelles sont les implications sur les performances de ces solutions autres que ce que nous pourrions remarquer par hasard. Quels sont les problèmes communs qui leur sont associés ? Quelle est la stabilité de ces solutions ? Seuls les développeurs derrière la solution le savent avec certitude.
Quelle est l'alternative aux solutions DBaaS ?
Vous vous demandez peut-être s'il existe une alternative au DBaaS ? Après tout, il est si pratique d'exécuter le service géré où vous pouvez accéder à la plupart des actions typiques via l'interface utilisateur. Vous pouvez créer et restaurer des sauvegardes, le basculement est géré automatiquement pour vous. L'environnement est facile à utiliser, ce qui peut être intéressant pour les entreprises qui ne disposent pas de personnel dédié et expérimenté pour gérer les bases de données.
ClusterControl fournit une excellente alternative aux services DBaaS basés sur le cloud. Il vous fournit une interface utilisateur graphique, qui peut être utilisée pour déployer, gérer et surveiller des bases de données open source.
En quelques clics, vous pouvez facilement déployer un cluster de bases de données hautement disponible, avec un basculement automatisé (plus rapide que la plupart des offres DBaaS), une gestion des sauvegardes, une surveillance avancée et d'autres fonctionnalités telles que l'intégration avec des outils externes (par exemple Slack ou PagerDuty) ou la gestion des mises à niveau. Tout cela en évitant complètement le verrouillage du fournisseur.
ClusterControl ne se soucie pas de l'emplacement de vos bases de données tant qu'il peut s'y connecter via SSH. Vous pouvez avoir des configurations dans le cloud, sur site ou dans un environnement mixte de plusieurs fournisseurs de cloud. Tant que la connectivité est là, ClusterControl pourra gérer l'environnement. L'utilisation des solutions que vous souhaitez (et non celles que vous ne connaissez pas ou que vous ne connaissez pas) vous permet de prendre le contrôle total de l'environnement à tout moment.
Quelle que soit la configuration que vous avez déployée avec ClusterControl, vous pouvez facilement la gérer de manière plus traditionnelle, manuelle ou par script. ClusterControl vous fournit même une interface de ligne de commande, qui vous permettra d'incorporer des tâches exécutées par ClusterControl dans vos scripts shell. Vous avez tout le contrôle que vous voulez - rien n'est une boîte noire, chaque élément de l'environnement serait construit à l'aide de solutions open source combinées et déployées par ClusterControl.
Voyons avec quelle facilité vous pouvez déployer un cluster de réplication MySQL à l'aide de ClusterControl. Supposons que vous ayez l'environnement préparé avec ClusterControl installé sur une instance et tous les autres nœuds accessibles via SSH à partir de l'hôte ClusterControl.
Nous allons commencer par choisir l'assistant "Déployer".
À la première étape, nous devons définir comment ClusterControl doit se connecter aux nœuds sur lesquelles les bases de données doivent être déployées. L'accès root ou sudo (avec ou sans mot de passe) sont pris en charge.
Ensuite, nous voulons choisir un fournisseur, une version et transmettre le mot de passe pour l'utilisateur administratif dans notre base de données MySQL.
Enfin, nous souhaitons définir la topologie de notre nouveau cluster. Comme vous pouvez le constater, il s'agit d'une configuration déjà assez complexe, contrairement à quelque chose que vous pouvez déployer à l'aide d'AWS RDS ou d'un nœud SQL GCP.
Il ne nous reste plus qu'à attendre la fin du processus. ClusterControl fera de son mieux pour comprendre l'environnement dans lequel il se déploie et installera l'ensemble de packages requis, y compris la base de données elle-même.
Une fois que le cluster est opérationnel, vous pouvez procéder au déploiement la couche proxy (qui fournira à votre application un point d'entrée unique dans la couche base de données). C'est plus ou moins ce qui se passe dans les coulisses avec DBaaS, où vous avez également des points de terminaison pour vous connecter au cluster de bases de données. Il est assez courant d'utiliser un point de terminaison unique pour les écritures et plusieurs points de terminaison pour atteindre des répliques particulières.
Ici, nous allons utiliser ProxySQL, qui fera le sale boulot pour nous - il comprendra la topologie, n'enverra des écritures qu'au maître et équilibrera la charge des requêtes en lecture seule sur tous les réplicas dont nous disposons.
Pour déployer ProxySQL, nous irons dans Gérer -> Équilibreurs de charge.
Nous devons remplir tous les champs obligatoires :hôtes sur lesquels déployer, informations d'identification pour l'utilisateur administratif et de surveillance, nous pouvons importer un utilisateur existant de MySQL dans ProxySQL ou en créer un nouveau. Tous les détails sur ProxySQL peuvent être facilement trouvés dans plusieurs blogs dans notre section blog.
Nous voulons qu'au moins deux nœuds ProxySQL soient déployés pour assurer une haute disponibilité. Ensuite, une fois déployés, nous déploierons Keepalived au-dessus de ProxySQL. Cela garantira que l'adresse IP virtuelle sera configurée et pointera vers l'une des instances ProxySQL, tant qu'il y aura au moins un nœud sain.
Voici le seul problème potentiel si vous optez pour des environnements cloud où le routage fonctionne d'une manière telle que vous ne pouvez pas facilement afficher une interface réseau. Dans ce cas, vous devrez modifier la configuration de Keepalived, introduire le script 'notify_master' et utiliser un script, qui apportera les modifications IP nécessaires - dans le cas d'EC2, il faudrait détacher l'IP élastique d'un hôte et l'attacher au autre hôte.
Il existe de nombreuses instructions sur la façon de procéder à l'aide de logiciels open source largement testés dans les configurations déployées par ClusterControl. Vous pouvez facilement trouver des informations supplémentaires, des conseils et des procédures adaptés à votre environnement particulier.
Conclusion
Nous espérons que vous avez trouvé cet article de blog perspicace. Si vous souhaitez tester ClusterControl, il est livré avec un essai d'entreprise de 30 jours où vous disposez de toutes les fonctionnalités. Vous pouvez le télécharger gratuitement et tester s'il s'adapte à votre environnement.
