Всем привет! Кратко: у нас на 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 подтвердить предложенное решение как приемлемое и устранить возможность регрессий, вызванных им.
доступно обновление corosync, чтобы решить большинство проблем "PVE XYZ Процесс завис ..." и зависания LRM, Proxmox Виртуальная Среда
|
27.04.2018 08:19:00
|
|
|
|
|
|
08.11.2019 12:02:00
Не мог бы ты также выложить свой /etc/corosync/corosync.conf? Если у тебя всего одна сеть, ты можешь попробовать применить настройки из следующего поста:
|
||||
|
|
|
|||
Читают тему
