documentation.suse.com / Instalando um cluster básico de três nós de alta disponibilidade
SUSE Linux Enterprise High Availability 16.0

Instalando um cluster básico de três nós de alta disponibilidade

Data de Publicação: 03/11/2025
O QUE É?

Como configurar um cluster básico de três nós de alta disponibilidade com SBD sem disco e um watchdog de software.

POR QUÊ?

Você pode usar esse cluster para fins de teste ou como uma configuração de cluster mínima que pode ser estendida no futuro.

DEDICAÇÃO

A configuração de um cluster básico de alta disponibilidade leva cerca de 15 minutos, dependendo da velocidade da sua conexão de rede.

META

Comece a usar o SUSE Linux Enterprise High Availability de forma rápida e fácil.

1 Cenário de uso

 

Este guia descreve a configuração de um cluster mínimo de alta disponibilidade com as seguintes propriedades:

  • Três nós de cluster com acesso SSH sem senha entre eles. São necessários três nós nessa configuração para o SBD sem disco lidar com os cenários de split brain sem a ajuda do QDevice.

  • Um endereço IP virtual flutuante para que os clientes se conectem à ferramenta de gerenciamento gráfico Hawk, seja qual for o nó em que o serviço é executado.

  • Um SBD (STONITH Block Device) sem disco e um watchdog de software usado como mecanismo de fencing de nó para evitar cenários de split brain.

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

Esta é uma configuração de cluster simples com requisitos externos mínimos. Você pode usar esse cluster para fins de teste ou como uma configuração de cluster básica que pode ser estendida para um ambiente de produção no futuro.

2 Visão geral da instalação

 

Para instalar o cluster de alta disponibilidade descrito na Seção 1, “Cenário de uso”, você deve executar as seguintes tarefas:

  1. Revise a Seção 3, “Requisitos do sistema” para garantir que você tenha tudo o que precisa.

  2. Instale o SUSE Linux Enterprise High Availability nos nós do cluster seguindo a Seção 4, “Habilitando a extensão de alta disponibilidade”.

  3. Inicialize o cluster no primeiro nó de acordo com a Seção 5, “Configurando o primeiro nó”.

  4. Consulte a Seção 6, “Adicionando o segundo e o terceiro nós” para adicionar outros nós ao cluster.

  5. Faça login na interface da Web do Hawk para monitorar o cluster seguindo a Seção 7, “Fazendo login no Hawk”.

  6. Execute testes básicos para garantir que o cluster funcione conforme o esperado. Consulte a Seção 8, “Testando o cluster”.

  7. Leia a Seção 9, “Próximas etapas” para obter orientação de como expandir o cluster para um ambiente de produção.

3 Requisitos do sistema

 

Esta seção descreve os requisitos do sistema para configuração mínima do SUSE Linux Enterprise High Availability.

3.1 Requisitos de hardware

 
Servidores

Três servidores para atuar como nós do cluster.

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.

Consulte a seção System Requirements em https://www.suse.com/download/sle-ha/ para obter mais detalhes sobre o hardware do servidor.

Placas de interface de rede (NICs, Network Interface Cards)

Pelo menos duas NICs por nó do cluster. Dessa forma, você pode configurar dois ou mais canais de comunicação para o cluster, usando um dos seguintes métodos:

  • Combinar as NICs em um vínculo de rede (preferencial). Nesse caso, você deve configurar o dispositivo vinculado em cada nó antes de inicializar o cluster.

  • Criar um segundo canal de comunicação no Corosync. O script de configuração do cluster pode configurá-lo. Nesse caso, as duas NICs devem estar em sub-redes diferentes.

STONITH (fencing de nó)

Para serem compatíveis, todos os clusters SUSE Linux Enterprise High Availability devem ter pelo menos um dispositivo de fencing de nó (STONITH) para evitar cenários de split brain. Ele pode ser um dispositivo físico (interruptor) ou um SBD (STONITH Block Device) em combinação com um watchdog. O SBD pode ser usado com armazenamento compartilhado ou no modo sem disco.

