Naše ruke nisu za dosadu: obnova Rook klastera u K8s

Mi već smo pričali, kako/zbog čega volimo Rook: u značajnoj mjeri olakšava rad s pohranjivanjem u Kubernetes klasterima. Međutim, s ovom lakoćom dolaze i određene poteškoće. Nadamo se da će novi materijal pomoći bolje razumjeti te poteškoće prije nego se pojave.

A kako bismo čitanje učinili zanimljivijim, započet ćemo s posljedicama hipotetskog problema u klasteru.

«Sve je izgubljeno!»

Zamislite da ste jednom konfigurirali i pokrenuli Rook u svom K8s klasteru, bio je dobar u svom radu, no u nekom „predivnom“ trenutku događa se sljedeće:

• Novi podovi ne mogu montirati RBD slike iz Ceph-a.
• Komande kao što su lsblk i df ne rade na Kubernetes čvorovima. To automatski znači: „nešto nije u redu“ s montiranim RBD slikama. Ne mogu se pročitati, što ukazuje na nedostupnost monitora…
• Da, u klasteru nema radnih monitora. Štoviše — nema ni podova s OSD-ima, niti poda MGR.

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

Za početak, idemo dužim zanimljivim putem, provodeći pažljivo istraživanje unutar Rooka i korak po korak obnavljajući njegove komponente. Naravno, postoji i kraći ispravan put: korištenje sigurnosnih kopija. Kao što je poznato, administratori se dijele na dva tipa: one koji ne rade sigurnosne kopije i one koji ih već rade… Ali o tome — nakon istraživanja.

Malo prakse, ili Dugi put

Pogledajmo i obnovimo monitore

Dakle, pogledajmo popis ConfigMap-a: tu su potrebni za rezervaciju rook-ceph-config i rook-config-override. Oni se pojavljuju prilikom uspješnog deployanja klastera.

NB: U novim verzijama, nakon prihvaćanja ovog PR-a, ConfigMap-i više nisu pokazatelj uspješnosti deployanja klastera.

Za daljnje radnje potrebno nam je tvrdo ponovno pokretanje svih servera koji imaju montirane RBD slike (ls /dev/rbd*). To treba provesti putem sysrq (ili „pješice“ u data centar). Ovaj zahtjev proizašao je iz potrebe za odspojivanjem montiranih RBD, za što standardno ponovno pokretanje nije prikladno (neće uspjeti normalno odspojiti).

Kazalište počinje s vješalicom, a Ceph klaster — s monitorima. Pogledajmo ih.

Rook montira u pod monitora ovakve entitete:

Volumeni:
 rook-ceph-config:
   Tip:      ConfigMap (volumen koji puni ConfigMap)
   Ime:      rook-ceph-config
 rook-ceph-mons-keyring:
   Tip:        Tajna (volumen koji puni Tajna)
   TajnaIme:  rook-ceph-mons-keyring
 rook-ceph-log:
   Tip:          HostPath (volumen direktorija domaćina)
   Putanja:      /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Tip:          HostPath (volumen direktorija domaćina)
   Putanja:      /var/lib/rook/mon-a/data
Montiranje:
  /etc/ceph iz rook-ceph-config (ro)
  /etc/ceph/keyring-store/ iz rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a iz ceph-daemon-data (rw)
  /var/log/ceph iz rook-ceph-log (rw)

Pogledajmo što je u tajni rook-ceph-mons-keyring:

vrsta: Tajna
data:
 keyring: LongBase64EncodedString=

Dekodiramo i dobijamo obični keyring s pravima za admina i monitore:

[mon.]
       ključ = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       privilegije mon = "dozvoli *"
[client.admin]
       ključ = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       privilegije mds = "dozvoli *"
       privilegije mon = "dozvoli *"
       privilegije osd = "dozvoli *"
       privilegije mgr = "dozvoli *"

Zapamtimo. A sada pogledajmo keyring u tajni rook-ceph-admin-keyring:

vrsta: Tajna
data:
 keyring: anotherBase64EncodedString=

Što je u njemu?

[client.admin]
       ključ = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       privilegije mds = "dozvoli *"
       privilegije mon = "dozvoli *"
       privilegije osd = "dozvoli *"
       privilegije mgr = "dozvoli *"

Isti. Pogledajmo još… Evo, na primjer, tajna rook-ceph-mgr-a-keyring:

[mgr.a]
       ključ = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       privilegije mon = "dozvoli *"
       privilegije mds = "dozvoli *"
       privilegije osd = "dozvoli *"

Na kraju nalazimo još nekoliko tajni u ConfigMapu rook-ceph-mon:

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

I ovo je izvorni popis s keyring-ima, odakle dolaze sve opisane više tajne.

Kao što je poznato (vidi dataDirHostPath u dokumentaciju), Rook pohranjuje takve podatke na dva mjesta. Zato idemo na čvorove da bismo pogledali keyring-e koji se nalaze u direktorijima koji su montirani u pod-ove s monitorima i OSD-ima. Da to učinimo, pronađimo na čvorovima /var/lib/rook/mon-a/data/keyring i vidimo:

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

Iznenada ovdje se tajna pokazala drugačijom — ne kao u ConfigMap-ima.

A što se tiče adminsog keyring-a? I on se nalazi:

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

Evo tu je problem. Došlo je do nekakvog kvara: klaster se ponovno stvorio… ali zapravo nije.

Postaje jasno da se u tajnama čuvaju ponovo generirani keyring-i, i oni ne su iz našeg starog klastera. Stoga:

• uzimamo keyring od monitora iz datoteke /var/lib/rook/mon-a/data/keyring (ili iz sigurnosne kopije);
• mijenjamo keyring u tajni rook-ceph-mons-keyring;
• upisujemo keyring od admina i monitora u ConfigMapu rook-ceph-mon;
• brišemo kontrolere pod-ova s monitorima.

Čudo neće dugo čekati: monitori će se pojaviti i pokrenuti. Ura, početak je postavljen!

Obnovit ćemo OSD

Ulazimo u pod rook-operator: poziv ceph mon dump pokazuje da su svi monitori na mjestu, a ili pokrenuti u zasebnom prozoru terminala — na ono što se odvija u kvorumu. Međutim, ako pogledamo stablo OSD (, trebali bismo vidjeti da na serveru na kojem su izvedeni radovi više nema OSD-a nad kojima su obavljene gornje operacije:), vidjet ćemo nešto neobično: OSD-ovi su počeli pojavljivati, ali su prazni. Ispada da ih također treba nekako obnoviti. Ali kako?

U međuvremenu, u ConfigMap-ovima su se pojavili potrebni rook-ceph-config i rook-config-override, kao i mnogi drugi ConfigMap-ovi s imenima poput rook-ceph-osd-$nodename-config. Pogledajmo u njih:

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

Sve je obrnuto, sve je pomiješano!

Resetirat ćemo pod operatora na nulu, izbrisati generirane Deployment-e podova s OSD-om i ispraviti ove ConfigMap-ove. Ali odakle uzeti ispravnu mapu OSD-a po čvorovima?

• Pokušat ćemo ponovno pretražiti direktorije /mnt/osd[1-2] na čvorovima — u nadi da ćemo se moći za nešto uhvatiti.
• U direktoriju /mnt/osd1 imamo 2 poddirektorija: osd0 i osd16. Posljednji — to je upravo onaj ID koji je naveden u ConfigMap-u (16)?
• Provjerit ćemo po veličinama i vidjeti da osd0 je daleko veći osd16.

Dolazimo do zaključka da osd0 — to je potreban OSD, koji je bio naveden kao /mnt/osd1 u ConfigMap-u (jer koristimo directory based osd.)

Korak po korak provjeravamo sve čvorove i ispravljamo ConfigMap-ove. Nakon svih uputa možemo pokrenuti pod Rook-operatora i pročitati njegove logove. A u njima je sve sjajno:

• ja sam operator klastera;
• pronašao sam diskove na čvorovima;
• pronašao sam monitore;
• monitori su se povezali, tj. formirali kvorum;
• pokrećem deploymente OSD…

Ponovno ćemo ući u pod operatora Rook i provjeriti stanje klastera… da, malo smo pogriješili u zaključcima o imenima OSD-a na nekim čvorovima! Nema veze: ponovno smo ispravili ConfigMap-ove, izbrisali suvišne direktorije od novih OSD-a i došli do dugo očekivanog stanja HEALTH_OK!

Provjerimo slike u bazenu:

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

Sve je na svom mjestu — klaster je spašen!

Ja sam lijen kad radim sigurnosne kopije, ili Brzi put

Ako se sigurnosne kopije za Rook prave, postupak oporavka postaje znatno lakši i svodi se na sljedeće:

1. Skaliramo na nulu deployment Rook-operatora;
2. Brišemo sve deploymente osim Rook-operatora;
3. Obnavljamo sve secret-e i ConfigMap-ove iz sigurnosne kopije;
4. Obnavljamo sadržaj direktorija /var/lib/rook/mon-* na čvorovima;
5. Obnavljamo (ako smo slučajno izgubili) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Ponovno skaliramo deployment Rook-operatora na 1.

Korisni savjeti

Radite sigurnosne kopije!

A kako biste izbjegli situacije kada vam bude trebala oporavka iz njih:

1. Prije velikih radova s klasterom koji uključuju restartanje servera, skalirajte na nulu Rook-operatora kako ne bi radio suvišne operacije.
2. Na monitore unaprijed dodajte nodeAffinity.
3. Obratite pažnju na prethodno postavljanje vremenskih ograničenja ROOK_MON_HEALTHCHECK_INTERVAL i ROOK_MON_OUT_TIMEOUT.

Umjesto zaključka

Nema smisla raspravljati da Rook, kao dodatni "sloj" (u općoj shemi organizacije skladišta u Kubernetesu), pojednostavljuje mnoge stvari, ali također donosi nove komplikacije i potencijalne probleme u infrastrukturi. Na vama je da donesete promišljen, opravdan izbor između tih rizika s jedne strane i koristi koju rješenje donosi u vašem konkretnom slučaju s druge.

Usput, nedavno je u dokumentaciju Rook dodana sekcija "Prilagodite postojeći Rook Ceph klaster novom Kubernetes klasteru". U njoj je detaljnije objašnjeno što treba učiniti kako biste prenijeli postojeće podatke u novi Kubernetes klaster ili kao da obnovite rad klastera koji je propao iz raznih razloga.

P.S.

Pročitajte i na našem blogu:

• «Rook ili ne Rook - to je pitanje»;
• «Rook - „samoosigurano“ skladište podataka za Kubernetes»;
• «Longhorn, distribuirano skladište za K8s od Ranchera, predano je CNCF-u».
• «Stvaramo trajno skladište s provisioningom u Kubernetesu na bazi Ceph-a».

Izvor: habr.com