Bundesamt für Sicherheit in der Informationstechnik

M 4.389 Partitionierung und Replikation bei OpenLDAP

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Die Aufteilung von Teilbäumen eines Verzeichnisdienstes auf verschiedene Server (Partitionierung) ist eine effektive Möglichkeit, um durch Lastverteilung eine höhere Verfügbarkeit zu erreichen. Damit die Aktualität der Verzeichniskopien sichergestellt ist, müssen Veränderungen an den Daten durch Replikation zwischen den Servern ausgetauscht werden. Welcher Replikationsmodus angemessen ist, muss in Anhängigkeit von Netzverbindungen und Verfügbarkeitsanforderungen gewählt werden.

In dieser Maßnahme ist die mögliche Umsetzung dieser Konzepte mit OpenLDAP beschreiben, für die generelle Planung von Partitionierung und Replikation siehe Maßnahme M 2.409 Planung der Partitionierung und Replikation im Verzeichnisdienst .

Partitionierung

Die Partitionierung von Verzeichnisdiensten unter Open LDAP ist sehr einfach zu konfigurieren. Wird ein Teil des Verzeichnisses ausgelagert oder soll ein Server wissen, welcher andere Server gewisse Teilbäume vorhält, so ist in der globalen Konfiguration dieses Servers der entsprechende Suffix als ein Objekt der Objektklasse "referral" anzulegen. Die Referenzadresse des Servers mit dem ausgelagerten Teilbaum wird dem Attribut "ref" zugeordnet. Operationen von Clients, die diesen Teil des Verzeichnisdienstes betreffen, beantwortet der Server mit einem Verweis auf diese Adresse. Die Zuordnung wird als "Subordinate Knowledge Information" bezeichnet. Der Server "weiß", welcher Teil des Verzeichnisbaumes auf welchem Server zu finden ist. Soll sichergestellt werden, dass der Server bei Suchanfragen ausgelagerte Teilbäume selbst durchsucht, ist die jeweilige Datenbank mit der Direktive "subordinate" bzw. "olcSubordinate" mit der Datenbank des Servers zu verbinden. Dieser Vorgang wird als Gluing (leimen) bezeichnet.

Ein untergeordneter Server wird im Gegenzug nicht mit der genauen Information darüber versorgt, von welchen anderen Servern welche Teilbäume oberhalb oder gleichberechtigt mit seinem gespeichert werden. Wann immer eine Operation nicht zu einem Suffix des Servers passt, wird diese mit einem globalen "Referral" (Verweis) beantwortet, das heißt, der anfragende Client wird an einen Server verwiesen, der die Antwort liefern könnte. Bei Partitionen wird hier der übergeordnete Verzeichnisdienst eingetragen. Das Referral wird in diesem Zusammenhang auch als "Superior Knowledge Information" bezeichnet, obwohl die Direktive auch unabhängig von Partitionierungen verwendet werden kann. Die über die Adressen in den Referrals identifizierten Verzeichnisdienste müssen nicht mit OpenLDAP betrieben werden.

Durch das Overlay "chain" (Chaining) kann der Server Referrals auch selbst verfolgen. Der Client bemerkt dadurch nichts von einer Partitionierung und bekommt eine abschließende Antwort immer vom ursprünglich angefragten Server. Dies funktioniert unabhängig von den Fähigkeiten des Clients, der gegebenenfalls selbst keine Referrals verarbeiten kann.

Replikation

Bei OpenLDAP wird die Replikation über den "LDAP Sync Replication Engine" (syncrepl) Mechanismus umgesetzt. Der Mechanismus ist auf die BerkeleyDB abgestimmt und wird nur von den Backends "back-bdb" und "back-hdb" unterstützt. Das bedeutet, OpenLDAP kann nicht ohne Weiteres als Agent eingesetzt werden, um Verzeichnisdienste zu replizieren, für die der slapd-Server lediglich einen Proxy darstellt.

Vor der Entwicklung des "syncrepl"-Mechanismus wurde der "stand-alone LDAP update replication daemon" (slurpd) zur Replikation verwendet. Hierbei handelte es sich um ein Programm, das wie der slapd-Server als Dienst ausgeführt wurde und Kopien der Verzeichnisdienstinhalte pflegte. Dieser Dienst hat nicht zuverlässig funktioniert und wurde mit der Version 2.4 offiziell aus OpenLDAP entfernt. Hinweise auf "slurpd" in veralteten Dokumentationen sind als historisch anzusehen. Der "slurpd" darf keinesfalls verwendet werden.

Master und Slave, Provider und Consumer

Traditionell werden die an der Replikation beteiligten Server als Master und Slave bezeichnet. Der Master ist der eigentliche Verzeichnisdienst, über diesen Server kann schreibend auf Verzeichnisdienstinhalte zugegriffen werden. Der Slave übernimmt nur alle Informationen vom Verzeichnisdienst und gewährt auf diese Kopie lesenden Zugriff. Diese strikte Trennung gilt in OpenLDAP seit der Version 2.3 nicht mehr. Bei der Replikation in OpenLDAP übernimmt ein sogenannter Consumer-Dienst Daten von einem Provider -Dienst. Es wichtig zu verstehen, dass ein Consumer gegenüber dem Provider als Client auftritt, obwohl der Consumer seine Replik selbst als Server für andere Clients zur Verfügung stellt. Die Einstellungen zur Serversicherheit des Consumers gelten für die Verbindung zum Provider nicht. Stattdessen gilt die Client-Konfiguration, diese ist auf einem Consumer sorgfältig vorzunehmen, obwohl sie für Server eigentlich nicht benötigt wird. Es ist insbesondere zu berücksichtigen, dass der Consumer ein "bind" beim Provider vornehmen muss und etwaige Zugriffsbeschränkungen und Suchlimits des verwendeten Benutzers die Replikation behindern können.

refreshOnly und refreshAndPersist

Die Replikation kann in einem pull- oder einem push-Mode betrieben werden. Beim pull-Mode, der in OpenLDAP als "refreshOnly" bezeichnet wird, fragt der Consumer in festgelegten Abständen den Provider auf Änderungen ab. Dabei sendet der Consumer in Form eines "Sync Cookies" die Aktualität der von ihm gehaltenen Daten. Aufgrund dieser Information wird beim Provider eine Suche gestartet, die alle Änderungen seit dem vom Consumer gemeldeten Zeitpunkt umfasst. Der Provider "kennt" in diesem Fall den Consumer nicht, er beantwortet lediglich Suchabfragen. Damit diese Suchen korrekte Ergebnisse bringen, ist es besonders wichtig, dass die Uhren von Provider und Consumer möglichst synchron laufen (siehe M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation und M 4.348 Zeitsynchronisation in virtuellen IT-Systemen ). Beim "push-Mode", der in OpenLDAP als "refreshAndPersist" bezeichnet wird, bleibt die Verbindung zwischen Provider und Consumer bestehen und der Provider sendet alle Änderungen immer an den Consumer. Bei der Auswahl der geeigneten Replikationsmethode gilt als Faustregel, dass "refreshOnly" umso sinnvoller ist, je größer die zu replizierenden Datenmengen sind und "refreshAndPersist" umso eher eingesetzt werden sollte, je wichtiger eine zeitnahe Aktualisierung des Providers ist.

Einrichtung einer Replikation

Um die Replikation eines Verzeichnisdienstes mit OpenLDAP einzurichten, sind mehrere Schritte nötig:

  • Der Consumer muss installiert (siehe M 4.383 Sichere Installation von OpenLDAP ) und konfiguriert (siehe M 4.384 Sichere Konfiguration von OpenLDAP ) werden. Dies kann und sollte nach Möglichkeit durchgeführt werden, indem Kopien der Provider-Konfiguration auf den Provider übertragen werden. Bei der Consumer-Konfiguration ist besonders wichtig, dass auf dem Consumer die gleichen Schemas eingerichtet werden, wie auf dem Provider.
  • Auf dem Consumer muss für die zu replizierende Datenbank die Datenbank-Direktive "syncrepl" eingerichtet werden. Mit den Sub-Direktiven "searchbase", "filter", "scope" und "attrs" lässt sich bestimmen, was repliziert werden soll. So können neben dem gesamten Verzeichnisdienst zum Beispiel nur Teilbäume repliziert werden oder auch nur bestimmte Attribute von Objekten. Bei der Einrichtung ist besonders zu beachten, dass im Fall der Online-Konfiguration auch der Konfigurationssuffix "CN=config" repliziert werden kann. Weitere Sub-Direktiven bestimmen die Adresse des Providers, replikationsspezifische Einstellungen zur Sicherung der Kommunikation zwischen Consumer und Provider, die Replikationsmethode und die Wiederaufnahme der Verbindung zum Provider, wenn diese abbricht (refreshAndPersist) oder der Provider nicht erreicht werden kann (refreshOnly).
  • Besonders wird außerdem auf die Sub-Direktive "schemachecking" hingewiesen. Ist "schemachecking" deaktiviert (was dem Vorgabewert entspricht), können durch die Replikation auch solche Daten eingefügt werden, die nach den Schemas eigentlich unzulässig sind. Dies kann sinnvoll sein (insbesondere bei Teilrepliken), aber die Integrität der Repliken einschränken.
  • Obwohl die Einstellungen zur Replikation hauptsächlich auf dem Consumer vorzunehmen sind, muss auch der Provider für eine korrekte Replikation konfiguriert werden. Damit er Suchanfragen des Consumers in Abhängigkeit von einem Änderungszeitpunkt beantworten kann, muss sich der Provider selbst vorgenommene Änderungen merken beziehungsweise eine Übersicht aktueller Zeitstempel, sogenannter "context change sequence numbers" (contextCSNs) führen. Dies wird durch den Aufruf des Overlay "syncprov" (Sync Provider) erreicht.
  • Um die Consumer-Datenbank erstmals zu befüllen, wird empfohlen, nur die benötigten Datensätze aus einer Datensicherung des Providers einzuspielen (siehe M 6.150 Datensicherung beim Einsatz von OpenLDAP ), da eine vollständige Übertragung aller Verzeichnisdienstinhalte über das Netz unnötig Zeit und Ressourcen beansprucht. Weil syncrepl über Mechanismen zum Datenabgleich verfügt, ist es nicht notwendig, dass die verwendete Datensicherung aktuell ist. Wird eine Datensicherung eingespielt, die noch keine contextCSNs enthält, ist der Parameter "-w" anzugeben, wenn die Datenbank mit slapadd befüllt wird, damit contextCSNs erzeugt werden. Dies wird insbesondere bei einer ersten Replikation der Fall sein, da der Provider üblicherweise noch nicht auf einen solchen Betrieb vorbereitet war und das Overlay "syncprov" noch nicht aufgerufen wurde.

