basiczto - Fotolia
Stockage SAN : pourquoi NVMe-over-Fabrics sur IP est un bon choix
Qu’il s’agisse de la version NVMe/TCP ou NVMe/RoCE, ces connectiques réseau ont à présent suffisamment évolué pour s’imposer en alternative au Fiber Channel, en termes de coût, d’administration et de performances.
Qu’on se le dise : la connectique SAN NVMe/TCP est adaptée à tous les types de projets en stockage bloc, que l’enjeu soit de limiter les coûts ou d’obtenir de bonnes performances. La richesse de ses options, garante de coûts flexibles, associée à une prise en charge désormais complète de la sécurité, ainsi qu’à des services de découverte automatisés et de zonage, font à présent de NVMe/TCP une plate-forme SAN complète. Son point faible pourrait être la latence. Si les besoins en la matière sont critiques, on optera pour sa variante, la connectique NVMe/RoCE, plus chère.
Pour autant, NVMe/TCP et NVMe/RoCE doivent encore convaincre des entreprises habituées à la connectique Fibre Channel (FC). FC est le réseau physique historique que l’on utilise lorsque l’on déploie une baie SAN, y compris quand celle-ci est compatible avec le protocole moderne NVMe-over-Fabrics. NVMe-over-Fabrics signifie littéralement faire transiter des commandes NVMe sur le réseau qui relie des serveurs à une baie de stockage ; les commandes NVMe sont plus adaptées aux SSD que les anciennes commandes SCSI qui étaient conçues pour les disques durs mécaniques.
Ethernet moins cher que Fiber Channel
Le succès du FC est principalement dû à la richesse de ses services. Ceux-ci simplifient la provision de ressources et apportent un haut degré d’automatisation. Plus particulièrement appréciés, les services FC Zone Server et FC Name Server fournissent respectivement un contrôle d’accès et une fonction de découverte.
Grâce au contrôle d’accès, l’administrateur du SAN peut définir quels points d’extrémité (les N_Ports) sont autorisés à communiquer. Grâce à la fonction de découverte, les N_Ports connaissent automatiquement l’adresse et les propriétés des autres N_Ports avec lesquels ils vont communiquer. Ces services sont fournis par le réseau FC ; l’administrateur n’a même pas besoin d’accéder à chaque point d’extrémité ni de provisionner manuellement leurs ressources. Pour les administrateurs, ils sont une facilité.
Revers de la médaille, Fibre Channel est coûteux à déployer, au point que certaines entreprises s’empêchent d’utiliser un SAN et optent pour des options moins flexibles, comme les tiroirs de disques directement attachés aux serveurs.
C’est pour répondre à cette problématique de coût que de nombreux acteurs du stockage proposent une alternative au réseau Fiber Channel : le réseau Ethernet. Son écosystème de développeurs et de fabricants est fourni, ses switches sont bien plus répandus, son amortissement est plus clair. En somme, Ethernet ne pose aucun problème. Reste à pouvoir l’utiliser pour transporter des commandes de stockage NVMe entre des serveurs et une baie de disques SAN.
NVMe/RoCE et NVMe/TCP
Il existe deux solutions pour transporter des flux NVMe sur un réseau Ethernet :
- NVMe/RDMA over Converged Ethernet (RoCE), qui utilise un routage sans perte pour assurer un transport rapide des commandes de lecture/écriture en mémoire vers l’unité de destination.
- NVMe/TCP, qui utilise l’omniprésent protocole TCP.
Le RoCE nécessite le déploiement de cartes et des switches Ethernet spéciaux. À l’instar d’un protocole quasiment jamais utilisé, le FC/Ethernet, cette technologie réseau est difficile à mettre en place. Par conséquent, l’utilisation de NVMe/RoCE s’est jusque-là limitée à des déploiements haut de gamme en entreprise, c’est-à-dire coûteux, mais de petite taille, ou à plus grande échelle chez des géants du cloud, lesquels sont prêts à investir fortement quand la latence la plus faible possible a une importance économique considérable.
NVMe/TCP, en revanche, peut être utilisé à toutes les échelles, même dans une succursale, à partir d’un réseau standard. La flexibilité du protocole TCP fait du NVMe/TCP le réseau de choix pour une adoption et un déploiement à grande échelle de baies SAN NVMe-over-Fabrics.
Jusqu’à récemment, tant NVMe/RoCE que NVMe/TCP souffraient de l’absence des services de découverte et d’automatisation du provisionnement dont on profite en Fibre Channel. Cela compliquait le travail des administrateurs des serveurs et ceux du stockage, car les étapes de configuration des points d’extrémité étaient nombreuses. De fait, quand bien même un SAN était déployé en NVMe/TCP, son extension au fil du temps était rare.
CDC, le module qui rend NVMe/TCP compétitif
Pour remédier à ce problème, le groupe de travail Fabrics and Multi-Domain Subsystem, du consortium NVMe Express, a implanté deux techniques, connues sous les noms de projets TP8009 et TP8010. Ces ajouts à l’architecture NVMe apportent un dispositif, le Centralized Discovery Controller (CDC), qui s’occupe de définir toute nouvelle entité NVMe sur le réseau.
Le CDC est accessible via une ou plusieurs adresses IP depuis de tous les serveurs et baies de stockage NVMe/TCP présents sur le réseau. Chacun découvre la ou les adresses IP du CDC par le biais d’un DNS Multicast.
La première connexion TCP sert aux serveurs et aux baies de disques à s’enregistrer auprès du CDC et à découvrir les ressources accessibles. Le projet TP 8010 définit un modèle de zonage complet pour le CDC, ce qui permet à un administrateur de SAN de spécifier des règles de contrôle d’accès sur le réseau SAN. En d’autres termes, le CDC met en route des services centralisés équivalents aux services d’un réseau Fibre Channel et comble l’une des lacunes les plus importantes des connectiques NVMe-over-Fabrics.
Un administrateur peut déployer un CDC comme un processus sur un serveur central ou distribuer sa fonction sur les switches d’un réseau Ethernet. Dans les deux cas, plusieurs options de redondance sont possibles. Comme le CDC est accessible par son adresse IP, il peut se cantonner à un seul sous-réseau ou englober plusieurs réseaux. En théorie, il peut être situé n’importe où sur Internet.
L’architecture NVMe a par ailleurs été améliorée sur le plan de la sécurité. À présent, elle utilise le protocole d’authentification Diffie-Hellman-Hash-Challenge-Handshake, ou DH-HMAC-CHAP (TP 8006), sur un canal sécurisé défini dans le projet technique TP 8011. Celui-ci décrit comment utiliser le protocole TLS 1.3 (Transport Layer Security) pour sécuriser les connexions NVMe/TCP.
Cette architecture de sécurité va de l’établissement d’une session TLS jusqu’à l’achèvement d’une transaction DH-HMAC-CHAP, en prépartageant la clé de session DH-HMAC-CHAP pour établir la session TLS, ce qui évite un provisionnement de sécurité séparé.
On notera que le réseau Fibre Channel dispose en option de fonctions de sécurité similaires, dans son module FC-SP-2 (FC Security Protocols 2). Cela dit FC-SP-2 est rarement mis en place, car les matrices Fibre Channel sont déployées comme des réseaux isolés, étanches, ce qui donne l’impression qu’ils sont particulièrement bien sécurisés. Une impression toutefois discutable puisqu’il est toujours possible de prendre le contrôle des baies de disques en attaquant le réseau qui transporte leurs commandes d’administration.
Sur un réseau IP, en revanche, les protocoles de sécurité ne sont pas un luxe. Les clients s’attendent même à ce qu’ils soient présents et l’exigent pour fonctionner correctement. Cela implique donc que l’administrateur du stockage ne peut pas ici faire l’économie de leur déploiement et de leur administration.
Plusieurs niveaux de performances
Étant donné la nature optimisée des commandes NVMe, il est raisonnable de se demander quel est l’impact de ces extensions sur les performances. La découverte centralisée est un protocole de contrôle ; elle n’a donc aucun impact sur le taux de transfert des données ou sur la latence. L’authentification DH-HMAC-CHAP est également un protocole de contrôle et a un impact négligeable sur le débit et la latence.
On ne peut pas en dire autant du trafic lié au stockage sur un canal sécurisé TLS. En effet, chaque segment TCP – et donc chaque transfert de stockage – doit être chiffré ou déchiffré. Ces opérations de sécurité nécessitent une puissance de traitement importante. La bonne nouvelle est que la quantité de traitements qu’un serveur ou qu’une baie de disques doit effectuer pour prendre en charge TLS, dépend de toute façon de la puissance de son matériel.
De nombreuses plates-formes sont disponibles avec différents niveaux de performances, à différents coûts. En entrée de gamme, les solutions NVMe/TCP uniquement logicielles peuvent servir à bâtir un SAN NVMe/TCP à un coût pratiquement nul, en utilisant les interfaces Ethernet disponibles sur les différents équipements.
En milieu de gamme, une carte réseau qui dispose d’une accélération matérielle pour les fonctions de sécurité permet d’absorber l’impact des performances de TLS, pour un coût modéré.
En haut de gamme, des cartes réseau intelligentes, alias SmartNIC, déchargent complètement le serveur des traitements NVMe-oF, TCP et TLS. Un serveur doté d’une SmartNIC a des performances maximales, au point que le stockage auquel il accède en réseau passe pour une unité de stockage interne. Bien entendu, cette option est la plus chère.
À propos de l’auteur :
Claudio DeSanti est membre de la Storage Networking Industry Assocation (SNIA) et ingénieur au sein du groupe CTIO Integrated Solutions and Ecosystem de Dell Technologies, spécialisé dans les configurations NVMe-oF et Edge computing.
La SNIA est une organisation mondiale à but non lucratif, composée d’entreprises membres couvrant le marché du stockage. En tant qu’autorité neutre dans le domaine, elle a pour mission de donner une orientation à l’industrie du stockage en développant et en promouvant des architectures, des normes et des services de formation indépendants des fournisseurs.