I componenti, le applicazioni e i carichi di lavoro di Supervisore devono archiviare e recuperare dati. Alcune applicazioni e oggetti possono utilizzare lo storage rapido temporaneo, mentre altri richiedono uno storage persistente.

Informazioni sui criteri di storage

Il Supervisore utilizza i criteri di storage per l'integrazione con lo storage disponibile nell'ambiente vSphere. I criteri rappresentano i datastore e gestiscono il posizionamento dello storage di tali componenti e oggetti come macchine virtuali del piano di controllo, dischi temporanei di Pod vSphere e immagini dei container. I criteri potrebbero essere necessari anche per il posizionamento dello storage di volumi persistenti e librerie di contenuti delle macchine virtuali. Se si utilizzano cluster di Tanzu Kubernetes Grid, i criteri di storage determinano anche come vengono distribuiti i nodi del cluster di Tanzu Kubernetes Grid.

I criteri di storage supportano tutti i datastore condivisi nell'ambiente, come VMFS, NFS, vSAN, incluso vSAN ESA, e vVols.

In base all'ambiente di storage vSphere e alle esigenze di DevOps, è possibile creare diversi criteri di storage per diverse classi di storage. Quando si abilita un Supervisore e si configurano spazi dei nomi, è possibile assegnare diversi criteri di storage che devono essere utilizzati da vari oggetti, componenti e carichi di lavoro.

Ad esempio, se un Pod vSphere monta tre tipi di dischi virtuali e l'ambiente di storage di vSphere dispone di tre classi di datastore, Bronze, Silver e Gold, è possibile creare criteri di storage per tutti i datastore. È quindi possibile utilizzare il datastore Bronzo per i dischi virtuali di immagini di container e temporanei e i datastore Argento e Oro per i dischi virtuali dei volumi persistenti.

Un pod vSphere monta tre tipi di dischi virtuali: disco virtuale del volume persistente, disco virtuale dell'immagine del container e disco virtuale temporaneo.

Per informazioni sulla creazione dei criteri di storage, vedere Creazione dei criteri di storage nella documentazione Installazione e configurazione di vSphere IaaS Control Plane.

Per informazioni generali sui criteri di storage, vedere il capitolo sulla gestione basata sui criteri di storage nella documentazione Storage di vSphere.

Criteri di storage per un Supervisore

A livello del Supervisore, si configura un criterio di storage per le macchine virtuali del piano di controllo del Supervisore. Se la distribuzione supporta Pod vSphere, si assegnano inoltre i criteri di storage e si specificano le posizioni dei datastore per i dischi temporanei e le immagini dei container. Per informazioni sull'impostazione dello storage quando si abilita il Supervisore, vedere la documentazione Installazione e configurazione di vSphere IaaS Control Plane. Per modificare le impostazioni di storage, vedere Modifica delle impostazioni di storage nel supervisore.

Criterio di storage del piano di controllo
Questo criterio garantisce che le macchine virtuali del piano di controllo vengano posizionate nei datastore che i criteri rappresentano.
Dischi virtuali temporanei
Durante le sue operazioni, un Pod vSphere richiede l'archiviazione di oggetti Kubernetes come registri, volumi emptyDir e ConfigMaps in uno storage temporaneo. Questo storage temporaneo, o transitorio, dura fino a quando il pod continua a esistere. I dati temporanei persistono dopo il riavvio del container, ma quando il pod raggiunge la fine del proprio ciclo di vita, il disco virtuale temporaneo scompare.

Ogni pod ha un disco virtuale temporaneo. Un amministratore di vSphere utilizza un criterio di storage per definire la posizione del datastore per tutti i dischi virtuali temporanei durante la configurazione dello storage per il Supervisore.

Dischi virtuali delle immagini dei container
I container all'interno di Pod vSphere utilizzano immagini che contengono il software da eseguire. Il pod monta le immagini utilizzate dai suoi container come dischi virtuali dell'immagine. Quando il pod completa il suo ciclo di vita, i dischi virtuali dell'immagine vengono scollegati dal pod.

Image Service, un componente di ESXi, è responsabile dell'estrazione delle immagini dei container dal registro immagini e della loro trasformazione in dischi virtuali da eseguire all'interno del pod.

Image Service estrae l'immagine di un container dal registro immagini e la trasforma in un disco virtuale dell'immagine da montare tramite il pod vSphere.

ESXi può memorizzare in cache le immagini scaricate per i container in esecuzione nel pod. I pod successivi che utilizzano la stessa immagine la estraggono dalla cache locale anziché dal registro dei container esterno.

Storage persistente per i carichi di lavoro

Alcuni carichi di lavoro Kubernetes eseguiti da DevOps in uno spazio dei nomi richiedono lo storage persistente per archiviare i dati in modo permanente.

Lo storage persistente può essere utilizzato da Pod vSphere, cluster Tanzu Kubernetes Grid, macchine virtuali e altri carichi di lavoro eseguiti nello spazio dei nomi. Per rendere lo storage persistente disponibile per il team DevOps, l'amministratore di vSphere crea criteri di storage che descrivono diversi requisiti di storage e classi di servizi. L'amministratore assegna quindi i criteri di storage e configura i limiti di storage a livello di spazio dei nomi.

Per comprendere come funziona vSphere IaaS control plane con lo storage persistente, è necessario conoscere i concetti essenziali di Kubernetes come le classi di storage, i volumi persistenti e le richieste di volumi persistenti. Per ulteriori informazioni, vedere la documentazione di Kubernetes all'indirizzo https://kubernetes.io/docs/home/.

Per ulteriori informazioni sullo storage persistente per il cluster Tanzu Kubernetes Grid, vedere Storage per i cluster Tanzu Kubernetes Grid.

Per informazioni sull'utilizzo dello storage persistente, vedere Utilizzo dello storage persistente con i carichi di lavoro nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.

Se il team DevOps prevede di distribuire servizi di terze parti che utilizzano vSAN Direct per le esigenze di storage persistente, vedere Abilitazione dei servizi stateful in vSphere with Tanzu nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.

Modalità di integrazione di Supervisore con vSphere Storage

Supervisore utilizza diversi componenti per l'integrazione con lo storage vSphere.

CNS viene visualizzato come componente di vCenter Server e CNS-CSI come componente di Supervisore. Entrambi interagiscono per creare volumi persistenti e FCD di supporto.

Cloud Native Storage (CNS) in vCenter Server
Il componente CNS si trova in vCenter Server. Si tratta di un'estensione della gestione di vCenter Server che implementa le operazioni di provisioning e del ciclo di vita per i volumi persistenti.
Quando si esegue il provisioning dei volumi persistenti, il componente interagisce con la funzionalità First Class Disk di vSphere per creare dischi virtuali che supportano i volumi. Il componente server CNS comunica inoltre con la gestione basata sui criteri di storage per garantire il livello di servizio necessario per i dischi.
CNS esegue anche operazioni di query che consentono agli amministratori di vSphere di gestire e monitorare i volumi persistenti e i relativi oggetti di storage di supporto tramite vCenter Server.
FCD (First Class Disk)
Chiamato anche Improved Virtual Disk. Tali dischi si trovano nei datastore e supportano i volumi persistenti ReadWriteOnce.
Quando si utilizzano gli FCD, tenere presente quanto segue:
  • Gli FCD non supportano i protocolli NFS 4.x. Utilizzare invece NFS 3.
  • vCenter Server non serializza le operazioni nello stesso FCD. Di conseguenza, le applicazioni non possono eseguire contemporaneamente operazioni sullo stesso FCD. L'esecuzione di operazioni come clonazione, riposizionamento, eliminazione e recupero contemporaneamente da thread diversi determina risultati imprevedibili. Per evitare problemi, le applicazioni devono eseguire le operazioni sullo stesso FCD in ordine sequenziale.
  • FCD non è un oggetto gestito e non supporta un blocco globale che protegge più scritture in un singolo FCD. Di conseguenza, l'FCD non supporta più istanze di vCenter Server che gestiscono lo stesso FCD. Se è necessario utilizzare più istanze di vCenter Server con gli FCD, sono disponibili le seguenti opzioni:
    • Più istanze di vCenter Server possono gestire datastore diversi.
    • Più istanze di vCenter Server non funzionano nello stesso FCD.
Gestione basata sul criterio di storage
La gestione basata sui criteri di storage è un servizio di vCenter Server che supporta il provisioning dei volumi persistenti e dei relativi dischi virtuali di supporto in base ai requisiti di storage descritti in un criterio di storage. Dopo il provisioning, il servizio monitora la conformità del volume con le caratteristiche del criterio di storage. Per ulteriori informazioni sulla gestione basata sul criterio di storage, vedere il capitolo Gestione basata sul criterio di storage nella documentazione Storage di vSphere.
vSphere CNS-CSI
Il componente vSphere CNS-CSI è conforme alla specifica Container Storage Interface (CSI), uno standard di settore progettato per fornire un'interfaccia che gli orchestrator di container come Kubernetes utilizzano per il provisioning dello storage persistente. Il driver CNS-CSI viene eseguito nel Supervisore e connette lo storage di vSphere all'ambiente Kubernetes in uno spazio dei nomi. vSphere CNS-CSI comunica direttamente con il componente CNS per tutte le richieste di provisioning dello storage provenienti dallo spazio dei nomi.

Funzionalità supportata da vSphere CNS-CSI

Il componente vSphere CNS-CSI eseguito nel Supervisore supporta più funzionalità di storage di vSphere e Kubernetes. Tuttavia, si applicano alcune limitazioni.

Funzionalità supportata vSphere CNS-CSI con Supervisore
Supporto di CNS in vSphere Client Sì
Integrità degli oggetti avanzata in vSphere Client Sì (solo vSAN)
Blocco dinamico volume persistente (modalità di accesso ReadWriteOnce) Sì
Volume persistente del file dinamico (modalità di accesso ReadWriteMany) No
Datastore vSphere VMFS, NFS, vSAN (incluso vSAN ESA), vVols
Volume persistente statico Sì
Crittografia No
Espansione del volume offline Sì
Espansione del volume online Sì
Topologia di volume e zone Sì. I volumi possono essere utilizzati solo dai cluster Tanzu Kubernetes Grid.
Istanze del piano di controllo multiple Kubernetes Sì
WaitForFirstConsumer No
VolumeHealth Sì
Storage vMotion con volumi persistenti No

Storage persistente e Supervisore con zone vSphere

Un Supervisore a tre zone supporta lo storage zonale, in cui un datastore è condiviso tra tutti gli host di una singola zona.

Tutti gli host di una singola zona condividono un datastore.

Quando si preparano le risorse di storage per il Supervisore a tre zone, tenere presenti le considerazioni seguenti:
  • Non è necessario che lo storage in tutte e tre le zone sia dello stesso tipo. Tuttavia, la presenza dello stesso tipo di storage in tutti e tre i cluster consente di ottenere prestazioni coerenti.
  • Per lo spazio dei nomi nel Supervisore a tre zone, utilizzare un criterio di storage conforme allo storage condiviso in ciascun cluster. Il criterio di storage deve essere sensibile alla topologia.
  • Non rimuovere i vincoli della topologia dal criterio di storage dopo averlo assegnato allo spazio dei nomi.
  • Non montare i datastore zonali in altre zone.
  • Un Supervisore a tre zone non supporta gli elementi seguenti:
    • Volumi tra zone
    • Volumi di file vSAN (volumi ReadWriteMany)
    • Provisioning del volume statico mediante l'API di registrazione del volume
    • Carichi di lavoro che utilizzano la piattaforma Persistenza dati vSAN
    • Pod vSphere
    • Cluster estesi vSAN
    • Macchine virtuali con vGPU e storage di istanze

Per ulteriori informazioni, vedere Utilizzo dello storage persistente in un supervisore a tre zone nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.