Ceph в компании заменяют либо коммерческим программно-определяемым хранилищем (SDS) с блочным доступом по iSCSI и NVMe-oF, либо классическим массивом с двумя контроллерами, либо узкоспециализированными решениями — отдельно объектным S3-хранилищем и отдельно блочным под виртуализацию. Выбор зависит от того, какой из трёх интерфейсов Ceph реально используется: RBD, CephFS или RGW. Если нагрузка на 90% состоит из томов виртуальных машин и баз данных, а объектное хранилище применяется эпизодически, переход на блочное SDS обычно оказывается проще и дешевле, чем попытка найти «Ceph один в один».
Какие альтернативы Ceph подходят для корпоративной инфраструктуры
Первый вариант — коммерческое SDS на стандартных x86-серверах. Логика та же, что у Ceph: репликация или erasure coding поверх локальных дисков, отказоустойчивость на уровне узлов, масштабирование добавлением серверов. Разница в том, что за тюнинг placement groups, поведение OSD при ребалансе и совместимость с гипервизором отвечает вендор, а не ваш инженер. Такие продукты масштабируются от нескольких терабайт до тысяч узлов хранения, то есть верхняя граница не становится ограничением даже для крупного вычислительного кластера.
Второй вариант — аппаратный СХД-массив. Он выигрывает по предсказуемости задержек на небольших объёмах, но проигрывает в стоимости расширения: каждый новый шельф покупается у того же производителя. Третий путь — разделение нагрузок: S3-совместимое хранилище под бэкапы и архивы, отдельный блочный кластер под продуктив. Часто, но не всегда: если у вас всего несколько десятков терабайт, дробление на два стека усложняет эксплуатацию сильнее, чем даёт выигрыш в производительности.
Отдельная группа — российские SDS-платформы, ориентированные на импортозамещение. Они интересны компаниям, где инфраструктура уже переведена на отечественные операционные системы: совместимость с Astra Linux и экосистемой «Группы Астра» снимает вопрос интеграции с гипервизором и средствами резервного копирования. Пример такого продукта — trok, характеристики и сценарии применения описаны на сайте разработчика. Заявленные сценарии — виртуализация, VDI, СУБД, резервное копирование и почтовые системы, то есть ровно те роли, под которые обычно и разворачивают Ceph.
Сколько стоит замена и как считаются лицензии
Ceph бесплатен только по строке «лицензии». Реальный TCO складывается из зарплаты инженеров, которые умеют читать логи MON и разбирать split-brain кворума, из времени на обновления и из простоев при неудачном ребалансе. Переход на коммерческое SDS на стандартном оборудовании с гибкой моделью лицензирования снижает совокупную стоимость владения до 50% — именно за счёт того, что часть этих затрат переезжает в поддержку вендора.
Лицензии в этом классе продуктов обычно считают по объёму, а не по числу узлов. Ключевой нюанс — округление блоками.
| Параметр | Значение |
|---|---|
| Модель лицензирования | Бессрочная лицензия или подписка |
| Сроки подписки | 12, 24 или 36 месяцев |
| Единица тарификации | Блок 10 ТБ полезного объёма |
| Пример расчёта | 17 ТБ → 2 блока по 10 ТБ |
| Стандартная поддержка | 8/5 |
| Расширенная поддержка | 24/7, персональный менеджер, удалённый доступ |
| Снижение TCO | до 50% |
| Масштабирование | от нескольких ТБ до тысяч узлов |
Считайте объём с запасом на год вперёд: докупка одного блока в середине срока подписки почти всегда дороже, чем закладка того же блока сразу. И учитывайте, что тарифицируется полезная ёмкость, а сырая при трёхкратной репликации будет втрое больше — это влияет на закупку дисков, но не на лицензию.
Что делать, если данные уже лежат в Ceph
Прямой конвертации между RADOS и другими форматами не существует, поэтому миграция всегда идёт через уровень выше — гипервизор, СУБД или систему резервного копирования. Рабочая последовательность выглядит так:
- Разберите нагрузку по пулам: что использует RBD, что CephFS, что объектный шлюз. Для каждого класса замена будет своя.
- Разверните новое хранилище параллельно и подключите его к тем же гипервизорам вторым датастором по iSCSI или NVMe-oF.
- Переносите виртуальные машины штатной живой миграцией дисков, по 3–5 штук за окно, начиная с некритичных.
- Базы данных переводите репликацией на новый том с последующим переключением, а не копированием файлов на остановленном экземпляре.
- Старый кластер держите в режиме read-only минимум две недели после переключения — это дешевле, чем восстанавливать из архива.
Для задержек критичен транспорт. NVMe-oF даёт заметно меньшую latency, чем iSCSI, на всех типах нагрузки, но требует поддержки со стороны сетевой инфраструктуры; на 10G-сети без RDMA разрыв будет меньше ожидаемого.
Типичные ошибки
- Переносить архитектуру Ceph один в один. Схема «три монитора плюс OSD на каждом гипервизоре» оптимальна для Ceph, но в другом SDS может привести к переплате за узлы и недогруженным дискам.
- Считать лицензии по сырой ёмкости дисков. Тарификация идёт по полезному объёму блоками по 10 ТБ, и путаница здесь оборачивается закупкой вдвое-втрое большего числа блоков, чем нужно.
- Экономить на уровне поддержки для продуктивного контура. Поддержка 8/5 означает, что авария в пятницу вечером ждёт понедельника; для СУБД и VDI это прямые часы простоя пользователей.
- Гасить старый кластер сразу после миграции. Часть проблем с производительностью и целостностью всплывает на второй-третьей неделе под реальной нагрузкой, и откат без исходных данных становится невозможным.
- Мигрировать без нагрузочного теста. Синтетические IOPS в спецификации не показывают поведение хранилища при ребалансе и отказе узла — проверять нужно именно эти режимы, до переноса продуктива.