VMworld 2020 – Récapitulatif jour 2

Conclusion

Ce n'est pas logique mais je vais conclure ce couple d'articles au sujet du VMworld avant les résumés des conférences regardées ce jour (que vous trouverez donc plus bas dans le présent article).

Forcément, un évènement en virtuel n'a pas la saveur d'un évènement en présentiel, surtout quand on apprécie de retrouver à cette occasion, des connaissances, des collègues, des partenaires de travail. Techniquement, j'aurais tout aussi bien pu regarder hors de la période du VMworld, les sessions, qui étaient déjà enregistrées et diffusées à la demande et non en live. Je précise "techniquement" car je suis à peu près certain que si je n'avais pas utiliser ces deux jours pour regarder ces sessions, je n'aurais jamais trouvé ou prit le temps ensuite de le faire, à cette échelle.

Je suis donc content d'avoir pû en profiter pendant 2 jours: de m'être nourris de nouvelles technologie, de nouveaux points de vue sur l'état de l'art des infrastructures. Je n'ai pas utilisé les moyens de mise en relation virtuelle des participants: Discord (j'étais connecté mais peu actif), Cloud City, le pass premium et les interractions avec les experts qui étaient proposées. J'ai consommé le contenu des breakout sessions et je n'ai pas participé, c'est mon seul regrêt cette année. Les explications sont multiples et personnelles. Je tâcherais de travailler là dessus si un nouvel évènement virtuel de ce type devait avoir lieu l'an prochain: j'espère que non tout de même 🤞.

La qualité des breakout sessions auxquelles j'ai assisté était variable. Je ne regarde généralement que les sessions annoncées avec un technical level à 300, mais malgré celà, il y avait peu de séance vraiment techniques et les deep dives ne sont plus forcément si complexes et si intéressants de ce point de vue. Je pense qu'il faudrait militer pour faire apparaitre un technical level de 400 histoire de pouvoir sélectionner des contenus systèmatiquement techniques.

En terme d'expérience utilisateur sur le site et les vidéos: un beau travail a été réalisé pour que le contenu soit facilement accessible, compréhensible, présenté de manière cohérente. Quelques bugs du site ont toutefois ternis un peu l'expérience, sans être trop génants. La qualité des captations était variables selon les speakers qui ont dû aussi, improviser chez eux, avec les moyens du bords (ou du moins forcément limités). Il aura manqué un verre d'eau par-ci pour faire passer une quinte de toux, des notifications slack en silencieux par là, un fond vert pour untel ou des transitions plus naturelles entre 2 speakers d'une même session. Mais globalement, c'était vraiment très bien et ce fût très apprécié.

Le dernier point (last but not least), forcément, cette année, pas de soirée(s) dans les rues, bars et boites de Barcelone. Boire un mojito seul devant mon écran de PC pendant un DJ set ne m'ayant pas particulièrement attiré, j'ai vaqué à des occupations différentes lors de mes soirées cette année.

Allez, place aux résumés de présentation de cette dernière journée:

Automate IT Processes with vRealize Automation and vRealize Orchestrator [HCMB2254]

• Speakers(s):
  • Francisco Poo Hernandez, Senior Technical Marketing Manager, VMware
  • Galina Kostova, Senior Product Manager, VMware

Cette courte session (33') propose de découvrir les moyens d'automatiser des process IT à l'aide de vRealize Automation et vRealize Orchestrator. La première explication concernant ce dernier est au sujet du support (assez récent) de langages de programmation tels que:

• Python 3.7
• PowerCLI 11 / PowerShell 6.2
• Node.js 10 et 12
• Javascript 5 (JavaScript était déjà supporté auparavant, toutefois, à chaud comme ça, le versionning ne me parle pas et ne correspond pas à celui des spécifications officielle de JS: [https://fr.wikipedia.org/wiki/JavaScript#Versions](voir l'article Wikipédia sur JavaScipt)... Est-ce un moteur ou une nu mérotation interne?)

Puis l'on aborde ABX (Action Based Extensibility) dont le but est de déclencher, via moteur d’exécution léger, des scripts en fonction d'évènements spécifiques. On est clairement dans le mode "event driven" qui devient de plus en plus présent pour les tâches simples dans le monde de l'IT.

C'est d'ailleurs un critère de choix évoqué lorsqu'on a la possibilité d'automatiser une tâche à l'aide de vRO ou d'ABX. vRO s'en sort forcément mieux pour des tâches complexes ou fortement liées à des composants variés via sa notion de plugins, de workflows enchaînant des actions pouvant êtres très variées. ABX s'adapte toutefois mieux à des tâches rapides, légères et simples et ses actions peuvent aussi être chaînées (presqu'à la manière d'un framework vRO) et c'est un produit plus orienté cloud que on-premise.

La seconde partie de la présentation concerne Code Stream, le produit de pipelines DevOps de VMware. Bon nombre de endpoints sont disponibles mais finalement la présentation s'attarde sur l'intégration de vRO et Docker dans Code Stream pour les tâches de CI.

Enfin, Francisco propose une démonstration: à partir d'une recommandation de Skyline Advisor à propros d'une menace potentielle liée aux failles Spectre/Meltdown présente sur l'infrastructure, déclencher une interaction avec vRO: déclencher un workflow qui permettra de résoudre la situation (ici il s'agit de mettre à jour le virtual-hardware de la machine). Puis la démonstration utilise Code Stream et un pipeline complexe afin de valider tous les impacts potentiels de cette action de remédiation.

Cette tâche pourra être lancée:

• Manuellement depuis le service broker de vRA
• Automatiquement lors d'une notification de Skyline Advisor

Pour ma part, je ne suis pas encore un gros utilisateur de Code Stream mais je pense qu'il constitue un wrapper intéressant pour piloter un enchaînement de workflow vRO et d'actions codées dans d'autres types de langage. Finalement, c'est un complément des développements vRO qui permet de superviser d'une autre manière l’exécution des workflows et d'un potentiel enchaînement.

Deep Dive: Troubleshooting Applications Without TCPdump [VCNC1920]

• Speakers(s):
  • Nathan McMahon, Director, Avi Enablement, VMware
  • Ashutosh Gupta, Software Architect, VMware

tcpdump est un outil qui a 35 ans et pourtant, c'est un outil qui peut aider un administrateur au quotidien quand il s'agit de troubleshooter un problème réseau, y compris lorsque vous travaillez avec de gros volumes de transfert. Toutefois, cela reste un outil basique qui nécessite:

• de savoir qu'on a un problème pour avoir à utiliser cette commande (ce n'est pas un outil qui vous détecte les pannes réseau, mais qui vous aide à comprendre ce qui s'y passe).
• de capturer le trafic au moment où le problème apparaît (pas de retour en arrière sur des mesures conservée en mémoire au fil de l'eau par exemple, pas de statistiques si l'outil n'est pas en cours d'exécution...)
• il faut un accès au segment réseau concerné par l'incident (via une VM par exemple)
• il faut avoir bien configuré tcpdump avant l’occurrence du problème pour trier au mieux les éléments de la capture

Ces contraintes semblent importantes mais en réalité, ce vieil outil est tout de même très pratique pour diagnostiquer des problèmes réseau et est presque, incontournable. Forcément, un outil de 35 ans va être limité à appréhender les évolutions récentes du contenu qui passe sur les réseaux: HTTP/2, SSL presque partout, volumes démultipliés... c'est possible, mais ça devient complexe.

De nouveau outils lui font à présent concurrence pour mieux appréhender ses limites et contraintes: vRealize Network Insight par exemple permet de faire bien plus de chose, via des échantillonnage, de l'apprentissage, des sondes positionnées sur des segments multiples, de la conservation de métriques...

Avec les logs de VMware NSX-T Advanced Load Balancer (ex AVI) il est aussi possible de collecter des informations très intéressantes au moment de diagnostique un souci qui pourrait être lié au réseau, sur une application. C'est l'objet de la démonstration qui suit et qui vise à montrer la manière de détecter, au sein d'un pool applicatif, de potentiels erreurs ou problèmes de performances. Frocément, ce produit permet de faire énormément plus de chose que tcpdump, notamment si on veut mesurer l'état d'une application distribuée, au delà de l'état d'une simple connection réseau.

NSX-T Container Networking Deep Dive [VCNC1163]

• Speakers(s):
  • Yasen Simeonov, Senior Technical Product Manager, VMware
  • Ali Al Idrees, Lead EMEA SDDC Solutions Architect, VMware

Ce n'est plus très nouveau, VMware vise depuis quelques années à pousser NSX-T pour tous les types de workload d'une infrastructure, que vous utilisiez du bare-metal, de la virtualisation, du Kubernetes... L'intégration avec ce dernier type de workload est à présent plutôt mature et permet à présent de partager un Shared T1 router entre namespaces différents (avant le seul modèle était de déployer un routeur T1 par namespace).

Avec NSX Container Plug-in (NCP), NSX-T DataCenter peut être à la fois intégré avec K8S, OpenShift, Pivotal Cloud Foundry etc. Cette intégration permet par exemple d'utiliser:

• Persistance de règles de IP par service (K8s)
• Les metadata de K8S au sein de NSX sous forme de tags qui sont propagés automatiquement pour la réalisation de règles de sécurité.
• des règles de sécurité dans les description de service K8S
• Load Balancing intégré...

Ensuite la présentation aborde Tanzu Application Service et notamment la partie réseau et sécurité: comment sont provisionnés les segments réseau, les routeurs T1, l’interconnexion via le T0, la création de nouveaux segments réseaux par tenant (Org).

Avec vSphere with Tanzu (vSphere 7) il devient possible de mixer pods et machine virtuelles au sein d'un namespace ce qui rend plus cohérent l'administration générale, tout en rendant un peu complexe, la liste de couches d'infrastructures impliquées:

Si vous préférez OpenShift (4), l'intégration est presque aussi aboutie et un projet d'opérateur spécifique pour NSX-T est en cours de développement dans les équipes VMware (ou de Red Hat, ou des deux, ce n'était pas clair).

La présentation se termine avec une démonstration de la Hipster shop, une pseudo-boutique en ligne dont l'architecture utilise massivement les micro-services. Au cours de la mise en place de cette boutique virtuelle sur un cluster OpenShift, on peut voir les interactions avec NSX-T, l'arrivée de nouveaux ports sur les segments, la création de règles de sécurité etc. L'usage de l'outil Traceflow intégré à NSX-T permet aussi l'analyse de potentielles erreurs réseau: ici une règle de sécurité bloquait le flux espéré.

VMware Cloud Foundation Deep Dive [HCI2519]

• Speakers(s):
  • Jason Shaw, Senior Technical Marketing Architect, VMware

La solution de base pour une architecture standardisée de SDDC chez VMware s'appelle "Cloud Foundation". Basée sur la recommandation d'utiliser des nœuds matériels 'vSAN ready', cette manière de concevoir et déployer un socle standard d'architecture permet de s'affranchir des silos de complexité généré par des choix opérés au fil de l'eau, des besoin, des projets, des changements d'avis.

Grace à des tests poussés coté VMware, vous avez une sorte de garantie vis à vis d'une association de produits et de versions:

Issu des VMware Validated Designs, le concept Application Virtual Networks (AVN) (des overlay réseau dédiés pour une solution applicative) est fortement utilisé pour vCF.

Un certain nombre de tâches plus ou moins complexes de la vie d'un SDDC sont aussi prises en charges par VCD telles que:

• Le déploiement de Edge NSX (HA, password management, lifecycle management...)
• La configuration de vSAN et vVol (ce dernier depuis vCF4.1)
• L'ajout de nouveaux hosts (scale-out) sur les workload domains

Une démonstration de ce dernier point permet de voir ce qui est requis pour démarrer ce type de tâche: grosso modo, un fichier json avec les FQDN des hosts (installés!) et leur infos d'authentification. Une bonne dose de vérifications sont tout de même à réaliser en amont: la checklist est proposée dans le wizard de vCF.

Bien sûr, Cloud Foundation propose aussi d'aider pour gérer le cycle de vie des composants déployés: notamment pour mettre à jour les composants, les certificats SSL.

Les API (et le Developer Center) disponibles sur vCF permettent d'automatiser certaines opérations sans même passer par l'interface graphique.

Enfin, on nous présente la notion de True Hybrid Cloud, une promesse de VCF pour que vous puissiez envisager de migrer toute ou partie de votre SDDC vers des providers compatibles (on pense forcément à VMware on AWS!) à l'aide de HCX.