Algunos gráficos

Sin balanceador de carga: 

Con balanceador de carga: 

Precio Load Balancing (aka LB)

 

• 20 equilibradores de carga (load balancers)
• 20 Pools
• 2 puntos finales (endpoints)
• Health checks (monitors) cada 60 segundos 
• Checkeos desde una sola región 

Es decir, el plan más económico sólo se admite máximo 2 puntos finales. (2 sistemas de backup)

• Por cada endpoint que adicional que añadimos tenemos que pagar 5$ al mes
• Health monitor cada 30 segundos 10$ al mes y cada 15 segundos 15$ al mes
• Check desde 4 regiones diferentes cuesta 10$ al mes y desde 8 regiones 15$ al mes
• Traffic Steering (Direccionamiento del tráfico) Dirigir dinámicamente el tráfico a los grupos más rápidos o crear políticas de direccionamiento geográfico cuesta 10$ al mes

 

Ejemplo regiones: 

• All Regions (Default)
• All Data Centers (Enterprise Only)
• Western North America
• Eastern North America
• Western Europe
• Eastern Europe
• Northern South America
• Southern South America
• Oceania
• Middle East
• Northern Africa
• Southern Africa
• Southern Asia
• Southeast Asia
• Northeast Asia

 

 Precio Consultas

Las primeras 500.000 consultas, compartidas entre todos los equilibradores de carga de su cuenta, son gratuitas. El uso adicional se cobra a 50 céntimos por cada 500 000 solicitudes por nombre de host habilitado y se factura al final de cada mes. 

Entonces bueno pues 1 Millón de consultas costarán = 1€  y 10M = 10€

No son consultas DNS, son peticiones al Pool, y sólo se  cuenta la primera petición. Por ejemplo si nuestros sitios tienen 500k peticiones https mensuales, (porque una petición https, pues incluye scripts js, imágenes, etc) y las peticiones al Pool serán bastantes menos. Es decir, sólo cuenta la primera petición para saber que endpoint tiene que servir la respuesta.

Las solicitudes de equilibrio de carga son el número de solicitudes no almacenadas en caché realizadas por su equilibrador de carga. De forma predeterminada, Cloudflare almacena en caché las direcciones IP resueltas durante un máximo de cinco segundos.

Es importante añadir una notificación por e-mail al ser del tipo "Usage based billing", nos avisará cuando superemos x número de consultas, por ejemplo 400.000, sabiendo que las primeras 500.000 son gratuitas.

Load Balancing tiene la opción «Notificar cuando el número total de consultas DNS supere el umbral».

Los tres componentes básicos son:

• Load Balancers
• Pools
• Monitors 

Que ahora veremos en detalle. 

Load Balancers

Pools

• Hostname 

Hostname será el registro DNS, es decir una entrada DNS, puede ser el root @ o un subdominio 

•  Endpoints

• Peso - Weight

Podemos (debemos) añadir  la distribución del endpoint, es decir que porcentaje de tráfico recibirá el endpoint.

Podemos repartir el tráfico por defecto 100% endpoint  A y 0% endpoint B de manera que sólo recibirá tráfico cuando el endpoint A esté caído.

El endpoint acepta Host "headers"  (cabeceras) por ejemplo si tenemos varios vhosts en apache o nginx sobre una misma IP, pues con el Host Header, indicamos cuál vhost queremos mostrar.

Ejemplo Peso (Weight)

A continuación se muestra un ejemplo en el que se aplican ponderaciones a tres extremos con una política de dirección de extremos aleatoria:

• Ponderaciones: EndPoint A = 0,25; EndPoint B = 0,25; EndPoint C = 0,50

Cuando todos los EndPoint (extremos) están en buen estado, cada EndPoint recibirá la siguiente proporción del tráfico total: A = 25 %; B = 25 %; C = 50 %.

Cuando un EndPoint no está en buen estado (como el EndPoint C), cada EndPoint en buen estado recibirá la siguiente proporción del tráfico total: A = 50 %; B = 50 %.

Un EndPoint con un peso de 0 no debe recibir ningún tráfico enviado a ese grupo (pool) (aunque el EndPoint seguirá recibiendo solicitudes del monitor de estado).

