PVE позволяет использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для размещения реплицированного хранилища.
Ceph — программная объектная отказоустойчивая система хранения данных. Она обеспечивает файловый и блочный доступ к данным. Ceph интегрирован в PVE, поэтому запуск и управление хранилищем Ceph возможны непосредственно на узлах гипервизора.
Преимущества использования Ceph в PVE:
простая настройка и управление через веб-интерфейс и командную строку;
гибкое резервирование данных;
поддержка моментальных снимков;
самовосстановление;
масштабируемость до уровня эксабайт;
настройка пулов с различными характеристиками производительности и избыточности;
репликация данных для обеспечения отказоустойчивости;
работа на стандартном оборудовании;
отсутствие необходимости в аппаратных RAID-контроллерах;
открытый исходный код.
pveceph — инструмент для установки и управления службами Ceph на узлах PVE.
Кластерная система хранения данных Ceph состоит из нескольких демонов:
Монитор Ceph (ceph-mon) — хранит информацию о состоянии кластера, карту всех узлов и правила распределения данных (CRUSH-карту). Мониторы также отвечают за управление аутентификацией между демонами и клиентами. Для обеспечения резервирования и высокой доступности требуется не менее трех мониторов;
Менеджер Ceph (ceph-mgr) — собирает информацию о состоянии всего кластера и работает совместно с демонами мониторов. Он обеспечивает расширенный мониторинг, взаимодействует с внешними системами управления и мониторинга, а также предоставляет дополнительные сервисы. Для обеспечения высокой доступности требуется по крайней мере два менеджера.
OSD Ceph (ceph-osd; демон хранилища объектов) — управляет устройствами хранения объектов, которые представляют собой физические или логические единицы хранения (жесткие диски или разделы). Демон также отвечает за репликацию данных и перебалансировку при добавлении или удалении узлов. Демоны OSD взаимодействуют с мониторами и передают им информацию о своём состоянии. OSD являются основными демонами кластера и несут основную нагрузку. Для обеспечения резервирования и высокой доступности требуется не менее трёх OSD.
Сервер метаданных Ceph (Metadata Server) — хранит метаданные файловой системы CephFS (блочные устройства Ceph и объектное хранилище Ceph MDS не используют). Разделение метаданных и пользовательских данных значительно повышает производительность кластера. Серверы метаданных позволяют клиентам файловой системы POSIX выполнять базовые операции (например, ls, find и т.д.) без создания избыточной нагрузки на кластер хранения.
26.6.1. Системные требования
Для построения гиперконвергентного кластера PVE + Ceph рекомендуется использовать не менее трёх идентичных серверов.
Требования к оборудованию Ceph могут варьироваться в зависимости от размера кластера, ожидаемой нагрузки и других факторов.
Таблица 26.4. Системные требования к оборудованию для Ceph
|
Процесс
|
Критерий
|
Требования
|
|
Монитор Ceph
|
Процессор
|
2 ядра минимум, 4 рекомендуется
|
|
ОЗУ
|
5ГБ+ (большим/производственным кластерам нужно больше)
|
|
Жёсткий диск
|
100 ГБ на демон, рекомендуется SSD
|
|
Сеть
|
1 Гбит/с (рекомендуется 10+ Гбит/с)
|
|
|
|
Менеджер Ceph
|
Процессор
|
1 ядро
|
|
ОЗУ
|
1 ГБ
|
|
|
|
OSD Ceph
|
Процессор
|
1 ядро минимум, 2 рекомендуется
1 ядро на пропускную способность 200-500 МБ/с
1 ядро на 1000-3000 IOPS
SSD OSD, особенно NVMe, выиграют от дополнительных ядер на OSD
|
|
ОЗУ
|
|
|
Жёсткий диск
|
1 SSD накопитель на демон
|
|
Сеть
|
1 Гбит/с (рекомендуется агрегированная сеть 10+ Гбит/с)
|
|
|
|
Сервер метаданных Ceph
|
Процессор
|
2 ядра
|
|
ОЗУ
|
2 ГБ+ (для производственных кластеров больше)
|
|
Жёсткий диск
|
1 ГБ на демон, рекомендуется SSD
|
|
Сеть
|
1 Гбит/с (рекомендуется 10+ Гбит/с)
|
Серверу в целом требуется не менее суммы ресурсов всех демонов, размещённых на нём, а также дополнительные ресурсы для журналов и других компонентов ОС. Следует учитывать, что потребность в ОЗУ и хранилище возрастает при запуске кластера, а также во время отказов, добавления компонентов и перебалансировки данных.
Дополнительные рекомендации:
Память: при гиперконвергентной конфигурации необходимо тщательно контролировать потребление памяти. Помимо потребностей ВМ и контейнеров, следует обеспечить достаточный объём ОЗУ для работы Ceph.
Сеть: рекомендуется использовать выделенную сеть со скоростью не менее 10 Гбит/с исключительно для Ceph. Объем трафика, особенно во время восстановления данных, может негативно влиять на другие службы в той же сети и даже нарушать работу кластера PVE. Необходимо заранее оценить потребность в пропускной способности: один жёсткий диск, как правило, не заполняет канал 1 Гбит/с, однако несколько OSD на одном узле — могут, а современные NVMe-накопители способны быстро насытить и 10 Гбит/с. Использование сетей 25, 40 или 100 Гбит/с позволяет избежать подобных узких мест.
Жесткие диски: OSD-диски ёмкостью значительно менее 1 ТБ используют заметную часть пространства под метаданные, а диски объёмом менее 100 ГБ практически неэффективны. Настоятельно рекомендуется использовать SSD как миниму для узлов мониторов и менеджеров Ceph, а также для пулов метаданных CephFS и индексов Ceph Object Gateway (RGW), даже если для хранения пользовательских данных применяются жёсткие диски.
Ceph наиболее эффективно работает при равномерном распределении одинаковых по размеру дисков между узлами. Например, конфигурация из четырёх дисков по 500 ГБ на каждом узле предпочтительнее смешанной конфигурации с одним диском на 1 ТБ и тремя по 250 ГБ.
Необходимо также балансировать количество OSD и их ёмкость. Большая ёмкость увеличивает плотность хранения, но при отказе одного OSD системе потребуется восстанавливать больший объём данных одновременно.
Поскольку Ceph самостоятельно управляет избыточностью и параллельной записью данных, использование RAID-контроллеров обычно не повышает производительность или надёжность. Напротив, RAID-контроллеры могут ухудшать работу Ceph из-за собственных алгоритмов записи и кеширования.
Следует избегать использования RAID-контроллеров — Ceph самостоятельно управляет избыточностью. Вместо них рекомендуется использовать HBA-адаптеры.
Приведенные рекомендации являются ориентировочными. Конфигурацию оборудования необходимо адаптировать под конкретные задачи, регулярно тестировать и контролировать производительность и состояние кластера.