Comments 21
Буквально сегодня общались с коллегой на тему использования kdump для отладки OpenVZ ядер :)

Как первый уровень обороны, для тех, кому kdump сложен либо не нужен, могу предложить netconsole (в CentOS искаропки, в Debian/Ubuntu — github). Netconsole умеет слать сообщения от ядра на удаленный хост и при падении намного проще понять, что произошло с ядром до часа X.
Ну kdump и так используется для отладки этих ядер, разве нет? ))) Если не само поторошение дампа «на месте» через gdb, то вычитывание стектрейса точно имеет место быть )
Брр, я честно говоря не понял что Вы имели в виду. В 99% конфигураций машин как netconsole, так и kdump отключены и если машина упала, приходится их включать/ждать повторного падения.

Да, когда машина падает повторно изымается kdump (хотя для более-менее простых багов достаточно стектрейса из netconsole) и анализируется разработчиками.

Ну стектрейс из нетконсоли не всегда бывает достаточно информативен ) и далеко не всегда он есть, даже при правильной ее настройке. В этих случаях kdump решает, но если позволяет версия дистрибутива. Просто эти два инструмента взаимно дополняют друг-друга и если есть возможность использовать kdump, то почему это не делать? ) К тому же разработчики и саппорт OpenVZ очень любят, когда он есть )
Ну мы используем оба, где это возможно. Но kdump есть только в CentOS 6, например, в 5ке его нету, тоже самое касается других дистрибутивовов на не особо новых ядрах.
Неплохой первый ход. Рекомендую ловить подобные ошибки в хост-системе и отправлять клиенту по почте или в виде SMS, как это сделано у нас :)
Это сработает лишь в случае KVM, но не OpenVZ :)

Хотя от чего падать KVM виртуалкам, которые работают в тепличных условиях, без железа (точнее с четко изветным списком виртуальных устройств)? Если не падали стораджи и клиент не занимается отладкой ядра — имхо, не особо полезная вещь.
За OpenVZ, равно как за HyperV и Vmware, ничего не отвечу :)
Ну а падать — например от OOM-событий.
Ядро не паникует от OOM событий. Просто выходит из строя все ПО на сервере, но OOM не убивает ядро. Полагаю, потенциально, это возможно, если ядро не сможет выделить какой-то свой буфер, но в подавляющем числе случаев падать будет лишь юзерспейс.

И как раз в этом случае netconsole поможет — будут видны ошибки OOM, а kdump не среагирует, никак.
Я писал не про панику ядра, а про причины падения виртуалок, о которых, изначально, и был ваш вопрос. И тут, как вы правильно отметили, рулит netconsole. Именно ей мы, кстати, и мониторим.

А что касается kernel panic'ов, то у нас на KVM виртуалках пользователи получали их на RT ядрах или, например, при использовании zswap.

В общем, что хочу сказать — если говорить об отладке сообщений и падений ядра, то, с точки зрения хостера, правильнее для начала научиться ловить и уведомлять об оомах, упсах и багах, и уже потом думать про паники.

По той простой причине, что в реальной жизни их количество соотносится в пропорции 100 к 1. И это действительно лучше делать нетконсолью.
Паникует. Как только init сносится, ядро паникует. А в виртуальной среде странности с выделением памяти куда более серьёзная проблема, чем на железе, особенно, когда граница памяти двигается.
От того же, от чего падают ядра на обычном железе. Дедлоки, ошибки обращения к памяти, нарушение целостности GTP и т.д.

Один nfs-север может доставить много весёлых моментов.
По моей практике на обычном железе в 99% случаев ядра падают от проблем железа (память, жесткие диски, сетевые карты) либо драйверов (виснущие рейд контроллеры, виснущие драйверы сетевых карт).

А в виртуальном окружении, если не таскать за собой нестабильные ядра, а брать стоковые CentOS 6/Debian 7/Ubuntu14.04 по нашей практике ничего никогда не падает, если, конечно, с физической нодой все ок и не отваливается СХД.

Ну и да, автор подтвердил, что netconsole рулез под эту задачу :)
Везёт. Потому что на моей практике большая часть странных проблем с ядром сводилась к проблемам в ядре.

Отказы железа, кстати, на приличном железе часто нефатальные (те же ошибки памяти — warning'и — не более, из-за ECC).

А стабильные ядра ровно так же ловят всякую неведомую херню. Потому что если бы в стабильных ядрах всё было хорошо, то у нас было бы 3.2-1, а не 3.2-64.
учитывая картинку к прошлой записи, нынешней картинкой нам как бы намекают что апдейтить ядро без перезагрузки можно, только если вы хотите научится пользоваться kdump и crash
Да, факапы при апгрейде без ребута вполне возможны :) Но на самом деле это не совсем верно назвать апгрейдом, оно же не обновляется. Просто латаются уязвимости.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.