La réplication ZFS dans Proxmox VE 9.2 permet de maintenir une copie des machines virtuelles et des conteneurs sur un second serveur sans recourir à une baie de stockage partagé. Cette fonctionnalité peut s’avérer précieuse pour les petites et moyennes entreprises souhaitant récupérer rapidement leurs services en cas de défaillance d’un nœud. Cependant, il est essentiel de connaître une limite importante : la copie n’est pas toujours à jour. Les derniers changements peuvent être perdus si une panne survient avant leur synchronisation. Par ailleurs, pour automatiser la récupération dans un cluster à deux nœuds, il est nécessaire de résoudre correctement la question du quorum avec un troisième vote.

Les clés de la réplication ZFS dans Proxmox VE 9.2 en 20 secondes

• La réplication utilise des instantanés ZFS, transférant périodiquement les modifications entre les serveurs.
• Le délai par défaut est de 15 minutes, mais il peut être réduit à une minute selon les besoins.
• Les deux nœuds doivent disposer d’un stockage ZFS local compatible, avec le même identifiant de stockage.
• Un QDevice externe fournit le troisième vote nécessaire pour maintenir le quorum en cas de défaillance d’un serveur.
• La réplication ne remplace pas les sauvegardes et ne garantit pas une récupération sans perte de données.

Cette solution constitue une option intéressante pour les entreprises souhaitant disposer d’un second serveur prêt à relancer leurs services sans supporter le coût d’une infrastructure de stockage partagé. Toutefois, la réussite dépend autant de la configuration de Proxmox que de la capacité du nœud de secours, de la qualité du réseau et des exigences spécifiques à chaque application.

La documentation de Proxmox VE 9 a été actualisée pour inclure des modifications dans la configuration de la réplication et de la haute disponibilité. Parmi ces nouveautés figurent la possibilité d’utiliser un réseau dédié à la réplication et l’emploi de règles d’affinité de nœud plutôt que des groupes de haute disponibilité, devenus obsolètes depuis la version 9.0.

Fonctionnement de la réplication ZFS entre deux serveurs

L’outil de Proxmox VE chargé de cette gestion s’appelle pvesr. Son principe repose sur les instantanés ZFS, qui permettent d’effectuer une copie complète d’un volume au démarrage, puis de n’envoyer que les modifications depuis le dernier instantané.

Dans une configuration à deux nœuds, l’un héberge la machine virtuelle (ou le conteneur) et écrit sur ses disques locaux. L’autre reçoit les copies et détient une réplique prête à restaurer le service si le nœud principal échoue.

Le délai par défaut de 15 minutes peut être configuré pour un cycle plus court, allant d’une minute à une semaine. Cette fréquence détermine le décalage maximal entre les données actives et leur réplica. En cas de panne du nœud principal avant que la réplication ne soit réalisée, les changements non transférés seront perdus dans la copie de secours.

Il est important de noter que la réplication ne transforme pas les disques locaux en stockage partagé. Chaque machine écrit dans son propre volume pendant son fonctionnement, la synchronisation étant assurée par des tâches planifiées.

Une autre limite concerne la compatibilité du stockage : la réplication intégrée à Proxmox VE 9.2 ne supporte que le stockage ZFS local, identifié comme zfspool. Elle ne fonctionne pas de la même manière avec d’autres types de stockage comme LVM-thin, un répertoire ou une image QCOW2 : il faut donc vérifier la localisation des disques de chaque machine à protéger.

Le troisième vote : clé essentielle pour la haute disponibilité

Un aspect critique d’un cluster à deux nœuds est le quorum. Proxmox utilise Corosync pour gérer la coordination entre membres, nécessitant une majorité de votes pour valider certaines opérations.

Avec deux nœuds, chacun apportant un seul vote, la défaillance soudaine de l’un d’eux prive l’autre de majorité. Même si un disque est répliqué sur le serveur survivant, cela ne suffit pas à garantir une reprise automatique grâce à la haute disponibilité.

La solution recommandée est d’utiliser un QDevice, un composant externalisé qui fournit un vote supplémentaire. Le service corosync-qnetd peut s’exécuter sur une machine indépendante ou dans une infrastructure séparée, à condition qu’il ne dépende pas des mêmes serveurs qui doivent être protégés.

Il ne stocke pas ses propres machines virtuelles ni leurs données. Son rôle est uniquement d’intervenir dans la décision de quorum. Avec deux nœuds et un QDevice, le cluster peut maintenir la majorité même en cas de défaillance d’un nœud.

La configuration exige l’installation de corosync-qnetd sur la machine externe et de corosync-qdevice sur chaque nœud Proxmox. Il faut ensuite enregistrer le dispositif via pvecm qdevice setup et vérifier avec pvecm status.

Enfin, le serveur survivant doit disposer de ressources suffisantes pour supporter la charge supplémentaire du nœud défaillant. Si les deux serveurs fonctionnent à pleine capacité, la réplication risque d’engendrer des problèmes de mémoire, CPU ou performance lors de la reprise.

Les évolutions de Proxmox VE 9 et ce qu’on perd en cas de panne

La version 9 introduit plusieurs ajustements à revoir lors de la mise en place de l’infrastructure. Il est possible de réserver un réseau dédié à la réplication, distinct des réseaux de gestion et de migration. De même, les règles d’affinité de nœud remplacent les groupes de haute disponibilité, devenus obsolètes après la version 9.0.

Concernant le failback – c’est-à-dire le retour automatique d’une machine vers son nœud préféré une fois celui-ci redevenu opérationnel – la gestion évolue aussi. Depuis Proxmox VE 9, cette opération se configure par ressource et est activée par défaut. Si vous souhaitez vérifier manuellement l’état de récupération, vous pouvez la désactiver.

En cas de panne, la haute disponibilité détecte le problème, vérifie si la machine peut être restaurée et la redémarre à partir de la dernière réplica disponible. La documentation indique un temps de récupération estimé d’environ deux minutes, mais celui-ci dépend fortement de la configuration et de la charge du système.

Le délai de rétablissement, appelé RTO (Recovery Time Objective), ne doit pas être confondu avec le point de récupération, ou RPO (Recovery Point Objective). Le premier mesure le temps nécessaire pour restaurer le service ; le second indique la quantité de données pouvant être perdue. Réduire l’intervalle de réplication limite cette perte, mais ne garantit pas un RPO zéro.

Les applications sensibles à la perte de données, comme une base de données, nécessitent des mécanismes complémentaires. Cela peut passer par une réplication propre ou une architecture de stockage synchrone, en fonction des exigences de cohérence et de disponibilité.

La réplication ne remplace pas la sauvegarde. Une suppression accidentelle ou un ransomware peuvent entraîner une perte de données, même si la réplication a été effectuée. Il est crucial de disposer de copies hors du cluster, avec un historique vérifié par des tests de restauration.

ZFS, Ceph ou stockage partagé : quelle solution privilégier ?

La réplication ZFS se distingue par l’utilisation des disques locaux des deux serveurs, évitant ainsi l’acquisition d’une baie externe. Elle constitue une solution raisonnable pour les entreprises tolérant une perte de modifications postérieure à la dernière réplication, et pouvant accepter une courte interruption pendant la récupération.

Ceph, basé sur le stockage distribué, offre une alternative, mais nécessite une architecture plus complexe et une planification rigoureuse du réseau et des ressources. Une baie partagée peut aussi convenir si elle est déjà en place, à condition qu’elle soit conçue pour la redondance, afin d’éviter la création d’un point de défaillance unique.

Le choix dépend du type de service à protéger. Une application interne peut supporter plusieurs minutes de décalage entre la copie et le système actif. En revanche, une plateforme de facturation, une base de données transactionnelle ou tout service critique nécessiteront une solution différente.

Avant de déployer un cluster à deux nœuds, il est conseillé de vérifier que les pools ZFS portent le même nom, que le QDevice est situé hors du cluster, que la réplication réseau ne perturbe pas Corosync, et que chaque machine critique dispose d’une tâche de réplication performante. Une simulation de panne réelle, avec mesure du temps de récupération et contrôle des données perdues, est également recommandée.

Questions fréquentes

Peut-on répliquer une machine virtuelle dans Proxmox sans ZFS ?

La réplication de stockage intégrée dans Proxmox VE 9.2 supporte uniquement ZFS local. Elle n’est pas compatible avec d’autres types de stockage, comme LVM-thin, répertoires ou images QCOW2, de la même façon.

En cas de panne, combien de données peut-on perdre en laissant un nœud tomber ?

Cela dépend du délai écoulé depuis la dernière réplication complète. Avec le délai par défaut de 15 minutes, des modifications postérieures peuvent être perdues ; en réduisant à un minute, cette fenêtre diminue, sans disparaître totalement.

Faut-il un QDevice pour une réplication entre deux nœuds ?

Pas pour faire la réplication ZFS elle-même. En revanche, un QDevice est indispensable pour garantir le quorum et assurer une haute disponibilité lorsque l’un des nœuds tombe en panne de façon imprévue.

La réplication ZFS remplace-t-elle les sauvegardes ?

Non. La réplication ne protège pas contre les erreurs humaines, les suppressions accidentelles ou les attaques comme le ransomware. Il est impératif de maintenir des sauvegardes indépendantes, vérifiées régulièrement et hors du cluster.