Ceph на Proxmox: коли варто, коли це пастка і як правильно підібрати ресурси

Коли Ceph на Proxmox варто використовувати

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

Підходить, якщо виконуються ці твердження

• Вам потрібна HA + live migration у масштабі без великого центрального SAN/NAS.
• Ви можете виділити реальне обладнання (NVMe, CPU, RAM, мережа) під поведінку зберігання, а не лише під ємність.
• Ви очікуєте відмов (диск на місяць, вузол на квартал) і хочете, щоб кластер їх витримав.
• Ви можете запустити щонайменше три вузли (а краще більше) з узгодженим апаратним забезпеченням та мережами.
• Ваше навантаження — переважно VM-диски (RBD) з розумними IO-патернами, а не хаотичні дрібні синхронні записи.
• У вас є дисципліна ops: моніторинг, вікна обслуговування, контроль прошивок і людина, відповідальна за здоров’я сховища.

Що Ceph дає, і що важко підробити

Справжня цінність не в «розподіленому сховищі». Це передбачувана стійкість до відмов і операційна еластичність.
Коли додаєте вузли — додаєте ємність і продуктивність. Коли вузол помирає — дані залишаються. Коли диск виходить — ви замінюєте і Ceph лікує. За правильного налаштування це нудно — у найкращому сенсі.

Якщо потрібно правило в одній фразі: Ceph вартий того, коли ви хочете, щоб сховище відмовляло як сервіс, а не як пристрій.

Коли це пастка (і що робити замість цього)

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

Червоні прапорці, які зазвичай означають «не ставте Ceph тут»

• Два вузли або «додамо третій пізніше». Ceph потребує кворуму і доменів відмов; «пізніше» — не дизайн.
• 1GbE або «трафік сховища й VM йде через дешевий комутатор». Відновлення з’їсть всю мережу.
• Змішане апаратне забезпечення, де половина вузлів — старі, половина — нові. Найповільніші OSD задають тон під час відновлення.
• Бюджет, орієнтований на ємність: багато HDD, крихітні SSD, мінімум RAM, мінімум CPU.
• База даних з важкими записами з fsync-штурмами або додатки з синхронними записами на транзакцію без батчування.
• Немає оператора. Якщо ніхто не відповідає за зберігання, то рано чи пізно кластер заволодіє вами.

Що робити замість цього (реалістичні альтернативи)

• Лаб для одного вузла або невеликого кластера: ZFS на кожному вузлі, реплікація через ZFS send, прийміть, що live migration не безкоштовна.
• Два вузли у продакшні: використовувати шарований SAN/NAS або третій легкий witness-вузол для кворуму (але не підробляйте Ceph).
• Бази з критичною затримкою: локальний NVMe з реплікацією на рівні додатка; або виділене сховище-пристрій.
• Обмежений бюджет: менше, але потужніших вузлів краще ніж багато слабких. Ceph не винагороджує «більше мотлоху».

Жарт №1: Ceph на 1GbE — чудовий спосіб навчитися терпінню, усвідомленості і пояснювати «eventual consistency» розлюченим людям.

Як Ceph поводиться під навантаженням VM

Proxmox зазвичай використовує RBD для VM-дисків. Це означає, що ваші читання й записи VM перетворюються на операції над об’єктами
в рамках placement groups (PGs), розподілених по OSDs, і реплікованих (або захищених erasure coding) по доменах відмов.
Це елегантно. Це також нещадно: кожен запис стає множинними записами.

Репліковані пули: за замовчуванням не просто так

Реплікований пул з size=3 записує дані на три OSDs. Ваш «1GB запис» — це три записи плюс метадані.
Перевага — низька read amplification і проста логіка відновлення. Для VM-дисків репліковані пули залишаються розумним дефолтом.

Erasure coding: красиво на папері, складно на практиці

Erasure coding економить корисну ємність, але збільшує витрати CPU, мережевий трафік і ампліфікацію дрібних записів.
Він підходить для великих послідовних навантажень. Для завантажувальних дисків VM і випадкових записів це часто перетворюється на машину затримок.
Використовуйте EC-пули обережно, зазвичай для холодних даних, резервних копій або об’єктних патернів — не як основне сховище для VM.

BlueStore, WAL/DB і «податок на дрібні записи»

Сучасний Ceph використовує BlueStore (не FileStore). BlueStore має власні метадані (RocksDB) і використовує WAL.
На HDD OSDs бажано розміщувати ці DB/WAL компоненти на SSD/NVMe, інакше ви платите латентністю за кожну операцію, що багато працює з метаданими.
На all-flash OSDs тримати DB/WAL на тому ж пристрої — нормально; розділення може допомогти, але не обов’язкове.

Затримка важливіша за пропускну здатність для віртуалізації

Диски VM домінуються дрібними випадковими IO, оновленнями метаданих і поведінкою fsync залежно від гостьової ОС.
Якщо ви дивитесь лише на «GB/s», ви побудуєте кластер, що добре бенчмаркується і почуватиметься жахливо.
Важливіше: p95 latency під час нормальної роботи і під час відновлення.

Одна цитата, тому що операції зберігають чеки

переказана ідея — Gene Kranz: «міцні та компетентні» системи народжуються через дисципліну і підготовку, а не через оптимізм.

Факти та історичний контекст (бо Ceph не з’явився випадково)

• Ceph починався як дослідницький проєкт в UCSC у середині 2000-х, зосереджений на усуненні централізованих вузьких місць метаданих.
• Алгоритм CRUSH був розроблений, щоб уникати таблиць пошуку і масштабу розміщення без центрального координатора.
• RADOS — це справжній шар продукту; block (RBD), file (CephFS) і object (RGW) — це «клієнти» зверху нього.
• BlueStore замінив FileStore, щоб уникнути подвійного журналювання через POSIX-файлову систему і покращити стабільність продуктивності.
• CephFS вимагав стабільної поведінки metadata server; пройшли роки, перш ніж його визнали продакшн-рішенням у консервативних середовищах.
• Proxmox інтегрував Ceph глибоко, щоб зробити гіперконвергентне сховище доступним без окремого стеку постачальника.
• Placement groups існують, щоб пакетувати розміщення об’єктів; замало PGs створює вузькі місця, замало — підвищує накладні витрати.
• Стани здоров’я Ceph (HEALTH_OK/WARN/ERR) навмисно різкі, щоб оператори не ігнорували «дрібні» проблеми до реальних збоїв.

Підібрати ресурси чесно

Підбір ресурсів для Ceph — це узгодження тolerancії до відмов, цілей по затримці і часу відновлення.
Ємність — найлегша і найзаверена частина. Правильний шлях — працювати назад від навантаження.

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

Коли вузол помирає, Ceph почне backfill/rebalance. Це означає багато читань із живих OSDs і записи на інші.
Ваш кластер має пережити це так, щоб IO VM залишався терпимим. Якщо ви підбираєте розміри лише під «щасливий шлях», відновлення стане простою відмовою.

Кількість вузлів: три — мінімум; п’ять — коли стає по-справжньому

• 3 вузли: працює, але домени відмов щільні. Тиск відновлення інтенсивний; обслуговування напружене.
• 4 вузли: краще, але все ще незручно для деяких CRUSH-розкладок і планування обслуговування.
• 5+ вузлів: плавніше відновлення, простіше виводити вузли з експлуатації, кращий розподіл PGs і IO.

Мережа: ставте її як шасі зберігання, а не «просто Ethernet»

Для Ceph на Proxmox мережа — це шасі. При нормальному IO ви штовхаєте реплікаційний трафік. Під час відновлення йде шторм.
Якщо мережа недостатня, усе перетвориться на «рандомні затримки» і почнеться гра у звинувачення.

• Мінімально життєздатно: 10GbE, бажано виділена або VLAN-розділена публічна/кластерна траса.
• Комфортно: 25GbE для змішаних навантажень або 10GbE для невеликих all-flash кластерів з акуратним тюнінгом.
• Комутатори: non-blocking, без болючих маленьких буферів, однаковий MTU і без «таємних» QoS-політик.

OSD-носії: all-flash простіше; HDD потребують допомоги SSD/NVMe

Якщо ви запускаєте VM-сторедж на HDD OSDs, ви обираєте світ, де випадкова латентність запису — ваш постійний супутник.
Це можна робити придатним, маючи SSD/NVMe для DB/WAL, достатньо шпінделів і реалістичні очікування. Але не прикидайтеся, що це буде як SAN flash.

Емпіричні профілі апаратного забезпечення (практично, а не теоретично)

• Малий all-flash VM кластер (3–5 вузлів): 8–16 NVMe на вузол або кілька більших enterprise NVMe; 128–256GB RAM; 16–32 ядра; 25GbE, якщо можливо.
• Гібрид (HDD для ємності + SSD для метаданих): 8–16 HDD на вузол плюс 1–2 NVMe для DB/WAL; 128GB+ RAM; 25GbE настійно рекомендується.
• «Ми знайшли диски у шафі»: не варто.

CPU і RAM: Ceph із задоволенням використає те, що ви йому відмовляєте

OSDs споживають CPU на контрольні суми, стиснення (якщо увімкнено), EC-математику (якщо використовується) і загальні IO-пайплайни.
MONs і MGRs потребують пам’яті, щоб тримати карти кластера і обслуговувати клієнтів без блокувань.

• RAM: плануйте для пам’яті OSD + накладні витрати хоста + Proxmox. Голодний хост викликає джиттер, який виглядає як «мережа» чи «баг Ceph».
• CPU: не робіть overcommit настільки, щоб потоки OSD були зачащені під навантаженням VM. Спайки латентності — симптом.

Математика ємності, що відповідає реальності

Для реплікованих пулів корисна ємність приблизно: raw / replica_size, мінус накладні витрати.
Replica size 3 означає приблизно одну третю корисної ємності. Додайте резерв: Ceph потребує місця для переміщення даних під час відмови і відновлення.

• Ціль: тримайте пули під ~70–75% заповненості в steady state, якщо цінуєте свої вихідні дні.
• Чому: відновлення і backfill потребують вільного простору по OSDs; майже повні кластери підсилюють біль при ребалансі і ризик.

Розрахунок IOPS і латентності: незручна частина

Ви підбираєте Ceph, розуміючи IO-патерни:

• Дрібні випадкові записи: карають HDD-кластери і недопрацьовані мережі.
• Синхронні записи (fsync): виявляють журнал/WAL і затримку пристрою; гості з базами даних можуть домінувати поведінку кластера.
• Читання: зазвичай легші, але холодні кеші й відновлення теж можуть нашкодити.

Якщо ви не можете виміряти навантаження, припускайте, що воно гірше, ніж здається. Продакшн-навантаження завжди такі.

Рішення щодо пулів, CRUSH і розміщення даних

Розмір реплікованого пулу: оберіть відмову, яку хочете пережити

Більшість розгортань Proxmox використовують size=3, min_size=2. Це зазвичай переживає одну відмову вузла без переходу в режим лише читання.
Падіння до size=2 спокушає заради ємності. Це також пониження надійності, яке часто призводить до несподіваної відмови при другому збоях.

Домени відмов: вузол, шасі, стійка

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

Кількість PG: не тягніть налаштування як у 2016

Існує PG autoscaling недарма. Все одно потрібно розуміти тиск PG:
замало PGs створює «гарячі точки»; надто багато може перевантажити пам’ять і CPU OSDs.
Користуйтеся autoscaler, а потім перевіряйте розподіл і продуктивність здоровим глуздом.

Розділяйте пули за класом продуктивності, а не за відчуттями

• Швидкий пул: all-flash NVMe OSDs для VMs з вимогливою латентністю.
• Пул ємності: HDD+SSD DB/WAL для масивного зберігання, менш чутливих навантажень.
• Не змішуйте: один повільний клас OSD у пулі тягне клієнтський IO під час відновлення і PG peering.

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

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

Завдання 1 — Підтвердьте здоров’я кластера і справжній заголовок

cr0x@server:~$ ceph -s
  cluster:
    id:     2c8c8b9a-1c61-4a9f-9a19-4c0d7cfe2a91
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops

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

  data:
    pools:   2 pools, 256 pgs
    objects: 1.12M objects, 4.3 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     254 active+clean
             2  active+remapped+backfilling

Значення: Не «все зламалося». Один OSD має slow ops і триває backfill.

Рішення: Розцінювати скарги на продуктивність як очікувані під час backfill; дослідити, чому osd.7 повільний (диск, CPU, мережа).

Завдання 2 — Перевірте, чи відбувається recovery/backfill

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops; 2 pgs backfilling
SLOW_OPS 1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops
PG_BACKFILLING 2 pgs backfilling

Значення: Є активність відновлення; клієнтська латентність може стрибнути.

Рішення: Визначте, чи треба тимчасово обмежити recovery або переждати; перевірте, чи backfill очікуваний (нещодавній рестарт OSD, заміна диска).

Завдання 3 — Визначити, який OSD винуватець (або жертва)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
  0                  6                 7
  1                  5                 6
  7                120               145
  8                  7                 8

Значення: osd.7 значно повільніший за колег; це не «Ceph повільний», а «один компонент повільний».

Рішення: Дослідити здоров’я диска, насичення або мережеві помилки на хості osd.7; розглянути виведення його з кластеру, якщо шкодить.

Завдання 4 — Перевірити дерево OSD і відповідність топології реальності

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         34.00000 root default
-3         11.33333     host pve1
 0    ssd   1.33333         osd.0      up   1.00000  1.00000
 1    ssd   1.33333         osd.1      up   1.00000  1.00000
 2    ssd   1.33333         osd.2      up   1.00000  1.00000
-5         11.33333     host pve2
 7    ssd   1.33333         osd.7      up   1.00000  1.00000
 8    ssd   1.33333         osd.8      up   1.00000  1.00000
 9    ssd   1.33333         osd.9      up   1.00000  1.00000

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

Рішення: Якщо один хост має менше OSDs/ваги, очікуйте «гарячі точки»; плануйте розширення або reweighting.

Завдання 5 — Перевірити стан PG autoscaler

cr0x@server:~$ ceph osd pool autoscale-status
POOL     SIZE  TARGET SIZE  RATE  RAW CAPACITY  RATIO  TARGET RATIO  PG_NUM  NEW PG_NUM  AUTOSCALE
rbd         3            -   3.0       34 TiB   0.65             -     128         192  on
cephfs      3            -   3.0       34 TiB   0.10             -     128          64  on

Значення: Autoscaler пропонує для rbd більше PGs (більше паралелізму), тоді як cephfs може мати менше.

Рішення: Приймайте зміни autoscaler у спокійні періоди; уникайте масового churn PG під час інцидентів.

Завдання 6 — Перевірити налаштування пулу, що впливають на латентність VM

cr0x@server:~$ ceph osd pool get rbd size
size: 3
cr0x@server:~$ ceph osd pool get rbd min_size
min_size: 2
cr0x@server:~$ rbd pool stats rbd
Total Images: 124
Total Snapshots: 37
Provisioned Size: 19.7 TiB
Total Used Size: 6.2 TiB

Значення: Реплікація встановлена для типової HA. Provisioned vs used допомагає помітити ризик thin-provisioning.

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

Завдання 7 — Перевірити стан мережі на Ceph-інтерфейсах

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123489123  8123492       0        3       0      0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    8451239912  7923341       0        0        0      0

Значення: Помилок немає; кілька drop можуть бути допустимі, але зростаючі дропи під навантаженням можуть означати перевантаження або проблеми з буферами.

Рішення: Якщо errors/drops зростають — припиніть звинувачувати Ceph і почніть налагоджувати порти комутатора, MTU або насичення.

Завдання 8 — Підтвердити консистентність MTU (мовчазний вбивця)

cr0x@server:~$ ip link show eno2 | grep mtu
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000

Значення: Інтерфейс має jumbo MTU. Це добре тільки якщо весь шлях це підтримує.

Рішення: Якщо деякі вузли 1500, а деякі 9000 — оберіть одне й стандартизуйте; неконсистентний MTU дає дивні затримки і фрагментацію.

Завдання 9 — Перевірити насичення IO на хості (чи диск завантажений?)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   980.0  2400.0  8820.0   2.1   0.3   34.0
sdb              10.0   320.0   160.0  5120.0  48.0   2.5   98.0

Значення: sdb майже 100% завантажений з високим await. Якщо це OSD-пристрій — він викликає slow ops.

Рішення: Якщо HDD OSDs насичені, зменшіть швидкість відновлення, перемістіть «гарячі» навантаження на флеш-пул, або додайте шпінделі/вузли.

Завдання 10 — Інспектувати конкретний демон 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: active (running) since Sun 2025-12-28 08:12:11 UTC; 2h 3min ago
   Main PID: 23871 (ceph-osd)
      Tasks: 92
     Memory: 5.1G
        CPU: 1h 12min
     CGroup: /system.slice/system-ceph\x2dosd.slice/ceph-osd@7.service
             └─23871 /usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph

Значення: OSD запущено; використання пам’яті видно. Це не доводить, що він здоровий, але виключає «він впав».

Рішення: Якщо CPU-час низький, а латентність висока — підозрюйте диск або IO-wait; перевіряйте логи і статистику пристрою.

Завдання 11 — Шукати проблеми на рівні ядра з диском

cr0x@server:~$ dmesg -T | tail -n 8
[Sun Dec 28 09:55:14 2025] blk_update_request: I/O error, dev sdb, sector 219902314
[Sun Dec 28 09:55:14 2025] Buffer I/O error on dev sdb, logical block 27487789, async page read
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Sense Key : Medium Error [current]
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Add. Sense: Unrecovered read error

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

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

Завдання 12 — Безпечно вивести OSD, коли він шкодить кластеру

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

Значення: Ceph почне переміщувати дані з osd.7, щоб відновити бажаний стан реплікації.

Рішення: Моніторьте вплив backfill. Якщо кластер не витримує відновлення без «плавлення», ваша оцінка розмірів маргінальна.

Завдання 13 — Спостерігати обмеження recovery/backfill і тонко налаштовувати

cr0x@server:~$ ceph config get osd osd_max_backfills
1
cr0x@server:~$ ceph config get osd osd_recovery_max_active
3

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

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

Завдання 14 — Перевірити «nearfull» до того, як воно стане «full»

cr0x@server:~$ ceph df
--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    34 TiB   21 TiB   13 TiB     13 TiB     38.25
TOTAL  34 TiB   21 TiB   13 TiB     13 TiB     38.25

--- POOLS ---
POOL  ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd    1  128  4.1TiB  950k     12.3TiB  57.0     6.2TiB
cephfs 2  128  0.2TiB  170k     0.6TiB    2.8     6.2TiB

Значення: Raw-статистика виглядає добре, але важливий %USED саме пулу для його ефективної ємності.

Рішення: Якщо rbd підходить до 70–75% — плануйте розширення; не працюйте дуже близько до повного і очікуйте безболісного відновлення.

Завдання 15 — Підтвердити, що Proxmox бачить і використовує Ceph datastore правильно

cr0x@server:~$ pvesm status
Name     Type     Status    Total     Used     Avail    %
local    dir      active   1.8T     220G     1.6T   12.0%
ceph-rbd rbd      active   6.2T     3.5T     2.7T   56.0%

Значення: Плагін Proxmox показує ємність і використання; невідповідність може вказувати на проблеми з auth/config.

Рішення: Якщо Proxmox показує «unknown» або «inactive», виправте конфігурацію клієнта Ceph перед тим, як ганятися за духами продуктивності.

Швидкий план діагностики (знайдіть вузьке місце без тижневих зборів)

Це порядок, що економить час. Не завжди. Але достатньо часто, щоб стати м’язовою пам’яттю.

Перше: кластер здоровий чи відновлюється?

• Запустіть ceph -s і ceph health detail.
• Якщо бачите backfill/recovery/peering — прийміть, що продуктивність погіршена, і вирішіть, обмежувати чи чекати.
• Якщо бачите slow ops — ідентифікуйте OSDs через ceph osd perf.

Друге: чи один хост або диск тягне всіх вниз?

• На підозрюваному хості: iostat -x для %util/await.
• Перевірте логи ядра: dmesg -T на предмет IO-ошибок/штормів reset.
• Перевірте SMART, якщо доступно (зазвичай через інструменти вендора).
• Якщо пристрій виходить з ладу — виведіть OSD і замініть; не домовляйтеся з фізикою.

Третє: мережа бреше?

• Перевірте лічильники: ip -s link (errors/drops).
• Підтвердьте MTU: ip link show.
• Шукайте конгестію: піки під час backfill нормальні; постійні дропи — ні.

Четверте: проблема в налаштуванні пулу/клієнта?

• Підтвердьте налаштування реплікації пулу і PG autoscaler.
• Перевірте, чи не використовували ви EC-пули для VM-дисків (поширена самостійна рана).
• Валідуйте конфігурацію Proxmox і що клієнти потрапляють у правильну мережу.

П’яте: чи просто недопідібрано?

Якщо всі компоненти «здорові», але латентність все ще погана під нормальним навантаженням, можливо ваш кластер просто не має достатньо
IOPS, CPU або мережі. Це момент чесності: тюнінг не перетворить HDD на NVMe.

Жарт №2: Налаштовувати недопідібраний Ceph — як переставляти стільці на палубі — тільки стільці горять, а корабель — ваш SLA.

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

1) «Усе повільніє, коли вузол відключається»

Симптоми: спайки латентності, тайм-аути VM, Proxmox тупить під час заміни диска або перезавантаження вузла.

Корінь: recovery/backfill насичує мережу або OSDs; кластер розрахований лише на «щасливий шлях».

Виправлення: збільшити кількість вузлів і пропускну здатність мережі; обмежувати recovery у робочі години; тримати запас (залишатися під ~75%).

2) «Випадкові уповільнення, без очевидних помилок»

Симптоми: випадкові затримки 5–30с, HEALTH_WARN зі slow ops, потім зникає.

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

Виправлення: використайте ceph osd perf для ідентифікації, перевірте dmesg, замініть нестабільні диски; не змішуйте споживчі SSD.

3) «Ceph повний, але df каже є місце»

Симптоми: пул досягає nearfull/full, записи блокуються, незважаючи на «raw» ємність.

Корінь: ефективна ємність пулу обмежена реплікацією і розподілом; нерівномірне заповнення OSDs; oversold thin provisioning.

Виправлення: розширюйте до того, як пули перевищать безпечні пороги; ребаланс ваг; впроваджуйте квоти і дисципліну provisioning.

4) «Великі бенчмарки пропускної здатності, жахливий досвід VM»

Симптоми: послідовні тести виглядають добре; реальні навантаження відчуваються повільними; p95 latency погано.

Корінь: бенчмарки не відображають дрібний випадковий IO + fsync; HDD/гібрид без достатнього SSD DB/WAL; голод по CPU.

Виправлення: вимірюйте латентність; перемістіть VM-диски в all-flash пул; забезпечте належне планування CPU для OSDs; не оверкоммітьте вузли зберігання.

5) «Ми використали erasure coding для VM-дисків, щоб заощадити місце»

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

Корінь: EC дає ампліфікацію дрібних записів і обчислювальні витрати; несумісно з IO-патернами VM-дисків.

Виправлення: використовуйте репліковані пули для VM-дисків; EC — для великих об’єктів і менш чутливих навантажень.

6) «Ceph постійно втрачає кворум / MONs скаржаться»

Симптоми: MONs втрачають кворум, кластер зупиняється, дивні помилки під піком трафіку.

Корінь: перевантажені або недопідібрані MON вузли, нестабільна мережа, або розміщення MONs на вузлах, що голодні через VM-навантаження.

Виправлення: забезпечте три MONs на стабільних вузлах; зарезервуйте CPU/RAM; ізолюйте мережу; не запускайте MONs на найбільш навантажених гіпервізорах.

7) «Backfill ніколи не закінчується»

Симптоми: тижні remapped/backfilling PGs, постійні degraded стани після невеликих змін.

Корінь: мало вільної ємності, замало пропускної здатності, або занадто агресивні зміни (додавання/видалення багатьох OSDs одночасно).

Виправлення: плануйте зміни; додавайте ємність порціями; обмежуйте recovery; уникайте роботи поруч з повним; збільшуйте мережу.

Три корпоративні міні-історії (анонімізовані, правдоподібні та болісно знайомі)

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мігрувала з одного хоста з локальними SSD у три-вузловий Proxmox кластер з Ceph.
Припущення було просте: «У нас три вузли, отже маємо HA. Це буде щонайменше так само швидко.»
Ніхто не сказав вголос «реплікація додає записи». Ніхто не робив тестів відмов під реальними навантаженнями.

Перше планове перезавантаження сталося у вівторок вранці. Один вузол пішов на оновлення прошивки. Ceph зробив те, що Ceph робить:
почав backfill, щоб зберегти реплікацію. Латентність VM зросла, потім зросла ще, потім служба підтримки почала отримувати тікети
з темами, написаними великими літерами.

Винуватили Proxmox, потім Ceph, потім мережу. Правда була нудною: 10GbE ділився з клієнтським трафіком,
а OSDs були SATA SSD, що виглядали добре в одновузловому сценарії, але розвалювалися під реплікованими випадковими записами плюс відновлення.
Неправильне припущення було не «Ceph швидкий». Воно було «Ceph веде себе як локальне сховище, тільки спільне».

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

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

Інша організація мала all-flash Ceph кластер, який «працював», але не вражав. Хотіли кращу ефективність ємності.
Хтось запропонував erasure coding для основного VM-датастору. Таблиці в Excel були прекрасні.
План міграції був чистим. Заява в change ticket — впевнена. Небезпека в корпоративному вигляді.

Спочатку це спрацювало. Корисна ємність зросла. Потім почалися скарги на продуктивність — спочатку тонкі, потім постійні.
Гірше було не середнє значення латентності; гірше — хвостова латентність. Додатки затримувалися коротко, потім відновлювалися. Користувачі описували це як «липке».

Під капотом дрібні випадкові записи страждали від EC-ампліфікації записів і додаткових обчислювальних витрат.
Під час відновлення мережа і CPU різко підскакували в спосіб, який команда не прорахувала. Кожний дрібний інцидент перетворювався
на тривалий період деградованої продуктивності.

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

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

Команда фінансових послуг працювала на п’яти-вузловому Proxmox+Ceph кластері. Нічого екзотичного: репліковані пули, 25GbE, консистентні NVMe,
консервативні налаштування відновлення. Їх секретна зброя — не залізо. Процес.

Вони мали маленьку щотижневу звичку: переглядати Ceph health, перевіряти OSD latency outliers і дивитися тренди заповнюваності пулів.
Також правило: оновлення прошивки сховища і kernel-апдейти відбувалися в контрольованих вікнах обслуговування, по одному вузлу,
з чекпоінтом «зупинитися, якщо відновлення агресивне».

Якось тижнем раніше вони помітили один OSD, що повільно наростав у commit/apply latency. Ще без помилок. Просто «інакший».
Вони вивели його під час тихого вікна, замінили диск, дали кластеру вилікуватися і пішли далі. За два дні в іншому середовищі
диск тієї самої моделі почав кидати read errors і спричинив інцидент, видимий клієнтам.

Їхній крах був не подією, бо вони ставили «трохи дивно» у список завдань, а не як цікавинку. Практика була нудною.
Результат — елітний.

Контрольні списки / план крок-за-кроком

Чеклист рішення: чи варто запускати Ceph на Proxmox?

• Чи маєте ви щонайменше 3 вузли зараз (не «скоро»)? Бажано 5+?
• Чи маєте ви мінімум 10GbE, ідеально 25GbE, з адекватними комутаторами?
• Чи можете тримати steady-state заповнення під ~70–75%?
• Чи є в вас узгоджене апаратне забезпечення між вузлами?
• Чи є у вас людина-власник стану сховища (алерти, обслуговування, апгрейди)?
• Чи приймаєте ви, що відновлення відмови — це подія продуктивності, яку треба бюджетувати?

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

1. Виберіть кількість вузлів і домени відмов. Вирішіть, чи «вузол» достатній або потрібен рівень стійки.
2. Обирайте швидкість мережі і топологію. Логічно розділяйте трафік Ceph (VLAN) і, якщо можливо, фізично.
3. Виберіть клас носіїв для кожного пулу. Не змішуйте HDD і NVMe в одному перформанс-пулі.
4. Встановіть репліковані пули для VM-дисків (size=3, min_size=2 — типовий вибір). Будьте явними в мотивації.
5. Увімкніть PG autoscaler і періодично переглядайте запропоновані зміни PG.
6. Описати алерти на: HEALTH_WARN/ERR, slow ops, nearfull/full, MON quorum changes, OSD flaps, disk errors.
7. Документуйте поведінку відновлення: що таке «нормальне деградоване» і коли треба обмежувати recovery.

Чеклист операцій: щотижня, щоб уникнути драм

• Перегляньте ceph -s і ceph health detail.
• Перевірте ceph osd perf на предмет аутлаєрів і досліджуйте по одному на тиждень.
• Переглядайте тренди ємності з ceph df і використання Proxmox storage.
• Підтверджуйте відсутність сплесків помилок/drops на NICs сховища.
• Робіть одне контрольоване обслуговування за раз (одне перезавантаження хоста, одна заміна OSD), а потім спостерігайте.

Чеклист розширення: додавання вузлів/OSDs без хаосу

1. Підтвердіть наявність запасу для backfill (місце і пропускна здатність).
2. Додавайте невеликими партіями, щоб відновлення не роздавило клієнтський IO.
3. Слідкуйте за станами PG і продуктивністю OSD під час ребалансування.
4. Після відновлення перевірте заповненість пулів і розподіл PG.
5. Потім переходьте до наступної партії.

FAQ

1) Яка мінімальна кількість вузлів для Ceph на Proxmox?

Три вузли — мінімум для справжнього кластера з кворумом і реплікованим сховищем. П’ять вузлів — коли технічне обслуговування і відновлення перестають бути трюком.

2) Можу я запускати Ceph на 1GbE, якщо навантаження невелике?

Можна, але ймовірно не варто. Навіть у дрібних кластерах бувають події відновлення, і 1GbE перетворює відновлення в «все повільно».
Якщо мусите, знизьте очікування і уникайте обіцянок HA.

3) Потрібні окремі мережі для public і cluster traffic?

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

4) Чи варто використовувати CephFS для VM-дисків?

Для VM-дисків на Proxmox зазвичай правильний вибір — RBD. CephFS чудовий для шарених файлових навантажень, але не заміна блочних семантик.

5) Реплікація size 2 проти 3: чи прийнятна size 2?

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

6) Чи потрібно використовувати erasure coding, щоб зекономити місце?

Використовуйте EC, коли навантаження підходить: великі об’єкти, низька чутливість до латентності і ви готові платити CPU/мережею.
Для основного VM-датастору репліковані пули — частіше правильний вибір.

7) Наскільки заповнений — «занадто заповнений» для Ceph?

Ставте ~70–75% як межу «почати планувати розширення» для реплікованих VM-пулів.
Після цього відновлення стає повільнішим і ризикованішим, і зрештою ви стикнетеся з обмеженнями backfill.

8) Чому продуктивність гірша під час rebuild, навіть якщо кластер здоровий?

Бо rebuild споживає ті самі ресурси, що й клієнти: диск IO, CPU і мережу.
Здоровий кластер може бути зайнятий. Ви підбираєте і тюните під прийнятну деградацію під час відновлення, а не під ідеал.

9) Чи можна змішувати різні моделі SSD або покоління вузлів?

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

10) Який перший метрик дивитися, коли «Ceph здається повільним»?

ceph osd perf для commit/apply latency-аутлаєрів, плюс перевірка, чи кластер backfilling. Один повільний OSD може отруїти весь досвід.

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

1. Запустіть швидкий план діагностики наступного разу, коли хтось поскаржиться. Збережіть ceph -s, ceph osd perf і host iostat.
2. Визначте свій бюджет відмов: наскільки погано може бути під час відновлення, щоб це було «прийнятно»?
3. Усуньте великі проблеми спочатку: пропускна здатність мережі, консистентні носії і запас ємності. Тюнінг — потім.
4. Розділіть пули за класом продуктивності і припиніть змішувати повільні й швидкі пристрої в одному VM-датасторі.
5. Інституціоналізуйте нудні перевірки: тижневий огляд здоров’я, пошук аутлаєрів, відстеження трендів ємності і політика «одна зміна за раз».

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