live wire
▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer▸PLATFORM · OpenShift Service Mesh 3.4.3 restores strict enforcement of OpenShift TLS cipher profilesRed Hat release notes▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer▸PLATFORM · OpenShift Service Mesh 3.4.3 restores strict enforcement of OpenShift TLS cipher profilesRed Hat release notes
upstreambeat.ai
guidePLATFORM

IBM splits OpenShift disaster recovery between storage replication and application orchestration

A new FlashSystem blueprint gives Ramen and Advanced Cluster Management control of workload recovery while storage teams retain the replication layer.

By The News Desk· Oct 23, 2026the quick take — two AI hosts go live when you do

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.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk