Como lidar com falhas do servidor em uma arquitetura de n camadas?

Question

Imagine que tenho uma arquitetura de n camadas em um ambiente de nuvem em escala automática com:

• um balanceador de carga em um par de failover
• camada de proxy reverso
• camada de aplicativo da web
• nível do bd

Cada camada precisa se conectar às instâncias na camada abaixo.

Quais são as formas padrão de conectar camadas para torná-las resilientes à falha de nós em cada camada? ou seja, como cada camada obtém os endereços IP de cada nó na camada abaixo?

Por exemplo, se todos os proxies reversos devem rotear o tráfego para todos os nós de aplicativos da Web, como eles podem ser configurados para não enviar tráfego para nós de aplicativos da web mortos e para que quando novos nós de aplicativos da web sejam colocados on-line? pode enviar tráfego para ele?

• Eu poderia executar um agente que atualizaria todas as configurações para todos os nós, mas parece ineficiente.
• Eu poderia colocar um par LB entre cada camada, então o nível acima só precisa se conectar aos balanceadores de carga, mas como eu lidei com o problema dos LBs morrendo? Isso parece apenas desviar o problema da camada A precisar conhecer os IPs de todos os nós na camada B, para todos os nós da camada A precisarem conhecer os IPs de todas as LBs entre as camadas A e B.

Para alguns aplicativos, eles podem implementar a lógica de nova tentativa se entrarem em contato com um nó na camada abaixo que não responde, mas existe alguma maneira de alguns middlewares direcionarem tráfego para apenas nós ativos na camada a seguir?

Se eu estivesse hospedando na AWS, poderia usar um ELB entre camadas, mas quero saber como conseguir a mesma funcionalidade.

Eu li (brevemente) sobre batimentos cardíacos e keepalived - são relevantes aqui? Quais são os IPs virtuais sobre os quais eles falam e como eles são gerenciados? Ainda há pontos únicos de falha usando-os?

    

Answer 1

um balanceador de carga de aplicativos como o haproxy faz isso. por exemplo, se detectar erros 5xx de um servidor da web, ele poderá marcar o servidor como com falha. Além disso, se um servidor falhar no handshake de três vias, ele poderá marcá-lo como com falha, além de tentar outro servidor enquanto o cliente continua aguardando.

usando keepalived e heartbeat, você pode ter um par de servidores haproxy. se um falhar, o outro assume.

Eu uso o haproxy como exemplo aqui, mas praticamente qualquer balanceador de carga de aplicativo (balanceadores de carga de camada 4/7) tem essas características.

    

Answer 2

Sua pergunta é How do I deal with failures?
A resposta é Redundancy ou, mais especificamente,

• Crieumconjuntodenósquepodemfazerotrabalhoquevocêprecisafazer.
  • Verifiqueseelestêmcaminhosderedeeenergiaseparadosparaoseunúcleo.
• Sevocêprecisartolerarumafalhadeumúniconóemumconjunto,coloqueoconjuntoatrásdeumbalanceadordecargaconformedescrito.
• Sevocêprecisartolerarafalhadobalanceadordecarga,forneçaaeleumparceiro.
  • Mesmaadvertênciasobrecaminhosseparadosdeenergiaerede.
• Sevocêprecisartolerarafalhadeváriosnós,useN+Sredundancy
  (váriaspeçasprontasparaentrareassumir).

VocêpodefazerissocomoAmazonELB(seestivernoEC2),opffirewall(ou pfsense ) com um IP virtual round-robin, ou várias ferramentas de balanceamento de carga de software, como haproxy (que são provavelmente a melhor escolha, pois vêm com alguns recursos decentes de detecção de falhas, embora eles exijam hardware adicional). Há também soluções dedicadas de balanceamento de carga comercial, como os switches de conteúdo da Cisco ou módulos de mudança de conteúdo se você tiver dinheiro.

Não se esqueça de simular falhas em seu ambiente de teste para garantir que as coisas falhem da maneira esperada.

    

Answer 3

O LB deve monitorar a camada de proxy e remover automaticamente os hosts (ou seja, redirecionar o tráfego para os nós sobreviventes).

O proxy reverso deve usar novamente um LB que monitora os aplicativos da web. Os aplicativos da web devem ser capazes de assumir sessões de outros nós.

Os aplicativos da web devem se conectar via LB aos servidores de banco de dados.