Estou investigando a configuração de uma solução de servidor com balanceamento de carga que consiste em três caixas CentOS 5.4. Duas dessas caixas residirão em uma instalação, enquanto uma terceira residirá em uma instalação diferente.
Atualmente estou trabalhando para configurar heartbeat, ldirectord, ipvsadm para balancear a carga das máquinas, mas não tenho certeza se isso funcionará com
Não estou muito familiarizado com os detalhes de como tudo isso funciona, mas o balanceamento de carga funcionará corretamente quando esses servidores não estiverem todos na mesma LAN? Não tenho certeza se o heartbeat está usando SNMP para enviar sinais ou não, o que só funcionaria em uma LAN. Alguém já tentou isso ou encontrou uma solução diferente?
Responder1
Este é um tópico amplo que se complica rapidamente. OTeorema CAPé um bom ponto de partida, pois identifica as escolhas de nível superior que devem ser feitas.
Quando você está lidando com um aplicativo da Web com muita gravação, fica mais difícil distribuir a carga pela Internet, mantendo a integridade dos dados. Aplicativos centrados em leitura (pesquisa!) são mais fáceis de distribuir, pois você não precisa se preocupar com a logística de gravação dos dados.
ipvspermite que o Linux se torne essencialmente um switch de camada 4. Tive mais sucesso ao usá-lo na camada 2 (ARP/ethernet - camada de link) e essa seria minha primeira escolha, mas pode ser viável usar algo comoLVS-Tunpara servidores geograficamente separados que não possuem conexão na camada de transmissão. Observe que ipvsadm é a ferramenta de usuário para ipvs e ldirectord é um daemon para gerenciar recursos de ipvs.
batimento cardíaco foi efetivamente sucedido pormarca-passo. Para monitorar o outro servidor, é essencial ter vários links. O risco de não haver conexão física serial ou redundante entre os servidores é substancialmente maior. Mesmo múltiplas conexões de Internet fisicamente distintas que monitoram a pulsação entre os dois sites estão fadadas a cair. É aqui que entra em jogo o risco dos dados, já que o failover automático corre o risco de corrupção de dados por divisão cerebral. Não existe um método ideal para mitigar esse risco.
Você poderia injetar mais lógica no processo de failover. Por exemplo:
Se o caminho1 estiver inativo, o caminho2 estiver inativo, este processo não está em execução e não posso fazer isso - então faça failover.
Isto reduz o risco, mas mesmo assim não necessariamente ao ponto de poder conectar fisicamente os servidores a uma curta distância.
Com conteúdo estático, é fácil empregar o uso de umRede de distribuição de conteúdo.
Balanceamento de carga e failover simples podem ser realizados usandoDNS Round Robin, o que é mais falível.
Protocolo de gateway de fronteiraé um protocolo de rede que pode permitir alta disponibilidade na camada de rede.
Em última análise, com dinheiro suficiente (tempo/recursos), um SLA apropriado pode ser desenvolvido para permitir um alto grau de disponibilidade. Seu orçamento será sua restrição final. Defina seus requisitos e veja o que você pode realizar dentro do seu orçamento, pois haverá compromissos.
Muitas vezes descobri que faz mais sentido, pelo menos no caso de aplicações pesadas, permitir alta disponibilidade e failover automático dentro da mesma premissa física. Como parte do plano de recuperação de desastres e do SLA, é necessário ter um processo de failover manual para um local fisicamente separado, que permite manter a integridade dos dados e ainda manter um nível de serviço de qualidade.
Responder2
Ter servidores diferentes em locais diferentes não deve ser um problema, até que eles possam se comunicar.
O problema seria a largura de banda entre eles e o que você faz fluir nele.
Heartbeat não usa snmp e pode ser multicast, unicast ou broadcast. É um protocolo específico (de qualquer forma, o snmp funciona entre lans sicne, é um protocolo udp).
Que tipo de serviço está tentando balancear a carga?
Responder3
Outra ideia seria alguma implementação de DRBD com alta disponibilidade. Confira este sitehttp://www.drbd.org/home/what-is-drbd/