IBM splits OpenShift disaster recovery between storage replication and application orchestration

IBM has published a disaster-recovery blueprint that deliberately keeps storage failover and OpenShift workload recovery as separate operating domains. FlashSystem handles asynchronous data replication, while Red Hat Advanced Cluster Management and the upstream Ramen framework coordinate where applications restart and how their Kubernetes state follows them.

The IBM engineering post describes the design as a validated, Bronze-level Ramen integration. That qualifier matters: the pattern coordinates two layers, but does not pretend that Ramen automates the underlying array operations.

What the blueprint connects

The design uses three OpenShift clusters or roles. An RHACM hub, placed outside the primary failure domain, hosts Ramen’s hub operator and initiates failover or relocation. A primary cluster runs the application and provisions persistent volumes through IBM’s Block Storage CSI driver. A secondary cluster receives the recovered workload.

FlashSystem replicates groups of related volumes asynchronously between sites. Separately, S3-compatible object storage protects the application metadata that Ramen needs to recreate Kubernetes resources and persistent volumes at the recovery cluster.

That separation gives platform teams a Kubernetes-native recovery workflow without hiding storage operations from the administrators responsible for replication health, lag, recovery-point objectives and network fencing.

How recovery works

During an unplanned failover, the storage team makes replicated volumes available at the recovery system and adjusts replication direction. Ramen then uses a DRPlacementControl resource to restore application metadata, recreate persistent volumes and bring the workloads online on the secondary cluster.

A planned relocation follows the reverse path: FlashSystem promotes the preferred production copy and reverses replication, then Ramen moves the application and cleans up resources at the former site.

The approach is intentionally hands-on at the storage boundary. IBM says it requires no changes to the storage product, but it also means teams must coordinate array promotion and application orchestration through tested operating procedures rather than expect a single control plane to perform both.

What teams should test

The blueprint recommends matching StorageClass configuration across clusters, grouping related volumes to preserve write order, and using highly available object storage for metadata. The RHACM hub must sit outside the failure domain it controls.

The most important validation is operational. Teams should rehearse failover, relocation and failback; measure replication lag against their recovery-point target; and test DNS or global-load-balancer changes after workloads restart. They should also practice fencing partial site failures, where an incorrect promotion decision can create split-brain conditions.

IBM positions the design as a foundation for more automated Silver- and Gold-level integrations. For current adopters, its value is more immediate: it defines exactly where storage responsibility ends and application-aware recovery begins.