Ceph часть #2 - Разворачиваем Ceph Tentacle с нуля: от чистых серверов до рабочего кластера

В прошлой статье мы разобрались с теорией — теперь руки в землю. Будем разворачивать минимальный продакшн-кластер Ceph Tentacle (20.2.x) через cephadm — официальный инструмент оркестровки, который умеет всё: установку, конфигурирование, обновление, добавление узлов.

Что мы будем строить

Минимальная продакшн-конфигурация:

┌─────────────────────────────────────────────────────┐
│  ceph-node1  │  ceph-node2  │  ceph-node3           │
│              │              │                       │
│  MON + MGR   │  MON + MGR   │  MON                 │
│  OSD.0       │  OSD.3       │  OSD.6               │
│  OSD.1       │  OSD.4       │  OSD.7               │
│  OSD.2       │  OSD.5       │  OSD.8               │
│              │              │                       │
│  /dev/sdb    │  /dev/sdb    │  /dev/sdb            │
│  /dev/sdc    │  /dev/sdc    │  /dev/sdc            │
│  /dev/sdd    │  /dev/sdd    │  /dev/sdd            │
└─────────────────────────────────────────────────────┘

Требования к каждому узлу:

OS: Ubuntu 22.04 LTS или Debian 12 (рекомендуется), RHEL 9 тоже ок
RAM: минимум 16 GB (рекомендуется 32+ GB для продакшна)
CPU: 4+ ядра
Сеть: минимум 1 GbE, лучше 10 GbE; отдельная сеть для репликации — хорошая идея
Диски: минимум 1 диск для OSD (не системный!), лучше SSD или NVMe

Важно: диски для OSD должны быть пустыми — без разделов, без файловых систем. BlueStore сам их форматирует.

Шаг 1: Подготовка всех узлов

Выполняем на каждом из трёх узлов.

Обновление системы и базовые пакеты

apt update && apt upgrade -y
apt install -y \
    chrony \
    curl \
    python3 \
    python3-pip \
    lvm2 \
    podman \   # или docker
    ntp

Почему chrony важен: Ceph очень чувствителен к рассинхронизации времени. Разница > 5 секунд между узлами вызывает предупреждения и может дестабилизировать кластер. Убедитесь что NTP работает:

timedatectl status
chronyc tracking

Настройка hostname и /etc/hosts

# На ceph-node1:
hostnamectl set-hostname ceph-node1

# На всех трёх узлах добавляем в /etc/hosts:
cat >> /etc/hosts << 'EOF'
192.168.10.11  ceph-node1
192.168.10.12  ceph-node2
192.168.10.13  ceph-node3
EOF

SSH ключи: cephadm общается через SSH

Генерируем ключ на первом узле (bootstrap узел) и распространяем:

# На ceph-node1:
ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519

# Копируем на все узлы (включая node1 самого себя):
for node in ceph-node1 ceph-node2 ceph-node3; do
    ssh-copy-id -i /root/.ssh/id_ed25519.pub root@$node
done

# Проверяем:
for node in ceph-node1 ceph-node2 ceph-node3; do
    echo "=== $node ==="
    ssh root@$node "hostname && uname -r"
done

Подготовка дисков: убеждаемся что они чистые

# Проверяем состояние дисков
lsblk
fdisk -l /dev/sdb
wipefs -a /dev/sdb  # если нужно очистить

# cephadm сам зачистит диски при добавлении — если они "чистые"
# (без LVM, без партиций, без файловой системы)
# Принудительно зачистить:
ceph-volume lvm zap /dev/sdb --destroy  # после установки ceph

Шаг 2: Bootstrap первого узла

Устанавливаем cephadm

# На ceph-node1:
curl --silent --remote-name --location \
    https://github.com/ceph/ceph/raw/reef/src/cephadm/cephadm

chmod +x cephadm

# Устанавливаем в систему
./cephadm install

# Добавляем репозиторий Tentacle
cephadm add-repo --release tentacle

# Устанавливаем ceph-common (для команды ceph)
cephadm install ceph-common

Bootstrap кластера

cephadm bootstrap \
    --mon-ip 192.168.10.11 \
    --cluster-network 192.168.20.0/24 \
    --initial-dashboard-user admin \
    --initial-dashboard-password 'YourStrongPassword!123' \
    --allow-fqdn-hostname \
    --skip-monitoring-stack  # добавим мониторинг позже отдельно

Что делает эта команда за кулисами:

Создаёт директории конфигурации /etc/ceph/
Генерирует ключи аутентификации
Поднимает первый MON в контейнере
Поднимает MGR
Активирует модуль Dashboard
Пишет /etc/ceph/ceph.conf и /etc/ceph/ceph.client.admin.keyring

После успешного выполнения вы увидите URL дашборда:

Ceph Dashboard is now available at:
             URL: https://ceph-node1:8443/
            User: admin
        Password: YourStrongPassword!123

Параметр --cluster-network: Это сеть для трафика репликации между OSD. Если у вас только одна сеть — уберите этот параметр. Но если есть выделенная сеть — обязательно используйте её, это критично для производительности публичной сети.

Шаг 3: Добавляем узлы в кластер

Проверяем первый узел

ceph status
# Должны увидеть: mon: 1 mons at quorum...
# health: HEALTH_WARN (это нормально на старте)

ceph orch status
# Оркестратор должен быть активен

Добавляем ceph-node2 и ceph-node3

# На ceph-node1 — добавляем public SSH ключ cephadm в авторизованные на узлах
ceph cephadm get-pub-key > /tmp/ceph.pub

ssh root@ceph-node2 "mkdir -p /root/.ssh && \
    cat >> /root/.ssh/authorized_keys" < /tmp/ceph.pub

ssh root@ceph-node3 "mkdir -p /root/.ssh && \
    cat >> /root/.ssh/authorized_keys" < /tmp/ceph.pub

# Добавляем хосты в кластер
ceph orch host add ceph-node2 192.168.10.12
ceph orch host add ceph-node3 192.168.10.13

# Проверяем
ceph orch host ls

Шаг 4: Добавляем MON и MGR

# По умолчанию cephadm хочет 5 MON — для нас 3 достаточно
ceph orch apply mon 3

# Проверяем что MON есть на всех трёх узлах
ceph orch ps --daemon-type mon

# Добавляем второй MGR (для failover)
ceph orch apply mgr 2

Ждём пока cephadm автоматически запустит MON на node2 и node3. Следим:

watch ceph status
# Ждём: mon: 3 mons at quorum ceph-node1,ceph-node2,ceph-node3

Шаг 5: Добавляем OSD — сердце кластера

Инвентаризация доступных дисков

# Смотрим что cephadm видит на всех узлах
ceph orch device ls

# Вывод покажет диски и их статус:
# HOST        PATH      TYPE  SIZE  AVAILABLE  REFRESHED
# ceph-node1  /dev/sdb  hdd   2TiB  Yes        12s ago
# ceph-node1  /dev/sdc  hdd   2TiB  Yes        12s ago
# ...

Диск помечен как AVAILABLE если он полностью пустой. Если нет — смотрим причину в колонке REJECT REASONS.

Автоматическое добавление всех доступных дисков

# Самый простой способ — использовать все доступные диски
ceph orch apply osd --all-available-devices

# Следим за прогрессом
watch ceph osd tree

Ручное добавление конкретных дисков (рекомендуется для продакшна)

# Добавляем по одному — больше контроля
ceph orch daemon add osd ceph-node1:/dev/sdb
ceph orch daemon add osd ceph-node1:/dev/sdc
ceph orch daemon add osd ceph-node1:/dev/sdd

ceph orch daemon add osd ceph-node2:/dev/sdb
ceph orch daemon add osd ceph-node2:/dev/sdc
ceph orch daemon add osd ceph-node2:/dev/sdd

ceph orch daemon add osd ceph-node3:/dev/sdb
ceph orch daemon add osd ceph-node3:/dev/sdc
ceph orch daemon add osd ceph-node3:/dev/sdd

OSD Service Spec для воспроизводимой конфигурации

Для инфраструктуры-как-код создаём spec-файл:

# osd-spec.yaml
service_type: osd
service_id: default
placement:
  host_pattern: 'ceph-node*'
data_devices:
  paths:
    - /dev/sdb
    - /dev/sdc
    - /dev/sdd
# Если есть отдельные SSD для WAL/DB:
# db_devices:
#   paths:
#     - /dev/nvme0n1
# wal_devices:
#   paths:
#     - /dev/nvme1n1

ceph orch apply -i osd-spec.yaml

Шаг 6: Проверяем здоровье кластера

После добавления OSD кластер начнёт балансировку данных (backfill). Это нормально и займёт время. Следим:

# Общий статус
ceph status

# Подробный статус OSD
ceph osd stat
ceph osd df  # использование дискового пространства

# Статус PG
ceph pg stat

# Потребление ресурсов
ceph df detail

# Дерево OSD с весами
ceph osd tree

Хорошее состояние:

cluster:
  id:     a7f64266-0894-4f1e-a635-d0aeaca0e993
  health: HEALTH_OK

services:
  mon: 3 daemons, quorum ceph-node1,ceph-node2,ceph-node3
  mgr: ceph-node1.xxx(active), ceph-node2.xxx(standby)
  osd: 9 osds: 9 up (since 5m), 9 in (since 5m)

data:
  pools: 1 pools, 1 pgs
  objects: 0 objects, 0 B
  usage:   450 MiB used, 54 TiB / 54 TiB avail
  pgs:     1 active+clean

Шаг 7: Создаём пулы хранения

Пул — логический контейнер для данных. Каждый пул имеет свою политику репликации/EC, количество PG и другие параметры.

Пул с репликацией 3x (для VM, баз данных)

# Создаём пул
ceph osd pool create vmpool 32 32  # 32 PG

# Настраиваем репликацию
ceph osd pool set vmpool size 3      # 3 копии
ceph osd pool set vmpool min_size 2  # минимум 2 для записи

# Тип пула - для RBD
ceph osd pool application enable vmpool rbd

# Инициализируем для RBD
rbd pool init vmpool

# Проверяем
ceph osd pool ls detail

Сколько PG нужно?

Формула: PG = (OSDs * 100) / pool_size

Для нашего кластера (9 OSD, репликация 3):

PG = (9 * 100) / 3 = 300 — но возьмём ближайшую степень 2 = 256

# Изменить количество PG (только увеличение)
ceph osd pool set vmpool pg_num 64
ceph osd pool set vmpool pgp_num 64

С Ceph Luminous появился PG autoscaler — он сам подбирает оптимальное число PG:

# Включаем автоскалер для пула
ceph osd pool set vmpool pg_autoscale_mode on

# Глобально включить автоскалер
ceph mgr module enable pg_autoscaler
ceph config set global osd_pool_default_pg_autoscale_mode on

Пул с Erasure Coding (для S3/бэкапов)

# Создаём EC-профиль
# k=4 data chunks, m=2 parity chunks = 6 OSD минимум
# overhead = 1.5x против 3x у репликации
ceph osd erasure-code-profile set myec \
    k=4 m=2 \
    plugin=isa \
    crush-failure-domain=host

# Просматриваем профиль
ceph osd erasure-code-profile get myec

# Создаём пул с EC
ceph osd pool create ecpool 32 32 erasure myec

# Включаем FastEC оптимизации (Tentacle 20.x+)
ceph osd pool set ecpool allow_ec_optimizations true

# Для работы RGW с EC нужен overlay pool
ceph osd pool create ecpool-index 16  # репликация для индексов
ceph osd pool application enable ecpool rgw
ceph osd pool application enable ecpool-index rgw

Шаг 8: Подключаем RBD — блочное хранилище

Создаём RBD-образ

# Создаём образ диска 100 GB
rbd create --size 102400 vmpool/myvm-disk01

# Смотрим информацию
rbd info vmpool/myvm-disk01

# Листинг образов в пуле
rbd ls vmpool

# Размер всех образов
rbd du vmpool

Монтируем на Linux через kernel driver

# Маппируем образ как блочное устройство
rbd device map vmpool/myvm-disk01 --id admin \
    --keyring /etc/ceph/ceph.client.admin.keyring

# Видим устройство
rbd device list
# /dev/rbd0 → vmpool/myvm-disk01

# Форматируем и монтируем
mkfs.xfs /dev/rbd0
mkdir /mnt/rbd-data
mount /dev/rbd0 /mnt/rbd-data

# Авто-монтирование через /etc/fstab через rbdmap
# /etc/ceph/rbdmap:
# vmpool/myvm-disk01 id=admin,keyring=/etc/ceph/ceph.client.admin.keyring
systemctl enable rbdmap

RBD для Proxmox VE

Proxmox имеет встроенную поддержку Ceph. Добавляем через GUI или:

# На Proxmox хосте устанавливаем ceph-клиент
apt install ceph-common

# Копируем конфиг и ключ с Ceph кластера
scp root@ceph-node1:/etc/ceph/ceph.conf /etc/pve/ceph.conf
scp root@ceph-node1:/etc/ceph/ceph.client.admin.keyring \
    /etc/pve/priv/ceph/

# Или создаём отдельного пользователя с ограниченными правами
ceph auth get-or-create client.proxmox \
    mon 'profile rbd' \
    osd 'profile rbd pool=vmpool' \
    mgr 'profile rbd pool=vmpool' \
    > /tmp/ceph.client.proxmox.keyring

# Добавляем Ceph storage в Proxmox
pveceph pool create vmpool --pg_num 64 --pg_autoscale_mode on

Шаг 9: CephFS — распределённая файловая система

# Создаём CephFS (автоматически создаёт metadata и data пулы)
ceph fs volume create myfs --placement="3"

# Проверяем статус MDS
ceph mds stat
ceph fs status myfs

# Монтируем через FUSE (для тестов)
apt install ceph-fuse
mkdir /mnt/cephfs
ceph-fuse /mnt/cephfs -m ceph-node1:6789

# Или через kernel driver (лучше производительность)
# Получаем ключ
ceph auth get-key client.admin | base64
# Монтируем:
mount -t ceph ceph-node1:6789:/ /mnt/cephfs \
    -o name=admin,secret=<base64-key>

# В /etc/fstab:
# ceph-node1:6789,ceph-node2:6789:/ /mnt/cephfs ceph \
#   name=admin,secretfile=/etc/ceph/admin.secret,noatime 0 0

Subvolumes для Kubernetes

# Создаём subvolume group
ceph fs subvolumegroup create myfs k8s

# Создаём subvolume (persistent volume)
ceph fs subvolume create myfs pvc-001 --group-name k8s --size 10G

# Получаем путь
ceph fs subvolume getpath myfs pvc-001 --group-name k8s
# /volumes/k8s/pvc-001/...

Шаг 10: RGW — S3-совместимое объектное хранилище

# Разворачиваем RGW через cephadm
ceph orch apply rgw myrgw --placement="2 ceph-node1 ceph-node2" \
    --port=8080

# Проверяем статус
ceph orch ps --daemon-type rgw

# Создаём пользователя
radosgw-admin user create \
    --uid=s3user \
    --display-name="S3 User" \
    --email=s3user@example.com

# Получаем ключи
radosgw-admin user info --uid=s3user
# access_key и secret_key для S3 клиентов

# Тестируем через s3cmd или mc (MinIO client)
apt install s3cmd
s3cmd --configure  # вводим access_key, secret_key, endpoint

