Architecture de Proxmox expliquée avec des exemples pratiques

Introduction

Proxmox Virtual Environment (VE) est une plateforme open source qui combine virtualisation, conteneurisation, stockage logiciel et réseau dans un système unique basé sur Debian. Pour les développeurs, consultants DevOps et équipes techniques de startup, comprendre son architecture est essentiel pour construire une infrastructure fiable et observable.

Cet article explique l'architecture de Proxmox à travers des exemples pratiques. Il relie les composants essentiels, le flux de données, les décisions de conception et les tâches opérationnelles à des commandes, des sorties attendues, des signaux de défaillance et des étapes de récupération. L'accent est mis sur la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des variables à la place des secrets, vérifier les résultats et documenter les chemins de récupération.

Nous aborderons l'inventaire de version et d'environnement, la configuration sécurisée, la vérification et le diagnostic, les modes de défaillance et la récupération, une liste de contrôle opérationnelle et les pièges courants. Chaque section comprend des commandes concrètes, des extraits de configuration et des sorties attendues afin que vous puissiez appliquer directement les conseils à votre environnement.

Inventaire de version et d'environnement

Avant tout changement, vous devez comprendre votre déploiement Proxmox : version, topologie du cluster, stockage et réseau. Cette section montre comment collecter ces informations en toute sécurité.

Identifier la version installée

Exécutez la commande suivante sur n'importe quel nœud Proxmox pour voir la version et le noyau :

pveversion --verbose

Sortie attendue (tronquée) :

proxmox-ve: 8.2.0 (running kernel: 6.8.4-2-pve)
pve-manager: 8.2.2 (running version: 8.2.2/abcd1234)
pve-kernel-6.8.4-2-pve: 6.8.4-2
ceph: 18.2.1-pve2

Cela indique la version majeure de Proxmox VE (8.2), le noyau et si Ceph est installé. Utilisez toujours la documentation correspondant à votre version majeure, car les commandes et les valeurs par défaut peuvent différer.

Inspecter la topologie du cluster

Si vos nœuds sont dans un cluster, vérifiez l'appartenance et la santé :

pvecm status

Sortie attendue en cas de bon fonctionnement :

Quorum information
------------------
Date:             Mon Apr 14 10:15:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1a
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.10.11 (local)
0x00000002          1 192.168.10.12
0x00000003          1 192.168.10.13

Signaux clés : Quorate: Yes signifie que le cluster possède le quorum. Si Quorate: No, le cluster ne peut pas effectuer de modifications et vous devez enquêter avant de continuer.

Capturer la configuration du stockage

Listez les stockages configurés et leurs types :

pvesm status

Exemple de sortie :

Name             Type     Status           Total            Used       Available        %
local             dir     active        98497780         4795172        93692608    4.87%
local-lvm     lvmthin     active       536870912        12582912       524288000    2.34%
ceph-pool         rbd     active      1099511627776    109951162777    989855829999   10.00%

Cela montre trois types de stockage : répertoire, LVM thin et Ceph RBD. Chacun a des capacités de performance et de snapshot différentes, ce qui affecte le placement des VM et la stratégie de sauvegarde.

Vérifier les interfaces réseau et les ponts

Consultez la configuration réseau :

cat /etc/network/interfaces

Configuration de pont typique pour la connectivité des VM :

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.11/24
        gateway 192.168.10.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Notez le nom du pont (vmbr0) et le port physique (eno1). Les VM se connectent à ce pont pour l'accès réseau externe.

Exemple de modification sécurisée : mise à jour d'un paquet

Après avoir observé l'état actuel, une modification minimale pourrait être la mise à jour d'un seul paquet. D'abord, vérifiez les mises à jour disponibles :

apt list --upgradable

Si vous décidez de mettre à jour uniquement pve-manager :

apt update && apt install --only-upgrade pve-manager

