Han er ikkje din dRook

Med den økende populariteten til Rook ønsker jeg å snakke om fallgruvene og problemene som venter deg på veien.

Om meg: Erfaring med administrasjon av Ceph siden versjon hammer, grunnlegger av fellesskapet. t.me/ceph_no i Telegram.

For å ikke være ordknapp vil jeg referere til vedtatte Habr (ifølge rangeringen) innlegg om problemer med Ceph. Jeg har også støtt på de fleste problemene som er omtalt i disse innleggene. Henvisninger til brukt materiale kommer på slutten av innlegget.

I innlegget om Rook nevner vi ikke Ceph uten grunn — Rook er i bunn og grunn Ceph pakket inn i Kubernetes og arver derfor alle problemene det har. La oss begynne med Cephs problemer.

Forenkling av klusteradministrasjon.

En av fordelene med Rook er muligheten for å administrere Ceph enkelt gjennom Kubernetes.

Imidlertid inneholder Ceph mer enn 1000 parametere for konfigurasjon, mens vi gjennom Rook bare kan endre en mindre del av dem.

Eksempel på Luminous.
> ceph daemon mon.a config show | wc -l
1401

Rook er posisjonert som en enkel måte å installere og oppdatere Ceph på.
Det er ingen problemer med å installere Ceph uten Rook — en Ansible playbook kan skrives på 30 minutter, men det er mange problemer med oppdateringer.

Sitat fra Krok-innlegget.

Eksempel: feilaktig funksjon av crush tunables etter oppdatering fra Hummer til Jewel.

> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}

Men selv innenfor mindre versjoner kan det oppstå problemer.

Eksempel: Oppdatering 12.2.6 som fører klyngen til en tilstand med health err og betinget ødelagte PG.
ceph.com/releases/v12-2-8-released

Ikke oppdatere, vent og test? Men vi bruker vel Rook også for bekvemmeligheten ved oppdateringer.

Vanskeligheter med katastrofegjenoppretting i Rook.

Eksempel: OSD krasjer med feil som fyller utgangen. Du mistenker at problemet ligger i ett av parameterne i konfigurasjonen, ønsker å endre konfigurasjonen for en bestemt daemon, men kan ikke fordi du har Kubernetes og DaemonSet.

Det finnes ingen alternativ. Ceph tell osd.Num injectargs fungerer ikke — OSD ligger nede.

Vansker med debugging.

For noen innstillinger og ytelsestester er det nødvendig å koble til selve sokkelen til OSD-daemonen. I Rook må du først finne den riktige containeren, deretter gå inn i den, oppdage at nødvendig debug-verktøy mangler og bli veldig skuffet.

Vansker med sekvensiell oppstart av OSD.

Eksempel: OSD krasjer på OOM, rebalansering begynner, deretter krasjer neste.

Løsning: Hev OSD én ad gangen, vent til den er fullt inkludert i klyngen, og deretter heve de neste. (Mer informasjon i rapporten Ceph. Katastrofeanatomi).

I tilfelle av baremetal-installasjoner gjør man dette enkelt manuelt, mens for Rook og én OSD per node er det ikke store problemer; problemer med sekvensiell heving vil oppstå hvis OSD > 1 per node.

Selvfølgelig er de løselige, men vi bruker Rook for forenkling, og ender opp med å komplisere det.

Kompleksiteten ved å finne passende grenser for ceph-demoner.

For baremetal-installasjoner er det ganske enkelt å beregne de nødvendige ressursene for klyngen – formler og forskning finnes. Ved bruk av svake CPU-er vil du fortsatt måtte gjennomføre en rekke ytelsestester, forstå hva Numa er, men det er fortsatt enklere enn i Rook.

I tilfelle av Rook vil du i tillegg til minnegrensene som kan beregnes, møte spørsmålet om CPU-grenser.

Og da må du jobbe med ytelsestester. Ved å sette grensene for lavt, får du en treg klynge; ved å sette dem til ubegrenset får du aktiv CPU-bruk under rebalansering, noe som vil påvirke applikasjonene dine i kubernetes negativt.

Problemer med nettverksinteraksjon v1.

For ceph anbefales det å bruke 2x10gb nettverk. Ett for klienttrafikk, det andre for cephs administrative behov (rebalance). Hvis du kjører ceph på baremetal, kan denne delingen enkelt settes opp; dersom du bruker Rook, vil deling av nettverk skape problemer, siden ikke hver klyngekonfigurasjon tillater at to forskjellige nettverk brukes i pod.

Problemer med nettverksinteraksjon v2.

Hvis du velger å ikke dele nettverk, vil ceph-trafikken under rebalansering fylle hele kanalen, og applikasjonene dine i kubernetes vil bli tregere eller krasje. Det er mulig å redusere rebalancehastigheten til ceph, men da risikerer du at den andre noden faller ut av klyngen på grunn av disker eller OOM, og da har du garanti for read-only på klyngen.

Lang rebalansering – lange nedetider for applikasjonene.

Sitat fra innlegget Ceph. Katastrofeanatomi.

Ytelsen til testklyngen:

En skriving på 4 KByte tar 1 ms, ytelse 1000 operasjoner/sekund i ett spor.

En operasjon på 4 MByte (objektstørrelse) tar 22 ms, ytelse 45 operasjoner/sekund.

Dermed, når én av tre domener svikter, er klyngen i en degredert tilstand i en periode, og halvparten av de varme objektene sprer seg over forskjellige versjoner, vil halvparten av skriveoperasjonene måtte begynne med en tvungen gjenoppretting.

Tiden for tvungen gjenoppretting beregner vi omtrent — skriveoperasjoner til et degredert objekt.

Først leser vi 4 MB på 22 ms, skriver i 22 ms, og deretter skriver vi 4 KB med faktiske data på 1 ms. Totalt er det 45 ms for én skriveoperasjon til et degredert objekt på SSD, når standardytelsen vår var 1 ms — en ytelsesreduksjon på 45 ganger.

Jo høyere prosentandel av degredere objekter vi har, desto verre blir det.

Det viser seg at hastigheten på rebalansering er kritisk viktig for korrekt drift av klyngen.

Spesifikke innstillinger for servere for Ceph

Ceph kan trenge spesifikk tuning av verten.

Eksempel: sysctl-innstillinger og samme JumboFrame, noen av disse innstillingene kan ha en negativ innvirkning på payloadet ditt.

Den reelle nødvendigheten av Rook er fortsatt et spørsmål.

Hvis du er i skyen, har du lagring fra din skyleverandør, noe som er mye mer praktisk.

Hvis du er på dine egne servere, vil administrasjon av Ceph være mer praktisk uten Kubernetes.

Leier du servere fra en slags lavpris hosting? Da venter det mye moro med nettverk, dets forsinkelser og båndbredde, noe som åpenbart påvirker Ceph negativt.

Totalt: Implementering av Kubernetes og implementering av lagring er forskjellige oppgaver med forskjellige inngangsverdier og forskjellige løsningsalternativer — å blande dem betyr å gjøre en potensielt farlig trade-off til fordel for den ene eller den andre. Å kombinere disse løsningene vil være veldig vanskelig selv på designfasen, og det er fortsatt driftsperioden.

Liste over brukt litteratur:

Innlegg #1 Men sier du Ceph… er han så bra?
Innlegg #2 Ceph. Katastrofens anatomi

Kilde: habr.com