Guide Complet d'Architecture Proxmox - PME & Grande Entreprise
Architecture Proxmox détaillée pour PME et grande entreprise : cluster, Corosync, migration live, stockage, PRA, sécurité et maintenance.
Guide Complet d'Architecture Proxmox
PME & Grande Entreprise
PARTIE 1 — FONDAMENTAUX PROXMOX VE
Qu'est-ce que Proxmox VE ?
Proxmox Virtual Environment (PVE) est une plateforme de virtualisation open-source basée sur Debian Linux. Elle intègre deux technologies de virtualisation complémentaires :
- KVM (Kernel-based Virtual Machine) : hyperviseur de type 1 pour les machines virtuelles complètes (Windows, Linux). Chaque VM dispose de son propre noyau, de son propre espace mémoire isolé et de ses ressources CPU virtualisées.
- LXC (Linux Containers) : conteneurs système légers partageant le noyau de l'hôte Proxmox. Idéal pour les workloads Linux nécessitant moins d'isolation mais plus de densité.
Proxmox s'administre via une interface web HTTPS (port 8006) ou via l'API REST, accessible sur chaque nœud et centralisée sur le cluster.
Le Cluster Proxmox — Concepts Fondamentaux
Corosync : le cœur du cluster
Corosync est le moteur de communication du cluster. Il assure :
- La diffusion des messages entre nœuds via un réseau dédié (réseau de cluster, distinct du réseau de production). Ce réseau utilise le protocole UDP multicast ou unicast sur le port 5405.
- Le heartbeat : chaque nœud envoie régulièrement des signaux aux autres pour confirmer qu'il est vivant. Si un nœud ne répond plus dans le délai configuré (token timeout), le cluster le considère comme défaillant.
- Le quorum : mécanisme de vote qui détermine si le cluster est en capacité de fonctionner. Pour qu'un cluster soit opérationnel, il faut obtenir la majorité absolue des votes (quorum = nombre de nœuds / 2 + 1). Avec 3 nœuds, le quorum est de 2. Si un nœud tombe, les 2 restants ont toujours le quorum et continuent à fonctionner. Si 2 nœuds tombent, le dernier n'a pas le quorum et se met en pause pour éviter un split-brain.
pmxcfs : le système de fichiers du cluster
Proxmox utilise un système de fichiers distribué spécifique appelé pmxcfs (Proxmox Cluster File System). Il est monté sur /etc/pve sur chaque nœud et contient :
- La configuration de toutes les VM et conteneurs
- Les certificats SSL du cluster
- La configuration des storages
- Les ACL et permissions utilisateurs
pmxcfs est synchronisé en temps réel entre tous les nœuds via Corosync. Toute modification de configuration sur un nœud est immédiatement répliquée sur l'ensemble du cluster. Ce système est basé sur SQLite localement et se synchronise via le réseau Corosync.
Le réseau dédié cluster (Corosync Network)
Il est fortement recommandé d'isoler le trafic Corosync sur un réseau dédié, distinct du réseau de production et du réseau de stockage. Ce réseau doit être :
- Faible latence : idéalement des liens directs ou un VLAN dédié sur une stack de switches
- Haute disponibilité : bonding ou LACP pour éviter une coupure réseau qui ferait perdre le quorum
- Séparé du stockage : le trafic Corosync est léger mais critique, il ne doit pas être impacté par la saturation du réseau SAN
High Availability (HA) Manager
Le gestionnaire HA de Proxmox surveille en permanence l'état des VM et conteneurs marqués comme hautement disponibles. Son fonctionnement :
- LRM (Local Resource Manager) : daemon sur chaque nœud qui exécute les ordres du cluster manager (démarrer, arrêter, migrer une VM).
- CRM (Cluster Resource Manager) : cerveau central qui décide des actions à entreprendre en cas de défaillance. Il ne s'exécute que sur le nœud élu maître.
- Watchdog : mécanisme matériel ou logiciel (softdog) qui, si le nœud ne reçoit plus d'instructions du cluster, déclenche un fence (redémarrage forcé) du nœud défaillant. Cela garantit qu'une VM ne tourne jamais sur deux nœuds simultanément (split-brain).
Quand un nœud tombe, le CRM détecte l'absence de heartbeat Corosync, attend la confirmation du fence du nœud défaillant, puis redémarre les VM HA sur les nœuds survivants.
Migration Live (Live Migration)
Proxmox supporte la migration à chaud des VM d'un nœud à l'autre sans interruption de service. Le processus :
- La mémoire RAM de la VM est copiée en continu vers le nœud cible (pré-copie).
- Une fois que le taux de changement de pages mémoire est suffisamment faible, la VM est brièvement suspendue (quelques dizaines de millisecondes à quelques secondes selon la charge).
- L'état final de la mémoire est transféré.
- La VM reprend sur le nœud cible.
Pour que la migration live fonctionne, le stockage des disques VM doit être partagé entre les nœuds (SAN, Ceph, NFS) ou la migration doit inclure le transfert des disques (migration avec stockage local, plus longue).
Le réseau virtuel dans Proxmox
Proxmox gère les interfaces réseau des VM via :
- Linux Bridge (vmbr) : bridge logiciel Linux auquel sont connectées les interfaces virtuelles des VM. C'est le mode le plus simple et le plus courant.
- Open vSwitch (OVS) : pour des besoins de réseau plus avancés (VLANs, bonding, tunnels VXLAN).
- SDN (Software Defined Networking) : fonctionnalité avancée de Proxmox permettant de créer des réseaux virtuels, VNets, zones réseau avec isolation complète entre tenants.
Chaque VM dispose d'une ou plusieurs interfaces réseau virtuelles (VirtIO, E1000) connectées à un bridge Linux, lui-même connecté à une interface physique du nœud ou à un VLAN taggé.
Le stockage dans Proxmox
Proxmox supporte de nombreux backends de stockage :
| Type | Usage | Partage entre nœuds |
|---|---|---|
| LVM / LVM-Thin | Disques locaux | Non |
| ZFS | Disques locaux avec snapshots | Non (ou ZFS over iSCSI) |
| Directory | Répertoire local | Non |
| NFS | Partage NFS | Oui |
| CIFS/SMB | Partage Windows | Oui |
| iSCSI + LVM | SAN iSCSI | Oui |
| Ceph RBD | Stockage distribué natif | Oui (natif Proxmox) |
| GlusterFS | Stockage distribué | Oui |
Pour les clusters HA, le stockage partagé est indispensable : les VM doivent être accessibles depuis n'importe quel nœud pour permettre la migration et le failover automatique.
PARTIE 2 — ARCHITECTURE PME (3 NŒUDS PROXMOX)
Vue d'ensemble
Cette architecture cible une PME de 50 à 200 utilisateurs nécessitant une infrastructure virtualisée résiliente, sans complexité excessive. Elle repose sur un cluster Proxmox à 3 nœuds avec stockage SAN partagé, permettant la haute disponibilité des services critiques.
Infrastructure physique et réseau
Stack de switches LAN
La stack LAN est composée de deux switches (ou plus) configurés en stack physique (agrégation de châssis). Cette stack présente un seul plan de contrôle logique tout en offrant de la redondance matérielle.
Rôle : transport du trafic de production (réseau des utilisateurs, réseau des serveurs, accès internet, VLAN de management).
Organisation en VLANs :
- VLAN Management (ex. VLAN 10) : interfaces de management des nœuds Proxmox, switches, firewalls. Trafic d'administration uniquement.
- VLAN Cluster (ex. VLAN 20) : trafic Corosync entre les nœuds Proxmox. Isolé pour garantir la fiabilité du heartbeat.
- VLAN Serveurs (ex. VLAN 30) : réseau de production des VM serveurs (AD, Exchange, fichiers...).
- VLAN Utilisateurs (ex. VLAN 40) : réseau des postes clients.
- VLAN DMZ (ex. VLAN 50) : serveurs exposés (web, mail relay).
Chaque nœud Proxmox est connecté à la stack LAN via des liens en LACP (802.3ad) pour combiner bande passante et redondance. En cas de défaillance d'un uplink, le trafic bascule automatiquement sur le lien restant.
Stack de switches SAN
La stack SAN est un réseau entièrement dédié au stockage. Elle est physiquement séparée du réseau LAN pour deux raisons :
- Performance : le trafic de stockage (lecture/écriture des disques VM) est intense et ne doit pas concurrencer le trafic de production.
- Isolation : une tempête de broadcast ou un problème sur le LAN ne doit pas impacter le stockage, ce qui causerait des interruptions de VM.
Cette stack utilise des interfaces 10GbE ou 25GbE sur les nœuds Proxmox et la baie de stockage.
Protocoles supportés :
- iSCSI : protocole SCSI over TCP/IP. La baie de stockage expose des LUNs iSCSI que les nœuds Proxmox initient via le logiciel open-iscsi. Proxmox voit ces LUNs comme des blocs bruts sur lesquels il crée des groupes de volumes LVM partagés.
- NFS : protocole de partage de fichiers. Plus simple à mettre en œuvre, légèrement moins performant que le bloc pour les workloads intensifs. Utilisé pour les templates, ISOs, et certaines VM moins exigeantes.
- FC (Fibre Channel) : dans des environnements nécessitant les meilleures performances, utilisation de HBA (Host Bus Adapters) et de switches FC dédiés. Plus coûteux.
Cluster de firewalls
Deux firewalls physiques (ex. pfSense/OPNsense, Fortinet, Palo Alto) fonctionnent en cluster actif/passif ou actif/actif avec synchronisation d'état (state synchronization).
Synchronisation d'état : les sessions TCP/UDP actives (connexions utilisateurs, tunnels VPN, sessions NAT) sont répliquées en temps réel du firewall actif vers le firewall passif. Si le firewall actif tombe, le passif reprend instantanément sans interruption des connexions établies.
CARP/VRRP : un protocole de redondance (CARP sur pfSense/OPNsense, VRRP sur Fortinet/Cisco) maintient une adresse IP virtuelle partagée. Les utilisateurs et serveurs pointent vers cette IP virtuelle, qui est portée par le firewall actif. En cas de bascule, l'IP virtuelle est reprise par le firewall passif.
Rôle :
- Filtrage entrant/sortant (règles de sécurité, IDS/IPS)
- NAT pour l'accès internet
- Terminaison des VPN site-à-site et client-to-site
- Routage inter-VLANs (ou délégué aux switches L3)
- Segmentation LAN / DMZ / WAN
Les nœuds Proxmox
Configuration physique type d'un nœud PME
Chaque nœud est un serveur physique équipé de :
- CPU : 2 processeurs Intel Xeon ou AMD EPYC (minimum 20 cœurs physiques au total)
- RAM : 256 à 512 Go ECC DDR4/DDR5
- Stockage local : 2 SSD NVMe en RAID 1 pour l'OS Proxmox (le système Proxmox lui-même n'occupe que peu d'espace)
- Réseau : 2 × 10GbE pour le LAN (LACP) + 2 × 10GbE pour le SAN (LACP ou séparés)
Organisation du cluster à 3 nœuds
[NODE-PVE-01] ←→ Corosync ←→ [NODE-PVE-02]
↑ ↑
└──────── Corosync ────────────┘
↕
[NODE-PVE-03]
Avec 3 nœuds, le cluster tolère la perte d'un seul nœud tout en maintenant le quorum (2/3 votes). C'est la configuration minimale recommandée pour la production.
Répartition de charge : les VM sont distribuées sur les 3 nœuds selon les ressources disponibles. Proxmox ne fait pas de répartition automatique (pas de DRS comme VMware par défaut), mais propose la migration manuelle ou des scripts d'équilibrage.
Règle de dimensionnement N-1 : l'ensemble des VM critiques doit pouvoir tenir sur 2 nœuds (N-1) en cas de perte d'un nœud. Si les 3 nœuds sont utilisés à 60% de leur capacité, en cas de panne d'un nœud, les 2 survivants doivent absorber 90% de la charge totale, ce qui est dans les limites.
Stockage partagé — Fonctionnement détaillé
La baie de stockage SAN est connectée aux 3 nœuds via le réseau SAN dédié.
Scénario iSCSI + LVM :
- La baie expose plusieurs LUNs iSCSI (ex. LUN-DATA-01, LUN-DATA-02 pour les VM, LUN-BACKUP pour les sauvegardes internes).
- Les 3 nœuds se connectent simultanément à ces LUNs via l'initiateur iSCSI Linux.
- Proxmox crée un groupe de volumes LVM partagé sur ces LUNs. Les métadonnées LVM (table des volumes logiques) sont accessibles par tous les nœuds simultanément grâce au LVM cluster-aware ou via le shared storage Proxmox.
- Chaque VM utilise un volume logique (LV) sur ce stockage partagé. Lors d'une migration live, la VM se déplace d'un nœud à l'autre, mais son disque reste en place sur la baie SAN — seul l'accès au volume logique est redirigé vers le nœud de destination.
Scénario NFS :
La baie expose un partage NFS sur le réseau SAN. Les 3 nœuds montent ce partage dans Proxmox. Les disques VM sont des fichiers qcow2 ou raw stockés dans ce partage NFS. La migration live transfère l'accès au fichier d'un nœud à l'autre.
NAS de backup — Architecture de sauvegarde
Un NAS dédié (ex. Synology, QNAP, ou serveur Linux avec ZFS) reçoit les sauvegardes de toutes les VM. Il est connecté soit via le réseau SAN (performances), soit via un VLAN dédié backup sur le LAN.
Proxmox Backup Server (PBS) : Proxmox propose son propre serveur de sauvegarde (PBS) qui peut être installé sur le NAS ou sur une VM dédiée. PBS offre :
- Déduplication : les blocs identiques entre sauvegardes ne sont stockés qu'une seule fois. Une VM de 100 Go dont 90% des données n'ont pas changé ne consomme que 10 Go supplémentaires pour la nouvelle sauvegarde.
- Compression : réduction de l'espace disque utilisé.
- Sauvegarde incrémentielle : seuls les blocs modifiés depuis la dernière sauvegarde sont transférés, réduisant la fenêtre de sauvegarde et la charge réseau.
- Chiffrement : les sauvegardes peuvent être chiffrées côté client avant transmission au PBS.
- Restauration granulaire : possibilité de restaurer des fichiers individuels depuis une sauvegarde sans restaurer la VM entière.
- Vérification d'intégrité : PBS vérifie régulièrement l'intégrité des sauvegardes stockées.
Les jobs de sauvegarde sont planifiés depuis l'interface Proxmox (Datacenter → Backup) avec des politiques de rétention (ex. 7 sauvegardes journalières, 4 hebdomadaires, 3 mensuelles).
Inventaire des VM — PME
| VM | Rôle | Nœud préféré | HA | RAM | vCPU |
|---|---|---|---|---|---|
| AD-01 | Active Directory Primary | PVE-01 | Oui | 8 Go | 4 |
| AD-02 | Active Directory Secondary | PVE-02 | Oui | 8 Go | 4 |
| EXCHANGE-01 | Messagerie Exchange | PVE-02 | Oui | 32 Go | 8 |
| FS-01 | Serveur de fichiers | PVE-01 | Oui | 16 Go | 4 |
| PRINT-01 | Serveur d'impression | PVE-03 | Non | 4 Go | 2 |
| ZABBIX-01 | Monitoring | PVE-03 | Non | 8 Go | 4 |
| ITSM-01 | Gestion de tickets (ex. GLPI) | PVE-03 | Non | 8 Go | 4 |
| WSUS-01 | Mises à jour Windows | PVE-02 | Non | 8 Go | 4 |
| WEB-LINUX-01 | Serveur web (Apache/Nginx) | PVE-01 | Non | 4 Go | 2 |
| PGSQL-01 | PostgreSQL | PVE-01 | Non | 16 Go | 4 |
Note sur la politique HA : seuls les services critiques (AD, Exchange, FS) sont marqués HA pour éviter de surcharger le mécanisme de failover avec des services non critiques.
Flux réseau et sécurité
Les VM sont réparties dans des VLANs selon leur rôle. Proxmox associe chaque interface virtuelle de VM à un bridge Linux tagged sur le bon VLAN :
- AD, Exchange, FS → VLAN Serveurs
- Web Linux, PostgreSQL → VLAN DMZ
- Zabbix, WSUS, ITSM → VLAN Serveurs (accès management)
Le firewall contrôle les flux entre VLANs. Par exemple, les utilisateurs (VLAN 40) accèdent aux serveurs de fichiers (VLAN 30) uniquement sur les ports SMB nécessaires, et le trafic web du VLAN DMZ vers le VLAN Serveurs est filtré.
PARTIE 3 — ARCHITECTURE GRANDE ENTREPRISE (8 NŒUDS + PRA)
Vue d'ensemble
Cette architecture cible une grande entreprise de 500 à plusieurs milliers d'utilisateurs avec des besoins en haute disponibilité, DevOps, RDS et un plan de reprise d'activité (PRA) sur site secondaire. Le site principal dispose de 5 nœuds Proxmox, le site secondaire de 3 nœuds.
Site Principal — Infrastructure physique
Configuration physique des nœuds enterprise
Pour une grande entreprise, les nœuds Proxmox sont plus puissants :
- CPU : 2 × AMD EPYC ou Intel Xeon Scalable (48 à 128 cœurs physiques au total par nœud)
- RAM : 512 Go à 2 To ECC DDR4/DDR5 par nœud
- Stockage local : 2 × NVMe en RAID 1 pour l'OS + éventuellement du NVMe local pour le cache (Ceph)
- Réseau : 2 × 25GbE LAN (LACP) + 2 × 25GbE SAN (LACP) + 1 × 1GbE management IPMI/iDRAC
Le cluster à 5 nœuds — Quorum et résilience
Avec 5 nœuds, le cluster tolère la perte de 2 nœuds simultanément (3/5 votes pour le quorum). Cela offre une résilience nettement supérieure pour les maintenances planifiées (mise à jour d'un nœud) tout en restant tolérant à une panne supplémentaire inattendue.
[PVE-01] ←─────────────────────→ [PVE-02]
↑ ↘ ↗ ↑
│ [PVE-03] ←────→ [PVE-04] │
│ ↕ │
└──────[PVE-05]────────────────┘
Homogénéité des nœuds :
Dans ce cluster, les 5 nœuds sont identiques en termes de matériel : même CPU, même quantité de RAM, même configuration réseau et même stockage local. Cette homogénéité est fondamentale dans la philosophie Proxmox :
- Elle garantit qu'une VM peut migrer sur n'importe quel nœud sans contrainte de ressources.
- Elle simplifie les opérations de maintenance et le remplacement de matériel.
- Elle évite les situations où un failover échoue parce que le nœud cible n'a pas assez de RAM ou de CPU.
Si certaines VM ont des affinités définies (PostgreSQL, ETCD, masters Kubernetes), c'est pour des raisons architecturales liées à la réplication applicative, non parce que les nœuds sont différents. En dehors de ces cas spécifiques, toutes les autres VM peuvent librement migrer sur n'importe lequel des 5 nœuds via la migration live Proxmox, sans contrainte de placement.
Proxmox et les groupes HA avancés
Pour une grande entreprise, les groupes HA (HA Groups) permettent d'affiner le comportement de failover :
- Groupes prioritaires : on peut définir un groupe "CRITICAL" incluant PVE-01 et PVE-02 avec une priorité élevée. Les VM de ce groupe migrent préférentiellement vers ces nœuds.
- Restricted : une VM avec le flag "restricted" ne migre que vers les nœuds de son groupe HA. Utile pour des raisons de licence (licence par socket CPU) ou de conformité.
- No-failback : empêche la migration automatique de retour vers le nœud d'origine après sa réparation, pour éviter les migrations inutiles en production.
Ceph — Stockage distribué natif Proxmox
Pour une grande entreprise avec 5 nœuds, l'utilisation de Ceph RBD intégré à Proxmox est une option puissante. Ceph est un système de stockage distribué open-source qui :
- Distribue les données en blocs (chunks) répliqués sur plusieurs nœuds. Par défaut, chaque bloc est répliqué 3 fois (replica=3), garantissant qu'aucune perte de données n'est possible même en cas de défaillance de 2 nœuds.
- Élimine la baie SAN : le stockage est fourni par les disques NVMe/SSD locaux de chaque nœud Proxmox, réunis dans un pool Ceph distribué.
- S'intègre nativement : Proxmox reconnaît nativement Ceph comme backend de stockage. Les disques VM sont des RBD images (RADOS Block Device) directement dans le pool Ceph.
- Supporte les snapshots COW : les snapshots Ceph sont instantanés (Copy-On-Write) et ne consomment de l'espace que pour les blocs modifiés depuis le snapshot.
Dans cette architecture, les 5 nœuds participent au cluster Ceph avec chacun plusieurs NVMe dédiés (séparés des NVMe OS). Le réseau SAN dédié transporte le trafic de réplication Ceph entre nœuds.
Coexistence SAN + Ceph : il est possible d'avoir une baie SAN externe pour certains workloads (bases de données critiques nécessitant des SLA de latence très stricts) et Ceph pour les autres workloads. Les deux storages coexistent dans Proxmox.
Organisation des VM — Grande Entreprise
Infrastructure socle (identique PME, renforcée)
| VM | Rôle | Nœud préféré | HA |
|---|---|---|---|
| AD-01, AD-02 | Active Directory | PVE-01, PVE-02 | Oui |
| EXCHANGE-01/02 | Messagerie (DAG) | PVE-01, PVE-02 | Oui |
| FS-01/02 | Fichiers (DFS) | PVE-01, PVE-02 | Oui |
| ADFS-01/02 | Fédération d'identité | PVE-01, PVE-02 | Oui |
Cluster Kubernetes (5 masters / 5 workers)
Les 10 VM Kubernetes sont distribuées sur les nœuds Proxmox selon cette logique :
Masters (PVE-01 à PVE-05, un master par nœud) : les 5 masters sont délibérément placés sur 5 nœuds différents via les groupes HA Proxmox avec flag "restricted". Chaque master est ancré sur son nœud Proxmox dédié et ne peut pas migrer vers un nœud hébergeant déjà un autre master. Cela garantit que la perte d'un nœud Proxmox n'impacte qu'un seul master Kubernetes, laissant les 4 restants former un quorum (5 masters, tolérance de 2 défaillances).
Workers (1 worker par nœud Proxmox, sur les 5 nœuds) : les 5 workers sont répartis équitablement, un par nœud Proxmox. Tous les nœuds étant identiques, chaque worker bénéficie des mêmes ressources. Cette distribution garantit qu'en cas de perte d'un nœud Proxmox, un seul worker est affecté et Kubernetes redistribue automatiquement les pods sur les 4 workers restants. Les VM workers n'ont pas d'affinité stricte : si leur nœud Proxmox tombe, elles peuvent redémarrer sur n'importe quel nœud survivant (la logique de distribution des pods reste gérée par Kubernetes).
Connexion réseau des VM Kubernetes : chaque VM Kubernetes dispose de 2 interfaces réseau :
- Une interface sur le VLAN Serveurs pour la communication inter-VM et l'accès aux services de l'entreprise
- Une interface sur un VLAN dédié Kubernetes pour le trafic interne au cluster (pod-to-pod, service mesh)
Les 2 HAProxy en frontaux
Deux VM HAProxy sont déployées sur des nœuds Proxmox distincts (placement HA avec anti-affinité pour garantir qu'elles ne se retrouvent jamais sur le même nœud). Une IP virtuelle (Keepalived/VRRP) flotte entre les deux instances. Le firewall publie cette IP virtuelle vers l'extérieur. Ces VM n'ont pas d'affinité fixe vers un nœud Proxmox précis et peuvent migrer librement sur n'importe lequel des 5 nœuds, la seule contrainte étant qu'elles ne doivent pas cohabiter sur le même nœud physique.
HAProxy répartit le trafic entrant vers les nodes Kubernetes (Ingress Controller) et vers la ferme RDS. Ces VM sont dans la DMZ (VLAN DMZ) avec des règles firewall strictes.
Ferme RDS (5 serveurs d'applications + rôles complémentaires)
Une ferme RDS complète ne se résume pas aux serveurs de sessions. Elle nécessite plusieurs rôles Windows Server complémentaires :
RDS Session Host × 5 : les 5 VM hébergeant les sessions utilisateurs sont réparties sur les 5 nœuds Proxmox, une par nœud. Tous les nœuds étant identiques, chaque serveur de sessions bénéficie des mêmes ressources (typiquement 32 à 64 Go de RAM, 8 à 16 vCPU). Ces VM n'ont pas d'affinité fixe et peuvent migrer librement sur n'importe quel nœud en dehors des maintenances planifiées.
RDS Connection Broker × 2 (en cluster) : le broker est le cerveau de la ferme. Il reçoit les demandes de connexion des utilisateurs, consulte ses bases de données de sessions actives, et redirige chaque connexion vers le serveur de sessions le plus approprié (charge, session existante à reconnecter). Il est déployé en cluster actif/actif avec une IP virtuelle pour la haute disponibilité. Ces 2 VM sont placées sur des nœuds distincts (contrainte d'anti-affinité Proxmox) mais sans affinité fixe sur un nœud précis.
RDS License Server × 1 : le serveur de licences RDS gère les CAL (Client Access Licenses) Remote Desktop. Il octroie et suit les licences utilisées par chaque session active. Sans ce serveur opérationnel, la ferme RDS fonctionne en mode de grâce limité (120 jours) puis bloque les nouvelles connexions. Cette VM est déployée avec le HA Proxmox activé pour garantir sa disponibilité, mais sans affinité de nœud fixe.
RDS Gateway × 2 : le gateway RDS est le point d'entrée sécurisé pour les connexions RDP provenant de l'extérieur du réseau d'entreprise (utilisateurs en télétravail, accès via internet). Il encapsule le protocole RDP dans HTTPS (port 443), permettant de traverser les firewalls sans exposer le port RDP 3389 directement sur internet. Deux VM Gateway sont déployées pour la redondance, sur des nœuds Proxmox distincts, derrière les HAProxy en frontal. Elles communiquent avec le Connection Broker pour valider les accès.
RDS Web Access × 1 (ou mutualisé sur le Gateway) : portail web permettant aux utilisateurs d'accéder à leurs applications RemoteApp et bureaux distants depuis un navigateur, sans client RDP installé.
Outils DevOps et Observabilité
Les VM de support infrastructure sont moins critiques en termes de SLA mais importantes opérationnellement. Elles n'ont pas d'affinité de nœud définie et migrent librement selon la charge du cluster :
| VM | Rôle | RAM |
|---|---|---|
| ANSIBLE-01 | Automatisation de configuration | 8 Go |
| JENKINS-01/02 | CI/CD pipelines | 16 Go |
| GRAYLOG-01 | Centralisation de logs | 32 Go |
| GRAFANA-01 | Dashboards de monitoring | 8 Go |
| K6-01 | Tests de charge | 8 Go |
| ZABBIX-01 | Monitoring infrastructure | 16 Go |
Ces VM bénéficient du HA Proxmox pour le redémarrage automatique en cas de panne de nœud, mais aucun nœud n'est désigné comme "préféré". Proxmox les place initialement selon les ressources disponibles au moment du démarrage, et elles peuvent ensuite être migrées manuellement ou automatiquement selon les besoins de maintenance.
Cluster PostgreSQL (5 serveurs) et ETCD (3 serveurs)
Philosophie du stockage PostgreSQL — pourquoi ne pas utiliser Ceph ou le SAN partagé
Le cluster PostgreSQL gère lui-même sa propre réplication des données entre ses 5 membres (via Patroni ou Replication Streaming natif). Il n'a donc pas besoin — et surtout ne doit pas utiliser — un stockage partagé de type Ceph ou SAN pour ses données.
Voici pourquoi c'est une mauvaise pratique :
Un stockage partagé (Ceph, SAN) introduit une couche d'indirection réseau entre PostgreSQL et ses données. Chaque écriture transite par le réseau SAN/Ceph avant d'atteindre les disques physiques. Pour une base de données OLTP avec des milliers de transactions par seconde, cette latence supplémentaire (même faible) est mesurable et préjudiciable. De plus, si la réplication PostgreSQL assure déjà que les données sont présentes sur plusieurs serveurs, utiliser Ceph revient à répliquer les données deux fois : une fois par Ceph (au niveau bloc) et une fois par PostgreSQL (au niveau applicatif), ce qui est à la fois coûteux en ressources et architecturalement redondant.
La bonne approche : disques NVMe locaux dédiés sur chaque nœud Proxmox
Chaque nœud Proxmox dispose de disques NVMe dédiés exclusivement aux VM PostgreSQL, distincts des disques NVMe de l'OS Proxmox et des disques participant au pool Ceph. Ces NVMe sont présentés en passthrough direct à la VM PostgreSQL (via le device passthrough Proxmox ou un volume LVM-Thin local dédié) pour minimiser la latence d'I/O.
Chacune des 5 VM PostgreSQL est donc ancrée (pinned) sur son nœud Proxmox via un groupe HA "restricted" à un seul nœud, précisément parce que ses données sont sur le stockage local de ce nœud. Cette VM ne peut pas migrer vers un autre nœud — ce serait d'ailleurs inutile puisque ses données ne sont pas accessibles depuis ailleurs. En cas de panne du nœud Proxmox, c'est PostgreSQL (via Patroni/ETCD) qui gère le failover applicatif en promouvant un réplica secondaire, sans intervention de Proxmox.
Résumé du placement PostgreSQL :
| VM | Nœud Proxmox | Rôle PostgreSQL | Stockage |
|---|---|---|---|
| PGSQL-01 | PVE-01 (ancré) | Primaire | NVMe local PVE-01 |
| PGSQL-02 | PVE-02 (ancré) | Réplica sync | NVMe local PVE-02 |
| PGSQL-03 | PVE-03 (ancré) | Réplica sync | NVMe local PVE-03 |
| PGSQL-04 | PVE-04 (ancré) | Réplica async | NVMe local PVE-04 |
| PGSQL-05 | PVE-05 (ancré) | Réplica async | NVMe local PVE-05 |
Cluster ETCD (3 serveurs) — rôle pour PostgreSQL
Le cluster ETCD à 3 nœuds n'est pas utilisé par Kubernetes dans cette architecture (Kubernetes utilise son propre ETCD intégré dans les masters). Il est dédié à Patroni, le gestionnaire de haute disponibilité de PostgreSQL.
Patroni est un agent déployé sur chaque VM PostgreSQL qui surveille l'état du cluster de bases de données. ETCD est son backend de consensus distribué : il stocke l'état du cluster PostgreSQL (qui est le primaire, qui sont les réplicas, leur état de santé), et sert d'arbitre en cas de décision de failover. Quand le nœud primaire PostgreSQL devient indisponible, les agents Patroni sur les réplicas consultent ETCD pour s'accorder sur quel réplica doit être promu primaire, évitant tout split-brain au niveau base de données.
Les 3 VM ETCD sont ancrées sur PVE-01, PVE-02 et PVE-03 (un par nœud, flag "restricted"), pour les mêmes raisons que les masters Kubernetes : il ne faut jamais que deux membres ETCD soient sur le même nœud Proxmox physique, au risque de perdre le quorum ETCD (2/3 requis) lors d'une panne d'un seul nœud Proxmox.
Politique globale de placement des VM dans le cluster
Dans cette architecture, les VM se répartissent en deux catégories du point de vue Proxmox :
VM avec affinité stricte (ancrées sur un nœud précis) : ce sont les VM dont le stockage est local ou dont l'architecture applicative impose une corrélation avec un nœud physique précis. Elles utilisent le groupe HA "restricted" à un seul nœud. En cas de panne de leur nœud Proxmox, Proxmox ne tente pas de les démarrer ailleurs — c'est la couche applicative qui gère la continuité de service.
- Masters Kubernetes (un par nœud, logique de quorum)
- VM PostgreSQL (stockage NVMe local)
- VM ETCD (quorum Patroni)
VM sans affinité fixe (migration libre) : toutes les autres VM. Elles sont configurées dans des groupes HA sans contrainte de nœud, ou simplement sans HA pour les moins critiques. Proxmox peut les migrer librement par live migration pour équilibrer la charge, pour une maintenance planifiée (évacuation d'un nœud), ou en cas de failover automatique. C'est le mode de fonctionnement normal pour la grande majorité des VM de l'infrastructure : AD, Exchange, ADFS, FS, HAProxy, RDS (Broker, Gateway, Session Hosts), Workers Kubernetes, et tous les outils DevOps/observabilité.
Pour une grande entreprise, la fonctionnalité SDN (Software Defined Networking) de Proxmox permet de créer une topologie réseau virtuelle complexe sans dépendre entièrement de la configuration VLAN des switches physiques.
Zones SDN : Proxmox SDN définit des "zones" (VLAN zone, VXLAN zone, EVPN zone) qui correspondent à des domaines d'isolation réseau. Une zone VXLAN, par exemple, permet de créer des réseaux virtuels qui traversent les nœuds Proxmox en encapsulant le trafic Ethernet dans UDP, indépendamment de la topologie physique des switches.
VNets : au sein d'une zone, des VNets (réseaux virtuels) sont créés et assignés aux VM comme des bridges normaux. La gestion est centralisée dans l'interface Proxmox et synchronisée sur tous les nœuds.
Site Secondaire — PRA (3 nœuds Proxmox)
Philosophie du PRA
Le site secondaire de PRA (Plan de Reprise d'Activité) est distinct du site principal, idéalement dans un bâtiment ou datacenter différent (pour couvrir les sinistres majeurs : incendie, inondation). Il n'est pas membre du même cluster Proxmox que le site principal.
Pourquoi des clusters séparés ?
Proxmox supporte techniquement des clusters multi-sites, mais cela est fortement déconseillé si la latence inter-sites dépasse quelques millisecondes. Corosync est très sensible à la latence réseau : un lien WAN avec 20-50 ms de latence peut provoquer de faux positifs de perte de quorum, déclenchant des fences intempestifs. Les deux sites disposent donc de leurs propres clusters Proxmox indépendants.
Réplication Proxmox (proxmox-backup / réplication native)
Proxmox intègre un mécanisme de réplication native basé sur ZFS ou Ceph. Pour le scénario PRA :
Réplication ZFS over SSH : si les nœuds utilisent ZFS comme stockage local (ou avec des pools ZFS sur le SAN), Proxmox peut répliquer les snapshots ZFS des VM vers les nœuds du site secondaire. Le processus :
- Proxmox prend un snapshot ZFS de chaque VM répliquée à intervalles réguliers (configurable : toutes les heures, toutes les 15 minutes...).
- Le snapshot est envoyé via
zfs send/receiveover SSH vers le nœud cible du site secondaire. - Seuls les blocs modifiés depuis le dernier snapshot sont transférés (réplication incrémentielle ZFS). Cela minimise l'utilisation de la bande passante WAN.
- Sur le site secondaire, les VM répliquées existent en état "verrouillé" (locked/réplication uniquement). Elles ne peuvent pas démarrer automatiquement — cela évite des conflits de données si la connexion WAN est temporairement interrompue.
RPO (Recovery Point Objective) : avec une réplication toutes les heures, le RPO est de 1 heure. En cas de sinistre majeur sur le site principal, les données des VM sur le site secondaire ont au maximum 1 heure de retard.
RTO (Recovery Time Objective) : en cas de déclenchement du PRA, un opérateur démarre manuellement (ou via un script) les VM répliquées sur le site secondaire. Selon le nombre de VM et leur temps de démarrage, le RTO est de l'ordre de 30 minutes à 2 heures.
Proxmox Backup Server sur le site secondaire
En complément de la réplication, un PBS (Proxmox Backup Server) est déployé sur le site secondaire. Il reçoit les sauvegardes PBS du site principal via un tunnel VPN site-à-site. Cela offre une copie hors-site des sauvegardes, indépendante de la réplication.
Cette double protection (réplication continue + sauvegarde PBS) permet de couvrir différents scénarios :
- Corruption de données : la réplication copie les données corrompues. La sauvegarde PBS permet de remonter à un point sain antérieur.
- Ransomware : idem, les sauvegardes PBS (immuables si configurées ainsi) permettent une restauration propre.
- Sinistre site principal : la réplication assure une bascule rapide sur le site secondaire.
Réseau WAN et liaison inter-sites
Les deux sites sont interconnectés via :
- VPN site-à-site (IPSec ou WireGuard) sur les firewalls des deux sites pour le trafic de gestion et les sauvegardes PBS.
- Lien WAN dédié (MPLS ou fibre dédiée) pour la réplication Proxmox, avec une bande passante suffisante pour absorber les deltas de réplication ZFS en heure de pointe.
Le réseau de réplication est séparé logiquement (VLAN ou VPN distinct) du réseau de management pour éviter que le trafic de réplication n'impacte les performances de gestion.
Gestion des mises à jour et maintenance
Proxmox Subscriptions et repositories
Proxmox propose deux canaux de mise à jour :
- Enterprise repository (avec souscription payante) : mises à jour testées et stables, support Proxmox inclus.
- No-subscription repository : gratuit, mises à jour moins testées. Pour les environnements de production d'entreprise, la souscription est recommandée.
Processus de mise à jour d'un nœud en production
Pour mettre à jour un nœud sans interruption de service :
- Évacuation du nœud (Migration) : depuis l'interface Proxmox, on déclenche une migration live de toutes les VM HA vers les autres nœuds. Les VM non-HA sont migrées manuellement ou arrêtées pendant la maintenance.
- Mise en maintenance : le nœud est placé en mode maintenance (Proxmox ne lui assignera pas de nouvelles VM via le HA manager).
- Mise à jour :
apt update && apt dist-upgradesur le nœud. - Redémarrage si nécessaire (nouvelle version du kernel).
- Réintégration : le nœud rejoint le cluster, le HA manager peut lui réassigner des VM (ou elles restent sur les nœuds où elles ont migré).
Sécurité de l'infrastructure Proxmox
Authentification
Proxmox supporte plusieurs mécanismes d'authentification :
- PAM : authentification via les comptes Linux locaux du nœud.
- PVE realm : authentification via la base d'utilisateurs interne Proxmox, avec gestion des tokens API pour l'automatisation.
- LDAP/Active Directory : intégration avec l'AD d'entreprise pour une authentification SSO.
Les tokens API permettent à des outils d'automatisation (Terraform, Ansible, Jenkins) d'interagir avec l'API Proxmox sans utiliser de compte utilisateur interactif. Les tokens ont des permissions granulaires (lecture seule, gestion VM, etc.).
RBAC (Role-Based Access Control)
Proxmox implémente un RBAC complet. Les permissions sont définies selon le modèle :
Sujet (utilisateur ou groupe) + Rôle (ensemble de permissions) + Objet (VM, nœud, storage, pool)
Des pools de ressources permettent de regrouper des VM et d'assigner des permissions à un groupe d'utilisateurs sur ce pool entier. Par exemple, l'équipe applicative peut avoir accès en lecture seule à ses VM mais ne peut pas arrêter les VM des autres équipes.
Firewall intégré Proxmox
Proxmox dispose d'un firewall basé sur iptables/nftables, administrable depuis l'interface web à trois niveaux :
- Datacenter level : règles appliquées sur tous les nœuds et toutes les VM.
- Node level : règles spécifiques à un nœud (ex. limiter les IPs autorisées à se connecter à l'interface web Proxmox).
- VM/CT level : règles spécifiques à chaque VM ou conteneur (micro-segmentation).
Ce firewall est complémentaire au firewall de périmètre physique et permet une segmentation fine entre VM sur le même nœud.
Tableau récapitulatif comparatif
| Critère | PME (3 nœuds) | Grande Entreprise (5+3 nœuds) |
|---|---|---|
| Tolérance de pannes | 1 nœud | 2 nœuds (site principal) |
| Quorum | 2/3 | 3/5 |
| Stockage partagé | SAN iSCSI/NFS externe | Ceph distribué (VM générales) + NVMe locaux dédiés (PostgreSQL) |
| Réplication PRA | PBS NAS local | Réplication ZFS inter-sites + PBS |
| Migration live | Oui (stockage SAN partagé) | Oui (Ceph natif) |
| SDN avancé | Non nécessaire | VXLAN/EVPN zones |
| Nombre de VM | ~10-15 | 50-100+ |
| Kubernetes | Non | Oui (intégré comme VM) |
| RDS | Non | Oui (ferme 5 serveurs) |
| Backup | PBS sur NAS | PBS site principal + PBS site secondaire |
| RPO | 24h (sauvegarde nuit) | 1h (réplication ZFS) |
| RTO | 2-4h | 30min-2h |
Guide rédigé pour Proxmox VE 8.x — Dernière mise à jour 2025