Пилотный Ceph-кластер: объектное хранилище как S3-совместимый бэкап-таргет

В начале года мы записали в план довести до ума историю с резервным хранилищем у одного из клиентов на сопровождении. Задача формулировалась примерно так: нужно место, куда льются бэкапы с нескольких серверов, которое умеет S3-совместимый API, переживает отказ одного диска или одного узла и не требует дорогой SAN-железки. Ceph с Hammer-релизом выглядел как логичный кандидат - поставили пилот на трёх серверах и смотрели.

Стенд

Три физических сервера, каждый с четырьмя SATA-дисками под данные и одним SSD под журналы OSD. На каждом узле - CentOS 7, Ceph 0.94 (Hammer). Сеть: отдельный 1G-свитч под кластерный трафик (replication network) и основная сеть под клиентский доступ.

Раскладка по ролям:

• MON (Monitor) - по одному на каждом узле, итого три. Кворум работает при потере одного.
• OSD (Object Storage Daemon) - по четыре на узел, итого двенадцать. Размещение журналов на SSD убирает большую часть write latency.
• RGW (RADOS Gateway) - шлюз поднят на одном узле, он же отдаёт S3-совместимый HTTP API.

ceph-deploy упростил первоначальный разворот до разумного: раскладываешь SSH-ключи, создаёшь кластер командой, добавляешь MON-ы, потом OSD-ы по дискам. Реально ушло около двух часов до рабочего состояния «HEALTH_OK».

CRUSH: что это и зачем его трогать

CRUSH (Controlled Replication Under Scalable Hashing) - алгоритм, по которому Ceph решает на каких OSD хранить каждый объект. По умолчанию кластер знает о серверах как об «узлах» и раскладывает реплики так, чтобы они не лежали на одном узле. Это значит: при потере одного сервера полного коппируешь данных не будет - каждый объект есть на двух других.

Важный момент: overhead CRUSH не бесплатный. При каждом чтении или записи клиент вычисляет карту - куда идти за объектом - локально, без запроса к MON. Это хорошо для масштабирования, но требует что карта у клиента актуальна. При изменении топологии (добавил OSD, переложил диск) кластер перебалансирует данные, и в этот момент нагрузка на сеть и диски заметно растёт.

На трёх узлах с replication factor 3 (по умолчанию для RBD, мы поставили 2 для объектного хранилища) CRUSH overhead в спокойном состоянии практически не виден. Головная боль начинается при «rebalancing» - мы специально выключили один OSD и посмотрели: кластер сразу начал перекладывать данные, I/O на остальных дисках подскочил, latency выросла вдвое. Минут через двадцать устаканилось.

RGW и S3-совместимость

RADOS Gateway поднимается поверх ceph-radosgw и отдаёт S3-совместимый API на HTTP (и HTTPS если настроить). Мы подключили Veeam Backup к хранилищу через CloudBerry Backup: он умеет S3-совместимый API, принимает endpoint, access key, secret key, bucket - и льёт туда резервные копии. Veeam в этой схеме пишет на локальную папку или SMB-шару, CloudBerry подхватывает и заливает в RGW.

Работает. Авторизация через keystone не нужна для такого сценария: RGW создаёт пользователей через radosgw-admin, выдаёт ключи, и этого достаточно.

Одна неочевидность: multi-part upload у Veeam при крупных файлах. RGW это поддерживает, но если сессия прерывается - незавершённые части остаются и занимают место. Нужно периодически чистить через s3cmd или аналог. Мелочь, но без мониторинга незаметно съедает пространство.

Сравнение с NFS по latency

Предыдущее решение у клиента - NFS-шара с одного сервера. Мы прогнали одинаковую нагрузку (последовательная запись крупных файлов, имитация backup-стрима) через NFS и через RGW.

Результат не в пользу Ceph на мелких объектах. На файлах меньше 1 МБ RGW заметно проигрывает: HTTP-overhead и накладные расходы на хэшинг объектов дают о себе знать. На крупных файлах (резервные копии - это обычно гигабайты) разрыв сокращается, и Ceph начинает выглядеть нормально. Последовательная пропускная способность при записи больших объектов сопоставима с NFS - иногда чуть хуже, иногда чуть лучше в зависимости от загрузки кластерной сети.

Latency при чтении похожая история: случайный доступ к мелким объектам - NFS быстрее. Последовательное чтение крупных блоков - паритет.

Вывод из этого простой: Ceph RGW - не замена NFS для файловой нагрузки. Это замена объектного хранилища типа S3 для конкретного сценария: бэкапы, архивы, бинарные артефакты, где важна отказоустойчивость и масштабируемость ёмкости, а не минимальная latency.

Что не так в пилоте

Три сервера - это минимум для кворума MON, но для OSD маловато если думать о надёжном отказоустойчивом пуле. Потеря одного узла при replication factor 2 оставляет вас с единственной копией данных - и кластер это понимает: уходит в HEALTH_WARN и не принимает новую запись до восстановления. С тремя репликами и тремя узлами при отказе одного вы в принципе в нормальном состоянии, но headroom нет никакого.

Для production мы бы смотрели минимум на пять узлов - чтобы один можно было вывести на обслуживание и при этом ещё иметь запас при одновременном отказе диска на другом.

Административный инструментарий у Ceph пока что спартанский: ceph status, ceph osd tree, ceph df. Работает, но для красивого дашборда нужно интегрировать с Zabbix или Graphite отдельно - out of the box мониторинга нет.

Итог

Пилот показал рабочую механику: S3-совместимый бэкап-таргет на трёх серверах поднимается, держит нагрузку, переживает потерю диска. CRUSH-алгоритм делает своё дело незаметно в штатном режиме и громко - при rebalancing. NFS по latency выигрывает на мелких объектах, но это сравнение некорректное - у них разные задачи.

Рекомендацию для продуктивного развёртывания пока не даём: хочется посмотреть на поведение под длительной нагрузкой и понять как ведёт себя RGW при деградации кластера. Но направление выглядит правильным - особенно для сценариев где нужна горизонтальная масштабируемость хранилища без апгрейда одной большой железки.