Apache Zookeeper

1

Apache Zookeeper ¨ Ein Uberblick

Philipp Abraham Seminararbeit Software Systems Engineering - WS 2012 / 2013

Zusammenfassung—In dieser Ausarbeitung soll Apache ZooKeeper beschrieben werden. ZooKeeper ist ein Dienst, der es vereinfacht Prozesse in verteilten Systemen zu koordinieren. Dabei wird eine Dateisystem-¨ahnliche Schnittstelle geboten, die ¨ zentral und repliziert verfugbar ist. Mit den Garantien, dass ¨ Anfragen eines Clients in FIFO-Manier ausgefuhrt werden und dass Ver¨anderungen am Zustand des ZooKeeper Dienstes linearisierbar sind, lassen sich Standard-Konstrukte – wie beispielsweise Locks, Barriers, Leader-Election – schnell und weniger fehleranf¨allig implementieren. Leseanfragen von Clients k¨onnen dabei aus lokalen Servern gelesen werden und Clients k¨onnen ¨ Daten cachen, da eine Invalidierung uber Events vom Server m¨oglich ist. Die getroffenen Design-Entscheidungen erm¨oglichen High-Performance Applikationen mit mehreren hunderttausend Anfragen pro Sekunde.

¨ I. E INF UHRUNG In Verteilten Systemen ist es oft n¨otig bestimmte Prozesse zu koordinieren. Beispielweise k¨onnten feste oder dynamische Konfigurationsparameter unter verschiedenen Servern synchronisiert werden m¨ussen. Gruppen von gleichartigen Prozessen m¨ussen oft gebildet werden, um zum Beispiel festzustellen, welche Server noch verf¨ugbar oder gerade mit einer bestimmten Aufgabe besch¨aftigt sind. H¨aufig ist es auch n¨otig einen “Master-Server” zu bestimmen unter allen verf¨ugbaren. Sich dynamisch auf solch einen zu einigen wird als Leader-Election bezeichnet. Ein Leader kann dann auch verwendet werden um Locks zu realisieren. Also exklusive Zugriffsrechte auf eine bestimmte Ressource. Da die Programmierung solche Koordinierungsdienste nicht immer trivial ist und schnell RaceConditions und Deadlocks entstehen k¨onnen, bietet es sich an ein Framework wie Apache ZooKeeper zu benutzen, dass diese Dienste anbietet. ZooKeeper entstand urspr¨unglich als Teil von Apache Hadoop [1], ist jetzt aber ein eigenes Projekt, dass auch von großen Firmen wie Yahoo und Rackspace und Projekten wie Eclipse und Solr genutzt wird [2]. Im Folgenden soll zun¨achst die Grundlegende Struktur des ZooKeeper Dienstes erl¨autert werden um dann mithilfe der durch ZooKeeper gegebenen Garantien und der Client-API beispielhafte Strukturen zur Prozesskoordinierung zu beschreiben. Diese Arbeit basiert zu gr¨oßten Teilen auf Informationen aus der Apache ZooKeeper Dokumentation [3] und einem von Yahoo Mitarbeitern 2010 publiziertem Paper [4]. II. AUFBAU DES Z OOKEEPER D IENSTES ZooKeeper ist ein Dienst, der auf einem oder mehreren Servern l¨auft und eine Client API anbietet um Koordinierungsaufgaben zu realisieren. Mehrere Server werden unter dem Begriff “Ensemble” zusammengefasst und automatisch

untereinander abgeglichen. Ein Server im Ensemble muss der so genannte “Leader” sein. Die anderen sind dann Follower und senden zur globalen Linearisierung jeden Schreibzugriff an den Leader (siehe Abbildung 1). Um alle Replikas synchron zu halten und auf Ausfall von Servern zu reagieren, wird der Ansatz der “State Machines” verwendet a¨ hnlich wie er 1990 von Schneider [5] beschrieben wurde. Dieser besagt, dass ein Dienst einen Zustand hat, der bei allen Replikaten gleich zu halten ist, indem alle zustandsver¨andernden Operationen auf allen Replikaten gleich angewendet werden. Dazu wird hier eine abgewandelte Form des Paxos Algorithmus von Lamport [6] verwendet um einen Konsens zu erreichen. Will ein Client den Zustand des ZooKeeper Dienstes a¨ ndern, so ist, um Fehler zu vermeiden, ein Konsens der Mehrheit des Ensembles n¨otig (weshalb es sich auch anbietet eine ungerade Anzahl an Servern bereitzustellen). Um den Zustand des Systems auch bei totalem Ausfall wiederherstellen zu k¨onnen wird ein “writeahead” Log benutzt. Es werden also alle Zustands¨anderungen in dieses Log geschrieben, bevor sie im System angewendet und verteilt werden. Aus Performance-Gr¨unden sollte dieses Log-File auf einem separaten Speichermedium liegen. Abbildung 1.

Aufbau des ZooKeeper Dienstes ZooKeeper Ensemble Leader

Server

Client

Client

Server

Client

Server

Client

Server

Client

Client

Datenstruktur ¨ Uber die Client-API k¨onnen Clients auf die abstrakte Datenstruktur des ZooKeeper Dienstes zugreifen. Diese ist als hierarchischer Namensraum in Baumstruktur realisiert a¨ hnlich eines UNIX-Dateisystems. Knoten in diesem Baum (auch “data-tree” genannt) werden als zNodes bezeichnet. Der Pfad zu einem zNode wird dabei wie in UNIXSystemen angegeben, beginnend mit dem Wurzelelement /. Beispielsweise wird ein Pfad zu Knoten C u¨ ber B und A notiert als /A/B/C (siehe auch Abbildung 2). ZooKeeper ben¨otigt zudem immer absolute Pfadangaben. Im Unterschied zu UNIX kann hier jeder zNode auch Daten enthalten. Da ZooKeeper nur f¨ur die Koordinierung von Prozessen und nicht f¨ur die Verwaltung von Anwendungsdaten konzipiert wurde, ist die Menge an Daten f¨ur zNodes auf

2

jeweils 1 Megabyte begrenzt. Diese Grenze sollte in der Praxis jedoch nicht ausgereizt werden, da die Performance des ZooKeeper Dienstes maßgeblich von der Menge der Daten in den zNodes abh¨angt. zNodes Grundlegend gibt es zwei Arten von zNodes: Persistent zNodes k¨onnen vom Client explizit erzeugt, ver¨andert und gel¨oscht werden. Sie k¨onnen Subknoten/-b¨aume haben und Daten beinhalten. Ephemeral zNodes unterscheiden sich durch die Tatsache, dass sie mit Beenden der Session des Clients, der sie erzeugt hat, automatisch gel¨oscht werden. Außerdem k¨onnen ephemeral zNodes keine Kind-Elemente haben.

Abbildung 2.

Visualisierung eines ZooKeeper Namensraums

Außerdem kann ein Client bei der Erzeugung eines Knotens ein sequential Flag setzen, welches automatisch eine Sequenznummer an den Namen des Knotens h¨angt. Es wird garantiert, dass alle Knoten auf der gleichen Ebene (also alle Knoten mit dem selben Eltern-Knoten) keine gr¨oßere Sequenznummer im Namen haben k¨onnen. Die Sequenznummern werden als 10 Stellige Zahl mit ZeroPadding dargestellt. Beispiel: /myApp/sequence/element-0000000001 Zus¨atzlich zu den optionalen Nutzdaten speichert ZooKeeper automatisch einige Meta-Daten (genannt Stat) zu jeder zNode; dazu geh¨oren Zeitstempel (in Sekunden seit der letzten Epoche), ACLs (siehe n¨achster Absatz) und Versionsinformationen. Diese werden standardm¨aßig beispielsweise dazu genutzt, statusver¨andernde Operationen auf zNodes nur dann durchzuf¨uhren wenn sich zwischenzeitlich die Versionsnummer nicht ge¨andert hat. Außerdem erm¨oglichen sie Lock-freies Lesen von Daten - selbst wenn andere Transaktionen auf diesem Datum gerade laufen - nach dem MVCC (Multiversion Concurrency Control) Prinzip welches erstmals von Reed 1978 beschrieben wurde [7]. Access Control Lists Um den Zugriff auf einzelne zNodes zu beschr¨anken hat jeder Knoten eine so genannte Access Control List (ACL) a¨ hnlich der in UNIX verwendeten Zugriffskontrolle f¨ur Dateien. Im unterschied zu Unix existieren aber keine festen Rollen wie Owner und Group. Stattdessen besteht ein ACL aus einer Menge IDs mit zugeordneten Rechten. F¨ur die

Authentifizierung von Benutzen steht ein modulares System zur Verf¨ugung, dass es erm¨oglicht eigene Authentifizierungsmechanismen einzubinden. Folgende Rechte k¨onnen dabei ver¨andert werden: CREATE: Kindknoten d¨urfen erzeugt werden. READ: Daten des Knotens d¨urfen gelesen und die Kinder aufgelistet werden WRITE: Daten des Knoten d¨urfen geschrieben werden DELETE: Kindknoten d¨urfen gel¨oscht werden ADMIN: Rechte d¨urfen gesetzt werden Sobald sich ein Client mit ZooKeeper verbindet, authentifiziert er sich gegen¨uber dem Server und bekommt alle zugeh¨origen IDs zugeordnet. Will der Client nun auf einen zNode zugreifen werden dessen ACLs mit der ID des Clients u¨ berpr¨uft. Eine ACL ist aufgebaut als Tupel (scheme:expression, perms). Das Format der expression ist dabei spezifisch zum gew¨ahlten Authentifizierungsschema scheme. Einige Mechanismen sind bereits eingebaut; beispielweise die Authentifizierung mittels IP, Hostname oder einer einfachen Benutzername:Passwort Kombination. Es existieren jedoch Projekte die sicherere Methoden nutzen; beispielsweise Anbindung an ein Kerberos [8] System mittels SASL [9]. Watches ¨ Damit Clients u¨ ber Anderungen am Datenmodell informiert werden ist kein Polling n¨otig. Stattdessen bietet ZooKeeper mit dem Prinzip der “Watches” einen event-basierten PublishSubscribe Mechanismus um vom Server informiert zu werden. Wird ein Watch auf einen Knoten gesetzt, wird der Client einmalig informiert, wenn sich der Zustand eines Knotens ge¨andert hat. Wie sich ein Knoten ge¨andert hat wird jedoch ¨ nicht u¨ bergeben. Um fortlaufend bei Anderungen eines bestimmten zNodes informiert zu werden muss also bei der Verarbeitung eines Events ein neues Watch gesetzt werden. Dabei ist zu beachten, dass nicht garantiert werden kann, ¨ dass der Client u¨ ber alle Anderungen zwischen dem Empfang eines Events und dem Neu-setzen einer Watch informiert wird. zNodes werden im Hauptspeicher des Servers gehalten, um Lesezugriffe zu beschleunigen. Trotzdem sollten Daten f¨ur eine Optimale Geschwindigkeit auf den Clients gecached werden. Beispielsweise k¨onnte der aktuelle Leader lokal beim Client gespeichert sein. Wird im System der aktuelle Leader immer in einem bestimmten zNode notiert, k¨onnen Clients ein Watch auf diesen setzen, um dann ihre zwischengespeicherte Version zu invalidieren sollte sich der Wert a¨ ndern. Sessions Baut ein Client eine Verbindung zu einem Server auf, wird eine Session erstellt. Sessions besitzen einen Timeout. Wird dieser u¨ berschritten gilt der Client als fehlerhaft. Dazu Innerhalb der Session kann ein Client mittels Watches und synchronen Operationen den Zustand des Systems beobachten und beeinflussen. Sessions sind persistent innerhalb des ZooKeeper Dienstes und erm¨oglichen somit die transparente

