Catégorie dans Générale

vSphere avec Kubernetes

VMware vSphere with Kubernetes connu sous le nom de projet Pacific a été annoncé à VMworld US 2019. Il fait partie des nombreuses nouvelles fonctionnalités de vSphere 7. Au moment de la rédaction de cet article il est encore en Beta mais j’ai eu l’occasion de l’installer à plusieurs reprises et de faire une dizaine démonstration internes et à des clients. Le retour des profils administrateur d’infrastructure et des profils de développeur sont positifs, la solution est bien accueillie et ils y trouvent une vraie valeur ajoutée dans leur métier respectif.

Le message de valeur mis en avant par VMware est la faculté à l’hyperviseur d’héberger nativement des pods kubernetes et des VMs proposant ainsi une plate-forme unique. Les hyperviseurs vSphere forment un cluster Kubernetes où ils jouent le rôle de worker node Kubernetes (serveurs qui exécutent les pods applicatif). Le control plane est quant à lui sous forme de VMs. Aucune compétence Kubernetes n’est requise pour l’administrateur vSphere, tout est intégré et configuré automatiquement. Pour avoir installé plusieurs fois Kubernetes, je peux vous dire qu’avoir une plate-forme prête à l’emploi est un vrai gain de temps au moment de l’installation et lors du maintien en condition opérationnel.

 

C’est vrai qu’héberger nativement des pods Kubernetes c’est une innovation unique mais personnellement, je me mettrai plutôt en avant la capacité de cette plate-forme à provisionner des cluster Kubernetes à la demande en une seule ligne de commande kubectl et ce directement par le développeur. Il pourra aussi bénéficier toujours via la commande kubectl des services de loadblancer, de volumes de stockage persistants, de réseau et des règles de sécurité et ce sans avoir à configurer quoique ce soit. D’autres fonctionnalité comme la création de VM ou de services applicatifs lui seront aussi offertes.

 

vSphere with Kubernetes peut être divisé en deux parties logiques, l’une pour la partie infrastructure et l’autre pour la partie développement (Namespace et Managed Cluster). La partie infrastructure est gérée par l’administrateur vSphere avec ses outils habituels et l’autre par le développeur ou encore par le DevOps avec ses APIs ou la commande habituelle kubectl.

 

 

 

 

L’administrateur vSphere créé des Namespace via son interface habituelle, il autorise quelles sont les personnes qui auront le droit de consommer ces Namespace, indique quelle classe de stockage à utiliser et si besoin, affecte des quotas aux ressources mémoire, CPU et stockage. Ca prend à tout casser 2 minutes. Une fois cette opération terminée, le Namespace est prêt à consommer. Le Namespace apparait automatiquement comme projet dans la registry privée Harbor ainsi que les utilisateurs associés.

Le développeur se connecte au Namespace et peut immédiatement y déployer des Pods Kubernetes.

kubectl vsphere login –server 10.40.14.33 -u devops@vsphere.local –insecure-skip-tls-verify

S’il le souhaite, il peut aussi y créer lui-même d’autres cluster Kubernetes via la commande Kubernetes kubectl apply, s’il veut par exemple une version de cluster différente :

$ cat CreateCluster-guest.yaml
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: l-oeil-du-se
  namespace: projets
spec:
  topology:
    controlPlane:
      count: 1
      class: guaranteed-xsmall
      storageClass: projectpacific-storage-policy
    workers:
      count: 2
      class: guaranteed-xsmall
      storageClass: projectpacific-storage-policy
  distribution:
    version: v1.16.8
  settings:
    network:
      cni:
        name: calico
      services:
        cidrBlocks: [“10.43.0.0/16”]
      pods:
        cidrBlocks: [“10.44.0.0/16”]

Ces clusters apparaissent aussi dans l’interface graphique de l’administrateur vSphere

 

Et aussi en ligne de commande

$ kubectl get TanzuKenertesCluster
NAME         CONTROL PLANE WORKER DISTRIBUTION                  AGE
l-oeil-du-se 1             2     v1.16.8+vmware.1-tkg.3.60d2ffd 5m

 

Le développeur peut faire évoluer la taille de son cluster en modifiant le nombre de master et/ou de worker directement en changeant la configuration de son cluster via la commande kubectl.

$ kubectl get TanzuKerbernetesCluster
NAME          CONTROL PLANE WORKER DISTRIBUTION                   AGE
l-oeil-du-se  1             3      v1.16.8+vmware.1-tkg.3.60d2ffd 109m

 

Les pods, les volumes persistants, les network policy et les services sont directement visible par l’interface vSphere :

 

En résumé, vSphere with Kubernetes (Projet Pacific) est une plate-forme permettant d’héberger nativement des pods (containers) kubernetes, des VMs et des clusters Kubernetes à la demande, offrant ainsi la possibilité de concilier les exigences de sécurité, de performance, de résilience et d’évolutivité souhaitée par l’administrateur de l’infrastructure et les exigences d’agilité, de rapidité et de simplicité souhaitée par le développeur. Cette plate-forme peut héberger une application complète même si elle est composée de VM et de containers. Les investissements en terme financier et de compétence sur la plate-forme vSphere sont ainsi pérennisés.

Les développeurs et les administrateurs continuent à utiliser leurs outils habituels avec lesquels ils sont à l’aise tout en travaillant sur une même plate-forme.

Cette plate-forme unique évolue en fonction des besoins en VM et en container. Les développeurs bénéficient de l’automatisation, de l’agilité et la souplesse qu’ils trouvent sur le cloud public et les administrateurs n’ont pas à gérer la complexité de gestion du cycle de vie inhérente à Kubernetes. C’est du Kubernetes as a Service intégrant les services de loadbalancing, de volumes persistants, de réseau et de sécurité.

Le Cloud Hybrid comble les inconvénients du Cloud Public

C’est un constat personnel que j’ai fait, dans certains secteurs d’activité notamment là où c’est économiquement très tendu comme dans la distribution ou l’industrie, il y a une plus grande appétence au cloud public. Ils ont mis en place une stratégie Cloud Public First ou Cloud Public Only. Quand je pose la question à mes interlocuteurs habituels quelle est la raison de cette stratégie, la réponse est souvent la même, ça vient d’en haut, de la direction informatique et/ou des finances. En effet un gros contrat signé avec l’un des trois acteurs du Cloud Public à savoir Amazon pour AWS, Microsoft pour Azure ou Google pour GCP, promettant de faire de grosses économies financières. Les opérationnels eux, ne sont pas consultés dans cette décision mais ont tout de même la charge de devoir mettre en place une campagne de migration massive pour suivre cette stratégie.  Pour la majorité de ces entreprises cette stratégie est récente, d’autres ont été précurseurs et cela permet d’avoir un peu de recul sur les bénéfices et les déficits qu’elle apporte :

  • L’aspect économique doit être scruté à la loupe car il y aura des mauvaises surprises, c’est sûr. Les éléments à prendre en compte :
    • Le gabarit des machines virtuelles. Un certain gabarit de machine virtuelle en ressource processeur et mémoire sera plus favorable au Cloud Public. Ce gabarit permet à l’hébergeur de faire fonctionner un nombre optimal de machine virtuelle sur un hôte physique et donc mieux amortir le coût de la machine physique. Alors que d’autres gabarits seront plus favorables au cloud privé. Il faut bien vérifier le coût du gabarit à migrer avant de faire le transfert.
    • La saisonnalité. Si votre application a des saisonnalités comme par exemple en période de solde, elles vont nécessiter des ressources physiques à la hausse durant cette période puis à la baisse une fois cette période terminée. L’élasticité native présente dans le Cloud Public évite des investissements en matériel et en logiciel d’infrastructure pour une utilisation périodique faible.
    • La périodicité. Si des environnements peuvent fonctionner sur une plage horaire partielle comme par exemple, la journée ou la nuit, ils permettent de payer l’infrastructure uniquement durant ces périodes d’utilisation et non pas tout le temps comme ça serait le cas sur un environnement On-Premise.
    • Les flux réseau. Les flux entrants vers le cloud public sont gratuits par contre les flux sortants sont dans la plupart des cas facturés, c’est un élément à prendre en compte si vous avez des échanges inter application ou si vous devez faire des exports de model de données volumineux.
    • Les services additionnels. Certains services comme une adresse IP publique ou encore des load balancer peuvent être commander (donc payés) à la demande puis associés à des VMs. Lorsque que la VM est détruite, les services associés ne sont pas “décommissionés” pour autant et continueront à être facturés.
    • Pour éviter les surprises il faut se doter d’un outil (eg : CloudHealth) qui vous donnera une visibilité pertinente de la consommation à l’instar d’un tableau de bord d’un d’avion. Il proposera ainsi des économies en identifiant les ressources mal, peu ou pas utilisées.
  • L’aspect services à valeur ajoutée comme l’intelligence artificielle ou le machine learning apportent un bénéfice indéniable car ce genre de service est difficile à obtenir On-Premise.
  • L’aspect agilité est là aussi un point fort au cloud public, avoir des ressources à la demande et les libérer quand on en a plus besoin.
  • L’aspect couverture géographique international est intéressant mais ne pourra pas se faire avec un hébergeur unique car pour des raisons réglementaires et/ou politiques, les trois acteurs principaux ne sont pas présents dans certains pays comme en Russie.

Il y a plusieurs possibilités pour aller dans le cloud public, il faut soit développer ses applications directement dessus, soit avoir une application basée sur des containers pour les transférer sans les retoucher, mais pour les autres qui sont la grande majorité des cas, il faudra les transformer. En effet il y a une forte chance que le format des VMs qui hébergent les applications dans vos Data Center On-Premise soit différent de celui des VMs du cloud public, il faudra donc les transformer. Il existe des outils pour les transformer mais ils fonctionnent correctement que si ce sont des applications simples.

Une fois que vous êtes dans le cloud public, êtes-vous sûr d’y rester ? Que faire si les coûts d’hébergement augmentent ou si les éditeurs des applications changent leur mode de tarification lorsqu’elles sont hébergées sur le Cloud Public ? Que faire si l’hébergeur devient un concurrent dans votre secteur d’activité, si les performances, le niveau de service ou les services ne sont pas au rendez-vous ? Comment faire des retours arrière, car cela nécessiterait une deuxième transformation pour revenir sur l’On-Premise et voire une troisième si c’est pour aller ensuite vers un autre hébergeur ?

La transformation n’est pas si simple, elle comporte des indisponibilités de service, des risques techniques et financiers et est très chronophage. Le coût de cette transformation et l’évaluation des risques associés ne sont pas pris en compte dans le coût de cette stratégie.

Alors comment éviter une telle transformation et pouvoir être libre de changer d’hébergeur tout en respectant la stratégie de son entreprise exigeant d’aller vers le Cloud Public ?

Il existe une solution moins radicale et plus agile, si vos applications sont hébergées sur l’hyperviseur vSphere ce qui doit représenter environs plus de 80% des cas, vous pouvez commander directement un SDDC VMware (Software Defined Data Center : Data Center virtualisé) chez l’hébergeur de votre choix, Atos, AWS, Azure, GCP, Oracle, OVH et bien d’autres avec pas loin de 4500 partenaires (VMware Cloud Verified Partner). Cela se fait en général directement à partir de la Market Place de l’hébergeur (Exemple : Azure VMware Solutions), ou directement chez VMware dans le cas d’AWS seulement (VMware Cloud On AWS) Ce processus prend environs 2 heures et vous avez ensuite un environnement complet serveur, stockage, réseau et sécurité qui vous ait dédié. Cet environnement est aussi basé sur l’hyperviseur vSphere, ce qui permet d’exécuter vos applications sans avoir à les transformer. La virtualisation du réseau permet de reproduire la topologie de votre réseau actuel sans avoir à modifier les adresses IP des serveurs et des applications. Vos applications s’exécutent ainsi comme chez vous mais dans le Data Center d’un Cloud Public à proximité des services natifs de l’hébergeur, comme montré dans le schéma qui suit, exemple sur AWS :

Vous avez ainsi le meilleur des deux mondes. Vos applications consomment des services natifs via les APIs et si vous souhaitez changer d’hébergeur, vous déplacez votre application vers le nouvel hébergeur et modifiez uniquement les appels API à ces services natifs. Et même cette partie peut être éviter en utilisant un “Wrapper” qui sera adresser les spécificités des APIs de chaque fournisseur. Il n’est donc pas nécessaire de transformer l’application complète. 

Maintenant que vous avez un SDDC chez un cloud public, comment déplacer simplement ses applications ?

Il est possible d’utiliser la méthode classique, c’est à dire faire un vMotion entre les deux environnements comme il est possible de le faire On-Premise depuis plusieurs années, ce qui fut une des forces de l’hyperviseur vSphere, ou utiliser l’outil de migration HCX qui permet de faire des migrations à chaud ou à froid, en masse, planifiable tout en bénéficiant d’une optimisation réseau pour que les migrations durent moins longtemps.

Le Cloud Public offre beaucoup de services innovants qu’il ne faut pas hésiter à utiliser. Par contre, il ne faut pas vous “verrouiller” avec un acteur, il faut que vos applications soient mobiles. La meilleure approche pour cela est de minimiser au maximum les dépendances. Cela passe par la modification partielle du code de l’application, en modifiant uniquement l’appel aux services natifs (ou passer par un “wrapper” d’API) et de garder son hébergement sur un format de VM qui garantira sa mobilité. Il n’y aura pas de “verrouillage” commercial avec VMware car les SDDC se contractualisent directement avec les fournisseurs des Cloud Public, sauf pour AWS où vous avez le choix de contractualiser avec VMware ou AWS.

Des containers physiques ou virtuels ?

Se poser la question d’exécuter des containers directement sur des serveurs physiques dit “Bare Metal” versus sur des serveurs virtuels dit des VMs est légitime, surtout lorsqu’on utilise un orchestrateur de container comme Kubernetes. Pour chaque nouvelle architecture applicative on me pose la question : est-il nécessaire de mettre en place une architecture virtuelle pour ces types d’application ou pour d’autres : SAP HANA, HADOOP, MONGO DB, CASSANDRA, …. et donc aussi Kubernetes ? L’élément déclencheur de cette réflexion est de vouloir faire l’économie du coût de l’hyperviseur. Mais ce dernier à beaucoup d’avantages opérationnel, sécuritaire, d’extensibilité et de souplesse.  Si vous êtes déjà convaincu par la nécessité de s’appuyer sur une architecture de virtualisation et vous pensez partir sur un hyperviseur dit gratuit, je vous invite à lire cet article : “C’est gratuit ! ?”.

Les portes containers vont s’exécuter sur un porte containers. Un porte container est un système d’exploitation en général Linux sur lequel vont s’exécuter les container. Sur du Bare Metal, on va maximiser le nombre d’exécution de containers alors que dans une VM on va à l’inverse plutôt minimiser le nombre d’exécution de containers voire 1 container par VM. Pour que ce soit efficace ou pertinent, il ne faut pas partir sur des VMs classiques mais sur des micros VMs sur lesquels est installé un systèmes d’exploitation épuré de services inutiles, durci (sécurité renforcée) et optimisé pour les containers de sortes à ce qu’ils consomment très peu de ressources et démarrent en quelques millisecondes.

