Повільні операції Ceph у Proxmox: знайти вузьке місце (диск, мережа або CPU)

October 14, 2025 • February 3, 2026 • Читання: 7 хв • Views: 9

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

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

Хитрість — припинити гадати. Кластер Ceph — це конвеєр: IO клієнта → мережа → черга OSD → диск → реплікація/еррейз-код → підтвердження.
«Повільні операції» стаються там, де цей конвеєр забивається. Ваше завдання — знайти який етап і усунути обмеження, а не блукати по налаштуваннях у темряві.

Що насправді означає «повільні операції» в Ceph (і чому Proxmox це показує)

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

Важливо: Ceph повідомляє про повільні операції з точки зору демонa, який чекає.
Якщо OSD чекає диска — воно повідомить про повільні операції. Якщо чекає підтверджень по мережі — теж повідомить.
Якщо заблоковано CPU і роботу не може запланувати, воно теж повідомить. Симптом загальний; причина — ні.

Proxmox показує ці попередження, бо інтегрує перевірки здоров’я Ceph у UI та логи кластеру. Це корисно… і небезпечно.
Корисно, бо ви помічаєте проблему рано. Небезпечно, бо багато адміністраторів починають вважати це проблемою Proxmox. Це не так. Proxmox — пасажир.
Ceph — літак. Якщо пахне димом — не звинувачуйте ремінь безпеки.

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

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

Перший: підтвердьте, що це реальна проблема, а не шум

Перевірте стан кластера і де повідомляються повільні операції. Вони на одному OSD, на одному хості чи повсюдно?
Перевірте затримки, які бачать клієнти. Якщо затримка IO ВМ стабільна і користувачі не скаржаться, можливо, ви бачите транзитний шум від відновлення.
Перевірте, чи інтенсивно працює відновлення/backfill/scrub. Багато подій «slow ops» спричинені самовикликаним навантаженням через налаштування відновлення.

Другий: визначте клас вузького місця (диск vs мережа vs CPU)

Дискове вузьке місце зазвичай виглядає так: висока commit/apply затримка OSD, висока завантаженість пристрою, довгі затримки NVMe/SATA, зупинки BlueStore, конкуренція WAL/DB.
Мережеве вузьке місце зазвичай виглядає так: підвищений msgr RTT, втрата пакетів, повторні передачі, нерівномірна затримка між вузлами, завантажені комутатори, невідповідний MTU, одна NIC завантажена під зав’язку.
CPU-вузьке місце зазвичай виглядає так: потоки OSD runnable, високий system time/softirq, сплески ksoftirqd, дисбаланс IRQ, багато переключень контексту, ceph-osd близький до 100%.

Третій: звузьте область впливу, потім зупиніть кровотечу

Область впливу: один OSD? один вузол? один стояк? один пул? один клієнт? Якщо повсюдно — підозрюйте ядро мережі або глобальний тиск відновлення.
Зупинити кровотечу: обмежте recovery/backfill, призупиніть scrubs у робочий час, перемістіть «гарячі» ВМ, тимчасово зменшіть паралелізм клієнтських IO.
Виправлення: замініть диски, виправте MTU, збалансуйте IRQ, розділіть public/cluster мережі, перемістіть BlueStore DB/WAL на швидші пристрої, адекватно налаштуйте recovery.

Жарт №1: Повільні операції Ceph — як затори: додавання більше машин (клієнтів) не зробить дорогу ширшою, воно просто покращить ваш словник помилок у дашборді.

Цікаві факти та контекст (коротко, конкретно, корисно)

Проєкт Ceph прагнув «відсутності єдиної точки відмови», але прошивка NIC, буфери комутатора або поганий SSD все одно можуть створити реальну єдину точку болю.
Термін «OSD» походить від object storage device, але на практиці OSD — це процес з чергами, потоками та поведінкою затримок, що часто важливіше за сиру швидкість диска.
BlueStore замінив FileStore, бо підхід «файлова система поверх файлової системи» мав неминучі накладні витрати і посилював write amplification під навантаженням.
Монітори Ceph (MON) невеликі, але критичні: вони не обслуговують IO даних, але їхня затримка та проблеми з кворумом можуть зупинити операції кластеру і викликати каскадні уповільнення.
«Відновлення» — це і функція, і податок: самовідновлення Ceph — це причина, чому ви його купили, але recovery IO конкурує з клієнтським IO, якщо ви це не керуєте свідомо.
CRUSH (розміщення даних) детерміністичний, що добре для масштабу, але це означає, що неправильний опис топології може сконцентрувати навантаження та створити видимість випадкової біди.
Мережева стека Ceph (msgr) розвивалася з часом, і сучасні розгортання часто використовують msgr2; помилки конфігурації можуть проявлятися як сплески затримок, а не явні відключення.
Proxmox зробив Ceph популярним у невеликих інфраструктурах, спростивши розгортання; це зручно, доки ви не забудете, що Ceph — розподілена система з розподіленими режимами відмови.

Ментальна модель: де ховається затримка (диск, мережа, CPU або «робота Ceph»)

Якщо ви хочете швидко відлагодити slow ops, припиніть думати «Ceph повільний» і почніть думати «ця черга росте».
Кожна повільна операція — це операція, що зайшла в чергу і не вийшла вчасно.

Дискові вузькі місця: нудний ворог

Диски голосно виходять з ладу, коли вмирають. Але вони можуть тихо деградувати місяцями до цього.
Для вибухового зростання затримок не потрібні помилки носія. Диск може бути «здоровим» і водночас мати 50–200ms tail latency.
Для Ceph важлива хвостова затримка, бо реплікація чекає на найповільніше потрібне підтвердження.

BlueStore додає свої особливості: він використовує RocksDB для метаданих і дуже чутливий до розміщення WAL/DB і характеристик пристрою.
Якщо ваш DB/WAL на тому ж повільному пристрої, що й дані, або ще гірше — на завантаженому SATA SSD, ви отримаєте періодичні зупинки, що будуть виглядати як мережеві проблеми.

Мережеві вузькі місця: підступний ворог

Ceph дуже «балакучий». Не лише в сенсі «відправляю багато байтів», він ще й потребує передбачуваної затримки і малої втрати пакетів для внутрішнього протоколу.
Мережа може мати достатню пропускну здатність, але стати катастрофою через мікробурсти, шторми втрат або невідповідний MTU.

Також: ваша «публічна мережа» (клієнти → OSD) і «кластерна мережа» (реплікація/backfill) — це різні шаблони трафіку.
Змішування їх не заборонене, але ви підписуєтесь на конкуренцію. Якщо кластер зайнятий, внутрішня реплікація може душити клієнтський IO.

CPU вузькі місця: сучасний ворог

З NVMe і швидкою мережею наступним вузьким місцем часто стає CPU: обчислення контрольних сум, накладні витрати BlueStore, шифрування, стиснення
і обробка переривань. Хост може мати «лише» 30% загального використання CPU і при цьому бути обмеженим там, де це важливо: один NUMA вузол,
одне ядро обробки IRQ NIC або декілька потоків ceph-osd, що застрягли в стані runnable.

Вузькі місця «роботи Ceph»: відновлення, backfill, scrub, peering

Ceph виконує фонову роботу, щоб зберегти дані в безпеці та консистентності. Ця робота непримиренна, але її швидкість можна регулювати.
Агресивні налаштування recovery можуть зробити кластер крутим у дашборді, в той час як клієнтський IO тихо задихається.
Навпаки, занадто низькі налаштування recovery затримують відновлення, збільшуючи ризик і іноді загальну кількість роботи.
Ви керуєте цим. Ви не ігноруєте.

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

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

Завдання 1: Визначте, де Ceph вважає проблему

cr0x@server:~$ ceph -s
  cluster:
    id:     9c6c2d4a-1c3b-4b8d-8a5e-2f2f3b2a7b61
    health: HEALTH_WARN
            17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 7d)
    mgr: mgr1(active, since 6d)
    osd: 36 osds: 36 up (since 7d), 36 in (since 7d)
  data:
    pools:   6 pools, 512 pgs
    objects: 4.8M objects, 18 TiB
    usage:   55 TiB used, 98 TiB / 153 TiB avail
    pgs:     510 active+clean
             2 active+clean+scrubbing
  io:
    client:   620 MiB/s rd, 210 MiB/s wr, 4.2k op/s rd, 1.9k op/s wr

Значення: Попередження називає конкретні демони (osd.12, osd.31). Це золото. Якщо це завжди ті самі OSD — підозрюйте хост/диск.
Якщо імена обертаються по багатьох OSD — підозрюйте мережу або глобальний тиск відновлення.

Рішення: Спочатку сфокусуйтесь на названих OSD. Не Міняйте глобальні налаштування CRUSH або пулів, поки не з’ясуєте, локалізована це проблема чи ні.

Завдання 2: Прочитайте докладний стан здоров’я (він містить підказку «blocked on»)

cr0x@server:~$ ceph health detail
HEALTH_WARN 17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
[WRN] SLOW_OPS: 17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
    osd.12 has 9 slow ops, oldest one blocked for 54 sec, committed 0, applied 0
    osd.31 has 8 slow ops, oldest one blocked for 42 sec, committed 0, applied 0

