SUSE Linux Enterprise High Availability Extension 15 SP5

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.

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 registradas de terceiros pertencem aos 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.

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.1.10) que permite aos clientes se conectarem ao serviço independentemente do nó em que ele está sendo executado. Esse endereço IP é usado para conexão com a ferramenta de gerenciamento gráfico Hawk2.
Um dispositivo de armazenamento compartilhado usado como mecanismo de fencing SBD. Isso evita cenários split-brain.
Failover de recursos de um nó para outro em caso de falha no host ativo (configuração ativo/passivo).

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, consulte o Administration Guide para modificar o cluster 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

Um dispositivo de fencing de nó (STONITH) para evitar cenários split-brain. Ele pode ser um dispositivo físico (interruptor) ou um mecanismo como SBD (STONITH por disco) em combinação com um watchdog. O SBD pode ser usado com armazenamento compartilhado ou no modo sem disco. Este documento descreve o uso do SBD com armazenamento compartilhado. Os seguintes requisitos devem ser atendidos:

Um dispositivo de armazenamento compartilhado. Para obter informações sobre como configurar o armazenamento compartilhado, consulte Storage Administration Guide for SUSE Linux Enterprise Server. Se você precisa apenas de armazenamento compartilhado básico para fins de teste, consulte o Apêndice A, Armazenamento iSCSI básico para SBD.
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 mais informações sobre o STONITH, consulte o Chapter 12, Fencing and STONITH. Para obter mais informações sobre o SBD, consulte o Chapter 13, Storage protection and SBD.

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 SP5
Server Applications Module 15 SP5
SUSE Linux Enterprise High Availability Extension15 SP5

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 Administration Guide for SUSE Linux Enterprise Server 15 SP5.

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.
Apenas o endereço IP principal é suportado.
Liste todos os nós do cluster no arquivo /etc/hosts com os respectivos nomes 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 mais nós ao cluster.
Com o crm cluster remove, remova 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 o 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

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

SSH

Cria chaves SSH para login sem senha entre os nós 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ó.

IP flutuante virtual

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

Firewall

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 Geográficos. Geralmente, o nome do cluster reflete a localização e facilita distinguir um site dentro de um cluster Geográfico.

QDevice/QNetd

Pergunta se você deseja configurar o QDevice/QNetd para participar das decisões de quorum. Recomendamos o uso do QDevice e do QNetd para clusters com um número par de nós e, especialmente, para clusters de dois nós.

Essa configuração não é abordada aqui, mas você pode defini-la posteriormente, conforme descrito no Chapter 14, QDevice and QNetd.

4 Instalando os pacotes de alta disponibilidade #

Os pacotes para configurar e gerenciar um cluster estão incluídos no padrão de instalação High Availability. Esse padrão só estará disponível após a instalação da SUSE Linux Enterprise High Availability Extension.

Você pode se registrar no SUSE Customer Center e instalar a High Availability Extension durante ou após a instalação do SUSE Linux Enterprise Server. Para obter mais informações, consulte o Deployment Guide para SUSE Linux Enterprise Server.

Procedimento 1: Instalando o padrão High Availability #

Instale o padrão de Alta Disponibilidade pela linha de comando:
```
# zypper install -t pattern ha_sles
```
Instale o padrão High Availability em todas as máquinas que farão parte do cluster.
Nota: Instalando pacotes de software em todos os nós
Para uma instalação automatizada do SUSE Linux Enterprise Server 15 SP5 e da High Availability Extension, use o AutoYaST para clonar os nós existentes. Para obter mais informações, consulte o Section 3.2, “Mass installation and deployment with AutoYaST”.

5 Usando o SBD para fencing de nó #

Antes de configurar o SBD com o script de boot, você deve habilitar um watchdog em cada nó. O SUSE Linux Enterprise Server é fornecido com vários módulos de kernel que incluem drivers 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 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.

Procedimento 2: Habilitando o watchdog do softdog para SBD #

Em cada nó, habilite o watchdog do softdog:

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

Teste se o módulo softdog foi carregado corretamente:
```
# lsmod | grep dog
softdog           16384  1
```

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 3: Configurando o primeiro nó (alice) com crm cluster init #

Efetue login no primeiro nó do cluster como root ou como um usuário com privilégios sudo.
Importante: Acesso de chave SSH do usuário sudo
O cluster usa o acesso SSH sem senha para comunicação entre os nós. O script crm cluster init verifica as chaves SSH e as gera caso não existam.
Se você pretende configurar o primeiro nó como um usuário com privilégios sudo, verifique se as chaves SSH do usuário existem (ou serão geradas) localmente no nó, e não em um sistema remoto.
Inicie o script de boot:
```
# 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 Geográfico no futuro, pois ele simplifica a identificação de um site.
Se você precisa usar 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. Se necessário, ele gera as chaves SSH públicas e privadas usadas para acesso SSH e sincronização Csync2 e inicia os respectivos serviços.
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.
Configure o SBD como mecanismo de fencing de nó:
1. Pressione y para confirmar que você deseja usar o SBD.
2. Insira um caminho persistente para a partição do dispositivo de blocos que você deseja usar para o SBD. O caminho deve ser consistente em todos os nós no cluster.
  O script cria uma pequena partição no dispositivo a ser usada para o SBD.
Configure um endereço IP virtual para administração do cluster com o Hawk2:
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.1.10
  Em vez de efetuar login em um nó de cluster individual com o Hawk2, você pode se conectar ao endereço IP virtual.
Escolha se deseja configurar o QDevice e o QNetd. Para a configuração mínima descrita neste documento, use o comando n para recusar por enquanto. Você pode configurar o QDevice e o QNetd posteriormente, conforme descrito no Chapter 14, QDevice and QNetd.

Por fim, o script iniciará os serviços do cluster para colocá-lo 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 4: Efetuando login na interface da Web do Hawk2 #

Em qualquer máquina, inicie um browser da Web e verifique se o JavaScript e os cookies estão habilitados.
Como URL, digite o endereço IP virtual que você configurou com o script de boot:
```
https://192.168.1.10:7630/
```
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.
Na tela de login do Hawk2, digite o Nome de usuário e a Senha do usuário que foi criado pelo script de boot (usuário hacluster, senha linux).
Importante: Senha segura
Substitua a senha padrão por uma segura assim que possível:
```
# passwd hacluster
```
Clique em Efetuar Login. A interface da Web do Hawk2 mostra a tela Status por padrão:
Figura 1: Status do cluster de um nó no Hawk2 #

7 Adicionando o segundo nó #

Adicione um segundo nó ao cluster com o script de boot 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, consulte a página de manual de crm cluster join.

Procedimento 5: Adicionando o segundo nó (bob) com crm cluster join #

Efetue login no segundo nó como root ou como um usuário com privilégios sudo.
Inicie o script de boot:
Se você configurar o primeiro nó como root, poderá executar este comando 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@alice
```
Se o NTP não está configurado para ser iniciado no momento da inicialização, uma mensagem é exibida. O script também verifica se há um dispositivo watchdog de hardware. Você receberá um aviso se não houver nenhum.
Se você ainda não especificou alice com -c, será solicitado o endereço IP do primeiro nó.
Se você ainda não configurou o acesso SSH sem senha entre as duas máquinas, será solicitado a digitar a senha do primeiro nó.
Após efetuar login no nó especificado, o script copiará a configuração do Corosync, definirá o SSH e o Csync2, colocará a máquina atual online como um novo nó do cluster e iniciará o serviço necessário para o Hawk2.

Verifique o status do cluster no Hawk2. Em Status › Nós, você deve ver dois nós com um status verde:

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

8 Testando o cluster #

Os testes a seguir podem ajudar você a identificar problemas com a 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.

O comando sbd -d DEVICE_NAME list lista todos os nós visíveis ao SBD. Para a configuração descrita neste documento, a saída deve mostrar alice e bob.
A Seção 8.1, “Testando o failover de recursos” apresenta um teste simples para verificar se o cluster move o endereço IP virtual para o outro nó caso o nó que atualmente executa o recurso esteja definido como standby.
A Seção 8.2, “Testando com o comando crm cluster crash_test” simula falhas de cluster e gera um relatório dos resultados.

8.1 Testando o failover de recursos #

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

Procedimento 6: Testando o failover de recursos #

Abra um terminal e execute o ping de 192.168.1.10, seu endereço IP virtual:
```
# ping 192.168.1.10
```
Efetue login no Hawk2.
Em Status › Recursos, verifique em qual nó o endereço IP virtual (recurso admin_addr) está sendo executado. Esse procedimento pressupõe que o recurso esteja sendo executado em alice.
Coloque alice no modo Standby:
Figura 3: Nó alice no modo standby #
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 Ctrl– C.

8.2 Testando com o comando `crm cluster crash_test` #

O comando crm cluster crash_test aciona falhas do cluster para detectar 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:

--split-brain-iptables: Simula um cenário split-brain bloqueando a porta do Corosync. Verifica se um nó pode ser delimitado conforme o esperado.
--kill-sbd/--kill-corosync/--kill-pacemakerd: Elimina os daemons do SBD, Corosync e Pacemaker. Após executar um desses testes, você encontrará um relatório no diretório /var/lib/crmsh/crash_test/. O relatório inclui uma descrição do caso de teste, um 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, consulte a crm cluster crash_test --help.

Exemplo 1: Testando o cluster: fencing de nó #

# 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

# crm cluster crash_test --fence-node bob

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

!!! 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 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Para observar a mudança de status de bob durante o teste, efetue login no Hawk2 e navegue até Status › Nós.

9 Próximas etapas #

Os scripts de boot são um meio rápido para configurar um cluster de Alta Disponibilidade básico que pode ser usado para fins de teste. No entanto, para expandir esse cluster em um cluster de Alta Disponibilidade funcional que possa ser usado em ambientes de produção, são recomendadas mais etapas.

Etapas recomendadas para concluir a configuração do cluster de alta disponibilidade #

Adicionando mais nós

Adicione mais nós ao cluster usando um dos seguintes métodos:

Para nós individuais, use o script crm cluster join conforme descrito na Seção 7, “Adicionando o segundo nó”.
Para instalação em massa de vários nós, use o AutoYaST conforme descrito no Section 3.2, “Mass installation and deployment with AutoYaST”.

Um cluster regular pode conter até 32 nós. Com o serviço pacemaker_remote, os clusters de Alta Disponibilidade podem ser estendidos para incluir nós adicionais além desse limite. Consulte o Pacemaker Remote Quick Start para obter mais detalhes.

Configurando o QDevice

Se o cluster tem um número par de nós, configure o QDevice e o QNetd para participar das decisões de quorum. O QDevice oferece um número configurável de votos, permitindo que um cluster suporte mais falhas de nó do que o permitido pelas regras de quorum padrão. Para obter os detalhes, consulte o Chapter 14, QDevice and QNetd.

Habilitando um watchdog de hardware

Antes de usar o cluster em um ambiente de produção, substitua o módulo softdog pelo módulo mais adequado ao seu hardware. Para obter os detalhes, consulte o Section 13.6, “Setting up the watchdog”.

10 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 Administration Guide completo.