Proxmox VE и Ceph: настройка гиперконвергентного кластера с командами

Когда Proxmox с Ceph имеет смысл

Типовая задача — дать нескольким гипервизорам доступ к дискам ВМ без отдельной внешней СХД. При плановом обслуживании ВМ можно перемещать между узлами. При аварии HA может запустить её на доступном сервере, если сохранились кворум, хранилище и необходимые ресурсы. Аварийный перезапуск всё равно прерывает работу приложения.

Для небольшой площадки локальный ZFS с резервным копированием иногда проще. ZFS-репликация между узлами — отдельный вариант с асинхронной передачей изменений и своим RPO. Она не превращает локальный диск в общее синхронное хранилище. Сравнивайте стоимость эксплуатации и нужный сценарий отказа, а не только цену дисков.

Основа архитектуры: официальное руководство Proxmox по хранилищам. Версия примера: выпуск Proxmox VE 9.2.

Кто за что отвечает: пять компонентов

Пример проекта: три узла, отдельные диски и сети

Названия pve01–pve03, интерфейсы и адреса ниже условные. Сначала составьте собственный паспорт: серийный номер сервера, порт, коммутатор, VLAN, IP, диск и его роль. Не переносите пример в рабочую сеть без сверки.

• Системные диски: отдельная пара под ОС, например зеркало. Не смешивайте её с OSD в этом примере.
• Данные: по четыре выделенных SSD на узел; всего 12 OSD. Диски одного назначения выбирайте сопоставимыми по классу, ресурсу и задержкам.
• Контроллер: прямой доступ к дискам, HBA/JBOD. Аппаратный RAID под группой OSD скрывает диски и усложняет модель отказа.
• CPU/RAM: бюджет для ОС, Ceph и ВМ считайте раздельно. Для предварительной оценки можно отложить по 8 ГиБ на OSD: четыре OSD — уже 32 ГиБ на узел только в этом бюджете, плюс остальные службы и ВМ. Это проектное допущение, не универсальная настройка и не гарантия достаточности. Учитывайте восстановление и размещение гостей после отказа одного сервера.

Почему 46 ТБ дисков — это не 46 ТБ для ВМ

Учебный расчёт: 3 узла × 4 диска × 3,84 ТБ = 46,08 ТБ raw. При трёх копиях грубая верхняя оценка — 46,08 / 3 = 15,36 ТБ до служебных расходов и неравномерности заполнения. Если для предварительного бюджета отложить условные 25%, получится 11,52 ТБ. Это пример планирования, а не универсальный порог Ceph или гарантированный полезный объём.

Реальную доступность определяют CRUSH, размеры OSD, фактическая заполненность и ограничения пула. ТБ и ТиБ различаются. Снимки и тонкое выделение тоже требуют контроля: выданный виртуальный объём не означает, что физические блоки уже есть.

1. До настройки: зафиксируйте исходное состояние

Установите Proxmox с официального ISO на системные диски. Имена, статические адреса и синхронизацию времени настройте до объединения. Пример рассчитан на новые узлы без ВМ и контейнеров: присоединение к кластеру заменяет локальную конфигурацию /etc/pve.

pveversion -v
hostname -f
getent hosts pve01 pve02 pve03
ip -br address
ip route
timedatectl status
chronyc tracking
lsblk -e 7 -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE,MOUNTPOINTS

pveversion -v сохраняет версии пакетов, getent проверяет разрешение имён средствами системы, ip показывает фактические адреса и маршрут. chronyc tracking применим при установленном chrony: если используется другой NTP-клиент, проверьте его состояние. У lsblk сопоставьте серийные номера с наклейками дисков и паспортом, а не только с именами sda/sdb.

pvecm help create
pvecm help add
pveceph help install
pveceph help init
pveceph help osd create
pveceph help pool create

Справка нужна до копирования изменяющей команды. Если ключа нет или поведение отличается, остановитесь и сверьте документацию своей версии. Репозитории Proxmox и Ceph должны соответствовать выпуску ОС и условиям подписки; случайное смешение веток не является способом обновления.

2. Сеть: скорость для Ceph, стабильная задержка для Corosync

В примере Corosync использует выделенный интерфейс eno2, а резервный link1 — независимую от него сеть управления. Для Ceph выделена пара быстрых портов eno3/eno4. Сеть ВМ проектируется отдельно; одинаковые bridge/VLAN должны существовать на всех целевых узлах.

Для небольшого стенда ниже Ceph public и репликация используют одну выделенную быструю сеть. Для нагруженной площадки отдельно рассчитайте public и cluster network. Официальные рекомендации начинают с выделенных 10 Гбит/с для Ceph; SSD/NVMe и восстановление могут потребовать 25 Гбит/с и выше. Это отправная точка, а не обещание производительности.

Пример bond для pve01

Это фрагмент /etc/network/interfaces для сети хранения. Он не заменяет конфигурацию управления, Corosync и bridge. Для других узлов меняется адрес; реальные имена портов определите по ip -br link.

iface eno3 inet manual
iface eno4 inet manual

auto bond1
iface bond1 inet static
    address 10.30.30.11/24
    bond-slaves eno3 eno4
    bond-mode active-backup
    bond-miimon 100
    mtu 1500

active-backup даёт резервирование, но не складывает скорость двух портов. Порты коммутаторов должны попадать в одну подходящую L2-сеть. Два отдельных коммутатора тоже нуждаются в корректной межкоммутаторной связности. Контроль физического линка не обнаруживает все отказы выше по сети — проверьте реальное переключение, а не только выдернутый кабель.

cp -a /etc/network/interfaces /root/interfaces.before-ceph
ifreload -a
cat /proc/net/bonding/bond1
ip -s link show bond1
ping -I 10.30.30.11 -c 5 10.30.30.12

Применяйте изменения с доступной BMC/IPMI-консолью: ошибочный адрес или VLAN может оборвать SSH. Копия делается до редактирования. Для возврата через эту консоль восстановите сохранённый файл и повторите ifreload -a. Убедитесь, что вернулись управление, маршруты и связь с соседями. Не выполняйте ifdown на bridge с работающими гостями ради проверки.

Применение конфигурации и сетевые ограничения: Network Configuration.

3. Создайте кластер Proxmox и проверьте кворум

Все три узла должны заранее видеть оба адресных пространства Corosync. В этом примере link0 идёт по выделенному порту, link1 — по другой физической сети управления. Два VLAN на одном кабеле не дают независимости от обрыва этого кабеля.

pvecm create avg-hci --link0 10.20.20.11 --link1 10.10.10.11
pvecm status

pvecm add 10.10.10.11 --link0 10.20.20.12 --link1 10.10.10.12

pvecm add 10.10.10.11 --link0 10.20.20.13 --link1 10.10.10.13

Проверяйте отпечаток сертификата первого узла по доверенному каналу. В командах add первый IP — уже существующий член кластера, а значения link0/link1 — локальные адреса присоединяемого узла. Подмена их адресами первого сервера — распространённая ошибка.

pvecm status
pvecm nodes
corosync-cfgtool -s
systemctl status corosync --no-pager
journalctl -u corosync -b -n 80 --no-pager

Ожидайте три узла, корректные связи и Quorate: Yes. При обычных трёх равноправных голосах большинство — два. Это кворум Proxmox. У трёх Ceph MON есть отдельное большинство, а у пула — отдельное условие доступности данных. Успех pvecm status не доказывает исправность Ceph.

Порядок создания и присоединения: официальный Cluster Manager.

4. Установите Ceph и распределите управляющие службы

Перед установкой сверьте доступные для вашей версии ветки в мастере Ceph и справке. Команда ниже предполагает доступ к enterprise-репозиторию по действующей подписке. Если выбран другой допустимый канал, явно задайте его поддерживаемым ключом repository; не заменяйте адреса репозиториев вслепую. Для выбранной здесь Tentacle 20.2 Proxmox VE 9.2 предоставляет интеграцию; существующий Squid-кластер не обновляют этими командами как новую установку.

pveceph install --version tentacle --repository enterprise

pveceph init --network 10.30.30.0/24

Команда инициализации задаёт сеть Ceph и общую конфигурацию. Она не создаёт сетевые интерфейсы и не открывает firewall. Здесь отдельный Ceph cluster network не задан: служебный и клиентский трафик хранения используют подготовленную сеть Ceph. Не повторяйте init на каждом сервере.

pveceph mon create

После первого MON дополнительные создавайте последовательно. Первый MON в интеграции Proxmox может автоматически создать и MGR. Проверьте ceph mgr dump, затем создайте недостающие MGR на pve02 и pve03 командой pveceph mgr create. Не повторяйте её на узле, где менеджер уже есть. Если использовали GUI-мастер и он уже создал службы, сначала проверьте их состав и не дублируйте шаг. Когда готовы все узлы, выполните:

ceph versions
ceph -s
ceph quorum_status --format json-pretty
ceph mgr dump

Нужны три MON в кворуме и активный MGR с резервными. До создания OSD и пула предупреждение о незавершённой конфигурации возможно; это не повод объявлять этап приёмкой. В примере используем внутреннюю интеграцию Proxmox, поэтому не разворачиваем параллельно Ceph через другой оркестратор.

5. Создайте OSD: сначала идентификация диска

На каждом узле подготовлены четыре диска данных. Каждый выбирают по серийному номеру и устойчивому пути /dev/disk/by-id/. Проверка выполняется на том сервере, в который физически установлен диск.

ls -l /dev/disk/by-id/
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
pvs
zpool status
wipefs --no-act /dev/disk/by-id/REPLACE_WITH_DATA_DISK

pvs ищет использование LVM, zpool status — ZFS. Если утилита отсутствует, это не доказательство свободного диска. wipefs --no-act показывает обнаруженные сигнатуры и не удаляет их. Дополнительно проверьте размещение системных, загрузочных и гостевых данных. Отсутствие сигнатур само по себе не разрешает уничтожение содержимого.

pveceph osd create /dev/disk/by-id/REPLACE_WITH_DATA_DISK

Повторите для каждого из четырёх выбранных устройств на каждом сервере. Не используйте цикл по всем /dev/sd*. Если остались старые метки, остановитесь: очистка допустима после отдельной проверки владельца данных. Универсальная команда стирания здесь не нужна для нового пустого стенда.

ceph osd tree
ceph osd df tree
ceph -s

Сверьте 12 OSD, распределение по трём правильным host, состояния up и in, ёмкости и класс носителей. Не создавайте пул, пока диски неожиданно группируются под одним host или часть сервисов недоступна. Для all-flash-примера DB/WAL остаются на самих дисках OSD; отдельный общий DB-накопитель меняет домен отказа и требует своего расчёта.

6. Пул для дисков ВМ: три копии, минимум две

На новом стенде создаём replicated-пул vm-rbd и сразу добавляем его в хранилища Proxmox. Перед выполнением убедитесь, что такого пула ещё нет. Параметры должны поддерживаться справкой установленной версии.

pveceph pool create vm-rbd --size 3 --min_size 2 --add_storages
ceph osd pool set vm-rbd pg_autoscale_mode on
ceph osd pool get vm-rbd all
ceph osd pool autoscale-status
ceph osd crush rule dump
pvesm status

size=3 задаёт число копий, min_size=2 — нижнюю границу для I/O. В выводе pool get найдите используемое CRUSH-правило, затем проверьте в его описании размещение по host. Три копии на дисках одного сервера не защищают от потери этого сервера. Autoscaler управляет количеством PG; не переносите фиксированное число PG из чужого кластера.

--add_storages избавляет от повторного ручного добавления того же RBD-хранилища. Убедитесь, что запись видна и активна на всех узлах. RBD предназначен для дисков гостей: ISO и резервные копии размещайте в подходящем файловом или backup-хранилище. Для CephFS отдельно проектируются MDS и файловые пулы.

Назначение параметров: Ceph Pools и PG autoscaling.

7. Сначала миграция тестовой ВМ, затем HA

В интерфейсе Proxmox создайте небольшую ВМ с свободным ID 900, системным диском в vm-rbd и одинаково доступным bridge. Установите тестовую ОС и проверьте приложение или простой сетевой сервис. Все диски, EFI/TPM-состояние и подключённые носители должны быть доступны целевому узлу. Локальный ISO, PCI passthrough и разные модели CPU могут помешать переносу.

qm config 900
qm status 900
qm migrate 900 pve02 --online

Перед миграцией проверьте совместимость CPU; режим host на неодинаковых поколениях не гарантирует переносимость. Дождитесь завершения задачи и проверьте сам сервис, а не только статус running. Общий RBD убирает необходимость копировать его содержимое целиком, но память ВМ и состояние исполнения всё равно передаются.

ha-manager add vm:900 --state started
ha-manager config
ha-manager status

Добавление в HA задаёт желаемое состояние и может запустить остановленную ВМ. После регистрации используйте управление HA для планового переноса ресурса:

ha-manager migrate vm:900 pve03
ha-manager status

На Proxmox VE 9 учитывайте действующие правила affinity, а не слепо переносите старые примеры HA groups. Watchdog/fencing должен корректно исключать одновременно работающую старую копию ВМ. Не используйте отключение watchdog как оптимизацию времени аварийного запуска.

Что именно проверять при отказе

1. Начните со штатной миграции и проверки приложения на каждом узле.
2. На согласованном учебном стенде испытайте потерю одного узла с тестовой нагрузкой и доступной консолью управления.
3. Зафиксируйте время отказа, обнаружения, запуска ОС и готовности приложения отдельно.
4. После возврата узла дождитесь восстановления Ceph и проверьте данные. Не отключайте второй узел во время деградации.

Проверка доступности по ping измеряет сеть, но не готовность базы или 1С. Контрольная операция приложения должна записать и прочитать тестовые данные. Документация HA Manager описывает управление ресурсом; фактический RTO определяет ваша проверка.

8. Диагностика: от симптома к конкретному уровню

pvecm status
ceph -s
ceph health detail
ceph osd tree
ceph osd df tree
ceph osd perf
ceph df detail
ceph pg stat
ha-manager status

Начните с общего состояния, затем смотрите деталь. ceph osd perf помогает заметить отличающиеся OSD по задержкам, но не заменяет измерение запросов приложения. ceph osd df tree полезнее общей суммы свободного места: один переполненный OSD или ограничение правила размещения могут мешать пулу при наличии свободных дисков в другом месте.

systemctl status ceph-osd@0 --no-pager
journalctl -u ceph-osd@0 -b -n 100 --no-pager
ip -s link
free -h

Если нужны iostat, smartctl или iperf3, устанавливайте их штатно из согласованных репозиториев. Измерение iperf3 нагружает сеть; запускайте в отдельное окно, привязав к проверяемым IP. Запись fio по сырому OSD-диску разрушит данные — тестируйте специально выделенный файл или виртуальный диск в отдельной тестовой ВМ.

Смысл статусов и предупреждений: Monitoring a Cluster и Health checks.

Практические приёмы, которые экономят время

• Подпишите путь до диска. Связка «OSD → host → serial → слот» сокращает риск замены исправного устройства. Сохраните её до первого инцидента.
• Проверьте сеть в обе стороны. После замены модуля или кабеля сравните счётчики ошибок и пропускную способность; статус link up не доказывает качество канала.
• Сначала обычный MTU. Устраните ошибки базовой схемы до jumbo frames, сложного SDN и тонкого тюнинга Ceph.
• Сравнивайте задержки в одинаковых условиях. Измеряйте до recovery, во время восстановления и после. Не выдавайте один удачный тест последовательной записи за быстродействие базы.
• Не прячьте предупреждения. Зелёная панель после mute не означает устранения причины. Контролируйте и состояние, и скорость восстановления.
• Записывайте исходные параметры. Перед изменением сохраните текущее значение, цель, метрику успеха и способ возврата. Меняйте один параметр за раз.

Обслуживание, обновления и возврат

Обновление начинается с независимой проверенной копии, чтения release notes и проверки поддерживаемого пути. Версию Proxmox и ветку Ceph планируют совместно. Нельзя считать откатом простую установку старых пакетов поверх изменившегося формата данных.

1. Зафиксируйте версии, кворум, заполнение и состояние копий. Разберите предупреждения до работ.
2. Проверьте ресурсы оставшихся серверов и возможность миграции всех зависимостей нужных ВМ.
3. Согласуйте обслуживание одного узла, перенесите нагрузку штатным способом и следуйте процедуре своего выпуска.
4. После возврата узла проверьте службы, ВМ и Ceph. Дождитесь восстановления перед следующим узлом.
5. При неожиданном поведении остановите последовательность. Возврат определяется типом изменения: сеть — из сохранённой конфигурации, данные — из backup, обновление — по поддерживаемому сценарию восстановления.

Флаги обслуживания Ceph, например noout, не превращают недоступный сервер в рабочий. Если процедура требует временного флага, заранее назначьте условие его снятия и контроль после работ. Здесь нет команды «выключить все OSD» или «уменьшить кворум», которую можно случайно применить вместо регламента.

Когда кластер можно принимать в работу

Протокол приёмки должен содержать фактические результаты и время операций. Данная статья даёт методику; конкретную производительность, непрерывность и RTO вашего оборудования подтверждает испытание.

Администрирование кластера или аренда облачных ресурсов

Руководство помогает понять устройство решения. Для внедрения и дальнейшей работы можно обсудить два направления: сопровождение вашей инфраструктуры и размещение нагрузки на арендованных ресурсах.

Чтобы сравнить варианты, подготовьте перечень сервисов, текущую нагрузку, объём данных и требования к восстановлению. Облачное размещение и администрирование — отдельные составляющие: уточним, что требуется вашей компании.

Подробнее об ИТ-аутсорсинге · Обслуживание серверов

Памятки для проектирования и диагностики

Вопросы и ответы