Considérations DevOps pour les déploiements de bases de données prêtes pour la production

MySQL est facile à installer et à utiliser, il a toujours été populaire auprès des développeurs et des administrateurs système. D'un autre côté, le déploiement d'un environnement MySQL prêt pour la production pour une charge de travail d'entreprise critique est une autre histoire. Cela peut être un peu difficile et nécessite une connaissance approfondie de la base de données. Dans cet article de blog, nous discuterons de certaines des étapes à suivre avant de pouvoir considérer que notre déploiement MySQL est prêt pour la production.

Haute disponibilité

Si vous faites partie de ces chanceux qui peuvent accepter des heures d'indisponibilité, vous pouvez arrêter de lire ici et passer au paragraphe suivant. Pour 99,999 % des systèmes critiques pour l'entreprise, ce ne serait pas acceptable. Par conséquent, un déploiement prêt pour la production doit inclure des mesures de haute disponibilité. Un basculement automatisé des instances de base de données, ainsi qu'une couche proxy qui détecte les changements de topologie et d'état de MySQL et achemine le trafic en conséquence, seraient une exigence principale. Il existe de nombreux outils qui peuvent être utilisés pour créer de tels environnements, par exemple MHA, MRM ou ClusterControl.

Couche proxy

Détection des défaillances du maître, basculement et récupération automatisés :ces éléments sont cruciaux lors de la création d'une infrastructure prête pour la production. Mais à eux seuls, cela ne suffit pas. Il reste une application qui devra s'adapter au changement de topologie déclenché par le basculement. Bien sûr, il est possible de coder l'application pour qu'elle soit consciente des défaillances d'instance. Il s'agit cependant d'une manière lourde et inflexible de gérer les changements de topologie. Voici le proxy de base de données - une couche intermédiaire entre l'application et la base de données. Un proxy peut masquer la complexité de votre couche de base de données à l'application - tout ce que fait l'application est de se connecter au proxy et le proxy s'occupe du reste. Le proxy acheminera les requêtes vers une instance de base de données, il gérera les changements de topologie et réacheminera si nécessaire. Un proxy peut également être utilisé pour implémenter la division lecture-écriture, soulageant l'application d'un cas plus complexe à couvrir. Cela crée un autre défi - quel proxy utiliser ? Comment le configurer ? Comment le surveiller ? Comment le rendre hautement disponible, afin qu'il ne devienne pas un SPOF ?

ClusterControl peut vous aider ici. Il peut être utilisé pour déployer différents proxys pour former une couche proxy :ProxySQL, HAProxy et MaxScale. Il préconfigure les proxys pour s'assurer qu'ils géreront correctement le trafic. Il facilite également la mise en œuvre des modifications de configuration si vous avez besoin de personnaliser la configuration du proxy pour votre application. La division lecture-écriture peut être configurée à l'aide de l'un des proxys pris en charge par ClusterControl. ClusterControl surveille également les proxys et les récupère en cas de panne. La couche proxy peut devenir un point de défaillance unique, car la récupération automatisée peut ne pas suffire. Pour résoudre ce problème, ClusterControl peut déployer Keepalived et configurer Virtual IP pour automatiser le basculement.

Sauvegardes

Même si vous n'avez pas besoin d'implémenter la haute disponibilité, vous devez probablement vous soucier de vos données. La sauvegarde est indispensable pour presque toutes les bases de données de production. Rien d'autre qu'une sauvegarde ne peut vous sauver d'un DROP TABLE ou DROP SCHEMA accidentel (enfin, peut-être un esclave de réplication retardé, mais seulement pendant un certain temps). MySQL propose plusieurs méthodes de sauvegarde - mysqldump, xtrabackup, différents types d'instantanés (certains disponibles uniquement avec un matériel ou un fournisseur de cloud particulier). Il n'est pas facile de concevoir la bonne stratégie de sauvegarde, de décider quels outils utiliser, puis de scripter l'ensemble du processus pour qu'il s'exécute correctement. Ce n'est pas sorcier non plus et nécessite une planification et des tests minutieux. Une fois la sauvegarde effectuée, vous n'avez pas terminé. Êtes-vous sûr que la sauvegarde peut être restaurée et que les données ne sont pas des déchets ? La vérification de vos sauvegardes prend du temps et n'est peut-être pas la chose la plus excitante que vous aurez sur votre liste de tâches. Mais cela reste important et doit être fait régulièrement.

ClusterControl dispose de fonctionnalités étendues de sauvegarde et de restauration. Il prend en charge mysqldump pour la sauvegarde logique et Percona Xtrabackup pour la sauvegarde physique - ces outils peuvent être utilisés dans presque tous les environnements, que ce soit dans le cloud ou sur site. Il est possible de construire une stratégie de sauvegarde avec un mélange de sauvegardes logiques et physiques, incrémentielles ou complètes, en ligne.

Outre la récupération, il dispose également d'options pour vérifier une sauvegarde - par exemple, la restaurer sur un hôte séparé afin de vérifier si le processus de sauvegarde fonctionne correctement ou non.

Si vous souhaitez surveiller régulièrement les sauvegardes (et vous voudriez probablement le faire), ClusterControl a la capacité de générer des rapports opérationnels. Le rapport de sauvegarde vous aide à suivre les sauvegardes exécutées et vous informe s'il y a eu des problèmes lors de leur exécution.

Surveillance et tendances

Aucun déploiement n'est prêt pour la production sans une surveillance appropriée des services. Vous voulez vous assurer que vous serez alerté si certains services deviennent indisponibles afin que vous puissiez prendre une action, enquêter ou lancer des procédures de récupération. Bien sûr, vous souhaitez également disposer d'une solution tendance. On ne saurait trop insister sur l'importance de disposer de données de surveillance pour évaluer l'état de l'infrastructure ou pour toute enquête, qu'il s'agisse d'une surveillance post-mortem ou en temps réel de l'état des services. Les métriques n'ont pas la même importance - si vous n'êtes pas très familier avec un produit de base de données particulier, vous ne saurez probablement pas quelles sont les métriques les plus importantes à collecter et à surveiller. Bien sûr, vous pourrez peut-être tout collecter, mais lorsqu'il s'agit d'examiner les données, il n'est guère possible de parcourir des centaines de métriques par hôte - vous devez savoir sur lesquelles vous devez vous concentrer.

Le monde open source regorge d'outils conçus pour surveiller et collecter des métriques à partir de différentes bases de données - la plupart d'entre eux vous obligeraient à les intégrer à votre infrastructure de surveillance globale, à votre plate-forme chatops ou à des outils d'assistance sur appel (comme PagerDuty). Il peut également être nécessaire d'installer et d'intégrer plusieurs composants - stockage (une sorte de base de données de séries chronologiques), couche de présentation et outils de collecte de données.

ClusterControl est une approche un peu différente, car il s'agit d'un produit unique avec une surveillance en temps réel, des tendances et des tableaux de bord qui affichent les détails les plus importants. Les conseillers de base de données, qui peuvent être de simples conseils de configuration, des avertissements sur les seuils ou des règles plus complexes pour les prédictions, produisent généralement des recommandations complètes.

Capacité à évoluer

Les bases de données ont tendance à croître en taille, et il n'est pas improbable qu'elles augmentent en termes de volumes de transactions ou de nombre d'utilisateurs. La capacité à évoluer ou à augmenter peut être essentielle pour la production. Même si vous faites un excellent travail en estimant vos besoins en matériel au début du cycle de vie du produit, vous devrez probablement gérer une phase de croissance - tant que votre produit réussit, c'est-à-dire (mais c'est ce que nous prévoyons tous, n'est-ce pas ?). Vous devez avoir les moyens de faire évoluer facilement votre infrastructure pour faire face à la charge entrante. Pour les services sans état comme les serveurs Web, c'est assez simple - il vous suffit de provisionner plus d'instances à l'aide de la dernière image de production ou du code de votre outil de contrôle de version. Pour les services avec état comme les bases de données, c'est plus délicat. Vous devez provisionner de nouvelles instances à l'aide de vos données de production actuelles, configurer la réplication ou une forme de clustering entre les instances actuelles et les nouvelles. Cela peut être un processus complexe et pour bien faire les choses, vous devez avoir une connaissance plus approfondie du modèle de clustering ou de réplication choisi.

ClusterControl, comme son nom l'indique, fournit un support étendu pour la création de configurations de bases de données en cluster ou répliquées. Les méthodes utilisées sont testées au combat à travers des milliers de déploiements. Il est livré avec une interface de ligne de commande (CLI) afin de pouvoir être facilement intégré aux systèmes de gestion de configuration. N'oubliez pas, cependant, que vous ne voudrez peut-être pas apporter de modifications à votre pool de bases de données trop souvent - le provisionnement d'une nouvelle instance prend du temps et ajoute des frais généraux dans les bases de données existantes. Par conséquent, vous voudrez peut-être rester un peu du côté "sur-provisionné" afin d'avoir le temps de créer une nouvelle instance avant que votre cluster ne soit surchargé.

Dans l'ensemble, vous devez encore suivre plusieurs étapes après le déploiement initial pour vous assurer que votre environnement est prêt pour la production. Avec les bons outils, il est beaucoup plus facile d'y arriver.