Cluster ?
Cluster é o ato de de rodar a mesma aplicação em vários servidores de aplicação simultaneamente com cada aplicação estando ciente das outras que estão no cluster. Um servidor de aplicação em um cluster é chamado de nó.
Pra quê ?
Creio que a melhor forma de entender o por que? é com um exemplo, então:
O servidor em que minha aplicação está rodando suporta 1000 usuários simultâneos, porém hoje 2000 usuários simultâneos acessaram minha aplicação e o servidor caiu.
E agora José ? Temos 2 opções, ou adquiro recursos para o servidor que já está rodando ou adiciono outras máquinas para responderem esses requests, desafogando a primeiro servidor.
Cluster: Vertical x Horizontal
Clusters podem ser formados com nós rodando em uma máquina ou em várias máquinas. Essa formação do cluster é comumente se referida como topologia.
- Horizontal: Quando os nós do cluster estão em diferentes máquinas.
- Vertical: Quando os nós do clusters estão na mesma máquina
No cluster horizontal se acontece alguma falha com a máquina (ex: queda de energia, queimar algum periférico, etc) a outra máquina assume o cluster sem problemas. Se a máquina do cluster vertical ocorrer algum problema todos os servidores que estavam rodando nela, serão comprometidos. Em outras palavras um cluster horizontal é uma melhor opção para alta disponibilidade.
Balanceamento de Carga
Balanceamento de carga é a maneira de distribuir a carga de entrada entre os diferentes servidores de aplicação, fazendo com que sua aplicação seja escalável e tenha alta disponibilidade. Escalabilidade é o termo usado para descrever a habilidade de fazer com que sua aplicação manipule mais carga adicionando hardware e/ou criando instâncias redundantes sem alterar o código. Então um cluster sem balanceamento de carga faz pouco ou nenhum sentido.
Alta disponibilidade
Caso se tenha uma aplicação que seja toda stateless, pode-se garantir alta disponibilidade apenas colocando um balanceador de carga na frente de vários servidores com a mesma aplicação deployada (note, sem cluster). Esse mecanismo é conhecido como Failover. Cabe a ressalva que no failover nenhum tipo de estado da aplicação é replicado.
Porém se a aplicação for stateful o problema é mais em baixo, imagine que você esteja em um site de compras o seu carrinho já possui 10 itens derrepente o servidor cai, você não vai gostar nada de quando clicar no próximo botão cair em um tela de login e o seu carrinho aparecer zerado. O failover não replica estado então não seria adequado para esse tipo de situação para isso temos o mecanismo a seguir:
Replicação e Tolerância a falhas (Replication e Fault Tolerance)
Um servidor com tolerância a falhas promove alta disponibilidade e continua se comunicando com o cliente mesmo que o servidor caia, ou seja o estado do cliente é mantido. Então no exemplo anterior se o cluster tiver tolerância a falhas então o servidor cairá o cliente será balanceado para outro nó e continuará logado na aplicação com seu carrinho de compras com todos os itens como se nada tivesse acontecido.
Mas o que contém nesse estado do cliente?
Basicamente duas coisas: Dados de sessão e de entidades.
Dados de sessão (Session data) são mantidos em memória pela aplicação ou por mecanismos de cache habilitados pelo servidor de aplicação.
Dados de entidade (Entity data) são mantidos em banco de dados.
Para ser tolerante a falhas o estado associado a uma aplicação deve redundantemente disponível, ou seja, os nós devem replicar o estado entre cada nó do cluster
Fault tolerance = fail over + state replication
É muito comum escutarmos conversas de pessoas pensando em cluster como uma forma de melhorar performance, e como podemos ver cluster é sinônimo de disponibilidade e dependendo do cluster pode é trazer défict de performance devido o fato do servidor de aplicação ter que ficar replicando estado, sincronizando cache, etc.
Existem diferentes formas dessa replicação de estado acontecer em um cluster, mas para não deixar o post muito longo vou encerrando por aqui.
Fonte:
JBoss in Action – Chapter 12 – Understanding Cluster.
#1 by Vinicius on 11/10/2011 - 15:42
Show Show Show! 3x SHOW!
#2 by Vinicius Nascimento on 11/10/2011 - 17:06
Muito bom o artigo, mas tenho uma pergunta. Como compartilhar “cache memory” entre as aplicações que em estão em cluster?
#3 by Rodrigo Ramalho da Silva on 12/10/2011 - 12:30
Então,
Se você quiser que todos os nós do cluster compartilhem de um mesmo cache, você tem que buscar uma solução de datagrid (JSR 347) o JBoss tem o Infinispan.
Agora se não for o caso, a replicação do cache ocorre juntamente com a replicação de estado citada no post e cada nó do cluster terá o seu próprio cache se comunicando com os demais para manter o sincronismo.
Suponhamos que você tenha um cluster, este cluster possua 3 nós A, B e C, e possuam cache de entidades. Um request é enviado para o nó A para que um registro seja alterado, ao invés do nó A replicar o seu cache para B e para C ele pode simplesmente mandar uma mensagem dizendo para os outros nós invalidar esse cache. Essa abordagem é mais rápida do que a replicação de estado e acarreta em menos tráfico de rede pois essa mensagem é muito menor do que uma replicação…
Não sei se respondi sua pergunta, de qualquer forma espero ter ajudado
#4 by Daniel on 13/10/2011 - 13:56
so fiquei com uma duvida, em qual ambiente se passa esta cluster ? unix ou windows ?
#5 by Rodrigo Ramalho da Silva on 13/10/2011 - 14:04
Os conceitos apresentados no post é independente de plataforma.
#6 by Douglas on 28/10/2011 - 21:53
Shutdown ou reset inesperado há possibilidade de intrusão? Algumas formas possíveis relativamente insignificantes para alguns usuários e enormes para que entende, roubo de ip muito permitidos pela maioria de provedores, ai não importa o cache e sim a autenticidade.
Como resetar a máquina quais seriam as possibilidades de resets inesperados? DDoS ou por inserção de um .exe .sh .hqx , como não depende da plataforma tariam as três comumente usadas, até mesmo com detectáveis simples e antigos que mostram fragilidade ao servidor para que ele se reinicie há que tipo de sistema incluso para detectar, bloquear e eliminar este tipo de ataque? fiz duas perguntas em uma pergunta pf.
Outra coisa qual requisitos mínimos para o serv?
Falow Ovo Maltini- é assim que se escreve?
#7 by Rodrigo Ramalho da Silva on 29/10/2011 - 02:32
A sua pergunta foi bastante confusa, mas vou tentar falar alguma coisa…
A maioria dos clusters são compostos por um front-end (apache, nginx, etc) recebendo as requisições webs e balanceando para os servidores de aplicações (jboss, glassfish, …). O que se costuma fazer é isolar o cluster da rede externa, eliminando qualquer tipo de acesso HTTP aos servidores de aplicações, assim o único ponto de saída e entrada para o cluster é a comunicação AJP com o apache no caso. É aconselhável também isolar a rede que o cluster usa para fazer sua comunicação entre seus nós, mas isso já não tem a ver com segurança é mais questão de performance mesmo, para que não fique concorrendo com o tráfego gerado pelas requisições feita pelo servidor.
“Outra coisa qual requisitos mínimos para o serv?”
Bom, fiz um teste rápido aqui com 2 servidores JBoss AS versão 5.1 sem nenhuma aplicação “deployada” e cada instância subindo com 256MB de memória (-Xmx256m) subiu tranquilo.