Konsistenzproblematik bei der Cloud-Datenspeicherung

Transkript

1 Konsistenzproblematik bei der Cloud-Datenspeicherung Adrian Zylla Fachhochschule Aachen Fachbereich Elektrotechnik und Informationstechnik Eupener Straße 70, Aachen Zusammenfassung Die Seminararbeit beschäftigt sich mit der Konsistenzproblematik in der Cloud. Zu Beginn wird eine Einführung in die Cloud sowie in die Ursachen der Konsistenzproblematik gegeben. Im Anschluss daran wird ein Theorem vorgestellt, welches den Beweis liefert, dass in der Cloud eine gewisse Zeitspanne der Inkonsistenz herrschen muss. Danach wird das Konsistenzmodell vorgestellt, welches in der Cloud im Einsatz ist. Zum Abschluss werden Verfahren erläutert, die die Zeitspanne der Inkonsistenz analysieren und auswerten. Key words: Cloud Computing, Amazon S3, Eventual Consistency, Letztendliche Konsistenz 1 Einleitung Die Cloud hat in den letzten Jahren immer mehr an Bedeutung gewonnen, sowohl bei den Firmen als auch bei Privatanwendern. Die Daten lassen sich nämlich kostengünstig und skalierbar speichern. Die Datenspeicherung unterscheidet sich jedoch von den klassischen Datenbanksystemen. Damit die Daten immer verfügbar und vor Ausfällen gesichert sind, speichert die Cloud die Daten auf mehrere Server verteilt. Dies hat zur Folge, dass die Replikationen nicht immer konsistent sind. Ein Schreibzugriff aktualisiert als allererstes nur eine Replikation. Bis die weiteren Replikationen aktualisiert werden, vergeht eine gewisse Zeit. In dieser Zeit sind die restlichen Replikationen inkonsistent. Die Cloud kann deshalb, anders als die Datenbank, keine strikte Konsistenz anbieten. Es kann nur eine letztendliche Konsistenz (Eventual Consistency) garantiert werden. Dieser Sachverhalt wird in der Ausarbeitung nun genauer beschrieben. (vgl. [13])

2 2 Konsistenzproblematik bei der Cloud-Datenspeicherung 2 Cloud Die Cloud ist ein virtueller Bereich, in dem Speicher- und Rechenkapazität bereitgestellt werden. Der virtuelle Bereich befindet sich im Internet und lässt sich von mehreren Endanwendern bearbeiten. Somit sind Clouds virtuelle Ablagen, deren Bestimmungsort unbekannt ist. Für die Endanwender ist die Cloud nicht fassbar und nur durch Schnittstellen nutzbar. Der Provider hingegen hat den Überblick über die gesamte Sicht und kümmert sich um die Wartung und das Angebot. Die in der Cloud abgelegten Dateien und Programme lassen sich mittels Cloud-Computing ausführen. Die erhaltenen Ergebnisse können wiederum in der Cloud gesichert werden. Die Dienste, die im Cloud-Computing angeboten werden, erstrecken sich auf das komplette Spektrum der Informationstechnik. (vgl. [1], [2], [3]) Das National Institute for Standards and Technology (NIST) veröffentlichte eine Definition, die das Cloud-Computing in drei Servicemodelle unterteilt [4]: SaaS Das Modell Software as a Service (SaaS) wird auch als Software on demand (Software bei Bedarf) bezeichnet, da der Provider seine Software- Sammlung und Anwendungsprogramme in der Cloud zur Nutzung bereitstellt. PaaS Das Modell nennt sich Platform as a Service (PaaS). Auf dieser Plattform kann der Endanwender eigene Software-Anwendungen in der Cloud betreiben. Der Provider liefert dafür sowohl Softwareumgebungen als auch den Zugriff auf die deployte Anwendung. IaaS Bei diesem Modell handelt es sich um das Infrastructure as a Service (IaaS). Der Provider bietet dem Endanwender virtuelle Ressourcen wie etwa Rechner, Speicher und Netzwerke an. Mithilfe der Ressourcen kann ein eigener Server mit einem vom Nutzer gewählten Betriebssystem betrieben werden. Der Endanwender ist somit für die Installation, den Betrieb und das Funktionieren der Komponenten selbst verantwortlich. (vgl. [4], [5]) Die vorgestellten Servicemodelle entsprechen im Cloud-Computing den unterschiedlichen funktionalen Abstraktionsebenen. Die Abstraktionsebenen bilden die Cloud-Computing-Architektur, die die Form einer Pyramide hat (siehe Abbildung 1). Im Kontext meiner Arbeit sind nur die Abstraktionsebenen PaaS und IaaS relevant, da es nur dort zur Konsistenzproblmematik kommen kann. Der Grund hierfür soll kurz erläutert werden. SaaS ist komplett in Provider-Hand, deswegen kann der Provider die Konsistenz der Daten gewährleisten. Ein weiterer Grund ist der folgende: Für PaaS und IaaS bietet das Cloud-Computing eine Skalierbarkeit an indem in Abhängigkeit vom Workload weitere Instanzen automatisch hinzu- bzw. abgeschaltet werden. Um die Ausfallsicherheit im

3 Konsistenzproblematik bei der Cloud-Datenspeicherung 3 Cloud-Computing zu gewährleisten, werden die Instanzen in mehreren Rechenzentralen repliziert. Die Replikation und das Starten mehrer Instanzen führt uns zu der Konsistenzproblematik. (vgl. [6]) Abbildung 1. Cloud-Computing-Architektur [5] 3 CAP-Theorem Im vorigen Abschnitt wurde erläutert, dass in der Cloud eine Konsistenzproblematik besteht. Es stellt sich jedoch die Frage, warum dem so ist. Die Antwort darauf wird uns das CAP-Theorem geben, welches für verteilte Systeme entwickelt wurde. Im Jahre 2000 stellte Eric A. Brewer in einer Keynote das Theorem vor [7]. Das Akronym CAP steht für die folgenden drei Eigenschaften: Consistency (Konsistenz) Die Clients sehen stets dieselben Daten in der Cloud. Zu keiner Zeit erhalten zwei Clients eine unterschiedliche Antwort auf dieselbe Anfrage. Availability (Verfügbarkeit) Wenn in der Cloud Knoten (Server) ausfallen, ist die Funktionsfähigkeit weiterhin gewährleistet. Die verbleibenden Knoten kompensieren den Ausfall mithilfe von Daten-Replikationen. Partition Tolerance (Partitionstoleranz) Die Cloud kann mit Nachrichtenverlusten zwischen den Knoten umgehen. Man spricht von einer Partitionierung eines Netzwerks, wenn nicht mehr alle Knoten mit allen anderen Knoten kommunizieren können. (vgl. [9]) Das CAP-Theorem besagt, dass in verteilten Systemen höchstens zwei Eigenschaften erfüllt sein können. Deswegen wird das Theorem oft als Dreieck, wie in der Abbildung 2, dargestellt. Die Kanten des Dreiecks stellen dabei die drei möglichen Systeme CP, CA und AP dar.

4 4 Konsistenzproblematik bei der Cloud-Datenspeicherung Abbildung 2. CAP-Theorem [8] Ein Geldautomat wäre ein Beispiel für ein CP-System. Für die Geldtransaktionen ist die Konsistenz und die Partitionstoleranz äußerst wichtig, im Gegensatz zur Verfügbarkeit, auf die verzichtet wird. Bei CA-Systemen wiederum handelt es sich um klassische relationale Datenbanksysteme, die Wert auf Konsistenz und Verfügbarkeit legen, jedoch nicht auf die Verteilung der Daten. Bei der Cloud handelt es sich um ein AP-System. Der Grund hierfür soll nun näher beschrieben werden. Die Cloud setzt auf Skalierung, d.h. zahlreiche Instanzen werden je nach Workload gestartet. Dabei werden die Instanzen innerhalb der Knoten verteilt. Die Knoten bestehen zumeist aus günstiger und nicht ausfallsicherer Hardware. Aus diesem Grund ist es erforderlich, dass die Cloud den Ausfall von Knoten toleriert. Die Cloud nutzt deswegen sehr stark die Partitionstoleranz. Zudem wird auf die Verfügbarkeit gesetzt, da der Endanwender bei langen Antwortzeiten sonst zum Konkurrenten wechselt. Auf die Konsistenz kann am ehesten verzichtet werden. Es beeinträchtigt nicht die Funktionalität von Facebook oder Twitter, wenn die Postings nicht bei allen Nutzern gleichzeitig eintreffen. Beim Cloud-Computing muss man sich daher mit einer letztendlichen Konsistenz abfinden. (vgl. [8], [9], [10]) 4 Arten von Konsistenz Es wurde bewiesen, dass die Cloud keine starke Konsistenz besitzt. Das bedeutet aber nicht, dass die Cloud dadurch für den Anwender nutzlos wäre. In diesem Abschnitt wird die letztendliche Konsistenz (Eventual Consistency) vorgestellt, welche die Cloud-Nutzung sehr gut ermöglicht. Zunächst soll ein Überblick über Konsistenzmodelle gegeben werden, die allen Clients systemweite (globale) Konsistenz liefern. In den Modellen kommt es nicht vor, dass ein Client veraltete (inkonsistente) Daten erhält. Dies realisiert das verteilte System, indem die Replikationen erst antworten, wenn alle Replikationen denselben Stand der Daten besitzen. Wegen der daraus resultierenden Wartezeit sind die Modelle für die Cloud nicht einsetzbar, da die Verfügbarkeit verletzt wird. Wie im Zusammenhang mit dem AP-System bereits erklärt, kann es nicht toleriert werden, dass die Cloud sekundenlang außer Betrieb ist. In diesem Abschnitt werden einige Modelle mit globaler Konsistenz erläutert, um das Verständnis davon zu erleichtern, was letztendliche Konsistenz ist.

5 Konsistenzproblematik bei der Cloud-Datenspeicherung 5 Im Anschluss daran wird die letztendliche Konsistenz beschrieben. In diesem Modell versendet das verteilte System die Antwort auf eine Leseanfrage direkt an den Client. Es wird nicht gewartet, bis alle Replikationen konsistent sind. Der Client kann deswegen inkonsistente Daten erhalten, da das Synchronisieren aller Replikationen Zeit beansprucht. Es kann nämlich passieren, dass der Client auf eine Replikation zugreift, die noch nicht aktualisiert worden ist. In diesem Modell ist die Verfügbarkeit gewährleistet, jedoch nicht die Konsistenz, was auch dem AP-System entspricht. Die Cloud ist dadurch immer verfügbar, jedoch kann sie veraltete (inkonsistente) Daten liefern. Zu Beginn müssen noch Begrifflichkeiten und Funktionalitäten erläutert werden. Zum besseren Verständnis werden die Konsistenzmodelle in der Cloud- Umgebung erklärt. Wenn der Client Daten aus der Cloud ausliest, ist dies eine Read Operation. Führt der Client einen Schreibvorgang in der Cloud aus, dann entspricht dies einer Write Operation. Die Cloud leitet die Operationen an Replikationen weiter, die geographisch nah am Client sind oder wenig ausgelastet sind. Deshalb arbeitet ein Client nicht immer auf derselben Replikation. (vgl. [11], [12]) Strict Consistency Führt ein Client eine Write Operation aus, erhält eine Replikation die Änderung. Direkt im Anschluss daran erhalten alle weiteren Replikationen in der Cloud die Änderung. Im Anschluss führt ein Client in extrem kurzer Zeit eine Read Operation auf dieselben Daten aus. Dabei kann es passieren, dass der Client einer anderen Replikation zugewiesen wird. Der Client erhält jedoch stets die letzte Write Operation und somit keine veralteten Daten. Das Modell ist in der Cloud nicht realisierbar, da die Partitionstoleranz nicht unterstützt wird. Das Modell setzt ausschließlich auf Verfügbarkeit und Konsistenz. Sequential Consistency Zwei Clients führen zur selben Zeit eine Write Operation aus. Die Cloud fängt die Operationen ab und übergibt sie allen Replikationen in einer sequentiellen Reihenfolge. So erhalten z.b. alle Replikationen die Write Operation von Client B und anschließend die Write Operation von Client A. Dass zuerst alle Replikationen die Write Operation von Client A erhalten und anschließend die von Client B, ist ebenso möglich gewesen. Weak Consistency In diesem Modell wird die Synchronisation Operation eingeführt. Mit dieser Operation kann der Client die zugeteilte Replikation synchronisieren und die Cloud somit konsistent setzen. Wenn der Client in der zugeteilten Replikation nicht auf veraltete Daten zugreifen möchte, führt er vorher die Synchronisation Operation aus. Eventual Consistency Eventual Consistency ( letztendliche Konsistenz ) ist dann von großer Bedeutung, wenn ein hochverfügbares System bereitgestellt werden soll. Deswegen ist das Modell sehr gut für den Einsatz in der Cloud geeignet.

6 6 Konsistenzproblematik bei der Cloud-Datenspeicherung In diesem Modell werden die Replikationen erst nach und nach konsistent. Das Synchronisieren aller Replikationen nimmt Zeit in Anspruch, da die Weiterleitung der Write Operation nicht umgehend verschickt wird. Dies lässt sich gut am folgenden Beispiel zeigen. Ein Client führt eine Write Operation aus und wird anschließend einer anderen Replikation zugeteilt. Bei der darauffolgenden Read Operation greift der Client auf veraltete Daten zu. Der Client wird auf eine Replikation verwiesen, die noch nicht die Write Operation erhalten hat. In den vorigen Modellen hätte der Client zwar keine veralteten Daten erhalten, doch müsste er Wartezeiten in Kauf nehmen. Eventual Consistency bietet Verfügbarkeit an, aber um den Preis der Konsistenz. Um das Problem der Inkonsistenz zu mildern, werden vier Eigenschaften in der Eventual Consistency angeboten. Die Eigenschaften bieten Konsistenz für die Abfolge von Client-Operationen an, allerdings nur für die eigenen Daten des Client. Bei Operationen anderer Clients auf Daten, die nicht ihre eigenen sind, ist die Konsistenz nicht gegeben. Das bedeutet, dass die Clients auf veraltete Daten stoßen können. Die Provider können selbst entscheiden, welche Eigenschaften ihre Cloud anbietet. Zudem ist es möglich, dass die Cloud mehr als eine Eigenschaft anbietet. So ist z.b. die Kombination von Monotonic Write Consistency und Read Your Writes Consistency möglich. Mit einer solchen Kombination ist die Programmierung von Anwendungen, die auf der Cloud aufbauen, wesentlich leichter. Eine weitere Kombination, die erwünscht ist, ist die Kombination von Monotonic Read Consistency und Read Your Writes Consistency. Nur wenige Cloud-Provider garantieren, dass die Eigenschaften zu 100 % fehlerfrei laufen [17]. Eigenschaften ohne Garantien können z.b. eine Fehlerquote von % besitzen [14]. Mithilfe dieser Eigenschaften kann Konsistenz in der Cloud herrschen, doch nur für den Client, der auch der Besitzer der Daten ist. Die Eigenschaften werden in der Cloud so angeboten, dass der Client keine Wartezeiten für seine Operationen hinnehmen muss. Damit ist sichergestellt, dass die Verfügbarkeit in der Cloud erhalten bleibt. Als Nächstes werden in diesem Abschnitt die Eigenschaften aus der Sichtweise der Cloud erläutert. (vgl. [11], [12], [13]) Monotonic Read Consistency Ein Client tätigt eine Read Operation und wird dabei der Replikation A zugeteilt. Anschließend folgt eine weitere Read Operation auf den identischen Daten, doch wird der Client vorher der Replikation B zugeteilt. Die Verlagerung kam zustande, weil es in der Cloud zu einer Lastenverteilung gekommen ist. Die Eigenschaft sorgt nun dafür, dass der Client keine veralteten Daten liest. Die Replikation B wird konsistent gesetzt, bevor der Client die Read Operation erhält. Monotonic Write Consistency Ein Client führt eine Write Operation in der ihm zugeteilten Replikation A aus. Anschließend wechselt der Client aufgrund einer Lastenverteilung zur Replikation B. Es folgt eine zweite Write Operation

7 Konsistenzproblematik bei der Cloud-Datenspeicherung 7 auf den identischen Daten. Die Eigenschaft stellt nun sicher, dass die vorangegangene Write Operation aus Replikation A an die Replikation B weitergeleitet wird. Des Weiteren achtet die Eigenschaft darauf, dass die vorangegangene Write Operation vor der zweiten Write Operation eingereiht und verarbeitet wird. Read Your Writes Consistency Eine Write Operation wird vom Client in der ihm zugeteilten Replikation A ausgeführt. Im Anschluss daran folgt eine Read Operation, um die Write Operation auszulesen. Vor der Read Operation kam es allerdings zu einer neuen Replikationszuweisung, der Client wurde der Replikation B zugeteilt. Die Eigenschaft leitet nun die vorangegangene Write Operation aus der Replikation A an die Replikation B weiter, damit der Client seine letzte Write Operation lesen kann. Write Follows Reads Consistency Ein Client tätigt eine Read Operation und wird einer Replikation A zugewiesen. Die Read Operation liest eine Datei in der Version X aus. Anschließend vollführt derselbe Client eine Write Operation, um die ausgelesene Datei zu bearbeiten. Der Client ist noch immer mit derselben Replikation A verbunden, weshalb diese Replikation die Write Operation zuerst erhält. Die Eigenschaft sorgt nun für die Verteilung der Write Operation auf die anderen Replikationen. Zuerst erhalten jene Replikationen die Write Operation, die die Datei in der Version X oder in einer aktuelleren Version vorliegen haben. Replikationen, die die Datei in einer älteren Version besitzen, erhalten die Write Operation erst dann, wenn die Datei in der Version X oder in einer aktuelleren Version vorliegt. (vgl. [11], [12]) 5 Cloud-Konsistenz in der Praxis Es ist nun gezeigt worden, dass die Cloud die Eventual Consistency anbietet, sowie eine Reihe von optionalen Eigenschaften. Der Anwender kann sich nicht immer auf die Eigenschaften verlassen, da nur wenige Cloud-Provider garantieren, dass ihre Eigenschaften fehlerfrei arbeiten [17]. Zudem werden nicht immer alle Eigenschaften von den Providern unterstützt. Deshalb muss der Anwender die Inkonsistenz hin und wieder in Kauf nehmen. Man muss zwar auf die Synchronisierung eine gewisse Zeit warten, doch hat dies den Vorteil, dass man eine Fehlerquote von null Prozent hat, im Gegensatz zu Eigenschaften, die keine Garantie besitzen. Die Zeitspanne der Inkonsistenz lässt sich statistisch ermitteln. In diesem Abschnitt sollen die Zeitspanne der Inkonsistenz (Inkonsistenzfenster) sowie die Fehlerquote der Eigenschaften analysiert werden. Für den Anwender, der sich für ein Cloud-Angebot entschieden hat, kann die Zeitspanne der Inkonsistenz ein wichtiger Faktor sein. Eine Inkonsistenz von wenigen Millisekunden mag für eine Webanwendung tolerierbar sein, eine Inkonsistenz von mehreren Sekunden jedoch nicht. Ein weiterer wichtiger Faktor für den Anwender sind die Fehlerquoten der Eigenschaften. (vgl. [13], [14])

8 8 Konsistenzproblematik bei der Cloud-Datenspeicherung 5.1 Vorgehensweise und Implementierung Die Forschungsgruppe eorganisation am Karlsruher Institut für Technologie (KIT) hat ein Verfahren entwickelt, dass das Inkonsistenzfenster approximiert [14]. Das Inkonsistenzfenster ist die Zeitspanne, in der eine Write Operation verschickt wird und gemessen wird, wann alle Replikationen die Operation erhalten haben. Da die Cloud keinen direkten Zugriff auf die Replikationen ermöglicht, kann nicht die Zeit gemessen werden, die vergeht, bis alle Replikationen nach einer Write Operation denselben Stand der Daten besitzen. Die Forschungsgruppe hat deswegen ein Verfahren entwickelt mit dem man sich dem Inkonsistenzfenster nähern kann. Der Provider ist der einzige, der in der Lage ist, das Inkonsistenzfenster zu ermitteln. Für den Provider ist die Cloud eine Whitebox, für den Client (Anwender) hingegen eine Blackbox. Der Client kann das Inkonsistenzfenster nur erhalten, indem er die Zeit misst, bis er keine inkonsistenten Daten mehr erhält. Die Cloud kann dem Client ältere (inkonsistente) Daten vorenthalten und sie nicht ausliefern [13]. Deswegen ist das erhaltene Inkonsistenzfenster nur eine Annäherung. (vgl. [13], [14]) Für das Messverfahren der Forschungsgruppe werden mehrere Server eingesetzt, die als Reader fungieren und Read Operations ausführen. Darüber hinaus wird ein weiterer Server als Writer eingesetzt, um Write Operations zu vollführen. Der Writer schickt periodisch Write Operations an die Cloud. In den Write Operations ist jeweils eine Kombination des Zeitstempels und einer Version enthalten. Die Reader schicken zur selben Zeit parallele Read Operations, um laufend die Daten auszulesen. Setzt man die erhaltenen Daten aller Reader zusammen, erhält man das Inkonsistenzfenster. Die Abbildung 3 veranschaulicht das Vorgehen. (vgl. [14]) Abbildung 3. Reader und Writer [13]

9 Konsistenzproblematik bei der Cloud-Datenspeicherung 9 Der Einsatz mehrerer Reader ist erforderlich, da dies die Wahrscheinlichkeit erhöht, jede Replikation zu erreichen. Der Zugriff auf viele Replikationen verbessert die Genauigkeit des Inkonsistenzfensters. Wenn die Reader nicht auf allen Replikationen vertreten sind, bemerken die Reader das Synchronisieren der Replikationen schneller. Daraus resultiert ein niedrigeres Inkonsistenzfenster. Für drei Replikationen müssten drei Reader reichen. Die Reader verschicken gleichzeitig Read Operations und sollten demzufolge auf allen Replikationen vertreten sein. Das ist aber nicht der Fall. Die Zuweisung der Replikationen zu den Readern (Clients) regelt die Cloud, und es nicht bekannt, welchen Regeln dies unterliegt. Deswegen muss eine Vielzahl von Readern genutzt werden. Die Forschungsgruppe gibt an, dass bei 3 Replikationen 9 Reader eingesetzt werden sollten. Die Wahrscheinlichkeit würde dann 93 % betragen, dass alle Replikationen einen Reader erhalten [14]. Des Weiteren lässt sich die Wahrscheinlichkeit steigern, indem die Reader geographisch nah an den Replikationen platziert werden. (vgl. [13], [14]) Eine zweite Forschungsgruppe aus Australien hat sich ebenfalls mit dem Problem beschäftigt, das Inkonsistenzfenster zu messen [15]. Ihr Ansatz unterscheidet sich jedoch von dem der eorganisation -Forschungsgruppe. Das Inkonsistenzfenster wird zwar auch mithilfe der Clients berechnet, doch kommt nur ein Reader zum Einsatz. Der Reader und der Writer befinden sich sogar im selben Server. Die Forschungsgruppe eorganisation steht diesem Ansatz kritisch gegenüber, da keine veralteten Daten erscheinen. eorganisation schildert, dass bei einem einzigen Reader die Wahrscheinlichkeit sehr groß ist, dass stets dieselbe Replikation zugewiesen wird [14]. (vgl. [14], [15]) Abbildung 4. Ermitteln des Inkonsistenzfensters [14] Die Abbildung 4 verdeutlicht, wie die Reader das Inkonsistenzfenster mit dem Messverfahren der eorganisation berechnen. Der Writer verschickt jeweils zu

10 10 Konsistenzproblematik bei der Cloud-Datenspeicherung allen 5 Zeitpunkten eine Write Operation, die eine Version und den Zeitstempel (Zeitpunkt) enthält. Im Zeitpunkt 5 verschickt der Writer die Write Operation mit der Version B. Der Reader 1 liest im Zeitpunkt 8 zum letzten Mal die alte Version A, der Reader 2 hingegen erst im Zeitpunkt 10. Nun wird überprüft, wie viele Zeitpunkte zwischen der Write Operation (Version B) und dem letzten Lesen von Version A vergangen sind. Bei Reader 1 sind dies 3 Zeitpunkte und bei Reader 2 sind dies 5 Zeitpunkte. Der höhere Wert, in diesem Fall der Zeitpunkt 5, entspricht dem Inkonsistenzfenster für die Version A. (vgl. [13], [14]) 5.2 Durchführung und Ergebnisse Die Forschungsgruppe eorganisation hat ihr Messverfahren beim bekanntesten Cloud-Computing-Dienst Amazon S3 angewendet. Der Dienst verspricht Skalierbarkeit, Verfügbarkeit, Ausfallsicherheit durch Replikationen und geographische Verteilung. Die Forschungsgruppe hat über die Zeit normalverteilte Konsistenzfenster erwartet, die von der Systemlast abhängen. Bei einer hohen Auslastung der Systemlast sollten die Write Operationens nicht so schnell an die Replikationen verschickt werden. Zur Verblüffung der Forschungsgruppe ist das normalverteilte Konsistenzfenster nicht aufgetreten. (vgl. [13], [14]) Die Forschungsgruppe aus Australien hat sich ebenfalls mit dem Messen des Inkonsistenzfensters im Amazon-S3-Dienst beschäftigt. Anders als die eorganisation -Gruppe entdeckte sie überhaupt keine Inkonsistenz und maß somit auch kein Inkonsistenzfenster [15]. Der Grund hierfür ist sicherlich, dass nur ein Reader eingesetzt wurde. Der Reader wird immer an die selbe Replikation verwiesen und nicht an eine Replikation, die die Write Operation später erhält [14]. Ein Blogger hat sich eines ähnlichen Verfahrens mit nur einem Reader bedient, um das Inkonsistenzfenster zu messen. Herausgekommen ist dasselbe Ergebnis, nämlich dass keine Inkonsistenz herrscht [16]. (vgl. [14], [15], [16]) Abbildung 5. Saw-Phase [14]

11 Konsistenzproblematik bei der Cloud-Datenspeicherung 11 Beim Ansatz der Forschungsgruppe eorganisation verschickt der Writer alle zehn Sekunden die Write Operation. Die Reader wiederum verschicken jede zehn Millisekunden die Read Operation. Das erhaltene Inkonsistenzfenster lässt sich in zwei Phasen unterteilen, zu einem in die Low-Phase und zum anderen in die Saw-Phase (sägende Konsistenz). In der Low-Phase treten niedrige Werte auf, die im Bereich weniger hundert Millisekunden liegen. In der Saw-Phase ist das Inkonsistenzfenster steigend und nicht einheitlich. Die Messergebnisse der Saw-Phase sind in der Abbildung 5 aufgeführt. Die erste Messung in der Saw-Phase liefert einen Wert zwischen null und zwei Sekunden, anschließend steigt der Wert für acht oder zwölf Messungen an. Ist der Wert auf zwölf Sekunden gestiegen, ist das Maximum erreicht. Anschließend beginnen die Werte von neuem beim Minimalwert und steigen bis zum Maximalwert. Die Dauer einer Saw-Phase beträgt 80 bis 120 Sekunden, da in jeder Messung ( Test Number ) eine Write Operation verschickt wird. Verschickt wird eine Write Operation alle zehn Sekunden. (vgl. [13], [14]) In der Abbildung 6 sind die Messergebnisse dargestellt, die im Zeitraum von einer Woche erhoben wurden. Zu erkennen sind in dieser Abbildung die einzelnen Low- und Saw-Phasen. Aufgrund der Dichte der Messungen ( Test Number ) ist das Steigen und Abfallen der Saw-Phasen nicht gut zu erkennen. Die Saw-Phasen starten montags bis freitags gegen 8 Uhr und enden gegen 21 Uhr. Am Wochenende gibt es kurz verteilte Saw-Phasen. In der restlichen Zeit überwiegt die Low-Phase. Zwischen der Tageszeit und der Inkonsistenz lässt sich eine Beziehung herstellen. Über den Grund für das Auftreten der Saw-Phasen und deren Verteilung lässt sich nur spekulieren. Allein Amazon kann hier für Aufklärung sorgen. (vgl. [13], [14]) Abbildung 6. Low- und Saw-Phase in einer Woche [14] Das Magazin ix nahm sich des Problems an und fragte bei Amazon nach. Leider wurde dem Magazin keine Auskunft bezüglich der Ursache der Low-

12 12 Konsistenzproblematik bei der Cloud-Datenspeicherung und Saw-Phase erteilt [14]. Allerdings scheint Amazon die Ergebnisse der Forschungsgruppe eorganisation ernst genommen zu haben. Bei einer weiteren Messung des Inkonsistenzfensters zeigten sich nach der Kontaktaufnahme verbesserte Werte. Die Verteilung der Low- und Saw-Phase blieb bestehen, doch waren die Werte der Saw-Phase nicht mehr so hoch. (vgl. [13]) 5.3 Bewertung der Eigenschaften in der letztendlichen Konsistenz Die Forschungsgruppe eorganisation hat anschließend die Fehlerquote einer Eigenschaft ausgewertet. Die Monotonic Read Consistency ist als Einziges gemessen worden. Es wurden Read Operation getätigt und Mal ist eine falscher Wert erschienen. Dies ergibt eine Fehlerquote von 12 % [14]. Leider wurden keine Messwerte zu den anderen Eigenschaften gefunden. Es konnte nur bestätigt werden, dass die Monotonic Write Consistency und die Read Your Writes Consistency fehlerhafte Daten liefern können [13]. Die Fehlerquoten sind allerdings nicht bekannt. (vgl. [13], [14]) Die Provider veröffentlichen nicht, welche Eigenschaften unterstützt werden, dies muss der Anwender mithilfe von Anwendungen und Messungen selbst ermitteln. Lediglich die Eigenschaften, die eine Garantie erhalten, werden bekannt gegeben. So hat Amazon vor kurzem die Read Your Writes-Garantie für seinen Cloud-Dienst veröffentlicht [17]. Dass die vesteckten Eigenschaften von den Providern nicht genannt werden, könnte an den vorhandenen Fehlerquoten liegen. (vgl. [17]) Eigenschaften ohne Garantien können dennoch genutzt werden, und zwar nur von Anwendungen. Die Daten in der Cloud können mit Metainformationen (z.b. mit einer Versionsnummer) versehen werden. Mit einer solchen Information weiß die Anwendung, wann ein falscher Wert gelesen wird. Die Anwendung kann auf den Fehler z.b. mit einer neuen Read Operation reagieren und dadurch den richtigen Wert erhalten. (vgl. [13]) 6 Fazit Die Cloud-Dienste bieten Verfügbarkeit und Partitionstoleranz an. Dadurch wird den Anwendern eine sehr geringe Wartezeit geboten, wenn sie die Cloud nutzen. Der Preis dafür ist jedoch der Verlust der strikten Konsistenz. Entwickler für Cloud-Anwendungen müssen deswegen berücksichtigen, dass die Replikationen erst nach einer recht langen Zeitspanne konsistent sind. In den Messungen wurde gezeigt, dass eine Anwendung maximal zwölf Sekunden warten müsste, um konsistente Daten zu erhalten. In der Nacht sind niedrigere Werte möglich. Einem Benutzer der Cloud-Anwendung kann nicht zugemutet werden, dass er bei einer Read Operation zwölf Sekunden warten soll. Aus diesem Grund können die Cloud-Anwendungen auf die Cloud-Eigenschaften zurückgreifen. Das Problem der Fehlerquoten lässt sich mit dem vorgestellten Ansatz der Metainformationen (Versionsnummern) lösen. Es kann jedoch der Fall auftreten, dass

