Introducción
LDAP (Lightweight Directory Access Protocol) es una fuente ubicua de información de directorio, codificada por primera vez en 1993. Se usa habitualmente para una amplia variedad de aplicaciones, como gestionar información de usuarios y grupos para instancias de Linux y controlar la autenticación de las VPN y las aplicaciones heredadas.
Tradicionalmente, el servidor LDAP de una empresa se ejecutaba internamente. a menudo forma parte del Active Directory de Microsoft o de una implementación del proyecto OpenLDAP de código abierto. Hoy en día, varios proveedores SaaS ofrecen compatibilidad con LDAP, incluido Foxpass, que fue el primer proveedor de LDAP en la nube en crear una implementación de LDAP multiinquilino y centrada en la nube desde cero.
LDAP normalmente tiene las siguientes primitivas: bind, search, compare, y add. Después de crear una conexión de Protocolo de control de transmisión (TCP), las aplicaciones primero tendrían que vincularse enviando un nombre de usuario y una contraseña. Una vez vinculado correctamente, el cliente emite comandos al servidor LDAP. Normalmente, este es el comando de búsqueda junto con filtros. La conexión TCP se mantiene hasta que el cliente o el servidor se desconecten.
LDAP en Foxpass
En Foxpass, nuestro servicio LDAP está desarrollado sobre Twisted, un popular framework de servicios basado en eventos para Python. El servicio está alojado en la plataforma ECS de AWS y se ejecuta en docenas de contenedores (nodos). Dado que las conexiones LDAP son persistentes, el clúster debe poder mantener cientos de miles de sesiones TCP simultáneas.
Mantenemos los datos de los clientes en la RAM. La razón de esto es múltiple: en primer lugar, el conjunto de datos es relativamente pequeño, incluso para los clientes más grandes. En segundo lugar, el lenguaje de consulta LDAP permite buscar en campos arbitrarios (lo cual es importante, ya que Foxpass permite campos personalizados). Esto significa que un sistema RDBMS tradicional no podrá crear índices eficaces, y debemos transformar los datos en una representación diferente en memoria. En tercer lugar, mantener los datos en la RAM permite el tiempo de respuesta más rápido posible: las latencias suelen rondar los 100 ms (ver gráfico a).
Una desventaja de este enfoque es la invalidación de caché. Cuando los datos de un cliente cambian (por ejemplo, se añadió o eliminó un usuario), los nodos LDAP deben actualizar sus datos desde nuestro RDBMS principal. En nuestra arquitectura anterior, esta era una operación relativamente costosa; cuando cada nodo actualiza los datos de la misma empresa, puede provocar un aumento perceptible de la latencia de LDAP y de la carga en el almacenamiento subyacente.
Desafíos de la sensibilidad a la latencia
Como se ha comentado anteriormente, debido a los requisitos de latencia, cada contenedor almacena todos los datos de un cliente en memoria (véase la figura a). Los datos se recuperan bajo demanda cuando la solicitud llega a un nodo (si aún no están presentes) y luego permanecen mientras se mantenga al menos una conexión de ese cliente.
Dado que una solicitud de conexión entrante puede llegar a cualquier contenedor (a través del equilibrador de carga), el contenedor que atiende una consulta también carga y almacena todos los datos del cliente. Posteriormente, el contenedor se registra en un servicio de redis pubsub para recibir mensajes de invalidación. Cuando se actualizan los datos de la empresa, se transmite una señal de invalidación a los nodos receptores, que borran la caché de datos de esa empresa y acceden a la base de datos para volver a obtener sus datos.
Esto planteó los siguientes desafíos para escalar nuestro servicio LDAP a medida que seguíamos creciendo e incorporando nuevos clientes a nuestro sistema:
Todos los datos del cliente (M) en todos los nodos (N) requieren una recarga cuando se invalidan. Aunque en la práctica no todos los nodos alojan una conexión de cada cliente, en el peor de los casos se realizan MxN llamadas a la base de datos para actualizar los datos. A medida que se añaden más clientes (M), el número de recuperaciones de la BD puede aumentar por un factor de N. Esto también significaba que, para no sobrecargar las máquinas de la base de datos, se necesitaban instancias adicionales de lector de BD para gestionar el aumento repentino de solicitudes.
Dado que todos los datos de los clientes (M) se almacenan en memoria en muchos nodos (N), la memoria sigue aumentando en todos los nodos de forma proporcional al número de clientes (M). Esto también significa que los requisitos de memoria del contenedor deben aumentar para albergar todos los datos en la memoria, lo que a su vez incrementa el coste total de la infraestructura.
Los desafíos anteriores eran muy claros y nos llevaron a distribuir los datos de los clientes entre los nodos en lugar de replicar todos los datos en cada nodo. Esto nos llevó a una solución distribuida de gestión de caché.
Gestión distribuida de caché
Introdujimos una capa de enrutamiento inteligente en nuestro servicio LDAP que reenviaba las solicitudes a los nodos que alojaban los datos del cliente si el contenedor en el que aterrizaba la conexión no alojaba esos datos. Para lograrlo, nos centramos en los siguientes requisitos de diseño para la capa de enrutamiento:
Los clientes deben distribuirse dinámicamente entre los nodos a medida que se añaden.
Los datos de los clientes deben distribuirse dinámicamente a medida que los nodos se reducen, se expanden y cuando se producen fallos en los nodos.
La capacidad de aumentar y reducir el número de particiones para un cliente específico, de modo que el desequilibrio del tráfico no sobrecargue ningún nodo individual.
Presentamos Apache Helix, que distribuye los recursos entre las instancias. El controlador Helix, el cerebro del ecosistema Helix, toma decisiones de asignación de recursos entre nodos cuando se añaden o eliminan nodos o clientes. Dockerizamos el controlador Apache Helix y el servidor Rest, y los desplegamos en ECS. El controlador Helix depende de Zookeeper para escuchar los cambios del clúster. Implementamos una forma fiable de desplegar Zookeeper en ECS, así que ahora toda la infraestructura de Helix y Zookeeper funciona en ECS.
Cada nodo LDAP interactúa con Zookeeper para registrarse y participar en el clúster. Cada instancia de LDAP aparece como un participante de Helix que participa en el clúster de asignaciones de cliente a nodo por parte del controlador de Helix. Cuando un nuevo cliente se crea sobre la marcha mediante un nodo LDAP, el número de particiones (cada partición representa un nodo que aloja los datos) para ese cliente se determina en función del número de usuarios.
Con esta integración, nuestros nodos LDAP están al tanto de los eventos que tienen lugar en el clúster (es decir, cuando se añade un nuevo cliente o cuando cambia el conjunto de nodos disponibles).
Con esta capacidad de reconocimiento de clústeres, la capa de enrutamiento de nuestro servicio LDAP proporciona la asignación entre los nodos y los clientes. Ahora, cada conexión entrante pasará por la capa de enrutamiento para decidir a qué nodo debe dirigirse la conexión. Con esto, los datos del cliente se asignan a nodos específicos (ver figura b).
La capa de enrutamiento aloja una caché que contiene la información de rutas de clientes y nodos. La capa de enrutamiento identifica cualquier cambio en la asignación de cliente a nodo y lo actualiza de inmediato cuando se detectan los cambios. De este modo, cada nodo LDAP conoce los cambios de cliente a nodo en cuanto se producen.
Con la solución de gestión de caché anterior, se abordaron los desafíos de escalabilidad mencionados en la sección Desafíos de sensibilidad a la latencia:
Ahora tenemos clientes distribuidos entre los nodos. Cada nodo alojará solo un subconjunto de clientes y será responsable de recuperar solo un subconjunto de los datos de los clientes al recibir invalidaciones de pubsub. Esto reduce significativamente el número de lecturas en la DB, eliminando la necesidad de añadir nodos lectores de DB para gestionar un alto volumen de lecturas de DB. El clúster LDAP ahora realiza un 75 % menos de lecturas de la base de datos que antes.
También hemos mejorado la eficiencia de la memoria porque no almacenamos todos los datos del cliente (M) en la memoria en todos los nodos (N). Esta arquitectura ofrece la posibilidad de escalar horizontalmente sin aumentar el tamaño de la instancia. Ahora, cada nodo LDAP consume un 40 % menos de memoria que antes.
Desafíos actuales
Con la implementación anterior, uno de los desafíos es que los nodos reciben un número desigual de conexiones TCP. Este desequilibrio en la distribución provoca un mayor uso de CPU en algunos nodos (nodos calientes) en comparación con otros. Pero la utilización media general de la CPU en todos los nodos sigue siendo la misma en comparación con antes.
Agradecimientos
Gracias a todo el equipo. Mención especial a Bryan Bojorque por ayudarnos con la containerización y la creación del clúster de Helix y Zookeeper, y por dar vida a las métricas de estos clústeres en Datadog.
Mejora tu seguridad
¿Tu red está protegida contra usuarios no autorizados? Haz clic aquí para descubrir cómo Foxpass puede ayudarte a evitar costosos errores de seguridad:
