Transition entre les infrastructures traditionnelles et le Cloud natif avec l’hyper-convergence

Par défaut

Par Emmanuel Forgues 

Voir le profil d'Emmanuel sur LinkedIn

Transition entre les infrastructures traditionnelles et le cloud natif avec l’hyper-convergence (VCE, Nutanix, Simplivity)

Cet article est la suite de l’article sur la place de l’Hyper-convergence dans la problématique du DevOps : « L’hyper-convergence (Nutanix, Simplivity, VCE) et les entreprises ensemble face au paradigme du DevOps. »

Bien qu’incontournable, l’infrastructure représente un coût important (qu’il soit direct ou indirect) dans les budgets des sociétés. Dans le même temps, les technologies utilisées dans les infrastructures traditionnelles sont de plus en plus matures alors que le cloud ne l’est pas encore assez aux yeux des entreprises. Cette différence entre deux approches oblige les entreprises à reconsidérer et à optimiser leurs infrastructures et donc leurs investissements.

 En juin 2016 le Laboratoire National de l’Université de Berkeley a publié une excellente étude qui explique et annonce la réduction de 75% des serveurs dans les entreprises en 2020. Bien que cette évolution soit en marche, comment l’appréhender et l’anticiper ?

Les principaux arguments sont l’augmentation de la puissance des serveurs capables de faire tourner un nombre grandissant de services (virtualisation, containers, …) et des services de plus en plus grand dans les clouds.

Selon cette étude, depuis 2014, nous constatons (confère l’étude, diagramme ci-dessous) le changement d’orientation entre l’infrastructure traditionnelle (current Trends) et les environnements Clouds (Hyperscale Shift)

Si nous reprenons le diagramme et en regardant la courbe d’évolution du « Non-Hyperscale », en 2020 il faut s’attendre à une perte d’environ 75% de serveurs.

(hyperscale représente les Clouds des grandes entreprises : MSFT, AWS, Google,… quand les non-hyperscales sont DC ou les Clouds dits privés)

Dans le même temps, il faut s’attendre à une croissance d’environ 20% des environnements clouds.

Cette perte de 75% de serveurs ne va pas se retrouver dans les environnements cloud comme un simple transfert des serveurs d’un environnement vers un autre. Il y a l’optimisation qui consiste à mutualiser les services sur les serveurs mais aussi l’évolution technologique. Les environnements Hyperscales sont en acquisition de nouvelles technologies alors que les environnements « Non-Hyperscale » sont en décroissance, ce qui explique en partie cette différence.

Sans aborder la problématique énergétique mondiale causée par l’informatique et tous les moyens de communication, l’étude montre la part grandissante de consommation d’énergie pour l’infrastructure, le stockage et les serveurs. (Confère ci-dessous le diagramme extrait de la même étude).

Les problèmes énergétiques sont un des moteurs du changement dans le choix d’infrastructure pour les systèmes d’informations. La virtualisation a été la première étape à éviter une explosion peut-être exponentielle du nombre de serveurs. L’étape suivante consiste à regrouper l’ensemble de ces besoins énergétiques en une et une seule technologie. Les promesses de l’Hyper-convergence est à mi-chemin de la promesse du Cloud en ce sens.

Cette différence est visible en faisant le lien entre ces deux précédents diagrammes :

  • réduction des serveurs (75%) associée à la réduction possible d’énergie dans les infrastructures restantes dans les entreprises (non-Hyperscale)
  • Augmentation énergétique associée à la faible augmentation en infra des solutions Hyper-scale (+21%) par rapport à la récupération des serveurs des solutions non-Hyperscale (75%?).

Même si la tendance montre une nécessité de changement, pour justifier des acquisitions il faut continuer de pouvoir les justifier par rapport à un service générant des revenus pour l’entreprise. Toutes les entreprises ne font pas face aux problèmes de DevOps mais doivent répondre dans tous les cas à l’équation : Ajuster les ressources pour un service aux utilisateurs dans une logique de business d’entreprise en réponse à un marché à acquérir ou à consolider.

Lors de nouvelles acquisitions, les DSI cherchent :

    • de la flexibilité
    • la capacité de supporter des environnements hétérogènes
    • le contrôle des composants
    • une intégration dans un système hardware ou applicatif existant
    • une montée en charge non prévues
    • des mises à jour (patchs ou nouvelles fonctionnalités) continuellement
    • mise à disposition « self-service » d’environnements (un grand nombre de petits environnements de travail)
    • garantir la continuité des services dans l’ensemble
    • garantir l’interopérabilité des mêmes services
    • l’agilité de l’infrastructure
    • la performance correspondant au cahier des charges des services
    • un contrôle des couts

Pour le développeur utilisant ces infrastructures que son travail (code) ne doit pas avoir d’emprise sur l’environnement de travail et être transparent par rapport à la localisation de son travail. Ce qui est déjà en soit un changement considérable.

Les infrastructures traditionnelles offrent des évolutions toujours constantes pour proposer de la performance. Ces dernières souvent s’appuient sur de nouvelles technologies (nouveaux processeurs, nouveaux type de disque, nouveaux protocoles, …) mais doivent toujours permettent la continuité et interopérabilités des services entre eux. Même si le prix est un élément important venant des contraintes financières, ce dernier et la densité (impact prix aussi sur les couts indirects) viennent s’ajouter dans l’équation du processus de décision d’acquisition.

Tel un père au prétendant de sa fille quadragénaire, secrètement désireux de la voir quitter le domicile parental à l’approche de sa retraite, les nouvelles technologies arrivent toutes avec des promesses. Faire converger dans le moins de densité possible : le prix, la puissance de calcul (computing), le stockage, le réseau, la virtualisation pour les services et avec la simplicité d’intégration aux besoins actuels et futurs. S’il fallait représenter les tendances, nous pourrions représenter la courbe de la maturité des technologies traditionnelles (TT) et celle de la maturité du cloud.

Ces deux technologies avec deux courbes de maturités différentes vont se croiser à un moment notable dans l’histoire de l’infrastructure de l’entreprise. Nous appelons cela aussi un «virage technologique» à prendre ou à rater.

Dans notre cas, il faut tenir compte d’un réajustement de la courbe de maturité des technologies traditionnelles avec l’arrivée d’une nouvelle approche lui donnant un second souffle (une séquence à cycle de vie double).

En rouge : séquence à cycle de vie double de la courbe de l’infrastructure traditionnelle des entreprises

En vert : courbe de maturité de l’approche «Cloud»

Etape 1 : phase d’adoption et de maturité des infrastructures traditionnelles. Apparition d’une nouvelle approche «cloud».

Etape 2 : phase de renouvellement mais en optimisant (refonte possible de l’infrastructure)

Etape 3 : le rebond par l’optimisation sur des solutions innovantes (en rupture ou non)

Etape 4 : Adoption des environnements cloud représente par l’intersection des deux tendances

A : point de maturité des infrastructures traditionnelles

B : point de rupture avec un rebond en s’appuyant sur une nouvelle technologie (par exemple l’hyper-convergence)

C : prolongation ou rupture vers les environnements clouds

D : point d’interception des infrastructures traditionnelles avec le cloud sans le rebond de l’hyper-convergence

En considérant les technologies actuelles (sections 1 et 2) et en y ajoutant un composant supplémentaire (hardware ou software, point B) les technologies traditionnelles entrent dans une séquence à cycle de vie double (section 3). Le marché appelle ce second souffle la convergence ou l’hyper-convergence.

C’est la phase 3 qui m’intéresse le plus parce qu’il me semble que nous sommes en train de la vivre. Nous avons une infrastructure actuelle et des besoins qui s’orientent vers le cloud sans trop savoir comment le faire. Le point C est le résultat des promesses de ces nouvelles technologies. C’est en phase 3, qu’il faut se poser les bonnes questions au sujet des promesses des acteurs proposant de nouvelles technologies et au point C ou nous avons la réponse … ou la terrible sanction. 

… l’évolution c’est aussi de sauter dans le bon bocal :

Phase 3

La phase 3 va être clé pour celui qui est le premier à faire le pas ou à changer de bassin sans trop savoir ce qu’il va y trouver.

Pour ceux qui ne mènent pas cette démarche, il suffit d’attendre l’obligation de migrer vers le cloud mais en poursuivant ses investissements dans le traditionnelle. Cette solution est rassurante et permet de rester en contrôle de tous les composants techniques, financiers et humains. Elle a aussi l’avantage de ne pas essuyer les plâtres pour les autres. Elle a bien évidemment des avantages comme des désavantages.

La suivante consiste à se montrer précurseur et de participer aux solutions de demain tout en acquérant des compétences précieuses pour le futur. Pour l’instant l’adoption de cette approche reste timide soit à cause des limitations techniques, sécuritaires, ou pour des aspects financiers ou légaux. L’adoption inconditionnelle du tout cloud n’est pas pour aujourd’hui …

L’approche la plus probable est d’anticiper avec des technologies qui répondent aux problématiques actuelles et capables de s’inscrire dans la prochaine étape à moindre couts. Cette phase d’optimisation de l’infrastructure trouve écho aux promesses des solutions d’Hyper-convergences … à condition que les investissements soient pérennes et permettent d’aborder le virage sereinement.

emmanuelforguesEmmanuel Forgues est diplômé de l’EPITA (promo 97) en spécialité système et Réseaux et récemment diplômé de Sciences Politique Paris en stratégie Internationale et accompagnement du changement. Emmanuel possède une vue globale en s’appuyant sur plus de 20 années d’expérience dans les start-ups, grandes entreprises et les éditeurs. Ces années sur différents domaines (avant-vente, product manager, stockage, sécurité ou réseaux) lui confère de fortes connaissances techniques. Spécialisé aujourd’hui dans la création, l’accompagnement et la montée en puissance des réseaux de distribution en Europe du sud.

Pour suivre Emmanuel et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Emmanuel Forgues Voir le profil de Emmanuel Forgues

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Atlantis USX – Storage is Software

Par défaut

Atlantis USX – The New Order of Storage Freedom

Atlantis est une solution purement Software, elle fournit une solution de stockage par logiciel (100%), du pur SDS ! Atlantis USX Unified Software-Defined Storage est une solution intelligente de stockage définie par logiciel. Elle peut fournir instantanément des ressources de stockage pour toute application utilisant plus efficacement une infrastructure classique existante et permet de renforcer ou de faire évoluer cette infrastructures vers des solutions hyper-convergées.

En exploitant la puissance de traitement (calcul, mémoire et flash) plus rapide et moins cher, Atlantis USX élimine les inefficacités et les contraintes des solutions de stockage legacy (traditionnel) du SAN et du NAS matériel. Atlantis USX 3.1 optimise le stockage et améliore les performances pour supporter les workloads tels que les applications critiques, stockage de fichiers, VDI, SBC, et sur n’importe quel hyperviseur.

USX supporte VMware, vSphere et Citrix XenServer.

La solution Atlantis est en cela très intéressante car elle propose conjointement une couche de virtualisation, à laquelle il est possible d’ajouter de nouvelles fonctionnalités au stockage existant (VVOL), et de proposer une solution complète SDS Software-Defined Storage.

Atlantis permet de mettre en commun et de proposer une abstraction du stockage (NAS, SAN et DAS) afin de créer des volumes destinés aux applications VM, VDI… La solution offre également de nouvelles fonctionnalités comme le HA, la déduplication, la mise en cache, la compression…

Atlantis solution est aujourd’hui distribuée sous forme d’appliance virtuelle OVF. La phase d’installation et de configuration est relativement simple, elle nécessite uniquement une bonne compréhension de certains concepts de base.

Atlantis USX 3.1 GA est sortie le 16 octobre 2015.

AtlantisUSX_myvmworld

 

Atlantis Computing propose à ses clients deux approches très simples. La première permet de s’intégrer dans un environnement virtualisé et de consolider le stockage existant. La seconde permet de fournir directement sous forme d’appliance hyper convergée (HyperScale), une infrastructure complète et Full Flash. Les deux approches utilisent le même logiciel, le même moteur : Atlantis USX.

hyperscale_Myvmworld

Comment fonctionne Atlantis ?

Atlantis introduit une couche logicielle entre l’hyperviseur et les machines virtuelles afin de fournir une file d’attente optimisée permettant, grâce à une déduplication en ligne (réalisée par les appliances virtuelles) de réduire la latence des I/O, mais également de réduire la capacité de stockage nécessaire aux machines virtuelles consommant le Datastore présenté par Atlantis.

Une fois l’OVF téléchargé et déployé sur l’infrastructure virtuelle, Atlantis USX déploie de manière automatisée deux types de machine virtuelle : les Volumes VM et les Services VM. Ces deux machines virtuelles sont fondamentalement différentes car elles possèdent des rôles bien distincts.

La flexibilité et la souplesse du logiciel permet à Atlantis de pouvoir proposer plusieurs types de volume en fonction du cas d’usage.

  • Hyper-Convergé (Hybrid ou All Flash),
  • Hybrid,
  • In-Memory,
  • All Flash,
  • Simple Hybrid, Simple In-Memory, and Simple All Flash.

USX volume comparison table-Myvmworld

Volume VM

Le volume VM est une machine virtuelle (Ubuntu) entièrement autonome possédant toute l’intelligence d’Atlantis : déduplication en ligne, compression, réplication, cloning, snapshot, etc. Elle représente le cœur de la solution et permet de présenter un Datastore à l’hyperviseur.

Cette machine virtuelle, va exporter au travers du réseau, le Datastore sous deux protocoles NFS ou iSCSI.

Du point de vue des machines virtuelles, le Datastore USX est perçu comme un DataStore partagé et les lectures / écritures se font directement au travers de ce Datastore.

Atlantis_myvmworld

Architecture HCI

Service VM

Les services VM sont utilisés afin de pouvoir distribuer la couche de « back end » des volumes VM au niveau de plusieurs hyperviseurs. La donnée est donc répartie sur les différents hyperviseurs grâce au service VM, l’accès au Datastore se fera toujours au travers du Volume VM.

USX components_myvmworld

Source: https://help.atlantiscomputing.com/usx3

Pour les volumes de type Hyper-Converged (Hybrid ou All Flash), hybride, et en mémoire, Atlantis déploie aussi sur chaque hôte une VM appelée Service VM. Ces Services VM permettent d’exporter des ressources locales sous-jacente à l’hyperviseur (RAM, mémoire flash locale, DAS, JBOD, SSD) de chaque hôte et d’agréger ces ressources en un pool virtuel. Chaque service VM peut servir plusieurs volumes.

Chaque service VM peut exporter jusqu’à deux des ressources suivantes :

  • mem (RAM uniquement).
  • DISK (DAS seulement).
  • FLASH (flash local uniquement).
  • mem + disque (RAM + DAS).
  • mem + flash (Flash RAM + local).

 Deduplication In-line In-Memory

La Volume VM va procéder une déduplication en ligne sur des blocs de données fixes de 4KB (< 200 microsecondes de latence par opération IO). Avant d’écrire sur le système de fichier embarqué en mémoire (DedupFS), les données en écriture sont segmentées en block de 4KB. L’algorithme propriétaire d’Atlantis permet d’identifier si un bloc de données de 4KB est déjà présent ou non dans le système de fichier. A partir de son algorithme, Atlantis utilise un mécanisme de Hash (MD5 HASH) qui couvre un domaine de collision de 91 ExaByte par volume pour 0,0001% de probabilité. 

deduplication_myvmworld

Si celui-ci n’est pas présent, un nouvel inode est créé dans le DedupFS, la table de blocs est mise à jour, une nouvelle entrée est créé et  identifiée de façon unique, ce block (en mémoire) est copié sur le tiers de performance (SSD, PCIe Flash, RAM). Les inodes, ainsi que la table des blocs, sont copiés sur le tiers de performance, puis l’acquittement est envoyé au niveau de l’application. Si en revanche le bloc de 4KB est déjà présent dans le système de fichier, ce bloc de 4KB n’est pas copié sur le tiers de performance, il est acquitté immédiatement, après que les metadata (inode + reference count) soient mises à jour et copiées sur le tiers de performance, le tiers de performance jouera le rôle de Write Caching et de Read Buffer.

La déduplication est construite à partir d’un journal en trois dimensions :

  • 1 pour les métadonnées dedup,
  • 1 pour les blocs Rewired,
  • 1 pour le système de fichiers (DedupFS).

La déduplication est implémentée par volume, elle n’est pas globale.

x-lzma-compressed-tarLes données sont compressées à partir d’un algorithme de compression sans perte LZMA, et ensuite écrites sur le tiers de performance, la compression favorise la croissance du facteur de déduplication.

