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

Последнее обновление Proxmox Community Edition 8.3.5 сломало Corosync., Proxmox Виртуальная Среда

lix

Guest

04.04.2025 22:30:00

У меня Proxmox 8.3.5. После последней обновы постоянно (каждые 2-5 секунд) получаю следующее сообщение для всех узлов кластера: Apr 04 22:17:04 prx-01 corosync[1488]: [KNET ] udp: Received packet on ifindex 1664013570 when expected ifindex 3 Apr 04 22:17:04 prx-01 corosync[1488]: [KNET ] udp: Received packet on ifindex 1664013570 when expected ifindex 3 Apr 04 22:17:04 prx-01 corosync[1488]: [KNET ] udp: Received packet on ifindex -714920235 when expected ifindex 3 Apr 04 22:17:03 prx-01 corosync[1488]: [KNET ] udp: Received packet on ifindex 1664013570 when expected ifindex 3 Apr 04 22:17:03 prx-01 corosync[1488]: [KNET ] udp: Received packet on ifindex 1664013570 when expected ifindex 3 Кластер Proxmox состоит из 4 узлов. Версия Corosync - corosync/stable,now 3.1.9-pve1 amd64 [установлено,автоматически] демоны и утилиты кластерного движка. Как это решить или отладить и устранить? Не могли бы вы помочь?

UdoB

Guest

05.04.2025 10:01:00

Ноль шаг: перезапустите corosync на всех узлах по одному: systemctl restart corosync.service ; systemctl status corosync.service Шаг один: убедитесь, что все кольца действительно включены и подключены, примерно так: Код: ~# corosync-cfgtool -n
Local node ID 3, transport knet
nodeid: 2 reachable
LINK: 0 udp (10.3.16.6->10.3.16.9) enabled connected mtu: 1397
LINK: 1 udp (10.11.16.6->10.11.16.9) enabled connected mtu: 1397

nodeid: 4 reachable
LINK: 0 udp (10.3.16.6->10.3.16.10) enabled connected mtu: 1397
LINK: 1 udp (10.11.16.6->10.11.16.10) enabled connected mtu: 1397

nodeid: 6 reachable
LINK: 0 udp (10.3.16.6->10.3.16.7) enabled connected mtu: 1397
LINK: 1 udp (10.11.16.6->10.11.16.7) enabled connected mtu: 1397
... Оговорка: просто случайные мысли...

ebenoit

Guest

05.04.2025 13:34:00

У меня похожая проблема. Ошибка немного отличается, но вызвана тем же куском кода — функцией check_dst_addr_is_valid в libknet/transport_udp.c из пакета kronosnet. Этот код был добавлен в kronosnet в прошлом году и только несколько дней назад попал в Proxmox. У меня 5-узловая кластеризация с некоторой мешевой сетью между узлами, что и вызывает предупреждение (как говорится в комментарии к функции, это действительно "странная маршрутизация"...). Пока что единственное решение, которое я нашёл, — это установить минимальный уровень логирования для corosync до error (syslog_priority: error в разделе логирования), но мне это не особо нравится. А если не сделать этого, то все узлы без остановки генерируют предупреждения, заполняя файловую систему журнала и перегружая индекс моего Graylog'а.

fabian Guest	#4 0 07.04.2025 11:58:00 Не могли бы вы описать вашу сетевую конфигурацию/маршрутизацию более подробно? Спасибо!

ebenoit

Guest

07.04.2025 12:38:00

У меня на каждом узле 6 физических сетевых интерфейсов. Два из них настроены с использованием Linux bonding, затем подключены к мостовому интерфейсу, поддерживающему VLAN, к которому подключены ВМ, и к другому мостовому интерфейсу, не поддерживающему VLAN, через который хосты имеют сетевой доступ. Это "фронт" сеть. Остальные интерфейсы используются для прямого подключения каждого узла друг к другу. Сетевой интерфейс dummy0 имеет адрес узла в этой "бэк" сети. FRR настроен для OSPFv3 с точечно-точечными соединениями через эти интерфейсы, позволяя другому узлу маршрутизировать между двумя пирами, если прямая связь каким-то образом недоступна. Если все 4 интерфейса на узле недоступны, маршрутизация будет происходить через "фронт" сеть. Эта сеть используется для Ceph и миграции ВМ. Corosync настроен с двумя кольцами. ring0 проходит через бэк сеть, а ring1 – через фронт сеть. В моем случае проблема вызвана тем, что kronosnet ожидает пакеты, поступающие с сетевого интерфейса dummy0, хотя на самом деле они поступают с одного из 4 бэк интерфейсов (и могли бы поступать с фронтового моста, если бэк сеть недоступна).

MeSU

Guest

07.04.2025 13:53:00

Всем привет,

У нас возникла та же проблема сегодня утром после обновления до версии 1.30-pve1 libknet1 и 3.1.9-pve1 corosync, libvotequorum8, libquorum5, libcmap4, libcfg7, libcpg4 и libcorosync-common4. (Возможно, проблема только в libknet1, но поскольку обновление установило все эти пакеты вместе, я перечислил их все). Понижение версий пакетов решило проблему:

```
apt-get install libknet=1.28-pve1 corosync=3.1.7-pve3 libcfg7=3.1.7-pve3 libcmap4=3.1.7-pve3 libcorosync-common4=3.1.7-pve3 libcpg4=3.1.7-pve3 libquorum5=3.1.7-pve3 libvotequorum8=3.1.7-pve3
```

Как заметил ebenoit, проблема, похоже, заключается в том, что libknet теперь проверяет происхождение пакетов и делает это, связывая IP-адрес с одним сетевым интерфейсом. Это выглядит неправильно, так как в mesh-сети IP-адрес общий (см. конфигурацию интерфейсов ниже). У нас трехузловый кластер с mesh-сетью. Сообщения об ошибках появлялись для обоих колец, несмотря на то, что corosync-cfgtool сообщал, что всё в порядке.

Вот пример (изменен для сохранения конфиденциальности) файла /etc/network/interfaces нашего node1 для одного из колец:

```
auto eno399np0
iface eno399np0 inet static
address 10.1.1.1/24
up ip route add 10.1.1.2/32 dev eno399np0
down ip route del 10.1.1.2/32
# MESH Corosync node1 <-> node2

auto eno409np1
iface eno409np1 inet static
address 10.1.1.1/24
up ip route add 10.1.1.3/32 dev eno409np1
down ip route del 10.1.1.3/32
# MESH Corosync node1 <-> node3
```

С уважением

deac

Guest

07.04.2025 20:43:00

Похоже, кто-то подумал, что если IP-адрес находится на интерфейсе, то все пакеты, адресованные на этот IP-адрес, должны проходить через этот интерфейс, и это реализовал в knet. Но это не так и не очень распространено в реальных условиях. Это только моя догадка, возможно, я не прав, но это могло бы иметь смысл на наших машинах:

Код: [KNET ] udp: Получен пакет с 2a01:1234::12 на 2a01:1234::13 на интерфейсе enp123s0f1, когда ожидалось lo.

IP-адрес 2a01:1234::13 находится на loopback интерфейсе lo:

Код: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 10.0.0.13/32 scope global lo
valid_lft forever preferred_lft forever
inet6 2a01:1234::13/128 scope global
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever

На других интерфейсах у нас нет не-линк-локальных IP-адресов:

Код: 5: enp123s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9216 qdisc mq state UP group default qlen 1000
link/ether xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet6 fe80::xx:xx:xx:xx/64 scope link
valid_lft forever preferred_lft forever

fabian Guest	#8 0 08.04.2025 08:11:00 Мы пока откатили изменения в Kronosnet и реализуем способ либо отключить проверку, либо снизить её уровень логирования.

hevisko Guest	#9 0 11.06.2025 15:49:00 Спасибо! Похоже, это исправлено как минимум в 8.4.1.

Читают тему

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