Tagged: VxRail

HCIBench

HCIBench «Hyper-converged Infrastructure Benchmark», vise à simplifier et à accélérer les tests de performance, dans le cadre des POC (Proof of concept) et démonstration de manière cohérente et contrôlée.

HCIBench est spécialement conçu pour exécuter des tests de performances sur des banques de données partagées ou locales dans vSphere.

Il disponible sous la forme d’une Appliance (OVA).

L’outil automatise entièrement le processus de bout en bout de :

  • Déploiement de machines virtuelles de test
  • Coordination des exécutions de charge de travail
  • Collecte des données
  • Agrégation des résultats de test
  • Analyse des performances

HCIBench n’est pas seulement un outil de référence conçu pour vSAN, mais peut également être utilisé pour évaluer les performances de tous les types de stockage d’infrastructure hyper-convergée dans un environnement vSphere.

Remarque : Il n’est pas recommandé d’exécuter les tests de performances dans un environnement de production car HCIBench exécute des tests de résistance (stress tests), ce qui aura un impact direct sur les autres machines virtuelles qui s’exécutent sur le même cluster.

HCIBench Architecture
Téléchargement

L’outil est disponible au téléchargement au niveau flings VMware : URL

Déploiement

Mode d’emploi (User guide) : URL

Tableau de bord

VxRail PTAgent – Appliance Missing

VxRail PTAgent Troubleshooting – Appliance Missing

Parfois, vous pouvez rencontrer une erreur où votre nœud VxRail entre dans l’état Appliance Missing dans le gestionnaire VxRail mais fonctionne normalement dans vCenter.

Appliance Missing

La cause est généralement le VxRail PTAgent.

Le PTAgent existe pour demander des informations matériel à propos d’un nœud avec une fréquance de quelques minutes en utilisant ipmi.

En supposant qu’il n’y a pas de bogue avec la version de PTAgent en cours d’exécution sur votre VxRail, ce qui suit est un bon point de départ pour le dépannage.

Etape 1

Vérifier la version de PTAgent dont vous disposez.

#esxcli software vib list | grep dellptagent

VxRail PTAgent 1
Etape 2

Vérifier l’état du service ISM.

#/etc/init.d/dcism-netmon-watchdog status
#/etc/init.d/dcism-netmon-watchdog stop
#/etc/init.d/dcism-netmon-watchdog start
#/etc/init.d/dcism-netmon-watchdog status

VxRail PTAgent 2
Etape 3

vérifier l’état du PTAgent

#/etc/init.d/DellPTAgent status
#/etc/init.d/DellPTAgent stop
#/etc/init.d/DellPTAgent start
#/etc/init.d/DellPTAgent status

VxRail PTAgent 3
Etape 4

Vérifiez si VxRail est sur l’état d’écoute (Listen)

#esxcli network ip connection list | grep LISTEN | grep Dell
–grab 4869528
#ps -s | grep 4869528

VxRail PTAgent 4
Etape 5

Si, après avoir effectué les étapes précédentes, le problème persiste.

Il faut mettre le nœud en mode maintenance et redémarrez-le, puis redémarrez la machine virtuelle VxRail Manager.

Par la suite, attendez 5 à 10 minutes et vérifiez l’état du nœud.

Etape 6

Si le problème persiste, veuillez contacter le support DellEMC.

vCenter Server 7.0 Configuration maximums

vCenter Server 7.0 Configuration maximums

  • vCenter Server (Standalone)
    • Hosts per vCenter Server : 2500
    • Powered-ON VMs : 30,000
  • Linked mode vCenter Servers :
    • 15 per SSO domain
    • 15,000 hosts
    • Powered-on VMs: 150,000
  • vCenter server Latency :
    • vCenter Server to vCenter server : 150 ms
    • vCenter Server to ESXi host : 150 ms
    • vSphere client to vCenter Server : 100 ms
vCenter Server 7.0 Configuration maximums
vCenter Server 7.0 Configuration maximums

Modèle de licence par CPU de VMWare

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:
Modèle de tarification par  CPU
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 Cloud Foundation
  • VMware Enterprise PKS
  • VMware EVO:RAIL General Purpose Suite
  • VMware HCI Kit
  • VMware HCX
  • VMware Integrated OpenStack
  • VMware NSX Data Center
  • VMware SDDC Manager
  • VMware Site Recovery Manager
  • VMware vCenter Site Recovery Manager
  • VMware vCloud Director
  • VMware vCloud NFV Bundle
  • VMware vCloud NFV OpenStack Bundle
  • VMware vCloud Suite
  • VMware vRealize Automation
  • VMware vRealize Code Stream
  • VMware vRealize Network Insight
  • VMware vRealize Suite
  • VMware vRealize Log Insight
  • VMware vSAN
  • VMware vSphere
  • VMware vRealize Operations Manager
  • vRealize Business
  • vRealize Hyperic

Nombre de licences -Licensing VMware

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.
Prérequis :
  • Connecter vous au vCenter Server:

Connect-VIServer -Server vCenter_Server

  • Import PowerCLI function: 

Import-Module .\vSphereCPUSocketToCoreUsage.psm1

  • 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.
Nombre de licences - Nouvelle politique de licensing VMware

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 Skyline

VMware Skyline est un service d’assistance proactif innovant de VMware.

VMware Skyline collecte, regroupe et analyse en toute sécurité et automatiquement les données de configuration, d’opérations et de performances.

Cela permet au support technique VMware d’améliorer les délais de résolution et résoudre de manière proactive les problèmes potentiels.

Aussi, améliorent la visibilité de votre infrastructure auprès du support VMware.

Grâce à ces capacités, les opérations de support abandonnent le mode réactif «Incident= Résolution » et passent à une expérience proactive, prédictive et prescriptive, rendant votre investissement dans le support VMware encore plus rentable.

Ce service est disponible pour tous les clients disposant d’un contrat de support valide (Production Support ou Premier Support).

VMware Skyline Advisor - Inventory View

VMware vSphere 6.7 U3b

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 :

  1. Le système d’exploitation Photon utilisé pour VMware vCenter Server Appliance.
  2. ESXI
  • VIB
  • Esx-base
  • Esx-update
  • Vsan
  • Vsanhealth
  • Résolution des probléme CBT

Platform Services Controller (PSC)

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.
vCenter Server & Platform Services Controller

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.

PSC : EMBEDDED MODE
  • 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.

PSC : EXTERNAL MODE

Contrôle d’admission vSphere HA

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 :

types de contrôle d'admission

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 :

  1. Calcule les besoins en ressources pour toutes les machines virtuelles sous tension dans le cluster.
  2. Calcule les ressources disponibles au niveau des hôtes pour les machines virtuelles.
  3. Calcule la Capacité CPU et Mémoire nécessaire au basculement du cluster.
  4. 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 %.
Pourcentage de ressources de cluster

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:

  1. Calculez la taille de l’emplacement. (Un emplacement est une représentation logique de la mémoire et CPU).
  2. Détermine le nombre d’emplacements pouvant être présents sur chaque hôte du cluster.
  3. Détermine la capacité de basculement actuelle du cluster.
  4. 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.
Stratégie d'emplacement

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.

VSANTOP Command-Line Tool

Avec la publication de vSphere 6.7 U3 et de vSAN 6.7 U3, VMware a ajouté un nouvel outil de ligne de commande VSANTOP.

L’outil s’exécute sur les hôtes ESXi pour afficher les mesures de performance vSAN en temps réel.

VSANTOP vous permet de surveiller et de dépanner les performances vSAN à un niveau très granulaire.

Ce nouvel outil pratique peut aider les administrateurs et le support VMware à résoudre les problèmes liés à l’environnement vSAN.

Lien de la documentation officielle

L’utilisation de l’outil est assez simple : démarrer une session SSH sur l’un des hôtes ESXi membre du cluster vSAN et taper : vsantop (en minuscule).

[root@esxi:~] vsantop

Pour afficher les différentes vues et mesures de performances dans vsantop, entrez les commandes suivantes :

VSANTOP commandes
Badr Eddine CHAFIQ