L’algorithme utilisé est propriétaire et protégé par les brevets US 8996800 B2 / US 8874877 B2 / US 8732401 B2 / US 8874851 B2 /US 8868884 B2.

 

Atlantis USX dispose d’une façon unique d’exploiter la mémoire disponible à l’intérieur des Hyperviseurs pour fournir un stockage performant et optimisé. En tirant parti des ressources de la RAM (un des composants les plus performants du serveur), Atlantis USX peut effectuer en temps réel, la déduplication Inline, la compression et l’écriture. Chacune de ces fonctions réduit la quantité de données consommée, d’accélérer les IOPS et surtout de diminuer la latence.

 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Hyper-Convergence – le nouveau visage du Datacenter

Par défaut

L’hyper-convergence : un buzz ? un phénomène de mode ?

L’hyper-convergence est-elle en train de modifier le paysage de nos Data centers et de nos salles informatique ? Intéressons nous à une technologie qui n’a pas fini de faire parler d’elle …BuzzMeter

Mais c’est quoi l’Hyper-convergence ?

L’Hyper-convergence est une architecture basée sur le logiciel qui s’intègre étroitement avec les ressources de calcul, de stockage, de réseau et de virtualisation. Le tout, embarqué dans une boîte, c’est le « All-In-One« . L’Hyper-convergence est donc un nouveau modèle d’infrastructure.

Mais pourquoi en sommes-nous venus à ce modèle ?

Back_to_the_Future.svgPetit retour en arrière… Souvenez-vous de « 1980 » c’était la période de la première démonstration du NAS (serveur de stockage en réseau). Puis, dans les années « 90 », est apparu le SAN (Storage Area Network). Cette technologie avait pour objectif de répondre aux problèmes d’évolution de la volumétrie des données et des performances. Cette architecture était basée sur la constitution d’un réseau performant dédié aux entrées/sorties avec des périphériques de stockage. Ce réseau était totalement indépendant du réseau classique.

Le SAN avait donc été créé pour offrir de la rapidité et du volume de stockage à notre système d’information qui, à l’époque, était construit sur des mainframes. En « 1989 », est apparu dans nos salles informatiques (salle blanche pour reprendre les termes de l’époque) des serveurs x86 (SystemPro). C’est à partir de ce moment que les serveurs x86 ont pris une place prépondérante dans notre SI. Serveurs ayant également eu besoin de volumétrie et de performance et sur lesquels ont donc été greffé le même stockage de type SAN que pour nos mainframes.

Très vite il a été constaté qu’un serveur sur six serait inutilisé dans le monde et dans certains Datacenters. L’utilisation des serveurs atteindrait péniblement 5 à 15 % de leur ressource de calcul et de mémoire. Ainsi, 85 à 95 % des ressources système étaient inexploitées et les salles des serveurs encombrées de machines sous-exploitées.

McKinsey_report

Source: McKinsey analysis: Utilization measurement tool

En conclusion, un datacenter est aujourd’hui utilisé à 56% de son potentiel selon une étude McKinsey et Uptime (Corporate Average Data Efficiency CADE).

Partant de ce postulat, la virtualisation s’est avérée une technologie incontournable et est devenue la pierre angulaire du SI.

infrastructure classique

Lorsque les projets de virtualisation sont apparus, il a fallu construire des architectures virtuelles reposant sur des serveurs x86 et du stockage, hérité de notre patrimoine SI, à savoir du SAN et/ou du NAS.

Les projets d’aujourd’hui ne cessent de prendre de l’ampleur et des objectifs à atteindre de plus en plus ambitieux, à savoir  :

  • réduire et maîtriser les coûts d’acquisition (CAPEX),
  • améliorer et optimiser la gestion de ces environnements (OPEX),
  • réduire le time-to-market,
  • être plus agile, plus souple face aux demandes du métier.

Comme évoqué dans un précédent article, le SDDC (Software-Defined Data Center) est là pour répondre à ces nouveaux enjeux et satisfaire les équipes d’infrastructure.

Afin de faciliter la mise en oeuvre du Data Center piloté par le logiciel, est apparu un nouveau modèle : l’HyperConvergence (HCIS).

L’origine de l’HyperConvergence

L’idée de reproduire ce que font certains acteurs du web tel que GAFA (Google-Amazon-Facebook-Apple) paraît et semble une nouvelle voie d’architecture pour nos data center.

GAFA-myvmworld

Tous ces acteurs ont été confrontés très rapidement, au vu de leur évolution, à des problématiques d’infrastructure et d’architecture dans un Data Center traditionnel. Dans un Data Center traditionnel, le modèle de fonctionnement est en effet basé sur une infrastructure serveur, baie de stockage partagée, réseau SAN.

Cette architecture semblait donc peu compatible avec le modèle de ces géants du web ou les besoins sont exponentiels en terme de volumétrie de stockage.

size_myvmworld

Les architectures traditionnelles nécessitent d’être « sizées », « désignées » par rapport à un besoin précis, définit dans le temps. Très souvent, elles sont taillées sur trois, voir cinq ans en prenant en compte le besoin à l’instant « t » et en se projetant sur cette période. Au moment du renouvellement de leur maintenance un choix doit être opéré vers un nouveau modèle plus novateur et donc un changement de gamme.

L’inconvénient dans cette approche c’est qu’elle ne peut pas s’appliquer à ces mastodontes du web car leur nombre d’utilisateur croit de façon exponentielle.

Inconcevable financièrement et du point de vu de son administration ! Les équipes auraient du passer un temps trop important à re-configurer le Data Center afin de supporter la montée en charge des utilisateurs.

Les acteurs du web vont alors inventer une nouvelle façon de fonctionner. Ils vont capitaliser sur leur savoir faire : le développement. Le hardware n’étant pas leur métier de prédilection, ils vont créer un équipement matériel le plus basic qui soit; CPU, MEM, stockage qui seront identiques les uns aux autres. Le but : multiplier ces configurations pour augmenter la puissance de calcul et la capacité de stockage simultanément.

Chacun de ces serveurs est ainsi conscient de l’existence de ces voisins afin qu’ils puissent se protéger conjointement.

Pour fédérer l’ensemble de ces serveurs, va être rajouter une couche de logiciel. Cette couche intelligente basée sur le logiciel va tout simplement « clusteriser » les serveurs, les rendre conscients de l’existence de leur voisin. A chaque fois qu’une donnée sera écrite quelque part, elle sera protégée sur le reste du Cluster.

HCIS_SDS_Myvmworld

Cette façon de penser « architecture du Data Center » souvent nommée « web-scale IT » répond ainsi aux problématiques de mise à l’échelle SCALE-OUT. Grâce à cette innovation technologique, nous pouvons étendre un Cluster à l’infini sans jamais être confronté à des problèmes de performance ou de capacité.

L’incrément dans ce modèle est un serveur complet (CPU + stockage).

Toutes les sociétés ne sont pas Google ou FaceBook (même si je leur souhaite le même succès), toutefois, dans l’univers de la virtualisation, nous sommes souvent confrontés à la même problématique.

La virtualisation a tellement simplifié la façon de provisionner les workloads qu’aujourd’hui nous avons multiplié le nombre de machines virtuelles (VMs). Beaucoup plus rapidement que les architectures physiques. Nous sommes donc confrontés à des problématiques de mise à l’échelle, et ce, beaucoup plus rapidement qu’il y a dix ans lorsque la virtualisation n’en était qu’à ses débuts.

D’où l’idée de certains player tels que Nutanix XCP (Xtrem Computing Platform), Simplivity (OmniStack 3.0), ou encore Pivot3 … de proposer cette même logique de web-scale IT pour le monde de la virtualisation et uniquement pour les VMs. D’autres on aussi embrayé le pas à ces player, et notamment Atlantis Computing qui, avant de proposer une solution de type scale-out, a développé une solution d’optimisation de stockage, (SCaleIO EMC, HP VSA, VMware EVO:RAIL, Nimboxx…).

HCIS

La plupart de ces solutions embarquent une VM sur chaque noeud (Hyperviseur+serveur+CPU+MEM+Stockage), cette VM fait office de contrôleur de stockage et embarque toute l’intelligence logicielle. On retrouve ainsi des fonctionnalités de type : compression, déduplication, tiering, réplication… Sauf pour EVO:RAIL où la gestion du stockage et des données est gérée par VSAN qui est inclus dans le Kernel de l’Hyperviseur.

Evolution & Tendance du marché de l’HyperConvergence

Lire la suite

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook