Wir haben im letzten Modul gesehen, wie Cluster aus vielen Computern einen mächtigen lokalen Supercomputer formen. Doch was passiert, wenn selbst dieser ausgereizt ist? Die nächste logische Evolutionsebene bestand darin, Rechenleistung nicht nur lokal, sondern global verfügbar zu machen – und neben reiner Rechenpower auch Daten und Applikationen grenzenlos bereitzustellen[cite: 1].

Stellt euch vor, ihr nutzt die Idle-Time (Leerlaufzeit) eures Rechners, während ihr euch einen Kaffee holt, um an Berechnungen für die AIDS-Forschung oder genetischen Abgleichen mitzuwirken[cite: 1]. Genau hier setzen Grid- und Cloud-Technologien an: Sie abstrahieren die Hardware so weit, dass der Nutzer nicht mehr weiß (und nicht mehr wissen muss), wo auf dem Planeten sein Code gerade ausgeführt wird.

Mitte der 1990er Jahre wurde der Begriff des Metacomputing geprägt[cite: 1]. Die Idee war gigantisch: Große Computersysteme sollten über Wide Area Networks (WAN) miteinander verbunden werden, um parallele Datenverarbeitung auf ein globales Level zu heben[cite: 1]. Im Jahr 1997 wagte man ein historisches Experiment: Zwei Supercomputer des High Performance Computing Center Stuttgart (HLRS) und des Pittsburgh Supercomputing Centre (PSC) wurden miteinander gekoppelt[cite: 1]. Das Experiment scheiterte jedoch dramatisch an einem physikalischen Problem, das selbst die besten Betriebssysteme nicht umgehen können: der Netzwerklatenz[cite: 1].

Aus den Lehren dieses Experiments stellten Ian Foster und Carl Kesselman 1999 ein neues Konzept vor: das Grid Computing[cite: 1]. Der Begriff leitet sich vom englischen Electrical Power Grid (Stromnetz) ab[cite: 1]. Das Ziel war eine technologische Utopie: Rechenleistung, Speicherplatz und spezielle Hardware sollen dem Anwender so transparent und standardisiert zur Verfügung stehen, wie der Strom aus der Steckdose kommt[cite: 1].

Im Grid Computing rotten sich Institutionen und Rechner zu sogenannten Virtuellen Organisationen (VO) zusammen[cite: 1]. Eine VO ist eine dynamische Allianz von Organisationen, die für die Dauer der Nutzung ein gemeinsames Interesse vertreten, Ressourcen teilen und Formalitäten wie Zugangsrechte und Abrechnungsschemata vorab klären[cite: 1].

Je nach Architektur und Einsatzzweck unterteilen wir Grids in vier primäre Kategorien[cite: 1]:

Der Fokus liegt auf reiner Rechenkapazität. Sie stellen einem Nutzer Rechnerleistung verteilt zur Verfügung, die ihm lokal fehlt[cite: 1]. Das kann ein gewaltiges Hochleistungsclustersystem sein oder einfach Tausende ungenutzte Workstations außerhalb der regulären Geschäftszeiten[cite: 1].

Hier geht es um die Beherrschung gewaltiger Datenmengen (Big Data). Data Grids erzeugen eine sogenannte Data-Federation, also eine organisationsübergreifende Sicht auf alle verteilten Daten eines Projekts[cite: 1]. Das System wird dezentral verwaltet, sodass der Bereitsteller der Daten stets die uneingeschränkte Kontrolle (Governance) über seine Informationen behält[cite: 1].

Der erste Ansatz, um virtuelle Organisationen zu etablieren. Hier werden Applikationen geteilt[cite: 1]. Die Herausforderungen sind hier extrem tiefgreifend für das Betriebssystem und die Netzwerkschicht: Es erfordert hochsichere Datenverbindungen, komplexe Authentifizierung, Autorisierung, Single-Sign-On (SSO) sowie lückenloses Accounting für die spätere Abrechnung[cite: 1].

Eine Erweiterung der Application Grids mit einem strikten Rollenmodell[cite: 1]. Man unterscheidet streng zwischen: * Grid Benutzer[cite: 1] * Grid Provider (stellt die Infrastruktur)[cite: 1] * Resource Provider (stellt die eigentliche Hard-/Software)[cite: 1] Der entscheidende technische Unterschied: Während Application Grids oft vertikal integriert sind (individuell hinzugefügte Komponenten), müssen bei einem Resource Grid alle Schnittstellen (APIs) absolut offen gelegt und standardisiert sein, damit beliebige Resource Provider ihre Systeme andocken können[cite: 1].

Der Begriff Cloud Computing stammt aus dem IT-Management und wird dem Wirtschafts-Professor Ramnath K. Chellappa zugeordnet[cite: 1]. Er leitet sich schlicht von dem in Netzwerkplänen verwendeten Wolkensymbol für das unbekannte Internet ab[cite: 1].

Während Grids oft forschungsorientiert sind, ist die Cloud extrem kommerziell getrieben. Forrester Research und Saugatuck Technology definieren Cloud Computing als einen Pool aus abstrahierter, hochskalierbarer und verwalteter IT-Infrastruktur, die On-Demand (auf Abruf) bereitgestellt und dynamisch nach dem exakten Gebrauch („pay per use“) abgerechnet wird[cite: 1]. Im Jahr 2009 prophezeite das Marktforschungsunternehmen Gartner in seinem berühmten „Hype Cycle“, dass Cloud Computing die IT-Welt grundlegend verändern würde[cite: 1]. Sie behielten recht.

