Reprise après sinistre dans le cloud pour MariaDB et MySQL

MySQL a une longue tradition de réplication géographique. La distribution de clusters à des centres de données distants réduit les effets de la latence géographique en rapprochant les données de l'utilisateur. Il fournit également une capacité de reprise après sinistre. En raison du coût important de la duplication du matériel sur un site séparé, peu d'entreprises pouvaient se le permettre dans le passé. Un autre coût est le personnel qualifié capable de concevoir, de mettre en œuvre et de gérer un environnement sophistiqué à plusieurs centres de données.

Avec la révolution de l'automatisation Cloud et DevOps, avoir un centre de données distribué n'a jamais été aussi accessible aux masses. Les fournisseurs de cloud augmentent la gamme de services qu'ils proposent à un meilleur prix. On peut créer des environnements hybrides cross-cloud avec des données réparties dans le monde entier. Il est possible de créer des plans de reprise après sinistre flexibles et évolutifs pour aborder un large éventail de scénarios de perturbation. Dans certains cas, il peut s'agir simplement d'une sauvegarde stockée hors site. Dans d'autres cas, il peut s'agir d'une copie 1 pour 1 d'un environnement de production exécuté ailleurs.

Dans ce blog, nous examinerons certains de ces cas et aborderons des scénarios courants.

Stocker les sauvegardes dans le cloud

Un plan de reprise après sinistre est un terme général qui décrit un processus de récupération des systèmes informatiques perturbés et d'autres actifs critiques qu'une organisation utilise. La sauvegarde est la principale méthode pour y parvenir. Lorsqu'une sauvegarde se trouve dans le même centre de données que vos serveurs de production, vous risquez que toutes les données soient effacées au cas où vous perdriez ce centre de données. Pour éviter cela, vous devez avoir la politique de créer une copie dans un autre emplacement physique. Il est toujours recommandé de conserver une sauvegarde sur disque pour réduire le temps nécessaire à la restauration. Dans la plupart des cas, vous conserverez votre sauvegarde principale dans le même centre de données (pour minimiser le temps de restauration), mais vous devez également disposer d'une sauvegarde pouvant être utilisée pour restaurer les procédures commerciales lorsque le centre de données principal est en panne.

ClusterControl permet une intégration transparente entre votre environnement de base de données et le cloud. Il fournit des options pour migrer les données vers le cloud. Nous proposons une combinaison complète de sauvegardes de bases de données pour Amazon Web Services (AWS), Google Cloud Services ou Microsoft Azure. Les sauvegardes peuvent désormais être exécutées, planifiées, téléchargées et restaurées directement depuis le fournisseur de cloud de votre choix. Cette capacité offre une redondance accrue, de meilleures options de reprise après sinistre et des avantages en termes de performances et d'économies.

La première étape pour configurer la "panne du centre de données - sauvegarde de preuve" consiste à fournir des informations d'identification à votre opérateur cloud. Vous pouvez choisir parmi plusieurs fournisseurs ici. Jetons un coup d'œil au processus mis en place pour l'opérateur cloud le plus populaire :AWS.

Tout ce dont vous avez besoin est l'AWS Key ID et le secret de la région où vous souhaitez stocker votre sauvegarde. Vous pouvez l'obtenir à partir de la console AWS. Vous pouvez suivre quelques étapes pour l'obtenir.

1. Utilisez l'adresse e-mail et le mot de passe de votre compte AWS pour vous connecter à AWS Management Console en tant qu'utilisateur racine du compte AWS.
2. Sur la page IAM Dashboard, choisissez le nom de votre compte dans la barre de navigation, puis sélectionnez Mes informations d'identification de sécurité .
3. Si vous voyez un avertissement concernant l'accès aux informations d'identification de sécurité pour votre compte AWS, choisissez de Continuer vers les informations d'identification de sécurité .
4. Développez la section Clés d'accès (ID de clé d'accès et clé d'accès secrète).
5. Choisir de Créer une nouvelle clé d'accès . Choisissez ensuite Télécharger le fichier clé pour enregistrer l'ID de la clé d'accès et la clé d'accès secrète dans un fichier sur votre ordinateur. Après avoir fermé la boîte de dialogue, vous ne pourrez plus récupérer cette clé d'accès secrète.

Lorsque tout est défini, vous pouvez ajuster votre calendrier de sauvegarde et activer l'option de sauvegarde vers le cloud. Pour réduire le trafic réseau, assurez-vous d'activer la compression des données. Cela rend les sauvegardes plus petites et minimise le temps nécessaire au téléchargement. Une autre bonne pratique consiste à chiffrer la sauvegarde. ClusterControl crée automatiquement une clé et l'utilise si vous décidez de la restaurer. Les politiques de sauvegarde avancées doivent avoir des durées de conservation différentes pour les sauvegardes stockées sur des serveurs dans le même centre de données et les sauvegardes stockées dans un autre emplacement physique. Vous devez définir une période de rétention plus longue pour les sauvegardes basées sur le cloud et une période plus courte pour les sauvegardes stockées à proximité de l'environnement de production, car la probabilité de restauration diminue avec la durée de vie de la sauvegarde.

Étendez votre cluster avec la réplication asynchrone

Galera avec réplication asynchrone peut être une excellente solution pour créer un nœud DR actif dans un centre de données distant. Il y a quelques bonnes raisons d'attacher un esclave asynchrone à un cluster Galera. Les requêtes de type OLAP de longue durée sur un nœud Galera peuvent ralentir tout un cluster. Avec l'option d'application différée, la réplication différée peut vous éviter des erreurs humaines afin que toutes ces entrées en or ne soient pas immédiatement appliquées à votre nœud de sauvegarde.

Dans ClusterControl, l'extension d'un groupe de nœuds Galera avec une réplication asynchrone se fait dans un assistant d'une seule page. Vous devez fournir les informations nécessaires sur votre futur serveur esclave ou existant. L'esclave sera configuré à partir d'une sauvegarde existante ou d'un XtraBackup fraîchement diffusé du maître vers l'esclave.

Équilibreurs de charge dans plusieurs centres de données

Les équilibreurs de charge sont un composant crucial de la haute disponibilité des bases de données MySQL et MariaDB. Il ne suffit pas d'avoir un cluster couvrant plusieurs centres de données. Vous avez toujours besoin de vos services pour y accéder. Une défaillance d'un équilibreur de charge disponible dans un centre de données rendra tout votre environnement inaccessible.

L'une des méthodes les plus courantes pour masquer la complexité de la couche de base de données d'une application consiste à utiliser un proxy. Les proxys agissent comme un point d'entrée vers les bases de données, ils suivent l'état des nœuds de la base de données et doivent toujours diriger le trafic uniquement vers les nœuds disponibles. ClusterControl facilite le déploiement et la configuration de plusieurs technologies d'équilibrage de charge différentes pour MySQL et MariaDB, y compris ProxySQL, HAProxy, avec une interface graphique pointer-cliquer.

Cela permet également de rendre ce composant redondant en ajoutant keepalived par-dessus. Pour éviter que vos équilibreurs de charge ne soient un point de défaillance unique, configurez deux instances HAProxy, ProxySQL ou MariaDB Maxscale identiques (une active et une dans un DC différent en veille) et utilisez Keepalived pour exécuter le protocole VRRP (Virtual Router Redundancy Protocol) entre eux. VRRP fournit une adresse IP virtuelle à l'équilibreur de charge actif et transfère l'adresse IP virtuelle au HAProxy de secours en cas de panne. C'est transparent car les deux instances de proxy n'ont pas besoin d'état partagé.

Bien sûr, il y a de nombreux éléments à prendre en compte pour rendre vos bases de données à l'abri des défaillances du centre de données.
Une planification et une automatisation appropriées permettront de le faire fonctionner ! Bonne création de cluster !