I takt med den stigende popularitet af Rook vil jeg gerne tale om de faldgruber og problemer, du kan støde på undervejs.
Om mig: Erfaring med administration af Ceph siden version hammer, grundlægger af fællesskabet på Telegram.
For at underbygge mine påstande vil jeg henvise til de anerkendte Habr (ifølge vurderingen) indlæg om problemer med Ceph. Jeg har også stødt på størstedelen af problemerne i disse indlæg. Links til det anvendte materiale findes i slutningen af indlægget.
I indlægget om Rook nævner vi Ceph ikke uden grund - Rook er i bund og grund Ceph pakket ind i Kubernetes, og det betyder, at det arver alle dets problemer. Lad os starte med problemerne i Ceph.
Forenkling af clusterstyring
En af fordelene ved Rook er den nemme administration af Ceph gennem Kubernetes.
Men Ceph indeholder over 1000 konfigurationsparametre, og gennem Rook kan vi kun ændre en mindre del af dem.
Eksempel på Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook markedsføres som en praktisk måde at installere og opdatere Ceph på
Der er ingen problemer med at installere Ceph uden Rook - en Ansible-playbook kan skrives på 30 minutter, men der er masser af problemer med opdatering.
Citater fra Krok's indlæg
Eksempel: Forkert funktion af Crush-tunables efter opdatering fra Hammer til Jewel
> ceph osd crush show-tunables
{
…
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "unknown",
"optimal_tunables": 0,
…
}
Men selv inden for mindre versioner kan der være problemer.
Eksempel: Opdatering fra 12.2.6 bringer clustret i health err tilstand og betinget beskadiget PG.
Skal vi undlade at opdatere, vente og teste? Men vi bruger jo Rook for nemheden ved opdateringer, blandt andet.
Vanskeligheder ved katastrofegenvinding af clustret i Rook
Eksempel: OSD falder og genererer fejl. Du mistænker, at problemet ligger i en af parametrene i konfigurationen, og du vil ændre konfigurationen for en specifik daemon, men du kan ikke, fordi du har Kubernetes og DaemonSet.
Der er ingen alternativer. ceph tell osd.Num injectargs fungerer ikke - OSD'en er jo nede.
Vanskeligheder ved fejlsøgning
For nogle indstillinger og performance tests er det nødvendigt at tilslutte sig socketen på OSD-daemonen. I Rook skal du først finde den relevante container, derefter logge ind i den, opdage, at den nødvendige fejlsøgningstools mangler, og blive meget skuffet.
Vanskeligheder ved sekventiel opstart af OSD
Eksempel: OSD falder på OOM, rebalance starter, og derefter falder de næste.
Løsning: Aktivér OSD én ad gangen, vent på, at den fuldt integreres i klyngen, og aktivér de næste. (Læs mere i rapporten Ceph. Anatomien af katastrofen).
I tilfælde af en baremetal-installation gøres dette let manuelt; i tilfælde af Rook og én OSD pr. node er der ikke mange problemer, men problemer med sekventiel aktivering opstår, hvis OSD > 1 pr. node.
Selvfølgelig kan de løses, men vi implementerer Rook for at forenkle, og får dermed en kompleksitet.
Kompleksiteten ved at finde grænserne for Ceph-demoner.
For baremetal-installationer er det relativt enkelt at beregne de nødvendige ressourcer til klyngen — der findes formler og forskning. Ved brug af svage CPU'er skal du stadig udføre en række ydeevnetests, finde ud af, hvad Numa er, men det er stadig lettere end i Rook.
I tilfælde af Rook præsenteres der et spørgsmål om at angive CPU-grænser, ud over hukommelsesgrænserne, som kan beregnes.
Her skal du virkelig arbejde med ydeevnetests. Ved at sætte for lave grænser vil du få en langsom klynge, og ved at sætte unlim vil du få aktiv CPU-brug under rebalance, hvilket vil påvirke dine applikationer i Kubernetes negativt.
Netværksinteraktionsproblemer v1
For Ceph anbefales det at bruge et 2x10gb netværk. Ét til klienttrafik, det andet til Ceph's tjenestebehov (rebalance). Hvis du kører Ceph på baremetal, er denne opdeling let at konfigurere; hvis du lever med Rook, vil opdelingen af netværk give dig problemer, da langt fra hver klyngekonfiguration tillader at give to forskellige netværk til en pod.
Netværksinteraktionsproblemer v2
Hvis du vælger ikke at dele netværk, vil Ceph-trafikken under rebalance blokere hele kanalen, og dine applikationer i Kubernetes vil hæmme eller falde. Du kan reducere Ceph's rebalance-hastighed, men det medfører en øget risiko for, at den anden node falder ud af klyngen på grund af diske eller OOM, og der vil derefter være en garanti for read-only på klyngen.
Langsom rebalance — lange nedbrud af applikationer.
Citat fra posten Ceph. Anatomien af katastrofen.
Ydeevne for testklyngen:
En skriveoperation på 4 Kbyte tager 1 ms, ydeevnen er 1000 operationer/sekund i 1 tråd.
En operation på 4 Mbyte (objektstørrelse) tager 22 ms, ydeevnen er 45 operationer/sekund.
Derfor, når en af de tre domæner svigter, vil klyngen i et stykke tid være i en degraderet tilstand, og halvdelen af de varme objekter vil blive fordelt på forskellige versioner, hvilket betyder, at halvdelen af skriveoperationerne vil begynde med et tvunget genoprettelse.
Tiden til tvunget genoprettelse beregnes omtrent — skriveoperationer til det degraderede objekt.
Først læser vi 4 MB på 22 ms, skriver 22 ms, og derefter skriver vi 4 KB reelle data på 1 ms. Samlet set 45 ms pr. skriveoperation til det degraderede objekt på SSD, når vores normale ydelse var 1 ms — et fald i ydelsen på 45 gange.
Jo højere procentdel af degraderede objekter, desto værre bliver det.
Det viser sig, at hastigheden for rebalance er kritisk vigtig for klyngens korrekte funktion.
Specifikke serverindstillinger for Ceph
Ceph kræver nogle gange specifik tuning af værten.
Eksempel: sysctl-indstillinger og den samme JumboFrame, nogle af disse indstillinger kan have negativ indflydelse på dit payload.
Den virkelige nødvendighed af Rook forbliver et spørgsmål.
Hvis du er i skyen, har du lager fra din cloud-udbyder, hvilket er meget mere praktisk.
Hvis du er på dine egne servere, vil håndteringen af Ceph være lettere uden Kubernetes.
Lejer du servere hos en eller anden low-cost hosting? Så venter der dig masser af sjov med netværket, dets latens og båndbredde, hvilket tydeligvis har en negativ indflydelse på Ceph.
I alt: Implementering af Kubernetes og implementering af lager er forskellige opgaver med forskellige forudsætninger og forskellige løsningsmuligheder — at blande dem indebærer potentielt en farlig trade-off til fordel for det ene eller det andet. At kombinere disse løsninger vil være meget vanskeligt selv på planlægningsstadiet, og der er stadig driftsperioden.
Liste over anvendt litteratur:
Men du siger Ceph... er det virkelig så godt?
Ceph. Anatomien af en katastrofe
Kilde: habr.com
