Contenido
Resumen
El objetivo del siguiente artículo es proporcionar una descripción arquitectónica de los componentes internos del software Zevenet dirigidos a administradores de sistemas y desarrolladores de software interesados en saber más sobre cómo funciona el software ADC de Zevenet. Toda esta información podría utilizarse también para ayudar con la configuración de los sistemas de producción o con fines de resolución de problemas.
Arquitectura Zevenet
Zevenet gestiona los procesos desde el espacio del usuario y del kernel, lo que permite obtener el mayor rendimiento, pero también con la mayor flexibilidad para realizar todas las tareas delegadas al controlador de entrega de aplicaciones, como el equilibrio de carga, la seguridad y la alta disponibilidad.
El siguiente diagrama ofrece una visión global de los diferentes componentes que componen el sistema Zevenet internamente. Se han perdido piezas adicionales de menor importancia para ofrecer una visión más simple y clara.
Las siguientes secciones describirán las diferentes piezas y cómo están interconectadas.
Zevenet Load Balancer en espacio de usuario
Los subsistemas utilizados en User Space son:
GUI web: La interfaz gráfica de usuario web utilizada por los usuarios para administrar la configuración y administración de todo el sistema, es administrada por un servidor web HTTPS que consume la API Zevenet para todas las acciones realizadas en el equilibrador de carga.
API de Zevenet: o la interfaz del programa de aplicación Zevenet, diseñada siguiendo el RESTO y JSON interfaces, consumidas a través de HTTPS, es utilizada por otras interfaces de usuario diferentes desde el punto de vista del usuario, como el GUI web interfaz o ZCLI (Interfaz de línea de comandos de Zevenet). Esta herramienta verifica cualquier acción contra el subsistema RBAC y, si está permitida, la acción se realiza en el dispositivo Zevenet. La API puede conectarse y administrar cualquier otro subsistema de espacio de usuario descrito en el diagrama.
RBAC: El control de acceso basado en roles es un mecanismo de acceso y control definido en torno a usuarios, grupos y roles. Este módulo define qué acciones se le permite a un usuario realizar con un alto nivel de configuración entre grupos, usuarios y roles. Está totalmente integrado en la interfaz web GUI que permite cargar las vistas web en función del rol del usuario. Además, este subsistema se consume a través de API o cualquier otra herramienta que use el API.
LSLB - HTTP (S): El módulo LSLB (Local Service Load Balancer) compuesto por el perfil HTTP (S) es ejecutado en el espacio del usuario por un proxy inverso llamado Zproxy que puede administrar aplicaciones de alto rendimiento de manera muy eficiente. Este subsistema está configurado por la API y puede ser protegido por el subsistema IPDS (utilizando listas negras, reglas DoS, conjuntos de reglas RBL y WAF).
GSLB: El módulo GSLB (Global Service Load Balancer) implementado con una instancia de perfil GSLB se ejecuta en el espacio del usuario mediante un proceso de servidor DNS llamado Gdnsd que puede funcionar como un servidor de nombres DNS avanzado con funciones de equilibrio de carga. Este subsistema está configurado por la API y puede ser protegido por el subsistema IPDS (usando BlackLists, DoS y RBL).
Verificaciones de salud: La API configura este subsistema y lo utilizan todos los módulos de equilibrador de carga (LSLB, GSLB y DSLB) para verificar el estado de los backends. Las verificaciones simples y avanzadas se ejecutan en el back-end y luego, si la verificación falla, el back-end para la granja de servidores determinada se marca como inactivo y no se reenvía más tráfico hasta que la verificación funcione nuevamente en el back-end. Farm Guardian es responsable de estos controles y está diseñado con un alto nivel de flexibilidad y capacidad de configuración.
Sistema de archivos de configuración: Este directorio se utiliza para guardar la configuración, cualquier cambio en este directorio se replicará en el clúster, si dicho servicio está habilitado.
Nftlb: Este proceso de espacio de usuario es administrado por el subsistema API y utilizado para dos propósitos principales: LSLB - L4XNAT gestión y configuración de la IPDS módulo del subsistema
Zevenet Load Balancer en Kernel Space
Los subsistemas utilizados en Kernel Space son:
Sistema Netfilter LSLB L4xNAT: El subsistema Netfilter es utilizado por Nftlb para fines de equilibrio de carga. Las reglas de Netfilter se cargan en el núcleo mediante este proceso Nftlb para construir un equilibrador de carga L4 de alto rendimiento. Nftlb carga las reglas del equilibrador de carga en el kernel de una manera eficiente para administrar los paquetes de tráfico de la manera más óptima posible. Además, Nftlb cargará las reglas de Netfilter para la prevención y protección contra intrusiones (BlackLists, RBL y DoS).
Listas negras de IPDS: Este subsistema está integrado en el sistema Netfilter y gestionado por Nftlb. Se compone de un grupo de reglas configuradas antes de las reglas del equilibrador de carga para desconectar conexiones para las IP de origen dadas. Internamente crea un conjunto de reglas ordenadas por categoría, país, tipos de atacante, etc. y actualizadas diariamente.
IPDS RBL: De manera análoga al anterior, este subsistema también está integrado en Netfilter y administrado por Nftlb. La IP de origen se captura antes del establecimiento de la conexión y la IP del cliente se valida contra un servicio de DNS externo. Si la IP se resuelve, la IP se marca como maliciosa y la conexión se cortará.
DoS de IPDS: El mismo sistema de configuración que los dos módulos anteriores, integrado en Netfilter y administrado por Nftlb. Es un conjunto de reglas configurado antes de las reglas de equilibrio de carga que verifican si los paquetes son parte de un Ataque de denegación de servicio. Algunas reglas se aplican al flujo de paquetes para interceptar el ataque antes de que se realice.
Sistema de seguimiento de conexión: Este sistema lo utiliza el subsistema Netfilter para fines de gestión de conexión, traducción de red y para módulo de estadísticas, Así como la chequeo de salud El subsistema para forzar acciones de conexión en el momento de un problema se detecta en el backend. El sistema de seguimiento de conexión también es utilizado por Servicio de agrupamiento para reenviar el estado de la conexión al segundo nodo del clúster, en caso de que falle un nodo maestro del clúster, el segundo nodo puede gestionar el tráfico en el mismo estado de conexión que el maestro anterior.
Sistema de enrutamiento y DSLB: Estos subsistemas son administrados por la API y configurados en el espacio Kernel. El subsistema de enrutamiento está construido con iproute2 lo que nos permite gestionar múltiples tablas de enrutamiento en orden para evitar mantener un conjunto de reglas complejo para el enrutamiento estático, además, gracias a iproute2, se creó el módulo DSLB (Datalink Service Load Balancer) para proporcionar equilibrio de carga de enlaces ascendentes con varias puertas de enlace.
En el momento de escribir este artículo, Zevenet 6 está en producción, por lo que esos subsistemas podrían evolucionar en futuras versiones para ofrecer un mejor rendimiento o más funciones.
Documentación adicional
Pruebas de rendimiento Zevenet zproxy, perfil LSLB -HTTP (S)
Zevenet nftlb benchmarks, LSLB - perfil L4xNAT