Cloud Computing - Chance oder Risiko? Für die Implementierung und Anwendung in Unternehmen

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung der Arbeit
1.3 Methodik und Aufbau der Arbeit

2 Grundlagen
2.1 Virtualisierung
2.2 Cloud Computing

3 Architektur des Cloud Computing
3.1 Deployment Modelle
3.2 Delivery Modelle
3.3 Übersicht und Ebenen der Cloud-Dienste

4 Implementierung von Cloud Computing in Unternehmen
4.1 Technische Rahmenbedingungen
4.2 Organisatorische Rahmenbedingungen
4.3 Rechtliche Rahmenbedingungen
4.4 Chancen und Risiken des Cloud Computing für Unternehmen
4.5 Empfohlener Implementierungsprozess

5 Bewertung der Anwendung von Cloud Computing
5.1 Geschäftsmodelle im Internet der Dienste (Fraunhofer-Institut)
5.2 Reshaping IT - Transformation im Rechenzentrum (IDC)
5.3 Cloud Computing in der IKT-Brache (TU-Berlin)

6 Fazit und Ausblick

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Ring-Modell

Abbildung 2: Ring-Modell mit Virtualisierungsschicht

Abbildung 3: Laufzeitvergleich der Emulation

Abbildung 4: Übersicht über die Virtualisierungskonzepte

Abbildung 5: Schichtensystem ohne Virtualisierung

Abbildung 6: Hypervisor Typ1 (Bare-Metal)

Abbildung 7: Hypervisor Typ2 (Software)

Abbildung 9: Marktprognose Cloud Computing der BITKOM

Abbildung 10: Public-, Private-, Hybrid Cloud

Abbildung 11: Ebenen der Cloud-Services

Abbildung 12: Clusterschema mit geteilten Speicherressourcen

Abbildung 13: Interdependenzen zwischen den Verfügbarkeitskenngrößen

Abbildung 15: Multidimensionale SWOT-Analyse im Cloud Computing

Abbildung 16: Prozess der Entscheidungsfindung für eine Cloud Strategie

Abbildung 17: Realisierung der Integrationsleistung bei SaaS Angeboten

Abbildung 18: KPIs für Rechenzentren im EMEA-Raum

Abbildung 19: Erfolg von IT-Bereitstellung in Rechenzentren

Abbildung 20: Veränderung der Funktionsbereiche in einer IT-Abteilung

Abbildung 21: Entscheidungsmerkmale bei IT-Sourcing in die Cloud

Tabellenverzeichnis

Tabelle-1: Prozentuale Verfügbarkeit und Ausfallzeit

Tabelle-2: Bestandteile des Bausteins ITIL Service Delivery

Tabelle-3: Messgrößen der technischen IT-Infrastruktur für Cloud Leistungen

Tabelle-4: Grundmodell einer SWOT-Analyse

Tabelle-5: technische SWOT-Matrix

Tabelle-6: organisatorische SWOT-Matrix

Tabelle-7: rechtliche SWOT-Matrix

1 Einleitung

1.1 Problemstellung

Unser globales Wirtschaftssystem wird heutzutage zunehmend durch wachsenden Wettbewerbs- und Innovationsdruck geprägt. Bedingt durch die rasche technologische Entwicklung und zunehmende Produktvielfalt mit steigender Komplexität gilt es für viele Unternehmen immer ausgereiftere Lösungen, Dienstleistungen und Produkte mit Alleinstellungsmerkmal zu schaffen, um sich von der Konkurrenz abzuheben und nachhaltig auf dem Markt existieren zu können. Vor diesem Hintergrund avancierte der Begriff des Cloud Computing in den letzten Jahren vom Hype zum nachhaltigen Trend nach Green-IT und Virtualisierung. In der Literatur ist dieser relativ neue Begriff noch nicht hinreichend definiert und in der IT-Fachwelt noch umstritten. Dies wird auch nicht dadurch entschärft, dass Hard- und Softwarehersteller vorwiegend den Begriff Cloud in ihre Produkte integrieren, da auch die Hersteller über ein unterschiedliches Verständnis der Cloud verfügen. Es existiert eine Vielzahl von ungesicherten Informationen über das Thema, so dass die Vor- und Nachteile des Cloud Computings bei Unternehmen bzw. IT-Entscheidern oft im Verborgenen bleiben. Bei der Auseinandersetzung mit dem Thema wird die Realität bestehender IT-Strukturen in Unternehmen oft vernachlässigt. So stellt sich die Frage, ob sich die Geschäftsprozesse eines Unternehmens überhaupt für eine Cloud-Infrastruktur eignen, und ob sich dadurch Vorteile für die Unternehmung ableiten lassen.

1.2 Zielsetzung der Arbeit

