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.
À propos de l'auteur
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).
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit