Сховище Proxmox: Ceph проти ZFS — Дерево рішень, яке ніхто вам не показує

Ви не відчуваєте наслідків вибору сховища в перший день. Ви відчуваєте їх уперше, коли о 2:13 ночі помирає вузол, CEO летить з переривчастим Wi‑Fi, а ваша «HA»-історія перетворюється на «ми розбираємося». Ось тоді й виявляється, чи ви купили надійність, чи просто придбали нове хобі.

У Proxmox питання Ceph проти ZFS виглядає як порівняння функцій. У продакшні це рішення про режим відмов. Цей матеріал — дерево рішень, яке я хотів би, щоб більше команд мали, перш ніж впевнено побудувати не те, що треба.

Дерево рішень (користуйтесь цим, а не інтуїцією)

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

Крок 1: Вам потрібне спільне сховище для живої міграції та HA між вузлами?

• Якщо так, і ви хочете вбудованого рішення: оберіть Ceph (RBD). Це саме про це: розподілене блочне сховище, яке переживає втрату вузла і продовжує обслуговувати запити.
• Якщо ні (або ви готові до «міграції з простоєм» чи підходів на основі реплік): ZFS на кожному вузлі зазвичай дає найкращий баланс надійності та витрат зусиль.

Крок 2: Скільки у вас реально вузлів?

• 1 вузол: ZFS. Ceph — не продукт для одного вузла, якщо ви не в лабораторії або не любите навмисну складність.
• 2 вузли: ZFS з третім голосом (qdevice) для кворуму. Ceph на 2 вузлах — пастка; ви винайдете нові форми нещастя.
• 3 вузли: Ceph стає життєздатним. ZFS усе ще простіший. Вимога щодо спільного сховища й відмовостійкості вирішує питання.
• 4–8 вузлів: Ceph виправдовує себе, якщо вам потрібне спільне сховище і ви можете дозволити мережу та диски відповідного класу.
• 9+ вузлів: Ceph часто є правильним дефолтом для спільного сховища, але тільки якщо ви ставитесь до нього як до справжньої системи зберігання, а не як до галочки в списку вимог.

Крок 3: Який у вас бюджет на відмовостійкість?

• «Вузол може померти і ніхто нічого не помітить»: Ceph з реплікацією (size 3) і адекватними failure domain.
• «Вузол може померти і ми відновимося за хвилини, можливо відновимо кілька ВМ»: ZFS з реплікацією (zfs send/receive), бекапами і реалістичним RTO.
• «Нам потрібні просто хороші локальні диски, відновимося з бекапу»: ZFS, зеркала і план резервного відновлення, що дійсно працює.

Крок 4: Яка у вас мережа для трафіку сховища?

• 10GbE з загальними комутатором і без ізоляції: ZFS має перевагу, якщо ваш Ceph-кластер невеликий і мало навантажений. Ceph може працювати на 10GbE, але продуктивність і відновлення будуть вам протистояти.
• 25GbE+ виділена мережа для сховища (або хоча б добре відокремлені VLAN/QoS): Ceph стає набагато передбачуванішим, особливо під час backfill/rebalance.

Крок 5: Який тип IO виконують ваші ВМ на практиці?

• Чутливі до затримки випадкові записи (бази даних, черги повідомлень): зеркала ZFS часто відчуваються швидше. Ceph може це забезпечити, але треба інженерити: NVMe OSD, хороша мережа і налаштоване відновлення.
• Переважно читання, помірні записи, багато ВМ: Ceph хороший вибір, якщо ви хочете спільне сховище і погоджуєтесь на write amplification реплікації/EC.
• Великі послідовні навантаження: обидва варіанти впораються; обирайте за операційною моделлю та поводженням при відмовах.

Крок 6: Хто буде обслуговувати це о 2-й ночі?

• Мала команда, низька готовність до storage-on-call: ZFS. Менше складових, менше кластерних непередбачуваних поведінок.
• Команда, готова інвестувати в операційну зрілість: Ceph може стати «нудним» — у хорошому сенсі — після дисципліни й регламентів.

Правило думки: якщо ви обираєте Ceph, щоб не купувати спільний SAN, ви все одно маєте заплатити за еквівалент у формі мережі, дисків та операційних зусиль. Ceph — це не «дешеве спільне сховище». Це «спільне сховище, яке ви володієте».

Що ви насправді купуєте: семантика та режими відмов

ZFS у Proxmox: локальна істина, сильна цілісність

ZFS — це файловий менеджер і менеджер пулів з end-to-end checksumming, copy-on-write, снапшотами, реплікацією та моделлю кешування, що може зробити ваші ВМ чуттєво відзивними. У Proxmox ZFS зазвичай використовується як локальне сховище на кожному вузлі: пули для дисків ВМ (zvol) і датасети для бекапів або шаблонів.

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

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

Ceph у Proxmox: розподілене блочне сховище, спільне за дизайном

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

Що ви отримуєте: спільне сховище, самовідновлювану реплікацію, усвідомлення доменів відмов та можливість втратити вузол, не втративши доступ до дисків ВМ.

Чого ви не отримаєте: простоти. Ви керуєте розподіленою системою. Розподілені системи чудові, аж до того моменту, коли ви розумієте, що мережа тепер частина вашого RAID-контролера.

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

Парафразована ідея (атрибуція): Werner Vogels (CTO Amazon) давно просуває ідею «усе ламається, тож розробляй під відмови». Вибір сховища — місце, де ви або серйозно це маєте на увазі, або ні.

Цікаві факти та історичний контекст (щоб не повторювати помилки 2012 року)

• Ceph почався як дослідницький проєкт (PhD Sage Weil), і ранній дизайн сильно ставив на коммодиті‑обладнання та надійність, реалізовану програмно.
• CRUSH (алгоритм розміщення Ceph) створений, щоб уникати централізованих метаданих, обчислюючи розміщення об’єктів замість їхнього пошуку.
• RBD (RADOS Block Device) став основним механізмом для дисків ВМ, бо блочні семантики гарно накладаються на гіпервізори й формати образів.
• ZFS народився в Sun з моделлю «пул сховища», яка трактувала диски як керований ресурс, а не як набір розділів надії.
• ZFS популяризував end-to-end checksumming у свідомості адмінів: мовчазна корупція перестає бути міфом, коли ZFS дає вам чеки.
• Ранні кластери Ceph мали репутацію операційної складності, бо налаштування відновлення, підбір PG та варіації обладнання могли робити поведінку непередбачуваною. Багато чого покращилось, але фізика лишилась.
• Еразурне кодування стало важливим для Ceph, бо реплікація (3x) дорога; EC знижує накладні витрати, але додає складності та вартість запису.
• Proxmox рано підтримав і Ceph, і ZFS, бо невеликі та середні команди потребували реальних варіантів сховища без купівлі повного SAN-екосистеми.

Жарт №1: RAID означає «Redundant Array of Inexpensive Disks», а потім ви купуєте 25GbE комутатори і це перетворюється на «Remarkably All‑Incostly Decision».

Обладнання та топологія: частина, яку всі недооцінюють

Обладнання для Ceph: мінімум — не те саме, що «добре працює»

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

Варіанти розміщення дисків

• HDD для OSD: добре для ємності, погано для латентності випадкових записів. Підходить для архівних робочих навантажень ВМ, але не для жвавих баз даних, якщо ви не готові до більшої затримки.
• SSD/SATA для OSD: робоча золота середина, але стежте за витривалістю та стійкістю при довготривалих записах.
• NVMe для OSD: досвід «Ceph як локальне сховище» зазвичай = NVMe плюс хороша мережа.

Вартість Ceph часто домінує write amplification: реплікація (size 3) пише кілька копій; EC розподіляє дані та парність по OSD; малі випадкові записи стають дорогими. Не бюджетуйте Ceph по сирим ТБ. Бюджетуйте його за корисними ТБ при потрібній затримці під час відновлення.

Мережа

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

• 10GbE: може працювати для малих кластерів, але відновлення «з’їсть» все. Потрібно відокремлення від клієнтського трафіку або дуже акуратне формування трафіку.
• 25GbE: розумний базовий рівень для «нам важлива продуктивність та час відновлення».
• Дві мережі: все ще корисно (публічна/клієнтська vs кластерна/backfill), але багато розгортань успішні з однією продуманою мережею, якщо ви дисципліновані.

Обладнання для ZFS: нудне — це перевага

ZFS винагороджує за базові речі: ECC-пам’ять (бажано), зеркальні vdev для дисків ВМ та збереження пулу з запасом. ZFS може робити RAIDZ для ємності, але робочі навантаження ВМ — це не «один великий послідовний файл». Це купа малих випадкових записів у тренчкості.

Mirror vs RAIDZ у робочих навантаженнях Proxmox VM

• Зеркала: нижча затримка, вищі IOPS, простіше відновлення. Чудовий дефолт для пулів ВМ.
• RAIDZ2/3: краща ємнісна ефективність, але штраф для випадкових записів і довгі resilver можуть бути болісними. Краще для bulk‑сховища, бекапів та навантажень з меншою чутливістю до затримки.

SLOG та L2ARC: перестаньте купувати магічні частини перш за все

Більшість команд не потребує окремого SLOG. Якщо ваше навантаження — переважно асинхронні записи (поширено для багатьох ВМ), SLOG навряд допоможе суттєво. Якщо ви працюєте з синхронно-залежними базами даних і вам важлива затримка, то так, висококласний SLOG з захистом від втрати живлення може мати значення.

L2ARC може допомогти читанням, але також споживає RAM для метаданих і дає фальшиве відчуття безпеки. Почніть з достатньої RAM і розумного макету пулу. Додавайте L2ARC, коли доведете проблему пропусків кеша.

Реальність продуктивності: затримка, IOPS, відновлення та «податок» за шумний контейнер

Ceph: steady-state vs failure-state

У steady state Ceph може давати відмінну пропускну здатність і непогану затримку — особливо на NVMe і швидких мережах. У failure-state (OSD down, reboot вузла, мережевий глюк) Ceph починає робити те, для чого він спроєктований: реплікувати, backfill‑ити, ребалансувати. Ця робота з відновлення конкурує з клієнтським IO.

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

• Правильний запас пропускної здатності мережі та дисків.
• Розумні налаштування recovery/backfill (не «без обмежень, YOLO»).
• Домені відмов, які відповідають реальності (хост, шасі, рюк).

ZFS: ARC змушує вас виглядати розумно (доки ні)

Продуктивність ZFS часто сприймається як «швидка», бо ARC (кеш в пам’яті) приховує затримку читань. Це реальна цінність. Але це також може приховати те, що ваш пул не підготовлений для записів, або що ви ось-ось досягнете фрагментації і отримаєте катастрофу від sync‑записів.

Ще реалія ZFS: коли ви перевищуєте ~80% використання пулу, продуктивність часто падає. Люди сперечаються про точні числа; ваші графіки не брешуть. Тримайте пул ВМ з запасом. Ви не зберігаєте сімейні фото. Ви зберігаєте дедлайни інших людей.

«Шумний сусід» на практиці

З локальними пулами ZFS шумна ВМ зазвичай шкодить цьому вузлу. З Ceph шумна ВМ може підсилитися в більший біль для кластера, якщо вона генерує багато записів, що викликає реплікаційний трафік і затримки відновлення. Ось чому QoS та розумні ліміти дисків для ВМ важливі в просторі Ceph.

Операційні витрати: хто на виклику і за що

ZFS ops: менше складових, але треба робити реплікацію/бекапи

Операційне навантаження ZFS переважно:

• Моніторинг стану пулу (scrub‑и, SMART, лічильники помилок).
• Керування снапшотами та політиками збереження (не робіть снапшоти вічно; це не план, це прокрастинація).
• Реплікація, якщо ви хочете стійкість поза межами одного хоста.
• Керування ємністю: додавайте vdev, не загоняйте себе в кут розширення RAIDZ.

Ceph ops: кластер сховища — це живий організм

Ceph вимагає комфорту з:

• Станом кластера: placement groups, backfill, degraded objects.
• Налагодження мережі як навику збереження, а не як хобі іншої команди.
• Управління змінами: додавання OSD змінює розміщення даних і запускає ребаланс.
• Розуміння поведінки відновлення: компроміс швидкості та впливу.

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

Три корпоративні міні-історії (усі досить болючі)

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

Середній SaaS перейшов від локального ZFS на Ceph, бо хотіли безшовну живу міграцію. Інженер зі сховища (добрі наміри, мало часу) припустив, що існуюча 10GbE мережа «буде ок» бо steady‑state бенчмарки виглядали прийнятно. Вони збудували 4‑вузловий Ceph, replication size 3, змішали SATA SSD OSD та кілька старих дисків «тимчасово» і пішли в продакшн.

Через два місяці один OSD почав флапати — up/down кожні кілька хвилин — через маргінальний диск і HBA, який не дуже любив його кабелі. Ceph зробив своє: backfill почався, потім пауза, потім знову, потім знову. Латентність клієнтського IO зросла. Диски ВМ почали таймаутити. Гіпервізори виглядали «здоровими», але сховище фактично тряслось.

Хибне припущення було тонким: вони думали, що трафік відновлення — це фонове завдання. Ні. У Ceph відновлення — первинне навантаження. На 10GbE відновлення плюс клієнтський IO можуть наситити ті ж лінки, спричиняючи латентні сплески, що виглядають як «випадкові проблеми додатків».

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

