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 comment faire pour Désactiver / Supprimer et Redéployer les machines virtuelles vCLS qu’on retrouve depuis la version 7 de vSphere au sein de nos clusters VMware.

Pour commencer, il est important de préciser à quoi servent les machines vCLS.

Les machines virtuelles vCLS servent à contrôler les fonctionnalités DRS et HA de vSphere en proposant des recommandations de placement ou de redémarrage des machines virtuelles suite à une charge importante du cluster ou suite à un sinistre qui touche nos ESXi. Auparavant, cela était contrôlé directement par le vCenter, mais depuis la version 7 cela se passe maintenant directement à l’aide des machines vCLS pour avoir une meilleure disponibilité des fonctionnalités et pour des futures nouvelles fonctionnalités qui utiliserons les vCLS.

Désactiver / Supprimer

Pour désactiver les machines vCLS, on doit mettre le cluster en Retreat Mode.

Pour cela, se placer sur votre cluster pour récupérer son ID

Au niveau de la barre d’adresse de votre navigateur, noter l’ID qui commence par domain-cXXXX, dans mon cas c’est domain-c1005

Aller à la fin de la fenêtre et rajouter config.vcls.clusters.domain-cXXXX.enabled avec pour valeur FALSE. Replacer XXXX par l’ID de votre cluster. Cliquer sur ADD ensuite sur SAVE.

Vous pouvez vérifier la bonne prise en compte en cherchant la valeur qui commence par config.vcls.

À la suite de cette configuration, patientez environs 1 min pour que vCenter supprime les machines vCLS existantes.

Redéployer

Pour redéployer les machines vCLS, vous devez juste repasser le paramètre en TRUE au lieu de FALSE. Par la suite, le vCenter procèdera au redéploiement des machines vCLS.

L’article vSphere : Désactiver / Supprimer / Redéployer les VMs vCLS 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.

introduction

Nous allons dans cet article voir comment mettre en place un cluster vSAN avec uniquement 2 hôtes.

Pour pouvoir fonctionner correctement, en plus des 2 hôtes il est obligatoire d’avoir une VM Witness qui doit-être hébergée de préférence dans un site indépendant du/des premier(s).

La VM Witness sert au stockage des métadonnées des objets contenus dans vSAN et permet de participer aux votes pour le quorum, la VM ne sert pas au stockage des données! et demande un faible débit réseau avec le cluster vSAN.

La VM Witness est tout simplement un nested ESXi en version 6.5 préparé par VMware pour faciliter les déploiements de vSAN. C’est le seul cas où VMware tolère et supporte la virtualisation d’ESXi, mais il n’est pas toléré de faire tourner des VM dans ce dernier.

Il existe plusieurs façons de faire du vSAN à 2 hôtes, l’architecture finale dépend des besoins.

• Cluster 2 node sur 2/3 sites avec un node sur SITEA, deuxième node sur SITEB et le Witness sur un 3e site.
• Cluster 2 node ROBO (Remote Office Branch Office), les deux node se trouvent dans le même site SITEA et le Witness en SITEB.

Les architectures ci-dessus sont flexibles et peuvent être adaptées à tous les besoins à condition de respecter une latence d’au maximum 5ms RTT (aller-retour) dans le réseau vSAN entre les 2 node, et de 500ms RTT maximum entre le réseau vSAN et le witness. En ce qui concerne le débit VMware préconise du 10GB dans le réseau vSAN entre les 2 node.

Pour le débit qui concerne la VM Witness avec le réseau vSAN cela dépend du nombre d’objets qui se trouvent dans le datastore, on utilise la formule débit (octet) = 1138 B x NumComp / 5 seconds pour déterminer le débit.

Par exemple pour environs 166VM avec pour chacune 3 objets (vmx, vmdk, vmswap) le tout avec un PFTT de 1 (on tolère la perte d’un site) ce qui nous fait au total 1000 objets, il est nécessaire d’avoir un débit d’environs 2Mbps (inclus une marge de sécurité de 10%). Débit (octet) = 1138 B  * 1,000 / 5s = 227600 octets = 0,227 Mo/s ==> conversion en Bits *8 = 1.82 Mb/s + on rajoute une marge de 10% = environs 2Mb/s.

Un autre exemple : 1500VM avec pour chacune 3 objets (vmx, vmdk, vmswap) le tout avec un PFTT de 1 nous donne donc 9000 objets: Débit (octet) = 1138 B  * 9000 / 5s = 20048400 octets = 2 Mo/s ==> conversion en Bits *8 = 16 Mb/s + on rajoute une marge de 10% = environs 17,6Mb/s.

Une autre notion qu’il faut comprendre est le PFTT (Primary Failures To Tolerate), depuis le début de l’article on parle de 2 node physique qui sont en miroir et qui nous permettent une PFTT de 1, en réalité nous avons donc 2 domaines de pannes on tolère la perte d’un site complet (dans notre article chaque domaine de panne contient un seul ESXi).

Nous avons aussi le SFTT (Secondary Failures To Tolerate), qui permet de définir combien d’ESXi nous pouvons perdre dans chaque site/domaine de panne dans les cas où chaque site dispose de plusieurs ESXi qui participent au stockage vSAN.

Le contenu qui va suivre dans cet article s’applique donc à toutes les architectures avec 2 domaines de pannes quelle que soit le nombre d’ESXi qui se trouvent dans chaque domaine, le principe reste le même.

La VM Witness est disponible gratuitement sur le site de VMware avec une licence qui est auto générée pour le nested ESXi. Il n’est donc pas nécessaire d’acheter une licence pour ce dernier.

Prérequis

• L’architecture ci-dessus
• L’OVF de la VM Witness à télécharger sur le site de VMware.
• Assez de ressource pour faire tourner 2 ESXi de 6GB chacun + VM Witness + vCenter

Configuration LAB requise

• vCenter installé avec 2 Node dans l’inventaire.
• Dans mon cas chaque ESXi dispose de 4 cartes réseau (2 MGMT et 2 vSAN).
• Chaque ESXi dispose en plus du disque dans lequel est installé l’ESXi un HDD de 100GB et d’un HDD de 10GB tagué en FLASH.
• Configuration réseau suivante
• Création du dvs-MGMT et du port groupe DPG-MGMT + configuration IP
• Création du dvs-vSAN et du port groupe DPG-vSAN + Configuration IP
• Préparer les ports groupes nécessaires dans le site qui hébergera la VM Witness dans mon cas je les ai appelés labvsan-witnessMGMT et labvsan-witnessvSAN

Sommaire

• 1) Import de la VM Witness dans le 3e site.

• 2) Configuration du réseau de MGMT de la VM Witness.

• 3) Ajout de l’hôte Witness dans le vCenter

• 4) Configuration IP du VMKernel vSAN

• 5) Création du Cluster vSAN 2 nodes.

• 6) Vérification

1) Import de la VM Witness dans le 3e site

Pour commencer, il est nécessaire d’importer l’OVF téléchargé sur le site de VMware et de le déployer sur le 3e site dans lequel se trouvera le Witness. Pour cela cliquer sur “Déployer un modèle OVF” dans le vCenter.

Cliquez sur “parcourir” et sélectionnez le fichier OVF. Cliquez ensuite sur “suivant“.

Donnez un nom à la VM, ensuite sélectionner le DC dans lequel se placera la VM.

Choisir le cluster dans lequel déployer la VM.

Acceptez les conditions générale, cliquer ensuite sur suivant.

Choisir provisionnement dynamique dans le cadre de ce LAB. Sélectionnez par la suite le datastore sur lequel la VM sera hébergée. Dans mon cas “vsanDatastore“, car mon LAB utilise déjà du vSAN.

Cette étape est très importante ! Il est nécessaire de choisir les bons ports groupes pour les deux réseaux proposés. Pour le Witness Network choisir le port groupe qui sera capable d’aller jusqu’au réseau vSAN de notre futur cluster et Management Network le réseau qui sera capable d’atteindre le vCenter qui gère notre cluster vSAN.

Choisir le mot de passe pour le compte root de l’ESXi Witness.

2) Configuration du réseau de MGMT de la VM Witness.

Après avoir démarré la VM Witness, ouvrir la console.

Appuyer sur la touche F2 pour aller dans le menu de configuration de l’ESXi. mettre le clavier en French et le mot de passe du compte root. Appuyez ensuite sur la touche ENTRÉE du clavier.

