订阅内容

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

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

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

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

用于启用 kdump 的选项

启用 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.comrhel9 -server2.example.com)。  

Simple illustration of three RHEL 9 systems, including one controlnode and two servers

发生崩溃时,可以将内核转储配置为在系统本地写入,或者通过 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_userkdump_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 任务时失败。  

Screenshot of a command result in a terminal

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

Screenshot of a PLAY RECAP in a terminal window

检查 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 按钮。这会显示一条警告消息,指出这会使内核崩溃。

Screenshot of the "Test kdump settings" dialog box with a "Crash system" button

现在,检查 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)团队提交支持工单,与我们联系。


关于作者

Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management.  He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).  

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事