在红帽企业 Linux 中配置内核转储的重要性

如果您曾担任过系统管理员，那么在系统崩溃导致生产中断后，您可能会面临巨大的压力。在这种情况下，首要目标是尽快让生产系统重新启动并运行。但是，一旦一切恢复并正常运行，您必须将重点转到根本原因分析（RCA）上。您必须了解问题发生的原因，才能防止问题再次发生。

Linux 内核是红帽企业 Linux（RHEL）的核心，负责处理使 RHEL 能够在系统上运行的所有低级细节。当内核检测到不可恢复的错误时，内核会出现混乱，从而导致系统崩溃。这些类型的内核崩溃可能由多种因素引起，包括硬件问题、第三方内核模块的问题、内核中的错误等。

RHEL 包含 kdump 服务。内核崩溃时，kdump 可以启动到辅助内核，以便将系统内存转储写出到文件。可以分析此内核转储文件，并使用它来帮助确定内核崩溃的根本原因。如果没有内核转储文件，通常无法确定根本原因。

在生产环境中，务必要定期验证 kdump 是否已正确配置并正常工作（在内核崩溃之前）。

用于启用 kdump 的选项

启用 kdump 的方法有很多，包括：

• RHEL 安装程序最初构建系统时
• 使用命令行手动
• 红帽客户门户实验室中的 kdump 帮助程序
• RHEL Web 控制台
• RHEL kdump 系统角色

在本文中，我将演示如何使用 RHEL kdump 系统角色来配置 RHEL 系统以进行内核转储，然后演示如何使用 RHEL Web 控制台来验证 kdump 是否正常工作。

使用 RHEL kdump 系统角色

有关如何开始使用 RHEL 系统角色的概述，请参阅 RHEL 系统角色简介博客文章。  

请注意，最近出现了几个与通过 SSH 配置内核转储相关的 kdump 系统角色错误，这些错误已得到解决。本文中的示例需要 RHEL 系统角色版本 1.22 或更高版本，该版本目前可从 Ansible 自动化中心获取（适用于拥有 Ansible 自动化平台订阅的客户），同时也在 RHEL 8 和 RHEL 9 Beta AppStream 存储库中提供。

我的环境中有三个 RHEL 9 系统。一个系统充当我的 Ansible 控制节点（rhel9-controlnode.example.com），另外两个系统是我要在上面配置 kdump 的托管节点（rhel9-server1.example.com 和 rhel9 -server2.example.com）。  

发生崩溃时，可以将内核转储配置为在系统本地写入，或者通过 SSH 或 NFS 写出到远程主机。在本例中，我要将两个托管节点配置为通过 SSH 在 rhel9-controlnode.example.com 主机上写入内核转储。我还想在每个托管节点上配置 RHEL Web 控制台，以便我可以轻松验证 kdump 是否正常工作。

从控制节点主机，首先使用以下内容创建 Ansible 清单文件，命名为 inventory.yml：

all:
  hosts:
    rhel9-server1.example.com:
    rhel9-server2.example.com:
  vars:
    kdump_target:
      type: ssh
      location: kdump@rhel9-controlnode.example.com
    kdump_path: "/home/kdump/crash"
    kdump_ssh_user: kdump
    kdump_ssh_server: rhel9-controlnode.example.com
    cockpit_manage_firewall: true

清单文件的顶部列出了两个托管节点。接下来，为 kdump 和 cockpit RHEL 系统角色定义 Ansible 变量。

• kdump_target 变量指定 kdump 应通过 SSH 传输到 rhel9-controlnode.example.com 主机。
• kdump_path 变量指定 kdump 应写入 /home/kdump/crash 目录。
• kdump_ssh_user 和 kdump_ssh_server 变量指定应当使用 rhel9-controlnode.example.com 主机上的 kdump 用户帐户传输 kdump（我在 rhel9-controlnode.example.com 主机上创建了此用户帐户，然后再运行 kdump 系统角色）。
• cockpit_manage_firewall 变量指定 cockpit 系统角色应在防火墙中启用 cockpit 服务。

接下来，使用以下内容定义名为 system_roles.yml 的 Ansible playbook：

- name: Run RHEL kdump system role
  hosts: all
  roles:
    - redhat.rhel_system_roles.kdump
- name: Run RHEL cockpit system role
  hosts: all
  roles:
    - redhat.rhel_system_roles.cockpit

此 playbook 调用 RHEL kdump 和 cockpit 系统角色。

使用 ansible-playbook 命令运行 playbook：

$ ansible-playbook -i inventory.yml -b system_roles.yml

在本例中，我指定应运行 system_roles.yml playbook，升级到 root（-b 标志），并且 inventory.yml 文件应用作我的 Ansible清单（-i 标志）。

在我的环境中，该角色在执行 Fail if reboot is required and kdump_reboot_ok is false 任务时失败。  

配置 kdump 可能需要重新启动系统。如果我在清单文件中将 kdump_reboot_ok 变量设置为 true，主机会自动重启。在本例中，我手动重启主机，然后再次运行 playbook。playbook 的第二次运行成功完成。

检查 kdump 配置

在两个托管节点上， kdump 系统角色分别创建了一个新的 SSH 密钥，存储在 /root/.ssh/kdump_id_rsa 下，并且配置了 kdump.conf 配置文件。  

在控制节点主机 rhel9-controlnode.example.com 上，kdump 系统角色使用来自两个托管节点各自的对应公钥配置了 kdump 用户帐户 authorized_keys 文件。  

验证一切是否正常工作的最佳方法是使每个托管节点上的内核崩溃，并验证是否正确创建了内核转储。警告：内核崩溃会导致系统停机！仅在维护期内执行此操作。

您可以从命令行或使用 Web 控制台强制内核崩溃。

使用 Web 浏览器在端口 9090 上连接其主机名，即可使用 RHEL Web 控制台登录每个托管节点。登录后，选择左侧菜单中的 Kernel dump，然后单击 Test configuration 按钮。这会显示一条警告消息，指出这会使内核崩溃。

现在，检查 rhel9-controlnode.example.com 主机上的 /home/kdump/crash 目录。

[rhel9-controlnode]$ ls -l /home/kdump/crash/
total 0
drwxr-xr-x. 2 kdump kdump 72 Sep  6 15:07 192.168.122.102-2023-09-06-15:07:39
drwxr-xr-x. 2 kdump kdump 72 Sep  6 15:07 192.168.122.103-2023-09-06-15:07:44

发生内核转储时，为每个主机创建了一个目录，其目录名称指示了发生崩溃的 IP 地址和日期/时间。内核转储文件也已创建：

[rhel9-controlnode]$ ls -l /home/kdump/crash/192.168.122.103-2023-09-06-15\:07\:44/
total 99120
-rw-------. 1 kdump kdump     77622 Sep  6 15:07 kexec-dmesg.log
-rw-------. 1 kdump kdump     66633 Sep  6 15:07 vmcore-dmesg.txt
-rw-------. 1 kdump kdump 101350015 Sep  6 15:07 vmcore.flat

建议定期测试 kdump 功能，以验证其是否正常工作。系统上有更改时，例如修补、存储更改、硬件更换和网络层更改（如果 kdump 目标设置为 SSH 或 NFS）等，这一点尤其重要。

结论

如果您的某个 RHEL 系统发生过内核崩溃，您是否需要确定原因？如果需要，您必须在 RHEL 环境中正确配置和测试内核转储。RHEL kdump 系统角色使您能够使用自动化在 RHEL 环境中大规模配置内核转储。如果您在 RHEL 环境中设置 kdump 时遇到任何困难，请随时向我们的全球支持服务（GSS）团队提交支持工单，与我们联系。