3 cosas que los operadores deben saber sobre el equilibrio de carga
Equilibrio de carga. Se acepta comúnmente que lo necesitamos, dependemos de él y lo usamos todos los días para ampliar (y con suerte reducir) las aplicações. Se ha convertido en una infraestructura crítica responsable no solo de escalar para satisfacer la demanda, sino también de garantizar la disponibilidad continua de las aplicações y los servicios de los que dependen las empresas para lograr tanto productividad como ganancias.
Es por eso que es algo que debemos revisar. Porque el equilibrio de carga no debería ser algo tan táctico como lo tratan cada vez más los profesionales de operaciones, que cada vez más a menudo tienen que aprovisionar, configurar e implementar estos servicios mágicos. El equilibrio de carga, cuando se analiza estratégicamente, puede mejorar el rendimiento, reducir el riesgo y ayudar a hacer un uso más eficiente de los recursos necesarios para entregar aplicações. Son más inteligentes que el apodo de "plomería" que a menudo se les obliga a soportar y comprender algunos puntos clave ayudará a las operaciones a pensar más sobre cómo están usando el equilibrio de carga para respaldar las aplicações.
Así que, sin más preámbulos, aquí hay tres cosas que los operadores realmente necesitan saber sobre el equilibrio de carga.
1.Los algoritmos son relativos
Me gustaría comenzar mencionando que el algoritmo round robin es el último que deberías mencionar, pero eso ya lo sabías, ¿verdad? Así que omitiremos eso y abordaremos los algoritmos más inteligentes, como la menor cantidad de conexiones y el tiempo de respuesta más rápido . Por supuesto, estas son opciones mucho mejores a medida que elabora estrategias sobre cómo equilibrar el rendimiento con el uso eficiente de los recursos. Cada uno tiene en cuenta las características de la aplicação (o al menos las características de las plataformas que entregan las aplicações) que son fundamentales para tomar decisiones sobre qué instancia de la aplicação (o contenedor, si lo prefiere) debe recibir la próxima solicitud. La menor cantidad de conexiones implica que si una instancia tiene menos conexiones, tiene más capacidad y, por lo tanto, está en mejores condiciones de cumplir esta solicitud en este momento. Se trata de elegir la capacidad y la eficacia por encima del rendimiento.
El tiempo de respuesta más rápido , en el otro extremo del espectro, es elegir dirigir las solicitudes en función del rendimiento. Cuanto más rápida sea la instancia, más a menudo será seleccionada. Los axiomas operativos son los que son (a medida que aumenta la carga, disminuye el rendimiento), lo que significa que, en última instancia, un servidor menos cargado responderá más rápido y, por lo tanto, será el elegido. Si bien esto supone un avance en cuanto a la eficacia de la capacidad, este algoritmo siempre prioriza el rendimiento sobre la capacidad.
Pero ahora observemos los nombres de los algoritmos: Menos y más rápido . Ahora consideremos que si dos tortugas corren por la acera, una de ellas es más rápida, aunque ambas viajan a lo que todos llamaríamos una velocidad “lenta”. Lo mismo ocurre con el menor número de conexiones. Cuando se da la opción de elegir entre 99 y 100, 99 es definitivamente el menor de los dos.
Por qué importa
La forma en que el equilibrio de carga gestiona las solicitudes tiene un impacto directo e inmediato en el rendimiento y la disponibilidad. Ambas son características críticas que en última instancia afectan la participación del cliente y la productividad de los empleados. La optimización de arquitecturas que incluyan el equilibrio de carga ayudará a garantizar el éxito empresarial a la hora de alcanzar objetivos de mayor productividad y ganancias.
Profundización:
- Volver a lo básico: La teoría de la relatividad (del rendimiento)
- Volver a lo básico: Menos conexiones no significa menos carga
2.Fracasar instantáneamente es (a menudo) un mito
Desde el ascenso de la nube y los centros de datos definidos por software, la elasticidad se ha convertido en la forma de escalar aplicações. La elasticidad requiere escalabilidad ascendente y descendente según demanda como un medio para optimizar el uso de recursos (y presupuestos). ¿Por qué aprovisionar en exceso cuando es posible ampliarlo según demanda? De manera similar, las arquitecturas de alta disponibilidad (HA) que dependen de los principios de redundancia se han vuelto casi obsoletas. ¿Por qué requerir recursos inactivos en espera en el caso (improbable) de que falle la instancia de la aplicación principal? ¡Es un desperdicio de capital y de presupuesto operativo! ¡Fuera, fuera, maldito stand-by!
Si bien la teoría del fracaso y la escalabilidad a pedido es hermosa, en la práctica no es tan simple. La realidad es que incluso los servidores virtuales (o servidores en la nube, o cualquier término que prefiera utilizar) tardan en lanzarse. Si usted (o su sistema automatizado) espera hasta que ese servidor principal falle o alcance su capacidad máxima antes de lanzar otro, ya será demasiado tarde. La planificación de la capacidad en entornos en la nube no puede basarse en las mismas matemáticas que funcionaban en un entorno tradicional. Los umbrales de capacidad ahora deben tener en cuenta en la ecuación la tasa de consumo junto con el tiempo que lleva lanzar otro servidor para poder escalar sin problemas junto con la demanda.
Lo mismo ocurre con la conmutación por error. Si el principal falla, llevará tiempo lanzar un reemplazo. Tiempo en el que las personas pierden conexiones, pierden el tiempo y probablemente te abandonan por un competidor o por el último video de gatos. Aunque tener una rueda de repuesto inactiva puede parecer un desperdicio (como un seguro), cuando la necesitas, te alegrarás de tenerla allí. En particular, si esa aplicación es responsable de la interacción con el cliente o de los ingresos, entonces el riesgo de incluso unos pocos minutos de inactividad (y su costo posterior) puede compensar con creces el costo de tener una de repuesto a mano.
Curiosamente, los contenedores parecen solucionar potencialmente estos problemas con tiempos de lanzamiento increíblemente rápidos. Si la disponibilidad, el rendimiento y el costo son igualmente importantes, tal vez sea momento de comenzar a explorar el valor que pueden aportar los contenedores en términos de equilibrar los tres.
Por qué importa
El tiempo de inactividad es costoso. La causa del tiempo de inactividad no es tan importante como evitarlo en primer lugar. Garantizar que se cuente con la arquitectura y los planes de conmutación por error adecuados en caso de falla es fundamental para mantener la disponibilidad continua, fundamental para el éxito del negocio.
Profundización:
3.La IP del cliente no es la IP del cliente real .
De todos los problemas que ocurren cuando una aplicación pasa del desarrollo a la producción, este es probablemente el más común y fácilmente evitable. Verá, la mayoría de los servicios de equilibrio de carga (todos los buenos, de todos modos) son proxies . Esto significa que el cliente se conecta al proxy y este a tu aplicación. Ambos usan TCP para transportar el HTTP, lo que implica que debe cumplir con las leyes de la red. La IP de origen (lo que crees que es la IP del cliente) es en realidad la dirección IP del proxy. Si está realizando tareas de seguridad, autenticación o medición en función de la dirección IP, esto plantea un problema grave. El valor que extraes del encabezado HTTP no es el que deseas.
La industria prácticamente ha estandarizado el manejo de este problema aprovechando los encabezados HTTP personalizados. El encabezado X-Forwarded-For es probablemente lo que realmente estás buscando: ahí es donde un proxy coloca la dirección IP real del cliente cuando reenvía solicitudes. Lamentablemente no es un estándar, es más bien un estándar de facto en el que “todos estamos de acuerdo”, por lo que tendrás que verificarlo.
El punto es que la dirección IP del cliente que estás buscando no es la que crees y, por lo tanto, los desarrolladores deben tenerlo en cuenta antes de que las aplicaciones que necesitan esa información pasen a un entorno de producción y de repente dejen de funcionar.
Por qué es importante para el negocio
La resolución de problemas en producción es mucho más costosa que en entornos de desarrollo o prueba. Tanto el tiempo necesario para encontrar como para solucionar el problema inciden negativamente en los plazos del proyecto y dificultan el tiempo de comercialización, tan fundamental para obtener una ventaja competitiva y el éxito empresarial en el mundo de las aplicação . Reconocer este problema común y abordarlo en la fase de desarrollo o prueba puede garantizar una implementación más rápida y fluida en producción y en el mercado.
Profundización: