Привет, Хабр! Меня зовут Евгений Мартынов, я директор по информационным технологиям в Рег.ру. В декабре 2024 года мы запустили сервис объектного хранилища S3, построенный на Ceph. Тогда это был MVP с минимально необходимым функционалом — сейчас мы вышли из беты, добавили ключевые возможности, расширили хранилище и накопили первые 130+ ТБ пользовательских данных.
В этой статье я решил поделиться опытом облачной команды Рег.ру: почему выбрали Ceph, как проектировали квоты, масштабировали инсталляцию без остановки сервиса, какие вызовы нас ждали на проде и как мы их решили.
Навигация по тексту:
Почему Ceph, и как мы его приручили
Ceph — мощная, но не самая простая в эксплуатации система хранения. У нее долгая история, в которой хватает как успехов, так и рисков. Мы внимательно изучили чужой опыт: деградации производительности, падения кластеров, потерю данных. Вывод оказался ожидаемым: большинство проблем возникали не из-за архитектурных ограничений Ceph, а из-за ошибок в эксплуатации — недонастроенного мониторинга, экономии на железе, неправильного проектирования.
Чтобы избежать подобных ошибок, мы:
Использовали производительное и надежное оборудование с резервированием.
Настроили детализированный мониторинг (Zabbix, VictoriaMetrics, Grafana) для отслеживания метрик (IOPS, latency, состояние OSD, общее состояние кластеров).
Тщательно рассчитали параметры: архитектуру избыточного хранения/резервирования, размеры кэшей, параметры CRUSH-карты и др.
Накопили экспертизу, добавив к смелости опыт и внимание к деталям.
Запустили процесс долговременной аналитики работы оборудования и самого Ceph для выработки проактивных мер защиты данных.
Итог: Ceph оказался устойчивым и гибким решением. Да, он не самый быстрый (например, по сравнению с некоторыми аппаратными СХД enterprise-класса и даже программными решениями S3), и порог входа высок. Но при правильной настройке он показывает высокую надежность, а данные остаются в безопасности даже при серьезных внешних воздействиях.
Ранее мы уже рассказывали, как подходим к R&D с Ceph.
Наша типовая инсталляция Ceph
Основу хранилища составляют серверы с 12 отсеками под 3.5" накопители. На них запускаются OSD-демоны Ceph. Каждый сервер подключен к сети с двумя 40 Gbit-интерфейсами, объединенными в LCAP и разведенными по разным коммутаторам доступа. В качестве носителей используем SATA SSD объемом 8 ТБ — это базовый класс хранения, который обеспечивает баланс между скоростью и емкостью.
Для RGW/MON используются выделенные серверы, также подключаемые в общую сеть хранилища на скорости 2x40Gbit (LACP).
Хранение организовано на базе Erasure Coding — кодирования с исправлением ошибок или избыточного кодирования на различных узлах кластера. Это позволяет восстановить информацию даже при выходе из строя части дисков или узлов.
Инсталляция спроектирована так, что мы можем пережить отказ любого из компонентов, будь то диск, патч-корд, свитч, сервер RGW/MON или даже стойка, без простоя и потери данных.
Как внедряли квоты и почему отказались от оверселлинга
Один из первых архитектурных вызовов, с которым мы столкнулись, — проектирование квот. Объектное хранилище всегда работает на грани баланса между доступным объемом, скоростью масштабирования и поведением клиентов.
Мы пошли по пути без оверселлинга. Это значит, что если клиент устанавливает квоту в 10 ТБ, то в инфраструктуре под него физически резервируется место. Квоты для нас — это не только ограничение, но и инструмент планирования. Представьте: 1000 клиентов одновременно загружают терабайты данных. Без квот хранилище может исчерпать место быстрее, чем мы успеем его масштабировать.
Мы применяем несколько подходов:
Автоматическое квотирование: если клиент достигает 80% от текущей квоты, система автоматически увеличивает ее. В ближайшем будущем будет доставлена фича и в личном кабинете публичного Облака Рег.ру.
Резерв пространства: всегда держим не менее 30% свободного места на каждом пуле для экстренных случаев и снижения сложностей при миграции данных между OSD.
Гибкость: для крупных клиентов мы обсуждаем индивидуальные лимиты, чтобы поддерживать их сценарии использования.
Даже при наличии мониторинга с алертами на 75% и 85% заполнения пулов, а также горячего резерва для масштабирования, расширение инфраструктуры требует времени. Мы учитываем возможные сбои: всегда держим дополнительный домен отказа и закладываем его в пороги срабатывания и планирования, чтобы не зависеть от сроков замены оборудования в случае неполадок.
Масштабирование в режиме онлайн
Рост объема — ожидаемый процесс, и важно было убедиться, что расширение возможно без остановки сервиса.
Мы проверили два сценария масштабирования:
Добавление новых серверов: подключили новые ноды без даунтайма, клиенты даже не заметили, что Ceph копировал данные.
Увеличение числа дисков: добавляли диски кратно, чтобы сохранить баланс распределения данных по серверам и стойкам.
Обе операции прошли успешно в режиме онлайн, без остановки или деградации сервиса. На текущий момент у нас есть запас для трехкратного расширения без необходимости закупки нового оборудования.
Из интересных кейсов — проводили миграции между различными типами носителей. В одном из проектов заказчик изначально выбрал SSD для «горячего» хранения, но затем перешел на гибридные OSD — SSD для WAL и DB и HDD под данные — для «холодного» хранилища. В другом случае столкнулись с неожиданной деталью: JBOD на RAID-контроллерах оказался заметно медленнее, чем «честный» JBOD на HBA. Пришлось переезжать. Самый продолжительный переход занял чуть больше месяца, но мы сознательно не торопились, чтобы избежать деградации сервиса.
Первый инцидент: клиентская нагрузка и пределы безлимитности
Несмотря на стабильную работу кластера, инциденты случаются. Один из первых стал для нас важным ориентиром. Клиент развернул многопользовательскую онлайн-игру с интенсивной работой с хранилищем: высокая частота операций и одновременно большое количество активных игроков. Мы не ограничиваем трафик и число API-запросов — и в этом случае столкнулись с аномально высокой нагрузкой на S3-интерфейс.
Технически инфраструктура выдержала, но инцидент заставил задуматься о лимитах. Что мы сделали:
Ввели преднастроенные лимиты на I/O и количество API-запросов.
Начали сбор статистики для будущего расчета разумной тарификации: чтобы не ограничивать честных пользователей, но при этом контролировать потребление ресурсов.
Другие инциденты были связаны с особенностями поведения Ceph. Например, при создании бакетов выполняется распределенный коммит: метаданные хранятся в нескольких пулах, а RGW технически не может гарантировать транзакционность такой записи, будь то создание бакета или его удаления. В одном из случаев мы обнаружили клиента, у которого был формально удален пул: объекты отсутствовали, пул очищен, но сам бакет продолжал отображаться в листинге. Автоматических инструментов для исправления такой неконсистентности на тот момент не было — мы разбирались вручную и заодно выработали подход к мониторингу подобных кейсов.
Интеграции: S3 в экосистеме
Наше хранилище S3 легко интегрируется с другими сервисами и инструментами, что делает его универсальным решением для разных сценариев:
Kubernetes: S3 можно использовать в качестве бэкенда для хранения данных в кластерах Kubernetes. Например, для работы с Persistent Volumes можно настроить S3 через csi-s3 драйвер. Вот пример конфигурации:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: s3-storage
provisioner: s3.csi
parameters:
bucket: my-bucket
endpoint: https://s3.example.comНо мы не рекомендуем использовать S3 в режиме эмуляции файловой системы — fuse ;)
ISPManager: наш партнерский продукт для управления облачными серверами нативно поддерживает протокол S3 для создания резервных копий. Настройка занимает буквально пару минут через веб-интерфейс.
Nextcloud: S3 интегрируется как внешний диск для Nextcloud. Это позволяет использовать хранилище через веб-интерфейс или клиенты Nextcloud на любой ОС. Подключение — по инструкции.
Сторонние утилиты: такие инструменты, как CloudMounter или ExpanDrive, превращают S3 в сетевой диск, упрощая работу с файлами. Это особенно удобно для пользователей, не знакомых с S3 API.
Обновления и достижения
В итоге вот что мы сделали за полгода:
Открыли широкий функционал S3 в его API (есть и серверное шифрование данных SSE-C и публичные ссылки на объекты).
Реализовали управление ключами и правами доступа через личный кабинет.
Обновили Ceph до версии 19.2.2 (Squid), что улучшило производительность и стабильность. Changelog.
Добавили возможность работы с объектами (загрузка, удаление, просмотр) через веб-интерфейс.
Вышли из бета-версии, обеспечив SLA 99.95% для всех клиентов.
На июль 2025 года сервисом пользуются более 1100 клиентов, а объем хранимых данных превысил 130 ТБ. Среди популярных сценариев: бэкапы, хранение логов, медиафайлы и данные для ML-моделей.
Что дальше: наши приоритеты
Мы не останавливаемся на достигнутом и в будущем планируем:
наращивать функциональность управления хранилищем через личный кабинет;
доставить метрики, визуализирующие использование хранилища;
добавлять всевозможные интеграции и комплементарные продукты;
внедрять механизмы авто квотирования;
расширить географию, добавив новые регионы и мультизонные инсталляции;
расширить количество доступных классов хранения.
Полгода непрерывной работы объектного хранилища S3 на базе Ceph в продакшене показали, что с правильным подходом open-source решение может быть надежным и масштабируемым. Но по-настоящему зрелая архитектура растет из обратной связи. Если у вас был похожий опыт — расскажите, какие задачи и компромиссы стояли перед вами. Если вы уже используете наше хранилище — делитесь впечатлениями в комментариях. А если только планируете — пишите, поможем настроить под ваши задачи.