Inicialização Rápida de Instalação e Configuração #

Os procedimentos neste documento conduzem a configuração mínima de um cluster de dois nós com as seguintes propriedades:

Após a instalação do cluster com os scripts de boot, ele será monitorado com o Hawk (HA Web Konsole) gráfico, uma das ferramentas de gerenciamento de cluster incluídas na SUSE® Linux Enterprise High Availability Extension. Como um teste básico para verificar se o failover de recursos funciona, colocaremos um dos nós no modo standby e verificaremos se o endereço IP virtual será migrado para o segundo nó.

Você pode usar o cluster de dois nós para fins de teste ou como uma configuração de cluster mínima que pode ser estendida posteriormente. Antes de usar o cluster em um ambiente de produção, modifique-o de acordo com os seus requisitos.

Esta seção informa você sobre os principais requisitos do sistema para o cenário descrito na Seção 1, “Cenário de uso”. Para ajustar o cluster para uso em um ambiente de produção, leia a lista completa de Requisitos e recomendações do sistema no Chapter 2, System Requirements and Recommendations.

Em todos os nós que farão parte do cluster, é necessário instalar o seguinte software:

Todos os comandos do pacote ha-cluster-bootstrap executam scripts de boot que exigem apenas um mínimo de intervenção manual e de tempo.

Todos os scripts de boot são registrados em /var/log/ha-cluster-bootstrap.log. Consulte esse arquivo para obter todos os detalhes do processo de boot. As opções definidas durante o processo de boot podem ser modificadas posteriormente com o módulo de cluster do YaST. Consulte o Section 3.1, “Manual Installation” para obter os detalhes.

Cada script vem com uma página de manual que abrange a variedade de funções, as opções do script e uma visão geral dos arquivos que o script pode criar e modificar.

O script de boot ha-cluster-init verifica e configura os seguintes componentes:

Os pacotes para configurar e gerenciar um cluster com a High Availability Extension estão incluídos no padrão de instalação High Availability (Alta Disponibilidade). Esse padrão apenas estará disponível após a instalação da SUSE Linux Enterprise High Availability Extension como uma extensão ao SUSE® Linux Enterprise Server.

Para obter informações sobre como instalar extensões, consulte o Guia de Implantação do SUSE Linux Enterprise 12 SP5: https://documentation.suse.com/sles-12/html/SLES-all/cha-add-ons.html.

Se o padrão ainda não foi instalado, instale-o com o comando zypper install -t pattern ha_sles. Se preferir, instale o padrão com o YaST. Proceda da seguinte maneira:

Se você tem armazenamento compartilhado, como uma SAN (Storage Area Network), pode usá-lo para evitar cenários de split brain configurando o SBD como mecanismo de fencing de nó. O SBD usa o suporte a watchdog e o agente de recurso external/sbd do STONITH.

5.2 Configurando o watchdog do Softdog e o SBD #

No SUSE Linux Enterprise Server, o suporte a watchdog no kernel está habilitado por padrão: Ele está incluído em vários módulos do kernel que fornecem drivers de watchdog específicos do hardware. A High Availability Extension usa o daemon SBD como o componente de software que “alimenta” o watchdog.

O procedimento a seguir usa o watchdog do softdog.

Importante: Limitações do softdog

O driver softdog supõe que pelo menos uma CPU ainda esteja em execução. Se todas as CPUs estiverem travadas, o código no driver softdog que deve reinicializar o sistema nunca será executado. Por outro lado, os watchdogs do hardware continuarão funcionando mesmo se todas as CPUs estiverem travadas.

Antes de usar o cluster em um ambiente de produção, é altamente recomendável substituir o módulo softdog pelo módulo correspondente mais adequado ao seu hardware.

No entanto, se nenhum watchdog corresponder ao seu hardware, o softdog poderá ser usado como o módulo watchdog do kernel.

1. Crie um armazenamento compartilhado persistente conforme descrito na Seção 5.1, “Requisitos do SBD”.

2. Habilite o watchdog do softdog:

   root # echo softdog > /etc/modules-load.d/watchdog.conf
   root # systemctl restart systemd-modules-load

3. Teste se o módulo softdog foi carregado corretamente:

   root # lsmod | egrep "(wd|dog)"
   softdog                16384  1

4. Em bob, inicialize a partição SBD:

   root # sbd -d /dev/SBDDEVICE create

5. Inicie o SBD para escutar no dispositivo SBD:

   root # sbd -d /dev/SBDDEVICE watch

6. Em alice, envie uma mensagem de teste:

   root # sbd -d /dev/SBDDEVICE message bob test

7. Em bob, verifique o status com o comando systemctl, e a mensagem recebida deve ser exibida:

   root # systemctl status sbd
   [...]
   info: Received command test from alice on disk SBDDEVICE

8. Pare de monitorar o dispositivo SBD em bob com:

   root # systemctl stop sbd

É altamente recomendável testar se o mecanismo de fencing SBD funciona de maneira apropriada em caso de split brain. Esse tipo de teste pode ser feito bloqueando a comunicação do cluster Corosync.

Configure o primeiro nó com o script ha-cluster-init. Isso exige apenas um mínimo de intervenção manual e de tempo.

Agora, você tem um cluster de um nó em execução. Para ver seu status, faça o seguinte:

Se você tem um cluster de um nó ativo em execução, adicione o segundo nó do cluster com o script de boot ha-cluster-join, conforme descrito no Procedimento 4. O script precisa apenas de acesso a um nó do cluster existente para concluir a configuração básica na máquina atual automaticamente. Para obter detalhes, consulte a página de manual do ha-cluster-join.

Os scripts de boot ficam encarregados de mudar a configuração específica para um cluster de dois nós, por exemplo, SBD e Corosync.

Verifique o status do cluster no Hawk2. Em Status › Nós, dois nós são exibidos com um status verde (consulte a Figura 2, “Status do Cluster de Dois Nós”).

Figura 2: Status do Cluster de Dois Nós #

O Procedimento 5, “Testando o failover de recursos” é um teste simples para verificar se o cluster move o endereço IP virtual para o outro nó caso o nó que executa o recurso atualmente esteja definido como standby.

No entanto, um teste realista envolve casos de uso e cenários específicos, incluindo testes do mecanismo de fencing para evitar uma situação de split brain. Se você não configurar o mecanismo de fencing corretamente, o cluster não funcionará de maneira apropriada.

Antes de usar o cluster em um ambiente de produção, teste-o completamente de acordo com os seus casos de uso.

Durante a migração, é exibido um fluxo contínuo de pings para o endereço IP virtual. Isso mostra que a configuração do cluster e o IP flutuante funcionam corretamente. Cancele o comando ping com Ctrl–C.

Encontre mais documentação para este produto em https://documentation.suse.com/sle-ha-12. A documentação também inclui um Guia de Administração completo para a SUSE Linux Enterprise High Availability Extension. Consulte-o para ver mais tarefas de configuração e administração.

Copyright © 2006– 2023 SUSE LLC e colaboradores. Todos os direitos reservados.

Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da Licença GNU de Documentação Livre, Versão 1.2 ou (por sua opção) versão 1.3; com a Seção Invariante sendo estas informações de copyright e a licença. Uma cópia da versão 1.2 da licença está incluída na seção intitulada “GNU Free Documentation License” (Licença GNU de Documentação Livre).

Para ver as marcas registradas da SUSE, visite http://www.suse.com/company/legal/. Todas as marcas comerciais de terceiros pertencem a seus respectivos proprietários. Os símbolos de marca registrada (®,™ etc.) representam marcas registradas da SUSE e suas afiliadas. Os asteriscos (*) indicam marcas registradas de terceiros.

Todas as informações deste manual foram compiladas com a maior atenção possível aos detalhes. Entretanto, isso não garante uma precisão absoluta. A SUSE LLC, suas afiliadas, os autores ou tradutores não serão responsáveis por possíveis erros nem pelas consequências resultantes de tais erros.