Definición
Un balanceador de carga es la pieza que se sitúa delante de varios servidores y reparte entre ellos las peticiones que llegan.
Desde fuera hay una sola dirección; por dentro hay varias máquinas atendiendo. Y aporta dos cosas distintas que conviene no mezclar:
Capacidad. Más máquinas atendiendo, más peticiones simultáneas. Es la parte que todo el mundo espera.
Disponibilidad. Si una máquina cae, el balanceador deja de mandarle tráfico y el servicio sigue. Esta suele ser la razón de verdad, más que la capacidad: elimina el punto único de fallo.
Cómo reparte
Por turnos. Una petición a cada servidor, en orden. Simple y sorprendentemente eficaz.
Por menos conexiones. Manda al servidor que menos trabajo tiene ahora mismo. Mejor cuando las peticiones duran tiempos muy distintos.
Por peso. Si una máquina es más potente, recibe más.
Por origen. El mismo cliente cae siempre en el mismo servidor. Se llama sesión pegajosa, y volveré sobre ello porque suele ser un parche.
Las comprobaciones de salud
Es la parte que hace que todo lo demás funcione. El balanceador pregunta periódicamente a cada servidor si está bien; si deja de responder correctamente, lo saca del reparto.
Y aquí está el detalle que decide si sirve de algo: la comprobación tiene que ser significativa. Un endpoint que devuelve «OK» sin comprobar nada acredita que el proceso web está vivo, no que el sistema funcione. Si la base de datos está caída, el servidor sigue diciendo «OK» y el balanceador le sigue mandando usuarios a una página de error.
Una comprobación útil verifica lo que la aplicación necesita de verdad para atender: conexión a la base de datos, acceso al almacenamiento. Y debe ser barata, porque se ejecuta cada pocos segundos.
Ejemplo práctico
Poner un balanceador es fácil. Lo que cuesta es que la aplicación esté preparada, y es exactamente el trabajo que describía en escalabilidad: nada de estado local, nada de ficheros en disco local, tareas programadas que no se dupliquen.
Lo que aprendí: la sesión pegajosa se ofrece como atajo para no tocar nada — el mismo usuario siempre al mismo servidor, y así la sesión en memoria local sigue funcionando. Funciona, y trae dos problemas que aparecen justo cuando peor viene: el reparto deja de ser equilibrado, porque los usuarios no se distribuyen uniformemente, y si cae ese servidor, esos usuarios pierden la sesión, que es precisamente el escenario que el balanceador debía cubrir.
Es un parche legítimo para ganar tiempo y no una solución. Lo correcto es sacar la sesión a un almacén compartido.
El segundo aprendizaje, operativo y muy útil: con un balanceador, desplegar sin cortar el servicio deja de ser difícil. Sacas una máquina del reparto, la actualizas, compruebas que va, la devuelves, y repites con la siguiente. Los usuarios no se enteran. Es una de las mejores razones para tener uno, y casi nadie la menciona al justificarlo. Ver despliegue.
Y una advertencia sobre lo que introduce: el balanceador es él mismo un punto único de fallo si hay uno solo. En servicios gestionados eso ya viene resuelto; montado a mano, hay que preverlo. Y añade un salto más: la dirección IP que ve tu aplicación pasa a ser la del balanceador, y hay que leer la cabecera correspondiente para saber quién llama de verdad — o los registros y el control de peticiones por IP dejan de servir.
Errores comunes
- Comprobación de salud que no comprueba nada.
- Sesión pegajosa como sustituto de sacar el estado fuera.
- Ficheros subidos a disco local.
- Tareas programadas duplicadas en cada máquina.
- No leer la cabecera de IP real y registrar siempre la del balanceador.
- Balanceador único presentado como alta disponibilidad.
- Servidores con configuraciones distintas, que producen el clásico «a veces falla».
Cuándo plantearlo
Cuando una caída del servidor sea inaceptable, cuando una sola máquina no dé abasto, o cuando quieras desplegar sin interrupciones.
Y con el orden correcto: primero la aplicación sin estado local, después el balanceador. Al revés, aparecen fallos intermitentes imposibles de reproducir.
