VMworld 2018 – Recapitulatif jour 2

Ludovic Rivallain calendar Nov 6, 2018  · 13 min read  ·
Share on: linkedin copy
vmware vmworld

Second jour, beaucoup plus de monde, une General Session folle et toujours plus de conférences:

#DEV3466BE – Putting It All Together: Using VMware Products to Deliver the DevOps Dream

Cette conférence avait pour but d'expliquer comment utiliser les produits VMware dans un processus de transformation en méthodologie DevOps.

vCenter configuré en multi-tenants avec des resourcesPools et des droits adaptés aux publics de votre société, vRA avec business groups etc., Code Stream pour les pipelines et l'automatisation de tâches répétitives: tout est là. Mais force est de constater qu'il manque à mon avis (@lrivallain speaking) du liant entre ces outils, et qu'obtenir une infrastructure as code dans ces conditions nécessite un investissement de temps assez important.

Tout est automatisable, mais il manque peut être de la part de VMware, un peu d'outillage ou de simplification des process internes des produits pour rendre ça: convenable et attractif pour une transformation DevOps.

#NFV2220BE – Service Providers Love VMware Integrated OpenStack. Here's Why.

Alors qu'on pourrait penser qu'en principe, OpenStack et VMware ne cohabitent pas sur les mêmes segments de marché, visiblement, ce n'est pas le point de vue de VMware qui espère proposer avec VMware Integrated OpenStack (VIO) des réponses à quelques challenges et difficultés rencontrées dans le déploiement de la solution OpenStack.

Pour rappel, la promesse du projet OpenStack est la suivante: Open Source, Cross Vendor, Standard, Software Defined DataCenter

Toutefois dans la mise en œuvre, certains challenges peuvent être rencontrés:

  • Segmentation des solutions possibles: the snowflake effet (un challenge rencontré très souvent dans le milieu des ESN et leurs réponses possibles à une demande d'expertise autour d'OpenStack
  • Monitoring et Opérations: difficulté à troubleshooter et peu d'outils disponibles et efficace: haut niveau de technicité nécessaire.
  • Upgrades complexes...

La réponse de VMware est VIO (actuellement en version 5.0) en mêlant le meilleur des mondes VMware et d'OS: En gros il s'agit de mettre en place, en amont d'un DataCenter VMware, les API standards d'OS pour gérer, les instances, le compute, le stockage, le réseau et les métriques.

Pour le moment, les produits suivants sont disponibles (en version 2018.02):

  • nova
  • cinder
  • neutron
  • glance
  • swift

Et finalement, à travers la surcouche VMware, vous opérez, sans le savoir, un cloud basé sur vSphere/vCenter/NSX tout en utilisant les commandes ou les API d'OpenStack.

#HCI1552BE – Deploying vSAN to 300 Stores in 2 Weeks: An Automation Story

Nigel et Simon souhaitaient par cette conférence, revenir sur un projet d'automatisation réalisé pour un de leur client: un global food retailer (seulement la 3e chaine de supermarché au monde, 6800 magasins, 440 000 employés).

Le but était d'implémenter une plateforme résiliente, sous la forme d'un canvas, où les développeurs pourraient librement déployer des VMs et des containeurs. Et par ce fait, de remplacer l'existant qui commençait à dater.

Le choix de la solution s'est porté sur des clusters (par magasin) de 3 nœuds vSAN, un uplink unique (10GBps) par nœud (simplicité!). Le tout a été groupé en pod (1000 magasins par pod) avec pour chacun: 2 vCSA small, 2 vROPs, et un serveur vRO. Ensuite à coup de clé USB bootable, d'un très gros workflow vRO (et c'est là qu'est la magie: Voodoo part!), tout est préparé presque automatiquement (seulement les variables à changer en fonction du lieu) quand un technicien débarque dans un magasin avec son nouveau matériel.

Etonnant, VMware a conservé une approche semi-automatisée: certains inputs viennent d'un être humain afin de lancer le workflow et sont gérées déploiement par déploiement… le risque d'erreur est présent et c'est étonnant de n'avoir pas poussé plus loin la logique d'automatisation.

Bilan de la conférence: que ferait VMware sans vRO au niveau automatisation 🤔?

#HYP1499BE – VMware Cloud Provider Pod

Au tout début de cette présentation, VMware a insisté une nouvelle fois sur leur politique d'hybridation et de moderniser le cloud VMware.

Qu'est-ce qu'est Cloud Provider Pod (CPOD)?

Un outil qui permet de déployer (avec encore seulement un clic) toute une infrastructure pour un cloud provider basée sur la suite vRealize et vCloud Director. Les produits déployés par CPOD 1.0 sont les suivants:

  • vRO 7.4
  • vROPS 7.0
  • vCD 9.1
  • vCD Extender 1.0.1
  • Usage meter 3.6.1
  • vRNI 3.9
  • vRLI 4.6.1
  • vSphere 6.5u2
  • NSX 6.4.1
  • vSAN 6.6.1

La prochaine release de CPOD intègrera des versions plus récentes.

Tout comme Vmware Cloud Fundation avec les VMware Validated Design, CPOD permet d'offrir une infrastructure destinée aux cloud providers avec la certification VMware cloud verified.

Le déploiement de l'infrastructure se fait à travers un formulaire ou avec un fichier de configuration . Le formulaire se décompose en 8 étapes qui vont du choix du nombre d'hôtes ESXi en passant par la configuration VXLAN jusqu'au licensing.

A la fin du déploiement, un package d'une dizaine de documentations est automatiquement généré suivants les inputs définis lors du déploiement. On retrouve ainsi les documentations suivantes (liste non exhaustive):

  • Logical design
  • Configuration réseau
  • Configuration guide vCD
  • Configuration guide vROps
  • Configuration guide VCD Extender
  • Config Sheet
  • Export de la configuration
  • Export package vRO

Pour ce qui nous a été montré, les documentations ont l'air d'être vraiment claires et détaillées. On nous explique ensuite que le déploiement de l'infrastructure se fait en bonne partie à travers vRealize Orchestrator et que l'on peux extraire ce package et voir en détail ce qu'il fait (voir même de l'adapter à nos besoins).

Il n'y a plus qu'à explorer ce produit plus en détail sur les HOLs et voir s'il tient ses promesses!

#NET1559BE – SDDC Reference Design with NSX Data Center for vSphere

Cette conférence était là pour nous rappeler les bonnes pratiques et surtout s'avoir s'orienter au début d'un design avec le produit NSX. De là on nous fait un petit rappel sur les avantages de NSX et notamment qu'il est complètement agnostique des équipements réseaux, mis à part peut être le fait que pour certaines fonctionnalités notamment le hardware VTEP, il faut quand même du matériel spécifique validé par VMware.

Ensuite petit retour sur les différents composants de NSX et aussi de là où il se trouvent entre le data plane, control plane, management plane et enfin consumption. Jusque là aucune surprise, on insiste toujours autant sur le fait que dans le cadre de NSX il y'a toujours un seul NSX manager avec 3 controler pour un vCenter.

Suivi ensuite par un petit what's new de NSX 6.4.x, et on notera le passage à l'interface graphique en HTML5 -que VMware est en train de généraliser à tous ses logiciels), sinon globalement c'est une version de correction de bug et d'augmentations de limites diverses, pas de grosse fonctionnalités avec cette version.

Passons maintenant au vif du sujet, le speaker nous rappelle bien que notre bible doit être le fameux design reference guide que l'on peut trouver à cet endroit. Néanmoins, il va nous faire part de quelques points qui peuvent être imprécis dans ce guide.

Voici quelques une de ses recommandations:

  • A partir du moment on utilise un domaine avec plusieurs vcenters, il faudra penser à utiliser un cluster de management dédié ainsi qu'un vcenter dédié pour celui-ci
  • On peut provisionner le mangement, vmotion, stockage mais aussi les portgroups VXLAN sur le même dvSwitch (VDS), on fera juste attention au fait qu'ils ne reposent pas tous sur le même vmKernel
  • On doit utiliser le même numéro de VLAN pour le VXLAN sur tous les clusters NSX
  • Les jumbo frames doivent être configurés sur les ESXs (passage du MTU à 9000)
  • Transport zone unicast recommandée sauf si vous disposez d'un grand domaine niveau 2 et dans ce cas on préférera utiliser le mode Hybrid

