Introdução ao SUSE Linux Enterprise High Availability

O SUSE Linux Enterprise High Availability está disponível com os seguintes produtos:

O SUSE Linux Enterprise High Availability elimina pontos únicos de falha para melhorar a disponibilidade e a capacidade de gerenciamento dos recursos críticos. Isso ajuda a manter a continuidade dos negócios, proteger a integridade dos dados e reduzir o tempo de inatividade não planejado para as cargas de trabalho críticas.

A figura a seguir mostra um cluster de três nós. Cada um dos nós tem um servidor Web instalado e hospeda dois sites. Todos os dados, os gráficos e os conteúdos das páginas da Web de cada site são armazenados em um subsistema de disco compartilhado conectado a cada um dos nós.

Figura 1: Cluster de três nós #

 

Durante a operação normal do cluster, cada nó fica em constante comunicação com os outros nós no cluster e verifica os recursos periodicamente para detectar falhas.

A figura a seguir mostra como o cluster move os recursos quando o Servidor Web 1 falha devido a problemas de hardware ou de software.

Figura 2: Cluster de três nós após a falha de um nó #

 

O Site A foi movido para o Servidor Web 2, e o Site B foi movido para o Servidor Web 3. Os sites continuam disponíveis e são distribuídos igualmente entre os nós restantes do cluster.

Quando o Servidor Web 1 falhou, o software de alta disponibilidade executou as seguintes tarefas:

Neste exemplo, o failover ocorreu rapidamente, e os usuários recuperaram o acesso aos sites em segundos, em geral, sem precisar fazer login novamente.

Quando o Servidor Web 1 recuperar o estado operacional normal, o Site A e o Site B poderão voltar (“failback”) para o Servidor Web 1 automaticamente. Isso gera um pouco de tempo de inatividade, portanto, a alternativa é configurar os recursos para failback apenas em um horário especificado para causar o mínimo de interrupção do serviço.

Um cluster de alta disponibilidade é um grupo de servidores que trabalham juntos para garantir a disponibilidade dos aplicativos ou serviços. Os servidores configurados como membros do cluster são chamados de nós. Se um nó falhar, os recursos executados nele poderão ser movidos para outro nó no cluster. O SUSE Linux Enterprise High Availability suporta clusters com até 32 nós. No entanto, os clusters costumam se enquadrar em uma destas duas categorias: clusters de dois nós ou clusters com um número ímpar de nós (em geral, três ou cinco).

A comunicação interna do cluster é feita pelo Corosync. O Corosync Cluster Engine é um sistema de comunicação em grupo que fornece informações sobre o cluster referentes a mensagens, participação e quorum. No SUSE Linux Enterprise High Availability 16, o Corosync usa o kronosnet (knet) como o protocolo de transporte padrão.

É altamente recomendável configurar pelo menos dois canais de comunicação para o cluster. O método preferido é usar o vínculo de dispositivo de rede. Se você não pode usar um vínculo de rede, configure um canal de comunicação redundante no Corosync (também conhecido como segundo “anel”).

Em um cluster de alta disponibilidade, os aplicativos e serviços que precisam estar altamente disponíveis são chamados de recursos. Os recursos do cluster podem incluir sites, servidores de e-mail, bancos de dados, sistemas de arquivos, máquinas virtuais e outros aplicativos ou serviços baseados em servidor que você deseja manter sempre disponíveis aos usuários. Você pode iniciar, parar, monitorar e mover os recursos conforme necessário. Você também pode especificar se determinados recursos devem ser executados juntos no mesmo nó, ou iniciá-los e pará-los em uma ordem sequencial. Se um nó do cluster falhar, será feito failover (serão movidos) dos recursos executados nele para outro nó, em vez de serem perdidos.

No SUSE Linux Enterprise High Availability, o gerenciador de recursos de cluster (CRM, Cluster Resource Manager) é o Pacemaker, que gerencia e coordena todos os serviços do cluster. O Pacemaker usa agentes de recursos (RAs, Resource Agents) para iniciar, parar e monitorar os recursos. Um agente de recursos abstrai o recurso que ele gerencia e apresenta o status dele ao cluster. O SUSE Linux Enterprise High Availability suporta diversos agentes de recursos desenvolvidos para gerenciar tipos específicos de aplicativos ou serviços.

Em um cenário de split brain, os nós do cluster são divididos em dois ou mais grupos (ou partições) que não se reconhecem. O motivo pode ser uma falha de hardware ou de software, ou na conexão de rede, por exemplo. É possível resolver um cenário de split brain por meio de fencing (redefinir ou desligar) de um ou mais dos nós. O fencing no nível do nó impede que um nó com falha acesse recursos compartilhados e que os recursos do cluster sejam executados em um nó com status incerto.

O SUSE Linux Enterprise High Availability usa o STONITH como mecanismo de fencing de nó. Para serem compatíveis, todos os clusters SUSE Linux Enterprise High Availability devem ter pelo menos um dispositivo STONITH. Para cargas de trabalho críticas, é altamente recomendável usar dois ou três dispositivos STONITH. Ele pode ser um dispositivo físico (interruptor) ou um mecanismo de software (SBD em combinação com um watchdog).

Quando a comunicação falha entre um ou mais nós e o restante do cluster (um cenário de split brain), ocorre uma partição de cluster. Os nós podem se comunicar apenas com outros nós na mesma partição e não reconhecem os nós separados. Uma partição de cluster tem quorum (ou “quorum atingido”) quando tem a maioria dos nós (ou “votos”). Isso é determinado pelo cálculo do quorum. O quorum deve ser calculado para permitir fencing dos nós que não atingiram o quorum.

O Corosync calcula o quórum com base na seguinte fórmula:

N ≥ C/2 + 1

N = minimum number of operational nodes
C = number of cluster nodes

Por exemplo, um cluster de cinco nós precisa de, no mínimo, três nós operacionais para manter o quorum.

Os clusters com um número par de nós, principalmente os de dois nós, podem ter números iguais de nós em cada partição e, portanto, nenhuma maioria. Para evitar essa situação, você pode configurar o cluster para usar o QDevice em combinação com o QNetD. O QNetD é um arbitrador executado fora do cluster. Ele se comunica com o daemon QDevice executado nos nós do cluster para fornecer um número configurável de votos para cálculo do quorum. Isso permite que um cluster suporte mais falhas de nós do que o permitido pelas regras de quorum padrão.

Os clusters de alta disponibilidade podem incluir um subsistema de disco compartilhado conectado por Fibre Channel ou iSCSI. Se houver falha em um nó, outro nó no cluster montará automaticamente os diretórios de discos compartilhados que foram montados no nó com falha. Isso fornece aos usuários acesso contínuo aos diretórios no subsistema de disco compartilhado. O conteúdo armazenado no disco compartilhado pode incluir dados, aplicativos e serviços.

A figura a seguir representa o aspecto de uma configuração típica de cluster Fibre Channel. As linhas verdes mostram as conexões com um interruptor Ethernet, que poderá reinicializar o nó se uma solicitação de ping falhar.

Figura 3: Configuração típica de cluster Fibre Channel #

 

A figura a seguir representa o aspecto de uma configuração típica de cluster iSCSI.

Figura 4: Configuração típica de cluster iSCSI #

 

A maioria dos clusters inclui um subsistema de disco compartilhado, mas você também pode criar um cluster sem esse subsistema. A figura a seguir representa o aspecto do cluster sem um subsistema de disco compartilhado.

Figura 5: Configuração típica de cluster sem armazenamento compartilhado #

 

O SUSE Linux Enterprise High Availability tem uma arquitetura em camadas. A figura a seguir mostra as diferentes camadas e os componentes associados.

Figura 6: Arquitetura do cluster SUSE Linux Enterprise High Availability #

 

Muitas ações executadas no cluster provocam mudanças em todo o cluster, por exemplo, adição ou remoção de um recurso do cluster ou alteração das restrições de recursos. O seguinte exemplo explica o que acontece no cluster quando você executa esse tipo de ação: