Technologien aus dem Bereich Cloud Computing k¨onnen an dieser Stelle eingesetzt werden, um einige der Restriktionen im BereichMobiler Server-unterst¨utzter Anwendungen aufzuwei-chen. 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 Rzugewiesen wird. Da-mit wird erreicht, dass die Netzwerkperformance und die Verarbeitungsgeschwindigkeit f¨ur jede Anfrage konstant sind. Genauer wird davon ausgegangen, dass exakt gleiche Programm-ausf¨uhrungen (pl, el) zu jedem Zeitpunktt1, t2, . . . , tnauf der gleichen Ressource mit der glei-chen 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 Zeitpunktet1 undt2:
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-RessourcenRm¨oglich, ∆tworkzu beeinflussen, indem man die zur Berechnung verwendete Ressource entsprechend der Anforderungen anpasst. Da auch Cloud-Ressourcen nicht unbegrenzt zur Verf¨ugung stehen, bedarf es einer Scheduling-Komponente,
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 Ka-pitel 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 wer-den konnte. Im Cloud Computing ist es ¨ublich, die Verwendung von Ressourcen nach dem pay-per-use Modell in Rechnung zu stellen. Dies impliziert eine Authentifikation zum Be-ginn 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 Verarbeitungsgeschwindig-keit garantiert werden. Jedoch wird auch ein gewisser Overhead f¨ur Allokation und Authen-tifizierung notwendig. Somit lohnt sich der Einsatz erst, wenn die Berechnungsdauer einen gewissen Umfang ¨uberschreitet. 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. Cloud-Ressourcen werden ¨ublicherweise auf Stundenbasis gemietet. Unterschiedliche Ressourcenty-pen sind dabei verschieden teuer. Daraus ergibt sich f¨ur die Ressourcenauswahl zudem eine Kostenbeschr¨ankungcostlimit:
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 Funktionceil(∆tremote) liefert die auf volle Stunden aufgerundete Nutzungsdauer. Diese stun-denweise Abrechnung kann zu großem finanziellen Overhead f¨uhren, wenn die Nutzungszeit die Abrechnungsperiode immer nur kurz ¨ubersteigt, so werden beispielsweise 61 min als 2 h abgerechnet. Hier bedarf es also einer Wiederverwendungsstrategie f¨ur Cloud-RessourcenR, um diesen Overhead zu minimieren.
3.3 Fazit
Das Modell beschreibtMobile Cloud-unterst¨utzte Anwendungen. Dabei wird eine Applikati-on 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 Laufzeitfunktionlauf(R, p, e), die die Abh¨angigkeit zwischen einer Eingabe eund der Ausf¨uhrungszeit eines Programmmodulsp berechnet,
• Abh¨angigkeit der Daten¨ubertragungszeit ∆tcomm vom verwendeten Netzwerk und der gew¨ahlten Codierung,
• Abh¨angigkeit der Allokationszeit einer Ressource (∆tauthund ∆talloc) von der gew¨ahlten Systemarchitektur, dem verwendeten Schedulingverfahren und der Implementierung des Service-Lebenszyklus.
Außerdem werden folgende Einschr¨ankungen modelliert:
• Die Ausf¨uhrungszeit der Mobilen Cloud-unterst¨utzten Anwendung darf die Ausf¨ uh-rungszeit der rein mobilen Anwendung nicht ¨ubersteigen.
• Die als maximal definierten Kosten f¨ur die Ausf¨uhrung d¨urfen nicht ¨uberschritten wer-den.
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.
4 Verbindungen in 3G und WLAN Netzwerken
Aus dem Studium vorhandener Literatur in Kapitel 2 ist hervorgegangen, dass manche Tech-nologien aus dem Bereich MCC zwar die verf¨ugbare Kommunikationsperformance beachten, jedoch sind dazu keine Bewertungsmaßst¨abe genannt. Ebenso wird auf die speziellen Eigen-schaften mobiler Kommunikationstechnologien in der Literatur oft nicht eingegangen. Da die Performance mobiler Kommunikationsverbindungen auch immer von der konkreten Konfi-guration abh¨angt, besch¨aftigt sich dieses Kapitel genauer mit der Analyse von kablellosen Netzwerkverbindungen aus dem Bereich WLAN und 3G Mobilfunk. Eine der beiden Verbin-dungsarten 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 Kommu-nikationsverbindung 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 ¨ubertragen wer-den k¨onnen.
Eine belastbare Bewertung der verf¨ugbaren Netzwerkperformance ist wichtig, da die Aus-f¨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 Netzwerk-performance 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 schmal-bandigen Netzwerkkommunikation nicht schnell genug mit Daten versorgt werden kann.
Alle in dieser Arbeit betrachteten Netzwerkverbindungen bauen auf dem im Internet ver-wendeten 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 Ver-bindungen 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, wel-ches 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 Netzwerkpro-tokollstapels darstellt [Com06]. Er setzt sich zusammen aus Netzzugangsschicht, Internet-Schicht, Transportschicht und der Anwendungsschicht. Abbildung 4.1 verdeutlicht das Schich-tenmodell 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
OSI-Schicht TCP/IP-Schicht Beispiele
Host 1 Gateway 1 Gateway 2 Host 2
(vgl. Onlineressource http://www.
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 ¨uber die Aufgaben der einzelnen Schichten gegeben. F¨ur weiterf¨uhrende 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 Netz-werk befinden sich ¨ublicherweise Knoten, die ¨uber 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 uber das physikalische Netzwerk hinaus aufgebaut werden.¨
Internet Um auch ¨uber Grenzen physikalischer Netzwerke hinweg zu kommunizieren, f¨uhrt die Internet-Schicht ein allgemeines Paketvermittlungsverfahren ein und weist jedem Netzwerkger¨at eine Adresse zu. Die Internet-Schicht wird auch als IP-Schicht bezeich-net und sorgt daf¨ur, dass ein Datenpaket von einem Absender zu jedem beliebigen adressierbaren Empf¨anger im Internet gelangt.
1Alle Internet Standards sind im Original alsRequest 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 Onlineressourcehttp://tools.ietf.org/html/rfc791verf¨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 vorange-stellt, der unter anderem die Adresse des Senders und Empf¨angers (MAC-Adressen) enth¨alt.“ (siehe [Sau13, S. 311])
3802.11 ist die Oberbezeichnung verschiedener IEEE-Standards, die seit dem Erscheinen als Weiterentwicklun-gen der WLAN-Technologie erschienen sind. Die wichtigsten Standards f¨ur das 2,4 GHz und das 5 GHz Fre-quenzband 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])