INTRODUCTION

Dans cet article, nous allons voir ensemble comment utiliser le Raspberry Pi 4 en tant que witness pour notre cluster vSAN 7. À noter que le Witness n’est pas compatible ESXi 8.

Vous devez aussi utiliser des ESXi 7 avec la même version de build que le Witness.

Pour voir les étapes d’installation de l’ESXi sur le Raspberry 4, vous pouvez consulter cet article.

Configuration du Witness

Pour commencer, vous devez activer le service vSAN sur l’adaptateur VMkernel de votre ESXi ARM. Pour cela, allez dans la configuration des adaptateurs VMkernel.

Cocher la case vSAN.

Vous devez vous connecter en SSH sur l’ESXi ARM et exécuter les commandes ci-dessous :

/etc/init.d/usbarbitrator stop 
esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

Tapez la commande vdq -q pour afficher les informations sur nos clés USB. On remarque que nous avons 2 clés USB éligibles pour vSAN.

Pour que nos clés puissent être utilisées par vSAN, nous devons les taguer en tant que SSD et en tant que disque de capacité :

esxcli storage nmp satp rule add -s VMN_SAT_LOCAL --device=mpx.vmhba39:CO:TO:L0 --option-enable_ssd  
esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=mpx.vmhba38:CO:TO:LO --option=enable_ssd 
esxcli storage core claiming unclaim --type device --device=mpx.vmhba39:CO:TO:LO 
esxcli storage core claiming unclaim --type device --device=mpx.vmhba38:CO:TO:LO 
esxcli storage core claimrule load 
esxcli storage core claimrule run
esxcli vsan storage tag add -d mpx.vmhba39:CO:TO:LO -t capacityFlashesxcli vsan storage tag add -d mpx.vmhba39:CO:TO:LO -t capacityFlash

Si on refait la commande vdq -q on remarque que nos disques sont maintenant bien tagués.

Vous pouvez maintenant utiliser le witness dans la configuration de votre vSAN 7.

Nos clés USB sont bien utilisables.

En cas d’erreur, veuillez à bien vérifier que vous avez la même version de build que l’ESXi installé sur le raspberry. Dans certains cas, un Raspberry Pi 4 avec 4Gb de ram peut ne pas être suffisant.

L’article ESXionARM : Utiliser le Raspberry en tant que Witness vSAN est apparu en premier sur MCHELGHAM.

INTRODUCTION

Dans la suite de cet article, nous vous guiderons à travers les étapes de déploiement et de configuration de VMware vCenter 8 ainsi que la mise en place de vSAN 8 ESA.

Que vous soyez un administrateur système chevronné ou que vous débutiez dans le domaine de la virtualisation, ce guide vous aidera à maîtriser ces outils et à tirer le meilleur parti de votre infrastructure informatique. Restez avec nous pour les étapes détaillées à suivre.

Installer vCenter 8 / vSAN 8 ESA

Dans un premier temps, vous devez télécharger l’iSO d’installation de vCenter 8.

Une fois que l’ISO est téléchargé, montez-le dans votre explorateur de fichier. Cliquer sur Installer pour lancer l’assistant d’installation. Le chemin du fichier Installer est différent suivant le système d’exploitation utilisé.

Une fois l’assistant ouvert, cliquez sur Install.

Cliquez sur NEXT.

Acceptez les conditions d’utilisation.

Ici vous devez renseigner l’ESXi sur lequel vous voulez installer le vCenter 8 ainsi que le déploiement de vSAN 8. Dans notre cas on prend esxi01.

Renseignez ici le futur nom de votre VM vCenter qui sera déployée sur votre ESXi.

Passer la taille du déploiement en Tiny pour éviter que le vCenter utilise beaucoup de ressource. Dans le cadre de notre LAB/POC cette modification est importante.

À cette étape, nous allons demander au vCenter de créer un nouveau Datacenter ainsi qu’un nouveau cluster et d’activer vSAN 8 ESA dessus.

Sélectionner tous les disques SSD que vous avez sur votre esxi01.

Configurez le vCenter avec les réglages réseau qu’il doit avoir. À savoir l’IP, le fqdn, le DNS, etc.

Cliquez sur Finish pour lancer l’installation du vCenter.

Patientez pendant le déploiement.

Une fois que la première phase de déploiement est terminée. Cliquez sur CONTINUE.

Cliquez sur NEXT.

La modification des réglages de ces étapes est optionnelle.

Renseignez ici le nom du domaine SSO de votre vCenter ainsi que le mot de passe pour le compte administrator.

Acceptez le CEIP si nécessaire.

Cliquez sur Finish pour lancer la configuration.

Cliquez sur OK pour confirmer.

Patientez pendant la configuration.

La configuration est terminée. Vous pouvez maintenant cliquer sur l’URL de votre vCenter pour l’ouvrir dans un navigateur. Et cliquez ensuite sur CLOSE pour fermer l’assistant qui n’est plus nécessaire.

Renseignez les informations d’authentification.

Votre vCenter est maintenant fonctionnel, de plus notre cluster et notre premier ESXi sont déjà intégrés dans l’inventaire.

Suite de la configuration vSAN 8 ESA

Il est maintenant nécessaire de finaliser la configuration de notre cluster vSAN 8 ESA.

Pour cela, ajouter l’ESXi manquant à notre cluster CL01.

Renseignez les informations de l’esxi02.

Cliquez sur SUIVANT ensuite sur TERMINER.

L’esxi02 est maintenant intégré à notre cluster CL01.

Configuration du Distributed Switch

Il est maintenant nécessaire de configurer le réseau de nos ESXi. Pour cela, allez dans l’onglet réseau ensuite sur notre DC.

Cliquez sur « Nouveau Distributed Switch ».

Donnez un nom au nouveau Distributed Switch.

Laissez la dernière version.

Passez le nombre de Uplink à 2 et décochez la case de création d’un port groupe.

Cliquez sur TERMINER.

Configuration des Distributed Port Groups

