So überwinden Unternehmen Hindernisse beim Cloud Bursting

Herausforderungen beim Cloud Bursting

Cloud Bursting (zu deutsch: Wolkenbruch) ist eine Metapher aus der Meteorologie, um diese Variante der Hybrid Cloud zu beschreiben. In diesem Modell übernimmt die Private-Cloud-Infrastruktur den grundlegenden Bedarf an Ressourcen und hostet sensible und ältere Datenbanken sowie Backend-Systeme; die Public Cloud springt bei vorrübergehenden, regelmäßig auftretenden Lastspitzen, unerwarteten Ausreißern und der horizontalen Skalierung von Web-Frontend-Systemen ein.

In der Anfangsphase gab es sogar Visionen von der Kostenoptimierung durch Cloud Bursting. In einem Konzept, das als Multi-Cloud-Arbitrage bekannt ist, nutzt ein Unternehmen mehrere IaaS-Anbieter zusammen mit Echtzeit-Kostenanalysesoftware und leitet bei einem Burst den Workload zum jeweiligen aktuell günstigsten Anbieter weiter.

Wann lohnt sich Cloud Bursting?

Cloud Bursting erfordert ein beträchtliches Maß an Fachwissen für das Cloud-Design und die Implementierungsplanung. Ob sich der Aufwand lohnt, hängt von den konkreten Eigenschaften der einzelnen Workloads und dem Geschäftswert einer Anwendung ab.

Cloud Bursting eignet sich ideal für umsatzgenerierende Anwendungen, bei denen der Kapazitätsbedarf stark schwankt. In diesem Fall erfüllen die Systeme On-Premises die grundlegenden Ressourcenanforderungen, und kostengünstige, Cloud-basierte Instanzen unterstützen sie bei Nachfragespitzen.

Leider kollidierte, wie so oft, eine elegante Theorie mit der Realität in den Unternehmen. Multi-Cloud-Infrastrukturen und Anwendungsdesigns sind in der Realität komplex und mitunter chaotisch. Infolgedessen sind nur wenige Unternehmen in der Lage, Cloud-Bursting-Architekturen zu implementieren. Skeptiker gehen sogar so weit, Cloud Bursting weitgehend als Mythos abzutun. Zu den typischen Hindernissen bei der Einführung gehören laut der Consulting-Firma Architecting IT:

• Vernetzung, nämlich der Aufbau von Verbindungen mit geringer Latenz, hoher Bandbreite sowie redundanten Verbindungen zwischen Public sowie Private Clouds und die automatische Weiterleitung eingehender Verbindungen an den optimalen Standort.
• Sicherheit, da Cloud Bursting auf konsistente Richtlinien und Kontrollen angewiesen ist, sowohl für Benutzer als auch für Systeme über mehrere Umgebungen hinweg.
• Datenkonsistenz, beziehungsweise das Problem, Datenspeicher an mehreren Standorten synchron zu halten, insbesondere in Zeiten hoher Transaktionslast.
• Der Schutz von Unternehmensdaten und das damit zusammenhängende Problem, Backups konsistent zu halten, wenn sie aus mehreren Quellen eingespeist werden.

Es gibt jedoch noch eine fünfte Herausforderung zu ergänzen, nämlich die automatische Bereitstellung und dynamische Skalierung von Ressourcen. Dies hängt ab von der Fähigkeit einer Public Cloud, mit vorübergehender, stark ansteigender Nachfrage umzugehen, die in erster Linie durch Rechen- oder Containerinstanzen, aber auch Ein- und Ausgaben von Speicher auftreten.

Das sind alles lösbare, jedoch komplizierte Probleme. Viele Unternehmen sind daher zu der Feststellung gelangt, dass sich Cloud Bursting nicht lohnt, oder zumindest nicht, solange es keine neue Generation von Modellen für verteilte Anwendungen gibt, die für den Einsatz in mehreren Clouds ausgelegt sind. Für diejenigen, die sich davon nicht abschrecken lassen, haben wir hier jedoch Lösungsvorschläge für die genannten Herausforderungen zusammengestellt.

Cloud Bursting eignet sich ideal für umsatzgenerierende Anwendungen, bei denen der Kapazitätsbedarf stark schwankt.

Netzwerke und Sicherheit

Vernetzung und Sicherheit sind die grundlegendsten Herausforderungen beim Cloud Bursting, da sie für jede hybride Umgebung gelöst werden müssen, unabhängig davon, ob Cloud Bursting zum Einsatz kommt. Glücklicherweise können IT-Teams hierfür auf ein großes Angebot an Technologien und Services zurückgreifen, beispielsweise von den großen Cloud-Anbietern, Telekommunikationsunternehmen, ISPs (Internet Service Provider) und Colocation-Betreibern. Es gibt mehrere sichere Möglichkeiten, Private und Public Clouds bei verbesserter Hybrid-Cloud-Konnektivität miteinander zu verbinden:

• virtuelle Private Clouds, die Standard-VPN-Protokolle (in der Regel IPsec) und einen virtuellen Router verwenden, um ein firmeneigenes Netzwerk mit einem oder mehreren privaten Subnetzen in der Public Cloud zu verbinden. Ein Unternehmen kann sein Unternehmensnetzwerk über ein VPN zu einem Cloud-Subnetz erweitern und die volle Kontrolle über den Verkehrsfluss behalten, indem es virtuelle Dienste wie Router, NAT-Gateways (Network Address Translation) und Internet-Gateways
• Standleitung, die den Service eines Cloud-Providers wie AWS Direct Connect, Azure ExpressRoute oder gleichwertige Produkte von Google, Oracle und IBM Diese Angebote bieten eine dedizierte Verbindung mit geringer Latenz zwischen den Private- und Public-Cloud-Netzwerken eines Kunden. Aufgrund von Einschränkungen bei den Endpunktstandorten, endet der Dienst in der Regel in einem Colocation-Zentrum, wo er mit dem privaten Netz des Kunden verbunden werden kann.
• Standleitung über einen Dienst von einem Telekommunikations-, ISP- oder Colocation-Anbieter. Diese ähneln den Diensten von Cloud-Providern, die Netzwerkunternehmen nutzen jedoch ihre umfangreichen Verbindungen mit den großen Carriern, um weitaus mehr Abschlusspunkte anzubieten. Sie bieten zudem oft Dienste zur Vereinfachung des Designs und von Multi-Cloud-Zusammenschaltungen an, da sie mit großen IaaS- und SaaS-Anbietern per Peering zusammenarbeiten.

Mit beiden Varianten für die private Standleitung behalten Unternehmen die vollständige Kontrolle über das Netzwerk-Routing, das Traffic-Management und die Sicherheitsrichtlinien. Die Dienste von Cloud-Anbietern haben jedoch den Vorteil, dass sie bereits auf weitere Probleme mit dem Cloud Bursting bezüglich ihrer eigenen Cloud ausgelegt sind. Sie laufen über Glasfaserleitungen, die im Rechenzentrum des Cloud-Anbieters enden, so dass sie die höchste Leistung und die geringste Latenz bieten.

Datenkonsistenz und -schutz

Ähnlich wie beim Implementieren von Disaster Recovery mit der Cloud, erfordert das Cloud Bursting, dass Anwendungskomponenten von On-Premises in die Cloud dupliziert werden. Eine Organisation muss die erforderlichen Infrastrukturressourcen und Netzwerktopologie manuell aufbauen, es sei denn, sie hat bereits ein Cloud-agnostisches Infrastructure-as-Code-System wie Terraform, Chef, Ansible oder andere vollständig implementiert, das Instanzen von Ressourcen und Richtlinien automatisch erstellen kann. So oder so können nach dem Aufbau die nativen Tools der Cloud-Anbieter, wie AWS CloudFormation oder Google Cloud Deployment Manager, die Skalierung automatisieren oder Ressourcen in anderen Cloud-Regionen duplizieren.

Die Datensynchronisierung kann dann auf verschiedene Weise angegangen werden, je nach vorhandener Anwendungsarchitektur:

• Das Unternehmen behält die Datenbank On-Premises und sorgt für eine zuverlässige Hybrid-Cloud-Konnektivität mit hoher Geschwindigkeit über die oben genannte Standleitung. Diese Strategie eignet sich für Anwendungen, die nicht latenzempfindlich sind und nicht kontinuierlich auf eine Datenbank zugreifen, da die Frontend- und Business-Logik-Anwendungsebenen bei steigender Last am ehesten Engpässe aufweisen.
• Das Unternehmen repliziert die Datenbank standortübergreifend, insbesondere bei Anwendungen mit hoher transaktionaler Datenbanklast. Die Replikation wirft naturgemäß Probleme bei der Datenkonsistenz auf, aber diese Probleme lassen sich durch Datenbanksysteme wie Oracle und Microsoft SQL Server lösen, die eine standortübergreifende Replikation unterstützen. Anwendungen, die Echtzeit-Konsistenz erfordern, müssen eine ausgefeiltere Methode wie Oracle RAC, GoldenGate oder verschiedene Systeme von Drittanbietern, wie Qlik Replicate oder SymmetricDS verwenden.

Dynamische Ressourcenzuweisung

Sobald die Netzwerkinstallationen und die Anwendungsinfrastruktur eingerichtet sind, umfasst der operative Teil des Cloud Bursting das dynamische Steuern und das Ausgleichen von Workloads zwischen On-Premises- und Cloud-Umgebungen.

Die primären Werkzeuge hierfür sind Load Balancer, Application Delivery Controller und virtuelle Netzwerkschnittstellen. Moderne Load Balancer verfügen über umfangreiche Konfigurationsoptionen zum Festlegen von Lastgewichtungsfaktoren, Ressourcen-/CPU-Grenzwerten und Fallback-Vorkehrungen, um jedem Anspruch an das Cloud Bursting gerecht zu werden.

Cloud-Lastenausgleichservices wie AWS Elastic Load Balancing, Google Cloud Load Balancer oder Azure Load Balancer skalieren die Kapazität automatisch, um erhöhten Datenverkehr zu bewältigen.

Eine weitere Herausforderung beim Cloud Bursting ist das dynamische Kapazitätsmanagement. Containerisierte Anwendungen haben hier einen inhärenten Vorteil, da Kubernetes Cluster und Pods, das sind Gruppen von Containern auf einem Host, automatisch skalieren können. Alle wichtigen Kubernetes-Cloud-Dienste umfassen daher die automatische Skalierung von Clustern.

Das Kapazitätsmanagement ist bei Anwendungen, die auf virtuellen Maschinen (VMs) gehostet werden, schwieriger, obwohl die großen Cloud-Plattformen die automatische Skalierung von Instanzgruppen durch Dienste wie EC2 Auto Scaling und Azure Scale Sets unterstützen. Diese Tools reagieren auf Richtlinien wie virtuelle CPU-Auslastung, Netzwerkverkehr oder andere Metriken von ihren entsprechenden Überwachungsdiensten.