Linux-kernen 6.x: Vigtige nyheder for hosting-servere

Korrekt klassificering af kerne-stand

Betegnelsen Linux 6.x dækker over mange hovedudgivelser, ikke et ensartet funktionsniveau. Som »mainline« betegnes den hovedgren, der vedligeholdes af Linus Torvalds: Efter »merge window« følger der normalt »release candidates« frem til den endelige hovedudgivelse. Disse skal skelnes fra Stable- og LTS-grene, som fortsætter med at vedligeholde udgivne kerner med udvalgte rettelser. Distributionskerner følger igen deres egne pakkeversioner, supportforpligtelser og integrationsbeslutninger.

Især for hosting-servere er Bagdøre Afgørende: En distribution kan indarbejde enkelte funktioner, driverforbedringer eller sikkerhedsrettelser i en ældre kerne, der vedligeholdes på lang sigt. Omvendt kan den deaktivere funktioner, ændre patches eller begrænse dem via konfigurationen. Ud fra et versionsnummer kan man derfor hverken udlede det fulde funktionsomfang eller den konkrete driftsmæssige virkning.

Kommandoen uname -r identificerer den aktuelle release-streng og er et godt udgangspunkt for inventaropgørelse og pakkesammenligning. Den beviser dog ikke, at en funktion er indkompileret, aktiveret under kørsel eller tilgængelig for et program. Selv en ny kernerversion kan ikke erstatte en kontrol af den konfiguration og dokumentation, som distributøren stiller til rådighed.

For at kunne foretage en pålidelig klassificering skal du undersøge flere niveauer: distribution og pakkestatus, kernekonfiguration, opstartsparametre og eksisterende runtime-grænseflader. Dertil kommer hardware, firmware og drivere, f.eks. i forbindelse med lagring eller virtualisering. Endelig skal den anvendte applikation rent faktisk benytte en grænseflade; en eksisterende kernefunktion ændrer ikke automatisk en webserver.

Denne artikel følger derfor ikke en fuldstændig oversigt over udgivelser. Den ser på funktioner, der er relevante for driften af nutidens 6.x-kerner. Ikke alle disse funktioner blev først introduceret i 6.x-serien; det afgørende er det funktionsniveau, der er tilgængeligt i den konkrete kerne, mulige udvidelser samt indvirkningen på hukommelsesadfærd, CPU-konkurrence, procesisolering og vedligeholdelse.

Fire driftsområder inden for hosting

For hosting-servere er fire driftsområder særligt relevante: hukommelsestryk, CPU-konkurrence, yderligere procesisolering og vedligeholdelse. Det handler ikke om at aktivere så mange kernel-funktioner som muligt, men om at finde de rette værktøjer til et konkret problem. PHP-FPM-puljer, databaser, cacher, batch-jobs og specialiserede workere stiller forskellige krav, som ikke kan udledes ud fra kerneversionen alene.

cgroup v2 er et tværgående emne, men ikke en nyhed i 6.x-serien. Hierarkiet strukturerer hukommelses- og CPU-ressourcer for tjenester, containere eller kundegrupper. Hvilke controllere der er tilgængelige og aktiveret i en underhierarki, skal kontrolleres ved den pågældende cgroup-v2-mount. En dedikeret webserver kræver derfor en anden vurdering end en container- eller VM-host.

Tabellen skelner bevidst mellem build-konfiguration, boot-aktivering, runtime-grænseflade og faktisk brug. En funktion kan være inkluderet i kernen, men være deaktiveret eller uden betydning for applikationen. Ligeledes kan distributioner tilbageporte funktioner. Vurder derfor ændringer ud fra belastningsforløb, cgroup-opbygning, hardware og applikationsmålinger i stedet for ud fra det højeste tilgængelige versionsnummer.

Cache-tryk og sidegenvinding

