Nous sommes au STADE 3 de l’épidémie en France mais le COVID-19 n’aura pas eu raison de moi pour vous écrire un petit article,
VMware vient d’annoncer la nouvelle mise à jour majeure de vSphere –> vSphere 7 !  Nous sommes très fiers de faire évoluer le coeur de notre réacteur. Il est important de comprendre que nous continuons d’investir massivement sur notre hyperviseur, pour justement accueillir les futurs besoins pour les cinq prochaines années, une des plus grandes nouveautés de vSphere 7 et une ré-architecture complète pour intégrer Kubernetes au sein meme de l’hyperviseur.

Voici les 6 features majeures de vSphere 7

vSphere 7 s’améliore sur trois points importants : 

  • Cycle de vie
  • Sécurité Intrinsèque
  • Accélération du déploiement des applications ( surtout moderne)

GoodBye Flash, Windows et PSC Externe

A mon sens, l’abandon de l’interface flash est une bonne chose et ne manquera à personne, étant donné que même l’ensemble des navigateurs et Adobe annonce la fin de flash pour la fin 2020, ceci va donc dans le bon sens de l’histoire !

L’installation de vCenter 7 ne pourra plus se faire avec une PSC Externe ni même sur une machine virtuelle Windows. 

vCenter Server Profiles : 

Une fonctionnalité fait son apparition dans vSphere 7, à savoir la capacité à travers l’interface REST API de lister l’ensemble des configurations vCenter, de les valider, puis de les réimporter dans un autre vCenter. On pourrait tout à fait imaginer à travers un outil comme PUPPET de vérifier la déviance de configuration de vos différents vCenter et donc d’avoir une conformité homogène. L’export de configuration vCenter est limité à 100 vCenter maximum et sera au format JSON. 

Il est relativement facile de consulter l’API du vCenter à travers la section Developper Center :

Content Library 

Dans le client vSphere, vous pouvez désormais modifier les templates stockés dans la content library et ainsi  surveiller les modifications apportées par d’autres utilisateurs.
Vous pouvez effectuer l’opération « Check Out » pour mettre à jour une machine virtuelle à partir d’un template de VM.

Après avoir extrait une machine virtuelle d’un modèle et mis à jour la machine virtuelle, vous devez reconvertir la machine virtuelle dans le modèle VM. Lorsque vous effectuez un Check In de la VM dans un template, vous créez une nouvelle version du template VM (VMTX) contenant l’état mis à jour de la machine virtuelle. Si le dernier modèle de VM contient des modifications que vous ne souhaitez plus conserver ou si vous avez commis une erreur lors de votre dernier check-in, vous pouvez rétablir le modèle de VM dans la version précédente.

vCenter Multi-homing

vCenter Server 7 prend désormais en charge la configuration multi-nic.
Le premier adaptateur réseau (NIC 1) est reservé pour la configuration VCHA et il sera toujours la premiere interface (NIC1).
Le nombre maximum d’interface virtuelle est de 4 sur vCenter.
Il est possible d’ajouter d’autres adaptateurs à l’appliance, mais seul 4 interfaces seront pris en charge par le support GSS

vSphere LifeCycle Manager

vSphere LifeCycle Manager est une des annonces majeures de vSphere 7, cette fonctionnalité va permettre de créer une unique image intégrant la mise à jour ESXI, les drivers et firmwares de votre matériel (DELL et HPE uniquement pour le moment).  Précision importante, l’ensemble des hôtes d’un cluster doivent être de la même marque ainsi que du même modèle. L’utilisation du LifeCycle Manager facilitera la vérification et la mise à jour firmware et interagira avec les composants HP OneView et Dell OpenManage.

Cluster Image

DRS v2

DRS a été releasé en 2006 et le code a totalement été réecrit
DRS v1 se concentrait sur l’état du cluster, vérifiant s’il a besoin d’être rééquilibré car il pouvait arriver qu’un hôte ESXi soit sur-consommé alors qu’un autre hôte ESXi a moins de ressources consommées. Si la logique du DRS déterminait qu’il pouvait améliorer l’équilibre du cluster, il exécutait un vMotion en fonction des paramètres configurés.

La nouvelle logique DRS (DRS v2) adopte une approche très différente: 

DRS v2 calcule un score DRS VM sur l’ensemble des hôtes et déplace les VMs vers un hôte qui fournit le score DRS VM le plus élevé. La plus grande différence avec l’ancienne version DRS est qu’elle n’équilibre plus la charge de l’hôte. Cela signifie que le DRS se soucie moins de la base d’utilisation de l’hôte ESXi.
Désormais, nous améliorons l’équilibrage de la charge sur le cluster en nous concentrant sur la mesure qui nous importe le plus, l’état de la machine virtuelle.
Le DRS fonctionne désormais chaque minute et calcule l’équilibrage des workloads de manière encore plus granulaire qu’auparavant.

Enfin d’autres améliorations ont vu le jour comme le Assignable Hardware : 
Le new direct path I/O  est la nouvelle façon d’exposer du matériel PCIe directement à une machine virtuelle.  Par exemple si une VM dispose d’un vGPU dans sa configuration, le placement DRS est activé ou meme vSphere HA seront directement en capacité de trouver les hôtes ESXi qui ont le meme profil GPU  de la machine virtuelle en cas de défaillance d’un host par exemple.
Cette fonctionnalité nécessite la nouvelle version matérielle VM 17.

vMotion v2

Là encore le vmotion a été amélioré pour réduire l’impact lors du déplacement des machines virtuelles conséquentes, dont notamment les grandes bases de données ORACLE  ou du SAP HANA. 

Pour rappel voici les grandes étapes du vMotion : 

  1. Création de la VM qui doit être migrée en direct, sur l’hôte ESXi de destination.
  2. Début de la phase de pré-copie de la mémoire, en copiant toutes les pages de mémoire utilisées par la VM vers la destination
  3. La source VM est suspendue.
  4. Les derniers bits de mémoire et l’état du dispositif (c’est-à-dire les pages de mémoire utilisées par le VM) sont transférés vers la destination.
  5. La VM sur la destination est reprise, pointant sur les pages de mémoire que vMotion a copiées.
  6. La VM source est nettoyée, supprimée.

Le point essentiel à retenir est que nous devons maintenir le temps de commutation (ou temps d’arrêt) dans un délai inférieur 1 seconde.  VMotion était capable de gérer pour les machines dites normales mais l’augmentation des workloads a fait qu’il était plus difficile de gérer le vMotion de plusieurs grosses VMs (quelques TB de RAM par exemple) et donc de difficilement maintenir ce switch-over.

Je vous invite donc à regarder cette vidéo de Niels qui explique parfaitement comment nous avons pu améliorer VMotion (en insérant Page Tracer par vCPU), l’une de nos features phare de cette décennie.

Comparaison VMOTION 6.X VS

Sécurité 

Intel Software Guard Extensions (Intel SGX) est une extension de l’architecture x86/x64 conçue pour augmenter la sécurité du code et des données, introduite avec l’architecture Skylake. Intel SGX permet le chiffrement de la mémoire système pour isoler les données les plus critiques de l’application.

Pour rappel une faille a été découverte dans l’architecture SGX cet été :

https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00203.html

Les machines virtuelles disposants de SGX auront quelques restrictions importantes :  

  • Impossible de réaliser du VMOTION
  • Impossible d’appliquer du Fault Tolérance
  • Impossible de réaliser un snapshot
  • Impossible de suspendre la VM.
  • etc…

vSphere Trust Autority : 

Amélioration de la gestion des certificats. Dans vSphere 6.x, vous disposez d’un grand nombre de certificats. Dans vSphere 7, la gestion des certificats est beaucoup plus simple. Et vous pouvez gérer les certificats du serveur vCenter de manière programmatique en utilisant des API.

Identity Federation : 

Authentification de la fédération basée sur des normes avec un fournisseur d’entreprise (idPs) tel que ADFS. Cela réduit la portée de l’audit et la charge de travail de l’administrateur vSphere.

Je parlerai volontairement dans un article séparé de vSphere 7 with Kubernetes qui est disponible uniquement dans VMware Cloud Foundation. 

Allez un petit teasing…. 😉 

N’hésitez pas à commenter cet article dans un soucis d’amélioration continue.

See you and take care of you, respectez votre distance sociale et restez chez vous ! 

Mikael.

Mikael Lelouch

Rédigé par

Mikael Lelouch

Mikael Lelouch est Solution Engineer pour VMware et agit pour l'ensemble des entreprises françaises sur la région PACA et Grand Est. Par le passé, il a été consultant chez Axians Cloud Builder pendant 6 ans, et consultant indépendant. Ses interventions sont multiples auprés de grand comptes dans la région Sud Est. Spécialisé en réseaux et sécurité, il a décidé il y a quelques année d’attaquer le segment du Cloud Computing. Spécialisé dans les produits VMware mais surtout autours de NSX et de vRealize Suite.