Mettre l’adressage en statique et remplir avec l’adresse IP de management de l’ESXi ainsi que le masque et une passerelle par défaut si elle existe. Il est important de comprendre que dans mon cas ma passerelle connait le réseau du vCenter qui héberge le cluster vSAN et routera donc le trafic vers ce dernier. Si vous votre passerelle ne route pas ou ne connait pas le réseau du vCenter vous êtes obligé de vous connectez en SSH sur l’ESXi et le vCenter pour rajouter les routes statiques dans chacun d’eux pour qu’ils puissent s’atteindre mutuellement.

Appuyez sur la touche ECHAP, une fenêtre vous demande si vous voulez appliquer les paramètres. Appuyez sur la touche Y de votre clavier pour valider.

Maintenant, le réseau Management de notre ESXi Witness est bien configuré.

3) Ajout de l’hôte Witness dans le vCenter

L’hôte est maintenant ajouté dans le vCenter et l’icône bleue de celui-ci nous signale que c’est un ESXi Witness utilisable uniquement pour les clusters vSAN en tant que témoin et ne sert pas a héberger des VM.

4) Configuration IP du VMKernel vSAN

Mettre l’adresse IP ainsi que le masque. Par défaut les VMKernel, leur passerelle par défaut est automatiquement configurée avec l’IP de la passerelle de l’interface Management. Dans notre cas le réseau vSAN de l’hôte Witness ainsi que le réseau vSAN du cluster vSAN ne sont pas dans le même réseau. Il est donc obligatoire de montrer le chemin que l’adaptateur doit prendre pour atteindre le réseau vSAN distant. Comme pour l’adresse IP de management ma passerelle par défaut connait le réseau vSAN, j’ai donc juste à mettre la bonne passerelle par défaut qui se trouve dans le même réseau que l’adresse IP 192.168.14.1, le routage sera fait par ma passerelle. Si vous votre passerelle ne route pas ou ne connait pas le réseau du vSAN distant vous être obligé de vous connectez en SSH sur l’ESXi01, l’ESXi02 ainsi que l‘ESXi Witness et rajouter les routes statiques nécessaires dans chacun d’eux pour qu’ils puissent s’atteindre mutuellement.

5) Création du Cluster vSAN 2 nodes

Donnez un nom au Cluster SANS rien cocher et cliquez sur OK

Sélectionner le CLUSTER-vSAN, allez dans configurer => vSAN => Général => Configurer

Dans cette étape il faut sélectionner les disques de capacité et les disques du cache. Dans mon cas le disque de 100Go est un disque HDD de capacité, le disque de 10Go je l’utilise en tant que disque de cache pour cela il est nécessaire de le tagué en flash pour qu’il puisse être utilisé en cache, car c’est un disque HDD à la base. Cliquez ensuite sur Suivant.

Maintenant que tout est prêt, cliquer sur Terminer.

6) Vérification

Dans cette partie, nous allons vérifier que notre Cluster vSAN 2 hôtes fonctionne correctement. Dans l’onglet “Surveiller” de notre cluster, dans Santé du vSAN, nous avons une vue globale sur l’état de santé de notre cluster. Ici nous avons 4 avertissements.

• Disque physique : Dans mon cas le total de l’espace disque est < 250Go
• Compatibilité matérielle : Ce Lab est virtualisé cet avertissement est donc normal
• Service de performance : Par défaut le service est désactivé, il suffit de cliquer sur l’avertissement et vSAN vous proposera de l’activer. Ce service permet d’avoir en temps réel la performance du cluster (IOPS, Débit…)
• Recommandation de la build vSAN : Il est nécessaire de mettre les identifiants myvmware pour que vSAN puisse se connecter au service de recommandation de build.

Dans l’onglet datastore on trouve notre nouveau datastore “vsanDatastore“.

Dans Surveiller => vSAN => Tests proactifs, il est possible de lancer un test de création de VM dans le vsanDatastore et vérifier que tout fonctionne correctement. Cliquer sur la flèche verte pour lancer le test.

Confirmez en cliquant sur “Oui“

L’article Mise en place d’un cluster vSAN à 2 hôtes [Stretched cluster] est apparu en premier sur MCHELGHAM.

INTRODUCTION

Je vais à travers cet article vous expliquer les avantages et fonctionnements de vSphere HA de VMware.

Il existe deux types de surveillances dans vSphere HA, la première est la surveillance d’hôtes (Host Monitoring), la deuxième est la surveillance des VMs et applications (VM Monitoring).

vSphere HA Host Monitoring

