Este é um tópico grande que é complicado rapidamente. O teorema 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 de gravação pesada, fica mais difícil distribuir a carga pela Internet, mantendo a integridade dos dados. Os aplicativos de leitura centralizada (pesquisa!) São mais fáceis de distribuir, já que você não precisa se preocupar com a logística de gravação dos dados.
Oipvs permite que o Linux se torne essencialmente um switch da camada 4. Eu tive o maior sucesso em usá-lo na camada 2 (ARP / ethernet-- camada de link) e essa seria minha primeira escolha, mas pode ser viável usar algo como LVS-Tun para servidores geograficamente separados que não têm uma conexão na camada de transmissão. Note que ipvsadm é a ferramenta userland para ipvs e ldirectord é um daemon para gerenciar recursos de ipvs.
O batimento cardíaco foi efetivamente sucedido por marca-passo . Para monitorar o outro servidor, é essencial ter vários links. O risco de não ter uma conexão física serial ou redundante entre os servidores é substancialmente maior. Mesmo várias conexões da Internet fisicamente distintas que os monitores de pulsação entre os dois sites estão fadadas a cair. É aí que entra em jogo o risco dos dados, pois o failover automático arrisca a corrupção de dados pelo cérebro dividido. Não existe um método ideal para mitigar esse risco.
Você pode injetar mais lógica no processo de failover. Por exemplo:
Se o caminho1 estiver inoperante, o caminho2 estiver inoperante, esse processo não está sendo executado e não posso fazer isso-- então, o failover.
Isso reduz o risco, mas mesmo assim não é necessariamente capaz de conectar fisicamente os servidores a uma curta distância.
Com o conteúdo estático, é fácil empregar o uso de uma Rede de distribuição de conteúdo .
Balanceamento de carga e failover simples podem ser feitos usando Round Robin DNS , que é mais falível.
O Border Gateway Protocol é um protocolo de rede que permite a alta disponibilidade na camada de rede.
Em última análise, com dinheiro suficiente (tempo / recursos), um SLA adequado pode ser desenvolvido para permitir um alto grau de disponibilidade. Seu orçamento será sua última restrição. Defina seus requisitos e veja o que você pode realizar dentro do seu orçamento, pois haverá compromissos.Descobri com frequência que faz mais sentido, pelo menos no caso de escrever aplicativos pesados, habilitar alta disponibilidade e failover automático dentro da mesma premissa física. Como parte do plano de recuperação de desastre e do SLA para ter um processo de failover manual em um site separado fisicamente, o que permite que a integridade dos dados seja mantida e ainda assim mantenha um nível de serviço de qualidade.