Il est nécessaire de créer nos différents ports groupes qui vont gérer notre trafic réseau.

Pour cela, créer un nouveau port groupe distribué.

Dans notre cas on lui donne le nom DPG-vMotion.

Renseignez le vlan ID pour le trafic vMotion. Dans mon cas 201. En cas de doute, n’oubliez pas de revenir à notre premier article de ce guide.

Faire la même chose pour le trafic vSAN. Dans mon cas le nom est DPG-vSAN et vlan ID 202.

Maintenant que nos ports groupes sont créés, il est nécessaire de rattacher notre DVS à nos ESXi. Pour cela, allez dans Ajoutez et gérez des hôtes.

Sélectionnez « Ajouter des hôtes ».

Sélectionnez nos deux ESXi.

Affectez nos deux cartes réseau qui sont en rattachées directement entre nos deux ESXi aux Uplink. Dans mon cas c’est vmnic4 Uplink 1 et vmnic5 Uplink 2.

Ne rien modifier à cette étape.

Ne rien modifier à cette étape.

Cliquez sur TERMINER.

Nous devons avant de continuer modifier notre MTU à 9000 au niveau de notre DVS. Pour cela, allez dans l’onglet configuration du DVS ensuite dans propriétés ensuite MODIFIER.

Dans l’onglet Avancé, modifier le MTU à 9000.

Configuration des VMKernel vMotion et vSAN

Avant de continuer, nous devons affecter des adresses IP pour chaque trafic (vMotion et vSAN) au niveau de nos ESXi pour qu’ils puissent communiquer entre eux.

Pour cela, nous commençons avec le vMotion. Allez dans Ajouter des adaptateurs VMkernel.

Sélectionnez nos deux ESXi.

Cochez le service vMotion.

Utilisez des paramètres réseau statiques, ensuite renseignez les différents paramètres IP pour nos ESXi.

Cliquez sur TERMINER.

Faire la même chose pour le service vSAN.

Cochez le service vSAN.

Renseignez les paramètres.

Cliquez sur TERMINER.

Configuration du Witness Separation trafic

Par défaut, le trafic witness vSAN doit transiter sur un réseau vSAN dédié. Dans notre cas, cela n’est pas possible, car nos deux ESXi sont directement connectés entre eux. Nous allons modifier cela pour le faire transiter par le réseau de Management de nos ESXI pour qu’ils puissent atteindre sans problème le witness.

Repérez le nom de l’interface vmkernel qui correspond au réseau de management de vos ESXi. Dans notre cas vmk0.

Allez en SSH et renseignez la commande :

esxcli vsan network ip add -I vmk0 -T witness

Faire la même chose sur l’autre ESXi.

Vous pouvez vérifier la bonne prise en compte en allant dans services activés de l’interface vmk0.

Finalisation de la configuration de vSAN

Avant de continuer, vous devez dans un premier temps suivre l’article qui vous explique comment déployer le witness. Ensuite ll nous restera plus qu’à lier notre Witness à notre cluster vSAN.

Pour cela, au niveau de notre cluster CL01 allez dans configurer ensuite dans vSAN et cliquez sur « Configurer le cluster étendu ».

Déplacez l’esxi02 en domaine secondaire.

Sélectionnez le witness dans l’inventaire.

Cliquez sur TERMINER.

Maintenant la configuration du witness est terminée.

Il nous reste plus qu’à réclamer les disques de notre esxi02 et les intégrer au cluster. Cliquez sur « Réclamer des disques inutilisés ».

Sélectionnez tous les disques.

Patientez le temps que le cluster se reconfigure. Pour suivre l’évolution, allez surveiller > Skyline Health. Les alertes en orange concernent les différents contrôleurs et disques NVME qui ne sont pas certifiés par VMware. Dans notre cas, cela n’est pas important, car nous sommes en LAB/POC.

Activer DRS / HA

Maintenant que notre vSAN est fonctionnel, nous devons activer le DRS pour une meilleure répartition et équilibrage automatisé de nos machines virtuelles sur nos ESXi.

Pour cela, allez dans vSphere DRS > Modifier.

Activez le DRS.

Maintenant, nous devons activer vSphere HA pour un redémarrage automatique de nos machines virtuelles en cas de panne de l’esxi qui les héberges. Dans Disponibilité vSphere > vSphere HA > Modifier.

Activez vSphere HA.

Votre cluster vSAN 8 ESA est maintenant prêt !

L’article Guide complet : Mise en place d’une architecture VMware vSAN 2 nodes (Homelab, Demo, POCs) – Installer / Configurer vCenter 8 et vSAN 8 ESA est apparu en premier sur MCHELGHAM.

Introduction

Dans cet article, nous allons explorer en détail les étapes de déploiement du vSAN 8 ESA Witness, qui est un élément essentiel de notre architecture vSAN 8 ESA à deux nœuds.

Le vSAN 8 ESA Witness est un composant important qui assure la disponibilité et la fiabilité du stockage pour notre environnement virtualisé. Il est conçu pour fournir une solution de stockage haute disponibilité pour les petites infrastructures vSAN qui n’ont pas besoin d’un troisième nœud physique.

Déploiement du vSAN 8 ESA Witness

Dans un premier temps, vous devez télécharger le witness sur le site de VMware. Prenez la version ESA et non pas la version OSA.

Une fois que le fichier est téléchargé, allez sur le datacenter ou le cluster sur lequel vous voulez placer votre witness. Ensuite, cliquez sur Déployer un modèle OVF.

Sélectionnez le fichier téléchargé.

Donnez un nom au witness, ensuite sélectionnez son emplacement dans votre inventaire vCenter.

Cliquez sur Suivant.

Sélectionnez le déploiement large qui est suffisant.

Sélectionner le réseau de management sur lequel votre witness communiquera. Dans notre cas c’est le même réseau que les ESXi. Le choix du réseau secondaire n’est pas nécessaire.

Renseignez la configuration réseau de votre witness.

Cliquez sur TERMINER pour lancer le déploiement.

Démarrez le witness.

Une fois que le witness est lancé, vous devez le rajouter à l’inventaire de votre vCenter en tant qu’hôte. Pour cela, cliquez sur Ajouter un hôte.

Renseignez le fqdn de votre witness.

Renseignez le compte root.

Confirmez le résumé de l’hôte.

Laissez la configuration par défaut.

Cliquez sur TERMINER pour finaliser.

Le witness est maintenant déployé et prêt à être rattaché à un cluster vSAN 8 ESA.

L’article Guide complet : Mise en place d’une architecture VMware vSAN 2 nodes (Homelab, Demo, POCs) – Déployer le vSAN 8 ESA Witness est apparu en premier sur MCHELGHAM.

Introduction

Nous détaillerons dans cette partie les étapes à suivre pour installer l’ESXi sur nos serveurs, en veillant à bien configurer les paramètres réseau et à sécuriser l’accès à l’hyperviseur.

Une fois l’ESXi installé, nous pourrons passer à la configuration de vSAN et au déploiement des machines virtuelles. Nous aborderons ces sujets dans les parties suivantes de notre guide complet de mise en place d’une architecture VMware vSAN 2 nodes.

Installation ESXi

Dans un premier temps, connectez-vous sur l’interface IPMI de votre serveur. Vous devez au préalable avoir configuré l’adresse IP au niveau du BIOS.

Pour vous connecter à la console, allez dans Virtual Media, Remote Console ensuite cliquer sur Launch Console.

Avant d’aller plus loin, allez dans préférences.

Allez ensuite dans Input pour régler le clavier et le passer en français.

Allez dans Virtual Media > Virtual Storage.

Sélectionnez ISO File > Open Image allez ensuite chercher l’ISO de l’ESXi > cliquez sur Plug In ensuite sur OK.

Allez dans Power Control > Set Power On pour allumer le serveur.

Au boot du serveur, appuyez rapidement sur la touche de sélection du média de démarrage. F11 pour supermicro. Sélectionnez ATEN Virtual CDROM pour booter sur l’ISO monté préalablement.

Patientez le temps du chargement de l’installateur.

Appuyez sur la touche entrée de votre clavier

Appuyez sur la touche F11 de votre clavier.

Sélectionnez le disque sur lequel l’ESXi sera installé. Dans mon cas, je sélectionne mon module SATADOM.

Choisissez la bonne disposition du clavier. Dans mon cas French.

Renseignez un mot de passe pour le compte ROOT.

Appuyez sur la touche F11 pour lancer l’installation.

Patientez pendant l’installation.

Une fois l’installation terminée, appuyez sur la touche ENTRÉE pour redémarrer le serveur.

Au démarrage du serveur, appuyez sur la touche de sélection du média de boot. Allez dans Enter Setup pour configurer le BIOS.

Dans l’onglet Boot, allez dans Boot Option #1.

Sélectionnez le disque dans lequel vous avez installé l’ESXi. Une fois terminé sortez sur BIOS en sauvegardant les paramètres.

Patientez pendant le boot du serveur.

Configuration ESXi

Une fois que le serveur a booté appuyez sur la touche F2.

Connectez-vous avec le mot de passe du compte root renseigné pendant l’installation.

Allez dans Configure Management Network.

Ensuite dans Network Adapters.

Si ce n’est pas déjà fait. Sélectionnez l’adaptateur réseau sur lequel vous avez connecté votre câble de management ESXi.

Dans IPv4 Configuration.

Configurez l’adresse IP de L’ESXi en static, ensuite renseignez les paramètres IPs.

Dans IPv6 Configuration.

Désactivez l’IPv6 si vous n’en avez pas besoin.

Dans DNS Configuration.

Renseignez votre / vos serveurs DNS ainsi que le nom d’hôte de l’ESXi.

Dans Custom DNS Suffixes.

Renseignez votre domaine.

Appuyez sur la touche ECHAP de votre clavier, la console vous proposera d’appliquer les réglages et de redémarrer si besoin.

Après le reboot votre ESXi est maintenant configuré et prêt à l’emploi.

Maintenant, il nous est possible de nous connecter sur l’interface WEB de management. En allant dans un navigateur et en renseignant l’adresse IP de notre ESXi. Une fois sur l’interface, renseignez le compte ROOT ainsi que le mot de passe.

Vous êtes maintenant connecté sur votre ESXi.

Avant d’aller plus loin, vous devez configurer le NTP. En allant dans Gérer > Système > Date et heure > Modifier les paramètres NTP

Sélectionnez Utiliser le NTP > Lancement avec le démarrage et l’arrêt de l’ESXi > renseigner un serveur NTP dans mon cas l’ESXi a accès à internet je mets time.google.com.

Allez dans Services > sur le service ntpd cliquez sur Démarrer.

Votre ESXi est maintenant à l’heure !

>>> Procédez de la même façon pour le deuxième ESXi (esxi02).

L’article Guide complet : Mise en place d’une architecture VMware vSAN 2 nodes (Homelab, Demo, POCs) – Installer / Configurer ESXi 8 est apparu en premier sur MCHELGHAM.

Introduction

Dans les articles à venir, nous allons mettre en place une architecture complète basée sur les solutions VMware qui pourra être utilisée pour des LABs, des démonstrations, des environnements de test ou des POCs. Nous utiliserons du matériel spécifiquement dédié au développement et aux tests. Cette architecture est facilement adaptable pour des environnements de production moyennant quelques modifications apportées à certains éléments.

Pour commencer, nous allons concevoir notre future architecture. Le schéma est important car il nous permet d’anticiper d’éventuelles erreurs de câblage, de dimensionnement réseau, de redondance ou autres…

Architecture

Nous allons décrire élément par élément leur rôle dans notre architecture ainsi que le choix du matériel physique.

Les serveurs ESXi

Pour ce nouveau LAB, le choix s’est orienté vers des serveurs de la marque SUPERMICRO, car mon ancien LAB tournait avec des cartes mère de cette marque et je n’ai eu aucun souci pendant 5 ans en tournant 7j/7 et 24h/24.

Le model choisi est le A+ Server E301

Il permet d’avoir des performances exceptionnelles avec son CPU AMD EPYC ainsi que la possibilité de supporter jusqu’à 4 SSD/HDD SATA en 2.5 pouces et 512GB de RAM !

Une carte PCI Ethernet DUAL 10G SFP a été rejoutée pour nous permettre de faire du direct connect entre nos ESXi et ainsi avoir une bande passante importante pour notre trafic vMotion, vSAN, Fault tolérance et VTEP pour nos futurs segments NSX.

La connexion directe de nos ESXi nous permet de nous passer de l’achat d’un switch 10Gb, ce qui peut faire grimper la facture de notre environnement. De plus, cette architecture est prise en charge pour les installations de vSAN en deux nœuds, il est donc judicieux d’en profiter.

L’installation de l’ESXi se fera quant à elle directement sur nos modules SATADOM de 64Gb et non plus sur une clé USB, car depuis les dernières versions de VMware, l’utilisation de clé USB ou de carte SD n’est plus supportée.

L’avantage des cartes mère SUPERMICRO est la possibilité de brancher les modules de stockage SATADOM directement sur un port SATA auto alimenté (couleur orange).

Raspberry PI

Le Raspberry PI 3 nous permettra d’installer la version ARM de l’ESXi et ainsi pouvoir l’utiliser en tant que Witness pour notre cluster vSAN. Il est nécessaire de l’accompagner avec au moins 2 clés USB ou de deux disques SATA branchés en USB.

Switch réseau 1G

Un switch réseau est indispensable pour connecter nos ESXi et garantir une communication fluide entre eux. Il nous permettra également de nous connecter à nos équipements depuis notre réseau domestique ou professionnel. Dans mon cas, j’ai utilisé un ancien switch TP-Link TL-SG108E que j’avais à disposition. Les points forts de ce switch sont la possibilité de l’administrer via une interface web, la gestion des VLANs et la prise en charge de l’agrégation de ports pour maximiser la bande passante.

Stockage

Il est crucial de dimensionner correctement notre vSAN. Dans notre cas, avec une architecture en deux nœuds, nous devrons utiliser un RAID 1 pour nos ESXi. Cela signifie que notre ESXi01 sera un miroir de notre ESXi02. Aucun RAID matériel n’est requis dans chacun de nos ESXi. Nos disques seront présentés directement à notre ESXi qui se chargera de protéger nos données vers l’autre ESXi. J’ai opté pour un disque NVME de 480 Go pour le disque de cache.

J’ai fait le choix d’utiliser un disque de 2Tb SSD ainsi qu’un disque de 480Gb SSD en SATA pour les disques de capacités. L’avantage de vSAN est la scalabilité, ce qui veut dire qu’on pourra facilement augmenter la taille de notre datastore vSAN simplement en rajoutant de nouveaux disques dans nos ESXi.

Récapitulatif

Configuration réseau

Configuration des liaisons

Configuration des IPs

DNS1 : 192.168.0.1

Conclusion

Dans les prochains articles, nous verrons techniquement comment mettre en place cette nouvelle architecture.

L’article Guide complet : Mise en place d’une architecture VMware vSAN 2 nodes (Homelab, Demo, POCs) – Architecture est apparu en premier sur MCHELGHAM.

Dans cet article nous allons voir ensemble toutes les nouveautés de VMware vSAN 7 !

Depuis ces dernières années, vSAN ne cesse d’être amélioré pour être toujours plus performant et robuste pour se positionner en tant plateforme HCI par excellence ! Avec vSAN 7, VMware continue ces efforts en apportant toujours plus de fonctionnalités nouvelles pour moderniser les produits et surtout améliorer les techniques déjà en place dans les versions précédentes, pour toujours s’adapter à la demande croissante en performance des différentes charges de travail. Aujourd’hui, dans un monde très concurrentiel, les performances des charges de travail ont un impact sur la productivité des entreprises.

Pour réussir cette modernisation, vSAN 7 enrichie de nouveaux principes moteurs à la réussite du produit.

Gestion du Cycle de vie avec vSphere Lifecyle Manager (vLCM)

Comme vu brièvement dans mon article sur les nouveautés de vSphere 7 (vSphere 7 : Toutes les nouveautés!), la gestion du cycle de vie des produits VMware est aujourd’hui perfectionnée pour toujours apporter de la simplicité aux entreprises. vSphere Lifecyle Manager (vLCM) permet aujourd’hui de non seulement mettre à jour vSphere, mais permet aussi de mettre à jour les différents pilotes et firmware de vos serveurs HPE/DELL !  Ce qui permet aux entreprises de toujours avoir une plateforme à jour qui profite des dernières améliorations techniques et corrections de bug. Tout cela avec un effort très simplifié et automatisé !  (terminées les prises de tête dans la compatibility list).

Service de partage de fichiers intégré

Une des fonctionnalités qui était la plus attendue est le service de partage de fichiers qui fait son apparition dans vSAN 7 ! Vous avez maintenant la possibilité d’avoir un cluster vSAN qui en plus d’offrir un stockage type bloc pour vos machines virtuelles, vous avez maintenant le support du stockage type fichier à travers le protocole NFS v4.1 et v3. Cette fonctionnalité facilitera aux entreprises la mise en place de certaines de leurs applications. De plus, le service de partage de fichier vSAN supporte la mise en place des quotas pour chaque partage configuré.

Stockage compatible Kubernetes et plus…

La version vSAN 7 est aujourd’hui dotée de fonctionnalités supplémentaires pour offrir aux différents containers type K8S une compatibilité native qui profite pleinement des fonctionnalités vSAN. Comme la compatibilité avec les “Storage Class” au travers du CNS Control Plane qui assure la création du volume et l’application de la bonne stratégie de stockage. De plus, VMware vSAN 7 offre aujourd’hui la persistance des volumes, le support de vVols, l’encryption et les snapshots, le support du redimensionnement des volumes et la compatibilité avec les systèmes de monitoring type Wavefront, Prometheus et vRealize Opérations Suites.

Stretched Cluster et architecture 2 Nodes

Avoir de très bonnes performances est primordial pour une solution HCI étendue, car les performances peuvent être impactées lorsqu’une mauvaise gestion des flux est rencontrée. C’est pour cette raison qu’aujourd’hui la nouvelle version de vSAN apporte de très grandes améliorations dans la gestion des I/O qu’ils soient en local ou en Inter-Site. vSAN 7 apporte la priorisation des lectures locales pour réduire l’utilisation du lien Inter-Site, l’intégration avec DRS pour empêcher la migration d’une machine virtuelle qui n’est pas synchronisée avec le site disant, amélioration de la gestion des conditions de récupération après sinistre pour prioriser les I/O de lecture des machines virtuelles.

Avec la nouvelle version, lors d’un changement du Witness une remédiation des objets est lancée immédiatement pour réduire la non-conformité des objets.

Avec la nouvelle version, vSAN est plus intelligent pour prendre des décisions lors d’un scénario ou la capacité du vSAN est saturé ou mal équilibré. Dans les versions précédentes par exemple, les machines virtuelles subissaient des ralentissements voir un arrêt complet en cas de problème de capacité. Dans la nouvelle version, vSAN 7 se charge de changer la conformité de la machine virtuelle pour qu’elle soit toujours accessible, mais avec moins de protection le temps que les équipes informatiques réalisent un scale in / scale out de l’infrastructure vSphere / vSAN pour augmenter la capacité.

Pour les configurations étendues, plus besoin de rajouter des routes statiques pour le trafic vSAN. L’option “Override default gateway” est maintenant supportée !

Gestion de la capacité améliorée

La nouvelle version apporte des améliorations dans l’affichage de la taille réellement occupé par une machine virtuelle pour réduire les confusions.

VMware vSAN 7 apporte aussi une meilleure visibilité de la consommation mémoire engendrée par sa configuration.

Meilleure résilience

vSAN 7 supporte des disques de plus grande capacité pour offrir des possibilités d’amélioration pour le taux de déduplication du cluster, mais aussi pour minimiser le mouvement de la donnée.

Le support du Hot plug pour les disques de type NVMe.

Suppression de la nécessité d’avoir des disques virtuels de types Eager Zero Thick (EZT) pour les disques partagés.

L’article VMware vSAN 7 : Toutes les nouveautés ! est apparu en premier sur MCHELGHAM.

Dans cet article, nous allons voir ensemble comment réaliser un benchmark de notre cluster vSAN avec HCIBench. Cela nous permettra d’avoir une idée des performances que notre cluster peut supporter.

Attention: il n’est pas recommandé de réaliser le test dans un environnement de production, car HCIBench utilisera le stockage de manière intensive. Cela aura un impact sur les autres machines qui s’exécutent sur le même cluster et auront donc des difficultés pour accéder au stockage.

HCIBench ne s’utilise pas uniquement sur du stockage de type vSAN, vous pouvez aussi tester vos autres datastores montés en SAN, NFS, iSCSI.

Téléchargement

Avant de commencer, vous devez télécharger HCIBench depuis flings de VMware.

1- Installation:

L’installation se fait de façon très simple, il suffit d’importer l’OVA depuis le vCenter comme dans les images ci-dessous.

Sélectionner le fichier OVA téléchargé précédemment.

Donner un nom à la nouvelle machine virtuelle, ensuite sélectionner le DC dans lequel vous voulez déployer la machine.

Ensuite, sélectionner le cluster.

Cliquer sur NEXT.

Sélectionner le datastore dans lequel stocker la machine virtuelle.

La machine virtuelle HCiBench disposera de 2 interfaces réseaux, une interface “Management” pour pouvoir se connecter au vCenter si celui se trouve dans un réseau de management, ainsi qu’une interface VM Network depuis laquelle elle communiquera avec les machines virtuelles de test qui seront déployés pour stressé le stockage. Dans mon cas, mon réseau DPG-NOVLAN route le trafic sans aucune restriction vers celui du management.

Étant donné que je dispose d’un serveur DHCP dans mon réseau, je laisse les champs qui concernent la configuration du réseau vide, mais je choisis un mot de passe pour le compte root de l’appliance.

2- Configuration:

Je me connecte à l’adresse https://adresseip:8443 avec le login root ainsi que le mot de passe choisit durant le déploiement de l’ova.

L’interface de configuration apparaît. Dans cette partie nous allons configurer toutes les informations nécessaires pour que HCIBench puisse se connecter à un vCenter et déployer les machines virtuelles de test. Pour cela, vous devez compléter les informations comme dans l’image ci-dessous. Sans oublier de mettre le nom de votre datastore vSAN “vsanDatastore“.

Dans la partie basse, vous devez créer un Worload Parameter File, pour cela cliquer sur ADD.

Compléter les paramètres avec le profil avec lequel le stockage sera testé. Dans mon cas, je mets 8 disques de test par machine virtuelle, avec un WS de 20%, 2 threads par disque, des blocs de 4K, et un pourcentage de lecture de 70% (30% d’écriture), avec des données aléatoires à 100% et je teste tout ça pendant 30Min (1800 secondes).

Une fois validé, je rafraîchis les profils, et je sélectionne le profil précédemment généré.

Pour pouvez sélectionner l’outil de benchmark interne à HCIBench, vous avez le choix entre FIO et VDBENCH. Vous pouvez aussi personnaliser le test en choisissant le nombre de machines virtuelles à déployer ainsi que leur préfixe. Cliquer ensuite sur “SAVE CONFIG” pour enregistrer la configuration.

Une fois que la configuration est enregistrée, il est maintenant nécessaire de la valider. HCIBench va déployer des machines de test pour voir si les paramètres renseignés sont corrects ou non, en plus de ça ce dernier va vérifier que le cluster est bien configuré. Cliquer sur “VALIDATE CONFIG”.

Une fois la validation terminée, observez bien les erreurs remontées et corrigez-les. Sinon le test ne fonctionnera pas ou ne sera pas représentatif. Dans mon cas, HCIBench me demande de désactiver temporairement DRS pour éviter que les machines se déplacent lors du benchmark.

Au bout d’un certain temps, l’interface vous proposera de vous connecter à une jolie interface GRAFANA pour observer en direct les performances et l’état du cluster vSAN.

Ce qui nous donne un joli Dashboard très parlant.

Vous pouvez maintenant attendre la fin du test. Vous pouvez retrouver les différents rapports de test en cliquant sur  “REVIEW RESULT”.

Voilà, c’est terminé! N’hésitez pas à faire des tests de benchmark de vos infrastructures avant leur mise en prod  

L’article Performance vSAN : Réaliser un benchmark avec HCIBench est apparu en premier sur MCHELGHAM.

Un article pour vous montrer comment corriger et/ou supprimer les objets inaccessibles dans un cluster vSAN. Ce genre de problèmes arrivent lorsqu’on maltraite son cluster vSAN mais étant en LAB rien de bien grave, mais il est important d’être vigilant si vous êtes en environnement de production pour ne pas reproduire ce genre de problématiques qui peuvent causer beaucoup de dégâts comme la perte de fichiers ou des VM qui passent en “inaccessible”.

Dans mon cas, le problème est apparu lors d’un changement de policy de stockage vSAN et en même temps j’ai éteint de façon très “sauvage” un de mes ESXi (pendant une longue durée) sans au préalable le mettre en mode maintenance….

La correction / suppression se fera en 4 étapes

• étape 1 : Scan complet du cluster à la recherche des “inaccessible vSAN objects”
• étape 2 : Purge des “inaccessible vswp objects”
• étape 3 : Nouveau scan complet du cluster
• étape 4 : Suppression des objets restants

étape 1

VMware vCenter Server Appliance 6.7.0.20000

Type: vCenter Server with an embedded Platform Services Controller

Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Launch BASH: "shell"

Command> shell
Shell access is granted to root
root@vcsa01a [ ~ ]# rvc administrator@mchelgham.lab@localhost

• Une fois le mot de passe renseigné vous devriez avoir :

0 /
1 localhost/
>

• Dans RVC on se balade dans l’inventaire du vCenter avec les commandes “ls” et “cd“

cd localhost/LABDC/computers/

• Faire “ls” pour afficher les clusters disponibles

/localhost/LABDC/computers> ls
0 CL-MGMT01 (cluster): 
1 CL-CMPT01 (cluster): 
2 vsanwitness01.mchelgham.lab (standalone):

/localhost/LABDC/computers> vsan.check_state CL-CMPT01

2019-03-10 13:34:26 +0000: Step 1: Check for inaccessible vSAN objects
Detected 50 objects to be inaccessible
Detected 2be3725c-2835-e60a-9119-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 27e5725c-4328-d10b-8569-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-0584-c514-2d93-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ee3725c-a470-be15-7859-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected bee2725c-3ef0-9518-722e-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 86e4725c-bdb4-bb1b-3451-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 8ee3725c-2fb8-021f-3b30-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 58e3725c-5c1b-8d24-b062-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-a0ea-7b27-a09a-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 00e4725c-595f-072c-e42d-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 4fe4725c-830d-a12d-38df-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected eae3725c-f197-d52f-d5ef-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 24e3725c-3008-8e31-7dbc-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-03bf-0338-59ea-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 34e3725c-cdf5-5a3d-e913-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ee5725c-300e-3840-876d-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 6ed6725c-bc05-cc40-952e-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ce5725c-8d9d-d74c-15af-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected ece3725c-74d6-5e5e-b7be-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ae5725c-1b47-1060-3eda-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected d0e3725c-6163-9762-76d1-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 45b6725c-73f9-bb63-2d7c-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 3ae3725c-b351-d364-e248-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected dd0e735c-7a95-2967-08a4-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected ce0e735c-5e7d-ed6d-1e80-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected f0e3725c-0b79-3b70-30e6-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-f4d2-0d71-c9a3-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 4fe4725c-5d13-bb72-c2ec-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected c0e2725c-3dd0-f478-faac-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ce0e735c-f4e5-2c7b-29f2-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected eae3725c-da8e-1c82-ced6-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-e219-cb9b-7385-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 3fe3725c-2984-3e9c-9388-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 010f735c-5c18-57a7-7c33-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-b17f-3fab-9c89-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 920e735c-c57e-9ab6-d9a8-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 50e4725c-5926-01b7-6675-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 800e735c-3303-7cba-b842-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 400e735c-b39d-eabe-ce92-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-7a77-debf-c7a0-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 7e0e735c-1c84-42cc-3e73-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected d1e4725c-dd14-f5d4-9b30-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-1764-89d7-5c0f-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected f3e3725c-5080-a0de-b23b-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 52e4725c-0ec6-c0e3-162e-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 1ee3725c-6e37-bfe7-aa60-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-5564-15f3-8eb4-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 50e4725c-1565-bdf6-61ad-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 95e3725c-7438-28f7-c75c-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2fe5725c-2603-09fe-5d0d-002655db0344 on esxi01a.mchelgham.lab to be inaccessible

2019-03-10 13:34:26 +0000: Step 2: Check for invalid/inaccessible VMs

2019-03-10 13:34:26 +0000: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync

étape 2

Nous allons maintenant purger les objets vswp qui sont périmés et plus accessibles avec la commande vsan.purge_inaccessible_vswp_objects suivie du nom du cluster.

/localhost/LABDC/computers> vsan.purge_inaccessible_vswp_objects CL-CMPT01

