Proxmox Ceph: OSD недоступний — диск, мережа чи сервіс — швидка ідентифікація

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

Коли OSD переходить у down, ваше завдання не бути кмітливим. Ваше завдання — бути швидким, правильним і нудним. Почніть з питань, які найшвидше зменшують невизначеність.

Перший: вузол досяжний і час синхронізований?

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

Другий: процес OSD падає, чи він працює, але ізольований?

• Стан сервісу: Якщо systemd показує, що OSD зациклюється на крашах, ймовірно, проблема у диску/BlueStore/корупції/повідомленнях автентифікації. Якщо сервіс «active (running)», але кластер відображає його як down — підозрюйте мережу, фаєрвол або неправильне прив’язування IP.
• Погляд Ceph: Порівняйте ceph osd tree зі статусом systemd. Несумісності — діагностичне золото.

Третій: чи достатньо диск здоровий для обробки журналу/BlueStore IO?

• Ядрові логи: Один погляд на dmesg і journalctl часто показує, чи диск видає помилки або таймаути.
• SMART і таймаути IO: Якщо бачите ресети, таймаути або перерахування секторів SMART, припиняйте перезапуски демонів і починайте планувати заміну.

Умови зупинки (уникайте погіршення)

• Якщо декілька OSD впали на різних хостах: розглядайте це як проблему мережі або кластера, поки не доведено інше.
• Якщо на одному хості одночасно пропало багато OSD: підозрюйте HBA/баєкплейн/БП або мережу цього хоста.
• Якщо OSD флапає: вважайте це за переривчасті IO-стали або втрату пакетів, а не «Ceph дивний». Ceph детермінований; ваше залізо — ні.

Практична ментальна модель: що насправді означає «OSD down»

Ceph має два різні «погляди» на OSD:

• Що думає хост: systemd запускає ceph-osd@ID, процес працює, може читати своє сховище, прив’язується до IP і може з’єднатися з моніторами.
• Що думає кластер: монітори відстежують heartbeat OSD. Якщо монітори не отримують їх вчасно, OSD позначається як down. Окремо OSD може бути out (виключений з розміщення даних), навіть якщо він up.

Отже, «OSD down» не означає за визначенням «диск помер». Це означає «кластер не може надійно почути цей OSD». Це може бути:

• Диск/IO: процес OSD зависає або крашиться, бо читання/записи у BlueStore блокуються через таймаути блочного пристрою.
• Мережа: локально OSD здоровий, але не може дістатися до моніторів або пірів (маршрутизація, VLAN, MTU, bonding, комутатор, фаєрвол).
• Сервіс/конфіг: OSD не стартує, не може аутентифікуватися (cephx), прив’язується до неправильної адреси або має розбіжність версій/конфігу.

Вам потрібен мінімальний набір перевірок, які на ранньому етапі розділять ці категорії. Усе інше — деталі.

Парафразована ідея (Gene Kim, автор з надійності/операцій): «Покращення відбувається, коли ви скорочуєте й стабілізуєте зворотні петлі». Ось що таке цей план: короткі петлі.

Цікаві факти та контекст (реальність Ceph + Proxmox)

1. Логіка «heartbeat» OSD у Ceph зорієнтована на монітори. Ваш OSD може бути зайнятий, живий і все одно визнаний down, якщо heartbeats не доходять вчасно.
2. «Down» і «out» — різні важелі. down — це виявлення здоров’я; out — це розміщення даних. Плутання їх викликає самостійні штормі ребалансингу.
3. BlueStore замінив FileStore, бо подвійний запис FileStore і накладні витрати файлової системи не витримували сучасних дисків і очікувань по латентності.
4. Алгоритм CRUSH Ceph походить із досліджень про контрольовані домени відмов. Саме тому ви можете пережити втрату хостів або стійок за умови чесної топології.
5. Proxmox інтегрував керування Ceph, щоб зробити гіперконвергентне сховище доступнішим, але це також полегшує випадкові помилки, якщо ви не розумієте поведінки демонів.
6. Помилки мережі маскуються під помилки диска. Втрата пакетів може виглядати як «повільні операції» та таймаути. Поганий порт комутатора зіпсував більше вихідних днів, ніж баги прошивки.
7. Флапінг OSD зазвичай не програмна випадковість. Часто це енергозбереження, термальне заглушення, проблеми HBA або нестабільні лінки — речі, що «працюють більшість часу», поки навантаження не зросте.
8. Відновлення Ceph може підсилити проблеми. Коли OSD падає, backfill/recovery збільшує IO та мережевий трафік, що може довести маргінальні компоненти до межі.

