Superviser la consommation des serveurs VMware ESX(i) avec Nagios

Dans un article précédent, je vous présentais une solution pour superviser un serveur VMware ESX(i). Elle reposait sur l’utilisation du plugin Nagios check_esx3.pl de la société OP5.
A l’aide du client vSphere, il est possible d’obtenir la consommation d’un serveur VMware ESX(i) (test effectué avec un serveur Dell PowerEdge R710).

Cette donnée de performance ne pouvait pas être mesurer avec le plugin Nagios check_esx3.pl. J’ai donc décidé d’implémenter cette fonctionnalité.

– Placez-vous dans le répertoire suivant : cd /usr/local/src/
– Téléchargez le plugin Nagios : wget "http://git.op5.org/git/?p=nagios/op5plugins.git;a=blob_plain;f=check_esx3.pl" -O check_esx3.pl
– Téléchargez le patch pour prendre en compte la consommation des serveurs VMWare ESX(i) : wget http://www.be-root.com/downloads/nagios/check_esx3/0001-check_esx3.pl-Added-power-consumption.patch
– Appliquez le patch sur le plugin check_esx3.pl : patch < 0001-check_esx3.pl-Added-power-consumption.patch

Ce patch a été récemment soumis à la liste de diffusion des utilisateurs OP5 pour intégrer le plugin check_esx3.pl. Je n’ai pas encore eu de réponse pour le moment.

– Copiez ce script dans le répertoire contenant les plugins Nagios : cp check_esx3.pl /usr/local/nagios/libexec/
– Rendez le script exécutable : chmod +x /usr/local/nagios/libexec/check_esx3.pl
– Modifiez le propriétaire pour ce script : chown nagios:nagios /usr/local/nagios/libexec/check_esx3.pl

– Vérifiez la consommation d’un serveur VMware ESX(i) : /usr/local/nagios/libexec/check_esx3.pl -H xxx.xxx.xxx.xxx -u supervision -p MotDePasse -l power -w 500 -c 600

CHECK_ESX3.PL OK - power=216.22 Watts | power=216.22W;500;600

– Ajoutez la définition de l’objet command : vi /etc/nagios/objects/commands.cfg

define command {
command_name check_esx_power
command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l power -w $ARG1$ -c $ARG2$
}

– Ajoutez la définition de l’objet host pour le serveur : vi /etc/nagios/objects/hosts.cfg

define host {
host_name server01
use generic_host
alias VMware ESXi
address xxx.xxx.xxx.xxx
contact_groups +admin
}

– Ajoutez la définition de l’objet service pour le serveur : vi /etc/nagios/objects/services.cfg

define service {
host_name server01
use generic_service
service_description Puissance
check_command check_esx_power!917!966
contact_groups +admin
}

– Rechargez la configuration de Nagios : service nagios reload

La configuration de Nagios dépend bien entendu de la structure que vous avez adopté.

Supervision de VMware ESX(i) avec Nagios

Pour superviser le serveur VMware ESX(i), nous allons utiliser le plugin Nagios check_esx3.pl de la société OP5. En pré-requis à son utilisation, il est nécessaire d’installer VMware vSphere SDK for PERL et le module PERL Nagios::Plugin sur le serveur de supervision.

Apercu de la supervision d'un serveur VMWare ESX(i)
Nous installerons VMware vSphere SDK for PERL dans le répertoire /opt/vmware-vsphere-perl-sdk/.

– Depuis le serveur de supervision, créez le répertoire suivant : mkdir /opt/vmware-vsphere-perl-sdk/

Depuis le site de VMware vous devez télécharger VMware vSphere SDK for Perl. Le téléchargement de ce composant nécessite un compte VMware.

– Installez la bibliothèque de développement d’OpenSSL : yum install openssl-devel
– Placez-vous dans le répertoire suivant : cd /usr/local/src/
– Décompressez l’archive : tar -xzvf VMware-vSphere-Perl-SDK-4.1.0-254719.x86_64.tar.gz
– Placez-vous dans le répertoire suivant : cd vmware-vsphere-cli-distrib
– Lancez l’installation de VMware vSphere SDK for Perl : ./vmware-install.pl

Avant de procéder à l’installation, vous devez  accepter la licence d’utilisation.

Indiquez l’emplacement des fichiers exécutables (/opt/vmware-vsphere-perl-sdk/bin/).

Installation de VMware

Pour désinstaller VMware vSphere SDK for Perl, il vous suffira de lancer la commande suivante : /opt/vmware-vsphere-perl-sdk/bin/vmware-uninstall-vSphere-CLI.pl.

Nous allons installer le module PERL Nagios::Plugin.

perl -MCPAN -e ‘shell’
cpan > install Nagios::Plugin
cpan > quit

Ensuite, nous allons récupérer le plugin Nagios check_esx3.pl depuis le site d’OP5.

– Placez-vous dans le répertoire suivant : cd /usr/local/src/
– Téléchargez le plugin Nagios : wget "http://git.op5.org/git/?p=nagios/op5plugins.git;a=blob_plain;f=check_esx3.pl" -O check_esx3.pl
– Copiez ce script dans le répertoire contenant les plugins Nagios : cp check_esx3.pl /usr/local/nagios/libexec/
– Rendez le script exécutable : chmod +x /usr/local/nagios/libexec/check_esx3.pl
– Modifiez le propriétaire pour ce script : chown nagios:nagios /usr/local/nagios/libexec/check_esx3.pl

Le plugin Nagios check_esx3.pl récupère les informations d’un serveur VMware ESX(i) en s’y connectant à l’aide d’un compte utilisateur. Nous allons créer un compte utilisateur supervision possédant les droits de lecture.

Connectez-vous au serveur VMware ESX(i) avec le client VMware vSphere.

Dans l’onglet Local Users & Groups, cliquez sur l’option Add du menu surgissant pour créer un nouvel utilisateur supervision avec un mot de passe associé.

Dans l’onglet Permissions, cliquez sur l’option Add Permission…. Dans la partie Users and Groups, cliquez sur le bouton Add pour ajouter l’utilisation supervision. Dans la partie Assigned Role, sélectionnez le rôle Read-only pour cet utilisateur.

L’installation est terminée. Voici quelques exemple d’utilisation du plugin Nagios check_esx3.pl.

– Placez-vous dans le répertoire suivant : cd /usr/local/nagios/libexec/
– Vérifiez l’utilisation du CPU de l’hyperviseur en pourcentage : ./check_esx3.pl -H xxx.xxx.xxx.xxx -u supervision -p MotDePasse -l cpu -s usage -w 80 -c 90

CHECK_ESX3.PL OK - cpu usage=1.24 % | cpu_usage=1.24%;80;90

– Vérifiez l’utilisation de la mémoire vive de l’hyperviseur  en Mo : ./check_esx3.pl -H xxx.xxx.xxx.xxx -u supervision -p MotDePasse -l mem -s usagemb -w 14336 -c 16384

CHECK_ESX3.PL OK - mem usage=6022.40 MB | mem_usagemb=6022.40MB;14336;16384

– Vérifiez l’état de l’hyperviseur : ./check_esx3.pl -H xxx.xxx.xxx.xxx -u supervision -p MotDePasse -l runtime -s status

CHECK_ESX3.PL OK - overall status=green

– Vérifiez que toutes les cartes réseaux de l’hyperviseur sont connectées : ./check_esx3.pl -H xxx.xxx.xxx.xxx  -u supervision -p MotDePasse -l net -s nic

CHECK_ESX3.PL OK - All 8 NICs are connected | OK_NICs=8;; Bad_NICs=0;;

Pour obtenir de l’aide sur ce plugin Nagios, il vous suffit de lancer la commande suivante : ./check_esx3.pl -h

Cette partie dépend de votre arborescence de configuration et de votre installation de Nagios. Nous allons modifier la configuration de Nagios pour superviser un serveur VMware ESX(i).

– Ajoutez deux nouvelles variables : vi /etc/nagios/resource.cfg

$USER2$=supervision
$USER3$=MotDePasse

Les variables USER2 et USER3 correspondent aux identifiants de l’utilisateur possédant les droits de lecture sur le serveur VMware ESX(i).

– Ajoutez les définitions des objets command : vi /etc/nagios/objects/commands.cfg

define command {
  command_name check_esx_cpu
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l cpu -s usage -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_memory
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l mem -s usagemb -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_swap
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l mem -s swap -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_network
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l net -s usage -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_disk_io_read
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l io -s read -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_disk_io_write
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l io -s write -w $ARG1$ -c $ARG2$
}

define command {
  command_name check_esx_nic
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l net -s nic
}

define command {
  command_name check_esx_service
  command_line $USER1$/check_esx3.pl -H $HOSTADDRESS$ -u $USER2$ -p $USER3$ -l service -s $ARG1$
}

– Ajoutez la définition de l’objet host pour le serveur : vi /etc/nagios/objects/hosts.cfg

define host {
  host_name server01
  use generic_host
  alias VMware ESXi
  address xxx.xxx.xxx.xxx
  contact_groups +admin
}

