Blog scientifique, technologique, environnemental et politique de Nicolas HAHN

Aller au contenu | Aller au menu | Aller à la recherche

Quel avenir pour les technologies de stockage?

A l'aune de la révolution portée par les containers dans l'IT, du changement de paradigme en cours impulsé par l'avènement des micro-services et de certains logiciels fer-de-lance comme Kubernetes, Containerd.io, docker et d'autres, et considérant les besoins dignes de ce que mange un ogre, en perpétuelle croissance, en terme de stockage des données, j'avais envie d'écrire ce petit article pour me poser un moment par rapport aux différentes évolutions du point de vu des technologies de stockage.

Je me rappelle du temps lointain (à l'échelle de l'histoire de l'informatique) où j'ouvrais le carton, tout excité, de mon tout premier ordinateur. Il s'agissait à l'époque d'un ATARI 520STf. C'était à mes 13 ans. Bon on ne va pas épiloguer sur mon âge actuel, mais j'ai à peine vieilli depuis.

Celui-ci était doté d'un lecteur de disquette 3.5 pouces intégré, sur lequel je pouvais stocker mes merveilleux programmes réalisés en GFA Basic 3.5E, en assembleur Motorola 68000 ainsi qu'en C, puis mes fichiers MIDI générés à partir de mon piano électronique et de PRO 24 ou Cubase, jusqu'à hauteur de 360 ou 720 Ko...

ATARI 520 STf, mai 2020

Puis un peu plus tard, je l'ai changé pour un ATARI 1040STe, doté d'un lecteur de disquette HD 3.5 pouces permettant de stocker 1440 Ko, et beaucoup plus tard j'ai pu faire l'acquisition d'un ATARI FALCON 030 toujours doté du même lecteur de disquette mais aussi et surtout d'un disque dur de 20 Go!!!

Je possède toujours cet ATARI FALCON 030 aujourd'hui, pour me remémorer cette époque tant regrettée.

Good old times...

Trente ans plus tard, ce qui nous amène à aujourd'hui, je travaille toujours dans des gros environnements IT dans des datacenters de toute taille, et cela fait très peu de temps que je m'intéresse au monde des micro-services et des containers, dont le principal moteur est Kubernetes. Je m'y intéresse surtout au niveau de l'infrastructure, pour le moment, c'est à dire quelles machines au sens large on peut être susceptible de mettre en place dans un datacenter pour permettre à des clusters Kubernetes de pouvoir fournir un bon niveau de service vis à vis de toutes les applications qui sont hébergées et de la quantité de données astronomique qui doit être gérée et rendue disponible en à peine quelques millisecondes.

Au niveau des applications, et pour rester très simple, l'évolution est la suivante. Les applications ont tout d'abord été hébergées:

  1. sur des serveurs qualifiés de "standalone". C'est à dire sur quantité de serveurs "bare-metal" hébergés dans des datacenters, donc des machines physiques brutes sur lesquelles on installait un système d'exploitation (OS), qui faisait ensuite tourner une application. Très souvent en ce temps là pas si lointain, une application = un serveur.
  2. puis est venu le temps de la virtualisation avec des produits comme VMWare. On installe dans ce cas un système d'exploitation particulier (l'hyperviseur) sur le serveur physique, qui permet de distribuer les ressources de celui-ci (processeurs, mémoire, stockage) entre plusieurs serveurs "virtuels", sur ces derniers est installé un OS, et ensuite vient l'application en dernier lieu. L'évolution de la virtualisation a été matériellement accompagnée et favorisée par l'avènement des processeurs multi-cores, c'est à dire dotés de plusieurs coeurs de CPU plus ou moins indépendants les uns des autres (hyper-threading ou pas par exemple). Pour certain, la virtualisation a pu soutenir la rationalisation des moyens informatiques physiques et une meilleur utilisation et distribution de ses ressources, en simplifiant notamment la gestion de l'infrastructure ainsi virtualisée. On pourrait même dire qu'on a vu à ce moment là les premiers projets de gestion de l'infrastructure par les aspects logiciels (infra-as-code). Pour d'autres, la virtualisation a apporté une couche de complexité supplémentaire, donc des bugs et vulnérabilités supplémentaires, beaucoup de dépenses supplémentaires avec des coûts parfois supérieurs au standalone bare-metal pur, des performances un peu moindres ou très très franchement moindres par rapport au bare-metal surtout dans le cas des bases de données, et une dépendance accrue aux éditeurs de solutions de virtualisation.
  3. et enfin nous en sommes en ce moment à l'hébergement des applications sous forme de containers. Autrement dit l'application à héberger est rendue la plus simple et élémentaire possible, ce qui lui permet d'avoir une petite taille, et du coup d'être "agile" dans l'infrastructure. On parle de micro-services. Par exemple, une application telle qu'on pouvait la concevoir "dans l'ancien temps" (je devrais dire dans le cycle précédent, par analogie avec les cycles CPU ou à TRON/TRON Legacy) était monolithique: un énorme bloc de code compilé dans un seul exécutable qui pouvait peser plusieurs Mo ou Go. Le monde des micro-services est plutôt un monde dans lequel les applications restent de toute façon découpées en fonctionnalités, mais chaque fonctionnalité tend à être un mini-exécutable déployé dans un container dédié. Le container est donc censé être de petite taille, et il est censé pouvoir se déplacer quelque part en quelques secondes, sur n'importe quel serveur en fait, de l'infrastructure sous-jacente. Cela le rend très résilient et tolérant aux pannes et aux demandes de charge puisqu'il peut se multiplier pour absorber les requêtes "clientes" et chaque copie peut en théorie prendre le relais d'une autre copie qui viendrait à défaillir, entre autre. Tout ceci étant géré non plus par un hyperviseur, mais par un orchestrateur comme Kubernetes.

