SQL Server en IAAS sur Azure – Config « Windows Server Storage Pools »

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, or les performances n’ont pas vraiment été à la hauteur, voyons si les Pools de disques sont une solution.

2 – La configuration « Windows Server Storage Pools »

Nous allons donc créer deux pools de disques, G: DataPools (2 disques) et LogPools (2 disques) je ne rentre pas dans le détail de la création de ceux-ci, vous trouverez une explication assez détaillée => ici <=

Étape 1 : Bench I/O

Guère mieux que notre première configuration standard sur la partie 4K, un petit mieux sur les gros fichiers.

Étape 2 : La restauration de backup

Contoso, un backup compressé de 645 Mo que l’on va restaurer depuis le disque temporaire vers nos deux disques (G: Data H: Log qui sont en fait 2X2 disques, vous vous souvenez ?)

RESTORE DATABASE [Contoso] FROM  DISK = N'D:\ContosoRetailDW.bak' WITH  FILE = 1,  MOVE N'ContosoRetailDW2.0' TO N'G:\Data\Contoso.mdf',  MOVE N'ContosoRetailDW2.0_log' TO N'H:\Log\Contoso.ldf',  NOUNLOAD,  REPLACE,  STATS = 5

Il aura fallu dans cette configuration 30 secondes pour restaurer le backup soit une moyenne de 21,5 mo/s.

Étape 3 : Charge OLTP avec HammerDB

Vuser 1:Test complete, Taking end Transaction Count.
Vuser 1:5 Virtual Users configured
Vuser 1:TEST RESULT : System achieved 7925 SQL Server TPM at 1740 NOPM

Un petit peu mieux que notre configuration par défaut.

É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 40 s sur cache froid, peu d’amélioration comparé à notre première solution.

Considérations sur cette configuration :

• Les performances sont légèrement meilleures que la configuration par défaut, et pour cela il m’a fallu sacrifier des disques. Cela aura donc un impact sur la tarification de ma machine vu que le nombre de disques est proportionnel au nombre de CPU.
• Les performances ne sont pas forcément meilleures sur les petites transactions.
• Durant les tests, les écarts entre chaque mesure peuvent être très importants, cela est certainement du à la mutualisation des ressources et à l’absence de garantie en nombre d’I/O minimum. (Nous ne sommes pas en storage premium)

Après cette approche qui n’est pas un franc succès, je vous propose dans le prochain article de nous affranchir de la limite du nombre de disques en stockant directement nos fichiers de données et transactions sur un container Azure.