Pourquoi la norme RoCE s’est d’abord imposée dans le stockage NVMe-oF
Parmi les déclinaisons du protocole NVMe-over-Fabrics pour relier les serveurs à des baies SAN Flash, la variante NVMe-over-RoCE, basée sur les réseaux Ethernet, a le mérite de coûter moins cher et d’être routable.
Il existe plusieurs connectiques possibles pour déployer une solution de stockage en NVMe-over-Fabrics. Alors que les professionnels aguerris au Fiber Channel s’attendaient à voir le NVMe-over-FC s’imposer rapidement, la première déclinaison à avoir été déployée – et donc aujourd’hui la plus courante – est le NVMe-over-RoCE. Cette version repose sur un réseau Ethernet, mais elle en élimine la lenteur en utilisant dans son protocole du RDMA (Remote Direct Memory Access), lequel contourne l’habituelle étape d’encodage des informations en paquets TCP par le système d’exploitation des serveurs, ce qui coûte beaucoup de temps de calcul à leur processeur.
L’intérêt du NVMe-over-RoCE est qu’il se contente de cartes réseau 10 Gbits/s pour fonctionner, que celles-ci sont largement répandues, qu’elles s’accompagnent de switches Ethernet qui coûtent peu chers et qu’elles sont pratiquement toutes compatibles RDMA (elles portent dans ce cas la mention RNIC). De plus, depuis la version 2 de RoCE, les commandes NVMe sont routables, ce qui signifie que des serveurs qui communiquent avec leurs baies de disques en NVMe-over-RoCEv2 n’ont pas besoin de liens dédiés ; ils peuvent passer par les mêmes switches qui interconnectent le reste du réseau.
Les fournisseurs de baies de stockage compatibles NVMe-over-RoCE comprennent Pure Storage, IBM, Quantum, Micron (solutions SolidScale), Dell EMC (gamme DSSD), Pavillon Data Systems, Vexata, ou encore Apeiron Data Systems. Le plus grand sponsor de ce protocole est certainement le fabricant de cartes contrôleur Mellanox, mais son concurrent Broadcom dispose aussi de nombreuses solutions. Notons qu’il existe par ailleurs un pilote Linux, Soft-RoCE, qui permet d’utiliser le protocole avec n’importe quel chip Ethernet, y compris les chipsets disponibles sur les cartes mères des serveurs.
Envoyer des commandes NVMe et non SCSI, sans passer par TCP
Jusqu’ici, les réseaux Ethernet ont été utilisés en stockage pour communiquer via le protocole iSCSI avec les baies de disques, c’est-à-dire en empaquetant au niveau de l’OS des commandes SCSI dans des paquets TCP/IP véhiculés sur des infrastructures Ethernet peu chères.
En NVMe-over-Fabrics, l’idée est de remplacer les commandes SCSI, conçues pour des disques durs mécaniques qui lisent des blocs les uns derrière les autres, par des commandes NVMe, à savoir des lectures/écritures mémoire appliquées en parallèle à plusieurs zones des unités Flash. La communication au protocole NVMe est beaucoup plus rapide qu’en SCSI. Mais ce gain de vitesse ne doit pas non plus être perdu par un empaquetage des commandes en TCP au niveau du processeur des serveurs. D’où l’intérêt d’utiliser le RDMA.
Précisons que la question du RDMA ne se pose pas en NVMe-over-FC, puisque, en Fiber Channel, le processeur envoie des commandes SCSI à la carte contrôleur FC, laquelle se charge de mettre elle-même les données dans des paquets FC. Le NVMe-over-FC revient donc simplement à envoyer des commandes NVMe plutôt que SCSI à la carte contrôleur.
La douloureuse nécessité de configurer les switches pour éviter la perte de paquets
L’acronyme RoCE – qui se prononce « Rocky » - signifie plus exactement RDMA over Converged Ethernet. Le Converged Ethernet est une déclinaison du protocole Datacenter Bridging (DCB), lequel avait été conçu initialement pour faire transiter des paquets Fiber Channel sur réseau Ethernet (FC-over-Ethernet), dans le but de réduire les coûts de la connectique. L’apport technique du DCB est qu’il élimine la perte de paquets, une situation dont se jouent les réseaux Ethernet mais qui impactent l’efficacité d’une communication en Fiber Channel.
DCB nécessitait que l’administrateur réseau configure plusieurs paramètres sur chacun des ports des switches Ethernet, afin d’obtenir les performances escomptées. Dans le cas contraire, utiliser du FC-over-Ethernet s’avérait contre-productif. En pratique, dans les grandes entreprises, cette opération de configuration nécessite souvent des délais d’intervention incompressibles. De fait, les administrateurs systèmes ont jusqu’ici préféré déployer leurs nouveaux serveurs en utilisant du iSCSI, c’est-à-dire sans profiter du gain de vitesse que leur aurait offert DCB avec du FC-over-Ethernet.
RoCE, de son côté, n’a théoriquement pas besoin de configuration spéciale pour fonctionner. C’est en tout cas vrai lorsque tous les appareils connectés aux switches fonctionnent en RoCE. Cependant, les utilisateurs ne vont pas nécessairement déployer un réseau physique à part uniquement pour les quelques serveurs parmi leur cluster qui communiqueront en NVMe-over-RoCE avec une baie de stockage. Les fournisseurs de solutions de stockage compatibles recommandent donc d’activer sur les switches et les cartes réseau des serveurs les modes Priority Flow Control (PFC) et Explicit Congestion Notification (ECN), afin de garantir que la perte de paquets sera évitée.
Ces configurations ne sont pas triviales, même pour les administrateurs système. La plupart des cartes réseau utilisées jusqu’ici pour communiquer avec des baies de stockage en iSCSI comportent d’ailleurs, elles aussi, des options d’optimisation, mais, à notre connaissance, aucun administrateur ne s’est donné la peine de les activer.