Linux bruger gerne ledig RAM som filcache. At en stor del af RAM’en er optaget, er derfor i sig selv ikke en fejl og heller ikke et tegn på spild af hukommelse: Cachelagrede filsider kan genvindes efter behov. For diagnosticeringen er det snarere belastningens udvikling og konsekvenser, der tæller, f.eks. responstider, swap-aktivitet, fejlprotokoller og procesafbrydelser.

Det afhænger af trykket i tanken Genvinding af sideplads , hvilke sider der kan fjernes fra cachen eller eventuelt flyttes til en anden placering. Kernen kan udføre dette arbejde asynkront via kswapd udføre. Hvis en proces selv skal genvinde sider ved en hukommelsesanmodning, taler kerne-dokumentationen om direkte genvinding; dette kan påvirke den anmodende proces og dermed de observerede ventetider.

Advarselssignaler opstår oftest som en kombination: vedvarende ind- eller udlagring til swap, OOM-hændelser, stigende ventetider og fejl på applikationsniveau bør vises på en fælles tidslinje. En engangsudsving kan derimod være et planlagt batchjob. Heller ikke en cachedienst med stor RAM-andel er automatisk årsagen, hvis dens cgroup og de øvrige processer forbliver tilstrækkeligt funktionsdygtige.

cgroup v2 udvider det globale overblik med tjeneste- eller containergrænser. Hukommelseskontrolleren stiller hændelsestællere til rådighed; memory.events er hierarkisk, mens memory.events.local kun viser lokale hændelser i den pågældende cgroup. På den måde kan man skelne mellem, om et problem skyldes ens egen tjenestegrænse eller belastningen i en overordnet struktur.

Disse grundlæggende forhold taler endnu ikke for tuning. Inden du ændrer grænseværdier, swap-strategi eller kernegrænseflader, skal du kortlægge belastningskilder, cgroup-tildeling og tidsmæssig sammenhæng. Især en stram hukommelsesgrænse kan få en tjeneste til at gå ned før tid, i stedet for at løse den underliggende spidsbelastning. Først efter en diagnose kan man se, om en ændring overhovedet er en passende teknisk justeringsmulighed.

Målrettet kontrol af Multi-Gen LRU

Multi-Gen LRU er en alternativ implementering af Genvinding af sideplads og er beskrevet i den her omhandlede kerne-dokumentation fra og med Linux 6.1. Under hukommelsespres skal kernen beslutte, hvilke filcache- eller anonyme hukommelsessider der kan frigøres. Multi-Gen LRU inddeler sider i generationer efter, hvor længe der er gået siden sidste adgang, og tager højde for adgangs mønstre, så sider, der ofte bruges, er mindre tilbøjelige til at blive valgt til frigørelse.

Dette er relevant for en tæt udnyttet webhostingserver, hvor PHP-FPM-puljer, en database og en cachedienst samtidig belaster RAM-hukommelsen. Funktionen kan ændre valget ved genvinding, men er hverken en udvidelse af hukommelsen eller en garanti for kortere svartider. Arbejdsmængde, RAM-kapacitet, swap, masselagring og tjenesternes cgroup-grænser bestemmer fortsat, om og hvordan en effekt kan mærkes.

Før hver evaluering skal du først kontrollere, om runtime-grænsefladen er til stede og kan læses. Den aktuelle kerne-dokumentation angiver følgende konfigurationsindstillinger til dette formål CONFIG_LRU_GEN og CONFIG_LRU_GEN_ENABLED samt stien under /sys/kernel/mm/lru_gen/. En distributionskerne kan tilbageporte funktionsniveauer eller konfigurere dem på en anden måde; versionsnummeret alene er derfor ikke et pålideligt bevis.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

En udskrift viser i første omgang blot, at den dokumenterede sysfs-grænseflade findes og kan læses. Bitværdien er afgørende for aktiveringsstatus: 0x0001 er hovedafbryderen for Multi-Gen LRU. Mangler dette bit, kan filen vise en deaktiveret hovedafbryder, selvom der er en tilgængelig grænseflade; de øvrige bits vedrører yderligere komponenter. Selv et sat hovedbit er ikke en generel anbefaling om at ændre værdien i produktionsmiljøet.

Skriveadgang til sysfs er derfor ikke en standardoptimering. Indsaml først tidsserier for Reclaim, Swap, latenstider og cgroup-hændelser, dokumenter udgangsværdien ved en begrundet ændring, og fastlæg en tilbagevendelsesvej. På den måde kan man spore, om det observerede problem rent faktisk har ændret sig, eller om der blot er blevet justeret flere parametre samtidigt.

Du bør være særlig forsigtig, når der både er begrænsede lagerpladsgrænser og overbookede tjenester. En ændret reclaim-algoritme løser ikke problemer med for store PHP-worker-puljer, uhensigtsmæssige databasecacher eller manglende adskillelse af konkurrerende kunder. Den fornuftige rækkefølge er: Fastlæg årsagen og den berørte cgroup, begræns eller fordel belastningen, og vurder først derefter en tilgængelig kernel-funktion som mulig påvirkningsfaktor.

Sikker indkredsning af lagerproblemer

Brugt RAM er i sig selv ikke en fejl: Linux bruger ledig hukommelse målrettet som filcache. Der er snarere behov for at gribe ind, når kravene i direkte Reclaim kører, swap-aktiviteten stiger, der opstår OOM-hændelser, eller forespørgslerne bliver langsommere på samme tid. Asynkron frigørelse via kswapd fungerer i baggrunden; direkte genvinding foregår derimod i forbindelse med den opgave, der anmoder om hukommelse, og kan forsinke udførelsen af denne.

Hændelsesfilen memory.events tæller begivenheder hierarkisk, dvs. inklusive underordnede cgroups. For den udelukkende lokale visning gælder memory.events.local klar. high betyder begrænsning og direkte genvinding, når memory.high, mens oom en allokering, der er ved at mislykkes på grund af cgroup-grænsen, tæller med. oom_kill tæller derimod processer i denne cgroup, der er blevet afbrudt af en eller anden form for OOM-killer.

Start fejlfindingen med en klar kortlægning: Hvilken tjeneste eller hvilken container hører til den mistænkelige cgroup, hvornår opstod hændelserne, og hvilke applikationssignaler var der samtidig? Sammenlign derefter lokale og hierarkiske tællere, systemloggen, swap-historikken samt HTTP-forsinkelser, ventetider i databasen eller fejlrater. I tilfælde af en OOM-hændelse skal det desuden afklares, om dataene tyder på en cgroup-relateret hændelse eller en mulig global hukommelsesmangel.

Værdien memory.max er en streng cgroup-grænse og ikke en første standardforanstaltning. En strammere grænse kan beskytte klienter, men kan også få en applikation til at havne i OOM-situationer tidligere; en højere grænse kan forstærke fortrængningen hos tilstødende tjenester. Kontroller derfor først antallet af arbejdsprocesser, cachestørrelser, belastningstoppe og cgroup-strukturen. Ændr derefter kun en velbegrundet parameter med en observationsperiode og en plan for tilbageførsel.

At forstå EEVDF og konkurrencen på CPU-markedet

Den aktuelle officielle kernel-dokumentation angiver, at overgangen til EEVDF Linux 6.6. Algoritmen »Earliest Eligible Virtual Deadline First« ændrer udvælgelsen af normale, retfærdigt planlagte opgaver: Der tages højde for virtuel køretid, forsinkelse som afvigelse fra den ideelle fordeling samt virtuelle frister. Berettigede opgaver med den tidligste virtuelle frist kan dermed få tildelt CPU-tid først.

Udtrykket „overgang“ er vigtigt. EEVDF erstatter ikke Fair Scheduling-klassens valgbeslutning i den forstand, at alle datastrukturer, grænseflader og koncepter, der historisk set er blevet betegnet som CFS, dermed forsvinder. Også den aktuelle dokumentation sammenligner fortsat EEVDF med CFS. For en konkret distributionskerne skal man derfor kontrollere dens integrerede patch- og funktionsstatus i stedet for udelukkende at basere sig på 6.6 eller højere, kan man konkludere, at der er tale om en fuldstændig ensartet adfærd.

