Proxmox Ceph «mon down/out of quorum»: відновлення моніторів і кворуму без паніки

Як насправді відмовляє кворум моніторів Ceph (ментальна модель)

Монітори Ceph (MON) — це не «ще один демон». Вони джерело істини для кластера: monmap (хто є моніторами), osdmap (які OSD існують і де), стан авторизації (CephX) та купа станів консенсусу, які мають збігатися в більшості.

Монітори формують кворум за допомогою алгоритму консенсусу (історично Ceph використовував Paxos-подібні механізми та еволюціонував з релізів). Простими словами: монітори мають надійно спілкуватися між собою й погоджувати останні підтверджені мапи. Якщо не можуть — краще перестати бути авторитетними, ніж брехати.

Що зазвичай означає «down» проти «out of quorum»

• mon down: процес монітора недоступний або не запущений (або завис настільки, що це практично еквівалентно вимкненню).
• out of quorum: процес працює, але не є частиною більшості, яка зараз погоджує стан. Він може бути частково ізольований, зручитись за годинником, мати старий monmap або ушкоджене сховище.
• no quorum: кластер фактично «сліпий». OSD можуть ще деякий час обслуговувати існуючі IO, але зміни стану й звітування про здоров’я стають обмеженими й ризикованими. Трактуйте це як «припиніть імпровізувати».

Золоте правило

Ніколи не «виправляйте кворум», видаляючи елементи, поки не з’ясуєте, який монітор має найсвіжішу правду. Якщо ви стерли неправильний монітор, ви можете перетворити відновлюваний простій на проєкт з відтворення кластера.

Ось операційна установка, яку я хочу, щоб ви прийняли: монітори — це plane керування; OSD — plane даних. Ви можете пережити пошкоджену plane даних завдяки надлишковості. Ви не переживете контрольну площину, яка помиляється і від цього впевнена.

Цитата, яку варто мати на стіні: Hope is not a strategy. — General Gordon R. Sullivan. В операціях це не мотивація; це нагадування перевіряти, перш ніж змінювати.

Жарт №1: Монітор Ceph поза кворумом — як менеджер, який не в нараді: все ще надсилає листи, але ніхто їм серйозно не довіряє.

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

Це послідовність «зупинити кровотечу». Не починайте з відтворення моніторів. Почніть з доведення режиму відмови.

Перший крок: Чи взагалі є кворум?

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

Другий крок: Чи проблема маскується під мережу або час?

Мережеві розриви та зсув часу — дві найпопулярніші причини «ніби все зламалося». Перевіряйте їх перед тим, як чіпати дані моніторів.

Третій крок: Чи здорове сховище монітора (місце на диску, файлову систему, корупція)?

Монітори чутливі до подій «диск заповнений» і проблем з файловою системою. Монітор може «працювати», але фактично бути мертвим, бо не може комітити.

Четвертий крок: Чи monmap/FSID неправильний або застарілий на вузлі?

Поширена пастка Proxmox/Ceph: на вузлі залишилися конфіги від старого кластера або його перевстановили, і тепер він впевнено говорить з неправильною ідентичністю.

П’ятий крок: Лише тепер розглядайте відтворення/пересоздання

Відтворення монітора безпечне, коли у вас є кворум і ви замінюєте учасника. Це небезпечно, коли нема кворуму і ви робите припущення.

Цікаві факти та контекст (чому монітори чутливі)

1. Назва Ceph походить від міфологічного морського монстра (Cephalopod). Це кумедна назва для системи, яка вас кусає за халатні операції.
2. Монітори Ceph роками використовували механізм консенсусу на базі Paxos; мета дизайну — сильна консистентність мап, а не «завжди бути доступним за будь-яку ціну».
3. Правило «непарна кількість MON» — не містицизм. Більшістевий консенсус означає: 3 MON витримають 1 відмову; 4 — все одно 1; 5 витримають 2.
4. Зсув часу — це першокласна відмова у розподілених системах. Монітори можуть відмовлятися брати участь, якщо зсув годинника ламає припущення про таймаути/лізи.
5. Стан авторизації CephX зберігається й роздається моніторами; монітор з пошкодженими keyring може проявлятися як «випадкові помилки доступу» по кластеру.
6. Монітори зберігають критичні мапи на локальному диску; вони не «безстанні». Ставтеся до сховища монітора як до маленької бази даних з реплікацією консенсусом.
7. Інтеграція Proxmox робить розгортання легким, але також полегшує забуття про інструменти життєвого циклу Ceph (і їхню важливість).
8. Історично «корупція сховища монітора» часто була наслідком повного диска, відключення живлення або багів у файловій системі — рідко це «Ceph просто вирішив забути».

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

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

Завдання 1: Перевірити поточний вигляд кворуму (з будь-якого вузла з ceph.conf + ключем)

cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_WARN
            1/3 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2 (age 5m), out of quorum: mon3
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 40 TiB / 53 TiB avail
    pgs:     256 active+clean

Значення: У вас є кворум (mon1, mon2). mon3 — пацієнт, а не хірург.

Рішення: Відремонтуйте/поверніть mon3 за допомогою здорового кворуму. Уникайте операцій з «force».

Завдання 2: Якщо ceph -s зависає, перевірте пряму доступність MON

cr0x@server:~$ timeout 5 ceph -s; echo $?
124

Значення: Код виходу 124 = timeout. Часто це означає «немає кворуму» або клієнт не може дістатися до моніторів.

Рішення: Перейдіть до перевірок мережі/часу й локальних логів монітора. Не починайте змінювати мапи Ceph з хоста, який навіть не може говорити з MON.

Завдання 3: Визначити кінцеві точки моніторів з конфігу

cr0x@server:~$ grep -E '^(fsid|mon_host|public_network|cluster_network)' /etc/pve/ceph.conf
fsid = 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
mon_host = 10.10.10.11 10.10.10.12 10.10.10.13
public_network = 10.10.10.0/24
cluster_network = 10.10.20.0/24

Значення: Ви маєте очікувані IP. Якщо IP монітора змінився, він «існує», але ніколи не буде знайдений.

Рішення: Підтвердіть, що ці IP коректні на кожному вузлі. Якщо ні — виправте мережу/DNS і лише потім чіпайте Ceph.

Завдання 4: Перевірити стан systemd MON (чи він справді запущений?)

cr0x@server:~$ systemctl status ceph-mon@mon3 --no-pager
● ceph-mon@mon3.service - Ceph monitor daemon
     Loaded: loaded (/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:11:32 UTC; 2min 12s ago
    Process: 18231 ExecStart=/usr/bin/ceph-mon -f --cluster ceph --id mon3 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)

Значення: Це не загадка кворуму; це відмова сервісу на mon3.

Рішення: Читайте логи, перевірте місце на диску, перевірте mon store, потім перезапустіть.

Завдання 5: Прочитати останні логи MON для реальної причини

cr0x@server:~$ journalctl -u ceph-mon@mon3 -n 80 --no-pager
Dec 26 09:11:31 mon3 ceph-mon[18231]: mon.ceph-mon@mon3: error opening mon data directory at '/var/lib/ceph/mon/ceph-mon3': No space left on device
Dec 26 09:11:31 mon3 systemd[1]: ceph-mon@mon3.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:32 mon3 systemd[1]: ceph-mon@mon3.service: Failed with result 'exit-code'.

Значення: Диск заповнений. Класично. Передбачувано. Виправляється.

Рішення: Вивільніть місце безпечно, при необхідності запустіть перевірку файлової системи, потім перезапустіть MON.

Завдання 6: Перевірити місткість файлової системи і навантаження по інодах

cr0x@server:~$ df -h /var/lib/ceph/mon/ceph-mon3
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   50G     0 100% /

cr0x@server:~$ df -i /var/lib/ceph/mon/ceph-mon3
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       3276800 220000 3056800    7% /

Значення: Проблема в ємності, не в інодах.

Рішення: Видаліть правильний «сміття» (логи, старі ядра, дампи). Не видаляйте файли mon store у шаленстві.

Завдання 7: Перевірити синхронізацію часу (кворум ненавидить мандрівників у часі)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 09:14:10 UTC
           Universal time: Fri 2025-12-26 09:14:10 UTC
                 RTC time: Fri 2025-12-26 09:14:09
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Цей вузол синхронізований.

Рішення: Запустіть це на кожному MON. Якщо якийсь показує «synchronized: no» або великий зсув, виправте NTP/chrony перед повторною спробою кворуму.

Завдання 8: Перевірити, чи порти MON доступні між моніторами

cr0x@server:~$ nc -vz 10.10.10.11 3300
Connection to 10.10.10.11 3300 port [tcp/*] succeeded!

cr0x@server:~$ nc -vz 10.10.10.12 6789
Connection to 10.10.10.12 6789 port [tcp/*] succeeded!

Значення: Сучасний Ceph використовує 3300 (msgr2); стара сумісність — 6789 (msgr1). Якщо ці підключення не проходять, кворум не повернеться, поки мережа/фаєрвол не виправлені.

Рішення: Якщо блокуються: виправте правила фаєрволу, VLAN, MTU, маршрутизацію. Якщо відкриті: переходьте до перевірки mon store.

Завдання 9: Підтвердити існування директорії і права на ідентичність MON

cr0x@server:~$ ls -ld /var/lib/ceph/mon/ceph-mon3
drwxr-x--- 8 ceph ceph 4096 Dec 26 09:02 /var/lib/ceph/mon/ceph-mon3

Значення: Директорія існує і належить ceph.

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

Завдання 10: Подивитися, кого кластер вважає моніторами (mon dump)

cr0x@server:~$ ceph mon dump
epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000
min_mon_release 18 (reef)
election_strategy: 1
0: [v2:10.10.10.11:3300/0,v1:10.10.10.11:6789/0] mon.mon1
1: [v2:10.10.10.12:3300/0,v1:10.10.10.12:6789/0] mon.mon2
2: [v2:10.10.10.13:3300/0,v1:10.10.10.13:6789/0] mon.mon3

Значення: mon3 все ще в monmap. Добре. Ви хочете, щоб він приєднався знову, а не додавався заново, якщо це не потрібно.

Рішення: Якщо IP/hostname тут неправильний, потрібно виправити адресацію (або, у крайньому випадку, правильно видалити/додати монітор).

Завдання 11: Перевірити підказки щодо здоров’я сховища монітора (fsck для файлових систем; це для MON)

cr0x@server:~$ ceph-mon -i mon3 --cluster ceph --mon-data /var/lib/ceph/mon/ceph-mon3 --check
ceph-mon: mon data is consistent

Значення: Сховище монітора виглядає послідовним для запуску.

Рішення: Перезапустіть сервіс. Якщо перевірка повідомляє про корупцію — зупиніться і оберіть шлях відновлення замість повторних перезапусків.

Завдання 12: Перезапустити MON і спостерігати, як він приєднується до кворуму

cr0x@server:~$ systemctl restart ceph-mon@mon3
cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 10s)
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in

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

Рішення: Тепер зробіть наступні дії: чому диск заповнився? Додайте алерти і хазяйське утримання, щоб це не повторилося в п’ятницю ввечері.

Завдання 13: Якщо немає кворуму, перевірити локальний вигляд mon без контакту з кластером

cr0x@server:~$ ceph-mon -i mon1 --cluster ceph --show_monmap | head
dumped monmap epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000

Значення: Ви можете прочитати monmap з локального сховища. Це допомагає довести, яке сховище ціле.

Рішення: Порівняйте між вузлами; найсвіжіший epoch і послідовний FSID — ваші підказки, кому довіряти.

Завдання 14: Підтвердити, що FSID співпадає між Proxmox ceph.conf і mon store

cr0x@server:~$ ceph fsid
0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f

Значення: Якщо це повертає інший FSID, ніж /etc/pve/ceph.conf, ви змішуєте кластери або конфіги.

Рішення: Зупиніться і узгодьте конфігурації перед тим, як «виправляти» щось інше.

Завдання 15: Перевірити, що монітор слухає на очікуваних адресах

cr0x@server:~$ ss -lntp | egrep ':(3300|6789)\s'
LISTEN 0      4096         10.10.10.13:3300       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=20))
LISTEN 0      4096         10.10.10.13:6789       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=21))

Значення: Він прослуховує правильно. Якщо слухає тільки на 127.0.0.1 або неправильному інтерфейсі — ви знайшли винуватця.

Рішення: Виправте хост-мережу і/або налаштування public_network у Ceph; перезапустіть.

Завдання 16: Перевірити політику фаєрволу, що блокує трафік між вузлами

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

cr0x@server:~$ iptables -S | head
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N PVEFW-Drop
-N PVEFW-Input

Значення: У вас політика за замовчуванням DROP. Це нормально, але лише якщо порти Ceph дозволені між MON.

Рішення: Якщо правила змінилися недавно, перевірте набори правил і забезпечте доступ TCP 3300 і (за потреби) 6789 у мережі Ceph.

Завдання 17: Санітарна перевірка інструментів Proxmox Ceph (не боріться з платформою)

cr0x@server:~$ pveceph status
Cluster FSID: 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
MONs: 3, quorum: mon1, mon2, mon3
OSDs: 12 up/12 in
MGR: mon1 (active)

Значення: Підтверджує, що погляд Proxmox збігається з поглядом Ceph.

Рішення: Якщо вони не збігаються — підозрюйте дрейф конфігів між /etc/pve, локальним /etc/ceph і тим конфігом, який насправді використовує ваш CLI.

Шляхи відновлення: від «один mon down» до «немає кворуму»

Сценарій A: Один монітор down, кворум існує (найкращий випадок)

Це «нормальна» відмова. У вас достатньо моніторів для підтримки більшості. Ваша мета — повернути відсутній монітор в обслуговування або чисто його замінити.

• Виправте локальну причину (диск заповнений, сервіс впав, вузол перезавантажився в неправильному ядрі, мережевий інтерфейс впав).
• Перевірте синхронізацію часу і мережеві порти.
• Запустіть монітор і спостерігайте його приєднання.

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

Сценарій B: Два монітори впали в кластері з 3 MON (немає кворуму)

Тепер ви в режимі «відновити більшість». З 3 MON вам потрібно 2. Найбезпечніше відновлення зазвичай виглядає так:

1. Виберіть вузол-монітор, який найімовірніше цілий (стабільне сховище, менше змін, ймовірно має недоторканий mon store).
2. Запустіть цей монітор чисто і перевірте його store.
3. Підніміть ще один монітор, щоб досягти кворуму.
4. Коли кворум відновлено, відтворіть решту моніторів з використанням здорового кворуму, а не намагайтеся реанімувати пошкоджене сховище.

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

Сценарій C: Усі монітори «up», але жоден не в кворумі (флапінг кворуму або спліт-брейн)

Зазвичай це мережевий розрив або зсув часу. Іноді це невідповідність MTU у Ceph public network: малі пакети проходять, великі — ні, й усе виглядає «майже доступним».

Пріоритети:

• Перевірка синхронізації годинника між усіма MON.
• Двостороння доступність портів 3300/6789 між усіма MON.
• Правильність інтерфейсів/IP (немає дубльованих IP, немає застарілих ARP, немає сюрпризів від VRRP).
• Перегляд змін у фаєрволі (Proxmox або вище).

Сценарій D: Пошкодження store монітора (невтішний варіант)

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

На практиці ви зробите одне з наступного:

• Відтворити один монітор із існуючого кворуму (безпечний шлях).
• Створити нового монітора і приєднати до кворуму (безпечно, якщо кворум існує).
• Відновити кворум, запустивши найліпше збереження монітора і додавши інших (ризиковано, але інколи необхідно).

Жарт №2: Пошкоджене сховище монітора — як пошкоджена таблиця Excel: хтось запропонує «просто переписати», і цій людині не мав би бути наданий доступ у продакшн.

Чеклисти / покроковий план (робіть це, а не за відчуттями)

Чеклист 1: Коли кворум ще є (ремонтуємо один MON)

1. Підтвердіть, що кворум існує за допомогою ceph -s. Якщо команда зависає — перемкніться на локальну діагностику.
2. На вузлі збою MON: systemctl status ceph-mon@<id> та journalctl -u ....
3. Виправте корінь проблеми: диск заповнений, права, NIC відключений, час не синхронізований, правило фаєрволу.
4. Запустіть перевірку сховища: ceph-mon -i <id> --check (де підтримується), щоб уникнути флапінгу.
5. Перезапустіть MON і підтвердьте, що він слухає (ss -lntp).
6. Підтвердіть приєднання в ceph -s і ceph quorum_status.
7. Виконайте післяпрацю: моніторинг використання диска, додайте алерти, запобіжні заходи, щоб не повторилося.

Чеклист 2: Коли у вас немає кворуму (безпечно відновити більшість)

1. Припиніть глобальні зміни в кластері. Ваша мета — знайти одне або два хороші збереження моніторів.
2. Виберіть кандидата «найкращого монітора» (найстабільніше сховище, найменше змін, ймовірно найціліший mon store).
3. На кожному вузлі MON: перевірте місце на диску (df -h), синхронізацію часу (timedatectl) і останні помилки (journalctl).
4. Підтвердіть узгодженість FSID між /etc/pve/ceph.conf і локальним відображенням сховища (ceph-mon --show_monmap).
5. Спочатку виправте мережеві розриви (порти 3300/6789). Якщо монітори не можуть спілкуватися — жодне відтворення не допоможе.
6. Запустіть один монітор чисто. Спостерігайте логи. Ви шукаєте поведінку «формування кворуму», а не просто «active (running)».
7. Підніміть другий монітор, щоб досягти більшості. Два MON з трьох — це кворум.
8. Як тільки кворум існує: відтворіть будь-які решта моніторів правильно з кворуму, замість того щоб намагатися воскресити пошкоджений стан.

Чеклист 3: Відтворення монітора коли кворум є (контрольована заміна)

Я навмисно не даю однокомандного «nuke and pave». Відтворення безпечне, коли ви робите його навмисно і перевіряєте кожен крок.

1. Підтвердіть кворум і здоров’я: ceph -s, ceph mon dump.
2. Зупиніть цільовий MON: systemctl stop ceph-mon@monX.
3. Відсуньте старе сховище: перейменуйте директорію mon замість видалення. Це дає важіль відкату.
4. Відтворіть моніторне сховище з поточних мап кластера за допомогою відповідних інструментів для вашої версії Ceph/Proxmox.
5. Запустіть MON і перевірте приєднання через ceph -s та ceph quorum_status.

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

Типові помилки: симптом → корінь → виправлення

1) Симптом: «mon down» після рутинного перезавантаження

Корінь: Директорія даних монітора відсутня/переміщена, змінилися права або вузол завантажився з іншим hostname/мапінгом ID, ніж очікувалося.

Виправлення: Переконайтеся, що /var/lib/ceph/mon/ceph-<id> існує і належить ceph:ceph. Підтвердіть, що ID монітора відповідає назві сервісу. Перезапустіть та перевірте слухачі портів.

2) Симптом: «out of quorum», але сервіс активний

Корінь: Мережевий розрив, фаєрвол блокує 3300/6789, невідповідність MTU або асиметрична маршрутизація між MON.

Виправлення: Тестуйте зв’язок MON→MON за допомогою nc -vz на 3300 і 6789. Перевірте комутацію/VLAN/MTU, потім правила фаєрволу. Не відтворюйте монітори через мережеву проблему.

3) Симптом: ceph-команди зависають або таймаутяться тільки з деяких вузлів

Корінь: Клієнтські вузли вказують на застарілі адреси моніторів у конфігу, або DNS повертає різні IP. Іноді це проблема з частково налаштованим dual-stack (IPv6).

Виправлення: Переконайтеся, що mon_host коректний у конфігу, який реально використовує вузол. Встановіть явні IP, якщо ваш DNS недисциплінований.

4) Симптом: монітори флапають кожні кілька хвилин

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

Виправлення: Перевірте timedatectl на MON. Перегляньте dmesg на помилки накопичувача. Шукайте CPU steal або IO wait. Виправляйте платформу, а не симптом.

5) Симптом: після «виправлення» монітор Ceph показує неправильний FSID або дивні помилки авторизації

Корінь: Змішування кластерів: застарілий /etc/ceph/ceph.conf, неправильний keyring або вузол перевстановлено й генерував інший кластерний конфіг.

Виправлення: Перевірте FSID у /etc/pve/ceph.conf та від ceph fsid — вони мають збігатися. Переконайтеся, що CLI використовує потрібний конфіг і keyring. Видаліть застарілі конфіги, що затіняють Proxmox-керовані.

6) Симптом: монітор не стартує, лог каже «No space left on device»

Корінь: Коренева файловая система повна (зазвичай логи, дампи або локальні бекапи).

Виправлення: Вивільніть місце безпечно. Потім перезапустіть. Якщо сховище монітора постраждало, запустіть перевірку консистентності, якщо доступна, і стежте за повторними помилками.

7) Симптом: MON запускається, але одразу виходить з помилками, пов’язаними зі сховищем

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

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

Три корпоративні міні-історії з трас моніторів

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

У них був акуратний тривузловий кластер Proxmox: три монітори, багато OSD і переконання, що «монітори легкі, тож можемо ставити їх куди завгодно». Один монітор жив на вузлі, де також працював гучний CI runner і система метрик, що писала, ніби за іноди платять.

Потрібно було оновлення ядра з перезавантаженням. Перезавантаження пройшло нормально. Але за десять хвилин стан Ceph пішов криво: один монітор down, інший «повільні операції», а третій — out of quorum. На чергуванні припустили, що це баг Ceph, бо «крім перезавантаження нічого не змінювалося». Це припущення витратило першу годину.

Реальність: перезавантаження запустило CI runner, який моментально почав насичувати диск на тому вузлі. Латентність комітів монітора підскочила, вибори таймаутувалися, і кворум став обертовими дверима. Нічого «не було не так» з Ceph. Платформа порушила потребу монітора в нудних, передбачуваних IO.

Виправлення не було екзотичним. Вони перемістили CI runner з хоста монітора, закріпили IO монітора на швидшому сховищі і додали алерти на використання кореневого файлового простору та затримки диска. Постмортем навчив простому висновку: монітори «легкі» лише якщо їх не ображати дисками.

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

Інша команда захотіла підвищити безпеку. Вони ввімкнули сувору політику фаєрволу в Proxmox і похвалилися, що «заблокували кластер». Це працювало в тому сенсі, що нічого явного не зламалося відразу. Монітори тримали кворум тижнями.

Потім мережеві роботи спричинили перезавантаження одного монітора. Коли він повернувся, він не зміг приєднатися до кворуму. Сервіс працював, логи виглядали ніби мережеві, і Ceph кричав про монітор, що вийшов з кворуму. Команда виконала стандартний план: перезапуск, реініціалізація, навіть переміщення директорії даних монітора. Все марно.

Оптимізація, що повернулася бумерангом, була тонкою: правила фаєрволу дозволяли встановлені з’єднання, але бракувало явних дозволів для портів моніторів у мережі Ceph. У спокійному стані все працювало, бо сесії вже були відкриті. Після перезавантаження монітору потрібно було встановити нові з’єднання — і він не міг. Кворум не впав миттєво; він впав, коли «оптимізація» зіткнулася зі зміною стану.

Підсумкове виправлення: явні, перевірені правила фаєрволу, що дозволяють трафік MON→MON на правильних інтерфейсах, плюс вимога при перегляді змін: «Якщо змінюєте фаєрвол, перевіряйте порти Ceph між моніторами». Вони зберегли безпеку, але перестали сподіватися на щасливе збереження сесій.

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

Ця команда зробила дещо дуже непрестижне: вони тримали невеликий файл «факти кластера» в приватному репозиторії. У ньому був Ceph FSID, ID моніторів, IP моніторів, призначені public/cluster мережі та місця директорій даних моніторів. Також були приклади нормального виводу ceph -s і який хост зазвичай є активним менеджером.

Коли хост монітора зазнав відмови сховища і застряг у перезавантаженні, черговий не мусив гадати, які монітори існують або які IP вони мають. Вони перевірили кворум, підтвердили ідентичність мертвого монітора і миттєво зрозуміли, що в них ще є більшість. Жодної драматичної ситуації. Вони поводилися як при заміні RAID-члена: ізолювати, замінити, повторно ввести.

Другий бонус: під час заміни вони уникнули найпоширенішої людської помилки — випадково використати старий ceph.conf з іншого середовища. Їхній файл факті включав FSID. Вони перевірили його перед початком. Він співпав. Вони продовжили.

Це не було героїчно. Це було нудно. І це врятувало їх від простої ситуації, де всі вивчають CLI Ceph, читаючи логи як чайні листи.

FAQ

1) Яку мінімальну кількість моніторів слід запускати?

Три. Завжди три для реальних кластерів. Один — це лабораторія. Два — поганий компроміс: ви не зможете витримати відмову без втрати кворуму.

2) Чому Ceph наполягає на непарній кількості моніторів?

Через більшістевий консенсус. З 3 ви можете втратити 1. З 5 — втратити 2. З 4 ви все одно можете втратити лише 1, тож ви додали складності без додаткової відмовостійкості.

3) Чи можна запускати монітори на тих самих вузлах, що й OSD?

Так, часто. Але тримайте сховище монітора передбачуваним: уникайте заповнення кореневих дисків, уникайте «галасливих сусідів» і не ставте MON на ненадійні споживчі SSD, а потім дивуйтеся.

4) «ceph -s» зависає. Чи означає це автоматично, що немає кворуму?

Не автоматично, але це сильний натяк. Це також може означати, що ваш вузол не може дістатися жодного монітора через фаєрвол/DNS/маршрутизацію. Тестуйте TCP 3300/6789 до кожного IP монітора з вузла, де зависає команда.

5) Чи безпечно видаляти директорію даних монітора, щоб «скинути» його?

Лише коли у вас є кворум і ви свідомо відтворюєте конкретний монітор. Навіть тоді відсуньте її спочатку. Видалення неправильного store під час відсутності кворуму — це рецепт довшого простою.

6) Як зрозуміти, чи це зсув часу чи мережеві проблеми?

Зсув часу дає специфічний тип хаосу: переривчасті вибори, «out of quorum» при загалом хорошій доступності і логи з приводу таймаутів, що здаються випадковими. Перевірте timedatectl на MON і виправте NTP/chrony спочатку. Мережеві проблеми проявляють себе чіткіше через невдалі перевірки портів і послідовні проблеми з досяжністю.

7) Чи змінює Proxmox спосіб відновлення моніторів Ceph?

Фундаменти ті самі. Proxmox дає зручні інструменти і зберігає конфіг Ceph у /etc/pve, що класно, поки ви випадково не почнете використовувати застарілий локальний /etc/ceph. Ваше відновлення все одно залежить від кворуму, мережі, часу і правильного стану monmap.

8) На що слід ставити алерти, щоб уникнути інцидентів з кворумом моніторів?

Використання диска на хостах моніторів (особливо кореневий), стан синхронізації часу, втрата пакетів/затримки між моніторами і здоров’я сервісів ceph-mon@*. Також алерти на «mon down» і «quorum changed» — це ранній дим.

9) Якщо я втратив два монітори в кластері з 3, чи можу я «примусово» зробити кворум з одного?

Іноді ви можете примусово змусити кластер у аварійному режимі залежно від версії і інструментів, але це небезпечно і сильно залежить від контексту. Операційно: відновіть другий монітор замість цього. Більшість існує, щоб не дозволяти вам підтвердити неправильну істину.

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

Тому що монітори повинні зберігати оновлення стану, щоб бути авторитетними. Якщо вони не можуть писати — вони не можуть безпечно брати участь. Це не крихкість Ceph; це відмова Ceph брехати.

Висновок і подальші кроки

«mon down/out of quorum» здається специфічною катастрофою Ceph, але більшість відновлень — це робота з платформою: виправте тиск на диск, синхронізацію часу, доступність мережі, а потім дайте моніторам робити свою роботу. Якщо кворум існує — ремонтуйте або відтворюйте монітор із відомо здорової більшості. Якщо кворуму немає — припиніть імпровізувати і зосередьтеся на відновленні більшості, використовуючи найбільш ціле сховище монітора.

Наступні кроки, які виправдовують витрати:

• Розмістіть вузли моніторів на надійному, передбачуваному сховищі і не дозволяйте заповнювати кореневі файлові системи.
• Стандартизуйте та перевіряйте правила фаєрволу для портів MON у мережі Ceph.
• Зробіть синхронізацію часу обов’язковою: налаштуйте алерти, коли будь-який монітор не синхронізований.
• Запишіть факти кластера (FSID, ID моніторів, IP, мережі). Це не гламурно. Це ефективно.