¿Qué es el balanceo global de carga de servidores?

El balanceo global de carga de servidores dirige a los clientes entre endpoints de distintas regiones geográficas. Las decisiones pueden tener en cuenta el estado de los endpoints, la latencia, la capacidad, las políticas o la ubicación del usuario.

El balanceo global de carga de servidores (GSLB) es un término de los proveedores, no un protocolo. RFC 3568 describe la misma tarea como enrutamiento de solicitudes y clasifica los mecanismos conocidos en técnicas de DNS, de capa de transporte y de capa de aplicación. La modalidad DNS es común porque todos los clientes ya resuelven nombres: un servidor de nombres autoritativo responde al mismo nombre con direcciones diferentes según las políticas, las mediciones o ambas, y la dirección devuelta suele ser una IP virtual situada delante de un grupo regional de servidores que realiza su propio balanceo de carga local. Las otras modalidades actúan después. Anycast anuncia una dirección desde varias sedes y deja la elección de la sede al enrutamiento de red. Un balanceador de capa de aplicación redirige al cliente, por ejemplo, con un HTTP 302, o actúa como proxy de las solicitudes y elige una región para cada una. Los balanceadores de DNS y de capa de aplicación pueden ponderar la proximidad de red o la latencia, la carga y la capacidad, los resultados de las comprobaciones de estado y reglas como la ubicación geográfica o los pesos. Anycast por sí solo sigue únicamente el enrutamiento de red: RFC 3568 señala que los protocolos de enrutamiento normalmente no son sensibles a la carga y que no se tiene en cuenta la carga del servidor, y una sede sigue recibiendo tráfico mientras se anuncie su ruta, por lo que RFC 4786 considera deseable vincular el anuncio a la disponibilidad del servicio.

¿Con qué rapidez desvía el GSLB basado en DNS el tráfico de una región que ha fallado? De forma gradual, no de una sola vez. Primero se detecta el fallo, y esa detección depende del intervalo entre comprobaciones y de cuántas comprobaciones fallidas consecutivas exige el balanceador (Route 53 lo llama umbral de fallos). Una vez que cambia la respuesta autoritativa, las consultas que no se atienden desde una caché reciben la nueva respuesta, mientras que un resolutor que haya almacenado la respuesta anterior puede seguir usándola durante lo que reste de su TTL. La nueva respuesta indica una región que supera sus comprobaciones, si existe alguna; cuando ninguna las supera, se aplica la regla de respaldo del balanceador y, por ejemplo, Route 53 devuelve el registro principal cuando ambos registros de un par de conmutación por error están en mal estado. El TTL indica cuánto tiempo puede usar un resolutor una respuesta almacenada en caché antes de tener que volver a consultar, y el balanceador no puede retirar una respuesta que ya ha dado. Un TTL más corto reduce esa ventana y aumenta el volumen de consultas en los servidores DNS. Aun así, una respuesta puede seguir usándose después de que venza su TTL: el RFC 3568 señala que muchas implementaciones de DNS no respetan el TTL, y el RFC 8767 permite que un resolutor siga sirviendo una respuesta vencida cuando falla su intento de actualizarla. El proyecto k8gb informa de un tiempo de inactividad aproximadamente igual al TTL de DNS cuando falla un servicio detrás de su GSLB; se trata de la observación de un proyecto, no de un límite superior. Cambiar la respuesta DNS tampoco traslada las conexiones que ya están abiertas: AWS señala, para su conmutación por error entre regiones basada en DNS, que las conexiones existentes tardan en completarse según el comportamiento del cliente y la reutilización de las conexiones. Cloudflare enumera una conmutación por error más lenta como una limitación de su balanceo de carga basado únicamente en DNS frente a su modo con proxy.
¿La ubicación de quién se usa en una decisión basada en DNS? La del resolutor recursivo, salvo que este envíe la opción EDNS Client Subnet. Amazon Route 53 documenta ambos casos: usa la dirección IP de origen del resolutor cuando este no admite la opción y una forma abreviada de la dirección del usuario cuando sí la admite. El RFC 7871, que describe la opción, recomienda que esté desactivada de forma predeterminada por motivos de privacidad. En cambio, un balanceador que actúa como proxy determina la ubicación del cliente a partir de la propia conexión de este.
¿Qué demuestra una comprobación de estado satisfactoria? Solo lo que solicita la comprobación. En Route 53, una comprobación de estado TCP se considera satisfactoria en cuanto se establece una conexión; una comprobación HTTP o HTTPS exige un código de estado 2xx o 3xx, y una comprobación de coincidencia de cadenas también exige un texto determinado en el cuerpo de la respuesta; sus comprobaciones HTTPS no validan el certificado. Una región cuyo front end acepta conexiones mientras falla la aplicación que tiene detrás supera una comprobación TCP. Dirigir la comprobación a una URL que ponga a prueba las dependencias que necesitan tus usuarios es una decisión de diseño que tú tomas, no algo que el balanceador deduzca.
¿Anycast o direccionamiento mediante DNS? Con anycast, el sistema de enrutamiento elige el sitio, por lo que la elección no depende de las respuestas DNS almacenadas en caché, pero el operador tiene un control limitado: el RFC 4786 describe la distribución de carga entre nodos anycast como generalmente desequilibrada y señala que la decisión de enrutamiento debe mantenerse estable durante más tiempo que una transacción, porque una interacción entre cliente y servidor normalmente debe permanecer en el mismo nodo de principio a fin. Esto importa para los flujos de larga duración, como las descargas masivas y el streaming multimedia. El GSLB basado en DNS puede devolver direcciones distintas según la política y hereda los límites de almacenamiento en caché mencionados antes. Ambos mecanismos también se combinan, por ejemplo, asignando una dirección anycast a los propios servidores DNS que enrutan las solicitudes.

El GSLB importa cuando un servicio se ejecuta en más de una región y necesita una regla que determine qué región usa cada cliente y qué ocurre cuando falla una región. El mecanismo que elijas determina con qué rapidez se desvía el tráfico y con qué precisión se ubica a los clientes: las respuestas DNS se almacenan en caché y las políticas DNS basadas en la ubicación ven la dirección del resolutor, salvo que este transmita parte de la dirección del cliente, mientras que un balanceador que actúa como proxy decide para cada solicitud, pero hace que todas pasen por él.

¿Qué es el balanceo global de carga de servidores?

Cómo funciona el balanceo global de carga de servidores

Datos clave

Cuándo importa el balanceo global de carga de servidores

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional