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 do Geo Clustering
SUSE Linux Enterprise High Availability Extension 15 SP2

Inicialização Rápida do Geo Clustering

SUSE Linux Enterprise High Availability Extension 15 SP2

Data de Publicação: December 11, 2023

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 Geo, usando os scripts de boot Geo incluídos no pacote ha‑cluster-bootstrap.

Autores: Tanja Roth e Thomas Schraitle

1 Visão geral conceitual

Os clusters Geo baseados na SUSE® Linux Enterprise High Availability Extension 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 Geo 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 arbitrador) para chegar a um consenso sobre as decisões (por exemplo, o 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 Geo 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 Geo de dois sites sem um arbitrador. Nesse caso, um administrador de cluster Geo 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 usado para clusters Geo, consulte o Geo Clustering Guide.

2 Cenário de uso

A seguir, configuraremos um cluster Geo básico com dois sites do cluster 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 terá o seguinte endereço IP virtual: 192.168.201.100.

  • O site berlin terá 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 para combinar em um cluster Geo. (Se você primeiro precisa configurar dois clusters, siga as instruções na Inicialização Rápida de Instalação e Configuração.)

Nomes de cluster significativos

Cada cluster tem um nome significativo definido em /etc/corosync/corosync.conf que reflete seu local.

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) que farão parte do cluster precisam, no mínimo, dos seguintes módulos e extensões:

  • Base System Module 15 SP2

  • Server Applications Module 15 SP2

  • SUSE Linux Enterprise High Availability Extension 15 SP2

Ao instalar as máquinas, selecione HA GEO Node como a função do sistema. Isso 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 Geo.

  • 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 Guia de Administração do SUSE Linux Enterprise Server 15 SP2.

    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 Geo. Em caso de falha na conexão, esse procedimento garante que ainda exista uma maioria dos sites (para evitar um cenário de split brain). Se você tem um número par de sites de cluster, use um arbitrador para gerenciar 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 de cada site são definidos nos respectivos arquivos /etc/corosync/corosync.conf:

    totem {
        [...]
        cluster_name: amsterdam
        }

    Mude o nome com o seguinte comando crmsh:

    root # crm cluster rename NEW_NAME

    Pare e inicie o serviço pacemaker para as mudanças entrarem em vigor:

    root # crm cluster restart
  • Não há suporte para arquiteturas mistas em um cluster. No entanto, cada membro do cluster Geo 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 ha-cluster-geo-init, transforme um cluster no primeiro site de um cluster Geo. O script usa alguns 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 Geo”.

  • Com o ha-cluster-geo-join, adicione o cluster atual a um cluster Geo 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 Geo”.

  • Com o ha-cluster-geo-init-arbitrator, transforme a máquina atual em um arbitrador para o cluster Geo. 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/ha-cluster-bootstrap.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 detalhes, consulte o Geo Clustering Guide.

5 Instalação

O suporte para uso de clusters de Alta Disponibilidade a distâncias ilimitadas está disponível com a Geo Clustering for SUSE Linux Enterprise High Availability Extension.

Para configurar um cluster Geo, você precisa dos pacotes incluídos nos seguintes padrões de instalação:

  • High Availability (denominado sles_ha na linha de comando)

  • Geo Clustering for High Availability (denominado ha_geo na linha de comando)

Ambos os padrões estão disponíveis apenas se você registrou seu sistema no SUSE Customer Center (ou em um servidor de registro local) e adicionou os respectivos módulos ou a mídia de instalação como uma extensão. Para obter informações sobre como instalar as extensões, consulte o Guia de Implantação para SUSE Linux Enterprise 15 SP2.

Para instalar os pacotes de ambos os padrões por meio da linha de comando, use o Zypper:

root # zypper install -t pattern ha_sles ha_geo
Importante
Importante: Instalando pacotes de software em todas as partes

Os pacotes de software necessários para os clusters High Availability e Geo não são copiados automaticamente para os nós do cluster.

  • Instale o SUSE Linux Enterprise Server 15 SP2 e os padrões ha_sles e ha_geo em todas as máquinas que farão parte do cluster Geo.

  • Em vez de instalar manualmente os pacotes em todas as máquinas que farão parte do cluster, use o AutoYaST para clonar nós existentes. Encontre mais informações no Section 3.2, “Mass Installation and Deployment with AutoYaST”.

6 Configurando o primeiro site de um cluster Geo

Use o script ha-cluster-geo-init para transformar um cluster existente no primeiro site de um cluster Geo.

Procedimento 1: Configurando o Primeiro Site (amsterdam) com ha-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 será feito pelos scripts de boot.

  2. Defina o nome de pelo menos um ticket que concederá 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. Execute ha-cluster-geo-init. Por exemplo, use as seguintes opções:

    root # ha-cluster-geo-init \
      --clusters1 "amsterdam=192.168.201.100 berlin=192.168.202.100" \
      --tickets2 ticket-nfs \
      --arbitrator3 192.168.203.100

    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 1 resulta na seguinte configuração de booth e recursos de cluster:

Exemplo 1: Configuração de Booth Criada por ha-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 ha-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 Geo para obter os detalhes.

7 Adicionando outro site a um cluster Geo

Depois de inicializar o primeiro site do cluster Geo, adicione o segundo cluster com ha‑cluster-geo-join, conforme descrito no Procedimento 2. O script precisa de acesso SSH a um site do cluster já configurado e adicionará o cluster atual ao cluster Geo.

Procedimento 2: Adicionando o Segundo Site (berlin) com ha-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 ha-cluster-geo-join. Por exemplo:

    root # ha-cluster-geo-join \
      --cluster-node1 192.168.201.100\
      --clusters2 "amsterdam=192.168.201.100 berlin=192.168.202.100"

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

    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 script ha-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

Depois de configurar todos os sites do cluster Geo com o ha-cluster-geo-init e o ha‑cluster-geo-join, configure o arbitrador com o ha-cluster-geo-init-arbitrator.

Procedimento 3: Configurando o Arbitrador com ha-cluster-geo-init-arbitrator
  1. Efetue login na máquina que você deseja usar como arbitrador.

  2. Execute o seguinte comando. Por exemplo:

    root # ha-cluster-geo-init-arbitrator --cluster-node1 192.168.201.100

    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 Geo já configurado. Se preferir, use o endereço IP virtual de um site do cluster existente (como neste exemplo).

O script ha-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 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 do Hawk2 devem executar a SUSE Linux Enterprise High Availability Extension 15 SP2.

  • Se você ainda não substituiu o certificado autoassinado para o 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 4: 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. Além disso, ele mostra quaisquer Tickets que foram configurados para o cluster Geo. 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, berlim.

    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 exibirá 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 Geo.

10 Próximas etapas

Os scripts de boot de cluster Geo são um meio rápido para configurar um cluster Geo básico que pode ser usado para fins de teste. No entanto, para mover o cluster Geo resultante para um cluster Geo funcional que pode ser usado em ambientes de produção, mais etapas são necessárias. Consulte Etapas necessárias para concluir a configuração do cluster Geo.

Etapas necessárias para concluir a configuração do cluster Geo
Iniciando os serviços de booth em 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 ha-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 Geo, 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 Chapter 6, Configuring Cluster Resources and Constraints.

Concedendo inicialmente um ticket a um site

Antes que o booth possa gerenciar determinado ticket no cluster Geo, 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 os detalhes, consulte o 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 Geo para entrarem em vigor.

Nota
Nota: Sincronizando mudanças com todos os sites do cluster

11 Para obter mais informações

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