Aller au contenu

Réplication ZFS entre nœuds (pvesr) et HA sans stockage partagé

Day 1 · DéployerNiveau 2 · OpérerProcédureRédigé · à valider en lab

Objectif : copier toutes les 15 minutes les disques de la VM 101 de pve01 vers pve02 avec la réplication de stockage (pvesr), puis la placer en HA. En cas de panne de pve01, la VM redémarre sur pve02 à partir de la dernière réplication réussie : les écritures faites depuis cette synchronisation sont perdues.

flowchart LR
    subgraph pve01
        A["tank/vm-101-disk-0<br/>(actif)"]
    end
    subgraph pve02
        B["tank/vm-101-disk-0<br/>(copie)"]
    end
    Q["QDevice<br/>(3e vote)"]
    A -- "zfs send incrémental<br/>toutes les 15 min" --> B
    pve01 -.- Q
    pve02 -.- Q

Ce qu'il faut savoir avant

Point Détail
Stockage supporté ZFS local uniquement (type zfspool)
Prérequis de nommage Un stockage ZFS de même ID (tank) sur le nœud source et le nœud cible
Planification Toutes les 15 min par défaut ; de 1 minute à une fois par semaine (syntaxe calendrier systemd)
Identifiant de job <VMID>-<n>, par exemple 101-0
Cibles Plusieurs nœuds cibles possibles, jamais deux fois le même
Réseau utilisé Celui de la migration (à défaut, le réseau de management), modifiable dans Datacenter → Options → Replication Settings
En cas d'échec Le job réessaie toutes les 30 minutes, puis reprend son planning normal après un succès
Migration Vers le nœud qui a déjà la copie : seul le delta est envoyé, le sens de réplication s'inverse
HA Autorisée, avec perte possible des données écrites depuis la dernière synchronisation

Avant de toucher la prod

  • Cluster sain et quorate : pvecm status (Quorate: Yes), QDevice actif sur une architecture 2 nœuds.
  • Pool tank présent sur les deux nœuds et stockage tank déclaré pour pve01 et pve02 (voir Créer un pool).
  • Tous les disques de la VM sur tank : pas de disque sur local-lvm ni de CD-ROM monté depuis un stockage local.
  • Espace libre sur pve02 pour la copie et ses snapshots (moins de 80 % après réplication).
  • RPO (perte de données maximale admise) validé avec le métier et le MSP, par exemple 15 min.

Étapes

  1. Sélectionner la VM 101 → Replication → Add.
  2. Target : pve02. Schedule : */15 (défaut) ou */5 pour une VM critique. Rate limit : optionnel, en Mo/s, si le lien est partagé.
  3. Create, puis Schedule now pour lancer la première synchronisation complète. Suivre l'avancement avec le bouton Log.
  4. Vue d'ensemble : Datacenter → Replication (tous les jobs, colonnes Last Sync, Duration, State).
  5. HA : Datacenter → HA → Resources → Add, VM 101, état demandé started. Si une préférence de nœud est souhaitée, la définir avec le MSP (règles d'affinité HA de PVE 9).
# Créer le job de réplication de la VM 101 vers pve02, toutes les 15 min
pvesr create-local-job 101-0 pve02 --schedule "*/15"
# Avec limitation de débit (Mo/s)
# pvesr create-local-job 101-0 pve02 --schedule "*/15" --rate 50

# Lancer immédiatement la première synchronisation
pvesr schedule-now 101-0
pvesr status

# Mettre la VM sous HA
ha-manager add vm:101 --state started
ha-manager status

Ce qui se passe lors d'une panne

Situation Comportement
Migration planifiée pve01 → pve02 Delta envoyé, aucune perte ; la réplication repart dans l'autre sens
Panne de pve01, VM en HA Après isolement (fencing) de pve01, la VM redémarre sur pve02 sur la dernière copie
Panne de pve01, VM hors HA Reprise manuelle : avec le MSP, déplacer /etc/pve/nodes/pve01/qemu-server/101.conf vers /etc/pve/nodes/pve02/qemu-server/, puis qm start 101
Retour de pve01 Ses copies sont plus anciennes ou divergentes : la réplication doit repartir de pve02 vers pve01. Contrôler pvesr status avec le MSP avant toute migration retour

Vérifications

pvesr status
# JobID  Enabled  Target       LastSync             NextSync             Duration  FailCount  State
# 101-0  Yes      local/pve02  2026-10-23_10:15:02  2026-10-23_10:30:00  4.1       0          OK
zfs list -t snapshot | grep vm-101    # sur pve01 et pve02 : snapshots __replicate_101-0_...
ha-manager status                     # service vm:101 (pve01, started)
Test de bascule lors d'une fenêtre de maintenance : migration de la VM 101 vers pve02, puis retour.

Rollback

Retirer la VM de la HA (Datacenter → HA → Remove, ou ha-manager remove vm:101), puis supprimer le job (VM → Replication → Remove, ou pvesr delete 101-0). La suppression du job nettoie les copies sur le nœud cible : vérifiez ensuite l'espace sur pve02. Ne supprimez jamais à la main un dataset sur le nœud cible.

Pièges vus en support

  • Stockage nommé tank sur pve01 et zfs-data sur pve02 : la réplication échoue (storage with the same storage ID is not available).
  • VM avec un disque de cloud-init ou un second disque sur local-lvm : réplication impossible.
  • La réplication n'est pas une sauvegarde : un chiffrement par ransomware est répliqué au cycle suivant. PBS reste indispensable.
  • Cluster 2 nœuds sans QDevice : la panne d'un nœud fait perdre le quorum, la HA ne redémarre rien.
  • Pool cible plein : tous les jobs échouent, les snapshots s'accumulent côté source (voir RB-11).
  • Base de données en HA répliquée : la perte de 15 minutes de transactions doit être acceptée par le métier, ou la VM doit utiliser sa propre réplication applicative.

Quand ouvrir un ticket iTop

Mise en place de la HA sur une architecture répliquée, réglage du réseau de réplication, reprise manuelle après panne d'un nœud : avec le MSP (P2 en incident, P3 en projet). Réplication en échec : suivre d'abord RB-11. Joindre pvesr status, ha-manager status, pvecm status.

Ouvrir un ticket iTop

Pour aller plus loin