Proxmox репликация виртуальной машины
ProxMox, репликация VM
Всем доброго времени суток. Установил 2 узла PVE настроил репликацию, репликация прошла, но как запустить виртуалку которая находилась на выключенном узле не удалось, Узел выключался намерено, тестировался вариант выхода одного узла из строя. Пока не нашёл информации как правильно в данном случае делать репликацию. Пытался создать виртуалку и прикрутить к ней реплецированный диск и поднять таким образом, но не смог указать уже готовый диск. Правда делал это через интерфейс. Правда пока не получилось даже мигрировать машину.
Может нужно общее хранилище.
Если 2 узла PVE то не будет кворума (не запустится не одна машина), т.е. для норм работы кластера нужно 3 узла PVE. Вот тогда и репликация и HA будет работать.
Используется ZFS и задержка устраивает, и диск имеется на второй ноде, то есть репликация прошла, задержка этих 15 минут устраивают. Но как запустить машину я не понял.
Да в том то и дело что устраивает, и вроде реплика есть но как на другом узле запустить не получилось.
Две ноды вас не спасут только три.
И да, если две ноды то только миграция (имена хранилищ должны быть одинаковыми на всех нодах), если нужно HA то только три ноды при отвале одной ноды две оставшиеся соберут т.н. кворум и запустят (kvm,lxc) на одной из свободных нод.
хранилища одинаковые, то есть только три узла. посоветуйте что нить на два узла, не хочу Hyper-v использовать. От части из за того что управлять из шела не каждый сможет, а для оснастки нужна ОС соответствующая или 5nine покупать.
В качестве 3 ноды ставишь обычный пк, без хранилища, он будет арбитром. В настройках НА указываешь, что миграция виртуалки только между 2 нодами.
на 2-х узлах НА работать не будет. но руками поднять можно, как это делается написано в вики прокса.
Storage Replication
The pvesr command line tool manages the Proxmox VE storage replication framework. Storage replication brings redundancy for guests using local storage and reduces migration time.
It replicates guest volumes to another node so that all data is available without using shared storage. Replication uses snapshots to minimize traffic sent over the network. Therefore, new data is sent only incrementally after the initial full sync. In the case of a node failure, your guest data is still available on the replicated node.
The replication is done automatically in configurable intervals. The minimum replication interval is one minute, and the maximal interval once a week. The format used to specify those intervals is a subset of systemd calendar events, see Schedule Format section:
It is possible to replicate a guest to multiple target nodes, but not twice to the same target node.
Each replications bandwidth can be limited, to avoid overloading a storage or server.
Guests with replication enabled can currently only be migrated offline. Only changes since the last replication (so-called deltas ) need to be transferred if the guest is migrated to a node to which it already is replicated. This reduces the time needed significantly. The replication direction automatically switches if you migrate a guest to the replication target node.
If you migrate to a node where the guest is not replicated, the whole disk data must send over. After the migration, the replication job continues to replicate this guest to the configured nodes.
High-Availability is allowed in combination with storage replication, but there may be some data loss between the last synced time and the time a node failed.
Кластеризация в Proxmox VE
В прошлых статьях мы начали рассказывать о том, что такое Proxmox VE и как он работает. Сегодня мы расскажем о том, как можно использовать возможность кластеризации и покажем какие преимущества это дает.
Что же такое кластер и зачем он нужен? Кластер (от англ. cluster) — это группа серверов, объединенных скоростными каналами связи, работающая и представляющаяся пользователю как единое целое. Существует несколько основных сценариев использования кластера:
Раз уж мы коснулись темы распределенных вычислений, то хочется отметить, что существует еще такое понятие как грид-система (от англ. grid — решетка, сеть). Несмотря на общую схожесть, не стоит путать грид-систему и кластер. Грид не является кластером в привычном понимании. В отличие от кластера, входящие в грид узлы чаще всего разнородны и отличаются низкой доступностью. Такой подход упрощает решение задач распределенных вычислений, однако не позволяет создать из узлов единое целое.
Яркий пример грид-системы — популярная вычислительная платформа BOINC (Berkeley Open Infrastructure for Network Computing). Эта платформа изначально создавалась для проекта SETI@home (Search for Extra-Terrestrial Intelligence at Home), занимающегося проблемой поиска внеземного разума путем анализа радиосигналов.
Теперь, когда у нас есть четкое понимание того, что такое кластер, предлагаем рассмотреть каким образом его можно создать и задействовать. Будем использовать систему виртуализации с открытым исходным кодом Proxmox VE.
Особенно важно перед тем, как приступать к созданию кластера четко понимать ограничения и системные требования Proxmox, а именно:
Создание кластера
Важно! Нижеприведенная конфигурация является тестовой. Не забудьте свериться с официальной документацией Proxmox VE.
Для того, чтобы запустить тестовый кластер, мы взяли три сервера с установленным гипервизором Proxmox одинаковой конфигурации (2 ядра, 2 Гб оперативной памяти).
Если вы хотите узнать каким образом можно установить Proxmox, то рекомендуем прочитать нашу предыдущую статью — Магия виртуализации: вводный курс в Proxmox VE.
Изначально, после установки ОС, единичный сервер работает в Standalone-mode.
Создадим кластер, нажав кнопку Create Cluster в соответствующем разделе.
Задаем имя будущему кластеру и выбираем активное сетевое соединение.
Нажимаем кнопку Create. Сервер сгенерирует 2048-битный ключ и запишет его вместе с параметрами нового кластера в конфигурационные файлы.
Надпись TASK OK свидетельствует об успешном выполнении операции. Теперь, взглянув на общую информацию о системе видно, что сервер перешел в режим кластера. Пока что кластер состоит всего лишь из одной ноды, то есть пока у него нет тех возможностей, ради которых необходим кластер.
Присоединение к кластеру
Прежде чем подключаться к созданному кластеру нам необходимо получить информацию для выполнения подключения. Для этого заходим в раздел Cluster и нажимаем кнопку Join Information.
В открывшемся окне нас интересует содержимое одноименного поля. Его необходимо будет скопировать.
Здесь закодированы все необходимые параметры подключения: адрес сервера для подключения и цифровой отпечаток. Переходим на сервер, который необходимо включить в кластер. Нажимаем кнопку Join Cluster и в открывшемся окне вставляем скопированное содержимое.
Поля Peer Address и Fingerprint будут заполнены автоматически. Вводим пароль root от ноды номер 1, выбираем сетевое подключение и нажимаем кнопку Join.
В процессе присоединения к кластеру веб-страница GUI может перестать обновляться. Это нормально, просто перезагружаем страницу. Точно таким же образом добавляем еще одну ноду и в итоге получаем полноценный кластер из 3-х работающих узлов.
Теперь мы можем контролировать все узлы кластера из одного GUI.
Организация High Availability
Proxmox «из коробки» поддерживает функционал организации HA как для виртуальных машин, так и для LXC-контейнеров. Утилита ha-manager обнаруживает и отрабатывает ошибки и отказы, выполняя аварийное переключение с отказавшей ноды на рабочую. Чтобы механизм работал корректно необходимо, чтобы виртуальные машины и контейнеры имели общее файловое хранилище.
После активации функционала High Availability, программный стек ha-manager начнет непрерывно отслеживать состояние работы виртуальной машины или контейнера и асинхронно взаимодействовать с другими нодами кластера.
Присоединяем общее хранилище
Для примера мы развернули небольшое файловое хранилище NFS по адресу 192.168.88.18. Чтобы все ноды кластера могли его использовать нужно проделать следующие манипуляции.
Выбираем в меню веб-интерфейса Datacenter — Storage — Add — NFS.
Заполняем поля ID и Server. В выпадающем списке Export выбираем нужную директорию из доступных и в списке Content — необходимые типы данных. После нажатия кнопки Add хранилище будет подключено ко всем нодам кластера.
При создании виртуальных машин и контейнеров на любом из узлов указываем наш storage в качестве хранилища.
Настраиваем HA
Если это количество будет превышено, гипервизор пометит VM как сбойную и переведет в состояние Error, после чего прекратит выполнять с ней какие-либо действия.
После нажатия кнопки Add утилита ha-manager оповестит все ноды кластера о том, что теперь VM с указанным ID контролируется и в случае падения ее необходимо перезапустить на другой ноде.
Устроим сбой
Чтобы посмотреть, как именно отрабатывает механизм переключения, погасим нештатно node1 по питанию. Смотрим с другой ноды, что происходит с кластером. Видим, что система зафиксировала сбой.
Работа механизма HA не означает непрерывность работы VM. Как только нода «упала», работа VM временно останавливается до момента автоматического перезапуска на другой ноде.
И вот тут начинается «магия» — кластер автоматически переназначил ноду для выполнения нашей VM и в течение 120 секунд работа была автоматически восстановлена.
Гасим node2 по питанию. Посмотрим, выдержит ли кластер и вернется ли VM в рабочее состояние автоматически.
Увы, как видим, у нас возникла проблема с тем, что на единственной, оставшейся в живых, ноде больше нет кворума, что автоматически отключает работу HA. Даем в консоли команду принудительной установки кворума.
Спустя 2 минуты механизм HA отработал корректно и не найдя node2 запустил нашу VM на node3.
Как только мы включили обратно node1 и node2, работа кластера была полностью восстановлена. Обратите внимание, что обратно на node1 VM самостоятельно не мигрирует, но это можно сделать вручную.
Подводим итоги
Мы рассказали вам про то, как устроен механизм кластеризации в Proxmox, а также показали, как настраивается HA для виртуальных машин и контейнеров. Грамотное использование кластеризации и HA значительно повышает надежность инфраструктуры, а также обеспечивает восстановление после сбоев.
Перед тем как создавать кластер, нужно сразу планировать для каких целей он будет использоваться и насколько его потребуется масштабировать в будущем. Также нужно проверить сетевую инфраструктуру на готовность работы с минимальными задержками, чтобы будущий кластер работал без сбоев.
Расскажите нам — используете ли вы возможности кластеризации в Proxmox? Ждем вас в комментариях.
Предыдущие статьи на тему гипервизора Proxmox VE:
Настройка кластера Proxmox VE
В данной инструкции мы сначала соберем кластер Proxmox для управления всеми хостами виртуализации из единой консоли, а затем — кластер высокой доступности (HA или отказоустойчивый). В нашем примере мы будем работать с 3 серверами — pve1, pve2 и pve3.
Мы не станем уделять внимание процессу установки Proxmox VE, а также настройки сети и других функций данного гипервизора — все это можно прочитать в пошаговой инструкции Установка и настройка Proxmox VE.
Подготовка нод кластера
* в данном примере у нас в hosts занесены наши два сервера Proxmox, из которых мы будем собирать кластер.
Настройка кластера
Построение кластерной системы выполняется в 2 этапа — сначала мы создаем кластер на любой из нод, затем присоединяем к данному кластеру остальные узлы.
Создание кластера
Для создания кластера нам нужно задать его имя и, желательно, выбрать IP-адрес интерфейса, на котором узел кластера будет работать:
. кликаем Создать — процесс не должен занять много времени. В итоге, мы должны увидеть «TASK OK»:
Присоединение ноды к кластеру
На первой ноде, где создали кластер, в том же окне станет активна кнопка Данные присоединения — кликаем по ней:
В открывшемся окне копируем данные присоединения:
В поле «Данные» вставляем данные присоединения, которые мы скопировали с первой ноды — поля «Адрес сервера» и «Отпечаток заполняться автоматически». Заполняем пароль пользователя root первой ноды и кликаем Присоединение:
Присоединение также не должно занять много времени. Ждем несколько минут для завершения репликации всех настроек. Кластер готов к работе — при подключении к любой из нод мы будем подключаться к кластеру:
Готово. Данный кластер можно использовать для централизованного управления хостами Proxmox.
Посмотреть статус работы кластера можно командой в SSH:
Отказоустойчивый кластер
Настроим автоматический перезапуск виртуальных машин на рабочих нодах, если выйдет из строя сервер.
Для настройки отказоустойчивости (High Availability или HA) нам нужно:
1. Подготовка кластера
Процесс добавления 3-о узла аналогичен процессу, описанному выше — на одной из нод, уже работающей в кластере, мы копируем данные присоединения; в панели управления третьего сервера переходим к настройке кластера и присоединяем узел.
2. Добавление хранилища
Подробное описание процесса настройки самого хранилища выходит за рамки данной инструкции. В данном примере мы разберем пример и использованием СХД, подключенное по iSCSI.
Если наша СХД настроена на проверку инициаторов, на каждой ноде смотрим командой:
. IQN инициаторов. Пример ответа:
* где iqn.1993-08.org.debian:01:4640b8a1c6f — IQN, который нужно добавить в настройках СХД.
В открывшемся окне указываем настройки для подключения к хранилке:
* где ID — произвольный идентификатор для удобства; Portal — адрес, по которому iSCSI отдает диски; Target — идентификатор таргета, по которому СХД отдает нужный нам LUN.
Нажимаем добавить, немного ждем — на всех хостах кластера должно появиться хранилище с указанным идентификатором. Чтобы использовать его для хранения виртуальных машин, еще раз добавляем хранилище, только выбираем LVM:
Задаем настройки для тома LVM:
* где было настроено:
Нажимаем Добавить — мы должны увидеть новое устройство для хранения виртуальных машин.
Для продолжения настройки отказоустойчивого кластера создаем виртуальную машину на общем хранилище.
3. Настройка отказоустойчивости
Создание группы
Вносим настройки для группы и выбираем галочками участников группы:
Также мы можем задать приоритеты для серверов, если отдаем каким-то из них предпочтение.
Нажимаем OK — группа должна появиться в общем списке.
Настраиваем отказоустойчивость для виртуальной машины
В открывшемся окне выбираем виртуальную машину и группу:
. и нажимаем Добавить.
4. Проверка отказоустойчивости
После выполнения всех действий, необходимо проверить, что наша отказоустойчивость работает. Для чистоты эксперимента, можно выключиться сервер, на котором создана виртуальная машина, добавленная в HA.
Важно учесть, что перезагрузка ноды не приведет к перемещению виртуальной машины. В данном случае кластер отправляет сигнал, что он скоро будет доступен, а ресурсы, добавленные в HA останутся на своих местах.
Для выключения ноды можно ввести команду:
Ручное перемещение виртуальной машины
Представим ситуацию, что у нас произошел сбой одного из узлов кластера, но при этом виртуальная машина не переехала на рабочую ноду. Например, если сервер был отправлен в перезагрузку, но не смог корректно загрузиться. В консоли управления нет возможности мигрировать виртуалку с неработающего сервера. Поэтому нам понадобиться командная строка.
И так, открываем SSH-консоль сервера, на любой работающем сервере Proxmox. Переходим в каталог qemu-server той ноды, которая не работает:
* мы предполагаем, что у нас вышел из строя сервер pve1.
Смотрим содержимое каталога:
Мы должны увидеть конфигурационные файлы запущенных виртуальных машин, например:
* в нашем примере у нас запущена только одна виртуальная машина с идентификатором 100.
* где pve2 — имя второй ноды, на которой мы запустим виртуальный сервер.
. проверяем, что виртуальная машина появилась в системе. В противном случае, перезапускаем службы:
systemctl restart pvestatd
systemctl restart pvedaemon
systemctl restart pve-cluster
Сбрасываем состояние для HA:
* в данном примере мы сбросили состояние для виртуальной машины с идентификатором 100. Если это не сделать, то при запуске виртуалки ничего не будет происходить.
После виртуальную машину можно запустить:
Репликация виртуальных машин
Если у нас нет общего дискового хранилища, мы можем настроить репликацию виртуальных машин между нодами. В таком случае мы получим, относительно, отказоустойчивую среду — в случае сбоя, у нас будет второй сервер, на котором есть аналогичный набор виртуальных машин.
Настройка ZFS
Репликация может выполняться только на тома ZFS. Подробная работа с данной файловой системой выходит за рамки данной инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимы том.
Пул ZFS необходимо создавать из командной строки, например:
* в данном примере мы создадим пул с названием zpool1 из диска /dev/sdc.
Задаем настройки для создания хранилища из созданного ранее пула ZFS:
* в данном примере мы создаем хранилище из пула zpool1; название для хранилище задаем zfs-pool, также ставим галочку Дисковое резервирование. Остальные настройки оставляем по умолчанию.
После этого мы должны либо перенести виртуальную машину на хранилище ZFS, либо создать в нем новую машину.
Настройка репликации
Задаем настройки для репликации виртуальной машины:
* в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором 100. Репликация должна проводиться на сервер pve2.
Нажимаем Создать — теперь ждем репликации по расписанию или форсируем событие, кликнув по Запустить сейчас:
Удаление ноды из кластера
Удаление узла из рабочего кластера выполняется из командной строки. Список всех нод можно увидеть командой:
Мы увидим, примерно, следующее:
Membership information
———————-
Nodeid Votes Name
1 1 pve1 (local)
2 1 pve2
3 1 pve3
* где pve1, pve2, pve3 — узлы кластера; local указываем на ноду, с которой мы выполняем команду pvecm.
Для удаления узла, например, pve2 вводим:
pvecm delnode pve2
Ждем немного времени, пока не пройдет репликация. В консоли управления Proxmox удаленный сервер должен пропасть
Удаление кластера
Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли — все операции делаем в командной строке.
Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:
Мы получим список нод — удалим все, кроме локальной, например:
pvecm delnode pve2
pvecm delnode pve3
* в данном примере мы удалили ноды pve2 и pve3.
Необходимо подождать, минут 5, чтобы прошла репликация между нодами. После останавливаем следующие службы:
systemctl stop pvestatd pvedaemon pve-cluster corosync
Подключаемся к базе sqlite для кластера PVE:
Удаляем из таблицы tree все записи, поле name в которых равно corosync.conf:
> DELETE FROM tree WHERE name = ‘corosync.conf’;
Отключаемся от базы:
Удаляем файл блокировки:
Удаляем файлы, имеющие отношение к настройке кластера:
Запускаем ранее погашенные службы:
systemctl start pvestatd pvedaemon pve-cluster corosync