Gestion des ressources dans les pools élastiques denses

S’applique à : Azure SQL Database

Les pools élastiques Azure SQL Database sont une solution économique pour gérer de nombreuses bases de données avec diverses utilisations des ressources. Toutes les bases de données d’un pool élastique partagent la même allocation de ressources, telles que l’UC, la mémoire, les threads de travail, l’espace de stockage et tempdb, en partant du principe que seul un sous-ensemble de bases de données dans le pool utilisera des ressources de calcul à un moment donné. Cette hypothèse permet aux pools élastiques d’être rentables. Au lieu de payer pour toutes les ressources dont chaque base de données individuelle peut éventuellement avoir besoin, les clients paient un ensemble de ressources bien plus petit, partagé entre toutes les bases de données du pool.

Gouvernance des ressources

Le partage de ressources nécessite que le système contrôle minutieusement l’utilisation des ressources pour réduire l’effet de « voisinage bruyant », où une base de données avec une consommation de ressources élevée perturbe les autres bases de données dans le même pool élastique. Azure SQL Database atteint ces objectifs en implémentant la gouvernance des ressources. En même temps, le système doit fournir suffisamment de ressources pour que des fonctionnalités telles que la haute disponibilité et la récupération d’urgence (HADR), la sauvegarde et la restauration, la surveillance, le Magasin des requêtes, le réglage automatique et autres fonctionnent de manière fiable.

Le principal objectif de conception des pools élastiques est d’être rentable. C’est la raison pour laquelle le système autorise intentionnellement les clients à créer des pools denses, c’est-à-dire des pools dont le nombre de bases de données approche ou atteint le maximum autorisé, mais avec une allocation modérée des ressources de calcul. Pour la même raison, le système ne réserve pas toutes les ressources potentiellement nécessaires pour ses processus internes, mais autorise le partage des ressources entre les processus internes et les charges de travail utilisateur.

Cette approche permet aux clients d’utiliser des pools élastiques denses afin d’obtenir des performances adéquates et de réaliser des économies substantielles. Toutefois, si la charge de travail sur de nombreuses bases de données d’un pool dense est suffisamment intense, la contention des ressources devient importante. La contention des ressources réduit le niveau de performance des charges de travail utilisateur et peut avoir un impact négatif sur les processus internes.

Quand une contention de ressources se produit dans un pool très dense, les clients peuvent choisir une ou plusieurs des actions suivantes pour les atténuer :

• Réglez la charge de travail de requête de façon à réduire la consommation de ressources ou à répartir celle-ci sur plusieurs bases de données au fil du temps.
• Réduisez la densité du pool en déplaçant certaines bases de données vers un autre pool ou en les rendant autonomes.
• Montez le pool en puissance pour obtenir davantage de ressources.

Pour obtenir des suggestions sur la façon d’implémenter les deux dernières actions, consultez Recommandations opérationnelles plus loin dans cet article. La réduction de la contention des ressources profite à la fois aux charges de travail utilisateur et aux processus internes et permet au système de conserver le niveau de service attendu de manière fiable.

Surveillance de la consommation des ressources

Pour éviter une détérioration des performances en raison d’une contention des ressources, les clients qui utilisent des pools élastiques denses doivent surveiller de façon proactive la consommation des ressources et prendre des mesures en temps opportun si l’augmentation de la contention des ressources commence à perturber les charges de travail. La surveillance continue est importante, car l’utilisation des ressources dans un pool change au fil du temps, en raison des modifications apportées à la charge de travail utilisateur, des modifications des volumes et de la distribution de données, des modifications de la densité du pool et des modifications du service Azure SQL Database.

Azure SQL Database fournit plusieurs mesures pertinentes pour ce type de surveillance. Le dépassement de la valeur moyenne recommandée pour chaque métrique indique une contention des ressources dans le pool, qui doit être résolu à l’aide de l’une des actions mentionnées précédemment.

Pour envoyer une alerte lorsque l’utilisation des ressources en pool (UC, E/S de données, E/S de journal, workers, etc.) dépasse un seuil, envisagez de créer des alertes via le portail Azure ou la cmdlet PowerShell Add-AzMetricAlertRulev2. Lorsque vous contrôlez des pools élastiques, envisagez de créer des alertes pour des bases de données individuelles du pool si nécessaire dans votre scénario. Pour un exemple de surveillance de pools élastiques, consultez Superviser et gérer les performances d’Azure SQL Database dans une application SaaS multilocataire.

En plus de ces métriques, Azure SQL Database fournit un affichage qui retourne les limites réelles de la gouvernance des ressources, ainsi que des affichages supplémentaires qui retournent des statistiques d’utilisation des ressources au niveau de la liste de ressources partagées et au niveau du groupe de charge de travail.

Ces affichages peuvent être utilisés pour surveiller l’utilisation des ressources et résoudre la contention des ressources en temps quasi-réel. La charge de travail utilisateur sur les réplicas primaires et secondaires accessibles en lecture, y compris les géoréplications, est classée dans la liste de ressources partagées SloSharedPool1 et dans le groupe de charges de travail UserPrimaryGroup.DBId[N], où N correspond à la valeur de l’ID de base de données.

Outre la surveillance de l’utilisation actuelle des ressources, les clients qui utilisent des pools denses peuvent gérer les données d’utilisation des ressources historiques dans un magasin de données distinct. Ces données peuvent être utilisées dans une analyse prédictive pour gérer de manière proactive l’utilisation des ressources en fonction des tendances historiques et saisonnières.

Recommandations opérationnelles

Laissez une marge de manœuvre suffisante aux ressources. En cas de détérioration des performances et de contention des ressources, l’atténuation peut impliquer le déplacement de certaines bases de données hors du pool élastique concerné ou la montée en puissance du pool, comme indiqué plus haut. Toutefois, ces actions nécessitent des ressources de calcul supplémentaires pour s’exécuter. En particulier, pour les pools Premium et Critique pour l’entreprise, ces actions nécessitent le transfert de toutes les données pour les bases de données déplacées, ou pour toutes les bases de données du pool élastique si le pool est monté en puissance. Le transfert de données est une opération durable et gourmande en ressources. Si le pool est déjà soumis à une forte sollicitation des ressources, l’opération d’atténuation proprement dite détériorera encore davantage les performances. Dans les cas extrêmes, il peut être impossible de résoudre la contention de ressources via la montée en puissance du pool ou le déplacement de bases de données, car les ressources requises ne sont pas disponibles. Dans ce cas, la réduction temporaire de la charge de travail des requêtes sur le pool élastique concerné peut être la seule solution.

Les clients qui utilisent des pools denses doivent surveiller étroitement les tendances d’utilisation des ressources comme décrit précédemment et prendre des mesures d’atténuation tant que les métriques restent dans les plages recommandées et qu’il existe toujours suffisamment de ressources dans le pool élastique.

L’utilisation des ressources dépend de plusieurs facteurs qui changent au fil du temps pour chaque base de données et chaque pool élastique. L’obtention d’un rapport prix/performances optimal dans les pools denses requiert une surveillance et un rééquilibrage continus, c’est-à-dire le déplacement des bases de données des pools très utilisés vers des pools qui le sont moins et la création de pools le cas échéant pour répondre à une charge de travail accrue.

Ne déplacez pas les bases de données « chaudes » . Si la contention de ressources au niveau du pool est principalement due à un petit nombre de bases de données fortement utilisées, il peut être tentant de déplacer ces bases de données vers un pool moins utilisé ou de les rendre autonomes. Toutefois, il est déconseillé d’effectuer cette opération alors qu’une base de données reste fortement utilisée, car l’opération de déplacement détériorera davantage les performances, à la fois pour la base de données en cours de déplacement et pour l’ensemble du pool. Au lieu de cela, attendez plutôt que le taux d’utilisation diminue ou déplacez les bases de données moins utilisées pour alléger la sollicitation des ressources au niveau du pool. Toutefois, le déplacement de bases de données ayant une utilisation très faible ne fournit aucun avantage dans ce cas, car il ne réduit pas de façon significative l’utilisation des ressources au niveau du pool.

Créez des bases de données dans un pool de « quarantaine » . Dans les scénarios où des bases de données sont créées fréquemment, telles que les applications utilisant le modèle de locataire par base de données, il existe un risque qu’une nouvelle base de données placée dans un pool élastique existant consomme de manière inattendue des ressources importantes et perturbe les autres bases de données et les processus internes du pool. Pour atténuer ce risque, créez un pool de « quarantaine » distinct avec une allocation généreuse de ressources. Utilisez ce pool pour les nouvelles bases de données ayant des modèles de consommation de ressources encore inconnus. Lorsqu’une base de données est restée dans ce pool pendant un cycle d’activité, par exemple une semaine ou un mois, et que sa consommation de ressources est connue, elle peut être déplacée vers un pool ayant une capacité suffisante pour prendre en charge cette utilisation supplémentaire des ressources.

Surveiller l’espace utilisé et alloué. Quand l’espace du pool alloué (taille totale de tous les fichiers de base de données stockés pour toutes les bases de données dans un pool) atteint la taille de pool maximale, des erreurs d’espace insuffisant peuvent se produire. Si l’espace alloué est en hausse et en passe d’atteindre la taille de pool maximale, les options d’atténuation sont les suivantes :

• déplacer des bases de données hors du pool pour réduire l’espace total alloué ;
• réduire la taille des fichiers de base de données pour diminuer l’espace alloué vide dans les fichiers ;
• effectuer un scale-up du pool vers un objectif de service avec une taille de pool maximale supérieure.

Si l’espace du pool utilisé (taille totale des données de toutes les bases de données d’un pool, à l’exclusion de l’espace vide dans les fichiers) est en hausse et en passe d’atteindre la taille de pool maximale, les options d’atténuation sont les suivantes :

• déplacer des bases de données hors du pool pour réduire l’espace total utilisé ;
• déplacer (archiver) des données hors de la base de données ou supprimer les données qui ne sont plus nécessaires ;
• implémenter la compression des données ;
• effectuer un scale-up du pool vers un objectif de service avec une taille de pool maximale supérieure.

Évitez les serveurs trop denses. Azure SQL Database prend en charge un maximum de 5 000 bases de données par serveur. Les clients qui utilisent des pools élastiques ayant des milliers de bases de données peuvent envisager de placer plusieurs pools élastiques sur un seul serveur, avec le nombre total de bases de données allant jusqu’à la limite prise en charge. Toutefois, les serveurs englobant plusieurs milliers de bases de données constituent des défis opérationnels. Les opérations qui requièrent l’énumération de toutes les bases de données sur un serveur, par exemple l’affichage de bases de données dans le portail, seront plus lentes. Les erreurs opérationnelles, telles que la modification incorrecte des connexions au niveau du serveur ou des règles de pare-feu, perturbent un plus grand nombre de bases de données. La suppression accidentelle du serveur nécessite une assistance de la part du Support Microsoft afin de récupérer les bases de données sur le serveur supprimé, ce qui entraîne une interruption prolongée pour toutes les bases de données concernées.

Limitez les bases de données par serveur à un nombre inférieur à la valeur maximale prise en charge. Dans de nombreux scénarios, l’utilisation de 1 000 à 2 000 bases de données par serveur est optimale. Afin de réduire les risques de suppression accidentelle d'un serveur, placez un verrou de suppression sur le serveur ou son groupe de ressources.

Exemples

Afficher les paramètres de capacité d’une base de données individuelle

Utilisez la vue de gestion dynamique sys.dm_user_db_resource_governance pour afficher les paramètres réels de configuration et de capacité utilisés par la gouvernance des ressources dans la base de données actuelle ou le pool élastique. Pour plus d’informations, voir sys.dm_user_db_resource_governance.

Exécutez cette requête dans une base de données de pool élastique. Toutes les bases de données du pool ont les mêmes paramètres de gouvernance des ressources.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Surveillance de la consommation globale de ressources du pool de ressources

Utilisez la vue de catalogue système sys.elastic_pool_resource_stats pour surveiller la consommation des ressources de l’ensemble du pool. Pour plus d’informations, voir sys.elastic_pool_resource_stats.

Cet exemple de requête pour afficher les 10 dernières minutes doit être exécuté dans la base de données master du serveur Azure SQL logique contenant le pool élastique souhaité.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Surveillance de la consommation individuelle des ressources de base de données

Utilisez la vue de gestion dynamique sys.dm_db_resource_stats pour surveiller la consommation de ressources de base de données individuelles. Pour plus d’informations, voir sys.dm_db_resource_stats. Il existe une ligne pour chaque période de 15 secondes, même s’il n’y a aucune activité. Les données historiques sont conservées pendant environ une heure.

Cet exemple de requête pour afficher les 10 dernières minutes de données doit être exécuté dans la base de données souhaitée.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Pour une durée de rétention plus longue avec moins de fréquence, envisagez la requête suivante sur sys.resource_stats, qui s’exécute dans la base de données master du serveur logique Azure SQL. Pour plus d’informations, voir sys.resource_stats (Azure SQL Database). Une ligne existe toutes les cinq minutes, et les données historiques sont conservées pendant deux semaines.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Surveillance de l’utilisation de la mémoire

Cette requête calcule la métrique oom_per_second de chaque pool de ressources pour l’historique récent, en fonction du nombre d’instantanés disponibles. Cet exemple de requête permet d’identifier le nombre moyen récent d’allocations de mémoire ayant échoué dans le pool. Cette requête peut être exécutée dans n’importe quelle base de données d’un pool élastique.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Surveillance de l’utilisation de l’espace du journal tempdb

Cette requête retourne la valeur actuelle de la métrique tempdb_log_used_percent, en présentant l’utilisation relative du journal des transactions tempdb par rapport à sa taille maximale autorisée. Cette requête peut être exécutée dans n’importe quelle base de données d’un pool élastique.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Étapes suivantes

• Une introduction aux pools élastiques est disponible dans le document Les pools élastiques vous aident à gérer et à mettre à l'échelle plusieurs bases de données dans Azure SQL Database.
• Pour plus d’informations sur le réglage des charges de travail de requête afin de réduire l’utilisation des ressources, consultez Surveillance et réglage et Surveillance et réglage des performances.