VMworld 2019 – Récapitulatif jour 3

Delivering Custom Services Through vCloud Director Extensibility [HBI1855BE]

• Auteur de la notice ci-dessous: Ludovic Rivallain
• Speaker(s):
  • Nick de Kuijer, Cloud Architect, Simac IT NL
  • Martin Hosken, Principal Architect, VMware
  • Milko Slavov, Staff Engineer, VMware
• Vidéo

Je ne vais pas le cacher, c'était la présentation que j'attendais le plus de ce VMworld! Étant donné que je travaille sur le sujet de l'extensibilité de vCloud Director depuis plus d'un an (voir le post à ce sujet Extending VMware vCloud Director functionalities), j'avais de hautes attentes concernant les méthodes utilisées par d'autres personnes pour réaliser le même type d'extensions d'UI et d'API.

La présentation a commencé avec une description générale du concept d'extension des API et de l'UI du portail. Et de citer quelques exemples de use-case (notamment avec la très belle intégration réalisée par Avamar). Il y a aussi eu une annonce d'un nouveau framework permettant la création d'intégrations plus poussées des extensions (notamment la possibilité d'ajouter des actions contextuelles sur des objets de l'inventaire) et plus facile à mettre en œuvre.

Nous avons eu ensuite une démonstration un peu plus technique d'un Backend as a Service qui n'a pas été très clairement expliquée à mon avis.

Enfin, Nick de Kuijer, Cloud Architect @ Simac IT 🇳🇱 a démontré un exemple d'extension permettant la mise à disposition des logs Firewall NSX dans le portail vCD, pour les utilisateurs. Leur permettant ainsi de pouvoir analyser si une requête est légitimement bloquée ou pas. Puis un mécanisme de déploiement de VM personnalisé permettant d'adapter la zone de disponibilité, le type d'instance…

Evolving vRealize Automation [HBO1323BE]

• Auteur de la notice ci-dessous: Ludovic Rivallain
• Speaker(s):
  • Chris McClanahan, Staff Technical Marketing Architect, VMware
  • Liad Ofek, Director, Product Managerment, VMware
• Vidéo

Note à moi-même pour l'année prochaine: ne pas aller à des conférences de niveau technique 100 ou 200. Jamais. Même quand le sujet semble passionant.

C'était le cas de cette présentation de vRealize Automation 8.0. J'en attendais beaucoup car vRA est un produit très utilisé par nos clients et sur lequel nous passons nous-même beaucoup de temps pour y réaliser de l'automatisation. Et comme le changement 7.x > 8.0 s'annonce majeur, il vaut mieux se renseigner au maximum au plus tôt.

Pour résumer tout de même les informations majeures:

• vRA a été totalement réécrit pour réduire sa complexité de déploiement. Les services IaaS ont notamment disparu.
• L'installation et la maintenance de vRA s'appuyent à présent sur Life Cycle Manager et la gestion d'identité sur le Identity Manager.
• Tous les services vRA sont à présent devenus des services basés sur Kubernetes.
  • J'ai tout de même un doute sur les services PostgreSQL et RabbitMQ car la slide n'était pas limpide du tout.
• L'apparition de FaaS (Function as a Service) comme nouveau support à l'extensibilité, au coté de vRO. Par exemple AWS Lambda mais pas que.
• Une intégration git complète pour les éléments du catalogue de service!

VMware indique clairement que cette version 8.0 est une version qui n'est pas à mettre en production car elle manque de maturité. Il faudra donc attendre au moins la version 8.1, premier semestre 2020. La migration de quelques données de plateformes 7.5 ou 7.5 ne sera elle disponible qu'à partir de la mi-2020. C'est un gros gros challenge pour nos clients qui avaient misés sur l'extensibilité de vRA 7.x et ne pourront probablement pas réutiliser beaucoup de ces efforts en vRA 8.x…

The Art of Code That Writes Code [CODE2216E]

• Auteur de la notice ci-dessous: Ludovic Rivallain
• Speaker(s):
  • Kyle Ruddy, Senior Technical Marketing Architect, VMware
• Vidéo

Qui ne rêve pas d'un outil permettant de générer d'autres outils du même type tout en écrivant le moins de code possible. Vous décrivez une nouvelle API, c'est déjà un beau travail. Et vous devez en plus coder des clients ou des SDK pour utiliser cette API en ligne de commande par exemple? C'est un doublon de travail qui peut être évité.

On recommence: Vous décrivez une nouvelle API en la documentant au fur et à mesure. Par exemple en réalisant un fichier de description swagger. Ensuite, il suffit de faire digérer ce descripteur à un outil comme autorest (Azure) pour obtenir un client ou un SDK en C#, NodeJS, Python, Java, Ruby, Go, TypeScript…

Kyle nous a proposé un exemple basé sur l'API xkcd et la génération d'un client en PowerShell. Exemple: Get-XkcdComic.

L'occasion de rappeler que les API vSphere évoluent dans le bon sens (c'est à dire vers plus de REST, moins de SOAP!) et que VMware propose nombre de SDK dans différents languages: vsphere-automation-sdk.

Kubernetes Operators for VMware Enterprise PKS and VMware Cloud PKS [CODE1360E]

• Auteur de la notice ci-dessous: Christian Tritten
• Speaker(s):
  • Michael Gasch, Application Platforms Architect - Office of the CTO, VMware
  • Tom Schwaller, Technical Product Line Manager, CNABU, VMware
• Vidéo

Plongée en détail sur ce qu'est un Operator, à quoi ça peut servir et comment en écrire. Les Operators couplés aux Custom Resource Definitions sont un moyen extrêmement puissant d'étendre l'api de Kubernetes pour introduire des logiques métiers complexes :

• Les Custom Resource Definitions permettent de déclarer de nouveaux types de Ressources que Kubernetes va pouvoir gérer de la même manière que ses Ressources natives. Une fois la CRD déclarée, il devient possible de créer des objets (Custom Resources) de ce nouveau type. La validation des Customs Resources créées par les utilisateurs se base sur la spécification OpenAPI 3.0.
• Les Operators sont des Controllers Kubernetes (du code exécuté dans des Pods) qui surveillent les évènements liés aux Custom Resources et implémentent la logique métier pour réaliser des tâches complexes (comme par exemple le déploiement d'un système de base de données en cluster, la gestion de la sauvegarde des base ou encore l'ajout de nouveaux noeuds au cluster).

Il existe plusieurs frameworks pour faciliter le développement d'Operators.

La démo montre comment utiliser le framework Kopf, développé par Zalando, pour écrire un Operator qui va créer des VMs sur vSphere via des CR de type VMGroup.

Project Pacific: Guest Clusters Deep Dive [HBI4500BE]

• Auteur de la notice ci-dessous: Christian Tritten
• Speaker(s):
  • Derek Beard, Senior Staff Engineer, VMware
  • Zach Shepherd, Staff Engineer II, VMware
• Vidéo

Cette session expose en détail le projet Pacific.

Kubernetes as a platform platform
-- Joe Beda

Project Pacific is a re-architecture of vSphere with Kubernetes as its control plane.
-- Jared Rosoff

Kubernetes devient un élément central de vSphere via l'introduction d'un composant d'orchestration nommé Kubernetes Cluster Supervisor. Le Supervisor utilise ESXi comme worker nodes au lieu de Linux. Ceci passe par une implémentation spécifique de Kubelet, nommée Spherelet qui tourne directement sur ESXi. Il devient ainsi possible de faire tourner des Pods kubernetes natifs sur ESXi avec des performances impressionnantes (30% plus rapide que des Pods tournant dans des VMs Linux, et 8% plus rapide que des Pods tournant sur du bare metal Linux, ceci grâce à des optimisations sur la gestion de la mémoire et du cpu).

D'autre part, le Supervisor se base sur des CRDs et Operators spécifiques (Machine, MachineSet, MachineDeployment, Cluster, ManagedCluster) afin de permettre de gérer des objets vSphere via des fichiers de description de ressources au format Kubernetes. Des Operators dédiés comme le VM operator ou le Guest Cluster Operator offrent la possibilité d'orchestrer le déploiement et cycle de vie de :

• Machines Virtuelles,
• Clusters Kubernetes Managés (dit 'Guest clusters').

Il devient ainsi plus facile de séparer les préoccupations entre les Ops qui déploient l'infrastructure et les développeurs qui vont accéder à des VMs et des clusters Kubernetes à la demande via des ressources de type Machine, ou ManagedCluster.

The Circle of (Token) Life [CODE3332E]

• Auteur de la notice ci-dessous: Christian Tritten
• Speaker(s):
  • Dan Illson, Staff Native Cloud Advocate, VMware
• Vidéo US

Dan Illson présente la gestion de données sensibles dans Kubernetes avec Hashicorp Vault. Il rappelle que les Secrets dans Kubernetes sont simplement encodés en base64 mais pas du tout chiffrés ce qui pose des problèmes en matière de sécurité. De plus l'accès aux secrets manque cruellement de granularité.

L'outil Vault vient compléter la gestion des secrets avec tout un panel de fonctionnalités comme le chiffrement, la rotation des clés, l'expiration ou la révocation d'un secret, secrets dynamiques, etc...).

NSX-T Deep Dive: Kubernetes Networking [CNET1270BE]

• Auteur de la notice ci-dessous: Christian Tritten
• Speaker(s):
  • Ali Al Idrees, Lead EMEA SDDC Architect, VMware
  • Yasen Simeonov, Senior Technical Product Manager, VMware
• Vidéo

Après une brève présentation de Kubernetes, cette session expose comment l'intégration du réseau NSX-T avec Kubernetes permet de gérer l'ensemble des problématiques réseau (adressage des Pods, cloisonnement entre namespaces, loadbalancing L4 et L7, firewalling) via les ressources Kubernetes habituelles (ns, networkpolicies, ingresses).

Le composant NSX Container Plugin (NCP) est chargé d'assurer la traduction (ainsi que la synchronisation) des règles définies dans les objets Kubernetes vers les règles NSX-T correspondantes. Le composant NCP se présente sous la forme d'un Pod qui est exécuté directement dans le cluster Kubernetes.

Service Mesh, Tracing, Prometheus: Wavefront Provides Observability for All [KUB1862BE]

• Auteur de la notice ci-dessous: Christian Tritten
• Speaker(s):
  • Chhavi Nijhawan, Product Line Marketing Manager, VMware
  • Nikolay Nikolaev, Open Source Networking Team Lead, VMware
• Vidéo

Cette session commence par une introduction aux concepts de service mesh, de distributed tracing et de monitoring dans Kubernetes. Ces outils se révèlent utiles lorsqu'on l'on commence à déployer des applications fortement orientées microservices.

On présente ensuite l'outil Wavefront, et comment celui-ci peut venir s'interfacer avec les outils opensources istio, jaeger/zipkin, et prometheus. Wavefront se propose d'enrichir les fonctionnalités de ces outils mais aussi de permettre leur utilisation dans une interface unifiée. Wavefront fourni en outre plus de 200 intégrations pour ingérer des métriques et des logs de toute provenance.

La démo présente un cas d'usage d'observabilité en démontrant comment repérer d'où provient une latence dans une application microservices via la combinaison du monitoring pour la détection du problème, du tracing pour l'analyse d'une requête de bout en bout et de l'analyse des logs pour trouver la cause précise du problème. Tout cela sans quitter l'interface web de Wavefront.

NSX-T Deep Dive : L3 Routing [CNET1069BE]

• Auteur de la notice ci-dessous: Jérémy Rossignol
• Speaker(s):
  • Amit Aneja, Senior Technical Product Manager, VMware
• Vidéo

Ici nous avons eu un cours accéléré sur le rroutage au sein de NSX-T. Petit rappel, toujours pour commencer un logical router NSX-T est constitué de deux composants le DR et le SR.

Le DR ou Distributed Router s'éxecute localement sur les transport nodes. Une transport node cela peut être à la fois un ESXi ou un hyperviseur KVM qui hébergeront vos VMs clientes mais cela peut être aussi une edge node qui elle hébergera vos logical router. Le SR ou Service Router lui s'éxecutera seulement sur les edge nodes.

Le DR comme son nom l'indique est distribué sur votre plateforme et permet de faire tout le travail de routage. Le SR quant à lui va se déployer automatiquement lorsque vous aurez configuré un service sur l'un de LR que ce soit T0 ou T1, il n'est pas distribué mais centralisé.

Voilà si on récapitule déjà ce petit rappel qui a lui tout seul vous donne certainement déjà des cheveux blancs :

• NSX-T c'est du tier routing avec des routeurs T0 et T1, T0 permet de se connecter au réseau physique et T1 est fait pour se connecter à vos workloads
• Un logical router T0 ou T1 est composé d'un DR ET d'un SR si on configure un service dessus (Connexion au physique, routage dynamique, LB, VPN, NAT, Firewall,DHCP, DNS Forwarder, Metadata Proxy)
• DR : routage distribué
• SR : service, centralisé

Ensuite maintenant que vous avez les bases, parlons un peu des edges nodes qui dans NSX-T peuvent être à deux formats, baremetal ou VM. ces edges nous allons donc les déployer grâce à un ova sur des ESXi ou directement sur un serveur baremetal. L'utilité de la edge node, c'est d'héberger vos logical router T0 et T1 qui ne sont plus des VMs au sens propre mais plutôt des micro-services au sein de votre edge node.

Parlons maintenant un peu de routage, nous pouvons faire de l'Equal Cost MultiPathing avec NSX-T et notament les T0, par contre si vous voulez faire de l'ECMP, il faudra impérativement utiliser le Bidirectional Forwarding Detection (BFD) en BGP. Si vous êtes dans un cas ou vous avez plusieurs T0 en HA active/active alors dans ce cas les échanges de routes entre vos deux SR T0 se feront via iBGP. Chose importante, le routage dans NSX-T se fera toujours au plus proche de l'émetteur, si vous avez une VM qui émet une trame qui a besoin d'être routée, le routage se fera toujours sur le DR de l'ESXi qui héberge la VM.

Prenez en considération que vos uplinks sur vos T0 serviront toujours à se connecter au réseau physique et que vos T1 auront toujours, ou du moins quand ils sont connectés au T0, une route par défaut vers votre T0.

Bon alors tout cela c'est très technique, je vous recommande comme Amit d'ailleurs d'aller voir les Design Guides.

Petite nouveauté de la version 2.5, les failure domains pour les edge clusters (ensemble de edge nodes), vous pouvez maintenant définir au sein d'un même cluster edge 2 failure domains qui représenteront par exemple deux racks différents dans votre datacenter, ce qui permettra lorsque vous utilisez du HA d'avoir vos instances T0 sur différents racks en cas de panne cela peut être utile :) Je parle ici seulement de T0 car il n'ya que les T0 qui peuvent être en mode active/active.

Enfin le plus possible il faut installer vos services au plus proche du workload, c'est à dire le plus possible sur vos T1 pour permettre d'avoir vos T0 en mode active/active car vous ne pouvez pas faire de active/active sur vos T0 si vous installez des services dessus.

Si vous voulez aller plus loin voici les conférences que vous pourrez aller voir:

• Network Virtualization and NSX-T - A technical Overview [CNET1582BE]
• NSX-T Deep Dive: Logical Switching [CNET1511BE]
• NSX-T Deep Dive: Load balancing [CNET1356BE]
• NSX-T Deep Dive: Connecting Cloud and Data Centers via NSX-T VPN [CNET2841BE]
• Apply Consistent Security Across VMs, Containers, and Bare Metal [SAI1017BE]

Solutions Exchange

• Auteur de la notice ci-dessous: Jérémy Rossignol

Cette année j'ai voulu prendre le temps d'aller faire un tour et discuter au Solutions Exchange sur les différents stands des éditeurs.

Voici quelques technos auquelles vous devriez penser si vous cherchez de nouvelles solutions, évidemment ce n'est que mon avis et je invite à vous faire votre propre avis sur ces technos :

• AVI Networks : appliance virtuelles de load balancing concurrente de F5 et racheté tout récement par VMware
• Rubriq : j'ai eu l'occasion d'avoir une petite démo du produit avec une discussion technique très intéressante, pensez-y si vous souhaitez changer votre solution de sauvegarde.
• Datacore : vous souhaitez faire du stockage hyperconvergé, franchement j'y allais un peu à reculons mais finalement ce produit a l'air d'être une alternative à VSAN très intéressante, en plus elle vous permettrait de réutiliser vos anciennes baies de stockage.
• Cohesity : de la même manière que Rubriq, pour moi ces 2 éditeurs sont en train de faire bouger le monde de la sauvegarde, ce sont vraiment des solutions à prendre en compte lors du choix de votre future solution de sauvegarde.