Inicialização Rápida do Geo Clustering #

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.

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

A seguir, configuraremos um cluster Geo básico com dois sites do cluster e um arbitrador:

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

Para obter os requisitos detalhados de cada item, consulte também a Seção 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:

Ao instalar as máquinas, selecione HA GEO Node como a system role. 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.

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 detalhes, consulte o Administration Guide.

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

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

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

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: 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 SP4 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”.

Use o comando crm cluster geo_init para transformar um cluster existente no primeiro site de um cluster Geo.

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:

# 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"

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

Depois de inicializar o primeiro site do cluster Geo, adicione o segundo cluster com crm 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.

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

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

O comando crm cluster geo_init_arbitrator copia a configuração de booth de 1. Consulte 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.

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.

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.

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: 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 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 Geo. 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 a Section 6.4, “Transferring the resource configuration to other cluster sites”.

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