Questa serie di articoli consente di comprendere meglio come mappare i dati dell'applicazione all'interno dei cluster ODF utilizzando il toolkit Rook e i comandi OpenShift. Questa conoscenza e gli strumenti associati possono essere molto utili per la risoluzione dei problemi e per una comprensione più approfondita dell'archiviazione dei dati in ODF. Assicurati di aver letto la prima e la seconda parte prima di leggere questa (parte terza della serie).
Crea un progetto di archiviazione file
Seguirai gli stessi principi che hai utilizzato finora per fare qualcosa di simile al precedente progetto di archiviazione a blocchi con un'applicazione che utilizza CephFS da ODF per l'archiviazione condivisa. Crea un nuovo progetto chiamato ocs-file-app :
[alexon@bastion ~]$ oc new-project ocs-file-app
Now using project "ocs-file-app" on server "https://api.example.com:6443".
Puoi aggiungere applicazioni a questo progetto con new-app comando. Ad esempio, per creare una nuova applicazione di esempio in Ruby, prova:
oc new-app rails-postgresql-example
Oppure usa kubectl per distribuire una semplice applicazione Kubernetes:
kubectl create deployment hello-node --image=k8s.gcr.io/serve_hostname Per questo esempio, utilizza una Dimostrazione di caricamento di file PHP OpenShift applicazione (che ho ricavato dal progetto di Christian Hernandez - due crediti) che servirà bene i tuoi interessi:
[alexon@bastion ~]$ oc new-app openshift/php:7.2-ubi8~https://github.com/AlexonOliveiraRH/openshift-php-upload-demo.git --name=file-uploader
--> Found image 67520c7 (5 weeks old) in image stream "openshift/php" under tag "7.2-ubi8" for "openshift/php:7.2-ubi8"
Apache 2.4 with PHP 7.2
-----------------------
PHP 7.2 available as container is a base platform for building and running various PHP 7.2 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts.
Tags: builder, php, php72, php-72
* A source build using source code from https://github.com/AlexonOliveiraRH/openshift-php-upload-demo.git will be created
* The resulting image will be pushed to image stream tag "file-uploader:latest"
* Use 'oc start-build' to trigger a new build
--> Creating resources ...
imagestream.image.openshift.io "file-uploader" created
buildconfig.build.openshift.io "file-uploader" created
deployment.apps "file-uploader" created
service "file-uploader" created
--> Success
Build scheduled, use 'oc logs -f buildconfig/file-uploader' to track its progress.
Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
'oc expose service/file-uploader'
Run' oc status' to view your app.
[alexon@bastion ~]$ oc expose svc/file-uploader -n ocs-file-app
route.route.openshift.io/file-uploader exposed
[alexon@bastion ~]$ oc scale --replicas=3 deploy/file-uploader -n ocs-file-app
deployment.apps/file-uploader scaled
[alexon@bastion ~]$ oc get pods -n ocs-file-app
NAME READY STATUS
RESTARTS AGE
file-uploader-1-build 0/1 Completed
0 79s
file-uploader-764468fb46-6vlxg 1/1
Running 0 11s
file-uploader-764468fb46-cr4mc 1/1
Running 0 7s
file-uploader-764468fb46-vtsq5 1/1
Running 0 15s Questa nuova applicazione utilizza ocs-storagecluster-cephfs SC:
[alexon@bastion ~]$ oc set volume deploy/file-uploader --add --name=ocs-file-app \
> -t pvc --claim-mode=ReadWriteMany --claim-size=1Gi \
> --claim-name=ocs-file-app --claim-class=ocs-storagecluster-cephfs \
> --mount-path=/opt/app-root/src/uploaded \
> -n ocs-file-app
deployment.apps/file-uploader volume updated
NAME READY STATUS
RESTARTS AGE
file-uploader-1-build 0/1 Completed
0 2m7s
file-uploader-69b547dfd6-gvhfk 1/1
Running 0 33s
file-uploader-69b547dfd6-nzhl8 1/1
Running 0 26s
file-uploader-69b547dfd6-qbj28 1/1
Running 0 15s
[alexon@bastion ~]$ oc get pvc
NAME
STATUS VOLUME
CAPACITY ACCESS MODES STORAGECLASS AGE
ocs-file-app
Bound
pvc-73c1bda0-2256-407d-885d-e5bcfd221b27 1Gi
RWX
ocs-storagecluster-cephfs 44m
Come semplice test, crea un file chiamato testfile.txt con il "Ciao mondo!" contenuto e caricarlo nella tua applicazione tramite l'interfaccia utente dell'applicazione:
[alexon@bastion ~]$ oc get route file-uploader -n ocs-file-app -o jsonpath --template="http://{.spec.host}{'\n'}"
http://file-uploader-ocs-file-app.apps.example.com
[alolivei@alolivei ~]$ echo 'Hello world!' >> testfile.txt
[alolivei@alolivei ~]$ cat testfile.txt
Hello world! Carica il file:
Ed ecco il risultato:
Per mappare un oggetto file, la procedura è leggermente diversa dall'oggetto blocco. Questo perché CephFS utilizza l'indirizzo inode del file convertito in esadecimale per denominarlo all'interno del pool di file. Pertanto, è necessario trovare l'oggetto utilizzando uno dei pod dell'applicazione nella directory montata all'interno del pod da CephFS, scoprire il suo inode, quindi convertire il numero dell'inode in esadecimale, come nell'esempio seguente:
[alexon@bastion ~]$ oc get pods
NAME READY STATUS RESTARTS
AGE
file-uploader-1-build 0/1 Completed
0 8m32s
file-uploader-69b547dfd6-gvhfk 1/1
Running 0 6m58s
file-uploader-69b547dfd6-nzhl8 1/1
Running 0 6m51s
file-uploader-69b547dfd6-qbj28 1/1
Running 0 6m40s
[alexon@bastion ~]$ oc rsh file-uploader-69b547dfd6-gvhfk
sh-4.4$ mount | grep csi-vol
172.30.38.159:6789,172.30.136.12:6789,172.30.73.120:6789:/volumes/csi/csi-vol-8a803889-bcce-11eb-8d22-0a580a81023e/3910620a-e68c-424b-8982-8f2b21c26a8a on /opt/app-root/src/uploaded type ceph (rw,relatime,seclabel,name=csi-cephfs-node,secret=<hidden>,acl,mds_namespace=ocs-storagecluster-cephfilesystem)
sh-4.4$ ls /opt/app-root/src/uploaded
testfile.txt
sh-4.4$ stat -c %i /opt/app-root/src/uploaded/testfile.txt | xargs printf '%x\n'
1000000001a Ora che hai queste informazioni, segui gli stessi passaggi di prima, con alcune piccole differenze, per trovare l'oggetto all'interno di ocs-storagecluster-cephfilesystem-data0 pool e anche il nodo ad esso collegato, come segue:
sh-4.4$ ceph df
RAW STORAGE:
CLASS SIZE
AVAIL USED RAW USED %RAW USED
ssd 1.5 TiB 1.2 TiB
253 GiB 256 GiB 16.68
TOTAL 1.5 TiB
1.2 TiB 253 GiB 256 GiB 16.68
POOLS:
POOL
ID STORED OBJECTS USED
%USED MAX AVAIL
ocs-storagecluster-cephblockpool 1 84 GiB 22.45k
253 GiB 19.43 350 GiB
ocs-storagecluster-cephfilesystem-metadata 2
1.5 MiB 26 4.5 MiB 0
350 GiB
ocs-storagecluster-cephfilesystem-data0 3
171 B 2 24 KiB 0
350 GiB
sh-4.4$ rados -p ocs-storagecluster-cephfilesystem-data0 ls | grep 1000000001a
1000000001a.00000000
sh-4.4$ rados -p ocs-storagecluster-cephfilesystem-data0 stat2 1000000001a.00000000
ocs-storagecluster-cephfilesystem-data0/1000000001a.00000000 mtime 2021-05-24T20:33:51.179464+0000, size 13 Sembra che tu abbia trovato il tuo oggetto. Un modo semplice e veloce per convalidarlo è esportarlo dall'interno del pool e verificarne il contenuto:
sh-4.4$ rados -p ocs-storagecluster-cephfilesystem-data0 get 1000000001a.00000000
/tmp/output.txt
sh-4.4$ cat /tmp/output.txt
Hello world! Ora termina il processo e mappa in quale nodo si trova il file:
sh-4.4$ ceph osd map ocs-storagecluster-cephfilesystem-data0 1000000001a.00000000
osdmap e405 pool 'ocs-storagecluster-cephfilesystem-data0' (3) object '1000000001a.00000000' -> pg 3.a8154e0 (3.0) -> up ([2,1,0], p2) acting ([2,1,0], p2)
sh-4.4$ ceph osd status
+----+------------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id |
host |
used | avail | wr ops | wr data | rd ops | rd data | state
|
+----+------------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0 | ip-10-0-171-63.ec2.internal | 85.4G | 426G | 86 | 1221k
| 0 |
0 | exists,up |
| 1 | ip-10-0-143-192.ec2.internal | 85.4G |
426G | 78 | 1678k |
0 | 0
| exists,up |
| 2 | ip-10-0-154-20.ec2.internal | 85.4G | 426G | 67 | 643k
| 2 |
106 | exists,up |
+----+------------------------------+-------+-------+--------+---------+--------+---------+-----------+
sh-4.4$ ceph osd tree
ID CLASS WEIGHT TYPE NAME
STATUS REWEIGHT PRI-AFF
-1 1.50000 root default
-5 1.50000 region us-east-1
-4 0.50000 zone 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 zone us-east-1b
-9 0.50000 host ocs-deviceset-gp2-csi-2-data-0n9lkb
2 ssd 0.50000 osd.2 up 1.00000 1.00000
-14
0.50000 zone us-east-1c
-13
0.50000 host ocs-deviceset-gp2-csi-0-data-0gvt22
0 ssd 0.50000 osd.0 up 1.00000 1.00000
Ancora una volta, sappi che l'oggetto si trova in un PG con ID OSD 2 come principale, con le sue repliche negli ID OSD 1 e 0, che questo OSD sta utilizzando l'host del dispositivo ocs-deviceset-gp2-csi-2- data-0n9lkb sull'host ip-10-0-154-20.ec2.internal . Se vuoi essere sicuro che questo sia il nodo corretto, controlla il dispositivo con lsblk o dmsetup :
[alexon@bastion ~]$ oc debug node/ip-10-0-154-20.ec2.internal
Starting pod/ip-10-0-154-20ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.154.20
If you don't see a command prompt, try pressing enter.
sh-4.4# lsblk | grep ocs-deviceset-gp2-csi-2-data-0n9lkb
`-ocs-deviceset-gp2-csi-2-data-0n9lkb-block-dmcrypt 253:0 0 512G
0 crypt
sh-4.4# dmsetup ls | grep ocs-deviceset-gp2-csi-2-data-0n9lkb
ocs-deviceset-gp2-csi-2-data-0n9lkb-block-dmcrypt (253:0)
Usando il nome del PV utilizzato dalla PVC dell'applicazione che hai visto in precedenza, grep e vedere dove sono montati i percorsi disponibili per l'applicazione:
sh-4.4# mount | grep pvc-73c1bda0-2256-407d-885d-e5bcfd221b27
172.30.38.159:6789,172.30.136.12:6789,172.30.73.120:6789:/volumes/csi/csi-vol-8a803889-bcce-11eb-8d22-0a580a81023e/3910620a-e68c-424b-8982-8f2b21c26a8a on /host/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/globalmount type ceph (rw,relatime,seclabel,name=csi-cephfs-node,secret=<hidden>,acl,mds_namespace=ocs-storagecluster-cephfilesystem)
172.30.38.159:6789,172.30.136.12:6789,172.30.73.120:6789:/volumes/csi/csi-vol-8a803889-bcce-11eb-8d22-0a580a81023e/3910620a-e68c-424b-8982-8f2b21c26a8a on /host/var/lib/kubelet/pods/ac40b1fa-a08d-46b5-8bb6-dc55a5638e9e/volumes/kubernetes.io~csi/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/mount type ceph (rw,relatime,seclabel,name=csi-cephfs-node,secret=<hidden>,acl,mds_namespace=ocs-storagecluster-cephfilesystem) Infine, guarda il contenuto delle directory, e all'interno troverai il tuo oggetto, pronto per essere visualizzato:
sh-4.4# ls /host/var/lib/kubelet/pods/ac40b1fa-a08d-46b5-8bb6-dc55a5638e9e/volumes/kubernetes.io~csi/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/mount
testfile.txt
sh-4.4# cat /host/var/lib/kubelet/pods/ac40b1fa-a08d-46b5-8bb6-dc55a5638e9e/volumes/kubernetes.io~csi/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/mount/estfile.txt
Hello world!
sh-4.4# ls /host/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/globalmount
testfile.txt
sh-4.4# cat /host/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-73c1bda0-2256-407d-885d-e5bcfd221b27/globalmount/testfile.txt
Hello world! Ora sai come trovare e mappare le informazioni sugli oggetti dei file nel cluster, proprio come hai visto nell'articolo due con le informazioni sui blocchi.
[ Ottieni questo libro gratuito da Red Hat e O'Reilly - Operatori Kubernetes:Automating the Container Orchestration Platform. ]
Concludi
L'approccio ODF allo storage distribuito e scalabile è molto diverso da altre soluzioni di storage. Può essere difficile capire dove sono archiviati gli oggetti dell'applicazione all'interno del cluster, il che presenta problemi durante la risoluzione dei problemi (e la progettazione).
Questa serie di articoli è una dimostrazione di base del funzionamento del mapping di oggetti dell'applicazione ODF. Nella prima parte, hai stabilito l'ambiente e le utenze necessarie. La seconda parte riguardava l'archiviazione a blocchi mentre la terza parte esaminava le strutture di archiviazione dei file. Ora che sai come farlo, fai buon uso.