Cara Aman Reboot OCS 4.x node.
Pada artikel ini saya mengambil satu kasus dimana node ODF (OpenShift Data Foundation) sebelum nya kita menyebutnya OCS (OpenShift Container Storage) pada cluster yang kita miliki mengalami SchedulingDisabled, hal ini bisa dikarenakan banyak hal, salah satunya adalah kerusakan pada ceph-mon dan ceph-osd. Secara normal tiap node ODF akan memiliki ceph-mon dan ceph-osd.
Ceph adalah aplikasi open source yang menyediakan layanan kepada pengguna untuk membangun sebuah storage cluster. Storage cluster merupakan kumpulan node/computer/server yang tergabung dalam satu pengelolaan untuk menyediakan layanan media penyimpanan lintas komputer (terdistribusi).
Ceph-mon (Monitoring) adalah cluster monitor daemon untuk sistem file terdistribusi Ceph. Satu atau lebih instance dari ceph-mon akan membentuk kluster part-time Paxos yang mem-provides extremely reliable dan durable storage untuk cluster membership, configuration dan state. Sederhananya, ceph-mon adalah bagian dari Ceph yang bertanggung jawab untuk memantau kluster dan menyimpan informasi tentang cluster membership, configuration, dan statusnya.
Ceph-osd (Object Storage Device) adalah sebuah daemon yang bertanggung jawab untuk menyimpan data pada sebuah node dalam sebuah cluster Ceph. Setiap node OSD memiliki beberapa disk yang digunakan untuk menyimpan data.
Kita bisa melakukan pengecekan apakah odf node yang kita miliki dalam keadaan proper.
oc get pods -o wide -n openshift-storage | grep <odf-node-domain> | egrep 'osd|mon'
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-1.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-mon-a-668cf79bd4-nmjs5 2/2 Running 2 35d 10.130.6.6 odf-1.devqa-kcln.ocp.hq.example.co.id <none> <none>
rook-ceph-osd-1-6b546f65bf-x27m7 2/2 Running 2 35d 10.130.6.11 odf-1.devqa-kcln.ocp.hq.example.co.id <none> <none>
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-2.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-mon-b-9b64c565-5j2tn 2/2 Running 2 42m 10.131.4.6 odf-2.devqa-kcln.ocp.hq.example.co.id <none> <none>
rook-ceph-osd-2-66cb999b4d-6kn8p 2/2 Running 0 24m 10.131.4.11 odf-2.devqa-kcln.ocp.hq.example.co.id <none> <none>
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-3.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-mon-c-5c47bb47c-vw2q4 2/2 Running 2 73d 10.129.6.13 odf-3.devqa-kcln.ocp.hq.example.co.id <none> <none>
rook-ceph-osd-3-5b444fdf96-bf5dn 2/2 Running 2 44d 10.129.6.12 odf-3.devqa-kcln.ocp.hq.example.co.id <none> <none>
Dari hasil pengecekan openshift-storage dalam keadaan normal, kita bisa lihat bahwasanya tiap odf akan memiliki 1 mon daemon dan 1 osd daemon. Untuk penamaan pods umumnya di namai sesuai dengan nama odf node nya, kurang lebih naming convention nya akan terlihat seperti ini.
odf-1 -> rook-ceph-mon-a dan rook-ceph-osd-1
odf-2 -> rook-ceph-mon-b dan rook-ceph-osd-2
odf-3 -> rook-ceph-mon-c dan rook-ceph-osd-3
Rook adalah sebuah tools yang digunakan untuk menjalankan Ceph di dalam Cluster Kubernetes. Ceph sendiri adalah sistem penyimpanan terdistribusi yang menyediakan penyimpanan file, blok, dan objek dan diterapkan dalam klaster produksi skala besar. — Rook.io
Penamaan yang di lakukan tidak selalu seperti itu, tapi pada umumnya akan terlihat seperti itu. Lalu kenapa hal itu perlu kita perhatikan ? Nanti nya naming convention ini akan kita gunakan untuk melakukan pengecekan quorum ceph dalam cluster kita. Kita akan bahas di bagian lain atikel ini.
Dan seperti ini kondisi odf yang tidak normal. Tidak ada nya ceph-mon ataupun tidak ada nya ceph-osd.
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-1.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-mon-a-668cf79bd4-nmjs5 2/2 Running 2 35d 10.130.6.6 odf-1.devqa-kcln.ocp.hq.example.co.id <none> <none>
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-2.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-mon-b-9b64c565-5j2tn 2/2 Running 2 42m 10.131.4.6 odf-2.devqa-kcln.ocp.hq.example.co.id <none> <none>
[root@bastion ~]# oc get pods -o wide -n openshift-storage | grep odf-3.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
rook-ceph-osd-3-5b444fdf96-bf5dn 2/2 Running 2 44d 10.129.6.12 odf-3.devqa-kcln.ocp.hq.example.co.id <none> <none>
Setelah kita mendapat sedikit gambaran tentang apa itu ceph, kita akan mulai untuk membahas topik utama dari artikel ini, yaitu bagaimana cara yang aman untuk melakukan restart node pada Openshift Container Platform.
Katakanlah kita memilki kondisi cluster seperti ini, dimana odf-1, odf-2 dan odf-3 mengalami SchedulingDisabled. Tujuan kita membuat semua node itu kembali ke keadaan Ready.
[root@bastion ~]# oc get no
NAME STATUS ROLES AGE VERSION
csworker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-3.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
infra-1.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-2.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-3.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
master-1.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-2.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-3.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
odf-1.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
odf-2.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
odf-3.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
worker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
worker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
Hal pertama yang perlu kita lakukan adalah melakukan cordon untuk node yang akan kita restart. Cordon adalah salah satu fitur dalam OpenShift yang memungkinkan administrator untuk menonaktifkan node dari cluster. Ketika node dinonaktifkan, tidak ada pod yang di scheduling ke node tersebut dan pod yang sedang berjalan di dalam node akan dihapus.
Prosedure restart node secara aman mulai dari sini.
oc adm cordon <node-name>
oc adm cordon odf-1.devqa-kcln.ocp.hq.example.co.id
Setelah kita melakkukan cordon, kita perlu menunggu setidak nya 5 menit agar semua scheduler bertahap di hentikan oleh system.
Setelah di rasa scheduler sudah berhenti, langkan selanjutnya adalah kita perlu melakukan pengecekan pods dan deployment resource yang bersangkutan dengan node yang akan kita restart.
oc get deployment -n openshift-storage | grep osd
oc get deployment -n openshift-storage | grep mon
oc get pods -n openshift-storage -o wide | egrep 'mon|osd' | grep odf-1
oc get deployment -n openshift-storage | grep osd
rook-ceph-osd-1 0/1 1 0 155d
rook-ceph-osd-2 0/1 1 1 155d
rook-ceph-osd-3 0/1 1 1 35d
oc get deployment -n openshift-storage | grep mon
rook-ceph-mon-a 0/1 1 0 155d
rook-ceph-mon-b 0/1 1 1 155d
rook-ceph-mon-c 0/1 1 1 35d
oc get pods -n openshift-storage -o wide | egrep 'mon|osd' | grep odf-
rook-ceph-osd-1-66cb999b4d-r8f5k 2/2 Running 10 (47h ago) 44d 10.131.4.10 odf-1.devqa-kcln.ocp.hq.example.co.id <none> <none>
rook-ceph-osd-2-98e4rt9b6d-r6h1f 2/2 Running 10 (47h ago) 44d 10.131.4.10 odf-2.devqa-kcln.ocp.hq.example.co.id <none> <none>
rook-ceph-osd-3-54cb9hkb7d-rkh3k 2/2 Running 10 (47h ago) 44d 10.131.4.10 odf-3.devqa-kcln.ocp.hq.example.co.id <none> <none>
Dari hasil pengecekan deployment resource di atas, kita bisa lihat bahwasannya osd dan mon dalam keadaan down, dan hasil pengecekan pods di namespace openshift-storage menunjukkan hanya ada osd saja, dalam kondisi normal harus ada osd dan mon pods untuk tiap odf node.
Setelah kita tau kondisi deployment dan pods, langkah selanjutnya adalah kita perlu melakukan scaling down. Kita melakukan step ini untuk merestart pods yang berada dalam keadaan down.
oc scale deployment <rook-ceph | rook-mon> --replicas=0 -n openshift-storage
oc scale deployment rook-ceph-mon-a --replicas=0 -n openshift-storage
oc scale deployment rook-ceph-osd-1 --replicas=0 -n openshift-storage
Dalam satu waktu baiknya kita hanya melakukan restart satu node saja, jadi pertama kali kita akan fokus di node odf-1 dulu, baru setelah itu kita hanya perlu melakukan step yang serupa untuk odf node yang lain.
oc get deployment -n openshift-storage | grep osd
rook-ceph-osd-1 0/0 1 0 155d
rook-ceph-osd-2 0/1 1 1 155d
rook-ceph-osd-3 0/1 1 1 155d
oc get deployment -n openshift-storage | grep mon
rook-ceph-mon-a 0/0 1 0 155d
rook-ceph-mon-b 0/1 1 1 155d
rook-ceph-mon-c 0/1 1 1 155d
Pastikan bahwa osd dan mon deployment nya 0/0. Langkah selanjutnya kita akan melakukan delete resource yang ada di dalam node odf. Step ini biasanya memakan waktu 5–10 menit bahkan lebih.
oc adm drain odf-1.devqa-kcln.ocp.hq.example.co.id --ignore-daemonsets --delete-local-data
Ada beberapa cara untuk melakukan drain node, tapi perlu di perhatikan sesuai dengan kebutuhan. Untuk case saat ini menggunakan cara di atas.
oc adm drain odf-1.devqa-kcln.ocp.hq.example.co.id --ignore-daemonsets --delete-local-data --force=true
oc adm drain odf-1.devqa-kcln.ocp.hq.example.co.id --ignore-daemonsets --delete-local-data --force --disable-eviction
oc adm drain odf-1.devqa-kcln.ocp.hq.example.co.id --ignore-daemonsets --delete-emptydir-data --force --disable-eviction
Step selanjutnya melakukan debugging node lalu di lanjut step restart melalui pods debug yang kita buat.
# oc debug node/odf-1.devqa-kcln.ocp.hq.example.co.id
# chroot /host
# systemctl reboot
Setelah melakukan reboot, tunggu hingga node odf bersangkutan naik.
watch 'oc get nodes | grep odf-1.devqa-kcln.ocp.hq.example.co.id'
[root@bastion ~]# oc get no
NAME STATUS ROLES AGE VERSION
csworker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-3.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
infra-1.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-2.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-3.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
master-1.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-2.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-3.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
odf-1.devqa-kcln.ocp.hq.example.co.id NotReady,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
odf-2.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
odf-3.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
worker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
worker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
Pastikan odf node menjadi Ready.
odf-1.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
Tunggu 5–10 menit, agar system melakukan preparation. Jika dirasa sudah ready lakukan uncordon pada node.
oc adm uncordon odf-1.devqa-kcln.ocp.hq.example.co.id
oc get deployment -n openshift-storage
oc get pods -o wide -n openshift-storage | grep odf-1.devqa-kcln.ocp.hq.example.co.id | egrep 'osd|mon'
Step selanjutnya kita perlu melakukan scaling up, pada pods yang sebelum nya kita scalling down.
oc scale deployment rook-ceph-mon-a --replicas=1 -n openshift-storage
oc scale deployment rook-ceph-osd-1 --replicas=1 -n openshift-storage
[root@bastion ~]# oc get no
NAME STATUS ROLES AGE VERSION
csworker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
csworker-3.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
infra-1.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-2.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
infra-3.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
master-1.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-2.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
master-3.devqa-kcln.ocp.hq.example.co.id Ready master 156d v1.23.12+a57ef08
odf-1.devqa-kcln.ocp.hq.example.co.id Ready infra,worker 156d v1.23.12+a57ef08
odf-2.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
odf-3.devqa-kcln.ocp.hq.example.co.id Ready,SchedulingDisabled infra,worker 156d v1.23.12+a57ef08
worker-1.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
worker-2.devqa-kcln.ocp.hq.example.co.id Ready worker 156d v1.23.12+a57ef08
Lakukan pengecekan apakah sudah ada pods yang di schedule kedalam node odf-1.
oc get pods -A --field-selector=spec.host=<node-name>
[root@bastion ~]# oc get pods -A --field-selector=spec.host=odf-1.devqa-kcln.ocp.hq.example.co.id
NAMESPACE NAME READY STATUS RESTARTS AGE
openshift-cluster-node-tuning-operator tuned-mccvk 1/1 Running 2 2d9h
openshift-dns dns-default-mvvbd 2/2 Running 4 2d9h
openshift-dns node-resolver-rks7p 1/1 Running 2 2d9h
openshift-image-registry node-ca-plvw4 1/1 Running 2 2d9h
openshift-ingress-canary ingress-canary-7b49b 1/1 Running 2 2d10h
openshift-ingress router-default-56454b67b9-4hbmm 1/1 Running 0 13h
openshift-local-storage diskmaker-discovery-dsm7n 2/2 Running 4 2d13h
openshift-local-storage diskmaker-manager-z9mzx 2/2 Running 4 2d13h
openshift-machine-config-operator machine-config-daemon-mbf7t 2/2 Running 4 2d9h
openshift-monitoring node-exporter-tk5w9 2/2 Running 4 2d9h
openshift-multus multus-additional-cni-plugins-h2tw9 1/1 Running 2 2d9h
openshift-multus multus-xc666 1/1 Running 2 2d9h
openshift-multus network-metrics-daemon-md4jz 2/2 Running 4 2d9h
openshift-network-diagnostics network-check-target-cp2zj 1/1 Running 2 2d9h
openshift-sdn sdn-rqzbs 2/2 Running 4 2d9h
openshift-storage csi-cephfsplugin-tw5cp 2/2 Running 6 36d
openshift-storage csi-rbdplugin-cfgcn 3/3 Running 9 36d
openshift-storage noobaa-core-0 1/1 Running 0 13h
openshift-storage noobaa-db-pg-0 1/1 Running 0 13h
openshift-storage noobaa-endpoint-6c4bc67dd5-svkjg 1/1 Running 0 13h
openshift-storage rook-ceph-crashcollector-odf-1.devqa-kcln.ocp.hq.example.co.idnnxr8 1/1 Running 0 13h
openshift-storage rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-8689df6ckqg5t 2/2 Running 0 13h
openshift-storage rook-ceph-mon-c-668cf79bd4-c5z5n 2/2 Running 0 13h
openshift-storage rook-ceph-osd-3-6b546f65bf-spq4c 2/2 Running 0 13h
Di titik ini odf-1.devqa-kcln.ocp.hq.example.co.id sudah dalam keadaan normal dan system sudah bisa melakukan scheduling kedalam odf-1.
Kalian tinggal melakukan step yang sama untuk me restart odf node yang lain.
Langkah lanjutan yang perlu juga di perhatikan adalah pengecekan quorum. Dari bastion server jalankan command di bawah ini.
oc rsh -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-operator)
sh-4.4$ export CEPH_ARGS='-c /var/lib/rook/openshift-storage/openshift-storage.config'
sh-4.4$ ceph -s
cluster:
id: 29ef8d78-adcd-44e6-9fca-ecf177afad6f
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c (age 13m)
mgr: a(active, since 2h)
mds: 1/1 daemons up, 1 hot standby
osd: 4 osds: 3 up (since 15m), 3 in (since 15m)
rgw: 1 daemon active (1 hosts, 1 zones)
data:
volumes: 1/1 healthy
pools: 11 pools, 177 pgs
objects: 34.07k objects, 12 GiB
usage: 35 GiB used, 1.4 TiB / 1.5 TiB avail
pgs: 177 active+clean
io:
client: 17 KiB/s rd, 168 KiB/s wr, 6 op/s rd, 14 op/s wr
Sebelum nya saya sudah menyinggung soal quorum, part yang perlu di perhatikan adalah harus adanya 3 quorum dalam satu cluster ceph agar status nya HEALTH_OK.
mon: 3 daemons, quorum a,b,c (age 13m)
Saat salah satu ceph daemon tidak berjalan dengan proper, status dari ceph akan berubah seperti ini dan status nya akan HEALTH_WARN.
sh-4.4$ ceph -s
cluster:
id: 29ef8d78-adcd-44e6-9fca-ecf177afad6f
health: HEALTH_WARN
1/3 mons down, quorum a,b
services:
mon: 3 daemons, quorum a,b (age 16m), out of quorum: c
mgr: a(active, since 16m)
mds: 1/1 daemons up, 1 hot standby
osd: 4 osds: 3 up (since 44m), 3 in (since 47h)
rgw: 1 daemon active (1 hosts, 1 zones)
data:
volumes: 1/1 healthy
pools: 11 pools, 177 pgs
objects: 33.95k objects, 11 GiB
usage: 34 GiB used, 1.4 TiB / 1.5 TiB avail
pgs: 177 active+clean
io:
client: 9.2 KiB/s rd, 181 KiB/s wr, 3 op/s rd, 18 op/s wr
Jadi pastikan, untuk melakukan pengecekan odf yang di gunakan, dan setiap odf harus memiliki mon dan osd, dan semua nya berjalan dengan proper.
Link :