Comprendre la haute disponibilité de MySQL : Bonnes et mauvaises raisons de l'utiliser

Le coût des temps d'arrêt dans l'environnement de l'entreprise s'élève rapidement. Dans une enquête, 40% des répondants ont suggéré qu'une seule heure de temps d'arrêt coûtait à leur entreprise plus d'un million de dollars de pertes. S'assurer que les services de base de données sont disponibles en permanence en vaut clairement la peine.

Elle permet à votre organisation d'économiser d'importantes sommes d'argent, sans compter qu'elle facilite les relations avec les parties prenantes de toutes formes et de toutes tailles.

Alors comment assurer une disponibilité permanente ? Le concept qui sous-tend la disponibilité permanente est appelé haute disponibilité. Dans cet article, nous décrivons ce qu'est la haute disponibilité et comment vous pouvez l'obtenir pour vos clusters MySQL.

Nous mettons également en évidence un aspect plus sombre de la haute disponibilité, à savoir le fait que les administrateurs système s'appuient à tort sur la haute disponibilité pour effectuer des tâches de maintenance. Nous expliquons pourquoi cela compromet les objectifs de la haute disponibilité et met en danger les opérations de votre entreprise.

Introduction à la haute disponibilité

Parlons d'abord de la disponibilité. Il n'y a guère d'intérêt à faire fonctionner un service tel qu'une base de données s'il n'est pas disponible pour les utilisateurs la plupart du temps. Ainsi, lorsque nous parlons de disponibilité, nous faisons référence au degré d'accessibilité d'un service.

Pour tout service qui fonctionne, on peut raisonnablement s'attendre à ce qu'il soit disponible quand on en a besoin, mais on peut aussi s'attendre à des temps d'arrêt, un jour ou deux par an ou peut-être quelques heures par mois.

Un service généralement disponible peut convenir à de nombreux scénarios d'utilisation, mais lorsque le service est de nature critique ou lorsqu'un très grand nombre d'utilisateurs dépend d'un service, la simple "disponibilité" ne suffit pas.

Et c'est là que la haute disponibilité entre en jeu. En termes simples, la haute disponibilité garantit une disponibilité supérieure à celle normalement attendue et, plus précisément, à un niveau convenu, même en tenant compte de la maintenance, des correctifs et des erreurs générales.

Quel est le niveau de disponibilité de la haute disponibilité ?

Il n'existe pas de définition commune de ce qui constitue la haute disponibilité, mais seulement le fait qu'elle dépasse ce qui serait généralement accepté comme "disponible" afin de répondre à une exigence de disponibilité spécifique (plus élevée). En fait, votre entreprise définira probablement la disponibilité dont elle a besoin en fonction de ses besoins opérationnels, en mettant en balance les coûts de la haute disponibilité et les pertes associées aux temps d'arrêt.

Le niveau de disponibilité dont vous avez besoin peut être exprimé en pourcentage. Par exemple, une disponibilité de 99,99 % ou "quatre neuf" implique un maximum de 52,60 minutes de temps d'arrêt par an, tandis qu'une disponibilité de "six neuf" ou 99,9999 % limite le temps d'arrêt à 31,56 secondes par an.

En fait, c'est à vous de choisir, mais, là encore, il y a un compromis à faire. Le maintien de la haute disponibilité sera coûteux, car il nécessitera des ressources physiques et des licences logicielles supplémentaires et mobilisera également vos ressources humaines. Cependant, vous pourriez bien trouver que c'est un prix à payer pour éviter les coûts de perturbation ou les risques de perte de revenus dus à des clients mécontents.

Comment la haute disponibilité fonctionne-t-elle en pratique ?

La nature exacte de votre infrastructure de haute disponibilité dépend de votre charge de travail. Cependant, on pourrait dire que la haute disponibilité est atteinte lorsqu'il y a tolérance aux pannes, de sorte que même si un service ou un dispositif tombe en panne, la charge de travail n'est pas interrompue. Typiquement, cela signifie qu'il n'y a pas de point de défaillance unique - tous les services et dispositifs sont entièrement redondants au niveau du réseau et de l'application.