Ce que l'on voit très souvent maintenant, ce sont des containers qui tournent au sein de machines virtuelles qui elles-même tournent sur des serveurs physiques (bare-metal) dotés d'un nombre de coeurs de CPU très important (40 coeurs, 64 ou encore plus) et d'une mémoire très importante (de l'ordre du To ou plus): de plus en plus de couches empilées qui font tourner de plus en plus de code principalement écrit en Java et qui donc lui même n'est pas tendre avec la consommation qu'il fait des ressources...

J'ai beaucoup vu aussi une utilisation totalement erronée des containers: une utilisation en "mode VM", c'est à dire des containers très très lourds empaquettant des applications monolithiques... Autant rester sur de la VM dans ce cas. Mon dernier exemple en date: regardez la taille du container de la base de données DB2!

Mais revenons-en à ce qui m'intéresse donc ici: plaçons-nous maintenant du côté des technologies de stockage.

Du point de vue physique, une énorme quantité d'applications peuvent donc être amenées à s'exécuter sur un seul et même serveur physique. Pour que le temps de réponse de ces applications reste acceptable pour les clients, l'achitecture même des serveurs a dû suivre et s'adapter pour pouvoir traiter et transférer toujours plus de données. Comme je l'ai déjà évoqué plus haut:

  • toujours plus de CPU et de cores de CPU
  • toujours plus de mémoire
  • toujours plus de stockage
  • et bien entendu toujours plus de serveurs dans les datacenters
  • toujours plus de consommation électrique aussi...

Tout ceci se traduit inévitablement par un besoin toujours plus important de bande passante. A quel niveau? Au niveau des bus de données.

Les bus de données.

De quels bus de données parle-t-on?

Tout d'abord les bus de données internes des serveurs: les lignes conductrices gravées sur les carte-mères des machines entre les différents composants que sont les CPUs, les divers chipsets, les contrôleurs (IDE, SATA, SCSI, NVME, ...)

Mais bien entendu on parle aussi des bus de données externes comme toute l'infrastructure réseau.

La règle universelle ici est que plus l'on s'éloigne du processeur, plus les bus de données sont lents. Pour transporter toujours plus de données d'un point A à un point B, il faut des vitesses toujours plus élevées de transmission des données (en GHz), et il faut aussi de plus en plus de lignes de transmission en parallèle. Les processeurs que l'on utilise aujourd'hui sont qualifiés de processeurs 64 bits. Pour imager, 64 autoroutes parallèles qui vont de Lyon à Paris peuvent transporter 64 fois plus de véhicules qu'une seule autoroute. Plus on s'éloigne du centre, ici de Paris, et plus on s'enfonce dans les campagnes, moins il y a d'autoroutes qui permettent aux données - les véhicules - de rouler à 130 km/h. Et donc on tombe à des vitesses de plus en plus faibles, avec un nombre de lignes de transmission de plus en plus faible aussi.

Bus de données saturé???, mai 2020
Bus de données saturé???

Tout ceci étant rapporté au stockage, qu'est ce que cela nous donne?

Tout d'abord au niveau des bus de données utilisés pour les mediums de stockage, disons que nous sommes passés, pour en parler rapidement, de l'IDE, puis les différentes normes SATA 1 à SATA 3, en passant par le SAS, le SCSI et toutes ses déclinaisons (ultra, ultra wide, ...), puis le NVMe sur bus PCI-express (1x, 2x, 4x, ...), le bus le plus performant d'un serveur aujourd'hui et utilisé par toutes les cartes d'extension très gourmandes en données comme les grosses cartes graphiques, les cartes d'extension RAID, les cartes réseau >= 10 Gbits/s, les SSDs NVMe...

Ensuite pour ce qui est des mediums de stockage, au delà des cartes perforées, des bandes magnétiques, des disquettes, des premiers disques durs à plateaux de quelques Go seulement qui ont fait les beaux jours des technologies de stockage d'antan, nous en sommes maintenant aux disques durs à plateaux d'une capacité qui dépasse 16 To par disque dur pour les plus gros, et aux SSDs de quelques Tos mais qui sont capables d'atteindre des vitesses de traitement de l'ordre de 200 fois plus importante que celle des disques à plateaux. On parle des IOps, c'est à dire du nombre d'opérations d'entrée/sortie par seconde que peut soutenir un medium de stockage.

Les disques durs ont une capacité de stockage très importante, mais un nombre d'Iops très faible et une bande passante faible en comparaison des SSDs.

De manière générale, un disque dur ne peut pas soutenir plus de 200 à 500 Iops. Car c'est un dispositif mécanique primaire qui nécessite que les têtes de lecture/écriture, qui sont sur un bras mécanique servant de balancier, se déplace sur la surface des plateaux. Tout ceci prend un temps considérable à l'échelle de l'électronique pure. Ensuite la bande passante d'un disque dur est au mieux située entre 80 Mo/s et 150 Mo/s.

Ces deux notions, Iops et bande passante, sont les deux notions essentielles pour qualifier les performances d'un medium de stockage.

Un SSD SATA-3 qui n'est constitué quant à lui que de puces électroniques sans avoir de quelconques parties mécaniques en mouvement, offre un niveau d'Iops supérieur à 80000, et peut même atteindre les 100000, donc au minimum 200 fois plus qu'un disque dur à plateaux, et une bande passante de l'ordre de 500 Mo/s ou plus, ce qui est dans la fourchette haute de ce que peut transférer un bus de données SATA-3 qui permet au mieux 6 Gbits/s. Le SAS (Serial Attached SCSI), principalement utilisé dans les serveurs des datacenters peut monter à 12 Gbit/s.

Enfin un SSD en NVMe, offre un niveau d'Iops supérieur à 600000 Iops, soit au bas mot 1200 fois plus qu'un disque dur à plateaux, et une bande passante de l'ordre de 3300 Mo/s. C'est ce qui se fait littéralement de mieux à ce jour. Les serveurs physiques utilisés dans le cadre de grosses bases de données sont très utilisateurs de ce type de SSDs.

Pour finir, ces mediums de stockage physique sont agrégés en forme de grappes dans les serveurs au moyen de cartes RAID, que ce soit des serveurs conventionnels, des serveurs dédiés au stockage, ou des SANs, qui ne sont ni plus ni moins qu'un type spécifique de serveur dédié exclusivement au stockage et que l'on nous vend très... très cher.

Les bus de données reliant les SANs aux serveurs qui vont traiter les données sont majoritairement câblés au moyen de fibres optiques sur les serveurs, par un réseau SAN dédié qui n'est pas le réseau Ethernet "standard" des serveurs. En principe. Les cartes SAN elles-même sont passées de 1 Gbits/s, 2 Gbits/s, 4 Gbits/s anciennement à 8, 10 ou 16 Gbits/s aujourd'hui. Les SANs peuvent regrouper une quantité importante de disques, que ce soit SSDs ou à plateaux, segmentés en LUNs et servis aux différents serveurs.

Les SANs sont un moyen de stockage hyper-centralisé, et partagés, avec un certain nombre de Tos mis à disposition, ou de quelques Po (péta-octets) maximum.

Voici pour ce retour sur le passé et ce petit état des lieux rapide.

D'où pourraient provenir les problèmes de performance?

