Есть технологии, о которых говорят: «Поставили и забыли». С Ceph тоже так можно — но это скорее исключение, чем правило. Обычно всё иначе: его тюнят, чинят, переосмысливают архитектуру кластеров. ​​И дело не в том, что Ceph какой-то особенно капризный. Просто система редко остаётся в том же состоянии, в котором её запустили: она расширяется, сжимается, мигрирует, обрастает новыми нагрузками и новыми требованиями. Иногда кажется, что индустрия давно должна была устать и перейти на что-нибудь новое, более простое и красивое.

Но когда компании требуется серьёзное хранилище, в обсуждении снова появляется Ceph.

Почему? Неужели рынок просто привык страдать?

Ответ менее драматичный. Ceph неудобно списывать со счетов, потому что за 20 лет он накопил ровно то, что особенно дорого в инфраструктуре: сценарии использования, опыт эксплуатации, людей, которые знают его поведение, и доверие к данным, которые уже страшно отдавать экспериментам.

Я Анна Короткова, Product Owner команды Deckhouse Storage. В этой статье я попытаюсь разобраться, почему мы до сих пор не разводимся с Ceph (в том числе в нашей Kubernetes-платформе), даже когда очень хочется, и что с этим делать тем, кто строит инфраструктуру сегодня.

Ceph давно перестал быть просто технологией

Первую публикацию об архитектуре Ceph представили в 2006 году. Изначально проект решал амбициозную задачу: построить распределённую систему хранения, которая масштабируется на обычном железе, сама раскладывает данные, восстанавливается после отказов и обходится без центрального сервера на каждом обращении.

За следующие годы вокруг этой идеи выросла целая storage-платформа:

  • объектный слой RADOS;

  • блочное хранение через RBD;

  • файловый доступ через CephFS;

  • S3-совместимый объектный интерфейс через RGW;

  • политики размещения данных через CRUSH;

  • репликация, erasure coding, снимки, mirroring, multisite-сценарии и множество эксплуатационных инструментов.

Но когда инженеры сегодня говорят: «Нам нужен Ceph», они чаще всего имеют в виду не конкретный демон или протокол. Они просят знакомую модель: программно-определяемое распределённое хранилище, где уже есть ответ почти на любую хотелку — блоки, файлы, объекты, рост объёмов, отказ железа, резервная площадка, геораспределённые кластеры между дата-центрами по всей стране, интеграция с облаком или Kubernetes. Для больших компаний с распределённой инфраструктурой это отдельное преимущество: Ceph умеет работать на расстояниях, где другие решения начинают буксовать.

Новые решения могут быть значительно проще в отдельном сценарии. Но сравнивать их с Ceph по одной функции нечестно. Он давно продаёт не функцию, а широту применимости: накопленные за 20 лет ответы на самые разные задачи.

Open Source здесь не справка о лицензии, а часть доверия 

Живучесть Ceph — это не только про функции. Это ещё и про модель развития. Ceph остаётся Open Source и активно растёт: технически проект ведут разработчики из сообщества, а Ceph Foundation под Linux Foundation координирует участников, чтобы всё это не превратилось в закрытую технологию одного вендора. Это значит, что технология не заперта внутри чьей-то продуктовой стратегии. Код, история решений, обсуждения, фиксы и накопленная практика — всё это доступно рынку. В проект годами вкладывались крупные компании, разработчики и инженеры, для которых Ceph решал реальные задачи.

Ещё один плюс такой модели — проект живёт длинными циклами и предсказуемо взрослеет. Стабильные релизы у Ceph выходят примерно раз в год, и это не просто «новая версия ради новой версии». От релиза к релизу обычно растут производительность, устойчивость и зрелость day-2-эксплуатации в ответ на потребности рынка: от классического распределённого storage до S3-совместимых сценариев, мультипротокольного доступа и геораспределённых конфигураций. Для рынка это важный сигнал: технология не застряла в статусе «легендарного старого storage», а продолжает улучшаться. При этом Ceph не требует экзотического железа — он исторически силён тем, что умеет работать на самом разном стандартном оборудовании, если его характеристики честно соотнесены с задачей.

