Les environnements hybrides, où une partie de l'infrastructure de la base de données est située sur site et une partie dans un cloud public, ne sont pas rares. Il peut y avoir différentes raisons d'utiliser une telle configuration :évolutivité, flexibilité, haute disponibilité, reprise après sinistre. Comment mettre en œuvre cette configuration de manière appropriée ? Cela peut être difficile car vous devez considérer plusieurs pièces d'un puzzle qui doivent s'emboîter. Ce blog est destiné à vous donner un aperçu de ce à quoi pourrait ressembler une telle configuration.
Connectivité
Nous n'entrerons pas dans les détails ici car il existe de nombreuses façons de configurer la connectivité entre votre configuration sur site et le cloud public. Cela dépendra de l'infrastructure dont vous disposez, du cloud public que vous souhaitez utiliser et de nombreux autres facteurs. La gamme d'options peut commencer par des routeurs compatibles BGP, via un VPN matériel, un VPN logiciel se terminant sur des tunnels SSH comme moyen de connecter temporairement votre réseau aux instances dans un cloud public. Ce qui est important, quoi que vous fassiez, le résultat final doit être une connectivité complète et transparente de votre réseau sur site aux instances situées dans le cloud public.
Considérations sur la haute disponibilité
La réplication MySQL est un excellent moyen de créer des systèmes hautement disponibles, mais elle s'accompagne de limitations importantes. La principale chose à considérer est l'auteur - vous ne pouvez avoir qu'un seul endroit où envoyer vos écritures - le maître. Quelle que soit la façon dont vous souhaitez concevoir l'ensemble de l'environnement, vous devez examiner attentivement l'emplacement du maître. Vous souhaitez très probablement qu'il fasse partie de l'environnement, qui contient les hôtes de l'application. Considérons la configuration suivante :
Nous avons une configuration sur site avec trois nœuds MySQL et deux esclaves supplémentaires situé dans le cloud public, agissant comme un moyen de reprise après sinistre pour l'entreprise, il est tout à fait clair que le nœud inscriptible doit être colocalisé avec les hôtes d'application dans la partie privée du cloud. Nous voulons maintenir la latence aussi faible que possible pour les connexions les plus importantes.
Ce type de conception se concentre sur la disponibilité des bases de données - si les nœuds situés sur place ne sont pas disponibles, les hôtes d'application peuvent être en mesure de se connecter à la partie distante de la configuration - les nœuds de base de données situés dans le cloud public. Idéalement, vous utiliseriez une sorte de proxy pour cela - ProxySQL est l'une des solutions qui peut suivre la topologie et reconfigurer selon les besoins en fonction de la chaîne de réplication existante.
Si vous souhaitez envisager davantage une configuration active-active où vous avez des nœuds d'application à la fois privés et publics, vous devez faire des compromis car les écritures devront être transférées sur le WAN, du cloud public au cloud privé (ou vice versa, si votre emplacement principal où vous opérez dans le cloud public).
Encore une fois, ProxySQL est le proxy de choix. Ce qui est formidable, ProxySQL peut être configuré en tant que cluster ProxySQL, garantissant que les modifications de configuration introduites dans un nœud seront répliquées sur les nœuds ProxySQL restants.
Gestion des échecs
Considérons quelques scénarios d'échec. Avant toute chose, nous devons garder à l'esprit que la réplication asynchrone MySQL n'est pas compatible avec les clusters, donc la division du réseau doit être gérée manuellement - ce sera à l'utilisateur de prendre la décision et d'appuyer sur le commutateur pour promouvoir l'un des les esclaves dans l'environnement disponible. Il appartient également à l'utilisateur de s'assurer que l'environnement, qui a perdu la connectivité réseau, se comportera comme il se doit et qu'il ne continuera pas à fonctionner.
Si la partie privée du cloud devient indisponible, comme nous l'avons mentionné précédemment, une action manuelle sera nécessaire pour promouvoir l'un des esclaves afin qu'il devienne un nouveau maître. Ensuite, tous les serveurs d'applications Web restants situés dans le cloud public, utilisant ProxySQL local, verront leur trafic redirigé vers le nouveau maître et tous les esclaves restants. D'autre part, étant donné que nous avons perdu trois nœuds MySQL sur cinq, nous souhaitons étendre la configuration du cloud public - ClusterControl peut vous aider à ajouter efficacement des nœuds supplémentaires à votre cluster.
Un autre scénario pourrait être que le rédacteur se soit planté alors que la connectivité entre notre configuration sur site et le cloud public fonctionne parfaitement.
Dans un tel scénario, nous voulons promouvoir l'un des esclaves pour qu'il devienne un nouveau maître. Selon les besoins, nous pouvons également souhaiter que le nouveau maître soit promu entre les nœuds d'une partie donnée de l'environnement. ClusterControl a la capacité de mettre sur liste blanche ou sur liste noire les nœuds pour le basculement, garantissant que vous avez un contrôle total sur le processus de basculement et que vous pouvez choisir quels nœuds doivent être considérés comme candidats pour un nouveau maître et dans quel ordre.
Nous espérons que ce blog vous a donné une idée du fonctionnement de la configuration du cloud hybride pour la réplication MySQL et de la manière dont il peut vous protéger en cas de défaillance de la base de données ou du réseau.
