Cloud Bursting – platzt die Private Cloud, ist die Public Cloud zur Stelle

On Premises betriebene Anwendungen in der Private Cloud lassen sich bei Auslastungsspitzen durch die Rechenkapazität einer Public Cloud entlasten.

Lesezeit: 14 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 35 Beiträge

(Bild: Shutter Ryder/Shutterstock.com)

Von
  • Simon Mennig
Inhaltsverzeichnis

In den vergangenen Jahren hat das Cloudgeschäft ein rasantes Wachstum erlebt. Lag der weltweite Umsatz 2018 noch bei 182,4 Milliarden US-Dollar, wird er für 2022 auf 331,2 Milliarden US-Dollar prognostiziert.

Young Professionals schreiben für Young Professionals

Dieser Beitrag ist Teil einer Artikelstrecke, zu der heise Developer explizit junge Entwickler:innen eingeladen hat – mit dem Ziel, ihresgleichen, aber natürlich auch die interessierten "älteren Semester" über aktuelle Trends, Entwicklungen, Phänomene und persönliche Erfahrungen zu informieren. Die Beiträge dieser Reihe erscheinen im monatlichen Rhythmus. Du bist selbst ein "Young Professional" und willst Teil dieser Serie sein? Dann bewirb dich mit einem Vorschlag bei der Redaktion: developer@heise.de. Wir stehen dir mit hilfreichen Tipps über den Schreib-, Redigier- und Freigabeprozess hinweg zur Seite.

Damit steigt auch das Interesse von Unternehmen, die die Cloud für ihre IT-Zwecke nutzen. Jedoch können oder wollen viele Firmen nicht all ihre Daten in eine Public Cloud verlagern (zum Beispiel aufgrund von Compliance-Regeln) und entscheiden sich deshalb für das Modell der hybriden Cloud. Hierbei lassen sich nicht nur die Vorteile mehrerer Technologien vereinen, sondern auch die Unabhängigkeit und Hoheit eines bestimmten Anbieters gewährleisten. Ein weiterer Vorteil besteht im elastischen Skalieren einzelner Komponenten. Sie bietet die Möglichkeit, die Grundlast auf der eigenen Infrastruktur zu betreiben und aufwendige oder unregelmäßige Lasten in der Public Cloud auszuführen. Aus der Kombination von Public und Private Cloud ergeben sich einige neue Optionen:

  • Die Kontrolle über Speicherung und Verarbeitung von Daten bleibt bei der Organisation.
  • Unternehmen können fallweise entscheiden, ob Daten die Private Cloud verlassen dürfen (besonders hinsichtlich personenbezogener und unternehmenskritischer Daten).
  • Für Anwendungsfälle mit stark schwankender Last (z. B. bei einem Reiseveranstalter) ist die Elastizität der Public Cloud attraktiv.

Weiterhin ist ein sogenanntes Cloud Bursting denkbar: Dabei lässt sich eine Anwendung On Premises betreiben, aber bei hoher Last erweitert eine Public Cloud die Kapazitäten automatisch.

Das NIST (National Institute of Standards and Technology) definiert eine hybride Cloud wie folgt:

„Die Cloud-Infrastruktur [der hybriden Cloud] ist ein Zusammenschluss aus zwei oder mehr unterschiedlichen Cloud-Infrastrukturen (privat, gemeinschaftlich oder öffentlich), die grundsätzlich getrennte Einheiten bilden. Allerdings sind sie durch standardisierte oder proprietäre Technologie miteinander verbunden, die die Portabilität von Daten und Anwendungen ermöglicht, wie im Falle von Cloud Bursting für den Lastausgleich zwischen Clouds.“

Meist handelt es sich um die Kombination einer privaten und einer Public Cloud. Kommen mehrere Public Clouds zum Einsatz, spricht man von einer Multicloud. Ein wichtiges Merkmal ist in jedem Fall die Portabilität von Daten und Anwendungen. Der Einsatz von Containern und Kubernetes ermöglicht hierbei einen standardisierten Umgang mit der Anwendung – unabhängig vom Cloud-Anbieter.

Der Begriff „Cloud Bursting“ enthält das englische Wort „to burst“, das für zerplatzen und explodieren steht, aber auch „etwas zum Platzen bringen“ heißen kann. Bildlich gesprochen hieße der Ausdruck auf Deutsch etwa „die Cloud sprengen“. Worum genau geht es hier? Im Kern geht es darum, Anwendungen im privaten Teil einer hybriden Cloud bei steigender Last durch die Ressourcen einer Public Cloud zu erweitern: die Private Cloud „platzt“ gewissermaßen und die Public Cloud fängt sie auf. Viele der eingesetzten Technologien sind dabei nicht auf hybride Clouds beschränkt, sondern sie lassen sich auch auf Multicloud-Umgebungen mit mehreren Kubernetes-Clustern übertragen. Damit ist das Thema für alle interessant, die mehrere Cluster parallel betreiben und diese enger miteinander verzahnen wollen, um die verfügbaren Ressourcen besser zu nutzen. Das trifft insbesondere auf Anwendungsfälle mit schwankender Last zu (s. Abb. 1).

Lastschwankungen mit Auslastungsspitzen (Abb. 1)

(Bild: doubleSlash)

Die meiste Zeit über befindet sich die Auslastung unterhalb der Kapazitätsgrenze der privaten Cloudinfrastruktur. Es kommt zu kurzen Spitzen, welche die Kapazität überschreiten. Diese bestandsüberschreitenden Auslastungen soll der öffentliche und kostenpflichtige Teil der hybriden Cloud auffangen. Auf diese Weise lassen sich die benötigten Ressourcen elastisch beanspruchen und die zusätzlichen Kosten für die Nutzung des öffentlichen Teils gering halten.

Cloud Bursting kann beispielsweise bei der optischen Analyse von Wirkstoffen im Rahmen der Entwicklung neuer Medikamente zum Einsatz kommen. Dazu werden Proben mit verschiedenen Wirkstoffkandidaten kombiniert. Anhand von Aufnahmen der Proben gilt es, ein neuronales Netz zu trainieren, das bereits in einem frühen Stadium erkennen soll, ob es sich um einen vielversprechenden Wirkstoffkandidaten handelt. Da hierbei von einer schwankenden Auslastung auszugehen ist und teilweise sensible medizinische Daten als Basis dienen, handelt es sich um ein passendes Einsatzgebiet für eine hybride Cloud.

Das Training ist – abhängig von der Menge der Daten und dem Aufbau des Netzwerks – vergleichsweise ressourcenhungrig, damit ist es ein Kandidat für das Cloud Bursting. Ein fertig trainiertes Modell lässt sich zentral im privaten Teil der Cloud speichern. Stößt man das Training eines neuronalen Netzes an, beginnt in der hybriden Cloud die dafür notwendige Arbeit. Abhängig von der Ressourcenauslastung läuft der Job entweder im privaten Kubernetes-Cluster oder im öffentlichen Teil der Cloud. Die Übermittlung des trainierten Modells in das zentrale Repository geschieht gesichert. Dabei spielt es keine Rolle, in welchem Teil der hybriden Cloud das Training letztlich stattgefunden hat.