Eu ofereço minha solução para o seguinte problema, e peço a você profissionais de administração de redes e servidores para validá-la ou fazer furos nela. Estou interessado em quaisquer vetores de ataque óbvios ou problemas de escalabilidade que você possa ver. Obrigado!
Requisitos:
- Suporte HTTPS, tratado por cada servidor de aplicativos de forma independente
Escalabilidade horizontal quase linear -
- largura de banda distribuída entre os servidores (os dados de resposta não retornam todos através dos LBs ou proxies)
- algo como failover para servidores de aplicativos e balanceadores de carga
- afinidade cliente-servidor
- compatível com Linux (solução não fechada)
- amigável ao bootstrap! (isto é, baixo custo inicial)
O esquema:
PUBLIC NETWORK
+-----+------+--------+-----+------->
| | | |
v v v v
+---+ +---+ +--+ +--+
|LB1| |LB2| ... |S1| |S2| ...
+---+ +---+ +--+ +--+
Balanceadores de carga redundantes (LB *, via algo como DNS RR ou apenas failover): seu único objetivo é oferecer aos clientes o URI para alguma instância do servidor de aplicativos, que o cliente usaria perpetuamente para suas solicitações. A distribuição seria aleatória ou round robin, inicialmente.
As instâncias do Servidor de Aplicativos (S *) lidam de forma independente com solicitações diretamente dos clientes.
A arquitetura sem estado permite que servidores individuais sejam desativados. Os clientes solicitam um novo servidor a partir dos balanceadores de carga se o servidor atribuído falhar.
Novos servidores de aplicativos podem gerar, registrar-se com os balanceadores de carga e serem atribuídos aos clientes muito rapidamente. Todos os S * teriam uma entrada de DNS de subdomínio para compartilhar um certificado curinga.
Uma implementação ingênua pode ser feita inteiramente em um servidor com redundância zero e delegar responsabilidades para expandir conforme necessário.
Preocupações imediatas
A proteção contra firewall e DDoS teria que ser gerenciada em cada servidor, em vez de centralizada, como acontece com os proxies reversos de balanceamento de carga. O gerenciamento centralizado de configurações é o máximo que eu pensei sobre isso.
Este esquema não tira proveito da localização geográfica ou do tempo de resposta do servidor, como algo semelhante ao Anycast DNS. É um trade-off consciente para uma maior probabilidade de afinidade com o servidor, e possivelmente pode ser usado posteriormente.