Proxmox VE: Кластеризация и Высокая Доступность (HA)! (Часть 9)

Как я собрал кластер из двух серверов

Долгое время мой Proxmox жил на одном железе, и я думал, что этого достаточно. Так оно и было, пока я не попробовал обновлять гипервизор: виртуалки падали вместе с ним, и весь мой «умный дом» молчал минут десять. Именно тогда я впервые задумался о кластере. Объединение двух серверов Proxmox в одну систему даёт две главные вещи: если один узел умирает, виртуалки автоматически поднимаются на втором, а живую VM можно перетащить между серверами без выключения. Звучит как магия, но настраивается проще, чем кажется.

В этой части расскажу, как я это делал, на чём спотыкался и что важно знать до начала.

Шаг 28: что нужно до старта

Первый и главный урок: кластер начинается не с кнопки в интерфейсе, а с планирования. Я подготовил для себя короткий чек-лист:

• Два узла Proxmox VE — установленные и настроенные, с доступом по SSH между ними.
• Общее хранилище — чтобы виртуалки могли переехать на другой узел, их диски должны быть ему видны. У меня это отдельный ZFS-пул, который я отдал в сеть.
• Синхронизированные часы — кластеру без общего времени никак, я настроил NTP на обоих узлах.

Ещё один момент, который я понял не сразу: имена хостов и IP должны быть статичными и уникальными. Я прописал узлам постоянные адреса, чтобы потом не ловить странные ошибки коросика — так называется служебный механизм кластера.

Отдельно скажу про требования к железу: второй узел не обязан быть «богатым». Мне хватило старого ноутбука с парой ядер и 8 гигабайтами памяти — на нём жили запасные копии лёгких контейнеров. Главное, чтобы оба узла были доступны друг другу по сети надёжно, иначе кластер будет терять связь и нервничать. Для служебного трафика кластера я вообще завёл отдельную подсеть на втором сетевом интерфейсе: так я изолировал служебные пакеты от основного трафика и заметно успокоил систему.

Шаг 29: создаю кластер

Первым делом я создал кластер на «главном» узле. В веб-интерфейсе: Datacenter → Cluster (я работал на уровне дата-центра, а не отдельного узла), кнопка Create Cluster. Задал имя — home-pve-cluster — и указал подсеть 192.168.0.0/24. Нажал Create, и через несколько секунд кластер был создан. Приятный момент: никаких консольных команд не потребовалось, всё сделалось из браузера.

Тут важно знать: кластер автоматически тянет за собой сервисы синхронизации конфигурации между узлами. Любое изменение на одном узле мгновенно видно на другом — удобно, но и накладывает ответственность: лучше не менять настройки руками в файлах, когда кластер уже собран.

Шаг 30: присоединяю второй узел

Второй узел не «создаёт» свой кластер, а присоединяется к первому. На первом узле в разделе Cluster я открыл Join Information — там показывается строка для вставки на втором узле, что-то вроде:

pvecm add 192.168.1.10 -force_ip_version 4

На втором узле я открыл консоль по SSH и выполнил эту команду, затем ввёл пароль root первого узла. Через пару секунд в интерфейсе я увидел оба узла в списке Members со статусом online.

Здесь я наступил на грабли, о которых предупреждают на форумах: если на втором узле уже был создан свой кластер (а он создаётся автоматически при установке), присоединение откажется работать. Пришлось сначала расформировать «пустой» кластер командой pvecm delnode и стереть локальные конфиги. Пять минут копания — и всё встало на место. Проверьте заранее, чтобы не повторять мой путь.

И ещё один нюанс, который я вынес из этого вечера: делайте всё по порядку и не спешите. Сначала первый узел создаёт кластер, потом второй присоединяется — и никак иначе. Я поначалу запустил команду на первом узле и чуть не сломал себе настроение, потому что она «не сработала». А всё было просто: я не прочитал подсказку, что команду надо выполнять именно на втором узле. Внимательность здесь экономит полчаса разбирательств.

Шаг 31: живая миграция (Live Migration)

Кластер собран, теперь самое интересное — перетащить работающую виртуалку с одного узла на другой без остановки. Я выбрал тестовую VM со статусом Running, кликнул правой кнопкой → Migrate, в диалоге выбрал Target Node — второй сервер — и нажал Migrate.

VM переехала буквально на глазах: консоль не моргнула, сеть не отвалилась. У меня было ощущение, что я показываю фокус. Правда, есть нюанс: для такой миграции у VM должны стоять VirtIO-драйверы и QEMU Guest Agent, иначе гипервизор может не «договориться» с гостем. Это я усвоил ещё в третьей части курса, когда ставил агент, и теперь он окупился.