La fonctionnalité vSphere HA Host Monitoring permet de rajouter un niveau de protection non négligeable pour vos VMs, car elle permet en cas de panne de l’un de vos hôtes, de redémarrer les VMs qu’il contenait sur un ou plusieurs autres hôtes.

Donc vSphere HA Host Monitoring redémarre les VM sur un autre hôte SI:

• L’hôte ne répond plus sur le réseau de management
• Aucun signal de pulsation (heartbeats) n’est émis de la part de l’hôte vers les Datastores

Configuration de vSphere HA Host Monitoring

vSphere HA VM Monitoring

Permet de surveiller à l’aide des VMware Tools l’état de fonctionnement de l’OS de vos VMs et des applications compatibles avec vSphere HA, en cas de non-réponse de la part de ceux-ci (Écran bleu par exemple), vSphere HA VM Monitoring redémarre complètement la machine pour tenté de la rendre fonctionnelle à nouveau.

Donc vSphere HA VM Monitoring redémarre la VM SI:

• Plus aucun signal de pulsation (heartbeats) n’est reçu de la part des VMware Tools dans un certain intervalle: 
• La VM ne génère plus aucune E/S (entrée/sortie) au niveau du stockage et du réseau (intervalle de 120 secondes par défaut personnalisable avec le paramètre das.iostatsInterval)

Configuration de vSphere HA VM Monitoring Sélectionner votre cluster, ensuite aller dans Configurer > Disponibilité vSphere > Modifier

Dans Disponiblité vSphere > Pannes et réponses > Surveillance de VM, cocher la case Surveillance de VM.

Dans la partie “Sensibilité de la surveillance des signaux de pulsations“, sélectionnez le niveau de surveillance (Basse/Moyenne/Haute) suivant le tableau au-dessus.

Lien

L’article Avantages et fonctionnements de vSphere HA est apparu en premier sur MCHELGHAM.

INTRODUCTION

Aujourd’hui, nous allons voir à travers plusieurs articles et vidéos comment mettre en place un cluster de plusieurs ESXi en lui activant les fonctionnalités  vSAN, DRS, EVC, vSphere HA, ainsi que Fault Tolerance

vSAN : Solution logicielle (Software Defined Storage) qui permet de grouper tous les disques des différents ESXi de notre cluster pour en faire un seul Datastore qui fournit un haut niveau de performance et de sécurité des données.

DRS (Distributed Ressource Scheduler): fonction qui permet d’équilibrer la charge des différents ESXi en répartissant les VMs sur les différents hosts de notre cluster.

EVC (Enhanced vMotion Compatibility): Fonction qui permet d’améliorer la compatibilité vMotion en configurant tous les hosts du cluster avec le même niveau de fonctionnalité CPU. Si dans notre cluster nous avons 2 hosts avec CPU INTEL de 7ème génération et 1 host avec CPU INTEL de 6ème génération. EVC va brider le cluster à la génération la plus basse.

vSphere HA : Fonction qui assure la haute disponibilité (failover) de nos VM. En cas de perte d’un des ESXI, les VM qui étaient présentes dans celui-ci redémarrent automatiquement sur les autres ESXi disponibles au sein du cluster. On a donc une coupure de service de courte durée.

Fault Tolerance : Fonction qui permet de faire de la Très Haute Disponibilité, Notre VM est synchronisée en temps réel sur un autre ESXi. En cas de panne du premier, la VM continue à fonctionner sur le deuxième en toute transparence.

AVERTISSEMENT

ATTENTION : LA CONFIGURATION CI-DESSUS EST A UTILISER UNIQUEMENT DANS UN LAB POUR TESTER LES SOLUTIONS ET VOIR LEUR FONCTIONNEMENT, EN PRODUCTION IL EST TOTALEMENT DÉCONSEILLER D’AVOIR UN SEUL RÉSEAU DANS LEQUEL DES DONNÉES VSAN, VMOTION, JOURNALISATION FT, GESTION ET ADMINISTRATION QUI CIRCULENT ENSEMBLE.

1 – PRÉSENTATION + CONFIGURATION DE BASE D’UN CLUSTER

2 – CONFIGURATION DE vSAN 6.6

3 – CONFIGURATION DE vSPHERE HA + DRS + EVC

4 – CONFIGURATION DE VMWARE FAULT TOLERANCE

L’article Mise en place d’un Cluster vSAN, vSphere HA, DRS, EVC et Fault Tolerance[VIDEO] est apparu en premier sur MCHELGHAM.