Proxmox Ceph: PG stuck/inactive — що робити, поки ризик для даних не зросте

Ментальна модель: що насправді означає “PG stuck/inactive”

В Ceph об’єкти живуть у Placement Groups (PGs). PG сам по собі — не дані; це одиниця розміщення та узгодженості. Кожен PG відображається на наборі OSD
через правила CRUSH. Ceph стежить за станом PG, бо саме так кластер вирішує: «Чи можу я безпечно обслуговувати операції читання/запису?» і «Чи знаю я, хто має останню
версію кожного об’єкта?»

inactive означає, що PG наразі не може обробляти I/O, бо не завершив peering до узгодженого acting set (OSD, які зараз за нього відповідають).
Можливо відсутні OSD, бракує знань про кворум або PG чекає історії. stuck — це попередження за тривалістю:
PG знаходиться в якомусь неідеальному стані (peering, activating, backfilling, undersized, degraded) довше, ніж очікувалося.

Небезпечна пастка — сприймати «inactive» як одну багу. Це не так. Це клас симптомів. Іноді виправлення банальне (повернути OSD, замінити диск,
відновити мережу). Іноді — хірургічне (відкоригувати recovery limits). Іноді — рішення з наслідками (тимчасово зменшити pool size, позначити OSD out,
або, як крайній захід, визнати дані втраченими).

Ваш безпечний операційний принцип: не змінюйте уявлення кластера про дані, поки не з’ясували, чому він не може домовитися. Якщо PG не може
pegar, то зазвичай тому, що якийсь учасник відсутній, неконсистентний або занадто повільний у відповіді. Змушуйте його відповісти або акуратно виводьте з кворуму — і тільки з чіткою оцінкою впливу.

Жарт №1 (короткий і доречний): відновлення Ceph схоже на систему багажу в аеропорту — усе «зрештою консистентно», поки ваш чемодан не залишиться десь невідомо.

Ключові стани PG, які ви побачите в кластерах Proxmox Ceph

• active+clean: цільовий стан.
• active+degraded: I/O працює, але деякі репліки відсутні; recovery намагається виправити.
• active+undersized: acting set має менше OSD, ніж вимагає pool size; ризик зростає.
• peering / activating: триває узгодження; якщо застрягло — щось його блокує.
• backfill_wait, backfilling, recovering: переміщення даних; може бути повільним або заблокованим через throttles/повні диски.
• stale: монітор не отримує оновлень від відповідних OSD; часто причина — мережа або хост не працює.
• incomplete: Ceph не може знайти авторитетні дані для PG; тут слід уповільнитися і подумати.

Що означає «поки ризик для даних не зросте» на практиці

Ризик для даних зростає, коли ви перетинаєте будь-який із цих порогів:

• Кілька OSD впали в одному домені відмов (той самий хост, той самий рід, той самий джерело живлення) для пулів з size 3.
• PG стають incomplete або inactive для пулу, що обслуговує диски VM, а ви продовжуєте записувати або перезавантажувати служби.
• Диски OSD близькі до заповнення, а ви продовжуєте backfill, що створює write amplification і може спричинити помилки BlueStore при виділенні.
• Ви починаєте використовувати руйнівні команди (ceph pg repair, ceph-objectstore-tool, ceph osd lost) без доказів.
• Мони нестабільні щодо кворуму; карти кластера постійно змінюються; PG не можуть заспокоїтися.

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

• PG існують для масштабування метаданих: Ceph уникає рішень на рівні кожного об’єкта, групуючи об’єкти в PG; саме тому кількість PG важлива для продуктивності та відновлення.
• «Peering» — це консенсус-lite Ceph на рівні PG: це не Paxos на кожен об’єкт; це обмін історією на рівні PG, щоб вирішити авторитетний лог.
• CRUSH (корені досліджень 2006 року): розміщення в Ceph базується на детерміністичному алгоритмі, який дозволяє уникати центральних таблиць пошуку.
• Прапори «nearfull/backfillfull/full» у Ceph — це запобіжні бар’єри: вони існують, бо закінчення місця під час відновлення може залишити PG у поганому стані.
• Backfill — не «просто копіювання»: він конкурує з клієнтським I/O, підсилює записи і може виявити приховані проблеми з прошивкою дисків/SSD.
• BlueStore змінив профіль відмов: порівняно з FileStore, BlueStore зменшив подвійні записи, але зробив стан пристроїв (DB/WAL розміщення, затримки) більш видимим.
• Кворум монів — жорстка залежність для карт: навіть якщо OSD «up», нестабільні карти можуть змусити PG постійно проходити peering.
• PG autoscaler існує, бо люди погано рахували PG: ручне тонке налаштування PG спричинило роки інцидентів, особливо після додавання OSD.
• Планування scrub стало операційною дисципліною: scrubs виявляють біторт-типові проблеми, але надто агресивні налаштування scrub можуть зіпсувати вікна відновлення.

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

Коли PGs застрягли/неактивні, вам не потрібні додаткові дашборди. Потрібне чисте дерево рішень.
Мета — визначити вузьке місце, що перешкоджає peering/activation, і чи маєте ви проблему доступності чи ризик цілісності.

Перше: підтвердьте зону впливу та точні стани PG (2 хвилини)

• Скільки PG, які пули та в яких станах?
• Це inactive, stale, incomplete чи просто повільне відновлення?
• Чи монітори в кворумі та стабільні?

Друге: знайдіть відсутніх учасників (5 хвилин)

• Які OSD впали або позначені out?
• Чи впали вони через помилку хоста, помилку диска чи завислу службу?
• Чи є роз’єднання в мережі (серцеві пакети OSD не доходять)?

Третє: перевірте ємність та throttles (5–10 хвилин)

• Чи є OSD близькі до nearfull/backfillfull/full?
• Чи recovery/backfill налаштовано надто консервативно (кластер повільний) або надто агресивно (кластер тоне)?
• Чи є повільні операції, що вказують на конкретний пристрій або вузол?

Четверте: вирішіть стратегію відновлення (і дійте)

• Якщо OSD відновлюваний: поверніть його, дайте peering завершитись, мінімізуйте зміни.
• Якщо диск OSD виходить з ладу: позначте out, замініть і перебудуйте; не перезавантажуйте постійно пристрій у надії, що він стане здоровим.
• Якщо PG incomplete: не імпровізуйте; визначте останні авторитетні OSD, перевірте логи і плануйте ретельно. «Force» — це не стратегія.

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

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

Команди нижче припускають, що ви користуєтесь інтеграцією Proxmox з Ceph (тобто CLI ceph доступний на вузлі з адмін-ключем),
і що OSD/mon/mgr керуються systemd. Підлаштуйте імена хостів/ID під вашу інфраструктуру.

Завдання 1: Отримайте реальне повідомлення про стан (не здогадуйтеся)

cr0x@server:~$ ceph -s
  cluster:
    id:     6c2a6d0c-3a7f-4c50-9c90-2d14c5d1f9aa
    health: HEALTH_WARN
            12 pgs inactive
            4 pgs peering
            1 osds down
            37 slow ops, oldest one blocked for 412 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 17m)
    mgr: pve1(active), standbys: pve2
    osd: 24 osds: 23 up (since 3m), 24 in (since 2h)

  data:
    pools:   4 pools, 512 pgs
    objects: 3.1M objects, 12 TiB
    usage:   36 TiB used, 48 TiB / 84 TiB avail
    pgs:     488 active+clean
             12 inactive
             4 peering

Що це означає: стан health вже підказує, чи це «просто відновлення», чи «ми не можемо безпечно обслуговувати I/O». inactive PGs впливають на доступність.
Лічильник «osds down» підказує про відсутнього учасника; «slow ops» вказує на вузьке місце в продуктивності.

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

Завдання 2: Визначте, які PG застрягли і чому Ceph так вважає

cr0x@server:~$ ceph health detail
HEALTH_WARN 12 pgs inactive; 4 pgs peering; 1 osds down; 37 slow ops
[WRN] PG_AVAILABILITY: 12 pgs inactive
    pg 1.2f is stuck inactive for 611.243 seconds, current state inactive, last acting [3,7,12]
    pg 2.9a is stuck inactive for 603.991 seconds, current state inactive, last acting [5,9,21]
[WRN] PG_DEGRADED: 4 pgs peering
    pg 1.31 is stuck peering for 503.102 seconds, current state peering, last acting [7,12,18]
[WRN] OSD_DOWN: 1 osds down
    osd.12 is down
[WRN] SLOW_OPS: 37 slow ops, oldest one blocked for 412 sec

Що це означає: Тепер у вас є конкретні ID PG та їх останній acting set. Цей acting set — ваш шлях у пошуках причин.
Якщо кілька застряглих PG повторно вказують на один OSD ID, цей OSD зазвичай винуватець (або ж жертва).

Рішення: Сфокусуйтеся на спільних OSD. Не перезапускайте все підряд.

Завдання 3: Виведіть статус PG для одного проблемного PG (подивіться, кого він чекає)

cr0x@server:~$ ceph pg 1.2f query
{
  "state": "inactive",
  "acting": [3,7,12],
  "up": [3,7,12],
  "blocked_by": ["osd.12"],
  "peering_blocked_by": ["osd.12"],
  "info": {
    "last_update": "145'9023",
    "last_complete": "145'9001"
  }
}

Що це означає: Це золото. Показує, що PG не може активуватися, бо osd.12 не бере участі.
Іноді blocked_by відсутнє; тоді дивляться логи peering і продуктивність OSD.

Рішення: Зосередьтесь на відновленні osd.12 або його акуратному виведенні (out), якщо диск невідновний.

Завдання 4: Підтвердьте топологію й стан OSD (up/in/out та прив’язку до хостів)

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         84.00000 root default
-3         28.00000     host pve1
 0   ssd    3.50000         osd.0      up   1.00000  1.00000
 1   ssd    3.50000         osd.1      up   1.00000  1.00000
 2   ssd    3.50000         osd.2      up   1.00000  1.00000
-5         28.00000     host pve2
 3   ssd    3.50000         osd.3      up   1.00000  1.00000
 7   ssd    3.50000         osd.7      up   1.00000  1.00000
12   ssd    3.50000         osd.12    down  1.00000  1.00000
-7         28.00000     host pve3
 5   ssd    3.50000         osd.5      up   1.00000  1.00000
 9   ssd    3.50000         osd.9      up   1.00000  1.00000
21   ssd    3.50000         osd.21     up   1.00000  1.00000

Що це означає: Ви бачите, де живе osd.12 (хост pve2), і чи він просто down або також out.
У цьому прикладі він down, але ще in, і це може блокувати PG, які потребують його для peering.

Рішення: Підключіться до pve2, дослідіть, чому OSD впав, і вирішіть: «рестарт» чи «заміна».

Завдання 5: Перевірте статус служби OSD і останні логи на хості

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

Dec 26 08:14:02 pve2 ceph-osd[11472]: bluestore(/var/lib/ceph/osd/ceph-12) _read_bdev_label failed: (5) Input/output error
Dec 26 08:14:02 pve2 ceph-osd[11472]: OSD:init: unable to mount object store
Dec 26 08:14:02 pve2 systemd[1]: ceph-osd@12.service: Failed with result 'exit-code'.

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

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

Завдання 6: Перевірте шар пристрою (SMART, dmesg). Підтвердіть апаратну проблему.

cr0x@server:~$ ssh pve2 -- sudo dmesg -T | tail -n 12
[Fri Dec 26 08:13:51 2025] blk_update_request: I/O error, dev sdd, sector 129024 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 08:13:51 2025] Buffer I/O error on dev sdd1, logical block 16128, async page read
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] Sense Key : Medium Error [current]
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] Add. Sense: Unrecovered read error

Що це означає: Ядро підтверджує невідновлені помилки читання. Це не налаштування.

Рішення: Вважайте osd.12 як апаратний збій. Позначте його out і плануйте заміну.

Завдання 7: Підтвердьте, що монітори в кворумі і не «флапають» (PG не зможуть заспокоїтись без карт)

cr0x@server:~$ ceph quorum_status
{
  "quorum": [0,1,2],
  "quorum_names": ["pve1","pve2","pve3"],
  "quorum_age": 1052,
  "election_epoch": 94
}

Що це означає: Кворум є і стабільний (quorum_age ~17 хвилин). Добре. Якби кворум «флапав», потрібно було б виправляти це в першу чергу.

Рішення: Продовжуйте з ремедіацією OSD; не женіться за фантомною поведінкою PG, спричиненою мон-хвилюванням.

Завдання 8: Перевірте nearfull/backfillfull/full (ємність може блокувати відновлення)

cr0x@server:~$ ceph df
--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    84 TiB   48 TiB   36 TiB    36 TiB       42.86
TOTAL  84 TiB   48 TiB   36 TiB    36 TiB       42.86

--- POOLS ---
POOL         ID  PGS  STORED   OBJECTS  USED     %USED  MAX AVAIL
rbd          1   256  9.8 TiB  2.1M     29 TiB   60.42  14 TiB
cephfs_data  2   128  2.0 TiB  0.7M     6.0 TiB  12.50  14 TiB

Що це означає: Сира ємність в нормі. Якби ви бачили пул з маленьким MAX AVAIL або сирий майданчик на 85%+, можна очікувати блокування backfill або попередження nearfull.

Рішення: Ємність не є блокером у цій ситуації; продовжуйте з заміною/виведенням OSD.

Завдання 9: Перед маркуванням out перевірте, чи кластер вже деградований і наскільки

cr0x@server:~$ ceph osd stat
24 osds: 23 up, 24 in; epoch: e4123

Що це означає: OSD down, але ще «in», тому Ceph продовжує пробувати його використовувати. Це може блокувати peering залежно від історії PG.

Рішення: Якщо диск мертвий і не повернеться швидко, позначте його out, щоб Ceph перемапив і відновив дані іншде.

Завдання 10: Позначте невдалий OSD out (контрольоване перемапування) і спостерігайте за відновленням

cr0x@server:~$ ceph osd out 12
marked out osd.12.

Що це означає: Ceph почне перемаповувати PG, які мали osd.12 в acting set. Це запускає backfill/recovery.

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

Завдання 11: Перевірте прогрес відновлення і чи виходять PG із inactive/peering

cr0x@server:~$ ceph -s
  cluster:
    health: HEALTH_WARN
            0 pgs inactive
            18 pgs degraded
            52 pgs recovering
            19 slow ops, oldest one blocked for 98 sec
  data:
    pgs:     442 active+clean
             52 active+recovering
             18 active+degraded

Що це означає: Негайна проблема доступності (inactive PGs) зникла. Тепер ви в режимі відновлення. Це краще: I/O працює, ризик зменшено, кластер лікується.

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

Завдання 12: Визначте винуватців slow ops (часто один OSD або один хост)

cr0x@server:~$ ceph health detail | grep -A3 -i slow
[WRN] SLOW_OPS: 19 slow ops, oldest one blocked for 98 sec
    osd.7 has slow ops
    osd.21 has slow ops

Що це означає: Тепер у вас є кандидати для інспекції. Slow ops під час відновлення — звичне явище, але затяжні slow ops можуть гальмувати peering або заважати відновленню.

Рішення: Перевірте OSD perf counters та затримки на хості; не підвищуйте recovery сліпо.

Завдання 13: Перевірте лічильники продуктивності OSD (commit/apply latency)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    7                   11
3    9                   14
7    120                 220
21   85                  160

Що це означає: OSDs 7 і 21 помітно повільніші за інших. Це може бути через диск, насичення мережі або проблеми з DB/WAL.

Рішення: Досліджуйте ці хости перед тонким налаштуванням. Якщо один OSD патологічний, відновлення стоятиме у черзі за ним і PG виглядатимуть «застряглими».

Завдання 14: Швидко перевірте здоров’я мережі (Ceph — розподілене сховище)

cr0x@server:~$ ceph config get osd public_network
10.10.0.0/24

cr0x@server:~$ ssh pve2 -- ping -c 3 10.10.0.11
PING 10.10.0.11 (10.10.0.11) 56(84) bytes of data.
64 bytes from 10.10.0.11: icmp_seq=1 ttl=64 time=0.411 ms
64 bytes from 10.10.0.11: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 10.10.0.11: icmp_seq=3 ttl=64 time=0.405 ms

--- 10.10.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2033ms
rtt min/avg/max/mdev = 0.399/0.405/0.411/0.005 ms

Що це означає: Затримка низька і стабільна на базовому ping. Це не доводить ідеальність мережі, але виключає очевидні роз’єднання.

Рішення: Якщо ping показує втрати або стрибки латентності — зупиніться. Виправте мережу спочатку, інакше «виправлення» Ceph заглибить проблему.

Завдання 15: Огляньте список застряглих PG масово (pattern matching економить час)

cr0x@server:~$ ceph pg dump_stuck inactive
PG_STAT  STATE     UP      UP_PRIMARY  ACTING  ACTING_PRIMARY  LAST_SCRUB  SCRUB_STAMP  LAST_DEEP_SCRUB  DEEP_SCRUB_STAMP

Що це означає: Якщо цей вивід порожній — ви очистили inactive PGs. Якщо ні — список покаже, чи повторюються одні й ті самі OSD IDs.

Рішення: Спільні acting sets вказують на специфічний вузол/OSD; розкидані патерни вказують на мережу/кворум/правила/ємність.

Завдання 16: Перевірте, чи якісь пули неправильно сконфігуровані (size/min_size mismatch може тримати PG unhappy)

cr0x@server:~$ ceph osd pool ls detail
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 256 pgp_num 256 autoscale_mode on
pool 2 'cephfs_data' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 autoscale_mode on

Що це означає: Для реплікованих пулів size — кількість реплік; min_size — мінімум, потрібний для записів.
Якщо min_size занадто високий щодо доступності OSD, ви отримаєте заблоковані записи або нездорові PG під час відмови.

Рішення: Не знижуйте min_size необережно. Це може відновити можливість запису, але підвищить ризик. Виконуйте тільки з усвідомленням ризиків і бізнес-готовністю.

Завдання 17: Переконайтеся, що кластер не в паузі (таке трапляється)

cr0x@server:~$ ceph osd dump | egrep 'pause|noup|nodown|noin|nobackfill|norecover|noscrub|nodeep-scrub'
flags nodown,noin,nobackfill,norecover

Що це означає: Хтось встановив прапори, що запобігають нормальному лікуванню (norecover, nobackfill). Іноді це зроблено під час обслуговування. Іноді забуто.

Рішення: Якщо ви не в контрольованому вікні обслуговування, зніміть прапори. Інакше ваші PG залишаться деградованими/застряглими назавжди.

cr0x@server:~$ ceph osd unset norecover
unset norecover
cr0x@server:~$ ceph osd unset nobackfill
unset nobackfill
cr0x@server:~$ ceph osd unset noin
unset noin
cr0x@server:~$ ceph osd unset nodown
unset nodown

Завдання 18: Якщо конкретний OSD повільний, перевірте насиченість I/O на хості (швидка санітарна перевірка)

cr0x@server:~$ ssh pve2 -- iostat -x 1 3
Linux 6.8.12-pve (pve2)  12/26/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    6.24   18.52    0.00   63.13

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0   310.0  7800.0  21400.0    92.0     8.40   24.10   12.30   28.70   1.20  51.00
sdd              15.0    40.0   800.0   1900.0    84.0    22.10  410.00  380.00  421.00  7.10  98.50

Що це означає: sdd завантажений ~98% з очікуванням ~410 ms. Це однозначно створює slow ops і подовжує відновлення.

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

Завдання 19: Зв’яжіть PG з acting OSD, а потім з хостами (для кореляції відмов)

cr0x@server:~$ ceph pg map 1.2f
osdmap e4123 pg 1.2f (1.2f) -> up [3,7,18] acting [3,7,18]

Що це означає: Після маркування out osd.12 PG перемапувався на новий acting set. Це має усунути умови «blocked_by osd.12».

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

Завдання 20: Лише якщо є доказ метаданкової неконсистентності: спробуйте ceph pg repair (рідко, обережно)

cr0x@server:~$ ceph pg repair 1.31
instructing pg 1.31 on osd.7 to repair

Що це означає: ceph pg repair може допомогти, коли PG застряг через неконсистентність реплік. Але воно також може навантажити CPU і I/O
і погіршити ситуацію, якщо базова проблема — відсутні OSD або зламані диски.

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

Цитата, що допоможе зберегти спокій: Werner Vogels (парафразована думка): «Все ломиться, весь час — проектуйте й експлуатуйте, як ніби це норма.»

Режими відмов, які тримають PGs у застої

1) OSD впав, але ще «in», а PG потребує його для peering

Це найпоширеніший сценарій у Proxmox-on-Ceph: хост перезавантажився, диск помер, контролер скинувся або OSD впав. Ceph позначає його down.
Якщо він залишається «in», деякі PG чекатимуть на нього (особливо якщо він раніше мав авторитетні дані і інші OSD потребують його лог для узгодження).

Правильний крок залежить від кореня проблеми:

• Збой демона, пристрій здоровий: перезапустіть OSD, підтвердіть, що він лишається up.
• Помилки вводу/виводу пристрою: позначте out, замініть, відбудуйте. Не перезавантажуйте помираючий диск постійно — це не зробить його здоровим.
• Хост не в мережі: відновіть хост/мережу/живлення; вирішіть, чи маркувати out залежно від очікуваного MTTR і поточної надмірності.

2) Нестабільність моніторного кворуму спричиняє постійні зміни карт

Якщо монітори не можуть утримувати кворум, карти OSD і мапи PG можуть змінюватися. PG peer-яться, потім знову, і так далі. Ви побачите stuck peering,
але реальна проблема — управління: кластер не може погодитись щодо істини.

Корені включають мережеві розрізи, зсув часу, перевантажені moni, або повільні диски, де живе мон DB. У Proxmox монітори часто запускають на зайнятих вузлах.
Це може працювати — поки не перестає.

3) Nearfull/backfillfull/full блокує переміщення і створює дедлоки

Ceph захищає себе від вичерпання місця, обмежуючи backfill і, у крайніх випадках, записи. Якщо деякі OSD nearfull, CRUSH може продовжити розміщувати дані
на решту, роблячи їх також nearfull. Відновлення сповільнюється, і ваше «виправлення» (додавання навантаження або рестарт) погіршує становище.

Якщо ви близькі до заповнення і маєте inactive PGs, варіанти скорочуються:

• Додайте ємність (найкращий варіант, якщо це можна зробити швидко).
• Видаліть дані (тільки якщо точно знаєте, що видаляєте).
• Тимчасово змініть full ratios (ризиковано; ви міняєте гарантії коректності на час).

4) Неправильне тонке налаштування backfill/recovery, що стало самопошкодженням

Налаштування відновлення — не інструмент для «прискорення». Це компроміси. Якщо recovery надто агресивний, ви можете наситити диски і мережі,
викликати таймаути клієнтів, OSD почнуть виглядати «down» через затримки heartbeat, і PG застрягнуть у peering через перевантаження учасників.

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

5) Один патологічний пристрій (часто DB/WAL) отруює весь кластер

BlueStore використовує RocksDB і WAL. Якщо DB/WAL на спільному SSD, який виходить з ладу або насичується, кілька OSD можуть стати «повільними, але не мертвими».
Це найгірше: усе технічно up, але PG не можуть просунутись достатньо швидко, і slow ops накопичуються.

6) Зміни CRUSH/правил або параметрів пулу створюють несподіванки

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

7) Incomplete PGs: коли Ceph не може знайти авторитетні дані

incomplete — це перетин «інциденту доступності» та «інциденту цілісності даних». Воно може статися, якщо занадто багато OSD, що тримали PG, пішли
(або позначені lost), або якщо залишкові репліки не мають достатньої історії логів для узгодження.

Ваше завдання — визначити, чи:

• Ці OSD можна повернути (найкраще).
• Ви можете відновити з бекапу/снапшоту (часто правильне бізнес-рішення).
• Потрібно визнати дані втраченими для конкретних PG (останній захід, бізнес-рішення, не CLI-рефлекс).

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

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

Середня компанія запускала Proxmox з Ceph на трьох вузлах. Хтось побачив 12 pgs inactive після рутинного оновлення ядра, яке перезавантажило один вузол.
Вони припустили, що «inactive» означає «перебалансування». У тікеті служби підтримки писали «сховище повільне», отже діяли, як з проблемою продуктивності.

Підвищили налаштування recovery: більше backfills, більше одночасних відновлень. Здавалося, що прогрес є — більше I/O, більше мережевого трафіку. Тим часом перезавантажений вузол
підняв NIC з неправильною швидкістю через autoneg, і heartbeat почали втрачатися. OSD флапали, а не падали чисто.

Хибне припущення було тонким: ніхто не помітив, що Ceph може переміщувати дані лише якщо членство стабільне. Зростання recovery-трафіку зробило крихкий NIC ще гіршим:
більше пакетів губились, ще більше OSD виглядали down, ще більше PG намагалися peer-итись. Замкнуте коло.

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

Висновок: inactive PG часто — це проблема членства, а не пропускної здатності. Вирішіть участь (OSD, мережа, кворум) перед тим, як тонко налаштовувати recovery.

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

Велика компанія хотіла швидше відновлюватися після відмов дисків. Їхня команда збільшила паралелізм: більше backfills, більше потоків відновлення, вища пріоритетність recovery.
На папері в лабораторії MTTR зменшився.

У продакшні це співпало з партією SSD з поганою прошивкою в окремих вузлах. Ці SSD не виходили з ладу жорстко; під тривалим записовим навантаженням вони розгорталися в дуже повільний режим.
Звичайний клієнтський I/O був ОК. Recovery-трафік — ні. «Оптимізація» примусила SSD показати найгіршу поведінку: довгі стрибки латентності та інколи скидання.

Коли пристрій почав гальмувати, Ceph робив типову річ для розподіленої системи: повторював, ставив у чергу, пере-peer-ив, логував slow ops. Кластер чекав на кілька пристроїв,
які технічно були живі. PG застрягали в peering і backfill_wait, бо кластер не міг тримати ритм.

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

Висновок: тюнінг recovery має бути обмежений реальною латентністю, а не оптимізмом. Паралелізм — зброя; не направляйте її у власну ногу.

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

Фінансова організація мала сувору дисципліну змін для свого Proxmox Ceph. Це було не гламурно. Вони підтримували runbook і вимагали «знімок стану кластера»
(простіше кажучи ceph -s та ceph health detail в тікеті) до і після обслуговування.

Одного ранку вони побачили pgs inactive після перезавантаження верхньої комутаційної панелі в стійці. On-call дотримувався runbook: перевірив кворум монів, стан OSD,
виявив спільні acting sets і перевірив доступність мережі між Ceph public/cluster мережами. З’ясували, що один VLAN trunk не піднявся коректно.

Тут нудна частина: вони не перезапускали OSD. Не чіпали recovery. Не маркували нічого як втрачене. Вони виправили trunk, чекали стабілізації heartbeat OSD, спостерігали, як PG peer-яться,
і потім моніторили відновлення. Інцидент залишився коротким випадком доступності, а не подією цілісності даних.

Пізніше у постмортемі порівняли це з подібною подією місяців раніше (до наявності runbook), коли хтось помилково швидко позначив OSD out,
спричинивши великий шторм відновлення в робочий час. Runbook не зробив інженерів розумнішими. Він зробив їх менш імпровізаційними.

Висновок: нудні процедури зменшують креативну шкоду. У зберіганні даних креативність часто переоцінена.

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

1) Симптом: «PGs stuck peering» після перезавантаження вузла

Корінь: OSD флапають, бо вузол повернувся з неправильною мережею, невідповідним MTU або проблемами синхронізації часу; peering не стабілізується.

Виправлення: Стабілізуйте вузол: перевірте швидкість/duplex NIC, узгодженість MTU, маршрути/VLAN-и та NTP/chrony. Тільки після цього перезапускайте постраждалі демони OSD, якщо потрібно.

2) Симптом: «PGs inactive» і ceph pg query показує blocked_by osd.X

Корінь: Той OSD down, завислий або надто повільний у відповіді, і потрібен для історії peering.

Виправлення: Якщо відновлюваний: відновіть OSD (сервіс + пристрій). Якщо ні: позначте out і замініть. Не запускайте ceph pg repair щоб компенсувати відсутній OSD.

3) Симптом: Відновлення не починається, PG залишаються degraded, але «все up»

Корінь: Установлені прапори кластера, такі як norecover або nobackfill, були застосовані під час обслуговування і забуті.

Виправлення: Зніміть прапори (ceph osd unset ...). Потім слідкуйте за ceph -s, щоб підтвердити відновлення.

4) Симптом: Під час відновлення вибухають slow ops; OSD починають таймаутити

Корінь: Конкурентність відновлення занадто висока для апаратного/мережевого ресурсу. Heartbeat затримуються, викликаючи флапи OSD і churn peering.

Виправлення: Зменшіть concurrency recovery/backfill. В термінах Proxmox: налаштовуйте консервативно, дивіться ceph osd perf, і надавайте пріоритет стабільності кластера над швидкістю.

5) Симптом: PG застрягли з backfill_wait надовго

Корінь: Або throttles занадто жорсткі, або прихований вузький момент: nearfull OSDs, повільні цільові OSD або мережеві обмеження.

Виправлення: Перевірте ceph df і ceph osd perf. Виправте повільний пристрій або тиск по ємності перед підвищенням backfill-ліміту.

6) Симптом: Inactive/incomplete PG після кількох збоїв дисків на одному хості

Корінь: Невідповідність failure domain. CRUSH думав, що репліки рознесені, але це не так (або хост тримає забагато OSD для цього домену).

Виправлення: Перегляньте failure domain CRUSH (host/rack) і розподіл OSD. Це дизайн-рішення, а не тимчасове залатування. Для інциденту: відновіть відсутні OSD або відновлюйте з бекапу.

7) Симптом: PG застрягли після зміни pool size/min_size або правил

Корінь: Ви змінили правила розміщення, коли кластер вже був нездоровий; перемапування наклалося на відновлення.

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

8) Симптом: Ceph показує «stale» PGs

Корінь: Mons/OSDs не отримують heartbeat (мережевий розріз, зависання хоста або блокування портів Ceph у фаєрволі).

Виправлення: Виправте доступність мережі і здоров’я хоста. Не позначайте stale OSD як lost, якщо ви не готові до постійних втрат даних.

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

Покроковий план для живого інциденту (PG stuck/inactive)

1. Зупиніть ризиковані зміни.
   Припиніть тонку настройку, припиніть «давайте швидко оновимо», припиніть перезапуск демонів, як ніби ви струшуєте торговий автомат.
2. Збережіть поточну істину.
   Запустіть ceph -s і ceph health detail. Збережіть виводи в каналі інциденту/тікеті.
3. Складіть список застряглих PG і визначте спільні acting OSD.
   Використайте ceph health detail і ceph pg dump_stuck inactive.
4. Підтвердьте стабільність мон-кворуму.
   ceph quorum_status. Якщо кворум нестабільний, виправляйте це в першу чергу.
5. Перевірте стан OSD і їхнє розташування.
   ceph osd tree і ceph osd stat.
6. Для підозрілого OSD — перевірте службу + логи + kernel messages.
   Якщо бачите I/O помилки — це апаратна проблема, а не «поганий настрій» софта.
7. Вирішіть: відновлювати чи маркувати out.
   Якщо OSD може повернутись швидко і чисто — відновлюйте. Якщо ні — виведіть і замініть.
8. Спостерігайте за змінами станів PG.
   Перша умова успіху — «немає inactive PGs». Друга — «кількість degraded зменшується».
9. Керуйте навантаженням відновлення, якщо потрібно.
   Якщо slow ops і клієнтські проблеми сильні — зменшіть concurrency. Якщо відновлення надто повільне і кластер стабільний — трохи підвищте. Ніколи не стрибайте з 1 до 11.
10. Після стабілізації виправте корінь проблеми.
    Замініть обладнання, виправте мережу і задокументуйте ланцюг доказів (виводи, логи і рішення).

Чекліст безпеки перед використанням «гострих інструментів»

• Кворум монів стабільний принаймні кілька хвилин (немає швидких виборів).
• Ви можете назвати конкретні PG(и) і конкретні OSD(и), залучені до проблеми.
• Ви перевірили логи пристроїв/ядра на предмет апаратних помилок.
• Ви розумієте вплив pool size та min_size на безпеку даних.
• У вас є план відкату або щонайменше «умова зупинки».
• Зацікавлені сторони поінформовані, якщо ви розглядаєте ceph osd lost або зниження min_size.

Чекліст стабілізації після інциденту

• Зніміть тимчасові прапори: переконайтеся, що немає norecover, nobackfill, noscrub.
• Підтвердьте, що PG у стані active+clean (або у вас є відомий, прийнятний degraded стан з планом).
• Перегляньте OSD perf аутлаєри (ceph osd perf) і замініть/відремонтуйте слабкі пристрої.
• Перевірте синхронізацію часу між вузлами; Ceph не любить проблеми з часом.
• Зафіксуйте: що вийшло з ладу, час виявлення, точки прийняття рішень і що ви змінили.

FAQ

1) Чи одне й те саме «PGs stuck» і «PGs inactive»?

Ні. «Stuck» — тривожний сигнал за тривалістю: PG довго перебуває в якомусь стані. «Inactive» — це стан: PG не може безпечно обслуговувати I/O. inactive — більш критичне.

2) Чи можна просто перезапустити Ceph-сервіси на всіх вузлах?

Можна, але це грубий інструмент і часто приховує корінь проблеми. Якщо причина — помилки I/O диска, мережеві розрізи або нестабільний кворум,
перезапуски можуть подовжити peering і збільшити churn карт. Перезапускайте тільки той компонент, для якого маєте докази.

3) Коли слід маркувати OSD out?

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

4) Який найшвидший спосіб побачити, на що чекає inactive PG?

Почніть з ceph health detail для ID PG і acting set, потім ceph pg <pgid> query. Шукайте blocked_by або peering blockers.

5) Чи треба запускати ceph pg repair, коли peering застряг?

Зазвичай ні. Якщо PG застряг через відсутній OSD або нестабільний кластер, repair не вирішить відсутнього учасника. Використовуйте repair, коли всі необхідні OSD присутні та стабільні і є докази неконсистентності.

6) Що означає active+undersized для дисків моїх VM?

Це означає, що PG активний (I/O може виконуватись), але реплік менше, ніж pool size. Ризик зростає: ще одна відмова у невдалому місці може зробити дані недоступними або втраченими.
Трактуйте це як «їдете на запасному колесі».

7) Чому PG застрягають під час backfill навіть якщо апарат виглядає нормально?

Поширені причини: прапори/throttles (nobackfill, norecover), обмеження nearfull, або один OSD значно повільніший за інших.
Відновлення йде зі швидкістю найповільнішого критичного учасника.

8) Чи безпечно знизити min_size, щоб відкрити записи?

Іноді це оперативно необхідно, але це свідомий ризик. Зниження min_size дозволяє писати з меншою кількістю реплік, що підвищує шанс втрати даних при наступній відмові.
Робіть це документовано, тимчасово і з чітким планом відновлення.

9) Чи часто оновлення Proxmox викликають PG inactive події?

Самі оновлення — не причина; причиною є перезавантаження та рестарти сервісів. Паралельні перезавантаження Ceph-вузлів без перевірки здоров’я кластера — надійний спосіб отримати нові стани PG.

10) Якщо у мене incomplete PGs, що робити спочатку?

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

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

Коли PGs застрягли або inactive, кластер каже, що не може завершити критично важливе узгодження. Ваше завдання — не «заставити попередження зникнути».
Ваше завдання — відновити стабільну участь: кворум, мережу, доступність OSD і здоровий запас ємності.

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

• Кодифікуйте швидкий playbook діагностики в нотатках on-call: ceph -s, ceph health detail, ceph pg query, ceph osd tree, кворум, ємність, perf.
• Відстежуйте та замінюйте повільні пристрої до того, як вони стануть «не зовсім мертвими». Аутлаєри ceph osd perf — ранні попереджувальні сигнали.
• Тримайте налаштування recovery мінімальними і тимчасовими. Якщо змінюєте — зафіксуйте, поставте нагадування і поверніть назад.
• Проектуйте failure domains відповідно до реальності. Рознесення на рівні хоста обов’язкове, коли ваші «хости» ділять живлення або комутатор.
• Практикуйте нудний підхід. Докази, найменша зміна, спостерігайте, повторюйте. Це не героїчно. Воно працює.

Якщо ви запам’ятаєте одну річ: PG inactivity — це перш за все сигнал про коректність, а вже потім про продуктивність. Ставтеся до нього відповідно, і у вас буде менше постмортемів типу «ми підвищили ризик».