> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/productos/servers/how-to/how-to-deploy-a-load-balancer.md).

# Cómo Desplegar un Balanceador de Carga

Un balanceador de carga reparte las peticiones entre varios servidores, de modo que ninguno se sobrecargue y el servicio siga en pie aunque uno falle.

En este tutorial creas una regla de balanceo sobre un pool de al menos dos servidores de la misma suscripción.

> #### 👍 Qué consigues
>
> Una regla de balanceo publicando un servicio en una IP pública y repartiendo el tráfico entre los servidores que elijas.

### Cómo encaja el balanceo

El tráfico llega a una IP y un puerto públicos, y el balanceador lo reparte entre los servidores del pool según un algoritmo. Para que esto funcione, todos los servidores del pool tienen que servir lo mismo: el balanceo distribuye la carga, no sincroniza el contenido.

> #### 📘 Reparte carga, no es alta disponibilidad total
>
> El balanceo mejora la disponibilidad y absorbe picos, pero no convierte tu servicio en infalible. 
>
> Si un servidor del pool sirve algo distinto a los demás, el cliente verá respuestas inconsistentes. Mantén el mismo contenido y configuración en todos.

### Antes de empezar

* Iniciar sesión en la plataforma de Plenit con un usuario con permisos de administración sobre la organización.
* Tener al menos **dos servidores** desplegados en la misma suscripción. Puedes crear la regla antes de añadirlos e incorporarlos después.

### Paso 1. Accede a Load Balancers

1. Entra en la suscripción de **Servidores** desde su card.
2. Abre la subsección **Load Balancers** del menú lateral izquierdo.

{/\* 📸 CAPTURA 1 · menú lateral con la subsección Load Balancers \*/}

![Acceso a la subsección Load Balancers](https://REEMPLAZA-URL/servidores-howto-lb-01.png)

### Paso 2. Crea una nueva regla

Si aún no hay reglas, verás la pantalla inicial para crear una; si ya existen, verás el listado. Selecciona la **Network** sobre la que vas a crear la regla y pulsa **New rule**.

{/\* 📸 CAPTURA 2 · selección de la Network y el botón New rule \*/}

![Creación de una nueva regla de balanceo sobre una red](https://REEMPLAZA-URL/servidores-howto-lb-02.png)

### Paso 3. Configura red, IP y puertos

1. Elige la red con **Select network**.
2. Selecciona una **Public IP** de las disponibles para esa red.
3. Define el **Protocol** (`TCP` o `UDP`), el **Public Port** (por el que entran las peticiones desde Internet, por ejemplo `80` o `443`) y el **Private Port** (al que se reenvían internamente).
4. Pulsa **Next**.

> #### 🚧 Un puerto, un único uso por red
>
> Dentro de una misma red, un puerto solo puede usarse una vez: no puede haber dos reglas para el mismo puerto en el mismo espacio de red.

{/\* 📸 CAPTURA 3 · campos Public IP, Protocol, Public Port y Private Port \*/}

![Configuración de IP pública, protocolo y puertos](https://REEMPLAZA-URL/servidores-howto-lb-03.png)

### Paso 4. Define qué redes tendrán acceso

Indica desde qué IPs se puede acceder al servicio publicado:

* **Any**: acceso desde cualquier red. Es la opción menos segura.
* **Specify**: acceso solo desde las IPs o rangos que indiques.

Con **Specify**, introduce la IP o el rango permitido (puedes añadir varios) y pulsa **Next**.

{/\* 📸 CAPTURA 4 · opción Specify con la IP o rango permitido \*/}

![Definición de las redes con acceso al servicio publicado](https://REEMPLAZA-URL/servidores-howto-lb-04.png)

### Paso 5. Elige el algoritmo y la afinidad

Selecciona cómo se reparten las peticiones entre los servidores del pool:

| Algoritmo         | Qué hace                                                     | Cuándo encaja                                             |
| ----------------- | ------------------------------------------------------------ | --------------------------------------------------------- |
| Round Robin       | Reparte por turnos, de forma circular                        | Caso general, servidores equivalentes                     |
| Least connections | Envía cada petición al servidor con menos conexiones activas | Peticiones de duración desigual                           |
| Source            | Asigna según la IP de origen                                 | Cuando un mismo cliente debe ir siempre al mismo servidor |

Después, decide si activas las **reglas de afinidad**. Actívalas si la aplicación guarda el estado de la sesión en el propio servidor y no lo comparte entre máquinas; si lo haces, completa **Table size (KB)** y **Expiration(s)**. Pulsa **Next**.

> 📘 La afinidad mantiene al cliente en el mismo servidor
>
> Sin estado compartido entre servidores, repartir a ciegas puede cortar la sesión de un usuario a media navegación. La afinidad lo evita atándolo a un servidor, a cambio de un reparto algo menos uniforme.

{/\* 📸 CAPTURA 5 · selección del algoritmo y la opción de afinidad \*/}

![Selección del algoritmo de reparto y la afinidad](https://REEMPLAZA-URL/servidores-howto-lb-05.png)

### Paso 6. Selecciona los servidores del pool

Elige las máquinas que responderán a las peticiones. Pulsa cada elemento que aparece como **Not selected** y asígnale la IP correspondiente. Un servidor bien añadido muestra un check y el contorno marcado en color de Plenit. Cuando termines, pulsa **Create Rule**.

{/\* 📸 CAPTURA 6 · selección de los servidores del pool con el check de añadido \*/}

![Selección de los servidores que forman el pool del balanceador](https://REEMPLAZA-URL/servidores-howto-lb-06.png)

### Paso 7. Verifica que la regla se ha creado

Durante la creación verás un mensaje del tipo `Servers: Creating Load Balancer ...` y, al terminar, otro confirmando que se ha creado correctamente. La regla aparece en el listado, aunque quizá tengas que refrescar la pantalla.

Para comprobar que el servicio responde de verdad, prueba el endpoint público desde fuera. En Linux o macOS:

```bash
curl -I http://<IP-PUBLICA>:<PUERTO-PUBLICO>
```

En Windows, desde PowerShell:

```powershell
Test-NetConnection <IP-PUBLICA> -Port <PUERTO-PUBLICO>
```

Y en cada servidor del pool, confirma que el servicio escucha en el puerto privado. En Linux:

```bash
ss -tlnp | grep <PUERTO-PRIVADO>
```

En Windows:

```powershell
netstat -ano | findstr <PUERTO-PRIVADO>
```

### Si algo no encaja

| Síntoma                                | Causa probable                                        | Qué hacer                                                  |
| -------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------- |
| No deja crear la regla por el puerto   | Ese puerto ya está en uso en la red                   | Usa otro puerto público o libera el existente              |
| El endpoint público no responde        | Ningún servidor del pool escucha en el puerto privado | Revisa con `ss` / `netstat` que el servicio está levantado |
| Un usuario pierde la sesión al navegar | Reparto sin estado compartido                         | Activa la afinidad o comparte el estado entre servidores   |

### Conclusión

Con esto tienes un servicio publicado tras un balanceador que reparte el tráfico entre varios servidores, lo que suaviza los picos y mantiene el servicio aunque una máquina falle. El balanceo rinde de verdad cuando el pool es homogéneo y eliges el algoritmo acorde a tu carga: ahí dejas de repartir peticiones a ciegas y empiezas a repartir con criterio.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.plenit.com/productos/servers/how-to/how-to-deploy-a-load-balancer.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.