3

Weitergabe an andere Server sollte der aktuell zu einem Client ¨ zugeordnete ausfallen. Diese Ubergabe an einen Server des Ensembles geschieht automatisch im Fehlerfall und ben¨otigt in der Regel nur wenige Millisekunden und st¨ort somit den operativen Betrieb im besten Fall nicht. III. G ARANTIEN Um mit ZooKeeper verteilte Anwendungen zu koordinieren, ist wichtig die Garantien innerhalb des ZooKeeper Protokolls zu kennen. Linearisierbare Schreibvorg¨ange: Alle Vorg¨ange die den Zustand des ZooKeeper Dienstes ver¨andern werden unter Beachtung der Reihenfolge (am Leader) linearisiert. Realisiert wird dies durch ein Atomic “Broadcast Protocol” names Zab [10]. FIFO Client Abarbeitung: Alle Anfragen eines Clients werden in der Reihenfolge bearbeitet in der sie abgesandt wurden. Atomare Operationen Lese- und Schreiboperationen in ZooKeeper sind atomar. Das heißt, es wird immer der gesamt Inhalt gelesen bzw. ver¨andert. Da nur Updates linearisiebar sind k¨onnen Lesevorg¨ange aus dem lokalen Server geliefert werden. Damit skaliert ZooKeeper linear in Bezug auf die Anzahl der Server (Replikate). Watches • Watches sind geordnet bez¨uglich anderen Events, Watches und asynchronen Antworten. ZooKeeper sorgt f¨ur die Einhaltung der Reihenfolge. • Setzt ein Client ein Watch auf ein zNode, so bekommt dieser Client im Falle einer Daten¨anderung das Watch Event bevor er die neuen Daten sieht. • Die Reihenfolge der Watch-Events korrespondiert zu der Reihenfolge der Updates auf dem ZooKeeper Server. Um die Bedeutung dieser Garantien zu verdeutlichen soll folgendes Beispiel betrachtet werden: Ein verteiltes System, bestehend aus vielen Prozessen, soll einen Leader w¨ahlen. Dieser muss dann einige Konfigurationen anpassen und danach alle anderen Prozesse informieren, damit diese die neuen Parameter nutzen k¨onnen. Wichtig sind f¨ur diesen Vorgang zwei Anforderungen: • Andere Prozesse sollen die neuen Parameter erst nutzen ¨ sobald der Leader vollst¨andig mit seinen Anderungen fertig ist. • Falls der neue Leader aufgrund eines Fehlers vor Beendigung der Parameteranpassungen stirbt, sollen andere ¨ Prozesse die unvollst¨andigen Anderungen nicht nutzen. Mit ZooKeeper k¨onnte ein ready zNode eingef¨uhrt werden, welcher anzeigt, dass die Konfigurationsparameter von allen Prozessen genutzt werden k¨onnen. Wird ein neuer Leader bestimmt l¨oscht er diesen Knoten, sendet asynchron al¨ le Anderungsw¨ unsche ab und erzeugt wieder einen ready Knoten. Angenommen jede Anfrage w¨urde 5ms dauern und es m¨ussten 4000 Knoten ge¨andert werden, dann w¨urde dieser Vorgang bei synchroner Abarbeitung 20 Sekunden dauern. Durch die von ZooKeeper geleisteten Garantien kann das absetzen

