Volumes EBS Amazon : performance disque avec SQLIO

Après avoir testé les performances des disques éphémères des VM Amazon EC2 je me devais de poursuivre l’étude en m’attaquant aux volumes EBS.

Amazon Elastic Block Store (EBS)

Amazon Elastic Block Store (Amazon EBS) fournit des volumes de stockage en mode bloc à utiliser avec les instances Amazon EC2. Les volumes Amazon EBS sont liés au réseau et persistent indépendamment de la durée de vie d’une instance. Amazon EBS fournit des volumes de stockage hautement disponibles et fiables, qui peuvent être annexés à une instance Amazon EC2 en cours d’exécution et exposés sous forme de périphérique au sein de l’instance. Amazon EBS convient, en particulier, pour les applications qui nécessitent une base de données, un système de fichiers ou un accès à un stockage brut en mode bloc.

Contrairement aux disques temporaires, ceux ci résistent à une changement d’hôte de la part de la VM. Il serait donc tout a fait judicieux de déposer nos fichiers de bases de données sur ces disques. Cependant, comme je l’avais constaté avec les VM Windows Azure et les disques permanents, il ne faut pas s’attendre à avoir le même niveau de performance.

J’ai choisi d’effectuer ces test sur une M2.4XL (8 vCores et 65 GB de RAM).

image

Contrairement à l’instance HI1, il n’y a pas de disque local attaché, mis a part le disque système.

On va donc créer un premier volume EBS et l’attacher à la VM (attention à bien choisir le même emplacement que votre VM sinon il ne sera pas possible d’attacher le volume):

imageimageimageimageimageimage

Amazon affiche 1000 IOPS pour une taille de cluster de 16K. J’ai décidé de m’aligner sur ces 16K. Notez aussi que j’ai volontairement décoché la case de formatage rapide afin d’initialiser tous blocs et ainsi obtenir les meilleures perfs possible (recommandation Amazon).

image

Lors du formatage, on n’atteint est plus proche des 750IOPS que des 1000 annoncés. Mais je ne suis pas sur que cela soit très représentatif.image

Pendant la phase de création du fichier de test SQLIO (20 GB), on plafonne a 41 MB/s.image

SQLIO confirme que l’on est bien à 1000 IOPS pour des IOs <= 16K.

image

Pas spécialement de surprise donc sur la partie IOs. Par contre, quelle latence! On serait On-Premise, j’aurais simplement cela d’inacceptable. 240ms en Read Random 64. Et plus de 120ms pour l’écriture de blocks de 8K ! Autrement dit, ne cherchez pas la performance pour un OLTP. Vos transactions seront lentes. Pour de l’OLTP, on tolère généralement une latence de 5ms pour un disque ne disposant pas de cache (1ms si un cache est présent). Au delà de 20ms on est pas du tout performant. Nous sommes plus de 4 ou 5 fois au delà de ce que l’on tolèrerait On-Premise.

Une VM Azure avec un disque blob offraient une latence entre 50 et 60ms. Pas terrible, mais 2 fois mieux tout de même.

Mais voilà, nous sommes dans le Cloud, ce qui offre une certaine flexibilité et une certaine sécurité. Mais quel dommage d’avoir une si grande latence. Bien des applicatifs vont s’en ressentir.

Nous allons vérifier a présent que le stripping de disques (RAID 0, pas de parité => performance mais pas de sécurité) nous permet de gagner en performance…

J’ajoute 4 disques de 100GB provisionnés à 1000 IOPS. Je créé ensuite le stripping disque et je reformate avec une taille de cluster à 16K (pas de formatage rapide). Pensez à changer le nom de votre volume (les noms autorisés vont de xvdf à xvdp), sinon l’attachement provoquera une erreur (mais rien de bien grave).

imageimageimageimageimageimage

Le formatage prends un certain temps …

image

Trèèèèèès longtemps (plus ou moins 3 heures !!!). Les disques seront chauds, pas besoin de rodage (Ramp Up) avant de commencer.

image

Les valeurs obtenues proches de 5000 IOPS (5*1000 : trop fort en math) laissent entrevoir une augmentation linéaire des performance en ajoutant des volumes EBS. Cette solution a l’air de fonctionner dans la limite de la bande passante maximale (10 LUN devraient théoriquement proposer 10000 IOPS).  La limite théorique est de 1Gbit/s, notez bien le b et non B.

image

Les 120 MB obtenus sont très proche du débit maximum théorique. Donc ajouter des volumes EBS ne changerais pas grand chose. En utilisant une instance HI1 ou bien Cluster Compute, on bénéficie d’une interface réseau à 10Gb, donc plus de bande passante. Mais il faudra multiplier les volumes EBS.

La “bonne nouvelle” nous vient de la latence qui est de 25ms pour des blocks de 8K et de 80ms pour des blocks de 64K. C’est pas extraordinaire, mais bien mieux …

Comparaison avec le stockage Windows Azure.

Pour une VM disposant d’un seul volume, on peut considérer que Microsoft en propose légèrement plus (j’avais 1000 IOPS pour une taille de cluster de 64K alors qu’Amazon propose cette valeur pour des IOs <= à 16KB). De même la latence d’un volume EBS semble supérieure à un volume sur Azure.

La déception face à la performance du stripping de 16 volumes dans Windows Azure fais place à une certaine “satisfaction” chez son équivalent Amazon. Sur les volumes Azure, je n’avais pas noté de gain de performance notable en faisant un RAID 0. En jouant avec les tailles de clusters sur le formatage du disque, les valeurs s’échelonnaient entre 1000 et 4000 IOPS, pour 16 volumes de 1TB chacun. Sur les volumes EBS, certes les IOs ne s’envolent pas mais la latence est contenue, du moins du même ordre que celle rencontrée sur Azure.

Au final difficile de faire un choix entre des disques éphémères performants mais qui ne sont en rien protégés contre une panne ou un déplacement de machine virtuelle et des disques annoncés comme “hautement disponible” par Amazon mais dont les performances sont bien moindres et la latence plus conséquente.

La sagesse voudrait que l’on place les données sur les volumes EBS, et si le niveau de performance ne vous satisfait pas, utilisez les disques éphémères. Il faut alors prévoir son propre système de haute disponibilité / disaster recovery. Peut être faut il “classifier” les bases avec des niveaux de disponibilité et de performance, et en fonction, répartir les fichiers sur les volumes EBS ou éphémères.

Hum , le travail d’architecture parait aussi intéressant dans le cloud que On-Premise !

Testez, faites vous votre propre opinion …

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 )

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