como projetar libras - verniz - jboss para ha + loadbalancing

Question

Estou planejando uma nova infraestrutura para nosso aplicativo da web. Nós temos dois servidores JBossAS5, rodando em um cluster. O estado da sessão será replicado através do JBoss Cache.

Na frente disso, deve haver algum cache, para acelerar a entrega de elementos estáticos. No entanto, a maior parte do tráfego para o nosso aplicativo será via HTTPS.

Até agora, eu estava pensando em dois caches de Varnish na frente do JBossASs, cada um sendo configurado para balanceamento de carga para os dois JBossASs via round-robin. Como o Varnish não suporta HTTPS, então seria necessário ter proxies de dois quilos na frente dos Varnishs, lidando com o HTTPS. Os dois quilos seriam disponibilizados com o Heartbeat / LinuxHA.

O tráfego para www.example.com passaria pelo nosso firewall, daí para o IP virtual das libras, daí para os Varnishs, e daí para o JBossASs.

Pergunta 1: Isso faz sentido? Ou é muito complicado, e o mesmo objetivo pode ser alcançado com métodos mais simples?

Pergunta 2: Se meu layout estiver correto, como configuro a libra - > Passo de verniz? Devo a) tornar o serviço Varnish altamente disponível também através do Heartbeat / LinuxHA e direcionar o tráfego de libra para o IP virtual dos Varnishs, ou devo preferir b) Configurar dois vernizes independentes e usar balanceamento de carga em libra para resolver o problema? diferentes vernizes?

Obter loadbalancing de hardware não é uma opção, infelizmente, devido a custos. Isso não é corporativo, mas um sistema de ONGs, e estamos sempre com pouco dinheiro ... A coisa toda não é de missão crítica, mas eu gostaria que fosse o mais confiável possível, porque nossa TI nem sempre está disponível em curto prazo (não temos pessoal de TI em tempo integral empregado ...).

Muito obrigado pela sua percepção!

Andreas.

    

Answer 1

Eu acho que sua abordagem faz sentido. Se você não tiver a necessidade de armazenamento em cache avançado de objetos dinâmicos, sugiro usar nginx como capacidade de armazenamento em cache, https e balanceamento de carga. Eu amo o Varnish, e acho que a maioria dos sites pode ganhar muito usando-o, mas com base em suas informações, faria mais sentido usar nginx (+ heartbeat ou carp).

• O Nginx pode armazenar em cache objetos dinâmicos, mas não acho possível escrever regras baseadas em uris (ou parte deles), cookies, ip de conexão etc. etc. O Nginx pode armazenar em cache no disco e memcached, então seria possível para o par de nginx ter o mesmo cache, mais ou menos.
• É possível equilibrar a carga, acho que com base em uma sessão, hash de ip e muito mais.
• faz https muito bem.

Boa sorte! :)

    

Answer 2

Eu diria que a solução proposta é mais de engenharia. Existe uma variedade de tecnologias que seriam adequadas à sua situação.

Eu uso o LVS para balanceamento de carga e SQUID para caching, particularmente no que diz respeito ao Jboss. Para conteúdo estático, geralmente é melhor servir a partir do Apache. Você ainda pode usar o heartbeat ou o pacemaker para redundância com essas tecnologias.

A principal razão que eu uso o SQUID é para reescrever, mas muito do conteúdo que eu lido é dinâmico. O cache é um bônus. A maioria dos meus aplicativos Java praticamente não tem conteúdo estático, então, muitas vezes, pulo a parte mod_jk. Sendo assim, seus requisitos podem simplificar drasticamente até mesmo a minha solução proposta.

Um exemplo possível:

NAT para SQUID (ha cluster - > SQUID é um proxy transparente para LVS VIP - > LVS no cluster do Apache - > mod_jk para o Jboss

    

Answer 3

Existe algum motivo para você não querer usar um balanceador de carga de hardware?

Como você descreve um design de alta disponibilidade, acredito que esse seja um site de missão crítica e possivelmente de alto tráfego. Como tal, você pode ter o orçamento para tal aparelho ou aparelhos para fornecer HA nessa camada.

Um appliance como o F5 BigIP fornece mais recursos e confiabilidade do que a libra. Você poderá fazer o descarregamento de SSL para manipular os https, bem como o armazenamento em cache e a compactação.

    

Answer 4

Adicionar mais camadas definitivamente dificulta a manutenção, mas não acho que haja algo errado com a abordagem básica. Meu primeiro pensamento foi que o Squid faz o que você deseja para armazenar em cache as conexões http e https. Eu usei com sucesso por cerca de 4 anos em um site de hospedagem de fotos.

O Squid está aqui: link . Há evidentemente algumas considerações de desempenho: link , mas talvez essas desvantagens sejam compensadas pelo apoio de https.