13 Konsistenzproblematik bei der Cloud-Datenspeicherung 13 nicht alle Eigenschaften von der Cloud unterstützt werden. Dann muss ein Kompromiss gefunden werden, der so aussieht, dass einige Daten lokal in der Cloud- Anwendung (Instanzen) gespeichert werden. Gelöst werden könnte dies mit einem Caching. Entwickler von Cloud-Anwendungen sollten bei der Implementierung beachten, dass die Anwendung bei Änderungen der Cloud weiterhin funktionieren muss. Das folgende Beispiel erläutert den Sachverhalt: Angenommen, eine Cloud- Anwendung nutzt die versteckte Eigenschaft Monotonic Read Consistency, da in vorangegangenen Messungen herausgefunden wurde, dass diese Eigenschaft in der Cloud unterstützt wird. Der Cloud-Provider führt nach einigen Monaten ein Cloud-Update durch und deaktiviert dabei die Monotonic Read Consistency. Der Provider kann so verfahren, weil er keine Garantie für die Eigenschaft veröffentlicht hat. Nach dem Update wird die Cloud-Anwendung beim Kunden allerdings nicht mehr problemlos arbeiten. Bei der Implementierung von Cloud- Anwendungen sind die Entwickler sehr vom Provider abhängig. Bei der Entscheidung, welches Cloud-System gewählt werden soll, sollte nicht nur die Anfragemächtigkeit, die Antwortzeit oder die Service Level Agreements eine Rolle spielen. Es kann von großem Nutzen sein, wenn der Anwender nichttriviale Kriterien berücksichtigt. Ein solches Kriterium wäre der statistische Mittelwert des Inkonsistenzfensters, ein weiteres die garantierten Eigenschaften, die in der Cloud angeboten werden. (vgl. [13], [14]) Literatur 1. ITWissen, Cloud ( ) 2. ITWissen, Cloud-Computing ( ) 3. BSI, Cloud Computing Grundlagen Grundlagen_node.html ( ) 4. Peter Mell, Tim Grance - The NIST Definition of Cloud Computing ( ) 5. Wikipedia, Cloud-Computing ( ) 6. Wolfgang Herrmann - TecChannel, Grundlagen Cloud Computing cloud_computing_saas_virtualisierung/ ( )

14 14 Konsistenzproblematik bei der Cloud-Datenspeicherung 7. Dr. Eric A. Brewer - Towards Robust Distributed Systems ( ) 8. Wikipedia, CAP-Theorem ( ) 9. Kai Spichale, Eberhard Wolf - NoSQL: Konzepte und Prinzipien Software & Support Media GmbH, Java Magazin 04/ Eberhard Wolff - Architekturen für die Cloud JavaSpektrum.pdf ( ) 11. A. S. Tanenbaum and M. V. Steen - Verteilte Systeme Prinzipien und Paradigmen Pearson Studium, 2., aktualisierte Auflage, Werner Vogels - All Things Distributed html ( ) 13. David Bermbach, Stefan Tai - Sägende Konsistenz Heise Verlag, ix 06/ David Bermbach, Stefan Tai - Eventual Consistency: How Soon is eventual? Karlsruher Institut für Technologie, H. Wada, A. Fekete, L. Zhao, K. Lee, and A. Liu. - Data Consistency Properties and the Trade-offs in Commercial Cloud Storages: the Consumers Perspective National ICT Australia - NICTA, Huan Liu s - The cost of eventual consistency BFthe-cost-of-eventual-consistency/ ( ) 17. Shlomo Swidler - Read-After-Write Consistency in Amazon S3 html ( )