Ceph часть #3 - Ceph в продакшне: тюнинг, апгрейд до Tentacle и восстановление после катастроф

Кластер работает. Теперь начинается настоящая работа: выжать из него максимум производительности, не потерять данные при апгрейде и знать, что делать когда (не «если») что-то сломается.

Часть 1: Планирование железа — правильный старт

Перед тем как тюнить — убедитесь что железо подобрано правильно. Никакой тюнинг не исправит плохую архитектуру.

Сети: разделяйте публичную и кластерную

Худшее что можно сделать — смешать пользовательский трафик и репликацию в одну сеть.

Публичная сеть (client network): клиенты → MON/OSD
Кластерная сеть (cluster network): OSD → OSD (репликация)

Рекомендация:
- Публичная: 10 GbE minimum
- Кластерная: 25 GbE или bond из двух 10 GbE

Конфигурируем при bootstrap:

cephadm bootstrap \
    --mon-ip 192.168.10.11 \
    --cluster-network 192.168.20.0/24
# или после:
ceph config set global cluster_network 192.168.20.0/24

Размещение BlueStore компонентов

BlueStore — три уровня данных с разными требованиями:

Компонент	Что хранит	Требования	Рекомендация
DATA	Тела объектов	Ёмкость	HDD или SSD
DB (RocksDB)	Метаданные объектов	IOPS, latency	NVMe SSD
WAL	Write-Ahead Log	Высокие IOPS	NVMe SSD

Если все компоненты на одном диске — они конкурируют за I/O. Выносим DB и WAL на NVMe:

# osd-spec-nvme.yaml
service_type: osd
service_id: nvme-optimized
placement:
  host_pattern: 'ceph-node*'
data_devices:
  paths:
    - /dev/sdb  # HDD для данных
    - /dev/sdc
db_devices:
  paths:
    - /dev/nvme0n1  # NVMe для DB (разделяется между несколькими OSD)
wal_devices:
  paths:
    - /dev/nvme1n1  # отдельный NVMe для WAL

Золотое правило: один NVMe может обслуживать WAL/DB для 4-6 HDD OSD.

Расчёт оптимального числа OSD на сервер

Больше OSD — больше параллелизма, но больше RAM. Один OSD потребляет:

~1 GB RAM (HDD OSD, небольшие данные)
~2-4 GB RAM (SSD/NVMe OSD под нагрузкой)

BlueStore cache: по умолчанию 1/4 RAM на все OSD

# Проверяем потребление памяти OSD
ceph daemon osd.0 dump_mempools
ceph daemon osd.0 perf dump | grep -i mem

Часть 2: Тюнинг производительности

BlueStore: кэш и компрессия

# Размер BlueStore кэша — главный параметр
# По умолчанию: 1/4 от общей RAM (авто)
# Можно задать явно для SSD/NVMe (они меньше нуждаются в кэше)
ceph config set osd bluestore_cache_size_ssd 1073741824  # 1 GB для SSD OSD

# HDD нуждаются в бОльшем кэше
ceph config set osd bluestore_cache_size_hdd 536870912   # 512 MB для HDD OSD

# Компрессия — включаем для cold data
ceph osd pool set mypool compression_mode aggressive  # сжимать всегда
# или
ceph osd pool set mypool compression_mode passive     # сжимать если выгодно

ceph osd pool set mypool compression_algorithm zstd   # лучший ratio
# или snappy — быстрее, но меньше сжимает
# или lz4   — самый быстрый, минимальное сжатие

ceph osd pool set mypool compression_min_blob_size 8192  # мин. размер для сжатия

Настройка очереди I/O — mclock

С Ceph Pacific появился планировщик mclock, дающий QoS на уровне OSD:

# Проверяем текущий планировщик
ceph config get osd osd_op_queue
# должен быть: mclock_scheduler

# Приоритеты для workload'ов:
# client — пользовательские операции
# recovery — восстановление данных
# scrub — фоновая проверка

# Для HDD-кластера снижаем агрессивность recovery
ceph config set osd osd_mclock_scheduler_client_res 1
ceph config set osd osd_mclock_scheduler_recovery_res 1
ceph config set osd osd_mclock_scheduler_scrub_res 1

В Tentacle добавили защиту от нереалистичных значений IOPS capacity для mclock — теперь если измеренное значение IOPS слишком низкое (< 50 для HDD, < 1000 для SSD), планировщик использует последнее валидное значение.

Оптимизация для конкретных workload'ов

Для виртуальных машин (много случайных мелких I/O):

# Увеличиваем число OSD threads
ceph config set osd osd_op_num_shards 8
ceph config set osd osd_op_num_threads_per_shard 2

