Эксперты в подборе 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 ТБ, чуть больше четверти. Четвёртый сервер при тех же дисках не добавляет безопасного объёма, зато даёт кластеру возможность вылечиться самому. Заполнение по дискам всегда неравномерное, поэтому реальный