Delta-Replikation

Grundsätzlich sendet der Provider alle Attribute von Einträgen, die geändert wurden, als Suchergebnis oder im Rahmen der Replikation. Er tut dies selbst dann, wenn im Eintrag nur eines der Attribute verändert wurde. In Verbindung mit dem Overlay "accesslog" (siehe auch M 4.407 Protokollierung beim Einsatz von OpenLDAP ) ist es auch möglich, die Veränderungen von Attributen detailliert aufzuzeichnen und dann mit dem "syncrepl"-Mechanismus lediglich die Änderungen zu übermitteln. Dies setzt eine umfangreichere Konfiguration voraus. Bei häufigen Änderungen von kleinen Attributen an relativ großen Objekten sollte diese Möglichkeit geprüft werden, bei wenigen Objekten oder geringen Anzahlen ist die Delta-Replikation nicht notwendig.

Multi-Master- und Mirror-Mode-Betrieb

Es ist auch möglich, einen Multi-Master-Betrieb einzurichten. Bei einem Multi-Master-Betrieb gibt es mehr als einen Server, auf den schreibend zugegriffen werden kann, und die Master sind untereinander sowohl Provider als auch Consumer. Der Sinn dieser Betriebsvariante besteht darin, dass beim Ausfall eines Servers immer noch schreibender Zugriff auf den Verzeichnisdienst besteht, ohne dass (wie bei einem Slave/nur-Consumer) erst die Konfiguration angepasst werden muss. Dieser Betrieb ist nicht unumstritten und wird von einigen Mitgliedern des OpenLDAP-Teams als nicht sinnvoll angesehen, da er die Konsistenz eines Verzeichnisses bedrohen kann. Dies geschieht, wenn auf den beiden Mastern zeitgleich konkurrierende Änderungen vorgenommen werden. Ein Multi-Master-Betrieb ist für eine OpenLDAP-Installation in einem Informationsverbund mit normalem Schutzbedarf nicht notwendig. Sollten hohe oder sehr hohe Anforderungen an die Verfügbarkeit bestehen, kann eine Multi-Master-Konfiguration geprüft werden. Als Faustregel kann gelten, je wichtiger die unterbrechungsfreie Verfügbarkeit ist, desto eher ist ein Multi-Master-Betrieb sinnvoll, je wichtiger die Integrität der Daten zu jedem Zeitpunkt ist, desto weniger sinnvoll ist der Multi-Master-Betrieb.

Als Alternative zwischen dem Single-Master- und Multi-Master-Betrieb besteht die Möglichkeit eines Mirror-Mode-Betriebs. Bei dieser Betriebsvariante bestehen ebenfalls mehrere Server, über die schreibend auf den Verzeichnisdienst zugegriffen werden kann. Allerdings legt eine externe Monitoring-Komponente immer einen aktiven Server fest, der Änderungen durchführt. Fällt ein Server aus, bestimmt die Monitoring-Komponente automatisch den anderen Server zum aktiven Server. Die Delta-Replikation wird in dieser Betriebsart noch nicht unterstützt. Nachteilig ist auch, dass beim Ausfall der Monitoring-Komponente der eigentlich redundant ausgelegte Verzeichnisdienst nicht mehr verfügbar ist.

Prüffragen:

  • Werden bei OpenLDAP auf Provider und Consumer hinreichend genaue Zeitdienste betrieben?

  • Wird in Abhängigkeit von Netzverbindungen und Verfügbarkeitsanforderungen über den angemessenen Replikationsmodus von OpenLDAP entschieden?

  • Sind bei der Consumer-Konfiguration von OpenLDAP die gleichen Schemas eingerichtet worden, wie auf dem Provider?

Stand: 13. EL Stand 2013