VM SQL Server 2012 sur Azure : SQLIO suite

Suite à la remarque extrêmement pertinente de Thomas Conté (Blog , Twitter) Technical Evangelist, Windows Azure chez Microsoft au sujet de mon article sur les performance disque d’une VM dans Windows Azure, je me devais de poursuivre mes tests. J’avoue manquer un peu de temps, j’ai donc été à l’essentiel.

Je n’ai malheureusement pas pu poursuivre les tests sur ma VM XL (8 cœurs / 14 GB). Une fois mon bench précédent terminé, j’avais stoppé ma VM. Lorsque j’ai voulu la redémarrer, un message d’erreur m’informait que cela n’était pas possible ! Toute activité sur cette VM donnerait lieu à facturation (soit, pourquoi pas après tout, j’ai utilisé cette VM, du disque, etc.), mais la seule option qui m’était présentée était de supprimer ma VM!

J’ai donc créé une nouvelle VM, Small cette fois-ci (1 cœur, 1,5 GB RAM). J’ai lancé un SQLIO sur le disque temporaire qui est présenté. Ce même disque où j’ai effectué mes tests sur la VM XL. Cette fois ci, il n’y a pas 1.3 TB de stockage temporaire ultra performant (comme l’ont montrés les tests de l’article précédent) mais seulement 70 GB. On peut déjà noter que le volume du disque “Temporary Storage” est variable suivant la catégorie de VM que l’on sélectionne.

Les performance sont correctes, sans pour autant être au niveau de la VM XL avec un latence tout a fait correcte :

imageimage

Ensuite, j’ai aussi ajouté à cette VM un disque persistant, sur lequel j’ai rejoué le même scénario SQLIO. Et là, par contre, les performance ne sont plus du tout du même ordre. On est clairement un ton en dessous.

imageimage

Le stockage temporaire propose 15 000 IOPS (pour un read random 64K), alors que le stockage permanent ne permet que 1000 IOPS. La latence moyenne proche de zéro sur le disque temporaire dépasse les 10 ou 15 ms sur le disque persistant.

Il y a fort a parier que soir les volumes des VMs sont réparties sur des baies dont les performances ne sont pas comparables entre une XL et une S, soit il s’agit des mêmes baies mais les raid groups sont taillés différemment avec plus de disques et donc de répondant pour des VMs XL.

Que conclure de ce nouveau test ?

  • le stockage (en volume et en performance) est liée à la “taille” de la VM.
    • en XL le disque fait 1.3 TB et 64 000 IOPS (read random 64K)
    • en S le disque taille 70 GB et 15 000 IOPS (read random 64K)
    • Il est probable que les raid group ou les disques
  • Le stockage persistant est bien plus lent que le stockage temporaire.

Thomas mettait en garde, à juste titre, sur le côté temporaire de ces disques : “Il faut faire attention au fait que ces disques ne sont pas persistants : leur contenu disparait si l’on détruit la VM…”.

Pour ma part, ma réflexion est la suivante : les disques temporaires survivent à un reboot. Donc ils sont tout à fait valables pour stocker une base de donnée (et vu les performances, je ne vais probablement pas passer à côté de cette opportunité). Maintenant, si je détruis ma VM, cela veut bien dire que je ne suis plus intéressé par le service (SQL) rendu. Dans ce cas, finalement, peu m’importe si les données sont définitivement supprimées. Je pense néanmoins que j’aurais pris soin d’en faire une sauvegarde.

Et là, le disque permanent trouve tout son sens. OK, il est lent. Il faudra s’en accommoder. Mais il garde comme avantage précieux le fait de pouvoir être “géo-répliqué”, c’est à dire répliqué sur une autre datacenter.

image

Il se peut qu’en cas de crash de la VM, mes données soient perdus si elles étaient stockées sur ce disque temporaire … Maintenant, si ma VM crashe alors que les données sont un disque persistant, il y a fort à parier qu’il ne soit pas possible de rattacher les bases à une nouvelle instance, même avec un rebuild log. Donc il faudrait repartir d’un backup pour revenir opérationnel.

Le fait qu’une VM tourne dans le cloud ne doit pas vous empêcher de garder de vieux et bons réflexes : surveillance et sauvegarde…

Il se peut aussi que mon raisonnement ne soit pas bon, dans ce cas, faites le moi savoir au travers de vos commentaires. La discussion est ouverte …

Note : Je n’ai pas publié tous les graphes issus du PAL pour cette batterie de tests, si cela vous intéresse, n’hésitez pas à m’envoyer un email.

A propos Christophe

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

4 commentaires pour VM SQL Server 2012 sur Azure : SQLIO suite

  1. Il serait intéressant de savoir l’architecture disque dans les 3 cas de ton test. Combien de disques, répartis de quelle manière etc … Je ne sais pas si l’info est disponible🙂

  2. Ping : 16 volumes Windows Azure : le test SQLIO | Christophe LAPORTE – Consultant SQL Server

  3. Ping : VM Amazon HI1 : performance disque avec SQLIO | Christophe LAPORTE – Consultant SQL Server

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 )

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 )

Photo Google+

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

Connexion à %s