Våra händer är inte till för att vara sysslolösa: återställning av Rook-kluster i K8s

Vi redan har diskuterat, hur/varför vi gillar Rook: det förenklar avsevärt arbetet med lagringslösningar i Kubernetes-kluster. Men med denna enkelhet följer också vissa svårigheter. Vi hoppas att det nya materialet hjälper till att bättre förstå dessa svårigheter innan de uppstår.

För att göra läsningen mer intressant, låt oss börja med konsekvenser av den hypotetiska problematiken i klustret.

„Allt är förlorat!"

Tänk dig att du en dag har konfigurerat och startat Rook i ditt K8s-kluster, och den fungerar som den ska, men vid något "underbart" ögonblick händer följande:

• Nya poddar kan inte montera RBD-bilder från Ceph.
• Kommandon som lsblk och df fungerar inte på Kubernetes-noder. Detta innebär automatiskt: "något är fel" med de monterade RBD-bilderna. De kan inte läsas, vilket tyder på att monitorerna är otillgängliga...
• Ja, det finns inga fungerande monitorer i klustret. Dessutom finns det inte ens några poddar med OSD eller en podd MGR.

När podden startades : bland de betydande förändringarna i Rook 1.0.0 relaterade till Ceph, kan man notera stödet för Ceph Nautilus och möjligheten att använda NFS för CephFS- eller RGW-behållare. Bland annat framhävs "mognaden" av stödet för EdgeFS till beta-nivå.? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Först ska vi ta en mer intressant och lång väg, och göra en noggrann utredning av Rooks "inuti" och steg-för-steg återställning av dess komponenter. Självklart finns det en kortare och mera korrekt väg: att använda säkerhetskopior. Som bekant delas administratörer in i två typer: de som inte gör säkerhetskopior och de som redan gör dem... Men mer om det efter utredningen.

Lite praktik, eller den långa vägen

Låt oss titta på och återställa monitorerna

Så vi ser på listan över ConfigMap:ar: där finns de som behövs för säkerhetskopiering rook-ceph-config och rook-config-override. De visas vid en lyckad deployment av klustret.

NB: I nya versioner, efter antagandet av denna PR, har ConfigMap:ar slutat vara en indikator på framgångsrik distribution av klustret.

För att fortsätta med våra åtgärder behöver vi en hård omstart av alla servrar där monterade RBD-bilder finns (ls /dev/rbd*). Det måste göras via sysrq (eller "till fots" i datacentret). Detta krav beror på behovet av att avmontera de monterade RBD-bilderna, vilket en vanlig omstart inte går att använda för (det skulle bli misslyckat att försöka avmontera dem på ett normalt sätt).

Teatern börjar med klädhängaren och Ceph-klustret med monitorerna. Låt oss titta på dem.

Rook monterar sådana entiteter i monitorpodden:

Volymer:
 rook-ceph-config:
   Typ:      ConfigMap (ett volym som fylls med en ConfigMap)
   Namn:      rook-ceph-config
 rook-ceph-mons-keyring:
   Typ:        Secret (ett volym som fylls med en Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Typ:          HostPath (ren värd katalog volym)
   Sökväg:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Typ:          HostPath (ren värd katalog volym)
   Sökväg:          /var/lib/rook/mon-a/data
Monteringar:
  /etc/ceph från rook-ceph-config (ro)
  /etc/ceph/keyring-store/ från rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a från ceph-daemon-data (rw)
  /var/log/ceph från rook-ceph-log (rw)

Låt oss se vad som finns i hemligheten rook-ceph-mons-keyring:

typ: Secret
data:
 keyring: LongBase64EncodedString=

Vi dekodar och får en vanlig keyring med rättigheter för administratören och monitorerna:

[mon.]
       nyckel = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       rättigheter mon = "allow *"
[client.admin]
       nyckel = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       rättigheter mds = "allow *"
       rättigheter mon = "allow *"
       rättigheter osd = "allow *"
       rättigheter mgr = "allow *"

Kom ihåg det. Låt oss nu titta på keyring i hemligheten rook-ceph-admin-keyring:

typ: Secret
data:
 keyring: anotherBase64EncodedString=

Vad finns i den?

[client.admin]
       nyckel = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       rättigheter mds = "allow *"
       rättigheter mon = "allow *"
       rättigheter osd = "allow *"
       rättigheter mgr = "allow *"

Samma. Låt oss titta vidare… Här är till exempel en hemlighet rook-ceph-mgr-a-keyring:

[mgr.a]
       nyckel = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       rättigheter mon = "allow *"
       rättigheter mds = "allow *"
       rättigheter osd = "allow *"

Till slut hittar vi ytterligare några hemligheter i ConfigMap: rook-ceph-mon:

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

Och detta är den ursprungliga listan med keyringar, därifrån alla ovan nämnda hemligheter hämtas.

Som bekant (se dataDirHostPath på dokumentationen), lagrar Rook sådana data på två ställen. Så låt oss gå till noderna för att se keyringarna som ligger i katalogerna som är monterade i pods med monitorer och OSD. För detta ändamål finner vi på noder /var/lib/rook/mon-a/data/keyring och ser:

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

Överraskande nog visade sig den här hemligheten vara en annan — inte som i ConfigMap.

Men vad sägs om admin keyring? Den finns också hos oss:

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

Här ligger problemet. Det inträffade ett slags fel: klustret återskapades… men i själva verket finns det inte.

Det blir tydligt att hemligheterna lagrar nyligen genererade keyringar, och de inte är från vårt gamla kluster. Därför:

• tar vi keyringen från monitorn från filen /var/lib/rook/mon-a/data/keyring (eller från en backup);
• ändrar keyringen i hemligheten rook-ceph-mons-keyring;
• angiver keyringen från admin och monitor i ConfigMap rook-ceph-mon;
• tar bort controllrarna för pods med monitorerna.

Ett mirakel låter inte vänta på sig: monitorerna kommer att dyka upp och starta. Hurra, det är en början!

Låt oss återställa OSD

Vi går in i podden rook-operator: anropar ceph mon dump visar att alla monitorer är på plats, och ceph -s — på att de är i quorum. Men om vi ser på OSD-trädet (root@ceph01-q:~# ceph osd tree), kommer vi att se något konstigt: OSD:erna började dyka upp, men de är tomma. Det verkar som att vi också måste återställa dem på något sätt. Men hur?

Under tiden har det dykt upp de ConfigMap:ar som vi verkligen behöver rook-ceph-config och rook-config-override, samt många andra ConfigMap:ar med namn som rook-ceph-osd-$nodename-config. Låt oss ta en titt på dem:

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

Det är inte rätt, allt är blandat!

Vi ska skala ner operatörens pod till noll, ta bort de genererade Deployment:erna av OSD-poddarna och fixa dessa ConfigMap:ar. Men var ska vi få den korrekta OSD-kartan per noder?

• Låt oss försöka gräva igenom mapparna /mnt/osd[1-2] på noderna — i hopp om att vi kan få något där.
• I kataloget /mnt/osd1 det finns 2 underkataloger: osd0 och osd16. Sista — det är ju precis den ID som anges i ConfigMap (16)?
• Vi kontrollerar storlekarna och ser att osd0 mycket större osd16.

Vi kommer fram till att osd0 — det är den OSD som angavs som /mnt/osd1 i ConfigMap (eftersom vi använder directory based osd.)

Steg för steg kontrollerar vi alla noder och rättar till ConfigMap:arna. Efter alla åtgärder kan vi starta Rook-operatorens pod och läsa dess loggar. Och i dem är allt fantastiskt:

• jag är klusteroperator;
• jag har hittat diskar på noderna;
• jag har hittat monitorer;
• monitorerna har kommit överens, det vill säga bildat quorum;
• jag startar OSD-deployment:er…

Låt oss gå tillbaka till Rook-operatörens pod och kontrollera klustrets hälsa… ja, vi gjorde några små misstag med namnen på OSD på vissa noder! Ingen fara: vi har rättat till ConfigMap:arna, tagit bort onödiga mappar från nya OSD och kommit till det efterlängtade tillståndet HEALTH_OK!

Vi kontrollerar bilderna i poolen:

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

Allt är på plats — klustret är räddat!

Jag är lat med att göra säkerhetskopior, eller Snabb väg

Om säkerhetskopior för Rook gjordes, blir återställningsproceduren betydligt enklare och handlar om följande:

1. Skala ner Rook-operatorens deployment till noll;
2. Ta bort alla deployment:er förutom Rook-operatorn;
3. Återställ alla secret:er och ConfigMap:ar från säkerhetskopian;
4. Återställ innehållet i mapparna /var/lib/rook/mon-* på noderna;
5. Återställ (om vi av misstag har tappat bort dem) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Skala upp Rook-operatorns deployment till 1 igen.

Nyttiga tips

Gör säkerhetskopior!

Och för att undvika situationer där återställning kan behövas:

1. Innan stora arbeten med klustret, som innebär omstart av servrar, skala ner Rook-operatorn till noll så att den inte gör något överflödigt.
2. Till monitorerna i förväg lägg till nodeAffinity.
3. Ge uppmärksamhet åt den preliminära konfigurera tidsgränser ROOK_MON_HEALTHCHECK_INTERVAL och ROOK_MON_OUT_TIMEOUT.

Avslutande

Det är meningslöst att diskutera att Rook, som en extra "skikt" (i den övergripande strukturen för lagringsorganisation i Kubernetes), både förenklar mycket men också tillför nya komplexiteter och potentiella problem i infrastrukturen. Frågan kvarstår att göra ett väl avvägt och motiverat val mellan dessa risker å ena sidan och den nytta som lösningen ger i just ditt fall å andra sidan.

För övrigt, nyligen i Rook-dokumentationen lades till avsnittet "Adopt an existing Rook Ceph cluster into a new Kubernetes cluster". Här beskrivs mer i detalj vad som behöver göras för att flytta befintlig data till en ny Kubernetes-kluster eller återställa funktionaliteten i ett kluster som kollapsat av en eller annan anledning.

P.S.

Läs även i vår blogg:

• «Rook eller inte Rook — det är frågan»;
• «Rook — en "självbetjänande" datalagring för Kubernetes»;
• «Longhorn, ett distribuerat lagringssystem för K8s från Rancher, har överlämnats till CNCF».
• «Skapa permanent lagring med provisioning i Kubernetes baserat på Ceph».

Källa: habr.com