# Write pipeline
ceph config set osd bluestore_throttle_bytes 67108864  # 64 MB
ceph config set osd bluestore_throttle_deferred_bytes 134217728  # 128 MB

# Для NVMe — отключаем оверхед на большие буферы
ceph config set osd bluestore_max_blob_size_ssd 65536

Для больших последовательных записей (S3, медиа):

# Увеличиваем объект для EC
ceph config set osd osd_max_write_size 512  # MB

# RGW chunk size
ceph config set client rgw_obj_stripe_size 8388608  # 8 MB

Для read-heavy workload'ов:

# Увеличиваем BlueStore cache для чтения
ceph config set osd bluestore_cache_meta_ratio 0.4   # 40% для метаданных
ceph config set osd bluestore_cache_kv_ratio 0.4     # 40% для RocksDB

# Readahead на уровне BlueStore
ceph config set osd bluestore_default_buffered_read true

Настройка RBD для Kubernetes / Proxmox

# Включаем RBD кеширование на стороне клиента
cat >> /etc/ceph/ceph.conf << 'EOF'
[client]
rbd cache = true
rbd cache size = 134217728      # 128 MB
rbd cache max dirty = 100663296 # 96 MB
rbd cache target dirty = 67108864  # 64 MB
rbd cache max dirty age = 5.0
rbd cache writethrough until flush = true
EOF

# Для diskless систем — через librbd
rbd config image set vmpool/myvm-disk01 rbd_cache true
rbd config image set vmpool/myvm-disk01 rbd_cache_size 134217728

Часть 3: FastEC — как правильно использовать

FastEC — главная фича Tentacle для EC пулов. Разберём как мигрировать и что получаем.

Создаём новый EC пул с FastEC

# Профиль с ISA-L (новый дефолт в Tentacle)
ceph osd erasure-code-profile set fastec-profile \
    k=4 m=2 \
    plugin=isa \
    technique=reed_sol_van \
    crush-failure-domain=host

# Создаём пул
ceph osd pool create fastec-pool 64 64 erasure fastec-profile

# Включаем FastEC оптимизации
ceph osd pool set fastec-pool allow_ec_optimizations true

# Проверяем что включилось
ceph osd pool get fastec-pool allow_ec_optimizations

Миграция существующего EC пула

Если у вас был EC пул с Jerasure — миграция возможна без пересоздания данных:

# Обновляем OSD и MON до Tentacle (см. раздел Upgrade)

# После апгрейда — включаем оптимизации
ceph osd pool set oldpool allow_ec_optimizations true

# Следим за состоянием пула во время активации
watch ceph pg stat

Бенчмарк: насколько быстрее FastEC?

Сравниваем производительность:

# Устанавливаем инструменты
apt install ceph-common

# Тест записи в EC пул с FastEC
rados bench -p fastec-pool 60 write --no-cleanup

# Тест чтения
rados bench -p fastec-pool 60 seq

# Сравниваем с репликацией
rados bench -p vmpool 60 write --no-cleanup
rados bench -p vmpool 60 seq

# Очищаем после теста
rados bench -p fastec-pool 60 cleanup
rados bench -p vmpool 60 cleanup

По данным разработчиков и независимым тестам (blog nuvotex.de, 42on.com): FastEC при workload'е с преобладанием чтения и объектами среднего размера (1-4 MB) может превысить производительность репликации 3x при вдвое меньшем расходе места.

Часть 4: Апгрейд с Squid (19.x) до Tentacle (20.x)

Подготовка к апгрейду

Это самый важный раздел. Апгрейд Ceph — процедура, требующая внимания.

# 1. Проверяем здоровье — ОБЯЗАТЕЛЬНО перед началом
ceph status
ceph health detail

# Кластер ДОЛЖЕН быть в HEALTH_OK или HEALTH_WARN (без critical)
# НЕ начинайте при: OSD down, degraded PGs, incomplete PGs

# 2. Проверяем версии клиентов
ceph features  # показывает connected clients и их версии

# 3. Делаем снэпшот всех RBD образов (опционально, но разумно)
for pool in $(ceph osd pool ls); do
    for image in $(rbd ls $pool 2>/dev/null); do
        rbd snap create $pool/$image@pre-upgrade-$(date +%Y%m%d)
    done
done

# 4. Отключаем PG autoscaler на время апгрейда
ceph osd pool set noautoscale

# 5. Устанавливаем noout флаг (предотвращает rebalancing при рестарте OSD)
ceph osd set noout

Апгрейд через cephadm (рекомендуется)

# Запускаем апгрейд — cephadm делает всё сам, rolling update
ceph orch upgrade start --image quay.io/ceph/ceph:v20.2.0

# Мониторим прогресс
ceph orch upgrade status

# Детальный лог
ceph -W cephadm

# В реальном времени
watch ceph versions

Cephadm обновляет в правильном порядке:

MGR (сначала standby, потом active)
MON (по одному, ждёт quorum)
OSD (по одному, ждёт чистых PG после каждого)
MDS, RGW, другие сервисы

Вы можете поставить на паузу и возобновить:

ceph orch upgrade pause
ceph orch upgrade resume

Апгрейд вручную (для не-cephadm кластеров)

# Порядок строго важен!
# 1. MON
for mon_host in ceph-node1 ceph-node2 ceph-node3; do
    echo "Upgrading MON on $mon_host"
    ssh root@$mon_host "apt update && apt install -y ceph-mon"
    ssh root@$mon_host "systemctl restart ceph-mon.target"
    
    # Ждём возврата quorum
    sleep 30
    ceph mon stat
done

# Проверяем что все MON обновились
ceph mon dump | grep min_mon_release
# Должно показать: min_mon_release 20 (tentacle)

# 2. MGR
for mgr_host in ceph-node1 ceph-node2; do
    ssh root@$mgr_host "apt install -y ceph-mgr"
    ssh root@$mgr_host "systemctl restart ceph-mgr.target"
    sleep 10
done

# 3. OSD (по одному за раз!)
for osd_id in $(ceph osd ls); do
    osd_host=$(ceph osd find $osd_id | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['crush_location']['host'])")
    
    echo "Upgrading OSD.$osd_id on $osd_host"
    
    # Устанавливаем новый пакет
    ssh root@$osd_host "apt install -y ceph-osd"
    
    # Рестартуем OSD
    ssh root@$osd_host "systemctl restart ceph-osd@$osd_id"
    
    # Ждём пока OSD поднимется
    sleep 30
    
    # Проверяем что OSD up и PGs чистые
    while ceph pg stat | grep -q "degraded\|recovering"; do
        echo "Waiting for PGs to recover..."
        sleep 30
    done
    
    echo "OSD.$osd_id upgraded successfully"
done

# 4. После всех OSD — финализация
ceph osd require-osd-release tentacle

Финализация апгрейда

# Снимаем noout
ceph osd unset noout

# Включаем PG autoscaler обратно
ceph osd pool unset noautoscale

# Проверяем что все демоны на новой версии
ceph versions

# Убеждаемся что все фичи Tentacle включены
ceph osd dump | grep require_osd_release

# Включаем новые возможности Tentacle
ceph osd pool set mypool allow_ec_optimizations true  # если EC пул

Часть 5: Disaster Recovery — что делать когда всё плохо

Сценарий 1: OSD упал

# Смотрим что произошло
ceph health detail
ceph osd tree | grep -i down

# Оценка: сколько времени OSD уже down?
ceph osd info osd.5 | grep "last_clean_epoch"

# Быстрый рестарт (если проблема временная)
systemctl restart ceph-osd@5
# или через cephadm:
ceph orch daemon restart osd.5

# Если OSD не стартует — смотрим логи
journalctl -u ceph-osd@5 -n 100 --no-pager

# OSD сломан физически — нужно заменить
# Помечаем как out (начнётся rebalancing)
ceph osd out osd.5

# Ждём завершения rebalancing
watch ceph pg stat  # ждём active+clean

# Удаляем из кластера
ceph osd purge osd.5 --yes-i-really-mean-it

# Меняем диск, зачищаем и добавляем обратно
ceph orch daemon add osd ceph-node2:/dev/sdc

Сценарий 2: Целый хост упал

# Если хост не вернётся — убираем его OSD
# Для примера: умер ceph-node2 с OSD 3,4,5

# Помечаем все OSD хоста как out
ceph osd host-down-out ceph-node2  # если есть команда
# или вручную:
for osd in 3 4 5; do ceph osd out osd.$osd; done

# После rebalancing — удаляем
for osd in 3 4 5; do
    ceph osd purge osd.$osd --yes-i-really-mean-it
done

# Удаляем MON если он был на этом хосте
ceph mon remove ceph-node2

# Удаляем хост из оркестратора
ceph orch host drain ceph-node2
ceph orch host rm ceph-node2 --force

# Проверяем здоровье после
ceph status

Сценарий 3: PG застряла в inconsistent/corrupt

# Находим проблемные PG
ceph pg dump | grep -v "active+clean"

# Запускаем repair
ceph pg repair 3.1a

