🥇Meie käed pole igavuseks: Rooki klastrite taastamine K8s

Meie oleme juba rääkinud, kuidas/miks me Rook'i armastame: see muudab Kubernetes klastrite salvestusruumide haldamise märgatavalt lihtsamaks. Siiski, koos selle lihtsusega tuleb ka teatud keerukus. Loodame, et uus materjal aitab paremini mõista neid keerukusi enne, kui need end kuuldavaks teevad.

Ja et lugemine oleks huvitavam, alustame tagajärgedest hüpoteetilises probleemis klastris.

„Kõik on kadunud!”

Kujutage ette, et olete kunagi seadistanud ja käivitanud Rook'i oma K8s klastris, see on töötanud hästi, kuid mingil

hetkel ei suuda uued pod'id Ceph'ist RBD-pilte mountida.
Käsklused nagu lsblk ja df ei tööta Kubernetes node'idel. See tähendab automaatselt: „midagi on valesti” mountitud RBD-piltidega node'ides. Neid ei õnnestu lugeda, mis viitab monitoride puudumisele...
Jah, klastris ei ole töövalmis monitore. Veelgi enam - ei ole isegi OSD pod'e ega MGR pod'i.

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

käivitatud oli,

Hakkame juurdlema pikema ja huvitavama tee kaudu, uurides Rook'i „sisemisi” ja taastades selle komponente samm-sammult. Loomulikult on ka lühem õige tee: varukoopiate kasutamine. Nagu öeldakse, jagunevad administraatorid kaheks: need, kes ei tee varukoopiaid, ja need, kes juba teevad... Kuid sellest rääkime hiljem.

Veidi praktikat või Pikem tee

Vaadata ja taastada monitorid Nii et vaatame ConfigMap'ide nimekirja: seal on vajalikud varundamiseks ja rook-ceph-configrook-config-override

NB. Need ilmuvad, kui klastrite juurutamine on eduka. : Uutes versioonides, pärastselle PR'i

, ei ole ConfigMap'id klastrite juurutamise edukuse näitaja.Edasi liikuda, vajame kõigi serverite tugevdatud taaskäivitamist, kus on mountitud RBD-pildid (ls /dev/rbd*

). See tuleb teha sysrq kaudu (või

„jalgsi” andmekeskuses). See nõue tuleneb vajadusest eraldada mountitud RBD-d, mille jaoks tavapärane taaskäivitamine ei sobi (proovides neid normaalselt eemaldada, ebaõnnestub).

Mahud: 
 rook-ceph-config: 
   Tüüp:      ConfigMap (mahud, mille täidab ConfigMap) 
   Nimi:      rook-ceph-config 
 rook-ceph-mons-keyring: 
   Tüüp:        Salajane (mahud, mille täidab Salajane) 
   SalajaneNimi:  rook-ceph-mons-keyring 
 rook-ceph-log: 
   Tüüp:          HostPath (puhtad host-directory mahud) 
   Tee:          /var/lib/rook/kube-rook/log 
 ceph-daemon-data: 
   Tüüp:          HostPath (puhtad host-directory mahud) 
   Tee:          /var/lib/rook/mon-a/data 
Paigaldused: 
  /etc/ceph rook-ceph-config'ist (ro) 
  /etc/ceph/keyring-store'ist rook-ceph-mons-keyring'ist (ro) 
  /var/lib/ceph/mon/ceph-a'st ceph-daemon-data'st (rw) 
  /var/log/ceph'ist rook-ceph-log'ist (rw)

Vaadake, mis on salajas! rook-ceph-mons-keyring:

tüüp: Salajane
data: 
 keyring: PikkBase64KodeeritudString=

Dekodeerime ja saame tavalise keyring'i, mille õigused on administraatorile ja monitoridele:

[mon.]
       võti = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       õigused mon = "luba *"
[client.admin]
       võti = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       õigused mds = "luba *"
       õigused mon = "luba *"
       õigused osd = "luba *"
       õigused mgr = "luba *"

Pidagem meeles. Aga nüüd vaatame keyring'i salajas. rook-ceph-admin-keyring:

tüüp: Salajane
data: 
 keyring: anotherBase64KodeeritudString=

Mis seal on?

[client.admin]
       võti = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       õigused mds = "luba *"
       õigused mon = "luba *"
       õigused osd = "luba *"
       õigused mgr = "luba *"

Sama. Vaatame veel... Näiteks salajane rook-ceph-mgr-a-keyring:

[mgr.a]
       võti = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       õigused mon = "luba *"
       õigused mds = "luba *"
       õigused osd = "luba *"

Lõpuks leiame veel mõningaid saladusi ConfigMap'ist rook-ceph-mon:

tüüp: Salajane
data: 
 admin-saladus: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-saladus: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

Ja see on algne nimekiri keyring'idest, mille kaudu kõik ülaltoodud saladused saadakse.

Nagu teada (vt. dataDirHostPath ja dokumentatsioon), Rook salvestab selliseid andmeid kahes kohas. Niisiis, minge sõlmedesse, et vaadata keyring'e, mis asuvad kataloogides, mis on paigaldatud pod'idesse koos monitoride ja OSD-ega. Selleks leidke sõlmedelt /var/lib/rook/mon-a/data/keyring ja näeme:

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

