Проектування сховищ: чому Ceph‑кластер починає гальмувати
Ceph‑кластер із 15 OSD вночі показує health: HEALTH_WARN. ceph -s повертає too many PGs per OSD (400 > max 250). Запити до RBD‑томів сповільнилися вдвічі — типова картина при проектуванні сховищ без розрахунку PG. Така ситуація не катастрофа, але ми за 5 років (більше 50 впроваджених Ceph‑кластерів) навчилися проектувати так, щоб вона не виникала.
Одна з частих помилок при проектуванні сховищ — невірна оцінка кількості placement groups. Наші інженери підбирають pg_num під поточну конфігурацію та включають автомасштабування в Ceph Nautilus+, гарантуючи SLA 99.9% на доступність даних. Досвід показує: правильний розрахунок PG знижує пікову затримку введення-виведення на 40–60% порівняно з конфігурацією за замовчуванням.
Ceph: архітектура та підводні камені
Ceph — програмно-визначене сховище з алгоритмом CRUSH, який розподіляє об'єкти без центрального каталогу. Це дає горизонтальне масштабування, але вимагає точного розрахунку PG.
CRUSH Map і розподіл даних. Кожен об'єкт хешується в PG, а PG маппіться на OSD через CRUSH. Failure domain налаштовується так, щоб репліки не потрапляли на один хост, стійку або датацентр.
# Перегляд CRUSH map та розрахунок pg_num ceph osd getcrushmap -o /tmp/crushmap.bin crushtool -d /tmp/crushmap.bin -o /tmp/crushmap.txt ceph osd pool get <pool_name> pg_num # Рекомендація: (OSD_count * 100) / replica_count → округлити до степеня 2 Для 12 OSD з реплікацією 3x: (12 * 100) / 3 = 400 → 512. Якщо пулів п'ять — сумарне PG на OSD різко зростає, і з'являється too many PGs per OSD. Увімкніть ceph osd pool autoscale-status — це знімає проблему.
Продуктивність RBD. RBD (RADOS Block Device) — основа для VM (Proxmox, OpenStack). Критичні параметри:
-
rbd_cache = trueзrbd_cache_size = 128 MB— write‑back кеш на клієнті (прискорює випадковий запис, але ризик втрати при падінні). Для БД використовуйтеrbd_cache_writethrough = trueабо вимикайте кеш. -
ms_async_op_threads— для NVMe збільште до 8–16 замість 3 за замовчуванням.
# Бенчмарк пулу rados bench -p <pool_name> 60 write --no-cleanup rados bench -p <pool_name> 60 seq rados bench -p <pool_name> 60 rand Типові проблеми Ceph‑кластера:
-
slow ops— операції чекають >30 с.ceph daemon osd.<id> dump_ops_in_flightпокаже причину: перевантажений OSD, мережева затримка (перевірте MTU, jumbo frames), заниженийbluestore_throttle_bytes. - Rebalancing після додавання OSD сповільнює весь кластер. Регулюємо:
ceph osd set-backfillfull-ratio 0.90 ceph config set osd osd_max_backfills 1 ceph config set osd osd_recovery_max_active 3 Зменшення osd_max_backfills до 1 знижує навантаження, але збільшує час відновлення — знаходимо баланс під конкретний кластер.
Моніторинг. ceph mgr module enable prometheus включає експортер на порту 9283. Метрики: ceph_health_status, ceph_osd_stat_bytes_used, ceph_pool_rd_bytes. У Grafana використовуйте дашборд ID 2842.
Розрахунок PG: як уникнути перевантаження OSD
При проектуванні сховищ ми завжди розраховуємо PG так, щоб на один OSD припадало не більше 250 PG. Якщо пулів багато — використовуємо автомасштабування (pg_autoscale_mode = on). Вмикаємо ceph osd pool autoscale-status — і кластер сам підлаштовує pg_num під навантаження. Згідно з офіційною документацією Ceph, перевищення 250 PG на OSD веде до деградації продуктивності та зростання затримок.
NFS: коли просто працює і коли перестає
NFS v4.1 з pNFS для паралельного доступу надлишковий для більшості завдань. Для shared storage веб-серверів або home directories достатньо NFS v4 без pNFS.
/etc/exports:
/data/shared 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash) -
sync— підтвердження запису після скидання на диск (production). -
no_root_squash— необхідно для Kubernetes Persistent Volumes з NFS provisioner.
Параметри монтування клієнта:
10.0.0.1:/data/shared /mnt/shared nfs rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,nfsvers=4.1 rsize/wsize 1 MB оптимальні для великих файлів. hard — клієнт чекає сервер нескінченно (на відміну від soft).
S3‑сумісні системи: MinIO та RadosGW
MinIO в single‑node — для dev/staging. Distributed mode з erasure coding — від 4 нод, стійкий до втрати половини дисків.
mc alias set myminio http://localhost:9000 minioadmin minioadmin mc mb myminio/backups mc cp backup.tar.gz myminio/backups/ Для Ceph RadosGW дані зберігаються в RADOS, масштабується горизонтально.
radosgw-admin user create --uid=s3user --display-name="S3 User" --access-key=KEY --secret=SECRET radosgw-admin quota set --quota-scope=user --uid=s3user --max-size=100G Чому RAID 6 кращий за RAID 5 для дисків ≥16 TB?
Software RAID через mdadm живе на bare‑metal. При rebuild RAID 5 сучасні диски (16–20 TB) відновлюються 20–40 годин. Ймовірність відмови другого диска за цей час у 3–5 разів вища, ніж на 4-годинному rebuild старих дисків. RAID 6 тримає одночасну відмову двох дисків — безпека в 2 рази вища за критерієм збереження даних.
# Створення RAID6 з 6 дисків mdadm --create /dev/md0 --level=6 --raid-devices=6 /dev/sd[bcdefg] # Моніторинг cat /proc/mdstat mdadm --detail /dev/md0 Обов'язково налаштуйте MAILADDR у /etc/mdadm/mdadm.conf для алертингу.
| Сценарій | Інструмент |
|---|---|
| Block storage для VM/контейнерів | Ceph RBD |
| Object storage, бекапи, медіа | MinIO / Ceph RadosGW |
| Shared filesystem для кластера | CephFS / NFS v4 |
| Bare‑metal, немає бюджету на СЗД | mdadm RAID6 + LVM |
| High‑performance, NVMe | Ceph з BlueStore + NVMe OSD |
Як обрати тип сховища?
Вибір між Ceph, NFS та MinIO диктується профілем навантаження. Для блочного доступу (VM, БД) — Ceph RBD. Для файлового — NFS v4 або CephFS. Для об'єктів — MinIO або RadosGW. Гібридні схеми (наприклад, CephFS + RBD) вимагають ретельного планування CRUSH‑рутів.
Приклад розрахунку PG для гібридного кластера
12 OSD, 3 репліки, 4 пули. За формулою (12 × 100) / 3 = 400 → 512 PG на пул. Сумарне PG на OSD = (512 × 4) / 12 ≈ 171, що нижче ліміту 250. Автомасштабування увімкнено.Що входить у роботу з проектування сховищ?
- Документація архітектури (CRUSH map, топологія мережі, розрахунок PG).
- Конфігураційні файли та скрипти автоматизації (Ansible, Terraform).
- Інтеграція з моніторингом (Prometheus, Grafana, дашборди).
- Runbook для адміністрування та аварійного відновлення.
- Навчання команди (2–3 сесії по 4 години).
Більше 5 років на ринку, 50+ впроваджених Ceph‑кластерів, 10+ проектів з MinIO. Отримайте консультацію — ми оцінимо вашу інфраструктуру.
Як ми проектуємо відмовостійкі сховища
- Аналіз вимог — профілі навантаження, RPO/RTO, бюджет.
- Вибір архітектури — Ceph, NFS, MinIO або гібрид.
- Проектування — CRUSH map, PG, мережа, моніторинг.
- Реалізація — розгортання, конфігурація, тести продуктивності.
- Введення в експлуатацію — runbook, навчання команди, SLA 99.9%.
Вартість розраховується індивідуально після аналізу вимог до сховища. Замовте аудит поточної інфраструктури — ми запропонуємо рішення з TCO на 30–50% нижче комерційних SAN/NAS.
Корисні джерела: Ceph, RAID.