Tout système d’exploitation a ses contraintes, ses limites et ses faiblesses :

  • Sur un système d’exploitation, le nombre de container est limité (Exemple pour Kubernetes : https://kubernetes.io/docs/setup/best-practices/cluster-large/), la règle est la même pour un porte container basé sur une machine virtuelle. Par contre, un serveur de virtualisation hébergera plusieurs VMs soit autant de porte container à hauteur des ressources physiques disponibles soit : Max Container par OS x Nombre de VM porte containers par serveur de virtualisation.
  • En Bare Metal, le porte containers est en contact directe avec le matériel. Les composants physiques du serveur doivent être compatibles avec le système d’exploitation et ses drivers. La virtualisation elle, fait abstraction et le porte container n’a plus à se soucier de la compatibilité du matériel et des drivers associés, vous pouvez changer de fournisseurs de serveurs et des composants.
  • Le système d’exploitation du porte container doit être maintenu à jour et les opérations de maintenance auront un impact sur tous les containers qui y sont hébergés. Avec une approche VM, l’impact sera limité car comme expliqué juste avant, on privilégie peu de container par VM porte container voire même 1 container par VM.
  • Le porte container est dédié à un usage : dev, prod, pré-prod, …, donc si toutes les ressources ne sont pas utilisées pour cet usage, il y aura beaucoup de perte (€€€). Avec la virtualisation, les serveurs physiques peuvent héberger des VMs porte containers de différents usages et la consommation des ressources sont ainsi optimales.
  • En Bare Metal, le porte container exécutera un seul système d’exploitation. Avec une infrastructure virtualisée, un serveur physique peut héberger des porte containers, Windows et différents types de Linux.
  • Les solutions d’orchestration comme Kubernetes orchestre des containers mais pas le provisionnement de porte containers. L’orchestrateur utilise les ressources physiques qu’il a à sa disposition à un instant T et s’il en manque, il faut rajouter un serveur, mais ce n’est pas lui qui va le faire, il va s’appuyer sur un IaaS (Infrastructure As A Service). En environnement virtualisé le déploiement de porte containers consiste au déploiement de VMs. Les IaaS basés sur des VMs sont beaucoup plus commun que ceux basés sur des serveurs physiques.
  • Quid des performances ? Et bien là aussi un bon hyperviseur permet de gagner en performance, vSphere tire mieux parti des architecture NUMA que les systèmes d’exploitation du marché et permet ainsi d’avoir un gain de performance. Un test comparatif a été effectué par VMware sur des applications Web : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/docker-vsphere65-weathervane-perf.pdf
  • L’isolation des containers entres eux, même si elle fonctionne correctement, elle peut avoir un gros impact sur tous les containers en cas de faille de sécurité. La virtualisation offre en plus, une isolation inter VMs donc inter porte containers beaucoup plus robuste et plus vous limitez le nombre de containers par VM plus la sécurité sera renforcée.
  • Ne vous inquiétez pas sur la consommation des ressources par un porte container VM. Si un OS classique consomme des ressources et met du temps à démarrer, un OS optimisés pour l’hébergement des containers (Micro OS comme Photon OS), consomment peut de ressources et démarre en quelques millisecondes. De plus un bon hyperviseur à des optimisations de consommation de ressources lorsque des OS identiques sont exécutés en même temps.
  • Un container doit pouvoir démarrer sur n’importe quel porte container d’un cluster (regroupement des ressources de plusieurs serveurs), s’il a besoin de persistance des données, il doit pouvoir y a accéder depuis n’importe où et pour cela, il faut un système de fichiers partagé en général un export NFS externe qu’il faut maintenir. La virtualisation propose un système de fichier partagé natif qui est complètement intégré. Sur vSphere ce système de fichiers peut s’appuyer sur pratiquement n’importe quelle baie de stockage du marché. L’utilisation de la solution hyper convergée vSAN offre néanmoins beaucoup plus d’avantages qui sont détaillés dans cet article : Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

J’ai apporté une liste non exhaustive des avantages à utiliser la virtualisation pour des containers, si vous avez encore des doutes, je vous invite à vérifier sur quel type d’architecture s’exécute les offres de containers as a service proposées par les grands acteurs du Cloud Publics. D’ailleurs RedHat et VMware ont annoncé lors du Red Hat Summit de mai 2019 une architecture de référence pour la solution Red Hat OpenShift basée sur le SDDC VMware : https://octo.vmware.com/vmware-red-hat-bring-red-hat-openshift-vmware-sddc/.

Les offres autour de Kubernetes ne cessent d’évoluer, VMware vient d’annoncer à VMworld 2019 le Projet Pacific, une nouvelle évolution de l’hyperviseur vSphere qui intégra nativement l’orchestrateur Kubernetes et les portes containers, ca fera l’objet d’un nouvel article 🤔😉.

Une histoire virtuelle sur la transformation digitale

Pour changer, j’ai écrit cet article sous la forme d’un petit “roman photo” qui explique comment une chaine de pizzeria est confrontée à la digitalisation de son métier. En roles principaux, il y a : le client, le boss, ceux qui réfléchissent à une solution, ceux qui trouvent la solution, le responsable informatique, le responsable de sécurité, le développeur et l’avant-vente VMware. Je tiens à remercier mes collègues qui se sont prêtés au jeu en posant ou en prenant les photos.

L’IOT a besoin d’une infrastructure et elle existe !

Les objets sont de plus en plus présents dans les entreprises et sous diverses formes (Caméra, capteur de température, ventilateur, ….). Ces objets génèrent énormément de données qui sont traitées par une ou plusieurs applications. Prenons un exemple simple de parking, avant d’y rentrer vous pouvez savoir le nombre de places de stationnement disponibles, puis une fois rentré le nombre de places par étage et enfin par rangée, ceci grâce à des capteurs qui sont généralement fixés au plafond à quelques dizaines de centimètres au-dessus des voitures. Dans ce même parking vous avez des caméras un peu partout pour enregistrer les mouvements des personnes, vous avez des capteurs pour mesurer le taux de monoxyde de carbone et enclencher des extracteurs pour évacuer ces particules. Tous ces objets vont générer des données et Il y aura une application provenant de différents constructeurs et par activité pour les traiter, une application pour les places de parking, une pour les caméras et une pour la détection des particules. Par contre comment gérer ces objets ? Comment connaitre leur santé, mettre à jour leur firmware ? Pour cela, il est pertinent d’avoir une infrastructure commune hétérogène.

La solution VMware IOT Pulse Center permet à l’IOT d’avoir à la fois son infrastructure basée sur le SDDC VMware et aussi de gérer le cycle de vie des objets comme le fait VMware Workspace One avec les périphériques utilisateur. 

Cependant il y a un élément nouveau dans l’IOT par rapport à une infrastructure classique, c’est la gateway, comme les objets sont nombreux et utilisent souvent un protocole et une connectique qui leurs sont propres, ils passent par cette gateway qui servira de concentrateur et permettra la communication avec les applications via le réseau classique IP.

 

En 2016 VMware a développé l’agent LIOTA (Little Internet Of Things Agent) qui est un SDK Open source installé sur ces gateway permettant la communication avec les objets et ainsi de les gérer, de les monitorer et d’orchestrer les données en provenance et allant vers le Data Center et/ou Cloud Public. LIOTA découple aussi l’application du type/marque/model d’objet, l’application communique ainsi via LIOTA qui lui retranscrira aux objets en fonction de leurs spécificités.

 

Pour les grosses architectures ou les solutions nécessitant des prises de décisions rapides, un élément intermédiaire sera ajouté entre la gateway et l’application qui va permettre de faire des pré/post traitements et être ainsi plus réactif, ces traitements sont hébergés et exécutés sur du Edge Computing. Le Edge Computing est au bout de la chaine au plus près des gateways et objets. Sur ces Edge Computing est installé le SDDC de VMware.

 

 

Les objets sont enregistrés dans Pulse IOT Center, ce qui permet de connaitre leur états de santé, de les sécuriser en sécurisant les mot de passe (bien souvent les mots de passe par défaut ne sont pas remplacés) et de gérer les cycles de vie des firmwares. Pulse IOT Center permet aussi de classifier les objets de manière à avoir des vues pertinentes et prendre les bonnes décisions rapidement.

 

Les objets ont désormais leur Infrastructure basée sur des solutions existantes et éprouvées depuis de nombreuses années. Cette infrastructure permet de s’affranchir de l’hétérogénéité et la massification induite par ce type de technologie. Les opérationnels ont avec le SDDC de VMware un case d’usage supplémentaire.

Consommer les solutions VMware as a Service via un partenaire Service Provider

Le programme VCPP (VMware Cloud Provider Program) permet aux clients finaux de consommer les solutions VMware comme un service (VMware as a Service) avec une couverture locale ou géographiquement répartie à travers le monde. Il existe environs 4 600 partenaires Service Provider VMware dans le monde qui offrent ces possibilités dont plusieurs centaines en france.  Les services proposés vont de la mise à disposition d’infrastructure nue (Bare Metal) jusqu’à une infrastructure complètement opérée, simplifiant ainsi au maximum leurs usages. La liste complète ainsi que les services proposés sont disponibles via ce lien :https://cloud.vmware.com/providers/search-result.

Ce qui caractérise tous ces partenaires, c’est qu’ils utilisent au moins une technologie VMware, pour la majorité d’entres-eux ils utilisent au minimum l’hyperviseur vSphere, ce qui rassure les clients finaux car c’est une technologie pérenne, largement répandue, fiable et performante leur permettant ainsi d’accroitre leur business.

Les raisons pour lesquels les clients finaux trouvent un(des) intérêt(s) à consommer ces services ?

  • Diminuer les frais d’infrastructures. Pour certains clients, consommer ces services peuvent coûter moins chers s’ils n’ont pas les outils leur permettant d’optimiser l’utilisation des ressources physiques On Premise, n’ont pas la taille critique pour un contexte spécifique ou encore n’ont pas de temps à passer sur des problèmes de sécurité (comme par exemple) le hacking permanent de site web.
  • N’ont pas et ne souhaitent pas acquérir les compétences pour gérer une infrastructure.
  • Ont besoin d’une agilité qu’ils n’ont pas On Premise et ainsi gagner du temps pour développer et déployer les applications.
  • Ne veulent plus gérer le cycle de vie matériel et logiciel, s’affranchir ainsi des mises à jour et des matrices inter-solutions de plus en plus complexe.
  • Avoir des ressources informatiques à travers le monde sans avoir à investir dans des data center.
  • Intégrer plus facilement les nouvelles filiales.
  • Respecter les SLAs et les normes comme par exemple HADS pour la santé, ISO 27000 pour la confidentialité des données ou encore la gestion d’archivage des données publique, SIAF et bien d’autres.
  • Avoir un “réceptacle” pour les sauvegardes et/ou une possibilité de relancer les applications en cas de désastre.
  • Proposer des postes de travail virtuels comme une commodité, accessibles depuis n’importe où pour les populations à risque ou ultra nomade.
  • D’être une extension du Data Center On Premise en permettant un “débordement” sur le cloud public.
  • D’héberger des applications nécessitant de gros serveurs puissants pour les BDD type SAP HANA ou au contraire nécessitant beaucoup de petit serveur pour des cluster Hadoop.
  • De bénéficier de gros tuyaux vers Internet, les applications orientées consommateurs externes seront ainsi au plus proche d’Internet.
  • Avoir un hébergement sécurisé par des services provider dont c’est le métier.
  • Une consommation à l’usage et donc la capacité à changer de type de service ou de volumétrie simplement, réduire les risques projets lié à des volatilités ou non prédictibilité suffisante.

Sur quels critères les clients finaux choisissent leur(s) partenaire(s) VCPP ?

  • Présence locale, régionale et/ou international, un client peut vouloir rechercher de la proximité et choisir un partenaire de sa région, un autre peut vouloir choisir un partenaire ayant une couverture internationale pour par exemple une extension au Brésil, en Chine, en Afrique du sud. Il sera peut-être amené à devoir choisir plusieurs partenaires si un seul n’est pas en mesure de tout couvrir.
  • La possibilité de personnaliser des configurations matériels et/ou de machines virtuelles c’est le  “sur mesure”.
  • Qualité de l’interconnexion entres les plaques géographiques.
  • Standardisation, avoir les mêmes hyperviseurs, les mêmes réseaux, les mêmes outils d’opération….
  • Bien sur le prix, les niveaux de services attendus ainsi que les services proposés

Types d’usages généralement proposés :

  • Bare Metal as a Service : les serveurs physiques sont installés, configurés et maintenus automatiquement par le partenaire.
  • vSphere as a Service / vCenter as a service : Les serveurs physique, vSphere et le vCenter sont installés et configurés automatiquement et maintenus par le partenaire. Le client a accès au vCenter et l’utilise comme habituellement.
  • VM as a Service : Le client dispose d’un portail pour créer des VMs sur une infrastructure déjà opérationnel, elle est en générale mutualisée et partagée par plusieurs clients.
  • SDDC as a Service, tous le composants du SDDC VMware (vSphere, vSAN, NSX et vCenter) sont installés automatiquement.
  • Les postes de travail virtuels.
  • Des Service applicatif.
  • Mise à disposition d’un cloud privé, portail de self service avec un parfaite maîtrise des services , de la sécurité et des coûts.
  • Service avec validation de certification ou contexte (HADS, PCI-DSS, SIAF …).

Il existe donc une multitude de raisons pour travailler avec un partenaire VMware fournisseur de services mais la principale réside sur l’utilisation d’une ou plusieurs solution VMware gage de sécurité, de fiabilité et simplicité .

 

La Fondation Digitale pour la Transformation Digitale

De nos jours, la nouvelle monnaie c’est la rapidité.

Dans tous les secteurs d’activités les entreprises subissent une nouvelle concurrence venue de la digitalisation, ces entreprises l’ont bien compris mais malheureusement bien souvent trop tard, rares sont celles qui l’ont anticipée, elles sont réactives. Il existe de multitude d’exemples comme Uber avec les taxis et Airbnb avec l’hôtellerie. Ce qui caractérise cette concurrence, c’est l’apport ou l’amélioration d’un service par un nouvel acteur sur un secteur d’activité dominé par des acteurs historiques et qui n’ont pas sus/voulus évolués.

Ces nouveaux services nécessitent d’adapter ou de développer des logiciels à de nouveaux usages et à de nouvelles méthodes de consommation. Pour une entreprise qui vient de se créer c’est simple, elles n’ont pas d’infrastructure et de patrimoine d’applications à faire évoluer, elles peuvent démarrer directement sur un environnement agile et à partir de là développer ces applications. En revanche pour les entreprises existantes ca sera beaucoup plus complexe et cette complexité et proportionnelle à la taille de l’entreprise. Plus les entreprises sont importantes et plus elles auront à faire évoluer un patrimoine d’applications important et auront aussi besoin d’en developper de nouvelles. Pour cela elles devront entreprendre une transformation du personnel et des process mais aussi une Transformation Digitale ! Un “Digital Business” nécessite une “Digital Foundation”

 

La transformation digitale s’opère sur la fourniture des applications, l’hébergement des applications et la consommation des applications tout en renforçant la sécurité. Elle doit résulter d’une foundation unique pour différents usages. Elle repose évidement sur du matériel pour lequel on peut exiger performance, capacité et fiabilité. L’autre partie c’est la part belle du logiciel, c’est elle qui va apporter l’agilité nécessaire à la digitalisation. La fondation peut-être dans le data center privé comme sur une infrastructure cloud public. Elle doit pouvoir héberger des applications classiques comme des Cloud Native Apps qui seront consommées via des desktops, des objets connectés ou des smartphones.

 

 

La transformation digitale doit être impulsée par la direction et répercutée dans toute la chaine managériales car elle implique l’adhésion du personnel qui lui aussi doit être prêt à se “transformer”. C’est la partie la plus compliquée, il faut s’attendre à avoir des résistances, je l’ai souvent constaté. La gestion des couches basses de part l’automatisation nécessitera de moins en moins de personnel qui sera désormais de en plus en plus proche du métier de l’entreprise. L’IT devient partenaire du business voire même partie prenante du business. Cependant c’est difficile de faire comprendre à un administrateur de stockage qu’il n’aura plus de baie de stockage et de réseau SAN à administrer (cf article sur la virtualisation du stockage  http://loeilduse.fr/?p=43). Difficile de faire comprendre à un administrateur réseau que la création de réseaux va être déportée dans une cloud management platform ou un orchestrateur de containers. Ils doivent pourtant comprendre qu’ils tentent de résister à un rouleau compresseur qu’est la tendance du marché et c’est une question de temps avant que la transformation ne s’opère. Ils doivent saisir l’occasion pour s’orienter vers de nouvelles technologies comme le cloud (privé, public et/ou hybride), le DevOps, les containers, la mobilité, l’IOT, les blockchains, …, la liste est longue et il y a quoi bien s’occuper.

Pour être efficiente, la fondation digitale doit être appliquée sur toute la chaine allant des ressources hébergeant les applications jusqu’à l’utilisateur qui va les consommer à l’instar de la sécurité (cf article la sécurité de bout en bout http://loeilduse.fr/?p=249). Très important, cette chaine doit être constituées de composants qui s’intègres les uns aux autres nativement sans effort. Pour diminuer les risques, il est indispensable d’avoir tous ces composants issus du même éditeur.

Commençons par l’hébergement sur le Data Center privé, ensuite le Cloud Hybrid pour finir par la consommation via les terminaux :

 

Le Data Center Privé 

L’agilité va permettre de gagner du temps en étant plus réactif voire proactif.  Pour cela, il faut le moderniser en le rendant agile afin que, le patrimoine d’applications puisse en bénéficier, pour y héberger les nouvelles applications Cloud Native et pour renforcer la sécurité existante (car on ne sécurise pas les Cloud Native Apps et les containers comme on le faisait avec les applications traditionnelles). Cette agilité ne peut être obtenue que par le SDDC (Software Defined Data Center) en virtualisant tous les composants du Data Center. Une fois virtualisés, ils pourront être automatisés presque robotisés! L’infrastructure physique, elle est là pour être capacitive, performante et fiable avec un sas de sécurité pour filtrer tout ce qui y rentre et tout ce qui sort. Le SDDC va utiliser ces ressources pour y exécuter tout type d’applications et sera couplé à une Cloud Management Platform ou un orchestrateur de container comme Kubernetes (cf article sur PKS http://loeilduse.fr/?p=158)

L’architecte peut ainsi en tout autonomie “désigner” son application en y intégrant tous les composants du SDDC dont il a besoin. Ci-dessous un exemple de design d’un service web en cluster, la création du réseau, l’insertion de service Load Balancer et l’application de règle de sécurité. Plus besoin de faire des demandes à différences services pour obtenir les ressources dont il a besoin.

 

Une fois terminé, l’architecte peut soit la déployer ou soit le mettre à disposition via un catalogue de services pour des utilisateurs puissent la déployer ultérieurement :

 

Aboutir à ce résultat n’est pas d’un point de vue technique si compliqué que ça, à condition, j’insiste, que tous les composants logiciels du SDDC soient prévus pour fonctionner nativement ensemble, ainsi les efforts d’intégrations et de maintient en condition opérationnel seront réduits. La mise à jour du SDDC se fait sans avoir à se soucier de l’intéropérabilité des versions des composants, le SDDC Manager se charge de ça.

Il ne faut pas aussi que le SDDC n’est d’adhérence avec la couche matériel, vous devez être libre de choisir et de changer les composants physiques avec un minimum d’impact. Ainsi les switches peuvent être des Cisco, des Arista, des juniper, ou autre, les serveurs peuvent être des HP, des DELL, des Lenovo, ou autre, ça n’a pas d’importance que ce soit à la création du SDDC ou durant son cycle de vie.

 

Le Cloud Hybride

Hybride au sens où on peut transférer des applications du cloud public vers le cloud privé et vice-versa en fonction des besoins. Ce qui est recherché :

  • Ce sont des services innovants utilisables à la demande sans avoir à les installer et à les administrer.
  • Des ressources physiques à la demande sans avoir à anticiper les achats matériels. Si un gros projet nécessitant beaucoup de ressources non disponibles sur le Data Center privé, il faudrait attendre de les commander, de les installer et les configurer avant de pouvoir commencer le projet. Avec le Cloud Hybrid on commande un SDDC et deux heures après il est disponible pour démarrer le projet. Si vous souhaitez le voir au final sur votre Data Center privé vous pourrez le rapatrier une fois les nouvelles ressources disponibles. Pour que ce soit faisable et sans risque, il faut que le SDDC public soit le même que le SDDC privé (à minima le même hyperviseur). Pour en savoir plus je vous conseil cet article : http://loeilduse.fr/?p=74.

 

Les terminaux

Une fois les applications déployées il faut les consommer, le problème c’est qu’elles prolifèrent et c’est difficile de s’y retrouver tellement on en a. En plus maintenant ont a plusieurs terminaux : un smartphone (Android ou IOS), une tablette (Android, IOS ou Windows) ou laptop (Mac, Chrome OS ou Windows).

Pour être efficace, l’utilisateur doit avoir une visibilité directe des applications dont il a besoin et ce quelque soit le terminal qu’il utilise. Ci-dessous une copie d’écran du portail avec les applications que j’utilise le plus souvent sur mon Mac ou mon S8.

En plus d’avoir accès rapidement aux applications, on n’a plus à se soucier d’avoir à gérer la complexité des différentes politiques de mot de passe par application, une fois connecté via son compte principal, l’utilisateur n’a plus besoin de s’authentifier à nouveau pour accéder à ses applications et ce quelque soit son mode d’hébergement (SaaS, Web ou installées sur le terminal) (cf article la sécurité de bout en bout, chapitre sécuriser les accès à distance  http://loeilduse.fr/?p=249).

La sécurité de bout en bout !

Comme on ne vit pas dans le monde des Bisounours, la sécurité est pour nous tous un mal nécessaire je dirais même obligatoire. Elle ne se résume pas à la mis en place d’un firewall pour filtrer tout ce qui entre et qui sort du data center et d’un anti-virus sur le poste de travail, il faut sécuriser toute la chaine allant de l’utilisateur à l’application en passant par l’infrastructure.

Vous avez surement déjà vue l’image à droite lors d’une présentation VMware, elle explique la stratégie de VMware, à droite de cette image, il y a des petits cadenas orange qui correspondent à la sécurité. C’est ce que je vais décrire succinctement dans cet article : les fonctionnalités qui contribuent à améliorer la sécurité. Elles peuvent être utilisées de manière indépendantes ou complémentaires les unes par rapport aux autres. Je vais commencer par le bas (l’infrastructure) pour finir par le haut (l’utilisateur).

 

Sécuriser la base : le boot de l’hyperviseur

Pour être sûr que l’hyversieur est basé sur un code authentifié, celui-ci peut être vérifier dès la première phase de démarrage par le BIOS UEFI du serveur et si le code n’a pas la bonne signature, l’hyperviseur ne pourra pas démarrer. La vérification se fait par un système de clé privé / clé publique.

The UEFI secure boot stack includes multiple elements, explained in the text.

 

“Durcir” les composants

VMware délivre des “Security Hardenig Guides” https://www.vmware.com/security/hardening-guides.html pour sa solution d’hyperviseur vSphere et sa solution de réseau et de sécurité NSX. Ces “Security Hardening Guides” sont des règles de configuration de bonne pratique qui permettent de sécuriser au maximum les solutions VMware et limiter ainsi les surfaces d’attaques. Un exemple de règle sur vSphere parmi les 70 qui existent, le timeout d’accès au shell pour exécuter des lignes de commande, par défaut il n’y en a pas, la recommendation est de 900 minutes.

Pour faciliter la vérification du bon respect de ces règles la solution vRealize Opérations propose des tableaux de bords simples à consulter :

 

Le chiffrement des VMs

Pour éviter que des VMs soient copiées illicitement et ensuite démarrées sur un autre environnement, il est possible de chiffrer les fichiers qui les constitue ainsi que les éventuels déplacement (vMotion) vers d’autres hyperviseurs identifiés, et ce, quel que soit l’OS des VMs. La mise en place nécessite que le vCenter soit relié à un serveur de gestion de clés KMS, ensuite il suffit d’associer les VMs que l’on souhaite chiffrer à une politique de stockage ayant l’attribut chiffrement, cela peut se faire post création.

Il est possible aussi de chiffrer un espace de stockage complet (nécessite d’avoir la solution vSAN), tout ce qui y sera stocké sera sécurisé, pas besoin de sélectionner les VMs à sécuriser. Un autre avantage ce cette possibilité auquel on ne pense pas concerne la partie matériel, ainsi si un disque est défaillant vous n’êtes pas obligé de passer par une société tierce pour le détruire car son contenu est chiffré et donc illisible.

 

Sécuriser le boot des VMs

Pour éviter que des root kits malveillants soient installés dans le système d’exploitation de la VM et ainsi corrompre le système d’exploitation, l’hyperviseur vSphere permet de sécuriser le boot de la VM de façon a ce que seuls les systèmes d’exploitation, le boot loader et les drivers signés par l’éditeur puissent démarrer.

 

Création de réseaux par usage

Pour limiter les surfaces d’attaques, il faut limiter l’exposition des applications sur les réseaux. Idéalement une application devrait venir avec ses propres réseaux de communication. Prenons une architecture applicative composée de plusieurs services comme par exemple un service Web, un serveur d’application et un service de base de données. Seul le service Web doit être exposé aux utilisateurs. Les autres communications doivent se faire par réseau dédiés comme illustré dans le schéma ci-dessous :

Avec ce principe on créé un réseau dédié par canal de communication entre les services applicatifs. Le fait d’avoir des petits réseaux dédiés à chaque communication limite l’utilisation de règles de sécurité. Alors bien sûr avec un réseau classique c’est complexe à mettre en place mais avec la virtualisation du réseau (NSX), c’est un jeu d’enfant.

 

La micro segmentation

La micro segmentation consiste  à améliorer la sécurité de l’infrastructure en étant le plus granulaire possible. Elle permet de filtrer les communications de chaque carte réseau de chaque VM.

Grâce à cela les communications entres les VMs peuvent être filtrées mêmes si elles résident sur le sur un même segment réseau IP. Dans l’exemple ci-dessous la VM qui appartient à l’application Finance et connectée au réseau DMZ mais elle ne peut pas communiquer avec les autres VMs HR et Engineering même si elles aussi sont connectées au même segment réseau IP DMZ.

Alors il est possible de le faire avec une architecture physique classique mais ça devient vite une usine à gaz à mettre en place et à administrer au quotidien.  Avec la virtualisation de la sécurité (NSX), c’est beaucoup plus simple, les règles peuvent être créés dynamiquement, par exemple on peut identifier toutes les VMs (existantes et à venir) Windows sans avoir à spécifier les adresses IPs. De plus si les VMs sont amenées à se déplacer d’un hyperviseur à un autre, les règles restent toujours actives car le firewall est distribué dans le kernel de tous les hyperviseurs concernés.

 

La conformité

Suivant le secteur d’activité de son entreprise, on peut être amené à devoir respecter certaines normes de sécurité et mettre en conformité une partie de son infrastructure.  Comme un de mes clients stockait et traitait des informations relatives aux paiements par carte bancaire, J’ai dû travailler sur la norme de sécurité PCI-DSS ( Payment Card Industry Data Security Standard). Pour PCI-DSS, il faut prendre en compte toute une chaine à sécuriser. L’avantage principal des solutions VMware est qu’elles vont vous permettre de ne pas avoir à dédier une infrastructure physique mais plutôt de segmenter celle existante et dédier un segment à l’environnement PCI-DSS et de le rendre hermétique par rapport au reste. Prenons deux exemples, l’un coté utilisateur et l’autre coté réseau :

  • Coté utilisateur, le poste de travail utilisé par un opérateur manipulant des données de paiement par carte bancaire doit être dédié à cet usage, s’il est amené à travailler avec d’autres données, il doit avoir un autre poste pour cet usage. Grace à la visualisation du poste de travail (VMware Horizon), il a un poste physique avec son environnement classique et un autre environnement virtuel dédié à PCI-DSS, les deux sont complètement isolés et étanches l’un par rapport à l’autre.
  • Coté réseau, le réseau utilisé par l’environnement qui va manipuler des données de paiement par carte bancaire doit être isolé par rapport aux autres réseaux des autres environnements. Grace à la visualisation du réseau et de la sécurité (NSX), vous créez à la demande des réseaux virtuels de confiance dédiés au périmètre PCI-DSS complément isolés et hermétiques du réseau classique d’entreprise

Ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-sddc-euc-product-applicability-guide-for-pci-dss.pdf détail l’apport de chaque solution à chaque recommandation.

 

La sécurité des applications

La devise est : si on sait modéliser le bon comportement d’une application alors on sait aussi identifier un mauvais comportement, un comportement déviant de la normal. La solution AppDefense modélise le bon comportement grace à une capture de l’application, c’est à dire identifier tous les process et communications réseau utilisés. (Tout est plus détaillé dans ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-appdefense-solution-overview.pdf)

La première chose que tente de faire un “malware” est de désactiver les outils de sécurité basés sur des agents. AppDefense bénéfice d’une zone sécurisée fournie par l’hyperviseur qui est inaccessible par le système d’exploitation de la machine virtuelle, AppDefense ne peut ainsi pas être corrompu ou désactivé.

Lorsqu’une menace est détectée, AppDefense peut demander à vSphere d’arrêter une VM, de la suspendre ou d’en faire un snapshot afin de pouvoir la décortiquer. AppDefense peut aussi demander à NSX (solution de virtualisation de réseaux et sécurité) de bloquer les communications réseaux ou de le connecter à un réseau de quarantaine.

 

Sécuriser les accès distants

Il y a plusieurs possibilité d’accéder à distance à des applications d’entreprise, pour chaque méthode il faut une solution sécurisée :

  • Le VPN SSL de NSX permet à des utilisateurs de se connecter depuis n’importe où à un réseau spécifique du Data Center via un canal chiffré, comme si il était directement au réseau de son entreprise.
  • Le VPN IPSEC de NSX permet de connecter deux segments de réseaux IP différents tout en sécurisant les flux de communication.
  • Le VPN L2 permet d’interconnecter deux réseaux physiques de niveau 2 (Ethernet) différents pour qu’ils soient vus comme un seul. Les VMs ainsi connectées se voient toutes comme si elles étaient physiquement connectées sur un même réseau.
  • Les VPNs par application de Workspace One sont utilisés notamment pour les applications smartphone, ils permettent à chaque application d’avoir son propre tunnel sécurisé. Ça offre l’avantage de ne pas avoir un seul gros VPN pour tout le smartphone où il n’y a pas de distinction des communications personnelles et professionnelles. Cela permet aussi de diminuer la consommation de la batterie, le VPN engendrant des cycles CPU n’est activé que quand l’application est utilisée.
  • Le poste de travail virtuel (VMware Horizon anciennement VMware View) permet de donner accès via un réseau à un poste de travail qui est entièrement exécuté sur un Data Center, seuls les flux entrants et sortants comme le clavier, la souris, l’écran ou encore le son sont locaux. Toute la propriété intellectuelle de l’entreprise reste au sein de l’entreprise, les transferts de fichiers, le copier/coller, l’accès à des périphériques USB peuvent être inhibés. Le poste de travail virtuel est souvent utilisé lorsque les entreprise ont recours à des prestataires ou à des sous-traitant.
  • La gestion des terminaux (Android et IOS) et de leurs contenus (VMware Workspace One anciennement Airwatch) permet de sécuriser les accès. En effet quelque soit le model d’attribution choisi : Bring Your Own Device, Choose Your Own Device ou autre, il est possible de créer un espace professionnel distinct du personnel sans compromettre la sécurité. L’utilisateur gère son propre espace avec ses propres contenus et l’administrateur s’occupe de sécuriser l’espace professionnel. Il autorise l’accès aux applications et aux données de l’entreprise par des critères d’authentification multi facteur requis en fonction du réseau de connexion.  Pour simplifier et sécurisé les authentifications, la fédération d’identité est utilisée pour accéder à l’ensemble des applications (SaaS, Web,  Messagerie, …) empêchant ainsi les traditionnels risques liés aux mot de passe faibles et identiques, tout en permettant à l’utilisateur une seule authentification valable pour l’ensemble des applications. Si le terminal est perdu ou volé il est possible de remettre à zéro le contenu de la partie professionnelle.

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

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.