Diplomarbeit LDAP UBIK

Transkript

1 Diplomarbeit LDAP UBIK Verfasser: Alexander Merzky Matrikel: Fakultät für Informatik Professur Rechnernetze und verteilte Systeme Betreuer: Dipl.-Inf. Chris Hübsch eingereicht am:

2 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung Grundlagen LDAP - Lightweight Directory Access Protocol Einführung Das LDAP-Protokoll Das LDAP-Datenmodell Einsatzszenarien Replikation Einführung Multi-Master-Replikation Single-Master-Replikation Die Failover-Konstellation Weitere Aspekte Nachteile Anforderungen - Top-Down Entwurf Anforderungen Allgemeine Anforderungen Anforderungen an den Replikationsmechanismus Fazit Replikationsmodelle - Bottom-Up Entwurf Vorhandene LDAP-Replikationsmethoden LDAP-slurpd ixsync LDAP Sync-Operation Der UBIK-Algorithmus OpenAFS - UBIK UBIK-Implementierung der Carnegie Mellon University Andere Modelle Bayou Oracle Replikationsmedium Eignung der Möglichkeiten Untersuchung der Mechanismen und Modellentwurf Bewertung und Wahl der Mechanismen LDAP-slurpd / LDAP-sync UBIK Modellentwurf Aufgabenverteilung Anpassung der Aktualitätskriterien Anpassung des VOTING-Mechanismus Zustandsmapping Das Leseverbot Berücksichtigung von Teilbaumreplikationen

3 5.2.7 Klientenbenachrichtigung Design und Implementierung Grundlegende Änderungen Änderungen der CMUbik-Bibliothek Änderungen / Erweiterungen des slapd Das Kommunikationsmodell Kommunikation zwischen slapd und lokalem UBIK Kommunikation zwischen den UBIK-Instanzen Das Prozessmodell und Interprozesskommunikation Das Ablaufmodell anhand eines Szenarios Voraussetzungen Der Serverstart Die Masterwahl Klienteninteraktion Ein dritter Server tritt ein Ein Serverausfall Teilbaumreplikation Der RefreshAndPersist-Modus Behandlung von ungünstigen Konstellationen Grenzfälle Klientenaktionen während des Quorum-Timeouts Updates und Ausfälle im RefreshOnly-Modus Einsatzszenarien Der Quelltext UBIK Der ubik loop Die Funktion parse() Für die Wahl wichtige Funktionen Modifizierter slapd-quelltext Die Initialisierung Der slapd daemon task Ubiksync Ubiksync get sync ctxcsn() Ubiksync change syncstate() Ubiksync state set master() Installation, Konfiguration und Test Installation der Quellpakete BerkeleyDB SASL OpenLDAP mit ubiksync Konfiguration Voraussetzung für den Betrieb von ubiksync Konfiguration des slapd Konfiguration von UBIK Initialisierung Test Die Wahl

4 8.3.2 Eintritt eines nicht-aktuellen Servers Ausfall des Masters Ausfall eines Slaves Teilbaumreplikation Performance Fazit Anforderungskonformität Verbesserungs- / Optimierungsmöglichkeiten Abschliessende Worte / Ausblick A Quellen 104 B Abbildungen 105 C Selbstständigkeitserklärung 106