Жарт #1: Розподілене сховище — це просто однокористувацьке сховище плюс мережа, плюс консенсус, плюс шанс помилитися в трьох місцях одночасно.

Завдання триажу: команди, виводи, рішення (12+)

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

Завдання 1: Підтвердіть, що кластер бачить OSD як down і який саме

cr0x@pve1:~$ ceph -s
  cluster:
    id:     7c2a0d3e-0f8a-4e5a-9a5b-5e9b0c7d3c12
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12 pgs undersized
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 6h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 12 osds: 11 up (since 4m), 12 in (since 6h)
  data:
    pools:   4 pools, 128 pgs
    objects: 2.1M objects, 8.3 TiB
    usage:   25 TiB used, 40 TiB / 65 TiB avail
    pgs:     12 undersized+degraded

Значення: Це реальна ситуація: кластер попереджає про хоча б один OSD down, і PGs під впливом.

Рішення: Негайно визначте, який(і) OSD і на яких хостах. Не перезапускайте служби навмання.

Завдання 2: Відобразіть ID OSD на хост і розташування пристрою

cr0x@pve1:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         65.00000 root default
-3         21.66667     host pve1
 0   hdd    3.61111         osd.0      up   1.00000  1.00000
 1   hdd    3.61111         osd.1      up   1.00000  1.00000
 2   hdd    3.61111         osd.2    down   1.00000  1.00000
-5         21.66667     host pve2
 3   hdd    3.61111         osd.3      up   1.00000  1.00000
...

Значення: osd.2 down на pve1.

Рішення: Перейдіть на конкретний хост і перевірте демон OSD + диск.

Завдання 3: Перевірте, чи сервіс OSD запущений (розділення сервіс/мережа)

cr0x@pve1:~$ systemctl status ceph-osd@2 --no-pager
● ceph-osd@2.service - Ceph object storage daemon osd.2
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 08:51:22 UTC; 2min 10s ago
    Process: 18342 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 2 (code=exited, status=1/FAILURE)
   Main PID: 18342 (code=exited, status=1/FAILURE)

Dec 26 08:51:22 pve1 ceph-osd[18342]: bluestore(/var/lib/ceph/osd/ceph-2) _read_bdev_label failed: (5) Input/output error
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Failed with result 'exit-code'.

Значення: Не запущено; лог кричить про IO error при читанні BlueStore label. Зазвичай це проблема шляху до диска, а не мережі.

Рішення: Припиніть перезапуски; перевірте диск/HBA і журнали ядра. Підготуйтеся до заміни.

Завдання 4: Якщо сервіс працює, перевірте, чи Ceph усе ж вважає його down (підозра на мережу)

cr0x@pve1:~$ systemctl is-active ceph-osd@2
active

Значення: Локально активний. Якщо ceph osd tree все ще показує його як down, часто це мережа, автентифікація або прив’язка адреси.

Рішення: Перевірте підключення до моніторів і адреси, до яких прив’язаний OSD.

Завдання 5: Швидко візьміть логи конкретного OSD

cr0x@pve1:~$ journalctl -u ceph-osd@2 -n 80 --no-pager
Dec 26 08:49:10 pve1 ceph-osd[18011]: starting osd.2 at /var/lib/ceph/osd/ceph-2
Dec 26 08:49:11 pve1 ceph-osd[18011]: bluestore: using bdev /dev/ceph-2/block
Dec 26 08:49:15 pve1 ceph-osd[18011]: heartbeat_map is_healthy_to_peer osd.7 down
Dec 26 08:49:22 pve1 ceph-osd[18011]: slow ops, oldest one is now 31.122s
Dec 26 08:49:29 pve1 ceph-osd[18011]: monclient(hunting): authenticate timed out
Dec 26 08:49:31 pve1 ceph-osd[18011]: unable to talk to monitor
Dec 26 08:49:35 pve1 ceph-osd[18011]: dropped 3 slow requests due to timeout

Значення: Повільні операції, потім таймаути автентифікації монітора. Це може бути і диск, і мережа. «unable to talk to monitor» схиляє до мережі, але не робіть поспішних висновків.

Рішення: Перевірте журнали ядра на наявність IO таймаутів або проблем лінку. Одне з них зазвичай визнається винуватцем.

Завдання 6: Перевірте кільце ядра на ресети/таймаути диска (підказка про диск)

cr0x@pve1:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|timed out|nvme|sd '
[Fri Dec 26 08:48:58 2025] sd 6:0:12:0: [sdl] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[Fri Dec 26 08:48:58 2025] blk_update_request: I/O error, dev sdl, sector 182400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 08:48:59 2025] sd 6:0:12:0: [sdl] rejecting I/O to offline device
[Fri Dec 26 08:49:02 2025] ata12: hard resetting link
[Fri Dec 26 08:49:07 2025] ata12: link is slow to respond, please be patient

Значення: Це диск або шлях до нього поводиться неналежним чином (диск, кабель, backplane, HBA). Ceph лише повідомляє про проблему.

Рішення: Обробляйте як інцидент обладнання: припиніть флапінг, відмітьте out при потребі і плануйте заміну/обслуговування.

Завдання 7: Перевірте мережевий лінк, помилки та скидки пакетів (підказка про мережу)

cr0x@pve1:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    981G  744M      0   18422       0  11922
    TX:  bytes packets errors dropped carrier collsns
    904G  701M      0       0       0      0      0

Значення: RX-пакети відкидаються на рівні bond. Для мережі зберігання відкиди — це сплески латентності в маскувальному плащі.

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

Завдання 8: Перевірте узгодженість MTU (класична пастка Proxmox/Ceph)

cr0x@pve1:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

cr0x@pve2:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Значення: Несумісність MTU. Джамбо-кадри з одного боку і стандартні з іншого — класичний шлях до «випадкових» таймаутів.

Рішення: Виправте MTU кінця в кінець (хости, bond-и, брижі, порти комутатора). Потім повторно оцініть стан OSD.

Завдання 9: Підтвердіть підключення до моніторів з ураженого вузла (мережа vs автентифікація)

cr0x@pve1:~$ ceph quorum_status --format json-pretty | sed -n '1,40p'
{
  "election_epoch": 88,
  "quorum": [
    0,
    1,
    2
  ],
  "quorum_names": [
    "pve1",
    "pve2",
    "pve3"
  ],
  "quorum_leader_name": "pve1"
}

Значення: З цього вузла CLI може говорити з моніторами. Це не гарантує, що OSD може, але зменшує ймовірність повної мережевої ізоляції.

Рішення: Якщо OSD не може аутентифікуватися, але CLI може, підозрюйте cephx keyring/дозволи або те, що OSD прив’язаний до неправильного інтерфейсу.

Завдання 10: Перевірте, які IP Ceph вважає правильними для прив’язки (помилки прив’язки)

cr0x@pve1:~$ ceph config get osd public_network
10.10.10.0/24

cr0x@pve2:~$ ceph config get osd cluster_network
10.10.20.0/24

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

Рішення: Перевірте IP-адресацію хоста і що обидві мережі присутні й маршрутизуються правильно на цьому вузлі.

Завдання 11: Перевірте, яку адресу OSD рекламуює

cr0x@pve1:~$ ceph osd find 2
{
  "osd": 2,
  "ip": "10.10.10.11:6806/12345",
  "crush_location": {
    "host": "pve1",
    "root": "default"
  }
}

Значення: OSD рекламує 10.10.10.11. Якщо ця IP-адреса неправильна, переміщена або тепер належить іншому інтерфейсу/VLAN, пірі не зможуть її досягти.

Рішення: Якщо це не відповідає очікуваній мережевій конфігурації, виправте адресацію і чисто перезапустіть OSD. Не виводьте out, якщо лише ризики даних цього не вимагають.

Завдання 12: Перевірте деталі здоров’я Ceph для явних підказок

cr0x@pve1:~$ ceph health detail
HEALTH_WARN 1 osds down; Degraded data redundancy: 12 pgs undersized
[WRN] OSD_DOWN: 1 osds down
    osd.2 is down
[WRN] PG_DEGRADED: Degraded data redundancy: 12 pgs undersized
    pg 1.2c is undersized+degraded, acting [7,2]
    pg 1.2f is undersized+degraded, acting [2,9]

Значення: Кластер повідомляє «мій osd.2 відсутній». Він не каже, чому, але показує вплив і терміновість.

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

Завдання 13: Перевірте відображення блочного пристрою для цього OSD (точність шляху до диска)

cr0x@pve1:~$ ceph-volume lvm list --osd-id 2
====== osd.2 =======
[block]       /dev/ceph-2/block
  type        block
  lv_path     /dev/ceph-2/osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  vg_name     ceph-2
  lv_name     osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  devices     /dev/sdl

Значення: OSD залежить від /dev/sdl. Тепер можна перевірити SMART, контролер, кабелі і чи присутній /dev/sdl.

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

Завдання 14: Швидка перевірка присутності пристрою та латентності

cr0x@pve1:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,STATE,ROTA,TYPE,MOUNTPOINT | egrep 'sdl|ceph-2|NAME'
NAME          SIZE MODEL            SERIAL        STATE ROTA TYPE MOUNTPOINT
sdl         3.6T  ST4000NM000A     ZC1ABC12      running    1 disk
ceph--2-osd--block--3c6f8a1d 3.6T                          1 lvm

Значення: Пристрій присутній. Присутність — це не те саме, що здоров’я, але це краще, ніж «зник».

Рішення: Якщо сервіс падає з IO-помилками незважаючи на присутність, запустіть SMART і перевірте ресети шляху.

Завдання 15: Перевірка SMART (не переінтерпретуйте, але поважайте її)

cr0x@pve1:~$ smartctl -a /dev/sdl | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       39876
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       3200
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       88
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       88

Значення: Диск фактично повідомляє, що йде у відмову. Повірте йому.

Рішення: Замініть диск. Не витрачайте час на налаштування Ceph для обладнання, що відмовляє.

Завдання 16: Якщо підозрюєте втрату мережі, тестуйте втрати й MTU правильно (не тільки ping)

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
From 10.10.10.11 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.10.10.11 icmp_seq=2 Frag needed and DF set (mtu = 1500)
--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4081ms

Значення: На шляху є MTU 1500. Джамбо не проходить кінця в кінець.

Рішення: Виправте конфігурацію MTU перед тим, як звинувачувати Ceph. Потім перезапустіть уражений OSD, якщо він правильно прив’язаний.

Завдання 17: Якщо сервіс падає, швидко перевірте BlueStore і права файлової системи

cr0x@pve1:~$ ls -ld /var/lib/ceph/osd/ceph-2
drwxr-x--- 5 ceph ceph 4096 Dec 26 08:40 /var/lib/ceph/osd/ceph-2

Значення: Власність виглядає нормально. Якщо вона неправильна (root:root або занадто обмежувальна), OSD може падати рано.

Рішення: Виправляйте права тільки якщо можете пояснити, чому вони змінилися (скрипти пакета, ручні правки, відновлення). Інакше ризикуєте замаскувати глибшу проблему.

Завдання 18: Перевірте звіти про краш Ceph для цього демона (часто недооцінюються, дуже повчальні)

cr0x@pve1:~$ ceph crash ls | head
ID                                      ENTITY    NEW
2025-12-26_08:51:22.18342               osd.2     *
2025-12-20_14:11:03.22991               osd.7

cr0x@pve1:~$ ceph crash info 2025-12-26_08:51:22.18342 | sed -n '1,60p'
{
  "crash_id": "2025-12-26_08:51:22.18342",
  "entity_name": "osd.2",
  "utsname_hostname": "pve1",
  "assert_condition": "bdev_label_valid",
  "backtrace": [
    "ceph-osd(...",
    "libc.so.6(..."
  ]
}

Значення: Краш зафіксовано й вказує на проблему з міткою/читанням блочного пристрою BlueStore. Це підсилює гіпотезу «шлях диска / IO».

Рішення: Не вважайте, що «перезапуск виправить це». Плануйте заміну обладнання або ремонт BlueStore лише якщо ви впевнені і маєте резерви.

Диск vs мережа vs сервіс: ознаки для розрізнення

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

Показники проблем диска/IO

• OSD не запускається з помилками BlueStore, «Input/output error» або «failed to read bdev label».
• Журнали ядра показують ресети/таймаути на базовому пристрої (SATA link reset, NVMe timeout, SCSI “rejecting I/O”).
• SMART показує pending/reallocated сектори або загальний стан SMART FAIL.
• OSD флапає під навантаженням (відновлення/backfill це триггер). Маргінальні диски падають під реальним навантаженням.

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

