Après 10 années d’expérience en implantation du système Dynamics AX, je trouve que la performance des disques est la composante la plus négligée lors du design de l’infrastructure. Il est facile de dire qu’un serveur AOS a besoin de 4 ou 8 cœurs avec 12 ou 16GB de mémoire RAM. Mais qu’est-ce qui en est de la performance des disques du serveur SQL ?
Maintenant que nous avons configuré une machine virtuelle dans Azure avec des disques haute performance et nous avons récolté les métriques. Qu’est ce qu’on fait ensuite ?
Il y a quatre scénarios qui me viennent à l’esprit.
Note: je mentionne souvent le nombre de IOPs. Quand je parle de IOPs, j’assume que la latence est très faible. Il faut savoir qu’il est possible d’avoir 25 000 IOPs avec 100ms de délai de latence, ce qui est très mauvais. Si vous n’êtes pas familier avec ce concept, je vous conseille d’aller lire les blogues suivants
Scénario #4 - Système existant avec un problème de performance de disques
Maintenant que nous avons configuré une machine virtuelle dans Azure avec des disques haute performance et nous avons récolté les métriques. Qu’est ce qu’on fait ensuite ?
Il y a quatre scénarios qui me viennent à l’esprit.
Note: je mentionne souvent le nombre de IOPs. Quand je parle de IOPs, j’assume que la latence est très faible. Il faut savoir qu’il est possible d’avoir 25 000 IOPs avec 100ms de délai de latence, ce qui est très mauvais. Si vous n’êtes pas familier avec ce concept, je vous conseille d’aller lire les blogues suivants
Scénario #1 - Implantation d’un nouveau système AX sur un système de stockage existant
La majorité des entreprises ont déjà un système de stockage en place. Peu importe la configuration du système de stockage et des disques, le consultant va demander d’avoir les meilleures performances possible pour le serveur SQL. L’entreprise doit généralement vivre avec les performances offertes.
Toutefois, en tant que consultant, je vous conseille de faire des tests avec Diskspd sur votre serveur SQL avant de commencer l'implantation.
Scénario #2 - Implantation d’un environnement AX dans Azure
Il est maintenant possible de déployer Dynamics AX 2012 R3 dans le Cloud. Il y a un gros avantage dans le Cloud: l’entreprise paye en fonction des performances désirées. Voici des tableaux qui représente les coûts du stockage Premium dans Azure. Il coûte environ 850$ par mois pour 25 000 IOPs et je peux avoir environ 13 000 IOPs pour la moitié du prix.
Note: Les lignes en rouge représentent une restriction du dimensionnement de la machine virtuelle. Par exemple, DS12 possède une limitation de 12 800 IOPs.
Source: Sizes for virtual machines
Est-ce que vous voyez le dilemme ? Ai-je besoin de 25 000 IOPs ou de 13 000 IOPs.
Scénario #3 -Implantation d’un nouveau système AX qui requiert une nouvelle unité de stockage
Le client doit acheter une nouvelle unité de stockage. Que ce soit un SAN, un NAS ou des disques locaux, le client veut savoir ce dont Dynamics AX a besoin en terme de performance de disques. La question est légitime lorsque le SSD coûte 8000$ l’unité ! C’est le scénario le plus difficile puisqu’on ne peut pas profiter de l’élasticité du Cloud.
Scénario #4 - Système existant avec un problème de performance de disques
De façon générale, le client va ajouter de la performance au système de stockage. Sois en ajoutant de nouveaux disques ou en déplaçant les données sur une unité de stockage plus performant. Si le client doit acheter un nouveau système de stockage, alors vous vous retrouvez avec le scénario numéro 3.
Donc, combien d’IOPs ai-je besoin ?
J’ai posé à Microsoft et j’ai aussi posé la question à plusieurs consultants: comment puis-je planifier correctement mon stockage pour mon serveur SQL Dynamics AX ? Je n’ai jamais reçu une réponse claire et précise. Tout simplement parce qu’il n’y a pas assez d’information à ce sujet et aucun outil pour nous aider. Les seuls donnés se trouvent dans le document Microsoft Dynamics AX 2012 Day in the Life Benchmark Detail.
Microsoft a simulé une charge de travail et a récolté les métriques de performance des serveurs. Le test a été effectué avec différents types de transaction pour un total de 778 783 transactions AX par heure (12 979 transactions AX par seconde).
Pour répondre à la demande, le système de stockage a dû générer en moyenne 34 610 176 opérations par seconde en écriture et 830 575 opérations par seconde en lecture pour un total de 35 440 751 IOPS pour le disque de données seulement.
Ceci représente
- 97% écriture et 3% lecture.
- une transaction AX égale en moyenne 2 730 opérations SQL (35 440 751/12 979)
- Attention, le test a été effectué avec le système AX 2012 RTM. Ceci veut dire que la base de données contient les données et le code.
La question est: qu'est-ce qu'une opération AX ? Dans cet exemple, voici une Sales Order:
Alors, on revient à la question. Combien d’IOPs ai-je besoin ? La réponse que vous allez lire sur internet est: ça dépend de l’utilisation du système. La vraie réponse est: c’est trop complexe à calculer, il n’y a pas d’outil mis à notre disposition pour calculer le nombre de IOPS en fonction de l’utilisation du système.
Donc, le mieux qu'on peut faire est d'obtenir une estimation par heure du nombre de transactions effectué par les utilisateurs + les transactions effectuées par des intégrations externes + les transactions effectuées par le système de batch. Ensuite, diviser ce chiffre par 3600 afin d'avoir théoriquement le nombre de transactions AX par secondes. Ensuite, basé sur les calculs ci-haut, on peut dire qu'il faut environ 2500 IOPs par transaction AX si l’utilisation du système est similaire à celle testée par Microsoft.
Finalement, la clé est de collecter le maximum d’information lors de vos implémentations et de vous assurer que la configuration des disques et de SQL est optimale en tenant compte qu’un délai de latence faible avec un maximum d’IOPs vous donnera les meilleures performances.