# ODF & Metro-DR : Résilience Multi-Cluster RPO=0 et Stockage Synchrone sur OpenShift

> Architecture OpenShift Data Foundation Metro-DR : réplication synchrone Rook-Ceph RBD, orchestration déclarative RamenDR et RHACM pour une résilience RPO=0 des workloads stateful et IA.

- **Date de publication** : 2026-10-08T08:30:00.000Z

---

En production cloud-native, la haute disponibilité des architectures sans état (stateless) est largement maîtrisée grâce à la répartition des pods sur plusieurs zones de disponibilité. En revanche, pour les services **stateful critiques** — bases relationnelles transactionnelles, brokers Kafka, disques virtuels de machines **KubeVirt**, ou bases vectorielles de serving IA (**Milvus, Qdrant**) —, la perte soudaine d'un datacenter complet constitue le pire cauchemar de l'ingénieur de plateforme : corruption d'état, perte irréversible de transactions (*RPO > 0*) ou indisponibilité prolongée (*RTO élevé*).

Si les sauvegardes asynchrones par snapshots périodiques (CSI / OADP / Velero) sont adaptées à la reprise sur sinistre régionale distante, elles ne répondent pas aux exigences de continuité d'activité stricte à l'échelle métropolitaine. C'est précisément le périmètre d'**OpenShift Data Foundation (ODF)** dans sa topologie **Metro-DR** : combiner le moteur de stockage distribué **Rook-Ceph**, la réplication synchrone au niveau bloc (**Ceph RBD Mirroring**) et l'opérateur d'orchestration multi-cluster **RamenDR** sous l'égide de **Red Hat Advanced Cluster Management (RHACM)** pour garantir un **RPO = 0** et un basculement automatisé en quelques minutes.

---

### 1. Les deux architectures de reprise après sinistre ODF : Metro-DR vs Regional-DR

Pour concevoir une stratégie de résilience robuste, il convient de distinguer clairement les deux modes de Disaster Recovery proposés par OpenShift Data Foundation :

1. **Regional-DR (Asynchrone — RPO > 0) :** Déployé sur deux clusters OpenShift séparés par de grandes distances géographiques (plusieurs centaines de kilomètres), où la latence réseau interdit la synchronisation synchrone. La réplication RBD s'effectue par snapshots différentiels à intervalles programmés (ex. toutes les 5 à 15 minutes). En cas de sinistre, les données écrites entre le dernier snapshot et le crash sont perdues.
2. **Metro-DR (Synchrone — RPO = 0) :** Déployé à l'échelle d'une aire métropolitaine (deux datacenters interconnectés par fibre noire avec une latence réseau aller-retour **RTT < 10 ms**). Chaque écriture bloc est confirmée simultanément sur les deux sites avant acquittement au niveau applicatif. En cas d'effondrement intégral du datacenter primaire, **aucune donnée n'est perdue (RPO = 0)**.

Dans le modèle Metro-DR bi-clusters d'entreprise, deux clusters OpenShift indépendants hébergent chacun une instance locale d'ODF/Ceph, reliées en miroir synchrone par l'intermédiaire du réseau inter-cluster chiffré **Submariner**. Un troisième site neutre héberge le plan de contrôle RHACM pour éviter tout scénario de split-brain.

---

### 2. Le cœur mécanique : Rook-Ceph RBD Mirroring et Submariner

Au niveau de la couche de stockage sous-jacente, ODF s'appuie sur l'opérateur open source **Rook-Ceph** :

* **Daemon rbd-mirror synchrone :** Les pools de blocs Ceph (RADOS Block Device - RBD) dédiés aux Persistent Volume Claims (PVC) sont configurés en mode miroir journalisé synchrone. Chaque requête d'écriture I/O traverse le journal Ceph et est répliquée sur le cluster pair avant validation de l'opération POSIX.
* **Interconnexion réseau avec Submariner :** Les flux de réplication de stockage entre les deux clusters OpenShift transitent via des tunnels sécurisés IPSec/WireGuard établis au niveau de la couche réseau (CNI OVN-Kubernetes) par l'opérateur **Submariner**, éliminant tout besoin d'exposer publiquement les démons OSD/MON Ceph.
* **Cohérence et isolation :** Contrairement à un cluster étiré unique (*Stretch Cluster*), le modèle Metro-DR bi-clusters isole totalement les plans de contrôle Kubernetes et etcd. Un incident de réseau ou un dysfonctionnement de l'API Server sur le site A n'a aucun impact sur la stabilité du cluster B.

---

### 3. Orchestration déclarative avec RamenDR et RHACM

