Block, File, and S3 Storage

ABB Block, File, and S3 Storage

Summary

Block, File, and S3 Storage is the product-neutral architecture building block for persistent block, file, and object storage for DC 3.0 workloads. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

• Provides persistent block, file, and object storage for DC 3.0 workloads.
• Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
• Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
• Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

• The resulting SBB must fit the datacenters ownership model and document the support, lifecycle, and service-management boundary.
• Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
• Storage classes must make availability, performance, encryption, and data-protection behavior explicit.
• SBBs must support multi-tenant isolation and lifecycle operations without workload-specific manual handling.

Service Description

This ABB offers a storage service that exposes fit-for-purpose block, file, and S3-compatible object storage to platforms and workloads. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

• Baseline: confirm scope, service ownership, constraints, and acceptance criteria for Block, File, and S3 Storage.
• MVP: validate the mapped SBB implementations and record the selected support and lifecycle model.
• Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

• Private cloud and central DC 3.0 landing zone for core infrastructure and platform services.
• Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

• CSI block and file interfaces.
• S3-compatible object APIs.
• Storage management, telemetry, and backup integration APIs.

Dependencies

• Depends on dc-network-structure for a supporting capability or integration boundary.
• Depends on backup-and-disaster-recovery for a supporting capability or integration boundary.
• Implemented by red-hat-openshift-data-foundation, ceph as currently mapped SBB traceabilities.
• Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

• EIRA reference: European Interoperability Reference Architecture (EIRA).
• EIRA definition mapping (PURI):
• Data Persistence
• Data Persistence (Application Component)
• Implemented mapping in this vault:
• Active realizations: ceph, red-hat-openshift-data-foundation.
• Cross-reference register: EIRA Alignment Index.

Available SBB's

• ceph - Ceph is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.
• red-hat-openshift-data-foundation - Red Hat OpenShift Data Foundation is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.