¨ der Anderungen asynchron erfolgen und Clients k¨onnen alle ¨ Anderungen sehen sobald der ready Knoten verf¨ugbar ist. Was jedoch wenn ein Client einen alten ready Knoten sieht und anf¨angt die Konfigurationsparameter zu lesen w¨ahrend der neue Leader den ready zNode entfernt und die Konfiguration a¨ ndert? Da jedoch garantiert ist, dass Clients in der Reihenfolge der Updates Benachrichtigungen erhalten, sieht auch ein Client der ¨ ein Watch auf ready hat, die Anderung dieses Knotens bevor er ge¨anderte Konfigurationsparameter einlesen w¨urde. Abbildung 3. Schreibzugriffe werden an einen lokalen Server gesendet. Von dort zum Leader, in das Transaktionslog und u¨ ber einen atomaren Broadcast zur Mehrheit des Ensembles. Erst dann kann eine Antwort herausgegeben werden. Weitere anfragen k¨onnen dann wieder aus der im Speicher liegenden lokalen Datenbank der Server beantwortet werden.

IV.

C LIENT API

Die wichtigsten Methoden der Client API [11] sollen hier kurz vorgestellt werden um sp¨atere Beispiele nachvollziehen zu k¨onnen. Die Client APIs sind in den von Apache ZooKeeper angebotenen Bindings als C oder Java Variante verf¨ugbar. Es werden jeweils blockierende oder asynchrone Varianten von allen Operationen angeboten. Außerdem existieren weitere inoffizielle Bindings beispielsweise f¨ur Ruby [12], Node.js [13], PHP [14], Scala [15] und Weitere. create(path, data, acl, flags): Erzeugt einen neuen zNode mit Namen path und Inhalt data. Der Parameter flags bestimmt den Knoten-Typ (ephemeral oder persistent) und erm¨oglicht setzen des sequence Flags. acl ist die “Access Control List” f¨ur den neuen Knoten. delete(path, version): L¨oscht den Knoten path insofern die Version u¨ bereinstimmt und keine Kind-Knoten vorhanden sind. exists(path, watch): Gibt ein Meta-Daten Objekt (Stat) zur¨uck falls ein Knoten mit angegebenem Pfad existiert und null sonst. Wird watch auf true gesetzt wird der ¨ Client u¨ ber eine Anderung an diesem Knoten informiert. getData(path, watch): Liefert ein Byte-Array der Daten im angegebenen Knoten. setData(path, data, version): Setzt den Inhalt des angegebenen Knotens auf data falls die Version u¨ bereinstimmt. getChildren(path, watch): Liefert eine Liste der Pfade aller Kind-Knoten des angegebenen Knotens. sync(path, callback): Wartet auf eine Synchronisierung und benachrichtigt dann u¨ ber den callback .

4

Jede dieser Operationen ist noch in einer asynchronen Variante verf¨ugbar, welcher dann zus¨atzlich ein Callback-Objekt u¨ bergeben werden muss. Operationen die nur bei u¨ bereinstimmender Versionsnummer ¨ ausgef¨uhrt werden, k¨onnen durch Ubergabe der Versionsnummer -1 dazu gezwungen werden immer ausgef¨uhrt zu werden. Falls ein Watch gesetzt werden soll kann meist entweder einfach true u¨ bergeben werden und der bei Initiierung der Session angegebene default Watcher wird benutzt. Alternativ l¨asst sich auch ein Objekt vom Typ Watcher angeben, welches lediglich die Methode process(WatchedEvent event) implementieren muss. Ein WatchedEvent kann dabei vom Typ NodeChildrenChanged, NodeCreated, NodeDataChanged, NodeDeleted oder None sein. V.

P RIMITIVES

In diesem Abschnitt sollen exemplarisch Ans¨atze gezeigt werden, wie in ZooKeeper komplexere Primitive f¨ur die Koordination von Prozessen implementiert werden k¨onnen. Der ZooKeeper Dienst selbst weiß nichts von der Existenz dieser Konstrukte. Eine Realisierung erfolgt in den Clients mithilfe der API. A. Group Membership F¨ur die Bildung von Gruppen k¨onnen ephemeral zNodes ausgenutzt werden. Zun¨achst muss ein persistenter zNode mit dem Namen der Gruppe erstellt werden. Jedes Mitglied erstellt nun ein ephemeral zNode unterhalb dieses GruppenKnotens und vergibt als Namen seine ID (falls keine eindeutigen Namen garantiert sind kann auch das sequence Flag genutzt werden). Verl¨asst ein Mitglied die Gruppe (sei es durch Verbindungsabbruch oder freiwillig) so existiert auch kein Knoten mehr f¨ur public void join(String groupName, String memberName) throws KeeperException, InterruptedException { String path = "/" + groupName + "/" + memberName; String createdPath = zk.create(path, null/*data*/, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); System.out.println("Created " + createdPath); }

