+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Синхронизация публичного IP при отказоустойчивости с Proxmox HA, Proxmox Виртуальная Среда

EuroDomenii

Guest

08.02.2017 06:49:00

A) Первая проблема — момент срабатывания
A1) Мониторинг через cron, когда узел меняет статус с online на fenced. Это можно сделать с помощью get /cluster/ha/status/manager_status как с внешнего сайта, так и через скрипт на самих узлах (скрипт должен быть на всех узлах, но запускаться только если узел имеет статус мастера в кластере, чтобы избежать дублирующих запусков). Такой подход имеет преимущество в том, что все failover IP адреса перемещаются сразу. Перемещение failover IP занимает несколько минут. При 50 виртуалках первые 10 не будут иметь готовый IP, а для последних 40 публичные failover IP уже должны быть перенаправлены на новый узел.
A2) Как лучше триггерить скрипты, когда узел становится fenced? (без использования cron) Или когда VM мигрируется менеджером HA на новый узел? В описанном сценарии, если узел коротко в состоянии fenced, то не стоит сразу перемещать все IP, так как некоторые виртуалки не будут мигрированы и останутся на исходном узле.

B) Следующий шаг — перемещение IP
- Я получаю IP контейнера через get /nodes/{nodefenced}/lxc/{vmid}/config. Что если в это время контейнер уже восстановлен на следующем активном узле?
- Если бы я мог сохранить ID сервиса OVH API (выделенного сервера) в комментарии на узле Proxmox, я мог бы просто вызвать команду OVH API клиента, чтобы перенести IP на новый активный сервер (который должен быть следующий в порядке приоритета и онлайн в HA группе).

guletz

Guest

29.05.2017 18:58:00

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

- Допустим, сейчас у тебя есть x1 ВМ на узле n1, x2 ВМ на n2 и так далее.
- Если n1 падает, тебе НУЖНО переместить x1 (возможно, меньше) на узел n7 (или любой другой, какой ты захочешь).
- Но поскольку x1 велико, время на восстановление всех этих ВМ на n7 будет очень долгим... не так уж и весело.

Давай сделаем так:

- Запусти одинаковые ВМ на 2 разных узлах, равномерно распределенных по остальной части кластера proxmox. Например, ВМ1 на n1 и на n2, ВМ2 на n2 и так далее (или все ВМ на n4, если хочешь — зависит от твоей инфраструктуры, ты сам решишь, что лучше).
- Для каждой ВМ на n1 у тебя будет две одинаковые ВМ: одна на n1, вторая — на другом узле.
- Перед клиентами поставь haproxy для каждой пары ВМ, используя соответствующие tcp порты. haproxy будет слушать клиентов и направлять трафик в режиме отказоустойчивости: если активный узел n1 в сети, трафик идет туда, а резервная ВМ, например на n7, — для подстраховки.
- Когда n1 упадет на время больше t1 (скажем, 10 секунд или заданный таймаут), все клиенты, которые шли на n1, автоматически переключатся на резервную ВМ.
- Возможно, ты захочешь вместо fail-over использовать балансировку нагрузки (load-balancing) через haproxy — в таком случае, если n1 или n7 упадут, пострадает только 50% клиентов.

Я опустил много деталей, чтобы донести основную идею — гораздо удобнее иметь отказоустойчивость и балансировку на tcp-уровне (через haproxy, который просто перенаправляет трафик клиентам), чем перемещать большое количество ВМ на другой узел.

Извини за мой очень плохой английский, но могу объяснить на твоем родном языке (ro).

EuroDomenii

Guest

30.05.2017 05:25:00

Я заметил, что вы недавно зарегистрировались на форуме Proxmox (полтора месяца назад) и уже довольно активно там общаетесь. Это напоминает мне тот энтузиазм, который я испытывал, когда открыл для себя этот замечательный софт прошлой осенью. Я не ветеран, но позвольте немного мягко напомнить вам пару моментов, касающихся Proxmox HA.

Во-первых, речь не идет о восстановлении больших виртуальных машин на другом узле при простое. Конечно, это заняло бы слишком много времени, и тогда уже не было бы HA. Есть два варианта использования:

- Либо у вас общий сторедж (Ceph) как здесь: https://pve.proxmox.com/wiki/High_Availability#_requirements, и Proxmox HA просто переносит конфигурацию VM X1 с узла n1 на n7.

- Либо используется удаленное инкрементальное резервирование/отправка-прием, например https://pve.proxmox.com/wiki/PVE-zsync, с почти непрерывным бэкапом, как в сценарии https://forum.proxmox.com/threads/high-availability-without-san.11378/.

Мы используем внутреннюю адаптированную версию https://github.com/digint/btrbk с BTRFS-стореджем (см. https://forum.proxmox.com/threads/btrfs-experimental-storage-pve-4-4-13-testing-issues-patch.33896/).

Здесь тоже два кейса:

1. Клиенты с выделенным IP, для тех, кто хочет полностью кастомизируемую VM (без HAproxy, возможно, с nginx, работающим как веб-сервер напрямую). В такой ситуации моё решение не идеально, но единственное работающее. Нужно оставаться в логике fencing Proxmox HA и синхронизировать публичные IP для failover.

2. Использование HAproxy для нескольких клиентов. Ваша идея классная, HAProxy — лучший выбор для балансировки нагрузки, при этом он предоставляет бесплатные Advanced Health Checks, которые доступны только в Nginx Plus (https://thehftguy.com/2016/10/03/haproxy-vs-nginx-why-you-should-never-use-nginx-for-load-balancing/). Мы недавно экспериментировали с https://github.com/imjoey/pyhaproxy/issues/6, но были недовольны производительностью python-парсера конфигурации haproxy. Суть в том, чтобы разобрать конфиг на объекты/массивы, поиграть с ними и собрать обратно. При росте размера конфига производительность падает. Поэтому мы предпочитаем пропускать этап парсинга, храня всю конфигурацию в базе данных и отрисовывать финальный конфиг на C — самом быстром языке.

По практическим причинам предположим, что наш кейс — OVH. OVH Hybrid Cloud — круто, он соединяет выделенные серверы с облаком OVH через vrack приватную сеть. В вашем сценарии предполагается, что HAProxy уже настроен в HA (в облаке OVH), и не нужно переносить никакие публичные IP. Если ваши backend VM с выделенным IP падают, балансировка идет по приватным IP в vrack. Этот пост про перенос PUBLIC failover IP. Но раз уж вы затронули тему, стоит обсудить.

Если ваша HAProxy VM не в публичном облаке OVH, а на одном из ваших узлов Proxmox-кластера, тогда вы возвращаетесь к моему исходному кейсу: при сбое нужно через API переносить PUBLIC IP с одного узла на другой.

Что касается скорости соединения между HAProxy и backend VM в Proxmox: в vrack скорость 1 Гбит/с, но если HAproxy — это тоже Proxmox VM на том же узле, LXC к LXC, iperf показывает 32.3 Гбит/с?! Кстати, кто-то считает, что 1 Гбит/с в vrack достаточно для связи HAProxy с backend?

Дальше возникают сложности с согласованием логики fencing в Proxmox и логики балансировки HAproxy, когда backend'ы не отвечают. Если у нас общий сторедж — проблем нет. Но с инкрементальным send/receive (ZFS, BTRFS) поведение nofailback в Proxmox HA нужно адаптировать для HAproxy и потом синхронизировать обратно.

В итоге для некоторых кейсов идея синхронизировать логику Proxmox HA с балансировкой HAproxy выглядит очень перспективной.

guletz Guest	#4 0 30.05.2017 11:12:00 Ucarp можно использовать на любом количестве хостов. Затем запустите haproxy на VIP-адресе ucarp (можно запускать скрипты при поднятии и опускании VIP).

corroded Guest	#5 0 29.05.2017 01:44:00 Привет, EuroDomenili, ты уже нашёл способ перенести блок IP между серверами, если один из узлов выходит из строя?

EuroDomenii Guest	#6 0 29.05.2017 01:53:00 Пока это задача низкого приоритета. Обновлю информацию, когда она снова станет актуальной.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры