Fundamentos do Clustering
Clustering é a utilização de vários computadores e ligações redundantes para formar o que parece ser um sistema único e altamente disponível. Um cluster fornece protecção contra a inactividade para aplicações importantes ou serviços que precisam estar sempre disponíveis, distribuindo a carga entre vários computadores para que, no caso de falha num sistema, o serviço esteja disponível noutro.
O conceito básico de um cluster é fácil de entender; um cluster são dois ou mais sistemas trabalhando em conjunto para alcançar um objectivo comum. No Windows existem dois tipos principais de clustering: clusters de expansão/disponibilidade conhecidos como Network Load Balancing clusters (NLB) e clusters estritamente baseados em disponibilidade conhecidos como Failover Clusters. A Microsoft tem também uma variante do Windows chamada Windows Compute Cluster Server.
Quando um computador inesperadamente falha ou é deliberadamente desligado, o clustering garante que os processos e serviços a ser executados, mudam para outra máquina, ou seja, fazem "failover" no cluster. Isto acontece sem interrupção nem necessidade de intervenção imediata do administrador fornecendo uma solução de alta disponibilidade, o que significa que os dados críticos estão sempre disponíveis.
Os clusters de failover são normalmente constituídos por dois servidores (ou ocasionalmente por vários servidores), como a configuração mostrada na figura. Um servidor (principal) está activamente a processar pedidos dos clientes e a prestar os serviços em situações normais, enquanto o outro servidor (failover) está a monitorizar o servidor principal para assumir e executar os serviços, se este falhar.
O sistema primário é monitorizado, com verificações activas em intervalos de poucos segundos para garantir que o sistema principal está a funcionar correctamente. Quando o cluster é composto apenas por dois servidores, a monitorização pode ser feita através de um cabo dedicado que interliga as duas máquinas, ou através da rede. O sistema que realiza a monitorização pode ser o computador de failover ou um sistema independente (chamado controlador de cluster).
Do ponto de vista do cliente, as aplicações são acessíveis através de um nome DNS que por sua vez está mapeado a um endereço IP virtual que pode flutuar de uma máquina para outra, dependendo de qual máquina que está activa. Em caso de falha do sistema activo, ou falha de componentes associados com este sistema, tais como hardware de rede, o sistema de monitorização irá detectar a falha e o sistema de failover assumirá a operação do serviço.
Um elemento-chave das soluções de failover clustering é que ambos os computadores partilham um sistema de arquivos comum. Uma abordagem é fornecer este sistema usando um RAID (Redundant Array of Independent Disks) de portas duplas, para que o subsistema de disco não seja dependente de nenhuma drive isolada. Outra possibilidade é a utilização de uma SAN (Storage Area Network).
Um cluster de failover fornece:
- Alta disponibilidade, reduzindo os tempos de inactividade não planeados e aumentando a fiabilidade dos serviços e aplicações;
- Alta escalabilidade permitindo aos administradores atribuir até 16 nós a um cluster melhorando o desempenho e disponibilidade o que significa que torna o sistema mais escalável, pois permite o crescimento incremental.
Num cluster de failover, todos os nós do cluster estão cientes dos recursos partilhados com todos os outros nós e da sua disponibilidade de serviços. Assim, quando um recurso ou hardware falhar, o serviço de cluster pode transferir automaticamente as cargas de trabalho em execução num nó para outro.
Comparação de Clusters
Como já vimos nos artigos anteriores, os clusters NLB são principalmente destinados a fornecer alta disponibilidade para os serviços que dependem do protocolo TCP/IP funcionando como um balanceadores de carga, distribuindo a carga o mais uniformemente possível entre vários computadores, cada um executando as suas próprias cópias independentes e isoladas de uma aplicação, como o IIS. Um cluster NLB adiciona disponibilidade, bem como escalabilidade, a servidores web ou servidores de FTP e, sendo um conceito externo ao Windows, o balanceamento de carga pode ser conseguido através de hardware específico.
Uma implementação do NLB baseada em Windows é aquela onde vários servidores (até 32) correm independentemente uns dos outros sem partilharem os seus recursos e assim, os pedidos dos clientes ligam-se ao grupo de servidores e podem ser enviadas para qualquer um deles uma vez que todos fornecem a mesma funcionalidade. Os algoritmos que suportam o NLB mantêm um registo de quais os servidores que estão ocupados de modo a que quando chega um novo pedido ele seja enviado para um servidor que pode lidar com isso. No caso de uma falha individual do servidor, o NLB “sente” o problema e pode ser configurado para redireccionar a ligação para outro servidor no cluster. O NLB não pode ser configurado em servidores que façam parte de um cluster de failover, por isso só pode ser usado com servidores isolados (standalone).
Os clusters de failover são provavelmente o tipo mais comum de clusters consistindo em servidores que podem suportar e partilhar cargas de trabalho para aplicações stateful (as que têm estados de longa duração na memória ou dados actualizado com frequência), tais como o e-mail, bases de dados, ficheiros, impressão e serviços de virtualização de vários servidores.
A finalidade de um cluster de failover do Windows é ajudar a manter o acesso dos clientes a aplicações e recursos de servidor, mesmo no caso de ocorrer algum tipo de interrupção (de desastres naturais, falhas de software, falha no servidor, etc.). O conceito genérico por trás de toda a disponibilidade de uma implementação de failover clustering é que as máquinas cliente e as aplicações não precisam se preocupar com que servidor do cluster está activo a disponibilizar um determinado recurso; o nome e o endereço IP de tudo o que está a ser executado dentro do cluster de failover são virtualizados. Isto significa que as aplicações ou clientes ligam-se a um único nome ou endereço IP, mas nos bastidores, o recurso a que estão a aceder pode ser disponibilizado em qualquer dos servidores que faz parte do cluster.
Tentando comparar o NLB com o failover clustering, poderíamos dizer que o clustering é a utilização de vários computadores para prestar um serviço único enquanto o balanceamento de carga é uma técnica para utilizar vários computadores num cluster, ou seja, um Cluster é um objecto(s) e Balanceamento de Carga é um método.
Então, vamos tentar comparar esses dois tipos de cluster no Windows Server 2008:
Característica
|
NLB
|
Failover Clustering
|
| Principal utilização | Reduzir cargas de trabalho, fornecer alguma tolerância a falhas para aplicações stateless | Aumentar a fiabilidade do software, serviços e ligações de rede |
| Aplicações | IIS, ISA Server | E-mail, bases de dados, serviços de ficheiros, serviços de impressão, virtualização |
| Transparência | É possível que ocorra alguma interrupção para os clientes | Na maioria dos casos, é completamente transparente para os clientes |
| Número de nós | 32 | 16 |
Terminologia de Clusters
Failover Cluster
Um cluster é um grupo de computadores independentes, também conhecidos como nós, que estão ligados entre si para fornecer recursos de alta disponibilidade para uma rede. Cada nó que é um membro do cluster tem simultaneamente o seu armazenamento em disco individual e acesso a um subsistema de disco comum. Quando um nó no cluster falha, o nó (ou nós) restante assume a responsabilidade pelos recursos que o nó falhado tinha. Isso permite que os utilizadores continuem a aceder a esses recursos enquanto o nó está fora de operação.
Nó
Um servidor num cluster de failover é conhecido como um nó de forma que estes são apenas os servidores que são membros do cluster.
Geocluster
Os clusters podem ser implementados numa server farm num único local físico ou em instalações diferentes separadas geograficamente para maior resiliência. Este último tipo de cluster é muitas vezes referido como um Geocluster. Os Geoclusters tornaram-se muito populares como forma de garantir continuidade dos negócios uma vez que melhoraram o tempo de resposta de uma aplicação caso os servidores no site primário fiquem indisponíveis o que acaba por melhorar o RTO.
Redes do cluster
Os nós num cluster comunicam através de uma rede pública e uma rede privada. A rede pública é utilizada para receber pedidos de clientes, enquanto a rede privada é utilizada principalmente para a monitorização. Cada nó monitoriza continuamente o estado do outro através das mensagens de controlo (heartbeat) trocadas na rede privada mas se esta rede ficar indisponível eles podem utilizar a rede pública. Pode existir mais que uma ligação de rede privada para garantir redundância mas a maioria das implementações simplesmente usa uma VLAN diferente para a ligação de rede privada. Alternativamente, também é possível usar uma única interface de LAN para a ligação pública e privada, mas isso não é recomendado por motivos de falta de redundância.
Host lógico
O termo "host lógico” ou “host lógico do cluster” é utilizado para descrever o endereço de rede que é usado para aceder aos serviços prestados pelo cluster. Esta entidade não está vinculada a um único nó de cluster sendo na realidade um endereço de rede/nome que está relacionado com o serviço(s) fornecido pelo cluster. Se um nó do cluster com uma base de dados vai abaixo, a base de dados será reiniciada noutro nó do cluster e o endereço de rede que os utilizadores usam para lhe aceder irá direccioná-los para o novo nó de modo a que os utilizadores possam aceder à base de dados novamente.
Failover
Failover ocorre quando um recurso de cluster falha num servidor e outro servidor assume a gestão desse recurso.
Failback
Quando o servidor que abandonou o cluster retorna ao serviço e se volta a juntar ao cluster, os serviços ou aplicações que migraram anteriormente para outro nó podem agora retornar para o servidor no qual estavam originalmente. Isto é o chamado failback.
Quórum
O quórum para um cluster pode ser visto apenas como o número mínimo de nós que devem estar online para que o cluster se mantenha em funcionamento. Mas há mais do que isso; por exemplo, se toda a comunicação entre os nós do cluster for perdida, todos os nós tentarão colocar online mesmo o recurso, o que resulta num cenário activo-activo. Os pedidos recebidos vão para ambos os nós, que tentam escrever para o disco partilhado, causando corrupção de dados. Isto é vulgarmente referido como o problema split-brain .
O mecanismo que protege contra este problema é o quórum e em qualquer altura apenas um nó do cluster possui o quórum . O conceito-chave é que, quando toda a comunicação é perdida, o nó que possui o quórum é o único que pode colocar recursos online, mas se a comunicação parcial continua a existir, o nó que possui o quórum é o único que pode iniciar a migração de um grupo de aplicações.
Implementação do quórum no Windows Server
Quando um cluster de failover é colocado online (supondo que isto é feito um nó de cada vez), o primeiro disco colocado online é o que estará associado ao modelo de quórum implementado. Para fazer isso, o cluster de failover executa um algoritmo de arbitragem de disco para que o primeiro nó se aproprie do disco sendo este inicialmente colocado offline e passando depois por algumas verificações. Quando o cluster está convencido de que não há problemas com o quórum, este é colocado online. A mesma coisa acontece com os outros discos. Depois de todos os discos estarem online, o controlador de disco do cluster envia reservas periódica a cada 3 segundos para manter a posse do disco.
Se por algum motivo, o cluster perder a comunicação em todas as suas redes, o processo de arbitragem do quórum recomeça. O resultado é simples: o nó que detém actualmente a reserva do quórum é o titular e os outros são os pretendentes. Quando um pretendente detecta que não pode comunicar, emite um pedido de quebra de todas as reservas existentes que possui através de um reset SCSI no Windows Server 2003 e reserva persistente no Windows Server 2008. Sete segundos após este reset , o pretendente tenta ganhar o controle do quórum e aqui várias situações podem ocorrer:
- Se o nó que já possui o quórum estiver a funcionar, ainda tem a reserva do disco de quórum e o pretendente não pode tomar posse logo desliga o seu serviço de cluster;
- Se o nó que possui o quórum falhar e ceder a sua reserva, então o pretendente pode tomar posse após terem decorrido 10 segundos. O pretendente pode então reservar o quórum, colocá-lo online e, posteriormente, apropriar-se de outros recursos do cluster;
- Se nenhum nó do cluster conseguir adquirir a titularidade de quórum, o serviço de cluster é interrompido em todos os nós.
Aplicações
Pelo simples facto de uma aplicação correr num servidor com software de clustering instalado não significa imediatamente que a aplicação vá beneficiar do clustering. Se a aplicação não for projectada para isso (cluster aware), uma falha nos seus processos não levará obrigatoriamente a um failover para a máquina redundante. Para que isso aconteça, é necessário que as aplicações sejam cluster-aware e cada fornecedor de software de cluster fornece suporte imediato para determinadas aplicações.
Recursos
Os recursos são os serviços aplicacionais, ou outros elementos sob o controlo do serviço de cluster. Uma aplicação num cluster tem recursos individuais, tais como endereço IP, um disco físico, e um nome de rede.
Monitor de recursos
Monitores de Recursos verificam os recursos atribuídos e notificam o serviço de cluster se houver qualquer alteração no estado dos recursos.
Grupo de recursos
Um conceito-chave em clusters é o de grupo. Este termo refere-se a um conjunto de recursos dependentes que são agrupados. Os recursos individuais são contidos num grupo de recursos de cluster, que é semelhante a uma pasta no disco rígido que contém os arquivos. O grupo é uma unidade de failover; noutras palavras, é o agrupamento de todos os recursos que constituem uma aplicação, incluindo o seu endereço IP, o seu nome, os discos, e assim por diante . Um grupo de recursos é a menor unidade de failover, os recursos individuais não podem fazer failover. Ou seja, todos os elementos que pertencem a um único grupo de recursos têm que estar presentes num único nó.
Um exemplo do agrupamento de recursos pode ser uma aplicação de partilha de ficheiros, o seu endereço IP, o disco que essa aplicação usa, e o nome da rede. Se qualquer um desses recursos não está disponível, por exemplo, se o disco não é acessível via este servidor, o grupo faz failover para a máquina redundante. O failover de um grupo de uma máquina para outra pode ser automático, quando um recurso fundamental no grupo falhar, ou manual.
Dependências
Alguns recursos precisam de outros recursos para serem executados, são uma dependência de outro recurso (ou recursos) dentro de um grupo. Se um recurso é dependente de outro, ele não será capaz de iniciar, até que o nível superior de recursos esteja online. Por exemplo, uma partilha de ficheiros precisa de um disco físico para armazenar os dados que serão acedidos usando a partilha ou, numa implementação de cluster do SQL Server, o SQL Server Agent é dependente do SQL Server para iniciar antes que ele possa ficar online. Se o SQL Server não puder ser iniciado, o SQL Server Agent também não será colocado online.
Essas relações são conhecidas como dependências de recursos. Quando um recurso é definido como uma dependência de outro recurso, ambos devem ser colocados no mesmo grupo. Se uma série de recursos, depende em última análise de um único recurso (por exemplo, um recurso de disco físico), todos esses recursos devem pertencer ao mesmo grupo. As dependências são usadas para definir como os diferentes recursos se relacionam entre si. Estas interdependências controlam a sequência em que o serviço de cluster coloca recursos online ou offline.
Estados dos Recursos
Os recursos podem estar num dos cinco estados:
- Offline: o recurso não está disponível para uso por qualquer outro recurso ou cliente;
- Offline Pendente: este é um estado transitório, enquanto o recurso está a ser colocado offline;
- Online: o recurso está disponível;
- Online Pendente: este é um estado transitório, enquanto o recurso está a ser colocado online;
- Falha: há um problema com o recurso que o serviço de cluster não pode resolver.
Pode ser especificado o tempo que o serviço de cluster concede para que determinado recurso fique online ou offline. Se o recurso não puder ser colocado online ou off-line dentro deste prazo, é colocado em estado de falha.
Testemunha
Um elemento de testemunha, seja um disco testemunha ou uma testemunha de partilha de ficheiros, é utilizado apenas nalguns clusters, geralmente naqueles com um número par de nós, na qualidade de desempate quando houver falhas e os nós restantes tiverem que determinar se os nós restantes são suficientes para trabalhar juntos como um cluster.