Показники проблем мережі

• Процес OSD працює, але Ceph позначає його down; логи показують «unable to talk to monitor» або heartbeat таймаути.
• Декілька OSD впали на різних хостах одночасно.
• Відкиди/помилки пакетів на інтерфейсах для зберігання; лічильники комутатора зростають; bond флапає.
• MTU mismatch (джамбо частково ввімкнено) викликає фрагментацію або мовчазні відкиди при DF.
• Асиметрична маршрутизація (public працює, cluster — ні) призводить до часткової підключеності.

Практичне рішення: Виправте втрату пакетів перед «налаштуванням Ceph». Ceph не може налаштувати фізику.

Показники проблем сервісу/конфігурації

• systemd показує exit-code помилки без IO-помилок ядра (наприклад: автентифікація, конфіг, права, відсутній keyring).
• Помилки cephx в логах OSD: «permission denied», «bad key», «authenticate timed out» (може бути й мережа, тож перевіряйте).
• OSD прив’язується до неправильної адреси після перейменування інтерфейсу, зміни bridge або мережевої рефакторизації.
• Різниця версій або дрейф конфігурації після часткових оновлень (поширено під час корпоративних вікон змін).

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

Поглиблені розділи: швидкі шляхи в кожному режимі відмови

1) Збої шляху диска: симптом «OSD down» — останній доміно

OSD Ceph дуже добре терплять тимчасову повільність — до того моменту, поки не перестають. Коли IO-стали перевищують допустимі heartbeat, монітори вважають OSD down. Іноді процес OSD ще живий, заблокований в IO, видаючи вигляд «працює». Саме тому не зупиняйтеся на статусі systemd.

Збої шляху диска бувають різних видів:

• Відмова носія: перераховані/очікувані сектори, некориговані помилки, повторні читання, проблеми з термальністю.
• Транспортна відмова: поганий SATA/SAS-кабель, маргінальний backplane, баги прошивки HBA, проблеми експандера.
• Проблеми живлення: спільна лінія БП або живлення backplane, що викликає ресети під навантаженням.
• Колапс черги: диск, який «працює», але має катастрофічні сплески латентності (вбивця для розподіленого зберігання).

Що робити, коли ви впевнені в проблемі шляху диска:

• Зберіть докази (dmesg, SMART, логи OSD) один раз.
• Припиніть флапінг. Флапінг підвищує churn відновлення, що підвищує навантаження й посилює флапінг.
• Вирішіть: тримати in тимчасово, якщо OSD швидко повернеться і ви хочете уникнути ребалансингу, або маркувати out, якщо він справді помер або небезпечний.

Рекомендація: Якщо ви бачите повторювані IO таймаути/ресети більш ніж кілька хвилин — маркуйте OSD out і плануйте заміну. Якщо ви тримаєте його in, «подивитися, чи заспокоїться» — ви граєте в азартну гру з кластера.

2) Мережеві збої: Ceph — це детектор латентності, що також зберігає дані

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

Мережеві збої, що зазвичай виглядають як OSD down:

• Невідповідність MTU між vmbr/bond, портами комутатора або VLAN інтерфейсами.
• Неправильна конфігурація bonding (LACP на хості, статичне на комутаторі або навпаки), що викликає інтермітентні хеш-«чорні діри».
• Невідповідності тегування VLAN після змін на комутаторі.
• Правила фаєрволу, що блокують порти messenger Ceph (типово 6800–7300) або порти моніторів.
• Переповнення і мікросплески під час recovery/backfill.

Швидкий спосіб відокремити «мережу» від «дискового стагу», коли логи показують таймаути: дивіться журнали ядра. Дискові стаги часто показують повідомлення про пристрій. Мережеві проблеми зазвичай показують відкиди пакетів, флапи лінків, повідомлення bonding або взагалі нічого у журналі, тоді як Ceph скаржиться. У такому «нічого» випадку перевіряйте лічильники інтерфейсів і логи комутатора.

3) Сервісні/конфігураційні збої: тонкі випадки

Проблеми сервісу — це там, де люди найчастіше роблять шкоду, бо вони впевнені. Диск існує, мережа відповідає, отже OSD «повинен» стартувати. Але Ceph — це не один бінарник; це набір ідентичностей, keyring-ів, конфігів і відображень пристроїв. Зламайте одну з частин — отримаєте OSD, який ввічливо відмовляється працювати.

Поширені тригери сервісу/конфігу:

• Відсутній або неправильний keyring у /var/lib/ceph/osd/ceph-ID/keyring.
• Права директорії OSD змінилися під час ручного ремонту або відновлення.
• Застарілий символічний лінк пристрою, якщо udev змінив імена і OSD вказує на відсутній шлях.
• Часткові оновлення, що викликають несумісність messenger/protocol або припущення конфига.

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

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

Три міні-історії з корпоративного життя (що пішло не так, що спрацювало)

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

У невеликому кластері Proxmox з Ceph для дисків ВМ один OSD впав після планового перезавантаження. На чергового подивилися ceph -s, побачили «1 osd down» і вирішили, що диск помер. Розумно… якщо ви любите помилково ставити діагнози ефективно.

Команда одразу відмітила OSD out, щоб «почати відновлення». Це запустило backfill по кластеру. Мережеве завантаження виросло. Латентність зросла разом із цим. Потім ще два OSD почали флапати на інших вузлах. Дашборд перетворився на різдвяну ялинку, а клієнтські операції стали періодично зависати.

Корінь проблеми не був у дисках. Перезавантаження змінило імена інтерфейсів на тому хості після оновлення ядра, а налаштування Ceph public network все ще вказувало на старий бридж. OSD стартував, прив’язався до неправильної адреси і став недоступним для пірів. «Відмова диска» — це історія, яку люди розповіли собі, бо вона підходила під симптом.

Після виправлення прив’язки інтерфейсу і перезапуску OSD він миттєво повернувся. Але шкода вже була завдана: кластер уже інтенсивно ребалансив. Вони перетворили проблему ідентичності OSD в багатохостовий інцидент з продуктивністю.

Що змінило їхню поведінку після цього — правило: ніколи не маркуйте OSD out, поки не перевірили шлях диска або не підтвердили стійку мережеву ізоляцію. Це сповільнило їх на п’ять хвилин і зекономило години пізніше.

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

Інша команда хотіла «більше продуктивності» і «менше накладних витрат». Вони включили джамбо-фрейми на мережі зберігання. Добре з точки зору інтенції. Вони оновили бриджі і bond-и Proxmox до MTU 9000, оновили пару ToR портів і протестували базовим ping’ом, після чого оголосили перемогу.

Через тижні, під час важкого recovery (планова заміна OSD), OSD почали випадати. Повільні операції накопичувалися. На чергового у журналах з’явилися таймаути автентифікації моніторів, і він підозрював cephx. Ключі міняли. Демони перезапускали. Навіть монітор перезавантажили. Все пішло гірше.

Винуватцем виявився банальний проміжний порт комутатора з MTU 1500 на одному тракті VLAN. Більшість трафіку «працювала», бо падала назад до менших пакетів, але під навантаженням специфічні шаблони messenger Ceph почали підпадати під проблеми фрагментації. Початковий тест ping не використовував DF + великий корисний, тож латентна помилка спрацювала лише під навантаженням.

Після виправлення MTU кінця в кінець і стандартизації валідації (DF ping, лічильники інтерфейсів, перевірка портів комутатора) флапінг припинився. Продуктивність теж покращилася, але головне — передбачуваність.

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

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

Одна організація запускала Ceph на Proxmox з суворою процедурою змін, яку всі висміювали, поки вона не знадобилася. Кожен диск OSD мав записану карту: місце в шасі → серійний номер → Linux-путь пристрою → ID OSD. Вони також тримали невеликий запас ідентичних дисків і мали випробуваний runbook заміни.

Коли OSD впав о 14:00 у вівторок (найприємніший інцидент), черговий не вгадав. Він виконав ceph osd tree, зіставив ID OSD зі серійним номером через інвентар, потім підтвердив через ceph-volume lvm list і smartctl. SMART показав pending сектори, а журнали ядра — ресети. Ніякої драматургії.

Вони відмітили OSD out після підтвердження реальної відмови, встановили прапори відновлення, щоб не наситити клієнтський IO, і замінили диск у правильній касеті з першої спроби. Новий OSD піднявся, відбув backfill, і кластер повернувся до чистого стану без жодного «де цей диск?» зібрання.

Ніяких героїчних вчинків. Жодних езотеричних команд Ceph. Просто точний інвентар і runbook, який уже випробували до того, як він знадобився.

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

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

1) «OSD down, отже диск помер»

Симптом: ceph -s показує 1 OSD down; адміністратори одразу планують заміну диска.

Корінь: OSD працює, але недоступний через MTU mismatch, VLAN або неправильну прив’язку адреси.

Виправлення: Порівняйте systemctl is-active ceph-osd@ID з ceph osd tree. Якщо локально активний, але кластер бачить down — протестуйте MTU DF ping’ом, перевірте відкиди інтерфейсів і підтвердьте рекламу адресу OSD через ceph osd find.

2) «Перезапуск OSD це виправить» (підсилювач флапінгу)

Симптом: OSD чергується up/down кожні кілька хвилин; перезапуск тимчасово допомагає.

Корінь: IO стаги або ресети лінку під навантаженням; перезапуск лише скидає таймери і ховає проблему до наступного навантаження.

Виправлення: Перевірте dmesg на ресети/таймаути; перевірте SMART. Якщо є ознаки апаратної проблеми — припиніть перезапуски і плануйте заміну. Якщо є ознаки мережі — виправте мережу перш за все.

3) Маркування OSD out занадто рано

Симптом: Один OSD down; оператор одразу відмічає його out; продуктивність кластера падає.

Корінь: Ребалансинг/backfill починається, тоді як базова проблема була транзитною або виправною (наприклад, неправильна прив’язка сервісу). Трафік відновлення перевантажує кластер і спричиняє додаткові таймаути.

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

4) Джамбо-кадри ввімкнено наполовину

Симптом: Випадкові OSD down під час відновлення; ping працює; TCP сесії скидаються під навантаженням.

Корінь: Несумісність MTU через bridges, bonds, VLAN або trunks.

Виправлення: Стандартизувати MTU кінця в кінець. Валідовуйте з ping -M do -s 8972 між усіма вузлами Ceph у відповідних мережах. Перевірте конфіг комутаторів також.

5) Ігнорування диска, що «переважно працює», але має піки латентності

Симптом: SMART не показує FAIL, але часто бувають slow ops і час від часу OSD down.

Корінь: Диск/HBA/backplane викликають інтермітентні довгі хвости латентності без явної відмови. Ceph карає за хвости латентності.

Виправлення: Використовуйте журнали ядра й логи OSD для кореляції. Розгляньте заміну підозрілого компонента навіть без драматичного SMART звіту.

6) Зміни фаєрволу або ACL блокують порти Ceph

Симптом: OSD стартує, але не може підключитися до моніторів; логи показують таймаути; проблема почалася після «посилення безпеки».

Корінь: Заблоковані порти моніторів/OSD messenger або асиметричні правила між вузлами.

Виправлення: Перевірте досяжність потрібних портів з вузла OSD до моніторів і пірів. Відкрутіть або виправте правила. Узгодженість важливіша за кмітливість.

Контрольні списки / покроковий план

Контрольний список A: П’ятихвилинний триаж «що це?»

1. Запустіть ceph -s і ceph osd tree. Визначте ID OSD і хости.
2. На хості: systemctl status ceph-osd@ID і journalctl -u ceph-osd@ID -n 80.
3. На хості: dmesg -T | egrep -i 'I/O error|timed out|reset|rejecting I/O'.
4. На хості: ip -s link на інтерфейсах Ceph; шукайте відкиди/помилки.
5. Підтвердіть MTU DF ping’ом між IP зберігання, якщо джамбо увімкнено.

Контрольний список B: Якщо схоже на диск/IO

1. Підтвердьте мапінг: ceph-volume lvm list --osd-id ID.
2. Перевірте SMART: smartctl -a /dev/DEVICE.
3. Перевірте помилки ядра і ресети: dmesg -T.
4. Якщо підтверджено відмову: плануйте заміну. Якщо сильне флапання — маркуйте out для стабілізації розміщення.
5. Обмежте відновлення, якщо клієнтський IO важливий (узгодьте з командою).

Контрольний список C: Якщо схоже на мережу

1. Перевірте лічильники інтерфейсів (відкиди/помилки) і стан лінку.
2. Підтвердіть MTU кінця в кінець DF ping’ом.
3. Перевірте стан bond і узгодженість LACP; перевірте, чи slave-и не флапають.
4. Підтвердіть рекламовану IP OSD: ceph osd find ID.
5. Виправте мережу спочатку, потім перезапустіть OSD один раз, а не десять.

