Temos este JavaEE WebApp (JSP+Struts+Hibernate+MySQL) que atualmente está rodando em um único servidor. Devido ao crescimento do site e problemas de desempenho decidimos agrupar o projeto em algumas máquinas. O site deve tolerar algo em torno de 5.000 solicitações por segundo. Depois de pesquisar e ler algumas coisas no Google, descobri algumas estratégias para fazer isso:
- Usando o Apache como balanceador de carga front-end e proxy reverso, algumas instâncias do Tomcat, cada uma em uma máquina separada e, finalmente, um servidor de banco de dados rodando MySQL. As instâncias do Tomcat podem ser dimensionadas conforme necessário.
- UsandoNginxcomo balanceador de carga front-end e proxy reverso. O resto seria igual ao anterior.
- UsandoHAProxycomo balanceador de carga front-end e proxy reverso. O resto seria igual ao anterior.
Suponho que nas abordagens mencionadas acima todo o tráfego deva passar pelo balanceador de carga front-end (Apache, Nginx ou HAProxy Server). isso torna o servidor front-end um gargalo e também um SPOF. Isso está certo? um único servidor front-end pode tolerar todo o tráfego de um grande aplicativo da web?
para contornar esse problema, criei uma estratégia meio artesanal:
- Colocar a página de Login e ações de autenticação em um servidor front-end (por exemplo, será acessível em myapp.com). quando um usuário faz login com sucesso, ele é redirecionado para um dos servidores back-end (como srv1.myapp.com) e continua sua atividade lá.
Então, estou no caminho certo?
Deixe-me saber sua opinião sobre essas abordagens e se você estiver pensando em uma melhor, mencione-a aqui.
Responder1
Colocar a página de login em um servidor frontend e redirecionar para backends é uma má ideia. Os usuários podem marcar seus servidores backend, você pode acabar com uma distribuição desigual e quando um servidor cair, os usuários ainda tentarão acessá-lo se estiverem na mesma sessão.
O que você precisa é de um ativo/passivo (Batimento cardiaco/Marcapasso/Failover de IP/Failover de DNS) ou ativo/ativo (Rodada de DNS/balanceamento de carga de rede) servidores front-end.
Com ativo/passivo, todo o seu tráfego seria redirecionado para um servidor front-end, com um segundo em espera (Hot Standby). Quando o primeiro caiu, você de alguma forma faria o failover (Ether reatribuindo o endereço IP ou modificando o DNS *) para apontar para o segundo servidor.
Com ativo/ativo você teria dois (ou mais) servidores constantemente ativos, usando etherRodada de DNSouBalanceamento de carga IP/redepara distribuir a carga (aproximadamente) uniformemente entre os dois. Em seguida, os dois servidores distribuiriam novamente a carga para seus servidores back-end.
ativo/ativo é o método usado pela maioria dos grandes aplicativos da web (veja os registros DNS do Youtube/Google/Twitter/Wordpress.com/Tumblr e eles terão vários IPs para os servidores para round robin de DNS.
Depois de tomar essa decisão e implementá-la, tudo o que você terá é uma escolha entre soluções. Pessoalmente eu sugeririaNGINXmas todo mundo tem sua preferência (HAProxy,Lula,Cherokee,Velocidade da luz,F5(hardware),Cisco(hardware) e inúmeros outros).
Infelizmente, para esse tipo de pergunta não podemos simplesmente dizer "faça isso" porque realmente depende de quais são os seus requisitos. Pesquise algumas das palavras-chave acima e se tiver alguma dúvida específica, fique à vontade para perguntar.
*O failover baseado em DNS provavelmente deve ser evitado, se possível, alguns clientes armazenarão em cache o DNS além do TTL, portanto, não é o ideal.
Responder2
Não sei sobre o nginx, mas você pode emparelhar alguns balanceadores de carga haproxy em uma configuração ativa/passiva para evitar que o haproxy se torne aquele ponto único de falha.
Existem também soluções comerciais, mas elas não parecem receber tanta "tinta" em falhas de servidor por algum motivo.