L'équilibreur de charge F5 renvoie la demande après expiration du délai

Permettez-moi de dire ceci en disant que je ne suis pas administrateur système, je suis programmeur.

Récemment, nos administrateurs systèmes ont installé des équilibreurs de charge F5. Depuis lors, j'ai remarqué que chaque fois qu'une demande expire et finit par lancer un 500, l'équilibreur de charge envoie la même demande à notre autre serveur. IIS envoie la réponse de délai d'attente même si le script est toujours en cours d'exécution. Même les requêtes POST sont dupliquées si un script s'exécute pendant plus de 5 minutes. Cela me semble être un problème potentiel, en particulier avec les sites de commerce électronique où la facturation des clients est impliquée.

Ce n'est qu'un problème avec quelques-uns de nos scripts plus longs (mais c'est un problème sérieux). On m'a dit que c'est un comportement attendu, et nous devrons changer notre code pour qu'il soit conforme. Mes questions sont donc:

Est-ce un comportement attendu?
Quel est l'avantage de l'équilibreur de charge répliquant la demande après un délai d'expiration autre que l'utilisateur n'ayant pas à actualiser?
Avec cette architecture, si un script qui bloque le serveur ou les ressources de porcs est exécuté, il finira par s'exécuter sur les deux serveurs. Est-ce vraiment optimal?

iis load-balancing f5-big-ip

— Jim D
source

Lorsque vous dites «envoie la même demande» à l'autre serveur, faites-vous référence aux contrôles de santé configurés ou aux demandes des utilisateurs? Mon sentiment est non, mais cela mérite d'être clarifié. La réponse à cela modifiera la réponse et / ou toute suggestion.

— mcauth

@mcauth, il renvoie la demande de l'utilisateur. Fondamentalement, si un utilisateur effectue une action qui provoque une erreur 500, l'équilibreur de charge envoie la même demande exacte à l'autre serveur, créant ainsi deux réponses à partir d'une seule demande HTTP.

— Jim D

Je suis sur l'orbite de Big-IP depuis assez longtemps, et je ne l'ai jamais connu pour rejouer une demande, sauf si on me le demandait spécifiquement, par exemple, via une iRule faisant un HTTP :: collect pour mettre en mémoire tampon la charge utile de la demande . Très étrange. Sans voir la configuration en cours, c'est très difficile à dire.

— mcauth

Il suffit de cogner un peu ce fil pour vous faire savoir que je rencontre exactement le même problème. Êtes-vous allé plus loin dans sa résolution?

— BitMask777

@ BitMask777 - Malheureusement, nous ne sommes jamais vraiment allés plus loin avec cela. C'est toujours le comportement de l'équilibreur de charge et nous l'avons "traité".

— Jim D

Réponses:

Jetez un œil à cette entrée sur la surveillance passive des applications dans Big-IP

Mes réponses à vos questions, aussi décevantes soient-elles, sont

Peut-être (dépend de la configuration de surveillance passive)
L'utilisateur ne voit pas d'erreur
Peut-être (est-ce que je veux signaler les erreurs de mes utilisateurs ou essayer la demande ailleurs?)

"Action on Service Down" est un paramètre configurable.

— quadruplebucky
source

Merci pour votre réponse. Vous avez raison, c'est un peu décevant, j'espérais quelque chose de plus concret. Je suppose qu'il est concret d'expliquer qu'il n'y a tout simplement pas de réponse définitive.

— Jim D

Si une erreur 500 se produit, cela indique un problème sur le serveur Web. Le F5 transmettra ensuite simplement cette erreur au client qui se connecte. Il ne "renverra" pas la demande de son propre gré. Le seul moyen pour que cela se produise est que le client réessaie la demande. À ce stade, cette demande peut éventuellement être équilibrée en charge vers un autre membre du pool, bien qu'il n'y ait aucune garantie et qu'elle soit basée sur la persistance ou la méthode d'équilibrage de charge utilisée (round robin, moindres connexions, etc.).

En bref, à moins que vous n'ayez une iRule vraiment folle sur votre F5, c'est un comportement causé par le script lui-même.

(Remarque: j'étais un ingénieur de support de Nework pour F5 pendant un an et demi travaillant avec le LTM)

— James Shewey
source