Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação da SUSE Linux Enterprise High Availability Extension / Quick Start Guides / Inicialização Rápida de Instalação e Configuração
SUSE Linux Enterprise High Availability Extension 15 SP4

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

Data de Publicação: 11 de dezembro de 2023

Este documento orienta você na configuração de um cluster muito básico de dois nós usando os scripts de boot incluídos no crm shell. Isso inclui a configuração de um endereço IP virtual como um recurso de cluster e o uso do SBD em armazenamento compartilhado como um mecanismo de fencing de nós.

Autores: Tanja Roth e Thomas Schraitle

1 Cenário de uso

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

  • Dois nós: alice (IP: 192.168.1.1) e bob (IP: 192.168.1.2), conectados um ao outro pela rede.

  • Um endereço IP virtual flutuante (192.168.2.1) que permite aos clientes se conectarem ao serviço independentemente do nó físico no qual estão sendo executados.

  • Um dispositivo de armazenamento compartilhado usado como mecanismo de fencing SBD. Isso evita cenários de split brain.

  • Failover de recursos de um nó para outro em caso de falha no host ativo (configuração ativo/passivo).

Após a configuração do cluster com os scripts de boot, monitoraremos o cluster com o Hawk2 gráfico. Trata-se de 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.

2 Requisitos do sistema

Esta seção informa você sobre os principais requisitos do sistema para o cenário descrito na Seção 1. Para ajustar o cluster para uso em um ambiente de produção, consulte a lista completa no Chapter 2, System requirements and recommendations.

2.1 Requisitos de hardware

Servidores

Dois servidores com software conforme especificado na Seção 2.2, “Requisitos de software”.

Os servidores podem ser completamente vazios ou máquinas virtuais. Eles não exigem hardware idêntico (memória, espaço em disco etc.), mas devem ter a mesma arquitetura. Clusters compatíveis com várias plataformas não são suportados.

Canais de comunicação

No mínimo, duas mídias de comunicação TCP/IP por nó do cluster. O equipamento de rede deve suportar os meios de comunicação que você deseja usar para comunicação do cluster: multicast ou unicast. A mídia de comunicação deve suportar uma taxa de dados de 100 Mbit/s ou superior. Para uma configuração de cluster compatível, são necessários pelo menos dois caminhos de comunicação redundantes. Isso pode ser feito por meio de:

  • Ligação de Dispositivo de Rede (preferencial)

  • Um segundo canal de comunicação no Corosync

Fencing de nó/STONITH

Para evitar um cenário de split brain, os clusters precisam de um mecanismo de fencing de nó. Em um cenário de split brain, os nós do cluster são divididos em dois ou mais grupos que não sabem a respeito um do outro (devido a uma falha de hardware ou de software ou a uma conexão de rede interrompida). Um mecanismo de fencing isola o nó em questão (geralmente, redefinindo ou desligando o nó). Isso também é chamado de STONITH (Shoot the other node in the head – Atirar na cabeça do outro nó). O mecanismo de fencing de nó pode ser um dispositivo físico (switch de energia) ou um mecanismo como SBD (STONITH por disco) em combinação com um watchdog. O uso do SBD requer armazenamento compartilhado.

2.2 Requisitos de software

Todos os nós que farão parte do cluster precisam, no mínimo, dos seguintes módulos e extensões:

  • Módulo Basesystem 15 SP4

  • Server Applications Module 15 SP4

  • SUSE Linux Enterprise High Availability Extension 15 SP4

2.3 Outros requisitos e recomendações

Sincronização de Horário

Os nós do cluster devem ser sincronizados com um servidor NTP fora do cluster. Desde a SUSE Linux Enterprise High Availability Extension 15, chrony é a implementação padrão de NTP. Para obter mais informações, consulte o Guia de Administração do SUSE Linux Enterprise Server 15 SP4.

Se os nós não forem sincronizados, o cluster poderá não funcionar apropriadamente. Além disso, os arquivos de registro e os relatórios do cluster são muito difíceis de analisar sem a sincronização. Se você usar os scripts de boot, será avisado caso o NTP ainda não tenha sido configurado.

Nome de host e endereço IP
  • Use endereços IP estáticos.

  • Liste todos os nós do cluster no arquivo etc/hosts com o respectivo nome completo e abreviado do host. É essencial que os membros do cluster possam encontrar uns aos outros pelo nome. Se os nomes não estiverem disponíveis, haverá falha na comunicação interna do cluster.

SSH

Todos os nós do cluster devem ser capazes de acessar uns aos outros por SSH. Ferramentas como o crm report (para solução de problemas) e o Explorador do Histórico do Hawk2 exigem acesso por SSH sem senha entre os nós; do contrário, elas apenas poderão coletar dados do nó atual.

Se você usar os scripts de boot para configurar o cluster, as chaves SSH serão automaticamente criadas e copiadas.

3 Visão geral dos scripts de boot

Os comandos a seguir executam scripts de boot que exigem apenas um mínimo de intervenção manual e de tempo.

  • Com o crm cluster init, defina os parâmetros básicos necessários para a comunicação do cluster. Dessa forma, você tem um cluster de um nó em execução.

  • Com o crm cluster join, adicione outros nós ao cluster.

  • Com o crm cluster remove, remova os nós do cluster.

Todos os scripts de boot são registrados em /var/log/crmsh/crmsh.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 a Chapter 4, Using the YaST cluster module para obter os detalhes.

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

NTP

Se o NTP não foi configurado para ser iniciado no momento da inicialização, uma mensagem é exibida. Desde a SUSE Linux Enterprise High Availability Extension 15, chrony é a implementação padrão de NTP.

SSH

Ele cria chaves SSH para login sem senha entre os nós do cluster.

Csync2

Ele configura o Csync2 para replicar os arquivos de configuração para todos os nós em um cluster.

Corosync

Ele configura o sistema de comunicação do cluster.

SBD/watchdog

Ele verifica se há um watchdog e pergunta se é para configurar o SBD como mecanismo de fencing de nó.

IP flutuante virtual

Ele pergunta se é para configurar um endereço IP virtual para administração do cluster com o Hawk2.

Firewall

Ele abre as portas no firewall que são necessárias para a comunicação do cluster.

Nome do cluster

Define um nome para o cluster. Por padrão, hacluster. Isso é opcional e é útil principalmente para clusters Geo. Geralmente, o nome do cluster reflete a localização e facilita distinguir um site dentro de um cluster Geo.

QDevice/QNetd

Essa configuração não está no escopo deste documento. Para usar um servidor QNetd, configure-o com o script de boot, conforme descrito no Chapter 14, QDevice and QNetd.

4 Instalando a SUSE Linux Enterprise High Availability Extension

Os pacotes para configuração e gerenciamento de um cluster com a High Availability Extension estão incluídos no padrão de instalação High Availability (denominado sles_ha na linha de comando). 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 as extensões, consulte oGuia de Implantação para SUSE Linux Enterprise Server 15 SP4.

Procedimento 1: Instalando o padrão High Availability

Se o padrão ainda não foi instalado, faça o seguinte:

  1. Instale-o por meio da linha de comando usando o Zypper:

    root # zypper install -t pattern ha_sles
  2. Instale o padrão High Availability em todas as máquinas que farão parte do cluster.

    Nota
    Nota: Instalando pacotes de software em todas as partes

    Para uma instalação automatizada do SUSE Linux Enterprise Server 15 SP4 e da SUSE Linux Enterprise High Availability Extension 15 SP4, use o AutoYaST para clonar os nós existentes. Para obter mais informações, consulte a Section 3.2, “Mass installation and deployment with AutoYaST”.

  3. Registre as máquinas no SUSE Customer Center. Encontre mais informações no Guia de Upgrade para SUSE Linux Enterprise Server 15 SP4.

5 Usando o SBD como mecanismo de fencing

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

5.1 Requisitos do SBD

Durante a configuração do primeiro nó com crm cluster init, você decide se vai usar o SBD. Em caso afirmativo, será necessário digitar o caminho para o dispositivo de armazenamento compartilhado. Por padrão, o crm cluster init cria automaticamente uma pequena partição no dispositivo que será usado para o SBD.

Para usar o SBD, os seguintes requisitos devem ser atendidos:

  • O caminho para o dispositivo de armazenamento compartilhado deve ser persistente e consistente em todos os nós no cluster. Use nomes de dispositivos estáveis, como /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.

  • O dispositivo SBD não deve usar RAID com base em host, cLVM2 nem residir em uma instância DRBD*.

Para obter detalhes sobre a configuração do armazenamento compartilhado, consulte o Guia de Administração de Armazenamento do SUSE Linux Enterprise Server 15 SP4.

5.2 Habilitando o watchdog do softdog para 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
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 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 | grep dog
    softdog                16384  1

É altamente recomendável testar o mecanismo de fencing SBD na função apropriada para evitar um cenário de divisão. Esse tipo de teste pode ser feito bloqueando a comunicação do cluster Corosync.

6 Configurando o primeiro nó

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

Procedimento 2: Configurando o primeiro nó (alice) com crm cluster init
  1. Efetue login como root na máquina física ou virtual que será usada como nó do cluster.

  2. Inicie o script de boot executando:

    root # crm cluster init --name CLUSTERNAME

    Substitua o marcador CLUSTERNAME por um nome significativo, como a localização geográfica do seu cluster (por exemplo, amsterdam). Isso é útil principalmente para criar um cluster Geo no futuro, pois ele simplifica a identificação de um site.

    Se você precisar de multicast em vez de unicast (padrão) para a comunicação com o cluster, use a opção --multicast (ou -U).

    O script verifica se há um serviço watchdog de hardware e uma configuração do NTP. Ele gera as chaves SSH públicas e privadas usadas para acesso SSH e sincronização Csync2 e inicia os respectivos serviços.

  3. Configure a camada de comunicação do cluster (Corosync):

    1. Digite um endereço de rede ao qual vincular. Por padrão, o script propõe o endereço de rede de eth0. Se preferir, digite um endereço de rede diferente, por exemplo, o endereço de bond0.

    2. Aceite a porta proposta (5405) ou insira uma diferente.

  4. Configure o SBD como mecanismo de fencing de nó:

    1. Pressione y para confirmar que você deseja usar o SBD.

    2. Digite um caminho persistente para a partição do dispositivo de blocos que você deseja usar para o SBD. Consulte a Seção 5, “Usando o SBD como mecanismo de fencing”. O caminho deve ser consistente em todos os nós no cluster.

  5. Configure um endereço IP virtual para administração do cluster com o Hawk2. (Usaremos esse recurso de IP virtual para testar o failover bem-sucedido mais adiante.)

    1. Pressione y para confirmar que você deseja configurar um endereço IP virtual.

    2. Digite um endereço IP não utilizado que você deseja usar como o IP de administração no Hawk2: 192.168.2.1

      Em vez de efetuar login em um nó de cluster individual com o Hawk2, você pode se conectar ao endereço IP virtual.

Por fim, o script iniciará o serviço Pacemaker para colocar o cluster online e habilitar o Hawk2. O URL a ser usado no Hawk2 é exibido na tela.

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

Procedimento 3: Efetuando login na interface da Web do Hawk2
  1. Em qualquer máquina, inicie um browser da Web e verifique se o JavaScript e os cookies estão habilitados.

  2. Como URL, digite o endereço IP ou nome de host de qualquer nó do cluster que executa o serviço Web Hawk. Se preferir, digite o endereço IP virtual que foi configurado na Passo 5 do Procedimento 2, “Configurando o primeiro nó (alice) com crm cluster init:

    https://HAWKSERVER:7630/
    Nota
    Nota: Aviso de certificado

    Se um aviso de certificado for exibido quando você tentar acessar o URL pela primeira vez, um certificado autoassinado estará em uso. Os certificados autoassinados não são considerados confiáveis por padrão.

    Solicite ao operador do cluster os detalhes do certificado para verificá-lo.

    Para continuar mesmo assim, você pode adicionar uma exceção ao browser para ignorar o aviso.

  3. Na tela de login do Hawk2, digite o Nome de usuário e a Senha do usuário que foi criado durante o procedimento de boot (usuário hacluster, senha linux).

    Importante
    Importante: Senha segura

    Substitua a senha padrão por uma segura assim que possível:

    root # passwd hacluster
  4. Clique em Efetuar Login. Após o login, a interface da Web do Hawk2 mostrará a tela Status por padrão, exibindo o status atual do cluster imediatamente:

    Status do cluster de um nó no Hawk2
    Figura 1: Status do cluster de um nó no Hawk2

7 Adicionando o segundo nó

Se você tem um cluster de um nó ativo em execução, adicione o segundo nó do cluster com o script de boot crm 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 crm 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.

Procedimento 4: Adicionando o segundo nó (bob) com crm cluster join
  1. Efetue login como root na máquina virtual ou física que deve se unir ao cluster.

  2. Inicie o script de boot executando:

    root # crm cluster join

    Se o NTP não foi configurado para ser iniciado no momento da inicialização, uma mensagem é exibida. O script também verifica se há um dispositivo de watchdog de hardware (que é importante se você deseja configurar o SBD). Você receberá um aviso se não houver nenhum.

  3. Se você continuar mesmo assim, será solicitado a digitar o endereço IP de um nó existente. Digite o endereço IP do primeiro nó (alice, 192.168.1.1).

  4. Se você ainda não configurou o acesso SSH sem senha entre as duas máquinas, será solicitado a digitar a senha de root do nó existente.

    Após efetuar login no nó especificado, o script copiará a configuração do Corosync, definirá o SSH e o Csync2 e colocará a máquina atual online como o novo nó do cluster. Além disso, ele iniciará o serviço necessário no Hawk2.

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”).

Status do cluster de dois nós
Figura 2: Status do cluster de dois nós

8 Testando o cluster

A Seção 8.1, “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 integralmente de acordo com seus casos de uso ou usando o script ha-cluster-preflight-check.

8.1 Testando o failover de recursos

Como um teste rápido, o procedimento a seguir verifica os failovers de recursos:

Procedimento 5: Testando o failover de recursos
  1. Abra um terminal e execute o ping de 192.168.2.1, seu endereço IP virtual:

    root # ping 192.168.2.1
  2. Efetue login no seu cluster conforme descrito no Procedimento 3, “Efetuando login na interface da Web do Hawk2”.

  3. No Hawk2, Status ›  Recursos , verifique em qual nó o endereço IP virtual (recurso admin_addr) está sendo executado. Consideramos que o recurso esteja sendo executado em alice.

  4. Coloque alice no modo Standby (consulte a Figura 3, “Nó alice no modo standby”).

    Nó alice no modo standby
    Figura 3: alice no modo standby
  5. Clique em Status ›  Recursos. O recurso admin_addr foi migrado para bob.

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 CtrlC .

8.2 Testando com o comando ha-cluster-preflight-check

O comando ha-cluster-preflight-check executa testes padronizados para um cluster. Ele aciona falhas no cluster e verifica a configuração para localizar problemas. Antes de usar seu cluster na produção, é recomendável usar esse comando para verificar se tudo funciona conforme o esperado.

O comando suporta as seguintes verificações:

  • Verificação de ambiente -e/--env-check Esse teste verifica:

    • Os nomes de host podem ser resolvidos?

    • O serviço de horário está habilitado e foi iniciado?

    • O nó atual tem um watchdog configurado?

    • O serviço firewalld foi iniciado e as portas relacionadas do cluster estão abertas?

  • Verificação de estado do cluster -c/--cluster-check Verifica estados e serviços diferentes do cluster. Esse teste verifica:

    • Os serviços do cluster (Pacemaker/Corosync) estão habilitados e em execução?

    • O STONITH está habilitado? Ele também verifica se os recursos relacionados ao STONITH estão configurados e foram iniciados. Se você configurou o SBD, o serviço SBD foi iniciado?

    • O cluster tem um quorum? Mostra os nós DC atuais e os nós que estão online, offline e sujos.

    • Iniciamos, paramos ou falhamos os recursos?

  • Verificação split brain --split-brain-iptables Simula um cenário de split brain bloqueando a porta do Corosync. Verifica se um nó pode ser delimitado conforme o esperado.

  • Elimina os daemons do SBD, Corosync e Pacemaker -kill-sbd/-kill-corosync/-kill-pacemakerd Após a execução desse tipo de teste, você encontrará um relatório em /var/lib/ha-cluster-preflight-check. O relatório inclui a descrição do caso de teste, o registro de ações e explica os resultados possíveis.

  • Verificação de delimitação de nó --fence-nodeDelimita o nó específico passado pela linha de comando.

Por exemplo, para testar o ambiente, execute:

root # crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

root # ha-cluster-preflight-check -e
[2020/03/20 14:40:45]INFO: Checking hostname resolvable [Pass]
[2020/03/20 14:40:45]INFO: Checking time service [Fail]
 INFO: chronyd.service is available
 WARNING: chronyd.service is disabled
 WARNING: chronyd.service is not active
[2020/03/20 14:40:45]INFO: Checking watchdog [Pass]
[2020/03/20 14:40:45]INFO: Checking firewall [Fail]
 INFO: firewalld.service is available
 WARNING: firewalld.service is not active

Você pode inspecionar o resultado no /var/log/ha-cluster-preflight-check.log.

9 Para obter mais informações

Há mais documentação para este produto disponível em https://documentation.suse.com/sle-ha/. Para ver outras tarefas de configuração e de administração, consulte o Guia de Administração completo.

10 Informações legais

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.) indicam as marcas registradas da SUSE e de 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.