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.

Dans cet article nous allons voir comment déployer rapidement et en quelques clics un cluster vSAN dans lequel on installe le vCenter. Cela est possible grâce à l’assistant d’installation de la vCSA 6.5/6.7 qui dispose d’une fonctionnalité qui nous permet de gagner du temps lors de déploiement de clusters vSAN. Le cluster hébergera son propre vCenter.

PRÉREQUIS LAB

• ISO du vCenter 6.7 U1
• 3 hôtes ESXi 6.7 avec au minimum 15Gb de RAM pour le premier et 6Gb de RAM pour les 2 autres.
• Dans chaque hôte au moins 2 cartes réseaux. (1 pour management/vMotion et 1 pour le vSAN).
• Adressage IP ci-dessous

INSTALLATION DU VCENTER

Commencer la configuration de la vCSA comme dans l’animation ci-dessous.Vous aurez besoin d’un ESXi avec assez de RAM pour déployer le vCenter dessus (étape 4).

Donner un nom de VM au vCenter (étape 5), ainsi qu’un mot de passe pour le compte root de l’appliance.

Continuer la configuration de la vCSA comme dans l’animation ci-dessous. À l’étape 7 choisissez “install on a new vSAN Cluster…”, à l’étape 8 donner un nom aux nouveaux Datacenter et Cluster qui seront créés.

Réclamer les disques de l’ESXi comme dans l’animation ci-dessous, avec au minimum un disque de cache (SSD) et un disque de capacité (SSD ou HDD). (Dans le cadre de ce LAB j’ai tagué un disque HDD en tant que disque SSD).

Pour l’étape 9, configurer les informations FQDN/IP/DNS et cliquez sur Next.

Continuer la configuration de la vCSA (stage 2) comme dans l’animation ci-dessous.

Une fois la configuration terminée, cliquer sur le FQDN du vCenter.

Lancer le vSphere client (HTML5).

AJOUT DES AUTRES HÔTES AU CLUSTER

Valider l’ajout des hôtes comme dans l’animation ci-dessous.

Voilà, les hôtes sont maintenant dans le cluster, mais avant de les sortir du mode maintenance, il est nécessaire de configurer les réseaux des hôtes.

CONFIGURATION RÉSEAU

Ci-dessous une capture de la configuration réseau de l’hôte 1

Ci-dessous une capture de la configuration réseau de l’hôte 2

Ci-dessous une capture de la configuration réseau de l’hôte 3

(En option), si vous avez besoin d’utiliser le vMotion n’oubliez pas de l’activer sur l’interface VMkernel 0 (vmk0).Vous pouvez maintenant quitter le mode maintenance des hôtes.

RÉCLAMER LES DISQUES

Pour que le vSAN fonctionne correctement, il est nécessaire de réclamer les disques des hôtes restants. Pour cela au niveau du Cluster aller dans vSAN => Gestion des disques, cliquer sur l’icône de réclamation des disques.

Réclamer les disques comme dans l’animation ci-dessous. (Dans le cadre de ce LAB, j’ai tagué les disques HDD en tant que disques SSD).Maintenant que tous les disques sont réclamés, vérifier que le groupe de partition est le même pour tous les hôtes, si ce n’est pas le cas vérifier votre configuration réseau.Voilà vous disposez maintenant d’un datastore vSAN qui cumule la capacité des disques de tous les hôtes.

RAPPLIQUER LA POLITIQUE DE STOCKAGE AU VCENTER

Maintenant que le cluster est bien configuré, il est nécessaire de réappliquer la politique de stockage vSAN sur la VM vCenter pour qu’elle soit conforme à la nouvelle configuration.

Vous pouvez suivre l’état de la resynchronisation au niveau du cluster dans Surveiller => vSAN => Objets de resynchronisation.

Ajout du witness (Stretched Cluster)

Si vous êtes en train de déployer un cluster étendu, vous devez définir le witness du Cluster. Pour cela, ajouter dans un premier temps l’hôte witness dans le vCenter, ensuite aller au niveau du cluster dans Configurer => Domaines de pannes => cluster étendu, et suivez l’assistant.

L’article Déployer rapidement la vCSA 6.7 U1 dans un nouveau cluster vSAN 6.7 U1 est apparu en premier sur MCHELGHAM.

introduction

Nous allons dans cet article voir comment mettre en place vCenter HA. vCenter High Availability est une nouvelle fonctionnalité apparue avec la version 6.5 du vCenter mais disponible uniquement dans la vCSA.

vCenter HA permet de protéger de façon encore plus efficace les vCenter des pannes matérielle, mais aussi logicielle là ou des mécanismes de protection comme vSphere HA protège uniquement des pannes matérielles avec un temps de coupures assez important et des risques de corruption de la base de données interne du vCenter.

vCenter HA fonctionne avec la création d’un cluster de vCenter dans lequel 2 instances vCenter se synchronisent entre elles, la première instance est “Active” alors que la seconde est en mode “Passive” ce qui nous permet d’avoir un Recovery Point Objective (RPO) de ZERO.

Lorsque l’instance active ne répond plus, un failover se produit et l’instance “Passive” prend le rôle d’active et continue à servir les demandes des utilisateurs/applications. En ce qui concerne le Recovery Time Objective (RTO) il est inférieur à 5 minutes.

Le node Witness ne participe pas au cluster Active/Passive, mais participe au quorum lorsque les deux instances ne peuvent plus communiquer ensemble.

Il est important de penser à la mise en place de vCenter HA dans les environnements où des solutions comme NSX et les suites vRealize tournent, car ces dernières dépendent grandement de la disponibilité du vCenter pour pouvoir fonctionner.

vCenter HA  – Architecture

• Active node: l’instance active qui reçoit les requêtes utilisateurs/applications (vCenter complet avec 10GB de RAM).
• Passive node: l’instance passive qui se synchronise de façon continue avec l’instance active et attend l’échec de ce dernier pour prendre son rôle et son identité (adresse IP).  (vCenter complet avec 10GB de RAM).
• Witness node: l’instance qui participe aux décisions lorsque les deux instances (active et passive) ne peuvent plus communiquer entre elles (vCenter léger avec 1GB de RAM).

vCenter HA  – Prérequis

• Un Port groupe dédié au trafic vCenter HA (Eth1)
• 3 adresses IP pour les interfaces Eth1
• Assez de ressource pour 2 vCenter et un Witness

vCenter HA  – Configuration

Pour commencer, cliquez sur votre vCenter au niveau du vSphere Web Client

L’assistant de configuration apparait et nous propose deux modes de configuration le basique et l’avancé. Je vous conseille d’utiliser le mode Basique dans lequel l’assistant s’occupe du rajout de la nouvelle interface Eth1 et la configuration de l’adresse IP dans le vCenter existant ainsi que son clone.

Mettre l’adresse IP dédiée à l’interface Eth1 dans le réseau vCenterHA du vCenter existant, ainsi que le port groupe créé pour l’occasion.

Faire de même pour les interfaces Eth1 du nouveau vCenter passif ainsi que le Witness.

Ici vous avez un résumé du futur emplacement du vCenter passif ainsi que le témoin. Vous avez la possibilité de modifier cela en cliquant sur “Modifier” sinon cliquez sur suivant.

Un résumé vous affiche la configuration qui sera déployée. Cliquer sur Terminer pour commencer.

Dans les taches récentes, vous pouvez voir l’avancement de la configuration.

Une fois terminé, le vCenter HA est activé, mais il est nécessaire de patienter le temps de la synchronisation des deux vCenter (Actif et passif).

Une fois la synchronisation terminée. Un message vous indique que la protection est bien activée!

vCenter HA  – Test

Confirmer le basculement en cliquant sur “Oui”

En allant sur votre vCenter la connexion est plus possible pendant quelques minutes le temps que le vCenter passif prend l’identité du vCenter anciennement actif.

Après quelques minutes, l’interface du vCenter apparait!

En ouvrant le vCenter Web client, ce dernier vous indique qu’un failover est en cours et qu’il est nécessaire de patienter.Après quelques minutes le vSphere Web Client est de nouveau fonctionnel.

Nous avons bien un RPO de 0 et un RTO de quelques minutes (2 à 5minutes).

L’article Mise en place de vCenter HA (High Availability) est apparu en premier sur MCHELGHAM.

INTRODUCTION

Je vais dans cet article vous expliquer comment installer vCSA 6.7 dans VMware Workstation 14 ou Fusion 10 (Mac). L’objectif est d’avoir un vCenter fonctionnel sans devoir à installer un ESXi dans lequel déployer la VCSA. Cette installation n’est pas du tout recommandée en production, mais peut être réalisée uniquement dans un environnement de lab et de test.

PRÉREQUIS

• VMware Workstation 14 ou Fusion 10
• l’ISO de la vCSA 6.7 depuis le site de VMware
• 8 GB d’espace disque.
• 10 GB de RAM de disponible dans votre Système d’exploitation.

vCSA 6.7 dans Workstation 14 / Fusion 10

Dans la partie “Networking Configuration” remplissez comme dans l’image ci-dessous en adaptant avec vos propres paramètres IP. Cliquez ensuite sur “Import“.

Une fois l’import terminé, la machine démarre automatiquement. /!IMPORTANT/! par défaut la machine est configurée en mode “Bridge“, si vous devez la mettre en “NAT” ou “Host Only” vous devez l’arrêter avant qu’elle ne démarre complètement et faire les modifications nécessaires puis la relancer.

Le démarrage met un peu de temps, une fois celui-ci terminé, vous arrivez sur l’écran de l’appliance qui nous dit qu’aucun mot de passe root n’est configuré. Vous devez donc en configurer un en appuyant sur la touche F2 de votre clavier.

Par la suite, appuyez sur la touche Echap de votre clavier pour sortir de l’écran de configuration de la console.

On arrive à une étape importante, avant de poursuivre, il est nécessaire de remplacer le nom du système “photo-machine” par l’IP.

Laissez le choix “Créer un domaine SSO“, choisissez un nom de domaine SSO et un mot de passe pour le compte “administrator“. Cliquez sur “SUIVANT” pour continuer.

L’écran de connexion apparaît. Renseignez avec le compte administrator@domaine.SSO et le mot de passe. Cliquez ensuite sur “Connexion“

Voilà c’est terminé. Vous venez d’installer le vCenter dans VMware Workstation. Les mêmes manipulations s’appliquent aussi pour VMware Fusion sur MAC.

L’article Installation de vCSA 6.7 dans VMware Workstation / Fusion est apparu en premier sur MCHELGHAM.

RAPPEL

Petit article pour vous rappeler que la fin générale du support (EOGS) de vSphere 5.5 et vSAN 5.5 arrive à grands pas, car elle est fixée pour le 19 septembre 2018.

C’est aussi l’occasion pour vous d’accélérer votre transformation digitale et moderniser vos infrastructures SDDC (Software Defined DataCenter) ou Centre de données définies par logiciel pour les puristes de la langue française.

Il est donc fortement recommandé pour vous de ne pas oublier cette date en continuant à migrer votre infrastructure ; et si vous n’avez toujours pas commencé, c’est une bonne raison de commencer maintenant en prenant de l’avance et en demandant les budgets nécessaires à votre direction.

Car, si vous n’anticipez pas dès maintenant les vacances d’été, les jours de récupération et les jours fériés vous risquer de vous retrouver à la rentrée de septembre avec beaucoup choses à gérer.

Dans les prochains articles, j’aborderais avec vous les moyens possibles pour pouvoir réaliser la migration des différents composants VMware comme vSphere, vCenter et vSAN vers leurs dernières versions.

LIENS

N’hésitez pas à visiter mes différents articles sur comment mettre en place un cluster vSphere 6.5 et vSAN 6.6.

L’article RAPPEL : Fin de support pour vSphere 5.5 et vSAN 5.5 est apparu en premier sur MCHELGHAM.

INTRODUCTION

Aujourd’hui, je vais vous parler du PSC qui est un composant très important dans une infrastructure vSphere, car il centralise à lui tout seul énormément de fonctionnalités importantes.

Pour commencer, PSC est l’acronyme de Platform Services Controller, il simplifie et centralise des services comme la gestion des licences, des tags, gestion de l’identité avec les permissions, les rôles, domaines Single Sign-on (SSO) et les certificats ! Avant la version 6 de vSphere, beaucoup des services cités précédemment été gérés de façon séparée.

Le PSC est nécessaire pour le vCenter! sans PSC aucune possibilité d’installer un vCenter.

DÉPLOIEMENT

Comment se fait le déploiement d’un PSC ? à l’étape d’installation du vCenter (VCSA) vous avez le choix entre deux types d’installations

Embedded Mode

Le mode intégré comme son nom l’indique permet une installation d’une Appliance vCenter ainsi que l’installation du PSC dans cette même Appliance (une seule VM). Ce mode est idéal pour les petits environnements.

External Mode

Le mode external permet de déployer dans un premier temps une Appliance avec un PSC (une seule VM) et en second temps permet l’installation du vCenter (Une deuxième VM) en lui indiquant l’adresse de la première Appliance PSC.

À savoir : Plusieurs vCenter peuvent se connecter au même PSC!

Pourquoi deux modes différents ? Le deuxième type de déploiement nous permet beaucoup de flexibilité, comme la possibilité de lier plusieurs vCenter au même PSC et de mettre en place des mécanismes de très haute disponibilité et de Load Balancing entre plusieurs instances PSC synchronisées.

ACCÈS

Configuration requise

L’article Le Platform Services Controller (PSC) en bref! 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.

VIDEO

INTRODUCTION

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 7e génération et 1 host avec CPU INTEL de 6e 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.

CONFIGURATION VM

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 – CONFIGURATION EVC

La configuration de la fonctionnalité EVC est tellement simple que l’explication tient juste en une seule image  Dans l’onglet “Configurer” de notre ClusterLAB aller dans “Configuration->VMware EVC” ensuite cliquer sur “Modifier“. Dans la fenêtre qui apparaît “le type de mode” sélectionner celui qui correspond à votre CPU (AMD ou INTEL), ensuite EVC vous proposera automatiquement la génération la plus haute compatible avec votre Cluster. Cliquer sur “OK” pour terminer la configuration.

2 – CONFIGURATION DRS

3 – CONFIGURATION vSphere HA

IMPORTANT: Cette partie concerne uniquement les personnes qui se trouvent dans la même situation que moi. Cette partie est nécessaire si vos ESXi vous leur avait pas affecter de passerelle par défaut dans l’interface de MGMT. vous avez juste configuré IP+MASQUE. Une adresse appelée adresse d’isolation est nécessaire pour chaque host dans le cas ou celui-ci ne reçoit plus de signal heartbeat il se retrouve alors isolé, avant de prendre une décision et pour qu’il soit sur qu’il n’a pas de problème réseau l’host tente de faire un PING vers l’adresse d’isolation “das.isolationaddress0” par défaut vSAN configure l’adresse de la passerelle par défaut en tant qu’adresse d’isolation. Dans options avancées il est donc possible de choisir une adresse personnalisée. Dans mon cas j’ai mis le vCenter en tant qu’adresse d’isolation. une fois terminé, cliquer sur “OK“

Nous venons de voir les fonctionnalités vSphere HA, DRS et EVC vous pouvez maintenant passer à la [PARTIE 4].

L’article [PARTIE3] Configuration de vSphere HA + DRS + EVC [VIDEO] est apparu en premier sur MCHELGHAM.

VIDEO

INTRODUCTION

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.

CONFIGURATION VM

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 LAQUELLE DES DONNÉES VSAN, VMOTION, JOURNALISATION FT, GESTION ET ADMINISTRATION QUI CIRCULENT ENSEMBLE.

1 – CONFIGURATION DE Fault Tolerance

Voilà,  maintenant vous savez comment mettre en place la fonctionnalité VMware Fault Tolerance.

L’article [PARTIE4] Configuration de VMware Fault Tolerance [VIDEO] est apparu en premier sur MCHELGHAM.