💻 computer science

Predictive and Adaptive Resource Scheduling for Kubernetes–Ceph Hyperconverged Infrastructure on Proxmox VE

Questo articolo propone e valuta un modello di scheduling predittivo e adattivo che integra la previsione del carico di lavoro con decisioni di storage consapevole di Ceph per ridurre significativamente la contesa delle risorse e la latenza di I/O in un'infrastruttura iperconvergente Kubernetes–Ceph in esecuzione su Proxmox VE, ottenendo un bilanciamento del carico e prestazioni superiori rispetto allo scheduler predefinito di Kubernetes.

Autori originali: Doston Khasanov, Abdurauf Abdullaev, Halimjon Khujamatov, Temirbek Toshtemirov, Alisher Mamatov, Razvan Craciunescu

Pubblicato 2026-07-23

📖 8 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Doston Khasanov, Abdurauf Abdullaev, Halimjon Khujamatov, Temirbek Toshtemirov, Alisher Mamatov, Razvan Craciunescu

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate una città frenetica dove le strade, la rete elettrica e l'approvvigionamento idrico vivono tutti nello stesso quartiere. Nel mondo dell'informatica moderna, questo viene chiamato "infrastruttura iperconvergente". Invece di avere edifici separati per i server (calcolo), gli hard disk (archiviazione) e i cavi di rete, tutto è compresso strettamente sugli stessi macchinari fisici. È efficiente e fa risparmiare spazio, ma crea un complicato problema di traffico. Se un enorme camion per le consegne (un programma ad alto carico di dati) cerca di percorrere una strada mentre un cantiere (un compito di archiviazione) sta lavorando proprio accanto a lui, tutto si blocca.

Per gestire questa città digitale, usiamo un sistema chiamato Kubernetes. Pensate a Kubernetes come al controllore del traffico della città. Il suo compito è decidere quale edificio (server) riceverà il nuovo camion per le consegne (programma software, o "pod"). Tuttavia, il controllore del traffico standard è un po' vecchio stile. Guarda solo ciò che sta accadendo in questo momento. Vede che un edificio è vuoto e dice: "Ottimo, manda il camion lì!". Non si rende conto che la rete elettrica di quell'edificio sta già lottando a causa di un progetto edilizio nelle vicinanze, o che il camion sta per arrivare con un carico che causerà un ingorgo tra cinque minuti. Questo stile reattivo porta spesso alcuni edifici a essere schiacciati da troppo lavoro mentre altri rimangono inattivi, e le "strade" (archiviazione dati) si intasano, rallentando tutto.

Questo è l'enigma che un team di ricercatori provenienti da università dell'Uzbekistan e della Romania ha deciso di risolvere. Si sono chiesti: E se il nostro controllore del traffico potesse sbirciare nel futuro? E se potesse prevedere dove si creeranno gli ingorghi prima che accadano e spostare i camion di conseguenza? Nel loro articolo, hanno costruito un sistema più intelligente, "predittivo e adattivo", che non si limita a reagire al presente ma pianifica il futuro immediato. Combinando uno strumento di previsione semplice con un nuovo modo di posizionare il software, sono riusciti a regolarizzare il caos nella loro città di test, dimostrando che a volte, un po' di lungimiranza è meglio di un cervello super complesso.

Il Problema: Il Controllore del Traffico Reattivo

Nel mondo digitale, i ricercatori hanno allestito un banco di prova "iperconvergente" utilizzando tre strumenti principali: Proxmox VE (la base che sostiene i server), Ceph (il sistema di archiviazione che funge da enorme hard disk condiviso) e Kubernetes (il controllore del traffico).

In una configurazione standard, Kubernetes gioca sul sicuro. Aspetta che un server stia eseguendo un programma, controlla quanta CPU (potenza di calcolo) e memoria (memoria a breve termine) vengono utilizzate, e poi decide dove posizionare il programma successivo. È come un vigile urbano che vede solo le auto attualmente sulla strada. Se un server sembra libero, il vigile invia una nuova auto lì. Ma in un sistema iperconvergente, l'"auto" potrebbe dover accedere all' "archiviazione" (l'hard disk) su quello stesso server. Se il vigile non sa che l'archiviazione del server è già occupata, la nuova auto rimane bloccata, causando un ritardo.

I ricercatori hanno scoperto che questo approccio "reattivo" porta a tre grandi mal di testa:

Contesa delle Risorse: Troppi programmi che combattono per la stessa CPU o archiviazione contemporaneamente.
Squilibrio del Carico: Alcuni server stanno sudando copiosamente (eseguendo al 95% della capacità) mentre altri riposano (al 40% della capacità).
Latenza di Archiviazione: Il tempo necessario per leggere o scrivere dati diventa più lento perché il sistema di archiviazione è sovraccarico.

La Soliazione: Una Palla di Cristallo e una Mappa Flessibile

Il team ha proposto un nuovo modello che agisce come un controllore del traffico con una palla di cristallo e una mappa flessibile. Il loro sistema ha quattro parti principali che lavorano insieme in un ciclo:

La Palla di Cristallo (Previsione): Inveve di guardare solo il momento attuale, il sistema utilizza un trucco matematico chiamato "Media Mobile Esponenzialmente Pesata" (EWMA). Pensate a questo come a un previsore del tempo che guarda le piogge degli ultimi giorni per indovinare se avrete bisogno di un ombrello domani. Prevede quanta CPU e archiviazione richiederà un programma nei prossimi minuti. Hanno scoperto che un'impostazione specifica per questa "previsione" funzionava meglio, prevedendo le necessità di CPU con un errore dell'8,4%, la memoria con un errore del 5,1% e le necessità di archiviazione con un errore del 12,3%.
La Mappa Flessibile (Scheduling Adattivo): Una volta che il sistema sa cosa sta arrivando, non scarica semplicemente il programma sul primo server vuoto. Calcola il "carico previsto" per ogni server. Chiede: "Se metto questo programma qui, il server sarà sovraccarico tra cinque minuti?". Se la risposta è sì, salta quel server e ne trova uno migliore.
La Decisione Consapevole dell'Archiviazione: Questa è la formula segreta. Il sistema non guarda solo la CPU; controlla anche lo stato di salute dell'archiviazione Ceph (i daemon OSD o di archiviazione). Se un server ha un'unità di archiviazione impegnata, il sistema sa di dover inviare i programmi pesanti altrove, anche se la CPU sembra libera.
L'Aggiustamento Dinamico: Se un programma improvvisamente richiede più potenza di quanto previsto, il sistema può regolare automaticamente i suoi limiti senza crash o riavvii, mantenendo fluido il flusso.

L'Esperimento: Un Test in Tre Città

Per vedere se questo funzionava, i ricercatori hanno costruito una vera, piccola città utilizzando tre computer fisici (nodi). Ogni nodo aveva un processore potente, 32 GB di RAM e due SSD NVMe velocissimi (hard disk super veloci). Hanno riempito questa città con diversi tipi di traffico:

Camion pesanti per la CPU: Programmi che si limitano a elaborare numeri (come stress-ng).
Camion pesanti per l'archiviazione: Programmi che leggono e scrivono enormi quantità di dati (come fio).
Traffico misto: Database e applicazioni web che fanno un po' di tutto (come YCSB).

Hanno eseguito due scenari affiancati per 30 minuti.

Scenario A (Il Vecchio Modo): Kubernetes standard senza previsione.
Scenario B (Il Nuovo Modo): Il loro modello predittivo e adattivo.

I Risultati: Strade Più Fluide, Consegne Più Veloci

I risultati sono stati una chiara vittoria per il nuovo modello, e i numeri raccontano una storia vivida di miglioramento.

1. Bilanciare il Carico:
Nel vecchio modo, il traffico era estremamente disomogeneo. Un server stava urlando sotto la pressione, operando al 95,64% della capacità, mentre un altro lavorava appena al 39,73%. Lo "squilibrio" (la differenza tra il server più impegnato e quello più tranquillo) era un caotico 53,29%.
Con il nuovo modello, il traffico si è regolarizzato perfettamente. Il server più impegnato è sceso al 67,41%, e quello meno attivo si è svegliato al 56,33%. Lo squilibrio è crollato a solo il 10,98%. Si tratta di una riduzione del caos del 79,4%. Il nuovo sistema ha mantenuto tutti i server in una stretta e felice fascia di utilizzo tra il 54% e il 68%, il che significa che nessuno era sovraccaricato e nessuno era annoiato.

2. Velocizzare l'Archiviazione:
Poiché il nuovo sistema sapeva dove l'archiviazione era impegnata, ha evitato di intasare le strade. Il tempo medio per applicare le modifiche all'archiviazione (latenza) è sceso da 1,11 ms a 1,00 ms. Anche se sembra una differenza minima, nel mondo dei dati, significa che il sistema è più costante e affidabile. Anche il ritardo nel "caso peggiore" (il 95° percentile) è migliorato da 1,15 ms a 1,00 ms, dimostando che il sistema gestiva molto meglio il traffico pesante.

3. Nessun Costo Extra:
I ricercatori hanno sottolineato con cura che non hanno dovuto ricostruire l'intera città o utilizzare cervelli IA costosi e complessi. Hanno utilizzato strumenti standard (Kubernetes e API di Prometheus) e un metodo di previsione semplice. Hanno dimostrato che non è necessario un algoritmo super complesso per ottenere ottimi risultati; basta connettere i punti tra calcolo e archiviazione.

La Conclusione: Integrazione sopra la Complessità

La parte più entusiasmante di questo articolo non è solo che ha funzionato, ma perché ha funzionato. I ricercatori sostengono che il problema non fosse che il vecchio controllore del traffico fosse troppo stupido; era che stava guardando il problema in una sola dimensione. Vedeva la CPU ma ignorava l'archiviazione.

Semplicemente aggiungendo un livello di "lungimiranza" e "consapevolezza dell'archiviazione" al sistema esistente, hanno ottenuto guadagni enormi. Hanno dimostrato che l'integrazione architettonica (far sì che il calcolo e l'archiviazione parlino tra loro) è più potente del semplice rendere più complicati gli algoritmi. Anche un semplice strumento di previsione leggero, se combinato con un posizionamento intelligente, può risolvere i colli di bottiglia più grandi in un sistema iperconvergente.

