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

Proxmox: после завершения живой миграции сеть не работает, Proxmox Виртуальная Среда

Mitterhuemer

Guest

16.07.2018 01:38:00

Привет, немецкая почта на форуме Hetzner: https://forum.hetzner.com/thread/25240-vswitch-proxmox-live-migration-kein-netzwerk-nach-abschluss/.

У меня есть 2 выделенных сервера Hetzner — один в Хельсинки, другой в Фалькенштейне. У меня есть публичный IP /29 подсеть на vlan4000 вместе. (всем ВМ нужно выставить MTU 1400). Первый доступный IP из подсети — это шлюз Hetzner. Я пробросил vlan4000 (vmbr4000) и добавил этот интерфейс к ВМ.

Код:
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp0s31f6
iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
address PUBLIC IP OF SERVER
netmask NETMASK OF SERVER
gateway HETZNER GW
bridge-ports enp0s31f6
bridge-fd 0
bridge_hello 2
bridge_maxage 12
bridge_stp off

iface vmbr0 inet6 static
address PUBLIC IP OF SERVER
netmask 64
gateway fe80::1

auto vmbr4000
iface vmbr4000 inet manual
bridge-ports enp0s31f6.4000
bridge-fd 0
mtu 1400
bridge_hello 2
bridge_maxage 12
bridge_stp off
#Public

auto vmbr4001
iface vmbr4001 inet static
address 10.100.30.10
netmask 255.255.255.0
bridge-ports enp0s31f6.4001
bridge-fd 0
mtu 1400
bridge_hello 2
bridge_maxage 12
bridge_stp off
#Cluster

Всё работает. Все ВМ доступны по публичному IP из подсети. Но когда я делаю live migration с сервера A на сервер B, сеть мигрированной ВМ после завершения миграции перестаёт работать. Иногда, через 20–30 минут после миграции сеть возвращается. Я пробовал: ip -s -s neigh flush all, но не помогло. Настройки proxy_arp тоже не решили проблему.

Hetzner спросил, посылает ли Proxmox Gratuitous ARP после миграции? Я включил эту опцию в ядре:
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.vmbr0.arp_ignore = 1
net.ipv4.conf.vmbr0.arp_announce = 2
net.ipv4.conf.vmbr0.arp_accept = 1
net.ipv4.conf.default.arp_accept = 1
net.ipv4.conf.all.arp_accept = 1
net.ipv4.conf.vmbr0.arp_notify = 1
net.ipv4.conf.default.arp_notify = 1
net.ipv4.conf.all.arp_notify = 1

Но live migration с Фалькенштейна в Хельсинки всё равно не работает (миграция проходит, но у ВМ больше нет интернета). При этом странно, что live migration с Хельсинки в Фалькенштейн работает всегда и сеть доступна сразу.

Я пробовал миграцию как с обычной сетью, так и с openvswitch — разницы нет. При использовании openvswitch команда arp -a показывает MAC-адреса всех ВМ и их IP (видно на всех нодах).

Но дальше у меня совсем нет идей, как это решить. Может, кто-то из сообщества Hetzner и пользователи смогут помочь? Нас много с такой же проблемой, и решения до сих пор нет.

spirit

Guest

13.12.2019 10:00:00

Привет, я всё ещё работаю над bgp-evpn sdn для Proxmox (наверстка для версии 6.2), думаю, это могло бы помочь с этой проблемой. (Он заменит hertzner vswitch и будет выполнять маршрутизацию между узлами Proxmox с anycast VM шлюзом, то есть с повторяющимся IP на vmbr разных узлов Proxmox.) Постараюсь раздобыть сервера hertzner и ovh для тестов.

G-Tony

Guest

13.01.2019 21:41:00

Привет! Ты разобрался с этой проблемой? У меня точно такая же ситуация, и несмотря на все мои попытки и поиски по форумам, ничего не работает как надо. Такое ощущение, что vSwitch цепляется за MAC-адрес старого Hypervisor, и что я ни делал, обновить его не получается (даже вручную через команды Gratuitous ARP — хотя gateway vSwitch отвечает). Трафик не проходит, но если вернуть ВМ в другой датацентр, всё работает нормально. Есть идеи?

---
Кстати, я точно знаю, что vSwitch пропускает трафик, потому что у меня есть другая ВМ (тестовая) в другом датацентре, которая перемещается между тремя датацентрами и продолжает (внутренне) пинговать ВМ на vSwitch, независимо от их местоположения. Проблема именно в том, чтобы трафик дошёл до шлюза vSwitch и обратно.

spirit

Guest

14.01.2019 07:45:00

Привет! Сейчас работаю над добавлением vxlan / bgp-evpn в Proxmox, будет готово в ближайшие несколько месяцев. (что-то вроде VMware NSX) Это позволит использовать anycast gateway на Proxmox (один и тот же IP-шлюз для виртуалки на каждом Proxmox), а потом маршрутизация заработает. (даже между несколькими датацентрами) Я начал писать документацию: https://git.proxmox.com/?p=pve-docs...5;hb=9f400be21b58701daefd8083e441f2c6c8f9ab39 Сейчас довожу до ума интеграцию в GUI и код Proxmox, чтобы настройка была максимально простой.

G-Tony

Guest

14.01.2019 09:07:00

Привет, spirit! Звучит как интересная штука, и, возможно, я в итоге тоже этим займусь — когда закончу то, что сейчас делаю. Но сейчас у меня совсем нет времени, нужно разобраться с проблемой, что у меня сейчас. По словам Hetzner, всё должно работать нормально, но я начинаю сомневаться, не пропущена ли какая-то настройка у них (на их vSwitch) или у меня. На самом деле, это должна быть простая конфигурация. Всё работает — просто не всегда, и иногда приходится ждать очень долго: минуты, часы, а то и дни, пока ARP обновится на стороне vSwitch, то есть укажет на правильный Hypervisor/Proxmox хост в vSwitch/vlan.

Возможно, я неправильно настроил сеть или гостевую машину, и узел Proxmox, на котором система сейчас находится (или куда она перемещается), не может отправить запрос на обновление ARP, потому что не знает IP (хотя у меня установлены Guest tools и я вижу это в интерфейсе). Либо vSwitch просто игнорирует этот запрос на обновление с узла.

Есть идеи, как я могу посмотреть трафик vlan, чтобы проверить, действительно ли Proxmox отправляет "Gratuitous ARP"? (Или это должны делать сами гости?). Или, может, эту функцию надо сначала включить и как это сделать?

Ещё важный момент: я не делаю горячую миграцию гостей, сначала выключаю их, потом мигрирую офлайн; в данный момент не могу мигрировать онлайн.

spirit Guest	#6 0 14.01.2019 10:34:00 Если вы используете сетевую карту virtio-net, то да, gratuitous arp отправляется напрямую виртуальной машиной после живой миграции.

AngeLinuX

Guest

12.12.2019 18:14:00

Привет, такая же проблема с нашим кластером Hetzner Proxmox. У нас два сервера на Falkenstein FSN1 (Falkenstein) FSN1-DC1 (Node-1) FSN1-DC5 (Node-2). При живой миграции и офлайн миграции любых виртуальных машин с node-1 на node-2 и обратно происходит сбой сети. Кто-нибудь может поделиться опытом по этому вопросу? Мы общаемся с техподдержкой Hetzner, но они не дают никаких решений. Спасибо.

G-Tony

Guest

14.01.2019 11:14:00

Привет, spirit, спасибо, что ответил, я очень ценю это. Ладно, чтобы прокомментировать твой комментарий: «если используешь virtio-net nic, то да» — я использую его во всех гостевых системах. Думаю, с гостями на CentOS 7 всё нормально, и они будут отправлять это; хотя, нужно ли их как-то специально настроить для отправки? «беспричинный ARP посылается напрямую гостевой системой после live migration». Обрати внимание, я не делаю live migration, а только offline migration. Гость всё равно отправляет это после перезапуска на новом узле? (Может, в этом случае надо это принудительно запустить?)

spirit

Guest

14.01.2019 23:55:00

Гратисный ARP отправляется после живой миграции. (работает из коробки с virtio, ничего настраивать не нужно). Если вы выполняете «офлайн» миграцию, гостевая ОС виртуальной машины при загрузке должна отправить ARP-запрос, чтобы, например, найти свой шлюз. (можно использовать tcpdump -e -i vmbr.., чтобы их увидеть).

G-Tony

Guest

#10

15.01.2019 22:41:00

Привет, Spirit,

Итак, я сделал это и получил следующее — немного исправленное:

tcpdump -nnti eth0 arp or icmp and host X.X.X.211
ARP, Request who-has X.X.X.209 tell X.X.X.211, length 28
ARP, Reply X.X.X.209 is-at X:X:X:X:X:40, length 42

Гостевая система отправляет запрос при загрузке и получает ответ от IP-шлюза. Это заставило меня задуматься, и я создал клон рабочей гостевой машины и начал перемещать их между дата-центрами (Нюрнберг и Франкенштейн), при этом с места, откуда их перемещал, постоянно шел ping — начав с Фалькенштайна:

- Каждый раз, как только гость запускался в Нюрнберге, ping шел без перебоев.
- Перемещаю обратно в Фалькенштайн — никакого ping.

В какой-то момент — случайно, после переезда туда и обратно — один из гостей в Фалькенштайне начал отправлять ping, но заняло несколько минут; другой так и не начал (оба перемещались и запускались одновременно).

Я повторил эксперимент: обратно в Нюрнберг — оба сразу работают, затем обратно в Фалькенштайн — и снова ни один не работает, хотя я оставил их подолгу.

И что более интересно: в Фалькенштайне после перемещения нет ARP-ответа от IP-шлюза.

По мне, это выглядит как проблема маршрутизации или, возможно, связанная с таймингом/обновлением, то есть vSwitch в итоге отпускает контроль над источником в Нюрнберге и позволяет другому дата-центру отправлять трафик.
[Это моё предположение, но могу ошибаться.]

КСТАТИ: стоит отметить, что у меня два узла в Фалькенштайне — в разных дата-центрах, и у них одна и та же проблема: гости, перемещённые к ним, не могут обмениваться ARP-ответами между собой.

Но я точно знаю, что они могут общаться, потому что я запускал по одному гостю в каждом дата-центре (в Фалькенштайне), и они спокойно пинговали друг друга — проблема возникает именно при перемещении в другой дата-центр.

Дело в том, что если я меняю IP у гостя на другой в том же подсети — ping сразу появляется, даже между узлами, если менять по одному; но при перемещении гостя с изменённым IP проблема возвращается.

DerDanilo

Guest

#11

29.10.2019 14:06:00

Мы некоторое время нормально использовали vSwitch, но потом столкнулись с проблемами офлайн-узлов. Узлы перестали нормально общаться друг с другом, даже миграция на новый хост или дата-центр не работала. Единственное, что помогало снова всё запустить — это удалить все хосты из vSwitch и добавить их заново через Robot. Это, конечно, не вариант, потому что всё уходит в офлайн на несколько минут. Я уже отправил запрос в Hetzner, чтобы разобраться, как можно решить эту проблему, если она на их стороне. Потому что раньше всё работало нормально, и я не понимаю, что изменилось, что перестало функционировать. Без vSwitch мы бы снова вернулись к настройке с failover IP, а это требует более сложного механизма переключения. У кого-то есть свежий опыт по этой теме?

SebastianS

Guest

#12

05.11.2019 21:19:00

У нас тоже работает трехузловой кластер Proxmox VE с высокой доступностью на Hetzner. Все три узла расположены в разных дата-центрах во Фалькенштайне. Серверы связаны через VLAN с использованием функции vSwitch от Hetzner. Наши KVM-хосты подключены к интернету через кластер pfSense. Кластер pfSense настроен на удержание наших публичных IP-адресов с помощью CARP на интерфейсе WAN. Перемещение виртуальной машины с хоста 1 на 3 проходит без проблем. Ни одного потерянного пинга. А вот при перемещении той же ВМ на хост 2 пинг от ВМ к какому-то ресурсу в интернете перестает проходить, как только ВМ становится активной. Она не получает MAC-адрес для своего шлюза по умолчанию, который является CARP IP на LAN-интерфейсе файрвола. Сначала мы предполагали, что это может быть связано со вторым узлом файрвола, который работает на этом хосте. Чтобы проверить, мы перенесли второй узел файрвола на хост 2 и повторили тесты. На этот раз пинг снова пропадал при перемещении ВМ на хост 2 и моментально восстанавливался при перемещении ВМ на хост 3, где сейчас не работал ни один узел файрвола. На данный момент, с моей точки зрения, проблема связана с дата-центром, где расположен хост 2. Я еще раз проверю конфигурацию интерфейсов всех трех хостов и удостоверюсь, что они одинаковы. Иногда при переносе ВМ на хост 2 пинг возвращался после 254–300 потерянных пакетов. Это всего лишь результат двух тестов. С наилучшими пожеланиями, Себастьян.

openaspace

Guest

#13

16.11.2019 15:04:00

Привет. Я тоже пользуюсь Hetzner и хотел бы настроить такую же конфигурацию, добавив еще 2 хоста. Я запускаю несколько серверов для распределения больших файлов. Можешь объяснить, как ты настраиваешь VLAN-свитч, чтобы получить автоматическое переключение IP при сбое на Hetzner?

SebastianS

Guest

#14

14.12.2019 14:56:00

Привет, openaspace! Не уверен, что правильно понял твой вопрос. Я создал коммутатор через Hetzner Robot и заказал публичный пул IP-адресов в меню vswitch. Для подключения WAN я использую VLAN 4000. Зайди в vswitches, нажми на свой VLAN, который смотрит в публичный интернет, и там ты найдёшь четыре пункта меню: Virtual-Switch, IPs, Cancellation и Monitoring. Перейди в IPs и снизу слева выбери заказ дополнительных IP-адресов и сетей. Надеюсь, это именно тот ответ, который ты искал. С уважением, Себастьян.

SebastianS

Guest

#15

14.12.2019 15:03:00

Привет, spirit! Большое спасибо за твои усилия. К концу следующей недели у меня будет кластер для тестирования на двух серверах в Hetzner. Я готов поделиться им с тобой для проведения тестов, если хочешь. Планирую держать этот кластер до конца января 2020 года. Не уверен, подходит ли это под твой график и доступность. Просто дай знать, если это тебе чем-то поможет.

2019-12-20: Во время миграции моих текущих виртуальных машин на кластер Proxmox в Hetzner выяснилось, что я могу запускать меньше ВМ на каждый хост, так как теперь использую Ceph в Proxmox-кластере. Ранее я работал с обычным решением KVM. К сожалению, поэтому я не смогу предоставить тебе тестовый кластер, так как мне пришлось добавить машины в мой существующий кластер. Извини за это.

С наилучшими пожеланиями, Себастьян

SebastianS

Guest

#16

20.12.2019 22:09:00

Всем привет! Сегодня я перемещал виртуальную машину с одного хоста на другой — всё шло нормально. Но когда я переместил другую виртуалку, это закончилось потерей связи с виртуальным хостом. Я выполнил следующую команду в командной строке виртуалки, и пинг вернулся мгновенно: arping -c 4 -A -I <сетевой интерфейс> <IP виртуальной машины> В моём случае это была команда arping -c 4 -A -I eth0 192.168.0.100. Насколько я понимаю, это вручную вызванный Gratious ARP. Было бы здорово, если кто-то из вас сможет это проверить. Возможно, в моём случае пинг просто случайно вернулся именно в этот момент. Если у вас тоже это работает, то, похоже, иногда виртуалки не отправляют правильно gratious ARP-пакеты или же свитчи на Hetzner иногда их некорректно обрабатывают. Большое спасибо и всего наилучшего, Себастьян.

AngeLinuX

Guest

#17

23.12.2019 11:50:00

Привет, SebastianS. Мы провели тесты, о которых ты говорил, но они не сработали. Когда мы перестаем получать пинги от перенесённой ВМ сразу после завершения миграции, мы запускаем команду arping, которую ты предложил, из консоли перенесённой ВМ, но пинг всё равно недоступен. В любом случае, мы увидели с помощью tcpdump, что arping запускается автоматически из ВМ после завершения миграции, так что вручную запускать команду не нужно (по крайней мере в нашем случае). В любом случае большое спасибо за твои предложения, но у нас проблемы продолжаются. С уважением.

AngeLinuX Guest	#18 0 10.01.2020 09:36:00 Привет, есть какие-нибудь идеи по этой проблеме? Счастливого 2020-го!

spirit Guest	#19 0 13.01.2020 08:38:00 Привет, angelinux, кроме миграции, виртуальная машина может выходить в сеть при обычном запуске с обеих сторон?

AngeLinuX Guest	#20 0 13.01.2020 10:03:00 Да, но когда мы выполняли живую миграцию между серверами Proxmox, виртуальной машине требовалось как минимум 5 минут, чтобы выйти в сеть. В любом случае, я не знаю, менял ли Hetzner что-то в прошлые выходные, так как сейчас у меня проблемы с исходящим трафиком. Спасибо за вопросы. Могу провести любые тесты, если нужно. Всего доброго.

Читают тему

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