ekzman - Fotolia

Non, le Software Defined Storage n’est pas un caprice !

Le SDS est une réponse à la transformation des applications métiers. La migration vers le SDS ne se fera donc pas sur un effet de mode, mais sur des analyses de coût, de performance et de risque sérieuses.

Cet article se trouve également dans ce contenu premium en téléchargement : STORAGE: Avantages et coûts cachés du Software Defined Storage

Si le matériel a toujours été important dans la conception d’une baie de stockage, nous savons tous depuis longtemps que la vraie valeur ne réside pas dans ce matériel.

Elle provient pour l’essentiel du logiciel embarqué dont la mission est de fournir les services avancés qui permettent de garantir la sécurité des données mais aussi d’en optimiser le coût de stockage et d’en faciliter l’administration.

D’une certaine façon ce que l’on appelle aujourd’hui le Software Defined Storage (SDS) est un pléonasme. Car le stockage a toujours été une question de logiciel.

Seul problème, ce logiciel était dans la majorité des cas embarqué dans le matériel et son usage strictement contrôlé par son fournisseur.

Mais les temps changent.

Le verrou qui liait matériel et logiciel est en train de sauter et l’on est en train de voir émerger une multitude de solutions, chacune offrant un spectre fonctionnel bien différent et répondant donc à des besoins spécifiques.

Le SDS : des visages multiples

On peut, pour schématiser, regrouper les « combattants » actuels en plusieurs catégories distinctes.

La première est celle des baies de stockage « logicielles » ou virtuelles. Elles sont le fruit de l’abstraction des OS de stockage SAN/NAS des baies bi-contrôleurs du marché et permettent de fournir, à partir d’un serveur ou d’une VM, l’équivalent des services d’une baie de stockage bi-contrôleurs d’entrée/milieu de gamme.

Parmi les solutions dans cette catégorie, on peut citer des produits tels que EMC Virtual VNX, NetApp OnTap Edge, Nexenta NexentaStor, StarWind vSAN ou un produit libre comme FreeNAS – ces deux derniers s’appuyant sur le système de fichiers ZFS créé à l’origine par Sun Microsystems.

La seconde catégorie est celle des solutions de stockage distribué SAN ou NAS telles EMC ScaleIO, Red Hat Storage, HP StoreVirtual, EMC Isilon Edge SD ou Storpool, qui permettent à partir de serveurs chargés de disques durs (et de SSD) de créer un système de stockage à grande échelle dont les performances et la capacité augmentent avec le nombre de nœuds.

La troisième est catégorie, plus établie, est celle des outils de virtualisation de stockage comme IBM Spectrum Virtualize, Hitachi SVOS, Citrix Melio, Falconstor FreeStor, Datacore SAN Symphony (ces trois derniers pouvant aussi servir à la constitution de systèmes de stockage SAN distribués et/ou hyperconvergés).

La quatrième est celle des fournisseurs de systèmes de stockage hyperconvergés comme VMware vSAN, Nutanix, Simplivity, Atlantis, SpringPath, dont les solutions ont historiquement été packagées sous forme d’appliances, mais qui de plus en plus proposent aussi des versions purement logicielles de leur technologie.

La cinquième est celle des fournisseurs de systèmes de stockage objet comme Cleversafe, Scality, Cloudian, Red Hat (Ceph), SwiftStack, dont l’objectif est de fournir un stockage sûr et bon marché pour les données non structurées de l’entreprise.

Enfin, ce tour d’horizon rapide serait incomplet sans mentionner les solutions visant à séparer le stockage des données lui-même de la gestion des politiques de stockage comme VIPR d’EMC ou comme l’initiative Data Fabric de NetApp (même si ces produits ou initiatives sont encore récents et incomplets).

Face au SDS, les solutions traditionnelles et les organisations font de la résistance

On le voit, pour tout type de besoin, il y a aujourd’hui une réponse possible via une solution SDS. Cela signifie-t-il la fin à court terme des baies de stockage telles qu’on les connaît aujourd’hui ?

La réponse est bien entendu négative.

Tout d’abord parce que les baies de stockage bi-contrôleurs utilisées par nombre d’entreprises ne déméritent pas. Dans bien des cas, elles remplissent parfaitement le rôle qui leur est assigné, en particulier dans les PME, qui n’ont souvent pas besoin d’infrastructures massivement distribuées (acteurs du web ou du e-commerce mis à part). Loi de Moore aidant, il n’y a aucune raison pour que les baies traditionnelles bi-contrôleurs ne continuent pas à répondre aux besoins des PME.

Il ne faut pas non plus sous-estimer le fait que l’assemblage d’une solution de stockage sur mesure combinant matériel et logiciel requiert de l’expertise. Expertise que les PME n’ont pas forcément et qui complique un peu plus la pénétration des solutions de SDS dans ces entreprises.

Enfin, nombre de fournisseurs sont prêts à des remises conséquentes pour éviter l’exode de leurs clients. On voit sur le marché des remises allant de 35 % à 90 % qui suppriment les gains financiers immédiats promis par les solutions SDS. En fait sur ce marché des PME et des grosses PME, ce sont sans doute les solutions hyperconvergées qui sont la principale menace pour les baies traditionnelles.

Dans les grandes organisations, c’est souvent l’inertie qui est le principal obstacle à l’adoption du SDS. Dans nombre de DSI, spécialistes stockage, spécialistes réseaux et administrateurs systèmes continuent à évoluer dans des équipes séparées. Problème, la mise en œuvre de systèmes SDS performants nécessite leur regroupement dans des équipes pluridisciplinaires, ce qui prend du temps et nécessite parfois de ménager quelques susceptibilités.

Le volume de données stocké dans les grandes baies des grands constructeurs est aussi tel, que toute migration vers des solutions de stockage massivement distribuées ne peut s’envisager que dans le cadre de plans de migration mûrement réfléchis et planifiés – d’autant que chaque migration de stockage a un impact sur la disponibilité de multiples applications.

La migration vers le SDS ne se fera donc pas sur la base d’un caprice, mais sur des analyses de coût, de performance et de risque sérieuses.

Le SDS : une évolution inévitable née de la transformation des applications et de la pression du cloud

A mon sens toutefois cette évolution est inévitable. Tout simplement parce que l’infrastructure des datacenters va devoir s’adapter à l’évolution des applications.

La nature des applications d’entreprise évolue. Les applications monolithiques historiques et la première génération d’applications web trois-tiers, cèdent progressivement la place à une nouvelle génération d’applications distribuées dites « cloud native » conçues avec des technologies « webscale ».

Et qui dit applications webscale, dit nécessité de bâtir une infrastructure distribuée bâtie sur des modèles proches de ceux des grands offreurs de Cloud, sous peine de voir ces applications quitter le giron des datacenters d’entreprise pour finir sur les cloud d’Amazon, Microsoft, Google, IBM ou Oracle.

Le portrait typique du stockage de grand compte d’ici quelques années risque donc fort d’être composé de trois grandes couches de stockage.

Tout d’abord, une couche persistante rapide (Flash ou technologie plus avancées type PCM, Memristor…), locale aux serveurs et gérée par une solution de SDS plus ou moins distribuée, afin de répondre aux applications les plus sensibles à la performance (applications transactionnelles massives, analytique/Big Data, simulation et calcul hautes performances, etc).

Pour les besoins SAN/NAS intermédiaires (ceux de la plupart des applications) seront satisfaits par une seconde couche de stockage massivement distribuée,fournie par une infrastructure serveur hyperconvergée ou par une solution SAN/NAS distribuée.

Enfin, les besoins de stockage de masse et d’archivage seront gérés par une solution de stockage objet délivrant à un coût au gigaoctet faible des services objets et des services NAS plus traditionnels.

Le lien entre ces différents étages de stockage sera effectué par une couche fournissant des services riches et des mécanismes de gestion de politiques capables d’orchestrer les mouvements de données entre les différentes couches, mais aussi de gérer les politiques de réplication et de protection de données.

Cette couche sera largement logicielle et interfacée avec les couches d’orchestration Cloud.

Dernière mise à jour de cet article : mars 2016

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close