🥇Duart tona nuk janë për hidhërim: rikuperimi i klasterit Rook në K8s

Ne vazhduam të flasim, si/psërsëm s’duken Rook: ai lehtynë bënd që puna me depozitë në klasterat Kubernetes të jetë më e lehtë. Megjithatë, me këtë lehtësi vijnë edhe disa vështirësi. Shpresojmë që materialet e reja do të ndihmojnë në kuptimin e këtyre vështirësive para se ato të shfaqen.

Dhe për ta bërë leximin më interesante, le të fillojmë me pasojat e një problemi hipotetik në klaster.

“Gjithçka humbi!”

Imagjinoni se një ditë keni konfiguruar dhe aktivizuar Rook në klasterin tuaj K8s, ai ka funksionuar mirë, por në një çast “të bukur” ndodh kjo:

Pod’ët e rinj nuk mund të montojnë imazhet RBD nga Ceph.
Komanda si lsblk dhe df nuk funksionojnë në njësitë Kubernetes. Kjo automatikisht do të thotë: “diçka nuk shkon” me imazhet RBD të montuara në njësitë. Ato nuk mund të lexohen, që tregon për mungesën e monitorëve…
Po, në klaster nuk ka monitorë funksional. Më tepër — nuk ka as pod’ë me OSD, as pod’ë MGR.

Kur është aktivizuar pod rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Në fillim, le të ndjekim një rrugë më të gjatë dhe interesante, duke kryer një hetim të thellë mbi “brendësitë” e Rook dhe duke rikuperuar komponentët e tij hap pas hapi. Sigurisht, ka një rrugë më të shkurtër të saktë: përdorimi i kopjeve rezervë. Siç dihet, adminët ndahen në dy tipe: ata që nuk bëjnë kopje rezervë dhe ata që tashmë bëjnë… Por për këtë — pas hetimit.

Pak praktikë, ose Rruga e gjatë

Le të shohim dhe rikuperojmë monitorët

Kështu, le të shohim listën e ConfigMap’ëve: aty ka ato të nevojshme për rezervimin rook-ceph-config dhe rook-config-override. Aty janë kur klasteri është shkarkuar me sukses.

NB: Në versionet e reja, pas pranimit këtij PR, ConfigMap’ët nuk janë më tregues i suksesit të shkarkimit të klasterit.

Për të vazhduar me veprimet e tjera, ne kemi nevojë për një ribut të ashpër të të gjitha serverëve ku janë të montuar imazhet RBD (ls /dev/rbd*). Kjo duhet të bëhet përmes sysrq (ose “me këmbë” në Qendrën e të Dhënave). Kjo kërkesë është për shkak të detyrës për të ndarë imazhet e montuara RBD, për të cilat ributi standard nuk do të funksionojë (do të përpiqet të çmontojë ato në mënyrë normale pa sukses).

Teatri fillon me pendë, dhe klasteri Ceph — me monitorët. Le të shohim ata.