Важны и громкие имена. Ceph давно вышел за пределы лабораторных и энтузиастских инсталляций. Его используют в больших и требовательных средах вроде CERN, а в коммерции — DigitalOcean, OVHcloud, China Mobile. Со стороны разработки в проект вкладывались и вкладываются Red Hat / IBM, Canonical, Intel, SUSE — для всех них Ceph был не побочным экспериментом, а частью реальной storage-стратегии.

Вот поэтому вокруг Ceph и существует слой доверия. Если решение критично для инфраструктуры, важно понимать: оно развивается публично, имеет широкую экспертизу за пределами одного поставщика и не исчезнет вместе со сменой приоритетов отдельной компании.

У зрелости есть приятная сторона: почти на каждую хотелку уже кто-то наступал

Ceph развивался не в вакууме. Год за годом в нём появлялись ответы на реальные запросы: блочный диск для виртуалки, файловая система, объектный доступ, экономия ёмкости через erasure coding, репликация между площадками, интеграции с Kubernetes.

Причём это касается не только типов доступа, но и самой модели хранения. В Ceph можно выбирать между классической репликацией и разными схемами erasure coding, а в реальных кластерах — сочетать их: одни пулы под простую и предсказуемую модель с репликами, другие — под экономное хранение больших объёмов. Это не одна фиксированная схема, а возможность собирать storage-профиль под разные классы нагрузок на одной технологической базе.

Отсюда и накопленная экспертиза рынка. Когда команда говорит: «У нас Ceph», это может означать очень разные вещи: кому-то нужен надёжный блоковый слой под виртуалки, кому-то — файловый доступ, кому-то — зеркалирование между площадками, кому-то — петабайтный кластер, а кому-то, наоборот, — небольшой гиперконвергентный контур на тройке узлов. 

На практике это выглядит так (из моего опыта): у телекомов — три узла Ceph под кластеры разработки, у исследовательских институтов — десятки узлов (обычно кратные трём), у хостеров — отдельный кластер под архивы и бэкапы, а небольшие хостеры часто начинают с гиперконвергентной архитектуры, потому что держать отдельный Ceph-кластер дорого, пока не заработаешь.

Где-то Ceph — один большой storage-контур, а где-то в одной инфраструктуре живут сразу несколько разных кластеров под разные профили нагрузок.

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

Важно, что Ceph не остался «хранилищем для виртуалок» или OpenStack-ландшафтов. Когда в индустрии начали массово переходить на Kubernetes и stateful-нагрузки в контейнерах, Ceph получил штатный путь и туда: через ceph-csi Kubernetes динамически выдаёт приложениям тома на базе RBD, а для файловых сценариев используется CephFS поверх той же общей storage-основы. То есть смена формы запуска приложения — с виртуалки на под — не заставила компании выбрасывать уже освоенную storage-технологию.

Это тоже одна из причин долгой жизни Ceph: он успевал адаптироваться к новым инфраструктурным слоям. Сначала стал фундаментом для облачной виртуализации, потом — для контейнерных платформ, где постоянные данные нужны базам, очередям, registry, аналитике и другим stateful-сервисам.

Не всё из этого одинаково легко развернуть. Не всё одинаково хорошо сочетается в одном кластере. Иногда богатство возможностей превращается в разнообразие способов ошибиться.

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

У нового решения могут быть более лаконичная архитектура и более ясный путь для одного workload. Но ему ещё нужно доказать, что оно выдержит не только демонстрационный стенд и аккуратный пилот, а несколько лет эксплуатации, смену оборудования, рост данных и внезапное появление требований, которых не было на старте.

Бывает ли Ceph лаконичным?

Ceph может быть лаконичным — если использовать его под один простой сценарий. Например, только блочное хранение для виртуалок или только файловый доступ. В таких случаях кластер собирается компактно и работает предсказуемо. Но это скорее исключение.