Die vorliegende Bachelorthesis beschäftigt sich vorwiegend mit den Voraussetzungen, und der Implementierung und Anwendung von Cloud Computing in Unternehmen. Ziel hierbei ist es, nach der Klärung des Grundlagenteils, einen Überblick über die bestehende Architektur und Nutzungsmodelle im Cloud Computing zu erhalten. Darüber hinaus werden unterschiedliche Voraussetzungen erläutert, die nötig sind, damit die Implementierung einer cloudbasierten IT-Infrastruktur gelingt. Weiterhin werden die Vor- sowie Nachteile dieses IT-Konzepts ausreichend erläutert. Hiernach werden diese anhand wissenschaftlicher Studien bewertet.

1.3 Methodik und Aufbau der Arbeit

Diese Bachelorarbeit beinhaltet insgesamt sechs Kapitel. Im Grundlagenteil in Kapitel 2 wird die technologische Basis des Cloud Computings erläutert und eine Begriffsbestimmung durchgeführt. In Kapitel 3 werden die Architektur sowie Nutzungsmodelle des Cloud Computings beschrieben. Es werden die notwendigen Bedingungen für das Cloud Computing entwickelt, welche die Designgrundlagen des Cloud Computing beschreiben und die erarbeiteten Stufen einschließt. Hier wird eine Beziehung zwischen Architektur und Nutzungsmodell hergestellt. Um Cloud Computing erfolgreich im Unternehmen implementieren zu können, müssen zudem verschiedene organisatorische und rechtliche Voraussetzungen erfüllt sein. Diese werden ebenfalls in Kapitel 4 zusammenhängend erarbeitet. Zudem erfolgt die Entwicklung und Darstellung eines empfohlenen Implementierungsprozesses nachdem die beschriebenen Chancen und Risiken bei der Implementierung des Cloud Computings erläutert wurden. Hierbei wird die Methode der SWOT-Analyse angewandt. Sie stellt ein geeignetes Instrument der Strategischen Analyse dar, um externe und interne Chancen und Risiken abzuwägen, und um die Geschäftsstrategie eines Unternehmens daraufhin anzupassen. Im fünften Teil erfolgt eine Bewertung von Anwendungsbeispielen aus der Implementierung des Cloud Computings anhand aktueller wissenschaftlicher Studien. Kapitel 6 schließt diese Thesis mit einem Fazit sowie einem Ausblick auf zukünftige Entwicklungstrends ab.

2 Grundlagen

In diesem Kapitel werden die Grundlagen für das weitere Verständnis beschrieben. Zunächst werden dabei die verschiedenen Formen der Virtualisierung behandelt. Danach wird der Begriff des Cloud Computing behandelt und definiert.

2.1 Virtualisierung

In Bezug auf das Thema Cloud Computing spielt die technologische Entwicklung der Virtualisierung in der Informatik eine entscheidende Rolle. Aus diesem Grund widmen sich die folgenden Seiten mit den Aspekten der Virtualisierung, die für das Cloud Computing als technische Grundlage anzusehen sind.

2.1.1 Definition

Der Begriff der Virtualisierung tritt in der Praxis in den unterschiedlichsten Bereichen auf. In der Informatik steht die Virtualisierung für verschiedene technische Ausprägungen und Eigenschaften von Informationssystemen. Die Virtualisierung findet daher diverse Anwendungen in Themenbereichen wie Netzwerk- oder Speichersysteme, Hardware und Software. In der Literatur wird deshalb zwischen mehreren Bereichen unterschieden.

Im Netzwerkbereich werden mit der Virtualisierung Technologien beschrieben, die es erlauben logische Netzwerkbereiche aufzuteilen und zu trennen. Als Stichworte dazu sind an dieser Stelle die Begriffe VLAN und VPN zu nennen. Diese Techniken simulieren separate Netzwerkbereiche innerhalb physischer und logischer Netzwerke. Für die damit verbundenen Computer ist die darunterliegende Netzwerkinfrastruktur nicht transparent.^[1]

Virtualisierung im Speicherbereich hingegen beschreibt die Nutzung und Auslagerungen von Informationen und Rechenoperationen auf physisch nicht vorhandene Speicherbereiche in der Informatik. Gragon spricht in diesem Zusammenhang von virtuellem Speicher (engl. virtual memory). „ … virtual memory has been used to denote a computer with a large linear adress space that hides memory management tasks, dis- cussed above, from the programmer.“^[2] Ein Computerprozessor nutzt demnach mehr Arbeitsspeicherbereiche als ihm zur Verfügung stehen. Technisch rechnen Prozessoren die reale Adressierung im Arbeitsspeicher in ein virtuelles Adressregister (pagetable) um.^[3]

Umfassender beschreibt Thorns die Virtualisierung als Abstraktionsebene, die dafür sorgt, Rechenoperationen in Hardwaresystemen unabhängig voneinander abzubilden. So entstehen sog. virtuelle Maschinen, die sich „ … wie eigenständige Computer verhalten und die in ihnen ausgeführten Operationen auf die tatsächlich vorhandene Hardware abbilden.“^[4] Weiterhin schreibt Thorns über die Bestandteile einer virtuellen Maschine und bezieht sich dabei auf die sog. vier Kernelemente einer virtuellen Maschine nach dem Popek-Goldberg-Papier. Demnach seien der Prozessor (CPU), der Arbeitsspeicher, die Festplatte und das Netzwerk als eine Einheit einer virtuellen Maschine zu sehen.^[5] Der Amerikaner Gerald Popek, Mathematiker und Computerwissenschaftler an der Universität von Kalifornien, stellte mit seinem Kollegen Robert Goldberg von der Universität in Harvard bereits 1974 diese „ Formal requirements for virtualizable third generation architecture s “^[6] auf.

Eine abstraktere These formuliert Gull und sieht die Virtualisierung als "... die Eigenschaft einer nicht vorhandenen Entität, in Form und W irkung einer r ealen Entität gl e i chg est ellt zu s ein."^[7] Ähnlich der Erklärung von Thorns bildet die IT durch Virtualisierung eigene Infrastrukturkomponenten, deren Verhalten und Erscheinung mit denen realer Komponenten nahezu identisch ist.^[8]

Zu dem Schluss, dass Virtualisierung im Allgemeinen, besonders jedoch in der Informatik, ein weitgefächerter Begriff ist, der noch nicht hinreichend definiert ist, kommt Picht. Der Inhaber der IT-Beratungsfirma Picht Consulting stellt weiterhin jedoch fest, dass unter Virtualisierung „ … oftmals die Emulation oder die Simulati on von Hard- ware-Ressourcen verstanden werden kan n.“^[9] Dies führt zu einer Trennung von Betriebssystem und der darunterliegenden Hardware, die einen höheren Grad an Flexibilität erlaubt.^[10]

Für das weitere Verständnis der Virtualisierung im Zusammenhang mit Cloud Compu- ting wird sich auf die Definition von Picht bezogen. Die angesprochene Flexibilität und die Entwicklung zur Unabhängigkeit von Hardwareressourcen bestimmen maßgeblich die Struktur des Cloud Computing. Virtualisierung liefert in Ihren verschiedenen Ausprägungen die technische Grundlage. Die Ausprägungsformen der Virtualisierung lassen sich in unterschiedliche Kategorien aufteilen. Wie bei der Definition der Virtualisierung, sind die weiteren Merkmale der Virtualisierung in der Literatur ebenfalls unterschiedlich eingeordnet. Die folgenden Kapitel beschreiben diese Technologien. Sie sind essentiell für das spätere Verständnis des Cloud Computing.

2.1.2 Exkurs Prozessortheorie

Für das Verständnis der technischen Grundlagen der Virtualisierung ist zunächst eine vorige Betrachtung des Prozessormodells erforderlich. Nach Gübeli et al. bilden Prozessoren, als die zentrale Recheneinheit, den Kern eines Computersystems. Sie lesen und verarbeiten die notwendigen Informationen einer Operation.^[11]

Prozessoren arbeiten bei der Ausführung von Prozessen und Aktionen nach dem sog. Ring-Modell. Ähnlich wie beim OSI-Schichtenmodell aus der Netzwerktechnik, welches eine hierarchische Beziehung bei der unterschiedlichen Kommunikation zwischen Computersystemen beschreibt,^[12] verwendet ein Prozessor privilegierte und nicht privilegierte Bereiche, um seine Operationen auszuführen. Die Beziehung zwischen Applikation, Betriebssystem und Hardware ist demnach streng hierarchisch. D.h. ein Programm hat zunächst keinen uneingeschränkten Zugriff auf die Hardwareressourcen eines Systems. Den Zugriff darauf regelt das Betriebssystem. Bei der Aufstellung des Ring-Modells unterscheidet man nach insgesamt vier Berechtigungsstufen. „Je nach Ring sind die Rechte bestimmter Befehle eingeschränkt … .“^[13]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Ring-Modell^[14]

Wie in Abbildung 1 zu erkennen ist, besitzt der unterste Ring 0 den vollständig privile gierten Zugriff auf die Hardwareressourcen. Diese Stufe wird auch als Kernel-Mode bezeichnet. Anwendungen, die oberhalb von Ring 0 laufen, werden im Kontext des sog. User-Mode (Benutzermodus) ausgeführt. Der Betriebssystem-Kernel läuft auf Ring 0 und besitzt vollständigen Zugriff auf die Hardwareressourcen wie Speicher, Netzwerk und Rechenkapazität. Anwendungen im User-Mode erhalten stets nur die Hardwareres-sourcen zugewiesen, die Sie über die Ausführung im Speicher benötigen. ^[15] Sobald ein Programm eine Operation ausführen möchte, bei der Ressourcen verlangt werden, die über den eigenen Rechtekontext hinausgehen, werden diese bei den entsprechenden Betriebssystem-Schnittstellen angefordert. Sollte beispielweise eine Datei von der Festplatte gelesen oder geschrieben werden, erfolgt dies durch das Betriebssystem in Ring 0. Bei der Aufforderung zu einem Druckauftrag ist die Schnittstelle des Betriebssystems, die dabei genutzt wird allgemein etwas bekannter. Über die sog. Treiber werden Programmparameter an das Betriebssystem übergeben, welche später einen Rückgabewert an das Programm erwidern. Die Anforderung zur Ausführung einer Operation, die Ressourcen einer höher privilegierten Schicht benutzt, wird als Syscall (dt. Systemaufruf) bezeichnet. Das Betriebssystem führt die gewünschte Operation durch und reserviert beispielsweise Adressen im Hauptspeicher. Die Anwendung kann nur auf die zugewiesenen Speicherbereiche zugreifen. Dennoch kann es vorkommen, dass ein Programm auf Speicherbereiche zugreifen möchte, die zuvor nicht vom Betriebssystem reserviert wurden. In diesem Fall wird eine sog. Exception (dt. Ausnahmesituation) ausgelöst, die durch das Betriebssystem abgefangen wird. Dies kann in einigen Fällen zum Absturz des Systems bzw. der Anwendung führen. Der Vorgang der Erkennung einer Exception durch das Betriebssystem wird als Trap (dt. Fang) bezeichnet.^[16]

