Les besoins en stockage continuent d’exploser. Le commerce électronique, les progiciels de gestion intégrés et les datawarehouses sont autant d’applications consommatrices de disques. Pour absorber cette croissance, les réseaux de stockage (SAN, Storage Area Network) semblent plus appropriés que les autres architectures, tout en étant plus coûteux et plus lourds à installer. Les NAS (Network Attached Storage) représentent, selon les cas, un complément ou une alternative plus facile à mettre en place. Et leur progression en termes de ventes est tout aussi remarquable. Les prévisions d’IDC témoignent de cet accroissement exponentiel : le marché des systèmes de stockage vendus dans le cadre de configurations SAN et NAS devrait représenter 18,8 milliards de dollars en 2004, soit quatre fois plus qu’en 2000.
Une technologie qui s’appuie sur Fibre Channel
Difficile, en effet, de répondre à une brusque montée en charge en ajoutant des baies directement sur les serveurs applicatifs ?” ce qui correspond à l’architecture SAS, pour Server Attached Storage. Dans une telle configuration, où les baies sont reliées au serveur par un lien SCSI, il n’est effectivement pas question de partager des disques entre plusieurs serveurs. L’architecture NAS, en revanche, permet de mutualiser les ressources. Elle consiste à placer sur le réseau IP de l’entreprise une baie de stockage multi-environnement, partageable par plusieurs serveurs grâce à un service de fichiers. Très facile à mettre en place et relativement économique, le NAS souffre néanmoins du même inconvénient que le SAS. A savoir le risque d’engorgement du réseau local en cas de sollicitations répétées des utilisateurs. Les SAN permettent précisément de contourner cet obstacle. Le principe ? Créer un réseau dédié au stockage, distinct du LAN, dans lequel toutes les ressources sont mutualisées. Un concept rendu possible grâce à une technologie de bus série à haut débit, le Fibre Channel ?” 1 Go/s théorique sur fibre optique. Une aubaine, puisque, à l’arrivée des premiers SAN en 1997, quatre disques haut de gamme suffisaient à saturer un bus Ultra-2 SCSI. Autre avantage : FCP, le protocole de haut niveau associé à Fibre Channel, a été conçu pour gérer différents protocoles ?” dans les faits, il encapsule essentiellement des instructions SCSI. Enfin et surtout, cette technologie est capable de gérer des distances intern?”uds de dix kilomètres, contre seulement douze mètres pour l’Ultra-2 SCSI.Aujourd’hui, les entreprises mettent en place un SAN pour répondre à trois problématiques. L’une d’elles concerne la sauvegarde des données : la fenêtre de sauvegarde doit être réduite au minimum pour ne pas avoir un impact sur les applications de production. L’autre a trait aux espaces disques supplémentaires qu’il faut allouer aux serveurs : ces opérations impliquent encore souvent l’arrêt du système et nécessitent de lourdes dépenses ?” supérieures, en tout cas, à celles investies lors d’une mutualisation des ressources. Et la troisième enfin : les activités de commerce électronique exigent du système qu’il fonctionne en haute disponibilité. “Or, le Fibre Channel, un protocole déjà testé et éprouvé, garantit un maximum de robustesse et de fiabilité”, explique Franck Didi, directeur général de Distrilogie.
“Les choix du client ne sont jamais objectifs”
Mais si l’architecture du SAN est très séduisante sur le papier, un point reste encore très problématique : l’interopérabilité entre ses différents éléments. Schématiquement, le SAN peut être vu comme un puzzle constitué de cinq briques : le matériel réseau ?” commutateurs, concentrateurs, cartes HBA ?”, les baies de stockage, les serveurs et leurs systèmes d’exploitation, les logiciels de sauvegarde, et, pour finir, les outils d’administration (qui incluent les logiciels de gestion de stockage). L’enjeu est de les faire cohabiter et dialoguer. Car si, dans le monde du SAN, les normes existent pour l’architecture Fibre Channel ?” elles sont édictées par la SNIA, Storage Networking Industry Association ?”, elles ne normalisent pas les échanges de fonctionnalités entre matériels. Historiquement, la première difficulté ?” aujourd’hui partiellement résolue ?” portait sur l’interopérabilité des systèmes d’exploitation et des unités de stockage. Si EMC a toujours été en avance dans ce domaine, ses concurrents commencent à rattraper leur retard. Même si, MTI ne supporte pas Open VMS ?” idem avec HDS jusqu’en avril dernier ?” et que l’offre de Sun reste essentiellement tournée vers Solaris. “Au final, les choix des clients ne sont jamais objectifs : ils restent en grande partie guidés par les compatibilités des matériels avec leur infrastructure existante”, rappelle Joël Willeretz, consultant chez CMG. L’interopérabilité devient plus complexe encore lorsque cohabitent, au sein du SAN, des baies ou des commutateurs de marques concurrentes. Car si les premiers réseaux de stockage restaient homogènes ?” le SAN reposait sur un fournisseur unique ?”, “la donne change, précise Franck Didi. Les clients ne veulent plus dépendre d’un seul acteur”. Il s’adressent donc à des intégrateurs pour agréger des éléments hétérogènes. Parmi les conflits les plus flagrants, on retiendra ceux concernant les commutateurs.
Un début d’ouverture sur le front du SAN hétérogène
Un SAN dans lequel des commutateurs Brocade, Irange, Vixel ou McData seraient mis en cascade relève encore du rêve. Les constructeurs s’accordent pour accuser le leader, Brocade, de ne pas implémenter dans son microcode un protocole pourtant reconnu par la SNIA. L’accusé, lui, nie en bloc… D’autres constructeurs ?” EMC en tête ?” sont accusés par les intégrateurs de verrouiller leur offre SAN : les cartes HBA seraient paramétrées pour n’accepter que du matériel EMC. La situation évolue toutefois vers plus d’ouverture. La SNIA, HP, HDS, IBM et… EMC se sont engagés à faire collaborer leurs équipes de support dans des SAN hétérogènes, pour garantir l’interopérabilité entre leurs baies.“A terme, cependant, le principal problème sera moins la reconnaissance du matériel par les systèmes que l’interopérabilité des logiciels de gestion des SAN”, explique Franck Didi. Car ces outils représenteront une manne financière colossale. Acquis à cette réalité, les constructeurs : après avoir, jusqu’à présent, restreint leurs logiciels à leur matériel, ils cherchent à devenir des éditeurs généralistes capables de gérer des ressources qui ne sont pas les leurs. Et ce à grand renfort d’acquisitions ou d’accords technico-marketing. Compaq, Sun, Hitachi, HP, EMC… Tous ont des prétentions dans l’administration, la supervision ou la virtualisation des SAN multiplates-formes. Ils cherchent en cela à concurrencer des acteurs comme Veritas, Tivoli, BMC, ou encore Datacore et Falconstore, spécialisé dans la virtualisation. Mais l’intégration de ces outils aux différents matériels n’est pas sans poser quelques difficultés. “Certains constructeurs, comme HDS il y a encore quelques mois, n’étaient pas à même de fournir les modules de connaissance nécessaires à leur interfaçage avec Patrol, de BMC. Il fallait donc procéder à des développements spécifiques”, explique Joël Willeretz. Celui-ci reconnaît toutefois que les constructeurs cherchent désormais à développer des ponts avec le maximum de logiciels d’administration. Un autre exemple concerne les unités d’EMC. Des éditeurs tels que Veritas et BMC ont accès à leurs API. Mais s’ils sont capables d’administrer les LUN (Logical Unit Number) de leurs baies, ils ne peuvent, en théorie, les modifier. Sauf à développer, comme Veritas, une passerelle spécifique avec le logiciel d’EMC dédié à la création de LUN. D’autres constructeurs, en revanche, tel HDS, ouvrent plus volontiers leurs baies aux éditeurs.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