Toutes ces recommendations sont bien sûre à prendre en compte avant l'installation mais pour ce qui est du design du produit NSX en lui même et la configuration à apporter sur les clusters de ressources, j'ai noté quelques remarques intéressantes:

  • Le même VDS pour tous les clusters de ressources
  • Pas de edge ECMP sur le même ESXi qu'un DLR control VM
  • Pour une edge ECMP, configurer 2 uplinks avec 2 VLANs différents pour diminuer les interruptions potentielles
  • Surtout si possible éviter le VPC car ce protocole (sauf dans des design bien particuliers) sera plus contre-productif qu'autre chose

Bilan de la conférence: plusieurs points intéressants, des rappels qui ne font pas de mal, des points de vigilance de configuration mais aussi d'installation et de design qui ne sont pas forcément explicites et que l'on acquiert en général seulement avec de l'expérience. En somme, c'était plutot positif, tout ça.

#NS3729KE – The NSX Keynote: Building the Network of the Future with the Virtual Cloud Network

  • Auteur de la notice ci-dessous: Jérémy Rossignol
  • Vidéo
  • Speakers:
    • Tom Corn, SVP, VMware
    • Tom Gillis, SVP/GM, Network & Security, VMware
    • Sanjay Uppal, Vice President & GM , VMware
    • Stefano Firenze, CIO CNH Industrial, CNH Industrial
    • Ed Higgs, Global Service Delivery Director, Rentokil Initial
    • Faiyaz Shahpurwala, General Manager, IBM Cloud Platform, IBM
    • Jean-Marc Voisin, CTO, ALLIANZ

Le but ici était de donner un aperçu de ce que fait NSX et comment il répond aux problématiques des clients.

On a pu voir pour les différents produits NSX: NSX Data Center (NSX-v), NSX Cloud (NSX-T), NSX Hybrid connect, NSX SD-WAN by velo cloud et enfin AppDefense, différents usecases clients présentés sous forme de talk pour illustrer les mises en pratique de chaque produit.

Personnellement, le format ne m'a pas enchanté et plutôt que d'annonce(s), la discussion client/fournisseur manquait un peu d'intérêt car les informations qui auraient pû être intéressantes ont été noyées dans les dicsussions.

Néanmoins, un produit a attiré mon attention: AppDefense. Il s'agit d'un nouveau produit de VMware permettant d'analyser les processus côté OS et de définir des profils de serveurs pour reconnaître les comportements normaux des comportements suspects.

En effet, jusqu'à maintenant pour se protéger contre des attaques, le comportement standard des antivirus était d'avoir une liste de "Know bad" (sous-entendus, des comportement suspects identifiés au préalable par le passé comme des bouts de codes malveillants par exemple). Avec AppDefense*, l'idée ici est d'utiliser la philosophie "know good" pour réduire le périmètre possible d'une attaque.

Pour rajouter ce "know good", voici comment on procède:

  1. A l'installation d'un serveur, une fois tous les applicatifs installés et configurés, il vous suffit d'analyser les processus détectés par AppDefense et de cliquer sur un bouton pour établir qu'il s'agit du profil "normal" du serveur.
  2. A partir de ce moment, si il y'a une attaque extérieure et un comportement qui sort du profil standard, les services seront automatiquement bloqués par AppDefense grâce au machine learning.

Le machine learning permet d'avoir une vue en temps réel du comportement d'un serveur et de ces services, ainsi il est possible de mettre en place de manière très simple de la micro segmentation: plus seulement au niveau échanges Est-Ouest mais aussi au niveau applicatif.

Bilan de la conférence: je dirais que le format ne correspondait pas du tout à une keynote mais il y'a des moments où le fond est plus important que la forme.

#NET1516BE – Introduction to NSX Cloud

Le but de NSX Cloud est de pouvoir protégé de manière centralisée toutes vos apps tournant sur des clouds publics. Un des avantages de NSX Cloud est que vous n'avez pas besoin d'avoir l'édition datacenter au sein de votre infrastructure et que pouvez commencer de 0 avec NSX Cloud. Vous allez pouvoir étendre vos politiques de sécurité sur vos clouds publics et les gérer de manière centralisée et homogène (Actuellement, seulement Azure et AWS sont supportés) via une seule unique interface graphique ou une seule API.

