F5 Load Balancer reenvía solicitud en tiempo de espera

Permítanme introducir esto diciendo que no soy administrador de sistemas, soy programador.

Recientemente, nuestros administradores de sistemas instalaron equilibradores de carga F5. Desde entonces, he notado que cada vez que una solicitud agota el tiempo de espera y termina arrojando un 500, el equilibrador de carga envía la misma solicitud a nuestro otro servidor. IIS envía la respuesta de tiempo de espera aunque el script todavía se está ejecutando. Incluso las solicitudes POST se duplican si un script se ejecuta durante más de 5 minutos. Esto me parece un problema potencial, especialmente con los sitios de comercio electrónico en los que está involucrada la facturación del cliente.

Esto es solo un problema con algunos de nuestros scripts de ejecución más larga (pero es un problema grave). Me han dicho que este es un comportamiento esperado, y tendremos que cambiar nuestro código para cumplir. Entonces mis preguntas son:

¿Es este comportamiento esperado?
¿Cuál es la ventaja de que el equilibrador de carga replica la solicitud después de un tiempo de espera que no sea que el usuario no tenga que actualizar?
Con esta arquitectura, si se ejecuta un script que bloquea el servidor o acapara los recursos, terminará ejecutándose en ambos servidores. ¿Es eso realmente óptimo?

iis load-balancing f5-big-ip

— Jim D
fuente

Cuando dice 'envía la misma solicitud' al otro servidor, ¿se refiere a las comprobaciones de estado configuradas o a las solicitudes de los usuarios? Mi sentido es no, pero vale la pena aclararlo. La respuesta a esto cambiará la respuesta y / o cualquier sugerencia.

— mcauth

@mcauth vuelve a enviar la solicitud del usuario. Básicamente, si un usuario realiza cualquier acción que provoque un error 500, el equilibrador de carga envía la misma solicitud exacta al otro servidor, creando así dos respuestas de una sola solicitud HTTP.

— Jim D

He estado en la órbita de Big-IP durante bastante tiempo, y nunca he sabido que reproduzca una solicitud a menos que se me indique específicamente que lo haga, por ejemplo, a través de un iRule que realiza una carga útil de solicitud HTTP :: recolectar al búfer . Muy raro. Sin ver la configuración en ejecución, es muy difícil decirlo.

— mcauth

Simplemente tope un poco este hilo para hacerle saber que estoy llegando exactamente al mismo problema. ¿Llegaste a resolverlo?

— BitMask777

@ BitMask777 - Lamentablemente, nunca hemos llegado más lejos con esto. Este sigue siendo el comportamiento del equilibrador de carga y hemos estado "lidiando con él".

— Jim D

Respuestas:

Eche un vistazo a esta entrada sobre monitoreo pasivo de aplicaciones en Big-IP

Mis respuestas a sus preguntas, por decepcionantes que puedan ser, son

Quizás (depende de la configuración de monitoreo pasivo)
El usuario no ve un error.
Tal vez (¿Quiero servir los errores de mis usuarios o intentar la solicitud en otro lugar?)

"Acción en servicio inactivo" es una configuración configurable.

— quadruplebucky
fuente

Gracias por tu respuesta. Tienes razón en que es un poco decepcionante, esperaba algo más concreto. Supongo que es concreto al explicar que simplemente no hay una respuesta definitiva.

— Jim D

Si se produce un error 500, esto indica un problema en el servidor web. El F5 simplemente reenviará este error al cliente de conexión. No "reenviará" la solicitud por sí misma. La única forma en que esto podría suceder es si el cliente vuelve a intentar la solicitud. En ese punto, esta solicitud posiblemente podría equilibrar la carga a otro miembro del grupo, aunque no hay garantía y se basaría en la persistencia o el método de equilibrio de carga utilizado (round robin, menos conexiones, etc.).

En resumen, a menos que tenga un iRule realmente loco en su F5, este es un comportamiento causado por el script en sí.

(Nota: fui ingeniero de soporte de Nework para F5 durante un año y medio trabajando con el LTM)

— James Shewey
fuente