Après avoir examiné les niveaux de performances du cluster VMware VSAN avec un OLTP Sysbench charge de travail, nous voulions savoir dans quelle mesure la plateforme répondait à une charge de travail accrue pour des cas d'utilisation plus exigeants. Le déploiement initial était de quatre machines virtuelles Sysbench, 1 par nœud, mais cette charge de travail n'a pas amené les E/S de disque à une plage suffisamment élevée pour que nous sentions que les ressources étaient pleinement utilisées. Ceci est similaire à un client exécutant un POC, le testant sous un sous-ensemble de sa charge de travail actuelle, mais ne mesurant pas la façon dont la plate-forme réagit à mesure que les charges de travail augmentent au fil du temps ou que davantage de données d'application sont migrées. Pour mieux comprendre comment ce cluster VSAN répond aux charges de travail MySQL en constante augmentation, nous avons fait évoluer le benchmark de quatre VM Sysbench (1 par nœud) jusqu'à 8 et 12 VM au total.
Après avoir examiné les niveaux de performances du cluster VMware VSAN avec un OLTP Sysbench charge de travail, nous voulions savoir dans quelle mesure la plateforme répondait à une charge de travail accrue pour des cas d'utilisation plus exigeants. Le déploiement initial était de quatre machines virtuelles Sysbench, 1 par nœud, mais cette charge de travail n'a pas amené les E/S de disque à une plage suffisamment élevée pour que nous sentions que les ressources étaient pleinement utilisées. Ceci est similaire à un client exécutant un POC, le testant sous un sous-ensemble de sa charge de travail actuelle, mais ne mesurant pas la façon dont la plate-forme réagit à mesure que les charges de travail augmentent au fil du temps ou que davantage de données d'application sont migrées. Pour mieux comprendre comment ce cluster VSAN répond aux charges de travail MySQL en constante augmentation, nous avons fait évoluer le benchmark de quatre VM Sysbench (1 par nœud) jusqu'à 8 et 12 VM au total.
Spécifications du Dell PowerEdge R730xd VMware VSAN
- Serveurs Dell PowerEdge R730xd (x4)
- Processeurs : Huit Intel Xeon E5-2697 v3 2.6 GHz (14C/28T)
- Mémoire : 64 x 16 Go DDR4 RDIMM
- SSD : 16 disques SSD de 800 Go avec utilisation mixte MLC 12 Gbit/s
- Disque dur : 80 x 1.2 To 10 6 tr/min SAS XNUMX Gbit/s
- Mise en réseau : 4 x Intel X520 DP 10 Go DA/SFP+, + I350 DP 1 Go Ethernet
- Capacité de stockage: 86.46TB
Performances de Sybench
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é-construite (~ 447 Go) et le troisième pour la base de données testée (400 Go). 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.
Avec une charge de 8 machines virtuelles, nous avons vu les machines virtuelles Sysbench consommer entre 5,200 6,300 et 18,000 22 MHz chacune, avec des ressources hôtes totales indiquant qu'environ 8 16 MHz étaient utilisés. Cela a laissé beaucoup de ressources CPU avec seulement 14 % utilisées par hôte, bien qu'avec une charge de travail de 86.46 machines virtuelles Sysbench, nous utilisions presque tout le cache SSD disponible. Pour l'impact sur le stockage, nous avons chargé 8 machines virtuelles Sysbench pour élargir l'empreinte globale, consommant environ 7 To de la capacité de stockage VSAN totale de 14 To. Au moment de la charge de travail de 3.5 VM, seuls 4 To de ces XNUMX To étaient cependant actifs. Cela se compare à XNUMX To dans la charge de travail de XNUMX VM.
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 : 12 heures
- 6 heures de préconditionnement 32 fils
- 1 heure 32 fils
- 1 heure 16 fils
- 1 heure 8 fils
- 1 heure 4 fils
- 1 heure 2 fils
Au fur et à mesure que nous faisions évoluer la charge de travail OLTP Sysbench, nous avons mesuré une augmentation des performances de 2,830 4 TPS au total avec 4,259 VM à 8 50 TPS avec XNUMX VM. Cela équivaut à une augmentation de XNUMX % des performances avec un doublement de l'empreinte de la charge de travail.
Avec l'augmentation des performances transactionnelles globales, nous avons mesuré l'augmentation moyenne de la latence de 45 ms à 60 ms par machine virtuelle. Il s'agit d'un saut d'environ 33 % par rapport à la charge de travail plus petite.
La latence moyenne au 99e centile a également augmenté, passant de 94 ms à 131 ms, à mesure que les demandes d'E/S augmentaient.
Pendant que le benchmark fonctionnait, nous avons capturé les statistiques du processeur, du disque et du réseau à partir de vCenter. Au cours du test de 8 VM, nous avons constaté une propagation VM-CPU de 5,275 6,393 MHz à XNUMX XNUMX MHz sur les VM.
Avec 2 machines virtuelles actives par nœud, nous avons constaté une activité de disque mixte mesurant un total de 609 Mo/s après le démarrage de la charge de travail. Les pics les plus importants ont été mesurés pendant que la base de données prédéfinie se copiait dans chaque VM au début du test.
Le trafic réseau d'un hôte pendant le test 8 VM Sysbench a mesuré un mélange de 391 Mo/s après que le test se soit stabilisé.
Étant donné que le but de ce test est de montrer comment VSAN répond à une charge de travail en constante augmentation, nous avons poussé la plate-forme à 12 VM au total après l'exécution de 8 VM. Ce fut le point de rupture où une partie de la charge de travail a été poussée en dehors du cache SSD. Nous n'avons pas tracé ces performances car la plupart des charges de travail ne se sont pas terminées ou n'ont pas obtenu les scores appropriés. Pour les machines virtuelles qui se sont terminées, nous aurions vu des performances de transaction globales aussi basses que 1000 1500 à 1.6 800 TPS sur l'ensemble du cluster. La baisse de performances que nous avons mesurée peut bien sûr être atténuée avec des périphériques flash plus grands, tels que des SSD de XNUMX To au lieu de XNUMX Go, ou le passage à un modèle VSAN entièrement flash où le déversement dans votre niveau de lecture n'a pas un aussi grand d'un Station d'E/S. Cela souligne la nécessité de dimensionner correctement le composant flash de l'environnement VSAN, les administrateurs ou leurs partenaires revendeurs doivent avoir une bonne connaissance de l'ensemble de données de travail. C'est l'un des points forts de la plate-forme VSAN ; permettant aux clients de personnaliser les configurations pour mieux répondre aux besoins des charges de travail actuelles et futures ou d'échanger/d'ajouter des SSD à moindre coût selon les besoins.
Savoir où se situent les points de rupture de votre plateforme est très important. Les charges de travail déployées initialement augmenteront généralement au fil du temps, à la fois en nombre de machines virtuelles et en capacité de stockage. Chaque plate-forme de stockage a un point d'étranglement (même les baies entièrement flash), ce qui nous amène à la façon dont ce cluster VSAN à quatre nœuds s'empile. Actuellement, nous n'avons eu qu'une seule plate-forme de stockage qui a exécuté avec succès 12 et 16 machines virtuelles Sysbench, qui était une baie 575,000 % flash avec un PDSF de XNUMX XNUMX $. Les futurs tests de ce cluster VSAN incluront toutefois des configurations XNUMX % Flash pour tenter d'atteindre des objectifs de performances similaires.
Examen de VMware Virtual SAN : présentation et configuration
Examen de VMware Virtual SAN : performances de VMmark
Examen de VMware Virtual SAN : performances OLTP de Sysbench
Examen de VMware Virtual SAN : performances de SQL Server
Examen de VMware Virtual SAN : performances OLTP Sysbench évolutives
Examen de VMware Virtual SAN : performances synthétiques HCIbench
Inscrivez-vous à la newsletter StorageReview
