Ceph на трёх узлах: пилот распределённого хранилища для VM-дисков и S3-совместимого объектного слоя

Несколько месяцев назад мы смотрели на Storage Spaces как на способ убрать аппаратный контроллер из уравнения. Идея понравилась, но упёрлись в ограничение: это Windows-стек, и за его рамки не выйдешь. Тогда один из наших инженеров притащил на летучку тему Ceph - распределённой системы хранения данных, где нет ни единой точки отказа и нет единого контроллера вообще. Решили поднять пилот.

Что за зверь. Ceph - это не NAS и не SAN в привычном смысле. Внутри работает RADOS - объектное хранилище, поверх которого живут три интерфейса: RBD (блочные устройства, читай - диски для виртуалок), CephFS (файловая система, её мы не трогали) и RADOSGW (HTTP-шлюз с S3- и Swift-совместимым API). Управляет всем Monitor-кластер - три демона, которые следят за картой кластера и консенсусом. OSD-демоны сидят на каждом диске и разговаривают напрямую друг с другом, минуя какой-либо центральный брокер.

Железо пилота. Три старых сервера, снятых с другого проекта: по 32 ГБ RAM, по четыре диска на 2 ТБ каждый и отдельная гигабитная сетка под кластерный трафик (это важно - смешивать клиентский и репликационный трафик мы побоялись). Итого 12 OSD, фактор репликации выставили в 3 - каждый объект на всех трёх узлах. Такой расклад выдерживает потерю любого одного сервера без потери данных.

Где застряли на настройке. Если честно, первые попытки ушли в никуда из-за ceph-deploy - утилиты, которая обещает «поднять кластер за пять команд», но на практике валится с невнятными ошибками при малейшем несовпадении hostname и /etc/hosts. Пришлось разобраться руками:

• Конфигурация CRUSH-карты - алгоритм, который решает, на каких OSD хранить данные. По умолчанию он работает на уровне хостов, но без понимания того, как он считает веса, получаешь неравномерную нагрузку.
• Настройка пулов - размер pg_num (placement groups) надо задавать сразу с головой: маленькое значение - плохой баланс, слишком большое - лишний оверхед на метаданные. Формула «100 * OSD / replica_count» даёт стартовую точку, но не истину в последней инстанции.
• RADOSGW потребовал отдельно поднять FastCGI и Apache, прописать keystone-интеграцию (без неё аутентификация сугубо собственная) и пережить пару часов отладки прав доступа в keyring-файлах.

На всё это ушло около двух недель не самого непрерывного времени.

Что получили. RBD-диски подключаются к KVM-виртуалкам через librbd, и с точки зрения гипервизора это обычный блочный девайс. Живая миграция VM между хостами стала тривиальной - диск уже не привязан к конкретному железу. Производительность последовательных операций нас устроила, с random-IO на HDD ожидаемо всё скромнее, но для файловых серверов клиентов этого достаточно.

RADOSGW заработал как S3-совместимая точка. Залили через него архивные бэкапы одного из клиентов - утилиты, заточенные под Amazon S3, подошли без переделки, только поменяли endpoint. На managed-сопровождение такой стек ложится интересно: мониторинг состояния кластера через ceph -s даёт чёткую картину здоровья, OSD выпадают и возвращаются без ручного вмешательства.

Главный вывод пилота. Ceph - не для тех, кто хочет «поставил и забыл» прямо сейчас. Порог входа высокий: документация есть, но она предполагает понимание того, как работает распределённый консенсус и почему три монитора лучше двух. Зато когда кластер встал и прогрелся, масштабирование выглядит убедительно: добавь сервер с дисками, перебалансировка пройдёт сама.

0.67 Dumpling, который вышел и заявлен как первый production-ready релиз, мы планируем поставить вместо текущего 0.61 - посмотрим, насколько стабильнее стал RADOSGW и починили ли проблему с rbd map на ядрах старше 3.8.