Hubo un tiempo en que los dinosaurios vagaban por la Tierra; los seres humanos empezaron a trabajar con herramientas como las rocas y los equilibradores de carga basados en DSR de capa 4.
En aquella época, estas herramientas eran útiles porque con ellas podías llegar a los servidores, y también porque era fácil asegurarse de que al servidor de aplicaciones se le presentaba la dirección IP real del cliente.
Un equilibrador de carga se sitúa entre el Cliente y la aplicación, así que mirando hacia atrás desde la aplicación, ¿quién es el emisor? ¿El Cliente (Sí, por favor) o el equilibrador de carga?
Esto era bastante fácil, y tenías unas cuantas opciones abiertas.
Modo DSR – Retorno Directo del Servidor.
- El cliente se conectaría al equilibrador de carga.
- El equilibrador de carga lo enviaría a la Aplicación con el SourceIP del Cliente.
- La Aplicación enviaría entonces una respuesta directamente al cliente. Probablemente se daría cuenta de que la IP de origen es una IP externa, y entonces dirigiría la respuesta a la pasarela, saltándose así el equilibrador de carga en la Respuesta.
Así que a los dinosaurios les gustaba este enfoque, ya que utilizaba menos recursos de la infraestructura y la aplicación obtenía la IP real del cliente.
El inconveniente es que tienes que hacer una configuración especial de red en el servidor de la aplicación Y la gran revelación … El equilibrador de carga no recibe ni ve la respuesta, por lo que cualquier SSL o cambio de contenido está fuera de la ventana.
La otra desventaja es que el LB no tiene ni idea de lo bien que va el servidor de la App, por lo que es más difícil equilibrar la carga hacia servidores que probablemente tendrían más rendimiento. El ADC utilizaría los que respondieran más rápido o tuvieran menos conexiones. (El Hombre de la Edad de Piedra puede instalar un agente en el servidor de la App para que informe de esto.) O un ADC podría utilizar SNMP para obtener esto.
En cualquier caso, esta configuración funcionó bien durante muchos años, como el caballo y el carro, y de hecho, todavía hay situaciones en las que ésta es la mejor opción, como las carreras de cuadrigas o algunos protocolos antiguos, por ejemplo.
El siguiente es:
Modo pasarela
- El cliente se conectaría al equilibrador de carga
- El equilibrador de carga lo enviaría al App Server con el SourceIP del Cliente
- La aplicación enviaría entonces una respuesta directa al cliente, PERO A TRAVÉS del equilibrador de carga, porque has cambiado la puerta de enlace predeterminada del servidor de aplicaciones por la del equilibrador de carga. Esto significa que el equilibrador de carga recibirá la respuesta.
Esto es mucho mejor en algunos aspectos, pero TODO el tráfico externo del servidor de aplicaciones, como las actualizaciones de software, se ejecuta a través del equilibrador de carga, por lo que se convierte en un lío.
Esto era más habitual cuando los equilibradores de carga parecían conmutadores, y todo se conectaba directamente con enlaces de red de alta velocidad de taza y cuerda.
El hombre aprende a cultivar y utilizar el equilibrio de carga basado en proxy
Por aquel entonces, las redes y las velocidades de las CPU eran cada vez más rápidas, y empezamos a ver el enfoque Proxy.
Decidimos sincerarnos y empezar a utilizar el equilibrador de carga como IP de origen en lugar de engañar al servidor de aplicaciones. Lo hicimos por muchas razones, como el rendimiento TCP, la seguridad y la posibilidad de proporcionar servicios adicionales en el equilibrador de carga.
Pero este alejamiento de la caza-recolección conllevó un gran precio y un gran desafío.
¿Cómo envías la IP del cliente al servidor de aplicaciones?
Por suerte, el bueno y viejo HTTP tenía una gran respuesta, siempre que utilizaras HTTP.
Encabezado X_Reenviado_Por – te permite poner la IP del cliente en el encabezado y luego enviarlo.
No lo explicaré con demasiado detalle, ya que es bastante sencillo, pero baste decir que es un encabezamiento que cualquiera puede configurar fácilmente. Además, puede resultar complejo. Por ejemplo, ¿qué ocurre si al equilibrador de carga ya se le ha enviado una IP X_Forwareded_For? ¿Debe utilizarla o utilizar la IP de origen y cambiarla? Normalmente, esto es posible configurarlo en un LB decente, pero todos tienen consideraciones de seguridad, etc.
De todos modos, el 99% de las veces, cuando una aplicación web necesita el código fuente, lo obtiene así (Nota: el 99% de las estadísticas son inventadas)
¿Qué pasa con otros protocolos?
Algunos tienen algunos hacks específicos del protocolo, pero no hay nada genérico que esté más ampliamente adoptado.
Bueno, eso fue hasta que se propuso y adoptó ampliamente el Protocolo Proxy.
Explicación del protocolo proxy
El Protocolo Proxy resuelve este problema añadiendo una cabecera a la petición reenviada que contiene los datos de conexión del cliente original.
Ya existen dos versiones de este protocolo.
- Protocolo Proxy v1: Utiliza un formato de texto sencillo y legible por humanos.
- Protocolo Proxy v2: Utiliza un formato binario, que es más eficiente y puede admitir funciones adicionales como IPv6 y direcciones de socket Unix.
Lo que es diferente es que la mayoría de los servidores de aplicaciones se romperán si activas esto sin configurarlos para que lo acepten. Esto se debe a que el Protocolo Proxy añade literalmente el detalle requerido al inicio de los datos.
Sin embargo, la adopción está creciendo y muchos proveedores ya lo admiten.
Por ejemplo, es genial para el proxy DNS.
Al igual que con X_Forwardard_For, aún quedan algunas decisiones por tomar:
Por ejemplo, ¿qué quieres que haga el equilibrador de carga si se le presenta una cabecera de Protocolo Proxy? ¿Que lo elimine y establezca uno nuevo, o que lo mantenga? Si no espera que se le envíe ninguna, debería ignorarla y obtener la suya propia, pero estas decisiones deben tenerse en cuenta.
El Protocolo Proxy es una forma sencilla de obtener la IP del Cliente y ahora está ampliamente soportado, así que adelante y disfruta.
Vuelvo a pensar en la alta disponibilidad en la nube, ¡Ciao!
