Proxmox Corosync «link down»: чому кластер флапає й як його стабілізувати

October 6, 2025 • February 3, 2026 • Читання: 5 хв • Views: 5

Було корисно?

Інтерфейс Proxmox був зелений. Потім він став червоним. Потім ваші вузли вирішили, що знову самі по собі, наче розподілена система переживає фазу розриву.
У логах Corosync бачите link down, зникає кворум, HA нервує, і раптом ваше «просте» вікно технічного обслуговування має живу аудиторію.

«Link down» — це не містична примха Corosync. Це симптом: втрата пакетів, джиттер, невідповідність MTU, дивності апаратного офлоуда NIC, поганий дизайн кілець,
дрейф часу, перевантажені хости або кластер з двома вузлами, що удає, ніби правила кворуму на нього не поширюються. Повернемо це до рутинного стану.

Що насправді означає «link down» у Corosync

У Proxmox VE Corosync — це шар кластерного зв’язку. Саме він вирішує, чи вузли можуть надійно чути одне одного і чи кластер досі утворює єдину когерентну групу.
Коли Corosync каже link down, це не обов’язково говорить про фізичну пропажу ефіру Ethernet
(хоч таке теж може статись). Мова про те, що його транспортний шлях — його кільце — став непридатним, бо повідомлення не доходять у очікуваний часовий інтервал
або ж виявлено розділення мережі.

Corosync має власні принципи. Він швидше оголосить link down, ніж мовчки прийме ненадійний зв’язок. І це правильний підхід: ненадійна кластерна комунікація
породжує ситуацію «половина вузлів думає X, половина думає Y», що перетворює сховище та HA на джерело проблем.

Практичний переклад: Corosync link down означає, що плоскость керування кластера зазнає втрат пакетів, надмірного джиттера, перемішування пакетів
або затримок планування — і все це перевищує толерантність Corosync, встановлену таймаутами токена та логікою повторних передач. Виправляйте мережу
та поведінку хостів; не варто просто «збільшувати таймаути, поки не припинить скаржитись», якщо ви не виміряли компроміс.

Суха істина: якщо кільце Corosync нестабільне, усе над ним починає брехати. UI бреше. HA бреше. «Вчора працювало» бреше.

Факти й контекст: чому Corosync поводиться так

Corosync походить від проєкту OpenAIS (середина 2000-х) і був створений для надійного групового обміну повідомленнями; це не початково фіча Proxmox.
Протокол Totem (серце повідомлень Corosync) проєктований навколо членства й впорядкованих повідомлень; він консервативний щодо розділень.
Членство на основі токена — класичний підхід: якщо токен не може пройти вчасно, ви викидаєтесь. Ось чому таймаути важливі.
Кворум у двовузлових конфігураціях історично складний; існують зовнішні пристрої кворуму, бо «2» — політичне, а не відмовостійке число.
Колись мультикаст був рекомендований для деяких стеків, але сучасні дата-центри часто відключають або неконсистентно обробляють його, тому люди йдуть до унікасту.
Резервування кільця — не новинка: кластери HA давно використовують подвійну мережу (публічна + приватна heartbeat), бо «один комутатор» — не стратегія.
Режими bonding у Linux мають історію сюрпризів під втратами пакетів або асиметричною маршрутизацією; кластерний трафік — місце, де «практично нормально» стає «не нормально».
Помилки MTU — давня проблема і все ще живуть: jumbo-кадри, що мовчки деградують або фрагментуються, створюють саме ту переривчасту втрату, яка вбиває токен-кільце.

Чому кластер флапає: важливі режими відмов

1) Втрата пакетів (важливі мікропікети)

Corosync не потребує «великої втрати», щоб завдати шкоди. Кілька втрачених пакетів у щільному вікні можуть викликати повторні передачі і затримки токена, що веде до рішення link-down.
Мікроберсти — короткі сплески затору — відомі тим, що їх не видно в простому моніторингу. Комутатор може бути «нормальний» у середньому, але скидати саме той пакет, що потрібен кластеру.

2) Джиттер і затримки планування (хост теж мережа)

Навіть якщо мережевий шлях ідеальний, зайнятий хост може поводитись як втрата мережі, якщо потоки Corosync не можуть виконатись. Перевантаження CPU, бурі переривань,
затримки в роботі дисків та інші глюки ядра можуть затримувати обробку. Corosync вимірює час у реальному часі; ваш планувальник — у «коли дістанусь до цього» часі.

3) Невідповідність MTU і дивності фрагментації

Кластери часто живуть у «спеціальних» мережах: VLAN, jumbo-кадри, bonding, бріджі, NIC-offload, правила фаєрвола і іноді overlay. Класична проблема — невідповідність MTU:
pings працюють (малі), але великі пакети фрагментуються або падають, і Corosync отримує переривчасті таймаути.

4) Помилки дизайну кілець: точки відмов, замасковані під «резервування»

Якщо ring0 і ring1 використовують той самий комутатор, ту саму NIC, ту саму підлеглу лінію бонду або той самий шлях нагору, у вас не резервування, а дві назви одної проблеми.
Corosync зрадістю може флапати обидва кільця, якщо ваші «два кільця» насправді — один домен відмови.

5) Неправильний unicast/multicast або «допомога» фаєрвола

Corosync потребує послідовної доставки. Напівналаштований мультикаст, збої IGMP snooping або фаєрвол, що відкидає UDP-фрагменти, роблять членство нестабільним.
Corosync використовує UDP; UDP плюс «політика корпоративного фаєрвола» — стосунки, які потребують порозуміння.

6) Дрейф синхронізації часу та стрибки годинника

Таймаути токена припускають, що годинники адекватні. NTP/chrony, що роблять відкат часу, або вузли з радикально різними джерелами часу, можуть посилювати джиттер і викликати хибні підозри.
Corosync не суворо залежить від синхронізації годин, як деякі БД, але дикі часові артефакти ускладнюють діагностику й роблять таймаути непередбачуваними.

7) Граничні випадки кворуму (особливо двовузлові кластери)

Коли один вузол не бачить іншого, постає питання: хто «кластер»? У двох вузлах немає більшості без допомоги.
Proxmox пропонує qdevice/qnetd, щоб уникнути класичного сценарію split-brain. Ігноруєте це — і link-flap перетвориться на «кластер вниз».

Жарт №1: двовузловий кластер без qdevice — як конференц-дзвінок із двома людьми: коли стає тихо, обидва думають, що інший повісив слухавку.

Швидкий план діагностики (щодо першочергових перевірок)

Мета — швидко знайти вузьке місце: це шлях мережі, планування хоста чи дизайн кворуму? Не починайте з редагування таймаутів.
Почніть із доведення, де саме відбувається втрата або затримка.

Спочатку: підтвердьте, що це нестабільність членства Corosync, а не «дивина інтерфейсу»

Перевірте стан Corosync і кластера: зміни членства, стан кілець, очікувані голоси.
Перегляньте логи навколо флапу: який вузол першим оголосив link down?

Далі: перевірте транспортний шлях (втрати, MTU, фаєрвол, симетрія маршрутизації)

Запустіть таргетовані ping-тести з DF і більшими payload на інтерфейсах Corosync.
Зніміть короткий tcpdump під час вікна флапу; шукайте розриви та ICMP frag-needed.
Перевірте лічильники комутатора (навіть якщо «мережна команда каже, що все в порядку»).

Потім: перевірте хост на предмет затримок (CPU, переривання, softnet drops, паузи в I/O)

Шукайте сплески ksoftirqd, RX drops, переповнення ring buffer.
Перевірте, чи ZFS scrub, резервні копії або реплікація не насичують IO/CPU під час флапів.
Переконайтесь, що синхронізація часу стабільна (без великих стрибків або «паніки при повільному NTP»).

Четверте: перевірте стратегію кворуму

Два вузли? Додайте qdevice. Три вузли? Переконайтесь, що очікувані голоси відповідають дійсності.
Переконайтесь, що в конфігурації немає «схованого» третього голосу, що помер.

Практичні завдання: команди, очікуваний вивід і рішення

Це перевірки, які я насправді виконую, коли кластер починає флапати. Кожна містить рішення: що робити далі, залежно від результату.

Завдання 1: Підтвердити членство кластера й кворум

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

Що це означає: Якщо Quorate: No або Total votes раптово зменшується, ви маєте справу не з «дрібним мережевим спалахом», а з поділенням.

Рішення: Якщо кворум втрачається періодично, пріорітет — стабільність транспорту (Завдання 4–10) і дизайн кворуму (Завдання 12). Не чіпайте HA першочергово.

Завдання 2: Перевірити стан кілець Corosync та стан кожного лінка

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

Що це означає: Якщо бачите faulty або лише одне кільце активне, ви втратили резервування або шлях нестабільний.

Рішення: Якщо ring1 пошкоджене, перевірте проводку/VLAN/MTU саме для ring1. Не думайте, що «ring0 в порядку, отже ми в безпеці» — failover-фляпи можуть усе одно дестабілізувати членство.

Завдання 3: Витягніть релевантний зріз логів Corosync навколо флапу

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

Що це означає: Рядки «token not received» і «forming new configuration» — це бродіння членства. KNET-рядок ідентифікує, який peer/лінк впав.

Рішення: Визначте, який вузол першим повідомив про падіння і який peer фігурує. Потім протестуйте саме цей мережевий шлях (Завдання 4–8).

Завдання 4: Переконайтесь, що Corosync використовує ті інтерфейси, які ви вважаєте

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

Що це означає: Це підтверджує адресацію і транспорт. Неправильні підмережі або відсутні визначення кільця — частий результат «швидких змін».

Рішення: Якщо адреси не відповідають виділеній мережі, виправте це перш за все. Corosync на загальному зайнятому LAN — запит на джиттер.

Завдання 5: Перевірте MTU end-to-end за допомогою DF ping (малий і великий)

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

Що це означає: Ваш шлях має MTU 1500 (або щось на шляху його примушує таким бути), тож очікування jumbo помилкові.

Рішення: Або узгодьте jumbo на всіх компонентах NIC/комутатор/VLAN/мост/бонд, або стандартизуйте 1500 по всій дорозі для Corosync. Змішаний MTU — паливо для флапів.

Завдання 6: Переконайтесь у MTU на реальних Linux-інтерфейсах (включно з bridge/bond)

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

Що це означає: Якщо vmbr1 має 9000, але бонд або підлеглі NIC мають 1500, ви все одно втрачаєте. MTU має співпадати по всьому ланцюгу.

Рішення: Перевірте MTU на bondX та на підлеглих NIC. Виправте невідповідності, перш ніж чіпати таймаути Corosync.

Завдання 7: Виміряйте втрати та затримки за допомогою fping (мережа Corosync)

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

Що це означає: 4% втрат із сплесками 18 мс на кластерній мережі — не «добре». Це генератор link-down.

Рішення: Якщо бачите будь-яку втрату, зупиніться й знайдіть фізичну/логічну причину (скидання комутатора, поганий кабель/оптика, duplex mismatch, завантажений uplink).

Завдання 8: Перевірте лічильники помилок і скидань у Linux

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

Що це означає: RX dropped означає, що хост відкидає пакети (часто через буфер кільця, драйвер або тиск на CPU/переривання).

Рішення: Якщо скидання збільшуються під час флапів, досліджуйте переривання/softnet (Завдання 9), розміри черг NIC та навантаження хоста (Завдання 10).

Завдання 9: Перевірте softnet backlog drops (ядро не встигає)

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

Що це означає: Третя колонка (в hex) — відкинуті пакети через softnet backlog. Ненульові значення, що зростають під навантаженням, — гарячий доказ.

Рішення: Якщо ці лічильники ростуть під час флапів, зменшіть тиск переривань (IRQ affinity), налаштуйте черги NIC і перестаньте насичувати хост шумним трафіком на Corosync-NIC.

Завдання 10: Корелюйте флапи з тиском на CPU та I/O паузами

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

Що це означає: Високе r (run queue), нетривіальний wa (IO wait) і велика кількість переключень контексту можуть співпадати з затримками Corosync.

Рішення: Якщо флапи корелюють із резервними копіями, scrub-ами або реплікацією, перерозподіліть або обмежте їх, ізолюйте трафік Corosync (виділений NIC/VLAN, QoS).

Завдання 11: Переконайтесь, що синхронізація часу стабільна (приклад chrony)

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

Що це означає: Здорово: крихітні зсуви, стабільний stratum, немає проблем зі стрибками. Якщо бачите великі зсуви або часті стрибки, час — підозрюваний.

Рішення: Виправте стабільність NTP/chrony до налаштування Corosync. Хаос у часі ускладнює діагностику і робить таймаути непевними.

Завдання 12: Перевірте очікувані голоси та наявність qdevice (за потреби)

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

Що це означає: У двовузлових кластерах qdevice — це різниця між «коротким мережевим спалахом» і «всі панікують».

Рішення: Якщо у вас два вузли й немає qdevice, сплануйте додати його. Якщо qdevice є, але статус не OK — усуньте проблему, не покладайтесь на надію.

Завдання 13: Перевірте runtime-статистику Corosync (knet) на помилки лінків

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

Що це означає: Зростаючі errors і retries часто збігаються з фізичними втратами або проблемами MTU/PMTUD.

Рішення: Якщо retries підіймаються під час флапів, ставтесь до цього як до мережевого дефекту, поки не доведено протилежне. «Але vMotion працює» — не аргумент.

Завдання 14: Коротко захопіть трафік Corosync, щоб виявити фрагментацію/ICMP-проблеми

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

Що це означає: ICMP unreachable — великий знак: фаєрвол, неправильна адреса зв’язування або вузол не слухає на цьому інтерфейсі.

Рішення: Якщо бачите unreachable/frag-needed — виправляйте маршрутизацію/фаєрвол/MTU. Якщо під час флапів тиша — підозрюйте скид на більш ранньому етапі шляху.

Завдання 15: Перевірте стан фаєрвола для інтерфейсів Corosync

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

Що це означає: Увімкнений фаєрвол — нормально, але це означає, що слід підтвердити правила, які дозволяють Corosync на потрібних інтерфейсах/VLAN.

Рішення: Якщо флапи почалися після змін у фаєрволі, проведіть аудит правил дата-центру та хостів і підтвердіть, що UDP 5405/5404 (залежно від конфігу) дозволений між вузлами.

Три корпоративні міні-історії з реального життя (анонімізовано)

Міні-історія 1: Інцидент через хибне припущення

Середня компанія мігрувала від «одного потужного хоста» до трьох вузлів Proxmox. Вони зробили розумно — виділили VLAN для Corosync —
і необачно — помістили цей VLAN на ті самі top-of-rack комутатори, що й завантажену storage-мережу, не подумавши про патерни завантаження.

Хибне припущення було простим: «кластерний трафік малий, отже може ділити будь-що». Більшість часу це працювало. Графіки показували низьке середнє завантаження.
Усі погодились, і запит на зміну закрився емоційно.

Потім сталися щотижневі резервні копії і внутрішня експортна задача, що пробила storage-VLAN. Буфери комутатора заповнились, виникли мікроберсти, і Corosync-VLAN
отримав побічний ефект. Вузли втрачали членство на кілька секунд — достатньо, щоб викликати логіку fencing HA і розхитати кілька ВМ.

Виправлення не було в таймаутах Corosync. Вони перемістили Corosync на фізично окремі пари комутаторів і NIC, і припинили штовхати резервний трафік через ті самі uplink-и, що кластерні комунікації.
Теорія «малий трафік може ділити що завгодно» померла тихо, як і мала.

Міні-історія 2: Оптимізація, що відгукнулась бумерангом

Інша організація вирішила «оптимізувати латентність», увімкнувши jumbo frames скрізь. Мережна команда поставила MTU 9000 на комутаторах. Віртуалізаційна команда виставила MTU 9000
на Linux-бріджах. Вони раділи зарані, а це надійний спосіб покликати реальність.

Відгук: один проміжний пристрій — старий фаєрвол, що робив VLAN-маршрутизацію для management-підмережі — мовчки підтримував MTU 1500. PMTUD була непослідовною
через правила фільтрації, тож великі пакети скидались без корисного ICMP. Pings працювали. SSH працював. Усе працювало, окрім речі, що потребувала послідовної UDP-доставки під навантаженням: Corosync.

Кластер почав «випадково» флапати кілька разів на день. Команда спробувала збільшити таймаути токена. Флапи стали рідшими, але відновлення — повільнішим,
і рішення про відмову стало млявішим. Вони пожертвували коректністю заради оглушення.

Виправлення було нудне й хірургічне: забезпечити послідовність MTU end-to-end (або повернутися до 1500 для Corosync) і перестати блокувати ICMP, важливі для PMTUD,
на внутрішніх лінках. Кластер заспокоївся. «Оптимізація» виявилась генератором розподіленої невідповідності MTU.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда фінансових послуг запускала Proxmox з Ceph і поводилась з кластерними комунікаціями як з управляючим трафіком production: виділені NIC, виділені комутатори
і письмовий чекліст для будь-якої мережевої зміни. Також вони мали звичку робити короткий tcpdump до і після кожної зміни, що торкалась кластерної мережі.

Одного дня флапи почалися відразу після рутинного оновлення прошивки на комутаторі. Мережна команда наполягала, що конфігурація не змінилась. Зазвичай це правда —
до того моменту, коли ні. Віртуалізаційна команда дістала доказ: до/після захоплення показали періодичні сплески UDP-втрат кожні 30 секунд.

Вони зв’язали ці сплески зі зміною поведінки IGMP snooping після оновлення (оновлення поміняло дефолтні налаштування). Corosync працював у режимі, що покладався на припущення
щодо обробки мультикасту. З доказом на руках мережна команда відкоригувала налаштування snooping для того VLAN і валідувала зміни по лічильниках.

Кластер стабілізувався за кілька хвилин. Звичка з tcpdump не робила їх крутішими на зустрічах, але робила їх правими, коли це було важливо.

Стабілізація за дизайном: мережа, кільця, кворум і час

Побудуйте мережу кластера відчутно

Corosync чутливий до затримок, втрат і джиттера. Ставтесь до мережі Corosync як до control-plane трафіку. Це зазвичай означає:
виділений VLAN як мінімум, ідеально — виділені фізичні NIC, і пара виділених комутаторів, якщо можете собі дозволити.

Якщо змушені ділити, накладіть QoS і уникайте відомих «шумних сусідів» (резервні копії, реплікація, rebuild сховища). Не ставте членство кластеру на те, що
ваш top-of-rack буде вічно буферизувати все.

Використовуйте два кільця, але зробіть їх різними доменами відмов

Два кільця — добре. Два кільця, що ділять один комутатор — не два. Якщо ring0 і ring1 кінчаються на одному стеку комутаторів, тій самій бонд-парі
або тому самому upstream-роутері — ви побудували «театр резервування».

Ідеально: ring0 на одній NIC і парі комутаторів, ring1 на іншій NIC і іншій парі комутаторів. Прийнятно: ring1 ділиться парою комутаторів, але використовує інші NIC і інше кабелювання,
якщо ви перевірили, що сам стек комутаторів високо доступний і не насичений.

Будьте консервативні щодо MTU

Jumbo-кадри не злочин. Змішані jumbo — так. Якщо не можете довести консистентність MTU через NIC, бонд, міст, порти комутатора, VLAN-транки та будь-які проміжні L3-пристрої,
залишайтесь на 1500 для Corosync. Ви будете спати краще.

Не маскуйте проблеми налаштуванням таймаутів токена

Corosync має регулятори: таймаути токена, повторні передачі і поведінку консенсусу. Вони існують, бо середовища різні. Але налаштування — це не заміна фіксу втрат.
Довші таймаути можуть зменшити чутливість до перехідного джиттера, але також збільшують час виявлення відмови. Це означає повільніший fencing, повільніший failover
і триваліші періоди, коли кластер не погоджується.

Ось ваш компроміс: короткі таймаути — швидке виявлення відмов, але більша чутливість; довгі таймаути — менше хибних спрацьовувань, але повільніша реакція.
Налаштовуйте лише після вимірювання базової латентності й втрат і після виправлення очевидних дефектів транспорту.

Кворум: перестаньте вдавати, що два вузли — це три

Якщо ви запускаєте два вузли, додайте qdevice (qnetd) на третьому незалежному хості. Він може бути малим. Він може бути VM у іншому домені відмови.
Він не повинен сидіти на тому самому фізичному хості, який ви намагаєтесь арбітрувати. Так, люди так роблять. Ні, це не рахується.

Якщо ви маєте три і більше вузлів, перевірте, що очікувані голоси відповідають реальності, і видаліть застарілі вузли з конфігурації. Зомбі-голоси — шлях до відсутності кворуму, коли здається, що все «вгору».

Синхронізація часу: нудна, фундаментальна і без компромісів

Chrony зі стабільними upstream — звичайна відповідь. Уникайте великих часових стрибків на працюючих вузлах кластера, якщо ви не розумієте побічні ефекти.
Якщо в логах бачите стрибки часу — діагностика стає вигадкою. Виправте час першим, і все інше стане простішим.

Цитата з надійності, яка варта нагадування: Ідея у вільному переказі від John Allspaw: «Надійність приходить через можливість безпечно й швидко вчитись, а не через звинувачення людей, коли системи дивують нас.»

Жарт №2: Збільшувати таймаути Corosync, щоб припинити флапи — це як додати гучності радіо, щоб виправити лампочку «check-engine» — змінює атмосферу, а не проблему.

Поширені помилки: симптом → причина → виправлення

1) Симптом: випадковий `link down` під час резервних копій

Причина: резервний трафік створює затори на спільному комутаторі/uplink; мікроберсти скидають Corosync UDP.

Виправлення: ізолюйте Corosync на виділені NIC/VLAN/комутатор; застосуйте QoS; обмежте паралельність резервних копій; підтвердіть результат fping-тестами.

2) Симптом: флапи лише на одному кільці (ring1 постійно faulty)

Причина: ring1 VLAN неправильно тегований, поганий кабель/оптика, невідповідність MTU або неправильна IP/підмережа.

Виправлення: перевірте /etc/pve/corosync.conf, запустіть DF ping на ring1, перевірте ip -s link лічильники, замініть підозрілі фізичні компоненти.

3) Симптом: після ввімкнення jumbo frames кластер став нестабільним

Причина: часткове впровадження MTU; PMTUD заблоковано; фрагментація/скидання впливає на UDP.

Виправлення: забезпечте послідовність MTU end-to-end або поверніться до 1500 для Corosync; дозволіть важливі типи ICMP всередині; перевірте DF ping-ами.

4) Симптом: «Кворум втрачен» у двовузловому кластері під час коротких лінк-бліпів

Причина: немає зовнішнього арбітра; класичний механізм запобігання split-brain спрацьовує.

Виправлення: розгорніть qdevice/qnetd; забезпечте, щоб він був у незалежному домені відмов; перевірте за допомогою pvecm qdevice status.

5) Симптом: Corosync здається в порядку, але членство змінюється під навантаженням CPU

Причина: затримки планування; softirq backlog; затримка обробки пакетів.

Виправлення: зменшіть конкуренцію (прив’яжіть переривання, налаштуйте RPS/XPS, зменшіть шумний трафік), уникайте насичення CPU під час критичних операцій.

6) Симптом: один вузол часто «ініціює флап»

Причина: на цьому хості проблеми з драйвером NIC, RX drops, стара прошивка або гостева ВМ, що насичує міст.

Виправлення: порівняйте ip -s link, softnet_stat і логи між вузлами; оновіть прошивку/драйвер NIC; ізолюйте кластерний NIC від гостьових бриджів, якщо можливо.

7) Симптом: флапи після змін у фаєрволі

Причина: UDP-порти заблоковані, фрагменти відкидаються або асиметричні правила allow між вузлами.

Виправлення: явно дозволіть Corosync UDP між адресами кілець; підтвердіть за допомогою tcpdump і ss -u -lpn.

8) Симптом: флапи співпадають з обслуговуванням комутатора або подіями STP

Причина: реконвергенція spanning tree, флапи портів, LACP-ренеготіація — усе це створює сплески втрат.

Виправлення: використовуйте portfast/edge там, де це доречно, перевірте hashing LACP, уникайте L2-реконвергенції на VLAN Corosync і розгляньте dual-ring над незалежними парами комутаторів.

Чеклісти / покроковий план

Покроковий план стабілізації (робіть у цьому порядку)

Підтвердьте, що симптом реальний: зробіть знімки pvecm status, corosync-cfgtool -s і останніх 10 хвилин логів Corosync на всіх вузлах. Потрібні таймстемпи і хто оголосив першим.
Заморозьте зміни: припиніть «допоміжні» налаштування, поки не поміряєте. Вимкніть незахідні міграції й важкі maintenance-завдання, поки комунікація не стабілізується.
Доведіть MTU end-to-end: DF ping із максимальним payload на кожному кільці між усіма парами вузлів. Виправте невідповідності негайно.
Виміряйте втрати/джиттер: запустіть fping на кілька хвилин. Будь-яка втрата неприйнятна для control-plane.
Перевірте хостові скидання: див. ip -s link і /proc/net/softnet_stat. Якщо хост скидає — комутатор в обороні.
Перевірте симетрію маршруту: переконайтесь, що трафік Corosync йде по призначеному інтерфейсу і не робить hairpin через маршрутизатори чи фаєрволи.
Переконайтесь у стабільності часу: перевірте потужність chrony/NTP; впевніться, що під час інцидентів немає стрибків часу.
Виправте дизайн кворуму: два вузли → додайте qdevice; три+ → перевірте очікувані голоси, видаліть застарілі вузли, перевірте qdevice, якщо використовується.
Лише потім думайте про налаштування: якщо у вас невідворотний джиттер (довгі лінки, зашифровані overlay), коригуйте таймаути обережно й документуйте компроміси.

Операційний чекліст для будь-якої мережевої зміни, що торкається Corosync

Зафіксуйте поточний стан кілець і членства.
Запустіть DF ping-тести для обох кілець до кожного вузла.
Запустіть 2–5 хвилинний fping-бурст і збережіть результати.
Перевірте ip -s link лічильники до/після.
Переконайтесь, що правила фаєрвола для VLAN-ів кілець не змінились.
Після зміни: підтвердіть, що corosync-cfgtool -s не показує помилок і членство стабільне принаймні 30 хвилин.

Питання та відповіді

1) Чи означає «link down», що фізичний лінк NIC впав?

Не обов’язково. Це означає, що Corosync вважає свій транспортний лінк ненадійним. Це може бути фізична втрата, але частіше — втрата пакетів/джиттер понад допустиме.
Завжди перевіряйте ip -s link, лічильники комутатора й логи.

2) Чи варто просто збільшити token timeout?

Не перш за все. Якщо ви підвищуєте таймаути, щоб приховати втрати, ви уповільнюєте виявлення відмов і можете погіршити поведінку HA.
Виправте стабільність транспорту спочатку, потім налаштовуйте обережно, якщо є виміряна потреба.

3) Чи нормально запускати Corosync на мережі управління?

«Нормально» — це бізнес-рішення. Якщо мережа управління тиха, виділена й стабільна — гаразд. Якщо вона ділиться з користувацьким трафіком, резервними копіями або має непередбачувану маршрутизацію,
ви створюєте генератор флапів. Виділений VLAN — мінімум здорового глузду.

4) Чи треба мати два кільця?

Якщо вам важливий uptime — так. Але лише якщо вони — різні домени відмов. Два кільця на одному стеку комутаторів — трохи краще за одне, іноді гірше, якщо додають складність без реальної ізоляції.

5) Чому мій три вузловий кластер іноді втрачає кворум?

Зазвичай тому, що один вузол періодично ізольований або перевантажений, або очікувані голоси неправильно налаштовані (застарілий запис вузла). Перевірте pvecm status і логи.
Якщо один вузол часто «зникає», діагностуйте мережевий шлях і навантаження на цьому вузлі.

6) Чи може трафік Ceph спричиняти флапи Corosync?

Абсолютно, якщо вони ділять NIC/комутатори/uplink-и і Ceph recovery або backfill насичує шлях. Ceph може створювати тривалий великий трафік і вибухові патерни.
Corosync не потребує багато пропускної здатності, але потребує послідовної доставки.

7) Чи потрібен мультикаст для Corosync?

Сучасні кластери Proxmox зазвичай використовують knet/унікаст в залежності від конфігурації. Мультикаст може працювати, але часто в корпоративних мережах обробляється неправильно.
Якщо ви покладаєтесь на мультикаст — перевірте поведінку IGMP snooping і підтвердіть, що комутатори коректно трактують VLAN.

8) Який найшвидший доказ, що причина — невідповідність MTU?

DF ping із великим payload, який не проходить по одному шляху і проходить по іншому. Якщо ви очікуєте near-9000 — тестуйте близько 9000. Якщо він падає з «message too long» або мовчить,
ви знайшли реальну проблему, а не теорію.

9) Чи може зайнятий CPU реально змусити Corosync вважати мережу відпалою?

Так. Якщо хост не встигає обробляти мережеві переривання або планувати Corosync вчасно, пакети губляться або затримуються. Перевірте softnet-drops і корелюйте флапи з CPU/IO тиском.

10) Що робити, якщо у мене тільки два вузли і немає можливості додати третій для qdevice?

Тоді прийміть, що у вас немодельний кворум. Ви можете працювати, але мусите обирати між доступністю і безпекою під час розділень.
Якщо бізнес потребує HA, знайдіть третій домен відмов для qnetd — навіть маленький зовнішній хост — перш ніж звинувачувати Corosync за те, що він виконує свою роботу.

Висновок: наступні кроки, що зменшать шум пейджера

«Corosync link down» — це не конфігураційна загадка. Це кластер, що каже вам, що plane керування не може довіряти мережі або хосту в реальних умовах.
Ставтесь до цього як до дефекту надійності production.

Наступні кроки, які реально змінюють ситуацію:

Доведіть консистентність MTU на кожному шляху кільця за допомогою DF ping і виправте невідповідності.
Виміряйте втрати fping-ом і усуньте їх — особливо мікроберсти від спільних uplink-ів.
Перевірте хостові скидання (softnet, RX drops) і зменшіть тиск на переривання/CPU.
Зробіть кільця реальними: окремі домени відмов, а не просто різні IP-адреси.
Виправте дизайн кворуму: два вузли — отримайте qdevice, три вузли — перевірте голоси і видаліть зомбі.
Лише потім налаштовуйте таймаути Corosync і документуйте компроміс часу виявлення відмов.

Стабільний кінцевий стан — нудний: немає змін членства, немає несподіваних переконфігурацій і немає нічних суперечок про те, чи «напевно це мережа».
Коли Corosync замовкає, решта стека Proxmox знову починає говорити правду.