Ceph on Mook’s Lab Chronicles

J’allais ajouter un nœud Ceph. Mes backups partaient en même temps

Fri, 14 Aug 2026 12:40:31 +0200

Toutes les deux heures, mon cluster Ceph avait un petit passage à vide. Les VM devenaient moins réactives, les latences grimpaient et BlueStore finissait parfois par signaler des opérations lentes.

Ma première question a été assez classique : est-ce que le scheduler mClock était mal adapté à mon petit cluster ? Un retour à WPQ pouvait-il arranger les choses ? Et si le problème venait simplement du fait que trois nœuds et trois OSD ne suffisaient plus, fallait-il ajouter un quatrième PVE ?

Cette dernière option ne m’enchantait pas. Un nœud supplémentaire aurait apporté de la capacité et réparti la charge, mais aussi un nouveau coût pour corriger un problème que je ne comprenais pas encore.

J’ai donc commencé par regarder ce qui se passait réellement au moment des ralentissements. Le coupable n’était pas caché dans un obscur réglage Ceph : mes trois sauvegardes Proxmox Backup Server partaient exactement en même temps.

Avec trois OSD, le plus lent donne le tempo

Mon cluster repose sur trois nœuds Proxmox et un OSD NVMe par nœud :

Nœud	OSD	SSD
`pve-forum`	`osd.0`	WD Black SN770 2 To
`pve-dell`	`osd.1`	Crucial P310 2 To
`pve-fuji`	`osd.2`	Crucial P3 Plus 2 To

Le pool des VM utilise une réplication par trois. Chaque écriture doit donc être confirmée par les trois OSD. Ce choix me donne la tolérance aux pannes que je veux, mais il transforme naturellement le disque le plus lent en limite commune.

Le cluster n’était pourtant ni plein ni déséquilibré. Au moment du diagnostic, il était occupé à environ 33 %, ses 129 groupes de placement étaient active+clean et aucun recovery n’avait eu lieu durant les trente jours observés. Le réseau Ceph en 2,5 Gb/s ne montrait pas non plus d’erreurs ni de pertes.

En revanche, les latences maximales des OSD racontaient une tout autre histoire :

OSD	Latence commit maximale sur 30 jours
`osd.0`	3,2 s
`osd.1`	567 ms
`osd.2`	9,5 s

Le Crucial P3 Plus de pve-fuji était le plus préoccupant sur la durée, tandis que l’alerte active pouvait très bien pointer ponctuellement vers le WD de pve-forum. Ce n’était pas un OSD isolé qui souffrait en permanence : les trois SSD grand public encaissaient mal certaines rafales de petites écritures synchrones.

WPQ était une piste séduisante, mais pas la bonne

Le cluster utilisait déjà mClock avec son profil balanced. J’ai envisagé de repasser à la Weighted Priority Queue (WPQ), l’ancien scheduler, parce que le changement est souvent cité lorsque l’on cherche à réduire des latences Ceph.

Le souci, c’est que mon cluster n’était pas en train de faire du recovery ou du backfill. Les profils mClock savent répartir les ressources entre les opérations clientes, la récupération et les travaux de fond. Ici, les écritures des VM et celles provoquées par leurs sauvegardes appartenaient toutes à la même famille : des opérations clientes.

Passer à high_client_ops n’aurait donc pas appris à Ceph à préférer une VM interactive à sa propre sauvegarde. Revenir à WPQ aurait surtout changé la façon d’ordonner une saturation que je continuais à provoquer moi-même.

La documentation mClock de Ceph recommande d’ailleurs de rester prudent avec les réglages de bas niveau. Avant d’ajuster le scheduler, il fallait d’abord vérifier ce que je lui demandais d’absorber.

Le graphique qui revenait toutes les deux heures

Mon job PBS global était configuré toutes les deux heures, sans limite de bande passante. À chaque déclenchement, les sauvegardes des VM hébergées sur les trois nœuds partaient en parallèle : lecture des disques Ceph, création des snapshots et envoi vers PBS.

La corrélation avec les lenteurs était difficile à ignorer. Sur les 48 heures examinées :

les 563 événements aio_submit retries étaient tous apparus dans les trente minutes suivant le départ d’un backup ;
800 des 1 138 avertissements BlueStore étaient concentrés dans cette même fenêtre ;
les files NVMe avaient atteint une profondeur de 47 sur pve-forum et de 20 sur pve-fuji pendant un incident.

Ceph ne manquait pas de capacité. Il recevait simplement, à intervalles réguliers, trois grosses tapes sur l’épaule au même moment 😂.

Un quatrième PVE aurait probablement réduit la charge moyenne de chaque OSD. Il aurait aussi augmenté la capacité brute et les performances agrégées. Mais il n’aurait pas rendu raisonnables trois sauvegardes illimitées lancées ensemble. J’aurais payé du matériel pour mieux encaisser une mauvaise planification.

Quarante minutes entre chaque sauvegarde

J’ai remplacé le job global par trois jobs liés chacun à un nœud. Ils restent exécutés toutes les deux heures, mais avec quarante minutes d’écart :

Nœud	Horaire
`pve-forum`	heures paires à `:00`
`pve-dell`	heures paires à `:40`
`pve-fuji`	heures impaires à `:20`

Dans la syntaxe du planificateur Proxmox, cela donne :

1
2
3


pve-forum */2:00
pve-dell */2:40
pve-fuji 1/2:20

J’ai ajouté la même limite à chaque job :

1

bwlimit: 102400

La valeur est exprimée en Kio/s, soit 100 Mio/s. Le but n’était pas de rendre les sauvegardes artificiellement lentes, mais de leur laisser assez de débit sans leur permettre de prendre tout ce que les OSD pouvaient fournir pendant une pointe.

Je n’ai modifié ni la destination PBS, ni le mode snapshot, ni les exclusions existantes. Ce petit périmètre était important : une seule hypothèse changeait à la fois, donc le résultat restait lisible.

Le PoC a calmé la pointe, pas effacé le problème

Après avoir vérifié qu’aucun backup n’était encore actif, j’ai lancé manuellement le nouveau job de pve-dell. La sauvegarde complète s’est terminée en 43 secondes, avec des transferts ramenés autour de 80 à 104 Mio/s.

Sur ce passage, les logs ont compté cinq retries AIO, contre 22 pendant la fenêtre globale précédente. La latence commit Ceph a culminé à 47 ms, puis les 129 groupes de placement sont restés active+clean.

Cette comparaison reste indicative. Le PoC était fortement dédupliqué et un seul passage ne remplace pas plusieurs jours de métriques. Il a toutefois validé deux points utiles : le plafond était réellement appliqué et l’étalement réduisait déjà la violence de la pointe.

Le cluster n’est pas devenu parfait pour autant. Ceph continue ponctuellement de remonter un HEALTH_WARN pour des opérations BlueStore lentes. Les trois OSD sont toujours des SSD grand public sans protection contre les coupures de courant, et le P3 Plus en QLC reste le maillon qui m’inspire le moins confiance sous charge soutenue. La documentation matérielle de Ceph rappelle justement que les SSD clients peuvent voir leurs performances s’effondrer une fois leur cache épuisé, là où les modèles entreprise apportent notamment la protection contre les pertes d’alimentation.

Au moment où j’écris ces lignes, je prévois donc encore de remplacer progressivement les deux SSD les plus irréguliers, en commençant par celui de pve-fuji. Mais ce sera une amélioration matérielle posée sur une charge déjà mieux organisée, pas un achat destiné à masquer le symptôme.

Ce que j’en retiens

Je suis parti d’une question sur WPQ et de l’idée, un peu coûteuse, d’ajouter un quatrième nœud. La première amélioration utile a finalement tenu dans trois horaires et une limite de débit.

Le plus intéressant n’est pas que 100 Mio/s soit une valeur magique — elle ne l’est pas. C’est d’avoir trouvé le rythme réel du problème avant de toucher au scheduler ou au matériel. Les ralentissements revenaient toutes les deux heures parce que mes backups revenaient toutes les deux heures. Une fois la corrélation posée noir sur blanc, la solution est devenue beaucoup moins mystérieuse.

Pour ceux qui se demandent déjà vers quoi je compte me tourner, je remplacerais progressivement les SSD concernés par des Samsung 990 PRO 2 To, référence MZ-V9P2T0BW. Cela reste du matériel grand public, pas l’équivalent d’un NVMe datacenter avec protection contre les coupures, mais c’est le compromis que je retiendrais aujourd’hui pour mon homelab.

Je vais maintenant laisser tourner cette configuration, comparer plusieurs fenêtres de sauvegarde et observer si les futurs SSD changent encore le profil des latences. Le quatrième PVE, lui, peut rester pour l’instant dans la boutique.

12 Mo de SQLite, 28 Go d’écritures par jour : le piège des Query Logs de Technitium

Thu, 30 Jul 2026 11:00:00 +0200

Ma VM DNS écrivait près de 28 Go par jour sur Ceph. Avec un tel chiffre, je m’attendais à trouver un volume anormal de requêtes, un service bavard ou un buffer Vector qui débordait.

La réalité tenait dans une base SQLite de 12 Mo.

trust-dns-01 résout environ deux à trois requêtes par seconde. Ce n’est ni une attaque ni une charge impressionnante. Pourtant, le stockage travaillait suffisamment pour que la VM passe bien plus de temps à attendre ses entrées-sorties qu’à calculer.

Le DNS n’était pas débordé

Le 30 juillet 2026, j’ai repris les métriques sur les dernières 24 heures et l’état réel de la machine :

Mesure	Valeur observée
trafic DNS	environ 2,5 requêtes/s
CPU actif, hors attente I/O	6,3 % en moyenne
attente I/O (iowait)	29,1 % en moyenne
données écrites sur le disque	27,89 Go en 24 h
occupation du disque	8,8 Go sur 20 Go

La nuance entre CPU actif et iowait est importante. Un graphique calculé simplement comme 100 - idle donne l’impression que le processeur est occupé à 35 %. En réalité, sur cette VM limitée à un vCPU, près de 29 points correspondent au temps passé à attendre le stockage.

Le serveur DNS lui-même ne manque donc pas de puissance. Il attend surtout Ceph.

Une petite base qui réécrit sans arrêt

Technitium possède une application nommée Query Logs (Sqlite). Elle permet de retrouver précisément quel client a demandé quel domaine, à quelle heure et avec quelle réponse.

Sur mon instance, sa configuration contient notamment :

1
2
3
4
5
6
7
8


{
 "enableLogging": true,
 "maxLogDays": 7,
 "maxLogRecords": 10000,
 "enableVacuum": false,
 "useInMemoryDb": false,
 "sqliteDbPath": "querylogs.db"
}

La base fait environ 12 Mo et conserve autour de 10 000 entrées. Pendant une vérification, elle contenait 12 102 lignes couvrant un peu plus de 80 minutes, soit environ 2,5 requêtes par seconde.

Ce léger dépassement est normal : le plafond n’est pas appliqué à chaque insertion. Le nettoyage se déclenche toutes les quinze minutes. Entre deux passages, la table continue de grossir.

Dit comme cela, rien d’inquiétant. Le détail qui change tout se trouve dans les réglages effectifs de SQLite :

1
2


journal_mode = delete
synchronous = 2

La valeur 2 correspond au mode FULL. Avec le journal DELETE, SQLite crée un journal de rollback pour la transaction, synchronise les données, puis supprime le journal une fois le commit terminé. Ces choix privilégient la durabilité, comme l’explique la documentation officielle de SQLite sur les modes de journalisation et la synchronisation.

Ici, chaque nouvelle requête ajoute une ligne et met à jour treize index en plus de la clé primaire. L’application consomme les requêtes disponibles sans attendre de remplir un gros lot ; à faible trafic, elle peut donc committer très peu de lignes à la fois. Lorsque la limite est dépassée, les anciennes lignes sont aussi supprimées. La base reste petite, mais elle tourne en permanence : insertions, index, suppressions, journal, synchronisations.

Sur un disque local, cette activité passerait probablement inaperçue. Sur un stockage distribué comme Ceph, une succession de petites écritures synchrones coûte beaucoup plus cher que sa taille apparente. Le fichier querylogs.db-journal, présent et ouvert pendant le diagnostic, était le petit témoin de cette mécanique.

Deux mesures supplémentaires renforcent le diagnostic : le compteur du processus Technitium indiquait environ 15,5 Go écrits en 23 heures et, sur un échantillon de quinze secondes, 32 nouvelles requêtes ont accompagné 2,97 Mo d’écritures processus.

Je garde tout de même une réserve : Technitium écrit aussi ses statistiques et ses journaux, tandis que la métrique des 27,89 Go couvre toute la VM. Query Logs est la cause principale la mieux étayée, mais la preuve définitive viendra de la comparaison sur 24 heures après sa désactivation. Sans cet avant/après, lui attribuer chaque octet serait aller un peu vite.

L’espace disque racontait une autre histoire

L’amplification d’écriture n’explique pas à elle seule les 8,8 Go déjà occupés. Les plus gros consommateurs évitables étaient ailleurs :

Données	Taille observée
sauvegardes Technitium	3,7 Gio
statistiques DNS	568 Mio
journaux systemd	623 Mio

Le script de sauvegarde actuel supprime les archives âgées de plus de 30 jours. Cela laisse tout de même 36 fichiers, car une sauvegarde quotidienne pèse désormais entre 100 et 123 Mo et quelques sauvegardes manuelles s’ajoutent au lot.

Ce sont donc deux problèmes distincts :

Query Logs use le stockage avec beaucoup de petites écritures ;
les sauvegardes, statistiques et journaux consomment réellement l’espace disponible.

Supprimer la base SQLite ne libérerait qu’une douzaine de mégaoctets. Pour faire maigrir la VM, il faut aussi agir sur les rétentions.

Garder les requêtes, sans garder SQLite

Ma première idée était de désactiver complètement les journaux détaillés et de conserver seulement les statistiques agrégées dans Grafana. C’était efficace, mais je perdais une fonction à laquelle je tiens : pouvoir rechercher les requêtes DNS dans VictoriaLogs.

Le compromis que je prépare est donc le suivant :

1
2
3
4
5


Technitium Log Exporter
 ↓ HTTP local
 Vector
 ↓ NDJSON compressé
 VictoriaLogs

L’application officielle Log Exporter de Technitium peut expédier les requêtes par HTTP ou Syslog sans les écrire dans un fichier local. Vector recevra les lots en mémoire, extraira les champs utiles — client, nom demandé, type, code de réponse et temps de traitement — puis les enverra vers VictoriaLogs.

Vector n’est pas seulement là pour faire joli au milieu du schéma. Le sink HTTP utilisé par Technitium produit des lots JSON enveloppés par Serilog, alors que l’endpoint /insert/jsonline de VictoriaLogs attend un objet JSON par ligne. Il faut donc convertir et normaliser les événements.

Je préfère un buffer mémoire borné pour ce flux. Cela évite de recréer une nouvelle source d’écritures locales, au prix d’un compromis assumé : une panne ou un redémarrage peut faire perdre quelques requêtes. Pour mon homelab, la visibilité opérationnelle compte davantage qu’une conservation forensique parfaitement exhaustive.

Ces données restent sensibles. Une suite de requêtes DNS raconte rapidement les habitudes d’un réseau. Les noms demandés et les adresses clientes resteront des champs recherchables, mais pas des champs de stream à forte cardinalité, et leur accès devra être plus restreint que celui des journaux système ordinaires.

La suite, avec un vrai avant/après

Au moment où j’écris ces lignes, aucune modification de production n’a encore été appliquée. Le déploiement suivra volontairement plusieurs étapes :

activer Log Exporter et le flux Vector tout en gardant temporairement SQLite ;
comparer les événements pendant 30 à 60 minutes ;
mesurer pendant 24 à 72 heures le volume ingéré, la RAM et les écritures Ceph ;
désactiver Query Logs SQLite seulement après cette validation.

Je conserverai ensuite la base quelques jours comme possibilité de retour arrière. Si les écritures chutent comme prévu, j’aurai enfin le chiffre qui manque à ce diagnostic : le gain réel, pas seulement le coupable le plus crédible.

Je pensais devoir redimensionner un serveur DNS. En réalité, il fallait surtout l’empêcher de tenir son journal intime sur Ceph.