Hvad angår hosting, er denne ændring især relevant ved blandet belastning. Webforespørgsler, databaseopgaver og overvågning konkurrerer for eksempel med importer, komprimering eller sikkerhedskopier. Der kan forekomme et andet latenstidsprofil mellem forskellige kernelversioner, men det betyder ikke automatisk en højere samlet gennemstrømning. Scheduleren løser ikke problemer med kerner, der er konstant fuldt udnyttede, blokerede processer, I/O-ventetider og uhensigtsmæssige applikationskonfigurationer.

Den operationelle adskillelse sker fortsat på tværs af tjeneste- og platformgrænser. CPU-vægtninger påvirker den relative fordeling i tilfælde af konkurrence, mens kvoter kan begrænse den tilgængelige regnetid. Hvis webbelastning, hvor latenstid er afgørende, skal adskilles pålideligt fra omfattende batch-job, kan en egen VM eller en separat host også være hensigtsmæssigt. EEVDF erstatter disse Ressourceplanlægning ikke.

Inden forespørgslen om cgroup.controllers skal du finde ud af, om og hvor cgroup v2 er monteret. Følgende kommando søger efter cgroup-v2-monteringspunktet i stedet for den sædvanlige sti /sys/fs/cgroup skal antages. På et rent cgroup-v1-system forbliver variablen tom; i et hybridhierarki viser den kun den fundne v2-mount.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r angiver kun den aktuelle udgivelsesstreng. cgroup.controllers viser en liste over de controllere, der er tilgængelige for aktivering i netop denne cgroup; det bekræfter ikke, at de er blevet aktiveret i de relevante underhierarkier. Til det formål findes blandt andet cgroup.subtree_control skal kontrolleres på de respektive hierarkiniveauer. Controllere godkendes top-down, således at en underordnet cgroup kun kan videregive controllere, der er stillet til rådighed af den overordnede node.

systemd-cgtop giver ligeledes kun et øjebliksbillede og er ikke en årsagsanalyse. Indsaml data om CPU-udnyttelse pr. tjenestegruppe, anmodningsforsinkelser, køretider for batch-job og eventuelt I/O-ventetider over flere sammenlignelige belastningsfaser. Hvis forsinkelser kun opstår under en sikkerhedskopiering, er dens tidsvindue, CPU-vægt eller kvote som regel mere konkrete indgreb end formodet justering af scheduleren.

Landlock for specialiserede arbejdstagere

Landlock blev først introduceret med Linux 5.13 og er derfor ikke en nyhed, der stammer fra 6.x-serien. I 6.x-kerner findes der forskellige, udvidede ABI-versioner, afhængigt af udgivelsen og distributionskernen. Funktionen er en supplerende sikkerhedsmekanisme, som en proces kan bruge til at begrænse sig selv yderligere.

Som et stabelbart Linux-sikkerhedsmodul fungerer Landlock som et supplement til de allerede gældende adgangsbeslutninger; det erstatter hverken Unix-filerettigheder, SELinux, AppArmor, navnerum eller containere. Reglerne kan blandt andet begrænse adgangen til filsystemet og videregives til efterfølgende startede underprocesser. Det praktiske funktionsomfang afhænger af den tilgængelige ABI og kernelkonfigurationen.

Det er fornuftigt at Landlock især til egenudviklede eller målrettet udvalgte enkeltprocesser. En konverter til kundeuploads kunne f.eks. kun læse filer fra en indlæsningsmappe og udelukkende skrive resultaterne til en udskrivningsmappe. Selv hvis tjenesten behandles fejlagtigt, skal den hverken kunne læse SSH-nøgler, applikationshemmeligheder eller generelle systempatier. Denne begrænsning supplerer en omhyggelig tildeling af rettigheder; den gør den ikke overflødig.

En produktiv regel må ikke udelukkende baseres på en aktuel kerne. Landlock har flere ABI-versioner; et program bør under kørsel undersøge, hvilken ABI der er tilgængelig, og kun anmode om adgangsrettigheder eller funktioner, som denne ABI understøtter. På den måde kan programmet fungere i en nedgraderet tilstand på ældre systemer i stedet for at svigte fuldstændigt på grund af en utilgængelig grænseflade.

Hertil kommer handled_access_fs fastlægger eksplicit, hvilke filsystemadgange et regelsæt håndterer, og som som standard afvises, hvis der ikke findes en passende regel. Denne udtrykkelige aftale mellem applikationen og kernen forhindrer, at en sandkasse bliver strengere uden at man bemærker det blot på grund af en systemopdatering, og dermed får applikationer til at gå ned. ABI-forespørgsel og eksplicit behandlede rettigheder hører derfor sammen, men løser forskellige kompatibilitetsopgaver.

For filkonverteren følger der heraf en trinvis implementering: De nødvendige læse-, skrive- og arbejdsmapper skal udledes af den faktiske proces, fejlforløb skal tages i betragtning, og det hele skal først testes i et testmiljø. En kortfattet eksempelpolitik ville ikke være en pålidelig produktionsopskrift, da midlertidige filer, eksterne biblioteker og startede hjælpeprogrammer kan kræve yderligere adgang. Yderligere foranstaltninger til tjenesteisolering behandles også i artiklen om Kernel-hærdning til hosting-servere.

Der skal udvises særlig forsigtighed ved OverlayFS. Regler for et overlay-lag begrænser ikke automatisk den sammensatte mount-hierarki, og omvendt. Container- og build-miljøer med overlays kræver derfor en separat gennemgang af de konkrete mounts og adgangsstier. Landlock er her et muligt ekstra lag, men ikke en generel adskillelse af klienter og ikke en erstatning for et bæredygtigt container- eller autorisationskoncept.

DAMON kun i særlige tilfælde

DAMON og de derpå baserede Reclaim-mekanismer kan ikke generelt betragtes som funktioner, der først blev introduceret med Linux 6.x. For administratorer er det funktionsniveauet i den konkret anvendte 6.x- eller distributionskerne, der tæller. DAMON overvåger hukommelsesadgange med det formål at kunne klassificere områder ud fra deres brugsmønstre.

Med udgangspunkt i dette forsøger DAMON_RECLAIM, proaktivt at genvinde hukommelse, der ikke har været brugt i lang tid, ved hjælp af et let tryk. Metoden supplerer den normale LRU-baserede genvinding; den er ikke tænkt som en erstatning for denne. Kernel-dokumentationen henfører den til generelle overbookede hukommelsessystemer og nævner virtualisering baseret på Free-Pages-Reporting som eksempel.

I dette virtualiseringsscenarie er niveauet afgørende: Gæsterne rapporterer ledige hukommelsessider til værten, som værten kan tildele til andre gæster. Hvis en gæst kun rapporterer lidt ledig hukommelse, selvom den har sider, der ikke har været brugt i lang tid, kan proaktiv genvinding som gæst bidrage til at rapportere flere ledige sider til værten. DAMON_RECLAIM er derfor ikke uden yderligere undersøgelse en værtsbaseret løsning på gæsternes ubrugte hukommelse.

For en enkelt web- eller databaseserver er dette derfor ikke en standardforanstaltning. Også i virtualiserede miljøer skal det først stå klart, på hvilket niveau belastningen opstår, og om det rent faktisk er områder, der har været ubrugte i lang tid, der er årsagen. CPU-flaskehalse, langsom lagring, uhensigtsmæssige cgroup-grænser eller aktive applikationscacher kan forklare de samme symptomer, uden at proaktiv genvinding ville være den rette løsning.

Kvoter, aldersgrænser og vandmærker styrer, hvornår og i hvilket omfang DAMON_RECLAIM kører. Det er ikke standardværdier, der kan overføres: Et for aggressivt valg kan for tidligt fortrænge nyttig filcache eller hukommelsessider, der jævnligt skal bruges. Dette kan udløse yderligere I/O-operationer og optage CPU-tid til gentaget arbejde, selvom den nominelt ledige hukommelse stiger.

En velovervejet beslutning kræver derfor målinger med klare sammenligningsparametre, såsom ledig lagerplads angivet af brugeren, reclaim-aktivitet, swap-adfærd, lagerlatens og applikationsresponstider. Test ændringer først i et sammenligneligt staging-miljø, fastlæg en tilbageførselsplan, og overvåg dem gennem repræsentative belastningsfaser. Mangler disse forudsætninger, eller er årsagen til lagerpresset uafklaret, forbliver DAMON bevidst deaktiveret.

Opdateringer, live-opdateringer og genstarter

Vedligeholdelse af kernen begynder med at sammenholde sikkerhedsmeddelelsen, den installerede pakke og den kerne, der rent faktisk kører. Tjek derefter i vejledningen til din egen distribution, hvilken rettelse der er beregnet til netop denne kernegren, og om der kræves en genstart. Et højere 6.x-versionsnummer i sig selv beviser hverken, at den pågældende patch er inkluderet, eller at der findes en passende livepatch; sikkerhedsrettelser kan også tilbageporteres til ældre distributionskerner.

Også Live-patching blev ikke først introduceret som koncept med Linux 6.x. Den infrastruktur, der er relevant for 6.x-kernerne, gør det muligt at indføre bestemte kerneændringer under kørsel. Kumulative livepatches kan i den forbindelse erstatte en ældre patch atomart med en nyere. De dokumenterede begrænsninger vedrører blandt andet tilstandsændringer, callbacks og skift tilbage mellem patches.

Om der findes en passende livepatch til en bestemt distributionskerne, skal kontrolleres ud fra det pågældende tilbud og udbyderens godkendelser. Den generelle kernel-infrastruktur indebærer hverken, at alle sikkerhedsrettelser er tilgængelige live, eller at en installeret patch permanent erstatter en fuldstændig kernel-opdatering. Planlæg derfor fortsat regelmæssige vedligeholdelsesvinduer.

Vurder først, hvor presserende en opdatering er, og hvilke konsekvenser den vil have, sammenlign derefter pakkestatus og den aktuelle kerne, og gennemgå det konkrete Livepatch-tilbud. Efter en almindelig kerneopdatering med genstart skal du kontrollere, om den forventede kerne er aktiv, og om de kritiske tjenester, netværksstier, sikkerhedskopier og overvågningen fungerer korrekt. Denne kontrol er en del af vedligeholdelsesproceduren og bør ikke kun baseres på, om serveren er tilgængelig.

En planlagt genstart kan stadig være nødvendigt på trods af livepatching. Ændringer af kernelens opstartsparametre træder typisk først i kraft ved næste opstart. Hvad angår drivere, enhedsfirmware og hardware, afhænger fremgangsmåden derimod af komponenten, dens integration og producentens fremgangsmåde: I nogle tilfælde er det tilstrækkeligt at genstarte et modul, en enhed eller en tjeneste, mens det i andre tilfælde er nødvendigt at genstarte hele værten.

Den supplerende artikel om Livepatching på AlmaLinux-servere Omhandler en konkret distributionsafhængig implementering. Overfør ikke sådanne procedurer uden nærmere undersøgelse til andre kernegrene eller udbydere. Det er pakkerne, de understøttede kernerversioner og driftsanvisningerne for den faktisk anvendte platform, der er afgørende.

• Undlad bevidst at foretage ændringer, hvis den observerede fejl endnu ikke har en påviselig årsag.
• Der må ikke planlægges nogen Livepatch- eller kerneændringer uden en passende staging-test og en dokumenteret tilbageførselsvej.
• En funktion bør ikke aktiveres, hvis det pågældende program eller den pågældende platform ikke benytter dens grænseflade.
• Man skal ikke antage, at et manglende vedligeholdelsesvindue kan erstattes af den antagelse, at livepatching dækker alle kerneopdateringer.