Настройка Proxmox кластера для высокой доступности

Ошибка при настройке кластера Proxmox может стоить вам данных. Типичный сценарий: два узла, общее хранилище не настроено, кластер постоянно теряет кворум, ВМ падают каждую неделю. Мы знаем, как это исправить. За 5 лет мы реализовали 30+ проектов по настройке HA кластеров Proxmox для компаний разного масштаба — от стартапов до enterprise. Наша цель — чтобы ваши ВМ автоматически мигрировали при сбое узла, а downtime измерялся минутами, а не часами.

Как настроить Proxmox кластер для высокой доступности?

Мы делимся практическими конфигами, проверенными в бою. В этой статье разберём ключевые архитектурные решения: от выбора хранилища до настройки fencing. Стоимость решения рассчитывается индивидуально, но обычно ниже на 20–30% по сравнению с аналогами на VMware.

Проблемы, которые решаем

Минимальное количество узлов: 3

Кворум (большинство голосов) требуется для принятия решений кластером. С 2 узлами при потере связи каждый считает себя единственным выжившим — возникает split-brain, и оба пытаются запустить одинаковые ВМ, что приводит к повреждению данных. 3 узла гарантируют, что при любом единичном отказе остаётся большинство. Согласно документации Proxmox, кворум критичен для целостности кластера.

Как избежать типичных ошибок сети?

Самая частая проблема — общее хранилище не настроено или настроено неправильно. HA в Proxmox требует shared storage: ВМ должна быть доступна с любого узла. Если диск ВМ лежит на локальном ZFS хоста, при его падении ВМ никуда не мигрирует — данные недоступны.

Вторая проблема — 1 сетевой интерфейс для всего трафика. Cluster network (corosync), migration network и VM трафик на одном NIC: при высокой нагрузке коросинк теряет пакеты, кластер считает хост мёртвым и начинает fence — принудительно отключает питание через IPMI. На самом деле хост жив, просто занят. Итог — ненужный failover и downtime.

Сетевая архитектура: что и почему

Рекомендуемая схема для 3 узлов:

Corosync на выделенном интерфейсе — обязательно. Если отдельный физический NIC недоступен, используем VLAN с приоритетом QoS.

Как выбрать общее хранилище для Proxmox HA?

Выбор shared storage определяет отказоустойчивость и бюджет. Сравним основные варианты.

Сравнение вариантов shared storage

Ceph — встроен в Proxmox, распределённое хранилище прямо на дисках узлов. Каждый узел вносит диски в Ceph пул, данные реплицируются между 3 узлами автоматически. Минус: Ceph потребляет ~2–4 GB RAM на OSD.

NFS/iSCSI — внешний СХД. Проще в управлении, но единая точка отказа, если СХД не имеет собственного HA.

Shared ZFS через iSCSI — ZFS на dedicated storage сервере, экспортируется как iSCSI LUN и монтируется на все узлы.

Создание кластера

# На первом узле — создаём кластер
pvecm create pve-cluster --link0 address=10.10.1.1 --link1 address=10.10.2.1
# На втором и третьем узлах — присоединяемся
pvecm add 10.10.1.1 --link0 address=10.10.1.2 --link1 address=10.10.2.2
pvecm add 10.10.1.1 --link0 address=10.10.1.3 --link1 address=10.10.2.3
# Проверяем статус кластера
pvecm status

--link0 и --link1 — 2 независимых пути corosync. При потере одного — кластер продолжает работу через второй. Это redundant ring protocol, критично для стабильности.

Настройка HA Manager

После настройки shared storage включаем HA для конкретных ВМ:

# Добавление ВМ в HA группу
ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2

# Создание HA группы с приоритетами узлов
ha-manager groupadd production-group --nodes pve1:3,pve2:2,pve3:1 --restricted 1
ha-manager add vm:101 --group production-group

max_restart — сколько раз HA пытается рестартовать ВМ на текущем узле до эвакуации. max_relocate — сколько раз переносит на другой узел. restricted — ВМ запускается только на узлах из группы.

Почему fencing критичен?

Fencing — обязательный компонент HA. Proxmox должен уметь принудительно отключить питание проблемного узла, прежде чем запустить его ВМ на другом хосте. Без fencing данные могут повредиться: два хоста пишут в один диск одновременно. Настраиваем через IPMI/iDRAC/iLO:

# Настройка IPMI fencing для узла pve1
pvesh set /nodes/pve1/config --wakeonlan 0
# В /etc/pve/corosync.conf добавляем fence agent конфигурацию

totem {
  ring0_addr: 10.10.1.1
  ring1_addr: 10.10.2.1
}
quorum {
  provider: corosync_votequorum
}
nodelist {
  node {
    name: pve1
    nodeid: 1
  }
}
logging {
  to_syslog: yes
}

Live Migration и нагрузка

Proxmox поддерживает live migration (аналог vMotion) для ВМ без выключения. Для корректной работы: одинаковые или совместимые CPU на всех узлах (флаг --cpu host ограничивает миграцию — используем --cpu kvm64 для совместимости), общая storage, migration network на отдельном интерфейсе.

# Ручная live migration ВМ 101 на узел pve2 qm migrate 101 pve2 --live 1 --migration_network 10.10.3.0/24 

Что входит в работу

1. Полная документация по настройке кластера, сети и storage
2. Доступы к Proxmox, IPMI, мониторингу для вашего админа
3. Обучение команды базовым операциям (3–4 часа)
4. Гарантия работоспособности HA-конфигурации в течение 30 дней
5. Пост-релизная поддержка: 3 месяца консультаций по телефону/почте
6. Миграция данных из существующей инфраструктуры (при необходимости)
7. Скрипты автоматического восстановления для типовых сбоев

Получите консультацию инженера перед началом работ — мы подберём оптимальную архитектуру под ваш бюджет и нагрузку. Закажите настройку под ключ и получите кластер, готовый к продакшну. Экономия на отказоустойчивости может достигать 40% по сравнению с традиционными решениями. Свяжитесь с нами для оценки вашего проекта.

Сроки

Настройка 3-узлового кластера с Ceph: 3–5 дней. С внешним СХД (NFS/iSCSI): 2–3 дня. С нуля, включая установку ОС на хосты: добавить 1–2 дня.