Проектирование хранилищ: почему 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.