☁️ Виртуализация 📅 08.04.2026 ⏱️ 14 мин чтения ✍️ АйТи Фреш 👁 —

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

Мы в АйтИ-Фреш часто сталкиваемся с запросами на отказоустойчивую инфраструктуру, когда клиенту нужен гиперконвергентный кластер на Proxmox и Ceph, но пугает сложность настройки OSD и мониторов. В этой статье делюсь нашим практическим опытом сборки такого решения с нуля — от объединения дисков в распределённое хранилище до настройки живой миграции ВМ. Если понадобится помощь с развёртыванием или обслуживанием подобного кластера — обращайтесь.

Профильная услуга: внедрение open-source систем

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

Гиперконвергентная инфраструктура: зачем и когда

HCI — это когда вычисления и хранилище живут на одних и тех же серверах. Никакой отдельной СХД, никаких SAN/NAS с их ценниками и точками отказа. Диски всех серверов объединяются в распределённое хранилище Ceph, а Proxmox VE берёт на себя виртуализацию.

Почему мы вообще рекомендуем Proxmox + Ceph клиентам? Вот конкретные причины:

Стоимость: вы просто не покупаете отдельную СХД — а это легко 300–700 тысяч рублей экономии на старте
Масштабируемость: докинули ноду — получили сразу и CPU/RAM, и место под данные, без отдельного апгрейда хранилища
Отказоустойчивость: каждый блок данных живёт на 3 нодах одновременно, так что выход одной из них проходит совершенно незаметно для пользователей
Живая миграция: VM переезжают между нодами на ходу — без остановки, без окна обслуживания
Простота управления: один веб-интерфейс Proxmox закрывает всё — и виртуализацию, и хранилище

Минимум для нормальной работы — 3 ноды. Каждая одновременно работает и гипервизором (Proxmox VE), и узлом хранения (Ceph OSD). Меньше трёх нод не берите: Ceph без кворума превращается в тыкву. Рекомендуемые требования к серверу:

Параметр	Минимум	Рекомендуется
CPU	8 ядер	16+ ядер
RAM	32 ГБ	64+ ГБ
SSD/NVMe (OSD)	2 × 500 ГБ	4 × 1 ТБ NVMe
Сеть	2 × 10 GbE	2 × 25 GbE

Миграция с VMware: практический кейс

Один из наших клиентов, компания «ВиртуалПро», работала на трёх серверах Dell PowerEdge R740 с 40 виртуальными машинами под VMware vSphere. После покупки VMware компанией Broadcom лицензии подорожали втрое — с $15 000 до $45 000 в год. Полный переход на Proxmox + Ceph занял один рабочий день, а ежегодная экономия составила $73 000: $45 000 на лицензиях VMware, $8 000 на Veeam и $20 000 на vSAN.

Конвертация 40 VM заняла около 8 часов. Linux-машины заработали сразу после замены драйверов на virtio, Windows-машинам потребовалась установка VirtIO-драйверов после импорта. Время живой миграции между нодами сократилось с 15–30 секунд до 10–20 секунд.

Подготовка кластера Proxmox VE

Устанавливаем Proxmox VE 8.x на все три ноды. Систему — на отдельный SSD, лучше вообще вынести её на отдельный диск, чтобы не мешалась с Ceph. NVMe-диски под Ceph оставляем неразмеченными — Ceph сам разберётся с разметкой при создании OSD.

Сеть — это то, на чём чаще всего экономят и потом жалеют. Трафик Ceph между нодами может легко съесть весь канал, если не выделить для него отдельный интерфейс. Рекомендуемая схема:

# /etc/network/interfaces на каждой ноде
auto lo
iface lo inet loopback

# Management + Corosync
auto vmbr0
iface vmbr0 inet static
    address 10.0.1.11/24
    gateway 10.0.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

# Ceph Public + Cluster network (10GbE/25GbE)
auto vmbr1
iface vmbr1 inet static
    address 10.0.10.11/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
    mtu 9000

На Ceph-сети обязательно включайте Jumbo Frames с MTU 9000 — без этого теряете заметную часть производительности на мелких пакетах. Проверяем, что всё применилось:

ping -M do -s 8972 10.0.10.12

Создаём кластер Proxmox на первой ноде:

pvecm create my-cluster --link0 10.0.1.11

Присоединяем остальные ноды:

# На ноде 2
pvecm add 10.0.1.11 --link0 10.0.1.12

# На ноде 3
pvecm add 10.0.1.11 --link0 10.0.1.13

Проверяем, что все три ноды видят друг друга:

pvecm status
pvecm nodes

Типовой состав железа для офиса

Для офиса на 30–50 рабочих мест мы собираем кластер из трёх одинаковых серверов. Два узла — формальный минимум, но без третьего (или QDevice) кластер теряет кворум, и любой сбой останавливает все VM разом. Типовой конфиг, который мы закупаем под средний бизнес:

Платформа: Dell R650 или HP DL380 Gen10 б/у, Xeon Silver 4310 / Gold 6330, 128–256 ГБ ECC.
ОС-диски: 2 × Samsung PM893 480 ГБ в ZFS mirror — только для PVE и Ceph monitor.
VM-диски: 4–6 × NVMe 1.92 ТБ под OSD Ceph.
Сеть: 2 × 10G Intel X710 + 2 × 1G для management.
Свитч: Mikrotik CRS317 или MES5324, 10G L3 с LACP.
UPS: APC Smart-UPS SRT 3000 × 2, по линии питания на каждый ряд.

Итого по железу — 600–900 тыс. руб. за три б/у сервера плюс 150–250 тыс. руб. на сетевое. Новое обходится в 2,5–3 раза дороже, но клиенты на 30–50 мест обычно берут б/у с вендорской гарантией — разумный компромисс.

Развёртывание Ceph через веб-интерфейс Proxmox

Proxmox VE умеет устанавливать Ceph прямо из веб-интерфейса — это удобно и избавляет от лишних шагов. Заходим в любую ноду → Ceph → Install Ceph, выбираем версию Reef (18.x) и жмём Install. Просто и без магии.

Если привычнее через CLI — на каждой ноде выполняем:

pveceph install --repository no-subscription
pveceph init --network 10.0.10.0/24 --cluster-network 10.0.10.0/24

Параметр --network — это public network, по которой клиенты ходят к Ceph. Параметр --cluster-network — отдельная сеть для репликации между OSD, и лучше их не смешивать. В совсем маленьких кластерах можно обойтись одной сетью, но с ростом нагрузки это аукнется.

Создание мониторов и менеджеров

Ceph-мониторы (MON) — это мозг кластера, они хранят карту состояния и обеспечивают кворум. Нужно минимум 3 монитора, по одному на каждую ноду — иначе при потере одной ноды кластер встанет:

# На каждой ноде
pveceph mon create

# Проверка
pveceph status

Менеджеры (MGR) добавляют мониторинг, дашборды и ряд дополнительных функций. Создаём:

pveceph mgr create

После того как мониторы подняты на всех трёх нодах, кластер покажет HEALTH_WARN — это нормально, OSD ещё нет. Главное убедиться, что в кворуме именно 3 монитора.

Создание OSD

OSD (Object Storage Daemon) — это процесс, который управляет одним физическим диском. Под каждый NVMe создаём отдельный OSD:

# На ноде 1
pveceph osd create /dev/nvme0n1
pveceph osd create /dev/nvme1n1

# На ноде 2
pveceph osd create /dev/nvme0n1
pveceph osd create /dev/nvme1n1

# На ноде 3
pveceph osd create /dev/nvme0n1
pveceph osd create /dev/nvme1n1

Если хотите выжать максимум производительности — выделите отдельный NVMe специально под WAL и DB блоки Ceph. На практике это даёт заметный прирост на смешанной нагрузке:

pveceph osd create /dev/sda --db_dev /dev/nvme2n1 --wal_dev /dev/nvme2n1

Когда все OSD созданы и кластер их увидел, статус должен смениться на HEALTH_OK. Проверяем:

ceph -s
ceph osd tree

Настройка пулов и хранилищ

Ceph Pool — это логическое хранилище с заданным уровнем репликации. Создаём отдельные пулы для дисков виртуальных машин и контейнеров — смешивать их в один пул не стоит:

# Пул для виртуальных машин (3 реплики)
pveceph pool create vm-pool --size 3 --min_size 2 --pg_num 128

# Пул для контейнеров
pveceph pool create ct-pool --size 3 --min_size 2 --pg_num 64

# Пул для ISO-образов и шаблонов
pveceph pool create iso-pool --size 2 --min_size 1 --pg_num 32

Разберём ключевые параметры:

size=3 — три копии каждого блока данных; кластер спокойно переживёт выход одной ноды
min_size=2 — минимум копий, необходимых для записи; при min_size=1 данные останутся доступны даже при потере двух нод, но с реальным риском потери данных — на продакшне так не делаем
pg_num — количество Placement Groups; считается по формуле OSD * 100 / size / пулы, не берите от балды

Подключаем созданные пулы как хранилища в Proxmox:

# В веб-интерфейсе: Datacenter → Storage → Add → RBD
# Или через CLI:
pvesm add rbd ceph-vm --pool vm-pool --content images,rootdir --krbd 0
pvesm add rbd ceph-ct --pool ct-pool --content rootdir --krbd 0
pvesm add rbd ceph-iso --pool iso-pool --content iso,vztmpl --krbd 0

Всё, теперь при создании VM или контейнера просто выбираете ceph-vm или ceph-ct в качестве хранилища — и диски сразу оказываются в Ceph.

Живая миграция виртуальных машин

Вот где Ceph раскрывается по-настоящему. Поскольку хранилище общее для всех нод, VM можно перемещать между ними прямо на ходу — без остановки, без даунтайма. Живая миграция работает именно потому, что данные не привязаны к конкретному серверу.

Через веб-интерфейс — элементарно: правый клик по VM → Migrate → выбираем целевую ноду → Migrate. Занимает секунды.

Через CLI:

# Живая миграция VM 100 на ноду pve-02
qm migrate 100 pve-02 --online

# Миграция контейнера
pct migrate 200 pve-03 --online --restart

Если нода уходит на обслуживание — используйте режим maintenance, он сам эвакуирует все VM на соседние ноды:

# Перевести ноду в режим обслуживания (все VM мигрируют автоматически)
ha-manager set vm:100 --state migrate

# Или через HA-группы
ha-manager groupadd ha-group --nodes pve-01,pve-02,pve-03 --nofailback 0
ha-manager add vm:100 --group ha-group --state started --max_restart 3 --max_relocate 2

HA в Proxmox — это автоматический перезапуск VM на живой ноде, если текущая упала. Работает без ручного вмешательства, но VM нужно предварительно добавить в группу HA:

# В веб-интерфейсе: Datacenter → HA → Add
# Или CLI:
ha-manager add vm:100 --state started
ha-manager add vm:101 --state started
ha-manager add ct:200 --state started

Миграция с VMware ESXi на Proxmox

Начиная с Proxmox VE 8.2 появился встроенный ESXi-import. Подключаете ESXi к PVE как Storage: Datacenter → Storage → Add → ESXi, указываете адрес сервера и учётные данные. После добавления видите список VM на ESXi. Выбираете VM → Import → Target storage/node. Proxmox сам конвертирует VMDK в qcow2 или raw и создаёт VM с аналогичной конфигурацией — CPU, RAM, сеть. По времени: 100 ГБ диска по 10G сети занимает 15–40 минут.

Грабли, на которые мы наступали:

VMware Tools в госте нужно удалить до миграции — иначе после конвертации VM не запустится корректно.
Гость на UEFI-BIOS — при импорте выбирайте OVMF, иначе не загрузится.
Сетевая карта меняется (VMXNET3 → VirtIO) — гостевая ОС присваивает новый MAC и теряет IP. Лечится через netplan apply или ручной reset netsh на Windows.

Миграция VM с VMware на Proxmox

Если вы переезжаете с VMware, самый быстрый способ для офлайн-миграции — конвертация дисков через qemu-img:

# Экспорт VMDK из VMware
scp admin@esxi:/vmfs/volumes/ds1/myvm/myvm-flat.vmdk /tmp/

# Конвертация VMDK → qcow2
qemu-img convert -f vmdk -O qcow2 myvm-flat.vmdk myvm.qcow2

# Импорт в пул Ceph
qm importdisk 100 myvm.qcow2 ceph-pool --format raw

# Подключение диска к VM
qm set 100 --scsi0 ceph-pool:vm-100-disk-0

Для автоматической конвертации с установкой драйверов используйте virt-v2v:

virt-v2v -i vmx /path/to/myvm.vmx -o local -os /var/lib/vz/images/100/ --bridge vmbr0

Для Linux VM с минимальным даунтаймом подойдёт копирование через сеть:

dd if=/dev/sda bs=4M | ssh root@proxmox 'dd of=/dev/zvol/rpool/data/vm-100-disk-0 bs=4M'

Мониторинг и обслуживание кластера Ceph

Состояние кластера Ceph видно прямо в веб-интерфейсе Proxmox на вкладке Ceph. Но для реальной диагностики удобнее CLI — вот команды, которые мы используем чаще всего:

# Общий статус кластера
ceph -s

# Подробная информация об OSD
ceph osd tree
ceph osd df

# Статус пулов
ceph df detail
rados df

# Производительность в реальном времени
ceph -w

# Здоровье кластера с рекомендациями
ceph health detail

Несколько предупреждений, с которыми сталкиваются почти все, и что с ними делать:

HEALTH_WARN: 1 nearfull osd(s) — диск заполнен больше чем на 85%, Ceph начинает нервничать. Добавляйте диски или чистите данные, не тяните до full
HEALTH_WARN: too few PGs per OSD — пересчитайте и увеличьте pg_num для пулов, иначе производительность просядет
HEALTH_WARN: clock skew detected — время на нодах разошлось, Ceph это не любит. Лечится просто: timedatectl set-ntp true на каждой ноде

Замена диска OSD

Диски умирают — это факт жизни. Хорошая новость: Ceph при потере диска сам начинает перебалансировку данных на оставшиеся OSD. Порядок замены такой:

# 1. Помечаем OSD как вышедший из строя
ceph osd out osd.3

# 2. Останавливаем OSD
sudo systemctl stop ceph-osd@3

# 3. Удаляем из CRUSH-карты
ceph osd crush remove osd.3
ceph auth del osd.3
ceph osd rm osd.3

# 4. Физически заменяем диск

# 5. Создаём новый OSD на новом диске
pveceph osd create /dev/sdX

Перебалансировка стартует автоматически, как только новый OSD появляется в кластере. Следим за прогрессом в реальном времени: ceph -w.

CephFS для общего файлового хранилища — Настройка резервного копирования через PBS

Proxmox Backup Server для резервных копий

PBS — выделенный сервер, живущий отдельно от кластера и хранящий дедуплицированные бэкапы. Мы ставим его на отдельную машину — не обязательно серверную, подойдёт i5/i7 с 32 ГБ RAM и 4–8 ТБ SATA SSD.

# На кластере — добавляем PBS как storage
pvesm add pbs backups --server 10.10.0.50 \
  --datastore vmstore --fingerprint AB:CD:EF:... \
  --username root@pam

Настраиваем Backup Job: Datacenter → Backup → Add, schedule 23:00 Mon..Sun, storage pbs-backups, mode snapshot. Первая копия — полная, все следующие — инкременты с дедупликацией. Из нашего опыта: 20 VM общим размером 1,8 ТБ укладываются в 280–320 ГБ на PBS при хранении 30 дней.

Бэкап с Proxmox Backup Server

Proxmox Backup Server (PBS) — отдельный продукт, который интегрируется с Proxmox VE и даёт дедупликацию и инкрементальные бэкапы из коробки. Устанавливается на отдельный сервер или VM, после чего подключается как хранилище:

# Datacenter → Storage → Add → Proxmox Backup Server
# Server: 10.0.1.50
# Datastore: vm-backups
# Fingerprint: из веб-интерфейса PBS

Расписание настраивается через Datacenter → Backup → Add. Рекомендуемый режим — snapshot, он не останавливает VM. Для ротации: keep-daily=7, keep-weekly=4, keep-monthly=6.

Для Linux-сервисов (nginx, PostgreSQL, Redis) используйте LXC-контейнеры вместо полных VM — overhead по RAM и CPU в 3–5 раз ниже.

CephFS для общего файлового хранилища

Ceph умеет не только блочное хранилище (RBD) для VM-дисков. Есть ещё CephFS — распределённая файловая система с поддержкой POSIX, которая монтируется как обычная папка и доступна сразу со всех нод.

CephFS создаётся прямо из интерфейса Proxmox:

# Создаём пулы для метаданных и данных
pveceph pool create cephfs-meta --size 3 --pg_num 32
pveceph pool create cephfs-data --size 3 --pg_num 128

# Создаём MDS (Metadata Server) на каждой ноде
pveceph mds create

# Создаём файловую систему
ceph fs new cephfs cephfs-meta cephfs-data

Теперь подключаем CephFS как хранилище в Proxmox:

pvesm add cephfs ceph-shared --content snippets,iso,vztmpl --fs-name cephfs

CephFS монтируется и на обычных Linux-серверах — как стандартная файловая система:

# На клиентской машине
sudo apt install ceph-common -y

# Получаем ключ
ceph auth get-key client.admin

# Монтируем
sudo mount -t ceph 10.0.10.11:6789,10.0.10.12:6789,10.0.10.13:6789:/ /mnt/cephfs \
  -o name=admin,secret=AQDxxxxxxxxxxxxxxxxxxxxx==

# Или через fstab
echo '10.0.10.11:6789,10.0.10.12:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/admin.secret,noatime 0 0' >> /etc/fstab

На практике CephFS мы используем для ISO-образов, шаблонов контейнеров и бэкапов. Главный плюс — всё это доступно сразу со всех нод кластера, без лишних телодвижений.

Часто задаваемые вопросы

Технически — да, с двумя нодами запуститься можно. Через внешний QDevice на третьей машине Proxmox-кластер соберётся. Но Ceph с двумя нодами — это не отказоустойчивость, а её имитация: упала одна нода — данные недоступны. Для продакшена минимум три ноды, точка.

Для Ceph-трафика берите минимум 10 Гбит/с. На гигабите кластер поднимется, но NVMe-диски упрутся в сеть — толку от них будет немного. Если стоят NVMe с пропускной способностью от 3 ГБ/с, переходите на 25 Гбит/с, иначе деньги на железо выброшены зря. И обязательно включите Jumbo Frames — MTU 9000.

С тремя репликами (size=3) полезная ёмкость — ровно треть от сырого объёма. Считайте сами: 6 NVMe по 1 ТБ, по две на ноду — это 6 ТБ на бумаге и 2 ТБ реальных. Плюс Ceph не рекомендует заполнять хранилище выше 85%, так что рабочий объём — около 1,7 ТБ. Это нужно закладывать в проект заранее.

Можно, но скорость просядет заметно. HDD в роли OSD для виртуальных машин — не лучшая идея. Зато для холодного хранения — бэкапов, архивов — HDD вполне подходят. Мы в таких случаях делаем два пула: быстрый NVMe для дисков VM и медленный HDD для бэкапов. Разделяется это через CRUSH-правила Ceph — гибко и без лишних костылей.

Добавить ноду в работающий Proxmox+Ceph кластер можно без остановки сервисов. Ставите Proxmox VE на новый сервер, вводите его в кластер через pvecm add, устанавливаете Ceph командой pveceph install, поднимаете MON, MGR и OSD. Дальше Ceph сам перебалансирует данные на четыре ноды — от вас больше ничего не требуется.

#Proxmox#Ceph#гиперконвергентный кластер#HCI#виртуализация#распределённое хранилище#OSD#живая миграция

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики