Comments 21
Буквально сегодня общались с коллегой на тему использования kdump для отладки OpenVZ ядер :)
Как первый уровень обороны, для тех, кому kdump сложен либо не нужен, могу предложить netconsole (в CentOS искаропки, в Debian/Ubuntu — github). Netconsole умеет слать сообщения от ядра на удаленный хост и при падении намного проще понять, что произошло с ядром до часа X.
Как первый уровень обороны, для тех, кому kdump сложен либо не нужен, могу предложить netconsole (в CentOS искаропки, в Debian/Ubuntu — github). Netconsole умеет слать сообщения от ядра на удаленный хост и при падении намного проще понять, что произошло с ядром до часа X.
Ну kdump и так используется для отладки этих ядер, разве нет? ))) Если не само поторошение дампа «на месте» через gdb, то вычитывание стектрейса точно имеет место быть )
Брр, я честно говоря не понял что Вы имели в виду. В 99% конфигураций машин как netconsole, так и kdump отключены и если машина упала, приходится их включать/ждать повторного падения.
Да, когда машина падает повторно изымается kdump (хотя для более-менее простых багов достаточно стектрейса из netconsole) и анализируется разработчиками.
Да, когда машина падает повторно изымается kdump (хотя для более-менее простых багов достаточно стектрейса из netconsole) и анализируется разработчиками.
Ну стектрейс из нетконсоли не всегда бывает достаточно информативен ) и далеко не всегда он есть, даже при правильной ее настройке. В этих случаях kdump решает, но если позволяет версия дистрибутива. Просто эти два инструмента взаимно дополняют друг-друга и если есть возможность использовать kdump, то почему это не делать? ) К тому же разработчики и саппорт OpenVZ очень любят, когда он есть )
Неплохой первый ход. Рекомендую ловить подобные ошибки в хост-системе и отправлять клиенту по почте или в виде SMS, как это сделано у нас :)
Это сработает лишь в случае KVM, но не OpenVZ :)
Хотя от чего падать KVM виртуалкам, которые работают в тепличных условиях, без железа (точнее с четко изветным списком виртуальных устройств)? Если не падали стораджи и клиент не занимается отладкой ядра — имхо, не особо полезная вещь.
Хотя от чего падать KVM виртуалкам, которые работают в тепличных условиях, без железа (точнее с четко изветным списком виртуальных устройств)? Если не падали стораджи и клиент не занимается отладкой ядра — имхо, не особо полезная вещь.
За OpenVZ, равно как за HyperV и Vmware, ничего не отвечу :)
Ну а падать — например от OOM-событий.
Ну а падать — например от OOM-событий.
Ядро не паникует от OOM событий. Просто выходит из строя все ПО на сервере, но OOM не убивает ядро. Полагаю, потенциально, это возможно, если ядро не сможет выделить какой-то свой буфер, но в подавляющем числе случаев падать будет лишь юзерспейс.
И как раз в этом случае netconsole поможет — будут видны ошибки OOM, а kdump не среагирует, никак.
И как раз в этом случае netconsole поможет — будут видны ошибки OOM, а kdump не среагирует, никак.
Я писал не про панику ядра, а про причины падения виртуалок, о которых, изначально, и был ваш вопрос. И тут, как вы правильно отметили, рулит netconsole. Именно ей мы, кстати, и мониторим.
А что касается kernel panic'ов, то у нас на KVM виртуалках пользователи получали их на RT ядрах или, например, при использовании zswap.
В общем, что хочу сказать — если говорить об отладке сообщений и падений ядра, то, с точки зрения хостера, правильнее для начала научиться ловить и уведомлять об оомах, упсах и багах, и уже потом думать про паники.
По той простой причине, что в реальной жизни их количество соотносится в пропорции 100 к 1. И это действительно лучше делать нетконсолью.
А что касается kernel panic'ов, то у нас на KVM виртуалках пользователи получали их на RT ядрах или, например, при использовании zswap.
В общем, что хочу сказать — если говорить об отладке сообщений и падений ядра, то, с точки зрения хостера, правильнее для начала научиться ловить и уведомлять об оомах, упсах и багах, и уже потом думать про паники.
По той простой причине, что в реальной жизни их количество соотносится в пропорции 100 к 1. И это действительно лучше делать нетконсолью.
Паникует. Как только init сносится, ядро паникует. А в виртуальной среде странности с выделением памяти куда более серьёзная проблема, чем на железе, особенно, когда граница памяти двигается.
От того же, от чего падают ядра на обычном железе. Дедлоки, ошибки обращения к памяти, нарушение целостности GTP и т.д.
Один nfs-север может доставить много весёлых моментов.
Один nfs-север может доставить много весёлых моментов.
По моей практике на обычном железе в 99% случаев ядра падают от проблем железа (память, жесткие диски, сетевые карты) либо драйверов (виснущие рейд контроллеры, виснущие драйверы сетевых карт).
А в виртуальном окружении, если не таскать за собой нестабильные ядра, а брать стоковые CentOS 6/Debian 7/Ubuntu14.04 по нашей практике ничего никогда не падает, если, конечно, с физической нодой все ок и не отваливается СХД.
Ну и да, автор подтвердил, что netconsole рулез под эту задачу :)
А в виртуальном окружении, если не таскать за собой нестабильные ядра, а брать стоковые CentOS 6/Debian 7/Ubuntu14.04 по нашей практике ничего никогда не падает, если, конечно, с физической нодой все ок и не отваливается СХД.
Ну и да, автор подтвердил, что netconsole рулез под эту задачу :)
Везёт. Потому что на моей практике большая часть странных проблем с ядром сводилась к проблемам в ядре.
Отказы железа, кстати, на приличном железе часто нефатальные (те же ошибки памяти — warning'и — не более, из-за ECC).
А стабильные ядра ровно так же ловят всякую неведомую херню. Потому что если бы в стабильных ядрах всё было хорошо, то у нас было бы 3.2-1, а не 3.2-64.
Отказы железа, кстати, на приличном железе часто нефатальные (те же ошибки памяти — warning'и — не более, из-за ECC).
А стабильные ядра ровно так же ловят всякую неведомую херню. Потому что если бы в стабильных ядрах всё было хорошо, то у нас было бы 3.2-1, а не 3.2-64.
Всегда просто в восторге от иллюстраций к вашим статьям!
UFO just landed and posted this here
Sign up to leave a comment.
Kdump — диагностика и анализ причин сбоев ядра