VMworld 2020 – Récapitulatif jour 1

Introduction

Cette année le VMworld a une saveur une peu particulière. Habituellement, 2 VMwords (un US et un EU) tiennent place chaque année avec plusieurs milliers de personnes réunies sous un même toit pendant 3 ou 4 jours. Forcément, cette année, ce format n'a pas été possible au regard de la pandémie actuellement en cours et VMware a choisi de ne faire qu'un unique évènement virtuel, qui plus est, globalement gratuit.

Pour ma part, je n'ai pas pris de pass premium (pourtant accessible financièrement parlant) car j'ai pas remarqué un intérêt majeur me concernant vis à vis du pass gratuit permettant déjà l'accès à un nombre incalculable de conférences très intéressantes.

C'est donc depuis chez moi que j'ai réservé 2 jours de temps pour assister à quelques conférences et reporter ici quelques notes prises au fil de l'eau.

VMworld General Session

• Speakers(s):
  • Pat Gelsinger, Chief Executive Officer
  • Sanjay Poonen, Chief Operating Officer

Cette première Keynote en virtuel n'aura pas apporté tellement d'autres choses que des témoignages de dirigeants louant les produits VMware, particulièrement au regard de l'année 2020 qui a provoqué des challenges intéressants.

Il est dur de commenter une vision de l'avenir des infrastructure IT ou du développement d'applications et de services. Forcément, Kubenetes est à présent l'élement central et VMware semble vouloir miser dessus bien plus que sur son business traditionnel.

Kubernetes Operators for VMware Tanzu Kubernetes Grid [KUB1248]

• Speakers(s):
  • Tom Schwaller, Technical Product Line Manager, VMware
  • Michael Gasch, Staff Engineer - Office of the CTO, VMware

Après une introduction rapide aux opérateurs Kubernetes (Kubernetes Operators) et à leurs capacités à étendre le périmètre fonctionnel de K8S, Tom et Michael nous ont expliqué que c'est fondamentalement ce que réalise Cluster API pour déployer et opérer de nouveaux clusters K8S. Chez moi on dit "eat your own dog food" et je trouve cela très intéressant de voir qu'un projet s'appuie sur ses propres bases pour s'étendre, se diversifier et s'opérer.

Un second exemple d'opérateur était shell operator permettant de jouer des commandes shell basées sur des évènements au sein d'un cluster. C'est une méthode très simple pour générer de l'event-driven au sein de votre infrastructure.

Pour avoir une meilleure vision de la diversité offerte par ce système d'opérateurs, il est possible de visiter les hub suivants:

• operatorhub.io (156 items)
• github.com/operator-framework/awesome-operators

Et bien sûr, c'est la force du monde K8S, beaucoup d'outils permettent à présent de créer des opérateurs répondants à vos besoins: Operator Framework, Kubebuilder, Kopf...

La seconde partie de la présentation se porte sur le point de vue d'un développeur de contrôleur et le rapport à l'architecture de Kubernetes. L'occasion de faire un rappel très utile comparant commande et évènement et comment fonctionne le cœur de Kubernetes qui est grandement basé sur le concept d'évènements pilotant des commandes et non l'inverse.

Lorsqu'on souhaite créer un nouveau contrôleur, il faut prendre en compte un grand nombre d'éléments:

• Autonomie: uniquement basé sur la réception d'évènements.
• Asynchronisme et concurrence by design: il ne faut pas attendre les évènements dans un ordre spécifique.
• Stateless / Stateful: etcd est le seul composant faisant autorité. Le reste des données d'état étant grosso modo du "cache" qu'il faudra réconcilier de temps à autre avec l'état d'etcd.
• Anticiper les erreurs: Il y aura toujours des pannes, des erreurs... il faut les anticiper, ainsi que les effets sur le reste de l'infrastructure: defensive programming.
• Effets de bords: Ne pas utiliser autre chose de K8S car on sort de la garantie du comportement de K8S.

La dernière partie de la présentation est une démonstration de Kopf: un projet permettant de créer des opérateurs à base de python et initialement développé par Zalando. La démonstration utilise Kopf afin de déployer des machines virtuelles au travers d'un contrôleur maison: kopf vm controller. La réactivité est impressionnante ainsi que l'apparente simplicité de décrire ses propres opérateurs et contrôleurs.

Expand Your Service Portfolio with VMware Cloud Director Extensibility [HCPS1394]

• Speakers(s):
  • Joerg Lew, Staff Technical Product Manager, VMware

On aborde dans cette présentation, un domaine que je commence à bien connaître: l'extensibilité de Cloud Director (oui j'ai envie d'écrire vCloud Director !!).

Joerg évoque la disponibilité du provider Terraform pour Cloud Director puis le projet App Launchpad qui est un plugin vCD permettant de déployer des applications pré-packagées (Bitnami, in-house apps, VMware Cloud Marketplace) en un minimum de clics.

Ce projet App Launchpad est clairement le plugin le plus abouti que j'ai pu voir (merci la force interne de VMware) avec une intégration graphique parfaite, un portail provider, une gestion des droits, d'une configuration dynamique, recherche... Malheureusement il faut imaginer la démonstration car l'enregistrement n'est pas de bonne qualité à cause d'un partage de l'écran avec la webcam du présentateur.

Le second plugin évoqué est le traditionnel Container Service Extension qui bénéficie maintenant d'une UI proposée par VMware. Ce plugin (dont la partie API n'est pas nouvelle) a vocation a permettre de déployer des clusters K8S depuis Cloud Director en quelques clics là aussi. Ayant déjà travaillé sur cette extension par le passé, je suis toujours surpris qu'il manque toujours à l'UI le support d'Enterprise PKS. La variété de services autour de K8S chez VMware fait qu'il faille peut être encore attendre une stabilisation avant de bénéficier d'une intégration plus poussée de Tanzu par exemple au sein de Cloud Director.

Edit: Finalement après avoir écrit ces quelques lignes sur CSE, je vois l'annonce de Cloud Director qui inclut la réponse à mon interrogation: Announcing Major Updates in VMware Cloud Director 10.2. vCD 10.2 arrive donc en même temps que CSE 3.0 qui supportera VMware Tanzu.

Il a bien sûr aussi été question de:

• "Service Library" qui s'appuie sur vRealize Orchestrator pour proposer tout type de service à travers l'automatisation personnalisée via cet outil: XaaS.
• "vROPS tenant portal": qui permet d'accéder à une version "par tenant" de vROPS pour les organisations de vCD.
• "vCloud Object Storage Service" offrant la mise à disposition de bucket S3-like de stockage à destination des tenants vCD (STorage as a Service, Backup as a Service, import/export de VM, vAPP, calalogues etc.)

Enfin il a été question du branding de VCD qui peut être personnalisé au travers de l'API et du kit d'exemples de personnalisation de vCD. Force est de constater qu'un effort est en cours pour rendre un peu plus accessible ce type de modification de vCD avec notamment la mise en ligne de blog post: https://blogs.vmware.com/cloudprovider/2020/02/cloud-director-plugin-dev-env.html

60 Minutes of NUMA [HCP2453]

• Speakers(s):
  • Frank Denneman, Chief Technologist, CPBU, VMware

C'est devenu ma traditionnelle séquence annuelle que de participer à 60 Minutes of NUMA: une session généralement intense en technicité pour parler d'un sujet immensément complexe: le support de NUMA (Non-Uniform Memory Access) par le scheduler de l'hyperviseur ESXi (voir la présentation de l'an passé: 2019)

On commence par un refresh sur la notion/fonctionnalité de Node-Interleaving qui permet de faire du round robin lors de l'écriture mémoire entre 2 nœuds NUMA. Cela compromet toutefois les optimisations de NUMA et ce n'est pas conseillé de l'activer (désactivé par défaut). Ivaylo Ivanov (@ivgivanov) propose sur Twitter une commande permettant de comparer avant/après l'activation de cette fonctionnalité.

Second point de la présentation: Cluster on Die (CoD) qui permet de créer 2 nœuds NUMA par socket et d'améliorer l'empreinte CPU pour les applications réalisant beaucoup d'accès aux caches mémoire (cache intensives). C'est une bonne transition pour parler de l'architecture EPYC d'AMD qui propose au sein d'un package CPU unique, plusieurs "dies" avec en EPYCv2 (aka Rome), 16 domaines de caches pour un nœud NUMA. Une architecture qui remet en question l'intérêt des multiples sockets au sein d'une unique machine.

Ensuite, Frank évoque les "3 amigos", à savoir la complexe mécanique synchronisée de 3 schedulers auxquels sont confrontés les demandes des machines virtuelles:

• NUMA scheduler
• CPU scheduler
• Memory scheduler

Cela nous amène à la notion de vNUMA qui permet de présenter la topologie NUMA à des guestOS afin qu'ils puissent, adapter leur fonctionnement pour tirer partie, au mieux, de cette configuration.

Frank s'aventure ensuite à comparer les dernières génération d'AMD et d'Intel en terme de latence d'accès à la mémoire. Une comparaison légèrement en faveur d'Intel mais selon les usages, dans certains cas, AMD s'en sort mieux.

Puis nous abordons le sujet des wides VMs qui occupent seules, au choix:

• plus de vCPU que le socket ne peut en proposer
• plus mémoire qu'un socket ne peut en adresser en local access

Enfin, la présentation se termine en évoquant les composants d'accélération matérielle rencontrés dans les datacenters modernes: notamment les accès à des cartes en PCIe. C'est pour moi l'occasion de découvrir que la notion de localité s'applique au matériel PCIe car ceux-ci sont directement connecté à un package CPU. Dans cette configuration, les workloads de machine learning peuvent devenir le pire "voisin bruyant" (noisy neighbor) de votre infrastructure en inondant le bus interconnect en cas d'accès à un remote GPU par exemple (au sens NUMA du terme remote). Pour résoudre ce type de cas de figure, Frank propose un outil permettant de faire de l'affinité NUMA/PCIe Device.

Building a Mega Cloud – Lessons Learned [HCPS2600]

• Speakers(s):
  • Ken Lamoreaux, Director Technical Product Manager, VMware
  • Martin Hosken, Chief Technologist, Cloud Services, VMware

Cette présentation s'appuie sur les bases du toolkit "vCAT" (VMware Architectural Toolkit 5.0) pour aborder la scalabilité extrême d'un cloud massif en volume ou massivement distribué.

Parmi les éléments à prendre en compte, on retrouve:

• Les VMware Configuration Maximums (ce n'est pas nouveau)
• L'objectif exact de ce qu'on tente d'atteindre comme scalabilité/performance
• Les dépendances matérielles

On aborde en surface la capacité à provisionner à bon rythme la capacité matérielle (automatisation bas niveau), la configuration de la couche logicielle primaire (vSphere, clustering...), la notion de pod (pas K8S cette fois!) matériels dont le nombre peut évoluer en fonction des besoin de ce cloud "massif" que l'on essaie de créer. Je passe sur l'usage de vROps pour surveiller la capacité et l'état de santé de nos pods ou de notre cloud car c'est un usage finalement basique et attendu de ce produit.

On fait donc le tour des produits VMware qui constituent la base d'un cloud privé ou partagé à large échelle selon le point de vue de VMware: vSAN, NSX-T, vROps, VCF (Cloud Foundation)...

La partie sur NSX-T est intéressante car on ne parle plus de concepts généraux, on parle d'architecture, de choix de design, de contraintes, de faire sauter les bottlenecks! En guise de récap, coté réseau, on nous préconise de prendre en compte:

• la forme de notre trafic réseau: beaucoup de petits paquets (telco/nfv) ou de gros paquets plus traditionnel en intra-DC?
• la capacité d'offload matériel de notre trafic: Rx/Tx filters, Geneve Offload, RSS...
• les composants matériels choisis: par exemple, afin d'atteindre plus de 40GB.s^-1 de bande passante, 2 slots PCIe sont nécessaire.

Concernant Cloud Director, j'apprends que finalement ce composant, même dans sa nouvelle forme d'appliance est finalement limité en nombre d'instance: 3 max dans le cluster de BDD et ensuite chaque nouvelle appliance en plus génère beaucoup d'accès à la base qui peuvent impacter les performances globales ressenties.

Pour ma part je suis malgré tout un peu déçu que cette présentation ne soit pas descendu plus en détails dans les entrailles d'une vraie mise en situation avec des retours d'expérience. Probablement que la valeur du niveau de technicité de cette présentation (300) a été placé un peu haut au regard du contenu.