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.