# Или через AWS CLI
aws configure  # вводим ключи
aws --endpoint-url http://ceph-node1:8080 s3 mb s3://mybucket
aws --endpoint-url http://ceph-node1:8080 s3 ls
aws --endpoint-url http://ceph-node1:8080 s3 cp /tmp/test.txt s3://mybucket/

Шаг 11: Стек мониторинга

Ceph Tentacle поставляет готовый стек мониторинга через cephadm. В Tentacle появился новый mgmt-gateway — единая точка входа:

# Разворачиваем полный стек мониторинга
ceph orch apply prometheus
ceph orch apply grafana
ceph orch apply alertmanager
ceph orch apply node-exporter

# Новый в Tentacle: mgmt-gateway (nginx reverse proxy + TLS)
cat > mgmt-gateway.yaml << 'EOF'
service_type: mgmt-gateway
placement:
  count: 2  # HA — два инстанса
spec:
  port: 443
  enable_auth: true  # требовать аутентификацию
EOF

ceph orch apply -i mgmt-gateway.yaml

# Проверяем
ceph orch ps --daemon-type mgmt-gateway

Теперь Dashboard, Grafana, Prometheus — всё доступно через один HTTPS endpoint на порту 443.

Встроенные Grafana-дашборды Ceph показывают:

OSD latency и throughput
Pool utilization
MON quorum status
PG состояния
Алерты

Полезные команды для ежедневной работы

# === КЛАСТЕР ===
ceph status              # общий статус
ceph health detail       # детали о проблемах
ceph df                  # использование пространства
ceph versions            # версии всех демонов

# === OSD ===
ceph osd tree            # топология
ceph osd df              # место по OSD
ceph osd perf            # latency метрики
ceph osd dump            # полный дамп карты OSD

# Вывести из эксплуатации OSD (graceful)
ceph osd out osd.5
ceph osd drain osd.5     # ждём пока PG переедут

# === PG ===
ceph pg stat             # статус всех PG
ceph pg dump | grep -v active+clean  # проблемные PG
ceph pg repair 1.a3      # принудительный repair конкретной PG

# === Логи ===
ceph log last 20         # последние записи кластерного лога
journalctl -u ceph-osd@0 -f  # лог конкретного OSD

# === Оркестратор ===
ceph orch ls             # список сервисов
ceph orch ps             # список демонов с состоянием
ceph orch events         # события оркестратора

Типичные проблемы при развёртывании

HEALTH_WARN: too few PGs

ceph health detail
# HEALTH_WARN too few PGs per OSD

# Увеличиваем PG для затронутых пулов
ceph osd pool set vmpool pg_num 64
ceph osd pool set vmpool pgp_num 64

OSD не добавляется: диск не определяется как доступный

# Смотрим причины отказа
ceph orch device ls --wide

# Часто причина: старые сигнатуры на диске
# Зачищаем через ceph-volume
cephadm shell -- ceph-volume lvm zap /dev/sdb --destroy

# Или более агрессивно
wipefs -a /dev/sdb
dd if=/dev/zero of=/dev/sdb bs=4M count=10

clock skew detected

# Проверяем время на всех узлах
for node in ceph-node1 ceph-node2 ceph-node3; do
    echo "$node: $(ssh root@$node date)"
done

# На проблемном узле — синхронизируем немедленно
chronyc makestep
timedatectl set-ntp true

Кластер застрял в rebalancing надолго

# Смотрим прогресс
ceph progress

# Ускоряем (только во время обслуживания, не в бою)
ceph tell osd.* injectargs --osd-max-backfills 8
ceph tell osd.* injectargs --osd-recovery-max-active 8

# После — возвращаем в норму
ceph tell osd.* injectargs --osd-max-backfills 3

В следующей, финальной статье: производительность и тюнинг кластера, стратегии апгрейда с предыдущих версий, disaster recovery и продвинутые сценарии использования.

Далее читай - Часть #3

Sign In