Ir para o conteúdo
documentation.suse.com / Inicialização Rápida do Geo Clustering
SUSE Linux Enterprise High Availability 15 SP6

Inicialização Rápida do Geo Clustering

Data de Publicação: 12 de dezembro de 2024

O Geo Clustering protege as cargas de trabalho nos data centers distribuídos globalmente. Este documento orienta você na configuração básica de um cluster Geográfico usando os scripts de boot Geo incluídos no crm shell.

Copyright © 2006-2024 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 https://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 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 Visão geral conceitual

Os clusters Geográficos baseados no SUSE® Linux Enterprise High Availability podem ser considerados clusters sobrepostos, em que cada site do cluster corresponde a um nó em um cluster tradicional. O cluster sobreposto é administrado pelo gerenciador de tickets de cluster de booth (mencionado a seguir como booth). Cada uma das partes envolvidas em um cluster Geográfico executa um serviço, o boothd. Ele se conecta aos daemons de booth executados em outros sites e troca detalhes de conectividade. Para tornar os recursos de cluster altamente disponíveis em todos os sites, o booth usa como base objetos do cluster denominados tickets. Um ticket concede o direito de executar determinados recursos em um site de cluster específico. O booth garante que cada ticket seja concedido a, no máximo, um site por vez.

Se a comunicação entre duas instâncias de booth falhar, talvez seja por causa de uma queda na rede entre os sites do cluster ou uma interrupção de um site do cluster. Neste caso, é necessária uma instância adicional (um terceiro site do cluster ou um arbitrator) para chegar a um consenso sobre as decisões (por exemplo, failover de recursos em todos os sites). Arbitradores são máquinas únicas (fora dos clusters) que executam uma instância de booth em um modo especial. Cada cluster Geográfico pode ter um ou vários arbitradores.

Cluster de dois sites — 2x2 nós + arbitrador (opcional)
Figura 1: Cluster de dois sites — 2x2 nós + arbitrador (opcional)

É possível também executar um cluster Geográfico de dois sites sem um arbitrador. Nesse caso, um administrador de cluster Geográfico precisa gerenciar manualmente os tickets. Se for necessário conceder um ticket a mais de um site ao mesmo tempo, o booth exibirá um aviso.

Para obter mais detalhes sobre o conceito, os componentes e o gerenciamento de tickets usados para clusters Geográficos, consulte o Book “Administration Guide”.

2 Cenário de uso

Os procedimentos neste documento orientam em relação a um cluster Geográfico básico com dois sites e um arbitrador:

  • Vamos supor que os nomes dos sites do cluster são amsterdam e berlin.

  • Imagine que cada site tenha dois nós. Os nós alice e bob pertencem ao cluster amsterdam. Os nós charlie e doro pertencem ao cluster berlin.

  • O site amsterdam tem o seguinte endereço IP virtual: 192.168.201.100.

  • O site berlin tem o seguinte endereço IP virtual: 192.168.202.100.

  • Suponha que o arbitrador tenha o seguinte endereço IP: 192.168.203.100.

Antes de prosseguir, verifique se os seguintes requisitos foram atendidos:

Requisitos
Dois clusters existentes

Você tem pelo menos dois clusters existentes que deseja combinar em um cluster Geográfico (se você precisar configurar dois clusters primeiro, siga as instruções no Article “Inicialização Rápida de Instalação e Configuração”).

Nomes de cluster significativos

Cada cluster tem um nome significativo que reflete sua localização, por exemplo: amsterdam e berlin. Os nomes de cluster são definidos em /etc/corosync/corosync.conf.

Arbitrador

Você instalou uma terceira máquina que não faz parte de nenhum cluster existente e deve ser usada como arbitrador.

Para obter os requisitos detalhados de cada item, consulte também a Seção 3, “Requisitos”.

3 Requisitos

Todas as máquinas (nós do cluster e arbitradores) precisam, no mínimo, dos seguintes módulos e extensões:

  • Módulo Basesystem 15 SP6

  • Módulo Server Applications 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

Ao instalar as máquinas, selecione HA GEO Node como a system role. Esse procedimento leva à instalação de um sistema mínimo em que os pacotes do padrão Geo Clustering for High Availability (ha_geo) são instalados por padrão.

Requisitos de rede
  • Os IPs virtuais a serem usados para cada site do cluster devem estar acessíveis no cluster Geográfico.

  • Os sites devem ser acessíveis em uma porta UDP e TCP por instância de booth. Isso significa que qualquer firewall ou túnel IPsec intermediário deve ser configurado adequadamente.

  • Outras decisões de configuração podem exigir a abertura de mais portas (por exemplo, para replicação de banco de dados ou do DRBD).

Outros requisitos e recomendações
  • Todos os nós do cluster em todos os sites devem ser sincronizados com um servidor NTP fora do cluster. Para obter mais informações, consulte o Administration Guide for SUSE Linux Enterprise Server 15 SP6.

    Se os nós não estiverem sincronizados, será muito difícil de analisar os arquivos de registro e os relatórios do cluster.

  • Use um número ímpar de sites no cluster Geográfico. Em caso de falha na conexão de rede, esse procedimento garante que ainda exista a maioria dos sites (para evitar um cenário split-brain). Se você tem um número par de sites de cluster, use um arbitrador para processar o failover automático dos tickets. Se você não usar um arbitrador, precisará gerenciar o failover dos tickets manualmente.

  • O cluster em cada site tem um nome significativo, por exemplo: amsterdam e berlin.

    Os nomes dos clusters para cada site são definidos nos respectivos arquivos /etc/corosync/corosync.conf:

    totem {
        [...]
        cluster_name: amsterdam
        }

    Mude o nome com o seguinte comando crmsh:

    # crm cluster rename NEW_NAME

    Pare e inicie os serviços do cluster para as mudanças entrarem em vigor:

    # crm cluster restart
  • Não há suporte para arquiteturas mistas em um cluster. No entanto, cada membro do cluster Geográfico pode ter uma arquitetura diferente, seja um site de cluster ou um arbitrador. Por exemplo, você pode executar um cluster Geo com três membros (dois sites de cluster e um arbitrador), em que um site de cluster é executado no IBM Z, o outro site de cluster é executado em x86 e o arbitrador é executado no POWER.

4 Visão geral dos scripts de boot Geo

  • Com o crm cluster geo_init, transforme um cluster no primeiro site de um cluster Geográfico. O script usa parâmetros, como os nomes dos clusters, o arbitrador e um ou vários tickets, e cria o arquivo /etc/booth/booth.conf com base neles. Ele copia a configuração de booth para todos os nós no site do cluster atual. Ele também configura os recursos de cluster necessários para o booth no site do cluster atual.

    Para obter os detalhes, consulte a Seção 6, “Configurando o primeiro site de um cluster Geográfico”.

  • Com o crm cluster geo_join, adicione o cluster atual a um cluster Geográfico existente. O script copia a configuração de booth de um site do cluster existente e grava-a no /etc/booth/booth.conf em todos os nós no site do cluster atual. Ele também configura os recursos de cluster necessários para o booth no site do cluster atual.

    Para obter os detalhes, consulte a Seção 7, “Adicionando outro site a um cluster Geográfico”.

  • Com o crm cluster geo_init_arbitrator, transforme a máquina atual em um arbitrador para o cluster Geográfico. O script copia a configuração de booth de um site do cluster existente e grava-a no /etc/booth/booth.conf.

    Para obter os detalhes, consulte a Seção 8, “Adicionando o arbitrador”.

Todos os scripts de boot são registrados em /var/log/crmsh/crmsh.log. Consulte o arquivo de registro para obter todos os detalhes do processo de boot. Quaisquer opções definidas durante o processo de boot podem ser modificadas posteriormente (modificando configurações de booth, recursos, etc). Para obter os detalhes, consulte o Book “Administration Guide”.

5 Instalando os pacotes de High Availability e Geo Clustering

Os pacotes para configurar e gerenciar um cluster Geográfico estão incluídos nos padrões de instalação High Availability e Geo Clustering for High Availability. Esses padrões estarão disponíveis somente após a instalação do SUSE Linux Enterprise High Availability.

Você pode se registrar no SUSE Customer Center e instalar o SUSE Linux Enterprise High Availability 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 os padrões High Availability e Geo Clustering
  1. Instale os padrões High Availability e Geo Clustering pela linha de comando:

    # zypper install -t pattern ha_sles ha_geo
  2. Instale os padrões High Availability e Geo Clustering em todas as máquinas que farão parte do cluster.

    Nota
    Nota: Instalando pacotes de software em todos os nós

    Para uma instalação automatizada do SUSE Linux Enterprise Server 15 SP6 e do SUSE Linux Enterprise High Availability 15 SP6, use o AutoYaST para clonar os nós existentes. Para obter mais informações, consulte o Book “Administration Guide”, Chapter 3 “Installing SUSE Linux Enterprise High Availability”, Section 3.2 “Mass installation and deployment with AutoYaST”.

6 Configurando o primeiro site de um cluster Geográfico

Use o comando crm cluster geo_init para transformar um cluster existente no primeiro site de um cluster Geográfico.

Procedimento 2: Configurando o primeiro site (amsterdam) com crm cluster geo_init
  1. Defina um IP virtual por site do cluster que pode ser usado para acessar o site. Consideramos que 192.168.201.100 e 192.168.202.100 são usados para esta finalidade. Você ainda não precisa configurar os IPs virtuais como recursos de cluster. Isso é feito pelos scripts de boot.

  2. Defina o nome de pelo menos um ticket que concede o direito de executar determinados recursos em um site do cluster. Use um nome significativo que corresponda aos recursos que dependem do ticket (por exemplo, ticket-nfs). Os scripts de boot precisam apenas do nome do ticket. Você pode definir os detalhes restantes (dependências de ticket dos recursos) posteriormente, conforme descrito na Seção 10, “Próximas etapas”.

  3. Efetue login no nó de um cluster existente (por exemplo, no nó alice do cluster amsterdam).

  4. Executar crm cluster geo_init. Por exemplo, use as seguintes opções:

    # crm cluster geo_init \
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100" \1
      --tickets ticket-nfs \2
      --arbitrator 192.168.203.1003

    1

    Os nomes dos sites do cluster (conforme definido em /etc/corosync/corosync.conf) e os endereços IP virtuais que você deseja usar para cada site do cluster. Neste caso, temos dois sites do cluster (amsterdam e berlin), cada um com um endereço IP virtual.

    2

    O nome de um ou vários tickets.

    3

    O nome de host ou endereço IP de uma máquina fora dos clusters.

O script de boot cria o arquivo de configuração de booth e o sincroniza com os sites do cluster. Ele também cria os recursos de cluster básicos necessários para o booth. A Passo 4 do Procedimento 2 resulta na seguinte configuração de booth e recursos de cluster:

Exemplo 1: Configuração de booth criada por crm cluster geo_init
# The booth configuration file is "/etc/booth/booth.conf". You need to
# prepare the same booth configuration file on each arbitrator and
# each node in the cluster sites where the booth daemon can be launched.

# "transport" means which transport layer booth daemon will use.
# Currently only "UDP" is supported.
transport="UDP"
port="9929"

arbitrator="192.168.203.100"
site="192.168.201.100"
site="192.168.202.100"
authfile="/etc/booth/authkey"
ticket="ticket-nfs"
expire="600"
Exemplo 2: Recursos de cluster criados por crm cluster geo_init
primitive1 booth-ip IPaddr2 \
  params rule #cluster-name eq amsterdam ip=192.168.201.100 \
  params rule #cluster-name eq berlin ip=192.168.202.100 \
primitive2 booth-site ocf:pacemaker:booth-site \
  meta resource-stickiness=INFINITY \
  params config=booth \
  op monitor interval=10s
group3 g-booth booth-ip booth-site \
meta target-role=Stopped4

1

Um endereço IP virtual para cada site do cluster. Os daemons de booth exigem essa informação, pois precisam de um endereço IP persistente em cada site do cluster.

2

Um recurso primitivo para o daemon de booth. Ele se comunica com os daemons de booth nos outros sites do cluster. O daemon pode ser iniciado em qualquer nó do site. Para fazer com que o recurso permaneça no mesmo nó, se possível, resource-stickiness foi definido como INFINITY.

3

Um grupo de recursos de cluster para ambos os primitivos. Com essa configuração, cada daemon de booth está disponível em seu endereço IP individual, independentemente do nó em que o daemon é executado.

4

O grupo de recursos de cluster não é iniciado por padrão. Depois de verificar a configuração de recursos de cluster (e adicionar os recursos necessários para concluir a configuração), você precisará iniciar o grupo de recursos. Consulte Etapas necessárias para concluir a configuração do cluster Geográfico para obter os detalhes.

7 Adicionando outro site a um cluster Geográfico

Depois de inicializar o primeiro site do cluster Geográfico, adicione o segundo cluster com crm cluster geo_join, conforme descrito no Procedimento 3. O script precisa de acesso SSH a um site do cluster já configurado e adiciona o cluster atual ao cluster Geográfico.

Procedimento 3: Adicionando o segundo site (berlin) com crm cluster geo_join
  1. Efetue login no nó do site do cluster que você deseja adicionar (por exemplo, no nó charlie do cluster berlin).

  2. Execute o comando crm cluster geo_join. Por exemplo:

    # crm cluster geo_join \
      --cluster-node 192.168.201.100\1
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100"2

    1

    Especifica de onde copiar a configuração de booth. Use o nome de host ou endereço IP de um nó em um site do cluster Geográfico já configurado. Você também pode usar o endereço IP virtual de um site do cluster existente (como neste exemplo). Como alternativa, use o nome de host ou endereço IP de um arbitrador já configurado para o cluster Geográfico.

    2

    Os nomes dos sites do cluster (conforme definido em /etc/corosync/corosync.conf) e os endereços IP virtuais que você deseja usar para cada site do cluster. Neste caso, temos dois sites do cluster (amsterdam e berlin), cada um com um endereço IP virtual.

O comando crm cluster geo_join copia a configuração de booth de 1. Consulte o Exemplo 1. Além disso, ele cria os recursos de cluster necessários para o booth (consulte o Exemplo 2).

8 Adicionando o arbitrador

Após configurar todos os sites do cluster Geográfico com crm cluster geo_init e crm cluster geo_join, configure o arbitrador com crm cluster geo_init_arbitrator.

Procedimento 4: Configurando o arbitrador com crm cluster geo_init_arbitrator
  1. Efetue login na máquina que você deseja usar como arbitrador.

  2. Execute o seguinte comando. Por exemplo:

    # crm cluster geo_init_arbitrator --cluster-node 192.168.201.1001

    1

    Especifica de onde copiar a configuração de booth. Use o nome de host ou endereço IP de um nó em um site do cluster Geográfico já configurado. Se preferir, use o endereço IP virtual de um site do cluster existente (como neste exemplo).

O script crm cluster geo_init_arbitrator copia a configuração de booth de 1. Consulte o Exemplo 1. Ele também habilita e inicia o serviço de booth no arbitrador. Dessa forma, o arbitrador está pronto para se comunicar com as instâncias de booth nos sites do cluster quando os serviços de booth também são executados neles.

9 Monitorando os sites do cluster

Para ver os dois sites do cluster com os recursos e o ticket que você criou durante o processo de boot, use o Hawk2. A interface da Web do Hawk2 permite monitorar e gerenciar vários clusters (não relacionados) e clusters Geo.

Pré-requisitos
  • Todos os clusters que serão monitorados do Painel de Controle do Hawk2 devem executar o SUSE Linux Enterprise High Availability 15 SP6.

  • Se você ainda não substituiu o certificado autoassinado do Hawk2 em cada nó do cluster pelo seu próprio certificado (ou um certificado assinado por uma Autoridade de Certificação oficial), faça o seguinte: efetue login no Hawk2 em cada nó em cada cluster pelo menos uma vez. Verifique o certificado (ou adicione uma exceção ao browser para ignorar o aviso). Do contrário, o Hawk2 não poderá se conectar ao cluster.

Procedimento 5: Usando o painel de controle do Hawk2
  1. Inicie um browser da Web e insira o IP virtual do seu primeiro site do cluster, amsterdam:

    https://192.168.201.100:7630/

    Se preferir, use o nome de host ou endereço IP de alice ou bob. Se você configurou ambos os nós com os scripts de boot, o serviço hawk deve ser executado em ambos os nós.

  2. Efetue login na interface da Web do Hawk2.

  3. Na barra de navegação esquerda, selecione Painel.

    O Hawk2 mostra uma visão geral dos recursos e nós no site do cluster atual. Ele também mostra quaisquer Tickets que foram configurados para o cluster Geográfico. Se você precisar de informações sobre os ícones usados nesta tela, clique em Legenda.

    Painel de controle do Hawk2 com um site do cluster (amsterdam)
    Figura 2: Painel de controle do Hawk2 com um site do cluster (amsterdam)
  4. Para adicionar um painel de controle para o segundo site do cluster, clique em Adicionar Cluster.

    1. Insira o Nome do cluster para identificá-lo no Painel. Neste caso, berlin.

    2. Insira o nome completo do host de um dos nós do cluster (neste caso, charlie ou doro).

    3. Clique em Adicionar. O Hawk2 exibe uma segunda guia para o site do cluster recém-adicionado com uma visão geral de seus nós e recursos.

      Painel de controle do Hawk2 com os dois sites do cluster
      Figura 3: Painel de controle do Hawk2 com os dois sites do cluster
  5. Para ver mais detalhes para um site do cluster ou para gerenciá-lo, alterne para a guia do site e clique no ícone de corrente.

    O Hawk2 abre a tela Status referente a esse site em uma nova janela ou guia do browser. Neste local, você pode administrar esta parte do cluster Geográfico.

10 Próximas etapas

Os scripts de boot de cluster Geográfico são um meio rápido para configurar um cluster Geográfico básico que pode ser usado para fins de teste. No entanto, para mover o cluster Geográfico resultante para um cluster Geográfico funcional que possa ser usado em ambientes de produção, mais etapas são necessárias.

Etapas necessárias para concluir a configuração do cluster Geográfico
Iniciando os serviços de booth nos sites do cluster

Após o processo de boot, o serviço de booth do arbitrador ainda não poderá se comunicar com os serviços de booth nos sites do cluster, porque eles não são iniciados por padrão.

O serviço de booth para cada site do cluster é gerenciado pelo grupo de recursos de booth g-booth (consulte o Exemplo 2, “Recursos de cluster criados por crm cluster geo_init). Para iniciar uma instância do serviço de booth por site, inicie o respectivo grupo de recursos de booth em cada site do cluster. Isso permite que todas as instâncias de booth se comuniquem umas com as outras.

Configurando dependências de ticket e restrições de pedidos

Para tornar os recursos dependentes do ticket que você criou durante o processo de boot do cluster Geográfico, configure restrições. Para cada restrição, defina uma loss-policy, que define o que deverá acontecer com os respectivos recursos se o ticket for revogado de um site do cluster.

Para obter os detalhes, consulte o Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”.

Concedendo inicialmente um ticket a um site

Antes que o booth possa gerenciar determinado ticket no cluster Geográfico, você precisa concedê-lo a um site manualmente. Você pode usar a ferramenta de linha de comando do cliente de booth ou o Hawk2 para conceder um ticket.

Para obter detalhes, leia o Book “Geo Clustering Guide”, Chapter 8 “Managing Geo clusters”.

Os scripts de boot criam os mesmos recursos de booth em ambos os sites do cluster, e os mesmos arquivos de configuração de booth em todos os sites, incluindo o arbitrador. Se você estender a configuração do cluster Geo (para mover para um ambiente de produção), provavelmente ajustará a configuração de booth e também mudará a configuração dos recursos de cluster relacionados ao booth. Depois disso, será necessário sincronizar as mudanças com os outros sites do cluster Geográfico para entrarem em vigor.

Nota
Nota: Sincronizando mudanças com todos os sites do cluster
  • Para sincronizar as alterações na configuração de booth com todos os sites do cluster (incluindo o arbitrador), use o Csync2. Encontre mais informações no Book “Geo Clustering Guide”, Chapter 5 “Synchronizing configuration files across all sites and arbitrators”.

  • O CIB (Cluster Information Database) não é sincronizado automaticamente com todos os sites de um cluster Geográfico. Isso significa que quaisquer mudanças na configuração de recursos necessárias em todos os sites do cluster precisam ser transferidas para os outros sites manualmente. Para isso, marque os respectivos recursos, exporte-os do CIB atual e importe-os para o CIB nos outros sites do cluster. Para obter os detalhes, consulte o Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”, Section 6.4 “Transferring the resource configuration to other cluster sites”.

11 Para obter mais informações