Durch die fortschreitende Digitalisierung machen sich viele Unternehmen Gedanken über die Neuausrichtung ihrer IT-Infrastrukturen. Daher fließt sehr viel Geld in aktualisierte Softwarelizenzen und Hardware-Upgrades. Die Investitionen müssen jedoch einen messbaren Nutzen haben und mit möglichst wenig Risiko verbunden sein. Ein probates Mittel dafür ist die Verschiebung von Investitionskosten zu laufenden Kosten durch die Verlagerung der Dienste und Anwendungen in die Cloud.

Die hierfür angebotenen Pay-as-you-go-Modelle sorgen für eine einfachere Skalierung der Unternehmens-IT. Der Nachteil dieses Ansatzes besteht jedoch darin, dass die komplexen IT-Prozesse nicht mehr durch das eigene Personal bereitgestellt werden und oftmals der direkte Zugriff auf die IT-Ressourcen nicht mehr gegeben ist. Schon kleinere Ausfälle der IT können für Unternehmen einen Rattenschwanz an Problemen verursachen und im Endeffekt viel Geld kosten.

Die Bereitstellung von Cloudressourcen ist eine komplexe Aufgabe und stellt den Prozess der Anwendungsbereitstellung und -verwaltung in Cloudinfrastrukturen dar. Die drei Hauptschritte für die Cloudbereitstellung sind:

1. Die Bereitstellung von virtuellen Maschinen, wobei geeignete VMs instanziiert werden, um die erforderliche Hardware und Konfiguration einer Anwendung zu erfüllen.

2. Die Ressourcenbereitstellung: Dies ist der Prozess der Zuordnung und Planung der instantiierten VMs auf die physischen Cloudserver durch Hypervisoren. Öffentliche Clouds stellen beispielsweise APIs bereit, um eine Ressource zu starten und zu stoppen, aber nicht, um zu kontrollieren, welcher physische Server innerhalb dieser Region oder dieses Rechenzentrums die VM beherbergt.

3. Die Anwendungsbereitstellung auf VMs in der Cloud: Diese kann auf zwei Arten erfolgen. Die erste Methode besteht darin, die Anwendungen gemeinsam bereitzustellen, während eine VM gehostet wird. Bei der zweiten Methode kann der Kunde zunächst die VM bereitstellen und dann in einem separaten Schritt die Anwendungen bereitstellen.

Eine Cloud-Workflow-Instanz kann aus mehreren Clouddiensten bestehen und in einigen Fällen auf einer Reihe von Dienstanbietern basieren. Daher wird die Überwachung der Qualität der Cloudinstanz zu einer komplexen Aufgabe. Außerdem muss zur Laufzeit der Instanz die Servicequalität (Quality of Service; QoS) der laufenden Instanz konsequent überwacht werden, um Verletzungen der zugesagten Service Level Agreements (SLAs) zu vermeiden. Die Überwachung ist der Prozess der Beobachtung und Verfolgung von Anwendungen beziehungsweise Ressourcen zur Laufzeit. Diese bildet die Grundlage für Kontrolloperationen und Korrekturmaßnahmen für den Betrieb von Systemen in Clouds.

Somit hängen das Cloudmonitoring, die SLAs und die Dynamik der Clouddienste eng zusammen. Die Verbesserung der Überwachungsfunktionen trägt dazu bei, SLAs zu erfüllen und den Betrieb der dynamischen Konfiguration zur Laufzeit zu verbessern. Darüber hinaus müssen die SLAs von den Cloudanbietern eingehalten werden, um das von den Verbrauchern geforderte Zuverlässigkeitsniveau zu erreichen.

Die Anwendungsarchitektur bestimmt letztendlich, welche Prozesse und Ressourcen wie und wann für den Betrieb in der Cloud bereitstehen müssen. Die Anwendungen auf den höheren Ebenen (beispielsweise bei Multimedia) sind mehrschichtig aufgebaut und können aus den Nutzern (Clients/Anwendungen), Lastverteilungsmechanismen, Webservern, Streaming-Servern, Anwendungsservern und einem Datenbanksystem bestehen. Bei Bedarf werden unterschiedliche Softwareressourcen auf Basis einer oder mehrerer Hardwareressourcen zur Laufzeit bereitgestellt:

- Ressourcenwahl: Bezeichnet den Prozess, bei dem die Hardwareressourcen (CPU, Speicher und Netzwerk) den Software-Ressourcen wie etwa Webserver, Multimediaserver oder Datenbankserver zugewiesen werden.

- Ressourcenbereitstellung: Der Systemadministrator konfiguriert die ausgewählten Softwareressourcen auf der breitgestellten Hardware für die Kommunikation und die Zusammenarbeit mit anderen bereits im System arbeitenden Softwareressourcen.

- Ressourcenüberwachung: Um sicherzustellen, dass die eingesetzten Software- und Hardwareressourcen dem erforderlichen Niveau entsprechen und somit die SLAs erfüllen, ist ein kontinuierlicher Ressourcenüberwachungsprozess notwendig. Dieser Prozess beinhaltet das Erkennen und Sammeln von Informationen über die aktiven Ressourcen. Im Falle der Erkennung eines anormalen Systemverhaltens wird der System-Orchestrator benachrichtigt, damit richtlinienbasierte Korrekturmaßnahmen durchgeführt werden können.

- Ressourcensteuerung: Der Prozess zur Erfüllung der technischen Anforderungen des Systems sorgt für die Einhaltung der in den SLAs festgelegten QoS-Werte und ist für die Beseitigung von Systemunsicherheiten zur Laufzeit verantwortlich, beispielsweise für das Upgrade oder Downgrade eines Ressourcentyps oder einer Funktionalität.

In der Cloud ist die Überwachung für die Gesundheit des Systems unerlässlich und sowohl für Anbieter als auch für Nutzer wichtig. In erster Linie ist die Überwachung ein Schlüsselinstrument für die Verwaltung von Software- und Hardwareressourcen und die Bereitstellung kontinuierlicher Informationen über diese Ressourcen sowie für die in der Cloud gehosteten Anwendungen der Nutzer. Cloudaktivitäten wie Ressourcenplanung, Ressourcenmanagement, Rechenzentrumsmanagement, SLA-Management, Rechnungsstellung, Fehlerbehebung, Leistungsmanagement und Sicherheitsmanagement benötigen im Wesentlichen eine Überwachung, um einen effektiven und reibungslosen Betrieb des Systems zu gewährleisten.

Beim Cloud-Computing kann die Überwachung auf zwei Arten erfolgen: auf dem High-Level oder dem Low-Level. Die Überwachung auf dem High-Level hängt mit dem Zustand der virtuellen Plattform zusammen. Die Überwachung auf dem Low-Level bezieht sich auf Informationen, die für den Status der physischen Infrastruktur gesammelt werden. Das Cloud-Überwachungssystem kontrolliert die vorab identifizierten Instanzen beziehungsweise Ressourcen in der Cloud auf Anomalien. Bei der Erkennung eines abnormalen Verhaltens versucht das Überwachungssystem, die betreffende Instanz/Ressource automatisch zu reparieren, wenn der entsprechende Monitor eine Selbstheilungsaktion bereitstellt. Im Falle eines Fehlers bei der Autoreparatur oder des Fehlens einer automatischen Reparaturaktion erhält das Support-Team eine Benachrichtigung.

Für die Cloudüberwachung sind kontinuierliche Messungen erforderlich, um Ressourcen oder Anwendungen auf der Cloudplattform in Bezug auf Leistung, Zuverlässigkeit, Stromverbrauch, Fähigkeit zur Einhaltung von SLAs oder auch Sicherheit zu bewerten. Die Überwachungsfunktionen können sowohl auf Rechner- als auch auf Netzwerkebene realisiert werden.

Die rechnerbasierten Tests beschäftigen sich mit dem Status der realen oder virtualisierten Plattformen, auf denen Cloudanwendungen ausgeführt werden. Zu den bei solchen Tests zugrundeliegenden Datenmetriken gehören CPU-Geschwindigkeiten, CPU-Auslastungen, Festplattendurchsätze, VM-Zeiten und -Auslastungen sowie Systemverfügbarkeiten. Netzwerkbasierte Tests konzentrieren sich auf datenbezogene Metriken der Netzwerkschicht, wie Jitter, Round-Trip-Zeiten (RTT), Paketverluste, Verkehrsvolumen und Ähnliches.

Während des Betriebs finden eine Reihe von Operationen statt, um festzustellen, ob die im SLA-Dokument spezifizierten QoS-Parameter erfüllt und somit die mit dem Kunden vereinbarten Leistungsziele garantiert werden können. Parameter, wie beispielsweise die Verfügbarkeit, die Last und der Durchsatz von Hardwareressourcen, können unvorhersehbar variieren. Die Kenntnis des aktuellen Status der Software- und Hardware-Services des Systems ist für den Umgang mit Unsicherheiten unerlässlich, um die Erfüllung der QoS-Ziele zu gewährleisten. Darüber hinaus ist das Erkennen von Ausnahmen und Fehlfunktionen bei der Bereitstellung von Softwarediensten auf Hardwareressourcen von wesentlicher Bedeutung. Hierzu gehört beispielsweise die Anzeige der von jeder Anwendungskomponente (Softwaredienst wie Web- oder Datenbankserver) gelieferten QoS, die auf einer betreffenden Hardware-Ressource gehostet wird. Solche Unsicherheiten können durch die Entwicklung effizienter, skalierbarer, interoperabler Überwachungswerkzeuge beseitigt werden.

Die Anwendungskomponenten (etwa Streaming-Server, Webserver, Indexierungsserver, Speicherdienste und Netzwerk) werden über die unterschiedlichen Cloud-Layer einschließlich Platform-as-a-Service (PaaS) und Infrastruktur-as-a-Service (IaaS) verteilt. Um das Erreichen der QoS-Ziele für die Anwendung als Ganzes zu gewährleisten, sollten Sie daher die QoS-Parameter über alle Schichten des Cloud-Stacks überwachen. Dies schließt Funktionen wie PaaS (Webserver, Streaming-Server, Indexierungsserver et cetera) und IaaS (Rechendienste, Speicherdienste und Netzwerk) ein.

Normalerweise variieren die QoS-Ziele von Anwendungstyp zu Anwendungstyp. Beispielsweise unterscheiden sich QoS-Ziele für interaktive Anwendungen von statischen, einstufigen Webanwendungen (etwa Seiten mit statischen Inhalten) oder mehrstufigen Anwendungen wie Audio-/Video-Streaming auf Abruf. Je nach Anwendungstyp müssen Sie unterschiedliche SLAs aushandeln. Daher enthält ein SLA-Dokument alle Bedingungen und Einschränkungen, die der Art der QoS-Anforderungen jedes Anwendungstyps entsprechen. Soll beispielsweise eine Genomanalyse auf einem Clouddienst stattfinden, sind nur der Datentransfer (Upload und Download), die Netzwerklatenz und die Verarbeitungslatenz von Belang.

Bei Multimedia-Anwendungen ist die Qualität der über das Netzwerk übertragenen Daten dagegen wichtiger. Daher bekommen in diesem Fall andere Parameter Priorität. Werden die QoS-Parameter nicht überwacht, führt dies zu SLA-Verletzungen. Folglich ist die Überwachung grundlegend und verantwortlich für die Zertifizierung der SLA-Konformität. Darüber hinaus ermöglicht die Überwachung den Cloudanbietern, realistischere und dynamischere SLA-Modelle zu erstellen, indem sie sich das Wissen über die vom Nutzer wahrgenommene Leistung zunutze machen.

