Planification de capacité Proxmox : guide pratique avec exemples concrets

Introduction

La planification de capacité Proxmox est le processus d'estimation et de validation des ressources de calcul, de mémoire, de stockage et de réseau que vos machines virtuelles (VM) et conteneurs consommeront — et de s'assurer que vos hôtes Proxmox peuvent fournir ces ressources de manière fiable dans le temps. Sans approche systématique, vous risquez le surdimensionnement (gaspillage budgétaire) ou le sous-dimensionnement (dégradation des performances, plantages ou temps d'arrêt imprévus).

Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui exécutent Proxmox VE en production ou prévoient de le faire. Il se concentre sur la planification de capacité pratique et concrète à l'aide des outils natifs de Proxmox : l'interface web, l'API pvesh et les utilitaires en ligne de commande comme pveperf, qm et pct. Vous apprendrez à établir une référence de l'utilisation actuelle, à dimensionner de nouvelles charges de travail, à définir des limites raisonnables et à valider votre plan avant le déploiement.

Le principe fondamental est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des identifiants réels dans les exemples partagés, vérifier chaque résultat et documenter les étapes de récupération. À la fin, vous disposerez d'une liste de contrôle reproductible pour la planification de capacité dans tout environnement Proxmox.

1. Inventaire des versions et de l'environnement

Avant de pouvoir planifier la capacité, vous devez savoir exactement avec quoi vous travaillez. Les versions de Proxmox diffèrent par les fonctionnalités disponibles, les paramètres par défaut et les caractéristiques de performance. Commencez par collecter les informations suivantes sur chaque nœud de votre cluster :

• Version de Proxmox VE et statut du référentiel
• Modèle de CPU, nombre de cœurs et charge actuelle
• RAM totale et utilisée
• Types de stockage (LVM local, ZFS, Ceph, NFS, etc.), capacité et utilisation
• Vitesses des interfaces réseau et débit actuel
• Nombre et type de machines invitées en cours d'exécution (VM et conteneurs)

Commandes d'observation en lecture seule

Exécutez ces commandes sur un nœud Proxmox pour collecter une référence sans rien modifier :

# Version de Proxmox et informations sur le référentiel
pveversion -v

# Statut du cluster (si en cluster)
pvecm status

# Résumé CPU et mémoire
lscpu | grep -E 'Model name|CPU\(s\)|Thread|Core|Socket'
free -h

# Utilisation du stockage par pool
pvesm status

# Liste détaillée du stockage avec type et capacité
pvesh get /storage --output-format json

Exemple de sortie de pvesm status :

Name             Type     Status           Total            Used       Available        %
local             dir     active        98497780         3821376        89635012    3.88%
local-lvm     lvmthin     active      1073741824       268435456       805306368   25.00%
ceph-pool         rbd     active      21474836480      5368709120     16106127360   25.00%

Interprétation : local est le système de fichiers racine, local-lvm est le stockage LVM à provisionnement dynamique pour les disques de VM, et ceph-pool est un pool RBD si vous utilisez Ceph. La colonne % indique l'utilisation actuelle. Pour la planification de capacité, vous avez besoin à la fois de l'utilisation actuelle et de la tendance de croissance.

Prérequis et rayon d'impact

• Prérequis : Accès SSH au nœud avec un utilisateur ayant le rôle PVEAdmin ou au moins PVEAuditor pour les commandes en lecture seule. Pour les appels API pvesh, vous avez besoin d'un jeton API avec les autorisations appropriées (n'utilisez jamais le mot de passe root dans les scripts).
• Rayon d'impact : Ces commandes sont en lecture seule et sûres à exécuter à tout moment. Elles ne modifient pas la configuration et n'affectent pas les machines en cours d'exécution.
• Vérification : Après avoir exécuté chaque commande, confirmez que la sortie correspond à votre inventaire attendu. Par exemple, si vous attendez 128 Go de RAM mais que free -h affiche 64 Go, enquêtez avant de continuer.

Exemple : création d'un instantané de l'inventaire du nœud

Créez un script simple qui écrit la sortie de ces commandes dans des fichiers horodatés pour comparaison ultérieure :

#!/bin/bash
# inventory_snapshot.sh – à exécuter en tant que root sur chaque nœud Proxmox
DATE=$(date +%Y%m%d_%H%M%S)
OUTDIR=/var/log/proxmox-inventory
mkdir -p $OUTDIR

