Nutanix Elastic VM Storage

Nutanix Elastic VM Storage: condividere lo storage tra cluster AHV con Prism Central 7.5

Con AOS 7.5, AHV 11.0 e Prism Central 7.5, Nutanix introduce Elastic VM Storage, la possibilità di condividere uno storage container di un cluster AHV con VM in esecuzione su altri cluster AHV gestiti dallo stesso Prism Central domain. In pratica il consumo di storage viene disaccoppiato dalla località del compute: una VM può girare su un cluster e avere i propri dischi su un altro.

È un cambio di modello concreto. Fino a oggi, se un cluster era saturo lato storage ma aveva compute libero — o viceversa — l’unica opzione era espandere quel cluster o migrare i workload. Con Elastic VM Storage si può attingere alla capacità inattiva di un altro cluster senza spostare fisicamente i dati, portando on-prem un comportamento più vicino all’elasticità cloud.

Come funziona

Il meccanismo si basa su uno shared storage container creato sul cluster che fornisce lo storage. Una volta esposto, quel container diventa selezionabile in fase di creazione VM da altri cluster registrati sullo stesso Prism Central. Il control plane risiede interamente in Prism Central, che gestisce la relazione cross-cluster.

Il flusso è lineare:

Sul cluster che fornisce storage, si crea un container di tipo Shared (in alternativa si può convertire il SelfServiceContainer in shared).
In fase di creazione della VM su un altro cluster, si seleziona il cluster che fornisce il compute e si assegnano i dischi allo storage remoto condiviso.

Da notare il vincolo di posizionamento dei dischi: tutti i dischi di una singola VM devono risiedere su un unico cluster storage remoto. Non è possibile distribuire i dischi della stessa VM su più cluster remoti, né combinare storage locale e remoto sulla medesima VM.

Requisiti

Cluster di compute e di storage registrati sullo stesso Prism Central ≥ 7.5 (AOS 7.5 / AHV 11.0 su entrambi i lati).
Solo AHV: ESXi e Hyper-V non sono supportati.
Latency round-trip tra i cluster ≤ 5 ms. Se il requisito non è soddisfatto, la creazione della VM fallisce di proposito, per evitare problemi di performance.
Data Services IP configurato da Prism Element sui cluster coinvolti: è ciò che abilita la comunicazione cross-cluster.
Container Shared su RF2 o RF3. RF1 non è supportato.

Limitazioni e workload adatti

Prima di considerarne l’uso in produzione, vanno pesate le limitazioni. Le VM che usano Elastic VM Storage:

Non possono essere create da Template o OVA.
Non possono essere incluse in una protection policy di Nutanix Disaster Recovery.
Non supportano recovery point application-consistent.
Non supportano recovery point se hanno vTPM abilitato.
Non possono essere ripristinate (revert) da un recovery point.
Non permettono l’installazione di NGT.

Vanno inoltre considerati due comportamenti operativi:

Un cluster con connessioni Elastic VM Storage attive non può essere deregistrato da Prism Central finché non vengono rimosse tutte le dipendenze (rif. KB-4944).
In un evento di High Availability, se il cluster storage remoto è irraggiungibile, il failover delle Elastic VM su quell’host resta in pausa fino al ripristino della connettività. La dipendenza di rete tra cluster diventa quindi parte del dominio di fault della VM.

Questo insieme di vincoli delinea con chiarezza il perimetro d’uso. Elastic VM Storage è adatto a workload stateless, di servizio o non critici, a esigenze di burst temporaneo di compute su capacità storage disponibile altrove, e a scenari di ribilanciamento tra cluster storage-bound e compute-bound. È invece da escludere per VM che devono rientrare in un piano di Disaster Recovery, che richiedono consistenza applicativa dei backup o che dipendono da vTPM e NGT.

Quando ha senso

Elastic VM Storage non è un rimpiazzo dell’architettura storage tradizionale del cluster, ma una leva di efficienza. Ha senso quando la capacità è distribuita in modo disomogeneo tra cluster e si vuole evitare un’espansione hardware o una migrazione dati solo per liberare risorse. Il valore sta nel recuperare capacità inattiva e nel rendere più fluida l’allocazione delle risorse, mantenendo la gestione centralizzata su Prism Central.

La raccomandazione pratica è la stessa che vale per ogni novità che tocca il data path: validare il comportamento in pre-produzione, misurare la latenza inter-cluster reale rispetto alla soglia dei 5 ms e mappare esplicitamente quali workload rientrano nel perimetro supportato prima di portarlo in esercizio.

Fonte: Nutanix Prism Central Guide (pc.7.5) — sezioni Storage Container Management, Creating a Shared Storage Container, Limitations for Elastic VMs Storage Container.