Beim Cloudmonitoring werden die netzwerk- und systembezogenen Informationen wie CPUAuslastung, Netzwerkverzögerung und Paketverluste der aktiven Systeme gesammelt. Diese Informationen nutzen die Anwendungen für Aktionen, wie den Datentransfer zu dem Server zu leiten, der am nächsten zum betreffenden Nutzer angesiedelt ist. Das soll letztendlich die Erfüllung der SLA-Anforderungen sicherstellen.

Die Netzwerküberwachung lässt sich auf zentralisierten und dezentralisierten Netzwerkarchitekturen realisieren. Auf Basis einer zentralisierten Architektur werden die QoS-Status- und Aktualisierungsabfragen der PaaS- und IaaS-Ressourcen an den zentralen Überwachungsserver übermittelt. Hierbei sammeln die Überwachungstechniken kontinuierlich die Informationen von den Komponenten über periodische Polling-Meldungen. Eine zentralisierte Cloud-Überwachungsarchitektur weist jedoch mehrere Designprobleme auf:

- Single Point of Failure: Ausfälle bereits bei einem einzigen Fehler,

- geringe Skalierbarkeit,

- hohes Kommunikationsaufkommen auf den Verbindungen zum Informationsserver mit der Gefahr von Netzwerkengpässen sowie Überlastungen und

- möglicherweise zu geringe Rechenleistung, um eine große Anzahl von Überwachungsfunktionen gleichzeitig zu bedienen.

Dezentrale Cloudmonitoring-Tools beseitigen die Probleme der zentralisierten Systeme. Eine Überwachungskonfiguration gilt als dezentralisiert, wenn alle im System eingesetzten Komponenten gleich wichtig sind. Fällt eine der Komponenten aus, beeinflusst diese nicht den Betrieb der anderen Komponenten im System.

Die Entwicklung von strukturierten Peer-to-Peer-Netzwerken hingegen ist die Voraussetzung für eine Netzkonstellation, in der eine Zentralisierung umgangen und durch einen Netzwerk-Overlay ein Single Point of Failure eliminiert wird. Napster nutzte beispielsweise ein strukturiertes Peer-to-Peer-System.

Bei einer unstrukturierten Peer-to-Peer-Konfiguration ist das Netzwerk so aufgebaut, dass im Gegensatz zur strukturierten Peer-to-Peer-Konfiguration das Suchverzeichnis nicht zentralisiert angelegt ist. Dies resultiert in einem Single-Point-Fehler im Netzwerkkonstrukt. Gnutella ist beispielsweise eines der bekannten unstrukturierten Peer-to-Peer-Systeme.

Die hybride Peer-to-Peer-Konfiguration wird aus einer Kombination von strukturierten und unstrukturierten Peer-to-Peer-Netzsystemen gebildet. Sogenannte Super-Peers agieren in Teilen des Netzwerks als lokale Suchknoten, wobei sich der größte Teil des Netzwerks wie ein unstrukturiertes Peer-to-Peer-System verhält. Kazaa gilt beispielsweise als eine Mischung aus zentralisierten Napster- und dezentralisierten Gnutella-Netzsystemen.

Die Interoperabilität ist die Fähigkeit unabhängiger, heterogener Systeme, möglichst nahtlos zusammenzuarbeiten. Das Ziel: Informationen auf effiziente und verwertbare Art und Weise austauschen beziehungsweise dem Benutzer zur Verfügung stellen, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind. Die Interoperabilität konzentriert sich bei MaaS auf die Kompatibilität oder Inkompatibilität zwischen den beteiligten Systemen und Datenpartnern.

Moderne Geschäftsanwendungen, die in der Cloud entwickelt werden, sind oft kompliziert und erfordern Interoperabilität. So kann ein Nutzer einer Anwendung beispielsweise einen Webserver in der Amazon-Cloud einsetzen, während der Datenbankserver in Azure läuft. Sind die Daten und Anwendungen nicht ordnungsgemäß über die Cloud hinweg integriert, bleiben deren Vorteile auf der Strecke. Darüber vermeiden Sie mit dem notwendigen Maß an Interoperabilität die Bindung an einen Cloudanbieter (Vendor Lock-in). Die Interoperabilität der Monitoring-Frameworks lässt sich wie folgt klassifizieren:

- Cloudabhängig: Gegenwärtig bieten viele öffentliche Cloudanbieter ihren Kunden die Möglichkeit, ihre Anwendungen mit Hilfe der verfügbaren Monitoring-Tools für CPU, Speicher und Netzwerk zu überwachen. Häufig sind diese Werkzeuge eng mit anderen bestehenden Cloudanwendungen integriert. Beispielsweise ermöglicht CloudWatch von Amazon den Nutzern nur die Verwaltung und Überwachung der Applikationen, die auf AWS-EC2-(CPU)-Diensten basieren. Das Überwachungstool ist jedoch nicht in der Lage, eine Anwendungskomponente zu überwachen, die sich auf der Infrastruktur anderer Cloudanbieter wie etwa Azure befindet.

- Cloudagnostisch: Cloudagnostische Monitoringtools stellen eine große Herausforderung dar. Dies vor allem, da es keine gemeinsame, einheitliche Anwendungsprogrammierschnittstelle (API) für den Aufruf der QoS-Statistik zur Laufzeit von Cloud-Computing-Diensten gibt. Obwohl jüngste Entwicklungen der Cloud-API das Zusammenspiel von Diensten wie CPU, Speicher und Netzwerk, die zu mehreren Clouds gehören können, vereinfachen, haben diese nur eine begrenzte Möglichkeit, ihre Laufzeit-QoS-Statistiken und das Anwendungsverhalten zu überwachen. Die Überwachungstools sollten in der Lage sein, QoS-Daten von Diensten und Anwendungen abzurufen, die mehreren Clouds angehören. Cloudunabhängige Überwachungswerkzeuge sind auch erforderlich, wenn man eine hybride Cloud-Architektur mit Diensten aus privaten und öffentlichen Clouds realisieren möchte.

Für Anwendungsentwickler besteht die Herausforderung darin, die richtigen QoS-Parameter und Ziele über alle Schichten eines Cloud-Stacks einschließlich PaaS und IaaS zu spezifizieren und zu überwachen. Dies kann über einzelne Parameter oder eine Gruppe von Parametern geschehen.

Im Fall von einzelnen Parametern bezieht sich ein Parameter auf ein bestimmtes QoS-Ziel. In jedem System gibt es wichtige Einzelwerte, die exakt und kontinuierlich verfolgt werden müssen. So wird beispielsweise die CPU-Auslastung im Grunde nur durch einen einzigen Parameter in den SLA-Spezifikationen ausgedrückt. Solche Werte können sich auf das gesamte System auswirken, und eine Abweichung eines solchen Wertes kann zu einem schwerwiegenden Systemausfall führen. In den meisten Fällen kommt diesen Parametern eine hohe Priorität bei der Überwachung von SLA-Werten und QoS-Zielen zu.

In einem Szenario mit zusammengesetzten Parametern wird eine Gruppe von Parametern berücksichtigt. Eine Cloudanwendung besteht in der Regel aus vielen Cloud-Software-Services. Daher bestimmt sich die Leistung beziehungsweise Qualität durch das kollektive Verhalten von Softwarediensten. Die Beobachtung mehrerer Parameter zur Überwachung der Funktionalität eines oder mehrerer betroffener Prozesse ergibt als Ergebnis die Parameter zur Bewertung der QoS. Beispielsweise lässt sich der Parameter "Paketverlust" als Parameter aus den zwei Einzelparametern "Einwegpaketverlust" und "Round-Trip-Paketverlust" zusammenstellen. In ähnlicher Weise können Sie "Verzögerung" als zusammengesetzten Parameter aus den drei Einzelparametern "Einwegverzögerung", "RTT-Verzögerung" und "Verzögerungsvarianz" betrachten.

Die Komponenten (Streaming-Server, Webserver, Indexierungsserver, Compute-Service, Speicherdienst und Netzwerk) einer Multimedia-Streaming-Anwendung sind über die unterschiedlichen Cloud-Layer einschließlich PaaS und IaaS verteilt. Um die QoS-Ziele für die Anwendung als Ganzes zu gewährleisten, ist es daher entscheidend, die QoS-Parameter über mehrere Schichten hinweg zu überwachen. Daher besteht die Herausforderung darin, Überwachungswerkzeuge für das Erfassen und Darstellen dieser QoS-Parameter über die unterschiedlichen Schichten hinweg bereitzustellen.

Wie lassen sich nun Überwachungswerkzeuge an die Cloudumgebung anbinden? Programmierschnittstellen ermöglichen das Verbinden von Softwaresystemen zur Überwachung über verschiedene Schichten der Cloud hinweg. Eine solche Schnittstelle umfasst mehrere Komponenten wie APIs, Widgets und die Befehlszeile, um mehrere Komponenten eines komplexen Cloudsystems auf einheitliche Weise zu überwachen.

Ein API ist ein Programmteil, das die Verbindung eines Programms zu anderen Programmen oder Systemen auf Quelltext-Ebene ermöglicht. Dabei werden Informationen zwischen einer Anwendung und einzelnen Programmteilen standardisiert ausgetauscht. Die Übergabe der Daten und Befehle erfolgt strukturiert nach einer definierten Syntax. Der eigentliche Programmablauf erfolgt für das API transparent, denn die Schnittstelle gibt lediglich vor, in welcher Form die Informationen vom Anwendungsmodul entgegengenommen und wieder zurückgesendet werden. Die meisten kommerziellen Überwachungstools bieten dem Nutzer erweiterbare APIs, mit denen diese ihre eigenen Systemfunktionen spezifizieren können.

Es gibt verschiedene Arten von Programmierschnittstellen:

- Befehlszeile: Eine Kommandozeile beziehungsweise die Befehlszeile ist ein Teil eines Computerprogramms, das eine Textzeile als Eingabe vom Benutzer entgegennimmt und im jeweiligen Kontext interpretiert.

- Widgets: Ein Widget ist eine Komponente eines grafischen Fenstersystems. Das Widget besteht zum einen aus dem Fenster, einem sichtbaren Bereich, der Maus- oder Tastaturereignisse empfängt, und zum anderen aus dem nicht sichtbaren Objekt, das den Zustand der Komponente speichert und über bestimmte Zeichenoperationen den sichtbaren Bereich verändern kann. Widgets sind immer in ein bestimmtes Fenstersystem eingebunden und nutzen dieses zur Interaktion mit dem Anwender oder anderen Widgets des Fenstersystems.

- Kommunikationsprotokolle: Der Datenaustausch bei allen kommerziellen MaaS-Werkzeugen erfolgt auf der Basis von Kommunikationsprotokollen. Die jeweiligen Kommunikationsprotokolle unterscheiden sich von einem Überwachungswerkzeug zum anderen.

Da die Überwachung zu einem wesentlichen Bestandteil der gesamten Cloudinfrastruktur wird, muss deren Elastizität eine hohe Priorität eingeräumt werden. Noch sind in der IT-Industrie erhebliche Anstrengungen erforderlich, um zuverlässigere Cloud-Überwachungssysteme bereitstellen zu können. Auch fehlt es noch an Standards bezüglich Verfahren, Format und Metriken zur Bewertung der vom Cloudmonitoring gesammelten Daten.

Werden diese Lücken jedoch geschlossen, dann stehen den Unternehmen Rundum-Sorglospakete für eine professionelle Überwachung der gesamten Unternehmens-IT zur Verfügung. Systemausfälle reduzieren sich auf ein Minimum und profunde Netzwerkspezialisten differenzieren schnell und für den Kunden unsichtbar zwischen ernst zu nehmenden Alarmen und Fehlalarmen. Durch den Einsatz von Managed Monitoring aus der Cloud sparen Unternehmen Geld, das sie in die digitale Transformation investieren können, und profitieren dank genau definierter Service Level Agreements von einer professionellen Überwachung ihrer IT, die sie selbst nie in dieser Form gewährleisten könnten.