VMware a récemment ajouté NVMe sur structure (NVMe-oF) en tant qu'option de protocole de réseau de stockage dans vSphere 7.0. Le fait que la solution de stockage partagé la plus rapide puisse désormais être utilisée par le logiciel de virtualisation le plus populaire au monde change la donne, ouvrant un tout nouvel ensemble de cas d'utilisation pour un centre de données virtualisé. Cela signifie également qu'il existe désormais des applications bare metal capables de s'exécuter sur des machines virtuelles (VM) compatibles NVMe-oF sur vSphere. Il s'agit notamment de l'intelligence artificielle (IA), de l'apprentissage automatique (ML), des bases de données en mémoire, du calcul haute performance (HPC), du trading haute fréquence (HFT), du traitement des transactions en ligne (OLTP), ainsi que de toute autre application nécessitant latence extrêmement faible et stockage de grande capacité.
VMware a récemment ajouté NVMe sur structure (NVMe-oF) en tant qu'option de protocole de réseau de stockage dans vSphere 7.0. Le fait que la solution de stockage partagé la plus rapide puisse désormais être utilisée par le logiciel de virtualisation le plus populaire au monde change la donne, ouvrant un tout nouvel ensemble de cas d'utilisation pour un centre de données virtualisé. Cela signifie également qu'il existe désormais des applications bare metal capables de s'exécuter sur des machines virtuelles (VM) compatibles NVMe-oF sur vSphere. Il s'agit notamment de l'intelligence artificielle (IA), de l'apprentissage automatique (ML), des bases de données en mémoire, du calcul haute performance (HPC), du trading haute fréquence (HFT), du traitement des transactions en ligne (OLTP), ainsi que de toute autre application nécessitant latence extrêmement faible et stockage de grande capacité.
Chez StorageReview.com, nous sommes toujours intéressés à tester les dernières technologies pour voir comment elles fonctionnent dans le monde réel. Compte tenu de notre expérience précédente avec NVMe-oF, nous nous attendons à ce qu'il améliore considérablement les performances des applications pour vSphere. Pour avoir une idée réelle de la façon dont NVMe-oF affectera les performances, nous le comparerons à iSCSI, qui est le support standard actuel pour le stockage de blocs dans un centre de données vSphere. Mais nos tests auront une tournure unique, car nous n'utiliserons pas de technologie de niche hautement spécialisée. Au lieu de cela, nous utiliserons des produits couramment trouvés dans le centre de données aujourd'hui. Nos tests seront effectués sur un serveur Dell R720XD connecté par les adaptateurs à double port ConnectX-5 de NVIDIA fonctionnant à 25 GbE à un Stockage pur FlashArray//X qui prend en charge NVMe-oF.
Avant d'arriver aux résultats de nos tests, nous allons d'abord vous donner un aperçu de ce que VMware prend en charge en matière de NVMe-oF, puis vous donner un petit aperçu de NVMe et NVMe-oF et vous expliquer pourquoi ils sont plus performants que iSCSI. Nous couvrirons également certaines des étapes que nous avons suivies pour configurer NVMe sur vSphere.
VMware a récemment activé la prise en charge de NVMe-oF (avril 2020), bien que la norme NVMe-oF ait été publiée en 2016. Linux est capable de l'utiliser depuis 2018, et la prise en charge de NVMe-oF dans les baies de stockage est également disponible depuis quelques années. . NVMe-oF est considéré comme une technologie émergente, mais stable. En avril 2020, VMware a publié vSphere 7.0 et cette version incluait la prise en charge de NVMe-oF, permettant la connectivité aux baies NVMe avec NVMe sur Fibre Channel (NVMe/FC) ou NVMe sur RDMA Converged Ethernet (NVMe-RoCE, également appelé NVMe/RDMA).
Présentation de NVMe et NVMe-oF
Jusqu'à récemment, les SSD étaient les de facto support standard pour le stockage attaché. Cependant, ils ont également un goulot d'étranglement critique. Les SSD utilisent des connecteurs SATA ou SAS, qui ont été conçus pour être utilisés avec des disques durs, ce qui limite considérablement les performances d'un SSD. Pour résoudre ce problème, un consortium de plus de 90 entreprises s'est regroupé en 2011 et a publié une nouvelle spécification pour connecter les SSD aux ordinateurs qui n'auraient pas ce goulot d'étranglement SATA. Cette solution est finalement devenue connue sous le nom de NVMe.
Les appareils NVMe sont rapides. Alors que les SSD SATA/SAS ont radicalement changé l'industrie du stockage au cours de la dernière décennie, NVMe change radicalement l'industrie du stockage ce siècle. Par exemple, lors de nos récents tests utilisant une charge de travail de lecture 4K, nous avons constaté qu'un disque SATA (Kingston DC500M) pouvait fournir un peu moins de 80,000 1000 IOPS, mais qu'un disque NVMe (Kingston DC580,000M) pouvait fournir 7.25 XNUMX IOPS, soit une énorme différence de XNUMX fois. Il existe de nombreuses raisons techniques pour expliquer pourquoi NVMe est tellement plus performant que les disques SATA, mais l'une des plus importantes est qu'il a un chemin de données plus court. Le diagramme ci-dessous montre une illustration simplifiée de la façon dont le chemin des données est considérablement plus court pour NVMe par rapport au stockage de dernière génération comme SAS.
Ses améliorations de performances, associées à la chute vertigineuse des prix, ont fait de NVMe la coqueluche du data center moderne.
Peu de temps après que les disques NVMe soient devenus largement utilisés dans le centre de données, les gens ont réalisé que les appareils n'étaient pas utilisés à leur plein potentiel, et leur limitation d'être un stockage en attachement direct est devenue plus apparente. Les périphériques NVMe devaient être découplés du serveur, c'est pourquoi un autre groupe d'entreprises s'est réuni et a développé une spécification sur la manière de fournir NVMe sur un réseau. Une fois que le mécanisme de transport pour le stockage NVMe était disponible, nous pouvions agréger, résumer et partager les périphériques NVMe dans un système de stockage sur de nombreux systèmes différents, y compris les hôtes ESXi. NVMe-oF utilise la terminologie cible/initiateur.
RoCE permet l'accès direct à la mémoire à distance (RDMA) sur un réseau Ethernet. Il existe deux versions de RoCE : RoCE v1 et RoCE v2. Alors que RoCE v1 permet la communication entre deux hôtes quelconques dans le même domaine de diffusion Ethernet (couche 2), RoCE v2 s'exécute au-dessus de TCP (couche 3) et est donc routable, ce qui lui permet de se connecter à des hôtes en dehors d'un domaine de diffusion Ethernet. En raison de ses avantages inhérents et de sa popularité dans le centre de données, VMware ne prend en charge que v2. Pendant la durée de cet article, nous ferons référence à RoCE v2 simplement comme RoCE.
RoCE nécessite des contrôleurs d'interface réseau RDMA (rNIC) au lieu des cartes réseau standard. Les réseaux RoCE nécessitent généralement la configuration du contrôle de flux prioritaire, mais les commutateurs Spectrum sont optimisés pour le contrôle de la congestion lorsqu'ils sont utilisés avec des adaptateurs ConnectX, ce qui permet une configuration nulle. RoCE est très populaire et possède un écosystème florissant qui fournit à la fois des sous-systèmes rNIC et NVMe-oF. Il est actuellement utilisé par certains des plus grands centres de données hyperscale au monde, ce qui a fait baisser considérablement le prix des rNIC depuis leur introduction.
En utilisant RDMA, les données peuvent être transférées directement vers un hôte à partir des périphériques NVMe-oF sans avoir à être copiées dans des mémoires tampons, comme ce serait le cas si vous utilisiez une pile TCP/IP standard. En contournant les tampons, RDMA réduit l'utilisation du processeur sur l'hôte et diminue la latence pour accéder aux données sur le périphérique NVMe distant. Il existe de nombreuses raisons techniques pour lesquelles NVMe-oF est plus performant que les technologies de stockage réseau de dernière génération. Il convient de noter le nombre massif de files d'attente (64K) prises en charge par NVMe-oF, mais le plus révélateur est peut-être le chemin de données NVMe-oF. Le diagramme ci-dessous montre une illustration simplifiée de la façon dont le chemin de données est considérablement plus court pour NVMe-oF par rapport au stockage iSCSI.
RoCE utilise UDP, ce qui a un impact sur les performances car UDP nécessite moins de surcharge. Cependant, RoCE s'appuie sur la compatibilité de bout en bout pour fournir une connectivité complète sans perte. Bien que les commutateurs réseau modernes prennent en charge la connectivité sans perte, il faut veiller à ce qu'un commutateur plus ancien qui ne prend pas en charge la connectivité sans perte ne se trouve pas dans le chemin réseau de NVMe-oF.
Le résultat de tout cela est que NVMe-oF permet d'accéder aux disques NVMe d'un réseau comme s'ils étaient locaux sur le serveur d'accès. Les premiers rapports ont montré que la latence pour le stockage en pool est d'environ 100 μs, au lieu des 500 μs ou plus d'une baie de stockage iSCSI XNUMX % Flash.
NVMe-oF avec vSphere
Les exigences pour NVMe-oF avec vSphere sont simples :
- Baie NVMe prenant en charge le transport RDMA (RoCE)
- Hôte ESXi compatible
- Commutateurs Ethernet prenant en charge un réseau sans perte
- Adaptateur réseau prenant en charge RoCE
- Adaptateur logiciel NVMe sur RDMA
- Contrôleur NVMe
- Un réseau sans perte au niveau de la couche 2 et de la couche 3 ou un réseau avec perte avec la solution ZTR (Zero Touch RoCE) de NVIDIA
- Liens dédiés, VMkernels et adaptateurs RDMA vers les cibles NVMe
- VLAN de couche 3 dédié ou connectivité de couche 2
Étant donné que NVMe-oF est nouveau pour VMware, toutes les fonctionnalités de vSphere ne sont pas disponibles pour lui. Quelques fonctionnalités manquantes sont la prise en charge des VMDK partagés, des Raw Device Maps (RDM), des vVols et de la possibilité de démarrer à partir de NVMe-oF.
Implémentation de NVMe-oF
Nous avons utilisé les rNIC ConnectX-5 de NVIDIA, l'une des cartes les plus courantes dans le centre de données. Ces cartes sont des adaptateurs réseau à un ou deux ports compatibles RDMA. Ils sont disponibles pour les serveurs PCIe Gen 3.0 et Gen 4.0 et prennent en charge 1, 10, 25, 40, 50 et 100 Go. Ils ont une latence de 750ns et peuvent transmettre jusqu'à 200 millions de messages par seconde. Lorsqu'ils sont utilisés avec des charges de travail de stockage, ils prennent en charge un large éventail de technologies d'accélération.
Pour nos tests, nous avons exécuté des cartes PCIe Gen 3.0 ConnectX-5 à 25 GbE dans une paire de serveurs Dell R720 sur un réseau connecté via une paire de commutateurs Spectrum SN2010 de NVIDIA à la baie flash Pure Storage.
Nous avons d'abord vérifié que nous exécutions le pilote nmlx5_core en entrant esxcfg-nics -l |grep -E 'Nom|NVIDIA'.
Si nous exécutions le pilote nmlx4_core, nous aurions pu activer RoCE à partir de la CLI ESXi.
Le processus d'activation de NVMe-oF (similaire à celui de configuration et d'activation d'iSCSI) impliquait la configuration des vSwitches, des groupes de ports et des ports vmkernel sur les hôtes ESXi. La principale différence était que nous devions ajouter au moins deux adaptateurs logiciels NVMe sur RDMA à chaque hôte ESXi.
La dernière étape que nous devions terminer consistait à identifier le nom qualifié NVMe (NQN) de l'hôte ESXi en saisissant obtenir les informations esxcli nvme.
Sur la baie Pure Storage, cela ressemblait à la configuration d'une baie iSCSI, à une grande exception près. Nous devions sélectionner Configurer les NQN.
Résultats des tests de NVMe-oF avec vSphere
Pour ce test, nous avons gardé toutes choses constantes à l'exception du tissu. Ce que nous voulons évaluer, c'est l'impact du passage d'iSCSI plus traditionnel à RoCE. Pour être clair, il ne s'agit pas d'un exercice d'analyse comparative du stockage ; il s'agit d'un examen visant à examiner les avantages de NVMe-oF dans un environnement VMware nécessitant très peu de modifications. Nous avons utilisé deux serveurs Dell EMC PowerEdge ainsi qu'un Pure FlashArray//X R2 pour le backend de stockage.
Notre plan de test comprenait la mesure des performances globales de 8 machines virtuelles (4 sur chaque hôte ESXi) et l'utilisation de vdBench pour mesurer les quatre coins traditionnels et les charges de travail mixtes. Chaque machine virtuelle consommait 64 Go de stockage, avec une empreinte totale de 512 Go par charge de travail disponible pour comparer les changements de performances à mesure que le protocole changeait.
Pour interpréter ces résultats, sachez que pour le débit, une amélioration est meilleure, tandis qu'en latence, une diminution est préférable.
Dans notre première charge de travail mesurant les performances de lecture aléatoire 4K à 80 % de charge, nous avons mesuré une augmentation du débit de 14.6 % et une baisse de la latence de lecture de 21.4 %.
Ensuite, en examinant la bande passante de lecture dans une charge de travail de lecture séquentielle de 64 Ko, nous avons constaté une augmentation considérable du débit de 81.3 %, ainsi qu'une diminution de 36.8 % de la latence, à nouveau à 80 % de charge.
Alors que les gains les plus importants mesurés concernaient les charges de travail de lecture, nous avons également examiné certaines charges de travail mixtes courantes, dont la première était SQL 90/10. Dans cette charge de travail, nous avons mesuré une diminution de la latence jusqu'à 78.2 % à une charge de 100 % et une baisse de 43.4 % de la latence à une charge de 80 %.
Enfin, dans notre charge de travail Oracle 90/10, nous avons constaté une baisse de 13.2 % de la latence à une charge de 100 % et une baisse de 35.7 % de la latence à une charge de 80 %.
Lors de ces tests, il est clair que RoCE a enregistré de grandes améliorations sur un large éventail de charges de travail courantes dans l'entreprise.
Pour aller plus loin
Nos tests ont prouvé que NVMe-oF dans le monde réel est plus qu'un simple concept. NVMe-oF peut offrir des performances exceptionnelles en utilisant le matériel actuel de votre centre de données, comme les serveurs avec des emplacements PCI Gen 3.0, les cartes réseau ConnectX-5 de NVIDIA et un Pure Storage FlashArray//X R2 (Pure est maintenant livré //X R3 avec encore plus Amélioration des performances).
Lors de nos tests, nous avons constaté des gains significatifs dans les charges de travail de lecture de petits et grands blocs. Pour examiner l'impact dans le monde réel, nous nous sommes concentrés sur une saturation de la charge de travail inférieure à 100 %, car la plupart des charges de travail ne saturent pas complètement la plate-forme de stockage sous-jacente. Dans notre test mesurant les performances de lecture aléatoire 4K, la latence a chuté de 21.4 % avec une charge de travail de 80 %. Les performances de lecture séquentielle avec une charge de travail de 64 81.3 ont vu une énorme augmentation de 80 % du débit à une charge de 43.4 %. Nous avons également constaté des baisses de latence de 35.7 % et 90 % dans nos charges de travail SQL 10/90 et Oracle 10/80, respectivement, à nouveau à une charge de XNUMX %. Ces chiffres indiquent qu'il existe une opportunité supplémentaire de transférer des charges de travail bare metal exigeantes vers VMware.
Nous sommes convaincus que NVMe-oF sera la prochaine grande technologie de stockage, et nous nous attendons à ce que sa popularité dans le centre de données prolifère rapidement. Nous serons à l'avant-garde de cette catégorie au fur et à mesure de son développement au cours des prochaines années, et nous sommes impatients d'étudier d'autres technologies NVMe adjacentes au fur et à mesure de leur sortie.
Pour plus d'informations:
Ce rapport est sponsorisé par NVIDIA. Tous les points de vue et opinions exprimés dans ce rapport sont basés sur notre vision impartiale du ou des produits à l'étude.