2019-03-10 13:37:27 +0000: Collecting all inaccessible vSAN objects...
2019-03-10 13:37:27 +0000: Found 50 inaccessbile objects.
2019-03-10 13:37:27 +0000: Selecting vswp objects from inaccessible objects by checking their extended attributes...
2019-03-10 13:37:31 +0000: Found 9 inaccessible vswp objects.
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-------------------------+
| Object UUID                          | Object Path                                                                                                               | Size                    |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-------------------------+
| 45b6725c-73f9-bb63-2d7c-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/0aa4695c-fa0f-3269-dbe1-002655db0344/HCIBench_1.6.8.7-46a0a40e.vswp  | 8589934592B (8.00 GB)   |
| dd0e735c-7a95-2967-08a4-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/d351465c-a762-6d0b-2998-002655db0344/labexpert-vra-a629883b.vswp     | 12884901888B (12.00 GB) |
| ce0e735c-5e7d-ed6d-1e80-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/ab7a475c-b68b-1060-a376-002655db0344/labexpert-iaas-fc7d59ec.vswp    | 4294967296B (4.00 GB)   |
| ce0e735c-f4e5-2c7b-29f2-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/0a8e475c-f287-bbab-917d-002655db0344/labvra-sql-3ea253f8.vswp        | 4294967296B (4.00 GB)   |
| 010f735c-5c18-57a7-7c33-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/54c7375c-2ede-47cf-43d1-002655db0344/NSXMGMT01-d0ea65a9.vswp         | 17179869184B (16.00 GB) |
| 920e735c-c57e-9ab6-d9a8-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/00c7375c-d2fc-ad52-590f-002655daa884/labaxians-win7-a39e16b8.vswp    | 4294967296B (4.00 GB)   |
| 800e735c-3303-7cba-b842-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/fbc6375c-d1d5-22ab-8c0f-002655daa884/labaxians-vesxi01-3a430f56.vswp | 21474836480B (20.00 GB) |
| 400e735c-b39d-eabe-ce92-002655db0344 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/01c7375c-0aeb-dbf4-222e-002655daa884/labaxians-vcsa67-4207c99d.vswp  | 10737418240B (10.00 GB) |
| 7e0e735c-1c84-42cc-3e73-002655daa884 | /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/6de4495c-9043-5331-763d-002655daa884/labexpert-ad-88b91a45.vswp      | 2147483648B (2.00 GB)   |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-------------------------+
2019-03-10 13:37:31 +0000: Ready to delete the inaccessible vswp object...

VM vswp file is used for memory swapping for running VMs by ESX. In VMware
virtual SAN a vswp file is stored as a separate virtual SAN object. When a vswp
object goes inaccessible, memory swapping will not be possible and the VM may
crash when next time ESX tries to swap the memory for the VM. Deleting the
inaccessible vswp object will not make thing worse, but it will eliminate the
possibility for the object to regain accessibility in future time if this is
just a temporary issue (e.g. due to network failure or planned maintenance).

Due to a known issue in vSphere 5.5, it is possible for vSAN to have
done incomplete deletions of vswp objects. In such cases, the majority of
components of such objects were deleted while a minority of components were
left unavailable (e.g. due to one host being temporarily down at the time of
deletion). It is then possible for the minority to resurface and present
itself as an inaccessible object because a minority can never gain quorum.
Such objects waste space and cause issues for any operations involving data
evacuations from hosts or disks. This command employs heuristics to detect
this kind of left-over vswp objects in order to delete them.

It will not cause data loss by deleting the vswp object. The vswp object will
be regenerated when the VM is powered on next time.

Delete /vmfs/volumes/vsan:52a302c1e2dd0b4d-e21261438178731a/0aa4695c-fa0f-3269-dbe1-002655db0344/HCIBench_1.6.8.7-46a0a40e.vswp (45b6725c-73f9-bb63-2d7c-002655db0344)?
  [Y] Yes  [N] No  [A] yes to All  [C] Cancel to all:

[Y] Yes [N] No [A] yes to All [C] Cancel to all: A

étape 3

On relance un scan pour vérifier que le nombre d’objets inaccessibles a diminué (Dans mon cas : Detected 41 objects to be inaccessible).

/localhost/LABDC/computers> vsan.check_state CL-CMPT01
2019-03-10 13:45:27 +0000: Step 1: Check for inaccessible vSAN objects
Detected 41 objects to be inaccessible
Detected 2be3725c-2835-e60a-9119-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 27e5725c-4328-d10b-8569-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-0584-c514-2d93-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ee3725c-a470-be15-7859-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected bee2725c-3ef0-9518-722e-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 86e4725c-bdb4-bb1b-3451-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 8ee3725c-2fb8-021f-3b30-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 58e3725c-5c1b-8d24-b062-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-a0ea-7b27-a09a-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 00e4725c-595f-072c-e42d-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 4fe4725c-830d-a12d-38df-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected eae3725c-f197-d52f-d5ef-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 24e3725c-3008-8e31-7dbc-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-03bf-0338-59ea-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 34e3725c-cdf5-5a3d-e913-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ee5725c-300e-3840-876d-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 6ed6725c-bc05-cc40-952e-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ce5725c-8d9d-d74c-15af-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected ece3725c-74d6-5e5e-b7be-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2ae5725c-1b47-1060-3eda-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected d0e3725c-6163-9762-76d1-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 3ae3725c-b351-d364-e248-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected f0e3725c-0b79-3b70-30e6-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-f4d2-0d71-c9a3-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 4fe4725c-5d13-bb72-c2ec-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected c0e2725c-3dd0-f478-faac-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected eae3725c-da8e-1c82-ced6-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-e219-cb9b-7385-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 3fe3725c-2984-3e9c-9388-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 51e4725c-b17f-3fab-9c89-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 50e4725c-5926-01b7-6675-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-7a77-debf-c7a0-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected d1e4725c-dd14-f5d4-9b30-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2be5725c-1764-89d7-5c0f-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected f3e3725c-5080-a0de-b23b-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 52e4725c-0ec6-c0e3-162e-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 1ee3725c-6e37-bfe7-aa60-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected ebe3725c-5564-15f3-8eb4-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 50e4725c-1565-bdf6-61ad-002655daa884 on esxi01a.mchelgham.lab to be inaccessible
Detected 95e3725c-7438-28f7-c75c-002655db0344 on esxi01a.mchelgham.lab to be inaccessible
Detected 2fe5725c-2603-09fe-5d0d-002655db0344 on esxi01a.mchelgham.lab to be inaccessible

