Parent folderOpen Confluence

RWS Architecture article

ADR-001 Storage Backend Selection

We need a single storage backend for OpenShift, OpenShift Virtualization (live migration), and potential object storage use cases. The choice affects performance, backup, and opera

  1. Typeadr
  2. Statusaccepted
  3. Domainstorage
On this page
  1. Context and Problem Statement
  2. Decision Drivers
  3. Assumptions
  4. Considered Options
  5. Decision Outcome
  6. Pros and Cons of the Options
  7. Option 1 – Dedicated Ceph platform via Red Hat OpenShift Data Foundation (ODF) in external mode (backed by Red Hat Ceph Storage) (chosen)
  8. Option 2 – ODF hyperconverged
  9. Option 3 – Pure FlashArray + PortWorx
  10. Option 4 – Mixed appliances
  11. Option 5 – Defer / ad-hoc
  12. Links and References

Context and Problem Statement

We need a single storage backend for OpenShift, OpenShift Virtualization (live migration), and potential object storage use cases. The choice affects performance, backup, and operational tooling across all clusters.

Decision Drivers

  • Read-write-many (RWX) and live-migration support for OpenShift Virtualization.
  • Resilience and replication across datacenters.
  • Strong OpenShift integration and vendor support.
  • Alignment with procured hardware and long-term ODF external design.
  • Avoid fragmentation of storage technologies across clusters.

Assumptions

  • RWX and live migration are required for core platform workloads.
  • Some workloads may require higher availability and replication guarantees.
  • Hyperconverged storage is optional; externalized storage remains viable.

Considered Options

  1. Dedicated Ceph platform via Red Hat OpenShift Data Foundation (ODF) in external mode (backed by Red Hat Ceph Storage).
  2. ODF hyperconverged using internal disks only.
  3. Pure FlashArray + PortWorx.
  4. Mixed appliances (NFS or vendor-specific arrays) per use case.
  5. Defer decision and keep storage ad-hoc.

Decision Outcome

Chosen option: Dedicated Ceph platform via Red Hat OpenShift Data Foundation (ODF) in external mode (backed by Red Hat Ceph Storage) as the primary storage backend.

This aligns with the consulting report inputs while preserving a shared, scalable storage platform and avoids per-cluster fragmentation. Exceptions require an explicit ADR.

Pros and Cons of the Options

Option 1 – Dedicated Ceph platform via Red Hat OpenShift Data Foundation (ODF) in external mode (backed by Red Hat Ceph Storage) (chosen)

Pros

  • Supports block and file access with a consistent operational model.
  • Aligns with OpenShift integration and vendor support.
  • Centralized capacity planning and backup strategy.

Cons

  • Operational complexity of running a dedicated storage cluster.
  • Dependency on vendor lifecycle and support contracts.

Option 2 – ODF hyperconverged

Pros

  • Tight integration inside OpenShift clusters.
  • Simple consumption model for small environments.

Cons

  • Scales per cluster and duplicates capacity.
  • Underutilizes external storage hardware and complicates HCP plans.

Option 3 – Pure FlashArray + PortWorx

Pros

  • High performance for local storage use cases.
  • Leverages existing vendor contracts.

Cons

  • Expensive, complex, and less aligned with centralized Ceph operations.
  • Requires additional networking and iSCSI integration per node.

Option 4 – Mixed appliances

Pros

  • Potentially simple for narrow use cases.

Cons

  • Fragmented storage model and inconsistent practices.
  • Harder to standardize backup, DR, and live migration.

Option 5 – Defer / ad-hoc

Pros

  • No immediate work.

Cons

  • Defers critical decisions and increases inconsistency risk.

Links and References

Agreement

  • Wouter Moeken — Solutions Architecture
  • Vleer Doing — Domain Architecture
  • Patrick van der Most — Project Management
  • Dorus Rolvink — Platform Engineering (pending confirmation)

Relationships