Guide de deploiement Proxmox VE 9.x avec Ceph¶

Ce guide couvre le deploiement complet d'un cluster Proxmox VE 9.x (Debian 13 "Trixie") hyper-converge avec stockage Ceph Squid 19.2. Il s'adresse aux administrateurs systemes deployant Proxmox pour la premiere fois en environnement de production.

Version Proxmox

Ce guide cible Proxmox VE 9.1+ (derniere version stable, novembre 2025). Il inclut les nouveautes PVE 9 : Ceph Squid 19.2, SDN Fabric, snapshots LVM thick, images OCI pour LXC, regles d'affinite HA, QEMU 10.0, ZFS 2.3, et vTPM snapshots.

1. Configuration post-installation¶

Apres l'installation de Proxmox VE depuis l'ISO officiel, plusieurs ajustements sont necessaires avant de mettre le serveur en production.

Desactiver le depot enterprise et activer le depot no-subscription¶

Par defaut, Proxmox VE est configure pour utiliser le depot enterprise qui necessite une licence payante. Pour un environnement de test ou si vous n'avez pas de souscription :

# Desactiver le depot enterprise
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list

# Ajouter le depot no-subscription
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

Warning

Le depot no-subscription n'est pas recommande pour la production par Proxmox. Il est stable mais ne beneficie pas du meme niveau de tests que le depot enterprise. En production, privilegiez une souscription.

Ce popup apparait a chaque connexion sur l'interface web si vous n'avez pas de licence :

# Sauvegarder le fichier original
cp /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.bak

# Supprimer le popup (a re-appliquer apres chaque mise a jour du paquet)
sed -Ei "s/Ext\.Msg\.show\(\{.*?title:\s*gettext\('No valid subscription'\)/void({title:''/" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

systemctl restart pveproxy

Info

Cette modification sera ecrasee a chaque mise a jour du paquet proxmox-widget-toolkit. Vous devrez la re-appliquer apres un apt upgrade.

Mettre a jour le systeme¶

apt update && apt full-upgrade -y
reboot

Configurer NTP avec chrony¶

La synchronisation temporelle est critique pour le fonctionnement du cluster (Corosync, Ceph) :

apt install chrony -y

Editer /etc/chrony/chrony.conf :

# Serveurs NTP (adapter selon votre infrastructure)
server ntp1.example.com iburst
server ntp2.example.com iburst
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

# Permettre un saut de temps important au demarrage
makestep 1.0 3

# Activer RTC sync
rtcsync

systemctl enable chrony
systemctl restart chrony

# Verifier la synchronisation
chronyc sources -v
chronyc tracking

Danger

Un decalage temporel superieur a quelques secondes entre les noeuds peut provoquer des dysfonctionnements graves de Corosync et Ceph. Verifiez la synchronisation NTP AVANT de creer le cluster.

Verifier la configuration DNS¶

Le fichier /etc/hosts doit contenir le FQDN et l'IP de chaque noeud. L'adresse 127.0.1.1 par defaut pose souvent probleme :

# Verifier /etc/hosts — le hostname ne doit PAS pointer vers 127.0.0.1 ou 127.0.1.1
cat /etc/hosts

Exemple de /etc/hosts correct :

127.0.0.1       localhost

# Noeuds Proxmox
192.168.1.10    pve1.example.com pve1
192.168.1.11    pve2.example.com pve2
192.168.1.12    pve3.example.com pve3

Verifier /etc/resolv.conf :

cat /etc/resolv.conf
# Doit contenir un serveur DNS fonctionnel
# search example.com
# nameserver 192.168.1.1

# Tester la resolution
hostname --ip-address
# Doit retourner l'IP du reseau de management, PAS 127.0.x.x

2. Configuration reseau¶

L'architecture reseau est la fondation du cluster. Une mauvaise conception reseau est la cause numero un des problemes de performance et de stabilite.

Vue d'ensemble des reseaux¶

Le cluster utilise deux plans reseau physiquement separes :

Reseau	Usage	Interface	Infra	Subnet	MTU
Management + VMs	Interface web PVE, Corosync, trafic VM	vmbr0 (1G RJ45)	Fortinet (VLAN 230)	10.1.230.0/24	1500
Ceph (stockage)	Trafic OSD public + cluster, migration live	Interfaces 10G SFP+ directes	Full mesh point-a-point	10.0.10.0/29 (3x /30)	9000
iLO (hors bande)	Acces console, IPMI, fencing HA	Port iLO dedie	Fortinet (VLAN 250)	10.1.250.0/24	1500

Adressage des noeuds¶

Noeud	Hostname	IP Management (V230)	IP iLO (V250)	Batiment
DL380 #1	pve-dl380-bureaux	10.1.230.30	10.1.250.15	A (bureaux)
DL380 #2	pve-dl380-usine	10.1.230.31	10.1.250.16	B (usine)
DL360 #3	pve-dl360 (phase 2)	10.1.230.32 (a reserver)	(a documenter)	B (usine)

Passerelle VLAN 230 : 10.1.230.254 (Fortigate 60F)

Topologie Ceph — Full Mesh 10G¶

Architecture point-a-point sans switch. Chaque serveur est connecte directement aux deux autres via les NIC HPE 534FLR-SFP+ (Broadcom BCM57810S), 2 ports SFP+ 10G par serveur.

pve-dl380-bureaux (bat. A)
    port1 ──── LRM + fibre OM2 170m ──── port1  pve-dl380-usine (bat. B)
    port2 ──── LRM + fibre OM2 170m ──── port1  pve-dl360 (bat. B)
                                         port2 ── DAC 2m ── port2  pve-dl380-usine

Sous-reseaux point-a-point (Ceph) :

Liaison	Sous-reseau	IP noeud 1	IP noeud 2	Media
DL380-bureaux <-> DL380-usine	10.0.10.0/30	.1	.2	LRM + fibre OM2 150m
DL380-bureaux <-> DL360	10.0.10.4/30	.5	.6	LRM + fibre OM2 150m
DL380-usine <-> DL360	10.0.10.8/30	.9	.10	DAC SFP+ passif 2m

Pourquoi des /30 et pas un /24

En full mesh sans switch, chaque lien est un segment physique isole. Un /30 par lien est la bonne pratique : pas de broadcast inutile, routage explicite entre les noeuds. C'est la topologie recommandee par Proxmox pour Ceph.

Interfaces physiques par noeud¶

Les DL380 ont des interfaces 1G integrees (eno1-eno4) et la NIC 534FLR-SFP+ 10G. Les noms d'interface 10G dependent du systeme — verifier avec ip link apres installation. Typiquement : ens2f0 / ens2f1 pour la 534FLR.

Identifier les interfaces 10G et le port SFP+ actif

Apres installation de Proxmox, reperer les interfaces de la 534FLR et determiner quel port physique porte la liaison :

# 1. Vue rapide : toutes les interfaces et leur etat (UP/DOWN/carrier)
ip -br link show
# Exemple de sortie :
#   lo       UNKNOWN  00:00:00:00:00:00 <...>
#   eno1     UP       aa:bb:cc:dd:ee:f0 <...>
#   nic4     DOWN     ec:eb:b8:92:40:08 <...>   ← port SFP+ 1, LRM insere mais pas de signal
#   nic5     DOWN     ec:eb:b8:92:40:0c <...>   ← port SFP+ 2, lien fibre actif

# 2. Confirmer le driver Broadcom (bnx2x = 534FLR-SFP+)
dmesg | grep bnx2x
# ou plus precis :
ethtool -i nic4 | grep driver    # doit afficher "driver: bnx2x"

# 3. Verifier vitesse et etat du lien sur chaque port SFP+
ethtool nic5 | grep -E "Speed|Link detected"
#   Speed: 10000Mb/s       ← lien 10G actif
#   Link detected: yes

ethtool nic4 | grep -E "Speed|Link detected"
#   Speed: Unknown!        ← pas de signal recu (fibre non raccordee)
#   Link detected: no

# 4. Infos du transceiver insere (vendor, type, puissance optique)
ethtool -m nic5
#   Identifier         : 0x03 (SFP)
#   Connector          : 0x07 (LC)
#   Transceiver type   : 10G Ethernet: 10G Base-LRM
#   Vendor name        : FS
#   Vendor PN          : SFP-10GLRM-31
#   Laser output power : 0.7636 mW / -1.17 dBm
#   Receiver signal    : 0.9474 mW / -0.23 dBm   ← signal excellent

# 5. Correspondance port physique <-> interface systeme
# Proxmox renomme les interfaces : eno5 → nic4, eno6 → nic5
# La 534FLR a 2 ports SFP+ numerotes de gauche a droite :
#   Port 1 (gauche) = nic4 (bus b2:00.0, function 0)
#   Port 2 (droite) = nic5 (bus b2:00.1, function 1)
# Verifier avec :
ethtool -i nic4 | grep bus-info   # 0000:b2:00.0 → function 0 = port 1
ethtool -i nic5 | grep bus-info   # 0000:b2:00.1 → function 1 = port 2

Constate sur pve-dl380-bureaux : la fibre active vers pve-dl380-usine est sur nic5 (port 2 droit). nic4 (port 1 gauche) a un LRM insere mais ne recoit pas de signal — c'est le port libre pour la phase 2.

Nommage Proxmox : Proxmox renomme les interfaces Broadcom 534FLR en nic4/nic5 (et non ens2f0/ens2f1). Les interfaces 1G integrees sont nic0 a nic3. Verifier avec ip -br link show et dmesg | grep bnx2x.

Configuration reseau — pve-dl380-bureaux (bat. A)¶

Interfaces constatees sur pve-dl380-bureaux

nic0 (b8:83:03:48:26:30) — 1G RJ45 integree, management (UP)
nic1-nic3 — 1G RJ45 integrees (DOWN)
nic4 (ec:eb:b8:92:40:08) — 534FLR port 1 gauche, bus b2:00.0 — LRM insere, pas de signal RX
nic5 (ec:eb:b8:92:40:0c) — 534FLR port 2 droit, bus b2:00.1 — lien fibre actif vers DL380-usine (RX -0.23 dBm)

Editer /etc/network/interfaces :

auto lo
iface lo inet loopback

# ============================================================
# RESEAU MANAGEMENT + VMs — 1G RJ45 via Fortinet (VLAN 230)
# ============================================================

auto nic0
iface nic0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.1.230.30/24
    gateway 10.1.230.254
    bridge-ports nic0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# ============================================================
# RESEAU CEPH — 10G SFP+ Full Mesh (534FLR-SFP+, driver bnx2x)
# Pas de bridge : interfaces point-a-point directes
# ============================================================

# Port 2 (droit, nic5) — lien fibre LRM actif vers pve-dl380-usine (bat. B)
auto nic5
iface nic5 inet static
    address 10.0.10.1/30
    mtu 9000

# Port 1 (gauche, nic4) — lien fibre LRM vers pve-dl360 (bat. B) [phase 2]
#auto nic4
#iface nic4 inet static
#    address 10.0.10.5/30
#    mtu 9000

Configuration reseau — pve-dl380-usine (bat. B)¶

Interfaces constatees sur pve-dl380-usine

nic3 (b8:83:03:48:95:2d) — 1G RJ45 integree, management (UP, vmbr0)
nic0-nic2 — 1G RJ45 integrees (DOWN)
nic4 (98:f2:b3:3d:0a:58) — 534FLR port 1 gauche — contient un SR HPE d'origine (AVAGO, inutile sur OM2 150m), a remplacer par le DAC vers DL360 en phase 2
nic5 (98:f2:b3:3d:0a:5c) — 534FLR port 2 droit — lien fibre LRM actif vers DL380-bureaux (RX -0.78 dBm)

auto lo
iface lo inet loopback

# ============================================================
# RESEAU MANAGEMENT + VMs — 1G RJ45 via Fortinet (VLAN 230)
# Attention : sur ce serveur le management est sur nic3 (pas nic0)
# ============================================================

auto nic3
iface nic3 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.1.230.31/24
    gateway 10.1.230.254
    bridge-ports nic3
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# ============================================================
# RESEAU CEPH — 10G SFP+ Full Mesh (534FLR-SFP+, driver bnx2x)
# ============================================================

# Port 2 (droit, nic5) — lien fibre LRM actif vers pve-dl380-bureaux (bat. A)
auto nic5
iface nic5 inet static
    address 10.0.10.2/30
    mtu 9000

# Port 1 (gauche, nic4) — lien DAC vers pve-dl360 (bat. B) [phase 2]
# Retirer le SR HPE d'origine et brancher le DAC 2m
#auto nic4
#iface nic4 inet static
#    address 10.0.10.9/30
#    mtu 9000

Configuration reseau — pve-dl360 (bat. B) [phase 2]¶

Interfaces a verifier sur pve-dl360

Le DL360 est un modele different (Gen10 aussi) avec la 534FLR ajoutee en FlexLOM. Les noms d'interface seront probablement differents — verifier avec ip -br link show et dmesg | grep bnx2x apres installation de Proxmox.

auto lo
iface lo inet loopback

# ============================================================
# RESEAU MANAGEMENT + VMs — 1G RJ45 via Fortinet (VLAN 230)
# ============================================================

# Adapter le nom d'interface 1G (nic0, eno1... selon le modele)
auto nic0
iface nic0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.1.230.32/24
    gateway 10.1.230.254
    bridge-ports nic0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# ============================================================
# RESEAU CEPH — 10G SFP+ Full Mesh (534FLR-SFP+ ajoutee, driver bnx2x)
# Adapter nicX selon ip -br link show + dmesg | grep bnx2x
# ============================================================

# Port fibre LRM vers pve-dl380-bureaux (bat. A)
auto nic4
iface nic4 inet static
    address 10.0.10.6/30
    mtu 9000

# Port DAC vers pve-dl380-usine (bat. B)
auto nic5
iface nic5 inet static
    address 10.0.10.10/30
    mtu 9000

Validation du reseau management (post-installation)¶

Executer sur chaque noeud apres configuration :

# 1. Verifier la connectivite management
ping -c 3 10.1.230.254            # passerelle Fortigate
ping -c 3 10.1.230.30             # pve-dl380-bureaux (depuis un autre noeud)
ping -c 3 10.1.230.31             # pve-dl380-usine (depuis un autre noeud)

# 2. Verifier la resolution DNS
hostname --ip-address              # doit retourner l'IP 10.1.230.x, PAS 127.0.x.x
nslookup pve-dl380-bureaux        # si DNS configure

# 3. Verifier l'acces web Proxmox
curl -k https://10.1.230.30:8006  # doit repondre (page login PVE)

/etc/hosts obligatoire

Proxmox utilise /etc/hosts pour resoudre les noms des noeuds du cluster. Ne pas laisser le hostname pointer vers 127.0.1.1 — c'est une erreur frequente qui casse Corosync.

# /etc/hosts — pve-dl380-bureaux
127.0.0.1       localhost
10.1.230.30     pve-dl380-bureaux.d-sormg.local pve-dl380-bureaux

# /etc/hosts — pve-dl380-usine
127.0.0.1       localhost
10.1.230.31     pve-dl380-usine.d-sormg.local pve-dl380-usine

# /etc/hosts — pve-dl360 (phase 2)
127.0.0.1       localhost
10.1.230.32     pve-dl360.d-sormg.local pve-dl360

Validation du reseau Ceph 10G (phase 1 : 2 noeuds)¶

# 1. Verifier que l'interface 10G active est UP
ip link show nic5                 # state UP, mtu 9000
ethtool nic5 | grep -E "Speed|Link"
#   Speed: 10000Mb/s
#   Link detected: yes

# 2. Tester la connectivite point-a-point
# Depuis pve-dl380-bureaux :
ping -c 3 10.0.10.2               # vers pve-dl380-usine

# Depuis pve-dl380-usine :
ping -c 3 10.0.10.1               # vers pve-dl380-bureaux

# 3. Valider le MTU 9000 de bout en bout (jumbo frames)
# -M do = interdire la fragmentation, -s 8972 = payload max avec MTU 9000
ping -M do -s 8972 10.0.10.2

# 4. Test de debit (lancer iperf3 sur un noeud, tester depuis l'autre)
# Sur pve-dl380-usine :
iperf3 -s -B 10.0.10.2

# Sur pve-dl380-bureaux :
iperf3 -c 10.0.10.2 -B 10.0.10.1 -t 30
# Attendu : ~9.3-9.9 Gbps sur lien LRM 10G

Si le lien 10G ne monte pas

Verifier dans l'ordre :

Transceiver insere ? — ethtool nic5 doit montrer Link detected: yes
Signal RX ? — ethtool -m nic5 : Receiver signal doit etre > -16 dBm (si -40 dBm = pas de lumiere recue)
Bon port ? — les LRM vont dans les ports SFP+ de la 534FLR, pas dans les ports iLO ou 1G
Fibre connectee ? — verifier les jarretieres LC-LC aux deux extremites
Driver charge ? — dmesg | grep bnx2x doit montrer la detection de la NIC
Module reconnu ? — ethtool -m nic5 affiche les infos du transceiver (vendor FS, PN SFP-10GLRM-31)

Validation du reseau Ceph 10G (phase 2 : 3 noeuds full mesh)¶

Apres ajout du DL360, decommenter les interfaces nic4 sur les DL380 et valider tous les liens :

# Depuis pve-dl380-bureaux — tester les 2 liens
ping -M do -s 8972 10.0.10.2      # vers pve-dl380-usine (nic5, fibre)
ping -M do -s 8972 10.0.10.6      # vers pve-dl360 (nic4, fibre)

# Depuis pve-dl380-usine — tester les 2 liens
ping -M do -s 8972 10.0.10.1      # vers pve-dl380-bureaux (nic5, fibre)
ping -M do -s 8972 10.0.10.10     # vers pve-dl360 (nic4, DAC)

# Depuis pve-dl360 — tester les 2 liens
ping -M do -s 8972 10.0.10.5      # vers pve-dl380-bureaux (fibre)
ping -M do -s 8972 10.0.10.9      # vers pve-dl380-usine (DAC)

Routage mesh pour Ceph¶

En full mesh, chaque noeud a 2 interfaces sur 2 sous-reseaux differents. Ceph doit pouvoir atteindre les 3 noeuds. En full mesh point-a-point, chaque noeud est directement connecte aux deux autres par un lien physique dedie — aucune route supplementaire n'est necessaire.

Configuration Ceph reseau¶

Lors de l'initialisation de Ceph, specifier le reseau public (et optionnellement le reseau cluster) :

# Initialisation Ceph sur le premier noeud
pveceph init --network 10.0.10.0/24

Ceph utilisera toutes les interfaces dans le range 10.0.10.0/24 pour le trafic OSD. Dans cette architecture full mesh, le reseau public et le reseau cluster partagent le meme plan d'adressage car chaque lien est dedie (pas de contention possible).

Public vs cluster network

Separer public et cluster network est utile quand ils partagent un switch (pour eviter que la replication sature le trafic client). En full mesh point-a-point, chaque lien a sa propre bande passante dediee — la separation n'apporte rien et complique la configuration.

Reseau de migration live¶

La migration live transfere la RAM des VMs entre noeuds. Configurer Proxmox pour utiliser le reseau 10G Ceph plutot que le management 1G :

# /etc/pve/datacenter.cfg
migration: secure,network=10.0.10.0/24

Impact sur les temps de migration

Une VM avec 32 Go de RAM :

Sur le management 1G : ~4-5 minutes
Sur le mesh 10G : ~25-30 secondes

Le gain est critique pour la HA : en cas de panne d'un noeud, les VMs redemarrent plus vite sur les noeuds restants.

Corosync¶

Corosync gere le quorum du cluster Proxmox. Il utilise par defaut le reseau de management (vmbr0, 10.1.230.0/24). C'est suffisant pour cette architecture :

Le trafic Corosync est tres faible (~quelques Ko/s)
Le reseau 1G management n'est pas sature (pas de trafic VM lourd dessus)
Ajouter un ring Corosync sur le mesh 10G est possible mais pas necessaire avec 3 noeuds

Si souhaite, ajouter un second ring Corosync via l'interface web Proxmox (Datacenter > Cluster > lien Corosync) sur le reseau 10G pour la redondance.

Pare-feu Fortigate — Regles a ajouter¶

Les noeuds Proxmox communiquent entre eux sur le VLAN 230. Verifier que le Fortigate autorise :

Source	Destination	Port	Protocole	Usage
10.1.230.30-32	10.1.230.30-32	8006	TCP	Interface web PVE
10.1.230.30-32	10.1.230.30-32	5404-5405	UDP	Corosync
10.1.230.30-32	10.1.230.30-32	22	TCP	SSH (administration)
10.1.230.30-32	10.1.230.30-32	3128	TCP	SPICE proxy
10.1.230.30-32	10.1.230.30-32	111, 2049	TCP/UDP	NFS (si backup NAS)
Poste admin	10.1.230.30-32	8006	TCP	Acces web PVE
10.1.230.30-32	0.0.0.0/0	80, 443	TCP	Mises a jour APT

Le reseau Ceph 10G n'est PAS concerne

Le mesh 10G est physiquement isole (point-a-point sans switch ni routeur). Aucune regle firewall n'est necessaire — le trafic ne traverse jamais le Fortigate.

3. Stockage¶

Proxmox VE supporte de nombreux backends de stockage. Le choix depend de votre architecture et de vos besoins.

Stockage local par defaut¶

Apres l'installation, deux stockages locaux sont configures :

Stockage	Type	Utilisation
`local`	Directory (`/var/lib/vz`)	ISOs, templates de conteneurs, backups, snippets
`local-lvm`	LVM-thin	Disques VM et conteneurs (si pas de Ceph)

Configuration dans `/etc/pve/storage.cfg`¶

dir: local
    path /var/lib/vz
    content iso,vztmpl,backup,snippets

lvmthin: local-lvm
    thinpool data
    vgname pve
    content rootdir,images

ZFS pour le stockage local¶

ZFS est recommande pour le stockage local grace a ses fonctionnalites avancees (snapshots atomiques, compression, checksums, scrub automatique) :

# Si ZFS n'a pas ete choisi lors de l'installation, creer un pool
zpool create -f -o ashift=12 rpool mirror /dev/sda /dev/sdb

# Creer un dataset pour les VMs
zfs create rpool/data
zfs set compression=lz4 rpool/data
zfs set atime=off rpool/data
zfs set xattr=sa rpool/data

Ajouter le stockage ZFS dans Proxmox :

pvesm add zfspool local-zfs -pool rpool/data -content images,rootdir

Ou via /etc/pve/storage.cfg :

zfspool: local-zfs
    pool rpool/data
    content images,rootdir
    sparse 1

Info

ZFS et Ceph ne sont pas mutuellement exclusifs. Vous pouvez utiliser ZFS pour le stockage local (OS, ISOs, backups) et Ceph pour le stockage distribue des VMs.

Ceph¶

Le stockage Ceph est detaille dans la section suivante. C'est la solution recommandee pour un cluster hyper-converge car elle offre la replication des donnees entre les noeuds et la haute disponibilite du stockage.

4. Deploiement Ceph — Full SSD¶

Ceph est un systeme de stockage distribue integre nativement dans Proxmox VE. Il permet de creer un stockage partage replique entre tous les noeuds du cluster.

Prerequis pour ce cluster¶

3 noeuds : pve-dl380-bureaux, pve-dl380-usine, pve-dl360 (phase 2)
Reseau 10G dedie : full mesh point-a-point (10.0.10.0/24)
Full SSD : pas de HDD dans Ceph (les HDD du DL360 sont exclus de Ceph, reserves au stockage local)
Controleur P408i-a en mode JBOD — Ceph gere lui-meme la redondance, pas de RAID hardware

Pas de RAID hardware avec Ceph

Ne jamais utiliser de RAID hardware avec Ceph. Un RAID hardware masque les erreurs disque, degrade les performances et complique le remplacement des disques. Configurer le HPE Smart Array P408i-a en mode JBOD (ou HBA mode si disponible).

# Verifier le mode du controleur
ssacli ctrl slot=0 show config
# Si des arrays existent, les supprimer et passer en JBOD :
ssacli ctrl slot=0 modify hbamode=on

Inventaire disques par noeud :

Noeud	Disques Ceph	Capacite brute
pve-dl380-bureaux	5x SSD 500 Go	2,5 To
pve-dl380-usine	5x SSD 500 Go	2,5 To
pve-dl360 (phase 2)	4x SSD 400 Go (873351-B21, SAS 12G WI)	1,6 To
Total brut	14 SSD	6,6 To

Capacite utile avec replica size=3 : ~2,2 To (seuil nearfull 80% : ~1,7 To confortablement allouables)

RAM requise pour les OSD

Minimum 4 Go par OSD (osd_memory_target). Avec 5 OSD par DL380 : 20 Go reserves pour Ceph, il reste ~108 Go pour les VMs (sur 128 Go).

Installation de Ceph¶

Executer sur chaque noeud :

pveceph install --version squid

Info

Ou via l'interface web : Datacenter > noeud > Ceph > Installation. La CLI est utile pour l'automatisation.

Configuration reseau Ceph¶

A l'initialisation, specifier le reseau du mesh 10G. Executer sur le premier noeud uniquement :

pveceph init --network 10.0.10.0/24

Cela genere /etc/pve/ceph.conf (partage entre tous les noeuds via pmxcfs) :

[global]
    auth_client_required = cephx
    auth_cluster_required = cephx
    auth_service_required = cephx
    public_network = 10.0.10.0/24
    fsid = <genere-automatiquement>
    mon_allow_pool_delete = true
    osd_pool_default_min_size = 2
    osd_pool_default_size = 3

[mon]
    mon_warn_on_pool_no_redundancy = true

Pas de cluster_network separe

En full mesh point-a-point, chaque lien a sa propre bande passante dediee — la separation public/cluster n'apporte rien. Un seul reseau public_network sur 10.0.10.0/24 suffit.

Deploiement des Monitors (MON)¶

Les monitors maintiennent la carte du cluster. Il faut un nombre impair pour le quorum.

Phase 1 (2 noeuds) :

# Creer un monitor sur chaque DL380
# Sur pve-dl380-bureaux :
pveceph createmon

# Sur pve-dl380-usine :
pveceph createmon

# Ceph exige un nombre impair de monitors.
# Creer un 3e monitor sur une VM legere (Debian minimal, 512 Mo RAM)
# hebergee sur un des DL380 — c'est un arbitre temporaire.
# Sur la VM arbitre :
pveceph createmon

Phase 2 (3 noeuds) :

# Ajouter le monitor sur pve-dl360
pveceph createmon

# Supprimer le monitor-arbitre VM (maintenant inutile)
pveceph destroymon <id-mon-vm>

# Verifier : 3 monitors sur 3 hosts physiques
ceph mon stat

Deploiement des Managers (MGR)¶

# Creer un manager sur chaque noeud (minimum 2 pour la redondance)
pveceph createmgr

# Verifier
ceph mgr stat

Deploiement des OSD¶

Chaque OSD correspond a un SSD physique. Pas de DB/WAL device separe (les SSD sont assez rapides).

Phase 1 — 2 noeuds, 10 OSD :

# Sur chaque DL380, lister les disques disponibles
lsblk

# Creer un OSD par SSD (5 par noeud)
# Exemple sur pve-dl380-bureaux :
pveceph osd create /dev/sda
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc
pveceph osd create /dev/sdd
pveceph osd create /dev/sde

# Idem sur pve-dl380-usine

# Verifier l'arbre des OSD
ceph osd tree
# Attendu : 10 OSD (5 par host), tous UP

Phase 2 — ajout DL360, 14 OSD total :

# Sur pve-dl360 (4x SSD 400 Go 873351-B21)
pveceph osd create /dev/sda
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc
pveceph osd create /dev/sdd

# Verifier le rebalancing
ceph -w   # suivre en temps reel
ceph osd tree
# Attendu : 14 OSD (5+5+4), tous UP

Rebalancing apres ajout du DL360

Ceph va redistribuer ~33% des donnees vers le nouveau noeud. Pendant ce processus :

Les performances sont degradees (mais les VMs restent accessibles)
Les SSD SAS Write Intensive (873351-B21) encaissent bien les ecritures massives (10 DWPD)
Surveiller avec ceph -s et attendre HEALTH_OK avant tout autre changement

Creation du pool SSD¶

Un seul pool, full SSD, pour toutes les VMs et conteneurs :

Phase 1 (2 noeuds) :

# Replica size=2 (seules 2 copies possibles avec 2 noeuds)
pveceph pool create ssd-pool --size 2 --min_size 1

# Verifier
ceph osd pool ls detail

Phase 1 : size=2, min_size=1

Perte d'un DL380 = donnees accessibles mais sans redondance. Les backups Veeam quotidiens couvrent ce risque.

Phase 2 (3 noeuds) — passage en replica 3 :

# Augmenter la replication
ceph osd pool set ssd-pool size 3
ceph osd pool set ssd-pool min_size 2

# Ceph va repliquer les donnees sur le 3e noeud — surveiller :
ceph -w

Pas de CRUSH rules SSD/HDD

Ce cluster est full SSD — pas besoin de rules CRUSH pour separer les classes de disques. Les HDD du DL360 sont exclus de Ceph et reserves au stockage local (ISOs, templates, backups secondaires).

PG Autoscaler¶

Le PG autoscaler est active par defaut. Verifier :

ceph osd pool autoscale-status
ceph config set mgr mgr/pg_autoscaler/autoscale_mode on

Configuration du scrub¶

Le scrub verifie l'integrite des donnees. Planifier en dehors des heures de production :

# Limiter le scrub aux heures creuses (2h-6h du matin)
ceph config set osd osd_scrub_begin_hour 2
ceph config set osd osd_scrub_end_hour 6

# Scrub en profondeur une fois par semaine
ceph config set osd osd_deep_scrub_interval 604800

Tuning du recovery¶

Lors du remplacement d'un disque ou de l'ajout du DL360, Ceph redistribue les donnees :

# Limiter l'impact du recovery sur les performances VM
ceph config set osd osd_recovery_max_active 3
ceph config set osd osd_recovery_sleep 0.1
ceph config set osd osd_max_backfills 1

# Pour accelerer le recovery (hors heures de prod, ex: week-end)
# ceph config set osd osd_recovery_max_active 10
# ceph config set osd osd_recovery_sleep 0
# ceph config set osd osd_max_backfills 3

Verification finale¶

# Le cluster doit etre en HEALTH_OK
ceph -s
ceph health detail

# Verifier l'espace disponible
ceph df
# Attendu phase 1 : ~5 To brut, ~2,5 To utile (size=2)
# Attendu phase 2 : ~6,6 To brut, ~2,2 To utile (size=3)

5. Configuration cluster¶

Le cluster Proxmox VE utilise Corosync pour la communication inter-noeuds et le quorum.

Creation du cluster (phase 1 — 2 noeuds)¶

Sur pve-dl380-bureaux (premier noeud) :

pvecm create clu-soreal --link0 10.1.230.30

Sur pve-dl380-usine :

pvecm add 10.1.230.30 --link0 10.1.230.31

# Verifier l'etat du cluster
pvecm status
pvecm nodes

Danger

Ne jamais ajouter un noeud qui contient deja des VMs ou des conteneurs. Le noeud doit etre fraichement installe. L'ajout detruit la configuration locale du noeud.

Quorum a 2 noeuds¶

Le quorum necessite la majorite des noeuds (N/2 + 1). Avec 2 noeuds, configurer les votes pour eviter le blocage :

# Temporairement, autoriser le fonctionnement avec 1 seul noeud
pvecm expected 1

Phase 1 : pas de quorum reel

A 2 noeuds sans QDevice, la perte d'un noeud bloque le cluster (pas de majorite). C'est acceptable en phase 1 car la migration vers les 3 noeuds arrive rapidement. Si le delai est long, envisager un QDevice sur une VM externe.

Ajout du DL360 (phase 2)¶

Sur pve-dl360 :

pvecm add 10.1.230.30 --link0 10.1.230.32

# Verifier : 3 noeuds, quorum OK
pvecm status
pvecm nodes
# Le quorum est maintenant 2/3 — tolerant a la perte d'un noeud

Fencing (cloture)¶

Le fencing empeche un noeud defaillant de corrompre les donnees en l'isolant du cluster.

Watchdog (defaut) — Le noeud se redemarrera automatiquement s'il perd le quorum :

# Verifier que le watchdog est actif
cat /etc/default/pve-ha-manager
# WATCHDOG_MODULE=softdog (defaut)

Fencing hardware via iLO — Recommande en production :

Les DL380/DL360 ont des interfaces iLO accessibles sur le VLAN 250. Cela permet a Proxmox de forcer le redemarrage d'un noeud defaillant via IPMI :

# Installer ipmitool
apt install ipmitool

# Tester l'acces iLO depuis un noeud
ipmitool -I lanplus -H 10.1.250.15 -U admin -P <password> power status
ipmitool -I lanplus -H 10.1.250.16 -U admin -P <password> power status

Noeud	Adresse iLO
pve-dl380-bureaux	10.1.250.15
pve-dl380-usine	10.1.250.16
pve-dl360	(a documenter)

La configuration du fencing hardware se fait via l'interface web sous Datacenter > HA > Fencing.

HA Manager¶

Configurer les groupes HA pour definir quels noeuds peuvent heberger quelles VMs :

# Creer un groupe HA avec les 3 noeuds
ha-manager groupadd production --nodes pve-dl380-bureaux,pve-dl380-usine,pve-dl360 --nofailback 0

# Ajouter les VMs de prod au HA
ha-manager add vm:100 --group production --state started --max_restart 3 --max_relocate 2
ha-manager add vm:101 --group production --state started --max_restart 3 --max_relocate 2

Politiques de migration :

migrate : migration live (sans interruption) — utilise par defaut
relocate : arret puis redemarrage sur un autre noeud — utilise si la migration live echoue

# Verifier l'etat du HA
ha-manager status

Reseau de migration¶

La migration live utilise le mesh 10G (configure dans la section reseau) :

# /etc/pve/datacenter.cfg
migration: secure,network=10.0.10.0/24

6. Securite¶

La securisation de votre cluster Proxmox est essentielle, surtout s'il est expose au reseau de l'entreprise.

Durcissement SSH¶

Editer /etc/ssh/sshd_config :

# Interdire le login root par mot de passe (autoriser uniquement par cle)
PermitRootLogin prohibit-password

# Desactiver l'authentification par mot de passe
PasswordAuthentication no

# Port SSH non standard (optionnel, security through obscurity)
# Port 2222

# Limiter les utilisateurs autorises
AllowUsers root@192.168.1.0/24 admin

# Timeout d'inactivite
ClientAliveInterval 300
ClientAliveCountMax 2

# Deployer votre cle publique SSH
mkdir -p ~/.ssh
chmod 700 ~/.ssh
# Copier votre cle publique dans ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Redemarrer SSH
systemctl restart sshd

Danger

Avant de desactiver l'authentification par mot de passe, assurez-vous que votre cle SSH est correctement deployee et fonctionnelle. Testez dans une seconde session SSH avant de fermer la session actuelle.

Authentification a deux facteurs (2FA)¶

Activer le TOTP via l'interface web :

Aller dans Datacenter > Permissions > Two Factor
Cliquer Add > TOTP
Scanner le QR code avec une application TOTP (Google Authenticator, Authy, etc.)

# Forcer le 2FA pour un realm
pveum realm modify pam --tfa type=totp

API tokens¶

Creer des tokens avec des permissions limitees au lieu d'utiliser le compte root :

# Creer un utilisateur dedie pour l'automatisation
pveum user add automation@pve --password <password>

# Creer un role personnalise
pveum role add VMAdmin --privs "VM.Audit VM.Console VM.PowerMgmt VM.Monitor"

# Assigner le role
pveum acl modify / --users automation@pve --roles VMAdmin

# Creer un API token
pveum user token add automation@pve monitoring-token --privsep 1

# Assigner des permissions au token
pveum acl modify / --tokens automation@pve!monitoring-token --roles VMAdmin

Info

L'option --privsep 1 active la separation de privileges : le token n'aura que les permissions qui lui sont explicitement attribuees, independamment des permissions de l'utilisateur parent.

Firewall Proxmox¶

Activer le firewall au niveau datacenter puis au niveau de chaque noeud :

Datacenter (/etc/pve/firewall/cluster.fw) :

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
# Autoriser l'interface web PVE
IN ACCEPT -p tcp -dport 8006 -source 192.168.1.0/24
# Autoriser SSH
IN ACCEPT -p tcp -dport 22 -source 192.168.1.0/24
# Autoriser Corosync
IN ACCEPT -p udp -dport 5405:5412 -source 192.168.1.0/24
# Autoriser le trafic Ceph
IN ACCEPT -p tcp -dport 6789 -source 10.10.10.0/24
IN ACCEPT -p tcp -dport 6800:7300 -source 10.10.10.0/24
# Autoriser la migration live
IN ACCEPT -p tcp -dport 8002 -source 10.10.10.0/24
IN ACCEPT -p tcp -dport 60000:60050 -source 10.10.10.0/24

Noeud (/etc/pve/nodes/<nodename>/host.fw) :

[OPTIONS]
enable: 1

Warning

Activez le firewall progressivement : d'abord testez les regles au niveau d'une VM, puis d'un noeud, puis du datacenter. Une mauvaise regle peut vous bloquer l'acces a l'interface web. Gardez toujours un acces console (IPMI/iLO) en secours.

Certificats TLS¶

Remplacer les certificats auto-signes par des certificats Let's Encrypt ou d'une CA interne :

# Via Let's Encrypt (necessite que le port 80 soit accessible depuis Internet)
pvenode acme account register default <email@example.com> --directory https://acme-v02.api.letsencrypt.org/directory

# Configurer le domaine
pvenode config set --acme domains=pve1.example.com

# Commander le certificat
pvenode acme cert order

Pour une CA interne :

# Copier le certificat et la cle
cp /path/to/cert.pem /etc/pve/nodes/<nodename>/pveproxy-ssl.pem
cp /path/to/key.pem /etc/pve/nodes/<nodename>/pveproxy-ssl.key

systemctl restart pveproxy

Permissions PVE — principe du moindre privilege¶

# Creer des roles personnalises
pveum role add Operator --privs "VM.Audit VM.Console VM.PowerMgmt VM.Snapshot VM.Backup VM.Monitor Datastore.Audit"
pveum role add ViewOnly --privs "VM.Audit Datastore.Audit Sys.Audit"

# Creer un pool de ressources
pveum pool add production

# Assigner des permissions sur un pool
pveum acl modify /pool/production --users operateur@pve --roles Operator

# Verifier les permissions
pveum acl list

7. Strategie de sauvegarde¶

Les sauvegardes sont votre derniere ligne de defense. Une strategie robuste couvre plusieurs niveaux de protection.

Proxmox Backup Server (PBS)¶

PBS est la solution recommandee par Proxmox. Il offre la deduplication, la compression et la verification d'integrite :

# Ajouter un PBS comme stockage dans Proxmox VE
pvesm add pbs pbs-backup \
    --server 192.168.1.50 \
    --datastore main \
    --username backup@pbs!token \
    --password <token-secret> \
    --fingerprint <fingerprint-du-serveur>

Configuration PBS dans /etc/pve/storage.cfg :

pbs: pbs-backup
    datastore main
    server 192.168.1.50
    content backup
    fingerprint <sha256-fingerprint>
    username backup@pbs!token

Veeam Backup & Replication 12.1+¶

Depuis la version 12.1, Veeam supporte nativement Proxmox VE :

Ajouter les hyperviseurs Proxmox dans la console Veeam
Creer des jobs de backup classiques ciblant les VMs Proxmox
La restauration granulaire est supportee

Info

Veeam communique avec Proxmox via l'API. Creez un API token dedie avec les permissions necessaires plutot que d'utiliser root@pam.

Strategie de retention GFS¶

Configurer une politique Grandfather-Father-Son pour une retention optimale :

# Exemple de job vzdump avec retention GFS
# Via /etc/pve/jobs.cfg ou l'interface web (Datacenter > Backup)

Configuration via l'interface web — Datacenter > Backup > Add :

Parametre	Valeur
Storage	pbs-backup
Schedule	Tous les jours a 01:00
Mode	Snapshot
Keep Daily	7
Keep Weekly	4
Keep Monthly	6
Keep Yearly	2

Ou via la ligne de commande :

# Sauvegarde manuelle d'une VM
vzdump 100 --storage pbs-backup --mode snapshot --compress zstd

# Sauvegarde de toutes les VMs d'un pool
vzdump --pool production --storage pbs-backup --mode snapshot --compress zstd

Verification des sauvegardes¶

# Sur le PBS — verification d'integrite
proxmox-backup-client verify --repository backup@pbs@192.168.1.50:main

# Tester une restauration regulierement (au moins mensuelle)
# Restaurer sur un stockage temporaire, verifier le bon fonctionnement, puis supprimer

Danger

Une sauvegarde non testee n'est pas une sauvegarde. Planifiez un test de restauration au moins une fois par mois. Documentez la procedure et le temps de restauration (RTO).

Copies hors-site¶

# Replication PBS vers un second site
# Sur le PBS distant, configurer un Sync Job :
# Remote > Add Remote (pointer vers le PBS source)
# Datastore > Sync Jobs > Add

# Ou vers un stockage S3
# PBS supporte la synchronisation vers des backends S3-compatible

vzdump pour les sauvegardes locales¶

Pour des sauvegardes simples sans PBS :

# Sauvegarde locale d'une VM
vzdump 100 --dumpdir /var/lib/vz/dump --mode snapshot --compress zstd

# Restaurer
qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 100 --storage local-lvm

8. Optimisation des performances¶

CPU¶

Activer NUMA pour les serveurs multi-sockets :

# Dans la configuration de la VM (/etc/pve/qemu-server/<vmid>.conf)
numa: 1

Ou via l'interface web : VM > Hardware > Processors > Enable NUMA.

Type de CPU :

# Meilleures performances (expose le CPU reel a la VM)
cpu: host

# Pour la compatibilite de migration entre CPU differents
cpu: x86-64-v2-AES

Info

Utilisez cpu: host si tous vos noeuds ont le meme modele de CPU. Utilisez x86-64-v2-AES (ou un type generique) si vos noeuds ont des CPU differents et que vous avez besoin de la migration live.

Memoire¶

Ballooning — gestion dynamique de la RAM :

# Dans la configuration VM
balloon: 2048
memory: 8192
# La VM demarre avec 8 Go max mais peut liberer de la RAM jusqu'a 2 Go minimum

Hugepages — pour les workloads memoire-intensifs (bases de donnees, etc.) :

# Ajouter dans /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet hugepagesz=2M hugepages=4096"

# Appliquer
update-grub
reboot

# Verifier
cat /proc/meminfo | grep HugePages

# Dans la configuration VM
hugepages: 2

Warning

Les hugepages reservent de la RAM au demarrage du serveur. Calculez soigneusement la quantite necessaire. La RAM reservee pour les hugepages n'est pas disponible pour le systeme hote ou les VMs sans hugepages.

Disques et I/O¶

IO Scheduler — pour les SSD avec Ceph :

# Verifier le scheduler actuel
cat /sys/block/sda/queue/scheduler

# Configurer pour les SSD (none = noop)
echo "none" > /sys/block/sda/queue/scheduler

# Rendre permanent via une regle udev
cat > /etc/udev/rules.d/60-io-scheduler.rules << 'EOF'
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
EOF

Cache disque VM :

# Pas de cache (recommande pour Ceph et ZFS)
cache=none

# Writeback (uniquement avec un controleur RAID avec batterie/supercap)
cache=writeback

VirtIO — toujours utiliser VirtIO pour les disques et le reseau :

# Disque VirtIO (dans la config VM)
virtio0: ceph-pool:vm-100-disk-0,iothread=1,size=50G

# Reseau VirtIO
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0

Info

VirtIO offre les meilleures performances en virtualisation KVM. Les pilotes VirtIO sont inclus dans les noyaux Linux. Pour Windows, installez les pilotes VirtIO depuis l'ISO fournie par Fedora/Red Hat (disponible dans Proxmox sous le nom virtio-win).

Tuning Ceph¶

# Memoire par OSD (defaut 4 Go, ajuster selon la RAM disponible)
ceph config set osd osd_memory_target 4294967296

# Si vous avez beaucoup de RAM et peu d'OSD, augmenter
# ceph config set osd osd_memory_target 8589934592  # 8 Go

# Desactiver le cache de lecture si vous avez des SSD/NVMe rapides
ceph config set osd bluestore_cache_autotune true

# Nombre de threads de recovery
ceph config set osd osd_recovery_threads 1

9. Supervision¶

La supervision proactive est indispensable pour anticiper les problemes avant qu'ils n'affectent les services.

Metriques integrees¶

L'interface web Proxmox fournit des metriques en temps reel :

Noeud : CPU, RAM, swap, load average, trafic reseau, I/O disque
VM/CT : memes metriques par machine virtuelle ou conteneur
Stockage : espace utilise/disponible par stockage
Ceph : etat du cluster, IOPS, bande passante, latence

Ceph Dashboard¶

Le dashboard Ceph est integre a l'interface Proxmox :

Aller dans noeud > Ceph > Dashboard pour voir :

Etat general du cluster (HEALTH_OK, HEALTH_WARN, HEALTH_ERR)
Nombre d'OSD up/in/down/out
Espace utilise et disponible
IOPS et throughput en temps reel

Exportation vers un serveur de metriques externe¶

Configurer l'envoi de metriques vers InfluxDB ou Graphite dans /etc/pve/status.cfg :

influxdb: influx1
    server 192.168.1.60
    port 8089

# Ou pour Graphite
graphite: graphite1
    server 192.168.1.61
    port 2003

Zabbix¶

Utiliser le template Proxmox officiel avec l'API :

# Creer un utilisateur dedie pour Zabbix
pveum user add zabbix@pve --password <password>
pveum role add Monitoring --privs "Sys.Audit VM.Audit Datastore.Audit"
pveum acl modify / --users zabbix@pve --roles Monitoring

# Creer un API token
pveum user token add zabbix@pve monitoring --privsep 1
pveum acl modify / --tokens zabbix@pve!monitoring --roles Monitoring

Importer le template Zabbix Proxmox et configurer l'hote avec les macros :

Macro	Valeur
`{$PVE.URL}`	`https://192.168.1.10:8006/api2/json`
`{$PVE.TOKEN.ID}`	`zabbix@pve!monitoring`
`{$PVE.TOKEN.SECRET}`	`<token-secret>`

Grafana avec Prometheus¶

# Sur chaque noeud Proxmox, installer node_exporter
apt install prometheus-node-exporter -y
systemctl enable prometheus-node-exporter

# Pour Ceph, activer le module prometheus
ceph mgr module enable prometheus
# Le endpoint est accessible sur http://<noeud>:9283/metrics

Configuration Prometheus (prometheus.yml) :

scrape_configs:
  - job_name: 'proxmox-node'
    static_configs:
      - targets:
          - '192.168.1.10:9100'
          - '192.168.1.11:9100'
          - '192.168.1.12:9100'

  - job_name: 'ceph'
    static_configs:
      - targets:
          - '192.168.1.10:9283'

Alertes recommandees¶

Configurez des alertes pour les evenements critiques suivants :

Alerte	Seuil	Severite
Ceph Health	!= HEALTH_OK	Critique
OSD down	tout OSD down	Critique
Espace disque Ceph	> 80% utilise	Warning
Espace disque Ceph	> 90% utilise	Critique
Latence reseau Corosync	> 5 ms	Warning
RAM noeud	> 90% utilisee	Warning
CPU noeud	> 90% soutenu (15 min)	Warning
Etat sauvegarde	echec d'un job vzdump	Critique
Ceph scrub	erreurs detectees	Critique

10. Procedures de maintenance¶

Mises a jour rolling (sans interruption de service)¶

Mettre a jour un noeud a la fois pour maintenir le quorum et la disponibilite :

# 1. Verifier l'etat du cluster avant de commencer
pvecm status
ceph -s  # Doit etre HEALTH_OK

# 2. Desactiver le rebalancing Ceph
ceph osd set noout

# 3. Migrer les VMs HA du noeud (optionnel mais recommande)
# Via l'interface web ou :
ha-manager migrate vm:100 pve2

# 4. Mettre a jour le noeud
apt update && apt full-upgrade -y

# 5. Rebooter si necessaire (mise a jour noyau)
reboot

# 6. Apres le reboot, verifier
pvecm status
ceph -s
ceph osd tree  # Tous les OSD du noeud doivent etre "up"

# 7. Passer au noeud suivant. Une fois tous les noeuds mis a jour :
ceph osd unset noout

Warning

Ne mettez jamais a jour plus d'un noeud a la fois. Attendez que le noeud soit completement revenu dans le cluster et que Ceph soit en HEALTH_OK avant de passer au noeud suivant.

