Crea un Balanceador de Carga desde la página Deploy en my.cubepath.com. El despliegue es rápido — los listeners y los targets de backend se añaden después, desde las pestañas del balanceador.
NotaTu cuenta debe estar verificada antes de poder desplegar.
Para qué sirve
Un balanceador te da una dirección pública estable delante de varios servidores, y deja de enviar tráfico a cualquiera que falle un health check. Eso te da dos cosas a la vez: puedes perder un backend sin perder el servicio, y puedes añadir o quitar backends sin tocar el DNS.
Desplegar
- 1Elige regiónEscoge una región. Hay balanceadores en Miami (MIA), Houston (HOU) y Barcelona (BCN).
- 2Elige un planCada plan fija el máximo de targets, listeners y conexiones por segundo, con precio mensual y por hora.
- 3Conecta una red privada (opcional)Conecta una red privada para que el balanceador llegue a los targets por su IP privada. Los targets deben estar en la misma red.
- 4Nombra y despliegaDefine el nombre (y una etiqueta opcional) y pulsa Deploy Load Balancer.
ImportanteLos listeners, los targets de backend y los health checks se configuran después del despliegue, desde la pestaña Listeners, no durante la creación. Un balanceador recién desplegado no acepta tráfico hasta que le añades un listener.
Algoritmo de distribución
En Settings, elige cómo se reparte el tráfico entre los targets:
| Algoritmo | Cómo se comporta | Úsalo cuando |
|---|---|---|
| Round Robin | Cada conexión nueva va al siguiente target por turno | Los backends son idénticos y las peticiones cuestan más o menos lo mismo |
| Least Connections | Las conexiones nuevas van al target con menos conexiones abiertas | La duración de las peticiones varía mucho: conexiones largas, streaming, consultas lentas |
Round robin es el valor por defecto razonable. Least connections es lo que quieres en cuanto algunas peticiones tardan mucho más que otras, porque round robin seguirá amontonando trabajo nuevo sobre un backend que ya está atascado con diez peticiones lentas.
Sesiones persistentes
Las sticky sessions dirigen las peticiones repetidas de un mismo cliente al mismo target, usando una cookie que tú nombras y un TTL que tú defines.
Actívalas cuando tu aplicación guarda el estado de sesión en memoria en cada servidor. Mejor aún: haz que no las necesite. Una aplicación que guarda las sesiones en un almacén compartido (una Valkey gestionada, por ejemplo) balancea limpiamente, sobrevive a la caída de un backend sin desconectar a todo el mundo, y te deja escalar sin barajar usuarios.
NotaCon la persistencia activa, quitar un target desconecta a los clientes fijados a él. Sopésalo frente a la comodidad.
IP flotante
El balanceador necesita una IP flotante para ser accesible desde internet. Asígnala en Settings; desasígnala para sacarlo de internet público sin eliminarlo.
Como la dirección es una IP flotante, pertenece a tu organización: puedes conservar la misma dirección pública tras una reconstrucción, y el DNS nunca tiene que cambiar.