Examen de VMware vSAN Western Digital Ultrastar DC SN630

Western digital a lancé l'Ultrastar DC SN630 en février de cette année, dans le cadre d'un rafraîchissement et d'un changement de marque de leur gamme Ultrastar (anciennement HGST) de disques de centre de données. Dans ce portefeuille, Western Digital propose plusieurs offres de SSD NVMe d'entreprise, le SN200 prenant le trône en tant que leader des performances et le nouveau SN630 remplace le SN620 dans l'espace NVMe à port unique, qui est une alternative de plus en plus populaire aux SSD SATA et SAS. Le SN630, qui est le cheval de bataille NVMe SSD de Western Digital, est conçu pour les charges de travail centrées sur la lecture ou les charges de travail à usage mixte à haute endurance. La construction du variateur dans les deux cas est la même, la différence fonctionnelle dans le niveau de surprovisionnement qui entre dans le variateur, qui à son tour produit la cote d'endurance souhaitée.

Western digital a lancé l'Ultrastar DC SN630 en février de cette année, dans le cadre d'un rafraîchissement et d'un changement de marque de leur gamme Ultrastar (anciennement HGST) de disques de centre de données. Dans ce portefeuille, Western Digital propose plusieurs offres de SSD NVMe d'entreprise, le SN200 prenant le trône en tant que leader des performances et le nouveau SN630 remplace le SN620 dans l'espace NVMe à port unique, qui est une alternative de plus en plus populaire aux SSD SATA et SAS. Le SN630, qui est le cheval de bataille NVMe SSD de Western Digital, est conçu pour les charges de travail centrées sur la lecture ou les charges de travail à usage mixte à haute endurance. La construction du variateur dans les deux cas est la même, la différence fonctionnelle dans le niveau de surprovisionnement qui entre dans le variateur, qui à son tour produit la cote d'endurance souhaitée.

Du point de vue de la conception SSD, l'Ultrastar SN630 utilise le contrôleur interne et la construction du micrologiciel de Western Digital et la propre NAND BiCS64 3D à 3 couches de Western Digital. Du point de vue de l'ingénierie, une solution intégrée verticalement comme celle-ci devient la norme pour les SSD d'entreprise de premier ordre. Bien qu'il soit certainement possible d'utiliser la NAND, des contrôleurs et des micrologiciels de différentes sources, nous avons tendance à voir des solutions plus performantes et plus fiables de la part de fournisseurs capables de faire tout le travail par eux-mêmes. Le lecteur lui-même utilise un facteur de forme U.7 de 2.5 mm 2 pouces et, comme les autres offres de SSD Western Digital, le SN630 offre des algorithmes propriétaires de nivellement d'usure et une protection contre les pertes de puissance.

Comme indiqué, le SN630 est disponible en SKU à usage mixte et à lecture intensive. Le premier est livré avec des capacités de 6.40 To, 3.20 To, 1.60 To et 800 Go, tandis que le second est disponible avec des capacités de 7.68 To, 3.84 To, 1.92 To et 960 Go. Tous les disques offrent Instant Secure Erase (ISE) qui utilise des clés de cryptage en arrière-plan pour gérer le redéploiement et le retrait des disques. Western Digital fournit également des téléchargements de micrologiciels sécurisés avec authentification RSA pour garantir que le SN630 exécute uniquement un micrologiciel authentique. Enfin, les disques sont couverts par une garantie limitée de 5 ans.

Dans cette revue, nous examinons les performances du SN630 dans le contexte de VMware vSAN. La configuration d'examen utilise un châssis Supermicro SuperServer BigTwin 2029BT-HNR à 4 nœuds, 24 SSD Ultrastar DC SN630 NVMe et VMware vSAN 6.7 Update 1 pour approfondir les performances du SN630 avec une perspective plus large à l'échelle du système.

Spécifications Western Digital Ultrastar DC SN630

Western Digital Ultrastar DC SN630 VMware vSAN Conception et construction

Le Western Digital Ultrastar DC SN630 est un disque NVMe de 2.5 pouces destiné au centre de données. Le disque a une capacité de 800 Go à 7.68 To. Le SN630 est recouvert de métal noir avec un autocollant sur le dessus qui contient des informations telles que le nom, la marque, la capacité, le numéro de modèle et les certifications.

