Em um modelo de aplicação distribuída, quase sempre somos desafiados a criar arquiteturas que possibilitem o balanceamento de carga entre máquinas de um mesmo backend. Já falei sobre isso em post aqui mesmo no site há algum tempo atrás. Naquela ocasião apresentei os modelos de balanceamento de carga disponíveis no Azure e dentre eles, falei sobre o Application Gateway. Se você não sabe ou entende muito bem sobre “o que” estamos falando, recomendo fortemente efetuar a leitura daquele post antes de seguir com a deste.
O Application Gateway (AG) é um serviço de rede extremamente útil em vários aspectos. Balancear carga com a possibilidade de conservar a sessão do usuário através de cookies é apenas uma das muitas possibilidades. Com ele é possível criar comportamentos específicos (regras) para diferentes configurações HTTP, definir listeners, criar comportamento de proxy reverso, fazer offload de SSL, dentre tantas outras funcionalidades.
Para prover esta ampla gama de funcionalidades, o Application Gateway acabou se tornando uma ferramenta granular (o que é extremamente positivo para quem precisa de controle detalhado quanto ao funcionamento do recurso). Dentro deste contexto de granularidade encontra-se a possibilidade de definir health probes personalizadas para determinada configuração HTTP/HTTPS. Dessa maneira, nos próximos parágrafos deste post quero discutir dois aspectos principais relacionados aos probes: 1) o que é; 2) problemas que eles resolvem e quando você deve se preocupar com isso.
O que é e como trabalha um “health probe”?
Se você for até um tradutor e digitar esta expressão (health probe), verá que a resposta será “Sondagem de saúde” ou outra semelhante a esta. Essa definição é ótima porque resume de maneira exata a atuação de uma probe no contexto de um balanceador de carga (como é o caso do Application Gateway).
O AG, por padrão, monitora a saúde de todas as instâncias dentro de seu backend pool (região lógica de agrupamento das máquinas virtuais cujo AG distribui as cargas). Isso é transparente para o usuário mas, no momento em que um AG é criado, ele (Azure) automaticamente ele adiciona um health probe com valores default para aquele AG e, a partir daí, de tempos em tempos e baseado em parâmetros específicos, as instâncias são monitoradas. Se por um motivo qualquer (manutenção, por exemplo) determinada instância dentro do backend pool ficar indisponível (ver Figura 1), automaticamente o AG começa a direcionar as cargas apenas para as instâncias que estão “de pé”.
Figura 1. Health probe monitorando as instâncias do backend pool
Um aspecto importante é que o monitoramento se extende também para as instâncias já identificadas como “offline”. Isso é feito porque é possível que, em algum momento, aquela instância volte a estar disponível para receber carga de processamento.
Você pode estar se perguntando a esta altura: “Mas como a probe sabe que determinada instância está saudável?”. É simples. A cada x segundos um request HTTP ou HTTPS é enviado para uma URL configurada na probe. Se a resposta a este request for um código de status entre 200 e 309, a instância será considerada “saudável”. Caso contrário, não saudável.
Health probe default x personalizada
Conforme mencionado anteriormente neste texto, se você for até o portal do Azure agora e criar um novo AG, automaticamente um health probe default será adicionado ao mesmo e o monitoramento já estará ocorrendo. Os valores automaticamente adicionados para a probe default são apresentados pela tabela 1.
Tabela 1. Valores para a probe padrão do AG
Acedito que uma explicação se faça necessária aqui, certo?
- Probe URL. Aqui temos a definição do endpoint para onde os requests serão enviados. Neste caso, este monitoramento funcionará apenas para as máquinas que estiverem na mesma rede do AG (sim, o AG pode rotear requests para máquinas em outras redes e neste caso, precisaria ter o endpoint público das máquinas).
- Interval. De quanto em quanto tempo o AG irá enviar um request para a instância do backend pool. No caso da probe default, a cada 30 segundos a verificação será realizada.
- Time-out. O tempo que o AG deve esperar antes de assinar determinado request com time-out. Neste caso, 30 segundos.
- Unhealthy threshold. Número de tentativas consecutivas (retry) que o AG deve fazer até que determinada instância seja considerada não saudável. Neste caso, se na terceira tentativa um código válido não for retornado, a instância estará invalidada para o AG.
Para muitos casos a configuração padrão do Application Gateway é suficiente em termos de monitoramento do backend, entretanto, para outra quantidade considerável de casos, esta configuração não é adequada. Por exemplo, se a aplicação que se pretende balancear tem tempos curtos de iteração do usuário com as funcionalidades e chamadas sucessivas ao backend, 30 segundos para para realizar uma verificação de saúde do servidor pode ser uma eternidade. Para esses casos, uma probe personalizada é quem irá resolver o problema.
Uma situação real para probe personalizada
Recentemente, ao trabalhar em um projeto de migração para Azure em dos nossos clientes aqui na Microsoft, durante o período de testes, identificamos um “problema” com a configuração padrão de probe do Application Gateway. O cliente possui um modelo de operação da infra em que, de tempos em tempos, para fins de manutenção nos servidores de aplicação, as máquinas vão uma a uma (e uma por vez, evidentemente) sofrendo um processo de manutenção/atualização. Para fazer isso, a máquina da vez é retirada do AG. Quando isso ocorria, todos os usuários “pendurados” naquele servidor pelo sticky session, recebiam o erro 502 (conforme apresenta a Figura 2) e alguns instantes após (em torno de 4 minutos), o usuário voltava a ter sua navegação reestabelecida.
Figura 2. Erro exibido para o usuário quando o servidor saía do backend pool
Não precisamos nem mencionar o quão impactante isso (aplicação fora por 4 minutos) foi, certo? A solução para este “problema” estava justamente em se ajustar a configuração de probe do AG. O que fizemos? Criamos um novo health probe e o atachamos à configuração HTTP que se aplicava. Ver Figura 3.
Figura 3. Custom probe configurada para atender a demanda do cliente
Como mencionado anteriormente, o que fizemos aqui foi adicionar uma nova configuração de health probe. As diferenças em relação a probe default (e que impactaram positivamente para a solução do problema) são as seguintes:
- Ao invés de monitorar 127.0.0.1, estamos monitorando o endpoint “de produção” da aplicação (veja o campo “host”). Neste caso nem precisaríamos fazer dessa maneira. Se monitorássemos 127.0.0.1 teria o mesmo comportamento porque todas as máquinas do backend estão na mesma rede do AG. Quisemos apenas reproduzir a navegação do usuário.
- O protocolo que nos interessa é HTTP na porta 80.
- Como estamos especificando um endpoint púbico, precisamos complementar com o path que queremos monitorar.
- Na sequência reduzimos o intervalo de tempo de envio de requests de 30 segundos para 5 segundos. Ou seja, ao invés de esperar 30 segundos para verificar a disponibilidade do servidor, esperamos apenas 5 segundos e dessa forma, conseguimos desviar o fluxo de execução para os demais servidores do pool mais rapidamente.
- Ao invés de esperarmos 30 segundos como tempo de resposta para um request, levantamos o tempo médio de resposta da aplicação e ajustamos o timeout para atender a este requisito.
- O mesmo ocorreu com o número de tentativas. Reduzimos para apenas duas tentativas.
Todos estas informações juntas resultaram na transferência dos usuários de um servidor que “caiu” para um servidor “ativo” em questão de poucos segundos. Bacana, não? Para relacionar esta nova probe a configuração HTTP respectiva, navegamos até a mesma, marcamos a opção “Use custom probe” e na sequência selecionamos a regra recém criada, como você pode visualizar na Figura 4.
Figura 4. Adicionando a custom probe à configuração HTTP
Vale observar que esta decisão tem que ser tomada com certa cautela, uma vez que “pingar” cada instância do backend a cada 5 segundos pode gerar um overhead significativo para o Application Gateway. Esses tempos de configuração devem ser cuidadosamente levantados. Considere também a possibilidade de elevar o número de instâncias do AG em caso de queda de performance.
Por hoje é só! Espero que esta dica possa ser útil.
Abraços.
Facebook
Twitter
Instagram
LinkedIn
RSS