Wir unterscheiden beim Cloud Computing drei elementare Bereitstellungsmodelle (Typen)[cite: 1]:

* Private Clouds: Unternehmen betreiben eigene Rechenzentren und bieten die Cloud-Dienste exklusiv innerhalb ihrer eigenen, geschützten Unternehmensnetze an[cite: 1]. Die Datensicherheit, Ausfallsicherheit und Corporate Governance liegen zu 100% in der eigenen Hand[cite: 1]. * Public Clouds: Die Dienste (Speicher, Rechenleistung) werden von einem Drittanbieter der Allgemeinheit (kostenlos oder gegen Bezahlung) zur Verfügung gestellt[cite: 1]. Die Instanzen verschiedener Kunden werden auf derselben physischen Hardware gehostet (Multi-Tenancy)[cite: 1]. Der Kunde weiß nicht, wessen Daten noch auf dem gleichen physischen RAM-Modul liegen[cite: 1]. * Hybrid Clouds: Eine Mischform. Unternehmen nutzen ihre Private Cloud für kritische Stammdaten, greifen aber bei extremen Lastspitzen (Cloud Bursting) dynamisch auf Ressourcen externer Public-Cloud-Anbieter zu[cite: 1]. Dies ist nahtlos integriert, sodass der Endanwender nicht bemerkt, wo die Daten physisch verarbeitet werden[cite: 1].

Innerhalb der Cloud („der Wolke“) werden Dienste in aufeinander aufbauenden Schichten (Layers) bereitgestellt[cite: 1].

Die unterste Schicht. Anstatt Serverblech, Router und Switches im eigenen Rechenzentrum zu verschrauben, mietet ihr virtuelle Hardware[cite: 1]. Dies wird auch als Hardware as a Service (HaaS) bezeichnet[cite: 1]. Alles basiert auf extremer Virtualisierungstechnologie (Hypervisoren wie KVM, VMware oder Hyper-V). * Vorteil: Bei Spitzenlasten kann die Infrastruktur dynamisch nach oben skaliert (erweitert) werden[cite: 1]. Der Drittanbieter kümmert sich um kaputte Festplatten oder defekte RAM-Module[cite: 1]. * Zuständigkeit: Alles oberhalb der Hardware (Betriebssystem, Patches, Sicherheit, Anwendungen) obliegt weiterhin euch als Administrator[cite: 1].

Geht einen Schritt weiter. Der Anbieter stellt euch eine vollständige, transparente Entwicklungs- und Laufzeitumgebung (z.B. einen Webserver, Datenbanken, Frameworks) zur Verfügung[cite: 1]. * Vorteil: Entwickler (insbesondere in kleinen Unternehmen) benötigen nur noch einen Browser oder eine IDE und können sofort Code schreiben[cite: 1]. * Zuständigkeit: Das Management des Betriebssystems und der Webserver-Infrastruktur übernimmt komplett der Provider[cite: 1]. Ihr kümmert euch nur noch um euren Code und euren Anwendungs-Lebenszyklus, den ihr über APIs steuert[cite: 1].

Die höchste Abstraktionsebene. Dem Anwender werden fertige, vollständige Anwendungen über das Internet bereitgestellt (z. B. E-Mail, Office-Programme, ERP-Systeme)[cite: 1]. * Vorteil Provider: Er muss den Code nur an einer einzigen zentralen Stelle pflegen und updaten. Eine Instanz der Software bedient unzählige Anwender gleichzeitig[cite: 1]. * Vorteil Kunde: Er braucht nur noch einen Web-Browser und eine Internetverbindung[cite: 1]. Keine lästigen lokalen Updates, keine Serverwartung, keine Backup-Sorgen. Der Anbieter ist für Verfügbarkeit, Redundanz und Datensicherung verantwortlich[cite: 1]. Die Abrechnung erfolgt pro nutzendem Anwender[cite: 1].

Ohne Virtualisierung auf Betriebssystemebene gäbe es keine Cloud. Moderne Linux-Kernel haben Virtualisierung heute fest integriert (z.B. KVM - Kernel-based Virtual Machine).

Wenn ihr IaaS bei einem großen Provider einkauft, bucht ihr keine physische Hardware. Euer „Betriebssystem“ läuft stattdessen in einer Virtuellen Maschine (VM) als isolierter Prozess auf einem Host-OS. Der Hypervisor (VMM - Virtual Machine Monitor) abstrahiert dabei CPU, RAM und Peripheriegeräte. Eine noch leichtgewichtigere Variante, die extrem in PaaS- und SaaS-Strukturen genutzt wird, ist die Container-Virtualisierung (z.B. Docker). Hierbei teilen sich hunderte Container denselben Linux-Kernel des Host-Systems, sind aber durch Kernel-Features wie cgroups (Ressourcenlimitierung) und namespaces (Prozessisolation) streng voneinander getrennt. So können Cloud-Provider Millionen Instanzen mit minimalem Overhead (ohne die Last emulierter Hardware) hosten.

Quellen & Materialien
Dieses Modul basiert auf dem Lehrskript „Betriebssysteme“ der German-Baltic Management School.[cite: 1]