🥇Meie käed ei ole igav: Rook'i klastrite taastamine K8s

Meie oleme juba rääkinud, kuidas/miks me Rook'ist hoolime: see lihtsustab märkimisväärselt klastrite Kubernetes andmesalvestustega töötamist. Kuid selle lihtsuse kaudu tuleb ka teatud raskusi. Loodame, et uus materjal aitab mõista neid keerukusi juba enne, kui need end ilmutavad.

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

„Kõik on kadunud!”

Kujutage ette, et olete kord seadistanud ja käivitanud Rook'i oma K8s-kliimale, mis on teid oma tööga rõõmustanud, kuid mingil „ilusamal” hetkel juhtub järgmist:

Uued pod'id ei saa Ceph'ist RBD-pilte sisse monteerida.
Käsud nagu lsblk ja df ei tööta Kubernetes'e sõlmedes. See tähendab automaatselt: „midagi on valesti” nendel sõlmedel monteeritud RBD-piltidega. Neid ei saa lugeda, mis viitab monitoride kättesaamatusele...
Jah, klastris pole töötavaid monitore. Veelgi enam — isegi OSD pod'e ega MGR pod'i pole.

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

Alustame pikemat, huvitavat teekonda, tehes põhjaliku uuringu Rook'i „siseelude” kohta ja samm-sammult taastades selle komponente. Loomulikult on olemas ka lühem, õige tee: varukoopiate kasutamine. Nagu teada, jagunevad administraatorid kaheks: need, kes ei tee varukoopiaid, ja need, kes juba teevad... Kuid sellest räägime pärast uurimist.

Veidi praktikat ehk pikk tee

Vaatame ringi ja taastame monitorid

Nii et vaatame ConfigMap'ide nimekirja: sealt leiame vajalikud varukoopiate jaoks rook-ceph-config ja rook-config-override. Need ilmuvad klastrit edukalt juurutades.

NB: Uutes versioonides, pärast selle PR'i vastuvõtmist , ConfigMap'id ei ole enam klastrite juurutamise edukuse näitajad.Eelseisvate toimingute jaoks on meil vaja kõigi serverite kõvaketast taaskäivitada, kus on monteeritud RBD-pildid (

ls /dev/rbd*). See tuleb läbi viia sysrq kaudu (või „jalgsi” andmekeskusesse). See nõue tuleneb vajadusest lahti ühendada monteeritud RBD, mille jaoks tavaline taaskäivitamine ei sobi (proovitakse neid normaalselt lahti monteerida, mis ei õnnestu).Teater algab nagist, Ceph-klaster aga monitoredega. Vaatame neid.

Rook monteerib monitori pod'i järgmised üksused:

Volumes: rook-ceph-config: Tüüp: ConfigMap (ConfigMap'i poolt täidetud maht) Nimi: rook-ceph-config rook-ceph-mons-keyring: Tüüp: Salajane (salajase poolt täidetud maht) SalajaneNimi: rook-ceph-mons-keyring rook-ceph-log: Tüüp: HostPath (tavaline hosti katalooge maht) Tee: /var/lib/rook/kube-rook/log ceph-daemon-data: Tüüp: HostPath (tavaline hosti katalooge maht) Tee: /var/lib/rook/mon-a/data Montaažid: /etc/ceph rook-ceph-config'ist (ro) /etc/ceph/keyring-store'ist rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a'st ceph-daemon-data (rw) /var/log/ceph'ist rook-ceph-log (rw)

Vaadakem, mis on salajasel

rook-ceph-mons-keyring tüüp: Salajane data: keyring: LongBase64EncodedString=:

Dekodeerime ja saame tavalise keyring'i koos administraatori ja monitoride õigustega:

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

Mäletame. Ja nüüd vaatame keyring'i salajasel

rook-ceph-admin-keyring tüüp: Salajane data: keyring: anotherBase64EncodedString=:

Mis seal on?

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

Sama. Vaadakem veel… Näiteks salajane

rook-ceph-mgr-a-keyring [mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *":

Lõppkokkuvõttes leiame veel mitmeid salajasi ConfigMap'is

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

Ja see on algne nimekiri keyring'idest, kust toodetakse kõik ülaltoodud salajased.

Nagu teada (vt.

), Rook salvestab selliseid andmeid kahte kohta. Seetõttu läheme sõlmedesse uurima keyring'e, mis asuvad kataloogides, mis on monteeritud monitoride ja OSD pod'idega. Selleks leiame sõlmedelt dataDirHostPath ühes dokumentatsioonisja näeme: /var/lib/rook/mon-a/data/keyring Üllatuslikult

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

oli siin salajane midagi muud — mitte nagu ConfigMap'ides. Aga mis meie administraatori keyring'iga? See on meil ka olemas:

Siin ongi probleem. Toimus mingi tõrge: klaster loodi uuesti... aga tegelikult ei.

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

Hakkab selgeks saama, et salajastes on uuesti genereeritud keyring'id, ja need

ei ole meie vanast klastrist. Seetõttu: ei võtame monitori keyring'i failist

(või varukoopiast); /var/lib/rook/mon-a/data/keyring muudame salajas keyring'i
kirjutame administraatori ja monitori keyring'i ConfigMap'i tüüp: Salajane data: keyring: LongBase64EncodedString=;
kustutame monitoride pod'ide kontrollijad. tüüp: Salajane data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==;
Ime ei lase end kaua oodata: monitorid ilmuvad ja hakkavad töötama. Hurraa, algus on pandud!

Taastame OSD

Siseneme pod'i

rook-operator : kutseceph mon dump näitab, et kõik monitorid on kohal, kuid — et nad on kvoorumis. Siiski, kui vaatame OSD puu ( ceph -s — et see, et nad on koosolekul. Kuid kui vaadata OSD puut,ceph osd tree), näeme seal midagi kummalist: OSD-d hakkasid ilmuma, kuid need on tühjad. Tundub, et needki tuleb kuidagi taastada. Aga kuidas?

Vahepeal on ConfigMap'idesse ilmunud meile vajalikke rook-ceph-config ja rook-config-override, samuti palju teisi ConfigMap'e, mille nimed on vormis 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 segi!

Skaleerime Rook-operatori pod'i nulli, kustutame OSD-de pod'ide genereeritud Deployment'id ja parendame neid ConfigMap'e. Aga kust leida õige OSD kaart sõlmede kaupa?

Proovime uuesti kaevata kaustadesse /mnt/osd[1-2] sõlmedes – lootuses, et suudame seal midagi leida.
Kaustas /mnt/osd1 on 2 alakaustat: osd0 ja osd16. Viimane on ju just see ID, mis on määratud ConfigMap'is (16)?
Kontrollime suuruste järgi ja näeme, et osd0 kaugelt rohkem osd16.

Jõuame järeldusele, et osd0 — see ongi vajalik OSD, mis oli määratud kui /mnt/osd1 ConfigMap'is (sest kasutame ju directory based osd.)

Samm-sammult kontrollime kõiki sõlmi ja parandame ConfigMap'e. Pärast kõiki juhiseid saab käivitada Rook-operatori pod'i ja lugeda selle logisid. Ja seal on kõik suurepärane:

mina olen klastrite operaator;
ma leidsin sõlmedel kettad;
ma leidsin monitoorijaid;
monitoorijad sõbrunesid, st moodustasid kvoorumit;
käivitame OSD-de deploymente…

Käime taas Rook-operatori pod'is ja kontrollime klastrite elu… jah, me natuke eksisime OSD nimede osas mõnede sõlmede peal! Pole muret: parandasime taas ConfigMap'e, eemaldasime uute OSD-de üleliigsed kaustad ja jõudsime kauaoodatud olekusse HEALTH_OK!

Kontrollime pilte basseinist:

# 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 kohal — klaster on päästetud!

Mina olen laisk varukoopiate tegemisel, või Kiire tee

Kui Rook'i jaoks olid varukoopiad tehtud, siis taastamisprotsess muutub oluliselt lihtsamaks ja piirdub järgmisega:

Skaleerime Rook-operatori deploymente nulli;
Kustutame kõik deploymendid, välja arvatud Rook-operator;
Taastame kõik saladused ja ConfigMap'id varukoopiast;
Taastame direktorite sisu /var/lib/rook/mon-* sõlmedes;
Taastame (kui kaotame) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Tagasi skaleerime Rook-operatori deploymente 1.

Kasulikud nõuanded

Tehke varukoopiaid!

Ja et vältida olukordi, kus on vajalik taastamine:

Enne ulatuslikke töid klastriga, mis sisaldavad serverite taaskäivitamist, skaleerige Rook-operator nulli, et ta ei teeks liigseid toiminguid.
Monitoorijatele eelnevalt lisage nodeAffinity.
Pöörake tähelepanu eelnevale ajaülesannete seadistamisele ROOK_MON_HEALTHCHECK_INTERVAL ja ROOK_MON_OUT_TIMEOUT.

Kokkuvõtte asemel

Ei ole mõtet vaielda, et Rook, olles täiendav "vahekiht" (Kubernetesi salvestustehnoloogia üldises skeemis), lihtsustab paljusid asju, kuid toob endaga kaasa ka uusi keerukusi ja potentsiaalseid probleeme infrastruktuuris. Asi jääb "väikese" taha: teha kaalutletud, põhjendatud valik nende riskide vahel ühel pool ja selle kasu vahel, mida lahendus toob teie konkreetses olukorras — teiselt poolt.

Muide, hiljuti lisati Rook'i dokumentatsiooni peatükk «Adopt an existing Rook Ceph cluster into a new Kubernetes cluster». Seal on üksikasjalikult kirjeldatud, mida on vaja teha, et kolida olemasolevate andmetega uude Kubernetes klastrisse või taastada klaster, mis on kokku kukkunud mõne või teise põhjuse tõttu. Longhorn, jaotatud salvestus K8s jaoks Rancherilt, on üle antud CNCF