Il est très courant de voir des bases de données réparties sur plusieurs emplacements géographiques. Un scénario pour effectuer ce type de configuration est la reprise après sinistre, où votre centre de données de secours est situé dans un emplacement distinct de votre centre de données principal. Il pourrait tout aussi bien être nécessaire pour que les bases de données soient situées plus près des utilisateurs.
Le principal défi pour réaliser cette configuration consiste à concevoir la base de données de manière à réduire les risques de problèmes liés au partitionnement du réseau.
MariaDB Cluster peut être un bon choix pour construire un tel environnement pour plusieurs raisons. Nous aimerions en discuter ici et aussi parler un peu de ce à quoi un tel environnement peut ressembler.
Pourquoi utiliser MariaDB Cluster pour les environnements géo-distribués ?
La première raison est que MariaDB Cluster peut prendre en charge plusieurs écrivains. Cela facilite la conception du routage en écriture - il vous suffit d'écrire sur les nœuds MariaDB locaux. Bien sûr, étant donné la réplication synchrone, la latence a un impact sur les performances d'écriture et vous pouvez constater que vos écritures ralentissent si vous étendez votre cluster trop loin géographiquement. Après tout, vous ne pouvez pas ignorer les lois de la physique et elles disent, à partir de maintenant du moins, que même la vitesse de la lumière dans les connexions par fibre est limitée. Tout routeur ajouté en plus de cela augmentera également la latence, même si ce n'est que de quelques millisecondes.
Deuxièmement, la gestion des décalages dans le cluster MariaDB. La réplication asynchrone est un sujet de décalage de réplication - les esclaves peuvent ne pas être à jour avec les données s'ils ont du mal à appliquer toutes les modifications dans le temps. Dans MariaDB Cluster, c'est différent - le contrôle de flux est un mécanisme destiné à maintenir la synchronisation du cluster. Eh bien, presque - dans certains cas extrêmes, vous pouvez toujours observer un décalage. Nous parlons ici, typiquement, de millisecondes, quelques secondes au plus alors que dans le ciel de la réplication asynchrone, c'est la limite.
Troisièmement, segments. Par défaut, MariaDB CLuster utilise la communication all to all et chaque jeu d'écriture est envoyé par le nœud à tous les autres nœuds du cluster. Ce comportement peut être modifié à l'aide de segments. Les segments permettent aux utilisateurs de diviser les clusters MariaDB en plusieurs parties. Chaque segment peut contenir plusieurs nœuds et il élit l'un d'eux comme nœud relais. Ces nœuds reçoivent des jeux d'écriture d'autres segments et les redistribuent sur les nœuds MariaDB locaux du segment. En conséquence, comme vous pouvez le voir sur le schéma ci-dessus, il est possible de réduire le trafic de réplication passant sur le WAN par trois - seulement deux "répliques" du flux de réplication sont envoyées sur le WAN :une par centre de données contre une par esclave. en réplication asynchrone.
Enfin, là où MariaDB Cluster brille vraiment, c'est la gestion du partitionnement du réseau. MariaDB Cluster surveille en permanence l'état des nœuds du cluster. Chaque nœud tente de se connecter avec ses pairs et d'échanger l'état du cluster. Si un sous-ensemble de nœuds n'est pas accessible, MariaDB tente de relayer la communication, donc s'il existe un moyen d'atteindre ces nœuds, ils seront atteints.
Un exemple peut être vu sur le schéma ci-dessus :DC 1 a perdu la connectivité avec DC2 mais DC2 et DC3 peuvent se connecter. Dans ce cas, l'un des nœuds de DC3 sera utilisé pour relayer les données de DC1 à DC2 en veillant à ce que la communication intra-cluster puisse être maintenue.
MariaDB est capable de prendre des mesures en fonction de l'état du cluster. Il implémente le quorum - la majorité des nœuds doivent être disponibles pour que le cluster puisse fonctionner. Si le nœud est déconnecté du cluster et ne peut atteindre aucun autre nœud, il cessera de fonctionner.
Comme on peut le voir sur le schéma ci-dessus, il y a une perte partielle de la communication réseau dans DC1 et le nœud affecté est supprimé du cluster, garantissant que l'application n'accédera pas aux données obsolètes.
Cela est également vrai à plus grande échelle. Le DC1 s'est vu couper toutes ses communications. En conséquence, l'ensemble du centre de données a été supprimé du cluster et aucun de ses nœuds ne desservira le trafic. Le reste du cluster est resté majoritaire (6 nœuds sur 9 sont disponibles) et s'est reconfiguré pour conserver la connexion entre DC 2 et DC3. Dans le diagramme ci-dessus, nous avons supposé que l'écrivain atteignait le nœud dans DC2, mais gardez à l'esprit que MariaDB est capable de fonctionner avec plusieurs écrivains.
Concevoir un cluster MariaDB distribué géographiquement
Nous avons passé en revue certaines des fonctionnalités qui font de MariaDB Cluster une solution idéale pour les environnements géo-distribués, concentrons-nous maintenant un peu sur la conception. Au début, expliquons avec quel environnement nous travaillons. Nous utiliserons trois centres de données distants, connectés via un réseau étendu (WAN). Chaque centre de données recevra les écritures des serveurs d'applications locaux. Les lectures seront également uniquement locales. Ceci est destiné à éviter le trafic inutile traversant le WAN.
Pour rendre ce blog moins compliqué, nous n'entrerons pas dans les détails de la façon dont la connectivité devrait ressembler. Nous supposons une sorte de connexion sécurisée et correctement configurée entre tous les centres de données. Un VPN ou d'autres outils peuvent être utilisés pour implémenter cela.
Nous utiliserons MaxScale comme loadbalancer. MaxScale sera déployé localement dans chaque centre de données. Il acheminera également le trafic uniquement vers les nœuds locaux. Les nœuds distants peuvent toujours être ajoutés manuellement et nous expliquerons les cas où cela pourrait être une bonne solution. Les applications peuvent être configurées pour se connecter à l'un des nœuds MaxScale locaux à l'aide d'un algorithme round-robin. Nous pouvons également utiliser Keepalived et Virtual IP pour acheminer le trafic vers le seul nœud MaxScale, tant qu'un seul nœud MaxScale serait capable de gérer tout le trafic.
Une autre solution possible consiste à colocaliser MaxScale avec des nœuds d'application et à configurer l'application pour qu'elle se connecte au proxy sur l'hôte local. Cette approche fonctionne assez bien dans l'hypothèse où il est peu probable que MaxScale ne soit pas disponible, mais l'application fonctionnerait correctement sur le même nœud. Généralement, ce que nous voyons est soit une panne de nœud, soit une panne de réseau, ce qui affecterait à la fois MaxScale et l'application.
Le schéma ci-dessus montre la version de l'environnement, où MaxScale forme des fermes proxy - tous les nœuds proxy avec la même configuration, équilibrage de charge à l'aide de Keepalived, ou simplement tourniquet depuis l'application sur tous les nœuds MaxScale. MaxScale est configuré pour répartir la charge de travail sur tous les nœuds MariaDB du centre de données local. L'un de ces nœuds serait choisi comme nœud pour envoyer les écritures tandis que les SELECT seraient distribués sur tous les nœuds. Le fait d'avoir un nœud d'écriture dédié dans un centre de données permet de réduire le nombre de conflits de certification possibles, ce qui se traduit généralement par de meilleures performances. Pour réduire encore plus cela, nous devrions commencer à envoyer le trafic via la connexion WAN, ce qui n'est pas idéal car l'utilisation de la bande passante augmenterait considérablement. À l'heure actuelle, avec les segments en place, seules deux copies du jeu d'écriture sont envoyées dans les centres de données :une par DC.
Conclusion
Comme vous pouvez le voir, MariaDB Cluster peut facilement être utilisé pour créer des clusters géo-distribués qui peuvent fonctionner même à travers le monde. Le facteur limitant sera la latence du réseau. S'il est trop élevé, vous devrez peut-être envisager d'utiliser des clusters MariaDB séparés connectés à l'aide de la réplication asynchrone.
