I driver backend ONTAP si differenziano in base al protocollo utilizzato e al modo in cui i volumi vengono forniti sul sistema di archiviazione. Pertanto, è opportuno valutare attentamente la scelta del driver da implementare.

A un livello superiore, se l'applicazione ha componenti che necessitano di storage condiviso (più pod che accedono allo stesso PVC), i driver basati su NAS sarebbero la scelta predefinita, mentre i driver iSCSI basati su blocchi soddisfano le esigenze di storage non condiviso. Scegliere il protocollo in base ai requisiti dell'applicazione e al livello di comfort dei team di storage e infrastruttura. In generale, per la maggior parte delle applicazioni c'è poca differenza tra loro, quindi spesso la decisione si basa sulla necessità o meno di uno storage condiviso (in cui più di un pod necessita di accesso simultaneo).

I driver backend ONTAP disponibili sono:

La scelta tra i tre driver NAS ha alcune implicazioni sulle funzionalità rese disponibili all'applicazione.

Si noti che nelle tabelle seguenti non tutte le funzionalità sono esposte tramite Trident. Alcune devono essere applicate dall'amministratore dell'archiviazione dopo il provisioning, se si desidera tale funzionalità. Le note a piè di pagina in apice distinguono la funzionalità per caratteristica e driver.

Trident offre 2 driver SAN per ONTAP, le cui capacità sono illustrate di seguito.

Le funzionalità che non sono granulari PV vengono applicate all'intero FlexVolume e tutti i PV (ovvero qtree o LUN nei FlexVol condivisi) condivideranno una pianificazione comune.

Come possiamo vedere nelle tabelle sopra, gran parte della funzionalità tra ontap-nas E ontap-nas-economy è lo stesso. Tuttavia, poiché il ontap-nas-economy il driver limita la possibilità di controllare la pianificazione con granularità per PV, il che può influire in particolare sulla pianificazione del disaster recovery e del backup. Per i team di sviluppo che desiderano sfruttare la funzionalità di clonazione PVC sullo storage ONTAP , ciò è possibile solo utilizzando ontap-nas , ontap-san O ontap-san-economy conducenti.

Cloud Volumes ONTAP fornisce il controllo dei dati insieme a funzionalità di archiviazione di livello aziendale per vari casi d'uso, tra cui condivisioni di file e archiviazione a livello di blocco che servono protocolli NAS e SAN (NFS, SMB/CIFS e iSCSI). I driver compatibili per Cloud Volume ONTAP sono ontap-nas , ontap-nas-economy , ontap-san E ontap-san-economy . Sono applicabili a Cloud Volume ONTAP per Azure, Cloud Volume ONTAP per GCP.

Amazon FSx for NetApp ONTAP ti consente di sfruttare le funzionalità, le prestazioni e le capacità amministrative NetApp che conosci, sfruttando al contempo la semplicità, l'agilità, la sicurezza e la scalabilità dell'archiviazione dei dati su AWS. FSx per ONTAP supporta numerose funzionalità del file system ONTAP e API di amministrazione. I driver compatibili per Cloud Volume ONTAP sono ontap-nas , ontap-nas-economy , ontap-nas-flexgroup , ontap-san E ontap-san-economy .

IL solidfire-san driver utilizzato con le piattaforme NetApp HCI/ SolidFire , aiuta l'amministratore a configurare un backend Element per Trident in base ai limiti QoS. Se desideri progettare il tuo backend per impostare i limiti QoS specifici sui volumi forniti da Trident, usa type parametro nel file backend. L'amministratore può anche limitare la dimensione del volume che può essere creato sullo storage utilizzando limitVolumeSize parametro. Attualmente, le funzionalità di archiviazione Element come il ridimensionamento del volume e la replica del volume non sono supportate tramite solidfire-san autista. Queste operazioni devono essere eseguite manualmente tramite l'interfaccia utente web di Element Software.

Trident utilizza il azure-netapp-files autista per gestire il"Azure NetApp Files" servizio.

Ulteriori informazioni su questo driver e su come configurarlo possono essere trovate in"Configurazione del backend Trident per Azure NetApp Files" .

Trident utilizza il gcp-cvs driver per il collegamento al Cloud Volumes Service su Google Cloud.

IL gcp-cvs Il driver utilizza pool virtuali per astrarre il backend e consentire a Trident di determinare il posizionamento del volume. L'amministratore definisce i pool virtuali nel backend.json file. Le classi di archiviazione utilizzano selettori per identificare i pool virtuali in base all'etichetta.

Per configurare il backend di Google Cloud su Trident, è necessario specificare projectNumber , apiRegion , E apiKey nel file backend. Puoi trovare il numero del progetto nella console di Google Cloud. La chiave API viene ricavata dal file della chiave privata dell'account di servizio creato durante la configurazione dell'accesso API per Cloud Volumes Service su Google Cloud.

Per i dettagli sul Cloud Volumes Service sui tipi di servizio e sui livelli di servizio di Google Cloud, fare riferimento a"Scopri di più sul supporto Trident per CVS per GCP" .

È possibile utilizzare il filtraggio all'interno di un oggetto di classe di archiviazione specifico per determinare quale pool di archiviazione o set di pool utilizzare con quella specifica classe di archiviazione. Nella classe di archiviazione è possibile impostare tre set di filtri: storagePools , additionalStoragePools , e/o excludeStoragePools .

IL storagePools Il parametro consente di limitare l'archiviazione al set di pool che corrispondono a uno qualsiasi degli attributi specificati. IL additionalStoragePools Il parametro viene utilizzato per estendere il set di pool che Trident utilizza per il provisioning insieme al set di pool selezionati dagli attributi e storagePools parametri. È possibile utilizzare uno dei due parametri da solo o entrambi insieme per assicurarsi che venga selezionato il set appropriato di pool di archiviazione.

IL excludeStoragePools Il parametro viene utilizzato per escludere specificamente l'insieme elencato di pool che corrispondono agli attributi.

Se si desidera progettare classi di archiviazione per emulare le policy di qualità del servizio, creare una classe di archiviazione con media attributo come hdd O ssd . Sulla base del media attributo menzionato nella classe di archiviazione, Trident selezionerà il backend appropriato che serve hdd O ssd aggregati per abbinare l'attributo multimediale e quindi indirizzare il provisioning dei volumi all'aggregato specifico. Pertanto possiamo creare una classe di archiviazione PREMIUM che avrebbe media attributo impostato come ssd che potrebbe essere classificata come politica QoS PREMIUM. Possiamo creare un'altra classe di archiviazione STANDARD che avrebbe l'attributo multimediale impostato su `hdd' e potrebbe essere classificata come policy QoS STANDARD. Potremmo anche utilizzare l'attributo ``IOPS'' nella classe di archiviazione per reindirizzare il provisioning a un'appliance Element che può essere definita come una politica QoS.

Le classi di archiviazione possono essere progettate per indirizzare il provisioning dei volumi su un backend specifico in cui sono abilitate funzionalità quali provisioning sottile e spesso, snapshot, cloni e crittografia. Per specificare quale storage utilizzare, creare classi di storage che specifichino il backend appropriato con la funzionalità richiesta abilitata.

I pool virtuali sono disponibili per tutti i backend Trident . È possibile definire pool virtuali per qualsiasi backend, utilizzando qualsiasi driver fornito da Trident .

I pool virtuali consentono a un amministratore di creare un livello di astrazione sui backend a cui è possibile fare riferimento tramite classi di archiviazione, per una maggiore flessibilità e un posizionamento efficiente dei volumi sui backend. È possibile definire backend diversi con la stessa classe di servizio. Inoltre, è possibile creare più pool di archiviazione sullo stesso backend, ma con caratteristiche diverse. Quando una classe di archiviazione viene configurata con un selettore con etichette specifiche, Trident sceglie un backend che corrisponda a tutte le etichette del selettore per posizionare il volume. Se le etichette del selettore della classe di archiviazione corrispondono a più pool di archiviazione, Trident ne sceglierà uno da cui eseguire il provisioning del volume.

È possibile progettare pool virtuali per emulare classi di servizi. Utilizzando l'implementazione del pool virtuale per Cloud Volume Service per Azure NetApp Files, esaminiamo come possiamo configurare diverse classi di servizi. Configurare il backend di Azure NetApp Files con più etichette, che rappresentano diversi livelli di prestazioni. Impostato servicelevel aspetto al livello di prestazione appropriato e aggiungere altri aspetti richiesti sotto ciascuna etichetta. Ora crea diverse classi di archiviazione Kubernetes che verranno mappate su diversi pool virtuali. Utilizzando il parameters.selector campo, ogni StorageClass richiama quali pool virtuali possono essere utilizzati per ospitare un volume.

È possibile progettare più pool virtuali con un set specifico di aspetti da un singolo backend di archiviazione. Per fare ciò, configura il backend con più etichette e imposta gli aspetti richiesti sotto ciascuna etichetta. Ora crea diverse classi di archiviazione Kubernetes utilizzando parameters.selector campo che verrebbe mappato su diversi pool virtuali. I volumi che vengono forniti sul backend avranno gli aspetti definiti nel pool virtuale scelto.

Alcuni parametri che vanno oltre la classe di archiviazione richiesta potrebbero influire sul processo decisionale di provisioning Trident durante la creazione di un PVC.

Quando si richiede l'archiviazione tramite PVC, uno dei campi obbligatori è la modalità di accesso. La modalità desiderata può influenzare il backend selezionato per ospitare la richiesta di archiviazione.

Trident tenterà di abbinare il protocollo di archiviazione utilizzato al metodo di accesso specificato in base alla seguente matrice. Ciò è indipendente dalla piattaforma di archiviazione sottostante.

Una richiesta per un PVC ReadWriteMany inviata a una distribuzione Trident senza un backend NFS configurato non comporterà il provisioning di alcun volume. Per questo motivo, il richiedente deve utilizzare la modalità di accesso più adatta alla propria applicazione.

I volumi persistenti sono, con due eccezioni, oggetti immutabili in Kubernetes. Una volta creata, la politica di recupero e le dimensioni possono essere modificate. Tuttavia, ciò non impedisce che alcuni aspetti del volume vengano modificati al di fuori di Kubernetes. Ciò potrebbe essere utile per personalizzare il volume per applicazioni specifiche, per garantire che la capacità non venga consumata accidentalmente o semplicemente per spostare il volume su un controller di archiviazione diverso per qualsiasi motivo.

I dettagli di connessione del PV non possono essere modificati dopo la creazione.

Trident supporta la creazione di snapshot di volumi su richiesta e la creazione di PVC da snapshot utilizzando il framework CSI. Gli snapshot rappresentano un metodo pratico per conservare copie puntuali dei dati e hanno un ciclo di vita indipendente dal PV di origine in Kubernetes. Queste istantanee possono essere utilizzate per clonare i PVC.

Trident supporta anche la creazione di PersistentVolume da snapshot di volume. Per fare ciò, basta creare un PersistentVolumeClaim e menzionare il datasource come snapshot richiesto da cui creare il volume. Trident gestirà questo PVC creando un volume con i dati presenti nello snapshot. Grazie a questa funzionalità è possibile duplicare i dati tra regioni diverse, creare ambienti di test, sostituire completamente un volume di produzione danneggiato o corrotto oppure recuperare file e directory specifici e trasferirli su un altro volume collegato.

Gli amministratori di storage hanno la possibilità di spostare volumi tra aggregati e controller nel cluster ONTAP senza interrompere l'attività del consumatore di storage. Questa operazione non ha alcun effetto Trident o sul cluster Kubernetes, a condizione che l'aggregato di destinazione sia uno a cui ha accesso l'SVM utilizzato da Trident . È importante sottolineare che se l'aggregato è stato appena aggiunto all'SVM, il backend dovrà essere aggiornato aggiungendolo nuovamente a Trident. Ciò indurrà Trident a rielaborare l'inventario dell'SVM in modo che il nuovo aggregato venga riconosciuto.

Tuttavia, lo spostamento di volumi tra backend non è supportato automaticamente da Trident. Ciò include tra SVM nello stesso cluster, tra cluster o su una piattaforma di archiviazione diversa (anche se tale sistema di archiviazione è connesso a Trident).

Se un volume viene copiato in un'altra posizione, è possibile utilizzare la funzionalità di importazione del volume per importare i volumi correnti in Trident.

Trident supporta il ridimensionamento di PV NFS, iSCSI e FC. Ciò consente agli utenti di ridimensionare i propri volumi direttamente tramite il livello Kubernetes. L'espansione del volume è possibile per tutte le principali piattaforme di storage NetApp , inclusi i backend ONTAP, SolidFire/ NetApp HCI e Cloud Volumes Service . Per consentire una possibile espansione successiva, impostare allowVolumeExpansion A true nella StorageClass associata al volume. Ogni volta che è necessario ridimensionare il volume persistente, modificare il spec.resources.requests.storage annotazione nella Persistent Volume Claim alla dimensione del volume richiesta. Trident si occuperà automaticamente di ridimensionare il volume sul cluster di archiviazione.

L'importazione di volumi consente di importare un volume di archiviazione esistente in un ambiente Kubernetes. Questo è attualmente supportato da ontap-nas , ontap-nas-flexgroup , solidfire-san , azure-netapp-files , E gcp-cvs conducenti. Questa funzionalità è utile quando si trasferisce un'applicazione esistente in Kubernetes o durante scenari di disaster recovery.

Quando si utilizza ONTAP e solidfire-san driver, utilizzare il comando tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml per importare un volume esistente in Kubernetes da gestire tramite Trident. Il file PVC YAML o JSON utilizzato nel comando di importazione del volume punta a una classe di archiviazione che identifica Trident come provisioner. Quando si utilizza un backend NetApp HCI/ SolidFire , assicurarsi che i nomi dei volumi siano univoci. Se i nomi dei volumi sono duplicati, clonare il volume con un nome univoco in modo che la funzionalità di importazione dei volumi possa distinguerli.

Se il azure-netapp-files O gcp-cvs viene utilizzato il driver, utilizzare il comando tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml per importare il volume in Kubernetes affinché venga gestito da Trident. Ciò garantisce un riferimento volumetrico univoco.

Quando viene eseguito il comando sopra, Trident troverà il volume sul backend e ne leggerà le dimensioni. Aggiungerà automaticamente (e sovrascriverà se necessario) la dimensione del volume del PVC configurato. Trident crea quindi il nuovo PV e Kubernetes lega il PVC al PV.

Se un contenitore è stato distribuito in modo tale da richiedere lo specifico PVC importato, rimarrà in uno stato di attesa finché la coppia PVC/PV non verrà associata tramite il processo di importazione del volume. Una volta legata la coppia PVC/PV, il contenitore dovrebbe sollevarsi, a meno che non ci siano altri problemi.

L'implementazione e la gestione dell'archiviazione per il registro sono state documentate su"netapp.io" nel"blog" .

Come altri servizi OpenShift, il servizio di registrazione viene distribuito tramite Ansible con parametri di configurazione forniti dal file di inventario, noto anche come host, fornito al playbook. Verranno trattati due metodi di installazione: l'implementazione della registrazione durante l'installazione iniziale di OpenShift e l'implementazione della registrazione dopo l'installazione di OpenShift.

Se si sceglie di utilizzare NFS con il servizio di registrazione, sarà necessario impostare la variabile Ansible openshift_enable_unsupported_configurations A true per evitare che il programma di installazione fallisca.

Dopo aver definito le variabili Ansible appropriate nel file hosts/inventory, distribuisci il servizio utilizzando Ansible. Se si esegue la distribuzione al momento dell'installazione di OpenShift, il PV verrà creato e utilizzato automaticamente. Se si esegue la distribuzione utilizzando i playbook dei componenti, dopo l'installazione di OpenShift, Ansible crea tutti i PVC necessari e, dopo che Trident ha predisposto lo storage per essi, distribuisce il servizio.

Le variabili sopra indicate e il processo di distribuzione potrebbero cambiare con ogni versione di OpenShift. Assicurati di rivedere e seguire"Guida alla distribuzione di OpenShift di Red Hat" per la tua versione in modo che sia configurata per il tuo ambiente.