Remplacement certificats autosignés du vCenter

Je vous propose ici un petit mode opératoire vous aidant à remplacer les certificats autosignés par défaut lors de l'installation du VMware vCenter par ceux issus de votre autorité de certification.

=> Faire un snapshot à froid du vCenter ( se connecter sur l'ESXi qui héberge la VM vCenter pour cela)

1- Demandez le fichier PFX au service compétent, en fournissant les éléments suivants :

Le FQDN du vCenter
Email (celle d'un compte de service)
IP du vCenter

2- Installer OpenSSL

Disponible ici : https://slproweb.com/products/Win32OpenSSL.html

3- Extraire la clé

Dans un CMD, exécuter la commande suivante :

C:\Program Files\OpenSSL-Win64\bin>openssl pkcs12 -in blablabla.pfx -out c:\temp\key.txt -nocerts -nodes

Renseigner le mot de passe fourni avec le PFX

4- Extraire les chaines de cert

Dans un CMD, exécuter la commande suivante :

C:\Program Files\OpenSSL-Win64\bin>openssl pkcs12 -in blablabla .pfx -out c:\temp\cert.txt -nokeys

• Renseigner le mot de passe fourni avec le PFX

5- Modification des fichiers

• Fichier key.txt

Aller dans c:\temp (ou là ou vous avez sauvegardé le fichier de l'étape 3)

Editer le fichier key.txt et supprimer ce qui est en jaune 

Enregistrer

• Fichier cert.txt

Faire une copie du fichier cert.txt et le nommer ca.txt

Editer le fichier cert.txt
Supprimer tout ce qui est en jaune


Supprimer également tout ce qui est sous le premier “-----END CERTIFICATE-----”

Enregistrez

• Fichier ca.txt

Editer le fichier ca.txt

Supprimer tout le début jusqu’au début du second “-----BEGIN CERTIFICATE-----”

Supprimer également la partie jaune entre les blocs :

Enregistrez

6- Copie des fichiers créés au point 5 sur le vCenter

En utilisant WinSCP, copier sur /tmp les fichiers :

• ca.txt

• cert.txt 

• key.txt

7- Mise à jour du certificat

• Se connecter avec putty sur le vcenter

• Executer :  /usr/lib/vmware-vmca/bin/certificate-manager

• Selectionner 1

 => Appuyer sur Entrée

=> mot de passe du compte administrator@vsphere.local

=> 2

 => y

En vous reconnectant sur l'interface web de votre vCenter, vous pouvez constater que votre certificat s'est bien mis à jour

Si tout est OK, n'oubliez pas de supprimer le snapshot pris au début ;-)

Read More

[PowerCLI] Cross vCenter vMotion

Je vous propose ici une évolution d'un script qui permet de lancer un vMotion sur une VM d'un vCenter à un autre.

Les pré requis sont :
- Que le stockage soit partagé entre les 2 environnements.
- Avoir un compte unique avec des droits sur les 2 vCenters
- Remplir le fichier "List_VM.csv" ainsi : "Name;Cluster;Datastore;DstPortGroup1;DstPortGroup2" 

Le script sais donc gérer les VMs qui ont plusieurs cartes réseaux, et assurer la "reconnexion" de chacune des carte au bon port group à destination.

En vous connectant sur les 2 vcenters, vous pourrez observer les VMs disparaître du premier, et s'inventorier sur le second.

Script disponible ici : https://github.com/GuillaumeDamien/crossvcentervmotion

Have fun !

Read More

[PowerCLI] Rapport Veeam

Bonjour à tous,

Aujourd’hui je souhaite partager avec vous une manière d’envoyer automatiquement par mail des rapports très synthétiques de vos sauvegardes Veeam. Ce mail contiendra uniquement la liste des VMs non sauvegardées depuis X jours.

Bien sûr Veeam propose déjà d’envoyer des mails avec le résultat de chaque job. Mais vous recevrez un mail par job. Donc si vous avez une grosse infra, avec plusieurs dizaines de jobs Veeam, vous risquez de littéralement vous faire spammer et ne plus prêter attention à ces mails. De plus, rien ne garantit que certaines VMs ne soient contenues dans aucun job, et donc ne soient jamais sauvegardées. Pour ce 2^e point, il existe "Veeam One", mais encore faut-il acheter le produit.

La méthode que je propose s’appuie sur les attributs personnalisés des VMs. Comme vous le savez peut-être, Veeam est capable de mettre à jour ces attributs en cas de sauvegarde réussie d’une VM (et uniquement en cas de sauvegarde réussie). Donc si une VM n'a pas été sauvegardée depuis plus d'une semaine, son attribut personnalisé datera de plus d'une semaine. Pour configurer cela, il suffit de cocher la case « Set successful backup details to this VM attribute », et d’indiquer le nom de l’attribut personnalisé comme ceci :

Lorsque vos VMs seront correctement sauvegardées, leur attribut sera mis à jour avec la date de la dernière sauvegarde réussie :

Dans le champ « Valeur » vous pourrez trouver le nom du Job ainsi que la date et l’heure de la dernière bonne sauvegarde. L’idée est donc de créer un script afin de  :

--> Lister toutes les VMs du vCenter
--> Récupérer l’attribut personnalisé de chacune d’entre elles
--> Parser le champ « valeur » afin de récupérer la date de dernière bonne sauvegarde
--> Créer un tableau avec toutes les VMs dont la dernière sauvegarde date de plus de X jours (3 jours dans mon cas), ou dont le champ est vide (ce qui signifie qu’elles n’ont jamais été sauvegardées).
--> Envoyer ce tableau par mail

Dans mon cas, j’exécute ce script tous les matins du lundi au vendredi. Vu que la sauvegarde Full se lance le vendredi soir et tourne tout le weekend, il peut se passer 3 jours entre le lancement du script du lundi matin et la dernière sauvegarde du vendredi soir. C’est pour cette raison que, dans mon cas, j’ai configuré le script pour qu’il ne liste que les VMs n’ayant pas été sauvegardées depuis plus de 3 jours. A vous d'adapter selon votre besoin.

Vous pourrez trouver mon script ici:  https://github.com/charivel/VeeamReport

Enjoy  😊

Read More

[Proxy Veeam] Design Réseau

Bonjour à tous,

Je voulais partager avec vous un petit retour d’expérience concernant l’architecture réseau des proxies Veeam. Chez mon client, nous avons plusieurs clusters VMware 6.5. Chaque cluster possède des VLANs différents pour ses VMs, mais aussi pour le réseau de management des ESXi. Donc le réseau de management d’un ESXi de DEV n’est pas le même que celui d’un ESXi de PROD.

Afin de répartir la charge, nous avons créé un proxy virtuel par cluster. Chaque proxy virtuel est positionné au plus proche des ESXi, c’est-à-dire dans le même VLAN de management des ESXi du cluster qui l’héberge. Afin de faire simple, nous avons créé un job de sauvegarde par cluster. Voici un schéma simplifié afin d’illustrer la situation :

Malheureusement, nous avions beau avoir plusieurs VMs proxy déployées, nous avions souvent des jobs en attente durant plusieurs heures fiasant dépasser la fenêtre de sauvegarde. Le message était le suivant :

En regardant de plus près, plusieurs de nos VMs proxy n’étaient pas utilisées. Ceci est dû au fait que Veeam cherche à utiliser le proxy optimal en priorité. Et pour lui, le proxy optimal c’est celui qui est dans le même réseau que les ESXi hébergeant les VMs à sauvegarder. Pour résumer, avec cette architecture, si je lance la sauvegarde de plusieurs clusters en même temps, je vais utiliser plusieurs proxies donc tout va bien. Mais si je ne sauvegarde qu’un seul cluster, ou si un cluster est plus gros et donc se termine après les autres, je n’utiliserai qu’un seul proxy, donc les perfs vont s’écrouler.

Afin de vérifier cette idée, pour chaque cluster, j’ai autorisé l’utilisation de tous les proxies sauf celui hébergé sur le cluster en question. Et là, pour chaque Backup Job, j’obtiens le message d’avertissement suivant :

Ce qui est normal puisqu'on vient d'exclure le seul proxy se trouvant dans le même sous-réseau. Attention, si vous avez un parefeu entre vos VLANs, cela peut effectivement impacter les performances et le temps de vos sauvegardes. Mais comme par magie, tous les autres proxies autorisés pour ce job sont utilisés, et dans mon cas les performances sont nettement améliorées ! Malheureusement, chaque Job n’est autorisé qu’à utiliser N-1 proxies.

Donc si on veut :

-         Garder la configuration Veeam la plus simple possible

-         Eviter d’aller "bidouiller" chaque backup job pour exclure un proxy (et on risque d'oublier de le faire sur les futurs Jobs)

-         Et surtout que chaque job puisse utiliser la totalité des proxies et non N-1

Je préconiserais :

-         Si le management des ESXi sont tous dans le même VLAN, alors déployer les VMs proxy dans ce VLAN

-         Sinon, créer un VLAN spécifique pour vos VMs proxy qui n’a rien à voir avec les réseaux de management de vos ESXi.

Maintenant que ce problème est réglé, je suis tombé sur une 2e limitation qui se cachait derrière :

Par défaut, Veeam limite la sauvegarde de 4 VMs en simultannées par datastore, afin que les snapshots ne saturent pas le datastore en espace libre. Si vous avez suffisamment de place sur vos datastores, vous pouvez augmenter cette limite à 6 voir 8 snapshots simultannées. Ce sujet est déjà traité par Bilel et Igor, je vous laisse donc le soin de consulter leur article :

http://vinception.fr/veeam-resource-not-ready-active-snapshots-limit-reached-for-datastore/

J’espère que ce retour d’expérience sur le Design réseau des proxies Veeam pourra vous aider 😊

Read More

[PowerCLI] Création d'un cahier de configuration VMware

Bonjour à tous,

Lors de mes différentes prestations VMware, j'ai souvent dû réaliser un cahier de configuration au format Excel. Le but de ce fichier est de centraliser tous les éléments de configuration nécessaires au redéploiement de tout ou partie de l'infrastructure (Adresses IP, MASK, GW, DNS, etc...).

Habituellement ce cahier de configuration est à renseigner par le client au début du projet, avant le déploiement de l'infrastructure. Mais il peut arriver que certains éléments soient modifiés au cours du temps. C'est pourquoi j'ai créé un script Powershell. Ce script se connecte au serveur vCenter et créé un fichier XLSX avec toutes les informations nécessaires.

Contrairement à ce que fait Rvtools, je relève uniquement les points de configuration et non d'audit. De même, je ne relève rien concernant les VMs, car je ne souhaite que les points de configuration de l'infrastructure VMware. Ce script organise les résultats par onglets dans le fichier Excel généré (vCenter, ESXi, ...)

L'avantage c'est que vous pouvez lancer ce script manuellement, ou en tâche planifiée afin de toujours avoir un cahier de configuration à jour sous le coude :)

Vous pourrez retrouver ce script sur mon Github:
https://github.com/charivel/Cahier-Config.git

J'espère que cela pourra vous servir et vous faire gagner du temps !
Si vous avez des remarques ou des idées d'amélioration, n'hésitez pas, je suis preneur :)

Read More

REX Veeam

Voici un petit retour d’expérience sur un problème que j’ai rencontré avec Veeam Backup & Replication 9.5 U4. Je voulais partager ce REX avec vous car il m’a donné quelques cheveux gris 😊

Chez mon client, nous sommes actuellement en plein projet de migration depuis un logiciel de sauvegarde lambda vers Veeam Backup. Au fur et à mesure, nous désactivons la sauvegarde d’un cluster VMware sur l’ancien logiciel de sauvegarde, pour l’activer côté Veeam. Jusque-là tout va bien.

Puis un matin, je vérifie les sauvegardes de la veille et je me rends compte que certains ont fonctionné, mais la plupart sont restés à 0% d’avancement à l’étape suivante : « Pending : Polling Scale-Out Backup Repository extents »

Donc pas de message d’erreur car les jobs n’ont pas échoués, mais cela fait plus de 12h qu’ils sont en attente, et clairement ils n’avanceront plus… 1er réflexe, je me dis que les serveurs proxy sont sous-l’eau ou qu’ils ont un problème. Je me connecte dessus pour vérifier, sans rien remarquer d’anormal. Dans le doute je décide de les redémarre un à un ; mais cela ne change pas le problème. Finalement je redémarre le serveur Veeam lui-même, et les 1ers jobs semblent repartir.

Le lendemain matin, je vérifie les sauvegardes, et de nouveau les jobs sont en attente « Pending : Polling Scale-Out Backup Repository extents » !

Donc je sens tout de suite que ce problème est plus profond, qu’il va se reproduire et va me faire perdre pas mal de temps, donc j’ouvre tout de suite un ticket au support Veeam. La personne du support vérifie tous les logs, et me dit que les serveurs proxy doivent être saturés ou que la connexion avec les target repository doit être HS. On vérifie tout ça, mais ce n’est pas ça le problème. On convient alors d’une prise de main en webex. De là, il vérifie toute la configuration de chaque Repository, Scale-Out Repository, ainsi que chaque serveur proxy, Gateway server, et Mount server… Tout semble correct et on commence à s’arracher les cheveux !

Finalement, après avoir épluché pas mal de logs, on a fini par trouver qu’au fur et à mesure de notre projet de migration, et qu’on ajoutait de nouveaux jobs Veeam, la base de données ainsi que les logs avaient bien grossi et qu’ils saturaient l’espace disque sur la partition du cluster SQL. Donc sans pouvoir écrire de nouveaux journaux de transactions, Veeam restait en attente, CQFD !

Au final, rien de très sorcier, mais les messages d’erreur étant inexistants, difficile de pointer du doigt le problème.

Moralité : bien designer la partie SQL, monitorer l’espace disque, et ceci surtout quand elle est mutualisée avec d’autres applis.

Read More

vCenter HA - Mode avancé

INTRODUCTON
Nous l'avons vu dans mon précédent article sur VCHA, il existe 2 modes de déploiement:
- basique
- avancé

Afin de compléter mon précédent article, voici un cas d'usage nous obligeant à opter pour le déploiement en mode avancé de VCHA.

CONTEXTE
Chez mon client, nous avons voulu déployer VCHA sur 3 sites distincts:
- 2 sites de production en Datacenter
- et un site tiers pour le noeud witness.

La problématique, c'est que certains VLANs peuvent être étendus entre les 2 sites de production mais pas avec le 3e site.

Nous avons donc choisi l'architecture suivante:
- l'adresse IP de management du vCenter sera sur un VLAN étendu entre les 2 sites de production
- les adresses IP pour le service "Heartbeat/réplication" de VCHA seront sur des sous-réseaux différents.

A noter qu'il est également possible d'avoir des adresses IP de management sur des sous-réseaux différents. Dans ce cas, il faudra mettre à jour manuellement l'entrée DNS au moment de la bascule .
Dans tous les cas, lorsque les noeuds VCHA sont répartis sur des sites différents, veuillez à bien respecter les 10ms de latence maximum entre les sites.


PROCEDURE
Dans cet article, nous partons du principe que vous disposez déjà d’un serveur VCSA fonctionnel.

Voici les grandes étapes afin de mettre en place VCHA. Ces étapes doivent être suivies rigoureusement dans le bon ordre:

1. Ajout d'une 2e NIC au serveur VCSA
2. Activer SSH sur le serveur VCSA
3. Lancer le Wizard de déploiement VCHA en mode avancé
4. Stopper le Wizard à une étape précise
5. Faire un clone pour le noeud passif
6. Faire un clone pour le noeud témoin
7. Configuration réseau & Ajout des routes
8. Reprendre et terminer le Wizard

Ajout d'une 2e NIC au serveur VCSA

Pour commencer, il suffit d'éditer les paramètres de la VM vCenter pour ajouter une NIC et la positionner sur le bon VLAN.

Ensuite, il faut se connecter sur l'interface VAMI (https://nom_du_vcenter:5480) afin de configurer l'adresse IP de cette 2e NIC:

Sélectionner la "nic1" et modifier les paramètres:

Spécifier l'adresse IP de réplication et le masque de sous-réseau:

Activer SSH sur le serveur VCSA

Profitez d'être connecté sur l'interface VAMI pour activer le SSH sur le serveur vCenter VCSA:

Lancer le Wizard de déploiement VCHA en mode avancé

Se connecter sur le vCenter avec l’interface Web en Flash (cette fonctionnalité n'est pas encore disponible en version HTML5 sur vSphere 6.5), puis sélectionner la racine et aller dans l’onglet « Configurer » puis « vCenter HA ». Cliquer sur le bouton « Configurer » en haut à droite :

Choisissez l’option « Avancé » :

Renseignez les adresses IP de réplication des nœuds passif et témoin mais ne pas cliquer sur "Terminer":

Nous allons laisser le Wizard en pause le temps de réaliser les clones.

Faire un clone pour le noeud passif

Utiliser le client Web en Flash encore une fois (car la création de fichier de customisation n'est pas présente en HTML5) pour lancer un clone de votre serveur VCSA :

Choisir le cluster qui hébergera le nœud passif, dans l’idéal il s’agit d’un cluster différent voir d’un site différent du nœud actif :

Choisir un Datastore avec suffisamment d’espace libre :

Choisir l’option « Personnaliser le système d’exploitation » :

Appuyer sur le bouton avec la croix verte pour créer un nouveau profil :

Donner un nom au fichier de personnalisation :

Renseigner le nom DNS du noeud passif ainsi que le nom de domaine :

Choisir le fuseau horaire :

Sélectionner la « NIC 1 » cliquer sur le bouton en forme de crayon :

Indiquer les paramètres de l’adresse IP de management :

Faire de même pour la « NIC 2 » et indiquer l’adresse IP de réplication du nœud passif. Ne pas indiquer de passerelle 

Vérifier les informations et cliquer sur « suivant » :

Renseigner les serveurs DNS et le champ de recherche DNS :

Cliquer sur « Terminer »:

La création du fichier de personnalisation est terminée, vous pouvez maintenant le sélectionner et cliquer sur « Suivant » :

Vérifier une dernière fois les informations et cliquer sur « Suivant »

Enfin cliquer sur « Terminer » pour lancer la création du clone :

Le 1^er clone est maintenant créé et éteint.

Ensuite, nous pouvons passer à la création du clone pour le 3e noeud.

Faire un clone pour le noeud témoin
De la même manière, veuillez créer un clone pour le 3e noeud.
La différence étant cette fois de créer un fichier de customisation pour le "Noeud Témoin".

Dans ce fichier de personnalisation, veuillez laisser la NIC1 en DHCP et configurer uniquement la NIC2 pour le heartbeat avec les noeuds actif et passif.

Les 2 clones sont maintenant créés et ils sont restés éteints.

Si tous les sites ne sont pas gérés au sein du même vCenter, il peut être nécessaire de faire un « backup/restore » avec Veeam par exemple afin de copier les clones sur le bon site.

Editer ensuite les paramètres des 2 clones afin de connecter les cartes réseaux sur les bons VLANs.

Enfin vous pouvez baisser la quantité de CPU et RAM du nœud témoin à :

         - 1 vCPU
         - 512Mo de RAM (dans notre cas, nous avons choisi de garder 1GB de RAM)

*cf : https://kb.vmware.com/s/article/2148442

Puis allumer les clones.

Configuration réseau & Ajout des routes

Afin que les adresses IP de réplication VCHA de chaque nœud puissent communiquer entre elles, il est nécessaire de rajouter des routes sur chaque nœud.

Ouvrir une console sur le nœud principal et se connecter en tant que « root » :

Taper la commande « shell » pour activer le CLI :

Configurer l’adresse IP de réplication sur le nœud passif avec la commande suivante :

/opt/vmware/share/vami/vami_config_net

Taper « 7 » pour vérifier/configurer l’adresse IP d’eth1 :

Puis taper la commande suivante afin de rajouter une route :

vi /etc/systemd/network/10-eth1.network

Ajouter les routes afin que le noeud1 puisse communiquer avec les nœuds 2 et 3 sur le réseau VCHA :

Avec l’éditeur de texte « VI », il faut taper la lettre « i » pour insérer des caractères, puis « Echap » et « :wq » pour enregistrer et quitter.

Enfin redémarrer le service réseau pour que le changement soit pris en compte :

systemctl restart systemd-networkd

Faire de même sur le noeud passif afin qu’il puisse communiquer avec les nœuds 1 et 3 :

Enfin redémarrer le service réseau pour que le changement soit pris en compte :

systemctl restart systemd-networkd

Enfin, se connecter sur le nœud 3 (Témoin) afin de configurer le réseau de la carte eth1, puis modifier la passerelle par défaut pour eth1 avec la commande suivante :

/opt/vmware/share/vami/vami_config_net

Il n’y a pas de route à ajouter sur le nœud 3, puisqu’on modifie directement la passerelle par défaut.

Reprendre et terminer le Wizard

Une fois que :

       - les clones sont créés
       - les clones sont hébergés sur les bons sites/clusters
       - les routes ont été ajoutées sur les nœuds 1 et 2

Vous pouvez retourner sur le wizard et cliquer sur « Terminer » :

Une fois la tâche de configuration terminée, une tâche de synchronisation sera lancée automatiquement entre les nœuds actif et passif. Une fois terminée, vous serez alors dans l’état suivant :

Problèmes courants

Si la tâche de configuration de VCHA échoue:
=> assurez-vous que le nœud principal est capable de résoudre son propre nom cours (sans le suffixe DNS) avec la commande "nslookup".

=> Vérifier également que chaque nœud est capable de communiquer avec les 2 autres sur le réseau VCHA.

=> De plus, si vous n’avez pas respecté l’ordre de création des clones au bon moment du wizard VCHA, ceux-ci ne pourront pas se connecter entre-eux en SSH car la clé d’encryption SSL ne sera pas bonne. Il faudra donc recommencer depuis le début et respecter l’ordre de création rigoureusement.

Enfin, vous pourrez trouver des fichiers de logs très intéressant à l’endroit suivant :

REFERENCES
https://kb.vmware.com/s/article/2148442

Read More