Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    [TOTEM] Список повторной передачи ... приводит к неожиданной перезагрузке всего кластера HA.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    [TOTEM] Список повторной передачи ... приводит к неожиданной перезагрузке всего кластера HA., Proxmox Виртуальная Среда
     
    compliceit
    Guest
    #1
    0
    06.06.2025 04:01:00
    После развертывания нашего нового кластера всё шло хорошо, но у нас возникла проблема: кластер самопроизвольно перезагружался дважды за две недели, причем без каких-либо уведомлений об ошибках или ограждения проблемного узла. Все логи указывают на истечение времени ожидания сторожевого таймера (watchdog timer) в нашем трёхузловом кластере, что приводит к полной перезагрузке всех трёх узлов. Мы в замешательстве, потому что в системных логах для узлов 1–3 нет соответствующих записей. Прикрепляю логи для pve2, они практически идентичны логам для всех трёх узлов. На стороне сети не было потери соединения на портах — каждый узел подключен через LACP с двумя 10-гигабитными каналами в выделенную нетегированную VLAN. Первое сообщение о повторной передаче Corosync появилось в 10:32:18, и с этого момента всё пошло не так. К 11:23:52 проблемы усугубились, пока машина не перезагрузилась в 13:37:20. Логи подключения root от Veeam. Наш коммутатор, обрабатывающий трафик Corosync, — это коммутатор Mikrotik, я также проверил конфигурацию LACP. Прикрепляю соответствующий файл журнала. Спасибо за помощь!
     
     
     
    fabian
    Guest
    #2
    0
    11.06.2025 09:14:00
    Идеально было бы, если бы у вас было два физических интерфейса, выделенные для трафика Corosync (1G достаточно — важна в основном задержка).
     
     
     
    compliceit
    Guest
    #3
    0
    11.06.2025 09:35:00
    Ок. Потому что у каждого узла по 2x 10gb встроенных сетевых адаптеров. Но, можешь, пожалуйста, уточнить, что ты имеешь в виду, говоря о двух физических интерфейсах, выделенных для corosync? Это на узел или для всего кластера из двух узлов? Просто хочу убедиться, что я всё правильно понял.
     
     
     
    fabian
    Guest
    #4
    0
    11.06.2025 09:49:00
    https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_cluster_network там есть все подробности, включая то, как перенастроить кластер.
     
     
     
    fabian
    Guest
    #5
    0
    06.06.2025 09:49:00
    Похоже, ссылка у тебя шалит... Corosync сеть отдельная? Можешь рассказать поподробнее о конфигурации твоей сети?
     
     
     
    compliceit
    Guest
    #6
    0
    06.06.2025 15:03:00
    Да, сеть corosync отдельная, это относится ко всем 3 узлам. Скриншот с узла 2. Что мне кажется таким странным, так это то, что повторные передачи происходят на всех 3 узлах почти одновременно. И если порт "машет" (flapping), не должна ли резервная ссылка LACP взять на себя неисправную? Даже в этом случае не должно ли это привести к исключению узла из кластера (fencing) вместо срабатывания сторожевого таймера во всем кластере?
     
     
     
    fabian
    Guest
    #7
    0
    10.06.2025 08:14:00
    Использование bond как ссылки Corosync может вызвать именно эти симптомы – вы по сути накладываете отказоустойчивость и восстановление ссылки друг на друга, из-за чего процесс сходимости занимает гораздо больше времени. Это может привести к тому, что Corosync не успеет сходиться, прежде чем ссылка снова развалится. Истечение времени ожидания сторожевого таймера означает, что все узлы получают ограждение.
     
     
     
    compliceit
    Guest
    #8
    0
    10.06.2025 17:59:00
    Ну, в таком случае, посоветуешь ли ты, чтобы интерфейс Corosync был одним, не объединенным? И если это так, лучше ли просто отключить один из объединенных портов на стороне коммутатора для каждого PVE, чтобы у каждого хоста был только один активный интерфейс, или лучше переконфигурировать интерфейс в Proxmox как одиночный?
     
     
     
    VictorSTS
    Guest
    #9
    0
    11.06.2025 16:05:00
    Помни, что в кластере из 2 узлов, если один теряет кворум, другой тоже его потеряет, потому что у него не будет большинства голосов (у него будет только 1 голос, что составляет ровно 50% от 2 голосов в целом). Кластер из 2 узлов + HA вообще не обеспечит никакой избыточности/устойчивости. Как минимум, добавь QDevice [1]. [1] https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support
     
     
     
    compliceit
    Guest
    #10
    0
    11.06.2025 17:54:00
    У нас кластер из 3 узлов. Но полезно знать!
     
     
     
    compliceit
    Guest
    #11
    0
    11.06.2025 22:26:00
    Спасибо за информацию, изучу это и свяжусь с тобой, если возникнут какие-то проблемы!
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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