La monitorización es la base de la disponibilidad. Antes de elegir un recurso de destino, todo balanceador de carga debe saber si dicho recurso está realmente disponible. De lo contrario, ¿qué sentido tendría?
En entornos en los que la vida útil de los recursos puede medirse en minutos en lugar de horas o días, resulta aún más importante conocer su estado antes de decidir enviarles una solicitud.
La supervisión del estado es una parte esencial de los balanceadores de carga y los proxies. Esto también es así (o debería serlo) en los entornos de contenedores. A medida que estos entornos siguen madurando (rápidamente), vemos surgir nuevos modelos de supervisión para hacer frente a los retos, en cierto modo únicos, asociados a estos sistemas distribuidos tan volátiles.
La supervisión tradicional del estado es, sin duda, parte de la ecuación, pero algunos modelos de disponibilidad y escalabilidad en entornos de contenedores someten a la supervisión tradicional del estado a tensiones que deben abordarse. Por ejemplo, se espera que los proxies implementados según un modelo de proxy directo puedan seleccionar un destino en buen estado (disponible) entre todos los servicios posibles. Mientras que un proxy inverso (un balanceador de carga tradicional, por así decirlo) solo se encarga de supervisar el estado de un conjunto muy específico de servicios para una única aplicación, un proxy directo debe conocer el estado de todos los servicios de todas las aplicaciones del entorno. Porque enviar una solicitud a un contenedor que ya está fuera de servicio sería malo, ¿vale?
Monitorización tradicional del estado
Tradicionalmente, un proxy lleva a cabo la supervisión del estado de dos maneras:
- Monitorización activa: Envío de sondas o solicitudes de comprobación de estado a los contenedores y evaluación de sus respuestas.
- Monitorización pasiva: Observación de las solicitudes habituales de los clientes y de sus respuestas.
Como cabe imaginar, la monitorización activa de cada servicio por parte de todos los proxies de reenvío aumentará de forma bastante drástica el tráfico de la red local y consumirá recursos innecesariamente. Para que resulte útil, la monitorización debe realizarse, como mínimo, en la capa TCP e, idealmente, en la capa HTTP. Al fin y al cabo, la conectividad de red no indica el estado ni la disponibilidad de un servicio. El uso de conexiones TCP y la necesidad de procesamiento HTTP sobrecargarán rápidamente los contenedores a medida que aumente el número de nodos (y, por tanto, de proxies de reenvío). No conviene tener que ampliar la capacidad porque la monitorización sature los contenedores.
La monitorización pasiva es una opción mejor en este caso, ya que no supone una carga para el sistema monitorizado, aunque presenta ciertas limitaciones en algunos entornos de contenedores. Muchos se basan en los principios de las redes superpuestas, lo que dificulta garantizar que todos los proxies puedan ver y rastrear las respuestas de cada servicio. No es imposible, pero sí complicado en la capa de red.
Ambos modelos también suponen una carga para el propio proxy, ya que obligan a dedicar recursos únicamente a supervisar el entorno, en lugar de destinarlos a la tarea para la que se han implementado: escalar los servicios.
Monitorización del estado en contenedores
Los entornos de contenedores no son ajenos a estos desafíos. Como respuesta, están surgiendo dos nuevos modelos que sin duda ayudarán a garantizar la disponibilidad en arquitecturas que emplean proxies directos para mejorar la disponibilidad y la escalabilidad.
Estos dos modelos son:
- Supervisión del entorno: Los proxies conocen el estado y la disponibilidad de los contenedores gracias a la información sobre su estado que proporciona el entorno de orquestación de contenedores (COE).
- Monitorización compartida: Dado que es probable que haya muchos proxies en un entorno, el trabajo de monitorización puede repartirse entre ellos y los resultados pueden compartirse.
La supervisión del entorno suele estar asociada al registro de servicios, que realiza un seguimiento de los contenedores a medida que entran y salen del sistema. Esto significa que, a menudo, es la fuente más fiable sobre la disponibilidad de los contenedores en el sistema. Los proxies también pueden suscribirse a los eventos que se desencadenan al crear y destruir contenedores para realizar ellos mismos un seguimiento de esos recursos (actuando, en la práctica, como un registro).
Por ejemplo, si la supervisión del estado está habilitada para una aplicación en Marathon, un proxy puede utilizar el campo 'healthCheckResults'. En Kubernetes, los proxies pueden utilizar comprobaciones de actividad y/o disponibilidad. Las comprobaciones del estado del entorno permiten que los proxies empiecen a seleccionar endpoints en mejor estado antes de que el sistema de orquestación reinicie uno que no esté en buen estado.
La monitorización compartida resulta muy útil en sistemas que emplean modelos de proxy directo, especialmente aquellos basados en una malla de servicios como Istio. El proxy asociado al nodo puede encargarse de monitorizar el estado y la disponibilidad de los contenedores a los que reenvía solicitudes (de forma muy similar a como podría realizar un seguimiento de los servicios en un modelo de proxy inverso). Sin embargo, no conviene que todos los proxies sondeen activamente todos los endpoints de un sistema de este tipo. Al compartir la información local sobre el estado con otros proxies (o, mejor aún, con el entorno), todos los proxies pueden obtener el estado completo conocido del sistema sin necesidad de realizar comprobaciones de estado excesivas en cada servicio.
Se están produciendo muchos cambios en «la red» en lo que respecta a servicios de aplicaciones como el balanceo de carga y a cómo interactúan para satisfacer las necesidades y los requisitos de nuevos modelos como la contenerización. Estos requisitos ejercen una presión constante sobre los proxies para que se adapten. Esto se debe a que los proxies son una de las tecnologías más flexibles desarrolladas en los últimos veinte años y siguen siendo una base importante sobre la que se diseñan, desarrollan e implementan los servicios de aplicaciones.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.