Забегая вперёд, скажу про подготовку заранее: перед первой живой миграцией я пару раз получил ошибку «недостаточно памяти на целевом узле». Оказалось, что для переезда на второй узел нужно столько же RAM, сколько у VM на исходном. То есть если виртуалка жрёт 8 гигабайт, то на целевом узле должно быть 8 гигабайт свободных. Я сначала этого не учёл, ужался в лимитах и потом долго ломал голову, почему миграция не проходит. Теперь просто держу на втором узле запас памяти под переезд.

Высокая доступность: включаю HA

Теперь главное, ради чего всё затевалось, — высокая доступность. Настраивается она за минуту: Datacenter → HA → Add, выбираю VM, жму ОК. Всё. Если узел, на котором живёт виртуалка, падает, кластер сам перезапустит её на втором узле. Я проверял это «боевым» выключением питания одного сервера — VM поднялась на другом за пару минут, и я не потерял ни одного сервиса.

Честно скажу про ограничение: HA работает только если диски VM лежат на общем хранилище. Локальный диск узла умрёт вместе с узлом. Я поэтому и поднял ZFS-пул в сеть заранее — иначе всё это было бы красивым, но бесполезным.

Что мне это дало на практике

После сборки кластера я перестал бояться плановых работ: хочу обновить один сервер — мигрирую виртуалки на второй, обновляю, возвращаю обратно. Никаких «окон обслуживания», никаких ночных дежурств. А внезапные сбои теперь решаются сами: HA делает работу за меня.

Конечно, кластер — это не «второй сервер просто так». Это второе железо, которое надо обслуживать, и второе место, где что-то может сломаться. Но для меня плюсы перевесили: спокойствие важнее пары часов возни с настройкой.

Расскажу про самый смешной случай. Я закончил настройку HA поздно вечером и решил проверить его боевое испытание — выдернул вилку из розетки одного узла. Через две минуты мои контейнеры застучали на втором, всё поднялось само. Я стоял в коридоре с вилкой в руке и чувствовал себя волшебником. Потом я вставил вилку обратно, узел вернулся в кластер, и вся инфраструктура продолжила жить как ни в чём не бывало. Именно в этот момент я окончательно понял, ради чего всё это делалось.

Если у вас только один сервер — не расстраивайтесь: весь предыдущий курс работает и на одиночном узле, а кластер можно собрать позже, когда появится второе железо. Я именно так и сделал: сначала довёл до ума один узел, а кластер собирал, когда стало по-настоящему нужно.

И ещё одна деталь, о которой я чуть не забыл: после присоединения второго узла не выключайте первый «насовсем». Кластер с одним доступным узлом теряет кворум и по умолчанию останавливает виртуалки, защищая данные от «двойного владельца». Я про это не знал и однажды удивился, почему всё встало, когда один сервер уехал на дачу. Урок: либо держите третий узел, либо — как я — просто выключайте HA-виртуалки только при плановых работах на обоих узлах.

Пара слов о разделении обязанностей

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

Кстати, о HA: не включайте его сразу для всех виртуалок. У меня был соблазн «защитить» всё подряд, но я вовремя вспомнил совет с форумов: в HA держите только то, что действительно должно быть доступно всегда. Второстепенные контейнеры лучше оставить обычными — тогда при сбое они не будут перезапускаться толпой и грузить уцелевший узел. Сначала я не послушался, включил HA для дюжины контейнеров, и после тестового сбоя второй узел захлебнулся от одновременных перезапусков. Убрал лишнее — и всё стало работать как надо.

Если вкратце

1. Подготовьте два узла, общее хранилище и синхронизацию времени — кластер без этого рассыплется.
2. Создайте кластер: Datacenter → Cluster → Create Cluster, задайте имя и подсеть.
3. Присоедините второй узел через Join Information: скопируйте команду pvecm add ... и выполните её на втором узле.
4. Проверьте Members — оба узла должны быть online.
5. Переносите VM: правая кнопка → Migrate → Target Node.
6. Включайте HA: Datacenter → HA → Add, и сервис переживёт падение узла.

Кластер — это тот уровень, после которого мой сервер перестал быть «компьютером с виртуалками» и стал настоящей маленькой инфраструктурой. Не обязательно строить его в первый же день, но знать, что такой путь существует, — полезно. А на этом наш курс выходит на финишную прямую: в последней части я собрал десять советов, которые помогли мне выжать из сервера максимум без лишних вложений.

И напоследок маленькое предостережение от собственной лени: раз уж собрали кластер — проверяйте его регулярно. Я завёл привычку раз в месяц делать тестовый переезд виртуалки и раз в пару месяцев — «виртуальное» отключение узла. Это занимает десять минут, зато когда случится настоящий сбой, вы будете знать, что всё сработает. Спокойствие стоит того, поверьте.

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

Мой опыт в двух словах: кластер — это не про «два сервера», а про то, что ваш сервис перестаёт зависеть от одной железки. Для домашнего использования это может звучать избыточно, но когда у тебя дома крутятся почта, сайт и умный дом — эта избыточность превращается в банальный сон без тревоги.