Nous avons des groupes de disponibilité de base (BAG) SQL Server configurés pour exécuter une base de données SQL sur un disque SSD Intel local. On m'a demandé de déplacer une base de données vers SQL Server Failover Cluster Instance (FCI) pour augmenter les performances de SQL Server : exécuter la base de données sur un disque virtuel HA alimenté par un stockage défini par logiciel. D'après mon expérience, le système VSAN hyperconvergé devrait doubler les opérations de lecture et, par conséquent, la latence des entrées-sorties SQL (pour les lectures de la base de données) devrait diminuer deux fois.
Deux scénarios ont donc été évalués : SQL BAG et SQL FCI. Pour ces deux cas, la mémoire maximale du serveur de 512 Go de RAM a été définie pour SQL Server afin d'exclure la mise en cache et d'effectuer des opérations de lecture équitables à partir de la table de la base de données.
Management Studio SQL et SQLQueryStress ont été utilisés à des fins de test. L'instruction SQL est SELECT TOP (500000) ... FROM [SQL].[dbo].[table] pour lire les 500K premières lignes.
Les résultats de la requête SQL BAG sont les suivants :
Management Studio SQL : Temps de requête = 15sec
SQLQueryStress :
Nombre de threads = 1 : Temps de requête = 2sec
Nombre de threads = 2 : Temps de requête = 2sec
Nombre de threads = 4 : Temps de requête = 2sec
Nombre de threads = 8 : Temps de requête = 2sec
Nombre de threads = 10 : Temps de requête = 3sec
Nombre de threads = 12 : Temps de requête = 4sec
Le scénario SQL FCI a été construit sur un cluster Windows Failover composé de deux nœuds matériels identiques exécutant Windows Server 2016. Le stockage a été configuré à l'aide d'un stockage défini par logiciel (hyperconvergé VSAN) sur des disques SSD Intel. Ainsi, un disque virtuel a été présenté à Failover Cluster en tant que disque de cluster. Pour tester le disque de cluster, j'ai utilisé diskspd.
Les résultats de diskspd sont les suivants :
4k lecture aléatoire - 76K IOPS (SSD), 153K IOPS (hyperconvergé VSAN - Cluster Disk)
8k lecture aléatoire - 45K IOPS (SSD), 89K IOPS (hyperconvergé VSAN - Cluster Disk)
Comme je m'y attendais, VSAN hyperconvergé a doublé les performances de stockage. Pour la suite, SQL FCI a été configuré pour stocker les fichiers de la base de données sur ce disque de cluster. Une autre copie de la base de données a été téléchargée sur le serveur et les mêmes tests ont été effectués.
Les résultats de la requête SQL FCI sont les suivants :
Management Studio SQL : Temps de requête = 15sec
SQLQueryStress :
Nombre de threads = 1 : Temps de requête = 9sec
Nombre de threads = 2 : Temps de requête = 8sec
Nombre de threads = 4 : Temps de requête = 9sec
Nombre de threads = 8 : Temps de requête = 8sec
Nombre de threads = 10 : Temps de requête = 10sec
Nombre de threads = 12 : Temps de requête = 12sec
Les questions sont les suivantes :
-
Pourquoi la latence est la même pour SQL BAG et SQL FCI, tous deux benchmarkés via Management Studio ?
-
Qu'est-ce qui peut augmenter la latence de 3-4 fois pour SQL FCI la base de données ?
