Les Brocade, McDATA et autres apôtres des réseaux dédiés au stockage en étaient sûrs : à l’avenir, le Fibre Channel constituerait le fédérateur des serveurs de l’entreprise et de ses ressources de stockage. C’était sans compter avec la prédisposition du protocole IP à absorber tous les flux d’information, les uns après les autres, qu’ils soient informatiques, téléphoniques, télévisés… Et, c’était aussi oublier la capacité de ce protocole à “tailler la route” sur tous les réseaux de transport (ATM, Ethernet, Frame Relay et liaisons louées).À présent, c’est au tour des informations échangées lors de l’accès aux disques et aux bandes magnétiques d’y être intégrées. Afin de mener cette tâche à bien, IP s’étoffe de deux technologies ad hoc : SCSI sur IP (iSCSI) et Fibre Channel sur IP (FCIP). Il en résulte tantôt des économies, grâce à l’utilisation d’infrastructures IP existantes, tantôt la constitution de tuyaux dédiés au stockage, sans qu’il soit nécessaire de maîtriser des compétences nouvelles.
Le SCSI sur IP ou le SAN sans Fibre Channel
Le protocole iSCSI est des plus prometteurs. Il s’agit d’utiliser un réseau IP pour transporter le protocole SCSI entre un serveur et un sous-système de stockage distant, ou entre un serveur et une passerelle reliant le réseau IP à un SAN basé sur Fibre Channel. Dans le premier cas, l’objectif est de construire des SAN basés sur une infrastructure Ethernet fédératrice. Dans le second, on cherche à étendre la portée du SAN à des systèmes qui n’y sont pas directement reliés.Cependant, la mise à profit des réseaux IP existants a ses limites. L’iSCSI pourrait, en effet, les engorger, surtout s’il est sollicité pour effectuer des sauvegardes. En fin de compte, ce nouveau protocole devrait, bien souvent, imposer le déploiement de réseaux fédérateurs en Gigabit Ethernet dédiés au stockage.L’encapsulation des commandes SCSI dans IP, que sous-tend l’iSCSI, et son corollaire, la désencapsulation, doivent être réalisées sur chaque n?”ud iSCSI, qu’il s’agisse d’un serveur, d’un sous-système de stockage ?” telles une baie Raid ou une bibliothèque de bandes ?” ou d’une passerelle entre le monde IP et celui du Fibre Channel. Sur le serveur ?” on parle ici d’initiateur SCSI ?”, ces opérations sont confiées à un pilote spécialisé, qui se substitue à l’habituel pilote SCSI et s’interface avec des applications telles que le système de fichiers ou les bases de données. Actuellement, ce pilote prend généralement le contrôle d’une carte Ethernet traditionnelle. C’est le cas dans la solution IP Storage 200i, d’IBM, livrée avec des pilotes pour Windows NT, Windows 2000, AIX et Linux. Côté sous-système de stockage ou passerelle ?” on parle alors de cible SCSI ?”, un contrôleur implémente également le protocole iSCSI. L’IP Storage 200i comprend ainsi une baie de disques SCSI traditionnelle, un serveur Netfinity sous Linux étant placé en frontal. Celui-ci accueille une carte Ethernet et exécute un pilote iSCSI et une pile TCP-IP. Le constructeur Cisco Systems supporte aussi le protocole iSCSI. Celui-ci prend la forme d’un logiciel tournant sur la passerelle SN 5420, qui relie des unités Fibre Channel à un réseau IP. Toutes ces mises en ?”uvre sont logicielles et devront, à terme, laisser la place à des implémentations matérielles plus rapides. Adaptec et Intel amorcent cette tendance avec leurs cartes pour serveurs (AEA-7110C et Intel Pro/1000 T IP Storage Adapter), qui soulagent l’unité centrale en confiant à un circuit dédié l’exécution des protocoles TCP-IP et iSCSI. Mais, pour l’instant, ce circuit demeure un processeur généraliste. Plus tard, Adaptec et Intel, mais aussi IBM, Cisco et Emulex, mettront en ?”uvre des composants réellement conçus pour cette fonction, à l’image de leurs homologues dédiés à SCSI ou à Fibre Channel.
Un protocole iSCSI aux multiples facettes
Plusieurs responsabilités incombent à l’iSCSI. Il s’agit, d’abord, de nommer les ressources (initiateurs et cibles) ; puis, de les découvrir sur le réseau, d’assurer leur authentification et d’établir des sessions ; et, enfin, de réaliser l’encapsulation de SCSI dans IP. L’identification est obtenue grâce à un nom unique désignant chaque cible et chaque initiateur. Ce nom comprend notamment celui d’une autorité de nommage ?” qui peut être un constructeur, un prestataire ou l’entreprise elle-même ?” et un numéro qu’elle a attribué à la ressource. Le standard iSCSI inclut également une méthode afin de spécifier une adresse unique de la ressource. Celle-ci est composée de son nom, de son adresse IP (ou du nom de domaine correspondant) et du port TCP.Ce procédé facilite l’identification de la cible, même si elle correspond à plusieurs adresses IP ou à plusieurs ports TCP. À l’inverse, il permet de distinguer plusieurs cibles situées derrière la même adresse ou le même port. La découverte des n?”uds peut être réalisée à l’aide de plusieurs méthodes. La plus simple consiste à configurer, sur l’initiateur, l’adresse de la cible. Mais, on peut aussi spécifier une adresse par défaut, sur laquelle l’initiateur interrogera un fichier d’adresses de cibles, via une commande prévue par l’iSCSI. Une fois la cible identifiée, une session iSCSI est lancée par un mécanisme d’authentification, qui peut s’appuyer sur IPSec. Puis, il faut réaliser l’encapsulation proprement dite.Classiquement, une application communique avec un pilote SCSI, via des CDB. En iSCSI, ces CDB traditionnels sont encapsulés dans des paquets IP : les iSCSI Protocol Data Units (PDU). Ils sont transportés jusqu’à la cible, qui les désencapsule afin de restituer et, éventuellement, de remettre en ordre, grâce à la couche TCP, des CDB en bonne et due forme. Un processus identique est mis en ?”uvre pour retourner les réponses, qui prennent la forme de statuts ou de blocs de données. En fait, une session iSCSI sera composée d’une ou de plusieurs connexions TCP correspondant à autant de tâches élémentaires qui représentent chacune, dans le jargon SCSI, une commande SCSI ou un ensemble de commandes logiquement liées entre elles. Les commandes et les réponses transmises aux connexions TCP tombées sont automatiquement relancées par la couche iSCSI.
Fibre Channel sur IP ou l’interconnexion de SAN
Alors que, en iSCSI, IP intervient entre des n?”uds qui sont aussi bien des serveurs que des passerelles ou des sous-systèmes de stockage, FCIP n’est mis en ?”uvre qu’entre des passerelles. Il s’agit, en effet, de mettre à profit le réseau longue distance de l’entreprise pour interconnecter des SAN éloignés. Cette offre est embryonnaire. Lucent Technologies et CNT ont été les premiers à se lancer sur ce créneau : Lucent, avec un module conférant le support du FCIP à son commutateur-routeur Giga Ethernet, l’OptiStar EdgeSwitch ; et CNT, avec une passerelle réalisant l’encapsulation de Fibre Channel sur IP, mais aussi sur ATM. De jeunes pousses occupent également le terrain. C’est le cas d’Entrada Networks, qui propose un déport du stockage SAN via un réseau longue distance ou un LAN pour réaliser la copie entre baies éloignées ou pour bâtir un site de reprise avec sa passerelle Silverline-222 SAN over IP Switch. SAN Valley Systems, lui, offre, avec son SL1000 IP-SAN Gateway, une passerelle entre les réseaux FC et les réseaux IP ou Gigabit Ethernet. Les flux IP sont ensuite confiés à un routeur traditionnel pour être transportés sur un réseau longue distance.Cisco, Brocade et Gadzoox sont également partie prenante du processus. Cisco prévoit ainsi d’implémenter la technologie de Brocade sur ses routeurs, tandis que Gadzoox tarde à concrétiser son engagement puisqu’il fut, avec Lucent, à l’origine de la standardisation du FCIP, à l’IETF.Dans la pratique, le FCIP prévoit que les trames Fibre Channel sont encapsulées dans des paquets IP dont le transport est confié, comme dans le cas de l’iSCSI, au protocole TCP. Mais cette encapsulation est totalement aveugle. Les trames Fibre Channel ressortent telles qu’elles sont entrées sur la passerelle dont l’adresse IP est spécifiée. Contrairement à l’iSCSI, il n’est donc pas nécessaire de découvrir des ressources, ni de modifier les pilotes ou les contrôleurs des serveurs et des sous-systèmes de stockage. Cette interconnexion est réalisée de point à point. Aux performances près, elle revient à raccorder deux SAN distants par une fibre noire ou par un réseau ATM, Sonet ou DWDM. Telle est, d’ailleurs, la vocation de solutions signées Nortel Networks, Finisar ou CNT. Certaines d’entre elles interconnectent également des réseaux Gigabit Ethernet, voire Escon et Ficon.On notera également qu’avec le FCIP les trames Fibre Channel transporteront presque toujours des commandes et des données SCSI, si bien, que, en fin de compte, le FCIP revient à réaliser, comme avec l’iSCSI, un transport de SCSI sur IP. Par ailleurs, le transport d’IP sur Fibre Channel est peu utilisé. Il est intéressant au cours de l’interconnexion directe de deux serveurs à hauts débits ou pour le transport d’un protocole tel que SNMP, afin de gérer des équipements SAN sans avoir à les relier au réseau Ethernet.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
