# Réplication entre Volume Groups

**URL:** <https://www.debian-fr.org/t/replication-entre-volume-groups/89022>\
**Category:** Support Debian\
**Tags:** lvm\
**Created:** [Octobre 24, 2023, 1:56 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022 "2023-10-24T13:56:14Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\
**Post date:** [Octobre 24, 2023, 1:56 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/1 "2023-10-24T13:56:14Z")

</div>

Bonjour,

j’ai 2 disques de taille identique sur un serveur Proxmox. Ces disques sont tous deux partitionnés en 3 partitions:

- /boot (dans un RAID 1)
- / (dans un autre RAID1)
- une partition pour les données

Sur chaque disque la partition de données est utilisée pour créer un Volume Group LVM, et ce Volume Group est entièrement utilisé par un _thinpool_ LVM (les habitué·es auront peut-être deviné qu’il s’agit d’un serveur Proxmox).

Je n’ai pas mis ces deux partitions en RAID, car on m’a remonté que mélanger RAID1 logiciel et LVM thinpool était une mauvaise idée, en termes de performance et de stabilité. Je n’ai pas pris le temps de vérifier ou de chercher pourquoi (par confiance et manque de temps, surtout).

D’où mes deux questions:

1. avec-vous une expérience de combinaison soft RAID1 / LVM thin ? Si oui, est-ce qu’il y a des choses auxquelles prêter une attention particulière ? Avez-vous remarqué des changements dans les performances de lecture/écriture ou de stabilité ?

2. Et sinon en écartant RAID, auriez-vous des mécanismes pour assurer une tolérance à la panne du VG principal ou du disque sur lequel se trouve son PV ? Je commence à me documenter sur les fonctionnalités de _mirroring_ de LVM, mais je ne connais pas bien: est-ce qu’il est possible / efficient de _mirrorer_ (pardon pour l’anglicisme) des LVs d’un VG à l’autre ? Pour l’instant j’ai l’impression qu’on ne peut le faire qu’au sein du même VG (ce qui n’est pas grave en soi, je peux étendre le VG déjà existant)

Merci, et désolé pour les nombreux acronymes, c’est difficile de faire autrement avec LVM…

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Octobre 24, 2023, 2:40 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/2 "2023-10-24T14:40:10Z")

</div>

Bonjour,  
J’utilise du RAID 1 avec LVM mais pas avec du thin pool (je préfère maitriser les tailles de mes partitions plutôt que d’avoir à gérer un jour un over-provisionning).  
Mais sinon, RAID1 et LVM Thin c’est correct. Il faut faire attention à la partie des metadonnées de spare je crois qu’elle risque de ne pas être en RAID. Et en cas de perte d’un disque ton thin pool sera cassé.

Après Tu pourrais éventuellement utiliser BTRFS pour tes données. Je crois qu’en termes de performances BTRFS est meilleurs que LVM. et tu retrouverais des mécanismes de tolérance de panne (en plus de l’aspect RAID1 proprement dit) du fait des fonctionnalités de btrfs.

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 2:42 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/3 "2023-10-24T14:42:54Z")

</div>

Je déconseille d’utiliser du raid sur une proxmox, créer des pools zfs est bien plus pertinent surtout au vu de votre besoin.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Octobre 24, 2023, 2:59 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/4 "2023-10-24T14:59:34Z")

</div>

Donc il ne reste plus qu’à choisir entre BTRFS et ZFS.  
BTRFS est inclu dans le noyau, par contre je ne sais pas si ZFS est uniquement à travers OpenZFS ou s’il est désormais intégré au moyen?

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 3:03 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/5 "2023-10-24T15:03:32Z")

</div>

J’installais des serveurs proxmox pour mon avant-dernier employeur (sur un hebergeur bien connu )et je n’ai pas eu - de mémoire à installer openzfs.

Debian etait le systeme de base

edit: je suppose qu’openzfs etait pre-installé dans leur image

---

<div class="post-metadata">

**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\
**Post date:** [Octobre 24, 2023, 3:07 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/6 "2023-10-24T15:07:42Z")

</div>

D’ac, merci à vous deux !

Dans la [doc de Proxmox](https://pve.proxmox.com/wiki/Storage) il est mentionné que l’intégration de BTRFS est encore au stade de «&nbsp;technology preview&nbsp;», je partirais donc plutôt sur ZFS. Je n’ai encore utilisé ni l’un ni l’autre, en termes de réplication ou _mirroring_ sur deux disques, j’imagine que ça se fait bien ?

PS: j’ai bien un module `zfs` chargé sans avoir rien installé de spécial à ce sujet, c’est inclus dans les paquets Proxmox:

```auto
 ~# modinfo zfs
filename: /lib/modules/6.2.16-12-pve/zfs/zfs.ko
version: 2.1.12-pve1
license: CDDL
author: OpenZFS
description: ZFS

```

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 3:09 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/7 "2023-10-24T15:09:36Z")