Notificaciones Pool 

Notificaciones de grupos: puedes configurar nuevas alertas (y ver las existentes) para recibir notificaciones cuando se habiliten o deshabiliten grupos, o cuando los grupos o puntos finales experimenten cambios en su estado de integridad. 

Es decir, podemos recibir un e-mail cuando un endpoint esté caído (no disponible) mediante las notificaciones por e-mail o ejecutar un webhook. 

 Estados del Pool

Cuando un punto final individual (endpoint) deja de estar en buen estado, esto puede afectar al estado de salud de cualquier pool asociado (visible en el panel de control):

• Sano: todos los puntos finales están sanos.
• Degradado: al menos un punto final no está sano, pero el grupo sigue considerándose sano y podría estar recibiendo tráfico.
• Crítico: el grupo ha caído por debajo del número de extremos disponibles especificado en su umbral de estado y no recibirá tráfico de su equilibrador de carga (a menos que otros grupos tampoco estén en buen estado y este grupo esté marcado como grupo de reserva).
• Estado desconocido: no hay monitores conectados a los extremos del grupo o los monitores aún no han determinado el estado de los extremos.
•  Sin estado: reservado para el grupo de reserva de su equilibrador de carga.

Cómo un equilibrador de carga deja de estar en buen estado

Cuando uno o más pools dejan de estar en buen estado, es posible que su equilibrador de carga también muestre un estado diferente en el panel de control:

• En buen estado: todos los grupos están en buen estado.
• Degradado: al menos un grupo no está en buen estado, pero el tráfico aún no se dirige al grupo de reserva.
• Crítico: todos los grupos están en mal estado y el tráfico se dirige al grupo de reserva.

Si un equilibrador de carga alcanza un estado crítico y el grupo que sirve como grupo de reserva (fallback pool) también está desactivado:

• Si Cloudflare actúa como proxy de su nombre de host, verá un error 530 HTTP/1016 Origin DNS.
• Si Cloudflare no actúa como proxy de su nombre de host, verá el registro SOA.

Fallback Pool

Grupo de reserva

En caso de que todos los grupos estén marcados como inactivos, Cloudflare utiliza el grupo de reserva, que es la última opción para enviar tráfico a un punto final con éxito. Dado que el grupo de reserva es el último recurso, no se tiene en cuenta su estado y Cloudflare informa de su estado como «Sin estado».

También debes decidir cuál de los grupos asociados en un equilibrador de carga debe ser el grupo de reserva.

Este grupo está destinado a ser el último recurso, lo que significa que su estado no se tiene en cuenta a la hora de dirigir el tráfico.

Los grupos de reserva son importantes porque es posible que el tráfico siga llegando al equilibrador de carga incluso cuando todos los grupos estén inaccesibles (desactivados o en mal estado). El equilibrador de carga necesita un lugar al que dirigir este tráfico, por lo que lo enviará al grupo de reserva.

Traffic Steering

 Cloudflare dirigirá el tráfico a los grupos de estas regiones. El tráfico se dirige a los grupos por orden de disponibilidad. El tráfico fuera de estas regiones se ajustará a la política de conmutación por error definida previamente.

• Desactivado: Cloudflare dirigirá los grupos (pools) en orden de conmutación por error.
• Direccionamiento dinámico: dirige el tráfico al grupo más rápido en función de la latencia medida en las comprobaciones de estado.
• Direccionamiento geográfico: enruta a grupos específicos en función de la región de Cloudflare que atiende la solicitud.
• Direccionamiento por proximidad: enruta las solicitudes al grupo físico más cercano.
• Direccionamiento aleatorio: enruta a un grupo en buen estado de forma aleatoria o aleatoria ponderada.
• Direccionamiento por solicitudes pendientes mínimas: enruta el tráfico en función de las ponderaciones de los grupos y el número de solicitudes pendientes.

Al pool debemos añadir un Monitor.

 Monitors - Health Checks 

 

- [25/Oct/2025:10:15:25 +0200] "GET / HTTP/2.0" 200 6853 "-" "Mozilla/5.0 (compatible; Cloudflare-Traffic-Manager/1.0; +https://www.cloudflare.com/traffic-manager/; pool-id: XXX)"
172.68.10.207 - 

- [25/Oct/2025:09:20:11 +0200] "GET / HTTP/1.1" 200 4523 "-" "Mozilla/5.0 (compatible; Cloudflare-Traffic-Manager/1.0; +https://www.cloudflare.com/traffic-manager/; pool-id: XXX)"

El Health Threshold, el umbral de salud es el número de puntos finales saludables que debe tener el grupo en su conjunto para que se considere saludable y reciba tráfico según el orden del grupo en un equilibrador de carga. Aumentar este número hace que el grupo sea más fiable, pero también más propenso a dejar de ser saludable.

Afinidad de sesión - Session Affinity

Habilite la afinidad de sesión para dirigir todas las solicitudes de un usuario final concreto a un punto final específico. La afinidad de sesión genera una cookie que codifica la información sobre el punto final al que deben reenviarse las solicitudes posteriores del mismo cliente, siempre que el punto final siga funcionando correctamente. Esta continuidad conserva la información sobre la sesión del usuario, como los artículos de su carrito de la compra, que de otro modo se perdería si las solicitudes se distribuyeran entre varios servidores.

Enrutamiento adaptativo - Adaptive Routing

Controla las funciones que modifican el enrutamiento de las solicitudes a los grupos y puntos finales en respuesta a condiciones dinámicas, como durante el intervalo entre solicitudes de supervisión de estado activas. Si hay otro punto final en buen estado en el mismo grupo, la solicitud se vuelve a intentar una vez en este punto final alternativo.

Conmutación por error entre grupos - Failover across pools

Amplía la conmutación por error sin tiempo de inactividad de las solicitudes a puntos finales en buen estado de grupos alternativos, cuando no existe ningún alternativo en buen estado en el mismo grupo, de acuerdo con el orden de conmutación por error definido por el tráfico y la dirección de los puntos finales. Cuando se desactiva, la conmutación por error sin tiempo de inactividad solo se producirá entre puntos finales dentro del mismo grupo. Consulte Afinidad de sesión para controlar cuándo se interrumpen o reasignan las sesiones.  

Load Balancing Analytics

 Análisis del equilibrio de carga

Evalúa el flujo de tráfico y compruebe el estado de los puntos finales de sus grupos.

Aquí podemos ver las peticiones (requests) al Balanceador de carga y la distribución, es decir, cada endpoint cuántas peticiones ha gestionado. 

 

Por ejemplo si tenemos un peso de 0.5 y 0.5 en cada endpoint, significa que se reparte al 50% de manera que las peticiones recibidas por cada endpoint deberían ser también repartidas al 50%

Aquí también podemos ver un historial de las caídas de los endpoints, cuáles han caído, el motivo (code response) y cuándo han caído ( y cuándo se han recuperado) 

DNS Load Balancing

Cloudflare realiza un equilibrio de carga solo DNS cuando el tráfico hacia su nombre de host no se proxy a través de Cloudflare. En el panel de control de equilibrio de carga, estos equilibradores de carga se marcan con una nube gris.

No obstante, en comparación con el equilibrio de carga proxy, el equilibrio de carga de capa 7 y el equilibrio de carga solo DNS:

• No oculta las direcciones IP de sus puntos finales, lo que los deja vulnerables a los ataques DDoS
• .Realiza una conmutación por error más lenta y un enrutamiento menos preciso, ya que depende de los resolutores DNS y la configuración de la caché.
• No se puede integrar con otras funciones de Cloudflare, como el almacenamiento en caché, Workers y WAF
• .Aumenta las consultas autoritativas contra Cloudflare, lo que puede suponer un coste adicional para los clientes con facturación basada en el uso.
• No admite afinidad de sesión.Geolocaliza el tráfico basándose en el centro de datos asociado a la dirección de origen ECS, si está disponible. Si no está disponible, geolocaliza basándose en el resolutor recursivo del usuario, lo que a veces puede causar problemas con el direccionamiento basado en la latencia.
• No admite equilibrio de carga de red privada.