Um controlador de entrega de aplicações é um proxy reverso com opiniões sobre distribuição, saúde e otimização. Tudo o que ele faz se apoia numa hierarquia de quatro objetos.
A hierarquia
Um servidor real é um backend: endereço, porta, peso e verificação de saúde.
Um pool de servidores agrupa servidores reais e define como o tráfego é distribuído entre eles.
Um servidor virtual é o endereço ao qual os clientes conectam. Liga um endereço e porta de escuta a um pool.
Um perfil de aplicação descreve o comportamento de protocolo: como o HTTP é tratado, o que é reescrito, quais otimizações se aplicam.
Qualquer coisa que você configure se prende a um desses quatro, e saber a qual é a maior parte de se orientar.
Métodos de balanceamento, e o que pressupõem
O método decide qual servidor real recebe a próxima requisição, e cada um carrega uma premissa:
Round robin distribui igualmente e pressupõe que todos os servidores e todas as requisições são iguais. Serve a cargas homogêneas e sem estado.
Round robin ponderado deixa servidores desiguais carregarem carga proporcional, o que importa depois de uma renovação de hardware deixar um pool misto.
Menos conexões envia ao servidor com menos conexões ativas, o que lida com requisições de duração variável muito melhor que round robin. É o padrão sensato para a maioria das aplicações reais.
Resposta mais rápida usa tempo de resposta medido, o que se adapta a servidores degradados em vez de fora do ar. Seu risco é oscilação se a janela de medição for curta.
Hash de origem mapeia um cliente consistentemente a um servidor. É um método de distribuição que por acaso dá aderência, e é instrumento grosseiro para persistência — veja abaixo.
A persistência é onde aplicações com estado quebram
Se uma aplicação mantém estado de sessão no servidor que a criou, um cliente cuja próxima requisição cai em outro lugar parece deslogado. O sintoma é intermitente e de aparência aleatória, o que o torna caro de diagnosticar e é por isso que a persistência merece decisão deliberada.
Persistência por endereço de origem liga um endereço de cliente a um servidor. Simples, e falha onde muitos clientes compartilham um endereço atrás de : um escritório inteiro cai num servidor, o que é desequilíbrio e fragilidade.
Persistência por cookie faz o inserir ou ler um cookie identificando o servidor. Bem mais exata porque identifica uma sessão em vez de uma localização de rede, e exige que o cliente aceite cookies e que o tráfego seja legível.
Persistência por ID de sessão SSL funciona onde cookies não estão disponíveis, com a ressalva de que identificadores de sessão mudam mais do que as sessões.
A regra geral: prefira persistência por cookie onde puder terminar o TLS, e recorra a endereço de origem apenas onde não puder.
Verificações de saúde decidem o que significa "no ar"
Um membro do pool é usado ou não conforme sua verificação de saúde, e a profundidade da verificação determina qual falha ela consegue enxergar.
Uma verificação de conexão TCP confirma que algo está escutando. Ela seguirá alegremente mandando tráfego a um servidor cuja aplicação travou atrás de um socket vivo.
Uma verificação HTTP busca uma página e pode conferir conteúdo esperado. Isso detecta a aplicação falhando, e não a porta fechando, que é a falha que de fato acontece.
Uma verificação com script ou de vários passos exercita uma transação real, que é o que se quer para uma aplicação cuja saúde depende de um banco de dados alcançável.
A regra prática é verificar tão fundo quanto a falha que você quer sobreviver. Uma verificação rasa num serviço crítico é a decisão de continuar servindo erros.
Otimização
Por terminar conexões, um ADC consegue melhorar a entrega além de distribuir.
O offload de SSL tira trabalho criptográfico dos servidores, e a decisão é se a perna interna é recriptografada. Fazer offload para texto claro exige confiar na rede interna; recriptografar, não.
A compressão troca CPU por banda e ajuda mais em texto.
O cache serve conteúdo estático repetido sem tocar num servidor.
A otimização de velocidade de página reescreve conteúdo — embutindo, minificando, adiando — para reduzir idas e voltas. É a que se introduz com cautela, porque muda o que o navegador recebe e pode quebrar um front end frágil. Teste antes de habilitar amplamente.
A multiplexação de conexões reutiliza conexões de backend entre requisições de clientes, o que reduz a rotatividade de conexões que os servidores tratam e frequentemente ajuda mais que a compressão que todos buscam primeiro.
O que quem vai prestar o exame precisa saber de cor
Servidores reais se agrupam em pools, um servidor virtual liga um endereço de escuta a um pool, e um perfil de aplicação descreve comportamento de protocolo. Menos conexões serve a durações variáveis e é o padrão sensato; hash de origem dá aderência como efeito colateral e é ferramenta grosseira de persistência. Persistência por cookie identifica uma sessão e é preferida onde o TLS é terminado; por endereço de origem colapsa clientes atrás de NAT num servidor. Verificações de saúde precisam ser tão profundas quanto a falha que se quer sobreviver, já que uma verificação TCP não percebe uma aplicação travada atrás de um socket vivo. O offload de SSL exige uma perna interna confiável salvo se recriptografada.