</div>

> [@Sputnik93](#):
>
> Je n’ai encore utilisé ni l’un ni l’autre, en termes de réplication ou _mirroring_ sur deux disques, j’imagine que ça se fait bien ?

Ca me prenait moins d’1/4h à installer, donc «&nbsp;oui&nbsp;» ca se fait bien, meme très bien.

Je n’ai pas la procedure sur cet ordi mais vous pouvez selectionner mirroring lors de la conf de vos pools

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Octobre 24, 2023, 3:19 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/8 "2023-10-24T15:19:14Z")

</div>

Attention le besoin de ram et de bande passante pour maintenir le cluster (dans le cas d’un cluster bie n entendu) est énorme.

Idem ZFS ou Ceph ne doivent être envisagé uniquement dans le cadre de cluster avec une forte valeur ajouté et un besoin de haute disponibilité (toujours en ayant au préalable s’être bien documenté).  
Maintenir du ZFS ou du Ceph lorsque l’on ne connais pas 😕

Pour ma part je travail régulièrement avec du Proxmox et on tourne avec du LVM sur du raid matériel ou du raid software.  
les performances sont aussi à évaluer sachant que pour de la performance on peu très souvent oublié la virtualisation pour du physique par exemple pour de la base de donnée critique et consommatrice d’I/O .

La complexité et bien souvent l’ami du mal, faut rester le plus simple possible et en accord avec ces besoins.

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 3:24 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/9 "2023-10-24T15:24:22Z")

</div>

> [@Clochette](#):
>
> Idem ZFS ou Ceph ne doivent être envisagé uniquement dans le cadre de cluster avec une foret valeur ajouté et un besoin de haute disponibilité (toujours en ayant au préalable s’eêtre bien documenté).

?

> [@Clochette](#):
>
> Idem ZFS ou Ceph ne doivent être envisagé uniquement dans le cadre de cluster avec une foret valeur ajouté et un besoin de haute disponibilité (toujours en ayant au préalable s’eêtre bien documenté).

Ca c’est la theorie …  
Pour en avoir installé un bon paquet et surtout n’avoir jamais eu de souci … pour des serveurs vraiment basiques accueillant qu’une application

---

<div class="post-metadata">

**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\
**Post date:** [Octobre 24, 2023, 3:25 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/10 "2023-10-24T15:25:02Z")

</div>

Oui, je me demande d’ailleurs s’il ne serait pas mieux de gérer le stockage (et sa réplication) ailleurs, genre un SAN.  
En tout cas, je me souviens que dans le cadre de mon ancien boulot, on a tourné la question dans tous les sens et on a fini par ne pas faire de réplication, mais gérer correctement les sauvegardes car la solution idéal était d’avoir un SAN, mais nous n’avions pas le budget pour une solution aussi complexe avec le besoin que nous avions.

---

<div class="post-metadata">

**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\
**Post date:** [Octobre 24, 2023, 3:27 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/11 "2023-10-24T15:27:54Z")

</div>

@Clochette veut dire qu’on ne tue pas les moustiques à la bombe H, même si les moustiques décèdent peu de temps après la détonation…

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 3:28 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/12 "2023-10-24T15:28:40Z")

</div>

Lol ok…désolé pour la briéveté de mes commentaires mais vous vous prenez le chou sur des precepts theoriques qui n’ont aucune utilité dans ce cas.

---

<div class="post-metadata">

**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\
**Post date:** [Octobre 24, 2023, 3:42 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/13 "2023-10-24T15:42:25Z")

</div>

> [@Almtesh](#):
>
> Oui, je me demande d’ailleurs s’il ne serait pas mieux de gérer le stockage (et sa réplication) ailleurs, genre un SAN.  
> En tout cas, je me souviens que dans le cadre de mon ancien boulot, on a tourné la question dans tous les sens et on a fini par ne pas faire de réplication, mais gérer correctement les sauvegardes car la solution idéal était d’avoir un SAN, mais nous n’avions pas le budget pour une solution aussi complexe avec le besoin que nous avions.

Idem, le budget est serré, et les attentes en termes de haute-disponibilité / SLA ne sont pas hyper élevées (c’est de l’associatif, ça doit tourner, mais si jamais ça ne tourne pas pendant 15 minutes à un moment, c’est pas hyper grave).

La réplication est là uniquement pour ne pas avoir de problème (ni d’interruption de service, idéalement) si un des 2 disques lâche, autrement les données sont sauvegardées sur site distant. Donc pas de cluster, et pas de possibilité de stockage distribué.

Personne n’a essayé le _LVM mirroring_ dans ce type de contexte, du coup ? Comme j’ai déjà un VG, je testerais bien. J’ai trouvé ce post sur le forum Proxmox: [Proxmox dual storage lvm volume mirror | Proxmox Support Forum](https://forum.proxmox.com/threads/proxmox-dual-storage-lvm-volume-mirror.27435/#post-138021)

> [@Clochette](#):
>
> Pour ma part je travail régulièrement avec du Proxmox et on tourne avec du LVM sur du raid matériel ou du raid software.

LVM sans thinpool ? Personnellement j’ai besoin du thinpool car certaines personnes ont accès à certains conteneurs applicatifs (màj de logiciels dév spécifiquement) et la fonctionnalité de Snapshot est franchement très utile pour ces personnes.

> [@Clochette](#):
>
> La complexité et bien souvent l’ami du mal, faut rester le plus simple possible et en accord avec ces besoins.

+1

J’avais l’impression que ZFS n’était pas particulièrement plus difficile à administrer / prendre en main que LVM, mais j’ai très peu d’expérience avec. Par contre, Ceph ne présente pas vraiment d’intérêt dans mon cas, et je préfère ne pas y toucher pour l’instant.

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 3:44 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/14 "2023-10-24T15:44:13Z")

</div>

> [@Sputnik93](#):
>
> Ceph ne présente pas vraiment d’intérêt dans mon cas, et je préfère ne pas y toucher pour l’instant.

ZFS ne bouge pas  
Et c’est plus simple à manipuler qu’lvm

Ceph n’a pas d’utilité dans votre cas

ps: je ne comprends ce blabla sur une pseudo-complexité surtout venant de personnes connaissant freebsd

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Octobre 24, 2023, 4:41 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/15 "2023-10-24T16:41:14Z")

</div>

> [@loicmtp](#):
>
> ZFS ne bouge pas  
> Et c’est plus simple à manipuler qu’lvm

Pour celui qui connait la cli et les principes.

> [@loicmtp](#):
>
> ps: je ne comprends ce blabla sur une pseudo-complexité surtout venant de personnes connaissant freebsd

Lorsque l’on travail en informatique la fainéantise est une habitude (le principe hein qu’on soit d’accord).  
Tant qu’une techno fonctionne pas de souci, mais imagine toi devoir mettre les mains dans le cambouis après un incident ou un effet de bord non géré/pensé au départ … avec la pression du service down à rétablir etc ce n’est clairement pas agréable.

> [@Sputnik93](#):
>
> LVM sans thinpool ? Personnellement j’ai besoin du thinpool car certaines personnes ont accès à certains conteneurs applicatifs (màj de logiciels dév spécifiquement) et la fonctionnalité de Snapshot est franchement très utile pour ces personnes.

J’ai du snapshot/suspend et stop comme type de sauvegarde disponible avec le LVM classique, par contre attention il y a un type de sauvegarde (snapshot il me semble) qui parfois corrompre les disque lors de fortes charges I/O en même temps (c’est très variable, j’ai pas de chiffres précis mais ça m’ai déjà arrivé 😡), en règle générale j’utilise le type _suspend_.

> [@Sputnik93](#):
>
> Personne n’a essayé le _LVM mirroring_ dans ce type de contexte, du coup ? Comme j’ai déjà un VG, je testerais bien. J’ai trouvé ce post sur le forum Proxmox: [Proxmox dual storage lvm volume mirror | Proxmox Support Forum](https://forum.proxmox.com/threads/proxmox-dual-storage-lvm-volume-mirror.27435/#post-138021)

Nope, j’ai déjà fais du mirroring LVM mais pas dans ce cas là.

Remarque si tu as un PRA maintenu à jour et que tu peux basculer sur celui-ci dans un temps raisonnable pour ton besoin c’est déjà à 95% mieux que de vouloir absolument testé cette solution surtout que la machine elle même deviens un SPOF elle même vue qu’il y a pas de cluster 😅

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 4:47 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/16 "2023-10-24T16:47:12Z")

</div>

> [@Clochette](#):
>
> Lorsque l’on travail en informatique la fainéantise est une habitude (le principe hein qu’on soit d’accord).  
> Tant qu’une techno fonctionne pas de souci, mais imagine toi devoir mettre les mains dans le cambouis après un incident ou un effet de bord non géré/pensé au départ … avec la pression du service down à rétablir etc ce n’est clairement pas agréable.

ZFS est un rail et d’une flexibilité incroyable. Je ne comprends vraiment pas pourquoi dissuader @Sputnik93 sputnik de l’utiliser: ca n’a aucun sens

---

<div class="post-metadata">

**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\
**Post date:** [Octobre 24, 2023, 5:01 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/17 "2023-10-24T17:01:24Z")

</div>

> [@Clochette](#):
>
> Remarque si tu as un PRA maintenu à jour et que tu peux basculer sur celui-ci dans un temps raisonnable pour ton besoin c’est déjà à 95% mieux que de vouloir absolument testé cette solution surtout que la machine elle même deviens un SPOF elle même vue qu’il y a pas de cluster 😅

Oui, la machine est toujours un SPOF, mais si le service est down parce qu’un disque a claqué, c’est moi qui suis responsable, parce qu’il y a 2 disques dans le serveur, alors que si c’est la baie / la machine qui crame → «&nbsp;j’y peux rien chef, c’est l’hébergeur&nbsp;» (pas les sous pour un 2e serveur) 😆

En effet, le temps de rétablissement (restauration de la dernière sauvegarde sur le disque sain) est relativement raisonnable, mais ça peut arriver quand je ne suis pas au boulot / pas dispo, alors si j’ai de la tolérance à la panne d’un disque sans rien faire, c’est mieux.

Je retiens des échanges ici que mon choix se fera entre LVM mirroré et ZFS. Ce dernier a l’air mieux intégré par la distrib Proxmox, mais je connais moins. Je pense faire tourner un temps avec LVM mirroré, et me faire la main sur Proxmox + ZFS durant ce temps (sur une VM par exemple) avant de basculer, si je suis convaincu par ZFS.

---

<div class="post-metadata">

**Author:** ![loicmtp](https://www.debian-fr.org/user_avatar/www.debian-fr.org/loicmtp/32/13315_2.png) [@loicmtp](https://www.debian-fr.org/u/loicmtp)\
**Post date:** [Octobre 24, 2023, 5:09 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/18 "2023-10-24T17:09:01Z")

</div>

> [@Sputnik93](#):
>
> Je retiens des échanges ici que mon choix se fera entre LVM mirroré et ZFS

ZFS propose le mirroring c’est ce que je disais plus haut  
ZFS est la solution faite pour votre genre d’infra

edit: Il va vous falloir dix fois plus de temps pour implementer lvm mirroring alors qu’il faut une seule ligne de commande pour le mirroring sur zfs …mais bon si le temps ne vous est pas compté…

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Octobre 24, 2023, 5:38 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/19 "2023-10-24T17:38:47Z")

</div>

En fait ZFS est fait pour ça surtout avec des gros volumes de données. Pour des petits volumes les performances sont moins bonnes.  
Dommage que BTRFS soit pas bien supporté par Promox.

---

<div class="post-metadata">

**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\
**Post date:** [Octobre 25, 2023, 2:32 UTC](https://www.debian-fr.org/t/replication-entre-volume-groups/89022/20 "2023-10-25T14:32:24Z")

</div>

> [@Clochette](#):
>
> J’ai du snapshot/suspend et stop comme type de sauvegarde disponible avec le LVM classique, par contre attention il y a un type de sauvegarde (snapshot il me semble) qui parfois corrompre les disque lors de fortes charges I/O en même temps (c’est très variable, j’ai pas de chiffres précis mais ça m’ai déjà arrivé 😡), en règle générale j’utilise le type _suspend_ .

Je parlais de la fonctionnalité de snapshot LVM, qui permet de prendre un instantané à chaud avec possibilité de rollback, pas de la fonctionnalité de sauvegarde.

Pour le mode de sauvegarde, le mode _suspend_ n’a pas l’air très mis en avant par Proxmox, àa la limite le mode _stop_ est peut-être mieux ?

> **stop mode**
> 
> This mode provides the highest consistency of the backup, at the cost of a short downtime in the VM operation. It works by executing an orderly shutdown of the VM, and then runs a background QEMU process to backup the VM data. After the backup is started, the VM goes to full operation mode if it was previously running. Consistency is guaranteed by using the live backup feature.
> 
> **suspend mode**
> 
> This mode is provided for compatibility reason, and suspends the VM before calling the snapshot mode. Since suspending the VM results in a longer downtime and does not necessarily improve the data consistency, the use of the snapshot mode is recommended instead.
> 
> **snapshot mode**
> 
> This mode provides the lowest operation downtime, at the cost of a small inconsistency risk. It works by performing a Proxmox VE live backup, in which data blocks are copied while the VM is running. If the guest agent is enabled (agent: 1) and running, it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to improve consistency.

([Backup and Restore](https://pve.proxmox.com/pve-docs/chapter-vzdump.html))

En tout cas merci d’avoir mentionné ça, j’ai scindé mes jobs de sauvegarde, du coup.

[Page suivante](https://www.debian-fr.org/t/replication-entre-volume-groups/89022.md?page=2)