Урок: якщо ви не можете дозволити мережевий запас пропускної здатності для подій відновлення — ви не можете дозволити Ceph. Ви просто позичаєте надійність у майбутнього під жахливі відсотки.

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

Інша організація використовувала Proxmox з ZFS зеркалами. Вони були обмежені по ємності і вирішили «оптимізувати», переключивши нові пули на RAIDZ2. Рахунки виглядали привабливо. Дашборди стали зеленішими. Фінанси були в захваті.

Потім навантаження змінилось. Продуктова команда додала пишучий аналітичний пайплайн, багато дрібних випадкових записів і пару баз даних з агресивним fsync. Латентність зросла з «нормально» до «мій додаток переслідують примари». ZFS почав витрачати багато часу на паритетні обчислення і обробку випадкових записів, що RAIDZ не любить. Scrub‑и та resilver‑и подовжились. Продуктивність під навантаженням стала стрибкоподібною.

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

Зрештою вони перемістили найгарячіші ВМ на зеркальні vdev і залишили RAIDZ2 для bulk‑датасетів і бекапів. Економія ємності була реальною, але це був не той рівень для цього навантаження.

Урок: оптимізація без моделі робочого навантаження — це лотерея продуктивності. Іноді виграєш. Операції пам’ятають, коли програєш.

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

Компанія в суміжній до охорони здоров’я сфері використовувала Proxmox з Ceph для спільних дисків ВМ. Нічого вишуканого: узгоджені NVMe OSD, виділений VLAN для сховища та строгі вікна змін. Ненудна частина — їх тижнева рутина: перевіряти стан Ceph, веріфікувати scrub‑и, перевіряти SMART‑лічильники і тестувати відновлення хоча б однієї ВМ з бекапів.

В один четвер топ‑оф‑рек комутатор почав скидати пакети під навантаженням. Не повний спад. Достатньо, щоб викликати інтермітентні латентні сплески. Додатки почали скаржитись. Гіпервізори виглядали нормально. Графіки збереження показали зростання retransmits і падіння пропускної здатності клієнтів.

Оскільки у них були нудні бази, вони швидко побачили зміну: помилки в мережі зросли, і Ceph почав показувати slow ops. Вони обмежили відновлення, перемістили частину трафіку і скоординувалися з мережею для заміни обладнання. Кластер залишився доступним.

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

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

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

Нижче — практичні завдання, які ви можете виконати на вузлах Proxmox. Кожне включає: команду, реалістичний приклад виводу, що це означає і яке рішення вона підштовхує. Виконайте їх. Не дискутуйте в Slack.

Завдання 1: Підтвердити, які типи сховища Proxmox вважає доступними

cr0x@server:~$ pvesm status
Name             Type     Status  Total     Used     Available  %
local            dir      active  196.00G   21.30G    164.70G  10%
local-zfs        zfspool  active  1.75T     612.00G   1.14T    35%
ceph-rbd         rbd      active  10.00T    6.20T     3.80T    62%

Значення виводу: У вас налаштовані локальний ZFS і Ceph RBD, і Ceph зайнятий на 62%.

Рішення: Якщо Ceph — ваше основне сховище дисків ВМ, 62% не означає «повний», але це вже достатньо, щоб вартість відновлення/ребалансування збільшилась. Плануйте ємність до 75–80%.

Завдання 2: Перевірити здоров’я ZFS пулу і помітити мовчазні проблеми рано

cr0x@server:~$ zpool status -x
all pools are healthy

Значення виводу: Немає відомих помилок, немає деградування vdev.

Рішення: Якщо тут не «all pools are healthy», припиніть сперечатися про Ceph vs ZFS і спочатку виправте свій пул. Гігієна сховища переважає архітектурні дискусії.

Завдання 3: Інспектувати макет ZFS (mirror vs RAIDZ дає очікування продуктивності)

cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1        ONLINE       0     0     0
            ata-SAMSUNG_SSD_2        ONLINE       0     0     0
          mirror-1                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_3        ONLINE       0     0     0
            ata-SAMSUNG_SSD_4        ONLINE       0     0     0

Значення виводу: Два зеркальні vdev (striped mirrors). Чудово для IOPS ВМ і поведінки при відновленні.

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

Завдання 4: Перевірити стиснення ZFS і volblocksize (тихі вбивці продуктивності)

cr0x@server:~$ zfs get -o name,property,value -s local compression,volblocksize local-zfs/vmdata
NAME               PROPERTY      VALUE
local-zfs/vmdata   compression   lz4
local-zfs/vmdata   volblocksize  8K

Значення виводу: LZ4 стиск ввімкнений (зазвичай корисно), volblocksize 8K (поширено для дисків ВМ).

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

Завдання 5: Перевірити тиск на ARC (продуктивність ZFS часто = реальність RAM)

cr0x@server:~$ arcstat 1 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:11   892    73      8    39   53    34   47     0    0   48G   56G

Значення виводу: ARC 48G, ціль 56G, miss rate 8%. Не критично.

Рішення: Якщо miss% постійно високий і диски зайняті, розгляньте додавання RAM перед покупкою кеш‑SSD. RAM — найдешевше покращення продуктивності в ZFS‑світі.

Завдання 6: Підтвердити, чи sync‑записи є вузьким місцем (тут вирішують SLOG)

cr0x@server:~$ zfs get -o name,property,value sync local-zfs/vmdata
NAME               PROPERTY  VALUE
local-zfs/vmdata   sync      standard

Значення виводу: Стандартна поведінка sync. Додатки, що просять sync, отримають його; інші — ні.

Рішення: Не ставте sync=disabled, щоб «поліпшити продуктивність» для дисків ВМ. Якщо ви це зробите, перейменуйте кластер в «можливо‑пізніше» і оновіть своє резюме.

Завдання 7: Перевірити стан Ceph‑кластера на око

cr0x@server:~$ ceph -s
  cluster:
    id:     8e0c2d8f-7e2b-4c2a-9d1b-2c9e5d2e3a1a
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
            1 osds down
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 11 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     240 active+clean
             16  active+degraded

Значення виводу: Один OSD down, але ще «in», і є slow ops та degraded PGs.

Рішення: Ставте HEALTH_WARN зі slow ops як продакшн‑інцидент, якщо він триває. Знайдіть down OSD і причину перед тим, як перезавантажувати щось інше.

Завдання 8: Швидко ідентифікувати down або flapping OSD

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         37.260   root default
-3         12.420       host pve1
 0    ssd   3.105            osd.0     up   1.00000  1.00000
 1    ssd   3.105            osd.1   down   1.00000  1.00000
 2    ssd   3.105            osd.2     up   1.00000  1.00000
 3    ssd   3.105            osd.3     up   1.00000  1.00000
-5         12.420       host pve2
 4    ssd   3.105            osd.4     up   1.00000  1.00000
 5    ssd   3.105            osd.5     up   1.00000  1.00000
 6    ssd   3.105            osd.6     up   1.00000  1.00000
 7    ssd   3.105            osd.7     up   1.00000  1.00000
-7         12.420       host pve3
 8    ssd   3.105            osd.8     up   1.00000  1.00000
 9    ssd   3.105            osd.9     up   1.00000  1.00000
10    ssd   3.105            osd.10    up   1.00000  1.00000
11    ssd   3.105            osd.11    up   1.00000  1.00000

Значення виводу: osd.1 down на хості pve1.

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

Завдання 9: Перевірити, чи Ceph backfilling/recovering (прогноз впливу на продуктивність)

cr0x@server:~$ ceph -w
2026-02-04T12:03:10.123+0000 mon.pve1 [WRN] Health check update: 1 osds down (OSD_DOWN)
2026-02-04T12:03:12.456+0000 osd.3 [INF] 1.2% backfill_recovery 120/10000 objects recovered
2026-02-04T12:03:13.222+0000 mgr.pve1 [WRN] Slow OSD heartbeats on back (osd.6)

Значення виводу: Recovery/backfill активний, плюс попередження про heartbeat (мережа або перевантажений OSD).

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

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

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

Значення виводу: Ваш пул дисків ВМ (rbd) реплікований size 3, min_size 2.

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

Завдання 11: Перевірити латентність і завантаження OSD Ceph (хто повільний в групі)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   7
1    0                   0
2    6                   8
3    52                  75
4    6                   9
5    5                   7
6    7                   10

Значення виводу: osd.3 значно повільніший за інших.

Рішення: Розслідуйте обладнання хоста osd.3, стан дисків і мережу. Один повільний OSD може викликати глобальну латентність через slow ops.

Завдання 12: Валідовати мережу сховища (втрата пакетів перетворюється на «Ceph повільний»)

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9823456789  8123456  0       0        0       12345
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7123456  0       0        0       0

Значення виводу: Немає помилок RX/TX або дропів на цьому інтерфейсі.

Рішення: Якщо бачите помилки/скидання пакетів — виправляйте мережу перед налаштуванням Ceph. Трафік сховища ненавидить «майже працює».

Завдання 13: Перевірити сигнали здоров’я дисків (і ZFS, і Ceph гинуть від нудних дисків)

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i "critical_warning|media_errors|num_err_log_entries|percentage_used"
critical_warning                    : 0x00
percentage_used                     : 7%
media_errors                        : 0
num_err_log_entries                 : 0

Значення виводу: NVMe виглядає здоровим; низький знос, немає помилок медіа.

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

Завдання 14: Виміряти затримку IO на вузлі (доведіть, чи це диск чи мережа)

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    4.25    8.90    0.00   74.74

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0   850.0  4800.0 55200.0    0.0     2.0     1.2     18.4    6.5   92.0

Значення виводу: Пристрій сильно завантажений, write await ≈18ms — високо для NVMe, що вказує на насичення або чергування.

Рішення: Якщо %util на максимумі і await росте — ви пов’язані з диском на цьому вузлі/хості OSD. У Ceph це може бути один повільний OSD; в ZFS — можливо один vdev перевантажений.

Завдання 15: Перевірити налаштування дисків ВМ у Proxmox (іноді вузьке місце — самонавчене)

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|iothread|cache|discard"
scsihw: virtio-scsi-single
scsi0: ceph-rbd:vm-101-disk-0,discard=on,iothread=1,ssd=1

Значення виводу: virtio-scsi-single з iothread увімкнено і discard увімкнений, використовується Ceph RBD.

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

Завдання 16: Дивитися клієнтський IO Ceph з перспективи кластера

cr0x@server:~$ ceph osd pool stats
pool rbd id 1
  client_io_rate: 48 MiB/s rd, 22 MiB/s wr, 310 op/s rd, 420 op/s wr
pool cephfs_data id 2
  client_io_rate: 12 MiB/s rd, 4 MiB/s wr, 90 op/s rd, 60 op/s wr

Значення виводу: RBD‑пул робить основну частину IO.

Рішення: Коли користувачі кажуть «сховище повільне», перевірте, чи IO дійсно стрибнув, або ж затримка зросла без зміни пропускної здатності (часто мережа або один OSD).

План швидкої діагностики: знайти вузьке місце за хвилини

Ось порядок діагностики, яким я користуюсь, коли хтось каже «ВМ повільні» і починають ритуально звинувачувати сховище.

Перший: це локально на вузлі чи по всьому кластеру?

• Перевірте навантаження вузла Proxmox: якщо один вузол гарячий, це може бути локальний IO або планування CPU.
• Перевірте, чи страждають лише ВМ на Ceph: якщо так, фокусуйтеся на Ceph‑здоров’ї і мережі; якщо ні — можливо CPU хоста, пам’ять або спільна мережева проблема.

Другий: Ceph нездоровий або відновлюється?

• Запустіть: ceph -s і дивіться на HEALTH_WARN/ERR, slow ops, degraded PGs, OSD down, recovery/backfill.
• Рішення: Якщо відновлення йде, вважайте, що воно додає до латентності. Вирішіть, чи тимчасово обмежити recovery.

Третій: це втрата/запізнення мережі?

• Перевірте помилки/скидання інтерфейсів: ip -s link на всіх вузлах і портах storage VLAN.
• Шукайте попередження про heartbeat у Ceph: вони часто вказують на мікровтрати мережі або насичені лінки.
• Рішення: Якщо бачите дропи/retransmits — вважайте мережу головним підозрюваним.

Четвертий: це один повільний диск/OSD?

• Ceph: ceph osd perf щоб знайти аутлайєрів; потім перевірте SMART і dmesg на хості.
• ZFS: zpool status на помилки; iostat -x для насичення; перевірте, чи один vdev не несе більшу частину навантаження.
• Рішення: Замініть апарат негайно. Частково деградований, але ще працюючий диск — як початок аварії.

П’ятий: це конфігурація ВМ чи поведінка гостя?

• Перевірте шину дисків і iothread‑и: неправильні налаштування можуть обмежувати продуктивність.
• Перевірте fsync‑поведінку гостя: бази даних можуть перетворити сховище на мікроскоп затримок.
• Рішення: Якщо одна ВМ — винуватець, застосуйте ліміти IO або перемістіть її на відповідний рівень сховища.

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

1) Симптом: «Ceph повільний вдень, нормальний вночі»

Корінь: Recovery/backfill конкурує з клієнтським IO; денне навантаження не лишає запасу.

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

2) Симптом: Випадкові фризи/таймаути ВМ на Ceph

Корінь: Втрата пакетів або мікроспроби в мережі сховища; flapping OSD; накопичення slow ops.

Виправлення: Перевірте лічильники помилок і стан комутаторів; ізолюйте трафік сховища; виправте MTU‑невідповідності; замініть нестабільні диски/OSD.

3) Симптом: ZFS пул «здоровий», але продуктивність поступово падає місяцями

Корінь: Пул занадто заповнений; фрагментація; накопичені снапшоти; малі випадкові записи на RAIDZ.

Виправлення: Тримайте запас; обрізайте снапшоти; мігруйте гарячі ВМ на зеркальні vdev; додавайте vdev до кризи.

4) Симптом: «Додавання дисків зробило Ceph гіршим»

Корінь: Запустився ребаланс/backfill і наситив мережу/диски; OSD не однорідні; CRUSH‑домен відмов не відповідає фізиці.

Виправлення: Додавайте ємність у контрольовані вікна; обмежуйте backfill; тримайте класи OSD однорідними; перевіряйте CRUSH‑топологію.

5) Симптом: Страх корупції ZFS після відключення живлення

Корінь: Відсутність UPS; споживчі SSD без захисту при втраті живлення; ризиковані налаштування кеша запису.

Виправлення: UPS плюс належні SSD для критичних навантажень; уникайте unsafe кешів; тестуйте процедури відновлення.

6) Симптом: Ceph виглядає здоровим, але латентні сплески тривають

Корінь: Один повільний OSD (висока apply latency) або CPU‑контенція на хостах OSD; шумна ВМ, що насичує IO.

Виправлення: Використайте ceph osd perf і iostat на хості; перемістіть важкі ВМ; застосуйте IO‑ліміти; забезпечте CPU‑запас на хостах OSD.

7) Симптом: Жива міграція повільна або падає під навантаженням

Корінь: Трафік міграції ділить обмежену мережу з Ceph; або сховище локальне ZFS і ви фактично копіюєте диски.

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

8) Симптом: «Ми встановили sync=disabled і все стало швидким»

Корінь: Ви обміняли стійкість на швидкість; тепер ви вразливі до втрати живлення і втрати даних при kernel panic.

Виправлення: Поверніть налаштування. Якщо sync‑записи занадто повільні, виправляйте шлях збереження (зеркала, SLOG з PLP, швидше носії, кращі налаштування), а не закони фізики.

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

Чекліст A: Якщо ви схиляєтеся до ZFS (локальне сховище, простіше в експлуатації)

1. Вибирайте зеркала для пулів ВМ, якщо тільки у вас немає перевіреного робочого навантаження, що підходить для RAIDZ.
2. Увімкніть стиснення (lz4) і перевірте його для датасетів/zvol ВМ.
3. Плануйте запас: ціль <70% використання для пулів ВМ; розглядайте 80% як край продуктивності, а не поради.
4. Розклад scrubs і моніторинг checksum‑помилок.
5. Запровадьте реплікацію (zfs send/receive) на інший вузол або ціль бекапу, якщо потрібні швидкі відновлення.
6. Тестуйте відновлення щомісяця мінімум; частіше, якщо змінюєте політики ретеншену.
7. Визначте історію відмов: вузол помер = ми робимо X; диск помер = ми робимо Y; мережа фле́рить = ми робимо Z.

Чекліст B: Якщо ви схиляєтеся до Ceph (спільне сховище, семантика HA)

1. Почніть з 3+ вузлів з узгодженим OSD‑обладнанням; уникайте змішаних класів латентності в одному пулі.
2. Бюджетуйте мережу належно: 25GbE як базис для серйозних навантажень; ізолюйте трафік сховища.
3. Оберіть розмір реплікації навмисно (часто size 3). Запишіть, яку відмову це витримує.
4. Визначте failure domain (хост/рейк), щоб CRUSH відповідав фізичній реальності.
5. Встановіть ліміти recovery/backfill для денного стабільного режиму; майте профіль «після робочого часу» для прискорення.
6. Моніторьте slow ops і OSD‑аутлайєри; тримайте їх як попередження раннього рівня.
7. Практикуйте заміну OSD у не‑кризовий день. Перший раз під час деграду — не найкращий момент.

Чекліст C: План міграції, якщо ви помилились торік

1. Інвентаризуйте робочі навантаження: які ВМ потребують низької затримки, які — ємності, які — спільних семантик.
2. Створіть рівні: гаряче сховище (зеркала/NVMe), загальне сховище, bulk/бекап сховище.
3. Перемістіть одне навантаження першим і виміряйте before/after (латентність, пропускну здатність, tail‑lat).
4. Автоматизуйте відкат, щоб міграція не була односторонньою дорогою.
5. Документуйте операційні runbook‑и для нового рівня (як замінити диск, як діагностувати повільний IO, хто кличе кого).

FAQ

1) Чи можна запускати Ceph на 3 вузлах з змішаними SSD і HDD?

Можна, але, швидше за все, не варто для дисків ВМ. Змішана латентність в одному пулі дає хвостову латентність. Якщо мусите змішувати — розділяйте по класу пристроїв і використовуйте різні пули.

2) Чи Ceph завжди повільніший за локальний ZFS?

Ні. Але Ceph додає мережеві «гоп‑хопи» і наклад реплікації. На відмінному обладнанні й мережі Ceph може бути швидким і стабільним. На «залишковому 10GbE» локальний ZFS часто відчувається краще для чутливих до латентності записів.

3) Чи RAIDZ «поганий» для ZFS VM‑сховища?

Не морально. Практично — RAIDZ може не підходити для випадкових записів ВМ через паритетні штрафи та поведінку IOPS. Зеркала зазвичай безпечніший дефолт для дисків ВМ.

4) Чи варто використовувати erasure coding Ceph для дисків ВМ?

Зазвичай ні для первинних дисків ВМ, якщо тільки у вас немає сильної причини і ви розумієте компроміси продуктивності. EC вигідне для ефективності ємності, часто краще підходить для об’єктно/файлових навантажень, а не для латентних випадкових блочних записів.

5) Яка мінімальна «серйозна» мережа для Ceph?

Для продакшну з значним навантаженням: 25GbE і нормальні комутатори. 10GbE може працювати, але ви будете налаштовуватися навколо подій відновлення і жити з більшою варіативністю.

6) Чи потрібна ECC RAM для ZFS?

Дуже рекомендовано, особливо для критичних навантажень. ZFS захищає дані на диску через контрольні суми, але помилки в RAM все одно можуть спричиняти погані наслідки. ECC зменшує клас тихих, огидних несправностей.

7) Чим відрізняються снапшоти в Ceph і ZFS операційно?

Снапшоти ZFS дуже зрілі і прості для розуміння. Ceph RBD‑снапшоти існують і корисні, але оперативна пам’ять зі ZFS‑рутин буде міцнішою. Для бекапів Proxmox ви зазвичай використовуєте Proxmox Backup Server незалежно від шляху.

8) Чи можна поєднувати: ZFS локально і Ceph для спільного?

Так, багато організацій так роблять. Кладіть чутливі до латентності або «із прив’язкою до вузла» навантаження на локальний ZFS, а Ceph використовуйте для ВМ, які потребують спільного сховища і HA. Головне — мати чіткі правила розміщення і моніторинг обох шляхів.

9) Найбільш поширена причина розчарування в розгортаннях Ceph?

Недобюджетована мережа і неоднорідне OSD‑обладнання. Люди очікують, що розподілене сховище поведеться як локальний SSD. Ceph може так поводитися, але тільки якщо ви за це заплатите в проєкті.

10) Найбільш поширена причина розчарування в розгортаннях ZFS?

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

Наступні кроки, які ви можете зробити цього тижня

• Виконайте команди з розділу вище на вашому кластері і запишіть факти (макет, стан, латентні аутлайєри, дропи мережі). Це буде ваша базова лінія.
• Визначте, що вам насправді потрібно: семантика спільного сховища (Ceph) або сильне локальне сховище з реплікацією/бекапами (ZFS). Не прикидйтесь, що вам потрібні обидва, якщо це не так.
• Якщо ви на Ceph: перевірте ізоляцію мережі та запас пропускної здатності; підтвердіть size/min_size пулу; знайдіть повільні OSD і виправте їх до того, як вони стануть інцидентом.
• Якщо ви на ZFS: перевірте зеркала для пулів ВМ, увімкніть стиснення і забезпечте запас; аудитуйте ретеншен снапшотів; зробіть тест відновлення, який передбачає запуск ВМ.
• Напишіть історію відмов на одній сторінці: «Якщо вузол помирає, ми робимо X; якщо диск помирає, ми робимо Y; якщо мережа фле́рить, ми робимо Z.» Якщо ви не можете її написати, ви ще не володієте ситуацією.

Рішення Ceph проти ZFS — це не «що кращє». Це «який набір компромісів ви готові дебажити о 2‑й ночі». Обирайте те, що ви зможете оперувати, а не те, що виграє суперечку на форумі.