Proxmox + Ceph: гиперконвергентный кластер с нуля для корпоративной инфраструктуры

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. Гиперконвергентные кластеры на Proxmox + Ceph я строю с 2019 года — от компактных трёхнодовых для офиса на 80 человек до больших сборок на пять узлов с 40G-фабрикой Mellanox в дата-центре МТС. Поделюсь тем, что у нас на практике даёт надёжность и предсказуемую производительность.

Зачем HCI на Proxmox + Ceph

Классическая схема «серверы + СХД» требует дорогой железки с двумя контроллерами и вендор-локом. HCI кладёт данные прямо на диски компьют-узлов: отказоустойчивость за счёт реплики 3х, линейное масштабирование по объёму и IOPS, отсутствие single point of failure. И всё это на открытом софте без лицензий.

Железо: требования, которые не обойти

Я всегда повторяю клиентам: HCI на Ceph — это не «подниму на десктопных дисках, потом поменяю». Поменять потом — значит мигрировать данные, терять ночи и нервы.

Сеть: критичный слой

Ceph генерирует репликационный трафик 2х от клиентского write, плюс heartbeat-проверки. У нас на практике всегда две независимые сети: публичная (ВМ + клиенты Ceph) и cluster (репликация между OSD). Обе на 40G Mellanox ConnectX-5, связь через коммутатор Mikrotik CRS504.

# /etc/network/interfaces на каждом узле
auto bond0
iface bond0 inet static
  address 10.10.10.11/24
  bond-slaves enp2s0f0 enp2s0f1
  bond-mode 802.3ad
  bond-miimon 100
  mtu 9000
# public_network = 10.10.10.0/24
# cluster_network = 10.10.20.0/24

Сборка кластера PVE

# На первом узле
pvecm create production-cluster
# На остальных
pvecm add 10.10.10.11 --link0 10.10.10.11
pvecm status

Установка Ceph через PVE

pveceph install --repository no-subscription
pveceph init --network 10.10.10.0/24 --cluster-network 10.10.20.0/24
# На трёх узлах создаём мониторы
pveceph mon create
# Менеджеры
pveceph mgr create

Создание OSD

Каждый NVMe-диск — отдельный OSD. BlueStore с WAL/DB на том же устройстве (для NVMe нет смысла выносить).

for disk in /dev/nvme{1,2,3,4}n1; do
  pveceph osd create $disk
done
ceph osd tree

Пулы и CRUSH

# RBD-пул для ВМ с репликой 3
pveceph pool create vm-pool --size 3 --min_size 2 \
  --pg_autoscale_mode on --application rbd

# Проверка
ceph osd pool ls detail
rbd pool init vm-pool

Мини-кейс: кластер для ритейла

Сентябрь 2025, клиент — сеть из 42 магазинов с центральной 1С и SCADA. Дата-центр МТС, пять узлов Dell R750 с Xeon Platinum 8280, 512 ГБ RAM, по 6 NVMe 7,68 ТБ Samsung PM9A3. Сеть 40G Mellanox. На 230 ТБ raw получили 76 ТБ usable после реплики 3. IOPS-потолок 4K random write — 340 000 с одного клиента. Один узел на плановом обслуживании выпадает без единого прерывания сервиса. Стоимость железа — 14,2 млн руб., внедрение — 480 000 руб., срок работ — 11 дней.

Мониторинг и типичные грабли

• Не ставьте MON на 2 узла — будет split-brain. Минимум 3, лучше 5.
• Consumer SSD без PLP убивают кластер за полгода. Только Enterprise.
• MTU 9000 везде или нигде — смешанная фабрика даёт дикие тормоза.
• noout/norebalance без понимания — путь к data loss.
• Мониторинг через Prometheus + Grafana с ceph-exporter, алерты на HEALTH_WARN.

FAQ — частые вопросы

Сколько узлов минимум нужно для Ceph?

Технически три, практически пять. Три монитора для кворума, плюс запас на обслуживание одного узла без потери отказоустойчивости.

Можно ли использовать SATA SSD?

Можно, но только enterprise-линейку с PLP и высоким DWPD. Consumer-SSD умирают за полгода под нагрузкой OSD.

Зачем отдельная сеть для Ceph?

Трафик репликации и восстановления может забить гигабит за секунды. Минимум 10G, рекомендуется 25-40G Mellanox.

Какую репликацию выбрать?

Для прода size=3 min_size=2. Erasure coding только для архивных пулов, а для ВМ — только 3х реплика.

Что делать, если упал один узел?

Ceph автоматически перераспределит данные на оставшиеся. Главное — иметь запас места и не трогать noout/norebalance без понимания.