Эксперты в подборе IT-оборудования
Ceph - это программное хранилище, которое объединяет диски нескольких серверов в один отказоустойчивый пул. Отдельная СХД ему не нужна: данные хранятся копиями на нескольких узлах, и отказ диска или целого сервера не останавливает работу. Ceph открытый и бесплатный, встроен в Proxmox VE и входит в российские платформы виртуализации.
Короткий ответ на вопрос «нужен ли он вам»: Ceph окупается, когда серверов от четырёх-пяти, между ними быстрая сеть и данные должны переживать отказ узла без внешней СХД. Для двух-трёх серверов малого офиса чаще проще и дешевле локальный ZFS с репликацией или обычная СХД. Ниже - почему, в цифрах.
Классическая схема для виртуализации выглядит так: несколько серверов и одна общая СХД, на которой лежат диски всех виртуальных машин. Схема понятная, но у неё три слабых места. СХД стоит дорого. Если отказывает она сама или её контроллеры, останавливается всё. Расти можно только полками того же производителя и в пределах того, что умеет конкретная модель.
Ceph убирает центральное хранилище из схемы. Диски стоят в обычных серверах, а программа раскладывает данные по ним так, чтобы каждая часть лежала в нескольких копиях на отдельных узлах. Кончилось место - добавили сервер с дисками, и Ceph сам перераспределит данные. Умер диск - копии есть на других серверах, и кластер восстановит недостающую сам.
За это платят сетью, количеством серверов и квалификацией администратора. Об этом дальше подробно.
Проект открытый. С 2023 года команду разработки Ceph, раньше работавшую в Red Hat, содержит IBM, код остался открытым. Ceph входит в Proxmox VE, поддерживается в ROSA Virtualization, описан в документации Astra Linux и платформы «Брест». Общий взгляд на класс таких систем даёт статья о том, что такое SDS.
В кластере Ceph работают несколько видов служб. Для малого кластера они обычно живут на тех же серверах, что и диски.
| Роль | Что делает | Сколько нужно в малом кластере |
|---|---|---|
| OSD (Object Storage Daemon) | одна служба на один диск: хранит данные, копирует их на другие OSD, участвует в восстановлении | по числу дисков, Proxmox рекомендует от 12 на кластер |
| MON (монитор) | хранит карту кластера и следит за кворумом | 3, нечётное число |
| MGR (менеджер) | метрики, веб-панель, модули | 2: активный и резервный |
| MDS (сервер метаданных) | нужен только для файловой системы CephFS | 2, если используете CephFS |
| RGW (шлюз) | отдаёт данные по протоколу S3 | 1-2, если нужен S3 |
Внизу всего лежит RADOS: слой, который хранит объекты и отвечает за их копии. Данные внутри делятся на пулы, пулы делятся на группы размещения (placement groups), а группы размещения раскладываются по дискам.
Главная идея Ceph - алгоритм CRUSH. У Ceph нет центрального справочника «какой файл на каком диске». Клиент получает от мониторов карту кластера и сам вычисляет, на каких OSD лежит нужный объект. Это как если бы каждому курьеру выдали одну и ту же формулу, по которой из номера заказа получается адрес склада: звонить диспетчеру не нужно, и диспетчер не становится узким местом. Поэтому Ceph масштабируется до сотен узлов.
Та же карта описывает домены отказа. По умолчанию две копии одного объекта никогда не окажутся на одном сервере. Отключили узел целиком, и у каждого объекта остались копии на других.
| Интерфейс | Что это | Где используют |
|---|---|---|
| RBD (блочное устройство) | виртуальный диск, который подключается к ВМ или серверу | диски виртуальных машин в Proxmox, OpenStack, Kubernetes |
| CephFS | общая файловая система, монтируется на многие серверы сразу | общие каталоги, данные приложений, образы |
| RGW (объектное хранилище) | S3-совместимый доступ по HTTP | резервные копии, архивы, файлы веб-приложений |
Для виртуализации в малом и среднем бизнесе главный из трёх - RBD: на нём лежат диски ВМ в гиперконвергентном кластере. S3 через Ceph подходит, чтобы поднять объектное хранилище S3 в своей стойке, хотя для небольших объёмов есть варианты проще.
Формальный минимум: три сервера. Типовая настройка пула: три копии данных (size=3), работа продолжается, пока доступны хотя бы две (min_size=2). Три узла дают ровно столько мест, сколько копий, и в этом подвох.
Отключился один сервер из трёх. Данные доступны: у каждого объекта остались две копии, запись и чтение идут. Но третью копию положить некуда, потому что копии должны лежать на отдельных серверах, а живых серверов два. Кластер работает в деградированном режиме, пока узел не вернут. Если в это время откажет ещё один диск, у части данных останется одна копия, меньше min_size, и запись в неё остановится до восстановления.
На четырёх серверах картина другая. Через 10 минут после отказа узла (параметр mon_osd_down_out_interval по умолчанию) Ceph признаёт его диски выбывшими, восстанавливает третью копию на оставшихся трёх серверах и снова становится полностью защищённым. Поэтому перед плановым выключением узла на кластере ставят флаг noout, чтобы восстановление не началось зря. Для этого на трёх оставшихся должно хватить свободного места. Отсюда расчёт, который редко делают до покупки.
Пример: в каждом сервере по четыре диска на 4 ТБ, три копии данных. Запас до порога заполнения nearfull держим 15 %: по умолчанию Ceph поднимает предупреждение при заполнении OSD на 85 %, на 90 % OSD перестаёт принимать данные при восстановлении, на 95 % кластер останавливает запись.
| Узлов | Сырой объём | После трёх копий | До порога 85 % | Сколько можно занять, чтобы кластер восстановился после отказа узла |
|---|---|---|---|---|
| 3 | 48 ТБ | 16 ТБ | 13,6 ТБ | восстановиться некуда, живёт на двух копиях |
| 4 | 64 ТБ | 21,3 ТБ | 18,1 ТБ | 13,6 ТБ |
| 5 | 80 ТБ | 26,7 ТБ | 22,7 ТБ | 18,1 ТБ |
Из 48 ТБ дисков в трёхузловом кластере под данные спокойно планируется около 13 ТБ, чуть больше четверти. Четвёртый сервер при тех же дисках не добавляет безопасного объёма, зато даёт кластеру возможность вылечиться самому. Заполнение по дискам всегда неравномерное, поэтому реальный порог стоит держать ещё ниже.
Документация Proxmox добавляет два правила. Дисков в кластере лучше от 12, распределённых поровну и одинаковых по объёму на всех узлах. В небольших кластерах лучше SSD, чем HDD: восстановление после отказа идёт быстрее, и окно, когда данные защищены хуже, короче.
Erasure coding вместо трёх копий экономит место: данные делятся на k частей и дополняются m частями контрольных сумм, по тому же принципу, что в RAID 5 и 6. Но каждая часть должна лежать на отдельном сервере, то есть нужно минимум k+m узлов, а для работы при отказе узла - ещё запас. Схема 2+1 на трёх серверах формально собирается, но при рекомендованном min_size = k+1 отказ любого сервера останавливает запись. Разумные схемы начинаются от 5-6 узлов, и для дисков ВМ erasure coding обычно не берут: запись медленнее, чем при копиях.
Ceph собирается на обычных серверах, но требования к ним свои. Главное:
| Компонент | Что нужно | Почему |
|---|---|---|
| Контроллер дисков | HBA или RAID-контроллер в режиме HBA (IT, JBOD), NVMe - напрямую | Ceph сам защищает данные, аппаратный RAID под OSD прячет от него диски и мешает |
| Диски под данные | серверные SSD или NVMe с защитой от потери питания; HDD - для объёма, с быстрыми дисками под метаданные | дешёвые клиентские SSD проседают по скорости под постоянной записью, а Ceph пишет на диски непрерывно |
| Системный диск | отдельное зеркало из двух SSD | система и мониторы не должны делить диски с OSD |
| Память | от 8 ГиБ на каждый OSD, служба по умолчанию берёт 4 ГБ | при восстановлении расход растёт |
| Процессор | минимум поток на каждую службу Ceph; на NVMe OSD - 4-6 потоков | быстрые диски упираются в процессор раньше, чем в скорость накопителя |
| Сеть | от 10 Гбит/с только под Ceph, лучше 25 Гбит/с | см. следующий раздел |
Чем HBA отличается от RAID-контроллера и как перевести контроллер в нужный режим, разобрано в статье HBA или RAID-контроллер. Про выбор накопителей рассказано в материале о NVMe-накопителях в серверах.
В гиперконвергентном кластере, где те же серверы запускают виртуальные машины, ресурсы Ceph вычитаются из ресурсов ВМ. Сервер с восемью NVMe под OSD отдаёт Ceph от 64 ГиБ памяти и 32-48 потоков процессора ещё до первой виртуальной машины. Если это не заложить в конфигурацию, кластер будет тормозить именно в момент восстановления после отказа, когда нагрузка и так выше обычной.
Узлы под такие кластеры обычно собирают на серверах с большим числом отсеков под диски, подходящие конфигурации есть в разделе сервер в стойку 19.
Каждая запись в Ceph уходит по сети на другие узлы: при трёх копиях основной OSD, получив данные, пересылает их ещё на два сервера. Когда отказывает диск, кластер начинает копировать его данные с других узлов, и это может быть сотни гигабайт или терабайты трафика.
Для производительных кластеров Proxmox рекомендует разделять сети:
| Сеть | Что по ней идёт | Рекомендация Proxmox |
|---|---|---|
| Публичная сеть Ceph | обмен между клиентами (ВМ) и OSD | от 10 Гбит/с |
| Кластерная сеть Ceph | копирование между OSD и восстановление | от 25 Гбит/с |
| Corosync | служебная связь узлов кластера Proxmox | отдельный порт 1 Гбит/с |
Для малого кластера допустимо совместить публичную и кластерную сети на одной паре 10 или 25 Гбит/с, но corosync лучше не сажать на те же порты: когда восстановление забьёт канал, узлы Proxmox начнут терять связь друг с другом. Какие адаптеры брать под такую схему, разобрано в статье про сетевые карты для виртуализации.
Частая ошибка: «на тестовом стенде Ceph работал на гигабите - значит, и в продуктиве потянет».
На пустом стенде восстанавливать нечего, и нагрузки нет. Гигабит заканчивается, как только у Ceph появляются реальные данные и первый отказ диска: копирование терабайта по 1 Гбит/с идёт больше двух часов при полной загрузке канала, и всё это время виртуальные машины делят его с восстановлением. Proxmox рекомендует под Ceph не меньше 10 Гбит/с.
В Proxmox VE Ceph встроен: он ставится и настраивается из того же веб-интерфейса, мониторы, менеджеры и OSD создаются мышкой. Серверы кластера одновременно запускают виртуальные машины и хранят их диски. Это и есть гиперконвергентная схема: без внешней СХД работают живая миграция ВМ между узлами и автоматический перезапуск ВМ при отказе сервера.
Актуальное на сентябрь 2026 года: Proxmox VE 9.2 для новых кластеров по умолчанию ставит Ceph 20.2 Tentacle. У предыдущей версии 19.2 Squid поддержка заканчивается 19 сентября 2026 года, так что кластеры на ней пора планировать к обновлению.
Ограничения схемы вытекают из предыдущих разделов. Ceph и ВМ делят процессор и память. Обновление Ceph - отдельная процедура поверх обновления Proxmox. Сеть под хранилище нужна заранее, а не когда кластер начал тормозить. Про сам гипервизор читайте в обзоре Proxmox VE.
У российских платформ картина разная. ROSA Virtualization поддерживает Ceph как хранилище. У zVirt штатного программного хранилища пока нет, гиперконвергентную схему там строят с MIND uStor другого разработчика. Подробнее об этом в сравнении российских платформ виртуализации.
Ceph силён там, где есть масштаб. На малом числе серверов его преимущества не успевают проявиться. Стоимость в сети, дисках и времени администратора остаётся полной.
| Ситуация | Что взять | Почему |
|---|---|---|
| Один сервер | локальный ZFS или аппаратный RAID | Ceph на одном узле не даёт отказоустойчивости, только сложность |
| Два сервера | ZFS на каждом + репликация Proxmox | Ceph на двух узлах в продуктиве не собирают: нет кворума мониторов и места для третьей копии |
| Три сервера, сеть 1 Гбит/с, до 20-30 ВМ | ZFS-репликация Proxmox или общая СХД по iSCSI/NFS | гигабита на Ceph не хватит, а три узла не дают самовосстановления |
| Три-четыре сервера, 10/25 Гбит/с, данные растут | Ceph или СХД - считать стоимость | Ceph уже работает, но полезный объём - около четверти сырого |
| Пять и больше серверов, десятки ТБ, нужен S3 или CephFS | Ceph | масштаб, на котором распределённое хранилище выигрывает у СХД |
| Есть СХД, её хватает, она на поддержке | оставить СХД | переход ради модной технологии добавит работы и не решит задачу |
Репликация ZFS в Proxmox проще Ceph, но это другой класс защиты. Диски ВМ копируются на соседний узел по расписанию, минимальный интервал - одна минута. Если сервер отказал, ВМ запустится на соседнем с тем состоянием, которое было на момент последней репликации: данные за этот интервал потеряются. Для 1С с постоянной записью это может быть неприемлемо, для файлового сервера или контроллера домена обычно терпимо. Как устроен ZFS в Proxmox, описано в статье про proxmox zfs, подробный разбор файловой системы есть в статье про ZFS.
И последнее, о чём забывают при выборе. Ceph нужно обслуживать: следить за состоянием кластера, разбираться, почему он перешёл в предупреждение, менять диски так, чтобы восстановление не совпало с пиком нагрузки, обновлять версии. Если в компании один администратор, который отвечает и за 1С, и за принтеры, общая СХД на поддержке у поставщика может оказаться надёжнее, чем Ceph, который некому сопровождать.
Для обучения и тестов да, если поменять домен отказа. Для продуктива нет: на одном сервере нет защиты от отказа узла, на двух нет кворума мониторов и места для третьей копии. Для двух серверов в Proxmox используют ZFS с репликацией.
Один-два сервера или гигабитная сеть: ZFS. Три узла и больше, сеть от 10 Гбит/с, нужны живая миграция и перезапуск ВМ без потери данных: Ceph. На трёх узлах выбор зависит от того, насколько критична потеря данных за интервал репликации.
Нет. Диски отдаются Ceph напрямую через HBA или контроллер в режиме HBA, а защиту данных делает сам Ceph копиями на соседних узлах. RAID нужен только под системный диск.
При трёх копиях остаётся треть сырого объёма, а с запасом под порог заполнения и восстановление после отказа узла около четверти. Из 48 ТБ дисков на трёх серверах под данные планируют около 13 ТБ.
СХД - отдельное устройство с контроллерами и полками, её отказоустойчивость живёт внутри одного корпуса. Ceph работает программой на обычных серверах и защищает данные между серверами. СХД проще в эксплуатации на малом масштабе, Ceph дешевле и гибче при росте.
По теме: NVMe over TCP или iSCSI · системные требования Proxmox
Собираете кластер на Ceph?
Инженеры ITTELO посчитают узлы под ваш объём и нагрузку: диски с защитой от потери питания, HBA вместо RAID, сеть 10/25 Гбит/с. Соберём и протестируем серверы перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