En fonction du service, cela peut impliquer un certain nombre de nœuds - par exemple, votre cluster MySQL contiendra plusieurs nœuds sur lesquels les données sont stockées. Les nœuds multiples sont ensuite combinés avec un outil d'équilibrage de charge de sorte que, si un nœud tombe en panne, les demandes sont simplement dirigées vers un autre nœud. Les utilisateurs auront toujours accès à un service disponible, même si les performances sont légèrement dégradées.

Configuration de la haute disponibilité dans MySQL

Votre chemin vers une base de données MySQL à haute disponibilité dépendra, bien entendu, de votre implémentation de MySQL. D'une manière générale, vous devrez créer un type de cluster MySQL avec plusieurs nœuds. En d'autres termes, vos données doivent résider sur plusieurs serveurs MySQL.

Ensuite, vous aurez besoin d'un service capable de répliquer les données sur ces nœuds, afin que chacun d'entre eux dispose d'une copie exacte des données contenues dans votre base de données. Enfin, vous avez besoin d'un équilibreur de charge qui garantit que toutes les demandes de la base de données sont dirigées de manière égale vers les nœuds de la base de données - assurant, oui, une charge équilibrée - mais garantissant également que les demandes sont satisfaites même si un nœud est hors ligne.

Par exemple, MySQL offre un produit commercial orienté vers la haute disponibilité - le MySQL InnoDB Cluster. Il est basé sur la réplication de groupe MySQL, qui est un moyen populaire d'assurer la haute disponibilité dans un environnement de base de données MySQL.

Une autre alternative est Galera, qui offre la haute disponibilité de MySQL depuis de nombreuses années. Si vous utilisez le fork MariaDB de MySQL, vous pouvez par exemple configurer votre environnement MariaDB pour la haute disponibilité en faisant tourner plusieurs nœuds à l'aide de Galera Cluster - tout en vous appuyant sur HAProxy pour l'équilibrage des charges. Vous pouvez également vous pencher le produit MaxScale de MariaDB..

DE BONNES RAISONS DE COMPTER SUR LA HAUTE DISPONIBILITÉ...

Les charges de travail à l'échelle de l'entreprise font de plus en plus appel aux principes de haute disponibilité, tout simplement parce que, à long terme, ils donnent les meilleurs résultats. Voici quelques-unes des nombreuses bonnes raisons pour lesquelles vous devriez envisager de mettre en place la haute disponibilité dans vos opérations :

• Applications critiques. Certaines applications ne peuvent tout simplement pas se permettre le moindre temps d'arrêt. Pensez aux applications militaires ou aux réseaux d'énergie. La haute disponibilité est une nécessité dans ces scénarios, et vous n'avez guère d'autre choix que de garantir des niveaux de disponibilité extrêmement élevés - même si vous pouvez toujours évaluer les risques et décider du niveau exact de la garantie de disponibilité dont vous avez besoin.
• Effets d'entraînement. Lorsqu'un système est au cœur d'une charge de travail, une interruption, même brève, peut entraîner des problèmes beaucoup plus étendus, car les systèmes connectés et synchronisés tombent en cascade. Il vaut la peine d'envisager d'investir dans la haute disponibilité dans quelques domaines essentiels - comme une base de données - car cela peut valoir la peine, compte tenu des coûts des problèmes en chaîne beaucoup plus importants qui peuvent être très difficiles à récupérer.
• Perte de revenus. Une haute disponibilité, même si elle n'atteint qu'un nombre modeste de neuf, peut prévenir les pertes de revenus. Pour un grand détaillant en ligne, quelques heures de ventes perdues, associées à une atteinte à la réputation, peuvent avoir un impact très important sur les résultats.
• Attentes des clients et accords de niveau de service. Vos opérations peuvent être liées à des accords de niveau de service garantissant à vos clients un certain niveau de temps de fonctionnement. Si tel est le cas, vous devez vous assurer que les services qui prennent en charge les charges de travail de vos clients ont le niveau de disponibilité requis - et vous y parviendrez grâce à la haute disponibilité. Tout manquement à cette obligation peut entraîner la résiliation des contrats ou des pénalités.

Ce ne sont là que quelques-unes des raisons valables d'opter pour la haute disponibilité - et, encore une fois, dans le monde actuel, dominé par la technologie, de nombreuses charges de travail ne peuvent tout simplement pas fonctionner sans une plateforme de haute disponibilité.

... et la mauvaise raison de compter sur la haute disponibilité 

La prévalence croissante de la haute disponibilité a, malheureusement, également conduit à son abus. Parce que la haute disponibilité rend les systèmes incroyablement robustes, les équipes techniques peuvent être tentées de prendre des raccourcis lors de l'exécution de tâches d'administration système telles que l'application de correctifs, car elles supposent que l'infrastructure de haute disponibilité supportera simplement le poids de la mise hors ligne d'une machine.

En pratique, cela peut rapidement devenir plus compliqué. Prenez un cluster MySQL, par exemple. Oui, si vous redémarrez une machine pour la réparer, votre cluster MySQL continuera de fonctionner grâce à la haute disponibilité. Cependant, n'oubliez pas que lorsque vous mettez un nœud hors service pour le réparer et que vous le redémarrez ensuite, il en résulte une accumulation de données qui doivent être injectées. Ce processus peut prendre beaucoup de temps.

Il va sans dire que chaque hôte de la base de données doit voir les mêmes données. Le danger survient lors de la resynchronisation : si un autre nœud tombe en panne alors que vous avez déjà retiré un nœud pour le réparer, vous pouvez vous retrouver avec une perte de quorum valide. En d'autres termes, le nombre de serveurs qui détiennent la "vérité" sur les données tombe en dessous d'un niveau acceptable. La récupération d'un tel état peut être difficile et complexe, voire entraîner une perte de données.

Ne pas compter sur la haute disponibilité pour la maintenance

La haute disponibilité est là pour maintenir vos systèmes en état de marche, même en cas de défaillance. Cette protection inhérente contre les défaillances n'est pas un laissez-passer pour dépendre de la robustesse de la haute disponibilité afin d'effectuer la maintenance du système de manière irresponsable, en espérant que personne ne le remarquera.

Les équipes techniques devraient plutôt s'appuyer sur d'autres solutions - par exemple, mettre en place une redondance complète pour un système qui fait l'objet d'un correctif plutôt que d'espérer simplement que l'infrastructure de haute disponibilité absorbe la pression. Ou, dans la mesure du possible s'appuyer sur des correctifs en direct et, ce faisant, supprimer la nécessité de redémarrer un service pour installer un correctif.

Néanmoins, la dépendance à la haute disponibilité pour les tâches de maintenance montre des signes inquiétants de prévalence. En cherchant un peu, vous trouverez même des conseils officiels de fournisseurs qui demandent aux utilisateurs de dépendre de la haute disponibilité pour exécuter les tâches de correction et d'espérer simplement que rien d'autre ne se passe sur les autres nœuds pendant qu'un nœud est mis hors ligne pour la correction.

ENVELOPPEMENT

La haute disponibilité est essentielle pour un grand nombre d'applications - et très bénéfique pour beaucoup d'autres. Configurée correctement, une base de données MySQL peut offrir une disponibilité quasi parfaite, mais cela ne signifie pas que les équipes techniques peuvent considérer la disponibilité comme acquise.

Abuser de l'architecture de haute disponibilité pour prendre des raccourcis de maintenance n'est tout simplement pas une option - les risques sont plus grands qu'il n'y paraît à première vue.

Les administrateurs système doivent plutôt se tourner vers des solutions de rechange éprouvées - notamment la redondance et les correctifs en direct - pour effectuer les opérations de maintenance sans compromettre les capacités des solutions de haute disponibilité.