L’importance de la supervision

L’importance de la supervision

En environnement physique traditionnel, la supervision consiste à collecter des informations sur tous les éléments actifs de l’infrastructure : les switchs, le réseau, les baies de stockage et les serveurs. Les composants serveurs sont en particulier surveillés afin de détecter les défaillances matérielles et d’analyser les potentiels goulets d’étranglement. Dans cet environnement, les ressources d’un serveur sont disponibles pour une seule application et il est très rare que le serveur soit saturé. Les problèmes de performance constatés proviennent bien souvent d’une mauvaise configuration, de l’application, ou du réseau mais rarement à cause des performances intrinsèques du serveur.

Dans un environnement virtuel, l’aspect performance est fondamental puisque les VM vont partager les mêmes ressources d’un seul serveur hôte ESX. Il est donc indispensable de superviser l’activité de l’hôte et des VM afin de s’assurer que les VM disposent de suffisamment de ressources pour faire tourner leurs applications.

Cette analyse fine des ressources doit permettre de consolider l’infrastructure de façon optimale et ainsi de faire des économies importantes car il ne sera pas nécessaire d’investir dans de nouveaux serveurs.

Un serveur mal dimensionné avec une charge importante peut faire écroulé les performances globales de celuici.

A contrario un serveur sousdimensionné avec des VM n’exploitant qu’une faible partie des ressources du serveur est un gâchis et fait perdre de l’argent à l’entreprise.

C’est la notion de taux de consolidation qui est importante à prendre en considération car il représente le nombre de VM qu’il est possible de faire tourner simultanément sur un serveur hôte ESX en respectant les performances et les niveaux de qualité de services requis.

Une étude d’EMA Research montre que le taux de consolidation moyen pour un serveur en production est de 6 VM. Ce taux peut varier de 2 VM pour les pires consolidations (on peut se demander dans ce cas la pertinence du passage en environnement virtuel) jusqu’à une moyenne de 15 VM pour les meilleures.

Les meilleurs taux ont été observés dans les entreprises qui utilisent des outils d’optimisation ou de gestion prévisionnel de charge qui offrent une gestion fine des ressources et permettent d’atteindre en toute sérénité des taux de consolidation importants. Les constructeurs, éditeurs, revendeurs n’encouragent pas naturellement à optimiser l’infrastructure et ce travail doit absolument être réalisé par le client luimême. L’utilisation de tels outils permettra d’obtenir des gains considérables.

En 2009, mettre plus de 20 VM par serveurs peut paraître gigantesque mais dans quelques années la technologie aidant, il y a tout lieu de penser que les taux de consolidation atteindront des centaines de VM par serveurs.

1. Supervision du serveur hôte

Superviser l’infrastructure est la combinaison d’actions proactives de la part de l’administrateur et d’actions réactives en fonction d’alarmes définies.

Sous vCenter Server, il est possible de conjuguer les deux méthodes. D’autres outils du marché peuvent venir en complément de vCenter pour analyser finement les métriques relevés et les performances des différents objets.

La supervision du serveur peut se faire au travers d’un agent qui récupère les informations et les envoie vers un serveur de management. L’agent de supervision est souvent fourni par le constructeur du serveur. L’intérêt de ce type de solution est que les informations récupérées sont exhaustives, l’inconvénient est qu’il est nécessaire d’installer un agent au niveau du service Console.

Une autre solution consiste à se baser sur les API (Application Program Interface) fournis par VMware pour une intégration parfaite avec l’environnement virtuel.

Dans vCenter Server, il est également possible d’utiliser le Health Status afin de récupérer des informations basiques sur l’état de santé du serveur hôte. Le Health Status ne nécessite pas l’ajout d’agent dans le service Console.

L’installation d’un agent au niveau du Service console est tout à fait envisageable si l’empreinte de l’agent n’est pas très importante. Cela permet de récupérer des informations plus riches permettant de faire des

analyses plus fines.

2. Health Status

L’outil Health Status permet de visualiser l’état du serveur. Certains composants sont surveillés. Ces informations sont récupérées en utilisant SMASH (Systems Management Architecture for Server Hardware) qui est un jeu de spécifications techniques permettant de définir un protocole standard pour le management du datacenter. Pour en savoir plus, consultez http://www.dmtf.org/standards/mgmt/smash/

