La vérification de l’Etat VMware Tools est essentiel pour voir si la version à jour de VMware Tools est installée et s’il s’exécute sur vos machines virtuelles.
Cela vous permet de surveiller l’état de conformité et de remédier aux écarts.
Vous devez d’abord déterminer les machines virtuelles :
Sans VMware Tools.
Avec une version VMware Tools obsolète.
Le moyen le plus simple de vérifier si une machine virtuelle n’est pas conforme est de la visualiser via le client vSphere.
Cela vous montrera des détails tels que la version et la conformité.
Cas1 : VM sans VMware Tools (non installé)
Cas2 : VM avec VMware Tools non à jour/obsolète
Pour plus d’efficacité et moins de charge de travail, parlons automatisation.
Je vais vous montrer comment vérifier l’Etat VMware Tools de manière automatisée à l’échelle d’une plateforme VMware via deux commandes à l’aide de PowerCLI.
Liste des VMs avec VMware Tools obsolètes
Get-Datacenter -name « DC NAME » | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like « guestToolsNeedUpgrade »} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Sort-Object Name
Liste des VMs sans VMware Tools (non installé)
Get-Datacenter -name « DC NAME » | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like « guestToolsNotInstalled »} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Sort-Object Name
Jetons un coup d’œil aux nouvelles fonctionnalités et améliorations du VMware vSAN 7.0 U1
HCI Mesh
Avec VMware vSAN HCI Mesh, les clusters vSAN peuvent essentiellement être rassemblés pour fournir une approche désagrégée des ressources de calcul et de stockage qui permet à plusieurs clusters de participer à une architecture inter-cluster.
Pour un cluster vSAN local surutilisé, vous avez désormais la possibilité de monter un stockage supplémentaire à partir d’un cluster vSAN distant disposant de stockage libre
Cela signifie que toute capacité vSAN peut être partagée avec un autre cluster vSAN.
Actuellement, les clients peuvent monter une banque de données vSAN du cluster vSAN A vers le cluster vSAN B, et vice versa.
Compression-only
Il s’agit d’un changement de VMware concernant la déduplication et la compression vSAN.
Cette nouvelle fonctionnalité est cruciale pour de nombreux clients qui souhaitent utiliser uniquement la compression sur leur cluster vSAN.
Aujourd’hui, les administrateurs vSAN peuvent choisir d’utiliser la compression uniquement sans avoir à utiliser la dédiplication.
Au niveau du cluster, l’interface utilisateur de vCenter Server présente désormais trois options:
None
Compression only
Deduplication and compression.
vSAN “Shared” Witness Appliance
Pour chaque cluster à 2 nœuds, une appliance témoin est nécessaire , cela signifie que si un client possède plusieurs clusters à 2 nœuds, il en aura plusieurs.
Avec cette nouvelle fonctionnalité, vSAN a changé le fonctionnement de l’appliance Witness.
Aujourd’hui, avec cette nouvelle appliance Shared Witness, les clients peuvent avoir jusqu’à 64 clusters à 2 nœuds avec un seul dShare Witness Appliance.
Cela réduira considérablement la quantité de CPU et de mémoire nécessaires à l’appliance Witness.
Améliorations du service de fichiers vSAN
Dans vSAN 7.0, VMware a démarré les services de fichiers, le service de fichiers vSAN natif inclut la prise en charge de :
Partages de Fichiers SMB
Microsoft Active Directory
Authentification Kerberos
Il sera désormais possible de protéger tous vos dossiers partagés en fournissant des autorisations.
Augmentation de la capacité utile
Les optimisations éliminent le besoin pour vSAN d’avoir 25 à 30% d’espace libre disponible pour les opérations internes et les reconstructions après une panne d’hôte. La quantité d’espace requise est une valeur déterministe basée sur des variables de déploiement, comme la taille du cluster et la densité des périphériques de stockage.
Ces modifications fournissent une capacité plus utilisable pour les charges de travail.
Aperçu des nouvelles fonctionnalités de vSAN 7.0 U1
vSAN HCI Mesh (également appelé Maillage HCI) est l’une des nouvelles fonctionnalités introduites avec la version vSAN 7 Update 1.
Le Maillage HCI assure la désagrégation du calcul et du stockage en permettant aux clients vSAN de partager des banques de données vSAN entre deux ou plusieurs clusters.
Les administrateurs vSAN peuvent configurer une relation entre plusieurs clusters et autoriser ces clusters à partager la capacité de la banque de données vSAN.
En utilisant vSAN HCI Mesh, vous pouvez maintenant monter la banque de données distante et l’utiliser comme s’il s’agissait d’une banque de données locale.
Quelques exemples de cas d’utilisation (Use case) :
Vous avez un cluster hybride et un cluster 100% Flash et vous souhaitez provisionner une VM sur le cluster hybride, tout en profitant des avantages du stockage 100% Flash.
Vous avez deux clusters, le premier (Cluster X) n’a plus de stockage disponible et le second (Cluster Y) est plein côté calcul et vous devez déployer de toute urgence une VM pour répondre à un besoin métier, dans ce cas vous pouvez créer la VM sur le cluster X (utilisation de la capacité de calcul) en pointant vers la base de données du cluster Y (utilisation du stockage disponible).
Cette fonctionnalité utilise l’adaptateur vSAN VMKernel natif et le protocole RDT pour communiquer dans la topologie HCI maillée avec d’autres nœuds vSAN.
La grande différence entre une banque de données vSAN « locale » et un maillage HCI réside dans le fait que « DOM Client » et « DOM Owner » ont été séparés.
Donc au lieu d’avoir le « DOM Owner » localement, il est maintenant distant sur le cluster distant.
VMware vSAN HCI Mesh offre certainement la capacité nécessaire pour satisfaire de nombreux cas d’utilisation différents.
Les capacités de désagrégation apportées par vSAN HCI Mesh dans vSAN 7 Update 1 permettront aux clients d’utiliser plus efficacement le stockage dans les environnements vSAN.
Cela facilitera le regroupement des ressources disponibles, notamment le calcul et le stockage sur de nombreux clusters différents (Disaggregated cross cluster architecture).
VMware à annoncé une mise à jour importante du modèle de licence par CPU (per-CPU licensing model), afin de continuer à répondre aux besoins des clients dans un paysage industriel en évolution.
Nous aurons maintenant besoin d’une licence pour couvrir jusqu’à 32 cœurs physiques.
Si un CPU a plus de 32 cœurs, des licences supplémentaires seront nécessaires.
L’annonce du modèle de licence par CPU s’inscrit dans la continuité du parcours de VMware visant à aligner ces offres de produits sur les modèles de tarification standard du secteur.
Ce changement rapproche VMware du modèle de tarification standard basé sur le processeur adopté sur le marché.
Par conséquent, cette approche permettra aux clients de comparer plus facilement les licences et les prix entre VMware et les autres fournisseurs (en utilisant la tarification par cœur).
Cela aide VMware également à maintenir des tarifs simples et pertinents par rapport à l’évolution du marché du matériel.
Ce changement n’aura probablement aucun impact sur la grande majorité des clients actuels, car ils utilisent des serveurs Intel et AMD qui sont au niveau ou en dessous du seuil de 32 cœurs.
Tout client qui achète des licences logicielles VMware, pour un déploiement sur un serveur physique avec plus de 32 cœurs par CPU, avant le 30 avril 2020 sera éligible pour des licences supplémentaires gratuites par CPU pour couvrir les processeurs sur ce serveur.
Quelques exemples:
Produits concernés
La mise à jour des licences par CPU aura un impact sur toutes les offres VMware qui utilisent le processeur comme métrique de licence.
Voici une liste partielle des produits concernés par la nouvelle politique de licence:
VMware a créé un outil pour identifier le nombre de licences par processeur requis lors de la mise à niveau vers la nouvelle versions des licences VMware.
Cet outil sera utile pour les produits VMware achetés après les changements de modèle de licence annoncés le 3 février 2020 et en cas de renouvellement pour les anciennes plateformes.
Afin d’identifier le nombre de licences requises pour la mise à niveau vers une nouvelle version de vSphere et vSAN, il existe deux méthodes :
En ce qui concerne les petits déploiements et les hôtes ESXi non connectés à un vCenter Server:
Accéder à Host > Hardware > CPU et vérifiez la valeur des cœurs par socket pour déterminer si votre hôte a plus de 32 cœurs physiques par CPU.
Pour les déploiements d’infrastructures à grande échelle :
VMware a développé un outil PowerCLI qui collecte et consolide des informations sur la quantité de licences de processeur requises pour chaque hôte connecté à un vCenter Server.
Run Get-vSphereCPUSocketToCoreUsage function to retrieve results. By default, the script will iterate through all vSphere Clusters.
Exécuter la fonction Get-vSphereCPUSocketToCoreUsage pour récupérer les résultats.
Par défaut, le script parcourt tous les clusters vSphere.
CPU_LICENSE_COUNT: nombre de licence CPU de la méthode de licence actuelle LIMITED_CPU_CORE_LICENSE_COUNT: nombre de licence CPU sous le nouveau modèle de licence.
VMware a publié une nouvelle mise à jour vSphere 6.7 U3b.
Au niveau de cette version, il n’y a pas de nouvelles fonctionnalités. Toutefois, de nombreux correctifs et mises à jour de sécurité ont été implémentés.
Cette version contient nombreux correctifs de sécurité pour :
Le système d’exploitation Photon utilisé pour VMware vCenter Server Appliance.
Les candidatures pour le programme vExpert pour l’année 2020 sont maintenant ouvertes.
Les candidatures seront acceptées jusqu’au vendredi 10 janvier à minuit (Pacific Standard Time).
L’annonce des vExpert 2020 aura lieu entre fin février et début mars.
Le programme VMware vExpert est le programme mondial d’évangélisation et de sensibilisation de VMware, ce programme est conçu pour mettre les ressources marketing de VMware au service de vos efforts de plaidoyer. Promotion de vos articles, visibilité lors de nos événements mondiaux, publicité coopérative, analyse du trafic et accès rapide aux programmes bêta et à la feuille de route de VMware.
Les récompenses sont destinées aux individus et non aux entreprises et pour une durée d’un an.
Les employés des clients et des partenaires peuvent recevoir les récompenses.
Dans l’application, VMware prend en compte vos différentes activités communautaires de l’année précédente afin de déterminer qui recevra des récompenses.
Si vous souhaitez devenir vExpert, le critère est simple. VMware recherche des professionnels de l’informatique qui partagent leurs connaissances sur VMware et les transmettent à la communauté, donc ceux qui ont un impact positif sur la communauté VMware en ce qui concerne le partage de connaissances autour des produits VMware.
Il existe plusieurs façons de partager vos connaissances et de vous engager avec la communauté.
Certaines de ces activités sont les suivantes: blogging, création de livres, activités dans des groupes facebook, plates-formes de forum (VMTN et autres plateformes non VMware), prise de parole en public, direction de VMUG, vidéos, etc…
Tous les vExpert, VCDX ainsi que tous les nouveaux candidats doivent postuler au moins une fois par an.
Dans cet article, nous allons essayer de comprendre ce qu’est un Platform Services Controller.
À partir de vSphere 6.0, les composants vCenter sont regroupés en deux rôles séparés, comme suit :
VCenter Server : appelé nœud de gestion, utilisé pour fournir des services spécifiques liés à vCenter.
Platform Services Controller : appelé contrôleur d’infrastructure, utilisé pour fournir des services d’infrastructure communs à différents produits VMware.
PSC est un composant très
important dans une plateforme vSphere, car il centralise de nombreuses
fonctionnalités importantes.
Platform Services Controller appelé PSC, il simplifie et centralise les services tels que la gestion des licences, les tags, la gestion des identités avec les autorisations, les rôles, les domaines d’authentification unique (SSO) et les certificats.
Le PSC est un composant nécessaire pour pouvoir déployer le vCenter, sans PSC, il est impossible d’installer un vCenter.
Le déploiement est possible selon
deux types d’installations :
EMBEDDED MODE
Le mode intégré permet une installation de vCenter Server et PSC dans une même Appliance (une seule machine virtuelle), il s’agit du mode idéal pour les petits environnements.
EXTERNAL MODE
Le mode externe permet de déployer une Appliance PSC en premier (une seule VM) et par la suite permet l’installation du vCenter (Une deuxième VM) en indiquant l’adresse du premier PSC Appliance.
Ce type de déploiement (External PSC) nous permet une grande flexibilité, tel que la possibilité de connecter plusieurs vCenter au même PSC et de mettre en place des mécanismes de haute disponibilité et d’équilibrage de charge entre plusieurs instances PSC synchronisées.
vSphere HA utilise le contrôle d’admission pour
s’assurer que des ressources suffisantes sont disponible dans un cluster VMware
pour assurer la disponibilité des machine virtuelles en cas de basculement à
cause d’une de défaillance d’un hôte.
La base du contrôle d’admission vSphere HA est le
nombre de défaillances d’hôte que le cluster est autorisé à tolérer (FTT :
Number of Failures to Tolerate).
Trois types de contrôle d’admission sont disponibles :
Pourcentage de ressources de cluster
Avec ce type de contrôle d’admission, vSphere HA vérifie qu’un pourcentage spécifié de ressources CPU et Mémoire est réservé pour le basculement.
Lorsque l’option de pourcentage de ressources de
cluster est configurée, vSphere HA implémente le contrôle d’admission comme
suite :
Calcule les besoins en ressources pour toutes les machines virtuelles sous tension dans le cluster.
Calcule les ressources disponibles au niveau des hôtes pour les machines virtuelles.
Calcule la Capacité CPU et Mémoire nécessaire au basculement du cluster.
Détermine si la Capacité CPU et Mémoire requis pour le basculement sont inférieures ou non à la Capacité de basculement configurée correspondante (spécifiée par l’utilisateur).
Prenons l’exemple suivantes pour un cluster VMware
:
Un cluster de trois
hôtes ESXI, ayant la configuration mémoires et CPU :
Hôtes ESXI
CPU (Ghz)
Mémoire (Go) disponible
H1
9
9
H2
9
6
H3
6
6
Il y a cinq machines
virtuelles sous tension dans le cluster avec des besoins en CPU et en mémoire
différents :
Machine Virtuelle
CPU (Ghz)
Mémoire (Go)
VM 1
2
1
VM 2
2
1
VM 3
1
2
VM 4
1
1
VM 5
1
1
La capacité de basculement configurée pour le processeur et la mémoire est de 25 %.
Les ressources totales requises pour les machines
virtuelles sous tension sont de 7 Ghz et 6 Go.
Le total des ressources hôte disponibles pour les
machines virtuelles est de 24 Ghz et 21 Go. À partir de là, la capacité de
processeur actuelle pour le basculement est de 70% ((24 Ghz – 7 Ghz)/24 Ghz).
De même, la capacité de mémoire de basculement actuelle est de 71% (21 Go – 6
Go) / 21 Go).
Étant donné que la capacité de basculement configurée pour le cluster est de 25%, 45% des ressources CPU et 46% des ressources de mémoire sont toujours disponibles.
Stratégie d’emplacement
vSphere HA garantit que même si un nombre spécifié d’hôtes est défaillant, il reste suffisamment de ressources sur le cluster pour permettre le basculement de toutes les machines virtuelles à partir de ces hôtes. .
Donc, vSphere HA effectue le contrôle d’admission comme suit:
Calculez la taille de l’emplacement. (Un emplacement est une représentation logique de la mémoire et CPU).
Détermine le nombre d’emplacements pouvant être présents sur chaque hôte du cluster.
Détermine la capacité de basculement actuelle du cluster.
Détermine si la capacité de basculement actuelle est inférieure à la capacité de basculement configurée (spécifiée par l’utilisateur).
Nous allons illustrer par un exemple la méthode de calcul de la taille d’emplacement et son utilisation avec cette stratégie de contrôle d’admission, Considérez les hypothèses suivantes :
Le cluster est composé de trois hôtes, chacun avec différentes quantités de CPU et de mémoire disponibles. Le premier hôte (H1) à 9 Ghz de ressources processeur et 9 Go de mémoire disponible. Le second (H2) à 9 Ghz de CPU et 6 Go de mémoire disponible et le troisième (H3) à 6 Ghz de CPU et 6 Go de mémoire disponible.
Cinq machines virtuelles actives du cluster ont des exigences différentes en matière de processeur et de mémoire. VM1 nécessite 2 Ghz de ressources de processeur et 1 Go de mémoire, alors que VM2 nécessite 2 Ghz et 1 Go, VM3 nécessite 1 Ghz et 2 Go, VM4 nécessite 1 Ghz et 1 Go, VM5 nécessite 1 Ghz et 1 Go.
Le nombre de défaillance d’hôte tolérées par le cluster sont définies sur la valeur 1.
1– La taille d’emplacement est calculée en comparant à la fois les exigences de CPU et de mémoire des machines virtuelles et en sélectionnant la plus élevée.
Le besoin en CPU le plus élevé (partagé par VM1 et VM2) est de 2 GHz, tandis que le besoin en mémoire le plus élevé (VM3) est de 2 Go. Partant de là, la taille d’emplacement se compose d’un CPU de 2 GHz et d’une mémoire de 2 Go.
2– Le nombre maximum d’emplacements pouvant être pris en charge par chaque hôte est déterminé.
H1 peut prendre en charge quatre emplacements. H2 peut prendre en charge trois emplacements (le plus bas de 9 GHz/2 GHz et 6 Go/2 Go) et H3 peut aussi en prendre en charge trois.
3- La Capacité de basculement actuelle est calculée.
Le plus gros hôte est H1 et s’il est défectueux, le cluster contient toujours six slots, ce qui est suffisant pour les cinq machines virtuelles sous tension. Si H1 et H2 sont défectueux, il ne reste que trois emplacements, ce qui est insuffisant. Par conséquent, la Capacité de basculement actuelle est de 1.
Le cluster a un slot disponible (les six slots de H2 et H3 moins les cinq slots utilisés).
Hôtes de basculement dédiés
vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés, en cas de défaillance de l’hôte, vSphere HA tente de redémarrer ses machines virtuelles sur les hôtes de basculement prédéfinis. vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés,
Si cela n’est pas possible parce que les hôtes de basculement sont en panne ou que leurs ressources sont insuffisantes, vSphere HA tente de redémarrer ces VMs sur d’autres hôtes du cluster.
Pour que les fonctionnalités restent disponibles sur un hôte de basculement, vous ne pouvez pas mettre les machines virtuelles sous tension ni utiliser vMotion pour migrer des machines virtuelles vers un hôte de basculement.
De plus, DRS n’utilise pas d’hôte de basculement pour l’équilibrage de la charge.
Badr Eddine CHAFIQ
En tant qu'Architecte et Expert Systèmes et Virtualisation, ce blog fait partie d'une approche de partage de connaissances «giving back» autour des technologies de virtualisation "en particulier VMware", Cloud et Hyper-convergence.Le but principal de ce blog est de partager les nouveautés, Tutoriels , conseils et apporter des solutions techniques.
