Proxmox on Mook’s Lab Chronicles

J’ai enfin activé Hyperscan sur mes deux OPNsense

Mon, 24 Aug 2026 15:20:00 +0200

Tout est parti d’un article publié sur le blog de Suricata : Faster Suricata startups with Hyperscan caching.

Le sujet était le cache MPM (Multi-Pattern Matching) introduit avec Suricata 8. Au lieu de recompiler toutes les bases de motifs Hyperscan à chaque démarrage ou rechargement des règles, Suricata peut les conserver sur disque et les réutiliser. L’article annonçait un temps de démarrage réduit jusqu’à 50 %.

En le lisant, je me suis surtout posé une question beaucoup plus basique : est-ce qu’Hyperscan tournait réellement sur mes firewalls ?

La réponse était non.

Suricata fonctionnait déjà sur mes deux OPNsense, les événements remontaient bien dans VictoriaLogs et mon cluster HA faisait son travail. Mais le moteur de recherche de motifs capable de profiter des instructions vectorielles du processeur n’était pas actif.

Le verrou ne se trouvait pas vraiment dans Suricata. Mes deux VM utilisaient encore le modèle de CPU générique kvm64, pratique pour la compatibilité, mais trop conservateur pour exposer les instructions que je voulais utiliser. Avant de jouer avec le cache, il fallait donc commencer par activer le moteur lui-même.

Donner le bon CPU virtuel à Suricata

J’ai passé fw-core-p1 et fw-core-p2 en x86-64-v3. FreeBSD voyait alors correctement AVX2, AES et FMA, et je pouvais enfin demander explicitement Hyperscan à Suricata :

1
2
3


cpu {
 type = "x86-64-v3"
}

1

opnsense_ids_mpm_algo: "hs"

Le hs sélectionne Hyperscan comme moteur MPM. C’est la partie de Suricata qui cherche plusieurs motifs à la fois dans le trafic et écarte rapidement les signatures qui ne peuvent pas correspondre. La documentation OPNsense le présente d’ailleurs comme le meilleur choix sur les plateformes compatibles.

Le changement posait tout de même une question importante : mes hôtes Proxmox mélangent des processeurs Intel et AMD. J’ai donc fait migrer une VM de test d’Intel vers AMD, puis de nouveau vers Intel, avant de considérer x86-64-v3 comme un socle suffisamment portable chez moi.

Je n’ai pas touché aux règles de placement HA. Les deux firewalls restent volontairement séparés sur deux hôtes différents.

Le test qui comptait vraiment

Voir mpm-algo = hs sur les deux nœuds était une bonne nouvelle, mais cela ne disait encore rien sur le comportement du cluster pendant une vraie bascule.

J’ai donc laissé p2 reprendre les neuf VIP CARP. Pendant qu’il était MASTER avec Hyperscan actif, la sortie Internet continuait de fonctionner. Je n’ai observé aucune perte de paquets pendant le failover, avec une latence maximale de 13 ms.

Après le test, la situation normale était revenue : p1 MASTER, p2 BACKUP et neuf VIP au bon endroit. Le moteur de détection avait changé sans perturber le cluster.

Seize heures plus tard

Le premier contrôle montrait déjà Suricata autour de 356 à 359 Mio de mémoire, contre environ 548 Mio auparavant. J’ai laissé tourner avant de regarder de nouveau les compteurs.

Mesure	Après environ 16 heures
CPU Suricata	0 à 0,1 % sur les deux nœuds
Mémoire sur P1	233 Mio, soit −57,5 % par rapport au repère de 548 Mio
Mémoire sur P2	356 Mio, stable depuis le premier contrôle
Capture sur P1	51 044 239 paquets, 4 669 drops, soit 0,0091 %
Capture sur P2	1 078 301 paquets, aucun drop
Événements TLS	22 056 événements centralisés dans VictoriaLogs

Les 4 669 drops de capture observés sur p1 n’avaient pas augmenté depuis plus de deux heures lors du dernier relevé. Aucun drop Suricata n’apparaissait dans les échantillons contrôlés et la qualité de capture restait supérieure à 99,99 %.

Surtout, l’enrichissement n’avait pas disparu au passage : 926 SNI, 370 empreintes JA4, 55 empreintes de certificats et 23 émetteurs distincts remontaient toujours dans VictoriaLogs.

Ce n’est pas un benchmark. p1 et p2 n’ont ni le même rôle ni le même volume de trafic, et je ne vais pas attribuer toute la baisse à une seule option. La tendance observée reste néanmoins assez nette : CPU négligeable, mémoire en baisse et aucune dégradation visible de la détection ou du failover.

La configuration est maintenant décrite dans Terraform et Ansible. Le plan Terraform ne montrait aucun drift, le second passage Ansible terminait avec changed=0, et les sept tests du rôle passaient avec le syntax-check et ansible-lint.

Assez ironiquement, un article consacré au cache m’aura d’abord fait découvrir que je n’utilisais même pas le moteur. Le cache pourra venir ensuite. Pour l’instant, Hyperscan tourne enfin sur mes deux firewalls — et c’était déjà le vrai chantier.

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.

J’ai doublé mon firewall pour pouvoir en éteindre un

Tue, 31 Mar 2026 00:00:00 +0000

Mon premier OPNsense fonctionnait très bien. C’était justement le problème.

Tout le cœur du réseau reposait sur fw-core-p1 : le LAN, huit VLANs, l’accès Internet et les routes entre mes différentes zones. Tant que la VM tournait, je n’avais aucune raison d’y penser. Dès qu’une mise à jour demandait un redémarrage, la question revenait : qu’est-ce qui reste accessible si ce firewall s’arrête ?

Pas grand-chose.

Je ne cherchais pas à transformer mon homelab en infrastructure bancaire. Je voulais simplement pouvoir maintenir un firewall sans couper volontairement tout ce qui passait derrière lui. C’est comme ça que fw-core-p2 est arrivé.

Une seconde VM ne fait pas encore un cluster

Le plus facile aurait été de cloner fw-core-p1, de démarrer la copie et d’appeler ça de la haute disponibilité. Deux firewalls mal coordonnés savent surtout produire deux fois plus de problèmes.

J’ai donc commencé par leur donner la même forme. Les deux VM vivent sur deux nœuds Proxmox différents et possèdent exactement le même ordre d’interfaces : le WAN, le LAN, les huit VLANs du homelab, puis une dernière interface réservée à la synchronisation.

1
2
3
4
5
6


pve-forum pve-fuji
fw-core-p1 fw-core-p2
 MASTER ─── VLAN 999 SYNC ─── BACKUP
 │ pfsync │
 │ XML-RPC │
 └────── 9 VIP CARP partagées ──┘

Cette symétrie n’est pas seulement jolie dans Terraform. pfsync associe les états aux interfaces : si leur ordre ou leur nom diffère entre les deux machines, la réplication ne raconte plus la même histoire des deux côtés.

CARP, pfsync et XML-RPC ne font pas le même travail

J’avais tendance à ranger tout cela dans la boîte « HA ». En pratique, trois mécanismes distincts coopèrent.

CARP (Common Address Redundancy Protocol) détermine quel firewall porte les adresses IP virtuelles. Les machines du réseau utilisent ces VIP comme passerelles et n’ont pas besoin de savoir si p1 ou p2 répond derrière.

pfsync réplique la table d’états. Quand p2 reprend le trafic, il connaît déjà les connexions suivies par p1 au lieu de repartir avec une feuille blanche.

XML-RPC synchronise la configuration depuis le primaire : règles, alias, NAT et objets partagés. Le second nœud reste ainsi un vrai pair, pas une vieille copie que j’espère encore correcte six mois plus tard.

La documentation HA d’OPNsense recommande justement une interface dédiée à pfsync. J’ai appliqué ce principe avec le VLAN 999, utilisé également pour la synchronisation de configuration.

Dans Terraform, ce choix tient dans quelques lignes :

1
2
3
4
5
6


# vtnet10 -> SYNC (pfsync + xmlrpc HA)
network_device {
 bridge = var.fw_core_lan_bridge
 vlan_id = var.fw_core_sync_vlan
 model = "virtio"
}

Ce petit vtnet10 est pourtant l’une des pièces les plus importantes du montage. Le trafic utilisateur et les échanges qui permettent au cluster de rester cohérent ne se disputent pas la même interface logique.

Le moment où neuf VIP ont changé de côté

Une interface verte dans OPNsense ne prouve pas grand-chose. Le cluster est devenu réel le jour où j’ai placé fw-core-p1 en maintenance et regardé fw-core-p2 reprendre les neuf VIP.

1
2
3


fw-core-p1 : BACKUP
fw-core-p2 : MASTER
VIP CARP : 9/9 sur p2

Le DNS continuait de répondre et mes routes applicatives restaient accessibles. En quittant le mode maintenance, p1 a repris son rôle par préemption et p2 est retourné attendre en secours.

C’est un test très simple, mais il change complètement la confiance que j’accorde au montage. Avant lui, j’avais deux VM configurées pour faire du CARP. Après lui, j’avais un cluster que je pouvais réellement utiliser pendant une intervention.

La haute disponibilité synchronise aussi les erreurs

Le piège le plus intéressant est arrivé plus tard. Une VIP utilisait un pair CARP unicast propre à p1. XML-RPC a parfaitement synchronisé cette valeur vers p2, qui s’est alors mis à envoyer ses annonces… à sa propre adresse.

La synchronisation n’était pas cassée. Elle exécutait fidèlement une configuration qui n’aurait pas dû être identique sur les deux nœuds.

J’ai raconté cette petite surprise dans ma révision du cluster OPNsense. Elle m’a rappelé qu’un cluster ne rend pas une configuration correcte par magie. Il propage aussi très efficacement les mauvaises idées.

Le retour au multicast CARP a supprimé cette exception locale et rendu les deux configurations réellement partageables. Depuis, mon test ne consiste plus seulement à vérifier que les deux firewalls affichent du vert : je provoque la bascule et je contrôle ce qui continue à fonctionner.

Ce que ce second firewall a réellement changé

Je n’ai pas supprimé tous les points de panne. Les deux VM dépendent toujours du réseau physique, des bridges Proxmox et de ce qui se trouve en amont. La haute disponibilité du firewall ne rend pas magiquement le reste du homelab redondant.

Elle a en revanche retiré un blocage très concret : je peux éteindre un OPNsense sans considérer la coupure comme une étape normale de la maintenance.

Le bénéfice n’est pas spectaculaire quand tout va bien. fw-core-p2 passe l’essentiel de son temps en BACKUP, ce qui est exactement ce que je lui demande. Sa valeur apparaît quand je mets à jour p1, quand je redémarre une VM ou quand je veux vérifier une modification sans jouer toute la connectivité du homelab sur un seul clic.

Au fond, j’ai doublé mon firewall pour pouvoir enfin en éteindre un sereinement. C’était tout le projet.