Rapide aujourd'hui, prêt pour demain : stockage unifié QSAN XN4226D

QSAN conçoit des solutions de stockage d'entreprise depuis 2004, et cette expérience se reflète dans la gamme XN4. Le XN4226D, présenté dans notre laboratoire, est une baie 2U, 26 baies, entièrement NVMe, dotée de deux contrôleurs actifs, offrant une haute disponibilité grâce à un stockage unifié en mode bloc et fichier. Le logiciel QSM 4 ajoute les services de données attendus, notamment les snapshots, les options de réplication, la réduction des données et une gestion simplifiée. Le XN4 est conçu pour les équipes qui recherchent la vitesse NVMe sans compromettre la flexibilité multiprotocole, le tout à un prix très abordable.

À retenir

• Bloc et fichier unifiés avec un véritable HA. Les contrôleurs actifs doubles et QSM 4 offrent une haute disponibilité avec une seule plate-forme pour les blocs et les fichiers.
• NVMe-oF bien fait. Protocole complet diffusé avec NVMe-oF sur TCP et RDMA aux côtés d'iSCSI, Fibre Channel, NFS, SMB, FTP et WebDAV.
• Débit prouvé. Nous avons mesuré jusqu'à 21.21 Go/s sur des lectures séquentielles volumineuses avec TCP et 11.14 Go/s sur des écritures séquentielles volumineuses avec RDMA.
• Conçu pour les pipelines modernes. 26 baies entièrement NVMe dans 2U, gestion simple et options d'E/S évolutives jusqu'à 100-200 GbE pour les médias, les analyses de surveillance, le VDI, les bases de données et l'inférence d'IA.

La plateforme prend en charge NVMe-oF sur TCP et RDMA, ainsi que iSCSI, Fibre Channel, NFS, SMB, FTP et WebDAV. Nous avons également réalisé une étude NVMe-oF ciblée comparant le comportement et la scalabilité de TCP et RDMA. Lors de nos tests, nous avons poussé l'unité à ses limites avec des lectures séquentielles volumineuses, atteignant un débit impressionnant de 21.21 Go/s. L'intégration de ce système est aussi importante que les chiffres bruts. Le XN4226D est compatible avec des environnements mixtes combinant VMware ou Proxmox pour les machines virtuelles, les infrastructures VDI et les niveaux de base de données, ainsi que des services de fichiers créatifs, des nœuds d'inférence IA nécessitant des chemins NVMe prévisibles, des sauvegardes de médias et une ingestion haut débit pour les charges de travail de surveillance et de capteurs. Le QSAN XN4226D est parfaitement adapté à la quasi-totalité des charges de travail.

QSAN a constaté une croissance significative de la production multimédia, notamment pour les diffusions en direct, les options de rediffusion, l'amélioration vidéo par l'IA et la mise en cache OTT/edge, ainsi que pour l'analyse vidéo de surveillance, comme la vidéosurveillance urbaine intelligente, la détection d'anomalies et la rediffusion en temps réel. Ces charges de travail sont idéalement prises en charge par un débit de 100 à 200 GbE.

En fin de compte, la valeur est évidente. Vous bénéficiez d'une haute disponibilité unifiée, de NVMe sur l'ensemble du châssis et d'un choix d'E/S allant jusqu'à 100 GbE ou 32 Gb Fibre Channel selon vos besoins. Les performances sont comparables à celles de nombreuses baies de stockage de niveau 1, tandis que les licences restent plus accessibles et la couverture des protocoles reste étendue (NVMe-oF, iSCSI, Fibre Channel, SMB et NFS). Pour les entreprises qui envisagent InfiniBand mais dont le budget est limité, l'approche Ethernet de QSAN offre une réactivité proche de celle d'un IB sur des équipements standard, à l'échelle de 100 à 200 GbE.

Pour les équipes qui privilégient les résultats d'applications concrètes, la longévité du QSAN, son logiciel intuitif et sa conception matérielle épurée font du XN4226D un cheval de bataille entièrement flash crédible sur lequel construire.

Matériel QSAN XN4

Les baies de stockage QSAN de la série XN4 sont proposées dans un châssis serveur 2U 19 pouces compatible rack, avec 26 baies et un ou deux contrôleurs, abritant des processeurs Intel Xeon 4 ou 8 cœurs, pour répondre aux besoins de redondance et de performance des plus petites comme des plus grandes entreprises. Avec ses 26 baies occupées, un seul châssis XN4 peut stocker jusqu'à 798 téraoctets de données sur des disques SSD NVMe U.2/U.3 de 2.5 pouces. Il est également possible d'ajouter jusqu'à 20 unités d'extension connectées SAS, portant la capacité totale d'une baie à 16.773 pétaoctets.

Chaque contrôleur embarqué dispose d'un port Ethernet RJ45 2.5 Gbit/s, de quatre ports SFP+ 10 Gbit/s et de deux ports SAS 12 Gbit/s. Des options de mise à niveau sont également disponibles pour les ports RJ45 10 Gbit/s, SFP28 25 Gbit/s et QSFP 100 Gbit/s. La compatibilité Fibre Channel est également possible grâce aux adaptateurs SFP+ 16 Gbit/s et SFP28 32 Gbit/s.

Le tableau ci-dessous compare les spécifications des systèmes de stockage XN4226D-4C et XN4226S-4C. Il s'agit des variantes 4C, conçues avec des contrôleurs actifs doubles ou simples évolutifs selon le modèle. Pour les déploiements nécessitant une puissance de traitement accrue, une version 8C de ces systèmes est également disponible.