La collecte d’information au travers d’Health Status se fait sur les composants : CPU, mémoire, ventilateur, température, voltage, consommation, batterie, réseau, câble de connexion, composants logiciels.

- 1 -© ENI Editions - All rigths reserved - Guillaume DUBOIS

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAABAMzg5NDA3IC0gR3VpbGxhdW1lIERVQk9JUyAtIGI5MzMxMjgxLTc0ZjktNGZiNy1hYzBmLWQzYzQxMTljYjgyY+BNLf+mmcyICwA=-enidentnumber

Health Status est un Plugin.

■ Pour l’installer, allez dans vCenter Server, onglet Plugin, Manage Plugin. Faites un clic droit, puis Enable.

■ Pour le visualiser, allez dans vCenter, onglet Hardware Status.

3. Performance dans vCenter Server

La visualisation des performances sous vSphere 4 a été améliorée et des graphiques ont été ajoutés pour faciliter l’analyse. Cela permet d’avoir une vision simple de l’état de votre serveur ESX et des VM associées.

Les métriques relevées portent sur le CPU, la mémoire, les disques, le réseau, les ressources, les clusters et le système.

Les données relevées dépendent de deux facteurs : le niveau et les intervalles de collectes.

Il existe 4 niveaux de collectes :

● Niveau 1 (par défaut) :

Collecte des informations générales sur l’utilisation d’ESX.

Les métriques relevées portent sur le CPU, la mémoire, les disques et le réseau ainsi que des informations systèmes : Uptime, Heartbeat et métriques DRS.

Cela permet de voir comment les ressources matérielles sont utilisées.

● Niveau 2 :

Collecte des informations de façon plus détaillée que le niveau 1 en particulier les données mémoire : mémoire active, swap, partage mémoire. Détermine la mémoire active et permet d’anticiper la possibilité de mettre d’autres VM sur le même hôte.

● Niveau 3 :

Inclut les mêmes métriques que les niveaux 1 et 2 avec en plus : des informations au niveau périphérique par carte réseau, cartes HBA ou par cœur. Cela inclut des informations concernant l’utilisation CPU. Permet de déterminer l’efficacité du vSMP (en comparant le temps Ready et Wait Time pour chaque vCPU), ainsi que les performances.

● Niveau 4 :

Inclut toutes les informations supportées par vCenter Server.

- 2 - © ENI Editions - All rigths reserved - Guillaume DUBOIS


Permet de déterminer si un composant est surchargé ou pas.

Le niveau 1 consomme très peu de ressources du serveur hôte pour faire la collecte d’informations. Les ressources utilisées par les niveaux 2 à 4 ne sont pas négligeables. Le niveau 4 ne doit être utilisé qu’à des fins d’analyse de problème sur une courte durée.

Pour paramétrer ces niveaux :

■ Allez dans Home\vCenter Server Settings, onglet Statistics.

■ Puis cliquez sur Edit.



■ Choisissez votre niveau de collecte Level 1 à Level 4.

Les intervalles de collecte :

Par défaut, vCenter Server possède plusieurs intervalles de collections : Realtime, Day, Week, Month, Year ou Custom.

Chaque intervalle spécifie une longueur de statistique de temps enregistrés dans la base de données vCenter.

Les statistiques Realtime (temps réel) ne sont pas stockées dans la base de données. Ces données sont stockées dans un fichier plat dans le serveur hôte ESX et sont collectées directement toutes les 20 secondes.

Pour visualiser les performances dans vCenter Server :

■ Cliquez sur l’onglet Performance puis choisissez Chart Options.



■ Sélectionnez les objets que vous souhaitez visualiser.

Visualisation des ressources CPU utilisé par un serveur ESX



Visualisation des accès disque en entrées/sorties d’une VM

vSphere 4 introduit des compteurs CPU et mémoire dans le gestionnaire de performance (perfmon) de Windows dans les Guest OS. Cela permet d’avoir une meilleure granularité et une meilleure interprétation des performances à l’intérieure de la VM.

4. Différences entre Host Mem, Guest Mem, Memory Size

Dans vCenter Server, trois valeurs sont visualisables Guest Mem, Host Mem et Memory Size.

■ Cliquez sur votre Datacenter puis allez dans l’onglet Virtual Machines.

Trois valeurs sont présentes : Host Mem, Guest Mem et Memory size.

Memory size est la mémoire configurée.

