Entwicklung eines mandantenfähigen Software-Dienstes zur -Archivierung

Transkript

1 Institut für Parallele und Verteilte Systeme Universität Stuttgart Universitätsstraÿe 38 D70569 Stuttgart Diplomarbeit Nr Entwicklung eines mandantenfähigen Software-Dienstes zur -Archivierung Michael Fechter Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr.-Ing. habil. Bernhard Mitschang Dipl.-Inf. Oliver Schiller begonnen am: 9. September 2009 beendet am: 17. März 2010 CR-Klassikation: H.3.1, H.3.2, H.3.3

2 Kurzfassung Im Rahmen dieser Diplomarbeit soll der vorhandene Prototyp einer Archivierungslösung auf eine mögliche Verwendung der von Amazon angebotenen Infrastruktur- und Plattformdienste namens Amazon Web Services (AWS) hin untersucht und diese Variante anschlieÿend realisiert werden. Dabei stehen die eziente Nutzung der verschiedenen AWS sowie die Entwicklung einer mandantenfähigen und skalierbaren Lösung im Vordergrund, welche anschlieÿend hinsichtlich eines Leistungstests und einer Kostenanalyse für die verwendeten AWS bewertet werden soll.

3 Inhaltsverzeichnis 1 Einleitung Vorwort Struktur Abkürzungen Begrie Grundlagen Amazon Web Services Einführung Amazon SimpleDB Amazon Simple Storage Service Amazon Elastic Compute Cloud Amazon Simple Queue Service Projekt Cmgrid Rechtliche Vorschriften Vorhandene Version Anforderungen an die neue Version Implementierung Komponenten zur Verwendung der AWS Externe Bibliotheken Common SimpleDB S EC SQS Übergeordnete Schichten Threadverwaltung Dokumentenverwaltung Abrechnung Aufgabenplanung Datenzusammenfassung Allgemeine Verwaltung Kommandozeilenwerkzeug Web-basierende Schnittstelle von Amazon

4 Inhaltsverzeichnis 4 Integration Allgemeiner Aufbau Domains des Prototyps Bereitstellung neuer Jobs Abruf eingereihter Jobs Archivierungsprozess Speicherung der Dokumente Zugri auf das Package cmgrid-aws Neue Komponenten Überarbeitete Komponenten Konguration der Instanzen in der Cloud Amazon Machine Image (AMI) Benutzerdaten Skripte Verwaltung der Instanzen in der Cloud Web-basierende Benutzeroberäche Umgebungsintegration Simulation Allgemeiner Ablauf der Dokumentenarchivierung Durchführung der Messreihen Beschreibung Messergebnisse Interpretation Kosten Kostenrechnung anhand eines allgemeinen Beispiels Kostenrechnung am Beispiel der Messreihen Zusammenfassung Ergebnisse der Diplomarbeit Ausblick Weitere Verwendung von AWS im Projekt Mögliche Fortsetzungen zu dieser Arbeit

5 Abbildungsverzeichnis 3.1 Vereinfachtes Klassendiagramm der Komponenten Vereinfachtes Klassendiagramm der Schichten Web-basierende Schnittstelle von Amazon Domains des Prototyps Bereitstellung neuer Jobs Abruf eingereihter Jobs Archivierungsprozess Speicherung der Dokumente Übersicht in der Benutzeroberäche Übersicht der Knoten in der Benutzeroberäche Status der AWS in der Benutzeroberäche Details zur SimpleDB in der Benutzeroberäche Details zu SQS in der Benutzeroberäche Details zu S3 in der Benutzeroberäche Aktivitäten der Knoten in der Benutzeroberäche Statistiken zu Jobs in der Benutzeroberäche Warteschlange für Jobs in der Benutzeroberäche Bereitstellung von Jobs in der Benutzeroberäche Suche in AWS in der Benutzeroberäche Verwaltung der Knoten in der Benutzeroberäche Messreihe mit 10 Instanzen Messreihe mit 10 Mandanten Load Balancing per Auto Scaling and CloudWatch

6 Tabellenverzeichnis 2.1 Kosten der Rechenleistung in Amazon SimpleDB Kosten des Datentransfers in Amazon SimpleDB Kosten des Speicherplatzes in Amazon SimpleDB Kosten des Speicherplatzes in Amazon S Kosten des Datentransfers in Amazon S Kosten der Abfragen in Amazon S Instanztypen in Amazon EC Kosten von Instanzen auf Abruf in Amazon EC Einmalige Kosten von reservierten Instanzen in Amazon EC Betriebskosten von reservierten Instanzen in Amazon EC Kosten von Spot-Instanzen in Amazon EC2 (zufälliger Zeitpunkt) Kosten des Datentransfers in Amazon EC Kosten des Speicherplatzes in Amazon EC Kosten der IP-Adressen in Amazon EC Kosten der Abfragen in Amazon SQS Kosten des Datentransfers in Amazon SQS Operatoren in Auswahlanfragen Kennzahlen der Abrechnungsdaten Allgemeine Befehle Befehle für Amazon SimpleDB Befehle für Amazon S Befehle für Amazon EC Befehle für Amazon SQS Projekteigene Befehle Einzelne Messreihe mit einem Mandanten als Bemessungsgrundlage Messreihe mit 10 Instanzen Messreihe mit 10 Mandanten

7 1 Einleitung 1.1 Vorwort Dieses Dokument ist die Ausarbeitung der Diplomarbeit Entwicklung eines mandantenfähigen Software-Dienstes zur -Archivierung, in welcher eine neue Variante eines bereits existierenden Dienstes zur -Archivierung entwickelt werden soll. In diese Variante sollen die von Amazon angebotenen Amazon Web Services (AWS) möglichst ezient in den Dienst einbettet und zusätzliche Anforderungen hinsichtlich der Mandantenfähigkeit und der Skalierbarkeit berücksichtigt werden. Des Weiteren soll das Leistungsvermögen der entwickelten Variante untersucht und eine Kostenrechnung anhand der durchgeführten Messreihen für die laufenden Kosten der AWS erstellt werden. 1.2 Struktur Im ersten Teil dieses Dokuments bendet sich diese Einleitung. Im zweiten Teil des Dokuments werden zunächst die Grundlagen für das Verständnis der AWS sowie des vorhandenen Prototyps erläutert. Daraufhin wird im dritten Teil die eigentliche Implementierung der AWS innerhalb des Prototyps dargestellt. Der vierte Teil setzt sich schlieÿlich mit der Integration der implementierten Komponenten zur Verwendung innerhalb des portierten Prototyps auseinander. Im fünften Teil werden die Leistungstests mit Hilfe verschiedener Messreihen sowie die Kostenanalyse durchgeführt. Der sechste Teil besteht aus der Zusammenfassung der Ergebnisse dieser Arbeit und einem Ausblick auf mögliche zukünftige Entwicklungsfelder. 1.3 Abkürzungen AMI Amazon Machine Image API Application Programming Interface AWS Amazon Web Services CAS Center of Advanced Studies CFS Cluster File System CMaaS Content Management as a Service 6

8 Begrie Cmgrid Content Management Grid DHT Distributed Hash Table EBS Elastic Block Store EC2 Elastic Compute Cloud FERC Federal Energy Regulatory Commission GB Gigabyte IaaS Infrastructure as a Service IBM International Business Machines Corporation I/O Input / Output JAR Java Archive JSP JavaServer Pages KB Kilobyte MA Mitarbeiter MB Megabyte PAI Parse Archive Index REST Representational State Transfer RDS Relational Database Service SimpleDB Simple Database S3 Simple Storage Service SLA Service Level Agreement SOAP Simple Object Access Protocol SQL Structured Query Language SQS Simple Queue Service TB Terabyte URL Uniform Resource Locator VOI Verband Organisations- und Informationssysteme 1.4 Begrie Accounting Die Abrechnungsdaten werden dafür verwendet, den Verbrauch der AWS für jeden Mandanten nachvollziehen zu können. Attribut Ein Attribut in der Amazon SimpleDB hat die Form eines Key-Value Paares. BitTorrent BitTorrent ist ein kollaboratives Filesharing-Protokoll, das sich besonders für die schnelle Verteilung groÿer Datenmengen eignet 1. Bucket Ein Bucket bezeichnet einen Container für Objekte in Amazon S3. Cloud Eine Cloud stellt dynamische IT Infrastrukturen in einer (metaphorischen) Wolke zur Verfügung, deren Zugri über ein Netzwerk (zumeist das Internet) erfolgt

9 Begrie Constraints Semantische Integritätsbedingungen (constraints) werden in Datenbanksystemen verwendet, um die Konsistenz der Datenbank zu gewährleisten. Domain Eine Domain ist vergleichbar mit einer Tabelle, welche verschiedene Elemente enthält. Element Ein Element bendet sich in einer Domain und besitzt zwischen 1 und 256 Attributen. Entscheidungswert Ein Entscheidungswert (oder auch Flag genannt) ist entweder gesetzt (also 'true') oder nicht gesetzt (also 'false'). Hash-Tabelle Eine Hash-Tabelle verwaltet beliebige Objekte, indem die Objekte mit einem Schlüssel verknüpft und über diesen Schlüssel schlieÿlich referenziert werden. ID, identier Ein 'identier' stellt einen eindeutigen Bezeichner dar. Image Ein Image bezeichnet das Abbild einer Maschine, welches als Grundlage für den Start von Instanzen dienen kann. Import Mit Hilfe eines Imports kann eine Komponente eine andere Komponente verwenden. Instanz Eine Instanz in Amazon EC2 bezeichnet einen virtuellen Rechner in der Cloud. Die Instanz einer Klasse hingegen ist eine Ausprägung oder ein Exemplar dieser Klasse. Iterator Ein Iterator ist ein Zeiger, mit welchem die Elemente einer Liste durchlaufen werden können. Join Der Verbund (join) wird in Datenbanksystemen verwendet, um Tabellen miteinander zu verknüpfen. Key-Value Ein Key-Value Paar hat die Struktur key = 'value'. Klasse Eine Klasse enthält verschiedene Methoden und Variablen oder auch weitere Unterklassen. Knoten Ein Knoten bezeichnet einen Rechner im Netzwerk des Projekts (zum Beispiel einen PAI-Knoten). Komponente Eine Komponente besteht aus der Angabe des Packages, den zu verwendenden Imports und einer einzelnen Klasse mit gleichem Namen. MessageQueue Eine MessageQueue bezeichnet eine Warteschlange für Nachrichten. Metadaten Als Metadaten werden Informationen über andere Daten bezeichnet. Modulo-Operator Der modulo-operator berechnet den Rest einer Division (also zum 8

10 Begrie Beispiel: 17 modulo 7 = 3). Multiple attributes Mehrwertige Attribute können innerhalb eines Elements in Amazon SimpleDB auch mehrmals existieren, falls sich die Werte der Attribute unterscheiden (der Name des Attributs ist elementweit nicht eindeutig). Objekt Die Daten in Amazon S3 werden als Objekte in den verschiedenen Buckets abgespeichert. Package Ein Package bezeichnet eine Sammlung von Komponenten. PAI-Knoten PAI steht für 'Parse Archive Index (PAI)' und ein PAI-Knoten stellt eine Instanz innerhalb der Cloud dar, welche für den Archivierungsprozess der Dokumente bestehend aus Analyse ('parse'), Archivierung ('archive') und Indizierung ('index') verantwortlich ist. Replaceable attributes Ersetzbare Attribute existieren innerhalb eines Elements in Amazon SimpleDB nur einmal (der Name des Attributs ist elementweit eindeutig). Servlet Ein Servlet ist eine Klasse, welche auf einem Webserver läuft und bestimmte Anfragen beantwortet. Singleton Singleton ist ein Entwurfsmuster, in welchem nur eine Instanz einer Klasse erzeugt werden kann. Static Eine statische Klasse, Methode oder Variable kann über ihren Klassennamen ohne Instanziierung aufgerufen werden. Transactions Transaktionen werden in Datenbanksystemen verwendet, um mehrere Operationen entweder vollständig oder überhaupt nicht durchzuführen. Thread Ein Thread bezeichnet einen eigenständigen Teilprozess, welcher parallel zum Hauptprozess abläuft. 9

11 2 Grundlagen 2.1 Amazon Web Services (AWS) In diesem Abschnitt werden einige der von Amazon zur Verfügung gestellten Amazon Web Services (AWS) ausführlich vorgestellt und deren Funktionsweise erläutert. Aufgrund der Vielfalt an angebotenen Web Services sowie der Aktualität dieser Thematik und der damit verbundenen ständigen Weiterentwicklung, werden nur die zum Zeitpunkt des Beginns dieser Arbeit vorhandenen Web Services näher betrachtet. Somit liegt der Fokus auf denjenigen Web Services, welche später in das vorhandene Projekt Content Management Grid (Cmgrid) integriert werden sollen Einführung Amazon bietet seit Anfang 2006 eine Plattform für eine Web Service Infrastruktur mit dem Namen AWS an, welche dem Geschäftsmodell des Infrastructure as a Service (IaaS) [9] entspricht und IT Infrastrukturen (wie beispielsweise dynamische Rechenkapazitäten oder dauerhafte Speicherlösungen) als Web Service für Unternehmen jeder Gröÿe anbietet. Die AWS verwirklichen somit den Ansatz des Cloud Computing [5], in welchem die IT Infrastruktur nicht mehr lokal, sondern in einer (metaphorischen) Wolke (engl. 'cloud') betrieben wird und der Zugri über ein Netzwerk (zumeist das Internet) erfolgt. Dieser Ansatz dient somit dazu, dem Benutzer eine dynamische IT Infrastruktur als Service anzubieten, welcher sich vor allem durch Flexibilität, Skalierbarkeit und Hochverfügbarkeit auszeichnet. Flexibilität: Aufgrund der Plattformunabhängigkeit der AWS und der Unterstützung unterschiedlichster Systeme haben die Unternehmen die freie Auswahl, welche Entwicklungsplattform und welches Programmiermodell sie für die Lösung ihres Problems verwenden möchten. Durch die Vielzahl an bereits vorhandenen Web Services können beliebige Anwendungen in kürzester Zeit auf den AWS ausgeführt werden und sind somit schnellstmöglich verfügbar. Die vorhandenen AWS lassen sich ohne groÿen Aufwand in die eigenen Anwendungen eingliedern und bieten eine einfache Realisierung der verschiedenen Komponenten (von einem einfachen Datenbanksystem bis hin zum vollständigen 10

12 Amazon Web Services Zahlungswesen). Demzufolge entfällt eine kostenintensive Neuentwicklung dieser Komponenten und das Unternehmen kann die Anwendung ohne vorab zu leistende Investitionen realisieren. Skalierbarkeit: Amazon betreibt eines der gröÿten Netzwerke von Webseiten, um monatlich Millionen von Kunden zu bedienen sowie Millionen von Transaktionen für Kunden und Verkäufer auszuführen. Aus diesem Grund besitzt Amazon weitreichende Erfahrungen im Aufbau, im Betrieb und in der Wartung einer weltweiten Infrastruktur. Somit steht diese enorme Rechenleistung und ausreichend Speicherplatz zur Verfügung, um beinahe jede Anwendung eines Unternehmens ausführen zu können, unabhängig davon, wie schnell die Anwendung wächst oder wie viele Ressourcen sie benötigt. Hochverfügbarkeit: Die Rechenzentren der Amazon Infrastruktur bestehen aus einer groÿen Anzahl an Hardware-Knoten, die den Ausfall eines einzelnen Knotens abfangen und dessen Arbeit übernehmen können. Daraus ergeben sich für den Benutzer die Vorteile einer dauerhaften und ausfalltoleranten Infrastruktur, ohne jemals selbst Hardware kongurieren oder ersetzen zu müssen. Die Sicherheit der Daten ist durch mehrere Ebenen von operationalen und physischen Sicherungen gewährleistet, welche die Integrität und die Dauerhaftigkeit der Daten schützen [4]. Kosten: Das Kostenmodell von Amazon gewährleistet, dass dem Benutzer der AWS nur die Leistungen abgerechnet werden, welche er tatsächlich konsumiert hat. Es entstehen keine Kosten im Voraus bzw. kein Mindestumsatz für die AWS und der Benutzer muss keine langfristigen Verpichtungen oder Verträge eingehen. Durch eine höhere Anzahl an Anwendungen in der Cloud verringern sich die Kosten für den Betrieb, das Management und die Hardware, da sie auf mehrere Benutzer verteilt werden können. Diese Kostenersparnisse werden von Amazon an die Benutzer der AWS in einer transparenten Preisgestaltung weitergegeben, welche keine versteckten Kosten enthält. Mit Hilfe der AWS kann der Fokus des Arbeitsaufwands und der Ausgaben auf die eigentlichen Kerngeschäfte des Unternehmens gelegt werden, wodurch sich ein wesentlicher Mehrwert für den Kunden ergibt. Umweltschutz: Aufgrund der Verwendung von innovativen Technologien zur Kühlung und Stromversorgung der Rechenzentren von Amazon führen die AWS zu einer geringeren Umweltbelastung. Des Weiteren ergeben sich durch die gemeinsame Verwendung der 11

13 Amazon Web Services AWS weniger umweltbelastende Einüsse einzelner Unternehmen, ohne auf eine umfassende Skalierbarkeit oder Flexibilität verzichten zu müssen Amazon SimpleDB Allgemeine Beschreibung Im Rahmen der AWS bietet Amazon einen Web Service namens Amazon SimpleDB an, welcher dem Benutzer ohne weiteren administrativen Aufwand eine nicht-relationale Datenbank zur Verfügung stellt. Der Zugri auf diese Datenbank erfolgt über eine Web Service Schnittstelle, wobei die Anfragen mit Hilfe einer API an die Datenbank gestellt werden. Dabei stehen allerdings nur einige Grundfunktionen zur Manipulation der Daten zur Verfügung, da bei der Amazon SimpleDB auf komplexe, aber oft unbenutzte Datenbankoperationen verzichtet wurde. Im Hintergrund erstellt die Amazon SimpleDB automatisch mehrere geographisch verteilte Kopien der gespeicherten Daten, wodurch die Hochverfügbarkeit und Dauerhaftigkeit dieser Daten gewährleistet wird. Falls der unwahrscheinliche Fall eintreten sollte, dass eine Kopie der Daten ausfällt, dienen die anderen Kopien als automatische Ausfallsicherung. Durch die Verwendung der Amazon SimpleDB kann der Entwickler seinen Fokus auf die eigentliche Anwendungsentwicklung legen und muss sich nicht mit administrativen Aufgaben wie der Beschaung der Infrastruktur, der Wartung von Hard- und Software oder der Verwaltung der Schemata und des Indexes befassen Aufbau In Amazon SimpleDB werden die Daten in sogenannten Domains (oder Domänen) gespeichert, die in etwa mit den Tabellen einer Datenbankanwendung vergleichbar sind. Im Vergleich zu einer herkömmlichen Datenbank werden in der Amazon SimpleDB allerdings keine Schemata zur Beschreibung der Datenstruktur benötigt, da die Amazon SimpleDB nach der exiblen Charakteristik eines sogenannten 'Key-Value Stores' entworfen ist. Das bedeutet, dass die Daten innerhalb der Datenbank aus 'Key-Value' Paaren (der Form Name = 'Wert') bestehen und somit keinen festgelegten Strukturen entsprechen müssen. In diesen Domains benden sich Elemente, welche über einen in dieser Domain eindeutigen Bezeichner ('ID') referenziert werden. Jedes Element kann wiederum eine beliebige Anzahl an Attributen besitzen. Dabei ist zu beachten, dass ein Element allerdings immer mindestens ein Attribut enthalten muss, da Elemente ohne Attribute aus der Domain 12

14 Amazon Web Services entfernt werden (genau genommen bezeichnet das Entfernen aller Attribute die Löschoperation für Elemente). Die Attribute eines Elements sind jeweils als Key-Value Paar aufgebaut und ordnen somit einem Namen (Bezugsschlüssel, 'key') einen beliebigen Wert ('value') zu. Bei der Erstellung von Attributen kann zudem ausgewählt werden, ob das neue Attribut sämtliche vorhandenen Attribute mit dem gleichen Namen ersetzt (ersetzbare Attribute, 'replaceable attributes') oder ob mehrere Attribute mit dem gleichen Namen, aber unterschiedlichen Werten nebeneinander existieren dürfen (mehrwertige Attribute, 'multiple attributes'). Diese Einstellung legt somit fest, ob Attribute nur anhand ihrer Namen oder anhand der Kombination von Namen und Wert identiziert werden. Beschränkungen der Amazon SimpleDB: Innerhalb der Amazon SimpleDB wurden von Amazon Beschränkungen festgelegt, welche die Ausmaÿe des zur Verfügung stehenden Speicherplatzes begrenzen: Ein Account darf maximal 100 Domains beinhalten. Eine Domain darf maximal 10 Gigabyte an Benutzerdaten enthalten. Eine Domain darf maximal eine Milliarde Attribute (Key-Value Paare) beinhalten. Ein Element darf maximal 256 Attribute (Key-Value Paare) besitzen. Eine Anfrage darf eine maximale Gesamtgröÿe von einem Megabyte besitzen. Eine Stapelverarbeitungsanfrage darf maximal 25 Elemente beinhalten. Des Weiteren mussten zum Zeitpunkt des Beginns dieser Arbeit einige Beschränkungen bezüglich der Konsistenz der Daten innerhalb der Amazon SimpleDB berücksichtigt werden. Das Konsistenzmodell der Amazon SimpleDB folgte derzeit dem Prinzip der 'eventual consistency'. Das heiÿt, dass keine Garantie für die Konsistenz der Daten gegeben werden konnte und ein gelesener Wert nicht unbedingt den aktuellen Wert darstellt. Bei der Einbringung von Änderungen konnte es zu Verzögerungen im höheren Sekundenbereich kommen, wodurch es zu Inkonsistenzen wie eines 'lost update' (mehrmaliges Überschreiben eines Werts) oder eines 'dirty read' (Lesen eines veralteten Werts) kommen konnte. Diese Prinzipien mussten demzufolge bei der Implementierung des Prototypen berücksichtigt werden Funktionalität Die Amazon SimpleDB wurde für Anwendungen innerhalb der Amazon Cloud optimiert und sie lässt sich daher einfach in andere AWS integrieren. Davon protieren die Anwendungen in der Cloud, da dadurch die Latenzzeiten zwischen den Services gering gehalten 13

15 Amazon Web Services werden (laut Amazon erreichen beispielsweise Anfragen aus Amazon EC2 an Amazon SimpleDB beinahe die Latenzzeiten von LAN-Verbindungen). Für die Verwendung der Amazon SimpleDB stehen dem Benutzer verschiedene Regionen zur Verfügung, die sich hinsichtlich der Latenzzeiten (abhängig vom Standort) und der Kosten (siehe Kapitel ) unterscheiden: US-East (Northern Virginia) US-West (Northern California) EU (Ireland) Die Grundfunktionen der API zur Manipulation der Daten bestehen aus den Methoden zur Speicherung eines einzelnen Elements (put) oder zur Speicherung einer Liste von Elementen (batchput) als sogenannte Stapelverarbeitungsanfrage. Des Weiteren existieren zur Abfrage der Daten Methoden, um entweder direkt ein bestimmten Element (getattributes) oder verschiedene Elemente, welche bestimmte Kriterien erfüllen (select), abzufragen. Sämtliche in der Amazon SimpleDB abgespeicherten Daten werden automatisch im Hintergrund indiziert, um mit Hilfe dieses Indexes die Abfrage der Daten erheblich zu beschleunigen. Aufgrund des einfachen Aufbaus und der Beschränkung auf einige Grundoperationen in der Amazon SimpleDB muss auf komplexere Operationen wie der Verbund von Tabellen (joins), der Festlegung von semantischen Integritätsbedingungen (constraints) oder der Verwendung von Transaktionen (transactions) verzichtet werden Kosten Das Kostenmodell von Amazon besagt, dass dem Benutzer der Amazon SimpleDB nur die Kosten für die verwendeten Rechenleistungen und Speicherressourcen angerechnet werden, die für die durchgeführten Anfragen tatsächlich angefallen sind und die der Benutzer tatsächlich verwendet. Rechenleistung: Die Rechenleistung wird in Anteilen an Maschinenstunden (eines 2007er 1,7GHz Xeon Prozessors) gerechnet, welche für die Abarbeitung der Anfragen (get, put, select usw.) tatsächlich aufgewendet werden musste und ist abhängig von der jeweiligen Region (siehe Tabelle 2.1). 14

16 Amazon Web Services US-East US-West EU für die ersten 25 Maschinenstunden im Monat für jede weitere Maschinenstunde im Monat 0,140 $ 0,154 $ 0,154 $ Tabelle 2.1: Kosten der Rechenleistung in Amazon SimpleDB Datentransfer: Der ein- und ausgehende Datentransfer von Amazon SimpleDB wird in Gigabyte (GB) pro Monat gerechnet (siehe Tabelle 2.2). Für den Datentransfer zwischen verschiedenen AWS innerhalb einer Region werden keine Kosten berechnet. Der Datentransfer über Regionen hinweg wird in der einen Region als ausgehender, in der anderen Region als eingehender Datentransfer berechnet. Eingehender Datentransfer Kosten pro GB bis 30. Juni ab 30. Juni ,10 $ Ausgehender Datentransfer Kosten pro GB erstes GB im Monat - erste 10 TB im Monat 0,15 $ nächste 40 TB im Monat 0,11 $ nächste 100 TB im Monat 0,09 $ über 150 TB im Monat 0,08 $ Tabelle 2.2: Kosten des Datentransfers in Amazon SimpleDB Speicherplatz: Der durch die Benutzerdaten verbrauchte Speicherplatz wird in Gigabyte (GB) pro Monat berechnet, wobei die Kosten abhängig von der jeweiligen Region sind (siehe Tabelle 2.3). Zur Berechnung des verbrauchten Speicherplatzes wird zur Gröÿe der Ursprungsdaten jeweils 45 Bytes (für Metadaten) pro Element, pro Attributname und pro Attributwert hinzugerechnet. US-East US-West EU für das erste Gigabyte pro Monat für jedes weitere Gigabyte pro Monat 0,250 $ 0,275 $ 0,275 $ Tabelle 2.3: Kosten des Speicherplatzes in Amazon SimpleDB 15

17 Amazon Web Services Amazon Simple Storage Service (Amazon S3) Allgemeine Beschreibung Im Rahmen der AWS bietet Amazon einen Web Service namens Amazon Simple Storage Service (Amazon S3) an, der dem Benutzer ohne weiteren administrativen Aufwand einen über das Internet erreichbaren Speicher für Daten beinahe beliebiger Gröÿe zur Verfügung stellt. Der Zugri auf diesen Speicher erfolgt über eine Web Service Schnittstelle, wobei die Anfragen mit Hilfe einer API an den Speicher gestellt werden. Als API stehen hierbei die weitverbreiteten Schnittstellen 'REST' und 'SOAP' zur Verfügung, welche von den meisten bekannten Entwicklungswerkzeugen unterstützt werden. Im Hintergrund von Amazon S3 werden automatisch mehrere geographisch verteilte Kopien der gespeicherten Daten auf verschiedenen Knoten erstellt, wodurch die Zuverlässigkeit des Services und die Dauerhaftigkeit dieser Daten gewährleistet wird. Falls ein Knoten ausfällt und somit die gewünschte Redundanz der Daten gefährdet ist, wird dieser Knoten schnellstmöglich durch einen anderen Knoten ersetzt, ohne dass es zu Unterbrechungen der Verfügbarkeit dieses Services kommen würde. Da somit eventuelle Ausfälle einzelner Komponenten die Verfügbarkeit des Services nicht beeinussen (kein sogenannter 'single point of failure'), garantiert Amazon im Service Level Agreement (SLA) für Amazon S3 eine Verfügbarkeit von 99,9 % [2]. Zudem wird regelmäÿig die Integrität der gespeicherten Daten geprüft, indem intern eine Prüfsumme ('checksum') berechnet und mit dem gesicherten Sollwert verglichen wird. Falls hierbei Unregelmäÿigkeiten auftreten und die Konsistenz der Daten somit nicht mehr gegeben ist, ist der Knoten selbst dafür verantwortlich, wieder eine konsistente Kopie mit Hilfe der redundanten Daten der anderen Knoten herzustellen. Diese Prüfsummen werden des Weiteren auch bei der Übertragung über das Netzwerk verwendet, um eine eventuelle Beschädigung bei der Übertragung der Datenpakete zu erkennen. Der Benutzer kann somit mit einfachen Mitteln auf einen vollständig dezentralisierten und demzufolge hochverfügbaren und skalierenden Speicher zugreifen, ohne sich Gedanken über die tiefergehende Verwaltung oder Wartung dieses Speichers machen zu müssen Aufbau In Amazon S3 werden die Daten in sogenannten Buckets gespeichert, welche in etwa mit einem über das Internet erreichbaren Laufwerk vergleichbar sind. Um Daten im Bucket abzuspeichern, werden sogenannte Objekte angelegt, die über einen in diesem Bucket eindeutigen Objektschlüssel ('ObjectKey') referenziert werden. In der API existieren Methoden, um Objekte aus einfachen Texten (String), aus lokalen Da- 16

18 Amazon Web Services teien (File) oder aus beliebigen Eingabeströmen (InputStream) anzulegen. Zur Sicherung der Objekte vor unberechtigtem Zugri existieren Mechanismen zur Authentizierung des Benutzers, welcher auf ein Objekt zugreifen möchte. Bei der Erstellung von Objekten kann der Besitzer des Objekts festlegen, ob das Objekt privat (Zugri nur durch den Besitzer) oder öentlich (Zugri durch jeden Benutzer) ist. Des Weiteren kann der Besitzer verschiedene Lese- und Schreibrechte für spezische Benutzer festlegen, die auf das Objekt zugreifen dürfen. Beschränkungen in Amazon S3: Innerhalb von Amazon S3 wurden von Amazon Beschränkungen festgelegt, welche die Namenswahl des Buckets sowie die Gröÿe der zu speichernden Objekte betreen: Ein Account kann maximal 100 Buckets beinhalten. Ein Bucket kann eine unbegrenzte Anzahl an Objekten enthalten. Ein Objekt darf eine Gröÿe zwischen 1 Byte und 5 Gigabyte besitzen. Bucketnamen dürfen nur aus Kleinbuchstaben a...z, Ziern sowie Punkten., Unterstrichen _ und Gedankenstrichen - bestehen. Bucketnamen müssen mit einem Kleinbuchstaben oder einer Zier beginnen (und sollten nicht mit einem Gedankenstrich enden). In Bucketnamen dürfen keine zwei Punkte sowie kein Punkt und Gedankenstrich aufeinander folgen (und der Unterstrich sollte vorzugsweise nicht verwendet werden). Bucketnamen dürfen zwischen 3 und 255 Zeichen lang sein (die empfohlene Länge liegt zwischen 3 und 63 Zeichen). Bucketnamen dürfen nicht die Form einer IP-Adresse (zum Beispiel ) besitzen Funktionalität Die Übertragung der Objekte erfolgt standardmäÿig mit dem Protokoll HTTP, allerdings besteht auch die Möglichkeit, die Objekte über eine Schnittstelle für das BitTorrent- Protokoll 1 zur Verfügung zu stellen. Amazon plant in Zukunft weitere, bisher aber noch ungenannte Schnittstellen zu entwickeln. Für die Verwendung des Amazon S3 stehen dem Benutzer verschiedene Regionen zur

19 Amazon Web Services Verfügung, welche sich hinsichtlich der Latenzzeiten (abhängig vom Standort) und der Kosten (siehe Kapitel ) unterscheiden: US Standard (automatische Vermittlung zu Einrichtungen in 'Northern Virginia' oder 'Pacic Northwest') US-West (Northern California) EU (Ireland) Die Grundfunktionen in der API zur Übertragung von Objekten bestehen aus den Methoden zur Speicherung eines Objekts (putobject) im Bucket oder zur Abfrage eines Objekts (getobject) aus dem Bucket. Des Weiteren existieren unter anderem noch Methoden, um Objekte beispielsweise von einem Bucket in einen anderen Bucket zu verschieben (moveobject) oder zu kopieren (copyobject) sowie alle im Bucket vorhandenen Objekte aufzulisten (listobjects) Kosten Bei der Verwendung von Amazon S3 entstehen dem Benutzer keine Kosten im Voraus, wie dies beispielsweise für die Bereitstellung einer eigenen Speicherlösung der Fall wäre. Dementsprechend fallen auch keine laufenden Kosten für die Absicherung der Skalierbarkeit und Verfügbarkeit durch eine eventuell notwendige Erweiterung des Speichers sowie für die Wartung der Hard- und Software des Speichers an. Das Kostenmodell von Amazon besagt, dass dem Benutzer in Amazon S3 nur die Kosten für den tatsächlich für Objekte verbrauchten Speicherplatz, den ein- und ausgehenden Datentransfer sowie die Anzahl der Abfragen angerechnet werden. 18

20 Amazon Web Services Speicherplatz: Der durch die Objekte verbrauchte Speicherplatz wird in Gigabyte (GB) pro Monat berechnet, wobei die Kosten abhängig von der jeweiligen Region sind (siehe Tabelle 2.4). US Standard US-West EU für die ersten 50 Terabyte pro GB und Monat 0,150 $ 0,165 $ 0,150 $ für die nächsten 50 Terabyte pro GB und Monat 0,140 $ 0,155 $ 0,140 $ für die nächsten 400 Terabyte pro GB und Monat 0,130 $ 0,145 $ 0,130 $ für die nächsten 500 Terabyte pro GB und Monat 0,105 $ 0,120 $ 0,105 $ für die nächsten Terabyte pro GB und Monat 0,080 $ 0,095 $ 0,080 $ für über Terabyte pro GB und Monat 0,055 $ 0,070 $ 0,055 $ Tabelle 2.4: Kosten des Speicherplatzes in Amazon S3 Datentransfer: Der ein- und ausgehende Datentransfer von Amazon S3 wird in Gigabyte (GB) pro Monat gerechnet (siehe Tabelle 2.5). Für den Datentransfer zwischen verschiedenen AWS innerhalb einer Region werden keine Kosten berechnet. Der Datentransfer über Regionen hinweg wird in der einen Region als ausgehender, in der anderen Region als eingehender Datentransfer berechnet. Eingehender Datentransfer Kosten pro GB bis 30. Juni ab 30. Juni ,100 $ Ausgehender Datentransfer Kosten pro GB erste 10 TB im Monat 0,150 $ nächste 40 TB im Monat 0,110 $ nächste 100 TB im Monat 0,090 $ über 150 TB im Monat 0,080 $ Tabelle 2.5: Kosten des Datentransfers in Amazon S3 19

21 Amazon Web Services Abfragen: Jede in Amazon S3 durchgeführte Operation (putobject, getobject, usw.) wird als eigene Abfrage angerechnet, deren Kosten abhängig von der jeweiligen Region sind (siehe Tabelle 2.6). US Standard US-West EU für die Operationen 'put', 'copy', 'post' und 'list' pro Abfragen im Monat 0,010 $ 0,011 $ 0,010 $ für die sonstigen Operationen (wie 'get' usw.) pro Abfragen im Monat 0,010 $ 0,011 $ 0,010 $ Tabelle 2.6: Kosten der Abfragen in Amazon S3 Falls die von Amazon in den SLA garantierte Verfügbarkeit von 99,9 % unterschritten wird, erstattet Amazon dem Benutzer einen gewissen Prozentsatz der Kosten: Falls die Verfügbarkeit unter 99,9 % aber noch über 99 % liegt, werden 10 % der Kosten erstattet. Falls die Verfügbarkeit unter 99 % liegt, werden 25 % der Kosten erstattet Amazon Elastic Compute Cloud (Amazon EC2) Allgemeine Beschreibung Im Rahmen der AWS bietet Amazon einen Web Service namens Amazon Elastic Compute Cloud (Amazon EC2) an, welcher dem Benutzer dynamische Rechenkapazitäten zur Verfügung stellt, um beliebige Anwendungen in der sogenannten Cloud (also einer metaphorischen Wolke) zu betreiben. Hierbei kann eine beliebige Anzahl an sogenannten Instanzen eingesetzt werden, die innerhalb der Cloud einen virtuellen Rechner darstellen. Die Skalierung der Rechenleistung erfolgt durch das Starten von neuen Instanzen bzw. dem Beenden laufender Instanzen und kann somit an den jeweiligen Bedarf angepasst werden. Der Zugri auf die Instanzen erfolgt über eine Web Service Schnittstelle, wobei die Anfragen mit Hilfe einer API an die Cloud gestellt werden und somit die Entwicklung von skalierenden Web-Anwendungen erleichtert wird. 20

22 Amazon Web Services Funktionalität Jede Instanz in Amazon EC2 basiert auf einem Amazon Machine Image (AMI), welches ein virtuelles Maschinenabbild darstellt. Zu diesem Zweck stehen in Amazon EC2 bereits kongurierte öentliche AMI als Vorlagen zur Verfügung, welche einfach als Grundlage für eine zu startende Instanz verwendet werden können. Des Weiteren können auch benutzerdenierte AMI erstellt werden, welche die vom Benutzer gewünschten Anwendungen und Bibliotheken sowie beliebige Daten und Kongurationseinstellungen enthalten können. Nachdem das AMI erfolgreich hochgeladen und registriert wurde, können davon beliebig viele Instanzen gestartet, überwacht oder wieder beendet werden. Da der lokale Speicher der Instanzen nicht persistent ist und mit Beendigung der Instanz verloren geht, besteht noch die Möglichkeit, einen Elastic Block Store (EBS) von Amazon als zusätzliches Laufwerk an die Instanz anzuhängen, auf welchem beliebige Dateien persistent abgespeichert werden können. Von diesen Laufwerken können zudem Speicherauszüge als Grundlage für neue Laufwerke in Amazon S3 abgespeichert werden. Nachdem eine Instanz gestartet wurde, ist sie über eine öentliche DNS-Adresse erreichbar. Da diese Adressen allerdings dynamisch vergeben werden, kann der Benutzer innerhalb seines Accounts statische IP-Adressen (die sogenannten Elastic IPs) reservieren. Diese IP-Adressen können jeder laufenden Instanz zugeordnet werden, wodurch diese Instanz unter dieser statischen IP-Adresse erreichbar ist. Ein eventueller Ausfall dieser Instanz kann nun kompensiert werden, indem die statische IP-Adresse einfach stattdessen einer alternativen fehlerfreien Instanz zugeordnet wird und sämtlicher Netzwerkverkehr somit auf diese Instanz umgeleitet wird. Für die Verwendung von Amazon EC2 stehen dem Benutzer verschiedene Regionen zur Verfügung, die sich hinsichtlich der Latenzzeiten (abhängig vom Standort) und der Kosten (siehe Kapitel ) unterscheiden: US-East (Northern Virginia) US-West (Northern California) EU (Ireland) Die einzelnen Regionen sind zudem noch weiter in sogenannte Verfügbarkeitszonen unterteilt (zum Beispiel 'us-east-1a', 'us-east-1b', usw.). Die Verfügbarkeitszonen bezeichnen voneinander unabhängige, getrennte Standorte, welche nicht durch Fehler in anderen Zonen beeinusst werden, sich aber dennoch über das Netzwerk mit geringen Latenzzeiten verbinden können. Als einzige Beschränkung hat Amazon festgelegt, dass ein Benutzer von Amazon EC2 innerhalb seines Accounts maximal 20 Instanzen pro Region gleichzeitig ausführen kann. 21

23 Amazon Web Services Kongurationen Instanztypen: Für die Amazon EC2 Instanzen stehen mehrere Instanztypen in zwei Klassen zur Verfügung (siehe Tabelle 2.7), die sich bezüglich Gröÿe des Arbeitsspeichers und Speicherplatzes sowie der Anzahl der Prozessorkerne unterscheiden. Die Angabe der Prozessorkerne erfolgt hierbei in Anzahl der 'EC2 Compute Units' (ECU), wobei ein ECU der Rechenkapazität eines 2007 Opteron oder 2007 Xeon Prozessors zwischen 1,0 und 1,2 GHz entspricht. Instanztyp Arbeits- Prozessorkerne lokaler Plattspeicher Speicher form Standard Instanzen Small 1,7 GB 1 ECU (1 x 1 ECU) 160 GB 32-bit Large 7,5 GB 4 ECU (2 x 2 ECU) 850 GB 64-bit Extra Large 15 GB 8 ECU (4 x 2 ECU) 1690 GB 64-bit High-Memory Instanzen Extra Large 17,1 GB 6,5 ECU (2 x 3,25 ECU) 420 GB 64-bit Double Extra Large 34,2 GB 13 ECU (4 x 3,25 ECU) 850 GB 64-bit Quadruple Extra Large 68,4 GB 26 ECU (8 x 3,25 ECU) 1690 GB 64-bit High-CPU Instanzen Medium 1,7 GB 5 ECU (2 x 2,5 ECU) 350 GB 32-bit Extra Large 7 GB 20 ECU (8 x 2,5 ECU) 1690 GB 64-bit Tabelle 2.7: Instanztypen in Amazon EC2 Betriebssysteme: Für die AMI stehen eine Vielzahl an vorkongurierten Systemen zur Verfügung. Weitere Betriebssysteme können mit Hilfe der vorhandenen Bundling- Werkzeuge ebenfalls verwendet werden. Momentan werden in Amazon EC2 unter anderem die folgenden Betriebssysteme unterstützt: Red Hat Enterprise Linux Windows Server 2003/2008 Oracle Enterprise Linux OpenSolaris Ubuntu Linux Fedora Gentoo Linux Debian opensuse Linux 22

24 Amazon Web Services Zusätzliche Software: Amazon stellt eine Vielzahl an kostenlosen AMI zur Verfügung, welche bereits mit zusätzlicher Software ausgestattet sind und verwendet werden können: Datenbanken: IBM DB2, IBM Informix Dynamic Server, Microsoft SQL Server Standard 2005, MySQL Enterprise, Oracle 11g Stapelverarbeitung: Hadoop, Condor, Open MPI Web Hosting: Apache HTTP, IIS/Asp.Net, IBM Lotus Web Content Management, IBM WebSphere Portal Server Entwicklungsumgebungen: IBM smash, JBoss Enterprise Application Platform, Ruby on Rails Application Servers: IBM WebSphere Application Server, Java Application Server, Oracle WebLogic Server Video Encoding & Streaming: Wowza Media Server Pro, Windows Media Server Kosten Das Kostenmodell von Amazon besagt, dass dem Benutzer der Amazon EC2 nur die Kosten für die verwendeten Rechenkapazitäten angerechnet werden, welche durch den Betrieb der Instanzen tatsächlich angefallen sind. Instanzen: Die Abrechnung für verwendete Instanzen erfolgt über die tatsächliche Betriebszeit der Instanzen. Dabei existieren verschiedene Möglichkeiten, Instanzen für den Betrieb zu reservieren, die sich hinsichtlich der Kosten unterscheiden. Instanzen auf Abruf: Bei Instanzen auf Abruf wird die Betriebszeit der Instanzen für den jeweiligen Instanztyp pro tatsächlich anfallender Stunde abgerechnet. Es müssen dabei keine langfristigen Verpichtungen eingegangen oder Zahlungen im Voraus geleistet werden. Die abzurechnende Rate für die Instanzen ist abhängig von der jeweiligen Region sowie dem verwendeten Instanztyp und Betriebssystem (siehe Tabelle 2.8). 23

25 Amazon Web Services US-East US-West EU Instanztyp Linux Windows Linux Windows Linux Windows Standard Instanzen auf Abruf Small 0,085 $ 0,12 $ 0,095 $ 0,13 $ 0,095 $ 0,12 $ Large 0,34 $ 0,48 $ 0,38 $ 0,52 $ 0,38 $ 0,48 $ Extra Large 0,68 $ 0,96 $ 0,76 $ 1,04 $ 0,76 $ 0,96 $ High-Memory Instanzen auf Abruf Extra Large 0,50 $ 0,62 $ 0,57 $ 0,69 $ 0,57 $ 0,62 $ Double Extra Large 1,20 $ 1,44 $ 1,34 $ 1,58 $ 1,34 $ 1,44 $ Quadruple Extra Large 2,40 $ 2,88 $ 2,68 $ 3,16 $ 2,68 $ 2,88 $ High-CPU Instanzen auf Abruf Medium 0,17 $ 0,29 $ 0,19 $ 0,31 $ 0,19 $ 0,29 $ Extra Large 0,68 $ 1,16 $ 0,76 $ 1,24 $ 0,76 $ 1,16 $ Tabelle 2.8: Kosten von Instanzen auf Abruf in Amazon EC2 Reservierte Instanzen: Für reservierte Instanzen fällt eine einmalige Zahlung im Voraus an, um die Instanz entweder für ein Jahr oder für drei Jahre zu reservieren (siehe Tabelle 2.9). Anschlieÿend wird die Betriebszeit der Instanzen für den jeweiligen Instanztyp pro tatsächlich anfallender Stunde zu deutlich geringeren Raten abgerechnet, welche allerdings von der jeweiligen Region sowie dem verwendeten Instanztyp und Betriebssystem abhängig sind (siehe Tabelle 2.10). Instanztyp 1 Jahr 3 Jahre Reservierte Standard Instanzen Small 227,5 $ 350 $ Large 910 $ 1400 $ Extra Large 1820 $ 2800 $ Reservierte High-Memory Instanzen Extra Large 1325 $ 2000 $ Double Extra Large 3185 $ 4900 $ Quadruple Extra Large 6370 $ 9800 $ Reservierte High-CPU Instanzen Medium 455 $ 700 $ Extra Large 1820 $ 2800 $ Tabelle 2.9: Einmalige Kosten von reservierten Instanzen in Amazon EC2 24

26 Amazon Web Services US-East US-West EU Instanztyp Linux Windows Linux Windows Linux Windows Reservierte Standard Instanzen Small 0,03 $ 0,05 $ 0,04 $ 0,06 $ 0,04 $ 0,06 $ Large 0,12 $ 0,20 $ 0,16 $ 0,24 $ 0,16 $ 0,24 $ Extra Large 0,24 $ 0,40 $ 0,32 $ 0,48 $ 0,32 $ 0,48 $ Reservierte High-Memory Instanzen Extra Large 0,17 $ 0,24 $ 0,24 $ 0,32 $ 0,24 $ 0,32 $ Double Extra Large 0,42 $ 0,55 $ 0,56 $ 0,69 $ 0,56 $ 0,69 $ Quadruple Extra Large 0,84 $ 1,10 $ 1,12 $ 1,38 $ 1,12 $ 1,38 $ Reservierte High-CPU Instanzen Medium 0,06 $ 0,125 $ 0,08 $ 0,145 $ 0,08 $ 0,145 $ Extra Large 0,24 $ 0,50 $ 0,32 $ 0,58 $ 0,32 $ 0,58 $ Tabelle 2.10: Betriebskosten von reservierten Instanzen in Amazon EC2 Spot-Instanzen: Bei Spot-Instanzen legt der Benutzer einen maximalen Preis pro Stunde Betriebszeit fest, den er bereit ist für den Betrieb von bestimmten Instanztypen zu zahlen. Der von Amazon festgelegte aktuelle Spot-Preis passt sich in den verschiedenen Regionen an die jeweilige momentane Auslastung innerhalb dieser Region an. Die Instanz wird anschlieÿend ausgeführt, solange der aktuelle Spot- Preis unter dem vom Benutzer festgelegten Maximalpreis liegt, ansonsten wird die Instanz beendet. Der Benutzer zahlt somit niemals mehr als den von ihm festgelegten Maximalpreis. Es müssen dabei keine langfristigen Verpichtungen eingegangen oder Zahlungen im Voraus geleistet werden. Die abzurechnende Rate für die Instanzen ist abhängig von der jeweiligen Region sowie dem verwendeten Instanztyp und Betriebssystem (siehe Tabelle 2.11). Anmerkung: Da sich die Spot-Preise ständig ändern, ist die Tabelle nur ein beispielhafter Auszug für die Spot-Preise zu einem zufälligen Zeitpunkt. 25

27 Amazon Web Services US-East US-West EU Instanztyp Linux Windows Linux Windows Linux Windows Standard Instanzen Small 0,03 $ 0,05 $ 0,04 $ 0,068 $ 0,038 $ 0,07 $ Large 0,119 $ 0,197 $ 0,155 $ 0,276 $ 0,155 $ 0,258 $ Extra Large 0,24 $ 0,403 $ 0,309 $ 0,55 $ 0,314 $ 0,554 $ High-Memory Instanzen Extra Large 0,175 $ 0,249 $ 0,243 $ 0,307 $ 0,23 $ 0,325 $ Double Extra Large 0,428 $ 0,552 $ 0,536 $ 0,769 $ 0,574 $ 0,755 $ Quadruple Extra Large 0,856 $ 1,123 $ 1,172 $ 1,394 $ 1,098 $ 1,448 $ High-CPU Instanzen Medium 0,061 $ 0,127 $ 0,077 $ 0,162 $ 0,077 $ 0,17 $ Extra Large 0,231 $ 0,484 $ 0,305 $ 0,676 $ 0,331 $ 0,638 $ Tabelle 2.11: Kosten von Spot-Instanzen in Amazon EC2 (zufälliger Zeitpunkt) Datentransfer: Der ein- und ausgehende Datentransfer von Amazon EC2 wird in Gigabyte (GB) pro Monat gerechnet (siehe Tabelle 2.12). Für den Datentransfer zwischen verschiedenen AWS innerhalb einer Region werden keine Kosten berechnet. Der Datentransfer über Regionen hinweg wird in der einen Region als ausgehender, in der anderen Region als eingehender Datentransfer berechnet. Eingehender Datentransfer Kosten pro GB bis 30. Juni ab 30. Juni ,10 $ Ausgehender Datentransfer Kosten pro GB erste 10 TB im Monat 0,15 $ nächste 40 TB im Monat 0,11 $ nächste 100 TB im Monat 0,09 $ über 150 TB im Monat 0,08 $ Ein-/Ausgehender Datentransfer zwischen Instanzen in verschiedenen Verfügbarkeitszonen oder mit Hilfe öentlicher IP-Adressen pro GB im Monat 0,01 $ Tabelle 2.12: Kosten des Datentransfers in Amazon EC2 26

28 Amazon Web Services Speicher: Der in Amazon EBS verbrauchte Speicherplatz wird in Gigabyte (GB) pro Monat berechnet, wobei die Kosten abhängig von der jeweiligen Region sind (siehe Tabelle 2.13). Zusätzlich dazu werden die Operationen für in Amazon S3 gespeicherte Speicherauszüge abgerechnet. US-East US-West EU Kosten für EBS Speicher pro Gigabyte und Monat 0,10 $ 0,11 $ 0,11 $ Kosten für 1 Million EBS I/O-Anfragen 0,10 $ 0,11 $ 0,11 $ Kosten für S3 Speicher pro Gigabyte und Monat (Speicherauszug) 0,15 $ 0,18 $ 0,15 $ Kosten für PUT-Operationen (Speicherauszug abspeichern) 0,01 $ 0,012 $ 0,01 $ Kosten für GET-Operationen (Speicherauszug abrufen) 0,01 $ 0,012 $ 0,01 $ Tabelle 2.13: Kosten des Speicherplatzes in Amazon EC2 IP-Adressen: Für die statischen IP-Adressen (Elastic IP) innerhalb eines Accounts (reservierte IP-Adressen) fallen nur Kosten pro Stunde an, falls sie momentan nicht zu einer laufenden Instanz zugeordnet sind. Auch jede erneute Zuordnung der IP-Adresse wird angerechnet, falls eine bestimmte kostenfreie Stufe überschritten wird (siehe Tabelle 2.14). Kosten für reservierte IP-Adressen pro Stunde zu Instanzen zugeordnete IP-Adressen - nicht zugeordnete IP-Adressen 0,01 $ Kosten für die Zuordnung von IP-Adressen für die ersten 100 Zuordnungen - für jede weitere Zuordnung 0,10 $ Tabelle 2.14: Kosten der IP-Adressen in Amazon EC2 Für den Betrieb dieses Web Service garantiert Amazon in den SLA für Amazon EC2 für jede Region eine jährliche Betriebszeit von 99,95 % [1]. Das bedeutet, dass der Service pro Jahr mindestens zu 99,95 % der Zeit verfügbar ist. Falls diese Grenze unterschritten wird, erstattet Amazon 10 % der abgerechneten Kosten. 27

29 Amazon Web Services Amazon Simple Queue Service (Amazon SQS) Allgemeine Beschreibung Im Rahmen der AWS bietet Amazon einen Web Service namens Amazon Simple Queue Service (Amazon SQS) an, welcher dem Benutzer ohne weiteren administrativen Aufwand eine zuverlässige und skalierende MessageQueue zur Verfügung stellt. Im Hintergrund werden sämtliche Nachrichten der MessageQueues redundant auf mehreren Servern und Datenzentren gespeichert, um die Zuverlässigkeit des Services zu gewährleisten. Des Weiteren besitzt der Service laut Amazon die Kapazität, um einer beliebigen Anzahl an Rechnern den Versand und Empfang einer beliebigen Anzahl an Nachrichten zu ermöglichen, wodurch die Skalierbarkeit des Services sichergestellt ist [3]. Der Zugri auf diese MessageQueue erfolgt über eine Web Service Schnittstelle, wobei die Nachrichten in der MessageQueue mit Hilfe einer API eingereiht, abgerufen oder gelöscht werden Aufbau In Amazon SQS können MessageQueues angelegt werden, in welchen Nachrichten eingereiht, abgerufen und gelöscht werden können. Nach Abruf einer Nachricht aus einer MessageQueue ist diese Nachricht für eine festgelegte Zeitspanne (der sogenannten VisibilityTimeout) für weitere Abrufe unsichtbar. Falls die Nachricht in dieser Zeitspanne nicht gelöscht wird (oder die Zeitspanne für diese Nachricht nicht vom Benutzer verlängert wird), steht sie danach wieder zum Abruf zur Verfügung. Beschränkungen von Amazon SQS: Innerhalb von Amazon SQS wurden von Amazon Beschränkungen festgelegt, welche die Gröÿe sowie die Aufbewahrungsdauer der Nachrichten in den MessageQueues betreen: Ein Account kann eine unbegrenzte Anzahl an MessageQueues beinhalten. Eine MessageQueue kann eine unbegrenzte Anzahl an Nachrichten enthalten. Eine Nachricht darf eine maximale Gröÿe von acht Kilobyte an Text (in einem beliebigen Format) besitzen. Nachrichten werden bis zu vier Tage in der MessageQueue aufbewahrt. Nachrichten können simultan gesendet und empfangen werden. 28

30 Amazon Web Services Funktionalität Für die Verwendung von Amazon SQS stehen dem Benutzer verschiedene Regionen zur Verfügung, die sich hinsichtlich der Latenzzeiten (abhängig vom Standort) unterscheiden: US-East (Northern Virginia) US-West (Northern California) EU (Ireland) Die Grundfunktionen in der API bestehen aus den Methoden für die Erstellung von MessageQueues (createqueue) sowie den Versand (sendmessage) und Empfang (receivemessage) oder der letztendlichen Entfernung (deletemessage) von Nachrichten Kosten Bei der Verwendung von Amazon SQS entstehen dem Benutzer weder Kosten im Voraus noch feste Kosten für den Betrieb des Services. Das Kostenmodell von Amazon besagt, dass dem Benutzer in Amazon SQS nur die Kosten für die tatsächlich angefallenen Abrufe sowie dem ein- und ausgehenden Datentransfer angerechnet werden. Abfragen: Jede in Amazon SQS durchgeführte Operation (createqueue, sendmessage, usw.) wird als eigene Abfrage angerechnet (siehe Tabelle 2.15). Kosten für alle Operationen im Monat (wie 'createqueue', 'sendmessage' usw.) pro Abfragen 0,01 $ Tabelle 2.15: Kosten der Abfragen in Amazon SQS Datentransfer: Der ein- und ausgehende Datentransfer von Amazon SQS wird in Gigabyte (GB) pro Monat gerechnet (siehe Tabelle 2.16). Für den Datentransfer zwischen verschiedenen AWS innerhalb einer Region werden keine Kosten berechnet. Der Datentransfer über Regionen hinweg wird in der einen Region als ausgehender, in der anderen Region als eingehender Datentransfer berechnet. 29

31 Projekt Cmgrid Eingehender Datentransfer Kosten pro GB bis 30. Juni ab 30. Juni ,10 $ Ausgehender Datentransfer Kosten pro GB erste 10 TB im Monat 0,15 $ nächste 40 TB im Monat 0,11 $ nächste 100 TB im Monat 0,09 $ über 150 TB im Monat 0,08 $ Tabelle 2.16: Kosten des Datentransfers in Amazon SQS 2.2 Projekt Cmgrid Um die Prozesse und Entscheidungen in Unternehmen nachvollziehbar und überprüfbar zu halten, müssen diese entsprechend dokumentiert werden, und die prozess- bzw. entscheidungsrelevanten Dokumente müssen aufbewahrt werden. Insbesondere umfasst dies auch Nachrichten, die über digitale Kommunikationsträger wie und Instant- Messaging übertragen werden. Hierbei stellt deren Aufbewahrung, deren Aufbereitung und deren Aunden entsprechend den vorgeschriebenen Verordnungen bei groÿen Unternehmen mit vielen Nachrichten eine groÿe Herausforderung dar Rechtliche Vorschriften Das Projekt Cmgrid (oder auch CMaaS für Content Management as a Service) wurde aufgrund neuer rechtlicher Vorschriften ins Leben gerufen, die jedem Unternehmen die vollständige Archivierung aller gesendeten und empfangenen s vorschreibt [6]. Aufgrund dieser Vorschriften bestand für groÿe Unternehmen mit hohem -Aufkommen der Bedarf an einem Projekt, welches die Kapazitäten bieten konnte, um eine groÿe Menge an s pro Sekunde zu archivieren. Des Weiteren muss die Archivierung im Projekt die Merksätze des Verbands Organisationsund Informationssysteme (VOI) zur revisionssicheren elektronischen Archivierung erfüllen [7]: Jede muss unveränderbar archiviert werden. Keine darf während der Archivierung oder im Archiv selbst verloren gehen. Jede muss wieder aundbar sein. Bei der Suche muss genau die gewünschte wiedergefunden werden. 30

32 Projekt Cmgrid Keine darf vor Ablauf ihrer Lebenszeit zerstört werden. Die Form der muss exakt erhalten bleiben. Das Aunden einer darf nicht zu lange dauern. Jede Änderung im Archiv muss vollständig protokolliert werden, um den ursprünglichen Zustand wiederherstellen zu können. Das Archiv muss ohne Informationsverlust auf neue Plattformen, Medien, Softwareversionen und Komponenten migriert werden können. Die gesetzlichen Bestimmungen bezüglich der Sicherheit und dem Schutz der Daten müssen über die gesamte Lebenszeit des Archivs sichergestellt werden Vorhandene Version Im Rahmen eines durch das IBM Center of Advanced Studies (CAS) geförderten Projektes wurde bereits ein Prototyp für eine entsprechende Archivierungslösung implementiert. Diese zeichnet sich durch dynamische Skalierbarkeit, Lastverteilung und eine Volltextsuche aus. Für die Skalierbarkeit und die Lastverteilung ist eine dynamische Datenorganisation notwendig. Diese wird durch Verwendung einer Distributed Hash Table (DHT) aus dem Bereich des Peer-to-Peer-Computings realisiert. Beim Hinzufügen oder Entfernen eines Knotens erfolgt dadurch automatisch eine Anpassung an den geänderten Systemzustand. Während dieser Anpassungsphase bleibt der globale Zustand des Systems konsistent und ezient abfragbar und es können weiterhin Schlüssel eingefügt werden. Die Volltextsuche erfolgt verteilt über die im System vorhandenen Knoten, wobei als lokale Lösung auf den Knoten Apache Lucene eingesetzt wird. Apache Lucene ist eine Bibliothek, die das Erstellen und Durchsuchen von Text-Indizes unterstützt. Derzeit werden verschiedene Konzepte für das Monitoring untersucht und integriert. Auf Basis der erfassten Daten soll dann eine regelbasierte automatische Skalierung erfolgen, damit Vorgaben für bestimmte Kennzahlen (z.b. Anzahl der pro Sekunde archivierter Nachrichten) eingehalten werden. Die vorhandene Version des Prototyps bietet somit bereits die Möglichkeit, eine groÿe Menge an s in einem verteilten System zu archivieren. Dafür werden allerdings mehrere über ein Netzwerk verbundene Rechner benötigt, welche die Archivierung gemeinsam durchführen und welche von einem einzelnen Rechner koordiniert werden. Somit ist die maximale Rechenkapazität auf die Summe der vorhandenen Rechner begrenzt und ein eventueller höherer Bedarf kann nur durch den Erwerb neuer Rechner bewältigt werden. Bisher wurde das System lediglich auf dem hauseigenen Bladecenter getestet. Hierbei kam zur Speicherung der Metadaten und der Daten die IBM DB2 und der IBM Resource Manager zum Einsatz. 31

33 Projekt Cmgrid Anforderungen an die neue Version In Rahmen dieser Diplomarbeit sollen die folgenden Anforderungen untersucht und im vorhandenen Prototyp realisiert werden. Anschlieÿend soll der entwickelte Prototyp verschiedenen Leistungstests unterzogen werden und eine Kostenanalyse hinsichtlich der laufenden Kosten für die AWS erstellt werden Ersetzung bisheriger Komponenten durch AWS Das Ziel dieser Diplomarbeit ist die Entwicklung eines mandantenfähigen Software-Dienstes für die Archivierung von s. Zur Realisierung des Dienstes soll der erwähnte Prototyp sowie die von Amazon angebotenen Infrastruktur- und Plattformdienste eingesetzt werden. Hierbei soll berücksichtigt werden, dass es unterschiedliche Varianten hinsichtlich des Nutzungs- und Integrationsgrades der angebotenen Dienste gibt Mandantenfähigkeit Eine besonders hervorzuhebende Eigenschaft, die bei der Entwicklung berücksichtigt werden muss, ist die Mandantenfähigkeit. In diesem Zusammenhang bedeutet dies, dass der Dienst mehreren Mandanten zur Verfügung gestellt werden kann, diese jedoch soweit voneinander isoliert sind, dass sie sich gegenseitig nicht beeinussen. Weitere Bedingungen hinsichtlich dieser Eigenschaft sind der kostengünstige Betrieb und die kostengünstige Verwaltung des Dienstes, auch für eine Vielzahl von Mandanten Skalierbarkeit Eine weitere Anforderung ist die nahtlose Integration neuer PAI-Knoten in die vorhandene Infrastruktur bzw. die Entfernung von PAI-Knoten aus der Infrastruktur. Dabei soll es zu keinen Unterbrechungen des Archivierungsbetriebs kommen und die Umgebung soll sich (gröÿtenteils) automatisch an den neuen Zustand anpassen. Hinweis: PAI steht in diesem Zusammenhang für 'Parse Archive Index (PAI)' und ein PAI-Knoten stellt eine Instanz innerhalb der Cloud dar, welche für den Archivierungsprozess der Dokumente bestehend aus Analyse ('parse'), Archivierung ('archive') und Indizierung ('index') verantwortlich ist. 32

34 3 Implementierung In diesem Kapitel wird die vollständige Implementierung der entwickelten Variante des Prototypen erläutert. Zunächst werden die Komponenten zur Verwendung der AWS, anschlieÿend die darauf basierenden, übergeordneten Schichten und zuletzt die allgemeine Verwaltung der AWS beschrieben. 3.1 Komponenten zur Verwendung der AWS Sämtliche Komponenten zur Verwendung der AWS benden sich im Package cmgridaws, welches die Grundfunktionen für den Zugri auf die einzelnen Services über jeweils eigene Komponenten zur Verfügung stellt. In Abbildung 3.1 bendet sich ein vereinfachtes Klassendiagramm als grober Überblick über die Komponenten, die in diesem Abschnitt genauer erläutert werden. Abbildung 3.1: Vereinfachtes Klassendiagramm der Komponenten 33

35 Komponenten zur Verwendung der AWS Die Komponente Common enthält gemeinsam verwendete Methoden. Die Komponente SimpleDB enthält die Funktionalität zur Abfrage der Elemente und Attribute in den Domains der Amazon SimpleDB. Die Komponente S3 enthält die Funktionalität zur Übertragung der Objekte in die Buckets von Amazon S3. Die Komponente EC2 enthält die Funktionalität zur Verwaltung der Instanzen in Amazon EC2. Die Komponente SQS enthält die Funktionalität zum Versand und Empfang von Nachrichten in den MessageQueues von Amazon SQS Externe Bibliotheken Für die Verwendung der AWS innerhalb des Projekts mussten die folgenden externen Bibliotheken eingebunden werden, wodurch im Projekt jeweils eine eigene API in Java für die einzelnen Komponenten zur Verfügung steht: Amazon SimpleDB: Für die Verwendung von Amazon SimpleDB wurde die von Amazon bereitgestellte API 'amazon-simpledb java-library' 1 in der zum Zeitpunkt des Beginns dieser Arbeit aktuellen Version eingebunden. Amazon S3: Für die Verwendung von Amazon S3 wurde die Open Source API 'jets3t-0.7.1' 2 in der zum Zeitpunkt des Beginns dieser Arbeit aktuellen Version eingebunden. Amazon EC2 und SQS: Für die Verwendung von Amazon EC2 und SQS wurde die gemeinsame API 'typica-1.6' 3 in der zum Zeitpunkt des Beginns dieser Arbeit aktuellen Version 1.6 eingebunden Common Die Komponente Common enthält die Klasse Common, deren Methoden statisch (static) implementiert sind und von mehreren Komponenten gemeinsam verwendet werden. Beispielsweise sind in dieser Klasse die Zugangsdaten eines Amazon Accounts (bestehend aus Access Key und Secret Access Key) gespeichert, welche für die Authentizierung des Benutzers in jedem der AWS benötigt werden. Für diese Arbeit wurde der Universi

36 Komponenten zur Verwendung der AWS tät zu Studienzwecken ein Amazon Account inklusive eines Freibetrags von $ zur Verfügung gestellt. Des Weiteren benden sich in dieser Klasse Methoden zur Abfrage der IP sowie zur Konvertierung und Formatierung von Datums- oder Gröÿenangaben SimpleDB Die Komponente SimpleDB stellt innerhalb des Projekts die Schnittstelle zur externen Bibliothek von Amazon SimpleDB (siehe Kapitel 3.1.1) zur Verfügung. Sämtliche Methoden dieser Komponente benden sich in der Klasse SimpleDB und sind statisch (static) implementiert. Die Klasse SimpleDB ist intern nach dem Entwurfsmuster einer sogenannten 'Singleton'- Klasse entworfen. Das heiÿt, dass sämtliche Zugrie der statischen Methoden darin über eine einzelne statische Instanz des SimpleDB-Services aus der externen Bibliothek ablaufen. Beim ersten Zugri auf eine der öentlichen Methoden dieser Klasse wird zunächst der Konstruktor für die Service-Klasse aufgerufen, der die zu verwendende Instanz des Services erstellt. Da allerdings der parallele gleichzeitige Zugri auf diese Komponente möglich ist, wird der Service für weitere Zugrie gesperrt, bis die Erstellung des Services abgeschlossen ist. Dadurch ist gewährleistet, dass der Service innerhalb dieser Komponente nur einmal erstellt wird und jeder weitere Zugri über diese Instanz abläuft. Da die Berechtigung zur Verwendung von Amazon SimpleDB an einen Amazon Account geknüpft ist, müssen sowohl der Access Key als auch der Secret Access Key des zu verwendenden Accounts an den Konstruktor des SimpleDB-Services übergeben werden. Hierfür werden die in der Komponente Common festgelegten Zugangsdaten verwendet (siehe Kapitel 3.1.2). Zudem wird zur Konguration des Services dem Konstruktor eine Kongurationsklasse aus der externen Bibliothek übergeben, in welcher beispielsweise die Region der Amazon SimpleDB (US oder EU) festgelegt werden kann Allgemeine Methoden Die allgemeinen Methoden dieser Klasse stellen die Grundfunktionen der Amazon SimpleDB zur Verfügung (also die Erstellung, die Verwaltung und die Abfrage von Domains, Elementen und Attributen) und können somit in die folgenden drei Bereiche unterteilt werden: Verwaltung von Domains: In diesem Bereich können neue Domains mit beliebigen (aber innerhalb des Accounts eindeutigen) Namen erstellt oder bereits bestehende Domains wieder komplett gelöscht werden. Zudem können hier Metadaten (wie die Anzahl an Elementen sowie die Anzahl an Attributnamen und -werten, und deren Gröÿe in 35

37 Komponenten zur Verwendung der AWS Bytes) zu einzelnen Domains abgefragt werden. Zuletzt besteht in diesem Bereich noch die Möglichkeit, eine vollständige Liste aller in diesem Account verfügbaren Domains abzurufen. Verwaltung von Elementen bzw. Attributen: Wie bereits erwähnt bestehen Elemente in den Domains nur solange sie mindestens ein Attribut enthalten. Somit ist die Verwaltung der Elemente unweigerlich an die Verwaltung ihrer Attribute gekoppelt. In diesem Bereich können die Attribute eines bestimmten Elements über den eindeutigen Bezeichner des Elements abgefragt werden. Ebenso können hier neue Attribute zu einem Element hinzugefügt werden, wobei das Element wiederum über den Bezeichner identiziert wird (falls für den angegebenen Bezeichner hierbei bisher kein Element existiert, wird das Element angelegt). Darüber hinaus kann für die Erstellung von Attributen (und gegebenenfalls ihrer zugehörigen Elemente) eine Stapelverarbeitungsanfrage (batch) verwendet werden, die mit einer Liste an Elementen und ihren jeweils zu erstellenden Attributen ausgeführt wird. Somit können mit einer einzelnen Anfrage gleich mehrere Elemente mitsamt Attributen übertragen werden, wodurch vermieden wird, dass für jedes Element eine eigene Anfrage gestartet werden muss. Allerdings unterliegt die Stapelverarbeitung (sowie jede andere Anfrage) bestimmten, von Amazon festgelegten Beschränkungen, welche den maximalen Umfang einer einzelnen Anfrage begrenzen (eine Anfrage darf eine maximale Gesamtgröÿe von einem Megabyte besitzen und aus höchstens 25 Elementen bestehen). Zuletzt können in diesem Bereich Attribute eines Elements auch wieder gelöscht werden. Um das zu löschende Attribut eindeutig identizieren zu können, muss dabei sowohl der Name als auch der Wert des Attributs angegeben werden (da Elemente mehrwertige Attribute mit gleichem Namen enthalten können). Ausführung von Auswahlanfragen: In diesem Bereich können Auswahlanfragen ausgeführt werden, die die Elemente einer Domain nach bestimmten Kriterien durchsuchen und die alle Elemente zurückliefern, welche diesen Kriterien entsprechen. Diese Anfragen sind annähernd mit den Anfragen in der Structured Query Language (SQL) vergleichbar, da sie eine ähnliche Struktur (select-from-where), jedoch einen deutlich geringeren Funktionsumfang besitzen: Anfrageteil 'select' (erforderlich): In diesem Teil der Anfrage werden die Namen der Attribute angegeben, welche von der Anfrage zurückgeliefert werden sollen. Durch Angabe des Sternchens * besteht die Möglichkeit, sämtliche Attribute der zurückgelieferten Elemente anzufordern. Darüber hinaus können durch Angabe von itemname() nur die Namen der Elemente ohne deren Attribute abgefragt werden. Mit Hilfe der Angabe von count(*) wird nur die Anzahl an Elementen abgefragt, welche die angegebenen Kriterien erfüllen. 36

38 Komponenten zur Verwendung der AWS Die weiteren in SQL vorhandenen Aggregationen (wie zum Beispiel min(), max(), avg(), sum() usw.) sind in den Auswahlanfragen von Amazon SimpleDB nicht verfügbar. Anfrageteil 'from' (erforderlich): In diesem Teil der Anfrage wird die Domain angegeben, die nach den angegebenen Kriterien durchsucht werden soll. Im Unterschied zu SQL kann eine Anfrage hier nur eine einzelne Domain durchsuchen und deren Elemente zurückliefern. Anfrageteil 'where' (optional): In diesem Teil der Anfrage werden die Kriterien angegeben, nach welchen die Domain durchsucht werden soll. Im einfachsten Fall werden hier keine Kriterien angegeben und die Anfrage liefert somit alle Elemente zurück. Ansonsten können die Kriterien durch einfache Ausdrücke festgelegt werden, welche mit den Operatoren and bzw. or verknüpft oder mit not negiert, mit Klammern geschachtelt oder mit intersection verbunden werden. Ein Ausdruck wiederum besteht aus einem einfachen lexikographischen Vergleich zweier Werte. Allerdings werden alle Werte in den Domains als Text aufgefasst, wodurch sich beispielsweise Schwierigkeiten beim Vergleich von Zahlenwerten ergeben (der Text '2' ist lexikographisch gröÿer als '10'). Ähnlich wie im Anfrageteil 'select' können hier wieder einzelne Attribute mit Hilfe ihrer Namen (zum Beispiel Farbe = 'blau') oder die Bezeichner der Elemente mit Hilfe von itemname() verglichen werden (zum Beispiel itemname() = 'id123'). Die zur Verfügung stehenden Operatoren können in der Tabelle 3.1 eingesehen werden. Die komplexeren in SQL bekannten Strukturen (wie Unteranfragen, Verbundoperatoren oder Gruppierungen) sind in den Auswahlanfragen von Amazon SimpleDB nicht verfügbar. 37

39 Komponenten zur Verwendung der AWS Operator Beschreibung Beispiel = Gleichheit attribute = 'value'!= Ungleichheit attribute!= 'value' < kleiner als attribute < 'value' <= kleiner oder gleich attribute <= 'value' > gröÿer als attribute > 'value' >= gröÿer oder gleich attribute >= 'value' like Vergleich von Textteilen address like 'www%' not like negierter Vergleich von Textteilen address not like 'www%' between Werte innerhalb eines Bereichs year between '2005' and '2008' in Werte in einer Liste color in ('blue', 'red','green') is null Elemente ohne dieses Attribut attribute is null is not null Elemente mit diesem Attribut attribute is not null every() jedes Attribut muss den folgenden Vergleich erfüllen (in Verbindung mit einem weiterem Operator, für mehrwertige Attribute) Tabelle 3.1: Operatoren in Auswahlanfragen every(address) like 'www%' Anfrageteil 'order by' (optional): In diesem Teil kann eine eventuell gewünschte Sortierung der Ergebnisse festgelegt werden, indem der Name des Attributes, nach welchem sortiert werden soll, angegeben wird. Alternativ sortiert die Angabe von itemname() die Ergebnisse wiederum nach den Bezeichnern der Elemente. Dahinter kann schlieÿlich optional die Sortierrichtung ausgewählt werden, indem entweder asc (für eine aufsteigende Sortierung, ist standardmäÿig festgelegt) oder desc (für eine absteigende Sortierung) hinzugefügt wird. Hierbei muss beachtet werden, dass das zu sortierende Attribut (bzw. itemname()) zwangsläug auch in den Kriterien beliebig beschränkt werden muss (im Anfrageteil 'where'), da die Anfrage ansonsten mit einer Fehlermeldung abgelehnt wird. Anfrageteil 'limit' (optional): In diesem Teil kann eine Anzahl festgelegt werden, wie viele Elemente bei einer Anfrage maximal zurückgegeben werden sollen, wobei der erlaubte Bereich zwischen 100 und 2500 liegt (standardmäÿig werden maximal 100 Elemente zurückgegeben). Falls die Anfrage mehr Elemente betrit als durch diesen Wert festgelegt werden, wird zusätzlich zu den Elementen ein sogenannter nexttoken zurückgeliefert. Dieser nexttoken dient als Markierung, an welcher die Anfrage fortgesetzt werden soll. Somit können die nächsten Elemente dieser Anfrage abgefragt werden, bis letztendlich keine weiteren Elemente mehr gefunden werden. 38

40 Komponenten zur Verwendung der AWS Beispiel: Auswahlanfrage in Amazon SimpleDB select state, nodeurl from nodedomain where state in ('start','stop','pause') and nodeurl like 'www%' order by nodeurl limit Spezielle Erweiterungen In diesem Bereich werden die vorhandenen allgemeinen Attributmethoden um weitere Methoden zur Erstellung, Suche und Änderung von Attributen erweitert. Somit können neue Attribute von verschiedenen Typen erstellt (String, int, double, Date) und nach erfolgter Konvertierung an die bekannten Attributmethoden übergeben werden. Auÿerdem können vollständige Listen von erhaltenen Attributen nach bestimmten Attributnamen durchsucht und deren Werte im richtigen Format zurückgegeben werden. Dabei besteht für mehrwertige Attribute auch die Möglichkeit, sämtliche für diesen Attributnamen vorhandene Attributwerte aufzulisten. Zudem stehen Methoden zur Verfügung, die entweder ein einzelnes Attribut in Abhängigkeit des aktuellen Wertes abändern oder eine Liste von Attributen für ein bestimmtes Element aktualisieren und zurückgeben. Des Weiteren werden in diesem Bereich die vorhandenen allgemeinen Auswahlanfragen um weitere Methoden zur Abfrage aller Elemente, zur Gruppierung der Elementanzahlen und zur Rückgabe unterschiedlicher Werte erweitert. Wie zuvor erwähnt, ist die allgemeine Auswahlanfrage auf eine bestimmte Anzahl an Elementen beschränkt. Mit Hilfe der vollständigen Auswahlanfrage (fullselect) können alle Elemente zurückgeliefert werden, die die angegebenen Kriterien erfüllen (die Rückgabe ist nur durch den zur Verfügung stehenden Speicherplatz beschränkt, falls eine ausreichend lange Wartezeit eingeplant ist). Darüber hinaus wurde eine Methode zur Ermittlung und Gruppierung von Elementanzahlen erstellt (groupcountselect), welche die erhaltenen Elemente nach einem Attribut gruppiert und nur die Anzahl der jeweils vorhandenen Attributwerte zurückliefert. Zuletzt existiert noch eine Methode zur Rückgabe unterschiedlicher Werte (distinctselect), die sämtliche unterschiedliche Attributwerte einer Anfrage zurückliefert. Die Methoden in diesem Bereich wurden aufgrund von fehlender Funktionalität in der Amazon SimpleDB entwickelt und orientieren sich am Vorbild der Methoden in SQL. Allerdings ist die Ezienz dieser Methoden nicht mit SQL vergleichbar, da seitens der Amazon SimpleDB keine Unterstützung für diese geforderte Funktionalität geboten wird. Beispielsweise werden die erhaltenen Elemente sowohl bei der Gruppierung als auch bei der Rückgabe unterschiedlicher Werte erst auf lokaler Ebene aggregiert und müssen somit zunächst in vollem Umfang abgerufen werden. 39

41 Komponenten zur Verwendung der AWS Ein ähnliches Problem ergibt sich für die Änderung von Attributwerten in Abhängigkeit des aktuellen Wertes. Aufgrund der fehlenden Unterstützung muss der aktuelle Attributwert zunächst abgerufen, anschlieÿend geändert und zuletzt wieder hochgeladen werden (dadurch ergeben sich zwei Anfragen beispielsweise für die bloÿe Inkrementierung eines Zählers) Projekteigene Methoden Die Methoden in diesem Bereich bieten die Funktionalität an, die für die Verwendung der Amazon SimpleDB innerhalb des Projekts und zur Verwaltung der verschiedenen Domains benötigt wird: Verwaltung der Projektdomains: Innerhalb des Projekts werden bestimmte Domains benötigt, um den korrekten Ablauf des Projekts zu gewährleisten. Mit Hilfe der Methoden in diesem Bereich kann eine vollständige Projektumgebung (alle Projektdomains inkl. Startdaten) eingerichtet oder wieder entfernt werden. Darüber hinaus stehen hier Methoden zur Verfügung, mit welchen die weiteren Komponenten des Projekts auf diese Domains zugreifen können. Erzeugung von Bezeichnern ('ID'): Die Elemente in den Domains werden über eindeutige Bezeichner identiziert, welche bei der Erstellung eines Elements festgelegt werden müssen. Aufgrund der fehlenden Unterstützung dieser Funktionalität in der Amazon SimpleDB (im Gegensatz zur Erzeugung von automatisch generierten Schlüsseln in SQL) ist der Benutzer selbst für die Eindeutigkeit der verwendeten Bezeichner verantwortlich. Dafür werden im Projekt Methoden benötigt, die abhängig vom bisherigen Inhalt der jeweiligen Domain neue eindeutige Bezeichner generieren. Abfrage bestimmter Elemente: Zuletzt bietet dieser Bereich die Möglichkeit, direkt einzelne Elemente für bestimmte Domains abzufragen oder zu setzen. Diese Methoden sind somit auf spezielle Komponenten des Projekts zugeschnitten (beispielsweise können hier Jobs mit einem bestimmten Status oder auch Knoten eines bestimmten Typs abgefragt werden) S3 Die Komponente S3 stellt innerhalb des Projekts die Schnittstelle zur externen Bibliothek von Amazon S3 (siehe Kapitel 3.1.1) zur Verfügung. Sämtliche Methoden dieser Komponente benden sich in der Klasse S3 und sind statisch (static) implementiert. Die Klasse S3 ist intern ebenfalls nach dem Entwurfsmuster einer sogenannten 'Singleton'- Klasse entworfen (siehe 'Singleton' in Kapitel 3.1.3). 40

42 Komponenten zur Verwendung der AWS Da die Berechtigung zur Verwendung von Amazon S3 an einen Amazon Account geknüpft ist, müssen sowohl der Access Key als auch der Secret Access Key des zu verwendenden Accounts an den Konstruktor des S3-Services übergeben werden. Hier werden ebenfalls die in der Komponente Common festgelegten Zugangsdaten verwendet (siehe Kapitel 3.1.2) Allgemeine Methoden Die allgemeinen Methoden in dieser Klasse stellen die Grundfunktionen der Amazon S3 zur Verfügung (also die Erstellung, die Verwaltung und die Abfrage von Buckets und Objekten) und können somit in die folgenden zwei Bereiche unterteilt werden: Verwaltung von Buckets: In diesem Bereich können neue Buckets mit beinahe beliebigen (allerdings amazonweit eindeutigen) Namen erstellt (siehe Kapitel ) oder zuvor bereits erstellte Buckets wieder komplett gelöscht werden. Zudem kann hier der Status einzelner Buckets abgefragt werden, wobei ein Bucket entweder noch nicht existiert oder im Besitz dieses Accounts ist oder aber bereits von einem anderen Account verwendet wird (und somit für diesen Account nicht zugänglich ist). Zuletzt besteht in diesem Bereich noch die Möglichkeit, eine vollständige Liste aller in diesem Account verfügbaren Buckets abzurufen. Verwaltung von Objekten: Innerhalb eines Buckets werden Objekte gespeichert, indem ein beliebiger Text (als String), eine beliebige Datei (als File) oder ein beliebiger Datenstrom (als InputStream) übertragen wird. Für jedes Objekt muss dabei ein (im Bucket) eindeutiger Schlüssel (der sogenannte 'ObjectKey') übergeben werden, welcher dieses Objekt im Bucket identiziert. In diesem Bereich können die gespeicherten Objekte über diesen Schlüssel schlieÿlich auch wieder abgefragt werden. Des Weiteren kann eine vollständige Liste aller Objekte eines Buckets oder Details eines einzelnen Objekts (wie Gröÿe in Bytes, Typ des Inhalts usw.) direkt abgerufen werden. Auÿerdem können einzelne Objekte umbenannt oder von einem Bucket in einen anderen Bucket kopiert oder verschoben werden. Zuletzt können in diesem Bereich Objekte eines Buckets auch wieder gelöscht werden, indem der Name des Buckets sowie der Schlüssel des zu löschenden Objekts angegeben wird Projekteigene Methoden Die Methoden in diesem Bereich bieten die Funktionalität an, welche für die Verwendung der Amazon S3 innerhalb des Projekts und zur Verwaltung der archivierten Objekte benötigt wird. 41

43 Komponenten zur Verwendung der AWS Archivierung und Abfrage: Innerhalb des Projekts werden Dokumente und Dokumentteile archiviert, welche mit Hilfe der Methoden in diesem Bereich direkt unter Angabe eines gültigen Schlüssels in den für die Archivierung verwendeten Bucket übertragen werden. Zur Abfrage eines archivierten Objekts stehen wiederum Methoden zur Verfügung, welchen der Schlüssel des abzurufenden Objekts übergeben werden muss. Verwendung eines Indexes: Um die Archivierung im Projekt zu beschleunigen, wurde in diesem Bereich ein eigener Index für die archivierten Objekte erstellt. Jedes archivierte Objekt wird in diesen Index eingetragen, wodurch die mehrfache Übertragung desselben Objekts verhindert werden kann. Optional kann in den Eigenschaften eines Jobs (siehe Kapitel ) ausgewählt werden, ob vor Beginn der Archivierung sämtliche bereits archivierten Objekte aus dem Bucket ausgelesen und in den Index eingetragen werden sollen. Allerdings könnte dieser Vorgang einige Zeit dauern, falls bereits eine groÿe Menge an Objekten im Bucket vorhanden ist (ein Test ergab ca. 20 Sekunden für ca Objekte). Aufgrund der zu erwartenden groÿen Datenmenge ist diese Funktion nicht zu empfehlen, da die Erstellung des Indexes einen im Vergleich zum gesamten Archivierungsprozess unverhältnismäÿig groÿen Zeitaufwand erfordern würde EC2 Die Komponente EC2 stellt innerhalb des Projekts die Schnittstelle zur externen Bibliothek von Amazon EC2 (siehe Kapitel 3.1.1) zur Verfügung. Sämtliche Methoden dieser Komponente benden sich in der Klasse EC2 und sind statisch (static) implementiert. Die Klasse EC2 ist intern ebenfalls nach dem Entwurfsmuster einer sogenannten 'Singleton'- Klasse entworfen (siehe 'Singleton' in Kapitel 3.1.3). Da die Berechtigung zur Verwendung von Amazon EC2 an einen Amazon Account geknüpft ist, müssen sowohl der Access Key als auch der Secret Access Key des zu verwendenden Accounts an den Konstruktor des EC2-Services übergeben werden. Hier werden ebenfalls die in der Komponente Common festgelegten Zugangsdaten verwendet (siehe Kapitel 3.1.2) Allgemeine Methoden Die allgemeinen Methoden in dieser Klasse stellen die Grundfunktionen der Amazon EC2 zur Verfügung und bieten die Verwaltung der folgenden Bereiche an: Images: Ein Image wird in Amazon als AMI bezeichnet und stellt ein Abbild eines vollständigen Systems dar, welches als Grundlage für die in Amazon EC2 ablaufen- 42

44 Komponenten zur Verwendung der AWS den Instanzen dient. In diesem Bereich können sämtliche (öentlich) verfügbaren AMI oder nur die in diesem Account erstellten AMI aufgelistet werden. Instanzen: Eine Instanz stellt ein laufendes System dar, welches auf der Grundlage eines bestimmten AMI basiert. In diesem Bereich können sämtliche momentan existierenden Instanzen dieses Accounts aufgelistet werden. Zudem besteht die Möglichkeit, neue Instanzen auf Basis eines bestimmten AMI zu starten, indem der Methode der Bezeichner des zu startenden AMI sowie die Anzahl der zu startenden Instanzen übergeben wird. Zuletzt steht noch eine Methode zur Verfügung, um laufende Instanzen anhand des eindeutigen Bezeichners der Instanz wieder beenden zu können. Laufwerke: Die innerhalb einer Instanz erstellten Dateien werden dort nicht persistent abgespeichert und gehen somit verloren, sobald die Instanz beendet wird. Um dies zu verhindern, können in diesem Bereich Laufwerke ('Volumes') an die Instanzen angehängt werden, welche die persistente Speicherung der Dateien gewährleisten. Nach dem Anhängen der Laufwerke ist allerdings zu beachten, dass die Laufwerke auch noch innerhalb der laufenden Instanzen gemountet werden müssen, bevor sie verwendet werden können. Des Weiteren stehen hier noch Methoden zur Verfügung, um angehängte Laufwerke wieder abzutrennen sowie neue Laufwerke zu erstellen oder vorhandene Laufwerke komplett zu löschen. Adressen: Da neu gestartete Instanzen eine zufällige IP-Adresse zugeteilt bekommen und der Zugri darauf nur erschwert möglich ist, können bestimmte feste IP-Adressen (die sogenannten 'Elastic IPs') zu laufenden Instanzen zugeordnet werden, woraufhin diese Instanz unter der festen IP erreichbar ist. In diesem Bereich existieren somit Methoden, um die festen Adressen eines Accounts zu den laufenden Instanzen zuordnen zu können sowie diese Zuordnungen wieder aufzuheben Projekteigene Methoden Die Methoden in diesem Bereich bieten die Funktionalität an, die für die Verwendung der Amazon EC2 innerhalb des Projekts und zur Verwaltung der Instanzen benötigt wird. Starten von Projektinstanzen: In diesem Bereich ist es möglich, neue Projektinstanzen mit Hilfe eines Methodenaufrufs zu starten, wobei der zu startende Knotentyp (Job Server, Search Server, PAI) als Parameter übergeben wird. Die Methode sucht daraufhin nach einem in diesem Account erstellten AMI und verwendet dieses AMI, um eine neue Instanz zu starten. Der übergebene Knotentyp wird in die Benutzerdaten der zu startenden Instanz eingetragen. Falls eine Instanz vom Typ 'PAI' gestartet werden soll, werden die Benutzerdaten zudem um die lokalen Adressen des aktuellen Job Servers sowie des Search Servers ergänzt (diese müssen zuvor gestartet worden sein). 43

45 Komponenten zur Verwendung der AWS Integration der Instanz: Nachdem die Instanz erfolgreich gestartet wurde, werden sämtliche Startskripte der Instanz abgearbeitet (siehe Kapitel 4.3.3). In diesem Rahmen wird die Methode zur Initialisierung der Projektumgebung aus diesem Bereich aufgerufen. Diese Methode bekommt den aktuellen Knotentyp als Parameter übergeben und speichert diesen Typ zusammen mit dem Status des Knotens und dem Bezeichner der Instanz (ID) in einer Domain zur Knotenverwaltung ab. Der Knoten in dieser Domain wird hierbei über die lokale IP-Adresse identiziert, welche als Bezeichner des Elements verwendet wird. Daraus wird auch ersichtlich, dass für den Aufbau einer kompletten Cloud zunächst der Job Server und der Search Server gestartet werden müssen. Erst wenn diese Knoten ihre lokalen IP-Adressen in die Domain geschrieben haben, kann ein Knoten vom Typ 'PAI' zusammen mit den Adressen für Job Server und Search Server gestartet werden. Beenden von Projektinstanzen: Das Beenden einer Projektinstanz kann auf verschiedene Arten erfolgen: Im Kommandozeilenwerkzeug awscmd (siehe Kapitel 3.3.1) existiert der Abschaltbefehl cmgshutdown, welcher die Shutdown-Methode dieser Klasse aufruft. In dieser Methode wird zunächst der Knoten aus der Domain zur Knotenverwaltung gelöscht. Anschlieÿend werden die Protokolldateien dieses Projekts zusammen mit einem Zeitstempel in einem eigenen Bucket abgespeichert, da diese Dateien ansonsten durch das Herunterfahren der Instanz verloren gehen würden. Zuletzt wird der Befehl zum Beenden dieser Instanz ausgeführt, der diese Instanz letztendlich terminiert. Das Ausführen des Abschaltbefehls kann hierbei nur innerhalb der laufenden Instanz erfolgen. Nach Abschluss eines Jobs überprüft jeder Knoten für sich selbst, ob für ihn ein sogenanntes Abschaltsignal ('shutdown signal') gesetzt wurde. Falls dies der Fall ist, nimmt der Knoten keine weiteren Jobs an und ruft ebenfalls die oben erwähnte Shutdown-Methode auf. Das Setzen des Abschaltsignals kann ebenfalls im Kommandozeilenwerkzeug mit dem Befehl cmgsendshutdown ausgeführt werden, indem zusätzlich die lokale Adresse der Instanz angegeben wird, für die das Abschaltsignal gesetzt werden soll. Das Setzen des Abschaltsignals kann auch auÿerhalb der laufenden Instanz erfolgen. Zuletzt kann zum Beenden einer beliebigen Instanz auch die web-basierende Schnittstelle von Amazon verwendet werden (siehe Kapitel 3.3.2), in welcher sämtliche laufenden Instanzen des Accounts aufgelistet sind. In dieser Schnittstelle ist es möglich, jede laufende Instanz zwangsweise zu terminieren. 44

46 Komponenten zur Verwendung der AWS Allerdings ist darauf zu achten, dass hierbei keine Aufräumarbeiten wie bei den anderen Beendigungsarten durchgeführt werden und die Instanz nach Beendigung somit noch immer in der Knotenverwaltung auftaucht. Diese Art der Beendigung sollte somit nur verwendet werden, falls sich eine Instanz nicht mehr auf eine der anderen Arten beenden lässt SQS Die Komponente SQS stellt innerhalb des Projekts die Schnittstelle zur externen Bibliothek von Amazon SQS (siehe Kapitel 3.1.1) zur Verfügung. Sämtliche Methoden dieser Komponente benden sich in der Klasse SQS und sind statisch (static) implementiert. Die Klasse SQS ist intern ebenfalls nach dem Entwurfsmuster einer sogenannten 'Singleton'- Klasse entworfen (siehe 'Singleton' in Kapitel 3.1.3). Da die Berechtigung zur Verwendung von Amazon SQS an einen Amazon Account geknüpft ist, müssen sowohl der Access Key als auch der Secret Access Key des zu verwendenden Accounts an den Konstruktor des SQS-Services übergeben werden. Hier werden ebenfalls die in der Komponente Common festgelegten Zugangsdaten verwendet (siehe Kapitel 3.1.2) Allgemeine Methoden Die allgemeinen Methoden in dieser Klasse stellen die Grundfunktionen der Amazon SQS zur Verfügung und bieten die Verwaltung der folgenden Bereiche an: MessageQueues: Eine MessageQueue ist eine Warteschlange für Nachrichten, in der Nachrichten eingereiht und wieder abgerufen werden können. Die grundlegende Charakteristik einer MessageQueue ist hierbei, dass niemals eine Nachricht verloren gehen darf (allerdings mit den von Amazon vorgegebenen Einschränkungen, siehe Kapitel ). In diesem Bereich können mit Hilfe der vorhandenen Methoden neue MessageQueues erstellt oder zuvor bereits erstellte MessageQueues wieder komplett gelöscht werden. Auÿerdem besteht die Möglichkeit, eine vollständige Liste aller in diesem Account verfügbaren MessageQueues oder auch nur die MessageQueues mit einem bestimmten Präx abzurufen. Zuletzt kann hier die Standard-Zeitspanne für die gesamte MessageQueue eingestellt werden, wie lange abgerufene Nachrichten unsichtbar bleiben, bevor sie erneut abgerufen werden können (falls sie in der Zwischenzeit nicht gelöscht wurden). Nachrichten: Die Nachrichten in den MessageQueues können einen beliebigen Text beinhalten, allerdings gelten wiederum die bereits erwähnten Beschränkungen von Amazon. In diesem Bereich stehen die Methoden zur Verfügung, um Nachrich- 45

47 Komponenten zur Verwendung der AWS ten in eine bestimmte MessageQueue einzureihen sowie von dort wieder abzurufen oder letztendlich endgültig aus der MessageQueue zu löschen. Zudem kann hier auch die Zeitspanne für eine einzelne Nachricht eingestellt werden, wie lange diese Nachricht unsichtbar bleiben soll, bevor sie erneut abgerufen werden kann (falls sie in der Zwischenzeit nicht gelöscht wurde) Projekteigene Methoden Die Methoden in diesem Bereich bieten die Funktionalität an, welche für die Verwendung der Amazon SQS innerhalb des Projekts benötigt wird. Die in diesem Bereich vorhandenen Methoden werden ausschlieÿlich von der Komponente SchedulerLayer (siehe Kapitel 3.2.4) verwendet und dienen somit nur der Verwaltung der verschiedenen Aufgaben (den sogenannten Jobs im Projekt). Einreihen von Jobs: Mit Hilfe der Methoden in diesem Bereich können bestimmte Jobs eingereiht werden, indem die Bezeichner dieser Jobs als Nachricht in die entsprechende MessageQueue übergeben werden. Abrufen von Jobs: Zudem können die zuvor eingereihten Jobs wieder abgerufen werden, wobei der Bezeichner des Jobs aus der Nachricht ausgelesen und zurückgegeben wird. Die Nachricht ist anschlieÿend für eine gewisse Zeitspanne unsichtbar, bis sie wieder in der MessageQueue abgerufen werden kann (falls sie in der Zwischenzeit nicht gelöscht wurde). Löschen von Jobs: Mit dieser Methode wird der Job (genauer gesagt die Nachricht mit dem Bezeichner des Jobs) endgültig aus der entsprechenden Message- Queue gelöscht. Hinweis: Die zuvor beschriebenen Methoden stellen nur die Grundfunktionen für den Abruf einer einzelnen standardmäÿigen Job-MessageQueue zur Verfügung. Da im Projekt allerdings für jeden Mandanten eine eigene MessageQueue verwendet wird, erfolgt die Verwaltung sämtlicher MessageQueues in der Komponente SchedulerLayer (siehe Kapitel 3.2.4). 46

48 Übergeordnete Schichten 3.2 Übergeordnete Schichten In diesem Abschnitt werden die übergeordneten Schichten ('layer') beschrieben, die auf der bisher erläuterten Funktionalität der AWS basieren und die diese Funktionalität um weitere spezische Funktionen wie die Verwaltung der Dokumente, Aufgaben und Threads innerhalb des Prototypen erweitern. In Abbildung 3.2 bendet sich ein vereinfachtes Klassendiagramm als grober Überblick über die Schichten, die in diesem Abschnitt genauer erläutert werden. Abbildung 3.2: Vereinfachtes Klassendiagramm der Schichten Die Komponente ThreadingLayer realisiert die Verwaltung der Threads. Die Komponente CoordinationLayer organisiert die Speicherung der Dokumente. Die Komponente AccountingLayer realisiert die Erfassung der Abrechnungsdaten. Die Komponente SchedulerLayer organisiert die Verwaltung der Jobs. Die Komponente CollectorLayer organisiert die Zusammenfassung der Daten Threadverwaltung Die Komponente ThreadingLayer stellt die Threadverwaltung dar und bietet somit den Zugri auf sämtliche in diesem Package verwendeten Threads. Sämtliche Methoden dieser Komponente benden sich in der Klasse ThreadingLayer und sind statisch (static) implementiert. 47

49 Übergeordnete Schichten Allgemeine Threadverwaltung In den ersten Tests des Prototypen wurde ersichtlich, dass der gröÿte Teil der Verarbeitungszeit auf den Knoten durch den Speichervorgang der Dokumente in Amazon S3 in Anspruch genommen wurde. Aus diesem Grund wurden die einzelnen Speichervorgänge in eigene Threads ausgelagert, um den eigentlichen Archivierungsprozess nicht aufzuhalten, sondern parallel fortsetzen zu können. Um Speicherprobleme aufgrund zuvieler Threads zu verhindern, wurde in der Threadverwaltung eine Höchstzahl an parallelen Threads festgelegt. Bevor ein Thread gestartet werden kann, muss zunächst die Anzahl an momentanen laufenden Threads überprüft werden. Nur unter der Bedingung, dass noch nicht die Höchstzahl an parallelen Threads erreicht ist, darf anschlieÿend ein neuer Thread gestartet werden. Da die Anfragen zur Erstellung neuer Threads von mehreren Prozessen parallel an diese Threadverwaltung gestellt werden, mussten Maÿnahmen zur Synchronisation dieser Anfragen erfasst werden. Zu diesem Zweck wurde die Anzahl an momentan laufenden Threads in einer statischen Variable des Typs 'AtomicInteger' gespeichert. Da der Zugri auf diese Variable 'atomar' erfolgt, kann es zu keinen Nebenläugkeiten wie beispielsweise der mehrmaligen Erhöhung desselben Werts kommen. Des Weiteren wurden zur Synchronisation der Threads eines Mandanten eine Variable des Typs 'AtomicBoolean' verwendet, welche den Zugri auf die Threads des Mandanten für andere Prozesse sperrt (unter der Bedingung, dass bisher noch keine Sperre vorliegt), um einen Thread für diesen Mandanten hinzuzufügen oder zu entfernen. Aufgrund der Sperre kann der Zugri auf die Threads des Mandanten somit ebenfalls als 'atomar' angesehen werden und es können ebenfalls keine Nebenläugkeiten auftreten. In dieser Klasse werden sämtliche erstellten Threads in Listen verwaltet, um gewährleisten zu können, dass auf alle gestarteten Threads (falls erforderlich) gewartet werden kann. Dabei werden Threadlisten sowohl für jede Art von Thread (Dokumente, Dokumentteile, Abrechnungsdaten, Sammlungen, Auswahlanfragen) sowie für jeden einzelnen Mandanten des Projekts verwaltet. Für die Threads der Mandanten wird hierbei eine Hash-Tabelle geführt, in welche die Threadlisten in Abhängigkeit des zugehörigen Mandanten einsortiert werden. Die Threadverwaltung stellt zudem verschiedene Methoden zur Verfügung, mit deren Hilfe auf andere Threads (oder einfach eine bestimmte Zeitspanne) gewartet werden kann. Dabei kann entweder auf einen bestimmten einzelnen Thread sowie auf alle laufenden Threads eines Mandanten oder der gesamten Threadverwaltung gewartet werden. Zuletzt besteht auch noch die Möglichkeit, auf einen freien Thread-Slot zu warten, falls momentan bereits die maximale Anzahl an parallelen Threads aktiv ist. 48

50 Übergeordnete Schichten Speicherung von Dokumenten Zur Speicherung von Dokumenten existiert in dieser Klasse eine Unterklasse 'StoreDocumentThread', welche vom Typ 'Thread' abgeleitet ist und somit parallel ausgeführt werden kann. Diese Unterklasse dient dazu, ein vollständiges Dokument für einen bestimmten Mandanten im festgelegten Bucket zu archivieren und die Metadaten zu diesem Dokument (wie Absender, Empfänger, Betre, Datum, zugehörige Dokumentteile) in den Domains zur Dokumentenverwaltung abzuspeichern. Nachdem ein Thread dieser Art gestartet wurde, verwendet der Thread die Komponente CoordinationLayer (siehe Kapitel 3.2.2), um das Dokument letztendlich in den jeweiligen AWS abzuspeichern Speicherung von Dokumentteilen Zur Speicherung von Dokumentteilen existiert in dieser Klasse eine Unterklasse 'StorePartThread', welche vom Typ 'Thread' abgeleitet ist und somit parallel ausgeführt werden kann. Diese Unterklasse dient dazu, ein Dokumentteil eines Dokuments für einen bestimmten Mandanten im festgelegten Bucket zu archivieren. Nachdem ein Thread dieser Art gestartet wurde, verwendet der Thread die Komponente CoordinationLayer (siehe Kapitel 3.2.2), um den Dokumentteil letztendlich im jeweiligen AWS abzuspeichern Speicherung von Abrechnungsdaten Bei jedem Speichervorgang von Dokumenten und ihren Dokumentteilen in die jeweiligen AWS werden Abrechnungsdaten aufsummiert (siehe Kapitel 3.2.3), die das Ausmaÿ der verwendeten Leistungen in den betreenden AWS beschreiben. Zur Speicherung dieser Abrechnungsdaten existiert in dieser Klasse eine Unterklasse 'StoreAccountingData- Thread', welche vom Typ 'Thread' abgeleitet ist und somit parallel ausgeführt werden kann. Diese Unterklasse dient dazu, sämtlichen bisher gesammelten Abrechnungsdaten (wie beispielsweise die Anzahl der übertragenen Bytes oder die Dauer der benötigen Maschinenzeit) für einen bestimmten Mandanten in der zugehörigen Domain abzuspeichern. Nachdem ein Thread dieser Art gestartet wurde, verwendet der Thread die Komponente AccountingLayer (siehe Kapitel 3.2.3), um die Abrechnungsdaten des Mandanten letztendlich im jeweiligen AWS abzuspeichern Speicherung von Sammlungen Um die wiederholte Übertragung einzelner Elemente (und ihrer Attribute) in die Domains zur Dokumentenverwaltung zu verhindern, werden die zu übertragenden Elemente und deren Attribute zunächst gesammelt und erst zu einem späteren Zeitpunkt als komplette Sammlung von Elementen übertragen (siehe Kapitel 3.2.5). Zur Speicherung dieser 49

51 Übergeordnete Schichten Sammlungen existiert in dieser Klasse eine Unterklasse 'StoreCollectionThread', welche vom Typ 'Thread' abgeleitet ist und somit parallel ausgeführt werden kann. Diese Unterklasse dient dazu, sämtliche bisher gesammelten Elemente (und deren Attribute) für einen bestimmten Mandanten in den Domains zur Dokumentenverwaltung abzuspeichern. Nachdem ein Thread dieser Art gestartet wurde, verwendet der Thread eine statische Methode der Komponente CollectorLayer (siehe Kapitel 3.2.5), um die Sammlung des Mandanten letztendlich im jeweiligen AWS abzuspeichern Ausführung von Auswahlanfragen Da aufgrund der Beschränkungen einzelner Domains (siehe Kapitel ) die archivierten Dokumente auf mehrere Domains zur Dokumentenverwaltung verteilt sind, muss die Ausführung von Auswahlanfragen in mehrere Threads untergliedert werden, welche die Anfrage an jeweils eine Domain der Dokumentenverwaltung weiterleiten. Zur Ausführung dieser Teilanfragen existiert in dieser Klasse eine Unterklasse 'SelectRequestThread', welche vom Typ 'Thread' abgeleitet ist und somit parallel ausgeführt werden kann. Diese Unterklasse dient dazu, eine Auswahlanfrage (siehe Kapitel ) an eine bestimmte Domain der Dokumentenverwaltung weiterzuleiten und die zurückgelieferten Elemente dieser Domain (bzw. im Fehlerfall die zugehörige Fehlermeldung) bereitzustellen. Nachdem ein Thread dieser Art gestartet wurde, verwendet der Thread die Komponente SimpleDB (siehe Kapitel 3.1.3), um die Auswahlanfrage letztendlich für die jeweilige Domain auszuführen Dokumentenverwaltung Die Komponente CoordinationLayer stellt die komplette Dokumentenverwaltung zur Verfügung, in welcher aufgrund der Beschränkungen einzelner Domains (siehe Kapitel ) die archivierten Dokumente auf mehrere Domains verteilt sind. Sowohl die Archivierung als auch die Abfrage von Dokumenten und Dokumentteilen wird hier koordiniert. Sämtliche Methoden dieser Komponente benden sich in der Klasse CoordinationLayer und sind statisch (static) implementiert Archivierung von Dokumenten Diese Klasse koordiniert die Archivierung von Dokumenten und Dokumentteilen, indem für jede Archivierung überprüft wird, ob ein neuer Thread gestartet werden muss. Ansonsten wird überprüft, ob die zu archivierenden Daten entweder bereits vorhanden sind oder zunächst einmal gesammelt werden, um sie später gemeinsam in einem einzelnen Durchlauf zu archivieren. 50

52 Übergeordnete Schichten Dokumente: Zu Beginn der Archivierung von Dokumenten wird zunächst geprüft, ob generell Threads für die Archivierung verwendet werden sollen. Falls dies nicht der Fall ist, wird die weitere Archivierung des Dokuments sequentiell durchgeführt und der Programmablauf erst fortgeführt, sobald die Archivierung beendet wurde. Andernfalls besteht noch die Möglichkeit, dass nur Metadaten des Dokuments in den Domains und kein Dokumentinhalt im Bucket archiviert werden sollen. In diesem Fall wird kein Thread benötigt, da die Metadaten für jeden Mandanten in einer Instanz der Klasse CollectorLayer (siehe Kapitel 3.2.5) gesammelt werden und erst zu einem späteren Zeitpunkt gemeinsam archiviert werden. Diese Instanzen werden in einer Hash-Tabelle verwaltet, welche jedem Mandanten eine Instanz der Klasse CollectorLayer zuordnet. Zuletzt besteht im Gegensatz dazu noch die Möglichkeit, dass der Dokumentinhalt im Bucket archiviert werden soll, wodurch letztendlich die Verwendung eines Threads erforderlich ist. Somit wird ein neuer Thread der Unterklasse StoreDocumentThread (siehe Kapitel ) erstellt, welcher den zu archivierenden Dateninhalt und die Metadaten des Dokuments enthält. Für die weitere Verwaltung und Durchführung des Threads ist schlieÿlich die Komponente ThreadingLayer (siehe Kapitel 3.2.1) verantwortlich. Dokumentteile: Zu Beginn der Archivierung von Dokumentteilen wird zunächst geprüft, ob sich der zu archivierende Dokumentteil bereits im Index der Komponente S3 (siehe Kapitel 3.1.4) bendet. Falls dies der Fall ist, wurde dieser Dokumentteil bereits zuvor archiviert und es muss keine weitere Archivierung durchgeführt werden. Andernfalls wird geprüft, ob generell Threads für die Archivierung verwendet werden sollen. Falls dies nicht der Fall ist, wird die weitere Archivierung des Dokumentteils sequentiell durchgeführt und der Programmablauf wird erst fortgeführt, sobald die Archivierung beendet wurde. Fall Threads für die Archivierung verwendet werden sollen, wird ein neuer Thread der Unterklasse StorePartThread (siehe Kapitel ) erstellt, welcher den zu archivierenden Dateninhalt des Dokumentteils enthält. Für die weitere Verwaltung und Durchführung des Threads ist schlieÿlich die Komponente ThreadingLayer (siehe Kapitel 3.2.1) verantwortlich Abfrage von Dokumenten Die Abfragen von archivierten Dokumenten und Dokumentteilen werden ebenfalls von dieser Komponente koordiniert. Dokumente: Diese Klasse koordiniert die Abfrage von archivierten Dokumenten, indem für bestimmte Dokumente direkt die entsprechenden Dateninhalte aus dem Bucket bzw. Metadaten aus den Domains ausgelesen werden. Dies ist allerdings 51

53 Übergeordnete Schichten nur möglich, falls der Bezeichner des Dokuments bekannt ist. Falls dies nicht der Fall ist, besteht in dieser Komponente die Möglichkeit, eine Auswahlanfrage (siehe Kapitel ) mit Hilfe mehrerer Threads an die Domains zur Dokumentenverwaltung abzuschicken. Diese Anfrage liefert letztendlich sämtliche Dokumente aus den Domains zurück, welche die angegebenen Suchkriterien erfüllen. Dokumentteile: Diese Klasse koordiniert die Abfrage von archivierten Dokumentteilen, indem für bestimmte Dokumentteile direkt die entsprechenden Dateninhalte aus dem Bucket ausgelesen werden. Dies ist allerdings nur möglich, falls der Bezeichner des Dokumentteils bekannt ist Abrechnung In der Komponente AccountingLayer werden Abrechnungsdaten für jeden Mandanten gesammelt, die das Ausmaÿ der verwendeten Leistungen dieses Mandanten in den betreenden AWS beschreiben. Sämtliche Methoden dieser Komponente benden sich in der Klasse AccountingLayer und sind statisch (static) implementiert Struktur der Klasse Die Kennzahlen der Abrechnungsdaten werden in der Unterklasse TenantAccounting zusammengefasst, wobei für jeden Mandanten eine eigene Instanz dieser Unterklasse existiert. Der Zugri auf die Instanzen erfolgt über eine Hash-Tabelle, die jedem Mandanten eine solche Unterklasse zuordnet. Zudem existiert noch eine zusätzliche Instanz dieser Unterklasse, in welcher die gesamten Abrechnungsdaten aller Mandanten aufsummiert werden. In der Tabelle 3.2 werden sämtliche in der Unterklasse TenantAccounting enthaltenen Kennzahlen und deren Beschreibung sowie die damit verbundenen AWS und die auslösende Komponente aufgelistet. 52

54 Übergeordnete Schichten Kennzahl Beschreibung AWS Erfassung in Komponente AccountingLayer starttime Beginn der Erfassung - firstsenttime Zeitpunkt des ersten Versands SQS firstrecvtime Zeitpunkt des ersten Empfangs SQS lastsenttime Zeitpunkt des letzten Versands SQS lastrecvtime Zeitpunkt des letzten Empfangs SQS Erfassung in Komponente SchedulerLayer nummsgsent Anzahl der gesendeten Nachrichten SQS nummsgrecv Anzahl der empfangenen Nachrichten SQS jobsfinished Anzahl der erledigten Jobs SimpleDB, SQS jobsfailed Anzahl der fehlerhaften Jobs SimpleDB, SQS Erfassung in Komponente CoordinationLayer bytesins3 Anzahl der übertragenen Bytes S3 bytesinsimpledb Anzahl der übertragenen Bytes SimpleDB boxusagesimpledb Anteil an Maschinenstunden für Anfragen SimpleDB Erfassung in Komponente Crawler dipdocs Anzahl der verarbeiteten Dokumente SimpleDB, S3 dipbytes Anzahl der verarbeiteten Bytes SimpleDB, S3 Tabelle 3.2: Kennzahlen der Abrechnungsdaten Erfassung von Abrechnungsdaten Zur Erfassung der Abrechnungsdaten werden die Methoden dieser Klasse unter Angabe des betreenden Mandanten sowie der zu erfassenden Werte für eine der Kennzahlen aufgerufen. Nachrichten und Jobs: Die von der Komponente SchedulerLayer (siehe Kapitel 3.2.4) erfassten Anzahlen an gesendeten und empfangenen Nachrichten werden zusammen mit den Anzahlen an erledigten und fehlerhaften Jobs in den Abrechnungsdaten gespeichert. Aus diesen Aufrufen werden zudem noch die Kennzahlen für den Zeitpunkt des ersten und letzten Versands einer Nachricht sowie des ersten und letzten Empfangs einer Nachricht abgeleitet. Dokumente, Dokumentteile und Sammlungen: Nachdem die Komponente CoordinationLayer (siehe Kapitel 3.2.2) erfolgreich Dokumente und Dokumentteile (oder ganze Sammlungen) im Bucket bzw. in den Domains archiviert hat, wird die Anzahl an Bytes der in S3 und SimpleDB archivierten Daten in den Abrechnungsdaten gespeichert. Zusätzlich dazu wird der Anteil an benötigten Maschinenstunden für Anfragen an SimpleDB aufsummiert. 53

55 Übergeordnete Schichten Speicherung der Abrechnungsdaten Zuletzt wird die Speicherung der gesammelten Abrechnungsdaten in einer eigenen Domain ebenfalls von der Komponente SchedulerLayer ausgelöst, wobei für jeden Mandanten ein einzelnes Element mit dem aktuellen Zeitstempel angelegt wird. In diesem Element werden sämtliche für diesen Zeitraum erfassten Kennzahlen als Attribute dieses Elements aufgelistet. Zusätzlich dazu werden auch noch die aufsummierten Gesamtwerte der Kennzahlen aller Mandanten abgespeichert Aufgabenplanung In der Komponente SchedulerLayer wird die vollständige Planung der im Projekt durchzuführenden Aufgaben (Jobs) realisiert. Die Jobs in diesem Projekt bezeichnen hierbei einzelne Aufgaben, welche von den verschiedenen Knoten des Projekts abgearbeitet werden sollen (im Allgemeinen umfasst ein Job immer eine bestimmte Menge an zu archivierenden Dokumenten). Sämtliche Methoden dieser Komponente benden sich in der Klasse SchedulerLayer und sind statisch (static) implementiert. Aufgrund der nur bedingten Konsistenz innerhalb der Amazon SimpleDB (siehe 'eventual consistency' in Kapitel ) kann die Verwaltung der Jobs nicht nur anhand der Amazon SimpleDB erfolgen. Eine Änderung des Status eines Jobs ist in der Amazon SimpleDB erst nach einigen Sekunden sichtbar, wodurch die unerwünschte Möglichkeit besteht, dass der Job in der Zwischenzeit nochmals von einem anderen Prozess übernommen wurde. Um dies zu verhindern, ist zu gewährleisten, dass ein Job nur einmal abgerufen werden kann Erstellung neuer Jobs Die Klasse SchedulerLayer stellt die Methoden zur Verfügung, um einen neuen Job für einen bestimmten Mandanten zu erstellen, indem die Daten des Jobs an diese Komponente übergeben werden. Anschlieÿend sorgt diese Komponente dafür, dass der Job in der entsprechenden Domain des Projekts abgespeichert und der Bezeichner des Jobs (ID) in eine sogenannte MessageQueue (eine Warteschlange für Nachrichten) eingereiht wird. Für jeden Mandanten des Projekts wird hierbei eine eigene MessageQueue angelegt, über die die Jobs dieses Mandanten abgerufen werden können Bereitstellung eingereihter Jobs Aufgrund der erwähnten bedingten Konsistenz werden sämtliche Jobbezeichner bei der Erstellung des Jobs in eine MessageQueue eingereiht. In der Klasse SchedulerLayer können diese zuvor abgespeicherten und eingereihten Jobs auch wieder abgerufen werden, 54

56 Übergeordnete Schichten um den Job auf einem Knoten des Projekts durchführen zu können. Nach Abruf eines Jobs ist der Bezeichner noch immer in der MessageQueue als Nachricht vorhanden, ist aber für eine bestimmte Zeitspanne (in diesem Fall 90 Sekunden) nicht sichtbar. Während dieser Zeitspanne muss diese Klasse dafür sorgen, dass der Status des Jobs in der Domain aktualisiert wird, damit anschlieÿend kein anderer Knoten ebenfalls diesen Job parallel abarbeiten kann. Der Bezeichner darf erst aus der MessageQueue entfernt werden, wenn der Job tatsächlich beendet wurde, da der Job ansonsten verloren gehen könnte (falls beispielsweise der Knoten abstürzt). Die Auswahl des Mandanten, für den der nächste Job abgerufen wird, liegt dabei ebenfalls in der Verantwortung dieser Klasse. In diesem Rahmen besteht die Möglichkeit, Prioritäten für die vorhandenen Mandanten zu vergeben, um bestimmte Mandanten gegenüber anderen zu bevorzugen. Falls für einen Mandanten hierbei keine Priorität angegeben wurde, wird die Standardpriorität 100 verwendet. Die letztendliche Auswahl des Mandanten erfolgt nach dem Zufallsprinzip, wobei sich die Wahrscheinlichkeiten der einzelnen Mandanten an den jeweils gegebenen Prioritäten orientiert. Dieser Ansatz soll nur eine einfache Variante der priorisierten Auswahl darstellen und ist keineswegs optimal, da beispielsweise keine Aussagen über die Zeitspanne bis zur tatsächlichen Abarbeitung eines Jobs getroen werden können. Beispiel: Der Mandant A besitzt die Priorität 100, Mandant B die Priorität 200 und Mandant C die Priorität 400. Nun wird eine Zufallszahl im Bereich von minimal 1 bis maximal der Gesamtsumme aller Prioritäten (hier 700) gezogen. Falls sich die Zufallszahl im Bereich von 1 bis 100 bendet, wird Mandant A ausgewählt. Für den Bereich von 101 bis 300 wird Mandant B und für den Bereich von 301 bis 700 Mandant C gewählt. Im Durchschnitt ergibt sich somit, dass Mandant C doppelt so häug wie Mandant B, und sogar viermal so häug wie Mandant A ausgewählt wird (eine ausreichend groÿe Zahl an Versuchen ist vorausgesetzt) Beendigung abgearbeiteter Jobs Nachdem ein Knoten einen Job vollständig abgearbeitet hat, wird eine Rückmeldung an die Klasse SchedulerLayer übergeben, die angibt, ob der Job erfolgreich oder fehlerhaft beendet wurde. Anschlieÿend sorgt diese Klasse dafür, dass der Job in der entsprechenden Domain des Projekts aktualisiert und der Bezeichner des Jobs aus der MessageQueue des Mandanten entfernt wird. Zum Abschluss des Jobs weist diese Klasse noch die Komponente 'CoordinationLayer' (siehe Kapitel 3.2.2) an, die für den Mandanten des Jobs gesammelten Metadaten in die Domains der Dokumentenverwaltung zu übertragen. Zuletzt wird noch die Komponente 'AccountingLayer' (siehe Kapitel 3.2.3) angewiesen, die Abrechnungsdaten dieses Mandanten ebenfalls abzuspeichern. Daraufhin ist die Abarbeitung des Jobs in dieser Klasse abgeschlossen. 55

57 Übergeordnete Schichten Datenzusammenfassung In der Komponente CollectorLayer werden die Metadaten der archivierten Dokumente gesammelt, um die wiederholte Übertragung einzelner Elemente zu verhindern und sämtliche Metadaten gebündelt zu übertragen. Um die Methoden dieser Komponente, die sich in der Klasse CollectorLayer benden, zu verwenden, muss die Klasse unter Angabe des betreenden Mandanten instanziiert werden. Die Metadaten werden innerhalb einer Instanz immer nur für einen einzelnen Mandanten gesammelt und dieser Mandant muss somit beim Erstellen der Klasse festgelegt werden. Die Verwaltung der einzelnen Instanzen der verschiedenen Mandanten erfolgt in der Komponente 'CoordinationLayer' (siehe Kapitel 3.2.2), welche zu diesem Zweck eine Hash- Tabelle zur Zuordnung von Mandanten und den jeweiligen Instanzen dieser Klasse führt. Nachdem die Archivierung von Dokumenten für einen Mandanten abgeschlossen wurde, sorgt die Komponente 'CoordinationLayer' dafür, dass die für diesen Mandanten gesammelten Metadaten abgespeichert werden Struktur der Klasse Innerhalb einer Instanz dieser Klasse werden die gesammelten Metadaten für jede Domain der Dokumentenverwaltung einzeln in Listen abgespeichert. Die Zuordnung der Listen zu den jeweiligen Domains erfolgt hierbei wiederum mit einer Hash-Tabelle. Der zugehörige Mandant dieser Metadaten wird bei der Erstellung der Instanz festgelegt und kann nicht geändert werden. Für die letztendliche Speicherung von Metadaten existiert in dieser Klasse noch eine einzelne statische Methode, welche aus den Threads zur Speicherung von Sammlungen aufgerufen wird (siehe Kapitel ) Erfassung von Metadaten Zur Erfassung von Metadaten wird das neue Element unter Angabe der betreenden Domain an die Instanz dieser Klasse übergeben. In dieser Instanz wird zunächst geprüft, ob für diese Domain bereits Elemente zusammengefasst wurden. Falls dies nicht der Fall ist, wird eine neue Liste für diese Domain erstellt, welche schlieÿlich das neue Element enthält. Andernfalls wird das neue Element einfach zu dieser bereits vorhandenen Liste hinzugefügt Speicherung der Metadaten Aufgrund der von Amazon festgelegten Beschränkungen für Stapelverarbeitungsanfragen (siehe Kapitel ) muss nach dem Hinzufügen von Elementen gewährleistet werden, dass diese Beschränkungen eingehalten werden. Falls diese Überprüfung ergibt, dass kein 56

58 Allgemeine Verwaltung weiteres Element für diese Domain hinzugefügt werden kann, liegt es in der Verantwortung dieser Komponente, die bisher gesammelten Metadaten zu übertragen. Dafür erstellt die Komponente einen neuen Thread (siehe Kapitel ), in welchem die zu speichernden Metadaten dieser Domain gespeichert werden. Um die weitere Verarbeitung von Metadaten nicht zu behindern, wird die Liste daraufhin geleert und steht sofort wieder für die weitere Erfassung von Metadaten zur Verfügung. Anschlieÿend sorgt der erstellte Thread dafür, dass diese Metadaten in den Domains zur Dokumentenverwaltung abgespeichert werden. Nach Abschluss der Archivierung von Dokumenten für einen Mandanten müssen sämtliche, noch nicht gespeicherten Metadaten ebenfalls in die Domains der Dokumentenverwaltung übertragen werden. Dafür wird für jede vorhandene Domain ein eigener Thread erstellt, der die Metadaten in dieser Domain abspeichert. Nachdem die Metadaten in die Amazon SimpleDB übertragen wurden, ist die Abarbeitung dieses Jobs beendet. 3.3 Allgemeine Verwaltung In diesem Abschnitt werden die Möglichkeiten zur allgemeinen Verwaltung der AWS beschrieben, wobei die Funktionen der AWS entweder im entwickelten Kommandozeilenwerkzeug oder in der von Amazon stammenden web-basierenden Schnittstelle gesteuert werden können Kommandozeilenwerkzeug Das Kommandozeilenwerkzeug awscmd bietet eine umfassende Befehlssammlung zur Verwaltung der im Projekt verwendeten AWS. Dieser Abschnitt beschreibt sowohl diejenigen Befehle, welche ausschlieÿlich die allgemeinen Funktionen der AWS betreen und welche somit unabhängig vom vorhandenen Projekt sind (siehe Tabellen 3.3 bis 3.7), als auch die projekteigenen Befehle zur Verwaltung und Integration der Knoten (siehe Tabelle 3.8) Voraussetzungen Die Voraussetzung für den Start des Kommandozeilenwerkzeugs ist, dass sich die Bibliotheken des Packages cmgrid-aws (siehe Kapitel 3.1) im CLASSPATH des Systems benden, da das Kommandozeilenwerkzeug ansonsten keine Funktionen der AWS nutzen kann. Die folgenden Bibliotheken, welche sich im Paket 'cmgrid-service-war' benden, müssen zur Verwendung des Kommandozeilenwerkzeugs im CLASSPATH vorhanden sein: 57

59 Allgemeine Verwaltung cmgrid-aws-1.0.jar aws.simpledb-1.0.jar aws.s3-1.0.jar commons-codec-1.3.jar commons-httpclient jar commons-logging-1.1.jar aws.ec2-1.0.jar Befehlsgesteuerter Modus Im befehlsgesteuerten Modus wird dem Kommandozeilenwerkzeug der auszuführende Befehl direkt beim Aufruf als Parameter (um weitere befehlsspezische Parameter ergänzt) übergeben. Die Anzahl und Formatierung der einzelnen Zusatzparameter hängt hierbei vom jeweiligen durchzuführenden Befehl ab. Grundsätzlich muss der Aufruf allerdings der folgenden Form entsprechen: java awscmd <command> [<parameter1> <parameter2> <parameter3>...]? Erklärungen der verwendeten Ausdrücke: Die Verwendung von [...]? bedeutet, dass der Inhalt der eckigen Klammern entweder einmal oder gar nicht vorkommen kann. Die Verwendung von [...]+ bedeutet, dass der Inhalt der eckigen Klammern mindestens einmal, aber auch mehrmals nacheinander vorkommen kann. In den folgenden Tabellen werden sämtliche Befehle des Kommandozeilenwerkzeugs inklusive deren spezischer Parameter aufgelistet. 58

60 Allgemeine Verwaltung Die Tabelle 3.3 enthält zunächst die allgemeinen Befehle zur Verwendung des Kommandozeilenwerkzeug. Befehl Verwendung Befehlsbeschreibung usage usage [/detailed]? zeigt (optional detaillierte) Hinweise zur allgemeinen Verwendung des Kommandozeilenwerkzeugs an usage usage /keywords [<keyword>]+ zeigt detaillierte Hinweise für diejenigen Befehle an, welche eines der angegebenen Schlüsselwörter betreen usage usage [<command>]+ zeigt detaillierte Hinweise für die angegebenen Befehle an interactive interactive startet den interaktiven Modus (siehe Kapitel ) Tabelle 3.3: Allgemeine Befehle 59

61 Allgemeine Verwaltung Die Tabelle 3.4 enthält die für Amazon SimpleDB verfügbaren Befehle inklusive der spezischen Parameter für die einzelnen Befehle. Befehl Verwendung Befehlsbeschreibung listdomains listdomains listet sämtliche vorhandenen Domains dieses Accounts auf createdomain createdomain [<domainname>]+ erstellt neue Domains mit den angegebenen Namen deletedomain deletedomain [<domainname>]+ löscht die Domain(s) mit den angegebenen Namen listitems listitems <domainname> listet die Elemente der angegebenen Domain auf putitem putitem <domainname> <itemname> [<attribute> <value> <replaceable>]+ überträgt für ein Element die angegebenen Attribute in die Domain edititems edititems <domainname> <whereexpression> [<attribute> <value> <replaceable>]+ überträgt für alle den Kriterien entsprechenden Elemente die angegebenen Attribute in die Domain deleteitems deleteitems <domainname> [<itemname>]+ löscht die aufgelisteten Elemente aus der angegebenen Domain deleteitems deleteitems <domainname> /all löscht sämtliche Elemente aus der angegebenen Domain deleteitems deleteitems <domainname> /where <whereexpression> löscht den Kriterien entsprechende Elemente aus der angegebenen Domain deleteitems deleteitems <domainname> /range [<numberrange>]+ löscht die Elemente aus der angegebenen Domain, deren Bezeichner in den angegebenen Zahlenbereichen liegt (z.b. '12-17;23', nur möglich für Nummern als Bezeichner) deleteattributes deleteattributes <domainname> <itemname> [<attribute>]+ löscht die Attribute des Elements aus der Domain (die Option '/all' löscht alle Attribute des Elements) select select "<selectexpression>" führt die angegebene Auswahlanfrage ('select-from-where') aus fullselect fullselect "<selectexpression>" führt die angegebene Auswahlanfrage ('select-from-where') vollständig aus Tabelle 3.4: Befehle für Amazon SimpleDB 60

62 Allgemeine Verwaltung Die Tabelle 3.5 enthält die für Amazon S3 verfügbaren Befehle inklusive der spezischen Parameter für die einzelnen Befehle. Befehl Verwendung Befehlsbeschreibung listbuckets listbuckets listet sämtliche vorhandenen Buckets dieses Accounts auf createbucket createbucket <bucketname> [<location>]? erstellt einen neuen Bucket mit dem angegebenen Namen deletebucket deletebucket <bucketname> löscht die Domain(s) mit den angegebenen Namen listobjects listobjects <bucketname> listet die Objekte des angegebenen Buckets auf objectexists objectexists <bucketname> [<objectkey>]+ prüft, ob die angegebenen Objekte im Bucket vorhanden sind objectdetails objectdetails <bucketname> [<objectkey>]+ gibt Details zu den angegebenen Objekten des Buckets aus putstring putstring <bucketname> <objectkey> <stringtext> überträgt den Text unter dem angegebenen Objektschlüssel in den Bucket putfile putfile <bucketname> <destinationdir> <localfilename> überträgt die lokale Datei in das Zielverzeichnis des Buckets deleteobject deleteobject <bucketname> <objectkey> löscht das angegebene Objekt aus dem Bucket Tabelle 3.5: Befehle für Amazon S3 61

63 Allgemeine Verwaltung Die Tabelle 3.6 enthält die für Amazon EC2 verfügbaren Befehle inklusive der spezischen Parameter für die einzelnen Befehle. Befehl Verwendung Befehlsbeschreibung describeimages describeimages [<imageid>]+ gibt Details zu den angegebenen Images aus describeinstances describeinstances [<instanceid>]+ gibt Details zu den angegebenen Instanzen aus describevolumes describevolumes [<volumeid>]+ gibt Details zu den angegebenen Laufwerken aus startinstance startinstance [<imageid> [<securitygroup> [<keyname>]? ]? ]? startet eine neue Instanz basierend auf dem angegebenen Image, der Sicherheitsgruppe und dem Schlüsselnamen (mit Standardwerten, falls nicht angegeben) terminateinstance terminateinstance <instanceid> beendet die angegebene Instanz getconsole getconsole <instanceid> gibt die Konsolenausgabe der angegebenen Instanz aus attachvolume attachvolume <instanceid> <volumeid> <device> hängt ein Laufwerk als bestimmtes Gerät an eine laufende Instanz an detachvolume detachvolume <instanceid> <volumeid> <device> [<force>]? trennt ein Laufwerk als bestimmtes Gerät von einer laufenden Instanz ab associateaddress associateaddress <instanceid> <publicip> verbindet die laufende Instanz mit der angegebenen öentlichen IP disassociateaddress disassociateaddress <publicip> trennt die laufende Instanz von der angegebenen öentlichen IP Tabelle 3.6: Befehle für Amazon EC2 62

64 Allgemeine Verwaltung Die Tabelle 3.7 enthält die für Amazon SQS verfügbaren Befehle inklusive der spezischen Parameter für die einzelnen Befehle. Befehl Verwendung Befehlsbeschreibung listqueues listqueues listet sämtliche vorhandenen Buckets dieses Accounts auf getorcreatequeue getorcreatequeue <queuename> [<timeout>]? gibt die angegebene MessageQueue zurück (wird mit dem angegebenen Timeout erstellt, falls noch nicht vorhanden) getqueue getqueue <queueurl> gibt die angegebene MessageQueue zurück deletequeue deletequeue [<queueurl>]+ löscht die angegebenen MessageQueues sendmessage sendmessage <queueurl> [<message>]+ reiht die angegebenen Nachrichten in die MessageQueue ein receivemessage receivemessage <queueurl> [<messagecount>]? ruft die angegebene Anzahl an Nachrichten von der MessageQueue ab deletemessage deletemessage <queueurl> [<receipthandle>]+ löscht die Nachrichten mit den angegebenen Belegen aus der MessageQueue receiveanddeletemessage receiveanddeletemessage <queueurl> [<messagecount>]? ruft die angegebene Anzahl an Nachrichten von der MessageQueue ab und löscht diese Nachrichten anschlieÿend settimeout settimeout <queueurl> <timeout> setzt den Timeout der angegebenen MessageQueue Tabelle 3.7: Befehle für Amazon SQS 63

65 Allgemeine Verwaltung Zusätzlich zu diesen Befehlen sind zur Verwaltung des Prototyps noch projekteigene Befehle vorhanden (siehe Tabelle 3.8). Befehl Verwendung Befehlsbeschreibung cmgstart cmgstart <nodetype> startet eine Projektinstanz des angegebenen Typs ('JobServer', 'SearchServer' oder 'PAI') cmgterminate cmgterminate <instanceid> beendet die angegebene Projektinstanz cmgshutdown cmgshutdown beendet diese Maschine (innerhalb der Projektinstanz) cmgsendshutdown cmgsendshutdown [<nodeurl>]+ setzt das Abschaltsignal für die angegebenen Knoten cmgattach cmgattach <instanceid> hängt ein projekteigenes Laufwerk an die Projektinstanz an cmgdetach cmgdetach <instanceid> trennt das projekteigene Laufwerk von der Projektinstanz ab cmgassociate cmgassociate <instanceid> verbindet die Projektinstanz mit der projekteigenen IP cmgdisassociate cmgdisassociate trennt die Projektinstanz von der projekteigenen IP cmgaddtenant cmgaddtenant <tenantid> [<tenantpriority>]? fügt einen neuen Mandanten mit einer optionalen Priorität hinzu cmgdeletetenant cmgdeletetenant [<tenantid>]+ löscht die angegebenen Mandanten aus der Domain cmgaccount cmgaccount <tenantid> [<startdate> <enddate>]? summiert die Abrechnungsdaten des angegebenen Mandanten für einen optionalen Zeitraum auf cmgaccount cmgaccount /total [<startdate> <enddate>]? summiert die gesamten Abrechnungsdaten für einen optionalen Zeitraum auf cmgaccount cmgaccount /where <whereexpression> summiert den Kriterien entsprechende Abrechnungsdaten auf Tabelle 3.8: Projekteigene Befehle 64

66 Allgemeine Verwaltung Interaktiver Modus Der interaktive Modus des Kommandozeilenwerkzeugs bietet die Möglichkeit, bestimmte Befehle für die AWS auszuführen, indem die Befehle nicht von Hand eingegeben, sondern über eine interaktive Auswahl der verfügbaren Befehle selektiert werden. Um den interaktiven Modus zu starten, muss das Kommandozeilenwerkzeug folgendermaÿen aufgerufen werden: java awscmd interactive Auswahl der Befehlsgruppe: Zu Beginn des interaktiven Modus wird das Hauptmenü angezeigt, in welchem zunächst die Befehlsgruppe des auszuführenden Befehls gewählt werden kann: available commands: 'L': list list domains, queues, buckets, objects... 'C': create create domains/queues/buckets, start instances,... 'D': delete delete domains/queues/buckets, terminate instances,... 'S': send send messages, put items/attributes/objects... 'G': get receive messages, get items/attributes/objects... 'M': cmgrid start/terminate cmgrid instances, attach/detach cmgrid... 'E': exit close interactive mode Befehlsgruppe Auistung: Im Untermenü list werden die verschiedenen Möglichkeiten angezeigt, um die vorhandenen Domains, Elemente und MessageQueues sowie Buckets, Objekte, Instanzen und Laufwerke aufzulisten: available list selections: 'D': domains list all available domains (in SimpleDB) 'I': items list all available items for domain (in SimpleDB) 'Q': queues list all available queues (in SQS) 'U': buckets list all available buckets (in S3) 'O': objects list all objects from bucket (in S3) 'N': instances list all available instances (in EC2) 'V': volumes list all available volumes (in EC2) 'B': back back to command menu 'E': exit close interactive mode Befehlsgruppe Erstellung: Im Untermenü create werden die verschiedenen Möglichkeiten angezeigt, um neue Domains, MessageQueues oder Buckets anzulegen bzw. um 65

67 Allgemeine Verwaltung Zuordnungen von laufenden Instanzen zu Laufwerken oder öentlichen IP-Adressen zu erstellen: available create selections: 'D': domain create new domain (in SimpleDB) 'Q': queues create new queue (in SQS) 'U': buckets create new bucket (in S3) 'A': attach attach volume to running instance (in EC2) 'S': associate associate address with running instance (in EC2) 'B': back back to command menu 'E': exit close interactive mode Befehlsgruppe Entfernung: Im Untermenü delete werden die verschiedenen Möglichkeiten angezeigt, um vorhandene Domains, Elemente oder Attribute sowie MessageQueues, Buckets oder Objekte zu löschen bzw. um Zuordnungen von laufenden Instanzen zu Laufwerken oder öentlichen IP-Adressen aufzuheben: available delete selections: 'D': domain delete domain (in SimpleDB) 'I': item delete item from domain (in SimpleDB) 'A': attribute delete attribute from item in domain (in SimpleDB) 'Q': queue delete queue (in SQS) 'U': bucket delete bucket (in S3) 'O': object delete object from bucket (in S3) 'T': detach detach volume from running instance (in EC2) 'S': disassociate disassociate address form running instance (in EC2) 'B': back back to command menu 'E': exit close interactive mode Befehlsgruppe Versand: Im Untermenü send werden die verschiedenen Möglichkeiten angezeigt, um neue Elemente, Attribute oder Nachrichten sowie Objekte (Dateien oder Zeichenketten) zu übertragen: available send selections: 'I': item put new item in domain (in SimpleDB) 'A': attribute put attribute to existing item in domain (in SimpleDB) 'M': message send message to queue (in SQS) 'F': file send file to existing bucket (in S3) 'S': string send string to existing bucket (in S3) 'B': back back to command menu 'E': exit close interactive mode 66

68 Allgemeine Verwaltung Befehlsgruppe Empfang: Im Untermenü get werden die verschiedenen Möglichkeiten angezeigt, um Nachrichten aus einer MessageQueue oder Beschreibungen zu bestimmten AMI abzurufen: available get selections: 'M': message receive message from queue (in SQS) 'I': image get image description (in EC2) 'B': back back to command menu 'E': exit close interactive mode Projekteigene Befehlsgruppe: Im Untermenü cmgrid werden die verschiedenen Möglichkeiten angezeigt, um projekteigene Befehle zur Verwaltung und Integration der Knoten auszuführen: available cmgrid selections: 'C': create create cmgrid environment (domains, buckets,...) 'L': delete delete cmgrid environment (domains, buckets,...) 'S': start start new cmgrid instance 'T': terminate terminate running cmgrid instance 'A': attach attach cmgrid volume to running instance 'D': detach detach cmgrid volume from running instance 'P': associate associate elastic IP with running instance 'I': disassociate disassociate elastic IP from running instance 'H': shutdown shutdown this machine (within running instance) 'U': shutdown shutdown an instance (set shutdown signal) 'N': add tenant add new tenant to tenant domain 'X': delete tenant delete tenant from tenant domain 'O': accounting show accounting data 'B': back back to command menu 'E': exit close interactive mode 67

69 Allgemeine Verwaltung Web-basierende Schnittstelle von Amazon Amazon stellt für die Verwaltung der Instanzen eine eigene web-basierende Schnittstelle namens AWS Management Console 4 zur Verfügung (siehe Abbildung 3.3). Abbildung 3.3: Web-basierende Schnittstelle von Amazon In dieser Schnittstelle können neue Instanzen basierend auf beliebigen vorhandenen AMI gestartet, die laufenden Instanzen überwacht sowie überüssige Instanzen wieder terminiert werden. Des Weiteren sind Funktionen vorhanden, um beliebige Laufwerke an die laufenden Instanzen anzuhängen oder um öentliche IP-Adressen zu diesen Instanzen zuzuordnen. Die nähere Dokumentation dieser Schnittstelle kann auf der oben erwähnten Webseite eingesehen werden und wird somit in dieser Arbeit nicht weiter erläutert

70 4 Integration 4.1 Allgemeiner Aufbau In diesem Kapitel wird der Aufbau der Archivierungslösung beschrieben, indem die in Amazon SimpleDB verwendeten Domains sowie die Interaktion zwischen den implementierten Komponenten erläutert wird Domains des Prototyps Aufgrund der Portierung des Prototyps von einer lokalen Datenbanklösung hin zur Verwendung der AWS werden Domains benötigt, welche die zuvor genutzten Tabellen ersetzen. Allerdings musste dabei die Charakteristik des vereinfachten Datenbankspeichers innerhalb der Amazon SimpleDB beachtet werden, um die Daten dennoch mit einer ausreichenden Geschwindigkeit abfragen zu können. Aufgrund der fehlenden Verbund-Operation der Amazon SimpleDB wurden die Daten innerhalb der Domains denormalisiert abgespeichert, was bedeutet, dass die Daten (eventuell) mehrmals redundant in verschiedenen Elementen vorkommen können. Dadurch können die Elemente ezient abgefragt werden, ohne noch zusätzliche Anfragen für referenzierte Attribute zu benötigen. Allerdings erhöht sich dementsprechend auch der Speicherplatzbedarf. In der Abbildung 4.1 werden sämtliche innerhalb des Prototyps verwendeten Domains mitsamt der darin abgespeicherten Attribute dargestellt. Aufgrund der Key-Value Charakteristik dieses Speichers müssen Elemente innerhalb der Domains allerdings nicht zwingend alle hier aufgeführten Attribute enthalten (es existiert kein deniertes Schema, wie es im Gegensatz dazu in relationalen Datenbanklösungen der Fall wäre). 69

71 Allgemeiner Aufbau Abbildung 4.1: Domains des Prototyps Mandanten Die Mandanten können in der Domain 'cmgridtenants' gespeichert werden, falls innerhalb des Prototyps nicht die Standardwerte für einen Mandanten verwendet werden sollen. Das Attribut 'tenantpriority' gibt die Priorität des jeweiligen Mandanten an, mit der er in der Komponente SchedulerLayer (siehe Kapitel 3.2.4) bei der Auswahl des nächsten Jobs berücksichtigt werden soll. Falls dieses Attribut nicht vorhanden ist, wird eine festgelegte Standardpriorität von 100 verwendet. Zudem kann im Attribut 'state' festgelegt werden, ob dieser Mandant überhaupt aktiv ist oder ob die Priorität dieses Mandanten ignoriert werden soll Jobs Sämtliche eingereihten Jobs werden komplett in der Domain 'cmgridjobs' abgespeichert. Die hier festgelegten Angaben in den Attributen 'handlers' und 'properties' werden während des Archivierungsprozesses verwendet, um die einzelnen Dokumente dieses Jobs an die jeweiligen Handler mit den entsprechenden Eigenschaften zu übergeben. 70

72 Allgemeiner Aufbau Ein Handler realisiert einen einzelnen Verarbeitungsschritt im gesamten Archivierungsprozess und ist für eine bestimmte Aufgabe zuständig, wobei die Eigenschaften des Handlers in jedem Job einzeln festgelegt werden können (zum Beispiel ist der Handler Part- DigestCalculator für die Berechnung des Hash-Wertes nach einem als Eigenschaft übergebenen Algorithmus zuständig) Knoten Jeder im Netzwerk vorhandenen Knoten trägt sich beim Starten in der Domain 'cmgridnodes' ein, indem er seine lokale IP als URL sowie seinen jeweiligen Knotentyp im Attribut 'nodetype' angibt. Zudem wird der Status running im Attribut 'state' eingetragen, um diesen Knoten als verfügbar zu deklarieren. Mit Hilfe dieses Attributs kann das Abschaltsignal für den jeweiligen Knoten gesetzt werden, indem der Status shutdown eingetragen wird. Sobald der Knoten einen Job beendet und anschlieÿend den Status shutdown vorndet, nimmt er keinen weiteren Job an und fährt sich selbst herunter Dokumente Aufgrund der zu erwartenden Vielzahl an zu archivierenden Dokumenten wird zur Speicherung der Dokumente nicht eine einzelne Domain, sondern eine Verteilung auf 90 Domains verwendet (von 'cmgriddocuments00' bis 'cmgriddocuments89'). Für jedes zu speichernde Dokument wird eine Hashfunktion verwendet, deren Ergebnis die Nummer der Domain festlegt, die diesem Dokument zugeordnet ist. Diese Höchstgrenze für die Anzahl an Domains für Dokumente ergibt sich aus den Beschränkungen eines Accounts bezüglich der Anzahl an maximal verfügbaren Domains (siehe Kapitel ) Fälle Ein Fall umfasst eine bestimmte Anzahl an Dokumenten und wird in der Domain 'cmgridcases' gespeichert. Diese Funktionalität wurde in dieser Arbeit nicht weiter verfolgt Abrechnung Die während des Archivierungsprozesses anfallenden Abrechnungsdaten werden in der Domain 'cmgridaccounting' gespeichert. Dabei wird ein Datensatz pro Mandant und Speicherzeitpunkt angelegt, der sämtliche Kennzahlen der Abrechnungsdaten für diesen 71

73 Allgemeiner Aufbau Mandanten für den Zeitraum vom letzten Speicherzeitpunkt bis zu diesem Speicherzeitpunkt enthält (siehe Kapitel 3.2.3). Nachdem die aktuellen Abrechnungsdaten gespeichert wurden, wird der Datensatz dieses Mandanten geleert, um die Abrechnungsdaten des nächsten Zeitraums aufzunehmen. Da die Abrechnungsdaten ebenfalls von verschiedenen Prozessen erfasst werden, muss der Zugri auf die Abrechnungsdaten synchronisiert erfolgen, um keine unerwünschten Nebenläugkeiten zu erhalten. Zu diesem Zweck wird zum einen die Erfassung der Abrechnungsdaten für die Dauer der Speicherung (bzw. bis die Daten geleert wurden) gesperrt. Zum anderen sind die Variablen der Abrechnungsdaten vom Typ 'AtomicInteger' und 'AtomicLong', wodurch der atomare Zugri darauf gewährleistet ist Indexe Der durch Apache Lucene erstellte Index wird entweder auf einem Netzlaufwerk des Search Servers oder lokal in den Instanzen abgespeichert und abschlieÿend in der Domain 'cmgridindexes' zusammengefasst. Diese Funktionalität wurde in dieser Arbeit nicht weiter verfolgt Search Server Die Search Server werden in der Domain 'cmgridsearchserver' abgespeichert. Diese Funktionalität wurde in dieser Arbeit nicht weiter verfolgt Bereitstellung neuer Jobs Die Bereitstellung neuer Jobs kann entweder direkt per Kommandozeile mit Hilfe der Komponente AWSLoadJobs (siehe Kapitel ) oder indirekt über die Benutzerober- äche (siehe Kapitel ) erfolgen. Die Benutzeroberäche nutzt dabei im Hintergrund ebenfalls die Funktionalität der Komponente AWSLoadJobs, um die neuen Jobs in die Warteschlange einzureihen. In der Abbildung 4.2 wird die Bereitstellung neuer Jobs im einzelnen dargestellt. 72

74 Allgemeiner Aufbau Abbildung 4.2: Bereitstellung neuer Jobs Nachdem die Komponente AWSLoadJobs eine Jobdatei, bestehend aus jeweils einem Job pro Zeile, erhalten hat, werden sämtliche Jobs nacheinander einzeln in die Warteschlange für Jobs, also die Komponente AWSJobQueue (siehe Kapitel ), eingereiht. Die Komponente AWSJobQueue gibt zu diesem Zweck jeden erhaltenen Job an die Komponente SchedulerLayer (siehe Kapitel 3.2.4) weiter. In der Komponente SchedulerLayer wird der erhaltene Job zunächst komplett in der Domain 'cmgridjobs' abgespeichert. Anschlieÿend wird, abhängig vom Mandanten dieses Jobs, der Bezeichner des Jobs in die MessageQueue dieses Mandanten in Amazon SQS eingereiht. Somit steht für jeden vorhandenen Mandanten eine eigene MessageQueue zur Verfügung, aus der die Jobbezeichner dieses Mandanten abgerufen werden können Abruf eingereihter Jobs Der Abruf und die Verteilung von eingereihten Jobs erfolgt durch die Komponente DispatcherCapability (siehe Abbildung 4.3), welche die Realisierung des sogenannten Dispatchers darstellt. 73

75 Allgemeiner Aufbau Abbildung 4.3: Abruf eingereihter Jobs Nachdem der Dispatcher (Verteiler der Jobs) gestartet wurde, fordert dieser zunächst einen Job bei der Warteschlange AWSJobQueue an. Die Komponente AWSJobQueue wiederum leitet die Anfrage an die Komponente SchedulerLayer weiter, welche eine priorisierte Zufallsauswahl des nächsten Jobs durchführt. Das bedeutet, dass die Prioritäten der Mandanten für eine zufällige Auswahl des nächsten Mandanten verwendet werden (je höher die Priorität eines Mandanten, umso häuger wird er ausgewählt). Anschlieÿend wird ein Jobbezeichner aus der jeweiligen MessageQueue des gewählten Mandanten abgerufen und an die Warteschlange zurückgeliefert. Die Warteschlange lädt daraufhin die Jobdaten des zurückgelieferten Jobbezeichners aus der Domain 'cmgridjobs' und gibt den vollständigen Job an den Dispatcher weiter. Der Dispatcher sucht nun im Netzwerk nach vorhandenen Knoten und beauftragt den ersten verfügbaren PAI-Knoten mit der Durchführung des erhaltenen Jobs Archivierungsprozess Der vollständige Archivierungsprozess der einzelnen Jobs läuft auf den verschiedenen PAI-Knoten ab (siehe Abbildung 4.4), wobei die abzuarbeitenden Handler und deren Eigenschaften innerhalb des Jobs festgelegt sind. 74

76 Allgemeiner Aufbau Abbildung 4.4: Archivierungsprozess Auf den PAI-Knoten bendet sich die Komponente PaiCapability, die den durchzuführenden Job über das Netzwerk vom Dispatcher empfängt und an die Komponente Crawler (siehe Kapitel ) weitergibt. Diese Komponente startet für diesen Job die Unterklasse 'WorkerRunnable', welche sämtliche Dokumente dieses Jobs einzeln nacheinander in den Archivierungsprozess einführt, indem das jeweilige Dokument an die Komponente DocumentIngestProcessor übergeben wird. Die Komponente DocumentIngestProcessor ist dafür verantwortlich, das vorliegende Dokument nacheinander an jeden der Handler zu übergeben, die im Job festgelegt sind. Die Handler können dabei beliebig kombiniert werden und müssen als einzige Voraussetzung die Schnittstelle 'DocumentHandler' realisieren. Im dargestellten Beispiel in der Abbildung 4.4 wird das Dokument zuerst dem Handler PartDigestCalculator übergeben, der einen eindeutigen Hash-Wert für das Dokument berechnet und diesen Hash-Wert für die weitere Verwendung durch die folgenden Handler in die Eigenschaften des Dokuments einträgt. Anschlieÿend wird der Text des Dokuments mit Hilfe des Handlers ExtractPlainTextHandler extrahiert und im Handler LuceneIndexingHandler für die Erstellung des Indexes verwendet. 75

77 Allgemeiner Aufbau Der folgende Handler AWSDeDuplicate dient zur Duplikaterkennung (siehe Kapitel ) und fügt das Ergebnis der Erkennung ebenfalls in die Eigenschaften des Dokuments ein. Zuletzt überprüft der Handler AWSHandler das zuvor hinzugefügte Ergebnis der Duplikaterkennung (siehe Kapitel ). Falls dieses Dokument kein Duplikat ist, wird es an die Komponente AWSProcessor zur endgültigen Speicherung (siehe Kapitel ) und somit zum Abschluss der Archivierung übergeben Speicherung der Dokumente Die letztendliche Speicherung des Dokuments zum Abschluss der Archivierung wird von der Komponente AWSProcessor initiiert und durchläuft anschlieÿend die in Abbildung 4.5 dargestellten Schritte innerhalb der verschiedenen Schichten. Abbildung 4.5: Speicherung der Dokumente Nachdem die Komponente AWSProcessor das zu speichernde Dokument erhalten hat, werden die Daten und die Metadaten des Dokuments an die Komponente Coordination- Layer (siehe Kapitel 3.2.2) übertragen. 76

78 Zugri auf das Package cmgrid-aws In der Komponente CoordinationLayer werden die Metadaten des Dokuments verarbeitet, indem zunächst eine Hash-Berechnung für dieses Dokument durchgeführt wird. Das Ergebnis dieser Berechnung wird benötigt, um das Dokument zu einer der vorhandenen Domains zur Dokumentenverwaltung zuzuordnen. Die dabei verwendete Hash-Funktion berechnet einen Hash-Wert für die ID des Dokuments und teilt diesen Wert mit Hilfe des Modulo-Operators (berechnet den Rest einer Division) durch die Anzahl an Domains (zum Beispiel ergibt die ID 'abc123' den Hash-Wert 9876, dieser Wert modulo 90 ergibt 66). Aufgrund dieses Wertes wird das Dokument zur Domain mit dieser Nummer zugeordnet und mitsamt dieser Zuordnung an die Komponente CollectorLayer (siehe Kapitel 3.2.5) übertragen. In der Komponente CollectorLayer werden sämtliche Metadaten zu den einzelnen Dokumenten für alle Domains zwischengespeichert und erst am Ende der Archivierung komplett übertragen, indem für jede Domain bei der Speicherung ein eigener Thread in der Komponente ThreadingLayer (siehe Kapitel 3.2.1) ausgeführt wird. Des Weiteren werden die Daten des Dokuments in der Komponente CoordinationLayer verarbeitet, indem für jedes Dokument und jeden Dokumentteil ebenfalls ein Thread zur Speicherung dieser Daten in der Komponente ThreadingLayer gestartet wird. In der Komponente ThreadingLayer werden sämtliche gestarteten Threads ausgeführt, wobei die Metadaten der Dokumente in der jeweils errechneten Domain in der Amazon SimpleDB sowie die Daten der Dokumente und Dokumentteile in Amazon S3 abgespeichert werden. Die beim Abspeichern anfallenden Abrechnungsdaten werden dabei an die Komponente AccountingLayer übergeben (siehe Kapitel 3.2.3), welche die Abrechnungsdaten für alle Mandanten am Ende des Archivierungsprozesses in die Domain 'cmgridaccounting' überträgt. 4.2 Zugri auf das Package cmgrid-aws Im Rahmen der Integration der AWS in das vorhandene Projekt mussten einige Komponenten entweder neu implementiert oder teilweise überarbeitet werden, um die entsprechende Funktionalität zur Verfügung stellen zu können. Die jeweilige Entscheidung, ob eine Komponente neu implementiert oder nur überarbeitet wurde, hing dabei vom Ausmaÿ der notwendigen Änderungen innerhalb der Komponente ab. Falls nur wenige Bereiche angepasst werden mussten, wurde die Komponente nur überarbeitet, andernfalls komplett neu implementiert. 77

79 Zugri auf das Package cmgrid-aws Neue Komponenten Für den Zugri auf das Package cmgrid-aws (siehe Kapitel 3.1) innerhalb des Projekts mussten die folgenden Komponenten neu implementiert werden, da keine Funktionalität aus den vorhandenen Komponenten wiederverwendet werden konnte AWSJobQueue Innerhalb der Komponente AWSJobQueue existiert die Klasse AWSJobQueue, die mit Hilfe der AWS die im Projekt vorgesehene Schnittstelle einer Warteschlange (Queue) für Jobs realisiert. Im Projekt kann die verwendete Warteschlange somit einfach ausgetauscht werden, indem an den entsprechenden Stellen des Projekts, anstatt der bisherigen Warteschlange, diese Klasse instanziiert und verwendet wird. Die Klasse bietet Methoden zur Erstellung, zum Abruf und zur Beendigung der Jobs innerhalb des Projekts an. Die Verbindung zu den AWS erfolgt mit Hilfe der Komponente SchedulerLayer (siehe Kapitel 3.2.4), die die letztendliche Funktionalität für die Jobverwaltung zur Verfügung stellt AWSSegmentRegistry Innerhalb der Komponente AWSSegmentRegistry existiert die Klasse AWSSegmentRegistry, die mit Hilfe der AWS die im Projekt vorgesehene Schnittstelle einer Registrierung (Registry) realisiert. Im Projekt kann die verwendete Registrierung somit einfach ausgetauscht werden, indem an den entsprechenden Stellen des Projekts, anstatt der bisherigen Registrierung, diese Klasse instanziiert und verwendet wird. Die Klasse bietet Methoden zur Verwaltung des Indexes und der Search Server innerhalb des Projekts an, wobei die Verbindung zu den AWS direkt mittels der Komponente SimpleDB (siehe Kapitel 3.1.3) erfolgt. Da die Funktionalität des Indexes und der Search Server keine Priorität in dieser Arbeit aufweist, wurde diese Komponente gröÿtenteils nur rudimentär entwickelt, damit die anderen Komponenten nicht negativ beeinusst werden AWSDeDuplicate Innerhalb der Komponente AWSDeDuplicate existiert die Klasse AWSDeDuplicate, die eine im Projekt vorhandene Schnittstelle für die Bearbeitung von Dokumenten (einen sogenannten DocumentHandler) realisiert. Im Verlaufe der Dokumentenarchivierung wird das Dokument von verschiedenen Handlern bearbeitet, wobei jeder Handler eine be- 78

80 Zugri auf das Package cmgrid-aws stimmte Aufgabe erledigt. Bei der Erstellung der Jobs für die Dokumentenarchivierung können die zu verwendenden Handler für den jeweiligen Vorgang beliebig ausgewählt werden. Dieser Handler besitzt die Aufgabe, das bearbeitete Dokument bzw. die Dokumentteile daraufhin zu untersuchen, ob es ein Duplikat ist (und somit nicht weiter archiviert werden muss), oder ob es kein Duplikat ist (und somit den gesamten Archivierungsprozess durchlaufen muss). Für die Entscheidung, ob ein Duplikat vorliegt, können mehrere Möglichkeiten in Betracht gezogen werden. Die Auswahl der tatsächlich zu prüfenden Möglichkeiten erfolgt mit Hilfe der Eigenschaften des Jobs, welche bei der Erstellung dieses Handlers als Parameter übergeben werden. In diesen Eigenschaften ist für jede der vorhandenen Möglichkeiten ein Entscheidungswert (wahr oder falsch) angegeben, der festlegt, ob diese Möglichkeit in diesem Handler geprüft werden soll. Sammlung: Bei der Archivierung von Dokumenten werden die abzuspeichernden Metadaten des Dokuments in der Komponente CollectorLayer (siehe Kapitel 3.2.5) zusammengefasst, bevor sie gesammelt in die Domain übertragen werden. In diesem Handler besteht also die Möglichkeit, innerhalb dieser Sammlung nach dem aktuellen Dokument zu suchen. Falls sich das Dokument bereits in der Sammlung bendet, handelt es sich um ein Duplikat. Da die gesammelten Daten in der Komponente CollectorLayer im Speicher vorliegen, kann die Prüfung auf Duplikate in der Datensammlung sehr schnell vorgenommen werden. Aufgrund der von Amazon festgelegten Beschränkungen (siehe Kapitel ) benden sich allerdings nicht allzu viele Daten in der Datensammlung. Domain: Eine weitere Möglichkeit, ein Dokument als Duplikat zu identizieren, besteht aus der Überprüfung der Domain, in die die Metadaten des Dokuments abgespeichert werden sollen. Falls das Dokument in der Domain bereits existiert, handelt es sich um ein Duplikat und die weitere Archivierung des Dokuments ist unnötig. Da für jedes Dokument eine einzelne Anfrage an die Domain gestellt werden muss, ist diese Möglichkeit nur zu empfehlen, falls unter den zu archivierenden Dokumenten viele Duplikate zu erwarten sind. Andernfalls würden die wiederholten erfolglosen Anfragen den gesamten Archivierungsvorgang deutlich verlangsamen, ohne einen tieferen Mehrwert davon zu erhalten. Index: Bei der Archivierung von Dokumenten und Dokumentteilen werden die Schlüssel der abgespeicherten Objekte in einem Index in der Komponente S3 (siehe Kapitel 3.1.4) zwischengespeichert. In diesem Handler besteht somit die Möglichkeit, innerhalb dieses Indexes nach dem aktuellen Dokument und den Dokumentteilen zu suchen. Falls das Dokument bzw. einzelne Dokumentteile bereits indiziert wurde, handelt es sich dabei um Duplikate. 79

81 Zugri auf das Package cmgrid-aws Da sich der Index innerhalb der Komponente S3 im Speicher bendet, kann die Prüfung auf Duplikate im Index sehr schnell durchgeführt werden und ist somit immer zu empfehlen. Zusätzlich besteht auch noch die Möglichkeit, vor Beginn eines Jobs sämtliche bisher archivierten Objekte in den Index zu laden, wodurch die Erkennung eines Duplikates vollständig mit Hilfe des Indexes erfolgen kann. Allerdings kann die Erstellung des Indexes sehr lange dauern, falls bereits ausgesprochen viele Objekte archiviert wurden (ein Test ergab ca. 30 Sekunden für 5000 Objekte). Somit muss für jede Archivierung entschieden werden, ob sich der Mehraufwand zur Erstellung des Indexes in der jeweiligen Situation lohnt. Bucket: Eine weitere Möglichkeit, Dokumente und Dokumentteile als Duplikate zu identizieren, besteht aus der Überprüfung des Buckets, in welchem die Dokumente und Dokumentteile abgespeichert werden sollen. Falls das Dokument bzw. einzelne Dokumentteile im Bucket bereits existieren, handelt es sich dabei um Duplikate und die weitere Archivierung ist unnötig. Da für jedes Dokument und jeden Dokumentteil eine einzelne Anfrage an den Bucket gestellt werden muss, ist diese Möglichkeit nur bedingt zu empfehlen, falls unter den zu archivierenden Dokumenten und Dokumentteilen viele Duplikate zu erwarten sind. Andernfalls würden die wiederholten erfolglosen Anfragen den gesamten Archivierungsvorgang deutlich verlangsamen, ohne einen tieferen Mehrwert davon zu erhalten. Nachdem der Handler die gewählten Möglichkeiten für die Duplikaterkennung überprüft hat, wird das Ergebnis dieser Erkennung in den Eigenschaften des jeweiligen Dokuments bzw. Dokumentteils abgespeichert. Diese Eigenschaft kann anschlieÿend von den weiteren Handlern verwendet werden, um zu entscheiden, ob dieses Dokument bzw. dieser Dokumentteil weiter bearbeitet werden soll oder nicht AWSHandler Innerhalb der Komponente AWSHandler existiert die Klasse AWSHandler, die ebenfalls die im Projekt vorhandene Schnittstelle für die Bearbeitung von Dokumenten realisiert. Im Verlaufe der Dokumentenarchivierung wird das Dokument von verschiedenen Handlern bearbeitet, wobei jeder Handler eine bestimmte Aufgabe erledigt. Bei der Erstellung der Jobs für die Dokumentenarchivierung können die zu verwendenden Handler für den jeweiligen Vorgang beliebig ausgewählt werden. Dieser Handler besitzt die Aufgabe, die endgültige Archivierung des Dokuments bzw. der einzelnen Dokumentteile in den AWS zu initiieren. Für diese Aufgabe steht dem Handler die Schnittstelle eines Archivierungsservices ('ArchiveService') zur Verfügung, welcher letztendlich die Speicherung der Dokumente und Dokumentteile vornimmt. In 80

82 Zugri auf das Package cmgrid-aws diesem Handler wird dabei die Komponente AWSProcessor (siehe Kapitel ) als fester Archivierungsservice verwendet. Bevor der Handler das Dokument bzw. die Dokumentteile an den Archivierungsservice weitergibt, werden die Eigenschaften der zu speichernden Dokumente und Dokumentteile nach dem Ergebnis der Duplikaterkennung (siehe Kapitel ) durchsucht. Falls dabei festgestellt wird, dass es sich um ein Duplikat handelt, wird das jeweilige Dokument bzw. der jeweilige Dokumentteil nicht weiter an den Archivierungsservice übertragen AWSProcessor Innerhalb der Komponente AWSProcessor existiert die Klasse AWSProcessor, die die im Projekt vorhandene Schnittstelle für einen Archivierungsservice ('ArchiveService') realisiert. Im Verlaufe der Dokumentenarchivierung wird ein Archivierungsservice verwendet, um die Dokumente und Dokumentteile endgültig abzuspeichern. In den verschiedenen Handlern kann dabei individuell festgelegt werden, welcher Archivierungsservice verwendet werden soll. Dieser Archivierungsservice besitzt die Aufgabe, die endgültige Archivierung des Dokuments bzw. der einzelnen Dokumentteile in den AWS durchzuführen. Für diese Aufgabe verwendet der Archivierungsservice die Komponente CoordinationLayer (siehe Kapitel 3.2.2), welche die Speicherung des Dokuments und der zugehörigen Metadaten sowie der einzelnen Dokumentteile koordiniert. Die zu speichernden Metadaten werden in dieser Komponente festgelegt und umfassen beliebige Felder des Dokuments, die für die Suche nach diesem Dokument verwendet werden könnten (in dieser Implementierung wurden hierbei beispielsweise die Felder einer 'from', 'to', 'subject' und 'date' erfasst) AWSLoadJobs Mit Hilfe der Komponente AWSLoadJobs können beliebige Jobs per Kommandozeile direkt in die Warteschlange des Projekts geladen werden. Die gewünschten Eigenschaften für die zu erstellenden Jobs können dabei als Parameter übergeben werden. Der Aufruf kann auf zwei verschiedene Arten erfolgen, wobei entweder sämtliche Eigenschaften festgelegt oder stattdessen standardmäÿige Eigenschaften verwendet werden. Um diese Komponente aufzurufen, muss das Schlüsselwort java und der Name dieser Komponente, gefolgt von den festzulegenden Parametern in die Kommandozeile eingegeben werden. 81

83 Zugri auf das Package cmgrid-aws Aufrufmöglichkeit 1: java AWSLoadJobs <filename> <tenantid> Beispiel: java AWSLoadJobs jobfile.txt tenant123 Bei diesem Aufruf wird nur die zu verwendende Jobdatei (<filename>) sowie der Bezeichner des Mandanten (<tenantid>) übergeben. Innerhalb der Jobdatei muss dabei in jeder Zeile ein vollständiger Dateiname stehen (zum Beispiel /mnt/jobs/job_1.zip), welcher als einzelner Job für diesen Mandanten in die Warteschlange eingereiht wird (somit wird pro Zeile ein Job erstellt). Da keine Eigenschaften angegeben wurden, entscheiden die einzelnen Komponenten selbst, welche Eigenschaften standardmäÿig für diese Jobs verwendet werden. Aufrufmöglichkeit 2: java AWSLoadJobs <storagename> <filename> <handler> <archivedir> <indexprefix> <indexpostfix> <tenantid> Beispiel: java AWSLoadJobs AWS-Storage jobfile.txt AWSDeDuplicate,AWSHandler /tmp/archivedir /tmp/index.1 tenant123 Bei diesem Aufruf werden zusätzlich die zu verwendenden Eigenschaften für die zu erstellenden Jobs übergeben. Zuerst wird der Speicher (<storagename>) angegeben, welcher für die Archivierung verwendet werden soll. In dieser Version des Projekts ist dieser Parameter überüssig, da standardmäÿig die Verwendung der AWS-Komponenten festgelegt ist (der Parameter existiert nur aus Gründen der Abwärtskompatibilität weiterhin). Anschlieÿend wird die zu verwendende Jobdatei (<filename>) angegeben, die (wie bereits erwähnt) in jeder Zeile den Dateinamen eines einzelnen Jobs enthält. Daraufhin werden die abzuarbeitenden Handler (<handler>) der Archivierung festgelegt, indem die Namen der Handler mit Kommata getrennt (aber ohne Leerzeichen) aufgelistet werden. Der Parameter für das Archivierungsverzeichnis (<archivedir>) wird wiederum nur benötigt, falls ein Handler verwendet wird, der die Dokumente in das lokale Filesystem abspeichert (in dieser Version unerheblich, da die Dokumente in den AWS gespeichert werden). Die beiden nächsten Parameter dienen der Indexerstellung und bestimmen, in welches Verzeichnis und mit welchem Präx (<indexprefix>) sowie mit welcher Ergänzung (<indexpostfix>) die erstellten Indexdateien abgespeichert werden. Zuletzt muss noch der Bezeichner des Mandanten (<tenantid>) angegeben werden, für den die Jobs eingereiht werden sollen. 82

84 Zugri auf das Package cmgrid-aws AWSSearchDocuments Innerhalb der Komponente AWSSearchDocuments existiert die Klasse AWSSearchDocuments, die ein sogenanntes Servlet (HttpServlet) implementiert. Im Projekt wird dieses Servlet von der Benutzeroberäche im Bereich der Suche (siehe Kapitel ) verwendet, um die Metadaten der archivierten Dokumente nach bestimmten Kriterien zu durchsuchen und die betreenden Dokumente zurückzuliefern. Nachdem eine Suche in der Benutzeroberäche gestartet wurde, müssen die eingegebenen Parameter an diese Klasse übertragen werden. Für diesen Zweck existiert in dieser Klasse eine Unterklasse SearchParameters, welche sämtliche für die Anfrage benötigten Parameter aufnehmen kann. Demzufolge werden die Parameter zuerst aus der gesendeten Anfrage ausgelesen und in diese Unterklasse eingetragen. Ein in dieser Unterklasse vorhandener Parameter legt fest, an welche Domain diese Anfrage gesendet werden soll, wobei entweder direkt eine bestimmte Domain eingetragen werden kann oder die Domains zur Dokumentenverwaltung ausgewählt werden können. Falls eine bestimmte Domain eingetragen wurde, wird die Auswahlanfrage mit Hilfe der Komponente SimpleDB (siehe Kapitel 3.1.3) direkt an diese Domain gesendet und die zurückgelieferten Ergebnisse wiederum in dieser Unterklasse abgespeichert. Falls die Domains zur Dokumentenverwaltung ausgewählt wurden, muss die Auswahlanfrage nicht nur an eine Domain, sondern an alle Domains der Dokumentenverwaltung gesendet werden. Diese Aufgabe übernimmt die Komponente CoordinationLayer (siehe Kapitel ), welche diese Anfrage parallel durchführt, indem sie auf mehrere Threads verteilt wird. Jeder Thread schickt die Anfrage an eine einzelne Domain der Dokumentenverwaltung und speichert die erhaltenen Ergebnisse innerhalb des Threads ab. Nachdem alle Threads beendet sind, werden die Ergebnisse sämtlicher Threads (bzw. Domains) gesammelt und in der oben erwähnten Unterklasse SearchParameters abgespeichert. Nachdem die Auswahlanfrage ausgeführt wurde, werden die in der Unterklasse gespeicherten Ergebnisse in der Benutzeroberäche im Bereich der Suche dargestellt. Suchparameter: Sämtliche Parameter für die Suche in den AWS sowie die zurückgelieferten Ergebnisse werden in der Unterklasse SearchParameters in den jeweiligen Feldern gespeichert. Attribute: Das Feld selectattributes enthält die Attribute oder Direktiven (wie * oder count(*)), welche von der Anfrage zurückgeliefert werden sollen (siehe Anfrageteil 'select' in Kapitel ). Domains: Das Feld fromdomain enthält den Namen der Domain, die durchsucht werden soll (siehe Anfrageteil 'from' in Kapitel ). Allerdings besteht die Möglichkeit, stattdessen sämtliche Domains der Dokumentenverwaltung zu durchsu- 83

85 Zugri auf das Package cmgrid-aws chen, indem der Entscheidungswert docdomains (auf 'true') gesetzt wird. Kriterien: Das Feld whereexpression enthält die Kriterien, nach welchen die angegebene Domain durchsucht werden soll (siehe Anfrageteil 'where' in Kapitel ). Mandanten: Das Feld tenantid enthält den Bezeichner des Mandanten, für den diese Abfrage ausgeführt werden soll. Da sämtliche Domains der Projektumgebung für alle Mandanten gemeinsam verwendet werden, müssen die Daten innerhalb der Domains für den jeweiligen Mandanten geltert werden, damit der Mandant nur seine eigenen Daten und keine Daten anderer Mandanten zurückgeliefert bekommt. Allerdings besteht die Möglichkeit, diese Filterung zu umgehen und die Daten aller Mandanten gemeinsam zu erhalten, indem der Entscheidungswert ignoretenants (auf 'true') gesetzt wird. Dieses Feld sollte dementsprechend nur Administratoren (oder ähnlichem Personal) vorbehalten sein, denen der Zugri auf sämtliche Daten erlaubt sein muss. Ergebnisse der Suche: Das Feld results enthält die Ergebnisse der zuletzt durchgeführten Suche und ist als Hash-Tabelle aufgebaut, die jeder Domain ein eigenes Suchergebnis zuordnet. Dieses Suchergebnis enthält zum einen die in dieser Domain gefundenen Elemente sowie zum anderen eine eventuelle Markierung (den sogenannten nexttoken) für die Fortsetzung der Suche (falls weitere, bisher nicht zurückgelieferte Elemente vorhanden sind). Fortsetzung der Suche: In das Feld nexttokens werden die Markierungen aus den Suchergebnissen für eine eventuelle Fortsetzung der Suche eingetragen. Falls die zuletzt durchgeführte Suche fortgeführt werden soll, muss dementsprechend der Entscheidungswert nextpage auf 'true' gesetzt werden Überarbeitete Komponenten Für den Zugri auf das Package cmgrid-aws (siehe Kapitel 3.1) innerhalb des Projekts mussten die folgenden Komponenten überarbeitet werden. Da in diesen Komponenten nur einige Bereiche für die Verwendung der AWS angepasst werden mussten, konnten somit die meisten Teile der vorhandenen Komponenten wiederverwendet werden PaiCapability Diese Komponente besteht aus der Klasse PaiCapability, die einen Web Service für den Empfang von Job-Anfragen für einen PAI-Knoten implementiert. Nachdem der Job Server den zu bearbeitenden Job an einen PAI-Knoten geschickt hat, 84

86 Zugri auf das Package cmgrid-aws kann dieser Knoten entscheiden, ob er diesen Job akzeptiert und somit durchführt, oder ob er diesen Job aus einem bestimmten Grund ablehnt. Der Grund hierfür ist entweder, dass der Knoten noch immer mit dem letzten Job beschäftigt ist oder dass das Abschaltsignal gesetzt wurde und der Knoten somit demnächst heruntergefahren wird. Falls der Job akzeptiert wird, wird eine Instanz der Unterklasse PAIRunner erstellt und ausgeführt, die den Job an die Komponente Crawler (siehe Kapitel ) übergibt und auf die Rückgabe dieser Komponente wartet. Die einzige Änderung in dieser Klasse für die Verwendung der AWS betraf die Überprüfung des Abschaltsignals, bevor ein Job letztendlich akzeptiert wird Crawler Diese Komponente besteht aus der Klasse Crawler, die dafür zuständig ist, sämtliche Dokumente aus einem Job auszulesen und den Archivierungsprozess für diese Dokumente zu beginnen. Zu diesem Zweck startet diese Klasse eine festgelegte Anzahl an Threads der Unterklasse WorkerRunnable, welchen die zu archivierenden Dokumente mit Hilfe eines Iterators übergeben werden. Die Unterklasse WorkerRunnable arbeitet mittels des übergebenen Iterators sämtliche Dokumente innerhalb des Threads ab und bringt diese in den Verarbeitungsprozess der Archivierung ein, indem die Dokumente einzeln an die Klasse DocumentIngestProcessor übergeben werden. In der Klasse DocumentIngestProcessor werden schlieÿlich nacheinander alle in den Eigenschaften dieses Jobs festgelegten Handler aufgerufen (siehe Kapitel und ), welche jeweils für eine bestimmte Aufgabe innerhalb des Archivierungsprozesses zuständig sind StorageServlet Diese Komponente besteht aus der Klasse StorageServlet, die ein Servlet für die verschiedenen Speichermöglichkeiten während des Archivierungsprozesses implementiert. Da in dieser Version des Projekts die Dokumente und Dokumentteile ausschlieÿlich in den AWS gespeichert werden, wurde diese Komponente gröÿtenteils nur insoweit verändert, um die anderen Komponenten nicht negativ zu beeinussen. 85

87 Konguration der Instanzen in der Cloud JobQueueServlet Diese Komponente besteht aus der Klasse JobQueueServlet, die ein Servlet implementiert, um neue Jobs in die Warteschlange für den Archivierungsprozess einzureihen. Bei der Erstellung der neuen Jobs werden sämtliche Parameter (wie Handler, Eigenschaften usw.) aus der Benutzeroberäche ausgelesen (siehe Kapitel ). Anschlieÿend werden die erstellten Jobs in die Warteschlange eingereiht und stehen für den zukünftigen Archivierungsprozess zur Verfügung RemoteServiceImpl Diese Komponente besteht aus der Klasse RemoteServiceImpl, die die im Projekt vorhandene Schnittstelle eines 'RemoteService' realisiert. Über diese Schnittstelle können Dokumente und Dokumentteile von entfernten Knoten abgefragt werden. Da in dieser Version des Projekts die Dokumente und Dokumentteile nicht auf den einzelnen Knoten, sondern zentral in den AWS vorliegen, wurde diese Komponente gröÿtenteils nur insoweit verändert, um die anderen Komponenten nicht negativ zu beeinussen SetupSearchServers Diese Komponente besteht aus der Klasse SetupSearchServers, die ein Servlet zur Verwaltung der Search Server innerhalb des Projekts implementiert. Da die Funktionalität der Search Server keine Priorität in dieser Arbeit aufweist, wurde diese Komponente gröÿtenteils nur rudimentär entwickelt, damit die anderen Komponenten nicht negativ beeinusst werden. 4.3 Konguration der Instanzen in der Cloud Amazon Machine Image (AMI) Das im Rahmen dieser Arbeit erstellte AMI basiert auf einem öentlichen AMI, das den Benutzern von Amazon EC2 von Rightscale zur Verfügung gestellt wurde (AMI Bezeichnung 'rightscale-us-east/centos_5.4_x64_v manifest.xml'). Auf diesem AMI wurde der Webserver 'Apache Tomcat' in der Version installiert. Diese Version wurde ausgewählt, um zum einen die Vergleichbarkeit zu wahren, da der bisherige Prototyp ebenfalls in dieser Version betrieben wurde. Zum anderen trat mit 86

88 Konguration der Instanzen in der Cloud der aktuelleren Version ein Fehler für den JSP:getProperty-Befehl auf. Die Nachforschungen zu dieser Version bestätigen diesen Fehler als bereits bekannten Bug (siehe Bug ), welcher im nächsten Release behoben werden sollte. In den Webserver wurden die Pakete 'cmgrid-service-war' (für die eigentliche Anwendungslogik des Prototypen) sowie 'cmgrid-ui' (für die Benutzeroberäche des Prototypen) in der jeweils aktuellen Version installiert. Darüber hinaus wurden die Komponenten für das Kommandozeilenwerkzeug 'awscmd' (siehe Kapitel 3.3.1) und für die Umgebungsintegration 'awsenvironment' (siehe Kapitel 4.4.2) auf dem AMI bereitgestellt Benutzerdaten Beim Start einer Instanz dieses AMI muss in den Benutzerdaten der Instanz der gewünschte Typ dieses Knotens (also entweder 'JobServer', 'SearchServer' oder 'PAI') angegeben werden. Für den Start eines PAI-Knotens müssen zusätzlich die lokalen IP- Adressen des zu verwendenden Job Servers und Search Servers übergeben werden, da innerhalb des AMI ein Netzlaufwerk mit diesen beiden Knoten eingerichtet wird. Dadurch können alle PAI-Knoten auf sämtliche Jobdateien zugreifen, die originär auf mehreren EBS-Laufwerken des Job Servers liegen. Die Verbindung mit dem Search Server erlaubt die Erstellung des Indexes auf einem Netzlaufwerk, dass vom Search Server betrieben wird. Benutzerdaten für den Start eines Job Servers: "NODETYPE=jobserver" Benutzerdaten für den Start eines Search Servers: "NODETYPE=searchserver" Benutzerdaten für den Start eines PAI-Knotens: "NODETYPE=pai&SEARCHSERVER=<localSearchServerIP>&JOBSERVER=<localJobServerIP>" Beispiel: "NODETYPE=pai&SEARCHSERVER= &JOBSERVER= " Skripte Auf dem AMI wurden zudem verschiedene Startskripte installiert, um die zu startende Instanz automatisch in die Umgebung zu integrieren. 1. Skript 'ec2userdata': Dieses Skript liest die Benutzerdaten ein, die beim Starten der Instanz übergeben wurden und schreibt diese Daten in ein eigenes Skript

89 Verwaltung der Instanzen in der Cloud 'user_data.sh', das zur Verwendung in allen weiteren Skripten eingebunden werden kann. 2. Skript 'startupnodetype': Dieses Skript bindet das zuvor erstellte Skript ein und verbindet abhängig vom gewählten Typ des Knotens die Laufwerke mit dieser Instanz: Für einen Job Server werden die vier EBS an die Instanz angehängt, welche die Jobdateien enthalten und die anschlieÿend als einzelnes Laufwerk für die Verwendung durch die PAI-Knoten gemountet werden. Für einen Search Server wird das Netzlaufwerk gemountet, das von allen PAI- Knoten zur Erstellung des Indexes verwendet werden kann. Für einen PAI-Knoten werden mit Hilfe der übergebenen lokalen IPs die Netzlaufwerke mit dem Job Server (für die Jobdateien) und dem Search Server (für den Index) verbunden. 3. Skript 'start_complete_environment': Zuletzt wird noch dieses Skript aufgerufen, das letztendlich den Apache Tomcat Webserver startet und die Umgebungsintegration 'awsenvironment' (siehe Kapitel 4.4.2) ausführt. 4.4 Verwaltung der Instanzen in der Cloud Web-basierende Benutzeroberäche Die Benutzeroberäche cmgrid-ui enthält zahlreiche JavaServer Pages (JSP), die auf den einzelnen Knoten (bzw. Instanzen) mit Hilfe des dort ausgeführten Webservers 'Apache Tomcat' erreichbar sind. In den JSP können Übersichten über momentan ablaufende Archivierungsprozesse und Statistiken zu bereits durchgeführten Vorgängen eingesehen werden. 88

90 Verwaltung der Instanzen in der Cloud Übersicht In der Übersicht werden allgemeine Informationen für diese Instanz angezeigt (siehe Abbildung 4.6). Abbildung 4.6: Übersicht in der Benutzeroberäche Die Auistung aller vorhandenen Knoten kann über den Link am oberen Rand der Seite abgerufen werden (siehe Abbildung 4.7). 89

91 Verwaltung der Instanzen in der Cloud Abbildung 4.7: Übersicht der Knoten in der Benutzeroberäche Status der AWS Auf dieser Seite kann der Status der verschiedenen AWS überwacht werden. Auf der ersten Seite werden nur generelle Informationen, wie die Auistung der vorhandenen Domains und MessageQueues sowie des verwendeten Buckets angezeigt (siehe Abbildung 4.8). Um nähere Informationen zu den einzelnen Bereichen zu erhalten, existiert jeweils ein Link am oberen Rand der Seite, über welchen Details zu den einzelnen AWS abgerufen werden können. 90

92 Verwaltung der Instanzen in der Cloud Abbildung 4.8: Status der AWS in der Benutzeroberäche Details zu den Domains: Auf dieser Seite wird eine vollständige Auistung der Domains angezeigt und zu jeder Domain die Anzahl der Elemente und Attribute sowie deren Einzelgröÿen und die aufsummierte Gesamtgröÿe (siehe Abbildung 4.9). Abbildung 4.9: Details zur SimpleDB in der Benutzeroberäche 91

93 Verwaltung der Instanzen in der Cloud Details zu den MessageQueues: Auf dieser Seite werden sämtliche MessageQueues sowie Details zu jeder MessageQueue wie Anzahl der vorhandenen (sichtbaren und unsichtbaren) Nachrichten und das Datum der Erstellung aufgelistet (siehe Abbildung 4.10). Abbildung 4.10: Details zu SQS in der Benutzeroberäche Details zu den Buckets: Auf dieser Seite wird die Anzahl an Objekten sowie deren Gesamtgröÿe in den verwendeten Buckets angezeigt (siehe Abbildung 4.11). Abbildung 4.11: Details zu S3 in der Benutzeroberäche 92

94 Verwaltung der Instanzen in der Cloud Aktivitäten der Knoten Diese Seite dient zur Überwachung der Aktivitäten der einzelnen Knoten, da der Status und der aktuell zu verarbeitende Job sowie einige Statistikangaben für jeden vorhandenen Knoten angezeigt werden (siehe Abbildung 4.12). Abbildung 4.12: Aktivitäten der Knoten in der Benutzeroberäche 93

95 Verwaltung der Instanzen in der Cloud Statistiken zu Jobs Auf dieser Seite können Statistiken über vollständige Job-Gruppen eingesehen werden, wobei die Jobs sowohl nach dem Zeitpunkt der Bereitstellung als auch nach den zugrundeliegenden Mandanten gruppiert werden (siehe Abbildung 4.13). Abbildung 4.13: Statistiken zu Jobs in der Benutzeroberäche 94

96 Verwaltung der Instanzen in der Cloud Warteschlange für Jobs Die Warteschlange für Jobs kann auf dieser Seite eingesehen werden, wobei die Jobs nach dem Zeitpunkt der Bereitstellung geordnet werden (siehe Abbildung 4.14). Abbildung 4.14: Warteschlange für Jobs in der Benutzeroberäche Um die beendeten Jobs aus der Warteschlange zu entfernen, steht die Schaltäche 'Remove Finished Jobs' zur Verfügung. Zudem können fehlerhafte Jobs mit Hilfe der Schalt- äche 'Reset Failed Jobs' zurückgesetzt werden, um sie nochmals auszuführen Bereitstellung von Jobs Mit Hilfe dieser Seite können neue Jobs bereitgestellt werden, wobei die gewünschte Jobdatei sowie die zu verwendenden Handler und Eigenschaften für die zu erstellenden Jobs ausgewählt werden können (siehe Abbildung 4.15). 95

97 Verwaltung der Instanzen in der Cloud Abbildung 4.15: Bereitstellung von Jobs in der Benutzeroberäche Diese Seite dient zur Einreihung neuer Jobs in die Warteschlange, wobei die folgenden Handler und Eigenschaften für die neuen Jobs festgelegt werden können: In der Auswahlliste 'Job Batch' kann die Jobdatei ausgewählt werden, die sämtliche einzureihenden Jobs enthält. Falls das Auswahlfeld 'Indexing using Lucene' markiert ist, wird Apache Lucene verwendet, um einen Index für die Volltextsuche in den archivierten Dokumenten zu erstellen. Im Eingabefeld 'Tenant ID' wird der Bezeichner des Mandanten eingetragen, der für diese Jobs verwendet werden soll. Im Bereich 'Use asynchronous upload' kann ausgewählt werden, ob für die Übertragung zu den AWS mehrere Threads verwendet werden sollen. Dementsprechend kann hier auch die maximale Anzahl an Threads und die Wartedauer für Threads 96

98 Verwaltung der Instanzen in der Cloud ('sleeptime', falls momentan bereits die maximale Anzahl an Threads läuft) angepasst werden. Das Auswahlfeld 'Create object index...' entscheidet, ob vor Beginn der Archivierung ein Index sämtlicher bereits archivierter Objekte angelegt werden soll. Im Bereich 'AWS DeDuplication' kann ausgewählt werden, welche Möglichkeiten für die Erkennung von Duplikaten verwendet werden sollen (siehe Kapitel ). Anschlieÿend werden die Jobs mit Hilfe der Schaltäche 'Just Add More Jobs' in die Warteschlange übertragen Suche in AWS Die Domains des Projekts (inkl. der Domains zur Dokumentenverwaltung) können auf dieser Seite durchsucht werden, indem Anfragen an die archivierten Metadaten gestellt werden (siehe Abbildung 4.16). Abbildung 4.16: Suche in AWS in der Benutzeroberäche Diese Seite dient vorwiegend der Suche nach archivierten Dokumenten in den Domains der Dokumentenverwaltung. Allerdings können auch sämtliche anderen Domains durch- 97

99 Verwaltung der Instanzen in der Cloud sucht werden. Die erste Zeile dieser Seite dient als (theoretische) Benutzeranmeldung, mit welcher der aktuelle Mandant identiziert werden soll. Da eine umfassende Benutzerverwaltung nicht Teil dieser Arbeit war, dient dieses Eingabefeld als einfachste mögliche Variante. Falls gewünscht, könnte stattdessen eine gesicherte Benutzeranmeldung verwendet werden, die alle weiteren Abfragen auf diesen angemeldeten Mandanten beschränkt. Nach Eingabe eines Mandantenbezeichners werden die auf dieser Seite durchgeführten Anfragen nur für diesen Mandanten durchgeführt und dementsprechend auch nur die Dokumente (oder Elemente) dieses Mandanten zurückgeliefert. Die Beschränkung auf den eingegebenen Mandanten wird allerdings nur für diejenigen Domains angewandt, in denen die Daten auch einem bestimmten Mandanten zugeordnet werden können (zum Beispiel für die Jobs und Domains zur Dokumentenverwaltung sowie die Abrechnungs- und Mandantendaten). In allen anderen Domains ist keine Beschränkung auf den eingetragenen Mandanten festgelegt. Zusätzlich existiert auf dieser Seite ein Auswahlfeld 'ignore tenants', mit dem die Beschränkung auf einen Mandanten auch für die beschränkten Domains aufgehoben werden kann. In das Eingabefeld 'select' werden die Attribute eingetragen, die von dieser Anfrage zurückgeliefert werden sollen (siehe Anfrageteil 'select' in Kapitel ). Darüber hinaus können in diesem Feld die folgenden Direktiven verwendet werden: Die Eingabe von * liefert alle vorhandenen Attribute zurück. Die Eingabe von count(*) liefert nur die Anzahl an gefundenen Elementen zurück. Die Eingabe von groupcount(...) in Verbindung mit einem beliebigen Attribut in der Klammer liefert eine gruppierte Liste für die Werte dieses Attributs und deren Anzahlen zurück. Zum Beispiel: Die Anfrage groupcount(farbe) würde als Ergebnis die Anzahlen der jeweiligen Farbe liefern (also Anzahl des Attributwertes 'blau': 5, Anzahl des Attributwertes 'rot': 12, usw.). In das Eingabefeld 'from' wird die zu durchsuchende Domain eingetragen oder alternativ das Auswahlfeld 'document domains' für die Suche in den Domains der Dokumentenverwaltung ausgewählt. In das Eingabefeld 'where' werden die Kriterien eingetragen, nach welchen in der jeweiligen Domain gesucht werden soll (siehe Anfrageteil 'where' in Kapitel ). Falls erforderlich, kann dieses Feld problemlos um weitere Angaben bezüglich der Sortierung (Anfrageteil 'order by') oder Limitierung (Anfrageteil 'limit') der Anfrage ergänzt werden. Des Weiteren können Optionen ein- oder ausgeblendet werden, indem auf einen der Links 'show details' oder 'hide details' geklickt wird. Diese Optionen beinhalten die Auswahl, 98

100 Verwaltung der Instanzen in der Cloud ob die Namen der Domains zur Dokumentenverwaltung in den Ergebnissen angezeigt werden sollen oder nicht. Zudem kann hier die Anzahl an zu verwendenden Threads für Anfragen an die Domains zur Dokumentenverwaltung festgelegt werden. Auch die maximale Länge der Attributwerte in den Ergebnissen kann in den Optionen eingetragen werden. Durch Anklicken der Schaltäche 'Search' wird die eingetragene Anfrage an die jeweilige Domain abgeschickt und die Ergebnisse werden im unteren Bereich der Seite aufgelistet. Falls die Suche nicht alle vorhandenen Elemente zurückgeliefert hat, erscheint unterhalb der Schaltäche 'Search' eine Meldung, dass weitere Elemente vorhanden sind. Die Suche kann dann fortgesetzt werden, indem das Auswahlfeld 'continue search' markiert bleibt und nochmals die Schaltäche 'Search' geklickt wird. Dadurch wird die zuvor durchgeführte Anfrage an der entsprechenden Stelle fortgeführt und die nächsten Elemente als Suchergebnis aufgelistet (dabei ist darauf zu achten, dass die Suche nur fortgeführt werden kann, wenn keiner der Suchparameter zwischenzeitlich geändert wurde). Um stattdessen eine neue Anfrage durchzuführen, muss einfach die Markierung aus dem Auswahlfeld 'continue search' entfernt werden Verwaltung der Knoten Die im Netzwerk vorhandenen Knoten können auf dieser Seite verwaltet werden, um die Knoten beispielsweise zu initialisieren, die Anzahl der Threads und Services auf den Knoten zu ändern oder den Dispatcher zur Verteilung der Jobs zu starten (siehe Abbildung 4.17). 99

101 Verwaltung der Instanzen in der Cloud Abbildung 4.17: Verwaltung der Knoten in der Benutzeroberäche Um einen PAI-Knoten für die Dokumentenarchivierung zu initialisieren, muss die lokale IP-Adresse des entsprechenden Knotens im Bereich 'Host initialization' ausgewählt und die Schaltäche 'initialize Host' geklickt werden. Falls der Knoten erfolgreich initialisiert werden konnte, wird eine Erfolgsmeldung zurückgegeben und der verfügbare Knoten erscheint im Bereich 'Service status'. Des Weiteren kann im Bereich 'Status display control' die Dauer des Intervalls für die Aktualisierung der Statusanzeige geändert sowie die Aktualisierung komplett gestoppt oder wieder gestartet werden. Im Bereich 'Service parameters' kann die Anzahl an Threads pro Service sowie die Anzahl an Services pro Knoten geändert werden. Im Bereich 'Dispatcher Control' kann der Dispatcher gestartet werden, der die in der Warteschlange bendlichen Jobs auf die zur Verfügung stehenden Knoten verteilt. 100

102 Verwaltung der Instanzen in der Cloud Umgebungsintegration Die letztendliche Umgebungsintegration eines Knotens erfolgt nach Anschluss sämtlicher Startskripte (siehe Kapitel 4.3.3), welche während des Starts einer neuen Instanz ausgeführt werden. Zuletzt wird die Umgebungsintegration 'awsenvironment' aufgerufen und der soeben gestartete Knotentyp als Parameter übergeben. Innerhalb dieser Umgebungsintegration wird der erhaltene Knotentyp zur Initialisierung an die Komponente EC2 (siehe Kapitel ) weitergeleitet. Die Komponente EC2 speichert den Knotentyp zusammen mit dem Status des Knotens und dem Bezeichner der Instanz (ID) in der Domain zur Knotenverwaltung (Domain 'cmgridnodes') ab. Der Knoten in dieser Domain wird hierbei über die lokale IP-Adresse identiziert, welche als Bezeichner des Elements verwendet wird. Die in dieser Domain vorhandenen Knoten werden in der Benutzeroberäche auf der Seite zur Verwaltung der Knoten angezeigt und können dort initialisiert werden, wodurch sie im laufenden Archivierungsprozess verwendet werden und somit erfolgreich integriert wurden. Für die Entfernung eines Knotens muss das sogenannte Abschaltsignal ('shutdown signal') in der Domain zur Knotenverwaltung (Domain 'cmgridnodes') für den entsprechenden Knoten gesetzt werden (siehe Kapitel ). Nach Abschluss eines Jobs überprüft jeder Knoten für sich selbst, ob für ihn dieses Abschaltsignal gesetzt wurde. Falls dies der Fall ist, nimmt der Knoten keine weiteren Jobs an und ruft die Shutdown- Methode auf, wodurch der Knoten letztendlich beendet wird. Das Setzen des Abschaltsignals kann mit dem Befehl cmgsendshutdown im Kommandozeilenwerkzeug erfolgen, wobei die lokale Adresse des Knotens anzugeben ist, für welche das Abschaltsignal gesetzt werden soll (siehe Kapitel ). 101

103 5 Simulation 5.1 Allgemeiner Ablauf der Dokumentenarchivierung Der Ablauf einer vollständigen Dokumentenarchivierung umfasst die folgenden Schritte: 1. Zu Beginn der Dokumentenarchivierung müssen sämtliche abzuarbeitenden Jobs in die Warteschlange für Jobs eingereiht werden. Dafür wird für jeden zu archivierenden Mandanten die gewünschte Jobdatei ausgewählt, welches sämtliche Jobs für diesen Mandanten beinhaltet (siehe Kapitel ). Zudem können hier für jeden Mandanten die Eigenschaften angegeben werden, die für diese Jobs gelten sollen (beispielsweise ob ein Lucene Index erstellt werden soll). Nachdem dieser Vorgang für jeden Mandanten ausgeführt wurde, stehen alle abzuarbeitenden Jobs in der Job-Domain und es existiert für jeden Mandanten eine eigene MessageQueue mit den Bezeichnern der jeweiligen Jobs des Mandanten. 2. Anschlieÿend müssen sämtliche Instanzen, die für die Archivierung verwendet werden sollen, gestartet werden. Dabei ist zu beachten, dass der Job Server und der Search Server zuerst gestartet werden müssen, da die lokalen IP-Adressen dieser Server für den Start der PAI-Knoten benötigt werden (siehe 4.3.2). 3. Nachdem alle Instanzen sämtliche Startskripte abgearbeitet haben (siehe 4.3.3), können die PAI-Knoten für die Dokumentenarchivierung initialisiert werden (siehe ). 4. Daraufhin kann der Dispatcher gestartet werden (siehe ), der für die Verteilung der eingereihten Jobs auf die verfügbaren PAI-Knoten zuständig ist. 5. Je nach Anzahl der gestarteten Instanzen und Anzahl der eingereihten Jobs dauert der Vorgang der Dokumentenarchivierung unterschiedlich lange. Der Fortschritt des Archivierungsprozesses kann auf den Seiten der Benutzeroberäche (siehe ) eingesehen werden. 6. Nachdem die Dokumentenarchivierung abgeschlossen ist, können die Statistiken zu diesem Vorgang auf den Seiten der Benutzeroberäche eingesehen werden (siehe ). 7. Mit Hilfe der Suchseite in der Benutzeroberäche kann nach beliebigen Dokumen- 102

104 Durchführung der Messreihen ten gesucht werden, die zuvor archiviert wurden (siehe ). Die Abfrage der Dokumente kann hierbei für jeden Mandanten getrennt erfolgen. 5.2 Durchführung der Messreihen Beschreibung Im folgenden Abschnitt wird die Durchführung der unterschiedlichen Messreihen beschrieben. Für jede Messreihe ist die Anzahl an verwendeten Instanzen (Anzahl der PAI- Knoten) sowie die Anzahl an Mandanten angegeben, die parallel archiviert werden sollen. Zur Durchführung der Messreihen steht ein Datensatz zur Verfügung, welcher einen Gesamtumfang von Jobs zu je 500 Dokumenten umfasst (insgesamt somit Dokumente). Die Dokumente des Datensatzes basieren dabei auf den s, welche im Mai 2002 von der Federal Energy Regulatory Commission (FERC) aufgrund des Enron Skandals veröentlicht wurden 1. Aufgrund der sicherlich groÿen, aber dennoch limitierten Menge an Dokumenten mussten in den Messreihen die vorhandenen Jobs mehrmals verwendet werden, um eine ausreichend groÿe Datenmenge zur Messung mehrerer Mandanten zu erhalten. Um ein realistisches Messergebnis zu erhalten, muss bei den Messreihen demzufolge die Duplikaterkennung ausgeschaltet werden, da die zu archivierenden Daten in den Datenspeichern (Amazon SimpleDB und Amazon S3) durch die mehrmalige Verwendung bereits vorhanden sein könnten. Zur Simulation eines realistischen Szenarios soll aber davon ausgegangen werden, dass für jeden Mandanten ein eigener Datensatz zur Verfügung steht und es zwischen den Mandanten realistischerweise zu keinen Überschneidungen kommt. Der normalerweise bei der Archivierung gegebenenfalls entstehende Geschwindigkeitsvorteil durch die Duplikaterkennung kann vernachlässigt werden, da in der Realität ein Dokument in den seltensten Fällen mehrmals archiviert wird Einzelne Messreihe als Bemessungsgrundlage Als Bemessungsgrundlage für die folgenden Messreihen wird zuerst eine einzelne Messreihe mit einem Mandanten und fünf PAI-Knoten durchgeführt, welche den Einuss der Apache Lucene Indizierung auf den Archivierungsprozess veranschaulichen soll (siehe Tabelle 5.1)

105 Durchführung der Messreihen Anzahl Anzahl Lucene Dauer in Dokumente Durchsatz Knoten Dokumente verwendet Minuten pro Sekunde pro Knoten ,6 14, ,4 13, lokal ,1 14, CFS ,0 1,2 Tabelle 5.1: Einzelne Messreihe mit einem Mandanten als Bemessungsgrundlage Aus dieser Messreihe ist ersichtlich, dass die lokal durchgeführte Indizierung mit Apache Lucene zu keinem nennenswerten Unterschied im Vergleich zur Durchführung ohne Indizierung führt. Falls die Indizierung hingegen nicht lokal, sondern auf dem Netzlaufwerk des Search Servers (CFS) erfolgt, erweist sich der Zugri auf dieses Netzlaufwerk als Engstelle, welche den Archivierungsprozess deutlich verlangsamt Messergebnisse Für die beiden Messreihen wird pro Mandant jeweils ein halber Datensatz ( Dokumente) verwendet und durchgehend eine lokale Indizierung mit Apache Lucene durchgeführt. Auf jedem PAI-Knoten läuft eine Instanz des Services, wobei dieser Service aus zwei parallelen Threads besteht. Ansonsten unterscheiden sich die Tests nur anhand der Anzahl an Mandanten sowie anhand der Anzahl an Instanzen Messreihe mit fester Anzahl an Instanzen Diese Messreihe wird mit einer festen Anzahl an 10 Instanzen (PAI-Knoten) und einer jeweils unterschiedlichen Anzahl an Mandanten durchgeführt. Anzahl Anzahl Dauer in Dokumente Durchsatz Mandanten Dokumente Minuten pro Sekunde pro Knoten ,5 38, ,6 39, ,4 42,1 Tabelle 5.2: Messreihe mit 10 Instanzen 104

106 Durchführung der Messreihen Diese Messergebnisse werden im Diagramm in Abbildung 5.1 veranschaulicht: Abbildung 5.1: Messreihe mit 10 Instanzen Messreihe mit fester Anzahl an Mandanten Diese Messreihe wird mit einer festen Anzahl an 10 Mandanten und einer jeweils unterschiedlichen Anzahl an Instanzen (PAI-Knoten) durchgeführt. Dabei ist zu beachten, dass keine Messung mit mehr als 18 Instanzen ausgeführt werden konnte, da maximal 20 Instanzen parallel gestartet werden können und der Job Server sowie der Search Server ebenfalls eine Instanz beanspruchen (siehe Amazon EC2 Beschränkungen in Kapitel ). Anzahl Anzahl Dauer in Dokumente Durchsatz Knoten Dokumente Minuten pro Sekunde pro Knoten ,6 22, ,8 32, ,6 39, ,6 20, ,9 23, ,5 20,0 Tabelle 5.3: Messreihe mit 10 Mandanten 105

107 Durchführung der Messreihen Diese Messergebnisse werden im Diagramm in Abbildung 5.2 veranschaulicht, wobei für die mehrmals durchgeführten Messungen Durchschnittswerte verwendet wurden: Abbildung 5.2: Messreihe mit 10 Mandanten Interpretation Aus der ersten Messreihe ist ersichtlich, dass für 10 Instanzen der Durchsatz eines einzelnen PAI-Knotens jeweils relativ konstant bei ca. 40 Dokumenten pro Sekunde bleibt. Die Gesamtdauer des Archivierungsprozesses erhöht sich proportional zur Anzahl an Mandanten (bzw. zur Anzahl an Dokumenten). Somit ergibt sich die Schlussfolgerung, dass das der Durchsatz eines PAI-Knotens von 40 Dokumenten pro Sekunde das Optimum für eine Testumgebung mit 10 Instanzen darstellt. Die zweite Messreihe hingegen zeigt, dass sich der Durchsatz mit der Anzahl der Instanzen ebenfalls erhöht, bis ein Optimum von ca. 10 Instanzen erreicht ist. Ab diesem Wert verringert sich der Durchsatz bei steigender Instanzzahl allerdings wieder. Des Weiteren fällt auf, dass sich der Gesamtdurchsatz aller PAI-Knoten nicht proportional zur Anzahl der Instanzen verhält, sondern sich bei der Verdopplung von 5 auf 10 Instanzen sogar verdreifacht, anschlieÿend aber auf diesem Niveau stagniert. Die Erhöhung der Anzahl an Instanzen führt ab einem Optimum von 10 Instanzen zu keinerlei Verbesserung des Gesamtdurchsatzes und demzufolge zu einer Verringerung des Durchsatzes der einzelnen PAI-Knoten. Daraus kann gefolgert werden, dass die Jobs nicht optimal auf die unbeschäftigten PAI-Knoten verteilt werden und die PAI-Knoten zu lange auf einen neuen Job warten müssen. In Anbetracht des möglichen Optimums aus der ersten Messreihe führt die zweite Messreihe zu der Interpretation, dass die Verteilung der Jobs nicht optimal auf die zur Verfügung 106

108 Kosten stehenden Ressourcen erfolgt. Sowohl das Abrufen der Jobs als auch das Aunden der momentan unbeschäftigten PAI-Knoten erweisen sich hier als verlangsamende Faktoren. Aus diesen Messreihen ergibt sich somit ein optimales Testsystem von 10 Instanzen für mindestens 10 Mandanten. Zusätzliche Mandanten haben keinen Einuss auf den Durchsatz dieses Systems, sondern erhöhen lediglich die Anzahl an Gesamtdokumenten und verlängern die Dauer des Gesamtvorgangs proportional zur Menge der Dokumente. 5.3 Kosten Die in diesem Kapitel durchgeführte Kostenrechnung basiert auf den jeweiligen Kapiteln über die Kosten der unterschiedlichen AWS (siehe Kapitel für Amazon SimpleDB, Kapitel für Amazon S3, Kapitel für Amazon EC2 und Kapitel für Amazon SQS) Kostenrechnung anhand eines allgemeinen Beispiels In diesem Abschnitt wird eine Kostenrechnung anhand eines einfachen allgemeinen Beispiels durchgeführt. Beispielsituation: In einem Unternehmen sind 100 Mitarbeiter (MA) beschäftigt, welche alle täglich mehrere s versenden. Jeder Mitarbeiter verschickt pro Stunde ca. 8 s und ist pro Werktag 8 Stunden im Unternehmen. Die Durchschnittsgröÿe einer beträgt 150 Kilobyte (KB). Dieses Unternehmen möchte nun den Prototypen verwenden, um die die gesetzliche Aufbewahrungsfrist von 3 Jahren für den elektronischen Datenverkehr einzuhalten. Beispielrechnung: Insgesamt fallen pro Tag 100 MA 8 Std. 8 s = s zur Archivierung an, was einem täglichen Volumen von s 150 KB = KB = 937, 5 MB 0, 92 GB entspricht. Das Gesamtvolumen über drei Jahre würde 937, 5 MB 5 Werktage 52 Wochen 3 Jahre = MB 714, 11 GB ergeben. 107

109 Kosten Kosten in Amazon S3: In Amazon S3 müssten ständig Daten der letzten 3 Jahre vorgehalten werden, was zu jährlichen Speicherkosten von 714, 11 GB 0, 15 $ pro GB und Monat 12 Monate = 1.285, 40 $ führen würde. Zusätzlich würde das täglich eingehende Volumen in Amazon S3 jährliche Kosten für den Datentransfer von 0, 92 GB 0, 10 $ pro GB 5 Werktage 52 Wochen = 23, 80 $ produzieren. Die Kosten für die Operationen zur Übertragung der Daten (0,01 $ pro put-operationen) würden pro Jahr zudem noch ergeben s 0, 01 $ 5 Werktage 52 Wochen = 16, 64 $ Op. Zusammengerechnet würden in Amazon S3 somit Gesamtkosten von verursacht , 40 $ + 23, 80 $ + 16, 64 $ = 1.325, 84 $ Kosten in Amazon SimpleDB: In der Amazon SimpleDB müssten die Metadaten der letzten 3 Jahre vorgehalten werden. Jede besitzt einen Bezeichner (ca. 32 Bytes) sowie 5 Attributwerte (jeweils ca. 40 Bytes), wodurch sich durchschnittlich 232 Bytes an Metadaten pro aufsummieren. Die 5 Attributnamen (jeweils ca. 40 Bytes) werden nur einmal für alle s gezählt und können vernachlässigt werden. Die Metadaten würden somit ein tägliches Volumen von s 232 Bytes = Bytes 1, 42 MB und ein Gesamtvolumen über drei Jahre von ergeben. 1, 42 MB 5 Werktage 52 Wochen 3 Jahre = 1.104, 49 MB 1, 08 GB Da das erste Gigabyte in Amazon SimpleDB umsonst ist, würde dies zu jährlichen Speicherkosten von 0, 08 GB 0, 14 $ pro GB und Monat 12 Monate = 0, 13 $ führen. Zusätzlich würde das täglich eingehende Volumen in Amazon SimpleDB jährliche Kosten für den Datentransfer von 1, 42 MB 0, 10 $ pro GB 5 Werktage 52 Wochen = 0, 04 $ 108

110 Kosten produzieren. Die Rechenleistung zur Übertragung der Metadaten wird in Maschinenstunden (MStd) pro Monat gerechnet. Mit der Abschätzung von durchschnittlich 0,00002 Maschinenstunden pro würde sich eine Rechenleistung pro Monat s 0, MStd 22 Werktage = 2, 82 MStd ergeben, welche keine Kosten verursacht, da die ersten 25 Maschinenstunden im Monat umsonst sind. Insgesamt würden in Amazon SimpleDB somit Gesamtkosten von verursacht. 0, 13 $ + 0, 04 $ = 0, 17 $ Kosten in Amazon EC2: Für die Archivierung der s würde eine Amazon EC2 Instanz, die durchschnittlich 30 s pro Sekunde archiviert, eine jährliche Betriebszeit von s 5 Werktage 52 Wochen 15, 41 Stunden 30 s pro Sek. benötigen. Diese Betriebszeit einer Amazon EC2 Instanz würde jährliche Kosten von produzieren. 15, 41 Stunden 0, 34 $ pro Stunde = 5, 24 $ Gesamtergebnis: Die Gesamtkosten des Unternehmens für die Archivierung der s würden sich somit auf 1.325, 84 $ für S3 + 0, 17 $ für SimpleDB + 5, 24 $ für EC2 = 1.331, 37 $ pro Jahr belaufen. Bei der Berechnung der Gesamtkosten fällt auf, dass die Kosten fast ausschlieÿlich nur aus den Speicherkosten in Amazon S3 bestehen. Die sonstigen Kosten sind im Vergleich zu diesen Speicherkosten äuÿerst gering und beeinussen die Gesamtkosten nur unerheblich Kostenrechnung am Beispiel der Messreihen In diesem Abschnitt wird die Kostenrechnung am Beispiel des optimalen Testsystems der Messreihen durchgeführt. 109

111 Kosten Situation: Die Universität betreibt einen Archivierungsservice, welcher aus dem vorhandenen Prototypen besteht, der auf 10 Instanzen für 4 Stunden pro Werktag (pro PAI-Knoten mit durchschnittlich 30 s pro Sekunde) ausgeführt wird. Jeder Mandant wird durch jeweils ein Unternehmen mit Mitarbeiter repräsentiert, von denen jeder Mitarbeiter pro Stunde ca. 8 s verschickt und pro Werktag 8 Stunden im Unternehmen ist. Die Durchschnittsgröÿe einer beträgt wiederum 150 KB. Die Universität möchte nun den Unternehmen die Verwendung des Prototypen anbieten, um die die gesetzliche Aufbewahrungsfrist von 3 Jahren für den elektronischen Datenverkehr einzuhalten. Rechnung: Insgesamt könnte der Service pro Werktag 10 Instanzen 30 s pro Sek. 60 Sek. 60 Min. 4 Std. = s archivieren, was einem täglichen Volumen von entspricht s 150 KB = KB 618, 0 GB Insgesamt fallen für einen einzelnen Mandanten pro Werktag MA 8 Std. 8 s = s zur Archivierung an, was einem täglichen Volumen von entspricht s 150 KB = KB 45, 8 GB Somit hätte der Service ausreichend Kapazitäten für s insgesamt 13 Mandanten s pro Mandant Pro Tag würden für alle 13 Mandanten somit s 13 Mandanten = s anfallen, das einem täglichen Gesamtvolumen von entspricht. 45, 8 GB 13 Mandanten = 595, 1 GB Das absolute Gesamtvolumen für alle 13 Mandanten über drei Jahre würde ergeben. 595, 1 GB 5 Werktage 52 Wochen 3 Jahre = 453, 3 TB 110

112 Kosten Kosten in Amazon S3: In Amazon S3 müssten ständig Daten der letzten 3 Jahre mit einem Volumen von 453,3 TB vorgehalten werden, was zu monatlichen Speicherkosten von führen würde. 50 TB 0, 15 $ pro GB und Monat (5.1) + 50 TB 0, 14 $ pro GB und Monat (5.2) + 353, 3 TB 0, 13 $ pro GB und Monat = , 41 $ (5.3) Zusätzlich würde das täglich eingehende Volumen in Amazon S3 monatliche Kosten für den Datentransfer von produzieren. 595, 1 GB 0, 10 $ pro GB 22 Werktage = 1.309, 20 $ Die Kosten für die Operationen zur Übertragung der Daten (0,01 $ pro put- Operationen) würden pro Monat zudem noch ergeben s 0, 01 $ 22 Werktage = 915, 20 $ Op. Zusammengerechnet würden in Amazon S3 somit Gesamtkosten von im Monat verursacht , 41 $ , 20 $ + 915, 20 $ = , 81 $ Kosten in Amazon SimpleDB: In der Amazon SimpleDB müssten die Metadaten der letzten 3 Jahre vorgehalten werden. Jede besitzt einen Bezeichner (ca. 32 Bytes) sowie 5 Attributwerte (jeweils ca. 40 Bytes), wodurch sich durchschnittlich 232 Bytes an Metadaten pro aufsummieren. Die 5 Attributnamen (jeweils ca. 40 Bytes) werden nur einmal für alle s gezählt und können vernachlässigt werden. Die Metadaten würden somit ein tägliches Volumen von s 232 Bytes = Bytes 920, 4 MB und ein Gesamtvolumen über drei Jahre von ergeben. 920, 4 MB 5 Werktage 52 Wochen 3 Jahre = MB 701, 1 GB 111

113 Kosten Da das erste Gigabyte in Amazon SimpleDB umsonst ist, würde dies zu monatlichen Speicherkosten von 700, 1 GB 0, 14 $ pro GB und Monat = 98, 01 $ führen. Zusätzlich würde das täglich eingehende Volumen in Amazon SimpleDB monatliche Kosten für den Datentransfer von 920, 4 MB 0, 10 $ pro GB 22 Werktage = 1, 98 $ produzieren. Die Rechenleistung zur Übertragung der Metadaten wird in Maschinenstunden (MStd) pro Monat gerechnet. Mit der Abschätzung von durchschnittlich 0,00002 Maschinenstunden pro würde sich eine Rechenleistung pro Monat s 0, MStd 22 Werktage = 1.830, 40 MStd ergeben, was zu monatlichen Kosten (abzüglich der kostenlosen ersten 25 Maschinenstunden im Monat) von führen würde , 40 MStd 0, 14 $ pro MStd = 252, 76 $ Insgesamt würden in Amazon SimpleDB somit Gesamtkosten von im Monat verursacht. 98, 01 $ + 1, 98 $ + 252, 76 $ = 352, 75 $ Kosten in Amazon EC2: Die 10 Instanzen des Archivierungsservices sind 4 Stunden pro Werktag in Betrieb und würden somit monatliche Kosten von 10 Instanzen 4 Stunden 0, 34 $ pro Stunde 22 Werktage = 299, 20 $ produzieren. Gesamtergebnis: Die Gesamtkosten der Universität für den Betrieb des Archivierungsservice würden sich somit auf , 81 $ für S , 75 $ für SimpleDB + 299, 20 $ für EC2 = , 76 $ pro Monat belaufen. Zudem würden noch Kosten für diejenigen Domains anfallen, welche keine Mandantendaten, sondern nur Betriebsdaten des Prototyps (wie beispielsweise die Abrechnungsdaten) enthalten. Da diese Kostenkomponente der Amazon SimpleDB allerdings im Vergleich 112

114 Kosten zu den Kosten für Amazon S3 verschwindend gering wäre, können diese Kosten vernachlässigt werden. Die berechneten laufenden Kosten könnten auf die 13 Mandanten umgelegt werden, wodurch jedem Mandanten monatliche Kosten von , 76 $ 13 Mandanten = 4.981, 14 $ für die Archivierung seines gesamten elektronischen Datenverkehrs entstehen würden. 113

115 6 Zusammenfassung 6.1 Ergebnisse der Diplomarbeit Als Ergebnis dieser Diplomarbeit habe ich festgestellt, dass sich die Amazon Web Services ausgesprochen gut für die Verwendung innerhalb des vorhandenen Prototyps eignen, da sich der ständig ändernde Bedarf an das Leistungsvermögen der Dokumentenarchivierung durch die Flexibilität der AWS ausgleicht. Insbesondere die innerhalb von wenigen Minuten verfügbare Skalierung der AWS (beispielsweise aufgrund unvorhergesehener zusätzlicher Anforderungen) stellt einen herausragenden Vorteil gegenüber lokalen Netzwerklösungen dar, welche nur verbunden mit groÿen Investitionen im Voraus und mit wesentlich mehr Zeitaufwand einen zuvor nicht eingerechneten Bedarf bewältigen können. Bei den durchgeführten Messreihen erwies sich die Übertragung der Dokumente in Amazon S3 als der ausschlaggebende Faktor für den Durchsatz der PAI-Knoten, da diese Übertragung den Groÿteil der Verarbeitungszeit eines einzelnen Dokuments in Anspruch nahm. Eine mögliche Optimierung des Zugris auf Amazon S3 könnte dementsprechend eine deutliche Steigerung des Leistungsvermögens zur Folge haben. Beispielsweise könnte ein eigener Threadpool für die Abarbeitung der Speichervorgänge des gesamten PAI-Knotens eingesetzt werden, der sich die zu speichernden Objekte aus einer Queue holt und auf mehrere Threads verteilt parallel abspeichert. Die vorhandene Lösung realisiert diese Möglichkeit ansatzweise, verwendet allerdings einen eigenen Threadpool für jeden Archivierungsprozess des PAI-Knotens. Ein auf dem gesamten Knoten einheitlicher Threadpool könnte diese Aufgabe möglicherweise ezienter lösen. Die dargestellten Kostenrechnungen führen zu der Schlussfolgerung, dass die Gesamtkosten der Archivierungslösung fast ausschlieÿlich aus den Speicherkosten der Dokumente in Amazon S3 bestehen. Aufgrund der groÿen Datenvolumens sind sämtliche anderen Kostenkomponenten im Vergleich zu diesen Speicherkosten verschwindend gering und können (beinahe) vernachlässigt werden. Eine Möglichkeit zur Reduzierung dieser Kosten wäre die Verwendung eines alternativen, kostengünstigeren Langzeitspeichers, um die Daten der letzten Jahre vorzuhalten. Ansonsten sind die Kosten für den Betrieb der Dokumentenarchivierung mit Hilfe der AWS angemessen und können aufgrund der Mandantenfähigkeit der vorhandenen Archivierungslösung auf mehrere Mandanten verteilt werden. 114

116 Ausblick 6.2 Ausblick In diesem Kapitel wird ein Ausblick auf mögliche Fortsetzungen zu dieser Diplomarbeit gegeben, wobei beispielsweise zusätzliche Amazon Web Services, welche erst im Verlaufe dieser Arbeit von Amazon entwickelt und angeboten wurden, in den Prototyp integriert werden könnten Weitere Verwendung von AWS im Projekt Amazon SimpleDB Während des Verlaufs dieser Diplomarbeit wurden für den Service Amazon SimpleDB neue Funktionen entwickelt, die dem Benutzer eine konsistente Leseoperation sowie bedingte Schreib- und Löschoperationen zur Verfügung stellen [8]. Eine der neuen Funktionen bietet dem Benutzer der Amazon SimpleDB die Möglichkeit, zwischen einer konsistenten Leseoperation ('consistent read') oder einer nur eventuell konsistenten Leseoperation ('eventually consistent read') auszuwählen. Dadurch kann der Benutzer exibel wählen, ob die jeweilige Anwendung eher Anforderungen an die Geschwindigkeit (bezüglich Latenz und Durchsatz) oder an die Konsistenz der Daten stellt. Des Weiteren können verlorene Schreiboperationen aufgrund konkurrierender Schreibzugrie ('lost update') mit Hilfe der bedingten Schreiboperation ('conditional put') verhindert werden, da die Schreiboperation hierbei nur durchgeführt wird, falls der aktuelle Wert einem bestimmten Erwartungswert entspricht. Dementsprechend wird die bedingte Löschoperation ('conditional delete') ebenfalls nur durchgeführt, falls der aktuelle Wert des zu löschenden Objekts einem bestimmten Erwartungswert entspricht. Diese neuen Funktionen könnten im vorhandenen Prototyp verwendet werden, um beispielsweise das Problem der Generierung von neuen Bezeichnern zu lösen. Der aktuelle Bezeichner könnte für die weitere Generierung in einer Domain gespeichert werden. Zur Vergabe neuer Bezeichner müsste dieser Wert abgerufen, erhöht und mit Hilfe der bedingten Schreiboperation wieder zurück in die Domain geschrieben werden. Nur unter der Bedingung, dass diese Schreiboperation erfolgreich war und der Wert somit nicht bereits von einem anderen Prozess überschrieben wurde, darf der neue Bezeichner schlieÿlich verwendet werden Amazon Relational Database Service (Amazon RDS) Seit Beginn dieser Diplomarbeit hat Amazon die Plattform der AWS um weitere zusätzliche Web Services wie beispielsweise den Amazon Relational Database Service (Amazon 115

117 Ausblick RDS) erweitert. Dieser Service bietet dem Benutzer die Möglichkeit, eine relationale Datenbank als einfachen und skalierenden Web Service in der Cloud zu verwenden. Dabei stehen sämtliche Leistungsmerkmale einer gebräuchlichen MySQL Datenbank zur Verfügung, wodurch bestehende Anwendungen ohne groÿen Aufwand auf die Verwendung dieses Services umgestellt werden können. Im vorhandenen Prototyp trat zwischenzeitlich das Problem auf, dass der Web Service Amazon SimpleDB keine komplexen Datenbankoperationen wie beispielsweise den Verbund von Tabellen bzw. Domains zur Verfügung stellt. Dieses Problem könnte mit dem neuen Web Service Amazon RDS gelöst werden, ohne weitreichende Änderungen innerhalb des Prototyps vornehmen zu müssen, da in der früheren Version des Prototyps bereits SQL-Anfragen zu einer lokal vorhandenen Datenbank vorhanden waren Amazon CloudWatch Der Web Service Amazon CloudWatch bietet die Möglichkeit, systemnahe Metriken wie die Auslastung des Prozessors oder die Anzahl der Schreib- und Lesezugrie auf die lokalen Festplatten sowie den ein- und ausgehenden Netzwerkverkehr der Instanzen in der Cloud zu erfassen. Dieser Web Service könnte in Kombination mit dem Web Service Auto Scaling in den vorhandenen Prototyp eingebettet werden, um beispielsweise einen Load Balancing Automatismus zu realisieren (siehe Kapitel ) Auto Scaling Im Web Service Auto Scaling können die in Amazon CloudWatch erfassten Metriken verwendet werden, um die Anzahl an Instanzen in der Cloud zu regulieren, falls bestimmte, vom Benutzer festgelegte Bedingungen erfüllt werden. Dieser Web Service könnte in Kombination mit dem Web Service Amazon CloudWatch in den vorhandenen Prototyp eingebettet werden, um beispielsweise einen Load Balancing Automatismus zu realisieren (siehe Kapitel ) Mögliche Fortsetzungen zu dieser Arbeit Load Balancing per Auto Scaling and CloudWatch Eine denkbare Fortsetzung dieser Arbeit wäre die Entwicklung eines möglichst intelligenten Automatismus, welcher sowohl auf Grundlage der momentanen Verarbeitungsgeschwindigkeit als auch mit dem Vorwissen der kommenden Aufgaben eine automatische 116

118 Ausblick Auf- und Abwärts-Skalierung der Instanzen in der Cloud durchführt (das sogenannte 'Load Balancing'). Als erster Ansatz könnten zu diesem Zweck die AWS Amazon CloudWatch und Auto Scaling in Betracht gezogen werden, welche die Anzahl an Instanzen auf Grundlage der erfassten Metriken regulieren, falls bestimmte Bedingungen erfüllt werden. Eine solche Bedingung wäre beispielsweise die Erhöhung der Anzahl an Instanzen in der Cloud, falls die durchschnittliche Prozessorauslastung für einen Zeitraum von über 10 Minuten über 80 % liegt. Dementsprechend könnte die Anzahl an Instanzen verringert werden, falls die durchschnittliche Prozessorauslastung wiederum unter 20 % fällt. Die Instanzen in der Cloud sowie die Web Services Amazon CloudWatch und Auto Scaling bilden hierbei einen Regelkreis, dessen Regelung allerdings vorwiegend nur reaktiv und ohne jegliches Vorwissen über die kommenden Aufgaben abläuft (siehe Regelkreis 1 in Abbildung 6.1). Abbildung 6.1: Load Balancing per Auto Scaling and CloudWatch Dieser Ansatz könnte noch erweitert werden, indem man die Kennzahlen sowie das Vorwissen der Komponente SchedulerLayer (dem sogenannten Scheduler) verwendet, um einen zweiten Regelkreis in den Archivierungsprozess einzuführen. Dabei werden die vorhandenen Kennzahlen wie der Gesamtdurchsatz an Dokumenten pro Sekunde (bzw. pro Mandant oder pro PAI-Knoten) sowie das Vorwissen über die zu erwartende Anzahl 117