Значення: «committed 0, applied 0» часто вказує, що шлях запису застряг на ранньому етапі — часто це пов’язано з диском/WAL/DB.
Якщо бачите ops committed, але не applied — можливо, це інший етап конвеєра.

Рішення: Перевірте лічильники продуктивності OSD далі; не чіпайте CRUSH або налаштування пулів поки що.

Завдання 3: Перевірте commit/apply затримку OSD (швидкий індикатор проблем із диском)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
 12               87.23             132.71
 31               65.10             110.44
  7                2.11               3.05
  8                1.98               2.80
  9                2.45               3.40

Значення: Два OSD значно повільніші за решту. Це майже ніколи не «тюнінг Ceph». Зазвичай це шлях диска, контролер,
прошивка, чергування або проблема на рівні хоста.

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

Завдання 4: Співставте ID OSD з хостами (перестаньте гадати, куди залогінитись)

cr0x@server:~$ ceph osd find 12
{
    "osd": 12,
    "ip": "10.20.10.12:6803/12345",
    "crush_location": {
        "root": "default",
        "host": "pve3"
    }
}
cr0x@server:~$ ceph osd find 31
{
    "osd": 31,
    "ip": "10.20.10.31:6809/23456",
    "crush_location": {
        "root": "default",
        "host": "pve7"
    }
}

Значення: Тепер ви точно знаєте, які вузли Proxmox перевіряти: pve3 і pve7.

Рішення: Працюйте локально на хості: затримка диска, помилки пристрою, планувальник IO, обробка IRQ, втрати на NIC.

Завдання 5: Шукайте затримки диска і насичення на ураженому хості

cr0x@server:~$ iostat -xz 1 5
Linux 6.8.12-pve (pve3)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.24    0.00    6.18    9.80    0.00   71.78

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  svctm
nvme0n1          42.0   310.0   1800   52600     0.0     0.0   98.7  24.10   0.32
sdb               0.2   120.4      4    2048     0.0     0.0   99.9  87.55   0.41

Значення: %util близько 100% з високим await кричить «черга пристрою».
NVMe з 24ms і SATA/SAS з 87ms await — це не щасливий OSD Ceph. Зверніть увагу, що %iowait теж суттєвий.

Рішення: Визначте, який OSD використовує який пристрій. Якщо це один проблемний диск — заплануйте заміну.
Якщо DB/WAL на насиченому пристрої — перерахуйте розміщення.

Завдання 6: Підтвердіть, які блочні пристрої використовує OSD (відображення BlueStore)

cr0x@server:~$ ceph-volume lvm list | sed -n '1,120p'
====== osd.12 =======
  [block]       /dev/ceph-4f3c7f9d-.../osd-block-1a2b3c4d-...
      devices              /dev/sdb
  [block.db]    /dev/ceph-4f3c7f9d-.../osd-db-9f8e7d6c-...
      devices              /dev/nvme0n1p3
  [block.wal]   /dev/ceph-4f3c7f9d-.../osd-wal-11223344-...
      devices              /dev/nvme0n1p3

Значення: Дані на /dev/sdb, DB/WAL на розділі NVMe. Це нормальна схема, але лише якщо NVMe не перевантажений іншими OSD.

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

Завдання 7: Перевірте системний журнал на «тихі» сигнали відмов диска

cr0x@server:~$ dmesg -T | egrep -i 'blk|nvme|scsi|ata|reset|error|timeout' | tail -n 20
[Thu Dec 26 10:14:02 2025] blk_update_request: I/O error, dev sdb, sector 112394232 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 10:14:02 2025] sd 3:0:8:0: [sdb] tag#218 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Thu Dec 26 10:14:03 2025] sd 3:0:8:0: [sdb] rejecting I/O to offline device
[Thu Dec 26 10:14:05 2025] nvme nvme0: I/O 932 QID 7 timeout, aborting

Значення: Це не «Ceph як завжди». Це ядро каже, що стек зберігання дає збій.
Таймаути і скидання підсилюють затримки і створюють slow ops.

Рішення: Замініть або перепід’єднайте обладнання; перевірте прошивку HBA; перемістіть OSD з підозрілого пристрою. Програмний тюнінг тут марний.

Завдання 8: Перевірте внутрішній погляд Ceph на повільність диска по OSD (метрики)

cr0x@server:~$ ceph daemon osd.12 perf dump | egrep -i 'commit_latency|apply_latency|op_wip|op_queue|bluestore|kv|rocksdb' | head -n 30
    "op_wip": 128,
    "op_queue_age_hist": {
        "avgcount": 4312,
        "sum": 183.221
    },
    "bluestore_kv_commit_lat": 0.084,
    "bluestore_commit_lat": 0.132,
    "bluestore_state_deferred_write": 1

Значення: Високе op_wip означає накопичення черги. Підвищена BlueStore commit latency. Якщо latency RocksDB commit зростає — зазвичай причетний DB/WAL пристрій.

Рішення: Якщо backlog корелює з DB commit latency — перевірте завантаженість DB-пристрою і розгляньте переміщення DB/WAL на швидше носій або збільшення каналів.

Завдання 9: Визначте, чи recovery/backfill — «булі» в кімнаті

cr0x@server:~$ ceph -s | sed -n '1,120p'
  cluster:
    health: HEALTH_WARN
            17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
  data:
    pgs: 480 active+clean
         22 active+clean+remapped+backfilling
         10 active+recovering
  io:
    client: 620 MiB/s rd, 210 MiB/s wr
    recovery: 480 MiB/s, 120 objects/s

Значення: Recovery працює інтенсивно. Це не означає автоматично, що це причина, але воно може посилювати проблему.

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

Завдання 10: Відрегулюйте recovery відповідально (і знайте, що ви змінили)

cr0x@server:~$ ceph osd dump | egrep 'osd_recovery_max_active|osd_max_backfills|osd_recovery_sleep' | head
osd_recovery_max_active 3
osd_max_backfills 1
osd_recovery_sleep 0
cr0x@server:~$ ceph config set osd osd_recovery_max_active 1
cr0x@server:~$ ceph config set osd osd_max_backfills 1
cr0x@server:~$ ceph config set osd osd_recovery_sleep 0.05
cr0x@server:~$ ceph config get osd osd_recovery_max_active
1

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

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

Завдання 11: Перевірте мережу на втрати і повторні передачі (не довіряйте лише «link up»)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed   mcast
    98765432109 123456789 0      124      0       1234
    TX:  bytes  packets  errors  dropped  carrier collsns
    87654321098 98765432  0      0        0       0
cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|IpInDiscards|IpOutDiscards'
TcpRetransSegs            18422
IpInDiscards              91
IpOutDiscards             0

Значення: RX drops і TCP retransmits сильно корелюють зі сплесками затримок Ceph, особливо під навантаженням реплікації.
Втрати можуть бути через переповнення кільцевих буферів на хості, затори в комутаторі, невідповідний MTU, або неправильну конфігурацію bond/LACP.

Рішення: Якщо під час інцидентів drops зростають — виправте шлях мережі до змін Ceph. Перевірте MTU end-to-end і лічильники на комутаторі.

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

cr0x@server:~$ ping -c 20 -M do -s 8972 10.20.10.31
PING 10.20.10.31 (10.20.10.31) 8972(9000) bytes of data.
8972 bytes from 10.20.10.31: icmp_seq=1 ttl=64 time=0.385 ms
8972 bytes from 10.20.10.31: icmp_seq=2 ttl=64 time=0.401 ms
8972 bytes from 10.20.10.31: icmp_seq=3 ttl=64 time=3.912 ms
8972 bytes from 10.20.10.31: icmp_seq=4 ttl=64 time=0.392 ms
--- 10.20.10.31 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19022ms
rtt min/avg/max/mdev = 0.361/0.612/3.912/0.802 ms

Значення: Jumbo frames працюють (немає «Frag needed»), але max RTT підскакує до ~4ms. На локальній кластерній мережі це підозріло.
Сплески без втрат пакетів часто походять від заторів або bufferbloat.

Рішення: Якщо RTT-сплески корелюють з slow ops — дослідіть черги комутатора, QoS і те, чи публічний та кластерний трафік ділять перевантажені аплінки uplink.

Завдання 13: Перевірте насичення CPU і softirq-навантаження на хості OSD

cr0x@server:~$ mpstat -P ALL 1 5 | sed -n '1,80p'
Linux 6.8.12-pve (pve7)  12/26/2025  _x86_64_  (32 CPU)

01:22:10 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
01:22:11 PM  all  22.1  0.0  9.8   1.2    0.0  7.9    0.0   59.0
01:22:11 PM   3  18.0  0.0  12.2  0.9    0.0  28.1   0.0   40.8
01:22:11 PM   4  12.1  0.0  10.8  0.8    0.0  25.4   0.0   50.9

Значення: Softirq високий на певних CPU. Це часто NIC-переривання, сконцентровані на кількох ядрах.
Ceph може виглядати «дисковим», коли насправді CPU не встигає обробляти пакети.

Рішення: Перевірте affinity IRQ і RPS/XPS. Розгляньте ізоляцію NIC для Ceph-трафіку, увімкнення multiqueue і балансування переривань по ядрах.

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

cr0x@server:~$ ceph mon stat
e3: 3 mons at {mon1=10.20.0.11:6789/0,mon2=10.20.0.12:6789/0,mon3=10.20.0.13:6789/0}, election epoch 98, leader 0 mon1, quorum 0,1,2 mon1,mon2,mon3
cr0x@server:~$ ceph time-sync-status
{
  "time_skew_status": {
    "mon1": "ok",
    "mon2": "ok",
    "mon3": "ok"
  },
  "timechecks": {
    "epoch": 98,
    "round": 21834,
    "round_status": "finished"
  }
}

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

Рішення: Якщо монітори нестабільні — полагодьте синхронізацію часу і вирішіть ресурси MON першими. Ненадійний plane керування ускладнює відлагодження data-plane.

Завдання 15: Перевірте, чи конкретний пул потерпає (CRUSH правила, кількість PG, витрати EC)

cr0x@server:~$ ceph osd pool stats
pool rbd:     client_io 1200op/s rd, 800op/s wr, 410MiB/s rd, 190MiB/s wr
pool backups: client_io  50op/s rd,  30op/s wr,  20MiB/s rd,  15MiB/s wr
pool cephfs:  client_io 300op/s rd, 200op/s wr,  90MiB/s rd,  20MiB/s wr
cr0x@server:~$ ceph osd pool ls detail | egrep 'pool|crush_rule|size|min_size|pg_num|pgp_num'
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 pg_num 256 pgp_num 256
pool 2 'backups' replicated size 2 min_size 1 crush_rule 0 pg_num 64 pgp_num 64

Значення: Гарячий пул — rbd з size 3. Це нормально. Якщо повільні операції спостерігаються тільки в одному пулі,
можливо, CRUSH правило розміщує дані на підмножині хостів, або EC-пул має високі витрати CPU.

Рішення: Якщо один пул створює гарячі точки — перевірте CRUSH правила і класи пристроїв. Не карайте весь кластер за дизайн одного пулу.

Завдання 16: Зкорелюйте slow ops зі станами PG (peering/backfill може бути тригером)

cr0x@server:~$ ceph pg stat
512 pgs: 480 active+clean, 22 active+clean+remapped+backfilling, 10 active+recovering; 18 TiB data, 55 TiB used, 98 TiB / 153 TiB avail
cr0x@server:~$ ceph pg dump pgs_brief | egrep 'backfill|recover|peering|stuck' | head
1.2a0  active+clean+remapped+backfilling  [12,7,8]  12  12  1012  1012
1.2a1  active+recovering                  [31,9,10] 31  31  980   980

Значення: Проблемні OSD — частина PG, що активно backfilling/recovering. Це сильна кореляція.

Рішення: Якщо slow ops зумовлені recovery — throttle (Завдання 10) і/або тимчасово виключіть найгірший OSD, якщо це апаратна відмова.

Завдання 17: Якщо один OSD хворий — перевірте heartbeat і обережно приймайте рішення про mark-out

cr0x@server:~$ ceph osd tree | egrep 'pve3|osd.12|pve7|osd.31'
-3     2.91089 host pve3
 12    0.97030     osd.12  up  1.00000  1.00000
-7     2.91089 host pve7
 31    0.97030     osd.31  up  1.00000  1.00000
cr0x@server:~$ ceph osd out 12
marked out osd.12.

Значення: Помітити OSD як out запускає переміщення даних. Якщо робити це під піковим навантаженням, ви можете обміняти «повільні операції» на «повільно все».

Рішення: Mark out тільки коли є докази відмови апаратури або постійної патологічної затримки.
Якщо робите це — throttle recovery і поінформуйте про очікуваний вплив.

Жарт №2: Єдина річ повільніша за відновлення Ceph у зайнятому кластері — це нарада, де хтось пропонує «давайте просто додамо більше PG».

Корпоративна міні-історія #1: інцидент через хибне припущення

Середня компанія працювала на Proxmox з Ceph на трьох вузлах. Місяцями все було добре. Потім «повільні операції» почалися в робочий час,
здебільшого коли запускалася резервна задача. Графіки зберігання показували запас IOPS — принаймні на папері — тож команда вирішила,
що Ceph «просто чутливий».

Неправильне припущення: «Якщо пропускної здатності вистачає, мережа — не проблема.» У них були 10GbE лінки, і iperf тести між вузлами виглядали чудово
опівночі. Під час інциденту вони зосередилися на налаштуваннях BlueStore та recovery, бо саме про це багато дискутують в інтернеті.
Повільні операції тривали, а затримка ВМ ставала неприємною.

Зрештою хтось зробив нудну річ: перевірив ip -s link на bond Ceph під час вікна резервного копіювання.
RX drops почали стрімко зростати. Не «трохи», а настільки, щоб мати значення. Порти комутатора виглядали «UP», але їхні буфери переповнювались мікробурстами:
трафік резервного копіювання, реплікація Ceph і клієнтський IO ділили один аплінк, а стандартні налаштування черг комутатора не допомагали.

Виправлення було непретензійним і дієвим: розділити трафік Ceph кластеру від публічного/клієнтського (VLAN і фізичні порти),
зменшити паралелізм резервного копіювання і забезпечити консистентність MTU end-to-end. Повільні операції перестали бути щоденним ритуалом.
Команда зробила болісне відкриття: розподілене зберігання не потребує лише швидкої мережі; йому потрібна передбачувана мережа.

Найважливіший висновок постмортему: вони міряли пропускну здатність мережі, але не втрати пакетів і хвостову затримку під реальним навантаженням.
Вони тестували трасу о 2-й ночі і проголошували її безпечною для годин пік.

Корпоративна міні-історія #2: оптимізація, що відсіклася боком

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

Потім рутинний рестарт OSD перетворився на інцидент у будній день. Затримка клієнтів зросла. Повільні операції накопичилися. Кластер технічно лишався «up»,
що робило ситуацію гіршою: навантаження не падало чітко, а просто сповільнювалося, поки таймаути і повтори не зробили все голосніше.
Здавалося, що диски виходять з ладу — доки не виявили, що диски в порядку, а кластер просто тону в власному ентузіазмі recovery.

Ця «оптимізація» не була аргументом проти тюнінгу. Вона була аргументом проти тюнінгу без меж.
Вони фактично наказали всім OSD віддавати пріоритет відновленню на рівні, що мало сенс лише коли кластер був інакше простий.
У продукції recovery конкурував з клієнтським IO на кожному кроці: читання для копіювання об’єктів, запис для розміщення, і мережа для реплікації.

Виправлення було простим: ставити recovery як заплановане навантаження. У робочий час recovery обмежили.
Поза робочим часом його дозволили працювати інтенсивніше, але все одно в межах безпечних спостережуваних лімітів.
Також почали відстежувати «відновлювальну швидкість vs затримка клієнтів» як перший показник SLO, а не надію.

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

Корпоративна міні-історія #3: нудна практика, що врятувала ситуацію

Регульоване середовище (аудити, вікна змін і люди, які люблять таблиці) працювало на Proxmox+Ceph з суворою операційною дисципліною.
Вони не були захоплюючими. Але вони були стабільно онлайн.

Їхня «нудна практика» — щотижневий базовий замір латентності і здоров’я: записувати ceph osd perf, iostat на хості і лічильники втрат мережі
під відомим навантаженням. Вони не оптимізували постійно. Вони стежили за дрейфом.
Коли дрейф виявляли — наприклад, один OSD повільно піднімав apply latency від 2ms до 8ms — діяли рано.

Одного тижня baseline зафіксував хост OSD з ростом таймаутів NVMe в dmesg, але ще без SMART-помилок.
Вони відключили цей хост, замінили NVMe у заплановане вікно і уникли інциденту, який би стався під час квартального звіту.
Через місяць про це вже ніхто не згадував — найкраща похвала для технічного обслуговування.

Вони також тримали throttles recovery як документовану політику, а не як племінне знання. Коли OSD впав несподівано,
on-call мав відомий безпечний набір налаштувань, який можна було застосувати, замість імпровізації під тиском.

Урок стабільний: нудні операції — це не лінощі. Це дисципліна не вчитися на ті самі помилки знову.

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

Це не теоретично. Це помилки, що з’являються о 3-й ранку, коли ви носите пейджер як капелюх.

1) Повільні операції тільки на кількох OSD

Симптоми: ceph osd perf показує 1–3 OSD з у 10–100× вищою commit/apply затримкою; попередження називають ті самі демони.
Корінь: Один проблемний диск, канал HBA, спільний DB/WAL, або проблема контенції на хості.
Виправлення: Співставте OSD до хосту/пристрою; перевірте iostat і dmesg; замініть обладнання або перемістіть DB/WAL; уникайте кластерних глобальних налаштувань.

2) Повільні операції повсюдно під час recovery/backfill

Симптоми: Багато OSD повідомляють slow ops; PG показують backfill/recovering; пропускна здатність recovery висока; затримка клієнтів зростає.
Корінь: Паралельність recovery занадто агресивна для вашого обладнання/мережі; змішування клієнтського і кластерного трафіку на перевантажених лінках.
Виправлення: Обмежте recovery/backfill; розділіть мережі за можливості; плануйте інтенсивне відновлення на поза-години.

3) Повільні операції разом із RX drops або retransmits

Симптоми: ip -s link показує drops; nstat показує TCP retransmits; ping RTT під навантаженням стрибає.
Корінь: Переповнення, bufferbloat, невідповідний MTU, поганий bond/LACP hashing, баги драйвера/прошивки NIC, помилки на портах комутатора.
Виправлення: Перевірте MTU end-to-end; перегляньте лічильники комутатора; зафіксуйте режим bond; збалансуйте IRQ; розгляньте окремі мережі для Ceph.

4) «Диски виглядають вільними», але Ceph все одно повільний

Симптоми: iostat показує помірне %util; Ceph apply latency все ще висока; CPU softirq або system time високі.
Корінь: CPU-вузьке місце (обробка переривань, контрольні суми, шифрування), проблеми NUMA, дисбаланс IRQ.
Виправлення: Збалансуйте переривання; переконайтесь у multiqueue; виділіть Ceph адекватними ядрами; уникайте перевантаження CPU VM-вантаженнями на вузлах OSD.

5) Сплески slow ops без очевидних помилок

Симптоми: Кластер здебільшого в порядку, але періодично латентність виростає; явних помилок диска немає.
Корінь: Фонові scrubs у невдалий час, компактна RocksDB, або «гучні» сусідні ВМ, що насичують ті самі ресурси хоста.
Виправлення: Плануйте scrubs; переконайтесь, що DB/WAL пристрої мають запас; ізолюйте Ceph трафік; розміщуйте шумні навантаження обережно.

6) «Ми збільшили PG і продуктивність погіршилась»

Симптоми: Більше PG — більше пам’яті, більше навантаження CPU; OSD зайняті; збільшуються slow ops.
Корінь: Кількість PG перевищила можливості кластера; зросли накладні витрати на метадані; peering і технічне обслуговування дорожчають.
Виправлення: Використовуйте розумні розміри PG; зменшіть PG якщо їх надто багато; зосередьтесь на апаратних вузьких місцях і розміщенні, а не на «більше шард».

7) «Повільні запити» CephFS, що маскуються під загальні slow ops

Симптоми: CephFS клієнти повільні; MDS повідомляє slow requests; RBD може бути в порядку.
Корінь: Недостатньо ресурсів MDS (CPU/RAM), занадто багато caps, або метадантажна навантаженість без налаштувань.
Виправлення: Масштабуйте MDS, закріпіть їх на надійних хостах і, за потреби, розмістіть метаданний пул CephFS на швидших пристроях.

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

Чекліст A: Тріаж за 10 хвилин

Запустіть ceph -s і ceph health detail. Запишіть, які демони і наскільки старий найстарший slow op.
Запустіть ceph osd perf. Визначте, локалізовано це (кілька OSD) чи системне (багато підвищених).
Перевірте стани PG з ceph pg stat. Якщо активне backfill/recovery — зафіксуйте пропускну здатність recovery.
На уражених хостах запустіть iostat -xz 1 5 і ip -s link. Шукайте високий await/%util або drops.
Якщо бачите помилки/таймаути в dmesg, обробляйте як апаратну помилку, поки не доведено інше.

Чекліст B: Визначте «диск vs мережа vs CPU» з доказами

Дисковий випадок: Висока commit/apply затримка на конкретних OSD + високий await/%util + помилки/таймаути ядра. Замінити або перемістити.
Мережевий випадок: Drops/retransmits + RTT-сплески під навантаженням + багато OSD по хостах. Виправити MTU, затори, bond, комутацію.
CPU випадок: Високий softirq/system time + концентрація IRQ + швидкі диски + швидка мережа, але все одно slow ops. Збалансувати IRQ і зменшити контенцію.
Тиск recovery: PGs backfilling/recovering + висока пропускна здатність recovery + spike латентності після події. Тротлити, потім відновити.

Чекліст C: Безпечні дії «зупинити кровотечу» (ранжовано)

Тротлити recovery/backfill (тимчасово). Це відкатне і часто миттєво допомагає.
Призупинити scrubs в пікові години, якщо scrubbing сприяє (потім увімкнути пізніше).
Перемістити найгарячіші ВМ з хостів OSD, що вже працюють на межі (зменшити noisy neighbor).
Позначити явно несправний OSD out тільки коли є сильні докази. Потім контролювати швидкість recovery.
Не перезапускайте масово OSD в надії, що «очиститься». Це часто множить роботу відновлення і перетворює попередження на довгий день.

Чекліст D: Структурні поліпшення (те, що робити поза пожежами)

Розділіть публічний і кластерний трафік Ceph, якщо можете (фізичні NIC або VLAN з плануванням пропускної здатності).
Переконайтесь, що розміщення DB/WAL свідоме: достатньо NVMe, не перевантажене, не ділиться з чужими навантаженнями.
Правильно розміркуйте хости OSD: запас CPU і RAM має значення з швидкими носіями і 25/40/100GbE.
Базуйте і трендуйте: записуйте щотижнево OSD latency, диск latency і мережеві drops. Дрейф — ваш ранній сигнал тривоги.
Стандартизуйтe політику recovery: обмеження у робочий час, інтенсивніше поза робочими годинами, документовані кроки відкату.

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

1) Чи завжди «повільні операції» — це продакшн-аварія?

Ні. Декілька повільних операцій під час контрольованого відновлення можуть бути прийнятними. Якщо повільні операції тривають, ростуть або корелюють зі сплесками затримки IO ВМ — трактуйте це як інцидент.

2) Якщо лише один OSD має високу apply latency, чи безпечно його перезапустити?

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

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

Проблеми з диском проявляються у невеликій кількості OSD із екстремальною commit/apply затримкою і високим await на пристрої. Проблеми мережі дають ширший вплив плюс drops/retransmits і RTT-сплески під навантаженням.

4) Чи має сенс розділяти public і cluster мережі для невеликих кластерів?

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

5) Чи може CPU бути вузьким місцем, якщо загальне завантаження CPU лише 30%?

Так. Обробка IRQ і softirq може наситити кілька ядер, тоді як решта проста. Також NUMA локальність і поведінка потоків на демоні можуть створити «локальну насиченість», яку середні значення приховують.

6) Чи варто підвищувати налаштування recovery, щоб кластер швидше загоювався?

Лише після вимірювання впливу на клієнтів. Швидше recovery — корисно, але не якщо воно перетворює клієнтський IO на болото. Використовуйте політику: консервативно в пікові години, агресивніше поза ними, і перевіряйте метрики затримки.

7) Як зрозуміти, чи BlueStore DB/WAL — мій вузький горлечко?

Шукайте підвищені BlueStore/RocksDB commit latencies у ceph daemon osd.X perf dump і перевірте завантаження/затримки на DB-пристрої. Якщо DB ділиться між занадто багатьма OSD — це спільний вузький горлечко.

8) Нормально, що recovery викликає slow ops?

Невеликий вплив нормальний. Великий вплив зазвичай означає, що recovery конкурує занадто агресивно з клієнтським IO або що апарат/мережа недостатні для обраних налаштувань реплікації/EC.

9) Чи змінює Proxmox поведінку Ceph під навантаженням?

Proxmox не змінює фундаментальні властивості Ceph, але впливає на шаблони навантаження (міграції, бекапи, снепшоти) і конкуренцію ресурсів (ВМ і OSD на тих самих хостах). Фізика залишається.

10) Який безпечний перший регулятор у інциденті?

Часто найбезпечніша і відкатна дія — тротлити recovery/backfill, особливо коли повільні операції з’явилися після відмови і PG активно відновлюються. Не намагайтеся «відтюнити» проблему замість виправлення несправного обладнання.

Висновок: наступні кроки, які дійсно змінюють результат

Коли Ceph каже «повільні операції», він не просить ваших почуттів. Він просить вимірів.
Почніть зі сфери (які демони), потім класифікуйте вузьке місце (диск, мережа, CPU або тиск recovery), і дійте з відкатними контролями, перш ніж змінювати архітектуру.

Практичні наступні кроки:

Сформуйте короткий рукопис з Fast diagnosis playbook і розділу Tasks. Покладіть його туди, де його знайде on-call.
Ведіть baseline ceph osd perf, host iostat і мережеві лічильники втрат щотижнево. Слідкуйте за дрейфом.
Визначте політику recovery і задокументуйте її (включно з тим, як відкотити зміни).
Якщо ви змішуєте public і cluster трафік на одній перевантаженій мережі — плануйте розділення. Це найпростіший спосіб придбати надійність.
Якщо конкретні OSD постійно повільні — припиніть дебати. Замініть апарат або виправте топологію пристроїв. Ceph рідко помиляється щодо того, який OSD страждає.