imageteam - Fotolia
Les trois définitions du « Software Defined Storage »
TRIBUNE. Comme tout un chacun, je me suis efforcé de déterminer ce qu’est le SDS… Jusqu’à ce que je me rende compte qu’il en existe trois.
Ce que je souhaite le plus, c’est une forme de lucidité sur la terminologie que nous utilisons pour décrire ce qui a trait au stockage. Car ce qui m’a d’abord attiré dans l’informatique, c’est un usage rigoureux du langage ; l’application précise, quoique parfois un peu rigide, de la terminologie utilisée pour décrire les produits et les processus. Cet usage contrastait nettement avec le double langage informe du marketing ou de la politique, domaines dans lesquels le haut peut également désigner le bas, et le chaud quelque chose de carrément froid.
Voilà longtemps déjà que la rigueur linguistique susmentionnée est partie en fumée.
Et nous voici confrontés au double défi consistant, d’une part, à comparer des solutions concurrentes en fonction de problèmes techniques, tout en recherchant ce qui convient le mieux à notre environnement, et d’autre part, à essayer de comprendre précisément ce que les fournisseurs essaient de nous vendre.
En 1999, le discours en matière de stockage assimilait le DAS (Direct Attached Storage), au croquemitaine. Un rattachement direct des ressources de stockage placées en arrière-plan des serveurs restreignait l’accès aux données résidentes. Pire : si le serveur était mal configuré, ou s’il perdait de sa puissance, l’accès aux données était fermé.
Les NAS et les SAN solutionnent les carences des DAS… ou pas
Pour remédier à la nature « insulaire » du stockage DAS, il existait alors une solution qui consistait à déployer un stockage rattaché au réseau, le NAS (Network Attached Storage) ; une appliance qui offrait de formidables possibilités de partage.
Sauf que le NAS n’était ni plus ni moins qu’un DAS.
En coulisse, le « serveur léger » chargé de l’appliance NAS était (et est toujours) constitué d’une carte mère, d’un système d’exploitation et d’applications logicielles spécifiques. Les disques sont directement rattachés à ce serveur et sont partagés à l’échelle d’un réseau via un logiciel qui s’exécute sur le serveur NAS.
Un NAS n’était donc pas différent d’un service de fichiers administré par un serveur connecté à une batterie de stockage DAS. Toutefois, un fournisseur pouvait bricoler un assemblage des deux concepts et le vendre sous la forme d’une solution unifiée, qui devenait alors supérieure au bricolage du serveur matériel d’un concurrent, ou du stockage matériel d’un autre.
Et voici alors qu’apparut cette autre solution DAS appelée réseau de stockage, ou SAN (Storage Area Network). À ceci près que, selon la définition technique des réseaux, le SAN n’en était pas un.
Un SAN fournissait un maillage interconnecté fondé sur le protocole Fibre Channel (FC) et utilisait une commutation de couche physique rudimentaire pour établir/rompre à grande vitesse des connexions DAS, offrant ainsi des fonctions de type réseau.
À cet effet, un argumentaire de 10 pages élégamment tourné, rédigé par un ingénieur en chef de chez Cisco Systems faisant autorité à l’époque, est disponible dans les dossiers d’historique du comité ANSI T11 en charge de la normalisation de Fibre Channel… Ce qui n’a pas empêché Cisco d’entrer sur le marché des commutateurs SAN FC quelques années plus tard, en s’alignant sur le discours du marché et en désignant la technologie FC comme un protocole « réseau ».
Les SAN, à leur tour, fournissent des ressources de stockage aux serveurs à la manière des DAS. Ce principe se vérifie quel que soit le maillage utilisé : FC, iSCSI, SAS ou InfiniBand, voire du fil et des gobelets en carton. Ainsi, à l’instar de simples DAS et NAS, le stockage SAN dans son ensemble est donc « directement rattaché ».
Le Stockage partageable fait la différence
C’est la capacité de partage qui différenciait vraiment le SAN et le NAS du DAS classique. Peu d’installations DAS affichaient des architectures de partage d’un type ou de l’autre ; cet aspect constituait l’apanage des appliances SAN et NAS.
En tant qu’ingénieurs chargés du stockage, nous sélectionnions un produit qui reposait sur deux choses. D’une part sur le nombre de dispositifs de stockage qu’il nous fallait connecter (SCSI série et ses variantes - notamment FCP, iSCSI et SAS, qui offraient un grand nombre de points de connexion – là où le SCSI parallèle était beaucoup plus limité). Et d’autre part sur le nombre de serveurs/postes bureautiques nécessaires au partage de la capacité de stockage (le DAS traditionnel était considéré comme un peu plus rébarbatif en termes de partage multi-utilisateur qu’un SAN ou un NAS).
Parallèlement, nous tenions compte du coût, des affinités avec le fournisseur ainsi que d’autres facteurs divers et variés.
Les SAN deviennent virtuels, ou presque
Si nous avançons en accéléré jusqu’à aujourd’hui, on nous dit que les SAN virtuels constituent la nouvelle topologie, celle qui corrige la rigidité et diminue le coût des SAN classiques, en renvoyant l’intégralité des ressources de stockage à une configuration à rattachement direct installée derrière chaque hôte de serveur virtuel.
Qui plus est, ce type de stockage est à « définition logicielle » ; en effet, les services à valeur ajoutée, traditionnellement installés sur les contrôleurs des baies de stockage SAN ou NAS, font l’objet d’une abstraction au sein d’une couche logicielle autonome installée sur chaque serveur, réduisant ainsi le kit à un simple ensemble de disques JBOD (Just a Bunch of Disks).
Plutôt que de partager le stockage avec différents hôtes, nous allons répliquer les données en continu entre plusieurs exemplaires d’ensembles complexes serveur/stockage, que nous appellerons désormais « nœuds de cluster ».
À ceci près que cette définition du « stockage à définition logicielle » (SDS) ou du SAN virtuel n’améliore pas la clarté.
VMware place les services de stockage à valeur ajoutée sur une couche logicielle qui fait partie intégrante de son hyperviseur de serveurs, ajoutant des frais au logiciel qui sont équivalents à ceux du stockage flash et du disque physique rattaché. Un récent rapport de laboratoire de test industriel nous apprend que les frais de licence logicielle et les coûts d’acquisition du matériel pour un cluster de SAN virtuel (vSAN) VMware minimal de trois machines s’inscrivent dans une fourchette de 10 000 à 15 000 dollars par nœud. Un peu cher pour les petites entreprises (et même pour nombre de grandes entreprises).
De plus, dans l’approche VMware, le stockage est dédié aux seules charges de travail instanciées par l’hyperviseur VMware. Il en ressort que dans un nombre croissant d’entreprises, seule une partie de l’infrastructure fait fonctionner un hyperviseur VMware. Et il y a de grandes chances que vous disposiez également de solutions Microsoft Hyper-V, voire Citrix ou KVM, et très probablement d’applications transactionnelles non encore virtualisées — le tout lui aussi accompagné d’exigences de stockage spécifiques — autant d’éléments que vous ne pourrez intégrer au stockage du vSAN VMware.
Des applications indépendantes des hyperviseurs apportent l’espoir d’un stockage à définition logicielle
Mais il y a quelques bonnes nouvelles… Maxta, StarWind Software et StorMagic semblent tous proposer des kits logiciels indépendants des hyperviseurs ; des kits qui font la même chose que VMware avec son vSAN (un concept inventé par StarWind, soit dit en passant), mais selon un mode qui permet de partager le stockage à l’échelle de plusieurs charges de travail exécutées sous des hyperviseurs distincts. Mais est-ce encore un stockage à définition logicielle ?
Autre bonne nouvelle : toutes les solutions de virtualisation du stockage comme celles de DataCore Software ou IBM affirment pouvoir répondre non seulement aux besoins de stockage des applications virtualisées via un hyperviseur, mais aussi à ceux du groupe récalcitrant des applications transactionnelles stratégique que personne ne veut virtualiser. Mais est-ce vraiment un stockage à définition logicielle ?
À l’aube de l’année à venir, peut-être que des efforts seront faits pour améliorer la terminologie du stockage, ce qui nous permettra d’obtenir un jeu de descriptions plus utile.
Pour le moment, selon moi, le débat autour de la définition du stockage à définition logiciel (SDS) a trois centres de gravité :
- SDS dépendant de l’hyperviseur : Les services de stockage sont administrés directement par le logiciel hyperviseur et exploités par la charge de travail virtualisée exclusivement via cet hyperviseur.
- SDS indépendant de l’hyperviseur : Les services de stockage sont administrés par un produit logiciel tiers qui permet de partager le stockage géré à l’échelle de plusieurs types d’hyperviseurs.
- SDS indépendant de la charge de travail : La capacité et les services de stockage sont administrés par un produit tiers qui permet l’affectation et le partage des actifs de stockage à l’échelle de toutes les charges de travail, virtualisées ou non.
Peu m’importe la terminologie employée au final, tant que l’industrie abandonne des éléments différenciateurs sans intérêt comme le rattachement direct, et en finit avec cette absurdité consistant à s’évertuer à mettre en avant des approches dépendantes des hyperviseurs comme autant d’attributs à consonance positive, tels qu’« unifié » ou « hyperconvergé ».
En réalité, les approches indépendantes sont bien plus économiques et bien plus efficaces en termes d’E/S. Voilà : vous avez mon point de vue pour ce qu’il vaut.
Informaticien expérimenté, JON WILLIAM TOIGO est PDG de Toigo Partners International, et président du Data Management Institute.
