Clusters e tipos de clusters

Cluster, esse termo está ficando cada vez mais comuns em bate papos de DBAs e administradores, afinal é a tecnologia de ponta pensando-se em alta disponibilidade (HA High Availability), ainda mais lidando na disponibilidade de ambientes críticos. O conceito de cluster é você ter ambientes homogêneos ,isto é, contendo o mesmo hardware, arquitetura, software e atualização. Cluster poderá ser utilizado para escalonar sistemas, fornecer um melhor desempenho e ainda sobreviver falhas. Os tipos de cluster estão relacionados ao tipo de armazenamento que é feito.

Estarei dando foco nesse artigo sobre os tipos de clusters disponíveis e suas aplicações. Segue abaixo os tipos de clusters:

• Cluster não compartilhado (Shared Nothing Architecture).
  
• Arquitetura de compartilhamento de discos (Shared disk architecture).
  
• Arquitetura de compartilhamento de recursos (Shared everything architecture).
  

 

Todos os tipos de clusters apresentados são usados em tecnologias diferentes e para diferentes tipos de aplicações.

Funcionalidade	Cluster não compartilhado	Arquitetura de compartilhamento de discos	Arquitetura de compartilhamento de recursos
Discos/ Compartilhamento	Os donos dos discos não compartilham informação entre os nos ao mesmo tempo.	Os donos dos discos são geralmente os nos do cluster. E em caso de falha o conteúdo de um disco e copiado para outro.	O compartilhamento e feito a nível disco para todos os nos, ou seja, todos os nos conseguem fazer a escrita/leitura de todos os discos.
Numero de nós	Usualmente o numero de nos é muito grande.	Normalmente 2 nos fazem parte desse cluster, com um deles trabalhando em contingenciamento.	2 ou mais nos dependendo da configuração de arquitetura. Nessa arquitetura é limitado apenas pelo licenciamento do cluster.
Particionamento de informação	Nós podem acessar apenas dados pertencentes ao seu nó. Relação de 1 para 1.	Não necessário particionamento, já que a arquitetura foi criada para o acesso completo da informação.	Não necessário particionamento, já que a arquitetura foi criada para o acesso completo da informação.
Coordenador client	Servidor externo ou qualquer membro do grupo	Não requer coordenador, o outro nos de contingência só é usando em caso de failover.	Não requer coordenador, qualquer um pode acessar a informação.
Escalabilidade	Altamente escalavel, mas é limitada a quantidade de nós individuais.	Escalabilidade limitada devido as limitações no hardware utilizado.	Escalabilidade infinita devido a quantidade de nós independentes e compartilhamento de recursos.
Acesso de escrita	Cada nó é pode escrever apenas na sua instancia. Uma instancia não pode escrever em discos de outra instancia.	Um no pode escrever em todos os discos, mas somente um por vez.	Todos os nos podem escrever em todos os discos limitados apenas pelo controlador de recursos de escrita (lock manager control)
Carga de balanciamento (Load Balancing)	Não é possível	Não é possível	Possui perfeita carga de balanciamento.
Particionamento da aplicação	Requer em toda a aplicação.	Não é requerimento, mas quando ativado é apenas para um nó (No ativo)	Não necessário.
Adicionar novos nós	Não é possível	É possível mas apenas 1 no estará disponível por vez.	É possível. O conceito é baseado nessa idéia de acionamento de novos membros e prover maior disponibilidade.
Capacidade de falhas (failover)	Não há failover devido 1 no acessar seus discos devidos, e não prover acesso a outros discos disponíveis em outras instancias.	Poderá reverter o nó ativo com um script automático ou a transição dos servidores manuais.	Provem toda e qualquer garantia, sua arquitetura foi construída para a alta disponibilidade removendo assim perigos no contingenciamento de recursos.
I/O	Escrita normal.	Escrita normal.	A escrita/leitura é controlada pelo DLM (Data Locker Manager) e pelo Controlador de Cluster.
Falhas de um no	As informações providas pelo cluster que falhou ficaram indisponíveis.	As informações momentaneamente ficaram indisponíveis para utilização, até o outro nó assumir o controle.	As conexões no no danificado é distribuída entre os nos restantes e toda a informação é disponibilizada novamente. Não há perdas e nem falhas todas são transparentes para a aplicação.
Adicionar nó (disponibilidade)	Requer completa reorganização da arquitetura.	É possível a adição de novos nós, mas a adição não resolverá em nada, devido a mesma oferecer uma disponibilidade que já existem.	Podem ser removidos e adicionados novos nós com os bancos de dados online sem necessidade de parada no ambiente. Após a conclusão de adição do novo nó é feito o balanciamento automáticamente.
Exemplos	IBM SP2, Informix Online XPS, Microsoft Cluster Server, etc.	ServiceGuard, Veritas Cluster Server, etc.	Oracle RAC, Oracle Parallel Server, etc.

Obs. Tabela acima foi extraída do livro de Oracle RAC 10G da Oracle Press e traduzida.