La force de la solution réside dans l'automatisation déclarative pilotée par les Custom Resource Definitions (CRDs) du projet open source **RamenDR**, intégré nativement dans **Red Hat Advanced Cluster Management (RHACM)** :

* **CRD `DRPolicy` :** Définit la politique de protection, la planification de synchronisation (synchrone pour Metro-DR) et les clusters pairs cibles :
```yaml
apiVersion: ramendr.openshift.io/v1alpha1
kind: DRPolicy
metadata:
  name: metro-dr-sync-policy
spec:
  drClusters:
    - ocp-cluster-primary
    - ocp-cluster-secondary
  schedulingInterval: 0m # Mode synchrone strict (RPO=0)
```
* **CRD `DRPlacementControl` (DRPC) :** Associe une application (déployée via un `Placement` RHACM ou un `ApplicationSet` ArgoCD) à la politique `DRPolicy`. Le contrôleur Ramen surveille en continu la santé de la réplication des PVCs associées au namespace.
* **Failover vs Relocate :**
  * **Relocate (Maintenance planifiée) :** L'administrateur bascule l'application vers le second cluster. RamenDR met en pause l'application source, draine les pods, vide les tampons I/O, détache les PVCs Ceph, bascule le statut du miroir RBD en primaire sur le cluster cible et redémarre les workloads. Zéro perte de données, interruption minimale.
  * **Failover (Crash imprévu) :** Lorsque le cluster primaire cesse de répondre, RHACM initie un failover d'urgence. RamenDR promeut unilatéralement les volumes RBD secondaires en lecture/écriture et déploie instantanément les pods applicatifs sur le cluster survivant.

---

### 4. Cas d'usage critiques : KubeVirt et AI Vector Databases

Cette architecture de stockage résiliente répond aux deux défis majeurs de l'ingénierie de plateforme moderne :

1. **Machines virtuelles KubeVirt (OpenShift Virtualization) :** Les disques virtuels de VM sont matérialisés par des PVCs de type Block en StorageClass RBD. Grâce à Metro-DR, une machine virtuelle legacy critique exécutée dans KubeVirt peut basculer d'un datacenter à l'autre sans réinstallation, en conservant l'intégrité intégrale de son système de fichiers.
2. **Pipelines IA et bases vectorielles RAG (Milvus / Qdrant) :** Les bases vectorielles servant les applications LLM d'entreprise nécessitent une persistance d'index à haute performance. Metro-DR sécurise le stockage persistant de l'index vectoriel et des métadonnées, garantissant que l'inférence générative d'entreprise reste opérationnelle même en cas de panne d'infrastructure majeure.

---

### 5. Alignement Cursus Aperta Scientia

* **Cursus AS200 (DevOps Platform Engineer — 399h) :** Modules avancés DO380 (OpenShift Automation and Integration) et DO370 (Enterprise Storage with OpenShift Data Foundation) — conception et déploiement de pools **Rook-Ceph**, configuration des StorageClasses RBD/CephFS, interconnexion multi-cluster avec **Submariner**, et automatisation des basculements de reprise après sinistre via **RHACM** et les CRDs **RamenDR**.
* **Cursus AS300 (AI Platform Engineer — 399h) :** Architecture de résilience pour plateformes de données IA et serving LLM — persistance des bases vectorielles (**Milvus**, **Qdrant**), gestion de la disponibilité des volumes de cache et des checkpoints de modèles distribués en environnement multi-zone souverain.

---

### Sources & Références Techniques

* **Red Hat Developer Blog** — *Disaster recovery for stateful applications on OpenShift* : [developers.redhat.com/articles/2025/08/14/disaster-recovery-stateful-applications-openshift](https://developers.redhat.com/articles/2025/08/14/disaster-recovery-stateful-applications-openshift)
* **Red Hat Documentation** — *Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads (Metro-DR)* : [docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/](https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/)
* **Rook-Ceph Documentation** — *Ceph Cluster CRD & Synchronous Mirroring* : [rook.io/docs/rook/latest-release/CRDs/Cluster/ceph-cluster-crd/](https://rook.io/docs/rook/latest-release/CRDs/Cluster/ceph-cluster-crd/)
* **RamenDR Project (CNCF Sandbox)** — *Disaster Recovery for Kubernetes Stateful Applications* : [ramendr.github.io/ramen/](https://ramendr.github.io/ramen/)
* **Red Hat Advanced Cluster Management (RHACM)** — *Multi-Cluster Application Lifecycle & DRPolicy Automation* : [access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/](https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/)

---

*Source : https://aperta.io/fr/radar/2026-10-08-odf-rook-ceph-metro-dr-resilience-multicluster-openshift/ — Aperta Scientia Tech Radar*