💻 computer science

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

Dit artikel stelt een voorspellend, adaptief planningsmodel voor en evalueert dit, dat werkbelastingvoorspelling integreert met Ceph-bewuste opslagbeslissingen om resourcecontention en I/O-latentie in Kubernetes–Ceph hypergeconvergeerde infrastructuur draaiend op Proxmox VE aanzienlijk te verminderen, waarbij een superieure load balancing en prestaties wordt bereikt vergeleken met de standaard Kubernetes-scheduler.

Oorspronkelijke auteurs: Doston Khasanov, Abdurauf Abdullaev, Halimjon Khujamatov, Temirbek Toshtemirov, Alisher Mamatov, Razvan Craciunescu

Gepubliceerd 2026-07-23

📖 8 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Doston Khasanov, Abdurauf Abdullaev, Halimjon Khujamatov, Temirbek Toshtemirov, Alisher Mamatov, Razvan Craciunescu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een bruisende stad voor waar de wegen, het elektriciteitsnet en de watervoorziening allemaal in dezelfde buurt wonen. In de wereld van moderne computing wordt dit "hyperconverged infrastructure" genoemd. In plaats van aparte gebouwen voor servers (computing), harde schijven (opslag) en netwerkkabels, is alles compact samengepakt op dezelfde fysieke machines. Het is efficiënt en bespaart ruimte, maar het creëert een lastig verkeersprobleem. Als een enorme vrachtwagen (een data-intensief programma) een straat probe de door te willen rijden terwijl er een bouwploeg (een opslagtaak) vlak naast werkt, loopt alles vast.

Om deze digitale stad te beheren, gebruiken we een systeem genaamd Kubernetes. Zie Kubernetes als de verkeersregelaar van de stad. Zijn taak is om te beslissen welk gebouw (server) welke nieuwe vrachtwagen (softwareprogramma, of "pod") krijgt. Echter, de standaard verkeersregelaar is een beetje ouderwets. Hij kijkt alleen naar wat er nu gebeurt. Hij ziet dat een gebouw leeg is en zegt: "Geweldig, stuur de vrachtwagen daarheen!" Hij realiseert zich niet dat het elektriciteitsnet van het gebouw al moeite heeft door een nabijgelegen bouwproject, of dat de vrachtwagen bijna arriveert met een lading die over vijf minuten voor een verkeersopstopping zal zorgen. Deze reactieve stijl leidt er vaak toe dat sommige gebouwen onder te veel werk worden verpletterd terwijl andere stilzitten, en de "wegen" (dataopslag) raken verstopt, waardoor alles vertraagt.

Dit is de puzzel die een team van onderzoekers van universiteiten in Oezbekistan en Roemenië besloten op te lossen. Ze vroegen zich af: Wat als onze verkeersregelaar in de toekomst kon kijken? Wat als hij de verkeersopstoppingen zou kunnen voorspellen voordat ze gebeuren en de vrachtwagens dienovereenkomstig zou verplaatsen? In hun paper bouwden ze een slimmer, "voorspellend en adaptief" systeem dat niet alleen reageert op het heden, maar ook plant voor de directe toekomst. Door een eenvoudige voorspellingsmethode te combineren met een nieuwe manier van softwareplaatsing, slaagden ze erin de chaos in hun teststad te verminderen, waarmee ze bewezen dat soms een beetje vooruitziendheid beter is dan een supercomplexe hersenkracht.

Het Probleem: De Reactieve Verkeersregelaar

In de digitale wereld hebben de onderzoekers een "hyperconverged" testomgeving opgezet met drie belangrijke tools: Proxmox VE (de fundering die de servers vasthoudt), Ceph (het opslagsysteem dat fungeert als een gigantische gedeelde harde schijf) en Kubernetes (de verkeersregelaar).

In een standaardopstelling speelt Kubernetes op safe. Het wacht tot een server een programma draait, controleert hoeveel CPU (hersencapaciteit) en geheugen (kortetermijngeheugen) er wordt gebruikt, en beslist dan waar het volgende programma terechtkomt. Het is als een verkeersagent die alleen de auto's ziet die momenteel op de weg rijden. Als een server vrij lijkt, stuurt de agent een nieuwe auto daarheen. Maar in een hypergeconvergeerd systeem moet de "auto" mogelijk toegang krijgen tot de "opslag" (de harde schijf) op diezelfde server. Als de agent niet weet dat de opslag van de server al druk bezig is, komt de nieuwe auto vast te staan, wat voor vertraging zorgt.

De onderzoekers ontdekten dat deze "reactieve" aanpak tot drie grote hoofdpijnklachten leidt:

Resource Contention (Resource-conflicten): Te veel programma's die tegelijkertijd vechten om dezelfde CPU of opslag.
Load Imbalance (Onbalans in de belasting): Sommige servers zweten zich kapot (draaien op 95% capaciteit) terwijl andere een dutje doen (draaien op 40% capaciteit).
Storage Latency (Opslaglatentie): De tijd die nodig is om gegevens te lezen of te schrijven wordt trager omdat het opslagsysteem overbelast is.

De Oplossing: Een Kristallen Bol en een Flexibele Kaart

Het team stelde een nieuw model voor dat werkt als een verkeersregelaar met een kristallen bol en een flexibele kaart. Hun systeem bestaat uit vier hoofdonderdelen die in een lus samenwerken:

De Kristallen Bol (Voorspelling): In plaats van alleen naar het huidige moment te kijken, gebruikt het systeem een wiskundige truc genaamd "Exponentially Weighted Moving Average" (EWMA). Denk hierbij aan een weervoorspeller die naar de regen van de afgelopen paar dagen kijkt om te voorspellen of je morgen een paraplu nodig hebt. Het voorspelt hoeveel CPU en opslag een programma de komende paar minuten nodig zal hebben. Ze ontdekten dat een specifieke instelling voor deze "voorspelling" het beste werkte, waarbij de CPU-behoeften werden voorspeld met een fout van ongeveer 8,4%, het geheugen met 5,1% en de opslagbehoeften met 12,3%.
De Flexibele Kaart (Adaptieve Planning): Zodra het systeem weet wat er aankomt, dumpt het het programma niet zomaar op de eerste lege server. Het berekent de "voorspelde belasting" voor elke server. Het vraagt: "Als ik dit programma hier plaats, is de server dan over vijf minuten overbelast?" Als het antwoord ja is, slaat het die server over en zoekt het een betere plek.
De Opslagbewuste Beslissing: Dit is het geheime ingrediënt. Het systeem kijkt niet alleen naar de CPU; het controleert ook de gezondheid van de Ceph-opslag (de "OSD" of opslagdaemons). Als een server een drukke opslag schijf heeft, weet het systeem dat het de zware dataprogramma's ergens anders naartoe moet sturen, zelfs als de CPU vrij lijkt.
De Dynamische Aanpassing: Als een programma plotseling meer kracht nodig heeft dan verwacht, kan het systeem automatisch de limieten aanpassen zonder te crashen of te herstarten, om de doorstroom soepel te houden.

Het Experiment: Een Test met Drie Steden

Om te zien of dit werkte, bouwden de onderzoekers een echte, kleinschalige stad met drie fysieke computers (nodes). Elke node had een krachtige processor, 32 GB RAM en twee snelle NVMe SSD's (super-snelle harde schijven). Ze vulden deze stad met verschillende soorten verkeer:

CPU-zware vrachtwagens: Programma's die alleen getallen verwerken (zoals stress-ng).
Opslag-zware vrachtwagens: Programma's die enorme hoeveelheden gegevens lezen en schrijven (zoals fio).
Gemengd verkeer: Databases en webapplicaties die een beetje van beide doen (zoals YCSB).

Ze draaiden twee scenario's naast elkaar gedurende 30 minuten.

Scenario A (De Oude Manier): Standaard Kubernetes zonder voorspelling.
Scenario B (De Nieuwe Manier): Hun voorspellende, adaptieve model.

De Resultaten: Soepelere Wegen, Snellere Levering

De resultaten waren een duidelijke overwinning voor het nieuwe model, en de cijfers vertellen een levendig verhaal van verbetering.

1. De Belasting Verdelen:
Op de oude manier was het verkeer extreem ongelijkmatig. Eén server schreeuwde onder de druk en draaide op 95,64% capaciteit, terwijl een andere nauwelijks werkte op 39,73%. De "onbalans" (het verschil tussen de drukste en de rustigste server) was een chaotische 53,29%.
Met het nieuwe model werd het verkeer perfect gladgestreken. De drukste server daalde naar 67,41% en de rustigste werd wakker op 56,33%. De onbalans kelderde naar slechts 10,98%. Dat is een reductie van 79,4% in chaos. Het nieuwe systeem hield alle servers in een nauwe, gelukkige band van 54% tot 68% gebruik, wat betekent dat niemand overwerkt was en niemand zich verveelde.

2. De Opslag Versnellen:
Omdat het nieuwe systeem wist waar de opslag druk was, voorkwam het dat de wegen verstopt raakten. De gemiddelde tijd die nodig was om opslagwijzigingen toe te passen (latentie) daalde van 1,11 ms naar 1,00 ms. Hoewel dat een minuscuul verschil lijkt, betekent het in de wereld van data dat het systeem consistenter en betrouwbaarder is. Ook de "worst-case" vertraging (de 95e percentiel) verbeterde van 1,15 ms naar 1,00 ms, wat aantoont dat het systeem het zware verkeer veel beter aan kon.

3. Geen Extra Kosten:
De onderzoekers merkten er zorgvuldig bij op dat ze niet de hele stad hoefden te herbouwen of dure, complexe AI-hersenen nodig hadden. Ze gebruikten standaardtools (Kubernetes en Prometheus API's) en een eenvoudige voorspellingsmethode. Ze bewezen dat je geen supercomplex algoritme nodig hebt om geweldige resultaten te behalen; je moet alleen de lijnen trekken tussen computing en opslag.

De Conclusie: Integratie boven Complexiteit

Het meest opwindende deel van dit paper is niet alleen dat het werkte, maar waarom het werkte. De onderzoekers stellen dat het probleem niet was dat de oude verkeersregelaar te dom was, maar dat hij het probleem slechts in één dimensie bekijkt. Hij zag de CPU, maar negeerde de opslag.

Door simpelweg een laag van "vooruitziendheid" en "opslagbewustzijn" aan het bestaande systeem toe te voegen, behaalden ze enorme winsten. Ze lieten zien dat architecturale integratie (het laten praten van computing en opslag met elkaar) krachtiger is dan simpelweg de algoritmen complexer maken. Zelfs een eenvoudig, lichtgewicht voorspellingsinstrument, gecombineerd met slimme plaatsing, kan de grootste knelpunten in een hypergeconvergeerd systeem oplossen.

Uiteindelijk suggereert dit paper dat de toekomst van efficiënte computing niet noodzakelijkerwijs ligt in het bouwen van grotere, intelligentere hersenen, maar in het zorgen dat de verschillende onderdelen van het systeem elkaars hand vasthouden en samen vooruit kijken. De verkeersregelaar hoeft geen genie te zijn; hij hoeft alleen maar te weten wat er om de volgende bocht komt.

Technische Samenvatting: Voorspellende en Adaptieve Resource-planning voor Kubernetes–Ceph Hyperconverged Infrastructuur op Proxmox VE

Probleemstelling
Hyperconverged infrastructuur (HCI) integreert compute, opslag en netwerken op dezelfde fysieke nodes, maar standaard Kubernetes-scheduling werkt reactief op basis van instantane resource-metrieken. Deze reactieve aanpak mist bewustzijn van de onderliggende Ceph-opslagstatus, wat leidt tot resource-concurrentie, lastonbalans en verhoogde I/O-latentie wanneer compute- en opslagworkloads strijden om dezelfde fysieke resources. Bestaand onderzoek heeft zich grotendeels gericht op scheduling en opslagoptimalisatie in isolatie, of gefocust op gedisaggregeerde architecturen, en is erin gefaald een geïntegreerd framework te bieden dat kortetermijn-workloadvoorspelling koppelt aan opslagbewuste plaatsing op een enkele HCI-control plane.

Methodologie
De auteurs stellen een verenigd, closed-loop control model voor dat volledig opereert via standaard Kubernetes- en Prometheus-API's zonder kerncomponenten van het systeem te wijzigen. De architectuur bestaat uit vier onderling verbonden stadia:

Monitoring: Directe metriekverzameling van Kubernetes, Ceph en Proxmox VE via API's.
Voorspelling (Prediction): Een lichtgewicht workload-vraagvoorspeller met behulp van een Exponentially Weighted Moving Average (EWMA) algoritme. Deze component voorspelt de resource-vraag (CPU, geheugen, I/O) voor het volgende scheduling-interval op basis van historische gegevens. De studie identificeerde een afvlakkingsfactor ( $\alpha$ ) van 0,3 als empirisch optimaal, waarbij Mean Absolute Percentage Errors (MAPE) werden behaald van 8,4% voor CPU, 5,1% voor geheugen en 12,3% voor I/O.
Besluitvorming (Adaptieve Scheduling): De scheduler maakt gebruik van de voorspelde vraag in plaats van de huidige belasting om plaatsingsbeslissingen te nemen. Het minimaliseert de lastonbalans ( $\Delta_k$ ) en zorgt ervoor dat de geprojecteerde resource-benutting de node-capaciteit niet overschrijdt.
Adaptatie (Opslagbewuste Plaatsing): Het model incorporeert Ceph OSD-belasting en apply-latentie in de scoringfunctie voor pod-plaatsing. Dit voorkomt dat opslagintensieve workloads worden geplaatst op nodes die al belast worden door hoge I/O of opslaglatentie, waardoor de compute-scheduling effectief wordt gekoppeld aan de opslagstatus.

Het systeem werd geïmplementeerd en geëvalueerd op een echte drie-node testbed draaiend op Proxmox VE 9.1.4, Ceph 19.2.3 en Kubernetes 1.29.15. Experimenten omvatten gemengde workloads inclusief CPU-intensieve (stress-ng), I/O-intensieve (fio) en transactionele (YCSB) taken.

Belangrijkste Resultaten
Vergeleken met de standaard Kubernetes-scheduler vertoonde het voorgestelde model significante prestatieverbeteringen:

Lastbalancering: De CPU-lastonbalans werd met 79,4% verminderd, van een gemiddelde van 53,29% naar 10,98%.
Efficiëntie van Benutting: De maximale node-benutting daalde van 95,64% naar 6 de 67,41%, terwijl de minimale benutting steeg van 39,73% naar 56,33%, wat resource-hotspots en idle nodes effectief elimineert.
Opslagprestaties: De gemiddelde Ceph OSD apply-latentie verbeterde van 1,11 ms naar 1,00 ms, waarbij ook de 95e percentiel latentie daalde van 1,15 ms naar 1,00 ms.
Stabiliteit: De Ceph-cluster behield een HEALTH_OK status gedurende de gehele evaluatie, en het model beheerde transiënte lastpieken succesvol zonder dat pod-migraties of systeemherstarts nodig waren.

Betekenis en Claims
Het paper betoogt dat de primaire bottleneck in HCI-prestaties niet een gebrek aan algoritmische verfijning in voorspelling is, maar de inherente reactieve, single-layer architectuur van de standaard Kubernetes-scheduling. De auteurs beweren dat architecturale integratie over de compute- en opslaglagen grotere prestatiewinsten oplevert dan het enkel vergroten van de algoritmische complexiteit.

De belangrijkste bijdragen zoals benadrukt door de auteurs zijn:

Verenigd Framework: Een structurele beschrijving van een voorspellend en adaptief framework dat demand forecasting, adaptieve scheduling, dynamische resourceallocatie en opslagbewuste plaatsing samenbrengt.
Cross-Layer Coördinatie: Een mechanisme dat plaatsingsbeslissingen optimaliseert door voorspelde I/O-vraag en Ceph OSD-belasting te incorporeren, waardoor wordt voorkomen dat zware opslagworkloads landen op reeds drukke nodes zonder kerncomponenten van het systeem te wijzigen.
Praktische Toepasbaarheid: Het model vertrouwt op standaard API's en lichtgewicht heuristieken (EWMA) in plaats van complexe machine learning-modellen, wat het inzetbaar maakt in real-world open-source HCI-omgevingen.
Empirisch Bewijs: De studie levert reproduceerbaar bewijs vanuit een fysieke testbed dat bevestigt dat cross-layer integratie de CPU-balancering aanzienlijk verbetert en de opslaglatentie vermindert onder realistische gemengde workloads.

De auteurs concluderen dat zelfs eenvoudige, lichtgewicht voorspellingsmechanismen, wanneer gecombineerd met adaptieve scheduling en opslagbewuste besluitvorming, aanzienlijke prestatieverbeteringen kunnen bereiken (79,4% reductie in onbalans) die die van meer complexe machine learning-gebaseerde benaderingen in gerelateerde studies overtreffen.