I forbindelse med Rooks voksende popularitet vil jeg gerne fortælle om dens faldgruber og problemer, der venter dig undervejs.
Om mig: Erfaring med ceph administration fra hammer version, community founder i telegram.
For ikke at være ubegrundet vil jeg henvise til indlæg accepteret af Habr (at dømme efter vurderingen) om problemer med ceph. Jeg stødte også på de fleste problemer i disse indlæg. Links til det anvendte materiale findes i slutningen af indlægget.
I indlægget om Rook nævner vi ceph af en grund - Rook er i bund og grund ceph pakket ind i kubernetes, hvilket betyder at den arver alle sine problemer. Lad os starte med ceph-problemer.
Forenkle klyngestyring
En af fordelene ved Rook er den nemme håndtering af ceph gennem kuberentes.
Men ceph indeholder mere end 1000 parametre til konfiguration, mens vi på samme tid gennem tårn kun kan redigere et mindretal af dem.
Eksempel på Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook er placeret som en bekvem måde at installere og opdatere ceph på
Der er ingen problemer med at installere ceph uden Rook - ansible playbook er skrevet på 30 minutter, men der er mange problemer med at opdatere.
Citat fra Kroks indlæg
Eksempel: crush tunables fungerer ikke korrekt efter opdatering fra hummer til juvel
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "ukendt",
"optimal_tunables": 0,
...
}
Men selv inden for mindre versioner er der problemer.
Eksempel: Opdatering 12.2.6, der bringer klyngen i tilstanden helbredsfejl og betinget brudt PG
Vil du ikke opdatere, vente og teste? Men vi ser ud til at bruge Rook for bekvemmeligheden af opdateringer, blandt andet.
Kompleksiteten af disaster recovery cluster i Rook
Eksempel: OSD falder med et udslæt af fejl ved fødderne. Du har mistanke om, at problemet er i en af parametrene i konfigurationen, du vil ændre konfigurationen for en bestemt dæmon, men du kan ikke, fordi du har kubernetes og DaemonSet.
Der er intet alternativ. ceph tell osd.Num injectargs virker ikke - OSD'en lyver.
Svært ved debug
Nogle opsætninger og ydeevnetest kræver tilslutning direkte til dæmonens osd-socket. I tilfælde af Rook skal du først finde den ønskede beholder, derefter gå ind i den, finde værktøjet, der mangler til fejlretning og blive meget ked af det.
Vanskeligheder ved at hæve OSD sekventielt
Eksempel: OSD falder i OOM, rebalance begynder, hvorefter de følgende falder.
Løsning: Hæv OSD'en én ad gangen, vent, indtil den er helt inkluderet i klyngen, og hæv de næste. (Flere detaljer i Ceph-rapporten. Anatomy of a disaster).
I tilfælde af en baremetal-installation udføres dette ganske enkelt i hånden; i tilfælde af Rook og én OSD pr. node er der ingen særlige problemer; problemer med alternativ løft vil opstå, hvis OSD > 1 pr. node.
Selvfølgelig kan de løses, men vi bruger Rook til at forenkle tingene, men få mere kompleksitet.
Vanskeligheder med at vælge grænser for ceph-dæmoner
For en baremetal installation af ceph er det ret nemt at beregne de nødvendige ressourcer til en klynge - der er formler og forskning er tilgængelig. Hvis du bruger en svag CPU, skal du stadig køre nogle ydelsestests for at finde ud af, hvad Numa er, men det er stadig nemmere end Rook.
I tilfældet Rook har du ud over de hukommelsesgrænser, der kan beregnes, spørgsmålet om at sætte en CPU-grænse.
Og her bliver du nødt til at arbejde hårdt med præstationstests. Hvis du sænker grænserne, vil du få en langsom klynge; hvis du indstiller unlim, vil du få aktiv CPU-brug under rebalancering, hvilket vil have en dårlig effekt på dine applikationer i kubernetes.
Netværksproblemer v1
Til ceph anbefales det at bruge et 2x10GB netværk. En til klienttrafik, den anden til ceph-servicebehov (rebalance). Hvis du bor med ceph på baremetal, så er denne opdeling let konfigureret, hvis du bor med Rook, så vil opdelingen efter netværk give dig problemer, på grund af det faktum, at ikke hver klyngekonfiguration tillader dig at fodre to forskellige netværk til poden .
Netværksproblemer v2
Hvis du nægter at adskille netværk, vil ceph-trafik ved rebalancering tilstoppe hele kanalen, og dine applikationer i kubernetes vil bremse eller gå ned. Du kan reducere hastigheden af ceph rebalancering, men så får du på grund af den lange rebalancering en øget risiko for, at den anden node falder ud af klyngen via diske eller OOM, og der er allerede garanteret read only for klyngen.
Lang rebalance - lange påføringsforsinkelser
Citat fra Cephs indlæg. Anatomi af en katastrofe.
Testklyngens ydeevne:
En skriveoperation på 4 KB i størrelse tager 1 ms, ydeevnen er 1000 operationer/sekund i 1 tråd.
En operation på 4 MB (objektstørrelse) tager 22 ms, ydeevnen er 45 operationer/sekund.
Følgelig, når et domæne ud af tre fejler, klyngen er i en forringet tilstand i nogen tid, og halvdelen af de varme objekter er fordelt på tværs af forskellige versioner, vil halvdelen af skriveoperationerne begynde med en tvungen gendannelse.
Vi beregner den tvungne restitutionstid cirka - skriveoperationer til et degraderet objekt.
Først læser vi 4 MB på 22 ms, skriver 22 ms, og derefter på 1 ms skriver vi 4 KB faktiske data. I alt 45 ms pr. skriveoperation til et forringet objekt på en SSD, når standardydelsen var 1 ms - et 45-fold fald i ydeevnen.
Jo højere procentdelen af nedbrudte genstande vi har, jo værre bliver alting.
Det viser sig, at hastigheden af rebalancering er kritisk for den korrekte drift af klyngen.
Specifikke serverindstillinger for ceph
ceph kan kræve specifik værtsindstilling.
Eksempel: sysctl-indstillinger og den samme JumboFrame, nogle af disse indstillinger kan påvirke din nyttelast negativt.
Det reelle behov for Rook er stadig i tvivl
Hvis du er i skyen, har du lagerplads fra din cloududbyder, hvilket er meget mere praktisk.
Hvis du er på dine egne servere, vil det være mere bekvemt at administrere ceph uden kubernetes.
Lejer du servere fra en billig hosting? Så vil du have en masse sjov med netværket, dets forsinkelser og båndbredde, hvilket klart påvirker ceph negativt.
Totalt: Implementering af kuberentes og implementering af storage er forskellige opgaver med forskellige inputs og forskellige løsningsmuligheder – at blande dem betyder, at der foretages en muligvis farlig afvejning af hensyn til den ene eller den anden. Det vil være meget vanskeligt at kombinere disse løsninger selv på designstadiet, og der er stadig en driftsperiode.
Liste over brugt litteratur:
Men du siger Ceph... er han virkelig så god?
Ceph. Anatomi af en katastrofe
Kilde: www.habr.com