Vous cherchez à démarrer avec la base de données open source la plus populaire au monde et vous vous demandez comment configurer votre hébergement MySQL ? Beaucoup utilisent par défaut Amazon RDS, alors que MySQL fonctionne exceptionnellement bien sur Azure Cloud. Bien que Microsoft Azure propose une solution gérée, Azure Database, la solution présente des limitations majeures que vous devez connaître avant de migrer vos déploiements MySQL. Dans cet article, nous décrivons la meilleure façon d'héberger MySQL sur Azure, y compris les solutions gérées, les types d'instance, la réplication haute disponibilité, la sauvegarde et les types de disque à utiliser pour optimiser les performances de votre base de données cloud.
MySQL DBaaS vs MySQL autogéré
La première chose à considérer lorsque vous pesez entre l'autogestion et une solution MySQL Database-as-a-Service (DBaaS) est les ressources internes dont vous disposez. Si vous lisez ceci, vous connaissez probablement déjà l'ampleur des tâches opérationnelles associées au maintien d'un déploiement de production, mais pour un bref récapitulatif, il y a le provisionnement, le déprovisionnement, les configurations maître-esclave, les sauvegardes, la mise à l'échelle, les mises à niveau, les rotations de journaux, les correctifs du système d'exploitation. , et la surveillance pour n'en nommer que quelques-uns.
Un expert MySQL interne, ou une équipe de DBA selon la taille de votre application, peut certainement les gérer avec votre organisation pour vous, mais la question est de savoir où vous voulez que les efforts de votre équipe se concentrent . Beaucoup décident de passer à un DBaaS MySQL pour automatiser ces tâches chronophages afin de pouvoir se concentrer davantage sur le développement et l'optimisation de leurs bases de données d'applications. Un bon exemple serait l'analyse lente des requêtes. Bien que presque tous les DBaaS proposent un outil d'analyse de requêtes lentes MySQL pour aider à identifier les requêtes problématiques, cette tâche nécessite toujours des compétences humaines et de l'intuition pour déterminer comment optimiser les requêtes ayant un impact sur les performances de leur application.
Que vous soyez une start-up ou une entreprise Fortune 500, vous constaterez que de nombreuses organisations choisissent de tirer parti d'un DBaaS pour optimiser le temps de leur DBA, tandis que les mêmes types et tailles d'entreprises également choisir de s'en tenir à l'autogestion interne. Pour de nombreuses entreprises, la décision se résume en grande partie à la personnalisation et au contrôle. C'est pourquoi nous mettons en garde contre l'utilisation par défaut d'Azure Database, ou de son concurrent AWS, Amazon RDS, car ils ne vous permettent pas de conserver l'accès superutilisateur MySQL ni même l'accès SSH à vos machines. De plus, la possibilité de personnaliser la configuration de votre déploiement est très limitée, comme les types d'instance, la RAM, la taille du disque ou les IOPS que vous pouvez utiliser. Vous en apprendrez plus sur les meilleurs types d'instance et les meilleurs disques à utiliser ci-dessous, et vous pouvez consulter cette comparaison des fournisseurs MySQL pour voir les avantages et les limites des quatre principales solutions MySQL gérées, ScaleGrid, Compose, Azure Database et Amazon RDS.
Déploiement haute disponibilité
Si vous déployez en production, vous devez toujours configurer MySQL en tant que déploiement maître-esclave. Les déploiements autonomes sont un nœud unique sans aucune réplication et ne doivent vraiment être utilisés que pour des environnements de développement ou de test. Avec les déploiements maître-esclave, vous pouvez configurer la haute disponibilité. Ainsi, si l'un de vos nœuds tombe en panne, vous pouvez basculer vers un esclave sans aucun temps d'arrêt. Ceci est généralement configuré soit comme un maître-esclave-esclave à 3 nœuds, soit comme un quorum maître-esclave à 2 + 1 nœuds. L'avantage d'utiliser un quorum est qu'il s'agit d'une alternative moins coûteuse, mais l'inconvénient est que vous n'avez que 2 nœuds porteurs de données, l'autre agissant comme un nœud de quorum pour déterminer le meilleur cours de basculement. Si votre application est capable de lire à partir de l'esclave, vous devez effectuer une mise à l'échelle de la lecture afin qu'elle renvoie les mêmes données à partir du volume du cluster avec un décalage minimal.
La meilleure façon d'héberger MySQL sur Azure CloudCliquez pour tweeter
Lorsque vous utilisez une configuration maître-esclave MySQL, nous vous recommandons de configurer une réplication semi-synchrone pour améliorer l'intégrité de vos données grâce à la redondance des données. Cela garantit que lorsqu'un commit revient avec succès, les données existent à la fois dans le maître et l'esclave, donc en cas de panne d'un centre de données, votre maître MySQL peut basculer vers un esclave sans aucune perte de données. Vous pouvez le faire avec une réplication asynchrone ou semi-synchrone, et apprenez-en plus à ce sujet dans notre article de blog MySQL High Availability Explained - Part II.
Alors, comment configurer la haute disponibilité pour MySQL sur Azure ? Nous devons répartir nos instances esclaves sur différentes zones de disponibilité Azure (AZ). Donc, nous voulons nous assurer que nous choisissons une région Azure qui a au moins 3 AZ, en plaçant chaque instance dans une AZ différente. Nous procédons ainsi parce que les garanties de disponibilité s'appliquent à travers les AZ, donc si 1 zone tombe en panne, votre base de données d'application peut toujours rester en ligne via les 2 autres AZ. Les zones de disponibilité sont assez nouvelles pour Azure, donc si vous travaillez dans une région qui n'offre pas d'AZ, vous avez la possibilité d'utiliser des ensembles de disponibilité. Celles-ci sont légèrement plus faibles que celles d'AZ, mais assurez-vous que vous êtes déployé sur différents domaines et racks pour vous protéger contre une panne potentielle. Il existe également la possibilité de déployer dans plusieurs régions, mais il s'agit d'une configuration plus compliquée. Nous vous recommandons donc de vous contacter pour en discuter avant la mise en œuvre.
Réseaux virtuels Azure
La meilleure façon de protéger votre base de données d'Internet consiste à la déployer dans un sous-réseau privé pour vous assurer qu'elle n'est pas exposée. Azure facilite cette configuration grâce à l'utilisation d'un réseau virtuel (VNET) qui peut être configuré pour vos serveurs MySQL. Avec un VNET Azure pour MySQL, vous pouvez configurer des communications sécurisées entre vos serveurs, Internet et même votre réseau cloud privé sur site. Ceux-ci sont généralement configurés pour communiquer sur un seul réseau, mais si vous devez connecter plusieurs régions, vous pouvez créer plusieurs réseaux virtuels pour communiquer via l'appairage de réseaux virtuels.
De plus, vous pouvez gérer votre contrôle d'accès MySQL via les règles des groupes de sécurité réseau (NSG) sans avoir à gérer les listes blanches d'adresses IP. Ceci n'est pas disponible via Azure Database pour MySQL, mais VNET et NSG peuvent être configurés via nos plans MySQL Bring Your Own Cloud (BYOC) sur Azure où vous pouvez héberger vos clusters via votre propre compte cloud.
Types d'instances Azure
Un autre aspect important à prendre en compte est la performance de vos instances MySQL dans le cloud public. Le cloud Azure propose plusieurs types d'instances pouvant être utilisées pour votre hébergement MySQL, notamment Es2 v3, Ds2, v2 et Ls4.
Nous vous recommandons de commencer avec un type d'instance à mémoire optimisée, car les bases de données nécessitent beaucoup de RAM et recherchent la vitesse de disque la plus rapide possible pour les meilleures performances. La série Es2 est généralement un bon point de départ pour la plupart des charges de travail MySQL des applications. À partir de là, vous pouvez effectuer des tests de performances pour voir si vous avez besoin de plus de CPU, auquel cas des types d'instances équilibrés ou des types d'instances gourmands en CPU pourraient mieux répondre à vos besoins MySQL, tels que les types d'instance Dv3. Vos tests de performances peuvent également montrer que vous avez besoin de plus d'E/S (entrée/sortie), vous pouvez passer à un type d'instance gourmand en disque.
Si vous envisagez d'utiliser Azure comme fournisseur de cloud MySQL pour les 1 à 3 prochaines années et de maintenir des configurations de déploiement assez cohérentes, vous pouvez également envisager des instances réservées. Ce sont essentiellement des instances prépayées qui vous permettent de réaliser des économies considérables pour votre hébergement MySQL. En moyenne, vous pouvez économiser environ 20 % à 30 % pour les instances réservées d'un an et 40 % à 50 % sur les instances réservées de 3 ans.
Types de disques Azure
La première décision que vous devez prendre lorsqu'il s'agit de choisir un type de disque Azure pour vos déploiements MySQL est de savoir s'il faut opter pour un disque géré ou non géré. Les disques non gérés sont les disques hérités proposés par Azure où vous devez configurer le compte de stockage, mapper votre disque au compte de stockage et surveiller l'utilisation et les limites d'IOPS pour ce compte de stockage. Nous vous recommandons fortement d'utiliser des disques gérés, et si vous déployez toujours avec des disques non gérés, vous devriez envisager de passer aux disques gérés.
Environnements de développement/test MySQL :disques standard
Plusieurs types de disques gérés sont disponibles via Azure, la valeur par défaut étant les disques standard. Les disques standard peuvent prendre en charge jusqu'à 500 IOPS (opérations d'entrée/sortie par seconde) et conviennent aux opérations de développement et de test car ils peuvent être redimensionnés de manière dynamique, mais ne doivent pas être utilisés pour les déploiements de production MySQL.
Déploiements de production MySQL :disques Premium
Pour vos serveurs de production MySQL, nous vous recommandons vivement d'utiliser les disques premium Azure. Il existe une grande variété de disques premium parmi lesquels vous pouvez choisir. Pour chaque disque premium, vous pouvez choisir la meilleure taille, et chaque taille est livrée avec différentes IOPS provisionnées afin que vous puissiez sélectionner celle qui correspond le mieux aux besoins de votre application.
Déploiements de production MySQL :SSD local
Les SSD locaux Azure sont une alternative hautes performances aux disques premium, généralement mieux adaptés aux grands clusters. Les SSD locaux offrent des performances d'E/S beaucoup plus élevées et le meilleur débit d'Azure. Mais, ils ont un inconvénient en ce qu'ils sont des disques éphémères, pas un magasin permanent, donc si vous arrêtez l'instance, les données disparaissent. Nous recommandons la série Ls v2 qui est très rapide, mais attention, le processeur est vraiment faible, ce qui peut provoquer des goulots d'étranglement de la machine.
Sauvegardes MySQL sur Azure
La meilleure façon de sauvegarder vos données MySQL sur Azure consiste à utiliser des instantanés de disque gérés. Un instantané est une version ponctuelle en lecture seule d'un disque. Ces sauvegardes peuvent être lues, copiées ou supprimées, mais notez qu'elles ne peuvent pas être modifiées. C'est une bonne idée d'effectuer des sauvegardes complètes afin que toutes vos bases de données, utilisateurs et paramètres soient sauvegardés sur l'instance au cas où vous auriez besoin de récupérer une base de données MySQL. C'est également une bonne idée de chiffrer vos instantanés de sauvegarde afin que la sauvegarde ne puisse être restaurée que sur la machine sur laquelle la sauvegarde a été effectuée.
Vos sauvegardes MySQL entraîneront des frais de stockage de données Azure supplémentaires, sauf si vous utilisez une solution MySQL sur Azure tout compris comme nos plans d'hébergement dédié chez ScaleGrid. Afin de contrôler les coûts, il est judicieux d'automatiser vos sauvegardes grâce à une planification personnalisable qui vous permet de configurer la fréquence de vos sauvegardes, le nombre maximal de sauvegardes à conserver et votre cible de sauvegarde. Bien sûr, cela vous aide également à vous assurer que vos données MySQL sont régulièrement sauvegardées en cas de perte de données dans votre déploiement de production afin que vous puissiez récupérer rapidement avec une sauvegarde récente.
Si vous avez des questions sur la meilleure façon d'héberger MySQL sur Azure, laissez-nous un commentaire ci-dessous ou contactez-nous à support@scalegrid. io. Vous pouvez également commencer un essai gratuit de 30 jours pour découvrir les avantages d'un service MySQL entièrement géré pour améliorer les performances de vos déploiements.