5 Abkürzungen und Begriffe Attribute BaseDN CSN ContextCSN CS Ctxcsn DAP DIT DN DNS DSA DSE Entry EntryCSN GPL IMAP LAN LDAP LDIF Matching Rule MIB NC NDS NIS NS OID P2P Quorum RDN Referral RootDSE Schema Scope Slapd Slurpd Suffix URL WAN Ein Datenelement, das in einem Entry untergebracht ist Wurzel des NC, Suffix Change Sequence Number (Zeitstempel der letzten Änderung) CSN des NC s eines LDAP-Servers Client-Server (Kommunikationsmodell zwischen Provider und Consumer) ContextCSN Directoryx Access Protocol Directory Information Tree (Naming Context) Distinguished Name (Absolute Pfadangabe im DIT) Domain Name Service Directory Service Agent (LDAP-Server, kann mehrere NC s verwalten) DSA specific Entry Knoten oder Blatt im DIT CSN eines einzelnen Entries im NC eines LDAP-Servers GNU Public Licence Internet Messaging Access Protocol Local Area Network Lightweight Directory Access Protocol LDAP Data Interchange Format (Dateiformat für Im-/Export von LDAP-Daten) Regel, in welcher Weise Attribute verglichen werden Management Information Base Naming Context (Eindeutiger NS inklusive rootdn) Netware Directory Service Network Information Service Name Space (gesamter Teilbaum, der unter dem rootdn liegt Object ID (eindeutiger Identifikator für eine Schemadefinition) Peer To Peer (Kommunikationsmodell zwischen gleichberechtigten Hosts) Menge von Servern, die einen gemeinsamen Master wählen Relative Distinguished Name (relative Pfadangabe im DIT) URL eines anderen LDAP-Servers, die dem Klienten zurückgeliefert wird, wenn der lokale Server die Anfrage nicht verarbeiten kann Wurzel eines DITs (enthält Informationen über den Server) Art der Definition von Entries, Attributen, MatchingRules entsprechen Datentypen Suchtiefe im DIT openldap Server openldap Replikationsagent Wurzel des NC Uniform Resource Locators Wide Area Network

6 1 Einleitung 1.1 Aufgabenstellung Das Problem bei einigen verteilten Verzeichnissen, wie zum Beispiel bei OpenLDAP ist, dass es nur einen Masterserver gibt, auf dem Änderungsoperationen durchgeführt werden können. Auf die Replikaserver kann nur lesend zugegriffen werden. Diese Konstellation wird dann zum Problem, wenn der Masterserver aus irgendeinem Grund nicht erreichbar ist. Dann wären Schreiboperationen so lange nicht erlaubt, bis der Masterserver wieder in Betrieb ist oder ein anderer Server dessen Aufgabe übernimmt. Um die Administration dieser Dienste zu erleichtern, wäre es wünschenswert, den gesamten Serverpool als Einheit zu betrachten und den Servern selbst die Verteilung der Daten zu überlassen. Sie sollten also autonom die Änderungen verbreiten und bei Ausfällen selbstständig ihre Struktur optimal anpassen oder wiederherstellen. Im Rahmen der Diplomarbeit sollen verschiedene Mechanismen auf deren Eignung untersucht werden. Dabei spielen Zuverlässigkeit, Leistung und Resourcenverbrauch im Zusammenspiel mit verschiedenen Nutzungsszenarien eine zentrale Rolle. Weiterhin soll bei der Wahl des Mechanismus auf die Art, den Umfang und die Häufigkeit der Änderungen Rücksicht genommen werden. Der für diese Ansprüche optimale Mechanismus soll als Modul für den OpenLDAP Server sowie ggf. eine Klientenerweiterung implementiert werden und unter die GPL gestellt werden. 6

7 2 Grundlagen 2.1 LDAP - Lightweight Directory Access Protocol Einführung LDAP ist eine vereinfachte Form des X.500 Directory Access Protocol. Es wird bisher grösstenteils benutzt, um z.b. ein Personenverzeichnis einer Einrichtung zu verwalten und dabei die innere Struktur der Organisation abzubilden. Wie der Name schon sagt, handelt es sich um ein Verzeichnis-Zugriffs-Protokoll. Ein Verzeichnis kann als eine Art Datenbank verstanden werden, die aber so optimiert ist, dass Leseoperationen sehr viel weniger Rechenaufwand benötigen als Schreiboperationen. Wie in einem Telefonbuch sind die enthaltenen Daten indexiert, sodass man bei der Suche nach einem bestimmten Eintrag durch Angabe des Indexes alle mit dem Index übereinstimmenden Einträge zurückbekommt. Der Index in einem Telefonbuch ist zum Beispiel der Nachname, die Stadt, der Stadtteil u.s.w.. Auch ein Inhaltsverzeichnis eines Buches ist ein Beispiel für einen Verzeichnisindex, genauso wie die Verzeichnisstruktur in einem Computerfilesystem. Abstrakt gesagt haben Verzeichnisse die Aufgabe, gesammeltes Wissen schnell zugänglich zu machen. Ein Entry (Verzeichniseintrag) besteht aus einem Distinguished Name (DN) und einer Anzahl von Attributen mit zugehörigen Werten. Einen Distinguished Name kann man sich als Pfadangabe vorstellen. Um beim Beispiel Computerfilesystem zu bleiben, entspricht der Distinguished Name dem absoluten Pfad zu einer Datei, z.b. /home/user1/public-html/index.html. Wenn man aber die Filesystemstruktur in LDAP übertragen will, ist es wichtig zu wissen, dass in LDAP der most-specific-value (hier index.html) als erstes dargestellt wird. (cn=index.html, cn=public-html, cn=user1, cn=home) wäre zum Beispiel ein DN für o.g. Filesystempfad. Jedes einzelne der 4 Elemente des DN ist ein Relative Distinguished Name (RDN). Das bedeutet, dass dieses Element einen Verzweigungsast im Verzeichnisbaum darstellt. Für das Beispiel kann das Verzeichnis /home/user1/ die Unteverzeichnisse public-html, PUBLIC, PRIVATE, mathe u.s.w. haben. Diese Unterverzeichnisse stellen im Verzeichnisbaum RDN s ausgehend von /home/user1/ dar. Attribute sind Eigenschaften eines Eintrags. Das Verzeichnis mit dem DN (cn=public-html, cn=user1, cn=home) kann mit den Eigenschaften cn=public-html, owner=user1, group=bin, inode= u.s.w. definiert werden. In einem Telefonbuch wäre der DN von einer Person z.b. cn=alexander, cn=merzky, cn=chemnitz, cn=deutschland. Die Attribute sind etwa Strasse, Hausnummer, Telefonnummer. Im Unterschied zum Telefonbuch kann man aber in elektronischen Verzeichnissen nicht nur nach RDN s suchen, sondern nach allen vorhandenen Attributen. Also ist bei der Abbildung des Telefonbuchs in X.500/LDAP auch die Suche nach einer bestimmten Telefonnummer möglich und nicht nur nach den Indizes Nach- und Vorname. Relationale Datenbanken durchforsten standardmässig bei einer Suchanfrage ihren gesamten Datenbestand, um einen zum Suchkriterium passenden Eintrag zu finden, während Verzeichnisse nur den Teilbaum durchsuchen, der bei der Suche angegeben wurde (searchbase). Dafür sind Einfügeoperationen in Datenbanken wesentlich einfacher, weil kein Pfad gesucht werden muss, in dem ein neuer Eintrag zu tätigen ist. Der Vorteil von LDAP gegenüber anderen Verzeichnisdiensten wie dem Netware Directory Service (NDS) oder MS Active Directory ist, dass es ein offener Standard ist und somit kostenlos, auf allen Plattformen verfügbar und frei änderbar ist. Der Begriff LDAP bezieht sich sowohl auf ein Protokoll zum Austausch von Verzeichnisinhalten als auch auf das Format, in dem die Daten intern organisiert sind. [IMPLDAP][BINLDAP] 7

8 2.1.2 Das LDAP-Protokoll Das LDAP-Protokoll ist direkt auf dem TCP-Layer aufgesetzt und beruht auf dem Client-Server- Prinzip. Demnach stellt ein Klient eine Anfrage an den Server, der diese dann entsprechend bearbeitet und dem Klienten das Ergebnis zurückliefert. Anfragen und Antworten werden dazu in LDAPMessages eingebettet. Eine LDAPMessage besteht aus: MessageID - eine eindeutige fortlaufende Nummer, die den Bezug zwischen Anfrage und Antwort herstellt protocolop - die Art der Anfrage bzw. Antwort controls - erweiterte Informationen Der Klient kann folgende Anfragen (protocolops) stellen: BindRequest - Klient will eine Verbindung zum Server aufbauen, dabei muss er sich ihm gegenüber authentifizieren Dafür stehen 2 Mechanismen zur Auswahl: Simple, SASL UnbindRequest - Klient will seine Verbindung zum Server trennen SearchRequest - Klient stellt eine Suchanfrage nach bestimmten Einträgen Diese werden durch folgende Suchattribute definiert: BaseObject: die Wurzel des Teilbaums, in dem die Suche stattfinden soll (searchbase) Scope: Soll nur das BaseObject, die gesamte nächste Ebene oder der ganze Teilbaum durchsucht werden Filter: Wonach soll gesucht werden, Angabe von Attribut-Wert Paaren ggf. mit Wildcards Attributes: Welche Attribute sollen zurückgegeben werden ModifyRequest - Klient will Einträge im Verzeichnuis ändern AddRequest - Klient will dem Verzeichnis einen neuen Eintrag hinzufügen DelRequest - Klient will einen Eintrag aus dem Verzeichnis löschen Bei diesen 3 Requestarten muss der DN des zu ändernden Eintrags angegeben werden, sowie gegebenenfalls Attribut-Werte-Paare ModifyDNRequest - Klient will den DN eines Eintrags im Verzeichnis ändern das heisst, er will ihn im Verzeichnisbaum verschieben Dazu muss der alte und der neue DN angegeben werden, sowie ein Flag, das das Löschen des alten Eintrags veranlasst CompareRequest - Klient will einen Attributwert eines Eintrags mit einem gelieferten Wert vergleichen AbandonRequest - Klient will eine Operation abbrechen, die der Server in seinem Auftrag gerade ausführt Die Operation ist durch die Angabe der MessageID eindeutig referenziert ExtendedRequest - Erweiterung des LDAP-Protokolls ab Version 3, um nichtstandardisierte Anfragen und Antworten implementieren zu können, der Inhalt ist frei definierbar Der Server kann folgende Antworten (protocolops) liefern: BindResponse - Antwort auf einen BindRequest, success im Erfolgsfall SearchResultEntry - Server liefert eine Menge von Einträgen mit Attributen, die den Suchkriterien entsprechen 8

9 SearchResultReference - Die gewünschten Daten sind auf einem anderen Server zu erfragen, eine LDAP-URL wird zurück geliefert SearchResultDone - Nach der Auslieferung der Suchergebnisse wird im Erfolgsfall ein success gesendet, woraufhin die Verbindung beendet wird ModifyResponse - Antwort auf einen ModifyRequest, success im Erfolgsfall AddResponse - Antwort auf einen AddRequest, success im Erfolgsfall DeleteResponse - Antwort auf einen DeleteRequest, success im Erfolgsfall ModifyDNResponse - Antwort auf einen ModifyDNRequest, success im Erfolgsfall CompareResponse - Antwort auf einen CompareRequest, success im Erfolgsfall ExtendedResponse - Antwort auf einen ExtendedRequest, der Inhalt ist frei definierbar Um die Funktionsweise zu verdeutlichen, folgt jetzt ein repräsentativer Protokollablauf eines SearchRequests Dabei wird der Klient zur Vereinfachung C und der Server S genannt 1 C sendet an S einen BindRequest, mit dem er sich gegenüber ihm authentifiziert AuthType: simple MessageID=1 S antwortet mit einem BindResult mit einem LDAPResult ResultCode:success MessageID=1 C sendet an S einen SearchRequest BaseDN: o=meinefirma.org Scope: Subtree Filter: (cn=merzky) Attributes: * MessageID=2 S findet ein entsprechendes Ergebnis und sendet ein SearchResultEntry DN: cn=alexander, cn=merzky, ou=admin, o=meinefirma.org Attribute: objectclass, Value: organisationalperson Attribute: cn, Value: Alexander Attribute: sn, Value: Manager Attribute: telephonenumber, Value: 1234 MessageID=2 danach sendet S ein SearchResultDone ResultCode: Success MessageID=2 C sendet einen UnbindRequest MessageID=3 [RFC2251] Die Konfiguration des Servers wird im allgemeinen durch das File /etc/openldap/slapd.conf vorgenommen, während der Klient sein erforderliches Wissen entweder aus ldap.conf bezieht oder als Programmparameter übergeben bekommt. 1 C=Klient, S=Server 9

10 2.1.3 Das LDAP-Datenmodell Die Grundidee ist das Vorhandensein eines globalen Directory Information Tree (DIT), der, wie der Name schon sagt, als baumförmiges Verzeichnis strukturiert ist. Jeder Server, der Verzeichniseinträge in diesem weltweiten DIT bereitstellen will, braucht einen eindeutigen Einstiegspunkt, den sogenannten Suffix (Firmen-DN), also einen Pfad im globalen Verzeichnisbaum, der zur eigenen Organisation führt. Damit die Eindeutigkeit gewährleistet ist, muss ein solcher Suffix bei einer weltweiten Organisation registriert werden. Er stellt die Wurzel des lokalen, vom Server bereitgestellten, Naming Contexts dar. Ein LDAP Server kann aber auch eigenständig betrieben werden, muss in dem Falle also nicht in den globalen DIT eingehängt werden. Jeder Knoten und jedes Blatt im DIT stellt ein Objekt dar. Es besteht aus einem DN, der eindeutig seine Position im Baum beschreibt, sowie einer Menge von Atrribut-Werte-Paaren. Ein Attribut, das in jedem Objekt enthalten sein muss, ist die ObjectClass. Objekte werden im LDAP-Datenmodell über Schemata (entsprechen Datentypen) definiert, die die benötigten (MUST-) und möglichen (MAY-) Attribute festlegt. Eine ObjectClass definiert genau ein solches Schema. Beispielsweise benötigt die ObjectClass person die Attribute sn (Surname) und cn (common Name) und ermöglicht die Belegung der Attribute userpassword, telephonenumber, seealso und description. Ein Attributeschema legt unter anderem seinen Namen, eine Beschreibung und eine Syntax fest. Syntaxes werden ebenfalls über Schemata definiert, genauso wie MatchingRules, welche beim Vergleich mehrerer Attributwerte gleichen Typs angewandt werden. Jedes Schema besitzt eine eindeutige ObjectID (OID). Sie ist eine eindeutige ID in der sogenannten Management Information Base (MIB). Neben den Standard-LDAP-Schemata für Organisationsstrukturen und DIT- Management können auch eigene Schemata definiert werden, deren OIDs ebenfalls an zentraler Stelle zu registrieren sind. Um eine einheitliche Schnittstelle zur Datenmanipulation zu bieten, wird der Import (Eintrag von Daten) über sogenannten LDIF-Files (LDAP Data Interchange Format) vorgenommen. Dieses Datenformat ist genau definiert und spiegelt die Struktur des entstehenden Eintrags wieder. Die LDAP-Kliententools wie etwa ldapadd wandeln diese Daten in LDAP-Protokollwerte um und kontaktieren damit den Server, der sie zur Speicherung in sein internes Format umwandelt. Die Art der internen Datenspeicherung im Server kann durch die Wahl eines Backends bestimmt werden. OpenLDAP bietet zu diesem Zweck eine Vielzahl von Schnittstellen an, beispielsweise zur Unterbringung der Daten in einer BerkeleyDB (back-bdb) oder in einer SQL-Datenbank (backsql). Die Wahl des Backends wird ebenfalls im Konfigurationsfile vorgenommen und beeinflusst massgeblich die Such- und Änderungsperformance. Ein Server verwaltet allerdings nicht nur nutzerzugängliche Daten, sondern auch Einträge, die ausschliesslich zur Ausführung von Operationen nötig sind, sogenannte DSAOperation-Entries. Auch auf bestimmte Attribute von Nutzereinträgen kann nicht ohne weiteres zugegriffen werden, da auch sie von openldap nur zur Verwaltung genutzt werden, beispielsweise der EntryCSN (Change Sequence Number), der den Zeitpunkt der letzten Änderung dieses Eintrags angibt Einsatzszenarien Wie bereits erwähnt, werden Verzeichnisse grösstenteils zur Bereitstellung von Mitarbeiterinformationen genutzt. Es können gesamte Firmenstrukturen abgebildet werden, indem die einzelnen Abteilungen je einen Teilbaum belegen. Wenn beispielsweise eine Firma den Suffix o=meinefirma, c=de besitzt, können unter dem DN ou=management, o=meinefirma, c=de die Managementabteilung und unter ou=programming, o=meinefirma, c=de die Programmierer im Naming Context untergebracht werden. Es ist bei grossen Unternehmen auch möglich, in den einzelnen Abteilungen eigenständige LDAP- 10

11 Server zu betreiben, welche zusammen die gesamte Firma repräsentieren. Dabei werden die Anfragen an fremde LDAP-Server entsprechend weitergeleitet. Weiterhin vorstellbar ist der Betrieb mehrerer DSAs, die das selbe DIT-Fragment bereitstellen. Dieses Szenario kann verwendet werden, um die Ausfallsicherheit zu erhöhen oder die Antwortzeiten zu verkürzen. Allerdings fallen damit Probleme mit der Synchronisation der Server an, die in dieser Diplomarbeit behandelt werden sollen. Verzeichnisse können aber nicht nur zur reinen Informationsbeschaffung dienen, sondern werden auch zur Authentifizierung bei weiteren Diensten (z.b. IMAP, Linux Login) genutzt. 11

12 2.2 Replikation Einführung Unter Replikation versteht man die mehrfache Speicherung von Daten, aber auch das parallele Ausführen mehrerer gleicher Prozesse und das Vervielfältigen von Nachrichten, um Dienste zu dezentralisieren, und damit die Ausfallsicherheit und Fehlertoleranz zu erhöhen sowie im Falle der Datenreplikation die Netzlast und die Antwortzeiten zu verringern. In dieser Arbeit soll es hauptsächlich um Datenreplikation gehen. Dafür bietet es sich an, einen Verbund von Servern zu installieren, die den selben Datenbestand redundant speichern und jeweils vorrangig von Klienten in ihrer unmittelbaren Umgebung kontaktiert werden. Vorrangig deswegen, weil die Klienten im Sinne der Ausfallsicherheit bei Nichterreichbarkeit des lokalen Servers und bei Weiterleitungen auf einen anderen zurückgreifen sollen. Solange die redundant gespeicherten Inhalte nicht verändert werden, müssen die Server nicht miteinander kommunizieren. Es reicht, bei einem Ausfall oder einer Inbetriebnahme, den Datenbestand von einem laufenden Server oder einer Masterkopie manuell oder automatisch zu kopieren. Anders sieht es aus, wenn Klienten die Möglichkeit haben, die Daten zu manipulieren. Dazu zählen zum Beispiel das Ändern, Löschen, Hinzufügen oder auch die Umstrukturierung von Datensätzen. Da jeder Klient im Normalfall jeweils nur mit einem Server verbunden ist, hätte dieser nach Ausführung der vom Klienten gewünschten Änderungen nicht mehr den einheitlichen Dateninhalt der restlichen Server. Das heisst, der Datenbestand im Serververbund wäre inkonsistent. Wenn dann ein zweiter Klient seinen (einen anderen) Server nach den Informationen fragen würde, die im ersten Server geändert wurden, so könnte dieser nur seinen veralteten Wissenstand liefern, was natürlich nicht gewünscht war. Um dieses Problem zu beheben, muss ein Mechanismus vorhanden sein, der einen einheitlichen und konsistenten Inhalt aller Server garantiert. Es wäre denkbar, dass jeder Klient, der eine Änderung vornimmt, selbige an jeden Server im Verbund schickt, was aber die Kenntnis und die Erreichbarkeit aller Server voraussetzt. Ausserdem sollte die Vervielfältigung der Daten eher Aufgabe des Servers sein, um die Klientenrechner zu entlasten und die Struktur der Server für den Klienten transparent zu gestalten. Eine weitere Idee ist das Vorhandensein eines Agenten, an den jeder Klient seine Updates schickt und der seinerseits jeden Server damit beliefert. Die gängigste Lösung ist, die Server untereinander abzugleichen, oder fachlich ausgedrückt, sie zu synchronisieren. Dabei nimmt der zuständige Server den Änderungswunsch entgegen und sorgt dafür, dass er an die restlichen Verbundsteilnehmer weitergeleitet wird. Bei der Replikation kann es vorkommen, dass einige der Server durch Software- und Hardwarefehler, Überlastungssituationen, menschliche Fehler oder durch Stromausfälle vorübergehend ausfallen oder zumindest nicht erreichbar sind. Um eine hohe Verfügbarkeit des Serververbundes zu gewährleisten, sollten derartige Fehler erkannt, toleriert oder isoliert/maskiert und im Idealfall sogar repariert und die Server neu gestartet werden. Zu diesen Mechanismen gehört auch, dass die Servicebereiche von ausgefallenen Systemen von anderen Servern übernommen werden, ohne dass der Klient etwas davon mitbekommt (Transparenz). Bei der Erkennung des Fehlverhaltens ist zwischen netzwerkbedingter Nichterreichbarkeit und echten Hardwarefehlern zu unterscheiden. Nach der Wiederinbetriebnahme, die sowohl automatisch als auch manuell vorgenommen werden kann, müssen die ausgefallenen Systeme wieder mit den betriebsbereiten Servern synchronisiert werden. [REPTEC] Ein Performancevorteil durch Replikation kann aber nur erreicht werden, wenn die Anzahl der Leseoperationen die der Schreiboperationen übersteigt. Der Grund liegt im grossen Schreibaufwand, der um ein vielfaches höher ist als bei einem einzelnen System, da mit jeder Writeoperation ein komplexer Updatemechanismus ausgelöst wird. Der Aufwand der Verteilung kann zwar 12

13 auf Kosten der Konsistenz reduziert werden, indem weniger Server mit den Updates versorgt werden, dadurch leidet aber wiederum die Leseperformance, weil nicht alle Server auf dem aktuellen Stand sind. Die nicht versorgten Server müssen dann die Anfragen weiterleiten oder liefern eben eine veraltete Version der Daten. Die Performance von Leseoperationen steigt durch die gegebenenfalls geringere Entfernung zwischen Klient und Server, sowie durch das parallele Verarbeiten von mehreren Readrequests an verschiedenen Servern. Die Ausfallsicherheit wird jedoch immer durch Replikation erhöht. Für die folgenden Erklärungen ist eine kurze Einführung in die Terminologie erforderlich: Replikation: Der Prozess, Datenbestände in mehreren Orten zu duplizieren und diese periodisch zu synchronisieren Synchronisation: Der Prozess, zu einem früheren Zeitpunkt bereits konsistente Datenbestände erneut abzugleichen Masterserver (Provider) : Server, der definitiv den Datenbestand hält, mit dem sich alle anderen synchronisieren müssen; auf ihn kann direkt geschrieben werden; authoritative Datenquelle Replikaserver (Consumer, Slave, Replikaserver) : Server, der sich mit dem Masterserver synchronisieren muss; auf ihn sollte von Klientenseite aus nur lesend zugegriffen werden können Full Reload (initial content load): Die gesamte zu replizierende Menge wird im Ganzen übertragen Inkrementelles Update: Es werden nur Daten übertragen, die sich seit der letzten Synchronisation verändert haben Es gibt mehrere mögliche Konstellationen der Aufgabenverteilung, die in den folgenden Abschnitten näher beleuchtet werden: Jeder Server nimmt die Änderungen zuerst lokal vor und verteilt sie dann als authoritative Datenquelle an die anderen (Multi-Master-Replikation) Es gibt nur einen authoritativen Server, der Änderungen verbreiten darf. Daher leitet jeder der anderen Replikaserver die Updaterequests an ihn weiter und empfängt dann ein Update von ihm, mit dem er letztlich seinen Datenbestand auffrischt. (Single-Master-Replikation) Jeder Klient ist so konfiguriert, dass er Änderungswünsche immer an ein und den selben Server schickt, der dann auch ihren lokalen Server updatet (Single-Master-Replikation) Es gibt zwei oder mehr Masterserver, von denen aber immer nur einer Updaterequests verarbeiten darf. Die restlichen Failover-Server synchronisieren sich mitb dem aktuellen Master solange er aktiv ist. Wenn dieser durch irgendeinen Grund nicht mehr erreichbar ist, übernimmt einer der anderen seine Rolle. Auf die übrigen Replikaserver kann nur lesend zugegriffen werden Multi-Master-Replikation Diese Konstellation scheint auf den ersten Blick die vorteilhafteste zu sein, weil die Updates den kürzesten Weg zurücklegen müssen (vom Klient zu seinem Server und von da aus zu allen 13

14 anderen Servern) und beim Ausfall eines Servers zumindest die nicht mit ihm verbundenen Klienten weiterhin updaten und lesen können. Nun stelle man sich aber folgendes Szenario vor: 2 Abbildung 1: gleichzeitige Updates C1 will an O1 eine Änderung U1 vornehmen, schickt die entsprechende Anfrage also an S1. C2 möchte ebenfalls zur gleichen Zeit O1 ändern und schickt seinen Request (U2) an S3. Da sowohl S1 als auch S3 das lokale Update entgegengenommen haben, bevor das der anderen Partei sie erreicht hat, kann keiner der beiden Server entscheiden, welche Version nun die entgültige sein soll. Mathematisch ausgedrückt: 3 S1: t[u1] < t[u2] S3: t[u2] < t[u1] S1: tdiff1 = t[u2] - t[u1] > 0 S3: tdiff3 = t[u1] - t[u2] > 0 Ohne zusätzliche Massnahmen sind U1 und U2 in einem solchen Fall nicht eindeutig serialisierbar. Nun könnte man sagen, dass dieser Fall relativ unwahrscheinlich ist. Dabei muss aber in Betracht gezogen werden, dass tdiff durch Netzwerklatenzen, Verarbeitungszeiten sowie eventuelle Updateintervalle (die Synchronisation wird z.b. nur alle 5 min durchgeführt) erhöht wird. 2 C=Klient, S=Server, O=Objekt, U=Update 3 tdiff = Zeitdifferenz zwischen lokalem und Replikaupdate 14

15 Für dieses Problem sind verschiedene Lösungsvarianten möglich: Der Klient schickt einen Zeitstempel beim Updatewunsch mit. Somit wissen die Server dann, welches Update zuerst in Auftrag gegeben wurde. Diese Lösung setzt den Einsatz eines Zeitsynchronisationsprotokolls voraus. [MMREPROP] Die gleiche Idee kann auch angewandt werden, wenn der Server beim Eingang eines Updaterequests einen Zeitstempel hinzufügt, bevor er es verbreitet. Um überhaupt eine Multi-Master-Umgebung in Betrieb nehmen zu können, müssen alle Server laut [LDAPMMRP] Änderungen aufzeichnen (loggen) und an die anderen übertragen können sowie einen Konflikterkennungs- und lösungsmechanismus beinhalten. Ausserdem müssen im LDAP-Umfeld einzelne Objekte ausser ihrem DN eine wirklich eindeutige ID besitzen. Denn wenn der DN bei einem Update verändert wird, kann mit ihm kein eindeutiges Objekt mehr referenziert werden. Um die Anzahl der Änderungen pro Objekt aufzeichnen zu können, muss auch eine Versionsnummer gespeichert werden, genau wie für jedes einzelne Attribut in jedem Objekt. All diese Zusatzinformationen müssen ebenfalls im Verzeichnis untergebracht werden Single-Master-Replikation Hierbei gibt es einen Server, der die Masterkopie des zu replizierenden Verzeichnisteils bereitstellt. Nur er darf Schreibanforderungen der Klienten ausführen und an alle Replikaserver weiterleiten. Die Replikaserver werden auf Klientenseite entweder nur zum lesen genutzt (rechtes Bild), oder sie leitet die an sie gerichteten Updaterequests an den Masterserver weiter, weil sie nicht authorisiert sind, die Requests zu verarbeiten (linkes Bild). In beiden Fällen werden danach die Replikaserver vom Master aus aktualisiert C2 schickt einen Updaterequest an R1 1. C2 schickt seinen Updaterequest direkt an M 2. R1 forwardet den Request zu M 2. M updatet sich, verteilt die Updates an R1, R2 3. M updatet sich und verteilt Updates an R1,R2 3. R1 und R2 updaten sich 4. R1 und R2 updaten sich Abbildung 2: Single-Master-Replikation Das Multi-Master-Problem mit gleichzeitigen Änderungsanforderungen ist hier quasi ausgeschlossen, da der Server netzwerk- und prozessorbedingt alle ankommenden Queries sequentiell abarbeitet. Eine Ausnahme bilden hier nur multi-homed Multiprozessorsysteme mit entsprechender 4 C=Klient, M=Masterserver, R=Replikaserver, U=Update 15

16 Serversoftware. Der Umstand, dass sich Pakete durch unterschiedliche Netzwerklatenzen überholen können, sollte hier trotzdem nicht ausser Acht gelassen werden. Auch hier wäre es hilfreich, wenn der Klient den Request mit einem Zeitstempel versehen würde, um die Anfragereihenfolge rückverfolgbar zu machen. Das grösste Problem besteht aber darin, dass ein Ausfall des Masterservers alle Schreiboperationen unausführbar machen würde. Aber auch hierfür gibt es mehrere Lösungsansätze: Der Administrator kann einen bisher als Replikaserver genutzten Host zum Masterserver umfunktionieren Wenn die Replikaserver mitbekommen, dass ihr Master nicht mehr erreichbar ist, können sie selbstständig einen neuen wählen Die Failover-Konstellation Der letzte Punkt wird in abgewandelter Form beim Failover-Prinzip angewandt. Es gibt einen Masterserver, und mehrere Replikaserver, von denen einige als Masterkandidaten deklariert sind. Fällt nun der eigentliche Master aus, übernimmt sofort der erste Kandidat seine Rolle. Dieser sollte zu diesem Zeitpunkt auch die Bedingung an einen Masterserver erfüllen, nämlich eine authoritative Datenquelle zu sein, weil er ja bis dahin mit der bisherigen authoritativen Datenquelle synchronisiert wurde. Im Idealfall wäre jeder Replikaserver ein Failoverserver, sodass nur beim Ausfall aller Server keine Schreiboperationen (wie auch Leseoperationen) mehr möglich sein würden. 5 Das Problem bei Abbildung 3: Failover-Prinzip dieser Methode ist der Neustart eines in der Failover-Hieranrchie höher liegenden Servers. Nimmt dieser sofort wieder die Masterrolle ein, gehen die zwischenzeitlich vorgenommenen Änderungen verloren, wenn er seine Daten nicht vorher mit denen des bisherigen Masters abgleicht Weitere Aspekte Die Zusammenarbeit mehrerer Nutzer wird allgemein als Kollaboration bezeichnet. Diese Sichtweise kann auch auf die Replikation projiziert werden. Da jeder Nutzer (Klient) lesend und schreibend mit dem System kommunizieren kann, können sich die verschiedenen Nutzer so untereinander verständigen. Somit kann eine Replikationsumgebung auch als verteilter Informationskanal angesehen werden. Die Unterscheidung der zeitlichen Gebundenheit der Nutzer lassen sich 2 gegensätzliche Szenarien beschreiben: Die synchrone Kollaboration wird vor allem bei interaktiven Echtzeitsystemen eingesetzt, in denen Nutzer gemeinsam (verteilt) zur selben Zeit arbeiten, um ein gemeinsames Ziel zu erreichen 5 C=Klient, M=Masterserver, R=Replikaserver, F=Failoverserver 16

17 Die asynchrone Kollaboration verlangt kein gleichzeitiges Arbeiten aller Mitglieder, sondern bietet die Möglichkeit, zeitlich unabhängig Informationen zu liefern und zu benutzen, oder anders ausgedrückt, zu teilen Dass die Nutzer des Systems asynchron über Verzeichnisse kommunizieren, dürfte jedem klar sein. Hier stellt sich vielmehr die Frage, in welcher Weise die Server untereinander kommunizieren. Sie können entweder jede Änderung sofort (so schnell wie möglich), zu festgelegten Zeiten oder nur auf Anfrage verbreiten Nachteile Wie bereits teilweise erwähnt, hat die Replikation von Daten nicht nur Vorteile. Durch die mögliche parallele Verarbeitung von Writerequests können Inkonsistenzen auftreten, die unter Umständen schwer oder nicht eindeutig zu beheben sind. Der Vervielfältigungsvorgang selbst benötigt Systemressourcen (Rechnerlast, Netzwerklast) und kann die Write-Performance des zu replizierenden Dienstes sehr stark herabsetzen. Der Vorteil der Dezentralisierung kann hier zum Nachteil werden, wenn auftretende Fehler nicht mehr eindeutig lokalisierbar sind. Auch ist ein erhöhter Aufwand zu betreiben, um Sicherheitsrichtlinien einhalten zu können, weil durch die Kommunikationsschnittstelle zu den Replikaservern auch nicht authorisierte Quellen Datenänderungen veranlassen können. Bei der Auflösung von Inkonsistenzen kann es systembedingt zu Deadlocks kommen, besonders in Multi-Master-Umgebungen, bei denen Updates verschiedener Server über einen Zeitstempel zeitlich geordnet werden und mehrere Updates gleiche Zeitstempel haben oder die Server verschiedene Systemzeiten haben. 17

18 3 Anforderungen - Top-Down Entwurf In diesem Abschnitt werden konkrete Anforderungen an den zu erstellenden LDAP- Replikationsmechanismus erarbeitet. Dabei werden sowohl allgemeine als auch verzeichnis- und LDAP-spezifische Betrachtungen vorgenommen. Die Ergebnisse werden im nächsten Abschnitt mit bereits vorhandenen Lösungen abgeglichen. 3.1 Anforderungen Allgemeine Anforderungen Allgemeine Anforderungen an Software sollten hier grundsätzliche Beachtung finden. Zuerst wäre die Korrektheit zu nennen. Im Sinne des Softwareentwurfs bedeutet dies die Korrektheit des Entwurfs, aber auch die Konformität von Entwurf und Implementation. Ein weiterer Punkt ist die Zuverlässigkeit. Es sollte garantiert werden können, dass der Replikationsmechanismus unter allen Bedingungen, selbst bei Ausnahmesituationen, korrekt arbeitet, oder zumindest eigenständig zu einer korrekten Funktionsweise zurückfindet. Laut [REPTEC] bedeutet Zuverlässigkeit die längstmögliche Laufzeit einer Komponente im Replikationsverbund, die durch Fehlertoleranz und Recovery erreicht wird. Dabei soll jeder Request zu irgendeinem Zeitpunkt beantwortet werden. Sie wird durch den Wert MTTF (Mean Time to Failure) gemessen, der die mittlere Zeit zwischen 2 Fehlern angibt. Im Gegensatz dazu gibt die Verfügbarkeit an, ob ein System zu einen bestimmten Zeitpunkt Anfragen entgegennehmen kann (momentane Erreichbarkeit). Sie wird zeitunabhängig durch die Wahrscheinlichkeit A=MTTF/(MTTF+MTTR) angegeben, wobei MTTR die Mean Time to Repair angibt. Letzterer Punkt wird auch als Robustheit bezeichnet. Mit dem Einsatz von Netz- und Systemresourcen sollte die Software effizient umgehen, und sollte auch bei grossen Datenmengen eine ausreichende Performance bieten Die Nutzung der Resourcen sollte ebenso wie die Policies konfigurierbar sein. Die Installation und Nutzung des Replikationsmechanismus sollte nutzerfreundlich gestaltet werden, das heisst ohne Spezialwissen oder übermässige Administratorinteraktion bedienbar sein und sich nach gängigen Standards richten. Der Replikationszustand (Fortschritt, laufende Aktionen, Fehlerlogs...) sollten jederzeit einsehbar oder prüfbar sein, um dem Administrator ein rechtzeitiges Eingreifen zur Vermeidung möglicher Katastrophen zu ermöglichen, aber auch um Resourcenknappheiten oder Fehlkonfigurationen zu erkennen. Die Software sollte leicht wartbar und erweiterbar sein, das heisst zum Beispiel, einen modularen, übersichtlichen Quelltext mit Schnittstellen für zusätzliche Pakete anbieten. Die Einteilung in Quelltextmodule dient auch der Reparierbarkeit. Der Punkt Wiederverwendbarkeit hängt in diesem Fall stark mit der Portierbarkeit und der Interoperabilität zusammen. So sollte versucht werden, den Mechanismus vielen Implementationen von LDAP zugänglich zu machen oder zumindest mit minimalen Änderungen eine Anpassung zu ermöglichen. Damit die Software mit anderen LDAP-Servern zusammenarbeiten kann, muss sie ihnen natürlich in Form entsprechender Schnittstellen zugänglich gemacht werden. [ST1SCRIPT] Anforderungen an den Replikationsmechanismus Der Mechanismus soll für den openldap Server V3 implementiert werden. Um die Vorteile der Replikation voll ausnutzen zu können, sollten Lese- oder Suchzugriffe auf jedem teilnehmenden Server erlaubt sein, während die relativ seltenen Schreibzugriffe nur von einem oder einigen wenigen Servern auszuführen sind. Wünschenswert wäre es jedoch, dass jeder Server Schreiboperationen von Klienten annimmt und diese an die entsprechend authorisierten Server weiterleitet, sodass für die Nutzer eine grösstmögliche Transparenz entsteht. Natürlich müssen die Server untereinander synchronisiert werden. Hier treten allerdings 18

19 die ersten näher zu spezifizierenden Anforderungen auf. Da der Updatevorgang selbst eine gewisse Zeit in Anspruch nimmt und von Updatepolicies beeinflusst wird (Synchronisationsintervalle, Reihenfolge der Kontaktaufnahme...), muss eine Aussage gemacht werden, wie lange die Server untereinander inkonsistent sein dürfen (temporäre Inkonsistenzen), oder anders ausgedrückt, welche Form der Kollaboration (synchron/asynchron) zu verwenden ist. Diese Festlegungen sollten vom Nutzer konfigurierbar sein. Die Replikation selbst sollte zuverlässig arbeiten, genauer gesagt muss garantiert sein, dass jeder Server letztlich mit einem Master synchronisiert wird, sodass keine dauerhaften Inkonsistenzen oder Datenunterschiede auftreten können. Ausserdem muss gesichert sein, dass jeder Replikaserver kein Update mehrmals verarbeitet, was potentiell bei mehr als einem Master möglich wäre. Der Replikations- /Synchronisationsprozess sollte von verschiedenen Punkten aus angestossen werden können. Die Replikaserver sollten jederzeit den Wunsch äussern können, auf den aktuellen Stand gebracht zu werden während es dem Master auch möglich sein sollte, nach ausgeführten Änderungen die Replikas zu informieren. Es sollten sowohl inkrementelle Updates zu Synchronisation wie auch ein kompletter Datentransfer zur Initialisierung oder Fehlerbehebung möglich sein. Laut [LDAPREPREQ] sollte ein Master mehrere Replika gleichzeitig mit (den selben) Daten versorgen können, um Bandbreite zu sparen. Falls ein Server neu startet, zum Beispiel nach einem Absturz, solte er automatisch nach den korrekten Daten fragen und sie geliefert bekommen. Es sollten alle gängigen LDAP-Schemata unterstützt werden. Auch die Skalierbarkeit spielt hier eine grosse Rolle: die Replikation sollte sowohl in LAN- wie auch in WAN- oder Internet- Umgebungen noch ausreichende Performance bieten können. Ein automatische Skalierung ist jedoch nicht zwingend nötig, es reicht die Konfigurierbarkeit. [LDAPREPREQ] Im Rahmen dieser Diplomarbeit soll ein Replikationsmechanismus entwickelt werden, bei dem Schreiboperationen auch bei Ausfällen möglichst vieler Server (Master- oder Replikaserver) noch ausführbar sind. Die Server sollen untereinander die Verteilung der Daten regeln, bei Ausfällen ihre Struktur so anpassen, dass die volle Funktionsfähigkeit (sofern möglich) erhalten bleibt. Die Administratorinteraktionen im laufenden Bertieb sollten minimal sein. Der Replikationsvorgang inklusive aller auftretenden Fehler und Einstellungen sollte für den Endnutzer transparent (unsichtbar) sein. Die Replikation von Teilbäumen (DIT-Fragmenten) soll unterstützt werden. 3.2 Fazit Um die oben genannten Anforderungen erfüllen zu können, eignen sich das Multi-Master-Prinzip sowie die Failover Konstellation. Das Single-Master-System, das beim Ausfall des Masters jegliche Schreiboperationen unmöglich macht, ist hier nur mit den genannten Erweiterungen brauchbar. 19

20 4 Replikationsmodelle - Bottom-Up Entwurf In diesem Abschnitt werden bereits vorhandene und genutzte Replikations- und Synchronisationsmechanismen vorgestellt und auf ihre Anforderungskonformität geprüft. 4.1 Vorhandene LDAP-Replikationsmethoden LDAP-slurpd Die erste LDAP-Replikationsmethode, die im grösseren Stil angewandt wurde, nutzt den Einsatz des slurpd, der sozusagen als Verteiler von Updates dient und auf dem selben Server ausgeführt wie wie der Master slapd. Er überwacht ein Replikationslogfile, dass vom Master-slapd mit LDIF- Updateinformationen gefüllt wird, wenn er selbst Änderungen ausführt. Das File beinhaltet alle Replikaserver, die zu kontaktieren sind, und für jede Änderung einen Zeitstempel, den DN des modifizierten Eintrags und eine Menge von Änderungen im LDIF-Format. Falls vom slurpd eine Änderung festgestellt wird, kontaktiert er alle registrierten slapd-slaves und versorgt sie mit den Updates. Dabei läuft ein Updatevorgang folgendermassen ab: C2 sendet einen Updaterequest an S1 dieser liefert ein Referral (Überweisung) an M C2 sendet Updaterequest nun an M M führt das Update aus, schreibt es in den ReplicationLog und liefert C2 eine Erfolgsmeldung slurpd registriert die Änderung im Log und sendet die Anderungen via LDAP an S1 und S2 S1 und S2 führen die Änderungen aus und senden eine Erfolgsmeldung an slurpd Abbildung 4: slurpd-prinzip [SLAPDADMIN] Der Einsatzbereich des slurpd liegt hauptsächlich in Umgebungen, in denen Änderungen vorwiegend an zentraler Stelle vorgenommen werden, während die Menge der Leseanfragen nur durch eine Verteilung der Last über mehrere Repliakserver zu bewältigen ist. Durch das angewandte Singel-Master-Prinzip kann jedoch nicht sichergestellt werden, dass Schreibzugriffe jederzeit möglich sind. Mit der Definition von Verzeichnisdiensten, dass auf Directories relativ selten schreibend zugefgriffen wird, kann dieser Nachteil in Szenarien, bei denen die Aktualität der Daten nicht zwingend notwendig ist, akzeptiert werden. 20

21 In Umgebungen, die aufgrund von Sicherheitsrichtlinien oder anderweitigen Restriktionen die Replikation von Teilbäumen benötigen, ist der Einsatz slurpd-mechanismus nicht geeignet, da von ihm keine Teilbaumreplikation angeboten wird. Aufgrund des langjährigen Einsatzes ist der slurpd-replikationsmechanismus zuverlässig genug, um auch in kritischen Umgebungen eingesetzt werden zu können, vor allem wenn grossen Wert auf Konsistenz zwischen allen Servern gelegt wird. Durch die genannten Einschränkungen hinsichtlich Fehlertoleranz und Teilbaumreplikation ist dieser Mechanismus nicht mit den Anforderungen dieser Arbeit vereinbar ixsync Die Firma ]init[ bietet eine kommerzielle Lösung zur Synchronisation verschiedener Verzeichnisdienste unterschiedlicher Hersteller an. Sie basiert auf dem Multi-Master Prinzip. Um die verschiedenartigen DAP- (Directory Access Protocol-) Server unterstützen zu können, sind hier Objektklassen und Attributtypen frei konfigurierbar und abbildbar, wodurch unterschiedliche Objektklassen miteinander synchronisiert werden können. Besonders unterstützt werden hier PKI-Umgebungen (Public Key Infrastrukturen) mit der Replikation von Zerifikaten für Microsoft Exchange und Active Directory. Als Protokoll, auf dem die Synchronisation aufsetzt, wird hier LDAP verwendet, um neue Verzeichnisdienste durch Definieren von Basis-Templates einfach einbinden zu können, ohne am Server selbst Änderungen vornehmen zu müssen. Da es sich bei dieser Möglichkeit um eine kommerzielle Lösung handelt und aufgrund dessen keine näheren Angaben zur Funktionsweise gemacht wurden, kann hier nur die obige Beschreibung als Ansatz für die Einsatzszenarien angeführt werden. [IXSYNC] LDAP Sync-Operation Im letzten Jahr wurde durch eine Kooperation von openldap und IBM ein Internet-Draft herausgegeben, das einen weiteren LDAP-Synchronisationsmechanismus vorstellt. Er nutzt normale LDAP Requests und Responses, um eine Single-Master-Replikationsumgebung zu schaffen. Ursprünglich ist er dazu gedacht, dass ein Klient einen Teil des DITs lokal beherbergt und synchron hält. Laut Draft kann der Klient aber auch ein Slave-/Replikaserver sein, sodass sich der Mechanismus auch zur Server-Server-Synchronisation eignet. Die Grundlage bildet eine erweiterte LDAP-Search Anfrage, die die üblichen Argumente BaseObject, Scope, DerefAliases, sizelimit, timelimit, typesonly, filter und attributes enthält. Zusätzlich enthält dieser Request einen LDAP-Control namens Sync Request Control, der die Nutzung dieses Mechanismus anzeigt. Auch der Server nutzt bei seinen Responses zusätzliche Controls namens Sync State Control und Sync Done Control, um Synchronisationszustand und -daten zu liefern, verhält sich aber sonst wie bei der Beantwortung regulärer Anfragen. Die Idee dabei ist, dass der Klient anfangs den kompletten Kontext verlangt und im Anschluss daran aktiv oder passiv mit den Änderungen versorgt wird. Der Modus, in dem der Klient aktiv agiert, das heisst regelmässig nach Änderungen fragt, nennt sich RefreshOnly Mode, weil jede Client-Server-Verbindung nur zum Abgleich (Refresh) mit der aktuellen Server-Datenbasis dient. Der Passive Modus heisst RefreshAndPersist Mode. Hier trennt der Server die Verbindung nach dem initial content load nicht, sondern versorgt den Klienten über diese Session automatisch mit neuen Updates. Damit sich der Master nicht den Zustand jedes Slave merken muss, sendet er mit jedem Update ein Cookie an den Klienten, das den aktuellen Datenzustand repräsentiert und vom Klient im RefreshOnly Mode bei jedem Request mitgeschickt wird. Dieses Cookie besteht aus einem ContextCSN (Zeitstempel des letzten Updates am Master) und der RID (eindeutige 21

22 ID des Masters). Wird nun der Master von einem LDAP-Klient geupdatet, aktualisiert er seinen ContextCSN. Der Slave schickt beim nächsten sync-request sein (veraltetes) Cookie mit, woraufhin der Master die Differenz erkennt und ihn mit mit den Updates versorgt, die zwischen diesen beiden Timestamps vorgenommen wurden. Um herauszufinden, welche Einträge neuer sind als der Cookiewert, nutzt der Master deren EntryCSN-Attribute und liefert die Einträge, bei denen der EntryCSN grösser sind als der Cookie-Timestamp. Schliesslich schickt der Master noch den aktuellen Cookiewert. Im RefreshAndPersist-Modus verwaltet der Master intern die Cookiewerte der Slaves, schickt aber mit jedem Update den aktuellen Wert mit, sodass der Slave nach einem Absturz und dem darauf folgenden Neustart das seiner Aktualität entsprechende Cookie bei der nächsten Anfrage liefern kann. Im folgenden werden die zusätzlichen Controls noch einmal aufgelistet: SyncRequestControl mode (RefreshOnly RefreshAndPersist) cookie OPTIONAL reloadhint SyncStateControl state (add delete present modify) entryuuid (eindeutige ID eines Eintrags, DN wird bei Änderung uneindeutig) cookie OPTIONAL SyncDoneControl cookie OPTIONAL refreshdeletes BOOLEAN Für die vollständige Funktion ist noch eine LDAP IntermediateResponseMessage nötig: SyncInfoMessage newcookie (cookie) refreshdelete (cookie, refreshdone) refreshpresent (cookie, refreshdone) syncidset (cookie, refreshdeletes, syncuuids) Letztlich ist noch ein LDAP ResultCode definiert: e-syncrefreshrequired Die Synchronisation im Modus RefreshOnly läuft folgenderweise ab: 6 Initial Content Poll: 1. C sendet einen normalen LDAP-SearchRequest (BaseObject, scope, derefaliases=neverderefaliases, sizelimit, timelimit, typesonly, filter, attributes) inklusive eines SRC (mode=refreshonly, keinem cookie und reloadhint=false) 2. S erkennt, dass kein Cookie mitgeliefert wurde und schliesst daraus, dass C einen kompletten Transfer des gewünschten Kontexts wünscht; S sendet mehrere LDAPResultEntry-Pakete (objectname, Attributes) inklusive eines SSC (state=add, 6 C=Klient, S=Server, SRC=SyncRequestControl, SSC=SyncStateControl, SDC=SyncDoneControl, SIM=SyncInfoMessage 22

23 entryuuid=uuid des Objekts, kein cookie), bis der Klient das gesamte DIT-Fragment erhalten hat. 3. S schickt eine LDAPSearchResultDone inklusive eines SDC (refreshdeletes=false, kein cookie) 4. Dann schickt er eine LDAPIntermediateResponseMessage [LDAPIRM] inklusive einer SIM (newcookie=aktueller Synchronisationszustand) Content Update Poll: 1. C sendet den selben LDAP-SearchRequest wie oben inklusive eines SRC (mode=refreshonly, cookie=letztes von S geliefertes cookie, reloadhint=false) 2. S erkennt cookie, schliesst daraus den Synchronisationszustand des Klienten; wenn alle Änderungen einzeln mehr Datenvolumen entsprechen als ein kompletter Reload, dann schickt er den LDAPResultCode e-syncrefreshrequired, was eine komplette Neuübertragung zur Folge hat; ansonsten schickt er mehrere LDAPResultEntry-Pakete (objectname, Attributes) inklusive eines SSC (state=add delete modify present, entryuuid=uuid des Objekts, newcookie OPTIONAL), bis das Klient-DIT-Fragment mit dem entsprechenden Server-DIT-Fragment übereinstimmt. Dabei versucht er, durch eine geschickte Wahl der Modifikationsart Bandbreite zu sparen: Bei add-sync s sind alle Attribute mit Werten belegt. Bei delete-/ present - Sync s sind Attribute ohne Werte, d.h. sie können mittels SIM s (syncuuids=uuids aller gelöschten/ presenten Objekte, refreshdeletes=true/false) zusammengefasst werden, um die Menge der zu übertragenden Daten zu verringern. 3. S schickt eine LDAPSearchResultDone inklusive eines SDC (refreshdeletes=true/false, newcookie) Die Synchronisation im Modus RefreshAndPersist läuft folgenderweise.ab: Der Initial Content Poll funktioniert wie oben beschrieben. Dieser wird aber nicht mittels LDAP- SearchResultDone beendet, sondern durch eine SIM, die den Eintritt in den Persist-Zustand anzeigt. Somit ist der Server in der Lage, weitere Pakete (die Updates) an C zu schicken, ohne dass dieser mittels LDAPSearchRequest danach fragen muss. Der komplette Reload des Kontexts kann durch C angestossen (reloadhint=true) oder von S veranlasst werden (result=esyncrefreshrequired) Sowohl der ContectCSN des Masters als auch die Cookies der Slaves werden im jeweils lokalen LDAP-Baum gespeichert. Zuständig dafür sind die Objektklassen SyncProviderSubentry und SyncConsumerSubentry, auf die von Nutzerseite aus nicht zugegriffen werden kann, da sie zu den DSAOperationEntries gehören. Der erzielte Einsatzbereich des sich noch im Beta-Stadium befindlichen sync-mechanismus liegt vorwiegend in Umgebungen, in denen Änderungen von verschiedenen Rechnern angestossen werden können. Ähnlich wie beim slurpd-prinzip ist durch den Single-Master-Mechanismus die Verfügbarkeit von Updates begrenzt. Der Umgang mit Ressourcen wie Bandbreite oder Prozessorleistung wurde jedoch durch die Optimierung der Datenübertragung und den Verzicht auf zusätzliche Module stark verbessert. Die Minimierung der übertragenen Daten ist in Umgebungen, in denen häufig Umstrukturierungen des Verzeichnisses vorgenommen werden, von besonderem Vorteil. Auch die Unterstützung der Teilbaumreplikation ist ein Fortschritt gegebüber dem slurpd-mmechanismus, der in bandbreitenbegrenzten Anbindungen oder in durch security policies beschränkten Umgebungen ausgenutzt werden kann. Aufgrund des derzeitigen Entwicklungsstadiums dieser Methode kann über die Zuverlässigkeit keine verbindliche Aussage gemacht werden; in durchgeführten Test erwies sich LDAPsync als stabil. Da dieser Algorithmus aber auf dem Single-Master-Prinzip beruht, ist es in der Form nicht mit 23

24 den Anforderungen vereinbar. Eine Erweiterung im Sinne eines automatisch gewählten Masters (je nach Verfügbarkeit) wäre eine Lösung dieses Problems. 24

25 4.2 Der UBIK-Algorithmus OpenAFS - UBIK UBIK beinhaltet einen ganz anderen Ansatz. Es beruht auf der Replikation der unterliegenden Datenbank. Der Serverpool besteht aus N Servern, von denen mehr als die Hälfte erreichbar sein muss (Q > N/2), um Lese- und Schreiboperationen ausführen zu können. Der Grund hierfür ist, dass unter diesen Q Servern zu jedem Zeitpunkt mindestens ein Server dabei ist, der bereits zu einem früheren Zeitpunkt Lese- und Schreiboperationen annehmen durfte und durch einen Datenabgleich jetzt die aktuelle Datenbasis bereitstellt. Die Menge der gerade erreichbaren Server, die durch die erfüllte Bedingung schreibberechtigt sind, wird als Quorum (Q) bezeichnet. Wenn mehr als N/2 Server online sind, wählen sie einen Koordinator, der als einziger Server Schreiboperationen ausführen darf. Die anderen sind nur zur Ausführung von Leseoperationen berechtigt. Die Zeit, in der ein Server der Koordinator ist, wird als Epoche (Regierungszeit) bezeichnet. Sobald der Koordinator (Synchronization Site, SS) gewählt wurde, vollzieht er eine Recovery- (Aktualisierungs-) Operation, um sicher zu stellen, dass er eine Up-To-Date Datenbasis besitzt. Falls zu einem Zeitpunkt weniger als Q Server erreichbar sind, endet die aktuelle Epoche und die Datenbasis ist bis zur nächsten Epoche nicht erreichbar. Nach einer Neuwahl bearbeitet der neue Koordinator die noch ausstehenden Requests. Die Aktualität der Daten wird durch eine DB-Versionsnummer beschrieben (ServerID + Epoche + Anzahl der Änderungen). Bei der Wahl sendet jeder Server regelmässige beacons (implizite VOTEFORME-Anfragen mit seiner DB-Version) aus, die entweder mit VOTE NO oder VOTE YES beantwortet werden. Falls der Server mindestens Q VOTE YES-Antworten bekommen hat, deklariert er sich als Synchronisation Site und sendet fortan beacons inclusive der restlichen Zeit bis zur Neuwahl (Expire), seiner Datenbankversion und der aktuellen Epoche, um seine Erreichbarkeit anzuzeigen und Stimmen für die Verlängerung seiner Regierungszeit zu sammeln. Leseoperationen können ausgeführt werden, wenn die letzte vom Koordinator empfangene beacon- Expiretime noch aussteht und wenn dessen mitgesendete DB-Version der eigenen entspricht. Schreiboperationen dürfen nur vom Koordinator ausgeführt werden, wenn dessen Regierungszeit noch nicht vorbei ist und werden durch einen Write-Request an jeden Slave weitergeleitet. Wenn weniger als Q Slaves auf diesen Request antworten, bricht der Koordinator die Transaktion ab und beendet seine Epoche. Ansonsten sendet er eine Prepare-Message an an alle erreichbaren Server. Diese nehmen den Updaterecord in ihren log auf und antworten dem Koordinator. Falls der Koordinator von allen Servern eine Antwort erhält, sendet er eine Unlock-Message, die alle Server zum Ausführen/Unlock des Updates auffordert. Falls der Koordinator von mindestens einem Server keine Antwort erhält, bricht er die Transaktion ab und beendet seine Epoche. Dieses Vorgehen wird als 2-Phase-Commit Protokoll bezeichnet und dient der atomaren Datenverteilung (Alles oder Nichts-Prinzip). Bevor der Koordinator überhaupt Schreiboperationen annehmen und Leseoperationen erlauben kann, muss er nach seiner Wahl ein Recovery ausführen. Dazu gehört die Eröffnung einer neuen Epoche, die Umfrage nach der neuesten DB-Version, mit der er sich darauffolgend abgleicht, die Deklaration seiner neuen Version als Null-Version und der Abgleich aller anderen Server mit dieser Version. Ein Recovery kann vom Koordinator auch zur Behebung von nicht auflösbaren Problemen durchgeführt werden. Dabei beenden alle anderen Server ihre ausstehenden Writes. Durch die nicht festgelegte Rollenverteilung kommunizieren die UBIK-Instanzen in einer P2Pähnlichen Weise, was zwar grundsätzlich die benötigte Bandbreite erhöht, aber zu einem toleranteren Umgang mit Serverausfällen führt. Der gesamte Algorithmus ist dafür ausgelegt, eine geringe Anzahl von Writes (max. 1/sec) aber eine mittlere bis hohe Anzahl von Read (10-100/sec) verarbeiten zu können. Dabei wird grosser Wert auf starke Konsistenz gelegt. Wenn dieser Algorithmus im Backend eines LDAP-Servers angewandt wird, ergeben sich aller- 25

26 dings einige Probleme: Die zugrundeliegende Datenbank (hier Berkeley DB) bildet zwar eine mögliche Grundlage der LDAP-Baumstruktur, diese ist aber nicht direkt ansprechbar, sodass die Replikation von Teilen des Naming Contexts nur unter grossem Aufwand und einer Erweiterung des Algorithmus möglich ist. Dazu müssten entsprechende Filter und Attributlisten implementiert werden, die bei jedem Replikationsvorgang zu beachten sind. [UBIKAFS] UBIK-Implementierung der Carnegie Mellon University Den gleichen Grundalgorithmus nutzt auch die Implementierung der CMUbik-Bibliothek, die jedoch fest an die BerkeleyDB gekoppelt ist. Eine BDB-ähnliche API erlaubt es, Datenbankoperationen so vorzunehmen, als gäbe es nur eine lokale BerkeleyDB. Der UBIK-Mechanismus verteilt jedoch - transparent für den Nutzer - die Daten an alle Server im Quorum. Die Aktualität wird hier durch eine Quorum- und eine Datenbankversion festgehalten: Bei jeder Neuwahl erhöht sich die Quorumversion um 1, während sich die Datenbankversion bei jedem Update erhöht, aber bei einer Neuwahl zurückgesetzt wird. Ein Configfile namens ubik.conf beinhaltet unter anderem eine Liste von Hosts, die die Menge aller potentiellen Quorummitglieder festlegt, also den Serverpool darstellt. Diese Liste muss bei jedem teilnehmenden Host gleich sein, weil das einzige Kriterium zur Wahl des Masters die Position in dieser Liste ist (vordere Einträge haben Priorität). Die Hosts kommunizieren untereinander über das UBIK-Protokoll, das aus Kommandos für den Wahlvorgang (VOTEFORME, VOTE YES, VOTE NO), zur Authentifiziereng (AUTH*), zur Übermittlung der Version (ASKVERSION, MYVER, VERIS), zur Quorumdeklaration (QUORUM WRITE, QUORUM NULL) und zur Synchronisation selbst (GIMME(Give Database), W(rite), FORWARD(Write), SWITCHDBS) besteht. Bekommt ein Host mehr als n/2 VOTE YES Stimmen, weil er unter den i Servern die niedrigste Hostlistenposition hat, deklariert er ein QUORUM NULL und fragt mittels ASKVERSION alle Hosts nach ihren Versionen. Vom Host mit der grössten Kombination aus Quorumversion, Databaseversion bezieht er mitteln GIMME die aktuelle (komplette) Datenbank. Anschliessend deklariert er ein QUORUM WRITE, woraufhin alle anderen Hosts die an sie gerichteten Writes an die gewählte Synchronization Site (SS) FORWARDen. Diese werden von SS in die Datenbank geschrieben und mit SWITCHDBS und W(riteoperationen) an die anderen Hosts verteilt. Ein die UBIK-API nutzendes Programm kann nur lesend und schreibend auf die Datenbank zugreifen, wenn sich die lokale UBIK-Instanz in einem Writequorum befindet. Der Hintergedanke für das Leseverbot ist, dass die lokale Instanz wegen eines Netzproblems ein existierendes Quorum nicht erreichen kann und deswegen veraltete Daten, die im Quorum aktueller sein können, liefern würde. Auch hier findet sich wieder das Problem, dass, selbst wenn openldap mit einem BDB-Backend arbeitet, eine Replikation von Teilbäumen nur unter grossem Aufwand implementierbar ist. Beide UBIK-Implementierungen setzen auf die Repliaktion der unterliegenden Datenbank. Sie arbeiten grundsätzlich mit dem selben Algorithmus, der jedoch nicht für den Einsatz als LDAP- Replikationsmechanismus konzipiert wurde. Die Zuverlässigkeit der AFS-Variante hat sich aufgrund des weltweiten Einsatzes gezeigt, während sich die CMUbik-Variante noch im Entwicklungsstadium befindet. Durch die anfängliche Übertragung des gesamten Datenbestandes beim Masterwechsel sind beide Varianten nicht besonders bandbreitenfreundlich, was bei grossen Datenmengen und langsamen Abbindungen zwangsweise zu starken Verzögerungen führt. Somit ist der Einsatz in WAN-Umgebungen bei häufigen Serverausfällen nicht zu empfehlen, was im AFS-Umfeld ohnehin nicht unbedingt vorgesehen ist. In LAN-Umgebungen, in denen ausreichend Bandbreite zur Verfügung steht, kann der Algorithmus hingegen seine Vorteile ausnutzen, die in der gesicherten Konsistenz und der Toleranz gegenüber Serverausfällen liegen. Da es sich hierbei 26

27 um keine spezifische Verzeichnisreplikation handelt, sondern vielmehr um einen Mechanismus zur Synchronisation von Datenbanken, wurde der Grundsatz, dass Schreibzugriffe eher selten stattfinden, nicht in Betracht gezogen. Daher ist der Algorithmus sowohl für die Entgegennahme von häufigen Änderungen als auch für der Verabeitung von grossen Update-Datenmengen optimiert. 4.3 Andere Modelle Bayou Xerox PARC s Bayou Projekt wurde entworfen, um die Zusammenarbeit zwischen Nutzern zu ermöglichen, die nicht dauerhaft über ein Netzwerk miteinander verbunden sind. Es beruht auf dem Multi-Master-Prinzip. Deswegen unterstützt Bayou schwache Konsistenz, was bedeutet, dass nicht zu jedem Zeitpunkt alle Server erreichbar und somit synchronisiert sein müssen. Es muss nur gewährleistet sein, dass in endlicher Zeit ein Abgleich zwischen allen Servern stattfindet (endliche Konsistenz). Der Synchronisationsprozess selbst findet immer nur zwischen 2 Servern statt (Anti-Entropie-Protokoll). Bei mobilen Geräten (Laptops...) wird der Vorteil dieses Systems voll ausgenutzt: Sie brauchen neben dem Klienten noch einen lokalen Bayou-Server, der sich beim Verbinden mit dem Netz mit den restlichen abgleicht. Bis dahin wird nur dieser lokale Server zum Lesen und Schreiben benutzt. Um den Abgleich zu ermöglichen, ist die Einteilung von Writes in mehrere Schritte nötig. Der Dependency Check prüft, ob ein konfliktloses Ausführen der gewünschten Schreiboperation möglich ist. Der Update Set beinhaltet die eigentlichen auszuführenden Operationen. Der dritte Schritt ist die Merge Procedure. Sie stellt ein Template bereit, das Regeln für die Auflösung von möglichen Konflikten beinhaltet. Jede Applikation, die diese Prozedur aufruft, kann sie mit eigenen Daten instanziieren und somit Konflikte aus eigenen Änderungen entfernen. Der Server bekommt also nur Informationen, welche Daten er ändern soll, welche Bedingungen dabei einzuhalten sind und wie Konflikte aufzulösen sind. Jede lokale Änderung wird in einem Write-Log zusammen mit einem Zeitstempel und dem Servernamen hinterlegt. Nach der lokalen Ausführung werden die gleichen Informationen zusätzlich in ein Undo-Log geschrieben. Wenn sich anschliessend zwei Server synchronisieren, und von der Gegenseite Updates mit einem früheren Zeitstempel empfangen werden, so müssen diese auch an der lokalen Datenbasis vorher ausgeführt werden. Dazu werden zuerst die lokalen Updates rückgangig gemacht, die zeitlich nach den empfangenen Updates liegen. Dann werden beide Updatesequenzen zeitlich geordnet und erneut ausgeführt. Jeder der beiden Server führt also letztlich die selbe Updatesequenz aus. Da Änderungen erst wirklich fest vorgenommen werden können, wenn alle Server synchronisiert sind (weil jeder Server Updates enthalten kann, die mit bereits ausgeführten Änderungen in Konflikt stehen), kann es bei manchen Anwendungen, die dauerhaft fixe Daten benötigen, zu Problemen kommen. Dazu bietet Bayou den Einsatz eines Primary Servers an, der diese tentativen (ausstehenden)writes zu stabilen Writes machen kann. Nach dieser Aktion werden fremde Updates, die zeitlich vor der nun stabilen Änderung liegen, danach ausgeführt, sodass die stabilen Änderungen auf jeden Fall nicht rückgängig gemacht werden. Die Implementation des Bayousystems besteht aus 2 Komponenten: Client Stub - Laufzeitbibliothek, die mit der eigentlichen Applikation verlinkt ist; besitzt Mechanismen zur Serverlokalisierung, Implementierung von Session Guarantees, unterstützt Secure Sessions, Read und Write Operationen and verschiedene Utilities. Server - der Datenbasisserver, beinhaltet Mechanismen zur Konfliktfindung und -auflösung, Server-Server-Kommunication und Database Management. Die Kommunikation zwischen Client und Server findet über ein plattformunabhängiges RPC- Package statt. 27

28 Die unterliegende Datenbank ist nicht festgelegt, muss aber folgende Eigenschaften vorweisen: Speichereffizientes Write logging Effizientes Undo/Redo von Schreiboperationen Möglichkeit zur Unterscheidung zwischen Committed Data (verbindlich) und Tentative Data (provisorisch) Support für Server-Server Antientropie [BAYOU][XEROXBAYOU] Der Einsatz dieser Implementierung ist vorwiegend in WAN-Umgebungen vorteilhaft, in denen dial-up-klienten sowohl eingene Änderungen publizieren als auch Informationen (Daten) anderer Endnutzer verarbeiten wollen. Der grosse Vorteil liegt hier in der Unterstützung von nicht dauerhaft aktiven Rechnern, deren Datenbanken trotzdem letztlich synchronisiert werden. Durch den Einsatz einer Variante der Multi-Master-Konstellation ist die Abwesenheit einzelner Server (Rechner) unproblematisch, was allerdings auch die erwähnte potentielle Gefahr eines deadlock s mit sich bringt. Häufige Änderungen an verschiedenen Hosts verursachen beim Abgleich zwischen ihnen durch die Nutzung des Anti-Entropie-Verfahrens eine hohe Rechen- und Bandbreitenlast, zumal eigene Änderungen ohne den Einsatz eines Primary Servers nie fest vorgenommen werden können, da sich jederzeit ein Host mit einem zurückliegenden Update synchronisieren und damit die eigenen Änderungen rückgängig machen kann kann Oracle Die Datenbank Oracle besitzt mehrere Replikationsmethoden. Die einfachste, Read-Only- Snapshot genannt, dupliziert die gewünschten Datenbanken / Tabellen auf einen anderen Server und updatet diese Kopien in bestimmten Zeitabständen. Falls der Master eine Zeit lang unerreichbar ist, wird der Snapshot als broken deklariert und ein manueller Refresh-Start ist nötig, um die Replikation fortzusetzen. Alternativ kann auch in einem solchen Fall eine komplette Neuübertragung getriggert werden, was bei grossen Datenbanken aber zu starker Netzlast führen kann. Diese Methode arbeitet also nach dem Single-Master-Prinzip. Eine weitere Möglichkeit ist die sogenannte Advanced Replication und arbeitet im Multi-Master- Modus, was auch hier unweigerlich zu Konflikten führen kann. Jedoch werden diese hier durch entsprechende Mechanismen aufgelöst oder durch manuelles Triggern der Synchronisation mit parallelem Verteilen der Transaktionen verhindert. [ORACLEREP] Oracle kann zwar als Backend für openldap (back-sql) verwendet werden, die Einschränkung auf ein bestimmtes Backend würde jedoch der Universalität widersprechen. Desweiteren sind auch hier Teilbäume nicht ohne weiteres in die SQL-Datenbank abbildbar. 4.4 Replikationsmedium Die Replikation kann auf verschiedenen Ebenen vorgenommen werden, die sich in ihrer Abstraktion der Daten unterscheiden. Das einfache Kopieren von Datenfiles ist wohl die einfachste Art des Abgleichs, wenngleich sie wenig effizient im Umgang mit Ressourcen ist. Eine Stufe höher wäre der Vergleich von Datenfiles mit anschliessendem Austausch der Unterschiede anzusiedeln (Stichwort diff ), was den Umgang mit der Bandbreite erheblich verbessert, aber dafür die Rechenleistung stark fordert. Die Strukturierung der Daten in Datensätze ist ein entscheidendes Merkmal von Datenbanken. Damit wird es in der nächsten Stufe möglich, beim Vergleich der Daten ihre Semantik (Bedeutung, Zusammenhang) zu nutzen, durch die Referenzierung von Datensätzen mittels IDs Bandbreite 28

29 zu sparen aber auch die Daten durch den optimierten Suchalgorithmus schneller finden und vergleichen zu können. Die Replikation der Daten auf Datenbankebene wird zum Beispiel beim UBIK-Algorithmus der CMU angewandt, der ausschliesslich mit der BerkeleyDB von Sleepycat zusammenarbeitet. LDAP kann verschiedene Backend-Datenbanken nutzen. Dazu zählen unter anderem BerkeleyDB, SQL oder gdbm. Wie im LDAP Datenmodell bereits beschrieben, werden LDAP-Daten als Entries verwaltet, die ihrerseits in die Backend-Datenbank abgebildet werden, also eine weitere Abstraktion hin zu LDAP erfahren. Die Replikation auf dieser Ebene bringt weitere Vorteile mit sich, da hier die Semantik der Daten durch Objekt- und Attributklassen genau bekannt ist. Das hat unter anderem zur Folge, dass Teile des Gesamtdatenbestandes exakt durch Merkmale wie Basisknoten oder Attributlisten beschrieben werden können. Somit ist auch die Replikation von Teilbäumen oder ausgewählten Attributen (Thema Datenschutz) möglich. Als Beispiel wäre hier die Replikation mittels slurpd oder LDAP-sync zu nennen. Am geeignetsten für unser Vorhaben ist also die Synchronisation auf LDAP-Ebene, zumal die openldap-implementation ja weitestgehend backendunabhängig entworfen wurde und ein Abgleich auf einer der unteren Abstraktionsebenen diese Unabhängigkeit stark eingrenzen würde. 4.5 Eignung der Möglichkeiten In diesem Abschnitt sollen mehrere der aufgeführten Replikationsarten auf ihre Eignung für die Server-Server-Synchronisation von openldap untersucht werden. Da wir im letzten Abschnitt festgestellt haben, dass die Synchronisation über das LDAP- Datenmodell die meisten Vorteile mit sich bringt und die Teilbaumreplikation nur durch diese Abstraktion ermöglicht wird, bleiben damit nur die bereits vorhandenen LDAP- Replikationsmechanismen LDAPsync und slurpd sowie ixsync zur Auswahl. Da es sich bei letzterem um eine kommerzielle Lösung handelt, fällt auch diese Möglichkeit für diese Arbeit weg. Die beiden LDAP-Replikationsmechanismen arbeiten beide über das Single- Master Prinzip, erfüllen damit also allein nicht die geforderten Bedingungen. Bezüglich des Replikationsmodells stellt meiner Meinung nach UBIK das Optimum dar, da hier die Vorteile sowohl des Single-Master-Modells (keine Konfliktentstehung bei gleichzeitigen Updates) als auch der Multi-Master-Modells (kein Single Point Of Failure) kombiniert werden. Der Nachteil hier ist allerdings, dass die bisherigen Implementationen bei der Wahl des Datenmodells recht unflexibel sind und nicht ohne weiteres auf eine Verwendung mit dem openldap Server portierbar sind. Zusammenfassend lässt sich sagen, dass eine Kombination des LDAP-Datenmodells und des UBIK-Replikationsmodells am besten geeignet ist, um die gewünschten Anforderungen zu erfüllen. 29

30 5 Untersuchung der Mechanismen und Modellentwurf 5.1 Bewertung und Wahl der Mechanismen LDAP-slurpd / LDAP-sync Aus der Beschreibung des slurpd-mechanismus ist zu erkennen, dass der dortige Master (M) noch einen weiteren Prozess benötigt (den slurpd) um die Slaves (Si) mit Updates zu versorgen. Fällt M, oder auch nur einer seiner beiden Komponenten, aus, ist der Replikationsvorgang solange unterbrochen, bis wieder beide Prozesse von M laufen. Um hier überhaupt einen Masterwechsel veranlassen zu können, müsste jeder Server in der Lage sein, einen eigenen slurpd zu starten, um mit dessen Hilfe alle anderen Server mit Updates versorgen zu können. Die Slaves allein sind ausserdem nicht in der Lage, einen Ausfall des Masters zu bemerken, da die Kommunikation nur von M ausgeht (Slaves listens for changes): meldet sich ein Master nicht mehr, weil er unerreichbar oder abgestürzt ist, gehen die Slaves davon aus, dass es nur keine neuen Updates gibt, die der Master liefern könnte. Es müsste also zusätzlich noch ein entsprechender Mechanismus erstellt werden, der Ausfälle erkennt. Der Sync-Master hingegen benötigt keine zusätzlichen Module, um Slaves mit Updates zu versorgen, die ja ihrerseits eine Klientenrolle gegenüber M einnehmen. Eher noch liegt hier der Mehraufwand, zumindest im RefreshOnly Mode, beim Slave, der in festgelegten Abständen einen sync-request an den Master schickt (Slave polls for changes). Dadurch ist er ohne weiteres in der Lage, Masterabstürze zu registrieren, wenn auch unter Umständen in nicht-akzeptabler (Request-Intervall-) Zeit. Im RefreshAndPersist Mode wird ähnlich wie beim slurpd der Slave aktiv mit Updates versorgt (Slave listens for changes), ohne dass M zusätzliche Prozesse benötigt. Im Gegensatz zum slurpd-mechanismus wird ein Masterausfall von den Slaves erkannt, da in diesem Fall ihre persistente Verbindung unterbrochen wird. Der sync-mechanismus bietet die Möglichkeit, mehrere Server zu kaskadieren. Bei dieser Variante übernimmt ein Server die Rolle des alleinigen Masters, während einige von seinen Slaves wiederum für andere Server die Masterrolle übernehmen, sodass Änderungen langsam bis zum letzten Slave durchsickern. Aber auch hier darf nur der oberste Master Schreiboperationen vornehmen, da ansonsten unauflösbare Inkonsistenzen auftreten können. Wenn jeder kaskadierte Master beliebige Änderungen vornehmen könnte, die der Obermaster nicht mitbekommt (weil ER ja der Master ist), würde er diese beim nächsten Update unweigerlich rückgangig machen, da er seinen Datenbestand ja für authoritativ hält. Aufgrund dieser Tatsachen ist auch der Sync-Mechanismus allein nicht in der Lage, die geforderten Bedingungen zu erfüllen. Es ist also festzuhalten, dass weder slurpd noch sync allein die geforderten Bedingungen erfüllen. Da aber LDAP-sync sowohl Polling als auch Listening beherrscht, die Replikation von Teilbäumen erlaubt und eine gleichmässigere Aufgabenverteilung zwischen Master und Slave implementiert (was einen Wechsel zwischen S und M vereinfacht) ziehe ich diesen Mechanismus vor. Es bedarf also noch zusätzlich folgender Erweiterungen, um die gewünschte Funktionalität zu erreichen: Die Slaves benötigen eine sichere Ausfallerkennung des Masters innerhalb einer festgelegten Zeit (unabhngig vom Replikationsintervall), um entsprechend reagieren zu können Wenn der Master ausfällt, muss ein anderer Server seine Rolle übernehmen (Wahl eines neuen Masters) Der gesuchte Mechanismus muss dabei folgende Bedingungen erfüllen: 30

31 Der neue Master muss die gleiche Aktualität haben wie der vorherige Master Der neue Master muss, genau wie sein Vorgänger, den Gesamtkontext aller Slaves enthalten, um alle mit entsprechenden Updates versorgen zu können; der Algorithmus muss also in der Lage sein, einen Server nur im Falle der Datenvollständigkeit als Master zuzulassen Der Abgleich der Datenbanken NACH der Wahl eines neuen Masters kann von LDAP-sync übernommen werden UBIK Der einzige Algorithmus, der einen Grossteil dieser o.g. Erweiterungen implementiert, ist UBIK: Auch hier stehen wieder 2 Varianten zur Auswahl: UBIK-Implementierung von openafs und die CMUbik-Bibliothek. Die Spezifikation besagt, dass der Master nach seiner Wahl alle Slaves nach ihren Versionen fragt und sich die höchste liefern lässt, bevor er seine Koordinatorrolle antritt. Anschliessend nimmt er Schreibaufträge an und leitet diese an die Slaves weiter. Fällt der Master aus oder kann der Master zu irgendeinem Zeitpunkt nicht mehr als die Hälfte der Server erreichen, findet eine Neuwahl statt bzw. verliert der Master sein Schreibrecht. In userem Fall soll aber LDAP sync die Synchronisation übernehmen, sodass der UBIK-Teil, der den Datenabgleich vornimmt, überflüssig wird. Wir benötigen nur den Voting-Mechanismus, der für jede Serverkonstellation einen eindeutigen Master findet. In genau diesem Punkt unterscheiden sich die beiden Implementierungen gravierend. CMUbik nutzt die Hostliste, die bei jedem Server gleich sein muss, um jedem Server eine quorum-weite eindeutige ID, nämlich seine Position in der Hostliste, zuzuweisen. Der Server mit der niedrigsten ID, der VOTEFORME-Anfragen aussendet, wird von anderen zum Master gewählt, natürlich mehr als n/2 VOTE YES Antworten vorausgesetzt. Die openafs-ubik-variante nutzt zusätzlich noch einige andere Kriterien, die zwar die Effizienz erhöhen, aber auch die Gefahr von VOTING-Deadlocks vergrössert. Dazu zählt zum Beispiel die Bevorzugung von früher gewählten Servern, die zwar einen Datenabgleich vor der Koordinatorrollenübernahme verhindern kann, wenn der vorherige Master erneut gewählt wird, aber in ungünstigen Fällen dazu führen kann, dass von mehreren Servern verschiedene Master bevorzugt werden und dadurch keine Entscheidung zustande kommt. Aus diesem Grund habe ich mich dafür entschieden, die einfachere aber auch sicherere Variante CMUbik zu verwenden. Im folgenden soll untersucht werden, inwieweit die CMUbik-Implementation unseren Anforderungen entspricht und wo Änderungen vorgenommen werden müssen. Erfüllte Forderungen: Ausfallerkennung wird durch das Ausbleiben von Lebenszeichen (beacons) erkannt Die Wahl eines neuen Masters wird durch den UBIK-voting Mechanismus implementiert Teilweise erfüllte Bedingungen: Die ursprüngliche Variante von UBIK garantiert die Aktualität des neuen Masters, da sich dieser nach abgeschlossenem Voting die neueste Datenbankversion beschafft. Da beim UBIK-Algorithmus mehr als die Hälfte aller Server verfügbar sein müssen, ist zu jedem Zeitpunkt garantiert, dass mindestens einer die neueste Version besitzt. Weil die Daten hier aber nicht auf der Datenbankebene (Schlüssel-Wert-Paare), sondern aus LDAP-Sicht (verzeichnisorientierte Datenverwaltung) zu behandeln sind (Stichwort Teilbaumreplikation), sollte sich das Attribut Aktualität auf den Inhalt des Verzeichnisses beziehen. 31

32 Nicht erfüllte Bedingungen: Die reine Datenreplikation, wie sie UBIK implementiert, benötigt kein Wissen über der Inhalt den Datenbank, weil hier die Datenbankfiles 1-zu-1 repliziert werden. Deswegen ist es UBIK auch nicht möglich, zu entscheiden, ob eine Kopie der Datenbank vollständig ist oder nicht (ob ein Server den Gesamtkontext oder nur einen Teilbaum verwaltet). Es fehlt also ein Mechanismus, der nur Server mit vollständigem Kontext als potentielle Master zulässt. Da die Aktualität der jeweiligen Daten mit dem bereits vorhandenen LDAP-ContextCSN ausreichend beschrieben wird und durch die Auswertung von slapd-parametern auch über die Mastertauglichkeit bezüglich der Datenvollständigkeit eine Aussage gemacht werden kann, sind durch die Kombination von UBIK und sync alle Anforderungen erfüllbar. 5.2 Modellentwurf Um LDAPsync und CMUbik kombinieren zu können, muss zuerst die Aufgabenverteilung zwischen beiden genau definiert werden Aufgabenverteilung Allgemeine Aufgaben UBIK: Wahl eine Masters wenn mehr als n/2 Server im Quorum sind Erkennen von Serverausfällen und Auflösen des Quorums bei weniger als n/2 Servern Mitteilen der Serverrolle und des neuen Masters an LDAP Mitteilen, wenn kein Quorum zustande gekommen ist Allgemeine Aufgaben LDAPsync: Starten von UBIK Wenn slapd zum Slave gewählt wurde soll er sich fortan mit neuem Master synchronisieren darf er keine Schreiboperationen mehr selbst annehmen, sondern muss sie an den Master weiterleiten Wenn slapd zum Master gewählt wurde darf er sich fortan mit keinem Server synchronisieren muss er an ihn gerichtete Schreiboperationen verarbeiten Wenn kein WriteQuorum existiert darf er sich fortan mit keinem Server synchronisieren Darf er weder Lese- noch Schreiboperationen annehmen 32

33 Abbildung 5: Grundmodell Anpassung der Aktualitätskriterien Wie zu erkennen ist, benötigen wir nur den Teil des UBIK-Algorithmus, der den Wahlmechanismus implementiert. Dieser funktioniert in der CMUbik-Variante folgendermassen: 1. Wenn Host A startet, versucht er sich mit allen Hosts in der Hostliste zu verbinden 2. Es antworten die Hosts X=Host1..Hostn aus der Hostliste, die zu diesem Zeitpunkt laufen 3. Die Hosts Xi nehmen die Verbindung von Host A an und bestimmen seine Hostlist-Position (ID) 4. Nun sind die Hosts Y = X+A miteinander verbunden 5. Wenn Host Yi unter allen die niedrigste ID hat, prüft dieser, ob mehr als n/2 Hosts mit ihm verbunden sind 6. Ist dies der Fall, deklariert er ein Null-Quorum und fragt alle Server nach ihrer Quorumund Datenbankversion sowie nach einer Stimme für das NullQuorum 7. Bekommt er daraufhin mehr als Y / 2 Stimmen, bezieht er die komplette Datenbank von dem Host mit der höchsten Quorum- und zweitrangig höchsten Datenbankversion 8. Ist er damit fertig, übernimmt er die Rolle der Synchronisation Site (Koordinatorrolle) im neuen Write-Quorum 9. Alle anderen Hosts synchronisieren ihre Daten ab jetzt inkrementell mit der Synchronisation Site Bis zu Punkt 6 könnte diese Vorgehensweise ohne Änderungen übernommen werden. Schritt 7 scheint aber für grosse Datenbanken (LDAP-Verzeichnisse) relativ ungeeignet, vor allem bei Szenarien, die die Synchronisation über WAN-Umgebungen verlangen. Auch der zweifache Wechsel zwischem Provider- und Consumerrolle, einmal vor dem Abgleich der neuen SyncSite mit der aktuellsten Datenbank und zum zweiten vor dem Einnehmen der SyncSite-Rolle, erscheint recht umständlich und im Zusammenhang mit openldap wenig geeignet. Es wäre sinnvoll, die Datenbankversion in der Datenbank selbst zu speichern, um nach einem eventuellen Absturz nur die Änderungen seit dem Absturz aktualisieren zu müssen. Sie sollte 33

34 unabhängig davon, ob der Server vor dem Absturz Master oder Slave war, seine Aktualität der Daten wiederspiegeln. OpenLDAP benutzt zu diesem Zweck ein Attribut namens ContextCSN, dass einen Zeitwert der Form entspricht YYYYMMDDhhmmss also :41:07 speichert. Es ist in einem DSAOperation-Entry der Klasse SyncProviderSubentry untergebracht, der seinerseits ein direktes Kind des BaseDN ist und selbst den DN cn=ldapsync,< BaseDN > hat. Dieser Entry existiert bei jedem Server der zu irgendeinem Zeitpunkt einmal Master in einer sync-konstellation war und ist der Maximalwert aller EntryCSN s im Kontext (bereitgestellten LDAP-Baum) des Servers. Ein EntryCSN ist ein Attribut, das in jedem Entry existiert und den Timestamp der Erstellung des Entry s angibt. Der ContextCSN wird in der sync-umgebung folgendermassen genutzt: 1. Jeder Server (Master und Slave) muss eine eindeutige sync-id rid besitzen 2. Wenn sich ein Slave S das erste Mal mit dem Master M synchronisieren will, stellt er eine entsprechende Suchanfrage an ihn 3. M erkennt die erstmalige Anfrage am Fehlen eines Cookies bei der Anfrage 4. M versorgt S mit dem kompletten Kontext (grosse Datenmengen!!!) und liefert anschliessend seinen ContextCSN in Form eines Cookies der Form csn=<master-contextcsn>,rid=<eigene rid>,sid=<eigene sid> 5. S speichert dieses Cookie als Kind des BaseDN S unter dem DN cn=syncrepl<eigene rid>,<basedn> also zum Beispiel unter cn=syncrepl2, o=university Of Michigan, c=us Diese ebenfalls operationalen Entries werden SyncConsumerSubentries genannt. 6. Wenn sich S erneut mit M synchronisieren will, zum Beispiel weil es per Aktualisierungsintervall wieder so weit ist oder S neu gestartet wird, sendet er nun bei jedem sync-request an M dieses Cookie mit. Die Verwaltung der <rid> s dient dem Master im RefreshAndPersist- Modus zur Unterscheidung der Versionen verschiedener Slaves; im RefreshOnly-Modus wird die <rid> ohnehin bei jedem Request mitgeschickt. 7. M erkennt dieses Cookie, sucht nur diejenigen Entries aus seinem Kontext heraus, deren Entry-CSN s grösser als der CookieCSN sind und versorgt S nur mit diesen Änderungen 8. Anschliessend sendet er ein neu generiertes Cookie mit dem aktuellen ContextCSN an S 9. S nimmt die Änderungen vor und überschreibt den entsprechenden SyncConsumerSubentry mit dem empfangenen Cookie wiederholen sich Die Aktualität der Datenbank kann bei M also durch seinen ContextCSN ausgedrückt werden, während sie beim Slave im SyncConsumerSubentry gespeichert wird. Man beachte, dass beim Slave der SyncConsumerSubentry den Zeitpunkt der Aktualisierung am Master angibt und nicht den Zeitpunkt, zu dem S die Updates vornimmt. Ansonsten hätte der Slave eine neuere Version, was bei späteren Betrachtungen zu Problemen führen würde. Wir suchen aber eine Version, die sowohl bei Master als auch bei Slaves bestimmt werden kann, also unabhängig von der aktuellen Serverrolle ist. 34

35 Wenn der Server zuletzt Master war, ergibt sich: 7 V = ContextCSN. Wenn der Server zuletzt Slave war, ergibt sich V = CSN(SyncConsumerSubentry). Da bei einem Masterausfall mittles UBIK ein neuer Server zum Master gewählt werden kann und somit jeder Server sowohl einen SyncProviderSubentry (PSE) als auch einen SyncConsumerSubentry (CSE) haben kann, ergibt sich für die Version folgende Gesamtformel: V = MAX(PSE,CSE). Da dieser Wert, umgewandelt in einen Timestamp (type time t), die echte Aktualität angibt und nicht, wie die DBVersion beim ursprünglichen UBIK-Algorithmus, relativ zu anderen Servern ist, kann damit auch die Quorum-Version wegfallen. Allerdings setzt das die genaue Zeitsynchronisation zwischen allen Servern voraus (was aber für die Auswertung der UBIK Quorum-Timeout-Zeit sowieso Bedingung ist). 7 V=Datenbankversion eines Servers 35

36 5.2.3 Anpassung des VOTING-Mechanismus Wie wir bereits gesehen haben, bringt der Voting Mechanismus von UBIK einige unvorteilhafte Effekte mit sich. Einen Nachteil, die Komplettübertragung der Daten vom Server mit der maximalen Version SmaxDB zum neuen Master MminID, haben wir mit der neuen Versionierung bereits ausgeschaltet, denn MminID müsste sich nur noch die Updates beschaffen, deren EntryCSN s zeitlich zwischen seiner Version und der Version von SmaxDB liegen. Der Nachteil, dass MminID zuerst in den Slave-Modus wechseln muss, um seine Daten zu aktualisieren, um danach in den Master-Mode zu gelangen, während SmaxDB zuerst im Mastermode seine Daten liefert, um danach im Slavemode seine entgültige Rolle einzunehmen, lässt sich auch umgehen. Es wäre doch sinnvoll, wenn nicht der Server mit der kleinsten Hostlist-ID zum Master wird, sondern derjenige, der beim Votingvorgang ohnehin die grösste Version hat. Falls, was der Normalfall sein sollte, mehrere Server diese maximale Version haben, sollte dann die Hostlistenposition als zweite Bedingung genutzt werden, um einen eindeutigen Master zu bestimmen. Daraus ergibt sich folgender Algorithmus: int lowest_host_with_biggest_version() maxdb = -1; hlpos = -1; for all Hosts i in Hostlist if (dbver (Host i) > maxdb) maxdb=dbver (Host i); hlpos = i; return(hlpos); Den Server, der durch diese Funktion zurückgegeben wird, nennen wir SmaxDBminPos dieser Algorithmus funktioniert, müssen einige Bedingungen eingehalten werden: Damit Jeder Server muss vor dem Voting die DBVersion von jedem anderen Server wissen, der läuft (diese wird beim UBIK-Algorithmus als Host-Attribut dbver in der Hostliste gespeichert) Das gilt auch, wenn ein neuer Server in das Quorum eintritt oder das Quorum verlässt, denn die bereits / noch vorhandenen Server müssen in einer eventuell folgenden Neuwahl mit ihrer aktuellen Version berücksichtigt werden. Wenn ein Server nicht mehr erreichbar ist (von ihm seit einer bestimmten Zeit kein UBIK- Kommando mehr empfangen wurde), muss dessen dbver in der Hostliste jedes Servers zurückgesetzt werden, damit er nicht mehr als Master kandidieren kann. (Da während eines WriteQuorums jeder Slave Si nur mit dem Master M kommuniziert, werden in Si die Datenbankversionen aller Slaves ausser der eigenen zurückgesetzt. Nur M kommuniziert mit allen Si s und kennt daher alle Slaveversionen, die ihrerseits auch M s Version kennen.) Damit dieser Algorithmus zum gewünschten Ziel führt, müssen weiterhin folgende Votingregeln eingehalten werden:: Ein Server sollte nur VOTEFORME-Messages broadcasten, wenn seine eigene ID bei lowest host with biggest version() zurückgegeben wird (gilt nur im VOTING State, dazu gleich mehr) Ein Server darf nur mit VOTE YES auf diesen Request antworten, wenn lowest host with biggest version() die ID des fragenden Hosts zurückgibt (gilt ebenfalls nur im VOTING State) 36

37 Es ergibt sich jetzt die Frage, woher jeder Server die Datenbankversionen der anderen laufenden Server bekommt. Beim ursprünglichen UBIK-Algorithmus wurde erst nach QuorumVersion,DBVersion gefragt, nachdem der Master bereits feststand, also der Voting- Vorgang abgeschlossen war. Hier muss die Datenbankversion eines jeden Servers vor jeder Neuwahl jedem anderen Server bekannt sein. Dabei sind 6 Fälle zu unterscheiden: 1. Ein erster Server aus der Hostliste startet > keine Versionen werden erfragt 2. Ein bereits laufender Server nimmt eine Verbindung entgegen, ist aber in keinem Writequorum > er fragt den verbindenden Server nach seiner Version (die Versionen der bereits verbundenen Server hat er schon erfragt) 3. Ein bereits laufender Server nimmt eine Verbindung entgegen und ist bereits in einem Writequorum > er fragt alle Server nach ihren Versionen (da sie sich während des Writequorums geändert haben könnten) 4. Ein Server versucht beim Start eine Verbindung zu allen Servern aus der Hostliste aufzubauen > er bekommt wegen (2/3) ein CMD ASKVERSION von jedem Server, er antwortet darauf und sendet seinerseits ebenfalls ein CMD ASKVERSION an jeden dieser Server 5. Ein Server, der Master in einem Writequorum ist, stürzt ab > Die Slaves bemerken das am Ausbleiben der Quorumerneuerung und fragen daraufhin jeden Host in der Hostliste nach seiner Version 6. Ein Server, der Slave in einem Writequorum ist, stürzt ab > Der Master erkennt dies an einem Quorum Timeout Es könnte während des letzten Write Quorums ein Server N hinzugekommen sein, dessen Hostlistenposition niedriger ist als die des derzeitigen Masters O ist und der seine Datenbankversion auf den aktuellen Stand gebracht hat, sodass er (N) jetzt Master werden müsste. Da aber die anderen Server seine aktualisierte Version nicht kennen, weil, wie bereits beschrieben, die Slaves nur die DBVersion des Masters kennen, werden sie trotzdem den alten Master (O) wählen, was zu keinem Problemen führt. Ausserdem verhindert das einen unnötigen Masterwechsel. Damit kann N also erst zum Master werden, wenn O ausfällt. Um auch unnötige Masterwechsel bei einem existierenden WriteQuorum beim Hinzukommen eines neuen Slaves (3) zu verhindern, zum Beispiel wenn SmaxDBminPos Slave im bestehenden Write Quorum ist, weil er erst als Slave die aktuelle Version erhalten hat, wählen alle Slaves, die in einem Writequorum eine VOTEFORME-Message vom Master erhalten, aus o.g. Gründen immer diesen Master, auch wenn sie selbst SmaxDBminPos sind oder der derzeitige Master nicht SmaxDBminPos ist. Nur der neue Slave erkennt wegen (4), dass der Master nicht SmaxDBminPos ist und votet deswegen mit VOTE NO. Da er aber nach einer gewissen Zeit (SMALL SECONDS) SmaxDBminPos als disconnected annimmt und damit seine Version aus der lokalen Hostliste löscht, weil er keine Kommandos von ihm empfängt (er ist ja weiterhin Slave), fragt er nun den einzigen Server, der VOTEFORME s sendet (den Master), nach seiner Version. Dieser ist für den neuen Slave nun erster Masterkandidat und deshalb votet er mit VOTE YES. Einzige Ausnahme ist ein beitretender Server, der sowohl die aktuelle Version als auch eine niedrigerer Hostlistenposition als der bisherige Master hat, also SmaxDBminPos ist. In diesem Fall wählt jeder Slave wegen (3) den neu beigetretenen Server zum Master und verneint VOTEFORME- Messages des alten Masters. Zwar könnten die Slaves auch weiterhin den alten Master wählen 37

38 (weil sie wissen, dass ein Writequorum besteht), der neue Server würde jedoch fortlaufend VOTEFORME-Messages aussenden und den bisherigen Server nicht akzeptieren, weil er nicht weiss, dass bereits ein WriteQuorum besteht (und damit auch nicht, dass er die VOTEFORME s des Masters mit VOTE YES erwidern sollte). In einem solchen Fall scheint es einfacher, den Masterwechsel zu tolerieren, also den neuen Server Master werden zu lassen. Dadurch wird also nur ein neuer Master gewählt, wenn die Bedingung i > n/2 zwischenzeitlich nicht oder zum ersten Mal erfüllt war, der Master selbst ausfällt oder ein aktueller Server hinzukommt, der eine höhere Priorität (niedrigere Hostlistenposition) hat. Um zu unterscheiden, ob sich ein Server in einem Quorum (Write- / Nullquorum) befindet oder nicht, definiert UBIK einen internen Zustand namens Ubikstate. Er kann 3 Werte annehmen: VOTING Es laufen weniger als oder genau n/2 Server, die zusammen noch kein Writequorum bilden können Es laufen seit kurzem mehr als n/2 Server, die gerade einen Master wählen Der Master ist abgestürzt, woraufhin ein neuer gewählt werden muss WRITE QUORUM Es laufen mehr als n/2 Server und der Master wurde gewählt NULL QUORUM Aus einem bestehenden WriteQuorum stürzt ein Server ab, durch das entstehende Quorumtimeout deklariert der Master ein Nullquorum; Sobald er wieder genügend Stiimmen erhalten hat, deklariert er erneut ein WriteQuorum Abbildung 6: Zustände eines UBIK-Servers Der WRITE QUORUM-Zustand wird zusätzlich noch einmal in OTHER WRITE QUORUM (Slave in einem Writequorum) und in SS WRITE QUORUM (Master / Synchronization Site in einem Writequorum) unterteilt. Auch der VOTING-State benötigt eine Unterteilung in einen permanenten (VOTING) und einen temporären (VOTING TEMP) Zustand. Letzterer wird von den Slaves bei der Wahlabgabe für ein Null- oder Writequorum zwischenzeitlich eingenommen. 38

39 5.2.4 Zustandsmapping Im letzten Abschnitt wurden die interne Zustände von UBIK beleuchtet. Um ihnen entsprechende Aktionen des slapd zuordnen zu können, wird eine Abbildung des UBIK-Zustands auf einen internen slapd-zustand benötigt, der nur 3 Werte unterscheiden soll: VOTING : kein WriteQuorum existent MASTER : Server hat die Masterrolle in einem WriteQuorum SLAVE : Server hat die Slaverolle in einem WriteQuorum Bei Start sollten sich sowohl ubik als auch der slapd im VOTING-State befinden. Wenn ein Server von UBIK zur SynchronizationSite gewählt wurde, er also den UBIK-Zustand SS WRITE QUORUM besitzt, sollte der slapd die Masterrolle auf sync-ebene einnehmen, was durch seinen Zustand MASTER angezeigt wird. In diesem Zustand sendet er fortwährend CMD QUORUM WRITE s an die anderen UBIK-Instanzen, die ihrerseits im Zustand OTHER WRITE QUORUM sind. Die entsprechend lokalen slapd-instanzen (Slaves) sollten sich in diesem Fall mit dem Master synchronisieren und nehmen deswegen den Zustand SLAVE ein. Wenn sie vom Master ein CMD QUORUM NULL empfangen, sollten sie zurück in den slapd-zustand VOTING wechseln, da dies das erste Anzeichen für die Auflösung des Quorums bedeuten kann. Der Zustand VOTING TEMP findet im slapd keinerlei Beachtung Abbildung 7: Zustandsmapping zwische n UBIK und slapd Das Leseverbot Beim CMUbik-Algorithmus verbieten Hosts, die in keinem WriteQuorum sind, den Usern das Lesen, weil sie netzwerkbedingt von einem eventuell existierenden Quorum getrennt sein könnten, und deswegen veraltete Daten ausliefern würden. Diese harte Beschränkung ist zwar sinnvoll, wenn es unbedingt erforderlich ist, aktuelle Daten zu erhalten, schränkt aber auch die Nutzbarkeit der LDAP-Server stark ein. Wenn kein Netzproblem vorliegt und wirklich kein Writequorum existiert, könnten die Server ohne Bedenken ihre Daten ausliefern, da es keine aktuellere Version gibt, weil die Daten in keinem Quorum aktualisiert werden könnten. Und selbst wenn sie netzwerkbedingt von einem Quorum getrennt sind, ist die Wahrscheinlichkeit gross, das ein Klient Daten verlangt, die nicht im getrennten Quorum verändert wurden, da LDAP für Daten entwickelt wurde, die selten geändert werden. Deswegen sollte zumindest eine Möglichkeit geschaffen werden, das Verbot von Leseoperationen bei Servern, die nicht in einem Writequorum sind, manuell aufzuheben. 39

40 5.2.6 Berücksichtigung von Teilbaumreplikationen Ein Problem ergibt sich dann, wenn einige Server einen anderen Kontext haben als andere Server. Dies soll hier kurz anhand folgender Abbildung erläutert werden: Nehmen wir folgendes Szenario an: 8 Abbildung 8: Teilbaumreplikation S2 liegt in der Hostliste vor S1 S2 wurde als Slave mit Master S1 synchronisiert, weil S1 eine aktuellere Version hatte S1 fällt aus S2 bemerkt den Ausfall des Masters und geht in den VOTING-State S1 wird neu gestartet da beide die gleiche Datenbankversion haben, gewinnt S2 das Voting, weil seine hlpos kleiner ist nun wird also S2 zum (alleinigen) Master Da S2 den Teilbaum B nicht kennt, kann er für diesen Kontext keine Updates entgegennehmen und S1 daher auch nicht mit Updates für B versorgen. Somit sind Updates für B solange ausgeschlossen, bis wieder ein Server zum Master gewählt wird, bei dem B im Kontext liegt. Um dieses Problem zu umgehen, sollten also nur Server zum Master gewählt werden, die die Vereinigungsmenge der Kontexte aller Server in ihrem eigenen Kontext haben, oder anders gesagt, die jeden Teilbaum in ihrem DIT haben, der von einem anderen Server im Quorum bereitsgestellt wird. Weiterhin muss ein potentieller Masterserver auch den gesamten DIT replizieren, also seine sync-searchbase SBi muss dem Suffix Sui des Servers entsprechen. Das gleiche gilt auch für Server, die zwar den gesamten Kontext replizieren, dafür aber nur ausgewählte Attribute in ihren Entries speichern (Stichwort Datenschutz/Sicherheitsrichtlinien). 8 S = Server 40

41 Entry-Updates, die von diesen Servern als Slave empfangen werden, besitzen zwar den Zeitstempel der letzten Änderung des gesamten Entries, aber nur die zu replizierenden Attribute sind auf dem aktuellen Stand. Somit würden sie als Master die restlichen Attribute unter falschen Namen ausliefern, also mit einem nicht zutreffenden Zeitstempel. Wenn der frühere Master diese restlichen Attribute geändert hat, liefert der neue in dem Falle definitiv falsche Daten aus. Bei der normalen LDAP-sync Umgebung ist das kein Problem, da es keine Masterwechsel gibt, aber hier ist das ein Grund, auch solche Server nicht als Master zuzulassen. Die erwähnte Vereinigungsmenge aller Teilbäume sollte bei jedem Replikationsszenario ein fixer Wert sein und kann somit als konstant angenommen werden. Im obigen Beispiel ist die Vereinigungsmenge der (Teil-)bäume mit dem DN o=org1,c=de (der allgemeinste Suffix), was bedeutet, dass S2 kein Master werden kann. Der gewählte allgemeinste Suffix, nennen wir ihn common suffix Sucom, kann zum Beispiel per Configfile festgelegt werden. Nur wenn folgender Algorithmus einem Server Erfolg meldet, kann er sich als Master bewerben. int canbemaster(my_id) if ((SUi == SUcom) && (SUi == SBi) && all_attrs_replicated) return YES; else return NO; Nun weiss zwar jeder Server Si selbst, ob er VOTEFORME-Anfragen stellen darf, wenn er jedoch der niedrigste Host mit höchster Version im Quorum SmaxDBminPos ist und die anderen Server nicht wüssten, dass er kein Master sein kann, würden sie ihn trotzdem zum Master wählen, weil ja Si ihr Favorit ist. Die anderen Server müssten also darüber informiert werden, dass Si nicht als Master zur Wahl steht, weil er obige Bedingung nicht erfüllt. Diese Information kann zusammen mit der Version ausgetauscht werden und sollte ebenfalls für jeden Host in der Hostliste gespeichert werden. Dadurch würde sich der Algorithmus zur Bestimmung des bestgeeignetsten Servers zum Master erweitern: int lowest_host_with_biggest_version_that_can_be_master() maxdb = -1; hlpos = -1; for all Hosts i in Hostlist if (dbver (Host i) > maxdb) maxdb=dbver (Host i); if (canbemaster (Host i)) hlpos = i; return(hlpos); Den Server, der durch diese Funktion zurückgeben wird, nennen wir SmaxDBpotMminPos einfach Mreal oder Nun ergibt sich aber folgendes Problem: Der UBIK-Algorithmus baut darauf auf, dass alle Server identische Dateninhalte haben. Die Annahme, dass mehr als die Hälfte der Servermenge ausreicht, um mindestens einen aktuellen Server zu enthalten, der Master wird, trifft hier nicht 41

42 mehr zu, da genau dieser eine aktuelle Server möglicherweise kein Master werden kann, weil er obige Bedingung nicht erfüllt und deswegen ein nicht aktueller Server Master wird. Um die Möglichkeit von Teilbaumreplikationen dennoch nutzen zu können, muss die Bedingung i > n/2 in j > n/2 geändert werden. i = notwendige server, um ein Quorum zu bilden j = notwendige server, um ein Quorum zu bilden, die alle potentielle Master sein müssen n = Anzahl der Server in der Hostliste K = Menge aller Server, die potentielle Master sind k i K a k = K Es stehen also nur noch ak von n Servern als Master zur Auswahl. Man beachte, dass mit jedem Server, der nicht Master werden kann, die Wahrscheinlichkeit für ein Writequorum rapide abnimmt. Die Wahrscheinlichkeit PW für ein Writequorum aus mindesten m von n Servern, die je eine Zuverlässigkeit p besitzen, berechnet sich folgendermassen: P W = der Wkt aller Fälle, in denen i m Server laufen p = Zuverlässigkeit eines Servers, zum Beispiel 0, 9 H(i) = Fälle, in denen genau i Server laufen m > n 2 P (i) = Produkt der Wahrscheinlichkeiten p aller i laufenden Server Q(i) = Produkt der Wahrscheinlichkeiten q=1-p aller (n-i) nicht laufenden Server i m P W = H(i) P (i) Q(i) m > n 2 i n m ( ) n = p (n i) (1 p) i n m > i 2 i=0 P W = 1 P W = Wahrscheinlichkeit für das Nichtzustandekommen eines Writequorums Wenn zum Beispiel nur 2 von 8 Servern einen Teilbaum replizieren müssen statt 5 von 8 Servern 5 von (8-2) als 5 von 6 Servern laufen. P 5/8 = P 5/6 = 8 5=3 i=0 6 5=1 i=0 ( 8 i ( 6 i ) 0.9 (8 i) (0.1) i = 0, , , 033 = 99, 5% ) 0.9 (6 i) (0.1) i = 0, , 354 = 88, 5% Damit ist die Wahrscheinlichkeit für das Nichtzustandekommen eines Writequorums rund 23 mal so hoch. Auch bei höherer Serverzahl ist eine relativ grosse Wahrscheinlichkeitsabnahme zu 42

43 beobachten, zum Beispiel wenn 3 von 25 Servern Teilbäume replizieren: P 13/25 = P 13/22 = 12 ( ) (25 i) (0.1) i 100% i 9 ( ) (22 i) (0.1) i = 99, 931% i i=0 i=0 Diese Zahlen wurden mit dem beigelegten Programm n of m berechnet, das auch im Rahmen dieser Arbeit entstand. Es ergibt sich nun die Frage, ob Nicht-Master-Kandidaten trotzdem wahlberechtigt sind. Dazu wieder ein Szenario: In einer Hostliste sind 10 Server angegeben (n=10) Zum Zeitpunkt t0 laufen 5 Masterkandidaten (m=5), sie können kein Quorum bilden, weil die Bedingung m > n/2 nicht erfüllt ist Zum Zeitpunkt t1 startet ein Nicht-Master-Kandidat N und votet für SmaxDBminPos SmaxDBminPos erfüllt ist eröffnet aber trotzdem kein Writequorum, weil m > n/2 immer noch nicht Wie man sieht, ist die Stimme von N wertlos. Da aber beim vorliegenden UBIK-Algorithmus nur diejenigen Hosts eine Benachrichtigung über ein entstandenes Writequorum bekommen, die den Master auch gewählt haben, muss N trotzdem seine Stimme abgeben. Um also die Teilbaumreplikationen zu ermöglichen, muss ein common Suffix im Configfile aufgenommen werden und mit dem Datenbanksuffix und der searchbase verglichen werden, sowie die zu replizierenden Attribute untersucht werden, um zu entscheiden, ob M ein potentieller Master ist eine neue Bedingung geschaffen werden, damit ein Server sich zur Wahl stellen kann - für VOTEFORME (er muss neben der maximalen Version und der minimalen Hostlistenposition auch noch potentieller Master sein) eine neue Bedingung für die Wahl eines Masters eingehalten werden - für VOTE YES (M muss neben der maximalen Version und der minimalen Hostlistenposition auch noch potentieller Master sein) Das gilt nur, wenn sie sich im VOTING-State befindenn (siehe vorheriger Abschnitt) eine neue Bedingung für die Deklaration eines Writequorums erstellt werden - für QUORUM WRITE (es dürfen nur VOTE YES-Stimmen von potentiellen Mastern gezählt werden, um m zu berechnen mit m > n/2) jeder Server seine Master-Eigenschaft allen anderen mitteilen - für MYVER Klientenbenachrichtigung All diese Massnahmen haben wenig Sinn, wenn kein Klient (Nutzer) auf diese Daten zugreift. Die Grundkonfiguration sieht in solch einer Umgebung normalerweise so aus: Klienten in einem LAN kontaktieren den lokalen LDAP-Server Klienten, die nicht dauerhaft vernetzt sind (beispielsweise ppp-klienten) kontaktieren einen fest konfigurierten Server 43

44 Abbildung 9: Klientenszenario Die Aktionen, die ein Klient beim Server veranlassen kann, lassen sich in 3, für diese Arbeit relevante Hauptgebiete aufteilen: Write (hinzufügen, ändern, löschen, verschieben) Read (lesen, suchen, vergleichen) Authorization Da es sich hierbei um eine Single-Master-Umgebung handelt, und der Master als einziger schreibberechtigt ist, besteht die erste Aufgabe darin, die an die Slaves gerichteten Writes an den Master umzuleiten. In Abb. 7 müssten also slapd A und slapd B Writes von ihren Klienten an slapd C weiterleiten, welcher dann nach ihrer Ausführung A und B per LDAP-sync updated. Im slapd-konfigurationsfile slapd.conf gibt es zu diesen Zweck für Replacation-Slaves ein Schlüsselwort namens updateref. Die dort angegebenen LDAP-URLs definieren die Server, an die die Updates weitergeleitet werden sollen und werden als Attribut des für die Replikation definierten Backends gespeichert. In unserem Fall ist hier nur eine URL nötig, und zwar die des Masters. Da dieser Master je nach Konstellation ein anderer Server sein kann, muss dieser Eintrag dynamisch geändert werden können. Diese URL der Form <protocol>://<host>[:<port>] könnte in Standardfällen (protocol=ldap, port=389) aus den Einträgen der UBIK-Hostliste generiert werden, was allerdings die Flexibilität stark einschränken würde. Auch das fixe Mapping zwischen Hostlisteneintrag und LDAP-URL bringt den Nachteil mit sich, dass beispielsweise bei einer Änderung des Protokolls eines Servers dieses Mapping bei allen Servern geändert werden müsste. Sinnvoller wäre es, wenn der Master nach erfolgreicher Wahl allen Slaves seine LDAP-URL mitteilt, die ihrerseits diese URL als Update-Referral im entsprechenden Backend (und als provider- URL) speichern. Da die UBIK-SyncSite (Master) ohnehin die Slaves darüber informiert, dass er der neue Master ist und fortlaufend seine Masterrolle verlängert (QUORUM WRITE), kann dieser Protokollschritt zur Übermittlung der updateurl genutzt werden. QUORUM_WRITE <quorum_until> <updateref> 44

45 Das zweite zu lösende Problem entsteht, wenn ein Master, beispielweise slapd A, ausfällt und die Klienten A1, A2, A3 und X1 so konfiguriert sind, dass sie ausschliesslich auf A zugreifen. In diesem Fall könnten diese Klienten nicht mehr auf die LDAP-Daten zugreifen, weder lesend noch schreibend. Es wäre denkbar, dass B und C in A1, A2, A3 und X1 als Alternativen für A konfiguriert werden, wobei A bevorzugt zu benutzen ist. Dazu ist es nötig, dass sich alle potentiellen Klienten bei allen Servern in der Hostliste authentifizieren können. Haben die Klienten auf Server A Schreibrechte, müssen sie auch auf allen anderen Servern dazu authorisiert sein, damit die Transparenz gewährleistet wird. Dazu muss der DN, mit dem sich der Klient authentifiziert, auf jedem Server vorhanden sein. Bei allen openldap-kliententools (ldapsearch, ldapadd, ldapmodify...) wird der zu kontaktierende Server entweder im File /etc/openldap/ldap.conf oder als Argument des Klienten festgelegt und kann somit nicht während der Laufzeit verändert werden. Um dennoch einen dauerhaften Zugang zu den gewünschten Daten haben zu können, wäre folgende Konstellation denkbar: Die Klienten fragen beim ersten Kontakt mit dem lokalen LDAP-Server nach der UBIK- Hostliste und speichern alle vorhandenen Server (auch die nicht erreichbaren) in einer Liste Fällt der lokale Server aus, versuchen die Klienten der Reihe nach alle Server aus der Liste zu kontaktieren Der Nachteil ist hier, dass die Flexibilität stark eingeschränkt wird, da kein direkter Rückschluss vom Servername auf die LDAP-URL gezogen werden kann und deswegen die Standardwerte protocol=ldap, port=389 angenommen werden müssen. Um diesen Nachteil zu umgehen, müsste die URL jedes Servers bekannt sein. Aus o.g. Gründen (Unflexibilität bei der Änderung von Port und Protokoll) sind diese aber nicht festgelegt und müssen somit bei laufenden Servern erfragt werden. Jeder Server müsste dann beim Start seine URL jedem erreichbaren Quorumaspirant mitteilen, der diese in einer gesonderten Liste speichert. Nun müsste der Klient entweder regelmässig diese Liste vom lokalen Server übernehmen oder müsste von ihm über jede neu hinzugekommene URL informiert werden, um sie in seine eigene Liste zu übernehmen. Wenn der Klient sich nach jeder Operation wieder vom Server trennt, was bei allen openldap-tools der Fall ist, müsste er die Daten permanent speichern können, beispielsweise in ldap.conf. Damit könnte er bei Unerreichbarkeit des lokalen Servers sofort die Alternativserver kontaktieren. Jeder Klient speichert alle bekannten Server-URL s in ldap.conf Jeder Server fragt jeden beitretenden Quorumkandidat (Server) nach seiner URL und speichert sie in einer Liste Der Klient versucht beim Start zuerst den lokalen Server zu kontaktieren Ist er erreichbar, gleicht der Klient sein Configfile mit der Liste des Servers ab, indem neue Server aufgenommen werden und geänderte URLs aktualisiert werden (das kann bei mehreren slapd s pro Server problematisch sein) und sendet seine Requests an ihn Ist der lokale Server nicht erreichbar, kontaktiert er der Reihe nach alle in ldap.conf vorhandenen Server, bis einer von ihnen antwortet. An diesen Server sendet er seine Requests. Da es aber eine grosse Menge anderer LDAP-Klienten gibt, zum Beispiel gq, den javabasierten Ldapbrowser, die Erweiterung des NetscapeMessenger Telefonbuchs oder auch die im openldap-paket enthaltenen Kliententools, die verschiedenste LDAP-Bibliotheken nutzen, kann im Rahmen dieser Arbeit nicht darauf eingegangen werden. Ein weiterer Grund dafür ist, dass 45

46 eine sehr grosse Anzahl von Klienten nicht mit update-referrals umgehen kann (beispielsweise die OpenLDAP-Kliententools) und deswegen derzeit unbrauchbar für ubiksync sind. Eine einfache Variante ist der manuelle Eintrag von mehreren Quorumservern (URL s) in jedes ldap.conf- Klientenconfigfile. 46

47 6 Design und Implementierung Im letzten Abschnitt wurden die genauen Anforderungen sowie die daraus entstehenden Probleme erfasst, und deren Lösung teilweise als Algorithmen realisiert. In dieser Sektion soll es vor allem um die programmiertechnische Umsetzung gehen. 6.1 Grundlegende Änderungen Änderungen der CMUbik-Bibliothek Die CMUbik Bibliothek ist, wie bereits erwähnt, eine Bibliothek, die ein API ähnlich der von BerkeleyDB anbietet. Da wir aber nur den Voting-Mechanismus benötigen, die API aber ausschliesslich Datenbankoperationen anbietet, muss die Schittstelle zu UBIK grundlegend verändert werden. Zu den Aufgaben von UBIK zählte die Masterwahl, die Ausfallerkennung anderer Server, das Mitteilen der Serverrolle an den slapd und das Informieren über ein aufgelöstes Quorum. Desweiteren benötigt UBIK zur Erfüllung seiner Aufgaben einige Daten des slapd, und zwar die Datenbankversion (ctxcsn), den Datenbanksuffix, die URL, die sync-searchbase und die Information, ob der Server als Slave alle Attribute replizieren soll. Die grundlegende Funktionsweise sieht wie folgt aus: 1. Beschaffung o.g. Informationen (ContextCSN, Suffix, URL, Searchbase, allattrs) 2. Anhand von Suffix, Searchbase und Common Suffix prüfen, ob der lokale Server als Master kandidieren kann 3. Kontaktieren aller UBIK-Instanzen in der Hostliste 4. Austausch von Datenbankversion und Mastertauglichkeit mit allen erreichbaren UBIK s 5. Wahl eines Masters anhand der Datenbankversionen und Hostlistenposition 6. Beitritt in ein bestehendes Quorum / Eröffnen eines neuen WriteQuorums 7. Die LDAP-URL des Masters senden oder empfangen 8. Mitteilen des UBIK-Zustands (Ubikstate), also VOTING / NULLQUORUM / WRITE- QUORUM, gegebenenfalls inclusive Master-URL, an den lokalen LDAP-Server Da in keinem dieser Schritte die Datenbankschnittstelle erforderlich ist, kann diese aus der Bibliothek entfernt werden, sodass zu diesem Zeitpunkt keine API mehr vorhanden ist. Alle aufgeführten Schritte kennzeichnen die ausschliesslich aktive Rolle von UBIK. Einzig das Starten des UBIK-Prozesses benötigt eine Funktion, die anderen Programmen zur Verfügung gestellt werden muss. Um die Semantik dieser Funktion gut zu beschreiben, wurde der name ubiksync joinquorum() gewählt. Sie initialisiert den internen Zustand (Ubikstate) und startet anschliessend 2 Threads, die Anfragen anderer UBIK-Instanzen entgegennehmen und verarbeiten. Da die Implementierung von Ubiksync den slapd-quelltext möglichst wenig beeinflussen sollte, wird dessen Konfiguration im Configfile ubik.conf vergenommen. Dazu zählt die Hostliste, der CommonSuffix und ein Flag, das festlegt, ob auch Reads erlaubt sind, wenn der Server nicht in einem Writequorum ist. Letztere Einstellung wird direkt vom slapd gebraucht, um entsprechende Backend-Restrictions zu setzen. Deswegen wird die Funktion ubiksync get always read flag() ebenfalls in die API aufgenommen. 47

48 6.1.2 Änderungen / Erweiterungen des slapd Um folgende Erklärungen besser verstehen zu können, müssen erst einige Algorithmen und Funtionsweisen näher beleuchtet werden: LDAPsync verwaltet eine Runqueue, in der Tasks verwaltet werden, die einen sync-slave dazu veranlassen, sich mit dem Master zu synchronisieren. Jeder Eintrag dieser FIFO- Liste besteht hauptsächlich aus dem Task (do syncrepl() und einem Zeitpunkt, zu dem diese Funktion ausgeführt werden soll. Diese Queue nennen wir hier syncrepltask-list. Im RefreshOnly Mode berechnet sich der Zeitpunkt aus der Summe des Timestamps der letzten Synchronisation und dem Sync-Intervall (interval in slapd.conf), während dieser Wert im RefreshAndPersist-Modus 0 ist, weil es nur einen Task gibt, der nie beendet wird. Diese Runqueue wird im slapd daemon task(), also im Hauptloop des slapd-servers verarbeitet, sodass bei jedem Durchlauf geprüft wird, ob die Zeit wieder reif für einen Updaterequest ist (Das gilt natürlich nur im RefreshOnly-Mode). Ist das der Fall, wird dieser Request ausgeführt, also der Master nach Updates gefragt. Das nachfolgende select() wartet auf eine Aktivität an den listener-sockets, über die die Clients (also auch Slaves) den Server kontaktieren. Liegt nach einem timeout keine Anfrage vor (erkennt select an keinem Socket einen Statuswechsel), wird wieder zum Anfang des Loops gesprungen. Jeder sync-slave verwaltet die Informationen, die zum Replizieren nötig sind, in einem struct namens syncinfo. Er beinhaltet unter anderem die eigene rid, die LDAP-URL des Providers (Masters), Authentifizierungsmerkmale, Replikationsattribute (Attributlisten, Filter, Scope), den Replikationstyp (RefreshOnly / RefreshAndPersist), Zeitintervalle für die Replikation und das synccookie für die Abstimmung mit dem aktuellen Master. Auf diesen syncinfo-struct wird im slapd ausschliesslich über einen Verweis im Backend zugegriffen, wodurch ein Wechsel des Masters einfach durch ein Umsetzen des Zeigers auf einen anderen syncinfo-struct mit anderer provider uri vorgenommen werden kann. Das Backend wird ebenfalls durch einen Struct definiert, in dem eben der Verweis auf den ubiksync-struct gespeichert wird. Unter anderem sind dort auch der Datenbanksuffix (der Kontext) und backendspezifische Einschränkungen (restrict ops) hinterlegt. Über diese Restrictions können beispielsweise Lese- und Schreiboperationen datenbankweit verboten werden. Der bereits erwähnte ContextCSN, der die Aktualität der Datenbank angibt, wird im sync- Umfeld ctxcsn genannt Um mit UBIK Informationen austauschen zu können, muss auch der slapd erweitert werden. Die Funktionsweise sieht hier folgendermassen aus: 1. Starten von UBIK, nachdem auf alle erforderlichen Informationen zugegriffen werden kann 2. Einnehmen der Slaverolle (dazu später mehr) 3. Liefern der von UBIK angeforderten Informationen (ContextCSN, Suffix, URL, Searchbase, allattrs) 4. Warten, bis UBIK einen neuen Zustand mitteilt und entsprechende Aktionen ausführen MASTER im WriteQuorum: Synchronisation stoppen, Lese- und Schreiboperationen erlauben SLAVE im WriteQuorum: Synchronisation mit neuem Master aufnehmen, Lese- und Schreiboperationen erlauben, Schreiboperationen an Master weiterleiten VOTING (kein WriteQuorum): Synchronisation stoppen, Lese- und Schreiboperationen verbieten 48

49 Da der slapd nach dem Start fast ausschliesslich passiv mit UBIK kommuniziert, fällt hier die API etwas umfangreicher aus. Zunächst müssen Funktionen definiert werden, die UBIK alle geforderten Daten liefern können. Die Funktion ubiksync get sync ctxcsn() liefert den ContextCSN des slapd, ubiksync get slapd suffix() liefert den Datenbanksuffix aus slapd.conf, ubiksync get db allattrs() liefert die Information, ob als laut slapd.conf alle Attribute repliziert werden sollen und ob der Server somit als Master geeignet ist und ubiksync get slapd url() gibt im Falle der Wahl als Master die eigene URL zurück, um mittels UBIK den anderen Servern ihren neue SynchronizationSite mitzuteilen. Da ein laufender Standard-LDAP-Server nur auf Klientenanfragen reagiert und sonst keine Schnittstelle für weitergehende Anfragen bereitstellt, lässt sich ein direktes Eincompilieren der ubiksync-schnittstelle nicht umgehen. Es muss also ein Headerfile entstehen, dessen Funktionen den slapd oder seine Komponenten direkt ansprechen. Weiterhin müssen verschiedene Informationen, wie zum Beispiel die URL oder der Datenbanksuffix, beim Start eingelesen werden, da im laufenden Betrieb von aussen nicht darauf zugegriffen werden kann. Die wichtigste Funktion fehlt bis jetzt aber noch: die Möglichkeit, die Rolle im sync-prozess zu wechseln: ubiksync change sync state(). Da der Server im slapd daemon task()-loop auf Verbindungen wartet und erst nach Ablauf des select-timeouts den restlichen Code abarbeitet, was je nach Konfiguration sehr lange dauern kann, ist hier ein einfacher Funktionsaufruf unpraktikabel. Ist der Timeout unendlich, würde die Verarbeitung der veränderten Taskliste bis zur nächsten select-aktivierung warten müssen, also bis sich ein Klient oder ein Sync-Slave mit einem Request meldet. Würde ubiksync selbst die syncrepl-tasklist verändern, könnte slapd diese Änderungen trotzdem erst nach einem Timeout-Ablauf übernehmen, weil die Verarbeitung der syncrepl-tasks vor dem select stattfindet. Der einzige Weg, einen sofortigen Moduswechsel zu veranlassen, ist also die Aktivierung des Abbildung 10: Die Hauptschleife des LDAP-Servers slapd durch das Senden von Daten an einen von select überwachten Socket, sodass dieser unverzüglich aufwacht. Zu diesem Zweck wird im init-abschnitt des slapd daemon task s ein neuer Socket namens ubiksync sock geöffnet und an den UBIKSYNC PORT gebunden. Dieser wird in den listen()-status versetzt, wartet also auf Verbindungswünsche, und wird schliesslich in die Socket-Menge aufgenommen, die select() beaufsichtigt. Nach dem select() wird geprüft, ob dieser Sockets der Grund für die Aktivierung war (FD ISSET(ubiksync sock,&readfds)) und falls dies der Fall ist, wird die neue Verbindung akzeptiert. Die empfangenen Daten (ubiksync request, dazu gleich mehr) werden ausgewertet und die entsprechdenden Aktionen sofort von der Funktion ubiksync change sync state() vorgenommen. Da nach der Verarbeitung sofort ein neuer Loop-Durchgang folgt, werden die Änderungen der syncrepl-tasklist unverzüglich berücksichtigt. 49

50 6.2 Das Kommunikationsmodell Kommunikation zwischen slapd und lokalem UBIK Die im letzten Abschnitt gesammelten Interaktionsanforderungen an UBIK und den slapd werden hier noch einmal zusammenfassend dargestellt. Die folgende Abbildung zeigt eine Erweiterung von Abb. 5. Der Informationsaustausch findet durch Funktionsaufrufe und Socketoperationen statt. Abbildung 11: Kommunikation zwischen UBIK und slapd Die Aufrufe put suffix(), put slapd uri() und put slave syncinfo() werden beim Starten des Servers ausgeführt, um die entsprechenden Daten in Ubiksync zu speichern und während der Laufzeit darauf zugreifen zu können. Unter die Kategorie get config fällt zum Beispiel, dass sich der slapd mittels get always read flag() die Erlaubnis einholt, auch Leseoperationen im Voting- oder Nullquorum-State zu gestatten. Die Kommunikation über den UBIKSYNC-Socket geschieht durch den Austausch von ubiksync request s, die aus folgender Datenstruktur bestehen: typedef struct _ubiksync_request int request_id; /* 4 byte */ int oldstate; /* 4 byte */ int newstate; /* 4 byte */ char newmaster[50]; /* 50 byte */ ubiksync_request; /* 62 bytes */ Die request id kann den Wert UBIKSYNC RQ CHANGE SYNCSTATE annehmen, was, wie der Name schon andeutet, einen Zustandswechsel auslösen soll. Die Antwor- 50

51 ten auf diesen Request sind entweder UBIKSYNC RP CHANGE SYNCSTATE SUCCESS oder UBIKSYNC RP CHANGE SYNCSTATE NOSUCCESS. Die Variablen newstate und oldsate können die Werte UBIKSYNC STATE MASTER, UBIKSYNC STATE SLAVE oder UBIKSYNC STATE VOTING annehmen und somit dem slapd mitteilen, welche Rolle er einnehmen soll. Der String newmaster teilt einem Slave (UBIKSYNC STATE SLAVE) die URL des neuen Masters mit. Um den Einsatz von ubiksync mit möglichst wenigen Einschränkungen zu ermöglichen, sollte sowohl der Port, mit dem UBIK lokal mit dem slapd kommuniziert, als auch der, mit dem die UBIK-Instanzen untereinander über ein Netzwerk Informationen austauschen, konfigurierbar sein. Auch diese Einstellungen werden in ubik.conf vorgenommen (ubik port, ubiksync port) und müssen zum Teil an den slapd übertragen werden, was durch die in das UBIK-Interface aufgenommene Funktion ubiksync get ubiksync port() erfolgt. Da UBIK vom slapd gestartet wird, kann es vorkommen, dass UBIK seine Konfiguration noch nicht eingelesen hat, wenn slapd den Port erfragt, und ubiksync get ubiksync port() somit den Wert Init-Wert 0 liefert. Um dises Problem zu umgehen, muss die Funktion selbst die entsprechende Zeile aus ubik.conf lesen Kommunikation zwischen den UBIK-Instanzen Diese Kommunikation erfolgt ausschliesslich durch den Austausch von Kommandos des UBIK- Protokolls über Sockets. Zur Vereinfachung werden hier nur 3 Instanzen U1,U2 und U3 verwendet. Folgende Kommandos, von denen einige durch Parameter ergänzt werden, sind definiert: 9 CMD VOTEFORME wird von U1 versendet, wenn er SmaxDBminPos ist U2 und U3 antworten mit einem CMD VOTEYES, wenn sie mit diesem Master einverstanden sind, wenn sie also auch der Meinung sind, dass U1 SmaxDBminPos ist. U2 und U3 antworten mit einem CMD VOTENO, wenn sie U1 nicht für SmaxDBminPos halten oder sie in den letzten BIG SECONDS einen anderen Server gevotet hatten Um die Version von U1 zu erfragen, sendet U2 ein CMD ASKVERSION Dieser antwortet darauf mit einem CMD MYVER <icanbemaster> <version>. Diese Version ist der in einen Unix-Zeitstempel umgewandelte ContextCSN des lokalen LDAP-Servers, also eine 8-Byte lange LongInt-Zahl, während das erste Argument der Rückgabewert der Funktion can i be master() ist. Um als gewählter Master den Slaves die Bildung eines NullQuorums mitzuteilen, dient das Kommando CMD QUORUM NULL <quorum until> <master uri> Quorum until ist die Summe vom aktuellen Unix-Timestamp und SMALL SECONDS und hilft den empfangenden Slaves beim Erkennen eines Masterausfalls (Quorum-Timeouts), indem sie selbst ständig prüfen, ob ihre lokale Zeit, addiert mit SMALL SECONDS diesen Wert überschritten hat. In diesem Fall wechseln sie in den Voting-State. Die master uri enthält die LDAP-URL des gewählten LDAP-Servers, die von den empfangenden Slaves an ihren slapd weitergeleitet wird, um ihm den neuen Master und das Update-Referral zu liefern. Zur Mitteilung über ein entstandener WriteQuorum wird das Kommando CMD QUORUM WRITEL <quorum until> <master uri> verschickt, das die gleichen Parameter wie CMD QUORUM NULL besitzt. 9 U = UBIK-Instanz 51

52 Die Kommandos werden in der Funktion parse(), die von connections select() aufgerufen wird, ausgewertet und anhand von empfangenen Versionen und Erreichbarkeiten anderer Instanzen entsprechend beantwortet. Ein Problem, das in der CMUbik-Originalversion nicht beachtet wurde, ist das fast gleichzeitige Eintreffen von Kommandos ein und der selben Ubik-Instanz auf dem selben Socket. Das führte in dieser Implementierung, in der dieser Fall öfter auftritt, dazu, dass select nur einmal aktiviert wurde und kurz darauf das zweite Kommando eintraf, bevor der gesamte Socketinhalt ausgelesen wurde. Nach der Auswertung des Kommandos wurden eventuelle Parameter aus den noch nicht verarbeiteten empfangenen Daten gesammelt und im Anschluss alle nicht gebrauchten Daten verworfen. Wenn nun zum Beispiel ein hier häufiger versendetes Kommando wie CMD ASKVERSION kurz nach einem CMD MYVER eintrifft, was beim Start eines Servers immer der Fall ist, wird das zweite Kommando unter Umständen einfach ignoriert, da es wie gerade erläutert, weggeworfen wird und es würden Verklemmungen entstehen, da auf genau dieses zweite Kommando gewartet werden würde. Die Lösung dieses Problems besteht darin, schon auf Protokollebene zu entscheiden, wieviele Daten gelesen werden müssen. Dazu wird nach der Aktivierung von select() jeweils nur ein Byte (das Kommando) gelesen. Anschliessend wird geprüft, wie gross die Datenmenge der Parameter dieses Kommandos sein sollte, genau diese Menge gelesen und von parse() verarbeitet. Eventuell nicht gelesene Daten aktivieren das select() beim nächsten Schleifendurchgang und werden in gleicher Weise verarbeitet. Diese Vorgehensweise verhindert den Kommandoverlust komplett, führt aber auch dazu, dass alle Parameter eine fixe Grösse haben müssen. In dieser Implementierung betrifft dies vor allem die zu übertragende slapd-url, die hier unabhängig von ihrer Stringlänge immer als 50-Byte-String übertragen wird. Eine graphische Darstellung dieses Protokolls erübrigt sich hier, jedoch wird später noch einmal auf die genaue Ursache und Wirkung der einzelnen Kommandos eingegangen sowie ein Kommunikationsablauf anhand eines beispielhaften Szenarios erklärt Das Prozessmodell und Interprozesskommunikation Da Ubik vom laufenden LDAP-Server gestartet wird, mit ihm kommunizieren soll, selbst aber eigenständig und unabhängig von ihm arbeiten sollte, ist nur eine parallele Ausführung beider Teile praktikabel. Die beiden Möglchkeiten, die hierzu in Frage kommen, sind Prozesse und Threads. Die CMUbik-Implementation arbeitet intern mit Lightweight Processes (Threads), da der Aufwand zum Taskwechsel hier bedeutend kleiner ist als bei Prozesswechseln und Threads das Teilen eines gemeinsamen Datenbereichs ermöglichen. In diesem zusammen genutzen Speicher werden unter anderem Semaphore (Mutexe) verwaltet, um atomare Datenbereichszugriffe zu ermöglichen. Der erste Thread, den UBIK verwendet, ist der ubik loop, der den ubik state auswertet und entsprechende Aktionen auslöst, beispielsweise das Aussenden von VOTEFORME-Kommandos oder den Übergang in den Voting-State beim Erkennen eines Quorum-Timeouts. Die vom ubik loop aufgerufene Funktion connections select() überwacht weiterhin alle aktiven Verbindungen zu anderen UBIK-Instanzen, wertet von ihnen empfangene Kommandos aus und sendet gegebenenfalls entsprechende Antworten zurück. Der zweite Thread, der consuming loop(), wurde in der CMUbik-Implementierung hauptsächlich zur Verarbeitung von empfangenen Kommandos zur Datenbankmanipulation (Twophase-Commit, Write-Forwards u.s.w.) verwendet. Da diese hier nicht benötigt werden, wurden die übrigen Funktionen in den ersten Thread verlagert und dieser Thread entfernt. OpenLDAP arbeitet mit einem Thread-Pool, dessen Grösse im Configfile mit dem Schlüsselwort threads bestimmt werden kann und ansonsten einen Standardwert von 32 hat. Sofern diese Maximalzahl von laufenden Threads noch nicht erreicht ist, wird für jede Klientenverbindung ein Thread aus diesem Pool benutzt. Anderenfalls wird die Anfrage zurückgestellt und in ei- 52

53 ne Warteliste (pending list) aufgenommen. Sobald ein Platz im Threadpool frei wird, nutzt die am längsten wartende Aufgabe diesen verfügbaren Slot. Zu beachten ist hier, dass Klienten, deren Verbindung nach einem Request nicht beendet wird, also zum Beispiel SyncSlaves im RefreshAndPersist-Mode, dauerhaft einen Thread aus diesem Pool besetzen. Wenn also beispielsweise ein Master bei Standardkonfiguration 32 Slaves im RefreshAndPersist-Mode mit Updates versorgt, können weder Updates am Master selbst noch an Slaves gerichtete Updates vorgenommen werden, die an den Master geforwardet werden, weil jede Updateoperation eine gesonderte Verbindung zu M erfordert und der zu erstellende Thread nie aus der pending list übernommen wird, weil der Pool bereits voll ist. Deswegen sollte bei der Konfiguration dieses Pools die Grösse der Hostliste beachtet werden, wenn der zu bevorzugende RefreshAndPersist-Mode verwendet wird. Da der Wechsel zwischen Threads bedeutend weniger Zeit in Anspruch nimmt als der Prozesswechsel, wird UBIK vom slapd in der Funktion slapd daemon task() vor der Hauptschleife aus als Thread gestartet. Die Funktion ubik init() liest das Konfigurationsfile ubik.conf aus, erstellt daraufhin eine interne Repräsentation der Hostliste, initialisiert den ubik state, erfragt mit getdbversion() und ubiksync get slapd suffix() die für folgende Aufgaben erforderlichen Daten des LDAP-Servers, öffnet den Socket, über den andere UBIK-Instanzen Kontakt aufnehmen können, versucht seinerseits alle Hosts aus der Hostliste zu erreichen und startet schliesslich den ubik loop() ebenfalls als Thread. Dieser arbeitet dann in oben beschriebener Weise und erfüllt damit alle Aufgaben, die von UBIK verlangt werden. Die folgende Abbildung stellt sämtliche Prozesse (Threads), sowie deren Aufruf und die Kommunikation zwischen ihnen noch einmal graphisch dar. Abbildung 12: Das Prozessmodell und InterProcessCommunication Die Kommunikation zwischen den LDAP-Servern selbst, die über das nomale LDAP-Protokoll 53

54 stattfindet, bleibt hier unverändert, lediglich von LDAP-Klienten initiierte Schreiboperationen werden durch einen Tausch von Provider- und Consumerrolle derart beeinflusst, dass sie gegebenenfalls an den Master geforwardet werden müssen. Die Verbindung zu Klienten selbst bleibt ebenfalls weitestgehend unverändert, ausser dass bei entsprechender Einstellung Leseoperationen verboten werden, wenn sich der Server in keinem WriteQuorum befindet. 6.3 Das Ablaufmodell anhand eines Szenarios In diesem Abschnitt werden die genauen Abläufe während des Betriebs von Ubiksync und die Koordination von UBIK und slapd vorgestellt. Um die neu entwickelte Funtionsweise von Ubiksync näher zu beleuchten, wird eine beispielhafte Kommunikation zwischen mehreren Ldap-Ubik- Servern nachvollzogen Voraussetzungen Es existieren 3 LDAP-Server, A, B und C, die in jeder Hostliste in der gleichen Reihenfolge (A,B,C) registriert sind. Auch der UBIK-Port ist in allen ubik.conf-files gleich definiert. Alle 3 Server waren bisher weder Master noch Slave in einer LDAPSync- oder ubiksync-umgebung, sind in slapd.conf aber als Sync-Slave konfiguriert und haben im Verzeichnis bereits Einträge wie den BaseDN, den RootDN, den UpdateDN und den BindDN gespeichert. Wenn nicht gesondert darauf hingewiesen wird, handelt es sich um die RefreshOnly-Methode Der Serverstart In unserem Szenario startet Server B zuerst. Als erstes wertet slapd die Kommandozeilenargumente aus, wobei für diese Erklärung nur die Option -h URLs wichtig sind. Der ermittelte Wert wird mittels ubiksync put slapd url() im slapd-teil von ubiksync zwischengespeichert. Sobald slapd sein Konfigurationsfile slapd.conf einliest, erkennt er am Vorhandensein einer syncrepl-direktive, dass er die Slaverolle einnehmen soll und erzeugt daraufhin eine syncrepl runqueue mit einem dummy-master, der nur der Vollständigkeit halber vorhanden sein muss, in Wirklichkeit aber nicht existiert. Es wird ausserdem ein syncinfo-struct erzeugt, der mit dem Backend verknüpft und zur späteren Verwendung in ubiksync hinterlegt wird, Auch der suffix und das db allattrs-flag, das aus dem syncinfo-struct extrahiert wird, wird in ubiksync gespeichert. Nachdem die vollständige Initialisierungen abgeschlossen ist, wird der slapd daemon task() als Thread gestartet. Die erste Aktion, die diese Funktion ausführt, ist das Starten von UBIK mittels ubiksync start ubik(). Anschliessend wird der Socket zur Kommunikation mit UBIK geöffnet, an den über ubiksync get ubiksync port() ermittelten Port gebunden und in den listen-staus versetzt. Nach der Aufnahme dieses Sockets in die von select() überwachte Menge startet die Hauptschleife. Diese überwacht hauptsächlich die Menge aller registrierten Sockets. In der Zwischenzeit sollte UBIK seine vollständige Konfiguration eingelesen haben und die Datenbankversion vom slapd mit getdbversion() erfragt haben. Desweiteren benutzt es den gespeicherten Suffix, das db allattrs-flag, die im syncinfo-struct hinterlegte Searchbase, die gespeicherte URL des slapd-servers und die commonsuffix-einstellung aus ubik.conf, um zu entscheiden, on der Server Masterkandidat ist. Nun wird die alwaysallowreads-direktive aus ubik.conf in ubiksync gespeichert, der UBIK- und UBIKSYNC PORT registriert und die Hostliste initialisiert. Schliesslich wird versucht, eine Verbindung zu jedem Hostlistenmitglied herzustellen und der ubik loop() gestartet. Mit der Initialisierung des ubik-states mit VOTING wird dem slapd ein ubiksync request zugeschickt, bei dem nur die Werte request id = UBIKSYNC RQ CHANGE SYNCSTATE und newstate = UBIKSYNC STAE VOTING belegt sind. 54

55 Aufgrund des aktivierten select s wertet der slapd diesen Request aus und ruft infolge dessen die Funktion ubiksync change sync state(ubiksync STATE VOTING, 0, NULL) auf. Sie bekommt mit dem Aufruf von ubiksync get always read flag das always read flag, entfernt den Verweis vom Backend zum Syncinfo-Struct, leert die syncrepl runqueue, verbietet anhand des Backend-Flags SLAP RESTRICT OP WRITES Schreiboperationen und, wenn entsprechend konfiguriert, mittels SLAP RESTRICT OP READS das Lesen von diesem LDAP-Server. Infolge der geleerten syncrepl-tasklist versucht der slapd nun nicht mehr, sich mit dem Dummyserver zu synchronisieren. Abbildung 13: Koordination beim Start eines Servers 55

56 6.3.3 Die Masterwahl Der zweite startende Server ist C, dessen Startprozedur der gerade beschriebenen entspricht. Der folgende Absatz behandelt ausschliesslich UBIK-Interaktionen. Nach dem Eintritt in den ubik loop versucht C, sich mit allen anderen Servern aus der Hostliste zu verbinden, also mit A und B. B akzeptiert die Verbindung, aktualisiert seine eigene in der Hostliste gespeicherte Datenbankversion und sendet durch den Aufruf der Funktion hostlist hostconnected() ein CMD ASKVER an C, der daraufhin die Funktionen getdbver() und canibemaster() seiner ubiksync-instanz aufruft um mit den erhaltenen Werten ein CMD MYVER <icanbemaster> <dbver> zurückzuliefert. Da das CMD ASKVER das erste von B empfangene Kommando war, sendet C ebenfalls ein CMD ASKVER, das B in gleicher Weise beantwortet. Im Anschluss an diesen Protokollabschnitt hat jeder der beiden Server die eigene Version und die des anderen in der Hostliste gespeichert. Aufgrund dessen kann nun jeder Server auswerten, ob er selbst lowestwithbiggestversion() ist. Da beide Server den Ctxcsn = 0 geliefert haben, weil sie bisher weder Master noch Slave in einer Sync-Umgebug waren, entscheidet zu diesem Zeitpunkt nur die Hostlistenposition. Also sendet B ein CMD VOTEFORME an C, der diese Anfrage zuerst verneint (CMD VOTE NO). Das liegt daran, dass sich C vor der Bekanntgabe von B s Version selbst gewählt hat und erst nach SMALL SECONDS einen anderen Server wählen darf. B sendet weiterhin in bestimmten Intervallen VOTEFORME-Messages aus, sodass nach Ablauf der SMALL SECONDS eine CMD VOTE YES- Antwort von C empfangen wird. Da sich B auch selbst wählt, also insgesamt 2 VOTE YES- Stimmen von unterschiedlichen Servern erhalten hat, womit die Bedingung i>n/2 erfüllt ist, deklariert er lokal ein WRITE QUORUM. Anschliessend erfragt er mittels get slapd url() die URL des lokalen LDAP-Servers, bestimmt den Wert quorumuntil in bereits beschriebener Weise und teilt C mit einem CMD QUORUM WRITE <until> <ownurl> diese Entscheidung mit. Nun ruft er die Funktion ubiksync state set master(master URL) auf, die ihrerseits einen ubiksync request mit der Belegung request id = UBIKSYNC RQ CHANGE SYNCSTATE und newstate = UBIKSYNC STATE MASTER an den ubiksync-port schickt. Nachdem der select()-port des slapd daraufhin aktiviert und der Request ausgewertet wurde, wird in der Funktion ubiksync change sync state(ubiksync STATE MASTER, UBIKSYNC STATE VOTING,NULL) aufgerufen, deren einzige Aufgabe zu diesem Zeitpunkt im Zurücksetzen aller Datenbankrestriktionen besteht. Somit können ab diesem Zeitpunkt von B sowhl Lese- als auch Schreibanforderungen entgegengenommen werden. Wenn C das CMD QUORUM WRITE empfängt, deklariert er lokal ein WRITE QUORUM und sendet ebenfalls einen ubiksync request an den lokalen slapd mit der Belegung request id = UBIKSYNC RQ CHANGE SYNCSTATE, newstate = UBIKSYNC STATE SLAVE und newmaster = master uri, also der empfangenen URL des Masters. Auch hier wird die Funktion ubiksync change sync state() aufgerufen, allerdings mit den Argumenten (newstate = UBIKSYNC STATE SLAVE,oldstate = UBIKSYNC STATE VOTING,newmaster = Master-URL). Die empfangene URL wird im durch ubiksync put slave syncinfo() zwischengespeicherte Syncinfo-Struct als syncinfo->si provideruri und im Backend-Struct als backend->be update refs eingetragen, wodurch der neue Master von C festgelegt wird, mit dem er sich synchronisieren soll und an den Updates weiterzuleiten sind. Weitere Einstellungen in slapd.conf, die die Synchronisation beeinflussen, beispielsweise die Wahl der Methode, die Searchbase, Replikationsintervalle oder auch Authentifizierungsattribute, werden unverändert in den neu generierten Struct übernommen. Anschliessend werden laufzeitspezifische Elemente des Syncinfo-Structs neu initialisiert, sodass er nun mit dem Backendinfo-Struct verlinkt werden kann. Die durch den vorangehenden Votingzustand gesetzten Datenbankrestriktionen werden aufgehoben, die Syncrepl-Taskliste wird initialisiert und mit dem generierten Syncinfo-Struct als Argument gestartet, wodurch C sich ab nun mit B synchronisiert. 56

57 Abbildung 14: Koordination bei der Masterwahl Klienteninteraktion Da an den Master gerichtete Updates von Klientenseite genauso ablaufen, wie bei einem Standard- LDAP-Server, sollen hier nur Interaktionen mit dem Slave näher betrachtet werden. Bei dieser Interaktion spielen UBIK und Ubiksync keine Rolle; alle Aufgaben werden hier vom slapd durchgeführt. Wichtig dabei ist, dass der LDAP-Klient, hier K genannt, mit Referrals umgehen, also die bei einem Updatevorgang vom Slave erhaltene Referral-URL verarbeiten kann. Auf der Seite von Openldap [OLDAPORG] ist zu lesen, dass die mitgelieferten Tools (ldapadd, ldapsearch, ldapmodify...) diese Anforderung nicht erfüllen. Ich selbst benutze den LDAPBrowser von Jarek Gawor. [LDAPBROWSER] Sobald sich K bei C authentifiziert hat, startet der LDAPBrowser eine Suche nach dem gesamten 57

58 Teilbaum, der als BaseDN konfiguriert werden kann. Soll nun beispielsweise ein neuer Eintrag erstellt werden, etwa mit dem Inhalt eines LDIF-Files, wird von K ein Addrequest mit dem gewünschten Inhalt generiert und an den slapd C gesendet. Dieser erkennt am Vorhandensein des SLAP DBFLAG SHADOW-Flags seine Slaverolle und sucht daraufhin in seinem BackendInfo-Struct nach einen Eintrag in der Liste be update refs, wo er B s URL findet. Infolge dessen führt er dieses Update nicht aus, sondern sendet eine Referral-Antwort mit der in der Liste vorhandenen URL zurück an K. Kann K diese Referrals verabeiten, sendet er den gleichen Addrequest an die gelieferte URL, also an B. Dieser nimmt das Update entgegen und führt es aufgrund des Nichtvorhandenseins des Flags SLAP DBFLAG SHADOW aus. Im folgenden wird angenommen, dass B aufgrund der schon vorhandenen Eintragungen einen ContextCSN-Eintrag hat, denn er wird beim Erstellen des allerersten Eintrags erzeugt. Nach dem Update aktualisiert B also einen Context-CSN-Entry mit dem Zeitstempel des gerade ausgeführten Updates. Beim nächten SyncRequest seitens C erkennt B am mitgelieferten Cookie, das in früheren Requests erstellt wurde, dass der soeben getätigte Neueintrag einen neueren Zeitstempel trägt als der ctxcsn-wert der Cookies und sendet infolge dessen diesen Eintrag als Antwort zurück. C aktualisiert seine Datenbank und übernimmt den neuen ctxcsn-wert in seinen SyncConsumer- Subentry, dessen Werte er als Cookie für die folgenden Anfragen nutzt. Auch im RefreshAndPersist-Mode leitet C die Updates an B weiter, erhält jedoch unverzüglich eine SyncStateControl-Message von B, die den geänderten Eintrag enthält. Falls der SyncProviderSubentry noch nicht existiert hat, wird er von B zum Zeitpunkt des ersten ausgeführten Updates mit entsprechendem ctxcsn-wert erstellt. Das gleiche gilt für C s Sync- ConsumerSubentry, der mit dem ersten Empfangen eines sync-reply s erzeugt wird. Abbildung 15: Klienteninteraktion Ein dritter Server tritt ein In diesem Abschnitt wird nur die Interaktion zwischen den UBIK-Instanzen betrachtet, da die Kommunikation mit Ubiksync und dem slapd bereits beschrieben wurde und sich hier nicht anders darstellt. Als dritter Server startet in diesem Szenario Server A, der ebenfalls die selbe 58

59 Startprozedur wie B durchläuft. Er versucht sich daraufhin mit B und C zu verbinden, wodurch er von beiden Servern je ein CMD ASKVER erhält. Er liefert seine durch das verpasste Update nicht aktuelle Datenbankversion und fragt B und C ebenfalls nach ihrer Version. Nachdem er die beiden Antworten erhalten hat, erkennt er durch den Aufruf von lowestwithbiggestversion(), dass er selbst nicht Master werden kann und wartet auf ein VOTEFORME vom lowest Host with biggest Version B, der dieses Kommando regelmässig an alle Hosts aussendet, die nicht in seinem WriteQuorum sind. Während C nun aus oben genannten Gründen diese Anfrage für eine bestimmte Zeit mit VOTE NO beantwortet, synchronisiert sich C weiterhin mit B. Sobald A mit VOTE YES antwortet, deklariert B den Server A intern als Mitglied in seinem Quorum und sendet ab sofort CMD QUORUM WRITE s an A. A sendet beim Empfangen dieses Kommandos ebenfalls einen ubiksync request an den lokalen slapd, der daraufhin die oben beschriebenen Aktionen zur Initialisierung des Slavezustands ausführt und sich fortan mit B synchronisiert. Abbildung 16: Ein Out-Of-Date-Server tritt bei Falls A die gleiche Datenbankversion wie B hätte, sieht der Vorgang etwas anders aus: Nach dem Austausch der Versionen wissen alle 3 Server, dass A lowestwithbiggestversion ist. Doch B sendet weiterhin VOTEFORME-Messages aus, die von A, C aber auch von B selbst mit einem VOTE NO beantwortet werden, bis B s WriteQuorum durch ein Timeout (SMALL SECONDS) ausläuft. Nach der Auflösung des Quorums und dem internen Übergang in den VOTING-State sendet B ein QUORUM NULL an C, sodass dieser ebenfalls den ubiksync-voting-state einnimmt. Zu diesem Zeitpunkt fängt A an, selbst VOTEFORME-Messages auszusenden, die sofort mit VOTE YES beantwortet werden, da alle Server innerhalb der letzten SMALL SECONDS keinen anderen Server gewählt haben. Damit ist die Bedingung i>n/2 erfüllt, A nimmt die Masterrolle in oben beschriebener Weise ein, während B und C durch das empfangene CMD QUORUM WRITE in den Slavestate wechseln. 59

60 Abbildung 17: Ein Up-To-Date-Server mit niedrigster Hostlistenposition tritt bei Ein Serverausfall Auch hier sind wieder verschiedene Fälle zu unterscheiden, deren Auswirkungen im folgenden beleuchtet werden. Das erste zu betrachtende Szenario ist der Ausfall eines Slaves, wobei anschliessend immer noch genügend Server laufen, um das Quorum aufrecht zu erhalten. Es sei, um bei der letzten Konstellation zu bleiben, A der Master, sowie B und C seine Slaves. (Abb. 18) Fällt nun B aus, erneuert A den quorum until-wert des WriteQuorums nicht, weil die Funktion declare quorum() diesen Wert berechnet, indem die Summe aus oldestinquorum() und SMALL SECONDS gebildet wird. Die Funktion oldestinquorum() gibt den Zeitpunkt der letzen Wahl des Servers zurück, dessen Stimme am längsten zurück liegt, also den Zeitpunkt der letzten Wahl seitens B. Wird nun SMALL SECONDS lang kein VOTE YES von B empfangen, läuft das Quorum aus, weil eben der quorum until-wert nicht erneuert wird. Daraufhin sendet A ein QUORUM NULL an B und C mit bereits beschriebenen Folgen, bleibt selbst aber im Zustand SS WRITE QUORUM und erhält von C ein VOTE YES. Zusammen mit seiner eigenen Stimme ist damit die Anzahl der benötigten Votes erreicht und A deklariert sofort ein neues WriteQuorum, das ebenfalls von C akzeptiert wird. Beim zweiten Fall soll nach dem Ausfall des Slaves B die Bedingung i>n/2 nicht mehr erfüllt sein. (Abb. 19) Für diese Betrachtung muss ein weiterer Server in die Hostliste (ubik.conf) aufgenommen werden, damit ein Writequorum nur mit mindestens 3 Servern (3>4/2) gebildet werden kann, nach dem Ausfall aber immer noch 2 Server miteinander kommunizieren. Auch hier sollen sich im Augangszustand B und C mit A synchronisieren. Fält nun Server B aus, wird dies von A durch ein Quorum-Timeout nach SMALL SECONDS bemerkt. Infolge dessen sendet er ein CMD QUORUM NULL an C, der den OTHER NULL QUORUM-Zustand einnimmt, während A selbst noch SyncSite im Writequorum ist. Ebenso antwortet C sofort mit einem VOTE YES, jedoch kann A aufgrund der zu wenigen Stimmen kein WriteQuorum bilden, wechselt daher in den ubiksync-voting-state und sendet fortan solange VOTEFORME-Kommandos aus, bis er wieder 60

61 Abbildung 18: Nach dem Ausfall eines Slaves sind noch mehr als n/2 Server aktiv mehr als n/2 VOTE YES-Stimmen erhält. Währenddessen bleibt B im OTHER NULL QUORUM-State, um beim Starten eines weiteren Servers sofort in das Writequorum von A aufgenommen zu werden. Im ubiksync-kontext besitzt er durch das Mapping den VOTING-State, synchronisiert sich also nicht mehr mit A. Der dritte Fall behandelt den Ausfall des Masters A (Abb. 20). Nachdem von B und C SMALL SECONDS lang kein QUORUM WRITE von A empfangen wurde, ist für beide das Quorum ausgelaufen und sie wechseln in den VOTING-State. Beide Server haben zu diesem Zeitpunkt entweder nur die Version des anderen in der Hostliste, die er beim Start des Quorums hatte, oder diese wurde dadurch zurückgesetzt, weil beide nicht miteinander kommuniziert haben und sich gegenseitig als disconnected deklariert haben. Da es ausserdem sein kann, dass C sich bereits mit A synchronisiert hatte, bevor A ausfiel, während sich B noch nicht auf dem aktuellen Stand gebracht hatte, ist vor der Neuwahl ein erneuter Versionsaustausch erforderlich. Dazu wird im ubik loop bei jedem Eintritt in den VOTING-State geprüft, ob der letzte State OTHER WRITE QUORUM war, also der Server Slave in einem WriteQuorum war. Ist dies der Fall, wird von allen Servern ausser dem ehemaligen Master die Version mittels CMD ASKVER erfragt. Sind nach dem Masterausfall noch mehr als die Hälfte der Server aktiv, findet anhand der ausgetauschten Versionen eine Neuwahl statt, die wie bereits beschrieben abläuft. Laufen nach dem Masterausfall weniger als oder genau n/2 Server, sendet SmaxDBminPos fortlaufend VOTEFORME-Messages aus, die von den anderen Servern mit VOTE YES beantwortet werden, aber zu keinem WriteQuorum führen Teilbaumreplikation Wie bereits zu sehen war, wird das Flag icanbemaster nur gesetzt, wenn LDAP-Searchbase, slapd-suffix und Common Suffix übereinstimmen, sowie alle Atrribute repliziert werden. Es wird genutzt, um zu entscheiden, ob selbst VOTEFORME-Messages ausgesendet werden dürfen, und ob 61

62 Abbildung 19: Nach dem Ausfall eines Slaves sind weniger als n/2 Server aktiv selbige Anfragen anderer Server mit VOTE YES zu beantworten sind. Wird nun der aktuelle Server A gestartet, nachdem B und C bereits ein WriteQuorum gebildet haben, ist aber zum Beispiel so konfiguriert, dass er nur einen Teilbaum des Common Suffix repliziert, passiert folgendes: Nach seinem Start findet ein Versionsaustausch zwischen ihm und den beiden laufenden Servern statt. Beim Empfangen von A s Antwort CMD MYVER <icanbemaster> <dbver> tragen B und C sowohl seine Datenbankversion als dbver als auch seine Mastertauglichkeit als canbemaster-flag in ihre lokale Hostliste ein. A selbst prüft mit der Funktion islowestwithbiggestversion(me), ob er VOTEFORME s aussenden darf, was hier durch das nicht gesetzte Flag verneint wird. Empfängt er VOTEFORME-Messages von B, wird ebenfalls diese Funktion genutzt, die in diesem Fall eine positive Rückmeldung liefert. Da Datenbankversion und Mastertauglichkeit beim Start jedes Servers ausgetauscht werden und die Hostliste laut Anforderung bei jedem Server gleich sein muss (also auch ihre Reihenfolge), gibt die Funktion islowestwithbiggestversion(id) überall die selbe Antwort, wodurch Verklemmungen bei der Masterwahl praktisch ausgeschlossen sind Der RefreshAndPersist-Modus Die bisherigen Erklärungen beiziehen sich primär auf die Nutzung des RefreshOnly-Modes, in dem die Klienten periodisch nach Updates fragen und nach der Antwort seitens des Masters die Verbindung wieder trennen. Im RefreshAndPersist-Mode, in dem die Slaves die Verbindung dauerhaft aufrecht erhalten, sodass der Master sie aktiv mit Updates versorgen kann, ist folgendes zu beobachten: Fällt in einem bestehenden WriteQuorum der Master aus, melden die Slaves, dass der Master nicht erreichbar ist, da ihre bestehende Verbindung gekappt wurde, trennen anschliessend mittels ldap unbind() die entsprechende Verbindung, beenden die Synchronisation und geben alle Ressourcen wie etwa den Socket wieder frei. An diesem Verhalten muss für die Nutzung von Ubiksync nichts verändert werden, ausser die Anpassung der Fehlermeldung. Beim Ausfall eines Slaves mit anschliessender Quorumauflösung aufgrund unzureichender Hostan- 62

63 Abbildung 20: Ausfall des Masters zahl gelangt, wie zu sehen war, jeder Slave schliesslich in den VOTING-State und beendet damit ohnehin seine syncrepl-tasks und damit auch die Verbindung zum Master, sodass nach einer Neuwahl ein neuer dauerhafter (persistent) Syncrequest ohne Komplikationen gestartet werden kann. Bei der Aufrechterhaltung des Quorumns nach einem Klientenausfall gelangen die Slaves zwischenzeitlich in den UBIK-NULL QUORUM-State. Durch das Mapping in den Ubiksync-State VOTING wird auch hier die SyncRequest-Verbindung getrennt, bevor sie von neuem initialisiert und der Request mit gleichen Attributen gestartet wird. Damit ist auch hier kein Fehlverhalten zu erwarten. Wenn ein neuer Server in ein bestehendes Writequorum eintreten will, selbst aber sowohl die aktuelle Version als auch die niedrigste Hostlistenposition besitzt, kommt es auch hier auf jeden Fall zum Masterwechsel. Durch den Versionsaustausch nach dem Start von A und dem anschliessendem Quorumtimeout aufgrund unzureichender Stimmen für B nehmen die beiden bisherigen Quorumteilnehmer nach einer gewissen Zeit den VOTING-Zustand ein, setzen die entsprechenden Datenbankrestriktionen und C leert zusätzlich seine syncrepl-taskliste. Beide wählen anschliessend A als neuen Master, initialisieren den syncinfo-struct sowie die Syncrepl-Taskliste und starten mittels do syncrepl() den Synchronisationsvorgang. Auch hier ist funktional kein Unterschied zur Nutzung des RefreshOnly-Modes erkennbar. Erwähnenswert ist jedoch, dass der syncrepl-task, also die dauerhafte Verbindung zum Master, beim Übergang in den Voting-State auf jeden Fall getrennt werden muss, auch wenn der ehemalige Master weiterhin läuft, damit seine Verbindungspunkte (Sockets) wieder freigegeben werden können Behandlung von ungünstigen Konstellationen Sowohl im RefreshOnly- als auch im RefreshAndPersist-Modus kommt es zu einem Problem, wenn der aktuelle Server A ein bestehendes Writequorum eintritt und kurz darauf (innerhalb SMALL SECONDS) der bisherige Master B abstürzt. Da A nach dem Versionsaustausch von allen Servern als SmaxDBminPos erkannt wird, bekommt B keine VOTE YES-Stimmen mehr. Nachdem B etwa durch einen Ausfall nicht mehr erreichbar ist, hat er auch keine Gelegenheit, nach dem 63