In definitiva, questo articolo suggerisce che il futuro di un'informatica efficiente non è necessariamente costruire cervelli più grandi e intelligenti, ma assicurarsi che le diverse parti del sistema si tengano per mano e guardino avanti insieme. Il controllore del traffico non ha bisogno di essere un genio; ha solo bisogno di sapere cosa sta arrivando dietro l'angolo.

Sintesi Tecnica: Programmazione delle Risorse Predittiva e Adattiva per Infrastrutture Iperconvergenti Kubernetes–Ceph su Proxmox VE

Definizione del Problema
L'infrastruttura iperconvergente (HCI) integra calcolo, storage e networking sugli stessi nodi fisici, tuttavia la programmazione standard di Kubernetes opera in modo reattivo basandosi su metriche istantanee delle risorse. Questo approccio reattivo manca della consapevolezza dello stato sottostante dello storage Ceph, portando a contesa delle risorse, squilibrio del carico ed elevata latenza di I/O quando i carichi di lavoro di calcolo e di storage competono per le stesse risorse fisiche. La ricerca esistente ha affrontato ampiamente la programmazione e l'ottimizzazione dello storage in modo isolato o si è concentrata su architetture disaggregate, fallendo nel fornire un framework integrato che accoppi la previsione del carico a breve termine con il posizionamento consapevole dello storage su un unico piano di controllo HCI.

Metodologia
Gli autori propongono un modello di controllo a ciclo chiuso unificato che opera interamente attraverso le API standard di Kubernetes e Prometheus senza modificare i componenti core del sistema. L'architettura è composta da quattro fasi interconnesse:

Monitoraggio: Raccolta diretta delle metriche da Kubernetes, Ceph e Proxmox VE tramite API.
Previsione: Un previsore leggero della domanda di carico utilizzando un algoritmo di Media Mobile Esponenzialmente Pesata (EWMA). Questa componente prevede la domanda di risorse (CPU, memoria, I/O) per l'intervallo di programmazione successivo basandosi sui dati storici. Lo studio ha identificato un fattore di smoothing ( $\alpha$ ) di 0,3 come empiricamente ottimale, raggiungendo Errori Assoluti Percentuali Medi (MAPE) dell'8,4% per la CPU, 5,1% per la memoria e 12,3% per l'I/O.
Processo Decisionale (Programmazione Adattiva): Lo scheduler utilizza la domanda prevista anziché il carico attuale per prendere decisioni di posizionamento. Esso minimizza lo squilibrio del carico ( $\Delta_k$ ) e garantisce che l'utilizzo previsto delle risorse non superi la capacità del nodo.
Adattamento (Posizionamento Consapevole dello Storage): Il modello incorpora il carico degli OSD di Ceph e la latenza di applicazione nel modulo di scoring per il posizionamento dei pod. Ciò evita che carichi di lavoro intensivi di I/O vengano posizionati su nodi già gravati da un alto I/O o latenza di storage, accoppiando efficacemente la programmazione del calcolo con lo stato dello storage.

Il sistema è stato implementato e valutato su un testbed reale a tre nodi eseguendo Proxmox VE 9.1.4, Ceph 19.2.3 e Kubernetes 1.29.15. Gli esperimenti hanno coinvolto carichi di lavoro misti, tra cui compiti intensivi di CPU (stress-ng), intensivi di I/O (fio) e transazionali (YCSB).

Risultati Chiave
Rispetto allo scheduler predefinito di Kubernetes, il modello proposto ha dimostrato miglioramenti significativi delle prestazioni:

Bilanciamento del Carico: Lo squilibrio del carico della CPU è stato ridotto del 79,4%, scendendo da una media del 53,29% al 10,98%.
Efficienza di Utilizzo: L'utilizzo massimo del nodo è diminuito dal 95,64% al 67,41%, mentre l'utilizzo minimo è aumentato dal 39,73% al 56,33%, eliminando efficacemente hotspot di risorse e nodi inattivi.
Prestazioni dello Storage: La latenza media di applicazione degli OSD di Ceph è migliorata da 1,11 ms a 1,00 ms, con una riduzione della latenza al 95° percentile da 1,15 ms a 1,00 ms.
Stabilità: Il cluster Ceph ha mantenuto uno stato HEALTH_OK durante tutta la valutazione, e il modello ha gestito con successo i picchi di carico transitori senza richiedere migrazioni di pod o riavvii del sistema.

Significatività e Rivendicazioni
Il documento sostiene che il collo di bottiglia primario nelle prestazioni HCI non sia la mancanza di sofisticatezza algoritmica nella previsione, ma piuttosto l'inerente architettura reattiva a singolo livello dello scheduling predefinito di Kubernetes. Gli autori affermano che l'integrazione architettonica tra i livelli di calcolo e storage produce guadagni di prestazione maggiori rispetto al solo aumento della complessità algoritmica.

I principali contributi evidenziati dagli autori includono:

Framework Unificato: Una descrizione strutturale di un framework predittivo e adattivo che coesiona la previsione della domanda, la programmazione adattiva, l'allocazione dinamica delle risorse e il posizionamento consapevole dello storage.
Coordinamento Cross-Layer: Un meccanismo che ottimizza le decisioni di posizionamento incorporando la domanda di I/O prevista e il carico degli OSD di Ceph, evitando che carichi di lavoro pesanti per lo storage finiscano su nodi già occupati senza modificare i componenti core del sistema.
Applicabilità Pratica: Il modello si affida a API standard ed euristiche leggere (EWMA) piuttosto che a modelli complessi di machine learning, rendendolo implementabile in ambienti HCI open-source reali.
Evidenza Empirica: Lo studio fornisce prove riproducibili da un testbed fisico che confermano come l'integrazione cross-layer migliori significativamente il bilanciamento della CPU e riduca la latenza dello storage sotto carichi di lavoro misti realistici.

Gli autori concludono che anche meccanismi di previsione semplici e leggeri, se combinati con una programmazione adattiva e un processo decisionale consapevole dello storage, possono raggiungere miglioramenti delle prestazioni sostanziali (una riduzione dello squilibrio del 79,4%) che superano quelli riportati da approcci basati su machine learning più complessi in studi correlati.