Üllatuslikult oli seal saladus hoopis teine — mitte kuten ConfigMap'ides.

Kuidas on administraatori keyring'iga? Seda on meil ka:

# 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 *"

Siit tuleb probleem. Toimus mingi tõrge: klaster loodi uuesti... aga tegelikult ei.

Saame aru, et saladustesse on salvestatud uuesti genereeritud keyring'id, ja need ei on meie vanast klastrist. Seetõttu:

võtame monitori keyring'i failist /var/lib/rook/mon-a/data/keyring (kas või varukoopiast);
muudame keyring'i salajas rook-ceph-mons-keyring;
märkige administraatori ja monitori keyring ConfigMap'isse rook-ceph-mon;
kustutame monitoridega pod'ide kontrollijad.

Imet ei pea kaua ootama: monitorid ilmuvad ja käivituvad. Hooray, algus on tehtud!

Taastame OSD

Sisenege pod'isse rook-operator: kutse ceph mon dump näitab, et kõik monitorid on kohal, ja ceph -s — asja, et need on kvoorumis. Kui vaadata OSD puu (ceph osd tree), näeme seal midagi kummalist: OSD-d hakkasid ilmuma, kuid need on tühjad. Tundub, et need tuleb kuidagi taastada. Kuidas aga?

Samas on ConfigMap-idesse ilmunud meile vajalikud Nii et vaatame ConfigMap'ide nimekirja: seal on vajalikud varundamiseks ja rook-ceph-config, samuti palju teisi ConfigMap-e, mille nimed on kujul rook-ceph-osd-$nodename-config. Vaatame neid:

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

Käik on vale, kõik on segamini!

Skaleerime Rook operaatori pod'i nulli, kustutame genereeritud OSD pod'ide Deployment'id ja parandame need ConfigMap-id. Kuid kust saada õige OSD kaardi sõlmedest?

Proovime jälle kaevata kataloogidesse /mnt/osd[1-2] sõlmedes — lootuses, et saame seal millegagi kinni haarata.
Kataloogis /mnt/osd1 on 2 alamkatalooge: osd0 ja osd16. Viimane - see on ju just see ID, mis on märgitud ConfigMap-is (16)?
Kontrollime mõõtmeid ja näeme, et osd0 see on palju suurem osd16.

Jõuame järeldusele, et osd0 — see on vajalik OSD, mis on märgitud kui /mnt/osd1 ConfigMap-is (sest kasutame directory based osd.)

Käime samm-sammult kõik sõlmed üle ja parandame ConfigMap-id. Pärast kõiki juhiseid saame Rook operaatori pod'i käivitada ja lugeda tema logisid. Ning seal on kõik suurepärane:

ma olen klastrite operaator;
ma leidsin sõlmedelt kettad;
ma leidsin monitorid;
monitorid said omavahel toime, st moodustasid kvoorumi;
ma käivitame OSD-de jaotised...

Siseneme taas Rook operaatori pod'i ja kontrollime klasteri elujõudlust... jah, me eksisime mõnede sõlmede OSD nimede järeldustes! Pole hullu: uuesti parandasime ConfigMap-id, kustutasime uute OSD-de üleliigsed kataloogid ja jõudsime kauaoodatud olekusse HEALTH_OK!

Kontrollime kuvasid basseinis:

# 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
…

Kõik on paigas - klaster päästetud!

Ma olen laisk varukoopiaid tegema, või Kiire tee

Kui Rooki jaoks varukoopiaid tehti, muutub taastamisprotsess oluliselt lihtsamaks ja piirdub järgnevaga:

Skaleerime Rook operaatori jaotise nulli;
Kustutame kõik jaotised, välja arvatud Rook operaator;
Taastame kõik salajased ja ConfigMap-id varukoopiatest;
Taastame kataloogide sisu /var/lib/rook/mon-* sõlmedes;
Taastame (kui oleme kaotanud) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Tagasi skaleerime Rook operaatori jaotise 1-ks.

Kasulikud näpunäited

Tehke varukoopiaid!

Ja et vältida olukordi, kus on vaja neist taastada:

Enne ulatuslikke töid klastriga, sealhulgas serverite taaskäivitamisi, skaleerige Rook operaator nulli, et ta ei teeks liigset.
Monitoridele lisage ette nodeAffinity lisage nodeAffinity.
Pöörake tähelepanu eelhäälestusele taimerite seadistamisel ROOK_MON_HEALTHCHECK_INTERVAL ja ROOK_MON_OUT_TIMEOUT.

Lõpetuseks

Ei ole mõtet vaielda, et Rook, olles lisakihiks (Kubernetes'i salvestusorganisatsiooni üldskeemis), lihtsustab palju, kuid toob ka uusi keerukusi ja võimalikke probleeme infrastruktuuris. Valik jääb „väikese“ otsustada: teha tasakaalustatud ja põhjendatud valik nende riskide ja selle kasu vahel, mida otsus teie konkreetses olukorras toob.

Muide, Rooki dokumentatsiooni oli äsja lisatud jaotis „Adopt an existing Rook Ceph cluster into a new Kubernetes cluster“. Seal on üksikasjalikumalt kirjas, mida teha, et eksportida olemasolevad andmed uude Kubernetes'i klastrisse või taastada hajutatud klaster, mis on mingil põhjusel kokku kukkunud.