Niveaux de service d’Azure Database pour MySQL - Serveur flexible
S’APPLIQUE À :
Azure Database pour MySQL - Serveur flexible
Vous pouvez créer une instance de serveur flexible Azure Database pour MySQL dans l’un des trois différents niveaux de service : Burstable, Usage général et Critique pour l’entreprise. Les niveaux de service sont différenciés par les références de machine virtuelle sous-jacentes utilisées : série B, série D et série E. Le choix du niveau de calcul et de la taille détermine la mémoire et les vCores disponibles sur le serveur. La même technologie de stockage est utilisée sur tous les niveaux de service. Toutes les ressources sont approvisionnées au niveau de l’instance de serveur flexible Azure Database pour MySQL. Un serveur peut avoir une ou plusieurs bases de données.
| Ressource/Niveau | Expansible | Usage général | Critique pour l’entreprise |
|---|---|---|---|
| Série de la machine virtuelle | Série B | Dadsv5-seriesDdsv4-series | Edsv4/Edsv5-series*/Eadsv5-series |
| vCores | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Mémoire par vCore | Variable | 4 Gio | 8 Gio ** |
| Taille de stockage | De 20 Gio à 16 Tio | De 20 Gio à 16 Tio | De 20 Gio à 16 Tio |
| Période de rétention de sauvegarde de bases de données | 1 à 35 jours | 1 à 35 jours | 1 à 35 jours |
** À l’exception de 64, 80 et 96 vCores, qui disposent respectivement de 504, 504 et 672 Gio de mémoire.
* La capacité de calcul Ev5 offre les meilleures performances parmi les autres séries de machines virtuelles en termes de QPS et de latence. Découvrez plus d’informations sur les performances et la disponibilité régionale de la capacité de calcul Ev5 ici.
Pour choisir un niveau de calcul, utilisez le tableau suivant comme point de départ.
| Niveau de calcul | Charges de travail cibles |
|---|---|
| Expansible | Idéal pour les charges de travail qui n’ont pas besoin de l’UC complète en permanence. |
| Usage général | La plupart des charges de travail professionnelles qui nécessitent une capacité de calcul et de mémoire équilibrée avec un débit d’E/S extensible. Il s’agit, par exemple, de serveurs destinés à l’hébergement d’applications web et mobiles, ainsi que d’autres applications d’entreprise. |
| Critique pour l’entreprise | Charges de travail de base de données haute performance qui nécessitent des performances en mémoire suffisantes pour un traitement plus rapide des transactions et une simultanéité plus élevée. Il s’agit, par exemple, de serveurs destinés au traitement de données en temps réel et à des applications transactionnelles ou analytiques haute performance. |
Une fois que vous avez créé un serveur, le niveau de calcul, la taille de calcul et la taille de stockage peuvent être modifiés. La mise à l’échelle du calcul requiert un redémarrage et prend entre 60 et 120 secondes, alors que la mise à l’échelle du stockage ne nécessite pas de redémarrage. Vous pouvez également augmenter ou réduire la période de rétention de sauvegarde de manière indépendante. Pour plus d’informations, consultez la section Ressources de mise à l’échelle.
Niveaux de service, tailles et types de serveurs
Les ressources de calcul peuvent être sélectionnées en fonction du niveau et de la taille. Cela détermine les vCores et la taille de la mémoire. Les vCores représentent le processeur logique du matériel sous-jacent.
Les spécifications détaillées des types de serveurs disponibles sont les suivantes :
| Taille de calcul | vCores | Taille de la mémoire (Gio) | Nombre maximal d’E/S par seconde pris en charge | Nombre maximal de connexions | Stockage temporaire (SSD) en Gio |
|---|---|---|---|---|---|
| Expansible | |||||
| Standard_B1s | 1 | 1 | 320 | 171 | 4 |
| Standard_B1ms | 1 | 2 | 640 | 341 | 4 |
| Standard_B2s | 2 | 4 | 1 280 | 683 | 4 |
| Standard_B2ms | 2 | 8 | 1 700 | 1365 | 16 |
| Standard_B4ms | 4 | 16 | 2 400 | 2731 | 32 |
| Standard_B8ms | 8 | 32 | 3100 | 5461 | 64 |
| Standard_B12ms | 12 | 48 | 3 800 | 8193 | 96 |
| Standard_B16ms | 16 | 64 | 4300 | 10923 | 128 |
| Standard_B20ms | 20 | 80 | 5 000 | 13653 | 160 |
| Usage général | |||||
| Standard_D2ads_v5 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D2ds_v4 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D4ads_v5 | 4 | 16 | 6 400 | 2731 | 150 |
| Standard_D4ds_v4 | 4 | 16 | 6 400 | 2731 | 150 |
| Standard_D8ads_v5 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D8ds_v4 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D16ads_v5 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D16ds_v4 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D32ads_v5 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D32ds_v4 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D48ads_v5 | 48 | 192 | 20000 | 32 768 | 1800 |
| Standard_D48ds_v4 | 48 | 192 | 20000 | 32 768 | 1800 |
| Standard_D64ads_v5 | 64 | 256 | 20000 | 43691 | 2 400 |
| Standard_D64ds_v4 | 64 | 256 | 20000 | 43691 | 2 400 |
| Critique pour l’entreprise | |||||
| Standard_E2ds_v4 | 2 | 16 | 5 000 | 2731 | 75 |
| Standard_E2ads_v5 | 2 | 16 | 5 000 | 2731 | 75 |
| Standard_E4ds_v4 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E4ads_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v4 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E8ads_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v4 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E16ads_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v4 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E20ads_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v4 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E32ads_v5 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E48ds_v4 | 48 | 384 | 48 000 | 65536 | 1800 |
| Standard_E48ads_v5 | 48 | 384 | 48 000 | 65536 | 1800 |
| Standard_E64ds_v4 | 64 | 504 | 64 000 | 86016 | 2 400 |
| Standard_E64ads_v5 | 64 | 504 | 64 000 | 86016 | 2 400 |
| Standard_E80ids_v4 | 80 | 504 | 72 000 | 86016 | 2 400 |
| Standard_E2ds_v5 | 2 | 16 | 5 000 | 2731 | 75 |
| Standard_E4ds_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v5 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E48ds_v5 | 48 | 384 | 48 000 | 65536 | 1800 |
| Standard_E64ds_v5 | 64 | 512 | 64 000 | 87383 | 2 400 |
| Standard_E96ds_v5 | 96 | 672 | 80000 | 100000 | 3600 |
Pour plus d’informations sur la série de calcul disponible, reportez-vous à la documentation des machines virtuelles Azure concernant Burstable (série B), Usage général série Dadsv5série Ddsv4 et Critique pour l’entrepriseEdsv4/série Edsv5/série Eadsv5
Notes
Pour le niveau de calcul Burstable (série B) si la machine virtuelle est démarrée/arrêtée ou redémarrée, les crédits peuvent être perdus. Pour plus d’informations, consultez les questions fréquentes sur le niveau Burstable (série B).
Limitations des performances des instances de série Burstable
Le niveau de calcul Burstable est conçu pour fournir une solution économique pour les charges de travail qui ne nécessitent pas l’intégralité du processeur en continu. Ce niveau est idéal pour les charges de travail hors production, telles que les environnements de développement, de préproduction ou de test. La fonctionnalité unique du niveau de calcul Burstable est sa capacité à prendre en charge des « rafales », c’est-à-dire à utiliser plus que ses performances de processeur de référence en utilisant jusqu’à 100 % du processeur virtuel lorsque la charge de travail l’exige. Cela est rendu possible par un modèle de crédit de processeur, qui permet aux instances de série B d’accumuler des « crédits de processeur » pendant les périodes de faible utilisation du processeur. Vous pouvez ensuite dépenser ces crédits pendant des périodes d’utilisation élevée du processeur, ce qui permet à l’instance de dépasser ses performances de processeur de base.
Toutefois, il est important de noter qu’une fois qu’une instance Burstable a épuisé ses crédits de processeur, elle fonctionne selon ses performances de processeur de base. Par exemple, la performance de base du processeur (CPU) d’un Standard_B1ms est de 20 %, soit 0,2 Vcore. Si le serveur tiers Burstable exécute une charge de travail qui nécessite plus de performance du processeur (CPU) que le niveau de base, et qu’il a épuisé ses crédits de processeur, le serveur peut voir ses performances limitées et éventuellement affecter diverses opérations du système telles que l’arrêt/le démarrage/le redémarrage de votre serveur.
Remarque
Pour les serveurs du niveau de calcul Burstable (série B), tels que Standard_B1s/Standard_B1ms/Standard_B2s, la taille relativement plus petite de leur mémoire hôte peut entraîner des blocages (manque de mémoire) en cas de charge de travail continue, même si la métrique memory_percent n’a pas atteint 100 %.
En raison de cette limitation, le serveur peut rencontrer des problèmes de connectivité et les opérations du système peuvent être affectées. Dans ces situations, il est recommandé de mettre en pause la charge de travail sur le serveur afin d’accumuler des crédits conformément au modèle de banque de crédits de la série B, ou d’envisager de mettre le serveur à l’échelle vers des niveaux supérieurs tels que les niveaux Usage général ou Critique pour l’entreprise.
Par conséquent, bien que le niveau de calcul Burstable offre des avantages significatifs en matière de coût et de flexibilité pour certains types de charges de travail, il n’est pas recommandé pour les charges de travail de production qui nécessitent des performances de processeur homogènes. Le niveau Burstable ne prend pas en charge la création de réplicas en lecture ni la fonctionnalité Haute disponibilité. Pour ces charges de travail et fonctionnalités, d’autres niveaux de calcul, tels qu’Usage général ou Critique pour l’entreprise, sont plus appropriés.
Pour plus d’informations sur le modèle de crédit de processeur de la série B d’Azure, consultez les instances Burstable de la série B et modèle de crédit de processeur de la série B.
Supervision des crédits de processeur au niveau Burstable
La supervision de votre solde de crédits de processeur est essentielle pour maintenir des performances optimales au niveau de calcul Burstable. Le serveur flexible Azure Database pour MySQL fournit deux mesures clés liées aux crédits de processeur. Le seuil idéal pour déclencher une alerte dépend de vos exigences spécifiques en matière de charge de travail et de performances.
Crédits de processeur consommés : cette mesure indique le nombre de crédits de processeur consommés par votre instance. La supervision de cette mesure peut vous aider à comprendre les modèles d’utilisation du processeur de votre instance et à gérer efficacement ses performances.
Crédit du processeur restant : cette mesure indique le nombre de crédits de processeur restants pour votre instance. Garder un œil sur cette mesure peut vous aider à empêcher une dégradation des performances de votre instance en raison de l’épuisement de ses crédits de processeur. Si la mesure Crédit du processeur restant tombe en dessous d’un certain niveau (par exemple, moins de 30 % du total des crédits disponibles), cela indique que l’instance risque d’épuiser ses crédits de processeur si la charge actuelle du processeur se maintient.
Pour plus d’informations, sur la configuration des alertes sur les mesures, reportez-vous à ce guide.
Stockage
Le stockage que vous approvisionnez est la quantité de stockage disponible pour votre serveur flexible. Le stockage est utilisé pour les fichiers de base de données, les fichiers temporaires, les journaux d’activité de transaction, et les journaux d’activité du serveur MySQL. Dans tous les niveaux de service, le stockage minimal pris en charge est de 20 Gio et la valeur maximale de 16 Tio. Le stockage est mis à l’échelle par incréments de 1 Gio et peut être mis à l’échelle après la création du serveur.
Notes
Le stockage peut seulement monter en puissance.
Vous pouvez surveiller votre consommation de stockage dans le portail Azure (avec Azure Monitor) à l’aide des métriques de limite de stockage, de pourcentage de stockage et de stockage utilisé. Reportez-vous à l’article sur la surveillance pour en savoir plus sur les métriques.
Atteindre la limite de stockage
Lorsque le stockage consommé sur le serveur est proche de la limite configurée, le serveur est mis en mode lecture seule pour protéger les écritures perdues sur le serveur. Les serveurs avec moins de 100 Gio de stockage approvisionnés sont marqués en lecture seule si l’espace de stockage libre est inférieur à 5 % de la taille de stockage approvisionnée. Les serveurs avec plus de 100 Gio de stockage approvisionnés sont marqués en lecture seule lorsque l’espace de stockage libre est inférieur à 5 Gio.
Par exemple, si vous avez approvisionné 110 Gio de stockage et que l’utilisation réelle dépasse 105 Gio, le serveur est marqué en lecture seule. Sinon, si vous avez provisionné 5 Gio de stockage, le serveur est marqué en lecture seule quand le stockage disponible est inférieur à 256 Mo.
Pendant que le service tente de marquer le serveur en lecture seule, toutes les nouvelles demandes de transactions d’écriture sont bloquées et les transactions actives existantes continuent de s’exécuter. Une fois que le serveur est marqué en lecture seule, toutes les opérations d’écriture et validations de transaction ultérieures échouent. Les requêtes de lecture continueront de fonctionner sans interruption.
Pour sortir le serveur du mode lecture seule, vous devez augmenter le stockage approvisionné sur le serveur. Pour ce faire, vous pouvez utiliser le portail Azure ou Azure CLI. Une fois augmenté, le serveur est prêt à accepter de nouvelles transactions d’écriture.
Nous vous recommandions de configurer une alerte pour vous avertir quand votre serveur de stockage est proche du seuil afin d’éviter la mise en lecture seule. Pour plus d’informations, consultez la documentation sur comment configurer une alerte.
Croissance automatique du stockage
La croissance automatique du stockage permet à votre serveur de disposer en permanence d’un espace de stockage suffisant et de ne pas passer en lecture seule. Si la croissance automatique du stockage est activée, le stockage évolue automatiquement sans affecter la charge de travail. La croissance automatique du stockage est activée par défaut pour tous les serveurs créés. Pour les serveurs avec moins de 100 Go de stockage approvisionnés, la taille de stockage approvisionnée augmente de 5 Go lorsque l’espace de stockage libre est inférieur à 10 % de la taille de stockage approvisionnée. Pour les serveurs avec plus de 100 Go de stockage approvisionnés, la taille de stockage approvisionnée augmente de 5 % lorsque l’espace de stockage libre est inférieur à 10 Go de taille de stockage approvisionnée. Les limites de stockage maximales indiquées ci-dessus s’appliquent. Actualisez l’instance de serveur pour voir l’approvisionnement du stockage mis à jour sous Paramètres sur la page Calcul + stockage.
Par exemple, si vous avez approvisionné 1000 Go de stockage et que l’utilisation réelle dépasse 990 Go, la taille de stockage du serveur passe à 1050 Go. Sinon, si vous avez configuré 20 Go de stockage, la taille de stockage passe à 25 Go lorsque moins de 2 Go de stockage est libre.
N’oubliez pas qu’il est impossible d’effectuer un scale-down du stockage une fois que le scale-up automatique a été configuré.
Remarque
La croissance automatique du stockage est activée par défaut pour un serveur configuré à haute disponibilité. Cela ne peut pas être désactivée.
E/S par seconde
Le serveur flexible Azure Database pour MySQL prend en charge les IOPS pré-approvisionnés et les IOPS de mise à l’échelle automatique. Plus d’informations Le nombre minimal d’E/S par seconde est de 360 pour toutes les tailles de calcul, avec un nombre maximal d’E/S par seconde déterminé par la taille de calcul sélectionnée. Pour en savoir plus sur le nombre maximal d’IOPS par taille de calcul, consultez le tableau.
Important
**Le nombre minimal d’E/S par seconde est de 360 pour toutes les tailles de calcul
**Le nombre maximal d’E/S par seconde est déterminé par la taille de calcul sélectionnée.
Vous pouvez surveiller votre consommation d’E/S dans le portail Azure (avec Azure Monitor) à l’aide de la métrique IO percent. Si vous avez besoin de plus d’IOPS que le nombre maximal d’IOPS basé sur la capacité de calcul, vous devez mettre à l’échelle la capacité de calcul de votre serveur.
IOPS par seconde préconfigurées
Azure Database pour MySQL serveur flexible offre des IOPS préconfigurées, ce qui vous permet d’allouer un nombre spécifique d’IOPS à votre instance de serveur flexible Azure Database pour MySQL. Ce paramètre garantit des performances cohérentes et prévisibles pour vos charges de travail. Avec les IOPS préconfigurées, vous pouvez définir une limite d’IOPS spécifique pour votre volume de stockage, garantissant ainsi la possibilité de gérer un certain nombre de demandes par seconde. Cela se traduit par un niveau de performance fiable et garanti. Les IOPS pré-approvisionnés vous permettent d’approvisionner des IOPS supplémentaires au-dessus de la limite d’E/S par seconde. À l’aide de cette fonctionnalité, vous pouvez augmenter ou diminuer à tout moment le nombre d’IOPS approvisionnées en fonction des exigences de votre charge de travail.
Mise à l’échelle automatique des E/S par seconde
La pierre angulaire du serveur flexible Azure Database pour MySQL est sa capacité à obtenir les meilleures performances pour les charges de travail de niveau 1, ce qui peut être amélioré en permettant au serveur de mettre à l’échelle automatiquement les performances (E/S) de ses serveurs de base de données en fonction des besoins de charge de travail. Il s’agit d’une fonctionnalité d’activation qui permet aux utilisateurs de mettre à l’échelle des E/S par seconde sans avoir à pré-approvisionner une certaine quantité d’E/S par seconde. Avec cette fonctionnalité activée, vous pouvez désormais profiter sans souci de la gestion gratuite des E/S dans le serveur flexible Azure Database pour MySQL, car le serveur met à l’échelle les E/S par seconde de manière automatique en fonction des besoins de charge de travail.
Avec la mise à l’échelle automatique des E/S par seconde, vous payez uniquement pour les E/S que le serveur utilise et n’avez plus besoin d’approvisionner et de payer des ressources qui ne sont pas entièrement utilisées, ce qui permet d’économiser du temps et de l’argent. En outre, les applications de Niveau 1 stratégique peuvent atteindre des performances cohérentes en rendant des E/S supplémentaires disponibles pour la charge de travail à tout moment. La mise à l’échelle automatique des E/S par seconde élimine l’administration requise pour fournir les meilleures performances au moindre coût pour les clients de serveur flexible Azure Database pour MySQL.
Mise à l’échelle dynamique : les IOPS de mise à l’échelle automatique ajustent dynamiquement la limite d’IOPS de votre serveur de base de données en fonction de la demande réelle de votre charge de travail. Cela garantit un niveau de performance optimales sans intervention ou configuration manuelle.
Gestion des pics de charge de travail: les IOPS de mise à l’échelle automatique permettent à votre base de données de gérer en toute transparence les pics de charge de travail ou les fluctuations sans compromettre le niveau de performance de vos applications. Cette fonctionnalité garantit une réactivité cohérente même pendant les périodes d’utilisation maximales.
Économies : contrairement aux IOPS préprovisionnées où une limite d’IOPS fixe est spécifiée et payée indépendamment de l’utilisation, les IOPS de mise à l’échelle automatique vous permettent de payer uniquement le nombre d’opérations d’E/S que vous consommez.
Sauvegarde
Le service effectue automatiquement des sauvegardes de votre serveur. Vous pouvez sélectionner une période de conservation comprise entre 1 et 35 jours. Pour plus d’informations sur les sauvegardes, consultez cet article sur les concepts de sauvegarde et de restauration.
Mettre les ressources à l’échelle
Après avoir créé votre serveur, vous pouvez modifier de manière indépendante le niveau de calcul, la taille de calcul (vCores et mémoire) et la quantité de stockage et la période de rétention de sauvegarde. La taille de calcul peut être augmentée ou réduite. La période de rétention de sauvegarde peut être augmentée ou diminuée et va de 1 à 35 jours. La taille de stockage ne peut être qu’augmentée. La mise à l’échelle des ressources peut être effectuée par le biais du portail ou d’Azure CLI.
Notes
La taille de stockage ne peut être qu’augmentée. Vous ne pouvez pas revenir à une taille de stockage inférieure après l’augmentation.
Lorsque vous modifiez le niveau de calcul ou la taille de calcul, le serveur redémarre pour que le nouveau type de serveur prenne effet. Pendant le moment durant lequel le système bascule vers le nouveau serveur, aucune nouvelle connexion ne peut être établie, et toutes les transactions non validées sont restaurées. Cette fenêtre varie, mais dans la plupart des cas elle dure entre 60 et 120 secondes.
La mise à l’échelle du stockage et la modification de la période de rétention de la sauvegarde sont des opérations en ligne et ne nécessitent pas de redémarrage du serveur.
Tarifs
Pour obtenir les dernières informations sur la tarification, veuillez consulter le service Page de tarification. Pour voir le coût de la configuration souhaitée, le Portail Azure affiche le coût mensuel dans l’onglet Calcul et stockage selon les options que vous avez sélectionnées. Si vous n’avez pas d’abonnement Azure, vous pouvez utiliser la calculatrice de prix Azure pour obtenir une estimation. Pour personnaliser les options, sur le site web Calculatrice de prix d’Azure, sélectionnez Ajouter des éléments, développez la catégorie Bases de données, sélectionnez Azure Database pour MySQL, puis Serveur flexible comme type de déploiement pour personnaliser les options.
Si vous souhaitez optimiser le coût du serveur, vous pouvez prendre en compte les conseils suivants :
- Réduisez le niveau de calcul ou la taille de calcul (vCores) si le calcul est sous-exploité.
- Envisagez de basculer vers un niveau de calcul Burstable si votre charge de travail n’a pas besoin de la capacité de calcul complète en continu à partir des niveaux Usage général et Critique pour l’entreprise.
- Arrêtez le serveur lorsqu’il n’est pas en cours d’utilisation.
- Réduisez la période de rétention des sauvegardes si une rétention de sauvegarde plus longue n’est pas nécessaire.
Étapes suivantes
- Découvrez comment créer une instance de serveur flexible Azure Database pour MySQL dans le portail.
- En savoir plus sur les limitations du service.