Host Mem est la mémoire physique en Mo allouée pour la VM (incluant l’overhead de la VM).

Guest Mem est la quantité de mémoire active utilisée par la VM pour son OS et ses applications.

L’overhead est la quantité de ressources utilisée par le serveur ESX pour tout ce qui est lié aux techniques de virtualisation. Une application tournant dans un Guest OS d’une VM consomme un peu plus de ressources que

la même application tournant sur un serveur physique. Même si ces ressources sont très faibles (elles ne représentent qu’un tout petit pourcentage), il faut néanmoins en tenir compte lorsque les taux de consolidation sont importants. Cet overhead concerne principalement le processeur, la mémoire et les accès disques.



Pourquoi la valeur Host Mem estelle si élevée dans certaines VM ?

Comme nous l’avons vu précédemment, un système d’exploitation charge au maximum la mémoire dont il dispose et cela même s’il n’en a pas l’utilité.

Avec des outils comme Veeam il est possible d’analyser ces différentes valeurs.

Exemple :

Démarrons une VM configurée avec 1 Go de mémoire et voyons comment la mémoire est gérée. Pour des raisons de compréhension, nous ne faisons pas de surallocation de mémoire et ne démarrons aucune application après le démarrage.

Mémoire configurée (Memory Size) 1024 MB.

Mémoire allouée par le Host (Host Mem) 663 MB.

Mémoire active (Guest Mem) 22 %.



Ce que nous constatons est que lorsque la VM démarre vers 13h, le serveur hôte ESX lui alloue 1 Go de mémoire. Le système d’exploitation possède 1 Go et charge au maximum ses pages mémoires.

Après quelques minutes nous voyons que la mémoire consommée par le serveur hôte est de 663 Mo alors que la mémoire active ne représente que 22 % de la mémoire configurée, soit 220 Mo.

Certaines pages mémoires sont chargées en mémoire centrale mais ne sont pas utilisées (idle memory). C’est cette mémoire qui est récupérée en priorité par le ballooning (cf. chapitre Fonctionnement et concepts).

Cette valeur Host mem peut être par moment très élevée car les pages mémoires chargées dans le temps ne sont pas forcément libérées par l’OS.

5. Les métriques pour le CPU

Il existe beaucoup de métriques disponibles pour le processeur remonté par les différents outils. Les métriques comme CPU Usage (Average) dans vCenter Server permettent de déterminer la charge moyenne du processeur ainsi que la charge au niveau des VM. Cette valeur est à surveiller et donne des indications si une VM monopolise de façon importante du temps CPU.

Un métrique très intéressant et moins connu est le Ready Time.

Ready Time :

Dans un environnement virtuel où les ressources sont partagées, il peut arriver que plusieurs VM souhaitent utiliser le CPU au même moment. Certaines VM devront patienter avant de pouvoir être traitées par le CPU. Le Ready Time est le temps qu’une VM attend avant qu’elle ne puisse être traitée par un CPU. C’est le gestionnaire de ressource au sein du VMkernel qui attribue du temps CPU en fonction des requêtes des VM et qui décide sur quel coeur la VM doit tourner.

Si un coeur d’un processeur est trop chargé, le gestionnaire de ressource privilégie de laisser la VM sur le même coeur afin de pouvoir utiliser les données qui se trouvent dans le cache du CPU générant par là même un peu de Time Ready. Le gestionnaire peut cependant décider de migrer la VM sur un autre coeur si l’attente devient trop longue.

Même s’il est normal qu’un serveur accumule du Time Ready, il faut cependant veiller à ce que cette valeur ne dépasse pas 5 % (cf. chapitre Annexe esxtop).

Cette valeur ne doit pas être la seule à prendre en considération mais elle est un bon indicateur sur d’éventuels problèmes de configuration (mauvaise utilisation du Scheduling Affinity, du vSMP ou des VM avec un paramétrage Share ou Limit non approprié) ou sur le mauvais placement de certaines VM au sein de l’infrastructure.

6. Les alarmes

Les alarmes sont des actions réactives par rapport à des critères définis. Ils peuvent déclencher une action comme par exemple l’envoi d’un email à l’administrateur.

Les alarmes doivent être utilisées avec parcimonie afin de seulement mettre en relief les dysfonctionnements importants.

a. Les alarmes de base

Pour avoir accès aux alarmes de tous les objets du Datacenter :

■ Cliquez sur votre vCenter Server (dans notre cas HP32662138FDF).

■ Puis accédez à l’onglet Alarms.

Un certain nombre d’alertes sont de base. Vous pouvez désactiver ces alertes :

■ Cliquez sur l’alerte et décochez enable this alert.

Lorsqu’une alerte a été envoyée, vous avez un panneau rouge sur l’objet en l’occurrence sur l’hote ESX :

■ Pour désactiver et enlever l’alerte, cliquez sur l’onglet Triggered Alarms, faites un clic droit sur l’hôte et cliquez sur Reset Alarm to Green.



Votre serveur n’a plus d’alerte.

b. Création d’une alarme

■ Allez dans l’onglet Alarms Definitions.

■ Faites un clic droit sur un espace libre New Alarm.

■ Choisissez l’objet de l’infrastructure virtuelle à surveiller et sur lequel une alerte sera créée.

■ Configurez Triggers qui correspond au seuil pour lequel une alarme sera déclenchée.



■ Cliquez sur Add.

Par exemple : VM CPU Usage (%) : entre 75 et 90% il y aura un warning et audelà de 90 % une alerte sera envoyée.

Vous pouvez associer une action (non obligatoire) comme l’envoi d’un email ou envoi d’un trap SNMP vers une console de management. À noter que s’il n’y a pas d’action associée les alarmes seront visualisables dans cette partie alarme.

■ Choisissez l’action, par exemple Send a notification email.

Si vous rentrez une adresse mail, il ne faut pas oublier de configurer votre serveur SMTP (allez dans Home puis vCenter Server Settings puis mail).



7. Les Maps

Les Maps permettent d’avoir une vision graphique de l’environnement virtuel. Il est possible de connaître les relations entre les serveurs hôtes et les VM, le réseau et les Datastore.

8. Esxtop

Esxtop : permet de visualiser en temps réel les activités du serveur hôte CPU, mémoire, disque et réseau.

■ Allez dans le service console puis tapez esxtop.

■ Pour superviser les statistiques E/S des disques et contrôleurs : saisissez d.

■ Pour la mémoire : saisissez m.

■ Pour le réseau des cartes physiques ou cartes dans les VM : saisissez n.

■ Pour le CPU : saisissez c.

Pour connaître l’interprétation des valeurs obtenues, cf chapitre Annexes.

9. Les outils de supervision et de management

a. OmnivisionVPR (Virtual Performance Reporting) de Systar

Le produit Omnivision de Systar est une solution de "Capacity Management" qui permet d’aborder avec sérénité et de façon optimale les différentes étapes de la virtualisation VMware : de la phase de P2V à la phase d’optimisation. Pour chaque étape, Omnivision fournit des rapports à valeur ajoutée qui analysent la performance de l’infrastructure virtuelle et donnent de la visibilité sur les ressources disponibles et utilisées, celles en risque de surcharge et celles ayant des potentiels d’optimisation.

Omnivision permet ainsi de réaliser rapidement un ROI (Return On Investment) sur les environnements VMware par une exploitation optimisée de l’infrastructure : taux de consolidation optimal et investissement différés de nouveaux serveurs.



Une vue de l’interface Omnivision VPR de Systar.

b. Veeam Monitor

Veeam Monitor est un outil très simple d’utilisation et très visuel. Les informations relevées sont pertinentes et permettent de faire une analyse rapide des différents pics d’activité. Cette solution est plutôt orientée pour les PME ou moyens comptes. À noter que Veeam propose des solutions orientées pour les grands comptes avec les connecteurs (nworks connector) pour HP Operation Manager et pour Microsoft System Center Operations Manager.



c. vFoglight de Vizioncore (Quest Software)

vFoglight est un outil très convivial avec beaucoup d’indicateurs et de métriques. Il est riche en fonctionnalités et l’interface est très conviviale et permet d’analyser les performances rapidement. En outre, vFoglight offre des fonctionnalités de tracking et de refacturation (appelé Chargeback) permettant de réallouer des coûts aux différents services de l’entreprise.

d. Vkernel

C’est une solution assez visuelle basée sur une appliance. Vkernel fournit un tableau de bord assez intéressant car sur une seule vue il est possible de visualiser instantanément l’état des VM avec différentes couleurs : rouge, vert, jaune...



L’importance de la supervision

Documents

Transcript of L’importance de la supervision