Общее представление
Kexec это механизм быстрой загрузки, который позволяет загружать ядро Linux из контекста уже запущенного ядра без передачи управления BIOS. Процедуры инициализации BIOS-а могут занимать очень много времени, особенно на больших серверах со множеством периферийных устройств. Механизм kexec позволяет сэкономить массу времени разработчикам, которые должны многократно перезагружать систему.
Kdump это новый очень надёжный механизм получения дампа памяти при крахе ядра. Дамп захватывается в контексте свежезагруженного ядра, а не в контексте сбойного ядра. Kdump использует kexec чтобы загрузить второе ядро при сбое основного ядра. Это второе ядро, которое часто называют “ядром захвата” (capture kernel), загружается в небольшой участок памяти и создаёт образ памяти основного ядра.
Первое ядро резервирует часть памяти, которая используется вторым ядром при загрузке. Учтите, что kdump резервирует значительную часть памяти при загрузке, что меняет фактические минимальные требования к оперативной памяти Red Hat Enterprise Linux 5. Чтобы рассчитать их, обратитесь к документу http://www.redhat.com/rhel/details/limits/, где указаны минимальные требования к ОЗУ и прибавьте к ним количество памяти, необходимое для kdump.
Kexec реализует загрузку ядра захвата без передачи управления BIOS-у, а значит сохраняется содержимое памяти основного ядра, что и представляет собой дамп памяти ядра при крахе.
Установка Kdump
Проверьте, что пакет kexec-tools установлен:
Если он не установлен, установите его с помощью yum:
|
|
# yum install kexec-tools |
Расположение дампа Kdump
В файле /etc/kdump.conf должно быть указано место для сохранения дампа памяти ядра при крахе. Отсутствие этого параметра ведёт к неопределённому поведению Kdump. Есть возможность сохранять дамп непосредственно на устройство, в файл, или через сеть по протоколам NFS и SSH.
Дампирование на устройство
Вы можете настроить Kdump выполнять дамп непосредственно на устройство, указав директиву raw в файле kdump.conf. Синтаксис этой директивы такой:
Например:
Пожалуйста учтите, что эта конфигурация уничтожит все данные, которые находятся на этом устройстве.
Дампирование в файл на диске
Kdump может быть настроен монтировать раздел и сохранять дамп в файл на диске. Это делается указанием типа файловой системы и раздела в файле kdump.conf. Раздел может быть задан именем устройства, меткой файловой системы или UUID, аналогично тому, как это указывается в файле /etc/fstab.
По-умолчанию, каталог в котором будет сохранятся дамп, называется /var/crash/%DATE/, где %DATE — это текущая дата на момент создания дампа. Например, конфигурация:
смонтирует /dev/sda1, как устройство с файловой системой ext3, и запишет дамп в каталог /var/crash/, тогда как
смонтирует устройство с файловой системой ext3 и меткой /boot. На большинстве инсталляций Red Hat Enterprise Linux, это будет каталог /boot. Самый простой способ узнать, какое устройство нужно указать в конфигурации — посмотреть файл /etc/fstab. Как уже говорилось, каталог по-умолчанию для сохранения дампов называется /var/crash/%DATE/. Изменить его можно с помощью директивы path в файле kdump.conf. Например:
|
|
ext3 UUID=f15759be-89d4-46c4-9e1d-1b67e5b5da82 path /usr/local/cores |
Эта конфигурация указывает, что сохранять файлы дампов нужно в каталоге /usr/local/cores/ вместо /var/crash/.
Дампирование на сетевое устройство по NFS
Чтобы настроить kdump для дампирования на том NFS, отредатируйте файл /etc/kdump.conf и добавьте в него строку в формате:
|
|
net <nfs-сервер>:/nfs/mount |
Например:
|
|
net nfs.example.com:/export/vmcores |
Эта директива указывает, что дамп памяти нужно сохранять в файл /export/vmcores/var/crash/[имя_хоста]-[дата] на сервере nfs.example.com. Система-клиент должна иметь права на запись для этого тома.
Дампирование на сетевое устройство по SSH
Преимущество SSH — шифрование передаваемого по сети трафика. По этой причине, этот метод является наилучшим в ситуации, когда дамп памяти нужно передавать через сеть с общем доступом, такую как Internet или корпоративную WAN.
|
|
net user@<ssh-сервер> |
Например:
|
|
net kdump@crash.example.com |
В этом случае, kdump будет использовать scp для подключения к серверу crash.example.com под пользователем kdump. Дамп памяти будет скопирован в каталог /var/crash/[имя_хоста]-[дата]/. Пользователь kdump должен иметь необходимые права для записи на удалённом сервере.
Чтобы активировать внесённые в настройку изменения, выполните команду service kdump propagate, которая должна выдать примерно следующий вывод:
|
|
Generating new ssh keys... done, kdump@crash.example.com's password: /root/.ssh/kdump_id_rsa.pub has been added to ~kdump/.ssh/authorized_keys2 on crash.example.com |
Задание выборки страниц и сжатие
На системах с большим объемом оперативной памяти рекомендуется не дампировать ненужные страницы памяти и сжимать остальные. Это настраивается в файле kdump.conf командой core_collector. На текущий момент единственным полностью поддерживаемым коллектором является makedumpfile. Его опции можно посмотреть командой makedumpfile --help. Опция -d указывает какие типы страниц не нужно дампировать. Параметр этой опции представляет битовую маску следующих типов:
|
|
zero pages = 1 cache pages = 2 cache private = 4 user pages = 8 free pages = 16 |
Вообще говоря, все эти страницы не содержат ценной для отладки информации. Чтобы исключить их из дампа, укажите параметр -d 31. Опция -c говорит makedumpfile сжимать остальные страницы памяти.
|
|
#core_collector makedumpfile -d 1 # throw out zero pages (containing no data) #core_collector makedumpfile -d 31 # throw out all trival pages #core_collector makedumpfile -c # compress all pages, but leave them all core_collector makedumpfile -d 31 -c # throw out trival pages and compress (recommended) |
Помните, что использование ключей -d и -c немного увеличивает время, необходимое для создания дампа памяти.
Добавление параметров загрузки
Необходимо модифицировать параметры загрузки основного ядра, чтобы зарезервировать память для ядра захвата. Для архитектур i386 и x86_64 отредактируйте файл /etc/grub.conf и добавьте crashkernel=128M@16M в конец строки с параметрами ядра.
Примечание: вы можете указать размер резервируемой памяти меньше 128M, но тестирование показало, что уже при 64M kdump может работать ненадёжно.
Пример файла /etc/grub.conf с добавленными параметрами kdump:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,0) # kernel /boot/vmlinuz-version ro root=/dev/hda1 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/boot/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Client (2.6.17-1.2519.4.21.el5) root (hd0,0) kernel /boot/vmlinuz-2.6.17-1.2519.4.21.el5 ro root=LABEL=/ rhgb quiet crashkernel=128M@16M initrd /boot/initrd-2.6.17-1.2519.4.21.el5.img |
Тестирование
После внесения указанных изменений, перезагрузите систему. 128M памяти (начиная с 16M), зарезервированные для ядра захвата, не будут использоваться основной системой. Обратите внимание, что команда free -m покажет на 128M доступной памяти меньше, чем до настройки kdump.
Теперь, когда необходимая память выделена и зарезервирована, включите скрипт автозапуска kdump и запустите сервис:
|
|
# chkconfig kdump on # service kdump start |
В результате через kexec будет загружен образ ядра, что приготовит систему к захвату дампа памяти при крахе. Чтобы это проверить, вызовите крах системы с помощью sysrq:
|
|
# echo "c" > /proc/sysrq-trigger |
Эта команда вызовет панику ядра, после чего система должна загрузить ядро kdump. Когда процесс загрузки дойдёт до момента запуска сервиса kdump, дамп памяти основного ядра будет скопирован на диск или другое место, указанное в файле /etc/kdump.conf.
Примечание: kdump не поддерживает работу консоли в режиме frame-buffers или X-ов. В системах, обычно работающих с параметром ядра вроде “vga=791” или с запущенным сервером X, изображение на консоли при загрузке ядра через kexec будет искажено. Тем не менее, это не помешает ядру kdump создать дамп памяти, а изображение восстановится после перезагрузки системы.