– Ajoutez la définition des objets service pour le serveur : vi /etc/nagios/objects/services.cfg

define service {
  host_name server01
  use generic_service
  service_description CPU
  check_command check_esx_cpu!80!90
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Memoire
  check_command check_esx_memory!14336!16384
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Trafic_Reseau
  check_command check_esx_network!5120!102400
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Disque_IO_Lecture
  check_command check_esx_disk_io_read!50!90
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Disque_IO_Ecriture
  check_command check_esx_disk_io_write!50!90
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Interfaces_Reseaux
  check_command check_esx_nic
  contact_groups +admin
}

define service {
  host_name server01
  use generic_service
  service_description Services
  check_command check_esx_service!DCUI,lbtd,ntpd,vmware-vpxa
  contact_groups +admin
}

– Rechargez la configuration de Nagios : service nagios reload

Votre serveur VMWare ESX(i) est maintenant supervisé depuis Nagios.

Supervision du CPU d'un serveur VMware ESX

Supervision de la mémoire vive d'un serveur VMware ESX

P2V : De Compaq Proliant ML370 vers Vmware Server

L’abréviation P2V signifie Physical To Virtual, c’est à dire que c’est le procédé qui permet de virtualiser un serveur physique.

Dans notre étude, nous allons virtualiser un serveur Compaq Proliant ML370 G2 équipé d’une carte Raid SmartArray 5i fonctionnant sous CentOS 4.7.

Cependant, cette méthode est utilisable pour tout type de matériel, moyennant quelques légères adaptations.

Pré-requis :

  • Un serveur VMware en état de fonctionnement (VMware 1.0.9 sous Linux dans notre cas)
  • Un disque dur USB d’une capacité suffisante pour contenir des fichiers images de l’ensemble des partitions du serveur physique
  • Un CD bootable de SystemRescueCD
  • Du temps 🙂

1 . Backup du serveur physique

Tout d’abord nous allons créer des fichiers images des partitions du serveur physique sur le disque dur USB.

Le serveur étant en fonctionnement, relever la hiérarchie des points de montage à l’aide d’un cat /etc/mtab

Nous faisons booter le serveur sur le CD SystemRescueCD.
Au prompt du bootloader du CD, il est possible de booter le noyau par défaut (appui sur la touche entrée) ou de taper altkern32 pour avoir accès à un noyau alternatif au cas où celui par défaut ne détecterait pas certains périphériques.

Après le choix du keymap (fr=16), nous nous retrouvons sous le shell de SystemRescueCD.Il est alors temps de connecter le disque dur USB

Grâce à la commande sfdisk -l, il est alors facile de repérer le disque dur USB sur le système (dans mon cas, c’est la seule partition en W95 Fat32).

Ici, le disque USB est en /dev/sda1 et les partitions de mon serveur sont /dev/c0d0p1, /dev/c0d0p2 (swap), /dev/c0d0p3, /dev/c0d0p5, /dev/c0d0p6, /dev/c0d0p7, /dev/c0d0p8.

Nous en profitions également pour relever la taille des partitions (#blocks)

Nous allons donc monter le disque usb :

mkdir /mnt/usbdisk
mount /dev/sda1 /mnt/usbdisk

Nous lançons ensuite l’utilitaire partimage.

Nous choisissons  la partition à sauvegarder (/dev/c0d0p1), le nom du fichier image (/mnt/usbdisk/c0d0p1) et nous validons en appuyant sur F5. Le nom des fichiers est volontairement le même que le nom de la partition afin de faciliter la restauration par la suite.

Dans l’écran suivant, nous laissons toutes les options par défaut et nous poursuivons en appuyant sur F5.

Après validation, le backup commence.

Il faut ensuite recommencer l’opération pour chaque partition présente sur le serveur (exceptée la swap).

2. Restauration sur la machine virtuelle

Nous sommes connecté à la console VMware Server, le disque dur USB étant connecté

Tout d’abord il faut créer la machine virtuelle en prêtant attention à ce que la taille du disque soit au moins très légèrement supérieure à la somme de la taille des partitions sauvegardées.

Ensuite dans les settings de la VM, il faut ajouter un controleur USB en cliquant sur le bouton ADD

usb

Il faut aussi mapper le lecteur CD sur l’image ISO de SystemRescue CD

Nous pouvons alors connecter le disque USB via le menu VM->Removables Devices->USB Devices une fois que la VM est démarrée.

Nous bootons sur le CD de la machine virtuelle. Nous arrivons alors au prompt de SystemRescueCD.

De nouveau, un sfdisk -l permet de repérer les périphériques de stockage.

Ici /dev/sdb1 est le disque USB externe et /dev/sda est le disque dur virtuel.

Grâce à l’utilitaire Fdisk, nous allons recréer des partitions /dev/sda1, /dev/sda2, /dev/sda3, /dev/sda5, /dev/sda6, /dev/sda7, /dev/sda8 de taille légèrement supérieure à celles que l’on a relevées pour /dev/c0d0p1, /dev/c0d0p2 (swap), /dev/c0d0p3, /dev/c0d0p5, /dev/c0d0p6, /dev/c0d0p7, /dev/c0d0p8.

Par exemple si /dev/c0d0p1 faisait 9Go, alors /dev/sda1 fera 9.1Go afin d’éviter d’avoir un message « partition too small » lors de la restauration du fait de la différence de géométrie des disques si l’on utilisait le même nombre exact de blocs.

Ne pas oublier le type de la partition de swap en 82 (Linux Swap).

Formater la partition de swap à l’aide de mkswap /dev/sda2

Nous allons donc monter le disque usb :

mkdir /mnt/usbdisk
mount /dev/sda1 /mnt/usbdisk

Nous lançons ensuite l’utilitaire partimage.

Choisir la partition à restaurer (/dev/sda1),  l’image à utiliser (/mnt/usbdisk/c0d0p1.000). Positionner l’Action à effectuer sur Restore partition from an image file et valider avec F5. Recommencer l’opération pour chaque partition à restaurer.

3. Opérations post-restauration

Une fois les partitions restaurées, toujours sur le CD SystemRescue CD, il convient de les monter afin de pouvoir chrooter dans l’environnement restauré.

Voici le schéma de points de montage utilisé dans le serveur original :

/dev/c0d0p1  ->  /boot
/dev/c0d0p3  ->  /
/dev/c0d0p5  ->  /var
/dev/c0d0p6 -> /usr
/dev/c0d0p7 -> /tmp
/dev/c0d0p8 -> /data

Nous allons donc les monter comme suit :

mkdir /mnt/guest
mount /dev/sda3 /mnt/guest
mount /dev/sda1 /mnt/guest/boot
mount /dev/sda5 /mnt/guest/var
mount /dev/sda6 /mnt/guest/usr
mount /dev/sda7 /mnt/guest/tmp
mount –bind  /dev /mnt/guest/dev

Cette dernière ligne nous permet d’avoir accès aux périphériques lorsque nous serons chrooté dans l’environnement et que nous devrons réinstaller le bootloader.

Nous chrootons dans l’environnement crée :

chroot /mnt/guest /bin/bash

Il suffit ensuite d’éditer le fichier /etc/fstab et de modifier les anciennes références des partitions vers les nouvelles partitions (ex: /dev/c0d0p1 (ou LABEL=/boot) devient /dev/sda1).

L’initrd présent est généré d’après le fichier /etc/modprobe.conf pour fonctionner avec le matériel du proliant ML380G2. Il faut donc le régénérer pour le matériel de la machine virtuelle.

Le fichier /etc/modprobe.conf contient :

alias eth0 tg3
alias scsi_hostadapter cciss

Il faut le modifier ainsi :

alias eth0 pcnet32
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 mptscsih

Un petit less /boot/grub/menu.lst permet de connaitre le noyau (mais surtout l’initrd) utilisé par défaut.

Dans notre cas, il s’agit de initrd-2.6.9-78.0.22.EL.img. Nous allons donc le sauvegarder et en générer un nouveau :

mv /boot/initrd-2.6.9-78.0.22.EL.img /boot/initrd-2.6.9-78.0.22.EL.img.old
mkinitrd /boot/initrd-2.6.9-78.0.22.EL.img 2.6.9-78.0.22.EL

Il nous reste donc à réinstaller le bootloader grub.

Tout d’abord, il faut modifier dans le fichier /boot/grub/menu.lst les références aux anciennes partitions (ex: root=LABEL=/ devient root=/dev/sda3).

Ensuite, exécutons sous l’utilitaire en ligne de commande grub :

root (hd0,0)setup (hd0)

Ceci a pour effet de réinstaller le bootloader.

Il suffit ensuite de sortir du chroot, de rebooter la VM en n’oubliant pas démapper l’ISO du lecteur CD et de déconnecter le disque externe et de booter sur le disque virtuel normalement.

Au premier boot, il se peut que kudzu détecte de nouveau périphériques et notamment la carte réseau. Il suffit alors
de lui remettre les paramètres IP du serveur physique.