На практике от Ceph обычно хотят всего сразу: блоки, файлы, объекты, зеркалирование между площадками. И тогда он становится громоздким — слишком широк охват задач и слишком много движущихся частей.

Но внутри него есть решения, которые архитектурно действительно красивы. Самый очевидный пример — CRUSH. Вместо того чтобы хранить центральную таблицу с адресом каждого объекта, Ceph вычисляет размещение данных по карте кластера и правилам распределения. Клиенты и демоны сами понимают, куда идти за данными, без центрального узкого места на каждый запрос. За этой идеей стоят и масштабирование, и управляемое размещение реплик по доменам отказа: дискам, хостам, стойкам, площадкам.

То есть Ceph может быть тяжёлым в эксплуатации, но это не значит, что внутри него нет сильных инженерных решений. Скорее наоборот: именно хорошая базовая архитектура позволила нарастить вокруг неё столько возможностей. Цена этого роста — сложность всей системы целиком.

Главная причина вернуться к Ceph: людям уже доверяют его проблемы

В выборе хранилища есть странный парадокс. Инженеры могут прекрасно знать, что Ceph сложный. Могут знать, что для крупного кластера нужны компетенции, дисциплина эксплуатации, мониторинг, нормальная сеть и команда, которой хватит не только на установку, но и на годы сопровождения.

И всё равно выбрать Ceph.

Потому что известная сложность иногда безопаснее неизвестной простоты.

Если у компании уже были Ceph-кластеры, у неё, скорее всего, накоплены:

  • архитектурные шаблоны и требования к железу;

  • правила мониторинга и реагирования;

  • процедуры расширения, обновления и восстановления;

  • опыт инцидентов;

  • сотрудники или подрядчики, которые умеют с этим работать;

  • понимание, в каких сценариях Ceph подходит, а где от него лучше отказаться.

На практике это выглядит так: опытные команды знают, что при замене OSD в большом кластере CRUSH может перегнать петабайты данных, и у них есть playbook, как это делать ночью с пониженным recovery priority. Они умеют мигрировать данные с одного Ceph на другой (например, с ванильного Ceph на Ceph от вендора или наоборот) — встроенный механизм репликации сильно упрощает эту задачу. У них есть сценарии обновления до новых релизов без простоя, и они умеют развёртывать кластер не только на трёх репликах, но и на erasure coding — это чуть сложнее, зато экономнее по ёмкости.

Для нового решения всё это придётся строить заново. Провести тесты. Подтвердить поведение на нужном оборудовании. Проверить сценарии отказов. Разобраться с обновлениями и поддержкой. Убедить службу безопасности, архитекторов и владельцев критичных систем, что важные данные можно перенести в новый контур.

Для тестовых данных это один разговор. Для данных рабочей системы, персональных данных, финансовых операций или коммерчески чувствительной информации — совершенно другой.

Но цена этих отношений со временем растёт

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

Здесь важно не впасть в две крайности.

Первая: «Ceph старый и сложный — значит, его надо заменить везде». Так мы забываем, сколько уже вложено в знания, зрелость процессов и закрытые сценарии.

Вторая: «Ceph уже есть, все умеют работать с ним — значит, новое хранилище бессмысленно». Так мы забываем, что сложность стоит денег, и многим нагрузкам вообще не нужна универсальная распределённая storage-платформа.

Не каждому приложению нужен Ceph. Для конкретной базы, локальной репликации, встроенного хранилища платформы, простого backup-контура или отдельного S3-сценария более узкое решение часто оказывается проще, дешевле в сопровождении и предсказуемее.

Вопрос не в том, побьёт ли новое решение Ceph «вообще». Вопрос в том, в каких сценариях больше не нужно платить за всю широту Ceph, когда нужна только конкретная его часть.

Мы продолжаем развивать Ceph: теперь как встроенное решение платформы

Для команды Deckhouse это не абстрактное наблюдение за рынком. Подключение внешнего Ceph-кластера через CSI стало одной из первых storage-интеграций Deckhouse Kubernetes Platform (DKP, единая платформа для контейнеризации и виртуализации). Решение было практичным: у многих уже есть Ceph, данные и компетенции. Задача платформы в таком случае — не заставить отказаться от работающего контура, а дать использовать его для нагрузок в понятной операционной модели.

Сейчас мы делаем следующий шаг: встроенный Ceph, который развёртывается силами самой платформы. Если раньше мы подключали к DKP внешний Ceph-кластер через CSI (и этот внешний Ceph развёртывала и обслуживала отдельная команда storage), то теперь платформа поднимает Ceph самостоятельно — как часть своей инфраструктуры (при этом механика взаимодействия не меняется: мы по-прежнему используем стандартный ceph-csi, просто теперь он работает с кластером, который платформа развернула сама). Причина простая: Ceph — одно из лучших и самых известных решений на рынке, и мы хотим дать его клиентам «из коробки». Вместо того чтобы каждый раз подключать внешний кластер, развёрнутый кем-то другим, платформа теперь сама поднимает знакомый storage-контур, в котором можно реализовывать блочные, файловые, а в перспективе и объектные сценарии.

Типичные сценарии, где это имеет смысл:

  • Хранилище для виртуальных машин под управлением Deckhouse, там где не планируется использовать внешнюю СХД.

  • Сценарий с неоднородным железом, когда в инфраструктуре есть разные серверы и диски, но нужно собрать из них единый управляемый storage-контур без ручного сопровождения.

  • Площадки, где важны отказоустойчивость и рост по мере добавления дисков/узлов, с эксплуатацией через единый platform path Deckhouse, а не через отдельный storage-кластер.

  • Новый storage-контур рядом с существующей СХД, когда основное хранилище менять рано, но для новых workloads нужна отдельная распределённая система.

Здесь важно не подменять понятия. «Встроенный Ceph» в Deckhouse — это продуктовый контур использования Ceph внутри платформы. То есть мы отвечаем за то, чтобы Ceph корректно работал как часть Deckhouse: развёртывался, обновлялся, интегрировался с CSI и жил в общей операционной модели.

Это также не обещание полностью управляемого сервиса, в котором всю ежедневную эксплуатацию хранилища передают нам. Полное сопровождение — это отдельный сервисный вопрос, и его условия обсуждаются индивидуально.

Это не значит, что Ceph нужен всем и для любой нагрузки. Напротив, выбор должен оставаться сценарным: где-то правильнее использовать более компактное встроенное реплицируемое хранилище, где-то — существующую внешнюю СХД, а где-то масштаб и набор требований действительно возвращают нас к Ceph.

В этом смысле встроенный Ceph для платформы — не признание, что новых решений не существует. Это признание того, что зрелая платформа должна уметь работать и с простыми сценариями, и с задачами, где важна уже доказанная функциональная широта Ceph.

Почему мы не разводимся с Ceph

Мы не разводимся с Ceph не потому, что он идеален.

Мы не разводимся с ним потому, что он стал частью инфраструктурного опыта рынка. Он накопил функции, интеграции, людей и доверие. Его проблемы известны, а известные проблемы можно заранее заложить в проект, бюджет и модель эксплуатации.

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

Ceph остаётся с нами не как последняя истина в хранении. Он остаётся как взрослый, сложный и очень хорошо известный соперник — тот, на фоне которого рынок будет оценивать все новые storage-решения.

И, пожалуй, это самый полезный способ на него смотреть: не как на технологию, от которой всем давно пора избавиться, а как на мерку зрелости, доверия и стоимости эксплуатации.

Мы расширяем storage-команду Deckhouse. Если вам интересно не просто «поддерживать» хранилища, а строить платформенные решения для Kubernetes и виртуализации, разбираться не только с Ceph, но и с разными сценариями блочного, файлового и объектного хранилищ — нам по пути.

Посмотрите вакансию Senior Go Developer for the Storage Team. Будем рады обсудить задачи! 

P. S.

Читайте также в нашем блоге: