Bedarfsgerechte Auswahl der Dienstqualität für - EPub Bayreuth

Bedarfsgerechte Auswahl der Dienstqualität für - EPub Bayreuth

Bedarfsgerechte Auswahl der Dienstqualit¨ at fu ¨ r Mobile Cloud-unterstu ¨ tzte Anwendungen Von der Universit¨at Bayreuth zur Erlangung des Grades ei...

11MB Sizes 0 Downloads 3 Views

Recommend Documents

Jahresbericht - EPub Bayreuth - Uni-Bayreuth
2011/2012 weitere 18 Gruppenarbeitsräume anbieten zu können. Zu verdanken hat ..... Zusatzmagazin. GSP. 10.00 – ....

Daniel Alexander Kunz - EPub Bayreuth - Uni-Bayreuth
11.04.2014 - Daniel Alexander Kunz ...... xer als der durch die Lennard-Jones Kraft beschriebene. .... unterschied ∆m

Chikas Danfulani - EPub Bayreuth
24.04.2012 - of women's lives with a few exceptions such as the works of Umar (2004), whose work ... madrassa schools (s

1 einleitung - EPub Bayreuth
14.04.2003 - Anopheles gambiae. ATc. Anhydrotetracyclin. BSA bovine serum albumin, Rinderserumalbumin. D. melanogaster D

Das System der Verbalstämme in der arabischen - EPub Bayreuth
04.07.2006 - Liste der verwendeten Transkriptionszeichen . ...... Lautwerte werden die entsprechenden Umschriftzeichen d

Das Bild der Stadt im Musiktheater - EPub Bayreuth
26.05.2016 - Liedern122 finden sich Stereotypen, die insbesondere für Komödien essentiell sind. ...... Bernado Buontalen

Polarmodifikation von Butadienkautschuk mit - EPub Bayreuth
H. L. Hsieh und R. P. Quirk: Anionic Polymerization-Principles and Practical Applications; .... HPLC-Modus und die Signa

Konformationsänderungen im katalytischen Zyklus - EPub Bayreuth
Bindungspuffer Nickel 50 mM Tris/HCl, 500 mM NaCl (bzw. ...... (Eggeling et al., 2001). Die in dieser Arbeit gewonnenen

Maßgeschneiderte Schichtsilicate für - EPub Bayreuth - Uni-Bayreuth
21.10.2010 - Brydges, W. T.; Gulati, S. T.; Baum, G. Permeability of Glass Ribbon-reinforced ...... [56] E.Ferrage, B.La

Multimedial unterstütztes Lernen: Intrinsische - EPub Bayreuth
28.07.2009 - Dr. Franz X. Bogner bin ich sehr dankbar für die Betreuung ... Josef Scharfenberg half mir so oft und stet

Bedarfsgerechte Auswahl der Dienstqualit¨ at fu ¨ r Mobile Cloud-unterstu ¨ tzte Anwendungen Von der Universit¨at Bayreuth zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigte Abhandlung

von

Marvin Ferber aus Werdau

1. Gutachter : Prof. Dr. Thomas Rauber 2. Gutachter : Prof. Dr. Stefan Jablonski Tag der Einreichung : 27. 05. 2014 Tag des Kolloquiums : 06. 08. 2014

Danksagung Ich danke meinem Doktorvater Prof. Dr. Thomas Rauber f¨ ur die langj¨ahrige Unterst¨ utzung und die M¨ oglichkeit meinen eigenen wissenschaftlichen Stil zu entwickeln und meinen Forschungsinteressen nachzugehen. Ich danke meinen Kollegen am Lehrstuhl f¨ ur Angewandte Informatik 2 der Universit¨at Bayreuth f¨ ur fruchtbare Diskussionen und Anregungen, aber auch f¨ ur berechtigte Kritik. Außerdem m¨ochte ich mich auch bei allen anderen Wegbegleitern bedanken, mit deren Hilfe Forschungsideen sich in Implementierungen und abschließend in Publikationen transformiert haben. Hierf¨ ur m¨ochte ich insbesondere Dr. Sascha Hunold und Mario Henrique Cruz Torres danken. Weiterhin m¨ochte ich auch den Studenten danken, die im Rahmen von HiWi-T¨atigkeiten und Abschlussarbeiten Ergebnisse erzielten, die zum Entstehen dieser Arbeit beigetragen haben. Ich danke zudem meinen Eltern Ute und Mathias sowie meinem Bruder Henning ganz herzlich, da sie mich von Anfang an motiviert und unterst¨ utzt haben, damit ich diese Arbeit beginnen und abschließen kann. Danken m¨ochte ich ebenso Bettina f¨ ur ihr ge¨ ubtes Auge bei der Suche nach Schreibfehlern. Erw¨ahnt werden sollen auch die unz¨ ahligen Freunde, die mich in den letzten Jahren nach Kr¨aften unterst¨ utzt haben. Vielen Dank! Besonderer Dank gilt meiner Frau, ohne deren umfangreiches Hintergrundengagement“ ” und deren Motivationsarbeit diese Arbeit wohl nicht so entstanden w¨are. Danke Anne!

Kurzfassung Mobilger¨ ate wie Smartphones, Tablets und kleine Laptops finden immer gr¨oßere Verbreitung. Dadurch w¨ achst auch der Bedarf an mobil genutzten Applikationen. Aufgrund der zugunsten der Batterielaufzeit eingeschr¨ ankten Ressourcen k¨onnen jedoch berechnungsintensive Anwendungen auf diesen Mobilger¨ aten nur schwer realisiert werden. Eine m¨ogliche L¨osung ist die Anwendung von Cloud-Ressourcen zur zeitlich begrenzten Unterst¨ utzung solcher Applikationen. Cloud Computing hat sich in letzter Zeit immer mehr etabliert und meint unter anderem das Mieten von Rechnern auf feingranularer zeitlicher Basis nach dem Selbstbedienungsprinzip (Infrastructure as a Service (IaaS)). Darauf aufbauende Plattform-Dienste (Platform as a Service (PaaS)) f¨ uhren Programmcode der Applikationen (Software as a Service (SaaS)) aus. Bei SaaS handelt es sich um eine Art Software, die zeitlich flexibel via Internet genutzt wird. In der Literatur vorgestellte Ans¨atze zur Anwendung von Cloud Computing zur Unterst¨ utzung mobiler Applikationen lassen jedoch h¨aufig die f¨ ur Cloud-Ressourcen anfallenden Kosten außer Acht und beachten die teils stark schwankende mobile Netzwerkperformance nicht. Ziel dieser Arbeit ist darum die Erforschung von Techniken zur bedarfsgerechten Bereitstellung von Compute-Ressourcen f¨ ur mobil genutzte Anwendungen unter Beachtung situationsbezogener Eigenschaften. Es wird eine Middleware f¨ ur Java vorgestellt, die auf der PaaS-Schicht angesiedelt ist und die die Cloud-unterst¨ utzte Ausf¨ uhrung mobiler Anwendungen via Code-Offloading erm¨ oglicht. Dabei wird vormals lokal ausgef¨ uhrter Programmcode zur Laufzeit zu einem Server u uhrt. Im Gegensatz zu ¨bertragen und anschließend dort ausgef¨ anderen Middlewares ist es hier m¨ oglich, die Qualit¨at der zu verwendenden Cloud-Ressource zur Laufzeit auszuw¨ ahlen. Dazu ist es notwendig, die verf¨ ugbare Netzwerkperformance und die erwartete Ausf¨ uhrungszeit der mobilen Applikation zu prognostizieren. Zun¨achst wird die Netzwerkperformance von 3G-Mobilfunk und WLAN untersucht. Danach wird ein Pipeliningbasiertes Kommunikationsprotokoll erarbeitet, welches die Gesamtperformance und die Vorhersagbarkeit der erreichbaren Daten¨ ubertragungsrate verbessert. Zur Laufzeitprognose werden durch Regressionsanalyse Applikationsprofile erstellt, die auf Monitoring-Daten basieren, ¨ die die Middleware f¨ ur jede Anwendung sammelt. Uber die API der Middleware kann dann in Abh¨angigkeit situationsbezogener Parameter (Netzwerkperformance und Eingabedaten) eine bedarfsgerechte Auswahl an Cloud-Ressourcen pr¨asentiert werden. Da nicht f¨ ur jede Anwendung Applikationsprofile erstellt werden k¨onnen, wird eine Kategorisierung mobiler Anwendungen in taugliche und untaugliche Applikationstypen erarbeitet. Da die Middleware auf IaaS-Ressourcen eines Cloud-Anbieters basiert, werden Lastbalancierungsstrategien analysiert, die eine optimale Auslastung der Ressourcen bei gleichzeitig konstanter Performance f¨ ur alle Nutzer garantieren. Hierf¨ ur werden Simulationen zum Verhalten der Strategien auf einer IaaS-Cloud durchgef¨ uhrt. Die Evaluation der prototypischen Implementierung der Middleware und insbesondere der G¨ ute der vorhergesagten Performance wird anhand realer Applikationen durchgef¨ uhrt. Dazu wird die Raytracing-Funktionalit¨at zur Erstellung fotorealistischer Bilder einer 3D-Hausdesignsoftware und eine Applikation zur fortlaufenden Kamerabildverarbeitung auf Smartphones genutzt. Die erzielten Ergebnisse unter Benutzung von WLAN und 3G-Netzwerken zeigen, dass eine sinnvolle Auswahl passender Ressourcentypen zur Laufzeit nicht nur m¨ oglich, sondern auch wichtig ist, um f¨ ur den Nutzer unn¨otige Kosten aufgrund unzureichend ausgelasteter Cloud-Ressourcen zu vermeiden.

Abstract Mobile devices such as Smartphones and Tablets are becoming more and more popular. As a result, the need for mobile applications also grows. Because of the limited resources of such battery-powered devices, compute-intensive applications can hardly be executed on them. One solution to overcome this restriction is the time-limited use of cloud resources to assist mobile applications on demand. Cloud Computing has emerged in the past years. It includes the rental of compute resources on a fine-grained timely basis using self-service. This is known as Infrastructure-as-a-Service (IaaS). On top of this, a Platform-as-a-Service (PaaS) is set up that hosts the application code of Software-as-a-Service (SaaS). SaaS is a kind of software that is used via Internet and that is billed on a timely flexible model, e.g., the pay-per-use model. The use of Cloud Computing to assist mobile applications has been proposed in the literature already. However, the cost for cloud usage and the influence of the current mobile network performance are often not discussed. Consequently, this work aims at the provision of cloud resources to assist mobile applications in accordance with the current Quality of Service (QoS) demands of the user. To achieve this goal, the performance of 3G and WLAN network connections is studied in a first step. Based on the results, a novel communication protocol is developed, which uses pipelining. This protocol achieves a better overall communication performance and a better predictability of the throughput in contrast to widely used protocols such as HTTP. Furthermore, a middleware for Java is presented, which supports the execution of cloud-assisted mobile applications. The middleware is located at the PaaS layer. Code-Offloading is used to execute formerly locally executed program code on a remote server. This requires to transfer and install program code to the server at runtime. The middleware manages a pool of cloud resources from an IaaS provider. Thus, load-balancing and strategies for reuse are analysed in order to maximize resource usage while assuring a constant performance for each user. This analysis is done via simulation, which is based on parameters from an existing cloud environment. It is possible to select the quality of the underlying resources for a cloud-assisted mobile application at runtime. To facilitate the decision, a runtime prediction of the expected performance is done for available cloud resources. The prediction is based on monitoring data collected by the middleware for each application. A profile is created for each application using regression analysis. A common API is used to calculate cloud options at runtime in accordance with the current network performance and current input data. Applications are categorized in order to identify suitable applications that can be equipped with such a runtime prediction. The quality of the prediction is evaluated using real applications. A software for ray tracing of photo-realistic images of a 3D home designer and a software for streaming image processing of camera pictures on an Android device are used. Results show that a reasonable selection of resource types can be presented at runtime using 3G and WLAN mobile network configurations. Moreover, it is necessary to review the available options carefully in order to avoid monetary overhead for the user, which may be caused by inefficiently utilized cloud resources.

Inhaltsverzeichnis Abbildungsverzeichnis

v

Tabellenverzeichnis

vii

Abk¨ urzungsverzeichnis

ix

1 Einleitung 1.1 Begriffliche Grundlagen . . . . . . . 1.1.1 Internet und Technologien . . 1.1.2 Cloud Computing . . . . . . 1.1.3 Mobile Cloud Computing . . 1.1.4 Quality of Service . . . . . . 1.1.5 Mobile Kommunikationsnetze 1.2 Problemstellung und Zielsetzung . . 1.3 Aufbau der Arbeit . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

1 4 4 5 8 9 9 10 13

2 Verwandte Arbeiten 2.1 MCC-Anwendungen und deren Charakteristik . . . . . . . . . . . . 2.1.1 Bildverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Mobile Gaming . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Desktop Anwendungen . . . . . . . . . . . . . . . . . . . . . 2.1.4 Zusammenfassung Anwendungscharakteristik . . . . . . . . 2.2 Realisierung von Mobile (Cloud) Computing Anwendungen . . . . 2.2.1 Verfahren ohne explizite Anpassung des Programmcodes . . 2.2.2 Verfahren mit expliziter Client/Server Programmierung . . 2.2.3 Zusammenfassung Realisierung von MCC-Anwendungen . 2.3 MCC aus Sicht der Cloud-Infrastruktur . . . . . . . . . . . . . . . 2.3.1 MCC-Architekturen . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Eigenschaften von Diensten auf Cloud-Infrastrukturschicht 2.3.3 Lastbalancierung und Skalierungsmethoden . . . . . . . . . 2.3.4 Cloud-QoS und Monitoring . . . . . . . . . . . . . . . . . . 2.3.5 Zusammenfassung MCC-Infrastruktur . . . . . . . . . . . . 2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

16 16 16 17 17 17 19 19 20 21 22 22 23 25 27 28 28

3 Modell f¨ ur Mobile Server-unterst¨ utzte Anwendungen 3.1 Mobile Server-unterst¨ utzte Anwendungen . . . . . 3.1.1 Abstrakte generische Anwendung . . . . . . 3.1.2 Server-unterst¨ utzte Anwendung . . . . . . . 3.2 Mobile Cloud-unterst¨ utzte Anwendungen . . . . . 3.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

30 30 30 33 34 35

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . .

i

Inhaltsverzeichnis

4 Verbindungen in 3G und WLAN Netzwerken 4.1 Aufbau mobiler Kommunikationsnetze . . . . . . . . . . . . 4.1.1 WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Eigenschaften kabelloser TCP-Verbindungen . . . . . . . . . 4.2.1 Analyse der Grundperformance . . . . . . . . . . . . 4.2.2 Verschl¨ usselungsverfahren . . . . . . . . . . . . . . . 4.2.3 Duplexf¨ ahigkeit . . . . . . . . . . . . . . . . . . . . . 4.2.4 Protokolle und Codierung auf Anwendungsschicht . 4.2.5 Zusammenfassung Grundperformance . . . . . . . . 4.3 Wiederverwendung von TCP-Verbindungen und Pipelining 4.3.1 Voraussetzungen und Modellierung von Pipelining . 4.3.2 Pipelining-Implementierungen . . . . . . . . . . . . . 4.3.3 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . 4.4 Performancevorhersage in Alltagssituationen . . . . . . . . . 4.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

37 39 40 42 45 45 49 54 57 61 61 62 63 66 67 70

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien 5.1 Erh¨ ohung der Granularit¨ at . . . . . . . . . . . . . . . . . . . . 5.2 Authentifizierung, Abrechnung und Lebenszyklus . . . . . . . . 5.2.1 Einzelner Front-Server . . . . . . . . . . . . . . . . . . . 5.2.2 Mehrere Front-Server . . . . . . . . . . . . . . . . . . . 5.2.3 Broker-Server und Compute-Serverfarm . . . . . . . . . 5.2.4 Lebenszyklus einer Client-Anfrage . . . . . . . . . . . . 5.3 Cloud-Ressourcen Startup/Shutdown-Zeiten . . . . . . . . . . . 5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters . 5.4.1 Simulationsmodell . . . . . . . . . . . . . . . . . . . . . 5.4.2 Ressourcenallokationsstrategie . . . . . . . . . . . . . . 5.4.3 Generierung von Simulationseingaben . . . . . . . . . . 5.4.4 Implementierung des Simulators . . . . . . . . . . . . . 5.4.5 Simulationsergebnisse . . . . . . . . . . . . . . . . . . . 5.4.6 Daten¨ ubertragungskosten . . . . . . . . . . . . . . . . . 5.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

72 73 75 76 77 78 80 82 83 84 86 87 90 92 94 95

. . . . . . . . . Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

96 96 97 99 99 101 103 104 105 107 108 109 110

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit 6.1 Auswahlstrategien . . . . . . . . . . . . . . . . . . . . 6.1.1 Klassifikation von Mobilen Cloud-unterst¨ utzten 6.1.2 Laufzeitprognose von Tasks . . . . . . . . . . . 6.1.3 Auswahl einer geeigneten Ressource . . . . . . 6.2 Regressionsanalyse zur Laufzeiterfassung . . . . . . . . 6.2.1 Voraussetzungen . . . . . . . . . . . . . . . . . 6.2.2 Durchf¨ uhrung einer einfachen Regression . . . 6.2.3 Durchf¨ uhrung einer multiplen Regression . . . 6.2.4 Fehlerbehandlung . . . . . . . . . . . . . . . . . 6.2.5 Vorhersagetauglichkeit . . . . . . . . . . . . . . 6.2.6 Toolunterst¨ utzung . . . . . . . . . . . . . . . . 6.2.7 Zusammenfassung Regressionsanalyse . . . . .

ii

. . . . . . . . . . . . . . .

Inhaltsverzeichnis

6.3

. . . . . . . . .

110 111 112 112 117 117 118 120 121

. . . . . . . . . . . . .

123 124 126 127 132 132 133 133 133 139 141 144 145 147

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen 8.1 Synthetische Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Bereitstellungszeit von VM-Ressourcen und Code-Offloading . . . . . 8.1.2 Laufzeitvorhersage f¨ ur synthetische benutzerterminierte Applikationen 8.1.3 Laufzeitvorhersage f¨ ur synthetische eingabeterminierte Applikationen . 8.1.4 Zusammenfassung synthetische Applikationen . . . . . . . . . . . . . . 8.2 Raytracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Rechenzeitbedarf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Hauptspeicherbedarf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 Konstruktion der Laufzeitfunktion zur Vorhersage . . . . . . . . . . . 8.2.5 Bewertung der Auswahlstrategie . . . . . . . . . . . . . . . . . . . . . 8.3 Mobile Streaming-Bildverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Rechenzeitbedarf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Konstruktion der Laufzeitfunktion zur Vorhersage . . . . . . . . . . . 8.3.4 Bewertung der Auswahlstrategie . . . . . . . . . . . . . . . . . . . . . 8.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149 149 149 151 154 155 155 156 159 160 160 165 166 167 168 169 170 173

6.4

6.5

Cloud-Performance Modellierung und Bewertung . . . . . . . . . . 6.3.1 Performance-Rating . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Speicheranforderungen . . . . . . . . . . . . . . . . . . . . . 6.3.3 Volatilit¨ at der Performance virtueller Maschinen . . . . . . Java-spezifische Einflussparameter auf die Ausf¨ uhrungsperformance 6.4.1 Classloader . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Just-In-Time Compiler . . . . . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

7 Middleware-Implementierung f¨ ur Java 7.1 Middleware-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Netzwerk-APIs der Komponenten . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Abrechnung/Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 Compute-Ressource (VM) . . . . . . . . . . . . . . . . . . . . . . 7.3 Implementierung der Middleware-Komponenten . . . . . . . . . . . . . . 7.3.1 Implementierung der Taskverarbeitung . . . . . . . . . . . . . . . 7.3.2 Code-Installation zur Laufzeit . . . . . . . . . . . . . . . . . . . . 7.3.3 Implementierung von Applikationen auf Basis des Task Konzepts 7.3.4 Debugging und Analyse von Cloud-unterst¨ utzten Applikationen . 7.3.5 Installation/Deployment von Applikationsprofilen . . . . . . . . . 7.3.6 Bestimmung von Cloud-Optionen auf Clientseite . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . .

9 Zusammenfassung 175 9.1 Zusammenfassung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 175 9.2 Erstellungsleitfaden f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen . . . . . . . 176

iii

Inhaltsverzeichnis

9.3

Ausblick und weiterf¨ uhrende Arbeiten . . . . . . . . . . . . . . . . . . . . . . 178

Literaturverzeichnis

180

¨ A Ubersicht u ate ¨ber die verwendeten Rechner und Mobilger¨

192

B Eigenschaften von Diensten ausgew¨ ahlter IaaS Anbieter

193

C Simulationsergebnisse der Ressourcenallokationsstrategien

199

D WSDL Interface der externen Broker API

202

E Beispielszenen der Testapplikation Raytracing

205

iv

Abbildungsverzeichnis 1.1

Schichteneinteilung von Cloud-Diensten . . . . . . . . . . . . . . . . . . . . .

7

3.1

¨ Uberblick Mobile Cloud-unterst¨ utzte Anwendungen und Code Offloading . .

31

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

OSI/ISO und korrespondierendes TCP/IP-Schichtenmodell . . . . . . . . . Beispiel einer Ende-zu-Ende Verbindung im TCP/IP-Schichtenmodell . . . Konfigurationen verbreiteter WLAN Infrastrukturen . . . . . . . . . . . . . Konfiguration einer 3G Infrastruktur (UMTS Mobilfunknetz) . . . . . . . . Kommunikationsperformance Dell Streak 7 Tablet . . . . . . . . . . . . . . Kommunikationsperformance SONY Xperia P Smartphone . . . . . . . . . Performanceschwankung mobiler Kommunikationsverbindungen . . . . . . . Mobile Kommunikationsperformance mit und ohne Verschl¨ usselung . . . . . Dauer des TCP-Verbindungsaufbaus mit und ohne Verschl¨ usselung . . . . . Geschwindigkeiten mobiler Kommunikationstechnologien im Duplexbetrieb Vergleich von Pipelining mit Request/Response Kommunikation . . . . . . Schematische Darstellung der SPDY Protokoll Frames . . . . . . . . . . . . Schematische Darstellung der Pipelining Frames . . . . . . . . . . . . . . . Performancevergleich Pipelining-f¨ahiger Kommunikationsprotokolle . . . . . ¨ Vorhergesagte und erreichte Ubertragungsgeschwindigkeiten im Vergleich .

. . . . . . . . . . . . . . .

38 38 40 43 46 46 48 52 52 55 62 65 66 67 68

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

Anfrageverteilung auf dedizierte und wiederverwendbare VM-Instanzen . . Allokationsvorgang f¨ ur eine VM-Instanz mit einem einzelnen Front-Server . Allokationsvorgang auf einer Architektur mit mehreren Front-Servern . . . Allokationsvorgang auf einer Architektur mit Broker-Server . . . . . . . . . Illustration des Lebenszyklus einer Client-Anfrage (Sequenzdiagramm) . . . Durchschnittliche Startup-Zeiten von Amazon EC2 VM-Ressourcen . . . . Schematische Visualisierung des Ablaufs einer Simulation. . . . . . . . . . . Visualisierung verschiedener Anfrageverteilungen und Simulationsergebnisse Anfrageverteilung und Simulationsergebnis f¨ ur 100000 Anfragen . . . . . . . Ann¨ aherung einer Folge von Simulationen . . . . . . . . . . . . . . . . . . . Ungenutzte VM-Laufzeit (Kostenoverhead) . . . . . . . . . . . . . . . . . . Zeitlicher Allokationsoverhead f¨ ur VM-Instanzen . . . . . . . . . . . . . . . Daten¨ ubertragungskosten im Vergleich zu gesamten Cloud-Nutzungskosten.

. . . . . . . . . . . . .

74 78 78 79 81 82 85 88 89 91 93 93 94

6.1 6.2 6.3 6.4 6.5 6.6

Beispiel einer Regressionsanalyse . . . . . . . . . . . . . . . . . . . . . . . Schematische Darstellung des Ablaufs einer Regressionsanalyse . . . . . . Streuung des Vorhersagebereichs f¨ ur verschiedene VM-Typen . . . . . . . Softwarestack f¨ ur Java-Programme unter Verwendung von VM-Instanzen Ausf¨ uhrungszeiten einer Sequenz von gleichen Tasks in einer JVM . . . . Histogramm einzelner Tasklaufzeiten f¨ ur eine Kantenerkennung in Bildern

. . . . . .

102 103 108 113 117 119

. . . . . .

v

Abbildungsverzeichnis

vi

7.1 7.2 7.3 7.4 7.5 7.6

Illustration der Middleware-Komponenten und deren Interaktion. . . . . . . . 124 Screenshot des Programms zur Bestimmung der verf¨ ugbaren Netzwerkbandbreite131 UML-Diagramm der verf¨ ugbaren Softwarepakete und deren wichtigste Klassen 134 UML-Klassendiagramm zur Verwendung der wichtigsten Klassen . . . . . . . 135 Visualisierung der Taskverarbeitung auf dem Client . . . . . . . . . . . . . . . 137 Visualisierung der Taskverarbeitung auf der VM . . . . . . . . . . . . . . . . 138

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17

Allokationszeiten f¨ ur VM-Instanzen unter Verwendung der Middleware . . . . 150 Screenshot des 3D-Hausdesigners Sweethome 3D . . . . . . . . . . . . . . . . 156 Sequenzdiagramm des Ablaufs eines Renderings . . . . . . . . . . . . . . . . . 157 Laufzeiten f¨ ur das Rendering auf Mobilger¨aten und VM-Instanzen im Vergleich 159 CPU-Auslastung auf verschiedenen VM-Typen w¨ahrend des Renderings . . . 159 Approximation der Gr¨ oße eines PNG-Bildes. . . . . . . . . . . . . . . . . . . 161 Approximation der Initialisierungszeit der Szene f¨ ur das Rendering auf der VM 161 Korrelationen der Renderingzeit zu verschiedenen Eingabegr¨oßen . . . . . . . 163 Approximation der Renderingzeit auf verschiedenen VM-Typen . . . . . . . . 164 Auswahldialog zur Bestimmung von Cloud-Optionen f¨ ur das Rendering . . . 165 Zusammensetzung der Gesamausf¨ uhrungszeit f¨ ur das Rendering . . . . . . . . 166 Abbildung der Streaming-Bildverarbeitungsapplikation f¨ ur Android . . . . . . 167 Verarbeitungsraten f¨ ur Bildverarbeitungstasks der Streaming-Bildverarbeitung 168 H¨aufigkeitsverteilung verschiedener Tasklaufzeiten f¨ ur Bildverarbeitungstasks 170 Regressionsanalyse f¨ ur den Kantenerkennungs- und den Gesichtserkennungstask171 Auswahldialog zur Bestimmung von Cloud-Optionen f¨ ur Bildverarbeitungstasks172 G¨ ute der vorhergesagten Bildverarbeitungsraten f¨ ur die Bildverarbeitungstasks 173

Tabellenverzeichnis 1.1

Kategorisierung und Eigenschaften mobiler Endger¨ate . . . . . . . . . . . . .

2

2.1

Eigenschaften verschiedener Frameworks f¨ ur Mobile (Cloud) Computing . . .

18

3.1

Modell zur Beschreibung der Ausf¨ uhrungszeit von Computerprogrammen . .

32

4.1 4.2 4.3

Konfigurationen der untersuchten mobilen Kommunikationstechnologien . . . Gemessene Eigenschaften verschiedener mobiler Kommunikationstechnologien Nachrichtengr¨ oßen verschiedenen Typs in verschiedenen Codierungen . . . . .

41 42 61

5.1 5.2

Beschreibung des Modells zur Simulation der Allokationsstrategien f¨ ur VMs . VM-Bedarf f¨ ur verschiedene Allokationsstrategien (gleichzeitig aktive VMs) .

84 92

6.1 6.2 6.3

Kategorisierung von Tasks in 9 Kategorien nach deren Eigenschaften . . . . . 98 Auswertung von Benchmarks auf Cloud-Ressourcen . . . . . . . . . . . . . . . 114 Performancevergleich verschiedener JVM (64-bit) . . . . . . . . . . . . . . . . 116

7.1

Kategorisierung der API-Methoden der Middleware-Komponenten . . . . . . 125

8.1 8.2 8.3 8.4 8.5 8.6

Laufzeit elementarer Tasks in ms . . . . . . . . . . . . . . . . . . . . . . . . . Abweichung der Vorhersage f¨ ur synth. benutzerterminierte Applikationen 1 . Abweichung der Vorhersage f¨ ur synth. benutzerterminierte Applikationen 2 . Abweichung der Vorhersage f¨ ur synthetische eingabeterminierte Applikationen G¨ ute der Sch¨ atzung f¨ ur verschiedene VM-Typen und Netzwerke . . . . . . . Charakteristiken von Bildverarbeitungstasks f¨ ur Streaming-Bildverarbeitung .

A.1 Verwendete Rechner und Mobilger¨ate B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12

150 152 153 154 165 168

. . . . . . . . . . . . . . . . . . . . . . 192

Liste verf¨ ugbarer Instanztypen von Rackspace Cloud Servers in London (UK) Daten¨ ubertragungskosten von Rackspace Cloud Servers in London (UK) . . . Liste verf¨ ugbarer Amazon EC2 Instanztypen in EU Irland (Auszug) . . . . . Daten¨ ubertragungskosten von Amazon EC2 in EU Irland . . . . . . . . . . . Lister verf¨ ugbarer Instanztypen von GoGrid . . . . . . . . . . . . . . . . . . . Daten¨ ubertragungskosten von GoGrid . . . . . . . . . . . . . . . . . . . . . . Liste verf¨ ugbarer Instanztypen von Windows Azure in Europa . . . . . . . . . Daten¨ ubertragungskosten von Windows Azure in Europa (Nord und West) . Liste verf¨ ugbarer Instanztypen von Google Compute Engine in Europa . . . . Daten¨ ubertragungskosten von Google Compute Engine . . . . . . . . . . . . . Lister verf¨ ugbarer Konfigurationsm¨oglichkeiten von Elastic Hosts . . . . . . . Matrix verf¨ ugbarer Instanztypen von Flexiscale . . . . . . . . . . . . . . . . .

193 193 194 194 195 195 196 196 196 197 197 198

vii

viii

Abku ¨rzungsverzeichnis 3G

Mobilfunkstandard der 3. Generation

3GPP

3rd Generation Partnership Project

4G

Mobilfunkstandard der 4. Generation

ALU

Arithmetic Logic Unit

AMI

Amazon Machine Image

AP

Accesspoint (WLAN)

API

Application Programming Interface

AR

Augmented Reality

ARM

Acorn Risc Machine (Computerprozessor)

AWS

Amazon Web Services

CORBA

Common Object Request Broker Architecture

CPU

Central Processing Unit

CSMA/CA

Carrier Sense Multiple Access / Collision Avoidance

DSL

Digital Subscriber Line

EC2

Elastic Compute Cloud

ECU

Elastic Compute Unit

FDD

Frequency Division Duplex

FPU

Floating Point Unit

FPS

Frames per Second

GC

Garbage Collector, Garbage Collection

GSM

Global System for Mobile Communications

HSDPA

High Speed Downlink Packet Access

HSPA

High Speed Packet Access

HSUPA

High Speed Uplink Packet Access

HTML

Hypertext Markup Language

HTTP

Hypertext Transfer Protocol

IaaS

Infrastructure-as-a-Service

IDL

Interface Definition Language

I/O

Input / Output

JIT-Compiler Just-in-Time-Compiler JMS

Java Message Service

JDK

Java Development Kit

ix

Abk¨ urzungsverzeichnis

JRE

Java Runtime Environment

JSON

Javascript Object Notation

JVM

Java Virtual Machine

LTE

Long Term Evolution

MAC

Media Access Control

MAC

Message Authentication Code

MCC

Mobile Cloud Computing

MSS

Maximum Segment Size

MTU

Maximum Transfer Unit

OS

Operating System

PaaS

Platform-as-a-Service

QoS

Quality of Service

REST

Representational State Transfer

RFC

Request for Comments

RMI

Remote Method Invocation (Java)

RPC

Remote Procedure Call

RTT

Round Trip Time

SaaS

Software-as-a-Service

SASL

Simple Authentication and Security Layer

SLA

Service-Level Agreement

SOA

Service-Oriented Architecture

SOAP

Simple Object Access Protocol

SSH

Secure Shell

SSL/TLS

Secure Socket Layer / Transport Layer Security

TDD

Time Division Duplex

TCP/IP

Transmission Control Protocol / Internet Protocol

UML

Unified Modeling Language

UMTS

Universal Mobile Telecommunications System

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

VLAN

Virtual Local Area Network

VM

Virtuelle Maschine

WAR

Web Application Archive

WCDMA

Wideband Code Division Multiple Access

WLAN

Wireless Local Area Network

WSDL

Web Service Description Language

XML

Extensible Markup Language

x

1 Einleitung Die Verwendung mobiler Endger¨ ate zur Nutzung von Internet-Angeboten hat in den letzten Jahren stark zugenommen und es wird erwartet, dass dieser Trend anh¨alt1 . Zu mobilen Endger¨aten geh¨ oren unter anderem Internet-f¨ahige Mobiltelefone, sogenannte Smartphones, deren Absatz sich von 2010 zu 2011 um rund 61% auf u oht ¨ber 490 Mio. verkaufte Ger¨ate erh¨ hat [Int12]. Seit 2010 werden außerdem Tablet-PCs mit großem Touchscreen immer beliebter. Auch kleine Laptops mit Tastatur und ohne Touchscreen, wie etwa Netbooks, k¨onnen zu den mobilen Ger¨ aten gez¨ ahlt werden. Diese mobilen Endger¨ate erlauben durch mobile Daten¨ ubertragung unterwegs die Nutzung von vormals station¨ar genutzten Programmen, wie etwa Webbrowser. Zus¨ atzlich bieten diese Ger¨ate auch Software mit ausschließlich mobilem Einsatzzweck, etwa Fußg¨ angernavigation, an. Schl¨ usseltechnologien der mobilen Kommunikation sind in diesem Zusammenhang die Mobilfunkstandards der dritten Generation (3G) wie UMTS sowie WLAN Standards f¨ ur den r¨aumlich begrenzten Einsatz, beispielsweise im B¨ uro oder zu Hause. Im 4. Quartal 2011 gab es bereits u ¨ber 1 Mrd. Mobilfunkteilnehmer in 3G Netzen weltweit [MW12]. Die zunehmend mobile Nutzung von Anwendungen stellt jedoch neue Herausforderungen an die Entwicklung von Software. Dies betrifft unter anderem die Anpassung an eine ber¨ uhrungssensitive Touchoberfl¨ache und die Ber¨ ucksichtigung des ausschließlich kabellosen Netzwerkzugangs. Da mobile Ger¨ate im Gegensatz zu station¨aren PCs nur begrenzte Speicher- und Verarbeitungsf¨ahigkeiten haben, ist die Verwendung von entfernten Funktionen via Internet eine Alternative [KL10]. Ziel ist die Optimierung mobiler Ressourcen wie Akkulaufzeit und Speichernutzung sowie die schnellere Ausf¨ uhrung ressourcenintensiver Applikationen. Hierbei haben sich vor allem Dienste zur Online-Speicherung von Daten, wie etwa DropBox 2 oder Microsoft SkyDrive 3 , etabliert [Sos10]. Aber auch Funktionen wie B¨ uroprogramme und Online-Spiele werden immer st¨arker genutzt. Im Folgenden werden diese Art Applikationen unter dem Begriff Mobile Server-unterst¨ utzte Anwendungen zusammengefasst. Mobile Server-unterst¨ utzte Anwendungen werden da genutzt, wo mobile Kommunikationsger¨ ate genutzt werden, beispielsweise zu Hause, im B¨ uro oder im Urlaub. Mobile Endger¨ ate und station¨ are PCs oder Laptops unterscheiden sich in vielen Eigenschaften. Tabelle 1.1 fasst g¨ angige Eigenschaften verschiedener mobiler Endger¨ate zusammen. Die Mehrheit der Mobilger¨ ate nutzt heutzutage stromsparende Prozessoren auf ARMBasis [For12]. ARM-Prozessoren sind im Bereich eingebetteter Systeme sehr beliebt und daher 1

Der Anteil mobil aufgerufener Webseiten ist seit Anfang 2009 stetig gestiegen und erreichte im Dezember 2013 ca. 22%. Dabei ist der Anstieg im Vergleich zum Vorjahresmonat mit ca. 58% erheblich. (siehe Onlineressource http://gs.statcounter.com/ (abgerufen am 24.3.2014)) 2 Dropbox ist ein kostenloser Service, mit dem Sie Ihre Fotos, Dokumente und Videos u ¨berall dabeihaben ” und leicht mit anderen teilen k¨ onnen. Das Unternehmen wurde 2007 von den beiden MIT-Studenten Drew Houston und Arash Ferdowsi gegr¨ undet, die genug davon hatten, sich Dateien per E-Mail zuzusenden, nur damit sie auf mehreren Computern damit arbeiten konnten.“ (Onlineressource http://www.dropbox.com/ about (abgerufen am 1.11.2013)) 3 SkyDrive ist ein kostenloser Onlinespeicher f¨ ur Dateien, auf den Sie von beliebigen Ger¨ aten aus zugreifen ” k¨ onnen. [...] Mit SkyDrive k¨ onnen Sie von u ¨berall auf Ihre Fotos, Dokumente und anderen wichtigen Dateien zugreifen.“ (Onlineressource http://windows.microsoft.com/de-at/skydrive/download(abgerufen am 1.11.2013))

1

1 Einleitung

Tabelle 1.1: Kategorisierung und Eigenschaften mobiler Endger¨ate∗ Smartphone

Tablet

Netbook

Laptop/Desktop

3-5”

7-10”

10-13”

14-24”

800x480

1024x600

1366x768

1920x1080

CPU

1 Kern ARM

2 Kerne ARM

2 Kerne x86

4 Kerne x86

RAM

512 MB

1 GB

2 GB

4 GB

2 GB

8 GB

320 GB

500 GB

Displaygr¨ oße Displayaufl¨ osung

Persistenter Speicher Betriebssysteme

Android/iOS/Windows Phone/etc.

Linux/MacOS/Windows/etc.

Eingabemethode

Touchscreen

Tastatur und Mouse/Touchpad/Trackpoint

* = H¨ aufigste Werte ermittelt aus den auf www.geizhals.at am 8. M¨ arz 2013 in der Europ¨ aischen Union gelisteten Produkten in der jeweiligen Kategorie.

eher von geringem Energieverbrauch als von hoher Verarbeitungsgeschwindigkeit gepr¨agt. There are a number of physical features that have driven the ARM processor design. ” First, portable embedded systems require some form of battery power. The ARM processor has been specifically designed to be small to reduce power consumption and extend battery operation-essential for applications such as mobile phones and personal digital assistants (PDAs).“[SSW04, S.5] Außerdem haben mobile Ger¨ ate oft eine F¨ ulle von integrierten Sensoren wie beispielsweise Kamera, GPS, H¨ ohenmesser oder Beschleunigungssensor, was f¨ ur Laptops und station¨are PCs un¨ ublich ist. Station¨ are PCs haben neben einer h¨oheren Verarbeitungsgeschwindigkeit oft auch eine großz¨ ugigere Ausstattung mit Arbeitsspeicher und persistentem Speicher (Festplatte, etc.). Bez¨ uglich Display-Aufl¨ osung haben die Mobilger¨ate stark aufgeholt, wobei viele Smartphones und Tablets aufgrund der geringen Baugr¨oße dennoch eher kleinere Aufl¨osungen haben als die meisten station¨ aren PCs und Laptops. Um die Eigenschaften mobiler Ger¨ate besser zu unterst¨ utzen, wurden spezielle Betriebssysteme f¨ ur diese Ger¨ate entwickelt, beispielsweise iOS und Android [BK11]. Kann man auf einem Laptop u ¨blicherweise verschiedene Betriebssysteme und Anwendungen beliebiger Art installieren, so ist bei Mobilger¨aten oftmals mit dem Kauf des Ger¨ ats die darin verwendete Software-Plattform festgelegt. Dies a¨ußert sich einerseits darin, dass der Entwickler durch einfache Schnittstellen unterst¨ utzt wird und dem Anwender eine reichhaltige Anwendungsauswahl pr¨asentiert werden kann. Andererseits ist die Interoperabilit¨ at niedriger, man spricht von Vendor Lock-in 4 . Da solche mobilen Ger¨ ate die Nutzung des Internets zum Datenaustausch essenziell vorsehen, werden sogenannte App-Stores verwendet, um Applikationen direkt von dort herunterzuladen und zu installieren. Andere Arten der Installation, etwa via CD oder Diskette, sind hier nicht mehr vorgesehen. Verschiedene Internet-Dienste, die besonders mit der starken Verbreitung mobiler Endger¨ate an Bedeutung gewonnen haben, wie etwa Youtube oder Dropbox , profitieren von einer 4

2

Vendor lock-in, or just lock-in, is the situation in which customers are dependent on a single manufacturer ” or supplier for some product (i.e., a good or service), or products, and cannot move to another vendor without substantial costs and/or inconvenience.“ (Onlineressource http://www.linfo.org/vendor_lockin. html(abgerufen am 1.11.2013))

neuen Art der Bereitstellung von Server-Ressourcen, die nach dem pay-per-use Modell f¨ ur jedermann im Internet nutzbar ist. Dieses Konzept erlaubt es beispielsweise, Server-Maschinen auf Stundenbasis zu mieten und zu bezahlen. Man spricht bei diesem Konzept von Cloud Computing oder Utility Computing. Cloud Computing Technologien haben den Server-Markt gegen¨ uber traditionellen Rechenzentren stark flexibilisiert. In traditionellen Rechenzentren k¨onnen Server auf Monatsbasis gemietet werden. Man kann dort u ¨blicherweise vorkonfektionierte Betriebssysteme der Rechenzentrumsbetreiber nutzen oder ein angepasstes System selbst installieren. Cloud-Betreiber bieten heute Rechnerressourcen, Plattformen und Applikationen auf feingranularer Basis zur Miete an. Dies gilt vor allem f¨ ur die Konfigurationsm¨oglichkeiten und die feingranulare Abrechnung. Beliebige Betriebssysteme k¨onnen binnen weniger Minuten auf konfigurierbarer Serverhardware aufgesetzt und in Betrieb genommen werden. Diese flexible und schnelle Konfigurierbarkeit und Nutzbarkeit von Ressourcen hat ganz neue Arten von Applikationen hervorgebracht, die ohne solche Cloud-Technologie nur schwer realisierbar w¨ aren. Hierzu z¨ahlen beispielsweise Multicast-Videoanwendungen oder soziale Netzwerke, die immer mehr Multimedia-Inhalte verkn¨ upfen und aufbereiten. Dabei versuchen Cloud-Anbieter, durch bessere Auslastung der Hardware die Kosten zu reduzieren.

Eine Schl¨ usseltechnologie in diesem Zusammenhang ist die Virtualisierung von Ressourcen, welche es erlaubt, mehrere virtuelle Betriebssysteme auf einer physikalischen Maschine auszuf¨ uhren. Dadurch kann beispielsweise ein System mit 4 CPU-Kernen mit einem leichtgewichtigen Hostbetriebssystem ausgestattet werden, auf dem dann zwei Instanzen virtueller Maschinen mit je 2 CPU-Kernen und einer Partition des verf¨ ugbaren Arbeitsspeichers ausgef¨ uhrt werden. Die virtuellen Maschinen k¨onnen dabei verschiedene andere Betriebssysteme beherbergen. Durch Virtualisierung erh¨oht sich auch die Energieffizienz der Serverlandschaft, was zu einem weiteren positiven Effekt von Cloud Computing f¨ uhrt. Aufgrund dieser positiven Eigenschaften versuchen Entwickler, Cloud-Technologie gewinnbringend in ihre Applikationen und Dienste einzubauen.

Kombiniert man Cloud Computing mit der Nutzung von mobilen Endger¨aten, so spricht man von Mobile Cloud Computing (MCC). Solche Anwendungen lagern berechnungsintensive Teile/Module der Applikation auf entfernte Server aus. Dies wird h¨aufig als Client/Server Partitionierung bezeichnet. Dadurch k¨onnen Limitierungen bez¨ uglich Hauptspeicherbedarf, CPU-Leistung oder Speicherkapazit¨at mobiler Endger¨ate umgangen werden. Aber auch die Steigerung der Akkulaufzeit und die Verbesserung der Zuverl¨assigkeit mobiler Anwendungen sind Ziele des MCC [DLNW11]. Diese Arbeit untersucht, wie rechenintensive Anwendungen durch Cloud-Unterst¨ utzung f¨ ur mobile Endger¨ate besser nutzbar gemacht werden k¨onnen. Dazu wird der Begriff Mobile Cloud-unterst¨ utzte Anwendungen eingef¨ uhrt und deren Eigenschaften und Modellierungsm¨ oglichkeiten werden untersucht. Die Erstellung dieser Arbeit ist dabei ein Prozess, der u ¨ber ca. drei Jahre andauerte. W¨ahrend der Bearbeitung der einzelnen Fragestellungen in den Jahren 2011 bis 2014 wurden von Unternehmen und Forschergruppen teils neuere Technologien und Ergebnisse bekannt, die in dieser Arbeit nicht mehr umf¨anglich ber¨ ucksichtigt werden konnten. Auf einige dieser Ergebnisse und deren Bedeutung f¨ ur die vorliegende Arbeit geht das Abschlusskapitel ein. Zun¨achst werden im nachfolgenden Kapitel wichtige Begriffe erl¨ autert und anschließend die Problemstellung und Struktur der Arbeit vorgestellt.

3

1 Einleitung

1.1 Begriffliche Grundlagen Dieser Abschnitt f¨ uhrt einige grundlegende Begriff ein, die f¨ ur diese Arbeit bedeutsam sind. In dieser Arbeit sind wichtige Eigennamen, Firmennamen und Technologien kursiv dargestellt. Abk¨ urzungen werden bei ihrer ersten Verwendung eingef¨ uhrt und gegebenenfalls kurz erl¨autert. Sie k¨ onnen zudem im Abk¨ urzungsverzeichnis nachgeschlagen werden.

1.1.1 Internet und Technologien Das Internet, welches aus verschiedenen Forschungsnetzwerken wie dem ARPANET hervorging, basiert auf einer Reihe von Netzwerkprotokollen, die in den 1970er Jahren entwickelt wurden [HL08]. Dieser TCP/IP-Protokollstapel besteht aus Protokollen, die in Schichten organisiert sind und aufeinander aufbauen. Wichtige Protokolle sind in diesem Zusammenhang das Internet Protocol (IP), welches jedem Netzwerkger¨at eine Adresse zuweist und das Transmission Control Protocol (TCP), welches zuverl¨assige Ende-zu-Ende Verbindungen zwischen Netzwerkger¨ aten aufbaut [KR08]. Weitere Details zu den unteren hardwarenahen Schichten des TCP/IP-Protokollstapels werden in Kapitel 4 im Rahmen der Untersuchung verschiedener kabelloser Netzwerktechnologien betrachtet. Hier sollen zun¨achst weitere wichtige Protokolle der Anwendungsschicht eingef¨ uhrt werden. Dazu z¨ahlen vorrangig das Hypertext Transfer Protocol (HTTP) und die Hypertext Markup Language (HTML), welche zusammen Anfang der 1990er Jahre den Beginn des Web begr¨ undeten. Das zuvor nur zum Austausch von Daten genutzte Internet wurde so um eine Komponente erweitert, die eine einfache Verkn¨ upfung von Texten und Daten erm¨ oglichte. Damit weckte das Internet auch das Interesse von Privatpersonen und Firmen. Auf Basis des Internets und des Web wurden auch neue Architekturen f¨ ur verteilte Anwendungen vorgestellt. So wurde die noch in den 1990er Jahren favorisierte Komponentenarchitektur, wie sie beispielsweise die Common Object Request Broker Architecture (CORBA) implementiert, durch eine lose gekoppelte Service-oriented Architecture (SOA) abgel¨ost. SOA kann wie folgt definiert werden. A Service-Oriented Architecture (SOA) is a software architecture that is based on ” the key concepts of an application frontend, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation.“[KBS05, S.57] SOA beschreibt also, wie abgeschlossene, wiederverwendbare und selbstbeschreibende Dienste in standardisierter Art und Weise genutzt und kombiniert werden k¨onnen. Cloud Computing ist untrennbar mit dem Dienstbegriff (Service) verbunden. Der Dienstbegriff beschreibt in der Informatik eine Funktionalit¨ at, der vor allem die Attribute Abgeschlossenheit, Standardkonformit¨ at, Verf¨ ugbarkeit via Netzwerk/Internet und daraus resultierend auch eine flexible/leichte Kombinierbarkeit zuzuordnen sind [Pap03, Erl06]. Eine sehr popul¨are Implementierung von SOA sind Web Services, die auf dem Austausch von eXtended Markup Language (XML) Nachrichten basieren. Das Simple Object Access Protocol (SOAP) wird dabei zum Nachrichtenaustausch genutzt. SOAP verwendet dabei in den meisten F¨allen HTTP zur Kommunikation. Gr¨ oßter Kritikpunkt an SOAP Web Services ist der hohe Overhead durch die XML-Codierung. Deshalb wurden als eine Art Gegenbewegung zur weithin standardisierten SOAP Web Service Landschaft leichtgewichtige RESTful Web Services vorgestellt [Fie00].

4

1.1 Begriffliche Grundlagen

REST (Representational State Transfer ) hat als Ziel, die Struktur des Internets bestm¨ oglich f¨ ur die Kommunikation auszunutzen. Die Kernkonzepte des REST Architekturstils sind Zustandslosigkeit von Client/Server Verbindungen, Anwendbarkeit von (Web-)Caches, einheitliche Schnittstellen und die Anwendungen eines Schichtenmodells, was in diesem Zusammenhang mit transparenten Weiterleitungen gleichzusetzen ist. Da es außer HTTP keine weitere Implementierung von RESTful Web Services gibt, wird eine Ressource oder Dienst u ¨blicherweise durch einen Uniform Ressource Identifier (URI) adressiert und liefert Daten dann in einer bei der Anfrage zu spezifizierenden Codierung zur¨ uck. Hierbei wird neben XML auch oft die wesentlich schlankere JavaScript Object Notation (JSON) verwendet. Zust¨ande k¨onnen u ¨ber die Verwendung von Hyperlinks manipuliert werden. Fast jede Programmiersprache bringt heute Konstrukte oder Bibliotheken zur Netzwerkkommunikation mit. Dabei gibt es neben Implementierungen f¨ ur die genannten Web Service Technologien auch verschiedene Programmiersprachen-spezifische Implementierungen wie beispielsweise Java Remote Method Invocation (RMI) oder C# .NET Remoting. Diese Technologien sind zwar h¨ aufig nicht Plattform-¨ ubergreifend nutzbar, sind daf¨ ur aber aus der jeweiligen Sprache mit geringem Aufwand benutzbar, was zur Verk¨ urzung der Entwicklungszeit beitragen kann.

1.1.2 Cloud Computing Der Begriff Cloud Computing wird in der Wissenschaft kontrovers diskutiert [VRMCL08], was zu der Notwendigkeit f¨ uhrt, hier zun¨achst die f¨ ur diese Arbeit relevanten Termini einzuf¨ uhren und deren Bedeutung festzulegen. Der Begriff kann folgendermaßen zusammengefasst werden: Thus, Cloud Computing is the sum of SaaS and Utility Computing, but does not ” include Private Clouds.“[AFG+ 09, S.1] Diese Definition erscheint zun¨ achst unbefriedigend, da sie weitere spezifische Termini enth¨ alt, die einer Erkl¨ arung bed¨ urfen. Der Begriff Utility Computing meint die allgemeine Verf¨ ugbarkeit von Computerressourcen, wie dies etwa f¨ ur Strom und Wasser der Fall ist, und deren Abrechnung nach tats¨ achlichem Verbrauch [Rap04]. In diesem Zusammenhang wird von payper-use und pay-as-you-go gesprochen. Dies entspricht der Nutzung von Ressourcen eines traditionellen Rechenzentrums, nur mit einer sehr kurzen Vertragslaufzeit, beispielsweise mit einer Abrechnung im Stundentakt. Eine solche kurzlebige Art der Bereitstellung und Abrechnung von Computerressourcen, wie persistenter Speicher oder Compute-Ressourcen, ist mit realer Hardware praktisch kaum zu realisieren. Allein die Konfiguration eines Rechners und die Installation der Software w¨ urden wohl schon Stunden in Anspruch nehmen. Stattdessen werden virtualisierte Ressourcen verwendet, die sich schnell und flexibel bereitstellen lassen. Virtualisierung von Maschinen gilt als Schl¨ usseltechnologie f¨ ur Utility Computing. + Weiterhin wird in [AFG 09] ausgef¨ uhrt, dass Clouds eben diese Menge von teils virtualisierten Ressourcen sind, die Anbieter im Rahmen des Begriffs Utility Computing bereitstellen. Stellt ein Anbieter seine Cloud ¨offentlich zur Verf¨ ugung, wie etwa Amazon Web Services 5 (AWS) , dann spricht man von einer Public Cloud. Es gibt jedoch auch Clouds, die nur intern, 5

Amazon Web Services bietet einen kompletten Satz von Infrastruktur- und Anwendungsservices, mit denen ” Sie fast alles von unternehmensweiten Anwendungen und Big Data-Projekten (große Datenmengen) bis hin zu gesellschaftlichen Spielen und mobilen Anwendungen in der Cloud ausf¨ uhren k¨ onnen.“ (Onlineressource http://aws.amazon.com/de/ (abgerufen am 1.11.2013))

5

1 Einleitung

etwa in großen Banken, genutzt werden und nur unternehmensintern zur Verf¨ ugung stehen. Dabei sprich man von Private Clouds. Das US-amerikanische Standardisierungsinstitut NIST (National Institute of Standards and Technology) liefert folgende Definition von Cloud Computing, die ebenfalls oft zitiert wird: Cloud computing is a model for enabling ubiquitous, convenient, on-demand net” work access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.“[MG11, S.2] Dieses Dokument definiert die Charakteristiken On-demand self-service, Broad network access, Resource pooling, Rapid elasticity und Measured service. Dabei geht diese Definition u ¨ber [AFG+ 09] hinaus, da sie explizit die Messbarkeit verschiedener Laufzeitparameter der Cloud-Dienste zu Optimierungszwecken fordert. Außerdem definiert [MG11] zus¨atzlich zu den Private und Public Clouds eine Kombination aus beiden, die Hybrid Clouds, und eine Community Cloud, welche eine Mischform aus Public und Private Cloud ist. In [MG11] wird jedoch nicht explizit das pay-per-use Prinzip zur Abrechnung gefordert. In dieser Arbeit wird die Anwendung des Begriffs Cloud Computing auf Public Clouds eingeschr¨ankt. Dies setzt auch das obligatorische Vorhandensein eines pay-per-use Abrechnungsmodells voraus. Dar¨ uber hinaus sind aber auch auf diese eingeschr¨ankte Variante die in [MG11] genannten f¨ unf Charakteristiken anwendbar. Im Bereich Cloud Computing stellen Dienste nicht nur Software-Funktionalit¨at dar, wie etwa Wettervorhersage oder Suche im Branchenbuch, sondern auch virtuelle Hardware oder Ausf¨ uhrungsumgebungen f¨ ur benutzerdefinierten Programmcode. Hierbei spricht man von verschiedenen Schichten, die ihre Dienste aufeinander aufbauen k¨ onnen. Eine Visualisierung des Schichtenmodells ist in Abbildung 1.1 zu sehen. In der genannten und weiterer Literatur wird h¨aufig u ¨bereinstimmend zwischen den drei nachfolgend beschrieben Schichten unterschieden, die auch in dieser Arbeit zu Grunde gelegt werden. • Infrastrukutur als Dienst (Infrastructure as a Service - IaaS) bietet dabei grundlegende Dienste wie virtuelle Maschinen, Netzwerk oder Festplattenspeicher an. • Darauf aufbauend bieten Dienste der Plattform-Schicht (Platform as a Service - PaaS) die M¨ oglichkeit, Programmcode direkt auf vorgefertigten Maschinen oder Servern auszuf¨ uhren ohne dabei die Maschinen selbst installieren oder warten zu m¨ ussen. Hierbei werden dann h¨ aufig nur noch Programme einer ausgew¨ahlten Programmiersprache unterst¨ utzt. Im Gegenzug u ¨bernimmt die Plattform-Schicht das Verteilen der Applikation auf Ressourcen der darunter liegenden Schicht und außerdem die Lastbalancierung und das Anpassen der Anzahl von ben¨otigten Ressourcen an die jeweilige Situation (Skalierung). • Schließlich kann auf Basis der darunter liegenden Schichten als oberste Schicht Software als Dienst (Software as a Service - SaaS) angeboten werden. Dabei handelt es sich oft um Software, die via Webinterface im Browser genutzt wird. Eine dem Cloud Computing sehr ¨ ahnliche Technologie ist das Grid Computing. Dieser Begriff stammt aus dem wissenschaftlichen Rechnen und beschreibt Bestrebungen, moderne

6

1.1 Begriffliche Grundlagen

Cloud Service Stack SaaS Applikationen

Dienste für Entwickler

PaaS

Infrastrukturdienste  Virtuelle Maschinen  Datenspeicher  Verbindungsnetzwerke (auch VPN)

IaaS

Abbildung 1.1: Schichteneinteilung von Cloud-Diensten. (vgl. Onlineressource http:// commons.wikimedia.org/wiki/File:Cloud_Services.gif (abgerufen am 1.11.2013)) Hochleistungsrechner derart zu vernetzen, dass Berechnungen auf diesem zusammengeschalteten Netzwerk (genannt Grid ) noch schneller erfolgen k¨onnen. Ein Computational Grid ist eine im Vergleich zu einem Hochleistungsrechner lose gekoppelte Hardware- und SoftwareInfrastruktur, die einen konsistenten Zugriff auf die Kapazit¨aten von geografisch verteilten Hochleistungsrechnern erm¨ oglicht [FK04]. Durch Standardisierungsbem¨ uhungen haben sich allgemein anerkannte Protokolle f¨ ur den Zugriff auf entfernte (Grid-)Ressourcen etabliert, beispielsweise das Web Service Ressource Framework (WSRF) [Ban06]. Eine h¨aufig verwendete Implementierung dieser Grid -Technologie stellt das Globus Toolkit Version 4 dar [Fos05], welches von verschiedenen internationalen Partnern aus dem unternehmerischen und aus dem universit¨aren Bereich stetig weiterentwickelt wird. Grid und Cloud Computing sind sich in einigen Punkten sehr ¨ ahnlich. Beide bieten einen standardisierten und zuverl¨assigen Zugang zu Computerressourcen. Auch im Bereich Grid Computing wurden Probleme wie Allokation und Management von Ressourcen, Optimierung durch Virtualisierung und ein einheitlicher Zugriff auf alle Teile des Grids bereits thematisiert. Cloud Computing kann sowohl als Weiterentwicklung des traditionellen Rechenzentrumkonzepts verstanden werden, als auch als Erweiterung der Grid -Technologie [FZRL08]. Gegen¨ uber einem traditionellen Rechenzentrum wurde vor allem die Flexibilit¨at stark erh¨oht. Dies trifft nicht nur auf Kundenseite mit dem pay-per-use Modell zu. Auch auf Anbieterseite kann der Energieverbrauch durch Ressourcen-Konsolidierung und weniger Idle-Standby der Server optimiert werden. Zus¨ atzlich sind nun in einem Rechenzentrum viel mehr Anwendungen m¨oglich, was zu einer Vergr¨ oßerung von Rechenzentren und somit im Allgemeinen auch zu einer Steigerung der Effizienz f¨ uhrt. Grid und Cloud unterscheiden sich vor allem durch die anvisierte Nutzergruppe. W¨ ahrend Grid -Umgebungen u ¨berwiegend von Universit¨aten und anderen Forschungseinrichtungen betrieben werden und auch vornehmlich von diesen genutzt werden, stehen Clouds insbesondere auch einem privaten und unternehmerischen Publikum

7

1 Einleitung

zur Verf¨ ugung. Musste man sich fr¨ uher f¨ ur einen Zugang zu einem Großrechner bewerben und ein interessantes Forschungsvorhaben pr¨asentieren, so reicht heute eine Kreditkarte aus, um sich einen Rechner f¨ ur die Dauer eines Experiments zusammenzustellen. Cloud Computing richtet sich demnach insbesondere an den kommerziellen Sektor. Durch die damit verbundenen marktwirtschaftlichen Anforderungen stellt sich gerade beim Cloud Computing auch besonders die Frage nach einer effizienten Ressourcenausnutzung, um finanziellen Overhead zu vermeiden. Im Vergleich zu nicht virtualisierten Clustern, Grid -Infrastrukturen und Servern, die man bisher nutzte, um entfernte Ressourcen zur Verf¨ ugung zu stellen, bietet Cloud Computing folgende Vorteile: • feingranulare Partitionierung der verf¨ ugbaren Hardwareressourcen, • schnelle Konfiguration neuer Dienste durch Virtualisierung, • einfachere Lastbalancierung durch Verschiebung der Lastbalancierung von der Applikationsschicht auf die Infrastrukturschicht, • bessere Skalierungsm¨ oglichkeiten durch schnelles Starten und Beenden von Diensten und dadurch auch effizientere Ausnutzung der verf¨ ugbaren Hardware.

1.1.3 Mobile Cloud Computing Mobile Computing wird bereits seit ca. 20 Jahren aktiv beforscht [FZ94, Sat96]. Beim Mobile Computing geht man heute wie damals davon aus, dass man einen mobilen, batteriebetriebenen Computer benutzt, der in seiner Leistungsf¨ahigkeit gegen¨ uber einem Festrechner stark eingeschr¨ankt ist. Dies ist unter anderem dem geringen Gewicht und der begrenzten elektrischen Energie geschuldet, die ein solches Ger¨at verf¨ ugbar hat [PKKB09]. Schon vor vielen Jahren wurden Techniken der verteilten Ausf¨ uhrung von mobilen Anwendungen vorgeschlagen mit dem Ziel, den Funktionsumfang von mobilen Anwendungen zu erh¨ohen. Hierbei spielten Techniken der Client/Server Programmierung oder auch abstraktere Konzepte wie Verteilte Objekte (Remote Object) eine Rolle. Technologien wie CORBA und vor allem auch Internettechnologien wie HTTP, HTML und andere trugen maßgeblich dazu bei, dass Qualit¨at und Funktionsumfang Mobiler Server-unterst¨ utzter Anwendungen stetig stiegen. Mobile Cloud Computing versucht nun durch die Eigenschaft der st¨andigen Verf¨ ugbarkeit von Rechen- und Speicherressourcen, auch f¨ ur mobile Endger¨ate Dienste anzubieten. Das Mobile Cloud Computing Forum fasst den Begriff wie folgt zusammen: Mobile Cloud Computing at its simplest, refers to an infrastructure where both ” the data storage and the data processing happen outside of the mobile device. Mobile cloud applications move the computing power and data storage away from mobile phones and into the cloud, bringing applications and mobile computing to not just smartphone users but a much broader range of mobile subscribers.“Onlineressource http://www.2exhibitions.com/conference.asp?show=Mobile_Cloud_ Computing_Forum(abgerufen am 1.11.2013)

Es geht also darum, f¨ ur mobile Applikationen externe Ressourcen nutzbar zu machen. Dabei soll diese Technik f¨ ur viele Nutzer gleichzeitg zur Verf¨ ugung stehen. Hierbei trifft man oft auf Begriffe wie Applikations-Partitionierung [CM10] oder Code-Offloading [KL10, GTF06]. Applikations-Partitionierung besch¨ aftigt sich mit der Auftrennung von Applikationen in mobil

8

1.1 Begriffliche Grundlagen

ausgef¨ uhrte Teile und serverseitig ausgef¨ uhrte Teile. Da dies oft von der gerade verf¨ ugbaren Netzwerkperformance abh¨ angig ist, geschieht diese Partitionierung oft zur Laufzeit. Wenn ein Client Applikationscode zur Laufzeit auf dem Server installieren und verwenden kann, nennt man diesen Vorgang Code-Offloading. Dies hat den Vorteil, dass beliebiger Programmcode installiert werden kann und somit die Applikation auf dem Server nicht vorher installiert werden muss. Anwendungen f¨ ur Mobile Cloud Computing sind im Bereich Mobile Commerce, Mobile Learning, Mobile Healthcare oder Mobile Gaming zu finden [DLNW11]. Beliebt sind auch die eingangs erw¨ ahnten Anwendungen zum Abspeichern von Daten in der Cloud, wie etwa Dropbox oder Skydrive.

1.1.4 Quality of Service Die Dienstqualit¨ at (Quality of Service (QoS)) beschreibt nicht-funktionale Eigenschaften eines Dienstes. Dabei findet man in der Literatur h¨aufig die Kriterien Preis, Antwortzeit, Reputation, Zuverl¨ assigkeit und Verf¨ ugbarkeit, die die nicht-funktionalen Eigenschaften beschrei+ ben [ZBD 03]. Diese Kriterien werden benutzt, um bei gleichen funktionalen Eigenschaften eine Auswahl zwischen verschiedenen Diensten treffen zu k¨onnen. Die genaue Spezifikation der Kriterien h¨ angt dabei auch vom Anwendungsfall ab. Um ein genaues Verst¨andnis und entsprechende Werte dieser Kriterien beispielsweise im Fall einer bilateralen Vereinbarung zu manifestieren, werden h¨ aufig sogenannte Service-Level-Agreements (SLA) zwischen Dienstanbieter (Provider) und Dienstnutzer (Consumer) ausgehandelt. Der Preis beschreibt die Kosten, die durch Inanspruchnahme eines Dienstes entstehen. Hierbei wird im Cloud-Umfeld u ¨blicherweise das pay-per-use Modell zu Grunde gelegt. Die Antwortzeit beschreibt die Bearbeitungsdauer einer Anfrage durch einen Dienst. Die Bearbeitungsdauer ist oft auch von einer gegebenen Eingabegr¨oße abh¨angig. Die Reputation beschreibt die heute oft u ¨bliche Bewertung eines Dienstes durch die Endnutzer. Sie entspricht einer Produktbewertung und umfasst deshalb nicht nur die Bewertung nicht-funktionaler Eigenschaften. Dieses Kriterium wird in dieser Arbeit nicht weiter betrachtet. Die Zuverl¨ assigkeit beschreibt die Wahrscheinlichkeit, dass eine Anfrage in einem gegebenen Zeitfenster korrekt beantwortet wird. Die Zuverl¨assigkeit h¨angt stark von der Anzahl der Anfragen pro Zeiteinheit und den in diesem Zeitraum zur Verf¨ ugung stehenden Ressourcen ab. Aber auch die Effizienz eines Dienstes bez¨ uglich der Ausnutzung des Ressourcenpools spielt eine große Rolle. Die Verf¨ ugbarkeit eines Dienstes beschreibt die Wahrscheinlichkeit, dass der Dienst ¨ verf¨ ugbar ist. Ublicherweise wird diese als Verh¨altnis aus Dauer der Erreichbarkeit und einem Zeitinterval der Gesamtdauer definiert. Die Verf¨ ugbarkeit ist von sehr hardwarenahen Faktoren und auch den Netzwerkkomponenten abh¨angig und kann etwa durch redundante Rechenzentren verbessert werde. Der Softwareentwickler hat h¨aufig nur begrenzten Einfluss auf die Verf¨ ugbarkeit eines Dienstes, den er zur Verf¨ ugung stellt. Hierzu handelt der Softwareentwickler einen Vertrag mit dem Rechenzentrumsanbieter als Hoster seiner Dienste aus.

1.1.5 Mobile Kommunikationsnetze Die hier betrachteten kabellosen Kommunikationsnetze lassen sich in Fl¨achennetze und Punktnetze unterscheiden. Fl¨ achennetze sind die allgemeinen Mobilfunknetze, die an nahezu jedem Punkt verf¨ ugbar sind. Im Fokus dieser Arbeit steht vor allem das UMTS-Netz in Deutschland. Mobilfunknetze sind in Funkzellen unterteilt, die mindestens durch eine Antenne repr¨asen-

9

1 Einleitung

tiert sind. Als Teilnehmer in solch einer Funkzelle ist man stets mit mindestens einer Antenne verbunden. In der Literatur zu mobilen Kommunikationsnetzen wird ein mobiles Endger¨at auch oft als Handset oder mobile Equipment bezeichnet [Sau13]. Aus Kompatibilit¨atsgr¨ unden werden ¨ altere Netzwerke bei Einf¨ uhrung einer neuen Kommunikationstechnologie nicht sofort abgeschaltet, auch wenn diese neue Antennenkonfigurationen ben¨otigen. So existieren in Deutschland beispielsweise drei verschiedene Mobilfunktechnologien nebeneinander. Das ¨altere GSM-Netz, welches urspr¨ unglich nicht f¨ ur den Austausch von Daten vorgesehen war, wurde schon fast u ¨berall durch das auf Datenkommunikation optimierte UMTS-Netz erweitert. Zus¨ atzlich erfolgt in Deutschland momentan der Aufbau des LTE-Netzes, welches gegen¨ uber UMTS eine sehr stark beschleunigte Daten¨ ubertragung erlaubt und auch f¨ ur station¨are Internetanschl¨ usse via Mobilfunknetz genutzt wird. Das LTE-Netz in Deutschland ist jedoch noch nicht fl¨ achendeckend verf¨ ugbar. Die Mobilfunknetze unterliegen einer st¨andigen Weiterentwicklung. So existierten aufbauend auf dem UMTS-Standard Weiterentwicklungen namens HSPA und HSPA+, die durch verschiedene Optimierungen eine h¨ohere mittlere Bandbreite und geringere Netzwerklatenz pro Teilnehmer erm¨oglichen. In Deutschland sind maximale Bandbreiten zwischen 7,2 und ca. 21 Mbit/s je nach Anbieter verf¨ ugbar [PH13]. Im Vergleich zu kabelgebundenen Kommunikationsnetzen schwanken die Bandbreite und die Latenz je nach Nutzeranzahl und Verbindungsqualit¨at. Diese Schwankungen treten auch bei WLAN-Netzwerken auf, die die Gruppe der Punktnetze bilden. WLAN-Netzwerke sind immer nur punktuell verf¨ ugbar und bestehen im Allgemeinen aus einer Antenne, bzw. einem Zugangspunkt. Ausnahmen bilden hier gr¨oßere Installationen, wie etwa in Bahnh¨ ofen oder Universit¨aten, die aus mehreren Antennen bestehen und oftmals große Teile der Institution oder des Ortes mit WLAN-Zugang versorgen. Aber auch diese sind lokal begrenzt. WLAN wird auch h¨aufig in privaten Haushalten eingesetzt, um einen kabelgebundenen Internetzugang f¨ ur mehrere Personen/Ger¨ate nutzbar zu machen. WLAN unterliegt ebenso einer st¨ andigen Weiterentwicklung. Aktuell verf¨ ugt fast jeder Zugang u ¨ber eine Bandbreite von 54 Mbit/s. Weit verbreitet sind mittlerweile auch Zug¨ange mit 300 Mbit/s und mehr, je nach Antennenkonfiguration [Sau13]. WLAN erm¨oglicht u ¨blicherweise Latenzen im einstelligen Millisekunden-Bereich. Da der hinter dem WLAN liegende Internetzugang oft nicht die volle WLAN-Bandbreite durchleiten kann, begrenzt sich die verf¨ ugbare Bandbreite zum Internet ensprechend. G¨angige Anschl¨ usse f¨ ur private Haushalte liegen hier meist im zweistelligen Mbit-Bereich, jedoch ist die verf¨ ugbare Anschlussqualit¨at in Deutschland regional sehr unterschiedlich, sodass mancherorts auch nur weniger als 1 Mbit/s zur Verf¨ ugung stehen kann. WLAN und UMTS wurden f¨ ur diese Arbeit als Kandidaten f¨ ur die drahtlose Kommunikation ausgew¨ ahlt, da sie nicht nur eine angemessene Kommunikationsgeschwindigkeit bieten, sondern auch in vielen Ger¨aten verf¨ ugbar sind6 .

1.2 Problemstellung und Zielsetzung Die vorliegende Arbeit n¨ ahert sich dem Thema Mobile Cloud Computing zun¨achst aus Sicht des Anwenders, der auf mobilen Endger¨aten Applikationen nutzt. Mobile Applikationen k¨on6

Laut www.geizhals.at waren am 8. M¨ arz 2013 ca. 40% aller in der Europ¨ aischen Union angebotenen Handys ohne Vertrag mit UMTS und WLAN ausger¨ ustet. Bei den Smartphones (Touchscreen, Aufl¨ osung ab 320x240 und GPS) sind es sogar ca. 92%. Notebooks mit WLAN machen u ate aus. Da¨ber 99% aller Ger¨ gegen sind nur ca. 10% aller Notebooks mit UMTS ausger¨ ustet. Tablets ohne WLAN gibt es nicht und ca. 28% aller in der EU angebotener Tablets sind mit UMTS ausger¨ ustet.

10

1.2 Problemstellung und Zielsetzung

nen nach ihrem Einsatzzweck in zwei Gruppen unterteilt werden: 1. Anwender m¨ ochten die kabellosen Ger¨ate nutzen, um ihre vormals station¨ar genutzten Programme auch mobil zu verwenden, 2. Anwender m¨ ochten neue Anwendungen nutzen, die die F¨ahigkeiten der mobilen Sensoren nutzbar machen. Einsatzzweck 1 leitet sich aus dem aktuellen Trend in den Absatzzahlen von PCs, Notebooks und Mobilger¨ aten wie Tablets und Smartphones ab. Dieser l¨asst erkennen, dass zunehmend mehr Mobilger¨ ate und weniger PCs und Notebooks gekauft werden. Dies legt die Vermutung nahe, dass diese neuartigen Mobilger¨ate zunehmend auch als Ersatz f¨ ur PCs und Notebooks dienen. Einsatzzweck 2 macht sich den Unterschied zu Nutze, den diese Ger¨ate gegen¨ uber station¨aren PCs und Notebooks haben. Nutzer stellen demnach an mobile Anwendungen die Anforderung, dass diese sich ¨ ahnlich bedienen lassen wie station¨are Anwendungen und dass diese auch a hnlich fl¨ u ssig und schnell arbeiten. ¨ Bei der Realisierung von Anwendungen, die diesen Anforderungen entsprechen, kommt es jedoch zu verschiedenen Konflikten. Die gegen¨ uber station¨aren PCs ver¨anderte Hardware, beispielsweise geringere CPU Leistung, Hauptspeicher, Display-Aufl¨osung und unterschiedliche Betriebssysteme lassen eine einfache Portierung von Applikationen station¨arer PCs oft nicht zu. F¨ ur die mobile Nutzung ist eine komplexe Anpassung der Applikation an die jeweiligen Ger¨ate notwendig. Dies f¨ uhrt nicht selten dazu, dass der Funktionsumfang der vormals station¨ar genutzten Anwendungen auf dem Mobilger¨at geringer ausfallen muss. Weiterhin sind neue Applikationen, die die auf Mobilger¨aten vorhandenen Sensoren zur Laufzeit auswerten, schwierig zu realisieren, da die Auswertung oft mit komplexen Berechnungen verbunden ist. Diese Berechnungen k¨ onnen aufgrund der geringen Hardware-Ausstattung mobiler Ger¨ ate h¨aufig nicht schnell genug ausgef¨ uhrt werden, um einen nutzbaren Mehrwert f¨ ur den Anwender zu generieren. Manche dieser Probleme lassen sich durch Optimierungen, wie die Nutzung von Prozessorinstruktionserweiterungen des Mobilprozessors, direkt l¨osen, so etwa die Decodierung von HD-Videostr¨ omen. Andere Anwendungen, wie etwa speicherintensive Bildverarbeitungsroutinen k¨onnen davon nicht profitieren. Manche Anwendungen k¨onnen jedoch vom Einsatz von Mobile Cloud Computing profitieren. Bei der Bereitstellung einer Infrastruktur f¨ ur Mobile Cloud Computing sind verschiedene Aspekte von Bedeutung. Dabei fokussiert sich diese Arbeit auf die Nutzung von weitgehend ¨offentlich verf¨ ugbaren Technologien, um eine breite Anwendbarkeit der Technologie zu erreichen. Will man f¨ ur eine große Anzahl von MCC-Nutzern entfernt verf¨ ugbare Serverressourcen ¨offentlich zur Verf¨ ugung stellen, so sind nachfolgende Aspekte besonders zu betrachten. Mobile Netzwerkverbindung Problematisch ist bei Mobilen Server-unterst¨ utzten Anwendungen zun¨achst immer die Bewertung der verf¨ ugbaren Netzwerkverbindung. Die zuverl¨assige Kenntnis u ¨ber die Datenu ¨bertragungsgeschwindigkeit und die Gr¨oße der zu u ¨bertragenden Daten sind notwendig, um ¨ die erwarteten Ubertragungszeiten absch¨atzen zu k¨onnen. Hierbei ist die verf¨ ugbare kabellose Internetanbindung der mobilen Ger¨ ate besonders zu beachten, da je nach verwendeter Technik ¨ und Empfangsst¨ arke die Geschwindigkeit stark variieren kann. Die Ubertragungstechnologie ¨ selbst hat ebenfalls Einfluss auf die Ubertragungsgeschwindigkeit. Zus¨atzlich beeinflusst die

11

1 Einleitung

Codierung der Daten und die H¨ aufigkeit von Sendeoperationen die Performance der Kommunikation. Diese Parameter haben damit auch Einfluss auf den Speedup, der durch die Auslagerung von Berechnungen auf entfernte Server erreicht werden kann. Je kleiner das Verh¨altnis aus Daten¨ ubertragungszeit und Berechnungszeit ist, desto besser eignet sich ein Programm f¨ ur die Auslagerung. Es ist demnach notwendig, die potenziell geringe verf¨ ugbare Bandbreite durch geeignete Kommunikationsmuster und Codierungen bestm¨oglich auszunutzen. Dabei k¨onnen aufgrund beispielsweise der h¨ oheren Latenz und teilweise fehlenden Duplexf¨ahigkeit nur bedingt Technologien aus der kabelgebundenen Kommunikation u ¨bernommen werden. Auswahl der Cloud-Ressource Eine weitere Problemstellung ist die situationsabh¨angige Auswahl einer geeigneten CloudRessource zur Unterst¨ utzung der mobilen Applikation. Da Cloud-Anbieter ihre Ressourcen in verschiedenen Qualit¨ atsstufen anbieten, ist es sinnvoll, eine bedarfsgerechte Auswahl zu treffen, die mit den geforderten QoS Eigenschaften wie beispielsweise Verarbeitungszeit in Einklang steht. Die Auswahl h¨ angt zun¨achst wieder direkt von den Daten¨ ubertragungszeiten ab. Es ist beispielsweise un¨ okonomisch, bei geringer Netzwerkperformance eine schnelle und teure Ressource auszuw¨ ahlen, die dann nur zu einem geringen Prozentsatz ausgelastet werden kann. Hierbei ist zu beachten, dass verschieden schnelle Ressourcen auch verschiedene Kosten haben. Neben der Verarbeitungsgeschwindigkeit und Auslastung einer Ressource spielt also auch die Kostenoptimierung bei der Auswahl eine Rolle. Um die Verarbeitungsgeschwindigkeit absch¨atzen zu k¨ onnen, ist es notwendig, das Applikationsverhalten (insbesondere die Skalierbarkeit) f¨ ur eine bestimmte Eingabe auf den zur Verf¨ ugung stehenden Cloud-Ressourcen zu kennen. Insbesondere das Herstellen eines Zusammenhangs zwischen einer Eingabegr¨oße und der Verarbeitungszeit ist nicht immer einfach, da eine Abh¨angigkeitsfunktion gefunden werden muss, von der nicht bekannt ist, ob sie u ¨berhaupt existiert. Verbesserung der Granularit¨ at der Abrechnungsperiode Eine dritte Problemstellung ist die Verbesserung der Granularit¨at bez¨ uglich der Abrechnungsperiode f¨ ur den Endkunden. Mobile Cloud-unterst¨ utzte Anwendungen haben oft zeitlich begrenzte Anforderungen an entfernt verf¨ ugbare Ressourcen, die je nach Anwendung und Nutzerverhalten zwischen wenigen Sekunden bis Minuten betragen k¨onnen. Cloud-Anbieter hingegen rechnen die Nutzung im Stundentakt ab. Hier bedarf es einer geeigneten Wiederverwendungsstrategie, um Cloud-Ressourcen zwischen Nutzern zu teilen und m¨oglichst gut auszulasten. Dabei muss jedoch trotzdem sichergestellt werden, dass jeder Nutzer die Performance, f¨ ur die er zahlt, auch nutzen kann. Um zudem noch die Abrechnung auf feingranularer Basis zu erm¨ oglichen, bedarf es der Entwicklung eines Cloud-Nutzungs-Zyklus. Da Tests mit vielen Nutzern auf einer realen Cloud-Infrastruktur kaum zu finanzieren sind, muss eine Simulation durchgef¨ uhrt werden, die mit m¨oglichst real gemessenen Daten arbeitet. Weitere Nebenproblemstellungen Eine weitere Herausforderung ist der allgemeine Schutz der u ¨bertragenen Daten und auch der Schutz von Fremdzugriffen auf die bereitgestellten Ressourcen. Dies ist notwendig, weil jede Nutzung der Infrastruktur Kosten f¨ ur den Nutzer verursacht. Die Verschl¨ usselung der Verbindung sowie geeignete Mechanismen zur Authentifizierung sind deshalb obligatorisch. Dies erfordert eine geeignete Modellierung des Lebenszyklus der Verbindung zwischen Nutzer

12

1.3 Aufbau der Arbeit

und der entfernten Ressourcen. Die Bereitstellung von Applikationen f¨ ur die zu entwerfende Middleware ist ebenfalls Teil der Problemstellung. Hierbei sind geeignete Monitoring- und Debugging-M¨ oglichkeiten zu schaffen, um die Ausf¨ uhrung von Applikationen analysieren und abrechnen zu k¨ onnen. Zielsetzung der Arbeit ist demnach die Analyse der oben genannten Aspekte bei der Erstellung und Ausf¨ uhrung von mobilen Applikationen aus dem Bereich Mobile Cloud Computing und anschließend der Entwurf und die Implementierung einer Middleware, die die Ergebnisse der Analysen beachtet und die geforderten Eigenschaften umsetzt. Diese zu entwickelnde Middleware hat selbst Dienstcharakter und ist auf dem PaaS-Level anzusiedeln. Dem Nutzer soll jedoch im Gegensatz zu bestehenden PaaS-Systemen die M¨oglichkeit gegeben werden, auf die Qualit¨ atseigenschaften der darunter liegenden IaaS-Schicht Einfluss zu nehmen. Dies wird ben¨otigt, um rechenintensive Mobile Cloud-unterst¨ utzte Anwendungen realisieren zu k¨onnen, die dann in der Lage sind, den in 1.2 genannten Anforderungen gerecht zu werden. Insbesondere sollen dazu nur ¨ offentlich verf¨ ugbare Technologien betrachtet werden. Dazu z¨ahlen Public Clouds und das ¨ offentliche Mobilfunknetz erg¨anzt durch diverse WLAN HotSpots. Diese Einschr¨ ankung ist zugleich Herausforderung und soll eine breite Anwendbarkeit der Forschungsergebnisse sicherstellen. Im Gegensatz zu anderen Arbeiten wird in dieser Arbeit die Energieeinsparung durch Mobile Cloud Computing nicht thematisiert, da die Verbesserung des Nutzererlebnisses (englisch User Experience) unter Beachtung der Kosten im Vordergrund steht. Dazu ist es oft notwendig, die verf¨ ugbaren Ressourcen (Cloud-Ressourcen und mobiles Endger¨at) auch auszulasten.

1.3 Aufbau der Arbeit Diese Arbeit n¨ ahert sich der zentralen Fragestellung unter Beachtung verwandter Arbeiten. ¨ Dazu wird in Kapitel 2 zun¨ achst ein Uberblick u ¨ber die einschl¨agige Literatur zu den Themen Cloud Computing, Mobile Computing und anderen gegeben. Nach der Einordnung der Arbeit in die aktuelle Forschungslandschaft werden anschließend theoretische Grundlagen zu einer Theorie zusammengef¨ ugt, die durch eigene empirische Beobachtungen verfeinert und erweitert wird. Das resultierende Modell, welches in Kapitel 3 vorgestellt wird, ist in der Lage, Mobile Server-unterst¨ utzte Anwendungen abzubilden. Das Modell wird dabei aus Anforderungen und Erfahrungen generiert, die in verwandten und eigenen Arbeiten zu finden sind. Dazu werden Anwendungen und deren Charakteristik, existierende Middlewares und deren Architektur und weitere Technologien aus dem Bereich Public Computing analysiert. Weitere Aspekte, die insbesondere f¨ ur MCC von Bedeutung sind, werden in speziellen Kapiteln untersucht. Dazu z¨ ahlt die theoretische und praktische Untersuchung von mobilen Netzwerkverbindungen in Kapitel 4. Die Leistungsf¨ahigkeit von UMTS und WLAN-Verbindungen wird unter Verwendung verschiedener Mobilger¨ate betrachtet. Erfasst werden Parameter wie Latenz, Bandbreite und Duplexf¨ ahigkeit. Zus¨atzlich wird der Einfluss von Verschl¨ usselung, Kommunikationsfrequenz und Datencodierung untersucht. Diese Untersuchung m¨ undet in die Umsetzung einer effizienten Kommunikationsbibliothek, die die Eigenschaften mobiler Netzwerkverbindungen bestm¨ oglich unterst¨ utzt und f¨ ur Anwendungen eine zuverl¨assige Kommunikationsschnittstelle bereitstellt. In Kapitel 5 wird untersucht, wie eine Architektur zur Bereitstellung feingranularer und konfigurierbarer Cloud-Ressourcen zur Unterst¨ utzung von mobilen Anwendungen aussehen

13

1 Einleitung

kann. Dazu z¨ ahlt auch die Modellierung des Zugriffs auf solche Ressourcen. Um die Eigenschaften und die Leistungsf¨ ahigkeit einer solchen Architektur auf Basis o¨ffentlicher CloudAnbieter zu untersuchen, wird eine Simulation durchgef¨ uhrt. Dazu werden zun¨achst relevante Simulationsparameter und Simulationseingaben ermittelt. Diese sollen direkt aus realen MCC-Anwendungen und realer Infrastruktur abgeleitet sein und m¨ ussen dazu entsprechend gemessen werden. Ziel der Simulation ist der Vergleich verschiedener Algorithmen zur Allokation und Lastbalancierung von Cloud-Ressourcen. Kapitel 6 untersucht den Aspekt der bedarfsgerechten Auswahl von verf¨ ugbaren CloudRessourcen zur Ausf¨ uhrungszeit des Programms. Es werden geeignete Parameter ermittelt, die zun¨achst die aktuelle Situation des Nutzers bez¨ uglich der verf¨ ugbaren Netzwerkperformance und der Geschwindigkeit des Mobilger¨ats bestimmen. Zus¨atzlich werden weitere Parameter definiert, die eine Prognose u uhrungszeit bei Ausf¨ uhrung auf ei¨ber die zu erwartende Ausf¨ ner entfernten Cloud-Ressource erm¨ oglichen. Aufbauend auf diesen Parametern wird dann eine Schnittstelle entwickelt, die es erm¨oglicht, Applikationen mit spezifischen Eigenschaften bereitzustellen und dar¨ uber hinaus in Abh¨angigkeit der Laufzeitparameter eine Auswahl m¨oglicher und sinnvoller Ausf¨ uhrungsoptionen zu pr¨asentieren. Zur Auswahl werden geeignete Algorithmen entwickelt. Die Ergebnisse der in Kapitel 3–6 durchgef¨ uhrten Untersuchungen m¨ unden dann in Kapitel 7 in den Entwurf einer Middleware, die geeignete Mechanismen zur Kommunikation, Allokation von Ressourcen und deren bedarfsgerechte Auswahl unterst¨ utzt. Dazu werden die Middleware-Komponenten und die Programmierschnittstelle (Application Programming Interface (API)) der Middleware f¨ ur Java vorgestellt. Dieses Kapitel besch¨aftigt sich auch mit der Erstellung von Applikationen auf Basis der API und stellt die M¨oglichkeiten der Laufzeitumgebung bez¨ uglich Debugging und Monitoring von Anwendungen vor. Zur Demonstration der Anwendbarkeit der Middleware werden in Kapitel 8 Applikationen vorgestellt, die mit Hilfe der Middleware realisiert sind. Dies dient auch dem Zweck der Bewertung der Leistungsf¨ ahigkeit der Middleware. Dabei werden synthetische Parameter untersucht, wie etwa die Dauer der Allokation von Ressourcen. Außerdem werden auch Applikationen aus dem Open Source Bereich unter Verwendung der Middleware f¨ ur mobile Ger¨ate portiert. Die Transformation und Analyse wird ebenfalls beschrieben. Anschließend wird die Leistungsf¨ahigkeit der Auswahlstrategie f¨ ur Cloud-Ressourcen f¨ ur die einzelnen Applikationen gemessen. Dazu werden die gesch¨ atzten und die real gemessenen Ausf¨ uhrungszeiten verglichen. Kapitel 9 fasst die Arbeit zusammen und res¨ umiert die wichtigsten Ergebnisse der Untersuchungen. Außerdem werden Ankn¨ upfungs- und Erweiterungspunkte der Arbeit diskutiert. Dieses Kapitel m¨ undet in einer Handlungsempfehlung zur Erstellung von MCC-Anwendungen unten den Einschr¨ ankungen wie sie in dieser Arbeit untersucht wurden. Die f¨ ur die Untersuchungen in dieser Arbeit erstellten Java-Programme wurden u ¨berwie7 gend unter Linux Mint entwickelt. Dazu wurde Das Java Development Kit (JDK)8 der 7

The purpose of Linux Mint is to produce a modern, elegant and comfortable operating system which is both ” powerful and easy to use. Started in 2006, Linux Mint is now the 4th most widely used home operating system behind Microsoft Windows, Apple Mac OS and Canonical’s Ubuntu. [...] Based on Debian and Ubuntu, it provides about 30,000 packages and one of the best software managers.“ (Onlineressource http: //www.linuxmint.com/about.php (abgerufen am 16.4.2014)) 8 Mit dem Java Development Kit (JDK) lassen sich Java SE-Applikationen entwickeln. Dem JDK sind Hilfs” programme beigelegt, die f¨ ur die Java-Entwicklung n¨ otig sind. Dazu z¨ ahlen der essenzielle Compiler, aber auch andere Hilfsprogramme, etwa zur Signierung von Java-Archiven oder zum Start einer Management-

14

1.3 Aufbau der Arbeit

OpenJDK -Implementierung von Java verwendet, deren Eigenschaften in Kapitel 6.3.3 genauer betrachtet werden. Als Entwicklungsumgebung kam Eclipse 9 zum Einsatz. F¨ ur die erstellten Android -Programme kam ebenfalls die Entwicklungsumgebung Eclipse zum Einsatz, welche f¨ ur diesen Zweck um das Plugin Android Development Tools (ADT) erweitert wurde. Zur Entwicklung von Android -Programmen war zus¨atzlich das Android Software Development Kit (SDK)10 notwendig, welches unter anderem den Compiler f¨ ur Android -Programme enth¨alt.

Konsole. In den Versionen Java 1.2, 1.3 und 1.4 heißt das JDK Java 2 Software Development Kit (J2SDK), kurz SDK, ab Java 5 heißt es wieder JDK.“ (siehe [Ull12, S.78]) 9 Eclipse (von englisch eclipse ,Sonnenfinsternis’ ,Finsternis’ ,Verdunkelung’) ist ein quelloffenes Program” mierwerkzeug zur Entwicklung von Software verschiedenster Art. Urspr¨ unglich wurde Eclipse als integrierte Entwicklungsumgebung (IDE) f¨ ur die Programmiersprache Java genutzt, aber mittlerweile wird es wegen seiner Erweiterbarkeit auch f¨ ur viele andere Entwicklungsaufgaben eingesetzt. F¨ ur Eclipse gibt es eine Vielzahl sowohl quelloffener als auch kommerzieller Erweiterungen.“ (Onlineressource http: //de.wikipedia.org/wiki/Eclipse_(IDE) (abgerufen am 16.5.2014)) Eclipse ist verf¨ ugbar unter Onlineressource http://www.eclipse.org/ (abgerufen am 16.5.2014) 10 The Android SDK provides you the API libraries and developer tools necessary to build, test, and debug ” apps for Android. If you’re a new Android developer, we recommend you download the ADT Bundle to quickly start developing apps. It includes the essential Android SDK components and a version of the Eclipse IDE with built-in ADT (Android Developer Tools) to streamline your Android app development.“ (Onlineressource http://developer.android.com/sdk/index.html (abgerufen am 16.5.2014))

15

2 Verwandte Arbeiten ¨ Im Bereich Mobile Cloud-unterst¨ utzte Anwendungen gibt es eine Vielzahl von Uberschneidungen mit den Bereichen Mobilit¨ at, Client/Server, Services Computing, Ressourcenmanagement, und mehr. In diesem Kapitel werden wichtige verwandte Arbeiten vorgestellt. Zun¨achst erfolgt eine Charakterisierung von Anwendungen aus dem Bereich MCC, anhand derer dann eine bessere Einordnung des behandelten Problems erfolgen kann. Auf Basis der Anwendungscharakteristik werden dann bereits verf¨ ugbare und verwandte Technologien vorgestellt und deren Eignung und Beschr¨ ankungen f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen er¨ortert. Bez¨ uglich der Problemstellung liegt dabei besonderes Augenmerk auf der Beachtung der speziellen Eigenschaften von mobilen Kommunikationsverbindungen, der Granularit¨at der ben¨otigten Serverunterst¨ utzung und der bedarfsgerechten Auswahl der Serverressource.

2.1 MCC-Anwendungen und deren Charakteristik Aus dem Studium einschl¨ agiger Literatur zum Thema Mobile (Cloud) Computing geht hervor, dass vor allem Anwendungen aus den Bereichen Bildverarbeitung, Computerspiele und Internetanwendungen wie E-Mail oder Web eine große Rolle f¨ ur den Endbenutzer spielen (siehe Tabelle 2.1). Dabei z¨ ahlen E-Mail und Web u ¨blicherweise nicht zu den berechnungsintensiven Anwendungen und sind somit f¨ ur unsere Betrachtungen von untergeordnetem Interesse.

2.1.1 Bildverarbeitung Mobile Bildverarbeitung ist ein Beispiel, wof¨ ur man die in mobilen Endger¨aten eingebauten Sensoren nutzen kann. Damit k¨ onnen dem Nutzer neuartige Applikationen bereitgestellt werden, die auf einem station¨ aren PC nicht realisierbar w¨aren. Hierbei sind vor allem Applikationen der Mustererkennung, Bildbearbeitung oder Augmented Reality (AR) von Bedeutung [CLK+ 11, CBC+ 10, KPKB10, MPPS+ 12]. Diesen Anwendungen ist u ¨blicherweise gemein, dass sie in mindestens eine Richtung gr¨oßere bin¨are Datenmengen in Form von Video oder Bilddaten u ¨bertragen. Dabei sind die Anwendungen jedoch oft nicht sehr zeitkritisch. Das heißt, dass etwaige gr¨ oßere Latenzzeiten durch die mobile Datenverbindung durch Pufferung (beispielsweise bei Video) ausgeglichen werden k¨onnen. Eine Ausnahme bilden hier Anwendungen von Augmented Reality. Da hierbei aufgenommene Kamerabilder in Echtzeit mit Zusatzinformationen aufgewertet werden, ist eine schnelle Antwortzeit des Servers Voraussetzung f¨ ur das fl¨ ussige Bedienen einer solchen Anwendung. Anwendungen aus ¨ dem Bereich Bildverarbeitung ben¨ otigen außerdem eine recht hohe Ubertragungsbandbreite, die mindestens 1 Mbit/s betragen sollte, um brauchbare Ergebnisse zu gew¨ahrleisten. Auf Serverseite ben¨ otigen diese Anwendungen meistens erh¨ohte Rechenkapazit¨at. Aus [CBC+ 10] geht beispielsweise hervor, dass ein Gesichtserkennungsalgorithmus Daten im 10-100 kB Bereich zwischen Server und Client transferiert, und dass eine Client/Server-Variante der Gesichtserkennung 2-3 s ben¨ otigt. Die Bildverarbeitungsapplikationen k¨onnen sowohl in 3G und WLAN-Netzwerken benutzt werden. Bildverarbeitungsanwendungen sind meist von kurzer

16

2.1 MCC-Anwendungen und deren Charakteristik

Nutzungsdauer gepr¨ agt. Bei Augmented Reality Applikationen betr¨agt die Nutzungsdauer bis zu einigen Minuten [KPKB10].

2.1.2 Mobile Gaming Im Bereich Mobile Gaming ist zwischen zwei grunds¨atzlichen Richtungen zu unterscheiden. Einerseits wird hier das sogenannte Stream-Gaming oder auch Cloud-Gaming angewendet, bei dem die Spiele nicht mehr lokal auf dem Ger¨at, sondern auf entfernten Servern ausgef¨ uhrt werden. Die Bildschirmausgabe wird per Stream u ¨bertragen. Andererseits gibt es auch eine Gruppe von lokal ausgef¨ uhrten Spielen, bei der per Netzwerk verbundene Spieler gegeneinander/miteinander spielen. Im Vergleich zum Mobile Video Streaming, welches durch Pufferung eine schlechte Netzwerkperformance ausgleichen kann, ist beim Cloud-Gaming vor allem die Netzwerklatenz entscheidend, um ein fl¨ ussiges Spielerlebnis und eine ad¨aquate Reaktionszeit ¨ zu garantieren. Die Anforderungen an die Ubertragungsbandbreite k¨onnen dabei sehr unterschiedlich sein und zwischen wenigen kbit/s und einigen Mbit/s f¨ ur Cloud-Gaming liegen. Ebenso divergieren die Anforderungen auf Serverseite stark. Die in [CLK+ 11, CBC+ 10, KPKB10] vorgestellten Spiele geh¨oren zur Gruppe der lokal ausgef¨ uhrten Server-unterst¨ utzten Spiele. In [KPKB10] wird beispielsweise das AR-Spiel PhotoShoot vorgstellt, bei dem sich zwei Spieler via Smartphonekamera gegenseitig in einem Fadenkreuz anvisieren und virtuell aufeinander schießen k¨onnen. Die Software erkennt dabei Treffer automatisch. Dabei wird ein Gesichtserkennungsalgorithmus auf einem entfernten Server ausgef¨ uhrt, da er lokal zu viele Ressourcen und Zeit ben¨otigen w¨ urde. Mobile Gaming ben¨ otigt die entfernten Server-Ressourcen je nach Anforderung des Benutzers zwischen wenigen Sekunden bis zu mehreren Minuten.

2.1.3 Desktop Anwendungen Weitere Anwendung von MCC ist die Bereitstellung von existierenden Desktop-Anwendungen f¨ ur Mobilger¨ ate. Dabei werden die Desktop-Anwendungen manchmal nicht portiert, sondern entfernt ausgef¨ uhrt und nur die Bildschirmausgabe und Interaktionen werden u ¨bertragen [SBCD09]. Die Applikation kann auch in einen lokalen und einen entfernt ausgef¨ uhrten Teil partitioniert werden [CIM+ 11]. Diese Anwendung ¨ahnelt dem Cloud-Gaming, stellt jedoch aufgrund der geringeren Bildschirmaktivit¨at oftmals nicht so hohe Anforderungen an ¨ die verf¨ ugbare Ubertragungsbandbreite. Im Fokus dieser Technologien stehen nicht nur die schnellere Ausf¨ uhrung von Applikationen, sondern oft auch die Bereitstellung von großen Speichermengen, sowohl Arbeitsspeicher als auch persistenter Speicher, was Mobilger¨ate nicht leisten k¨ onnen. Die Nutzungsdauer dieser Applikationen liegt im Minutenbereich bis hin zu einigen Stunden. Als Beispiele f¨ ur mobil genutzte Desktop-Anwendungen sind in der Literatur beispielsweise B¨ uroprogramme [SBCD09] oder ein Virus-Scanner [CIM+ 11] angegeben.

2.1.4 Zusammenfassung Anwendungscharakteristik Die betrachteten Applikationen unterscheiden sich in der Menge der u ¨bertragenen Daten, der Nutzungsdauer und der ben¨ otigten Ressourcen. F¨ ur die meisten Anwendungen sind jedoch bidirektionale Kommunikation, kurze Reaktionszeit oder eine relativ hohe Bandbreite sehr n¨ utzlich, um den Overhead f¨ ur die entfernte Ausf¨ uhrung gering zu halten. Hier wird erneut die Diskrepanz zwischen der technologischen Verf¨ ugbarkeit und den Anforderungen, die Nutzer

17

2 Verwandte Arbeiten

Name Cloudlets [SBCD09]

CloneCloud [CIM+ 11]

Maui [CBC+ 10]

Mars [CLK+ 11]

Cuckoo [KPKB10]

Tasklets [MPPS+ 12]

• Dienst wird auf einer VM in der N¨ ahe ausgef¨ uhrt • Sprachunabh¨ angig

Technologie

• Beschleunigung • Energieeinsparung

• Realisierung ressourcenhungriger Anwendungen

Intention

• m¨ oglich • nicht implementiert

• SSH • SASL

Security

• Virus-Scanner • Bildersuche • Verhaltensbeobachtung

• B¨ uroprogramme • Gimp • andere

Applikationen

• WLAN • 3G3

• WLAN

Netzwerk

• f¨ ur genannte Apps: Ausf¨ uhrungszeit und Energieaufnahme

• Benchmarks zur Bereitstellungszeit der Cloudlets

Evaluation

Tabelle 2.1: Eigenschaften verschiedener Frameworks f¨ ur Mobile (Cloud) Computing

• Application Level VM Clone • Java/Dalvik/.NET • Android

• WLAN • 3G3

• WLAN • 3G3

• Messungen mit Smartphone und Tablet • WLAN und 3G3 • Vergleich mit simulierten statischen RPC-Aufrufen

• Gesichtserkennung • Arcade Spiel

• WLAN • andere

• Applikationsbenchmarks der Objekterkennung mit WLAN

• k.A.1

¨ • Sprach-Ubersetzer

• Gesichtserkennung • AR2 • AR Videospiel

• Objekterkennung • verteiltes AR2 Spiel

• Bildeverarbeitung • Spracherkennung

• k.A.1

• Energieeinsparung

• Microsoft .NET • Windows Mobile

• nicht implementiert • zuk¨ unftige Arbeit

• k.A.1

• Beschleunigung

• k.A.1

• Beschleunigung • Energieeinsparung

• Beschleunigung

• k.A.1

• Energieeinsparung und Speedup f¨ ur Gesichtserkennung, Videospiel und Schachspiel

• RPC Mechanismus • Laufzeitsystem zur Optimierung der RPCAufruf-Entscheidungen • keine konkrete Technologie genannt, vermutlich Linux nach den Testger¨ aten zu urteilen • Java • Android • IBIS middleware

• entfernte Ausf¨ uhrung von kleinen abgeschlossenen Berechnungseinheiten (Tasklets)

1 (k.A.) = keine Angabe 2 (AR) = Augmented Reality 3 (3G) = Mobilfunknetzwerk der 3. Generation (beispielsweise UMTS und HSPA)

18

2.2 Realisierung von Mobile (Cloud) Computing Anwendungen

an mobile Applikationen stellen, deutlich. Zudem ist eine Anwendung in ubiquit¨ar verf¨ ugbaren Mobilfunknetzwerken nicht immer m¨oglich. Die u bertragenen Datenmenge liegen im kB bis ¨ MB Bereich. Außerdem ist die Leistungsf¨ahigkeit der ben¨otigten Serverressourcen als moderat einzusch¨ atzen. Somit k¨ onnen prinzipiell auch Cloud-Ressourcen zum Einsatz kommen. Teure Servermaschinen aus dem H¨ ochstleistungsrechnen sind nicht erforderlich. Die Performance der Server sollte jedoch relativ konstant sein. Die Nutzungsdauer der meisten Applikationen liegt im Minutenbereich.

2.2 Realisierung von Mobile (Cloud) Computing Anwendungen Aus technischer Sicht folgen die verschiedenen Frameworks und Middlewares f¨ ur MCC-Anwendungen unterschiedlichen Ans¨ atzen. Eine m¨ogliche Form der Unterscheidung kann bez¨ uglich der Art der Auslagerung von berechnungsintensiven Anwendungsteilen vorgenommen werden. Hierbei sind in der Literatur Ans¨atze zu finden, die ohne Modifizierung des Programm- und Quellcodes des eigentlichen Programms auskommen. Es gibt aber auch Ans¨atze, die eine explizite Partitionierung des Programms durch den Programmierer vorsehen. Die einzelnen Verfahren sind in Tabelle 2.1 zusammengefasst.

2.2.1 Verfahren ohne explizite Anpassung des Programmcodes Es gibt die M¨ oglichkeit, eine Applikation direkt in der Cloud“ auszuf¨ uhren und nur die ” Bildschirmausgabe auf das Mobilger¨at zu u ¨bertragen. Dieses Cloudlets genannte Verfahren wird in [SBCD09] vorgeschlagen. Hierbei l¨auft das Programm selbst komplett auf einer VM und nur die Benutzereingaben und die Bildschirmausgabe werden u og¨bertragen. Dies erm¨ licht auch sehr komplexe und speicherintensive Programme. Da jedoch relativ viele Daten u ussen, ist eine WLAN-Verbindung notwendig. Dar¨ uber hinaus ist hier¨bertragen werden m¨ bei eventuell auch der Datenaustausch zwischen Mobilger¨at und Server schwierig und m¨ usste u ¨ber ein separates gemeinsames Laufwerk wie beispielsweise Dropbox realisiert werden. Zur Verschl¨ usselung setzt Cloudlets SSH 1 und SASL2 ein. Bei dem in [CIM+ 11] vorgestellten CloneCloud wird eine Client-Instanz und eine ServerInstanz des gleichen Programms simultan ausgef¨ uhrt. Dabei werden wie in [CBC+ 10] nur Programme unterst¨ utzt, die in einer Application Level VM (beispielsweise .NET 3 oder Java4 VM ) ausgef¨ uhrt werden. Die in [CIM+ 11] vorgestellte Implementierung von CloneCloud 1

Die Secure Shell (SSH) bietet eine sichere M¨ oglichkeit, um sich in einen entfernten Rechner einzuloggen ” und diesen mittels Befehlszeile zu steuern bzw. Dateien auszutauschen. Dazu stellt der anfragende SSHClient zuallererst die Identit¨ at des entfernten Rechners sicher. Erst danach findet eine Authentifizierung des Benutzers statt. Die Daten¨ ubertragung zum entfernten Rechner l¨ auft gesichert (verschl¨ usselt und integrit¨ atsgesichert) ab.“ [BMB+ 05, S.400ff.] 2 Das Simple Authentication and Security Layer Rahmenwerk (SASL) stellt Mechanismen bereit, die eine ” einfache Integration von Authentifizierungsverfahren in verbindungsorientierte Kommunikationsprotokolle erm¨ oglichen.“ [BMB+ 05, S.428ff.] 3 .NET bezeichnet eine von Microsoft entwickelte Software-Plattform zur Entwicklung und Ausf¨ uhrung von ” Anwendungsprogrammen. .NET besteht aus einer Laufzeitumgebung (Common Language Runtime), in der die Programme ausgef¨ uhrt werden, sowie einer Sammlung von Klassenbibliotheken, Programmierschnittstellen und Dienstprogrammen (Services). .NET ist auf verschiedenen Plattformen verf¨ ugbar und unterst¨ utzt die Verwendung einer Vielzahl von Programmiersprachen. .NET-Programme werden zun¨ achst in eine Zwischensprache (Common Intermediate Language) u uhrt ¨bersetzt, bevor sie von der Laufzeitumgebung ausgef¨ werden.“ (Onlineressource http://de.wikipedia.org/wiki/.NET(abgerufen am 2.11.2013)) 4 Die Java Virtual Machine (abgek¨ urzt Java-VM oder JVM) ist der Teil der Java-Laufzeitumgebung (JRE) ”

19

2 Verwandte Arbeiten

benutzt Java und ist f¨ ur eine speziell angepasste Android -Version f¨ ur Mobilger¨ate verf¨ ugbar. Die Server-Instanz des Programms residiert dabei ebenfalls in einer Application Level VM . In regelm¨ aßigen Abst¨ anden werden zudem deren Zust¨ande synchronisiert. Bei berechnungsintensiven Aufgaben ist die Server-Instanz schneller fertig und synchronisiert den neuen Zustand, bevor die Client-Instanz den neuen Zustand selbst errechnet h¨atte. Dadurch lassen sich Ausf¨ uhrungszeit und Energieaufnahme des Mobilger¨ats verringern. Es ist nicht bekannt, welche Kommunikationstechnologie zur Synchronisation verwendet wurde. Bei dieser Variante, wie auch bei den in [SBCD09] vorgestellten Cloudlets, ist eine Server-Instanz dediziert einem einzigen Benutzer zugewiesen. Multiplexing von Anfragen auf eine VM und die Wiederverwendung der VM sind ausgeschlossen. F¨ ur jeden Benutzer und jedes Programm wird eine neue VM-Instanz gestartet. In [CBC+ 10] wird eine Technik zur dynamischen Partitionierung der Applikation zur Laufzeit, genannt Maui , vorgeschlagen. Dazu wird eine Laufzeitanalyse des Programms durchgef¨ uhrt und potenziell rechenintensive Teile werden erkannt und unter Ber¨ ucksichtigung der aktuell verf¨ ugbaren Netzwerkperformance auf einen Server ausgelagert. Dabei wird der serverseitig auszuf¨ uhrende Quellcode erst zur Laufzeit u ¨bertragen. Hierbei spricht man vom Code-Offloading. Vorteil ist hierbei auch, dass die universellen Server verschiedene Anwendungen auch gleichzeitig beherbergen k¨onnen. Damit die Laufzeitanalyse auch mit vorkompilierten Programmen funktioniert, k¨ onnen nur Programmiersprachen zum Einsatz kommen, die eine Application Level VM zur Code-Interpretation einsetzen, da die VM auch Selbst¨ uberwachungsfunktionen (Monitoring) bereitstellt. In [CBC+ 10] wird .NET verwendet. F¨ ur die Daten¨ ubertragung wird die spezifische effiziente Bibliotheksimplementierung .NET Remoting benutzt. .NET Remoting unterst¨ utzt, wie auch Java, Objektserialisierung. Dabei werden Objekte aus dem Speicher der Application Level VM direkt via Netzwerk versendet, sodass der Objektzustand auf der Gegenseite erhalten bleibt und das Objekt dort als Kopie erscheint. Leider macht die zugeh¨ orige Literatur keine Angaben u ¨ber die Sicherheitsmechanismen, die bei der Daten¨ ubertragung verwendet wurden.

2.2.2 Verfahren mit expliziter Client/Server Programmierung Teilt man eine Applikation in eine Server-Komponente und eine Client-Komponente, so spricht man von remote processing. Dabei werden Teile der Applikation beispielsweise durch einen entfernten Prozeduraufruf (englisch Remote Procedure Call (RPC)) vom Client aufgerufen. Eine Applikation zu partitionieren ist jedoch im Allgemeinen ein schwieriger Vorgang. Das liegt darin begr¨ undet, dass einzelne Applikationsteile Abh¨angigkeiten zueinander haben k¨onnen, die eine Aufteilung in getrennte Teile erschweren oder verhindern. Oft werden Graphalgorithmen, vor allem zum L¨ osen des MINCUT Problems [GJ79], benutzt, um diese Abh¨angigkeitsgraphen effizient zu partitionieren. Solche Algorithmen sind oft NP-vollst¨andig und somit nicht in polynomieller Laufzeit zu l¨osen. Deshalb wird die Partitionierung oft be¨ reits zur Ubersetzungszeit durchgef¨ uhrt. Diesen Ansatz verfolgen [CLK+ 11] und [KPKB10]. + In [CLK 11] werden Programmfragmente, die entfernt ausgef¨ uhrt werden sollen, vor dem f¨ ur Java-Programme, der f¨ ur die Ausf¨ uhrung des Java-Bytecodes verantwortlich ist .Der andere Teil der Java-Laufzeitumgebung sind die Java-Klassenbibliotheken. [...] Die Java Virtual Machine ist dazu da, den vom Java-Compiler erzeugten (plattformunabh¨ angigen) Bytecode plattformabh¨ angig auszuf¨ uhren. Dazu werden die erzeugten Bytecode-Dateien (Dateiendung .class“) w¨ ahrend der Laufzeit in die lokale Maschinen” sprache u ¨bersetzt.“ (Onlineressource http://de.wikipedia.org/wiki/Java_Virtual_Machine(abgerufen am 2.11.2013))

20

2.2 Realisierung von Mobile (Cloud) Computing Anwendungen

Kompilieren durch den Programmierer markiert. Zur Laufzeit wird dann entschieden, welche Programmfragmente entfernt ausgef¨ uhrt werden, um einen guten Performancegewinn und eine m¨oglichst hohe Energieeinsparung zu erreichen. Dabei wird die Technik des entfernten Prozeduraufrufs angewendet. Es wird davon ausgegangen, dass die via RPC verf¨ ugbaren Methoden auf Serverseite bereits vorhanden sind und nicht erst zur Laufzeit dort installiert werden. Das in [CLK+ 11] vorgestellte Mars wurde f¨ ur Linux-Ger¨ate mit ARM-Prozessor ¨ getestet. Uber die verwendeten Programmiersprachen und Kommunikationstechnologien ist nichts bekannt. In [KPKB10] wird Cuckoo vorgestellt, ein Offloading Framework f¨ ur Android -Applikationen, welches auf der IBIS Middleware basiert [PKKB09]. Vom Programmierer werden Funktionen spezifiziert, die entfernt ausgef¨ uhrt werden k¨onnen. Cuckoo entscheidet dann zur Laufzeit, ob lokal oder entfernt ausgef¨ uhrt wird. Dazu besitzt die Middleware auch eine ManagementKomponente, die aus einer Menge von verf¨ ugbaren Compute-Ressourcen ausw¨ahlen kann. Die Ressourcen m¨ ussen der Middleware jedoch explizit bekannt gemacht werden. Eine zentrale Registry existiert nicht. Java-Code kann zur Laufzeit auf einer Compute-Ressource installiert werden. Daf¨ ur bietet die Ressource einen speziellen Port an. Zur Kommunikation wird die aus dem wissenschaftlichen Rechnen bekannte effiziente Kommunikationsbibliothek SmartSockets von IBIS benutzt, welche die effiziente Nutzung der verf¨ ugbaren Netzwerkbandbreite erleichtert [PKKB09]. Das Verzichten auf Sicherheitsmechanismen wird explizit genannt und deren Integration wird als zuk¨ unftige Arbeit angegeben.

2.2.3 Zusammenfassung Realisierung von MCC-Anwendungen Eine Laufzeitanalyse und Partitionierung zur Laufzeit erm¨oglichen zwar die verteilte Ausf¨ uhrung von unmodifizierten Programmen, jedoch erfordern sie auch eine entsprechend angepasste Laufzeitumgebung. Dies schr¨ ankt vor allem seitens des mobilen Endger¨ates die Anwendbarkeit dieses Ansatzes stark ein, da man dort kaum M¨oglichkeiten hat, die Softwareinstallation anzupassen. Um eine breite Anwendbarkeit sicherzustellen, ist eine vorpartitionierte Variante besser, die durch Bibliotheksunterst¨ utzung dann eingeschr¨ankte Entscheidungen zur Laufzeit treffen kann. Existierende Ans¨ atze zur Auslagerung beschr¨anken sich auf Betrachtungen zum Speedup, zur m¨oglichen Energieeinsparung auf dem mobilen Ger¨at und auf M¨oglichkeiten der Ent¨ scheidungsfindung, wann ausgelagert werden soll und wann nicht. Ublicherweise wird dabei davon ausgegangen, dass f¨ ur jeden Nutzer eine dedizierte Servermaschine bereitsteht. Diese Annahme ist jedoch mit vielen Nutzern kaum mehr zu rechtfertigen. Nur in [MPPS+ 12] wird die Allokation von Ressourcen auf ¨ offentlich verf¨ ugbarer Infrastruktur in Betracht gezogen. Das darin vorgeschlagene Konzept der Tasklets ist jedoch nur knapp beschrieben. Konkrete Mechanismen und Zielumgebungen sind nicht genannt, weshalb dieses Konzept den beschriebenen Kategorien nicht zugeordnet werden konnte. Manche der vorgestellten Technologien sind nur f¨ ur WLAN praktikabel. Andere unterst¨ utzen auch 3G oder andere Kommunikationstechnologien (siehe Tabelle 2.1). Manche Verfahren realisieren die entfernte Ausf¨ uhrung des Programmcodes in Abh¨angigkeit der verf¨ ugbaren Netzwerkperformance. Es wird jedoch bei keinem Verfahren darauf eingegangen, wie die Netzwerkperformance bestimmt wurde und wie die Entscheidungsfindung im Detail implementiert ist.

21

2 Verwandte Arbeiten

2.3 MCC aus Sicht der Cloud-Infrastruktur Die von den vorgestellten Technologien genutzten Server-Ressourcen m¨ ussen zun¨achst bereitgestellt werden und den einzelnen Clients zur Laufzeit auch zugewiesen werden. Man spricht von Ressourcenallokation. Hierbei gibt es zentral angelegte Middlewares, die einen einzelnen Front-Server benutzen, um Ressourcen f¨ ur die Clients zu allokieren. Es gibt jedoch auch dezentrale Verfahren, bei denen die Clients selbst versuchen, Ressourcen in ihrer Umgebung zu allokieren.

2.3.1 MCC-Architekturen In der Literatur finden sich von abstrakten Beschreibungen ganzer Paradigmen u ¨ber Architekturen mit einer konkreten Implementierung bis hin zu speziellen Cloud-basierten Middlewares die verschiedensten Ans¨ atze, um Cloud-basierte Compute-Dienste auf feingranularer Basis bereitzustellen. MCC-Architekturen sind im Allgemeinen zweischichtige Architekturen bestehend aus Client und Compute-Server. Dagegen ist die typische Web-Architektur dreischichtig, bestehend aus Client, Webserver und Datenbank. Die Datenhaltungskomponente spielte im MCC nur eine untergeordnete Rolle, da die zu verarbeitenden Daten ohnehin erst vom Client auf den Compute-Server u ussen. ¨bertragen werden m¨ In [FE10] wird [email protected] vorgestellt, eine neuartige Anwendung des @Home-Paradigmas aus dem Volunteer Computing auf Technologien des Cloud Computings. Ziel dabei ist es, konfigurierbare Compute-Ressourcen auf feingranularer Basis zur Verf¨ ugung zu stellen. Dabei werden explizit auch mobile Einsatzzwecke genannt. Beim Volunteer Computing k¨onnen Nutzer eigene ungenutzte Rechenkapazit¨aten f¨ ur eine rechenintensive Aufgabe zur Verf¨ ugung 5 stellen. Ein sehr bekanntes Projekt aus diesem Bereich ist beispielsweise [email protected] . The [email protected] motto ” Clouds.“[FE10, S.581]

is:

heterogeneous

hardware

for

homogeneous

Um dies zu erm¨ oglichen, ist [email protected] in die Schichten Frontend Layer, Virtual Layer und Physical Layer eingeteilt. Dabei vermittelt und verwaltet der Frontend Layer Ressourcen aus dem Virtual Layer. Zur Verf¨ ugung stehen die virtuellen Ressourcen storage und execution. Das @Home bedeutet hier, dass beliebige Maschinen, so auch Desktop-Computer, in den Physical Layer eingebunden werden k¨ onnen. Es wird jedoch nur ein abstraktes Konzept vorgestellt, das keine Aussagen dar¨ uber macht, ob beliebige VM Images (beispielsweise 32bit und 64bit) auf allen Ressourcen lauff¨ ahig sind oder ob die Resource Engine f¨ ur VM Images eine Vorauswahl an Anbietern trifft, auf denen die Images tats¨achlich lauff¨ahig sind. Obwohl das System auf Volunteer Computing aufsetzt, ist auff¨allig, dass keine Behandlung von FirewallProblemen, wie sie im privaten Bereich durch NAT-Router oder Betriebssystem-Firewalls h¨aufig auftreten, Bedeutung beigemessen wird. Zentrale Verfahren zur Ressourcenallokation setzen einen Front-Server oder Broker-Server ein. Dies hat den Nachteil, dass es einen Single Point of Failure gibt, der bei Ausfall das ge5

[email protected] ist ein wissenschaftliches Experiment, welches mit dem Internet verbundene Computer f¨ ur ” die Suche nach außerirdischer Intelligenz einsetzt. SETI (Search for Extraterrestrial Intelligence) ist ein wissenschaftliches Aufgabenfeld mit dem Ziel außerirdisches Leben zu finden. Eine Herangehensweise, bekannt als radio SETI, nutzt Radioteleskope, um nach schmalbandigen Funksignalen aus dem Weltraum zu suchen.“ (Onlineressource http://setiathome.berkeley.edu/sah_about.php (abgerufen am 2.11.2013))

22

2.3 MCC aus Sicht der Cloud-Infrastruktur

samte System unbenutzbar macht. Ein Ausfall kann beispielsweise durch eine DoS Attacke6 ausgel¨ost werden. Des Weiteren liegen Cloud-Rechenzentrum und Client eventuell weit entfernt voneinander, was zu hohen Netzwerklatenzen f¨ uhren kann. Um genau diese hohen Netzwerklatenzen zu vermeiden und um das System robuster gegen Angriffe zu machen, wurden auch dezentrale Technologien erforscht, die eine Compute-Ressource im lokalen Umfeld eines Client benutzen. Dabei befindet sich in [SF05] die Ressource direkt am WLAN Accesspoint. Ein sogenannter home server, der f¨ ur den Client immer erreichbar ist, migriert zur Laufzeit eine VM-Instanz auf einen lokal verf¨ ugbaren Server. Eine Spracherkennungs- und eine Remote-Desktop-Software konnten durch dieses System deutlich beschleunigt werden. Hierbei kann zwar hohe Netzwerkbandbreite sichergestellt werden, jedoch ist diese Technologie beispielsweise nicht auf 3G Netzwerke anwendbar. Auch Authentifizierung und Abrechnung sind in dezentralen Netzwerken mit hohem Aufwand verbunden. Zudem ist die Verf¨ ugbarkeit bestimmter Ressourcen nicht so gut sichergestellt wie bei einem zentralisierten System. Eine zentralisierte Middleware, die innerhalb einer Cloud-Infrastruktur, beispielsweise Amazon EC2 , ausgef¨ uhrt wird, bietet den Vorteil, dass sie sehr gut verf¨ ugbare und durch entsprechende horizontale Skalierung gen¨ ugend Ressourcen vorhalten kann, um Benutzeranfragen auf gleichbleibendem Niveau zu befriedigen. Ein solches System wird in [MPPS+ 12] vorgeschlagen. Zudem liegen die verf¨ ugbaren Ressourcen eines IaaS-Anbieters u ¨blicherweise in definierten Qualit¨ atsstufen vor. Zur Allokation der Ressourcen wird ein Broker eingesetzt, der Ressourcen an anfragende Clients vermittelt. Zudem kann u ¨ber diesen Broker auch die Authentifizierung und Abrechnung der Nutzung erfolgen. In [MPPS+ 12] wird Vision vorgestellt, eine Ausf¨ uhrungsplattform f¨ ur Tasklets, die zwischen PaaS- und IaaS-Schicht angesiedelt ist. Die vorgestellte Middleware behandelt ein Tasklet als abgeschlossene Berechnungseinheit, die durch einen sogenannten Tasklet Trading Service (TTS) auf eine passende Ressource zugewiesen werden kann. Dieser Trading Service ist ¨ahnlich dem CORBA Trading Service, unterscheidet sich von diesem jedoch dadurch, dass der (gehandelte) Dienst generisch ist und beliebige Tasklets ausf¨ uhren kann, also nur Compute-Ressourcen anbietet. Vision ist der in dieser Arbeit vorgestellten Middleware hinsichtlich der angestrebten Ziele ¨ahnlich (siehe Kapitel 1.2). Weitere Informationen zu Vision konnten jedoch aus der dar¨ uber verf¨ ugbaren Literatur nicht beschafft werden. Dies betrifft insbesondere Angaben zu den Anwendungsszenarien und Implementierungstechnologien. Somit konnte auch keine vergleichende Bewertung durchgef¨ uhrt werden.

2.3.2 Eigenschaften von Diensten auf Cloud-Infrastrukturschicht IaaS-Anbieter erm¨ oglichen das Mieten von virtuellen Maschinen (VMs) in verschiedenen Konfigurationen. Da die Vorstellung der einzelnen Konfigurationen der am Markt o¨ffentlich verf¨ ugbaren Cloud-Anbieter hier zu weit f¨ uhren w¨ urde, sind deren spezifische Eigenschaften in Anhang B zusammengefasst. Nachfolgend werden verschiedene Dienste auf Infrastrukturschicht allgemein vorgestellt. 6

Als Denial of Service (kurz DoS, englisch f¨ ur: Dienstverweigerung) wird in der digitalen Datenverarbeitung ” die Nichtverf¨ ugbarkeit eines Dienstes bezeichnet, der eigentlich verf¨ ugbar sein sollte. Obwohl es verschiedene Gr¨ unde f¨ ur die Nichtverf¨ ugbarkeit geben kann, spricht man von DoS in der Regel als die Folge einer ¨ ¨ Uberlastung von Infrastruktursystemen. Dies kann durch unbeabsichtigte Uberlastungen verursacht werden oder durch einen mutwilligen Angriff auf einen Server, einen Rechner oder sonstige Komponenten in einem Datennetz.“ (Onlineressource http://de.wikipedia.org/wiki/Denial_of_Service (abgerufen am 2.11.2013))

23

2 Verwandte Arbeiten

IaaS-Anbieter wie Amazon EC2 , Rackspace und Elastic Hosts betreiben dazu Rechenzentren an verschiedenen Standorten weltweit. Amazon EC2 und Rackspace bieten feste Konfigurationen von VM-Typen an. Bei Elastic Hosts kann der Kunde hingegen selbst die CPUKernanzahl, Arbeitsspeicher und weitere Parameter konfigurieren. Auch die Abrechnungsmodelle unterscheiden sich stark. Die Bezahlung erfolgt u ¨blicherweise nach Verbrauch (pay-asyou-go), aber auch Prepaid -Modelle werden vereinzelt angeboten. Amazon EC2 bietet zudem beispielsweise drei verschiedene Mietmodelle an. Die sogenannten On-Demand -Instanzen werden pro Stunde gemietet und pro Stunde bezahlt. Dies Variante ist immer garantiert verf¨ ugbar und sehr flexibel abzurechnen, f¨ uhrt in der Regel aber auch zu den h¨ochsten Kosten. Ben¨otigt man hingegen einfach nur Rechenzeit, die keinen zeitlichen Beschr¨ankungen unterliegt, so kann man Spot-Instanzen mieten, deren Preis sich nach marktwirtschaftlichen Regeln auf Basis von Angebote und Nachfrage in kurzen Abst¨anden ¨andert. Um eine Instanz zu erhalten, muss man einen Preis bieten. Liegt dieser u ur den ¨ber dem momentanen Marktpreis f¨ VM-Typ, so erh¨ alt man die Instanz zum aktuellen Marktpreis. Spot-Instanzen k¨onnen jedoch jederzeit unterbrochen werden, beispielsweise wenn der aktuelle Marktpreis das H¨ochstgebot u ur ausfalltolerante Anwendungen, wie etwa Datenanalyse, ge¨bersteigt. Sie sind deshalb nur f¨ eignet. Außerdem gibt es noch Reserved -Instanzen. Diese sind ebenfalls garantiert verf¨ ugbar und werden pro Stunde abgerechnet, jedoch wird f¨ ur die Nutzung ein Vertrag u ¨ber 1–3 Jahre geschlossen und eine Vorabgeb¨ uhr gezahlt. Im Gegenzug verbilligen sich dadurch die Nutzungskosten pro Stunde erheblich, sodass diese Variante f¨ ur h¨aufig genutzte und garantiert verf¨ ugbare Anwendungen die beste L¨ osung darstellt. Jeder IaaS-Anbieter hat eigene Abrechnungsmodelle. F¨ ur die jeweilige Applikation muss demnach von Fall zu Fall neu entschieden werden, welcher Anbieter die g¨ unstigste L¨osung bietet. Das Betriebssystem nebst Softwarestack der Cloud-Applikation wird auf einem VM-Image gespeichert, welches von der VM-Instanz ausgef¨ uhrt wird. Jeder Nutzer kann den aktuellen Zustand einer VM als Images speichern, dies wird oft als Snapshot bezeichnet. Alle IaaS-Anbieter stellen Vorgabeimages mit h¨aufig verwendeten Betriebssystemen und Software bereit. Manche Anbieter erlauben auch das Installieren beliebiger Systeme. Alle in Anhang B aufgef¨ uhrten Anbieter unterst¨ utzen Linux-Images. Viele bieten auch Windows-Images an, die oft etwas teurer sind. In der Regel kann ein VM-Image auf Instanzen verschiedenen Typs ausgef¨ uhrt werden. Dies gilt jedoch nur, solange die darunter liegende Virtualisierungstechnologie die gleiche ist. Amazon EC2 bietet beispielsweise paravirtualisierte Instanzen und hardwarevirtualisierte Instanzen an. Bei beiden Varianten wird ein Hypervisor verwendet, um beispielsweise den Zugriff auf die verschiedenen Hauptspeicherpartitionen der VM-Instanzen zu regeln. Der Hypervisor fungiert als eine Art Hardwarevermittler f¨ ur die Gastbetriebssysteme. Von Amazon EC2 wird die Virtualisierungstechnologie Xen 7 verwendet [LYKZ10]. Bei der Paravirtualisierung ist hierf¨ ur eine Anpassung des Betriebssystems n¨otig. Bei der Hardwarevirtualisierung ist dies nicht n¨ otig, daf¨ ur m¨ ussen jedoch spezielle Prozessorerweiterungen vor¨ handen sein. Eine Ubersicht u ¨ber verschiedene Virtualisierungstechnologien ist beispielsweise in [RHFN+ 12] zu finden. VM-Images in Amazon EC2 (Amazon Machine Images (AMIs)) k¨onnen jeweils nur auf einer Virtualisierungstechnologie ausgef¨ uhrt werden. Neuere hardwarevirtualisierte Instanzen erlauben den Zugriff auf die Hardware der entsprechenden Maschine. 7

Xen ist ein Hypervisor, eine Software, die den Betrieb mehrerer virtueller Maschinen auf einem physischen Computer erlaubt. Xen entstand an der britischen University of Cambridge. Xen wurde von Beginn an f¨ ur beste Performance optimiert und konnte dies auch gegen¨ uber anderen Virtualisierungstechnologien unter Beweis stellen. (siehe [BDF+ 03])

24

2.3 MCC aus Sicht der Cloud-Infrastruktur

Dies wird beispielsweise beim Zugriff auf die Grafikkarte f¨ ur GPU-unterst¨ utzte Applikationen ben¨otigt. F¨ ur den in diese Arbeit notwendigen Softwarestack mit Verwendung von Java, sind einfach ausgestattete Linux-Instanzen und eine darauf installierte Java-Laufzeitumgebung ausreichend. Amazon EC2 stellt f¨ ur solche Aufgaben eigene VM-Images mit einer Amazon Linux Distribution zur Verf¨ ugung. Diese beinhalten nur den n¨otigsten Softwarestack und schließen bereits die zur Verwaltung notwendigen Kommandozeilenwerkzeuge zum Ansprechen der Amazon EC2 -API ein. Außerdem bieten IaaS-Anbieter weitere Dienste an. Beispielsweise k¨onnen VM-Instanzen zur allgemeinen Verf¨ ugbarkeit mit statischen IP-Adressen versehen werden. Weiterhin k¨onnen virtuelle Lans (VLANs) eingerichtet werden, um Cloud-Ressourcen direkt in ein Unternehmensinternes Netzwerk einzugliedern. Zus¨atzlich kann eine Firewall konfiguriert werden, um die Cloud-Ressourcen abzuschotten. Abschließend ist es zudem m¨oglich ein Monitoring an die gemieteten Instanzen anzuheften, welches bei bestimmten Lastzust¨anden Alarm ausl¨ost. Jeder Anbieter stellt diese Zusatzdienste in verschiedener Auspr¨agung, Qualit¨at und Kosten zur Verf¨ ugung. Somit ist auch hier von Fall zu Fall zu entscheiden, welche Eigenschaften ben¨otigt werden und welche Kosten daf¨ ur anfallen.

2.3.3 Lastbalancierung und Skalierungsmethoden Die QoS eines Cloud-Dienstes sollte unabh¨angig von der Anzahl gleichzeitiger Nutzeranfragen sein. In der Schichteneinteilung der Cloud-Dienste gibt es die Plattform-Dienste (PaaS), die es erm¨oglichen, Software zu schreiben, die Lastbalancierung und Skalierung der Ressourcen automatisch implementiert. Cloud-Anbieter, die eine PaaS anbieten, skalieren selbstst¨andig die ben¨otigten Ressourcen, die notwendig sind, um die f¨ ur den Nutzer gehostete Applikation innerhalb der vereinbarten Parameter (SLA) zu betreiben. Dabei werden, wie etwa bei Googles App Engine, Geb¨ uhren f¨ ur jede einzelne Anfrage an die Applikation erhoben. Im Vergleich dazu werden bei IaaS-Anbietern im Allgemeinen Geb¨ uhren f¨ ur jede Stunde Nutzungsdauer einer laufenden virtuellen Maschine erhoben, zuz¨ uglich Kosten f¨ ur Speicher und Daten¨ ubertragung via Netzwerk. Das PaaS Modell ist zwar relativ feingranular, bietet aber auch kaum M¨ oglichkeiten der Einflussnahme, wie beispielweise eine situationsangepasste Bearbeitungsgeschwindigkeit. Das IaaS-Modell ist sehr grobgranular, bietet daf¨ ur aber das h¨ochste Maß an Konfigurierbarkeit im Cloud-Schichtmodell. Dazu bietet die IaaS-Schicht die M¨oglichkeit, die Anzahl der Ressourcen, die serverseitig genutzt werden, an die jeweilige Anfragemenge anzupassen. Bei dieser mengenm¨ aßigen Anpassung spricht man von horizontalem Skalieren. Skalierbarkeit wird wie folgt beschrieben: Im Allgemeinen bezeichnen wir Systemarchitekturen als skalierbar, wenn sie sich je” dem zuk¨ unftigen Lastzuwachs anpassen k¨ onnen, sei er erwartet oder nicht.“[Emm03, S. 22] Eine SaaS ist also besonders gut skalierbar, wenn sie in der Lage ist, durch Vergr¨oßerung der bereitgestellten Ressourcen einen m¨oglichst proportional gr¨oßeren Anfragedurchsatz zu erzielen und wenn die Skalierung so funktioniert, dass der m¨ogliche Anfragedurchsatz zu jedem Zeitpunkt in etwa dem tats¨ achlichen Anfrageverhalten entspricht. Dem gegen¨ uber spricht man von vertikalem Skalieren, wenn man nicht die Anzahl von Ressourcen ver¨andert, sondern deren individuelle Geschwindigkeit. Man kann eine VM dazu beispielsweise auf eine performantere

25

2 Verwandte Arbeiten

Hardware migrieren. Da das Anfrageverhalten vorweg nicht bekannt ist, kann eine optimale Ressourcennutzung nicht garantiert werden. Durch Anwendung von Heuristiken wird jedoch stets versucht das Optimum zu erreichen. Ziel einer horizontalen Skalierung ist es, immer gerade so viele Server wie n¨otig verf¨ ugbar zu haben. Um dies zu gew¨ ahrleisten, schaltet man auch Maschinen ab, wenn sie nicht mehr ben¨otigt werden. Um eine Entscheidung bez¨ uglich der Aufw¨arts- und Abw¨artsskalierung zu treffen, kann man beispielsweise die mittlere Server-Auslastung messen. Steigt diese u ¨ber 80%, skaliert man nach oben, f¨ allt sie unter 20%, skaliert man nach unten. Dieses Verfahren ist jedoch recht tr¨ age, da es erst reagiert, wenn es oft schon sehr sp¨at ist [CRB11]. Es dauert einige Minuten, bis neue Maschinen gestartet sind. Daher k¨onnen auch vorausschauende Verfahren angewendet werden, die aus dem aktuellen Anstieg der Server-Auslastung eine Prognose f¨ ur den Zeitpunkt geben, zu dem die neuen Maschinen schon gestartet sind. Ein solches Verfahren ist in [GGW10] beschrieben. Prognosealgorithmen werden h¨aufig auch mit maschinellem Lernen kombiniert, um nicht nur aus den aktuellen Daten, sondern auch aus vorangegangenen Messungen eine Prognose zu erstellen [RDG11]. Die Auswahl der Lastbalancierungsstrategie richtet sich auch nach der L¨ange und Komplexit¨at der Anfragen. Ziel der Lastbalancierung ist es, alle Anfragen so auf die verf¨ ugbaren Server zu verteilen, dass diese m¨ oglichst gleichm¨aßig ausgelastet sind. Einfache Web-Anfragen k¨onnen dabei oft ad hoc verteilt werden. Komplexe Anfragen, die zus¨atzlich eine Datenbankabfrage ausl¨ osen, sind schwieriger zu balancieren. Hierbei handelt es sich um Mehr-SchichtArchitekturen, die eine Anfrage in mehrere kleinere Anfragen aufsplitten, welche f¨ ur sich zus¨atzlich balanciert werden m¨ ussen. F¨ ur die hier betrachteten berechnungsintensiven Anwendungen sind einfache Anfragen zu erwarten, die sich jedoch in ihrer L¨ange unterscheiden k¨onnen. Solche Anfragen lassen sich oft auch als unabh¨angige Tasks formulieren. Somit k¨onnen zur Lastbalancierung auch Algorithmen aus den Bereichen Task-Scheduling und JobScheduling zum Einsatz kommen [OK10]. Cloud Computing erlaubt dabei aufgrund seiner marktwirtschaftlichen Ausrichtung zus¨atzliche Optimierungen beispielsweise auf Kosteneffizienz anstatt auf Geschwindigkeit. In Bezug auf MCC-Anwendungen wird von einzelnen spontan auftretenden Anfragen ausge¨ gangen. Scheduling und Lastbalancierung werden somit online durchgef¨ uhrt. Ein Uberblick u ur Online Scheduling ist beispielsweise in [Leu04] zu finden. ¨ber verschiedene Techniken f¨ Je nach Charakteristik der einzelnen Anfragen sind verschiedene Lastbalancierungsstragien m¨oglich. Haben alle Anfragen etwa die gleiche Bearbeitungsdauer, so wird das RundlaufVerfahren (englisch Round-Robin) angewendet und die Anfragen werden reihum auf die verf¨ ugbaren Server verteilt. Unterscheiden sich die Anfragen hingegen in der L¨ange, f¨ uhrt das Rundlauf-Verfahren nicht mehr zu einer gleichm¨aßigen Auslastung. Man teilt neue Anfragen in diesem Fall immer dem Server mit der geringsten Anzahl aktuell aktiver Anfragen zu. Man nennt dieses Verfahren Shortes Queue First [CM99]. Auch stochastische Verfahren, die die Anfragen per Zufall mit definierten Wahrscheinlichkeiten verteilen, sind m¨oglich [FHR09]. Unter Verwendung von Infrastrukturdiensten eines IaaS-Anbieters m¨ ussen Lastbalancierungsund Skalierungsmethoden f¨ ur darauf aufbauende Applikationen stets gemeinsam betrachtet werden. Im Vergleich zu anderen Technologien, wie Grid oder einem traditionellen Rechenzentrum, beeinflussen sich beide Methoden wechselseitig. Beispielsweise h¨angen Skalierungsalgorithmen oft von der Serverauslastung ab, welche wiederum durch die Lastbalancierung beeinflusst wird.

26

2.3 MCC aus Sicht der Cloud-Infrastruktur

2.3.4 Cloud-QoS und Monitoring Im Vergleich zu traditionellen Rechenzentren hat sich die Art des Aushandelns und Festschreibens der Dienstqualit¨ at zwischen Anbieter und Benutzer stark ge¨andert. Das self-service Prinzip im Cloud Computing stellt f¨ ur alle Benutzer gleichermaßen ein Service-Level-Agreement zur Verf¨ ugung und ersetzt damit das separate Aushandeln mit einzelnen Benutzern [Sos10]. Was f¨ ur den Anbieter aus ¨ okonomischer Sicht Vorteile bringen kann, kann den Benutzer aber auch Flexibilit¨ at kosten, da er beispielsweise die Verf¨ ugbarkeit nicht mehr nach seinen Bed¨ urfnissen aushandeln kann. Der Benutzer muss in diesem Fall nehmen, was ihm der Anbieter anbietet. Dar¨ uber hinaus sind bei Verletzung der SLA durch den Anbieter u ¨blicherweise auch ¨ keine Strafzahlungen vorgesehen. Außerdem l¨asst sich ein Monitoring zur Uberwachung der SLA im Cloud-Bereich auch schwer implementieren. Hier stellt sich beispielsweise die Frage, ob Maschinen des gleichen Typs auch immer die gleiche Performance aufweisen. Daraus ergibt sich, dass die einzelnen Anbieter auf dem Cloud-Markt auch immer mehr mit ihrer Reputation werben m¨ ussen. Kunden werden also nicht nur den Preis und die gebotene Leistung der einzelnen Anbieter vergleichen. Sie werden auch vergleichen, wie stabil die einzelnen Anbieter ihre Leistung anbieten. Dem gegen¨ uber steht jedoch auch die bereits beschriebene Schwierigkeit, einen einmal ausgew¨ ahlten Anbieter zu verlassen und zu einem anderen Anbieter zu migrieren (Vendor Lock-in). Services sollten vor allem im Cloud-Umfeld einen Service-Lebenszyklus und autonomes Management unterst¨ utzen. Der Service-Lebenszyklus ist teil des SLA Managements. In [WBTY11, S. 13ff.] werden dazu verschiedene Stationen eines Lebenszyklus beschrieben: 1. Desgin and Development – Entwicklung des Dienstes durch Anbieter, 2. Service Offering – Anbieten des Dienstes via Datenblatt, Werbung, etc., 3. Service Negotiation – Aushandeln der Konditionen mit dem Benutzer, 4. Service Provisioning – Bereitstellen des Dienstes f¨ ur den Benutzer, 5. Service Operations – Verwendung des Dienstes durch den Benutzer, 6. Service Decommissioning – Abschalten des Dienstes durch den Anbieter. Das Projekt [email protected] befasst sich mit der Realisierung dieser Anforderungen zur Unterst¨ utzung Cloud-basierter Business-Anwendungen. In diesem Zusammenhang wird oftmals auch ein Service-Broker eingesetzt, um f¨ ur den Benutzer einen dessen Anforderungen entsprechenden Service zu vermitteln. Die in [FE10, S. 575ff.] beschriebene und bereits weiter oben erw¨ahnte Technologie [email protected] vermittelt Compute-Ressourcen an Benutzer in mehreren Schritten. Zun¨ achst wird der Benutzer authentifiziert. Danach u ¨bersendet der Nutzer einen Computing Request mit den zugeh¨origen Anforderungen und der gew¨ unschten Qualit¨ at (SLA). Das System beantwortet den Request und allokiert eine passende VM f¨ ur den Benutzer. Die eigentliche Nutzung der VM erfolgt dann direkt durch Nutzer, ohne dass weitere Dienste der [email protected] Umgebung in Anspruch genommen werden m¨ ussen. Die Literatur macht jedoch keine Angaben, welche Anforderungen und Qualit¨atsstufen vom Benutzer spezifiziert werden k¨ onnen und auch nicht, wie danach eine geeignete VM gefunden und allokiert wird. Außerdem wird keine Aussage dar¨ uber getroffen, wie eine nicht mehr genutzte VM vom Benutzer an das System zur¨ uckgegeben wird.

27

2 Verwandte Arbeiten

Autonomes Service Management bedeutet im Cloud-Umfeld nicht nur das selbstst¨andige Aushandeln von SLAs zwischen Benutzer und Anbieter unter gegebenen Anforderungen, sondern auch eine Rekonfigurierung im Fehlerfalle oder die Reaktion auf Verletzungen der SLA. Eine große Herausforderung im Cloud-Umfeld ist die Durchsetzung der SLA beziehungsweise ¨ deren Uberwachung. In [WBTY11, S. 105ff.] wird eine Cloud-kompatible Variante des SLA Penalty Managements beschrieben. Zun¨achst m¨ ussen Monitoring-Parameter definiert werden, die dann w¨ ahrend der Service Operations Phase u ¨berwacht werden k¨onnen. In gewissen Abst¨anden werden die gesammelten Daten dann ausgewertet und auf die Verletzung von vorher definierten SLA-Parametern untersucht. Tritt eine solche Verletzung auf, wird sie in einem weiteren Schritt bearbeitet. Als Monitoring-Parameter wird oftmals die Service-Antwortzeit benutzt. Das sogenannte Penalty Management entscheidet dann, wie zu verfahren ist. Gegebenenfalls sind auch mehrere Verletzungen pro Zeiteinheit n¨otig, um eine Aktion auszul¨osen. Eine g¨angige L¨ osung besteht darin, den Service, der die Verletzung verursacht hat, auf eine andere Ressource zu migrieren. Dies kann gegebenenfalls auch die Migration zu einem anderen Anbieter bedeuten. Dazu muss der Dienst jedoch bei einem anderen Anbieter auch verf¨ ugbar sein.

2.3.5 Zusammenfassung MCC-Infrastruktur Aus Sicht des MCC ist eine zentrale Middleware, die auf einer IaaS-Umgebung aufgebaut ist, oft die bessere Wahl zur Bereitstellung feingranularer Compute-Ressourcen. Im Vergleich zu einer dezentral organisierten Middleware ist die Qualit¨at der Ressourcen genauer definiert und deren Verf¨ ugbarkeit ist in der Regel besser. Der Nachteil der recht hohen Latenzen impliziert jedoch die Einschr¨ ankung auf MCC-Anwendungen, die keine schnellen Reaktionszeiten erfordern. Die Vermittlung von Compute-Ressourcen muss durch einen Front-Server erfolgen, wenn eine Zugangskontrolle und Abrechnung der Nutzung der Ressourcen erfolgen soll. Die Verwendung eines Front-Server ist zudem notwendig, um eine Lastbalancierung bei der Allokation der verf¨ ugbaren Ressourcen zu gew¨ahrleisten. Die dabei favorisierte Variante weist einen Client fest auf eine dedizierte Ressource zu, die der Client danach direkt anspricht. Die dabei auftretende Schwachstelle des System bei Ausfall des Front-Servers kann nur durch redundante Auslegung dieses Servers vermieden werden. Jede Cloud-Ressource sollte zudem ein Monitoring implementieren, um einerseits die Abrechnung der Nutzungsdauer zu realisieren und andererseits auch die Performance der einzelnen Ressourcen zu u ¨berwachen. Da die SLAs der verf¨ ugbaren ¨ offentlichen IaaS-Anbieter eine Bestrafung von SLA-Verletzungen nicht vorsehen, m¨ usste man diese Bestrafung selbst implementieren. Dazu sollte die MCCInfrastruktur mehrere IaaS umfassen. Dann kann man im Rahmen einer SLA-Verletzung den Dienst auf einen anderen IaaS-Anbieter migrieren, der beispielsweise aufgrund von erhobenen Messdaten eine konstantere Dienstqualit¨at liefert.

2.4 Fazit Von den in diesem Kapitel vorgestellten Arbeiten, die unter dem Schlagwort MCC zu finden sind, betrachten nur [MPPS+ 12, KPKB10] auch die Allokation der ben¨otigten CloudRessourcen. Alle Arbeiten aus der betrachteten Literatur k¨onnen jedoch lokal verf¨ ugbare Serverressourcen nutzen. Die Verwendung von Fl¨achenkommunikationsnetzen (beispielsweise 3G Mobilfunk) ist nicht u oglich. Manche Ans¨atze sind nur mit WLAN nutzbar. ¨berall m¨

28

2.4 Fazit

Somit ist die breite Anwendbarkeit der vorgestellten Arbeiten nicht sichergestellt. Auch die Abrechnung der Nutzungskosten f¨ ur Cloud-Ressourcen und die daf¨ ur notwendige Integration einer Benutzerverwaltung werden von keinem der vorgestellten Ans¨atze betrachtet. Außerdem wird die Allokation von entfernt verf¨ ugbaren Ressourcen verschiedener Qualit¨at in den betrachteten Arbeiten nicht unterst¨ utzt. Im Ergebnis konnte somit keine Arbeit aus der Literatur identifiziert werden, die den Anforderungen dieser Arbeit gerecht wird. Deshalb werden in dieser Arbeit im Nachfolgenden zumeist eigene Techniken erarbeitet, um die gestellten Anforderungen zu erf¨ ullen. Bez¨ uglich der Anforderung einer breiten Anwendbarkeit von Mobilen Cloud-unterst¨ utzten Anwendungen unter Verwendung von ¨offentlicher Cloud-Infrastruktur sind nur Techniken anwendbar, die keine Modifikationen an vorhandenen Ger¨aten oder deren Betriebssystem erfordern. Somit scheiden Ans¨ atze aus, die eine automatische Partitionierung der Software zur Laufzeit implementieren, da dies oft die Modifikation der Ausf¨ uhrungsplattform erfordert. Auch Ans¨ atze der Bildschirm¨ ubertragung scheiden aus, da hier ein hoher Datenoverhead auftreten kann, der f¨ ur o ugbare Fl¨achenkommunikationsnetze nicht geeignet ist. ¨ffentlich verf¨ Es wird eine zentral organisierte Middleware favorisiert, die u ¨ber einen Front-Server den Mobilger¨ aten zur Verf¨ ugung steht. Jedem Endger¨at/Benutzer wird eine dedizierte Ressource f¨ ur Compute-Aufgaben zur Verf¨ ugung gestellt, um eine hohe Ausf¨ uhrungsperformance zu erreichen. Zudem wird die Technik des dynamischen Code-Offloadings favorisiert, um Programmcode auf den Compute-Servern zu installieren. Code-Offloading bieten den Vorteil, dass das Mobilprogramm auch ohne Serverunterst¨ utzung lauff¨ahig ist, beispielsweise wenn keine Compute-Ressourcen genutzt werden k¨onnen aufgrund zu geringer verf¨ ugbarer Netzwerkperformance. Außerdem sind die Compute-Ressourcen bei der Anwendung von Code-Offloading generisch, was deren Management in einer Cloud-Infrastruktur vereinfacht. Beim Code-Offloading ist es auf Serverseite notwendig, Programmcode zur Laufzeit kompilieren, laden und ausf¨ uhren zu k¨ onnen. Um dies zu realisieren, ist es zudem sinnvoll, wenn Mobilger¨ at und Compute-Server die gleiche Softwareplattform verwenden. Dann kann zur Laufzeit leicht u uhrung entschieden werden. Verbreitete ¨ber die lokale oder entfernte Ausf¨ Softwareplattformen, die serverseitig und auf Mobilger¨aten eingesetzt werden, sind etwa Java oder .NET. Java ist jedoch dank Android auf wesentlich mehr Mobilger¨aten verf¨ ugbar, weshalb die Wahl der Programmiersprache und Softwareplattform in der vorliegenden Arbeit f¨ ur die weiteren Untersuchungen und die zu entwickelnde Middleware auf Java und Android fiel.

29

3 Modell fu ¨r Mobile Server-unterstu ¨tzte Anwendungen In diesem Kapitel wird unter Beachtung der bereits analysierten Literatur ein Modell vorgestellt, welches Kosten- und Performance-Eigenschaften von Mobilen Cloud-unterst¨ utzten Anwendungen abbilden kann. Da kein vorhandenes Modell unver¨andert u ¨bernommen werden konnte, wurde f¨ ur diese Arbeit ein eigenes Modell erarbeitet, in das einzelne Aspekte aus [HBDTD07] und [CLK+ 11] eingeflossen sind. Dieses Modell wird zun¨achst allgemein f¨ ur Mobile Server-unterst¨ utzte Anwendungen aufgestellt und in den nachfolgenden Kapiteln zur Erfassung verschiedener spezieller Aspekte weiter verfeinert. Aus der Analyse der vorgestellten Literatur in Kapitel 2 ist bereits argumentiert worden, dass eine MCC-Architektur mit Front-Server favorisiert wird. Dabei realisiert der Front-Server die Authentifizierung des Benutzers und die Allokation der Compute-Ressource. ComputeRessourcen stammen aus dem Portfolio eines ¨offentlichen IaaS-Anbieters, liegen also in verschiedener, aber definierter Qualit¨ at vor. Der auszuf¨ uhrende Programmcode wird zur Laufzeit mittels Code-Offloading zun¨ achst durch den Client auf der Compute-Ressoure installiert um ihn anschließend aufrufen zu k¨ onnen. Abbildung 3.1 visualisiert die einzelnen Komponenten grafisch und zeigt deren Interaktion.

3.1 Mobile Server-unterst¨ utzte Anwendungen Wie jedes Modell soll das hier vorgestellte die wichtigsten Eigenschaften reflektieren, die zur Analyse von Mobilen Server-unterst¨ utzten Anwendungen notwendig sind. Zun¨achst werden mobile Anwendungen und Server-unterst¨ utzte Anwendungen betrachtet, anschließend wird das Modell zur Erfassung des Einflusses von Cloud-Technologien erweitert.

3.1.1 Abstrakte generische Anwendung Ausgehend von einer abstrakten Anwendung werden zun¨achst die wichtigsten Eigenschaften eines Computerprogramms abgebildet. Ein Programmlauf L beschreibt die Ausf¨ uhrung eines Programms P unter Verwendung der Eingabe E. Die Laufzeitfunktion lauf (. . . ) beschreibt die Ausf¨ uhrungszeit ∆tL eines Programmlaufs auf einer gegebenen Maschine/Ressource R. ∆tL = lauf (R, L).

(3.1)

Tabelle 3.1 fasst die Eigenschaften des betrachteten Modells zusammen. Da man die gesamte Eingabe eines Programms zu Beginn oftmals nicht kennt, wird das Programm in Module zerlegt, die jeweils Eingaben akzeptieren, die weniger komplex sind. Als Ergebnis sind f¨ ur die vollst¨andige Bearbeitung der Eingabe eines Programmmoduls keine weiteren Programmmodule involviert. Ein Programmteil pi ∈ P und eine zu pi passende Eingabe ei ∈ E bilden einen Programmteillauf (pi , ei ). Diese Dekomposition macht es m¨oglich, einige Programmteile mit bekannter Eingabe besser modellieren zu k¨onnen. Beispielsweise l¨asst sich ein Programm so in berechnungsintensive Teile und eine grafische Benutzeroberfl¨ache zerlegen. Dadurch l¨asst

30

3.1 Mobile Server-unterst¨ utzte Anwendungen

Mobile Applikation

rein lokale Ausführung

Cloud-unterstützte Ausführung Front-Server

Public Cloud

Code Offloading

VM

VM

VM

Abbildung 3.1: Ausf¨ uhrung einer Mobilen Cloud-unterst¨ utzten Anwendung unter Verwendung von Code-Offloading im Vergleich zu einer rein lokalen Ausf¨ uhrung. sich f¨ ur die berechnungsintensiven Programmteile die Ausf¨ uhrungszeit besser erfassen, obwohl andere Programmteile von Benutzereingaben abh¨angig sein k¨onnen. Ein Programmlauf L repr¨asentiert die Instanziierung einer Reihenfolge von Programmteill¨aufen, also genau einer m¨oglichen Ausf¨ uhrungsreihenfolge des Programms. Ein Programmlauf L ist eine durch die Ordnungsrelation ≤ vollst¨ andig geordnete Menge und wie folgt definiert:

L = ((p0 , e0 ), . . . , (pn , en )) mit

n = |P |.

(3.2)

Die Ordnungsrelation ≤ bedeutet, dass alle Elemente (pi , ei ) ∈ L nach ihrem Index i aufsteigend angeordnet sind. Die Ordnungsrelation ≤ gilt somit auch auf allen Teilmengen von L. Jeder Programmteillauf (pi , ei ) hat eine Ausf¨ uhrungszeit ∆ti unter Verwendung einer konkreten Eingabe auf einer konkreten Ressource R. Als spezieller Programmteillauf kann dabei eine Wartephase (pwait ) auftreten, beispielsweise zur Erfassung von Benutzereingaben oder Ein-/Ausgabeoperationen. W¨ ahrend einer Wartephase wird kein Programmcode ausgef¨ uhrt. Aus der Summe der Programmteill¨aufe l¨asst sich wiederum die Gesamtausf¨ uhrungszeit ∆tL f¨ ur einen Programmlauf zusammensetzen. Dies ist nachfolgend beschrieben: ∆ti = lauf (R, pi , ei )

mit (pi , ei ) ∈ L,

(3.3)

|L|

∆tL =

X

∆ti .

(3.4)

i=0

Hierbei wird die nebenl¨ aufige Ausf¨ uhrung von Programmteilen explizit ausgeschlossen. Innerhalb eines Programmteils pi kann jedoch eine nebenl¨aufige Ausf¨ uhrung erlaubt sein. Dies ist gleichzeitig auch eine Restriktion des Modells, das nicht jede m¨ogliche Dekomposition

31

3 Modell f¨ ur Mobile Server-unterst¨ utzte Anwendungen

Tabelle 3.1: Modell zur Beschreibung der Ausf¨ uhrungszeit von Computerprogrammen Definition Beschreibung pi

,i ∈ N

i-tes Programmmodul oder -funktion

ei

,i ∈ N

P = {p0 , . . . , pn }

, P 6= ∅

Gesamtprogramm

E = {e0 , . . . , en }

, E 6= ∅

Gesamteingabe des Programms

R lauf (R, L)/lauf (R, pi , ei )

eine beliebige g¨ ultige Eingabe f¨ ur pi

Maschine/Ressource, auf der das Programm ausgef¨ uhrt wird Ausf¨ uhrungszeit von P bzw. pi auf R mit der Eingabe E bzw. ei

L = ((p0 , e0 ), . . . , (pn , en )) , n = |P | spezifischer Programmlauf ∆tL = lauf (R, L) ∆t = lauf (R, pi , ei )

Ausf¨ uhrungszeit des Programmlaufs L auf R Ausf¨ uhrungszeit eines Programmmteillaufs auf R

eines Programms P abbilden kann. Beispielhaft kann etwa eine Applikation zur Bildverarbeitung genannt werden, bei der nur die einzelnen Bildverarbeitungsschritte durch Parallelverarbeitung beschleunigt werden k¨ onnen. Die Auswahl, das Einlesen und Anzeigen der Bilder ist jedoch ein sequentieller Vorgang. Somit repr¨asentieren Auswahl, Einlesen, Anzeigen und Verarbeiten jeweils einzelne Programmteill¨aufe. An diesem Beispiel wird zudem deutlich, dass die vollst¨ andige Eingabe zu einem Programmteillauf nur beim Verarbeitungsschritt und eventuell beim Anzeigen verf¨ ugbar ist. Die beiden anderen Programmteill¨aufe erwarten weitere Benutzereingaben zur Laufzeit. Aus diesem Szenario l¨asst sich außerdem ableiten, dass man Programmteill¨ aufe in zwei Arten kategorisieren kann, n¨amlich in die Menge Lprocessing der Programmteill¨ aufe, die tats¨ achlich etwas verarbeiten und in die Menge Lidle der Programmteill¨aufe, die nur aus Wartezeiten, beispielsweise auf (Benutzer)-Eingaben, bestehen und weder Programmcode ausf¨ uhren noch eine Eingabe haben. Ein solcher spezieller Programmteillauf wird als (pwait , eempty ) angegeben. Lidle = {(pi , ei ) ∈ L

mit

pi = pwait

und ei = eempty }

Lprocessing = L \ Lidle .

(3.5) (3.6)

Die Ausf¨ uhrungszeit eines Programmlaufs L kann nun also wie folgt zusammengesetzt werden: ∆tprocessing =

X

∆tm ,

(3.7)

∀(pm ,em )∈Lprocessing

∆tidle =

X

∆tn ,

(3.8)

∀(pn ,en )∈Lidle

∆tL = ∆tprocessing + ∆tidle .

(3.9)

F¨ ur die nachfolgenden Betrachtungen sind nur die Programmteill¨aufe aus Lprocessing interessant. F¨ ur diese l¨ asst sich sagen, dass sie von der Eingabe und der zur Berechnung verwendeten Maschine abh¨ angen. Weiterhin wird jedoch auch sichtbar, dass die vom Benutzer abh¨angigen Wartezeiten die Gesamtprogrammausf¨ uhrungszeit deutlich beeinflussen k¨onnen. Da diese Wartezeiten kaum durch Serverunterst¨ utzung beeinflussbar sind, werden sie von den

32

3.1 Mobile Server-unterst¨ utzte Anwendungen

nachfolgenden Betrachtungen ausgeschlossen. Es werden nur Programme oder Programmteile betrachtet, die ausschließlich aus Programmteill¨aufen bestehen, die keine (pn , en ) ∈ Lidle enthalten.

3.1.2 Server-unterst¨ utzte Anwendung In diesem Abschnitt wird gezeigt, welche Erweiterungen f¨ ur das vorgestellte Modell zur Erfassung von Serveruntst¨ utzung f¨ ur Anwendungen notwendig sind. Ein vormals lokal ausgef¨ uhrtes Programm wird dazu in serverseitig ausgef¨ uhrte und lokal ausgef¨ uhrte Programmteill¨aufe partitioniert. Dies bedeutet, dass einige Programmteill¨aufe nun auf einer anderen (Server-) Ressource ausgef¨ uhrt werden. Außerdem muss die neu auftretende Kommunikationszeit zus¨atzlich ins Modell aufgenommen werden. Ein vollst¨ andig auf dem Mobilger¨at ausgef¨ uhrter Programmlauf wird als Lprocessing mobil bezeichnet und dessen Ausf¨ uhrungszeit als ∆tprocessing mobil angegeben. Die Ausf¨ uhrungszeit wird durch Anpassung von Gleichung (3.7) wie folgt berechnet: ∆tprocessing mobil =

j X

∆tmobil m

mit

j = |Lprocessing mobil | .

(3.10)

m=0

Dabei beschreibt ∆tmobil die lokale Ausf¨ uhrungszeit und ∆tremote die Ausf¨ uhrungszeit f¨ ur einen entfernt ausgef¨ uhrten Programmteillauf. Auf einem Mobilger¨at l¨asst sich nun die Aufspaltung in eine Server-unterst¨ utzte Variante der Ausf¨ uhrung modellieren, bei der k Programmteill¨ aufe entfernt ausgef¨ uhrt werden. Die Ausf¨ uhrungszeit ∆tprocessing hybrid f¨ ur eine so zusammengesetzte Art der Ausf¨ uhrung wird wie folgt modelliert: ∆tprocessing hybrid =

j−k−1 X

∆tmobil m +

m=0

j X

∆tremote l .

(3.11)

l=j−k

Um das Ziel der schnelleren Ausf¨ uhrung Server-unterst¨ utzter Anwendungen zu verdeutlichen, sollte die Ausf¨ uhrungszeit des gleichen entfernt ausgef¨ uhrten Programmteillaufs stets kleiner sein als die lokal ausgef¨ uhrte Variante: ∆tmobil m ≥ ∆tremote m

,

(j − k) ≤ m < j.

(3.12)

Durch die Ausf¨ uhrung auf einem entfernten Server werden zus¨atzlich zu serverseitigen Berechnungszeiten ∆twork Daten¨ ubertragungszeiten ∆tcomm notwendig, die auch das Codieren und eventuell das Verschl¨ usseln der Daten mit einbeziehen. Somit l¨asst sich ∆tremote l erneut aufspalten in: ∆tremote l = ∆tcomm l + ∆twork l .

(3.13)

Dabei h¨angt ∆tcomm von verschiedenen Faktoren wie der Gr¨oße der zu u ¨bertragenden Daten, der verf¨ ugbaren Netzwerkperformance und der Codierung ab. Zur Vereinfachung wird ∆tcomm zun¨achst nur durch die Funktion comm(el ) repr¨asentiert, die lediglich von der Eingabe el abh¨angig ist. F¨ ur die Kommunikationszeit spielt insbesondere die Gr¨oße der Eingabe in Byte eine Rolle. ∆tcomm = comm(el ).

(3.14)

33

3 Modell f¨ ur Mobile Server-unterst¨ utzte Anwendungen

¨ Der Einfluss einzelner Faktoren wie der Ubertragungsrate auf die Kommunikationszeit wird in Kapitel 4 genauer betrachtet. Anhand des Modells wird jedoch bereits ersichtlich, dass es schwierig ist, f¨ ur Server-unterst¨ utzte Anwendungen eine gleichbleibende Anwendungsperformance zu realisieren. Dies ist bedingt durch folgende Ursachen. In traditionellen Client/Server Anwendungen werden Client-Anfragen auf die verf¨ ugbaren Server-Ressourcen in der Art zugewiesen, dass eine gleichm¨aßige Lastverteilung auf den verf¨ ugbaren Ressourcen erreicht wird. Trotz dieser Lastbalancierung kann meist nur eine obere Schranke bez¨ uglich der Antwortzeit garantiert werden. Und selbst diese ist nur in beispielsweise 99,9 % aller F¨ alle garantiert. F¨ ur das Modell bedeutet dies, dass ∆twork f¨ ur gleiche Anfragen zu unterschiedlichen Zeiten stark schwanken kann. In Kriterium (3.12) wird jedoch eine Mindest-Performance vorgegeben, um sicherzustellen, dass sich eine entfernte Ausf¨ uhrung positiv auf die Gesamtausf¨ uhrungszeit auswirkt. Weiterhin reduzieren sehr viele gleichzeitige Anfragen an einen Server auch die verf¨ ugbare Netzwerkperformance f¨ ur jede einzelne Anfrage, weil sich alle Clients die verf¨ ugbare Bandbreite zum Server teilen m¨ ussen. Dadurch steigt auch die Kommunikationszeit ∆tcomm eventuell an, was zu einer Verschlechterung der Gesamtreaktionszeit f¨ uhrt. Insgesamt betrachtet kann damit auf einem mobilen Ger¨ at auch bei Kenntnis der aktuellen Netzwerkperformance und der zu u uhrungszeit einer ¨bertragenden Daten keine Garantie gegeben werden, dass die Ausf¨ Server-unterst¨ utzten Anwendung ohne weitere Verbesserungen durch eine obere Schranke begrenzt wird.

3.2 Mobile Cloud-unterst¨ utzte Anwendungen Technologien aus dem Bereich Cloud Computing k¨onnen an dieser Stelle eingesetzt werden, um einige der Restriktionen im Bereich Mobiler Server-unterst¨ utzter Anwendungen aufzuweichen. Durch Virtualisierung von Komponenten im Bereich IaaS und PaaS kann die Anzahl der ben¨otigten Serverressourcen besser an den aktuellen Bedarf angepasst werden. Zentrale Idee dabei ist es, dass jede Anfrage auf eine dedizierte Serverinstanz R zugewiesen wird. Damit wird erreicht, dass die Netzwerkperformance und die Verarbeitungsgeschwindigkeit f¨ ur jede Anfrage konstant sind. Genauer wird davon ausgegangen, dass exakt gleiche Programmausf¨ uhrungen (pl , el ) zu jedem Zeitpunkt t1 , t2 , . . . , tn auf der gleichen Ressource mit der gleichen Ausf¨ uhrungs- und Kommunikationszeit bearbeitet werden. Dazu werden die Funktionen lauf (R, pl , el ) und comm(el ) aus den Gleichungen (3.3) und (3.14) um eine Zeitkomponente erweitert. Es gilt f¨ ur beliebige Zeitpunkte t1 und t2 :

comm(el , t1 ) = comm(el , t2 ),

(3.15)

lauf (R, pl , el , t1 ) = lauf (R, pl , el , t2 ).

(3.16)

In Bezug auf Gleichung (3.13) bedeutet dies, dass eine gewisse obere Schranke f¨ ur ∆tcomm und ∆twork ermittelt werden kann, die jedoch von der G¨ ute der Informationen, etwa bez¨ uglich der aktuell verf¨ ugbaren Netzwerkperformance, abh¨angt. Dadurch l¨asst sich nun absch¨atzen, ob das Kriterium (3.12) durch die Auslagerung eingehalten werden kann. Außerdem ist es durch Verwendung von IaaS-Ressourcen R m¨oglich, ∆twork zu beeinflussen, indem man die zur Berechnung verwendete Ressource entsprechend der Anforderungen anpasst. Da auch CloudRessourcen nicht unbegrenzt zur Verf¨ ugung stehen, bedarf es einer Scheduling-Komponente,

34

3.3 Fazit

die Anfragen auf verf¨ ugbare Cloud-Ressourcen zuweist. Diese Scheduling-Komponente ist auch daf¨ ur verantwortlich, die Anzahl vorgehaltener Cloud-Ressourcen zu regulieren und dem aktuellen Bedarf anzupassen. Man spricht dabei vom horizontalen Skalieren (siehe Kapitel 2.3.3). Dabei kann es vorkommen, dass bei einer großen Anzahl pl¨otzlich auftretender Anfragen nicht gen¨ ugend Ressourcen (V M s) zur Verf¨ ugung stehen. Die Allokationszeit ∆talloc beschreibt die Zeit, die vergeht, bis eine Anfrage auf eine verf¨ ugbare VM zugewiesen werden konnte. Im Cloud Computing ist es u ¨blich, die Verwendung von Ressourcen nach dem pay-per-use Modell in Rechnung zu stellen. Dies impliziert eine Authentifikation zum Beginn der Nutzung von Cloud-Ressourcen, die die Nutzung einer Ressource einem Benutzer eindeutig zuordnet. Die Zeit, die f¨ ur die Authentifizierung ben¨otigt wird, wird mit ∆tauth angegeben. Daraus resultiert, dass Gleichung (3.13) zur Erfassung der genannten Aspekte erweitert werden muss: ∆tremote = ∆tauth + ∆talloc + ∆tcomm + ∆twork .

(3.17)

Durch die Verwendung von Cloud-Ressourcen kann eine gewisse Verarbeitungsgeschwindigkeit garantiert werden. Jedoch wird auch ein gewisser Overhead f¨ ur Allokation und Authentifizierung notwendig. Somit lohnt sich der Einsatz erst, wenn die Berechnungsdauer einen gewissen Umfang u ¨berschreitet. Außerdem wird aus Gleichung (3.3) auch deutlich, dass das Einhalten des Kriteriums (3.12) von der gew¨ahlten Cloud-Ressource R abh¨angig ist. CloudRessourcen werden u ¨blicherweise auf Stundenbasis gemietet. Unterschiedliche Ressourcentypen sind dabei verschieden teuer. Daraus ergibt sich f¨ ur die Ressourcenauswahl zudem eine Kostenbeschr¨ ankung costlimit : costper h (R) · ceil(∆tremote ) ≤ costlimit .

(3.18)

Die Funktion costper h (R) liefert die Mietkosten f¨ ur die Ressoure R pro Stunde und die Funktion ceil(∆tremote ) liefert die auf volle Stunden aufgerundete Nutzungsdauer. Diese stundenweise Abrechnung kann zu großem finanziellen Overhead f¨ uhren, wenn die Nutzungszeit die Abrechnungsperiode immer nur kurz u bersteigt, so werden beispielsweise 61 min als 2 h ¨ abgerechnet. Hier bedarf es also einer Wiederverwendungsstrategie f¨ ur Cloud-Ressourcen R, um diesen Overhead zu minimieren.

3.3 Fazit Das Modell beschreibt Mobile Cloud-unterst¨ utzte Anwendungen. Dabei wird eine Applikation in lokal ausgef¨ uhrte Teile und entfernt ausgef¨ uhrte Teile zerlegt. Das Modell ist in der Lage, den Einfluss verschiedener Faktoren auf die Gesamtausf¨ uhrungszeit abzubilden. In den nachfolgenden Kapiteln werden besonders die nachfolgenden Faktoren genauer untersucht: • Art und Auspr¨ agung der Laufzeitfunktion lauf (R, p, e), die die Abh¨angigkeit zwischen einer Eingabe e und der Ausf¨ uhrungszeit eines Programmmoduls p berechnet, • Abh¨ angigkeit der Daten¨ ubertragungszeit ∆tcomm vom verwendeten Netzwerk und der gew¨ ahlten Codierung, • Abh¨ angigkeit der Allokationszeit einer Ressource (∆tauth und ∆talloc ) von der gew¨ahlten Systemarchitektur, dem verwendeten Schedulingverfahren und der Implementierung des Service-Lebenszyklus.

35

3 Modell f¨ ur Mobile Server-unterst¨ utzte Anwendungen

Außerdem werden folgende Einschr¨ ankungen modelliert: • Die Ausf¨ uhrungszeit der Mobilen Cloud-unterst¨ utzten Anwendung darf die Ausf¨ uhrungszeit der rein mobilen Anwendung nicht u ¨bersteigen. • Die als maximal definierten Kosten f¨ ur die Ausf¨ uhrung d¨ urfen nicht u ¨berschritten werden. Anhand des Modells soll nun die Frage beantwortet werden, welche Applikationen unter konkreten Instantiierungen des Modells realisierbar sind. Besonderes Augenmerk liegt dabei auf der Optimierung der Kosteneffizienz.

36

4 Verbindungen in 3G und WLAN Netzwerken Aus dem Studium vorhandener Literatur in Kapitel 2 ist hervorgegangen, dass manche Technologien aus dem Bereich MCC zwar die verf¨ ugbare Kommunikationsperformance beachten, jedoch sind dazu keine Bewertungsmaßst¨abe genannt. Ebenso wird auf die speziellen Eigenschaften mobiler Kommunikationstechnologien in der Literatur oft nicht eingegangen. Da die Performance mobiler Kommunikationsverbindungen auch immer von der konkreten Konfiguration abh¨ angt, besch¨ aftigt sich dieses Kapitel genauer mit der Analyse von kablellosen Netzwerkverbindungen aus dem Bereich WLAN und 3G Mobilfunk. Eine der beiden Verbindungsarten ist in Deutschland mit hoher Wahrscheinlichkeit an jedem Ort verf¨ ugbar. Ziel dieses Kapitels ist es, eine M¨ oglichkeit zu finden, um die Kommunikationsperformance zur Laufzeit m¨ oglichst realistisch zu bewerten. Außerdem soll eine Kommunikationsbibliothek entwickelt und implementiert werden, die die bestm¨ogliche Ausnutzung der mobilen Kommunikationsverbindung gew¨ ahrleistet. Es werden Parameter bestimmt, die zur Laufzeit messbar sind und auf deren Basis eine Performancevorhersage getroffen werden kann. Zudem wird analysiert, welche Eigenschaften f¨ ur eine mobile Kommunikationstechnologie charakteristisch sind, damit die Ergebnisse dieses Kapitels auch auf zuk¨ unftige Technologien u ¨bertragen werden k¨onnen. Eine belastbare Bewertung der verf¨ ugbaren Netzwerkperformance ist wichtig, da die Ausf¨ uhrungszeit serverseitig ausgef¨ uhrter Programmmodulen von Mobilen Cloud-unterst¨ utzten Anwendungen davon abh¨ angt. Dies ist in Gleichung (3.13) zu sehen, in der die Dauer der Netzwerk¨ ubertragung durch ∆tcomm l repr¨asentiert ist. Außerdem beeinflusst die Netzwerkperformance die Auswahl der Qualit¨at der Server-Ressource. Es ist beispielsweise nicht n¨otig, eine sehr schnelle und teure Maschine zu allokieren, wenn diese dann aufgrund einer schmalbandigen Netzwerkkommunikation nicht schnell genug mit Daten versorgt werden kann. Alle in dieser Arbeit betrachteten Netzwerkverbindungen bauen auf dem im Internet verwendeten TCP/IP-Protokollstapel auf. Somit startet die Analyse mit der Vorstellung dieses Modells und dessen Schichten. Anschließend werden die Netzzugangstechnologien WLAN und UMTS n¨ aher betrachtet. Weiterhin werden die Eigenschaften von TCP Ende-zu-Ende Verbindungen untersucht. Hierzu z¨ ahlen die Duplexf¨ahigkeit, Flusskontrolle und Verschl¨ usselung. Außerdem werden Kommunikationstechnologien f¨ ur Java untersucht, vor allem im Hinblick auf deren Codierungsleistung. Abschließend wird das Pipelining-Verfahren vorgestellt, welches in der Lage ist, die durch die Technologien gegebenen Eigenschaften gut auszunutzen und dem Programmierer eine Schnittstelle auf der Anwendungsschicht anzubieten. Der TCP/IP-Protokollstapel, auch Internetprotokollstapel genannt, ist ein vierschichtiges Modell, welches eine Spezialisierung des allgemeinen 7-schichtigen OSI/ISO Netzwerkprotokollstapels darstellt [Com06]. Er setzt sich zusammen aus Netzzugangsschicht, InternetSchicht, Transportschicht und der Anwendungsschicht. Abbildung 4.1 verdeutlicht das Schichtenmodell und nennt Beispiele f¨ ur Protokolle der jeweiligen Schicht. Jede Schicht ist dabei so ausgelegt, dass sie auf Diensten und Schnittstellen der darunter liegenden Schicht aufbaut und selbst auch Dienste f¨ ur die dar¨ uber liegende Schicht anbietet. Dies soll daf¨ ur sorgen, dass man verschiedene Implementierungen einer Schicht einfach gegeneinander austauschen

37

4 Verbindungen in 3G und WLAN Netzwerken

Host 1 OSI-Schicht

TCP/IP-Schicht

Anwendungen (7) Darstellung (6) Sitzung (5)

Anwendungen

HTTP, FTP, POP, SOAP, CORBA, RMI SOCKS

Transport (4) Vermittlung (3)

Transport

TCP, UDP

Internet

IP (IPv4, IPv6)

Netzzugang

Ethernet, Token Bus, Token Ring, 802.11, W-CDMA

Sicherung (2) Bitübertragung (1)

Gateway 1

Gateway 2

Host 2

Beispiele

Abbildung 4.1: OSI/ISO und korrespondierendes TCP/IPSchichtenmodell.

Anwendung

Anwendung

Transport

Transport

Internet

Internet

Internet

Internet

Netzzugriff

Netzzugriff

Netzzugriff

Netzzugriff

Netz1

Netz2

Netz3

(vgl. Onlineressource http://www. linux-praxis.de/lpic1/images/routing.png (abgerufen am 21.5.2014))

Abbildung 4.2: Beispiel einer Ende-zu-Ende Verbindung im TCP/IPSchichtenmodell.

kann. Auf der Netzzugangsschicht sind unter anderem Implementierungen f¨ ur kabelgebundene Technologien wie Ethernet und f¨ ur kabellose Technologien wie WLAN verf¨ ugbar. Nachfolgend ¨ wird ein Uberblick u ur weiterf¨ uhrende ¨ber die Aufgaben der einzelnen Schichten gegeben. F¨ Informationen sei auf [Com06, S. 159ff.] verwiesen1 . Netzzugang Auf der Netzzugangsschicht, manchmal auch MAC-Schicht2 genannt, werden Verbindungen eines physikalischen Netzwerks aufgebaut. In einem physikalischen Netzwerk befinden sich u ¨blicherweise Knoten, die u ¨ber ein Kabel miteinander verbunden sind oder die beispielsweise via WLAN nach dem Standard 802.113 , Ethernet oder UMTS verbunden sind. Auf dieser Schicht k¨onnen keine Kommunikationsverbindung u ¨ber das physikalische Netzwerk hinaus aufgebaut werden. Internet Um auch u uhrt ¨ber Grenzen physikalischer Netzwerke hinweg zu kommunizieren, f¨ die Internet-Schicht ein allgemeines Paketvermittlungsverfahren ein und weist jedem Netzwerkger¨ at eine Adresse zu. Die Internet-Schicht wird auch als IP-Schicht bezeichnet und sorgt daf¨ ur, dass ein Datenpaket von einem Absender zu jedem beliebigen adressierbaren Empf¨ anger im Internet gelangt. 1

Alle Internet Standards sind im Original als Request for Comments (RFC) ver¨ offentlicht. Einige wichtige RFCs sind beispielsweise RFC791 (IP), RFC1166 (IP-Adresse), RFC793 (TCP) und RFC2616 (HTTP 1.1). Alle RFC-Dokumente sind unter Onlineressource http://tools.ietf.org/html/rfc791 verf¨ ugbar, wobei jeweils der gew¨ unschte RFC in der URL substituiert werden muss. (abgerufen am 10.4.2014) 2 Das Medium Access Control Protocol (MAC, Layer 2) hat [...] unter anderem folgende Aufgaben: Es regelt ” ¨ den Zugriff der Endger¨ ate auf das Ubertragungsmedium. Jedem Datenpaket wird ein MAC-Header vorangestellt, der unter anderem die Adresse des Senders und Empf¨ angers (MAC-Adressen) enth¨ alt.“ (siehe [Sau13, S. 311]) 3 802.11 ist die Oberbezeichnung verschiedener IEEE-Standards, die seit dem Erscheinen als Weiterentwicklungen der WLAN-Technologie erschienen sind. Die wichtigsten Standards f¨ ur das 2,4 GHz und das 5 GHz Frequenzband sind nachfolgenden aufgelistet. 802.11b (2,4 GHz, bis 11 Mbit/s) 802.11g (2,4 GHz, bis 54 Mbit/s) 802.11a (5 GHz, bis 54 Mbit/s) 802.11n (2,4 und 5 GHz, bis 600 Mbit/s) 802.11ac (5 GHz, bis 6,93 Gbit/s) (siehe [Sau13, S. 298])

38

4.1 Aufbau mobiler Kommunikationsnetze

Transport Die Transportschicht realisiert Dienste, die die IP-Schicht um n¨ utzliche Funktionen erweitern, wie etwa Mechanismen zum Trennen von Paketen verschiedener Anwendungen, Mechanismen zur besseren und fairen Ausnutzung der verf¨ ugbaren Bandbreite zwischen verschiedenen Verbindungen (Flusskontrolle) und Mechanismen zur Erken¨ nung von Ubertragungsfehlern. Vor allem das Transmission Control Protocol (TCP) liefert zuverl¨ assige Ende-zu-Ende Verbindungen, die von Anwendungen verschiedenster Art genutzt werden k¨ onnen. Anwendung Auf Anwendungsschicht sind Protokolle spezifiziert, die eher der Organisation und Adressierung der eigentlichen Nutzdaten dienen. Sie werden auch ben¨otigt, um die korrekte Codierung von Daten sicherzustellen. Ein sehr bekanntes Protokoll auf dieser Schicht ist beispielsweise das HTTP-Protokoll. Sendet ein Client eine Nachricht zu einem Server unter Verwendung einer konkreten Instanziierung dieses TCP/IP-Protokollstapels, so durchl¨auft die Nachricht alle vier Schichten zun¨achst auf Clientseite. Ein Beispiel f¨ ur eine Ende-zu-Ende Verbindung zwischen Client und Server u ¨ber zwei Netzwerkknoten (englisch Gateways) unter Verwendung des TCP/IPProtokollstapels ist in Abbildung 4.2 dargestellt. Tats¨achlich versendet wird das Paket auf ¨ der MAC-Schicht. Uber verschiedene zwischengelagerte Netzwerkknoten gelangt die Nachricht schließlich zum Empf¨ anger, wo sie erneut durch alle vier Schichten bis zur entsprechenden Anwendung weitergereicht wird. Auf jeder Schicht wird der Nachricht ein weiterer Header mit f¨ ur diese Schicht spezifischen Informationen hinzugef¨ ugt. Die prim¨are Aufgabe der IP-Schicht ist beispielsweise das Hinzuf¨ ugen der IP-Adressen von Empf¨anger und Absender der Nachricht. Auf dieser Schicht ist es demnach nicht m¨oglich, eine Nachricht einer Anwendung zuzuordnen. Dazu muss der Header der Transportschicht analysiert werden. Verschiedene Zwischenknoten auf dem Weg der Nachricht bis zum Empf¨anger m¨ ussen das Nachrichtenpaket eventuell auch bis zu einer gewissen Schicht analysieren, um dessen Weiterleitung zu erm¨oglichen. Ein Gateway beispielsweise extrahiert die IP-Adresse, um den korrekten Ausgang f¨ ur die Weiterleitung des Pakets zu bestimmen. Neben dem TCP-Protokoll f¨ ur zuverl¨assige Ende-zu-Ende Verbindungen im Internet gibt es auf Transportschicht auch das h¨aufig eingesetzte User Datagram Protocol (UDP). UDP ¨ spezifiziert das zusammenhanglose Ubertragen von einzelnen Datenpaketen. Dabei kommen ¨ weder Mechanismen zur folgerichtigen und vollst¨andigen Ubertragung noch Mechanismen ¨ zur Flusskontrolle zum Einsatz. Somit ist die erfolgreiche Ubertragung von UDP-Paketen nicht gew¨ ahrleistet. Durch den nicht notwendigen Verbindungsaufbau werden einzelne UDPPakete jedoch mit gegen¨ uber TCP-Paketen erheblich verk¨ urzter Verz¨ogerung u ¨bertragen. Deshalb wird UDP oft f¨ ur fehlertolerante Anwendungen wie Internet-Telefonie (Voice-OverIP ) verwendet.

4.1 Aufbau mobiler Kommunikationsnetze Mobile Kommunikationsnetze bestehen u ¨blicherweise aus einem oder mehreren sogenannten Zugangs-Netzwerken und aus einem Kern-Netzwerk, welches die Zugangs-Netzwerke unter¨ einander verbindet. Uber das Kern-Netzwerk werden auch mobile Datenverbindungen ins Internet aufgebaut. Die Verbindungen im Zugangs-Netzwerk sind dabei kabellos. Ad-hocNetzwerke, die zwischen einzelnen Mobilger¨aten aufgebaut werden und ohne Netzzugangspunkt funktionieren, werden in dieser Arbeit nicht betrachtet. Daten werden also im Zugangs-

39

4 Verbindungen in 3G und WLAN Netzwerken

HOME-Konfiguration

CAMPUS-Konfiguration Internet Server

Internet WLAN Switch Access Controller Provider Netzwerk Accesspoint inkl. NAT Router

CAMPUS Netzwerk & Internet

Dienste des Providers bspw. E-Mail

CAMPUS Server

Accesspoint (einfach)

Wireless Client

Wireless Client

Abbildung 4.3: Konfigurationen verbreiteter WLAN Infrastrukturen. (vgl. Onlineressource http://www.cisco.com/web/about/ac123/ac147/archived_issues/ ipj_9-3/wireless_lan_switches.html (abgerufen am 23.1.2014))

Netzwerk u ¨ber einen Accesspoint (AP) oder eine UMTS Antennenstation ins kabelgebundene Netzwerk eingeschleust. Im Vergleich zu kabelgebundenen Netzwerken treten durch die Funku oreinfl¨ usse auf. Auch die Anzahl der Teilnehmer im Funknetzwerk ¨bertragung vermehrt St¨ ¨ beeinflusst Ubertragungsrate und Latenz. Kurzum, die verf¨ ugbare Bandbreite und Latenz ¨ kann sich w¨ ahrend der Dauer einer Ubertragung stark a¨ndern. Nachfolgend werden weitere Eigenschaften f¨ ur WLAN und UMTS unterschieden. Um den Einfluss der Eigenschaften verschiedener mobiler Netzwerktechnologien bewerten zu k¨onnen, werden nachfolgend die Technologien WLAN und UMTS genauer betrachtet. Hierbei werden Eigenschaften wie Bandbreite, Latenz, Duplexf¨ahigkeit oder Reichweite betrachtet. Dar¨ uber hinausgehend k¨ onnen weitere Details zu den verwendeten Netzwerktechnologien in [Sau13, Com06, KR08] nachgelesen werden. F¨ ur die nachfolgenden Untersuchungen wurden zwei WLAN- und eine Mobilfunkkonfiguration festgelegt. Deren Eigenschaften sind in Tabelle 4.1 zusammengefasst und werden im Text n¨aher erl¨autert.

4.1.1 WLAN WLAN ist eine sehr verbreitete kabellose Netzwerktechnologie f¨ ur lokal begrenzte Areale, die nach dem IEEE-Standard 802.11 spezifiziert ist [20112]. WLAN wird h¨aufig an privaten Breitbandanschl¨ ussen eingesetzt, um die einzelnen Computer, Smartphones, etc. in einem Haushalt mit einer Internet-Verbindung zu versorgen. Diese HOME-Konfiguration ist in Abbildung 4.3 ¨ (links) zu sehen. Uber das Kern-Netzwerk des Internet Providers, hier Provider Netzwerk genannt, wird jeder WLAN Accesspoint, hier inklusive Router, mit einem Internetanschluss versorgt, der an Mobilger¨ ate weitergereicht wird. In Abbildung 4.3 (rechts) ist hingegen eine CAMPUS-Konfiguration mit mehreren zu einem WLAN geh¨orenden Accesspoints abgebildet. Dies ist notwendig, um große Fl¨ achen, beispielsweise einen Universit¨ats-Campus, mit einem einheitlichen WLAN Netzwerk zu versorgen. Das Management der Clients ist hierbei aus den einfachen Accesspoints in einen Access Controller ausgelagert. Die Anbindung ins Internet erfolgt ebenfalls u ¨ber diesen Access Controller. Bei der HOME-Konfiguration

40

4.1 Aufbau mobiler Kommunikationsnetze

Tabelle 4.1: Konfigurationen der untersuchten mobilen Kommunikationstechnologien Zugangstechnologie Zugangstechnologie Download/Upload Internetzugang Download/Upload

HOME

CAMPUS

UMTS/HSPA

WLAN 802.11n

WLAN 802.11g

UMTS/HSPA

300 Mbit/s

54 Mbit/s

7,2 / 5,76 Mbit/s

32 / 2 Mbit/s

>54 Mbit/s

7,2 / 5,76 Mbit/s

steht u ¨blicherweise in den heute noch immer sehr stark verbreiteten IPv44 Netzwerken nur eine einzige IP-Adresse f¨ ur alle Ger¨ ate hinter einem Breitbandanschluss zur Verf¨ ugung. Um dennoch mehrere Ger¨ ate anschließen zu k¨onnen, wird ein NAT-Router zwischen Accesspoint und Breitbandanschluss geschaltet. Oft ist dieser schon wie in Abbildung 4.3 (links) mit dem Accesspoint kombiniert. Dieser NAT-Router weist allen Ger¨aten IP-Adressen aus einem frei verf¨ ugbaren Pool von privaten IP-Adressen5 zu. Da diese IP-Adresen im Internet keine G¨ ultigkeit haben, u ¨bersetzt der Router dann via Network Address Translation (NAT) alle Pakete zwischen der vom Provider zugewiesenen IP-Adresse und der privaten IP-Adresse des entsprechenden Ger¨ ates im WLAN-Netzwerk. Bei großen CAMPUS-Konfigurationen kann es auch sein, dass die Mobilger¨ ate Adressen aus dem Pool von o¨ffentlichen Adressen der Institution zugewiesen bekommen. Sehr verbreitet sind die Substandards 802.11g mit bis zu 54 Mbit/s und 802.11n, wel¨ ches in der verf¨ ugbaren Konfiguration eine Ubertragungsbandbreite von bis zu 300 Mbit/s erreicht. In der gesteten Konfiguration wurde f¨ ur WLAN das 2,4 GHz Frequenzband verwen¨ det. Die typischen, real erreichbaren Ubertragungsraten einer ungest¨orten WLAN-Verbindung unter Benutzung einer TCP-Netzwerkverbindnung liegen u ¨blicherweise weiter unterhalb des theoretischen Maximums. Beispielsweise wurde f¨ ur die 802.11g-Verbindung der CAMPUSKonfiguration eine maximale Bandbreitenausnutzung von ca. 12 Mbit/s gemessen. Tabel¨ le 4.2 fasst einige gemessene maximale Ubertragungsgeschwindigkeit f¨ ur die verschiedenen Konfigurationen zusammen. Die typische Umlaufzeit (englisch Round Trip Time (RTT)) f¨ ur kleine Nachrichten liegt f¨ ur 802.11g bei 13-14 ms. WLAN 802.11n liefert zwar durchweg bessere Performance, bleibt jedoch auch sehr weit vom theoretischen Maximum entfernt. Die Gegenstelle f¨ ur die Messungen wurde im Campus-Netzwerk der Universit¨at Bayreuth und f¨ ur WLAN 802.11n (HOME-Konfiguration) in unmittelbarer N¨ahe am WLAN Acesspoint platziert, sodass der Einfluss von St¨ orsignalen minimiert wurde. Die geringe Bandbreitenausnutzung bei WLAN liegt begr¨ undet im Zugriffsverfahren der 4

Es [IPv4] war die erste Version des Internet Protocols, welche weltweit verbreitet und eingesetzt wurde, ” und bildet eine wichtige technische Grundlage des Internets. Es wurde in RFC 791 im Jahr 1981 definiert. IPv4 benutzt 32-Bit-Adressen, daher sind maximal 4.294.967.296 eindeutige Adressen m¨ oglich.“ (Onlineressource http://de.wikipedia.org/wiki/IPv4 (abgerufen am 23.1.2014)) Das Internet Protocol Version 6 ” (IPv6), fr¨ uher auch Internet Protocol next Generation (IPnG) genannt, ist ein von der Internet Engineering ¨ Task Force (IETF) seit 1998 standardisiertes Verfahren zur Ubertragung von Daten in paketvermittelnden Rechnernetzen, insbesondere dem Internet. [...] Im Internet soll IPv6 in den n¨ achsten Jahren die gegenw¨ artig noch u osen, da es eine deutlich gr¨ oßere ¨berwiegend genutzte Version 4 des Internet Protocols abl¨ Zahl m¨ oglicher Adressen bietet, die bei IPv4 zu ersch¨ opfen drohen. [...] IPv6-Adressen sind 128 Bit lang.“ (Onlineressource http://de.wikipedia.org/wiki/IPv6 (abgerufen am 23.1.2014)) 5 Private IP-Adressen k¨ onnen innerhalb privater Netze verwendet werden. Es handelt sich um IPAdressbereiche, die im Internet nicht geroutet werden und deshalb nur G¨ ultigkeit in lokalen Netzwerken haben. Private IP-Adressen k¨ onnen aus folgenden Bereichen benutzt werden: 10.0.0.0 bis 10.255.255.255, 172.16.0.0 bis 172.31.255.255 und 192.168.0.0 bis 192.168.255.255 (siehe [RMK+ 96])

41

4 Verbindungen in 3G und WLAN Netzwerken

Tabelle 4.2: Gemessene Eigenschaften verschiedener mobiler Kommunikationstechnologien Dell Streak 7 Tablet ¨ max. Ubertragungsrate

RTT Ø

SONY Xperia P Smartphone ¨ max. Ubertragungsrate Ø RTT Ø

WLAN 802.11g

11,74 Mbit/s

ca. 13 ms

9,81 Mbit/s

ca. 14 ms

WLAN 802.11n

31,05 Mbit/s

ca. 6 ms

25,99 Mbit/s

ca. 6 ms

Down:2,88 Mbit/s Up:1,55 Mbit/s

ca. 92 ms

Down:4,35 Up:3,97 Mbit/s

ca. 85 ms

UMTS/HSPA

WLAN-Clients auf die Luftschnittstelle. WLAN verwendet den Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA)-Mechanismus [Sau13, S.311 ff.]. Dabei u ¨berwacht ein Endger¨at zun¨ achst die Luftschnittstelle und sendet erst, wenn diese f¨ ur eine gewisse Zeit frei war. Der Empf¨ anger muss den Erhalt der Nachricht explizit best¨atigen. Dennoch kann es vorkommen, dass mehrere Ger¨ ate gleichzeitig senden und die u ¨bertragenen Daten dadurch nicht mehr empfangbar sind. Durch das Abwarten und den m¨oglichen Fehlerfall kommt die erh¨ohte Latenz zustande und es reduziert sich so auch die nutzbare Bandbreite. Voll-DuplexBetrieb ist in WLAN Netzwerken zwar prinzipiell m¨oglich und auch standardisiert, jedoch ¨ sind dazu zwei unabh¨ angige Ubertragungsfrequenzen notwendig. Da dies technisch wegen der doppelten Anzahl Antennen nur sehr teuer zu realisieren ist und zudem die Fequenzu ¨berschneidung beispielsweise in Mehrfamilienh¨ausern ohnehin schon sehr hoch ist, wird das Voll-Duplex-Verfahren quasi nicht implementiert. Es kann also stets nur empfangen oder gesendet werden. In WLAN Netzwerken wird die verf¨ ugbare Bandbreite zwischen Mobilger¨at und Accespoint je nach Signalst¨ arke und H¨ aufigkeit der St¨orsignale entsprechend in verschiedenen Stufen st¨andig neu ausgehandelt. In WLAN Netzwerken k¨onnen selbstverst¨andlich auch UDP-Pakete versendet und empfangen werden. Das Empfangen von TCP- und UDP-Verbindungen ist jedoch oft bei der HOME-Konfiguration eingeschr¨ankt, da der dort verwendete NAT-Router nicht erkennt, welchem Ger¨ at er die eingehende Verbindung zuordnen soll. Man spricht deshalb auch manchmal von einer NAT-Firewall. In der CAMPUS Konfiguration ist es zus¨atzlich oft so, dass UDP-Pakete nicht weitergeleitet werden, um ressourcenhungrige UDP-Dienste wie Voice-over-IP zu unterbinden. Die UDP-F¨ahigkeit von WLAN-Netzwerken ist nur vom Willen des Providers abh¨ angig, jedoch unterbinden gerade ¨offentliche Provider UDP Traffic, beispielsweise in Bahnh¨ ofen, Flugh¨ afen, etc.

4.1.2 UMTS UMTS ist ein Mobilfunkstandard der 3. Generation (3G). Nach Standardisierung durch das Europ¨ aische Institut f¨ ur Telekommunikationsnormen (ETSI) wurde der Standard von der Internationalen Fernmeldeunion (ITU) als einer der drei Mobilfunkstandards der 3. Generation ausgew¨ ahlt. Heute wird der Standard vom 3rd Generation Partnership Project (3GPP) gepflegt und weiterentwickelt6 . Seit 2004 ist UMTS in Deutschland mit einer Daten¨ ubertragungsrate von 384 kbit/s verf¨ ugbar. Als wichtige Weiterentwicklungen sind die Erweiterungen 6

Im 3GPP partizipieren Standardisierungsorganisationen und Parxispartner aus der ganzen Welt. Das 3GPP ver¨ offentlicht in regelm¨ aßigen Abst¨ anden Weiterentwicklungen der Mobilfunkstandards in Releases. UMTS wurde erstmalig im Release 99 aus dem Jahre 2000 standardisiert. Aktuell ist Release 11 aus dem Jahr 2012, welches der achte Nachfolger von Release 99 ist. (siehe Onlineressource http://www.3gpp.org/ (abgerufen am 14.4.2014))

42

4.1 Aufbau mobiler Kommunikationsnetze

PSTN

Kern-Netzwerk Radio Access Network

Internet

PSTN = Public Switched Telephone Network (Netzwerk f¨ ur ¨ offentliche Telefonie)

Abbildung 4.4: Konfiguration einer 3G Infrastruktur (UMTS Mobilfunknetz). (vgl. Onlineressource http://www.altera.com/end-markets/wireless/cellular/ wir-cellular-infrastructure.html (abgerufen am 23.1.2014))

High Speed Downlink Packet Access (HSDPA) und High Speed Uplink Packet Access (HSUPA) ¨ zu nennen, zusammen HSPA, die die Ubertragungsraten auf 14,4 Mbit/s im Downstream und 5,76 Mbit/s im Upstream erh¨ oht haben. Außerdem hat sich durch HSPA gegen¨ uber UMTS auch die RTT im Durchschnitt auf unter 100 ms verringert. Dennoch ist die RTT gegenu oher. Tabelle 4.2 zeigt Messungen f¨ ur UMTS/HSPA im Vergleich zu ¨ber WLAN sehr viel h¨ WLAN. HSPA erreicht hierbei bis zu 4,35 Mbit/s im Download und 3,97 Mbit/s im Upload. Da sich bei den verwendeten Testger¨aten HSPA nicht mehr deaktivieren l¨asst, konnten leider keine Messungen mit dem UMTS-Standard gemacht werden. UMTS liefert jedoch stets mindestens 384 kbit/s im Download und 96 kbit/s im Upload. F¨ ur Vergleichsmessungen bez¨ uglich UMTS sei auf [TLKF09] verwiesen. Weitere Verbesserungen f¨ ur UMTS sind unter dem Namen HSPA+ standardisiert und bei einigen Anbietern in Deutschland bereits verf¨ ugbar [PH13]. Zudem befindet sich in Deutschland bereits auch das Mobilfunknetz der 4. Generation unter dem Namen Long Term Evolution (LTE) im Aufbau, welches nochmals verbesserte Datenraten und k¨ urzere Latenzzeiten verspricht. HSPA+ und LTE werden in dieser Arbeit nicht betrachtet. Die Ergebnisse der Analyse der hier betrachteten Technologien sollte es jedoch erm¨oglichen, Parameter zu bestimmen, um zuk¨ unftig auch diese und weitere Technologien bez¨ uglich ihrer Leistungsf¨ ahigkeit bewerten zu k¨onnen. UMTS ist ein fl¨ achendeckendes Mobilfunknetzwerk, welches aus Zellen besteht. Eine vereinfachte grafische Darstellung einer Mobilfunkkonfiguration ist in Abbildung 4.4 zu sehen. Jede Zelle wird dabei von einer festen Antenne versorgt und deckt ein großes Fl¨achengebiet von mehreren Quadratkilometern ab. Die Komplexit¨at der Netzwerke ist dabei jedoch h¨oher als beispielsweise f¨ ur WLAN, auch aufgrund der h¨aufigen Erweiterungen, sodass sehr hohe Latenzen f¨ ur mobile Datenpakete ins Internet entstehen [TLKF09, S.120f.]. F¨ ur die hier untersuchte UMTS/HSPA-Konfiguration (siehe Tabelle 4.1) wurde eine RTT von durchschnittlich 85 ms bestimmt (siehe Tabelle 4.2). F¨ ur UMTS sind sowohl das Frequency Divisi-

43

4 Verbindungen in 3G und WLAN Netzwerken

on Duplex (FDD) als auch das Time Division Duplex (TDD) Verfahren spezifiziert [Leh03, S. 67]. Bei FDD werden f¨ ur Upload und Download verschiedene Frequenzen benutzt, was gleichzeitigen Upload und Download von Daten erm¨oglicht. Dieses Verfahren wird von allen deutschen Mobilfunkprovidern unterst¨ utzt. Da jedoch Upload und Download verschiedene ¨ maximale Ubertragungsraten aufweisen, kann man nur von asynchronem Voll-Duplex sprechen. Beim TDD-Verfahren werden Download und Upload abwechselnd zeitlich getrennt auf einer einzigen Frequenz u uber beispielsweise WLAN sind Sendezeitpunk¨bertragen. Gegen¨ te und Sendedauer hier aber festgelegt. Das TDD Verfahren wird in Deutschland jedoch nicht implementiert. Es entspricht eher einem Half-Duplex-Verfahren. Im Gegensatz zum CSMA/CA-Verfahren des Zugriffs auf die Luftschnittstelle bei WLAN wird bei UMTS/HSPA das WCDMA-Verfahren (Wideband Code Division Multiple Access) verwendet. Dabei handelt es sich um ein Codemultiplexverfahren, bei dem das gleichzeitige Senden mehrerer Nachricht durch verschiedene Sender m¨oglich ist. Somit kann die ausgehandelte Datenrate einer UMTS/HSPA-Verbindung oft auch erreicht werden, da der aufwendige Kollisionserkennungsmechanismus wie bei WLAN nicht implementiert werden muss7 . In Deutschland und auch vielen anderen L¨andern Europas werden an UMTS Endger¨ate nur private IP-Adressen ausgegeben. Die Ger¨ate befinden sich also praktisch hinter einem NAT-Router, wenn sie Verbindungen ins Internet aufbauen. Dieser Umstand macht die Verwendung von UDP-Paketen zur Kommunikation unm¨oglich. Auch hier sind demnach nur TCP-Verbindungen m¨ oglich. Eine Verbindung zum Endger¨at aus dem Internet ist nie m¨oglich. Im Vergleich zu WLAN ist durch die erh¨ohte Reichweite auch eine wirkliche mobile Nutzung der Datenverbindung, also eine Nutzung im Freien, m¨oglich. Durch die mobile Nutzung nehmen jedoch auch die St¨ oreinfl¨ usse zu, was die Verbindung instabiler macht und als Folge dessen auch in der verf¨ ugbaren Bandbreite einschr¨ankt. Besonders kann sich dies auswirken, wenn ein Teilnehmer den Bereich einer Zelle verl¨asst und in eine neue Zelle hinein kommt. Hierbei kommt es zum Handover der Verbindung. Diese wird jedoch nicht, wie bei Sprachverbindungen u ¨blich, blitzschnell u ¨bergeben, ohne dass der Teilnehmer davon Notiz nehmen w¨ urde. Da Datenverbindungen als nicht so wichtig eingestuft werden, werden diese abgebaut und f¨ ur jede Antenne neu aufgebaut. Dieser Handover kann mehrere Sekunden, im Extremfall sogar bis zu 1 min dauern. W¨ahrend des Handover k¨onnen keine Daten transferiert werden. Es ist somit nicht ratsam, Mobile Cloud-unterst¨ utzte Anwendungen in der Bewegung via UMTS zu nutzen. Weitere Untersuchungen zur Nutzung von UMTS in der Bewegung sind beispielsweise in [TLKF09, S.117ff.] zu finden.

7

Die entscheidende Neuerung von UMTS war [...] die Verwendung eines neuen Zugriffsverfahrens auf der ” Luftschnittstelle. Statt Frequenz- und Zeitmultiplex wie bei GSM verwendet UMTS ein CodemultiplexVerfahren, um u ¨ber eine Basisstation mit mehreren Benutzern gleichzeitig zu kommunizieren. Dieses Verfahren wird Code Division Multiple Access (CDMA) genannt. Im Unterschied zum Zeit- und Frequenzmultiplex von GSM senden hier alle Teilnehmer auf der gleichen Frequenz und zur gleichen Zeit. Die Daten jedes Teilnehmers werden dabei mit einem Code multipliziert, der m¨ oglichst große Unterschiede zu Codes aufweist, die von anderen Teilnehmern zur gleichen Zeit verwendet werden. Da alle Teilnehmer gleichzei¨ tig senden, addieren sich alle Signale auf dem Ubertragungsweg zur Basisstation. Die Basisstation kann jedoch die Daten der einzelnen Teilnehmer wieder aus dem empfangenen Signal herausrechnen, da ihr die Sendecodes der Teilnehmer bekannt sind.“ [Sau13, S. 143]

44

4.2 Eigenschaften kabelloser TCP-Verbindungen

4.2 Eigenschaften kabelloser TCP-Verbindungen Da in vielen ¨ offentlichen Netzwerken keine UDP-Pakete zul¨assig sind, sollen im Folgenden ausschließlich TCP-Verbindungen betrachtet werden. Zudem wird in dieser Arbeit davon ausgegangen, dass sich das Mobilger¨at nicht in einer schnellen Bewegung befindet, sondern w¨ahrend der Nutzung von Mobilen Cloud-unterst¨ utzten Anwendungen seinen Standpunkt h¨ochstens langsam und um nur wenige Meter ver¨andert. TCP ist ein Protokoll, welches in der Lage ist, Fehl¨ ubertragung von Daten zu erkennen und in gewissem Maße auch zu korrigieren. Dazu werden TCP-Verbindungen durch einen sogenannten 3-Wege Handshake zwischen zwei Kommunikationsteilnehmern etabliert. Es werden Sequenznummern vereinbart, die die ¨ korrekte und folgerichtige Ubertragung von Datenpaketen sicherstellen. Ferner verwendet TCP auch eine Flusskontrolle, um die verf¨ ugbare Bandbreite m¨oglichst gut auszunutzen, jedoch nicht zu u ¨berlasten. Mobile Kommunikationsnetzwerke stellen jedoch besondere Anforderungen an das TCP-Protokoll. Einerseits sind die auftretenden Latenzzeiten sehr hoch und andererseits kann sich die maximal verf¨ ugbare Bandbreite h¨aufig und stark ¨andern. Auf die Auswirkungen dieser Ph¨ anomene auf die Performance der Endbenutzer-Applikation soll nachfolgend eingegangen werden. Danach wird der Einfluss von Verschl¨ usselungstechnologien untersucht, die f¨ ur diese Arbeit eine obligatorische Anforderung darstellen, da sensible Daten wie Benutzernamen und Passw¨orter zur Authentifizierung und Abrechnung u ¨bertragen werden m¨ ussen. Die Kommunikationszeit ∆tcomm , die bei der entfernten Ausf¨ uhrung von Programmmodulen auftritt (siehe Gleichung (3.13)), wird von den nachfolgend genannten Faktoren beeinflusst, die in dieser Arbeit betrachtet werden: • die Gr¨ oße der zu u ¨bertragenden Daten (msg size), • die verf¨ ugbare Netzwerkperformance (T hroughput(msg size)), • die Verarbeitungszeit f¨ ur Marshalling (∆tmarshall ), • und die f¨ ur Verschl¨ usselung ben¨otigte Zeit (∆tencrypt ). Die nachfolgenden Gleichungen bringen die Einflussfaktoren in Zusammenhang. Dabei setzt sich die Dauer f¨ ur einen einzelnen Datentransfer ∆ttransf er im hier verwendeten Modell wie in Gleichung (4.2) dargestellt zusammen. Ein Datentransfer vom Client zum Server wird als ∆ttransf erupload bezeichnet. In entgegengesetzter Richtung wird er als ∆ttransf erdownload bezeichnet. Zu beachten ist auch, dass die Nachrichtengr¨oße msg size durch Marshalling (marshall(...)) und die verwendeten Kommunikationsprotokolle (protocol(...)), insbesondere der Verschl¨ usselung, ver¨ andert werden kann. Die nachfolgenden Kapitel untersuchen jeweils eine der genannten Einflussgr¨ oßen n¨aher. ∆tcomm = ∆ttransf erupload + ∆ttransf erdownload , msg size + ∆tmarshall + ∆tencrypt , ∆ttransfer = T hroughput(msg size) msg size = protocol(marshall(raw data)).

(4.1) (4.2) (4.3)

4.2.1 Analyse der Grundperformance Wie bereits im Kapitel 4.1 festgestellt wurde, kann die technologiespezifische Bandbreitenan¨ gabe nicht zur realistischen Bewertung der tats¨achlichen Ubertragungsperformance genutzt

45

220

Übertragungsraten in Byte/s

Übertragungsraten in Byte/s

4 Verbindungen in 3G und WLAN Netzwerken

32768

1024 802.11g (Download) 802.11g (Upload) HSPA (Download) HSPA (Upload) 802.11n (Download) 802.11n (Upload)

32

1

32

1024 32768 Nachrichtengröße in Byte

220

220

32768

1024

802.11g (Download) 802.11g (Upload) HSPA (Download) HSPA (Upload) 802.11n (Download) 802.11n (Upload)

32 1

32

1024 32768 Nachrichtengröße in Byte

220

Abbildung 4.5: Kommunikationsperformance Abbildung 4.6: Kommunikationsperformance Dell Streak 7 Tablet SONY Xperia P Smartphone ¨ werden. In diesem Abschnitt wird untersucht, welchen Einfluss die Gr¨oße der Ubertragungs¨ daten, die verf¨ ugbare Ubertragungsgeschwindigkeit und die Netzwerklatenz auf die nutzbare ¨ Ubertragungsrate T hroughput(msg size) haben. Dazu sind in den Abbildungen 4.5 und 4.6 ¨ die gemessenen durchschnittlichen Ubertragungsraten f¨ ur verschiedene Nachrichtengr¨oßen unter Verwendung einer einzelnen TCP-Verbindung angegeben. Es wurden verschiedene Ger¨ate f¨ ur die clientseitigen Messungen genutzt. Es kamen ein Dell Streak 7 Tablet und ein Sony Xperia P Smartphone zum Einsatz. Beide Ger¨ate verwenden Android als Betriebssystem. Eine genaue Beschreibung der Ger¨ ate ist in Anhang A zu finden. Alle Messungen, die Mobilfunk verwenden, wurden im deutschen Mobilfunknetz von E-Plus und unter Verwendung des Anbieters blau.de8 durchgef¨ uhrt. Bei dieser Konfiguration sind maximal 7,2 Mbit/s im Download und 5,76 Mbit/s im Upload verf¨ ugbar. Messungen im WLAN Netzwerk wurden aus max. 10 m Entfernung zum AP in Sichtweite ausgef¨ uhrt. Die Gegenstelle f¨ ur die Messungen wurde erneut im Campus-Netzwerk der Universit¨at Bayreuth und f¨ ur WLAN 802.11n (HOME-Konfiguration) in unmittelbarer N¨ahe am WLAN AP platziert. ¨ Die Abbildungen 4.5 und 4.6 zeigen, dass die erreichbare Ubertragungsrate von der Nachrichtengr¨oße abh¨ angt. Dies ist in Gleichung (4.2) durch die Funktion T hroughput(msg size) ¨ ber¨ ucksichtigt. Dabei steigt die Ubertragungsrate mit der Nachrichtengr¨oße zun¨achst linear ¨ an, bis sie sich einem maximalen Wert n¨ahert, auf dem die Ubertragungsrate dann etwa gleich ¨ hoch bleibt. In den Abbildungen ist nicht dargestellt, dass die Ubertragungsrate mit einem weiteren starken Anstieg der Nachrichtengr¨oße wieder abf¨allt, da die Ger¨ate dann zunehmend Probleme haben, die Datenmenge zu verarbeiten. Dieser Effekt konnte bereits ab ca. 128 MB Nachrichtengr¨ oße beobachtet werden. Er wird jedoch nicht n¨aher betrachtet, da die Nachrichtengr¨ oßen f¨ ur MCC-Anwendungen u ¨blicherweise wesentlich kleiner sind. Bei beiden Ger¨aten konnte eine sehr ¨ ahnliche Performance festgestellt werden, obwohl das Tablet eine ¨ etwas h¨ohere durchschnittliche Ubertragungsrate bei WLAN erreichte. Tabelle 4.2 fasst die ¨ maximalen Ubertragungsraten und die durchschnittlichen Latenzen zusammen. Da die ser8

Die blau Mobilfunk GmbH ist ein Mobilfunk-Discounter mit Sitz in Hamburg. Die Kernmarken sind der ” Discount-Tarif blau.de“. Als Mobilfunkprovider nutzt blau Mobilfunk die Netzinfrastruktur von E-Plus und ” unterh¨ alt keine eigenen Filialen. [...] Die Netzabdeckung erreicht 2011 nach Angaben des Unternehmens deutschlandweit u olkerung. Durch das UMTS-Netz k¨ onnen 2011 Verbindungen mit einer ¨ber 98% der Bev¨ Geschwindigkeit von bis zu 384 kbit/s aufgebaut werden und mittels HSDPA als UMTS-Erweiterung bis zu 7,2 Mbit/s.“ (Onlineressource http://de.wikipedia.org/wiki/Blau.de(abgerufen am 24.1.2014))

46

4.2 Eigenschaften kabelloser TCP-Verbindungen

verseitigen Komponenten bei den Messungen gleich waren, liegen die Unterschiede tats¨achlich ¨ in den Ger¨ aten selbst begr¨ undet. Die geringeren Ubertragungsraten f¨ ur kleine Nachrichtengr¨oßen sind einerseits im prozentual h¨oheren Protokoll-Overhead f¨ ur kleinere Nachrichten zu suchen. Andererseits werden sie auch von der TCP-Flusskontrolle und dem Handshake beim TCP-Verbindungsaufbau verursacht. Dies wird nachfolgend erl¨autert. Ein hoher Protokoll-Overhead ensteht beispielsweise f¨ ur sehr kleine Nutzdaten, da immer ein vollst¨ andiges TCP-Paket versendet werden muss, welches mindestens 20 Byte Headerdaten enth¨ alt. Zus¨ atzlich kommen noch die Paketheader der unteren TCP/IP-Schichten hinzu, also IP-Header und MAC-Header. Dieser Overhead ist jedoch auf der Anwendungsschicht nicht messbar und relativiert sich mit gr¨oßer werdenden Nutzdaten. Die geringste Protokolloverhead wird erreicht, wenn die Nachrichtengr¨oße immer genau der maximalen Paketgr¨ oße entspricht. Diese maximale Paketgr¨oße wird als MTU (Maximum Transmission Unit) bezeichnet und ist spezifisch f¨ ur jedes physikalische Netzwerk. Die MTU wird u ur ¨blicherweise f¨ die Internet-Schicht angeben. Sie betr¨agt beispielsweise 2312 Byte f¨ ur WLAN 802.11 [Mau04, S. 162 ff.]. Die Nutzdatengr¨ oße betr¨agt dann abz¨ uglich der 20 Byte TCP-Header 2292 Byte. F¨ ur UMTS/HSPA Verbindungen wird in [20009] ein MTU-Werte von 1436 Byte angegeben. Wichtiger ist jedoch die sogenannte Path MTU. Diese beschreibt die kleinste MTU bei der ¨ Ubertragung einer kompletten Ende-zu-Ende Verbindung. Da die MTU f¨ ur jede physikalische Verbindung spezifisch ist und die meisten Verbindung ins Internet via Ethernet geleitet werden, betr¨ agt die maximale MTU oft nur so viel wie die MTU f¨ ur Ethernet, welche 1500 betr¨ agt bzw. 1480 f¨ ur die Anwendungsschicht unter Verwendung von TCP. Zwar k¨onnen TCP-Pakete auch gr¨oßer sein als die MTU, sie m¨ ussten dann jedoch auf IP-Schicht aufwendig fragmentiert und auf der Gegenseite wieder zusammengesetzt werden. Dies vermeidet man indem man die TCP-Paketgr¨ oße (Maximum Segment Size (MSS)) an die MTU anpasst. Außerdem wird zum Beginn einer TCP-Verbindung ein 3-Wege Handshake durchgef¨ uhrt. Bei diesem werden zwar kaum Daten u ¨bertragen, denn er dient nur zur Synchronisation von Client und Server, er kostet aber etwas Zeit, was sich auf die Gesamt¨ ubertragungsrate auswirkt. F¨ ur den 3-Wege Handshake muss mindestens die dreifache Latenz veranschlagt werden, da eine Anfrage, eine Best¨ atigung und deren R¨ uckbest¨atigung zu u ¨bertragen sind. Somit ist der Verbindungsaufbau gerade in Netzwerken mit hoher Latenz sehr zeitaufwendig. Dies l¨asst sich gut in den Abbildungen 4.5 und 4.6 erkennen. Da f¨ ur die UMTS/HSPA¨ Verbidnung die Latenz wesentlich h¨ oher ist, ist die Ubertragungsrate f¨ ur kleine Nachrichten geringer als f¨ ur WLAN. Sch¨atzt man die Dauer f¨ ur den Handshake mit der dreifachen Latenz ab und subtrahiert ¨ diesen Wert von der Ubertragungszeit, erh¨alt man unter Verwendung der MTU als Paketgr¨ oße ∗ ¨ f¨ ur einzelne TCP-Datentransfers nur eine Ubertragungsperformance T hroughput (msg size) zwischen 10-100 kB/s. Dieser Effekt wird durch die TCP-Flusskontrolle verursacht. Die Flusskontrolle in TCP dient dazu, eine potentiell langsamen Empf¨anger nicht zu u ¨berlasten, indem man die Datenrate bei Senden, ausgehend von einem kleinen Startwert, nur langsam erh¨oht. Dieses Verfahren wird als slow start bezeichnet. Dies hat gleichzeitig den Effekt, dass man ¨ auch eine schmalbandige Netzwerkverbindung nicht u bedeutet hier, ¨berlastet. Uberlasten dass mehr Daten gesendet werden als in Puffern der beteiligten Ger¨ate wie Routern oder dem Empf¨ anger gespeichert werden k¨onnen. Somit k¨ame es zum Verlust von Paketen, die dann erneut u ussten. Ziel ist es, mehrere Pakete direkt nacheinander zu ¨bertragen werden m¨ senden, ohne zun¨ achst die Best¨ atigung des Empf¨angers abzuwarten. Der Sender definiert also ein Fenster von Paketen, die gesendet werden. Den Erhalt aller Pakete best¨atigt der Empf¨ an-

47

4 Verbindungen in 3G und WLAN Netzwerken

0.9

32768

1024

32

1

802.11n 802.11g UMTS/HSPA

0.8 Variationskoeffizient

Übertragungsraten in Byte/s

220

UMTS/HSPA 802.11g 802.11n 1

32

1024 32768 Nachrichtengröße in Byte

2

20

0.7 0.6 0.5 0.4 0.3 0.2 0.1

2

25

0 1

32

1024 32768 Nachrichtengröße in Byte

220

Abbildung 4.7: Verteilung (links) und Variationskoeffizient (rechts) mehrerer Performancemessungen verschiedener mobiler Kommunikationsverbindungen (Download).

ger dann eventuell mit nur einer Nachricht. Die Gr¨oße dieses Fensters, auch congestion window genannt, wird soweit erh¨ oht, bis Pakete verloren gehen. Wenn Pakete verloren gehen, ist ¨ die maximale Ubertragungsgeschwindigkeit erreicht. Danach k¨onnen verschiedene Techniken angewendet werden, um den weiteren Verlauf der Kommunikation zu kontrollieren. Im Mobilbereich werden die Verfahren TCP-Vegas oder TCP-Westwood h¨aufig eingesetzt [CFM04]. Das Fenster wird jedoch zun¨ achst verkleinert, um wieder mehrere Pakete gemeinsam senden zu k¨onnen. Das congestion window wird weiterhin st¨andig angepasst, um auf wechselnde ¨ Ubertragungsleistung zu reagieren. Schwankungen k¨onnen hierbei durch auftretende St¨orungen, beispielweise bei WLAN oder UMTS, ausgel¨ost werden. Außerdem kann auch die Anzahl ¨ von Netzwerk-Clients die jeweilige Ubertragungsperformance einzelner Teilnehmer beeinflus¨ sen. Ein Uberblick u ¨ber verschiedene Mechanismen zur TCP-Flusskontrolle in kabellosen Netzwerken ist in [BDGS08] zu finden. Ein Performancevergleich zwischen verschiedenen Flusskontrollmechanismen unter Verwendung einer kabellosen Verbindung ist in [CFM04] zu finden. Darin sind unter anderem auch Experimente enthalten, die zeigen, dass die maximale Bandbreitenausnutzung einer TCP-Verbindung im Mobilbereich erst nach einigen Sekunden Verbindungsdauer erreicht wird. Somit bleibt die Erkenntnis, dass insbesondere einzelne kleine Nachrichtentransfers am besten u ¨ber eine einzige TCP-Verbindung abgewickelt werden ¨ sollten, da die maximale Ubertragungsbandbreite erst nach einer gewissen Zeit erreicht wird. Um die Zuverl¨ assigkeit und St¨ oranf¨ alligkeit der mobilen Kommunikationstechnologien besser bewerten zu k¨ onnen, wurden zus¨ atzlich Messungen an drei Punkten durchgef¨ uhrt. Dazu wurden je 30 Messungen f¨ ur WLAN 802.11g, 802.11n und UMTS/ HSPA mit dem XPERIA Smartphone durchgef¨ uhrt. Abbildung 4.7 (links) zeigt das Minimum, Maximum und den Interquartilsabstand (± 25 % der Werte um den Median) der Messwerteverteilung. Die Mittelwerte der Messungen sind bereits als Kurve in Abbildung 4.6 dargestellt. Zur besseren ¨ Ubersicht wurde in Abbildung 4.7 (links) nur der Download visualisiert. Es ist zu erkennen, dass f¨ ur beide WLAN Standards gegen¨ uber UMTS/HSPA deutlich h¨aufiger Ausreißer nach unten vorkommen. Eine bessere Vergleichbarkeit der Ergebnisse ist in Abbildung 4.7 (rechts) gegeben, in der der Variationskoeffizient9 der Messreihen abgebildet ist. Dieser ist ein relatives Maß und gibt an, wie stark die Messreihe um den Erwartungswert (hier wurde der Mittelwert 9

Der Variationskoeffizient ist ein relatives Maß f¨ ur die Schwankung einer Stichprobe/Messreihe X. Er ist wie folgt definiert: V arK(X) = Standardabweichung(X) , wobei als Erwartungswert hier der Mittelwert gew¨ ahlt Erwartungswert(X) wurde. (siehe [Koh05, S.82])

48

4.2 Eigenschaften kabelloser TCP-Verbindungen

gew¨ahlt) schwankt. Hier l¨ asst sich erkennen, dass UMTS/HSPA f¨ ur kleine Nachrichten weniger stark schwankt als die WLAN Standards. WLAN 802.11n schwankt stark f¨ ur kleine Nachrichten und wird besser mit steigender Nachrichtengr¨oße. Das durchweg gute Abschneiden von UMTS/HSPA ist im Zugriffsverfahren auf die Luftschnittstelle begr¨ undet. Im Vergleich zu WLAN gibt es hier kaum St¨ oreinfl¨ usse durch andere Mobilfunkteilnehmer. Außerdem sind bei UMTS/HSPA die Sende- und Empfangsfrequenzen unter den Mobilfunkprovidern fest zugeteilt. Sie behindern sich nicht gegenseitig wie beispielsweise bei WLAN Netzwerken in Mehrfamilienh¨ ausern. Insgesamt wird festgehalten, dass mit einer Schwankung von ca. 30 % ¨ um den gemessenen Wert der Ubertragungsgeschwindigkeit gerechnet werden muss. Aus der recht starken Schwankung auch bei zeitlich sehr nahen Messungen muss abgeleitet werden, dass die Verf¨ ugbarkeit der messbaren Maximalbandbreite eher pessimistisch bewertet werden muss. Zudem ist es sinnvoll, die maximale Bandbreite nicht durch eine einzelne Messung zu bestimmen, sondern u ¨ber den Mittelwert von aufeinander folgenden Messungen.

4.2.2 Verschl¨ usselungsverfahren ¨ Als Nebenproblemstellung wurde bereits ausgef¨ uhrt, dass die Verschl¨ usselung der Ubertragungsdaten im Cloud-Umfeld unerl¨asslich ist. Dies dient nicht nur dem Schutz von Benutzerdaten, sondern auch der Sicherheit des Abrechnungsmechanismus. Das Stehlen des Sessionkeys einer Cloud-Session k¨ onnte einen Angreifer in die Lage versetzen, auf Kosten des eigentlichen Benutzers dessen Cloud-Ressourcen unerlaubt zu nutzen. Das Verschl¨ usselungsverfahren hat Einfluss auf die Datengr¨oße und es wird Zeit ben¨otigt, um die Verschl¨ usselung durchzuf¨ uhren (siehe Gleichungen (4.2) und (4.3)). Nachfolgend werden zwei g¨angige Verschl¨ usselungsverfahren f¨ ur den Internet-Datenverkehr vorgestellt und deren Eignung f¨ ur MCC wird analysiert. Die Analyse und Auswahl der Verfahren basiert dabei auf [Eck12] und kann dort noch detailierter nachgelesen werden. SSL/TLS Die heute von u usselten Websites unterst¨ utzten Protokolle SSL 3.0 und ¨ber 99 % aller verschl¨ 10 TLS 1.0 stammen aus den sp¨ aten 1990er Jahren . Ohne zu tief in die Details des Secure Socket Layer (SSL) und die Transport Layer Security (TLS) zu gehen, sollen hier dennoch ¨ die f¨ ur die Ubertragung wichtigen Eigenschaften etwas n¨aher erl¨autert werden. Vor allem ¨ TLS gilt heute als Standard in der Verschl¨ usselung von Ubertragungsdaten im Internet. Dies liegt nicht zuletzt auch an der transparenten Implementierung auf Basis von regul¨aren TCP-Netzwerkverbindungen. Bibliotheken f¨ ur die Umsetzung von SSL/TLS sind f¨ ur nahezu alle Programmiersprachen vorhanden. Dabei sind diese Verschl¨ usselungsprotokolle eigentlich Protokolle der Anwendungsschicht, werden jedoch normalerweise alternativ zum regul¨aren TCP-Protokoll angeboten. Der Funktionsumfang von SSL/TLS wird wie folgt zusammengefasst: Die Hauptaufgaben von SSL sind die Authentifikation der Kommunikationspartner ” unter Verwendung von asymmetrischen Verschl¨ usselungsverfahren und Zertifikaten, die vertrauliche Ende-zu-Ende-Daten¨ ubertragung unter Nutzung eines gemeinsamen Sitzungsschl¨ ussels und schließlich auch die Sicherstellung der Integrit¨ at der transportierten Nachrichten unter Nutzung von Message Authentication Codes.“[Eck12, S. 789] 10

siehe Onlineressource http://www.trustworthyinternet.org/ssl-pulse/ (abgerufen am 16.2.2014)

49

4 Verbindungen in 3G und WLAN Netzwerken

Das SSL-Verschl¨ usselungsverfahren umfasst das Handshake-Protokoll, welches dem Aushandeln der Verschl¨ usselungsalgorithmen und der Authentifizeriung der Kommunikationspartner dient, und das Record-Protokoll, welches dem verschl¨ usselten Transfer der eigentlichen Nutzdaten unter Verwendung eines Sessionschl¨ ussels dient. Die Authentifikation basiert dabei auf asymmetrischen Public-Key-Verschl¨ usselungsalgorithmen und der Verwendung von Zertifikaten. Asymmetrisch bedeutet, dass zum Verschl¨ usseln und Entschl¨ usseln verschiedene Schl¨ ussel benutzt werden (siehe [Eck12, S. 415 ff.]). Jeder Kommunikationspartner besitzt einen ¨offentlichen und einen privaten Schl¨ ussel. Zudem sichert die Verwendung von Zertifikaten auch die Authentizit¨at der Daten. Mit einem ¨offentlichen Schl¨ ussel wird ein Klartext in einen Geheimtext umgewandelt. Der Klartext kann mit dem zugeh¨ origen geheimen Schl¨ ussel wieder entschl¨ usselt werden. Der geheime Schl¨ ussel muss geheim gehalten werden und es muss praktisch unm¨oglich sein, ihn aus dem ¨offentlichen Schl¨ ussel zu berechnen. Der ¨ offentliche Schl¨ ussel muss jedem zug¨anglich sein, der eine verschl¨ usselte Nachricht an den Besitzer des geheimen Schl¨ ussels senden will. Praktisch werden die Schl¨ ussel mit Zertifikaten gespeichert. Ein heute oft noch verwendeter Public-KeyVerschl¨ usselungsalgorithmus ist der RSA (Rivest, Shamir und Adleman) Algorithmus. Zertifikate werden u usselt, sodass ¨blicherweise im X.509 Format bereitgestellt und selbst verschl¨ man die entsprechende Zertifikatdatei nur mit einem bekannten Passwort entschl¨ usseln kann. Ein Zertifikat verbindet dabei einen ¨ offentlichen Schl¨ ussel (Public Key) mit einem Servername bzw. einer Server-IP-Adresse. Damit kann ein Empf¨anger den Absender einer Nachricht authentifizieren. Zertifikate allein sind jedoch nicht ausreichend, um einen Absender hinreichend sicher zu authentifizieren, denn der Absender kann sich ein Zertifikat u ¨blicherweise selbst ausstellen. Um die G¨ ultigkeit von Zertifikaten zu sichern, gibt es sogenannte Trusted Authorities, denen sowohl Client als auch Server vertrauen. Eine solche Infrastruktur wird als Public-Key-Infrastruktur (PKI) bezeichnet (siehe [Eck12, S. 415 ff.]). Eine Trusted Authority unterschreibt“ die Zertifikate nach Vorlage und sichert somit, dass das vorgezeigte Zertifi” ¨ kat wirklich g¨ ultig ist. Ublicherweise wird im Internet-Kontext nur der Server authentifiziert. Eine Client-Authentifizierung ist zwar ebenso m¨oglich, jedoch durch wechselnde IP-Adressen oft unpraktisch und wird deshalb selten angewendet. Der eigentliche Verbindungsaufbau einer SSL/TLS verschl¨ usselten Verbindung beginnt, nachdem bereits eine TCP-Verbindung zwischen den Kommunikationspartnern aufgebaut wurde. Danach wird zun¨ achst ein sogenannter SSL/TLS Handshake nach einem festgelegten Protokoll durchgef¨ uhrt. Dies geschieht in vier Schritten [Eck12, S. 793 ff.]. 1. In der Aushandlungsphase einigen sich Client und Server zun¨achst auf die zu benutzende TLS-Version. Anschließend wird eine CipherSuite ausgehandelt, welche ein Tupel aus Schl¨ usselaustauschalgorithmus, Verschl¨ usselungsalgorithmus, Message Authentication Code (MAC)11 und einer Pseudozufallsfunktion ist. Anschließend wird je nach verwendeter CipherSuite ein gemeinsames sogenanntes Master Secret von Client und Server generiert, was dann zur Initialisierung des eigentlichen Verschl¨ usselungsalgorithmus f¨ ur die Nutzdaten verwendet wird. 11

Wollen zwei Kommunikationspartner Alice und Bob u ufen k¨ onnen, dass die zwischen ihnen ausge¨berpr¨ ” tauschten Dokumente einen authentischen Ursprung besitzen, so k¨ onnen sie dazu einen Message Authentication Code (MAC) verwenden. [...] Ein Message Authentication Code ist somit eine Hashfunktion mit Einweg-Eigenschaften, die zus¨ atzlich noch einen geheimen Schl¨ ussel K verwendet. Der Schl¨ ussel ist nur den beiden Kommunikationspartnern bekannt, die authentifizierte Dokumente austauschen m¨ ochten.“ [Eck12, S. 387]

50

4.2 Eigenschaften kabelloser TCP-Verbindungen

2. Der Client sendet zun¨ achst eine authentifizierte und verschl¨ usselte Nachricht zum Server, die dort entsprechend entschl¨ usselt wird. Dadurch wird die korrekte Aushandlung und Verwendung der Schl¨ ussel verifiziert. 3. Gleiches wie in 2. wird auch vom Server an den Client gesendet. ¨ 4. War der Handshake erfolgreich, beginnt nun die eigentliche Ubertragungsphase der Nutzdaten. In SSL/TLS wird zur eigentlichen Verschl¨ usselung der Nutzdaten h¨aufig eine Stromchiffre 12 wie RC4 verwendet. Stromchiffren haben den Vorteil, dass sie Daten beliebiger L¨ange verschl¨ usseln k¨ onnen und somit kein Overhead f¨ ur das eventuelle Auff¨ ullen der Daten auf eine festgelegte Blockl¨ ange wie bei Blockchiffren erforderlich ist. Die Aushandlung und Verschl¨ usselung einer TCP-Netzwerkverbindung bringt auch einen gewissen Overhead mit sich. Zun¨ achst wird durch das auf TCP aufgesetzte TLS record protocol ein geringer Overhead pro TCP-Paket erzeugt. Das TLS record protocol spezifiziert dabei 5 Byte zur Codierung des Verbindungszustands, der verwendeten Version und der L¨ange der Nutzdaten. Zus¨ atzlich fallen 16-20 Byte f¨ ur die MAC an. Insgesamt sind demnach pro TCPPaket also 21-25 Byte an Overhead zu erwarten. Zwar k¨onnen via TLS Pakete von bis zu 65 kB verwendet werden, jedoch sind die Pakete im mobilen Umfeld durch geringe MTUs oft auf ca. 1500 Byte begrenzt. Insgesamt ergibt sich ein minimaler Overhead von ca 1,7% pro Paket. Ein Zertifikat hat u ussen weitere ¨blicherweise eine Gr¨oße von ca. 1 kB. Zus¨atzlich m¨ Schl¨ ussel und Nachrichten ausgetauscht werden. Dies f¨ uhrt außerdem dazu, dass noch vor ¨ der Ubertragung der eigentlichen Nutzdaten bereits ca. 2 kB an Daten f¨ ur den Handshake (msgHandshake ) u ber die TCP-Verbindung u bertragen werden m¨ u ssen. Die Nachrichtengr¨ oße ¨ ¨ ¨ msg size erh¨ oht sich insgesamt f¨ ur eine SSL-verschl¨ usselte TCP-Ubertragung wie folgt in msg sizeSSL : 

msg sizeSSL

 msg size = msgHandshake + msg size + · 25. MTU

(4.4)

Zudem kann vor allem f¨ ur den Handshake ein recht hoher zeitlicher Overhead beobachtet ¨ werden. Dieser setzt sich zusammen aus Berechnungszeit f¨ ur das Master Secret, der Uber¨ tragung der Daten in der Handshakephase selbst und dem Offnen und Laden der Zertifikatdateien von der Festplatte. Abbildung 4.8 zeigt die Verschiebung der Durchsatzkurve nach unten bei Verwendung einer SSL-Verschl¨ usselung gegen¨ uber einer unverschl¨ usselten Verbindung. Eine deutliche Beeintr¨ achtigung ist jedoch nur f¨ ur kleine Nachrichten festzustellen. ¨ Die SSL-Verschl¨ usselung beeintr¨ achtigt die maximale Ubertragungsrate nicht. Abbildung 4.9 visualisiert den gemessenen Overhead f¨ ur den Verbindungsaufbau unter Verwendung von TLS gegen¨ uber einem unverschl¨ usselten Verbindungsaufbau. Dabei ist zu beachten, dass die dargestellte Zeit den Verbindungsaufbau und zus¨atzlich die Zeit f¨ ur eine nachfolgende EchoKommunikation mit 2 Byte Daten darstellt. Dies ist notwendig, da die Verschl¨ usselung nach dem Aufbau der TCP-Verbindung erst mit dem Senden der ersten Nachricht etabliert wird. 12

RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a variable key-size stream ” cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. [...] Eight to sixteen machine operations are required per output byte, and the cipher can be expected to run very quickly in software.“ [Sta07, S. 45]

51

Aufbau einer TCP-Verbindung (Handshake)

220

1200 1000

SSL ohne SSL

32768

1024

Zeit in ms

Übertragungsraten in Byte/s

4 Verbindungen in 3G und WLAN Netzwerken

HOME (Download) HOME (Upload) HOME SSL (Download) HOME SSL (Upload) HOME VPN (Download) HOME VPN (Upload)

32

1

32

1024 32768 2 Nachrichtengröße in Byte

20

800 600 400 200

2

25

0 UMTS/HSPA

HOME

CAMPUS

Abbildung 4.8: Mobile Kommunikationsper- Abbildung 4.9: Dauer des TCP-Verbindungsformance zu einem Server im aufbaus zur VM mit und ohne Campus-Netzwerk der UniSSL-Verschl¨ usselung. (Testgeversit¨ at Bayreuth aus der r¨at Dell Streak 7) HOME-Konfiguration. (Testger¨ at Dell Streak 7) Der Overhead ∆tencrypt aus Gleichung (4.2) betr¨agt etwa 300-400 ms. Dieser zus¨atzliche Overhead beim Verbindungsaufbau zeigt ebenfalls die Vorteile der Wiederverwendung einer schon etablierten TCP-Verbindung. Im Cloud-Umfeld hat die zertifikatsbasierte Authentifizierung jedoch auch einen Nachteil. Da Cloud-Ressourcen u ¨blicherweise einer dynamischen Lastbalancierung und Skalierung unterliegen, ¨andern sich die IP-Adressen der Ressourcen h¨aufig. Da jedoch ein Zertifikat stets einem konkreten Server zugewiesen ist, kann eine solch restriktive Vergabe der Zertifikate nicht erfolgen. Es m¨ usste sonst f¨ ur jede m¨ogliche IP-Adresse ein Zertifikat erzeugt und zur Laufzeit auf dem Server installiert werden. Um dieses Problem zu l¨osen, werden oft sogenannte Wildcards eingesetzt. Dabei weist man ein Zertifikat einer Menge von Servern zu, f¨ ur die das Zertifikat dann g¨ ultig ist. Verzichtet man auf die Authentizit¨atspr¨ ufung des Zertifiktas durch eine Trusted Authority, kann man Zertifikate zur Laufzeit auch selbst ausstellen und unterschreiben, um das Problem wechselnder IP-Adressen zu umgehen. Virtuelles Privates Netzwerk (VPN) Ein virtuelles privates Netzwerk (VPN) stellt u usselung ¨ber die reine Kommunikationsverschl¨ hinaus zus¨atzlich noch die M¨ oglichkeit bereit, Clients direkt in ein entferntes Subnetz zu integrieren. Es wird ein virtuelles Subnetz erstellt, welches es Rechnern aus verschiedenen Netzen erlaubt, so zu kommunizieren, als w¨ aren sie lokal u ¨ber ein Subnetz verbunden. Anwendung findet dieses Verfahren beispielsweise, um Laptops von Außendienstmitarbeitern Zugriff auf eigentlich nur lokal verf¨ ugbare Unternehmensdienste wie E-Mail zu erm¨oglichen. Dazu wird durch den Client eine Verbindung zu einem VPN-Gateway aufgebaut, bei dem sich der Client bereits authentifizieren muss. Danach bekommt der Client eine virtuelle IP-Adresse aus dem entsprechenden Subnetz zugewiesen. Diese virtuelle Verbindung wird auf Clientseite durch einen entsprechenden Netzwerktreiber oder eine Kernel-Erweiterung etabliert. Dadurch funktioniert sie f¨ ur Anwendungen im Allgemeinen transparent. Die Einwahl in ein VPN-Subnetz hat gegen¨ uber der SSL/TLS-Implementierung den Vorteil, dass Server innerhalb des Sub-

52

4.2 Eigenschaften kabelloser TCP-Verbindungen

netzes u usselung und Authentifizierung mehr ben¨otigen. ¨blicherweise keine weitere Verschl¨ F¨ ur das Cloud-Umfeld ergibt sich hier der Vorteil, dass eine einmal etablierte Verbindung zur Cloud via VPN f¨ ur unterschiedliche Serveranfragen genutzt werden kann, ohne dabei die Verschl¨ usselung der Kommunikation jeweils immer neu initialisieren zu m¨ ussen. Es gibt zwei Arten von VPN-Verbindungen in Bezug auf deren technische Realisierung. Die bereits seit langem verf¨ ugbare Variante ist die auf TCP und SSL/TLS aufsetzende VPNVerbindung. Hierzu wird u ¨ber einen Treiber auf Clientseite ein virtuelles Netzwerkinterface etabliert, welches die Daten u usselte TCP-Verbindung zu einem VPN¨ber eine regul¨are verschl¨ Gateway u agt. Die Variante impliziert die gleichen Eigenschaften bez¨ uglich des Over¨bertr¨ heads wie im vorherigen Abschnitt beschrieben. Diese Variante arbeitet auf der Transportschicht im TCP/IP-Protokollstapel. Da das Etablieren der Verschl¨ usselung bei VPN bereits vor dem Aufbau der eigentlichen Datenverbindung erfolgt ist, wirkt sich dieser Overhead auch ¨ ¨ nicht auf die Ubertragungsrate aus. Abbildung 4.8 zeigt die gemessene Ubertragungsrate f¨ ur eine SSL-basierte VPN-Verbindung. Eine andere Variante setzt direkt auf der IP-Schicht auf, IPsec. Hierbei werden direkt IPPakete verschl¨ usselt u ¨bertragen. Dabei wird das sogenannte IP Tunneling angewandt, bei dem IP-Pakete komplett verschl¨ usselt und in ein neues IP-Paket abgelegt werden. Dies er¨ offnet eine gr¨ oßere Flexibilit¨ at, da Routing und andere Mechanismen von der VPN-Verbindung keine Notiz nehmen. Da IPsec jedoch auf einer sehr niedrigen Protokollebene angesiedelt ist, bedarf es f¨ ur die Umsetzung u utzung oder den Workaround u ¨blicherweise Kernel-Unterst¨ ¨ber die Anpassung der betriebssystemspezifischen Netzwerkimplementierung. Der Overhead f¨ ur IPsec Header ist nicht immer gleich. Da IPsec Blockchiffren verwendet, die nur blockweise verschl¨ usseln k¨ onnen, kommen zum eigentlichen Header eventuell noch F¨ ulldaten hinzu, um auf die ben¨ otigte L¨ ange aufzuf¨ ullen. Unter Verwendung einer 3DES-64bit13 Blockchiffre betr¨agt der Overhead zwischen 50-57 Byte. Zudem muss man noch einen neuen IP-Header hinzu addieren, da der urspr¨ ungliche mit verschl¨ usselt wird. Mit dem IP Header, der eine Mindestl¨ange von 20 Byte aufweist, kann so ein Overhead von 70 Byte und mehr pro Paket entstehen. Dies ist ein Vielfaches des Overheads, den eine SSL/TLS Verschl¨ usselung verursacht. Ein weiterer Nachteil von IPsec ist, dass das zum Schl¨ usselaustausch verwendete Internet-KeyExchange-Protokoll (IKE) den UDP Port 500 verwendet. Damit ist das Verfahren f¨ ur MCC nur sehr bedingt anwendbar, da UDP im Mobilfunknetz oft nicht geroutet wird. VPN-Verbindungen beider Auspr¨agungen sind f¨ ur mobile Ger¨ate oft auch nicht verf¨ ugbar. Dies liegt einerseits an fehlender Unterst¨ utzung durch die Hersteller. So ben¨otigt man auf Android -Ger¨ aten zum Etablieren einer VPN-Verbindung Administratorrechte (root), die man regul¨ar nicht hat. Erst ab Android Version 4.0 werden die wichtigsten VPN-Protokolle direkt unterst¨ utzt, ohne Administratorrechte haben zu m¨ ussen. Es liegt andererseits auch an der fehlenden Lizenzierung. Betreiber von VPN-Gateways von Cisco m¨ ussen beispielsweise gesonderte Lizenzen erwerben, um Android -Ger¨aten eine Verbindung zu erm¨oglichen. Eine weitere Eigenart von VPN-Verbindungen ist, dass u ¨blicherweise s¨amtlicher Datenverkehr zum Internet u uhrt wird. Dies ist jedoch f¨ ur MCC nicht gewollt und sogar ¨ber die VPN-Verbindung gef¨ kontraproduktiv, da jedes u ¨bertragene Byte zur Cloud abgerechnet wird und bezahlt werden muss. Clientseitig kann zwar ein sogenannter Traffic-split zur Aufspaltung in VPN-relevanten 13

Der Data Encryption Standard (DES) ist eine Blockchiffre, die einen Eingabeblock von 64 Bit mit einem ” 64-Bit Schl¨ ussel, von dem aber nur 56 Bit relevant sind, zu einem Ausgabeblock von 64 Bit verschl¨ usselt. [...] Meist wird heutzutage jedoch nicht mehr der reine DES eingesetzt, sondern der DES wird in abgewndelter Form, meist als 3DES mit mehreren Schl¨ usseln verwendet, um das Problem des zu kleinen Verschl¨ usselungsschl¨ ussels des DES abzumildern [...] .“ [Eck12, S. 334]

53

4 Verbindungen in 3G und WLAN Netzwerken

und anderen Datenverkehr konfiguriert werden, jedoch nur, wenn die VPN-Implementierung dies auch zul¨ asst. Zusammenfassung Verschl¨ usselung Eine SSL-verschl¨ usselte TCP-Verbindung ist aktuell die beste Variante, um eine sichere Verbindung im MCC-Umfeld zu realisieren. Sie bietet gegen¨ uber einer VPN-Variante folgende Vor- und Nachteile: Vorteile • geringer Overhead f¨ ur die Datenverschl¨ usselung im Vergleich zu IPsec • f¨ ur Mobilger¨ ate und Android problemlos anwendbar

Nachteile • Zertifikatmanagement im CloudUmfeld schwierig • hoher Overhead bei Aufbau f¨ ur jede einzelne Verbindung

Somit wird im Weiteren die SSL/TLS Verschl¨ usselung der TCP-Verbindung selbst bevorzugt. Die hohe Startup-Zeit der SSL-Verbindung muss jedoch durch eine Wiederverwendung der Netzwerkverbindung relativiert werden. F¨ ur Zertifikate werden Wildcards verwendet, um wechselnde IP-Adressen zu unterst¨ utzen.

4.2.3 Duplexf¨ ahigkeit Die Duplexf¨ ahigkeit beschreibt die F¨ ahigkeit, Daten nicht nur vom Sender zum Empf¨anger, sondern auch in umgekehrter Richtung zu transferieren. Dabei sind im TCP/IP-Protokollstapel alle g¨ angigen Protokolle, bis auf einige der MAC-Schicht, bereits duplexf¨ahig. Die Duplexf¨ahigkeit hat großen Einfluss auf die Daten¨ ubertragungsgeschwindigkeit, wenn Daten gleichzeitig in beide Richtungen u ¨bertragen werden. Im Gegensatz zu halb-duplex ist bei ¨ voll-duplex die Ubertragung in beide Richtungen gleichzeitig m¨oglich. Beim voll-duplex Verfahren sind mindestens zwei verschiedene Kan¨ale vorhanden, die gleichzeitig genutzt werden k¨onnen. Beim halb-duplex Verfahren ist oft nur ein Medium vorhanden, welches abwechselnd ¨ f¨ ur die Ubertragung in die verschiedenen Richtungen genutzt wird. In Kapitel 4.1 wurde bereits festgestellt, dass UMTS das asynchrone voll-duplex Verfahren und WLAN das halbduplex Verfahren unterst¨ utzen. In diesem Kapitel wird die Duplexf¨ahigkeit von Ende-zu-Ende Verbindung zwischen Client und Server genauer untersucht. Da ein Netzwerkpaket u ¨blicherweise einen Weg durch mehrere verschiedene physikalische Netzwerktechnologien zwischen zwei Kommunikationspartnern geht, ist die Duplexf¨ahigkeit einer Verbindung nicht einfach zu bestimmen. Im Allgemeinen kommt es hier darauf an, welcher der beteiligten Netzwerkabschnitte die geringste Bandbreite hat und wie dessen DuplexEigenschaften sind. Als Beispiel stelle man sich folgendes Szenario vor: Ein kabelgebundener DSL-Anschluss hat eine Bandbreite von 16 Mbit/s im Download und 1 Mbit/s im Upload. Diese Internet-Verbindung wird von einem Laptop via WLAN 802.11n mit bis zu 300 Mbit/s genutzt. Obwohl WLAN im Vergleich zum DSL-Anschluss im Regelfalle nur halb-duplex-f¨ahig ist, wird die WLAN-Verbindung nicht zum Flaschenhals. Dies liegt daran, dass die schnelle WLAN-Verbindung auch im halb-duplex-Verfahren noch schneller Daten u ¨bertragen kann als der DSL-Anschluss im (asynchronen) voll-duplex-Verfahren. Da bei MCC-Anwendungen stets mehrere verschiedene physikalische Netzwerke zwischen Client und Server liegen, wurde

54

8e+07 7e+07 6e+07 5e+07 4e+07 1000 1 Anzahl überlagerter Einzeltransfers UMTS/HSPA 160000 140000

Latitude 6530 Dell Streak 7

120000 100000 80000 60000 40000 20000 0

1000 1 1000 1 Anzahl überlagerter Einzeltransfers

Übertragungsgeschwindigkeit in Byte/s

Gigabit Ethernet 9e+07

Übertragungsgeschwindigkeit in Byte/s

Übertragungsgeschwindigkeit in Byte/s

Übertragungsgeschwindigkeit in Byte/s

4.2 Eigenschaften kabelloser TCP-Verbindungen

HOME 220000

WLan 802.11n FastEthernet

210000 200000 190000 180000 170000 160000 150000 140000 130000

1000 1 1000 1 Anzahl überlagerter Einzeltransfers CAMPUS

2.5e+06

Latitude 6530 Dell Streak 7

2e+06 1.5e+06 1e+06 500000 1000 1 1000 1 Anzahl überlagerter Einzeltransfers

Abbildung 4.10: Verteilung der gemessenen Gesamt¨ ubertragungsgeschwindigkeiten von u ¨berlagertem Upload/Download Traffic im Vergleich zu einzelnen Request/Response-Verbindungen (Quartile). Es wurden jeweils 30 aufeinander folgende Messungen am gleichen Standort durchgef¨ uhrt.

dieser Sachverhalt noch etwas genauer untersucht. Die Duplexeigenschaften von Ende-zu-Ende Verbindungen wurden im Rahmen dieser Arbeit durch verschiedene Messungen bestimmt. Es wurden jeweils 30 Messungen mit großen Datenmengen zwischen zwei Endpunkten durchgef¨ uhrt. Die Daten wurden zun¨achst zum Server u uckgesendet. Dabei wurden die Daten ¨bertragen und anschließend unver¨andert zur¨ einerseits nacheinander u ¨bertragen und in einem zweiten Test in Pakete aufgeteilt, die sofort nach Erhalt vom Server wieder zur¨ uckgeschickt wurden, ohne dabei auf weitere eingehende Daten zu warten. Gemessen wurde die resultierende Gesamt¨ ubertragungszeit, die sich im zweiten Test auf einer voll-duplex-f¨ahigen Infrastruktur etwa halbieren sollte. Die Gesamtu ¨bertragungsgeschwindigkeit sollte sich beim voll-duplex-Verfahren etwa verdoppeln. Bei dem asynchronen voll-duplex-Verfahren ergibt sich ein Mittelwert, der u ¨blicherweise oberhalb der geringeren Bandbreite (Minimum aus Upload- und Downloadbandbreite) liegt. ¨ ¨ Abbildung 4.10 zeigt die gemessenen Ubertragungsbandbreiten bei Uberlagerung von Upload und Download im Vergleich zu sequentieller Kommunikation. Es sind neben dem Medianwert auch die minimalen und maximalen Messwerte angegeben sowie der Interquartilsabstand von ± 25 % der Messwerte um den Median. Daraus ist zu erkennen, wie die u ¨berlagerte Kommunikation in verschiedenen Umgebungen unterst¨ utzt wird. Eine Vergleichsmessung f¨ ur u ¨ber genau einen Switch verbundene Kommunikationspartner zeigt, dass die voll-duplex-F¨ahigkeit

55

4 Verbindungen in 3G und WLAN Netzwerken

¨ der Gigabit Ethernet Verbindung gut ausgenutzt werden kann. Durch die u ¨berlagerte Uber¨ ¨ tragung von 1000 Paketen konnte die Ubertragungsbandbreite im Vergleich zur Ubertragung als einzelnes Paket nahezu verdoppelt werden. Es wurden je Messung 300 MB jeweils hin und zur¨ uck u ¨bertragen. Eine weitere Messreihe wurde in der HOME-Konfiguration durchgef¨ uhrt (siehe Tabelle 4.1). Hier wurden je 2 MB Daten zu einem Server im Campus-Netzwerk der Universit¨at Bayreuth hin und zur¨ uck u ¨bertragen. Dabei war der Client einmal via FastEthernet mit dem Modem verbunden und einmal u ¨ber einen WLAN-Router mit WLAN 802.11n und 300 Mbit/s ¨ Ubertragungsrate. Als Client wurde hierbei ein Dell Latitude 6530 Laptop verwendet. Man kann in Abbildung 4.10 (oben rechts) erkennen, dass, obwohl WLAN in diesem Szenario nur ¨ halb-duplex-f¨ ahig ist, durch Uberlagerung von Upload und Download trotzdem ein Geschwindigkeitszuwachs erreichbar ist. F¨ ur FastEthernet f¨allt dieser jedoch etwas h¨oher aus. Bei dieser asynchronen Verbindung kann ohnehin nur ein Zuwachs von maximal 1/16 der Bandbreite (ca. 6%) erreicht werden, da nur der ohnehin schnelle Download mit dem Upload u ¨berlagert werden kann. Dieser machte jedoch auch im sequentiellen Fall nur 1/17 der Gesamt¨ ubertragungszeit aus. Somit kann die Bandbreite auf maximal 17/16 des sequentiellen Falls steigen. F¨ ur FastEthernet liegt der gemessene Zuwachs bei ca. 10% und f¨ ur WLAN bei ca. 2%. Zu beachten ist auch, dass die geringen Zuw¨achse auch im Bereich der Schwankungsbandbreite der Verbindungen selbst liegen k¨ onnen. Weitere Messungen f¨ ur WLAN wurden in der CAMPUS-Konfiguration mit zwei verschiedenen Ger¨aten durchgef¨ uhrt. Als Ger¨ at wurde erneut das Dell Streak 7 Android Tablet benutzt. Zus¨atzlich wurde auch der Dell Latitude 6530 Laptop benutzt. Der Server befand sich wie bei der Messung in der HOME-Konfiguration im Campus-Netzwerk der Universit¨at Bayreuth. Deshalb waren Upload und Download-Datenrate bei dieser Messung gleichhoch. Es wurden 20 MB jeweils hin und zur¨ uck u ¨bertragen. Die Ergebnisse sind in Abbildung 4.10 (unten rechts) visualisiert. Die WLAN Verbindnung wies bei diesem Test die geringste Bandbreite auf der End-zu-Ende Verbindung zum Server auf. Die Maximalbandbreite war demnach ¨ durch die 802.11g-Verbindung limitiert. Trotzdem konnte durch die Uberlagerung bei beiden Ger¨aten eine Erh¨ ohung der Daten¨ ubertragungsgeschwindigkeit gemessen werden (Latitude 6530: ca. 10% Streak 7: ca. 9%). Dies liegt wahrscheinlich in der besseren Ausnutzung der verf¨ ugbaren Bandbreite beim Senden durch den Accesspoint begr¨ undet. Dieser best¨atigt nicht nur empfangene Pakete, sondern sendet auch gleich die Daten zur¨ uck (Piggybacking 14 ), womit die Sendephasen des Accesspoints besser genutzt werden. Abschließend wurden in der UMTS-Konfiguration auch Messungen zur Duplexf¨ahigkeit im Mobilfunknetz durchgef¨ uhrt (siehe Abbildung 4.10 unten links). Hierbei zeigte sich ein ganz unterschiedliches Bild zwischen den benutzen Mobilger¨aten. Auf beiden Ger¨aten betrug die Downloadbandbreite etwa das Zehnfache der Uploadbandbreite, wobei wir ca. 1,2 Mbit/s f¨ ur den Download bei großen Datentransfers (>1MB) messen konnten. Obwohl bei UMTS durch das FDD-Verfahren ein simultaner Upload und Download m¨oglich sein sollte, konnte dies nur bei dem Streak 7 gemessen werden. Hier konnte eine Steigerung von 133% und bei dem Dell Latitude eine Verminderung um 46% gemessen werden. Erwartet wurde durch die asynchrone Verbindung ein Zuwachs von 1/10. Die starken Unterschiede sind durch sehr stark schwanken14

Piggybacking beschreibt in Bezug auf TCP die M¨ oglichkeit, beim Best¨ atigen eines Pakets (ACK) zus¨ atzlich auch Nutzdaten an das Best¨ atigungspaket anzuh¨ angen, um so die Anzahl von Paketen einer Duplexverbindung zu reduzieren und damit die effektive Bandbreitenausnutzung zu maximieren. (siehe [KR08, S. 328])

56

4.2 Eigenschaften kabelloser TCP-Verbindungen

de Messwerte begr¨ undet. Diese starke Schwankung trat beispielsweise beim Bestimmen der Maximalbandbreiten nicht auf (siehe Abbildung 4.7). Um dieses Problem weiter einzugrenzen, wurden erneute Messungen durchgef¨ uhrt mit dem Ziel, Upload- und Downloadbandbreite gleichzeitig auszusch¨ opfen. Dazu wurden erneut 1000 u ¨berlagerte Datentransfers durchgef¨ uhrt, bei denen jeweils das Zehnfache an Downloaddaten gegen¨ uber den Uploaddaten u ¨ber¨ tragen wurde. Hier konnte tats¨ achlich bei beiden Ger¨aten die Ubertragungsdauer gegen¨ uber einem Einzeltransfer verringert werden. Somit konnte so die Duplexf¨ahigkeit nachgewiesen werden. Weiterhin konnte beobachtet werden, dass nachdem große und schnelle Downloads erfolgt waren, nachfolgende einzelne Request/Response-Verbindungen recht hohe Daten¨ ubertragungsgeschwindigkeiten aufwiesen, ehe sie dann allm¨ahlich auf ein konstantes niedriges Niveau absanken. Der Grund f¨ ur diese Beobachtungen ist die oft als Problem beschriebene dynamische Bandbreitenanpassung bei HSPA [AZ06]. Dabei wird die pro Benutzer verf¨ ugbare Bandbreite f¨ ur jedes Ger¨ at in kurzen Abst¨anden angepasst. F¨ ur große Downloads wird die Bandbreite entsprechend hochgesetzt. Bei den hier durchgef¨ uhrten Request/ResponseAnfragen k¨ onnen jedoch nur so viele Daten heruntergeladen werden wie auch hochgeladen wurden. Dies bedeutet f¨ ur die getestete Konfiguration, dass der Upload stets ausgelastet ist, der Download aber nur zu etwa 10%. Somit wird dem Ger¨at die zugeteilte Bandbreite gek¨ urzt. Dies f¨ uhrt dann unter Umst¨ anden dazu, dass die Downloadbandbreite so stark sinkt, dass auch ¨ durch Uberlagerung kein Durchsatzgewinn erzielt werden kann. Eine L¨osung dieses Problems ist kaum zu bewerkstelligen, ohne die Anpassungsroutinen des jeweiligen Mobilfunkproviders zu kennen. Außerdem h¨ angt die Duplexf¨ahigkeit auch von der Implementierung des UMTS¨ Modems ab. Im Durchschnitt ist aber die Uberlagerungsstrategie meist nicht schlechter als die ¨ Einzeltransfers und es kann ein kleiner Durchsatzgewinn erreicht werden. Die Ubertragungsbandbreite T hroughputmax Duplex f¨ ur u ¨berlagerte Request/Response Kommunikation, mit der gleichzeitig in beide Richtungen Daten u ¨bertragen werden k¨onnen (T hroughputmax Download und T hroughputmax U pload ), kann somit f¨ ur diese Arbeit unter Benutzung von WLAN oder UMTS wie folgt abgesch¨ atzt werden: T hroughputmax Duplex = M IN (T hroughputmax Download , T hroughputmax U pload ).(4.5)

4.2.4 Protokolle und Codierung auf Anwendungsschicht ¨ Beim Ubersenden von Daten via Netzwerk m¨ ussen Protokolle und Codierungen verwendet werden, die sowohl Client als auch Server verstehen, damit die Daten korrekt interpretiert werden k¨onnen. Dies ist auf den unteren TCP/IP-Schichten ebenfalls notwendig und wird durch die bereits vorgestellten Protokolle implementiert. Die Codierung beschreibt einerseits den Datenaustausch und andererseits auch die Anordnung der Daten und Datenformate, die die eigentliche Nachricht ausmachen. Um die nachfolgend vorgestellten Technologien einordnen zu k¨onnen, werden zun¨ achst wichtige abstrakten Konzepte f¨ ur Client/Server Kommunikation vorgestellt. Die Zusammenfassung basiert auf [Emm03, S. 93 ff.]. entfernter Prozeduraufruf / entfernte Objekte Bei dieser Art der Kommunikation handelt es sich meist um einen synchronen Nachrichtenaustausch. Das heißt, der anfragende Client blockiert so lange, bis er die Antwort vom Server erhalten hat. Dabei fasst man dieses Request/Response-Verhalten als eine Art Prozeduraufruf auf. Der Server stellt ¨ eine Methode zur Verf¨ ugung, empf¨angt Ubergabeparameter und sendet den R¨ uckgabewert der Methode zur¨ uck zum Client. Diese Art der Modellierung f¨ ugt sich sehr leicht

57

4 Verbindungen in 3G und WLAN Netzwerken

in das Programmierkonzept von prozeduralen Programmiersprachen ein. Eine Weiterentwicklung f¨ ur objektorientierte Programmiersprachen ist im Konzept der entfernten Objekte zu sehen (beispielsweise Java RMI ). Dabei wird auf Serverseite ein ganzes Objekt instanziiert, dessen Methoden dann entfernt durch den Client aufgerufen werden k¨onnen. Die Verbindung zwischen dem Client und dem Objekt wird dabei u ¨ber eine Session hergestellt. Oft wird dem Client vom Server eine abstrakte Interfacebeschreibung der verf¨ ugbaren Methoden und Objekte zur Verf¨ ugung gestellt. Diese Beschreibung nutzt der Client, um die entfernt verf¨ ugbare Funktionalit¨at korrekt aufrufen zu k¨onnen. asynchroner Nachrichtenaustausch Beim asynchronen Nachrichtenaustausch wird keine festgelegte Request/Response-Reihenfolge der Nachrichten eingehalten. Nachrichten in beide Richtungen k¨ onnen jederzeit gesendet werden. Dieses Verfahren impliziert, dass jede Nachricht komplett selbstbeschreibend ist, da ihr kein Gegenst¨ uck zugeordnet werden kann. Asynchroner Nachrichtenaustausch kommt oft in Event-basierten Systemen zum Einsatz. Die Entkopplung von Request und Response kann beispielsweise sinnvoll zur taskbasierten, entfernten Ausf¨ uhrung eingesetzt werden. Unabh¨angige Tasks werden dabei zum Server u ¨bertragen, dort verarbeitet und die Ergebnisse werden in der Reihenfolge der Beendigung der Tasks zur¨ uckgesendet. Dabei k¨onnen sich Anfrage- und Antwortnachrichten auch u ¨berlagern. Dieses Verfahren wird als Pipelining bezeichnet. ¨ Es kann sinnvoll eingesetzt werden, um die verf¨ ugbare Ubertragungsbandbreite besser zu nutzen und eventuell hohe Netzwerklatenzen zu verstecken. Bei Verwendung des entfernten Prozeduraufrufs machen sich hohe Netzwerklatenzen oft negativ bemerkbar, da auf das Eintreffen des Ergebnisses vom Server gewartet wird. Im Vergleich dazu ist es beim asynchronen Nachrichtenaustausch notwendig, dass die entfernt ausgef¨ uhrten Funktionen keine bestimmte Reihenfolge voraussetzen. Oft kann das Verhalten synchroner Kommunikation (entfernter Prozeduraufruf) u ¨ber einen asynchronen Nachrichtenaustausch emuliert werden, indem man zusammengeh¨orige Request/Response-Nachrichten entsprechend markiert. Somit ist es im Rahmen dieser Arbeit ausreichend, zun¨achst nur den asynchronen Nachrichtenaustausch zu unterst¨ utzen. Zudem unterscheidet man zwischen zustandsbehafteter und zustandsloser Kommunikation. zustandsbehaftete Kommunikation Hierbei wird zwischen Client und Server ein Zustand gespeichert. Dieses Verfahren wird beispielsweise im Electronic Commerce angewendet, um den Fortschritt eines Online-Bestellvorgangs zu dokumentieren. Dabei gibt es unter anderem die Variante der expliziten Zustandsmanipulation u ¨ber eine SessionImplementierung. Der u ¨bermittelte Sessionkey identifiziert dabei zusammengeh¨orige Aufrufe. Man kann aber auch eine implizite Zustandsmanipulation u ¨ber eine einzige TCP-Verbindung implementieren, da eine TCP-Verbindung bereits zusammengeh¨orige Daten¨ ubertragungen identifiziert. Letzteres hat den Vorteil, dass kaum zus¨atzliches Zustandsmanagement beim Client und Server implementiert werden muss und der Lebenszyklus des Zustands automatisch mit dem Abbau der Verbindung endet. Ersteres hat wiederum den Vorteil, dass die Session auch beim Abbruch der Kommunikation durch einen Fehler zun¨ achst nicht verloren geht. zustandslose Kommunikation Hierbei wird serverseitig kein Zustand gespeichert und es wird im Allgemeinen f¨ ur jede Anfrage eine neue Verbindung aufgebaut. Jede Anfrage liefert ¨ bei gleichen Ubergabeparametern dasselbe Ergebnis zur¨ uck. Diese Art der Modellierung

58

4.2 Eigenschaften kabelloser TCP-Verbindungen

erh¨ oht die Skalierbarkeit einer entfernt verf¨ ugbaren Funktionalit¨at, da der Server leicht repliziert werden kann. Zur Abrechnung der Nutzung von Cloud-Ressourcen, muss deren Nutzungsdauer durch eine Zustandsimplementierung erfasst werden. Eine Analyse der mobilen Kommunikationstechnologien in Abschnitt 4.2 ergab, dass die Wiederverwendung von bereits etablierten TCPVerbindungen angestrebt werden sollte. Somit ist eine zustandsbehaftete Kommunikation, die durch eine TCP-Verbindung reflektiert wird, zu bevorzugen. Oft geh¨ oren das Kommunikationsprokoll und die Datencodierung auch zusammen. Nachfolgend werden einige popul¨ are Technologien genannt und deren Eignung f¨ ur MCC-Anwendungen wird diskutiert. SOAP Das Simple Object Access Protocol (SOAP) [BEK+ 00] wurde f¨ ur den standardisierten Datenaustausch zwischen Rechnern entwickelt, die verschiedene Hardware und Software benutzen und via Internet miteinander verbunden sind. Dabei basiert SOAP auf dem Austausch von XML-Nachrichten, die wiederum u ¨ber ein Protokoll wie HTTP oder Java Message Service (JMS) u usselte Verbindungen ¨bertragen werden k¨onnen. SSL-verschl¨ sind ebenfalls m¨ oglich. SOAP ist damit vielf¨altig einsetzbar und bietet eine Reihe von Erweiterungen, die aus dem stark verwandten Bereich der Web Services stammen und gut standardisiert sind. SOAP ist vor allem auch im Business-to-Business (B2B) Verkehr beheimatet. Da das Protokoll jedoch als relativ ineffizient gilt, unter anderem wegen der XML-Verarbeitung und dem daraus resultierenden hohen Protokoll-Overhead, wird es im Web zunehmend verdr¨angt von schlankeren Implementierungen. Die Gr¨ oße einiger via SOAP u ¨bertragener Standarddatentypen ist in Tabelle 4.3 zusammengefasst. Alle namhaften Java-Applikationsserver und Entwicklungsumgebungen bieten Unters¨ utzung f¨ ur die Entwicklung von SOAP Web Services. SOAP ist via der ksoap-Library auch f¨ ur Android verf¨ ugbar. SOAP kann sowohl f¨ ur den entfernten Prozeduraufrauf (RPC), wie auch f¨ ur asynchrones Messaging verwendet werden. RESTeasy/JSON Als eine Art Gegenbewegung zu SOAP Web Services sind seit einigen Jahren RESTful Web Services verbreitet (REST = Representational State Transfer ) [Fie00]. Sie nutzen ausschließlich eine spezielle Untermenge des HTTP-Standards f¨ ur den effizienten Datenaustausch aus. Zur Codierung der Nutzdaten k¨onnen neben XML auch das Javascript Object Notation (JSON) Format [Cro06] und andere verwendet werden. Dabei ist JSON, wie auch XML, ein textuelles Format, welches jedoch auf die meisten Metainformationen verzichtet und somit wesentlich weniger Overhead als XML hat. RESTful Web Services sind zwar auch standardisiert, jedoch wird die Standardisierung nicht von vielen großen Unternehmen voran getrieben und somit ist auch die Werkzeugunterst¨ utzung f¨ ur Entwicklung solcher Web Services geringer. REST ist dank HTTP auch f¨ ur Android verf¨ ugbar und kann via SSL-verschl¨ usselter Verbindung genutzt werden. Zudem kann HTTP eine bereits aufgebaute TCP-Verbindung mehrfach verwenden. Es existieren auch Bibliotheken f¨ ur die JSON-Codierung. RESTful Web Services arbeiten ressourcenorientiert. Eine Ressource kann dabei unter anderem ein Bild, ein Text oder auch ein Objekt sein. Somit kann REST auch f¨ ur RPC-Aufrufe auf entfernten Objekten eingesetzt werden. CORBA Die Common Object Request Broker Architecture (CORBA) beschreibt einen Standard, der wie SOAP die Kommunikation zwischen verschiedenen Rechnern und Software-

59

4 Verbindungen in 3G und WLAN Netzwerken

Stacks erm¨ oglicht [Obj12]. CORBA 1.0 wurde bereits 1991 ver¨offentlicht und seither kontinuierlich weiterentwickelt. Im November 2012 wurde der bis dato aktuellste CORBA-Standard in der Version 3.3 beschlossen. Auch CORBA bietet verschiedene Erweiterung, wie etwa eine Service-Discovery, Services-Naming, Lastbalancierung und weitere. CORBA transferiert die Daten jedoch im Bin¨arformat und erzeugt damit wesentlich kleinere Nachrichten als die bereits vorgestellten textuellen Formate. CORBA ist urspr¨ unglich eher f¨ ur Intranets entwickelt worden und verschiedene CORBA-Implementierungen sind nicht immer 100% kompatibel. CORBA verwendet eine eigene InterfaceBeschreibung, die Interface Definition Language (IDL), aus der ein Client beispielsweise den Code f¨ ur eine spezifische Programmiersprache erzeugen kann. CORBA implementiert das Konzept von verteilten Objekten. Eine bekannte CORBA-Implementierung f¨ ur Java, JacORB15 , unterst¨ utzt sowohl SSL-Verschl¨ usselung als auch die Wiederverwendung einer TCP-Verbindung. Es gibt jedoch keine CORBA Implementierung, die f¨ ur Android verf¨ ugbar ist. RMI Remote Method Invocation (RMI) ist ein Java-spezifischer Standard, der ebenfalls das Konzept von Remote Object implementiert [ORA11]. Dabei arbeitet RMI, wie CORBA auch, bin¨ ar. Eine Besonderheit ist hierbei, dass Marshalling-Zeiten fast vollst¨andig wegfallen, da Objekte direkt aus dem Speicher versendet werden k¨onnen. Wie auch CORBA verwendet RMI einen Namensdienst, der entfernte Objekte zwischen Client und Server vermittelt. Namensdienste k¨ onnen im Cloud-Umfeld sehr hilfreich sein, da trotz h¨aufig wechselnder IP-Adressen der RMI-Server durch den Namensdienst mit fester IP immer ein Frontend zur Verf¨ ugung steht, welches Objekte nach außen vermitteln kann. RMI verwendet TCP-Verbindungen wieder und unterst¨ utzt SSL-Verschl¨ usselung. Leider sind die effizienten Protokolle CORBA und RMI f¨ ur Android -Ger¨ate nicht verf¨ ugbar. Dies liegt an den in der Android Systembibliothek fehlenden Klassen f¨ ur Java RMI16 , die auch f¨ ur eine CORBA-Implementierung ben¨otigt werden. Zusammenfassung Die Wahl einer effizienten Codierung und eines effizienten Protokolls erscheint zun¨achst vielf¨altig. Tabelle 4.3 zeigt jedoch, dass nur bin¨are Codierungen den Anforderungen von MCC bez¨ uglich Datenoverhead entsprechen k¨onnen. Zudem sind die beiden sehr effizienten Technologien RMI und CORBA f¨ ur Android nicht verf¨ ugbar. Die einzige Standardvariante, die zur Kommunikation im MCC-Umfeld tauglich ist, ist eine persistente HTTP-Verbindung, beispielsweise in Kombination mit RESTful Web services, und eine bin¨are Datencodierung als Byte-Datenstrom. Damit wird die Modellierung der Marshallingzeit ∆tmarshall und des Datenoverheads f¨ ur Marshalling marshall(msg size) f¨ ur die Performancevorhersage der Netz¨ werkkommunikation obsolet. Es wird im Weiteren davon ausgegangen, dass die Ubertragungs15 16

Verf¨ ugbar unter Onlineressource http://www.jacorb.org/ (abgerufen am 16.2.2014) Java-Bytecode wird auf einer JVM ausgef¨ uhrt. Auf der Android Plattform wird hingegen die Dalvik VM benutzt. Diese f¨ uhrt modifizierten Bytecode aus, der nicht JVM-kompatibel ist. Dieser modifizierte Dalvik-Bytecode wird aus dem Java-Bytecode durch einen speziellen Compiler erzeugt. Da RMI Objektserialisierung verwendet, um Objekte auszutauschen, kann es zu Inkompatibilit¨ aten zwischen Dalvik-Objekten und Java-Objekten kommen. Deshalb steht RMI f¨ ur Android nicht zur Verf¨ ugung. (siehe Onlineressource http://www.pcwelt.de/ratgeber/ Unterschiede-zwischen-JVM-und-Dalvik-VM-Smartphone-Grundlagen-1005308.html(abgerufen am 25.1.2014))

60

4.3 Wiederverwendung von TCP-Verbindungen und Pipelining

Tabelle 4.3: Nachrichtengr¨ oßen von 1.048.576 Werten verschiedenen Typs in verschiedenen Codierungen in MB Art

double

int

byte

String *

SOAP/Axis2

Text

54.59

35.51

1.42

1.06

RESTeasy/JSON

Text

19.61

7.08

1.01

1.03

RMI

bin¨ar

8.11

4.06

1.02

1.02

CORBA/JacORB

bin¨ar

8.05

4.06

1.02

1.02

* String mit 1.048.576 Zeichen.

daten bereits als Byte-Datenstrom vorliegen und dass somit durch die Kommunikationstechnologie kein weiteres Marshalling erfolgen muss.

4.2.5 Zusammenfassung Grundperformance ¨ Die gemessenen Ubertragungsbandbreiten lagen f¨ ur Ende-zu-Ende Verbindungen in den drei Konfigurationen CAMPUS, HOME und UMTS/HSPA (siehe Tabelle 4.1) bei maximal ca. 10 Mbit/s und sind oft wesentlich niedriger. Diese geringen Werte machen es notwendig, die Kommunikation so effizient wie m¨ oglich zu gestalten. Dies wirkt sich vor allem auf die Codierung der Daten aus, die bin¨ ar u ¨bertragen werden sollten. Als positiv hat sich herausgestellt, dass die meisten Verbindungsarten duplexf¨ahig sind und somit Download und Upload gleichzeitig genutzt werden k¨ onnen. Ein sehr negativer Fakt ist der daten- und zeitintensive Aufbau einer verschl¨ usselten TCP-Verbindung. F¨ ur feingranulare Daten¨ ubertragungen sollte deshalb eine bestehende TCP-Verbindung wiederverwendet werden. Als einzig verf¨ ugbare Kommunikationstechnologie, die Wiederverwendung und bin¨are Daten¨ ubertragung unterst¨ utzt, kann HTTP verwendet werden. Aus diesem Grund werden HTTP und verwandte Technologien sowie verschiedene Implementierungen im folgenden Abschnitt genauer untersucht. Ein etwas unerwartetes Ergebnis dieses Kapitels war, dass UMTS/HSPA-Verbindungen im Durchschnitt weniger st¨ oranf¨ allig waren als WLAN-Verbindungen. Diese Beobachtung macht aber auch deutlich, dass die mobile Kommunikation im Freien der Performance von WLAN in Geb¨auden ¨ ahnlich ist und somit k¨onnen per WLAN genutzte Applikationen mit ¨ahnlicher Geschwindigkeit auch im Freien genutzt werden. Aus Sicht der Kommunikationsperformance kann somit die Anforderung, vormals station¨ar genutzte Applikationen auch unterwegs zu nutzen, erf¨ ullt werden.

4.3 Wiederverwendung von TCP-Verbindungen und Pipelining Der Aufbau einer verschl¨ usselten TCP-Verbindung im mobilen Umfeld ist sehr zeitintensiv. Dies wurde in den vorangegangenen Unterkapiteln beschrieben. Es ist demnach sinnvoll, eine einmal etablierte verschl¨ usselte TCP-Verbindung f¨ ur verschiedene Serveranfragen wiederzuverwenden. Diese Technik wird im Web-Umfeld bereits h¨aufig eingesetzt und ist unter dem Namen HTTP Pipelining standardisiert [FGM+ 99]. Dieses Kapitel untersucht, wie die entfernte Ausf¨ uhrung von Programmcode f¨ ur MCC-Anwendungen u ¨ber eine einzige TCPVerbindung organisiert werden kann und vergleicht verschiedene Implementierungen. Dass

61

3500

separate 3000

TCP Verbindungen Dauer in ms

2500

eine TCP Verbindung

2000 1500 1000

mit Pipelining t

PIPE HTTP

40

30

20

10

0

b

1K

Kb 10

0x

0 10

x

b 0K

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Sequenznummer des Tasks

0 10

0

10

Download Idle

500

50

x 10

Upload Berechnung

PIPE 5kB HTTP 5kB PIPE 10kB HTTP 10kB

erreichte Übertragungsgeschwindigkeit in kB/s

4 Verbindungen in 3G und WLAN Netzwerken

¨ Abbildung 4.11: Links: Schematische Darstellung Pipelining. Mitte: Ubertragungsdauer von Nachrichten (5 kB und 10 kB) in einer Sequenz mit und ohne Pipelining. Rechts: Bandbreitenausnutzung u ¨berlagerter Datentransfers (Min, Avg, Max). Pipelining f¨ ur MCC-Anwendungen Vorteile bringen kann, wurden in [FR12] bereits gezeigt und wird nachfolgend noch ausf¨ uhrlicher betrachtet.

4.3.1 Voraussetzungen und Modellierung von Pipelining Beim Pipelining werden unabh¨ angig zu verarbeitende Daten direkt nacheinander an den Server zur Verarbeitung gesendet, ohne jeweils die Bearbeitung der Zwischenergebnisse abzuwarten [KEEH10]. Abbildung 4.11 (links) zeigt eine schematische Darstellung des PipeliningKonzepts im Vergleich zu jeweils einzelnen TCP-Verbindungen f¨ ur jeden Aufruf. In der Darstellung wurde davon ausgegangen, dass sich aufgrund der geringeren Daten¨ ubertragungszeiten durch Pipelining die Gesamtverarbeitungsdauer f¨ ur mehrere Anfragen verringert. Beim Pipeling werden die Daten verschiedener Verarbeitungsschritte u ¨ber nur eine TCPVerbindung geleitet. Nachdem eine TCP-Verbindung etabliert wurde, werden die Eingabedaten sequentiell u ¨ber den selben TCP-Kanal zum Server u ¨bertragen. Auf Serverseite werden die ankommenden Daten verarbeitet. Die Ergebnisse werden u ¨ber den gleichen TCP-Kanal zur¨ uck zum Client u ¨bertragen. Besonders gut funktioniert dieses Verfahren, wenn die Verarbeitungsschritte unabh¨ angig sind und dadurch keine Reihenfolge eingehalten werden muss. ¨ So kann ein fortlaufender Datenstrom entstehen, der die Ubertragungsbandbreite m¨oglichst gut ausnutzt. Ein Verarbeitungsschritt kann als Task aufgefasst werden. Ein Task besteht dabei aus den Eingabedaten, die zum Server u ¨bertragen werden, der Verarbeitungsfunktion und den resultierenden Ausgabedaten, die durch den Server generiert und zur¨ uck zum Client u unstig, wenn sich ein Programm in einzelne unabh¨angige ¨bertragen werden. Es ist demnach g¨ Tasks zerlegen l¨ asst. F¨ uhrt man nur einen Task aus, ist das Verhalten einem entfernten Prozeduraufruf ¨ ahnlich. L¨ asst sich ein Programm nicht in einzelne unabh¨angige Tasks zerlegen, so kann das Pipelining nicht effizient verwendet werden. In der Mitte von Abbildung 4.11 sind die Ergebnisse synthetischer Benchmarks abgebildet. ¨ Diese zeigen die Ausf¨ uhrungszeit einer Sequenz von einzelnen Tasks (5 kB und 10 kB Ubertragungsdaten) unter Verwendung einzelner HTTP-Verbindungen und unter Verwendung von Pipelining (PIPE) auf einer einzigen TCP-Verbindung. Es wurde ein Echo-Task verwendet, der keine Verarbeitung durchf¨ uhrt, sondern nur die Eingabedaten zur¨ ucksendet. Gemessen

62

4.3 Wiederverwendung von TCP-Verbindungen und Pipelining

wurde in der UMTS/HSPA-Konfiguration zu einem Server im Amazon EC2 Rechenzentrum in Irland unter Verwendung des Dell Streak 7 Tablets. Wie erwartet braucht mit der Pipeling Technik nur die erste Anfrage etwas l¨anger im Vergleich zu den nachfolgenden Anfragen, die u ¨ber den gleichen TCP-Kanal gesendet werden. Dabei werden in diesem Beispiel RPCAufrufe sogar u ¨berlappt, um die Bandbreitenausnutzung zu verbessern. Da die u ¨berlappten Aufrufe aber nicht synchronisiert sind, k¨onnen einzelne Aufrufe sogar l¨anger dauern als nicht u ugbare Netzwerkbandbreite eventuell von mehreren konkurrierenden ¨berlappte, da die verf¨ Aufrufen geteilt werden muss. F¨ ur die RPC-Aufrufe bleibt die Ausf¨ uhrungszeit aufgrund konkurrierender Netzwerknutzung konstant oder steigt sogar an. Durch Pipelining kann ab dem ¨ zweiten Task bereits davon ausgegangen werden, dass die volle verf¨ ugbare Ubertragungsbandbreite T hroughputmax Duplex genutzt werden kann. Dadurch vereinfacht sich die Berechnung von ∆ttransfer zu ∆ttransfer PIPE wie folgt:

∆ttransfer PIPE =

msg size . T hroughputmax Duplex

(4.6)

In Abbildung 4.11 (rechts) ist der gemessene Durchsatz f¨ ur insgesamt 1 MB Nutzdaten und verschiedene Anzahlen von Tasks zu sehen. Es wurden 10 Messungen f¨ ur jedes Szenario vorgenommen. Es ist zu sehen, dass der Overhead f¨ ur HTTP mit jeweils wenig Nutzdaten pro Aufruf h¨ oher ist. Dem gegen¨ uber ist der Durchsatz bei allen drei Tests f¨ ur das Pipelining Konzept nahezu gleich. Beim Pipelining ensteht durch die asynchrone Verarbeitung jedoch auch eine Wartezeit zwischen dem Zeitpunkt, zu dem ein Task versendet wird und dem Zeitpunkt, zu dem die verarbeiteten Daten wieder am Client vorliegen. Diese Zeit ∆tdelay setzt sich zusammen aus der entfernten Verarbeitungszeit inklusive Datentransfer (siehe Gleichung (3.13)) und der eventuellen Wartezeit ∆tqueue , die der Task aufgrund des Pipelinings in den Warteschlangen auf Client- und Serverseite verbringt:

∆tdelay = ∆tremote + ∆tqueue .

(4.7)

Diese Wartezeit ist in Abbildung 4.11 (links) grau dargestellt. Es bedarf somit Warteschlangen auf Serverseite und auf Clientseite, um solche wartenden Tasks zwischenzuspeichern. Dies ist notwendig, um die Taskverarbeitung auf Serverseite nicht zu blockieren. Die Warteschlange f¨ ur eingehende Tasks auf Clientseite muss stets groß genug sein, um alle eingehenden Tasks zu speichern. Wird n¨ amlich auf das Eintreffen eines bestimmten eingehenden Tasks gewartet w¨ahrend die Warteschlange voll wird, kommt es zu einem Deadlock, da keine neuen Tasks mehr aufgenommen werden k¨ onnen, aber auch keine entnommen werden.

4.3.2 Pipelining-Implementierungen Um das Konzept der Task-Verarbeitung u ¨ber eine einzige TCP-Verbindung zu realisieren, wurde im Rahmen dieser Arbeit ein Protokoll entworfen, welches den Nachrichtenaustausch zwischen Client und Server spezifiziert. Das Protokoll beginnt nach dem Aufbau einer SSLverschl¨ usslten TCP-Verbindung zun¨achst durch den Client mit dem Senden einer Pr¨aambel. Diese wird vom Server ausgewertet und entsprechend beantwortet. Sinn und Gestalt der Pr¨aambel werden sp¨ ater in Kapitel 7 genauer beleuchtet. Danach tauschen Client und Server solange Nachrichten aus, bis einer von beiden, u ¨blicherweise der Client, die Verbindung

63

4 Verbindungen in 3G und WLAN Netzwerken

trennt. Es wird in Client –> Server -Nachrichten und Server –> Client-Nachrichten unterschieden. Das Taskaustauschprotkoll wird dabei auf ein kompatibles Protokoll abgebildet, welches Pipelining unterst¨ utzen muss. Nachfolgend werden m¨ogliche Protokolle, die Abbildung des Task-Konzepts auf diese und deren Eignung f¨ ur MCC genauer betrachtet. HTTP Pipelining HTTP Pipelining ist eine bereits 1999 standardisierte Erweiterung des HTTP-Protokolls [FGM+ 99], die neben dem Etablieren einer persistenten TCP-Verbindung f¨ ur weitere Anfra¨ gen mittels keep-alive auch die Uberlagerung von Anfragen und Antworten u ¨ber die TCPVerbindung unterst¨ utzt. So muss nicht erst die Antwort auf eine Anfrage abgewartet werden, bevor die n¨ achste Anfrage abgesendet wird. HTTP Pipelining hat jedoch einen Nachteil, der die Anwendung des Pipelinings de facto unm¨oglich macht. HTTP Pipelining unterst¨ utzt nur synchrones Pipelining. Das bedeutet, dass beim Client eingehende Antworten in der gleichen Reihenfolge ankommen m¨ ussen, wie die Anfragen gesendet wurden. Sendet ein Client nun eine sehr komplexe Anfrage zuerst und schiebt viele einfache Anfragen hinterher, muss der Server die Ergebnisse der einfachen Anfragen zwischenpuffern, da die Antwort der komplexen Anfrage zuerst gesendet werden muss. Da serverseitige Puffer die Serverperformance aufgrund des erh¨ohten Speicherbedarfs stark ¨ beeintr¨achtigen k¨ onnen, wird das HTTP Pipelining nur selten angewandt. Ubrig bleibt allein die Wiederverwendung der TCP-Verbindung f¨ ur sequentielle Anfragen, was die Performance von Folgenanfragen jedoch auch schon stark verbessert. Somit kann HTTP Pipelining f¨ ur MCC-Anwendungen nicht im Zusammenspiel mit asynchroner Taskverarbeitung angewendet werden. SPDY Eine Weiterentwicklung des HTTP Pipelinings ist in dem seit einigen Jahren immer beliebter werdenden SPDY-Protokoll zu sehen [TJA12, Mat13]. SPDY ist keine Abk¨ urzung, sondern leitet sich vom englischen Wort speedy (deutsch schnell ) ab. Dieses ist bereits in einer Vielzahl von Webbrowsern integriert und unterst¨ utzt neben den aus HTTP bekannten Eigenschaften auch asynchrones Pipelining. Zudem k¨ onnen die Header in SPDY komprimiert werden, was den Datenoverhead f¨ ur kleine Nachrichten stark reduziert. Da die Reihenfolge der Anfragen und Antworten bei SPDY nicht erhalten werden braucht, kann ein konstanter Datenstrom zwischen dem Client und einem Server realisiert werden, wodurch die Duplexeigenschaften einer TCP-Verbindung bestm¨ oglich ausgenutzt werden und sich die Bandbreitenausnutzung maximiert. SPDY implementiert ein bidirektionales Datenaustauschprotokoll, bei dem verschiedene Datenstr¨ome (Streams) u usselte) TCP-Verbindung gemultiplext wer¨ber eine einzige (verschl¨ ¨ den k¨onnen. Dazu nutzt SPDY verschiedene Rahmen (Frames), die zur Ubermittlung von Nutzdaten eines Streams (Data Frames) oder zur Steuerung der Streams selbst (Control Frame) verwendet werden (siehe Abbildung 4.12). Ein Frame umfasst stets 8 Byte Headerdaten. Nachdem bereits eine TCP-Verbindung aufgebaut wurde, beginnt das Erstellen eines neuen Streams mit dem Senden eines SYN_STREAM Frames. Darin sind ebenfalls die Headerinformationen wie beispielsweise die URL der angefragten Web-Ressource codiert. Der Server antwortet mit einem SYN_REPLY Frame. Darin ist die ausgehandelte Stream-ID enthalten.

64

4.3 Wiederverwendung von TCP-Verbindungen und Pipelining SPDY Control Frame +----------------------------------+ |C| Version(15bits) | Type(16bits) | +----------------------------------+ | Flags (8) | Length (24 bits) | +----------------------------------+ | Data / Header | +----------------------------------+

SPDY Data Frame +----------------------------------+ |C| Stream-ID (31bits) | +----------------------------------+ | Flags (8) | Length (24 bits) | +----------------------------------+ | Data | +----------------------------------+

Abbildung 4.12: Schematische Darstellung der SPDY Protokoll Frames. (siehe Onlineressource http://www.chromium.org/spdy/spdy-protocol/ spdy-protocol-draft1 (abgerufen am 16.2.2014)) Empfangene weitere Data Frames zu diesem Stream k¨onnen nun als Antwort interpretiert werden. Außerdem k¨ onnen Data Frames auch zum Server u ¨bertragen werden. Zu beachten ist, dass eine große Nachricht in mehreren Data Frames u ¨bertragen werden kann. Das Schließen eines Streams wird durch das Senden des Control Frames GOAWAY realisiert. Eine einzelne Daten¨ ubertragung wird mittels SPDY u ¨blicherweise in einem dedizierten Stream gekapselt. SPDY befindet sich derzeit noch in der Standardisierungsphase17 . Die Standardisierung von SPDY begann 2009 mit Draft 1 und ist 2013 bereits bei Draft 3 (SPDY/3) angelangt. Eine weitere Version, Draft 4, wird bereits erwartet. F¨ ur Java gibt es bereits einige SPDYImplementierungen. In dieser Arbeit wird vor allem die Implementierung OkHttp18 in ihrer aktuellen Version 1.1.1 f¨ ur Android und Java-Applikationen betrachtet. Diese Implementierung unterst¨ utzt SPDY/3. Zudem wurde noch die Jetty-Implementierung des SPDY Protokolls19 in der Version 7.6.2 betrachtet, welche jedoch nicht f¨ ur Android verf¨ ugbar ist. Dies liegt daran, dass diese Implementierung Java 7 ben¨otigt, welches auf Android -Ger¨aten derzeit noch nicht unterst¨ utzt wird. Die Jetty SPDY-Implementierung unterst¨ utzt SPDY/2 und ¨ verwendet Java Socket Channels, welche eine hohe messbare Ubertragungsperformance versprechen. Die Jetty-Implementierung ist somit eher als eine Art Referenz zu betrachten und erm¨oglicht die bessere Einordnung der Performance anderer Implementierungen. Pipelining Zus¨atzlich wurde eine eigene Implementierung auf Basis von TCP-Sockets und SSL entwickelt. Die Implementierung ist f¨ ur Android -Ger¨ate und JRE-kompatible standardkonforme Java-Implementierungen wie dem OpenJDK oder Oracle Java verf¨ ugbar. ¨ In Abbildung 4.13 sind die Frames der Ubertragungsdaten beschrieben. In dieser Implementierung wird zwischen Client -> Server und Server -> Client Frames unterschieden. Die Eigenimplementierung ist bereits explizit an das Transferieren von Tasks angepasst. Die Zuordnung zwischen versendetem Task und eingehendem Ergebnis erfolgt auf Clientseite und wird durch eindeutige Task-IDs realisiert, die mit u ¨bertragen werden. Dies ist notwendig, da im Gegensatz zum HTTP Pipelining die Reihenfolge der eintreffenden Antworten verletzt werden darf. 17

siehe Onlineressource http://www.chromium.org/spdy/spdy-protocol (abgerufen am 16.2.2014) Verf¨ ugbar unter Onlineressource http://square.github.io/okhttp/ (abgerufen am 16.2.2014) 19 Verf¨ ugbar unter Onlineressource http://wiki.eclipse.org/Jetty/Feature/SPDY (abgerufen am 16.2.2014) 18

65

4 Verbindungen in 3G und WLAN Netzwerken Client -> Server +----------------------------------+ | L¨ ange der Task-ID (4 Byte) | +----------------------------------+ | Task-ID (5 - ca.12 Byte) | . ... . +----------------------------------+ | L¨ ange der Taskfunktion (4 Byte) | +----------------------------------+ | Taskfunktion (4 - ca.30 Byte) | . ... . +----------------------------------+ | L¨ ange der Input-Daten (4 Byte) | +----------------------------------+ | Input-Daten ( >= 0 Byte) | . ... . +----------------------------------+

Server -> Client +----------------------------------+ | L¨ ange der Task-ID (4 Byte) | +----------------------------------+ | Task-ID (5 - ca.12 Byte) | . ... . +----------------------------------+ | L¨ ange des Fehlercodes (4 Byte) | +----------------------------------+ | Fehlercode ( >= 0 Byte) | . ... . +----------------------------------+ | L¨ ange der Output-Daten (4 Byte) | +----------------------------------+ | Output-Daten ( >= 0 Byte) | . ... . +----------------------------------+

Abbildung 4.13: Schematische Darstellung der Pipelining Frames. Ein Task wird bei dieser Implementierung unter Verwendung einer Client->Server-Nachricht vom Client zum Server u ¨bertragen. Eine Nachricht besteht aus der Task-ID, dem Namen der auszuf¨ uhrenden Task-Funktion und den eigentlichen Eingabedaten des Tasks. Somit ist mindestens mit einem Verwaltungsoverhead bez¨ uglich der u ¨bertragenen Input-Daten von 21 Byte pro Task zu rechnen. Dieser Overhead kann jedoch aufgrund einer l¨angeren Task-ID oder Task-Funktion auch leicht gr¨ oßer werden. Die L¨angen der Task-ID und Task-Funktion sind nicht begrenzt, sie k¨ onnen jedoch mit maximal 12 bzw. 30 Byte durch Erfahrungen aus der Praxis abgesch¨ atzt werden. ¨ In umgekehrter Richtung wird die nicht mehr ben¨otigte Ubertragung der Taskfunktion ¨ ¨ durch die optionale Ubertragung einer Nachricht im Fehlerfalle ersetzt. Die Ubertragung vom Server zum Client ist in einer Sever->Client-Nachricht gekapselt. In dieser Richtung ist demnach mit einem Overhead von mindestens 17 Byte pro Task zu rechnen.

4.3.3 Benchmarks Die im vorangegangenen Abschnitt vorgestellten, f¨ ur MCC-tauglichen Kommunikationstechnologien OkHttp, Jetty SPDY und das selbst implementierte Pipeliningprotokoll wurden ¨ bez¨ uglich des erreichbaren Ubertragungsdurchsatzes untersucht. Dazu wurde von dem Dell Latitude Laptop eine verschl¨ usselte Ende-zu-Ende Verbindung zu einer virtuellen Maschine im Rechenzentrum von Amazon EC2 in Irland aufgebaut. Es wurden jeweils 1 MB Nutzdaten hin und zur¨ uck u uckelungen 10x100 kB, 100x10 kB und ¨bertragen. Dazu wurden die St¨ 1000x1 kB verwendet. Es wurden 30 Messungen f¨ ur alle drei Konfigurationen durchgef¨ uhrt. Abbildung 4.14 visualisiert die Ergebnisse. Dargestellt sind Minimum, Maximum und der Mittelwert der jeweiligen Messreihe. Zun¨achst ist wieder deutlich zu erkennen, dass die Messwerte stark schwanken k¨onnen. ¨ Um die Ubersichtlichkeit zu wahren, wurde die Standardabweichung der Messreihen hier nicht angegeben. Die Standardabweichung war jedoch bei allen Verfahren etwa ¨ahnlich. Außerdem sind alle drei Technologien in der Lage, die Pipeliningf¨ahigkeit auch umzusetzen,

66

4.4 Performancevorhersage in Alltagssituationen

Ausführungszeit in ms (Min, Mittelwert, Max)

18000

10x100000kB 100x10000kB 1000x1000kB

16000 14000 12000 10000 8000 6000 4000 2000 0

S

PU

AM

C S

S

Y

D

SP tty

Je

ttp

kH

O

g in lin

Y

D

tty

Je

pe

Pi

SP

Y

D g

in

ttp

kH

O

tty

Je

in

Y

Y

D

l pe

SP

PU

E

Pi

SP

D

ttp

kH

O

g in in

l pe

Y

D

SP

Pi

SP

PU

AM

C

AM

C M

O

H E

M

O

H E

TS

M

O

H

M

U TS

M

U TS

M

U

Abbildung 4.14: Performancevergleich verschiedener Pipelining-f¨ahiger Kommunikationsprotokolle unter Verwendung verschiedener Konfigurationen. was an den etwa gleichbleibenden Ausf¨ uhrungszeiten f¨ ur verschiedene St¨ uckelungen zu erkennen ist. Weiterhin kann an dem Diagramm abgelesen werden, dass in der CAMPUSKonfiguration im Durchschnitt die h¨ochste Datenrate zu erwarten ist. L¨asst man die OkHttpImplementierungen aus den Betrachtungen heraus, ist die Performance in der HOME-Konfiguration und in der UMTS-Konfiguration ¨ahnlich hoch. F¨ ur sehr kleine Nachrichten ist die ¨ Performance von OkHttp oft schlecht und die h¨ochste Ubertragungsgeschwindigkeit erreicht OkHttp f¨ ur die 100x10 kB St¨ uckelung. Die Jetty SPDY und die eigene Pipelining Implementierung sind von der Performance ¨ ahnlich schnell. Obwohl mit der Jetty SPDY-Implementierung eine schnelle und ausgereifte echte PipeliningImplementierung bereits existiert, so ist diese leider nicht f¨ ur Android nutzbar. Die OkHttpImplementierung kann bez¨ uglich der Performance besonders f¨ ur kleine Nachrichten nicht u ¨berzeugen. Abschließend wird im Weiteren die eigene Pipelining-Implementierung genutzt, da diese eine gute Leistung erzielt und f¨ ur alle betrachteten Ger¨ate/Plattformen verf¨ ugbar ist. Die konkrete Java-API dieser Implementierung wird in Kapitel 7 vorgestellt.

4.4 Performancevorhersage in Alltagssituationen Die G¨ ute der Vorhersage in Alltagssituationen wurde durch mehrere Messungen unter Verwendung der eigenen Pipeliningimplementierung in den in Tabelle 4.1 beschriebenen Konfigu-

67

4 Verbindungen in 3G und WLAN Netzwerken

UMTS Request/Response RTT ca. 100ms 3

2.5

2.5

Datendurchsatz in Mbit/s

Datendurchsatz in Mbit/s

UMTS Pipelining RTT ca. 100ms 3

2 1.5 1 0.5

10kB Durchschnitt 10kB 50kB Durchschnitt 50kB 100kB Durchschnitt 100kB Vorhersage

2 1.5 1 0.5

0

0 0

5

10

15

20

0

3

2.5

2.5

2 1.5

15

20

1 0.5

2 1.5 1 0.5

0

0 0

5

10

15

20

0

CAMPUS Pipelining RTT ca. 45ms

5

10

15

20

CAMPUS Request/Response RTT ca. 45ms 10 Datendurchsatz in Mbit/s

10 Datendurchsatz in Mbit/s

10

HOME Request/Response RTT ca. 80ms

3 Datendurchsatz in Mbit/s

Datendurchsatz in Mbit/s

HOME Pipelining RTT ca. 80ms

5

8 6 4 2 0

8 6 4 2 0

0

5

10

15

20

0

5

10

15

20

¨ Abbildung 4.15: Auswertung der vorhergesagten Ubertragungsgeschwindigkeiten f¨ ur die ¨ Ubertragung von Tasks im Pipeliningmodus und im Request/ResponseModus f¨ ur verschiedene Konfigurationen. rationen durchgef¨ uhrt. Dazu wurde serverseitig eine virtuelle Maschine das Anbieters Amazon EC2 EU Irland benutzt. Zun¨achst wurde die verf¨ ugbare Netzwerkperformance in drei aufeinander folgenden Messungen bestimmt. Dazu wurde das frei verf¨ ugbare Werkzeug SPEEDTEST.NET MINI 20 benutzt, welches ebenfalls auf dem Testserver installiert wurde. SPEEDTEST.NET MINI ist eine Web-Applikation, die in einem Webbrowser ausgef¨ uhrt wird. Sie u ¨bertr¨agt Datei¨ en zum Server und zur¨ uck und misst dabei die maximale Ubertragungsbandbreite. Detailliertere Informationen zu SPEEDTEST.NET MINI sind in Kapitel 7.2.1 u ¨ber Aufbau und Implementierung der entwickelten Middleware zu finden. Zus¨atzlich kann die RTT auf Android -Ger¨aten beispielsweise u ¨ber die kostenlose Applikation Android Terminal Emulator 21 , welche eine Kommandozeile bereitstellt, und das Kommandozeilenprogramm ping bestimmt werden. Außer diesen Informationen und der verwendeten Kommunikationstechnologie hat der Anwender zur Laufzeit keine weiteren Informationen verf¨ ugbar. Nach Bestimmung der durchschnittlichen Kommunikationsperformance wurde unter Be20 21

Verf¨ ugbar unter Onlineressource http://www.speedtest.net/mini.php (abgerufen am 3.2.2014) Verf¨ ugbar unter Onlineressource http://play.google.com/store/apps/details?id=jackpal. androidterm (abgerufen am 3.2.2014)

68

4.4 Performancevorhersage in Alltagssituationen

achtung der Ergebnisse aus Abschnitt 4.2 und Gleichung (4.5) die realistische verf¨ ugbare Bandbreite bestimmt. Aufgrund des gemessenen Variationskoeffizienten von ca. 0.3 wurde die gemessene Geschwindigkeit pessimistisch eingesch¨atzt und um 30% verringert. Die nachfolgende Gleichung fasst die Bildung von T hroughputmax f¨ ur die durchgef¨ uhrten Messungen zusammen:

T hroughputmax = M IN (∅T hroughputupload , ∅T hroughputdownload ) · 0.7.

(4.8)

Anschließend wurde eine Pipeliningverbindung aufgebaut und 20 Echo-Tasks wurden gestartet. Ein Echo-Task T aski besteht aus einer Bytefolge an Eingabedaten msg sizeT aski , die zum Pipeliningserver u ¨bertragen werden. Der Server schickt die Daten als Ergebnis der Taskausf¨ uhrung jedoch sofort unangetastet zur¨ uck. Aus dem Abstand des Eintreffens der Ergebnisse tF in T aski und tF in T aski−1 l¨asst sich dann bei Kenntnis der L¨ange der Bytefolge die ¨ ausgesch¨ opfte Ubertragungsbandbreite T hroughputT aski auf der Anwendungsschicht messen. Sie wird wie folgt bestimmt:

T hroughputT aski

=

tF in

msg sizeT aski . T aski − tF in T aski−1

(4.9)

Abbildung 4.15 (links) zeigt den gemessenen Durchsatz f¨ ur alle 20 gestarteten Tasks in den drei verschiedenen Konfigurationen unter Verwendung des Dell Streak 7 Tablets. Dargestellt ist zudem auch der Mittelwert f¨ ur die drei jeweils gemessenen Eingabegr¨oßen 10 kB, 50 kB und 100 kB. Erkennbar ist zun¨ achst, dass die erste Messung f¨ ur T ask0 unbrauchbar ist, da vorher kein Zeitstempel zum Vergleich existiert. Hier wurde der Zeitstempel des Startens des ersten Tasks verwendet. Es ist weiterhin zu erkennen, dass die gemessenen Werte stark schwanken, insbesondere f¨ ur die kleinste Testgr¨oße 10 kB. Dies ist der Tatsache geschuldet, dass hier die Messzeiten sehr klein waren (<50ms), sodass sich kleine Abweichungen aufgrund von St¨orungen stark auf die Bandbreitenmessung auswirken. F¨ ur die gr¨oßeren Eingabedaten schwanken die Werte weniger stark. Am geringsten f¨allt die Schwankung f¨ ur UMTS aus, was bereits erwartet wurde (siehe Abbildung 4.15 (links)). Außerdem liegt der Mittelwert der gemessenen Bandbreite f¨ ur alle Tasks in etwa im Bereich der Vorhersage. Dies trifft insbesondere f¨ ur UMTS und die CAMPUS-Konfiguration zu. F¨ ur die HOME-Konfiguration lag der vorhergesagte Wert etwas unterhalb des Mittelwerts. Somit kann prinzipiell davon ausgegan¨ gen werden, dass die vorhergesagten Ubertragungsbandbreiten im Durchschnitt auch real zu erreichen sind. Hierbei ist jedoch gerade f¨ ur kleine Eingabegr¨oßen mit großen Schwankungen zu rechnen. In einem weiteren Test wurde ermittelt, welche Leistung bei der Abbildung von RPCAufrufen auf das Pipeliningverfahren zu erwarten ist. Dazu wurden Tasks synchron in Analogie zu RPC-Aufrufen ausgef¨ uhrt. Es wurden erneut 20 Echo-Tasks unter den gleichen Bedingungen wie oben beschrieben gestartet. Doch bevor der jeweils nachfolgende Task gestartet wurde, wurde auf das Eintreffen des Ergebnisses des vorhergehenden Tasks gewartet. Eine Messung umfasst also den Zeitraum vom Absenden des Tasks bis zum Eintreffen des Ergebnisses auf der Anwendungsschicht. Da serverseitig keine Verarbeitung stattfindet und keine Marshalling ben¨ otigt wird, wird die messbare Verarbeitungszeit ∆tremote T aski eines Task T aski unter Beachtung von Gleichung (4.2) und Gleichung (4.6) wie folgt angegeben:

69

4 Verbindungen in 3G und WLAN Netzwerken

∆tremote

T aski

=

msg sizeT aski · 2 + RT T. T hroughputT aski

(4.10)

Die msg sizeT aski ist doppelt ber¨ ucksichtigt, da die Daten jeweils hin und zur¨ uck u ¨bertragen werden. Die RTT wird in die Gleichung aufgenommen, damit die Gleichung auch G¨ ultigkeit besitzt, wenn keine Nutzdaten u urden nur wenige ¨bertragen werden. In diesem Fall w¨ Byte zum Server und zur¨ uck u ¨bertragen werden, was in etwa der RTT entsprechen sollte. ¨ Nach Umstellung kann man die erreichte Ubertragungsgeschwindigkeit f¨ ur einen einzelnen Task T aski wie folgt ermitteln:

T hroughputT aski

=

∆tremote T aski − RT T . msg sizeT aski · 2

(4.11)

Abbildung 4.15 (rechts) visualisiert die gemessene Daten¨ ubertragungsgeschwindigkeit f¨ ur 20 aufeinander folgende sequentielle Task-Ausf¨ uhrungen. Die hier gemessenen Werte schwanken weniger stark als die der Pipelining-Messung. Dies liegt darin begr¨ undet, dass bei den RPC-Aufrufen kein gleichzeitiger Upload und Download stattfindet und somit keine zwei Datenstr¨ome abwechselnd u ussen, was bei WLAN aufgrund der fehlenden ¨bertragen werden m¨ Voll-Duplex-F¨ ahigkeit zu starken Schwankungen f¨ uhren kann. Jedoch sind auch vor allem bei der CAMPUS-Konfiguration Schwankungen u ¨ber die Dauer der 20 Messungen zu erkennen. ¨ Auch hier ist der ausgesch¨ opfte Datendruchsatz bei kleinen Ubertragungsdaten geringer. Hier spielt die RTT offenbar noch eine Rolle. Bei gr¨oßeren Daten relativiert sich deren Einfluss. ¨ Auch hier ist erkennbar, dass f¨ ur die gr¨oßeren Daten die durchschnittliche Ubertragungszeit in etwa dem vorhergesagten Wert entspricht. ¨ Insgesamt zeigen die Messungen auch, dass bei Einsatz des Pipelinings sehr ¨ahnliche Ubertragungscharakteristiken f¨ ur die einzelnen Technologien messbar sind. Zudem ist die Schwan¨ kungsbreite des messbaren Ubertragungsdurchsatzes unter Verwendung von Pipelining immer ¨ noch sehr hoch. Somit sind die prognostizierten Ubertragungswerte eher als Erwartungswert zu verstehen. Dies reicht aus, um bei einer Vielzahl von Tasks eine Taskverarbeitungsrate anzugeben. Es ist jedoch nicht m¨ oglich, einen definierten konstanten Abstand des Eintreffens der Ergebnisse der Taskverarbeitung einzuhalten. F¨ ur einzelne RPC-Aufrufe kann im Allgemeinen von weniger schwankenden Werten ausgegangen werden, sodass ab ca. 50 kB eine relativ genaue Vorhersage der Verarbeitungsdauer gemacht werden kann.

4.5 Fazit Mobile Endger¨ ate und kabellose Netzwerkverbindungen haben besondere Charakteristiken und stellen besondere Anforderungen an Kommunikationstechnologien. Diese Charakteristiken wurden unter Verwendung verschiedener Konfigurationen und Ger¨ate analysiert. Dabei wurden ausgehend von der Grundperformance die Duplexf¨ahigkeit, der Einfluss von Verschl¨ usselung und der Datencodierung untersucht. Die Analyse ergab f¨ ur die getesteten WLAN und 3G Mobilfunkverbindungen eine maximale Daten¨ ubertragungsrate im einstelligen MbitBereich, oft hohe RTT-Werte bis in den hohen zweistelligen Millisekundenbereich und von Fall zu Fall unterschiedliche Duplexeigenschaften, die von der Beschaffenheit der tats¨achlichen Ende-zu-Ende Verbindung abh¨ angen. Im Ergebnis ist es deshalb empfehlenswert, eine

70

4.5 Fazit

bereits etablierte TCP-Verbindung f¨ ur mehrere Anfragen wiederzuverwenden, um auch f¨ ur ¨ kleine Nachrichtengr¨ oßen eine gute Ubertragungsperformance zu erreichen und die teils lange Dauer f¨ ur den Aufbau einer verschl¨ usselten TCP-Verbindung zu relativeren. Außerdem sollten Upload und Download auch bei kabelloser Kommunikation u ¨berlagert werden, um die Gesamt¨ ubertragungszeit zu reduzieren. Aufgrund des geringen Overheads ist zudem eine bin¨are Datencodierung zu bevorzugen. Um diese Ergebnisse zur effizienten Kommunikation im mobilen Umfeld umzusetzen, wurden verschiedene Pipelining-f¨ ahige Protokolle auf ihre Tauglichkeit untersucht und verschiedene Implementierungen miteinander verglichen. Dabei stellte sich heraus, dass nur die eigene Pipeliningimplementierung den Anforderungen nach stabilen Ergebnissen und der Einsatzf¨ ahigkeit f¨ ur Android entsprach. Abschließend wurde unter Benutzung der Pipeliningimplementierung u uft, wie gut die ¨berpr¨ ¨ ¨ anhand gemessener Parameter vohergesagten Ubertragungsraten f¨ ur einzelne Ubertragungen ¨ tats¨achlich erreicht werden. Dabei wurden ausschließlich die maximale Ubertragungsrate f¨ ur ¨ Upload und Download und die RTT zur Laufzeit gemessen. Diese realistische Uberpr¨ ufung ergab, dass die vorhergesagten Werte f¨ ur Eingabedaten ab 50 kB im Durchschnitt gut stimmen. F¨ ur kleinere Daten sind die Ergebnisse eher pessimistischer zu bewerten. Zus¨atzlich wurde auch erneut festgestellt, dass die real gemessenen Einzelwerte stark schwanken k¨onnen. Dennoch kann unter Verwendung des Pipelinings die mobile Kommunikationsperformance anhand weniger ad hoc messbarer Werte belastbar abgesch¨atzt werden. Dieses Verfahren wird in den nachfolgenden Kapiteln vorausgesetzt, um die Gesamtverarbeitungsdauer entfernt ausgef¨ uhrten Programmcodes vorherzusagen. Um eine Vorhersage f¨ ur weitere mobile Kommunikationstechnologien zu erstellen, m¨ ussen deren Eigenschaften bez¨ uglich Duplexf¨ahigkeit und Schwankungsbreite bestimmt werden, um zu bestimmen, ob Pipelining sinnvoll angewendet werden kann. Ist dies der Fall, so kann auch ¨ f¨ ur diese Technologien die erwartete Ubertragungsbandbreite anhand der durchschnittlichen Upload und Downloadbandbreite und der RTT einfach bestimmt werden.

71

5 Server-unterstu ¨tzte mobile Anwendungen auf Cloud-Technologien Mobile Cloud-unterst¨ utzte Anwendungen haben zeitlich begrenzte Anforderungen an entfernt verf¨ ugbare Ressourcen, die je nach Anwendung und Nutzerverhalten zwischen wenigen Se¨ kunden bis Minuten betragen k¨ onnen. Ublicherweise werden Cloud-Ressourcen eines IaaSAnbieters jedoch auf Stundenbasis abgerechnet, was zu einem erheblichen Kostenoverhead bei der Nutzung f¨ uhren kann. In diesem Kapitel wird deshalb analysiert, wie die Granularit¨at bez¨ uglich der Ausleihdauer von Cloud-Ressourcen (VMs) f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen erh¨ oht werden kann. Dieses Kapitel beschreibt m¨ogliche Modellierungsvarianten, deren Vor- und Nachteile, sowie deren Abbildung auf ¨offentlich verf¨ ugbare CloudInfrastruktur-Anbieter. Da der Einfluss verschiedener Lastbalancierungsstrategien auf reale Cloud-Infrastruktur im großen Maßstab nur mit erheblichem finanziellen Aufwand bestimmbar w¨are, wird stattdessen eine Simulation durchgef¨ uhrt. Diese wird unter Verwendung m¨oglichst realistischer Eingaben und Simulationsparameter durchgef¨ uhrt, die aus der Literatur und durch eigene Beispielapplikationen unter Verwendung des IaaS-Anbieters Amazon EC2 gewonnen wurden. Compute-Ressourcen (VMs) aus dem Portfolio eines IaaS-Anbieters werden nach dem Selbstbedienungsprinzip genutzt, k¨ onnen jederzeit gestartet werden und werden u ¨blicherweise auf Stundenbasis gemietet. So l¨ asst sich deren Anzahl kurzfristig gut an die momentane Anfragemenge anpassen. In Kapitel 3.2 wurde vorgeschlagen, dass jede Ressourcenanfrage auf eine dedizierte VM zugewiesen werden sollte. Dadurch nutzt jeder Client die Ressource exklusiv und es kann sichergestellt werden, dass die Verarbeitungsgeschwindigkeit einer immer gleichen Anfrage auf der VM kaum schwankt. Zudem steht jedem Client durch die exklusive Nutzung auch die volle Netzwerkbandbreite zur Ressource zur Verf¨ ugung, was auch ¨ diesbez¨ uglich eine stabile Ubertragungsrate liefert. Die Gleichungen (3.15) und (3.16) bilden die Stabilit¨ at der Kommunikationsperformance und der Verarbeitungsgeschwindigkeit ab. Die Stabilit¨at ist wichtig, um belastbare Aussagen bez¨ uglich der Performance von Mobilen Cloud-unterst¨ utzten Anwendungen machen zu k¨onnen. Denn sollte eine entfernte Ausf¨ uhrung in Betracht gezogen werden, so muss aufgrund des enstehenden finanziellen Aufwandes auch eine schnellere Ausf¨ uhrung garantiert sein und die Kostenbeschr¨ankung muss eingehalten werden (siehe Bedingungen (3.12) und (3.18)). Die Art der Modellierung der exklusiven Ressourcenallokation und die daf¨ ur notwendigen Lastbalancierungsstrategien sind jedoch in der Literatur noch nicht beschrieben worden. W¨ urde man f¨ ur jede Anfrage eine neue VM starten, so w¨ urde dies nicht nur lange dauern, sondern es w¨ urde aufgrund der Abrechnungsperiode im Stundentakt eventuell auch ein hoher Kostenoverhead entstehen, da die Nutzungsdauer eher im Minutenbereich liegt. Da die Angebote der IaaS-Anbieter nicht ver¨andert werden k¨onnen, m¨ ussen VM-Instanzen f¨ ur verschiedene Anfragen wiederverwendet werden. Es sind im Rahmen dieser Arbeit Allokationsstrategien und Lastbalancierungsstrategien zu entwerfen, die f¨ ur Clients gewisse Schranken bez¨ uglich der VM-Allokations- und Verarbeitungszeit garantieren, auf deren Basis dann eine realistische Vorhersage der Verarbeitungsdauer der Mobile Cloud-unterst¨ utzte Anwen-

72

5.1 Erh¨ ohung der Granularit¨ at

dungen gemacht werden kann. Im Detail werden also in diesem Kapitel der Einfluss der Gr¨oßen • Dauer f¨ ur Authentifizierung ∆tauth , • Dauer f¨ ur Ressourcenallokation ∆talloc , • Verarbeitungsdauer ∆twork • und die daraus resultierenden Kosten cost in Abh¨angigkeit der gew¨ahlten Ressource R auf die Gesamtverarbeitungszeit ∆tremote (siehe Gleichung (3.17)) unter Verwendung verschiedener Allokations- und Lastbalancierungsstrategien genauer untersucht.

5.1 Erh¨ ohung der Granularit¨ at Es wird davon ausgegangen, dass die zu entwerfende Middleware f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen f¨ ur eine große Menge an Clients bereitgestellt wird. Somit k¨onnen verschiedene Anfragen auf die verf¨ ugbaren VMs zugewiesen werden. Unabh¨angig von der gew¨ahlten Lastbalancierungsstrategie kann unter Verwendung eines IaaS-Anbieters die Anzahl verf¨ ugbarer Ressourcen dem tats¨ achlichen Bedarf flexibel angepasst werden. Somit kann zun¨achst jedem Client eine Ressource zur Verarbeitung zugewiesen werden. Verschiedene Mobile Cloud-unterst¨ utzte Anwendungen ben¨otigen jedoch auch verschiedenen serverseitigen Programmcode, was im Normalfall dazu f¨ uhrt, dass f¨ ur jede Anwendung eine eigene Ausf¨ uhrungsumgebung in Form eines eigenen VM-Images bereitgestellt werden muss. Eine VM f¨ uhrt dann jeweils ein solches Image aus und somit nur eine einzige Anwendung. Jedes VM-Image besteht aus einer kompletten Betriebssysteminstallation nebst installiertem Softwarestack und der eigentlichen Anwendung. Der zeitliche Zugriff auf drei verschiedene Mobile Cloud-unterst¨ utzte Anwendungen, die auf verschiedenen VMs ausgef¨ uhrt werden, ist in Abbildung 5.1 (oben) dargestellt. Jede der drei Applikationen (App1, App2 und App3) wird auf einer zu diesem Anwendungstyp passenden VM ausgef¨ uhrt. VM-Instanzen eines Applikationstyps k¨onnen nicht f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen eines anderen Typs wiederverwendet werden. Da sich die zwei Nutzungszeiten der beiden Mobilger¨ ate f¨ ur App1 und App3 f¨ ur die dargestellte Abfolge jeweils u ussen aufgrund der exklusiven Ressourcenallokationen jeweils zwei VMs ¨berschneiden, m¨ dieses Typs gestartet werden. Obwohl VMs f¨ ur einzelne Nutzungen auch wiederverwendet werden k¨ onnen (beispielsweise App2), werden f¨ ur die Abfolge der dargestellten exklusiven Nutzungsperioden der drei Applikationen insgesamt f¨ unf VMs ben¨otigt. Diese sind rechts oben dargestellt. Als Resultat m¨ ussten in diesem Fall mindestens f¨ unf volle Abrechnungsperioden, also 5 h Nutzungszeit, bezahlt werden. Eine Erh¨ ohung der Granularit¨ at der Nutzungsperiode k¨onnte dieses Problem etwas reduzieren. W¨ urde man die Nutzungsdauer auf Minutenbasis abrechnen, so w¨ urde der Kostenoverhead erheblich sinken. Eine M¨oglichkeit, um die Erh¨ohung der Granularit¨at auf Basis der bestehenden IaaS-Angebote zu realisieren, ist die Wiederverwendung der VMs f¨ ur verschiedene Anwendungen. Somit kann die Auslastung der VM pro Abrechnungsperiode erh¨oht werden und der Kostenoverhead sinkt. Jedoch m¨ usste man bei Wiederverwendung m¨oglicherweise sehr viele Applikationen gleichzeitig auf einer VM installieren. Dies f¨ uhrt unter Umst¨anden zu Performance- und Managementproblemen. Um dieses Problem zu umgehen, wird

73

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

dedizierte Server für einzelne Apps App3

App1

App1

App1

App3

App2

App3

App2 Notwendige VM-Instanzen

App2

App1

App3

Zeitliche Nutzung von Apps

wiederverwendbare Server für verschiedene Apps

All Apps All Apps

Abbildung 5.1: Visualisierung der zeitlichen Nutzung verschiedener Mobiler Cloud-unterst¨ utzter Anwendungen, hier Apps genannt, durch zwei Mobilger¨ate unter Nutzung dedizierter und wiederverwendbarer VM-Instanzen. in der hier vorgestellten Middleware serverseitig kein Programmcode vorinstalliert. Alle VMInstanzen sind identisch und ein Client installiert den Programmcode f¨ ur die benutzte Mobile Cloud-unterst¨ utzte Anwendung selbst. Diese Modellierung erh¨oht zwar den Datentransfer zur ¨ VM aufgrund der zus¨ atzlichen Ubertragung des Programmcodes, jedoch steigt durch die universellen VM-Instanzen die Wiederverwendungsrate stark an und somit sinkt der Kostenoverhead f¨ ur die ungenutzten VM-Laufzeiten. Abbildung 5.1 (unten) visualisiert die bereits beschriebene Abfolge der Nutzungsperioden f¨ ur die drei Applikationen unter Benutzung der universell wiederverwendbaren VMs. Dabei werden nur zwei VM-Instanzen ben¨otigt, da sich stets nur maximal zwei Nutzungsperioden zeitlich u ur die ¨berschneiden, was die Kosten f¨ dargestellte Abfolge erheblich reduziert. Um eine Kostenreduktion zu erreichen, kann beim gleichzeitigen Starten einer gewissen Menge von VMs zus¨ atzlich ein Rabatt gew¨ahrt werden. Dazu muss die Anzahl ben¨otigter VMs im Voraus bekannt sein. Eine Broker-Architektur, die diesen Fakt ber¨ ucksichtigt, ist beispielsweise in [WNLL12] beschrieben. Kostenreduktion kann auch durch die Verwendung von sogenannten Spot-Instanzen erreicht werden, die durch eine Auktion allokiert werden. Diese sind zwar im Schnitt billiger als On-Demand -Instanzen, sie sind jedoch nicht immer verf¨ ugbar und k¨onnen unvermittelt beendet werden. Unter Verwendung dieser Spot-Instanzen k¨onnen jedoch bei Kenntnis der Verarbeitungsdauer auch Performancegarantien gegeben werden. In [MD11] ist eine solche Strategie beschrieben. Da die Verarbeitungsdauer und die Menge ben¨otigter VMs jedoch im Fall von Mobilen Cloud-unterst¨ utzten Anwendungen nicht immer bekannt ist, k¨ onnen diese Verfahren nicht verwendet werden.

74

5.2 Authentifizierung, Abrechnung und Lebenszyklus

Durch die Wiederverwendungstechnik wird das Installieren des Programmcodes zur Laufzeit notwendig. Diese Technik wird h¨aufig als Code-Offloading bezeichnet und wurde in Kapitel 2.2 bereits vorgestellt. Die Codeinstallation zur Laufzeit kostet jedoch nicht nur Zeit ¨ ∆tinstall , es wird auch eine zus¨ atzliche Ubertragung von Daten notwendig (msg sizeinstall ), welche sich nach Gleichung (4.1) und (4.2) in der Kommunikationszeit ∆tcomm niederschl¨agt. Die erh¨ohte Kommunikationszeit wird im folgenden deshalb durch ∆t∗comm angegeben. Das Code-Offloading beeinflusst die entfernte Ausf¨ uhrungszeit ∆tremote wie folgt: ∆tremote = ∆tauth + ∆talloc + ∆tinstall + ∆t∗comm + ∆twork .

(5.1)

Durch die Wiederverwendungsstrategie d¨ urfen jedoch die Bedingungen (3.12) und (3.18) bez¨ uglich der schnelleren Ausf¨ uhrung auf Serverseite und der Begrenzung der Kosten nicht verletzt werden. Dadurch ergeben sich bei Verwendung der Wiederverwendungstechnik folgende zus¨ atzliche Einschr¨ ankungen:

∆tinstall  ∆twork ,

(5.2)

msg sizeinstall  msg sizedata .

(5.3)

Diese Einschr¨ ankungen sind jedoch nicht immer zwingend einzuhalten, da es trotz deren Verletzung noch m¨ oglich sein kann, dass die Bedingungen (3.12) und (3.18) nicht verletzt werden. Sie sind eher als Richtwerte zu verstehen. Da die Codeinstallation zur Laufzeit von der konkreten Anwendung abh¨ angt, wird deren Einfluss nicht hier, sondern in Kapitel 6 untersucht. Zus¨atzlich verringert die erh¨ ohte Wiederverwendungswahrscheinlichkeit von VMs f¨ ur einzelne Anfragen eventuell auch die Allokationszeit ∆talloc . Da eine wiederverwendete VM bereits gestartet ist, f¨ allt die Allokationszeit wesentlich geringer aus. Die Zeit zum Starten einer neuen VM-Instanz wird mit ∆tstartup beschrieben. Es gilt: ∆tstartup ≥ ∆talloc .

(5.4)

Im Beispiel in Abbildung 5.1 (oben) m¨ ussen insgesamt f¨ unf VMs gestartet werden, was in f¨ unf von sechs F¨ allen die entfernte Ausf¨ uhrungszeit verl¨angert. Im unteren Beispiel m¨ ussen nur in zwei von sechs F¨ allen neue VMs gestartet werden, was sich positiv auf die Verarbeitungszeit der vier anderen Anfragen auswirkt. Die Verringerung der durchschnittlichen Allokationszeit ∆talloc ist bei Verwendung der Wiederverwendungstechnik nicht garantiert, die Wahrscheinlichkeit nimmt jedoch mit der Anzahl der Anfragen in einem festen Zeitraum im Allgemeinen zu. Dieser Sachverhalt wird nachfolgend durch eine Simulation noch genauer untersucht.

5.2 Authentifizierung, Abrechnung und Lebenszyklus Bezug nehmend auf Gleichung (5.1) wird klar, dass Authentifizierung und Allokation der ben¨otigten Ressource eine gewisse Zeit ben¨otigen k¨onnen. Nachfolgend werden verschiedene Modellierungsvarianten einer Middleware f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen vorgestellt. Es wird dabei davon ausgegangen, dass eine zertifikatsbasierte verschl¨ usselte

75

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

TCP-Verbindung verwendet wird. In Kapitel 4 wurde erarbeitet, dass eine persistente TCPVerbindung und eine Pipeline-artige Anordnung der Datentransfers notwendig sind, um die verf¨ ugbare mobile Kommunikationsbandbreite gut auszunutzen und somit auch deren Performance einsch¨ atzen zu k¨ onnen. Demnach muss ein Client jeweils nur beim Verbindungsaufbau einmalig authentifiziert werden. Die vorgestellten Architekturen sind dabei auf VMs eines IaaS-Anbieters abgebildet. Aufgrund der verwendeten Verbindung mit TCP-Pipelining kann zwischen der Zeit f¨ ur die Bearbeitung einer einzelnen/ersten Anfrage und der Zeit f¨ ur die Bearbeitung von Folgeanfragen unterschieden werden, bei denen dann ∆tauth = 0 gilt. Nachfolgend werden verschiedene Architekturen einer Middleware f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen vorgestellt und bez¨ uglich Skalierungsf¨ ahigkeit und Lastbalancierung untersucht. Es wird dabei davon ausgegangen, dass mehrere Anfragen/Tasks durch den Client an die VM gesendet werden. Die Middlewarearchitektur beeinflusst die berechnungsintensiven Verarbeitungsschritte ∆tinstall und ∆twork in der gleichen Weise. Somit wird f¨ ur nachfolgende Betrachtungen folgende Vereinfachung angenommen: ∆t∗work = ∆twork + ∆tinstall .

(5.5)

Untersucht werden die Auswirkung auf die Eigenschaften • der Summanden in Gleichung (5.1) bzw. (5.5) (∆tauth , ∆talloc , ∆t∗comm und ∆t∗work ) und • auf das Zertifikat-Management bzw. die Sicherheitsarchitektur bez¨ uglich der Verschl¨ usselung der Kommunikation. Um die Modellierung besser nachvollziehen zu k¨onnen, wird mit einer Architektur bestehend aus einem einzelnen Front-Server begonnen.

5.2.1 Einzelner Front-Server Steht nur ein einziger Server f¨ ur Authentifizierung, Abrechnung und Ausf¨ uhrung der eigentlichen Anfragen zur Verf¨ ugung, so werden alle eingehenden Anfragen auf diesen Server zugewiesen. Eine einzelne Anfrage w¨ urde von einem einzelnen Front-Server dann in folgender Reihenfolge bearbeitet: 1. Authentifizierung des Anfragenden, 2. Bearbeiten der Anfrage(n). Dabei w¨ urde der einzelne Front-Server alle ben¨otigte Funktionalit¨at u ¨bernehmen. Diese Variante bedarf nur eines Server-Zertifikats und ist in Abbildung 5.2 visualisiert. Bei mehreren gleichzeitigen Anfragen sinkt jedoch die Antwortgeschwindigkeit pro Client und es kann keine Performancegarantie gegeben werden. Außerdem m¨ ussen sich alle Clients eventuell eine einzige Netzwerkverbindung zum Server teilen. Somit sinkt auch hier die verf¨ ugbare Bandbreite ¨ pro Client bei mehreren gleichzeitigen Anfragen. Zus¨atzlich wird durch eine Uberlastung eventuell auch die Dauer f¨ ur die Authentifizierung verz¨ogert, weshalb diese auch von der Anzahl der gleichzeitigen Anfragen abh¨ angt. Zusammenfassend sind folgende Auswirkungen auf die Summanden in Gleichung (5.1) bzw. (5.5) zu erwarten:

76

5.2 Authentifizierung, Abrechnung und Lebenszyklus

Erste Anfrage ∆tauth ≈ # Anfragen ∆talloc = 0 ∆t∗comm ≈ # Anfragen ∆t∗work ≈ # Anfragen

Folgende Anfragen ∆tauth = 0 ∆talloc = 0 ∆t∗comm ≈ # Anfragen ∆t∗work ≈ # Anfragen

# Anfragen bezeichnet eine Anzahl gleichzeitiger Client-Anfragen, die auch von verschiedenen Clients abgesetzt werden k¨ onnen. Das Zeichen f¨ ur Proportionalit¨at (≈) zeigt hier die Abh¨ angigkeit der Gr¨ oßen an. Steigt beispielsweise die Anzahl gleichzeitiger Anfragen, so steigt auch jeweils die Verarbeitungsdauer pro Anfrage. Da nur ein Server zur Verf¨ ugung steht, ist die Performance bei steigender Anzahl von Anfragen sehr schlecht. Dieses Verhalten ist f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen nicht geeignet.

5.2.2 Mehrere Front-Server Da die Anzahl von VMs bei Verwendung eines IaaS-Anbieters leicht skaliert werden kann, kann die Menge ben¨ otigter VMs an die Anzahl von Anfragen angepasst werden. Zudem ist es sinnvoll, die Benutzerverwaltung und Abrechnung auf eine dedizierte Maschine auszulagern, um die konsistente Datenhaltung zu vereinfachen. In diesem Fall kann, wie gefordert, jedem Client eine dedizierte Ressource f¨ ur Berechnungen bereitgestellt werden. Die Architektur mit mehreren Front-Servern ist in Abbildung 5.3 visualisiert. Ein Client muss jedoch in diesem Fall eine freie Ressource zun¨ achst durch Verbindungsanfragen selbst suchen (Strichlinien). Da VMs bei jedem Start u ¨blicherweise neue IP-Adressen zugewiesen bekommen, ist dies eventuell schwierig. Selbst wenn der Client die Gesamtmenge der Ressourcen kennt, m¨ usste er im schlechtesten Fall alle anfragen, bis er eine freie Ressource findet. Sind alle Ressourcen belegt, kann die Allokation eventuell sogar fehlschlagen. Eine Anfrage w¨ urde folgendermaßen durchgef¨ uhrt: 1. Finden einer freien Ressource, 2. Authentifizierung des Anfragenden, 3. Bearbeiten der Anfrage. Hierbei wird f¨ ur jede Ressource ein eigenes Server-Zertifikat ben¨otigt. Durch den Einsatz einer Cloud-Infrastruktur kann hier bei geeigneter Skalierung der Front-Server bereits eine Performancegarantie bez¨ uglich der Verarbeitungsgeschwindigkeit ∆twork gegeben werden. Da hier keine zentrale Management-Komponente existiert, ist die Skalierung der ben¨otigten VMs jedoch eventuell schwierig und m¨ usste dezentral erfolgen. Durch die ausgelagerte Abrechnung und Authentifizierung in eine eigene VM kann die Dauer ∆tauth stark verbessert werden. Durch die exklusive Nutzung der Ressourcen der VM k¨onnen pro Zeiteinheit mehr Authentifizierungsvorg¨ange erfolgen, ohne dass die Dauer ∆tauth stark ansteigt. Dies ist damit zu begr¨ unden, dass es eher unwahrscheinlich ist, dass es sehr viele tats¨ achlich gleichzeitige Authentifizierungsvorg¨ange gibt. Selbst bei 100000 Anfragen in 12 h (beispielsweise zwischen 8–20 Uhr) m¨ ussten pro Sekunde im Durchschnitt nur ca. 2,3 Anfragen bearbeitet werden. In [WSKV08] wird beispielsweise beschrieben, dass ein LDAPbasiertes System bis zu einer Rate von ca. 50 Anfragen pro Sekunde eine konstante Authentifizierungsperformance von unter 100 ms erreicht. Das darin getestete LDAP-Verzeichnis hatte 10000 Eintr¨ age (Benutzer) mit je 488 Byte. Bei Datens¨atzen von 100–1000 Byte Gr¨oße pro

77

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

Einzelner Front-Server

Mehrere Front-Server Client 1

VM 1

Client 1 3 2

Client 2

VM 2

Client 3 Accounting/ Billing/ VM Notwendige Anfragen zum Finden einer freien VM

VM 3

Client 4

VM 4 Accounting/ Billing

Client 5

VM 5 skalierbar

Abbildung 5.2: Allokationsvorgang f¨ ur eine VM auf einer Architektur mit einem einzelnen FrontServer.

1

Client 2

Client 3

Client 4

Client 5

Abbildung 5.3: Allokationsvorgang f¨ ur eine VM auf einer Architektur mit mehreren Front-Servern und ausgelagerter Benutzerverwaltung und Abrechnung.

Benutzer betr¨ uge die Datenbankgr¨ oße ca. 0,1–1 GB f¨ ur 1 Mio Benutzer. Die Dauer von nur ca. 100 ms f¨ ur ∆tauth ist zudem sehr gering und kann fast immer vernachl¨assigt werden. Im Folgenden wird also davon ausgegangen, dass nahezu alle Authentifizierungsvorg¨ange in einer sehr kurzen Dauer ∆t erfolgen k¨ onnen. Zusammenfassend sind folgende Auswirkungen auf die Summanden in Gleichung (5.1) bzw. (5.5) zu erwarten: Erste Anfrage ∆tauth ≤ ∆t ∆talloc ≈ # Anfragen ∆t∗comm = konstant ∆t∗work = konstant

Folgende Anfragen ∆tauth = 0 ∆talloc = 0 ∆t∗comm = konstant ∆t∗work = konstant

Auch hier kann bez¨ uglich der entfernten Ausf¨ uhrungszeit keine obere Schranke angegeben werden, da das Finden einer freien Ressource noch von der Anzahl gleichzeitiger Anfragen abh¨angt. Diese Suche ist besonders im mobilen Umfeld langwierig, da hier der verschl¨ usselte Verbindungsaufbau aufgrund hoher Latenzen sehr lange dauert.

5.2.3 Broker-Server und Compute-Serverfarm Im Vergleich zur Variante mit mehreren Front-Servern, wird in dieser Variante ein BrokerServer hinzugef¨ ugt, der nur die Authentifizierung u ¨bernimmt und dem anfragenden Client eine VM f¨ ur Berechnungen zuweist (siehe Abbildung 5.4). Dieser Broker-Server hat eine feste IP-Adresse und ist somit immer erreichbar, was die Anzahl von Verbindungen im Vergleich zur Variante ohne Broker-Server stark reduzieren kann. Das eventuell langwierige Suchen einer freien VM entf¨ allt. Auch bei dieser Variante ist die Verarbeitungsgeschwindigkeit bei

78

5.2 Authentifizierung, Abrechnung und Lebenszyklus

Broker-Server mit Compute-Serverfarm

VM 1

Client 1 2

VM 2

1

VM 3

Client 3

Accounting/ Billing VM 4

Notwendige Anfragen zum Finden einer freien VM

VM 5

Client 2

Client 4

Master

skalierbar

Client 5

Abbildung 5.4: Allokationsvorgang f¨ ur eine VM auf einer Architektur mit Broker-Server. entsprechender Skalierung der Ressourcen konstant. Da die VM jedoch nicht mehr authentifiziert, muss ein Session-Management implementiert werden, damit sich der Client auch mit der zugewiesenen VM verbinden kann. Eine Anfrage wird dann folgendermaßen beantwortet: 1. Authentifizierung des Anfragenden durch den Broker, 2. Allokieren einer VM f¨ ur die Anfrage, 3. R¨ ucksenden der Serveradresse und der etablierten Session-ID an den Client, 4. Senden der Anfrage zur VM, 5. Beantworten der Anfrage, 6. Explizites Freigeben der VM durch den Client. Durch den Broker-Server, der alle VM-Instanzen kennt, kann ∆talloc insofern reduziert werden, als dass daf¨ ur ein Wert < ∆tstartup angenommen werden kann. ∆talloc ist somit nicht mehr von der Anzahl der Anfragen abh¨angig und es kann in jedem Fall eine Ressource zugewiesen werden. Diese Architekturvariante wird aufgrund ihrere positiven Eigenschaften f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen im Folgenden weiter untersucht. Dazu wird im folgenden Kapitel ∆talloc durch Simulation genauer bestimmt. Der Broker kann hier kaum zum Flaschenhals werden, da er nur f¨ ur die Authentifizierung zust¨andig ist, alle weiteren berechnungsintensiven Anfragen werden direkt an die allokierte VM gesendet. Somit steht auch f¨ ur jeden Client die volle Netzwerkbandbreite zur Verf¨ ugung. Zusammenfassend sind folgende Auswirkungen auf die Summanden in Gleichung (5.1) bzw. (5.5) zu erwarten:

79

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

Erste Anfrage ∆tauth ≤ ∆t ∆talloc ≤ ∆tstartup ∆t∗comm = konstant ∆t∗work = konstant

Folgende Anfragen ∆tauth = 0 ∆talloc = 0 ∆t∗comm = konstant ∆t∗work = konstant

Ein Nachteil dieser Variante ist, wie auch bei der Variante mit mehreren Front-Servern, dass f¨ ur jede VM ein eigenes Serverzertifikat ben¨otigt wird. Hier muss man also bestenfalls Wildcards in Zertifikaten verwenden oder mit einer eigenen Trusted Authority arbeiten, die die Serverzertifikate ausstellt und der der Client vertraut (siehe Kapitel 4.2.2).

5.2.4 Lebenszyklus einer Client-Anfrage Durch die favorisierte Modellierungsvariante mit dem Broker-Server wird die Implementierung eines Lebenszyklus f¨ ur eine VM-Nutzung obligatorisch. Dies ist notwendig, um durch die Vermeidung mehrfacher Authentifizierung Zeit einzusparen. Zudem ist der Lebenszyklus auch f¨ ur die korrekte Abrechnung der Nutzungsdauer essentiell. Als Repr¨asentation des Lebenszyklus wird nach der Authentifizierung des Client durch den Broker-Server ein Sessionkey erstellt. Die Abrechnung endet erst mit Aufl¨osung der Session. Der Nutzer zahlt also f¨ ur die Vorhaltung der f¨ ur ihn bereitgestellten VM, unabh¨angig davon, ob er sie tats¨achlich nutzt. Im Gegenzug wird nach der Initiierung einer Session aber auch eine geringere Latenz und eine gleichbleibende Performance der VM sichergestellt. In Abbildung 5.5 ist der Lebenszyklus einer Client-Anfrage anhand eines Beispiels dargestellt. Ein Client setzt eine Anfrage zur Nutzung einer VM einer bestimmten Qualit¨at via getInstanceForType() zum Broker ab. Der Broker pr¨ uft zun¨achst beim Abrechnungsdienst, ob der Nutzer, der sich mit Name und Passwort angemeldet hat, zur Nutzung des gew¨ unschten Dienstes zugelassen ist (authenticate()). Falls ja, allokiert der Broker nun die gew¨ unschte Ressource f¨ ur den Client (getCloudResourceForType()). Da der Broker alle laufenden Instanzen aller VMs und deren Qualit¨at und Auslastung kennt, kann er eine laufende Instanz wiederverwenden oder eine neue Instanz starten (startVM()). Dies h¨angt von der verwendeten Allokationsstrategie ab. Anschließend generiert der Broker einen Sessionkey, der fortan die Verbindung zwischen dem anfragenden Client und der Cloud-Ressource repr¨asentiert (generateKey()). Diesen Sessionkey u ¨bermittelt der Broker zur Cloud-Ressource, damit diese den Client akzeptieren kann. Außerdem wird der Sessionkey auch zum Abrechnungssystem u ¨bermittelt, damit dieses den Vorgang zur sp¨ateren Abrechnung speichern kann (startbilling()). Abschließend wird dem Client die IP-Adresse und der zu verwendende Sessionkey zum Zugriff auf den gew¨ unschten Dienst u ¨bermittelt. Der Client kommuniziert danach nur noch direkt mit der zugewiesenen Cloud-Ressource. Er verbindet sich direkt mit der VM unter Angabe des Sessionkey (connect()). Nun k¨onnen solange Berechnungen durchgef¨ uhrt werden, bis der Client die Verbindung trennt (disconnect()). Danach meldet die VM selbstst¨andig das Ende der Abrechnung (reportUsage()) und meldet ihren aktuellen Status an den Broker (returnKey()). Bei der Implementierung der Session gibt es verschiedene M¨oglichkeiten der Terminierung. Der u ¨bliche Weg sieht vor, dass der Client sich ordnungsgem¨aß mit der VM verbindet und nach Trennung der Verbindung die Session beendet wird. Aus verschiedenen Gr¨ unden k¨onnte es jedoch auch vorkommen, dass ein Client zwar eine VM anfragt und zur¨ uckgeliefert bekommt, sich jedoch nie verbindet. Aus diesem Grund wird ein Sessionkey mit einer Ver-

80

5.2 Authentifizierung, Abrechnung und Lebenszyklus

Abbildung 5.5: Illustration des Lebenszyklus einer Client-Anfrage (Sequenzdiagramm) anhand eines Beispiels.

¨ fallsdauer (englisch Lease) versehen, die daf¨ ur sorgt, dass die Session beim Uberschreiten dieser Dauer durch die VM automatisch beendet wird. Danach w¨ urde ein Verbindungsversuch durch den Client fehlschlagen und der Client m¨ usste erneut eine VM beim Broker-Server anfragen. Es sei nochmals darauf hingewiesen, dass die Kommunikation zwischen allen genannten Komponenten (Broker, VM, Benutzerverwaltung/Abrechnung und Client) verschl¨ usselt werden muss, um die Integrit¨ at und Geheimhaltung des Sessionkey zu gew¨ahrleisten, ohne den die Implementierung des beschriebenen Lebenszyklus nicht m¨oglich w¨are.

81

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

200000

Startup-Zeit in ms

180000 160000 140000 120000 100000 80000 60000 40000 20000

av g

ar ge m 2. 4x l

la rg e c1 .x

ar ge m 2. 2x l

la rg e m 1. x

la rg e m 2. x

ed iu m c1 .m

m 1. la rg e

m 1. s

m al l

0

Abbildung 5.6: Durchschnittliche gemessene Startup-Zeiten von EC2 VM-Ressourcen im Amazon Rechenzentrum in Irland.

5.3 Cloud-Ressourcen Startup/Shutdown-Zeiten F¨ ur Mobile Cloud-unterst¨ utzte Anwendungen wird die Anzahl von Cloud-Ressourcen kontinuierlich dem notwendigen Bedarf angepasst. Dazu muss die Dauer f¨ ur das Starten einer VM eines IaaS-Anbieters bekannt sein. Um aussagekr¨aftige Simulationen der Allokationszeit f¨ ur Cloud-Ressourcen durchf¨ uhren zu k¨onnen, muss zun¨achst die tats¨achlich zu erwartende Dauer ∆tstartup gemessen werden. Wie schon in Kapitel 4 wurde als Zielumgebung die EC2 Infrastruktur des Anbieters Amazon im Rechenzentrum in Irland benutzt. Zun¨achst wurden verf¨ ugbare Arbeiten bez¨ ugliche Daten zur Startup- und Shutdown-Zeit von Amazon EC2 Instanzen untersucht. Die Angaben der Startup-Zeit variieren dabei in der Literatur stark. In [IOY+ 11] ist die Startup-Zeit und Release-Zeit f¨ ur verschiedene VM-Typen von Amazon EC2 analysiert worden. Als Release-Zeit wird die Zeit betrachtet, die vom Ausschalten der VM bis zur tats¨ achlichen Freigabe der Ressource durch den IaaS-Anbieter vergeht. Als ∆tstartup wurde hier die Dauer von der Installationsanfrage bis zum abgeschlossenen Bootvorgang betrachtet. Es wurden je 20 aufeinander folgende Messungen f¨ ur die VM-Typen m1.small, m1.large, m1.xlarge, c1.medium und c1.xlarge durchgef¨ uhrt. Der Mittelwert f¨ ur ∆tstartup lag dabei bei ca. 73 s. Die durchschnittliche Release-Zeit lag bei ca. 19 s. In welchem Rechenzentrum die Messungen durchgef¨ uhrt wurden, ist nicht bekannt. In [IYE11] wird die Startup-Zeit des m1.small-Instanztyps von Amazon EC2 u ¨ber ein Jahr beobachtet und mit durchschnittlich ca. 77 s angegeben. Auch hier wurde die Zeit von der Installationsanfrage bis zum Abschluss des Bootvorgangs gemessen. In welchem Rechenzentrum die Messungen durchgef¨ uhrt wurden, ist ebenfalls nicht bekannt. In einer weiteren Arbeit [PSS+ 12] wurde die ∆tstartup -Zeit f¨ ur die VM-Typen m1.small, m1.large und m1.xlarge und 10 einzelne Messungen mit durchschnittlich ca. 36 s angegeben. Dabei wurde als Startup-Zeit jedoch nur die Zeit von der Installationsanfrage bis zur Bereitstellung der VM gemessen. Die Zeit f¨ ur den Bootvorgang ist nicht eingeschlossen. Die Messungen wurden im Rechenzentrum von Amazon EC2 in Virginia, USA (US-EAST) durchgef¨ uhrt. Aufgrund der wenigen und stark divergierenden Messungen, die in der Literatur zu finden waren, wurden eigene Messungen bez¨ uglich ∆tstartup im Amazon Rechenzentrum in Irland (EU-WEST) durchgef¨ uhrt. Die durchschnittlichen Startup-Zeiten sind in Abbildung 5.6 dar-

82

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

gestellt. Es wurden jeweils 10 aufeinander folgende Messungen durchgef¨ uhrt. Als Startup-Zeit ist hier die Zeit relevant, die von der Installationsanfrage bis zum ersten erfolgreichen LoginVersuch via SSH vergangen ist. Im Mittel wurde hier eine Dauer von 150 s gemessen. Die stark variierenden Startup-Zeiten sind einerseits durch verschiedene Messmodi (mit/ohne Dauer des Bootvorgangs) zu erkl¨ aren. Andererseits sind die Startup-Zeiten wahrscheinlich auch in unterschiedlichen Rechenzentren verschieden. Deshalb wird im Weiteren von einer Dauer ∆tstartup von ca. 150 s ausgegangen, wie sie selbst gemessen wurde. Die Release-Zeit ist f¨ ur die Simulation nicht relevant, da sie sich auf keinen Summanden der Gleichung (5.1) auswirkt. Eine ungenutzte VM sollte stets 5 min vor Beginn der n¨achsten Abrechnungsperiode heruntergefahren werden. Dadurch sollte gen¨ ugend Zeit f¨ ur die Freigabe der VM zur Verf¨ ugung stehen. Das Herunterfahren kann automatisiert durch den Broker erfolgen.

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters Um eine schnelle Bereitstellungszeit und einen geringen Kostenoverhead f¨ ur Mobile Cloudunterst¨ utzte Anwendungen zu erreichen, ist es, wie bereits beschrieben, notwendig, CloudRessourcen wiederzuverwenden. Dazu sind Scheduling- und Lastbalancierungsstrategien zu entwerfen, die die Bereitstellungszeit ∆talloc und die anfallenden Kosten auf einer Menge von in der Anzahl skalierbaren VM-Instanzen eines IaaS-Anbieters minimieren. Um eine gewisse Performance f¨ ur Client-Anfragen zu garantieren, soll jede Anfrage m¨oglichst exklusiv auf eine dedizierte Serverinstanz (VM) zugewiesen werden. Verschiedene Zuweisungsstrategien, man spricht auch von Ressourcenallokation, haben unterschiedlichen Einfluss auf die Kosten bzw. den Kostenoverhead und die Dienstqualit¨at (Performance). Um diesen Einfluss zu analysieren, wurden zwei verschiedene Allokationsstrategien simuliert. Zudem ist eine Simulation auch sinnvoll, um die Performance, die ein IaaS-Anbieter liefert, die daraus entstehenden Kosten und schließlich dessen Eignung f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen vor der Installation der Middleware bereits zu u ufen. Die nachfolgenden Ausf¨ uhrungen dieses ¨berpr¨ Unterkapitels sind in gek¨ urzter Form in [FRTH12] zu finden. Simuliert wird die zeitliche Nutzung einer Menge von VM-Instanzen f¨ ur eine Menge von Client-Anfragen, die u ¨ber einen Tag verteilt auftreten. Das Modell der Simulation ist in Tabelle 5.1 zusammengefasst und wird nachfolgend beschrieben. Bei der Simulation handelt es sich um eine diskrete Ereignissimulation1 . Jeder Simulationslauf durchl¨auft genau einen Tag zwischen 0 und 24 Uhr. Da der Simulation kein stetiger Prozess, sondern einzelne Ereignisse zu Grunde liegen, ist die diskrete Ereignissimulation eine passende Methode zur Durchf¨ uhrung der Simulation. Es werden mehrere Qualit¨atsattribute betrachtet, die zugleich die Simulationsgr¨oßen darstellen: 1. die Allokationszeit ∆talloc , 2. der Overhead der Verarbeitungszeit ∆tshared und 3. die Gesamtkosten der VM-Nutzungsdauer. 1

Eine diskrete Ereignissimulation ist eine zeitdiskrete Simulation, bei der auftretende Ereignisse nach deren Reihenfolge abgearbeitet werden. Das Auftreten eines Ereignisses a ¨ndert dabei den Simulationszustand. Bei dieser Art Simulation wird die Tatsache ausgenutzt, dass sich der Simulationszustand zwischen Ereignissen nicht ¨ andert und folglich nicht betrachtet werden muss. Grundlage der hier durchgef¨ uhrten Simulation ist eine einfache Ereignisverarbeitung (englisch Event Scheduling). (siehe [Tys99, S. 17 ff.])

83

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

Tabelle 5.1: Beschreibung des Modells zur Simulation der Allokationsstrategien f¨ ur VMs Definition Beschreibung Sim(V M s, REQs, Sinit , Sf inal , Falloc ) Sinit , Sf inal tsim numstandby ≥ 1 vm(tcreate , ∆tstartup , tkill , numreq ) V M s = {vm0 , . . . , vmx | x ∈ N} load(vm) f ree(vm) = true ready(vm) = true V Mf ree = {vm | vm ∈ V M s ∧ f ree(vm) ∧ ready(vm)} req(trequest , tstart , ∆twork , tf inish ) REQs = {req0 , . . . , reqx | x ∈ N} ∆talloc ∆tshared ∆toverhead Falloc (req) Fassign (vm, req) Fadjust (REQs, V M s)

Beschreibung einer Simulation anf¨ anglicher/finaler Simulationszustand ein Zeitpunkt in der Simulation |V Mf ree | sollte stets numstandby sein Beschreibung einer Cloud-Ressource Eine Menge von Cloud-Ressourcen gibt numreq zum Zeitpunkt tsim zur¨ uck falls numreq == 0 falls (tcreate + ∆tstartup ) ≤ tsim Menge ungenutzter Cloud-Ressourcen Beschreibung einer Anfrage Eine Menge von Anfragen tstart − trequest tf inish − tstart − ∆twork ∆talloc + ∆tshared allokiert eine vm zu einer Anfrage req weist einer Anfrage req eine vm zu passt numstandby vonV M s an

∆tshared repr¨ asentiert einen Overhead bez¨ uglich ∆twork , der durch simultane, also nicht exklusive, Verarbeitung mehrerer Anfragen auf einer VM entsteht, und sich in Gleichung (5.1) durch einen zus¨ atzlichen Term ∆tshared widerspiegelt: ∆tremote = ∆tauth + ∆talloc + ∆tinstall + ∆t∗comm + ∆twork + ∆tshared .

(5.6)

Der Zeitaufschlag aus ∆tshared und ∆talloc wird zur sp¨ateren besseren Vergleichbarkeit der Allokationsstrategien in ∆toverhead zusammengefasst. Ziel der Simulation ist es, f¨ ur die vorgestellte Variante der exklusiven VM-Allokation eine Einordnung gegen¨ uber einem bekannten System bez¨ uglich Kosten- und Performanceoverhead zu bekommen. Es wurde eine exklusive Allokationsstrategie implementiert, die jede Anfrage auf eine dedizierte Ressource zuweist. Außerdem wurde zum Vergleich eine traditionelle Strategie implementiert, die sehr schnell eine Ressource aus dem bestehenden Ressourcenpool aussucht und zuweist, auch wenn diese dann nicht exklusiv genutzt werden kann. Durch Multiplexing kann dann keine Performancegarantie gegeben werden. Die Simulation offenbart, wie h¨aufig Multiplexing dann f¨ ur verschiedene Anfragen durchgef¨ uhrt werden musste und wie sich das auf die Simulationsgr¨ oßen auswirkt.

5.4.1 Simulationsmodell Abbildung 5.7 zeigt den generellen Ablauf einer Simulation. Zun¨achst werden Simulationseingaben generiert. Auf Basis dieser Eingabe werden dann eine Reihe von aufeinander folgenden Simulationsl¨ aufen durchgef¨ uhrt, die solange wiederholt werden, bis sich ein stabiler Zustand einstellt, was man h¨ aufig auch als Konvergieren bezeichnet. Hierbei ist jedoch nur bedingt das strenge Zulaufen auf einen Grenzwert gemeint. Die Simulation gilt als konvergiert, wenn

84

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

Nein

Start

Anfrageverteilung generieren

Anfrageverteilung

Simulationslauf

Ergebnis konvergiert?

Simulationszustand

Ausgabe und Statistik

Ja

Fertig

Abbildung 5.7: Schematische Visualisierung des Ablaufs einer Simulation.

aufeinander folgende Simulationsl¨ aufe ¨ahnliche Ergebnisse erzielen, die nur um einen kleinen Wert  voneinander abweichen. Die genaue Metrik wird sp¨ater noch vorgestellt. Abschließend werden die Ergebnisse der Simulation ausgewertet und aufbereitet. Ist die Simulation nach einer Anlaufphase stabil, k¨ onnen fortlaufend mehrere Tage mit unterschiedlichem Anfrageverhalten (beispielsweise am Wochenende) nacheinander simuliert werden. Eine Cloud-Ressource (in diesem Abschnitt als vm bezeichnet) wird beschrieben durch ihren Erstellungszeitpunkt tcreate , die Dauer ihrere Startup-Phase ∆tstartup , ihres Zerst¨ orungszeitpunktes tkill und ihrer aktuellen Belegung numreq . Die Cloud-Ressource hat keine Attribute f¨ ur Performance, da diese von Anwendung zu Anwendung verschieden sind und allein durch verschiedene Werte von ∆twork repr¨asentiert wird. Eine Dienstanfrage req ∈ REQs ist charakterisiert durch den Zeitpunkt trequest , zu dem der Client die Anfrage absetzt, dem Zeipunkt tstart , zu dem die Anfrage tats¨achlich begonnen wird abzuarbeiten, der Anfragedauer ∆twork und dem Zeipunkt tf inish , der das Ende der Bearbeitung der Anfrage markiert. ∆twork ist dabei die Zeitdauer, die ben¨otigt wird, wenn die vm exklusiv zur Verf¨ ugung st¨ unde. Falls die Anfrage req ihre zugewiesene Ressource vm mit einer anderen Anfrage teilen muss, dann ist ∆tshared > 0 und beschreibt den Zeitraum, den die Ressource vm nicht exklusiv zur Verf¨ ugung stand. Es wurde eine diskrete Ereignissimulation durchgef¨ uhrt, die durch ein 5-Tupel beschrieben wird Sim(V M s, REQs, Sinit , Sf inal , Falloc ). Implementierungsdetails der Simulation werden in Abschnitt 5.4.4 genannt. Hier wird zun¨achst der Ablauf der Simulation beschrieben. Zu Beginn eines Simulationslaufs ist die initiale Menge verwendeter Ressourcen (V M s) und der finale Zustand leer (V M s = Sf inal = ∅). Die Simulation startet mit dem Wiederherstellen des initialen Zustands Sinit und dem Einlesen der definierten Anfragen REQs aus der entsprechenden Eingabedatei der Anfrageverteilung. Sinit enth¨alt eine Menge bei Start bereits ausgef¨ uhrter V M s und entsprechend auch eine Menge von Anfragen, die auf diesen bei Start schon bearbeitet werden. Sinit dient somit der Realisierung eines realistischen Simulationsanfangszustands. W¨ ahrend der Simulation wird jede Anfrage req entsprechend ihres Anfragezeitpunktes trequest durch die gew¨ahlte Funktion zur Allokation Falloc einer vm zugewiesen. Die Verarbeitungszeit ∆twork f¨ ur alle aktuell bearbeiteten Anfragen wird jede Sekunde verringert. Dabei wird die Belegung aller V M s ber¨ ucksichtigt. F¨ ur Anfragen, die exklusiv bearbeitet werden, wird ∆twork um 1 s verringert. F¨ ur Anfragen, die sich eine vm teilen, wird

85

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien 1 ∆twork um load(vm) s verringert, da in der selben Zeit weniger CPU-Zeit pro Anfrage zur Verf¨ ugung stand als bei exklusiver Nutzung. Fertig abgearbeitete Anfragen (∆twork == 0) werden von der vm entfernt und die vm wird eventuell wieder als frei angesehen, falls keine anderen Anfragen mehr darauf ausgef¨ uhrt werden. In periodischen Abst¨anden wird auch die die Anzahl numstandby von Reserve-V M s durch das Starten oder Beenden von Ressourcen entsprechend angepasst. Nicht mehr ben¨otigte Ressourcen aus V Mf ree werden noch so lange nicht terminiert, wie sie bereits durch die st¨ undliche Abrechnung bezahlt sind. Dies macht es m¨oglich, eventuell weitere Anfragen auf die noch verf¨ ugbaren Ressourcen zuzuweisen. Nach Beendigung des Simulationslaufs enth¨ alt V M s alle vm, die w¨ahrend der Simulation benutzt wurden einschließlich der durch die Simulation ermittelten Werte f¨ ur tcreate und gegebenenfalls tkill . Der Endzustand eines Simulationslaufs Sf inal enth¨alt alle am Ende des Simulationstages (24 Uhr) noch laufenden vm und die noch in Bearbeitung befindlichen Anfragen req. Sf inal kann als Eingabe Sinit f¨ ur den n¨ achsten Simulationslauf dienen. Somit ist es m¨oglich, eine fortlaufende Simulation durchzuf¨ uhren. Außerdem enth¨alt REQs am Ende der Simulation die aktualisierten simulierten Werte f¨ ur tstart und tf inish f¨ ur alle req ∈ REQs.

5.4.2 Ressourcenallokationsstrategie Das Ziel der hier vorgestellten Allokationsstrategie ist es, stets gen¨ ugend freie Ressourcen vorzuhalten, um alle eingehenden Anfragen sofort und exklusiv befriedigen zu k¨onnen. Das Optimum bez¨ uglich der daf¨ ur entstehenden Kosten w¨are erreicht, wenn stets genau so viele VM-Instanzen aktiv sind, wie Anfragen beantwortet werden m¨ ussen. Da Anfragen jedoch nicht vorhersagbar sind, m¨ ussen immer einige Reserve-VMs vorgehalten werden, um eine Wartezeit bei der Bearbeitung von Anfragen w¨ahrend des Startens neuer Instanzen zu verhindern. Deren Anzahl wird mit numstandby angegeben. Die nachfolgend beschriebenen Simulationsl¨aufe wurden mit verschiedenen Werten f¨ ur die Anzahl von Reserve-VMs durchgef¨ uhrt. Dabei wurde ein Wert von 10 % Reserve-VMs im Vergleich zur aktuellen Anfragemenge als ausgewogen ermittelt. Der Wert sollte je nach Anfrageverteilung, Anfrageh¨aufigkeit und Anfragel¨ange angepasst werden. F¨ ur die Simulation ist es wichtig, dass der Wert f¨ ur alle Simulationsl¨aufe konstant gehalten wird, um die Vergleichbarkeit der Ergebnisse zu gew¨ahrleisten. Außerdem l¨ auft zu jedem Zeitpunkt tsim mindestens immer eine vm. REQtsim beschreibt die Anzahl der zum Zeitpunkt tsim aktiven Anfragen: REQtsim

= {req 

numstandby =



mit req ∈ REQs

1 |REQtsim | · 0, 1

und req.tstart ≤ tsim < req.tf inish }, (5.7)

: falls |REQtsim | = 0 : sonst.

(5.8)

Trotzdem kann es passieren, dass zu einem bestimmten Zeitpunkt eine Anfrage gestellt wird, f¨ ur die keine freie vm mehr zur Verf¨ ugung steht. Die beiden vorgestellten Allokationsmethoden Falloc unterscheiden sich in der Strategie, wie sie genau dieses Problem l¨osen. Die Strategie Falloc exklusive weist nie mehr als eine Anfrage auf eine vm zu. Als Folge kann es vorkommen, dass erst eine neue VM-Instanz gestartet werden muss, um die Anfrage zu bearbeiten. Im schlimmsten Fall dauert es also ∆tstartup , bis die Bearbeitung der Anfrage beginnt. Da die Anfrage dann jedoch exklusiv verarbeitet wird, kommt es zu keiner weiteren Verz¨ogerung (∆tshared = 0). Der maximale zeitliche Overhead f¨ ur diese Variante ist demnach

86

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

Algorithmus 1 Falloc exklusive (exklusive Allokationsstrategie) Require: req {Zuweisung einer Anfrage auf eine VM } REQs = REQs ∪ req if |V Mf ree | < 1 then vmn = new vm() V M s = V M s ∪ {vmn } while |V Mf ree | < 1 do wait(1s) end while end if Fassign (vmx ,req) mit vmx ∈ V Mf ree V Mf ree = V Mf ree \ vmx Fadjust (REQs, V M s)

Algorithmus 2 Falloc immediate (unmittelbare Allokationsstrategie) Require: req {Zuweiseung einer Anfrage auf eine VM } if |V Mf ree | < 1 then  Fassign (vmn ,req) with vmn = argmin load(vmn ) vmn ∈V M s

else Fassign (vmx ,req) with vmx ∈ V Mf ree V Mf ree = V Mf ree \ vmx end if Fadjust (REQs, V M s)

M AX(∆toverhead ) = ∆tstartup . Der Pseudocode dieser Allokationsmethode Falloc exklusive ist in Algorithmus 1 angegeben. Die Allokationsstrategie Falloc immediate weist eine Anfrage immer unverz¨ uglich auf eine vm zu. Daraus ergibt sich ∆talloc = 0. Sollte dabei keine freie vm mehr verf¨ ugbar sein (|V Mf ree | = 0), wird die Anfrage auf die vm mit der geringsten Anzahl von aktuell bearbei¨ teten Anfragen zugewiesen. Durch die Uberladung einer vm kann jedoch ∆tshared eventuell stark ansteigen, wodurch man keine obere Schranke f¨ ur die Bearbeitungszeit mehr angeben kann. Diese unmittelbare Strategie ist in Algorithmus 2 angegeben. Beide Allokationsstrategien werden im Folgenden durch Simulation miteinander verglichen.

5.4.3 Generierung von Simulationseingaben Die als Simulationseingabe n¨ otigen Anfragen wurden zuf¨allig u ¨ber den Simulationszeitraum eines Tages zwischen 0 und 24 Uhr verteilt. Jede Anfrage req wird dabei durch den Zeitpunkt des Absetzens der Anfrage trequest und die Dauer der Anfrage ∆twork charakterisiert. Die Dauer jeder einzelnen Anfrage kann prinzipiell verschieden sein. Um die Ergebnisse verschiedener Verteilungen und Allokationsstrategien besser vergleichen zu k¨onnen, wurden jedoch f¨ ur eine generierte Simulationseingabe f¨ ur alle Anfragen die gleiche L¨ange gew¨ahlt. Zun¨achst wurden verschiedene synthetische Verteilungen angenommen, um die Simulation auf Plausibilit¨ at und Funktionalit¨ at zu u ufen. Dazu sind in Abbildung 5.8 verschiedene ¨berpr¨ Anfrageverteilungen und die zugeh¨ origen Simulationsergebnisse dargestellt. Es wurden jeweils 100000 Anfragen pro Tag mit je 20 min Anfragel¨ange benutzt. Zu sehen sind jeweils die Anzahl gleichzeitiger Anfragen (blau gepunktete Linie), die Anzahl gerade in Bearbeitung befindlicher Anfragen (lila gepunktete und rote Linie) und die dazu ben¨otige Anzahl von VM-Ressourcen (gr¨ une gestrichelte und hellblau gestrichelte Linie) f¨ ur die beiden Allokationsstrategien. Im

87

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

100000 Anfragen pro Tag, 20min Anfragelänge

100000 Anfragen pro Tag, 20min Anfragelänge

1650

3000

1600

2500

1550 2000 # Anzahl

# Anzahl

1500 1450 1400

1500

1000

1350 500

1300 1250 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

100000 Anfragen pro Tag, 20min Anfragelänge

100000 Anfragen pro Tag, 20min Anfragelänge

2600

9000 8000

2400

7000

# bearbeiteter Anfragen (immediate) # benötigter VMs (immediate) # Anfragen # bearbeiteter Anfragen (exclusive) # benötigter VMs (exclusive)

2200

1800

# Anzahl

# Anzahl

6000 2000

5000 4000 3000

1600 2000 1400 1200 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

Abbildung 5.8: Visualisierung verschiedener Simulationsergebnisse.

1000 0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

Anfrageverteilungen

und

zugeh¨orige

besten Fall sollten sich die Kurven f¨ ur die Anzahl gleichzeitiger Anfragen und die Anzahl gerade bearbeiteter Anfragen decken. Dies w¨ urde bedeuten, dass keine Verz¨ogerung bei der Bearbeitung von Anfragen auftritt und stets gen¨ ugend VM-Ressourcen zur Verf¨ ugung stehen, um jede Anfrage exklusiv auf eine VM zuzuweisen. In Abbildung 5.8 (oben links) wurden alle Anfragen mit der gleichen Wahrscheinlichkeit u ¨ber den ganzen Tag verteilt. Aus der Simulation ergibt sich dann, dass alle Anfragen ohne gr¨oßeren Overhead bearbeitet werden k¨onnen. Die exklusive Allokationsstrategie ben¨otigt hier jedoch mehr VM-Ressourcen. In Abbildung 5.8 (oben rechts) wurde die Anfragewahrscheinlichkeit gegen Mittag erh¨ oht und nachmittags spiegelverkehrt wieder abgesenkt. Dadurch ergibt sich eine Spitze um 12 Uhr Mittags. Hier ist links der Spitze zu erkennen, dass die Linie der aktuell in Bearbeitung befindlichen Anfragen f¨ ur die unmittelbare Allokationsstrategie (rote Linie) h¨ aufig leicht oberhalb der Linie der gleichzeitigen Anfragen (blau gepunktete Linie) liegt. Dies liegt daran, dass die unmittelbare Allokationsstrategie beim Allokieren neuer Ressourcen etwas tr¨ ager reagiert als die exklusive Strategie. Auf der abfallenden Seite ist die Performance beider Strategien nahezu gleich. Um die beobachteten Ph¨anomene beim Anstieg der Anfrageh¨ aufigkeit weiter zu untersuchen, wurden in Abbildung 5.8 (unten links) drei kurze Phasen mit einer sprunghaft ansteigenden und abfallenden Anfrageh¨aufigkeit eingebaut. Hier ist deutlich zu erkennen, dass dabei die Bearbeitungsdauer von Anfragen bei der unmittelbaren Allokation stark verz¨ ogert wird. Bei der exklusiven Allokation ist dies kaum zu beobachten, jedoch werden bei dieser Strategie sehr viele VM-Ressourcen ben¨otigt, um dem

88

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

100000 Anfragen pro Tag, 20min Anfragelänge 2400 # bearbeiteter Anfragen (immediate) # benötigter VMs (immediate) # Anfragen # bearbeiteter Anfragen (exclusive) # benötigter VMs (exclusive)

2200

2000

# Anzahl

1800

1600

1400

1200

1000

800 00:00

02:00

04:00

06:00

08:00

10:00

12:00 14:00 Tageszeit

16:00

18:00

20:00

22:00

00:00

Abbildung 5.9: Verteilung von 100000 simulierten Anfragen und die korrespondierende VM Allokationen f¨ ur verschiedene Allokationsstrategien.

starken Anfrageanstieg entgegenzuwirken. Noch deutlicher sichtbar wird dieser Effekt in Abbildung 5.8 (unten rechts), in der die kurzen Peaks zu einem langen Plateau zusammengefasst wurden. Dabei l¨ asst sich jedoch auch erkennen, dass nach einer gewissen Zeit die Anpassung der Anzahl von VM-Ressourcen auch f¨ ur die unmittelbare Allokationsstrategie abgeschlossen ist. Abschließend kann man anhand der synthetischen F¨alle das Verhalten der beiden Allokationsstrategien gut nachvollziehen. Die unmittelbare Allokationsstrategie reagiert auf Anstiegen sehr tr¨ age, verbraucht im Gegenzug aber auch weniger Ressourcen. Besonders gute Eigenschaften weist die unmittelbare Strategie nur auf, wenn die Anzahl Anfragen nahezu gleichverteilt ist. Um die zuf¨ allige Verteilung realistischer zu machen und Spitzen zu simulieren, wird f¨ ur die tats¨achliche Simulation eine Verteilungsfunktion wie in [SKS+ 11] verwendet. Hierbei wird beachtet, dass es wahrscheinlicher ist, dass eine Anfrage tags¨ uber abgesetzt wird als nachts. Eine beispielhafte Verteilung von 100000 Anfragen (∆twork =20 min) ist in Abbildung 5.9 dargestellt. In diesem realistischen Verlauf lassen sich das Verhalten an einem starken Anstieg um ca. 8 Uhr, das Verhalten an einer Spitze um ca. 14 Uhr und die gleichverteilte Platzierung von Anfragen zwischen ca. 20–24 Uhr erkennen. Unter Verwendung dieser realistischen Verteilung werden nachfolgend Simulationen f¨ ur verschiedene Anzahlen von Anfragen pro Tag und f¨ ur verschiedene Anfragel¨ angen durchgef¨ uhrt.

89

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

5.4.4 Implementierung des Simulators Da f¨ ur die hier durchgef¨ uhrten Simulationen kein bereits vorhandener Simulator verwendet wurde, sondern eine Eigeneentwicklung, wird nachfolgend noch auf einige Details des Simulators eingegangen. Der implementierte Simulator ist an das Design von Javasim angelehnt [BS96]. Da jedoch auch die parallele Verarbeitung der Simulationsl¨aufe gew¨ unscht war, wurde nicht direkt auf die Quellen zur¨ uckgegriffen. Ein sehr leistungsf¨ahiger und erweiterbarer Simulator f¨ ur Cloud-Umgebungen ist Cloudsim [CRB11]. Cloudsim ist jedoch dazu entworfen worden, die Prozesse und Architektur innerhalb einer Infrastruktur-Umgebung abzubilden. Dazu z¨ahlt beispielsweise das Platzieren von virtuellen Maschinen auf reale Server. Somit agiert Cloudsim auf einem anderen Abstraktionslevel. F¨ ur das hier dargestellte Simulationsmodell aus Anwendungssicht wird diese feingranulare Modellierung nicht ben¨otigt. Es wirkt sich sogar negativ auf die Performance aus. Zum Vergleich wurde aufbauend auf der Modellierung der Amazon EC2 Struktur, die durch die Arbeit [Feh12] schon vorhanden war, ebenfalls eine Simulationsvariante mit Cloudsim 3.0 2 implementiert. Hierbei stellte sich jedoch heraus, dass die Performance von Cloudsim nicht ausreichte. F¨ ur die Simulation von 1000 Anfragen pro Tag mit einer L¨ ange von je 20 Min ben¨otigte die Cloudsim-basierte Variante bereits ca. 75 s, f¨ ur 10000 Anfragen pro Tag schon 2 min 8 s. Die gleichen Simulationen wurden von dem selbst implementierten Simulator in 1 s bzw. 2,5 s durchgef¨ uhrt. Damit ergibt sich ein Gewinn von ca. Faktor 75–100. Somit lassen sich mit der selbst implementierten Variante auch sehr umfangreiche Simulationen in u uhren. ¨berschaubarer Zeit durchf¨ Der allgemeine Simulationsablauf ist bereits in Abbildung 5.7 dargestellt. Jede Simulation besteht dabei aus mindestens drei einzelnen Simulationsl¨aufen. F¨ ur die Simulation wurde ein Java-Programm geschrieben, welches auf einer Menge von Dateien arbeitet. Diese Dateien werden zun¨ achst genauer beschrieben. Anfrageverteilung Die Anfragen f¨ ur die Simulation werden gem¨aß der gew¨ahlten Wahrscheinlichkeitsfunktion u ¨ber einen Tag verteilt. Dazu wird jeder Tag in 86400 s eingeteilt. Die Werte der Wahrscheinlichkeitsfunktion liegen zwischen 0 und 1. Um die Verteilung so fair wie m¨ oglich zu gestalten, wird zun¨achst f¨ ur jede Sekunde gem¨aß der Gesamtanzahl von Anfragen und der Gesamtzahl Sekunden ausgew¨ urfelt, ob die aktuelle Sekunde u ¨berhaupt in die Verteilung einbezogen wird. Ist dies der Fall, so wird im zweiten Schritt gem¨ aß der Wahrscheinlichkeitsfunktion ausgew¨ urfelt, ob eine Anfrage platziert wird. Dieses Verfahren wird solange reihum angewendet, bis die gew¨ unschte Anzahl Anfragen verteilt wurde. Zus¨ atzlich wird zu jeder Anfrage auch deren Dauer vermerkt. Dabei haben alle Anfragen einer Simulationseingabe die gleiche Dauer, um die Vergleichbarkeit der Ergebnisse zu gew¨ahrleisten. Diese Datei wird f¨ ur alle nachfolgenden Simulationsl¨ aufe benutzt. Ausgabedatei Die Ausgabedatei enth¨ alt nach der Simulation f¨ ur jeden der betrachteten 86400 Zeitschritte die aktuelle Anzahl gerade in Bearbeitung befindlicher Anfragen. Dazu z¨ ahlen auch Anfragen, die zwar schon abgesetzt, aber noch nicht auf eine VM zugewiesen wurden. Zus¨ atzlich enth¨alt jeder Zeitschritt auch die Anzahl aktuell instanziierter VM-Ressourcen. Diese Datei wird f¨ ur jeden Simulationslauf neu berechnet und dient vornehmlich der Visualisierung der Ergebnisse. 2

Verf¨ ugbar unter Onlineressource http://code.google.com/p/cloudsim/ (abgerufen am 16.2.2014)

90

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

100000 Anfragen pro Tag, 20min Anfragelänge

100000 Anfragen pro Tag, 20min Anfragelänge

# bearbeiteter Anfragen (immediate) # benötigter VMs (immediate) # Anfragen

2500

# Anzahl

# Anzahl

2000 1500

100000 Anfragen pro Tag, 20min Anfragelänge

2000

2000

1800

1800

1600

1600 # Anzahl

3000

1400

1400

1000

1200

1200

500

1000

1000

0

800

800

0

0

:0

0

:0

00

0

0

:0

22

20

0

:0

:0

18

0

:0

16

0

:0

14

0

:0

12

0

:0

10

0

:0

08

0

:0

Tageszeit

1.Lauf (Abweichung Vorlauf +193 %)

06

0

:0

04

:0

02

00

0

0

:0

0

0

:0

00

22

0

:0

:0

20

0

:0

18

0

0

:0

16

14

0

:0

:0

12

0

:0

10

0

0

:0

08

06

0

:0

:0

04

:0

02

00

0

0

0

:0

:0

00

0

:0

22

0

:0

20

0

0

:0

18

16

0

:0

:0

14

0

:0

12

0

0

:0

10

08

0

:0

:0

06

0

:0

:0

04

02

00

Tageszeit

0.Lauf (Abweichung Vorlauf −−)

Tageszeit

2.Lauf (Abweichung Vorlauf +0, 8 %)

Abbildung 5.10: Ann¨ aherung einer Folge von Simulationen unter Verwendung der unmittelbaren Ressourcenallokationsstrategie. Simulationszustand Um mehrere Simulationsl¨aufe aufeinander folgender Tage durchf¨ uhren zu k¨ onnen, enth¨ alt diese Datei den Endzustand der Simulation als Eingabe f¨ ur den n¨achsten Tag. Dies ist wichtig, damit Simulationen mit vielen Anfragen auch konvergieren und stabile Ergebnisse liefern. Diese Datei ist also vor dem ersten Simulationslauf leer und enth¨ alt sonst die zum Ende der Simulation noch offenen Anfragen und gestarteten VMs. Dieser Zustand wird zu Beginn des n¨achsten Simulationslaufs eingelesen und wiederhergestellt. Statistikausgabe Diese Datei enth¨alt die w¨ahrend eines Simulationslaufes gesammelten Statistikinformationen. Dazu z¨ ahlen: • die Gesamtlaufzeit aller ben¨otigten VM-Instanzen, • die maximale und durchschnittliche Anzahl gleichzeitig instanziierter VMs, • die Anzahl tats¨ achlich vollst¨andig bearbeiteter Anfrage, • die Summe der Ausf¨ uhrungszeit aller vollst¨andig bearbeiteten Anfragen, • die maximale und durchschnittliche Anfragebearbeitungszeit, • und die maximale und durchschnittliche VM-Allokationszeit. Die Simulation wird dadurch bearbeitet, dass auftretende Ereignisse nach ihrer zeitlichen Abfolge durch einen einzelnen Thread bearbeitet werden. Zu diesen Ereignissen z¨ahlen beispielsweise das Starten einer Anfrage, das Beenden einer Anfrage und das Beenden einer VM. Ausgangspunkt sind die durch das Einlesen des Simulationszustands und der Anfrageverteilung gespeicherten Ereignisse. Zur Laufzeit kommen dazu je nach Simulationslauf weitere Ereignisse wie das Starten und Beenden von VMs hinzu. Besonders kritisch ist bei diskreten Ereignissimulationen die Abspeicherung und zeitliche Sortierung der Ereignisse, um das n¨achste Ereignis zu bestimmen. Dazu wird im Allgemeinen ein Fibonacci-Heap verwendet. Auf diesem speziellen Heap sind vor allem die oft ben¨otigte Einf¨ uge- und Entnahmeoperation von konstanter asymptotischer Laufzeit O(1). Weitere Informationen zu dieser Datenstruktur sind beispielsweise in [CLRS01, S. 476ff.] zu finden. F¨ ur Java gibt es eine Reihe von Implementierungen dieser Struktur. F¨ ur den Simulator wurde die Implementierung von JGraphT 3 verwendet. Startet man eine neue Simulation, so muss diese zun¨achst einen stabilen Zustand 3

Verf¨ ugbar unter Onlineressource http://jgrapht.org/ (abgerufen am 16.2.2014)

91

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

Tabelle 5.2: VM-Bedarf f¨ ur verschiedene Allokationsstrategien (gleichzeitig aktive VMs)

erreichen. Dazu wird die Simulation mehrfach nacheinander durchgef¨ uhrt und die Ausgabe eines Simulationslaufs als Eingabe des n¨achsten Simulationslaufs benutzt. Die Simulation wurde beendet, wenn die Ergebnisse von zwei aufeinander folgenden Simulationsl¨aufen sehr ¨ahnlich waren. Als Metrik wurde die Summe der insgesamt verbrauchten VM-Laufzeit gew¨ahlt. Als ¨ ahnlich gelten die Simulationsl¨aufe in dieser Arbeit, wenn sich die verbrauchte VM-Laufzeit um weniger als einen Wert  von 1 % unterscheidet. Abbildung 5.10 visualisiert das Ann¨ahern der einzelnen Simulationsl¨aufe, welches besonders bei der unmittelbaren Allokationsstrategie mit vielen Anfragen lange dauern kann, da weniger h¨aufig neue Maschinen gestartet werden. Ein  von 1 % f¨ uhrte zum zuverl¨assigen konvergieren, gemeint ist hier der Abbruch der Simulation durch das Unterschreiten von , aller in dieser Arbeit durchgef¨ uhrten Simulationen. Die Allokationsstrategien sind so implementiert, dass sie stets versuchen, die Anzahl von VM-Instanzen an die Anzahl konfigurierter Anfragen anzupassen. F¨ ur einige Simulationsl¨ aufe f¨ uhrt dies dazu, dass die Ausgabe der Simulation wieder exakt der Eingabe entspricht, beispielsweise bei gleichbleibenden Anfrageanzahlen u ¨ber einen ganzen Tag. Somit w¨aren auch aufeinander folgende Simulationsl¨aufe exakt gleich. F¨ ur sehr viele Anfragen ist es jedoch unwahrscheinlich, dass die Ausgabe erneut der Eingabe entspricht. Somit weichen aufeinander folgende Simulationsl¨ aufe immer wieder etwas ab. Darum wird die Simulation in dieser Arbeit als konvergiert betrachtet, wenn einzelne Simulationsl¨aufe nicht mehr als den Wert  voneinander abweichen. Jeder Simulationslauf ist in Java als ausf¨ uhrbares Objekt (Runnable) gekapselt. Somit k¨onnen unabh¨ angige Simulationen, beispielsweise f¨ ur verschiedene Anfrageanzahlen parallel verarbeitet werden. Das einmalige Ausf¨ uhren aller in Tabelle 5.2 visualisierten Simulationskonfigurationen konnte so auf dem Dell Latitude Laptop (siehe Anhang A) unter Ausnutzung von 8 Threads in ca. 28 min fertiggestellt werden.

5.4.5 Simulationsergebnisse #

ragen Es wurden Simulationen mit 100 bis 1000000 Anfragen pro Tag ( Anf ) durchgef¨ uhrt. T ag Außerdem wurde dabei ∆twork der Anfragen REQs zwischen 2 s bis zu 20 min variiert. Das Variieren von ∆twork kann dabei nicht nur als Anfragen unterschiedlicher L¨ange verstanden werden, sondern es kann auch verschiedene VM-Typen repr¨asentieren, die sich in der Geschwindigkeit unterscheiden. Ein k¨ urzeres ∆twork kann also auch die gleiche Anfrage auf einer schnelleren Maschine repr¨ asentieren. Jede Simulation wurde mehrfach durchgef¨ uhrt. Dabei wurde Sf inal f¨ ur die nachfolgende Simulation als Sinit benutzt. Die Simulationen wurden zun¨achst so oft durchgef¨ uhrt, bis sich die Simulation stabilisierte. Danach wurden 10 weitere L¨aufe nach der gleichen Vorgehensweise gestartet. Die hier pr¨asentierten Ergebnisse zeigen die durchschnittlichen Werte dieser 10 Simulationsl¨aufe. #req Abbildung 5.9 zeigt die Simulationsergebnisse f¨ ur 100000 day und ∆twork von 20 min. Das Diagramm stellt, wie auch in Abbildung 5.8, die Summe aller gleichzeitig bearbeiteten Anfragen REQ und der gleichzeitig aktiven virtuellen Maschinen VMs u ¨ber den Zeitraum eines Tages f¨ ur beide Allokationsstrategien dar. Dabei bedeutet der Abstand zwischen der Simula-

92

5.4 Scheduling und Lastbalancierung seitens des Cloud-Anbieters

Abbildung 5.11: Ungenutzte VM-Laufzeit (Kostenoverhead)

Abbildung 5.12: Zeitlicher Allokationsoverhead ∆toverhead

tionseingabe der Anfragen (dunkelblaue Linie) und den verwendeten V M s (gr¨ une/hellblaue Linie) den Overhead an Ressourcen f¨ ur die jeweilige Allokationsstrategie. Es wird sichtbar, dass die Linie der simulierten Anfragen f¨ ur die exklusive Allokationsstrategie (violette Linie) beinahe mit der Linie der Simulationseingaben identisch ist, was eine sehr gute Qualit¨at der Bearbeitung der Anfragen bedeutet. Allerdings werden dazu auch etwas mehr Ressourcen verwendet als bei der unmittelbaren Strategie. Die Linie der simulierten Anfragen f¨ ur die unmittelbare Allokationsstrategie (rote Linie) ist hingegen oft u ¨ber der Line der Simulationseingaben, was f¨ ur einzelne Anfragen auf ein deutlich messbares ∆toverhead schließen l¨asst. Dies ist vor allem der Fall, wenn die Anzahl der Anfragen in kurzer Zeit stark ansteigt, beispielsweise zwischen 6 und 10 Uhr. Das bessere Reaktionsverhalten von Falloc exklusive ist vor allem darauf zur¨ uckzuf¨ uhren, dass hier im Vergleich zu Falloc immediate nicht nur periodisch die Anzahl der Ressourcen erh¨ oht wird, sondern auch jedes Mal, wenn keine Ressourcen mehr zur Verf¨ ugung stehen. Dadurch reagiert Falloc exklusive schneller auf große Spitzen in der Anfrageanzahl, nutzt zur Beantwortung jedoch auch mehr Ressourcen. Weitere Visualisierungen der durchgef¨ uhrten Simulation mit anderen Parametern sind in Anhang C dargestellt. Tabelle 5.2 zeigt die durchschnittliche und maximale Anzahl von gleichzeitig aktiven VMs # ragen f¨ ur beide Allokationsstrategien unter verschiedenen Bedingungen f¨ ur Anf und ∆twork . T ag Beide Strategien haben relativ ¨ ahnliche Anforderungen. Abbildung 5.11 zeigt, dass der Over# ragen head in Bezug auf ungenutzte VM-Laufzeit f¨ ur viele Anfragen pro Tag ( Anf ) und lange T ag Anfragen (∆twork ) am Kleinsten ist. Der Overhead reflektiert auch die Kosteneffizienz der Strategie, da ungenutzte VM-Laufzeit trotzdem bezahlt werden muss, jedoch nicht auf den Anwendungs-Nutzer umgelegt werden kann. Weniger ungenutzte VM-Laufzeit bedeutet also einen geringeren Kostenoverhead, was zu einem geringeren Preis pro Anfragesekunde f¨ uhrt. Ein wesentlicher Vorteil der exklusiven Allokationsstrategie wird in Abbildung 5.12 deutlich. Der Overhead ∆toverhead kann mit dieser Strategie auf ∆tstartup =150 s begrenzt werden. Dies bedeutet, dass obwohl ein Nutzer eventuell kurz warten muss, bis die Bearbeitung seiner Anfrage beginnt, die Anfragezeit durch eine ober Schranke begrenzt wird. Dadurch wird die erwartete Anfragezeit vorhersehbarer. Außerdem l¨asst sich in Abbildung 5.12 erkennen, dass der Overhead bei steigender Anzahl an Anfragen pro Tag und steigender Anfragedauer abnimmt. Erreicht wird dies durch eine bessere VM-Wiederverwendungswahrscheinlichkeit, da mehr VMs aktiv sind. Außerdem ist absolut auch die Anzahl numstandby von ReserveV M s h¨oher. Wie bereits in Abbildung 5.9 dargestellt wurde, hat die unmittelbare Allokationsstrategie Probleme, die Anzahl Standbyinstanzen zu regulieren, wenn die Anzahl von Anfragen stark ansteigt. Ein hoher Overhead ∆toverhead ist die Folge. Diesen Effekt kann

93

5 Server-unterst¨ utzte mobile Anwendungen auf Cloud-Technologien

Abbildung 5.13: Daten¨ ubertragungskosten im Vergleich zu gesamten Cloud-Nutzungskosten.

man auch an den maximalen Werten in Abbildung 5.12 wiedererkennen. Trotzdem l¨asst sich auch feststellen, dass die durchschnittlichen Werte f¨ ur den Overhead viel niedriger sind als die Maximalwerte und dass die durchschnittlichen Werte beider Strategien recht ¨ahnlich sind.

5.4.6 Daten¨ ubertragungskosten Bei der Nutzung von Infrastrukturdiensten wie VMs fallen nicht nur Kosten f¨ ur die Nutzung der eigentlichen Ressourcen an, auch die Daten¨ ubertragungskosten sind zu ber¨ ucksichtigen. Nachdem der Kostenoverhead f¨ ur die Allokationsstrategien bestimmt wurde, ist zudem interessant, in welchem Verh¨ altnis zur eigentlichen Nutzungsgeb¨ uhr die Daten¨ ubertragungskosten stehen. Dazu wird bez¨ uglich der Kosten exemplarisch die Situation im Amazon EC2 Rechenzentrum in Irland betrachtet. Daten¨ ubertragungskosten werden quasi doppelt abgerechnet. Einerseits finden sie sich bereits in der VM-Nutzungsdauer wieder, da w¨ahrend Daten zur VM u ¨bertragen werden, diese auch aktiv sein muss und somit Geld kostet. Zus¨atzlich wird jedes Byte, welches aus dem Amazon Rechenzentrum heruntergeladen wird, in verschiedenen Stufen, je nach Menge der Gesamt¨ ubertragungsdaten im Monat, abgerechnet. Der Upload von Daten ist kostenlos. Zur Vereinfachung wurde angenommen, dass f¨ ur jedes angefangene GigaByte 0,12 $ berechnet werden. Diese Kosten reflektieren die pessimistischste Variante. Je nach tats¨ achlicher Nutzung kann es jedoch nur g¨ unstiger werden. Die genauen Abrechnungsmodalit¨ aten f¨ ur Daten¨ ubertragungen zu verschiedenen Cloud-Rechenzentren sind in Anhang B angegeben. Abbildung 5.13 zeigt die Daten¨ ubertragungskosten relativ zu den entstehenden VM-Kosten f¨ ur verschiedene Simulationseingaben. Da l¨angere Berechnungen auch etwas mehr an Download Traffic erzeugen, wurde die Datenmenge der Nutzungsdauer angepasst. Das Diagramm ¨ zeigt Daten¨ ubertragungen von 0,2 bis 60 MB. F¨ ur die kurze Ubertragungsdauer sind die ¨ prozentualen Ubertragungskosten besonders niedrig. Da die Daten¨ ubertragungskosten f¨ ur alle verschiedenen VM-Instanztypen konstant sind, reflektiert das Diagramm jedoch auch den Kostenoverhead, wenn teurere Instanztypen verwendet werden. Weniger performante Instanz-

94

5.5 Fazit

typen sind g¨ unstiger und kosteneffizienter, wodurch sich der relative Anteil der Daten¨ ubertragungskosten an den Gesamtkosten erh¨oht. Ebenso ist der Overhead f¨ ur wenige Anfragen pro Tag sehr hoch, wie bereits in Abbildung 5.11 zu sehen war, wodurch die Daten¨ ubertragungskosten relativ gesehen in diesem Szenario geringer werden. Zus¨atzliche Kosten, die f¨ ur die Datenspeicherung anfallen, wurden nicht mit in die Berechnungen inbegriffen, da diese nur 0,0024 US cent pro Anfrage ausmachen w¨ urden. Zusammenfassend ist zu sagen, dass die Daten¨ ubertragungskosten eher einen geringen Anteil an den Gesamtkosten haben, jedoch im Gegensatz zu den Kosten f¨ ur die Datenspeicherung nicht zu vernachl¨ assigen sind. Sie werden deshalb im Folgenden bei der Berechnung der Nutzungskosten auch weiter betrachtet.

5.5 Fazit In diesem Kapitel wurde untersucht, wie die Forderung nach einer exklusiven Ressourcenallokation f¨ ur jeden Client den Kostenoverhead f¨ ur die VM-Nutzung beeinflusst. Dabei wurde die Wiederverwendung von VM-Ressourcen zur Kostenreduktion als essentiell eingef¨ uhrt. Danach wurde eine Architektur vorgestellt, die VM-Ressourcen u ¨ber einen Broker-Server an die einzelnen Clients zuweist. In einer Simulation wurde die durchschnittliche VM-Allokationsdauer im Vergleich zu einer traditionellen Strategie mit Multiplexing von Anfragen verglichen. Gegen¨ uber der traditionellen unmittelbaren Ressourcenallokation stellt die exklusive Allokationsstrategie eine obere Schranke bez¨ uglich der Allokationsdauer f¨ ur eine VM nahezu sicher. Trotz dieser Verbesserung offenbarte eine Simulation, dass die exklusive Allokationsstrategie in Bezug auf den Kostenoverhead ein ¨ahnliches Verhalten zeigt wie die unmittelbare Allokationsstrategie, also f¨ ur die meisten simulierten F¨alle nicht teurer ist. F¨ ur die exklusive Allokationsstrategie dauert die Allokation f¨ ur die simulierten F¨alle im Mittel nicht l¨anger als ca. 10 s. F¨ ur die unmittelbare Allokationsstrategie war der Aufschlag auf die Ausf¨ uhrungszeit hingegen nicht nur im Mittel, sondern auch absolut, wesentlich h¨oher. F¨ ur die nachfolgenden Betrachtungen l¨asst sich im Ergebnis festhalten, dass eine VM zur Nutzung durch eine Mobile Cloud-unterst¨ utzte Anwendung exklusiv zugewiesen werden kann und dass die daf¨ ur notwendige exklusive Ressourcenallokation mit absch¨atzbarem Overhead realisierbar ist. Somit k¨ onnen nachfolgend Vorhersagealgorithmen u uhrungszeit ¨ber die Ausf¨ von Applikationen entwickelt werden, die die exklusive VM-Nutzung voraussetzen. Als Einschr¨ ankung bez¨ uglich der Verbesserung der Granularit¨at der Abrechnungsperiode stellte sich heraus, dass f¨ ur wenige kurze Anfragen u ¨ber einen Tag verteilt kaum eine Verbesserung erreicht werden kann. Erst ab ca. 10000 Anfragen/Tag, die jeweils ca. 1 min dauern, kann der Overhead auf das Doppelte begrenzt werden. Das heißt, dass eine so abgerechnete Minute Berechnungszeit circa der Nutzungsgeb¨ uhr f¨ ur zwei Minuten Berechnungszeit entspricht. Im Ergebnis kann nun zwar eine sekundengenaue Erfassung der Nutzungsdauer f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen implementiert werden, der Abrechnungspreis muss jedoch je nach tats¨ achlichem Nutzungsverhalten in der Vergangenheit angepasst werden. Aufgrund der Wiederverwendung von VMs f¨ ur verschiedene Anwendungen, muss der Programmcode durch den Client zur Laufzeit installiert werden. Dies f¨ uhrt zu der Einschr¨ankung, dass die Installation und Daten¨ ubertragung des Programmcodes in angemessenem Verh¨altnis zur Ausf¨ uhrung der eigentlichen Applikation stehen muss. Abschließend wurde festgestellt, dass auch die Daten¨ ubertragungskosten nicht zu vernachl¨assigen sind und somit nachfolgend in die Kostenvorhersage integriert werden m¨ ussen.

95

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit Mobile Cloud-unterst¨ utzte Anwendungen nutzen Cloud-Ressourcen zur entfernten Ausf¨ uhrung von berechnungsintensiven Programmmodulen. Dieses Kapitel widmet sich der Auswahl der Qualit¨at verf¨ ugbarer Cloud-Ressourcen (VMs). Das Treffen einer Auswahl ist n¨otig, da seitens des IaaS-Anbieters u ugung ¨blicherweise verschiedene Ressourcenkonfigurationen zur Verf¨ stehen. Nicht alle k¨ onnen jedoch f¨ ur eine konkrete Situation zur Laufzeit sinnvoll verwendet werden, da sie eventuell keine schnellere Ausf¨ uhrung erm¨oglichen oder die Kostenbeschr¨ankung verletzen, die in Kapitel 3 definiert wurde. Dar¨ uber hinaus hat jeder Nutzer eventuell eigene Vorgaben bez¨ uglich der Qualit¨ atsauswahl. So k¨onnte ein Nutzer etwa die bestm¨ogliche Performance pro Geldeinheit als Ziel haben und nicht die maximal m¨ogliche Performance. Die Auswahl h¨ angt von der momentan verf¨ ugbaren Netzwerkperformance ab, deren Bestimmung in Kapitel 4 behandelt wurde. Es ist beispielsweise un¨okonomisch, eine performante und teure Ausf¨ uhrungsressource auszuw¨ahlen, wenn diese dann aufgrund einer zu geringen Netzwerkperformance nicht schnell genug mit Daten versorgt werden kann. Die Ausf¨ uhrungsgeschwindigkeit der eigentlichen Applikation auf verschiedenen VM-Typen ist demnach auch wichtig f¨ ur die Ressourcenauswahl. In diesem Kapitel wird deshalb der Einfluss des Applikationsverhaltens auf die Auswahl der zur Verf¨ ugung stehenden Cloud-Ressourcen untersucht. Ziel ist es, eine Methode zu entwickeln, die das Applikationsverhalten approximiert und es so erm¨oglicht, f¨ ur eine spezifische Eingabe die Laufzeit vorherzusagen. Da nicht jedes Applikationsverhalten vorhersagbar modelliert werden kann, werden auch Grenzen des Verfahrens beschrieben und Applikationen genannt, die mit dem hier beschriebenen Verfahren nicht erfasst werden k¨onnen. Nachdem in Kapitel 5 die Anwendbarkeit eines exklusiven Allokationsmechanismus gezeigt wurde, wird in diesem Kapitel davon ausgegangen, dass f¨ ur jede entfernte Ausf¨ uhrung stets eine Ressource exklusiv zur Verf¨ ugung steht. Dadurch sind bei der Ausf¨ uhrung einer Mobilen Cloudunterst¨ utzten Anwendung Seiteneffekte durch andere gleichzeitig ausgef¨ uhrte Anwendungen ausgeschlossen. Außerdem spielen die Kosten f¨ ur die Nutzung von Cloud-Ressourcen und damit auch der Kostenoverhead nur eine untergeordnete Rolle. Es wird davon ausgegangen, dass VMs eines IaaS-Anbieters sekundengenau abgerechnet werden k¨onnen. Somit lassen sich neben der Laufzeit auch die Kosten vorhersagen.

6.1 Auswahlstrategien Zur Modellierung des Entscheidungsmodells zur Ressourcenauswahl ist es notwendig, Mobile Cloud-unterst¨ utzte Anwendungen zu kategorisieren und die Applikationen zu identifizieren, f¨ ur die eine Auswahl zur Laufzeit nicht vorgenommen werden kann. F¨ ur die vom Modell erfassten Applikationen wird anschließend analysiert, wie deren Verhalten f¨ ur verschiedene Eingaben und auf verschiedenen Ressourcentypen realistisch approximiert werden kann.

96

6.1 Auswahlstrategien

6.1.1 Klassifikation von Mobilen Cloud-unterst¨ utzten Anwendungen Zun¨achst wird die Berechnung der Laufzeit und die allgemeine Funktionsweise von Mobilen Cloud-unterst¨ utzten Anwendung kurz wiederholt (siehe Kapitel 3). Zur Repr¨ asentation der Ausf¨ uhrungszeit eines auf einem entfernten Server bearbeiteten Programmabschnitts wurde in Gleichung (3.13) die Variable ∆twork eingef¨ uhrt. Sie erh¨ alt ihren Wert durch Berechnung der Laufzeitfunktion lauf (R, pi .ei ). Die Ausf¨ uhrungszeit ist demnach von der Ressource R, dem Applikationscode pi und der eigentlichen Eingabe ei abh¨angig. Da das Laufzeitverhalten jedoch f¨ ur verschiedenen Programmcode auf verschiedenen Ressourcen unterschiedlich sein kann, wird intern f¨ ur jede Kombination aus R und pi eine separate Laufzeitfunktion laufR,pi (ei ) benutzt, die nur von der Eingabe abh¨angt. Will man lauf (...) approximieren und zur Vorhersage der Laufzeit benutzen, so ist zun¨achst f¨ ur jede Kombination aus Programmmodul pi und Ressource R eine separate Laufzeitfunktion laufR,pi (ei ) zu erstellen. Hierzu kann die Methode der Regressionsanalyse eingesetzt werden, auf die sp¨ ater noch eingegangen wird. Als Ressourcen R werden die verf¨ ugbaren VMs aus dem Portfolio des verwendeten IaaS-Anbieters eingesetzt. Anforderungen an diese Ressourcen werden sp¨ater beschrieben. Die in Kapitel 4 vorgeschlagene Kommunikation mittels Pipelining auf einer persistenten TCP-Verbindung impliziert die Kapselung des entfernt auszuf¨ uhrenden Programmcodes in einzelne Tasks. Je nach Interpretation der Laufzeitfunktion lauf (...) kann diese f¨ ur jede Task einzeln (pi ) oder als Komposition f¨ ur die Gesamtausf¨ uhrung aller Tasks als Programm P betrachtet werden (siehe Kapitel 3.1.1). Nicht f¨ ur jedes taskbasierte Programm kann eine Laufzeitvorhersage realisiert werden. Deshalb werden in diesem Kapitel taskbasierte Applikationen weiter differenziert. Das Applikationsverhalten kann unterschieden werden in benutzerterminierte und eingabeterminierte Applikationen. Eine eingabeterminierte Applikation endet, wenn die Eingabe verarbeitet wurde. Die Eingabe ist hier also vollst¨andig bekannt und die Laufzeit somit vorhersagbar. Ein Beispiel ist die Ausf¨ uhrung einer Gesichtserkennungssoftware auf einem einzelnen Foto. F¨ ur eingabeterminierte Programme wird die Laufzeitfunktion laufsingle (. . . ) verwendet, welche eine Laufzeit in Sekunden angibt. F¨ uhrt man die Gesichtserkennungssoftware jedoch auf sehr vielen Bildern oder auf einem laufenden Kamerabilddatenstrom aus, so terminiert nicht die Eingabe, sondern der Benutzer die Applikation, wenn er abbrechen m¨ochte. Dabei handelt es sich um eine benutzerterminierte Applikation. Die vollst¨andige Eingabe ist nicht bekannt. Nur f¨ ur einzelne Tasks pi kann die Laufzeit approximiert werden. Eine Laufzeitvorhersage ist hier nur f¨ ur einen fortlaufenden Strom von Tasks gleicher Art und gleicher Eingabe als Rate m¨ oglich. F¨ ur benutzerterminierte Applikationen ist die Laufzeitvorhersage demnach nur eingeschr¨ ankt m¨ oglich. F¨ ur mehrere einzelne Tasks wird die Laufzeitfunktion ratemulti (R, pi , ei ) verwendet, welche die Anzahl von pro Sekunde ausgef¨ uhrter Tasks als Rate angibt. Als Schlussfolgerung muss lauf (. . . ) f¨ ur jede Art Applikation verschieden berechnet werden. Es wird also zun¨ achst unterschieden in: laufsingle (R, pi , ei ) = b lauf (R, pi .ei ), 1 ratemulti (R, pi , ei ) = b . lauf (R, pi , ei )

(6.1) (6.2)

Daraus resultiert auch, dass die Auswahl geeigneter Ressourcen zur Laufzeit verschiedenen Anspr¨ uchen gen¨ ugt und somit nicht gleichartig f¨ ur beide F¨alle durchgef¨ uhrt werden kann. Diese Erkenntnis wird sp¨ ater beim Entwurf von Algorithmen zur Ressourcenauswahl ber¨ ucksichtigt.

97

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Tabelle 6.1: Kategorisierung von Tasks in 9 Kategorien nach deren Eigenschaften Ausf¨ uhrungsmodus Einzelprozessortasks unabh¨ angig/simultan 1 teils sequentiell 2 sequentiell 3  werden f¨ ur die Laufzeitvorhersage unterst¨ utzt

gemischte Tasks 8 9 4

Multiprozessortasks 7 6 5

Die Zuordnung einer Applikation zu den beschriebenen F¨allen kann aufgrund der Taskeigenschaften der Applikation erfolgen. Dazu werden die Eigenschaften der Tasks genauer untersucht. Es kann eine Unterscheidung bez¨ uglich der Nutzung mehrerer CPU-Kerne f¨ ur einzelne Tasks vorgenommen werden. Eine Applikation kann somit aus Einzelprozessortasks, aus Multiprozessortasks oder aus beiden Varianten gleichzeitig bestehen. Zudem k¨onnen Tasks bez¨ uglich ihrer Datenabh¨ angigkeiten in die Ausf¨ uhrungsmodi sequentiell und simultan unterteilt werden. Bez¨ uglich der Datenabh¨angigkeit der Tasks und deren Multithreadf¨ahigkeit gibt es neun verschiedene F¨ alle, die in Tabelle 6.1 zusammengefasst sind. Datenabh¨angigkeiten in der Ausf¨ uhrungsstruktur verschiedener Tasks k¨onnen als Taskgraphen (Directed Acyclic Graph (DAG)) modelliert werden [Hun09]. Existieren keine Datenabh¨angigkeiten zwischen Tasks, sind sie also unabh¨ angig, so k¨ onnen diese simultan, also parallel, ausgef¨ uhrt werden. Außerdem kann es auch Applikationen geben, bei denen die Ergebnisse einzelner Tasks aufeinander aufbauen. Die Tasks m¨ ussen dann sequentiell, also der Reihe nach, ausgef¨ uhrt werden. Sequentielle Verarbeitung bedeutet, dass, bevor ein neuer Task abgesetzt wird, zun¨achst die Bearbeitung des Vorangegangenen abgewartet werden muss. Als dritte Variante gibt es zudem Applikationen, bei denen Tasks beider Ausf¨ uhrungsmodi simultan vorhanden sind. Es k¨onnen jedoch nicht alle F¨ alle aus Tabelle 6.1 durch die Laufzeitfunktionen laufsingle und ratemulti repr¨ asentiert werden. Nachfolgend wird anhand der Nummerierung erl¨autert, welche F¨alle aus welchem Grund unterst¨ utzt oder nicht unterst¨ utzt werden k¨onnen. • Die Kombinationen 6–9 entfallen. Die Middleware besitzt keine Schedulingkomponente, die Tasks mit verschiedener Prozessorzahl sinnvoll gleichzeitig unter Minimierung der Gesamtlaufzeit auf einer VM ausf¨ uhren kann. Solche Algorithmen sind komplex und Gegenstand der aktuellen Forschung [IOY+ 11]. Da diese Taskanordnung aber f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen unwahrscheinlich ist und eher im wissenschaftlichen Rechnen vorkommt, sind solche komplexen Schedulingalgorithmen nicht Gegenstand dieser Arbeit. Komplexe Taskanordnungen (Taskgraphen) m¨ ussen gem¨aß der Datenabh¨angigkeiten in ihrer Ausf¨ uhrungsreihenfolge sequentialisiert werden, sodass sie sich auf eine der Kategorien 3–5 abbilden lassen. Dies kann beispielsweise durch eine topologische Sortierung erreicht werden. • Die Kombination 2 entf¨ allt. Die Laufzeitfunktionen laufsingle (. . . ) und ratemulti (. . . ) sind nur in der Lage, f¨ ur sequentielle und f¨ ur gleichartige simultan ausgef¨ uhrte Tasks die Laufzeit vorherzusagen. Das Mischen wird nicht unterst¨ utzt. Die Vorhersage kann dennoch erm¨ oglicht werden, wenn die Ausf¨ uhrungsreihenfolge sequentialisiert wird. • Die Kombination 1 wird von ratemulti (. . . ) unterst¨ utzt. Bei dieser Variante k¨onnen so viele Einzelprozessortasks simultan ausgef¨ uhrt werden wie CPUs vorhanden sind. • Die Kombinationen 3–5 werden von laufsingle (. . . ) unterst¨ utzt.

98

6.1 Auswahlstrategien

In Tabelle 6.1 sind alle F¨ alle, die ohne Einschr¨ankungen durch eine Laufzeitfunktion beschrieben werden k¨ onnen, grau markiert. Es wird darauf hingewiesen, dass Mobile Cloudunterst¨ utzte Anwendungen aller Kombinationen auf der entwickelten Middleware lauff¨ahig sind. Jedoch kann die f¨ ur die bedarfsgerechte Auswahl von Ressourcen notwendige Laufzeitvorhersage nur f¨ ur die beschriebene Untermenge durchgef¨ uhrt werden.

6.1.2 Laufzeitprognose von Tasks Die Klassifikation von Mobile Cloud-unterst¨ utzte Anwendungen bez¨ uglich deren Laufzeitvorhersagbarkeit hat ergeben, dass nur sequentielle Ausf¨ uhrungsfolgen (eingabeterminierte Applikationen) und die simultane Ausf¨ uhrung gleichartiger Einzelprozessortasks (benutzerterminierte Applikationen) zur Laufzeitvorhersage geeignet sind. F¨ ur benutzerterminierte Applikationen wird eine Rate fwork multi angegeben, die die Taskverarbeitungen pro Sekunde angibt. Da jeweils nur ein CPU-Kern der VM pro Task genutzt wird, kann die Bestimmung von ratemulti (R, pi , ei ) um die simultane CPU-Kern-Nutzung erg¨anzt werden. Die Verbesserung wird im Vergleich zu Gleichung (6.2) wie folgt angegeben: fwork multi = ratemulti (R, pi , ei ) =

cores(R) . lauf (R, pi , ei )

(6.3)

Dabei liefert cores(R) die Anzahl verf¨ ugbarer CPU-Kerne der Ressource R zur¨ uck. Es wird davon ausgegangen, dass die tats¨ achliche Anzahl ausgef¨ uhrter Tasks hierbei wesentlich gr¨oßer ist als cores(R). F¨ ur eingabeterminierte Programme muss lauf (. . . ) demnach nur f¨ ur einzelne Tasks bestimmt werden. Anschließend wird ratemulti (. . . ) je nach CPU-Kernanzahl der Ressource R berechnet. Dies bedeutet auch, dass f¨ ur VM-Typen mit gleichgroßer Einzelprozessorgeschwindigkeit (beispielsweise c1.medium und c1.xlarge (siehe Anhang Tabelle B.3)) die gleiche Funktion lauf (. . . ) verwendet werden kann. Die schnellere Taskverarbeitung kann jedoch aufgrund der h¨ oheren Kommunikationsanforderungen zur Daten¨ ubertragung eventuell nicht erreicht werden. Dies wird sp¨ ater bei der Auswahl der Cloud-Optionen ber¨ ucksichtigt und wird innerhalb der Laufzeitfunktion ratemulti (. . . ) nicht betrachtet. laufsingle (R, L) kann die komplette Dauer eines Programmlaufs L unter Verwendung einer Menge von Programmmodulen pn und deren zugeh¨origen Eingaben en beschreiben (siehe Kapitel 3.1.1). Somit setzt sich die Laufzeit aus mehreren Einzellaufzeiten wie folgt zusammen:

∆twork single = laufsingle (R, L) =

|L| X

laufsingle (R, pn , en )

mit

(pn , en ) ∈ L. (6.4)

n=1

6.1.3 Auswahl einer geeigneten Ressource Wenn nun in einem konkreten Fall eine geeignete VM zur Ausf¨ uhrung ausgew¨ahlt werden soll, so muss f¨ ur jede konfigurierte VMx gepr¨ uft werden, ob sie die Bedingungen (3.12) und (3.18) erf¨ ullt. Die Bedingungen stellen sicher, dass die entfernte Ausf¨ uhrung tats¨achlich zu einer Laufzeitverk¨ urzung f¨ uhrt. Außerdem darf dabei das festgelegte Kostenlimit nicht u ¨berschritten werden. Als Ergebnis erh¨ alt man eine Menge von Cloud-Optionen, unter denen der Nutzer dann w¨ ahlen kann. Diese Menge von Cloud-Optionen wird als M c bezeichnet. Eine Cloud-Option Cx wird f¨ ur eingabeterminierte Applikationen beschrieben durch ein 3er-Tupel Cx = (VMx , ∆twork , costx ) bestehend aus dem VM-Typ VMx , der entfernten Laufzeit ∆twork

99

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

und den daf¨ ur entstehenden Kosten costx . F¨ ur benutzerterminierte Applikationen enth¨alt Cx anstatt ∆twork eine Rate fwork k . Nachfolgend wird beschrieben, wie die Mengen M csingle f¨ ur eingabeterminierte Programme und die Menge M cmultiple f¨ ur benutzerterminierte Programme zur Laufzeit berechnet werden. Berechnung von Cloud-Optionen f¨ ur eingabeterminierte Programme Die entfernte Ausf¨ uhrungszeit setzt sich zusammen aus der Zeit f¨ ur die Daten¨ ubertragung ∆tcomm und der eigentlichen Berechnungszeit ∆twork . Diese Zusammensetzung l¨asst sich auch erkennen, wenn man die Kriterien (3.12) und (3.18) betrachtet und die Variablen entsprechend f¨ ur eingabeterminierte Programme anpasst. Dies ist nachfolgend dargestellt. ∆tmobil , ∆tcomm und ∆twork k¨ onnen dabei aufgrund der sequentiellen Ausf¨ uhrung auch Summen der Verarbeitungs- und Kommunikationszeit mehrerer Tasks repr¨asentieren (siehe Kapitel 3.1.2 und 3.2). (schnellere entfernte Ausf¨ uhrung)

∆tmobil ≥ ∆tremote , ∆tmobil ≥ ∆tcomm + ∆twork ,

(Einhaltung der Kostenbeschr¨ ankung)

(6.5)

costlimit ≥ costx , costlimit ≥ costper s (VMx ) · ceil(∆tremote ). (6.6)

Die Funktion costper s (VMx ) liefert die Mietkosten f¨ ur die Ressource VMx pro Sekunde zur¨ uck. ceil(∆tremote ) liefert die auf volle Sekunden aufgerundete Laufzeitabsch¨atzung zur¨ uck. F¨ ur eingabeterminierte Programme, die aus einer Sequenz von Ausf¨ uhrungen zusammengesetzt sind, gilt zudem die Vereinfachung, dass nur die Summe der entfernten Gesamtlaufzeit kleiner als die Summe der mobilen Laufzeit sein muss. Somit ist das Kriterium (3.12) nicht mehr f¨ ur alle Einzeltasks einzuhalten. Außerdem wurde in Kapitel 5.1 gezeigt, dass die Nutzungsdauer durch Wiederverwendung anstatt auf Stundenbasis auch auf Sekundenbasis abgerechnet werden kann. Diese Verbesserung wurde in Bedingung (6.6) im Vergleich zu Bedingung (3.18) ber¨ ucksichtigt. Unter Ber¨ ucksichtigung der angepassten Kriterien (6.5) und (6.6) generiert Algorithmus 3 die Menge M c aller 3er-Tupel Cx = (VMx , ∆twork , costx ) f¨ ur eingabeterminierte Programme. Zun¨achst werden f¨ ur alle verf¨ ugbaren VM-Typen die erwartete Ausf¨ uhrungszeit und die Algorithmus 3 Generierung von M csingle Require: ∆tmobil , ∆tcomm , L, costper s {berechne Cx f¨ ur alle VMx des IaaS-Anbieters} M c = {} for all VMx ∈ Portfolio des IaaS-Anbieters do ∆twork = laufsingle (VMx , L) costx = costper s (VMx ) · ceil(∆tcomm + ∆twork ) if (∆tmobil ≥ ∆tcomm + ∆twork ) ∧ (costlimit ≥ costx ) then Cx = (VMx , ∆twork , costx ) M c = M c ∪ {Cx } end if end for

daraus entstehenden Kosten berechnet. Anschließend werden alle Optionen ausgefiltert, die ¨ nicht den Bedingungen (6.5) und (6.6) entsprechen. Ubrig bleibt die Menge M c aller m¨oglichen Cloud-Optionen.

100

6.2 Regressionsanalyse zur Laufzeiterfassung

Berechnung von Cloud-Optionen f¨ ur benutzerterminierte Programme F¨ ur die Berechnung der Menge M cmultiple ergibt sich eine leicht angepasste Variante der Berechnung unter Verwendung der Taskrate f . M cmultiple enth¨alt die Cloud-Optionen f¨ ur die fortlaufende Ausf¨ uhrung eines Tasks k, charakterisiert durch (pk , ek ), unter Verwendung der immer gleichen Eingabegr¨ oße ek . fmobil k ≤ fremote k , fmobil k ≤ M IN (fcomm k , fwork k ),

(6.7)

costlimit ≥ costk , costlimit ≥ costper s (VMx ).

(6.8)

Algorithmus 4 generiert M cmultiple unter Ber¨ ucksichtigung der f¨ ur benutzerterminierte Programme angepassten Kriterien (6.7) und (6.8). Zun¨achst wird durch ratemulti (. . . ) die Rate Algorithmus 4 Generierung von M cmultiple Require: fmobil k , fcomm k , pk , ek , costper s {berechne Cx f¨ ur alle VMx des IaaS-Anbieters} M c = {} for all VMx ∈ Portfolio des IaaS-Anbieters do fwork k = ratemulti (VMx , pk , ek ) costk = costper s (VMx ) if (fmobil k ≤ M IN (fcomm k , fwork k ) ∧ (costlimit ≥ costk ) then Cx = (VMx , M IN (fcomm k , fwork k ), costk ) M c = M c ∪ {Cx } end if end for

der Taskverarbeitung pro Sekunde f¨ ur jeden verf¨ ugbaren VM-Typ berechnet. Danach wird gepr¨ uft, ob der errechnete Wert h¨ oher ist als die Taskrate, die durch die Netzwerkperformance limitiert ist. Falls nicht, wird weiter gepr¨ uft, ob die Bedingungen (6.7) und (6.8) nicht verletzt werden. Zu beachten ist hierbei, dass das Kostenlimit auch pro Sekunde zu verstehen ist, da die Gesamtlaufzeit unbekannt ist. Die nicht ausgefilterten Cloud-Optionen werden anschließend in der Menge M c zusammengefasst und zur¨ uckgeliefert. F¨ ur die beschriebenen Auswahlstrategien wird im Folgenden die Laufzeitfunktion lauf (. . . ) zur Laufzeitvorhersage bestimmt. Die weiteren Betrachtungen beschr¨anken sich demnach auf einzelne Tasks, die durch eine einzelne Laufzeitfunktion lauf (...) repr¨asentiert sind. Außerdem sind je nach Approximationsqualit¨ at von lauf (. . . ) auch die zur Auswahl stehenden VMTypen vmx einzuschr¨ anken, um dem Endnutzer sinnvoll unterscheidbare Cloud-Optionen anzubieten.

6.2 Regressionsanalyse zur Laufzeiterfassung F¨ ur die Laufzeitvorhersage der Tasktypen, die in Kapitel 6.1.1 vorgestellt wurden, muss ein Zusammenhang zwischen der Eingabe und der Laufzeit hergestellt werden. Das Herstellen eines Zusammenhangs setzt voraus, dass die Funktionsweise des zu untersuchenden Tasks hinreichend bekannt ist. Die Laufzeitfunktion lauf (...) wird u ur verschiede¨ber Messungen f¨ ne Eingaben auf allen verf¨ ugbaren VM-Typen konstruiert. Daf¨ ur kommt die Methode der Regressionsanalyse zum Einsatz.

101

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

abhängige Größe (y−Werte)

2000

Datenpunkte lineare Funktion Polynom 2. Grades Polynom 3. Grades

1800 1600 1400 1200 1000 800 600 400 200 0 0

5

10

15 20 25 unabhängige Größe (x−Werte)

30

35

40

Abbildung 6.1: Beispiel einer Regressionsanalyse f¨ ur drei verschiedene Kurventypen. Die Messwerte (Datenpunkte) wurden generiert und dabei zuf¨allig entlang einer Parabel durch den Nullpunkt verteilt. Außerhalb der Messpunkte gehen die Werte der Approximationsfunktionen weit auseinander.

Im Allgemeinen dient eine Regresionsanalyse dazu, eine Vermutung u ¨ber den Zusammenhang einer bestimmten Art, beispielsweise einen linearen Zusammenhang, zu u ufen. Da¨berpr¨ bei wird die abh¨ angige Variable durch eine oder mehrere unabh¨angige Variablen bestimmt. Es k¨onnen nur die Parameter eines vermuteten Funktionstyps bestimmt werden, nicht jedoch die Art des Zusammenhangs selbst. Zur Durchf¨ uhrung werden viele aussagekr¨aftige Messwerte ben¨otigt, auf deren Qualit¨ at sp¨ ater noch eingegangen wird. Ein Messwert umfasst zugeh¨orige Werte der unabh¨ angigen Variablen (X-Wert, eventuell auch X1 ,X2 ,usw.) und den resultierenden Wert der abh¨ angigen Variable (Y-Wert). Die Regressionsanalyse muss f¨ ur jeden Typ von Task und auf jedem VM-Typ separat durchgef¨ uhrt werden, da f¨ ur jede Applikation und jeden VM-Typ unterschiedliche Verhaltensweisen m¨oglich sind. Ziel der Regressionsanalyse ist es, die Parameter einer vorgegeben Funktion zu bestimmen, von der die Abweichungen der Messpunkte minimal sind. Es wird davon ausgegangen, dass die so konstruierte Funktion auch f¨ ur weitere Werte der unabh¨angigen Gr¨oße gute N¨aherungen f¨ ur die abh¨ angige Gr¨ oße errechnet [Nie08, S. 114ff.]. Im Allgemeinen versucht man, die approximierte Funktion so einfach wie m¨oglich zu gestalten, also beispielsweise als Gerade. Verwendet man hingegen eine polynomielle Funktion, k¨onnen die Messpunkte eventuell besser verbunden werden, da die Funktion besser angepasst werden kann. Je spezieller die Funktion jedoch wird, desto mehr geht ihr Vorhersagecharakter verloren. Man spricht in die¨ ¨ sem Fall von Uberanpassung. Da die Verwendung von Polynomen schnell zur Uberanpassung f¨ uhren kann, wird bei Unkenntnis des Kurventyps in dieser Arbeit ausschließlich mit linearen Funktionen gearbeitet. Abbildung 6.1 visualisiert einige zuf¨allig entlang einer quadratischen Funktion verteilte Datenpunkte. Zudem enth¨alt die Abbildung drei m¨ogliche Approximationskurven verschiedenen Typs. Es ist gut erkennbar, dass die Kurven u ¨ber die Spannweite der Messpunkte eine brauchbare Approximation liefern k¨onnen. F¨ ur Werte außerhalb der Spannweite (siehe Abbildung 6.1 (rechte Seite)) weichen die Kurven jedoch sehr stark voneinander ab, sodass deren Vorhersagecharakter verloren geht. Generell ist die approximierte Funktion zun¨achst nur f¨ ur die Spannweite, also die Werte zwischen dem minimalen und dem maximalen Messpunkt, g¨ ultig. Vor allem f¨ ur Polynome ist diese Einschr¨ankung notwendig. Hat

102

6.2 Regressionsanalyse zur Laufzeiterfassung

Nein Auswahl Parameter für Regression

Regressionsanalyse

Parameter waren sinnvoll? (Ω und t-Werte)

Ja

Ausreißer Vorhanden? (Ausreißer-Test) Nein

Monitoring Daten

Start

Ausreißer ggf. ausfiltern

Ja

Fertig

Abbildung 6.2: Schematische Darstellung des Ablaufs einer Regressionsanalyse. man jedoch Kenntnis u ¨ber die Art der Abh¨angigkeit, so kann man anhand des Funktionstyps eventuell auch u uhrende Literatur zum ¨ber die Spannweite hinaus Aussagen treffen. Weiterf¨ Thema Regressionsanalyse ist in [FKL09, Nie08, Bra13] zu finden. Nachfolgend werden nur f¨ ur diese Arbeit wichtige Aspekte n¨ aher erl¨autert.

6.2.1 Voraussetzungen Im Allgemeinen wird davon ausgegangen, dass die Abweichung der Messpunkte von der zu approximierenden Kurve normalverteilt ist (siehe [Nie08, S.39]). Dazu ist es notwendig, dass mindestens 30 unabh¨ angige Messungen vorliegen, damit diese Annahme auch hinreichend gest¨ utzt wird. Um einen guten Vorhersagecharakter der Approximationsfunktion sicherzustellen, sollten die verwendeten Messpunkte zudem eine m¨oglichst große Spannweite (Abstand zwischen minimalem und maximalem Messwert) abdecken. Die Gesamtheit der betrachteten Messwerte/Messpunkte wird auch als Stichprobe bezeichnet. Wichtig ist, dass sich Median und Mittelwert der Stichprobe nicht deutlich unterscheiden. Andernfalls muss davon ausgegangen werden, dass es starke Ausreißer in der Stichprobe gibt, die auf Plausibilit¨at u uft ¨berpr¨ werden m¨ ussen. Besonders f¨ ur sehr kurze Ausf¨ uhrungsdauern im Millisekundenbereich, die bei Mobilen Cloud-unterst¨ utzten Anwendungen u au¨blicherweise nicht auftreten, existieren h¨ fig endlastige Verteilungen der Messwerte [TTH05]. Hierbei treten vereinzelt starke Ausreißer nach oben auf, die den Mittelwert verzerren. F¨ ur solche Verteilungen kann jedoch eventuell trotzdem eine Regressionsanalyse durchgef¨ uhrt werden. M¨ogliche Vorgehensweisen dazu sind in Abschnitt 6.2.4 beschrieben. Die abh¨ angige Variable wird aufgrund von Fremdeinfl¨ ussen oft nicht nur von der unabh¨ angigen Variable bestimmt. Man kann Fremdeinfl¨ usse jedoch manchmal nicht spezifizieren und somit nicht ausschließen. Treten also bei verschiedenen Messungen f¨ ur die gleiche unabh¨angige Variable deutlich verschiedene Ergebnisse auf, so muss der Grund f¨ ur das Verhalten n¨aher analysiert werden. Dass Fremdeinfl¨ usse gerade auch bei Java-Programmen auftreten k¨onnen, wird sp¨ater in Kapitel 6.4 noch n¨ aher erl¨autert. Kommen erkl¨arbare starke Schwankungen nur selten vor, kann man sie oft ausfiltern. Weiterhin ist es auch m¨oglich, aus mehreren Messwerten f¨ ur die gleiche unabh¨ angige Variable den Mittelwert zu bilden, ohne dass dabei der Vorhersagecharakter verloren geht.

103

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Es wird außerdem in dieser Arbeit eingeschr¨ankt, dass die X-Werte der Messpunkte (unabh¨angige Variablen) keinem Fehler unterliegen, da diese f¨ ur die Messung explizit festgelegt werden k¨onnen. Dadurch vereinfacht sich die Regression. Sind die Voraussetzungen bez¨ uglich der Qualit¨at der Datenpunkte erf¨ ullt, so kann die eigentliche Bestimmung der Parameter der Regressionsfunktion beginnen. Da die Parameter linear kombiniert werden, spricht man von linearer Regression. Hierbei liegt der Sch¨atzfunktion eine unabh¨ angige Variable zu Grunde. Liegt der Sch¨atzfunktion hingegen mehr als eine unabh¨angige Variable zu Grunde, so spricht man von multipler Regression. Nachfolgend wird zun¨achst die einfache Methode erl¨ autert, um ein Verst¨andnis f¨ ur die Idee der Regressionsanalyse zu schaffen. Anschließend wird die Methode auf mehrere Variablen erweitert. Der schematische Ablauf einer Regressionsanalyse mit Vor- und Nachbereitung ist in Abbildung 6.2 dargestellt.

6.2.2 Durchf¨ uhrung einer einfachen Regression Eine oft verwendete Sch¨ atzmethode ist die Kleinste-Quadrate-Sch¨atzung [Nie08, S.129 ff.]. F¨ ur eine lineare Funktion wird diese folgendermaßen angewendet. Zun¨achst wird die Funktion allgemein aufgestellt: yˆ = f (ˆ x) = m · x ˆ + n.

(6.9)

Dabei ist yˆ der approximierte Wert und x ˆ sind die Abszissenwerte der tats¨achlichen Messwerte. F¨ ur eine Menge von k Messwerten (xi , yi ) mit i = 1, . . . , k wird nun die Summe der quadrierten Abweichungen der tats¨ achlichen Messwerte y von der Funktion f (ˆ x) wie folgt berechnet: V

=

k X

(yi − yˆi )2 .

(6.10)

i=1

Gesucht ist nun eine Wahl der Parameter m und n, sodass der Gesamtfehler V minimal wird. Dazu wird zun¨ achst Gleichung (6.9) in (6.10) eingesetzt: k X V (m, n) = (yi − m · x ˆi − n)2 .

(6.11)

i=1

Um nun das Minimum bez¨ uglich V (m, n) zu bestimmen, werden weiterhin die partiellen (m,n) (m,n) Ableitungen ∂V ∂n und ∂V ∂m gebildet [BSMM12, S.999 f.]. Man erh¨alt: ∂V (m, n) ∂m ∂V (m, n) ∂n

k X = 2· (yi − m · x ˆi − n) · (−ˆ xi ),

= 2·

i=1 k X

(yi − m · x ˆi − n) · (−1).

(6.12)

(6.13)

i=1

Diese werden nun zur Bestimmung des Minimums Null gesetzt. Es handelt sich hierbei stets um eine Minimum, da gezeigt werden kann, dass die Hesse-Matrix der partiellen Ableitungen

104

6.2 Regressionsanalyse zur Laufzeiterfassung

der 2. Ordnung stets positiv definit ist [Tou02, S.47 ff.]. Man erh¨alt: k X

(ˆ x i yi ) = m ·

i=1

k X

x ˆ2i + n ·

i=1 k X

yi = m ·

i=1

k X

k X

x ˆi ,

(6.14)

i=1

x ˆi + n · k.

(6.15)

i=1

Anschließend wird das gesamte Gleichungssystem durch die Variable k geteilt, was der Ersetzung der Summenformeln durch die entsprechenden Mittelwerte der Datenpaare entspricht: Pk Pk Pk Pk x i yi ) ˆi yi ˆ2i i=1 (ˆ i=1 x i=1 x 2 x ˆi yi = ˆi = ˆi = , x , x , yi = i=1 . k k k k Man erh¨ alt: x ˆ i yi = m · x ˆ2i + n · x ˆi ,

(6.16)

yi = m · x ˆi + n.

(6.17)

Aus diesem System lassen sich anschließend beispielsweise durch Anwendung des Einsetzungsverfahrens die Werte f¨ ur m und n berechnen. Weitere Verfahren zur Bestimmung nichtlinearer Zusammenh¨ange beispielsweise f¨ ur Polynome sind in [Nie08, BSMM12] beschrieben.

6.2.3 Durchf¨ uhrung einer multiplen Regression Die einfache Regression ist ein Spezialfall der multiplen Regression. Im Gegensatz zur einfachen Regression wird die abh¨ angige Variable yˆ aus mehreren unabh¨angigen Variablen x ˆ1 , ..., x ˆq (q ∈ Z, q > 1) gebildet. Somit ergeben sich f¨ ur jede Variable x ˆ1 , ..., x ˆq auch eigene Koeffizienten m1 , ..., mq . Allgemein schreibt man [Nie08, S. 389f.]: yˆ = f (ˆ x1 , . . . , x ˆ q ) = n + m1 · x ˆ 1 + · · · + mq · x ˆq .

(6.18)

Zur Bestimmung der Koeffizienten bietet sich bei der multiplen Regression die Matrixschreibweise an, um alle k Messpunkte darzustellen.

  yˆ1  ..  . = yˆk | {z } Yˆ

    n 1 x ˆ11 . . . x ˆq1 m1   .. .. ..  ·   . .  . .    ..  1 x ˆ1k . . . x ˆqk | {z } mq | {z } ˆ X

(6.19)

m

ˆ ·m u Es muss gelten k >> q. Somit ist das Gleichungssystem Yˆ = X ¨berbestimmt. Ziel ist, wie auch bei der einfachen Regression, die Summe der Fehlerquadrate zu minimieren. Das zu l¨osende Minimierungsproblem lautet demnach:

2

ˆ

(6.20)

X · m − Yˆ → min.

105

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

F¨ ur die Bestimmung des Minimums muss zun¨achst der Gradient dieses Terms bestimmt und Null gesetzt werden. Als Zwischenbemerkung sei erw¨ahnt, dass der Gradient einer Funktion g(x) = ||f (x)||2 f¨ ur beliebiges f : Rn → Rn durch ∇g(x) = 2Df (x)T f (x) gegeben ist [Gr¨ u08, S. 7], wobei Df (x)T die Differentiation von f (x)T darstellt. Mit diesem Hinweis l¨asst sich das Minimierungsproblem Null setzen und wie folgt schreiben: ˆ T Yˆ X

ˆ ˆ T Xm. = X

(6.21)

Der Vektor m l¨ ost das Minimierungsproblem genau dann, wenn die Normalengleichungen in ˆ vollen Spaltenrang besitzt, ist die zweite Ableitung (6.21) erf¨ ullt sind. Da X 

2 

ˆ

ˆTX ˆ = 2X D2 X · m − Yˆ stets positiv definit. Somit liegt als L¨ osung stets ein Minimum vor. Diese Arbeit beschr¨ ankt sich auf die multiple Regression mit genau zwei unabh¨angigen Variablen. R¨ aumlich betrachtet wird also im Gegensatz zur einfachen Regression nicht mehr nach einer Sch¨ atzfunktion in der Ebene, sondern nach einer Sch¨atzfunktion im Raum gesucht. Dabei ist diese Funktion bei g¨ anzlich unabh¨angigen x ˆ1 und x ˆ2 als Ebene beschrieben, bei sich beeinflussenden Variablen kann diese Ebene zus¨atzlich verformt sein. Die Beschaffenheit der Funktion f (ˆ x1 , x ˆ2 ) h¨ angt also auch davon ab, ob sich die unabh¨angigen Variablen gegenseitig beeinflussen. Da dieser Fall im Rahmen der Arbeit vorkommt, kann man ihn ber¨ ucksichtigen, indem man zus¨ atzlich einen Summanden hinzuf¨ ugt, der die Wechselwirkung der Variablen beschreibt. Bei etwa x ˆ1 und x ˆ2 f¨ ugt man den Summand (m12 · x ˆ1 x ˆ2 ) hinzu. F¨ ur den speziellen Fall mit zwei Variablen wird folgende Sch¨atzfunktion aufgestellt:

yˆ = f (ˆ x1 , x ˆ2 ) = n + m1 · x ˆ1 + m2 · x ˆ2 + m12 · xˆ1 xˆ2 .

(6.22)

Zur Bestimmung der Koeffizienten bietet sich bei der multiplen Regression die Matrixschreibweise an, um alle k Messpunkte darzustellen.

  yˆ1  ..  . = yˆk | {z } Yˆ

  n  1 x ˆ11 x ˆ21 (ˆ x11 x ˆ21 ) m1   ..   .. .. ..  . · . . .  m2  1 x ˆ1k x ˆ2k (ˆ x1k x ˆ2k ) | {z } | m{z12 } 

ˆ X

(6.23)

m

Das zu l¨osende Minimierungsproblem wird dann durch nachfolgende Normalengleichungen repr¨asentiert:  

1  x ˆ11   x ˆ21 (ˆ x11 · x ˆ21 ) |

··· ··· ··· ···

   y ˆ1 1   .  x ˆ1k · .    .  x ˆ2k (ˆ x1k · x ˆ2k ) y ˆk {z } ˆT Y ˆ X

=

k    k P   x ˆ1i  i=1   k P  x ˆ2i   i=1  k P (ˆ x1i · x ˆ2i ) i=1

|

k P i=1 k P i=1 k P i=1 k P i=1

k P

x ˆ1i

i=1 k P

x ˆ2 1i

x ˆ1i x ˆ2i

i=1 k P

x ˆ1i x ˆ2i

i=1 k P

x ˆ2 ˆ2i 1i x

i=1

{z ˆT X ˆ X

106

x ˆ2i

x ˆ2 2i

x ˆ1i x ˆ2 2i

k P

 (ˆ x1i · x ˆ2i )   i=1    k P  n x ˆ2 ˆ2i  1i x   m1  i=1  ·   m2  (6.24) k P  x ˆ1i x ˆ2  m 2i 12  i=1  | {z } k  P m (ˆ x1i · x ˆ2i )2 i=1

}

6.2 Regressionsanalyse zur Laufzeiterfassung

Das Gleichungssystem ist immer eindeutig bestimmt und der Koeffizientenvektor m kann durch geeignete Verfahren, beispielsweise Gaußelimination, bestimmt werden. Schließlich kann f¨ ur jeden Koeffizienten aus m bestimmt werden, wie stark er zur Erkl¨arung der Funktion yˆ beitr¨ agt. Dazu wird der t-Wert berechnet [Nie08, S. 398]. Ist dieser sehr klein, so kann die Gr¨ oße auch aus der Vorhersage eliminiert werden, da sie den vorhergesagten Wert eventuell nur sehr wenig verbessert. Die Regression muss ohne diesen Koeffizienten noch einmal durchgef¨ uhrt werden (siehe Abbildung 6.2). Durch das Weglassen vereinfacht sich jedoch eventuell die Sch¨ atzfunktion und die Summe der quadratischen Fehler wird h¨aufig kleiner.

6.2.4 Fehlerbehandlung Als Ergebnis der Approximation weichen einzelne Messpunkte von der Approximationsfunktion ab. Dieser Abstand wird Residuum genannt. Besteht tats¨achlich ein funktionaler Zusammenhang, sollten die Abweichungen einer Normalverteilung folgen. Ob eine Normalverteilung der Fehler vorliegt, l¨ asst sich beispielsweise mit dem X 2 -Test bestimmen [BSMM12, S.848 f.]. Ist dies nicht der Fall, wurde eventuell der falsche Funktionstyp approximiert oder man muss zu dem Schluss kommen, dass kein sinnvoller Zusammenhang zwischen der abh¨angigen und den unabh¨ angigen Variablen hergestellt werden kann. Liegt wenigstens n¨ aherungsweise eine Normalverteilung vor, k¨onnen weitere Metriken die Qualit¨at der Sch¨ atzung charakterisieren. Oft wird das Bestimmtheitsmaß Ω verwendet [Nie08, S.395 ff.]. Es liegt zwischen 0 und 1 und gibt an, wie groß der prozentuale Anteil der YWerte ist, die durch die approximierte Funktion erkl¨art werden. Eine hoher Wert von Ω (> 0, 9) ist also anzustreben. Da sich Ω nur auf die verf¨ ugbaren Messwerte bezieht, sagt es jedoch nichts u ber den Vorhersagecharakter der approximierten Funktion aus. Insbesondere ¨ ¨ f¨ ur Polynome sollte visuell u uft werden, ob nicht eine Uberanpassung stattgefunden ¨berpr¨ hat. Liefert das Bestimmtheitsmaß keinen guten Wert, so m¨ ussen die einzelnen Fehler n¨aher analysiert werden. Aus statistischer Sicht ist relevant, ob alle Messungen den gleichen Fehlerquellen in gleicher Auspr¨agung unterliegen, oder ob es bestimmte Messungen gibt, die Fehler beinhalten k¨onnen, die f¨ ur andere Messungen nicht relevant sind. Ein Problem der Kleinste-Quadrate-Sch¨atzung ist insbesondere die starke Beeinflussung des Ergebnisses durch sogenannte Ausreißer. Als Ausreißer werden Werte bezeichnet, die gegen¨ uber den anderen Werten eine deutliche Abweichung vom restlichen Verhalten der Messpunkte zeigen. In der Statistik wird ein Wert u ¨blicherweise als Ausreißer bezeichnet, wenn er um mehr als das 2,5 fache der Standardabweichung einer Stichprobe vom Erwartungswert, also von der konstruierten Sch¨atzfunktion, abweicht [GB09, S.57 ff.]. Ausreißer entstehen oft durch spezielle Einflussgr¨oßen (beispielsweise durch den Java Classloader, siehe Kapitel 6.4). Vor der Konstruktion der Approximationsfunktion sind die Ausreißer jedoch schwer zu ermitteln, da ein Referenzwert fehlt. Nach der Durchf¨ uhrung einer ersten Regressionsanalyse hingegen k¨onnen Werte, die mit einem großen Fehler behaftet sind, in begr¨ undeten F¨allen ausgefiltert werden. Danach wird die Regressionsanalyse erneut durchgef¨ uhrt. Sind f¨ ur einen X-Wert verschiedene Y-Werte vorhanden, so muss der Mittelwert der Y-Werte benutzt werden. Bei sehr vielen Y-Werten k¨onnen zudem zur Mittelwertbildung ausschließlich Werte aus dem Interquartilsabstand (± 25 % der Anzahl der Werte um den Median) aller dieser Y-Werte benutzt werden. Dadurch wird die Verzerrung des Mittelwerts durch Ausreißer minimiert [GB09, S. 92f.].

107

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Abbildung 6.3: Darstellung der Streuung vorhergesagter fiktiver Tasklaufzeiten einer Appli¨ kation auf je zwei verschiedenen VM-Typen. Der Uberschneidungsbereich der Streuung bei einem Performanceunterschied der VMs von Faktor 4 (zu erkennen an den Mittelwerten der Tasklaufzeiten) f¨ ur verschiedene VQgut ist jeweils rot markiert.

6.2.5 Vorhersagetauglichkeit Fraglich bleibt noch, ab wann eine Approximation unbrauchbar ist und nicht zur Vorhersage verwendet werden kann. Eine Antwort hierauf kann gegeben werden, wenn man beachtet, dass nur diskrete Werte f¨ ur die Geschwindigkeit der VM Ressourcen, also auch f¨ ur die Laufzeit der Tasks, vorliegen. Ziel ist, dass sich die vorhergesagten Laufzeitverteilungen f¨ ur verschiedene VM-Typen unter Beachtung des Vorhersagefehlers m¨oglichst wenig u ¨berschneiden. Eine ¨ Uberschneidung k¨ onnte bedeuten, dass f¨ ur die gleiche Performance auch eine andere, wom¨oglich g¨ unstigere Ressource, h¨ atte gew¨ ahlt werden k¨onnen. Von Bedeutung f¨ ur eine belastbare Laufzeitvorhersage ist also je nach G¨ ute der Streuung um den Mittelwert auch die Wahl der verf¨ ugbaren VM-Typen f¨ ur eine Mobile Cloud-unterst¨ utzte Anwendung. Zur Bewertung der Sch¨ atzung der Ausf¨ uhrungszeit wird das Maß G¨ ute verwendet, das die Abweichung vom Sch¨ atzwert beschreibt. Die G¨ ute Q berechnet sich wie folgt: Q =

Sch¨ atzwert . M esswert

(6.25)

Zudem wird festgelegt, dass eine spezielle G¨ ute Qgut genau dann vorliegt, wenn der Messwert nicht mehr als ± 50 % vom Sch¨ atzwert abweicht. Abbildung 6.3 verdeutlicht die ideal normalverteilte Laufzeitverteilung von unendlich vielen fiktiven Messwerten einer Applikation auf je zwei verschiedenen VM-Typen f¨ ur drei Konfi-

108

6.2 Regressionsanalyse zur Laufzeiterfassung

gurationen. Dabei unterscheiden sich die Mittelwerte der Tasklaufzeiten in der Abbildung um den Faktor 4. Konfiguriert man etwa aus dem Portfolio des Cloud-Anbieters Amazon EC2 die VM-Typen m1.small, c1.medium und c1.xlarge, so unterscheiden sich diese in ihrem Performance-Rating um den Faktor 4–5. Die drei Diagramme visualisieren jeweils eine Streuung zwischen ± 50 % um den Mittelwert (Qgut ). Dabei liegen 95%, 90% oder 80% der Messwerte innerhalb dieses Streuungsbereichs. Dazu wird das Verh¨altnis VQgut definiert:

VQgut

=

|M esswerte mit Qgut | . |M esswerte|

(6.26)

¨ Es ergibt sich jeweils eine leichte Uberschneidung der tats¨achlich auftretenden Werte zwischen den Streuungsbereichen der beiden VM-Typen (zwischen den X-Werten 3–4 und daru ur VQgut = 0, 95 ist die H¨aufigkeit des Auftretens von Messungen in dieser ¨ber hinaus). F¨ ¨ ¨ Uberschneidung sehr gering. Je geringer die Uberschneidung ist, desto weniger wahrscheinlich ist es, dass die andere VM Ergebnisse im gleichen Bereich liefert. Die Wahrscheinlichkeit, den falschen VM-Typ gew¨ ahlt zu haben, ist geringer. Diese Wahrscheinlichkeit nimmt jedoch in den beiden anderen Varianten zu. F¨ ur diese Arbeit wird definiert, dass es gerade noch vertretbar ist, wenn sich bei einem Performanceunterschied der gew¨ahlten Ressourcen von etwa Faktor 4 ca. 80% der tats¨ achlich auftretenden Messwerte innerhalb des ± 50 %-Bereichs um den Mittelwert befinden. Es wird deshalb das G¨ utekriterium KQgut definiert, welches besagt, dass mindestens 80% der Messwerte eine G¨ ute Qgut aufweisen m¨ ussen. Andernfalls gilt KQgut als nicht eingehalten. KQgut

⇔ VQgut ≥ 0, 8.

(6.27)

6.2.6 Toolunterst¨ utzung Um die Performance einer Applikation beziehungsweise einzelner Tasks mittels Regressionsanalyse in einer Sch¨ atzfunktion zu repr¨asentieren, bedarf es Werkzeugunterst¨ utzung in zwei Bereichen. Erstens muss ein Monitoring implementiert werden, welches alle n¨otigen Parameter der Taskausf¨ uhrung aufnehmen kann. Auf Basis dieser Messwerte wird anschließend die Regressionsanalyse durchgef¨ uhrt. Zweitens wird f¨ ur die Regressionsanalyse selbst auch Programmunterst¨ utzung ben¨ otigt, da diese f¨ ur eine große Anzahl von Messwerten nicht mehr h¨andisch durchgef¨ uhrt werden kann. Die zu entwickelnde Middleware auf Serverseite muss demnach f¨ ur jeden Task pk die Gr¨ oße der Eingabedaten ek und die jeweilige Ausf¨ uhrungszeit auf Serverseite ∆twork k erfassen. Dies kann schwierig sein, da die tats¨ achliche Eingabegr¨oße, die als unabh¨angige Gr¨oße f¨ ur die Sch¨atzfunktion identifiziert wurde, f¨ ur jeden Typ pk von Task verschieden sein kann. F¨ ur Bildverarbeitungstasks ist es eventuell die Pixelanzahl, f¨ ur Tonverarbeitung aber eventuell die Samplerate, etc. Somit muss die Middleware ein konfigurierbares Logging bereitstellen. F¨ ur die hier verwendete Regressionsanalyse u ¨ber lineare Regression gibt es viele verschiedene Software-Werkzeuge. Zun¨ achst ist es wichtig, die erhaltenen Messwerte zu visualisieren.

109

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Dazu kann beispielsweise MATLAB 1 oder das freie Werkzeug GNU R 2 verwendet werden. GNU R ist auch in der Lage, verschiedene Kurventypen an die Messwerte anzun¨ahern, und verwendet dazu die Methode der Kleinste-Quadrate-Sch¨atzung [SH07, S. 92]. Zu beachten ist jeweils, dass die Sch¨ atzfunktion auch beschr¨ankt sein kann, beispielsweise d¨ urfen eventuell keine negativen Werte entstehen. Dies ist bei der Spezifikation des Kurventyps anzugeben. Abschließend ist zu pr¨ ufen, ob das geforderte G¨ utekriterium KQgut f¨ ur die approximierte Funktion bez¨ uglich der Messwerte erreicht wird. Da es sich bei diesem Qualit¨atstest um keinen Standardtest handelt, muss die Qualit¨at mit Hilfe eines Tabellenkalkulationsprogramms auf Basis der Messwerte und der Sch¨ atzfunktion selbst berechnet werden.

6.2.7 Zusammenfassung Regressionsanalyse F¨ ur eine Regressionsanalyse sollte zun¨achst analysiert werden, von welchen Variablen die Laufzeit der Tasks der Mobilen Cloud-unterst¨ utzten Anwendung abh¨angt. Bez¨ uglich der Qualit¨at der Messdaten muss eine große Menge und eine m¨oglichst große Spannweite an Messdaten vorliegen. Erkl¨ arbare Ausreißer sollten ausgefiltert werden. F¨ ur jeden VM-Typ muss eine separate Regressionsanalyse durchgef¨ uhrt werden. Nach der Regressionsanalyse muss das Ergebnis auf jedem VM-Typ das G¨ utekriterium KQgut erf¨ ullen. Die Analyse kann mit Hilfe verschiedener verf¨ ugbarer Tools durchgef¨ uhrt werden, die zudem auch wichtige Parameter der Regression automatisch bestimmen. Im nachfolgenden Abschnitt wird untersucht, welche Performanceschwankungen durch die Middleware selbst und durch Applikationen zu erwarten sind.

6.3 Cloud-Performance Modellierung und Bewertung Cloud-Ressourcen eines IaaS-Anbieters sind virtuelle Maschinen und diese unterscheiden sich, wie auch dedizierte Server, im Allgemeinen in: (siehe Anhang B) • der Geschwindigkeit der einzelnen CPU-Kerne, • der Anzahl der einzelnen CPU-Kerne, • der Gr¨ oße des verf¨ ugbaren Hauptspeichers, • und in den daf¨ ur verlangten Kosten pro Zeiteinheit. 1

MATLAB ist eine h¨ ohere Programmiersprache und interaktive Umgebung f¨ ur numerische Berechnungen, ” Visualisierung und Programmierung. MATLAB dient zur Datenanalyse, Algorithmen-Entwicklung und zur Erstellung von Modellen und Anwendungen. Mit der Programmiersprache, den Tools und den integrierten mathematischen Funktionen k¨ onnen Sie verschiedene Ans¨ atze ausprobieren und schneller zu einer L¨ osung gelangen als mit Tabellenkalkulationen oder herk¨ ommlichen Programmiersprachen wie C/C++ oder Java.“ (Onlineressource http://www.mathworks.de/products/MATLAB/ (abgerufen am 12.9.2013)) 2 R ist eine freie Programmiersprache f¨ ur statistisches Rechnen und statistische Grafiken. Sie ist in An” lehnung an die Programmiersprache S entstanden und weitgehend mit dieser kompatibel. Außerdem orientierten sich die Entwickler an der Programmiersprache Scheme. R ist Teil des GNU-Projekts und auf vielen Plattformen verf¨ ugbar. [...] R wurde 1992 von Ross Ihaka und Robert Gentleman an der Universit¨ at Auckland entwickelt. [...] 1993 wurde die Software erstmals ¨ offentlich vorgestellt, seit Juni 1995 steht R unter der GNU General Public License. “ (Onlineressource http://de.wikipedia.org/wiki/R_ (Programmiersprache)(abgerufen am 30.10.2013))

110

6.3 Cloud-Performance Modellierung und Bewertung

Auf diesen virtuellen Maschinen k¨onnen verschiedene Betriebssysteme gestartet werden. Nicht von jedem IaaS-Anbieter wird das Starten beliebiger Betriebssysteme unterst¨ utzt. Weiterhin ist das Benutzen verschiedener Betriebssysteme verschieden teuer. Beispielsweise wird durch Amazon EC2 f¨ ur Windows-Instanzen etwas mehr berechnet als f¨ ur Linux-Instanzen. F¨ ur die f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen ben¨otigte Java-Umgebung sind jedoch schlicht konfigurierte Linux-Instanzen ausreichend, was sp¨ater in Kapitel 7.1 zur Implementierung noch n¨ aher erl¨ autert wird. In den nachfolgenden Abschnitten werden die besonderen Eigenschaften bei der Performancemodellierung virtualisierter Maschinen untersucht.

6.3.1 Performance-Rating Um die Berechnungsperformance ihrer Angebote zu kategorisieren, verwenden IaaS-Anbieter oft ein Performance-Rating. Dabei wird h¨aufig nur die Anzahl der CPU-Kerne und deren Geschwindigkeitsbewertung (oft als Rating bezeichnet) multipliziert und um einen Faktor erg¨anzt. Anhand dieser Angabe werden im Allgemeinen die Kosten f¨ ur die Abrechnung der Nutzungsdauer berechnet. Amazon EC2 etwa stellt ein ECU-Rating3 zur Verf¨ ugung (siehe Anhang B). Dieses Rating kann jedoch tr¨ ugerisch sein und reflektiert nicht notwendigerweise die tats¨ achliche Performanceeinordnung verschiedener VM-Typen zueinander. Aus Amdahls Gesetz l¨ asst sich ableiten, dass der parallele Speedup de facto niemals 100 % betragen kann [RR00, S.313], da ein Programm in der Praxis immer auch eine geringen Anteil sequentiell auszuf¨ uhrender Instruktionen umfasst, die sich nicht parallelisieren lassen. Ein ECURating von 2 kann auf einem Dual-Core System gebildet werden aus 2 ECU = 2 · 1 GHz und auf einem Single-Core System aus 2 ECU = 1 · 2 GHz. Nur ein paralleles Programm, welches einen parallelen Speedup von 100% aufweist, w¨ urde auf beiden Konfigurationen tats¨achlich die gleiche Performance erzielen. Das Performance-Rating ist demnach nur bedingt geeignet, um die Performance einer Ressource zu beschreiben. Eine andere M¨ oglichkeit, die Performance zu beschreiben, ist die Einteilung der verf¨ ugbaren Ressourcen in Gruppen, die jeweils die gleiche Einzelprozessor-Performance aufweisen. Da viele berechnungsintensive Programme recht proportional mit der CPU-Kernfrequenz des Prozessors skalieren, ist die Performance der Gruppeneinteilung wenigstens f¨ ur EinzelprozessorAnwendungen vergleichbar. Einige von Amazon EC2 angebotenen VM-Typen sind beispielsweise in den folgenden Konfigurationen verf¨ ugbar: 2 ECU pro CPU-Kern (m1.small,m1.large,m1.xlarge) 2,5 ECU pro CPU-Kern (c1.medium,c1.xlarge) 3,25 ECU pro CPU-Kern (m2.xlarge,m2.2xlarge,m2.4xlarge) 3

Amazon EC2 setzt verschiedene Maßnahmen ein, um jede Instance mit einer gleichbleibenden und vorher” sehbaren Menge an CPU-Kapazit¨ at zu versorgen. Um den Entwicklern den Vergleich zwischen den CPUKapazit¨ aten der verschiedenen Instance-Typen zu erleichtern, haben wir eine Amazon EC2 Compute Unit definiert. Die einer bestimmten Instance zugewiesene CPU-Menge wird in diesen EC2 Compute Units ausgedr¨ uckt. Um die Konsistenz und Vorhersehbarkeit der Leistung einer EC2 Compute Unit zu verwalten, werden verschiedene Benchmarks und Tests eingesetzt. Eine EC2 Compute Unit bietet die entsprechende CPU-Kapazit¨ at eines 1,0- bis 1,2 GHz-Opteron oder -Xeon Prozessors von 2007. Dies entspricht außerdem einem 1,7-GHz-Xeon-Prozessor von Anfang 2006, auf den in unserer Originaldokumentation verwiesen wird. Mit der Zeit werden wir m¨ oglicherweise weitere Gr¨ oßenwerte zur Definition einer EC2 Compute Unit hinzuf¨ ugen oder ersetzen, sofern Kennzahlen gefunden werden, die Ihnen die Rechenkapazit¨ at besser verdeutlichen.“ (Onlineressource http://aws.amazon.com/de/ec2/faqs/ (abgerufen am 6.9.2013))

111

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Innerhalb der Gruppen gibt es dann Ressourcen mit verschieden vielen CPU-Kernen. Man kann also je nach parallelem Speedup der Applikation eine weitere Beschleunigung erreichen. Zusammenfassend wird festgehalten, dass das Performance-Rating im Allgemeinen nicht verwendet werden kann, um die Applikationsperformance auf einer Ressource vorherzusagen. Somit muss f¨ ur jeden VM-Typ die Applikationsperformance f¨ ur verschiedene Eingaben separat bestimmt werden. Nur f¨ ur Einzelprozessorapplikationen k¨onnen eventuell Vereinfachungen ausgenutzt werden. Bisher wurde stets davon ausgegangen, dass die Verarbeitungsgeschwindigkeit f¨ ur identisch konfigurierte VM-Instanzen, wie bei physikalischen Servern, ann¨ahernd gleich hoch ist. Ob diese Annahme tats¨achlich auch f¨ ur virtualisierte Server getroffen werden kann, wird in Kapitel 6.3.3 untersucht.

6.3.2 Speicheranforderungen Die Menge des von einer Applikation verwendeten Hauptspeichers h¨angt unter anderem von dem verwendeten Algorithmus und der Beschaffenheit der Eingabedaten ab und l¨asst sich im Allgemeinen schwierig bestimmen [BFGY08]. Dies gilt insbesondere f¨ ur Java-Anwendungen, die keine explizite Speicherverwaltung erm¨oglichen, da das Laufzeitsystem diese u ¨bernimmt. Hier haben auch Einstellparameter des Laufzeitsystems Einfluss auf den Speicherbedarf. Dennoch ist der Speicherbedarf eine wichtige Gr¨oße. Bei der Auswahl eines VM-Typs mit zu wenig Speicher kann eine Applikation nicht mehr ausgef¨ uhrt werden und bricht ab. Im Gegensatz dazu beeinflusst die Auswahl von zu viel Speicher die Ausf¨ uhrungszeit im Allgemeinen kaum positiv. Bez¨ uglich der Speicherkonfiguration einer Ressource muss somit nur darauf geachtet werden, dass ausreichend Hauptspeicher vorhanden ist. Somit muss die Maximalmenge von ben¨otigtem Hauptspeicher f¨ ur jede Applikation a priori ermittelt werden. Aufgrund dieser Sch¨atzung k¨onnen anschließend nur VM-Typen f¨ ur die Nutzung konfiguriert werden, die die gew¨ unschte Menge an Speicher auch bereitstellen. Sind also beispielsweise mindestens 2 GB Hauptspeicher gefordert, so k¨onnen die Instanztypen m1.small, c1.medium und t1.micro vom Amazon EC2 nicht konfiguriert werden, da diese weniger Hauptspeicher zur Verf¨ ugung haben (siehe Anhang Tabelle B.3). Java bietet zur Erfassung des momentan verwendeten Arbeitsspeichers sowie des verf¨ ugbaren Speichers eingebaute Methoden. Die Informationen lassen sich im Programm selbst durch entsprechende Java-API-Aufrufe beschaffen. Zudem gibt es grafische Werkzeuge, die Laufzeitinformationen von Java-Programmen darstellen k¨onnen. Hierbei sind die Werkzeuge VisualVM4 und JConsole5 hervorzuheben, da sie Bestandteil der Java-Installation sind. Durch die Middleware ist sichergestellt, dass auf jeder VM nur eine Serverinstanz und demzufolge auch nur eine JVM ausgef¨ uhrt wird. Diese erh¨alt den u ugbaren ¨berwiegenden Teil des verf¨ Arbeitsspeichers zugewiesen.

6.3.3 Volatilit¨ at der Performance virtueller Maschinen An dieser Stelle wird untersucht, welche Auswirkungen durch den virtualisierten Softwarestack auf die Schwankung der Performance von VMs zu erwarten sind. Der f¨ ur die Midd4

VisualVM ist Bestandteil der Oracle Java-Installation. Das Programm bietet Profiling und Monitoring f¨ ur Entwicklungs- und Produktionsumgebungen an. Das Programm ist Open Source und kann durch Plugins erweitert werden. (siehe [Ull12]) 5 JConsole ist Teil des Java Development Kits (JDK). Es bietet die M¨ oglichkeit, Statusinformationen von lokal und entfernt ausgef¨ uhrten Programmen anzuzeigen. (siehe [Ull12])

112

6.3 Cloud-Performance Modellierung und Bewertung

Beispielimplementierung für Amazon EC2

Java 7 Bytecode

virtualisierter Softwarestack

Java Bytecode JRE Systembibliothek

OpenJDK 64-Bit Server VM

JVM

Amazon Linux AMI 64-bit

VM Gast OS

XEN-basierte Virtualisierung

Host OS

Intel Xeon E5410-basierter Server

Hardware (Host)

Abbildung 6.4: Softwarestack f¨ ur Java-Programme, die in einer virtuellen Maschine ausgef¨ uhrt werden. Zus¨ atzlich ist eine konkrete Instantiierung des Stacks f¨ ur den Cloud-Anbieter Amazon EC2 und die in dieser Arbeit verwendete JavaImplementierung OpenJDK angegeben. leware relevante Softwarestack ist in Abbildung 6.4 visualisiert. Dabei wird Virtualisierung auf mehreren Schichten eingesetzt. Die Cloud-Ressource selbst ist eine virtuelle Maschine, welche als Gast auf einem physikalischen Host neben weiteren virtuellen Maschinen residiert. Der Applikationscode wird wiederum nicht direkt, sondern von einer JVM ausgef¨ uhrt. Dazu liegt Java-Code als Bytecode vor. Beide Formen der Virtualisierung haben unterschiedlichen Einfluss auf die Performance von Anwendungen, die auf diesem Softwarestack implementiert werden. Um den Einfluss der Virtualisierung auf die Konstanz der Applikationsperformance auf dem verwendeten Softwarestack zu bestimmen, wird nachfolgend anhand von Literatur und eigenen Messungen eine Analyse durchgef¨ uhrt. IaaS-Ressourcen Im Vergleich zu einem dedizierten, nichtvirtualisierten Server ist es u ¨blich, dass mehrere V M s parallel zueinander auf einem physikalischen Host ausgef¨ uhrt werden. Dies kann im Vergleich zu nichtvirtualisierten Servern dazu f¨ uhren, dass die VM-Performance nicht zu jedem Zeitpunkt konstant hoch ist. Als Grund f¨ ur eine solche Schwankung kann beispielsweise angef¨ uhrt werden, dass sich alle auf dem gleichen Host ausgef¨ uhrten VMs die verf¨ ugbare Hauptspeicherbandbreite teilen. Bei gleichzeitiger Nutzung des Hauptspeichers durch mehrere VMs kann es zu Engp¨ assen kommen, die die Ausf¨ uhrungsgeschwindigkeit einer Applikation beeinflussen k¨onnen. Weiterhin ist es m¨ oglich, dass man bei mehrfachen Anforderungen eines gewissen VM-Types vom IaaS-Anbieter jeweils Maschinen mit verschiedener darunter liegender Hardware (beispielsweise Prozessortypen der Hersteller Intel oder AMD, siehe Tabelle 6.2) erh¨alt. Dies kann die Applikationsperformance ebenfalls beeinflussen, da sich die Architekturen in Speicher/Cache-Hierarchie oder dem Aufbau der CPU unterscheiden (beispielsweise Anzahl der ALU/FPU Einheiten). Derlei Geschwindigkeitsvolatilit¨at l¨asst sich nicht verhindern und sollte im Applikationsentwurf ber¨ ucksichtigt werden. Eine umfangreiche Analyse der Ausf¨ uhrungsgeschwindigkeit von Cloud-Ressourcen ist in einschl¨agiger Literatur zu finden. In [LML+ 11, LYKZ10, IOY+ 11, IYE11] werden einige Anbieter von IaaS-Diensten verglichen.

113

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Tabelle 6.2: Auswertung von Benchmarks auf Cloud-Ressourcen M¨ ogliche CPU-Typen von VM-Instanzen und H¨ aufigkeitsangaben CPU Typ AMD Opteron 2374 HE Intel Xeon E5430 Intel Xeon E5410 Intel Xeon E5345 AMD Opteron 2218 HE

EC2 Small

EC2 Medium

EC2 Large

67,10% 32,90%

87,50% 12,50% -

0,54% 99,46% -

Schwankungsbreite von Benchmarkl¨ aufen auf VM-Typen Anzahl Messwerte Ø Variationskoeffizient

462 7,70%

72 4,00%

186 11,60%

Quelle:[LML+ 11]

In [LML+ 11] werden Benchmarks mehrfach auf verschiedenen Ressourcen von Amazon EC2 durchgef¨ uhrt und dabei die Schwankungen gemessen. Dabei wurden 11 Programme aus verschiedensten Bereichen als Benchmarks benutzt. Tabelle 6.2 fasst die Ergebnisse der Messungen bez¨ uglich Schwankungsbreite f¨ ur die drei benutzten Amazon EC2 -Instanztypen zusammen. Die exakten Instanztypen wurden nicht genannt. Verglichen mit den Eigenschaften der verf¨ ugbaren Instanztypen (siehe Anhang Tabelle B.3), entsprechen sie jedoch wahrscheinlich den Typen m1.small, m1.medium und m1.large. Die absolute Performance der Instanztypen ist hier auch nicht von besonderer Bedeutung, da zun¨achst nur ein Eindruck bez¨ uglich der Stabilit¨at der Performance gewonnen werden soll. Der Variationskoeffizient liegt bei maximal 11,6 %. Das bedeutet bei einer angenommenen Normalverteilung der Messergebnisse, dass ca. 68,3 % der Messergebnisse um maximal 11,6 % vom Mittelwert abweichen. In [LML+ 11] wurden keine Vergleichsergebnisse f¨ ur nichtvirtualisierte Server angegeben. Absolut gesehen ist die Abweichung f¨ ur exakt gleichartige Benchmarks zwar hoch, jedoch nicht unbrauchbar hoch. Daraus kann abgeleitet werden, dass ein Fehler bei der Vorhersage der Performance einer Applikation zu einem geringen Teil auch durch die Schwankung der VM-Performance verursacht werden kann. Es kann jedoch davon ausgegangen werden, dass sich diese im unteren zweistelligen Bereich bewegt. In [IYE11] wurde eine Langzeitstudie u ¨ber ein Jahr auf der Amazon EC2 und Google AppEngine Infrastruktur durchgef¨ uhrt. Haupts¨achlich wurde die Schwankung der Performance f¨ ur Datenbankanfragen und Speicherdienste u ¨berwacht. Als Ergebnis wurde festgestellt, dass es Perioden stabiler Performance, aber auch monatliche und t¨agliche deutliche Schwankungen gibt. In [IOY+ 11] werden verschiedene Cloud-Anbieter bez¨ uglich der Performance ihrer Ressourcen miteinander verglichen. Das liefert nur bedingt Aussagen u ¨ber die Variabilit¨at der Performance, zeigt aber, dass auch andere Cloud-Anbieter ¨ahnlich performante Angebote wie Amazon EC2 zur Verf¨ ugung stellen. Zus¨atzlich wurde explizit die Performanceschwankung einer Instanz des Typs m1.xlarge untersucht. Genaue Zahlen sind nicht beschrieben, jedoch l¨asst sich aus dem abgebildeten Diagramm erkennen, dass die Gesamtschwankungsbreite bei ca. ± 20 % liegt. Dies ist im Gegensatz zu den anderen getesteten IaaS-Anbietern GoGrid , Elastic Hosts und Mosso ein sehr geringer Wert. In [LYKZ10] werden Metriken vorgestellt, die dazu geeignet sind, die Performance verschie-

114

6.3 Cloud-Performance Modellierung und Bewertung

dener Angebote von Cloud-Ressourcen miteinander zu vergleichen. Obwohl versucht wurde zu anonymisieren, konnten die Angebote von Amazon EC2 identifiziert werden. Auch die Schwankungsbreite wurde angegeben. Es wurde außerdem auch zwischen CPU-, Speicherund Disk-I/O-intensiven Applikationen unterschieden. Dabei wurde deutlich, dass die maximale Schwankungsbreite bei CPU-intensiven Applikationen gering ist (einstelliger Prozentbereich), bei Speicher-intensiven Applikationen h¨oher ist (unterer zweistelliger Prozentbereich) und bei Disk-I/O-intensiven Applikationen sehr hoch ist (bis in den dreistelligen Prozentbereich). Die untersuchten Anbieter Amazon AWS , Microsoft Azure, Google AppEngine und Rackspace CloudServers lieferten bez¨ uglich Schwankungsbreite ¨ahnliche Ergebnisse, einzig bei Disk-I/O-intensiven Applikationen schnitt Amazon AWS besonders schlecht ab. Im Gesamteindruck liefern die Instanztypen von Amazon EC2 die stabilste Performance f¨ ur CPU-intensive Applikationen. Dennoch muss davon ausgegangen werden, dass die Performance von berechnungsintensiven Applikationen im unteren zweistelligen Prozentbereich um einen Mittelwert schwankt. Dies liegt jedoch weit unterhalb der geforderten maximalen Schwankung von ca. 50% f¨ ur mindestens 80% der Messwerte und ist somit tolerierbar. Da f¨ ur speicherintensive und I/O-intensive Applikationen noch weit h¨ohere Schwankungen zu erwarten sind, kann f¨ ur diese Anwendungen keine sinnvolle Prognose der Verarbeitungsgeschwindigkeit erstellt werden. Auch f¨ ur berechnungsintensive Applikationen sollte die Prognose stets angepasst werden, da sich die Host-Hardware ¨andern kann oder es zu dauerhaften Ver¨ anderungen durch beispielsweise ge¨ andertes Scheduling von VM-Instanzen im Rechenzentrum kommen kann. Java Virtual Machine – JVM Bei Java handelt es sich um eine interpretierte Sprache, bei der der Java-Quellcode in einem Vorkompilierungsschritt zun¨ achst in einen Bytecode u ¨bersetzt wird, der dann durch eine JVM ausgef¨ uhrt wird. F¨ ur Java gilt zun¨achst die Vermutung, dass verschiedene JVMImplementierungen nicht die gleiche Applikationsperformance liefern. Zudem haben weitere Java-spezifische Eigenschaften wie Garbage Collection Einfluss auf die Performance. Dies h¨angt unter anderem von der verwendeten Konfiguration der JVM ab. Die Java-Sprachspezifikation [GJS+ 13], wie auch die Spezifikation des Bytecode und der JVM-API [LYBB13], sind ¨offentlich verf¨ ugbar. Es ist jedem gestattet, eine kompatible JVM6 zu entwickeln, die Bytecode ausf¨ uhren kann. Somit gibt es am Markt verschiedene JVM-Implementierungen f¨ ur unterschiedliche Zwecke. Ein ausf¨ uhrlicher Vergleich verschiedener JVM-Implementierungen ist in [Fri12] zu finden. Aufgrund der sich schnell entwickelnden JVMs verschiedener Hersteller ist das Vergleichen verschiedener JVMs bez¨ uglich der Performance nur schlecht m¨oglich. In der n¨achsten Version der JVM k¨ onnte sich die Geschwindigkeit bereits schon ver¨andert haben. Seit 2011 bildet Java 7 das aktuelle Ende der Entwicklung des Java-Softwaresystems. Die Ver¨offentlichung der n¨achsten Java-Entwicklungsstufe, Java 8 , ist f¨ ur 2014 geplant. Zudem findet im Moment eine Bereinigung des Marktes statt. Einige Hersteller haben die Entwicklung eigener JVMs aufgegeben und beteiligen sich stattdessen im OpenJDK -Projekt7 an der Entwicklung 6

JVM ist dabei ein gesch¨ utztes Label, welches von Oracle gepr¨ uft wird, bevor eine Virtuelle Maschine f¨ ur Java als JVM bezeichnet werden darf. Nicht zertifizierte Implementierungen werden als Research Virtual Machine (RVM) bezeichnet. (siehe [Fri12]) 7 Das OpenJDK ist ein Projekt, welches vom damaligen Java-Eigent¨ umer Sun Microsystems 2006 geschaffen wurde, um den Quellcode der Sun-Implemetierung von Java einer breiten Gemeinschaft zu u ¨bergeben und fortan durch diese weiterzuentwickeln. Nachdem Sun Microsystems durch Oracle u ¨bernommen wurde,

115

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Tabelle 6.3: Performancevergleich verschiedener JVM (64-bit) Benchmark SciMark

Leistungsunterschied 3,30%1

verglichene JVMs

System

Oracle HotSpot(TM) 1.7.0 17 / 2x Intel Xeon E5-2643 @3.3GHz OpenJDK 1.7.0 6 (Linux 3.2.0 64-bit) DaCapo 0,70% Oracle HotSpot(TM) 1.7.0 25 / Dell Latitude 6530 (siehe AnOpenJDK 1.7.0 25 hang A) SciMark 0,20% Oracle HotSpot(TM) 1.7.0 25 / Dell Latitude 6530 (siehe AnOpenJDK 1.7.0 25 hang A) 1 = Quelle:http://dior.ics.muni.cz/~makub/java/speed.html (abgerufen am 02.09.2013)

einer gemeinsamen Open Source JVM. Das OpenJDK umfasst seinerseits wiederum den von Oracle freigegeben Quellcode der Oracle HotSpot JVM mit einigen Einschr¨ankungen. Da f¨ ur GNU/Linux-Derivate nur freie Software verwendet werden darf, wurde das IcedTea-Projekt gegr¨ undet, welches als Ziel hat, die Einschr¨ankungen der OpenJDK -Quellen durch freie Software zu komplettieren. Dadurch steht nun f¨ ur nahezu alle Linux-Systeme eine OpenJDK Java-Laufzeitumgebung unter Verwendung der IcedTea JVM zur Verf¨ ugung. Somit ist f¨ ur die beiden sehr h¨ aufig verwendeten JVM-Implementierungen Oracle HotSpot JVM und die OpenJDK IcedTea-Implementierung kaum ein Performanceunterschied zu erwarten. Nachfolgend werden nur diese Implementierungen f¨ ur Java SE 7 verglichen. F¨ ur Performancevergleiche sind einschl¨ agige Benchmark-Anwendungen f¨ ur Java verf¨ ugbar. Oft verwendet wird beispielsweise der DaCapo Benchmark [BGH+ 06]. Darin werden eine Reihe verschiedenster Java-Anwendungen aus unterschiedlichen Bereichen verwendet. Ein weiterer Benchmark ist der SciMark 2.0 Benchmark8 , welcher die Geschwindigkeit numerischer Berechnungen als Einzelprozessoranwendung bestimmt. Tabelle 6.3 fasst eigene und fremde Ergebnisse einiger Benchmarkl¨ aufe zusammen. Aus den Benchmarkergebnissen ist abzulesen, dass sich die Verarbeitungsgeschwindigkeiten der beiden betrachteten JVM Implementierungen nur im Rahmen der Abweichung durch allgemeine Messtoleranz unterscheiden und kein deutlicher Unterschied zu erkennen ist. Dies bedeutet, dass die Wahl der JVM keinen deutlichen Einfluss auf die Schwankung der Verarbeitungsgeschwindigkeit hat. Obwohl im Folgenden aufgrund der breiteren und einfacheren Unterst¨ utzung der OpenJDK JVM ausschließlich diese verwendet wird, sollten alle weiteren Messergebnisse mit sehr geringen Abweichungen auch f¨ ur die Oracle JVM g¨ ultig sein. Da im Moment kaum weitere relevante Java-Implementierungen neben der Oracle- und der OpenJDK -Implementierung existieren, werden performancerelevante Einfl¨ usse aufgrund verschiedener JVM-Implementierungen nicht weiter betrachtet. Weitere Java-spezifische performancerelevante Eigenschaften, wie Garbage Collection oder Just-in-Time Compiler, werden sp¨ater in Kapitel 6.4 anhand der OpenJDK -Implementierung genauer untersucht.

wurde dieser Prozess fortgesetzt, sodass Oracle auch heute noch großen Anteil an diesem Open SourceProjekt hat. Heute stellt das OpenJDK die Referenzimplementierung von Java dar. (siehe [Fri12]) 8 Verf¨ ugbar unter Onlineressource http://math.nist.gov/scimark2 (Abgerufen am 20.3.2014)

116

6.4 Java-spezifische Einflussparameter auf die Ausf¨ uhrungsperformance

Abbildung 6.5: Ausf¨ uhrungszeiten einer Sequenz von gleichen Tasks innerhalb einer JVMInstanz auf einem nichtvirtualisierten System. Einzelne Tasklaufzeiten weichen von der Mehrheit deutlich nach oben ab.

6.4 Java-spezifische Einflussparameter auf die Ausf¨ uhrungsperformance Die Ausf¨ uhrungszeit eines Java-Programms wird durch verschiedene Java-spezifische Eigenarten des Java-Laufzeitsystems beeinflusst. Drei bedeutsame Eigenarten werden nachfolgend genauer betrachtet, der Classloader zum Laden der Bytecodedateien, der Just-In-Time Compiler zur laufzeitm¨ aßigen Codeoptimierung und der Garbage Collector zur Freigabe nicht ben¨otigten Arbeitsspeichers. Diese Einfl¨ usse k¨onnen vom Programmierer oft nur bedingt beeinflusst werden. Sie f¨ uhren jedoch in Bezug auf die Regressionsanalyse und die Bestimmung der Laufzeit eines Java-Programms zu Schwankungen und Ausreißern in den Messwerten. Abbildung 6.5 zeigt dazu die Laufzeiten einiger gleichartiger sequentiell ausgef¨ uhrter Tasks innerhalb der gleichen JVM, die die gleiche oder nur eine leicht verschiedene Eingabe verarbeitet haben. Es wurden Tasks der Kantenerkennung genutzt, die in Kapitel 8.3 vorgestellt wird. Somit ist pk konstant und ek schwankt nur sehr wenig. Als Ausf¨ uhrungsplattform wurde hier der Dell Latitude Laptop genutzt (siehe Anhang A). Deutlich sichtbar ist, dass einige Laufzeiten deutlich von der Mehrheit abweichen. Diese Effekte werden nachfolgend erkl¨art.

6.4.1 Classloader In Java werden Klassen erst dann geladen, wenn sie im Programmlauf gebraucht werden. Dazu ist jede Klasse in einer eigenen Datei gespeichert. Das Laden der Klassen u ¨bernimmt ein sogenannter Classloader. Im Ergebnis kommt es durch diese Implementierung des Ladens von Klassen zu einer Verz¨ ogerung beim ersten Verwenden eines Objektes der Klasse, da zun¨achst die entsprechende Klassendatei von der Festplatte geladen und gelesen werden muss. Je nach Umfang der Klasse kann dieser Vorgang einige Millisekunden dauern. Als Verwendung z¨ahlt hier schon der Import der Klasse zu Beginn einer Klassendeklaration. Ist die Klassendatei einmal geladen, steht sie bei der n¨ achsten Verwendung aus dem Klassencache zur Verf¨ ugung und es fallen nur noch minimale Kosten f¨ ur das Laden an. Dieses Verhalten ist in Abbildung 6.5 f¨ ur Task 0 deutlich sichtbar. Da dieser Aufschlag auf

117

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

die Verarbeitungszeit nur bei diesem ersten Task zu erwarten ist, sollte man diese Laufzeit f¨ ur die Konstruktion der Laufzeitfunktion ratemulti (. . . ) ausfiltern, da sie dazu f¨ uhren k¨onnte, dass die Laufzeit der restlichen Tasks deutlich mit einem Fehler behaftet w¨ urde. Die ebenfalls hohe Ausf¨ uhrungszeit der folgenden drei Tasks ist nicht durch den Classloader zu erkl¨aren, sondern durch den sp¨ ater noch vorgestellten JIT-Compiler.

6.4.2 Garbage Collection In Java werden dynamisch allokierte Variablen, die durch den new-Operator erzeugt werden, auf dem Heap-Speicher abgelegt. Der Speicherbereich dieser Variablen muss im Gegensatz zu statischen Variablen, die auf dem Programmstack abgelegt werden, explizit wieder freigegeben werden. In Java fehlt jedoch eine solche M¨oglichkeit der expliziten Freigabe. Solche Speicherbereiche werden durch das Java-Laufzeitsystem u ¨berwacht und automatisch freigegeben, wenn sie nicht mehr ben¨ otigt werden. Der Vorgang des automatischen Freigebens wird als Garbage Collection (GC) bezeichnet.Garbage Collection beeinflusst die Laufzeit eines Programms, da das Freigeben der Speicherbereiche je nach Anzahl und Art der Verwendung Programmlaufzeit und Arbeitsspeicher in Anspruch nimmt. Da Garbage Collection nicht Teil der Java Language Specification ist, implementiert jede Java-Laufzeitumgebung eventuell verschiedene Verfahren. Deshalb soll in diesem Abschnitt nur auf problematische Konstellationen bei der Speicherbereinigung eingegangen werden. Es wird kurz beschrieben, welche M¨ oglichkeiten der Garbage Collection es gibt, um diese Konstellationen bestm¨ oglich zu verarbeiten, und wie sich diese auf die Programmlaufzeit auswirken. F¨ ur weiterf¨ uhrende Informationen sei auf [Nag09, Fri12] verwiesen. Grundlegend muss f¨ ur den Vorgang der Speicherbereinigung zun¨achst f¨ ur jedes Objekt bestimmt werden, ob es noch erreichbar ist. Dazu muss es im Programm mindestens noch eine g¨ ultige Referenz auf das Objekt geben. Auch alle von einem erreichbaren Objekt erreichbaren weiteren Objekte sind erreichbar, jedoch eventuell nur indirekt. Um die Erreichbarkeit festzustellen, m¨ ussen alle Referenzen gez¨ahlt werden. Dieser Z¨ahlvorgang, genannt Reference Counting, kann zur Laufzeit simultan stattfinden und verteilt sich somit gleichm¨aßig u ¨ber die gesamte Programmlaufzeit, jedoch werden durch diese Variante nicht alle nicht mehr erreichbaren Objekte identifiziert. Zus¨ atzlich muss demnach von Zeit zu Zeit das Programm angehalten werden, um die Referenzen f¨ ur alle Objekte explizit zu bestimmen (Mark and Sweep). Nicht mehr erreichbare Speicherbereiche werden dann wieder freigegeben. Wie bei kompiliertem Programmcode auch, treten beim Speichermanagement in Java verschiedene Probleme auf, von denen zwei nachfolgend etwas n¨aher betrachtet werden. Viele kurzlebige Objekte implizieren auch das h¨aufige Ausf¨ uhren des Garbage Collectors. Dabei kann es zur Speicherfragmentierung kommen, die im Falle einer neuen Speicheranforderung dann dazu f¨ uhrt, dass kein zusammenh¨angender Speicherbereich f¨ ur die Anfrage mehr gefunden werden kann, obwohl insgesamt gen¨ ugend freier Speicher vorhanden w¨ are. Dieses Problem kann nur dadurch gel¨ost werden, dass nach der Ausf¨ uhrung des Garbage Collectors zus¨atzlich noch die u ¨brigen Speicherbereiche zusammenkopiert (defragmentiert) werden, sodass wieder große freie L¨ ucken enstehen, die f¨ ur neue Speicheranforderungen genutzt werden k¨onnen. Entsprechend sind die Varianten Mark and Compact und Stop and Copy des Garbage Collectors vorhanden. Dieses h¨aufige Zusammenkopieren kostet jedoch Zeit und kann in vielen F¨allen vermieden werden, wie nachfolgend beschrieben wird.

118

6.4 Java-spezifische Einflussparameter auf die Ausf¨ uhrungsperformance

300 250

160 Tasklänge 9−331ms Normalverteilung

140

Tasklänge 126−4880ms Normalverteilung

Anzahl Tasks

Anzahl Tasks

120 200 150 100

100 80 60 40

50 0 −100

20 −50 0 50 Approximationsfehler in ms

100

0 −2000 −1500 −1000 −500 0 500 1000 1500 2000 Approximationsfehler in ms

Abbildung 6.6: H¨ aufigkeitsverteilung der Abweichung der Laufzeit einzelner Tasks der Kantenerkennung vom approximierten Wert. Links: geringe Bildaufl¨osung, kurze Tasklaufzeiten Rechts: hohe Bildaufl¨osung, l¨angere Tasklaufzeiten Objekte mit sehr unterschiedlicher Lebensdauer sind oftmals in einem Programmlauf gleichzeitig anzutreffen. Diese Tatsache kann man ausnutzen, indem man ein generationelles Speichermanagement implementiert. Dabei wird der Heap in einen jungen und einen alten Bereich aufgeteilt. Neue Objekte werden im jungen Bereich angelegt. Beim Zusammenkopieren werden ¨ altere Objekte in den alten Speicherbereich kopiert, da es wahrscheinlich ist, dass diese weiter aktiv bleiben. Demnach werden die ¨alteren Objekte beim recht h¨ aufigen Defragmentieren des jungen Bereichs nicht mehr betrachtet, was Zeit einspart. Der alte Bereich muss nur selten defragmentiert werden. Insgesamt wirkt sich die Speicherbereinigung st¨arker auf die Programmlaufzeit aus, je mehr Objekte erstellt und gel¨ oscht werden m¨ ussen. Deshalb sollte auch in Java mit der Speicherallokation sorgsam umgegangen werden und es sollte nach M¨oglichkeit Speicher wiederverwendet werden. F¨ ur die in dieser Arbeit favorisierte Ausf¨ uhrung des Programmcodes als Tasks wirkt sich der Garbage Collector auf sehr kurzlebige Tasks aus, deren Verarbeitungsdauer unterhalb der Ausf¨ uhrungsdauer eines Garbage Collector Laufes liegt. F¨ ur die getesteten VM-Typen dauert ein Lauf des Garbage Collectors typischerweise zwischen 10–100 ms. Einzelne kurzlebige Tasks k¨ onnen dann, sollten sie durch eine Lauf des Garbage Collectors (GC-Lauf) unterbrochen werden, pl¨ otzlich eine vielfach l¨angere Laufzeit aufweisen. Dieses Ph¨anomen wird dann deutlich in der Regressionsanalyse sichtbar. In Abbildung 6.5 ist ein GC-Lauf an den wenigen deutlich l¨ angeren Tasklaufzeiten zu erkennen, die sich u ¨ber die gesamte Laufzeit verteilen. Dabei handelt es sich jedoch nicht um einen Messfehler, den man einfach ausfiltern k¨onnte. Da die Beeinflussung jedes Task durch einen GC-Lauf gleichwahrscheinlich ist, m¨ ussen in diesem Fall mehrere Messungen gemacht werden, aus welchen dann der Mittelwert bestimmt wird. Abbildung 6.6 stellt die Fehlerh¨ aufigkeiten nach absoluter Abweichung von der Sch¨atzfunktion f¨ ur relativ kurze Tasks und f¨ ur etwas l¨angere Tasks dar. Die Messpunkte stammen auch hier von der in Kapitel 8.3 vorgestellten Applikation zur Kantenerkennung. Zus¨atzlich wurde die erwartete Normalverteilung aufgrund der gemessenen Standardabweichung der Messwerte visualisiert. Zu erkennen ist, dass die Approximationsfehler der l¨angeren Tasks eher einer Normalverteilung entsprechen als die Fehler der kurzen Tasks. Zur Erkl¨arung der H¨aufigkeitsverteilung der k¨ urzeren Tasklaufzeiten sei noch einmal auf Abbildung 6.5 verwiesen. Dort ist

119

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

zu erkennen, dass einige Tasklaufzeiten viel l¨anger sind, als die Mehrheit. Es existieren also zwei Gruppen von Laufzeiten die vom Mittelwert getrennt werden. In Abbildung 6.6 (links) sind diese beiden Gruppen als starke H¨aufigkeitsansammlung unterhalb der Mitte und oberhalb der Mitte zu erkennen. Die untere Ansammlung reflektiert unbeeinflusste Tasklaufzeiten und die obere Ansammlung reflektiert durch einen GC-Lauf verl¨angerte Laufzeiten. Aus statistischer Sicht ist eine Normalverteilung f¨ ur kurze Tasks also nicht mehr gegeben. Praktisch tritt dieser Fall jedoch nur f¨ ur sehr kurze Tasks auf. Es muss demnach festgehalten werden, dass die Prognosequalit¨ at mit der durchschnittlichen L¨ange der Tasks zunimmt. F¨ ur sehr ¨ kurze Tasks ist jedoch auch die Ubertragungsdauer der Taskdaten eventuell schon h¨oher, sodass die ungenaue Prognose der Tasklaufzeit relativiert wird (siehe Kriterium (6.5) bzw. Kriterium (6.7)).

6.4.3 Just-In-Time Compiler Java-Bytecode wird interpretiert, um ein Java-Programm auf allen Systemen ausf¨ uhren zu k¨onnen, die einen Java-Interpreter bereitstellen. Diese breite Ausf¨ uhrbarkeit zieht jedoch eine teilweise geringe Verarbeitungsgeschwindigkeit nach sich. Vor allem berechnungsintensive Programme, die viele Programmschleifen enthalten, werden davon stark beeintr¨achtigt. Um dieses Problem zu beheben, m¨ usste der komplette Bytecode zu Beginn der Ausf¨ uhrung in entsprechenden systemspezifischen Maschinencode kompiliert werden. Dieser Kompilierungsvorgang w¨ urde jedoch je nach Programmumfang und Komplexit¨at sehr lange dauern. Um die Programmstartverz¨ ogerung zu vermeiden und dennoch berechnungsintensive Programmteile in Maschinencode zu u ¨bersetzen, wird im OpenJDK ein sogenannter Just-In-Time Compiler (JIT-Compiler) eingesetzt, der Programmcode zur Laufzeit selektiv u ¨bersetzt. Danach wird interpretierter Bytecode und u ¨bersetzter Maschinencode durch die JVM gemeinsam ausgef¨ uhrt. Man spricht deshalb auch von gemischtem Code (englisch mixed-mode execution). Bei dieser Art der Kompilierung wird ausgenutzt, dass nur ein kleiner Teil des gesamten Programmcodes im gr¨ oßten Teil der Programmlaufzeit genutzt wird. Solche Verteilungen kommen h¨aufig vor und sie sind auch bei der Code-Optimierung in der Informatik anwendbar [ACGS04]. Somit ist es nicht n¨ otig, das gesamte Programm zu kompilieren, um einen deutlichen Speedup zu erzielen. Es reicht, einen kleinen Teil zu kompilieren, um die Performance stark zu verbessern. Es muss jedoch bestimmt werden, welcher Teil zu kompilieren ist. Um die berechnungsintensiven Programmteile zu identifizieren, werden durch das Laufzeitsystem umfangreiche Statistikinformationen gesammelt. Wird beispielsweise eine Programmschleife sehr oft durchlaufen, so wird nach Erreichen eines Schwellwertes die gesamte umgebende Methode kompiliert. Dieser Kompilierungsvorgang erfolgt sogar nach verschiedenen Optimierungsstufen inkrementell. Wird die Schleife also weiterhin oft durchlaufen, so wird eventuell nach Erreichen eines weiteren Schwellwertes ein erneuter Kompilierungsvorgang gestartet, der eine h¨ ohere Optimierungsstufe nutzt. Zus¨atzlich zur Kompilierung k¨onnen aufgrund der Statstikinformationen auch weitere Optimierungen, teilweise auf dem Bytecode, zur Laufzeit vorgenommen werden. M¨ogliche Optimierungen sind beispielsweise: • Inlining von Methoden; dabei wird der Programmcode der Methode direkt ausgef¨ uhrt, ohne einen Methodenaufruf zu veranlassen; • Eliminierung von Locks, falls diese nur von einem Thread erreicht werden k¨onnen;

120

6.5 Fazit

¨ • Ubergehen der Interface-Methode beim Methodenaufruf, falls es nur eine einzige Implementierung gibt; • Verschieben von nicht-volatilen Speichervariablen auf den Stack; • L¨oschen von nicht erreichbarem Code. Die Optimierungen des Just-In-Time Compilers ver¨andern offensichtlich die Laufzeit eines Programms, nicht nur weil die Performance sich bei h¨aufigen Schleifendurchl¨aufen verbessert, sondern auch weil die Kompilierung auch Programmlaufzeit in Anspruch nimmt. Konkret ist zu erwarten, dass berechnungsintensive Programme w¨ahrend der Laufzeit ihre Performance steigern k¨ onnen. Dies geschieht in mehreren Stufen. Durch die Performancesteigerung kann es bei der Vergr¨ oßerung der Eingabe zu einem superlinearen Speedup kommen, obwohl der eigentliche mathematische Zusammenhang zwischen Eingabegr¨oße und Ausf¨ uhrungszeit linear ist. Ob und wie stark optimiert wurde, kann man durch eine spezielle Ausgabe der JVM zur Laufzeit nachvollziehen. Dazu sind die Aufrufparameter -XX:+PrintCompilation f¨ ur Informationen u ur Informationen ¨ber die erfolgten Kompilierungsvorg¨ange oder -XX:+CITime f¨ u ur ben¨ otigte Zeit an den java Kommandozeilenaufruf anzuh¨angen. Die ben¨otigte ¨ber die daf¨ Zeit wird dabei nur kumuliert bei der Terminierung des Programms ausgegeben. Es ist somit nicht m¨oglich, die Dauer f¨ ur einzelne Kompilierungsvorg¨ange zu bestimmen. In Abbildung 6.5 k¨ onnte die erh¨ohte Ausf¨ uhrungszeit der ersten f¨ unf Tasks darauf hindeuten, dass diese durch JIT-Compiler Aktivit¨aten beeinflusst wurden. Die Auswertung der Logdaten ergab jedoch, dass zwar Taskcode kompiliert wurde, die Gesamtlaufzeit lag jedoch nur bei ca. 500 ms. Somit kann die Laufzeit des ersten Task nicht nur durch den JIT-Compiler beeinflusst worden sein. Die Auswirkungen auf die Laufzeit sind in Abbildung 6.5 nicht von denen des Garbage Collectors unterscheidbar. Im Allgemeinen ist der Einfluss der JIT-Compiler als gering zu bewerten. Dennoch kann die Performance zu Beginn der Ausf¨ uhrung leicht beeinflusst werden. Es sollte f¨ ur jede Taskart gepr¨ uft werden, ob u ¨ber das Ausfiltern der ersten Tasklaufzeit aufgrund erh¨ ohter Ladezeiten der Klassendateien auch noch weitere Tasklaufzeiten aufgrund der erh¨ ohten Aktivit¨at des JIT-Compiler auszufiltern sind. Im vorliegenden Beispiel wurde nicht ausgefiltert, da der Einfluss nicht als u ¨berproportional eingesch¨atzt wurde. Vor allem beim Wechsel der JVM sollte jedoch der Einfluss des JIT-Compiler erneut untersucht werden.

6.5 Fazit Ziel dieses Kapitels war es, eine Technik zu entwickeln, die f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen passende VM-Typen zur Laufzeit anhand bestimmter Parameter ausw¨ahlen kann. Dazu wird die Ausf¨ uhrungsperformance vorhergesagt. Zun¨achst wurden m¨ogliche taskbasierte Applikationen kategorisiert und es wurden f¨ ur die Auswahl zur Laufzeit abschließend nur • aus unabh¨ angigen Einzeltasks bestehende benutzerterminierte Applikationen • und aus sequentiellen Tasks bestehende eingabeterminierte Applikationen zugelassen. Andere Arten von Applikationen k¨onnen aber durch entsprechende Einschr¨ankungen auf eine der Kategorien abgebildet werden. Darauf aufbauend wurden Algorithmen zur Bestimmung von Cloud-Optionen zur Laufzeit vorgestellt, anhand derer ein Benutzer sinnvolle Ausf¨ uhrungsoptionen w¨ ahlen kann. Als Ergebnis wurde festgestellt, dass die Qualit¨at der

121

6 Auswahl geeigneter Cloud-Ressourcen zur Laufzeit

Vorhersage der Tasklaufzeit und die Wahl der verf¨ ugbaren VM-Typen einen großen Einfluss auf die Bestimmung von Cloud-Optionen haben. Diese Aspekte wurden genauer untersucht. F¨ ur die Vorhersage der Tasklaufzeiten der beiden unterst¨ utzten Applikationsarten wurden zun¨achst durch Regressionsanlyse Vorhersagefunktionen bestimmt. F¨ ur die Regressionsanalyse m¨ ussen f¨ ur jede Art Task auf allen verf¨ ugbaren Ressourcentypen aussagekr¨aftige Messreihen der Laufzeit unter Verwendung verschiedener Eingaben durchgef¨ uhrt werden. Die Eingaben sollten dabei die maximale Spannweite aller m¨oglichen Eingaben abdecken, um sp¨ater auch f¨ ur diese Werte gute Vorhersagen treffen zu k¨onnen. Es ist jedoch von Bedeutung, in welchem Ausmaß die tats¨ achlichen Messwerte um die Vorhersage schwanken. Aus der jeweiligen Schwankungsbreite der Tasklaufzeiten ergibt sich auch, welche Ressourcentypen im Verh¨altnis zueinander konfiguriert werden sollten. Schwanken die Werte stark, so sollte die Performance der verf¨ ugbaren VM-Typen weiter auseinander liegen, als wenn die Werte nur leicht schwanken. Um dies zu analysieren, wurden VM-Typen, die Java-Laufzeitumgebung und die Applikationen selbst auf deren Verhalten untersucht. Zun¨achst wurden verf¨ ugbare VM-Typen und insbesondere Ressourcentypen von Amazon EC2 auf deren Performanceschwankung untersucht. Es wurde ermittelt, dass diese im unteren zweistelligen Prozentbereich liegt. Performanceschwankungen verschiedener JVMImplementierungen konnten als unbedeutend vernachl¨assigt werden. Weiterhin wurde unter anderem auch untersucht, wie die Schwankungsbreite von Tasklaufzeiten durch spezielle Eigenschaften der Java-Laufzeitumgebung beeinflusst wird. Dazu z¨ahlen Garbage Collection, der Classloader und der Just-in-Time Compiler. Es wurde festgestellt, dass der Einfluss des Garbage Collectors f¨ ur kurze Tasklaufzeiten groß ist und mit steigender Laufzeit abnimmt. Außerdem ist es oft ratsam, die ersten Tasklaufzeiten einer Reihe von Tasks f¨ ur die Regressionsanalyse auszufiltern, da diese stark durch verz¨ogertes Klassenladen und Aktivit¨aten des Just-in-Time Compilers beeinflusst werden. Abschließend wurde festgelegt, dass der Approximationsfehler aller Messdaten f¨ ur eine Approximationsfunktion ein G¨ utekriterium KQgut einhalten muss (siehe Abschnitt 6.2.4). Bei einer angenommenen Normalverteilung der Fehler entspricht dies etwa der Forderung, dass mindestens 80% aller Werte um weniger als 50% vom Wert der Sch¨atzfunktion abweichen. Wird diese Forderung eingehalten, dann k¨onnen jeweils VM-Typen ausgew¨ahlt werden, deren Performance um ca. den Faktor 4 verschieden ist. Wird dies nicht erreicht, so kann es entweder ¨ zu großen Uberschneidungen in der Schwankungsbreite f¨ ur die verschiedenen VM-Typen kommen, was dann geh¨ auft zur falschen Auswahl des VM-Typs f¨ uhren kann. Andererseits kann auch durch Vergr¨ oßerung des Performanceabstands der VM-Typen versucht werden, eine Fehlauswahl zu vermeiden, jedoch stehen dann eventuell nur eine oder sehr wenige VMTypen zur Auswahl. F¨ ur andere IaaS-Anbieter w¨ are die Einschr¨ankung bez¨ uglich des G¨ utekriteriums KQgut ebenso zu u ¨bernehmen. Je nach Schwankungsbreite der VM-Verarbeitungsgeschwindigkeit reagiert die entsprechende Applikation jedoch anders. F¨ ur weitere IaaS-Anbieter w¨aren also ebenso die Tasklaufzeiten auf verschiedenen Ressourcen zu messen, zu analysieren und entsprechend verschiedene Ressourcentypen zu konfigurieren.

122

7 Middleware-Implementierung fu ¨r Java In den vorangegangenen Kapiteln wurden Modellierungs- und Performanceaspekte f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen untersucht. Aufbauend auf den Ergebnissen wird in diesem Kapitel eine Middleware-Implementierung vorgestellt, die das Erstellen solcher Anwendungen in der Programmiersprache Java erm¨oglicht. Die Middleware ist f¨ ur Java implementiert, da Java f¨ ur viele Mobilger¨ ate sowie f¨ ur fast alle Desktop- und Server-Betriebssysteme verf¨ ugbar ist (siehe Kapitel 2.4). Die Middleware soll Benutzer und Entwickler bei der Erstellung und Nutzung von Mobilen Cloud-unterst¨ utzten Anwendungen unterst¨ utzen und dazu die erarbeiteten Algorithmen und Techniken implementieren. Dazu z¨ahlen: • die effiziente Kommunikations- und Taskverarbeitung in kabellosen Rechnernetzwerken, • die bedarfsgerechte Auswahl und Bereitstellung von VMs zur Laufzeit ¨ • und die Uberwachung der Mobilen Cloud-unterst¨ utzten Anwendungen zum Zweck der Verbesserung der Auswahlstrategie. Die Middleware besteht aus verschiedenen Komponenten in Form von Servern, die auf virtuellen Maschinen in einem Cloud-Rechenzentrum eines IaaS-Anbieters ausgef¨ uhrt werden. Eine vorteilhafte Architektur f¨ ur die Middleware wurde in Kapitel 5.2 erarbeitet. Sie besteht neben den VMs aus einem Front-Server und Servern f¨ ur Benutzerverwaltung und Abrechnung. Die Komponenten stellen u ¨ber ihre APIs Funktionalit¨aten zur Implementierung von Mobilen Cloud-unterst¨ utzten Anwendungen zur Verf¨ ugung. Zudem ist als zweiter Bestandteil eine Programmbibliothek Teil der Middleware, die die Benutzung der ServerAPIs durch Java-Anwendungen vereinfacht und abstrahiert. Zur Entwicklung von Mobilen Cloud-unterst¨ utzten Anwendungen wird ausschließlich diese Programmbibliothek ben¨otigt. Vom Entwickler wird nur das clientseitige Programm erstellt, welches dann unter Verwendung der Programmbibliothek in der Lage ist, VMs zur Unterst¨ utzung bei berechnungsintensiven Aufgaben hinzuzuziehen. Serverseitiger Programmcode muss nur zur Installation des Applikationsprofils erstellt werden, welches zur bedarfsgerechten Auswahl von VM-Ressourcen zur Laufzeit ben¨ otigt wird. Die Anwendungsschnittstelle der Middleware ist im Cloud-Schichtenmodell auf PlattformEbene angesiedelt. Die Implementierungsdetails der darunter liegenden Infrastruktur-Schicht bleiben dabei verborgen (siehe Kapitel 1.1.2). Im Unterschied zu Plattform-APIs anderer Cloud-Anbieter ist es jedoch hier m¨oglich, den zu verwendenden VM-Typ der InfrastrukturSchicht zu beeinflussen. Dadurch wird der Nutzer in die Lage versetzt, die Verarbeitungsgeschwindigkeit der entfernt ausgef¨ uhrten Programmmodule proaktiv zu beeinflussen und den aktuellen Bed¨ urfnissen anzupassen. Weitere Anforderungen an die Middleware sind die flexible Erfassung und Abrechnung der verwendeten Ressourcen/Netzwerktraffic/etc. und die Implementierung einer Lastbalancierungsstrategie, die die effiziente VM-Nutzung sicherstellt (siehe Kapitel 5.4). Seitens des IaaS-Anbieters wird dabei nur eine API vorausgesetzt, die es erm¨oglicht, zu jedem Zeitpunkt VM-Images auf VM-Typen zu starten und zu beenden.

123

7 Middleware-Implementierung f¨ ur Java

Mobile Client Task Task Client Client API API

Common Common API API

PUBLIC CLOUD

Externe API

Broker

Compute Ressource

Log Log API API

Management Management Lastbalancierung Lastbalancierung

Interne API

Interne API

Authentifizierung

Abrechnung/Log

VM Instanz

Externe Kommunikation

Interne API

Externe API

Interne API

Auth. Auth. API API

Speedtest Speedtest

Pipelining

SOAP/HTTP

Task Task Server Server API API

Log Log API API

IaaS Provider API Cloud-Interne Kommunikation

Java Bibliothek Abstrahiert API-Aufrufe

Abbildung 7.1: Illustration der Middleware-Komponenten und deren Interaktion. Das Kapitel ist wie folgt organisiert: Zun¨achst werden die einzelnen Komponenten und deren APIs sowie die zugeh¨ origen Programmbibliotheken vorgestellt. Anschließend wird anhand von Beispielen die Verwendung der Programmbibliothek zur Implementierung von Mobilen Cloud-unterst¨ utzten Anwendungen illustriert.

7.1 Middleware-Komponenten Zur Unterst¨ utzung des Client wurde ein Aufbau der Middleware aus vier Komponenten vorgeschlagen. Die Middleware besteht aus Broker, Compute-Ressource (VM), Authentifizierung und Abrechnung. Der Aufbau ist in Abbildung 7.1 dargestellt. Zus¨atzlich sind auch die entwickelten Java-Programmbibliotheken dargestellt, auf deren Aufgaben und Implementierung im nachfolgenden Abschnitt n¨aher eingegangen wird. Jede Komponente wird dabei auf eine dedizierte virtuelle Maschine innerhalb eines Cloud-Rechenzentrums abgebildet. F¨ ur alle Komponenten wird ein spezielles VM-Image bereitgestellt, welches bereits eine Implementierung des notwendigen Softwarestacks enth¨alt und nur gestartet werden muss. Als Betriebssystem f¨ ur alle VM-Instanzen wird ein Amazon Linux 1 benutzt, welches neben der 1

Das Amazon Linux AMI (Amazon Machine Image) ist ein von Amazon Web Services bereitgestelltes, ” unterst¨ utztes und gepflegtes Linux-Image zur Verwendung auf Amazon EC2 (Amazon Elastic Compute Cloud). Es bietet eine stabile, sichere und High-Performance-Ausf¨ uhrungsumgebung f¨ ur Anwendungen auf Amazon EC2. Außerdem enth¨ alt es Pakete f¨ ur die einfache Integration mit AWS, darunter Startkonfigurations-Tools und viele weitverbreitete AWS-Bibliotheken und -Tools. Amazon Web Services bieten laufend Sicherheits- und Wartungsaktualisierungen f¨ ur alle Instances, auf denen das Amazon Li-

124

7.1 Middleware-Komponenten

Tabelle 7.1: Kategorisierung der API-Methoden der Middleware-Komponenten Broker

VM Authentifizierung Log/Abrechnung

intern Sessionmanagement returnKey

Sessionmanagement sendeSessionkey Benutzerverwaltung authenticate Logging writeLogEntry

extern Ressourcenallokation Ressourcenauswahl getInstanceForType deploy undeploy calculateMCsingle calculateMCmulti SPEEDTEST (Web) Taskverarbeitung pipelining Bedeutung:

SOAP-API Socket-API propriet¨ are-API

notwendigen Java-Laufzeitumgebung auch Kommandozeilenwerkzeuge zur Verwendung der Amazon EC2 Provider-API bereitstellt. Es wurde auf eine minimale Softwareausstattung der VM-Instanzen geachtet, damit Performance und Sicherheit kaum beeintr¨achtigt werden. Authentifizierung und Abrechnung sind durch Datenbanken realisiert. Der Broker ist eine zentrale Komponente, die als Frontend fungiert und Nutzeranfragen von außen direkt entgegennimmt und beantwortet. Authentifizierung und Abrechnung sind von außen nicht erreichbar und werden nur von Komponenten innerhalb des Cloud-Rechenzentrums verwendet. Jede Komponente bietet eine interne Schnittstelle an, die von anderen Komponenten genutzt werden kann. Einzig Broker und VMs bieten auch externe Schnittstellen an, um mit den Clients kommunizieren zu k¨ onnen. Tabelle 7.1 fasst die verschiedenen Schnittstellen der einzelnen Komponenten zusammen und kategorisiert sie nach deren Verwendung. Außerdem ist dargestellt, welche Kommunikationsprotokolle je nach Aufgabe f¨ ur die einzelnen APIMethoden benutzt werden. Der eigentliche Programmcode zur Unterst¨ utzung der mobilen Applikationen wird auf den VMs ausgef¨ uhrt. Zwischen diesen und den Clients im Internet findet der Großteil der Kommunikation statt. Hier fließen die Nutzdaten. Dieses auf Pipelining basierende Kommunikationsprotokoll ist in Kapitel 4.3 vorgestellt worden und verwendet kein allgemein standardisiertes Protokoll. SPEEDTEST ist ebenfalls in Kapitel 4.3 bereits vorgestellt worden und verwendet ein auf HTTP basierendes Kommunikationsprotokoll, welches nicht ¨ offentlich publiziert ist. Details zu Aufgaben und Implementierungen der einzelnen Schnittstellen werden im nachfolgenden Abschnitt vorgestellt. Die bereitgestellte Programmbibliothek kapselt unter anderem API-Aufrufe zu den Komponenten (beispielsweise der komplexen Broker-API ) und reduziert so den Implementierungsaufwand f¨ ur den Entwickler. Besonders seitens des Clients und der VM ist die Programmbibliothek wichtig, da sie die effiziente Kommunikationstechnologie auf Basis des Task-Konzepts und des Pipelinings implementiert (siehe Kapitel 4.3). Die verf¨ ugbaren Programmbibliotheken sind in Abbildung 7.1 ebenfalls dargestellt. Ihre Funktionalit¨at wird sp¨ater in Kapitel 7.3 ¨ genauer erl¨ autert. Zun¨ achst wird jedoch ein Uberblick gegeben, welche Softwarepakete in Java zur Verf¨ ugung stehen und wo diese benutzt werden: nux AMI ausgef¨ uhrt wird. Das Amazon Linux AMI wird Amazon EC2-Nutzern kostenlos bereitgestellt.“ (Onlineressource http://aws.amazon.com/de/amazon-linux-ami/(abgerufen am 29.10.2013))

125

7 Middleware-Implementierung f¨ ur Java

ferb.auth stellt f¨ ur die Authentifizierung notwendige Klassen zur Verf¨ ugung. Dieses Paket wird auf dem Broker und der Authentifizierung verwendet. ferb.log stellt f¨ ur die Abrechnung notwendige Klassen zur Verf¨ ugung. Dieses Paket wird auf der Abrechnung, den VMs und dem Broker verwendet. ferb.master implementiert die Logik des Broker. Dazu z¨ahlt die Lastbalancierung von VM-Instanzen. Außerdem wird auch die Funktionalit¨at zur Ressourcenauswahl zur Laufzeit implementiert. Dieses Paket wird nur auf dem Broker ben¨otigt. ferb.common stellt f¨ ur den Client Funktionalit¨at f¨ ur die Ressourcenauswahl zur Laufzeit bereit. Dazu z¨ ahlen die Kapselung von Broker-API Aufrufen f¨ ur Android und Methoden zur Absch¨ atzung der Netzwerkperformance aufgrund gemessener Parameter. Dieses Paket wird nur auf den Clients ben¨otigt. ferb.pipe implementiert das Transferieren von Tasks unter Verwendung des Pipeliningprotokolls zwischen Client und VM. Dieses Paket wird nur auf den Clients und den VMs verwendet. F¨ ur den Entwickler von Mobilen Cloud-unterst¨ utzten Anwendungen sind demnach nur die Pakete ferb.log, ferb.common und ferb.pipe wichtig. Die clientseitige Programmbibliothek kann gleichermaßen unter Android und JVMs wie dem OpenJDK verwendet werden. Die u ¨brigen Pakete dienen der Implementierung der Middlewarekomponenten. Im nachfolgenden Kapitel werden die Netzwerkschnittstellen in ihrer Funktion und Benutzung genauer beschrieben.

7.2 Netzwerk-APIs der Komponenten Alle Datentransfers zwischen den Komponenten der Middleware finden verschl¨ usselt statt. Dazu wird die SSL/TLS-Verschl¨ usselung unter Verwendung von Zertifikaten benutzt (siehe Kapitel 4.2.2). Da die internen API-Methoden nur von Systemkomponenten benutzt werden, wird die Authentifizierung mit Hilfe von SSL-Zertifikaten gel¨ost, denen die einzelnen Komponenten gegenseitig vertrauen. Die internen Schnittstellen sind bis auf die des Broker als TCP-Socket-Verbindungen ausgef¨ uhrt. Nur externe Schnittstellen sind f¨ ur die Entwicklung von Mobilen Cloud-unterst¨ utzten Anwendungen relevant, somit kann die interne Kommunikation leicht an spezifische Gegebenheiten der Infrastruktur-Schicht angepasst werden. TCP-Sockets in Java wurden f¨ ur die interne Kommunikation gew¨ahlt, da sie zertifikatsbasiertes SSL standardm¨ aßig unterst¨ utzen. Zus¨atzlich wird bei Socket-Verbindungen kein Overhead f¨ ur die Datencodierung ben¨ otigt, da Bytes direkt transferiert werden. Dies ist f¨ ur die internen Schnittstellen ausreichend, weil ausschließlich Text u ¨bertragen wird. Zudem kann auf Komprimierung verzichtet werden, da interne Datentransfers zwischen VM-Instanzen ¨ innerhalb des gleichen Rechenzentrums stattfinden und somit eine hohe Ubertragungsgeschwindigkeit gew¨ ahrleistet ist (>100 Mbit). Alle internen Verbindungen arbeiten nach dem Request-Response Muster. Nach dem Aufbau der Verbindung wird nur eine einzelne Anfrage und darauf folgend eine Antwort gesendet. Danach wird die Verbindung sofort getrennt. Interne APIs sind zus¨ atzlich durch eine Firewall des IaaS-Anbieters gesch¨ utzt und k¨onnen aus dem Internet nicht angesprochen werden.

126

7.2 Netzwerk-APIs der Komponenten

Die externe Broker-API ist bis auf SPEEDTEST als SOAP-API ausgef¨ uhrt, da sie in verschiedene Anwendungen integriert werden muss und SOAP dabei vielf¨altige M¨oglichkeiten bietet. Die Implementierung der internen API ist dabei im Gegensatz zu allen anderen internen APIs auch als SOAP-API gew¨ahlt worden, um die Gleichartigkeit der Broker-API zu erreichen. Sie kann bei Bedarf auch anders realisiert werden. Bei SPEEDTEST handelt es sich um eine nicht selbst entwickelte Software, deren HTTP-basierte Web-API bereitgestellt wird und nicht ver¨ andert werden kann. Beim Aufrufen der externen SOAP-API des Broker sind stets Benutzername und Passwort anzugeben. Die Authentifizierung des Benutzers bzw. der Applikation auf den VMs erfolgt dagegen wie in Kapitel 5.2.4 beschrieben u ¨ber einen Sessionkey. Die verschl¨ usselte Kommunikationsverbindung zwischen den VMs und den Clients unter Verwendung des Pipeliningmechanismus wurde bereits in Kapitel 4.3 beschrieben. Die VMs bieten ausschließlich dieses Protokoll u ¨ber ihre externe API an. ¨ Ublicherweise erhalten neu gestartete VM-Instanzen stets verschiedene IP-Adressen. Bei der Verwendung von SSL-Zertifikaten f¨ uhrt dies zu einem Problem, da Zertifikate an IPAdressen oder Hostnamen gebunden werden. Als Ergebnis schl¨agt die Verifizierung des Zertifikats bei abweichender IP-Adresse fehl. Um dieses Problem bei den Komponenten Broker, Authentifizierung und Abrechnung zu l¨osen, bieten IaaS-Anbieter oft statische IP-Adressen oder Namensaufl¨ osungsdienste an, die gemietet werden k¨onnen. Somit bleiben Name oder IP-Adresse dieser Komponenten gleich und die Verifizierung funktioniert. Da die Anzahl von VMs jedoch schwankt, muss hier ein anderer Mechanismus angewendet werden. F¨ ur die VMs wird ein Wildcard-Zertifikat verwendet, welches f¨ ur alle Instanzen innerhalb des Bereichs des IaaS-Anbieters g¨ ultig ist (beispielsweise *.eu-west-1.compute.amazonaws.com statt ec2-54-228-14-184.eu-west-1.compute.amazonaws.com). Bis auf die Schnittstelle zur IaaS-Anbieter-API sind nachfolgend alle Schnittstellen der einzelnen Komponenten in Pseudocode angegeben. Die Schnittstelle des verwendeten Anbieters Amazon EC2 ist als SOAP Web Service verf¨ ugbar und kann u ¨ber verschiedene Bibliotheken unter anderem in den Sprachen Java und Python angesprochen werden2 . Alle IaaS-Anbieter Aufrufe werden vom Broker durchgef¨ uhrt.

7.2.1 Broker Die API-Methoden des Broker sind bis auf SPEEDTEST als SOAP Web Service ausgef¨ uhrt (siehe Tabelle 7.1). Als gemeinsame Ausf¨ uhrungsplattform wurde ein Applikationsserver verwendet, der die Methoden der internen API, der externen API und SPEEDTEST als einzelne Applikationen beherbergt. Der Applikationsserver b¨ undelt die Konfiguration und das Logging an zentraler Stelle und wurde deshalb jeweils einzelnen Serverprogrammen vorgezogen. Die Erzeugung der Web Services erfolgte mit Hilfe von Apache Axis2 3 und nutzt auch 2

Amazon stellt zur Verwendung seiner EC2-SOAP-API Programmbibliotheken f¨ ur verschiedenste Programmiersprachen bereit. Ebenso werden die Entwicklungsumgebungen Eclipse und Visual Studio unterst¨ utzt. Auf dem bereits erw¨ ahnten Amazon Linux sind ebenfalls Kommandozeilenwerkzeuge installiert, die zum Ansprechen der EC2-API geeignet sind. (siehe Onlineressource http://docs.aws.amazon.com/AWSEC2/ latest/APIReference/Welcome.html (abgerufen am 30.10.2013)) 3 Apache Axis (Apache eXtensible Interaction System) ist eine Laufzeitbibliothek zur Realisierung von darauf basierenden Web Services und Client-Anwendungen. Apache Axis 2 ist dabei eine komplette Neuimplementierung von Apache Axis. Die aktuelle Version stammt aus dem Jahr 2012. Diese Arbeit st¨ utzt sich auf die Verwendung von Axis2/Java. Ebenso ist eine Axis2/C Implementierung vorhanden. Zum Umfang geh¨ oren die Werkzeuge JAVA2WSDL und WSDL2JAVA, die das Erzeugen von Web Services aus Java-Klassen maßgeblich vereinfachen. (siehe [JA11])

127

7 Middleware-Implementierung f¨ ur Java

die Apache Axis2 Laufzeitkomponenten (beispielsweise zur Verarbeitung der SOAP XMLNachrichten). Mit deren Hilfe l¨ asst sich ein Web Service als standardisierte Java-Web-Komponente erzeugen (Web Application Archive (WAR)), die dann auf einem konformen Applikationsserver ausgef¨ uhrt werden kann. Grundlage ist die Java Servlet Spezifikation 4 , die die Definition und Ausf¨ uhrung von Java-Klassen auf einem Server spezifiziert. Als Server wurde hier der Apache Tomcat Applikationsserver5 benutzt. Bei allen externen API-Methoden sind stets Benutzername und Passwort anzugeben. Deshalb findet sich in allen externen SOAP-API-Methoden die Parameter String user und String pass wieder. Die externe Broker-API ist nur u usselte SSL-Verbindung ¨ber eine verschl¨ zu verwenden. Die Dienste der Middleware stehen nur registrierten Benutzern zur Verf¨ ugung. Diese Einschr¨ ankung ist notwendig, um die genutzten VMs auch in Rechnung stellen zu k¨onnen. Die WSDL-Beschreibung der externen API-Methoden ist in Anhang D zu finden. Nachfolgend wird die Funktionsweise der einzelnen externen und internen API-Methoden des Broker genauer erkl¨ art. Ressourcenallokation Die Methode getInstanceForType(...) allokiert f¨ ur einen Client eine Cloud-Ressource und etabliert f¨ ur den Anfragenden gleichzeitig einen Sessionkey. Sie markiert den Beginn eines Cloud-Nutzungszyklus, wie er in Kapitel 5.2.4 beschrieben ist. Sie hat folgenden Funktionsprototyp und liefert eine Struktur vom Typ CloudSession zur¨ uck: CloudSession getInstanceForType(String name, String type, String user, String pass)

Dabei beschreibt name den Namen des angeforderten Dienstes. Im Normalfall ist dieser als “PIPE“ anzugeben, da nur VM-Images des Pipelining Typs verf¨ ugbar sind. F¨ ur Erweiterungen der Middleware k¨ onnen hier neue VM-Images hinterlegt werden. Der Parameter type spezifiziert die gew¨ unschte Qualit¨ at der Cloud-Ressoure, also den VM-Typ. Die zur¨ uckgelieferte Struktur enth¨ alt die konkrete IP-Adresse (endpoint) der allokierten VM und den erstellten Sessionkey (session_key), der ben¨otigt wird, um vom Client eine Verbindung zu der VM aufzubauen. struct CloudSession { String endpoint; String session_key; }; 4

Servlets stellen eine Java-spezifische Variante dar, um Web-Inhalte dynamisch nach dem Inhalt einer Anfrage zu erzeugen und auszuliefern. Dazu spezifiziert die Servlet-API, wie eine Java-Klasse auszusehen hat, die dann Anfragen von außen, oft via HTTP, entgegennehmen und beantworten kann. Die Klassen werden von einem sogenannten Servlet-Container ausgef¨ uhrt, der die eingehenden Anfragen auf die enstprechenden ¨ Servlets zuweisen kann. Ahnliche Konzepte sind beispielsweise durch CGI-Skripte oder PHP-Skripte f¨ ur andere Programmiersprachen realisiert worden. (siehe [HC10]) 5 Apache Tomcat ist ein quelloffener, in Java geschriebener Webserver, der die Spezifikation f¨ ur Java Servlets und Java Server Pages (JSP) implementiert und es damit erlaubt, in Java geschriebene Web-Anwendungen auf Servlet- bzw. JSP-Basis auszuf¨ uhren. Urspr¨ unglich von Sun Microsystems gestartet, wird der Programmcode seit 1999 von einer Gemeinschaft unter der Apache Software Foundation weiterentwickelt. Er ist heute als Modul auch in sogenannten Enterprise Applikationsservern integriert, beispielsweise Apache Geronimo. (siehe [MM07])

128

7.2 Netzwerk-APIs der Komponenten

Ressourcenauswahl Die API zur Ressourcenauswahl wird aus den Methoden deploy(...), undeploy(...), calculateMCmulti(...) und calculateMCsingle(...) gebildet. Diese vier externen Methoden werden benutzt, um dem Client eine Auswahl sinnvoller VM-Typen zu erstellen, die f¨ ur die aktuelle Situation und Applikation verf¨ ugbar sind. Dabei wird dem Client die Menge M c zur¨ uckgeliefert, deren Berechnung in Kapitel 6.1.3 vorgestellt wurde. F¨ ur jede Applikation muss als Datenbasis zun¨ achst ein Profil installiert werden, aus dem dann M c berechnet werden kann. Ein Profil enth¨ alt neben den m¨oglichen VM-Typen auch Methoden zur Sch¨atzung der Laufzeit der Applikation auf diesen VM-Typen. F¨ ur das Installieren und Integrieren einer neuen Applikation in das System steht die externe API-Methode deploy(...) zur Verf¨ ugung. Die Methode hat folgenden Prototyp: bool deploy(String name, String[] lauf, String[] index, float[] kosten, String VM_image, float trafficcost, String user, String pass)

Die beiden Arrays index und kosten enthalten die ausw¨ahlbaren VM-Typen und deren jeweilige Abrechnungskosten in $ pro Stunde in der gleichen Reihenfolge. Beispiel: index={c1.medium, c1.xlarge}; kosten={0.13, 1.32}; Zu beachten ist hierbei, dass damit die Kosten gemeint sind, die dem Nutzer in Rechnung gestellt werden. Diese sind meist h¨oher als die Kosten, die vom IaaS-Provider als Miete f¨ ur Cloud-Ressourcen anfallen. Der zu erwartende Aufschlag ist von der Anfrageh¨aufigkeit, der Anfragel¨ange und der Ressourcenalloka¨ tionsstrategie abh¨ angig und wurde in Kapitel 5.4 durch Simulation bestimmt. Ublicherweise wird f¨ ur name wieder stets “PIPE“ angegeben. Das zu verwendende VM_image ist ebenfalls anzugeben. Dieses muss bereits vorher beim IaaS-Anbieter registriert worden sein, aber auch hier handelt es sich u ¨blicherweise stets um das gleiche Image. Das Array lauf enth¨alt den Quellcode von Klassen, die das Verhalten verschiedener Applikationen beschreiben. Der Name der Klasse spezifiziert dabei den Name der Anwendung, f¨ ur die sie die Laufzeitfunktion lauf (. . . ) bereitstellt. Die Anwendung wird auch als Subtyp bezeichnet, da alle Anwendungen auf VMs des “PIPE“-Typs ausgef¨ uhrt werden. Die genaue Spezifikation und Konstruktion des Quellcodes wird sp¨ ater in Kapitel 7.3.4 anhand eines Beispiels erl¨autert. Die Daten¨ ubertragungskosten sind ebenfalls in $ pro GigaByte als trafficcost anzugeben. Sie werden sp¨ater bei der Berechnung von Cloud-Optionen ben¨otigt, um den Anteil der Daten¨ ubertragungskosten zu berechnen. Zur Deinstallation von Applikationen steht die Methode undeploy(...) zur Verf¨ ugung. Sie hat folgenden Prototyp: bool undeploy(String name, String user, String pass)

Eine direkte Modifikation von bereits installierten Applikationen, beispielsweise des Mietpreises konfigurierter VM-Typen, ist nicht vorgesehen. Hierzu muss immer deinstalliert und erneut installiert werden. Die eigentliche Berechnung passender Cloud-Optionen zur Laufzeit wird durch die Methoden caculateMCsingle(...) und calculateMCmulti(...) f¨ ur eingabeterminierte Applikationen beziehungsweise f¨ ur benutzerterminierte Applikationen realisiert (siehe Kapitel 6.1.1). Sie werden zur Laufzeit mit den entsprechenden Parametern vom Client aufgerufen. Die Methode calculateMCsingle(...) hat folgenden Prototyp: List calculateMCsingle(String user, String pass, String name, String subtype, int[] size, float t_comm, float t_mobil, int downloadsize)

129

7 Middleware-Implementierung f¨ ur Java

Dabei werden die f¨ ur die Laufzeitsch¨ atzung notwendigen Parameter im Array size u ¨bergeben und die rein mobile Vergleichslaufzeit t_mobil wird in Sekunden angegeben. Die gesch¨atzte Kommunikationszeit t_comm wird ebenfalls u ur notwendigen Parameter ¨bergeben. Die daf¨ m¨ ussen, wie in Kapitel 4 beschrieben, vorher gemessen und mit Bibliotheksunterst¨ utzung in die Kommunikationszeit umgewandelt werden. Die daf¨ ur vorgesehenen Bibliotheksfunktionen werden sp¨ater bei der Vorstellung der clientseitigen Bibliotheken noch n¨aher erl¨autert. Abschließend wird die insgesamt zu erwartende Gr¨oße der Downloaddaten in Byte als downloadsize ebenfalls u ubertragungskosten berechnet, ¨bergeben. Aus dieser Gr¨oße werden die Daten¨ die im Fall des in dieser Arbeit verwendeten IaaS-Anbieters Amazon EC2 nur f¨ ur Downloaddaten anfallen. calculateMCsingle(...) liefert, wie auch calculateMCmulti(...), eine Liste von m¨ oglichen Cloud-Optionen zur¨ uck. Die Methode calculateMCmulti(...) hat folgenden Prototyp: List calculateMCmulti(String user, String pass, String name, String subtype, int[] size, float f_comm, float f_mobil, int downloadsize)

calculateMCmulti(...) unterscheidet sich von calculateMCsingle(...) dadurch, dass statt einer mobilen Laufzeit und einer Kommunikationszeit hier jeweils eine Rate ausgef¨ uhrter Tasks und eine Rate m¨ oglicher Task¨ ubertragungen pro Sekunde anzugeben ist. Als downloadsize ist hier die Downloaddatengr¨oße in Byte pro Task anzugeben. Eine zur¨ uckglieferte CloudOption repr¨ asentiert eine m¨ ogliche sinnvolle Option eines VM-Typs zur Ausf¨ uhrung der angefragten Applikation und die dann zu erwartenden Eigenschaften. Sie hat folgenden Typ: struct CloudOption { String type float t_remote int cost };

//Instanztyp (Ressource) //Ausf¨ uhrungszeit oder Rate auf dieser Ressource //Kosten (pro Sekunde) auf dieser Ressource in cent

F¨ ur eingabeterminierte Applikationen enth¨alt eine Cloud-Option den VM-Type (type), die Ausf¨ uhrungszeit eines Tasks des angegebenen Typs (t_remote) und die daf¨ ur anfallenden Kosten (cost). Bei benutzerterminierten Applikationen ist statt der Gesamtausf¨ uhrungszeit eine Rate angegeben. F¨ ur die Rate sind die Kosten pro Sekunde angegeben, f¨ ur die Gesamtausf¨ uhrungszeit sind die Gesamtkosten angegeben. Sessionmanagement Das Zur¨ uckgeben des Sessionkey erfolgt nach dem Trennen der Verbindung durch den Client von der allokierten VM-Ressource durch die VM selbst (siehe Kapitel 5.2.4). Dazu besitzt der Broker eine interne Schnittstelle mit folgendem Funktionsprototyp, die von der VM aufgerufen wird: bool returnKey(String session_key)

returnKey(...) ist ebenfalls als SOAP Web Service realisiert, da die Methode neben anderen als Einzelapplikation auf dem Applikationsserver des Broker installiert ist.

130

7.2 Netzwerk-APIs der Komponenten

Abbildung 7.2: Einsatz von SPEEDTEST Mini zur Bestimmung der Bandbreite zum BrokerServer gemessen auf einem Sony Xperia P Smartphone (siehe Anhang A).

SPEEDTEST zur Bestimmung der Kommunikationsperformance SPEEDTEST.NET MINI 6 , im Weiteren einfach SPEEDTEST genannt, wurde bereits in Kapitel 4.4 benutzt, um die Kommunikationsperformance f¨ ur die Vorhersage der Daten¨ ubertragungszeit zu bestimmen. Deshalb ist SPEEDTEST Teil der Broker-API, wird jedoch nicht via SOAP angesprochen. SPEEDTEST ist als kostenlose Web-Applikation f¨ ur Java Servlet Container verf¨ ugbar. Sie wurde im gleichen Apache Tomcat Server installiert, der bereits f¨ ur die Realisierung der restlichen API-Methoden des Broker verwendet wird. Das ¨ Servlet liefert zun¨ achst eine Webseite aus, welche ein Flash-basiertes Applet7 enth¨alt. Uber ¨ dieses werden vom Broker Dateien heruntergeladen und ebenso hochgeladen. Aus der Uber¨ tragungszeit wird die ausgenutzte Ubertragungsbandbreite bestimmt. Dieses Werkzeug ist flexibel einsetzbar. Es kann von einem Mobilger¨at oder von einem Desktop-PC aufgerufen werden. Einzig ein Flash-f¨ ahiger Webbrowser ist Voraussetzung. Ein Screenshot des Messergebnisses zwischen dem Broker und einem Smartphone ist in Abbildung 7.2 zu sehen. SPEEDTEST wurde aufgrund seiner kostenlosen Verf¨ ugbarkeit, der einfachen Installation und Anwendung und ebenso wegen seiner Ausgereiftheit eingesetzt und es wurde auf eine Eigenentwicklung der Bandbreitenbestimmung verzichtet. Zudem wurde in Kapitel 4 festgestellt, dass zur realistischen Bewertung der aktuellen Netzwerkperformance mehrere Messungen durchgef¨ uhrt werden sollten. Es ist hier schwierig eine automatisierte Bewertung durchzuf¨ uhren. Deshalb obliegt es dem Nutzer, die tats¨achlich verf¨ ugbare Performance vor der Bestimmung von Cloud-Optionen mit Hilfe von SPEEDTEST m¨oglichst gut abzusch¨atzen.

6 7

Verf¨ ugbar unter Onlineressource http://www.speedtest.net/mini.php (abgerufen am 3.2.2014) Adobe Flash ist eine Plattform f¨ ur Anwendungen, die u uhrt werden. Dazu ¨berwiegend im Webbrowser ausgef¨ wird ein Browser-Plugin ben¨ otigt, welches f¨ ur viele aktuelle Webbrowser verf¨ ugbar ist. Urspr¨ unglich zur besseren Unterst¨ utzung multimedialer Visualisierungen im Web-Umfeld entwickelt, wird Flash heute f¨ ur sehr viele verschiedene Web-Anwendungen genutzt. Darunter befinden sich Spiele, Informationsssoftware, Bildverarbeitung und auch Benchmarks. (siehe Onlineressource http://www.adobe.com/de/products/ flashplayer.html (abgerufen am 29.10.2013))

131

7 Middleware-Implementierung f¨ ur Java

7.2.2 Authentifizierung Der Broker nutzt zur Authentifizierung der Clients mittels Benutzername und Passwort einen dedizierten Dienst, welcher von der Authentifizierung zur Verf¨ ugung gestellt wird. Die Authentifizierung stellt die interne API-Methode authenticate(...) u ¨ber die beschriebene verschl¨ usselte TCP-Socket-Verbindung zur Verf¨ ugung. Diese hat folgenden Prototyp: bool authenticate(String user, String pass)

Die Methode liefert wahr oder falsch zur¨ uck. Auf die Implementierung einer umfassenden Nutzwerverwaltung, welche auch Bonit¨atspr¨ ufung und monatliche Abrechnung umfassen w¨ urde, wurde hier verzichtet, da dieser Aspekt f¨ ur die bedarfsgerechte Ressourcenauswahl f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen nur eine nachrangige Rolle spielt. Es wird davon ausgegangen, dass die konfigurierten Benutzer von einem Administrator direkt auf der Authentifizierung eingetragen werden. Somit ist auch keine externe API zur Authentifizierung implementiert. Zu Testzwecken sind berechtigte Benutzer und zugeh¨orige Passw¨orter zeilenweise in einer Datei abgelegt.

7.2.3 Abrechnung/Log Die Abrechnung besitzt ein sehr flexibles, nur intern verf¨ ugbares Interface, welches nur den Sessionkey zusammen mit einem benutzerspezifischen Logeintrag variabler L¨ange akzeptiert. Ein initialer Logeintrag wird vom Broker stets zum Beginn einer neuen Session u ¨bermittelt. ¨ Der gr¨oßte Teil der Logdaten kommt jedoch von VMs, welche die Uberwachungsdaten der Applikationen und das Ende der Sessions u ¨bermitteln. Die Logeintr¨age werden durch die VMs selbst gepuffert und nur gelegentlich zur Abrechnung u ¨bertragen. Durch diese wenigen ¨ großen Datentransfers kann die Ubertragungsbandbreite bestm¨oglich ausgenutzt werden. Die Methode writeLogEntry(...) hat folgenden Prototyp: bool writeLogEntry(String session_key, byte[] log_entry)

Zur bestm¨ oglichen Unterst¨ utzung von benutzerdefinierten Logformaten werden in der Logdatenbank nur komplette Logdatens¨ atze unter Angabe des Sessionkey und des Zeitstempels abgelegt. Diese k¨ onnen sp¨ ater unter Angabe des Sessionkey zu Debug- und Analysezwecken abgerufen werden. Eine spezielle Struktur der Logdatens¨atze wird nicht verlangt. F¨ ur die prototypische Implementierung wurde f¨ ur jeden stets eindeutigen Sessionkey eine eigene Datei angelegt, in der die u ¨bertragenen Logdaten unter Angabe des Zeitstempels abgespeichert wurden. Der Prozess der Rechnungsstellung selbst wird jedoch in dieser Arbeit nicht betrachtet, da der Fokus auf der Realisierung der Anwendung liegt. F¨ ur Produktivimplementierungen sollten die Logdaten redundant und sicher abgelegt werden, da sich aus Ihnen auch die Daten f¨ ur die Abrechnung der Nutzung ableiten. Moderne sogenannte NoSQL-Datenbanken8 k¨ onnen zur Speicherung verwendet werden, deren Kapazit¨at sehr groß und deren Schreibperformance f¨ ur INSERT-Operationen sehr hoch ist. Zur 8

NoSQL (englisch f¨ ur Not only SQL) bezeichnet Datenbanken, die nicht dem relationalen Ansatz folgen. Der heute genutzte Begriff geht zur¨ uck auf das Jahr 2009, in dem ein Meeting zum Thema alternative Datenspeicher in San Francisco stattfand, welches diesen Term als Titel trug. Diese Datenspeicher ben¨ otigen keine festgelegten Tabellenschemata und versuchen, Joins zu vermeiden, sie skalieren dabei horizontal. Bekannte Implementierungen sind Google BigTable und Amazon Dynamo. Dar¨ uber hinaus gibt es eine Rei-

132

7.3 Implementierung der Middleware-Komponenten

Auswertung werden zudem ausschließlich Abfragen der Form “Select * From TABLE where SESSION=abcd0123;“ ben¨ otigt, welche keine Joins erfordern, die von g¨angigen NoSQLDatenbanken wie MongoDB [MPH10] nicht unterst¨ utzt werden.

7.2.4 Compute-Ressource (VM) Die VMs bieten als externe Schnittstelle das bereits in Kapitel 4.3.2 vorgestellte PipeliningProtokoll zum Transport einzelner Tasks an. Da es sich hier um eine Eigenentwicklung handelt, wurde im Gegensatz zum Broker auf die Verwendung von Standardkomponenten bei der Implementierung des Servers verzichtet. Das Serverprogramm der VMs ist somit ohne weitere Abh¨ angigkeiten als eigenst¨ andiges Java-Programm lauff¨ahig. Die externe API beschr¨ ankt sich hier auf einen einzigen TCP-Port, der zum Aufbau ei¨ ner Pipelining-Verbindung von außen genutzt werden kann. Ublicherweise wird Port 8080 verwendet. Direkt nach dem Verbindungsaufbau wird zun¨achst der vom Broker-Server erhaltene Sessionkey vom Client zur VM u ¨bertragen. Dies wurden bei der Vorstellung des Pipelining-Protokolls in Kapitel 4.3.2 als Pr¨aambel bezeichnet. Damit authentifiziert sich der Client gegen¨ uber der VM. Als Antwort empf¨angt der Client anschließend OK oder, falls der Sessionkey nicht verifiziert werden konnte, eine Fehlernachricht. Schlug die Authentifizierung fehl, wird die Verbindung von der VM anschließend sofort geschlossen. War die Authentifizierung erfolgreich, beginnt danach sofort das Pipelining-Protokoll und die VM wartet auf ¨ die Ubermittlung des ersten Task. Diese externe Schnittstelle wird als verschl¨ usselte TCPSocket-Verbindung genutzt. Zus¨atzlich bietet die VM noch eine interne Schnittstelle an, die dem Broker dazu dient, den aktuellen Sessionkey f¨ ur die n¨ achste Clientanfrage an die VM zu u ¨bermitteln. Ihre Verwendung innerhalb des Lebenszyklus einer Client-Anfrage wurde in Kapitel 5.2.4 bereits erl¨autert. Sie hat folgenden Prototyp: void sendeSessionkey(String session_key)

7.3 Implementierung der Middleware-Komponenten Dieses Kapitel stellt nicht nur die Programmbibliotheken vor, die die Middleware zur Verf¨ ugung stellt, ihre Verwendung wird auch anhand von Beispielen demonstriert. Um den beispielhaften Programmcode besser von der bereits verwendeten Darstellungsweise der APIMethoden zu unterscheiden, wurde der Java-Code als solcher markiert. Die bereits vorgestellten Softwarepakete der Java-Programmbibliothek sind nochmals in Abbildung 7.3 als UML-Diagramm (Unified Modeling Language) visualisiert und es sind zus¨atzlich noch die wichtigsten Klassen innerhalb der Pakete dargestellt.

7.3.1 Implementierung der Taskverarbeitung Die Verwendung des Pipelining-Protokolls zur effizienten Netzwerkkommunikation impliziert die Anordnung von Berechnungen als einzelne Tasks. Zur Unterst¨ utzung der Applikationsentwicklung wird eine Programmbibliothek vorgestellt, die das Pipelining implizit durchf¨ uhrt he von Open Source-Implementierungen wie beispielsweise CouchDB , Apache Cassandra und MongoDB . (siehe [SF12])

133

7 Middleware-Implementierung f¨ ur Java ferb common

pipe

auth

NetworkHelper NetworkHelper

TaskServerPipeline TaskServerPipeline

Auth Auth

SOAPClient SOAPClient

TaskClientPipeline TaskClientPipeline

CloudOption CloudOption

Task Task

CloudSession CloudSession

InstallTask InstallTask

master SOAPServer SOAPServer

log Log Log

CopySourceTask CopySourceTask CompileTask CompileTask

Abbildung 7.3: UML-Diagramm der verf¨ ugbaren Softwarepakete und deren wichtigste Klassen. und die n¨otigen Funktionen zur Task-Programmierung bereitstellt. Die eigentlichen Datentransfers werden von der Programmbibliothek durchgef¨ uhrt und ebenso wie das Marshalling und Unmarschalling von Task-Objekten vor der Applikation verborgen. Wie bereits in Kapi¨ tel 4 beschrieben, besteht ein Task bei der Ubertragung via Netzwerk aus folgenden Teilen: struct Task { String task_id; String task_function; byte[] input_data; byte[] output_data; }

Beim Transfer via Netzwerk vom Client zur VM werden task_id, task_function und input_data u ¨bertragen. In die Gegenrichtung werden nur task_id und output_data u ¨bertragen. Anhand der task_id k¨ onnen auf dem Client ausgehende und eingehende Daten einander zugeordnet werden. Im Allgemeinen ist davon auszugehen, dass die Ausf¨ uhrungsdauer der Tasks im Vergleich zur Daten¨ ubertragungszeit hoch ist, da sonst eine entfernte Ausf¨ uhrung nicht sinnvoll w¨are. Somit ist es notwendig, Puffer zu verwenden, die Tasks zwischenspeichern k¨onnen, damit w¨ahrend der Ausf¨ uhrung weitere Tasks u ¨bertragen werden k¨onnen. Die Gr¨oße der Puffer ¨ wird begrenzt durch die Uberlegung, dass auf einem Client u ¨blicherweise nur begrenzt viel Arbeitsspeicher zur Verf¨ ugung steht. Somit sollten die Puffer auf dem Client nicht gr¨oßer ausfallen als n¨ otig. Außerdem kann eine kabellose Netzwerkverbindung auch unvermittelt getrennt werden. Da jedoch mobile Daten¨ ubertragungen oft bezahlt werden m¨ ussen, sollten stets nicht mehr Tasks zur VM u ¨bertragen werden, also dort auch momentan verarbeitet werden k¨onnen. Im Falle eines Verbindungsabbruchs m¨ ussten sonst eventuell Tasks erneut ¨ u bertragen werden und deren Ubertragungsdatengr¨ o ße w¨ urde erneut abgerechnet. ¨ Task und Task-Client-API Die Java-API, die die Pipelining-Funktionalit¨at und die dazu notwendige Taskverarbeitung auf einem Client nutzbar macht, steht im Softwarepaket ferb.pipe zur Verf¨ ugung. Die abstrakte Klasse Task implementiert die grundlegenden Taskfunktionen. Von Task abgeleitete

134

7.3 Implementierung der Middleware-Komponenten

TaskServerPipeline - java.util.concurrent.BlockingQueue task_q_in - java.util.concurrent.BlockingQueue task_q_out + TaskServerPipeline(int port) + configureSSL(String keystore, String password):void + start():void + stop():void TaskClientPipeline - java.util.concurrent.BlockingQueue task_q_in - java.util.concurrent.BlockingQueue task_q_out + connect(String session_key, String server, int port):boolean + configureSSL(String keystore, String password):void + startTask(Task t):String + getResult(String id):byte[] + getNextResult():byte[] + getLastResultId():String + close():void

Task {abstract} - String task_id - byte[] input_data - byte[] output_data + getId():String + setId(String id):void + getInput():byte[] + setInput(byte[] data) + getOutput():byte[] + setOutput(byte[] data) # getSourceCode():String # process():void + processmanually():void ::java.lang.Thread + run():void

1

1

* *

EchoTask ::ferb.pipe.Task + getSourceCode():String + process():void

Abbildung 7.4: UML-Diagramm der Klassen aus dem Softwarepaket ferb.pipe zur Implementierung und Verarbeitung eines beispielhaften EchoTask. Klassen implementieren die eigentlichen Berechnungstasks. Zudem gibt es f¨ ur die VMs die Klasse TaskServerPipeline als Implementierung der Taskverarbeitung auf Serverseite. F¨ ur die Clients gibt es die Klasse TaskClientPipeline. Die UML Repr¨asentation der Klassen ist in Abbildung 7.4 zu sehen. Die abstrakte Klasse Task ist von java.lang.Thread abgeleitet und kann somit nebenl¨ aufig ausgef¨ uhrt werden. Dies erm¨ oglicht die parallele Verarbeitung von Tasks. Die Klasse Task wird auf Client- und auf Serverseite zur Repr¨asentation der Berechnungstasks benutzt. Sie im¨ plementiert die Methoden zur Ubergabe der Eingabedaten setInput(byte[] data) und zum Abholen der Ausgaben getOutput(). Die eigentliche Taskfunktion byte[] process(byte[] input) ist leer und muss von einer abgeleiteten Taskklasse implementiert werden. Eine von Task abgeleitete Klasse, die die Methode byte[] process(byte[] input) implementiert, ¨ kann dann als eigenst¨ andiger Thread ausgef¨ uhrt werden. Uber die von java.lang.Thread geerbte Methode start() wird der Task gestartet. Der Task kann ebenso synchron vom aktuellen Thread abgearbeitet werden. Dazu wird statt der Methode start() die Methode processmanually() aufgerufen, die solange blockiert, bis die Methode process(...) des Tasks ausgef¨ uhrt wurde. Diese Methode wird benutzt, wenn der Task beispielsweise wegen einer fehlenden Kommunikationsverbindung nicht entfernt ausgef¨ uhrt werden kann, sondern lokal ausgef¨ uhrt werden muss. Um einen Task auf einer VM auszuf¨ uhren, muss dessen Taskklasse bekannt sein. Vor der ¨ Ubertragung eines Tasks muss also zun¨achst der Quellcode der Taskklasse an die VM gesendet werden. Dazu wird die Methode getSourceCode() in der abgeleiteten Taskklasse u ¨berschrieben. Sie liefert den Quellcode der Taskklasse zur¨ uck. Exemplarisch ist nachfolgend unten eine Klasse EchoTask dargestellt, die einen Task implementiert, der eingehende Daten unver¨ andert zur¨ ucksendet. Dazu wird EchoTask von ferb.pipe.Task abgeleitet. Zus¨atzlich wird die Methode process(...) u ¨berschrieben. Sie implementiert die Funktionalit¨at des EchoTask und gibt die u uck. Der eigene Quellcode der Klasse ist in der ¨bergebenen Daten direkt zur¨ Konstante code abgelegt und wird durch getSourceCode() zur¨ uckgeliefert. Das nachfolgende

135

7 Middleware-Implementierung f¨ ur Java

Codebeispiel zur Benutzung der Taskklasse in der erstellten Middleware stellt dabei schon die vollst¨andige Klasse dar, die so durch die Taskverarbeitung der Middleware ausgef¨ uhrt werden kann, was im nachfolgenden Beispiel dargestellt wird. F¨ ur komplexere Funktionalit¨at muss die Methode process(...) angepasst werden und der Quellcode erneut in der Konstante code abgelegt werden. // J a v a Code B e i s p i e l import ferb . pipe . Task ; public class EchoTask extends Task { private static final String code = " import ferb . pipe . Task ; " + " public class EchoTask extends Task { " + " @Override public byte [] process ( byte [] input ) { " + " return input ; }}} " ; @Override public String getSourceCode () { return code ; } @Override public byte [] process ( byte [] input ) { return input ; } }

Die Klasse TaskClientPipeline wird bereitgestellt, um die entfernte Ausf¨ uhrung von Tasks zu erm¨ oglichen. Sie implementiert die Methoden connect(String session_key, String server, int port), configureSSL(String truststore, String password) und close(), die der Verwaltung der Verbindung vom Client zur VM dienen. Weitere Methoden dienen der eigentlichen Taskverarbeitung. Nachdem unter Angabe des Sessionkey u ¨ber connect(...) eine Verbindung aufgebaut wurde, k¨onnen die Taskverarbeitungsmethoden bis zum Aufruf von close() verwendet werden. Durch Aufruf der Methode close() oder durch sonstiges Abbrechen der TCP-Verbindung wird die Abrechnung auf Serverseite beendet und der Sessionkey invalidiert. Der clientseitige Quellcode zur Verwendung der TaskClientPipeline zur Ausf¨ uhrung eines EchoTask ist nachfolgend unten dargestellt: // J a v a Code B e i s p i e l ferb . pipe . T a s k C l i e n t P i p e l i n e tcp = new ferb . pipe . T a s k C l i e n t P i p e l i n e (); // SSL k o n f i g u r i e r e n tcp . configureSSL ( " ./ resources / SS LClien tTrust " , " password " ); // Zur vm v e r b i n d e n , w e i t e r n u r wenn "OK" , s o n s t Abbruch if ( tcp . connect ( session_key , server_endpoint , 8080). equals ( " OK " )) // Task e r s t e l l e n EchoTask ct = new EchoTask (); // Task m i t N u t z d a t e n f ü l l e n ct . setInput ( custom_data ); // Task a b s e n d e n tcp . startTask ( ct ); // Auf d a s E r g e b n i s d e r V e r a r b e i t u n g w a r t e n try { byte [] result = tcp . getNextResult (); } catch ( U n k n o w n T a s k F u n c E x c e p t i o n e ) { // F a l l s Task a u f S e r v e r s e i t e u n b e k a n n t w i r d E x c e p t i o n a u s g e l ö s t } tcp . close ();

Die interne Verarbeitung der Tasks durch die Klasse TaskClientPipeline ist in Abbil-

136

7.3 Implementierung der Middleware-Komponenten Client

Last ID Name Daten ...

Daten ID First

ID Generator

Daten ID

starttask(Task t)

Name Daten ID

Daten ID

Name Daten ID

Daten ID

Last connect(String session_key,...)

getLastResultID()

getNextResult() Daten

getResult(String ID)

Last

First

Sessionkey

Daten

Taskreader

Taskwriter

Netzwerk

API Programmbibliothek (TaskClientPipeline)

zur VM Kommunikation mit VM

Abbildung 7.5: Visualisierung der Taskverarbeitung in der Klasse TaskClientPipeline auf dem Client.

dung 7.5 dargestellt. Die Klasse implementiert die Methode String startTask(Task t), die einen Task in die Warteschlange f¨ ur ausgehende Tasks einf¨ ugt und blockiert, falls diese Warteschlange bereits voll ist. Die Warteschlange f¨ ur ausgehende Tasks hat zwei Pl¨atze. Die Warteschlange sollte zwar so klein wie m¨oglich sein, jedoch hat sich herausgestellt, dass die Netzwerkschicht bei nur einem Platz manchmal nicht schnell genug mit Daten versorgt werden kann. Nach dem erfolgreichen Einf¨ ugen liefert die Methode eine eindeutige Task-ID zur¨ uck, die sp¨ ater zum Abfragen des Ergebnisses der Taskausf¨ uhrung verwendet werden kann. Verarbeitete Tasks werden von der VM zur¨ uck zum Client u ¨bertragen und dort in eine unbeschr¨ankt große Warteschlange eingef¨ ugt. Da Ergebnisse eventuell nicht direkt entnommen werden, w¨ urde eine beschr¨ ankte Gr¨ oße hier eventuell verhindern, dass alle fertigen Ergebnisse zwischengespeichert werden k¨ onnen. Es ist also Aufgabe der Applikation, die fertigen Ergebnisse auch zeitnah zu entnehmen. Ergebnisse von Tasksausf¨ uhrungen k¨onnen am Client u ¨ber die Methode byte[] getNextResult() abgefragt werden. Diese Methode liefert die Ausgabe des n¨achsten Tasks in der Warteschlange zur¨ uck und blockiert nur, falls keine Tasks in der Warteschlange vorhanden sind. Wartet man auf das Ergebnis eines bestimmten Tasks, so kann man die Methode byte[] getResult(String taskID) aufrufen. Sie kehrt erst zur¨ uck, wenn das Ergebnis des Tasks mit der angegebenen ID in der Warteschlange vorliegt. Diese Methode sollte jedoch nur benutzt werden, wenn sichergestellt ist, dass der Task, auf den gewartet wird, nicht vorher schon aus der Warteschlange abgeholt wurde. Sollte dies nicht sichergestellt sein, so kann die Methode dauerhaft blockieren, wenn der Task, auf den gewartet wird, schon entnommen wurde. Um diese Situation zu vermeiden, kann man durch Aufruf der Methode String getLastResultID() die ID des zuletzt entnommenen Tasks abfragen. Durch das asynchrone Ausf¨ uhren von Tasks ist es nicht direkt m¨oglich zu erkennen, ob ein Task, der startTask(...) u uhrt werden ¨bergeben wurde, auch ordnungsgem¨aß ausgef¨ konnte. Im Fehlerfalle werfen erst die Methoden getNextResult() und getResult(String

137

7 Middleware-Implementierung f¨ ur Java Compute Server (VM)

Sessionkey Task Task

Task Classloader

Verfügbare Tasks

zum Broker

CPU2

Ausgehender Puffer

Taskwriter

Taskreader

k

Task Dispatcher

CPU1

Install Install Task Task

SessionReader

Eingehender Puffer

SessionWriter

zum Mobile Client

Netzwerk Kommunikation mit Broker

Kommunikation mit Mobile Client

Abbildung 7.6: Visualisierung der Taskverarbeitung auf der VM durch die Klasse TaskServerPipeline. taskID) eine Exception vom Typ UnknownTaskFuncException. Anhand der ID kann jedoch festgestellt werden, welcher Task den Fehler verursacht hat. Task-Server-API Der Task-Server auf der VM wird von der Klasse TaskServerPipeline implementiert. Sie akzeptiert eingehende Verbindungen u ¨ber die externe API von jeweils nur einem Client gleichzeitig. Dazu wird nur ein einziger TCP-Port ben¨otigt, der dann in der Firewall des IaaSAnbieters f¨ ur eingehende Verbindungen aus dem Internet ge¨offnet werden muss. Zus¨atzlich akzeptiert die Klasse TaskServerPipeline auf der VM u ¨ber die interne API Verbindungen vom Broker. Der Broker teilt der VM w¨ahrend des Allokationsvorgangs eines Clients den zu erwartenden Sessionkey mit. Baut der Client dann eine Verbindung zur VM auf, so wird der u ¨bertragene Sessionkey des Client mit dem zuvor vom Broker erhaltenen Sessionkey verglichen. Abbildung 7.6 visualisiert die Interna der Klasse TaskServerPipeline. Die Klasse verwaltet 2 Warteschlangen (java.util.concurrent.BlockingQueue), eine f¨ ur eingehende und eine f¨ ur ausgehende Tasks. Deren Gr¨oße entspricht der Anzahl verf¨ ugbarer Prozessoren auf der VM. Dies entspricht der Forderung, dass stets nicht mehr Tasks transferiert werden, als auch verarbeitet werden k¨onnen. Sind die Tasklaufzeiten lang genug, dann ist stets ein Platz f¨ ur das Ergebnis und f¨ ur einen neuen Task zur Verarbeitung in den Warteschlangen bereit. Tasks werden, da sie von der Klasse java.lang.Thread abgeleitet sind, intern von einem Threadpool abgearbeitet, dessen Gr¨oße der Anzahl verf¨ ugbarer logischer Prozessoren des Systems entspricht. Die Verwendung eines Threadpools ist sinnvoll bei der Verarbeitung vieler Tasks kurzer Laufzeit, da zur Ausf¨ uhrung in einem Threadpool bestehende Threads wiederverwendet werden und die Threaderzeugung nicht f¨ ur jeden Task als Overhead anf¨ allt. Java bietet dazu das Interface java.util.concurrent.ExecutorService

138

7.3 Implementierung der Middleware-Komponenten

an, welches von verschiedenen Threadpool-Varianten implementiert wird. Zun¨achst wird f¨ ur eingehende Tasks eine Taskklasse des ben¨otigten Typs aus einem Archiv verf¨ ugbarer Taskklassen instanziiert. Es k¨ onnen sowohl von der Middleware bereitgestellte Taskklassen als auch zur Laufzeit installierte Taskklassen geladen werden. Sollte das Laden fehlschlagen, weil keine passende Class-Datei gefunden werden konnte, so wird ein ErrorTask in die ausgehende Warteschlange eingef¨ ugt, der den Fehler dem Client r¨ uckmeldet. War die Instanziierung hingegen erfolgreich, so wird der Task zur Bearbeitung an den Threadpool u ¨bergeben. Das Ergebnis der Ausf¨ uhrung wird danach direkt in die Warteschlange f¨ ur ausgehende Tasks eingef¨ ugt. Nach Beendigung einer Verbindung sendet die Klasse TaskServerPipeline selbstst¨andig eine Notiz an den Broker, dass die Session beendet ist und die VM f¨ ur neue Client-Anfragen bereitsteht. Zudem werden die gesammelten Logdaten versendet und das Verzeichnis f¨ ur benutzerdefinierte Class-Dateien geleert. Somit kann der n¨achste Benutzer nicht versehentlich Tasks des Vorg¨ angers instanziieren. Die Klasse TaskServerPipeline enth¨alt zus¨atzlich Methoden, um den Taskserver zu starten und zu konfigurieren. Ein Minimalbeispiel zur Verwendung ist nachfolgend dargestellt. // J a v a Code B e i s p i e l ferb . pipe . T a s k S e r v e r P i p e l i n e tsp = new ferb . pipe . T a s k S e r v e r P i p e l i n e (8080); tsp . configureSSL ( " ./ resources / SS LServe rStore " ," password " ); tsp . start ();

Der Konstruktor verlangt als Parameter den zu verwendenden externen TCP-Port. Die Methode configuteSSL(...) konfiguriert die Zertifikatdatei f¨ ur die SSL-Verschl¨ usselung und ¨ das zum Offnen notwendige Passwort. Gestartet wird der Server durch Aufruf der blockierenden Methode start(). Die Methode stop() f¨ahrt den Server herunter und f¨ uhrt dazu, dass start() zur¨ uckkehrt.

7.3.2 Code-Installation zur Laufzeit In Kapitel 5.1 wurde bereits festgestellt, dass es zur Senkung der Kosten notwendig ist, VMInstanzen f¨ ur verschiedene Nutzeranfragen wiederzuverwenden. Da jedoch nicht bekannt ist, welche Applikationen die Nutzer tats¨achlich ausf¨ uhren wollen, sind VM-Ressourcen rekonfigurierbar. Jeder Nutzer installiert den ben¨otigten Programmcode zur Laufzeit selbst. Um dies im Rahmen der Taskverarbeitung zu erm¨oglichen, stehen zur Installation von Programmcode verschiedene elementare Taskfunktionen zur Verf¨ ugung. Diese dienen dazu, Quell- oder Programmcode auf die VM zu kopieren und dort gegebenenfalls auch zu kompilieren. Das Laden der einzelnen Tasks erfolgt dann durch einen speziellen Classloader . Die vordefinierten Taskklassen sind ebenfalls im Softwarepaket ferb.pipe zu finden. InstallTask Um Tasks auszuf¨ uhren, muss die Taskklasse vom Classloader auf Serverseite gefunden und geladen werden k¨ onnen. Um neue Tasks zu installieren, kann ein vordefinierter InstallTask verwendet werden. Er wird auf Clientseite benutzt, indem man den Quellcode des neuen Tasks als Eingabedaten des InstallTask angibt und den Task dann absendet. Hierbei sollte man die synchrone und ordnungsgem¨ aße Bearbeitung des InstallTask abwarten, bevor man weitere Tasks zur Verarbeitung u ¨bersendet. Das nachfolgende Beispiel verdeutlicht die Verwendung zur Installation des bereits beschriebenen EchoTask.

139

7 Middleware-Implementierung f¨ ur Java

// J a v a Code B e i s p i e l ferb . pipe . T a s k C l i e n t P i p e l i n e tcp = new ferb . pipe . T a s k C l i e n t P i p e l i n e (); tcp . configureSSL ( " ./ resources / SS LClien tTrust " , " password " ); tcp . connect ( session_key , server_endpoint , 8080); // Task i n s t a l l a t i o n ferb . pipe . InstallTask it = new ferb . pipe . InstallTask (); it . setInput ( new EchoTask (). getSourceCode (). getBytes ()); // j a v a . l a n g . S t r i n g . g e t B y t e s ( ) // I n s t a l l Task a b s c h i c k e n String id = tcp . startTask ( it ); // Warten , d a s s d e r I n s t a l l Task o rdn un gs ge mäß a b g e f e r t i g t wurde System . out . println ( new String ( tcp . getResult ( id ))); // F e h l e r b e h a n d l u n g wurde w e g g e l a s s e n // Nun kann d e r Task p r o b l e m l o s v e r w e n d e t we rden EchoTask ct = new EchoTask (); ct . setInput ( custom_data ); tcp . startTask ( ct ); byte [] result = tcp . getNextResult (); // F e h l e r b e h a n d l u n g wurde w e g g e l a s s e n tcp . close ();

Auf Serverseite wird der u ¨bergebene Quellcode in einer Datei abgespeichert und anschließend kompiliert. Es ist darauf zu achten, dass die einzige Klasse innerhalb der Quellcodedatei, die als public markiert ist, von ferb.pipe.Task abgeleitet ist. Es k¨onnen keinerlei Bibliotheken außer der Java-Systembibliothek verwendet werden, wenn der Quellcode als InstallTask installiert wird. Aller ben¨ otigter Quellcode muss sich innerhalb einer Java-Datei befinden, die so kompilierbar ist. Als Ergebnis des InstallTask wird dem Client die Debugausgabe des Kompilierlaufs zur¨ uckgeliefert. Somit kann der Entwickler im Fehlerfalle erkennen, warum der Quellcode nicht kompiliert werden konnte. Classloader Wurde ein Task inklusive seiner Nutzdaten und der zu verwendenden Taskfunktion zum Server u ¨bertragen, so muss der Server zun¨achst die Taskklasse laden, die als Implementierung der u ¨bersendeten Taskfunktion konfiguriert wurde, und an das instanziierte Task-Objekt die Eingabedaten anh¨ angen. Ein spezieller Classloader versucht, die Klasse zu laden, deren Name der u ¨bersendeten Taskfunktion entspricht. Um beispielsweise die Klasse EchoTask zu laden, muss als Taskfunktion EchoTask“ u ¨bergeben worden sein. Der Classloader versucht dann, die ” Datei EchoTask.class zu finden und zu laden. Ist dies nicht m¨oglich, wird als Ergebnis der Taskverarbeitung ein Fehler an den Client gesendet, der dann dort als Ergebnis eine Exception vom Typ UnknownTaskFuncException ausl¨ost. Alle verf¨ ugbaren Klassen, die beispielsweise durch einen InstallTask auf dem Server installiert wurden, werden in ein daf¨ ur vorgesehenes Arbeitsverzeichnis kopiert. Aus diesem Arbeitsverzeichnis versucht auch der Classloader, die entsprechenden Klassen zu laden. CopySourceTask und CompileTask Umfangreichere Programmmodule k¨ onnen mit Hilfe der durch die Middleware bereitgestellten Taskklassen CopySourceTask und CompileTask vom Client zur VM u ¨bertragen und dort gegebenenfalls kompiliert werden. Manchmal kann der Programmcode eines Tasks aus mehreren Klassen bestehen, die mit einem einfachen InstallTask nicht installiert werden k¨onnen. Bei der Verwendung des InstallTask m¨ ussen alle ben¨otigten Klassen in einer einzigen CompilationUnit (Quellcodedatei) stehen. Dies kann unpraktisch sein und zerst¨ort eventuell die Pakethierarchie, wenn bereits vorhandener Quellcode entfernt ausgef¨ uhrt werden soll. Um dieses Problem zu umgehen, k¨ onnen auch umfangreichere Pakete von Quellcode- oder Programmcodedateien im Verbund zur VM u ¨bertragen werden.

140

7.3 Implementierung der Middleware-Komponenten

Ein CopySourceTask dient dazu, Dateien zur VM zu u ¨bertragen, und akzeptiert als Eingabedaten ein Byte-Array, welches ein durch den LZMA-Algorithmus9 gepacktes Tar-Archiv ¨ von Dateien repr¨ asentiert. Nach der Ubertragung eines CopySourceTask wird auf Serverseite die zugeh¨ orige Taskfunktion ausgef¨ uhrt, welche das Archiv entpackt und die einzelnen Dateien in ihrer Paketstruktur in das Arbeitsverzeichnis extrahiert. Wurden Quellcodedateien u ¨bertragen, kann zus¨atzlich ein CompileTask vom Client zur VM gesendet werden. Die Taskfunktion eines CompileTask kompiliert alle .java-Dateien ¨ im Arbeitsverzeichnis der VM und verlangt keine Ubergabeparameter. Dabei k¨onnen keine Bibliotheken im .jar-Format ber¨ ucksichtigt werden. Der gesamte Programmcode muss als Quellcode vorliegen. Da dies nicht immer gegeben ist und da die Kompilierung teilweise recht lange dauern kann (bis zu 40 s bei gr¨oßeren Projekten), ist es auch m¨oglich, einen CopySourceTask zu benutzen, um alle ben¨otigten vorkompilierten .class-Dateien direkt zu kopieren. Dabei m¨ ussen diese ebenfalls in ein LZMA-komprimiertes Tar-Archiv gepackt sein. Hierbei kann es jedoch dazu kommen, dass die Java-Version auf Serverseite die u ¨bertragenen Dateien aufgrund inkompatibler Bytecode-Versionen nicht verarbeiten kann. In diesem Fall m¨ ussen die Class-Dateien f¨ ur die entsprechende Java-Version neu kompiliert werden. ¨ Die Ubertragung von Quellcode via CopySourceTask und die M¨oglichkeit der Kompilierung direkt auf der VM via InstallTask oder CompileTask sind vor allem zur Entwicklung von Mobilen Cloud-unterst¨ utzten Anwendungen hilfreich, da kleinere Code-Anpassungen schnell umgesetzt werden k¨ onnen. Ist der Quellcode hinreichend stabil, so ist f¨ ur die produktive Phase die Installation als Bytecode-Archiv eventuell g¨ unstiger. Dies trifft insbesondere f¨ ur ¨ umfangreiche Archive zu, da durch die LZMA-Komprimierung die Dateigr¨oße zur Ubertragung zur VM erheblich gesenkt wird. Die Besonderheit der schnellen Dekomprimierung von LZMA-Archiven macht sich ebenfalls positiv bemerkbar. Dem gegen¨ uber spielt die geringe Performance beim Komprimieren des Tar-Archivs kaum eine Rolle, da u ¨blicherweise nur einmal verpackt wird.

7.3.3 Implementierung von Applikationen auf Basis des Task Konzepts Die Verwendung des hier beschriebenen Taskkonzepts setzt zun¨achst voraus, dass sich eine Applikation so transformieren l¨ asst, dass Teile der Applikation als abgeschlossene Tasks ausf¨ uhrbar sind. Besonders gut l¨ asst sich das Konzept anwenden, wenn die Tasks unabh¨angig sind und deshalb asynchron, also nebenl¨aufig, ausgef¨ uhrt werden k¨onnen. Ein verbreitetes Konzept in der verteilten Programmierung ist jedoch auch die Verwendung entfernter Funktionsaufrufe wie es beispielsweise von Java RMI realisiert wird (siehe Kapitel 4.2.4). Mit Hilfe der bereitgestellten Programmbibliothek ist es in Grenzen auch m¨oglich, dieses Konzept des synchronen entfernten Funktionsaufrufs via Adapter bereitzustellen. Nachfolgend werden Beispiele f¨ ur die beiden Implementierungsvarianten der asynchronen Taskverarbeitung und des entfernten Funktionsaufrufs vorgestellt. Asynchrone Taskverarbeitung Die asynchrone Taskverarbeitung wird anhand der Auswertung einer Folge von Kamerabildern auf einem Android -Ger¨ at demonstriert. Zur asynchronen Verarbeitung von Tasks ist es 9

Der Lempel-Ziv-Markow-Algorithmus (LZMA) ist ein freier Datenkompressionsalgorithmus, der von Igor Wiktorowitsch Pawlow seit 1998 entwickelt wird. Er liefert im Vergleich zu anderen Verfahren eine bessere Kompressionsrate und erreicht zudem beim Entpacken eine hohe Geschwindigkeit. Der Algorithmus ist im Quellcode f¨ ur verschiedene Programmiersprachen, darunter auch Java, verf¨ ugbar. (siehe [SM10, S.411 ff.])

141

7 Middleware-Implementierung f¨ ur Java

sinnvoll, wenn das Absetzen der Tasks und das Aufsammeln und Auswerten der Ergebnisse von unterschiedlichen Threads auf dem Client erledigt werden. Das nachfolgende Beispiel verdeutlicht dies. Links ist das Starten der Tasks und rechts die Verarbeitung der Ergebnisse dargestellt. Im Beispiel nicht dargestellt ist die initiale Erzeugung des TaskClientPipelineObjekts (tcp), der Aufbau der Verbindung zur VM und die Installation des Programmcodes des verwendeten PicTask. // J a v a Code B e i s p i e l @Override public void on Previe wFrame ( byte [] data , Camera camera ) { ... PicTask pt = null ; synchronized ( Application . this ){ if ( pending < 3){ pt = new PicTask (); pt . setInput ( data ); pending ++; } } if ( pt != null ) tcp . startTask ( pt ); ... }

// J a v a Code B e i s p i e l @Override public void run () { ... while ( running ){ byte [] result = tcp . getNextResult (); synchronized ( Application . this ){ pending −−; } show ( result ); } ... }

¨ Ublicherweise wird f¨ ur einen bestimmten Sensor eine Callback-Funktion registriert, die immer dann vom Laufzeitsystem aufgerufen wird, wenn neue Sensordaten verf¨ ugbar sind. Je h¨aufiger die Methode aufgerufen wird, desto h¨oher ist die zeitliche Aufl¨osung des Sensors. Bei Kamerabildern spricht man auch von Bildverarbeitungsrate. Eine solche Callback-Funktion (onPreviewFrame(...)) ist im Codebeispiel auf der vorherigen Seite links dargestellt. Rechts hingegen ist ein Codefragment eines separaten Threads zu sehen, der die verarbeiteten Daten von der VM in einer Schleife entgegennimmt und zur Anzeige bringt. tcp repr¨asentiert hier in beiden F¨ allen das gleiche TaskClientPipeline-Objekt. Beide Methoden werden innerhalb einer Klasse Application definiert und benutzen das Objekt als Synchronisationsobjekt. Dabei wird der Zugriff auf eine Variable pending synchronisiert, die daf¨ ur sorgt, dass nicht mehr als drei Bilder gleichzeitig auf der VM verarbeitet werden. Gegebenenfalls werden Bilder verworfen, wenn noch zu viele Ergebnisse ausstehen. Zu beachten ist auch, dass nicht davon ausgegangen werden kann, dass die Reihenfolge der abgesendeten Tasks im Codebeispiel auf der vorherigen Seite links mit der Reihenfolge der empfangenen Tasks rechts identisch ist, da die Verarbeitungszeiten aufeinander folgender Tasks eventuell ungleich lang sind. Will man die Reihenfolge synchronisieren, m¨ ussten die Task-IDs ausgewertet werden, was jedoch mehr Speicherplatz aufgrund der Zwischenspeicherung von Ergebnissen seitens des Clients erfordern k¨onnte. Synchrone Task Verarbeitung Die synchrone Task-Verarbeitung entspricht einer Art Remote Object Emulation. Dabei wird der synchrone Methodenaufruf auf einem entfernten Objekt u ¨ber die Klasse TaskClientPipeline modelliert. Es wird nachfolgend beschrieben, wie aus einem bestehenden Java RMI Interface eine Task-Pipelining-kompatible Variante zur Ausf¨ uhrung erzeugt werden kann. Dazu werden auf Client- und Serverseite Adapterklassen eingesetzt, die die notwendigen Verhaltenskonvertierungen u ¨bernehmen. Es wird von folgendem Java RMI Interface (IRemoteAPI) und dessen Implementierung (RemoteAPIImplementation) ausgegangen:

142

7.3 Implementierung der Middleware-Komponenten

// J a v a Code B e i s p i e l public interface IRemoteAPI extends java . rmi . Remote { public String getInfo () throws java . rmi . Re m ot e Ex ce p ti on ; public boolean setInfo ( String info ) throws java . rmi . R em ot e Ex ce p ti o n ; } // J a v a Code B e i s p i e l public class R e m o t e A P I I m p l e m e n t a t i o n implements IRemoteAPI { private String info ; public String getInfo () throws java . rmi . Re m ot e Ex ce p ti on { return info ; } ... }

Auf Clientseite wird eine Adapterklasse ben¨otigt, welche das Java RMI Interface implementiert, die (synchronen) Funktionsaufrufe entgegennimmt und die u ¨bergebenen Parameter via Task-Pipelining zur VM u bertr¨ a gt. Anschließend wird das Ergebnis der entfernten Verar¨ beitung als R¨ uckgabewert des Funktionsaufrufs zur¨ uckgeliefert. Zur Realisierung wird f¨ ur jede Methode im RMI Interface ein Hilfstask erstellt. F¨ ur die Methode getInfo() aus dem Interface IRemoteAPI wird beispielsweise eine Klasse GetInfoTask entwickelt. Die Implementierung der Adapterklasse ClientRemoteAdapter auf dem Client, die das Interface IRemoteAPI implementiert, ist nachfolgend dargestellt. Sie verwendet intern eine Instanz der Klasse GetInfoTask, wenn die Methode getInfo() aufgerufen wird. // J a v a Code B e i s p i e l public class C l i e n t R e m o t e A d a p t e r implements IRemoteAPI { @Override public String getInfo (){ // E i n e I n s t a n z d e r K l a s s e T a s k C l i e n t P i p e l i n e ( t c p ) wurde b e r e i t s e r s t e l l t GetInfoTask git = new GetInfoTask (); String id = tcp . startTask ( git ); String result = null ; try { result = new String ( tcp . getResult ( id )); // b l o c k i e r t b i s Task i d v e r f ü g b a r } catch ( U n k n o w n T a s k F u n c E x c e p t i o n e ) { } return result ; } ... }

Der Aufruf tcp.getResult(id) blockiert, bis das Ergebnis der Taskverarbeitung vorliegt. Dies entspricht einem synchronen Methodenaufruf. Auf Serverseite wird die Taskfunktion der Klasse GetInfoTask ausgef¨ uhrt. Dabei wird die urspr¨ ungliche Methode der RMI-Implementierung RemoteAPIImplementation aufgerufen. Auf Serverseite wird Adaptercode ben¨otigt, um die Beziehung zwischen einer Objektinstanz und dem zugeh¨ origen Methodenaufruf herzustellen. Bildet man das RMI-Verhalten nach, so erh¨ alt man stets die gleiche Objektinstanz bei Anfragen an dasselbe RMI-Objekt seitens des Client. Die Instanz lebt, solange die Pipelining-Verbindung besteht. Die nachfolgende Implementierung stellt eine Variante dar, die pro Client nur ein Serverobjekt der Klasse RemoteAPIImplementation erstellt, welches als Singleton realisiert ist. Die Implementierung der Klasse GetInfoTask ist nachfolgend beispielhaft dargestellt.

143

7 Middleware-Implementierung f¨ ur Java

// J a v a Code B e i s p i e l public class GetInfoTask extends ferb . pipe . Task { @Override protected byte [] process ( byte [] input ) { // A b b i l d u n g d e s M e t h o d e n a u f r u f s a u f e i n s e r v e r s e i t i g e s O b j e k t a l s S i n g l e t o n R e m o t e A P I I m p l e m e n t a t i o n rapi = R e m o t e A P I I m p l e m e n t a t i o n . getInstance (); String info = rapi . getInfo (); return info . getBytes (); } }

Bei dieser Art der Modellierung sind jedoch auch Einschr¨ankungen zu beachten: Die Taskverarbeitung l¨ asst nur Byte-Arrays als Datentypen zu. Andersartige Parameter m¨ ussen konvertiert werden. Komplexe Strukturen m¨ ussen wie bei Java RMI serialisiert werden. Mehrere ¨ Parameter werden zu einem einzigen Ubergabeobjekt zusammengefasst und via Objektserialisierung in ein Byte-Array umgewandelt. Dar¨ uber hinaus muss u ¨ber die Relation zwischen Client-Instanz und Objekt-Instanz auf Serverseite nachgedacht werden. Im Beispiel wurde stets auf die gleiche serverseitige Objektinstanz abgebildet. Auch eine statische Methode oder eine immer wieder neue Instanz k¨ onnte man realisieren, je nach Intention der Applikation.

7.3.4 Debugging und Analyse von Cloud-unterst¨ utzten Applikationen Die Erstellung von Mobilen Cloud-unterst¨ utzten Anwendungen erfordert nicht nur die Implementierung der Applikation selbst, sondern auch das Messen wichtiger Parameter der Applikation wie beispielsweise der Performance in Abh¨angigkeit des verwendeten VM-Typs. Dies ist notwendig, um eine bedarfsgerechte Auswahl des VM-Typs zur Laufzeit zu erm¨oglichen. Nachfolgend werden die Debug-M¨oglichkeiten beschrieben, die die Middleware zur Verf¨ ugung stellt, um die notwendigen Informationen zur Performancevorhersage zu erhalten und im System anzuwenden. Auf den VMs wird f¨ ur jeden ausgef¨ uhrten Task automatisch die u ¨bertragene Datenmenge (Eingabe und Ausgabe) und die jeweilige Bearbeitungszeit als Logdaten erhoben und zur Komponente Abrechnung gesendet. Im Paket ferb.log steht zus¨atzlich die statische Methode der Klasse Log (Log.LOG(String logstring)) zur Verf¨ ugung, die w¨ahrend der Taskausf¨ uhrung verwendet werden kann, um benutzerdefinierte Loginformationen abzuspeichern. Diese benutzerdefinierten Loginformationen werden ebenfalls an die Komponente Abrechnung gesendet. Der zur Abspeicherung notwendige aktuelle Sessionkey wird durch die VM automatisch erg¨ anzt. Aus den abgespeicherten Logdaten kann sp¨ater die Laufzeitfunktion lauf(. . . ) zur Vorhersage der Laufzeit konstruiert werden. Um die in Kapitel 6.1.1 eingef¨ uhrte Laufzeitfunktion lauf(...) zur Beschreibung des Verhaltens der Applikation bereitstellen zu k¨onnen, f¨ uhrt man die Mobile Cloud-unterst¨ utzte Anwendung zun¨achst aus, ohne vorher ein Applikationsprofil auf dem Broker zu installieren. Dazu testet man die Applikationsperformance unter Verwendung verschiedener Eingaben und VM-Typen. Die VM erfasst im sek¨ undlichen Abstand auch die aktuelle Serverauslastung, die einen Anhaltspunkt f¨ ur die erreichte Effizienz liefert. Die Logausgabezeile f¨ ur die automatische Erfassung eines Task (nicht die Zeile mit der CPU-Auslastung) enth¨ alt die Uhrzeit, den verwendeten VM-Typ, die Task-ID, den Name des Task, die Gr¨ oße der eingehenden und ausgehenden Daten und abschließend die Laufzeit in Millisekunden. Ein entsprechender Ausschnitt einer Logdatei hat folgende Gestalt.

144

7.3 Implementierung der Middleware-Komponenten

13:01:50 13:01:51 13:01:52 13:01:53 13:01:54 13:01:56 13:01:57 13:01:59 13:02:00 13:02:02 13:02:03 13:02:05 13:02:06 13:02:07 13:02:08 13:02:09 13:02:09 13:02:10 13:02:11 13:02:13 13:02:15 13:02:15 13:02:16

PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM

c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium c1.medium

CPUload 4.0 CPUload 13.9 task2 CopySourceTask in 203521 out 1 416ms CPUload 11.9 CPUload 37.8 CPUload 2.0 CPUload 105.3 CPUload 93.3 CPUload 103.3 CPUload 119.3 CPUload 77.5 CPUload 173.5 task3 CompileTask in 1 out 1 13574ms CPUload 35.8 CPUload 152.8 task4 PrepareBucketRenderingTask in 2010198 out 4 2146ms task5 StartRenderingTask in 1 out 4 1ms CPUload 186.7 CPUload 198.6 CPUload 198.6 CPUload 192.9 task6 GetNextBucketTask in 1 out 1363 6385ms CPUload 194.6

Aus diesen Informationen lassen sich anschließend bereits Auswertungen bez¨ uglich der Performance der Applikation erstellen. Die Loginformationen m¨ ussen dazu je nach Applikation entsprechend ausgewertet werden. Dies erfolgt nicht automatisch, da jede Applikation eventuell andere Abspeicherungsformate der relevanten Daten ben¨otigt. Ein applikationsspezifischer Logeintrag f¨ ur die Software Sunflow , die sp¨ater in Kapitel 8 als Beispielapplikation zur Bewertung der Middleware benutzt wird, hat folgende Gestalt. 08:27:26 08:27:26 08:27:26 08:27:26 08:27:27 08:27:27 08:27:27 08:27:27

AM AM AM AM AM AM AM AM

m1.small m1.small m1.small m1.small m1.small m1.small m1.small m1.small

SCENE SCENE SCENE SCENE LIGHT LIGHT LIGHT SCENE

info info info info info info info info

: Scene stats: : * Infinite instances: : * Instances: : * Primitives: : Light Server stats: : * Light sources found: : * Light samples: : Rendering ...

1 875 271306 15 57

Bei der prototypischen Middleware-Implementierung wird jeder Logeintrag zu einem Sessionkey in einer Datei abgespeichert, welche den Namen des Sessionkey tr¨agt. Der Sessionkey selbst ist in den Beispielen nicht abgebildet. Er wird jeweils zum Beginn der Session am Dateianfang und zus¨ atzlich am Ende der Session am Dateiende geschrieben.

7.3.5 Installation/Deployment von Applikationsprofilen Nachdem aus den Logdaten einer Mobilen Cloud-unterst¨ utzten Anwendung ein Anwendungsprofil konstruiert wurde, wird diese auf dem Broker installiert. Dazu und zur nachfolgenden Nutzung durch Clients stehen die vier externen API-Methoden deploy(...), undeploy(...), calculateMCmulti(...) und calculateMCsingle(...) zur Verf¨ ugung. Es sei hier nochmals darauf hingewiesen, dass die Installation von Applikationsprofilen auf dem

145

7 Middleware-Implementierung f¨ ur Java

Broker ausschließlich zum Zweck der bedarfsgerechten Auswahl von VM-Ressourcen f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen geschieht. Die Mobile Cloud-unterst¨ utzte Anwendung selbst ist auch ohne ein hinterlegtes Profil lauff¨ahig. Diese vier externen Methoden werden benutzt, um dem Client zur Laufzeit eine situationsbezogene Auswahl sinnvoller VM-Typen zur Unterst¨ utzung bei berechnungsintensiven Aufgaben zu pr¨ asentieren. Ein Profil wird u ¨ber die bereits vorgestellte Methode deploy(...) installiert. Neben Parametern wie den Namen der m¨oglichen VM-Typen und deren Kosten ist auch der Quelltext der Laufzeitfunktion lauf(. . . ) Teil der Parameterliste dieser Methode. Dabei wird f¨ ur jeden m¨ oglichen Subtyp der Applikation eine eigene Vorhersagemethode ben¨otigt, weshalb ein Array aus Quelltexten u ¨bergeben werden muss (String[] lauf). Dies ist notwendig, da der Haupttyp (String name) stets “PIPE“ ist. Der Prototyp der Methode deploy(...) ist nachfolgend noch einmal beschrieben. bool deploy(String name, String[] lauf, String[] index, float[] kosten, String VM_image, float trafficcost, String user, String pass)

Um gr¨oßtm¨ogliche Flexibilit¨ at bei der Konstruktion der Laufzeitfunktion lauf (. . . ) zu gew¨ahrleisten, wird die Laufzeitfunktion lauf (. . . ) in Java spezifiziert. Dazu wird f¨ ur jede Applikation eine Klasse erstellt, die das Java Interface LaufInterface implementiert, welches nachfolgend dargestellt ist. // J a v a Code B e i s p i e l public interface LaufInterface { public float lauf ( int type , int [] size ); }

Die implementierte Laufzeitfunktion lauf(...) muss dann f¨ ur jeden konfigurierten VMTyp aus String[] index und einer gegebenen Eingabegr¨oße size eine Laufzeit ∆twork oder eine Rate fwork berechnen, je nachdem um welche Art von Applikation es sich handelt (siehe Kapitel 6.1.1). Ist die Laufzeitsch¨ atzung von mehreren Parametern abh¨angig, so kann die Eingabegr¨oße size mehrere Werte umfassen, die als Array anzugeben sind. Der Klassenname der Implementierung von LaufInterface ist dabei identisch zum Subtyp der Applikation. Nachfolgende exemplarische Klasse BeispielApp verdeutlicht eine solche Implementierung. // J a v a Code B e i s p i e l public class BeispielApp implements LaufInterface { @Override public float lauf ( int type , int [] size ) { float ret = 0.0 f ; switch ( type ) { case VMTypes . m1_small : ret = size [0] / 100; break ; case VMTypes . c1_medium : ret = size [0] / 250; break ; case VMTypes . c1_xlarge : ret = size [0] / 400; default : break ; } return ret ; } }

146

7.3 Implementierung der Middleware-Komponenten

Bei der Installation eines Applikationsprofils durch die Methode deploy(...) enth¨alt jeder Eintrag des Arrays lauf den Quellcode einer Klasse wie BeispielApp. Jede dieser Klassen wird vom Broker-Server kompiliert und kann entsprechend einer Anfrage sp¨ater geladen werden. Der Kompilier- und Ladevorgang ist der Code-Installation zur Laufzeit ¨ahnlich, die bereits in Kapitel 7.3.2 vorgestellt wurde. Um f¨ ur eine Vorhersage der Laufzeit f¨ ur die Applikation “PIPE“ und den Subtyp “BeispielApp“ die m¨ oglichen Cloud-Optionen zu berechnen, wird die Klasse BeispielApp auf dem Broker instanziiert und die Laufzeitfunktion lauf(int type, int[] size) entsprechend innerhalb von calculateMCsingle(...) oder calculateMCmulti(...) aufgerufen. Im nachfolgenden Kapitel ist beschrieben, wie die daf¨ ur notwendigen API-Aufrufe seitens des Clients ausgef¨ uhrt werden, um Cloud-Optionen zur Laufzeit zu berechnen. F¨ ur den Aufruf der externen SOAP-API-Methoden deploy() und undeploy() existiert keine Bibliotheksunterst¨ utzung, da die Installation und Deinstallation von Anwendungsprofilen nicht vom Client sondern nur durch einen Administrator erfolgt. Aufrufe k¨onnen durch bekannte Hilfsprogramme wie SoapUI 10 durchgef¨ uhrt werden.

7.3.6 Bestimmung von Cloud-Optionen auf Clientseite Seitens des Clients kann die Klasse SOAPClient aus dem Paket ferb.common verwendet werden, um die SOAP API des Broker anzusprechen. Dazu implementiert die Klasse die bereits beschriebenen externen API-Methoden des Broker calculateMCmulti(...) und calculateMCsingle(...) in Java. Die Klasse SOAPClient f¨ uhrt dabei auch die notwendigen Konvertierungen zwischen Java-Typen und XML-Typen durch. Um Cloud-Optionen f¨ ur eine beim Broker installierte Applikation zu berechnen, m¨ ussen zun¨achst die ben¨ otigten Parameter bestimmt werden. Deshalb sind zur Laufzeit die Gr¨oße der Eingabe (size), die zu veranschlagende Kommunikationszeit (t_comm) und die lokal auf dem Client zu veranschlagende Ausf¨ uhrungszeit (t_mobil) zu bestimmen. Diese werden den Methoden der Klasse SOAPClient u ¨bergeben und zum Broker u ¨bertragen, der daraus m¨ogliche Cloud-Optionen berechnet. Mit Hilfe des Werkzeugs SPEEDTEST , welches in Abschnitt 7.2.1 vorgestellt wurde, wird zun¨achst die verf¨ ugbare Upload- und Downloadbandbreite bestimmt. Diese wird anschließend nach Gleichung (4.6) und (4.8) in einen realistischen Wert umgerechnet. Hierf¨ ur kann die Klasse NetworkHelper aus dem Paket ferb.common verwendet werden. Sie implementiert die statische Methode calculateTransmissionTime(...), deren Prototyp nachfolgend dargestellt ist: // J a v a Code B e i s p i e l public static float c a l c u l a t e T r a n s m i s s i o n T i m e ( int size , int bw )

¨ Die Methode erwartet die Gr¨ oße der Ubertragungsdaten size in Byte und die verf¨ ugbare Bandbreite bw in Byte/Sekunde. In Kapitel 4 wurde das Pipelining-Verfahren erarbeitet, wodurch unter Berufung auf Gleichung (4.6) f¨ ur die betrachteten 3G und WLAN Netzwerke ¨ die RTT vernachl¨ assigt werden kann, da sie die Ubertragungszeit bei diesem Verfahren kaum beeinflusst. Bei der Angabe der Bandbreite ist darauf zu achten, dass das Minimum aus 10

¨ SoapUI ist eine Desktop-Applikation zum Inspizieren, Aufrufen, Uberwachen SOAP/WSDL-basierter Web Services. SoapUI ist Open Source Software und in Java geschrieben. (Verf¨ ugbar unter Onlineressource http://www.soapui.org/(abgerufen am 29.10.2013))

147

7 Middleware-Implementierung f¨ ur Java

Upload- und Downloadbandbreite anzugeben ist (siehe Gleichung (4.8)), da im Mobilbereich ¨ oft asynchrone Ubertragungsraten f¨ ur Upload und Download vorliegen. Die lokal auf dem Client zu veranschlagende Ausf¨ uhrungszeit ist oft nur bei benutzerterminierten Applikationen u ¨berhaupt zu bestimmen. Dies kann beispielsweise durch eine initiale lokale Ausf¨ uhrung der Applikation geschehen, bei der die erreichte Performance gespeichert wird. F¨ ur Anwendungen, bei denen dies nicht m¨oglich ist oder die schlicht nur sehr eingeschr¨ankt auf dem Client ausgef¨ uhrt werden k¨onnen, kann als Laufzeit f¨ ur eingabeterminierte Applikationen Float.MAXVALUE angegeben werden. F¨ ur benutzerterminierte Applikationen ist analog eine Rate von 0.0 anzugeben. Dies f¨ uhrt dazu, dass keine Cloud-Optionen bei der Berechnung durch den Broker ausgefiltert werden (siehe Algorithmus 3 und Algorithmus 4 aus Kapitel 6.1.3). Sind alle Parameter bestimmt, k¨ onnen u ¨ber die Methoden calculateMCsingle(...) oder calculateMCmulti(...) Cloud-Optionen berechnet werden. Im nachfolgenden Kapitel wer¨ den die Auswahloptionen anhand verschiedener Applikationen noch genauer vorgestellt. Uber die externe API-Methode getInstanceForType(...) kann dann eine VM des ausgew¨ahlten Typs allokiert werden. Die zur¨ uckgelieferte Datenstruktur vom Typ CloudSession enth¨alt Informationen u ¨ber den Sessionkey und die IP-Adresse der allokierten VM, die benutzt werden, um u ¨ber die Klasse TaskClientPipeline eine Verbindung zur VM aufzubauen und die Taskverarbeitung zu beginnen. Ein Beispiel der Verwendung der bereitgestellten Bibliotheken zur Berechnung von Cloud-Optionen (benutzerterminierte Applikation) und zur Instanziierung einer VM ist nachfolgend gegeben. Dabei werden f¨ ur den in Abschnitt 7.3.3 bereits genannten PicTask, dessen Taskfunktion ein einzelnes Bild verarbeitet, m¨ogliche CloudOptionen berechnet. Als Eingabegr¨ oße f¨ ur die Laufzeitapproximation dient die Bildaufl¨osung imageres. Die verf¨ ugbare Netzwerkbandbreite wurde bereits ermittelt und ist als Variable bw verf¨ ugbar. Die Variable currentFramerate beschreibt die Taskverarbeitungsrate, die lokal auf dem Ger¨ at ohne Cloud-Unterst¨ utzung gemessen wurde. // J a v a Code B e i s p i e l String selectedtask = " PicTask " ; // int imageres [] = {640 ∗ 480}; // int imagesize = jpegpic . getData (). length ; // float f_mobil = c u r r e n t F r a m e r a t e ; //

Taskname Bildauflösung für Laufzeitvorhersage Bildgröße für die Transferzeitvorhersage a k t u e l l e frames per second ( f p s )

// E r r e i c h b a r e K o m m u n i k a t i o n s r a t e a u s B i l d g r ö ß e und B a n d b r e i t e bestimmen float f_comm = 1.0 f / ferb . common . NetworkHelper . c a l c u l a t e T r a n s m i s s i o n T i m e ( imagesize , bw ); // Cloud−O p t i o n e n v i a SOAPClient bestimmen l a s s e n ferb . common . CloudOption [] cs = ferb . common . SOAPClient . c a l c u l a t e M C m u l t i ( user , pass , " PIPE " , selectedtask , imageres , f_comm , f_mobil , imagesize ); if ( cs == null ) return ; // F a l l s d i e e n t f e r n t e A u s f ü h r u n g n i c h t r a t s a m wäre // Cloud−O p t i o n 0 z u r D e m o n s t r a t i o n a u s w ä h l e n ferb . common . CloudOption chosen = cs [0]; // Cloud−R e s s o u r c e v i a SOAPClient von B r o k e r a n f o r d e r n und g ü l t i g e S e s s i o n e r h a l t e n ferb . common . CloudSession session = ferb . common . SOAPClient . g e t I n s t a n c e F o r T y p e ( " PIPE " , chosen . type , user , pass ); // Aufbau d e r V e r b i n d u n g z u r Cloud−R e s s o u r c e m i t d e r e r h a l t e n e n S e s s i o n ferb . pipe . T a s k C l i e n t P i p e l i n e tcp = new ferb . pipe . T a s k C l i e n t P i p e l i n e (); tcp . connect ( session . session_key , session . endpoint , 8080);

148

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen In diesem Kapitel werden ausgew¨ ahlte Applikationen vorgestellt, die unter Verwendung der vorgestellten Middleware in Mobile Cloud-unterst¨ utzte Anwendungen transformiert wurden. Ziel ist die Demonstration der Anwendbarkeit der entwickelten Middleware f¨ ur die in Kapitel 6.1.1 beschriebenen Applikationstypen (eingabeterminiert und benutzerterminiert). Zudem werden anhand der Beispielapplikationen auch verschiedene Parameter bestimmt, die eine Einordnung der Leistungsf¨ ahigkeit der Middleware erlauben. Hierzu z¨ahlt insbesondere die G¨ ute der vorhergesagten Ausf¨ uhrungszeit. Zun¨achst werden synthetische Applikationen untersucht. Dabei wird analysiert, wie die Vorhersage der Ausf¨ uhrungszeit f¨ ur definierte Szenarien, die nicht via Regression bestimmt wurden, funktioniert. Außerdem werden anhand synthetischer Applikationen weitere Metaparameter gemessen wie die Installationszeit f¨ ur Taskfunktionen und die Gesamtallokationszeit f¨ ur VM-Ressourcen bis zur Verarbeitung des ersten Tasks. Anschließend wird die G¨ ute der Vorhersage der Ausf¨ uhrungszeit f¨ ur eine angepasste Version einer Raytracing-Software zur Berechnung fotorealistischer Bilder untersucht, die als Modul in einem 3D-Hausdesigner eingesetzt wird. Dabei handelt es sich um eine eingabeterminierte Applikation. Eine benutzerterminierte Applikation f¨ ur Android -Ger¨ate demonstriert danach die Anwendung der entwickelten Middleware bei der Verarbeitung von Kamerabildern. F¨ ur alle getesteten Applikationen wurde eine experimentelle Testinstallation der vorgestellten Middleware auf der Amazon EC2 Infrastruktur im Rechenzentrum in Irland benutzt (siehe Kapitel 2.3.2).

8.1 Synthetische Applikationen Einige synthetische Applikationen wurden implementiert, um die Leistungsf¨ahigkeit der Middleware zu untersuchen. Dabei war zun¨achst von Interesse, wieviel Zeitoverhead bis zur Bearbeitung des ersten wirklichen Tasks zu erwarten ist. Außerdem wurde untersucht, wie gut die vorhergesagte Performance der Cloud-Optionen f¨ ur definierte Tasks mit der tats¨achlich erreichten Performance u ur die Messungen in diesem Kapitel wurden erneut die ¨bereinstimmt. F¨ Netzwerkkonfigurationen und Testger¨ate genutzt, die bereits in Kapitel 4 verwendet wurden. Die Netzwerkkonfigurationen umfassen zwei WLAN-Konfigurationen und eine Mobilfunkkonfiguration (siehe Tabelle 4.1). Zu den Testger¨aten z¨ahlen zwei Android -Ger¨ate und zwei Laptops, deren Eigenschaften in Anhang A zusammengefasst sind.

8.1.1 Bereitstellungszeit von VM-Ressourcen und Code-Offloading Die Bereitstellungszeit einer Ressource umfasst die Schritte Allokieren der VM durch den ¨ ” Broker “ und Aufbau der Verbindung zur VM und Ubermitteln des Sessionkey“ (sie” he Kapitel 5.2.4). Bei beiden Schritten ist Netzwerkkommunikation notwendig. Da jedoch nur wenige Daten u ¨bermittelt werden, u ¨berwiegt hier der Einfluss der Netzwerklatenz. Die

149

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Zeit in ms

Allokationszeit für eine bereits gestartete VM 1500 1400 1300 1200 1100 1000 900 800 700 600 500 400

Quartile

Abbildung 8.1: Gemessene Allokationszeiten f¨ ur VM-Instanzen unter Verwendung der entwickelten Middleware.

Tabelle 8.1:

Laufzeit (∆tinstall ) elementarer, von der Middleware bereitgestellter, Tasks auf verschiedenen VM-Typen in ms

Taskart

Install/ Compile (msg sizeinstall ) (10 kB) m1.small ∅ 1400 σ 2031 c1.medium ∅ 1869 σ 1317 c1.xlarge ∅ 2336 σ 2239 σ = Standardabweichung ∅ = Mittelwert

Install/ Compile (34 kB) 3708 4228 1794 2522 2859 2748

CopySource (496 kB) 950 421 423 175 618 138

Allokation einer bereits gestarteten VM u ¨ber die Broker-API-Methode getInstanceForType(...) wird u ¨ber ein SOAP Web Service Interface abgewickelt. Dabei ist im Gegensatz zum Aufbau einer verschl¨ usselten TCP-Socket-Verbindung mit zus¨atzlichem Overhead f¨ ur die XML-Codierung zu rechnen. Abbildung 8.1 stellt die Verteilung der Allokationszeiten f¨ ur eine Reihe solcher Anfragen an den Broker dar. Die Anfragen wurden von einem Dell Streak 7 Android Tablet in allen drei Netzwerkkonfigurationen gestellt und umfassten 176 Allokationsvorg¨ ange f¨ ur die drei VM-Typen m1.small, c1.medium und c1.xlarge. Dargestellt sind die Quartile der Verteilung (Min, Max, Median sowie das 25 %- und 75 %-Quartil). F¨ ur die Bereitstellung der VM ist demnach mit einem Wert von mindestens ca. 450 ms bis ca. 1400 ms zu rechnen. Anschließend wird unter Verwendung des vom Broker zur¨ uckgelieferten Sessionkey eine Verbindung zur VM aufgebaut. Dieser Aufbau einer verschl¨ usselten Socket-Verbindung zur VM entspricht dem Experiment aus Kapitel 4.2.2, dessen Ergebnisse in Abbildung 4.9 dargestellt sind. Es wurde festgestellt, dass f¨ ur diesen Verbindungsaufbau auch ca. 400 ms bis 1100 ms, je nach Kommunikationstechnologie und Konfiguration, zu erwarten sind. Somit vergehen bis zum Beginn der ersten Task¨ ubertragung zwischen 950 ms und 2500 ms, wobei die Messungen auch starke Ausreißer enthalten und in mindestens 75 % der F¨alle mit einer Dauer bis ca. 1500 ms gerechnet werden kann. Hierbei wurde jedoch nicht beachtet, dass die Allokation einer freien VM durch den Broker auch erheblich mehr Zeit in Anspruch nehmen kann, wenn diese erst noch gestartet werden muss, wie in Kapitel 5.4 durch Simulation untersucht wurde. Vor der Bearbeitung benutzerdefinierter Tasks m¨ ussen die entsprechenden Taskklassen zun¨achst via InstallTask auf der VM installiert werden. Hierf¨ ur wird weitere Zeit ben¨otigt. Analog kann auch ein CopySourceTask verwendet werden, um bereits vorkompilierte Java Class-Dateien zur VM zu u ¨bertragen. Bei InstallTask und CopySourceTask handelt es sich um elementare, also durch die Middleware bereitgestellte, Klassen (siehe Kapitel 7.3.2). F¨ ur ¨ beide Arten der Codeinstallation wird sowohl Ubertragungszeit als auch Ausf¨ uhrungszeit ¨ auf der VM ben¨ otigt. F¨ ur die Ubertragungszeit sind die in Kapitel 4.4 erarbeiteten Vorhersagemethoden zu nutzen. Die reinen Ausf¨ uhrungszeiten verschiedener elementarer Tasks auf drei verschiedenen VM-Typen sind in Tabelle 8.1 zusammengefasst. Die Werte stammen von Messungen der in den nachfolgenden Abschnitten vorgestellten Applikationen. Der Copy-

150

8.1 Synthetische Applikationen

SourceTask ist f¨ ur die Installation des Programmcodes der Raytracing-Applikation zust¨andig. Die beiden InstallTask erledigen die Installation des Quellcodes der Bildverarbeitungstasks der Android -Applikation. F¨ ur die Ausf¨ uhrungszeiten der InstallTasks ist kein Muster zu erkennen. Sie schwanken sehr stark. Es kann jedoch davon ausgegangen werden, dass die durchschnittliche Ausf¨ uhrungszeit nicht mehr betr¨agt als 4 s. Ein Erkl¨arung f¨ ur die starken Schwankungen ist darin zu suchen, dass beim Kompilieren viele ben¨otigte Bibliotheken von der virtuellen Festplatte der VM-Instanz gelesen werden m¨ ussen. Wie in Kapitel 6.3.3 analysiert wurde, sind bei I/O-intensiven Aufgaben f¨ ur VMs besonders hohe Schwankungen zu erwarten. Etwas anders verh¨ alt es sich f¨ ur den CopySourceTask. Dessen mittlere Verarbeitungsdauer und Standardabweichung der Messwerte ist wesentlich geringer. F¨ ur die Werte in Tabelle 8.1 wurden zwischen 57 und 333 verschiedene Messwerte pro Taskart und VM-Typ ausgewertet. F¨ ur den CompileTask sind keine Ergebnisse abgebildet. Dieser entspricht von seinem Verhalten bis auf das anf¨ angliche Speichern der Quellcodedatei aber einem InstallTask. Das Speichern ben¨ otigt jedoch nur wenige Millisekunden. Somit ist f¨ ur beide Taskarten bei gleicher Quellcodemenge etwa das gleiche Verhalten und somit auch die gleiche Laufzeit zu erwarten. Eine Abh¨ angigkeit zwischen der Gr¨oße der u ¨bergebenen Daten und der Tasklaufzeit wurde hier nicht analysiert, da nur maximal zwei verschiedene Eingabegr¨oßen zur Verf¨ ugung standen und die Schwankung sehr hoch war. Als Ergebnis der Untersuchungen kann dennoch festgehalten werden, dass es wesentlich schneller geht, vorkompilierte Klassendateien zu installieren und dass diese Art der Codeinstallation zu bevorzugen ist. ¨ Insgesamt setzt sich die Zeit bis zur ersten Ubertragung eines Anwendungstasks f¨ ur die getesteten Applikationen aus der Allokationszeit f¨ ur die VM von ca. 1,5 s und der Zeit f¨ ur ¨ die Ubertragung und Installation des Codes zusammen. Daf¨ ur fallen ca. 4 s f¨ ur die Quellcodeinstallation und f¨ ur die Programmcodeinstallation sind nur ca. 0,5–1 s zu erwarten (siehe Tabelle 8.1). Gem¨ aß der geringeren Datengr¨oße fallen bei 2 Mbit/s Upload maximal 0,5 s f¨ ur die Daten¨ ubertragung der Quellcodedatei an. F¨ ur den umfangreicheren Programmcode wer¨ den jedoch ca. 2 s an Ubertragungszeit erwartet. Somit ergeben sich bei Quellcodeinstallation insgesamt ca. 6 s Wartezeit bis zur ersten Taskausf¨ uhrung. Verwendet man vorkompilierten Programmcode, ist mit einer Wartezeit von ca. 4–4,5 s zu rechnen.

8.1.2 Laufzeitvorhersage f¨ ur synthetische benutzerterminierte Applikationen In diesem Abschnitt wird untersucht, wie gut die Vorhersage der Laufzeit tats¨achlich ist, wenn alle Tasks exakt die gleich Taskfunktion ausf¨ uhren. Dazu wurde als Taskfunktion eine Z¨ahlschleife verwendet, die unabh¨ angig von der Eingabe immer die gleichen Arbeitsschritte ausf¨ uhrt und damit einen CPU-Kern der VM-Instanz g¨anzlich beansprucht. Zudem wird ¨ die Gr¨oße der Ubertragungsdaten exakt festgelegt. Laufzeitschwankungen durch verschiedene Eingaben und dadurch auch unterschiedlich aufwendige Taskfunktionen werden somit ausgeschlossen. Etwaige dennoch messbare Schwankungen k¨onnen nur durch die Middleware selbst, durch die verwendeten VM-Instanzen oder die verwendete Kommunikationstechnologie verursacht werden. F¨ ur die Untersuchungen werden drei VM-Typen aus dem Portfolio von Amazon EC2 benutzt, die in ihrer Performance um ca. den Faktor 4 verschieden sind: m1.small, c1.medium und c1.xlarge. Dass diese Auswahl f¨ ur gut abgegrenzte Vorschl¨age von Cloud-Optionen sinnvoll ist, wurde in Kapitel 6.2.5 erl¨autert. F¨ ur benutzerterminierte Applikationen kann aufgrund der unzureichend bekannten Eingabe nur eine Verarbeitungsrate f¨ ur gleichbleibende Taskfunktionen und schwankungsarme Ein-/Ausgabedaten gemessen werden. Die Taskverarbeitungsrate wird durch die maximal

151

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Tabelle 8.2: Abweichung der Vorhersage f¨ ur synthetische benutzerterminierte Applikationen in % (Taskrate fwork = 1.0 konstant) Datengr¨ oße in kB → m1.small ∆twork ≈ 1 s c1.medium ∆twork ≈ 2, 5 s c1.xlarge ∆twork ≈ 10 s

0 0,81

UMTS 10 50 1,37 0,76

100 0,35

0 0,62

HOME 10 50 1,77 0,09

100 0,90

0 1,15

CAMPUS 10 50 4,42 6,37

100 8,77

0,13

3,14

8,84

1,08

2,43

0,86

0,15

0,24

0,87

0,87

0,87

0,87

2,28

6,20

5,55

7,90

3,26

1,29

3,24

8,34

1,82

0,57

2,91

7,00

m¨ogliche Taskverarbeitungsrate auf der VM (fwork ) und durch die Kommunikationsrate fcomm begrenzt, die durch die Gr¨ oße der Ein-/Ausgabedaten pro Task und die Netzwerkperformance gegeben ist (siehe Kapitel 6.1.3, insbesondere Bedingung (6.7)). Der Vorhersagewert entspricht demnach dem Minimum aus fwork und fcomm . Zun¨achst wird untersucht, welche Abweichung von der Vorhersage f¨ ur eine Taskrate fwork von ca. 1,0 gemessen werden kann. Es wurde daf¨ ur Sorge getragen, dass fcomm stets gr¨oßer war als fwork , um eine Beeinflussung durch die Netzwerkperformance f¨ ur diesen Test zu vermeiden. Als Taskfunktion wurde eine Z¨ahlschleife verwendet, deren Anzahl von Schleifendurchl¨aufen auf einer m1.small-Instanz so geeicht wurde, dass die L¨ange der Tasklaufzeit ∆twork ca. 1 s betr¨ agt. Hierbei wurden einige Schleifendurchl¨aufe abgewartet, bis durch den JIT-Compiler vorgenommene Optimierungen abgeschlossen waren und eine stabile Tasklaufzeit erreicht wurde. Bei einem CPU-Kern ergibt sich somit eine Taskverarbeitungsrate von ca. 1,0. Durch eine auf dem Dell Streak 7 Android Tablet installierte Testapplikation, wurden dann fortw¨ ahrend Tasks zur VM-Instanz u ur die perfor¨bertragen. Um die Taskrate auch f¨ manteren Instanzen bei ca. 1,0 zu belassen, wurden die Durchl¨aufe der Z¨ahlschl¨afe auf diesen Instanzen mit dem Faktor des Performanceunterschieds zur m1.small-Instanz multipliziert. Als Maß wurde die ECU-Bewertung durch Amazon EC2 benutzt. Die m1.small-Instanz hat 1 ECU, die c1.medium hat beispielsweise 5 ECU. Somit wurde die Z¨ahlschleife mit dem Faktor 5 multipliziert. Dies f¨ uhrte im Ergebnis tats¨achlich zu einer etwa gleichen Taskrate auf allen VM-Typen. Die erreichte Tasklaufzeit wurde f¨ ur jede Instanz trotzdem noch einmal separat u uft und gegebenenfalls leicht angepasst. F¨ ur die drei Netzwerkkonfigurationen ¨berpr¨ HOME, CAMPUS und UMTS und verschiedene Gr¨oßen von Ein-/Ausgabedaten der einzelnen Tasks wurde anschließend die Abweichung der gemessenen Taskrate von der Vorhersage bestimmt. Die Ergebnisse sind in Tabelle 8.2 dargestellt. Dabei wurde pro Wert jeweils nur eine Messung u uhrt. Ein wirklicher Benut¨ber einen Zeitraum von mindestens 30 s durchgef¨ zer w¨ urde die Applikation vermutlich auch nur einmal ausf¨ uhren. Dargestellt ist jeweils die Abweichung der durchschnittlich erreichten Taskverarbeitungsrate im gemessenen Zeitraum vom vorhergesagten Wert. Die Netzwerkperformance limitierte die erreichbare Taskrate hier nicht. Auch f¨ ur 100 kB Ein-/Ausgabedaten war in allen drei Konfigurationen die m¨ogliche Kommunikationsrate h¨ oher. Die Ergebnisse zeigen, dass die Abweichung f¨ ur alle Messungen sehr gering sind. Zudem l¨asst sich an den Messungen auch erkennen, dass die f¨ ur die Taskverarbeitung notwendigen Daten¨ ubertragungen ohne merkliche Auswirkung auf die tats¨achliche Verarbeitungszeit der Tasks auf der VM im Hintergrund durchgef¨ uhrt werden. Zudem war die Performance der getesteten VM-Instanzen u ¨ber den gesamten Messzeitraum von mehreren Stunden stabil.

152

8.1 Synthetische Applikationen

Tabelle 8.3: Abweichung der Vorhersage f¨ ur synthetische benutzerterminierte Applikationen in % (Programmcode des Tasks konstant → fwork variabel) Datengr¨ oße in kB → fwork c1.medium fcomm ∆twork ≈ fmess 500 ms ∆ in % fwork c1.xlarge fcomm ∆twork ≈ fmess 800 ms ∆ in %  Abweichung > 20 %

0 3,97 ∞ 3,88 2,16 10,00 ∞ 9,55 4,46

UMTS 10 50 3,97 3,97 22,40 4,48 3,86 3,77 2,75 4,93 10,00 10,00 22,4 4,48 9,26 4,08 7,37 9,01

100 3,97 2,56 3,70 44,71 10,00 2,56 2,36 7,70

0 3,97 ∞ 3,90 1,78 10,00 ∞ 9,89 1,11

HOME 10 50 3,97 3,97 14,72 2,94 4,12 3,47 3,78 17,71 10,00 10,00 14,72 2,94 9,85 4,25 1,46 44,40

100 3,97 1,47 1,84 25,18 10,00 1,47 2,14 45,06

0 3,97 ∞ 3,39 14,55 10,00 ∞ 8,62 13,82

CAMPUS 10 50 3,97 3,97 35,84 7,17 3,42 3,54 13,93 10,76 10,00 10,00 35,84 7,17 9,71 8,04 2,92 12,13

100 3,97 3,58 3,33 7,02 10,00 3,58 3,17 11,57

In einem zweiten Szenario wurde im Gegensatz zum bereits beschriebenen Test die Taskfunktion auf allen Instanzen nicht ver¨ andert. Es wurde die Variante benutzt, die auf einer m1.smallInstanz eine Ausf¨ uhrungszeit von ca. 1 s ben¨otigt. Dies f¨ uhrt dazu, dass die Taskfunktion auf den c1.medium- und c1.xlarge-Instanzen nicht nur schneller bearbeitet wird, sondern aufgrund der h¨ oheren CPU-Kernanzahl auch mehr Tasks parallel verarbeitet werden k¨onnen. Somit steigt die Taskverarbeitungsrate gegen¨ uber m1.small teils erheblich an. Daf¨ ur kann in diesem zweiten Szenario die Netzwerkperformance nicht mehr vernachl¨assigt werden. Die messbare Taskverarbeitungsrate fmess wird begrenzt durch das Minimum aus der maximal m¨oglichen Taskverarbeitungsrate auf der VM (fwork ) und durch die Kommunikationsrate fcomm . Tabelle 8.3 stellt die Ergebnisse der Messungen dar. Auch hier wurde jede Messung einmal f¨ ur eine Dauer von mindestens 30 s durchgef¨ uhrt. Zus¨atzlich zur durchschnittlich erreichten Taskrate fmess sind noch fwork , fcomm und die Abweichung von der Vorhersage angegeben. F¨ ur die m1.small-Instanz entsprechen die Messungen den gleichen Werten wie in Tabelle 8.2, weshalb sie nicht noch einmal dargestellt sind. Es weichen nur 4 Werte der 36 Messungen (ca. 11 %) um mehr als 20 % von der Vorhersage ab. Dabei ist der Grund f¨ ur die starke Abweichung stets die falsch eingesch¨atzte Netzwerkperformance. Keiner der Messwerte weicht um mehr als 50 % ab, wodurch das G¨ uterkriterium KQgut erf¨ ullt ist. Mehr als zwei Drittel aller Werte weicht sogar nur um weniger als 10 % von der Sch¨ atzung ab. In der Zusammenfassung kann davon ausgegangen werden, dass die Taskverarbeitungsrate sich sehr gut vorhersagen l¨asst, wenn die Netzwerkperformance als limitierender Faktor keine Rolle spielt, wenn die Tasks also nur wenige Ein-/Ausgabedaten haben oder die Tasklaufzeiten recht hoch sind. Limitiert jedoch die Netzwerkperformance die Taskverarbeitungsrate, so wird die Vorhersage etwas ungenauer. Im Allgemeinen sollte es jedoch vermieden werden, dass die Taskverarbeitungsrate durch die Netzwerkperformance limitiert wird, da dadurch auch der Kostenoverhead durch eine schlecht ausgelastete VMInstanz steigt. Somit relativiert sich die teils ungenaue Vorhersage in diesem Bereich. Eine Restriktion des entwickelten Verfahrens l¨asst sich im Vergleich der Tabellen 8.2 und 8.3 erkennen. Die Messungen wurden an unterschiedlichen Tagen gemacht. Dabei wurden f¨ ur beide Messreihen offensichtlich verschieden schnelle VM-Instanzen der Typen c1.xlarge und c1.medium zur¨ uckgeliefert. Es wurden jeweils mehrere Instanzen angefordert. In Tabelle 8.2 zeigt die c1.xlarge-Instanz eine vierfach h¨ohere Performance als die c1.medium-Instanz, was der um viermal h¨ oheren CPU-Keranzahl entspricht. In Tabelle 8.3 betr¨agt der Unterschied f¨ ur die Messungen ohne Datentransfer hingegen nur 2,5. Dass es Perioden gr¨oßerer Schwankungen gibt, wurde in Kapitel 6.3.3 bereits erl¨autert. Um diesen l¨angerfristigen Schwankungen entgegenzuwirken, m¨ ussten die Profile f¨ ur die Laufzeitvorhersage h¨aufiger aktualisiert werden. Im hier beschriebenen Fall wurden f¨ ur beide Tage jeweils neue Profile erstellt.

153

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Tabelle 8.4: Abweichung der Vorhersage f¨ ur synthetische eingabeterminierte Applikationen in % Datengr¨ oße ↓ ∆twork → 0,2 MB m1.small 12 MB 60 MB 0,2 MB c1.medium 12 MB 60 MB 0,2 MB c1.xlarge 12 MB 60 MB  Abweichung > 20 %

CAMPUS (7 Mbit/s) 10 s 60 s 5 min 3,06 4,96 2,32 6,17 4,12 6,83 15,39 9,32 10,23 0,51 1,97 13,35 12,61 1,58 3,03 0,29 16,74 0,57 4,44 4,82 4,40 15,98 10,05 3,44 19,72 14,17 12,65

HOME (3 Mbits/s) 10 s 60 s 5 min 14,71 16,31 0,66 17,44 5,11 10,20 28,01 17,61 6,60 1,16 1,78 2,03 17,10 11,89 2,92 26,02 14,87 11,62 1,04 1,06 16,14 26,20 8,96 8,79 24,76 22,87 3,27

UMTS 10 s 13,65 10,21 10,02 48,46 14,37 0,24 15,45 18,12 11,11

(4,5 Mbit/s) 60 s 5 min 5,92 3,76 2,20 0,27 12,86 5,83 14,57 11,98 8,23 9,94 8,94 1,64 10,26 3,52 1,71 7,18 18,42 17,75

8.1.3 Laufzeitvorhersage f¨ ur synthetische eingabeterminierte Applikationen Die Taskfunktion zur Generierung einer synthetischen Last auf den VM-Instanzen wurde f¨ ur die eingabeterminierte Applikation so ver¨andert, dass die Z¨ahlschleife, die schon f¨ ur die Einzelprozessortasks der benutzerterminierten Applikation benutzt wurde, nun l¨anger und gegebenenfalls von mehreren Threads gleichzeitig abgearbeitet wird. Dabei werden jeweils so viele Threads verwendet, wie CPU-Kerne zur Verf¨ ugung stehen. Somit wird stets genau ein sogenannter Multiprozessortask ausgef¨ uhrt. Es ergibt sich eine gleichbleibende Abfolge von Arbeitsschritten, die jede VM-Instanz vollst¨andig beansprucht und auf jeder Instanz eines VM-Typs in etwa die gleiche Bearbeitungsdauer ben¨otigt. Zur Bestimmung der G¨ ute der Vorhersage wurden jeweils einzelne Tasks verschiedener Konfigurationen abgesetzt und deren Gesamtbearbeitungsdauer gemessen. Diese besteht bei ¨ eingabeterminierten Applikationen aus der Summe der Ubertragungsdauer der Daten und der tats¨achlichen Bearbeitungszeit auf der VM (siehe Kapitel 6.1.3). F¨ ur den Test wurden alle Kombinationen aus Verarbeitungszeit und Datengr¨oße benutzt, die bereits in Kapitel 5.4.6 zur Analyse der Daten¨ ubertragungskosten verwendet wurden. Als Verarbeitungszeiten ∆twork wurden 10 s, 60 s und 5 min gew¨ ahlt. Als Daten¨ ubertragungsgr¨oßen wurden 200 kB, 12 MB und 60 MB gew¨ ahlt. Die Daten wurden f¨ ur jede Messung zun¨achst zur VM u ¨bertragen und nach Berarbeitung der Taskfunktion wieder zur¨ uck transferiert. Jede einzelne Messung wurde genau einmal durchgef¨ uhrt auf den drei konfigurierten VM-Typen m1.small, c1.medium und c1.xlarge und den drei Netzwerkkonfigurationen HOME, UMTS und CAMPUS. Als Testger¨at wurde der Dell Latitude Laptop verwendet. F¨ ur jede VM-Instanz wurde zun¨achst die Z¨ahlfunktion passend geeicht, sodass sie die gew¨ unschte Tasklaufzeit realisiert. Vor jedem Test wurde dann die verf¨ ugbare Bandbreite ermittelt und entsprechend zur Vorhersage benutzt. Tabelle 8.4 fasst die Abweichungen der gemessenen Werte von der Vorhersage f¨ ur alle 81 Messungen zusammen. Nur 6 Messungen (ca. 7 %) wichen um mehr als 20 % von der Sch¨atzung ab. F¨ ur die HOME¨ Konfiguration war es aufgrund der asynchronen Ubertragungsrate f¨ ur Upload und Download schwierig, die tats¨ achlich nutzbare Bandbreite abzusch¨atzen. Deshalb traten hier vermehrt hohe Abweichungen auf, wenn die Taskausf¨ uhrungszeit gering und die Datengr¨oße hoch war. In der UMTS- und CAMPUS-Konfiguration waren Upload und Download nur leicht ver-

154

8.2 Raytracing

schieden, wodurch sich gleichm¨ aßigere Abweichungen ergaben. In der UMTS-Konfiguration war eine starke Abweichung festzustellen, die auf eine kurzzeitig stark verlangsamte Ausf¨ uhrungsgeschwindigkeit der VM-Instanz zur¨ uckzuf¨ uhren war. Im Allgemeinen ist die Vorhersage jedoch auch f¨ ur diese Art Applikationen sehr gut. Kein Messwert wich um mehr als 50 % von der Vorhersage ab.

8.1.4 Zusammenfassung synthetische Applikationen Getestet wurde die Verl¨ asslichkeit der Vorhersage f¨ ur Applikationen, die im Verhalten selbst nicht schwanken, deren ausgef¨ uhrte Verarbeitungsschritte also immer gleich sind. Etwaige Schwankungen der Ausf¨ uhrungszeit werden dann durch die Middleware und deren Komponenten selbst verursacht. Die gemessenen Abweichungen von der Vorhersage lagen sowohl f¨ ur eingabeterminierte als auch f¨ ur benutzerterminierte Applikationen in der u ¨berwiegenden Mehrzahl unter 20 %. Abweichungen sind fast immer auf die falsch eingesch¨atzte Netz¨ werkperformance zur¨ uckzuf¨ uhren. Dabei wurde die Ubertragungsrate h¨aufig zu pessimistisch eingesch¨ atzt. In einem Fall wurde jedoch auch ein kurzzeitiger Performanceeinbruch auf einer VM-Instanz registriert. Im Ergebnis ist festzuhalten, dass die Erstellung von Profilen zur Laufzeitvorhersage von Mobilen Cloud-unterst¨ utzten Anwendungen auf der entwickelten Middleware und im getesteten Rechenzentrum von Amazon EC2 von Zeit zu Zeit u uft ¨berpr¨ und erneuert werden muss. Es ist anzunehmen, dass dies auch f¨ ur andere IaaS-Anbieter gilt (siehe Kapitel 6.3.3).

8.2 Raytracing Die Software Sweethome 3D 1 ist ein quelloffener und in Java geschriebener 3D-Hausdesigner. Er erm¨oglicht die grafische Modellierung von Wohnungen und H¨ausern inklusive der Ausstattung mit M¨ obeln und Texturen. Abschließend kann die Szene aus verschiedenen Perspektiven (virtuell) durchschritten werden. Zus¨atzlich k¨onnen auch Bilder aus frei w¨ahlbaren Kamerablickwinkeln via Raytracing 2 gerendert werden. Dabei wird zum Rendern der Szene die ebenfalls quelloffene und in Java geschriebene Raytracing-Software Sunflow 3 verwendet. Die Visualisierung ist sehr zeitaufwendig. Sunflow unterst¨ utzt jedoch Multicore-Systeme und deshalb l¨asst sich die Renderinggeschwindigkeit auf solchen Systemen deutlich beschleunigen. Oft findet die Erstellung der Szenen beispielsweise vor Ort in einer Wohnung auf einem mobilen Ger¨at statt. Laptops und Netbooks haben u ¨blicherweise keine leistungsstarken Prozessoren eingebaut, um stattdessen eine hohe Akkulaufzeit zu erm¨oglichen. Das Erstellen fotorealistischer Bilder ist somit im mobilen Einsatz nur eingeschr¨ankt m¨oglich. Die Software Sweethome 3D wurde deshalb im Rahmen dieser Arbeit in eine Mobile Cloud-unterst¨ utzte Anwendung transformiert. Dazu wurde die Rendering-Funktionalit¨at ausgelagert. Ein Screenshot der Applikation ist in Abbildung 8.2 zu sehen. Da die Eingabe f¨ ur das Rendering vollst¨andig bekannt ist, handelt es sich um eine eingabeterminierte Applikation (siehe Kapitel 6.1.1). Dass die Aufspaltung von Sunflow in eine verteilte Anwendung durch Auslagerung des Renderings auf 1

Verf¨ ugbar unter Onlineressource http://www.sweethome3d.com/de/index.jsp (abgerufen am 16.2.2014) Raytracing (Strahlverfolgung) ist ein wirkungsvolles, aber bez¨ uglich Rechenzeit und Speicherplatz aufw¨ an” diges Verfahren zur Berechnung fotorealistischer Bilder. [...] Das Prinzip besteht im Gegensatz zur physikalischen Natur darin, vom Betrachterstandpunkt aus Sichtstrahlen durch jedes Pixel zu schicken und den Weg derselben durch die Szene zu verfolgen.“ [OM04, S. 257ff.] 3 Verf¨ ugbar unter Onlineressource http://sunflow.sourceforge.net/ (abgerufen am 16.2.2014) 2

155

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Abbildung 8.2: Screenshot des 3D-Hausdesigners Sweethome 3D. Rechts ist zus¨atzlich das Fenster zur Erstellung des durch Raytracing gerenderten Bildes zu sehen. performante Serverressourcen zu guten Speedups f¨ uhren kann, wurde bereits in einer fr¨ uheren Arbeit [FRH10] gezeigt. Um die Leistungsf¨ ahigkeit des Raytracings zu bewerten und eine Vorhersagemethode der Ausf¨ uhrungszeit f¨ ur die bedarfsgerechte Nutzung zu realisieren, wurden 32 Beispielszenen von H¨ausern, Wohnungen, einzelnen Zimmern und G¨arten benutzt. Sie sind in Anhang E visualisiert. Um eine breit gef¨ acherte und realistische Stichprobe zu erhalten, wurden die Szenen aus verschiedenen Quellen zusammengestellt. Sieben Szenen stammen aus den offiziellen Beispielszenen zu Sweethome 3D. Vier weitere Szenen wurden selbst konstruiert und reflektieren Extremf¨alle, also sehr einfache oder sehr komplexe Szenen, wie beispielsweise mit vielen Gr¨ unpflanzen. Die restlichen 21 Szenen stammen von 20 weiteren Personen, die gebeten wurden, eine Szene zu kreieren. Diese Szenen reflektieren teils realistische Modellierungen und teils fiktionale. Es wurde darauf geachtet, dass die Szenen sinnvolle Bilder erzeugen. Beispielsweise w¨are es auch denkbar, die Kamera in Richtung Himmel oder auf eine weiße Wand zu richten. F¨ ur diese Szene w¨ urde dann jedoch die Ausf¨ uhrungszeit wesentlich k¨ urzer ausfallen und die zu entwickelnde Vorhersage eventuell verf¨alschen. F¨ ur die Bewertung der G¨ ute der Vorhersage wurden die 32 Szenen in 16 Trainingsszenen und 16 Testszenen unterteilt. Anhand der Trainingsszenen wurde das Profil zur Vorhersage generiert. Anhand der Testszenen wurde die G¨ ute der Vorhersage u uft. Die Trainingsszenen sind in Anhang E jeweils links ¨berpr¨ abgebildet.

8.2.1 Implementierung Sunflow wird innerhalb des Quellcodes von Sweethome 3D als Modul genutzt und alle Aufrufe werden u ¨ber die Klasse SunflowAPI realisiert. Die Transformation von Sweethome 3D in eine Mobile Cloud-unterst¨ utzte Anwendung erforderte zwei Schritte. Zun¨achst wurden die Aufrufe zur SunflowAPI in eine Variante zur entfernten Ausf¨ uhrung u uhrt. Dazu wurde die Klasse ¨berf¨ SunflowAPI mit einem Remote Object Interface versehen und damit f¨ ur Java RMI nutzbar

156

8.2 Raytracing

Client

VM

connect

CopySourceTask

prepareBucketRendering

startRendering

init

Sunflow

renderImage

Schleife for each Bucket

getNextBucket

disconnect()

Abbildung 8.3: Sequenzdiagramm des Ablaufs eines Renderings.

gemacht. Das resultierende neue Interface der SunflowAPI konnte durch die in Kapitel 7.3.3 beschriebene Methode in eine Task-Pipelining-kompatible Variante transformiert werden. Als Ergebnis ist die Ausf¨ uhrung der Remote Object Aufrufe via synchroner Task-Verarbeitung m¨oglich. Somit ist Sweethome 3D als eingabeterminierte Applikation mit der entwickelten Middleware nutzbar. Obwohl Sunflow innerhalb des Quellcodes von Sweethome 3D bereits u ¨ber eine abgeschlossene API genutzt wird, konnten die einzelnen Methoden der Klasse SunflowAPI aufgrund der Komplexit¨ at der Parameter nicht direkt als entfernt aufrufbare Methoden ausgelagert werden. Einige Messungen mit verschiedenen Szenen ergaben, dass teilweise bis zu 100 MB an Parameterdaten u ¨ber das Interface u ¨bergeben werden, was im ausgelagerten Fall via (kabellosem) Netzwerk transferiert werden m¨ usste. Daraufhin wurde das Interface der SunflowAPI aufgeteilt in das Interface ISunflowRemoteAPI, das weiterhin die entfernt aufrufbaren Methoden enth¨alt, und eine Klasse SunflowSzene, die die Methoden der SunflowAPI zur Manipulation der eigentlichen Szene implementiert. Im Ergebnis werden so alle die Szene betreffenden Daten weiterhin zun¨ achst lokal abgespeichert. Erst wenn die Erstellung der Szene abgeschlos-

157

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

sen ist, wird diese u ¨ber das neue Interface ISunflowRemoteAPI zur entfernten Berechnung u bertragen. Dazu wird die Objektinstanz der Klasse SunflowSzene zun¨achst serialisiert und ¨ anschließend noch mit dem LZMA-Algorithmus komprimiert. Hierbei werden insgesamt nur wenige MB an Daten transferiert. Je nach Gr¨oße der Szene dauert in diesem Fall jedoch die Komprimierung einige Sekunden, was bei der Gesamtverarbeitungszeit zu ber¨ ucksichtigen ist. Das Remote Interface von Sunflow in Sweethome 3D ist nachfolgend dargestellt. // J a v a Code B e i s p i e l public interface I S u n f l o w R e m o t e A P I extends java . rmi . Remote { public Integer p r e p a r e B u c k e t R e n d e r i n g ( SunflowSzene scene ) throws R em o te Ex c ep ti o n ; public boolean sta rtRend ering () throws Re mo t eE x ce pt i on ; public ReadyBucket getNextBucket () throws R e mo te E xc ep t io n ; }

Das Interface ISunflowRemoteAPI enth¨alt zudem auch eine Optimierung, die der besse¨ ren Uberlagerung von Berechnungen und Datentransfers dient. Beim Raytracing wird jedes Pixel unabh¨ angig von den anderen berechnet. Somit ist es m¨oglich, bereits berechnete Pixel unverz¨ uglich zum Client zur¨ uckzusenden. Dadurch findet der teilweise R¨ ucktransport des gerenderten Bildes in einzelnen Kacheln (englisch Buckets) schon w¨ahrend der Berechnung statt. Dies spart Zeit, da am Ende nur noch ein geringer Teil des u ¨brigen Bildes u ¨bertragen werden muss und nicht mehr das Gesamtbild. Abbildung 8.3 visualisiert den Ablauf eines Renderings. Die Optimierung ist im Interface ISunflowRemoteAPI folgendermaßen implementiert. ¨ Die Funktion prepareBucketRendering(...) implementiert die beschriebene Ubertragung der Szene zur VM und liefert eine Zahl zur¨ uck. Diese Zahl gibt an, in wie viele Teile (Buckets) das Gesamtbild zur Berechnung zerlegt wurde. Die Funktion startRendering() startet den Rendering-Vorgang. Einzelne Buckets k¨onnen dann asynchron durch Aufruf der Methode getNextBucket() abgerufen werden. Die Anzahl der Aufrufe dieser Funktion korrespondiert mit der Anzahl Buckets, in die das Bild zerlegt wurde. Dabei enth¨alt das zur¨ uckgelieferte Objekt der Klasse ReadyBucket nicht nur das Teilbild selbst im PNG-Format4 , sondern auch dessen Abmaß und die Koordinaten der linken oberen Ecke des Teilbildes im Gesamtbild. Die Klasse SunflowRemoteTaskAPI implementiert das Interface ISunflowRemoteAPI und ist zus¨atzlich von der Klasse TaskClientPipeline abgeleitet. Somit wird auch der Lebenszyklus der Cloud-Nutzung durch SunflowRemoteTaskAPI verwaltet. Der Lebenszyklus ist ebenfalls in Abbildung 8.3 visualisiert. Dazu geh¨oren das Verbinden zu einer VM und das Installieren des ben¨ otigten Programmcodes. Da der Programmcode von Sunflow sehr umfangreich ist, wurde ein CopySourceTask gew¨ahlt, um diesen zu u ¨bertragen (siehe Kapitel 7.3.2). Die Kompilierung des Quellcodes auf Serverseite ist hier aufgrund der Menge des Codes nicht praktikabel. Das Kompilieren der 227 Quellcodedateien mit einer Gesamtgr¨oße von ca. 1,4 MB dauert auf einer Cloud-Ressource vom Typ c1.medium ca. 40 s. Das Auspacken der Kompilate wird hingegen in weniger als einer Sekunde beendet. Die durchschnittlichen Zeiten f¨ ur das Entpacken des 496 kB-Archivs sind in Tabelle 8.1 angegeben. 4

Portable Network Graphics (PNG [...], engl. portable Netzwerkgrafik) ist ein Grafikformat f¨ ur Rastergra” fiken mit verlustfreier Kompression. Es wurde als freier Ersatz f¨ ur das ¨ altere, bis zum Jahr 2006 mit Patentforderungen belastete Format GIF entworfen und ist weniger komplex als TIFF. PNG unterst¨ utzt neben unterschiedlichen Farbtiefen auch Transparenz per Alphakanal. PNG ist das meistverwendete verlustfreie Grafikformat im Internet.“ (Onlineressource http://de.wikipedia.org/wiki/Portable_Network_ Graphics(abgerufen am 5.11.2013))

158

8.2 Raytracing

0

CPU−Auslastung in %

c1.xlarge

m2.4xlarge

m2.2xlarge

200

m2.xlarge m1.xlarge

400

c1.medium

800 600

CPU−Auslastung über Zeitfortschritt 800

Netbook Laptop Cloud

m1.large

Ausführungszeit in s

1000

m1.small

Ausführungszeit von Sunflow auf Cloud Ressourcen 1200

700 600 500 c1.xlarge c1.medium

400 300 200 100 0

1

4 5 6,5 8 13 20 26 ECU−Rating (logarithmische Skalierung)

0

10

20

30

40 50 60 70 Zeitfortschritt in s

80

90

100

Abbildung 8.4: Renderingzeiten auf verschie- Abbildung 8.5: CPU-Auslastung auf verschiedenen Mobilger¨ aten im Verdenen VM-Typen und f¨ ur gleich zur Mobilen Cloudverschiedene Szenen. unterst¨ utzten Anwendung.

8.2.2 Rechenzeitbedarf Um zun¨ achst die Performanceverbesserung durch Auslagerung des Raytracings auf eine VM zu untersuchen, wurde eine Beispielszene aus dem Softwarepaket von Sunflow namens Aliens Shiny auf verschiedenen Ressourcen in der Aufl¨osung 640x480 gerendert (eine Abbildung der Beispielszene ist ebenfalls in Anhang E dargestellt). Dazu wurden je eine Variante eines 10”Netbooks und eines aktuellen 15”Laptops (siehe Anhang A) als Mobilger¨ate mit der Cloud-basierten Variante verglichen. Abbildung 8.4 visualisiert die Ausf¨ uhrungszeiten auf den Ressourcen. Die Cloud-basierte Variante wurde dabei auf dem Netbook in der Netzwerkkonfiguration HOME ausgef¨ uhrt. Es ist deutlich zu erkennen, dass gegen¨ uber der Ausf¨ uhrungszeit auf dem Netbook eine deutliche Beschleunigung durch die Mobile Cloud-unterst¨ utzte Anwendung erreicht werden kann. Dadurch l¨asst sich bei entsprechender Wahl des VM-Typs gegen¨ uber der lokalen Ausf¨ uhrung eine wesentlich geringere Ausf¨ uhrungszeit erreichen. Dies gilt insbesondere f¨ ur mobile Ger¨ ate mit geringer Prozessorperformance wie dem Netbook. F¨ ur aktuelle Laptops ist eventuell von Fall zu Fall zu entscheiden, ob eine entfernte Ausf¨ uhrung bevorzugt werden sollte. Da die Berechnung f¨ ur große Bilder (beispielsweise 1920x1080) mehrere Minuten dauert, kann jedoch durch die entfernte Ausf¨ uhrung auf dem Laptop Akkukapazit¨ at gespart werden, was sich bei einem Laptop aufgrund der relativ hohen Leistungsaufnahme unter Last besonders positiv auswirkt. Die entfernte Ausf¨ uhrung ist demnach, eine ausreichende Netzwerkperformance vorausgesetzt, f¨ ur große Bilder bez¨ uglich Ausf¨ uhrungszeit und Energieeinsparung fast immer sinnvoll. Abbildung 8.5 zeigt, dass die verf¨ ugbaren CPU-Kerne verschiedener VM-Instanzen gut ausgelastet werden k¨ onnen. Dargestellt ist jeweils die CPU-Auslastung f¨ ur ein komplettes Szenen¨ rendering, also Ubertragung und Vorverarbeitung der Szene (prepareBucketRendering(...)) sowie das Rendering selbst. Die vierfach h¨ohere CPU-Kernanzahl der c1.xlarge-Instanz kann ¨ w¨ahrend des Renderings gut genutzt werden. Zu erkennen ist auch, dass die Ubertragung zu Beginn unterschiedlich lang dauern kann, je nach Szenenkomplexit¨at. Hier sind verschiedene Szenen gerendert worden. Im Ergebnis ist es also g¨ unstig, unter Beachtung der zu erwartenden Kosten, m¨ oglichst performante VM-Typen zu w¨ahlen. Das beste Verh¨altnis aus Preis und Leistung bieten hier die c1.medium- und c1.xlarge-Instanztypen.

159

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

8.2.3 Hauptspeicherbedarf Der tats¨achliche Speicherbedarf ist in Java schwierig zu ermitteln, da er nicht nur von der Applikation und den Eingabedaten abh¨angt, sondern auch von den gew¨ahlten JVMStartparametern bez¨ uglich der Speicherobergrenze. Somit wurde hier ein anderer Weg gew¨ahlt. Aufgrund der Berechnungsperformance wurde der VM-Typ c1.medium als minimal m¨oglicher VM-Typ aus dem Portfolio von Amazon EC2 gew¨ahlt. Auf diesem und allen besser ausgestatteten VM-Typen sind mindestens 1,7 GB Arbeitsspeicher verf¨ ugbar. Um f¨ ur das auf der VM ausgef¨ uhrte Betriebssystem noch etwas Spielraum zu lassen, wurde der Speicher f¨ ur die JVM auf 1,4 GB festgesetzt. Die h¨ ochste sinnvolle Aufl¨osung wurde anhand des am Markt erh¨altlichen Monitors mit der h¨ ochsten Displayaufl¨osung (4096x2160) gew¨ahlt5 . Alle Beispielszenen konnten in dieser Aufl¨osung und mit der beschr¨ankten Speichermenge gerendert werden. Abschließend wird festgestellt, dass alle VM-Typen aus dem Portfolio von Amazon EC2 bez¨ uglich des Hauptspeicherbedarfs genutzt werden k¨onnen, solange sie wenigstens 1,7 GB Arbeitsspeicher zur Verf¨ ugung stellen. F¨ ur die weiteren Betrachtungen werden demnach die bez¨ uglich Rechengeschwindigkeit g¨ unstigen VM-Typen c1.medium und c1.xlarge benutzt.

8.2.4 Konstruktion der Laufzeitfunktion zur Vorhersage Die eigentliche Schwierigkeit bei der Bereitstellung von Sweethome 3D als Mobile Cloudunterst¨ utzte Anwendung ist die Prognose der Verarbeitungszeit einer gegebenen Szene auf verschiedenen Cloud-Ressourcen. Hierzu muss eine aussagekr¨aftige Laufzeitfunktion lauf (...) gefunden werden, die aufgrund von Metadaten u ¨ber die Szene eine Verarbeitungszeit sch¨atzen kann. Dazu wird zun¨ achst f¨ ur die einzelnen Methoden des entfernten Interfaces ISunflowRemoteAPI erl¨ autert, aus welchen Teilen sich die Gesamtausf¨ uhrungszeit zusammensetzt. • prepareBucketRendering(...) u ¨bertr¨agt die relativ große Szene zur VM und liefert einen Integerwert zur¨ uck. Zudem ben¨otigt das Dekomprimieren, Deserialisieren und Vorverarbeiten der Szenendaten auf Serverseite Zeit. F¨ ur prepareBucketRendering(...) muss also eine Laufzeitfunktion lauf (...) erstellt werden, die auf Basis der Beschaffenheit der Szene die Ausf¨ uhrungszeit sch¨atzt. • startRendering() u agt nur einen Wahrheitswert und ben¨otigt auf Serverseite ¨bertr¨ auch kaum Berechnungszeit, da nur das Rendering gestartet wird. Somit ist startRendering() sowohl f¨ ur die Kommunikations- als auch f¨ ur die Ausf¨ uhrungszeit nicht interessant. • getNextBucket() wird h¨ aufig aufgerufen und u uck ¨bertr¨agt kleine Bildausschnitte zur¨ zum Client. getNextBucket() selbst ben¨otigt keine Berechnungszeit auf Serverseite. Jedoch findet parallel zur Bearbeitung das eigentliche Rendering statt. F¨ ur lauf (...) ist demnach von Bedeutung, wie lange das Rendering aufgrund der Beschaffenheit der Szene dauert. Zus¨ atzlich ist f¨ ur die Pixelanzahl des Ergebnisbildes die Gesamtdatenmenge zu bestimmen, um daraus die Kommunikationszeit abzusch¨atzen. Dabei kann davon ausgegangen werden, dass die Einzelbilder der Buckets zusammen nicht deutlich gr¨oßer sind als das Gesamtbild in PNG-Codierung. 5

Das Modell mit der h¨ ochsten Displayaufl¨ osung, welches in Deutschland verf¨ ugbar ist, ist ein Eizo DuraVision FDH3601 schwarz, 36.4 ”. Die Aufl¨ osung betr¨ agt 4096x2160 Bildpunkte. Bestimmt wurde das Modell unter allen auf http://geizhals.at/ am 8.11.2013 in der EU gelisteten Produkten in der Kategorie Monitor.

160

8.2 Raytracing

Ausführungszeit über Szenengröße 12000

Min Avg Max

0

Verarbeitungszeit in ms

Bildgröße in MB

PNG Bildgröße über Pixelanzahl 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0

0

1e

9e

8e

7e

6e

5e

8

7

+0

7

+0

7

+0

7

+0

7

+0

7

+0

7

+0

7

Pixelanzanzahl

+0

0

7

08

+0

20

x1

4e

20

3e

19

x7

2000

+0

0

80

4000

2e

12

48

6000

1e

0x

8000

0

64

c1.medium c1.xlarge c1.medium approx. c1.xlarge approx.

10000

Szenengröße in Bytes

Abbildung 8.6: Approximation der Gr¨oße ei- Abbildung 8.7: Ausf¨ uhrungszeit von prepanes PNG-Bildes. reBucketRendering(..) und Approximation. Zusammenfassend wird die Ausf¨ uhrungszeit maßgeblich durch die sequentielle Ausf¨ uhrung von prepareBucketRendering(...) und dem eigentlichen Rendering bestimmt. Die Kommunikationszeit setzt sich zusammen aus der Upload-Zeit f¨ ur die Szene und der Download-Zeit f¨ ur das gerenderte Bild. Die genaue Konstruktion der Approximationsmethoden wird nachfolgend durchgef¨ uhrt. Bekannt sind f¨ ur die Konstruktion von lauf (...) nur die Szenenparameter, die Szenengr¨ oße f¨ ur den Upload und die Pixelanzahl des zu erstellenden Bildes. Die Gr¨oße des resultierenden PNG-Bildes muss anhand der Pixelanzahl gesch¨atzt werden, da sie vor dem Rendering im Gegensatz zur Szenengr¨oße nicht bekannt ist. Die Gr¨oße ist zur Sch¨atzung der Downloadzeit relevant. Sch¨ atzung der Gr¨ oße von PNG-Bildern Abbildung 8.6 zeigt die Bildgr¨ oßen in kB f¨ ur die verschiedenen Beispielszenen und verschiedene Bildgr¨ oßen. Es existiert eine Schwankung, da die Gr¨oße auch stark vom Bildinhalt abh¨angt. Dargestellt sind jeweils die minimalen, maximalen und durchschnittlich gemessenen Werte von jeweils 11 Bildern in den Aufl¨osungen 640x480, 1280x720 und 1920x1080. Es wurden Bilder der sieben offiziellen Beispielszenen zu Sweethome 3D und der vier selbst konstruierten Szenen benutzt (siehe Anhang E). Aus der Abbildung l¨asst sich erkennen, dass die Bildgr¨oße linear mit der Pixelanzahl steigt. Dabei wurde f¨ ur die mittlere Bildgr¨oße via Regression ein Anstieg von 1,7 bestimmt. Daraus ergibt sich folgende Gleichung zur Berechnung f¨ ur eine Pixelanzahl #P ixel > 0. Bildgr¨ oße = #P ixel · 1, 7 + 9988.

(8.1)

Diese Berechnung wird genutzt, um anhand der Pixelanzahl die Gr¨oße des zu u ¨bertragenden fertigen PNG-Bildes zu sch¨ atzen. Die maximale Abweichung der Gr¨oße der 33 Testbilder von der jeweiligen Sch¨ atzung lag bei ca. 31 %. Sch¨ atzung der Ausf¨ uhrungsdauer f¨ ur prepareBucketRendering(...) F¨ ur die Bestimmung der Laufzeitfunktion lauf(...) ist es notwendig, einen sinnvollen Zusammenhang zwischen einer Eingabegr¨ oße und der Verarbeitungszeit zu finden.

161

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Die Ausf¨ uhrungszeit von prepareBucketRendering(...) h¨angt maßgeblich von der Komplexit¨at der Szene ab. Das heißt, es wird vermutet, dass die Ausf¨ uhrungszeit mit der Szenengr¨oße in Byte (eSzene ) korreliert. Abbildung 8.7 zeigt die gemessenen Werte der Ausf¨ uhrungszeit f¨ ur alle Trainingsszenen auf verschiedenen VM-Typen. Durch die gemessenen Werte wurde eine lineare Funktion laufpbr (. . . ) approximiert, die aus einer gegebenen Szenengr¨oße die zu erwartende Verarbeitungszeit des PrepareBucketRenderingTask auf Serverseite in Abh¨angigkeit der verwendeten Ressource R sch¨atzt. Die approximierten Laufzeitfunktionen f¨ ur die beiden VM-Typen haben folgende Gestalt: laufpbr (Rc1.medium , eSzene ) = eSzene · 0, 0000000775101 + 1, 540,

(8.2)

laufpbr (Rc1.xlarge , eSzene ) = eSzene · 0, 0000000922838 + 2, 048.

(8.3)

Dabei wurden f¨ ur das G¨ uteverh¨ altnis VQgut , welches die Prozentzahl von Messwerten beschreibt, die um maximal 50% von der Sch¨atzung abweichen, Werte zwischen 91–96 % bestimmt. Somit wird das G¨ utekriterium KQgut eingehalten (siehe Kapitel 6.2.4). Sch¨ atzung der Ausf¨ uhrungsdauer f¨ ur das Rendering Die Ausf¨ uhrungszeit des Raytracings wird maßgeblich von zwei Faktoren bestimmt: • der Beschaffenheit/Komplexit¨ at der Szene und • der Gr¨ oße (Pixelanzahl) des resultierenden Bildes. Zur Findung eines Zusammenhangs zwischen der Ausf¨ uhrungszeit und diesen Parametern muss eine multiple Regression durchgef¨ uhrt werden (siehe Kapitel 6.2.3). Bei der Analyse der eigentlichen Berechnung wurde vermutet, dass das Rendering sehr gut mit der Anzahl der zu berechnenden Pixel skaliert. Abbildung 8.8 (links oben) best¨atigt diesen Zusammenhang. Abgebildet ist die Renderingzeit f¨ ur jeweils die gleiche Szene unter Verwendung verschiedener Bildgr¨oßen. Schließlich musste f¨ ur die weitere Beschreibung der Laufzeitfunktion laufrender (...) noch ein weiterer Parameter gefunden werden, der eine Korrelation zwischen den Parametern einer Szene und der Ausf¨ uhrungszeit der Berechnung herstellt. Vor dem eigentlichen Rendering stehen nur begrenzt Informationen u ugung. Gemessen werden k¨on¨ber die Szene zur Verf¨ nen nur die Anzahl von Objekten (Instanzen), die Anzahl von Dreiecken (Primitive) und die Szenengr¨ oße im Arbeitsspeicher. Die Szenengr¨oße ber¨ ucksichtigt dabei auch Texturen. Abbildung 8.8 zeigt zwei der gemessenen Abh¨angigkeiten in Bezug zu verschiedenen Eingabegr¨oßen. Daf¨ ur wurden die Ausf¨ uhrungszeiten von 12 verschiedenen Szenen in der Aufl¨osung 640x480 bestimmt. Auch hier wurden daf¨ ur die sieben offiziellen Beispielszenen zu Sweethome 3D, die vier selbst erstellten Testszenen und zus¨atzlich noch die Szene extern21“ ” benutzt (siehe Anhang E). Daraus l¨ asst sich erkennen, dass eine direkte Korrelation kaum zu finden ist. Einzig eine Abh¨ angigkeit zwischen der Szenengr¨oße und der Ausf¨ uhrungszeit l¨asst sich vermuten. In Abbildung 8.8 ist zus¨atzlich die G¨ ute der Approximation in Form des Verh¨altnisses VQgut dargestellt. Die Szenengr¨oße liefert den besten Wert. Zur Anzahl Instanzen konnte kein Zusammenhang ermittelt werden (VQgut = 0), weshalb dieser auch nicht abgebildet ist. Da die Szenengr¨ oße (eSzene ) bereits zur Vorhersage der Ausf¨ uhrungszeit von prepareBucketRendering(...) benutzt wird, wurde abschließend festgelegt, dass diese ebenfalls f¨ ur laufrender (. . . ) benutzt wird. Um die Abh¨angigkeit der Ausf¨ uhrungszeit von der

162

8.2 Raytracing

Abhängigkeit Laufzeit/Primitive−Anzahl 600

Messwerte approx. Funktion

Verarbeitungszeit in s

Verarbeitungszeit in s

Ausführungszeit über Pixelanzahl 1000 900 800 700 600 500 400 300 200 100 0

Messwerte approx. Funktion

500 400 300 200 100 0

+0

2e

1. 6

+0

1e

6

00

00

80 00

00

60 00

00

40

6

6

6

6

00

00

20

0

6

+0

+0

2e

+0

8e

1.

+0

6e

1.

+0

4e

1.

6

+0

2e

1.

00

00

1e

00

00

80

00

00

00

60

40

00

20

0

Pixelanzahl

Anzahl Primitive

Abhängigkeit Laufzeit/Szenengröße

Verarbeitungszeit in s

600

Messwerte approx. Funktion

500

Qualit¨at der approximierten Funktion f¨ ur das Rendering unabh¨angige Variable VQgut Szenengr¨oße ca. 58 % Anzahl Primitive ca. 42 %

400 300 200 100 0

8

7

+0

1e

7

+0

9e

7

+0

8e

7

+0

7e

7

+0

6e

7

+0

5e

7

+0

4e

7

+0

3e

7

+0

+0

2e

1e

0

Szenengröße in Bytes

Abbildung 8.8: Visualisierung m¨ oglicher Korrelationen der Renderingzeit zu verschiedenen Eingabegr¨ oßen. (In der Abbildung oben links ist die Szene konstant, sonst wurden je 12 verschiedene Szenen in der Aufl¨osung 640x480 erstellt.)

Bildgr¨oße (#P ixel) und von der Szenengr¨oße (eSzene ) zu reflektieren, wird f¨ ur laufrender (. . . ) der Eingabeparameter eRender aus Szenengr¨oße und Pixelanzahl konstruiert:

eRender = (#P ixel, eSzene ).

(8.4)

Nach der Festlegung der Eingabegr¨oße f¨ ur die Laufzeitfunktion laufrender (...) wurden Messungen f¨ ur die konfigurierten VM-Typen durchgef¨ uhrt. Dazu wurden die 16 Trainingsszenen in zwei Aufl¨ osungen jeweils zweimal berechnet. F¨ ur c1.medium wurden die Aufl¨osungen 200x200 und 300x300 verwendet. F¨ ur die c1.xlarge-Instanzen wurden die Aufl¨osungen 400x400 und 600x600 benutzt. Aus diesen je 64 Messwerten wurde dann durch lineare Approximation f¨ ur jeden VM-Typ eine Funktion erstellt, die f¨ ur eine Eingabe die entsprechende Ausf¨ uhrungszeit sch¨ atzt. Obwohl zwischen den Koeffizienten eSzene und #P ixel prinzipiell keine kausale Abh¨ angigkeit besteht, lieferte die multiple Regression unter Verwendung des zus¨atzlichen Koeffizienten eSzene · #P ixel deutlich bessere Ergebnisse. Somit wurde die multiple Regression, wie in Kapitel 6.2.3 beschrieben, mit diesem Koeffizienten durchgef¨ uhrt. Die Messpunkte und die approximierten Fl¨achen sind in Abbildung 8.9 zu sehen. Die approxi-

163

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

1000 800 600 400 200 0 20 40 60 80

Szenengröße in MB

Approximation von lauf für c1.xlarge Ausführungszeit

Ausführungszeit

Approximation von lauf für c1.medium

0

40000 80000 120000 Auflösung in Pixel

1000 800 600 400 200 0 20 40 60 80

Szenengröße in MB

VQgut ca. 68 %

0

480000 120000 240000 360000 Auflösung in Pixel

VQgut ca. 78 %

Abbildung 8.9: Approximation der Laufzeitfunktion laufrender (...) f¨ ur Sunflow auf verschiedenen VM-Typen. mierten Sch¨ atzfunktionen haben folgende Gestalt: laufrender (Rc1.medium , eRender ) = 0, 0000003753 · eSzene + 0, 0003284 · #P ixel +0, 00000000006309 · eSzene · #P ixel −4, 151,

(8.5)

laufrender (Rc1.xlarge , eRender ) = −0, 0000003343 · eSzene + 0, 0003957 · #P ixel +0, 00000000001644 · eSzene · #P ixel +6, 947.

(8.6)

F¨ ur die verwendeten Trainingsszenen l¨asst sich erkennen, dass die Approximation allein f¨ ur das Rendering unter Verwendung der Szenengr¨oße und der Bildaufl¨osung das G¨ utekriterium KQgut nicht erf¨ ullen kann. Jedoch wird es wenigstens f¨ ur die c1.xlarge-Instanz mit ca. 78 % fast erreicht. Da es sich bei dem Raytracing jedoch um eine eingabeterminierte Applikation handelt, deren Gesamtausf¨ uhrungszeit sich aus mehreren sequentiellen Einzeloperationen zusammensetzt, ist es nicht notwendig, dass alle approximierten Funktionen zur Tasklaufzeit das G¨ utekriterium KQgut erf¨ ullen. Es reicht aus, wenn die Gesamtsumme KQgut einh¨alt. Da also laufpbr bereits u ur VQgut erreicht hat, k¨onnen die niedrigeren Werte f¨ ur ¨ber 90 % f¨ laufrender toleriert werden. Berechnung der Gesamtausf¨ uhrungszeit Die Gesamtausf¨ uhrungszeit f¨ ur das Raytracing wird abschließend als laufraytracing (. . . ) angegeben und ergibt sich aus der Summe von laufpbr (. . . ) und laufrender (. . . ). F¨ ur die Gesamtlaufzeitfunktion laufraytracing (. . . ) wird ebenfalls der Parameter eRender benutzt (siehe Gleichung (8.4)), da dieser alle f¨ ur die Ausf¨ uhrung der Teilfunktionen notwendigen Parameter enth¨alt. Die Laufzeitfunktion laufraytracing (. . . ) ist wie folgt definiert: laufraytracing (eRender ) = laufpbr (eSzene ) + laufrender (eRender ).

(8.7)

Diese Sch¨ atzfunktion wird anschließend auf dem Broker als Applikationsprofil f¨ ur Sweethome 3D installiert. Die Auswertung der G¨ ute der Laufzeitvorhersage f¨ ur die Testszenen wird im nachfolgenden Abschnitt betrachtet.

164

8.2 Raytracing

Tabelle 8.5: G¨ ute der Sch¨atzung f¨ ur verschiedene VM-Typen und Netzwerke c1.medium c1.xlarge Abw.∗ Mittelwert ca. 34 % ca. 29 % UMTS VQgut 0,83 0,84 Abw. Mittelwert ca. 29 % ca. 27 % HOME VQgut 0,86 0,94 ∗ Abw. = mittlere Abweichung der 32 Messungen von der Vorhersage

Abbildung 8.10: Auswahldialog zur Bestimmung von Cloud-Optionen und zur Allokation von VM-Instanzen.

8.2.5 Bewertung der Auswahlstrategie Zur Bewertung der Auswahlstrategie wurden unter Verwendung der erstellten Laufzeitvorhersagemethoden mit den verbleibenden 16 Testszenen Messungen mit unterschiedlichen Kommunikationsverbindungen durchgef¨ uhrt. Als mobiles Testger¨at kam erneut das bereits in Abschnitt 8.2.2 benutzte 10”Netbook zum Einsatz. Es wurden je zwei verschiedene Aufl¨osungen auf den konfigurierten VM-Typen c1.medium und c1.xlarge unter Verwendung einer der Netzwerkkonfigurationen HOME und UMTS gerendert. Auf den c1.medium-Typen wurden die Aufl¨osungen 200x200 und 300x300 verwendet, was zu Gesamtausf¨ uhrungszeiten zwischen ca. 0,5–20 min f¨ uhrte. Auf dem c1.xlarge-Instanzen wurden die Aufl¨osungen 400x400 und 600x600 gerendert, was in Ausf¨ uhrungszeiten zwischen ca. 1–15 min resultierte. Die je 64 Kombinationen aus Netzwerkkonfiguration, VM-Typ und Testszene ergaben unter Verwendung der je zwei verschiedenen Bildaufl¨osungen genau 128 Messwerte. Zun¨achst wurde die momentan verf¨ ugbare Netzwerkperformance mit Hilfe des SPEEDTEST Widgets ermittelt, welches auf dem Broker installiert ist (siehe Kapitel 7.2.1). Auf deren Basis wurde dann unter Verwendung des Auswahldialogs in Abbildung 8.10 die Ausf¨ uhrungszeit gesch¨ atzt, eine Ressource allokiert und anschließend das Rendering gestartet. In der Abbildung ist auch zu sehen, dass f¨ ur eingabeterminierte Applikationen die Gesamtausf¨ uhrungskosten durch die Cloud-Optionen zur¨ uckgeliefert werden. Hier bekommt der Nutzer die M¨oglichkeit, zwischen einer schnelleren Bearbeitung oder geringeren Kosten zu w¨ahlen. Tabelle 8.5 fasst die G¨ ute der je 32 Einzelmessungen f¨ ur die vier Kombinationen zusammen. Angegeben ist das Verh¨ altnis VQgut aller Messungen, die nicht mehr als 50 % von der Sch¨ atzung abweichen, zur Gesamtzahl Messungen. Zus¨atzlich ist auch die mittlere Abweichung vom Vorhersagewert angegeben. Die erreichten Werte zeigen, dass das G¨ utekriterium KQgut f¨ ur die Vorhersage mit laufraytracing (. . . ) insgesamt eingehalten wird, obwohl f¨ ur diese eingabeterminierte Applikation KQgut nicht f¨ ur alle einzelnen Berechnungsschritte erf¨ ullt wird. Eine sinnvolle Auswahl der Ressource ist dadurch f¨ ur diese Applikation m¨oglich. Die tats¨ achliche Zusammensetzung der Gesamtausf¨ uhrungszeit verschiedener Messungen ist in Abbildung 8.11 dargestellt. Jeder Balken im Diagramm repr¨asentiert eine Messung. Die Zusammensetzung ist dabei fast immer ¨ahnlich. Der Anteil f¨ ur die Vorbereitung der Szene (prepareBucketRendering(...)) seitens der VM und die Installation des Programmcodes

165

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Zusammensetzung der Gesamtausführungsdauer WLAN 100 Prozentsatz

80 60 40

Install Task prepareBucketRendering rendering Netzwerkkommunikation

20 0

0x

0

60

0x

e6 en Sz 5 0 e 20 en 0x Sz 20 00 ne4 2 e 0x Sz 20 00 ne3 2 e 0x Sz 2 0 e 20 20 en 0x Sz 20 00 ne 2 e 0x Sz 20 00 ne6 2 e 0x Sz 5 0 e 20 30 en 0x Sz 30 00 ne4 3 e 0x Sz 30 00 ne3 3 e 0x Sz 2 0 e 30 30 en 0x Sz 30 00 ne 3 e 0x Sz 30 00 3 0x e6 30 en Sz 5 0 e 40 en 0x Sz 40 00 ne4 4 e 0x Sz 3 0 e 40 40 en 0x Sz 40 00 ne2 4 e 0x Sz 40 00 ne 4 e 0x Sz 6 0 e 40 40 en 0x Sz 40 00 ne5 6 e 0x Sz 60 00 ne4 6 e 0x Sz 3 0 e 60 60 en 0x Sz 60 00 ne2 6 e 0x Sz 60 00 ne 6 ze S

60

60

c1.xlarge

c1.medium

Zusammensetzung der Gesamtausführungsdauer UMTS

Prozentsatz

100 80 60 40

Install Task prepareBucketRendering rendering Netzwerkkommunikation

20 0

0

20

0x 0

20

0x

20

0

20

0x

20

0

20

0x

20

0

20

0x

20

0

20

0x

20

0

30

0x

20

0

30

0x

30

0

0

30

0x

30

30 30

0

30

0x

0x

30

0

30

0x

30

30 0

40

0x 0

40

0x

40

0

40

0x

40

0

40

0x

40

0

0

40

0x

40

0

40

0x

40

0

60

0x

40

0

60

0x

60

0

60

0x

60

60 60

0

0

60

0x

60

60

0x

0x

60

60

e6

e5

en

Sz

e4

en

Sz

e3

en

Sz

e2

en

Sz

e

en

Sz

e6

en

Sz

e5

en

Sz

e4

en

Sz

e3

en

Sz

e2

en

Sz

e

en

en

Sz

Sz e6

e5

en

Sz

e4

en

Sz

e3

en

Sz

e2

en

Sz

e

en

Sz

e6

en

Sz

e5

en

Sz

e4

en

Sz

e3

en

Sz

e2

en

Sz

e

en

en

Sz

Sz

c1.xlarge

c1.medium

Szene = b SweetHome3DExample, Szene2 = b SweetHome3DExample2, usw. (siehe Anhang E)

Abbildung 8.11: Gemessene prozentuale Zusammensetzung der Gesamausf¨ uhrungszeit f¨ ur das Rendering verschiedener Szenen in unterschiedlichen Konfigurationen.

ist in der Gesamtausf¨ uhrungszeit sehr gering. Der Anteil der Netzwerkkommunikation variiert von Szene zu Szene. Auch die verwendete Kommunikationstechnologie hat einen teils großen Einfluss. Die Messungen f¨ ur UMTS sollten den Messungen f¨ ur WLAN ¨ahnlich sein, jedoch stand bei den Messungen unter Verwendung einer c1.medium-Instanz in der UMTSKonfiguration weniger Bandbreite zur Verf¨ ugung als bei den Messungen unter Verwendung von WLAN. Hier wird erneut deutlich, dass die verf¨ ugbare Netzwerkperformance f¨ ur die aktuelle Situation stets neu bestimmt werden sollte. Da die Gesamtausf¨ uhrungszeit sehr gut mit der Bildaufl¨osung skaliert, kann der Vorhersagefehler begrenzt werden, indem zun¨achst in einer kleineren Aufl¨osung gerendert und die ben¨otigte Zeit mit der Vorhersage verglichen wird. Dadurch erh¨alt man einen guten Anhaltspunkt u ute der Sch¨ atzung und kann so die Ausf¨ uhrungszeit f¨ ur das Rendering eines ¨ber die G¨ gr¨oßeren Bildes im Vergleich zur Vorhersage besser bewerten.

8.3 Mobile Streaming-Bildverarbeitung Als benutzerterminierte Applikation wurde eine Android -App erstellt, die fortlaufend Kamerabilder verarbeitet. Jede Verarbeitung eines Bildes wird dabei durch einen Task repr¨asentiert. Das Ausgangsbild dient als Eingabe und das bearbeitete Bild als Ausgabe. Da die Dauer der Programmausf¨ uhrung nicht bekannt ist und durch den Benutzer gesteuert wird, handelt es sich um eine benutzerterminierte Applikation (siehe Kapitel 6.1.1), f¨ ur die eine Bildverarbeitungsrate pro Sekunde (englisch frames per second (fps)) angegeben werden kann. F¨ ur die eigentliche Verarbeitung der Bilder wurden zwei verschiedene Algorithmen implementiert.

166

8.3 Mobile Streaming-Bildverarbeitung

Abbildung 8.12: Abbildung der Streaming-Bildverarbeitungsapplikation f¨ ur Android auf dem DELL Streak 7. (Links: Gesichtserkennungsalgorithmus Rechts: Kantenerkennungsalgorithmus)

8.3.1 Algorithmen Bei der erstellten Android -App kann zwischen einer lokalen Verarbeitung und einer entfernten Cloud-unterst¨ utzten Verarbeitung der Kamerabilder umgeschaltet werden. Somit ist der Algorithmus eventuell auch ohne verf¨ ugbare Netzwerkverbindnung noch lokal verwendbar. Bevor die Algorithmen n¨ aher beschrieben werden, sei noch darauf hingewiesen, dass Java SE f¨ ur PCs und Laptops und die Android -Implementierung verschiedene Systembibliotheken verwenden. Dies f¨ uhrt dazu, dass unterschiedliche Klassen zur Abspeicherung von Bilddaten auf dem Mobilger¨ at und der VM benutzt werden m¨ ussen. Unter Android wird android.graphics.Bitmap und unter Java SE java.awt.image.BufferedImage verwendet. Als Ergebnis ist es nicht direkt m¨ oglich, denselben Code auf Android - und VM-Seite zur Bearbeitung der Algorithmen zu verwenden. Es wurden f¨ ur Testzwecke zwei verschiedene Bildverarbeitungsalgorithmen implementiert. Sobel Kantenerkennung Mit Hilfe des Sobel -Operators werden scharfe Kanten¨ uberg¨ange in einem Bild sichtbar gemacht (siehe [NA08, S. 123ff.]). Ein Beispiel unter Verwendung der vorgestellten Applikation ist in Abbildung 8.12 (rechts) zu sehen. Die Bildtransformation wurde auf Basis der Software ImageProx 6 implementiert. Der Programmcode f¨ ur die lokale und die entfernte Ausf¨ uhrung unterscheiden sich in diesem Beispiel nur f¨ ur die bereits beschriebenen verschiedenen Speicherformate f¨ ur Bilder unter Android und der Java SE . Gesichtserkennung Als weiterer Bildverarbeitungsalgorithmus wurde ein Gesichtserkennungsalgorithmus auf Basis von Hautfarbenerkennung implementiert [HAMJ02]. Ein Beispiel unter Verwendung der vorgestellten Applikation ist in Abbildung 8.12 (links) zu sehen. Hierzu wurde auf dem Quellcode des Programms Face Detection in Color Images 7 aufgebaut. Der Gesichtserkennungsalgorithmus ben¨ otigt viele Verarbeitungsschritte und große Datenmengen an Zwischenergebnis6

Verf¨ ugbar unter Onlineressource http://www.3programmers.com/mwells/research.html (abgerufen am 19.2.2014) 7 Verf¨ ugbar unter Onlineressource http://sourceforge.net/projects/facedetectionin/ (abgerufen am 19.2.2014)

167

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

10

Framerate (min, avg, max)

Tabelle 8.6: Charakteristiken von Bildverarbeitungstasks f¨ ur Streaming-Bildverarbeitung

640x480 320x240 1360x720 480x480

1

Upload

Download

∆tmobil (lokal)

∆twork (c1.medium)

320x240 (Sobel)

ca. 7 kB

ca. 12 kB

280 ms

25 ms

640x480 (Sobel)

ca. 22 kB

ca. 29 kB

990 ms

80 ms

1360x720 (Sobel)

ca. 54 kB

ca. 85 kB

2500 ms

250 ms

320x240 (Face)





2860 ms



480x480 (Face)

ca. 20 kB

ca. 21 kB



1000 ms

0.1

FA

FA

FA

E

C

E

C

E

BE

BE

BE

C

SO

SO

SO

A S

PU

7

S

PU

7

AM

AM

ak

C

tre

N

lS

LA

SP

H

W

el

A

ak

C

tre

N

lS

LA

SP

H

W

el

D

D

L

L

L

Abbildung 8.13: Verarbeitungsraten f¨ ur Bildverarbeitungstasks der Streaming-Bildverarbeitung. sen m¨ ussen gespeichert werden. Somit ist die Gesichtserkennung auf dem verf¨ ugbaren Tablet und Smartphone in ihrer urspr¨ unglichen Form selbst f¨ ur die geringste Kamerbildaufl¨osung von 176x144 nicht ausf¨ uhrbar. Um dennoch eine auf den Mobilger¨ aten ausf¨ uhrbare Variante zu erhalten, wurde der Algorithmus um einige Analyseschritte beschnitten. So werden in der vereinfachten Variante alle ¨ Hautpartien schon als Gesicht erkannt, ohne tats¨achlich eine Uberpr¨ ufung bez¨ uglich der Erkennung der Gesichtsgeometrie durchzuf¨ uhren. Diese Variante ist zwar ungenau, liefert aber auch das eigentliche Gesicht zur¨ uck und l¨asst sich auf dem Dell Streak 7 Tablet beispielsweise noch in einer Aufl¨ osung bis 320x240 ausf¨ uhren.

8.3.2 Rechenzeitbedarf Zun¨achst wurde die Geschwindigkeit der Ausf¨ uhrung der Bildverarbeitungstasks auf dem Dell Streak 7 Mobilger¨ at bestimmt und mit der auf eine VM ausgelagerten Variante verglichen, um die erreichbaren Verbesserungen zu zeigen. Abbildung 8.13 visualisiert die Ergebnisse. Dargestellt sind jeweils die minimale, maximale und durchschnittliche Bildverarbeitungsrate f¨ ur einen Messzeitraum von ca. 100 s. Die nebenstehende Tabelle enth¨alt zudem die Datengr¨oßen f¨ ur die u ¨bermittelten Bilder und die gemessenen durchschnittlichen Verarbeitungszeiten auf dem Ger¨ at und auf der VM. F¨ ur die Performancemessungen zur Kantenerkennung wurde eine c1.medium-Instanz genutzt, f¨ ur die Gesichtserkennung hingegen eine c1.xlarge-Instanz. Abbildung 8.13 zeigt, dass die Kantenerkennung als Mobile Cloud-unterst¨ utzte Anwendung

168

8.3 Mobile Streaming-Bildverarbeitung

deutlich beschleunigt werden kann. Interessant ist hier zudem, dass die Variante unter Verwendung der WLAN-Konfiguration CAMPUS wesentlich gr¨oßere Schwankungen, vor allem nach unten, aufweist. Wie bereits in Kapitel 4.2 erl¨autert wurde, h¨angt dies damit zusammen, ¨ dass sich hier alle WLAN-Ger¨ ate im gleichen Netzwerk das Ubertragungsmedium dynamisch ¨ teilen. Dies kann zu St¨ orungen f¨ uhren, die die Ubertragungsrate kurzzeitig stark vermindern. Bei UMTS/HSPA wird jedem Teilnehmer hingegen eine Bandbreite fest zugeteilt, die er dann auch verwenden kann, ohne dabei andere Teilnehmer zu st¨oren. F¨ ur die Bewertung des Gesichtserkennungstasks wurde nur eine Aufl¨osung von 480x480 gew¨ahlt. Bei dieser Aufl¨ osung ben¨ otigt ein Task ca. 1 s auf einer c1.xlarge oder c1.medium VM, siehe Tabelle 8.6. Diese Dauer ist als Verz¨ogerung im Bildfluss erkennbar. Bei h¨oherer Aufl¨osung w¨ urde sich diese Verz¨ ogerung noch erh¨ohen und die Applikation in der Anwendbarkeit einschr¨ anken. Bei niedrigeren Aufl¨osungen kann es sein, dass die Gesichtserkennung nicht mehr zufriedenstellend funktioniert. In Abbildung 8.13 ist zudem zu erkennen, dass die Mobile Cloud-unterst¨ utzte Anwendung im Mittel zwischen 2–3 fps erreicht. F¨ ur diese Variante ist eine Anwendbarkeit des Algorithmus somit gew¨ahrleistet. Die Unterschiede zwischen der HSPAVerbindung und der WLAN-Verbindung sind hier gering und eher auf die unterschiedliche Beschaffenheit der Bilder bez¨ uglich der Anzahl von Menschen/Gesichtern zur¨ uckzuf¨ uhren als auf Performanceunterschiede zwischen den mobilen Kommunikationsverbindungen.

8.3.3 Konstruktion der Laufzeitfunktion zur Vorhersage Das Ziel der vorgestellten Middleware ist es, einen passenden VM-Typ f¨ ur die entfernte Ausf¨ uhrung zur Laufzeit zu bestimmen. Um die daf¨ ur notwendigen Applikationsprofile zu erstellen, muss zun¨ achst f¨ ur jede der beiden Testapplikationen zur Kantenerkennung (SobelTask) und zur Gesichtserkennung (FaceTask) eine Laufzeitfunktion ratemulti (. . . ) erstellt werden. Im Gegensatz zu der in Kapitel 8.2 vorgestellten Beispielapplikation handelt es es sich hierbei um eine benutzerterminierte Applikation, deren vollst¨andige Eingabe also zum Beginn der Ausf¨ uhrung nicht feststeht. Deshalb wird hier die Verarbeitungszeit eines einzelnen Tasks gesch¨atzt und daraus eine Rate berechnet. Zun¨achst wurden die Applikation und beide Bildverarbeitungstasks auf verschiedenen VMTypen und unter Verwendung verschiedener Aufl¨osungen mehrfach ausgef¨ uhrt. Danach erfolgte die Auswertung der gesammelten Logdaten. Insgesamt wurden die Laufzeitfunktionen ratemulti f¨ ur beide Tasks aus 9497 Messwerten generiert. Die Auswahl konfigurierter VMs bestand aus den Typen m1.small, c1.medium und c1.xlarge, da sich diese, wie in Kapitel 6.2.5 gefordert, in der Ausf¨ uhrungsgeschwindigkeit jeweils um circa den Faktor 4 unterscheiden. Da hier f¨ ur viele gleichartige Tasks mit derselben Eingabeaufl¨osung verschiedene Messungen vorlagen, wurde jeweils der Mittelwert gebildet. Abbildung 8.14 zeigt die H¨aufigkeitsverteilung (Histogramm) der gleichartigen Tasks an. F¨ ur die Kantenerkennung (links) reflektiert der Mittelwert sichtbar auch den Großteil der Werte. Bei der Gesichtserkennung (rechte Abbildung) ist der Mittelwert durch eine etwas nach rechts verschobene Verteilung aller Messungen vom Median deutlich verschieden (Mittelw.: 2253 ms Median: 1525 ms). Deshalb wurde der Mittelwert hier nur aus den Werten aus dem Interquartilsabstand (± 25 % der Werte um den Median) gebildet. Dass diese Anpassung sinnvoll sein kann, wurde in Kapitel 6.2.4 zur Regressionsanalyse erl¨ autert. Der angepasste Mittelwert (1645 ms) ist eher typisch f¨ ur den Großteil der Werte (siehe Abbildung 8.14 (rechts)). Abbildung 8.15 zeigt das Ergebnis der Regressionsanalyse f¨ ur beide Bildverarbeitungstasks f¨ ur die durchschnittliche Ausf¨ uhrungszeit. Es ist gut zu erkennen, dass ein Zusammenhang

169

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Sobel Task 640x480 auf m1.small

Face Task 640x480 auf c1.xlarge

400

300

350

250 Mittelwert (Interquartilsabstand)

250 200

Mittelwert

150

Häufigkeit

Häufigkeit

300 200 150

Mittelwert

100

100 50

50 0

0 105 449 793 1137 1481 1825 Histogramm der verschiedenen Tasklaufzeiten in ms

662 3016 5370 7724 10078 12432 Histogramm der verschiedenen Tasklaufzeiten in ms

Abbildung 8.14: H¨ aufigkeitsverteilung verschiedener Tasklaufzeiten gleicher Art (Taskart und Bildaufl¨ osung) aus den Logdaten mehrerer Testl¨aufe der Cloud-unterst¨ utzten Streaming-Bildverarbeitung f¨ ur Mobilger¨ate. zwischen der Pixelanzahl des Bildes und der Ausf¨ uhrungszeit besteht. Beide Taskausf¨ uhrungszeiten lassen sich gut durch eine lineare Funktion approximieren. Jeder Punkt im Diagramm stellt den Mittelwert aus minimal 34 bis zu 3067 Einzelmessungen dar. Es wurden die Aufl¨osungen 320x240, 480x480 und 640x480 getestet. Außerdem ist den Digrammen auch zu entnehmen, dass die Approximationsgeraden f¨ ur c1.medium und c1.xlarge sehr ¨ahnlich sind. Dies ist darauf zur¨ uckzuf¨ uhren, dass diese VM-Typen die gleiche Einzelprozessorperformance aufweisen und alle Bildverarbeitungstasks Einzelprozessortasks sind. Es wurden nachfolgende Approximationsgeraden ermittelt: lauff ace (Rm1.small , #P ixel) = 0, 02585 · #P ixel − 320, 6, lauff ace (Rc1.medium , #P ixel) = 0, 004103 · #P ixel + 811, 3, lauff ace (Rc1.xlarge , #P ixel) = 0, 004600 · #P ixel + 193, 6, laufsobel (Rm1.small , #P ixel)) = 0, 0009589 · #P ixel + 7, 286, laufsobel (Rc1.medium , #P ixel)) = 0, 0005143 · #P ixel − 3, laufsobel (Rc1.xlarge , #P ixel)) = 0, 0004864 · #P ixel + 4, 714.

Abschließend wurde f¨ ur alle 9497 Messwerte die Qualit¨at der Vorhersage in Form des Wertes Qgut bestimmt. In der Tabelle in Abbildung 8.15 ist das Verh¨altnis VQgut aller positiv vorhergesagten Werte zur Gesamtzahl der Messungen f¨ ur eine Kombination aus VM-Typ und Algorithmustyp dargestellt. Dabei verfehlt nur die Kantenerkennung auf dem VM-Typ m1.small und die Gesichtserkennung auf dem VM-Typ c1.xlarge das G¨ utekriterium KQgut von 80 %. Im Vergleich zu den anderen Werten ist es dennoch m¨oglich, alle drei VM-Typen f¨ ur die Kantenerkennung und f¨ ur die Gesichtserkennung zu konfigurieren, da eine gut abgegrenzte Vorhersage immer noch m¨ oglich ist.

8.3.4 Bewertung der Auswahlstrategie Nach dem Konfigurieren der Applikationen auf dem Broker-Server, wurden insgesamt 36 Tests durchgef¨ uhrt, um die vorhergesagte Performance und die tats¨achlich erreichte Performance

170

8.3 Mobile Streaming-Bildverarbeitung

Approximation Sobel Task

Tasklaufzeit in ms

300

Approximation Face Task 8000

m1.small c1.medium c1.xlarge

7000 Tasklaufzeit in ms

350

250 200 150 100 50

6000

m1.small c1.medium c1.xlarge

5000 4000 3000 2000 1000

0 50000 100000 150000 200000 250000 300000 350000 Pixelanzahl

0 50000 100000 150000 200000 250000 300000 350000 Pixelanzahl

VQgut aller Einzeltasks m1.small c1.medium FaceTask 0,82 0,8 SobelTask 0,76 0,92

c1.xlarge 0,76 0,95

Abbildung 8.15: Regressionsanalyse der durchschnittlichen Ausf¨ uhrungszeit ∆ttask cloud f¨ ur den Kantenerkennungs- und den Gesichtserkennungstask auf verschiedenen Amazon EC2 -Instanztypen. miteinander zu vergleichen. Der Test bestand aus 24 Messungen unter Verwendung von 3G Mobilfunk in der UMTS/HSPA-Konfiguration und weiteren 12 Messungen, die unter Verwendung von WLAN in der HOME-Konfiguration und der CAMPUS-Konfiguration durchgef¨ uhrt wurden. Die genaue Beschreibung der einzelnen Konfigurationen ist in Tabelle 4.1 zu finden. Als Testger¨ at kam das Sony Xperia P Smartphone zum Einsatz (siehe Anhang A). Die Ermittlung der momentanen Netzwerkperformance wurde erneut mit dem SPEEDTEST Widget durchgef¨ uhrt, welches auf dem Broker installiert ist (siehe Kapitel 7.2.1). Jeder einzelne Test wurde folgendermaßen durchgef¨ uhrt: 1. Bestimmen der momentanen Netzwerkperformance mittels SPEEDTEST , 2. Ausw¨ ahlen des Bildverarbeitungstasks und der Displayaufl¨osung, 3. Senden der Anfrage an Broker und Berechnung von Cloud-Optionen, 4. Ausw¨ ahlen der passenden Cloud-Option und Warten auf deren Bereitstellung, 5. Aufnehmen einer Verbindung zur VM und Installation des Programmcodes, 6. Ausf¨ uhren der Applikation f¨ ur mindestens eine Minute f¨ ur aussagekr¨aftige Bildraten, 7. Stoppen der Applikation und Trennen der Verbindung zur VM. Der Broker berechnet verschiedene Cloud-Optionen auf Basis der gemessenen Netzwerkperformance, des ausgew¨ ahlten Bildverarbeitungstasks und der ausgew¨ahlten Aufl¨osung. Die zur¨ uckgelieferten Cloud-Optionen reflektieren dann die erreichbare Bildverarbeitungsrate auf verschiedenen VM-Typen. Ein Beispiel f¨ ur solche Cloud-Optionen ist in Abbildung 8.16 zu

171

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

Abbildung 8.16: Auswahldialog f¨ ur Cloud-Optionen f¨ ur verschiedene Bildverarbeitungstasks unter Verwendung einer Aufl¨osung von 640x480. (Links: Gesichtserkennung, c1.xlarge sollte gew¨ ahlt werden Rechts: Sobel Kantenerkennung, c1.medium sollte gew¨ ahlt werden) sehen. Hier wurde jeweils der Auswahldialog f¨ ur verf¨ ugbare Cloud-Optionen f¨ ur beide Bildverarbeitungstasks unter Verwendung einer Aufl¨osung von 640x480 dargestellt, wie er in der Applikation f¨ ur Streaming-Bildverarbeitung implementiert ist. Ein Benutzer kann dann anhand der gew¨ unschten Bildwiederholfrequenz oder eventuellen Kostenbeschr¨ankungen ausw¨ahlen. Es sollte die Cloud-Option mit der h¨ochsten prognostizierten Bildwiederholfrequenz gew¨ahlt werden. Falls es mehrere Cloud-Optionen mit der gleichen h¨ochsten Wiederholfrequenz gibt, sollte aus diesen die Cloud-Option mit den niedrigsten Kosten gew¨ahlt werden. Dies ist beispielsweise in Abbildung 8.16 (rechts) der Fall. Hier ist die Netzwerkbandbreite der limitierende Faktor, der eine h¨ ohere Bildverarbeitungsrate auf der schnelleren Maschine verhindert. Zus¨atzlich kann es vorkommen, dass die h¨ochste prognostizierte Bildverarbeitungsrate weit u oglichen Rate liegt. Je nach Lichtverh¨altnis und Bildaufl¨osung liefern ¨ber der technisch m¨ die verwendeten Ger¨ ate maximale Bildraten zwischen 7,5–25 fps. Bei h¨oheren prognostizierten Raten sollte, falls m¨ oglich, eine andere Cloud-Option gew¨ahlt werden, da die prognostizierte Bildverarbeitungsrate nicht erreicht werden kann und eventuell trotzdem ein h¨oherer Preis daf¨ ur gezahlt werden muss. Abschließend wurde die vorhergesagte und die tats¨achlich gemessene Bildverarbeitungsrate der 36 Experimente miteinander verglichen. Abbildung 8.17 zeigt die absolut vorhergesagten und gemessenen Werte (Minimum, Maximum und Mittelwert) und die berechnete Abweichung Q vom Sch¨ atzwert am oberen Rand (rechte Y-Achse). Von den 36 Experimenten erreichten nur 7 nicht die Qualit¨ at Qgut von maximal 50 % Abweichung. Damit liegt VQgut bei ca. 81 % und somit ist das G¨ utekriterium KQgut erf¨ ullt. Die maximale Abweichung wurde mit ca. 77 % gemessen. Die Experimente zeigen jedoch auch, dass in einzelnen F¨allen eine sehr schlechte G¨ ute erzielt wird. Dies trifft vor allem f¨ ur die UMTS/HSPA-Konfiguration zu. Dies kommt daher, dass die via SPEEDTEST vorhergesagte Netzwerkperformance nicht erreicht werden konnte. Ein Grund f¨ ur dieses Verhalten konnte bereits in Kapitel 4 er¨ortert werden. Die dynamische Band¨ breitenregulierung von HSPA-Verbindungen wirkt sich manchmal negativ auf Ubertragungen aus, die nicht die volle Bandbreite in beide Richtungen im Duplexbetrieb senden. Dies Art der Daten¨ ubertragung wird jedoch im Fall der Streaming-Bildverarbeitungsapplikation ben¨otigt. Kamerabilder werden zum Server u ¨bertragen und wieder heruntergeladen. Da jedoch der Upload beschr¨ ankt ist, kann im Download auch nicht die volle Bandbreite ausgesch¨opft wer-

172

8.4 Fazit

Experimente im 3G Mobilfunknetzwerk 0 12.5

Vorhersage und gemessene Framerate

16

25 14

37.5

12

50 62.5

10

75 8

87.5

6

100 112.5

4

125 2 0

gemessen (min,avg,max) vorhergesagt Abweichung in %

137.5

Abweichung von avg im Vergleich zur Vorhersage

18

150 24 Experimente Experimente WLAN CAMPUS 0 12.5

Vorhersage und gemessene Framerate

16

25 14

37.5

12

50 62.5

10

75 8

87.5

6

100 112.5

4

125 2 0

gemessen (min,avg,max) vorhergesagt Abweichung in %

137.5

Abweichung von avg im Vergleich zur Vorhersage

18

150 12 Experimente

Abbildung 8.17: Visualisierung der gemessenen und der vorhergesagten Bildverarbeitungsrate und der Qualit¨ at der vorhergesagten Performance der 36 Experimente. den. Dadurch wird die Bandbreite durch den Mobilfunkprovider manchmal so weit gek¨ urzt, dass die Gesamtperformance stark absinkt. Dieses Verhalten tritt jedoch nur selten auf.

8.4 Fazit In diesem Kapitel konnte gezeigt werden, dass die Middleware benutzt werden kann, um reale Mobile Cloud-unterst¨ utzte Anwendungen zu implementieren. Die Bereitstellungszeit f¨ ur VM-Ressourcen und der Zeitoverhead f¨ ur das Code-Offloading wurden anhand der prototypi¨ schen Implementierung der Middleware bestimmt. Bis zum Start der Ubertragung der ersten tats¨achlichen Tasks vergehen im Durchschnitt ca. 5–6 s. Die Middleware wurde durch synthetische Tasks auch auf deren generelle Eignung zur Vorhersage der Laufzeit untersucht. Dabei wurde festgestellt, dass durch den virtualisierten Softwarestack mit Schwankungen gerechnet werden muss, die jedoch nur selten gr¨oßer sind als 20 %. F¨ ur zwei reale Applikationen wurde außerdem die Konstruktion von Profilen erl¨autert. Die G¨ ute der Vorhersage in verschiedenen Szenarien f¨ ur diese realen Applikationen stand an-

173

8 Bewertung der Middleware anhand ausgew¨ ahlter Applikationen

schließend im Mittelpunkt der Untersuchung. Dabei konnte sowohl f¨ ur die eingabeterminierte Applikation als auch f¨ ur die benutzerterminierte Applikation das definierte G¨ utekriterium fast immer eingehalten werden. Eine sinnvolle Auswahl einer Cloud-Option zur Laufzeit ist f¨ ur die betrachteten Applikationen also m¨oglich. Dies versetzt den Nutzer in die Lage, die Performance der Ausf¨ uhrung der Mobilen Cloud-unterst¨ utzten Anwendung in Abh¨angigkeit der aktuellen Eingabe, Netzwerkgeschwindigkeit und Kostenbeschr¨ankung passend zu w¨ahlen. Als Restriktion der Middleware wurde jedoch auch festgestellt, dass die Vorhersage der verf¨ ugbaren Netzwerkperformance f¨ ur asynchrone Upload/Download-Konfigurationen (HOMEund UMTS-Konfiguration) oft schlechtere Ergebnisse liefert als f¨ ur die CAMPUS-Konfiguration. Dies macht erneut die Notwendigkeit deutlich, dass der Nutzer eine M¨oglichkeit haben sollte, die Vorhersage der Netzwerkperformance zu korrigieren. Diese wurde bei den implementierten Applikationen dadurch ber¨ ucksichtigt, dass die Bestimmung der Netzwerkperformance gesondert erfolgt und der Nutzer die Werte f¨ ur die Bestimmung von Cloud-Optionen noch anpassen kann. Zudem sollten die Applikationsprofile zur Vorhersage der Laufzeit in regelm¨aßigen Abst¨anden erneuert werden, da auch die Performance der VM-Typen in gr¨oßeren Abst¨anden deutlich schwanken kann. Allgemein beeintr¨achtigen diese Restriktionen die Anwendbarkeit des Verfahrens nicht grundlegend, sondern stellen vielmehr Verbesserungsm¨oglichkeiten dar, die im Umfang dieser Arbeit nicht mehr bearbeitet werden konnten.

174

9 Zusammenfassung In diesem Kapitel wird die Arbeit zusammengefasst. Anschließend werden die wichtigsten Ergebnisse der Betrachtungen zu einer Handlungsempfehlung f¨ ur die Erstellung von Mobilen Cloud-unterst¨ utzten Anwendungen geb¨ undelt. Abschließend werden Ankn¨ upfungspunkte f¨ ur ¨ weiterf¨ uhrende Arbeiten vorgestellt. Außerdem wird eine kurze Ubersicht geliefert u ¨ber Technologien, die w¨ ahrend der Erstellung der Arbeit verf¨ ugbar wurden sowie deren zu erwartende Auswirkungen auf die Ergebnisse dieser Arbeit.

9.1 Zusammenfassung der Ergebnisse Die vorliegende Arbeit befasste sich mit der Fragestellung, wie rechenintensive mobile Applikationen durch Cloud Computing derart unterst¨ utzt werden k¨onnen, dass die Dienstqualit¨ at f¨ ur die Ausf¨ uhrungsressourcen (VM-Instanzen) zur Laufzeit sinnvoll anhand der aktuellen Situation gew¨ ahlt werden kann. F¨ ur diese Art Applikationen wurde der Term Mobile Cloudunterst¨ utzte Anwendung eingef¨ uhrt. Als Zielger¨ate wurden Mobilger¨ate wie Smartphones, Tablets und kleine Laptops bestimmt, deren Ressourcen zugunsten einer l¨angeren Batterielaufzeit oft eingeschr¨ ankt sind. Es wurde festgestellt, dass die sinnvolle Auswahl einer VM-Instanz maßgeblich von drei Einflussfaktoren abh¨ angt: der Netzwerkperformance, der Ausf¨ uhrungsgeschwindigkeit der VM-Instanz und der Beschaffenheit der Applikation selbst. Um eine Auswahl zu erm¨oglichen, m¨ ussen alle drei Faktoren m¨ oglichst gut vorhersagbar sein und effizient genutzt werden. Diese Kernanforderung wurde zu Beginn der Arbeit definiert. Zun¨achst wurde ein Modell erarbeitet, welches alle relevanten Parameter einschließt und die Ausf¨ uhrungszeit von Mobilen Cloud-unterst¨ utzten Anwendungen erfassen kann. Danach wurde f¨ ur alle drei Einflussfaktoren untersucht, wie diese die Performance und die Vorhersagbarkeit beeinflussen. Insbesondere war die Schwankungsbreite und -h¨ aufigkeit von Interesse. Im Bereich der Netzwerkperformance wurden WLAN und Mobilfunknetze der 3. Generation (3G) in drei verschiedenen Konfigurationen untersucht. Zudem wurde der Einfluss von Verschl¨ usselung und Codierung der Nutzdaten erfasst. Die Analyse der Eigenschaften mobiler Kommunikationsnetze m¨ undete in den Entwurf einer effizienten Kommunikationsbibliothek auf Basis einer persistenten TCP-Verbindung mit Pipelining, die sowohl die Gesamtperformance als auch die Vorhersagbarkeit der Daten¨ ubertragungsrate verbessern konnte. Außerdem wurde eine Middleware f¨ ur Java entworfen und implementiert, die die Ausf¨ uhrung von Mobilen Cloud-unterst¨ utzten Anwendungen und die Auswahl der Dienstqualit¨at zur Laufzeit unterst¨ utzt. Die Auswahl zur Laufzeit und eine m¨oglichst gute Auslastung von VMInstanzen durch Wiederverwendung machen die Installation des Programmcodes zur Laufzeit notwendig. Dies ist unter dem Begriff Code-Offloading bekannt und ebenfalls durch die Middleware implementiert. Durch diese Technik kann der Kostenoverhead beim stundenbasierten Mieten von VM-Instanzen stark reduziert werden, was im Ergebnis f¨ ur eine feingranularere Abrechnung f¨ ur den Endkunden genutzt werden kann. Die Middleware erm¨oglicht eine sekundengenaue Abrechnung. Der verwendete Softwarestack wurde ebenfalls auf Performan-

175

9 Zusammenfassung

ceschwankungen untersucht. Hierbei wurde insbesondere der Einfluss durch Virtualisierung analysiert. Die VM-Instanzen selbst sind virtuelle Maschinen, die vom IaaS-Anbieter bereitgestellt werden. Zudem wird auch das Java-Programm selbst durch eine JVM ausgef¨ uhrt. Es wurde festgestellt, dass Performanceschwankungen auftreten k¨onnen, die die Vorhersage beeinflussen, jedoch nicht unm¨ oglich machen. Schließlich wurde der Einfluss der eigentlichen Applikation auf die Vorhersagbarkeit der Laufzeit betrachtet. Hierzu wurden Applikationen zun¨achst kategorisiert in eine Menge, die sich zwar auf der Middleware ausf¨ uhren l¨asst, deren Verhalten jedoch kaum vorhergesagt werden kann. F¨ ur die verbleibende zweite Menge potenziell vorhersagbarer Applikationen wurden zudem Kriterien bez¨ uglich der Performanceschwankung definiert, unter denen eine Vorhersage m¨ oglich ist. Außerdem muss zur Vorhersage ein Zusammenhang zwischen einer Eingabegr¨oße und der Laufzeit hergestellt werden. Dazu wurde die Methode der Regressionsanalyse vorgestellt und anhand von Beispielen erkl¨art. Die Evaluation der prototypischen Implementierung der Middleware und insbesondere der G¨ ute der vorhergesagten Performance zur Ressourcenauswahl wurde anhand realer Applikationen durchgef¨ uhrt. Dazu wurde die Raytracing-Funktionanlit¨at zur Erstellung fotorealistischer Bilder eines 3D-Hausdesigners und eine Applikation zur fortlaufenden Kamerabildverarbeitung auf Android -Ger¨ aten genutzt. Zus¨atzlich wurden auch synthetische Applikationen verwendet, um die Grenzen der entwickelten Technik zu untersuchen. F¨ ur fast alle Szenarien konnte eine zufriedenstellende G¨ ute der Vorhersage erreicht werden. Fehlprognostizierte Werte sind fast immer auf die falsche Einsch¨atzung der verf¨ ugbaren Netzwerkperformance zur¨ uckzuf¨ uhren.

9.2 Erstellungsleitfaden f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen Die Analyse der Performance mobiler Kommunikationsverbindungen ergab, dass aufgrund der relativ hohen Latenzen der Einsatz einer persistenten TCP-Verbindung große Vorteile bringt, vor allem wenn auch die Verschl¨ usselung obligatorisch ist. Zudem wurde festgestellt, ¨ dass die tats¨ achlich verf¨ ugbare Ubertragungsgeschwindigkeit auch dann sehr pessimistisch zu bewerten ist. Vor allem die Duplexf¨ahigkeiten der untersuchten Technologien sind oft beschr¨ankt durch asynchrone Upload/Download-Konfiguration oder durch viele Teilnehmer im ¨ WLAN. Tats¨ achlich nutzbar waren oft nur Ubertragungsraten im einstelligen Mbit-Bereich. Dies sollte beim Entwurf von Mobilen Cloud-unterst¨ utzten Anwendungen ber¨ ucksichtigt wer¨ den. Eventuell ist es sinnvoll, die Daten w¨ahrend der Ubertragung zus¨atzlich zu komprimieren. ¨ Auch in Bezug auf die Schwankungsbreite der nutzbaren Ubertragungsrate wurde festgestellt, dass diese hoch sein kann und manchmal sehr unvermittelt starke Schwankungen auftreten. ¨ Deshalb sollte die verf¨ ugbare Ubertragungsbandbreite nicht automatisch bestimmt werden. Ein Benchmarkwerkzeug zur Bestimmung der momentan verf¨ ugbaren Netzwerkperformance liefert zwar eine gute Orientierung, oft kann der Nutzer selbst durch seine eigene Erfahrung die verf¨ ugbare Bandbreite jedoch besser absch¨atzen. Beispielsweise kann in einem vollen H¨orsaal die momentan verf¨ ugbare Bandbreite hoch sein. Aufgrund der vielen Teilnehmer ist dies aber u ber einen l¨ a ngeren Zeitraum kaum zu erwarten. Da man jedoch vor der Allokation der ¨ VM die verf¨ ugbare Bandbreite sch¨ atzen muss, sollte in diesem Fall eher pessimistisch kalkuliert werden. Schnelle Bewegung und eine deutliche Entfernung vom urspr¨ unglichen Ort, f¨ ur den die VM-Allokation durchgef¨ uhrt wurde, f¨ uhren sehr wahrscheinlich auch dazu, dass

176

9.2 Erstellungsleitfaden f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen

die vorhergesagte Performance der Mobilen Cloud-unterst¨ utzten Anwendung nicht erreicht wird. F¨ ur die in dieser Arbeit betrachteten Kommunikationsnetzwerke und das entwickelte Kommunikationsprotokoll war die Bandbreitenvorhersage f¨ ur Nutzdaten ab ca. 50 kB recht genau. Bei Entwicklung der Middleware lag das Hauptaugenmerk auf einer m¨oglichst guten Unterst¨ utzung der Vorhersagbarkeit und der durchweg verschl¨ usselten Kommunikation. Dadurch konnten nicht alle Arten von Applikationen unterst¨ utzt werden. Alle Applikationen, die auf der entwickelten Middleware ausgef¨ uhrt werden, m¨ ussen taskbasiert arbeiten. Tasks sind als kleinste Einheit f¨ ur eine effiziente Ausnutzung der Kommunikation notwendig. Zus¨atzlich sind Tasks auch sehr gut f¨ ur Code-Offloading geeignet, da nur eine entsprechende Taskfunktion installiert werden muss. Eine weitere Einschr¨ankung musste getroffen werden, wenn die Laufzeit der taskbasierten Anwendung auch vorhersagbar sein soll, sodass eine Ressourcenauswahl zur Laufzeit m¨ oglich wird. Hierbei k¨onnen nur eingabeterminierte Applikationen unterst¨ utzt werden, die aus sequentiell zu verarbeitenden Tasks bestehen und deren vollst¨andige Eingabe bekannt ist. Zudem k¨ onnen auch benutzerterminierte Applikationen unterst¨ utzt werden, die aus unabh¨ angigen Einzelprozessortasks bestehen, bei denen die Eingabe zwar nicht vollst¨andig bekannt ist, aber deren Tasklaufzeiten und Eingabegr¨oße immer nahezu konstant bleiben. F¨ ur diese Art Applikationen l¨ asst sich eine Verarbeitungsrate von Tasks pro Sekunde angeben. F¨ ur die Vorhersage m¨ ussen Profile erstellt werden, die aufgrund der Beschaffenheit der Eingabedaten eine Laufzeit sch¨ atzen. Es muss also m¨oglich sein, f¨ ur die Tasks der Applikation einen solchen Zusammenhang herzustellen. In dieser Arbeit wurde gezeigt, dass dies u ¨ber eine (multiple) Regression f¨ ur bis zu zwei unabh¨angige Gr¨oßen gelingen kann. Die notwendigen Monitoringdaten f¨ ur die Regression werden dabei von der Middleware selbst gesammelt. Die erreichte G¨ ute der Sch¨ atzung muss die Konfiguration verschiedener Typen von CloudRessourcen zur Ausf¨ uhrung zulassen. Streuen die tats¨achlichen Laufzeiten beispielsweise stark vom Vorhersagewert, so m¨ ussen VM-Typen mit sehr großen Performanceunterschieden konfiguriert werden, damit eine sinnvolle Unterscheidung gegeben ist. Da jedoch Ressourcen nicht in beliebigen Konfigurationen vorliegen, wurde f¨ ur die Ressourcen des Cloud-Anbieters Amazon EC2 die Einschr¨ ankung getroffen, dass die Performance der Ressourcen nicht mehr als Faktor 4 verschieden sein kann. Dadurch ergibt sich eine G¨ ute der Sch¨atzung von Tasklaufzeiten derart, dass mindestens 80 % der gemessenen Tasklaufzeiten um nicht mehr als ± 50 % vom Vorhersagewert abweichen. Andernfalls k¨onnen eventuell nur 1-2 VM-Typen konfiguriert werden, was die sinnvolle Auswahl in Frage stellt. Zu beachten ist auch, dass aufgrund des teilweise virtualisierten Softwarestacks auch schon Schwankungen der Laufzeit f¨ ur berechnungsintensive Tasks im unteren zweistelligen Bereich zu erwarten sind. I/O-intensive Tasks sollten g¨ anzlich vermieden werden. Auch die JVM kann aufgrund der Garbage Collection zu schwankenden Laufzeiten beitragen, jedoch ist dies nur f¨ ur sehr kurze Tasklaufzeiten von weit unter 1 s deutlich. Als besonders tauglich f¨ ur die Vorhersage haben sich Tasks gezeigt, deren Laufzeit mindestens 1 s betr¨ agt. Obwohl die entwickelte Middleware die Abrechnung der Nutzung auf Basis von Sekunden erm¨oglicht, sollte die Ausf¨ uhrungszeit einer Mobilen Cloud-unterst¨ utzten Anwendung nicht nur wenige Sekunden betragen. Hier macht sich negativ bemerkbar, dass allein f¨ ur die Dauer der Allokation einer VM-Instanz und f¨ ur die Installation des ben¨otigten Programmcodes ca. 5–10 s zu erwarten sind. Damit eine Beschleunigung der Mobilen Cloud-unterst¨ utzten Anwendung zu erreichen ist, muss deren Laufzeit somit entsprechend l¨anger sein. Die getesteten Beispielapplikationen hatten in der Regel Ausf¨ uhrungszeiten im einstelligen Minutenbereich.

177

9 Zusammenfassung

9.3 Ausblick und weiterf¨ uhrende Arbeiten Seit der Formulierung der Anforderungen an die Arbeit in den Jahre 2011/2012 sind diverse Verbesserungen bez¨ uglich der verwendeten Technologien etabliert worden. Zudem wurden in dieser Arbeit f¨ ur die Untersuchungen der Eigenschaften von Mobilen Cloud-unterst¨ utzten Anwendungen diverse Einschr¨ ankungen getroffen. So wurde beispielsweise nur ein CloudAnbieter und nur ein Mobilfunknetz untersucht. Dies lag unter anderem auch in der Tatsache begr¨ undet, dass die Benutzung dieser Dienste mit erheblichen Kosten verbunden ist. Dennoch soll hier abschließend kurz darauf eingegangen werden, welche Neuerungen und Eigenschaften anderer Anbieter heute im Jahr 2014 eventuell einen Einfluss auf die Ergebnisse der Arbeit haben k¨onnten und wie die in dieser Arbeit entwickelten Techniken erweitert werden k¨onnten. Zun¨achst ist festzuhalten, dass im Laufe der Erstellung der Arbeit stetig an der Verbesserung der mobilen Kommunikationstechnologien gearbeitet wurde. Im Mobilfunkbereich steht im Jahr 2014 in Deutschland beispielsweise ein nahezu fl¨achendeckendes LTE-Netz (4. Generation (4G)) zur Verf¨ ugung. Dadurch verbessert sich allgemein die Performance mobiler Kommunikationsverbindungen. Im Vergleich zum Mobilfunknetz der 3. Generation sind ca. die doppelte Download- und dreifache Upload-Geschwindigkeit m¨oglich [PH13]. Außerdem wurden auch im Bereich WLAN neue Standards verabschiedet (beispielsweise 802.11ac), welche die Performance stark verbessern k¨ onnen. Entsprechende Ger¨ate sind jedoch noch sehr rar und werden noch nicht fl¨ achendeckend eingesetzt[Ahl14]. Auch die Maximalgeschwindigkeit der Breitbandanschl¨ usse f¨ ur Privatkunden hat sich im Vergleich zu 2012 leicht erh¨oht1 . Viele Anschl¨ usse sind jedoch weiterhin asynchron ausgef¨ uhrt, wodurch die relativ schlechte Uploadgeschwindigkeit die Performance von Mobilen Cloud-unterst¨ utzten Anwendungen stark negativ beeinflussen kann. Eine Ausnahme bilden hier auch immer h¨aufiger anzutreffende Breitbandanschl¨ usse via LTE. Diese weisen oft deutlich h¨ohere Uploadperformance auf als beispielsweise Anschl¨ usse via Telefon/DSL oder Fernsehkabel. Im Bereich der WLAN-Großinstallationen (beispielsweise CAMPUS-Netzwerk) werden bestehende Systeme nur langsam ausgetauscht, was dazu f¨ uhrt, dass fl¨ achendeckend hier auch weiterhin nur WLAN 802.11g mit maximal 54 Mbit/s verf¨ ugbar ist. Insgesamt gesehen ist jedoch die Unterst¨ utzung von Mobilen Cloudunterst¨ utzten Anwendungen verbessert worden, insbesondere in den Mobilfunknetzen. Hier k¨onnen zuk¨ unftige Arbeiten zeigen, ob diese Verbesserungen auch eine bessere Nutzung in der Bewegung erm¨ oglichen. Im Bereich der Cloud-Anbieter wurden w¨ahrend der Erstellung der Arbeit teils erhebliche Neuerungen eingef¨ uhrt. So bieten immer mehr Anbieter im Jahr 2014 auch sehr performante VM-Instanztypen aus dem Bereich des High-Performance-Computing an2 , wie beispielsweise das im Mai 2012 am Markt erschienene Unternehmen ProfitBricks. Diese Instanztypen mit vielen CPU-kernen erlauben nicht nur eine gr¨oßere Auswahl f¨ ur Mobile Cloud-unterst¨ utzte Anwendungen, sondern bieten auch noch bessere Performance, die beispielsweise f¨ ur die vorgestellte Raytracing-Applikation weitere Verbesserungen bringen k¨onnte. Zudem haben einige 1

Im Januar 2013 wurden 59 % der station¨ aren Breitbandanschl¨ usse in der Europ¨ aischen Union mit mehr als 10 Mbit/s beliefert. Ein Jahr zuvor wurden nur 48,6 % mit dieser Geschwindigkeit beliefert. (siehe Onlineressource http://de.statista.com/statistik/daten/studie/173685/umfrage/ kabelgebundene-breitbandanschluesse-in-der-eu-nach-geschwindigkeit/(abgerufen am 8.2.2014)) 2 Today, Cloud Computing brings HPC like performance and scalability to a much wider audience, allowing ” HPC teams to expedite their HPC workloads using highly flexible and scalable compute resources on demand, as needed, and save money by paying only for the resources that are actually consumed.“ (Onlineressource http://www.profitbricks.com/high-performance-computing-hpc (abgerufen am 8.2.2014))

178

9.3 Ausblick und weiterf¨ uhrende Arbeiten

Anbieter auch damit begonnen, die Abrechnung der Nutzungsdauer feingranularer zu gestalten. Der Dienst Google Compute Engine rechnet seine Instanzen nunmehr im Minutentakt ab, nachdem eine minimale Anlaufphase von 10 min abgeschlossen ist3 . Dadurch kann der Kostenoverhead f¨ ur k¨ urzere Nutzungsdauern von Mobilen Cloud-unterst¨ utzten Anwendungen weiter gesenkt werden. Hier k¨ onnte in zuk¨ unftigen Arbeiten auf Basis des erarbeiteten Simulationsmodells analysiert werden, wie sich diese Verbesserungen auf den Kostenoverhead auswirken. Die entwickelte Middleware ist in der Lage, Cloud-Optionen zur Laufzeit zu pr¨asentieren, die vorher als Profil installiert wurden. Es hat sich w¨ahrend der Arbeit als teilweise m¨ uhsam herausgestellt, ein Profil auf Basis der Logdaten zu generieren. Als sinnvolle Erweiterung erscheint demnach die automatische Generierung von Applikationsprofilen auf Basis der schon von der Middleware gesammelten Logdaten. Lediglich die Korrelationsparameter sollten noch von Hand gew¨ ahlt werden. Auf Basis der erarbeiteten Methoden (beispielsweise Regressionsanalyse) und der notwendigen Einschr¨ankungen der Schwankungsbreite der Approximation k¨onnten so nicht nur automatisch Profile erzeugt werden, sie k¨onnten auch fortw¨ahrend angepasst werden. Zudem k¨ onnte in weiterf¨ uhrenden Arbeiten analysiert werden, ob beispielsweise maschinelles Lernen eingesetzt werden kann, um die Laufzeit von Tasks vorherzusagen.

3

Google bills in minute-level increments (with a 10-minute minimum charge), so you don’t pay for unused ” computing time.“ (Onlineressource http://cloud.google.com/products/compute-engine/(abgerufen am 8.2.2014))

179

Literaturverzeichnis [20009]

European Telecommunications Standards Institute - ETSI: Real-time Transport Protocol (RTP) usage model (3GPP TR 26.937 version 8.0.0 Release 8). Version: 2009. http://www.etsi.org/deliver/etsi_tr/126900_126999/ 126937/08.00.00_60/tr_126937v080000p.pdf. 2009. – Technischer Bericht. – Abgerufen am 19.5.2014

[20112]

IEEE Computer Society: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. Version: M¨arz 2012. http: //standards.ieee.org/getieee802/download/802.11-2012.pdf. 2012. – Technischer Bericht. – Abgerufen am 19.5.2014

[ACGS04]

Ammons, Glenn ; Choi, Jong-Deok ; Gupta, Manish ; Swamy, Nikhil: Finding and Removing Performance Bottlenecks in Large Systems. In: Proceedings of the 18th European Conference on Object-Oriented Programming (ECOOP), Springer, 2004, S. 172–196

[AFG+ 09]

Armbrust, Michael ; Fox, Armando ; Griffith, Rean ; Joseph, Anthony D. ; Katz, Randy H. ; Konwinski, Andrew ; Lee, Gunho ; Patterson, David A. ; Rabkin, Ariel ; Stoica, Ion ; Zaharia, Matei: Above the Clouds: A Berkeley View of Cloud Computing / EECS Department, University of California, Berkeley. 2009 (UCB/EECS-2009-28). – Technischer Bericht

[Ahl14]

Ahlers, Ernst: Rasante Datenjongleure - 13 Gigabit-WLAN-Router im Vergleich. In: c’t magazin f¨ ur computer technik 1/2014 (2014), S. 78–90. – ISSN 07248679

[AZ06]

Assaad, Mohamad ; Zeghlache, Djamal: TCP Performance over UMTSHSDPA Systems. Taylor & Francis, 2006. – ISBN 9780849368387

[Ban06]

Banks, Tim: Web Services Resource Framework (WSRF)–Primer v1. 2. http://docs.oasis-open.org/wsrf/wsrf-primer-1.2-primer-cd-02.pdf, Mai 2006. – Abgerufen am 19.5.2014

[BDF+ 03]

Barham, Paul ; Dragovic, Boris ; Fraser, Keir ; Hand, Steven ; Harris, Tim ; Ho, Alex ; Neugebauer, Rolf ; Pratt, Ian ; Warfield, Andrew: Xen and the Art of Virtualization. In: Proceedings of the 19th Symposium on Operating Systems Principles (SOSP), ACM, 2003, S. 164–177

[BDGS08]

Braun, Torsten ; Diaz, Michel ; Gabeiras, Jose E. ; Staub, Thomas: End-toEnd Quality of Service Over Heterogeneous Networks. Springer, 2008. – ISBN 9783540791201

[BEK+ 00]

Box, Don ; Ehnebuske, David ; Kakivaya, Gopal ; Layman, Andrew ; Mendelsohn, Noah ; Nielsen, Henrik F. ; Thatte, Satish ; Winer, Dave: Simple

180

Literaturverzeichnis

Object Access Protocol (SOAP) 1.1. http://www.w3.org/TR/soap/, 2000. – Abgerufen am 19.5.2014 [BFGY08]

Braberman, Victor ; Fernandez, Federico ; Garbervetsky, Diego ; Yovine, Sergio: Parametric Prediction of Heap Memory Requirements. In: Proceedings of the 7th International Symposium on Memory Management (ISMM), ACM, 2008, S. 141–150

[BGH+ 06]

Blackburn, Stephen M. ; Garner, Robin ; Hoffmann, Chris ; Khang, Asjad M. ; McKinley, Kathryn S. ; Bentzur, Rotem ; Diwan, Amer ; Feinberg, Daniel ; Frampton, Daniel ; Guyer, Samuel Z. ; Hirzel, Martin ; Hosking, Antony ; Jump, Maria ; Lee, Han ; Moss, J. Eliot B. ; Phansalkar, Aashish ; Stefanovic, Darko ; VanDrunen, Thomas ; Dincklage, Daniel von ; Wiedermann, Ben: The DaCapo Benchmarks: Java Benchmarking Development and Analysis. In: Proceedings of the 21st ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 2006), ACM, 2006, S. 169–190

[BK11]

Basole, Rahul ; Karla, J¨ urgen: Entwicklung von Mobile-Platform-EcosystemStrukturen und -Strategien. In: WIRTSCHAFTSINFORMATIK 53 (2011), Nr. 5, S. 301–311. – ISSN 09376429

[BMB+ 05]

Bless, Roland ; Mink, Stefan ; Blaß, Erik-Oliver ; Conrad, Michael ; Hof, Hans-Joachim ; Kutzner, Kendy ; Sch¨ oller, Marcus: Sichere Netzwerkkommunikation - Grundlagen, Protokolle und Architekturen. Springer, 2005. – ISBN 9783540278962

[Bra13]

Brandt, Siegmund: Datenanalyse f¨ ur Naturwissenschaftler und Ingenieure: Mit statistischen Methoden und Java-Programmen. Springer Spektrum, 2013. – ISBN 9783642376634

[BS96]

Buss, Arnold H. ; Stork, Kirk A.: Discrete Event Simulation on the World Wide Web using Java. In: Proceedings of the 28th Conference on Winter Simulation (WSC), IEEE, 1996, S. 780–785

[BSMM12]

Bronstein, Ilja N. ; Semendjajew, Konstantin A. ; Musiol, Gerhard ; M¨ uhlig, Heiner: Taschenbuch der Mathematik. 2012. – ISBN 3808556706

[CBC+ 10]

Cuervo, Eduardo ; Balasubramanian, Aruna ; Cho, Dae-ki ; Wolman, Alec ; Saroiu, Stefan ; Chandra, Ranveer ; Bahl, Paramvir: MAUI: Making Smartphones Last Longer with Code Offload. In: Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services (MobiSys), ACM, 2010, S. 49–62

[CFM04]

Capone, Antonio ; Fratta, Luigi ; Martignon, Fabio: Bandwidth Estimation Schemes for TCP over Wireless Networks. In: IEEE Transactions on Mobile Computing 3 (2004), Nr. 2, S. 129–143. – ISSN 15361233

[CIM+ 11]

Chun, Byung-Gon ; Ihm, Sunghwan ; Maniatis, Petros ; Naik, Mayur ; Patti, Ashwin: CloneCloud: Elastic Execution between Mobile Device and Cloud. In:

181

Literaturverzeichnis

Proceedings of the 6th Conference on Computer Systems (EuroSys), ACM, 2011, S. 301 – 314 [CLK+ 11]

Cidon, Asaf ; London, Tomer M. ; Katti, Sachin ; Kozyrakis, Christos ; Rosenblum, Mendel: MARS: Adaptive Remote Execution for Multi-threaded Mobile Devices. In: Proceedings of the 3rd Workshop on Networking, Systems, and Applications on Mobile Handhelds (MobiHeld), ACM, 2011, S. 1–6

[CLRS01]

Cormen, Thomas H. ; Leiserson, Charles E. ; Rivest, Ronald L. ; Stein, Clifford: Introduction To Algorithms. MIT Press, 2001. – ISBN 9780262032933

[CM99]

Chen, Xiangping ; Mohapatra, Prasant: Providing Differentiated Service from an Internet Server. In: Proceedings of the 8th International Conference on Computer Communications and Networks (ICCCN), IEEE, 1999, S. 214–217

[CM10]

Chun, Byung-Gon ; Maniatis, Petros: Dynamically Partitioning Applications between Weak Devices and Clouds. In: Proceedings of the 1st Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond, ACM, 2010, S. 7:1–7:5

[Com06]

Comer, Douglas E.: Internetworking with TCP/IP.: Principles, protocols, and architecture. Vol. 1. 5th Edition. Prentice-Hall International, 2006. – ISBN 9780131876712

[CRB11]

Calheiros, Rodrigo N. ; Ranjan, Rajiv ; Buyya, Rajkumar: Virtual Machine Provisioning Based on Analytical Performance and QoS in Cloud Computing Environments. In: Proceedings of the International Conference on Parallel Processing (ICPP), IEEE, 2011, S. 295–304

[Cro06]

Crockford, Douglas: The application/json Media Type for JavaScript Object Notation (JSON). http://tools.ietf.org/html/rfc4627, Juli 2006. – Abgerufen am 19.5.2014

[DLNW11]

Dinh, Hoang T. ; Lee, Chonho ; Niyato, Dusit ; Wang, Ping: A Survey of Mobile Cloud Computing: Architecture, Applications, and Approaches. In: Wireless Communications and Mobile Computing (2011). – ISSN 15308677

[Eck12]

Eckert, Claudia: IT-Sicherheit: Konzepte - Verfahren - Protokolle. 7, u ¨berarbeitete und erweiterte Auflage. Oldenbourg Wissenschaftsverlag, 2012. – ISBN 9783486706871

[Emm03]

Emmerich, Wolfgang: Konstruktion von verteilten Objekten. dpunkt-Verlag, 2003 (dpunkt-Lehrbuch). – ISBN 9783898641401

[Erl06]

Erl, Thomas: Service-Oriented Architecture: Concepts, Technology, And Design. Pearson Education, 2006. – ISBN 9788131714904

[FE10]

Furht, Borko (Hrsg.) ; Escalante, Armando (Hrsg.): Handbook of Cloud Computing. Springer, 2010. – ISBN 9781441965233

182

Literaturverzeichnis

[Feh12]

Feher, Andrija: Entwurf und Analyse eines skalierbaren Web-Dienstes zur verteilten Compilierung auf der Amazon EC2 Cloud-Infrastruktur, Universit¨ at Bayreuth, Bachelorarbeit, 2012

[FGM+ 99]

Fielding, Roy ; Gettys, J ; Mogul, J ; Frystyk, H ; Masinter, L ; Leach, P ; Berners-Lee, T: RFC 2616-Hypertext Transfer Protocol. http://www.ietf.org/rfc/rfc2616.txt, Juni 1999. – Abgerufen am 20.6.2013

[FHR09]

Ferber, Marvin ; Hunold, Sascha ; Rauber, Thomas: Load Balancing Concurrent BPEL Processes by Dynamic Selection of Web Service Endpoints. In: Proceedings of the International Conference on Parallel Processing Workshops (ICPPW), IEEE, 2009, S. 290–297

[Fie00]

Fielding, Roy T.: Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine, Doktorarbeit, 2000

[FK04]

Foster, Ian T. ; Kesselman, Carl.: The Grid 2: Blueprint for a New Computing Infrastructure. Elsevier Limited, Oxford, 2004 (The Elsevier Series in Grid Computing). – ISBN 9781558609334

[FKL09]

Fahrmeir, Ludwig ; Kneib, Thomas ; Lang, Stefan: Regression. Springer, 2009. – ISBN 9783642018374

[For12]

Forbes.com, Trefis Team (verschiedene Autoren): Can Intel Challenge ARM’s Mobile Dominance? http://www.forbes.com/sites/greatspeculations/2012/11/09/can-intelchallenge-arms-mobile-dominance/, Nov 2012. – Abgerufen am 15.10.2013

[Fos05]

Foster, Ian: Globus Toolkit Version 4: Software for Service-Oriented Systems. In: Proceedings of the International Conference on Network and Parallel Computing, Springer, 2005 (NPC), S. 2–13

[FR12]

Ferber, Marvin ; Rauber, Thomas: Mobile Cloud Computing in 3G Cellular Networks using Pipelined Tasks. In: Proceedings of the European Conference on Service-Oriented and Cloud Computing (ESOCC), Springer, 2012, S. 192–199

[FRH10]

Ferber, Marvin ; Rauber, Thomas ; Hunold, Sascha: Combining ObjectOriented Design and SOA with Remote Objects over Web Services. In: Proceedings of the 8th European Conference on Web Services (ECOWS), IEEE, 2010, S. 83–90

[Fri12]

Fries, Aidan: The use of Java in large scientific applications in HPC environments, Universitat de Barcelona, Doktorarbeit, November 2012

[FRTH12]

Ferber, Marvin ; Rauber, Thomas ; Torres, Mario Henrique C. ; Holvoet, Tom: Resource Allocation for Cloud-Assisted Mobile Applications. In: Proceedings of the 5th International Conference on Cloud Computing (CLOUD), IEEE, 2012, S. 400–407

[FZ94]

Forman, George H. ; Zahorjan, John: The Challenges of Mobile Computing. In: Computer 27 (1994), April, Nr. 4, S. 38 –47. – ISSN 00189162

183

Literaturverzeichnis

[FZRL08]

Foster, Ian ; Zhao, Yong ; Raicu, Ioan ; Lu, Shiyong: Cloud Computing and Grid Computing 360-Degree Compared. In: Proceedings of the Grid Computing Environments Workshop (GCE), 2008, S. 1–10

[GB09]

Griffiths, Dawn ; Beyer, J¨org: Statistik von Kopf bis Fuß. O’Reilly, 2009 (Ein Buch zum Mitmachen und Verstehen). – ISBN 9783897218918

[GGW10]

Gong, Zhenhuan ; Gu, Xiaohui ; Wilkes, J.: PRESS: PRedictive Elastic ReSource Scaling for Cloud Systems. In: Proceedings of the International Conference on Network and Service Management (CNSM), IEEE, 2010, S. 9–16

[GJ79]

Garey, Michael R. ; Johnson, David S.: Computers and Intractability: A Guide to the Theory of NP-Completeness. W. H. Freeman, 1979. – ISBN 0716710455

[GJS+ 13]

Gosling, James ; Joy, Bill ; Steele, Guy ; Bracha, Gilad ; Buckley, Alex: The Java Language Specification, Java SE 7 Edition. Addison-Wesley, 2013 (Java Series). – 672 S. – ISBN 9780133260441

[Gr¨ u08]

Gr¨ une, Lars: Numerische Mathematik I (Dritte Auflage). Version: Wintersemester 2007/2008. http://num.math.uni-bayreuth.de/de/ team/Gruene_Lars/lecture_notes/num1/num1_3.pdf. Vorlesungsskript. – Abgerufen am 19.5.2014

[GTF06]

Geoffray, Nicolas ; Thomas, Ga¨el ; Folliot, Bertil: Transparent and Dynamic Code Offloading for Java Applications. In: Proceedings of the Confederated International Conference on On the Move to Meaningful Internet Systems: CoopIS, DOA, GADA, and ODBASE, 2006, S. 1790–1806

[HAMJ02]

Hsu, Rein-Lien ; Abdel-Mottaleb, Mohamed ; Jain, Anil K.: Face Detection in Color Images. In: IEEE Transactions on Pattern Analysis and Machine Intelligence 24 (2002), Nr. 5, S. 696–706

[HBDTD07] Hens, Raf ; Boone, Bas ; De Turck, Filip ; Dhoedt, Bart: Runtime Deployment Adaptation for Resource Constrained Devices. In: Proceedings of the International Conference on Pervasive Services (ICPS), IEEE, 2007, S. 335–340 [HC10]

Hunter, Jason ; Crawford, William: Java Servlet Programming. O’Reilly Media, 2010. – ISBN 9781449390679

[HL08]

Hafner, Katie ; Lyon, Metthew: Arpa Kadabra oder die Anf¨ ange des Internet. Dpunkt.Verlag GmbH, 2008. – ISBN 9783898645515

[Hun09]

Hunold, Sascha: Evaluation der Leistungsf¨ ahigkeit von gemischt-parallelen Programmen in homogenen und heterogenen Umgebungen unter Ber¨ ucksichtigung effizienter Schedulingstrategien, Universit¨at Bayreuth, Doktorarbeit, 2009

[Int12]

International Data Corporation (IDC): Smartphone Market Hits All-Time Quarterly High Due To Seasonal Strength and Wider Variety of Offerings, According to IDC. http://www.businesswire.com/news/home/20120206005252/en/SmartphoneMarket-Hits-All-Time-Quarterly-High-Due, Feb 2012. – Abgerufen am 15.10.2013

184

Literaturverzeichnis

[IOY+ 11]

Iosup, Alexandru ; Ostermann, Simon ; Yigitbasi, Nezih ; Prodan, Radu ; Fahringer, Thomas ; Epema, Dick: Performance Analysis of Cloud Computing Services for Many-Tasks Scientific Computing. In: IEEE Transactions on Parallel and Distributed Systems 22 (2011), Juni, Nr. 6, S. 931 –945. – ISSN 10459219

[IYE11]

Iosup, Alexandru ; Yigitbasi, Nezih ; Epema, Dick: On the Performance Variability of Production Cloud Services. In: Proceedings of the 11th International Symposium on Cluster, Cloud and Grid Computing (CCGrid), IEEE, 2011, S. 104 –113

[JA11]

Jayasinghe, Deepal ; Azeez, Afkham: Apache Axis2 Web Services. Packt Open Source Pub., 2011. – ISBN 9781849511575

[KBS05]

Krafzig, Dirk ; Banke, Karl ; Slama, Dirk: Enterprise Soa: Service-Oriented Architecture Best Practices. Prentice Hall, 2005 (The Coad Series). – ISBN 9780131465756

[KEEH10]

Kaspar, Dominik ; Evensen, Kristian ; Engelstad, Paal ; Hansen, Audun F.: Using HTTP Pipelining to Improve Progressive Download over Multiple Heterogeneous Interfaces. In: Proceedings of the International Conference on Communications (ICC 2010), IEEE, 2010, S. 1 –5

[KL10]

Kumar, Karthik ; Lu, Yung-Hsiang: Cloud Computing for Mobile Users: Can Offloading Computation Save Energy? In: Computer 43 (2010), Nr. 4, S. 51–56. – ISSN 00189162

[Koh05]

Kohn, Wolfgang: Statistik: Datenanalyse und Wahrscheinlichkeitsrechnung. Springer, 2005 (Statistik und ihre Anwendungen). – ISBN 9783540216773

[KPKB10]

Kemp, Roelof ; Palmer, Nicholas ; Kielmann, Thilo ; Bal, Henri: Cuckoo: a Computation Offloading Framework for Smartphones. In: Proceedings of the 2nd International Conference on Mobile Computing, Applications, and Services (MobiCASE), Springer, 2010, S. 59–79

[KR08]

Kurose, James F. ; Ross, Keith W.: Computernetzwerke: Der Top-DownAnsatz. Pearson Studium, 2008 (IT - Informatik). – ISBN 9783827373304

[Leh03]

Lehner, Franz: Mobile und drahtlose Informationssysteme: Technologien, Anwendungen, M¨ arkte. Springer, 2003. – ISBN 9783642556265

[Leu04]

Leung, Joseph Y-T.: Handbook of Scheduling: Algorithms, Models, and Performance Analysis. CRC Press, Inc., 2004. – ISBN 1584883979

[LML+ 11]

Lenk, Alexander ; Menzel, Michael ; Lipsky, Johannes ; Tai, Stefan ; Offermann, Philipp: What Are You Paying For? Performance Benchmarking for Infrastructure-as-a-Service Offerings. In: Proceedings of the International Conference on Cloud Computing (CLOUD 2011), IEEE, 2011, S. 484 –491

185

Literaturverzeichnis

[LYBB13]

Lindholm, Tim ; Yellin, Frank ; Bracha, Gilad ; Buckley, Alex: The Java Virtual Machine Specification, Java SE 7 Edition. Addison-Wesley, 2013 (Java Series). – 608 S. – ISBN 9780133260441

[LYKZ10]

Li, Ang ; Yang, Xiaowei ; Kandula, Srikanth ; Zhang, Ming: CloudCmp: Comparing Public Cloud Providers. In: Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement, ACM, 2010, S. 1 – 14

[Mat13]

Matsudaira, Kate: Making the Mobile Web Faster. In: Communications of the ACM 56 (2013), M¨ arz, Nr. 3, S. 56–61. – ISSN 00010782

[Mau04]

Maufer, Thomas: A Field Guide to Wireless LANs for Administrators and Power Users. Prentice Hall Professional Technical Reference, 2004. – ISBN 9780131014060

[MD11]

Mazzucco, Michele ; Dumas, Marlon: Achieving Performance and Availability Guarantees with Spot Instances. In: Proceedings of the 13th International Conference on High Performance Computing and Communications (HPCC), IEEE, 2011, S. 296–303

[MG11]

Mell, Peter ; Grance, Timothy: The NIST Definition of Cloud Computing / National Institute of Standards and Technology. Version: 2011. http: //csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf. 2011. – Technischer Bericht. – Abgerufen am 19.5.2014

[MM07]

Moodie, Matthew ; Mittal, Kunal: Pro Apache Tomcat 6. Apress, 2007 (Expert’s voice in Java technology). – ISBN 9781430203780

[MPH10]

Membrey, Peter ; Plugge, Eelco ; Hawkins, Tim: The Definitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing. Apress, 2010 (Books for professionals by professionals). – ISBN 9781430230519

[MPPS+ 12] Mazzola Paluska, Justin ; Pham, Hubert ; Schiele, Gregor ; Becker, Christian ; Ward, Steve: Vision: a Lightweight Computing Model for FineGrained Cloud Computing. In: Proceedings of the 3rd Workshop on Mobile Cloud Computing and Services, ACM, 2012, S. 3–8 [MW12]

Meeker, Mary ; Wu, Liang: 2012 Internet http://www.kpcb.com/insights/2012-internet-trends, May 2012. – rufen am 6.2.2013

[NA08]

Nixon, Mark S. ; Aguado, Alberto S.: Feature Extraction & Image Processing. Academic, 2008 (Academic Press). – ISBN 9780123725387

[Nag09]

Nagel, Raik: Erweiterung des Threadmodelles fur den Einsatz in verteilten und heterogenen Systemumgebungen, Universit¨at Bayreuth, Doktorarbeit, 2009

[Nie08]

Niemeier, Wolfgang: Ausgleichungsrechnung: Statistische Auswertemethoden. Walter de Gruyter, 2008. – ISBN 9783110190557

186

Trends. Abge-

Literaturverzeichnis

[Obj12]

Object Management Group (OMG): Common Object Request Broker Architecture (CORBA). http://www.omg.org/spec/CORBA/, November 2012. – Abgerufen am 19.5.2014

[OK10]

Oprescu, Anna ; Kielmann, Thilo: Bag-of-Tasks Scheduling under Budget Constraints. In: Second International Conference on Cloud Computing Technology and Science (CloudCom), IEEE, 2010, S. 351–359

[OM04]

Orlam¨ under, D. ; Mascolus, W.: Computergrafik und OpenGL: eine syste¨ matische Einf¨ uhrung ; mit 26 Ubungen. Fachbuchverl. Leipzig im Carl-HanserVerlag, 2004. – ISBN 9783446228375

[ORA11]

ORACLE: Remote Method Invocation (RMI). http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html, 2011. – Abgerufen am 19.5.2014

[Pap03]

Papazoglou, Mike P.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of the 4th International Conference on Web Information Systems Engineering (WISE), IEEE, 2003, S. 3 – 12

[PH13]

Pauler, Wolfgang ; Heinfling, Benjamin: Das beste Netz aller Zeiten. http://www.chip.de/artikel/Der-haerteste-Handy-Netztest-DeutschlandsTelekom-Vodafone-O2-und-E-Plus-im-Test 63944005.html, September 2013. – Abgerufen am 5.1.2014

[PKKB09]

Palmer, Nicholas ; Kemp, Roelof ; Kielmann, Thilo ; Bal, Henri: Ibis for Mobility: Solving Challenges of Mobile Computing Using Grid Techniques. In: Proceedings of the 10th Workshop on Mobile Computing Systems and Applications (HotMobile), ACM, 2009, S. 17:1 – 17:6

[PSS+ 12]

Pawluk, Przemyslaw ; Simmons, Bradley ; Smit, Michael A. ; Litoiu, Marin ; Mankovski, Serge: Introducing STRATOS: A Cloud Broker Service. In: Proceedings of the 5th International Conference on Cloud Computing (CLOUD), IEEE, 2012, S. 891–898

[Rap04]

Rappa, Michael A.: The utility business model and the future of computing services. In: IBM Systems Journal 43 (2004), Nr. 1, S. 32 – 42

[RDG11]

Roy, Nilabja ; Dubey, Abhishek ; Gokhale, Aniruddha: Efficient Autoscaling in the Cloud Using Predictive Models for Workload Forecasting. In: Proceedings of the International Conference on Cloud Computing (CLOUD), IEEE, 2011, S. 500–507

[RHFN+ 12] Rodr´ıguez-Haro, Fernando ; Freitag, Felix ; Navarro, Leandro ; ´ nchez-sa ´ nchez, Efra´ın ; Far´ıas-Mendoza, Nicandro ; GuerreroHerna ´n ˜ ez, Juan A. ; Gonza ´ lez-Potes, Apolinar: A summary of virtualization Iba techniques. In: Procedia Technology 3 (2012), Nr. 0, S. 267 – 272. – ISSN 22120173

187

Literaturverzeichnis

[RMK+ 96]

Rekhter, Y. ; Moskowitz, B. ; Karrenberg, D. ; Groot, G. J. ; Lear, E.: RFC 1918 – Address Allocation for Private Internets. http://www.rfceditor.org/info/rfc1918, Februar 1996. – Abgerufen am 19.5.2014

[RR00]

Rauber, Thomas ; R¨ unger, Gudula: Parallele Und Verteilte Programmierung. Springer, 2000 (Springer-Lehrbuch). – ISBN 9783540660095

[Sat96]

Satyanarayanan, Mahadev: Fundamental Challenges in Mobile Computing. In: Proceedings of the 15th annual Symposium on Principles of Distributed Computing (PODC), ACM, 1996, S. 1 – 7

[Sau13]

Sauter, Martin: Grundkurs Mobile Kommunikationssysteme: UMTS, HSDPA und LTE, GSM, GPRS, Wireless LAN und Bluetooth. 5. u ¨berarbeitete und erweiterte Auflage. Vieweg Verlag, Friedr, & Sohn Verlagsgesellschaft mbH, 2013. – ISBN 978–3–658–01461–2

[SBCD09]

Satyanarayanan, Mahadev ; Bahl, Paramvir ; Caceres, Ramon ; Davies, Nigel: The Case for VM-based Cloudlets in Mobile Computing. In: Pervasive Computing, IEEE 8 (2009), Nr. 4, S. 14 – 23

[SF05]

Su, Ya-Yunn ; Flinn, Jason: Slingshot: Deploying Stateful Services in Wireless Hotspots. In: Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services (MobiSys), ACM, 2005, S. 79–92

[SF12]

Sadalage, Pramodkumar J. ; Fowler, Martin: NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Pearson Education, 2012. – ISBN 9780133036121

[SH07]

Sachs, Lothar ; Hedderich, J¨ urgen: Angewandte Statistik: Methodensammlung Mit R. Springer, 2007. – ISBN 9783540321613

[SKS+ 11]

Saripalli, Prasad ; Kiran, G.V.R. ; Shankar, Ravi R. ; Narware, Harish ; Bindal, Nitin: Load Prediction and Hot Spot Detection Models for Autonomic Cloud Computing. In: Proceedings of the 4th International Conference on Utility and Cloud Computing (UCC), IEEE, 2011, S. 397–402

[SM10]

Salomon, David ; Motta, Giovanni: Handbook of Data Compression. Springer, 2010. – ISBN 9781848829039

[Sos10]

Sosinsky, Barrie: Cloud Computing Bible. Wiley, 2010 (Bible Series). – ISBN 9781118023990

[SSW04]

Sloss, Andrew ; Symes, Dominic ; Wright, Chris: ARM System Developer’s Guide: Designing and Optimizing System Software. Elsevier Science, 2004 (The Morgan Kaufmann Series in Computer Architecture and Design). – ISBN 9780080490496

[Sta07]

Stallings, William: Network Security Essentials - Applications and Standards. Third Edition. Pearson Education, 2007. – ISBN 0132380331

188

Literaturverzeichnis

[TJA12]

Thomas, Bryce ; Jurdak, Raja ; Atkinson, Ian: SPDYing Up the Web. In: Communications of the ACM 55 (2012), S. 64–73. – ISSN 00010782

[TLKF09]

Tapia, Pablo ; Liu, Jun ; Karimli, Yasmin ; Feuerstein, Martin: HSPA Performance and Evolution: A practical perspective. Wiley, 2009. – ISBN 9780470742051

[Tou02]

Toutenburg, Helge: 9783642573484

[TTH05]

Tabatabaee, Vahid ; Tiwari, Ananta ; Hollingsworth, Jeffrey K.: Parallel Parameter Tuning for Applications with Performance Variability. In: Proceedings of the ACM/IEEE Conference on Supercomputing (SC’05), 2005, S. 57–68

[Tys99]

Tyszer, Jerzy: Object-Oriented Computer Simulation of Discrete-Event Systems. Springer, 1999. – ISBN 9780792385066

[Ull12]

Ullenboom, Christian: Java ist auch eine Insel: Das umfassende Handbuch. Galileo Press, 2012 (Galileo Computing). – ISBN 9783836218023

Lineare Modelle:.

Physica-Verlag, 2002. –

ISBN

[VRMCL08] Vaquero, Luis M. ; Rodero-Merino, Luis ; Caceres, Juan ; Lindner, Maik: A Break in the Clouds: Towards a Cloud Definition. In: SIGCOMM Computer Communication Review 39 (2008), Nr. 1, S. 50 – 55. – ISSN 01464833 [WBTY11]

Wieder, Philipp (Hrsg.) ; Butler, Joe M. (Hrsg.) ; Theilmann, Wolfgang (Hrsg.) ; Yahyapour, Ramin (Hrsg.): Service Level Agreements for Cloud Computing. Springer, 2011. – ISBN 9781461416135

[WNLL12]

Wang, Wei ; Niu, Di ; Li, Baochun ; Liang, Ben: Dynamic Cloud Resource Reservation via Cloud Brokerage. In: Proceedings of the 33rd International Conference on Distributed Computing Systems (ICDCS), IEEE, 2012, S. 400– 409

[WSKV08]

Wang, Xin ; Schulzrinne, Henning ; Kandlur, Dilip ; Verma, Dinesh: Measurement and analysis of LDAP performance. In: IEEE/ACM Transactions on Networking 16 (2008), Februar, Nr. 1, S. 232–243. – ISSN 10636692

[ZBD+ 03]

Zeng, Liangzhao ; Benatallah, Boualem ; Dumas, Marlon ; Kalagnanam, Jayant ; Sheng, Quan Z.: Quality Driven Web Services Composition. In: Proceedings of the 12th International Conference on World Wide Web (WWW), ACM, 2003, S. 411–421

189

190

Anhang

191

Anhang A ¨ Ubersicht u ¨ber die verwendeten Rechner und Mobilger¨ ate F¨ ur die Durchf¨ uhrung verschiedener Experimente in dieser Arbeit wurden die nachfolgend tabellarisch beschriebenen vier Rechner und Mobilger¨ate benutzt. Tabelle A.1: Verwendete Rechner und Mobilger¨ate Hersteller DELL SONY Name Streak 7 Xperia P Gattung Tablet (7”) Smartphone (4”) Architektur ARMv7 (Nvidia Tegra 2) ARMv7 (ST-Ericsson Novathor U8500) Betriebssystem Android 3.2 Android 4.1 Displayauflo sung 800x480 960x540 ¨ 1 CPU-Kerne 2 (Cortex-A9 ) @ 1 GHz 2 (Cortex-A91 ) @ 1 GHz RAM 512 MB 1 GB WLAN 802.11 b/g/n 802.11 b/g/n UMTS/HSPA HSPA HSPA+ Hersteller Name Gattung Architektur Betriebssystem Displayaufl¨ osung CPU-Kerne RAM WLAN UMTS/HSPA

DELL Latitude E6530 Laptop (15”) x86-64 (Intel Core i7-3720QM) Linux Mint 13 (Kernel 3.2) 1920x1080 4 @ 2,6 GHz (Turbo 3,6 GHz) + HT2 8 GB 802.11 b/g/n HSPA

Asus Eee PC 1000H Netbook (10”) x86 (Intel Atom N270) Microsoft Windows XP 1024x600 1 @ 1,6 GHz + HT2 1 GB 820.11 b/g/n HSPA+ via USB Dongle

1) Cortex-A9 ist ein 32-bit Prozessordesign (ARMv7 Befehlssatz) mit max. 4 CPU-Kernen. 2) HT = b Hyperthreading

192

Anhang B Eigenschaften von Diensten ausgew¨ ahlter IaaS Anbieter Nachfolgend sind die Angebote einiger IaaS-Anbieter zusammengestellt, die On-Demand Instanzen nach dem Selbstbedienungsprinzip anbieten, diese mindestens auf Stundenbasis abrechnen, in Europa verf¨ ugbar sind und Linux-Instanzen anbieten. Preisangaben f¨ ur Windows sind teilweise zur Information mit angegeben. Die Angebote von Rackspace Cloud Servers, Amazon Elastic Compute Cloud (EC2), GoGrid , Windows Azure und Google Compute Engine verwenden das gleiche pay-as-you-go Abrechnungsmodell und bieten vorkonfigurierte Instanztypen an. Sie sind gut miteinander vergleichbar. Flexiscale und Elastic Hosts verwenden teilweise Prepaid Abrechnungsmodelle und bieten keine festen sondern anpassbare vorkonfigurierte Instanztypen an. Zudem sind diese die einzigen Anbieter, die auch eingehenden Datentransfer Abrechnen.

Rackspace Cloud Servers Rechenzentren in sechs Regionen: Nord-Virginia (USA), Dallas (USA), Chicago (USA), London (UK), Sydney (Australien) , Hong Kong (China). Tabelle B.1: Liste verf¨ ugbarer Instanztypen von Rackspace Cloud Servers in London (UK) Typ

vCPU

1 GB Performance 2 GB Performance 4 GB Performance 8 GB Performance 15 GB Performance 30 GB Performance 60 GB Performance 90 GB Performance 120 GB Performance

1 2 4 8 4 8 16 24 32

RAM (GB)

Instanz-Speicher (GB)

1 2 4 8 15 30 60 90 120

20 SSD 40+20 SSD 40+40 SSD 40+80 SSD 40+150 SSD 40+300 SSD 40+600 SSD 40+900 SSD 40+1200 SSD

Netzwerkleistung zum Internet in Mbit/s 80 160 320 640 500 1000 2000 3000 4000

Kosten Linux in £/h (Windows) 0,03 (n.v.) 0,06 (0,075) 0,12 (0,15) 0,24 (0,3) 0,5 (0,59) 1 (1,18) 2 (2,36) 3 (3,54) 4 (4,72)

vCPU = virtuelle CPU (Anzahl von logischen CPU-Kernen, die einer Instanz zur Verf¨ ugung stehen)

Tabelle B.2: Daten¨ ubertragungskosten von Rackspace Cloud Servers in London (UK) Ausgangsbandbreitennutzung Kosten in £/GB

0–10 TB

10–50 TB

50–200 TB

200–500 TB

500– 1024 TB

Mehr als 1024 TB

0,08

0,07

0,06

0,05

0,04

0,04

Stand 6.3.2014 http://www.rackspace.com/de/cloud/servers

193

Anhang

Amazon Elastic Compute Cloud (EC2) Rechenzentren in acht Regionen verf¨ ugbar: Europa (Irland), USA Ost (Nord-Virginia), USA West (Oregon), USA West (Nordkalifornien), Asien-Pazifik (Singapur), Asien-Pazifik (Tokio), Asien-Pazifik (Sydney), S¨ udamerika (S˜ ao Paolo).

Tabelle B.3: Liste verf¨ ugbarer Amazon EC2 Instanztypen in EU Irland (Auszug) InstanzFamilie

InstanzTyp

vCPU ECUs RAM (GB)

InstanzSpeicher (GB)

Netzwerkleistung

1

1

1,7

1 x 160

Niedrig

Kosten Linux in US $/h (Windows) 0,065 (0,091)

1

2

3,75

1 x 410

Mittel

0,13 (0,182)

m1.large

Prozessor-architektur 32-Bit od. 64-Bit 32-Bit od. 64-Bit 64-Bit

Allgemeiner Zweck Allgemeiner Zweck Allgemeiner Zweck Allgemeiner Zweck Allgemeiner Zweck Allgemeiner Zweck Recheneffizienz-optimiert Recheneffizienz-optimiert Recheneffizienz-optimiert RAMoptimiert RAMoptimiert RAMoptimiert RAMoptimiert Speicheroptimiert Speicheroptimiert MicroInstances GPUInstances

m1.small

2

4

7,5

2 x 420

Mittel

0,26 (0,364)

m1.xlarge

64-Bit

4

8

15

4 x 420

Hoch

0,52 (0,728)

m3.xlarge

64-Bit

4

13

15

nur EBS

Mittel

0,495 (0,702)

m3.2xlarge

64-Bit

8

26

30

nur EBS

Hoch

0,99 (1,404)

c1.medium

2

5

1,7

1 x 350

Mittel

0,165 (0,225)

c1.xlarge

32-Bit od. 64-Bit 64-Bit

8

20

7

4 x 420

Hoch

0,66 (0,9)

cc2.8xlarge

64-Bit

32

88

60,5

4 x 840

10 Gigabit

2,7 (2,97)

m2.xlarge

64-Bit

2

6,5

17,1

1 x 420

Mittel

0,46 (0,51)

m2.2xlarge

64-Bit

4

13

34,2

1 x 850

Mittel

0,92 (1,02)

m2.4xlarge

64-Bit

8

26

68,4

2 x 840

Hoch

1,84 (2,04)

cr1.8xlarge

64-Bit

32

88

244

10 Gigabit

3,75 (3,831)

hi1.4xlarge

64-Bit

16

35

60,5

10 Gigabit

3,10 (3,58)

hs1.8xlarge

64-Bit

16

35

117

2 x 120 SSD 2 x 1024 SSD 24 x 2048

10 Gigabit

4,90 (4,931)

t1.micro

32-Bit od. 64-Bit 64-Bit

1

variabel 33,5

0,615

nur EBS

0,02 (0,035)

22,5

2 x 840

Sehr niedrig 10 Gigabit

m1.medium

cg1.4xlarge

16

2,36 (2,6)

EBS = Elastic Block Store (eine persistente Netzwerkfestplatte einstellbarer Gr¨ oße und Geschwindigkeit zur Verwendung mit EC2-Instanzen)

Tabelle B.4: Daten¨ ubertragungskosten von Amazon EC2 in EU Irland Ausgangsbandbreitennutzung Kosten in $/GB

0–1 GB

1 GB–10 TB

10–50 TB

50–150 TB

150– 500 TB

Mehr als 500 TB

0

0,12

0,09

0,07

0,05

individuell

Stand 6.3.2014 http://aws.amazon.com/de/ec2/.

194

Anhang

GoGrid Rechenzentren in drei Regionen: San Francisco, Kalifornien (USA), Ashburn, Virginia (USA), Amsterdam, Niederlande. Besonderheit: Windows und Linux kosten gleich

Tabelle B.5: Lister verf¨ ugbarer Instanztypen von GoGrid Instanzfamilie

Standard Cloud Servers

SSD Cloud Servers

Raw Disk Cloud Servers

Instanz-Typ

RAM (GB)

X-Small Small Medium Large X-Large XX-Large XXX-Large Small Medium Large X-Large 2X-Large 4X-Large Large X-Large 2X-Large 4X-Large 8X-Large 16X-Large

0,5 GB 1 GB 2 GB 4 GB 8 GB 16 GB 24 GB 2 GB 4 GB 8 GB 16 GB 32 GB 64 GB 8 GB 16 GB 32 GB 64 GB 128 GB 240 GB

vCPU

shared CPU 1 2 4 8 16 24 2 4 8 16 28 40 4 8 16 24 32 40

Datentr¨ agergr¨ oßen (GB)

Netzwerk in Gbit/s

25 50 100 200 400 800 1200 80 SSD 160 SSD 320 SSD 640 SSD 1280 SSD 2199 SSD 1 x 4000 3 x 4000 6 x 4000 12 x 4000 24 x 4000 45 x 4000

1 1 1 1 1 1 1 10 10 10 10 10 10 10 10 10 10 10 10

Kosten Linux/ Windows in US $/h 0,03 0,06 0,12 0,24 0,48 0,96 1,44 0,15 0,30 0,60 1,20 2,04 2,99 0,60 1,50 3,00 5,25 8,93 17,85

Tabelle B.6: Daten¨ ubertragungskosten von GoGrid Ausgangsbandbreitennutzung Kosten in $/GB

0–1 GB

1 GB–1 TB

1–10 TB

10–50 TB

50– 200 TB

Mehr als 200 TB

0

0,12

0,11

0,10

0,09

0,08

Stand 6.3.2014 http://gogrid.com/pricing http://gogrid.com/network-pricing

Windows Azure Rechenzentren in zehn Regionen: USA Ost, USA West, USA Nord Mitte, USA S¨ ud Mitte, Europa Nord, Europa West, Asien Pazifik S¨ udost, Asien Pazifik Ost, Japan Ost, Japan West.

195

Anhang

Tabelle B.7: Liste verf¨ ugbarer Instanztypen von Windows Azure in Europa Instanz-Typ

vCPU

RAM (GB)

Datentr¨ agergr¨ oßen (GB)

Sehr klein (A0)

shared CPU 1 2 4 8 2 4 8

0,768 1,75 3,5 7 14 14 28 56

Klein (A1) Mittel (A2) Groß (A3) Sehr groß (A4) A5 A6 A7

Max. IOPS (500 pro Datentr¨ ager)

Kosten Linux in e/h (Windows)

127 + 20

Max. Datentr¨ ager (jeweils 1 TB) 1

1x500

0,015 (0,015)

127 127 127 127 127 127 127

2 4 8 16 4 8 16

2x500 4x500 8x500 16x500 4x500 8x500 16x500

0,045 (0,068) 0,09 (0,135) 0,179 (0,269) 0,358 (0,537) 0,239 (0,298) 0,477 (0,596) 0,961 (1,192)

+ + + + + + +

70 135 285 605 135 285 605

Tabelle B.8: Daten¨ ubertragungskosten von Windows Azure in Europa (Nord und West) Ausgangsbandbreitennutzung Kosten in e/GB zu ZONE 1 (ZONE 2)

0–5 GB

5 GB–10 TB

10–50 TB

50–150 TB

150– 500 TB

Mehr als 500 TB

0

0,09 (0,15)

0,07 (0,12)

0,06 (0,10)

0,04 (0,09)

individuell

ZONE 1 = Westen USA, Osten USA, USA (Mitte/Norden), USA (Mitte/S¨ uden), Westeuropa, Nordeuropa ZONE 2 = Asien Pazifik (Osten), Asien Pazifik (S¨ udosten)

Stand 6.3.2014 http://www.windowsazure.com/de-de/pricing/details/virtual-machines/

Google Compute Engine Rechenzentren weltweit verteilt. Google unterscheidet nur in die Regionen USA und Europa. Es sind ausschließlich Linux-Instanzen verf¨ ugbar.

Tabelle B.9: Liste verf¨ ugbarer Instanztypen von Google Compute Engine in Europa Instanz-Typ n1-standard-1 n1-standard-2 n1-standard-4 n1-standard-8 n1-standard-16 n1-highmem-2 n1-highmem-4 n1-highmem-8 n1-highmem-16 n1-highcpu-2 n1-highcpu-4 n1-highcpu-8 n1-highcpu-16 f1-micro g1-small

vCPU 1 2 4 8 16 2 4 8 16 2 4 8 16 1 1

RAM (GB) 3,75 7,5 15 30 60 13 26 52 104 1,80 3,60 7,20 14,40 0,60 1,70

GCEUs 2,75 5,5 11 22 44 5,5 11 22 44 5,5 11 22 44 shared CPU, keine Garantie 1,4

Kosten Linux in US$/h 0,114 0,228 0,456 0,912 1,825 0,275 0,549 1,098 2,196 0,146 0,292 0,584 1,167 0,021 0.059

GCEU = Google Compute Engine Unit (ein Google-eigenes Performancemaß zum Vergleich der Verarbeitungsgeschwindigkeiten verschiedener Instanztypen, analog zu Amazons Maß ECU)

196

Anhang

Tabelle B.10: Daten¨ ubertragungskosten von Google Compute Engine Ausgangsbandbreitennutzung Kosten in $/GB zu Americas/EMEA (APAC)

0–1 TB 0,12 (0,21)

1 TB–10 TB 0,11 (0,18)

Mehr als 10 TB 0,08 (0,15)

Americas = Wirtschaftsraum Nord-, Zentral- und S¨ udamerika EMEA = Wirtschaftsraum Europa, Mittlerer Osten und Afrika APAC = Asiatisch-Pazifischer Raum inkl. Japan

VM-Instanzen von Google Compute Engine haben keinen lokalen Festplattenspeicher. Persistenter Speicher wird u ¨ber Compute Engine Disks bereitgestellt. Dabei handelt es sich um via Netzwerk angeschlossenen Block-Speicher ¨ahnlich zu einem Storage Area Network (SAN). Stand 6.3.2014 http://developers.google.com/compute/

Elastic Hosts Rechenzentren in neun Regionen: Europa (London Maidenhead, London Portsmouth & Amsterdam), Nordamerika (San Jose, Los Angeles, San Antonio & Toronto), Asien (Hong Kong), Australien (Sydney) Elastic Hosts bietet keinen vorkonfigurierten Instanztypen an. Instanzen k¨onnen je nach Bedarf konfiguriert werden. Der Preis berechnet sich dadurch jeweils individuell. Nachfolgende Tabelle fasst die Wahlm¨ oglichkeiten zusammen. Tabelle B.11: Lister verf¨ ugbarer Konfigurationsm¨oglichkeiten von Elastic Hosts Eigenschaft CPU RAM Festplatte SSD

Wahlm¨ oglichkeit 1000–20000 MHz 512–32768 MB 0–1862 GB 0–1862 GB

Kosten Linux in e/h 0,03–0,6 0,02–1,28 0–0,36 0–1,81

Windows-Lizenzen m¨ ussen monatlich hinzugekauft werden. Datentraffic kann monatlich als Paket je nach gew¨ unschter Gr¨ oße gekauft werden. Dar¨ uber hinaus werden die Daten¨ ubertragungskosten zu einem h¨ oheren Tarif abgerechnet. Prepaid Datentraffic kostet 0,12 epro GB und dar¨ uber 0,24 epro GB. Es wird sowohl ausgehender wie auch eingehender Datentraffic berechnet. Stand 6.3.2014 http://www.elastichosts.com/pricing-information/

Flexiscale Flexiscale ist in einem Rechenzentrum im S¨ udosten von England beheimatet. Flexiscale verwendet ein Abstraktes Prepaid-Modell zur Abrechnung und unterscheidet sich dadurch stark von anderen IaaS-Anbietern. Cloud Ressourcen, Datentraffic und andere Dienste werden in Units abgerechnet. Diese Units m¨ ussen vorher von realem Geld gekauft werden. 1000 Units kosten beispielsweise 13 e zuz¨ uglich Steuern. Flexiscale bietet verschiedene Kombinationen aus RAM und vCPUS als Instanztypen an. Sie sind in nachfolgender Tabelle zusammengefasst.

197

Anhang

Tabelle B.12: Matrix verf¨ ugbarer Instanztypen von Flexiscale RAM 0,5Gb 1 Gb 2 Gb 4 Gb 6 Gb 8 Gb

1 2 3 5

2

6 10

3

11 15

vCPU Cores 4 5 6

12 16 20

17 21

18 22

7

8

23

24

Es wird kein lokaler Festplattenspeicher benutzt. S¨amtliche Daten inklusive der VM-Images liegen auf einem SAN. Deshalb muss Festplattenkapazit¨at in zwei Auspr¨agungen extra bezahlt werden. Einerseits werden pro GB pro Monat 5 Units berechnet. Außerdem werden pro GB Datentransfer zu/von der Festplatte weitere 2 Units berechnet. S¨amtlicher Datentransfer von und nach außen wird mit 5 Units pro GB berechnet. Stand 6.3.2014 http://www.flexiscale.com/products/flexiscale/pricing/

198

Anhang C Simulationsergebnisse der Ressourcenallokationsstrategien In Kapitel 5.4 wurde durch Simulation das Verhalten zweier Allokationsstretegien f¨ ur CloudRessourcen untersucht. Dazu wurden unter Verwendung einer m¨oglichst realistischen Anfrageverteilung Simulationen mit verschiedenen Anzahlen von Anfragen und Anfragel¨angen durchgef¨ uhrt. Nachfolgend sind die erhaltenen Verteilungen je eines stabilen Simulationslaufs f¨ ur alle simulierten Konfigurationen dargestellt. Die wichtigsten Ergebnisse der Simulationen sind bereits in Tabelle 5.2 zusammengefasst. Variiert wurde die Anfrageanzahl zwischen 100 – 1000000 Anfragen pro Tag und die Anfragel¨ange zwischen 2 s – 1200 s, wobei nur die Diagramme der Anfragel¨ angen zwischen 10 s – 300 s angegeben sind, da die restlichen Diagramme jeweils einem der dargestellten stark gleichen. Daraus ergeben sich 15 Konfigurationen. Jedes Diagramm zeigt die Anzahl aktuell in Bearbeitung befindlicher Anfragen und die Anzahl daf¨ ur ben¨ otigter VM-Instanzen in Abh¨angigkeit der Tageszeit (jeweils 1 Tag) f¨ ur beide Allokationsstrategien an. Zus¨ atzlich ist auch die optimale Verteilung angegeben. 100 Anfragen pro Tag, 60 s Anfragelänge 3

2.5

2.5

2

2 # Anzahl

# Anzahl

100 Anfragen pro Tag, 10 s Anfragelänge 3

1.5

1.5

1

1

0.5

0.5

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit 1000 Anfragen pro Tag, 10 s Anfragelänge 4

3.5

3.5

3

3

2.5

2.5

2 1.5

# Anzahl

# Anzahl

100 Anfragen pro Tag, 300 s Anfragelänge 4

2 1.5

1

1

0.5

0.5

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

199

Anhang

1000 Anfragen pro Tag, 60 s Anfragelänge

1000 Anfragen pro Tag, 300 s Anfragelänge

6

16 14

5

12 10 # Anzahl

# Anzahl

4

3

8 6

2

4 1

2

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

10000 Anfragen pro Tag, 10 s Anfragelänge

10000 Anfragen pro Tag, 60 s Anfragelänge

16 14 12

30 # bearbeiteter Anfragen (immediate) # benötigter VMs (immediate) # Anfragen # bearbeiteter Anfragen (exclusive) # benötigter VMs (exclusive)

25

20 # Anzahl

# Anzahl

10 8 6

15

10

4 5

2 0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

10000 Anfragen pro Tag, 300 s Anfragelänge

100000 Anfragen pro Tag, 10 s Anfragelänge

100

40

90

35

80 30 70 25 # Anzahl

# Anzahl

60 50 40

20 15

30 10 20 5

10 0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit 100000 Anfragen pro Tag, 300 s Anfragelänge 600

160

550

140

500

120

450

100

200

# Anzahl

# Anzahl

100000 Anfragen pro Tag, 60 s Anfragelänge 180

400

80

350

60

300

40

250

20 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

200 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

Anhang

1000000 Anfragen pro Tag, 10 s Anfragelänge

1000000 Anfragen pro Tag, 60 s Anfragelänge

300

1200 1100

250

1000 900 # Anzahl

# Anzahl

200

150

800 700

100

600 50

500

0 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

400 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

1000000 Anfragen pro Tag, 300 s Anfragelänge 5500 5000

# Anzahl

4500 4000 3500 3000 2500 2000 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 Tageszeit

201

Anhang D WSDL Interface der externen Broker API

202

Anhang



203

Anhang



204

Anhang E Beispielszenen der Testapplikation Raytracing In Kapitel 8.2 wird anhand der Software Sweethome 3D die Anwendbarkeit und Leistungsf¨ahigkeit der entwickelten Middleware untersucht. Dazu werden via Raytracing fotorealistische Bilder von 3D-Szenen erstellt. Das Raytracing wird dabei durch die separate aber in Sweethome 3D integrierte Software Sunflow durchgef¨ uhrt. Nachfolgend sind die verwendeten Szenen visualisiert. Da Sunflow auch als eigenst¨andige Software verf¨ ugbar ist, wurde eine eigene Testszene benutzt.

Beispielszene Sunflow Entnommen aus den offiziellen Beispielszenen. (Verf¨ ugbar unter Onlineressource http:// sourceforge.net/projects/sunflow/files/sunflow-data/v0.07.1/ (Stand 15.5.2014))

Aliens Shiny

Offizielle Beispielszenen Sweethome 3D Entnommen aus den offiziellen Beispielszenen. (Verf¨ ugbar unter Onlineressource http:// www.sweethome3d.com/gallery.jsp (Stand 15.5.2014))

205

Anhang

SweetHome3DExample

SweetHome3DExample2

SweetHome3DExample3

SweetHome3DExample4

SweetHome3DExample5

SweetHome3DExample6

206

Anhang

userGuideExample

Selbst konstruierte Beispiele

test1

test2

test3

test4

207

Anhang

Weitere Beispiele Dritter

extern1

extern2

extern3

extern4

extern5

extern6

208

Anhang

extern7

extern8

extern9

extern10

extern11

extern12

209

Anhang

extern13

extern14

extern15

extern16

extern17

extern18

210

Anhang

extern19

extern20

extern21

211