Maintenant, si je regarde derrière moi en faisant un petit état des lieux sur ma carrière en datacenter durant ces plus de 20 ans, il n'est pas faux de dire, par constat, que de tous temps, les principaux problèmes auxquels j'ai dû faire face d'une manière ou d'une autre ont pratiquement toujours été des problèmes d'I/Os et de bande passante insuffisante pour permettre d'alimenter suffisemment rapidement les applications, donc les machines, en données. C'est simple, il n'y a jamais assez d'I/Os et de bande passante car si vous m'avez suivi jusque là, la donnée se trouve toujours en bout de chaine dans une infrastructure IT, au fin fond du bout des bus de données, donc au plus loin des processeurs des machines, donc trop lent. Humainement, cela revient à dire qu'on est arrivé au bout du monde sur un chemin caillouteux étroit.

Dans l'une de mes expériences professionnelles, j'ai dû repenser intégralement une infrastructure serveur complète d'un datacenter tellement les performances étaient pauvres. Pour dire les choses, il s'agissait de faire tourner des containers sur des serveurs virtualisés OpenShift Origin, ces containers devant traiter des données sur environ 200 volumes persistants distincts subissant en permanence une forte tension sur les I/Os et la bande passante. Qui plus est le stockage était en replica 3 (donc répliqué 3 fois). 250 développeurs à travers le monde devaient travailler sur cette infrastructure OpenShift.

Les serveurs étaient physiquement câblés sur un seul réseau ethernet à 1 Gbits/s. Ce qui signifie que, à la fois les données pour le stockage et les échanges ethernet "standards" utilisaient tous les mêmes liens à 1 Gbits/s.

Pour poser le problème, 1 Gbits/s permet au mieux une bande passante de 120 Mo/s. Là encore, si vous m'avez suivi, 120 Mo/s c'est la bande passante moyenne haute d'un seul disque dur à plateaux. Puis comme je l'ai indiqué, les données étant répliquées trois fois, cela revient à dire que la bande passante utile est de 120 Mo/s divisé par trois, soit un maximum de 40 Mo/s. Et cela, c'est dans le meilleur des mondes si on estime qu'aucun autre type de traffic réseau ne viendra impacter la bande passante utilisée par le stockage! Le résultat, c'est qu'une vingtaine de gros serveurs virtuels OpenShift se partageaient tous l'accès à l'équivalent d'un seul disque à plateaux dont la bande passante est divisée par trois. Expliquer pourquoi les clients finaux n'étaient pas satisfaits du service, pourquoi la plateforme crashait sans arrêt, pourquoi quand cela marchotait c'était très lent, c'était finalement très facile dans ces conditions...

Afin d'améliorer la qualité de service, la solution résidait en très grande partie dans la création d'une infrastructure IT apte à supporter des bus de données externes et des mediums de stockage bien plus adaptés. Par exemple la solution suivante est de nature à franchement améliorer la qualité de service:

  1. séparer le réseau de stockage du réseau standard
  2. passer le réseau de stockage et son infrastructure à 10 Gbits/s
  3. mettre en place des serveurs de stockage dédiés utilisant des SSDs et une petite partie de disques à plateaux

Quoi de plus normal que d'appliquer ces simples principes en 2019/2020 me direz-vous? He bien non... Il y a des aberrations qui existent encore, et encore plus étonnant au sein de sociétés d'ingénierie informatique, et à mon humble avis bien plus qu'on ne le croit. Vous savez... L'histoire du cordonnier qui est le plus mal chaussé... Il ya beaucoup de cordonniers dans l'IT, beaucoup trop!

Tout ceci pour démontrer quoi? A de maintes reprises, j'ai constaté que les problèmes de telle ou telle infrastructure étaient dûs à l'infrastructure de stockage: aux choix réalisés, au design, à l'architecture mise en place à ce niveau, ainsi que il faut bien le dire, à l'incompétence de certains.

Quels sont donc les principaux goulots d'étranglement au niveau du stockage?

En premier lieu dans le serveur lui-même, c'est la carte RAID. Vous pouvez mettre autant de SSDs que vous voulez en espérant obtenir un nombre d'Iops et une bande passante astronomique et qui augmente linéairement à chaque disque que vous rajoutez, ce n'est pas du tout ce qui se passe, surtout dans le cadre des SSDs. Les cartes RAID son en effet limitées elles-même par leur puissance de traitement et leur propre bande passante. Sur des serveurs HP et DELL récents (de gros serveurs estampillés "storage" achetés en 2019), j'ai pu mesurer que les 8 disques SSDs SAS 12 Gbits/s ne me donnaient "que" un maximum de 600 à 700 Mo/s en RAID6... Bof quoi...

