Failover Clustering (II)

O mecanismo de failover


No cluster, os recursos partilhados podem ser vistos por todos os computadores, ou nós. Cada detecta automaticamente se outro nó no cluster falhou e os processos em execução no nó que falhou continuam a ser executados num que fica operacional. Para o utilizador, o failover é normalmente transparente. Retratado na figura seguinte está um cluster de dois nós em que ambos têm discos locais e existem recursos partilhados disponíveis para ambos os computadores. A ligação de heartbeat permite que os dois computadores comuniquem e detecta quando um falha; se o Nó 1 falhar, o software do cluster irá transferir todos os serviços de forma transparente para o Nó 2.
 
O mecanismo de failover
 
O serviço do Windows associado ao serviço de cluster, chamado Cluster Service, tem alguns componentes:
  • Processador de eventos;
  • Gestor de Base de Dados;
  • Gestor de Nó;
  • Actualizador Geral;
  • Gestor de Comunicações;
  • Gestor de Recursos ou de Failover.
O gestor de recursos comunica directamente com um monitor de recursos que utiliza uma DLL específica que torna uma aplicação apropriada para ser utilizada num cluster (cluster-aware). O gestor de comunicações fala directamente com o Winsock do Windows (um componente do nível de rede do Windows).
 
O processo de failover é o seguinte:

  1. O gestor de recursos no cluster detecta um problema num recurso específico;
  2. Cada recurso tem um número específico de tentativas em que pode ser colocado online, dentro de uma determinada janela de tempo. Os recursos são colocados online em ordem de dependência. Isto significa que os recursos tentarão ficar online até que seja atingido o número máximo de tentativas na janela de tempo limitada. Se nem todos os recursos poderem ser colocados online neste momento, o grupo pode entrar em operação parcialmente online com os outros recursos marcados como em falha. Qualquer recurso que tem uma dependência que falhou não será colocado online e permanecerá em estado de falha. No entanto, se qualquer recurso que falhou está configurado para afectar o grupo de recursos, as coisas são escaladas e é iniciado o processo de failover (através do Gestor de Failover) para esse grupo de recursos. Se os recursos não estão configurados para afectar o grupo, eles serão deixados num estado de falha, ficando o grupo parcialmente online;
  3. Se o gestor de failover é contactado, ele determina, com base na configuração do grupo de recursos, qual será melhor destinatário desse grupo. Um novo potencial proprietário é notificado, e o grupo de recursos é enviado para esse nó a fim de ser, começando todo o processo novamente. Se esse nó não também conseguir colocar os recursos online, um outro nó (assumindo que há mais de dois nós do cluster) pode tornar-se o seu proprietário. Se nenhum nó consegue iniciar os recursos, o grupo de recursos é globalmente deixado em estado de falha;
  4. Se um nó inteiro falhar o processo é semelhante, excepto na medida em que o gestor de failover determina que grupos eram propriedade do nó que falhou e, posteriormente, descobre qual o outro nó(s) para onde enviá-los para reiniciarem.

Hardware do Cluster


Para melhores resultados, use hardware idêntico em todos os nós. Aqui estão algumas regras simples:
 
  • Em cada servidor do cluster, são necessários pelo menos dois adaptadores de rede;

  • Planeie cuidadosamente os requisitos de sua carga de trabalho e escolha hardware que seja suficiente para suportar as cargas esperadas associados a esses serviços;

  • Escolha hardware que corresponda às exigências previstas para a sua carga de trabalho. Não desperdice dinheiro em quatro servidores com CPU quad-core se a sua carga de trabalho exige pouco poder de processamento mas intensa actividade nos discos;

  • Adicione capacidade excedentária se no cluster cada nó vai executar uma carga de trabalho activa. Caso contrário, em caso de falha de um nó, o remanescente pode ficar sobrecarregado. 

Arquitectura do Cluster

 
Uma das formas mais relevantes para categorizar clusters de alta disponibilidade é através da forma como o armazenamento é partilhado. As duas arquitecturas predominantes são os clusters sem nada partilhado e os clusters com disco partilhado.
 

Cluster sem nada partilhado

 
Em qualquer instante, apenas um nó possui um disco. Quando um nó falhar, outro nó do cluster tem acesso ao mesmo disco. Num sistema sem nada partilhado as CPU são apenas responsáveis por conjuntos individualizados de dados e apenas um dos sistemas pode ter a posse e aceder a um recurso específico ou a um subconjunto de dados. Esta arquitectura implica que cada servidor tem a sua própria memória privada e o seu armazenamento privado. Os dados são repartidos de uma determinada forma e são distribuídos por um conjunto de máquinas cada uma com acesso exclusivo e logo com responsabilidade exclusiva por esses dados.

Os servidores nestes clusters comunicam passando mensagens através da rede que os liga de modo a que os pedidos dos clientes sejam automaticamente reencaminhados para o sistema que tem o recurso solicitado. É claro que, em caso de falha, a posse dos recursos pode ser dinamicamente transferida para outro sistema.

A principal vantagem deste tipo de arquitectura é a sua escalabilidade. Em teoria, um cluster sem nada partilhado pode ter milhares de processadores porque não interferem uns com os outros; nada é partilhado.
 

Cluster com disco partilhado

 
Todos os nós têm acesso ao mesmo armazenamento. Um mecanismo de bloqueio protege contra as condições de conflito e corrupção de dados. A propriedade do disco é movida de um nó para o outro. Este procedimento requer que o disco seja partilhado entre os dois nós, de modo a que quando o nó passivo se torna activo, tem acesso aos mesmos dados que o anterior tinha;
 
Cluster com disco partilhado
 
Para permitir a virtualização de nomes e endereços IP, um cluster de failover fornece ou requer redundância de quase todos os componentes; servidores, placas de rede, redes, e assim por diante. Esta redundância é a base de toda a disponibilidade do cluster de failover. No entanto, há um ponto único de falha em qualquer implementação de um cluster de failover que é o subsistema de disco que é anexado e é acessível por todos os nós do cluster de failover.

Entre as tecnologias que podem ser necessárias para implementar clusters de disco compartilhado incluem-se um Gestor de Volumes Distribuídos, que é usado para virtualizar o armazenamento subjacente para todos os servidores acederem ao mesmo armazenamento, e o sistema de ficheiros do cluster, que controla a leitura e gravação de acesso a um único sistema de arquivos no armazenamento partilhado. Nesta arquitectura de disco partilhado, onde cada nó pode escrever em cada disco, um sofisticado mecanismo de bloqueio evita inconsistências que poderiam decorrer de acesso simultâneo aos mesmos dados.

Tipicamente, os clusters deste tipo tendem a não ser tão escaláveis mas ainda assim podem ser utilizados em aplicações e serviços que requeiram apenas partilha de dados partilhados.
Em qualquer uma das arquitecturas (disco partilhado ou nada partilhado), na perspectiva do armazenamento, o disco precisa estar ligado aos servidores de tal forma a que qualquer servidor no cluster pode aceder por meio de uma simples operação de software.
Existem outras arquitecturas de clusters, nomeadamente:
 
  • Clusters com tudo partilhado: Não só o sistema de arquivos é partilhado, mas a memória e processadores, oferecendo ao utilizador uma única imagem do sistema. Neste modelo, as aplicações não precisam ser cluster-aware porque os processos são lançados em qualquer um dos processadores disponíveis, e se um servidor/processador se torna indisponível, o processo é reiniciado num processador diferente.

  • Clusters com discos espelhados: O software de gestor de volumes é usado para criar discos espelhados em todas as máquinas do cluster. Cada servidor grava nos que possui e para os discos dos outros servidores que fazem parte do mesmo cluster.

Armazenamento do Cluster

 
No Windows Server 2008, os dispositivos de armazenamento devem ter LUNs (Logical Unit Number) múltiplos e individualizados. Estes LUNs devem ser instalados como discos básicos e preferencialmente formatados com o NTFS.

Cada vez mais, os servidores dos clusters e os dispositivos de armazenamento são ligados através de SANs (Storage Area Network). Estas redes usam ligações de alto débito entre os servidos e o armazenamento permitindo que este seja utilizado via rede ao invés de através de cabos dentro do chassis da máquina.

A SAN utilizada para o armazenamento do cluster deve suportar reservas persistentes e um conjunto de armazenamento deve ser isolado dos outros servidores através de mascaramento do LUN ou da criação de zonas.

As SANs permitem a consolidação do armazenamento utilizando poucos dispositivos altamente fiáveis em vez de muitos dispositivos menos fiáveis (como os discos internos dos servidores) e permitem também que o armazenamento seja partilhado com sistemas não-Windows o que incrementa a cooperação entre plataformas diferentes.
 

Redes do Cluster

 
Como vimos anteriormente, em cada servidor do cluster são necessários pelo menos dois adaptadores de rede pois um cluster de failover tem duas redes primárias:
 
  • A rede privada de cluster: Por vezes conhecida como a rede intracluster, ou mais vulgarmente, a rede de heartbeat, esta é uma rede dedicada que é separada de todos os outros tráfegos de rede e é utilizada com o único propósito de executar processos internos nos nós do cluster para garantir que os nós estão a funcionar e se não, para iniciar o failover. A rede privada de cluster não detecta falhas nos processo.

  • Uma rede pública: Esta é a rede que liga o cluster ao resto da rede e permite que os clientes, aplicações e outros servidores se liguem ao cluster de failover.
 
Redes do Cluster
 

Outras Considerações

 
  • Todos os nós de um cluster devem ter ou uma versão de 32 bits ou todos uma versão de 64 bits do Windows Server, sem mistura;

  • Todos os servidores do cluster devem estar no mesmo domínio Active Directory e devem ser preferencialmente servidores membros e não controladores de domínio;

  • Os servidores no cluster devem usar o Domain Name System (DNS) para resolução de nomes DNS e o pode ser utilizado o protocolo de actualização dinâmica.