I forbindelse med den økende populariteten til Rook, vil jeg gjerne snakke om fallgruvene og problemene som venter deg underveis.
Om meg: Erfaring med ceph-administrasjon fra hammerversjon, fellesskapsgrunnlegger i telegram.
For ikke å være ubegrunnet vil jeg referere til innlegg akseptert av Habr (etter vurderingen å dømme) om problemer med ceph. Jeg har også støtt på de fleste problemene i disse innleggene. Lenker til materialet som er brukt er på slutten av innlegget.
I innlegget om Rook nevner vi ceph av en grunn - Rook er i hovedsak ceph pakket inn i kubernetes, noe som betyr at den arver alle sine problemer. La oss starte med ceph-problemer.
Forenkle klyngeadministrasjon
En av fordelene med Rook er at det er enkelt å administrere ceph gjennom kuberentes.
Imidlertid inneholder ceph mer enn 1000 parametere for konfigurasjon, samtidig som vi gjennom tårn bare kan redigere et mindretall av dem.
Eksempel på Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook er plassert som en praktisk måte å installere og oppdatere ceph på
Det er ingen problemer med å installere ceph uten Rook - ansible playbook er skrevet på 30 minutter, men det er mange problemer med oppdatering.
Sitat fra Kroks innlegg
Eksempel: crush tunables fungerer ikke riktig etter oppdatering fra hummer til juvel
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "ukjent",
"optimal_tunables": 0,
...
}
Men selv innenfor mindre versjoner er det problemer.
Eksempel: Oppdatering 12.2.6 som bringer klyngen inn i helsefeiltilstanden og betinget ødelagt PG
Ikke oppdater, vent og test? Men vi ser ut til å bruke Rook for bekvemmeligheten av oppdateringer, blant annet.
Kompleksiteten til katastrofegjenopprettingsklyngen i Rook
Eksempel: OSD faller med et utslett av feil ved føttene. Du mistenker at problemet er i en av parameterne i konfigurasjonen, du vil endre konfigurasjonen for en spesifikk demon, men du kan ikke fordi du har kubernetes og DaemonSet.
Det er ikke noe alternativ. ceph tell osd.Num injectargs fungerer ikke - OSD-en lyver.
Problemer med feilsøking
Noen oppsett og ytelsestester krever tilkobling direkte til demonens osd-kontakt. Når det gjelder Rook, må du først finne ønsket container, deretter gå inn i den, finne verktøyet som mangler for feilsøking og bli veldig opprørt.
Vanskeligheter med å øke OSD sekvensielt
Eksempel: OSD faller i OOM, rebalansering begynner, hvoretter de følgende faller.
Løsning: Hev OSD en om gangen, vent til den er helt inkludert i klyngen og hev de neste. (Flere detaljer i Ceph-rapporten. Anatomy of a disaster).
Ved en baremetallinstallasjon gjøres dette ganske enkelt for hånd; for Rook og én OSD per node er det ingen spesielle problemer; problemer med alternativ løfting vil oppstå hvis OSD > 1 per node.
Selvfølgelig kan de løses, men vi bruker Rook for å forenkle ting, men få mer kompleksitet.
Vanskeligheter med å velge grenser for ceph-demoner
For en baremetallinstallasjon av ceph er det ganske enkelt å beregne de nødvendige ressursene for en klynge - det er formler og forskning er tilgjengelig. Hvis du bruker en svak CPU, må du fortsatt kjøre noen ytelsestester for å finne ut hva Numa er, men det er fortsatt enklere enn Rook.
Når det gjelder Rook, har du i tillegg til minnegrensene som kan beregnes spørsmålet om å sette en CPU-grense.
Og her må du jobbe hardt med ytelsestester. Hvis du senker grensene, vil du få en treg klynge; hvis du setter unlim, vil du få aktiv CPU-bruk under rebalansering, noe som vil ha en dårlig effekt på applikasjonene dine i kubernetes.
Nettverksproblemer v1
For ceph anbefales det å bruke et 2x10GB nettverk. En for klienttrafikk, den andre for ceph-tjenestebehov (rebalansering). Hvis du bor med ceph på baremetal, er denne divisjonen lett å konfigurere, hvis du bor med Rook, vil delingen etter nettverk forårsake problemer, på grunn av det faktum at ikke hver klyngekonfigurasjon lar deg mate to forskjellige nettverk til poden .
Nettverksproblemer v2
Hvis du nekter å skille nettverk, vil ceph-trafikk ved rebalansering tette hele kanalen og applikasjonene dine i kubernetes vil bremse ned eller krasje. Du kan redusere hastigheten på ceph-rebalansering, men da får du på grunn av den lange rebalanseringen økt risiko for at den andre noden faller ut av klyngen via disker eller OOM, og det er allerede garantert skrivebeskyttet for klyngen.
Lang rebalansering - lange påføringsforsinkelser
Sitat fra Cephs innlegg. Anatomi av en katastrofe.
Testklyngeytelse:
En skriveoperasjon på 4 KB i størrelse tar 1 ms, ytelsen er 1000 operasjoner/sekund i 1 tråd.
En operasjon på 4 MB (objektstørrelse) tar 22 ms, ytelsen er 45 operasjoner/sekund.
Følgelig, når ett domene av tre svikter, klyngen er i en degradert tilstand i noen tid, og halvparten av de varme objektene er fordelt på forskjellige versjoner, vil halvparten av skriveoperasjonene begynne med en tvungen gjenoppretting.
Vi beregner den tvungne gjenopprettingstiden omtrent - skriveoperasjoner til et degradert objekt.
Først leser vi 4 MB på 22 ms, skriver 22 ms, og deretter på 1 ms skriver vi 4 KB med faktiske data. Totalt 45 ms per skriveoperasjon til et degradert objekt på en SSD, når standardytelsen var 1 ms - en 45 gangers nedgang i ytelsen.
Jo høyere prosentandel av degraderte gjenstander vi har, jo verre blir alt.
Det viser seg at hastigheten på rebalansering er avgjørende for riktig drift av klyngen.
Spesifikke serverinnstillinger for ceph
ceph kan kreve spesifikk vertinnstilling.
Eksempel: sysctl-innstillinger og samme JumboFrame, noen av disse innstillingene kan påvirke nyttelasten negativt.
Det virkelige behovet for Rook er fortsatt i tvil
Hvis du er i skyen har du lagring fra skyleverandøren din, noe som er mye mer praktisk.
Hvis du er på dine egne servere, vil det være mer praktisk å administrere ceph uten kubernetes.
Leier du servere fra lavprishotell? Da vil du ha mye moro med nettverket, dets forsinkelser og båndbredde, noe som helt klart påvirker ceph negativt.
totalt: Implementering av kuberentes og implementering av lagring er ulike oppgaver med ulike innganger og ulike løsningsalternativer – å blande dem betyr å gjøre en mulig farlig avveining av hensyn til den ene eller den andre. Det vil være svært vanskelig å kombinere disse løsningene selv på designstadiet, og det er fortsatt en periode med drift.
Liste over brukt litteratur:
Men du sier Ceph... er han virkelig så god?
Ceph. Anatomi av en katastrofe
Kilde: www.habr.com
