- Red Hat Enterprise Linux (RHEL) 5
- Red Hat Enterprise Linux (RHEL) 6
- 如何在 RHEL 上配置 kexec/kdump 服务？
- 如何分析系统崩溃和系统重启？
- 如何分析系统重启的原因？
- 如何收集系统的 vmcore？
- 如何解决在收集 vmcore 过程中遇到问题？
系统版本为 RHEL 3 和 RHEL 4 的时候，由于不支持 kdump 功能，必须使用 netdump 功能。关于如何使用 netdump
请参照 How do I configure netdump on Red Hat Enterprise Linux 3 and 4?
系统是 xen 虚拟机的时候，必须使用 xendump 功能。关于如何使用 xendump,请参照 How do I configure Xendump on Red Hat Enterprise Linux 5?
系统是 KVM 和 RHEV 虚拟机的时候，请参照 How to capture vmcore dump from a KVM guest?
注意: 对于KVM 和 RHEV 虚拟机，上面的方法是在虚拟机不响应的时候的另一种收取 vmcore 的手段，这并不是强制使用的。
- 背景 / 概述
- 前提条件
- 安装 kdump
- 添加启动参数
- 指定转储目的地
- 直接转储到磁盘
- 转储到文件系统上的一个文件
- 转储到网络存储设备 NFS
- 通过 SSH 转储到网络存储设备
- 转储到 SAN 设备 (For RHEL5)
- 转储到 SAN 设备 ( For RHEL6 with blacklist of multipath)
- 转储到 SAN 设备 ( For RHEL6 with multipath device)
- 转储目的地的大小
- 指定页过滤和压缩
- 集群系统
- 测试
- kdump被触发的条件
- 评论
背景 / 概述
利用了 fastboot 机制，使得系统可以在已经运行内核的上下文中，在不通过 BIOS 的情况下，重新启动另一个内核。因为在正常启动过程中，BIOS 的硬件检查很耗时间(尤其是对于有很多硬件外设的大型服务器)， 可以为开发人员节省很多重启系统的时间。使用 kexec 来重启系统进入普通内核是可以实现的，不过，这并不是这篇文章所要讲的内容，请参考 kexec(1) 的 man 手册来获取更多信息。
第一个内核需要预留一些内存来保证第二个内核成功启动。请注意，这部分预留的内存是无法给第一个内核使用的，这也同时改变了 RHEL 所需要的最小内存的限制。关于如何计算 RHEL 使用的最小内存限制，请参照Red Hat Enterprise Linux 6 technology capabilities and limit。如果预留了第二个内核所需要的内存，那么最小内存限制必须加上这一部分的大小。
使用 kdump 功能允许不经过 BIOS 的情况下，启动转储内核，因此第一个内核的上下文可以被保留。被保留的这部分上下文，也就是收取到的 vmcore 的核心内容。
为了收取 vmcore，需要执行下面的指令。
前提条件
- 如果要将 vmcore 转储到网络存储，需要通过 NFS 或者 ssh 访问外部服务器。
- 无论是转储到本地，还是远端，转储目的地的空闲空间一定要足够大，否则不会正常收取到 vmcore。详见"转储目的地大小"章节，来确定需要多大的空闲空间。
- 对于在 Xen 内核中配置kdump的情况，需要安装一个跟当前 Xen 内核版本相同的普通内核。(如果这个系统是 32 位的，并且拥有多于 4G 的内存，需要安装跟当前 Xen 内核版本相同的内核，而不是普通内核。)
- 注意，内核只需要被安装即可，你仍可以继续使用 Xen 启动，安装内核之后，无需重启。
安装 KDUMP
检查是否已经安装了 包:
如果没有安装，请用 yum 安装 kexec-tools:
在其它架构上无需安装该包。
添加启动参数
必须在 kernel 那一行加入 crashkernel 参数,用来保存 kdump 内核所使用的内存。在 i386 和 x86_64 架构下的 RHEL5上，需要更改 /etc/grub.conf 文件，将 crashkernel=128M@16M 加入 kernel 那一行。 在 i386 和 x86_64 架构下的 RHEL6上，将 crashkernel=128M 加入 kernel 那一行。
也可以保留少于 128M 的内存，但是经过测试的最小值是 64M。
关于如何在 RHEL6 上设置 crashkernel 参数，请参照知识库文章 How should the crashkernel parameter be configured for using kdump on RHEL6?
下面是 RHEL5 上包含 crashkernel 的 例子:
RHEL6 上 grub.conf 的例子:
如果使用 RHEL5 的 Xen 内核，需要将参数追加到 kernel 那一行，而不是 module 那一行，即便 module
那一行指定了 vmlinuz。
使用 Xen 内核的RHEL5 上 grub.conf 的例评论子:
指定完 crashkernel 之后，为了使系统预留 kdump 所使用的内存，必须重启系统。可以指定完 crashkernel 之后立即重启，也可以完全配置完 kdump 服务之后重启。
指定转储目的地
vmcore 存放的位置可以由 配置文件指定。你可以选择直接转储到一个磁盘，一个文件，或者通过 NFS 和 SSH 的一些网络存储设备。如果没有在 /etc/kdump.conf 文件中指定转储目的地，那么默认 vmcore 会存放在根文件系统上的/var/crash 目录下。关于我们支持哪些类型的转储目的地，请参照支持库文章What targets are supported for use with kdump?
直接转储到磁盘
通过配置 kdump.conf 文件，指定转储目的地为一个裸设备。配置方法如下：
例如:
注意： 这种设置会丢失 /dev/sda1 中之前的所有数据。
转储到文件系统上的一个文件
通过上面的设置，将会以 ext3 的类型挂载 /dev/sda1, 并转储 vmcore 文件到 /dev/sda1 下的 /var/crash 目录
请用下面的命令查看一个磁盘的 LABEL:
一个更为简便地确定如何指定转储目的地的方法是，查看 /etc/fstab 中是如何指定一个分区的(转储目的地没有必要通过/etc/fstab永久的挂载到挂载点上)。默认转储地点是 ，是 vmcore 收取的时间。转储的目录可以由 更改。例如：
将会转储 vmcore 到 而不是默认的。
转储到网络存储设备 NFS
为了转储到 NFS 端，需要在 /etc/kdump.conf 中，指定如下的一行：
例如:
这会将 vmcore 转储到 NFS 服务器的 目录下。
客户端（也就是收取 kdump 这一端）必须有访问该 NFS 共享目录的权限。
注意，NFSv4 是 RHEL6.3 之后开始支持的。RHEL-6.3 onwards
如果是用网卡绑定的方式访问网络存储设备的情况，有必要在 /etc/kdump.conf 中指定 bonding 模块。请参考下面的知识库文章kdump doesn't accept module options from ifcfg-* files
通过 SSH 转储到网络存储设备
通过 SSH 转储 vmcore 的时候，网络传输是加密的。由于这个优点，通过公网传输 vmcore 到一个网络存储的时候，ssh 是最佳的方式。
例如:
这种情况下，kdump 会通过 scp 命令以 kdump 用户的身份连接到服务器，同时复制 vmcore 到 目录下。kdump 用户需要取得该目录的写权限。并且，第一次配置 ssh 方式的 kdump 的时候，kdump 程序会尝试在目标机器上用 mktemp 命令创建一个临时目录以确保在目标目录上有写权限。如果所使用的目标机器上没有 mktemp 这个命令，那么 ssh 这种方式是不可用的，请采取其他方式收取 vmcore.
为了使以上的配置生效，请执行命令，命令的输出如下：
为了 vmcore 的正常收集，请确保转储目的地的空闲空间(本地或者远程)大于系统物理内存的大小。
转储到 SAN 设备 (For RHEL5)
取得 SAN 设备的 wwid:
通过更改 /etc/multipath.conf 文件，将这个 lun 加入到 multipath 的黑名单中。
重载 multipath 的配置
在此 lun 上创建一个分区
将分区信息读入内核
验证是否成功分区
在分区上创建一个 ext3 文件系统（也可能是 ext4）
创建一条 udev 规则
触发 udev 规则，同时避免影响到其他设备。
验证 udev 规则是否生效，查找 /dev/crashsan1 文件。
更新 /etc/fstab，加入下面的一行。
验证配置是否正确。
相应地，编辑 /etc/kdump.conf 文件。
重新启动 kdump 服务。
触发 sysrq，并测试 kdump 功能。 这个命令会使服务器崩溃，所以如果是生产环境，请选择合适的时间做测试。
当系统重启完成之后，查看 vmcore 是否存在。
这种方式是在 RHEL5 上验证过的。
转储到 SAN 设备 ( For RHEL6 with blacklist of multipath)
Note: 这只是一个 workaround，并不是 Red Hat 所支持的方法。下面的内容仅作参考。
取得 SAN 设备的 wwid:
通过更改 /etc/multipath.conf 文件，将这个 lun 加入到 multipath 的黑名单中。
重载 multipath 配置
在此 lun 上创建一个分区
将分区信息读入内核
验证是否成功分区
在分区上创建一个 ext3 文件系统（也可能是 ext4）
在不必要的 wwid 前添加 # 用于注释
重新创建 initramfs 并加入 multipath 设置。
用 UUID 的方式在 /etc/fstab 文件追加下面的行。
/etc/fstab 中追加的内容：
验证是否成功。
相应地，更改 /etc/kdump.conf 中的内容。
重启 kdump 服务，并设为开机自动启动。
触发 sysrq，并测试 kdump 功能。 这个命令会使服务器崩溃，所以如果是生产环境，请选择合适的时间做测试。
当系统重启完成之后，查看 vmcore 是否存在。
注意: 下面是系统信息.
转储到 SAN 设备 ( For RHEL6 with multipath device)
注意: 这种方式是被 Red Hat 支持的，请参考下面的内容。
检查多路径的状态
在 lun 上创建一个分区
将分区信息读入内核
验证是否创建成功
在分区上创建一个 ext3 文件系统（也可以是 ext4）
用 UUID 的方式在 /etc/fstab 文件追加下面的行。
用 blkid 命令查看磁盘的 UUID。
验证是否正确。
相应地，更改 /etc/kdump.conf 文件。
重启 kdump 服务，并设为开机自动启动。
触发 sysrq，并测试 kdump 功能。 这个命令会使服务器崩溃，所以如果是生产环境，请选择合适的时间做测试。
当系统重启完成之后，查看 vmcore 是否存在。
转储目的地的大小
vmcore 的大小是由物理内存的大小和内存的使用情况决定的。为了确保 vmcore 能被正常收集，我们需要保证磁盘有比物理内存大的空闲空间。然而,利用 core_collector 参数(请参照"Specifying Page Selection and Compression"章节)，可以压缩 vmcore,也可以过滤掉一些内存页。这应该能够节省很大部分空间，但是仍然要看内存的使用情况（混乱程度）。压缩的程度是由内存的使用情况决定的，有可能压缩率较高，也有可能较低。
确定所要预留的空间大小的最好方式是用 sysrq 功能产生一个 vmcore.通过 NFS 或者 SSH 将 vmcore 存放到指定服务器中(详见上面的 "Dumping to a Network Device" 章节)可以减少不必要得本地空间预留。
指定页过滤和压缩
系统内存很大的时候，最好在使用页过滤的同时使用压缩方式。这些可以在 中的 命令中设置。目前为止，完全支持的收集 core 的工具是 . 的参数可以通过 命令查看。 参数可以指定哪些类型的页被过滤掉。这是一种类似掩码的方式，例如：
注意: 改变文件爱你的内容以后，需要重新启动 kdump 服务 。如果稍后要重启整个系统的话,kdump 服务可以不用重启。
集群系统
在集群系统的环境下，在收集完成 vmcore 之前，节点可能被 fence 或 reboot，从而导致 vmcore 收集失败。所以在集群环境中，为了使 vmcore 正常收集，有必要为fence配置一个延迟时间。关于如何在集群环境中配置 kdump,请参照下面的知识库文章。How do I configure kdump for use with the RHEL High Availability Add-On?
测试
在经过上面的配置之后，需要重启系统。从16M开始的128M内存会被保留为 kdump 内核使用，普通内核无法利用。如果 free 命令查看到内存总大小少了 128M，那么证明 crashkernel 已经配置成功了。
内存预留完毕以后，启动 kdump 服务，并设为开机自动启动。
警告: 下面的命令会使系统崩溃。
(关于 sysrq 的详细信息，请参照 What is the SysRq facility and how do I use it?.)
上面的命令执行后,内核会 panic,然后系统重启进入 kdump 内核。当系统启动到 kdump 服务的时候，kdump 服务就会将内存信息拷贝到 配置文件所指定的地点。
KDUMP被触发的条件
有很多参数可以控制 kdump 被激活的条件。kdump 可以在下面的条件下被触发。
- 通过 NMI Watchdog 机制，检测到 System Hang 的时候。
NMI Watchdog 机制由 内核参数控制。详细内容请参照What is NMI and what can I use it for?。
- 当硬件 NMI 按钮被按下的时候。
这个触发条件由 sysctl 的 参数指定。
- 当发生了一个不可回收的 NMI 的时候。
这个触发条件由 sysctl 的 参数指定。下面是有关不可回收的 NMI 的内核警告信息：
- OOM-killer 也会触发内核 panic, 从而触发 kdump。
这个触发条件由 sysctl 的 参数指定。
Console 上的 frame-buffers 和 X 不能被正常支持。 所以当系统在内核参数中加入类似参数或者运行 X 的情况下，kexec 将 kdump 内核启动的时候，在 Console 上会出现乱码。但是kdump 内核仍然可以正常收取 vmcore，并且在收取完成之后，frame-buffers 和 X 仍然能够正常使用。
在 RHEL6.3 之后的版本中，/etc/kdump.conf 文件可以配置 debug_mem_level 参数。设置这个参数后，启动 kdump 内核时，会在 console 上打印出一些 free/used 的内存使用信息。更高的 level 意味着更详细的信息。
如果触发 kdump 之后，无法收取 vmcore ，但是能够正常重启，请参照下面的文章。checking the system's RAM。
- 如果使用本地磁盘作为转储 vmcore 的目的地，并且本地磁盘的类型为 hpsa, 那么收集 vmcore 的时候，会遇到一些困难。在这种
情况下，请保证系统上的 kexec-tools 包是最新版本。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/1679.html