La haute disponibilité étant primordiale dans la réalité commerciale d'aujourd'hui, l'un des scénarios les plus courants auxquels les utilisateurs doivent faire face est de savoir comment s'assurer que la base de données sera toujours disponible pour l'application.
Chaque fournisseur de services comporte un risque héréditaire d'interruption de service. Par conséquent, l'une des mesures qui peuvent être prises consiste à s'appuyer sur plusieurs fournisseurs pour atténuer le risque et la redondance supplémentaire.
Les fournisseurs de services cloud ne sont pas différents - ils peuvent échouer et vous devez planifier cela à l'avance. Quelles sont les options disponibles pour MariaDB Cluster ? Jetons-y un œil dans cet article de blog.
Clustering de bases de données MariaDB dans des environnements multi-cloud
Si le SLA proposé par un fournisseur de services cloud ne suffit pas, il existe toujours une option pour créer un site de reprise après sinistre en dehors de ce fournisseur. Grâce à cela, chaque fois que l'un des fournisseurs de cloud subit une dégradation de service, vous pouvez toujours passer à un autre fournisseur et maintenir votre base de données disponible.
L'un des problèmes typiques des configurations multi-cloud est la latence du réseau qui est inévitable si nous parlons de distances plus grandes ou, en général, de plusieurs emplacements géographiquement séparés. La vitesse de la lumière est assez élevée mais elle est finie, chaque saut, chaque routeur ajoute également une certaine latence dans l'infrastructure réseau.
MariaDB Cluster fonctionne parfaitement sur les réseaux à faible latence. Il s'agit d'un cluster basé sur un quorum où une communication rapide entre tous les nœuds est nécessaire pour assurer la fluidité des opérations. L'augmentation de la latence du réseau aura un impact sur les opérations du cluster, en particulier sur les performances des écritures. Il existe plusieurs façons de résoudre ce problème.
Nous avons d'abord la possibilité d'utiliser des clusters séparés connectés à l'aide de liens de réplication asynchrones. Cela nous permet de presque oublier la latence, car la réplication asynchrone est nettement mieux adaptée pour fonctionner dans des environnements à forte latence.
Une autre option est que, compte tenu des réseaux à faible latence entre les centres de données, vous pouvez toujours parfaitement exécuter un cluster MariaDB couvrant plusieurs centres de données. Après tout, plusieurs centres de données ne signifient pas toujours de grandes distances géographiquement - vous pouvez également utiliser plusieurs fournisseurs situés dans la même zone métropolitaine, connectés à des réseaux rapides et à faible latence. Ensuite, nous parlerons de l'augmentation de la latence à des dizaines de millisecondes au maximum, certainement pas à des centaines. Tout dépend de l'application mais une telle augmentation peut être acceptable.
Réplication asynchrone entre clusters MariaDB
Regardons rapidement l'approche asynchrone. L'idée est simple :deux clusters connectés l'un à l'autre à l'aide de la réplication asynchrone.
Cela s'accompagne de plusieurs limitations. Pour commencer, vous devez décider si vous souhaitez utiliser plusieurs maîtres ou envoyer tout le trafic vers un seul centre de données. Nous vous recommandons de ne pas écrire dans les deux centres de données et d'utiliser la réplication maître-maître. Cela peut entraîner de graves problèmes si vous ne faites pas preuve de prudence.
Si vous décidez d'utiliser la configuration active - passive, vous souhaiterez probablement implémenter une sorte de routage basé sur DNS pour les écritures, afin de vous assurer que vos serveurs d'applications se connecteront toujours à un ensemble de proxys situés dans le centre de données actif. Cela peut être réalisé soit par une entrée DNS littérale qui serait modifiée lorsqu'un basculement est requis, soit par une sorte de solution de découverte de service comme Consul ou etcd.
Le principal inconvénient de l'environnement construit à l'aide de la réplication asynchrone est le manque de capacité à gérer les divisions du réseau entre les centres de données. Ceci est hérité de la réplication - peu importe ce que vous voulez lier à la réplication (nœuds uniques, clusters MariaDB), il n'y a aucun moyen de contourner le fait que la réplication n'est pas consciente du quorum. Il n'existe aucun mécanisme pour suivre l'état des nœuds et comprendre l'image de haut niveau de l'ensemble de la topologie. Par conséquent, chaque fois que le lien entre deux centres de données tombe en panne, vous vous retrouvez avec deux clusters MariaDB distincts qui ne sont pas connectés et qui sont tous deux prêts à accepter du trafic. Il appartiendra à l'utilisateur de définir ce qu'il doit faire dans un tel cas. Il est possible d'implémenter des outils supplémentaires qui surveilleraient l'état des bases de données depuis l'extérieur (c'est-à-dire depuis le troisième centre de données) puis prendraient des mesures (ou ne prendraient pas de mesures) en fonction de ces informations. Il est également possible de colocaliser des outils qui partageraient l'infrastructure avec des bases de données mais seraient sensibles aux clusters et pourraient suivre l'état de la connectivité du centre de données et être utilisés comme source de vérité pour les scripts qui géreraient l'environnement. Par exemple, ClusterControl peut être déployé dans un cluster à trois nœuds, nœud par centre de données, qui utilise le protocole RAFT pour garantir le quorum. Si un nœud perd la connectivité avec le reste du cluster, on peut supposer que le centre de données a subi un partitionnement du réseau.
Clusters MariaDB multi-DC
Une alternative à la réplication asynchrone pourrait être une solution de cluster entièrement MariaDB qui s'étend sur plusieurs centres de données.
Comme indiqué au début de ce blog, MariaDB Cluster, comme tous Le cluster basé sur Galera sera impacté par la latence élevée. Cela dit, il est parfaitement acceptable de l'exécuter dans des environnements de latence "moins élevée" et de s'attendre à ce qu'il se comporte correctement, offrant des performances acceptables. Tout dépend du débit et de la conception du réseau, de la distance entre les centres de données et des exigences des applications. Une telle approche fonctionnera très bien, surtout si nous utilisons des segments pour différencier les centres de données distincts. Il permet à MariaDB Cluster d'optimiser sa connectivité intra-cluster et de réduire au minimum le trafic cross-DC.
Le principal avantage de cette configuration est qu'elle s'appuie sur MariaDB Cluster pour gérer les pannes. Si vous utilisez trois centres de données, vous êtes à peu près couvert contre la situation du cerveau divisé - tant qu'il y aura une majorité, il continuera à fonctionner. Il n'est pas nécessaire d'avoir un nœud complet dans le troisième centre de données - vous pouvez également utiliser Galera Arbitrator, un démon qui fait partie du cluster mais qui n'a pas à gérer les opérations de base de données. Il se connecte aux nœuds, participe au calcul du quorum et peut être utilisé pour relayer le trafic si la connexion directe entre les deux centres de données ne fonctionne pas.
Dans ce cas, l'ensemble du processus de basculement peut être décrit comme suit :définissez tous les nœuds dans les équilibreurs de charge (tous si les centres de données sont proches les uns des autres, dans d'autres cas, vous voudrez peut-être ajouter une priorité pour le nœuds situés plus près de l'équilibreur de charge) et c'est à peu près tout. Les nœuds du cluster MariaDB qui forment la majorité seront accessibles via n'importe quel proxy.
Déploiement d'un cluster MariaDB multi-cloud à l'aide de ClusterControl
Regardons deux options que vous pouvez utiliser pour déployer des clusters MariaDB multi-cloud à l'aide de ClusterControl. Veuillez garder à l'esprit que ClusterControl nécessite une connectivité SSH à tous les nœuds qu'il gérera, il vous appartiendra donc d'assurer la connectivité réseau sur plusieurs centres de données ou fournisseurs de cloud. Tant que la connectivité est là, nous pouvons procéder de deux manières.
Déployer des clusters MariaDB à l'aide de la réplication asynchrone
ClusterControl peut vous aider à déployer deux clusters connectés à l'aide de la réplication asynchrone. Lorsque vous avez un seul cluster MariaDB déployé, vous voulez vous assurer que l'un des nœuds a activé les journaux binaires. Cela vous permettra d'utiliser ce nœud comme maître pour le deuxième cluster que nous créerons sous peu.
Une fois le journal binaire activé, nous pouvons utiliser le travail Créer un cluster esclave pour lancer l'assistant de déploiement.
Nous pouvons diffuser les données directement depuis le maître ou vous pouvez en utiliser un des sauvegardes pour provisionner les données.
Ensuite, un assistant de déploiement de cluster standard vous est présenté où vous devez passer Détails de la connectivité SSH.
Il vous sera également demandé de choisir le fournisseur et la version des bases de données comme demandé pour le mot de passe de l'utilisateur root.
Enfin, il vous est demandé de définir les nœuds que vous souhaitez ajouter au cluster et vous êtes prêt.
Une fois déployé, vous le verrez sur la liste des clusters dans le Interface utilisateur ClusterControl.
Déploiement d'un cluster MariaDB multi-cloud
Comme nous l'avons mentionné précédemment, une autre option pour déployer MariaDB Cluster serait d'utiliser des segments séparés lors de l'ajout de nœuds au cluster. Dans l'interface utilisateur de ClusterControl, vous trouverez une option pour "Ajouter un nœud":
Lorsque vous l'utilisez, l'écran suivant s'affiche :
Le segment par défaut est 0, vous souhaitez donc le remplacer par une valeur différente .
Une fois les nœuds ajoutés, vous pouvez vérifier dans quel segment ils se trouvent en consultant l'onglet Présentation :
Conclusion
Nous espérons que ce court blog vous a permis de mieux comprendre les options dont vous disposez pour les déploiements de cluster MariaDB multi-cloud et comment elles peuvent être utilisées pour garantir la haute disponibilité de votre infrastructure de base de données.
