Налаштування Ceph кластера (standalone) для розподіленого сховища

Користувачі скаржаться на повільний запис у S3, а віртуальні машини періодично зависають при IO. Причина — неправильно налаштований Ceph: OSD на HDD без NVMe кешу, CRUSH без розділення по стійках, 'cluster network' не налаштована. Налаштування Ceph кластера — це ключовий етап для відмовостійкого розподіленого сховища. Згідно з Wikipedia, Ceph — це розподілена система зберігання, що об'єднує блочне (RBD), файлове (CephFS) та об'єктне (RGW/S3) сховище в одному кластері. Один кластер закриває потреби віртуальних машин, Kubernetes, бекапів та додатків, що працюють з S3. Ціна цієї універсальності — складність: неправильно налаштований Ceph працює повільно та втрачає дані при збоях нестандартним чином. Наш досвід (10+ років у production, 50+ розгорнутих Ceph-кластерів) гарантує відмовостійку архітектуру. Економія на ліцензіях комерційних СЗД досягає $15,000 на рік, а правильно налаштований Ceph працює в 3-5 разів швидше стандартної конфігурації.

Як здійснюється налаштування Ceph кластера?

Налаштування Ceph кластера включає апаратне планування, розгортання cephadm, налаштування CRUSH-топології, тюнінг Bluestore та інтеграцію моніторингу. Кожен етап впливає на продуктивність та відмовостійкість. Середній тринодний кластер з моніторингом розгортається за 5-7 днів. Вартість проекту становить від $5,000 до $8,000, а економія на ліцензіях у масштабі року — до $30,000.

Чому варто обрати standalone Ceph?

Standalone — це Ceph без оркестратора сторонньої платформи (без Proxmox, без Rook для Kubernetes, без OpenStack). Керується через cephadm — офіційний оркестратор, який розгортає сервіси в контейнерах. Всі рішення щодо топології, дисків та мережі приймаємо самі. Це дає максимальний контроль і потребує максимального розуміння архітектури.

Налаштування Ceph кластера: які проблеми вирішуємо?

Неправильно налаштований Ceph — джерело хронічних головних болів: повільний запис (затримки до 50 мс на RBD), втрата даних при виході однієї ноди, неконтрольований backfill у пікові години (навантаження на мережу до 10 Гбіт/с). Ми вирішуємо ці проблеми через:

• точне апаратне планування з розділенням мереж та дисків;
• CRUSH-топологію, що ізолює відмови на рівні хостів або стійок;
• тонкий тюнінг Bluestore та recovery-параметрів.

Ceph з коректним tuning Bluestore демонструє latency на 70% нижче, ніж стандартна конфігурація, а швидкість запису зростає в 3-5 разів. Це підтверджується нашими кейсами: після тюнінгу швидкість запису RBD зростає в 3-5 разів.

Як вибрати правильну топологію дисків?

Мінімум для production — 3 ноди. З 3 нодами втрачаємо одну без втрати даних при size=3, min_size=2. З 5 нодами — терпимо дві одночасні відмови при size=3 з CRUSH-правилами на різні ноди. Диски: не змішуйте OSD різних класів (NVMe та HDD) в одному пулі без явного розділення через device classes. Ceph балансує дані рівномірно за вагою OSD, і повільний HDD буде визначати швидкість всього пулу.

Рекомендована конфігурація на 3 ноди:

• Системний диск: SATA SSD 240GB;
• 2-4 x NVMe для OSD (capacity);
• Виділений NVMe для WAL/DB (bluestore_block_wal, bluestore_block_db);
• 2 x 25GbE: public network + cluster network.

Розділення public та cluster мереж не опціональне. Реплікація між OSD генерує трафік до 25 Гбіт/с, який при змішуванні з клієнтським трафіком деградує latency на 30-50%.

Порівняння конфігурацій дисків — налаштування ceph кластера

Розгортання через cephadm

1. Встановіть cephadm на bootstrap-ноду за допомогою curl.
2. Запустіть bootstrap із зазначенням MON IP та cluster network.
3. Скопіюйте SSH ключ на інші ноди.
4. Додайте хости в кластер.
5. Застосуйте специфікацію ceph-init.yaml.

curl -s --remote-name https://download.ceph.com/rpm-latest/el9/noarch/cephadm && chmod +x cephadm && ./cephadm install
cephadm bootstrap --mon-ip 192.168.10.1 --cluster-network 192.168.20.0/24 --apply-spec /tmp/ceph-init.yaml
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-node2
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-node3
ceph orch host add ceph-node2 192.168.10.2
ceph orch host add ceph-node3 192.168.10.3
ceph orch apply -i /tmp/ceph-init.yaml

Файл /tmp/ceph-init.yaml:

---
service_type: host
hostname: ceph-node1
addr: 192.168.10.1
---
service_type: host
hostname: ceph-node2
addr: 192.168.10.2
---
service_type: host
hostname: ceph-node3
addr: 192.168.10.3
---
service_type: mon
placement:
  hosts:
    - ceph-node1
    - ceph-node2
    - ceph-node3
---
service_type: mgr
placement:
  count: 2
---
service_type: osd
service_id: default_drive_group
placement:
  hosts:
    - ceph-node1
    - ceph-node2
    - ceph-node3
data_devices:
  paths:
    - /dev/nvme1n1
    - /dev/nvme2n1
db_devices:
  paths:
    - /dev/nvme0n1
---

Чому CRUSH map критична для відмовостійкості?

CRUSH (Controlled Replication Under Scalable Hashing) визначає, як Ceph розподіляє дані. Правило за замовчуванням — replicated_rule з рівнем host. Це означає: репліки одних і тих же даних ніколи не опиняться на одному хості. Для більш складної топології (стійки, датацентри) створюємо правило з реплікацією по стійках. Приклад: 3 стійки, по одній ноді в кожній — втрата стійки не страшна.

ceph osd crush add-bucket rack01 rack
ceph osd crush add-bucket rack02 rack
ceph osd crush add-bucket rack03 rack
ceph osd crush move rack01 root=default
ceph osd crush move rack02 root=default
ceph osd crush move rack03 root=default
ceph osd crush move ceph-node1 rack=rack01
ceph osd crush move ceph-node2 rack=rack02
ceph osd crush move ceph-node3 rack=rack03
ceph osd crush rule create-replicated rack_replicated default rack
# Створення пулів
ceph osd pool create vm-data 0 0 replicated rack_replicated
ceph osd pool set vm-data size 3
ceph osd pool set vm-data min_size 2
ceph osd pool application enable vm-data rbd
rbd pool init vm-data
ceph osd pool create .rgw.root 32 32
ceph osd pool create default.rgw.log 32 32
ceph osd pool create default.rgw.control 32 32
ceph osd pool create default.rgw.meta 32 32
ceph osd pool application enable .rgw.root rgw
ceph mgr module enable pg_autoscaler
ceph osd pool set vm-data pg_autoscale_mode on

Параметри Bluestore в /etc/ceph/ceph.conf:

[global]
osd_pool_default_size = 3
osd_pool_default_min_size = 2
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
[osd]
bluestore_block_db_size = 107374182400 # 100GB
bluestore_block_wal_size = 10737418240 # 10GB
bluestore_cache_size_hdd = 1073741824 # 1GB
bluestore_cache_size_ssd = 3221225472 # 3GB
osd_op_num_threads_per_shard = 2
osd_op_num_shards = 8
osd_recovery_max_active_hdd = 3
osd_recovery_max_active_ssd = 10
osd_max_backfills = 1
[mon]
mon_osd_down_out_interval = 300 # 5 хв перед out

Моніторинг та відновлення

Для моніторингу використовуйте вбудований модуль Prometheus через MGR:

ceph mgr module enable prometheus 

При падінні ноди позначте впалі OSD як out (ceph osd out osd.X), дочекайтеся завершення backfill (стан active+clean), потім видаліть їх (ceph osd purge osd.X --yes-i-really-mean-it).

Що входить у нашу роботу

• Аудит поточної інфраструктури та підбір конфігурації;
• Розгортання кластера (3+ ноди) з cephadm;
• CRUSH-топологія під вашу схему відмовостійкості;
• Тюнінг Bluestore та recovery-параметрів;
• Інтеграція з Prometheus/Grafana;
• Документація та runbook з обслуговування;
• Навчання команди базовим операціям.

Зв'яжіться з нами для консультації — оцінимо проект та запропонуємо оптимальне рішення. Отримайте попередню оцінку термінів та вартості на основі вашої апаратної конфігурації.

Терміни та вартість

Вартість розраховується індивідуально після аудиту вашої інфраструктури. Замовте консультацію — ми покажемо, наскільки ефективним може бути Ceph при правильному налаштуванні.