Dynamics AX et SQL Resource Governor

Un de mes clients éprouvait des problèmes de performance avec leur serveur SQL. Après avoir utilisé le script de Glen Barry afin d'effectuer un diagnostique, il était évident que SQL souffrait de congestion au niveau de la mémoire et des disques. De plus, j’ai constaté que la majorité des ressources du serveur était utilisée par des  bases de données autre que MicrosoftDynamicsAX et MicrosoftDynamicsAX_model. Les instructions du client étaient claires: les bases de données de Microsoft Dynamics AX doivent avoir priorité sur les ressources.

Le client possède une architecture SQL AlwaysOn Availability groups avec 3 serveurs de réplication, dont un dans un leur site de recouvrement (DR). Les serveurs SQL sont hébergés sur la plateforme Azure dans un mode de déploiement Classic.  La taille des serveurs est déjà au maximum 8vCPU, 56GB et il est impossible pour le moment de migrer les serveurs dans le mode Azure Resource Manager (ARM). Impossible aussi pour l'instant de déplacer les autres bases de données.

C’est un excellent cas pour Resource Governor! C'est la première fois que j'utilisais Resource Governor parce que lors de toutes mes implantations précédentes, les clients ont décidé d'y aller avec une architecture SQL dédiée pour Dynamics AX.

Je ne vais pas entrer dans les détails de Resource Governor, mais en résumé c’est un outil qui permet de limiter la consommation de CPU, mémoire et IOPS. Bref, un outil parfait dans mon cas afin de limiter les ressources utilisées par les autres bases de données sur le serveur et laisser plus de performance pour Dynamics AX.

Tout d’abord, j’ai créé un nouveau Resource Pool nommé DynamicsAX. Mon intention est de rediriger toutes les sessions provenant des serveurs AOS vers ce Resource Pool. Je lui assigne un minimum de 50% du CPU et un minimum de 70% de la mémoire.  Prenez note que je ne peux pas assigner un minimum et maximum de IOPS via l’interface graphique, l'option est disponible seulement via T-SQL.

Ensuite, j’ai créé 3 différents workload groups. Un pour le serveur AOS qui dessert les utilisateurs, un pour le serveur AOS qui exécute les batch et un pour le serveur AOS qui dessert les utilisateurs Enterprise Portal.


Ensuite, j'ai créer un classifier. Le classifier permet de rediriger les sessions dans un workload group. Le workload group appartient à un Resource Pool. Dans ce cas-ci, j'ai décidé d'utiliser HOST_NAME() pour déterminer la source de la session en sachant que mes serveurs AOS se connectent à la base de données Dynamics AX uniquement via le service AOS. Il est aussi possible d’utiliser d’autre variable comme APP_NAME(), HOST_NAME(), ORIGINAL_DB_NAME(), etc.

CREATE FUNCTION dbo.DynamicsAXClassifier()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
DECLARE @WorkloadGroup AS SYSNAME
IF(HOST_NAME() = 'AOSSERVERNAME_USERS')
SET @WorkloadGroup = 'AOS_Users'
ELSE IF (HOST_NAME() = 'AOSSERVERNAME_BATCH')
SET @WorkloadGroup = 'AOS_Batch'
ELSE IF (HOST_NAME() = 'AOSSERVERNAME_EP')
SET @WorkloadGroup = 'AOS_EP'
ELSE
SET @WorkloadGroup = 'default'
RETURN @WorkloadGroup
END
GO


Toutes les sessions qui ne proviennent pas des serveurs AOS iront dans le resource pool default. Celui -ci a un accès maximum de 100% du CPU et de la mémoire, mais étant donné que le Resource Pool DynamicsAX a une réservation de 70% (CPU) et 70% (mémoire), ceci veut dire que le nouveau maximum est 30% et 30%.

Je voulais ajouter des limitations supplémentaires au Resource Pool default. Dans mon cas, la configuration global de MAXDOP est 4. Mais, il est possible de limiter MAXPOP à 1 pour toute requête autre que Dynamics AX:


Pour finir, j’ai modifié la limite de IOPS a 1000 pour le Resource Pool default:

ALTER RESOURCE POOL [default] WITH(
                min_cpu_percent=0, 
max_cpu_percent=100, 
min_memory_percent=0, 
max_memory_percent=100, 
cap_cpu_percent=100, 
AFFINITY SCHEDULER = AUTO
min_iops_per_volume=0, 
max_iops_per_volume=1000)
GO

Après que le tout est en place, il faut redemarrer les service AOS afin d'initier de nouvelles sessions. Ensuite, j’utilise un rapport SRRS SQL Server Resource Governor Monitoring reports pour surveiller l’utilisation des ressources dans les Ressources Pools.

Finalement, vous avez surment remarqué qu’il y a plusieurs options dont je n’ai pas mentionné. Je suggère la lecture de Resource Governor sur simple-talk afin de connaitre tous les détails.
Latest