Proxmox Corosync “link down” : pourquoi le cluster bascule et comment le stabiliser

octobre 6, 2025 • février 3, 2026 • Lecture : 29 min • Views: 5

Cet article vous a aidé ?

L’interface Proxmox est verte. Puis elle devient rouge. Puis vos nœuds décident qu’ils sont seuls à nouveau, comme un système distribué en pleine rupture.
Les logs Corosync indiquent link down, le quorum disparaît, le HA s’inquiète, et soudain votre fenêtre de maintenance simple a un public en direct.

« Link down » n’est pas une humeur mystique de Corosync. C’est un symptôme : perte de paquets, jitter, désaccord MTU, comportements étranges des offloads NIC, mauvais design d’anneaux,
dérive d’horloge, hôtes surchargés, ou un cluster à deux nœuds faisant comme si les règles de quorum ne s’appliquaient pas. Rendreons cela ennuyeux à nouveau.

Ce que « link down » signifie réellement dans Corosync

Dans Proxmox VE, Corosync est la couche de communication du cluster. C’est la partie qui décide si les nœuds peuvent s’entendre de manière fiable et si
le cluster forme toujours un groupe cohérent unique. Lorsque Corosync signale link down, il ne parle pas forcément d’une perte physique du lien Ethernet
(même si cela peut en être la cause). Il parle de son propre chemin de transport — son anneau — devenu inutilisable parce que les messages n’arrivent pas dans la fenêtre temporelle attendue,
ou parce qu’il détecte une partition.

Corosync est conservateur. Il préfère déclarer un lien « down » plutôt qu’accepter silencieusement une communication peu fiable. C’est un bon réflexe : des
communications de cluster peu fiables causent le type de chaos « la moitié des nœuds pense X, l’autre moitié pense Y » qui transforme le stockage et le HA en machines à problème.

Traduction pratique : Corosync link down signifie que la plane de contrôle du cluster subit de la perte de paquets, un jitter excessif, du réordonnancement
ou de longs délais d’ordonnancement — et que cela dépasse la tolérance de Corosync définie par les timeouts de token et la logique de retransmission. Corrigez le réseau et
le comportement des hôtes ; n’augmentez pas simplement les timeouts jusqu’à ce qu’il arrête de se plaindre, sauf si vous avez mesuré les compromis.

Une vérité sèche : si votre anneau Corosync est instable, tout ce qui est au-dessus devient menteur. L’UI ment. Le HA ment. « Ça marchait hier » ment.

Faits & contexte : pourquoi Corosync se comporte ainsi

Corosync a évolué depuis le projet OpenAIS (milieu des années 2000) pour fournir un messaging de groupe fiable pour les clusters ; ce n’était pas au départ une fonctionnalité Proxmox.
Le protocole Totem (le noyau de messaging de Corosync) est conçu autour de la gestion des membres et du message ordonné ; il est conservateur vis-à-vis des partitions.
La gestion par jeton (token) est une approche classique : si vous ne pouvez pas passer le « token » dans le temps imparti, vous êtes hors-jeu. D’où l’importance des timeouts.
Le quorum à deux nœuds est historiquement délicat dans la plupart des piles de clustering ; des dispositifs de quorum externes existent parce que « 2 » est un nombre politique, pas tolérant aux pannes.
Le multicast était autrefois recommandé pour certaines piles de cluster, mais les datacenters modernes le désactivent ou le gèrent de façon incohérente, poussant vers l’unicast.
La redondance d’anneau n’est pas nouvelle : les clusters HA utilisent depuis longtemps deux réseaux (public + heartbeat) parce que « un seul switch » n’est pas une stratégie.
Les modes de bonding Linux ont une longue histoire de surprises sous perte de paquets ou routage asymétrique ; le trafic de cluster est l’endroit où « presque bien » devient « pas bien ».
Les bugs de mismatch MTU sont anciens et toujours vivaces : les jumbo frames qui tombent silencieusement ou fragmentent peuvent créer exactement la perte intermittente qui tue un anneau token.

Pourquoi le cluster bascule : les modes de défaillance qui comptent

1) Perte de paquets (les micro-burst comptent)

Corosync n’a pas besoin d’une « grosse » perte pour vous nuire. Quelques paquets perdus dans une fenêtre serrée peuvent déclencher des retransmissions et des délais de token, conduisant à une décision de link-down.
Les micro-bursts — pics courts de congestion — sont connus pour être invisibles aux surveillances simplistes. Un switch peut être « correct » en moyenne tout en perdant le paquet unique dont votre cluster avait besoin.

2) Jitter et latence d’ordonnancement (l’hôte fait aussi partie du réseau)

Même si le chemin réseau est parfait, un hôte occupé peut se comporter comme un réseau perdant si les threads Corosync ne peuvent pas s’exécuter. Surallocation CPU, tempêtes d’interruptions,
blocages de stockage et accrochages au niveau du noyau peuvent retarder le traitement. Corosync mesure le temps en temps réel ; votre ordonnanceur mesure le temps en « quand j’en aurai le temps ».

3) Mismatch MTU et étrangetés de fragmentation

Les clusters vivent souvent sur des réseaux « spéciaux » : VLANs, jumbo frames, bonds, bridges, offloads NIC, règles de firewall et parfois réseaux overlay.
Le mismatch MTU est classique : les pings fonctionnent (petits paquets), mais les paquets plus grands fragmentent ou sont perdus, et Corosync subit des timeouts intermittents.

4) Erreurs de design d’anneau : faux points uniques de défaillance déguisés en « redondance »

Si ring0 et ring1 partagent le même switch, la même NIC, la même esclave de bond, ou le même chemin amont, vous n’avez pas de redondance. Vous avez deux noms pour un seul problème.
Corosync fera volontiers basculer les deux anneaux si vos « deux anneaux » sont en réalité un seul domaine de défaillance.

5) Unicast/multicast mal configuré, ou le « coup de main » du firewall

Corosync a besoin d’une livraison cohérente. Un multicast à moitié configuré, un IGMP snooping capricieux, ou un firewall qui supprime les fragments UDP peuvent rendre la gestion des membres instable.
Corosync utilise UDP ; UDP plus « politique de firewall entreprise » est une relation qui nécessite conseil.

6) Dérive d’horloge et sauts temporels

Les timeouts de token supposent des horloges raisonnables. NTP/chrony qui recule dans le temps, ou des hôtes avec des sources temporelles très différentes, peuvent amplifier le jitter et déclencher de fausses suspicions.
Corosync n’est pas strictement dépendant d’horloges synchronisées comme certaines bases de données, mais un comportement temporel erratique complique le diagnostic et les timeouts.

7) Cas limites de quorum (surtout les clusters à deux nœuds)

Au moment où un nœud ne voit plus l’autre, il faut décider : qui est « le cluster » ? Dans un cluster à deux nœuds, il n’y a pas de majorité sans aide.
Proxmox fournit qdevice/qnetd pour éviter la danse classique du split-brain. Ignorer cela et les fluctuations de liens deviennent des événements « cluster down ».

Blague #1 : Un cluster à deux nœuds sans qdevice, c’est comme une conférence téléphonique à deux personnes — quand ça se tait, chacun suppose que l’autre a raccroché.

Feuille de diagnostic rapide (vérifier d’abord/puis/ensuite)

L’objectif est de trouver rapidement le goulot d’étranglement : est-ce le chemin réseau, l’ordonnancement hôte, ou la stratégie de quorum ? Ne commencez pas par éditer les timeouts.
Commencez par prouver où la perte ou le délai se produisent.

Premier : confirmez qu’il s’agit d’instabilité de membership Corosync, pas d’un « bug d’UI »

Vérifiez Corosync et l’état du cluster : changements de membership, état des anneaux, votes attendus.
Consultez les logs autour du basculement : quel nœud a déclaré link down en premier ?

Deuxième : validez le chemin de transport (perte, MTU, firewall, symétrie de routage)

Exécutez des tests ping ciblés avec DF et des payloads plus larges sur les interfaces Corosync.
Faites une capture tcpdump courte pendant une fenêtre de flap ; recherchez des gaps et des ICMP frag-needed.
Vérifiez les compteurs du switch (même si « l’équipe réseau dit que tout va bien »).

Troisième : vérifiez l’hôte pour des blocages (CPU, interruptions, softnet drops, pauses de stockage)

Cherchez des pics de ksoftirqd, des RX drops, des débordements de ring buffer.
Vérifiez si des scrubs ZFS, sauvegardes ou réplications saturent IO/CPU pendant les flaps.
Vérifiez que la synchronisation horaire est stable (pas de grands sauts, pas de « panique de slew NTP »).

Quatrième : vérifiez la stratégie de quorum

Deux nœuds ? Ajoutez un qdevice. Trois nœuds ? Assurez-vous que les votes attendus correspondent à la réalité.
Confirmez qu’il n’y a pas un « vote » tiers caché et mort dans la config.

Tâches pratiques : commandes, sorties attendues et décisions

Voici les vérifications que j’exécute réellement quand un cluster commence à basculer. Chaque élément inclut une décision : que faire ensuite selon ce que vous voyez.

Task 1: Confirm cluster membership and quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 25 10:12:03 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.3a
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Ce que cela signifie : Si Quorate: No ou si Total votes diminue soudainement, vous ne regardez pas un « petit problème de comms » — vous avez un événement de partition.

Décision : Si le quorum est perdu de façon intermittente, priorisez les vérifications de transport (Tâches 4–10) et le design du quorum (Tâche 12). Ne touchez pas au HA en premier.

Task 2: Check Corosync ring status and per-link state

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 192.168.50.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 192.168.51.11
        status  = ring 1 active with no faults

Ce que cela signifie : Si vous voyez faulty ou seulement un anneau actif, vous avez perdu la redondance ou le chemin est instable.

Décision : Si ring1 est faulty, vérifiez le câblage/VLAN/MTU sur ring1 spécifiquement. N’assumez pas que « ring0 est OK donc nous sommes en sécurité » — les basculements peuvent toujours déstabiliser le membership.

Task 3: Pull the relevant Corosync log slice around the flap

cr0x@server:~$ journalctl -u corosync --since "10 minutes ago" --no-pager
Dec 25 10:05:41 pve1 corosync[1642]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 10:05:41 pve1 corosync[1642]:   [TOTEM ] Token has not been received in 1000 ms
Dec 25 10:05:41 pve1 corosync[1642]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:05:42 pve1 corosync[1642]:   [QUORUM] Members[2]: 1 3
Dec 25 10:05:47 pve1 corosync[1642]:   [KNET  ] link: host: 2 link: 0 is up

Ce que cela signifie : Les lignes « token not received » et « forming new configuration » sont l’agitation de membership. La ligne KNET identifie quel pair/quel lien est tombé.

Décision : Identifiez quel nœud rapporte la chute en premier et quel pair est impliqué. Testez ensuite ce chemin réseau exact (Tâches 4–8).

Task 4: Verify Corosync is using the interfaces you think it is

cr0x@server:~$ grep -E "ring0_addr|ring1_addr|transport|link_mode" /etc/pve/corosync.conf
        transport: knet
        link_mode: passive
        ring0_addr: 192.168.50.11
        ring1_addr: 192.168.51.11

Ce que cela signifie : Ceci confirme l’adressage et le transport. Des sous-réseaux erronés ou des définitions d’anneau manquantes sont fréquents après des « changements rapides ».

Décision : Si les adresses ne correspondent pas au réseau dédié prévu, corrigez cela en premier. Corosync sur un LAN partagé et chargé est une invitation au jitter.

Task 5: Check MTU end-to-end with DF ping (small and large)

cr0x@server:~$ ping -c 3 -M do -s 8972 192.168.50.12
PING 192.168.50.12 (192.168.50.12) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 192.168.50.12 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2046ms

Ce que cela signifie : Votre chemin d’interface a une MTU de 1500 (ou quelque chose sur le chemin l’impose), donc les attentes de jumbo sont fausses.

Décision : Configurez soit les jumbos de façon cohérente sur NIC/switch/VLAN/bridge/bond, soit standardisez sur 1500 partout pour Corosync. Le MTU mixte alimente les flaps.

Task 6: Confirm MTU on the actual Linux interfaces used (bridge/bond included)

cr0x@server:~$ ip -d link show vmbr1
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768 vlan_filtering 1

Ce que cela signifie : Si vmbr1 est à 9000 mais que le bond ou la NIC esclave est à 1500, vous perdez quand même. La MTU doit correspondre sur toute la chaîne.

Décision : Vérifiez la MTU sur bondX et les NIC sous-jacentes. Corrigez les incohérences avant de toucher aux timers Corosync.

Task 7: Measure packet loss and latency with fping (corosync network)

cr0x@server:~$ fping -c 200 -p 20 192.168.50.12 192.168.50.13
192.168.50.12 : xmt/rcv/%loss = 200/199/0%, min/avg/max = 0.20/0.35/4.10
192.168.50.13 : xmt/rcv/%loss = 200/192/4%, min/avg/max = 0.21/0.60/18.70

Ce que cela signifie : 4% de perte avec des pics à 18 ms sur un réseau de cluster n’est pas « acceptable ». C’est un générateur de link-down.

Décision : Si vous voyez une quelconque perte, arrêtez et trouvez la cause physique/logique (drops sur switch, câble ou optique défectueux, mismatch duplex, uplink saturé).

Task 8: Check Linux network error counters and drops

cr0x@server:~$ ip -s link show dev eno2
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0   4821       0  112233
    TX:  bytes packets errors dropped carrier collsns
    876543210  1122334      0      0       0       0

Ce que cela signifie : Des dropped en réception indiquent que l’hôte jette des paquets (souvent buffer d’anneau, driver, ou pression CPU/interrupt).

