Dimensionner et superviser un hôte de virtualisation

Dimensionner un hôte de virtualisation, c'est calculer le processeur, la mémoire, le stockage et le réseau dont il a besoin pour porter ses machines virtuelles, y compris quand un autre hôte du cluster est en panne ; le superviser, c'est mesurer en continu ces mêmes ressources pour être alerté avant qu'elles ne manquent. Ce chapitre donne une méthode de dimensionnement chiffrée, l'applique au cluster de Sorbier, explique la surallocation de chaque ressource, puis montre ce qu'il faut surveiller sur un hôte Proxmox VE et avec quels outils.

La surallocation, ressource par ressource

La virtualisation permet de promettre aux VM plus de ressources que l'hôte n'en a : c'est la surallocation (overcommit). Elle n'a pas le même effet sur chaque ressource.

Le ratio de consolidation du processeur, le nombre de vCPU attribués par cœur physique, mesure la surallocation. Pour des serveurs de PME peu chargés, un ratio de 2 à 4 vCPU par cœur physique est courant ; pour des VM très chargées en calcul (base de données importante, compilation), on reste près de 1. Les cœurs logiques de l'hyperthreading aident un peu, mais ne valent pas des cœurs physiques : compte les cœurs physiques pour rester prudent.

Une méthode de dimensionnement

1. Faire l'inventaire des VM à héberger : système, vCPU, mémoire, disques, et surtout la charge mesurée sur les serveurs actuels (moyenne et pointe, sur au moins un mois), plutôt que des estimations.
2. Additionner la mémoire des VM, et y ajouter la mémoire de l'hôte lui-même : environ 2 Gio pour Proxmox VE, plus le cache ZFS si l'hôte utilise ZFS (10 % de sa mémoire par défaut, au plus 16 Gio), plus Ceph le cas échéant.
3. Appliquer la règle N+1 : dans un cluster de n nœuds, n − 1 nœuds doivent pouvoir porter toutes les VM qui doivent continuer de tourner (au moins les ressources HA) quand l'un tombe.
4. Garder une marge : 20 % au-dessus du besoin calculé, pour les pointes et l'imprévu.
5. Dimensionner le stockage en capacité (disques, snapshots, croissance sur la durée de vie du matériel, sans dépasser 80 % de remplissage) et en performances (des SSD pour les disques des VM).
6. Dimensionner le réseau : 10 Gbit/s pour le stockage et les migrations, des liens agrégés pour le trafic des VM.
7. Prévoir la croissance sur la durée de vie du matériel, souvent cinq ans.

Le dimensionnement du cluster de Sorbier

L'inventaire des invités prévus :

La mémoire. Chaque hôte a 128 Gio ; avec le système en ZFS, son cache est limité à 12,8 Gio (10 % de 128), plus environ 2 Gio pour Proxmox : il reste 128 − 14,8 = 113,2 Gio par hôte pour les VM. Si un nœud tombe, les deux restants offrent 2 × 113,2 = 226,4 Gio, pour 52,5 Gio de besoin (63 Gio avec la marge de 20 %) : les invités occupent 23 % de la mémoire disponible en mode dégradé. Le cluster a de la place pour grandir, ce que Sorbier a voulu, pour accueillir plus tard les serveurs de l'agence ou des postes virtualisés.

Le processeur. En mode dégradé, 23 vCPU sur 2 × 16 = 32 cœurs physiques : un ratio de 0,72 vCPU par cœur, très confortable. En temps normal, sur 48 cœurs, il tombe à 0,48.

Le stockage. Les disques prévus totalisent 1 768 Go. Avec 30 % de croissance sur la durée de vie du NAS, 20 % de place pour les snapshots et un remplissage limité à 80 %, il faut 1 768 × 1,3 × 1,2 / 0,8 ≈ 3 450 Go utiles sur TrueNAS. Un pool de six disques de 2 To en RAIDZ-2 en offre environ 8 To avant les métadonnées de ZFS : la marge est large.

Ce qu'il faut surveiller

Les graphiques de l'onglet Summary (processeur, charge, mémoire, réseau, IO delay) se consultent sur une heure, un jour, une semaine, un mois ou un an. En ligne de commande, les vérifications rapides :

pvesh get /nodes/pve1/status          # processeur, mémoire, charge, version du noyau
pvesh get /cluster/resources --type vm   # tous les invités du cluster, leur nœud, leur consommation
pvesm status                          # remplissage des stockages
zpool status -x                       # « all pools are healthy », ou le pool en défaut
smartctl -H /dev/sda                  # état S.M.A.R.T. d'un disque
pvecm status                          # quorum
ha-manager status                     # ressources HA
pveperf                               # mesure rapide du processeur et des écritures synchrones (fsyncs/s)

Être alerté

Les notifications intégrées. Datacenter > Notifications envoie les événements de Proxmox VE (échec de sauvegarde, auto-isolation d'un nœud, échec de réplication, mises à jour disponibles) vers des cibles (targets) : messagerie par sendmail ou par un serveur SMTP, Gotify, webhook. Des règles (matchers) choisissent quels événements, de quelle gravité, vont vers quelle cible. Chez Sorbier, les erreurs partent vers l'adresse de l'équipe et vers le webhook de son outil de messagerie.

La supervision centrale. Pour suivre les tendances, corréler les hôtes avec le reste de l'infrastructure et déclencher des alertes sur des seuils, on raccorde Proxmox VE à l'outil de supervision de l'entreprise :

• Zabbix interroge l'API de Proxmox avec le modèle Proxmox VE by HTTP et un jeton en lecture seule (PVEAuditor, chapitre 11) : état des nœuds, des VM, des stockages, du cluster. L'agent Zabbix installé sur chaque hôte ajoute les mesures du système (disques, services) ;
• Grafana affiche des tableaux de bord à partir de Zabbix, ou des mesures que Proxmox exporte lui-même : Datacenter > Metric Server envoie en continu les statistiques des nœuds et des invités vers une base InfluxDB, un serveur Graphite ou, sur les versions récentes, un collecteur OpenTelemetry.

La mise en place de Zabbix, des modèles, des déclencheurs et des tableaux de bord Grafana est l'objet du cours Supervision, qui supervise justement Proxmox VE et TrueNAS et relie Grafana à Zabbix.

Exercices