Modulo 1 — Storage

⏱ Tempo di lettura: ~15 minuti 🎯 Obiettivo: capire dove finiscono i dischi delle VM in OpenShift, come si replica la logica delle Storage Policy, dove sta lo Storage vMotion e cosa cambia rispetto al mondo dei datastore.

Punto di partenza: come funziona oggi in vSphere

In vSphere il modello mentale è semplice e consolidato:

I dischi delle VM (.vmdk) vivono dentro un datastore.
Un datastore può essere VMFS su SAN/iSCSI, NFS, vSAN o vVols.
Le Storage Policy (SPBM) descrivono requisiti (es. RAID-1, 3 repliche, latency ≤ 5 ms) e il datastore conforme a quei requisiti viene scelto in automatico.
Lo Storage vMotion sposta a caldo i dischi di una VM da un datastore all’altro, senza spegnerla.
Le snapshot sono operate al livello della VM (anche se di fatto agiscono sui dischi).

L’admin VMware pensa in termini di “dove metto i dischi” → datastore. L’admin OpenShift pensa in termini di “che tipo di storage richiede questa VM” → StorageClass. È lo stesso bisogno, ma il punto di applicazione è diverso.

Il modello OpenShift: PV, PVC, StorageClass

Il cuore dello storage in Kubernetes (e quindi in OpenShift Virtualization) sono tre oggetti:

              ┌───────────────────────────────────────┐
              │              StorageClass             │
              │   (= profilo, "che tipo di storage")  │
              └────────────────────┬──────────────────┘
                                   │ provisioning dinamico
                                   ▼
              ┌───────────────────────────────────────┐
              │           PersistentVolume (PV)        │
              │   (= il volume reale sul backend)      │
              └────────────────────┬──────────────────┘
                                   │ binding
                                   ▼
              ┌───────────────────────────────────────┐
              │       PersistentVolumeClaim (PVC)     │
              │   (= la "richiesta" che fa la VM/pod) │
              └────────────────────┬──────────────────┘
                                   │ usato da
                                   ▼
                          Virtual Machine / Pod

Tradotto:

StorageClass è il profilo. È il concetto più vicino a una Storage Policy vSphere: descrive un tipo di storage (es. ocs-storagecluster-ceph-rbd per block, ocs-storagecluster-cephfs per file) con le sue caratteristiche e parametri. L’admin definisce le StorageClass disponibili nel cluster.
PersistentVolume (PV) è il volume vero e proprio sul backend (un LUN, un share NFS, una disk image su Ceph…). Lo crea il provisioner CSI in modo dinamico, oppure lo crea manualmente l’admin.
PersistentVolumeClaim (PVC) è la richiesta che fa l’utente: “mi serve un volume da 100 Gi, modalità ReadWriteOnce, da una StorageClass gold”. OpenShift trova/crea il PV adatto e lo lega al PVC.

Per una VM in OpenShift Virtualization, ogni disco è un PVC. Il .vmdk non c’è più: i dischi sono PVC che, sotto, possono contenere immagini in formato raw o qcow2.

CSI: il driver universale

Tutto questo è reso possibile dal Container Storage Interface (CSI): uno standard di interfaccia con cui i vendor di storage (Dell, NetApp, Pure, HPE, IBM, Ceph/ODF, AWS EBS, Azure Disk, vSphere stesso…) forniscono un driver. Da quel momento OpenShift può usare quel backend come provider di PV. È l’equivalente concettuale di “VAAI/VASA per Kubernetes”.

🔗 Per i driver CSI supportati: CSI drivers in OpenShift.

Tabella di mapping delle feature

Cosa fai in vSphere	Equivalente OpenShift Virtualization
Memorizzare il disco di una VM su un datastore	Allocare un PV tramite PVC
Definire una Storage Policy (SPBM)	Definire una StorageClass
Usare backend diversi (vSAN, NFS, FC, iSCSI, RDM)	Usare driver CSI specifici per ciascun backend; ODF (Ceph) come opzione full-stack Red Hat
Storage vMotion (spostare disco di VM a caldo)	Storage live migration fra StorageClass (vedi nota più sotto)
Ridimensionare a caldo un disco	Espansione del PVC (online resize, supportato dai principali driver CSI)
Snapshot della VM / dei dischi	VolumeSnapshot + meccanismo VM-level snapshot
Cloning accelerato (VAAI XCOPY)	Clonazione tramite driver CSI (offload sul backend, se supportato)
Storage DRS (rebalancing automatico fra datastore)	❌ Non c’è equivalente diretto — il rebalancing è demandato al backend (es. CRUSH di Ceph)
Catalogo storage vendor (Pure, NetApp, Dell…)	Stessi vendor, ma tramite driver CSI certificati

Quando entri nella OpenShift web console e clicchi su Storage nel menu di sinistra, vedi una serie di voci. Ecco cosa significano per chi viene da vSphere:

Voce di menu OpenShift	Cosa rappresenta	Equivalente / commento per admin VMware
PersistentVolumes	Lista dei volumi reali nel cluster	È simile a vedere la lista dei `.vmdk` o dei vVol esistenti, ma a un livello più astratto
PersistentVolumeClaims	Le “richieste” di storage fatte dalle VM/pod	Concetto nuovo: in vSphere non esiste un oggetto separato per la richiesta
StorageClasses	I profili di storage del cluster	È il parente più stretto delle Storage Policy SPBM
VolumeSnapshots	Le snapshot dei volumi	Equivale alle snapshot dei dischi VM (livello disco)
VolumeSnapshotClasses	I profili che descrivono come fare le snapshot per ciascun backend	Concetto nuovo: in vSphere è implicito nel datastore
VolumeSnapshotContents	I contenuti reali delle snapshot, lato backend	Vista “interna” delle snapshot, di solito non si tocca a mano
Data Foundation	Console di gestione di OpenShift Data Foundation (Ceph)	Concettualmente paragonabile a vSAN: storage software-defined integrato sul cluster
Object Storage	Gestione dell’Object Storage (S3-compatible) di ODF	Non ha un parente diretto in vSphere; pensa a un MinIO/S3 dentro il cluster

Esempio: una VM con un disco da 50 Gi

Per dare concretezza, ecco come si traduce in YAML il fatto di “creare una VM con un disco da 50 GB su una specifica policy”:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: web01
  namespace: produzione-web
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
        resources:
          requests:
            memory: 4Gi
            cpu: "2"
      volumes:
        - name: rootdisk
          dataVolume:
            name: web01-root
---
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: web01-root
  namespace: produzione-web
spec:
  source:
    pvc:
      namespace: openshift-virtualization-os-images
      name: rhel9-template
  storage:
    resources:
      requests:
        storage: 50Gi
    storageClassName: ocs-storagecluster-ceph-rbd   # ← qui scegli il "datastore equivalente"

Dove in vSphere avresti detto “deploy from template, scegli il datastore X”, qui:

DataVolume clona da un’immagine sorgente (l’equivalente di un content library template);
la storageClassName decide su quale tipologia di storage atterra;
la VM si riferisce al volume tramite dataVolume.name.

Storage live migration: l’equivalente di Storage vMotion

A partire da OpenShift Virtualization 4.18 esiste la storage live migration: puoi spostare a caldo i dischi di una VM da una StorageClass a un’altra, senza spegnere la VM. È l’analogo concettuale di Storage vMotion.

Workflow tipico in CLI:

# Migrare il disco principale di una VM verso una nuova StorageClass
oc patch vm web01 --type=merge -p '{
  "spec":{
    "updateVolumesStrategy": "Migration",
    "template":{"spec":{"volumes":[{"name":"rootdisk","persistentVolumeClaim":{"claimName":"web01-root-new"}}]}}
  }
}'

(Il campo esatto e l’API di gestione vanno verificati sulla doc ufficiale per la tua versione di OCP, perché l’API sta evolvendo.)

💡 Differenza importante con Storage vMotion. In vSphere puoi cambiare datastore senza vincoli particolari. In OpenShift, lo spostamento avviene fra StorageClass e funziona in modo affidabile fra backend che supportano la copia online (snapshot + clone CSI). Verifica sempre la matrice di supporto del tuo driver.

Le quattro casistiche di “storage migration” da capire

Storage vMotion in vSphere copre un solo workflow ma viene usato per molte ragioni diverse. In OpenShift è utile separare le quattro casistiche tipiche, perché la risposta è diversa caso per caso:

“Il datastore si sta riempiendo, devo spostare VM altrove.” In OpenShift il problema non si presenta nello stesso modo: non c’è un datastore con tante VM dentro. La capacity expansion la gestisce il backend storage (Ceph aggiunge OSD, NetApp aggiunge aggregate, ecc.) o il provisioner CSI. Se ti serve “fare spazio” lavorando sulle VM, agisci sul backend, non sulle VM.
“Voglio cambiare classe di storage a una VM” (es. l’ho creata sbagliata: SSD invece di HDD, RWO invece di RWX). Risposta: storage live migration se la versione di OCP la supporta, altrimenti cold migration con stop della VM, copia del PVC verso una nuova StorageClass, restart.
“Stiamo facendo lifecycle dello storage array (stesso vendor, nuova generazione).” Risposta: usa il tooling del vendor storage per migrare i volumi a livello backend (NetApp SnapMirror, Pure ActiveCluster, ecc.). I PV vengono ridichiarati sulla nuova destinazione, le VM continuano a vederli via lo stesso PVC. È la modalità più non-disruptive.
“Stiamo cambiando vendor di storage.” Risposta: cold migration delle VM (stop, copia PVC verso nuovo backend, start). Niente magia: per un cambio di vendor serve sempre downtime pianificato. Il Migration Toolkit for Containers (MTC) può aiutare a spostare interi namespace, comprese le VM.

In pratica: il “muovi i dischi” che facevi con Storage vMotion in vSphere si divide in quattro pattern distinti, e solo il caso (2) ha un equivalente diretto. Gli altri si risolvono “altrove” nello stack — il che è coerente con lo spirito Kubernetes: ogni livello ha la sua responsabilità.

Snapshot: il modello a due livelli

In OpenShift Virtualization c’è una distinzione importante che in vSphere non esiste:

VolumeSnapshot: snapshot del volume di disco a livello CSI. Veloce, atomica, gestita dal backend. Più o meno come una snapshot del datastore.
VirtualMachineSnapshot: snapshot a livello di VM. Cattura lo stato dei dischi (più, opzionalmente, la memoria) ed è coordinata da KubeVirt. È la più simile alla snapshot VM di vSphere.

In pratica:

# Snapshot completa della VM (analogo a snapshot VM in vSphere)
virtctl snapshot create web01-snap-pre-update --vm=web01

# Verifica
oc get vmsnapshot

# Restore
virtctl snapshot restore web01-snap-pre-update --vm=web01

⚠️ Stesso warning di vSphere: le snapshot sono per troubleshooting o per il “prima di un upgrade”, non sono un sistema di backup. Per il backup vero c’è OADP (OpenShift API for Data Protection) e i partner certificati (Trilio, Veeam Kasten, Portworx PX-Backup, NetBackup…).

Differenze chiave da tenere a mente

Niente datastore esplicito. Sparisce il concetto di “scegli il datastore”. Il decoupling è tra StorageClass (cosa voglio) e PV (dove finisce).
Niente Storage DRS. Se cerchi un “qualcuno che bilanci automaticamente fra datastore”, in OpenShift il bilanciamento si fa al livello del backend (Ceph CRUSH, vSAN, array vendor). Concetto da accettare e ridisegnare.
Modalità di accesso. Le PV hanno accessModes: ReadWriteOnce (RWO), ReadWriteMany (RWX), ReadOnlyMany (ROX). RWX è cruciale per le live migration: solo PV in RWX (o RWO + supporto specifico di “swapping” RWX-RWO temporaneo) consentono di muovere una VM fra nodi senza interruzione.
Volume binding mode. Immediate vs WaitForFirstConsumer: nel primo caso il PV viene allocato subito, nel secondo solo quando la VM viene effettivamente schedulata su un nodo. Per VM che richiedono storage locale al nodo, WaitForFirstConsumer è quasi sempre la scelta giusta.
Storage Profile. OpenShift Virtualization aggiunge un oggetto StorageProfile per dichiarare quali capability ha una StorageClass dal punto di vista delle VM (es. supporto a clone, snapshot, RWX). Vale la pena conoscerlo: spesso problemi di “non riesco a clonare la VM” si risolvono lì.

Best practice operative

Preferisci StorageClass con volumeBindingMode: WaitForFirstConsumer per la maggior parte delle VM: evita che il PV venga creato in una zona del cluster dove poi la VM non può girare.
Usa RWX dove possibile, almeno per i dischi root delle VM che vuoi poter migrare a caldo. Senza RWX la live migration richiede passi extra.
Storage Profile e default storage class. Definisci sempre una StorageClass di default per il cluster (annotazione storageclass.kubernetes.io/is-default-class: "true"): semplifica la creazione di VM da template.
Backup ≠ snapshot. Pianifica un sistema di backup vero (OADP + partner) fin dal giorno 1: snapshot è solo un punto di ripristino transitorio.

Approfondimenti ufficiali

About virtualization (Red Hat docs) — entry point della documentazione
Storage in OpenShift (concetti generali)
Configuring Storage Profiles per VM
Backup and restore tramite VM snapshot
OpenShift Data Foundation — soluzione storage software-defined Red Hat (Ceph)

← Modulo 0 — Overview | Avanti → Modulo 2 — Networking