VMworld 2018 – Recapitulatif jour 3

Ludovic Rivallain calendarNov 7, 2018  · 9 min read  ·
Share on: linkedincopy
vmware vmworld

Troisième jour au VMworld et déjà le sentiment un peu amer que la fin approche doucement. En attendant, on en profite pour assister à de nouvelles sessions et réseauter!

#VIN2642BE – Don't Sleep on RESTful APIs for vSphere

Dans cette session, Kyle Ruddy nous rappelle l'intérêt des API RESTful dans le monde de la programmation, de la navigation et surtout, de l'automatisation. L'importance des concepts CRUD (Create, Read, Update, Delete), la sécurité des appels et l'idempotence sont aussi rappelés rapidement.

Pour le sujet qui nous concerne, vSphere, les API SOAP ont eu la prédominance jusque-là mais VMware reconnait à présent que le choix n'était certainement pas le meilleur et démontre sa transition en cours vers des API RESTful (sur de nombreux produits d'ailleurs). Plus faciles à utiliser, documenter, maintenir, les API RESTful remplaceront totalement SOAP dans le futur des produits VMware. Entamé en version 6.5, cette migration a encore progressé en 6.7 avec l'ajout de nombreuse fonctions (dont, le scheduler de backup, le repoint PSC, des techpreview etc…).

La suite de la conférence est au sujet des outils disponibles pour utiliser ces API. Au-delà de la documentation disponible sur le site code.vmware.com/apis, VMware produit (et soutient la production communautaire) des outils pour différents modes de consommation des API REST: Postman, DatacenterCLI, Swagger based API Explorer, PowerCLI etc.

L'occasion de démontrer via une démo comment déployer rapidement une enveloppe de VM vide et que les différents modes d'utilisation et outils produits par VMware sont cohérents entre eux et permettent d'obtenir les mêmes résultats.

Trop de monde pour aller rencontrer la RockStar Kyle Ruddy à la fin mais si je le recroise, j'aimerais lui demander si VMware compte modifier ses interfaces pour ne plus utiliser QUE ses API REST pour atteindre le backend, ce qui assurerait que tout ce qui est possible dans une UI, l'est aussi dans le monde API.

#CNA1674BE – Deep Dive: Run Kubernetes in Production with PKS

Dans cette session #DeepDive Merlin Glynn (Technical Product Manager @ VMware) et James Webb (Cloud Foundry Platform Architect @ T-Mobile) reviennent sur le déploiement chez T-Mobile de la solution VMware PKS: un challenge qui visait à homogénéiser les différents modes de consommation de containeurs par les équipes de développement de différents produit. Accompagnés par VMware dans cette démarche, ils ont expliqué les challenges de ce projet: authentification, HA de la stack de management, automatisation, scalabilité des composants, réplications du stockage persistent, usage PAS-like (HTTPS, DNS, Load Balancing…), les difficultés rencontrées et les challenges qui restent à relever.

Le use case est intéressant mais clairement j'atteinds ma limite de technicité: Je visualise bien PKS, Kubernetes, mais ici on a affaire à des défis techniques très précis que j'ai du mal à appréhender. Toutefois je ressors de cette session avec en tête quelques noms d'outils qu'il m'intéresse d'explorer plus tard: GitOps, Concourse, Prometheus…

#DC3845KE – Cloud and Developer Keynote: Public Clouds and Kubernetes at Scale

  • Auteur de la notice ci-dessous: Ludovic Rivallain
  • Vidéo
  • Speakers:
    • Joe Beda, CTO, Heptio
    • Guido Appenzeller, CTO, VMware
    • Paul Fazzone, SVP and GM, Cloud Native Apps, VMware
    • Joseph Kinsella, Vice President and CTO, Products, CloudHealth, VMware

Cloud Health

Cette keynote démarre avec un constat de la situation actuelle et de l'évolution en cours de la consommation du cloud: l'usage de cloud multiples. Par exemple, les Hands On Lab de VMware tournent à la fois sur un Datacenter interne, mais aussi sur le cloud IBM, le cloud AWS (débordements, tolérance à la panne etc.).

Cela n'est pas sans problématique et notamment, celle de la compatibilité: formats, outils, méthodologies, complexités…

C'est là qu'arrive la promesse de VMware: Aider à l'adoption de différents cloud sans se poser ces questions, notamment à l'aide de Cloud Health (une acquisition récente). Un autre but de Cloud Health est de sécuriser l'usage d'un Cloud Public (ou plus) même si vous n'avez pas la maturité nécessaire pour gérer pro-activement les débordements, les sur-coûts, les réductions de ressources… au lieu d'être seulement dans la réaction (à la réception d'une facture AWS un peu salée par exemple).

Après une démo de Cloud Health (pas forcément très lisible), Vodafone intervient sur scène pour témoigner de son adoption de différents clouds à l'aide de Cloud Health.

Cloud Native Apps & Kubernetes

Forcément, avec l'acquisition de Heptio, nous allions aborder le sujet de Kubernetes et de Cloud Native Apps pour démontrer la volonté de rendre plus facile l'adoption de clouds dans un processus de développement.

VMware fait aussi beaucoup de pub de sa solution VMware PKS (et la nouvelle VMware Cloud PKS: en Beta !) pour déployer, gérer et proposer des clusters Kubernetes.

Forcément le scénario de la démo de VMware Cloud PKS sera de: "déployer un blog Wordpress" (s'il vous plait, soyez plus créatifs la prochaine fois que vous voudrez faire une démo…).

En gros, VMware gère pour vous la complexité de PKS et vous permet de lancer vos cluster Kubernetes vous-même en quelques minutes: réduisant ainsi le temps nécessaire entre l'expression de besoin et le déploiement d'une application.

#VIN1735BE – Clustering Deep Dive 2: Quality Control with DRS and Network I/O Control

Un petit mot déjà sur l'un des speakers, Niels est l'un des auteurs du livre VMware vSphere 6. 7 Clustering Deepdive - Rubrik, du coup la conférence est déjà très remplie car pour certain c'est une rockstar !

Bref, revenons à la conférence, Niels nous présente les bienfaits du Network I/O control, cette fonctionnalité souvent méconnue qui permet de limiter les bandes passantes via des valeurs share en cas de contention réseau par type de traffic. Le NIOC va nous permettre de contrôler le traffic entrant sur le DVSwitch(VDS). Pour ce qui est du traffic sortant, il faudra mettre en place du traffic shapping et ainsi pouvoir par exemple réserver une bande passante sortante pour le traffic de type stockage, attention cela va s'appliquer au niveau de l'uplink du VDS.

Plusieurs usecases nous sont présentés pour ensuite passer à la partie DRS. Que fait le DRS ici? Et bien il s'agit d'une technologie qu'on ne présente plus pour équilibrer la charge sur un cluster, mais depuis la version 6.5 il y'a une nouvelle fonctionnalité qui a été ajoutée: Network aware DRS. Concrètement il s'agit ici de prendre en compte en plus des ressources RAM et CPU, les contraintes réseaux pour être sûre que le déplacement d'une VM n'entrainera pas une saturation de bande passante ou bien d'autres problèmes liés au réseau.

Malheureusement, la fonctionnalité est seulement présentée par use-case et pas via une explication en profondeur de l'algorythme: on nous dit que ce sont des formules mathématiques dérrière, bref apparemment les informaticiens n'aiment pas les maths mais moi cela m'aurait intéressé.

#NET1106BE – Advanced VMware NSX Data Center: Demistifying the VTEP, MAC and ARP Tables

Le but de cette conférence était de rentrer dans le détail du fonctionnement des tables d'adresses MAC, VTEP et ARP lorsque l'on utilise des DLR. Nous commençons la conférence avec un petit rappel sur le fait que toutes ces tables sont stockées au niveau du/des NSX-controller(s), nous revenons ensuite sur la communication entre l'ESXi et le(s) controller(s) et le fait que cela se fait via le composant NetCPA (Network Control Plane Agent).

Ensuite, petite présentation de Central CLI qui permet depuis le NSX manager d'interroger les controlle(s) et ainsi afficher les tables MAC, VTEP et ARP. Démo à l'appui, on nous montre comment ces tables se remplissent au démarrage d'une VM (et pas avant).

Nous passons ensuite sur l'ARP suppression, gros avantage de NSX-V: Les échanges passant par l'agent NETCPA et les communications se font au niveau kernel et ne consomment pas de bande passante. Autre avantage de ce fonctionnement: Si une VM a besoin de communiquer avec une autre VM qui est allumée (qui est donc connue des controllers), la requête ARP s'arrêtera au niveau de l'ESXi et la trame sera envoyée directement en unicast vers l'ESXi qui héberge la VM.

Petite nouveauté: on nous parle d'une fonctionnalité qui était jusque là un peu caché, le CDO (Controller Disconnected Operation) mode. Dans le cas où on aurait un problème de communication entre le controler cluster et l'ESXi et grâce à ce procédé, l'ESXi conserve une copie locale des tables MAC, VTEP et ARP jusqu'à rétablissement de la communication avec le controller. Cela empêche d'avoir des broadcast dans tous les sens sans couper les échanges. Ces tables sont populées avant l'allumage des VMs ce qui permet de préparer la communication avec une VM qui était encore éteinte au moment de l'incident. Limite du procédé: si une VM inconnue est déployée et allumée après le crash du controller on ne pourra pas communiquer avec elle.

Conférence très intéressante et très pédagogique, elle m'a permis d'approfondir mes connaissances sur l'ARP suppression et aussi de faire connaissance avec le CPO mode qui sera très utile pour les futurs infrastructures NSX.

#MGT1312BE - Intro to VMware’s Cloud Management Automation Services. You agile enough?

L'utilisation du muticloud est un gros challenge pour les infrastructures IT:

  • Manque de visibilité
  • Complexe à gérer
  • Multiples portails (AWS, Azure, vCenter)

VMware annonce sur son portail VMware Cloud Services, trois services SaaS:

  • Cloud Assembly: Permet d'ouvrir du provisionning multi-cloud (Azure, AWS, VMware). Il orchestre l'infrastructure et les applications avec les principes DevOps.
  • Service broker: Presente à l'utilisateur tout son catalogue hybrid-cloud sous une seule et unique interface.
  • Code Stream: Un outil de CI/CD. Permet de tester du bout en bout le déploiement de son blueprints que ce soit côté infrastructure et/ou applicatif.

La conférence se concentre sur Cloud assembly qui permet d'offir du déploiement multi-cloud (Azure, vCenter, AWS, NSX-T, NSX-V, VMware Cloud on AWS). L'interface ressemble à s'y méprendre à vRealize Automation: On peut y déclarer ses endpoints, gérer des networks profiles, storage profiles et y créer ses propres blueprints.

L'interface de création des blueprints est très bien faite car on peut y créer directement son blueprint en mode Infra-as-code avec l'interface YAML présente sur l'UI. On peut aussi effectuer un versionning de blueprint (Impossible pour le moment sur vRA mais pourtant bien utile)!

Côté déploiement, on nous informe que le provisionning d'instances est beaucoup plus rapide que vRA car il a été optimisé pour le cloud public. On peut également peut mettre à jour les déploiements existants (Ajout d'un disque, ajout d'une VM ou d'un réseau par example).

Concernant l'extensibility, ce point a été abordé très rapidement car il est pour le moment en beta mais on retrouve les éléments suivants:

  • Integration avec Puppet
  • Action As A Service: Permet de proposer du code dans son catalogue
  • Workflow vRO

Un beau produit en perspective à suivre avec attention.

comments powered by Disqus