Quand envisager un SAN ?

Tout le monde semble vouloir se lancer dans l'achat d'un SAN, parfois avec beaucoup de passion. Les SAN sont, il faut l'admettre, plutôt séduisants. Ils figurent parmi les équipements matériels à grande échelle les plus amusants et les plus enthousiasmants que la plupart des professionnels de l'informatique ont la chance d'avoir dans leur propre infrastructure. Souvent, le désir de posséder son propre SAN relève du « besoin de faire comme les autres », car utiliser un SAN est devenu un peu un symbole de statut : l'un de ces derniers bastions de l'informatique des grandes entreprises que l'on ne voit que dans un local serveur dédié et jamais chez un particulier (enfin, presque jamais). Les SAN sont fortement mis en avant, présentés et vendus comme des boîtiers extraordinaires dont la redondance interne les rendrait infaillibles, dotés d'une vitesse qui défie toute logique et chargés de fonctionnalités dont vous ne soupçonniez même pas avoir besoin. Lorsque je discute avec des professionnels de l'informatique qui conçoivent de nouveaux systèmes, l'un des aspects de conception les plus courants que j'entends est : « eh bien, nous ne savons pas grand-chose de notre conception finale, mais nous savons que nous avons besoin d'un SAN. »

Dans le contexte de cet article, j'emploie le terme SAN dans son acception la plus courante, c'est-à-dire pour désigner un « périphérique de stockage en mode bloc » et non pour faire référence à l'ensemble du réseau de stockage lui-même. Un réseau de stockage peut exister pour un NAS sans recourir le moins du monde à un périphérique de stockage en mode bloc SAN. Ainsi, dans cet article, SAN désigne exclusivement le SAN en tant que périphérique, et non le SAN en tant que réseau. SAN est un terme flou utilisé pour signifier plusieurs choses selon les moments et peut prêter à confusion. Un SAN configuré sans réseau devient du DAS. Du DAS mis en réseau devient un SAN.

Marquons une pause un instant. Le SAN constitue votre stockage en arrière-plan. Le besoin d'en disposer serait, dans tous les cas, déterminé par d'autres aspects de votre architecture. Si vous n'avez pas encore arrêté de nombreux autres éléments, vous ne pouvez tout simplement pas savoir qu'un SAN sera nécessaire, ni même utile, dans la conception finale. Signaux d'alerte. Des signaux d'alerte partout. Imaginez une course de chars romains où les chevaux pousseraient les chars (si vous voyez ce que je veux dire).

Il est clair que la volonté de mettre en œuvre un SAN est si forte que, bien souvent, des projets entiers sont conçus sans réelle finalité, si ce n'est, semble-t-il, de justifier l'achat du SAN. Comme pour tout projet, la première question que l'on doit se poser est : « Quel est le besoin métier que nous cherchons à satisfaire ? » Et partir de là, et non de « nous voulons acheter un SAN, où pouvons-nous l'utiliser ? » Les SAN sont complexes, et qui dit complexité dit fragilité. Très souvent, les SAN entraînent des coûts élevés. Mais l'aspect le plus inquiétant d'un SAN réside dans le manque généralisé de connaissances approfondies à leur sujet dans l'industrie. Les SAN présentent d'énormes risques techniques et métier qui doivent être surmontés pour justifier leur utilisation. Les SAN sont, sans aucun doute, très enthousiasmants et fort utiles, mais cela suffit rarement à justifier l'envie d'en avoir un.

Nous qualifions les SAN de « stockage de dernier recours ». Cela signifie que, lors du choix d'un type de stockage, on espère pouvoir recourir à l'une des autres solutions, telles que des disques locaux, du DAS (Direct Attach Storage) ou du NAS (Network Attached Storage), plutôt qu'à un SAN. La plupart du temps, les autres options fonctionnent à merveille. Mais il arrive que les besoins métier imposent des exigences qui ne peuvent raisonnablement être satisfaites qu'avec un SAN. Lorsque ces cas se présentent, nous n'avons pas le choix et devons utiliser un SAN. Mais, en général, on peut l'éviter au profit d'options plus simples et habituellement moins coûteuses ou moins risquées.

Je constate que la plupart des personnes qui cherchent à mettre en œuvre un SAN le font sous l'effet d'un certain nombre d'idées fausses.

La première est que les SAN sont, par nature, hautement fiables. S'il existe assurément de nombreux fournisseurs de SAN et des produits SAN spécifiques d'une fiabilité remarquable, on pourrait en dire autant de n'importe quel produit informatique. Les serveurs haut de gamme situés dans la même gamme de prix que les SAN haut de gamme sont tout aussi fiables que les SAN. Comme les SAN sont fabriqués à partir des mêmes composants matériels que les serveurs ordinaires, il n'existe aucune magie pour les rendre plus fiables. Tout ce qui peut servir à rendre un SAN fiable est un effet de ruissellement des technologies RAS (Reliability, Availability and Serviceability) des serveurs. Tout comme un SAN, un NAS et du DAS, ainsi que des disques locaux, peuvent être rendus incroyablement fiables. SAN désigne uniquement le fait que le périphérique est utilisé pour fournir du stockage en mode bloc plutôt que pour accomplir une autre tâche. Un SAN n'est qu'un serveur très simple. Les SAN couvrent toute la gamme de fiabilité, avec une fiabilité digne d'un ordinateur central à l'extrémité haute et, à l'extrémité basse, des périphériques qui ne sont rien de plus que des disques durs externes : les périphériques réseau les moins fiables de votre réseau. Ainsi, plutôt que de signifier la fiabilité, SAN offre en réalité quelques cas particuliers correspondant à la plus faible fiabilité que l'on puisse imaginer. Mais, à toutes fins pratiques, tous les serveurs partagent des préoccupations de fiabilité à peu près équivalentes. Les SAN acquièrent une réputation de fiabilité parce que, souvent, les entreprises consacrent à leurs SAN des budgets considérables qu'elles n'allouent pas à leurs serveurs, de sorte que la comparaison oppose un SAN relativement haut de gamme à un serveur relativement bas de gamme.

La deuxième est que SAN signifierait « grand » et NAS « petit ». Une telle association n'existe pas. Les SAN comme les NAS peuvent être de presque n'importe quelle envergure ou qualité. Tous deux couvrent toute la gamme, et la technologie choisie ne donne pas la moindre indication quant à la taille d'un périphérique. De nouveau, comme ci-dessus, un SAN peut techniquement être « plus petit » qu'une solution NAS en raison de sa simplicité possible, mais il s'agit là d'un cas particulier et essentiellement théorique, même s'il existe sur le marché des produits SAN appartenant à cette catégorie : ils sont simplement très rares à rencontrer en service.

La troisième est que SAN et NAS seraient radicalement différents à l'intérieur du châssis. Ce n'est assurément pas le cas, car la majorité des périphériques SAN et NAS d'aujourd'hui relèvent de ce que l'on appelle le « stockage unifié », c'est-à-dire une appliance de stockage qui agit simultanément à la fois comme SAN et comme NAS. Cela met en évidence que la différence essentielle entre les deux ne réside ni dans la technologie d'arrière-plan, ni dans le matériel, ni dans la taille, ni dans la fiabilité, mais que la différence déterminante tient aux protocoles utilisés pour transférer le stockage. Les SAN relèvent du stockage en mode bloc, exposant des périphériques bloc bruts sur le réseau au moyen de protocoles comme Fibre Channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) ou Fibre Channel over Ethernet (FCoE). Le NAS, en revanche, utilise un système de fichiers réseau et expose des fichiers sur le réseau au moyen de protocoles de couche applicative comme NFS, SMB, AFP, HTTP et FTP, lesquels transitent ensuite par TCP/IP.

La quatrième est que les SAN seraient par nature une technologie de partage de fichiers. C'est le NAS. Un SAN consiste simplement à prendre votre stockage en mode bloc (le sous-système de disques durs) et à le rendre accessible à distance sur un réseau. La nature des réseaux laisse penser que nous pouvons rattacher ce stockage à plusieurs périphériques à la fois et, de fait, physiquement, nous le pouvons. Tout comme nous pouvions autrefois rattacher physiquement plusieurs contrôleurs aux extrémités opposées d'un câble nappe SCSI, avec des disques durs suspendus au milieu. Dans des circonstances normales, cela détruira l'ensemble des données présentes sur les disques, car les contrôleurs, qui ne savent rien les uns des autres, écrasent mutuellement leurs données, provoquant une corruption quasi instantanée. Il existe des mécanismes, dans des systèmes de fichiers en cluster spécifiques et leurs pilotes, qui permettent cette configuration, mais cela exige des connaissances et une compréhension particulières, bien plus techniques que ce que beaucoup de personnes faisant l'acquisition de SAN ont conscience de devoir maîtriser pour ce qu'elles croient souvent être la finalité même du SAN : une catastrophe si courante que je parle probablement à quelqu'un l'ayant vécue presque chaque semaine. Le fait que le SAN mette en péril le cas d'usage même que la plupart des gens croient qu'il est conçu pour gérer, et que non seulement il ne parvienne pas à offrir la protection quasi magique recherchée, mais qu'il soit au contraire la cause même de la perte de données, révèle le niveau de risque que comporte la mise en œuvre d'une technologie de stockage mal comprise.

La cinquième est que les SAN seraient rapides. Les SAN peuvent être rapides ; ils peuvent aussi être effroyablement lents. L'utilisation de la technologie SAN n'apporte en soi aucun gain de vitesse intrinsèque. Il est en réalité assez difficile pour les SAN de surmonter les goulets d'étranglement inhérents au réseau sur lequel ils reposent. Comme certaines autres options de stockage telles que le DAS utilisent toutes les mêmes technologies que le SAN mais sans le goulet d'étranglement ni la latence du réseau proprement dit, un DAS équivalent sera lui aussi un peu plus rapide que son homologue SAN. Les SAN sont généralement un peu plus rapides qu'un équivalent NAS au matériel identique, mais même cela n'est pas garanti. SAN et NAS se comportent différemment et, selon les cas d'usage, l'un ou l'autre peut offrir de meilleures performances. Un SAN serait rarement retenu comme solution sur la base de besoins en performances.

La sixième est que, du fait d'être un SAN, les problèmes inhérents aux choix de stockage cesseraient de s'appliquer. Un bon exemple est l'utilisation du RAID 5. Cela serait considéré comme une mauvaise pratique sur un serveur, mais lorsqu'on travaille avec un SAN (qui, en théorie, est bien plus critique qu'un serveur autonome), on néglige souvent une planification soigneuse du sous-système de stockage, partant du principe que, parce qu'il s'agit d'un SAN, celui-ci a d'une manière ou d'une autre résolu ces problèmes ou qu'ils ne s'appliquent pas. Il est vrai que certains SAN haut de gamme disposent bel et bien d'un certain niveau de fonctionnalités d'atténuation des risques que l'on a peu de chances de trouver ailleurs, mais elles sont rares et exclusivement réservées à des unités très haut de gamme, où l'emploi de conceptions fragiles serait de toute façon peu courant. C'est une pratique dangereuse, mais très répandue, qui consiste à apporter le plus grand soin et la plus grande attention à la planification du stockage pour un serveur physique, mais à passer outre cette même planification et cette même vigilance lorsqu'on utilise un SAN, en supposant que le SAN gère tout cela en interne ou que ce n'est tout simplement plus nécessaire.

Après avoir réfuté de nombreuses idées fausses au sujet des SAN, on peut se demander si les SAN sont parfois appropriés. Ils le sont, bien entendu, et se révèlent fort importants et incroyablement précieux lorsqu'ils sont utilisés correctement. Les points forts des SAN découlent de la consolidation et de certains types particuliers de stockage partagé.

La consolidation a été le moteur historique qui a amené les clients vers les solutions SAN. Un SAN nous permet de réunir de nombreux systèmes de fichiers au sein d'une seule baie de disques, autorisant une utilisation bien plus efficace des ressources de stockage. Parce que le SAN opère au niveau bloc, il peut le faire chaque fois qu'un sous-système de disques local et traditionnel pourrait être employé. Dans de nombreux serveurs, et même dans de nombreux postes de travail, de l'espace de stockage est gaspillé en raison des impératifs de croissance, de planification et de granularité de la capacité des disques. Si nous disposons de vingt serveurs équipés chacun de baies de disques de 300 Go, mais que chacun n'utilise que 80 Go de cette capacité, nous avons un gaspillage important. Avec un SAN, nous pourrions consolider à seulement 1,6 To, plus une faible quantité nécessaire à la surcharge, et dépenser bien moins en disques physiques que si chaque serveur gérait son propre stockage.

Une fois que nous commençons à consolider le stockage, nous nous mettons à rechercher des possibilités de consolidation avancées. Ayant consolidé de nombreux systèmes de fichiers de serveurs sur un seul SAN, nous avons la possibilité, si notre implémentation SAN le prend en charge, de dédupliquer et de compresser ces données, ce qui, dans de nombreux cas comme celui des systèmes de fichiers de serveurs, peut potentiellement entraîner une réduction significative de l'utilisation. Ainsi, les 1,6 To de notre exemple ci-dessus pourraient en réalité ne représenter au final que 800 Go, voire moins. Soudain, nos chiffres de consolidation s'améliorent de plus en plus.

Pour tirer efficacement parti de la consolidation, il faut disposer d'une certaine échelle, et c'est là que les SAN brillent vraiment : lorsque l'échelle, en capacité mais surtout en nombre de nœuds rattachés, devient très importante. Les SAN sont les mieux adaptés à la consolidation de stockage à grande échelle. C'est leur domaine de prédilection et ce qui les rend quasi omniprésents dans les grandes entreprises et très rares dans les petites.

Les SAN sont également très importants pour certains types de clustering et de stockage partagé qui requièrent un accès à un système de fichiers partagé unique. Il s'agit en réalité d'un besoin assez rare en dehors d'une circonstance particulière : les bases de données. La plupart des applications se contentent volontiers de n'importe quel type de stockage qui leur est fourni, mais les bases de données exigent souvent un accès bloc de bas niveau afin de pouvoir manipuler leurs données de la manière la plus efficace possible. De ce fait, elles peuvent rarement être utilisées, ou utilisées efficacement, sur du NAS ou des serveurs de fichiers. Fournir des environnements de stockage à haute disponibilité pour les clusters de bases de données est depuis longtemps un cas d'usage clé du stockage SAN.

En dehors de ces deux cas d'usage principaux, qui justifient la grande majorité des installations de SAN, le SAN offre également un haut niveau de flexibilité de stockage en rendant potentiellement très simple le déplacement, l'extension et la modification du stockage dans un grand environnement, sans avoir à gérer de déplacements physiques ni de procédures d'approvisionnement et de provisionnement compliquées. De nouveau, comme la consolidation, cela est un artefact de la grande échelle.

Dans de très grands environnements, l'utilisation d'un SAN peut aussi servir à établir un point de démarcation entre les équipes de stockage et d'ingénierie système, permettant un passage de relais au niveau de la couche réseau, généralement en Fibre Channel ou iSCSI. Cette séparation nette des responsabilités peut s'avérer cruciale pour permettre aux équipes d'être fortement cloisonnées dans les entreprises qui souhaitent des équipes de stockage, de réseau et de systèmes très distinctes. Cela permet à l'équipe de stockage de ne se consacrer qu'au stockage et à l'équipe des systèmes de ne se consacrer qu'aux systèmes, sans qu'aucune n'ait besoin de connaître les implémentations de l'autre équipe.

Pendant longtemps, les SAN se sont également présentés comme un moyen commode d'améliorer les performances de stockage. Ce n'est pas une composante intrinsèque du SAN, mais une retombée de leur usage courant pour la consolidation. De manière analogue à la virtualisation utilisée comme moyen de consolidation, les SAN partagés présentent un avantage naturel : une meilleure utilisation des broches disponibles, des caches centralisés et un matériel plus puissant que le stockage équivalent réparti entre de nombreux serveurs individuels. À l'instar des ressources CPU partagées, lorsque le SAN ne reçoit pas de requêtes de plusieurs clients, il a la capacité de consacrer l'intégralité de sa capacité au traitement des requêtes d'un seul client, offrant une expérience de performance moyenne potentiellement bien supérieure à ce qu'un serveur individuel pourrait atteindre à un coût raisonnable par ses propres moyens.

L'utilisation d'un SAN à des fins de performance perd toutefois rapidement de sa popularité, en raison de l'avènement du stockage SSD, devenu très courant. À mesure que les SSD, dotés d'une latence incroyablement faible et de performances IOPS élevées, voient leur prix baisser au point d'être ajoutés à des serveurs autonomes comme cache local, voire potentiellement utilisés comme stockage principal, le goulet d'étranglement du réseau des SAN devient un facteur de plus en plus prépondérant, rendant de plus en plus difficile pour les avantages de consolidation d'un SAN de compenser les gains de performance des SSD locaux. Les SSD sont potentiellement très disruptifs pour le marché du stockage partagé, car ils ramènent l'avantage de performance vers le stockage local : il s'agit là du dernier épisode en date des flux et reflux de la conception des architectures de stockage.

L'aspect le plus important à retenir concernant l'utilisation d'un SAN est qu'un SAN ne devrait pas constituer un point de départ par défaut dans la planification du stockage. C'est l'un des nombreux choix technologiques possibles, et un choix qui, souvent, ne répond pas au besoin comme on l'espérait, ou y répond mais à un coût inutilement élevé, que ce soit en termes financiers ou de complexité. Commencez par définir les objectifs et les besoins métier. Choisissez le SAN lorsqu'il répond le plus efficacement à ces besoins, mais gardez l'esprit ouvert et tenez compte de l'ensemble des besoins de stockage de l'environnement.