Informazioni sui concetti di base e sui diversi componenti della funzionalità di vSphere Virtual Volumes.

Oggetti volume virtuale

I volumi virtuali sono incapsulazioni dei file delle macchine virtuali, dei dischi virtuali e dei loro derivati.

I volumi virtuali vengono archiviati in modo nativo in un sistema di storage connesso agli host ESXi tramite Ethernet o SAN. Vengono esportati come oggetti da un sistema di storage conforme e vengono gestiti interamente dall'hardware sul lato storage. In genere un GUID univoco identifica un volume virtuale. I volumi virtuali non vengono sottoposti a provisioning preliminare, ma vengono creati automaticamente quando si eseguono operazioni di gestione delle macchine virtuali. Queste operazioni includono la creazione, la clonazione e lo snapshot di una macchina virtuale. ESXi e vCenter Server associano uno o più volumi virtuali a una macchina virtuale.

Tipi di volumi virtuali

Il sistema crea i seguenti tipi di volumi virtuali per gli elementi principali che costituiscono la macchina virtuale:
Data-vVol
Volume virtuale dei dati che corrisponde direttamente a ciascun file .vmdk di disco virtuale. Come i file dei dischi virtuali nei datastore tradizionali, i volumi virtuali vengono presentati alle macchine virtuali come dischi SCSI o NVMe. Data-vVol può essere in thick o thin provisioning.
Config-vVol
Un volume virtuale di configurazione, o directory home, rappresenta una piccola directory che contiene file di metadati per una macchina virtuale. I file includono un file .vmx, file descrittore per dischi virtuali, file di registro e così via. Il volume virtuale della configurazione è formattato con un file system. Quando ESXi utilizza il protocollo SCSI o NVMe per connettersi allo storage, i volumi virtuali della configurazione vengono formattati con VMFS. Con il protocollo NFS, i volumi virtuali di configurazione vengono presentati come una directory NFS. In genere, è in thin provisioning.
A partire da vSphere 7.0 Update 2, i partner possono aumentare config-vVol a un valore superiore a 4 GB. Rivolgersi al partner Virtual Volumes per implementare questa funzionalità, se è supportata dal partner e applicabile all'ambiente in uso.
vSphere 8.0 Update 2 supporta il recupero dello spazio per config-vVols che si trovano nei datastore Virtual Volumes a cui si accede tramite i protocolli SCSI o NVMe. Per ulteriori informazioni, vedere Recupero di spazio nei datastore vSphere Virtual Volumes
Swap-vVol
Creato alla prima accensione di una macchina virtuale. Si tratta di un volume virtuale che consente di contenere le copie delle pagine della memoria della macchina virtuale che non possono essere conservate in memoria. La sua dimensione è determinata dalle dimensioni della memoria della macchina virtuale. È in thick provisioning per impostazione predefinita
Snapshot-vVol
Un volume di memoria virtuale che contiene i contenuti della memoria della macchina virtuale per uno snapshot. In thick provisioning.
Per ulteriori informazioni, vedere Snapshot vSphere Virtual Volumes.
Altro
Un volume virtuale per funzionalità specifiche. Ad esempio, viene creato un volume virtuale digest per la cache di lettura basata su contenuti (CBRC).

In genere, una macchina virtuale crea almeno tre volumi virtuali, data-vVol, config-vVol e swap-vVol. Il numero massimo dipende dal numero di dischi virtuali e snapshot che si trovano nella macchina virtuale.

Utilizzando volumi virtuali diversi per componenti diversi di macchine virtuali, è possibile applicare e modificare i criteri di storage a livello di granularità più fine. Ad esempio, un volume virtuale che contiene un disco virtuale può includere un set di servizi più complesso rispetto al volume virtuale per il disco di avvio della macchina virtuale.

Provisioning del disco

La funzionalità Virtual Volumes supporta un concetto di dischi virtuali con thin e thick provisioning. Tuttavia, dalla prospettiva dell'I/O, l'implementazione e la gestione del thin o thick provisioning da parte degli array sono trasparenti per l'host ESXi. ESXi effettua l'offload negli array di storage di eventuali funzioni correlate al thin provisioning.

È possibile selezionare il tipo thin o thick per il disco virtuale al momento della creazione della macchina virtuale. Se il disco è thin e si trova in un datastore Virtual Volumes, non è possibile modificarne il tipo in un secondo momento aumentando le dimensioni del disco.

Dischi condivisi

È possibile collocare un disco condiviso in uno storage Virtual Volumes che supporta le prenotazioni persistenti SCSI per Virtual Volumes. È possibile utilizzare questo disco come disco quorum ed eliminare gli RDM nei cluster MSCS. Per ulteriori informazioni, vedere la documentazione di Gestione delle risorse di vSphere.

Provider di storage Virtual Volumes

Un provider di storage Virtual Volumes, chiamato anche provider VASA, è un componente software che funge da servizio di riconoscimento dello storage per vSphere. Il provider media la comunicazione out-of-band tra gli host vCenter Server e ESXi da un lato e un sistema di storage dall'altro.

Il provider di storage è implementato tramite VMware APIs for Storage Awareness (VASA) e viene utilizzato per gestire tutti gli aspetti dello storage Virtual Volumes.

Il provider di storage fornisce informazioni dal container di storage sottostante. Le funzionalità del container di storage vengono visualizzate in vCenter Server e in vSphere Client. Quindi, a sua volta, il provider di storage comunica i requisiti di storage della macchina virtuale, che è possibile definire sotto forma di criterio di storage, al livello di storage. Questo processo di integrazione garantisce che un volume virtuale creato nel livello di storage soddisfi i requisiti delineati nel criterio.

In genere, i fornitori sono responsabili della fornitura di provider di storage in grado di integrarsi con vSphere e fornire supporto a Virtual Volumes. Ogni provider di storage deve essere certificato da VMware e distribuito correttamente. Per informazioni sulla distribuzione e l'aggiornamento del provider di storage Virtual Volumes a una versione compatibile con la versione corrente di ESXi, contattare il fornitore dello storage.

Dopo aver distribuito il provider di storage, è necessario registrarlo in vCenter Server. Vedere Registrazione dei provider di storage per Virtual Volumes. Per aggiornare i provider di storage o per le altre operazioni che è possibile eseguire, vedere Gestione dei provider di storage per vSphere Virtual Volumes.

Container di storage Virtual Volumes

A differenza dello storage tradizionale basato su blocchi o file, la funzionalità Virtual Volumes non richiede lo storage preconfigurato sul lato storage. Al contrario, Virtual Volumes utilizza un container di storage. Si tratta di un pool di capacità di storage raw o di un'aggregazione di funzionalità di storage che un sistema di storage può fornire a volumi virtuali.

Un container di storage è una parte della struttura di storage logica ed è un'unità logica dell'hardware sottostante. Il container di storage raggruppa logicamente i volumi virtuali in base alle esigenze di gestione e amministrazione. Ad esempio, il container di storage può contenere tutti i volumi virtuali creati per un tenant in una distribuzione multi-tenant o in un reparto in una distribuzione enterprise. Ogni container di storage funge da storage di volumi virtuali e i volumi virtuali vengono allocati all'esterno della capacità del container di storage.

In genere, un amministratore di storage sul lato storage definisce i container di storage. Il numero di container di storage, la loro capacità e le relative dimensioni dipendono da un'implementazione specifica del fornitore. È necessario almeno un container per ogni sistema di storage.

Nota: Un singolo container di storage non può estendersi su array fisici diversi.

Dopo aver registrato un provider di storage associato al sistema di storage, vCenter Server individua tutti i container di storage configurati insieme ai relativi profili di funzionalità di storage, ai Protocol Endpoint e ad altri attributi. Un singolo container di storage può esportare più profili di funzionalità. Di conseguenza, le macchine virtuali con esigenze diverse e impostazioni dei criteri di storage diverse possono far parte dello stesso container di storage.

Inizialmente, tutti i container di storage rilevati non sono connessi ad alcun host specifico e non è possibile visualizzarli nella vSphere Client. Per montare un container di storage, è necessario mapparlo a un datastore Virtual Volumes.

Protocol Endpoint statici

Con i trasporti SCSI o NFS, gli host ESXi utilizzano un proxy I/O logico, denominato Protocol Endpoint, per comunicare con i volumi virtuali. ESXi utilizza i Protocol Endpoint per stabilire un percorso di dati su richiesta dalle macchine virtuali ai rispettivi volumi virtuali.

Nota: Le informazioni contenute in questa sezione si applicano solo ai Protocol Endpoint statici che utilizzano i trasporti SCSI o NFS. Per informazioni specifiche sui Protocol Endpoint NVMe, vedere NVMe e Virtual Volumes in vSphere.

Ogni volume virtuale è associato a un Protocol Endpoint specifico. Quando una macchina virtuale sull'host esegue un'operazione di I/O, il Protocol Endpoint indirizza l'I/O al volume virtuale appropriato. In genere, un sistema di storage richiede solo alcuni Protocol Endpoint. Un singolo Protocol Endpoint può connettersi a centinaia o migliaia di volumi virtuali.

Sul lato storage, un amministratore di storage può configurare i Protocol Endpoint, uno o più per ogni container di storage. I Protocol Endpoint fanno parte della struttura di storage fisica. Il sistema di storage esporta i Protocol Endpoint con i container di storage associati tramite il provider di storage. Dopo aver mappato il container di storage a un datastore Virtual Volumes, l'host di ESXi rileva i Protocol Endpoint, che diventano visibili in vSphere Client. I Protocol Endpoint possono essere rilevati anche durante una nuova scansione dello storage. Più host possono individuare e montare i Protocol Endpoint.

Nella vSphere Client, l'elenco dei Protocol Endpoint disponibili è simile all'elenco dei dispositivi di storage host. È possibile utilizzare trasporti di storage diversi per esporre i Protocol Endpoint a ESXi. Quando si utilizza il trasporto basato su SCSI, il Protocol Endpoint rappresenta un LUN proxy definito da un WWN LUN basato su T10. Per il protocollo NFS, il Protocol Endpoint è un punto di montaggio, ad esempio un indirizzo IP e un nome di condivisione. È possibile configurare il multipathing sul Protocol Endpoint basato su SCSI, ma non sul Protocol Endpoint basato su NFS. Indipendentemente dal protocollo utilizzato, l'array di storage può fornire più Protocol Endpoint a scopo di disponibilità.

I Protocol Endpoint sono gestiti per array. ESXi e vCenter Server presumono che tutti i Protocol Endpoint riportati per un array siano associati a tutti i container in tale array. Ad esempio, se un array ha due container e tre Protocol Endpoint, ESXi presuppone che i volumi virtuali di entrambi i container possano essere associati a tutti e tre i Protocol Endpoint.

Per informazioni sulla visualizzazione dei Protocol Endpoint statici in vSphere Client, vedere Controllo e gestione dei Protocol Endpoint statici.

Binding e annullamento del binding dei volumi virtuali

Al momento della creazione, un volume virtuale è un'entità passiva e non è immediatamente pronto per l'I/O. Per accedere al volume virtuale, ESXi o vCenter Server invia una richiesta di binding.

Il sistema di storage risponde con un ID del protocol endpoint che diventa un punto di accesso al volume virtuale. Il protocol endpoint accetta tutte le richieste di I/O al volume virtuale. Questo binding esiste finché ESXi non invia una richiesta di rimozione del binding per il volume virtuale.

Per le richieste di binding successive nello stesso volume virtuale, il sistema di storage può restituire ID Protocol Endpoint diversi.

Quando si utilizza il protocollo NVMe, la risposta del volume virtuale di binding fornisce l'NQN del sottosistema NVMe e l'ID spazio dei nomi (nsid) dell'oggetto volume virtuale dello spazio dei nomi. L'host ESXi utilizza queste informazioni e le risolve nel gruppo ANA all'interno del sottosistema. Se non esiste già, viene creato un endpoint del protocollo virtuale (vPE) corrispondente a questo gruppo ANA. Tale vPE viene utilizzato per indirizzare tutte le richieste di I/O a Virtual Volumes.

Quando si ricevono richieste di binding simultanee a un volume virtuale da più host ESXi, il sistema di storage può restituire gli stessi o diversi binding di endpoint a ogni host ESXi che esegue la richiesta. In altre parole, il sistema di storage può associare host simultanei diversi allo stesso volume virtuale tramite endpoint diversi.

L'operazione di rimozione del binding rimuove l'access point I/O per il volume virtuale. Il sistema di storage potrebbe rimuovere il binding del volume virtuale dal Protocol Endpoint immediatamente o dopo un ritardo oppure eseguire altre operazioni. Non è possibile eliminare un volume virtuale associato finché non viene rimosso il binding.

Datastore Virtual Volumes

Un datastore Virtual Volumes rappresenta un container di storage in vCenter Server e vSphere Client.

Dopo che vCenter Server rileva i container di storage esportati dai sistemi di storage, è necessario montarli come datastore Virtual Volumes. I datastore Virtual Volumes non vengono formattati in modo tradizionale, ad esempio i datastore VMFS. È comunque necessario crearli perché tutte le funzionalità di vSphere, tra cui FT, HA, DRS e così via, richiedono che il costrutto del datastore funzioni correttamente.

La procedura guidata di creazione del datastore in vSphere Client consente di mappare un container di storage a un datastore Virtual Volumes. Il datastore Virtual Volumes creato corrisponde direttamente al container di storage specifico.

Dalla prospettiva di un amministratore vSphere, il datastore Virtual Volumes è simile a qualsiasi altro datastore e viene utilizzato per contenere le macchine virtuali. Analogamente agli altri datastore, è possibile esplorare il datastore Virtual Volumes ed elencare i volumi virtuali in base al nome della macchina virtuale. Come i datastore tradizionali, il datastore Virtual Volumes supporta lo smontaggio e il montaggio. Tuttavia tali operazioni, quali l'aggiornamento e il ridimensionamento, non sono applicabili al datastore Virtual Volumes. La capacità del datastore Virtual Volumes è configurabile dall'amministratore di storage all'esterno di vSphere.

È possibile utilizzare i datastore Virtual Volumes con i datastore VMFS e NFS tradizionali e con vSAN.
Nota: Le dimensioni di un volume virtuale devono essere un multiplo di 1 MB, con una dimensione minima di 1 MB. Di conseguenza, tutti i dischi virtuali di cui si esegue il provisioning in un datastore Virtual Volumes devono essere multipli pari di 1 MB. Se il disco virtuale di cui si esegue la migrazione al datastore Virtual Volumes non è un multiplo pari di 1 MB, estendere il disco al più vicino multiplo pari di 1 MB.

Per creare un datastore Virtual Volumes, vedere Creazione di un datastore Virtual Volumes nell'ambiente vSphere.

Virtual Volumes e criteri di storage della macchina virtuale

Una macchina virtuale in esecuzione in un datastore Virtual Volumes richiede un criterio di storage macchina virtuale.

Un criterio di storage macchina virtuale è un insieme di regole che contiene requisiti di posizionamento e qualità del servizio per una macchina virtuale. Il criterio applica il posizionamento appropriato della macchina virtuale all'interno dello storage Virtual Volumes e garantisce che lo storage possa soddisfare i requisiti della macchina virtuale.

È possibile utilizzare l'interfaccia Criteri di storage della macchina virtuale per creare un criterio di storage Virtual Volumes. Quando si assegna il nuovo criterio alla macchina virtuale, il criterio fa in modo che lo storage Virtual Volumes soddisfi i requisiti.

Criterio di archiviazione predefinito Virtual Volumes

Per Virtual Volumes, VMware fornisce un criterio di storage predefinito che non contiene regole o requisiti di storage, denominato criterio Nessun requisito Virtual Volumes. Questo criterio viene applicato agli oggetti macchina virtuale quando non si specifica un altro criterio per la macchina virtuale nel datastore Virtual Volumes. Con il criterio Nessun requisito, gli array di storage possono determinare il posizionamento ottimale per gli oggetti della macchina virtuale.

Il criterio predefinito Nessun requisito offerto da VMware ha le seguenti caratteristiche:

  • Non è possibile eliminare, modificare o clonare questo criterio.
  • Il criterio è compatibile solo con i datastore Virtual Volumes.
  • È possibile creare un criterio di storage macchina virtuale per Virtual Volumes e designarlo come predefinito.

Virtual Volumes e protocolli di storage

Un sistema di storage Virtual Volumes fornisce Protocol Endpoint individuabili nella struttura di storage fisica. Gli host ESXi utilizzano i Protocol Endpoint per connettersi ai volumi virtuali nello storage. Il funzionamento dei Protocol Endpoint dipende dai protocolli di storage che espongono gli endpoint agli host di ESXi.

Virtual Volumes supporta NFS versione 3 e 4.1, iSCSI, Fibre Channel, FCoE, NVMe su Fibre Channel e NVMe su TCP.

Indipendentemente dal protocollo di storage utilizzato, i Protocol Endpoint forniscono un accesso uniforme allo storage SAN e NAS. Un volume virtuale, come un file su un altro datastore tradizionale, viene presentato a una macchina virtuale come disco SCSI o NVMe.

Nota:

Un container di storage è dedicato a SAN (SCSI o NVMe) o NAS e non può essere condiviso tra questi tipi di protocollo. Un array può presentare un container di storage con Protocol Endpoint SCSI e un container diverso con Protocol Endpoint NFS. Il contenitore non può utilizzare una combinazione di protocolli di accesso allo storage SCSI, NVMe e NFS.

Virtual Volumes e trasporto basato su SCSI

Sugli array di dischi, Virtual Volumes supporta i protocolli Fibre Channel, FCoE e iSCSI.

Quando si utilizza il protocollo basato su SCSI, il Protocol Endpoint rappresenta un LUN proxy definito da un WWN LUN basato su T10.

Come tutti i LUN basati su blocchi, i Protocol Endpoint vengono rilevati utilizzando comandi di individuazione LUN standard. L'host ESXi esegue periodicamente la scansione di nuovi dispositivi e rileva in modo asincrono i Protocol Endpoint basati su blocco. Il Protocol Endpoint può essere accessibile da più percorsi. Il traffico su questi percorsi segue criteri di selezione dei percorsi noti, come è tipico per i LUN.

Sugli array di dischi basati su SCSI al momento della creazione della macchina virtuale, ESXi crea un volume virtuale e lo formatta come VMFS. Questo piccolo volume virtuale archivia tutti i file di metadati della macchina virtuale ed è denominato config‐vVol. Il volume config‐vVol funziona come localizzatore di storage della macchina virtuale per vSphere.

Virtual Volumes negli array di dischi supporta lo stesso set di comandi SCSI di VMFS e utilizzano ATS come meccanismo di blocco.

Supporto CHAP per gli endpoint iSCSI

Virtual Volumes supporta il protocollo CHAP (Challenge Handshake Access Protocol) con destinazioni iSCSI. Questo supporto consente agli host ESXi di condividere le credenziali dell'iniziatore CHAP con i provider di storage Virtual Volumes, chiamati anche provider VASA, e ai provider di storage Virtual Volumes di generare eventi di sistema che informano vCenter Server delle modifiche alle credenziali di destinazione CHAP nell'array di storage.

Ogni host ESXi può includere più HBA e ogni HBA può avere proprietà configurate in tale host. Una di queste proprietà è il metodo di autenticazione che deve utilizzare HBA. L'autenticazione è facoltativa, ma se implementata deve essere supportata dall'iniziatore e dalla destinazione. CHAP è un metodo di autenticazione che può essere utilizzato in entrambe le direzioni tra l'iniziatore e la destinazione.

Per ulteriori informazioni sui diversi metodi di autenticazione CHAP, vedere Selezione del metodo di autenticazione CHAP. Per configurare il protocollo CHAP nell'host ESXi, vedere Configurazione dei parametri CHAP per le schede di storage iSCSI o iSER nell'host ESXi.

Virtual Volumes e trasporto NFS

Con lo storage NAS, un Protocol Endpoint è una condivisione NFS che l'host ESXi monta utilizzando l'indirizzo IP o il nome DNS e un nome di condivisione. Virtual Volumes supporta NFS versione 3 e 4.1 per accedere allo storage NAS. Sono supportati entrambi i formati IPv4 e IPv6.

Indipendentemente dalla versione utilizzata, un array di storage può fornire più Protocol Endpoint a scopo di disponibilità.

NFS versione 4.1 include inoltre meccanismi di trunking che abilitano il bilanciamento del carico e il multipathing.

Virtual Volumes sui dispositivi NAS supporta le stesse RPC (Remote Procedure Call) NFS utilizzate dagli host ESXi durante la connessione ai punti di montaggio NFS.

Sui dispositivi NAS, un config‐vVol è un sottoalbero di directory che corrisponde a una configurazione vVolID. Il volume config‐vVol deve supportare le directory e le altre operazioni necessarie per NFS.

Virtual Volumes e NVMe

Virtual Volumes supporta i protocolli NVMe, tra cui NVMe su Fibre Channel e NVMe su TCP. Un oggetto di volume virtuale è mappato a uno spazio dei nomi in un sottosistema NVMe. I gruppi ANA nel sottosistema NVMe sono visualizzati come endpoint del protocollo virtuale nell'host ESXi.

Gli endpoint del protocollo virtuale vengono utilizzati per la gestione dello stato del percorso quando lo stato del gruppo ANA viene modificato. L'host ESXi rileva dinamicamente i gruppi ANA, come e quando richiesto. Questo significa che il Protocol Endpoint virtuale viene creato solo quando l'host ESXi richiede l'accesso I/O a un volume virtuale dello spazio dei nomi nel sottosistema NVMe. Config-vVols in NVMe sono simili a SCSI formattati con VMFS. Vengono inoltre utilizzati per archiviare i file di metadati della macchina virtuale.

Per configurare NVMe con Virtual Volumes nell'host ESXi, vedere NVMe e Virtual Volumes in vSphere.

Architettura di Virtual Volumes

Un diagramma dell'architettura fornisce una panoramica del modo in cui tutti i componenti della funzionalità Virtual Volumes interagiscono tra loro.

L'illustrazione descrive il modo in cui interagiscono i diversi componenti di Virtual Volumes.

Questo video fornisce ulteriori informazioni sull'architettura di Virtual Volumes.