A configuração mínima descrita neste guia usa um watchdog de software e um SBD sem disco, portanto, nenhum hardware adicional é necessário. Antes de usar esse cluster em um ambiente de produção, substitua o watchdog de software por um de hardware.

3.2 Requisitos de software

 
Sistema operacional

Todos os nós devem ter o SUSE Linux Enterprise Server instalado e registrado.

Extensão de alta disponibilidade

A SUSE Linux Enterprise High Availability Extension requer um código de registro adicional.

É possível habilitar essa extensão durante a instalação do SLES, ou posteriormente em um sistema em execução. Este guia explica como habilitar e registrar a extensão em um sistema em execução.

3.3 Requisitos de rede

 
Sincronização de Horário

Todos os sistemas devem ser sincronizados com um servidor NTP fora do cluster. O SUSE Linux Enterprise Server usa o chrony para NTP. Ao inicializar o cluster, você receberá um aviso caso o chrony não esteja em execução.

Mesmo que os nós estejam sincronizados, ainda poderá ser difícil analisar os arquivos de registro e os relatórios do cluster se os nós tiverem fusos horários diferentes configurados.

Nome de host e endereço IP

Todos os nós do cluster devem conseguir encontrar uns aos outros pelo nome. Use os seguintes métodos para obter uma resolução de nomes confiável:

  • Use endereços IP estáticos.

  • Liste todos os nós no arquivo /etc/hosts com os endereços IP, o FQDN e o nome de host abreviado.

Apenas o endereço IP principal é suportado em cada NIC.

SSH

Todos os nós do cluster devem ser capazes de acessar uns aos outros por SSH. Algumas operações de cluster também exigem autenticação SSH sem senha. Quando você inicializa o cluster, o script de configuração verifica as chaves SSH existentes e as gera, se não existirem.

Importante
Importante: Acesso por SSH de root no SUSE Linux Enterprise 16

No SUSE Linux Enterprise 16, o login por SSH de root com senha está desabilitado por padrão.

Em cada nó, crie um usuário com privilégios de sudo ou configure a autenticação SSH sem senha para o usuário root antes de inicializar o cluster.

Se você inicializar o cluster com um usuário sudo, alguns comandos crmsh também precisarão de permissão de sudo sem senha.

4 Habilitando a extensão de alta disponibilidade

 

Este procedimento explica como instalar o SUSE Linux Enterprise High Availability em um SUSE Linux Enterprise Server existente. Você pode ignorar esse procedimento se já tiver instalado a extensão e os pacotes de alta disponibilidade durante a instalação do SLES com o Agama.

Requisitos
 

  • O SUSE Linux Enterprise Server é instalado e registrado no SUSE Customer Center.

  • Você tem um código de registro adicional para o SUSE Linux Enterprise High Availability.

Execute este procedimento em todas as máquinas que pretende usar como nós do cluster:

  1. Faça login como usuário root ou como usuário com privilégios de sudo.

  2. Verifique se a extensão de alta disponibilidade já está habilitada: 

    > sudo SUSEConnect --list-extensions

  3. Verifique se os pacotes de alta disponibilidade já estão instalados: 

    > zypper search ha_sles

  4. Habilite a SUSE Linux Enterprise High Availability Extension: 

    > sudo SUSEConnect -p sle-ha/16.0/x86_64 -r HA_REGCODE

  5. Instale os pacotes de alta disponibilidade:

    > sudo zypper install -t pattern ha_sles

5 Configurando o primeiro nó

 

O SUSE Linux Enterprise High Availability inclui scripts de configuração para simplificar a instalação do cluster. Para configurar o cluster no primeiro nó, use o script crm cluster init.

5.1 Visão geral do script crm cluster init

 

O comando crm cluster init inicia um script que define os parâmetros básicos necessários para comunicação do cluster, resultando em um cluster de um nó em execução.

O script verifica e configura os seguintes componentes:

NTP

Verifica se o chrony está configurado para ser iniciado no momento da inicialização. Do contrário, será exibida uma mensagem.

SSH

Detecta ou gera chaves SSH para login sem senha entre os nós do cluster.

Firewall

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

Csync2

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

Corosync

Configura o sistema de comunicação do cluster.

SBD/watchdog

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

Administração de cluster do Hawk

Habilita o serviço Hawk e exibe o URL para a interface da Web do Hawk.

IP flutuante virtual

Pergunta se é para configurar um endereço IP virtual para a interface da Web do Hawk.

QDevice/QNetd

Pergunta se é para configurar o QDevice e o QNetd para participar das decisões de quorum. Isso é recomendado para clusters com um número par de nós, principalmente para clusters de dois nós.

Nota
Nota: Configurações padrão do Pacemaker

As opções definidas pelo script crm cluster init podem não ser iguais às configurações padrão do Pacemaker. Você pode verificar as configurações que o script mudou em /var/log/crmsh/crmsh.log. As opções definidas durante o processo de inicialização podem ser modificadas mais tarde com o crmsh.

Nota
Nota: Configuração de cluster para plataformas diferentes

O script crm cluster init detecta o ambiente do sistema (por exemplo, Microsoft Azure) e ajusta determinadas configurações do cluster com base no perfil desse ambiente. Para obter mais informações, consulte o arquivo /etc/crm/profiles.yml.

5.2 Inicializando o cluster no primeiro nó

 

Configure o cluster no primeiro nó com o script crm cluster init. O script solicita informações básicas sobre o cluster e define as configurações e os serviços necessários. Para obter mais informações, execute o comando crm cluster init --help.

Requisitos
 

  • O SUSE Linux Enterprise High Availability está instalado e atualizado.

  • Todos os nós têm pelo menos duas interfaces de rede ou um vínculo de rede, com os endereços IP estáticos listados no arquivo /etc/hosts junto com o FQDN e o nome de host abreviado de cada nó.

Execute este procedimento apenas em um nó:

  1. Faça login no primeiro nó como usuário root ou como usuário com privilégios de sudo.

  2. Inicie o script crm cluster init: 

    > sudo crm cluster init

    O script verifica se o chrony está em execução, abre as portas de firewall necessárias, configura o Csync2 e confere as chaves SSH. Se não houver chaves SSH disponíveis, o script vai gerá-las.

  3. Configure o Corosync para comunicação com o cluster:

    1. Insira um endereço IP para o primeiro canal de comunicação (ring0). Por padrão, o script propõe o endereço da primeira interface de rede disponível. Pode ser uma interface individual ou um dispositivo vinculado. Aceite esse endereço ou insira um diferente.

    2. Se o script detectar várias interfaces de rede, ele perguntará se você deseja configurar um segundo canal de comunicação (ring1). Se você configurou o primeiro canal com um dispositivo vinculado, pode recusar com n. Se você precisar configurar um segundo canal, confirme com y e insira o endereço IP de outra interface de rede. As duas interfaces devem estar em sub-redes diferentes.

    O script configura as portas de firewall padrão para comunicação com o Corosync.

  4. Escolha se deseja configurar o SBD como mecanismo de fencing de nó:

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

    2. Quando for solicitado o caminho para um dispositivo de blocos, insira none para configurar o SBD sem disco.

    O script configura o SBD, incluindo as definições de tempo de espera relevantes. Ao contrário do SBD baseado em disco, o SBD sem disco não exige um recurso de cluster STONITH.

    Se não houver um watchdog de hardware disponível, o script vai configurar o watchdog de software softdog.

  5. Configure um endereço IP virtual para administração do cluster com a interface da Web do Hawk:

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

    2. Insira um endereço IP não usado para definir como o IP de administração do Hawk.

    Em vez de fazer login no Hawk em um nó de cluster individual, você pode se conectar ao endereço IP virtual.

  6. Escolha se você deseja configurar o QDevice e o QNetd:

    Para a configuração mínima descrita neste documento, insira n para recusar.

O script inicia os serviços do cluster para colocar o cluster online e habilitar o Hawk. O URL que será usado no Hawk é exibido na tela. Você também pode verificar o status do cluster com o comando crm status.

Importante
Importante: Senha segura para hacluster

O script crm cluster init cria um usuário e uma senha padrão do cluster. Substitua a senha padrão por uma segura assim que possível: 

> sudo passwd hacluster

6 Adicionando o segundo e o terceiro nós

 

Adicione outros nós ao cluster com o script crm cluster join. 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 mais informações, execute o comando crm cluster join --help.

Requisitos
 

  • O SUSE Linux Enterprise High Availability está instalado e atualizado.

  • Já existe um cluster executado em pelo menos um nó.

  • Todos os nós têm pelo menos duas interfaces de rede ou um vínculo de rede, com os endereços IP estáticos listados no arquivo /etc/hosts junto com o FQDN e o nome de host abreviado de cada nó.

  • Se você fizer login como usuário sudo: O mesmo usuário deverá existir em todos os nós. Esse usuário deverá ter permissão de sudo sem senha.

  • Se você fizer login como usuário root: A autenticação SSH sem senha deverá ser configurada em todos os nós.

Execute este procedimento em cada nó adicional:

  1. Faça login nesse nó como o mesmo usuário com o qual você configurou o primeiro nó.

  2. Inicie o script crm cluster join:

    • Se você configurar o primeiro nó como root, poderá iniciar o script sem parâmetros adicionais: 

      # crm cluster join

    • Se você configurar o primeiro nó como um usuário sudo, deverá especificar esse usuário com a opção -c: 

      > sudo crm cluster join -c USER@NODE1

    O script verifica se o chrony está em execução, abre as portas de firewall necessárias e configura o Csync2.

  3. Se você ainda não especificou o primeiro nó com -c, é solicitado o endereço IP ou o nome de host dele.

  4. Se você ainda não configurou a autenticação SSH sem senha entre os nós, são solicitadas as senhas de cada um dos nós existentes.

  5. Configure o Corosync para comunicação com o cluster:

    1. O script propõe um endereço IP para ring0. Esse endereço IP deve estar na mesma sub-rede que o endereço IP usado para ring0 no primeiro nó. Se não estiver, insira o endereço IP correto.

    2. Se o cluster tiver dois canais de comunicação do Corosync configurados, o script solicitará um endereço IP para ring1. Esse endereço IP deve estar na mesma sub-rede que o endereço IP usado para ring1 no primeiro nó.

O script copia a configuração do cluster do primeiro nó, ajusta as configurações de tempo de espera para considerar o novo nó e coloca o novo nó online.

Você pode verificar o status do cluster com o comando crm status.

Importante
Importante: Senha segura para hacluster

O script crm cluster join cria um usuário e uma senha padrão do cluster. Em cada nó, substitua a senha padrão por uma segura assim que possível: 

> sudo passwd hacluster

7 Fazendo login no Hawk

 

O Hawk permite monitorar e administrar um cluster de alta disponibilidade usando um navegador da Web gráfico. Você também pode configurar um endereço IP virtual que permite aos clientes se conectarem ao Hawk, seja qual for o nó em que ele está em execução.

Requisitos
 

  • A máquina cliente deve conseguir se conectar aos nós do cluster.

  • A máquina cliente deve ter um navegador da Web gráfico com JavaScript e cookies habilitados.

Você pode executar este procedimento em qualquer máquina que tenha conexão com os nós do cluster:

  1. Inicie um navegador da Web e insira este URL: 

    https://HAWKSERVER:7630/

    Substitua HAWKSERVER pelo endereço IP ou nome de host de um nó do cluster, ou pelo endereço IP virtual do Hawk, se foi configurado um.

    Nota
    Nota: Aviso de certificado

    Se um aviso de certificado for exibido quando você acessar o URL pela primeira vez, um certificado autoassinado estará em uso. 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.

  2. Na tela de login do Hawk, insira o Nome de usuário e a Senha do usuário hacluster.

  3. Clique em Entrar. Por padrão, a interface da Web do Hawk mostra a tela Status.

A tela Status mostra um recurso configurado: o endereço IP virtual admin-ip executado em um nó chamado alice.
Figura 1: Tela Status do Hawk
 

8 Testando o cluster

 

Os testes a seguir podem ajudar você a identificar problemas básicos na configuração do cluster. No entanto, um teste realista envolve casos de uso e cenários específicos. Antes de usar o cluster em um ambiente de produção, teste-o completamente de acordo com os seus casos de uso.

8.1 Testando o failover de recursos

 

Verifique se o cluster move recursos para outro nó caso o nó atual esteja definido como standby. Este procedimento usa nós de exemplo chamados alice e bob, e um recurso IP virtual chamado admin-ip com o endereço IP de exemplo 192.168.1.10.

  1. Abra dois terminais.

  2. No primeiro terminal, faça ping do endereço IP virtual: 

    > ping 192.168.1.10

  3. No segundo terminal, faça login em um dos nós do cluster.

  4. Verifique em qual nó o endereço IP virtual está em execução: 

    > sudo crm status
[..]
Node List:
  * Online: [ alice bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started alice

  5. Defina o modo de alice como standby: 

    > sudo crm node standby alice

  6. Verifique o status do cluster novamente. O recurso admin-ip deve ter migrado para bob: 

    > sudo crm status
[...]
Node List:
  * Node alice: standby
  * Online: [ bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started bob

  7. No primeiro terminal, você deve ver um fluxo contínuo de pings para o endereço IP virtual durante a migração. Isso mostra que a configuração do cluster e o endereço IP flutuante funcionam corretamente.

  8. Cancele o comando ping com Ctrl–C.

  9. No segundo terminal, coloque alice novamente online: 

    > sudo crm node online alice

8.2 Testando falhas do cluster

 

O comando crm cluster crash_test simula falhas do cluster e relata os resultados.

O comando suporta as seguintes verificações:

--split-brain-iptables

Simula um cenário de split brain bloqueando a porta do Corosync e verifica se é possível fazer fencing do nó conforme o esperado. Você deve instalar o pacote iptables antes de executar este teste.

--kill-sbd/--kill-corosync/--kill-pacemakerd

Encerra os daemons do SBD, Corosync ou Pacemaker. Após executar um desses testes, você encontrará um relatório no diretório /var/lib/crmsh/crash_test/. O relatório inclui a descrição de um caso de teste, o registro das ações e uma explicação dos possíveis resultados.

--fence-node NODE

Delimita o nó específico passado pela linha de comando.

Para obter mais informações, execute o comando crm cluster crash_test --help.

O exemplo a seguir usa os nós chamados alice e bob, e testa o fencing de bob. Para observar a mudança de status de bob durante o teste, você pode fazer login no Hawk e navegar até Status › Nós.

Exemplo 1: Testando o cluster: fencing de nó
 
> sudo crm status
[...]
Node List:
  * Online: [ alice bob ]

Active Resources:
  * admin-ip     (ocf:heartbeat:IPaddr2):    Started alice

> sudo crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     95

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 71s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

9 Próximas etapas

 

Este guia descreve um cluster básico de alta disponibilidade que pode ser usado para fins de teste. Para expandir esse cluster para uso em ambientes de produção, mais etapas são recomendadas:

Adicionando mais nós

Adicione outros nós ao cluster usando o script crm cluster join.

Habilitando um watchdog de hardware

Antes de usar o cluster em um ambiente de produção, substitua softdog por um watchdog de hardware.

Adicionando outros dispositivos STONITH

Para cargas de trabalho críticas, é altamente recomendável ter dois ou três dispositivos STONITH, usar dispositivos STONITH físicos ou SBD baseado em disco.

Configurando o QDevice

O QDevice e o QNetD participam das decisões de quorum. Com a ajuda do arbitrador QNetD, o QDevice fornece um número configurável de votos. Isso permite que os clusters suportem mais falhas de nós do que o permitido pelas regras de quorum padrão. É recomendado implantar o QDevice e o QNetd em clusters com um número par de nós, principalmente em clusters de dois nós.