Ensuite ce sont les bus de données, donc les réseaux, et leur débit de l'ordre de la dizaine de Gbits/s.

Enfin, c'est la nature même d'un SAN qui produit un réseau de stockage centralisé sur lequel tous les serveurs viennent se servir: toute ressource partagée entre plusieurs clients donne forcément moins de bande passante et de débit en fonction du nombre de clients qui utilisent la dite ressource.

Mais ce n'est pas tout. Parlons maintenant un peu du reste et notamment du coût.

Comme vous le savez, historiquement, le monde a confié ses données principalement à des solutions SAN vendues par différents constructeurs: NetApp, HP, DELL, EMC, Hitashi et j'en passe.

Encore très récemment, j'ai constaté un achat de 2 SANs HP 3PAR StoreServ d'une capacité utile de 190 To par SAN pour un montant, après réduction de 500k€. Il s'agissait de mettre un SAN dans chacun des deux datacenters et de les configurer en réplication. On obtient donc une capacité utile totale de 190 To, pour 500000€.

HP 3PAR StoreServ 8200, mai 2020
HP 3PAR StoreServ 8200

Au final, les performances des cartes RAID dans les serveurs ne suivent pas les performances cumulées des disques SSDs et vouloir s'approcher de cet état de fait abouti à un coût prohibitif et exponentiel.

De même le coût des SANs est encore plus prohibitif. J'ajouterais que les SANs n'offrent plus aujourd'hui assez de flexibilité, de performance et sont limités en terme de scalability. Là aussi plus ils sont gros, plus ils sont chers. C'est en plus une technologie littéralement "propriétaire" pour chaque constructeur.

Alors, quelles solutions de stockage finalement?

Fort heureusement, depuis quelques années, les GAFAs puis la communauté Open Source et diverses sociétés ont mené des réflexions pour repenser le stockage dans son ensemble, poussés notamment par les nouveaux besoin qui se sont fait jour avec l'avènement du monde des micro-services, du BigData et de l'Iot et des contraintes qui leur sont propres.

Ces solutions sont basées tout d'abord essentiellement sur une partie logicielle, et plus sur du matériel spécifique comme les cartes RAID et les SANs. Ces logiciels peuvent tourner sur n'importe quelle plateforme (ARM, AMD, Intel, ...) et sur n'importe quel serveur, ancien ou neuf, doté d'au moins un seul medium de stockage, disque dur ou SSD.

Ensuite ces solutions sont entièrement décentralisées et résilientes par nature. Elles sont aussi scalables à l'infini et de manière quasi-linéaire.

Enfin, leur coût est potentiellement beaucoup plus bas que les "vieilles" technologies encore utilisées aujourd'hui.

Je veux bien entendu parler des solutions de stockage objet. Il y en a quelques-unes et qui ne se valent pas toutes. Par exemple, on pourra citer:

et bien d'autres, mais celles ci-dessus sont bien connues et relativement largement déployées.

Si l'on prend le cas de CEPH, cela peut être une solution de stockage intéressante considérant qu'elle peut prendre en charge du filesystem, du stockage en mode Block, ou du stockage objet compatible S3. C'est la solution la plus polyvalente de toutes sur ce point là.

Et si l'on prend OpenIO, je pense qu'il s'agit là d'une des meilleurs solutions de stockage objet compatible S3 existantes à cette heure, en raison de ses performances, de sa scability infinie, de sa résilience et de sa passerelle mode block vers S3 permettant à n'importe quel serveur Linux d'avoir ses systèmes de fichiers XFS ou EXT4 dessus par exemple.

Ces solutions, basées sur des logiciels Open Source, n'ont besoin que de serveurs standards dotés de quelques disques durs ou SSDs en JBOD, c'est à dire connectés de manière "brute" et directe à la carte mère. Tous les traitements et toute l'intelligence de ces solutions sont déportés et résident dans le logiciel. La flexibilité est maximale, la portabilité aussi, et il n'y a pas de limites.

OpenIO a permis à des clients ayant de lourds besoins en stockage de ré-intégrer toutes leurs données on-premise tout en leur faisant réaliser 30 à 40% d'économies annuelles par rapport aux prix pratiqués par les GAFAs. En effet, les GAFAs veulent vos données: cela ne coute rien de les mettre dans leurs datacenter. Mais ensuite, cela coute cher d'y accéder et de les utiliser. On pourrait dire que c'est de la prise d'otage de vos données. Car les données, l'information de manière générale, c'est le nerf de la guerre, c'est le contrôle, et c'est surtout monétisable donc c'est de l'argent.

OpenIO toujours, a rendu sa solution utilisable sur processeur ARM: cela commence donc sur le Raspberry Pi. OpenIO a aussi développé un concept de micro serveur ARM attaché au dos de chaque disque dur, chaque couple ainsi formé pouvant prendre place dans un chassis de 4U composé de 96 de ces unités, pouvant atteindre 1.5 Po avec la capacité des disques durs actuels:

OpenIO Storage appliance, mai 2020
OpenIO Storage appliance
nano serveur ARM sur la frange du disque dur - Solution OpenIO., mai 2020
nano serveur ARM sur la frange du disque dur - Solution OpenIO.

La densité en terme de capacité de stockage est maximale, et la puissance de traitement aussi car cela revient à dire que chaque disque dur unitaire a son serveur dédié. Le coût annoncé par OpenIO pour un tel dispositif de stockage était de $0.008/Go/mois en 2017. Si je reprends l'exemple vécu des deux SANs HP 3PAR StoreServ ci-dessus, pour 190 To, le coût au Go revient à €2.56/Go à l'investissement. Mettons que ces SANs soient conservés 5 ans, cela donne un coût mensuel de €0.042/Go/mois, soit en dollars $0.047/Go/mois à la date d'écriture de cet article (référence: https://www.theregister.co.uk/2016/12/19/grab_yourself_an_armful_scaleout_storage_at_disk_drive_granularity/).

Dans ce cas précis, le stockage objet peut être jusqu'à 5.875 fois moins cher qu'une solution SAN. Autant dire qu'au rythme où la planète à besoin de Go de stockage, c'est extrêmement intéressant!

En conclusion:

Personnellement, je pense depuis deux ou trois années maintenant que les SANs sont aux stratégies de stockage IT ce qu'une voiture thermique diesel est en comparaison d'une voiture électrique TESLA (et je vous renvois à mes articles de blog sur ce sujet :-D): des dinosaures. C'est une ancienne technologie que les différents constructeurs tentent encore de faire vivre tout en restant sur leurs vieux acquis et en refusant de repartir d'une feuille blanche, tout en se servant allègrement dans le porte-monnaie de leurs clients.

C'est très cher, peu flexible, propriétaire, bref... dépassé.

Les solutions de stockage les plus performantes et les moins chères sont celles qui sont largement décentralisées: plusieurs serveurs peu chers, avec des processeurs AMD ou ARM (oubliez Intel), dotés de quelques disques connectés directement aux différents ports SATA présents sur la carte-mère, sans même passer par des cartes RAID dédiées, avec au moins deux interfaces réseau à 10 Gbits/s en Ethernet cuivre.

Mon avis est que le futur du stockage sera incontestablement décentralisé, flexible, presque insaisissable, résilient et redondant dans sa nature profonde. Il sera aussi peu cher comparé aux SANs.

Je pense qu'il est urgent d'accélérer le transfert des données des SANs vers les solutions de stockage objet, et qu'il faut mener une réflexion de fond sur le sujet de la prise d'otage de nos données par les GAFAs par la même occasion. En clair, les SANs, c'était bien... avant.

OpenIO, pour ne citer que lui, prouve tous les jours que ces clients réalisent des économies absolument substantielles en ayant abandonné le SAN d'une part, et aussi en s'étant rendu à nouveau maître de leurs données d'autre part en les conservant on-premise, donc chez eux. Il est vrai que tout le monde n'a pas forcément cette possibilité non plus...

Enfin, les développeurs d'applications doivent absolument prendre en considération ce mouvement par rapport aux technologies de stockage et ils doivent faire en sorte de les rendre compatibles objet/S3. Pour l'heure, beaucoup trop d'applications continuent d'être développées en laissant la gestion du stockage aux couches plus basses des systèmes de stockage, ce qui est de nature à ralentir l'adoption massive du stockage objet.

Quelques fournisseurs de solutions Objet mettent pour l'heure à disposition des passerelles très efficaces pour stocker les données des systèmes de fichiers conventionnels sous forme objet de façon transparente. OpenIO le permet par exemple. D'autres aussi. Il y a même un projet Open Source qui implémente ce type de passerelle: S3FS-Fuse.

Abandonnez vos SANs si et dès que vous le pouvez, leurs jours sont comptés, et privilégiez des solutions de stockage objet. Vous devriez y gagner sur plusieurs tableaux.