Avant d'exécuter, assurez-vous d'avoir une sauvegarde récente des VM critiques et notez la version exacte du paquet. Après la mise à jour, vérifiez :

pveversion | grep pve-manager

La sortie attendue affiche la nouvelle version. En cas d'échec, vous pouvez revenir en arrière en réinstallant la version précédente depuis les dépôts Proxmox ou en restaurant à partir d'un instantané si vous en avez pris un (voir Modes de défaillance et récupération).

Chemin de configuration sécurisé

La configuration de Proxmox s'étend sur de nombreux fichiers et commandes. Cette section fournit un chemin sûr vers les modifications courantes, en mettant l'accent sur la séparation entre observation et intervention.

Configurer une nouvelle VM ou un conteneur

La création d'une VM implique plusieurs étapes. Utilisez l'interface en ligne de commande pour la reproductibilité :

D'abord, vérifiez les ressources disponibles sur un nœud :

   pvesh get /nodes/proxmox01/status

Recherchez l'utilisation de memory et cpu pour vous assurer de la capacité.

Créez une VM avec l'ID 100, 2 cœurs CPU, 4 Go de RAM et un disque de 32 Go sur local-lvm :

   qm create 100 --name web-server --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --scsi0 local-lvm:32

Sortie attendue : aucune (succès). Vérifiez :

   qm config 100

Cela affiche la configuration de la VM. Vérifiez que memory: 4096, cores: 2 et net0 sont conformes.

Si vous devez modifier un paramètre ultérieurement, utilisez qm set :

   qm set 100 --memory 8192

Rayon d'impact : affecte uniquement la VM 100. Si la VM est en cours d'exécution, l'ajout à chaud de mémoire peut nécessiter le support du système invité ; sinon, un arrêt est requis.

Modifications de la configuration réseau

Modifier directement /etc/network/interfaces est risqué. Utilisez plutôt ifreload -a après avoir effectué et validé les modifications :

nano /etc/network/interfaces   # effectuez les modifications, assurez-vous que la syntaxe est correcte
ifreload -a                   # appliquez les modifications

Gardez toujours une copie de sauvegarde avant de modifier :

cp /etc/network/interfaces /etc/network/interfaces.bak.$(date +%Y%m%d)

Si le réseau échoue après le rechargement, restaurez à partir de la sauvegarde et relancez ifreload -a.

Configuration du stockage

Ajouter un nouveau backend de stockage, tel que NFS, nécessite de modifier /etc/pve/storage.cfg. Sauvegardez toujours d'abord :

cp /etc/pve/storage.cfg /etc/pve/storage.cfg.bak

Ajoutez un partage NFS :

pvesm add nfs my-nfs --server 192.168.10.50 --export /data

Vérifiez :

pvesm status

Vérifiez que my-nfs apparaît et est actif. Si le serveur NFS est injoignable, le statut affichera inactif et les VM utilisant ce stockage pourraient ne pas démarrer.

Utiliser des variables dans les exemples

Dans toutes les commandes, remplacez les valeurs réelles par des variables lors de la documentation. Par exemple, au lieu de :

qm create 100 --name web-server --memory 4096 ...

écrivez :

qm create <vmid> --name <vm-name> --memory <memory-mb> ...

Cela empêche une exécution accidentelle avec de mauvaises valeurs et protège les informations sensibles.

Vérification et diagnostic

Après avoir effectué des modifications, la vérification est cruciale. Proxmox propose plusieurs outils de diagnostic.

Vérifier le statut et les journaux des VM

Pour voir si une VM est en cours d'exécution :

qm status 100

Sortie attendue lorsqu'elle est en cours d'exécution :

status: running

Si elle ne tourne pas, démarrez-la :

qm start 100

Ensuite, vérifiez le journal des tâches :

qm status 100 --verbose

Ou consultez les tâches récentes :

pvesh get /nodes/proxmox01/tasks?limit=10

Cela renvoie du JSON avec les identifiants et statuts des tâches, utile pour déboguer les opérations échouées.

Vérifications de santé du stockage

Pour le stockage local, vérifiez l'utilisation du disque :

df -h

Pour Ceph, vérifiez la santé du cluster :

ceph -s

Sortie Ceph saine :

  cluster:
    id:     abc123
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum proxmox01,proxmox02,proxmox03
    mgr: proxmox01(active), standbys: proxmox02, proxmox03
    osd: 6 osds: 6 up, 6 in

  data:
    pools:   2 pools, 128 pgs
    objects: 12.34k objects, 45 GiB
    usage:   135 GiB used, 1.1 TiB / 1.2 TiB avail

Recherchez HEALTH_OK. Tout autre statut (par exemple, HEALTH_WARN) nécessite une enquête.

Diagnostics réseau

Testez la connectivité depuis une VM ou un nœud :

ping -c 4 192.168.10.1

Vérifiez l'appartenance au pont :

brctl show vmbr0

La sortie attendue liste les interfaces attachées au pont, y compris tap100i0 pour la VM 100.

Surveiller le quorum du cluster

Exécutez régulièrement pvecm status. Si le quorum est perdu, consultez les journaux de Corosync :

journalctl -u corosync -n 50

Recherchez des erreurs comme TOTEM: Retransmit List indiquant des problèmes réseau.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à réagir rapidement et en toute sécurité.

Défaillance d'un nœud et haute disponibilité

Si un nœud tombe en panne dans un cluster à haute disponibilité (HA), les VM gérées par HA migrent vers d'autres nœuds. Vérifiez le statut HA :

ha-manager status

La sortie attendue montre le statut du service et le nœud actuel. Si une VM n'a pas migré, vérifiez les ressources HA :

ha-manager config

Ensuite, migrez manuellement une VM :

qm migrate 100 proxmox02 --online

Pour les conteneurs :

pct migrate 101 proxmox02

Vérifiez toujours que la VM fonctionne sur le nouveau nœud :

qm status 100

Stockage plein ou indisponible

Si le stockage local se remplit, les VM peuvent se mettre en pause ou échouer en écriture. Vérifiez l'utilisation :

df -h /var/lib/vz

S'il est plein, identifiez les gros fichiers :

du -sh /var/lib/vz/images/*

Vous pouvez supprimer les images disque inutilisées, mais assurez-vous d'abord qu'aucune VM ne les référence. Déplacez le disque d'une VM vers un autre stockage :

qm move-disk 100 scsi0 other-storage

Si le stockage est indisponible (par exemple, NFS en panne), les VM peuvent se bloquer. Vérifiez le statut du stockage :

pvesm status

Rétablissez la connexion NFS, puis redémarrez les VM affectées.

Fichier de configuration corrompu

Si /etc/pve/storage.cfg est corrompu, Proxmox peut ne pas démarrer les services. Restaurez à partir de la sauvegarde :

cp /etc/pve/storage.cfg.bak /etc/pve/storage.cfg
systemctl restart pvedaemon pveproxy

Vérifiez avec pvesm status.

Panne réseau et récupération

Si une mauvaise configuration du pont coupe l'accès au nœud, connectez-vous via la console (IPMI, physique ou hors bande) et restaurez la configuration réseau à partir de la sauvegarde. Ensuite, exécutez ifreload -a.

Liste de contrôle opérationnelle

Utilisez cette liste pour les opérations de routine et avant d'effectuer des modifications. Attribuez un responsable (par exemple, le responsable de l'infrastructure) pour assurer la responsabilité et révisez chaque semaine.

[ ] Vérifier la version de Proxmox et le quorum du cluster avec pveversion et pvecm status (Responsable : responsable de l'infrastructure, hebdomadaire)
[ ] Vérifier la santé et l'utilisation du stockage avec pvesm status et df -h (Responsable : administrateur stockage, quotidien)
[ ] Examiner les travaux de sauvegarde et tester la restauration d'une VM ou d'un conteneur (Responsable : opérateur de sauvegarde, mensuel)
[ ] Surveiller les journaux pour détecter les erreurs avec journalctl -p err et l'historique des tâches Proxmox (Responsable : équipe de surveillance, quotidien)
[ ] Valider la configuration réseau et l'état du pont avant les modifications (Responsable : ingénieur réseau, à chaque modification)
[ ] Documenter toute modification manuelle dans un journal des modifications avec plan de retour en arrière (Responsable : gestionnaire des changements, à chaque modification)
[ ] Effectuer un exercice de reprise après sinistre pour une défaillance de nœud chaque trimestre (Responsable : responsable de l'infrastructure, trimestriel)

Chaque élément doit avoir un script ou une commande de vérification, une sortie attendue claire et une personne responsable de résoudre les écarts.

Pièges courants et comment les éviter

Dans les déploiements réels, plusieurs erreurs se reproduisent. Voici les plus fréquentes et comment les éviter.

1. Ignorer les incompatibilités de version

Pourquoi cela arrive : les équipes mélangent la documentation de Proxmox 7 et 8, ou utilisent des commandes obsolètes. Comment éviter : vérifiez toujours pveversion et consultez le wiki officiel pour la version exacte. Testez les commandes dans un environnement de préproduction.

2. Utiliser le stockage par défaut pour les VM de production

Pourquoi cela arrive : le stockage local (répertoire) est simple mais manque de support des instantanés et peut se remplir rapidement. Comment éviter : utilisez local-lvm (provisionnement dynamique, instantanés) ou Ceph pour la production. Planifiez la capacité et surveillez l'utilisation.

3. Modifier la configuration réseau sans sauvegarde

Pourquoi cela arrive : des modifications rapides de /etc/network/interfaces sans sauvegarde entraînent un verrouillage du nœud. Comment récupérer : conservez des sauvegardes horodatées et utilisez ifreload -a après avoir validé la syntaxe. En cas de verrouillage, utilisez l'accès console pour restaurer.

4. Ne pas tester les sauvegardes

Pourquoi cela arrive : les travaux de sauvegarde semblent réussir, mais les restaurations ne sont jamais testées. Comment éviter : restaurez régulièrement une VM ou un conteneur de test à partir de la sauvegarde vers un nœud non productif. Automatisez avec des scripts.

5. Négliger les exigences de quorum du cluster

Pourquoi cela arrive : les clusters à deux nœuds avec un nœud en panne perdent le quorum et gèlent les opérations. Comment éviter : utilisez un périphérique de quorum (QDevice) ou un cluster à trois nœuds. Pour les configurations à deux nœuds, ajoutez un QDevice sur un petit hôte externe.

6. Coder en dur les secrets dans les scripts

Pourquoi cela arrive : la commodité conduit à mettre des mots de passe dans les scripts ou les configurations. Comment éviter : utilisez des jetons API Proxmox avec des permissions limitées, ou des variables d'environnement avec une gestion des secrets. Ne commitez jamais de secrets dans un contrôle de version.

Conclusion

L'architecture de Proxmox se comprend mieux par la pratique avec un fort accent sur la sécurité et la vérification. En suivant les méthodes de cet article, vous pouvez exploiter Proxmox en toute confiance : observer l'état actuel, effectuer des modifications minimales, vérifier les résultats et récupérer après des défaillances.

Commencez par une tâche de vérification à faible risque : vérifiez votre version de Proxmox et le quorum du cluster, puis examinez la santé du stockage. Documentez l'état actuel, exécutez les vérifications et comparez les résultats avec les sorties attendues. Progressez ensuite vers des opérations plus complexes, en gardant toujours la récupération à l'esprit.

Un flux de travail fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications aux ressources prévues et définit la vérification de la récupération avant qu'un incident ne force la décision. Avec ces pratiques, Proxmox devient une base robuste pour votre infrastructure virtualisée.