L'importance de la configuration du vidage du noyau dans Red Hat Enterprise Linux

Si vous travaillez en tant qu'administrateur système, vous avez probablement déjà subi le stress lié à une panne du système ayant entraîné une interruption de la production. Dans une telle situation, l'objectif principal est de rétablir le plus rapidement possible le bon fonctionnement du système de production. Dès que tout est à nouveau opérationnel, vous devez vous intéresser à l'analyse des causes profondes pour comprendre la raison pour laquelle un problème s'est produit afin de l'empêcher de se reproduire.

Le noyau Linux est le cœur de Red Hat Enterprise Linux (RHEL) et gère tous les détails techniques qui permettent à RHEL de fonctionner sur un système. Lorsqu'il détecte une erreur irrécupérable, le noyau panique, ce qui entraîne la panne du système. Ces types de pannes du noyau peuvent être causés par divers facteurs, notamment des problèmes matériels, des problèmes liés aux modules tiers du noyau ou des bogues dans le noyau.

RHEL inclut le service kdump. En cas de panne du noyau, le service kdump peut démarrer dans un noyau secondaire afin d'enregistrer un vidage de la mémoire système dans un fichier. Ce fichier de vidage du noyau peut être analysé et utilisé pour déterminer la cause profonde de la panne du noyau. Sans fichier de vidage du noyau, il est souvent impossible de déterminer la cause profonde de la panne.

Dans les environnements de production, il est important de vérifier régulièrement que le service kdump est correctement configuré et qu'il fonctionne (bien avant que le noyau ne tombe en panne).

Options pour l'activation de kdump

Il existe plusieurs méthodes pour activer kdump, notamment :

• Programme d'installation RHEL lors de la création initiale du système
• Activation manuelle avec la ligne de commande
• Assistant kdump dans les ateliers du portail client Red Hat
• Console web RHEL
• Rôle système kdump dans RHEL

Dans cet article, j'explique comment utiliser le rôle système kdump dans RHEL pour configurer les systèmes RHEL et les vidages du noyau, puis comment utiliser la console web RHEL pour vérifier que le service kdump fonctionne correctement.

Utilisation du rôle système kdump dans RHEL

Pour savoir comment utiliser les rôles système RHEL, consultez cet article de blog.  

Récemment, il y a eu quelques bogues avec le rôle système kdump liés à la configuration des vidages du noyau via SSH qui ont depuis été corrigés. L'exemple présenté dans cet article repose sur les rôles système RHEL version 1.22 ou ultérieure, actuellement disponibles dans le référentiel Ansible Automation Hub (accessible avec une souscription Ansible Automation Platform), ainsi que dans les référentiels AppStream RHEL 8 et RHEL 9 Beta.

Dans mon environnement, j'ai trois systèmes RHEL 9. Un système sert de nœud de contrôle d'Ansible (rhel9-controlnode.example.com) et les deux autres sont des nœuds gérés sur lesquels je souhaite configurer kdump (rhel9-server1.example.com et rhel9 -server2.example.com).  

En cas de panne, le vidage du noyau peut être configuré pour un enregistrement local sur le système, ou sur un hôte distant via SSH ou NFS. Dans cet exemple, je souhaite configurer mes deux nœuds gérés pour un enregistrement des vidages du noyau sur l'hôte rhel9-controlnode.example.com via SSH. Je souhaite également configurer la console web RHEL sur chacun des nœuds gérés, afin de pouvoir vérifier facilement que le service kdump fonctionne correctement.

Depuis l'hôte du nœud de contrôle, commencez par créer un fichier d'inventaire Ansible nommé inventory.yml avec le contenu suivant :

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

Les deux nœuds gérés sont indiqués au début du fichier d'inventaire. Ensuite, il faut définir les variables Ansible pour les rôles système RHEL kdump et cockpit.

• La variable kdump_target spécifie que les vidages kdump doivent être transférés, via SSH, vers l'hôte rhel9-controlnode.example.com.
• La variable kdump_path spécifie que les vidages kdump doivent être enregistrés dans le répertoire /home/kdump/crash.
• Les variables kdump_ssh_user et kdump_ssh_server spécifient que les vidages kdump doivent être transférés à l'aide du compte d'utilisateur kdump sur l'hôte rhel9-controlnode.example.com (j'ai créé ce compte d'utilisateur sur l'hôte rhel9-controlnode.example.com avant d'exécuter le rôle système kdump).
• La variable cockpit_manage_firewall spécifie que le rôle système cockpit doit activer le service cockpit dans le pare-feu.

Ensuite, créez le playbook Ansible, nommé system_roles.yml, avec le contenu suivant :

- 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

Ce playbook appelle les rôles système RHEL kdump et cockpit.

Exécutez le playbook avec la commande ansible-playbook :

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

Dans cet exemple, je spécifie que le playbook system_roles.yml doit être exécuté, qu'il doit passer au mode root (-b) et que le fichier inventory.yml doit être utilisé comme inventaire Ansible (-i).

Dans mon environnement, le rôle échoue à la tâche Fail if reboot is required and kdump_reboot_ok is false.  

La configuration du service kdump peut nécessiter de redémarrer le système. Si j'avais défini la variable kdump_reboot_ok sur true dans le fichier d'inventaire, les hôtes auraient automatiquement redémarré. Dans cet exemple, je redémarre manuellement les hôtes, puis j'exécute à nouveau le playbook. La deuxième exécution du playbook se termine correctement.

Vérification de la configuration du service kdump

Sur chacun des deux nœuds gérés, le rôle système kdump a créé une clé SSH, stockée sous /root/.ssh/kdump_id_rsa et a configuré le fichier de configuration kdump.conf.  

Sur l'hôte du nœud de contrôle, rhel9-controlnode.example.com, le rôle système kdump a configuré le fichier authorized_keys des comptes d'utilisateur kdump avec les clés publiques correspondantes de chacun des deux nœuds gérés.  

La meilleure méthode pour s'assurer que tout fonctionne correctement consiste à générer une panne du noyau sur chacun des nœuds gérés et à vérifier que les vidages du noyau ont bien été créés. Attention : la panne d'un noyau entraîne des temps d'arrêt du système ! Faites-le uniquement pendant une période de maintenance.

Vous pouvez forcer une panne du noyau à partir de la ligne de commande ou en utilisant la console web.

Accédez à chacun des nœuds gérés à l'aide de la console web RHEL en vous connectant à leurs noms d'hôte sur le port 9090 dans un navigateur web. Une fois que vous êtes connecté, sélectionnez Kernel dump dans le menu situé à gauche, puis cliquez sur le bouton Test configuration. Un message d'avertissement s'affiche pour indiquer que cette opération va provoquer une panne du noyau.

Vérifiez à présent le répertoire /home/kdump/crash sur l'hôte 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

Un répertoire a été créé pour chaque hôte lors du vidage du noyau. Les noms des répertoires indiquent l'adresse IP et la date et l'heure de la panne. Des fichiers de vidage du noyau ont également été créés :

[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

Il est recommandé de tester régulièrement la fonctionnalité kdump pour vérifier son bon fonctionnement. Cette opération est particulièrement importante en cas de modifications apportées au système, telles que l'application de correctifs, l'ajustement de l'espace de stockage, le remplacement du matériel ou les changements au niveau de la couche réseau (si la cible kdump est définie sur SSH ou NFS).

Conclusion

Si l'un de vos systèmes RHEL subissait une panne de noyau, auriez-vous besoin d'en déterminer la cause ?Si tel est le cas, il est essentiel de configurer et de tester correctement les vidages du noyau dans votre environnement RHEL. Le rôle système RHEL kdump vous permet de configurer les vidages du noyau dans votre environnement RHEL à grande échelle à l'aide de l'automatisation. N'hésitez pas à contacter notre équipe des services d'assistance internationale si vous rencontrez des difficultés lors de la configuration du service kdump dans votre environnement RHEL.