Maintenance Ceph — flags noout¶

# Avant toute maintenance sur un noeud (reboot, remplacement materiel)
ceph osd set noout

# Faire la maintenance...

# Apres la maintenance, quand le noeud est revenu
ceph osd unset noout

# Verifier que le rebalancing reprend normalement
ceph -w  # Observer les evenements en temps reel

Info

Le flag noout empeche Ceph de marquer les OSD comme "out" apres un delai (10 minutes par defaut). Sans ce flag, Ceph commencerait a redistribuer les donnees inutilement pendant un simple reboot.

Evacuation d'un noeud¶

# Migrer toutes les VMs HA
for vmid in $(ha-manager status | grep "started" | grep "pve1" | awk '{print $2}'); do
    ha-manager migrate $vmid pve2
done

# Migrer les VMs non-HA
for vmid in $(qm list | grep running | awk '{print $1}'); do
    qm migrate $vmid pve2 --online
done

# Marquer les OSD du noeud comme out (declenche le rebalancing)
ceph osd out <osd_id>

Ajout d'un nouveau noeud¶

# 1. Installer Proxmox VE sur le nouveau serveur
# 2. Configurer le reseau (meme schema que les autres noeuds)
# 3. Configurer NTP, DNS, /etc/hosts

# 4. Joindre le cluster (depuis le nouveau noeud)
pvecm add 192.168.1.10

# 5. Installer Ceph
pveceph install --version squid

# 6. Creer les services Ceph
pveceph createmon
pveceph createmgr

# 7. Ajouter les OSD
pveceph osd create /dev/sdc
pveceph osd create /dev/sdd

# 8. Verifier
pvecm status
ceph -s
ceph osd tree

Retrait d'un noeud¶

# 1. Migrer toutes les VMs et conteneurs vers d'autres noeuds
# 2. Retirer les OSD Ceph du noeud

# Pour chaque OSD du noeud :
ceph osd out <osd_id>
# Attendre que le rebalancing soit termine
ceph -w
# Quand HEALTH_OK :
systemctl stop ceph-osd@<osd_id>
ceph osd destroy <osd_id> --yes-i-really-mean-it
ceph osd purge <osd_id> --yes-i-really-mean-it

# 3. Retirer le monitor et le manager
pveceph destroymon
pveceph destroymgr

# 4. Retirer le noeud du cluster (depuis un AUTRE noeud)
pvecm delnode <nodename>

# 5. Sur le noeud retire, arreter les services
systemctl stop pve-cluster corosync
pmxcfs -l  # Mode local
rm /etc/corosync/*
rm /etc/pve/corosync.conf
killall pmxcfs
systemctl start pve-cluster

Danger

Le retrait d'un noeud est une operation delicate. Assurez-vous que toutes les donnees Ceph sont redistribuees (HEALTH_OK) avant de detruire les OSD. Ne forcez jamais la suppression d'un OSD si le cluster n'est pas sain.

Remplacement d'un disque OSD¶

# 1. Identifier l'OSD et le disque defaillant
ceph osd tree
ceph health detail

# 2. Marquer l'OSD comme out (declenche le rebalancing)
ceph osd out <osd_id>

# 3. Attendre la fin du rebalancing
ceph -w
# Attendre "HEALTH_OK" ou "active+clean" sur tous les PG

# 4. Arreter l'OSD
systemctl stop ceph-osd@<osd_id>

# 5. Detruire l'OSD
ceph osd destroy <osd_id> --yes-i-really-mean-it
ceph osd purge <osd_id> --yes-i-really-mean-it

# 6. Retirer physiquement le disque et inserer le nouveau

# 7. Creer un nouvel OSD sur le nouveau disque
pveceph osd create /dev/sdX

# 8. Verifier le rebalancing
ceph -w
ceph osd tree

Info

Selon la quantite de donnees, le rebalancing peut prendre de quelques minutes a plusieurs heures. Pendant ce temps, le cluster fonctionne normalement mais avec des performances potentiellement reduites. Evitez de remplacer plusieurs disques simultanement.

Guide de deploiement Proxmox VE 9.x avec Ceph¶

Table des matieres¶

1. Configuration post-installation¶

Desactiver le depot enterprise et activer le depot no-subscription¶

Supprimer le popup de souscription (optionnel)¶

Mettre a jour le systeme¶

Configurer NTP avec chrony¶

Verifier la configuration DNS¶

2. Configuration reseau¶

Vue d'ensemble des reseaux¶

Adressage des noeuds¶

Topologie Ceph — Full Mesh 10G¶

Interfaces physiques par noeud¶

Configuration reseau — pve-dl380-bureaux (bat. A)¶

Configuration reseau — pve-dl380-usine (bat. B)¶

Configuration reseau — pve-dl360 (bat. B) [phase 2]¶

Validation du reseau management (post-installation)¶

Validation du reseau Ceph 10G (phase 1 : 2 noeuds)¶

Validation du reseau Ceph 10G (phase 2 : 3 noeuds full mesh)¶

Routage mesh pour Ceph¶

Configuration Ceph reseau¶

Reseau de migration live¶

Corosync¶

Pare-feu Fortigate — Regles a ajouter¶

3. Stockage¶

Stockage local par defaut¶

Configuration dans /etc/pve/storage.cfg¶

ZFS pour le stockage local¶

Ceph¶

4. Deploiement Ceph — Full SSD¶

Prerequis pour ce cluster¶

Installation de Ceph¶

Configuration reseau Ceph¶

Deploiement des Monitors (MON)¶

Deploiement des Managers (MGR)¶

Deploiement des OSD¶

Creation du pool SSD¶

PG Autoscaler¶

Configuration du scrub¶

Tuning du recovery¶

Verification finale¶

5. Configuration cluster¶

Creation du cluster (phase 1 — 2 noeuds)¶

Quorum a 2 noeuds¶

Ajout du DL360 (phase 2)¶

Fencing (cloture)¶

HA Manager¶

Reseau de migration¶

6. Securite¶

Durcissement SSH¶

Authentification a deux facteurs (2FA)¶

API tokens¶

Firewall Proxmox¶

Certificats TLS¶

Permissions PVE — principe du moindre privilege¶

7. Strategie de sauvegarde¶

Proxmox Backup Server (PBS)¶

Veeam Backup & Replication 12.1+¶

Strategie de retention GFS¶

Verification des sauvegardes¶

Copies hors-site¶

vzdump pour les sauvegardes locales¶

8. Optimisation des performances¶

CPU¶

Memoire¶

Disques et I/O¶

Tuning Ceph¶

9. Supervision¶

Metriques integrees¶

Ceph Dashboard¶

Exportation vers un serveur de metriques externe¶

Zabbix¶

Grafana avec Prometheus¶

Alertes recommandees¶

10. Procedures de maintenance¶

Mises a jour rolling (sans interruption de service)¶

Maintenance Ceph — flags noout¶

Evacuation d'un noeud¶

Ajout d'un nouveau noeud¶

Retrait d'un noeud¶

Configuration dans `/etc/pve/storage.cfg`¶