Décision : Si les drops augmentent pendant les flaps, investiguez les interruptions/softnet (Tâche 9), les tailles de files NIC, et la charge hôte (Tâche 10).

Task 9: Check softnet backlog drops (kernel can’t keep up)

cr0x@server:~$ awk '{print NR-1, $1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16}' /proc/net/softnet_stat | head
0 00000000 00000000 00000018 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1 00000000 00000000 000001a2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Ce que cela signifie : La troisième colonne (en hex) correspond aux paquets perdus à cause du softnet backlog. Des valeurs non nulles qui augmentent sous charge sont un indice majeur.

Décision : Si ces compteurs augmentent pendant les flaps, réduisez la pression d’interruptions (affinité IRQ), ajustez les queues NIC, et cessez de saturer l’hôte avec du trafic bruyant sur la NIC Corosync.

Task 10: Correlate flaps with CPU pressure and IO stalls

cr0x@server:~$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 102400  12345 678901    0    0    20    40  900 1500 12  4 83  1  0
 8  2      0  51200  12000 650000    0    0  8000 12000 4000 9000 35 20 25 20  0
 7  3      0  49000  11800 640000    0    0  9000 14000 4200 9200 33 22 20 25  0

Ce que cela signifie : Un r élevé (run queue), un wa non négligeable (IO wait), et des switchs de contexte élevés peuvent coïncider avec des délais Corosync.

Décision : Si les flaps coïncident avec des sauvegardes, scrubs, ou réplications, planifiez ou bridez ces opérations, et isolez le trafic Corosync (NIC/VLAN dédié, QoS).

Task 11: Confirm time synchronization is stable (chrony example)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0A0A01 (ntp1)
Stratum         : 3
Ref time (UTC)  : Thu Dec 25 10:10:58 2025
System time     : 0.000231456 seconds slow of NTP time
Last offset     : -0.000102334 seconds
RMS offset      : 0.000356221 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.012 ppm
Skew            : 0.045 ppm
Root delay      : 0.001234 seconds
Root dispersion : 0.002345 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Ce que cela signifie : Santé : offsets minimes, stratum stable, pas de problème de leap. Si vous voyez de grands offsets ou des sauts fréquents, le temps est suspect.

Décision : Corrigez la stabilité NTP/chrony avant de tuner Corosync. Le chaos temporel rend le diagnostic impossible et les timeouts imprévisibles.

Task 12: Validate expected votes and (if needed) qdevice presence

cr0x@server:~$ pvecm qdevice status
QDevice information
-------------------
Status:           OK
QNetd host:       10.10.10.50
QDevice votes:    1
TLS:              enabled
Algorithm:        ffsplit

Ce que cela signifie : Dans les clusters à deux nœuds, qdevice fait la différence entre « un bref clignotement de lien » et « tout le monde panique ».

Décision : Si vous avez deux nœuds et pas de qdevice, planifiez l’ajout d’un. Si un qdevice existe mais que son statut n’est pas OK, réparez-le — ne comptez pas sur l’espoir.

Task 13: Check Corosync runtime stats (knet) for link errors

cr0x@server:~$ corosync-cmapctl | grep -E "knet.*(rx|tx|errors|retries|latency)" | head -n 12
runtime.totem.knet.pmtud_interval = 60
runtime.totem.knet.link.0.packets_rx = 2849921
runtime.totem.knet.link.0.packets_tx = 2790012
runtime.totem.knet.link.0.errors = 12
runtime.totem.knet.link.0.retries = 834
runtime.totem.knet.link.0.latency = 420

Ce que cela signifie : Des errors et retries en croissance s’alignent souvent avec une perte physique ou un problème MTU/PMTUD.

Décision : Si les retries montent pendant les flaps, traitez cela comme un défaut réseau jusqu’à preuve du contraire. « Mais vMotion marche » n’est pas disculpant.

Task 14: Capture Corosync traffic briefly to detect fragmentation/ICMP issues

cr0x@server:~$ tcpdump -i vmbr1 -nn -c 50 udp port 5405
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:12:11.120001 IP 192.168.50.11.5405 > 192.168.50.12.5405: UDP, length 1240
10:12:11.120220 IP 192.168.50.12.5405 > 192.168.50.11.5405: UDP, length 1240
10:12:11.121003 IP 192.168.50.11 > 192.168.50.12: ICMP 192.168.50.11 udp port 5405 unreachable, length 1276

Ce que cela signifie : ICMP unreachable est un signe évident : firewall, mauvaise adresse liée, ou nœud qui n’écoute pas réellement sur cette interface.

Décision : Si vous voyez unreachable/frag-needed, corrigez le routage/firewall/MTU. Si vous voyez du silence pendant les flaps, suspectez des drops plus en amont.

Task 15: Verify firewall state for the Corosync interfaces

cr0x@server:~$ pve-firewall status
Status: enabled/running

Ce que cela signifie : Un firewall activé est acceptable, mais cela implique de confirmer que les règles autorisent Corosync sur la bonne interface/VLAN.

Décision : Si les flaps sont apparus après des changements de firewall, auditez les règles datacenter et hôtes et confirmez que UDP 5405/5404 (selon la config) est autorisé entre les nœuds.

Trois mini-récits d’entreprise tirés de la vie réelle (anonymisés)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne est passée d’un « hôte unique puissant » à un cluster Proxmox à trois nœuds. Ils ont fait la chose sensée — dédier un VLAN à Corosync —
et la chose insensée — mettre ce VLAN sur les mêmes top-of-rack switches qu’un réseau de stockage chargé sans penser aux schémas de congestion.

L’hypothèse erronée était simple : « Le trafic de cluster est minime, il peut partager n’importe quoi. » La plupart du temps, c’était vrai. Les graphiques montraient un faible débit moyen.
Tout le monde a hoché la tête, et la demande de changement s’est refermée émotionnellement.

Puis sont arrivées les sauvegardes hebdomadaires et une exportation interne qui ont saturé le VLAN stockage. Les buffers du switch se sont remplis, des micro-bursts se sont formés, et le VLAN Corosync
a pris des dommages collatéraux. Les nœuds perdaient l’appartenance quelques secondes à la fois — juste assez pour déclencher la logique de fencing HA et perturber quelques VM.

La correction n’était pas un réglage timeout Corosync. Ils ont déplacé Corosync vers une paire de switches physiquement séparée et des NIC dédiées, et ont cessé de faire passer
le trafic de sauvegarde par les mêmes uplinks que la communication du cluster. La théorie « le trafic minime peut tout partager » est morte en silence, comme il se doit.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a décidé « d’optimiser la latence » en activant les jumbo frames partout. L’équipe réseau a fixé MTU 9000 sur les switches. L’équipe virtualisation a mis MTU 9000
sur les bridges Linux. Ils ont fêté trop tôt, ce qui est une façon fiable d’invoquer la réalité.

Le retour de bâton : un équipement intermédiaire — un vieux firewall faisant du routage VLAN pour un sous-réseau de management — imposait silencieusement MTU 1500. Le PMTUD était
incohérent à cause des règles de filtrage, donc les grands paquets étaient rejetés sans ICMP utile. Les pings fonctionnaient. SSH fonctionnait. Tout fonctionnait sauf la chose qui avait besoin
d’une livraison UDP cohérente sous charge : Corosync.

Le cluster a commencé à « basculer au hasard » quelques fois par jour. L’équipe a essayé d’augmenter les token timeouts. Les flaps sont devenus moins fréquents, mais la récupération était
plus lente, et les décisions de basculement sont devenues molles. Ils ont troqué la correction pour l’engourdissement.

La correction a été chirurgicale et ennuyeuse : imposer une MTU cohérente de bout en bout (ou standardiser sur 1500 pour Corosync), et cesser de bloquer les ICMP liés au PMTUD
sur les liens internes. Le cluster s’est calmé. L’« optimisation » avait été un générateur distribué de mismatch MTU.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers exécutait Proxmox avec Ceph et traitait la communication de cluster comme du trafic de contrôle production : NIC dédiées, switches dédiés,
et une checklist écrite pour tout changement réseau. Ils avaient aussi l’habitude d’une chose peu tendance : capturer un court tcpdump avant et après chaque changement touchant le réseau du cluster.

Un après-midi, des flaps ont commencé immédiatement après une mise à jour de firmware de switch de routine. L’équipe réseau assurait qu’aucune config n’avait changé. C’est généralement vrai —
jusqu’au moment où ce n’est plus le cas. L’équipe virtualisation a sorti leurs preuves pratiques : captures avant/après montrant des rafales périodiques de pertes UDP toutes les 30 secondes.

Ils ont corrélé ces rafales avec un changement de comportement d’IGMP snooping sur le switch (la mise à jour a modifié des valeurs par défaut). Corosync fonctionnait dans un mode qui dépendait
d’hypothèses sur le traitement du multicast. Avec les preuves en main, l’équipe réseau a ajusté les paramètres de snooping pour ce VLAN et a validé avec des compteurs.

Le cluster s’est stabilisé en quelques minutes. L’habitude du tcpdump ne les rendait pas cool en réunion, mais elle les rendait justes quand il le fallait.

Stabiliser par le design : réseau, anneaux, quorum et temps

Construisez un réseau de cluster comme si vous en aviez l’intention

Corosync est sensible à la latence, à la perte et au jitter. Traitez le réseau Corosync comme du trafic control-plane. Cela signifie généralement :
VLAN dédié au minimum, NICs physiques dédiées idéalement, et une paire de switches dédiée si vous pouvez vous le permettre.

Si vous devez partager, appliquez du QoS et évitez les voisins bruyants connus (sauvegardes, réplication, reconstruction de stockage). Ne basez pas votre membership de cluster
sur l’idée que votre top-of-rack va tout tamponner indéfiniment.

Utilisez deux anneaux, mais faites-en deux domaines de défaillance différents

Deux anneaux, c’est bien. Deux anneaux qui partagent un seul switch, ce n’est pas deux anneaux. Si ring0 et ring1 se terminent sur la même pile de switches, la même paire bondée,
ou le même routeur amont, vous avez construit du « théâtre de redondance ».

Idéal : ring0 sur une NIC et une paire de switches, ring1 sur une autre NIC et une autre paire de switches. Acceptable : ring1 partage la paire de switches mais utilise des NIC différentes et des chemins de câblage différents, si vous avez validé que la paire de switches elle-même est hautement disponible et non saturée.

Soyez conservateur concernant le MTU

Les jumbo frames ne sont pas maléfiques. Les jumbos mixtes le sont. Si vous ne pouvez pas prouver la cohérence MTU à travers NICs, bonds, bridges, ports de switch, trunks VLAN, et tout équipement L3 intermédiaire,
restez sur 1500 pour Corosync. Vous dormirez mieux.

Ne masquez pas les problèmes en ajustant les timeouts de token

Corosync a des réglages : token timeouts, retransmits, et comportements de consensus. Ils existent parce que différents environnements existent. Mais le tuning n’est pas un substitut à la réparation de la perte.
Des timeouts plus longs peuvent réduire la sensibilité au jitter transitoire, mais augmentent aussi le temps de détection de panne. Cela signifie fencing plus lent, basculement plus lent, et périodes plus longues
où le cluster n’est pas d’accord.

Voici le compromis : des timeouts courts signifient détection rapide des pannes mais plus de sensibilité ; des timeouts longs signifient moins de faux positifs mais réaction plus lente.
Ajustez seulement après avoir mesuré la latence et la perte de base et après avoir corrigé les défauts de transport évidents.

Quorum : arrêtez de prétendre que deux nœuds font trois

Si vous exécutez deux nœuds, ajoutez un qdevice (qnetd) sur un troisième hôte indépendant. Il peut être petit. Il peut être une VM dans un autre domaine de défaillance. Il ne doit pas se trouver sur le même
hôte physique que celui que vous tentez d’arbitrer. Oui, des gens font ça. Non, ça ne compte pas.

Si vous exécutez trois nœuds ou plus, vérifiez que les votes attendus correspondent à la réalité et supprimez les nœuds obsolètes de la config. Les votes zombies sont la manière dont vous devenez non-quorate alors que tout semble opérationnel.

Synchronisation temporelle : ennuyeuse, fondamentale et non négociable

Chrony avec des upstreams stables est la réponse habituelle. Évitez les grands pas temporels sur des nœuds de cluster en fonctionnement à moins de comprendre les effets secondaires. Si vos logs montrent des sauts de temps,
vos diagnostics deviennent de la fiction. Réparez le temps d’abord, puis tout le reste devient plus simple.

Une citation fiabilité à garder sur un post-it : Paraphrased idea de John Allspaw : « La fiabilité vient de permettre un apprentissage sûr et rapide, pas de blâmer les gens quand les systèmes nous surprennent. »

Blague #2 : Augmenter les timeouts Corosync pour arrêter les flaps, c’est comme monter le volume de la radio pour corriger le voyant moteur — ça change l’ambiance, pas le problème.

Erreurs fréquentes : symptôme → cause → correction

1) Symptom: random `link down` during backups

Cause racine : le trafic de sauvegarde congestionne le switch/uplink partagé ; des micro-bursts font tomber l’UDP Corosync.

Correction : isolez Corosync sur NIC/VLAN/switch dédié ; appliquez du QoS ; limitez la concurrence des sauvegardes ; confirmez avec des tests fping.

2) Symptom: flaps only on one ring (ring1 keeps going faulty)

Cause racine : VLAN de ring1 mal taggé, câble/optique défectueux, mismatch MTU, ou IP/subnet erroné.

Correction : validez /etc/pve/corosync.conf, lancez des pings DF sur ring1, vérifiez les compteurs ip -s link, remplacez les composants physiques suspects.

3) Symptom: after enabling jumbo frames, cluster becomes unstable

Cause racine : déploiement MTU partiel ; PMTUD bloqué ; fragmentation/drop affectant UDP.

Correction : imposez la cohérence MTU de bout en bout ou revenez à 1500 pour Corosync ; autorisez les types ICMP essentiels en interne ; validez avec des pings DF.

4) Symptom: “Quorum lost” in a two-node cluster during brief link blips

Cause racine : pas de tie-breaker externe ; comportement classique de prévention du split-brain pour deux nœuds.

Correction : déployez qdevice/qnetd ; assurez-vous qu’il soit sur un domaine de défaillance indépendant ; vérifiez avec pvecm qdevice status.

5) Symptom: Corosync seems fine, but membership churns under CPU load

Cause racine : latence d’ordonnancement ; softirq backlog ; traitement des paquets retardé.

Correction : réduisez la contention (pinner les interruptions, ajuster RPS/XPS, réduire le trafic bruyant), évitez de saturer le CPU hôte pendant les opérations critiques.

6) Symptom: one node frequently “starts the flap”

Cause racine : ce host a des problèmes de driver NIC, RX drops, firmware défectueux, ou une VM voisine bruyante saturant le bridge.

Correction : comparez ip -s link, softnet_stat, et les logs entre nœuds ; mettez à jour firmware/driver NIC ; isolez la NIC de cluster des bridges invités si possible.

7) Symptom: flaps after firewall changes

Cause racine : ports UDP bloqués, fragments supprimés, ou règles asymétriques d’autorisation entre nœuds.

Correction : autorisez explicitement Corosync UDP entre les adresses d’anneau ; confirmez avec tcpdump et ss -u -lpn (voir tâche à ajouter à votre runbook).

8) Symptom: flaps coincide with switch maintenance or STP events

Cause racine : reconvergence spanning tree, flaps de port, renégociation LACP provoquant des pertes en rafale.

Correction : utilisez portfast/edge où approprié, validez le hashing LACP, évitez la reconvergence L2 sur le VLAN Corosync, et envisagez deux anneaux sur des paires de switches indépendantes.

Checklists / plan pas-à-pas

Plan de stabilisation pas-à-pas (faire dans cet ordre)

Confirmez que le symptôme est réel : capturez pvecm status, corosync-cfgtool -s, et les 10 dernières minutes de logs Corosync sur tous les nœuds. Vous avez besoin des horodatages et du nœud ayant déclaré en premier.
Gelez les changements : arrêtez les réglages « utiles » pendant que vous mesurez. Désactivez les migrations non essentielles et les tâches lourdes jusqu’à stabilisation des comms.
Prouvez la MTU de bout en bout : ping DF au payload maximum prévu sur chaque anneau entre chaque paire de nœuds. Corrigez immédiatement les mismatches.
Mesurez perte/jitter : lancez fping pendant quelques minutes. Toute perte est inacceptable pour le plan de contrôle.
Inspectez les drops côté hôte : vérifiez ip -s link et /proc/net/softnet_stat. Si l’hôte droppe, le switch est innocent (pour une fois).
Validez la symétrie de routage : assurez-vous que le trafic Corosync reste sur l’interface prévue et ne fait pas de hairpin via routeurs ou firewalls.
Vérifiez la stabilité temporelle : confirmez la santé chrony/NTP ; assurez-vous qu’aucun saut n’a lieu pendant les incidents.
Corrigez le design de quorum : deux nœuds → ajoutez qdevice ; trois+ → vérifiez les votes attendus, supprimez les nœuds obsolètes, vérifiez le qdevice s’il est utilisé.
Ce n’est qu’ensuite que vous envisagez le tuning : si votre environnement a du jitter inévitable (liens longue distance, overlays chiffrés), ajustez les timeouts prudemment et documentez les compromis.

Checklist opérationnelle pour tout changement réseau touchant Corosync

Enregistrez l’état actuel des anneaux et du membership.
Exécutez des pings DF pour les deux anneaux vers chaque nœud.
Effectuez un burst fping de 2–5 minutes et archivez les résultats.
Vérifiez les compteurs ip -s link avant/après.
Confirmez que les règles de firewall n’ont pas changé pour les VLAN d’anneau.
Après le changement : vérifiez que corosync-cfgtool -s ne montre pas de faults et que le membership est stable pendant au moins 30 minutes.

FAQ

1) Est-ce que « link down » signifie que le lien NIC est réellement tombé ?

Pas nécessairement. Cela signifie que Corosync considère son lien de transport comme malsain. Cela peut être une perte physique du lien, mais plus souvent c’est une perte/jitter de paquets au-delà de la tolérance.
Vérifiez toujours avec ip -s link, les compteurs du switch et les logs.

2) Est-ce que je dois simplement augmenter le token timeout ?

Pas en premier. Si vous augmentez les timeouts pour masquer la perte, vous ralentissez la détection des pannes et pouvez empirer le comportement HA. Réparez d’abord la stabilité du transport, puis tunez prudemment
si vous avez un besoin mesuré.

3) Est-il acceptable d’exécuter Corosync sur le réseau de management ?

« Acceptable » est une décision métier. Si le réseau de management est calme, dédié et stable, c’est acceptable. S’il est partagé avec du trafic utilisateur, des sauvegardes ou un routage imprévisible,
vous construisez un générateur de flaps. VLAN dédié au minimum est la base sensée.

4) Ai-je besoin de deux anneaux ?

Si vous tenez à la disponibilité, oui. Mais seulement s’ils représentent des domaines de défaillance séparés. Deux anneaux sur la même pile de switches n’est qu’un peu mieux qu’un anneau, et parfois pire
si cela ajoute de la complexité sans isolation réelle.

5) Pourquoi mon cluster à trois nœuds perd-il encore parfois le quorum ?

En général parce qu’un nœud est isolé de façon intermittente ou surchargé, ou parce que les votes attendus sont mal configurés (entrée de nœud obsolète). Vérifiez pvecm status et les logs.
Si un nœud « disparaît » à répétition, diagnostiquez le chemin réseau et la charge de cet hôte.

6) Le trafic Ceph peut-il provoquer des flaps Corosync ?

Absolument, s’ils partagent des NICs/switches/uplinks et que Ceph recovery ou backfill sature le chemin. Ceph peut créer des débits soutenus et des patterns rafales.
Corosync n’a pas besoin de beaucoup de bande passante, mais il a besoin d’une livraison cohérente.

7) Le multicast est-il requis pour Corosync ?

Les clusters Proxmox modernes utilisent couramment knet/comportement unicast selon la configuration. Le multicast peut fonctionner, mais il est souvent mal géré dans les réseaux d’entreprise.
Si vous dépendez du multicast, validez le comportement IGMP snooping et confirmez que les switches traitent correctement le VLAN.

8) Quelle est la preuve la plus rapide qu’un mismatch MTU est en cause ?

Un ping DF avec un grand payload qui échoue sur un chemin et réussit sur un autre. Si vous attendez du jumbo, testez près de 9000. Si cela échoue avec « message too long » ou est silencieusement perdu,
vous avez trouvé un vrai problème, pas une théorie.

9) Un CPU occupé peut-il vraiment faire croire à Corosync que le réseau est tombé ?

Oui. Si l’hôte ne peut pas traiter les interruptions réseau ou ordonnancer Corosync à temps, les paquets sont perdus ou retardés. Vérifiez les drops softnet et corrélez les flaps avec la pression CPU/IO.

10) Et si je n’ai que deux nœuds et ne peux pas ajouter un troisième pour qdevice ?

Alors acceptez que vous n’avez pas de modèle de quorum résilient. Vous pouvez fonctionner, mais vous devrez choisir entre disponibilité et sécurité lors des partitions.
Si l’activité exige du HA, trouvez un troisième domaine de défaillance pour qnetd — même un petit hôte externe — avant d’accuser Corosync de faire son travail.

Conclusion : prochaines étapes pour réduire les alertes

« Corosync link down » n’est pas un puzzle de configuration. C’est votre cluster qui vous dit que le plan de contrôle ne peut pas faire confiance au réseau ou à l’hôte dans des conditions réelles.
Traitez cela comme un défaut de fiabilité production.

Prochaines étapes qui font vraiment la différence :

Prouvez la cohérence MTU sur chaque chemin d’anneau avec des pings DF et corrigez les mismatches.
Mesurez la perte avec fping et éliminez-la — en particulier les micro-bursts provenant d’uplinks partagés.
Vérifiez les drops côté hôte (softnet, RX drops) et réduisez la contention interrupt/CPU.
Rendez les anneaux réels : domaines de défaillance séparés, pas seulement des IP séparées.
Corrigez le design du quorum : deux nœuds obtiennent un qdevice, trois nœuds vérifient les votes et suppriment les zombies.
Ce n’est qu’après que vous réglez les timeouts Corosync, et documentez le compromis sur le temps de détection des pannes.

L’état final stable est ennuyeux : pas d’agitation de membership, pas de reconfigurations surprises, et pas de débats nocturnes pour savoir si « c’est probablement le réseau ».
Quand Corosync se tait, le reste de votre stack Proxmox recommence à dire la vérité.