Um alle Mitglieder einer Gruppe aufzulisten muss dann lediglich getChildren() aufgerufen werden: public void list(String groupName) throws KeeperException, InterruptedException { String path = "/" + groupName; try { List children = zk.getChildren(path, false); if (children.isEmpty()) { System.out.printf("No members in group %s\n", groupName); return; } for (String child : children) { System.out.println(child); } } catch (KeeperException.NoNodeException e) {

System.out.printf("Group %s does not exist\n", groupName); } }

B. Service Directory Service Directories k¨onnten mit ZooKeeper wie folgt realisiert werden: Ein Dienst registriert sich beim Server, indem er einen ephemeral zNode mit seinem Namen erstellt und ¨ eventuell Konfigurationsdaten in diesen Knoten eintr¨agt. Uber den gleichen Ansatz wie beim Group Membership k¨onnten auch Kategorisierungen vorgenommen werden. Ein Client kann nun mit getChildren(’/category’,true) die angebotenen Dienste abrufen und wird automatisch informiert wenn neue Dienste hinzukommen. Durch die gew¨ahlte Repr¨asentation werden Dienste im data-tree gel¨oscht, sobald sie nicht mehr erreichbar sind und Clients werden umgehend informiert falls sie ein entsprechendes Watch gesetzt hatten. C. Barriers Barrieren werden beispielsweise genutzt, um die Verarbeitung von mehreren Prozessen zu blockieren bis eine bestimmte Bedingung erf¨ullt ist. Dieses Prinzip wird beispielsweise verwendet um Schleifen in parallelen Sprachen zu realisieren. Der Code nach der Schleife darf erst ausgef¨uhrt werden, wenn alle beteiligten Prozesse die Schleifenabbruchbedingung erf¨ullt haben. Analog dazu werden Doppel-Barrieren genutzt um Prozesse zu starten wenn eine gewisse Anzahl an Knoten die Barriere betritt und folgende Operationen erst erlaubt wenn alle Prozesse die Barriere verlassen haben. In ZooKeeper k¨onnte ein zNode b eine Barriere repr¨asentieren und Prozesse darunter jeweils Knoten pi erzeugen wenn sie die Barriere betreten m¨ochten. Bei Betreten setzt jeder Prozess ein Watch auf b. Ist die gew¨unschte Anzahl an Prozessen bereit (hat also Subknoten erstellt), beginnt die Operation. Ist ein Prozess mit der Verarbeitung fertig, l¨oscht er seinen Knoten. Sind alle Knoten gel¨oscht, k¨onnen alle Prozesse die Barriere verlassen. D. Locks Mit Locks k¨onnen exklusive Zugriffe auf Ressourcen realisiert werden. Lediglich ein Prozess darf zeitgleich Zugriff auf den kritischen Bereich haben. Eine einfache Realisierung w¨are, ein ephemeral zNode zu erstellen wenn man einen exklusiven Bereich betritt. Vorher wird geschaut, ob solch ein zNode bereits existiert. Wollen nun Zeitgleich mehrere Prozesse das Lock, setzen sie ein Watch und werden benachrichtigt wenn dies frei wird. Problematisch bei dieser Implementierung ist das Auftreten des so genannten “Herd Effects”. Es werden n¨amlich alle Prozesse, welche auf das Lock warten zeitgleich informiert und der Kommunikationskanal geflutet mit Benachrichtigungen. Um diesen Effekt zu vermeiden k¨onnten sich wartende Prozesse mit ephemeral sequence zNodes registrieren. Statt ein Watch auf den Besitzer des Locks zu setzen wird ein Watch auf

5

den wartenden Knoten gesetzt, der sich zuvor eingereiht hat. ¨ Damit wird bei Ubergabe des Locks nur jeweils ein Prozess benachrichtigt. Stirbt ein Prozess in der Warteschlange so bekommt der Nachfolgende dies mit und kann ein Watch auf den Vorg¨anger des fehlerhaften Prozesses setzen. VI.

E VALUATION

Das Yahoo Research Center hat Benchmarks durchgef¨uhrt um die Performance des ZooKeeper Dienstes unter m¨oglichst realen Bedingungen zu erproben [4]. Dabei wurde die Anzahl der Server des Ensembles variiert, die Anzahl der Clients jedoch konstant bei 250 gehalten. Das ZooKeeper System wird unter S¨attigung analysiert, wobei verschiedene Verh¨altnisse von Schreiben zu Lesen betrachtet werden. Jeder Client hat mindestens 100 ausstehende Anfragen. Eine Anfrage ist dabei eine Leseoperation oder eine Schreiboperation mit jeweils 1K an Daten. Abbildung 4.

m¨ussen, wurden Abstraktionsebenen entwickeln, die auf die ZooKeeper API aufsetzen. Haupts¨achlich vereinfachen diese das Error-Handling. Beispielsweise verbindet sich ein Client mit dem ZooKeeper Server durch einen Handshake. Dies geschieht asynchron. Werden nun synchrone Befehle an den Server gesendet bevor der Handshake abgeschlossen ist, liefern diese Operationen eine Fehlermeldung. Es muss also immer sichergestellt werden, dass synchrone Operationen erst abgesetzt werden, wenn dieser Handshake abgeschlossen ist. Auch muss oft die Funktionalit¨at implementiert werden, nach einem Timeout die aktuelle Operation nochmals zu Wiederholen. Dabei ist es unter Umst¨anden auch wichtig, nicht permanent erneute Versuche zu starten, da dies die anderen Clients potenziell auch tun und so das Netz m¨oglicherweise zu stark belasten. Verschiedene Strategien wie eine Obergrenze an Neuversuchen, ein Zeitlimit oder auch Neuversuche mit zuf¨alligen Zeitabst¨anden k¨onnten implementiert werden. Die Java Bibliothek Curator von Netflix [16] ist eine M¨oglichkeit, solche Fehlerf¨alle leichter zu behandeln. Curator ist ein Framework, dass auf die auf die ZooKeeper API aufsetzt und sie mit h¨aufig verwendeten Helfer-Methoden und vielen bereits implementieren Rezepten f¨ur Primitive komplettiert. Die im vorigen Absatz genannten Beispiele f¨ur wiederkehrende Implementierungen zur Fehlerbehandlung werden durch die Curator API stark vereinfacht. VIII.

Der Durchsatz steigt dabei mit dem Prozentsatz an Leseoperationen, da jede schreibende Operation durch den Leader gesendet wird und ein Konsens u¨ ber das Atomic Broadcast Protocol erreicht werden muss. Es ist auch erkannbar, dass mehr Server im Ensemble den Durchsatz negativ beeinflussen bei schreibenden Vorg¨angen. Urs¨achlich daf¨ur ist, dass jeder Server einen Abstimmenden Kandidaten f¨ur das Konsensprotokoll darstellt und somit mehr Stimmen eingeholt werden m¨ussen bei Schreiboperationen. Des Weiteren konnte ermittelt werden, dass falls der aktuelle Leader ausf¨allt, ein neuer Leader binnen 200ms gew¨ahlt ist. Typische Koordinierungsaufgaben in Verteilten Systemen erfordern jedoch meist deutlich mehr Lese- als Schreibvorg¨ange und k¨onnen somit von mehreren hunderttausend Operationen pro Sekunde profitieren. VII.

Apache ZooKeeper erm¨oglicht die Koordination verteilter Prozesse. Bei Anwendungen die durch Leseoperationen dominiert werden, sind Durchs¨atze mit hunderttausenden von Operationen pro Sekunde durch die Nutzung von lokalen Replikas mit im Hauptspeicher gehaltenen Datenbanken m¨oglich. Eine Dateisystem-¨ahnliche Schnittstelle erm¨oglicht schnelle Implementierungen verschiedenster Koordinierungskonstrukte. ZooKeeper bietet transparente Synchronisierung eines ServersClusters und erm¨oglicht fehlertolerante verteilte Applikationen mit wenig Programmieraufwand. L ITERATUR [1] [2] [3] [4]

[5]

¨ Z US ATZLICHE A BSTRAKTION

Um ZooKeeper noch leichter benutzbar zu machen und immer wiederkehrende Konzepte nicht neu implementieren zu

Z USAMMENFASSUNG

[6]

“Apache hadoop (abgerufen am 16. jan ’13),” http://hadoop.apache.org/. “Applications and organizations using zookeeper (abgerufen am 16. jan ’13),” http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy. “Zookeeper: Because coordinating distributed systems is a zoo (abgerufen am 16. jan ’13),” http://zookeeper.apache.org/doc/trunk/. P. Hunt, M. Konar, F. P. Junqueira, and B. Reed, “Zookeeper: wait-free coordination for internet-scale systems,” in Proceedings of the 2010 USENIX conference on USENIX annual technical conference, ser. USENIXATC’10. Berkeley, CA, USA: USENIX Association, 2010, pp. 11–11. [Online]. Available: http://dl.acm.org/citation.cfm? id=1855840.1855851 F. B. Schneider, “Implementing fault-tolerant services using the state machine approach: a tutorial,” ACM Comput. Surv., vol. 22, no. 4, pp. 299–319, Dec. 1990. [Online]. Available: http://doi.acm.org/10.1145/ 98163.98167 L. Lamport, “The part-time parliament,” ACM Trans. Comput. Syst., vol. 16, no. 2, pp. 133–169, May 1998. [Online]. Available: http://doi.acm.org/10.1145/279227.279229

6

[7] [8] [9] [10]

[11] [12] [13] [14] [15] [16]

D. P. Reed, “Naming and synchronization in a decentralized computer system,” Cambridge, MA, USA, Tech. Rep., 1978. “The mit kerberos consortium (abgerufen am 19. jan ’13),” http://www. kerberos.org/. “Zookeeper and sasl (abgerufen am 19. jan ’13),” https://cwiki.apache. org/ZOOKEEPER/zookeeper-and-sasl.html. B. Reed and F. P. Junqueira, “A simple totally ordered broadcast protocol,” in Proceedings of the 2nd Workshop on Large-Scale Distributed Systems and Middleware, ser. LADIS ’08. New York, NY, USA: ACM, 2008, pp. 2:1–2:6. [Online]. Available: http://doi.acm.org/10.1145/1529974.1529978 “Apache zookeeper 3.4.5 api (abgerufen am 16. jan ’13),” http:// zookeeper.apache.org/doc/r3.4.5/api/index.html. “Zk ruby interface (abgerufen am 16. jan ’13),” https://github.com/ slyphon/zk. “Node-zookeeper (abgerufen am 16. jan ’13),” https://github.com/ yfinkelstein/node-zookeeper. “Php-zookeeper (abgerufen am 16. jan ’13),” http://pecl.php.net/ package/zookeeper. “Scala-zookeeper (abgerufen am 16. jan ’13),” https://github.com/ twitter/scala-zookeeper-client. “Netfilx curator: Zookeeper client wrapper and rich zookeeper framework (abgerufen am 18. jan ’13),” https://github.com/Netflix/curator.