# Если repair не помогает — более агрессивно
ceph osd set nodeep-scrub  # временно отключаем deep-scrub

# Смотрим детали PG
ceph pg 3.1a query

# OSD с повреждёнными данными
ceph osd tree
ceph pg 3.1a get  # какие OSD участвуют

# Принудительное восстановление из другой реплики
# (осторожно! только если уверены что данные на primary повреждены)
ceph pg force-recovery 3.1a

Сценарий 4: MON потерял quorum

# Проверяем статус MON
ceph mon stat
ceph mon dump

# Если 1 из 3 MON не отвечает — quorum ещё есть (2 из 3)
# Рестартуем проблемный
systemctl restart ceph-mon@ceph-node2

# Если quorum потерян (0 из 3 доступны) — режим аварийного восстановления
# Это серьёзная ситуация

# На одном живом MON:
ceph-mon -i ceph-node1 --extract-monmap /tmp/monmap
monmaptool --print /tmp/monmap

# Удаляем недостижимые MON из карты
monmaptool --rm ceph-node2 /tmp/monmap
monmaptool --rm ceph-node3 /tmp/monmap

# Инжектируем исправленную monmap
ceph-mon -i ceph-node1 --inject-monmap /tmp/monmap

# Запускаем с одним MON
ceph-mon -i ceph-node1

# Добавляем новые MON после стабилизации
ceph orch apply mon ceph-node1,ceph-node2,ceph-node3

Сценарий 5: Восстановление удалённого RBD образа

# Если образ удалён — проверяем trash
rbd trash ls vmpool

# Восстанавливаем из trash (образы там держатся delay_seconds)
rbd trash restore vmpool/trash-id

# Если включён rbd-mirror с журналированием — восстановление из журнала
# В крайнем случае — восстановление из снэпшота
rbd snap ls vmpool/myvm-disk01
rbd snap rollback vmpool/myvm-disk01@pre-upgrade-20241201

# Восстановление из бэкапа через export
rbd export vmpool/myvm-disk01 /mnt/backup/myvm-disk01.raw
# Восстановление:
rbd import /mnt/backup/myvm-disk01.raw vmpool/myvm-disk01-restored

Часть 6: Продвинутые возможности Tentacle

SMB shares из CephFS

# Создаём SMB кластер (Active Directory интеграция)
ceph smb cluster create mysmb \
    active-directory \
    --domain DC=corp,DC=example,DC=com \
    --realm CORP.EXAMPLE.COM \
    --dns-server 192.168.1.10

# Добавляем CephFS share
ceph smb share create mysmb myshare \
    --cephfs-volume myfs \
    --cephfs-path /shares/myshare

# Проверяем
ceph smb cluster ls
ceph smb share ls

# Через Dashboard — аналогично с GUI

RBD Live Migration — новинка Tentacle

Мгновенный импорт образов из других кластеров без копирования данных:

# Импорт из другого Ceph кластера (native format)
rbd migration prepare \
    --source-spec '{"type":"native","cluster_name":"src-cluster","pool_name":"vmpool","image_name":"myvm"}' \
    dstpool/myvm-imported

# Импорт через NBD (из любого источника)
rbd migration prepare \
    --source-spec '{"type":"nbd","uri":"nbd://192.168.1.100:10809/disk"}' \
    dstpool/imported-disk

# Запускаем миграцию (фоновая копия данных)
rbd migration execute dstpool/myvm-imported

# Когда завершится — фиксируем
rbd migration commit dstpool/myvm-imported

Магия в том, что образ доступен для чтения и записи немедленно — пока данные копируются в фоне, читаются напрямую с источника.

Data Availability Score — новый инструмент мониторинга

# Включаем tracking
ceph config set global enable_availability_tracking true

# Проверяем score для каждого пула
ceph osd pool availability-status

# Вывод:
# POOL    AVAILABLE  SCORE
# vmpool  yes        1.00
# ecpool  yes        0.99   ← одна PG в не-clean состоянии

# Очищаем статус для пула после устранения проблемы
ceph osd pool clear-availability-status vmpool

Scrub: планирование глубоких проверок

# Принудительный scrub для конкретной PG
ceph pg scrub 1.a3
ceph pg deep-scrub 1.a3

# Scrub всего пула
ceph osd pool scrub vmpool

# Планирование — ограничиваем scrub нерабочим временем
ceph config set osd osd_scrub_begin_hour 1    # с 1:00
ceph config set osd osd_scrub_end_hour 6      # до 6:00
ceph config set osd osd_scrub_min_interval 86400   # не чаще раза в день
ceph config set osd osd_deep_scrub_interval 604800  # deep-scrub раз в неделю

# Статус scrub
ceph pg dump | awk '{print $1, $16, $17}' | head -30
# PG_ID | LAST_SCRUB | LAST_DEEP_SCRUB

Часть 7: Capacity planning и масштабирование

Добавление нового хоста и OSD

# Добавляем хост
ceph orch host add ceph-node4 192.168.10.14

# Добавляем OSD
ceph orch daemon add osd ceph-node4:/dev/sdb
ceph orch daemon add osd ceph-node4:/dev/sdc

# Автоматическая ребалансировка начнётся сразу
# Следим за прогрессом
ceph progress
watch ceph df

Расчёт сырого хранилища

Полезное место = (Общий объём) / overhead_factor

Репликация 3x: overhead = 3.0
EC 4+2:         overhead = 1.5
EC 6+3:         overhead = 1.5
EC 8+3:         overhead = 1.375

Для кластера с 9 × 4TB HDD и репликацией 3x:
- Сырое: 36 TB
- Полезное: 36 / 3 = 12 TB (минус ~10% overhead Ceph = ~10.8 TB)

Правило большого пальца: не заполняйте более 80% полезного места!
При 80%+ производительность падает из-за фрагментации и задержек recovery.

Мониторинг через Prometheus

# ceph exporter уже встроен, prometheus конечные точки:
# http://ceph-node1:9283/metrics  - MGR prometheus module

# Ключевые метрики для алертов:
# ceph_health_status != 0          — нездоровый кластер
# ceph_osd_in == 0                 — OSD out
# ceph_pg_degraded > 0             — деградированные PG
# ceph_osd_available_bytes < 20%   — заканчивается место
# ceph_osd_apply_latency_ms > 50   — высокая задержка записи

# Пример alertmanager rule:
cat >> /etc/prometheus/rules/ceph.yml << 'EOF'
groups:
- name: ceph
  rules:
  - alert: CephHealthError
    expr: ceph_health_status == 2
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Ceph cluster is in ERROR state"

  - alert: CephOSDDown  
    expr: ceph_osd_up == 0
    for: 2m
    labels:
      severity: warning

  - alert: CephDiskAlmostFull
    expr: (ceph_osd_stat_bytes_used / ceph_osd_stat_bytes) > 0.80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Ceph OSD {{ $labels.ceph_daemon }} is {{ $value | humanizePercentage }} full"
EOF

Чеклист: Ceph в продакшне

До разворачивания:

[ ] Минимум 3 физических хоста (лучше 5+ для отказоустойчивости)
[ ] Отдельные сети для публичного и кластерного трафика (10 GbE+)
[ ] NTP синхронизирован на всех узлах
[ ] SSD/NVMe для BlueStore DB и WAL
[ ] Резервные диски наготове для горячей замены
[ ] CRUSH map настроен с учётом физической топологии (стойки, ЦОД)

Оперативный мониторинг:

[ ] Prometheus + Grafana с Ceph дашбордами
[ ] Алерты на HEALTH_ERR, OSD down, PG degraded, диск >80%
[ ] mgmt-gateway настроен (Tentacle 20.x)
[ ] certmgr управляет TLS сертификатами

Регулярные процедуры:

[ ] Ежедневная проверка ceph status
[ ] Еженедельный deep-scrub (автоматически через cron)
[ ] Тестирование восстановления из снэпшотов раз в квартал
[ ] Обновления безопасности: следим за ceph-announce

Перед апгрейдом:

[ ] Кластер в HEALTH_OK
[ ] Снэпшоты критичных RBD образов
[ ] ceph osd set noout
[ ] Тест в staging среде
[ ] Откат-план: как вернуться на предыдущую версию (downgrade невозможен, нужен rollback через снэпшоты)

Где учиться дальше

Официальная документация:

docs.ceph.com — эталонная документация, всегда актуальная
ceph.io/en/news/blog — официальный блог с release notes и углублёнными техническими статьями

Сообщество:

ceph-users@ceph.io — рассылка для пользователей
irc.oftc.net #ceph — IRC канал
Cephalocon — ежегодная конференция сообщества

Практика:

Vagrant + VirtualBox: поднимите тестовый кластер на ноутбуке (cephadm работает в VM)
Rook — Ceph оператор для Kubernetes, хороший способ изучить интеграцию
Proxmox VE имеет встроенный Ceph — отличная песочница

Ceph — это не инструмент «поставил и забыл». Это живая система, требующая понимания и регулярного внимания. Но когда вы научитесь с ней работать — получаете petabyte-scale хранилище корпоративного уровня на обычном commodity железе. Это стоит вложенных усилий.

Sign In