Spécifications	XN4226D-4C	XN4226S-4C
Nom du modèle	XN4226D-4C	XN4226S-4C
Architecture	Contrôleur double-actif	Contrôleur unique évolutif
Processeur	Intel® Xeon® 4 cœurs × 2	Intel® Xeon® 4 cœurs
Mémoire
Module de mémoire préinstallé	32 Go DDR4 RDIMM	16 Go DDR4 RDIMM
Nombre total d'emplacements de mémoire	16	8
Mémoire extensible jusqu'à	2,048GB	1,024GB
Rangements
Baies de disques	Fente 2.5″ × 26	Fente 2.5″ × 26
Nombre maximal de baies de disques avec unité d'extension	546	546
Type de lecteur compatible	SSD NVMe U.2 / U.3 double port 2.5 pouces SSD SAS 2.5″ (pour unités d'extension) Disque dur SAS 3.5″ (pour unités d'extension)	SSD NVMe U.2 / U.3 à port unique de 2.5 pouces SSD SAS 2.5″ (pour unités d'extension) Disque dur SAS 3.5″ (pour unités d'extension)
Interface d'entraînement	U.2 NVMe (PCIe Gen 4) SAS 12 Gb/s (pour unités d'extension)	U.2 NVMe (PCIe Gen 4) SAS 12 Gb/s (pour unités d'extension)
Capacité brute interne maximale	798TB	798TB
Capacité brute maximale avec extension	16,773TB	16,773TB
Disque remplaçable à chaud	Oui	Oui
Port de connectivité
Extension PCIe	(Emplacement Gen 4×8) × 4	(Emplacement Gen 4×8) × 2
Port LAN RJ45 2.5 GbE	2 (à bord)	1 (à bord)
Port LAN SFP+ 10 GbE	8 (à bord) / 16 (en option)	4 (à bord) / 8 (en option)
Port LAN RJ45 10 GbE	16 (option)	8 (option)
Port LAN SFP28 25 GbE	16 (option)	8 (option)
Port LAN QSFP 100 GbE	8 (option)	4 (option)
Fibre Channel SFP+ 16 Gb	16 (option)	8 (option)
Fibre Channel SFP28 32 Go	16 (option)	8 (option)
Extension et port externe
Port large SAS 12 Gb/s	4 (à bord)	2 (à bord)
Port USB	1 (avant) / 2 (arrière)	1 (avant) / 1 (arrière)
Autres	Port de console × 2, port de service × 2	Port de console × 1, port de service × 1
Spécification du logiciel
Système d'exploitation de stockage	QSM 4	QSM 4
Type de RAID	0 / 1 / 5 / 6 / 10 / 50 / 60 / 5EE / 6EE / 50EE / 60EE
Efficacité de stockage	Provisionnement léger / Compression et déduplication (option)
Accélération logicielle	Cache SSD / Hiérarchisation automatique / RDMA
Protection des données	Instantané / Asynchrone / Synchrone (option)
Service de sauvegarde	Sauvegarde Rsync / S3 / Sauvegarde Cloud / XMirror* / Sauvegarde des e-mails Microsoft 365
Sûreté	SSL / SSH / iSCSI CHAP / ISE et SED / WORM / RBAC / Windows ACL / Antivirus
Protocoles de support	CIFS / NFS / FTP / WebDAV / iSCSI / FCP / NVMe-oF
Management	Interface utilisateur Web / Windows AD / LDAP / API RESTful / SES / LCM
lustrée
Dimensions (H × L × P)	88 × 438 × 573mm	88 × 438 × 573mm
Poids net	19.6 kg	16.5 kg
Poids brut	28.6 kg	25.5 kg
Autres
Protection mémoire	Module Cache-to-Flash (intégré)
Système Fan	8 pièces	4 pièces
Bloc D'Alimentation	850 W × 2 (80 Plus Platinum)
Alimentation	100 – 240 VCA, 50/60 Hz
Consommation d'énergie	812 W / 2 770 BTU
Zertifizierung beitragen	CE / FCC / BSMI
Garantie standard	Système : 5 ans | Module Cache-to-Flash : 1 an

Capacités de QSAN XN4

Les baies XN4 sont équipées en standard des protocoles de connexion les plus récents, nécessaires à la prise en charge des calculs haute performance et des modèles d'IA gourmands en données, notamment NVMe over Fabrics (NVMe-oF) via TCP et RDMA. Les connexions via iSCSI, NFS, FCP, CIFS/SMB, FTP et WebDAV sont également possibles, permettant à la baie de répondre aux besoins de stockage en mode bloc et fichier des centres de données utilisant des systèmes traditionnels et de pointe.

Les avantages du NVMe-oF

Si des protocoles tels que iSCSI, NFS et FCP sont encore largement utilisés dans les applications de stockage d'entreprise, NVMe-oF offre des améliorations significatives en termes de latence. Les normes NVMe ont été conçues dès l'origine pour les disques SSD connectés directement au bus PCIe d'un système. En revanche, les protocoles plus anciens comme iSCSI et NFS ont été développés pour pallier les limitations et les temps d'accès plus lents des disques durs traditionnels. Dans la quasi-totalité des cas, les technologies NVMe-oF surpassent les anciens protocoles de connexion, avec une bande passante plus élevée et des temps d'accès plus rapides. NVMe-oF peut également exploiter les interfaces réseau avec accès direct à la mémoire à distance (RDMA), permettant ainsi le transfert direct des données vers la mémoire d'un ordinateur cible sans nécessiter de traitement CPU.

Fonctionnalités de réduction et d'optimisation des données

La pile matérielle hautes performances de la baie de stockage XN4 est enrichie de nombreuses fonctionnalités logicielles reconnues et appréciées des administrateurs de stockage. Le provisionnement fin, la compression et la déduplication permettent aux entreprises d'optimiser la capacité de leur SAN, tandis que la mise en cache SSD et la hiérarchisation automatique du stockage accélèrent les temps d'accès aux fichiers et objets fréquemment utilisés. Le système d'exploitation QSM 4 de l'appliance simplifie également les tests et la restauration des modifications grâce aux outils de snapshots intégrés.

Fonctionnalités de sécurité et de gestion

QSAN a pris en compte l'évolution des besoins de sécurité et de gestion de ses clients avec la gamme XN4. Le XN4 est compatible avec l'effacement sécurisé instantané (ISE) et les disques à chiffrement automatique (SED), ainsi qu'avec les protocoles de sécurité tels que SSL/TLS, l'authentification par contrôle d'accès basé sur les rôles (RBAC) et la prise en charge des serveurs Active Directory/LDAP. La baie peut être gérée via une interface web HTTPS ou une API RESTful, permettant l'automatisation grâce à une grande variété d'outils, tels qu'Ansible ou Terraform.

Gestion QSM 4

QSM 4, le système d'exploitation de la série QSAN XN4, simplifie la configuration et la gestion de la baie de stockage pour les administrateurs de stockage de tous niveaux. Le déploiement est simple et immédiat : création rapide de pools, affectation intuitive des hôtes et gestion simplifiée via l'interface web et les API REST, le tout conçu pour les petites équipes informatiques sans expertise approfondie en stockage.

L'écran du tableau de bord affiche les informations sur l'état du système et les événements récents enregistrés par le serveur.

Après connexion, l'utilisateur accède au tableau de bord, qui fournit un aperçu rapide de l'état du SAN. De là, il peut accéder à n'importe quel sous-menu de la liste du panneau de gauche.

À partir du menu Stockage, les administrateurs peuvent créer et gérer des pools de lecteurs et leurs volumes associés.

Les groupes de disques qui constituent chaque pool peuvent être gérés dans l'onglet « Groupes de disques ». Cette fonctionnalité prend en charge différents niveaux RAID, notamment 0, 1, 5, 6, 10, 50, 60, 5EE, 6EE, 50EE et 60EE, selon le nombre de disques déjà attribués.

Des volumes pour le stockage de blocs et de fichiers peuvent ensuite être créés sur des pools. Grâce à l'assistant, la capacité et la taille des blocs de chaque volume peuvent être définies pour répondre aux besoins des clients connectés.

En descendant dans la liste, le menu « Partages » permet de créer un objet de partage sur un volume de fichiers. Les protocoles de partage pris en charge incluent CIFS (SMB), FTP, NFS et WebDAV.

Lors de la création d'un nouveau partage, QSM 4 propose deux options : un partage réseau standard pour héberger des fichiers auxquels plusieurs utilisateurs accéderont et un partage userhome, conçu pour contenir les dossiers personnels des utilisateurs auxquels ils ne peuvent accéder qu'individuellement.

Une fois qu'un volume de blocs ou un volume de fichiers et un partage sont créés, il faut leur attribuer une adresse IP ou un nom d'hôte dans le menu « Hôtes ». Les hôtes sont classés selon qu'ils correspondent à un stockage de blocs ou de fichiers (partage), comme illustré dans les captures d'écran ci-dessous.

Les hôtes de stockage en mode bloc peuvent utiliser iSCSI, FCP ou NVMe-oF sur TCP pour un volume. En revanche, les hôtes de stockage de fichiers (partagés) peuvent prendre en charge plusieurs protocoles simultanément, offrant une flexibilité essentielle aux centres de données ayant des besoins variés en matière de partage de fichiers.

QSM 4 fournit également des fonctionnalités de surveillance de base dans le menu Monitor, affichant les états de divers modules matériels et lecteurs au sein de la matrice, ainsi que des statistiques sur l'utilisation du lecteur, du pool de stockage, du processeur et de la mémoire.

L'interface web de QSM 4 permet également de gérer les utilisateurs, les groupes et les domaines via le menu « Comptes ». Diverses options de configuration pour l'ensemble du SAN sont également disponibles dans le menu « Système ». Les fonctionnalités de journalisation et d'alerte sont accessibles depuis le menu « Notification ». Enfin, les icônes « Gestionnaire de fichiers QSAN », « Prise en charge linguistique » et « Déconnexion/Gestion de l'alimentation » se trouvent en haut à droite de la barre de menus.

Intégration simple de Proxmox

Proxmox prend en charge nativement NVMe over Fabrics (NVMe-oF), facilitant l'intégration de baies de stockage hautes performances dans un cluster. Le processus commence par le provisionnement de cibles NVMe-oF sur votre système de stockage. Ensuite, utilisez l'hôte Proxmox pour détecter ces cibles et vous y connecter. Une fois connecté, vous devez configurer le système pour garantir la persistance de ces connexions après redémarrage.

Dans notre exemple, la découverte est effectuée à l’aide de commandes shell, qui spécifient l’adresse IP et le port de service de la baie.

nvme discover -t tcp -a 172.16.16.100 -s 4420
nvme discover -t tcp -a 172.13.13.100 -s 4420

Ensuite, connectez-vous aux espaces de noms provisionnés en référençant leurs NQN.

nvme connect -t tcp -n nqn.2024-11.com.qsan:dev4 -a 172.16.16.100 -s 4420
nvme connect -t tcp -n nqn.2024-11.com.qsan:dev6 -a 172.13.13.100 -s 4420

Pour garantir que la configuration est persistante lors des redémarrages, les adresses de découverte peuvent être ajoutées au fichier de configuration de découverte NVMe.

echo "discover -t tcp -a 172.16.16.100 -s 4420" | tee -a /etc/nvme/discovery.conf
echo "discover -t tcp -a 172.13.13.100 -s 4420" | tee -a /etc/nvme/discovery.conf

Enfin, activez le service de connexion automatique afin que Proxmox rétablisse automatiquement les sessions NVMe au démarrage.

systemctl enable nvmf-autoconnect.service

Proxmox peut être intégré de manière transparente au stockage QSAN, offrant les performances à faible latence et à bande passante élevée du NVMe ainsi que la flexibilité des structures en réseau.

Après avoir attaché notre QSAN, nous pouvons exécuter la commande « nvme list » à partir du shell Proxmox pour afficher tous les périphériques NVMe, où les volumes QSAN nouvellement ajoutés apparaissent sous les noms /dev/nvme6n1 et /dev/nvme7n1, chacun avec 11 To de stockage.

Une fois que le stockage QSAN est visible dans l'interface graphique Proxmox, nous pouvons créer un nouveau groupe de volumes LVM : pve > Disques > LVM, les deux périphériques de 11 To (/dev/nvme6n1 et /dev/nvme7n1) apparaissent et peuvent être initialisés en tant que groupes de volumes distincts (par exemple, qsan-1 et qsan-2) pour une utilisation avec des machines virtuelles et des conteneurs.

Cliquer sur l'un de nos nouveaux pools LVM (qsan-1) dans le volet de stockage indique qu'il est en ligne, activé et disponible à l'utilisation, avec une capacité totale de 11 To, et prêt pour le provisionnement de machines virtuelles et de conteneurs.

Test de performance

Nous avons testé le QSAN XN4226D dans deux environnements, en utilisant différentes plateformes de test. Notre premier environnement était basé sur un Dell PowerEdge R750, équipé de quatre cartes réseau NVIDIA ConnectX-5 double port 25G. Nous avons connecté directement le QSAN XN4226D à ce serveur à l'aide de huit câbles DAC. Cette configuration exploitait tous les ports réseau disponibles du QSAN, ce qui nous a permis d'exploiter ses performances maximales.

Pour le test FIO, nous avons utilisé deux pools de stockage RAID6, créant huit volumes de blocs répartis uniformément sur les deux contrôleurs. Chaque volume était assigné à une cible unique, une adresse IP lui étant dédiée. Nous avons mesuré les protocoles NVMe-oF RDMA et TCP sur cette plateforme.

Le deuxième environnement pour GDSIO s'appuyait sur un Dell PowerEdge R7715, équipé de deux GPU NVIDIA H100 et d'une carte réseau Broadcom 25G à quatre ports. Dans cet environnement, nous avons conservé la même configuration de volumes QSAN, tout en réduisant le nombre de volumes de huit à quatre. Avec une carte réseau à quatre ports, nous avons utilisé quatre connexions 25G pour connecter directement le serveur à la baie de stockage.

Benchmark de performance FIO

Pour mesurer les performances de stockage du QSAN XN4226D, nous avons appliqué des mesures courantes du secteur et utilisé l'outil FIO. Chaque périphérique de stockage est soumis au même processus de test, qui comprend une étape de préconditionnement impliquant deux remplissages complets du disque avec une charge de travail en écriture séquentielle, suivie d'une mesure des performances en régime permanent. À chaque modification du type de charge de travail mesuré, nous effectuons un nouveau remplissage de préconditionnement avec cette nouvelle taille de transfert.

Dans cette section, nous nous concentrons sur les benchmarks FIO suivants :

• 1M séquentiel
•  64K Aléatoire
• 16K Aléatoire
• 4K Aléatoire

Bande passante d'écriture séquentielle de 1 M

Lors du test d'écriture séquentielle de 1 Mo, NVMe sur RDMA a systématiquement fourni une bande passante supérieure pour presque toutes les profondeurs de file d'attente et tous les nombres de tâches, par rapport à NVMe sur TCP. Au maximum, RDMA a atteint 11.14 Go/s, tandis que TCP a plafonné à 8.83 Go/s, soit une différence d'environ 26 % en faveur de RDMA. Même à des profondeurs de file d'attente plus faibles, RDMA a conservé son avantage. Par exemple, pour la tâche QD1/1, il a atteint 6.30 Go/s, surpassant les 4.77 Go/s de TCP d'environ 32 %.

L'écart de performance entre les deux protocoles s'est quelque peu réduit à mesure que les charges de travail augmentaient, mais le RDMA a conservé un net avantage. TCP a constamment oscillé entre 8.5 et 8.8 Go/s sur plusieurs points de test, tandis que le RDMA a fréquemment dépassé la barre des 10.5 Go/s, atteignant un pic légèrement supérieur à 11 Go/s.

Latence d'écriture séquentielle de 1 M

Lors du test de latence d'écriture séquentielle de 1 M, RDMA a de nouveau conservé un net avantage en termes d'efficacité sur TCP pour la plupart des profondeurs de file d'attente et du nombre de tâches. À des charges de travail plus légères, les deux protocoles se sont rapprochés, affichant tous deux des latences inférieures à 5 ms. Cependant, à mesure que la concurrence augmentait, les différences sont devenues plus marquées. Par exemple, pour les tâches QD16/16, RDMA a enregistré 368.48 ms, tandis que TCP a enregistré 455.95 ms, soit une amélioration de 19 % pour RDMA.

La divergence s'est accentuée aux échelles extrêmes. Sur la tâche QD256/1, le RDMA a atteint 1 389,16 ms, tandis que le TCP a atteint 1 987,39 ms, ce qui représente une réduction de latence de 43 % en faveur du RDMA. Cette tendance souligne la capacité du RDMA à maintenir un débit plus élevé tout en maîtrisant la latence, notamment dans les scénarios de forte charge.

Bande passante de lecture séquentielle de 1 M

Lors du test de lecture séquentielle de 1 Mo, la dynamique des performances a changé, TCP surpassant nettement RDMA sur tous les plans. TCP a atteint un pic de 21.21 Go/s, tandis que RDMA a plafonné à 15.96 Go/s, soit une différence d'environ 33 % en faveur de TCP. Même avec des profondeurs de file d'attente plus faibles, TCP a rapidement progressé. Par exemple, pour les tâches QD1/4, TCP a atteint 18.91 Go/s, contre 15.05 Go/s pour RDMA, soit un écart de plus de 25 %.

L'avantage de TCP s'est avéré constant sur presque toutes les échelles de charge de travail. Une fois la saturation atteinte, TCP a maintenu ses résultats autour de 20-21 Go/s, tandis que RDMA s'est stabilisé autour de 15 Go/s. Cela indique que si RDMA excelle dans les opérations gourmandes en écriture et sensibles à la latence, TCP affiche une meilleure efficacité de bande passante en lecture séquentielle avec la configuration RAID6 NVMe testée.

Latence de lecture séquentielle de 1 M

Lors du test de latence de lecture séquentielle de 1 M, les résultats étaient plus proches entre les deux protocoles, même si le RDMA présentait généralement un léger avantage pour les profondeurs de file d'attente plus élevées. Avec des charges de travail plus légères, les profils de latence étaient quasiment identiques, les deux restant inférieurs à 5 ms jusqu'à ce que la concurrence commence à augmenter. Par exemple, pour les tâches QD8/64, TCP a enregistré 234.09 ms, tandis que le RDMA a enregistré un temps inférieur à 194.54 ms, soit une réduction de 17 %.

Cette tendance s'est poursuivie avec des charges plus importantes. Pour les tâches QD32/64, le RDMA a enregistré 847.59 ms, contre 881.31 ms pour TCP, soit une légère amélioration de 3.8 %, mais néanmoins cohérente avec la faible surcharge de pile du RDMA. Cela dit, les deux protocoles ont évolué de manière similaire, la latence augmentant de manière prévisible à mesure que la charge de travail s'intensifiait.

64 000 IOPS d'écriture aléatoire

 

Lors du test d'écriture aléatoire de 64 K, RDMA a systématiquement fourni des IOPS supérieures à celles de TCP, soulignant son efficacité dans la gestion des opérations aléatoires parallélisées. Au maximum, RDMA a atteint 58.89 K IOPS, tandis que TCP était à la traîne avec 48.57 K IOPS, soit un avantage de performance de 21 %.

L'écart entre les deux protocoles était présent tout au long du test. Par exemple, pour les tâches QD1/16, RDMA a enregistré 54 130 IOPS, contre 45 300 IOPS pour TCP, soit une différence de près de 16 %. À mesure que la charge de travail augmentait, RDMA a maintenu des résultats compris entre 53 000 et 55 000 IOPS, tandis que TCP maintenait une plage de 42 000 à 46 000 IOPS.

Latence d'écriture aléatoire de 64 K

Lors du test de latence d'écriture aléatoire de 64 K, le protocole RDMA a une fois de plus affiché des temps de réponse inférieurs à ceux de TCP, notamment à mesure que la profondeur des files d'attente et le nombre de tâches augmentaient. À faible charge, les deux protocoles ont affiché des performances quasi identiques, restant inférieurs à 1 ms. Par exemple, pour la tâche QD1/1, TCP a enregistré un temps de réponse de 0.26 ms, tandis que le protocole RDMA a affiché un temps de réponse sensiblement identique, soit 0.25 ms.

Cependant, à mesure que la charge de travail augmentait, le RDMA a conservé son avantage en termes d'efficacité. Pour les tâches QD16/64, le RDMA a enregistré 74.09 ms, contre 95.64 ms pour TCP, soit une différence d'environ 23 %. L'écart s'est encore creusé sous une charge maximale pour la tâche QD256/1, où le RDMA a enregistré 291.13 ms, tandis que TCP a bondi à 398.56 ms, soit une augmentation de près de 37 %.

IOPS en lecture aléatoire 64K

Lors du test de lecture aléatoire de 64 K, TCP et RDMA ont affiché des performances globalement très similaires, l'avantage variant légèrement entre les deux protocoles selon la charge de travail. TCP a atteint un pic de 176.33 K IOPS, suivi de près par RDMA avec 175.40 K IOPS, affichant une différence de seulement 0.5 %.

À des profondeurs modérées, les résultats sont restés très groupés. Par exemple, pour les jobs du trimestre 4/16, TCP a enregistré 168 600 IOPS, suivi de RDMA avec 163 940 IOPS, soit un écart de moins de 2.8 %. Sur d'autres points, RDMA a légèrement progressé, notamment pour les jobs du trimestre 8/1, où il a atteint 171 710 IOPS, contre 171 150 IOPS pour TCP, soit une quasi-égalité.

Latence de lecture aléatoire de 64 K

Lors du test de latence de lecture aléatoire de 64 K, les deux protocoles se sont très bien suivis, même si le RDMA a affiché un léger avantage sous charge élevée. À faible charge, TCP et RDMA ont tous deux affiché des latences inférieures à 1 ms, pratiquement identiques. Par exemple, pour la tâche QD1/1, TCP a enregistré 0.43 ms contre 0.38 ms pour le RDMA.

À mesure que la concurrence augmentait, l'écart de performance devenait plus marqué. Aux QD16/64, le RDMA affichait 23.28 ms, tandis que TCP enregistrait 26.19 ms, soit une amélioration de 12 %. L'écart s'est creusé sous contrainte maximale, le RDMA atteignant 98.08 ms contre 129.02 ms pour TCP, soit une réduction de 24 %.

IOPS en écriture aléatoire 16K

Lors du test d'écriture aléatoire de 16 000, l'écart de performances entre les deux protocoles était important, le RDMA fournissant plus du double des IOPS de TCP dans la plupart des cas. Le RDMA a atteint un pic de 111.13 000 IOPS, tandis que le TCP a atteint 68.95 000 IOPS, ce qui représente un avantage de 61 % pour le RDMA.

À des profondeurs de file d'attente plus faibles, la différence était évidente. Par exemple, pour les tâches QD1/16, RDMA a enregistré 104.86 000 IOPS, contre 41.78 000 IOPS pour TCP, soit une augmentation de 151 % en faveur de RDMA. Sur toute la plage de charge de travail, RDMA a constamment maintenu des résultats compris entre 100 000 et 111 000 IOPS, tandis que TCP est resté généralement entre 40 000 et 50 000 IOPS, à l'exception d'une augmentation tardive à la profondeur maximale.

Latence d'écriture aléatoire de 16 K

Lors du test de latence d'écriture aléatoire de 16 K, le protocole RDMA a une fois de plus conservé un net avantage sur TCP à mesure que les charges de travail augmentaient. À faible charge, les deux protocoles étaient quasiment identiques, avec des temps de réponse inférieurs à 2 ms. Par exemple, pour la tâche QD1/1, TCP a enregistré 0.40 ms, contre 0.41 ms pour le protocole RDMA.

À mesure que la concurrence augmentait, le RDMA a commencé à se séparer. Pour les tâches QD16/64, le RDMA a enregistré 21.15 ms, tandis que TCP atteignait 77.12 ms, soit une réduction spectaculaire de 72 %. Cet avantage a persisté aux plus hautes profondeurs. Pour les tâches QD32/64, le RDMA a atteint 161.13 ms, contre 235.17 ms pour TCP, soit une amélioration de 31 %.

IOPS en lecture aléatoire 16K

Lors du test de lecture aléatoire de 16 000, RDMA a largement surpassé TCP sur l'ensemble des charges de travail. RDMA a atteint un pic de 388.44 000 IOPS, tandis que TCP a atteint seulement 16.42 000 IOPS, démontrant ainsi un avantage de plus de 23 fois pour RDMA.

La disparité était visible dès le début. Sur la tâche QD1/1, RDMA a fourni 29 270 IOPS, tandis que TCP n'en a géré que 8 100 IOPS. Avec l'augmentation de la concurrence, RDMA a rapidement atteint une plage de 300 000 à 380 000 IOPS, tandis que TCP a stagné autour de 15 000 à 16 000 IOPS, même avec des profondeurs de file d'attente plus importantes.

Latence de lecture aléatoire de 16 K

Lors du test de latence de lecture aléatoire de 16 K, la différence entre RDMA et TCP était considérable, reflétant les résultats d'IOPS. À faible charge de travail, les deux protocoles étaient quasiment identiques, avec des latences comprises entre 1 et 10 ms.

À mesure que les charges de travail évoluaient, le RDMA a bien maîtrisé la latence, tandis que le TCP se dégradait significativement. Pour les tâches Q8/64, le RDMA a atteint 13.65 ms, contre 260.90 ms pour TCP, soit une amélioration de près de 19 fois. Au final, les tâches QD32/64 ont terminé le RDMA en 63.28 ms, contre 2 366,99 ms pour TCP, soit près de 37 fois plus longtemps.

IOPS en écriture aléatoire 4K

Lors du test d'écriture aléatoire 4K, RDMA a constamment surpassé TCP, bien que la marge soit plus faible par rapport aux charges de travail de plus grande taille de bloc. RDMA a atteint un pic de 125.73 000 IOPS, tandis que TCP a atteint 115.89 000 IOPS, soit un avantage d'environ 8.5 % pour RDMA.

À des profondeurs de file d'attente plus faibles, TCP était légèrement en retrait par rapport à RDMA, mais offrait néanmoins des performances compétitives. Par exemple, pour les tâches QD1/16, RDMA a atteint 122.82 kIOPS, contre 111.91 kIOPS pour TCP, soit une amélioration de près de 10 %. Sur la plupart des points de test, RDMA a oscillé entre 120 kIOPS et 125 kIOPS, tandis que TCP a maintenu ses résultats entre 110 kIOPS et 116 kIOPS, avec une baisse tardive pour les tâches QD32/64, à 92.21 kIOPS.

Latence d'écriture aléatoire de 4 K

Lors du test de latence d'écriture aléatoire 4K, le protocole RDMA a systématiquement affiché des temps de réponse inférieurs à ceux du protocole TCP, bien que les marges soient plus faibles par rapport aux charges de travail par blocs plus importantes. À des charges plus faibles, les deux protocoles étaient quasiment identiques, chacun restant inférieur à 1 ms. Par exemple, au QD1/1, le protocole TCP a enregistré 0.16 ms, tandis que le protocole RDMA a atteint 0.21 ms.

À mesure que la concurrence augmentait, les différences sont devenues plus évidentes. Pour les tâches QD16/64, le RDMA a enregistré 19.36 ms, contre 36.20 ms pour TCP, ce qui représente une réduction de latence de 46 % pour le RDMA. À la profondeur maximale, le RDMA a atteint 145.61 ms, tandis que TCP a atteint 177.62 ms, soit une amélioration de 22 % pour le RDMA.

IOPS en lecture aléatoire 4K

Lors du test de lecture aléatoire 4K, les deux protocoles ont affiché d'excellentes performances, même si le RDMA a régulièrement conservé un léger avantage sur le TCP. Le RDMA a atteint un pic de 404.64 000 IOPS, tandis que le TCP a plafonné à 382.96 000 IOPS, ce qui confère au RDMA un avantage de 5.7 %.

À des profondeurs inférieures, les résultats étaient déjà en faveur de RDMA. Par exemple, pour les tâches QD1/16, RDMA a atteint 353 570 IOPS, contre 329 100 IOPS pour TCP, soit une différence d'environ 7.5 %. À mesure que les charges de travail augmentaient, RDMA a conservé son avance, fonctionnant généralement entre 360 000 et 400 000 IOPS, tandis que TCP restait plus proche de 330 000 à 380 000 IOPS.

Latence de lecture aléatoire de 4 K

Lors du test de latence de lecture aléatoire 4K, RDMA a démontré un net avantage en termes d'efficacité par rapport à TCP, notamment à mesure que les charges de travail augmentaient. Avec des profondeurs de file d'attente faibles, les deux protocoles étaient quasiment identiques. Par exemple, pour la tâche QD1/1, TCP a enregistré 0.24 ms, tandis que RDMA était juste derrière avec 0.27 ms.

Avec l'augmentation de la concurrence, le RDMA a pris le dessus. Pour les tâches QD16/64, le RDMA a enregistré un temps de 23.92 ms, tandis que le TCP a atteint 26.81 ms, soit une amélioration de 10.8 %. À la charge maximale des tâches QD32/64, le RDMA a atteint 54.61 ms, tandis que le TCP a atteint 70.12 ms, soit une réduction de 22 % de la latence pour le RDMA.

Performances de stockage GPUDirect

L'un des tests que nous avons menés sur ce banc d'essai était le test Magnum IO GPUDirect Storage (GDS). GDS est une fonctionnalité développée par NVIDIA qui permet aux GPU de contourner le CPU lors de l'accès aux données stockées sur des disques NVMe ou d'autres périphériques de stockage haute vitesse. Au lieu de faire transiter les données par le CPU et la mémoire système, GDS permet une communication directe entre le GPU et le périphérique de stockage, réduisant ainsi considérablement la latence et améliorant le débit.

Comment fonctionne le stockage GPUDirect

Traditionnellement, lorsqu'un GPU traite des données stockées sur un disque NVMe, celles-ci transitent d'abord par le processeur et la mémoire système avant d'atteindre le GPU. Ce processus crée des goulots d'étranglement, le processeur devenant un intermédiaire, augmentant la latence et consommant de précieuses ressources système. GPUDirect Storage élimine cette inefficacité en permettant au GPU d'accéder directement aux données depuis le périphérique de stockage via le bus PCIe. Ce chemin direct réduit la charge de travail associée au déplacement des données, permettant des transferts plus rapides et plus efficaces.

Les charges de travail d'IA, notamment celles impliquant l'apprentissage profond, sont très gourmandes en données. L'entraînement de grands réseaux neuronaux nécessite le traitement de téraoctets de données, et tout retard dans le transfert de données peut entraîner une sous-utilisation des GPU et des temps d'entraînement plus longs. GPUDirect Storage relève ce défi en garantissant que les données sont transmises au GPU le plus rapidement possible, minimisant ainsi les temps d'inactivité et maximisant l'efficacité de calcul.

En outre, GDS est particulièrement utile pour les charges de travail impliquant la diffusion de grands ensembles de données, comme le traitement vidéo, le traitement du langage naturel ou l'inférence en temps réel. En réduisant la dépendance au processeur, GDS accélère le déplacement des données et libère les ressources du processeur pour d'autres tâches, améliorant ainsi encore les performances globales du système.

Au-delà de la bande passante brute, GPUDirect avec NVMe-oF (TCP/RDMA) offre également des E/S à très faible latence. Ainsi, les GPU ne manquent jamais de données, ce qui en fait le système idéal pour l'inférence d'IA en temps réel, les pipelines d'analyse et la relecture vidéo.

Pour de nombreux déploiements pratiques, cela se traduit par un débit utilisable de 100 à 200 GbE, s'alignant parfaitement sur des charges de travail telles que l'inférence d'IA (2 à 4 GPU), la production multimédia (relecture de diffusion, mise en cache périphérique OTT), l'analyse de vidéosurveillance et le point de contrôle HPC.

Débit de lecture

Dans la charge de travail de lecture séquentielle GDSIO, le débit a évolué de manière constante avec la taille des blocs et le nombre de threads, atteignant un maximum de 11.0 Gio/s sur plusieurs points de test. Les meilleurs résultats ont été maintenus lorsque la taille des blocs a atteint 512 Ko et plus, où le débit s'est stabilisé entre 10.9 et 11.0 Gio/s, quel que soit le nombre de threads.

Avec des blocs de plus petite taille, les performances initiales étaient bien inférieures. Par exemple, avec des blocs de 4 Ko, le débit initial était de seulement 0.3 Gio/s avec un seul thread et se stabilisait à 1.5 Gio/s même avec 256 threads. En comparaison, l'augmentation de la taille des blocs à 64 Ko a permis au système d'atteindre 10.9 Gio/s, saturent quasiment le débit avec un nombre de threads plus élevé.

Le point idéal semblait se situer entre 128 000 et 256 000 blocs, où le débit dépassait 10 Gio/s avec 32 threads ou plus et restait constant pour les blocs les plus volumineux testés. Cela démontre comment la plateforme atteint une saturation complète de la bande passante une fois que les blocs deviennent suffisamment volumineux, avec des gains seulement progressifs au-delà de 256 000.

Lire la latence

Les résultats de latence de lecture séquentielle GDSIO ont montré que les temps de réponse évoluaient de manière prévisible en fonction de la taille des blocs et du nombre de threads. Aux charges de travail les plus faibles, la latence restait extrêmement faible. Par exemple, avec 4 000 blocs sur un seul thread, la latence n'était que de 50 µs, restant inférieure à 200 µs jusqu'à 32 000 blocs avec une concurrence minimale.

À mesure que le nombre de threads augmentait, la latence a commencé à augmenter sensiblement. À 64 000 blocs et 64 threads, la latence atteignait 1.5 ms, doublait à 2.9 ms à 128 threads et grimpait à 5.7 ms à 256 threads. En revanche, les blocs de plus petite taille, comme 4 000 et 8 000, n'atteignaient que 2.7 à 2.8 ms, même à 256 threads maximum, ce qui témoigne d'un contrôle plus strict à des granularités plus fines.

Des blocs de plus grande taille ont entraîné des sauts plus spectaculaires. À 1 million de blocs et 256 threads, la latence a atteint 96.1 ms, tandis qu'à 10 millions de blocs et 256 threads, elle atteignait 4.3 s, illustrant clairement les limites d'évolutivité du système dans des conditions extrêmes.

Débit d'écriture

Dans la charge de travail d'écriture séquentielle GDSIO, le débit a évolué avec la taille des blocs et le nombre de threads, mais a stagné bien en dessous du plafond de performance en lecture. Le système a atteint un pic de 7.2 Gio/s, avec des blocs de plus grande taille, tels que 5 et 10 Mo, à 128 threads.

Aux plus petites tailles de blocs, le débit était modeste. Avec des blocs de 4 K, les performances démarraient à 0.3 Gio/s avec un seul thread, puis atteignaient 1.0 Gio/s avec 32 threads, avant de stagner. L'augmentation de la taille de bloc à 64 K a libéré davantage de bande passante, atteignant 5.6 Gio/s avec huit threads, avant de diminuer légèrement à une concurrence plus élevée.

Le meilleur équilibre se situait entre 512 000 et 1 M de blocs, où le débit variait de 6.7 à 7.1 Gio/s selon le nombre de threads, indiquant que le système atteignait la saturation dans cette plage. Au-delà, l'ajout de threads n'apportait pas de gains significatifs et, dans certains cas, les performances baissaient légèrement en raison d'une surcharge accrue.

Latence d'écriture

Dans les résultats de latence d'écriture séquentielle GDSIO, les temps de réponse ont évolué en douceur à des tailles de blocs inférieures, mais ont fortement augmenté une fois que la taille des blocs et le nombre de threads ont augmenté.

Aux charges de travail les plus faibles, la latence était minimale. Avec 4 000 blocs et un seul thread, la latence moyenne n'était que de 58 µs, et restait inférieure à 200 µs jusqu'à 16 000 blocs et jusqu'à quatre threads. Même avec 32 000 blocs et une concurrence modérée, la latence restait inférieure à 1 ms.

À mesure que le système évoluait vers des blocs de plus grande taille, les retards se sont accentués. À 128 000 blocs et 64 threads, la latence atteignait 5.3 ms, puis doublait à 10.7 ms à 128 threads. Avec 512 000 blocs, les résultats s'allongeaient encore, atteignant 73.4 ms à 256 threads.

Les cas les plus lourds, des blocs de 5 M et 10 M à 256 threads, ont connu une augmentation spectaculaire de la latence à 709 ms et 4.8 secondes, respectivement, révélant les limites supérieures de la mise à l'échelle de l'écriture séquentielle.

Réflexions finales

Le XN4226D de QSAN répond parfaitement aux besoins de nombreuses équipes informatiques. Il s'agit d'une plateforme NVMe unifiée à double contrôleur, compatible avec les protocoles modernes et traditionnels, sans nécessiter de modifications architecturales. Lors de nos tests, TCP a dominé les lectures séquentielles volumineuses à 21.21 Go/s, tandis que RDMA a produit les écritures séquentielles volumineuses les plus performantes à 11.14 Go/s, tout en maintenant une latence plus faible à mesure que la concurrence augmentait. Avec des tailles de blocs plus petites, RDMA a constamment amélioré l'efficacité des écritures aléatoires et maîtrisé le comportement de queue. Le constat est simple : utilisez NVMe-oF TCP pour une compatibilité étendue et une bande passante de lecture élevée, et optez pour RDMA lorsque la latence et la cohérence en écriture sont primordiales.

L'encombrement matériel est pratique. Vous disposez de 26 baies frontales pour disques NVMe U.2 ou U.3 dans un châssis 2U, avec une haute disponibilité active et une extension simple vers des baies SAS lorsque la capacité prime sur la vitesse NVMe brute. QSM 4 offre les services de données attendus et une interface utilisateur claire, ainsi qu'une API REST qui facilite l'intégration transparente avec les systèmes d'automatisation existants. Les petites équipes informatiques devraient trouver QSM 4 facile à configurer et à gérer. Pour le confirmer, nous avons facilement intégré notre cluster Proxmox, offrant ainsi à ces machines virtuelles un accès à un stockage haut débit. Pour les charges de travail plus avancées, QSAN est parfaitement adapté aux besoins d'IA des PME.

Pour les entreprises qui privilégient des performances prévisibles, une gestion claire et une portée multiprotocole, le XN4226D est une recommandation évidente. Il offre un débit NVMe réel, une latence d'écriture élevée avec RDMA et une expérience logicielle sans ralentissement. Ajoutez à cela un prix raisonnable, et cette plateforme QSAN peut ancrer les environnements mixtes sans problème.

Page produit QSAN