{
  echo "=== pveversion =="
  pveversion -v
  echo "=== lscpu =="
  lscpu
  echo "=== free -h =="
  free -h
  echo "=== pvesm status =="
  pvesm status
  echo "=== qm list =="
  qm list
  echo "=== pct list =="
  pct list
} > $OUTDIR/inventory_$DATE.txt

Planifiez ce script via cron pour qu'il s'exécute quotidiennement. Au fil du temps, vous disposerez de données historiques pour observer les tendances.

2. Chemin de configuration sûr

La planification de capacité implique souvent de modifier les allocations de ressources : ajouter des CPU, augmenter la RAM, étendre les disques ou ajuster les limites. Le « chemin de configuration sûr » signifie que vous effectuez des modifications de manière contrôlée et réversible.

Nommage des composants et plage de versions

Tous les exemples de ce guide sont pour Proxmox VE 7.x et 8.x. Les commandes peuvent différer légèrement dans les versions plus anciennes — consultez toujours la documentation officielle pour votre version spécifique.

Avant de modifier : enregistrez l'état actuel

Pour toute machine invitée (VM ou conteneur) que vous prévoyez de modifier, capturez sa configuration actuelle et son utilisation des ressources :

# Pour la VM avec l'ID 100
qm config 100
qm status 100 --verbose

# Pour le conteneur avec l'ID 101
pct config 101
pct status 101 --verbose

Exemple de sortie pour qm config 100 :

boot: order=scsi0;net0
cores: 2
memory: 4096
name: web-server
net0: virtio=BC:24:11:AA:BB:CC,bridge=vmbr0
scsi0: local-lvm:vm-100-disk-0,size=32G
sockets: 1

Plus petit changement justifié

Plutôt que de passer de 2 cœurs à 8, augmentez les ressources progressivement et mesurez l'impact. Par exemple, si une VM atteint constamment 100 % de CPU pendant les heures de pointe, l'ajout d'un cœur (ou le passage de 1 socket/2 cœurs à 1 socket/3 cœurs) peut suffire.

Exemple de modification : augmenter la RAM de la VM 100 de 4 Go à 6 Go

