Red Hat OpenShift Data Foundation, in precedenza Red Hat OpenShift Container Storage, è uno storage software-defined per i container. Progettata come piattaforma di servizi di archiviazione e dati per Red Hat OpenShift, Red Hat OpenShift Data Foundation (ODF) aiuta i team a sviluppare e distribuire applicazioni in modo rapido ed efficiente tra i cloud. È una soluzione potente che consente l'archiviazione di blocchi, file e oggetti.
Per coloro che sono abituati a una soluzione di archiviazione tradizionale, forse una domanda che sorge è come un utente può mappare dove sono archiviati gli oggetti di un'applicazione all'interno del cluster ODF poiché il concetto di archiviazione distribuita e scalabile che ODF offre presenta notevoli differenze rispetto ad altri soluzioni. In questo articolo, esplorerai come eseguire questa mappatura per la risoluzione dei problemi di scenari.
Ho molto terreno da trattare con questo argomento, quindi il contenuto è suddiviso in tre articoli. Il primo articolo (questo) pone le basi definendo l'ambiente ei componenti necessari. La seconda parte copre le informazioni sull'archiviazione dei blocchi e la terza gestisce la mappatura dell'archiviazione dei file.
L'infrastruttura
Per mantenere la praticità di questo articolo, non entrerò nei dettagli sull'architettura del cluster OpenShift Container Platform (OCP) o su altre informazioni irrilevanti per l'attività. Sappi solo che sto utilizzando un cluster OCP su AWS con una distribuzione interna del cluster ODF su tre lavoratori separati in diverse AZ con un set di dispositivi da 500 GB ciascuno (1,5 TB in totale). Queste sono le versioni utilizzate sia da OCP che da ODF:
[alexon@bastion ~]$ oc versionClient Version:4.7.4Server Version:4.7.11Kubernetes Version:v1.20.0+75370d3[alexon@bastion ~]$ oc -n openshift-storage get csvNAME DISPLAY VERSION SOSTITUISCE PHASEelasticsearch-operator.5.0.3-6 OpenShift Elasticsearch Operator 5.0.3-6 elasticsearch-operator.4.6.0-202103010126.p0 Succeededdocs-operator.v4.7.0 OpenShift Container Storage 4.7.0 ocs-operator.v4.6.4 Riuscito[ alexon@bastion ~]$ oc get nodes -l cluster.ocs.openshift.io/openshift-storage=NOME RUOLI STATO ETÀ VERSIONip-10-0-143-192.ec2.internal Ready worker 6d23h v1.20.0+75370d3ip-10 -0-154-20.ec2.internal Ready worker 6d23h v1.20.0+75370d3ip-10-0-171-63.ec2.internal Ready worker 6d23h v1.20.0+75370d3 Ora, per poter eseguire le analisi necessarie sul blocco ODF e sul file storage di backend, che in questo caso è Ceph, è necessario uno strumento specifico. Questo strumento è la casella degli strumenti Rook, un contenitore con strumenti comuni utilizzati per il debug e il test di Rook. È disponibile nel repository GitHub ufficiale di Rook e puoi leggere ulteriori informazioni qui.
Utilizzo della casella degli strumenti
La prima attività consiste nell'utilizzare le specifiche della casella degli strumenti per eseguire il contenitore della casella degli strumenti in una modalità interattiva disponibile al collegamento fornito sopra o scaricare direttamente da questo collegamento.
Salvalo come file YAML, quindi avvia rook-ceph-tools baccello:
[alexon@bastion ~]$ oc apply -f toolbox.yml -n openshift-storage Come puoi vedere di seguito, il mio stack ODF funziona senza problemi nel mio spazio di archiviazione a turni progetto. Ho configurato le classi di archiviazione appropriate, con ocs-storagecluster-ceph-rbd essendo l'SC predefinito. Inoltre, ho già gli strumenti rook-ceph pod distribuito e funzionante:
[alexon@bastion ~]$ oc progetto openshift-storageNow utilizzando il progetto "openshift-storage" sul server "https://api.example.com:6443": Accedi al tuo pod della casella degli strumenti per raccogliere ulteriori informazioni sul tuo cluster di archiviazione:
[alexon@bastion ~]$ toolbox=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)[alexon@bastion ~]$ oc rsh -n openshift -memorizzazione $cassetta degli attrezzi Esegui i comandi noti per l'amministrazione di un cluster Ceph per verificare alcune informazioni sul tuo cluster ODF:
sh-4.4$ ceph -s cluster: id:ef49037e-1257-462c-b8da-053f6a9ce9b2 salute:HEALTH_OK servizi: mon:3 daemons, quorum a,b,c (età 3h) mgr:a( attivo, da 3 ore) mds:ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-a=up:attivo} 1 su:standby-replay osd:3 osd:3 su (da 3 ore), 3 in ( dal 6d) stato attività: stato scrub: mds.ocs-storagecluster-cephfilesystem-a:idle mds.ocs-storagecluster-cephfilesystem-b:idle dati: pool:3 pool, 96 pgs oggetti:22,28 k oggetti, 85 GiB utilizzo:254 GiB utilizzati, 1,3 TiB / 1,5 TiB disponibili pgs:96 active+clean io: client:853 B/s rd, 2,1 MiB/s wr, 1 op/s rd, 171 op/s wr sh-4,4 $ ceph dfRAW STORAGE :Dimensione classe disponibile Utilizzato RAW Utilizzato %RAW Utilizzato SSD utilizzato 1,5 TIB 1.3 TIB 251 Gib 254 Gib 16,54 Totale 1,5 TIB 1,3 TIB 251 GIB 254 GIB 16,54 Pools:ID pool Oggetti memorizzati usati %usati MASSIMA VISUALI pool 1 84 GiB 22,25k 251 GiB 19,27 351 GiB ocs-storagecluster-cephfilesystem-metadata 2 1,4 MiB 25 4,2 MiB 0 351 GiB ocs-storagecluster-cephfilesystem-data0 3 0 B 0 0 B 0 5 os. ----+----------------+-------+------ -+---------+---------+---------+----------+---------- -+| id | ospite | usato | usufruire | operazioni | wr dati | rd operazioni | rd dati | stato |+----+------------------------------+--------+--- ----+--------+---------+---------+---------+------- ----+| 0 | ip-10-0-171-63.ec2.internal | 84.6G | 427G | 87 | 947k | 0 | 0 | esiste, su || 1 | ip-10-0-143-192.ec2.internal | 84.6G | 427G | 61 | 510k | 0 | 0 | esiste, su || 2 | ip-10-0-154-20.ec2.internal | 84.6G | 427G | 96 | 1072k | 2 | 106 | esiste,su |+----+------------------------------+-------+- ------+--------+---------+--------+---------+----- ------+SH-4,4 $ Ceph OSD TreeID Classe di classe Nome Nome REIEDE PRI-AFF -1 1.50000 Radice -5 1.50000 Regione US-EAST-1 -4 0,50000 ZONA US-EAST-1A -3 0,50000 host OCS-DEVICESET-GP2-CSI-1-DATA-085B8H 1 SSD 0,50000 OSD.1 UP 1.00000 1.00000 -10 0,50000 ZONA US-EAST-EAST-1B -9 0,50000 OCS-DEVICESET-GP2-CSI-2-DATA-0N9LKB 2 SSD 0,50000 OSD.2 UP 1.00000 1.00000 -14 0,50000 ZONA US-EAST-EAST-EAC -13 0.50000 Host OCS-Deviceset-GP2-CSI-0-DATA-0GVT22 0 SSD 0,50000 OSD.0 UP 1.00000 1.00000 SH-4.4 $ RADOS DFPOOL_NAME Objects usatiCloni Copie mancanti_on_primary infondata rd_ops rd wr_ops wr utilizzata comprendente in compocs-storagecluster-cephlockpool 251 gib 22266 0 66798 0 0 475905 34 GIB 37496563 634 gib 0 b 0 bocs-storagecluster-cephpesymystem-data0 14 kib 42 24 kib 0 b 0 bocs-storagecluster-pephfilesystem-metadata 4.2 mib 25 0 75 0 0 0 142734 78 mib 706 1.7 mib 0 b 0 btotal_objects 22291total_used 254 gibtotal_avail 1.3 tibtotal_space 1.5 tibsh-4.4 cEps fs fs 22291total_used 254 gibtotal_avail 1.3 tibtotal_space 1.5 tibsh-4 - 0 clienti===================================+------+------ ----------+--------------------------------------+- --------------+--------+-------+| Classifica | Stato | MDS | Attività | dn | inos |+-------+----------------+----------------------- --------------+----------------+-------+-------+| 0 | attivo | ocs-storagecluster-cephfilesystem-a | Richiesti: 0 /s | 59 | 32 || 0-s | riproduzione in standby | ocs-storagecluster-cephfilesystem-b | Eventi:0 /s | 68 | 24 |+------+----------------+----------------------- --------------+----------------+-------+-------++-- -------------------------------------------+------- ---+-------+-------+| Piscina | tipo | usato | usufruire |+---------------------------------------------+-- --------+-------+-------+| ocs-storagecluster-cephfilesystem-metadata | metadati | 4260k | 350G || ocs-storagecluster-cephfilesystem-data0 | dati | 0 | 350G |+---------------------------------------------+-- --------+-------+-------++--------------+| Standby MDS |+-------------++-------------+Versione MDS:versione ceph 14.2.11-147.el8cp (1f54d52f20d93c1b91f1ec6af4c67a4b81402800) nautilus ( stable)sh-4.4$ ceph fs volume ls[ { "name":"ocs-storagecluster-cephfilesystem" }] Come puoi vedere sopra, il ocs-storagecluster-cephblockpool e ocs-storagecluster-cephfilesystem-data0 i pool vengono creati per impostazione predefinita. Il primo è utilizzato da RBD per l'archiviazione a blocchi e il secondo è utilizzato da CephFS per l'archiviazione di file. Tienilo a mente, poiché questi sono i pool che utilizzerai nelle tue indagini.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Qui nella prima parte, ho definito il problema della mappatura degli oggetti dell'applicazione all'interno di un cluster ODF. Ho trattato il contenitore della casella degli strumenti Rook e gli strumenti comuni di debug e test contenuti al suo interno. Ho anche stabilito l'infrastruttura che utilizzerai nei prossimi due articoli della serie. Da qui, vai all'articolo due per la copertura dell'archiviazione a blocchi di mappatura all'interno del cluster ODF. Dopodiché, leggi la parte tre per la mappatura dell'archiviazione dei file e un riepilogo del progetto.