O balanceador de carga F5 reenvia a solicitação no tempo limite

Permitam-me que comece por dizer que não sou administrador de sistemas, sou programador.

Recentemente, nossos administradores de sistemas instalaram balanceadores de carga F5. Desde então, notei que sempre que uma solicitação atinge o tempo limite e acaba gerando 500, o balanceador de carga envia a mesma solicitação ao nosso outro servidor. O IIS envia a resposta de tempo limite, mesmo que o script ainda esteja em execução. Até as solicitações POST são duplicadas se um script for executado por mais de 5 minutos. Parece-me um problema em potencial, especialmente em sites de comércio eletrônico em que o faturamento do cliente está envolvido.

Este é apenas um problema com alguns de nossos scripts de execução mais longa (mas é um problema sério). Foi-me dito que esse é um comportamento esperado e teremos que alterar nosso código para estar em conformidade. Então, minhas perguntas são:

Esse comportamento é esperado?
Qual é a vantagem do balanceador de carga replicar a solicitação após um tempo limite diferente do usuário não ter que atualizar?
Com essa arquitetura, se um script que atolar o servidor ou consumir recursos for executado, ele será executado nos dois servidores. Isso é realmente ideal?

iis load-balancing f5-big-ip

— Jim D
fonte

Quando você diz 'envia a mesma solicitação' para o outro servidor, está se referindo às verificações de integridade ou solicitações de usuário configuradas? Meu senso é não, mas vale a pena esclarecer. A resposta para isso mudará a resposta e / ou quaisquer sugestões.

— mcauth

@mcauth reenvia a solicitação do usuário. Basicamente, se um usuário fizer alguma ação que solicite um erro 500, o balanceador de carga envia a mesma solicitação exata para o outro servidor, criando assim duas respostas a partir de uma única solicitação HTTP.

— Jim D

Estou na órbita do Big-IP há muito tempo e nunca soube reproduzir uma solicitação, a menos que seja especificamente instruído a fazê-lo, digamos, por meio de uma iRule executando HTTP :: collect para armazenar em buffer a carga útil da solicitação . Muito estranho. Sem ver a configuração em execução, é muito difícil dizer.

— Mcauth #

Apenas colidindo um pouco com este tópico para informar que estou atingindo exatamente o mesmo problema. Você avançou mais na resolução?

— BitMask777

@ BitMask777 - Infelizmente nunca mais chegamos a isso. Esse ainda é o comportamento do balanceador de carga e estamos "lidando com ele".

— Jim D

Respostas:

Veja esta entrada no monitoramento passivo de aplicativos no Big-IP

Minhas respostas para suas perguntas, por mais decepcionantes que sejam, são

Talvez (depende da configuração do monitoramento passivo)
O usuário não vê um erro
Talvez (desejo exibir erros aos meus usuários ou tentar a solicitação em outro lugar?)

"Ação em serviço desativado" é uma configuração configurável.

— quadruplebucky
fonte

Obrigado pela sua resposta. Você está certo, pois é um pouco decepcionante, eu esperava algo mais concreto. Eu acho que é concreto explicar que simplesmente não há resposta definitiva.

— Jim D

Se ocorrer um erro 500, isso indica um problema no servidor da web. O F5 simplesmente encaminhará esse erro para o cliente que está se conectando. Ele não "reenviará" o pedido por si próprio. A única maneira de isso acontecer é se o cliente tentar novamente a solicitação. Nesse ponto, essa solicitação poderia ser balanceada por carga para outro membro do pool, embora não haja garantia e basear-se-ia na persistência ou no método de balanceamento de carga usado (round robin, menos conexões, etc.).

Em resumo, a menos que você tenha um iRule realmente louco no seu F5, esse é um comportamento causado pelo próprio script.

(Nota: Eu fui engenheiro de suporte da Nework na F5 por um ano e meio trabalhando com o LTM)

— James Shewey
fonte