¿Cuáles son las técnicas con estado y sin estado en el equilibrio de carga?

Generalmente hablando:

Con estado significa que el sistema puede estar en diferentes … estados: la misma entrada puede producir una salida diferente basada en otra información en el sistema, como información almacenada de datos anteriores o datos recopilados de otras fuentes.

Los sistemas sin estado son un conjunto de reglas que solo actúan sobre la información que procesan en este momento.

Un equilibrador de carga con estado puede ver varias cosas antes de elegir el servidor para manejar una solicitud, como la carga de los diferentes servidores, estadísticas de cuántos clientes envió recientemente a cada servidor o una tabla de qué servidor manejó un cliente determinado la última vez.

Un equilibrador de carga sin estado es más simple: un método común es reducir la dirección IP del cliente a un número pequeño, luego usar ese número para decidir el servidor (que es ordenado, ya que enviará el mismo cliente al mismo servidor sin tener que recordar cualquier cosa). También podría elegir uno completamente al azar, o ir por turnos (cada solicitud va al siguiente servidor). Eso sí, round-robin mantiene un poco de estado (qué servidor usó por última vez), pero creo que todavía suele contarse como apátrida.

La respuesta se reduce a si la solicitud se reenvía o no según los estados del sistema.

Por ejemplo, en un esquema de equilibrio de carga sin estado, las búsquedas de tablas hash y otras técnicas se pueden utilizar para elegir el mismo nodo por sesión o un nodo aleatorio para reenviar el tráfico (dependiendo de cómo se reenvíe el tráfico). Se podría argumentar que el equilibrio de carga round-robin es prácticamente sin estado porque solo mantiene muy pocos datos sobre el estado del nodo.

Por el contrario, un esquema de equilibrio de carga con estado realiza un seguimiento de los estados de sesión. Las sesiones pueden significar cosas diferentes para diferentes usuarios. El equilibrio de carga con estado puede mantener el estado de una sesión tcp u otras sesiones más avanzadas que el software puede establecer entre puntos finales. Mantener el estado de una sesión entre puntos finales y luego usar esa información de sesión para tomar la decisión de cómo reenviar el tráfico mantiene las solicitudes entrantes y la carga de solicitud existente “en equilibrio” o eso espera el equilibrador de carga con estado. Deben considerarse los costos del mantenimiento del estado y los posibles efectos de latencia del mantenimiento del estado.

La latencia general, el rendimiento y los costos (incluida la gestión operativa y computacional, como el mantenimiento del estado y los costos de la lógica de paquetes) deben evaluarse antes de sacar conclusiones sobre qué enfoque tiene el mejor sentido para los usuarios, operadores y partes interesadas del negocio, etc.

Una buena serie de preguntas es: “¿Cuántos datos estatales guardamos? ¿Cuánto cuesta recolectar? ¿Cuántos datos de estado estamos viendo antes de reenviar un paquete? ¿Con qué frecuencia volvemos a verificar el estado? ¿Cuánto dura una sesión? ¿Cuánto cuesta verificar el estado (en cuanto al tiempo y al ciclo de la CPU) antes de reenviar un paquete? ¿Vale la pena pagar estos costos? ¿Esta lógica más sofisticada es mejor que reenviar paquetes sin verificar el estado? ”Y la respuesta podría ser sí.