Rook monte në pod’in e monitorit këto entitete:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (një volum i populluar nga një ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (një volum i populluar nga një Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (volum direkt të host-it)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (volum direkt të host-it)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph nga rook-ceph-config (ro)
  /etc/ceph/keyring-store/ nga rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a nga ceph-daemon-data (rw)
  /var/log/ceph nga rook-ceph-log (rw)

Le të shohim se çfarë është në sekretin rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Dekodojmë dhe do të marrim një keyring të zakonshëm me të drejta për admin dhe monitorë:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "lejo *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "lejo *"
       caps mon = "lejo *"
       caps osd = "lejo *"
       caps mgr = "lejo *"

Le ta mbajmë mend. Tani le të shohim keyring në sekretin rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Çfarë ka aty?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "lejo *"
       caps mon = "lejo *"
       caps osd = "lejo *"
       caps mgr = "lejo *"

I njëjti. Le të shohim më shumë… Ja, për shembull, sekretin rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "lejo *"
       caps mds = "lejo *"
       caps osd = "lejo *"

Në fund të fundit, gjejmë edhe disa sekrete në ConfigMap’in rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

Dhe kjo është lista fillestare e keyring’ave, nga ku dalin të gjitha sekretet e përmendura më lart.

Siç dihet (shih dataDirHostPath në dokumentacion), Rook i ruan këto të dhëna në dy vende. Prandaj, le të shkojmë tek njësitë, për të parë keyring’ët që ndodhen në katalogët, që janë montuar në pod’ët me monitorë dhe OSD. Për këtë, le të gjejmë në njësitë /var/lib/rook/mon-a/data/keyring dhe të shohim:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Papritur këtu u zbulua një sekret tjetër — ndryshe nga ConfigMap’ët.

Po si qëndron çështja me keyring’in e admin-it? Ai është gjithashtu aty:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Ja dhe problemi. Ka ndodhur një gabim: klasteri është rikrijuar… por në të vërtetë nuk është.

Nuk është e qartë se në sekretet ruhen keyring’ët e rinovuar, dhe ata janë nuk nga klasteri ynë i vjetër. Prandaj:

marrim keyring nga monitori nga skedari /var/lib/rook/mon-a/data/keyring (ose nga kopja rezervë);
modifikojmë keyring në sekret rook-ceph-mons-keyring;
shkruajmë keyring nga admin dhe monitori në ConfigMap rook-ceph-mon;
fshijmë kontrollet e pod’ëve me monitorë.

Mrekullia nuk do të vonojë: monitorët do të shfaqen dhe aktivizohen. Hurra, po fillojmë!

Le të rikuperojmë OSD

Hyr në pod rook-operator: thirrja ceph mon dump tregon se të gjithë monitorët janë në vend, ndërsa ceph -s — tregon se ata janë në kuorum. Megjithatë, nëse shikojmë pemën OSD (ceph osd tree), do të shohim diçka të çuditshme: OSD’ët kanë filluar të shfaqen, por ata janë bosh. Duket se ata gjithashtu duhet të rikuperohen. Por si?

Ndërkohë, ConfigMap-at u shfaqën me ato që na duhen rook-ceph-config dhe rook-config-override, si dhe shumë ConfigMap të tjera me emra të tipit rook-ceph-osd-$nodename-config. Le të shohim në to:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Nuk është ashtu, gjithçka është e konfuzuar!

Të rikuperojmë në zero pod-in e operatorit, të heqim Deployment-at e gjeneruar të pod-ëve me OSD dhe të rregullojmë këto ConfigMap. Por nga e gjejmë hartën e saktë OSD sipas nyjeve?

Të provojmë përsëri të shohim në direktoret /mnt/osd[1-2] në nyje — me shpresë se do të gjejmë diçka për t'u kapur.
Në katalog /mnt/osd1 ka 2 nënkatalogje: osd0 dhe osd16. E fundit — kjo është pikërisht ajo ID që është e dhënë në ConfigMap (16)?
Le t'i kontrollojmë për madhësitë dhe do të shohim se osd0 është shumë më e madhe osd16.

Arrijmë në përfundimin se osd0 — ky është OSD që na nevojitet, i ceku si /mnt/osd1 në ConfigMap (sepse përdorim directory based osd.)

Hapat në vazhdim kontrollevin të gjithë nyjet dhe rregullojmë ConfigMap-at. Pas të gjitha udhëzimeve, mund të nisim pod-in e operatorit Rook dhe të lexojmë log-et e tij. Dhe në to gjithçka është e shkëlqyer:

jam operatori i klasterit;
kam gjetur diskët në nyje;
kam gjetur monitorët;
monitorët u lidhën, dmth. formuan kuorum;
po nis deploymente OSD…

Sërish do të hyjmë në pod-in e operatorit Rook dhe të kontrollojmë gjallërinë e klasterit… po, ishim pak në gabim me përfundimet mbi emrat e OSD në disa nyje! Nuk është problem: e rregulluam përsëri ConfigMap-at, heqëm katalogët e tepërt nga OSD të rinj dhe arritëm në gjendjen e pritur HEALTH_OK!

Të kontrollojmë imazhet në rezervuar:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Gjithçka është në vend — klasteri është shpëtuar!

Unë bëj backup me leni, ose Rruga e Shpejtë

Nëse backup-et për Rook ishin realizuar, procedura e rikuperimit bëhet shumë më e lehtë dhe reduktohet në:

E shkallëzojmë në zero deployment Rook-operatorit;
Heqim të gjitha deploymet, përveç Rook-operatorit;
Rikuperojmë të gjitha secret-et dhe ConfigMap-at nga backup;
Rikuperojmë përmbajtjen e direktoreve /var/lib/rook/mon-* në nyje;
Rikuperojmë (nëse ndodhi të humbasim) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Rikthejmë në shkallë deployment Rook-operatorit në 1.

Këshilla të dobishme

Bëni backup!

Dhe që të shmangim situata ku do të nevojitet rikuperimi nga ato:

Para punëve të mëdha me klasterin, që nënkuptojnë rinisje të serverëve, shkallëzoni në zero Rook-operatorin, që të mos bëjë gjëra të panevojshme.
Për monitorët paraprakisht shtoni nodeAffinity.
Kujdesuni për parainizhimin e kohëve të pritjes ROOK_MON_HEALTHCHECK_INTERVAL dhe ROOK_MON_OUT_TIMEOUT.

Në vend të përfundimit

Nuk ka asnjë kuptim të diskutojmë se Rook, si një "ndërfaqe" shtesë (në diagramin e organizimit të ruajtjeve në Kubernetes), sa e thjeshton kaq shumë, po ashtu shton edhe vështirësi dhe probleme të reja të mundshme në infrastrukturë. Çështja mbetet për të bërë një zgjedhje të arsyeshme dhe të justifikuar midis këtyre rreziqeve nga njëra anë dhe asaj dobie që zgjidhja sjell në rastin tuaj të veçantë, nga ana tjetër.

Ajo që është e re, së fundi në dokumentacionin e Rook u shtua seksioni "Adopt an existing Rook Ceph cluster into a new Kubernetes cluster". Në të përshkruhet më në detaje se çfarë duhet bërë për të kaluar të dhënat ekzistuese në një klaster të ri Kubernetes ose për të rikuperuar funksionimin e klasterit që është prishur për ndonjë arsye.