L'importanza della configurazione dei dump del kernel in Red Hat Enterprise Linux

Se hai esperienza come amministratore di sistema, probabilmente avrai già vissuto situazioni di forte stress a seguito dell'arresto anomalo di un sistema che ha causato un'interruzione della produzione. In questi casi, l'obiettivo prioritario è ripristinare il prima possibile la normale operatività del sistema di produzione. Ma, una volta raggiunto questo obiettivo, bisogna assolutamente dedicarsi all'analisi della root cause (RCA) e comprendere la motivazione alla base del problema per evitare che si ripresenti.

Il kernel Linux è il fulcro di Red Hat Enterprise Linux (RHEL) e gestisce tutti i dettagli di base che consentono il funzionamento di RHEL su un sistema. Quando il kernel rileva un errore irreversibile, si verifica il kernel panic, che provoca un arresto anomalo del sistema. Questi tipi di arresti anomali del kernel possono essere causati da svariati fattori, tra cui problemi hardware, problemi con moduli del kernel di terze parti, bug nel kernel e così via.

RHEL comprende il servizio kdump. In caso di arresto anomalo del kernel, kdump può avviare un kernel secondario per scrivere un dump della memoria di sistema in un file. Questo file di dump del kernel può essere analizzato e utilizzato per individuare la root cause dell'arresto anomalo del kernel. Senza di esso, spesso è impossibile risalire alla root cause.

Negli ambienti di produzione, è importante verificare periodicamente la corretta configurazione e il funzionamento di kdump (e farlo molto prima che si verifichi un arresto anomalo del kernel).

Opzioni di abilitazione di kdump

Esistono diversi metodi per abilitare kdump, tra cui:

• programma di installazione di RHEL durante la configurazione iniziale del sistema;
• manualmente, con la riga di comando; 
• kdump helper nei laboratori del Red Hat Customer Portal;
• web console di RHEL;
• ruolo di sistema kdump di RHEL.

Questo articolo illustra come utilizzare il ruolo di sistema kdump di RHEL per configurare i sistemi RHEL per i dump del kernel e come utilizzare la web console di RHEL per verificare il corretto funzionamento di kdump.

Utilizzo del ruolo di sistema kdump di RHEL

Per una panoramica generale sull'utilizzo dei ruoli di sistema di RHEL, consulta l'articolo del blog Introduction to RHEL system roles.  

Tieni presente che di recente sono stati riscontrati e risolti un paio di bug del ruolo di sistema kdump correlati alla configurazione dei dump del kernel su SSH. L'esempio riportato in questo articolo richiede una versione 1.22 o successiva dei ruoli di sistema di RHEL, attualmente disponibile su Ansible Automation Hub (disponibile per i clienti provvisti di una sottoscrizione Ansible Automation Platform) e nei repository RHEL 8 e RHEL 9 Beta AppStream.

Nel mio ambiente ho tre sistemi RHEL 9: uno funge da nodo di controllo Ansible (rhel9-controlnode.example.com) e due sono nodi gestiti sui quali voglio configurare kdump (rhel9-server1.example.com e rhel9-server2.example.com).  

In caso di arresto anomalo, è possibile configurare la scrittura locale del dump del kernel nel sistema oppure in un host remoto su SSH o NFS. In questo caso, vorrei configurare i due nodi gestiti in modo che i dump del kernel vengano scritti nell'host rhel9-controlnode.example.com su SSH. Inoltre, vorrei configurare la web console di RHEL su ciascuno dei nodi gestiti, in modo da poter verificare facilmente il corretto funzionamento di kdump.

Dall'host del nodo di controllo, inizio con la creazione di un file di inventario Ansible, denominato inventory.yml, con il seguente contenuto:

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

La parte superiore del file di inventario indica i due nodi gestiti. Poi sono definite le variabili Ansible per i ruoli di sistema di RHEL kdump e cockpit.

• La variabile kdump_target indica che i kdump devono essere trasferiti, tramite SSH, nell'host rhel9-controlnode.example.com.
• La variabile kdump_path specifica che i kdump devono essere scritti nella directory /home/kdump/crash.
• Le variabili kdump_ssh_user e kdump_ssh_server indicano che i kdump devono essere trasferiti utilizzando l'account utente kdump nell'host rhel9-controlnode.example.com (ho creato questo account utente nell'host rhel9-controlnode.example.com prima di eseguire il ruolo di sistema kdump).
• La variabile cockpit_manage_firewall specifica che il ruolo di sistema cockpit deve abilitare il servizio cockpit nel firewall.

A questo punto definisco l'Ansible Playbook, denominato system_roles.yml, con il seguente contenuto:

- 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

Questo playbook richiama i ruoli di sistema kdump e cockpit di RHEL.

Eseguo il playbook con il comando ansible-playbook:

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

In questo esempio, specifico che deve essere eseguito il playbook system_roles.yml , che deve avvenire il passaggio al livello root (flag -b) e che il file inventory.yml deve essere utilizzato come inventario Ansible (flag -i).

Nel mio ambiente, il ruolo non porta a termine correttamente l'attività Fail if reboot is required e kdump_reboot_ok is false.  

La configurazione di kdump potrebbe richiedere il riavvio del sistema. Se avessi impostato la variabile kdump_reboot_ok su true nel file di inventario, gli host si sarebbero riavviati automaticamente. In questo esempio, riavvio manualmente gli host e poi eseguo nuovamente il playbook. La seconda esecuzione del playbook va a buon fine.

Verifica della configurazione di kdump

In ognuno dei due nodi gestiti, il ruolo di sistema kdump ha creato una nuova chiave SSH, archiviata in /root/.ssh/kdump_id_rsa e ha configurato il file di configurazione kdump.conf.  

Nell'host del nodo di controllo, rhel9-controlnode.example.com, il ruolo di sistema kdump ha configurato il file authorized_keys degli account utente kdump con le chiavi pubbliche corrispondenti di ciascuno dei due nodi gestiti.  

Il metodo migliore per accertarsi che tutto funzioni correttamente è provocare un arresto anomalo del kernel su ognuno dei nodi gestiti e verificare che i dump del kernel vengano creati correttamente. Attenzione: l'arresto anomalo di un kernel causa un downtime del sistema! Questa operazione deve essere eseguita esclusivamente nell'arco di una finestra di manutenzione.

L'arresto anomalo del kernel può essere forzato dalla riga di comando o dalla web console.

Accedo a ciascuno dei nodi gestiti dalla web console di RHEL connettendomi ai rispettivi nomi host sulla porta 9090 tramite un browser web. Dopo aver eseguito l'accesso, seleziono Kernel dump nel menu a sinistra, quindi faccio clic sul pulsante Test configuration. Viene visualizzato un messaggio di avviso che preannuncia un arresto anomalo del kernel.

A questo punto verifico la directory /home/kdump/crash nell'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

Al momento del dump del kernel, è stata creata una directory per ciascun host, con i nomi delle directory che indicano l'indirizzo IP e la data e l'ora dell'arresto anomalo. Sono stati creati anche i file di dump del kernel:

[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

Si consiglia di testare regolarmente il funzionamento di kdump per verificare che non presenti problemi. Questo è particolarmente importante in caso di modifiche al sistema, quali applicazione di patch, modifiche dello storage, sostituzioni dell'hardware e modifiche a livello di rete (se la destinazione di kdump è impostata su SSH o NFS) e così via.

Conclusioni

Se uno dei tuoi sistemi RHEL dovesse subire un arresto anomalo del kernel, avresti bisogno di risalire la causa? Se sì, è fondamentale configurare e testare correttamente i dump del kernel nell'ambiente RHEL. Grazie all'automazione, il ruolo di sistema kdump di RHEL ti permette di configurare i dump del kernel all'interno dell'ambiente RHEL su vasta scala. In caso di difficoltà nella configurazione di kdump nel tuo ambiente RHEL, non esitare a contattarci aprendo un ticket di supporto con il team Global Support Services (GSS).