Proxmox Ceph HEALTH_WARN: з чого почати безпечне усунення несправностей

October 17, 2025 • February 3, 2026 • Читання: 8 хв • Views: 10

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

Ви глянули в Proxmox, побачили жовту панель — і ваш мозок зробив те саме, що й кластер: почав панікувати. Повідомлення каже «Ceph HEALTH_WARN». Це може бути нешкідливе прибирання або перший кашель перед пневмонією.

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

Що насправді означає HEALTH_WARN (і чого воно не означає)

Стан здоров’я Ceph має три загальні стани: HEALTH_OK, HEALTH_WARN, HEALTH_ERR. HEALTH_WARN — це кластер, який каже: «Щось не ідеально, але я ще працюю.»

Це не означає «ігнорувати». І це не означає «панікувати й починати перезапуск демонами». HEALTH_WARN — це контейнер. Справжній сенс — у списку попереджень нижче: nearfull, OSD down, PGs degraded, slow ops, clock skew, проблеми кворуму моніторів, помилки scrub та близько десятка інших способів, якими сховище чемно просить про допомогу.

Два керівні принципи:

Ceph — це розподілена машина станів. Більшість «виправлень» стосуються дозволу йому зійтись у стані (або допомогти безпечно зійтись).
Найбезпечніші перші кроки — тільки для читання. Спостерігайте, вимірюйте, а потім змінюйте.

Операційно корисна інтерпретація:

HEALTH_WARN зі стабільним I/O і без ризику доступності даних: плануйте обслуговування, зменшуйте ризики, не запускайте хаотичних операцій.
HEALTH_WARN з впливом на клієнтів (затримки, таймаути, завислі ВМ): ставтеся до цього як до інциденту й швидко виявляйте вузьке місце.
HEALTH_WARN з “misplaced”, “degraded” або “undersized” PGs: ви на крок від неприємностей при ще одній відмові. Пріоритет — відновлення надмірності.

Суха правда: Ceph — як колективний проєкт — якщо ви не перевіряєте, що робить кожен, доведеться дебагувати «проблеми комунікації» о 2-й ночі.

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

Перший: підтвердьте, що саме неправильно (одна команда, один екран)

Ваше перше завдання — перетворити «жовтий» стан на одну-дві конкретні моделі відмови.

cr0x@server:~$ ceph -s
  cluster:
    id:     7c2f0b7c-9c55-4e2e-8b3f-8c3c7c1d8a2a
    health: HEALTH_WARN
            1 osds down
            2 nearfull osd(s)
            36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops.

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 2h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 12 osds: 11 up, 12 in

  data:
    pools:   2 pools, 256 pgs
    objects: 2.1M objects, 8.2 TiB
    usage:   24 TiB used, 36 TiB / 60 TiB avail
    pgs:     240 active+clean
             12  active+undersized+degraded

Значення: Це не одна проблема; це кластер під навантаженням. Один OSD вимкнений, кілька майже заповнені (що призводить до уповільнення), і є slow ops (впливає на клієнтів). PGs undersized/degraded (ризик).

Рішення: Поводьтеся як під час інциденту. Спершу зосередьтеся на ризику доступності (OSD down → degraded PGs), потім на продуктивності (slow ops), одночасно починаючи планування пом’якшення nearfull.

Другий: визначте, чи проблема — «контрольна площина», чи «площина даних»

Проблеми контрольної площини: флап кворуму моніторів, mgr помер, зсув часу. Проблеми площини даних: OSDs down, помилки диска, втрата мережі, slow ops, backfill-шторми.

Якщо кворум моніторів нестабільний, не починайте «ремонтувати» PGs. Виправте кворум спочатку.
Якщо OSDи down, не ганяйтеся за налаштуваннями продуктивності. Відновіть OSDи та надмірність.
Якщо всі демони працюють, але slow ops тривають, шукайте проблеми з мережею/диском та налаштування відновлення.

Третій: визначте тип вузького місця за 10 хвилин

Більшість реальних інцидентів HEALTH_WARN зводяться до одного з наступних:

Тиск ємності (nearfull/full, backfill блокує, записи обмежені).
Відмова одного вузла (OSD down, перезавантаження хоста, диск помер, HBA скидає з’єднання).
Проблеми мережі (втрати пакетів, невірний MTU, перевантажений комутатор, асиметрична маршрутизація).
Шторм відновлення (backfill/rebalance конкурують з клієнтським I/O).
Повільне сховище (один OSD-пристрій тягне всіх вниз).
Проблеми часу/годинника (попередження моніторів про зсув часу, аутентифікаційні аномалії, флапи).

