Kernel Linux 6.x: novità rilevanti per i server di hosting

Classificare correttamente la versione del kernel

Il termine “Linux 6.x” raggruppa numerose versioni principali, non un unico livello funzionale. Per “mainline” si intende il ramo principale curato da Linus Torvalds: dopo la “merge window” seguono solitamente le “release candidate” fino alla versione finale. Da queste vanno distinte le ramificazioni Stable e LTS, che continuano a mantenere i kernel pubblicati con correzioni selezionate. I kernel delle distribuzioni, a loro volta, seguono i propri stati dei pacchetti, gli impegni di supporto e le decisioni di integrazione.

Soprattutto per i server di hosting sono Portabagagli Fondamentale: una distribuzione può integrare singole funzioni, miglioramenti dei driver o correzioni di sicurezza in un kernel più vecchio, ma supportato a lungo termine. Al contrario, può disattivare funzioni, modificare le patch o limitarle tramite la configurazione. Da un numero di versione non è quindi possibile dedurre né l’insieme completo delle funzionalità né l’effettivo impatto operativo.

Il comando uname -r Identifica la stringa di versione corrente e rappresenta un punto di partenza utile per l'inventario e il confronto dei pacchetti. Tuttavia, non dimostra che una funzione sia stata compilata, attivata in fase di esecuzione o accessibile per un'applicazione. Anche una nuova versione del kernel non sostituisce la verifica della configurazione e della documentazione fornite dal distributore.

Per una classificazione attendibile, è necessario verificare diversi livelli: distribuzione e stato dei pacchetti, configurazione del kernel, parametri di avvio e interfacce di runtime disponibili. A ciò si aggiungono hardware, firmware e driver, ad esempio nel caso dello storage o della virtualizzazione. Infine, l’applicazione utilizzata deve effettivamente utilizzare un’interfaccia; una funzione del kernel già presente non modifica automaticamente un server web.

Questo articolo non segue quindi una cronologia completa delle versioni. Esamina le funzionalità rilevanti per il funzionamento dei kernel 6.x odierni. Non tutte queste funzionalità sono state introdotte solo nella serie 6.x; gli aspetti determinanti sono lo stato delle funzionalità disponibili nel kernel specifico, le possibili estensioni e le ripercussioni sul comportamento della memoria, sulla concorrenza della CPU, sull’isolamento dei processi e sulla manutenzione.

Quattro aree operative per l'hosting

Per i server di hosting, quattro ambiti operativi sono particolarmente rilevanti: pressione di accumulo, competizione per la CPU, isolamento aggiuntivo dei processi e manutenzione. Non si tratta di attivare il maggior numero possibile di funzioni del kernel, bensì di utilizzare gli strumenti adeguati per risolvere un problema specifico. I pool PHP-FPM, i database, le cache, i processi batch e i worker specializzati presentano requisiti diversi, che non possono essere dedotti dalla sola versione del kernel.

cgroup v2 Si tratta di un tema trasversale, ma non di una novità della serie 6.x. La gerarchia struttura le risorse di memoria e CPU per servizi, container o gruppi di clienti. Per verificare quali controller siano disponibili e attivati in una sotto-gerarchia, è necessario controllare il rispettivo mount cgroup-v2. Un server web dedicato richiede quindi una valutazione diversa rispetto a un host di container o di macchine virtuali.

La tabella distingue volutamente tra configurazione di build, attivazione all’avvio, interfaccia di runtime e utilizzo effettivo. Una funzionalità può essere presente nel kernel, ma essere disabilitata o irrilevante per l’applicazione. Allo stesso modo, le distribuzioni possono reimplementare funzionalità precedenti. Valuta quindi le modifiche in base all’andamento del carico, alla struttura dei cgroup, all’hardware e ai dati di monitoraggio delle applicazioni, anziché in base al numero di versione più alto disponibile.

Pressione di memoria e recupero delle pagine

