Зачем сравнивать Ceph, ZFS replication и DRBD именно для VDS
Для платформы VDS обычно важны три вещи: предсказуемые задержки и IOPS, понятное поведение при отказах (узел, диск, сеть, «половина кластера») и эксплуатация без сюрпризов (обновления, мониторинг, восстановление, рост). Ceph, ZFS replication и DRBD решают похожую задачу — защитить данные и обеспечить доступность — но делают это разными методами, поэтому и «цена» (сеть, CPU, процессы, риски) различается.
Ниже — не маркетинговое «что лучше», а разбор того, как технологии ведут себя в проде: где появляются хвосты latency, что будет при деградации, как быстро реально восстановиться и какие сценарии поломок чаще всего делают больно.
Модели данных: что реплицируется и где принимается решение о записи
Ceph RBD
Ceph RBD — распределённое блочное хранилище: данные дробятся на объекты и раскладываются по OSD согласно карте размещения. Клиент пишет в RBD-образ, а Ceph решает, на какие OSD положить реплики. «Кто с кем согласован» контролируется мониторами (MON) и состоянием кластера.
Практический вывод: Ceph рассчитан на горизонтальный рост и переживание отказов без ручных «перекидываний томов», но требует нормальной сети, запаса по ресурсам и дисциплины эксплуатации.
ZFS replication (send/receive)
ZFS replication — это репликация снапшотов через zfs send/zfs receive. Это не «кластерный блок-девайс», а доставка состояния датасета/тома на другой хост. Чаще всего репликация асинхронная: RPO почти всегда больше нуля и определяется частотой снапшотов и скоростью доставки инкрементов.
Сильная сторона: DR, резервная площадка, миграции, быстрые откаты по снапшотам. Слабая: типовая схема не даёт прозрачной синхронной записи одного и того же тома одновременно на двух узлах.
DRBD
DRBD реплицирует блочное устройство между узлами (обычно Primary/Secondary). В синхронном режиме запись подтверждается только после записи локально и на реплике. Отсюда понятная HA-модель «как локальный диск, но с зеркалом» и предсказуемое влияние задержки сети.
Ключевой риск: split brain при проблемах связи/кластер-менеджмента. Поэтому DRBD почти всегда должен идти вместе с fencing/STONITH и отработанными сценариями переключения.
Производительность: latency, IOPS и где появляется write amplification
Единой «таблички цифр» не будет: всё зависит от сети (10/25/100G), носителей (SSD/NVMe/HDD), профиля I/O (4K random write, 70/30 mixed, sequential), настроек кешей и того, что именно вы считаете «производительностью» (среднее vs p95/p99). Но архитектурные закономерности у всех трёх подходов довольно устойчивые.
Ceph: длинный путь записи и хвосты при деградации
У Ceph путь записи обычно длиннее: клиент → сеть → несколько OSD → подтверждение реплик → журналирование/бэкенд. При размере репликации 3 вы получаете несколько операций на каждый логический блок, плюс сетевой трафик. Это и воспринимается как практический write amplification (вместе с накладными расходами на протокол и метаданные).
- Средняя latency обычно выше, чем у локального диска, и часто выше, чем у DRBD в пределах одного ЦОД, особенно на sync-write.
- Хвосты p95/p99 могут заметно вырастать во время recovery/backfill/rebalance (и это важно именно для VDS, где «прыжки» задержек быстро видны гостям).
- Ceph очень чувствителен к CPU и сети на OSD-узлах: «экономия» на процессорах/сетевых картах почти всегда превращается в нестабильные задержки.
При этом правильно спроектированный Ceph умеет масштабировать суммарные IOPS и пропускную способность с ростом кластера — если нет узких мест и выдержаны домены отказа.
DRBD: синхронная репликация и цена RTT
В синхронном DRBD главным ограничителем становится RTT между узлами: подтверждение записи включает доставку данных на вторую сторону. В одной стойке или в одном ЦОД это часто даёт очень хорошие и предсказуемые задержки; между площадками — задержка растёт линейно с RTT, и это быстро становится заметно на мелких sync-write.
Write amplification проще: минимум 2 копии данных (локально и на реплике), без «распределённого планировщика размещения» как у Ceph. Именно поэтому DRBD часто ощущается «ближе к локальному диску», если сеть короткая и стабильная.
ZFS replication: прод — локальный, репликация — фоновая
Если ВМ живут на локальном ZFS (например, zvol), то продовая производительность определяется локальным стеком: ARC, запись в transaction groups, COW-эффекты, настройка recordsize/volblocksize, SLOG при sync-выгрузке и т.д. Репликация снапшотов обычно идёт отдельным потоком и её можно ограничить, чтобы не портить latency на проде.
Главное честно зафиксировать: ZFS replication — это не online HA-репликация записи «прямо сейчас» (в типовой схеме), а механизм доставки состояния с некоторым RPO.
Quorum, сеть и вопрос «кто прав» при проблемах связи
Ceph: quorum как предохранитель от неконсистентной записи
В Ceph quorum у MON — фундамент. Мониторы должны иметь кворум, чтобы кластер принимал согласованные решения. Это резко снижает вероятность сценария «две стороны считают себя главными», но вводит другой эффект: при сетевой нестабильности часть операций может быть остановлена до восстановления связности/кворума.
Для VDS это означает практический приоритет: дизайн сети и размещение MON критичны. «Маленький Ceph без запаса» + нестабильная сеть часто выглядит для клиента как «то работает, то нет», хотя с точки зрения целостности Ceph делает правильную вещь — не даёт писать в потенциально неконсистентное состояние.
DRBD: split brain и почему без fencing это лотерея
Опасный сценарий DRBD — разделение сети, при котором обе стороны начинают вести себя как Primary (или кластер-менеджер ошибочно допускает двойной Primary). Это и есть split brain: две независимые версии одного тома. Дальше вы выбираете «какая сторона правильная», и это может означать длительный простой и ручные действия.
DRBD в HA работает предсказуемо только при заранее продуманном fencing/STONITH и регулярно отработанных сценариях потери связи. Без этого вы меняете риск «упал сервер» на риск «разъехались данные».
Если у вас уже есть кластер-менеджмент, полезно держать под рукой практические сценарии переключения и разборов инцидентов. Как подход к «правильной репликации и фейловеру» хорошо ложатся материалы про GTID и семисинхронную репликацию в MySQL: фейловер MySQL с GTID и semisync.
ZFS replication: split brain нет, но есть RPO и дисциплина переключения
Классического split brain как у DRBD здесь нет: вы не пишете одновременно в один том с двух сторон. Но появляется ось риска RPO: если снапшоты отправляются раз в 5 минут, то в худшем случае вы потеряете до 5 минут изменений (плюс то, что не успело доехать из-за окна репликации).
Тут особенно важно не путать «репликация настроена» и «аварийное переключение отработано»: что будет с IP, маршрутами, DNS, доступами, и как быстро вы реально поднимете гипервизор/экспорт на второй стороне.
Recovery time: как быстро вы реально подниметесь после аварии
Ceph
В Ceph есть два разных «восстановления»: (1) продолжение работы ВМ при отказе диска/OSD/узла и (2) возврат к здоровому состоянию (rebalance/backfill). Для пользователя критично первое, но для админа второе не менее важно: пока идёт восстановление, p95/p99 latency может быть хуже нормы.
Если кластер спроектирован с запасом (CPU, сеть, домены отказа) — отказ одного узла часто малозаметен. Если запаса нет — «восстановление» превращается в долгую деградацию с жалобами на «всё тормозит».
DRBD
В идеальном HA-сценарии recovery time — это время, за которое кластер-менеджер распознаёт отказ, выполняет fencing и поднимает сервисы на втором узле. На практике время определяется таймаутами, состоянием файловой системы после падения и качеством тестов. Если произошёл split brain, recovery time становится непредсказуемым — это уже не фейловер, а разбор и выбор «истины».
ZFS replication
Recovery time обычно складывается из действий «промоутнуть» реплику (выбрать нужный снапшот/датасет), поднять экспорт/виртуализацию и вернуть связность для клиентов. Самые частые задержки — организационные: маршрутизация, IP, зависимости сервисов, доступы. С точки зрения данных всё проще: есть снапшоты, их и поднимаете.
Масштабирование и эксплуатация: где вы платите сложностью
Ceph: мощно, но требовательно к операционке
Ceph хорош, когда нужно масштабирование и отказоустойчивость пула: добавляете узлы — растёт ёмкость и потенциальная производительность. Но Ceph требует зрелой эксплуатации: мониторинг, плановые обновления, понимание деградаций, контроль заполнения и балансировки.
- Recovery/backfill может неожиданно «съесть» latency и IOPS.
- Перекосы между OSD и ошибки проектирования доменов отказа приводят к нестабильности.
- Производительность трудно прогнозировать без нагрузочного теста под ваш профиль.
DRBD: проще архитектурно, строже по процессам
DRBD проще внедрять в небольшой платформе: пары узлов, зеркалирование блоков, понятный фейловер. Но «простота» провоцирует экономить на fencing и тестировании. Если fencing нельзя обеспечить (политически/технически), DRBD становится заметно рискованнее, чем кажется на схеме.
Как единое масштабируемое хранилище «на десятки узлов» DRBD не является сильной стороной. Зато для ограниченного числа критичных пулов/томов он часто даёт лучший баланс предсказуемости и трудозатрат.
ZFS replication: отличный DR-инструмент и хороший второй контур
ZFS replication обычно приятна в эксплуатации: снапшоты, инкременты, простая диагностика. Масштабирование — это масштабирование отдельных хостов и потоков репликации, а не построение единого storage-кластера.
Частая продакшн-практика — использовать ZFS replication как второй контур даже при другом «основном» сторидже: для DR-площадки, миграций и быстрых откатов.
Мини-плейбук: что замерять и что проверять до выбора
1) Снимите профиль нагрузки и тестируйте хвосты
В VDS-среде «среднее значение» часто бесполезно. Замеряйте p95/p99 latency, отдельно для read/write и отдельно для sync-операций. Нагрузочный тест проводите максимально близко к реальности (размер блоков, количество потоков, очередь, доля записи).
2) Проговорите RPO/RTO и домены отказа
Если RPO должен быть нулевым, асинхронная репликация снапшотов вам не подходит как единственный механизм. Если у вас две площадки с ощутимым RTT — синхронная запись (DRBD или «строгий» Ceph-дизайн) может резко увеличить задержки. Домены отказа (стойка/ЦОД/площадка) определяют не только схему, но и требования к сети и процессам.
3) Отрепетируйте аварии как процедуру
Самая практичная проверка — регулярные учения: выключили узел, отключили линк, имитировали деградацию диска, замерили время, задокументировали. Если вы применяете репликации для БД, полезно также держать понятный план восстановления на уровне данных: например, для PostgreSQL хорошо помогает дисциплина PITR и работа с WAL — см. резервное копирование и восстановление PostgreSQL через PITR/WAL.
Итог: что выбрать для хранилища VDS
Ceph RBD — выбор для распределённого кластерного хранилища, когда нужен горизонтальный рост и переживание отказов на уровне пула. Вы получаете самовосстановление и работу через quorum, но платите сложностью, требованиями к сети/CPU и возможными хвостами latency во время восстановлений.
DRBD — сильное решение для HA-пар с синхронной репликацией и моделью «как локальный диск». Часто даёт отличную предсказуемость в одном ЦОД, но требует fencing/STONITH и дисциплины, иначе риск split brain перекрывает выгоды.
ZFS replication — практичный и удобный механизм DR/миграций/откатов: локальная производительность на проде, понятные снапшоты, простая диагностика. Но в типовой схеме это почти всегда история про RPO (пусть и небольшой), а не про мгновенную синхронную доступность одного тома.
Команды для базовой настройки ZFS replication (пример)
Ниже — минимальный шаблон, чтобы было от чего оттолкнуться в тестовой среде. Команды — примерные; имена пулов/датасетов подставьте свои.
zfs snapshot -r tank/vmdata@replica-2026-02-10-1200
zfs send -R tank/vmdata@replica-2026-02-10-1200 | zfs receive -F backup/vmdata
zfs snapshot -r tank/vmdata@replica-2026-02-10-1205
zfs send -R -i tank/vmdata@replica-2026-02-10-1200 tank/vmdata@replica-2026-02-10-1205 | zfs receive -F backup/vmdataПри выборе решения для платформы VDS самый надёжный путь — зафиксировать SLO по latency, допустимый RPO/RTO, протестировать под своим профилем нагрузки и отдельно прогнать учения по отказам. Именно там различия между Ceph, DRBD и ZFS replication проявляются сильнее всего.