Правила безпеки: чого уникати, коли кластер жовтий

Ceph винагороджує спокій. Він карає імпровізації.

1) Не перезапускайте демони «щоб очистити попередження»

Перезапуск монів/mgr/osd змінює стан, запускає пееринг, може перезапустити відновлення і зробити гірше те, що ви мали: стабільний кластер, який повільно сходився. Перезапускайте лише коли ви знаєте, що виправляєте (залежлий процес, підтверджений цикл краху, kernel reset тощо).

2) Не виводьте OSDs з кластера, якщо ви цього не маєте на увазі

ceph osd out запускає переміщення даних. На навантаженому кластері це може перетворити «один OSD down» на «весь кластер повільний годинами». Якщо OSD вимкнувся через транзитну проблему хоста, спочатку підніміть його, перш ніж оголошувати out.

3) Не «вирішуйте nearfull», змінюючи коефіцієнти повноти під час інциденту

Так, можна підвищити mon_osd_nearfull_ratio та подібні. Це не ємність. Це заперечення з додатковими кроками. Якщо потрібно змінити коефіцієнти для розблокування екстрених записів, ставте це як тимчасовий виняток з планом відкату.

4) Не запускайте агресивні команди ремонту без розбору

ceph pg repair та інструменти на рівні OSD можуть бути коректними, але це не перша реакція. Доведіть наявність помилок scrub або невідповідних PG, і підтвердіть стабільність кворуму та мережі спочатку.

5) Не оптимізуйте відновлення, поки діагностика ще триває

Зміна osd_max_backfills або osd_recovery_max_active може допомогти — але також може віджати клієнтський I/O або перевантажити слабкий вузол. Спочатку діагностуйте, потім налаштовуйте.

Жарт №1: Якщо ви збираєтеся «просто перезавантажити Ceph-нод», пам’ятайте: кластер має почуття, і він виражає їх у трафіку backfill.

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

Ceph почався в UC Santa Cruz як дослідницький проєкт у середині 2000-х, з метою самовідновлюваного сховища в масштабі. Цей підхід і нині помітний: він хоче лікувати себе сам, іноді голосно.
CRUSH — це не файловa система; це алгоритм розміщення, який вирішує, куди класти дані без центральної таблиці, тому Ceph масштабується без єдиного метаданого вузла для розміщення об’єктів.
PGs (placement groups) — віртуальні кошики, що управляють реплікацією й відновленням. Вони не «розділи» й не «томи», але контролюють радіус ураження під час відновлення.
HEALTH_WARN часто сигналізує про ємність, а не про відмову. Багато кластерів працюють «нормально», поки не досягнуть nearfull, після чого продуктивність падає, бо Ceph захищає себе.
Модель scrub Ceph — це профілактична медицина: легкі і глибокі scrubs торгують фоновим I/O за раннє виявлення корупції. Вимикати scrub — все одно, що знімати датчики диму лише тому, що вони пищать.
BlueStore змінив FileStore як дефолтний бекенд роки тому, щоб зменшити складність журналу і підвищити продуктивність, особливо на SSD/NVMe.
Публічна та кластерна мережі — окремі концепти в дизайні Ceph: змішування клієнтського трафіку та реплікації/backfill на одній насиченій мережі — класична помилка «в тесті було нормально».
Proxmox щільно інтегрує Ceph (pveceph інструменти, UI панелі здоров’я), але це не змінює фундаментальної поведінки Ceph: ви все ще розбираєтесь з інструментами Ceph, а не з відчуттями GUI.
Попередження про зсув часу існують не випадково: монітори Ceph покладаються на таймаути та логіку кворуму; дрейф часу може виглядати як відмови й спричиняти флапи.

Цитата, яку варто записати: «Надія — не стратегія.» — General Gordon R. Sullivan.

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

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

Завдання 1: Зробіть знімок деталей стану кластера

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 osds down; 2 nearfull osd(s); 36 slow ops
[WRN] OSD_DOWN: 1 osds down
    osd.7 down since 2025-12-26T09:01:33.123+0000, last_up 2025-12-26T08:42:10.991+0000
[WRN] OSD_NEARFULL: 2 nearfull osd(s)
    osd.3 is near full at 84%
    osd.9 is near full at 85%
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

