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 ensemble comment créer une Clé USB bootable à partir de l’ISO de VMware vSphere sur un MacOS. 

Pour commencer, brancher la clé USB dans votre Mac. Ensuite, lister la liste des disques branchés pour repérer le numéro du disque avec la commande : 

diskutil list

Une fois le numéro du disque repéré, dans mon cas c’est le #2 (/dev/disk2). Formater la clé USB avec la commande ci-dessous, en remplaçant disk2 par le numéro de votre disque.

diskutil eraseDisk MS-DOS "ESXI" MBR disk2

Une fois le formatage est terminé, démontez le disque avec la commande :

diskutil umountDisk /dev/disk2

Nous allons maintenant écrire le MBR sur la clé USB avec les commandes :

sudo fdisk -e /dev/disk2
f 1
write
quit

Une fois que l’opération est terminée, monter votre ISO ESXi sur votre Mac et copier tout son contenu vers la clé USB.

Patientez pendant la copie.

Une fois la copie terminée, repérer le fichier ISOLINUX.CFG

Renommer ISOLINUX.CFG par SYSLINUX.CFG

Une fois le renommage terminé, éditer le fichier SYSLINUX.CFG et rajouter -p 1 à la ligne APPEND -c boot.cfg 

Vous pouvez maintenant éjecter proprement la Clé USB et la brancher sur votre machine pour booter dessus.

L’article vSphere : Création d’une clé USB Bootable ESXi sur MacOS est apparu en premier sur MCHELGHAM.

Dans mon précédent article, j’ai parlé de certaines améliorations techniques qui ont été intégrées à vSphere 7 pour améliorer la qualité de services offerte par la plateforme aux charges de travail.

Avec vSphere 7, l’objectif est de répondre à la demande croissante en performance des charges de travail en améliorant les différentes technologies introduites par VMware dans les années passées. Aujourd’hui, dans un monde très concurrentiel, les performances des charges de travail ont un impact sur la productivité des entreprises.

La vMotion a donc était repensé pour répondre à ce challenge.

Fonctionnement de vMotion dans vSphere 7

Pendant une migration vMotion, chaque modification de la mémoire est surveillée avec un système appelé “Page Tracer”. Ce système est installé dans chaque vCPU alloué à la machine virtuelle, ce qui cause des impacts signifiants sur leur performance.

Avec vSphere 7, ce système est optimisé en utilisant uniquement un seul vCPU pour réaliser le “Page Tracer”. Ce qui permet donc d’avoir un très faible impact de performance au niveau de la machine virtuelle.

Pendant la dernière phase qui permet de réaliser le switch-over d’un ESXi vers un autre, les derniers bitmap (tableau de données binaire) sont donc transférés. Dans les versions précédentes, tout le tableau bitmap est transféré, ce qui posait d’énormes problèmes de performance sur les machines virtuelles qui disposent d’une très grande quantité de mémoire. Aujourd’hui avec vSphere 7, seule une version compactée du tableau bitmap est transférée. Ce qui nous permet pour une machine de 24TB par exemple d’avoir un switch-over de 175ms au lieu de 2s !

Pour résumé, un comparatif entre vMotion dans les versions précédentes et vMotion dans vSphere 7 !

L’article vSphere 7 : Nouveautés vMotion 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.

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 savons tous à quel point la sauvegarde de la configuration de nos solutions est importante et peut nous éviter une réinstallation complète ou la perte d’un gros volume de données en cas de problème. C’est pour cette raison que la mise en place du backup est primordiale surtout dans un environnement de production.

Depuis la sortie de l’appliance vCenter 6.7, il est désormais possible de faire un backup du vCenter de façon simple,  automatisée et surtout planifiée.

Dans la suite de cet article, nous allons voir comment configurer et planifier la sauvegarde du vCenter sur un Synology.

Le vCenter est compatible avec la sauvegarde vers un dossier en FTP, FTPS, SCP, HTTP et HTTPS, dans l’article je vais utiliser le protocole FTP.

Prérequis

• vCenter 6.7 (l’appliance)
• un Synology (ou un serveur FTP)
• Activation du FTP sur Synology (image ci-dessous)

1- Création d’un dossier backup sur Synology

Dans l’assistant de création d’un dossier partagé, donnez un nom au nouveau dossier qui sera utilisé pour le backup, choisir le volume dans lequel le stocker ensuite cliquez sur Suivant.

Dans mon cas, je ne chiffre pas le dossier. Cliquez sur Suivant Cliquez sur Suivant Cliquez sur Appliquer pour finir

2- Création d’un utilisateur backup sur Synology

Dans l’assistant de création d’un utilisateur, donnez un nom à votre utilisateur ainsi qu’un mot de passe. Cliquez ensuite sur Suivant.

Laissez le groupe par défaut et cliquer sur Suivant Cocher la case Lecture/Écriture sur le dossier créer précédemment “vmwarebackup“, ensuite cliquer sur Suivant Laissez en quota illimité et cliquez sur Suivant Autorisez uniquement le FTP pour l’utilisateur et refusez toutes les autres applications. Cliquez sur Suivant Laissez les limites par défaut. Cliquez sur Suivant. Cliquez sur Appliquer pour finir.

3- Configuration de la sauvegarde et la planification sur le vCenter

Il est nécessaire de se connecter à l’interface de configuration de l’appliance à l’adresse https://ip-ou-fqdn-du-vcenter:5480 Mettez le compte root avec son mot de passe et cliquez sur CONNEXION.

Une fois connecté, il est nécessaire d’aller dans la partie Sauvegarde en bas à droite.

Cliquez sur le bouton “CONFIGURER” pour lancer l’assistant de configuration.

Complétez comme dans l’image ci-dessous, avec l’emplacement de la sauvegarde, le nom d’utilisateur et le mot de passe défini précédemment. Choisir la planification et la durée de conservation qui vous convient le plus. Cliquez ensuite sur CREER pour finir.

On remarque que notre tache de sauvegarde et de planification a été activée. Pour pouvoir lancer immédiatement un backup, cliquez sur “SAUVEGARDER MAINTENANT“.

Cochez la case “Utiliser l’emplacement de sauvegarde…..” pour réutiliser les informations qui se trouve dans la tache de configuration et de planification créer précédemment. Renseignez le mot de passe de l’utilisateur ftp, cliquez ensuite sur DÉMARRER.

La tache de backup se lance. Après quelques minutes, la tache se termine. Allez dans le dossier qui contient les backups pour trouver les fichiers de sauvegarde créer par l’assistant.

Troubleshooting

En cas de problème de ce type lors du premier test de backup, il est nécessaire de démarrer le ou les services mentionnés par l’erreur.

Pour cela allez dans le vCenter au niveau de Administration > Déploiement > Configuration système > Noeuds > VotrevCenter > Objets associés 

L’article VMware vCenter 6.7 – Configuration et planification du backup sur Synology 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

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

Dans cet article nous allons voir comment réaliser une migration de VM à chaud (Allumées) ou à froid (Éteintes) entre un vCenter en version 6 vers un vCenter en version 6.5/6.7.

La migration peut être réalisée de deux manières différentes:

• A l’aide du vSphere Web Client.
• Utiliser un utilitaire tiers.

La migration avec le vSphere Web Client impose quelques contraintes, comme par exemple la nécessité d’avoir le vCenter source et le vCenter de destination liés au même PSC et partagent le même domaine vCenter Single Sign-On. Ceci est nécessaire pour qu’ils puissent se voir et s’authentifier mutuellement.

La deuxième solution et c’est celle qu’on va voir ensemble aujourd’hui est l’utilisation d’un utilitaire tiers qui se nomme “Cross vCenter Workload Migration Utility” qu’on retrouve dans le Flings Lab de VMware. Cet utilitaire a été développé par deux employés de chez VMware qui sont Vishal Gupta et William Lam.

L’utilitaire “Cross vCenter Workload Migration Utility” apporte la simplicité. Il n’est pas nécessaire d’avoir les deux vCenter sur le même domaine vCenter SSO, de plus l’interface est user friendly.

Fonctionnement

Le changement de la ressource de calcul se fait à l’aide de vMotion, dans le cas ou le datastore source et de destination n’est pas partagé entre les deux hosts ESXi alors du Storage vMotion est aussi utilisé.

Prérequis

• vCenter source en version 6 U3 minimum.
• vCenter destination en version 6 U3 minimum.
• Consulter la KB VMware pour la liste complète des versions supportées.
• Avoir téléchargé Cross vCenter Workload Migration Utility
• Avoir Java Runtime Environment 1.8-10 installé.
• L’utilitaire est compatible multiplateforme (Windows, Linux et Mac OS X).
• Avoir le trafic vMotion activé sur l’interface VMKernel (vmk) .

LAB Source (v6)

LAB Destination (v6.5)

1 – Lancement de “Cross vCenter Workload Migration Utility”

Le lancement de l’utilitaire est très simple, il suffit juste de lancer le fichier jar depuis une fenêtre Cmd/Terminal.

Cd C:UsersMoussa.CHELGHAMDesktopMoussaVMwarexvm-2.2
java -jar xvm-2.2.jar

2 – Enregistrement des vCenter

Remplir les champs avec les informations du premier vCenter, dans le cadre de ce LAB cocher la case “Skip certificate verification” pour ne pas vérifier le certificat du vCenter. Cliquez ensuite sur Submit pour enregistrer.

Nous avons maintenant nos deux vCenter (Source et destination) enregistrés. Il est important de noter que l’utilitaire enregistre les informations uniquement en RAM, en cas de fermeture ou de relance de ce dernier, il faut réenregistrer de nouveau les vCenter.

3 – Lancement de la migration Cross vCenter

Sélectionnez le type d’opération (Relocate pour migration) ou Clone. dans notre cas c’est une migration. Mettre le vCenter source et le vCenter destination, ne pas oublier de sélectionner les VM à migrer avec l’ESXi et datastore de destination et enfin remapper le port groupe source vers celui de destination pour la partie réseau. Cliquez sur Submit pour valider.

4 – Résultats

L’article Migration VM à chaud/froid Cross vCenter [6 vers 6.5/6.7] est apparu en premier sur MCHELGHAM.