Archive
ESXi : Configurer SNMP
Afin de monitorer les serveurs ESXi à l’aide de Nagios ou HP SIM, il faut configurer le service SNMP.
Voici les étapes:
Se connecter au serveur ESXi à monitorer via SSH ou console locale.
Modifier le fichier /etc/vmware/snmp.xml à l’aide de VI:
vi /etc/vmware/snmp.xml
Appuyer sur “i” pour passer en mode insertion.
Modifier le fichier comme ci-dessous :
<config><snmpSettings><enable>true</enable><communities>public</communities>
<targets>nom DNS du serveur@162/public</targets></snmpSettings></config>
true : permet d’activer le snmp
public : nom de la communauté
nom DNS du serveur@162/public : nom résolu du serveur devant recevoir les traps SNMP puis @ et le numéro de port et enfin / et le nom de la communauté
Fermer et sauvegarder le fichier :
Appuyer sur les touches “Echap”, “:”, “w”, “q”,”Entrée”.
Pour fermer sans sauvegarder :
Appuyer sur “Echap”, “:”, “q”, “!”,’Entrée”.
Redémarrer les services de gestion ESXi:
/sbin/services.sh restart
Redémarrage des services
Cette commande n’interrompt pas le fonctionnement des VM.
Pour tester l’activation du SNMP, il faut utiliser l’utilitaire SNMPWALK. Une version Windows est disponible à cette adresse: http://www.net-snmp.org/download.html
Une fois téléchargé et installé, lancer la commande suivante:
snmpwalk.exe -v 2c -c <nom de la communauté> <IP du serveur ESXi>
Exemple de résultat de l’utilitaire SNMPWALK
vSphere 4 : Les mécanismes d’optimisation de la mémoire
Lors du dimensionnement d’une infrastructure virtuelle, la quantité de mémoire par hôte est une élément essentiel. La quantité de VM pouvant fonctionner par hôte est un élément important à prendre en compte dans le calcul du ROI d’une infrastructure virtuelle. Plus on va utiliser la mémoire plus le ROI sera rapide.
Un des avantages de VMware face à ses concurrents est la gestion des mémoire. L’éditeur a développé plusieurs mécanismes permettant d’attribuer plus de mémoires aux VM que n’en dispose l’hôte. Ce procédé est nommé Memory overcommit (ou overcommitment).
Le lexique
Tout d’abord, voici un rappel du lexique :
Active Guest Memory : Mémoire récemment utilisée par le système. Cette mémoire ne peut pas être réduite par le ballooning.
Consumed Host Memory : Quantité maximale de mémoire consommée depuis le démarrage de la VM. Cette valeur prend en compte la surcharge liée à la virtualisation (overhead).
Les seuils
Les techniques de réductions de la consommation de la mémoire se déclenchent en fonction de certains seuils.
Les seuils sont définis par défaut avec les valeurs suivantes:
- High : plus 6% de mémoire libre
- Soft : 4% de la mémoire libre
- Hard : 2% de la mémoire libre
- Low : 1% de la mémoire libre
| Seuils | Techniques |
| High | Aucune |
| Soft | Ballooning |
| Hard | Swapping, Ballooning |
| Low | Swapping |
Les techniques
Le TPS (transparent page sharing) : L’hyperviseur déduplique les pages mémoires identiques (particulièrement efficace en VDI). Cette technique est utilisée en permanence.
ex: 5Go sur de mémoire économisée sur un serveur disposant de 64Go de RAM et n’hébergeant que des serveurs Windows 2003.
Le ballooning : VMware créé un processus dans l’OS à l’aide des VMware Tools. Ce processus a pour but de provoquer un swap de l’OS. Le système d’exploitation swappe en priorité la mémoire inutilisée, préservant ainsi l’Active Guest Memory. La quantité de Consumed Host Memory est réduite pour tendre vers l’Active Guest Memory (+ l’overhead). Cette méthode permet de conserver de bonnes performances.
ex: 2048Mo de mémoire économisée. 1750Mo de mémoire ciblée par le ballon => phase de “dégonflage”.
La compression (à partir de vSphere 4.1) : L’hyperviseur compresse la mémoire à la volée. Cette technique entraine une charge CPU supplémentaire. Cette technique est utilisée en permanence.
ex: 278Mo de mémoire économisée grâce à la compression.
Le swapping : Dans ce cas là, le swapping est réalisé non pas par l’OS invité mais par l’hyperviseur. Celui-ci écrit aléatoirement des pages mémoires dans un fichier de swap (créer au démarrage de la VM). Cette technique est la plus pénalisante car si une page mémoire doit être accédée à partir du swap, une opération de lecture sur les disques a lieu .
Mais il est possible de tirer parti de cette technique en utilisant des disques SSD pour stocker les fichiers de swaps. Cette architecture est particulièrement intéressante dans le cas d’une infrastructure VDI.
ex: 398Mo de mémoire swappée (493Mo ciblée).
Les outils de monitoring
esxtop : Utilitaire en mode console. Pour le lancer, se connecter en SSH sur l’hôte à surveiller.
Puis saisir esxtop. Puis taper m pour passer en vue memory.
vSphere Client : Via l’onglet performance
Conclusion
Il ne faut pas avoir peur du memory overcommit (“surutilisation” de la mémoire) car les mécanismes mise en place par l’hyperviseur permettent de conserver des performances correctes évitant ainsi un effondrement brutal des VM.
Ces techniques sont particulièrement intéressantes dans une infrastructure VDI (TPS trés performant dans le cadre de 100 postes identiques sous Windows 7 par exemple).
Concernant les applications critiques aux comportement aléatoires (périodes charges inconnues par exemple), l’overcommit ne dois être utilisé que temporairement.
Je n’ai pas abordé la mise en place de limites et de priorités concernant la gestion de la mémoire car l’expérience montre que le coût de gestion de ces critères est très important par rapport au retour attendu.
Ces mécanismes associés à la mise en place d’un processus de capacity planning vous permettront de proposer une infrastructure virtuelle performante sans aléas.
Installation VMware Consolidated Backup (VCB)
Jusqu’à présent pour sauvegarder un serveur Windows, il fallait installer un client de sauvegarde (Networker par exemple) puis sauvegarder les données ainsi que le System State. Pour réinstaller complètement un serveur, il fallait réinstaller l’OS et les applications avant de faire la restauration.
Les serveurs sont maintenant un ensemble de fichiers représentant d’une part la configuration « matérielle » (vmx) et d’autre part les données (vmdk) (ce sont les seuls fichiers qui nous intéressent dans le cadre de la gestion des sauvegardes). Il est donc possible de sauvegarder directement ces fichiers afin de faciliter les restaurations complètes.
Pour cela, VMware propose VMware Consolidated Backup (VCB) et plus récemment VMware Data Recovery.
Dans cet article, nous allons voir comment installer VCB. VMware Data Recovery sera traité dans un prochain billet.
Il existe plusieurs façons de configurer VCB. Dans notre cas, nous utiliserons le mode de transport SAN. C’est à dire que les données sauvegardées par VCB vont transiter par la fibre.
- Principe
- Exécution de la commande de sauvegarde
- Création d’un snapshot de la VM
- Dans le cas d’une sauvegarde fullvm, copie du snapshot via la fibre sur un stockage externe
- Dans le cas d’une sauvegarde file, montage du snapshot via la fibre sur le serveur VCB
- Démontage du snapshot
- Suppression du snapshot
- Prérequis
- Les binaires de VCB :
- Le serveur VCB doit avoir accès au SAN.
- Ne surtout pas présenter les LUNs contenant les datastore au serveur VCB maintenant.
- Créer un utilisateur ESX_VCB_SVC dans le domaine Active Directory. Je vous recommande de générer un mot de passe complexe via le logiciel Keypass.
- Ajouter l’utilisateur ESX_VCB_SVC dans le groupe administrateur local du serveur VCB.
- Habilitation de l’utilisateur ESX_VCB_SVC à accéder au VCenter.
- Se connecter au vcenter
- Faire un clic droit sur le nom du serveur VCenter puis choisir « Ajouter autorisation »
- Sélectionner « Utilisateur Vmware Consolidated Backup » puis cliquer sur « Ajouter »
- Saisir le nom de l’utilisateur ESX_VCB_SVC. Il faut préciser le nom du domaine. Cliquer sur « OK ».
- Désactivation de l’automount de Windows
- Ouvrir l’utilitaire diskpart
- Désactiver l’auomount
- Vérification de la désactivation
- Quitter diskpart
- Présentation des LUNs
- Installation de VCB
- Configuration
- BACKUPROOT= »K:\\mnt »; : Destination de la sauvegarde (il faut doubler les « \ »)
- HOST= »XXXXXXXX »; : Adresse du VCenter
- USERNAME= »__sspi__ »; : SSPI pour l’authentification intégrée
- PASSWORD= »*** »;
- TRANSPORT_MODE= »san »; : Utilisation de la fibre
- Exécution
Voici les étapes d’une sauvegarde VCB :
Cette étape a pour but de donner le droit à l’utilisateur ESX_VCB_SVC de créer un snaphot des VM puis de cloner ce snapshot.
Pour sauvegarder les VM en utilisant la fibre, il faut présenter les LUN VMFS au serveur Windows VCB. Par défaut Windows essaie de monter le disque, de lui attribuer une lettre et de le signer. Dans le cas du VMFS, il ne faut surtout pas que le serveur VCB monte les LUNs comme des partitions Windows.
Pour désactiver l’automount :
Pour cela lancer une fenêtre de commande et saisir les commandes suivantes :
Diskpart
Automount disable
Automount
Exit
Les LUNs contenant les VM peuvent être présentés au serveur VCB. Voici ce que préconise HP concernant les présentations des LUNs au VCB :
Note
When configuring VMware Consolidated Backup (VCB) with an EVA array, all vSphere servers must be set to VMware. However, the VCB proxy host, which is a Microsoft® Windows® server attached to the EVA, must be set to Microsoft Windows (Windows Server 2003) or Microsoft Windows 2008 (Windows Server 2008).
Bien que d’habitude, on recommande de présenter les LUNs de la même façon à tous les serveurs partageants une ressource, dans ce cas précis, les LUNs sont présentés en mode VMware pour les ESX et en mode Windows pour le VCB.
Il est possible de l’automatiser. Dans notre cas, l’installation est manuelle.
La configuration se trouve dans le fichier C:\Program Files (x86)\VMware\VMware Consolidated Backup Framework\config\config.js .
Les clauses à modifiées dans ce fichier sont :
Pour sauvegarder la VM nommée TEST (nom apparaissant dans le VCenter), la commande est la suivante :
cscript "C:\Program Files (x86)\VMware\VMware Consolidated Backup Framework\generic\pre-command.wsf" "C:\Program Files (x86)\VMware\VMware Consolidated Backup Framework" "TEST" fullvm
Du côté du VCenter, on peut voir le traitement :
Cette commande créée un répertoire TEST-fullVM à l’emplacement BACKUPROOT. La VM est sauvegardée sous forme de fichier VMDK. Ces fichiers peuvent alors être sauvegardés sur bande.
Les serveurs ainsi sauvegardés peuvent être réinstallés rapidement et par lots via Vmware Converter.
Extension d’un disque virtuel VMDK d’un serveur Windows
Les serveurs virtuels ont de nombreux avantages, il en existe un particulièrement intéressant: l’extension des disques.
Sur un serveur physique lorsque les disques sont pleins, il faut soit faire le ménage, soit capturer le disque (les disques dans le cas d’un raid) puis le remplacer par un plus grand et enfin restaurer l’image.
Avec les serveurs virtuels, il suffit de modifier les paramètres de la VM puis d’étendre la partition sous windows.
Voici les étapes pour étendre un disque d’un serveur Windows 2003 fonctionnant sur ESX 4.1.
Prérequis : Il faut supprimer les snapshots de la VM. Le datastore doit disposer de suffisamment d’espace. L’extension du disque peut être réalisée à chaud. Néanmoins le disque contenant le fichier de swap ne peut pas être étendu via Windows. Pour l’étendre, il faut utiliser une solution de type Winpe ou LiveCD Linux.
Se connecter au VCenter.
Sélectionner la vue « VM et modèles ».
Faire un clic droit sur la VM puis sélectionner « Modifier les paramètres ».
Sélectionner le disque puis augmenter sa taille à l’aide du champ « Taille Prévue » enfin cliquer sur « OK ».
Dans la taskbar, on peut voir que l’extension est terminée.
Il faut maintenant ouvrir une session avec droits administrateurs sur le serveur (TS, ILO, ou Vmrc).
Sur le serveur, ouvrir une fenêtre « cmd ».
Taper la commande « Diskpart ».
« List volume » pour déterminer la partition à étendre.
« Select volume n » (n est l’id du volume à étendre).
« Extend ».
La partition est étendue.
Nous verrons dans un prochain article comment étendre le disque contenant la partition de swap à l’aide d’un WINPE.
virtualsysadmin 