Значення: Це дієвий список. Він каже, що Ceph вважає проблемним, з ID та часовими мітками.

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

Завдання 2: Перевірте кворум моніторів і базову стабільність контрольної площини

cr0x@server:~$ ceph quorum_status --format json-pretty
{
  "election_epoch": 42,
  "quorum": [0,1,2],
  "quorum_names": ["pve1","pve2","pve3"],
  "quorum_leader_name": "pve1",
  "monmap": {
    "mons": [
      {"rank":0,"name":"pve1","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.11:3300"},{"type":"v1","addr":"10.10.0.11:6789"}]}},
      {"rank":1,"name":"pve2","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.12:3300"},{"type":"v1","addr":"10.10.0.12:6789"}]}},
      {"rank":2,"name":"pve3","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.13:3300"},{"type":"v1","addr":"10.10.0.13:6789"}]}}
    ]
  }
}

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

Рішення: Якщо кворум нестабільний: зупиніться і виправте мережу/час/здоров’я хоста моніторів спочатку. Не чіпайте стан OSD або ремонт PG, поки кворум не стане приємним і стабільним.

Завдання 3: Підтвердьте, що менеджер активний і не завис

cr0x@server:~$ ceph mgr stat
{
  "active_name": "pve1",
  "num_standbys": 1
}

Значення: MGR надає панелі і частину оркестраційної логіки (залежно від модулів). Якщо він впав, ви втрачаєте видимість і частину автоматизації.

Рішення: Якщо немає активного mgr: відновіть його, але не припускайте, що проблеми з mgr викликають I/O проблеми. Зазвичай це питання видимості, а не шляху даних.

Завдання 4: Визначте, які PGs нездорові і чому

cr0x@server:~$ ceph pg stat
256 pgs: 240 active+clean, 12 active+undersized+degraded, 4 active+peering
data: 8.2 TiB objects, 24 TiB used, 36 TiB / 60 TiB avail
io: 120 MiB/s rd, 45 MiB/s wr, 410 op/s rd, 190 op/s wr

Значення: undersized+degraded означає, що вимоги реплікації не виконуються. peering означає, що PG домовляється, хто за що відповідає; це може бути нормальним короткочасно або ознакою глибшої проблеми, якщо затягується.

Рішення: Якщо degraded/undersized триває більше кількох хвилин — знайдіть відсутні OSD і відновіть їх. Якщо peering затягується — підозрюйте мережеву розділеність або флапи OSD.

Завдання 5: Швидко знайдіть down OSD і його хост

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         5.45600  root default
-3         1.81900      host pve1
 0    hdd  0.45500          osd.0      up   1.00000  1.00000
 3    hdd  0.45500          osd.3      up   1.00000  1.00000
 7    hdd  0.45500          osd.7    down   1.00000  1.00000
-5         1.81900      host pve2
 1    hdd  0.45500          osd.1      up   1.00000  1.00000
 4    hdd  0.45500          osd.4      up   1.00000  1.00000
 9    hdd  0.45500          osd.9      up   1.00000  1.00000
-7         1.81800      host pve3
 2    hdd  0.45500          osd.2      up   1.00000  1.00000
 5    hdd  0.45500          osd.5      up   1.00000  1.00000
12    hdd  0.45500          osd.12     up   1.00000  1.00000

Значення: Це дає вам фізичний радіус ураження: який вузол містить down OSD.

Рішення: Якщо це проблема на рівні хоста (кілька OSDs down на одному хості), поводьтеся як з інцидентом вузла (живлення, kernel, NIC, HBA). Якщо це одиночний OSD — ймовірно проблема диска або шляху до нього.

Завдання 6: Перевірте, чи OSD дійсно «down», чи просто «out»/зупинений

cr0x@server:~$ ceph osd dump | grep -E '^osd\.7|^epoch'
epoch 12872
osd.7 up 0 in 1 weight 0.455 last_clean_begin 2025-12-26T08:40:15.000000+0000 last_clean_end 2025-12-26T08:40:15.000000+0000

Значення: OSD має up 0 (down), але ще in 1. Ceph очікує, що він є в кластері, але він не відповідає.

Рішення: Краще відновити демон/шлях диска, щоб він знову став up. Уникайте оголошення out, якщо ви очікуєте короткого простою або можете швидко відновити.

Завдання 7: На постраждалому хості перевірте сервіс OSD і останні логи

cr0x@server:~$ systemctl status ceph-osd@7 --no-pager
● ceph-osd@7.service - Ceph object storage daemon osd.7
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:02:01 UTC; 3min ago
    Process: 19444 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)
   Main PID: 19444 (code=exited, status=1/FAILURE)

cr0x@server:~$ journalctl -u ceph-osd@7 -n 80 --no-pager
Dec 26 09:01:58 pve1 ceph-osd[19444]: bluestore(/var/lib/ceph/osd/ceph-7) _mount failed: (5) Input/output error
Dec 26 09:01:58 pve1 ceph-osd[19444]: failed to mount object store
Dec 26 09:02:01 pve1 systemd[1]: ceph-osd@7.service: Main process exited, code=exited, status=1/FAILURE

Значення: Це не питання логіки Ceph; це помилка I/O при монтуванні BlueStore. Думайте про диск, контролер, кабелі, kernel.

Рішення: Перейдіть до перевірки апаратури і kernel-логів. Якщо диск помирає, плануйте процедуру заміни OSD, а не нескінченні перезапуски.

Завдання 8: Перевірте kernel-повідомлення про скидання/таймаути дисків на тому вузлі

cr0x@server:~$ dmesg -T | tail -n 40
[Fri Dec 26 09:01:41 2025] sd 6:0:2:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Fri Dec 26 09:01:41 2025] blk_update_request: I/O error, dev sdc, sector 918274048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 09:01:43 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Fri Dec 26 09:01:43 2025] ata7.00: failed command: READ DMA
[Fri Dec 26 09:01:44 2025] ata7: hard resetting link

Значення: Kernel бачить реальні I/O помилки/скидання. Ceph не може побороти фізику.

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

Завдання 9: Визначте винуватців «slow ops» і чи це один OSD чи багато

cr0x@server:~$ ceph health detail | sed -n '/SLOW_OPS/,$p'
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

cr0x@server:~$ ceph daemon osd.12 dump_historic_ops | head -n 25
{
  "ops": [
    {
      "description": "osd_op(client.48219:9123 3.2f3a 3:1f9d9b4f:::rbd_data.1a2b...:head [write 0~4194304] ...)",
      "duration": 92.334,
      "initiated_at": "2025-12-26T09:00:11.112233Z",
      "type_data": { "op_type": "write" }
    }
  ]
}

Значення: Ceph показує, який демон блокує операції. Якщо це один OSD систематично — підозрюйте його диск або хост (затримки, черги, NIC).

Рішення: Якщо один OSD — «гарячий», перевірте метрики диска та вузла. Якщо slow ops розподілені по багатьох OSDs — підозрюйте перевантаження мережі або шторм відновлення.

Завдання 10: Перевірте тиск відновлення/backfill (тихий вбивця продуктивності)

cr0x@server:~$ ceph -s | sed -n '/recovery/,$p'
  progress:
    Global Recovery Event (1m)
      [==========..........] (remaining: 2m)
      recovering, 1.2 GiB/s, 18 objects/s

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   8
1    6                   9
2    5                   8
3    7                   11
4    6                   9
5    5                   8
9    8                   14
12   60                  95

Значення: Відновлення йде, і один OSD (12) має значно гіршу затримку. Цей OSD може стати якорем, що тягне вниз і відновлення, і клієнтський I/O.

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

Завдання 11: Підтвердіть, що nearfull реальний, і знайдіть винуватців

cr0x@server:~$ ceph df detail | head -n 40
RAW STORAGE:
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
hdd    60 TiB   36 TiB   24 TiB     24 TiB      40.0
POOLS:
POOL     ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd      1   224  7.8 TiB 2.0M     23 TiB   62.5   11 TiB
cephfs   2   32   0.4 TiB 0.1M     1.1 TiB  18.0   11 TiB

cr0x@server:~$ ceph osd df | sort -k8 -n | tail -n 6
ID CLASS WEIGHT  REWEIGHT SIZE   RAW USE DATA   OMAP META AVAIL %USE VAR  PGS STATUS
3  hdd   0.45500 1.00000  5.5T   4.6T    4.5T   0B  4.0G 0.9T 84.1 1.20 24  up
9  hdd   0.45500 1.00000  5.5T   4.7T    4.6T   0B  4.1G 0.8T 85.2 1.21 26  up

Значення: Nearfull розраховується по OSD, а не по середньому по кластеру. Два OSD гарячі, ймовірно через CRUSH-нерівновагу, невідповідність розмірів пристроїв або попередні «out/in», що спричинили нерівномірне розміщення.

Рішення: Якщо кілька OSDs nearfull — не просто додавайте ємність «десь». Виправте дисбаланс (reweight/balancer), замініть малі диски або акуратно перерозподіліть. Також сплануйте негайний запас місця: видалення/перенесення даних, якщо ви близькі до заповнення.

Завдання 12: Перевірте, чи balancer увімкнено і чи допомагає він

cr0x@server:~$ ceph balancer status
{
  "active": true,
  "mode": "upmap",
  "optimize_result": "no_optimization_needed",
  "last_optimize_duration": "0.000000s"
}

Значення: Режим upmap може вирівняти розподіл без масивного руху даних, але він все одно змінює відображення. Якщо він вимкнений — у вас може бути довготривалий дисбаланс. Якщо увімкнений, але застряг — можуть бути обмеження (nearfull, неправильні CRUSH-правила).

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

Завдання 13: Перевірте синхронізацію часу і попередження про зсув годинника

cr0x@server:~$ ceph health detail | grep -i skew
[WRN] MON_CLOCK_SKEW: clock skew detected on mon.pve2, mon.pve3

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

Значення: Попередження про зсув часу можуть бути спричинені реальним дрейфом, призупиненими ВМ або перевантаженими вузлами, які затримують NTP. Часто це «нода занадто зайнята, щоб тримати час стабільно».

Рішення: Якщо NTP не синхронізовано — виправте час спочатку. Якщо NTP в порядку, але попередження тривають — перевірте завантаження CPU або призупинення ВМ на хостах моніторів.

Завдання 14: Перевірте помилки мережі і втрачені пакети на інтерфейсах Ceph

cr0x@server:~$ ip -s link show dev eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9123491234  12349123   0     412     0     10123
    TX:  bytes packets errors dropped carrier collsns
    8234123412  11234123   0      95      0     0     0

Значення: Drop-и на мережі збереження тісно корелюють зі slow ops, затримками пеерингу і флапами OSD. Невідповідність MTU може виглядати як випадкова втрата.

Рішення: Якщо drop-и/помилки ненульові та ростуть — підозревайте мережу. Підтвердіть MTU наскрізь і перевірте порти комутатора. Не налаштовуйте Ceph recovery, щоб «вилікувати» проблему втрати пакетів.

Завдання 15: Перевірте флаги кластера, які можуть блокувати відновлення

cr0x@server:~$ ceph osd dump | grep flags
flags noout,noscrub,nodeep-scrub

Значення: Флаги на кшталт noout можуть ставитись навмисно під час обслуговування, але вони також можуть тримати кластер деградованим довше, ніж треба. noscrub може приховувати сигнали корупції.

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

Завдання 16: Проінспектуйте конкретний PG, який застряг або деградований

cr0x@server:~$ ceph pg dump_stuck inactive | head
PG_STAT STATE             UP            UP_PRIMARY  ACTING        ACTING_PRIMARY
1.2a     inactive         [7,3,12]      7           [7,3,12]      7

cr0x@server:~$ ceph pg 1.2a query | head -n 35
{
  "state": "active+undersized+degraded",
  "up": [7,3,12],
  "acting": [7,3,12],
  "info": {
    "stats": {
      "state": "active+undersized+degraded"
    }
  },
  "recovery_state": [
    {
      "name": "Started/Primary/Active",
      "enter_time": "2025-12-26T09:01:40.000000Z"
    }
  ]
}

Значення: У складі acting set PG є OSD 7, який down. Ось чому PG не може виконати вимоги size/min_size.

Рішення: Відновіть OSD 7 або замініть його. Не марнуйте час на PG repair, коли відсутня копія — ось справжня причина.

Завдання 17: Якщо потрібно обмежити відновлення, робіть це цілеспрямовано (і поверніть зміни потім)

cr0x@server:~$ ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1'
injected data to osd.0
injected data to osd.1
injected data to osd.2
injected data to osd.3
injected data to osd.4
injected data to osd.5
injected data to osd.9
injected data to osd.12

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

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

Завдання 18: Перевірте, чи налаштування пулів replication/min_size не самосаботують

cr0x@server:~$ ceph osd pool ls detail | sed -n '1,80p'
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 224 pgp_num 224 autoscale_mode on
pool 2 'cephfs' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on

Значення: Size 3 / min_size 2 — типово. Якщо min_size = 3, один OSD down може блокувати записи. Якщо size = 2 в малому кластері — ваша толерантність до відмови тонша, ніж здається.

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

Три міні-історії з виробництва

1) Інцидент через хибне припущення: «Жовтий означає безпечно»

Середня SaaS-компанія використовувала Proxmox з Ceph для зберігання ВМ. Вони бачили HEALTH_WARN часто — зазвичай це був scrub-попередження, nearfull OSD, що зник після очищення, або тимчасовий флап OSD під час оновлення ядра. На чергуванні звикли глянути ceph -s, пожалкувати плечима і йти далі, якщо UI не ставав червоним.

Одної п’ятниці HEALTH_WARN повідомив про один OSD down і кілька degraded PG. Припущення було: «реплікація покриє це». У принципі правильно; неправильно — вчасно. Кластер був вже під навантаженням: високий запис, відновлення занадто сильно обмежено після попереднього інциденту, і один вузол мав трохи гірші диски.

За вихідні другий диск того ж хоста почав видавати піки затримки. OSD не впав повністю, він просто став настільки повільним, щоб викликати slow ops. Клієнти почали таймаути. Сховище технічно було доступне, але продуктивність стала відсутністю — бізнес сприйняв це як «платформа впала», бо ВМ, які не можуть писати, фактично вимкнені.

У постмортемі була одна важлива фраза: вони вважали втрату надмірності косметичною. Degraded PG — це не прикраса; це зворотний відлік, що прискорюється під навантаженням.

Виправлення не потребувало героїзму. Відновили down OSD, замінили диск і—найголовніше—додали правило: degraded/undersized PG запускає інцидент незалежно від кольору. Колір UI — не ваша модель ризику.

2) Оптимізація, що влізла боком: «Покращимо швидкість відновлення»

Інша організація часто перезавантажувала вузли через прошивку. Вони втомилися від довгого відновлення і вирішили «налаштувати Ceph». Хтось підвищив osd_max_backfills і osd_recovery_max_active по всьому кластеру, щоб backfill йшов швидше.

На порожньому стендовому кластері це спрацювало. У продакшні те саме змінило кожне перезавантаження у brownout. Відновлення конкурувало з клієнтськими записами та читаннями, насичуючи диски і мережу сховища. Піки затримок викликали більше slow ops. Slow ops призводили до таймаутів. Таймаути — до повторних спроб. Повторні спроби підсилювали навантаження. Уся річ перетворилася на самостворений DDoS, але з YAML.

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

Виправили, прив’язавши налаштування відновлення до часу доби й спостережуваної латентності. Створили два профілі: консервативний у робочий час, агресивний — вночі. Також почали дивитися ceph osd perf і мережеві drop-и перед змінами. Швидкість відновлення — не безкоштовний ресурс; це компроміс із користувачами.

3) Сухо, але правильно, що врятувало день: «noout під час обслуговування — потім відмінили»

Регульована корпорація планово замінювала відмовний диск у Ceph-ноді. Вони зробили нудний ритуал: встановили noout перед вимкненням хоста, записали час початку і призначили відповідального за зняття прапора в кінці.

Під час вікна ще один вузол зазнав короткої мережевої проблеми і втратив OSD. У багатьох середовищах це початок перерозподілу даних і перетворення обслуговування на всюнічний фестиваль backfill. Але з noout встановленим, Ceph не вирішив, що тимчасово відсутній OSD пішов назавжди, тож він не почав важкого переміщення даних, поки вони вже працювали з зменшеною надмірністю.

Відновили мережу, повернули ноду і потім свідомо зняли noout. Кластер вилікувався без драм. Бізнес цього не помітив.

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

Жарт №2: Обслуговування Ceph без чекліста — як гаряча заміна диска з закритими очима: технічно можливо, емоційно дороговартісно.

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

1) Симптом: «HEALTH_WARN nearfull» і продуктивність дивна

Корінь: Один або кілька OSDs nearfull, Ceph обмежує/сповільнює операції, і відновлення може блокуватись через коефіцієнти повноти.

Виправлення: Знайдіть OSDs з найвищим %use (ceph osd df). Негайно зменшіть ріст даних (видаліть/перенесіть снапшоти/ВМ), додайте ємність і виправте дисбаланс (balancer/CRUSH weights). Уникайте «коефіцієнтних хаків», якщо це не тимчасова екстрена міра.

2) Симптом: «1 osds down», але ви одразу помітили out і кластер став повільним

Корінь: Marking out спричинив великий ребаланс на вже зайнятих дисках/меражах.

Виправлення: Якщо OSD може швидко повернутися — підніміть його замість оголошення out. Якщо потрібно оголосити out — обмежте відновлення і плануйте переміщення на період низького навантаження.

3) Симптом: PGs довго застрягають у «peering»

Корінь: Флап OSD, втрата пакетів мережі або розділеність, що ускладнює обмін станом.

Виправлення: Перевірте історію up/down OSD, мережеві drop-и, узгодженість MTU та логи комутаторів. Стабілізуйте мережу спочатку. Випадкові перезапуски OSD часто подовжують peering.

4) Симптом: Slow ops прив’язані до одного OSD

Корінь: Диск того OSD повільний, хост перевантажений або є kernel-level скидання.

Виправлення: Використайте ceph osd perf для підтвердження, потім перевірте dmesg і логи сервісу на хості. Замініть пристрій або виправте шлях. Не «налаштовуйте Ceph», щоб компенсувати помираючий диск.

5) Симптом: Slow ops по багатьох OSDs, особливо під час відновлення

Корінь: Відновлення/backfill насичує мережу або диски. Або мережа сховища втрачає пакети/перевантажена.

Виправлення: Перевірте прогрес відновлення, OSD perf і drop-и NIC. Тимчасово обмежте відновлення, якщо вплив на клієнтів неприйнятний. Виправте мережу, якщо виявлено втрати.

6) Симптом: «MON_CLOCK_SKEW» з’являється час від часу

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

Виправлення: Переконайтеся, що NTP/chrony активні і синхронізовані. Дослідіть CPU steal, навантаження і призупинення ВМ на хостах моніторів. Попередження часу не косметичні; вони корелюють з дивною поведінкою кворуму.

7) Симптом: Помилки scrub або попередження «inconsistent PG»

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

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

8) Симптом: Все виглядає «up», але записи заблоковані

Корінь: Pool min_size занадто суворий для поточних відмов, або кластер досяг порогів повноти, або деякі PGs застрягли undersized.

Виправлення: Перевірте налаштування пулів, пороги заповнення, відновіть відсутні OSDs. Змінюйте min_size лише як усвідомлений ризик, з документуванням і планом.

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

Чекліст A: Перші 5 хвилин (без ризику, лише читання)

Запустіть ceph -s та ceph health detail. Вставте виводи в журнал інциденту.
Підтвердіть кворум: ceph quorum_status. Якщо нестабільний — зупиніться і вирішіть це спочатку.
Подивіться на стан PG: ceph pg stat. Визначте кількість degraded/undersized/peering.
Знайдіть очевидні down OSDs: ceph osd tree.
Перевірте, чи nearfull — по OSD: ceph osd df.

Чекліст B: Наступні 15 хвилин (виявлення вузького місця)

Якщо якийсь OSD down — знайдіть його хост і перевірте systemctl status + journalctl для цього OSD.
Запустіть ceph osd perf. Знайдіть аутлаєри.
Якщо є slow ops — виявте демони: ceph health detail і вибірково ceph daemon osd.X dump_historic_ops.
Перевірте drop-и на мережевих інтерфейсах Ceph: ip -s link. Якщо drop-и ростуть — вважайте мережу підозрілою.
Шукайте забуті флаги: ceph osd dump | grep flags.

Чекліст C: Сходи безпечного втручання (мінімальні зміни)

Відновіть те, чого бракує: підніміть OSDs, якщо апарат дозволяє; виправте проблеми хоста.
Зменшіть біль клієнтів: якщо відновлення нищить латентність, тимчасово обмежте його (і задокументуйте зміни).
Відновіть надмірність: якщо апарат загинув — оголосіть OSD out і почніть заміну, тільки після підтвердження запасу ємності і безпеки домену відмови.
Вирішіть проблему ємності: пріоритет — пом’якшення nearfull до того, як воно стане full; додавайте простір, ребаланс узгоджено, видаляйте дані при потребі.
Ремонт тільки за доказами: scrub-помилки ремонтуйте цілеспрямовано після відновлення стабільності.

