Аспро: ЛайтШоп [тема: доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM]

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Fri, 08 Nov 2019 12:02:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Не мог бы ты также выложить свой /etc/corosync/corosync.conf? Если у тебя всего одна сеть, ты можешь попробовать применить настройки из следующего поста: https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124/page-11#post-269060
08.11.2019 12:02:00, t.lamprecht.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Wed, 06 Nov 2019 15:07:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я также попробовал полностью переустановить все узлы, поскольку это не продуктивно, мы не можем делать это каждый раз. После установки я обновил каждый узел до последней версии 6.0-11, и проблема все еще присутствует на свежей установке. Изменений в corosync.conf не было сделано. Используем стандартную конфигурацию. На этот раз это произошло после добавления 10-го узла в кластер. Весь кластер завис, и каждый узел получил ошибки pvesr kernel stucks. Журнал и/или syslog показывает нам: Код: Nov 6 14:57:20 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:57:33 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:57:46 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:57:59 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:58:00 pop005-sniffer systemd[1]: Запуск репликации Proxmox VE... Nov 6 14:58:14 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:58:25 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:58:42 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:58:55 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:59:11 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:59:26 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:59:41 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 14:59:54 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:00:09 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:00:15 pop005-sniffer kernel: [725.943886] ИНФО: задача pvesr:2331 заблокирована более чем на 120 секунд. Nov 6 15:00:15 pop005-sniffer kernel: [725.943926] Поврежденный: P O 5.0.21-4-pve #1 Nov 6 15:00:15 pop005-sniffer kernel: [725.943938] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключает это сообщение. Nov 6 15:00:15 pop005-sniffer kernel: [725.943963] pvesr D 0 2331 1 0x00000000 Nov 6 15:00:15 pop005-sniffer kernel: [725.943975] Стек вызовов: Nov 6 15:00:15 pop005-sniffer kernel: [725.943987] __schedule+0x2d4/0x870 Nov 6 15:00:15 pop005-sniffer kernel: [725.943997] ? path_parentat.isra.44+0x3f/0x80 Nov 6 15:00:15 pop005-sniffer kernel: [725.944007] schedule+0x2c/0x70 Nov 6 15:00:15 pop005-sniffer kernel: [725.944015] rwsem_down_write_failed+0x160/0x340 Nov 6 15:00:15 pop005-sniffer kernel: [725.944026] call_rwsem_down_write_failed+0x17/0x30 Nov 6 15:00:15 pop005-sniffer kernel: [725.944037] down_write+0x2d/0x40 Nov 6 15:00:15 pop005-sniffer kernel: [725.944044] filename_create+0x8e/0x180 Nov 6 15:00:15 pop005-sniffer kernel: [725.944054] do_mkdirat+0x59/0x110 Nov 6 15:00:15 pop005-sniffer kernel: [725.944062] __x64_sys_mkdir+0x1b/0x20 Nov 6 15:00:15 pop005-sniffer kernel: [725.944071] do_syscall_64+0x5a/0x110 Nov 6 15:00:15 pop005-sniffer kernel: [725.944080] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 6 15:00:15 pop005-sniffer kernel: [725.944092] RIP: 0033:0x7f5586bfc0d7 Nov 6 15:00:15 pop005-sniffer kernel: [725.944103] Код: Неверное значение RIP. Nov 6 15:00:15 pop005-sniffer kernel: [725.944111] RSP: 002b:00007ffdee7869f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 Nov 6 15:00:15 pop005-sniffer kernel: [725.944126] RAX: ffffffffffffffda RBX: 00005586731d9260 RCX: 00007f5586bfc0d7 Nov 6 15:00:15 pop005-sniffer kernel: [725.944140] RDX: 000055867242c1f4 RSI: 00000000000001ff RDI: 0000558676c61590 Nov 6 15:00:15 pop005-sniffer kernel: [725.944154] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000000f Nov 6 15:00:15 pop005-sniffer kernel: [725.944168] R10: 0000000000000000 R11: 0000000000000246 R12: 00005586749182c8 Nov 6 15:00:15 pop005-sniffer kernel: [725.944182] R13: 0000558676c61590 R14: 0000558676c0fba0 R15: 00000000000001ff Nov 6 15:00:22 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 316 мс Nov 6 15:00:37 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:00:50 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:01:05 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:01:16 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:01:31 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:01:42 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:01:57 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс Nov 6 15:02:08 pop005-sniffer corosync[1738]: [TOTEM] Токен не был получен за 315 мс
06.11.2019 15:07:00, DenisKlimek_WT.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Wed, 06 Nov 2019 09:49:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Довольно интересная ситуация. Хмм, характеристики сети выглядят нормально. Хотя, признаюсь, мы никогда не тестировали это на такой топологии сети с более чем 20 коммутаторами. Есть ли какие-либо журнальные сообщения от corosync/knet или только ошибки зависших задач ядра?
06.11.2019 09:49:00, t.lamprecht.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Wed, 06 Nov 2019 09:43:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
libknet1 уже последняя версия с установленной 1.13-pve1 на всех узлах кластера. Причина, по которой я изменил транспорт с udp на tcp, заключается в том, что у нас были серьезные проблемы после добавления 7-8 узла в кластер. Каждый раз вся коммуникация кластера обрывалась. С tcp все работает стабильно через нашу L2 сеть. Это большая коммутируемая сеть с примерно 25 коммутаторами по всему городу, соединенная напрямую оптоволокном. На этом кластере не запущено никаких виртуальных машин и даже не установлено. Это совершенно новая и чистая установка Proxmox. Внутри этой сети использование канала очень низкое. Он используется только для некоторого управляющего и контролирующего трафика (< 1Mbit/s). Задержка между каждым хостом составляет < 1ms (проверено с помощью icmp ping от/до каждого узла).
06.11.2019 09:43:00, DenisKlimek_WT.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Mon, 04 Nov 2019 17:10:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я бы посоветовал убедиться, что у ваших хостов установлена libknet1 версии 1.13-pve1 (или более поздней) и попробовать использовать UDP. Эта версия включает исправления, которые могут вызывать сбои через некоторое время при высокой нагрузке. Или есть другая причина, по которой вы решили использовать SCTP? Кстати, вы перегружаете ЦП? Есть ли значительная нагрузка на систему? Что показывает: Код: head /proc/pressure/*? Кроме того, находятся ли ссылки corosync/kronosnet в сети с высокой (или более высокой) нагрузкой — дело в том, что не только трафик на верхнем пределе сети плох, это начинает становиться проблемой раньше, так как corosync чувствителен к времени (латентности). Мы сумели спокойно запустить около 25 узлов в кластере с knet и udp, где на каждом узле оставались ресурсы ЦП для corosync.
04.11.2019 17:10:00, t.lamprecht.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Mon, 04 Nov 2019 13:26:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Уважаемая команда Proxmox, нас также затрагивает эта проблема, которая всегда возникает после добавления нового узла в существующий кластер. Первые 10-12 подключений к кластеру прошли успешно, но затем каждый новый узел вызывал эту проблему. Думаю, мы сможем воспроизвести её, чтобы предоставить вам больше информации для отладки, если потребуется. Текущая система работает на Proxmox 6.0-9/508dce00 с corosync 3.0.2-pve4 (knet_transport изменён на sctp для стабильной работы corosync в нашей среде). В конце концов, мы выключили каждый узел и загрузили их по очереди, когда предыдущий узел присоединился к кластеру. Код: [421215.262783] INFO: задача pveproxy worker:4932 блокирована более 120 секунд. [421215.263610] Tainted: P O 5.0.21-3-pve #1 [421215.264348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключает это сообщение. [421215.265072] pveproxy worker D 0 4932 1048 0x00000000 [421215.265784] Стек вызовов: [421215.266481] __schedule+0x2d4/0x870 [421215.267174] schedule+0x2c/0x70 [421215.267990] rwsem_down_read_failed+0xe6/0x170 [421215.268644] call_rwsem_down_read_failed+0x18/0x30 [421215.269284] down_read+0x20/0x40 [421215.269908] lookup_slow+0x2c/0x60 [421215.270517] walk_component+0x1bf/0x330 [421215.271128] ? link_path_walk.part.43+0x29e/0x540 [421215.271814] path_lookupat.isra.47+0x6d/0x220 [421215.272385] filename_lookup.part.61+0xa0/0x170 [421215.272943] ? __check_object_size+0x16b/0x17c [421215.273487] ? strncpy_from_user+0x57/0x1c0 [421215.274017] user_path_at_empty+0x3e/0x50 [421215.274543] vfs_statx+0x76/0xe0 [421215.275081] ? _cond_resched+0x19/0x30 [421215.275720] __do_sys_newstat+0x3d/0x70 [421215.276237] ? _cond_resched+0x19/0x30 [421215.276747] ? task_work_run+0x46/0xc0 [421215.277248] __x64_sys_newstat+0x16/0x20 [421215.277746] do_syscall_64+0x5a/0x110 [421215.278231] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [421215.278719] RIP: 0033:0x7fb8d075eaa5 [421215.279292] Код: Неверное значение RIP. [421215.279737] RSP: 002b:00007ffce1b1c8b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000004 [421215.280182] RAX: ffffffffffffffda RBX: 0000561207ca5260 RCX: 00007fb8d075eaa5 [421215.280617] RDX: 0000561207ca5478 RSI: 0000561207ca5478 RDI: 0000561207e3d660 [421215.281039] RBP: 000056120e7237f0 R08: 0000000000000000 R09: 000000000000000f [421215.281449] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [421215.281845] R13: 0000561207c2c811 R14: 0000561207e3d660 R15: 0000000000000000 [421215.282231] INFO: задача pvesr:16378 блокирована более 120 секунд. [421215.282606] Tainted: P O 5.0.21-3-pve #1 [421215.282986] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключает это сообщение. [421215.283509] pvesr D 0 16378 1 0x00000000 [421215.283889] Стек вызовов: [421215.284259] __schedule+0x2d4/0x870 [421215.284626] ? path_parentat.isra.44+0x3f/0x80 [421215.284994] schedule+0x2c/0x70 [421215.285357] rwsem_down_write_failed+0x160/0x340 [421215.285721] call_rwsem_down_write_failed+0x17/0x30 [421215.286089] down_write+0x2d/0x40 [421215.286445] filename_create+0x8e/0x180 [421215.286814] do_mkdirat+0x59/0x110 [421215.287307] __x64_sys_mkdir+0x1b/0x20 [421215.287641] do_syscall_64+0x5a/0x110 [421215.287964] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [421215.288283] RIP: 0033:0x7f15368c70d7 [421215.288596] Код: Неверное значение RIP. [421215.288904] RSP: 002b:00007ffc5ff62198 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 [421215.289228] RAX: ffffffffffffffda RBX: 00005565d7c47260 RCX: 00007f15368c70d7 [421215.289556] RDX: 00005565d6d191f4 RSI: 00000000000001ff RDI: 00005565db67d140 [421215.289887] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000000f [421215.290318] R10: 0000000000000000 R11: 0000000000000246 R12: 00005565d9351078 [421215.290837] R13: 00005565db67d140 R14: 00005565db637878 R15: 00000000000001ff
04.11.2019 13:26:00, DenisKlimek_WT.

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM

Fri, 27 Apr 2018 08:19:00 +0300

доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Всем привет! Кратко: у нас на pvetest появился новый пакет corosync (и библиотеки), который включает предложенное исправление для ошибки, вызывающей (большинство) сообщений «Процесс PVE XYZ завис более чем на 120 секунд». Просьба к тем, кого это затрагивает, протестировать версию corsync 2-4-2-pve5, чтобы найти возможные проблемы с этим решением! Длинная версия: Мы получили достаточно много отчетов о том, что демоны PVE зависают в состоянии D (непрерываемое ожидание ввода-вывода), что приводит к снижению работоспособности систем. Наиболее классическим и часто сообщаемым процессом был pve-ha-lrm, но сам lrm (или другие демоны) не имели никаких проблем. Мы подозревали это с самого начала таких отчетов, но смогли убедиться, только когда наконец смогли воспроизвести проблему на наших тестовых системах, сначала случайно на тестовой системе ceph, но это дало возможность Фабиану и мне сесть вместе и найти реальный репродуктор (большое спасибо за его помощь). В принципе, проблема связана с библиотекой Closed Process Groups (CPG) corosync, которая является основой нашей распределенной файловой системы конфигураций (pmxcfs). Искусственный репродуктор можно легко настроить в виртуальном кластере (т.е. вложенные инстанции PVE) размером 3 (или больше). На здоровом кластере необходимы следующие последовательности: 1. Приостановите узел с наименьшим идентификатором узла 2. создайте/измените файл в /etc/pve на другом узле 3. Возобновите узел с наименьшим идентификатором узла 4. Попробуйте повторить шаг 2 — теперь это зависнет. (Кстати, быстрый выход — перезагрузить pve-cluster и corosync на узле 1) Шаги 1 и 3 обычно возникают из-за высокой нагрузки ввода-вывода, и это не обязательно должно длиться минуты или часы. Печально известные «плохие» секунды могут оказаться достаточными. Corosync, хотя и отмечен как реальный процесс, может не быть запланирован благодаря этому скачку, который можно сравнить с паузой/возобновлением. Почему зависание? Мы должны доверять CPG, чтобы он сообщал нам о изменениях конфигурации (т.е. члены присоединились или покинули узел). И обычно в corosync и pmxcfs более низкие идентификаторы членов означают, что они выбираются вместо более высоких идентификаторов для временных мастеров. Таким образом, в приведенном выше случае узел 1 должен был бы выйти из текущей группы процессов и присоединиться к новой (созданной другими членами) группе процессов. Это позволило бы узлу 1 зафиксировать изменение и синхронизировать обновления inode. Но, хотя оставшиеся (неприостановленные) узлы действуют корректно — они видят, как узел 1 исчезает и создают новую группу процессов с узлом 2 в качестве мастера, узел 1 не получает сообщение о выходе или вступлении и думает «эй, ничего не произошло» и считает, что он все еще мастер. Это работало до тех пор, пока ничего не менялось, но затем семафор, вышедший из синхронизации, блокировался на каждый будущий запрос к файловой системе. (сжатое техническое объяснение) Мы смогли сократить это до более простого тестового случая без pmxcfs и сообщили о нем в corosync upstream, который подтвердил, что мы нашли «довольно серьезную ошибку». Проблема с безопасностью, о которой сообщили примерно в то же время, была, безусловно, признана более важной, и поэтому мы получили предложенное исправление всего несколько дней назад. Это исправление упаковано и находится в нашем тестовом репозитории (pvetest) с corosync (и автоматически подтянутыми зависимостями) в версии 2.4.2-pve5 (обычно требуется только libcpg4, но лучше обновить все). Примечание: естественно, «процесс xyz завис дольше чем» и состояние D все еще могут возникать, это просто была симптоматика, которая может быть вызвана многими факторами (например, неисправным оборудованием, ошибками в ядре и т.д.). Это затрагивает только демоны и инструменты, работающие в /etc/pve, которые в основном являются нашими собственными демонами PVE. Если мы получим какие-то тесты, это действительно поможет нам и upstream подтвердить предложенное решение как приемлемое и устранить возможность регрессий, вызванных им.
27.04.2018 08:19:00, t.lamprecht.