Контрольний список D: Якщо схоже на сервіс/конфіг

1. Перевірте systemd і логи на помилки cephx/конфіг.
2. Підтвердіть права й наявність keyring у директорії OSD.
3. Підтвердіть, що конфіг Ceph мережі відповідає реальним інтерфейсам і маршрутам.
4. Перевірте нещодавні оновлення й можливий дрейф версій між вузлами.
5. Вносьте одну зміну за раз, документуйте та відкочуйте, якщо симптом змінюється, але не покращується.

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

1) У чому різниця між тим, що OSD «down» і «out»?

Down — це виявлення здоров’я (монітори не отримують heartbeats). Out змінює розміщення CRUSH, тож кластер перестає зберігати дані там і починає відновлення кудись іще.

2) Сервіс OSD «active (running)», але Ceph каже, що він down. Чому?

Процес може бути живий, але недоступний: неправильна прив’язка IP, мережева ізоляція, правила фаєрволу, MTU mismatch або сильна втрата пакетів. Перевірте рекламовану IP (ceph osd find) і відкиди інтерфейсу.

3) Чи варто перезапускати сервіс OSD при його падінні?

Тільки після перевірки journalctl і dmesg. Якщо журнали ядра показують IO таймаути/ресети, перезапуск лише зробить простій гучнішим. Відремонтуйте обладнання спочатку.

4) Коли маркувати OSD out?

Коли є докази, що він не повернеться швидко (апаратна відмова, стійка мережева ізоляція) і тримання його in викликає нестабільність. Маркування out запускає відновлення, тож робіть це обдумано.

5) Чи може один поганий диск вивести з ладу кілька OSD?

Так, якщо кілька OSD діляться HBA, експандером, backplane або якщо один хост має системні IO-проблеми. Також так, якщо ви неправильно змоделювали домен відмов.

6) Чому OSD частіше падають під час recovery/backfill?

Відновлення збільшує глибину IO і мережевий трафік. Маргінальні диски, HBA, кабелі або порти комутаторів, які «працюють в штатному режимі», можуть зламатися під реальним навантаженням.

7) Чи достатньо SMART, щоб оголосити диск здоровим або мертвим?

SMART корисний, але не всесильний. SMART FAIL вирішальний. Пройшовший SMART не гарантує відсутності проблем, особливо з піками латентності і проблемами шляху контролера.

8) Як відрізнити MTU mismatch від загальної втрати пакетів?

MTU mismatch проявляється при DF ping’ах з великим payload і повідомленням «Frag needed and DF set». Загальна втрата пакетів показує зростання відкидів/помилок і непослідовну втрату ping навіть для малих пакетів.

9) У нас є окремі public і cluster мережі. Яка з них має значення для OSD down?

Обидві можуть бути важливі. OSD звертаються до моніторів по public network, а для реплікації/backfill часто використовують cluster network. Відмова будь-якої з них може викликати down залежно від конфігурації й шаблонів трафіку.

10) Який найбезпечніший спосіб зібрати докази перед змінами?

Зберіть: ceph -s, ceph health detail, ceph osd tree, systemctl status ceph-osd@ID, journalctl -u ceph-osd@ID і dmesg -T. Цього зазвичай достатньо, щоб визначити категорію.

Наступні кроки, які варто виконати

Якщо хочете менше сюрпризів «OSD down», зробіть нудну, але необхідну роботу:

1. Стандартизуйте швидкий триаж: зробіть наведений вище план вашою м’язовою пам’яттю за замовчуванням. Послідовність важливіша за геніальність.
2. Зміцніть мережеві припущення: перевірте MTU кінця в кінець, моніторьте відкиди і ставтесь до VLAN зі сховищем як до критичного продакшну (бо це так і є).
3. Інвентаризуйте диски серйозно: зіставлення ID OSD з серією та шухлядою. Час вчитися, який диск де, не під час простимою.
4. Зменште стимули до флапінгу: припиніть сліпі перезапуски. Збирайте докази, вирішуйте диск vs мережа vs сервіс, а потім дійте раз.
5. Практикуйте заміну OSD коли нічого не горить. Runbook, який ви застосовували спокійно, — це той самий runbook, який ви застосуєте правильно під тиском.

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