Depuis déjà longtemps, Microsoft propose que l’on stocke les données de ses instances IaaS d’Azure dans un Storage Account.

Cela veut dire qu’il n’y a plus de disque monté sur la VM qui sont accédés par l’OS, mais SQL Server qui accède en HTTPS à un Storage Account. Sur le papier, et avec quelques tests, cela fonctionne bien.

Vraiment  ? Et puis il existe plusieurs type de Storage Account : donc duquel parle-t-on ? Comment se comparent-ils en terme de performances ? Économiquement ? Fonctionnellement ?

 

Protocole de tests :

Nous allons comparer 3 modes de stockages dans une VM Azure :

1. Un disque local premium P15 de 256 Go ( 1100 IOPS / 125 Mo/s avec des bursts à 3500 IOPS et 170 Mo/s)
2. Un storage account LRS de type “standard”
3. Un storage account LRS de type “premium”

La VM utilisée de base sera une D4s_v3 (4 vCPU / 16 Go de RAM / 6400IOPS), avec comme base de données un extrait de la base StackOverflow de 50 Go. Le disque local premium est configuré pour avoir du cache en lecture seule, on ignorera le fait que le log transactionnel est sur le même volume.

Gros clustered index scan  :

En faisant une requête du type  :

 select avg(answercount) from posts 

 

Le temps d’exécution sur le Storage Account “standard” (HDD) est extrêmement performant ! On atteint des débits de 400 Mo/s. Là où c’est plus surprenant, c’est que le storage équivalent mais en Premium (SSD) n’offre pas du tout les mêmes performances ! On voit des intermittences de débits réseaux :

 

 

On voit également que les débits sont tellements élevés dans le cas d’un stockage “standard”, que le CPU est saturé ! Cela pourrait aller encore plus vite, si la VM dispose d’assez de puissance CPU.

Indexation :

On peut ensuite tenter une indexation voir comment se comporte ces stockages :

create index Posts_LEDN ON POSTS(LastEditorDisplayName)

 

 

Ici également, on voit que le stockage le plus performant est le Storage Account “Standard”. Les débits disques sont supérieurs et battent le Premium qu’il soit distant ou local.

Clustered Index Seek :

Le Storage Account Premium est vendu autours de l’argument des temps d’accès. On peut vérifier cela en effectuant des seeks avec un buffer vide :

 DBCC DROPCLEANBUFFERS ;

select * from Posts
where LastEditorUserId = 12345 

 

 

 

 

 

Ici les chiffres sont plus conformes à ce que l’on pouvait s’attendre. Le stockage Premium (local ou distant) offre des temps de réponse inférieur au stockage “Standard”.

Interprétations et conclusions :

Les résultats n’étaient pas ceux auxquels je m’attendais lors de ce benchmarks, pour être honnête. J’avais réalisé des tests il y a quelques années avec du stockage standard pour réaliser des backups snapshots, et j’avais été très satisfait du niveau de performance. On pourrait donc s’attendre à ce que les performances soient meilleures en SSD ? Mais il n’en est rien, curieusement. Microsoft, dans sa documentation recommande l’usage de disque locaux Premium : pour les data, avec le cache en read-only, pour la tempdb sur le volume temporaire D: (si la machine en possède un), et le log transactionnel sur un volume séparé, sans cache.

Mais ça ne veut pas dire qu’il faut balayer d’un revers de main le stockage distant dans Azure :

• Les performances en lecture séquentielles sont vraiment élevées : un système décisionnel brassant de vaste quantité de données peut y trouver son compte à bas coût.
• Les backup snapshot pour les très grosses bases de données ont clairement un intérêt
• La capacité à avoir le stockage indépendant d’un côté, et la puissance de calcul dans la VM permet de faire des scénarios de PCA/PRA intéressant à faible coût
• Le fait que la latence soit élevé peut ne pas être un si gros problème du moment que la RAM est correctement dimensionnée, faisant tombé toute requête dans le buffer pool

Le stockage Ultra SSD commence à arriver progressivement dans différentes zones Azure, je completerais ces chiffres à l’occasion quand cela arrivera en zone “France Central”

 

 

Continuez votre lecture sur le blog :

• Sauvegardes SQL Server dans un Azure Blob Storage (Vincent Delabre) [AzureSQL Server]
• PaaS PostgreSQL AWS vs Azure (Capdata team) [AWSAzureNon classéPostgreSQL]
• Redémarrage des serveurs par l’hyperviseur : ça fait mal ? (Vincent Delabre) [SQL Server]
• Azure et PostgreSQL en PaaS (Capdata team) [AzurePostgreSQL]
• SQL Server et accéder à des données tierces : Linked Servers vs. Polybase (Vincent Delabre) [SQL Server]