Tous les articles par dans Farid BENREJDAL

Et l’écologie ?

Il y a plusieurs moyens d’apporter sa contribution à rendre la planète moins polluée, que ce soit dans sa vie personnelle ou dans sa vie professionnelle.

Dans la vie professionnelle notamment en informatique le choix du matériel (serveur, stockage, switch, …) est important mais pas suffisant. En effet le logiciel a une part plus importante que le matériel à la fois sur la consommation énergétique directe induite par la consommation électrique des équipements (serveur, stockage, switch, … ) et sur la consommation énergétique indirecte induite par la climatisation pour diminuer la dissipation thermique.

Alors pourquoi le choix du logiciel a-t-il un impact plus importante que le choix du matériel ?

Le premier levier est la consolidation des composants du Data Center en les virtualisant (SDDC : Software Defined Data Center). L’hyperviseur de par ses algorithmes d’optimisation et notamment la mémoire, a le meilleur taux de consolidation du marché. Avec vSphere vous hébergerez plus de VMs sur un serveur physique qu’avec tout autre hyperviseur. Ainsi, dans le DC, il y aura moins de serveurs physiques, donc moins de connectiques réseaux, moins de connectiques stockage réduisant ainsi le nombre de switches réseaux et SAN. La consommation électrique est réduite, la dissipation thermique aussi, le DC peut-être plus petit.

En plus du fort taux de consolidation possible, les fonctionnalités intégrées à l’hyperviseur permettent également d’obtenir des gains de consommations. DPM (Distributed Power Management), DRS (Distributed Ressource Scheduler) et vMotion fonctionnent conjointement pour optimiser l’utilisation des ressources sur un minimum d’hyperviseurs. DPM va analyser la demande de ressource et définir combien d’hyperviseurs sont nécessaires pour honorer cette demande, s’il y a trop d’hyperviseurs, il va demander à vMotion de déplacer à chaud les VMs afin de les concentrer sur un nombre réduit d’hyperviseur, ceux qui se retrouve sans VMs seront arrêter physiquement. Si DRS se rend compte que la demande s’accroit et que les ressources risques de ne plus être suffisantes, il va demander à DPM de démarrer le nombre d’hyperviseurs nécessaires et à vMotion et de déplacer certaines VMs afin d’équilibrer les charges entres eux. Pour que cela fonctionne, les serveurs physiques doivent supporter l’un des protocoles suivants : IPMI, ILO ou WOL.

 

Grace à la virtualisation du réseau et de la sécurité, tous les trafics de communication Est-Ouest (trafics intra DC) qui représentent environ 80% du trafic total, se font sans passer par le coeur de réseau car les fonctionnalités de routage, switch et firewall sont directement intégrées dans l’hyperviseur. En évitant ainsi de passer par les équipements physiques (voir illustration ci-dessous), cela permet de réduire en nombre et/ou en taille ces équipements.

 

Et ceci peut encore être optimisé ! Grâce aux tableaux de bord vRealize Operations (vROps) :

Vous pouvez connaitre les VMs qui ont été déployées, démarrées mais pas ou plus utilisées. Elles consomment tout de même de l’espace de stockage et des ressources processeur et mémoire :

 

Vous pouvez lister les VMs déployées mais éteintes depuis un certain temps qui consomment de l’espace stockage :

 

 

Une étude IDC détaillée (en Anglais) explique les calculs qui ont permis de mesurer les gains obtenus grâce à la virtualisation de l’ensemble des composants du Data Center et elle estime que les solutions VMware ont permis d’économiser 450 millions de tonnes de CO2 depuis la création de la société VMware : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/company/vmw-data-center-energy-and-carbon-emission-reductions-through-compute-storage-and-networking-virtualization.pdf

Pourquoi PKS (VMware Pivotal Container Service)

Après les VMs, les containers, c’est autour des orchestrateurs de containers de rencontrer un vif succès, mais dans ce domaine les modes ont été éphémères, il y en a un qui sort son épingle du jeu c’est Kubernetes et cet engouement à l’air de s’installer. Je n’ai pas rencontré un client qui ne me parle de ça. Ils ne sont pas tous au même niveau de connaissance et d’appétence mais tous y vont, certes à tâtons car c’est un monde nouveau mais ils y vont. Pour être rassurés, les clients souhaitent se reposer sur des éditeurs pérennes, en qui ils ont confiance, qui ont des solutions robustes et un support fiable. C’est une des raisons pour laquelle PKS est rassurante.

PKS est une solution issue du partenariat entre VMware, Pivotal et Google où chacun apporte sa contribution. D’un point de vu macroscopique VMware apporte la partie registre des containers ainsi que la virtualisation du réseau et de la sécurité, Pivotal apporte la partie gestion du cycle de vie des cluster Kubernetes et Google son orchestrateur de containers kubernetes.

PKS ne modifie pas Kubernetes et n’apporte pas de surcouche ou d’interface intermédiaire. Le Kubernetes qui est utilisé n’est pas non plus un “fork” (une sous branche) mais belle est bien celui de Google, toutes les APIs et les lignes de commande ainsi que les applications que vous allez développer seront compatibles avec un Kubernetes hors PKS. A quelques semaines près vous aurez toujours la dernière version stable de Kubernetes qui sera supportée.

Lorsqu’il est hébergé sur le data center privé, PKS repose sur le SDDC (Software Defined Data Center) de VMware, il utilisera à minima les ressources vSphere et idéalement s’appuiera sur vSAN et NSX. Certains éléments de kubernetes seront surveillés est relancés par PKS, certains éléments de PKS quant à eux seront surveillés et relancés par vSphere HA. Grace à PKS, Kubernetes utilisera de manière transparente la partie stockage de vSphere pour le stockage éphémère ou pour le stockage persistant, lorsque vSAN est présent, les classes de stockage Kubernetes ou les volumes Docker pourront bénéficier des politiques de stockage de vSAN comme par exemple définition de la tolérance aux pannes (FTT). PKS couplé à NSX offre un vrai SDN et une sécurité accrue. Les fonctionnalités de routage, switching et sécurité sont intégrées et distribuées aux hyperviseurs ce qui offre de meilleures performances, une meilleure scalabilité et une plus grande sécurité.  Lorsque des pod Kubernetes sont déployés, les réseaux, les routeurs et les services tels que le load balancing sont automatiquement provisionnés. Les Network Policy utilisé par Kubernetes permettent de définir des règles de sécurités qui sont traduites par des règles de firewall NSX (des vraies pas des ACLs). Il est possible de définir des règles de sécurités inter Pod. Encore une fois c’est transparent pour le développeur, il a juste besoin de connaitre les commandes/API kubernetes et Docker.

 

 

Pour connaitre les flux réseaux, la fonctionnalité Traceflow permet de les visualiser entre deux composants parmi les critères suivants logical switch, VM, IP et MAC. 

Si des règles de sécurité firewall ont bloquées les communications, elles seront aussi affichées ce qui permettra de vite identifier quelle règle est en cause.

 

PKS permet de créer des cluster Kubernetes à la demande. Chaque cluster Kubernetes est indépendant et isolé, plusieurs versions de Kubernetes peuvent résider sur une même plate-forme mais aussi pour plusieurs usages, dev, tests, pré-prod, … ou encore plusieurs “tenant” (colocation. Si vous possédez un portail self service tel que vRA (vRealize Automation), vous pouvez proposer un blueprint Kubernetes As A Service et offrir à un développeur ou à une équipe de développeurs de provisionner de manière automatisée des cluster Kubernetes.

PKS permet de gérer le cycle de vie complet des cluster kubernetes et de ses composants allant de l’installation, des mises à jour, de l’application de patches et le “scaling” du cluster, le tout à chaud.

 

PKS intègre un registre des containers privés (Harbor) pour y déposer vos images que vous ne souhaitez pas mettre sur un registre public. Il intègre une gestion des rôles d’accès (RBAC). Harbor peut scanner les images à la recherche de vulnérabilités, signer les images et répliquer les images sur un autre registre de containers. 

 

Si vous utilisez vROps (vRealize Operations) vous aurez la possibilité de surveiller vos clusters Kubernetes ainsi que l’infrastructure qui l’héberge et avoir ainsi des corrélations de performance et d’incidents.

 

 

Pour monitorer le fonctionnement des applications et/ou les métriques métiers comme par exemple le nombre de transaction par seconde, vous pouvez utiliser WaveFront :

 

 

Pour résumer les avantages de PKS :

  • Dernière version stable de Kubernetes natif de Google, même lignes de commandes, même API. Pas de surcouche !
  • Gestion complète du cycle de vie de Kubernetes, installation, mise à jour, application de patch et scalabilité.
  • Kubernetes As A Service, des cluster Kubernetes à la demande indépendant et isolé.
  • Utilisation du SDDC VMware permettant d’avoir un environnement Kubernetes résilient, performant et sécurisé.
  • Provisionnement automatique et natif de load balancer, réseaux, règles de sécurité et niveaux de service stockage.
  • Possibilité de monitorer l’infrastructure complète et les applications.

 

Les avantages non techniques :

  • Gain de temps en formation et en développement : les développeurs non que Kubernetes et Docker à connaitre.
  • Risques réduits : PKS est supportée par VMware et repose une plate-forme SDDC sécurisée.

Pour plus d’information https://cloud.vmware.com/fr/pivotal-container-service/resources

Pour la tester : http://labs.hol.vmware.com/HOL/catalogs/lab/4249 

C’est gratuit ! ?

€€€€

Combien de fois j’ai entendu cette phrase : Hyper-V et OpenStack c’est gratuit ! ? des centaines de fois, ou encore VMware c’est le top mais ça coute cher.

Certe les solutions VMware ont un coût, il est induit principalement par la recherche et développement et par la valeur ajoutée qu’elles apportent. La cherté subsiste s’il n’y a pas de valeur constatée. Pour faire un comparatif objectif, il faut prendre en compte toute la chaine de coûts et non pas seulement la partie CAPEX (acquisition) des licences, il faut intégrer la partie OPEX (opérationnelle) et tous les autres paramètres induits. Il existe beaucoup d’études comparatives qui démontrent la réalité des choses, je vais lister ici les éléments de ce qui m’a été remonté par mes clients.

Sur la partie hyperviseur :

  • vSphere a la meilleure densité VM par serveur sans compromettre sa stabilité. Sur un serveur ça peut-être paraître négligeable mais sur un grand nombre ça ne l’est plus. Un serveur a bien sûr un coût mais aussi, prend de la place en salle machine, consomme de l’énergie électrique et en climatisation, il consomme occupe aussi des ports réseau et éventuellement SAN. Les applications avec une tarification à la CPU nécessitent moins de licences.
  • vSphere à un noyau léger et stable, il consomme très peu stockage et subit très peu de panne ce qui induit beaucoup moins d’incidents à gérer.
  • Les opérations d’administration du quotidien prennent moins de temps, déplacement à chaud de VMs, déploiement de nouveaux hyperviseur, configuration réseau et stockage
  • vSphere fonctionne comme une ferme d’hyperviseur où toutes les ressources sont fédérées, mutualisées, l’équilibrage des charges se fait automatiquement et libère tu temps à l’administrateur pour qu’il se consacre à des tâches plus gratifiantes.

Sur la partie Cloud, on me mettait souvent en compétition avec les solutions Open Source comme OpenStack, il y a quelques années elles avaient le vent en poupe, c’est beaucoup moins le cas maintenant. Les arguments étaient, c’est gratuit et ce n’est pas vendor lock-in. Dans les fait ce n’est pas le cas, force est de constaté, ce qui n’est pas dépensé chez un éditeur doit l’être en ressource humaine pour développer et maintenir toute l’automatisation déjà présente dans les solutions payantes. Quelques exemples de ce qui est à développer sur OpenStack et qui est natif dans vRA (vRealize Automation) :

  • L’installation de vRA est beaucoup plus simple, en quelques heures on a un cloud opérationnel.
  • Nativement vRA intègre de la gouvernance basée sur des “Policies” (qui à le droit de faire quoi), des workflows d’approbation, les baux d’expirations, tout le cycle de vie d’un déploiement, un designer graphique de blueprint, …

Bref rien n’est gratuit, tout à un prix, tout à un coût. Il faut faire des comparaisons en prenant en compte toute la chaine et identifier les éléments qui ont de la valeur pour vous.

Pourquoi VMware

VMware fait partie des rares sociétés informatiques qui proposent à ses clients des solutions qui permettent un retour sur investissement rapide, palpable et mesurable.

Dès la première solution : la virtualisation des serveurs x86, il y a eu un retour sur investissement matériel et opérationnel. En faisant fonctionner simultanément plusieurs serveurs virtuels sur un seul serveur physique, on économise sur le nombre de serveurs physiques et de switches réseau, sur le câblage, sur la consommation électricité, et de climatisation, l’espace salle machine …

VMware investit énormément en recherche et développement pour faire évoluer ses solutions existantes, en créer de nouvelles ou encore en intégrer des nouvelles par acquisition.

VMware aurait pu rester uniquement dans le domaine de la virtualisation où elle était (et l’est encore) leader mais elle a préféré investir aussi dans d’autres domaines tels que le Software Defined Data Center, les containers, la sécurité, le cloud hybrid et la mobilité.

Les solutions sont en général reconnues comme leader dans leur segment et sont fiables.

VMware est une société pérenne avec des solutions pérennes intégrant les dernières technologies, les investissements faits par ses clients sur ces solutions sont eux aussi ainsi pérennisés et évolutifs.

Pourquoi VMware Cloud On AWS (AKA VMC)

VMC on AWS c’est le SDDC (Software Defined Data Center / Data Center logiciel) de VMware hébergée sur les infrastructures physiques d’AWS. Elle permet d’avoir un Data Center agile et programmable sans avoir à le gérer. Lorsqu’il est couplé à un Data Center privé on obtient un réel Cloud Hybrid, c’est à dire une administration centralisée commune des deux, la possibilité de migrer à chaud et à froid les workloads de l’un vers l’autre, de synchroniser les templates de VMs et d’étendre les réseaux (niveau 2 et 3) afin d’avoir le même plan d’adressage. La condition minimale pour avoir un cloud hybrid est d’avoir au moins l’hyperviseur vSphere sur son Data Center privé, sinon on n’a juste un cloud public SDDC VMware hébergé chez AWS (et c’est déjà très bien).

 

Je ne vais pas aborder les avantages du Cloud Public et du SDDC, je pars du principe qu’ils sont connus. Cependant, je vais aborder les points de vigilance auxquels ont fait face certains de mes clients :

 

  • Pour être efficient, il faut connaître l’architecture de l’infrastructure sous-jacente (réseau, stockage, serveur, sécurité, …).
  • Il faut que l’application soit développée en intégrant dans son design la prise en compte de panne des différents éléments constituant l’infrastructure.
  • Pour les applications existantes, il faut transformer les VMs car elles n’auront surement pas le même format.
  • Intégrer un nouveau model opératoire pour lequel il faut prévoir, de nouveaux outils d’administration à acquérir et à connaître, de nouveaux scripts d’administration à écrire ou à adapter, de nouvelles compétences à recruter et former celles existantes.
  • Appréhender une nouvelle gouvernance et de nouvelles règles de sécurité.
  • Il faut prévoir un retour arrière, les intérêts que vous avez trouvé à un hébergeur (notamment tarifaires) peuvent ne plus correspondre dans le futur.

 

Quels sont les principaux avantages techniques que trouvent les clients à utiliser VMC, notamment ceux qui ont déjà une infrastructure à base de vSphere ?

 

  • Une infrastructure qui leur est dédiée, donc une plus grande sécurité car elle n’est pas partagée par d’autres clients et des performances prédictibles car ce sont uniquement ses propres applications qui y fonctionnent.
  • Pas de besoin de transformer les VMs et les applications, le format et le même que sur les hyperviseurs vSphere de leur Data Center privé.
  • Une réversibilité, du fait d’avoir le même format, s’ils changent d’avis ils peuvent (re)transférer leurs VMs sur leur Data Center privé.
  • Un mode opératoire et des compétences identiques à ce qu’ils ont pour leur environnement vSphere sur leur Data Center privé, les investissements antérieurs sont ainsi pérennisés.
  • Être au plus proche des services AWS. Si vos applications hébergées sur votre Data Center privé ont besoin d’accéder aux services AWS, elles doivent passer par Internet ou par un lien direct connecte et les trafics réseaux sortants d’AWS vous seront facturées. Lorsqu’elles sont hébergées sur VMC, elles sont au plus proche des services AWS, vous allez gagner en performance et leurs échanges ne seront plus facturés.

 

Comment bénéficier de VMC et qui contacter en cas de problème ?

 

  • Au moment de la rédaction de cet article, le seul moyen d’y bénéficier et de passer par vos contacts VMware habituels. 
  • En cas d’incident, quel qu’y soit, VMware est votre interlocuteur unique.

 

La création du SDDC hébergé chez AWS, se fait directement via le site de VMware en l’associant à un compte et à un VPC AWS.

 

Contrairement à un Cloud Public, vous n’achetez pas de VMs ou des services applicatifs mais bien des ressources physiques bénéficiant du SDDC de VMware, le minimum pour démarrer c’est un cluster de quatre hyperviseurs puis si besoin des incréments d’au moins un hyperviseur. Un hyperviseur vient avec ses processeurs, sa mémoire et sa capacité de stockage. La tarification est basée sur le même principe.

Les cas d’usages constatés sont ceux d’un Data Center classique plus ceux qui figurent dans le schéma ci-dessous :

 

Les avantages non techniques constatés sont :

  • Ne plus avoir à gérer les acquisitions d’infrastructure bas niveau, le cycle de vie, la gestion des changements, les opérations de maintenance, la formation du personnel.
  • Libérer du temps et du budget aux services plus proche des métiers de l’entreprise.
  • Un accroissement de l’agilité, désormais un projet peut démarrer de zéro en quelque heures et adapter ses besoins en ressources en quelques minutes si nécessaire.
  • Être libre de choisir son hébergeur et d’y changer si besoin.
  • Récupérer les budgets qui auraient dû être alloué à la transformation applicative, à la formation et à l’adaptation d’outils.
  • Diminuer les risques, en utilisant une plate-forme au comportement connu et maitrisé.
  • Garder la gouvernance habituelle.

Pour plus d’information, je vous invite à visiter le site de VMware sur ce sujet : https://cloud.vmware.com/fr/vmc-aws

Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

vSAN est une solution stockage qui utilise les médias de stockage internes (Disque dur, SSD, NVME, …) de plusieurs hyperviseurs formant un cluster pour qu’ils soient vus par chacun comme un seul espace de stockage partagé.

vSAN a été conçu pour simplifier l’utilisation du stockage et diminuer les coûts opérationnels et d’acquisition. En effet contrairement aux solutions classiques vSAN ne nécessite pas de compétences pointues et de matériels dédiés spécifiques.

Pourquoi est-il important d’avoir besoin d’un espace de stockage partagé par plusieurs hyperviseurs ?

  • Les VMs sont constituées de fichiers persistants, pour qu’elles puissent s’exécuter sur l’ensemble des hyperviseurs il faut que ceux-ci puissent y accéder.

Quelles fonctionnalités de vSphere ont le plus besoin d’un stockage partagé ?

  • High Availability (HA) : Assure la haute disponibilité des VMs et ses applications. Si l’hyperviseur qui exécute la VM subit une panne, la VM est redémarrée sur un autre hyperviseur.
  • Distributed Resources Scheduler (DRS) : Réparti les charges (VMs) entre les hyperviseurs de façon à optimiser l’utilisation des ressources.
  • vMotion : Fonctionnalité qui permet de déplacer à chaud une VM d’un hyperviseur à un autre de façon préventive. Par exemple lors des opérations de maintenance pour éviter des interruptions de service.
  • Fault Tolerant : Une VM est exécutée sur un hyperviseur et les instructions (mémoire, CPU) induites sont envoyées simultanément sur un autre hyperviseur. Si l’hyperviseur qui effectue l’exécution subit une panne, l’autre hyperviseur active la VM immédiatement, il n’y aura pas d’interruption de service.

 

Avec des solutions de stockage traditionnelles, les administrateurs créent plusieurs espaces de stockage en fonction de leur capacité de stockage, de performance et de résilience.

Pour respecter le niveau de service requis par les applications, l’administrateur doit connaître les capacités de ces différents espaces de stockage.

Pour simplifier tout ça, vSAN ne créé lui qu’un seul espace de stockage et bénéficie d’une fonctionnalité intéressante : les politiques de stockage. L’administrateur les créés en fonction du niveau de service souhaité (niveau de tolérance aux pannes, de performance, de réservation, …).

Lorsqu’il crée une VM, il affecte à celle-ci la politique de stockage souhaitée et c’est ensuite l’hyperviseur qui s’assure que la VM sera stockée correctement afin de respecter ce niveau de service.

Si vous utilisez un portail self-service tel que vRealize Automation, celui-ci sera capable aussi d’affecter automatiquement la politique de stockage attendue à la VM à déployer.

Les politiques de stockage de vSAN apportent de la souplesse et un gain de temps non négligeable qui pourra être utilisé à autre chose.

vSAN est directement et complètement intégré dans l’hyperviseur, il ne nécessite pas d’installation. L’administration se fait comme pour l’hyperviseur, directement via le client web de vSphere.

vSAN est la brique principale des offres HCI (Hyper Convergence Infrastructure) qui consiste à créer un cluster de ressources comprenant des serveurs physiques, du stockage interne, un hyperviseur, un logiciel de virtualisation du stockage et de virtualisation du réseau.

Elle peut être « consommée » sous plusieurs formes différentes :

  • Dans des « Appliances Constructeur » comme par exemple VxRAIL ou VxRACK (il en existe d’autres chez plusieurs constructeurs). Le constructeur se charge d’effectuer l’ingénierie d’intégration et assure le support de l’ensemble.
  • Chez les cloud publics : AWS, IBM, OVH, ATOS et bien d’autres. Ici la constitution du cluster de ressources se fait à la volée, l’administrateur choisi le nombre d’hyperviseurs et un configurateur se charge d’interconnecter les serveurs entre eux, installe et configure la partie logicielle.
  • Directement sur vos hyperviseurs à base de serveurs compatibles vSAN Ready Node. Ici tous les composants ont déjà été validés par le constructeur.
  • Sur vos serveurs existants, dans ce cas Il y a un point de vigilance à prendre en compte si vous voulez que la solution fonctionne correctement. Il faut s’assurer que la carte contrôleur des médias, le média de cache et le media de capacité figurent bien dans la matrice de compatibilité.

J’ai des clients dans chaque cas de figure :

  • L’utilisation du modèle Appliance concerne des clients qui ont une certaine maturité et qui ne souhaitent plus avoir à gérer les installations de serveurs et des logiciels mais consacrent leur temps aux besoins plus proches des métiers.
  • L’utilisation du cloud public concerne des clients qui ne veulent plus du tout gérer d’infrastructures physiques et logiciels. Avoir vSAN dans le cloud public permet d’avoir le même mode opérationnel que sur le cloud privé, avec une définition des niveaux de service au travers des politiques de stockage.

Je vous conseille de bien répartir les serveurs dans des racks différents et de créer des « Fault Domain », comme illustré dans l’exemple ci-dessous : une VM est bien sûr stockée sur deux hyperviseurs différents mais surtout dans deux racks différents. Ainsi, si vous perdez un rack complet la VM restera malgré tout accessible. Le placement inter rack est automatique, la seule chose que l’administrateur est amené à faire c’est de définir l’appartenance de chaque hyperviseur à un rack donné.

Ce qui fait aussi la force de vSAN c’est son évolutivité, vous démarrez avec au minimum trois hyperviseurs et vous évoluez en fonction de vos besoins. Vous avez de nouvelles applications à héberger ? Vous ajoutez un hyperviseur (cela se fait à chaud) et votre cluster se retrouve avec plus de ressource processeur, mémoire, stockage et IOPS.

Autre point important si vous avez des sites distants, magasins, usines, agences ou autres qui ne nécessitent pas beaucoup de ressources, vous pouvez partir sur une configuration à deux hyperviseurs. Ces sites sont plus simples à déployer : juste deux serveurs !

Si vous avez des contraintes de licences avec un certain éditeur, grâce à vSAN et son espace de stockage partagé uniquement par les membres d’un cluster, vous pouvez affecter les licences de cet éditeur à ce cluster, et comme le stockage est « étanche », les autres hyperviseurs ne pourront pas accéder aux VMs.

Si vous avez des contraintes de sécurité, sachez que l’espace de stockage vSAN peut être crypté.

Si vous avez besoin de disponibilité, pas de souci, suivant la définition des politiques de stockage vous pouvez perdre un ou plusieurs hyperviseurs ou encore un site complet (configuration stretched cluster).

Dans l’illustration ci-dessous la VM est à la fois protégée sur le site local et sur le site distant, de manière à ce qu’une panne d’un hyperviseur n’entraine pas une bascule distante. Le witness sert d’arbitre en cas de rupture totale des communications inter-sites, les données générées par les VMs ne sont jamais envoyées au Witness.

Vous pouvez aussi augmenter cette disponibilité en ajoutant une réplication sur un troisième site en général beaucoup plus éloigné.

Je n’aborde pas toutes les fonctionnalités comme, la déduplication, la compression ou encore la possibilité de limiter les IOPS, ça serait trop long.

Comme son utilisation est transparente, vSAN ne se cantonne pas à un seul cas d’usage, mes clients l’utilisent comme du stockage traditionnel et ce pour tout type d’application, A titre d’exemple, le premier client vSAN Français a commencé avec un petit périmètre pour de la sauvegarde et maintenant l’utilise pour l’ensemble de ses environnements virtualisés en mode stretched cluster (cluster réparti sur deux sites éloignés de quelques kilomètres à des fins de résilience). Résultat : il ne possède plus de baie de stockage !

Les gains : le coût, la simplicité, la résilience et la performance.

Si je résume :

  • Rien à installer, tout est dans l’hyperviseur.
  • Pas de compétences spécifiques requises.
  • Plus besoin de baie de stockage et de réseau SAN, on utilise les médias internes.
  • Un seul et unique espace de stockage pour un cluster d’hyperviseur.
  • Niveau de service défini par des politiques de stockage.
  • Évolutivité verticale (ajout/retrait de média de stockage) ou horizontale (ajout/retrait d’hyperviseur).
  • Résilience locale ou par site.
  • Configuration deux hyperviseurs pour sites distants.
  • Large support de constructeurs et d’acteurs de cloud public.

Si vous souhaitez en savoir plus sur vSAN :