Alta disponibilidade e balanceamento de carga para MySQL e Jetty

Question

Estou prestes a implantar dois sistemas distintos: um cluster MySQL e um cluster de servidores web Jetty .

1. SOFTWARE

Eu posso conseguir mais servidores Linux para o HA / LB, mas qual software devo usar? Eu estou com o CentOS.

Já ouvi falar de HAProxy, LVS e UltraMonkey.
Eu li muito de sua documentação, mas não está claro se eles suportam MySQL e HTTP / S (ambos). Eu quero uma solução que cuida de ambos , para simplificar (em vez de lidar com dois).

• A solução deve ser de código aberto como as três acima.
• SSL (MySQL e HTTPS) deve ser possível.
  
• "Sticky Sessions" NÃO são um requisito, pois pretendo que as sessões do Jetty sejam compartilhadas no banco de dados MySQL.

2. DESEMPENHO

Eu li que o balanceamento de carga pode ser feito de três maneiras:
- Encaminhamento direto < < Interruptor de LAN dependente?
- encapsulamento IP-IP (encapsulamento) < < soa melhor. não vinculado a LAN, em oposição a "Roteamento Direto"
- Tradução de endereços de rede < < extremamente limitante (respostas do serviço de aplicativos passam pelo LB)

O ponto principal do desempenho, que me preocupa, é que eventualmente é possível (e eu não quero) que todos os dados entre usuários da Internet e meu cluster estejam passando por um servidor (o balanceador), o que torna < strong> o balanceador de um gargalo .
Se estiver conectado a uma conexão de 100MBit , então o sistema inteiro estará limitado a isso.
É possível evitar isso, mas conseguir balanceamento e alta disponibilidade? Qual é o "custo" para isso? Preciso de um interruptor especial na rede ou não?

    

Answer 1

É bom que você não precise confiar no LB (load-balancer) para as informações da sessão.

Sua necessidade de velocidade leva a IMHO a LVS e a abordagem de "direcionamento direto". Você pode fazer o roteamento direto sem usar o mecanismo ip_forward. Eu configurei isso usando uma rede lvs dedicada dos LBs para os servidores reais.

Agora, para a "necessidade de velocidade": com o roteamento direto, o LB recebe as solicitações recebidas, altera seu MAC de destino e as coloca na linha para o RS. Agora o RS tem que ter o IP lógico na rede LVS (mas não deve responder às solicitações arp para esse IP). O RS atenderá a solicitação e responderá DIRETAMENTE ao cliente - a resposta de retorno não voltará pelo LB, minimizando assim a carga no LB.

Além disso, o tráfego de entrada é muito mais baixo do que o tráfego de saída - de acordo com suas necessidades.

O último ponto fraco é a disponibilidade do LB itselv. Você pode agrupar o LB com outra máquina que assume o IP lógico (e lvs). Já que a aderência da sessão não é problema em sua configuração - isso é tudo que você precisa fazer.

Eu achei o lvs-kiss uma boa possibilidade de reconfigurar dinamicamente o lvs - mas existem outras soluções para isso.

BTW - a maioria dos servidores em que usamos o LVS é o CentOS 5.

Atualização 2011-11-11: heartbeat-ldirectord é um addon para heartbeat e então você não precisa de lvs-kiss - se você quiser cluster de qualquer maneira.

    

Answer 2

Balanceamento de carga:

• para o Mysql LB você pode usar o Mysql Proxy (ou melhor fazê-lo na camada de aplicação);
• para o servidor web LB, sugiro nginx .

Para HA, sugiro olhar para o marcapasso É uma solução robusta, escalável e flexível para clustering e alta disponibilidade.