Avec les infrastructures hyper-convergentes, on franchit un saut quantique dans le domaine de la convergence. C’est bien joli tout ça, mais à quoi ça sert exactement ?


L’infrastructure convergente est un concept qui a vu le jour à la fin des années 2000, développé par des fournisseurs d’infrastructure désireux de proposer des environnements serveur, stockage ou réseau construits de façon plus homogène, et managés de façon plus unifiée pour les plus chanceux. Avec une infrastructure convergente, le client pouvait réduire ses coûts (rien de neuf sous le soleil) grâce à une plus grande standardisation des composants, à un management simplifié, et accessoirement à des procédures d’installation et de déploiement plus rapides que lorsqu’on déploie des composants hétéroclites.

Quoiqu’aient pu être les arguments marketing des uns et des autres, les frontières entre les silos serveur, stockage et réseau n’étaient pas réellement tombées, chaque produit restant dans la convergence de son propre silo. Mais çà c’était avant…. C’était l’époque où le software-defined-anything n’était encore que l’ombre d’une idée…

Les  archéologues de l’IT pensent que l’ère de l’hyper-convergence remonte à la fin de l’année 2012, lors de  l’annonce de l’appliance HC3 par Scale Computing. Finis les produits qui convergent tout seuls dans leur silo ! L’idée est de proposer une solution complète intégrant les composants serveurs, stockage et réseau dans une même appliance pour les uns, et une solution purement logicielle chez les autres, agnostique sur les composants d’infrastructure. Le monde merveilleux de l’hyper-convergence s’ouvre à nous.

Fini les architectures de stockage hiérarchisé  SAN

Avec l’hyper-convergence, fini les architectures de stockage hiérarchisé  SAN ! Tout repose sur des boîtiers incorporant leurs propres disques DAS, et de préférence SSD.  Le File System distribué permet de créer des pools de stockage regroupant les unités de stockage de plusieurs serveurs. On fera appel à des logiciels additionnels pour assurer la déduplication, la réplication, la résilience, et plus si affinités.

Les premiers fabricants à monter dans le train de l’hyper-convergence ont été Scale Computing, rapidement suivi par Nutanix qui modernise son offre Complete Cluster, puis SimpliVity et son Omnicube, bâti sur l’offre VMware.  IDC, dans son étude « IDC MarketScape: Worldwide Hyperconverged Systems » parue en décembre 2014, met nos trois pionniers en bonne place de son classement. 

Dans cette première analyse IDC a analysé les 7 offres figurant dans son tableau, et mentionne que les offres d’HP, de NIMBOXX et Compuverde n’ont pas pu être intégrées dans cette étude.

On retrouve d’un côté les offres « appliances » proposées par Nutanix, SimpliVity ou Pivot3. Et de l’autre, les offres  « software-designed »  que l’on trouve chez EMC, Maxta, et VMware. Ces derniers vont plutôt proposer des architectures de référence destinées aux VAR’s et SI’s qui construiront une solution clé en main adaptée aux besoins de chaque client.

VMware distribue EVO: RAIL à travers de multiples fournisseurs OEMs, par exemple Dell qui propose une architecture de référence autour d’ EVO: RAIL, mais aussi un produit à base de Nutanix !  HP distribue le HP ConvergedSystem 200-HC EVO:RAIL (une version VMwarisée de l’appliance StoreVirtual VSA), DataCore Software et Gridstore ont également des produits hyper-convergés et des solutions de référence, et EMC vient de renforcer son offre avec l’annonce de VSPEX Blue. 

Ce qui rend les solutions hyper-convergées techniquement réalisables, c’est la mise en œuvre de produits « software-defined », en particulier du « software-defined storage » particulièrement crucial pour créer et provisionner à la volée des pools de stockage répartis sur plusieurs boîtiers. Nos amis de VMware viennent d’ailleurs d’annoncer VMware VSAN V6, une version « full flash » de leur solution de virtualisation du stockage.

Les avantages des appliances

Sans réelle surprise, par rapport aux solutions « software-defined », les appliances seront plus rapides à mettre en œuvre – en quelques dizaines de minutes –  et peut-être plus simples à administrer du fait d’une intégration plus profonde avec les composants matériels.  L’évolutivité par scale-out (plutôt qu’en mode scale-up) est plus naturelle, il suffit juste d’ajouter des appliances supplémentaires. Reste à vérifier l’augmentation linéraire –ou pas- des performances lorsque le nombre d’appliances dépasse la cinquantaine d’unités !!!

Côté support, l’avantage d’un fournisseur unique pour la totalité des composants réduit singulièrement le nombre d’interlocuteurs qui se renvoient la balle en cas de problème….

Les limites des appliances

La granularité de croissance est fixe, elle se fait par adjonction d’une boîte complète (serveurs, stockage et réseau). Si vous souhaitiez uniquement gonfler votre capacité de stockage, too bad : vous aurez dû acquérir également de la puissance de calcul. 

Lorsque vous avez à faire fonctionner plusieurs applications avec des profils d’usage différents (forte consommation de CPU pour l’une, fort débit d’IOPS pour l’autre, ou haute capacité de stockage pour la 3ème) comment faire avec de configurations parfois trop standardisées ? Cette approche est opposée à celle des cartouches spécialisées Moonshot, avec des configurations dédiées pour tel ou tel workload.

Randy Bias, dans un billet rédigé sur le blog de CloudScaling, dénonce également des risques de sécurité et de management des appliances.

Laissons-lui la parole :

« Avec une infrastructure hyper-convergée, en raison de la confusion entre plan de contrôle et plan de données, il est impossible de créer des partitions entre les zones d’un système disposant chacune de polices de sécurité différentes […]. Une intrusion réalisée n’importe où peut se traduire par une pénétration complète du système.  C’est pourquoi, par exemple, la spécification PCI vous oblige à segmenter le réseau entre votre base de données et le reste du système. Ce qui est très difficile, voire impossible, à réaliser dans un système hyper-convergé. »

Sur le management, Randy remet le couvert :

« Lorsque vous disposez de plusieurs nœuds, le problème du management distribué est souvent résolu en ayant le logiciel de management sur un seul nœud à la fois. Ce noeud est sélectionné à l’aide d’un processus d’élection du système maître.  Mais le problème avec un système d’élection de maître est qu’il y a un seul maître à la fois, le logiciel d’administration fonctionnant sur la même boîte que des machines virtuelles lambda et des unités de stockage. Si vous manquez de puissance parce que vous n’avez pas suffisamment de ressources, il n’y a qu’une solution: mettre à niveau le nœud maître. Mais si celui peut changer d’appliance à tout moment, la seule solution consiste à upgrader toutes les appliances. » Nos lecteurs férus de physique quantique – et je sais qu’il y en a parmi vous – n’auront pas manqué de faire le parallèle avec le principe d’indétermination d’Heisenberg.

Quelles applications ?

La vraie question est finalement celle de l’usage. Quelles sont les applications cibles pour lesquelles l’hyper-convergence apporte un intérêt substantiel, et à l’inverse quelles sont celles qui pourraient pâtir de plates-formes hyper-convergentes ?

La banalisation des infrastructures et l’aplatissement des couches de stockage (réduites à du DAS) font immédiatement penser aux white-boxes des géants du cloud, et même aux machines-types pour tourner des applications Hadoop. Le besoin de scalabilité de ces workloads trouve une bonne réponse dans le scale-out très normalisé que suggère l’utilisation d’appliances hyper-convergées.

Si à l’origine, le domaine d’usage de plates-formes hyper-convergées se concentrait sur le VDI, certains fournisseurs n’hésitent plus à mettre en avant leurs solutions hyper-convergées pour héberger des applications business comme SAP ou Oracle.  Cette vision n’est pas partagée par tout le monde, et la « converged infrastructure » traditionnelle n’est pas à jeter aux orties.  Notre ami Randy Bass propose l’arbre de décision Converged Infrastructure vs. Hyper-Converged Infrastructure suivant :

Arbre_de_dcision_Converged_Infrastructure_

À vous de déterminer quel est le meilleur choix. Encore une fois, l’Hyper-Convergence de l’Infrastructure ne va pas balayer définitivement les solutions «simplement » convergentes.

Pour terminer et vous laisser méditer sur le sujet de la convergence, je laisserai le dernier mot à Jacques Lacan qui disait (Ecrits 1966) : « mais dans l’unité interne de cette temporalisation, l’étant manque la convergence des ayant été ».

Rien de plus à ajouter.

 

L’auteur :

Philippe Roux a effectué la plus grande partie de sa carrière chez Digital Equipment puis, à partir de 1999 chez HP où il a exercé successivement les fonctions de Microsoft services marketing manager, outsourcing marketing manager, HP services solutions marketing manager, Enterprise solutions marketing manager et Cloud marketing manager. Depuis avril 2014, il s’occupe en tant que consultant de l’animation des communautés IT du CRIP (Club des Responsables d’Infrastructures et de Production) et en tant que membre fondateur de CDO Alliance, l’association des chief digital officers.

Cette tribune a été publiée initialement sur Cloud Experience, le blog des experts du Cloud, dont il est contributeur actif.