/и т.д./pve/corosync.conf Код: totem { .... token : 4000 это значение таймаута в миллисекундах.

Привет, тот же TOTEM снова retransmit, просто добавил window_size в cluster.conf. Есть новости?

от man corosync.conf значение по умолчанию уже 50. Код: window_size Эта константа указывает максимальное количество сообщений, которые могут быть отправлены за одну ротацию токена. Если все процессоры работают одинаково хорошо, это значение может быть большим (300), что приведет к более высокой задержке от отправки до доставки для очень больших колец. Чтобы уменьшить задержку в больших кольцах (16+), значения по умолчанию являются безопасным компромиссом. Если среди быстрых процессоров присутствует 1 или более медленных процессоров, значение window_size не должно превышать 256000 / netmtu, чтобы избежать переполнения буферов получения ядра. Пользователь уведомляется об этом отображением списка повторной передачи в журналах уведомлений. Потери данных не происходит, но производительность снижается, когда происходят эти ошибки. Значение по умолчанию — 50 сообщений. Не лучше ли отрегулировать значение токена? Может, установить на 20000? Код: token Этот тайм-аут указывает в миллисекундах, до тех пор пока не будет объявлено о потере токена после того, как токен не был получен. Это время, затраченное на обнаружение сбоя процессора в текущей конфигурации. Формирование новой конфигурации занимает около 50 миллисекунд в дополнение к этому тайм-ауту. Значение по умолчанию — 1000 миллисекунд. http://docs.openstack.org/high-availability-guide/content/_setting_up_corosync.html https://access.redhat.com/documenta...dministration/s1-creating-cluster-cli-CA.html

Спасибо, mir. Я попробую большее значение. Перезагрузка каждого узла после переноса всех KVM на другие узлы будет в порядке, да? Я боюсь, что могут возникнуть проблемы, так как некоторые узлы будут иметь разные токенные значения в течение нескольких часов, пока последний узел не будет перезагружен. Думаю, стандартные значения недостаточны, когда ты масштабируешь кластер Proxmox.

Интересно, нашел ли кто-нибудь решение этой проблемы? Мы также наблюдаем повторную передачу TOTEM, но только на джамбо-фрейм кольце из двух колец, а не на нашей публичной сети с MTU 1500.

Да, это сеть хранения, мы также наблюдаем ту же проблему на нашем производственном кластере, который настроен аналогично, хотя на другом оборудовании. Но эта тестовая лаборатория довольно «праздная», и ретрансляции происходят постоянно, оба кольца установлены на netmtu 1500, даже индивидуальный адаптер ring0 с рапортом mtu 9000: Похоже, ретрансляции видны постоянно.

О, ты спрашиваешь о конкретном чипсете... Серверы Testlab — это старые HPE DL380G5 с объединением 3x1Gbs (1 на материнской плате, 2 через дополнительную PCI). В производстве — объединение 2x10Gbs на HPE DL360 gen9.