En reprenant les technologies NSX pour manager ses politiques de sécurité sur Azure ou AWS par exemple, il est possible d'utiliser les règles 'dynamiques' propre à NSX et ainsi être plus réactif pour les besoins des développeurs.

Par exemple: Dès qu'une machine virtuelle portera dans son nom DEV, elle pourra être placer dynamiquement dans une règle qui aura déjà tous les accès de BDD configurés pour que la machine soit opérationnelle et prête à être utilisée sans pour autant être ouverte à tout le réseau.

Si un bypass des règles de firewall distribuées est identifié, la mchine sera mise dynamiquement dans une autre "policy" de quarantaine par exemple qui bloquera absolument tous les flux entrants et sortants. Il sera nécessaire d'avoir une intervention d'un administrateur pour la débloquer. Il est aussi possible de faire apparaître cette machine directement sur le dashboard et pour la mettre en évidence.

A prendre en compte pour un déploiement, le nombre de VMs à déployer:

  • NSX Manager: 1 VMs
  • Control Cluster: 3 VMs

Viens ensuite la connection aux différents cloud publics qui permet de déployer des edges gateways permettant de filtrer l'accès Nord-Sud de votre cloud public. Et enfin, vient le déploiement d'agents NSX sur les VMs afin de mettre en place des politiques de firewall distribué.

Les VMs n'ayant pas d'agent installé seront détectées comme étant non conformes et il est possible de lancer à distance l'installation de l'agent ou encore de l'ignorer si l'on estime que telle ou telle VM n'en a pas besoin.

Le produit semble vraiment intéressant: notamment le fait de pouvoir réutiliser la micro-segmentation NSX avec les groupes de sécurité dynamiques (et non plus uniquement via une information réseau, IP ou DNS). Il reste à voir si VMware arrivera à généraliser ce produit de manière simple malgré la multitude d'offres cloud qui existent sur le marché.

#EDU7505E – Advanced Troubleshooting for the VMware NSX Distributed Firewall

You shall not pass !

Voilà ce que l'on attend de notre firewall et c'est sur ces 4 petits mots que commence la session. L'utilité de notre firewall distribué est bien d'empêcher les attaques sur nos systèmes mais aussi les empêcher de pouvoir rebondir depuis un serveur via une porte dérobée.

Néanmoins sans les bons outils il peut être difficile de bien diagnostiquer les problèmes de communication. La difficulté lorsque l'on met en place la micro segmentations avec le firewall distribué est bien de s'assurer que l'on ne va pas contraindre les applications et se créer de nouveaux problèmes.

Le sujet ici est de savoir analyser en temps réel ce qui se passe au sein de notre infrastructure au niveau réseau et firewalling.

NSX introduit des outils qui nous permettent de répondre à cette problématique:

  • Flow Monitoring: Grâce à lui il est possible d'analyser en temps réel via une interface graphique le traffic réseau. Il permet aussi de bloquer ou d'autoriser via un simple clic le traffic affiché.
  • Traceflow: Cet outil permet de tester la communication depuis un source vers une target donnée par le port que on lui indiquera.
  • Packet Capture: Comme son nom l'indique, il va permettre de capturer les trames à la manière d'un wireshark.
  • Et bien sûr dans l'interface graphique de NSX vous disposez aussi de l'event viewer et des derniers logs de l'applicatif.

Si jamais ces informations ne suffisent pas, il ne faut pas oublier qu'il existe aussi CLI NSX, à exécuter depuis le NSX manager: Lancer une session SSH sur votre NSX manager et utiliser la commande:

1pktcap-uw

Une commande intéressante permettant de faire du debug:

1pktcap-uw --dvFilter dvfilter_name --capture PreDVFilter|PostDVFilter [filter_options] [--outfile pcap_file_path [--ng]] [--count number_of_packets]

Avec cette commande il est possible d'analyser les flux en entrée et à la sortie de votre distributed firewall et ainsi voir si c'est lui qui vous bloque ou non un flux particulier.

Rappel: pour ceux qui aiment aller voir les logs concernant NSX et les DLR ou DFW: Sans LogInsight, les logs seront éparpillés entre tous vos ESXi...