Niveau de calcul serverless pour Azure SQL Database
S’applique à : Azure SQL Database
Serverless est un niveau de calcul destiné aux bases de données uniques d’Azure SQL Database qui met automatiquement à l’échelle les calculs en fonction de la demande en charge de travail, et facture la quantité de calcul utilisée par seconde. Le niveau de calcul serverless met aussi automatiquement en pause les bases de données pendant les périodes d’inactivité, quand seul le stockage est facturé, et reprend leur exécution automatiquement avec l’activité. Le niveau de calcul serverless est disponible dans le niveau de service Usage général et le niveau de service Hyperscale.
Remarque
La mise en pause automatique et la reprise automatique sont uniquement prises en charge dans le niveau de service Usage général.
Vue d’ensemble
Une plage de mise à l’échelle automatique de calcul et un retard de mise en pause automatique sont des paramètres importants pour le niveau de calcul serverless. La configuration de ces paramètres déterminent l’expérience de performances de base de données et le coût du calcul.
Configuration des performances
- Les quantités minimale et maximale de vCores sont des paramètres configurables qui définissent la plage de la capacité de calcul disponible pour la base de données. Les limites en mémoire et E/S sont proportionnelles à la plage de vCore spécifiée.
- Le délai de mise en pause automatique est un paramètre configurable qui définit la durée pendant laquelle la base de données doit être inactive avant d’être automatiquement mise en pause. La base de données reprend automatiquement lors de la prochaine connexion ou activité. Vous pouvez également désactiver la mise en pause automatique.
Coût
- Le coût d’une base de données serverless correspond à la somme du coût de calcul et du coût de stockage.
- Quand l’utilisation du calcul est comprise dans les limites minimales et maximales configurées, le coût du calcul est basé sur le nombre de vCores et la mémoire utilisée.
- Quand l’utilisation du calcul est inférieure aux limites minimales configurées, le coût du calcul est basé sur le nombre minimal de vCores et la mémoire minimale configurée.
- Quand la base de données est en pause, le coût du calcul est égal à zéro et seuls les coûts de stockage sont facturés.
- Le coût de stockage est déterminé de la même façon que dans le niveau de calcul provisionné.
Pour plus de détails sur les coûts, consultez Facturation.
Scénarios
Serverless constitue un rapport prix/performance optimisé pour les bases de données uniques avec des modèles d’utilisation intermittents imprévisibles pouvant supporter un délai dans le préchauffage du calcul après des périodes d’inactivité. Par opposition, le niveau de calcul provisionné présente un rapport prix/performance optimisé pour une base de données unique ou plusieurs bases de données dans des pools élastiques avec une utilisation moyenne plus élevée qui ne tolèrent aucun délai lors du préchauffage du calcul.
Scénarios adaptés à l’informatique serverless
- Les bases de données uniques avec des modèles d’utilisation intermittente et non prévisible, entrecoupée de périodes d’inactivité, et une utilisation moyenne moins élevée des fonctions de calcul dans le temps.
- Les bases de données uniques dans le niveau de calcul provisionné qui sont souvent mises à l’échelle et les clients qui préfèrent déléguer la mise à l’échelle du calcul au service.
- Les nouvelles bases de données uniques sans historique d’utilisation où la taille de calcul est difficile ou impossible à estimer avant le déploiement dans une base de données Azure SQL.
Scénarios adaptés au calcul provisionné
- Les bases de données uniques avec des modèles d’utilisation plus régulière et prévisible, et une utilisation du calcul moyenne plus élevée dans le temps.
- Les bases de données qui ne peuvent pas tolérer de compromis sur les performances résultant d’insuffisances de mémoire plus fréquentes ou de délais dans la reprise après un état de mise en pause.
- Plusieurs bases de données avec des modèles d’utilisation intermittente et imprévisible qui peuvent être regroupées dans des pools élastiques pour un rapport prix/performances optimisé.
Comparer les niveaux de calcul
Le tableau suivant résume les différences entre le niveau de calcul serverless et le niveau de calcul provisionné :
Calcul serverless | Calcul provisionné | |
---|---|---|
Modèle d’utilisation des bases de données | Utilisation intermittente et imprévisible avec une utilisation moyenne du calcul moins élevée dans le temps. | Modèles d’utilisation plus régulière avec une utilisation moyenne du calcul plus élevée dans le temps, ou plusieurs bases de données regroupées dans des pools élastiques. |
Effort pour gérer les performances : | Moins grand | Plus grand |
Mise à l’échelle du calcul | Automatique | Manuel |
Réactivité du calcul. | Moins rapide après les périodes d’inactivité | Immédiat |
Mode de facturation | À la seconde | À l’heure |
Modèle d’achat et niveau de service
Le tableau suivant décrit la prise en charge du mode serverless en fonction du modèle d’achat, des niveaux de service et du matériel :
Catégorie | Pris en charge | Non pris en charge |
---|---|---|
Modèle d’achat | vCore | DTU |
Niveau de service | Usage général Hyperscale |
Critique pour l’entreprise |
Matériel | Série Standard (Gen5) | Tout autre matériel |
Mise à l’échelle automatique
Réactivité de la mise à l’échelle
Les bases de données serverless sont exécutées sur une machine d’une capacité suffisante pour répondre aux besoins en ressources sans interruption, quel que soit le volume de calcul demandé dans les limites définies par le nombre maximal de vCores. Parfois, un équilibrage de charge se produit automatiquement si l’ordinateur ne parvient pas à satisfaire les besoins en ressources en quelques minutes. Par exemple, si la demande en ressources est de quatre vCores, mais que seuls deux vCores sont disponibles, un délai de quelques minutes peut être nécessaire pour équilibrer la charge avant de fournir les quatre vCores demandés. La base de données reste en ligne au cours de l’équilibrage de charge, sauf pendant une courte période à la fin de l’opération lorsque les connexions sont supprimées.
Gestion de la mémoire
Dans les deux niveaux de service Usage général et Hyperscale, la mémoire des bases de données serverless est récupérée plus fréquemment que pour les bases de données de calcul provisionnées. Il est important de tenir compte de ce comportement pour maîtriser les coûts dans le niveau serverless et déterminer l’impact sur les performances.
Récupération du cache
Contrairement aux bases de données de calcul provisionné, la mémoire du cache SQL est sollicitée par une base de données serverless quand l’utilisation du processeur ou du cache actif est faible.
- L’utilisation du cache actif est considérée comme faible quand la taille totale des dernières entrées du cache utilisées tombe sous un certain seuil, pendant une période donnée.
- Quand la récupération du cache est déclenchée, la taille de cache cible est réduite de façon incrémentielle à une fraction de sa taille précédente, et la récupération continue uniquement si l’utilisation reste faible.
- S’il y a une récupération du cache, la stratégie de sélection des entrées du cache à supprimer est la même que celle utilisée pour les bases de données de calcul provisionné quand la mémoire est fortement sollicitée.
- La taille du cache n’est jamais réduite en deçà de la limite de mémoire minimale telle que définie par le nombre minimal de vCores.
Dans les bases de données de niveaux de calcul serverless et provisionné, des entrées de cache peuvent être supprimées si toute la mémoire disponible est utilisée.
Quand l’utilisation du processeur est faible, l’utilisation du cache actif peut rester élevée en fonction du modèle d’utilisation et empêcher la récupération de la mémoire. Il peut y avoir aussi des délais supplémentaires après l’arrêt de l’activité de l’utilisateur avant la récupération de la mémoire en raison des processus d’arrière-plan réguliers répondant à l’activité utilisateur précédente. Par exemple, les opérations de suppression et les tâches de nettoyage du Magasin des requêtes génèrent des enregistrements fantômes marqués pour suppression, mais qui ne sont pas physiquement supprimés tant que le processus de nettoyage des éléments fantômes n’est pas exécuté. Le nettoyage des éléments fantômes peut impliquer la lecture de pages de données dans le cache.
Alimentation du cache
La taille du cache mémoire SQL augmente à mesure que des données sont extraites du disque, de la même manière et au même rythme que pour des bases de données provisionnées. Quand la base de données est occupée, le cache est autorisé à grossir sans contrainte tant que de la mémoire est disponible.
Gestion du cache de disque
Dans le niveau de service Hyperscale pour les niveaux de calcul serverless et provisionné, chaque réplica de calcul utilise un cache RBPEX (Resilient Buffer Pool Extension), qui stocke les pages de données sur le disque SSD local pour améliorer les performances d’E/S. Toutefois, dans le niveau de calcul serverless pour Hyperscale, le cache RBPEX pour chaque réplica de calcul augmente et diminue automatiquement en réponse à l’augmentation et à la diminution de la demande en charge de travail. La taille maximale du cache RBPEX peut atteindre trois fois la mémoire maximale configurée pour la base de données. Pour plus d’informations sur la mémoire maximale et les limites de mise à l’échelle automatique RBPEX en mode serverless, consultez Limites de ressources Hyperscale serverless.
Mise en pause automatique et reprise automatique
La mise en pause automatique et la reprise automatique serverless ne sont prises en charge qu’au niveau Usage général.
Mise en pause automatique
Une mise en pause automatique est déclenchée si toutes les conditions suivantes sont remplies pendant la durée du délai de mise en pause automatique :
- Nombre de sessions = 0
- Processeur = 0 pour la charge de travail utilisateur exécutée dans le pool de ressources utilisateur
Une option permet de désactiver la mise en pause automatique si vous le souhaitez.
Les fonctionnalités suivantes ne prennent pas en charge la mise en pause automatique, mais prennent en charge la mise à l’échelle automatique. Si l’une des fonctionnalités suivantes est utilisée, la mise en pause automatique doit être désactivée et la base de données reste en ligne quelle que soit sa durée d’inactivité :
- Géoréplication (géoréplication active et groupes de basculement).
- Conservation de sauvegardes à long terme (LTR).
- Base de données de synchronisation utilisée dans SQL Data Sync. Contrairement aux bases de données de synchronisation, les bases de données hub et membre prennent en charge la mise en pause automatique.
- Alias DNS créé pour le serveur logique qui contient une base de données serverless.
- Tâches élastiques, la base de données serverless avec mise en pause automatique n’est pas prise en charge comme Base de données des tâches. Les bases de données serverless ciblées par les travaux élastiques prennent en charge la mise en pause automatique. Les connexions de projets vont reprendre une base de données.
La mise en pause automatique est temporairement indisponible durant le déploiement de certaines mises à jour de service pour lesquelles la base de données doit être en ligne. Dans ce cas, la mise en pause automatique est réactivée dès que la mise à jour du service est terminée.
Résolution des problèmes de mise en pause automatique
Si la mise en pause automatique est activée et que les fonctionnalités qui bloquent la mise en pause automatique ne sont pas utilisées, mais qu’une base de données n’est pas mise en pause automatique quand le délai est écoulé, il se peut que des sessions d’application ou utilisateur empêchent la mise en pause automatique.
Pour voir si des sessions d’application ou utilisateur sont actuellement connectées à la base de données, connectez-vous à la base de données à l’aide de n’importe quel outil client et exécutez la requête suivante :
SELECT session_id,
host_name,
program_name,
client_interface_name,
login_name,
status,
login_time,
last_request_start_time,
last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
AND
(
(
wg.name like 'UserPrimaryGroup.DB%'
AND
TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
)
OR
wg.name = 'DACGroup'
);
Conseil
Après avoir exécuté la requête, veillez à vous déconnecter de la base de données. Sinon, la session ouverte utilisée par la requête empêchera la mise en pause automatique.
- Si le jeu de résultats n’est pas vide, cela signifie que des sessions empêchent actuellement la mise en pause automatique.
- Si le jeu de résultats est vide, il est toujours possible que des sessions aient été ouvertes précédemment, peut-être durant une brève période, pendant le délai de pause automatique. Pour vérifier l’activité pendant la période de retard, vous pouvez utiliser l’audit Azure SQL et examiner les données d’audit sur la période concernée.
Important
La présence de sessions ouvertes, avec ou sans utilisation simultanée du processeur dans le pool de ressources utilisateur, est la raison la plus courante pour laquelle une base de données serverless n’est pas mise en pause automatique comme prévu.
Reprise automatique
La reprise automatique est déclenchée si l’une des conditions suivantes est remplie à un moment donné :
Fonctionnalité | Déclencheur de reprise automatique |
---|---|
Authentification et autorisation | Connexion |
Détection de menaces | Activation/désactivation des paramètres de détection des menaces au niveau de la base de données ou du serveur. Modification des paramètres de détection des menaces au niveau de la base de données ou du serveur. |
Découverte et classification des données | Ajout, modification, suppression ou affichage des étiquettes de sensibilité |
Audit | Affichage des enregistrements d’audit. Mise à jour ou affichage de la stratégie d’audit. |
Masquage de données | Ajout, modification, suppression ou affichage des règles de masquage des données |
Chiffrement transparent des données | État d’affichage ou état du chiffrement transparent des données |
Évaluation des vulnérabilités | Analyses ad hoc et analyses périodiques si elles sont activées |
Magasin de données des requêtes (performances) | Modification ou affichage des paramètres du magasin des requêtes |
Recommandations sur les performances | Affichage ou application des recommandations en matière de performances |
Réglage automatique | Application et vérification des recommandations de réglage automatique telles que l’indexation automatique |
Copie de base de données | Création d’une base de données comme copie. Exportation vers un fichier BACPAC. |
SQL Data Sync | Synchronisation entre les bases de données hub et membre qui s’exécutent selon une planification configurable ou qui sont exécutées manuellement |
Modification de certaines métadonnées de base de données | Ajout de nouvelles balises de base de données. Changement du nombre maximal de vCores, du nombre minimal de vCores ou du délai de mise en pause automatique. |
SQL Server Management Studio (SSMS) | Lorsque vous utilisez des versions de SSMS antérieures à 18.1 et que vous ouvrez une nouvelle fenêtre de requête pour toute base de données du serveur, tout base de données du même serveur qui ont été mises en pause automatique est reprise. Ce comportement ne se produit pas si vous utilisez SSMS version 18.1 ou ultérieure. |
- La surveillance, la gestion ou d’autres solutions permettant d’effectuer l’une des opérations énumérées déclenchent une reprise automatique.
- La reprise automatique est également déclenchée durant le déploiement de certaines mises à jour de service pour lesquelles la base de données doit être en ligne.
Connectivité
Si une base de données serverless est mise en pause, la première tentative de connexion reprend la base de données et retourne une erreur indiquant que la base de données n’est pas disponible (code d’erreur 40613). Une fois que la base de données est reprise, la connexion peut être retentée pour établir la connectivité. Les clients de base de données avec une logique de nouvelle tentative de connexion recommandée n’ont normalement pas besoin d’être modifiés. Pour connaître les modèles recommandés pour la logique de nouvelle tentative de connexion, passez en revue :
- Logique de nouvelle tentative dans SqlClient
- Logique de nouvelle tentative dans la base de données SQL utilisant Entity Framework Core
- Logique de nouvelle tentative dans la base de données SQL utilisant Entity Framework 6
- Logique de nouvelle tentative dans SQL Database à l’aide de ADO.NET
Latence
La latence pour la reprise automatique d’une base de données serverless est généralement d’environ une minute et pour la mise en pause automatique, entre une et dix minutes.
Chiffrement transparent des données géré par le client (BYOK)
Suppression ou révocation de clé
Si vous utilisez le chiffrement transparent des données géré par le client (BYOK) et que la base de données serverless est mise en pause automatique lors de la suppression ou de la révocation de la clé, la base de données reste dans l’état de pause automatique. Dans ce cas, après la reprise de la base de données, la base de données devient inaccessible pendant 10 minutes environ. Une fois que la base de données devient inaccessible, le processus de récupération est le même que pour les bases de données de calcul provisionnées. Si la base de données serverless est en ligne lors de la suppression ou de la révocation d’une clé, elle devient également inaccessible après environ 10 minutes, de la même façon qu’avec les bases de données de calcul approvisionnées.
Rotation des clés
Si vous utilisez le chiffrement transparent des données géré par le client (BYOK) et que la mise en pause automatique serverless est activée, la base de données est reprise automatiquement lors de la rotation des clés, puis mise en pause automatique lorsque les conditions de mise en pause automatique sont remplies.
Créer une base de données serverless
La création d’une base de données ou le déplacement d’une base de données existante dans un niveau de calcul serverless suivent le même modèle que la création d’une nouvelle base de données dans un niveau de calcul provisionné et impliquent les deux étapes suivantes :
Spécifiez l’objectif de service. L’objectif du service précise le niveau de service, la configuration matérielle et le nombre maximal de vCores. Pour connaître les options d’objectif de service, consultez Limites des ressources serverless.
Si vous le souhaitez, spécifiez un nombre minimal de vCores et un délai de mise en pause automatique différents des valeurs par défaut. Le tableau suivant présente les valeurs disponibles pour ces paramètres.
Paramètre Choix des valeurs Valeur par défaut Nombre minimal de vCores Dépend du nombre maximal de vCores configuré. Voir Limites des ressources. 0,5 vCore Délai de pause automatique Minimum : 60 minutes (1 heure)
Maximum : 10 080 minutes (7 jours)
Incréments : 10 minutes
Désactiver la mise en pause automatique : -160 minutes
Les exemples suivants créent une base de données au niveau de calcul serverless.
Utiliser le portail Azure
Utiliser PowerShell
Créez une base de données Usage général serverless avec l’exemple PowerShell suivant :
New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
-Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
-MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720
Utiliser l’interface de ligne de commande Microsoft Azure
Créez une base de données à usage général serverless avec l’exemple Azure CLI suivant :
az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
-e GeneralPurpose --compute-model Serverless -f Gen5 `
--min-capacity 0.5 -c 2 --auto-pause-delay 720
Utiliser Transact-SQL (T-SQL)
Lorsque vous utilisez T-SQL pour créer une base de données serverless, les valeurs par défaut sont appliquées pour le nombre minimal de vCores et le délai de pause automatique. Vous pourrez les modifier ultérieurement à partir du Portail Azure ou d’autres API de gestion (PowerShell, Azure CLI, API REST).
Pour plus d’informations, consultez CREATE DATABASE.
Créez une base de données serverless Usage général avec l’exemple T-SQL suivant :
CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;
Déplacer une base de données d’un niveau de calcul à l’autre
Il est possible de déplacer votre base de données du niveau de calcul provisionné vers le niveau de calcul serverless, et vice versa.
Notes
Il est également possible de mettre à niveau votre base de données dans le niveau Usage général vers le niveau Hyperscale. Pour en savoir plus, consultez Gérer les bases de données Hyperscale.
Quand vous déplacez votre base de données d’un niveau de calcul à l’autre, fournissez le paramètre Modèle de calculServerless
ou Provisioned
si vous utilisez PowerShell et Azure CLI ainsi que la taille de calcul pour SERVICE_OBJECTIVE si vous utilisez T-SQL. Passez en revue les limites des ressources pour identifier votre taille de calcul appropriée.
Les exemples de cette section vous montrent comment déplacer votre base de données provisionnée vers le mode serverless. Modifiez l’objectif du service en fonction des besoins, car ces exemples définissent le nombre maximal de vCores sur 4.
Utiliser PowerShell
Déplacez une base de données Usage général de calcul provisionnée vers le niveau de calcul serverless avec l’exemple PowerShell suivant :
Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
-Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
-MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440
Utiliser l’interface de ligne de commande Microsoft Azure
Déplacez une base de données Usage général de calcul provisionnée vers le niveau de calcul serverless avec l’exemple Azure CLI suivant :
az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
--edition GeneralPurpose --compute-model Serverless --family Gen5 `
--min-capacity 1 --capacity 4 --auto-pause-delay 1440
Utiliser Transact-SQL (T-SQL)
Lorsque vous utilisez T-SQL pour déplacer une base de données entre les niveaux de calcul, les valeurs par défaut sont appliquées pour le nombre minimal de vCores et le délai de pause automatique. Vous pourrez les modifier ultérieurement à partir du Portail Azure ou d’autres API de gestion (PowerShell, Azure CLI, API REST). Pour en savoir plus, consultez ALTER DATABASE.
Déplacez une base de données Usage général de calcul provisionnée vers le niveau de calcul serverless avec l’exemple T-SQL suivant :
ALTER DATABASE testdb
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;
Modifier la configuration serverless
Utiliser PowerShell
Utilisez Set-AzSqlDatabase pour modifier le nombre maximal ou minimal de vCores et le délai de mise en pause automatique. Utilisez les arguments MaxVcore
, MinVcore
et AutoPauseDelayInMinutes
. La mise en pause automatique serverless n’étant pas prise en charge dans le niveau Hyperscale, l’argument de délai de pause automatique ne s’applique qu’au niveau Usage général.
Utiliser l’interface de ligne de commande Microsoft Azure
Utilisez az sql db update pour modifier le nombre maximal ou minimal de vCores et le délai de mise en pause automatique. Utilisez les arguments capacity
, min-capacity
et auto-pause-delay
. La mise en pause automatique serverless n’étant pas prise en charge dans le niveau Hyperscale, l’argument de délai de pause automatique ne s’applique qu’au niveau Usage général.
Monitor
Ressources utilisées et facturées
Les ressources d’une base de données serverless sont comprennent le package d’application, l’instance SQL et les entités du pool de ressources utilisateur.
Package d’application
Le package d’application représente le maximum en termes de gestion des ressources d’une base de données, que celle-ci soit dans un niveau de calcul serverless ou provisionné. Le package d’application contient l’instance SQL et des services externes tels que la recherche en texte intégral, qui comprennent ensemble toutes les ressources utilisateur et système utilisées par une base de données dans SQL Database. En règle générale, l’instance SQL domine l’utilisation globale des ressources sur le package d’application.
Pool de ressources utilisateur
Le pool de ressources utilisateur représente une limite interne en termes de gestion des ressources d’une base de données, que celle-ci soit dans un niveau de calcul serverless ou provisionné. Le pool de ressources utilisateur comprend le processeur et les E/S de la charge de travail utilisateur générée par les requêtes DDL comme (CREATE et ALTER) et DML (INSERT, UPDATE, DELETE, MERGE et SELECT). Ces requêtes représentent généralement la proportion la plus importante de l’utilisation dans le package d’application.
Métriques
Le tableau suivant inclut des métriques de supervision de l’utilisation des ressources du package d’application et du pool de ressources utilisateur d’une base de données serverless, y compris les réplicas géographiques :
Entité | Métrique | Description | Units |
---|---|---|---|
Package d’application | app_cpu_percent | Pourcentage de vCores utilisés par l’application par rapport au nombre maximal de vCores autorisé pour l’application. Pour Hyperscale serverless, cette métrique est exposée pour tous les réplicas principaux, les réplicas nommés et les réplicas géographiques. | Pourcentage |
Package d’application | app_cpu_billed | Volume de calcul facturé pour l’application pendant la période de rapport. Le montant payé pendant cette période est le produit de cette métrique et du prix unitaire d’un vCore. Les valeurs de cette métrique sont déterminées par l’agrégation de la quantité maximale du processeur utilisé et de la mémoire utilisée par seconde. Si la quantité utilisée est inférieure à la quantité minimale provisionnée tel que définie par le nombre minimal de vCores et la mémoire minimale, la quantité minimale provisionnée est facturée. Pour comparer le processeur à la mémoire à des fins de facturation, la mémoire est normalisée en unités de vCores en remettant à l’échelle la quantité de mémoire en Go à 3 Go par vCore. Pour Hyperscale serverless, cette métrique est exposée pour le réplica principal et tous les réplicas nommés. |
Secondes de vCore |
Package d’application | app_cpu_billed_HA_replicas | Applicable uniquement à Hyperscale serverless. Somme des calculs facturés sur toutes les applications pour les réplicas haute disponibilité au cours de la période de reporting. Cette somme est limitée aux réplicas haute disponibilité appartenant au réplica principal ou aux réplicas haute disponibilité appartenant à un réplica nommé donné. Avant de calculer cette somme sur les réplicas haute disponibilité, la quantité de calcul facturée pour un réplica haute disponibilité individuel est déterminée de la même manière que pour le réplica principal ou un réplica nommé. Pour Hyperscale serverless, cette métrique est exposée pour tous les réplicas principaux, les réplicas nommés et les réplicas géographiques. Le montant payé pendant la période de reporting est le produit de cette métrique et du prix unitaire d’un vCore. | Secondes de vCore |
Package d’application | app_memory_percent | Pourcentage de mémoire utilisée par l’application par rapport à la mémoire maximale autorisée pour l’application. Pour Hyperscale serverless, cette métrique est exposée pour tous les réplicas principaux, les réplicas nommés et les réplicas géographiques. | Pourcentage |
Pool de ressources utilisateur | cpu_percent | Pourcentage de vCores utilisés par la charge de travail utilisateur par rapport au nombre maximal de vCores autorisé pour la charge de travail utilisateur. | Pourcentage |
Pool de ressources utilisateur | data_IO_percent | Pourcentage d’IOPS de données utilisées par la charge de travail utilisateur par rapport au nombre maximal d’IOPS de données autorisé pour la charge de travail utilisateur. | Pourcentage |
Pool de ressources utilisateur | log_IO_percent | Pourcentage de Mo/s de journal utilisés par la charge de travail utilisateur par rapport au nombre maximal de Mo/s de journal autorisé pour la charge de travail utilisateur. | Pourcentage |
Pool de ressources utilisateur | workers_percent | Pourcentage de workers utilisés par la charge de travail utilisateur par rapport au nombre maximal de workers autorisé pour la charge de travail utilisateur. | Pourcentage |
Pool de ressources utilisateur | sessions_percent | Pourcentage de sessions utilisées par la charge de travail utilisateur par rapport au nombre maximal de sessions autorisé pour la charge de travail utilisateur. | Pourcentage |
État de mise en pause et de reprise
Dans le cas d’une base de données serverless avec la mise en pause automatique activée, l’état signalé inclut les valeurs suivantes :
Statut | Description |
---|---|
En ligne | La base de données est en ligne. |
Suspension en cours | La base de données passe de l’état En ligne à Suspendue. |
Suspendu | La base de données est suspendue. |
En cours de reprise | La base de données passe de l’état Suspendu à En ligne. |
Utiliser le portail Azure
Dans le portail Azure, l’état de la base de données est affiché dans la page Vue d’ensemble de la base de données et la page Vue d’ensemble du serveur. En outre, dans le Portail Azure, l’historique des événements de suspension et de reprise d’une base de données serverless peut être consulté dans le Journal d’activité.
Utiliser PowerShell
Affichez l’état actuel de la base de données à l’aide de l’exemple PowerShell suivant :
Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
| Select -ExpandProperty "Status"
Utiliser l’interface de ligne de commande Microsoft Azure
Affichez l’état actuel de la base de données à l’aide de l’exemple Azure CLI suivant :
az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json
Limites des ressources
Pour connaître les limites de ressources, consultez Niveau de calcul serverless.
Facturation
Le volume de calcul facturé pour une base de données serverless correspond à la quantité maximale de processeur et de mémoire utilisée par seconde. Si la quantité de processeur et de mémoire est inférieure à la quantité minimale provisionnée pour chaque ressource, la quantité provisionnée est facturée. Pour comparer le processeur à la mémoire à des fins de facturation, la mémoire est normalisée en unités de vCores en remettant à l’échelle le nombre de Go à 3 Go par vCore.
- Ressource facturée : Processeur et mémoire
- Montant facturé : prix unitaire d’un vCore * nombre maximal (nombre minimal de vCores, vCores utilisés, Go de mémoire minimale * 1/3, Go de mémoire utilisée * 1/3)
- Fréquence de facturation : À la seconde
Prix unitaire d’un vCore est le coût par vCore par seconde. Pour Hyperscale, le prix unitaire des vCores pour un réplica haute disponibilité ou un réplica nommé est inférieur à celui du réplica principal.
Reportez-vous à la page des prix Azure SQL Database pour connaître les prix à l’unité d’une région donnée.
La quantité de calcul facturée en mode serverless pour une base de données Usage général ou un réplica principal ou nommé Hyperscale est exposée par la métrique suivante :
- Métrique : app_cpu_billed (secondes de vCore)
- Définition : nombre maximal (nombre minimal de vCores, vCores utilisés, Go de mémoire minimale * 1/3, Go de mémoire utilisée * 1/3)
- Fréquence de reporting : par minute en fonction des mesures par seconde agrégées sur 1 minute.
La quantité de calcul facturée en mode serverless pour les réplicas Hyperscale haute disponibilité appartenant au réplica principal ou à tout réplica nommé est exposée par la métrique suivante :
- Métrique : app_cpu_billed_HA_replicas (secondes de vCore)
- Définition : somme maximale (nombre minimal de vCores, vCores utilisés, Go de mémoire minimale * 1/3, Go de mémoire utilisée * 1/3) pour tous les réplicas haute disponibilité appartenant à leur ressource parente.
- Ressource parente et point de terminaison d’indicateur : le réplica principal et tout réplica nommé exposent chacun séparément cet indicateur qui mesure le calcul facturé pour tous les réplicas haute disponibilité associés.
- Fréquence de reporting : par minute en fonction des mesures par seconde agrégées sur 1 minute.
Facturation minimale du calcul
Si une base de données serverless est suspendue, la facturation du calcul est égale à zéro. Dans le cas contraire, la facturation minimale du calcul n’est pas inférieure à la quantité de vCores basée sur le nombre maximal (nombre minimal de vCores, Go de mémoire minimale * ⅓).
Exemples :
- Prenons une base de données serverless dans le niveau Usage général non mise en pause et configurée avec 8 vCores maximum et 1 vCore minimum, correspondant à 3,0 Go de mémoire minimum. La facturation minimale du calcul se base alors sur le nombre maximal (1 vCore, 3,0 Go * 1 vCore/3 Go) = 1 vCore.
- Prenons une base de données serverless dans le niveau Usage général non mise en pause et configurée avec 4 vCores maximum et 0,5 vCore minimum, correspondant à 2,1 Go de mémoire minimum. La facturation minimale du calcul se base alors sur le nombre maximal (0,5 vCore, 2,1 Go * 1 vCore/3 Go) = 0,7 vCore.
- Supposons qu’une base de données serverless dans le niveau Hyperscale possède un réplica principal avec un réplica haute disponibilité et un réplica nommé sans réplica haute disponibilité. Supposons que chaque réplica est configuré avec 8 vCores maximum et 1 vCore minimum, correspondant à 3 Go de mémoire minimum. La facture de calcul minimale pour le réplica principal, le réplica haute disponibilité et le réplica nommé est pour chacun basée sur le nombre maximal (1 vCore, 3 Go * 1 vCore/3 Go) = 1 vCore.
La Calculatrice de prix de la base de données Azure SQL pour le serverless peut aider à déterminer la mémoire minimale configurable en fonction du nombre maximal et minimal de vCores configurés. En règle générale, si le nombre minimal de vCores configuré est supérieur à 0,5 vCore, la facturation minimale du calcul est indépendante de la mémoire minimale configurée et se base uniquement sur le nombre minimal de vCores configurés.
Exemples de scénarios
Prenons l’exemple d’une base de données serverless dans le niveau Usage général configurée avec 1 vCore minimum et 4 vCores maximum. Cette configuration représente environ 3 Go de mémoire minimum et 12 Go de mémoire maximum. Supposons que le délai de mise en pause automatique est défini à six heures et que la charge de travail de la base de données est active durant les deux premières heures d’une période de 24 heures, mais qu’elle reste inactive le reste du temps.
Dans ce cas de figure, la base de données est facturée pour le calcul et le stockage pendant les huit premières heures. Même si la base de données devient inactive après la deuxième heure, elle continue d’être facturée pour le calcul durant les six heures suivantes, selon le calcul minimal provisionné quand la base de données est en ligne. Seul le stockage est facturé pendant le reste de la période de 24 heures où la base de données est mise en pause.
Plus précisément, les coûts de calcul dans cet exemple sont calculés de la façon suivante :
Intervalle de temps | vCores utilisés par seconde | Go utilisés par seconde | Dimension de calcul facturée | Secondes de vCore facturées dans l’intervalle de temps |
---|---|---|---|---|
0:00-1:00 | 4 | 9 | vCores utilisés | 4 vCores * 3 600 secondes = 14 400 secondes de vCore |
1:00-2:00 | 1 | 12 | Mémoire utilisée | 12 Go * 1/3 * 3 600 secondes = 14 400 secondes de vCore |
2:00-8:00 | 0 | 0 | Mémoire minimale provisionnée | 3 Go * 1/3 * 21 600 secondes = 21 600 secondes de vCore |
8:00-24:00 | 0 | 0 | Aucun calcul facturé pendant la mise en pause | 0 seconde de vCore |
Total de secondes de vCore facturées sur 24 heures | 50 400 secondes de vCore |
Supposons que le prix de l’unité Compute est 0,000145 $/vCore/seconde. Le calcul facturé sur cette période de 24 heures est le produit du prix de l’unité Compute et du nombre de secondes de vCore facturées : 0,000145 $/vCore/seconde * 50 400 secondes de vCore ~ 7,31 $.
Azure Hybrid Benefit et capacité réservée
Les remises liées à Azure Hybrid Benefit et aux capacités réservées ne s’appliquent pas au niveau du calcul serverless.
Régions disponibles
Les niveaux d’usage général et d’hyperscale serverless avec prise en charge de 40 vCores maximum sont disponibles partout dans le monde, sauf dans les régions suivantes :
- Chine orientale
- Chine du Nord
- Centre de l’Allemagne
- Nord-Est de l’Allemagne
- US Gov Centre (Iowa)
Régions prenant en charge 80 vCores maximum sans zones de disponibilité pour l’usage général et l’hyperscale
Actuellement, 80 vCores maximum en serverless pour les niveaux d’usage général et d’hyperscale sont pris en charge dans les régions suivantes :
- Australie Est
- Sud-Australie Est
- Brésil Sud
- Centre du Canada
- USA Centre
- Asie Est
- USA Est
- USA Est 2
- France Centre
- France Sud
- Allemagne Centre-Ouest
- Inde Centre
- Sud de l’Inde
- Japon Est
- OuJapon Est
- Centre-Nord des États-Unis
- Europe Nord
- Norvège Est
- Qatar Central
- Afrique du Sud Nord
- États-Unis - partie centrale méridionale
- Suisse Nord
- Sud du Royaume-Uni
- Ouest du Royaume-Uni
- Europe Ouest
- Centre-USA Ouest
- USA Ouest
- USA Ouest 2
- USA Ouest 3
Régions prenant en charge 80 vCores maximum avec zones de disponibilité pour l’usage général
Actuellement, la prise en charge des zones de disponibilité pour 80 vCores maximum en serverless pour le niveau d’usage général est limitée aux régions suivantes avec d’autres régions prévues :
- USA Est
- Europe Nord
- Europe Ouest
- USA Ouest 2
Régions prenant en charge 80 vCores maximum avec zones de disponibilité pour l’hyperscale
Actuellement, la prise en charge des zones de disponibilité pour 80 vCores maximum en serverless pour le niveau d’hyperscale est limitée aux régions suivantes avec d’autres régions prévues :
- USA Centre
- USA Est
- Europe Nord
- Europe Ouest
- USA Ouest 2
- USA Ouest 3
Contenu connexe
- Pour démarrer, consultez Démarrage rapide : Créez une base de données unique : base de données Azure SQL.
- Pour connaître les choix de niveau de service serverless, consultez Usage général et Hyperscale.