Según tengo entendido, según la documentación de NGINX Plus, su equilibrio de carga evitará servidores que estén inactivos o saturados y que la persistencia de sesión intenta mantener el mismo servidor para una sesión determinada. Parece que los dos podrían volverse mutuamente excluyentes cuando un servidor deja de funcionar a mitad de sesión. ¿Hay una indicación de falla del servidor, de modo que sepamos que puede haber alguna pérdida de datos debido al cambio a otro servidor (que podría no haber ocurrido en los cambios durante la sesión) o se cambia silenciosamente?
Esto es específicamente para la comunicación TCP/UDP, no para HTTP.
Respuesta1
Parece que los dos podrían volverse mutuamente excluyentes.
Sí. Ese no es un problema específico de nginx. Con diferencia, la mejor solución es tener los datos de su sesión replicados/altamente disponibles, pero no es fácil incorporarlo a un servicio existente que no ha sido bien planificado.
¿Qué quiere que haga nginx cuando falla el servidor que implementa una sesión? ¿Conmutación por error a cualquier otro servidor? ¿Conmutación por error a un servidor específico? ¿Están sus servidores en pares? ¿algo más? Detenga la sesión, ya que se encuentra en un estado indeterminado... Hay tantas opciones.
En cuanto a reporte de fallas. Hay 2 partes en esto. Uno es el monitoreo: alguien necesita que le digan que algo está roto o necesita ser reparado. Este no es el trabajo de Nginx. Eso lo debe manejar su pila de monitoreo. La segunda parte es hacerle saber al cliente que algo no ha funcionado. Nginx no sabe que debería volver a poner el stock en los estantes/volver a aplicar el cambio de DNS. Ese es el trabajo, el protocolo que está ejecutando y la aplicación. Si bien existen problemas de sincronización, la mayoría de los protocolos de red utilizan un intercambio de mensajes cortos de solicitud/respuesta para proporcionar visibilidad del estado del servidor en el cliente. En el caso de (la mayoría) de las bases de datos, esto está muy bien definido con un mensaje explícito "COMMIT" del cliente. Pero considere lo que sucede si el cliente dice "COMPROMISO" y no recibe respuesta.
Esto es específicamente para la comunicación TCP/UDP, no para HTTP.
Al igual que @PersionGulf, recomendaría usar HAProxy para equilibrio de carga no HTTP/HA de TCP sobre nginx. La última vez que lo comprobé no puede hacer UDP.
No indica cómo funciona en caso de falla.
No es difícil probarlo.