Etter overgangen til Dapla Lab februar 2025 har vi gjort erfaringer som tilsa at vi burde endre hvordan tjenestene er satt opp. Dette burde resultere i at brukere opplever færre avbrudd når de jobber i en tjeneste som Jupyter, og at det blir færre problemer knyttet til konkurerende minnebruk. Ofte er disse vurderingene en avveining mellom opplevd stabilitet og fleksibilitet vs kostnader for SSB. Det optimalet oppsettet er derfor noe vi må kontinuerlig justere etter hvert som vi får erfaring.
Færre avbrudd
Brukere som har jobbet i Jupyter, VS Code eller RStudio har rapportert at de plutselig kan oppleve avbrudd og at tjenesten ikke kan brukes på noen minutter. En refresh av nettsiden etter noen minutter har fikset problemet, men det oppleves ustabilt for brukeren. Vi har nå gjort endringer i den underliggende plattformen slik at dette ikke skal skje. Årsaken til avbruddene har vært at brukere har blitt omplassert på nye maskiner for å spare ressurser. Vi har nå økt toleransen for at brukere skal bli omplassert på ny maskin og dermed bør problemet forsvinne. For de som er interessert i mer detaljer så kan de lese neste avsnitt.
Når en tjeneste startes i Dapla Lab bestemmer Kubernetes1 hvilken underliggende maskin (også kalt node) tjenesten skal starte på. Hvis det er for lite kapasitet vil Kubernetes starte en ny maskin. Denne skaleringen er grunnen til at oppstart av en tjeneste noen ganger kan ta ekstra tid. Skulle det vise seg at vi har flere maskiner enn nødvendig vil de overflødige maskinene bli skrudd av. Ved å kun kjøre det minste nødvendige antallet med maskiner får vi en mer kostnadseffektiv drift. En konsekvens av dette har vært at tjenester plutselig kan oppleve et midlertidig avbrudd mens tjenesten blir flyttet fra en maskin til en annen. Etter tilbakemelding fra brukerne har vi endret denne praksisen, og lar nå tjenestene kjøre videre på samme maskin, selv om det er ledig kapasitet på andre maskiner.
Mindre konkurrerende minnebruk
Enkelte brukere har opplevd at tjenesten i Dapla Lab kræsjer pga. minnebruk selv om minnebruken er mindre enn det som ble forespurt av brukeren. Dette skyldes at det er forskjell på forespurte og tilgjengelige ressurser i Kubernetes. Vi har nå endret oppsettet i Dapla Lab slik at brukerne alltid får det som forespørres, og derfor vil mangel på ressurser ikke forekomme lenger. Resultatet for brukeren er en mer stabil tjeneste og bedre brukeropplevelse. De som er interessert i flere detaljer rundt dette, kan lese avsnittet under.
Når man som bruker i Dapla Lab konfigurerer en tjeneste med CPU og Minne/RAM, så blir det satt føringer som må overholdes av Kubernetes. Den ene føringen er en forespørsel - mengden CPU/minne man er garantert å få - og den andre er grensen/taket. Hvis man går over taket vil Kubernetes “drepe” tjenesten og starte den på nytt.
I “tradisjonelle” applikasjoner (tenk f.eks. Klass sitt API) gir forespørsler og grenser mening, grunnet naturlig variasjon i belastning og trafikk, og at applikasjonene er designet for å kunne feile, starte på nytt ofte og kjøre flere instanser i parallel. Hvis den om og om igjen går over grensen sin tyder dette på en feil i applikasjonen (f.eks. minnelekkasje).
Kubernetes benytter seg av det forespurte minnet når den velger hvilken maskin tjenesten eller applikasjonen skal kjøre på. Det vil si at det er mulig å totalt ha en høyere minnegrense enn hva som er tilgjengelig på maskinen. Et eksempel på dette er hvis tjeneste A har minneforespørsel/-grense på 100GB/150GB, og tjeneste B har tilsvarende, men maskinen bare har 256GB med minne tilgjengelig. Da er vi i et scenario der maskinen ikke har nok minne hvis både tjeneste A og tjeneste B bruker opp til minnegrensen sin. I dette tilfellet vil en tjeneste på maskinen bli drept og startet på nytt. Merk at dette kan være en tilfeldig tjeneste på maskinen, ikke nødvendigvis den som bruker mest minne.
Vi har sett at det for tjenester på Dapla Lab ikke gir mening å differensiere på forespørsel og grense, som i tradisjonelle applikasjoner. Derfor er det nå innført en endring der forespørselen er lik grensen.Dette håper vi gjør det mer forutsigbart for brukeren hva de kan forvente av tilgjengelig minne, samtidig som stabiliteten for alle brukerne ved at “minnetunge” brukere ikke påvirker andre sine tjenester.
Nye maskiner
Det å velge korrekte maskiner er ikke nødvendigvis en enkel oppgave, da generell bruk av maskinen må veies opp mot kostnaden ved den. Kostnadsdriveren for maskinene Dapla Lab og tjenestene kjører på er minne. Den nysgjerrige kan ta en titt på pris-oversikten her:
https://cloud.google.com/compute/all-pricing?hl=nb.
På Dapla Lab benyttes maskintype n2 (standard og highmem). Ved å monitorere og observere bruken av ressurser gjør vi nå også endringer i hvilke underliggende maskiner som kan kjøres opp. Fremover vil vi kjøre opp færre store maskiner enn flere små (fordi det finnes en basiskostnad for hver ekstra maskin), samtidig som vi nå innfører en maskintype som ikke har like mye minne som andre (n2-standard-80). Det vil være kostnadseffektivt for dem som trenger mye CPU men ikke nødvendigvis masse minne.
Dette vil være noe brukerne ikke merker eller vil ha et forhold til.
Fotnoter
Kubernetes er systemet som brukes under panseret for å skalere opp og ned ressurser i Dapla Lab. Les mer om Kubernetes her.↩︎