Чекліст D: Післяінцидентне загартування (що бажано було зробити заздалегідь)

Створіть алерти, які спрацьовують на degraded/undersized PGs, а не лише на HEALTH_ERR.
Базуйте OSD commit/apply latency і відстежуйте аутлаєри.
Відстежуйте розкид використання по OSD (VAR) і досліджуйте дисбаланс на ранніх стадіях.
Документуйте профілі налаштування відновлення і коли кожен застосовувати.
Стандартизуйтe MTU мережі сховища і валідуйте його наскрізь під час змін.
Робіть «зняття флагів обслуговування» кроком з призначеним власником.

FAQ

1) Чи завжди HEALTH_WARN терміновий?

Ні. Це рівень серйозності, а не діагноз. Деякі попередження інформаційні (наприклад, нещодавні краші демонів, які вже відновилися). Інші — індикатори передвідмови (nearfull, degraded PGs). Ставтеся як до термінових degraded/undersized PGs та slow ops, бо вони корелюють із ризиком і болем користувачів.

2) Чи перезапускати сервіси Ceph при HEALTH_WARN?

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

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

Down означає, що не відповідає. Out означає, що Ceph більше не розміщує дані там і переміщує дані. Down може бути тимчасовим; out — політичне рішення, яке запускає рух даних.

4) Чому nearfull на кількох OSDs має значення, коли кластер має багато вільного місця?

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

5) Який найшвидший спосіб знайти вузьке місце: мережа, диск чи відновлення?

Запустіть ceph health detail (що Ceph скаржиться), ceph osd perf (хто повільний) і ip -s link (чи мережа втрачає пакети). Ці три зазвичай підказують, куди дивитись далі.

6) Чи безпечно змінювати налаштування відновлення під час інциденту?

Так, якщо це тимчасова міра і ви знаєте, навіщо це робите. Зменшуйте паралелізм відновлення, щоб захистити латентність клієнтів; підвищуйте його, щоб зменшити час ризику, коли навантаження низьке і апаратна частина здорова. Завжди фіксуйте зміни і поверніть назад.

7) Що означають «active+clean», «degraded», «undersized» і «peering» насправді?

active+clean: повністю репліковано, обслуговує I/O нормально. degraded: відсутні одна або декілька реплік. undersized: нижче порогу min_size, ризик блокування записів залежно від налаштувань. peering: члени PG домовляються про стан; тривалий peering свідчить про нестабільність.

8) Коли оголошувати OSD out замість намагатися його повернути?

Поверніть, якщо проблема транзитна (перезавантаження хоста, сервіс зупинений, коротка мережєва проблема). Оголосіть out, якщо пристрій/шлях несправні або ви очікуєте тривалий простій, що підвищує ризик. Плануйте навантаження відновлення, якщо оголошуєте out.

9) Чи достатній GUI Proxmox для діагностики Ceph?

GUI підходить для швидкого огляду. Для рішень, що впливають на пересування даних і відновлення, використовуйте CLI Ceph. CLI дає точні типи попереджень, часові мітки і ID демонів, які потрібні.

10) Якщо бачу scrub-помилки, чи ремонтувати відразу?

Спершу стабілізуйте кластер (кворум, мережа, стабільність OSD). Потім визначте неконсистентні PG і ремонтуйте цілеспрямовано. Ремонт під час нестабільності може витратити час і іноді ускладнити ситуацію.

Висновок: наступні кроки, які можна виконати завтра

Коли Proxmox показує Ceph HEALTH_WARN — не сприймайте це як одну проблему і не довіряйте лише кольору. Спробуйте бачити список. Найбезпечніший шлях: зафіксуйте ceph health detail, підтвердіть кворум, визначте degraded PGs та down OSDs, а потім доведіть, чи вузьке місце — диск, мережа чи шторм відновлення.

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

Напишіть односторінковий runbook для чергових, що починається зі Швидкого плейбуку діагностики і містить команди, які ви реально використовуєте.
Додайте сповіщення по degraded/undersized PGs, nearfull OSDs і slow ops, а не лише HEALTH_ERR.
Вирішіть (у спокійному стані), яка політика налаштування відновлення у робочі години і поза ними.
Аудит мережі зберігання: узгодженість MTU, drop-и і помилки портів комутаторів. Ceph вірно підсилює те, що робить ваша мережа.
Плануйте запас ємності. Ceph nearfull — раннє попередження; ставтесь до нього відповідно.

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