L'exécution d'un cluster MySQL Galera (qu'il s'agisse de la version Percona, MariaDB ou Codership) n'est malheureusement pas prise en charge (ni ne fait partie) des bases de données prises en charge par Amazon RDS. La plupart des bases de données prises en charge par RDS utilisent la réplication asynchrone, tandis que Galera Cluster est une solution de réplication multimaître synchrone. Galera nécessite également InnoDB comme moteur de stockage pour fonctionner correctement, et bien que vous puissiez utiliser d'autres moteurs de stockage tels que MyISAM, il n'est pas conseillé d'utiliser ce moteur de stockage en raison du manque de gestion des transactions.
En raison du manque de support natif dans RDS, ce blog se concentrera sur les offres disponibles lors du choix et de l'hébergement de votre cluster basé sur Galera à l'aide d'un environnement AWS.
Il y a certainement de nombreuses raisons pour lesquelles vous choisiriez ou non la plate-forme cloud AWS, mais pour ce sujet particulier, nous allons passer en revue les avantages et les avantages de ce que vous pouvez exploiter plutôt que les raisons pour lesquelles vous choisirait la plate-forme AWS.
Les serveurs virtuels (instances Elastic Compute)
Comme mentionné précédemment, MySQL Galera ne fait pas partie de RDS et InnoDB est un moteur de stockage transactionnel pour lequel vous avez besoin des bonnes ressources pour les besoins de votre application. Il doit avoir la capacité de répondre à la demande du trafic de demandes de votre client. Au moment de cet article, votre seul choix pour exécuter Galera Cluster est d'utiliser EC2, l'offre cloud d'instance de calcul d'Amazon.
Parce que vous avez l'avantage d'exécuter votre système sur un certain nombre de nœuds sur des instances EC2, l'exécution d'un cluster Galera sur EC2 et sur site ne diffère pas beaucoup. Vous pouvez accéder au serveur à distance via SSH, installer les packages logiciels souhaités et choisir le type de version de Galera Cluster que vous souhaitez utiliser.
De plus, avec EC2, cette offre est plus élastique et flexible, ce qui vous permet de fournir et d'offrir une configuration plus simple et granulaire. Vous pouvez tirer parti des services Web pour automatiser ou créer un certain nombre de nœuds si vous avez besoin de faire évoluer votre environnement ou, par exemple, d'automatiser la création de votre environnement intermédiaire ou de développement. Il vous donne également un avantage pour créer rapidement l'environnement souhaité, choisir et configurer le système d'exploitation souhaité et sélectionner les ressources informatiques adaptées à vos besoins (telles que le processeur, la mémoire et le stockage sur disque). EC2 élimine le temps d'attente pour le matériel , puisque vous pouvez le faire à la volée. Vous pouvez également tirer parti de leur outil AWS CLI pour automatiser la configuration de votre cluster Galera.
Tarification des instances Amazon EC2
EC2 propose un certain nombre de sélections très flexibles pour les consommateurs qui souhaitent héberger leur environnement Galera Cluster sur des nœuds de calcul AWS. L'offre gratuite d'AWS comprend 750 heures d'instances Linux et Windows t2.micro, chaque mois, pendant un an. Vous pouvez rester dans le niveau gratuit en utilisant uniquement des instances EC2 Micro, mais ce n'est peut-être pas la meilleure chose à faire pour une utilisation en production.
Il existe plusieurs types d'instances EC2 pour lesquelles vous pouvez déployer lors du provisionnement de vos nœuds Galera. Idéalement, ces familles r4/r5/x1 (mémoire optimisée) et famille c4/c5 (calcul optimisé) sont un choix idéal, et ces prix diffèrent en fonction de l'importance de vos besoins en ressources de serveur et du type de système d'exploitation.
Ce sont les types d'instances payantes que vous pouvez choisir...
Sur demande
Le paiement en fonction de la capacité de calcul (par heure ou par seconde) dépend du type d'instances que vous exécutez. Par exemple, les prix peuvent différer lors du provisionnement d'une instance Ubuntu par rapport à une instance RHEL en dehors du type d'instance. Il n'a pas d'engagements à long terme ni de paiements initiaux nécessaires. Il a également la possibilité d'augmenter ou de diminuer votre capacité de calcul. Ces instances sont recommandées pour les besoins d'environnement peu coûteux et flexibles, comme les applications avec des charges de travail à court terme, ponctuelles ou imprévisibles qui ne peuvent pas être interrompues, ou les applications développées ou testées sur Amazon EC2 pour la première fois. Consultez-le ici pour plus d'informations.
Hôtes dédiés
Si vous recherchez des exigences de conformité et de réglementation telles que la nécessité d'acquérir un serveur dédié qui s'exécute sur un matériel dédié à l'utilisation, ce type d'offre répond à vos besoins. Les hôtes dédiés peuvent vous aider à répondre aux exigences de conformité et à réduire les coûts en vous permettant d'utiliser votre licence logicielle existante liée au serveur, y compris Windows Server, SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux ou d'autres licences logicielles liées aux machines virtuelles. , sockets ou cœurs physiques, sous réserve des conditions de votre licence. Il peut être acheté à la demande (horaire) ou sous forme de réservation jusqu'à 70 % de réduction sur le prix à la demande. Consultez-le ici pour plus d'informations.
Instances ponctuelles
Ces instances vous permettent de demander une capacité de calcul Amazon EC2 disponible jusqu'à 90 % de réduction sur le prix à la demande. Ceci est recommandé pour les applications qui ont des heures de début et de fin flexibles, les applications qui ne sont réalisables qu'à des prix de calcul très bas ou les utilisateurs ayant des besoins informatiques urgents pour de grandes quantités de capacité supplémentaire. Consultez-le ici pour plus d'informations.
Instances réservées
Ce type d'offre de paiement vous offre la possibilité de bénéficier d'une remise allant jusqu'à 75 % et, selon l'instance que vous souhaitez réserver, vous pouvez acquérir une réservation de capacité vous donnant une confiance supplémentaire dans vos capacités pour lancer des instances lorsque vous en avez besoin. Ceci est recommandé si vos applications ont une utilisation stable ou prévisible, des applications qui peuvent nécessiter une capacité réservée ou des clients qui peuvent s'engager à utiliser EC2 sur une durée de 1 ou 3 ans pour réduire leurs coûts informatiques totaux. Consultez-le ici pour plus d'informations.
Remarque sur les prix
Une dernière chose avec EC2, ils offrent également une facturation à la seconde qui prend également le coût des minutes et secondes inutilisées en une heure sur la facture. Ceci est avantageux si vous effectuez une montée en charge pendant une durée minimale, uniquement pour gérer la demande de trafic d'un nœud Galera ou si vous souhaitez essayer et tester sur un nœud spécifique pour une utilisation limitée dans le temps.
Chiffrement de la base de données sur AWS
Si vous êtes préoccupé par la confidentialité de vos données ou par le respect des lois requises pour votre conformité et vos réglementations en matière de sécurité, AWS propose le chiffrement des données au repos. Si vous utilisez MariaDB Cluster version 10.2+, ils disposent d'un support de plug-in intégré pour s'interfacer avec l'API Amazon Web Services (AWS) Key Management Service (KMS). Cela vous permet de tirer parti du service de gestion des clés AWS-KMS pour faciliter la séparation des responsabilités et la journalisation et l'audit à distance des demandes d'accès aux clés. Plutôt que de stocker la clé de chiffrement dans un fichier local, ce plug-in conserve la clé principale dans AWS KMS.
Lorsque vous démarrez MariaDB pour la première fois, le plug-in AWS KMS se connecte à AWS Key Management Service et lui demande de générer une nouvelle clé. MariaDB stockera cette clé sur disque sous une forme cryptée. La clé stockée sur disque ne peut pas être utilisée pour déchiffrer les données; à la place, à chaque démarrage, MariaDB se connecte à AWS KMS et demande au service de déchiffrer la ou les clés stockées localement. La clé déchiffrée est stockée en mémoire tant que le processus du serveur MariaDB est en cours d'exécution, et cette clé déchiffrée en mémoire est utilisée pour chiffrer les données locales.
Alternativement, lors du déploiement de vos instances EC2, vous pouvez chiffrer votre volume de stockage de données avec EBS (Elastic Block Storage) ou chiffrer l'instance elle-même. Le chiffrement pour les volumes de type EBS est tous pris en charge, même s'il peut avoir un impact, mais la latence est très minime, voire invisible pour les utilisateurs finaux. Pour le chiffrement de type instance EC2, la plupart des grandes instances sont prises en charge. Ainsi, si vous utilisez des nœuds de calcul ou de mémoire optimisés, vous pouvez tirer parti de son chiffrement.
Vous trouverez ci-dessous la liste des types d'instances pris en charge...
- Usage général :A1, M3, M4, M5, M5a, M5ad, M5d, T2, T3 et T3a
- Optimisation du calcul :C3, C4, C5, C5d et C5n
- Mémoire optimisée :cr1.8xlarge, R3, R4, R5, R5a, R5ad, R5d, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, X1, X1e et z1d
- Stockage optimisé :D2, h1.2xlarge, h1.4xlarge, I2 et I3
- Calcul accéléré :F1, G2, G3, P2 et P3
Vous pouvez configurer votre compte AWS pour toujours activer le chiffrement lors du déploiement de vos instances de type EC2. Cela signifie qu'AWS chiffrera les nouveaux volumes EBS au lancement et chiffrera les nouvelles copies des instantanés non chiffrés.
Déploiements multi-AZ/multi-régions/multi-cloud
Malheureusement, au moment d'écrire ces lignes, il n'y a pas de prise en charge directe de ce type dans la console AWS (ni aucune de leurs API AWS) qui prend en charge les déploiements Multi-AZ/-Region/-Cloud pour les clusters de nœuds Galera.
Haute disponibilité, évolutivité et redondance
Pour réaliser un déploiement multi-AZ, il est recommandé de provisionner vos nœuds galera dans différentes zones de disponibilité. Cela empêche le cluster de tomber en panne ou un dysfonctionnement du cluster en raison d'un manque de quorum.
Vous pouvez également configurer un AWS Auto Scaling et créer un groupe de mise à l'échelle automatique pour surveiller et effectuer des vérifications d'état afin que votre cluster soit toujours redondant, évolutif et hautement disponible. Auto Scaling devrait résoudre votre problème dans le cas où votre nœud tomberait en panne pour une raison inconnue.
Pour un déploiement multirégional ou multicloud, Galera a son propre paramètre appelé gmcast.segment pour lequel vous pouvez le définir au démarrage du serveur. Ce paramètre est conçu pour optimiser la communication entre les nœuds Galera et minimiser la quantité de trafic envoyé entre les segments de réseau, y compris le relais d'écriture et la sélection des donneurs IST et SST.
Ce type de configuration vous permet de déployer plusieurs nœuds dans différentes régions pour votre cluster Galera. En plus de cela, vous pouvez également déployer vos nœuds Galera sur un autre fournisseur, par exemple s'il est hébergé sur Google Cloud et que vous souhaitez une redondance sur Microsoft Azure.
Je vous recommande de consulter notre blog Multiple Data Center Setups Using Galera Cluster for MySQL or MariaDB and Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node pour recueillir plus d'informations sur la façon d'implémenter ces types de déploiements.
Performances de la base de données sur AWS
En fonction de la demande de votre application, si vos requêtes consomment de la mémoire, les instances optimisées en mémoire sont votre choix idéal. Si votre application comporte des transactions plus élevées qui nécessitent des performances élevées pour les serveurs Web ou le traitement par lots, choisissez des instances optimisées pour le calcul. Si vous souhaitez en savoir plus sur l'optimisation de votre cluster Galera, vous pouvez consulter ce blog Comment améliorer les performances du cluster Galera pour MySQL ou MariaDB.
Sauvegardes de bases de données sur AWS
La création de sauvegardes peut être difficile car il n'y a pas de support direct au sein d'AWS qui soit spécifique à la technologie MySQL Galera. Cependant, AWS vous fournit une solution en cas de sinistre et de récupération à l'aide d'instantanés EBS. Vous pouvez prendre des instantanés des volumes EBS attachés à votre instance, puis effectuer une sauvegarde planifiée à l'aide de CloudWatch ou en utilisant Amazon Data Lifecycle Manager (Amazon DLM) pour automatiser les instantanés.
Notez que les instantanés pris sont des sauvegardes incrémentielles, ce qui signifie que seuls les blocs de l'appareil qui ont changé après votre instantané le plus récent sont enregistrés. Vous pouvez stocker ces instantanés sur AWS S3 pour réduire les coûts de stockage. Vous pouvez également utiliser des outils externes tels que Percona Xtrabackup et Mydumper (pour les sauvegardes logiques) et les stocker dans AWS EFS -> AWS S3 -> AWS Glacier.
Vous pouvez également configurer la gestion du cycle de vie dans AWS si vous avez besoin que vos données de sauvegarde soient stockées de manière plus rentable. Si vous avez des fichiers volumineux et que vous allez utiliser AWS EFS, vous pouvez tirer parti de leur solution AWS Backup, car il s'agit également d'une solution simple mais économique.
D'autre part, vous pouvez également utiliser des services externes (ainsi que ClusterControl) qui vous fournissent à la fois des solutions de surveillance et de sauvegarde. Consultez ceci si vous voulez en savoir plus.
Surveillance de base de données sur AWS
AWS propose des vérifications de l'état et certaines vérifications d'état pour vous offrir une visibilité sur vos nœuds Galera. Cela se fait via CloudWatch et CloudTrail.
CloudTrail vous permet d'activer et d'inspecter les journaux et d'effectuer des audits en fonction des actions et des traces qui ont été effectuées.
CloudWatch vous permet de collecter et de suivre des métriques, de collecter et de surveiller des fichiers journaux et de définir des alarmes personnalisées. Vous pouvez le configurer en fonction de vos besoins personnalisés et obtenir une visibilité à l'échelle du système sur l'utilisation des ressources, les performances des applications et la santé opérationnelle. CloudWatch est livré avec un niveau gratuit tant que vous restez dans ses limites (voir la capture d'écran ci-dessous.)
CloudWatch est également proposé avec un prix en fonction du volume de métriques distribuées. Découvrez son prix actuel en vérifiant ici.
Remarque :il y a un inconvénient à utiliser CloudWatch. Il n'est pas conçu pour répondre à la santé de la base de données, en particulier pour la surveillance des nœuds de cluster MySQL Galera. Alternativement, vous pouvez utiliser des outils externes qui offrent des graphiques ou des diagrammes haute résolution qui sont utiles dans les rapports et sont plus faciles à analyser lors du diagnostic d'un nœud problématique.
Pour cela, vous pouvez utiliser PMM de Percona, DataDog, Idera, VividCortex ou notre propre ClusterControl (car la surveillance est GRATUITE avec ClusterControl Community.) Je vous recommande d'utiliser un outil de surveillance qui convient à votre besoins en fonction des exigences de votre application individuelle. Il est très important que votre outil de surveillance puisse vous avertir de manière agressive ou vous fournir une intégration pour les systèmes de messagerie instantanée tels que Slack, PagerDuty ou même vous envoyer des SMS en cas d'état de santé grave.
Sécurité des bases de données sur AWS
La sécurisation de vos instances EC2 est l'une des parties les plus vitales du déploiement de votre base de données dans le cloud public. Vous pouvez configurer un sous-réseau privé et configurer les groupes de sécurité requis uniquement pour autoriser le port ou l'adresse IP source en fonction de votre configuration. Vous pouvez définir vos nœuds de base de données avec un accès non distant et simplement configurer un hôte de saut ou une passerelle Internet, si les nœuds nécessitent d'accéder à Internet pour accéder ou mettre à jour les packages logiciels. Vous pouvez lire notre blog précédent Déploiement de la réplication MySQL multicloud sécurisée sur AWS et GCP avec VPN sur la façon dont nous avons configuré cela.
En plus de cela, vous pouvez sécuriser vos données en transit en utilisant une connexion TLS/SSL ou crypter vos données lorsqu'elles sont au repos. Si vous utilisez ClusterControl, le déploiement d'un transfert de données sécurisé est simple et facile. Vous pouvez consulter notre blog SSL Key Management and Encryption of MySQL Data in Transit si vous souhaitez essayer. Pour les données au repos, le stockage de vos données via S3 peut être chiffré à l'aide d'AWS Server-Side Encryption ou d'AWS-KMS dont j'ai parlé plus tôt. Consultez ce blog externe pour savoir comment configurer et exploiter un cluster MariaDB à l'aide d'AWS-KMS afin de pouvoir stocker vos données au repos en toute sécurité.
Dépannage du cluster Galera sur AWS
AWS CloudWatch peut être particulièrement utile lors de l'examen et de la vérification des métriques système. Vous pouvez vérifier le réseau, le processeur, la mémoire, le disque, ainsi que l'utilisation et l'équilibre de l'instance ou du calcul. Cependant, cela pourrait ne pas répondre à vos exigences lorsque vous creusez dans un cas spécifique.
CloudTrail peut effectuer des traces solides des actions qui ont été régies en fonction de votre compte AWS spécifique. Cela vous aidera à déterminer si les occurrences ne proviennent pas de MySQL Galera, mais peuvent être des bogues ou des problèmes dans l'environnement AWS (par exemple, Hyper-V rencontre des problèmes au sein de la machine hôte sur laquelle votre instance, en tant qu'invité, est hébergé.)
Si vous utilisez ClusterControl, allez dans Journaux -> Journaux système, vous pourrez parcourir les journaux d'erreurs capturés provenant du nœud MySQL Galera lui-même. En dehors de cela, ClusterControl fournit une surveillance en temps réel qui amplifie votre système d'alarme et de notification en cas d'urgence ou si votre ou vos nœuds MySQL Galera sont en panne.
Conclusion
AWS n'a pas de support pur pour une configuration MySQL Galera Cluster, contrairement à AWS RDS qui a une compatibilité MySQL. Pour cette raison, la plupart des recommandations ou opinions concernant l'utilisation d'un cluster Galera pour une utilisation en production dans l'environnement AWS sont basées sur des environnements expérimentés et bien testés qui fonctionnent depuis très longtemps.
MariaDB Cluster est livré avec une grande productivité, car ils fournissent constamment un support concis pour la solution de pile technologique AWS. Dans la prochaine version de la version 10.5 de MariaDB, ils offriront un support pour le moteur de stockage S3, ce qui peut valoir la peine d'attendre.
Des outils externes peuvent vous aider à gérer et à contrôler votre cluster MySQL Galera exécuté sur le cloud AWS. Ce n'est donc pas un gros problème si vous avez des dilemmes et des FUD sur les raisons pour lesquelles vous devriez exécuter ou passer au cloud AWS. Plate-forme.
AWS n'est peut-être pas la solution unique dans certains cas, mais il fournit un large éventail de solutions que vous pouvez personnaliser et adapter à vos besoins.
Dans la prochaine partie de notre blog, nous examinerons une autre plate-forme de cloud public, en particulier Google Cloud, et verrons comment nous pouvons en tirer parti si nous choisissons d'exécuter notre cluster Galera sur leur plate-forme.