L'avant du châssis Supermicro SuperServer BigTwin arbore 24 baies de lecteur NVMe 2.5″, avec 6 allouées par nœud. Chaque nœud offre son propre bouton LED de localisation ainsi qu'un bouton d'alimentation discret.

L'arrière du BigTwin montre les quatre plateaux de nœuds de calcul. Chacun est livré en standard avec un port IPMI pour la gestion hors bande, VGA, deux ports USB 3 ainsi qu'une carte réseau configurable par l'utilisateur. Avec notre configuration, nous utilisons une carte réseau à quatre ports, avec deux ports 10GBase-T ainsi que deux ports SPF28 25G. Notre configuration de test a exploité les connexions 25G pour le cluster vSAN. Tous les nœuds partagent une plate-forme d'alimentation commune à double bloc d'alimentation dans le cadre de la conception du châssis.

Western Digital Ultrastar DC SN630 VMware vSAN Examen de la configuration

Pour tester les 24 SSD SN630 dans un environnement vSAN, nous avons utilisé un système à quatre nœuds Supermicro SuperServer BigTwin 2029BT-HNR. La configuration par nœud est la suivante :

• 2 processeurs Intel Gold 6150 (2.7 GHz, 18 cœurs)
• 12 x 32 Go de RAM DDR2666 ECC à 4 XNUMX MHz
• 2 disques SSD Western Digital Ultrastar DC SN800 NVMe de 630 Go pour vSAN Cache
• 4 disques SSD Western Digital Ultrastar DC SN1.92 NVMe de 630 To pour la capacité vSAN
• 1 SSD SATA bleu Western Digital de 500 Go pour disque de démarrage
• Carte réseau Mellanox ConnectX-25 double port 4 Go
• VMwareESXi 6.7u1 (10302608)

Nous avons utilisé une version de serveur assez modeste pour nos tests VMware vSAN autour du Western Digital Ultrastar DC SN630. Les serveurs utilisaient des processeurs Intel Gold 6150 haut de gamme, avec une vitesse d'horloge de 2.7 GHz et un nombre de cœurs de 18. Par serveur, cela nous donne 97.2 GHz de puissance de calcul, ou 388.8 GHz au niveau du cluster. Nous avons également utilisé 384 Go de RAM par nœud, ce qui nous donne beaucoup de mémoire pour nos charges de travail synthétiques et applicatives.

Dans notre configuration de test, nous avons utilisé une disposition de deux groupes de disques par nœud, chacun avec un SSD SN800 NVMe de 630 Go pour le cache et deux SSD SN1.92 NVMe de 630 To pour la capacité. La capacité utilisable dépend de la façon dont les machines virtuelles sont provisionnées dans le cluster ainsi que du niveau de mise en miroir que vous utilisez. Le stockage brut mesure 27.95 To dans notre cluster, mais avec la politique de mise en miroir bidirectionnelle par défaut des machines virtuelles avec surcharge vSAN, il nous reste 13.79 To de capacité utilisable. La réduction des données, bien que cela s'étende considérablement pour certains types de charge de travail.

Alors que nos charges de travail d'application se concentreront sur les performances du cluster avec la réduction des données désactivée, nous inclurons des benchmarks synthétiques présentant les performances du cluster avec et sans la réduction des données activée. Bien que la réduction des données ait une composante de surcharge de performances qui lui est associée, elle augmentera considérablement la capacité utilisable du cluster vSAN dans certains déploiements.

Examen des performances de Western Digital Ultrastar DC SN630 VMware vSAN

Performances du serveur SQL

Le protocole de test Microsoft SQL Server OLTP de StorageReview utilise la version actuelle du Transaction Processing Performance Council's Benchmark C (TPC-C), une référence de traitement des transactions en ligne qui simule les activités trouvées dans des environnements d'application complexes. Le benchmark TPC-C est plus proche que les benchmarks de performances synthétiques pour évaluer les forces de performance et les goulots d'étranglement de l'infrastructure de stockage dans les environnements de base de données.

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 précédemment 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 Dell Benchmark Factory for Databases. 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 XNUMX XNUMX sur nos serveurs.

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

Pour notre benchmark transactionnel SQL Server, le Western Digital Ultrastar DC SN630 VMware vSAN dans le Supermicro BigTwin a pu atteindre un score global de 12,610.3 3,152.01 TPS avec des machines virtuelles individuelles allant de 3,153.2 XNUMX TPS à XNUMX XNUMX TPS.

Avec SQL Server, nous avons constaté un score global de 14.75 ms avec des machines virtuelles individuelles allant de 14 ms à 15 ms.

Performances Sysbench MySQL

Notre premier benchmark d'application de stockage local consiste en une base de données Percona MySQL OLTP mesurée via SysBench. Ce test mesure également le TPS moyen (transactions par seconde), la latence moyenne et la latence moyenne au 99e centile.

Chaque machine virtuelle Sysbench est configurée avec trois vDisks : un pour le démarrage (~92 Go), un avec la base de données prédéfinie (~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.

Configuration des tests Sysbench (par machine virtuelle)

• CentOS 6.3 64 bits
• 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

Avec l'OLTP Sysbench, nous avons testé 8VM et obtenu un score global de 11,739.7 1,326 TPS avec des machines virtuelles individuelles allant de 1,552.3 XNUMX TPS à XNUMX XNUMX TPS.

Avec la latence Sysbench, le serveur avait une moyenne de 21.86 ms.

Dans notre pire scénario (99e centile), la latence des disques Western Digital nous a donné 38.71 ms.

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.

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 tous nos tests VDBench, nous avons testé les disques Western Digital avec DR activé et désactivé. Avec une lecture 4K aléatoire, les deux configurations ont commencé en moins de 1 ms avec la version DR apparaissant et culminant à 387,937 7.5 IOPS avec une latence de 1 ms. Avec DR désactivé, les disques sont restés inférieurs à 350 ms jusqu'au nord de 442,089 4.8 IOPS et ont culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Pour 4K, écrivez à nouveau, les deux configurations ont commencé un peu moins de 1 ms. La version DR avait une latence inférieure à la milliseconde jusqu'à environ 90 182,791 IOPS et a culminé à 7.4 1 IOPS avec une latence de 110 ms. Avec DR désactivé, nous avons vu les disques rester sous 196,027 ms jusqu'à environ 7 XNUMX IOPS et culminer à XNUMX XNUMX IOPS avec une latence d'environ XNUMX ms avant d'en laisser tomber.

Ensuite, nos charges de travail séquentielles. En lecture 64K, la version DR a commencé au-dessus de 1 ms et a culminé à 132,918 8.3 IOPS ou 3.7 Go/s avec une latence de 1 ms. Avec DR désactivé, les disques sont restés inférieurs à 130 ms jusqu'à environ 8 159,681 IOPS ou environ 9.98 Go/s et ont culminé à 2.87 XNUMX IOPS ou XNUMX Go à une latence de XNUMX ms.

En écriture 64K, les deux configurations ont commencé avec une latence inférieure à la milliseconde mais ont rapidement dépassé 1 ms. Avec DR activé, nous avons vu un pic à seulement 22.7 1.4 IOPS ou environ 1.32 Go/s et une latence de 63,347 ms avant une baisse des performances et un pic de latence important. Avec DR désactivé, les disques ont culminé à 4 3.3 IOPS ou environ XNUMX Go / s à XNUMX ms avant d'en laisser tomber.

Notre prochaine série de tests concerne nos charges de travail SQL : SQL, SQL 90-10 et SQL 80-20. Pour SQL, les deux configurations ont commencé en dessous de 1 ms, la version DR passant au-dessus, puis en dessous de 1 ms tout au long du processus, pour culminer à 349,851 2.6 IOPS avec une latence de 255 ms. Avec DR désactivé, les disques avaient une latence inférieure à la milliseconde jusqu'à environ 358,787 2.24 IOPS et ont culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms avant une légère baisse.

Avec SQL 90-10, nous avons de nouveau vu la version compatible DR apparaître au-dessus et descendre plusieurs fois en dessous de la ligne de 1 ms avant de culminer à 283,524 3.42 IOPS avec une latence de 1 ms. La version non DR est restée inférieure à 275 ms jusqu'à environ 334,737 2.45 IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

SQL 80-20 a vu les deux configurations démarrer avec une latence inférieure à la milliseconde, la version DR dépassant 1 ms à environ 155 256,926 IOPS et culminant à 3.5 210 IOPS avec une latence de 1 ms. La version non DR a atteint environ 281,562 2.83 IOPS en moins de XNUMX ms et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Viennent ensuite nos charges de travail Oracle : Oracle, Oracle 90-10 et Oracle 80-20. Avec Oracle, la version DR-enable a basculé en dessous et au-dessus de 1 ms et a culminé à environ 264 3.7 IOPS à 250 ms avant de chuter légèrement. La version non DR avait une latence inférieure à la milliseconde jusqu'à environ 314,954 3.17 IOPS et culminait à XNUMX XNUMX IOPS XNUMX ms.

SQL 90-10 a vu la version DR-enable rester sous 1 ms jusqu'à environ 225 252,034 IOPS et culminer à 2.44 300 IOPS avec une latence de 338,146 ms. Le non-DR avait des performances de latence inférieures à la milliseconde jusqu'à environ 1.72 XNUMX IOPS et culminait à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Avec SQL 80-20, la version DR effectue quelques sauts autour de 1 ms et culmine à 225,327 2.64 IOPS avec une latence de 211 ms. La version non DR avait une latence inférieure à la milliseconde jusqu'à environ 278,051 2 IOPS et a culminé à XNUMX XNUMX IOPS et une latence de XNUMX ms.

Ensuite, nous sommes passés à notre test de clone VDI, Full et Linked. Pour le démarrage VDI Full Clone (FC), les deux configurations ont commencé en dessous de 1 ms, la version DR dépassant une latence inférieure à la milliseconde à environ 85 250,209 IOPS et atteignant un pic à 4.04 1 IOPS et une latence de 200 ms. La version non DR est restée inférieure à 283,786 ms jusqu'à environ 3.31 XNUMX IOPS et a culminé à XNUMX XNUMX IOPS et une latence de XNUMX ms avant de chuter légèrement.

Avec la connexion initiale VDI FC, la version DR a culminé à environ 129 4.2 IOPS à 1 ms avant de réduire considérablement les performances et d'augmenter considérablement la latence. La version non-DR a commencé en dessous de 75 ms et y est restée jusqu'à environ 139,401 6.3 IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms avec une légère baisse.

VDI FC Monday Login a fait démarrer la version DR sous 1 ms, mais l'a rapidement dépassée et a culminé à 108,611 2.22 IOPS avec une latence de 1 ms. La version non-DR est restée sous 90 ms jusqu'à un peu moins de 152,516 3.25 IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Pour VDI LC Boot, les deux configurations ont commencé en dessous de 1 ms avec le DR apparaissant immédiatement et atteignant un pic à 214,327 2.34 IOPS à une latence de 1 ms. La version non DR est restée inférieure à 205 ms jusqu'à environ 255,235 1.85 IOPS et a culminé à XNUMX XNUMX IOPS et une latence de XNUMX ms.

La connexion initiale VDI LC a vu la version DR culminer à environ 95 2.2 IOPS avec une latence de 1 ms avant de chuter de manière significative. La version non DR est restée en dessous de 65 ms jusqu'à environ 112,182 2.23 IOPS et a culminé à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Enfin, VDI LC Monday Login a brossé un tableau similaire à celui ci-dessus avec la version DR culminant à environ 108 3.7 IOPS avec une latence d'environ 65 ms avant de chuter un peu. La version non DR avait une latence inférieure à la milliseconde jusqu'à environ 126,656 3.91 IOPS et culminait à XNUMX XNUMX IOPS avec une latence de XNUMX ms.

Conclusion

Le Western Digital Ultrastar DC SN630 est le nouveau SSD NVMe pour centre de données qui se décline en deux versions : lecture centrée et utilisation mixte. Les disques sont disponibles dans des plages de capacité allant de 800 Go à 6.4 To pour une utilisation mixte et de 960 Go à 7.68 To pour la lecture centrée. Le lecteur exploite le contrôleur, le micrologiciel et la NAND 64D BiCS à 3 couches de Western Digital. Tous les disques offrent ISE, ce qui est idéal pour le redéploiement ou la retraite. Une autre fonction de sécurité est l'utilisation de téléchargements de micrologiciels sécurisés avec authentification RSA pour garantir que le SN630 exécute uniquement un micrologiciel authentique. Étant donné que le SN630 est certifié vSAN, nous l'avons testé dans le contexte de VMware vSAN pour voir comment il fonctionnait.

Pour les performances, nous avons exécuté le SSD Western Digital DC SN630 NVMe via notre analyse de la charge de travail des applications et notre analyse de la charge de travail VDBench. Pour l'analyse de la charge de travail des applications, les disques ont obtenu de bons résultats. Dans SQL Server, le SN630 avait un score transactionnel global de 12,610.3 14.8 TPS et une latence moyenne globale de 630 ms. Avec Sysbench, le SN11,739.7 a atteint 21.86 38.71 TPS, une latence moyenne de XNUMX ms, et dans le pire des cas, les disques nous ont donné un score global de XNUMX ms.

Dans nos charges de travail VDBench, nous avons testé les disques avec leur DR activé et désactivé. Évidemment, la désactivation de DR se traduira par de meilleures performances, cependant, plusieurs clients doivent exécuter DR et il est bon d'avoir une idée de la façon dont les disques fonctionneront avec DR activé. Les points forts pour DR étant désactivé incluent 442K IOPS en lecture 4K, 196K IOPS en écriture 4K, 9.98 Go/s en lecture 64K et 4 Go/s en écriture 64K. Dans nos charges de travail SQL, nous avons constaté 359 335 IOPS, 90 10 IOPS dans SQL 282-80 et 20 315 IOPS dans SQL 338-90. Pour Oracle, nous avons constaté des performances de pointe atteignant 10 278 IOPS, 80 20 IOPS dans Oracle 630-284 et 139 153 IOPS dans Oracle 630-255. Lors de notre test de clonage VDI, le SN112 nous a donné 127 XNUMX IOPS au démarrage, XNUMX XNUMX IOPS lors de la connexion initiale et XNUMX XNUMX IOPS lors de la connexion du lundi pour un clone complet. Dans le clone lié, le SNXNUMX a atteint XNUMX XNUMX IOPS au démarrage, XNUMX XNUMX IOPS lors de la connexion initiale et XNUMX XNUMX IOPS lors de la connexion du lundi.

Pour nos charges de travail VDBench avec DR enable, le SN630 avait des points forts de 388K IOPS en lecture 4K, 183K IOPS en écriture 4K, 8.3 Go/s en lecture 64K et 1.4 Go/s en écriture 64K. Dans nos charges de travail SQL, nous avons vu 350 283 IOPS, 90 10 IOPS dans SQL 257-80 et 20 264 IOPS dans SQL 252-90. Pour Oracle, nous avons constaté des performances de pointe atteignant 10 225 IOPS, 80 20 IOPS dans Oracle 630-220 et 129 109 IOPS dans Oracle 630-214. Lors de notre test de clonage VDI, le SN95 nous a donné 108 XNUMX IOPS au démarrage, XNUMX XNUMX IOPS lors de la connexion initiale et XNUMX XNUMX IOPS lors de la connexion du lundi pour un clone complet. Dans le clone lié, le SNXNUMX a atteint XNUMX XNUMX IOPS au démarrage, XNUMX XNUMX IOPS lors de la connexion initiale et XNUMX XNUMX IOPS lors de la connexion du lundi.

Lorsqu'il est utilisé dans VMware vSAN, le SSD Western Digital DC SN630 offre des performances impressionnantes même avec le DR activé. Dans ce cas, nous avons tiré parti d'une construction de serveur modeste et avons tout de même obtenu des résultats impressionnants. Le SN630 serait un bon choix pour ceux qui utilisent vSAN.

Page produit WD Ultrastar DC SN630

Discutez de cet avis

Inscrivez-vous à la newsletter StorageReview

*Les tests de performance sur lesquels cet examen était basé ont été commandés par Western Digital