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

Imaginez une ville bouillonnante où les routes, le réseau électrique et l'approvisionnement en eau vivent tous au sein du même quartier. Dans le monde de l'informatique moderne, cela s'appelle une « infrastructure hyperconvergée ». Au lieu d'avoir des bâtiments séparés pour les serveurs (calcul), les disques durs (stockage) et les câbles réseau, tout est regroupé étroitement sur les mêmes machines physiques. C'est efficace et cela permet de gagner de l'espace, mais cela crée un problème de circulation complexe. Si un énorme camion de livraison (un programme gourmand en données) tente de circuler dans une rue alors qu'une équipe de construction (une tâche de stockage) travaille juste à côté, tout se retrouve bloqué.

Pour gérer cette ville numérique, nous utilisons un système appelé Kubernetes. Voyez Kubernetes comme le contrôleur de trafic de la ville. Son rôle est de décider quel bâtiment (serveur) recevra quel nouveau camion de livraison (un programme logiciel, ou « pod »). Cependant, le contrôleur de trafic standard est un peu démodé. Il ne regarde que ce qui se passe en ce moment même. Il voit qu'un bâtiment est vide et dit : « Super, envoyez le camion là-bas ! ». Il ne réalise pas que le réseau électrique du bâtiment est déjà en difficulté à cause d'un projet de construction à proximité, ou que le camion est sur le point d'arriver avec une cargaison qui provoquera un embouteillage dans cinq minutes. Ce style réactif conduit souvent à ce que certains bâtiments soient écrasés sous trop de travail tandis que d'autres restent inactifs, et les « routes » (le stockage des données) s'engorgent, ralentissant tout le processus.

C'est ce casse-tête qu'une équipe de chercheurs issus d'universités d'Ouzbékistan et de Roumanie a décidé de résoudre. Ils se sont demandé : Et si notre contrôleur de trafic pouvait jeter un coup d'œil dans le futur ? Et si nous pouvions prédire où les embouteillages se produiraient avant qu'ils n'arrivent et déplacer les camions en conséquence ? Dans leur article, ils ont construit un système plus intelligent, « prédictif et adaptatif », qui ne se contente pas de réagir au présent mais planifie le futur immédiat. En combinant un outil de prédiction simple avec une nouvelle façon de placer les logiciels, ils ont réussi à lisser le chaos dans leur ville de test, prouvant que parfois, un peu de prévoyance vaut mieux qu'un cerveau super complexe.

Le Problème : Le Contrôleur de Trafic Réactif

Dans le monde numérique, les chercheurs ont mis en place un banc d'essai « hyperconvergé » utilisant trois outils principaux : Proxmox VE (la fondation qui soutient les serveurs), Ceph (le système de stockage qui agit comme un immense disque dur partagé) et Kubernetes (le contrôleur de trafic).

Dans une configuration standard, Kubernetes joue la prudence. Il attend qu'un serveur exécute un programme, vérifie la quantité de CPU (puissance de calcul) et de mémoire (mémoire à court terme) utilisée, puis décide où placer le programme suivant. C'est comme un agent de circulation qui ne voit que les voitures actuellement sur la route. Si un serveur semble libre, l'agent y envoie une nouvelle voiture. Mais dans un système hyperconvergé, la « voiture » peut avoir besoin d'accéder au « stockage » (le disque dur) sur ce même serveur. Si l'agent ne sait pas que le stockage du serveur est déjà occupé, la nouvelle voiture reste coincée, provoant un retard.

Les chercheurs ont découvert que cette approche « réactive » entraîne trois gros maux de tête :

1. Contention de ressources : Trop de programmes se battant pour le même CPU ou le même stockage en même temps.
2. Déséquilibre de charge : Certains serveurs transpirent à grosses gouttes (tournant à 95 % de leur capacité) tandis que d'autres font la sieste (tournant à 40 %).
3. Latence de stockage : Le temps nécessaire pour lire ou écrire des données devient plus lent car le système de stockage est surchargé.

La Solution : Une Boule de Cristal et une Carte Flexible

L'équipe a proposé un nouveau modèle qui agit comme un contrôleur de trafic doté d'une boule de cristal et d'une carte flexible. Leur système comprend quatre parties principales travaillant ensemble en boucle :

1. La Boule de Cristal (Prédiction) : Au lieu de simplement regarder le moment présent, le système utilise un tour mathématique appelé « Moyenne Mobile Pondérée Exponentiellement » (EWMA). Considérez cela comme un prévisionneur météorologique qui observe les derniers jours de pluie pour deviner si vous aurez besoin d'un parapluie demain. Il prédit de combien de CPU et de stockage un programme aura besoin dans les prochaines minutes. Ils ont constaté qu'un réglage spécifique pour cette « prévision » fonctionnait le mieux, prédisant les besoins en CPU avec environ 8,4 % d'erreur, la mémoire avec 5,1 % d'erreur et les besoins en stockage avec 12,3 % d'erreur.
2. La Carte Flexible (Ordonnancement Adaptatif) : Une fois que le système sait ce qui arrive, il ne se contente pas de déposer le programme sur le premier serveur vide. Il calcule la « charge prédite » pour chaque serveur. Il demande : « Si je place ce programme ici, le serveur sera-t-il surchargé dans cinq minutes ? ». Si la réponse est oui, il saute ce serveur et trouve un meilleur endroit.
3. La Décision Sensible au Stockage : C'est la recette secrète. Le système ne regarde pas seulement le CPU ; il vérifie également l'état de santé du stockage Ceph (les démons « OSD » ou démons de stockage). Si un serveur possède un disque de stockage très sollicité, le système sait qu'il doit envoyer les programmes de données lourdes ailleurs, même si le CPU semble libre.
4. L'Ajustement Dynamique : Si un programme a soudainement besoin de plus de puissance que prévu, le système peut ajuster automatiquement ses limites sans planter ni redémarrer, maintenant ainsi un flux fluide.

L'Expérience : Un Test dans Trois Villes

Pour voir si cela fonctionnait, les chercheurs ont construit une véritable petite ville utilisant trois ordinateurs physiques (nœuds). Chaque nœud possédait un processeur puissant, 32 Go de RAM et deux SSD NVMe ultra-rapides (disques durs super rapides). Ils ont rempli cette ville avec différents types de trafic :

• Camions lourds en CPU : Des programmes qui se contentent de calculer des chiffres (comme stress-ng).
• Camions lourds en Stockage : Des programmes qui lisent et écrivent de vastes quantités de données (comme fio).
• Trafic mixte : Des bases de données et des applications web qui font un peu de tout (comme YCSB).

Ils ont fait fonctionner deux scénarios côte à côte pendant 30 minutes.

• Scénario A (L'ancienne méthode) : Kubernetes standard sans prédiction.
• Scénario B (La nouvelle méthode) : Leur modèle prédictif et adaptatif.

Les Résultats : Des Rues Plus Fluides, Des Livraisons Plus Rapides

Les résultats sont une victoire claire pour le nouveau modèle, et les chiffres racontent une histoire frappante d'amélioration.

1. Équilibrage de la charge :
Avec l'ancienne méthode, le trafic était extrêmement inégal. Un serveur criait sous la pression, tournant à 95,64 % de sa capacité, tandis qu'un autre travaillait à peine à 39,73 %. L'« déséquilibre » (la différence entre le serveur le plus chargé et le plus calme) était un chaos de 53,29 %.
Avec le nouveau modèle, le trafic s'est lissé parfaitement. Le serveur le plus chargé est descendu à 67,41 %, et le plus calme s'est réveillé à 56,33 %. Le déséquilibre a chuté à seulement 10,98 %. Cela représente une réduction de 79,4 % du chaos. Le nouveau système a maintenu tous les serveurs dans une bande serrée et satisfaisante d'utilisation de 54 % à 68 %, ce qui signifie que personne n'est surchargé et que personne ne s'ennuie.

2. Accélération du stockage :
Parce que le nouveau système savait où le stockage était occupé, il a évité d'engorger les routes. Le temps moyen pour appliquer les changements de stockage (latence) est passé de 1,11 ms à 1,00 ms. Bien que cela semble être une différence infime, dans le monde de la donnée, cela signifie que le système est plus cohérent et plus fiable. Le « pire cas » de délai (le 95e percentile) s'est également amélioré, passant de 1,15 ms à 1,00 ms, montant que le système gérait bien mieux le trafic intense.

3. Aucun coût supplémentaire :
Les chercheurs ont pris soin de noter qu'ils n'avaient pas eu besoin de reconstruire toute la ville ou d'utiliser des cerveaux d'IA coûteux et complexes. Ils ont utilisé des outils standards (Kubernetes et les API Prometheus) et une méthode de prédiction simple. Ils ont prouvé qu'il n'est pas nécessaire d'avoir un algorithme super complexe pour obtenir de grands résultats ; il suffit de relier les points entre le calcul et le stockage.

La Conclusion : L'Intégration plutôt que la Complexité

La partie la plus excitante de cet article n'est pas seulement qu'il a fonctionné, mais pourquoi il a fonctionné. Les chercheurs soutiennent que le problème n'était pas que l'ancien contrôleur de trafic était trop stupide, mais qu'il regardait le problème sous une seule dimension. Il voyait le CPU mais ignorait le stockage.

En ajoutant simplement une couche de « prévoyance » et de « conscience du stockage » au système existant, ils ont obtenu des gains massifs. Ils ont montré que l'intégration architecturale (faire en sorte que le calcul et le stockage se parlent) est plus puissante que de simplement rendre les algorithmes plus compliqués. Même un outil de prédiction simple et léger, lorsqu'il est combiné à un placement intelligent, peut corriger les plus gros goulots d'étranglement dans un système hyperconvergé.

En fin de compte, cet article suggère que l'avenir d'une informatique efficace ne réside pas nécessairement dans la construction de cerveaux plus grands et plus intelligents, mais dans la manière de s'assurer que les différentes parties du système se tiennent par la main et regardent vers l'avant ensemble. Le contrôleur de trafic n'a pas besoin d'être un génie ; il a juste besoin de savoir ce qui arrive au tournant.