Inscreva-se no feed

Se você já trabalhou como administrador de sistemas, provavelmente já passou por situações de alto estresse após alguma falha que causou a interrupção da produção. Em tal situação, o objetivo principal é colocar o sistema de produção em funcionamento novamente o mais rápido possível. No entanto, assim que tudo for restabelecido e estiver funcionando, seu objetivo passa a ser encontrar a causa raiz do problema (RCA). É necessário entender o motivo pelo qual um problema ocorreu para que ele não aconteça novamente.

O kernel do Linux é o núcleo do Red Hat Enterprise Linux (RHEL) e lida com todos os detalhes de baixo nível que permitem que o RHEL opere em um sistema. Quando o kernel detecta um erro não recuperável, ele entra em pane, resultando em uma falha do sistema. Esses tipos de falhas do kernel podem ser causados por vários fatores, incluindo problemas de hardware, problemas com módulos do kernel de terceiros, bugs no kernel e assim por diante.

O RHEL inclui o serviço kdump. Quando o kernel falha, o kdump pode inicializar em um kernel secundário para gravar o despejo ("dump") da memória do sistema em um arquivo. Esse arquivo de despejo pode ser analisado e usado para determinar a causa raiz da falha do kernel. Muitas vezes é impossível determinar a causa raiz sem um arquivo de despejo de memória do kernel.

Em ambientes de produção, é importante validar periodicamente se o kdump está configurado corretamente e funcionando (bem antes de ocorrer uma falha do kernel).

Opções para habilitar o kdump

Há vários métodos para habilitar o kdump, como:

Neste artigo, demonstro como usar a função do sistema RHEL kdump para configurar sistemas RHEL para despejos de memória kernel e, em seguida, como usar o console web do RHEL para validar se o kdump está funcionando corretamente.

Uso da função de sistema RHEL kdump

Para uma visão geral de como começar a usar as funções do sistema RHEL, consulte o post Introdução às funções do sistema RHEL.  

Recentemente, alguns bugs com a função do sistema kdump relacionados à configuração de despejos de memória kernel através do SSH foram resolvidos. O exemplo neste artigo requer as funções do sistema RHEL da versão 1.22 ou posterior, atualmente disponível no Ansible Automation Hub (disponível para clientes com uma subscrição do Ansible Automation Platform) e também nos repositórios Beta do AppStream do RHEL 8 e RHEL 9.

No meu ambiente, tenho três sistemas RHEL 9. Um sistema atua como meu nó de controle do Ansible (rhel9-controlnode.example.com) e dois são nós gerenciados nos quais desejo configurar o kdump (rhel9-server1.example.com e rhel9 -server2.example.com).  

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

No caso de uma falha, o despejo do kernel pode ser configurado para ser gravado localmente no sistema ou gravado em um host remoto através do SSH, ou NFS. Neste exemplo, gostaria de configurar meus dois nós gerenciados para gravar despejos de memória kernel no host rhel9-controlnode.example.com através do SSH. Gostaria de configurar também o console da web do RHEL em cada um dos nós gerenciados para poder verificar facilmente se o kdump está funcionando apropriadamente.

No host do nó de controle, comece criando um arquivo de inventário do Ansible, chamado inventory.yml, com o seguinte conteúdo:

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

A parte superior do arquivo de inventário lista os dois nós gerenciados. Em seguida, defina as variáveis do Ansible para as funções do sistema RHEL kdump e cockpit.

  • A variável kdump_target especifica que os kdumps devem ser transferidos, por SSH, para o host rhel9-controlnode.example.com.
  • A variável kdump_path especifica que os kdumps devem ser gravados no diretório /home/kdump/crash.
  • As variáveis kdump_ssh_user e kdump_ssh_server especificam que os kdumps devem ser transferidos usando a conta de usuário kdump no host rhel9-controlnode.example.com (criei essa conta de usuário em o host rhel9-controlnode.example.com antes de executar a função do sistema kdump).
  • A variável cockpit_manage_firewall especifica que a função do sistema cockpit deve habilitar o serviço cockpit no firewall.

Em seguida, defina o playbook do Ansible, chamado system_roles.yml, com o seguinte conteúdo:

- 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

Esse playbook chama as funções de sistema kdump e cockpit do RHEL.

Execute o playbook com o comando ansible-playbook:

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

Neste exemplo, especifiquei que o playbook system_roles.yml deve ser executado, que deve ser escalonado para root (o sinalizador -b) e que o arquivo inventory.yml deve ser usado como meu inventário do Ansible (o sinalizador -i ).

Em meu ambiente, a função falha na tarefa Fail if reboot is required and kdump_reboot_ok is false.  

Screenshot of a command result in a terminal

A configuração do kdump pode exigir que o sistema seja reinicializado. Se eu tivesse definido a variável kdump_reboot_ok como true no arquivo de inventário, os hosts teriam sido reinicializados automaticamente.  Neste exemplo, eu reinicio manualmente os hosts e, em seguida, executo o playbook novamente. A segunda execução do playbook é concluída com êxito.

Screenshot of a PLAY RECAP in a terminal window

Verifique a configuração do kdump

Em cada um dos dois nós gerenciados, a função do sistema kdump criou uma nova chave SSH, armazenada em /root/.ssh/kdump_id_rsa, configurando o arquivo de configuração kdump.conf.  

No host do nó de controle, rhel9-controlnode.example.com, a função do sistema kdump configurou o arquivo do kdump de contas do usuário, authorized_keys, com as chaves públicas correspondentes de cada um dos dois nós gerenciados.  

O melhor método para validar o funcionamento apropriado de tudo é fazer com que o kernel falhe em cada um dos nós gerenciados e validar se os despejos de memória kernel foram criados adequadamente. Aviso: a falha de um kernel leva a um downtime no sistema! Faça isso somente durante um período de manutenção.

Você pode forçar uma falha do kernel a partir da linha de comando ou usando o console web.

Acesse cada um dos nós gerenciados usando o console web do RHEL, conectando-se aos seus nomes de host na porta 9090, mediante um navegador da web. Após acessar, selecione Kernel dump (despejo do kernel) no menu à esquerda e clique no botão Test configuration (Configuração de teste). Uma mensagem de aviso é exibida informando que isso provocará uma falha no kernel.

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

Agora verifique o diretório /home/kdump/crash no 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

Um diretório para cada host foi criado quando ocorreu o despejo do kernel, com os nomes dos diretórios indicando o endereço IP e a data/hora em que a falha ocorreu. Os arquivos de despejo do kernel também foram criados:

[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

Recomenda-se testar a funcionalidade kdump rotineiramente para validar sua correta execução. Isso é importante principalmente quando há alterações no sistema, como aplicação de patches, alterações de armazenamento, substituições de hardware e alterações na camada de rede (se o destino do kdump estiver definido como SSH ou NFS) e assim por diante.

Conclusão

Se um dos seus sistemas RHEL apresentar uma falha do kernel, será necessário determinar a causa?  Nesse caso, é essencial que você configure e teste adequadamente os despejos de memória kernel no seu ambiente RHEL. A função do sistema RHEL kdump permite que você configure esses dumps no seu ambiente RHEL em escala, usando a automação. Não hesite em entrar em contato abrindo um ticket de suporte com nossa equipe de Serviços de Suporte Global (GSS) se tiver problemas para configurar o kdump no seu ambiente RHEL.


Sobre o autor

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

Navegue por canal

automation icon

Automação

Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes

AI icon

Inteligência artificial

Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente

open hybrid cloud icon

Nuvem híbrida aberta

Veja como construímos um futuro mais flexível com a nuvem híbrida

security icon

Segurança

Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias

edge icon

Edge computing

Saiba quais são as atualizações nas plataformas que simplificam as operações na borda

Infrastructure icon

Infraestrutura

Saiba o que há de mais recente na plataforma Linux empresarial líder mundial

application development icon

Aplicações

Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações

Original series icon

Programas originais

Veja as histórias divertidas de criadores e líderes em tecnologia empresarial