Die Bedeutung der Konfiguration von Kernel-Dumps in Red Hat Enterprise Linux

Wenn Sie in der Systemadministration arbeiten, haben Sie wahrscheinlich sehr angespannte Situationen erlebt, nachdem ein Systemabsturz einen Produktionsausfall verursacht hat. In einer solchen Situation besteht das Hauptziel darin, das Produktionssystem so schnell wie möglich wieder zum Laufen zu bringen. Sobald jedoch alles wieder in Ordnung ist, muss Ihr Ziel die Ursachenanalyse (Root Cause Analysis, RCA) sein. Sie müssen die Ursache des Problems verstehen, wenn Sie verhindern wollen, dass es erneut auftritt.

Der Linux-Kernel ist der Kern von Red Hat Enterprise Linux (RHEL) und verarbeitet die Low-Level-Details, die den Betrieb von RHEL auf einem System ermöglichen. Wenn der Kernel einen nicht wiederherstellbaren Fehler erkennt, erfährt dieser die sogenannte „Kernel Panic“, was zu einem Systemabsturz führt. Diese Art von Kernel-Abstürzen kann durch verschiedene Faktoren verursacht werden, darunter Hardwareprobleme, Probleme mit Kernel-Modulen von Drittanbietern, Bugs im Kernel und so weiter.

RHEL enthält den Service kdump. Bei einem Kernel-Absturz kann kdump in einen sekundären Kernel booten, um einen Dump des Systemspeichers in eine Datei zu schreiben. Diese Kernel-Dump-Datei kann analysiert und dazu verwendet werden, die Ursache des Kernel-Absturzes zu ermitteln. Ohne eine Kernel-Dump-Datei ist es oft unmöglich, die Ursache zu ermitteln.

In Produktivumgebungen ist es wichtig, regelmäßig zu überprüfen, ob kdump ordnungsgemäß konfiguriert ist und funktioniert (lange bevor ein Kernel-Absturz auftritt).

Optionen zur Aktivierung von kdump

Es gibt verschiedene Methoden, um kdump zu aktivieren, einschließlich:

• RHEL-Installationsprogramm, wenn das System zum ersten Mal erstellt wird
• Manuell über die Befehlszeile
• Mit der kdump-Hilfe in den Red Hat Customer Portal Labs
• RHEL-Webkonsole
• RHEL kdump-Systemrolle

In diesem Artikel demonstriere ich die Verwendung der RHEL kdump-Systemrolle zur Konfiguration von RHEL-Systemen für Kernel-Dumps und anschließend die Verwendung der RHEL-Webkonsole, um zu validieren, ob kdump ordnungsgemäß funktioniert.

Verwendung der RHEL kdump-Systemrolle

Einen Überblick über die ersten Schritte mit RHEL-Systemrollen finden Sie im Blog-Beitrag Einführung in RHEL-Systemrollen.  

Beachten Sie, dass es kürzlich einige Fehler mit der kdump-Systemrolle im Zusammenhang mit der Konfiguration von Kernel-Dumps über SSH gab, die inzwischen behoben wurden. Für das Beispiel in diesem Artikel sind die RHEL-Systemrollen Version 1.22 oder höher erforderlich, die derzeit über Ansible Automation Hub (verfügbar als Teil einer Subskription für Ansible Automation Platform) und auch in den Beta-AppStream-Repositorys von RHEL 8 und RHEL 9 verfügbar sind.

In meiner Umgebung verfüge ich über drei RHEL 9-Systeme. Ein System fungiert als Ansible-Kontrollknoten (rhel9-controlnode.example.com), und zwei sind verwaltete Knoten, auf denen ich kdump konfigurieren möchte (rhel9-server1.example.com und rhel9 -server2.example.com).  

Der Kernel-Dump kann so konfiguriert werden, dass er im Falle eines Absturzes lokal auf dem System oder über SSH oder NFS auf einen Remote-Host geschrieben wird. In diesem Beispiel möchte ich meine beiden verwalteten Knoten so konfigurieren, dass Kernel-Dumps per SSH auf den Host rhel9-controlnode.example.com geschrieben werden. Ich möchte außerdem die RHEL-Webkonsole auf allen verwalteten Knoten konfigurieren, damit ich leicht überprüfen kann, ob kdump ordnungsgemäß funktioniert.

Erstellen Sie auf dem Kontrollknoten-Host zunächst eine Ansible-Inventardatei mit dem Namen inventory.ymlund folgendem Inhalt:

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

Oben in der Inventardatei werden die zwei verwalteten Knoten aufgeführt. Definieren Sie als Nächstes die Ansible-Variablen für die RHEL-Systemrollen kdump und cockpit.

• Die Variable kdump_target gibt an, dass kdumps per SSH an den Host rhel9-controlnode.example.com übertragen werden sollen.
• Die Variable kdump_path gibt an, dass die kdumps in das Verzeichnis /home/kdump/crash geschrieben werden sollen.
• Die Variablen kdump_ssh_user und kdump_ssh_server geben an, dass die kdumps mit dem kdump-Benutzerkonto auf den Host rhel9-controlnode.example.com übertragen werden sollen. Ich habe dieses Benutzerkonto vor dem Ausführen der kdump-Systemrolle auf dem Host rhel9-controlnode.example.com erstellt.
• Die Variable cockpit_manage_firewall gibt an, dass die cockpit-Systemrolle den cockpit-Service in der Firewall aktivieren soll.

Definieren Sie als Nächstes das Ansible Playbook mit dem Namen system_roles.yml mit dem folgenden Inhalt:

- 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

Dieses Playbook ruft die RHEL-Systemrollen kdump und cockpit auf.

Führen Sie das Playbook mit dem Befehl ansible-playbook aus:

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

In diesem Beispiel definiere ich, dass das Playbook system_roles.yml ausgeführt und auf root ausgeweitet werden soll (der Flag -b) und dass die Datei inventory.yml als mein Ansible-Inventory verwendet werden soll (der Flag -i).

In meiner Umgebung schlägt die Rolle bei der Aufgabe Fail if reboot is required and kdump_reboot_ok is false fehl.  

Die Konfiguration von kdump erfordert möglicherweise einen Neustart des Systems. Wenn ich die Variable kdump_reboot_ok in der Inventory-Datei auf true festgelegt hätte, wären die Hosts automatisch neu gestartet. In diesem Beispiel starte ich die Hosts manuell neu und führe dann das Playbook erneut aus. Die zweite Ausführung des Playbooks wird erfolgreich abgeschlossen.

Überprüfen der kdump-Konfiguration

Auf den beiden verwalteten Knoten hat die Systemrolle kdump jeweils einen neuen SSH-Schlüssel erstellt, der unter /root/.ssh/kdump_id_rsa gespeichert ist, und die Konfigurationsdatei kdump.conf konfiguriert.  

Auf dem Kontrollknoten-Host rhel9-controlnode.example.com hat die kdump-Systemrolle die kdump-Benutzerkonten authorized_keys-Datei mit den entsprechenden öffentlichen Schlüsseln von jedem der beiden verwalteten Knoten konfiguriert.  

Die beste Methode, um zu überprüfen, ob alles ordnungsgemäß funktioniert, besteht darin, den Kernel auf allen verwalteten Knoten zum Absturz zu bringen und zu überprüfen, ob die Kernel-Dumps ordnungsgemäß erstellt wurden. Warnung: Ein Kernel-Absturz führt zu Ausfallzeiten auf dem System! Tun Sie dies nur während eines Wartungsfensters.

Sie können einen Kernel-Absturz über die Befehlszeile oder über die Webkonsole erzwingen.

Melden Sie sich über die RHEL-Webkonsole bei jedem verwalteten Knoten an, indem Sie über einen Webbrowser eine Verbindung mit den entsprechenden Hostnamen auf Port 9090 herstellen. Wählen Sie nach der Anmeldung im Menü auf der linken Seite Kernel-Dump aus, und klicken Sie dann auf die Schaltfläche Testkonfiguration. Es wird eine Warnung angezeigt, dass dies den Kernel zum Absturz bringen wird.

Überprüfen Sie nun das Verzeichnis /home/kdump/crash auf dem Host rhel9-controlnode.example.com.

[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

Beim Kernel-Dump wurde für jeden Host ein Verzeichnis erstellt, wobei die Verzeichnisnamen die IP-Adresse und das Datum/die Uhrzeit des Absturzes angeben. Kernel-Dump-Dateien wurden ebenfalls erstellt:

[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

Es wird empfohlen, die kdump-Funktion routinemäßig zu testen, um sicherzustellen, dass sie ordnungsgemäß funktioniert. Dies ist besonders wichtig, wenn Änderungen im System vorhanden sind, wie beispielsweise Patching, Storage-Änderungen, Hardwareaustausch und Änderungen auf der Netzwerkschicht (wenn das kdump-Ziel auf SSH oder NFS gesetzt ist).

Fazit

Wenn jemals in einem Ihrer RHEL-Systeme ein Kernel abstürzt, müssten Sie dann die Ursache ermitteln? Falls ja, ist es wichtig, dass Sie Kernel-Dumps in Ihrer RHEL-Umgebung ordnungsgemäß konfigurieren und testen. Mit der RHEL-Systemrolle kdump können Sie Kernel-Dumps in Ihrer RHEL-Umgebung mithilfe von Automatisierung in großem Umfang konfigurieren. Wenn Sie auf Schwierigkeiten bei der Einrichtung von kdump in Ihrer RHEL-Umgebung stoßen, können Sie ein Support-Ticket bei unserem GSS-Team (Global Support Services) öffnen.