2.1.3 Prinzip der Virtualisierung

In Bezug auf die Ausführung der Virtualisierung sind Syscalls, die zusätzliche Ressourcen des Betriebssystems beanspruchen, kritisch. Das Abfangen und Verarbeiten von Exceptions ist die wesentliche Aufgabe einer zusätzlichen neuen Schicht, die anstelle des Betriebssystems im Kernel-Mode ausgeführt wird. Hier spielt der Gedanke der zusätzlichen Abstraktionsschicht eine Rolle, die zuvor in der Definition der Virtualisierung erwähnt wurde. In der Literatur wird diese Schicht oftmals entweder als Virtual Machine Monitor (VMM)^[17] oder als Hypervisor^[18] bezeichnet. Die Bedeutung des Wortes Hypervisor stammt dabei ursprünglich aus dem Griechischen und Lateinischem. Während das griechische Wort hyper so viel bedeutet wie über, steht visor für eine Ableitung des lateinischen Wortes videre, welches sehen bedeutet. Picht beschreibt den zusammengesetzten Wortsinn folgendermaßen. "Dieses zweideutige Wort ist hier nicht als >>übersehen<< im Sinne von >>nicht sehen<< gemeint, sondern im Sinne von >>die Aufsicht über etwas haben<< bzw. etwas zu überwachen, zu überblicken."^[19] Dies kommt der näheren Aufgabe dieser Abstraktionsschicht bereits sehr nahe. Denn diese hat vollständigen Zugriff und damit die Aufsicht über die Hardwareressourcen eines Computersystems. Eine Übersicht über die Einbindung dieser Abstraktions- bzw. Vir- tualisierungsschicht ist in Abbildung 2 veranschaulicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Ring-Modell mit Virtualisierungsschicht^[20]

Die Hypervisor-Schicht hat als Einzige den voll privilegierten Zugriff auf die Hardwareressourcen. Betriebssysteme, die zunächst auf Ring 0 im Kernel-Mode betrieben wurden, werden in die niedriger privilegierte Schicht Ring 1 ausgelagert. Man spricht in diesem Zusammenhang von der sog. virtuellen Maschine (VM). Über die Verlagerung durch den Hypervisor ist es möglich mehrere Programme, z. B. Betriebssysteme in dieser Schicht zu betreiben. So können mehrere Betriebssysteminstanzen entstehen. Bei Zugriffen auf die Hardware des Computersystems werden die Syscalls dann an die Abstraktionsschicht weitergegeben, die in sich wiederum eine Exception auslösen. Diese wird dann von der Abstraktionsschicht entgegengenommen und verarbeitet. Das Ergebnis dieser Verarbeitung wird dann virtualisiert und an das entsprechende Programm oder System zurückgegeben. Thorns spricht in diesem Zusammenhang von Aktionen die an die niedriger privilegierte Schicht emuliert werden.^[21]

Die Abstraktionsschicht, arbeitet mit der Technik der Emulation. Nach Schmitt ist die Emulation die ".. Anpassung und Abarbeitung des Befehlsvorrates einer Rechenanlage A durch geeignete Mikroprogrammierung in einer anderen Rechenanlage B heißt Emulation. Man sagt auch, B emuliert A. Bei der Emulation verhält sich die Rechenanlage B so, als ob sie gleich A wäre."^[22] Weiterhin beschreibt er den Emulator als ein Element, das Spezifikationen und Anweisungen von technologiefremden Bereichen ausführen kann, die ursprünglich nur für diese selbst erstellt wurden.^[23] Die Hypervisor übernimmt mit der Emulation Aufgaben, die ursprünglich vom Betriebssystem ausgeführt wurden. Bei mehreren Betriebssysteminstanzen muss er gleichzeitig dafür sorgen, dass Syscalls einer bestimmten Betriebssysteminstanz, z. B. von VM1 auch wieder an VM1 zurückgegeben werden und nicht an VM2 weitergereicht werden. Der Vorteil der Emulation bei der Abhandlung der Exceptions ist, dass Sie weitaus schneller verarbeitet werden kann. Dennoch entsteht ein gewisser Performanceverlust im Vergleich zu einer nativen Installation des Betriebssystems auf der Hardware selbst.^[24] Dieser fällt jedoch durch die Emulation verhältnismäßig gering aus und bewegt sich im Bereich von 2-3%.^[25] Eine Übersicht welchen Geschwindigkeitsvorteil mit der Emulation erzielt wird, zeigt Abbildung 3 nach Schmitt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Laufzeitvergleich der Emulation^[26]

Auf Grund der Verarbeitung von mehreren Exceptions, dem sog. Exception-Handling entsteht ein gewisser Overhead im Hypervisor. Dieser ist dadurch begründet, dass die Exceptions für die Verarbeitung im Hypervisor umgeschrieben werden müssen. Um den Overhead bzw. den daraus entstehenden Leistungsverlust möglichst gering zu halten, setzen die beiden großen Prozessorhersteller Intel und AMD auf zusätzliche Techniken. Mit der Integration von zusätzlichen Befehlssätzen in ihren Prozessoren versuchen die Hersteller die Verarbeitung der Exceptions zu optimieren. Bei AMD lautet der zusätzli- che Befehlssatz Pacifica^[27], während er bei Intel unter dem Namen Intel VT bzw. Intel Virtualization Technology (IVT)^[28] zu finden ist. Die Implementierungen dieser beiden Befehlssätze innerhalb der jeweiligen Prozessoren sind grundlegend unterschiedlich und deshalb untereinander nicht kompatibel.^[29]

2.1.4 Konzepte der Virtualisierung

Für den Einsatz von Virtualisierung in Unternehmen lassen sich unterschiedliche Konzepte feststellen. In der Praxis entstehen daraus verschiedene Ausprägungen und unterschiedliche Einsatzmöglichkeiten. Zu unterscheiden sind dabei die klassische Virtualisierung, die Software Emulation und das Partitionsverfahren. Eine Übersicht dazu bietet Abbildung 4.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Übersicht über die Virtualisierungskonzepte^[30]

Die gängigste und meist genutzte Form, in der Praxis, ist die klassische Virtualisierung. Sie wird auch als Systemvirtualisierung oder Hardwarevirtualisierung bezeichnet. Hierbei werden mehrere Systeme Betriebssysteminstanzen über den Hypervisor oberhalb der Schicht 0 virtualisiert dargestellt. Diese Instanzen werden als VM bezeichnet. Die Hardwarearchitektur der VM entspricht dabei weitestgehend der des Hypervisor bzw Hostsystems.^[31] Das virtuelle System wird dabei oft auch als Gastsystem oder Gastbetriebssystem geeignet.^[32] Die virtuellen Maschinen nutzen gemeinsam die Hardware des Hostsystems und sind voneinander unabhängig. Sie können sich dabei nicht gegenseitig beeinflussen. Dadurch ist es möglich unterschiedliche Betriebssysteme auf einer Host- hardware zu betreiben. Liegen diese virtuellen Maschinen in Form von Dateien in einem Ordner vor, spricht man dabei auch von Containervirtualisierung.^[33] „Hier wird auch nicht mehr von “virtuellen Maschinen“ gesprochen, sondern von Containern oder Jails.“^[34] In einigen Fällen wird im Rahmen der Systemvirtualisierung mit der sog. Para- virtualisierung gearbeitet. Der Begriff para stammt aus dem Griechischen und bedeutet so viel wie neben bzw. darüber hinaus. Bei dieser Form werden von den virtuellen Maschinen und der Virtualisierungsschicht sog. HypervisorCalls ausgelöst, die direkt an die entsprechende Hardware durchgereicht wird. Die virtuelle Maschine erhält dadurch für eine begrenzte Zeit Zugriff auf die angeforderte Hardware und die Verarbeitung kann unmittelbar beginnen, ohne dass der Hypervisor intervenieren muss. Dadurch ergibt sich für die virtuelle Maschine ein erheblicher Geschwindigkeitsvorteil in Folge des Direktzugriffs auf die Hardware.^[35]

Eine weitere Form der Virtualisierung ist die sog. Emulation bzw. API-Emulation. Bekannt ist diese Form bisher bei Programmen und Interpretern, die eine separate Laufzeitumgebung für eine Anwendung simulieren. Die Laufzeitumgebung wird auch in diesem Fall als VM bezeichnet. Sie dient dabei als Schnittstelle zwischen dem Betriebssystem und sich selbst. Bekanntester Vertreter dieser Form der Schnittstellenemulation ist die Java Virtual Maschine JVM. Die Java VM setzt ein Hostbetriebssystem voraus und baut die Laufzeitumgebung in der Anwendungsschicht des Hostbetriebssystems auf.^[36] In der aufgebauten Laufzeitumgebung können unterschiedliche Anwendungenimplementiert werden. Weiterhin ist es möglich diese Laufzeitumgebung auf unterschiedlichen Betriebssystemen zu installieren. Die Anwendungen, die in der JAVA VM abgebildet werden, können auf unterschiedlichen Betriebssystemen starten und sind dadurch virtualisiert. Damit werden Sie unabhängig vom zugrundeliegenden Betriebssystem, jedoch nur in Ausnahmefällen von der Hardwarearchitektur. Es kann somit vorkommen, dass 64-Bit Anwendungen nicht auf einer x86 bzw. 32-Bit Architektur funkti- onieren.^[37]

Das Virtualisieren von mehreren Systemumgebungen ohne die Abbildung einer jeweils separaten VM- bzw. Betriebssysteminstanz geschieht im sog. Partitionsverfahren.^[38] Die virtuellen Maschinen laufen alle auf derselben Schicht des Betriebssystems bzw. Im KernelModus. Der Kernel des Betriebssystems isoliert dabei jedoch die einzelnen Prozesse und kontrolliert die Schnittstellen, die mit dem System interagieren. Dies geht soweit, „ … daß den Prozessen einer Partition zwar die gesamten Schnittstellen des Betriebssystems zur Verfügung stehen, sie damit jedoch nur innerhalb der eigenen Partition interagieren können.“^[39]

Bekanntester Vertreter dieser Form der Virtualisierung ist das Unternehmen IBM. Die Systemumgebungen werden als logische Partitionen (LPARS) abgebildet und kommen zunehmend im Mainframe Bereich unter IBMs Betriebssystem AIX auf der Hardware- serie System z (z-Series) und System p (p-Series) zum Einsatz.^[40] Der Hypervisor in diesem Kontext wird als Processor Resource/System Manager (PR/SM)-Hypervisor bezeichnet. Durch diese Form der Virtualisierung entstehen keine Hardwareeinbußen. Der Zugriff auf die Hardware geschieht hier unmittelbar und wird durch den Hypervisor voneinander isoliert. Innerhalb der LPARS können dann unterschiedliche Dienste betrieben werden. Durch die strikte Trennung der logischen Systeme von der gegenseiti-gen Informationsverarbeitung und die hohe Gewährleistung einer Performanz werden diese Techniken vermehrt bei Banken, Regierung und im militärischen Bereich einge- setzt.^[41]

2.1.5 Zusammenfassung der Erkenntnisse

Aus dem vorangegangenen Beispiel der Containervirtualisierung zeigt sich wie unterschiedlich der Begriff einer virtuellen Maschine in der wissenschaftlichen Fachwelt verstanden wird. Während Thorns den Begriff der Container erst im Rahmen des Parti- tionierungsverfahrens verwendet,^[42] versteht Picht darunter eher die Funktion der virtuellen Maschine als emulierte Laufzeitumgebung für Programme.^[43] Beckereit sieht die virtuelle Maschine sowohl als Teil der klassischen Systemvirtualisierung, als auch der Partitionsvirtualisierung.^[44]

In der Praxis lassen sich die Technologien und Verfahren nicht konkret voneinander abgrenzen. Vielmehr sieht man in der Realität einen Trend zu konvergenten Systemen. Die kommerziellen Softwarefirmen, allen voran Microsoft, VMware Inc. und Citrix, sowie diverse Andere bieten in ihren Lösungen und Produkten einen Mix aus allen Technologien zur Virtualisierung an. Dennoch lassen sich in den Bereichen und Produkten immer wieder Parallelen finden. Für den weiteren Verlauf der Arbeit wird dabei grundsätzlich von folgenden Modellen und Begriffen ausgegangen.

Eine traditionelle Installationsweise eines Betriebssystems erfolgt direkt auf der Hardware selbst. Ohne die Inanspruchnahme der Virtualisierung lässt sich daher folgendes Schichtenmodell in Abbildung 5 aufstellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Schichtensystem ohne Virtualisierung^[45]

In der klassischen Virtualisierung, bei der der Hypervisor die Betriebssysteminstanzen in niedrigere privilegierte Schichten auslagert, unterscheidet man vermehrt zwischen einem Typ1 und Typ2 Hypervisor. Der Typ1 Hypervisor wird nativ auf der Hardware des Hostsystems installiert. Aus diesem Grund spricht man hier vermehrt von der sog. Bare-Metal-Virtualisierung bzw. von einem Bare-Metal Hypervisor. Dargestellt ist das Schema in Abbildung 6.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Hypervisor Typ1 (Bare-Metal)^[46]

Ein Typ2-Hypervisor wird innerhalb einer bestenden Betriebssysteminstanz installiert. Er läuft auf der Anwendungsschicht des Hostbetriebssystem und bildet dort wiederum eine eigene Systemumgebung in der VM. In einigen Bereichen wird diese Form auch als Softwarevirtualisierung bezeichnet. Der Vorteil liegt in der Flexibilität bedingt durch die Simulation von Hardwarekomponenten. So lassen sich durch einen Typ2 Hypervisor Hardwarekomponenten simulieren, die gar nicht Hostsystem verfügbar bzw. physisch verbaut sind. Gleichzeitig ist die Simulation in Bezug auf die Geschwindigkeit der Datenverarbeitung und Performance der VM langsamer als die Emulation bei einem Typ1 Hypervisor. Der Unterschied wird in Abbildung 7 deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Hypervisor Typ2 (Software)^[47]

