Virtualisation, conteneurs et supervision
Ce que ce chapitre apporte8 points
- Expliquer le principe de la virtualisation et distinguer les deux types d'hyperviseurs.
- Distinguer une machine virtuelle d'un conteneur, et savoir quand employer l'un ou l'autre.
- Décrire ce qu'est une image et ce qu'apporte la conteneurisation.
- Calculer un taux de surallocation et en connaître les limites.
- Nommer les métriques de supervision utiles et les seuils qui les accompagnent.
- Expliquer le rôle de SNMP et d'une MIB.
- Distinguer supervision technique et supervision fonctionnelle.
- Traduire un taux de disponibilité en temps d'arrêt réel.
La virtualisation
La virtualisation consiste à faire tourner plusieurs systèmes d'exploitation complets sur un même matériel physique. Chaque système virtualisé, appelé machine virtuelle, croit disposer de son propre matériel.
L'hyperviseur est le logiciel qui répartit les ressources physiques entre les machines virtuelles.
| Type | Où il s'exécute | Exemples | Usage |
|---|---|---|---|
| Type 1, dit natif | directement sur le matériel | ESXi, Hyper-V, Proxmox | production |
| Type 2, dit hébergé | au-dessus d'un système existant | VirtualBox, VMware Workstation | poste de travail, maquette |
Ce que la virtualisation apporte concrètement :
- Mutualiser : un serveur physique moderne est très largement sous-utilisé par un seul service.
- Isoler : un service qui plante n'entraîne pas les autres.
- Restaurer vite : une machine virtuelle est un ensemble de fichiers, qu'on sauvegarde et remonte ailleurs.
- Tester : un instantané pris avant une mise à jour permet de revenir en arrière en une minute.
C'est pourquoi les deux contrôleurs de domaine ne doivent pas être sur le même hyperviseur, et pourquoi on n'y place pas non plus la sauvegarde de ce qu'il héberge.
La surallocation
On attribue couramment aux machines virtuelles plus de processeurs virtuels qu'il n'y a de cœurs physiques, parce qu'elles ne travaillent pas toutes en même temps. C'est la surallocation, et elle a des limites.
La mémoire, non. Une machine qui a reçu 32 Go et qui les utilise les garde. Surallouer la mémoire conduit à l'échange sur disque, et le chapitre de supervision montre à quel point cela dégrade un service.
Le système invité, mis sous pression, décharge vers son propre fichier d'échange les pages dont il a le moins besoin. La mémoire est donc bien récupérée, et elle l'est en transformant des accès mémoire en accès disque, quelques dizaines de nanosecondes devenant quelques centaines de microsecondes.
La surallocation mémoire n'échoue donc pas franchement, ce qui serait préférable : elle se paie en entrées/sorties disque sur toutes les machines de l'hôte à la fois, y compris celles qui n'ont rien demandé. C'est ce qui rend le symptôme difficile à rattacher à sa cause.
Les conteneurs
Un conteneur est un environnement isolé contenant une application et toutes ses dépendances, mais partageant le noyau du système hôte.
Une image est le modèle immuable à partir duquel on crée un ou plusieurs conteneurs.
Docker est la plateforme la plus répandue pour construire et exécuter des conteneurs.
| Machine virtuelle | Conteneur | |
|---|---|---|
| Contient | un système d'exploitation complet | une application et ses dépendances |
| Noyau | le sien | celui de l'hôte |
| Démarrage | dizaines de secondes | moins d'une seconde |
| Taille | plusieurs gigaoctets | dizaines à centaines de mégaoctets |
| Isolation | forte | plus légère |
| Adapté à | des systèmes différents, une isolation stricte | déployer et répliquer une application |
Ai-je besoin de déployer la même application rapidement, plusieurs fois, à l'identique ? Alors un conteneur.
Les deux se combinent d'ailleurs très bien : des conteneurs qui tournent dans des machines virtuelles, c'est l'architecture la plus répandue en production.
Un conteneur qui s'exécute avec des privilèges élevés, ou qui monte un répertoire de l'hôte, réduit encore l'isolation. C'est pourquoi on n'isole pas deux clients différents par de simples conteneurs sur un même hôte.
Superviser
La supervision est l'ensemble des mécanismes permettant de surveiller l'état d'un système, d'un service ou d'une infrastructure.
Le monitoring est la collecte et l'analyse continues d'indicateurs afin d'observer un comportement dans la durée.
Un tableau de bord centralise ces indicateurs sous forme lisible. Grafana, Zabbix et Centreon sont les outils courants.
Technique ou fonctionnelle
La supervision fonctionnelle répond à « le service rend-il le service ? » : la page se charge-t-elle, la connexion à la base aboutit-elle, un utilisateur peut-il ouvrir une session.
Une infrastructure entièrement verte au tableau de bord technique peut être totalement inutilisable. C'est le rappel du chapitre 1 : une machine qui répond n'est pas un service qui fonctionne.
Les métriques et leurs seuils
| Métrique | Ce qu'elle dit | Seuil d'attention courant |
|---|---|---|
| Charge processeur | occupation, mais pas la file d'attente | soutenue au-dessus de 80 % |
| Mémoire disponible | ce qu'il reste réellement | moins de 10 %, ou échange actif |
| Espace disque | saturation prévisible | moins de 15 %, et la tendance |
| Latence réseau | qualité du lien | selon la ligne de base mesurée |
| Température | environnement de la salle | selon le constructeur |
| État d'un service | démarré ou non | tout arrêt inattendu |
La valeur instantanée dit où l'on est ; la pente dit quand on arrivera au mur. C'est cette seconde information qui permet d'intervenir avant l'incident plutôt qu'après.
SNMP et la MIB
SNMP est le protocole standard d'interrogation des équipements réseau et des serveurs pour en relever l'état. Il fonctionne dans les deux sens : par relève, quand la supervision demande une valeur (GET), et par notification, quand l'équipement signale de lui-même un événement (TRAP).
La MIB est la base d'information qui décrit, pour un équipement donné, l'ensemble des valeurs qu'on peut lui demander, organisées en arborescence. Chaque valeur y est identifiée par un OID, une suite de nombres.
L'intérêt est l'uniformité : un commutateur, une imprimante, un onduleur et un serveur répondent tous au même protocole, et l'outil de supervision n'a pas besoin de connaître chaque constructeur.
La notification est immédiate et part de l'équipement : une alimentation qui lâche, un ventilateur arrêté, une température franchie, un lien réseau qui tombe. L'équipement envoie un message sans attendre d'être interrogé.
Ne compter que sur la relève retarde la détection d'une panne du temps d'un intervalle, ce qui est acceptable pour un remplissage de disque et absurde pour une alimentation. Ne compter que sur les notifications prive de toute tendance, et laisse passer ce qui se dégrade sans jamais franchir de seuil. Un dispositif complet emploie les deux.
public. Quiconque écoute peut alors interroger l'équipement, voire le reconfigurer si l'accès est en écriture.On emploie donc SNMPv3, qui authentifie et chiffre, on limite l'accès en lecture seule, et on restreint par filtrage les adresses autorisées à interroger.
Relever autrement que par SNMP
SNMP reste la norme pour ce qui n'exécute pas de logiciel à soi : commutateurs, onduleurs, imprimantes, sondes. Pour un serveur, et plus encore pour un conteneur, deux autres approches ont pris le dessus, pour des raisons pratiques avant d'être techniques.
La première installe un agent sur la machine, qui relève ce qu'il veut et le transmet au collecteur. La seconde renverse le sens : l'application expose elle-même ses mesures sur une adresse, et le collecteur vient les lire à intervalle régulier. C'est le modèle de Prometheus, et il s'est imposé sur les architectures à conteneurs.
| SNMP | Agent | Exposition et collecte | |
|---|---|---|---|
| Sens du flux | le collecteur interroge | l'agent émet | le collecteur vient lire |
| Transport | UDP, souvent filtré | variable | HTTP ou HTTPS |
| Convient à | matériel réseau | serveurs | conteneurs et applications |
| Mesures applicatives | non | partiellement | oui, celles que l'application choisit |
La conséquence pour la supervision est nette : on ne surveille plus des machines, on surveille des services, et l'indicateur « la machine répond » perd tout intérêt au profit de « le service répond dans le temps annoncé ».
Disponibilité et engagement de service
Un taux de disponibilité s'annonce en pourcentage, ce qui masque ce qu'il autorise réellement.
C'est le même raisonnement que pour le RTO du chapitre précédent : un chiffre qu'on n'a pas mesuré est un chiffre qu'on ne tiendra pas.
À calculer soi-même
Un taux de disponibilité s'annonce en pourcentage, ce qui masque ce qu'il autorise réellement. Le traduire en minutes est le seul moyen de savoir ce qu'on promet.
Traduire un engagement en minutes
- 1.
Combien de minutes d'arrêt par an un engagement à 99,95 % autorise-t-il ?
- 2.
Combien d'heures d'arrêt par an un engagement à 99,9 % autorise-t-il ?
- 3.
Une fenêtre de maintenance d'une heure par mois est planifiée. Quel taux de disponibilité, en pour cent, cette seule fenêtre plafonne-t-elle, avant tout incident ?
- 4.
Deux composants à 99,9 % chacun sont montés en série, c'est-à-dire que la panne de l'un suffit à interrompre le service. Quelle disponibilité, en pour cent, l'ensemble offre-t-il ?
- 5.
Un hôte de 24 Go de mémoire héberge 8 machines virtuelles configurées avec 4 Go chacune. Quel est le taux de surallocation ?
Et ajouter un composant en série ne coûte pas « un peu » de disponibilité : il multiplie. Trois composants à 99,9 % n'offrent plus que 99,7 %, sans qu'aucun d'eux soit en cause.
Où la démarche dérape
Un calcul de disponibilité mené sur une chaîne de composants, avec la bonne intuition et la mauvaise opération.
Une disponibilité qui ne se moyenne pas
Une seule étape est fausse. Désigner laquelle.
Deux composants identiques, chacun disponible avec la probabilité , sont montés en série : la panne de l'un suffit à interrompre le service. On cherche la disponibilité de l'ensemble.
Exercices type
Machine virtuelle ou conteneur pour héberger une application web interne ?
Conteneur, si l'application est packagée pour cela. Elle démarre en une seconde, se réplique à l'identique, et se met à jour en remplaçant l'image.
Machine virtuelle, si l'application exige un système particulier, un accès matériel, ou si l'isolation doit être forte parce que l'application est exposée.
En pratique, le choix courant est mixte : des conteneurs qui tournent dans une machine virtuelle dédiée. On garde l'isolation de la virtualisation et la souplesse de déploiement des conteneurs.
Le tableau de bord est vert, et les utilisateurs ne peuvent pas travailler. Comment est-ce possible ?
Parce que la supervision est technique et pas fonctionnelle.
Les machines répondent, les services sont démarrés, les disques ont de la place. Et pourtant : l'annuaire refuse les authentifications à cause d'une dérive d'horloge, ou le partage est monté mais les permissions ont été modifiées, ou la base répond mais avec dix secondes de latence.
Le correctif est d'ajouter des sondes qui font ce que fait un utilisateur : ouvrir une session de test, écrire puis relire un fichier dans le partage, exécuter une requête simple sur la base. Ce sont ces sondes qui détectent les pannes que la supervision technique ne voit pas.
Un hyperviseur héberge 24 vCPU sur 8 cœurs physiques. Est-ce acceptable ?
Une surallocation de 3 pour 1 est courante, donc a priori oui. Mais le taux ne suffit pas à conclure : il faut la charge réelle.
Si les machines tournent en moyenne à 20 %, la consommation effective est d'environ 4,8 cœurs sur 8 : confortable. Si elles tournent à 70 %, on demande près de 17 cœurs à un matériel qui en a 8, et tout le monde attend.
Ce qu'il faut regarder n'est donc pas le taux d'attribution mais la file d'attente processeur de l'hyperviseur : c'est elle qui dit si les machines patientent.
Et la mémoire ne se raisonne pas ainsi : elle ne se suralloue pas.
Pourquoi ne pas placer les deux contrôleurs de domaine sur le même hyperviseur ?
Parce que la redondance disparaît. Deux contrôleurs sur un seul hôte tombent ensemble, et l'entreprise entière perd l'authentification.
C'est la reformulation du point de défaillance unique du premier chapitre : on croit avoir doublé le service, on a doublé un composant en gardant un support commun.
La règle vaut au-delà : la sauvegarde d'un hyperviseur ne se stocke pas sur cet hyperviseur, et les deux membres d'un couple redondant ne partagent ni le même hôte, ni la même baie, ni idéalement le même local.
Quelle différence entre superviser un serveur et superviser un service ?
Superviser un serveur, c'est mesurer un état matériel et logiciel : allumé, chargé à tant, disque à tant. C'est nécessaire, et cela ne dit rien de l'usage.
Superviser un service, c'est vérifier qu'il rend ce qu'on attend de lui, du point de vue de celui qui l'utilise.
Le cas d'école : un serveur de fichiers à 5 % de charge processeur, avec un disque plein. Techniquement au repos, fonctionnellement mort.
La supervision fonctionnelle coûte plus cher à mettre en place, parce qu'il faut écrire une sonde par service. C'est elle qui évite d'apprendre les pannes par un appel d'utilisateur.
Le métier demande 99,99 % de disponibilité. Que répondre ?
D'abord traduire : 52 minutes d'arrêt par an, toutes causes confondues, maintenances comprises si elles ne sont pas exclues.
Puis chiffrer ce que cela suppose : redondance complète sans point commun, bascule automatique testée, astreinte permanente, et fenêtres de maintenance sans interruption de service.
Enfin proposer une graduation par criticité, comme au chapitre précédent : 99,99 % sur l'authentification et la base de production peut se justifier ; le même taux sur l'intranet documentaire ne se finance pas.
La bonne réponse n'est jamais un refus, c'est un chiffrage qui rend l'arbitrage possible.
Vérification
1.Un conteneur est-il une machine virtuelle légère ?
2.Quelle ressource se suralloue le plus facilement ?
3.Un disque est rempli à 85 % et n'a pas bougé depuis six mois. Faut-il alerter ?
4.Une fenêtre de maintenance d'une heure par mois permet-elle d'annoncer 99,9 % ?
La méthode
- Compter les services qui tombent avec un hyperviseur avant de mutualiser.
- Surallouer le processeur, jamais la mémoire. Et regarder la file d'attente, pas le taux d'attribution.
- Machine virtuelle pour isoler, conteneur pour déployer. Les deux se combinent.
- Ajouter une sonde fonctionnelle par service critique, en plus des métriques techniques.
- Poser des seuils sur la tendance autant que sur la valeur, en particulier pour le disque.
- Employer SNMPv3, en lecture seule, et restreindre les adresses autorisées à interroger.
- Traduire tout taux de disponibilité en minutes avant de l'annoncer, et préciser si les maintenances en sont exclues.
Synthèse
- Hyperviseur type 1 sur le matériel, en production ; type 2 au-dessus d'un système, pour la maquette.
- La virtualisation mutualise, isole et accélère la restauration, au prix d'une concentration du risque.
- Processeur surallouable, mémoire non.
- Un conteneur partage le noyau de l'hôte : léger, rapide, mais isolation moindre. Une image en est le modèle immuable.
- Supervision technique : la machine tourne. Supervision fonctionnelle : le service rend le service. Il faut les deux.
- SNMP interroge, la MIB décrit ce qu'on peut demander. Version 3 obligatoire, en lecture seule.
- Un taux de disponibilité se traduit toujours en temps d'arrêt réel : 99,9 % vaut 8 h 45 par an, 99,99 % vaut 52 minutes.
Mettre en pratique
Ce que promet un taux de disponibilité, le seuil qui regarde la pente, et la surallocation.
- Ce que promet un taux de disponibilitéNiveau 3
- Le seuil qui regarde la penteNiveau 3
- Surallouer, mais pas n'importe quoiNiveau 3