Test d’IOPS dans une VM EC2 (Amazon AWS)

Le fait de travailler avec de nombreux clients (près de 130 différents ) offre des avantages.

Le premier bénéficie à chacun d’eux. Certes les compétences sur la plateforme SQL Server (choix d’infrastructure, performance, migration, troubleshooting, virtualisation, cloud …) est bien entendu importante.

Mais, mes clients sont aussi à la recherche d’expérience. 20 ans sur SQL Server, ses différentes versions, et autant de Windows !! Et quoi que l’on en dise, tout expert que l’on se prétend être, on apprend tous les jours avec un produit tel que SQL Server. Si vous croisez un consultant vous assurant tout connaitre, je penche pour un cas de mythomanie aggravée. 20 ans que je travaille sur ce SGBD, MVP depuis 10 ans, certifié MCM (100 personnes dans le monde), je n’ai pas d’hésitation à dire que je ne connais pas tout de SQL Server. Bref, accumuler des expériences chez chacun de ces clients apporte une valeur ajoutée indéniable  qui profitera à tous ces clients, et aux nouveaux … Avoir été confronté à un problème, c’est diagnostiquer plus rapidement et avancer plus rapidement vers la solution. C’est aussi proposer l’architecture adéquate en fonction des besoins.

Tout cela pour dire que je “kiffe” mes clients. Et certains sont joueurs, pour mettre en place des infrastructures hors du commun, avec des IOPS hors norme OnPrem, des VLDS de plusieurs dizaines de TB, ou des cluster Multi Régions sur cloud public.

Et certains sont suffisamment cool pour m’autoriser à partager des tests faits durant ces missions.

Aujourd’hui, c’est le cas d’un bench IOPS sur des VMs Amazon. Ne perdez pas de vue qu’il s’agit là d’un point de vue DBA, il est probable qu’un architecte certifié AWS ait un avis légèrement différent.

Les tests effectués sont strictement pragmatiques et répondent à une question simple : comment choisir mon sous système disque pour des VMs sur AWS.

Les tests ont été réalisés à l’aide Microsoft DISKSPD, successeur de SQLIO, qui portait bien mal son nom …

.\diskspd -b8K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat > resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b32K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b64K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b128K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b256K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt 

Un premier test consiste à mesurer la performance des disques “General Purpuse SSD”, dit GP2 pour les intimes.

La règle de base dit : 3 IOPS par GB, jusqu’à une limite de 10 000 IOPS.

Mais à cela s’ajoute un composant qui mérite TOUTE notre attention : un crédit de 5 400 000 IOPS qui permet de “monter” à 3000 IOPS sur des petits volumes ( < 1TB ).

image

Effectivement, sur un volume de 10GB, théoriquement limité à 30 IOPS, on constate l’effet burst io :

image

Le “surcroit de puissance” est bien présent.

Dès que l’on opte pour un volume plus grand, 5TB, l’effet disparait et on retrouve la règle de 3 IOPS/GB capés à 10 000 IOPS.

image

Si l’on se base sur ces chiffres, utiliser des gros disques est donc plus performant que d’utiliser des volumes plus petits.

Dans l’ancien temps Sourire, entendez pas là OnPrem avec des bons vieux disques rotatifs, pour gagner en performance, on strippait les disques (les bons vieux RAID xx). Pour ce cas précis la redondance ne m’intéresse pas. Un RAID 0 suffit.

Faisons un calcul théorique pour une volumétrie allant jusqu’à 14 TB : on peut utiliser 1 seul volume ou bien un stripe de 4 volumes. Le tableau ci dessous présente le calcul des IOPS théoriques :

image

Si l’on pivote les données pour mesurer les différences en fonction de la volumétrie totale, on constate que les performances sont similaires pour une volumétrie inférieure ou égale à 3TB (sans burst io) et, au delà, agréger les volumes devient plus intéressant Au delà, du fait du plafond d’IOPS, agréger les volumes est plus intéressant de part le plafond de 10 000 IOPS :

image

Mais si l’on ajoute l’effet Burst IO, l’agrégation de volumes est systématiquement plus performante.

image

Donc dans tous les scénarios, utiliser l’agrégation de volumes permet un gain de performance, tant que le crédit du burst IO n’est pas épuisé !!!

La question qui se pose donc naturellement à ce moment du test est : “quelle est la durée de vie de ce crédit d’IOPS ?”

En fait, cela dépend de la volumétrie du disque :

image

Dans tous les cas, vous avez 30 minutes minimum de burst IO. Donc à moins d’être systématiquement au maximum des performances des volumes ce genre de configuration peut s’appliquer à une très grande majorité des VMs supportant SQL Server.

Une fois le crédit épuisé, il faut par contre patienter entres 40 minutes (pour un volume de 750 GB) et 15 heures pour voir le crédit totalement ré-alloué.

En fonction de votre charge de travail, vous serez peut être en mesure de fonctionner à 3000 IOPS quand cela est nécessaire, durant toute votre période ouvrée Sourire . 4 volumes de 250 vous offrent 40 minutes de Burst IO avec une attente de 2 heures pour le remplir en totalité. Probablement que 80 ou 90% des charges de travail SQL sont compatibles avec cette topologie disque.

néanmoins, pour ceux qui recherche un maximum de performance, il existe aussi la possibilité de bénéficier d’IOPS provisionnés  (io1 : 50 IOPS / GB) avec un maximum de 32 000 IOPS atteint ) 640 GB.

image

Pour ce nouveau test, sur une instance R5DXL, pour les curieux, je vérifie que mes résultats sur le volume GP2 sont bien identiques au premier tests :

image

OK, tout est correct.

On provisionne donc ce volume à 10 000 IOPS:image

Sur des IOs 8K on est proche de la limite. Correct donc.

Si l’on monte encore le niveau de performance pour provisionner 25 000 IOPS, on constate cette fois ci que le niveau de performance attendu n’est pas au rendez vous !

image

En modifiant les paramètres du test, 16 threads et une profondeur de file  à 16, les performance s’effondrent totalement, de manière incompréhensibles !

image

Un point à investiguer, donc, mais grosse déception.

Un autre point est non négligeable lors du choix de la configuration : le tarif.

Partons du principe que le besoin en volumétrie est faible (seulement pour simplifier le calcul, si cela ne vous convient pas, Excel est votre ami ….) : 200 GB:

  • 200 GB en IOPS provisionnés
    • 10 000 IOPS réels
    • 320 MB de bande passante
    • 747 US$ par mois
  • 4 EBS GP2 de 50 GB
    • 12 000 IOPS avec Burst IO
    • 4 x 128 MB de bande passante (à valider toute fois)
    • 22 US$ par mois

22 $ contre 747 $. La différence est énorme pour au final peu d’IOPS supplémentaires. Est-ce que les 10 KIOPS sont utilisés en permanence sans laisser le temps au crédit du Burst IO de se recharger ??

par contre pour une volumétrie supérieurs à 4 TB, même avec 4 volumes > à 1 TB on perd le burst IO, donc peut être cette stratégie d’IO provisionnés prend de l’intérêt, mais à quel cout ?? Bien des questions à se poser.

Le test ne serait pas complet dans parler des disques éphémères, car il s’agit bien là d’un des intérêt des EC2 R5DXL, pour positionner la TempDB sur des disques locaux rapides.

Sans être au niveau attendu pour du NVMe, on est sur un cloud public et l’on doit satisfaire plusieurs clients …, il faut avouer que cela permet de donner un bol d’oxygène à SQL Server très friand d’IOs sur la TempDB.

image

C’est clairement la latence qui bénéficie de ces disques locaux.

A quelques semaines de Noel, si je devais faire ma liste au gros bonhomme en habits rouge, pour héberger du SQL Serveur, je voudrais bien une EC 2 de type R5DXL avec

  • EBS Simple pour l’OS
  • 4 volumes GP2 (General purpose SSD) en RAID 0, RAID 5 ou RAID 10 pour les data files.
  • 2 (ou 4) volumes GP2 (General purpose SSD) en RAID 0, RAID 1, (RAID 10) pour les log files.
  • Un volume éphémère pour la base TempDB.

Edit 2018-11-27 : Amazon double les IOPS provisionnés : 60 000 IOPS désormais.

Today we are announcing 2x improvement in peak performance of Provisioned IOPS SSD (io1) Volumes from 32,000 IOPS to 64,000 IOPS and from 500 MB/s to 1,000 MB/s of throughput per volume when attached to Nitro system EC2 instances.

These performance improvements make it even easier to run applications requiring high performance storage, such as large transactional databases, big data analytics, and log processing applications.

Happy IOPS on AWS !

Publicités

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans Amazon EC2, est tagué , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s