Red Hat · Infrastruttura · scheda YoctoIT

Data Foundation

Lo storage software-defined dentro OpenShift: blocchi, file e oggetti (Ceph) per i dati che vivono coi container.

FOCUS · LO STORAGE DEI CONTAINERPersistenza nativa Kubernetes: lo storage che segue le applicazioni
Materiale YoctoIT per clienti e partner · Red Hat, RHEL, OpenShift, Ansible e gli altri prodotti citati sono marchi di Red Hat, Inc. o di sue affiliate.
01 · Cos'è

OpenShift Data Foundation, in chiaro.

ODF porta Ceph dentro OpenShift come storage nativo: volumi a blocchi per i database, file system condivisi, object storage S3 — provisionati via StorageClass, replicati tra i nodi, gestiti come tutto il resto della piattaforma. I dati diventano cittadini del cluster, non ospiti di una SAN.

3-in-1
block, file e object da un'unica piattaforma Ceph
Nativo
StorageClass e PVC: lo storage si chiede in YAML, arriva in secondi
Metro-DR
replica sincrona tra siti per i volumi che non possono perdersi
OpenShift Data Foundation
VESTE UFFICIALE RED HAT · DATA FOUNDATION
ARCHITETTURA UFFICIALE · DATA FOUNDATION · FONTE: RED HAT DOCS
ARCHITETTURA UFFICIALE · DATA FOUNDATION · FONTE: RED HAT DOCS
02 · Come lo si usa bene

Le cose che fanno la differenza.

Dentro il cluster

Applicazioni & VMPVC: la richiesta di storage
Block (RBD)
File (CephFS)
Object (S3)
tre interfacce, un backend
Ceph distribuito sui nodireplica e self-healing
Dischi NVMe locali o Fusionil ferro sotto
Lo storage come servizio del cluster

Sizing onesto

Ceph vuole nodi e dischi pensati: repliche, failure domain e crescita si dimensionano prima.

Storage per le VM

Con OpenShift Virtualization, ODF dà alle VM live migration e snapshot: il pezzo che completa la VMware exit.

Resilienza integrata

Snapshot, cloni e mirroring regionale: la protezione del dato dentro la piattaforma.

Osservabilità

Capacità, IOPS e salute Ceph nel monitoring del cluster: lo storage non è più una scatola nera.

03 · In profondità

Ceph dentro OpenShift, fatto bene

ODF impacchetta Ceph (RBD per i blocchi, CephFS per i file, RGW/NooBaa per gli oggetti) come operatore OpenShift: StorageClass pronte, replica 3 o erasure coding, failure domain per zona. Internal mode sui dischi dei nodi o external verso un Ceph esistente; il Multicloud Object Gateway federa S3; Regional-DR e Metro-DR (stretched) danno RPO asincrono o zero ai carichi stateful, VM incluse.

  • 3-in-1 — RBD, CephFS, S3: tre semantiche da un cluster solo
  • Internal/External — dischi dei worker o Ceph esterno: la topologia si sceglie
  • Failure domain — repliche distribuite per zona/rack: il guasto previsto dal design
  • Metro-DR — stretched cluster con arbiter: RPO 0 tra due siti vicini
  • NooBaa/MCG — il gateway S3 che federa bucket ovunque: namespace unico
  • Capacity alert — soglie e espansione per OSD: Ceph non ama il 100%
04 · Numeri e ciclo di vita

I numeri che contano.

3x
la replica di default (o EC per efficienza)
RPO 0
in Metro-DR stretched fino a ~10ms RTT
S3
l'API oggetti interna: il lake dentro il cluster
85%
la soglia di riempimento da non superare mai: la governiamo
Lo storage container-native è un cluster nel cluster: lo dimensioniamo per failure domain e lo teniamo lontano dalle soglie rosse.
05 · Use case

Dove rende davvero.

Database su OpenShift

PostgreSQL, MongoDB e code con volumi replicati.

AI & data pipeline

Object storage S3 on-prem per dataset e modelli.

Stateful ovunque

Le app con stato senza dipendere da una SAN esterna.

Container senza storage pensato = incidenti annunciati: ODF dimensionato e gestito da chi lo esercita.