1. Observation : Utilisez qm status 100 --verbose pour confirmer l'allocation mémoire actuelle et l'utilisation réelle via qm guest cmd 100 summary (si l'agent invité est installé) ou la surveillance au niveau de l'hôte.
2. Prérequis : La VM doit être éteinte pour modifier la mémoire, sauf si le hotplug est activé. Vérifiez le support du hotplug : qm config 100 | grep hotplug. Si hotplug: 1 est présent, vous pouvez modifier la RAM en cours d'exécution.
3. Commande (modification hors ligne) :

   qm set 100 --memory 6144

Pour une modification en ligne avec hotplug :

   qm set 100 --memory 6144
   qm monitor 100 -c 'balloon 6144'   # si le ballooning est activé

1. Vérification :

   qm config 100 | grep memory
   # Devrait afficher memory: 6144
   qm status 100 --verbose | grep maxmem
   # Devrait refléter le nouveau maximum

1. Chemin de récupération : Revenez à la valeur d'origine :

   qm set 100 --memory 4096

Rayon d'impact et restauration

Lors de la modification du stockage, soyez particulièrement prudent. L'extension d'un disque est généralement irréversible (vous ne pouvez pas facilement réduire un disque), donc faites toujours un instantané avant les modifications si possible :

# Si vous utilisez ZFS ou LVM-thin, prenez un instantané du disque de la VM
qm snapshot 100 pre_resize_snapshot

Si la modification cause des problèmes, restaurez :

qm rollback 100 pre_resize_snapshot

3. Dimensionnement de nouvelles charges de travail : exemples concrets

La planification de capacité ne concerne pas seulement l'utilisation actuelle — elle consiste à prédire ce dont les nouvelles charges de travail auront besoin. Voici trois scénarios courants avec des chiffres concrets.

Exemple 1 : Dimensionnement d'une VM pour application web

Vous déployez un serveur web LAMP typique avec un trafic modéré. Sur la base des benchmarks ou de la documentation de votre application :

• CPU : Besoin estimé : 2 vCPU à une charge moyenne de 50 %. Règle empirique Proxmox : allouez 1 vCPU par cœur physique si possible, mais un surdimensionnement jusqu'à 2:1 est généralement sûr pour les charges non intensives en CPU. Donc 2 vCPU conviennent.
• RAM : Serveur web + MySQL + PHP : 2 Go pour le système d'exploitation, 2 Go pour le tampon MySQL, 1 Go pour les processus web/PHP. Total 5 Go, arrondissez à 6 Go.
• Stockage : Disque système 20 Go, application et journaux 10 Go, fichiers de base de données 30 Go. Total 60 Go. Avec le provisionnement dynamique LVM-thin, vous pouvez allouer 60 Go maintenant et étendre plus tard.
• Réseau : Pic attendu de 100 Mbps. La carte réseau Virtio peut gérer facilement le gigabit.

Commande de configuration Proxmox :

qm create 200 --name webapp --memory 6144 --cores 2 --sockets 1 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci \
  --scsi0 local-lvm:60,format=qcow2

Vérifiez : qm config 200 et assurez-vous que toutes les valeurs sont comme prévu.

Exemple 2 : Dimensionnement d'un serveur de base de données (PostgreSQL)

Les serveurs de base de données sont intensifs en RAM et en E/S de stockage. Supposons que vous ayez une base de données de 100 Go avec 200 transactions par seconde.

• RAM : PostgreSQL recommande shared_buffers ~25 % de la RAM. Pour un hôte de 64 Go, 16 Go de shared_buffers, plus 8 Go pour le système d'exploitation et les connexions, total 32 Go pour la VM.
• CPU : 8 vCPU pour gérer les requêtes simultanées (selon la charge de travail, 4 à 8 est typique).
• Stockage : Utilisez un stockage rapide (SSD ou NVMe). Allouez 200 Go pour permettre la croissance et les fichiers temporaires. Si vous utilisez Ceph RBD, assurez-vous que le pool a suffisamment d'IOPS.
• Limite d'E/S disque : Définissez une limite si le stockage est partagé pour éviter les problèmes de voisin bruyant :

  qm set 300 --drive scsi0,disk-iops-limit=5000

Création de la VM :

qm create 300 --name postgres --memory 32768 --cores 8 --sockets 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci \
  --scsi0 ceph-pool:200,format=raw

Exemple 3 : Dimensionnement d'un conteneur pour un microservice

Les conteneurs (LXC) sont plus légers que les VM. Pour un microservice Node.js avec des besoins modestes :

• CPU : 1 vCPU, mais autorisez les pics. Définissez la limite CPU à 50 % d'un cœur et autorisez 2 cœurs si nécessaire :

  pct set 400 --cores 2 --cpulimit 1

Ici --cores 2 donne accès à 2 cœurs, --cpulimit 1 limite le temps CPU total à 100 % d'un cœur.

• RAM : 512 Mo minimum, autorisez 256 Mo de swap :

  pct set 400 --memory 512 --swap 256

• Stockage : 5 Go de rootfs sur local-lvm.

Création avec :

pct create 400 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
  --hostname microservice --memory 512 --swap 256 --cores 2 --cpulimit 1 \
  --rootfs local-lvm:5 --net0 name=eth0,bridge=vmbr0,ip=dhcp

4. Formules et seuils de planification de capacité

Au-delà des VM individuelles, vous devez planifier au niveau de l'hôte et du cluster. Voici les formules clés et les seuils recommandés.

Ratio de surdimensionnement CPU

Cœurs physiques par rapport aux vCPU alloués. Surtaux maximal recommandé :

• Pour les charges de travail générales : 2:1 (par exemple, 32 cœurs physiques peuvent héberger 64 vCPU)
• Pour les charges intensives en CPU : 1:1 (pas de surdimensionnement)
• Pour les charges légères/inactives : 4:1 possible

Calculez le ratio actuel :

# Somme des vCPU alloués
sum_vcpus=$(qm list | awk '{print $3}' | grep -E '^[0-9]+$' | paste -sd+ | bc)
# Cœurs physiques
physical_cores=$(lscpu | grep '^CPU(s):' | awk '{print $2}')
echo "vCPU alloués : $sum_vcpus, Cœurs physiques : $physical_cores, Ratio : $(echo "scale=2; $sum_vcpus/$physical_cores" | bc)"

Maintenez ce ratio en dessous de votre seuil choisi. Par exemple, si 32 cœurs physiques et 48 vCPU alloués, ratio = 1,5, ce qui est acceptable pour les charges générales.

Surdimensionnement de la mémoire

Proxmox permet le surdimensionnement de la mémoire, mais vous devez surveiller l'utilisation réelle. L'hôte doit toujours avoir au moins 10 à 20 % de RAM libre plus la marge pour la surcharge de virtualisation (généralement 1 à 2 Go par hôte, plus 200 à 500 Mo par VM).

Vérifiez la pression mémoire de l'hôte :

free -h
cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'

Si MemAvailable tombe en dessous de 10 % du total, vous êtes à risque.

Capacité et croissance du stockage

Planifiez la capacité de stockage avec une marge. Une formule simple :

Capacité requise = Utilisation actuelle + (Croissance annuelle projetée × 1,5) + tampon de 20 %

Par exemple, si l'utilisation actuelle des disques de VM est de 2 To, la croissance annuelle de 500 Go, alors :

• Besoin supplémentaire l'année prochaine : 500 Go × 1,5 = 750 Go
• Tampon : 20 % de (2 To + 750 Go) = 550 Go
• Capacité totale : 2 To + 750 Go + 550 Go = 3,3 To
• Arrondissez à la taille de la matrice RAID (par exemple, 4 To utilisables).

Planification de la bande passante réseau

Estimez le débit réseau de pointe pour toutes les machines invitées. Par exemple, 10 VM nécessitant chacune 100 Mbps = 1 Gbps agrégé. Votre carte réseau hôte doit supporter au moins cela, plus la surcharge. Agrégez plusieurs cartes réseau si nécessaire.

5. Surveillance et tendances pour la planification de capacité

La planification de capacité est un processus continu, pas un événement ponctuel. Mettez en place une surveillance pour collecter des données historiques et alerter sur les tendances.

Surveillance intégrée de Proxmox

Proxmox fournit des graphiques RRD dans l'interface web (par nœud et par machine invitée). Pour les tendances à long terme, utilisez un système externe comme Prometheus + Grafana. Proxmox expose les métriques via l'API.

Activation de l'exportateur de métriques intégré (facultatif)

Proxmox 8 peut envoyer des métriques à InfluxDB ou Prometheus. Configurez dans /etc/pve/status.cfg pour utiliser InfluxDB :

influxdb: influxdb
  server 10.0.0.5
  port 8089
  protocol udp

Puis redémarrez pvestatd. Pour Prometheus, utilisez l'exportateur externe prometheus-pve-exporter.

Exemple de requête Prometheus pour la capacité

Si vous utilisez l'exportateur PVE, vous pouvez interroger :

# Pourcentage d'utilisation du CPU de l'hôte
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Pourcentage de mémoire disponible
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Définissez des alertes lorsque ces valeurs franchissent les seuils (par exemple, CPU > 85 % pendant 15 minutes, mémoire disponible < 10 %).

Analyse des journaux et des performances

Utilisez iostat, vmstat et sar sur l'hôte pour identifier les goulots d'étranglement d'E/S :

iostat -x 1 5
vmstat 1 5

Si la latence de stockage (await) est constamment élevée (>20 ms pour HDD, >5 ms pour SSD), vous pourriez avoir besoin de disques plus rapides ou d'un réglage Ceph.

6. Modes de défaillance et récupération

La planification de capacité doit tenir compte des défaillances. Voici les modes de défaillance courants et comment s'y préparer.

Mémoire insuffisante (OOM) sur l'hôte

Symptôme : L'hôte devient non réactif, les VM sont tuées aléatoirement. Proxmox utilise le tueur OOM lorsque la mémoire de l'hôte est épuisée.

Prévention :

• Activez le ballooning mémoire sur les VM.
• Définissez des garanties de mémoire minimales pour les VM critiques.
• Assurez-vous que le ratio de surdimensionnement de la mémoire de l'hôte n'est pas trop élevé.

Détection :

dmesg | grep -i 'out of memory'
journalctl -k | grep -i oom

Récupération :

• Éteignez les VM non critiques pour libérer de la mémoire.
• Augmentez la RAM de l'hôte (changement matériel).
• Ajustez les allocations de mémoire des VM pour réduire le surdimensionnement.

Disque plein sur le pool de stockage

Symptôme : Les VM ne peuvent pas écrire, erreurs ENOSPC dans l'invité, Proxmox peut mettre en pause les VM.

Prévention :

• Surveillez l'utilisation du stockage et définissez des alertes à 80 %.
• Utilisez le provisionnement dynamique avec prudence ; suivez l'utilisation réelle.
• Planifiez un nettoyage régulier des instantanés, des sauvegardes et des images ISO.

Détection :

pvesm status

Si un pool est rempli à plus de 80 %, agissez.

Récupération :

• Supprimez les anciens instantanés : qm delsnapshot <vmid> <snapname>
• Déplacez les disques vers un autre stockage : qm move-disk <vmid> <disk> <target-storage>
• Étendez le stockage sous-jacent (ajoutez des disques à LVM/ZFS, étendez les OSD Ceph).

Saturation du réseau

Symptôme : Latence élevée, perte de paquets, réseau de VM lent.

Prévention :

• Utilisez des réseaux séparés pour le stockage (Ceph) et le trafic des VM.
• Surveillez le débit de la carte réseau.

Détection :

iftop -i vmbr0

Récupération :

• Déplacez les VM lourdes vers différents hôtes.
• Ajoutez l'agrégation de cartes réseau ou passez au 10G.

Famine CPU

Symptôme : VM lentes, charge moyenne de l'hôte élevée.

Détection :

uptime
top

Si la charge moyenne dépasse les cœurs physiques pendant une période prolongée, vous êtes surdimensionné.

Récupération :

• Réduisez le nombre de vCPU sur les VM de faible priorité.
• Migrez les VM vers des hôtes moins chargés.
• Ajoutez plus de cœurs physiques (si possible).

7. Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après avoir apporté des modifications de capacité pour garantir la sécurité et la cohérence.

Avant toute modification

• [ ] Enregistrez l'état actuel du nœud et des machines invitées (commandes de la section 1).
• [ ] Confirmez la version de Proxmox et notez tout comportement spécifique à la version.
• [ ] Identifiez la ressource exacte à modifier (CPU, RAM, disque, réseau).
• [ ] Calculez la nouvelle valeur en fonction du besoin observé et de la marge.
• [ ] Vérifiez les ratios de surdimensionnement actuels (CPU, mémoire) pour vous assurer que l'ajout ne dépassera pas le seuil.
• [ ] Si vous modifiez le disque, créez un instantané si possible.
• [ ] Documentez la commande de restauration et la valeur d'origine.
• [ ] Planifiez une fenêtre de maintenance si un redémarrage est nécessaire.

Pendant la modification

• [ ] Exécutez la commande de modification (par exemple, qm set) et notez la sortie.
• [ ] Si vous utilisez l'interface web, vérifiez les valeurs avant d'appliquer.

Après la modification

• [ ] Vérifiez la nouvelle configuration avec des commandes en lecture seule (par exemple, qm config).
• [ ] Surveillez la machine invitée pendant une période raisonnable (au moins 15 minutes sous charge) pour confirmer l'amélioration.
• [ ] Vérifiez les métriques au niveau de l'hôte pour vous assurer qu'il n'y a pas d'impact négatif sur les autres machines invitées.
• [ ] Mettez à jour la documentation et les seuils de surveillance si nécessaire.
• [ ] Si la modification a causé des problèmes, restaurez immédiatement en utilisant le chemin de récupération documenté.

Exemple de déroulement de liste de contrôle pour une augmentation de RAM

1. Enregistrement de l'état :

   qm config 100 | tee /root/vm100_before.txt
   qm status 100 --verbose | tee /root/vm100_status_before.txt

1. Modification :

   qm set 100 --memory 8192

1. Vérification :

   qm config 100 | grep memory
   # Attendu : memory: 8192

1. Surveillance : Utilisez l'interface web ou qm monitor pour observer l'utilisation de la mémoire.
2. Restauration si nécessaire :

   qm set 100 --memory 4096

8. Planification de capacité avancée avec Ceph

Si vous utilisez Proxmox avec le stockage hyperconvergé Ceph, la planification de capacité s'étend au dimensionnement des OSD et aux groupes de placement des pools.

Planification de la capacité des OSD

Nombre d'OSD nécessaires = (Capacité totale requise après réplication) / (capacité utilisable par OSD).

Exemple : Vous avez besoin de 10 To utilisables avec une réplication 3x. Capacité brute = 30 To. Si chaque disque OSD fait 4 To, vous avez besoin de 30/4 ≈ 8 OSD, mais tenez compte des domaines de défaillance des nœuds : généralement un minimum de 3 nœuds, avec au moins 4 OSD par nœud pour les performances. Donc 3 nœuds × 4 OSD = 12 OSD, fournissant 48 To bruts, 16 To utilisables (après réplication 3x).

Réseau pour Ceph

Le réseau de cluster Ceph doit être d'au moins 10 Gbps dédié. Séparez-le du trafic des VM pour éviter la contention.

Surveillance de la capacité Ceph

Utilisez ceph df pour vérifier l'utilisation :

ceph df

La sortie montre RAW et USED, et POOLS avec USED et MAX AVAIL. Maintenez l'utilisation du pool en dessous de 75 % pour éviter les problèmes de rééquilibrage.

9. Considérations de sauvegarde et de récupération dans la planification de capacité

Les sauvegardes consomment de l'espace de stockage et des cycles CPU. Incluez le volume de sauvegarde dans votre plan de capacité.

Estimation de l'espace de sauvegarde

Si vous exécutez des sauvegardes nocturnes de toutes les VM (en utilisant vzdump), vous avez besoin de suffisamment de stockage pour au moins un ensemble complet de sauvegardes, plus les modifications incrémentielles si vous utilisez PBS (Proxmox Backup Server).

Exemple : 10 VM, utilisation moyenne du disque de 50 Go chacune = 500 Go. Sauvegardes complètes quotidiennes avec conservation de 7 jours = 3,5 To. La déduplication dans PBS peut réduire cela considérablement, mais planifiez pour le pire des cas.

Placez les sauvegardes sur un stockage séparé (NFS, serveur de sauvegarde dédié) pour éviter d'impacter le stockage de production.

Planification des sauvegardes et charge d'E/S

Planifiez les sauvegardes pendant les heures creuses. vzdump peut être intensif en CPU et en E/S. Utilisez --ionice et --bwlimit pour limiter l'impact :

vzdump 100 --mode snapshot --compress zstd --storage backup-nfs \
  --ionice 7 --bwlimit 102400

Cela limite les E/S de sauvegarde à 100 Mo/s (102400 Ko/s) et utilise une priorité d'E/S faible.

10. Référence rapide des outils et commandes

Voici un résumé des commandes essentielles pour la planification de capacité dans Proxmox.

Conclusion

La planification de capacité Proxmox est une discipline itérative : mesurez, modélisez, implémentez et surveillez. En suivant les pratiques de ce guide — en commençant par un inventaire approfondi de l'environnement, en utilisant des modifications de configuration sûres, en dimensionnant les nouvelles charges de travail avec des exemples concrets, en surveillant les tendances et en se préparant aux défaillances — vous pouvez maintenir une infrastructure de virtualisation stable et efficace.

Points clés à retenir :

• Observez toujours l'état actuel avant de faire des modifications.
• Utilisez des commandes adaptées à la version et des espaces réservés dans les scripts.
• Calculez les ratios de surdimensionnement et maintenez-les dans des limites sûres.
• Planifiez le stockage avec croissance et tampon.
• Implémentez la surveillance et les alertes pour le CPU, la mémoire, le stockage et le réseau.
• Documentez les procédures de restauration pour chaque modification.
• Considérez les scénarios avancés comme Ceph et le stockage de sauvegarde dans votre plan de capacité.

Comme prochaine étape, choisissez une tâche de vérification à faible risque de ce guide — par exemple, exécutez pvesm status et vérifiez votre utilisation du stockage par rapport au seuil de 80 %, ou calculez votre ratio actuel de surdimensionnement CPU. Enregistrez l'état actuel, exécutez la vérification et comparez le résultat avec le signal attendu. Ensuite, utilisez cette information pour apporter un petit ajustement bien documenté.

Un processus de planification de capacité fiable rend l'épuisement des ressources visible avant qu'il ne devienne un incident, et vous donne la confiance nécessaire pour faire évoluer votre environnement Proxmox en toute sécurité.