SQL Server en IAAS sur Azure – La configuration « Full Azure »

Cet article fait partie de la série SQL Server en IAAS sur Azure, vous pouvez retrouver tous les articles => ici <=

Nous avons testé précédemment une architecture à base d’un fichier par disque, puis d’un fichier par pool de disques or les deux solutions ont eu des performances mitigées et des limitations en nombre de disques dont nous aurions aimé nous affranchir. Je vous propose donc mon approche préférée, à savoir le stockage direct de nos fichiers de données et transactions sur un container Azure.

3 – La configuration « Full Azure »

Nous allons donc créer nos fichiers de données et de transaction directement sur un container Azure, malheureusement cela n’est pas si simple et passe par un certain nombre d’étapes que je détaille dans l’article suivant => Sql Server en IAAS avec Fichiers dans Azure Storage.

Étape 1 : Bench I/O

Difficilement applicable dans la mesure où nous n’avons pas directement accès en mode fichier au container Azure.

Étape 2 : La restauration de backup

Contoso, un backup compressé de 645 Mo que l’on va restaurer depuis le disque temporaire vers notre espace de stockage portalvhdssx2lqsybzfcm1 dans notre container bdd.

USE [master]
RESTORE DATABASE [Contoso] FROM  DISK = N'D:\ContosoRetailDW.bak' WITH  FILE = 1
,  MOVE N'ContosoRetailDW2.0' TO N'https://portalvhdssx2lqsybzfcm1.blob.core.windows.net/bdd/Contoso.mdf'
,  MOVE N'ContosoRetailDW2.0_log' TO N'https://portalvhdssx2lqsybzfcm1.blob.core.windows.net/bdd/Contoso.ldf',  NOUNLOAD,  REPLACE,  STATS = 5

Il aura fallu dans cette configuration 43 secondes pour restaurer le backup soit une moyenne de 15 mo/s.

Étape 3 : Charge OLTP avec HammerDB

Vuser 1:Timing test period of 5 in minutes
Vuser 1:1 ...,
Vuser 1:2 ...,
Vuser 1:3 ...,
Vuser 1:4 ...,
Vuser 1:5 ...,
Vuser 1:Test complete, Taking end Transaction Count.
Vuser 1:11 Virtual Users configured
Vuser 1:TEST RESULT : System achieved 9014 SQL Server TPM at 1988 NOPM

Les résultats sont là 14% plus performants que notre configuration par pool en nombre de transactions par minute.

Étape 4 : Test OLAP

Toujours à l’aide de la requête :

SELECT DC.ChannelName
      ,DP.ProductName
      ,DPSC.ProductSubcategoryName
      ,DPC.ProductCategoryName
      ,DS.StoreName
      ,SUM([SalesQuantity]) AS [SalesQuantity]
      ,SUM([ReturnQuantity]) AS [ReturnQuantity]
      ,SUM([ReturnAmount]) AS [ReturnAmount]
      ,SUM([DiscountQuantity]) AS [DiscountQuantity]
      ,SUM([DiscountAmount]) AS [DiscountAmount]
      ,SUM([TotalCost]) AS [TotalCost]
      ,SUM([SalesAmount]) AS [SalesAmount]
  FROM [Contoso].[dbo].[FactSales] F
  INNER JOIN [Contoso].dbo.DimChannel DC
    ON F.channelKey = DC.ChannelKey
  INNER JOIN [Contoso].[dbo].[DimProduct] DP
    ON F.ProductKey = DP.ProductKey
  INNER JOIN [Contoso].[dbo].[DimProductSubcategory] DPSC
    ON DP.ProductSubcategoryKey = DPSC.ProductSubcategoryKey
  INNER JOIN [Contoso].[dbo].[DimProductCategory] DPC
    ON DPC.ProductCategoryKey = DPSC.ProductCategoryKey
  INNER JOIN [Contoso].[dbo].[DimStore] DS
    ON F.StoreKey = DS.StoreKey
GROUP BY DC.ChannelName
      ,DP.ProductName
      ,DPSC.ProductSubcategoryName
      ,DPC.ProductCategoryName
      ,DS.StoreName

Verdict 1 minute 20 s sur cache froid.

Considérations sur cette configuration :

• Les performances sont les plus satisfaisantes des configurations testées jusqu’ici et cela avec un avantage certain, nous n’utilisons plus le système de disques de notre machine, ce qui nous permet d’avoir un coût uniquement en stockage sans avoir à jouer avec le nombre de CPU afin de pouvoir allouer plus de disques.
• Même si ces performances sont meilleures, cela n’est encore pas assez satisfaisant pour envisager de très fortes charges ou l’utilisation OLAP.

Cette configuration est une bonne solution afin d’obtenir un server SQL performant (cette configuration devrait d’ailleurs être votre choix par défaut) mais cela ne suffira pas pour les fortes charges, heureusement nous avons maintenant à notre disposition le Stockage Premium.