Conoscere OpenShift Data Foundation
Virtual Private Cloud Infrastruttura classica Satellite
OpenShift Data Foundation è una soluzione di archiviazione altamente disponibile che puoi utilizzare per gestire l'archiviazione persistente per le tue applicazioni inserite nel contenitore.
- Cos' è OpenShift Data Foundation?
- OpenShift Data Foundation è una soluzione di archiviazione ad alta disponibilità composta da diversi operatori e tecnologie open source come Cef, NooBaa, E Rook. Questi operatori ti consentono di effettuare il provisioning e gestire lo storage di file, blocchi e oggetti per i tuoi carichi di lavoro containerizzati Red Hat® OpenShift® on IBM Cloud® grappoli. A differenza di altre soluzioni di storage in cui potrebbe essere necessario configurare driver e operatori separati per ogni tipo di storage, ODF è una soluzione unificata in grado di adattarsi o scalare alle proprie esigenze di storage. È anche possibile distribuire ODF su qualsiasi cluster OCP.
- Come funziona OpenShift Data Foundation?
- ODF utilizza questi dispositivi per creare un livello di archiviazione virtualizzato, in cui i dati dell'applicazione vengono replicati per l'alta disponibilità. Poiché ODF astrae l'archivio sottostante, è possibile utilizzare ODF per creare richieste di archiviazione file, blocchi o oggetti dallo stesso archivio blocchi non elaborato sottostante.
- ODF utilizza volumi di memoria in multipli di 3 e replica i tuoi dati dell'applicazione su questi volumi. I volumi di archiviazione sottostanti utilizzati per ODF dipendono dal tipo di cluster.
- Per i cluster VPC che utilizzano macchine virtuali, i volumi di archiviazione sono volumi di archiviazione Block Storage for VPC.
- Per i cluster Classic o VPC che utilizzano worker bare metal, i volumi di archiviazione sono dischi locali sui nodi worker bare metal.
- Per Satellite cluster, i volumi di archiviazione sono dischi locali sui nodi worker, oppure si possono fornire dinamicamente i dischi usando un driver di archiviazione a blocchi compatibile.
- Posso installare un OpenShift Data Foundation su cluster VPC solo privati?
- Sì, è possibile installare ODF su cluster VPC solo privati a partire dalla versione cluster
4.16.23_1546_openshiftper i lavoratori CoreOS e4.16.21_1544_openshiftper i lavoratori RHEL. - Posso installare il componente aggiuntivo OpenShift Data Foundation nei cluster Satellite ?
- Num. Il componente aggiuntivo del cluster è disponibile solo per i cluster Classic e VPC.
- Come installare OpenShift Data Foundation su Satellite?
- Puoi installare ODF su Satellite utilizzando uno dei template di archiviazione Satellite. Per ulteriori informazioni, vedi la documentazione di archiviazione diSatellite.
odf-local: scegli questo template quando hai l'archiviazione locale disponibile per i tuoi nodi di lavoro. Se i volumi di storage sono visibili quando si eseguelsblk, è possibile utilizzare questi dischi quando si distribuisce ODF se non sono formattati e non sono formattati.odf-remote: scegliere questo modello se si dispone di un driver CSI installato nel cluster. Ad esempio, il driverazuredisk-csi-driver. È possibile utilizzare il driver CSI per eseguire dinamicamente il provisioning dei volumi di archiviazione durante la distribuzione di ODF.
Per una panoramica completa delle funzioni e dei vantaggi, vedi OpenShift Data Foundation.
Panoramica sull'architettura
Esamina il seguente diagramma e la seguente tabella per ulteriori informazioni su OpenShift Data Foundation.
| Numero | Componente ODF | Descrizione |
|---|---|---|
| 1 | Classi di archiviazione OpenShift Data Foundation | Quando si distribuisce ODF, l'operatore ODF crea classi di archiviazione file, blocchi e oggetti nel cluster. Fai riferimento a queste classi di archiviazione nelle tue PVC e per richiedere lo storage per le tue app. |
| 2 | Block Storage OSD | Questi dispositivi forniscono la memoria dell'applicazione nel cluster. Ogni OSD è un dispositivo di archiviazione blocchi non elaborato che può essere un disco locale sul tuo nodo di lavoro o di cui viene eseguito dinamicamente il provisioning
quando distribuisci ODF. Nei cluster VPC, il provisioning dei tuoi dispositivi di archiviazione blocchi OSD viene eseguito in modo dinamico utilizzando il driver Block Storage for VPC. Nei cluster Satellite, puoi utilizzare i volumi
locali sui tuoi nodi di lavoro o eseguire in modo dinamico il provisioning dei dispositivi di archiviazione blocchi utilizzando un driver di archiviazione blocchi che supporta il provisioning dinamico. Nei cluster classici, i dispositivi
di blocco OSD sono dischi locali sui tuoi nodi di lavoro. Quando si distribuisce ODF, ogni periferica viene montata da un pod OSD. L'archiviazione totale disponibile per le tue applicazioni è uguale a osdSize moltiplicato
per numOfOsd. |
| 3 | Pod OSD ( Object Storage Daemon) | I pod OSD gestiscono il posizionamento dei dati e la replica tra i tuoi dispositivi di archiviazione. |
| 4 | Pod di monitoraggio (Mon) | I pod di monitoraggio conservano un'associazione del tuo cluster di archiviazione OpenShift Data Foundation e monitorano l'integrità del cluster di archiviazione. |
| 5 | Periferica di archiviazione blocchi (Mon) di monitoraggio | Le unità di memoria di monitoraggio sono le unità di memoria sottostanti per i pod di monitoraggio. Ogni dispositivo di monitoraggio è un dispositivo di archiviazione blocchi non elaborato che può essere un disco locale sul tuo nodo di lavoro o di cui viene eseguito il provisioning in modo dinamico quando distribuisci ODF. Ogni periferica fornisce l'archiviazione a un pod di monitoraggio. |
Panoramica di Multicloud Object Gateway
Il Multicloud Object Gateway è costituito dallo strumento open source NooBaa ed è un componente di OpenShift Data Foundation. Con Multicloud Object Gateway, puoi gestire oggetti e bucket tra i provider cloud.
![Panoramica del gateway per oggetti Multicloud* ")
| Numero | Componente Multicloud Object Gateway | Descrizione |
|---|---|---|
| 1 | Archivio di backup | Gli archivi di backup sono bucket di archiviazione oggetti compatibili s3. In Multicloud Object Gateway, i tuoi archivi di backup possono essere in qualsiasi ambiente cloud, indipendentemente dal provider. È possibile collegare diversi archivi di backup a Multicloud Object Gateway. Quando si distribuisce ODF, l'archivio di backup predefinito utilizza i dispositivi di archiviazione blocchi non elaborati specificati per il cluster di memoria ODF. Tuttavia, puoi facoltativamente configurare IBM Cloud Object Storage come tuo archivio di backup predefinito. |
| 2 | Classe bucket | Una classe bucket è composta da uno o più archivi di backup (bucket) e da una politica di posizionamento. È possibile configurare gli archivi di backup e le politiche di posizionamento per gestire gli oggetti tra ubicazioni e cloud. |
| 3 | Classe di archiviazione | Una classe di memoria in Multicloud Object Gateway è simile a qualsiasi altra classe di memoria Kubernetes in quanto definisce i parametri delle risorse di memoria. Tuttavia, in Multicloud Object Gateway, quando si crea una classe di storage, si specifica la classe bucket da utilizzare. Creando una classe di archiviazione dalla tua classe bucket, puoi rendere disponibili le tue risorse Multicloud Object Gateway tra gli spazi nomi. |
| 4 | Richiesta bucket oggetto (OBC) | Un'attestazione del bucket di oggetti (OBC) è simile a un'attestazione del volume persistente (o PVC, persistent volume claim) Kubernetes in cui gli sviluppatori o gli amministratori di archiviazione possono creare degli OBC per richiedere le risorse di archiviazione. Quando crei un OBC, specifichi la classe di archiviazione che vuoi utilizzare e facoltativamente fornisci un nome per il bucket di oggetti creato dinamicamente. |
| 5 | Secret | Quando crei un'attestazione bucket oggetto, nel tuo cluster viene creato anche un segreto Kubernetes. |
| 6 | ConfigMap | Quando crei un'attestazione bucket di oggetti, nel tuo cluster viene creata anche una ConfigMap. |
| 7 | Bucket oggetto | Un bucket di oggetti è un provisioning dinamico quando crei una richiesta di bucket di oggetti. Il bucket di oggetti astrae uno o più archivi di backup in una singola risorsa. |
| 8 | App s3 | Un'applicazione che utilizza l'archiviazione oggetti. |
| 9 | Riferimento segreto | Un riferimento segreto è un riferimento a un segreto Kubernetes nel cluster. Quando crei una richiesta bucket di oggetti, NooBaa crea una mappa di configurazione e un segreto corrispondente. Puoi quindi fare riferimento alla mappa di configurazione e al segreto nelle tue applicazioni senza dover includere direttamente le credenziali nelle tue applicazioni. |
| 10 | Riferimento ConfigMap | Un riferimento della mappa di configurazione è un riferimento a una mappa di configurazione Kubernetes nel cluster. Quando crei una richiesta bucket di oggetti, NooBaa crea dinamicamente una mappa di configurazione e un segreto corrispondente. Puoi fare riferimento alla mappa di configurazione e segreto nelle tue applicazioni senza dover includere tali credenziali nelle tue applicazioni. |
| 11 | Risorsa spazio dei nomi | Una risorsa spazio dei nomi è un bucket compatibile con s3. Dopo aver aggiunto le risorse dello spazio dei nomi (bucket) a Multicloud Object Gateway, puoi fare riferimento a questi bucket creando un bucket dello spazio dei nomi che può essere utilizzato per leggere e scrivere da una o più risorse dello spazio dei nomi. |
| 12 | Bucket spazio dei nomi | Un bucket dello spazio dei nomi astrae una o più risorse dello spazio dei nomi nello spazio dei nomi NooBaa. Quando si crea un bucket dello spazio dei nomi, è possibile specificare politiche di lettura o scrittura per le risorse dello spazio dei nomi che sono state configurate in Multicloud Object Gateway. Ad esempio, è possibile leggere da due bucket su provider cloud differenti e scrivere in un terzo bucket in un altro ambiente cloud separato. |
| 13 | Chiave di accesso bucket spazio dei nomi | La chiave di accesso viene utilizzata per accedere al bucket dello spazio dei nomi. I bucket dello spazio dei nomi possono includere più risorse dello spazio dei nomi da provider cloud differenti o bucket in loco. La chiave di accesso al bucket dello spazio dei nomi e la chiave segreta vengono utilizzate nelle tue applicazioni s3 per configurare l'accesso al tuo bucket dello spazio dei nomi che definisce quindi le politiche di lettura e scrittura per le risorse dello spazio dei nomi che configuri. |
| 14 | Chiave segreta bucket spazio dei nomi | La chiave segreta viene utilizzata per accedere al bucket dello spazio dei nomi. I bucket dello spazio dei nomi possono includere più risorse dello spazio dei nomi da provider cloud differenti o bucket in loco. La chiave di accesso al bucket dello spazio dei nomi e la chiave segreta vengono utilizzate nelle tue applicazioni s3 per configurare l'accesso al tuo bucket dello spazio dei nomi che definisce quindi le politiche di lettura e scrittura per le risorse dello spazio dei nomi che configuri. |
| 15 | Politica di posizionamento | Quando crei una classe bucket, devi specificare una politica di posizionamento. Le politiche di posizionamento definiscono il modo in cui i tuoi dati vengono scritti nei tuoi archivi di backup. Una politica di posizionamento Mirror esegue il mirroring degli oggetti tra gli archivi di backup nella tua classe bucket e una politica di posizionamento Spread distribuisce gli oggetti tra gli archivi di backup nella tua classe bucket. |
Supporto funzione per tipo di fatturazione
| Supporto funzione | Essentials | Avanzate |
|---|---|---|
| Storage a blocchi | Sì | Sì |
| Storage file | Sì | Sì |
| Archiviazione oggetti | Sì | Sì |
| Node e resilienza del disco | Sì | Sì |
| Automazione basata sull'operatore | Sì | Sì |
| Compressione | Sì | Sì |
| Istantanee e clonazione locali | Sì | Sì |
| Codifica a livello di cluster di base | Sì | Sì |
| Crittografia avanzata con KMS | No | Sì |
| Disaster recovery regionale con replica | No | Sì |
| Cluster estesi - alta disponibilità Metro e ripristino di emergenza | No | Sì |
| Multi - cluster - alta disponibilità Metro e disaster recovery | No | Sì |
Procedure consigliate
Consultare le seguenti sezioni per le procedure ottimali durante l'installazione e la gestione di ODF.
Pianificazione
- Pianificare la distribuzione dei nodi worker
- Per garantire l'elevata disponibilità, distribuire il cluster ODF tra i domini di errore. Questa distribuzione consente di ridurre al minimo l'impatto degli errori dei nodi e di mantenere la stabilità generale del cluster.
- Soddisfa le specifiche minime del nodo di lavoro
- I nodi di lavoro che utilizzano ODF devono avere 16 vCPUs e 64GB di RAM o superiore. Per i cluster IBM Classic, il profilo consigliato è
mb4c.32x384.3.8tb.ssdo superiore. - Conserva un host standby per l'alta disponibilità
- Per garantire l'alta disponibilità e ridurre al minimo i tempi di inattività in caso di guasto di un host, è consigliabile mantenere sempre un host di riserva.
- Soddisfa i suggerimenti per il numero di dispositivi di memorizzazione per nodo
- Pianificare meno di nove periferiche di archiviazione per nodo. Ciò consente di prevenire potenziali colli di bottiglia e migliora l'efficienza di accesso e recupero dei dati.
- Utilizzare le dimensioni e i conteggi dei dispositivi di archiviazione consigliati
- Quando si distribuisce l'archiviazione locale, utilizzare dimensioni disco di 4 TiB o inferiori. È importante garantire che tutti i dischi all'interno del cluster, su tutti i nodi di memoria, siano della stessa dimensione e dello stesso tipo per un uso ottimale della memoria. Utilizzare OSD di almeno 512Gi.
- Scalabilità verso l'alto utilizzando il fattore di replica predefinito e la configurazione del nodo di archiviazione
- In OpenShift Data Foundation (ODF), il fattore di replica è impostato su 3 per impostazione predefinita. Quando si aggiunge capacità, pianificare l'aggiunta di nodi di memoria in multipli di 3.
- Scegli la giusta configurazione per le tue esigenze: archiviazione remota vs archiviazione locale
- Se hai esigenze di archiviazione inferiori o stai utilizzando le istanze del Virtual Server, l'archiviazione remota può essere un'opzione conveniente ed economica. Tuttavia, se i requisiti di storage sono elevati, sarebbe più adatto un cluster bare metal o uno storage ad alte prestazioni con bassa latenza di rete, che utilizza lo storage locale.
- Semplificare la distribuzione utilizzando la funzione di rilevamento automatico
- Nei {: tag-classic-inf} [classici*] o negli ambienti con storage locale, sfruttate la funzione di rilevamento automatico per identificare e configurare automaticamente i dischi di storage disponibili nel cluster per ODF. Questa opzione elimina la necessità di selezionare manualmente il disco. A meno che non vi siano requisiti di disco specifici per il provisioning ODF, l'utilizzo della funzione di rilevamento automatico semplifica il processo di distribuzione e riduce il potenziale di errori di configurazione.
- Utilizzare le classi di memoria metro per le installazioni ODF sulla memoria remota
- Quando si esegue un'installazione ODF che utilizza l'archiviazione remota, assicurarsi di utilizzare una classe di archiviazione che ha un
VolumeBindingModediWaitForFirstConsumerche ritarda la creazione dell' Block Storage fino a quando il primo pod che utilizza questa archiviazione è pronto per essere pianificato. - Dimensiona la distribuzione
- Per un'analisi dettagliata dei requisiti di memoria, lo Strumento di dimensionamento per determinare la capacità di memoria necessaria. È anche possibile utilizzare lo strumento di dimensionamento ufficiale Red Hat
- Configurazione di backup periodici
- L'esecuzione di backup periodici per il cluster ODF è essenziale per garantire la protezione dei dati e facilitarne il recupero in caso di disastro. Senza backup regolari, il recupero dei dati da un evento catastrofico diventa significativamente più impegnativo e può portare a una perdita permanente di dati.
Distribuzione
- Pianificare l'utilizzo di nodi di memoria dedicati
- In scenari con carichi di lavoro elevati, utilizzare nodi di memoria dedicati per ODF. Separando le operazioni dei nodi di storage, è possibile ottenere prestazioni e scalabilità migliori per l'infrastruttura di storage.
- Impostare il controllo regolare della console Red Hat
- La console Red Hat fornisce informazioni preziose sulla salute e sulle prestazioni dell'ambiente ODF. Si consiglia di monitorare regolarmente la console per essere informati su eventuali problemi potenziali. La console attiva gli avvisi in caso di problemi rilevati con ODF, consentendo di adottare misure proattive.
- Indirizzare tempestivamente gli avvisi di capacità
- Quando vengono emessi avvisi di capacità, è importante affrontarli tempestivamente. Ignorare o ritardare l'azione su queste avvertenze può portare a vincoli di capacità di archiviazione e potenziali interruzioni dei carichi di lavoro. Considera gli avvisi di capacità come un'opportunità per valutare le tue esigenze di archiviazione e adottare misure appropriate per mitigare eventuali potenziali problemi.
Espansione della capacità
- Comprendere le opzioni per l'espansione della capacità
- Esistono due opzioni disponibili per l'espansione della capacità in ODF. La prima opzione prevede l'incremento della capacità aggiungendo più OSD (daemonObject Storage ) sui nodi esistenti all'interno del cluster. Ciò consente di utilizzare le risorse disponibili per aumentare la capacità di memorizzazione. La seconda opzione è di espandere la capacità aggiungendo nuovi nodi al cluster. Una volta aumentato il numero di OSD, ne verrà automaticamente eseguito il provisioning sui nodi appena aggiunti.
Aggiorna
- Eseguire i controlli di integrità sostituendo i nodi
- Evitare di sostituire un nodo di memoria se ODF non è in uno stato integro. Prima di procedere con la sostituzione del nodo, verificare sempre lo stato di integrità di ODF. Provare a risolvere eventuali problemi prima di sostituire il nodo non integro.
- Mantieni aggiornato l'ambiente
- Mantenere la versione del cluster aggiornata alla versione predefinita o più recente disponibile. Rimanere aggiornati con la versione del cluster garantisce che puoi sfruttare le funzionalità più recenti e mantenere la compatibilità con altri componenti nel tuo ambiente.
- Esegui aggiornamenti ODF dopo gli aggiornamenti del cluster
- Aggiornare sempre prima il master cluster e il nodo di lavoro, quindi eseguire l'aggiornamento ODF. Dopo aver completato un aggiornamento del cluster, è essenziale aggiornare anche ODF. Sebbene ODF supporti sia la versione cluster corrente (n) che la versione cluster successiva (n+1), mantenere la versione ODF uguale alla versione cluster. Questo allineamento garantisce una compatibilità ottimale.
- Aggiorna nodi di memoria in modo sequenziale
- Quando si aggiornano i nodi di memoria, si consiglia di eseguire gli aggiornamenti uno per uno. Questo approccio sequenziale consente di verificare lo stato di ODF dopo ogni aggiornamento del nodo e garantisce che l'infrastruttura di memoria rimanga in buono stato per tutto il processo. Aggiornando i nodi singolarmente, è possibile monitorare attentamente l'impatto di ciascun aggiornamento su ODF e identificare e risolvere rapidamente eventuali problemi che potrebbero verificarsi.
Ripristino
- Sostituisci host non integri
- In caso di disastro locale, si consiglia di sostituire un host cluster non sano con uno sano.
- Seguire la documentazione per ripristinare gli OSD
- Quando un daemon OSD (Object Storage ) viene disattivo in OpenShift Data Foundation (ODF), è importante seguire la procedura consigliata per il ripristino. La documentazione fornita da IBM Cloud Platform fornisce istruzioni dettagliate su come ripristinare un OSD in queste situazioni.
Disinstallazione e rimozione
- Eliminazione di pod e volumi persistenti (PV)
- Quando si eliminano risorse che utilizzano classi di archiviazione ODF, è importante seguire la procedura consigliata. Eliminare sempre i pod e i PV associati creati utilizzando le classi di archiviazione OF prima di continuare con l'eliminazione di altre risorse.
- Seguire l'ordine di ripulitura corretto
- Quando si disattiva o si rimuove l'ODF dal cluster, accertarsi di seguire la documentazione durante la ripulitura delle risorse. Iniziare eliminando la risorsa
ocscluster, che è responsabile della gestione dell'ODF. Una volta rimossa la risorsaocscluster, procedere con la rimozione del componente aggiuntivo ODF dalla console IBM. Seguendo questa sequenza si garantisce una rimozione regolare e corretta di ODF dal cluster, evitando potenziali problemi o conflitti.
Risoluzione dei problemi
- Esaminare gli avvisi di capacità e le soglie
- ODF genera avvisi di capacità quando la capacità di memoria cluster raggiunge determinate soglie. Tali soglie sono fissate al 75% (quasi pieno) e all ' 85% (pieno) della capacità totale. Questi avvisi indicano che la capacità di memoria sta raggiungendo i suoi limiti e richiede attenzione.
- Esaminare le questioni comuni
- Quando riscontri problemi con OpenShift Data Foundation (ODF), è utile fare riferimento ai runbook disponibili che forniscono istruzioni per la risoluzione dei problemi comuni. I runbook contengono un elenco completo di problemi noti e le soluzioni corrispondenti per ODF.
Distribuzione di OpenShift Data Foundation
Esaminare le opzioni di distribuzione per il provider dell'infrastruttura.
- Cluster di cloud privato virtuale (VPC)
- È possibile distribuire ODF utilizzando il provisioning dinamico con Block Storage for VPC o utilizzando dischi locali su lavoratori bare metal. Per ulteriori informazioni, consulta Distribuzione di OpenShift Data Foundation on VPC clusters.
- Cluster Satellite
- Se vuoi distribuire ODF ai cluster Satellite, puoi utilizzare il modello di memoria Satellite. Per ulteriori informazioni, vedi i seguenti link.
- Distribuzione del template OpenShift Data Foundation per i dischi remoti con provisioning dinamico.
- Distribuzione del template OpenShift Data Foundation per i dischi locali.
- Cluster classici
- Puoi distribuire ODF utilizzando i dischi locali sui nodi di lavoro bare metal. Per ulteriori informazioni, consulta Distribuzione di OpenShift Data Foundation on Classic clusters.