Linux tende a utilizzare la memoria libera come cache dei file. Un elevato utilizzo della RAM non è quindi di per sé un errore né indice di uno spreco di memoria: le pagine dei file memorizzate nella cache possono essere recuperate all’occorrenza. Ai fini della diagnosi, sono più rilevanti l’andamento e le conseguenze del carico, quali i tempi di risposta, l’attività di swap, i log degli errori e le interruzioni dei processi.

È la pressione di stoccaggio a determinare Recupero spazio su pagina , quali pagine possono essere rimosse dalla cache o, se necessario, trasferite in memoria secondaria. Il kernel può eseguire questa operazione in modo asincrono tramite kswapd eseguire. Se un processo deve recuperare autonomamente le pagine in seguito a una richiesta di memoria, la documentazione del kernel parla di “reclamazione diretta”; ciò può influire negativamente sul processo richiedente e, di conseguenza, sulle latenze osservate.

I segnali di allarme si presentano solitamente come una combinazione di fattori: lo swap in entrata o in uscita prolungato, gli eventi OOM, i tempi di attesa crescenti e gli errori a livello di applicazione meritano di essere analizzati su una linea temporale comune. Un picco isolato può invece essere causato da un processo batch pianificato. Anche un servizio di cache che occupa una quota elevata di RAM non è automaticamente la causa, se il suo cgroup e gli altri processi mantengono una capacità operativa sufficiente.

cgroup v2 integra la visione globale con i confini dei servizi o dei container. Il controller di memoria mette a disposizione dei contatori di eventi; memory.events è gerarchico, mentre memory.events.local mostra solo gli eventi locali del rispettivo cgroup. In questo modo è possibile distinguere se un problema è dovuto al limite del proprio servizio o al carico in una struttura di livello superiore.

Questi elementi di base non sono ancora sufficienti per procedere con l’ottimizzazione. Prima di modificare i limiti, la strategia di swap o le interfacce del kernel, è necessario classificare le fonti di carico, l’assegnazione dei cgroup e la correlazione temporale. In particolare, un limite di memoria troppo rigido può causare il malfunzionamento prematuro di un servizio, anziché risolvere il picco di carico sottostante. Solo la diagnosi rivela se una modifica dispone effettivamente di una leva tecnica adeguata.

Verifica mirata delle LRU multigenerazionali

Multi-Gen LRU è un'implementazione alternativa per Recupero spazio su pagina ed è descritto nella documentazione del kernel qui trattata a partire da Linux 6.1. In condizioni di pressione sulla memoria, il kernel deve decidere quali pagine della cache dei file o della memoria anonima possano essere recuperate. A tal fine, il Multi-Gen LRU raggruppa le pagine in generazioni in base all’età di accesso e tiene conto dei modelli di accesso, in modo che le pagine utilizzate con minore frequenza siano selezionate con minore probabilità per il recupero.

Questo è rilevante per un server di web hosting molto carico, su cui i pool PHP-FPM, un database e un servizio di cache utilizzano contemporaneamente la RAM. Questa funzione può modificare i risultati del comando «reclaim», ma non costituisce né un’estensione della memoria né una garanzia di tempi di risposta più brevi. Il carico di lavoro, la dotazione di RAM, lo swap, lo spazio di archiviazione e i limiti cgroup dei servizi continuano a determinare se e in che misura si noti un effetto.

Prima di ogni valutazione, verifica innanzitutto se l'interfaccia runtime è presente e leggibile. La documentazione attuale del kernel indica le opzioni di configurazione seguenti a tale scopo CONFIG_LRU_GEN e CONFIG_LRU_GEN_ENABLED nonché il percorso in /sys/kernel/mm/lru_gen/. Un kernel di distribuzione può riportare indietro le versioni delle funzionalità o configurarle in modo diverso; il numero di versione da solo non costituisce quindi una prova attendibile.

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

Un output dimostra inizialmente solo che l'interfaccia sysfs documentata è presente e leggibile. Per lo stato di attivazione è rilevante il valore del bit: 0x0001 è l'interruttore principale di Multi-Gen LRU. Se questo bit manca, il file può indicare un interruttore principale disattivato nonostante l'interfaccia sia disponibile; gli altri bit riguardano componenti aggiuntivi. Anche se il bit principale è impostato, ciò non costituisce una raccomandazione generale a modificare il valore in produzione.

Gli accessi in scrittura a sysfs non rientrano quindi nella configurazione standard. Raccogli innanzitutto le serie temporali relative a Reclaim, Swap, latenze ed eventi cgroup; in caso di modifica giustificata, documenta il valore iniziale e definisci una procedura di ripristino. In questo modo sarà possibile verificare se il problema osservato sia effettivamente cambiato o se siano state semplicemente modificate contemporaneamente diverse variabili di controllo.

È necessario prestare particolare attenzione soprattutto in presenza di limiti di memoria ridotti e servizi sovraccarichi. Una modifica dell’algoritmo di reclaim non risolve i problemi legati a pool di worker PHP troppo grandi, cache del database inadeguate o alla mancanza di separazione tra clienti in competizione tra loro. La sequenza corretta è la seguente: individuare la causa e il cgroup interessato, limitare o distribuire il carico e solo successivamente valutare una funzione del kernel disponibile come possibile fattore influente.

Individuare con certezza i problemi di memoria

La RAM occupata non costituisce di per sé un errore: Linux utilizza la memoria libera in modo mirato come cache dei file. È necessario intervenire piuttosto quando le richieste in Reclaim diretto funzionamento, aumento dell'attività di swap, verificarsi di eventi OOM o rallentamento simultaneo delle richieste. Recupero asincrono tramite kswapd funziona in background; il recupero diretto, invece, avviene nel contesto dell'attività che richiede memoria e può ritardarne l'esecuzione.

Il file degli eventi memory.events conta gli eventi in modo gerarchico, includendo quindi anche i cgroup subordinati. Per la visualizzazione esclusivamente locale è disponibile memory.events.local pronto. high indica la limitazione e il recupero diretto in caso di superamento di memory.high, mentre oom un’allocazione che rischia di fallire a causa del limite del cgroup viene conteggiata. oom_kill Conta invece i processi di questo cgroup che sono stati terminati da un qualche tipo di OOM-killer.

Inizia la diagnosi con una chiara identificazione: quale servizio o container appartiene al cgroup sospetto, quando si sono verificati gli eventi e quali segnali dell’applicazione sono stati rilevati contemporaneamente? Confronta quindi i contatori locali con quelli gerarchici, il log di sistema, la cronologia dello swap, nonché le latenze HTTP, i tempi di attesa del database o i tassi di errore. In caso di OOM, occorre inoltre chiarire se i dati indichino un evento correlato al cgroup o una possibile carenza globale di memoria.

Il valore memory.max Si tratta di un limite rigido per i cgroup e non di una prima misura standard. Un limite più restrittivo può proteggere i client, ma può anche portare un’applicazione a situazioni di OOM prima del previsto; un limite più elevato può invece accentuare il fenomeno di esclusione nei servizi adiacenti. Verifica quindi innanzitutto il numero di worker, le dimensioni della cache, i picchi di carico e la struttura dei cgroup. Modifica poi solo una variabile ben motivata, con un periodo di osservazione e un piano di ripristino.

Comprendere l’EEVDF e la concorrenza tra CPU

L'attuale documentazione ufficiale del kernel indica l'inizio della transizione verso EEVDF Linux 6.6. L'algoritmo "Earliest Eligible Virtual Deadline First" modifica la selezione dei task normali, pianificati in modo equo: vengono presi in considerazione il tempo di esecuzione virtuale, il ritardo come scostamento dalla distribuzione ideale e le scadenze virtuali. I task idonei con la scadenza virtuale più vicina possono così ottenere per primi il tempo di CPU.

Il termine „transizione“ è importante. L’EEVDF non sostituisce la scelta della classe di fair scheduling nel senso che tutte le strutture dati, le interfacce e i concetti storicamente denominati CFS scompaiano. Anche la documentazione attuale continua a confrontare EEVDF con CFS. Per un kernel di distribuzione specifico è quindi necessario verificare lo stato integrato delle patch e delle funzionalità, anziché basarsi esclusivamente su 6.6 o superiore, si può dedurre un comportamento del tutto uniforme.

Per l’hosting, questa modifica è rilevante soprattutto in presenza di carichi misti. Le richieste web, le operazioni sui database e il monitoraggio, ad esempio, entrano in competizione con le importazioni, la compressione o i backup. È possibile che si verifichi un profilo di latenza diverso tra le diverse versioni del kernel, ma ciò non comporta automaticamente un aumento della larghezza di banda complessiva. Lo scheduler non risolve problemi quali nuclei costantemente sotto carico, processi bloccati, tempi di attesa I/O e configurazioni delle applicazioni inadeguate.

La separazione operativa continua a avvenire in base ai confini dei servizi e delle piattaforme. I pesi della CPU influenzano la distribuzione relativa in caso di concorrenza, mentre le quote possono limitare il tempo di calcolo utilizzabile. Se è necessario separare in modo affidabile i carichi web sensibili alla latenza da lavori batch di grandi dimensioni, può essere opportuno ricorrere a una propria macchina virtuale (VM) o a un host separato. EEVDF sostituisce questi Pianificazione delle risorse no.

Prima di eseguire la query su cgroup.controllers Devi verificare se e dove è montato cgroup v2. La seguente procedura di lettura cerca il punto di montaggio di cgroup v2, anziché il percorso standard /sys/fs/cgroup da presupporre. Su un sistema esclusivamente cgroup-v1, la variabile rimane vuota; in una gerarchia ibrida, indica solo il mount v2 individuato.

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 indica solo la stringa della versione corrente. cgroup.controllers elenca i controller disponibili per l'attivazione proprio in questo cgroup; non conferma però che siano stati attivati nelle sotto-gerarchie pertinenti. A tal fine serve, tra l'altro, cgroup.subtree_control da verificare ai rispettivi livelli gerarchici. I controller vengono abilitati con un approccio top-down, per cui un cgroup figlio può trasmettere solo i controller forniti dal nodo padre.

systemd-cgtop anche questo fornisce solo un’istantanea e non costituisce un’analisi delle cause. Raccogli i dati relativi all’utilizzo della CPU per gruppo di servizi, alle latenze delle richieste, ai tempi di esecuzione dei lavori batch e, se del caso, ai tempi di attesa I/O durante diverse fasi di carico comparabili. Se i ritardi si verificano solo durante un backup, la sua finestra temporale, il carico sulla CPU o la quota sono solitamente i primi parametri da regolare, più concreti rispetto a una presunta ottimizzazione dello scheduler.

Landlock per lavoratori specializzati

Landlock è stato introdotto per la prima volta con Linux 5.13 e non costituisce quindi una novità originaria della serie 6.x. Nei kernel 6.x sono disponibili diversi livelli avanzati di ABI, a seconda della versione e del kernel della distribuzione. La funzione costituisce un meccanismo di sicurezza supplementare che consente a un processo di auto-limitare ulteriormente le proprie operazioni.

In quanto modulo di sicurezza Linux impilabile, Landlock agisce in aggiunta alle decisioni di accesso già in vigore; non sostituisce né i permessi dei file Unix né SELinux, AppArmor, i namespace o i container. Le regole possono, tra l’altro, limitare l’accesso al file system e vengono trasmesse ai processi figlio avviati successivamente. Le funzionalità effettive dipendono dall’ABI disponibile e dalla configurazione del kernel.

È opportuno Senza sbocco sul mare soprattutto per processi singoli sviluppati internamente o selezionati in modo mirato. Un convertitore per i file caricati dai clienti potrebbe leggere i file solo da una cartella di input e salvare i risultati esclusivamente in una cartella di output. Anche in caso di elaborazione errata del servizio, questo non dovrebbe essere in grado di leggere né chiavi SSH né segreti applicativi né percorsi di sistema generali. Questa limitazione integra un’attenta assegnazione dei diritti, ma non la rende superflua.

Una regola produttiva non deve basarsi esclusivamente su un kernel aggiornato. Landlock dispone di diverse versioni ABI; un'applicazione dovrebbe interrogare l'ABI disponibile in fase di esecuzione e richiedere solo i diritti di accesso o le funzioni supportate da tale ABI. In questo modo, può funzionare in modo graduale su sistemi meno recenti, anziché smettere completamente di funzionare a causa di un'interfaccia non disponibile.

A parte questo, si pone handled_access_fs stabilisce esplicitamente quali accessi al file system vengono gestiti da un insieme di regole e, in assenza di una regola corrispondente, vengono negati per impostazione predefinita. Questo accordo esplicito tra l’applicazione e il kernel impedisce che una sandbox diventi più restrittiva in modo inosservato a seguito di un semplice aggiornamento di sistema, causando così il malfunzionamento delle applicazioni. L'interrogazione dell'ABI e i diritti gestiti esplicitamente sono quindi correlati, ma risolvono problemi di compatibilità diversi.

Per il convertitore di file ne consegue un’implementazione graduale: dedurre le directory di lettura, scrittura e di lavoro necessarie dal flusso effettivo, tenere conto dei percorsi di errore e testare inizialmente in ambiente di staging. Una policy di esempio troppo succinta non costituirebbe una procedura di produzione affidabile, poiché i file temporanei, le librerie esterne e i programmi di supporto avviati potrebbero richiedere ulteriori accessi. Ulteriori misure relative all’isolamento dei servizi sono trattate anche nell’articolo su Rafforzamento del kernel per server di hosting.

È necessario prestare particolare attenzione in caso di OverlayFS. Le regole relative a un livello di overlay non limitano automaticamente la gerarchia di mount unificata e viceversa. Gli ambienti container e di build con overlay richiedono quindi una verifica specifica dei mount e dei percorsi di accesso concreti. Landlock rappresenta in questo contesto un possibile livello aggiuntivo, ma non una separazione generale dei clienti né un sostituto di un solido concetto di container o di autorizzazioni.

DAMON solo in casi particolari

DAMON e i meccanismi di recupero basati su di esso non possono essere classificati in modo generalizzato come funzioni introdotte per la prima volta con Linux 6.x. Per gli amministratori, ciò che conta è lo stato funzionale del kernel 6.x o della distribuzione concretamente in uso. DAMON monitora gli accessi alla memoria con l’obiettivo di classificare le aree in base al loro comportamento di utilizzo.

Partendo da questo presupposto, si cerca di DAMON_RECLAIM, per recuperare in modo proattivo la memoria non utilizzata da tempo esercitando una leggera pressione. Questo metodo integra il normale recupero basato su LRU; non è destinato a sostituirlo. La documentazione del kernel lo associa ai sistemi di memoria in generale soggetti a sovraallocazione e cita come esempio la virtualizzazione basata sul reporting delle pagine libere.

In questo scenario di virtualizzazione, il livello è fondamentale: gli ospiti segnalano all’host le pagine di memoria libere, che l’host può assegnare ad altri ospiti. Se un ospite segnala poca memoria libera, nonostante conservi pagine inattive da tempo, è possibile ricorrere a un recupero proattivo come ospite contribuire a segnalare all’host un maggior numero di pagine libere. DAMON_RECLAIM non rappresenta quindi, senza un’ulteriore verifica, una soluzione a livello di host per la memoria non utilizzata dagli ospiti.

Per un singolo server web o di database, questa non è quindi una misura standard. Anche negli ambienti virtualizzati occorre innanzitutto chiarire a quale livello si verifichi il sovraccarico e se la causa sia effettivamente rappresentata da aree rimaste inattive per lungo tempo. Colli di bottiglia della CPU, storage lento, limiti cgroup inadeguati o cache delle applicazioni attive possono spiegare gli stessi sintomi, senza che il reclaim proattivo rappresenti la risposta adeguata.

Le quote, i limiti di età e i watermark determinano quando e in che misura DAMON_RECLAIM opera. Non si tratta di valori predefiniti trasferibili: una selezione troppo aggressiva può sostituire prematuramente la cache dei file utile o le pagine di memoria necessarie in modo ricorrente. Ciò può causare operazioni I/O aggiuntive e richiedere tempo di CPU per un nuovo elaborazione, nonostante la memoria nominalmente libera aumenti.

Una decisione fondata richiede quindi misurazioni con parametri di riferimento chiari, quali lo spazio libero dichiarato dall’utente, l’attività di reclaim, il comportamento dello swap, la latenza dello storage e i tempi di risposta delle applicazioni. Testa prima le modifiche in un ambiente di staging comparabile, definisci un percorso di ritorno e monitora le modifiche durante fasi di carico rappresentative. Se questi presupposti non sono soddisfatti o se la causa della pressione sullo storage non è chiara, DAMON rimane deliberatamente disattivato.

Aggiornamenti, correzioni in tempo reale e riavvii

La manutenzione del kernel inizia con il confronto tra la nota di sicurezza, il pacchetto installato e il kernel effettivamente in esecuzione. Verifica quindi nelle note della tua distribuzione quale correzione sia prevista proprio per quel ramo del kernel e se sia necessario un riavvio. Un numero di versione 6.x più alto, di per sé, non indica né la presenza della patch né la disponibilità di una livepatch adeguata; le correzioni di sicurezza possono essere portate anche su kernel di distribuzioni precedenti.

Anche Livepatching non è stato introdotto come concetto solo con Linux 6.x. L'infrastruttura relativa ai kernel 6.x consente di applicare determinate modifiche al kernel durante l'esecuzione. Le patch cumulative in tempo reale possono sostituire in modo atomico una patch precedente con una più recente. I limiti documentati riguardano, tra l'altro, i cambiamenti di stato, i callback e il ritorno a patch precedenti.

Per verificare se per un determinato kernel di distribuzione sia disponibile una livepatch adeguata, è necessario fare riferimento all’offerta specifica e alle autorizzazioni del fornitore. Dall’infrastruttura generale del kernel non deriva né che ogni correzione di sicurezza sia disponibile in tempo reale, né che una patch applicata sostituisca in modo permanente un aggiornamento completo del kernel. Si raccomanda pertanto di continuare a prevedere regolari finestre di manutenzione.

Valuta innanzitutto l’urgenza e l’impatto di un aggiornamento, quindi verifica la versione dei pacchetti e del kernel in esecuzione e controlla l’offerta concreta di Livepatch. Dopo un normale aggiornamento del kernel con riavvio, verifica che il kernel previsto sia attivo e che i servizi critici, i percorsi di rete, i backup e il monitoraggio funzionino correttamente. Questa verifica fa parte della procedura di manutenzione e non dovrebbe essere dedotta dalla semplice raggiungibilità del server.

A riavvio previsto potrebbe comunque essere necessario nonostante il live patching. Le modifiche ai parametri di avvio del kernel, in genere, diventano effettive solo al successivo avvio. Per quanto riguarda driver, firmware dei dispositivi e hardware, la procedura dipende invece dal componente, dalla sua integrazione e dal processo di produzione: in alcuni casi è sufficiente un riavvio del modulo, del dispositivo o del servizio, mentre in altri è necessario un riavvio completo dell’host.

L'articolo di approfondimento su Live patching sui server AlmaLinux tratta un'implementazione concreta dipendente dalla distribuzione. Non trasferire tali procedure ad altri rami del kernel o fornitori senza averle verificate. Fanno fede i pacchetti, le versioni del kernel supportate e le istruzioni operative della piattaforma effettivamente utilizzata.

• Non apportare alcuna modifica, se il malfunzionamento osservato non ha ancora una causa identificabile.
• Non pianificare alcuna patch live o modifica del kernel senza un adeguato test di staging e una procedura di ripristino documentata.
• Non attivare alcuna funzione se l'applicazione o la piattaforma in questione non utilizza la relativa interfaccia.
• Non dare per scontato, in assenza di una finestra di manutenzione, che il live patching copra ogni aggiornamento del kernel.