Resumen #

El objetivo del siguiente artículo es proporcionar una descripción arquitectónica de RELIANOID Balanceador de carga componentes internos de software dirigidos a administradores de sistemas y desarrolladores de software interesados ​​en saber más sobre cómo RELIANOID El software ADC funciona. Toda esta información también podría usarse para ayudar con la configuración de sistemas de producción o para solucionar problemas.

RELIANOID #

RELIANOID gestiona procesos tanto desde el espacio del usuario como del kernel, lo que permite obtener el mayor rendimiento pero con la mayor flexibilidad y también para realizar todas las tareas delegadas al controlador de entrega de aplicaciones, como equilibrio de carga, seguridad y alta disponibilidad.

El siguiente diagrama ofrece una visión global de los diferentes componentes que componen el RELIANOID sistema internamente. Se han omitido piezas adicionales de menor importancia para ofrecer una visión más sencilla y clara.

En los siguientes apartados se describirán las diferentes piezas y cómo se interconectan.

RELIANOID Balanceador de carga en el espacio de usuario #

Los subsistemas utilizados en User Space son:

GUI web: Interfaz gráfica de usuario web utilizada por los usuarios para gestionar la configuración y administración de todo el sistema, es gestionada por un servidor web HTTPS que consume el RELIANOID API para todas las acciones realizadas en el balanceador de carga.

RELIANOID API: or RELIANOID Interfaz del programa de aplicación, diseñada siguiendo las REST y JSON interfaces, consumido a través de HTTPS, es utilizado por otras interfaces de usuario diferentes desde el punto de vista del usuario, como el GUI web interfaz o ZCLI (RELIANOID interfaz de línea de comandos). Esta herramienta verifica cualquier acción contra el subsistema RBAC y, si está permitido, la acción se toma en el RELIANOID Aparato. La API puede conectar 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 control de acceso definido en torno a usuarios, grupos y roles. Este módulo define las acciones que un usuario puede realizar, con un alto nivel de configuración entre grupos, usuarios y roles. Está totalmente integrado en la interfaz gráfica web, que permite cargar las vistas web según el rol del usuario. Además, este subsistema se consume a través de la API o cualquier otra herramienta que la utilice.

LSLB – HTTP(S): El módulo LSLB (Local Service Load Balancer), compuesto por el perfil HTTP(S), se ejecuta en el espacio de usuario mediante un proxy inverso llamado Zproxy, capaz de gestionar aplicaciones de alto rendimiento de forma muy eficiente. Este subsistema se configura mediante la API y puede protegerse con el subsistema IPDS (utilizando listas negras, reglas DoS, RBL y conjuntos de reglas WAF).

GSLB: El módulo GSLB (Global Service Load Balancer), implementado con una instancia de perfil GSLB, se ejecuta en el espacio de usuario mediante un proceso de servidor DNS llamado Gdnsd, que funciona como un servidor de nombres DNS avanzado con funciones de balanceo de carga. Este subsistema se configura mediante la API y puede protegerse con el subsistema IPDS (mediante listas negras, protección contra ataques DoS y RBL).

Comprobaciones de estado: Este subsistema se configura mediante la API y lo utilizan todos los módulos de balanceo de carga (LSLB, GSLB y DSLB) para verificar el estado de los servidores backend. Se ejecutan comprobaciones simples y avanzadas en el servidor backend y, si alguna falla, el servidor backend de la granja se marca como inactivo y no se reenvía más tráfico hasta que la comprobación vuelva a funcionar. El Farm Guardian es responsable de estas comprobaciones y está diseñado con un alto nivel de flexibilidad y configurabilidad.

Sistema de archivos de configuración: Este directorio se utiliza para guardar la configuración; cualquier cambio que se realice en él 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 se utiliza para dos propósitos principales: LSLB – administración L4XNAT y configuración del módulo del subsistema IPDS .

RELIANOID Balanceador de carga en el espacio del kernel #

Los subsistemas utilizados en Kernel Space son:

Sistema Netfilter LSLB L4xNAT: El subsistema Netfilter es utilizado por Nftlb para el balanceo de carga. Las reglas de Netfilter se cargan en el kernel mediante este proceso de Nftlb para crear un balanceador de carga L4 de alto rendimiento . Nftlb carga las reglas del balanceador de carga en el kernel de manera eficiente para gestionar los paquetes de tráfico de la forma más óptima posible. Además, Nftlb carga reglas de Netfilter para la prevención y protección contra intrusiones (listas negras, RBL y DoS).

Listas negras de IPDS: Este subsistema está integrado en el sistema Netfilter y es administrado por Nftlb. Se compone de un conjunto de reglas configuradas antes de las reglas del balanceador de carga para bloquear las conexiones de las direcciones IP de origen especificadas . Internamente, crea un conjunto de reglas ordenadas por categoría, país, tipo de atacante, etc., y se actualiza diariamente.

IPDS RBL : De forma similar al anterior, este subsistema también está integrado en Netfilter y es gestionado por Nftlb. La IP de origen se captura antes de establecer la conexión y la IP del cliente se valida con un servicio DNS externo . Si la IP se resuelve, se marca como maliciosa y se interrumpe la conexión.

IPDS DoS: El mismo sistema de configuración que los dos módulos anteriores, integrado en Netfilter y gestionado por Nftlb. Se trata de un conjunto de reglas configuradas antes de las reglas de balanceo de carga que comprueban si los paquetes forman 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 complete.

Sistema de seguimiento de conexiones: Este sistema es utilizado por el subsistema Netfilter para la gestión de conexiones, la traducción de red y el módulo de estadísticas , así como por el subsistema de verificación de estado para forzar acciones de conexión en el momento en que se detecta un problema en el backend. El servicio de Clustering también utiliza el sistema de seguimiento de conexiones 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 con el mismo estado de conexión que el maestro anterior.

Sistema de enrutamiento y DSLB: Estos subsistemas son gestionados por la API y configurados en el espacio del kernel. El subsistema de enrutamiento está construido con iproute2, lo que nos permite gestionar múltiples tablas de enrutamiento para evitar mantener un conjunto de reglas complejo para el enrutamiento estático . Además, gracias a iproute2, se crea el módulo DSLB (Datalink Service Load Balancer) para proporcionar balanceo de carga de enlaces ascendentes con varias pasarelas.

Al momento de escribir este artículo, RELIANOID 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 #

RELIANOID Puntos de referencia de zproxy, perfil LSLB -HTTP(S)
RELIANOID Puntos de referencia nftlb, perfil LSLB – L4xNAT