Einführung
LDAP (Lightweight Directory Access Protocol) ist eine allgegenwärtige Quelle für Verzeichnisinformationen, die erstmals 1993 kodifiziert wurde. Es wird häufig für eine Vielzahl von Anwendungen verwendet, darunter die Verwaltung von Benutzer-/Gruppeninformationen für Linux-Instanzen und die Steuerung der Authentifizierung für VPNs und Legacy-Anwendungen.
Traditionell wurde der LDAP-Server eines Unternehmens intern betrieben. häufig entweder Teil von Microsofts Active Directory oder eine Bereitstellung des Open-Source-Projekts OpenLDAP. Heutzutage ist LDAP-Support von SaaS-Anbietern verfügbar, darunter Foxpass, der erste cloudbasierte LDAP-Anbieter, der eine mandantenfähige, cloudzentrierte LDAP-Implementierung von Grund auf entwickelt hat.
LDAP verfügt typischerweise über die folgenden Grundoperationen: bind, search, compare, und add. Nach dem Herstellen einer Transmission Control Protocol (TCP)-Verbindung müssen Anwendungen sich zunächst binden, indem sie einen Benutzernamen und ein Passwort senden. Nach erfolgreicher Bindung sendet der Client Befehle an den LDAP-Server. Typischerweise ist dies der Befehl „Suchen“ in Verbindung mit Filtern. Die TCP-Verbindung bleibt bestehen, bis entweder der Client oder der Server die Verbindung trennt.
LDAP bei Foxpass
Bei Foxpass basiert unser LDAP-Dienst auf Twisted, einem beliebten ereignisbasierten Service-Framework für Python. Der Dienst wird auf der ECS-Plattform von AWS gehostet und läuft auf Dutzenden von Containern (Knoten). Da LDAP-Verbindungen persistent sind, muss der Cluster in der Lage sein, Hunderttausende gleichzeitige TCP-Sitzungen aufrechtzuerhalten.
Wir halten die Daten der Kunden im RAM. Der Grund dafür ist vielfältig: Erstens ist der Datensatz selbst bei großen Kunden relativ klein. Zweitens ermöglicht die LDAP-Abfragesprache die Suche in beliebigen Feldern (was wichtig ist, da Foxpass benutzerdefinierte Felder zulässt). Das bedeutet, dass ein traditionelles RDBMS-System keine effektiven Indizes erstellen kann und wir die Daten in eine andere In-Memory-Darstellung umwandeln müssen. Drittens ermöglicht das Vorhalten der Daten im RAM die schnellstmögliche Reaktionszeit: Die Latenzen liegen typischerweise bei etwa 100 ms (siehe Diagramm a).
Ein Nachteil bei diesem Ansatz ist die Cache-Invalidierung. Wenn sich die Daten eines Kunden ändern (wenn beispielsweise ein Benutzer hinzugefügt oder gelöscht wurde), müssen die LDAP-Knoten ihre Daten aus unserem primären RDBMS aktualisieren. In unserer vorherigen Architektur war dies ein relativ kostspieliger Vorgang; wenn jeder Knoten die Daten desselben Unternehmens aktualisiert, kann dies zu einem spürbaren Anstieg der LDAP-Latenz und der Last auf dem Backing-Store führen.
Herausforderungen durch Latenzempfindlichkeit
Wie oben erläutert, speichert jeder Container aufgrund der Latenzanforderungen alle Daten eines Kunden im Arbeitsspeicher (siehe Abbildung a). Die Daten werden bei Bedarf abgerufen, wenn die Anfrage einen Knoten erreicht (falls sie nicht bereits vorhanden sind), und bleiben dort, solange mindestens eine Verbindung dieses Kunden bestehen bleibt.
Da eine eingehende Verbindungsanfrage auf jedem beliebigen Container landen kann (über den Load Balancer), lädt und speichert der Container, der die Anfrage bearbeitet, auch sämtliche Kundendaten. Anschließend registriert sich der Container bei einem redis pubsub -Dienst, um Invalidierungsnachrichten zu empfangen. Wenn sich die Unternehmensdaten aktualisieren, wird ein Invalidierungssignal an die empfangenden Knoten gesendet. Diese leeren den Cache dieses Unternehmens und rufen die Unternehmensdaten erneut aus der Datenbank ab.
Dies stellte uns bei der Skalierung unseres LDAP-Dienstes mit unserem kontinuierlichen Wachstum und der Aufnahme neuer Kunden in unser System vor folgende Herausforderungen:
Alle Daten für den Kunden (M) über alle Knoten (N) hinweg erfordern bei Invalidierungen ein erneutes Laden. Obwohl in der Praxis nicht jeder Knoten eine Verbindung von jedem Kunden hostet, werden im schlimmsten Fall MxN Aufrufe an die Datenbank ausgeführt, um die Daten zu aktualisieren. Wenn weitere Kunden hinzugefügt werden (M), kann sich die Anzahl der DB-Abrufe um den Faktor N erhöhen. Das bedeutete auch, dass zusätzliche DB-Reader-Instanzen erforderlich sind, um den Anstieg der Anfragen zu bewältigen, damit die Datenbankmaschinen nicht überlastet werden.
Da alle Daten über Kunden hinweg (M) im Speicher über viele Knoten (N) verteilt gespeichert werden, steigt die Speichernutzung auf allen Knoten weiterhin proportional zur Anzahl der Kunden (M). Das bedeutet auch, dass der Speicherbedarf des Containers wachsen muss, um alle Daten im Arbeitsspeicher unterzubringen, was wiederum die gesamten Infrastrukturkosten erhöht.
Die oben genannten Herausforderungen waren sehr klar und veranlassten uns dazu, die Daten der Kunden auf die Knoten zu verteilen, anstatt alle Daten auf jedem Knoten zu replizieren. Dies führte uns zu einer verteilten Cache-Management-Lösung.
Verwaltung verteilter Caches
Wir haben in unserem LDAP-Service eine intelligente Routing-Schicht eingeführt, die Anfragen an die Knoten weiterleitete, auf denen die Kundendaten gehostet wurden, falls der Container, auf dem die Verbindung einging, diese Daten nicht hostete. Um dies zu erreichen, haben wir die folgenden Designanforderungen für die Routing-Schicht festgelegt:
Kunden müssen dynamisch auf die Knoten verteilt werden, sobald diese hinzugefügt werden.
Die Daten der Kunden müssen dynamisch verteilt werden, wenn die Knoten schrumpfen, wachsen oder Knotenausfälle auftreten.
Die Möglichkeit, die Anzahl der Partitionen für einen bestimmten Kunden zu erhöhen oder zu verringern, damit ein Ungleichgewicht im Datenverkehr keinen einzelnen Knoten überlastet.
Wir haben Apache Helix eingeführt, das die Ressourcen auf die Instanzen verteilt. Der Helix-Controller, das Gehirn des Helix-Ökosystems, trifft Entscheidungen zur Ressourcenzuweisung über Knoten hinweg, wenn Knoten oder Kunden hinzugefügt oder entfernt werden. Wir haben den Apache Helix Controller und den Rest-Server in Docker-Container verpackt und auf ECS bereitgestellt. Der Helix-Controller ist auf Zookeeper angewiesen, um Clusteränderungen zu überwachen. Wir haben eine zuverlässige Methode zur Bereitstellung von Zookeeper auf ECS implementiert, sodass jetzt die gesamte Infrastruktur von Helix und Zookeeper auf ECS läuft.
Jeder LDAP-Knoten interagiert mit dem Zookeeper, um sich selbst zu registrieren und am Cluster teilzunehmen. Jede LDAP-Instanz wird als Helix-Teilnehmer eingebunden, der am vom Helix-Controller verwalteten Cluster der Kunden-zu-Knoten-Zuweisungen teilnimmt. Wenn ein neuer Kunde spontan von einem LDAP-Knoten erstellt wird, wird die Anzahl der Partitionen (wobei jede Partition einen Knoten darstellt, der die Daten hostet) für diesen Kunden anhand der Anzahl der Benutzer bestimmt.
Mit dieser Integration sind unsere LDAP-Knoten über Ereignisse informiert, die im Cluster stattfinden (d. h. wenn ein neuer Kunde hinzugefügt wird oder wenn sich die Menge der verfügbaren Knoten ändert).
Mit diesem Cluster-Bewusstsein stellt die Routing-Ebene in unserem LDAP-Service die Zuordnung zwischen den Knoten und den Kunden bereit. Jede eingehende Verbindung durchläuft nun die Routing-Ebene, um zu entscheiden, zu welchem Knoten die Verbindung weitergeleitet werden muss. Damit werden die Daten des Kunden bestimmten Knoten zugewiesen (siehe Abbildung b).
Die Routing-Ebene hostet einen Cache, der die Routing-Informationen von Kunden und Knoten enthält. Die Routing-Ebene erkennt Änderungen bei der Kundenzuordnung zu Knoten und aktualisiert diese sofort, sobald die Änderungen erkannt werden. Auf diese Weise ist jeder LDAP-Knoten über Änderungen zwischen Kunde und Knoten informiert, sobald sie eintreten.
Mit der oben genannten Lösung für das Cache-Management wurden die im Abschnitt Herausforderungen bei der Latenzempfindlichkeit genannten Skalierbarkeitsprobleme gelöst:
Wir haben jetzt Kunden, die über die Nodes verteilt sind. Jeder Knoten hostet nur eine Teilmenge der Kunden und ist dafür verantwortlich, beim Empfang von PubSub-Invalidierungen nur eine Teilmenge der Kundendaten abzurufen. Dadurch wird die Anzahl der Lesezugriffe auf die DB erheblich reduziert, sodass keine DB-Reader-Nodes mehr hinzugefügt werden müssen, um ein hohes Volumen an DB-Lesezugriffen zu bewältigen. Der LDAP-Cluster führt jetzt 75 % weniger DB-Lesevorgänge durch als zuvor.
Wir haben außerdem die Speichereffizienz verbessert, weil wir nicht alle Kundendaten (M) über alle Knoten (N) hinweg im Arbeitsspeicher speichern. Diese Architektur ermöglicht eine horizontale Skalierung, ohne die Instanzgröße zu erhöhen. Jeder LDAP-Knoten verbraucht jetzt 40 % weniger Speicher als zuvor.
Aktuelle Herausforderungen
Bei der oben beschriebenen Implementierung besteht eine der Herausforderungen darin, dass Knoten eine ungleiche Anzahl von TCP-Verbindungen erhalten. Dieses Verteilungsungleichgewicht führt dazu, dass einige Knoten (Hot Nodes) im Vergleich zu anderen stärker ausgelastet sind und mehr CPU-Ressourcen nutzen. Die durchschnittliche Gesamtauslastung der CPU über alle Knoten hinweg bleibt im Vergleich zu vorher jedoch gleich.
Danksagungen
Vielen Dank an das gesamte Team. Besonderer Dank an Bryan Bojorque für seine Unterstützung bei der Containerisierung und dem Aufbau des Helix- und Zookeeper-Clusters sowie dafür, die Metriken aus diesen Clustern in Datadog sichtbar gemacht zu haben.
Verbessern Sie Ihre Sicherheit
Ist Ihr Netzwerk vor unbefugten Benutzern geschützt? Klicken Sie hier, um zu erfahren, wie Foxpass Ihnen helfen kann, kostspielige Sicherheitsfehler zu vermeiden:
