L'année dernière, nous avons examiné la série QSAN XCubeSAN XS1200 qui, selon nous, offrait de bonnes performances, de bonnes capacités et un bon prix pour les marchés SMB et ROBO qui étaient sa cible. Pour cet examen, nous examinerons le même appareil avec le contrôleur XS5226 haut de gamme. Comme la conception, la construction et la gestion sont identiques (nous utilisons le même châssis), les lecteurs peuvent se référer au commentaire précédent.
L'année dernière, nous avons examiné la série QSAN XCubeSAN XS1200 qui, selon nous, offrait de bonnes performances, de bonnes capacités et un bon prix pour les marchés SMB et ROBO qui étaient sa cible. Pour cet examen, nous examinerons le même appareil avec le contrôleur XS5226 haut de gamme. Comme la conception, la construction et la gestion sont identiques (nous utilisons le même châssis), les lecteurs peuvent se référer au commentaire précédent.
Au sein de la famille XS5200 (un peu comme la famille XS1200), QSAN propose plusieurs facteurs de forme et un contrôleur simple ou double, encore une fois avec un S pour simple ou D pour double. Le XS5226D est un double contrôleur actif-actif et axé sur des performances supérieures pour les environnements critiques, les cas d'utilisation idéaux étant le HPC, l'intégration de la virtualisation et le M&E. La société revendique des performances aussi élevées que 12 Go/s en lecture séquentielle et 8 Go/s en écriture séquentielle avec plus de 1.5 million d'IOPS.
Comme indiqué, nous utilisons le même châssis, ce qui signifie qu'il existe plusieurs zones de chevauchement entre les deux revues et que nous les passerons donc ici. Cependant, nous examinerons les principales différences de spécifications car elles ont un impact direct sur les performances.
Spécifications du QSAN XCubeSAN XS5226D
| Raid contrôleur | Double actif |
| Processeur | Intel Xeon D-1500 quadricœur |
| Mémoire | jusqu'à 128 Go de DDR4 ECC |
| Type d'entraînement | |
| 2.5″ SAS, NL-SAS, disque dur SED | |
| SAS 2.5 pouces, SSD SATA (carte MUX 6 Go nécessaire pour les disques SATA 2.5 pouces dans un système à deux contrôleurs) | |
| Capacités d'extension | 2U 26 baies, petit format |
| Nombre maximum de lecteurs pris en charge | 286 |
Performance
Analyse de la charge de travail des applications
Les benchmarks de charge de travail d'application pour le QSAN XCubeSAN XS5226D comprennent les performances OLTP de MySQL via SysBench et les performances OLTP de Microsoft SQL Server avec une charge de travail TPC-C simulée. Dans chaque scénario, la baie était configurée avec 26 SSD Toshiba PX04SV SAS 3.0, configurés en deux groupes de disques RAID12 à 10 disques, un épinglé à chaque contrôleur. Cela a laissé 2 SSD en réserve. Deux volumes de 5 To ont ensuite été créés, un par groupe de disques. Dans notre environnement de test, cela a créé une charge équilibrée pour nos charges de travail SQL et Sysbench.
Performances du serveur SQL
Chaque machine virtuelle SQL Server est configurée avec deux vDisks : un volume de 100 Go pour le démarrage et un volume de 500 Go pour la base de données et les fichiers journaux. Du point de vue des ressources système, nous avons configuré chaque machine virtuelle avec 16 vCPU, 64 Go de DRAM et exploité le contrôleur LSI Logic SAS SCSI. Alors que nos charges de travail Sysbench testées saturaient la plate-forme à la fois en termes d'E/S de stockage et de capacité, le test SQL recherche les performances de latence.
Ce test utilise SQL Server 2014 s'exécutant sur des machines virtuelles invitées Windows Server 2012 R2 et est souligné par Benchmark Factory for Databases de Quest. Alors que notre utilisation traditionnelle de cette référence a été de tester de grandes bases de données à l'échelle 3,000 1,500 sur un stockage local ou partagé, dans cette itération, nous nous concentrons sur la répartition uniforme de quatre bases de données à l'échelle 5200 XNUMX sur le QSAN XSXNUMX (deux machines virtuelles par contrôleur).
Configuration des tests SQL Server (par machine virtuelle)
- Windows Server 2012 R2
- Empreinte de stockage : 600 Go alloués, 500 Go utilisés
- SQL Server 2014
- Taille de la base de données : échelle 1,500 XNUMX
- Charge de client virtuel : 15,000 XNUMX
- Mémoire tampon : 48 Go
- Durée du test : 3 heures
- 2.5 heures de préconditionnement
- Période d'échantillonnage de 30 minutes
SQL Server OLTP Benchmark Usine Équipement LoadGen
- Dell EMC PowerEdge R740xd Cluster virtualisé SQL à 4 nœuds
- 8 processeurs Intel Xeon Gold 6130 pour 269 GHz en cluster (deux par nœud, 2.1 GHz, 16 cœurs, 22 Mo de cache)
- 1 To de RAM (256 Go par nœud, 16 Go x 16 DDR4, 128 Go par processeur)
- 4 HBA FC double port Emulex 16 Go
- 4 x Mellanox ConnectX-4 rNDC 25GbE double port NIC
- VMware ESXi vSphere 6.5/Enterprise Plus 8-CPU
Pour nos tests, nous comparerons le nouveau contrôleur au précédent testé. Il s'agit moins d'un "quel est le meilleur" que d'un "regard sur les performances que l'on obtient en fonction de ses besoins".
Avec SQL Server, la différence de contrôleurs n'a pas vraiment eu d'incidence sur les performances globales. Le XS1226 avec 4 VM a atteint 12,634.3 5226 TPS et le XS4 avec 12,634.7 VM a atteint XNUMX XNUMX TPS.
Avec la latence moyenne SQL, nous avons vu la même chose. Le XS1226 avait une latence de 5.8 ms et le XS5226 avait une latence de 5.0 ms.
Performances de Sybench
Chaque Banc Sys La machine virtuelle est configurée avec trois vDisks, un pour le démarrage (~ 92 Go), un avec la base de données pré-construite (~ 447 Go) et le troisième pour la base de données testée (270 Go). Du point de vue des ressources système, nous avons configuré chaque machine virtuelle avec 16 vCPU, 60 Go de DRAM et exploité le contrôleur LSI Logic SAS SCSI. Les systèmes de génération de charge sont des serveurs Dell R740xd.
Cluster à 740 nœuds MySQL virtualisé Dell PowerEdge R4xd
- 8 processeurs Intel Xeon Gold 6130 pour 269 GHz en cluster (deux par nœud, 2.1 GHz, 16 cœurs, 22 Mo de cache)
- 1 To de RAM (256 Go par nœud, 16 Go x 16 DDR4, 128 Go par processeur)
- 4 HBA FC double port Emulex 16 Go
- 4 x Mellanox ConnectX-4 rNDC 25GbE double port NIC
- VMware ESXi vSphere 6.5/Enterprise Plus 8-CPU
Configuration des tests Sysbench (par machine virtuelle)
- CentOS 6.3 64 bits
- Empreinte de stockage : 1 To, 800 Go utilisés
- Percona XtraDB 5.5.30-rel30.1
- Tableaux de base de données : 100
- Taille de la base de données : 10,000,000 XNUMX XNUMX
- Threads de base de données : 32
- Mémoire tampon : 24 Go
- Durée du test : 3 heures
- 2 heures de préconditionnement 32 fils
- 1 heure 32 fils
Dans notre benchmark Sysbench, nous avons testé plusieurs ensembles de 4VM, 8VM, 16VM et 32VM. En termes de performances transactionnelles, le XS5226D a affiché de solides performances avec 6,889 4 TPS pour 13,023 VM, 8 21,645 TPS sur 16 VM, 26,810 32 TPS sur XNUMX VM et XNUMX XNUMX TPS sur XNUMX VM.
Avec une latence moyenne, le 4VM XS1226 a légèrement mieux fonctionné que le XS5226D, de 18.1 ms à 18.6 ms, mais le XS5226D a devancé le contrôleur précédent dans les autres configurations de VM avec 19.7 ms pour 8 VM, 23.9 ms pour 16 VM et 41 ms pour 32 VM.
Dans notre benchmark de latence dans le pire des cas, nous constatons la même chose qu'avec la latence moyenne : mieux en 4VM pour la série XS1200 et mieux dans le reste avec la série XS5200. Pour le XS5226D, nous avons constaté une latence de 32.7 ms pour 4 VM, 34.8 ms pour 8 VM, 47 ms pour 16 VM et 76.9 ms pour 32 VM.
Analyse de la charge de travail VDBench
Lorsqu'il s'agit de comparer les baies de stockage, les tests d'application sont les meilleurs et les tests synthétiques viennent en deuxième position. Bien qu'ils ne soient pas une représentation parfaite des charges de travail réelles, les tests synthétiques aident à référencer les périphériques de stockage avec un facteur de répétabilité qui facilite la comparaison de pommes à pommes entre des solutions concurrentes. Ces charges de travail offrent une gamme de profils de test différents allant des tests « aux quatre coins », des tests de taille de transfert de base de données communs, ainsi que des captures de traces à partir de différents environnements VDI. Tous ces tests exploitent le générateur de charge de travail vdBench commun, avec un moteur de script pour automatiser et capturer les résultats sur un grand cluster de test de calcul. Cela nous permet de répéter les mêmes charges de travail sur une large gamme de périphériques de stockage, y compris les baies flash et les périphériques de stockage individuels. Côté baie, nous utilisons notre cluster de serveurs Dell PowerEdge R740xd :
Profils:
- Lecture aléatoire 4K : 100 % de lecture, 128 threads, 0-120 % d'iorate
- Écriture aléatoire 4K : 100 % d'écriture, 64 threads, 0-120 % de vitesse
- Lecture séquentielle 64K : 100 % de lecture, 16 threads, 0-120 % d'iorate
- Écriture séquentielle 64K : 100 % d'écriture, 8 threads, 0-120 % d'iorate
- Base de données synthétique : SQL et Oracle
- Traces de clone complet et de clone lié VDI
Dans les performances de lecture maximales 4K, le XS5226D avait des performances de latence inférieures à la milliseconde jusqu'à un peu moins de 400K IOPS, avec une performance maximale de 442,075 8.03 IOPS avec une latence de 1200 ms. Cela a dépassé le XS284 qui a culminé à 13.82 XNUMX IOPS et une latence de XNUMX ms.
Avec des performances d'écriture maximales de 4K, le nouveau contrôleur avait des performances de latence inférieures à la milliseconde jusqu'à environ 270K IOPS avec un pic de 294,255 6.27 IOPS avec une latence de 246 ms. À titre de comparaison, l'ancien contrôleur avait des performances de pointe d'environ 7.9K avec une latence de XNUMX ms.
En passant aux performances séquentielles, dans la lecture 64K, le XS5226D a roulé juste en dessous de 1 ms jusqu'à environ 38K IOPS ou 2.3 Go/s et a culminé à 95,762 5.99 IOPS ou 5.34 Go/s avec une latence de 1200 ms. Le XSXNUMX n'avait même pas de performances inférieures à la milliseconde.
Pour une écriture de pointe séquentielle de 64K, le XS5226D avait des performances inférieures à 1 ms jusqu'à environ 63K IOPS ou 3.9 Go/s. Il a culminé à environ 80 4.95 IOPS ou 2.68 Go/s avec une latence de XNUMX ms.
Dans notre charge de travail SQL, le nouveau contrôleur surpasse facilement son homologue. Le XS5226D avait des performances de latence inférieures à la milliseconde jusqu'à environ 380 425,327 IOPS et culminait à 2.27 5226 IOPS avec une latence de 200 ms. Ainsi, le contrôleur XS1D avait environ XNUMX XNUMX IOPS supplémentaires avec une latence inférieure de XNUMX ms.
Dans le SQL 90-10, le XS5226D est resté sous 1 ms jusqu'à environ 350 407,661 IOPS et a culminé à 2.36 1 IOPS avec une latence de XNUMX ms. Encore une fois, il a surpassé l'autre contrôleur qui avait toutes ses performances sur XNUMX ms.
Le SQL 80-20 a montré le XS5226D avec des performances de latence inférieures à la milliseconde jusqu'à environ 340 387,085 IOPS et une performance maximale de 2.4 1200 IOPS avec une latence de 247 ms. Encore une fois, c'était tout un saut de performance sur le XS3.26 qui avait une performance maximale d'environ XNUMXK IOPS à une latence de XNUMX ms.
Avec Oracle Workload, le XS5226D a atteint près de 310 1 IOPS avant de casser 381,444 ms et de culminer à 3.1 1200 IOPS avec 246,186 ms. Le XS4.2 a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.
Avec l'Oracle 90-10, le XS5226D est resté en dessous de 1 ms jusqu'à environ 360 407,763 IOPS et a culminé à 1.56 1200 IOPS avec une latence de 248,759 ms. À titre de comparaison, le XS2.2 a culminé à 1 XNUMX IOPS avec une latence de XNUMX ms et n'est jamais descendu en dessous de XNUMX ms tout au long de son exécution.
Pour l'exécution Oracle 80-20, le XS5226D a atteint un peu moins de 350 1 IOPS avant de casser 386,844 ms et de culminer à 1.66 1200 IOPS avec une latence de 1 ms. Le XS242,000 était au-dessus de 4.16 ms tout au long avec un pic de XNUMX XNUMX IOPS et une latence de XNUMX ms.
Ensuite, nous sommes passés à notre test de clone VDI, Full et Linked. Pour VDI Full Clone Boot, le XS5226D a chevauché la ligne de 1 ms pendant un moment avant de tomber à environ 225 367,665 IOPS et de culminer à 2.78 1200 IOPS avec une latence de 218 ms. Un bond impressionnant en termes de performances par rapport aux 4.26 XNUMX IOPS et à la latence de XNUMX ms du XSXNUMX.
Pour la connexion initiale VCI FC, le XS5226D avait des performances de latence inférieures à la milliseconde jusqu'à environ 200 260 IOPS et culminait à environ 3 1200 IOPS avec une latence de 185,787 ms. Le XS3.91 a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms dans le même test.
La connexion VDI Full Clone Monday a vu le XS5226D atteindre environ 163 1 IOPS en moins de 269,724 ms et culminer à 1.86 182,376 IOPS avec une latence de 2.55 ms. Le contrôleur précédent a pu culminer à XNUMX XNUMX IOPS avec une latence de XNUMX ms.
En passant à VDI Linked Clone, le test de démarrage a montré que le XS5226D a atteint environ 110K avec des performances de latence inférieures à la milliseconde et a culminé à 216,579 2.36 IOPS avec une latence de 1200 ms. Le XS149,488 a culminé à 3.39 XNUMX IOPS avec une latence de XNUMX ms.
La connexion initiale VDI Linked Clone a également vu le XS5226D atteindre environ 110K avec des performances de latence inférieures à la milliseconde, puis il a culminé à 182,425 1.39 IOPS avec une latence de 1200 ms. Comparez cela avec le XS147,423 qui avait une performance maximale de 1.71 XNUMX IOPS à une latence de XNUMX ms.
Enfin, le VDI Linked Clone Monday Login a permis au XS5226D d'atteindre à nouveau environ 110K avec des performances de latence inférieures à la milliseconde, puis il a culminé à environ 220K IOPS avec une latence de 2.3 ms. Le XS1200 a culminé à 148,738 3.2 IOPS avec une latence de XNUMX ms.
Conclusion
Le QSAN XCubeSAN XS5226D est un SAN double actif-actif qui promet plus de performances que le XS1226D qui était destiné aux PME. Pour cet examen, nous avons utilisé le même châssis avec un contrôleur mis à niveau. Cela étant dit, la conception, la construction et la gestion étaient les mêmes et peuvent être trouvées dans notre avis original. Le XS5226D est destiné à des charges de travail plus critiques et cible des cas d'utilisation plus en amont que le XS1226D, tels que le HPC, le M&E et la virtualisation. L'utilisation du même châssis signifie que tous les avantages de la connectivité et de la haute disponibilité sont les mêmes.
En ce qui concerne les performances, dans notre analyse de la charge de travail des applications, la différence de contrôleurs ne s'est pas vraiment traduite par une grande différence de performances pour nos benchmarks SQL Server, bien que dans d'autres domaines, nous ayons constaté des gains massifs. Le TPS pour le XS1226 était de 12,634.3 5226 et pour le XS0.4, le score n'était que de 12,634.7 TPS supérieur à 5.8 5.0. Nous avons vu une action similaire avec une latence moyenne avec le plus petit contrôleur atteignant 1226 ms et le plus grand atteignant 4 ms. Avec Sysbench, nous avons vu de bien meilleures performances du XS5226 dans les configurations 32VM, mais le XS26,810.4 avait de meilleures performances avec plus de VM avec des performances 41VM de 76.9 XNUMX TPS, une latence moyenne de XNUMX ms et un scénario du pire des cas de XNUMX ms.
Avec nos charges de travail VDBench, il y avait une énorme différence dans presque tous nos tests, le XS5226D offrant clairement beaucoup plus de performances. Dans notre 4K, nous avons vu les contrôleurs XS5226D atteindre des scores supérieurs à 442K IOPS en lecture et 294K IOPS en écriture avec une latence aussi faible que 8.03 ms et 6.27 ms respectivement. Les performances de 64K ont montré que le contrôleur atteignait près de 6 Go/s en lecture et près de 5 Go/s en écriture. Avec notre charge de travail SQL, le contrôleur avait des performances de pointe supérieures à 425 407 IOPS, 90 10 IOPS pour 387-80 et 20 381 IOPS pour 407-90. La charge de travail Oracle a également montré de très bons chiffres avec des performances de pointe supérieures à 10 386 IOPS, 80 20 IOPS pour 1.56-3.1 et 5226 367 IOPS pour 216-260 avec des latences comprises entre 182 ms et 5226 ms. Pour notre clone complet VDI et notre clone lié, nous avons examiné le démarrage, la connexion initiale et la connexion du lundi. Pour les performances de démarrage, le XS269D a atteint plus de 220 XNUMX IOPS en FC et plus de XNUMX XNUMX IOPS en LC. La connexion initiale a montré environ XNUMX XNUMX IOPS de performances maximales FC et plus de XNUMX XNUMX IOPS pour LC. Et Monday Login avait le contrôleur XSXNUMXD avec plus de XNUMXK IOPS FC et XNUMXK IOPS LC.
Dans l'ensemble, le XS5200 s'est plutôt bien comporté, tirant pleinement parti des SSD Toshiba PX04 SAS3 que nous avons installés. Les performances au total sont très impressionnantes, car 6 Go/s en lecture et 5 Go/s en écriture (64K séquentiel) sur un SAN SMB sont très bons. Bien sûr, il y a un peu de compromis ; l'ensemble de fonctionnalités, l'interface et les intégrations logicielles avec des packages populaires tels que VMware laissent un peu à désirer alors que vous regardez plus haut de gamme les besoins de l'entreprise. Quoi qu'il en soit, le XS5200 offre un fantastique profil performance/coût qui fera le travail parfaitement pour une grande partie du public cible.
En résumé
Le QSAN XCubeSAN avec le contrôleur XS5226D apporte des performances bien supérieures aux charges de travail nécessaires, toujours avec un prix relativement bon.
Inscrivez-vous à la newsletter StorageReview