2019-03-10 13:45:27 +0000: Step 2: Check for invalid/inaccessible VMs

2019-03-10 13:45:27 +0000: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync

Comme vous pouvez le voir tous les objets se trouvent dans le même ESXi qui est le esxi01a

étape 4

Dans cette étape, nous allons dans un premier temps nous connecter en ssh sur l’esxi qui contient les objets inaccessibles.

ssh root@esxi01a.mchelgham.lab

Ensuite nous allons supprimer les objets 1 par 1 avec la commande ci dessous

/usr/lib/vmware/osfs/bin/objtool delete -u UUID -f -v 10

Vous devriez remplacer UUID par celui de votre objet

/usr/lib/vmware/osfs/bin/objtool delete -u 2be5725c-0584-c514-2d93-002655db0344 -f -v 10

Faire de même pour tous vos UUID inaccessibles…

Une fois terminé, refaire un scan du cluster avec la commande vsan.check_state suivie du nom du cluster et vous devriez avoir

/localhost/LABDC/computers> vsan.check_state CL-CMPT01
2019-03-10 14:08:22 +0000: Step 1: Check for inaccessible vSAN objects
Detected 0 objects to be inaccessible

2019-03-10 14:08:22 +0000: Step 2: Check for invalid/inaccessible VMs

2019-03-10 14:08:22 +0000: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync

L’article Troubleshooting vSAN : Corriger / Supprimer les objets inaccessibles est apparu en premier sur MCHELGHAM.

Dans cet article nous allons voir comment surveiller les performances d’un cluster vSAN avec “vSAN observer“. L’outil est accessible directement depuis RVC (Ruby vSphere Console) qui est la console Ruby intégrée au vCenter, pour les vCenter encore sous Windows l’outil est disponible dans %PROGRAMFILES%VMwarevCenter Serverrvcrvc.bat.

• Pour commencer, il faut se connecter en console/ssh à la vCSA:

VMware vCenter Server Appliance 6.7.0.14000

Type: vCenter Server with an embedded Platform Services Controller

Last login: Sun Dec 23 14:20:51 2018 from 192.168.XXX.XXX
Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Launch BASH: "shell"

Command>

• Tapez la commande ci-dessous, en modifiant mchelgham.lab par votre domaine SSO.

Command> rvc administrator@mchelgham.lab@localhost
Install the "ffi" gem for better tab completion.
password:

• Une fois le mot de passe renseigné vous devriez avoir :

0 /
1 localhost/
>

• Dans RVC on se balade dans l’inventaire de notre vCenter avec les commandes “ls” et “cd“

cd localhost/LABDC/computers/

• Faire “ls” pour afficher les clusters disponibles

/localhost/LABDC/computers> ls
0 CL-MGMT01 (cluster): 
1 CL-CMPT01 (cluster): 
2 vsanwitness01.mchelgham.lab (standalone):

• Pour lancer la surveillance, tapez la commande ci-dessous en remplaçant le cluster vSAN CL-CMPT01 par le vôtre.

vsan.observer ./CL-CMPT01 --run-webserver --force

• Maintenant pour accéder à l’interface d’exploitation des données il faut atteindre l’URL https://IP-VCSA:8010

• Tant que vsan.observer est lancé la collecte continue (par défaut pendant 2h), pour l’arrêter faire <Ctrl>+<C>

• Dans certaines situations, il pourrait être nécessaire de lancer la collecte et d’enregistrer le résultat dans des fichiers pour pouvoir les exploiter hors ligne ou les envoyer au support VMware par exemple. Pour cela :

cd localhost/LABDC/computers/
vsan.observer ./CL-CMPT01 --generate-html-bundle /tmp

• Pour arrêter la collecte faire <Ctrl>+<C>, ensuite le fichier se trouve dans /tmp :

root@vcsa01a [ /tmp ]# ls | grep vsan
vsan-observer-2018-12-23.15-11-04.tar.gz

• Récupérez le fichier par SCP avec WinSCP par exemple (voir Optionnel 2)

• Décompresser l’archive
• Lancer stats.html

• Pour pouvoir se connecter en SCP à la vCSA, il est nécessaire de changer le shell par défaut de l’utilisateur root, pour cela, tapez la commande ci-dessous en root.

chsh -s "/bin/bash" root

• Une fois que vous avez transféré les fichiers vous pouvez rétablir la configuration du shell en tapant:

chsh -s /bin/appliancesh root

L’article Troubleshooting vSAN : Surveiller les performances d’un cluster vSAN avec vSAN Observer est apparu en premier sur MCHELGHAM.

Un article rapide pour vous donner une solution qui permet de contourner une erreur qui arrive pendant l’installation d’un ou plusieurs ESXi imbriqués (Nested) sur un datastore de type vSAN.

En effet, lors de l’installation de l’ESXi à l’étape de la création d’un volume VMFS par l’assistant d’installation, une erreur bloquante s’affiche et stop l’installation. (Le message de l’erreur peut varier selon la version d’ESXi que vous tentez d’installer).

This program has encountered an error:

Error (see log for more info):
Unable to successfully execute 'tryFormatDevice' after 3 tries.

Installation cannot continue

Lors de la tentative de la création du volume VMFS l’installateur génère une réservation SCSI-2 qui n’est pas supportée par le vSAN.

Pour contourner cela un paramètre avancé existe (FakeSCSIReservations) au niveau des réglages des ESXi.

Sur chaque ESXi qui participe au cluster vSAN tapez en console/SSH :

esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1

Attention les ESXi imbriqués ne sont pas officiellement supporté par VMware, à utiliser uniquement que dans le cadre de LAB/POC.

L’article Contourner l’erreur lors de l’installation d’un nested ESXi dans un vsanDatastore est apparu en premier sur MCHELGHAM.