Red Hat OpenShift Data Foundation, anciennement Red Hat OpenShift Container Storage, est un stockage défini par logiciel pour les conteneurs. Conçue comme plate-forme de services de données et de stockage pour Red Hat OpenShift, Red Hat OpenShift Data Foundation (ODF) aide les équipes à développer et à déployer des applications rapidement et efficacement dans les clouds. C'est une solution puissante qui permet le stockage de blocs, de fichiers et d'objets.
Pour ceux qui sont habitués à une solution de stockage traditionnelle, une question qui se pose peut-être est de savoir comment un utilisateur peut mapper où les objets d'une application sont stockés dans le cluster ODF puisque le concept de stockage distribué et évolutif qu'apporte ODF présente des différences considérables par rapport aux autres solutions. Dans cet article, vous explorez comment effectuer ce mappage pour les scénarios de dépannage.
J'ai beaucoup de terrain à couvrir avec ce sujet, donc le contenu est divisé en trois articles. Le premier article (celui-ci) plante le décor en définissant l'environnement et les composants nécessaires. La deuxième partie couvre les informations de stockage de blocs et la troisième partie traite du mappage de stockage de fichiers.
Les infrastructures
Pour maintenir l'aspect pratique de cet article, je n'entrerai pas dans les détails de l'architecture du cluster OpenShift Container Platform (OCP) ou d'autres informations sans rapport avec l'activité. Sachez simplement que j'utilise un cluster OCP sur AWS avec un déploiement de cluster ODF interne sur trois travailleurs distincts dans différentes AZ avec un ensemble d'appareils de 500 Go chacun (1,5 To au total). Voici les versions utilisées à la fois par OCP et ODF :
[alexon@bastion ~]$ oc version
Client Version: 4.7.4
Server Version: 4.7.11
Kubernetes Version: v1.20.0+75370d3
[alexon@bastion ~]$ oc -n openshift-storage get csv
NAME DISPLAY VERSION REPLACES PHASE
elasticsearch-operator.5.0.3-6 OpenShift Elasticsearch Operator 5.0.3-6
elasticsearch-operator.4.6.0-202103010126.p0 Succeeded
ocs-operator.v4.7.0 OpenShift Container Storage 4.7.0 ocs-operator.v4.6.4 Succeeded
[alexon@bastion ~]$ oc get nodes -l cluster.ocs.openshift.io/openshift-storage=
NAME STATUS ROLES
AGE VERSION
ip-10-0-143-192.ec2.internal Ready
worker 6d23h v1.20.0+75370d3
ip-10-0-154-20.ec2.internal Ready
worker 6d23h v1.20.0+75370d3
ip-10-0-171-63.ec2.internal Ready
worker 6d23h v1.20.0+75370d3 Maintenant, pour pouvoir faire l'analyse nécessaire sur votre bloc ODF et votre stockage backend de fichiers, qui dans ce cas est Ceph, vous avez besoin d'un outil spécifique. Cet outil est la boîte à outils Rook, un conteneur avec des outils communs utilisés pour le débogage et les tests de Rook. Il est disponible dans le référentiel GitHub officiel de Rook, et vous pouvez en savoir plus ici.
Utiliser la boîte à outils
La première tâche consiste à utiliser la spécification de la boîte à outils pour exécuter le module de la boîte à outils dans un mode interactif disponible sur le lien fourni ci-dessus, ou à télécharger directement à partir de ce lien.
Enregistrez-le en tant que fichier YAML, puis lancez les rook-ceph-tools module :
[alexon@bastion ~]$ oc apply -f toolbox.yml -n openshift-storage Comme vous pouvez le voir ci-dessous, ma pile ODF fonctionne correctement dans mon openshift-storage projet. J'ai configuré les classes de stockage appropriées, avec ocs-storagecluster-ceph-rbd étant le SC par défaut. De plus, j'ai déjà les rook-ceph-tools pod déployé et en cours d'exécution :
[alexon@bastion ~]$ oc project openshift-storage
Now using project "openshift-storage" on server "https://api.example.com:6443":
[alexon@bastion ~]$ oc get pods
NAME
READY STATUS RESTARTS
AGE
csi-cephfsplugin-c86r8
3/3 Running 0
3h13m
csi-cephfsplugin-lk8cq
3/3 Running 0
3h14m
csi-cephfsplugin-pqhrh
3/3 Running
0 3h13m
csi-cephfsplugin-provisioner-6878df594-8547z 6/6 Running
0 3h14m
csi-cephfsplugin-provisioner-6878df594-bl7hn 6/6 Running
0 3h14m
csi-rbdplugin-ff4hz
3/3 Running 0
3h13m
csi-rbdplugin-m2cf7 3/3 Running
0 3h13m
csi-rbdplugin-provisioner-85f54d8949-h47td 6/6 Running
0 3h14m
csi-rbdplugin-provisioner-85f54d8949-mstpp 6/6 Running
0 3h14m
csi-rbdplugin-t8tpg
3/3 Running 0
3h14m
noobaa-core-0 1/1 Running
0 3h11m
noobaa-db-pg-0
1/1 Running 0
3h14m
noobaa-endpoint-75644c884-rv7zn 1/1 Running
0 3h10m
noobaa-operator-5b4ccb78d6-lz66m 1/1 Running
0 3h14m
ocs-metrics-exporter-db8d78475-ch2mk 1/1 Running
0 3h14m
ocs-operator-776b95f74b-mzmwq 1/1
Running 0 3h14m
rook-ceph-crashcollector-ip-10-0-143-192-59fc4bff5b-22sv4 1/1
Running 0 3h12m
rook-ceph-crashcollector-ip-10-0-154-20-65d656dbb4-4q6xk 1/1 Running
0 3h13m
rook-ceph-crashcollector-ip-10-0-171-63-74f8554574-f99br 1/1 Running
0 3h13m
rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-b89f56667z5fj 2/2
Running 0 3h12m
rook-ceph-mds-ocs-storagecluster-cephfilesystem-b-558f8bbct2lrv 2/2
Running 0 3h12m
rook-ceph-mgr-a-6d54bfd95d-7xdwp 2/2 Running
0 3h11m
rook-ceph-mon-a-67fc544d5f-f7ghz 2/2 Running
0 3h13m
rook-ceph-mon-b-6c6b9565d7-cbgqz 2/2 Running
0 3h11m
rook-ceph-mon-c-6c44cb9765-9h828 2/2 Running
0 3h13m
rook-ceph-operator-58c6f9696b-b2qnm 1/1 Running
0 3h14m
rook-ceph-osd-0-66cfd8cd5f-dgvpp 2/2 Running
0 3h10m
rook-ceph-osd-1-5c75dbffdd-qg8gs 2/2 Running
0 3h9m
rook-ceph-osd-2-7c555c7578-jq8sz 2/2 Running
0 3h8m
rook-ceph-tools-78cdfd976c-b6wk7 1/1 Running
0 179m
[alexon@bastion ~]$ oc get sc
NAME
PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
gp2
kubernetes.io/aws-ebs
Delete
WaitForFirstConsumer true 6d22h
gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 6d22h
ocs-storagecluster-ceph-rbd (default) openshift-storage.rbd.csi.ceph.com Delete Immediate true 6d2h
ocs-storagecluster-cephfs
openshift-storage.cephfs.csi.ceph.com
Delete Immediate true 6d2h
openshift-storage.noobaa.io
openshift-storage.noobaa.io/obc
Delete Immediate false 6d2h Accédez à votre pod de boîte à outils pour recueillir plus d'informations sur votre cluster de stockage :
[alexon@bastion ~]$ toolbox=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
[alexon@bastion ~]$ oc rsh -n openshift-storage $toolbox Exécutez les commandes connues pour administrer un cluster Ceph afin de vérifier certaines informations sur votre cluster ODF :
sh-4.4$ ceph -s
cluster:
id: ef49037e-1257-462c-b8da-053f6a9ce9b2
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c (age 3h)
mgr: a(active, since 3h)
mds: ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-a=up:active} 1 up:standby-replay
osd: 3 osds: 3 up (since 3h), 3 in (since 6d)
task status:
scrub status:
mds.ocs-storagecluster-cephfilesystem-a: idle
mds.ocs-storagecluster-cephfilesystem-b: idle
data:
pools: 3 pools, 96 pgs
objects: 22.28k objects, 85 GiB
usage: 254 GiB used, 1.3 TiB / 1.5 TiB avail
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 df
RAW STORAGE:
CLASS SIZE
AVAIL USED RAW USED %RAW USED
ssd 1.5 TiB 1.3 TiB
251 GiB 254 GiB 16.54
TOTAL 1.5 TiB
1.3 TiB 251 GiB 254 GiB 16.54
POOLS:
POOL
ID STORED OBJECTS USED
%USED MAX AVAIL
ocs-storagecluster-cephblockpool 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
351 GiB
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 | 84.6G | 427G | 87 | 947k
| 0 |
0 | exists,up |
| 1 | ip-10-0-143-192.ec2.internal | 84.6G |
427G | 61 |
510k | 0
| 0 | exists,up |
| 2 | ip-10-0-154-20.ec2.internal | 84.6G | 427G | 96
| 1072k |
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
sh-4.4$ rados df
POOL_NAME USED OBJECTS
CLONES COPIES MISSING_ON_PRIMARY UNFOUND
DEGRADED RD_OPS RD
WR_OPS WR USED COMPR
UNDER COMPR
ocs-storagecluster-cephblockpool 251 GiB 22266
0 66798 0 0 0
475905 34 GiB 37496563
634 GiB 0 B 0 B
ocs-storagecluster-cephfilesystem-data0 0 B 0
0 0 0 0 0
30 14 KiB 42
24 KiB 0 B 0 B
ocs-storagecluster-cephfilesystem-metadata 4.2 MiB
25 0 75 0
0 0 142734
78 MiB 706 1.7 MiB 0 B 0 B
total_objects
22291
total_used 254 GiB
total_avail 1.3 TiB
total_space 1.5 TiB
sh-4.4$ ceph fs status
ocs-storagecluster-cephfilesystem - 0 clients
=================================
+------+----------------+-------------------------------------+---------------+-------+-------+
| Rank |
State | MDS | Activity
| dns | inos |
+------+----------------+-------------------------------------+---------------+-------+-------+
| 0 |
active | ocs-storagecluster-cephfilesystem-a | Reqs:
0 /s | 59 |
32 |
| 0-s | standby-replay | ocs-storagecluster-cephfilesystem-b | Evts: 0 /s |
68 | 24 |
+------+----------------+-------------------------------------+---------------+-------+-------+
+--------------------------------------------+----------+-------+-------+
|
Pool |
type | used | avail |
+--------------------------------------------+----------+-------+-------+
| ocs-storagecluster-cephfilesystem-metadata | metadata | 4260k | 350G |
|
ocs-storagecluster-cephfilesystem-data0
| data | 0 | 350G |
+--------------------------------------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
+-------------+
MDS version: ceph version 14.2.11-147.el8cp (1f54d52f20d93c1b91f1ec6af4c67a4b81402800) nautilus (stable)
sh-4.4$ ceph fs volume ls
[
{
"name": "ocs-storagecluster-cephfilesystem"
}
] Comme vous pouvez le voir ci-dessus, le ocs-storagecluster-cephblockpool et le ocs-storagecluster-cephfilesystem-data0 les pools sont créés par défaut. Le premier est utilisé par RBD pour le stockage de blocs et le second est utilisé par CephFS pour le stockage de fichiers. Gardez cela à l'esprit, car ce sont les pools que vous utiliserez dans vos enquêtes.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Récapitulez
Ici, dans la première partie, j'ai défini le problème du mappage des objets d'application au sein d'un cluster ODF. J'ai couvert le conteneur de la boîte à outils Rook et les outils de débogage et de test communs qu'il contient. J'ai également établi l'infrastructure que vous utiliserez dans les deux prochains articles de la série. À partir de là, accédez à l'article deux pour la couverture du stockage de blocs de mappage dans le cluster ODF. Après cela, lisez la troisième partie pour le mappage de stockage de fichiers et une synthèse du projet.