Dans un précédent billet je vous avais présenté le CX400 M1 & CX2550 M2 de Fujitsu en Hyper Convergé Windows 2016.
Avec la sortie de Windows 2019 je vous propose un test du
Fujitsu PRIMERGY RX2540 M4.
Le serveur PRIMERGY RX2540 M4 est une machine biprocesseur s’appuyant sur les processeurs Intel® Xeon® ayant jusqu’à 28 cœurs UltraPath Interconnect pour des vitesses de transfert de données accrues entre les processeurs.
Au niveau mémoire, le serveur peut héberger jusqu’à 3 072 Go de DDR4 pouvant atteindre 2 666 MHz(24 slots DIMM)
Au niveau réseau, le serveur intgre un carte 2 x 10 Gbit/s Ethernet (RJ45), basée sur le chipset Intel X722. Cette carte assure le support de RDMA/iWARP ce qui est une exellente chose pour l’utilisation dans une solution hyper convergée.
Au niveau stockage le serveur peut heberger jusqu’a 24 disques 2,5 pouces SAS/SATA a l’avant, et optionnellement 4 disques supplémentaires a l’arriere. En interne, le serveur possede 2 slots M1 NVME pouvant etre utilisés pour stocker l’hyperviseur.
La plateforme de test est la suivante:
2x Fujitsu PRIMERGY RX2540 M4:
- CPU: 2 x Intel(R) Xeon(R) Silver 4108 CPU @ 1.80GHz
- Mémoire: 64 Go de DDR3 ECC enregistrés
- Espace de stockage:
- Système d’exploitation: 1x INTEL SSDSCKJB150G7
- Stockage S2D: 12x SSD SAMSUNG MZ7KM480 480Go
- Carte réseau:
- 2 x Intel(R) Ethernet Connection X722 10GBASE-T
- 2 x Intel(R) I350 Gigabit Network
- Système d’exploitation: Microsoft Windows Server 2019 Datacenter 1809
N’ayant pas pas de switch 10G BaseT, j’ai interconnecté les cartes 10G entre elles directement:
Ces cartes serviront exclusivement à la communication S2D. Ces cartes sont compatibles iWARP: Pour cela il faut installer un driver spécifique fourni par Intel délivré au travers d’un bundle de plus de 400Mo en version 23.2.
Ce dernier driver apporte le support RDMA au sein des VM Hyper-V (NDK mode 3). Mais cela nécessite l’utilisation de cartes X722 pour créer un
Switch Embedded Teaming (SET), qui supporte RDMA et vRSS.
N’ayant pas de switch physique 10 Gb, je me rabattrais vers un
Switch Embedded Teaming (SET) composé des deux cartes Intel I350 1Gb.
Storage Spaces Direct
Windows 2019 apporte son lot de nouveautés au niveau S2D:
- Déduplication et compression pour les volumes ReFS
- Prise en charge native de la mémoire persistante
- Résilience imbriquée pour une infrastructure hyper-convergée à deux nœuds
- Clusters deux nœuds utilisant une clé USB comme témoin
- Historique de performance
- Jusqu’à 4 PB par cluster
- La parité accélérée par le miroir deux fois plus rapide
- Détection des valeurs aberrantes de latence
Un des points intéressent, est la résilience imbriquée qui permet dans le cas d’un cluster deux nœuds, de perdre simultanément un nœud d’un cluster et un disque sur le nœud restant.
Pour tester l’impact des différentes options, j’ai utilisé comme sur mon précédent billet VMFleet afin de générer de la charge sur la plateforme.
Dans mes différents test, j’utiliserai 15 VM par nœud soit un total de 30 VM. Les paramètres de diskspd au sein des VMs seront les suivants:
.\
Start-Sweep
.ps1
-b
4
-t
8
-o
20
-w
0
-d
60
Soit des IO de 4k avec 8 thread, des queues de 20 et une durée de test de 60 secondes. Seule le paramètre w ( pourcentage d’écriture) variera en fonction des différents tests.
Test n°1: Miroir 2 voies sans déduplication 100% Lecture
J’ai créé deux volumes de 2 To de type « miroir 2 voies » comme historiquement sur une solution basée sur Windows 2016.
Dans ce cas de figure la plateforme fournit 533 000 IO/s avec une latence inférieure a 4 milliseconde.
Test n°2: Miroir 2 voies sans déduplication 30% écritures
Dans ce cas de figure la plateforme fournit 290 000 IO/s avec une latence en écriture inférieure à 20 milliseconde. La latence en lecture est elle toujours inférieure a 20 ms.
Test n°3: Parité imbriquée en miroir sans déduplication 100% lecture
Dans ce cas de figure la plateforme fournit 517 000 IO/s avec une latence inférieure a 1 milliseconde. La perte par rapport au miroir 2 voies est minime. En revanche le stockage utile disponible a diminué:
De 4.2 To utile, on passe à 3.3 To utile: c’est le prix à payer pour avoir de la tolérance de panne sur le stockage en cas de perte d’un nœud…
Test n°4: Parité imbriquée en miroir sans déduplication 30% écritures
La plateforme fournit 167 000 IO/s, mais la latence en écriture est entre 50 et 100 ms
Test n°4: Parité imbriquée en miroir avec déduplication 100% lecture
Avec la déduplication activée (85 % d’espace gagnée), les IO passent à 120 000 IO/s: à noter la latence entre 20 et 40 ms.
Test n°5: Parité imbriquée en miroir avec déduplication 30% écritures
On n’est plus qu’à 109 000 IO/s avec un latence entre 20 et 30 ms
Conclusion
Les deux nouvelles fonctionnalités de déduplication / compression, et de parité imbriquée rendent enfin complète la solution HCI de Microsoft même dans le cas d’un cluster 2 nœuds. Il faudra tout de même être vigilent sur le fait que ces mécanismes engendrent une surconsommation CPU. Dans mes différents test les processeurs étaient à 100%.
Il faut cependant relativiser cette surconsommation, car une configuration 2 nœuds s’adresse plus au marché SBS, qui ne sollicite pas forcément le stockage à concurrence de 100 000 IO/s. Les CPU seront des-lors plus à l’aise.
Concernant les serveurs PRIMERGY RX2540 M4 et S2D, ils sont totalement adaptés à cet usage et son certifié S2D par Microsoft. Dans tous les cas, le seul juge de paix pour le support de votre plateforme par Microsoft est le test de validation du cluster:
La partie « Storage Space Direct » devra sortir en vert:
Grace à leur cartes iWARP intégrées, les performance réseau sont remarquables. J’ai testé du transfert de fichiers inter nœud, le CPU ne bronche pas et le débit est la :):