Mise à jour solution finale article LINSTOR DRBD

Added info admonition blocks to both FR and EN versions documenting the final decision to partition NVMe drives (300GB LINSTOR + 200GB local-lvm) instead of using the Python script approach. Includes rationale and forward reference to upcoming NFS HA implementation article.

blog/2025-11-26-linstor-drbd-opentofu-problemes.md

@@ -282,6 +282,30 @@ Je documenterai ma décision finale et sa mise en œuvre dans un prochain articl
 
 ---
 
+:::info Mise à jour : Solution finale retenue
+
+Après avoir testé l'Option 1 avec un [script Python de gestion des ressources LINSTOR](https://forgejo.tellserv.fr/Tellsanguis/blog_tech/src/branch/main/manage_linstor_resources.py), j'ai constaté que cette approche, bien que fonctionnelle, ajoutait une complexité trop importante et des risques de désynchronisation pour une utilisation en production.
+
+**La décision finale** : Partitionner les disques NVMe de chaque nœud Proxmox selon la stratégie suivante :
+
+- **300 Go alloués à LINSTOR DRBD** (`linstor_storage`) pour :
+  - Les VMs et LXC nécessitant la haute disponibilité au niveau Proxmox
+  - Le conteneur LXC hébergeant le serveur NFS (voir [projet zfs-sync-nfs-ha](https://forgejo.tellserv.fr/Tellsanguis/zfs-sync-nfs-ha))
+  - Tout stockage distribué géré par Proxmox HA
+
+- **200 Go alloués à local-lvm** (`local-lvm`) pour :
+  - Les VMs du cluster K3S qui n'ont **pas besoin** de HA au niveau Proxmox
+  - La haute disponibilité étant assurée par le cluster Kubernetes lui-même
+  - Provisionnement simple et rapide via OpenTofu
+
+Cette architecture permet d'utiliser le bon outil au bon endroit : LINSTOR DRBD pour ce qui nécessite vraiment de la réplication synchrone au niveau infrastructure, et du stockage local performant pour les workloads où la HA est gérée par la couche applicative (Kubernetes).
+
+Un article détaillé sur cette mise en œuvre et le conteneur NFS HA suivra prochainement.
+
+:::
+
+---
+
 **Références** :
 - [Choisir sa technologie de stockage distribué pour un cluster Proxmox HA](/blog/stockage-distribue-proxmox-ha)
 - [LINSTOR User Guide](https://linbit.com/drbd-user-guide/)

i18n/en/docusaurus-plugin-content-blog/2025-11-26-linstor-drbd-opentofu-problemes.md

@@ -282,6 +282,30 @@ I'll document my final decision and its implementation in a future article.
 
 ---
 
+:::info Update: Final Solution Adopted
+
+After testing Option 1 with a [Python script for LINSTOR resource management](https://forgejo.tellserv.fr/Tellsanguis/blog_tech/src/branch/main/manage_linstor_resources.py), I found that this approach, while functional, added too much complexity and synchronization risks for production use.
+
+**The final decision**: Partition the NVMe drives on each Proxmox node according to the following strategy:
+
+- **300 GB allocated to LINSTOR DRBD** (`linstor_storage`) for:
+  - VMs and LXC containers requiring high availability at the Proxmox level
+  - The LXC container hosting the NFS server (see [zfs-sync-nfs-ha project](https://forgejo.tellserv.fr/Tellsanguis/zfs-sync-nfs-ha))
+  - Any distributed storage managed by Proxmox HA
+
+- **200 GB allocated to local-lvm** (`local-lvm`) for:
+  - K3S cluster VMs that **don't need** HA at the Proxmox level
+  - High availability ensured by the Kubernetes cluster itself
+  - Simple and fast provisioning via OpenTofu
+
+This architecture allows using the right tool for the right purpose: LINSTOR DRBD for what truly requires synchronous replication at the infrastructure level, and performant local storage for workloads where HA is managed by the application layer (Kubernetes).
+
+A detailed article on this implementation and the HA NFS container will follow soon.
+
+:::
+
+---
+
 **References**:
 - [Choosing a Distributed Storage Technology for a Proxmox HA Cluster](/blog/stockage-distribue-proxmox-ha)
 - [LINSTOR User Guide](https://linbit.com/drbd-user-guide/)