16 volumes Windows Azure : le test SQLIO

Lors de deux précédents billets, j’ai testé les performances disques des machines virtuelles sur Windows Azure.

Lors du premier test, j’ai été très agréablement surpris par le niveau de performance du disque temporaire.

image

Le problème du disque temporaire est … son côté temporaire. Il résiste à un reboot, donc on peut tout a fait imaginer poser une base de données sur ce volume performant en IO et pourvu d’une latence très faible.

Si je décide de supprimer ma VM, je perds mes données, ce qui parait logique. Maintenant, je conseillais aussi de poser des backup de ces bases sur un disque persistent.

Le second test, lui m’avait un peu déçu. OK, j’ai réalisé ce second test sur une VM de taille inférieure, donc de performance moindre.

Le disque temporaire n’a pas les mêmes performances même si elles restent plus qu’acceptables.

image

Par contre, le disque persistent voit les IOPS fondre comme neige au soleil:

image

On pouvait conclure de ces test que les disques temporaires étaient nettement plus performant que les disques persistants.

Alors, utiliser ces disques pour une base de données. Oui pourquoi pas. Mais il faut alors mettre en place sa propre méthode de HA/DR. Car en cas de bascule de la VM sur un autre host (n’oublions pas la notion de fault domain), la VM perd le disque temporaire.

Il n’est pas inconcevable de mettre en place un groupe de disponibilité dont les bases seraient supportées par le stockage temporaire associé à la VM. Il s’agirait d’une solution performante, répondant au besoins du plus grand nombre d’entre nous, à prix plus qu’abordable. Seuil écueil :  devoir reconfigurer le groupe de disponibilité suite au basculement de la VM sur un autre domaine.

Pour d’autres, la seule solution acceptable est dont l’utilisation de disques permanents. Poussons donc au maximum le curseur des performances : une VM XL, 16 volumes de 1TB stripés dans Windows…

J’ai donc ajouté 16 disques de 1TB

imageimage

J’ai ensuite stripé ces disques afin d’obtenir les meilleures performances, mais attention, pas de tolérance de pannes (un RAID 0 …).

imageimageimageimageimageimageimageimageimageimage

Il parait aussi que Azure s’adapte à notre comportement. Plus je demande à mes disques (en terme de performances) plus ils seront performants (en tout cas, c’est le message marketing). J’ai donc joué 2 scénarii SQLIO. un premier avec une durée totale de 45 minutes et un second de près de 2 heures. On verra s’il existe une différence de performances. Dans tous les cas, le fichier de test pèse 50GB.

Et bien ….. grosse déception. Pour rappel, un seul volume sur une VM small me permettait de tirer 1063 IOPS avec une latence de 14ms et un débit de 66 MB/s.

Le volume de 16TB ne fait guerre mieux lors du premier jeu de test :

image

Pour des blocks de 64KB, on reste scotché à 1283 IOPS et surtout une latence moyenne de 49 ms.  A peine 200 IOPS de différence par rapport à un seul disque de petite taille dans une VM small.

Les graphes issus du PAL sont tout a fait cohérents avec les données SQLIO :

LogicalDisk_Disk_Reads_sec1

Avec une latence et une file d’attente bien trop importante (pour du SQL Server):

LogicalDisk_Avg_Disk_Queue_Length1LogicalDisk_Avg_Disk_sec_Read1

Lors du second test, même si effectivement on constate un léger mieux, il n’y a pas de quoi sauter au plafond, 1723 IOPS pour un taille de 64K en read random.

image

LogicalDisk_Disk_Reads_sec1

Toujours de la file d’attente, mais par contre la latence à l’air d’être un peu moins élevée :

LogicalDisk_Avg_Disk_sec_Read1LogicalDisk_Avg_Disk_Queue_Length1

Compte tenu des performances plutôt moyennes (c’est du politiquement correct Sourire), j’ai rejoué encore une fois le test en formatant le disque avec des cluster de 4K.

image

Plus d’IOPS en écriture, moins en lecture … résultat mitigé. Et toujours 36ms de latence pour du read random 64K.

Que conclure ?!?

Pas spécialement performants, beaucoup de latence … Les disques persistants ne me paraissent pas suffisamment performants pour aborder sereinement un projet de virtualisation dans Windows Azure d’une instance SQL Server supportant une grosse charge et des IOPS élevés .

Mais restons lucides, je recherchais la performance maximale. Bien des configurations se satisfont de telles performances. Un VM de taille large devrait être suffisante dans bien des cas.

Certes, le cache en lecture et en écriture est désactivé par défaut sur ces disques. On pourrait envisager de l’activer, mais Microsoft recommande ce paramétrage pour un applicatif tel que SQL Server. Compréhensible.

Vu qu’il est difficile de supporter une grosse charge disque, j’aurais aimé un template de VM doté de 4 cœurs seulement mais disposant de 32GB de RAM. Ou bien 8 cœurs et 64GB de RAM. D’ailleurs, existe t’il un hébergeur capable de fournir des performances élevées en IaaS ? En tous cas, je mesure la complexité de fournir un tel service, à cout raisonnable, sur du matériel mutualisé. 

Après ce dernier tests, malgré le risque que cela représente et les contre-indications justifiées à poser les fichiers de BD sur le disque temporaire des VM, se passer de disques performants est un peu dommage. Posez y au moins la TempDB, ce sera autant de gagné pour vos IOPS sur les disques persistants.

Mais je ne laisse pas de côté l’idée de mettre en place un groupe de disponibilité sur plusieurs serveurs dont les données seraient stockées sur un disque temporaire performant.

Un AAG de 4 nœuds avec 3 nœuds synchrones (dont 2 en failover automatique) avec les données sur le disque temporaire et le dernier nœud, asynchrone, avec les données sur les disques persistants. Une dose de scripts pour remettre en place la synchronisation en cas de perte d’un des nœuds “performants”. Voilà une configuration intéressante, qu’il est aisé de transposer en 3 nœuds synchrones On-Premise (2 en failover automatique sur un premier datacenter et le troisième dans un second datacenter) et le dernier nœud, asynchrone dans le cloud pour la partie DR…

En tous cas, il parait plus que probable que l’avenir des bases de données passera par la virtualisation (pour de multiples raisons), et pour ma part, je regarde de très très près le private cloud (n’hésitez pas à me contacter ….) et quelques appliances qui permettent d’obtenir de très très bonnes performances et de retrouver la souplesse du cloud.

Le métier de DBA (et/ou architecte de données) est en plein mutation, comme une bonne partie des métiers de l’IT. Ne restez pas ancré sur votre savoir faire actuel, vos acquis, prenez le train en marche. Vous verrez, l’avenir, certes différent, promet d’être passionnant.

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.

2 commentaires pour 16 volumes Windows Azure : le test SQLIO

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

  2. Ping : Volumes EBS Amazon : 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