Inicialização Rápida do Geo Clustering #

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.

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

Os procedimentos neste documento orientam em relação a um cluster Geográfico básico com dois sites 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) precisam, no mínimo, dos seguintes módulos e extensões:

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.

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

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.

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

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:

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

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

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.

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.

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

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: 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 Capítulo 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 Seção 6.4, “Transferring the resource configuration to other cluster sites”.