Bei der Betrachtung der untersuchten Verfahren und Technologien lässt sich zu folgender Schlussfolgerung kommen. Virtualisierung schafft eine Form von System, welche gewissermaßen losgelöst von der zugrundeliegenden Hardwarearchitektur ist. Dies geschieht durch das Vortäuschen ihrerseits. Dies trifft auf beide Hypervisortypen zu. Durch die Nutzung dieser Abstraktionsschicht werden Systeme, Schnittstellen und Programme flexibel einsetzbar. Die bisherigen technologischen Grenzen von Hard- und Softwaresystemen verschieben sich hin zu denen des Hypervisors bzw. der Hersteller von Virtualisierungslösungen.

2.2 Cloud Computing

Nachdem im vorigen Kapitel das Thema Virtualisierung erläutert wurde, befasst sich dieses Kapitel mit den Grundlagen des Cloud Computing. Dabei wird zunächst die Begriffsherkunft geklärt und die wörtliche Abstammung erläutert. Weiterhin wird der Begriff des Cloud Computing an sich definiert, gefolgt von einer Abgrenzung zu anderen verwandten IT-Themen. Im Anschluss erfolgt eine kurze Zusammenfassung der gewonnenen Erkenntnisse.

2.2.1 Begriffsherkunft

Anfang der 90er Jahre wurde der Begriff Cloud erstmals von der amerikanischen Telekommunikationsindustrie verwendet. Zu dieser Zeit entwickelte sich die Dienstleistung des Telefon und Internetanschlusses. Die Unternehmen begannen Ihren Kunden sog. Komplettpakete inkl. der passiven Komponenten wie Switche, Router oder Hubs zusätzlich zum Standardanschluss als Extras anzubieten. Kunden konnten diesen Service als Paket bestellen. Bezugnehmend auf die Informationsverarbeitung nutzte der damalige CEO von Google Eric Schmidt den Begriff des Cloud Computing 2006 erstmals auf der Search Engine Strategies Conference in San Jose, Kalifornien. Dort beschrieb er Cloud Computing als ein Nachfolgemodell des Client-Server-Modells. Cloud Compu- ting entstand damit als Metapher für Leistungen und Dienste, die aus dem Internet bezogen werden.^[48]

2.2.2 Definition des Cloud Computing

Für Cloud Computing existieren viele verschiedene Interpretationen jedoch bislang noch keine allgemeingültige Definition. Dies lässt sich in den Werken verschiedener Fachautoren zum Thema Cloud Computing feststellen. Metzger et.al. beziehen sich in Ihrem Werk auf die Definition des National Institute of Standards und Technologie (NIST). „Cloud computing is a model for enabling convenient, on-demand network 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 com- posed of five essential characteristics, three service models, and four deployment mod- els.“^[49]

Die fünf charakteristischen Merkmale nach NIST beinhalten:

On-De ma nd self-servic e: Anwender können Computerressourcen wie Speicherplatz, Rechenleistung etc. selbst in Anspruch nehmen und sich bei Bedarf selbst über eine geeignete Schnittstelle zur Verfügung stellen.

B road n etwork access: Es müssen Möglichkeiten bestehen auf das Netzwerk über ein breites Spektrum an Plattformen und Endgeräten zuzugreifen. Die Standardisierung von Schnittstellen spielt dabei eine große Rolle.

Resso urce Poo ling: Anbieter und Firmen, die Cloud Computing nutzen und anbieten, müssen Computerressourcen wie Speicher, Netzwerk und Rechenleistung, egal ob physisch oder virtuell, dynamisch verwalten. Sie müssen bei Bedarf den Nutzern von IT-Dienstleistungen zugeschrieben werden. Dabei bleibt es transparent an welchem physikalischen Ort diese Ressourcen erbracht werden.

Ra pid elasticity: Ressourcen können schnell und flexibel zur Verfügung gestellt werden. Eine Cloudlösung zeichnet sich durch einen hohen Automatisierungsgrad aus und bedarf nur noch weniger manueller Eingriffe.

Mes u red serv i ce: Die angebotenen und genutzten IT-Dienstleistungen müssen sich gesondert und transparent abrechnen lassen. Es muss ein Verrech- nungsmodell existieren, dass für Anbieter und Nutzer den bedarfsbezogenden Ressourcenverbrauch anzeigt und überwacht.^[50]

Karin Sondermann von Microsoft stellt ebenso fest, dass es keine einheitliche Definition für den Begriff Cloud Computing gibt, jedoch viel Spielraum für mannigfaltige Interpretationen existiert. Nichtdestotrotz seien die Ziele des Cloud Computing übergreifend klar. So verändert "Die zunehmende Automatisierung, Standardi s ierung und Flexibilisierung .. d ie Bereitstellung von IT-Ressourcen fundamental."^[51] Durch die " ... Ausnutzung hoch virtua lisierter Rechen-, S peicher-, und N etzwerkressourcen wird ein gemeinsamer Pool an s kalierbare n, Internetbasierten, zentralen IT-In frastrukturen, Plattformen, Datenbanken und Anwendungen a ls on-demand-Dienste zur Verfügung gestellt und automatisch verwalte t."^[52] Weiterhin geht Sondermann in ihrer Definition auf die Automatisierung ein, die das manuelle Eingreifen von Administratoren minimieren wird.

Ein anderer Ansatz von Baun et al. bezieht eine stärkere Rolle des Internets bei der Bereitstellung von IT-Dienstleistungen mit ein. Demnach erlaubt Cloud Computing die Nutzung "... von Anwendungen aller Art als im Web elektronisch v erfügbare Dienste. Der Begriff Cloud soll dabei andeuten, dass d ie Di enste von ein em Anwender über das Internet ... erbracht werden".^[53] Die Autoren lehnen sich später jedoch an die NIST Definition des Cloud Computing an und bilden die fünf charakteristischen Merkmale in einem Satz ab. „ Unter d er Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner W eb -Technologien stellt Clo ud Computing skali erbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukt uren, P lattformen und Anwendungen als on- demand Dienste zur Verfügung. Die Abre chnung dieser Dienste erfolgt n utzungsabhän- gig.“^[54]

[...]

---

^[1] Vgl. Xu, Jingli (2009): S. 44ff

^[2] Gragon, Harvey G. (1996a): S. 113

^[3] Vgl. Gragon, Harvey G. (1996b): S. 121f

^[4] Thorns, F. (2008a): S. 19

^[5] Vgl. Thorns, F. (2008b): S. 21

^[6] Vgl. Popek. G.J.; Goldberg, R.P. (1974): S.418f

^[7] Gull, D. (2011a): S. 16

^[8] Vgl. Gull, D. (2011b): S. 16

^[9] Picht, H. (2009a): S.1

^[10] Vgl. Picht, H. (2009b): S.1f

^[11] Vgl. Gübeli, R. et.al. (2004): S. 21f

^[12] Vgl. Schreiner, R. (2009): S. 4f

^[13] Thorns, F. (2008c): S. 24

^[14] Quelle: Thorns, F. (2008d): S. 23

^[15] Vgl. Thorns, F. (2008e): S. 24

^[16] Vgl. Thorns, F. (2008f): S. 24f

^[17] Vgl. Thorns, F. (2008g): S. 27f

^[18] Vgl. Picht, H. (2009c): S.12f

^[19] Picht, H. (2009d): S.12f

^[20] Quelle: Thorns, F. (2008h): S. 27

^[21] Vgl. Thorns, F. (2008i): S. 27f

^[22] Schmitt, S. (2005a): S.20

^[23] Vgl. Schmitt, S. (2005b): S.20

^[24] Vgl. Thorns, F. (2008j): S. 28

^[25] Vgl. Gull, D. (2011c): S. 17

^[26] Quelle: Schmitt, S. (2005c): S.47

^[27] Vgl. AMD (2006): AMD Releases "Pacifica" Specification for AMD64 Technology http://www.amd.com/us/press-releases/Pages/Press_Release_98372.aspx, Abruf am 16.03.2012

^[28] Vgl. Neiger, G. et al. (2006): S.167ff

^[29] Vgl. Thorns, F. (2008k): S. 29

^[30] Quelle: eigene Darstellung

^[31] Vgl. Picht, H. (2009e): S.12

^[32] Vgl. Picht, H. (2009f): S.12

^[33] Vgl. Meinel, C. et al. (2011a): S.17f

^[34] Meinel, C. et al. (2011b): S.17f

^[35] Vgl. Thorns, F. (2008l): S. 30f

^[36] Vgl. Picht, H. (2009g): S.8f

^[37] Vgl. Thorns, F. (2008m): S.35f

^[38] Vgl. Thorns, F. (2008n): S.32f

^[39] Thorns, F. (2008o): S.32

^[40] Vgl. Picht, H. (2009h): S.16f

^[41] Vgl. MacNeil, T. (2006)

^[42] Vgl. Thorns, F. (2008p): S.32

^[43] Vgl. Picht, H. (2009i): S.8f

^[44] Vgl. Beckereit, F. (2011a): S.71f

^[45] Quelle: eigene Darstellung

^[46] Quelle: eigene Darstellung in Anlehnung an: Gull, D. (2011d): S. 17

^[47] Quelle: eigene Darstellung in Anlehnung an: Gull, D. (2011e): S. 17

^[48] Vgl. Metzger, C. et al. (2011a): S.2

^[49] Mell, P.; Grance, T. (2011a) S.2 zitiert nach Metzger, C. et al. (2011b): S.2

^[50] Vgl. Mell, P.; Grance, T. (2011b): S.2

^[51] Sondermann, K. (2011a): S.99

^[52] Sondermann, K. (2011b): S.100

^[53] Baun, C. et al. (2011a): S.3f

^[54] Baun, C. et al. (2011b): S.4