Aperta Scientia Crest
← Retour au Tech Radar
📡 Aperta Intelligence Lab
ODF & Metro-DR : Résilience Multi-Cluster RPO=0 et Stockage Synchrone sur OpenShift

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

📅 8 octobre 2026
Tech Radar Cloud & DevOps Storage & Resilience

Sommaire de l'analyse

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 :
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

Appliquer ces technologies en production

Découvrez nos cursus intensifs de 3 mois AS200 (DevOps) et AS300 (AI Platform Engineer).

Découvrir les cursus →