Verwaltung und Austausch von Cloud-Diensten: Rollen, Architektur, Design und Implementierung

Transkript

1 Bereitstellung, Verwaltung und Vermarktung von portablen Cloud-Diensten mit garantierter Sicherheit und Compliance während des gesamten Lebenszyklus Verwaltung und Austausch von Cloud-Diensten: Rollen, Architektur, Design und Implementierung Version 2.0 (Auszug der OpenTOSCA betreffenden Inhalte)

2 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Inhalt 1 Einleitung Inhalt Verfeinerung der CloudCycle-Gesamtarchitektur (AP-302) Beschreibung von Cloud-Diensten mittels TOSCA Interpretation und Ausführung von TOSCA Modellen CloudCycle-Laufzeitumgebung Anforderungen an die Implementierung von CloudCycle-Laufzeitumgebungen CloudCycle-Ökosystem und CloudCycle-Gesamtarchitektur Kommunikationsbeziehungen der Komponenten im Ökosystem Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur Verfeinerung des CloudCycle Rollenmodells (AP-301) Neue Rollen auf Basis erweiterter existierender Rollen Zusätzliche TOSCA-Container bezogene Rollen Die Rolle des Kunden Anforderungsanalyse an die Architektur der TOSCA-Laufzeitumgebung Struktur der Anwendungsfälle Anwendungsfälle für die TOSCA-Laufzeitumgebung TOSCA-Lösungspaket installieren TOSCA-Lösungspaket deinstallieren TOSCA-Laufzeitumgebung installieren TOSCA-Laufzeitumgebung konfigurieren TOSCA-Laufzeitumgebung deinstallieren TOSCA-Laufzeitumgebung starten TOSCA-Laufzeitumgebung herunterfahren TOSCA-Laufzeitumgebung Plugin installieren TOSCA-Laufzeitumgebung Plugin konfigurieren TOSCA-Laufzeitumgebung Plugin deinstallieren Dienstinstanz starten Dienstinstanz verwalten Dienstinstanz terminieren Open Source TOSCA-Container OpenTOSCA (Universität Stuttgart) Architektur Komponenten der Architektur Externe Schnittstellen und APIs Erweiterbarkeit des Containers Grobdesign Datenspeicher Entwurf, Feindesign und Implementierung Arbeitsweise des Containers Fazit und Ausblick Referenzen

3 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 1 Einleitung Das vorliegende Dokument basiert auf den in Arbeitskomplex AK-100 und AK-200 durchgeführten Analysen, Rollenkonzepten, Architektur- und Ökosystemgedanken und erweitert diese in Hinblick auf die Integration einer CloudCycle-Laufzeitumgebung zum Management von Cloud-Diensten, deren Instanzen und Sicherheitsanforderungen. Aus den erarbeiteten Verfeinerungen der CloudCycle-Gesamtarchitektur, Rollen und erarbeiteten Anwendungsfällen werden detaillierte Systemarchitekturen der OpenSource CloudCycle-Laufzeitumgebung vorgestellt. Diese Systemarchitektur wird in nachfolgenden Arbeitskomplexen im Projekt implementiert. Daher stellt dieses Dokument nicht nur die finale erweiterte Gesamtarchitektur des CloudCycle Projekts dar, sondern spezifiziert auch die letztendlichen Implementierungen der im Projekt einzusetzenden Laufzeitumgebung und deren Integration mit bestehenden Managementsystemen der Cloud-Betreiber. Das vorliegende Dokument ist die zweite aktualisierte Version und enthält verschiedene kleinere Anpassungen basierend auf den Erfahrungen und Arbeiten im Projekt, wie in AP-321 Pflege von Architekur- und Designdokumentation aus Erkenntnissen der Pilotstudie vorgesehen. Dieses Dokument enthält damit den endgültigen konzeptionellen Stand des Arbeitskomplexes AK-300 und der beiden TOSCA Laufzeitumgebungen im Rahmen des Projektes CloudCycle. 1.1 Inhalt Das vorliegende Dokument gliedert sich in die folgenden Kapitel: Kapitel 2 beschreibt, wie die CloudCycle-Gesamtarchitektur verfeinert werden muss, um die CloudCycle- Laufzeitumgebung in die Architektur zu integrieren. Kapitel 3 erweitert das in [CC-Ökosystem] definierte Rollenmodell in Hinblick auf die Integration der CloudCycle- Laufzeitumgebung in die Gesamtarchitektur. Kapitel 4 beschreibt 13 Anwendungsfälle, welche an die CloudCycle-Laufzeitumgebung gerichtet sind um diese in die Cloud-Managementsysteme des Cloud-Betreibers zu integrieren. Kapitel 5 beschreiben die beiden Architekturen der CloudCycle-Laufzeitumgebungen, welche im CloudCycle-Projekt entwickelt und implementiert werden. Die Architekturen basieren dabei auf den Erkenntnissen vorangegangener Kapitel und beziehen so die Rollen, Anwendungsfälle und die verfeinerte Gesamtarchitektur bei der Entwicklung mit ein. Kapitel 6 fasst die Ergebnisse zusammen und gibt einen kurzen Ausblick auf die weitere Vorgehensweise, bei der die Möglichkeiten, die die speziellen Eigenschaften der Architekturen und des CloudCycle-Ökosystems bieten, genutzt werden sollen. 2

4 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 2 Verfeinerung der CloudCycle-Gesamtarchitektur (AP-302) In diesem Abschnitt wird die CloudCycle-Gesamtarchitektur wie in [CC-Ökosystem] beschrieben basierend, auf dem CloudCycle-Ökosystem verfeinert. Der Fokus dieses Dokuments liegt dabei auf der Einbettung der CloudCycle- Laufzeitumgebung zum Management von portablen Cloud-Diensten in die Gesamtarchitektur und deren Auswirkungen, welche durch Anwendungsfälle (Use Cases) in späteren Kapiteln dokumentiert werden. In diesem Kapitel werden die CloudCycle-Laufzeitumgebung und deren Integration in die CloudCycle-Gesamtarchitektur beschrieben, sowie Rollen, Akteure und Use Cases abgeleitet bzw. verfeinert. Viele der Anforderungen an eine CloudCycle Laufzeitumgebung ergeben sich aus Konzepten und Vorgaben der OASIS Topology and Orchestration Specification for Cloud Applications (kurz TOSCA), welche als standardisiertes Austauschformat für Cloud-Dienste dem Projekt CloudCycle zugrunde liegt. Um die sich daraus ergebenden Anforderungen besser zu verstehen, wird deshalb in Abschnitt 2.1 zunächst ein Überblick über TOSCA Konzepte gegeben. Im Folgenden werden dann Anforderungen an eine CloudCycle Laufzeitumgebung abgeleitet. 2.1 Beschreibung von Cloud-Diensten mittels TOSCA TOSCA ermöglicht die standardisierte Beschreibung von Cloud-Diensten sowohl bezüglich der Struktur von Anwendungen, d. h. ihrer Bestandteile in Form von Komponenten und deren Relationen untereinander, als auch durch sog. Management-Pläne, welche detaillierte Managementprozesse für verschiedene Anwendungsfälle beschreiben. TOSCA Beschreibungen beinhalten somit detailliertes Wissen über den strukturellen und konzeptionellen Aufbau einer Cloud-Anwendung und bieten zusätzlich die Möglichkeit, technisches und nutzerbezogenes Expertenwissen in Form von Plänen zu hinterlegen. Komplette Lösungen können mit Hilfe von TOSCA als in sich abgeschlossene Archive (Cloud Service Archive, CSAR) paketiert werden, welche sowohl Modellbeschreibungen der Anwendung als auch sämtliche zur Instanziierung und zum Management der Anwendung erforderlichen Artefakte enthalten (siehe Abbildung 1). Abbildung 1: TOSCA Cloud Service Archive Die Beschreibung eines Cloud-Dienstes bzw. der zur Verfügung gestellten Anwendung erfolgt in Form eines Service Templates, welches die strukturelle Beschreibung der Anwendung (Topology Template) sowie Management-Pläne (Plans) enthält. Bausteine für die Modellierung einer Anwendung, d. h. mögliche Komponenten und mögliche Beziehungen zwischen Komponenten, werden durch Node Types und Relationship Types beschrieben. Beide definieren Attribute, die durch eine TOSCA-Laufzeitumgebung konfigurierbar sein sollen (z.b. Die IP-Adresse sein, unter der ein Web Server erreichbar ist, könnte solch ein Attribut sein), sowie Managementoperationen, die von einer TOSCA- Laufzeitumgebung aufgerufen werden können, um bestimmte Managementaktionen (z. B. das Starten oder Stoppen von Komponenten) zu ermöglichen. Ein wichtiger Aspekt von TOSCA ist, dass Artefakte, welche die eben genannten Managementoperation implementieren (sog. Implementation Artifacts) als Teil einer Lösung paketiert werden und Node- oder Relationship Types auf diese Artefakte verweisen können. Weiterhin können Artefakte, 3

5 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE welche für die Instanziierung der jeweiligen Komponenten einer Anwendung nötig sind (z. B. Installationspakete, Laufzeitbibliotheken, Virtual Machine Images) als sog. Deployment Artifacts innerhalb eines CSAR enthalten sein. Für eine TOSCA Laufzeitumgebung ergibt sich somit die Anforderung, diese Erweiterungskonzepte der TOSCA- Spezifikation (d. h. Definition neuer Node- und Relationship Types sowie verschiedener Typen von Artefakten) entsprechend zu unterstützen Interpretation und Ausführung von TOSCA Modellen Im Laufe der TOSCA-Standardisierung haben sich zwei grundlegende Varianten herauskristallisiert, über welche TO- SCA Modelle prozessiert werden können: die deklarative Verarbeitung und die imperative Verarbeitung. Bei der deklarativen Verarbeitung werden bestimmte Anwendungsfälle wie z. B. die Instanziierung oder die Terminierung eines Cloud-Dienstes einzig und allein aus der strukturellen Beschreibung des Dienstes abgeleitet. Für diese Art der Bearbeitung ist eine genau definierte Semantik von Komponenten und Beziehungen zwischen Komponenten notwendig, um sicherzugehen, dass unterschiedliche TOSCA Umgebungen gleiche Abfolgen von Managementaktionen basierend auf der Topologie einer Anwendung ableiten. Zum Beispiel kann aus dem Fakt, dass eine Komponente von einer anderen Komponente abhängig ist, abgeleitet werden, in welcher Reihenfolge Komponenten instanziiert werden müssen. Bei der imperativen Verarbeitung werden sämtliche Anwendungsfälle durch die Ausführung von Management- Plänen realisiert, wobei die genaue Abfolge von auszuführenden Managementaktionen explizit in Plänen (z. B. in Form von BPMN Prozessmodellen) vorgeben ist. Dieser Ansatz hat eine weniger starke Abhängigkeit auf die Definition der Semantik von Komponenten oder Beziehungen, sondern verlässt sich auf die Korrektheit der typischerweise von Experten erstellten Management-Pläne. Neben einer strikten Trennung beider Ansätze ist ebenfalls ein hybrider Ansatz möglich, bei dem zum Beispiel manche Anwendungsfälle, wie das Instanziieren einer Anwendung, mittels des deklarativen Ansatzes und andere Anwendungsfälle, wie das Erstellen ein Backups während der Laufzeit eines Dienstes mittels des imperativen Ansatzes implementiert werden. 2.2 CloudCycle-Laufzeitumgebung Die CloudCycle-Laufzeitumgebung (auch TOSCA-Container bzw. TOSCA-Laufzeitumgebung genannt) ermöglicht voll automatisiertes und portables Management von Cloud-Diensten über deren gesamten Lebenszyklus hinweg. Die Technologie basiert dabei TOSCA, welche die Definition von Cloud-Applikationen und deren Management ermöglicht. Die CloudCycle-Laufzeitumgebung ermöglicht somit, basierend auf der TOSCA-Spezifikation das Management von Cloud-Diensten, welche in TOSCA beschrieben werden. Da in TOSCA Standardisierung und Portabilität speziell unterstützt wird, ermöglicht die Implementierung einer CloudCycle-Laufzeitumgebung basierend auf TOSCA die Austauschbarkeit der Applikationen selbst und deren Management zwischen verschiedenen Cloud-Betreibern und auch zwischen verschiedenen TOSCA Laufzeitumgebungen, da der Standard die angesprochene Portabilität ausdrücklich ermöglicht. Im Folgenden wird beschrieben, wie die CloudCycle-Laufzeitumgebung in die Gesamtarchitektur integriert werden kann und wie dabei verschiedene Implementierungen der Laufzeitumgebung zusammenwirken. CloudCycle-Laufzeitumgebungen implementieren den TOSCA-Standard und sorgen so für Portabilität von Cloud- Diensten zwischen verschiedenen Implementierungen. In CloudCycle werden zwei verschiedene CloudCycle- Laufzeitumgebungen implementiert: Eine kommerzielle Variante und eine Open Source Variante. Ziel von CloudCycle ist es, die beiden Implementierungen so dicht an der standardisierten TOSCA-Spezifikation zu halten, dass Applikationen auf beiden Umgebungen ausführbar und somit portabel sind. Im folgenden Abschnitt werden vier Anforderungen beschrieben, die an eine TOSCA-standardkonforme Implementierung einer CloudCycle-Laufzeitumgebung erhoben werden. Diese dienen als Grundlage für die Portabilität von Cloud-Diensten und der Interoperabilität zwischen den verschiedenen Umgebungen Anforderungen an die Implementierung von CloudCycle-Laufzeitumgebungen An eine korrekte Implementierung einer CloudCycle-Laufzeitumgebung wird eine Reihe von Anforderungen gestellt, um die Ziele des TOSCA Standards insbesondere Portabilität von Cloud-Diensten und Interoperabilität zwischen verschiedenen TOSCA-Laufzeitumgebungen zu erfüllen. Im Folgenden werden diese Anforderungen vorgestellt und im Detail diskutiert. 4

6 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Anforderung 1: TOSCA Spezifikationstreue und Interoperabilität. Um Interoperabilität zwischen verschiedenen CloudCycle-Laufzeitumgebungen zu gewährleisten, müssen diese den TOSCA-Standard gemäß der Definitionen, Schnittstellen und Konzepte der Spezifikation implementieren. Dabei ist vor allem auf Portabilitätsanforderungen der Spezifikation zu achten, welche beispielsweise die Interaktionsmöglichkeiten von Plänen mit der Laufzeitumgebung spezifizieren. Anforderung 2: Erweiterbarkeit. Eine korrekte CloudCycle-Laufzeitumgebungsimplementierung muss bezüglich individueller Applikationstopologien erweiterbar sein. Dadurch sollen verschiedenste Cloud-Dienste modelliert und verwaltet werden können. Es wird gefordert, dass individuelle Komponenten in den Topologien verwendet werden können, beispielsweise beliebige Betriebssysteme oder Web Server. Dafür muss die Laufzeitumgebung Mechanismen anbieten, um individuelle Komponenten in Topologien integrieren und verarbeiten zu können. Anforderung 3: Lose Kopplung. Die Implementierung der Laufzeitumgebung muss auf lose gekoppelten Systemkomponenten basieren, sodass diese im Idealfall vom Cloud-Betreiber individuell ausgetauscht werden können. Ein Beispiel hierfür ist die Komponente zur Ausführung von Management-Plänen: Möchte ein Cloud-Betreiber nur spezielle Plan-Sprachen, wie z. B. BPMN 2.0, zulassen, muss das entsprechende Prozessmanagementsystem in die Laufzeitumgebung integriert werden können. Anforderung 4: Multi-Mandantenfähigkeit. CloudCycle-Laufzeitumgebungen müssen multi-mandantenfähig sein, um bei der Integration in die Cloud-Managementsysteme der Cloud-Betreiber verschiedene Kunden mit entsprechenden unterschiedlichen Sicherheitsmechanismen (z. B. Isolation) gleichzeitig bedienen zu können. Die Multi- Mandantenfähigkeit zielt dabei auf die Granularität der Lösungspakete pro Kunde ab. Die Architektur der in diesem Dokument vorgestellten Open Source CloudCycle-Laufzeitumgebung (Kapitel 5) erfüllt die genannten Anforderungen. 2.3 CloudCycle-Ökosystem und CloudCycle-Gesamtarchitektur In diesem Abschnitt werden das CloudCycle-Ökosystem und die CloudCycle-Gesamtarchitektur beschrieben. Basierend darauf werden diese in den nächsten Kapiteln verfeinert. Abbildung 2 zeigt das CloudCycle-Ökosystem wie in [CC-Ökosystem] beschrieben. Die CloudCycle-Gesamtarchitektur beschreibt dabei einen speziellen Teil dieses Ökosystems, welcher beim Cloud- Betreiber die Architektur der für CloudCycle wesentlichen Cloud Management Komponenten und Aspekte widerspiegelt, in welche die Laufzeitumgebung integriert wird. Die Gesamtarchitektur ist somit in das gesamte Ökosystem eingebettet und detailliert die nötigen Komponenten und Abhängigkeiten, welche zur Erfüllung der CloudCycle-Ziele benötigt werden alle anderen Komponenten wie z. B. Marktplatz sind dabei ohne Relevanz und finden sich deshalb in dieser Architektur nur in Form von Schnittstellen wieder. Da die beiden zu entwickelnden Laufzeitumgebungen konzeptionell ähnlich in die Cloud Management Schicht des Cloud-Betreibers eingebettet werden können, spiegelt die Gesamtarchitektur die abstrakten Gemeinsamkeiten der beiden Laufzeitumgebungen wider und beschreibt deren Integration. Das CloudCycle-Ökosystem unterscheidet zwischen den nachfolgend beschriebenen Akteuren und Komponenten sowie ihren jeweiligen Aufgaben. Abbildung 2 zeigt die Akteure und Komponenten in einem an UML angelehnten Diagramm. Akteure und Komponenten sind jeweils als Stereotype einer Klasse dargestellt (<<actor>>, <<component>>). Gemäß UML spezifiziert ein Akteur eine Rolle, die von Personen, Organisationen oder Systemen angenommen werden kann. Eine Komponente stellt gemäß UML einen modularen Teil eines Systems dar, der selbst wiederum andere Komponenten kapseln kann. Akteure und Komponenten können als abstrakte Klasse deklariert sein, von denen keine Instanzen angelegt werden können (gekennzeichnet durch die Eigenschaft {abstract}). Dies dient zum einen der Strukturierung von Klassen und zum anderen der Vereinfachung. Beispielsweise kann vereinfachend der Begriff Kunde verwendet werden, wenn eine Unterscheidung zwischen Diensteigentümer und 5

7 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Dienstnutzer nicht erforderlich ist [CC-Ökosystem]. Im Folgenden werden die drei Komponenten Cloud-Betreiber, Service-Orchestration und Service-Management zum besseren Verständnis aus [CC-Ökosystem] zitiert. Abbildung 2: CloudCycle-Ökosystem Akteure und Komponenten Cloud-Betreiber. Der Cloud-Betreiber kann typischerweise ein großes oder mittelständiges Unternehmen sein, das Cloud-Dienste anbietet, d. h. über die entsprechende Cloud-Technologie und über ein geeignetes Rechenzentrum verfügt. Hierbei kann es sich um Dienste auf allen Service-Modell-Ebenen handeln. Der Cloud-Betreiber kann über eine Pricing Komponente Angebote für konkrete Dienstinstanzen veröffentlichen. Zusätzlich kann er diese Angebote auch in die vom Marktplatzbetreiber verwaltete globale Pricing Komponente eintragen. Eine Komponente zum Service-Management läuft beim Cloud-Betreiber, über die IT-Ressourcen verwaltet werden können. Aufgabe des Cloud-Betreibers ist, für die Verfügbarkeit der von den Diensten benötigten Ressourcen (Software- und Hardware) zu sorgen. Der Cloud-Betreiber wiederum kann selbst Cloud-Dienste von anderen Cloud-Betreibern, die als Unterauftragnehmer fungieren, nutzen. Hierbei kann es sich sowohl um Dienste auf anderen Service-Modell-Ebenen (z. B. PaaS, IaaS) handeln, auf denen er seine eigenen Dienste aufsetzt, als auch um Dienste, die er nutzt, um daraus eine Aggregation von Diensten durchzuführen. Voraussetzung ist, dass das Sicherheitsniveau, welches diese anderen Cloud-Betreiber bieten, feststellbar ist und das Sicherheitsniveau für die verwalteten Dienste gehalten werden kann. Service-Management. Mit Hilfe des Service-Managements werden Lösungspakete, Dienste und Dienstinstanzen organisatorisch, technisch und kaufmännisch verwaltet. In diesem Dokument liegt der Schwerpunkt auf den technischen Aspekten. Das Service-Management ist dabei für die Administration der verfügbaren Dienste und deren Instanzen verantwortlich. Sie bietet unterschiedliche Sicherheitsniveaus für die Laufzeitumgebung von Cloud-Diensten und deren Instanzen. Die Service-Orchestration wertet die festgelegte Sicherheitsrichtlinie aus und setzt diese um, indem sie die Laufzeitumgebung des Cloud-Dienstes 6

8 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 entsprechend konfiguriert. Darin enthalten ist auch das Self-Service Portal welches es den Kunden ermöglicht, Lösungspakete zu installieren und ihre Dienstinstanzen zu verwalten (Kaufen und Abrechnen, Starten und Stoppen, Anlegen von Backups usw.). 2.4 Kommunikationsbeziehungen der Komponenten im Ökosystem Im Folgenden werden die Beziehungen zwischen den Akteuren des CloudCycle-Ökosystems beschrieben, welche für die Verfeinerung der CloudCycle-Gesamtarchitektur und der beteiligten Rollen benötigt werden. Dabei liegt der Fokus auf den Kommunikationsbeziehungen, über die Cloud-Applikationen übertragen und verwaltet werden (Kommunikationsbeziehungen, siehe Abbildung 3). Abbildung 3: Kommunikationsbeziehungen zwischen den Akteuren Die nachfolgenden Kommunikationsbeziehungen betreffen jeweils den Cloud-Betreiber und seine direkte Peripherie, da in diesem Dokument speziell der Cloud-Betreiber und die Einbettung der CloudCycle-Laufzeitumgebung im Fokus stehen. Die direkten Kommunikationskomponenten sind dabei der Marktplatzbetreiber, der Kunde und der Lösungsanbieter, da diese dem Cloud-Betreiber die Cloud-Applikationen überliefern. Cloud-Betreiber - Marktplatzbetreiber. Der Cloud-Betreiber sucht im Dienstverzeichnis des Marktplatzbetreibers nach Lösungspaketen. Er kann ein gefundenes Lösungspaket direkt beim Marktplatzbetreiber erwerben. Zudem kann der Cloud-Betreiber ein Angebot für Dienstinstanzen abgeben, welches dann in der globalen Pricing Komponente des Marktplatzbetreibers veröffentlicht wird. 7

9 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Cloud-Betreiber - Kunde. Der Kunde kann über die lokale Pricing Komponente des Cloud-Betreibers nach Angeboten für Dienstinstanzen suchen. Der Kunde kann Dienstinstanzen kaufen, administrieren und nutzen. Weiterhin kann er die Installation eines Lösungspaketes beauftragen. In diesem Fall überträgt er das Lösungspaket zu dem Cloud-Betreiber. Cloud-Betreiber - Lösungsanbieter. Der Cloud-Betreiber kann die Entwicklung eines Cloud-Dienstes (Lösungspaket) beim Lösungsanbieter beauftragen oder ein fertiges Lösungspaket direkt einkaufen. 2.5 Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur In diesem Kapitel wird die Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur des CloudCycle- Ökosystems beschrieben und die Auswirkungen verschiedener Implementierungen der Laufzeitumgebung untersucht. Die CloudCycle-Laufzeitumgebung wird in Form eines TOSCA-Containers realisiert, welcher das Management von Cloud-Diensten, welche in TOSCA definiert sind, automatisiert. Der TOSCA-Container wird dabei beim Cloud- Betreiber installiert und übernimmt Aufgaben zum Service-Management und Orchestrierung. Die CloudCycle-Laufzeitumgebung (im Folgenden TOSCA-Laufzeitumgebung genannt) stellt funktional Teile der beiden rot markierten Bereiche in Abbildung 2 zur Verfügung: Verwaltung der Dienste (Service-Management) und Verwaltung deren Instanzen (Cloud-Services). Cloud-Dienste werden basierend auf TOSCA in einem austauschbaren, portablen Format definiert und stellen somit portable Lösungspakete (siehe Abbildung 2, Komponente Lösungspaket ) dar, welche von Marktplatz, Kunde und Cloud-Betreiber als abgeschlossene Einheit gesehen und gehandelt werden können. Diese TOSCA-basierten Lösungspakete werden im Folgenden TOSCA-Lösungspaket genannt. TO- SCA-Lösungspakete beinhalten gemäß der Konzeption von TOSCA nicht nur die Applikationsstruktur und zugehörige Software-Artefakte, sondern auch Pläne, die das Management realisieren. Durch die Portabilität von TOSCA- Lösungspaketen zwischen verschiedenen TOSCA-Laufzeitumgebungen wird die Portabilität auf das Management der Applikation vererbt. Dies ermöglicht den Austausch von Cloud-Diensten zwischen verschiedenen Implementierungen einer TOSCA-Laufzeitumgebung inklusive all ihrer Management-Funktionalitäten. Dadurch können verschiedene Cloud-Betreiber basierend auf diesen Funktionalitäten die Applikation als Dienst ihren Kunden anbieten und auf diesen operieren, ohne dabei spezielles technisches Wissen über die Applikation und deren Management zu benötigen. Durch die standardisierte Beschreibung der TOSCA-Lösungspakete und deren Management können Dienste und Dienstinstanzen verwaltet werden. Die TOSCA-Laufzeitumgebung ist somit für das Installieren und De-Installieren eines Cloud-Dienstes (siehe Abbildung 2, Komponente Dienst ) verantwortlich und ermöglicht dies voll automatisiert. Das instanziieren einer Dienstinstanz (siehe Abbildung 2, Komponente Dienstinstanz ) des installierten Dienstes wird von Management-Plänen übernommen, welche im TOSCA-Lösungspaket applikationsspezifisch enthalten sind. Durch die Kombination dieser beiden Funktionalitäten wird die Self-Service -Komponente in Abbildung 2 realisiert: Marktplatz, Kunde oder Cloud-Betreiber selbst nutzen Schnittstellen (siehe nächsten Absatz) um einen Dienst zu installieren und anschließend Management-Pläne um den Dienst zu instanziieren und zu verwalten bzw. operieren. Welche Funktionen der Cloud-Betreiber dabei dem Marktplatz und dem Endnutzer bzw. Endkunden direkt zur Verfügung stellt und welche Funktionen er durch diese eigenen Schnittstellen nach außen kapselt, ist betreiberspezifisch und nicht Bestandteil dieses Dokuments. Speziell die Preisgestaltung und Bezahlmethoden sind dabei sehr Cloud-Betreiber spezifisch und benötigen weitere Integrationsmechanismen mit den vorhandenen Systemen und der TOSCA-Laufzeitumgebung. 8

10 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Cloud-Services <<component>> Service-Management <<component>> Dienstinstanz <<component>> Lösungspaket <<component>> Selfservice <<component>> Dienst <<component>> Pricing <<component>> TOSCA Laufzeitumgebung <<component>> + Abbildung 4: Verfeinerung des Cloud Betreibers Die resultierende Verfeinerung der CloudCycle-Gesamtarchitektur besteht somit zum einen Teil aus der Integration der TOSCA-Laufzeitumgebung in die Rolle des Cloud-Betreibers wo sie die beiden Komponenten Cloud-Services und Service-Management technisch umsetzt. Die Integration wird in Abbildung 4 veranschaulicht: Die TOSCA- Laufzeitumgebung wird unter Cloud-Services und Service-Management dargestellt und ist für das Verwalten der Dienst- und Dienstinstanz-Komponenten verantwortlich (Integration symbolisiert durch das grüne Plus-Symbol). Wie in vorherigen Abschnitten beschrieben, ist das Self-Service-Management und zugehörige Rechte für Marktplatz und Endnutzer bzw. Endkunde Cloud-Betreiber spezifisch, somit greift die Self-Service-Komponente auf die TOSCA- Laufzeitumgebung zu und steuert diese basierend auf den Anforderungen und Implementierungen des Cloud- Betreibers. 9

11 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 3 Verfeinerung des CloudCycle Rollenmodells (AP-301) In diesem Kapitel werden die Rollen aus AK-100 und AK-200 verwendet, um ein verfeinertes Rollenmodell basierend auf der verfeinerten CloudCycle-Gesamtarchitektur aus Kapitel 2 zu entwickeln, welches anschließend als Grundlage für die Anwendungsfälle an die CloudCycle-Laufzeitumgebung und deren Integration dient. Die Rollen werden dabei auf die verfeinerte Systemsicht aus den vorherigen Kapiteln angewendet, welche aus der Integration der TOSCAbasierten CloudCycle-Laufzeitumgebung (im Folgenden wieder TOSCA-Laufzeitumgebung genannt) in die Gesamtarchitektur bzw. das Ökosystem entstanden ist. Die in AK-100 und AK-200 entwickelten Rollen, Akteure und Komponenten werden dabei im Kern erhalten und um feingranulare Rollen bezüglich der Integration von TOSCA und der CloudCycle-Laufzeitumgebung erweitert. In den folgenden Definitionen werden folgende zwei Begriffe verwendet: TOSCA-Lösungspakete sind Lösungspakete, welche Cloud-Dienste basierend auf TOSCA implementieren und TOSCA- Cloud-Dienste sind Cloud-Dienste, welche durch ein TOSCA-Lösungspaket bereitgestellt werden. 3.1 Neue Rollen auf Basis erweiterter existierender Rollen In diesem Kapitel werden neue Rollen beschrieben, die auf anderen Rollen basieren und diese erweitern. Sie ergänzen das bisherige Rollenmodell um TOSCA-basierte Aspekte und stehen zusätzlich zu den bereits existierenden Rollen zur Verfügung. TOSCA-Enabled-Lösungspaket-Hersteller. Der TOSCA-Enabled-Lösungspaket-Hersteller ist ein Akteur, der aus der Software, die der Software-Hersteller implementiert hat, einen TOSCA-Cloud-Dienst erstellt. D. h., er erzeugt das TOSCA-Lösungspaket, welches den Dienst formal beschreibt und die Software enthält. Er basiert auf der Rolle des Lösungspaket-Hersteller und erweitert diesen um TOSCA-Konzepte. Ob der Hersteller auf TOSCA-Dienste spezialisiert ist und diese ausschließlich anbietet oder gemeinsam mit anderen Cloud-Diensten, ist individuell und wird durch die Definition nicht eingeschränkt. TOSCA-Enabled-Lösungsanbieter. Der TOSCA-Enabled-Lösungsanbieter erweitert die Rolle des Lösungsanbieters um TOSCA-basierte Cloud-Dienste. Diese Dienste werden in Form von TOSCA-Lösungspaketen vertrieben. Das TOSCA- Lösungspaket bietet der TOSCA-Lösungsanbieter wahlweise Interessenten 1 direkt an oder er kann es von einem TOSCA-Enabled-Marktplatzbetreiber vertreiben lassen. Hierzu erstellt er ein TOSCA-Lösungsangebot, das aus einer Beschreibung des Dienstes, des vorgegebenen Rahmens für das Sicherheitsniveau und den Leistungsumfang, sowie der Angabe der Nutzungsbedingungen für den Dienst besteht. Wählt ein Interessent ein Angebot aus, erhält er das TOSCA-Lösungspaket, das im Anschluss bei einem Cloud-Betreiber installiert werden muss. Ob der Hersteller auf TOSCA-Lösungspakete spezialisiert ist und diese ausschließlich anbietet oder gemeinsam mit anderen Lösungspaketen, ist individuell und wird durch die Definition nicht eingeschränkt. TOSCA-Enabled-Marktplatzbetreiber. Die Rolle des TOSCA-Enabled-Marktplatzbetreibers basiert auf der des Marktplatzbetreibers und erweitert diesen um TOSCA-basierte Angebote. Er bietet innerhalb des CloudCycle- Ökosystems einen speziellen Dienst, einen TOSCA-Enabled-Marktplatz 2, an und bietet Interessenten über ein Dienstverzeichnis zusätzlich zu anderen Cloud-Lösungen die zur Verfügung stehenden TOSCA-basierten Cloud- Lösungen an (TOSCA-Lösungspakete). Das letztendliche Angebot ist spezifisch für individuelle Marktplatzbetreiber und liegt außerhalb des Rahmens von CloudCycle. Für TOSCA-basierte Lösungspakete nutzt der TOSCA-Enabled- Marktplatzbetreiber die in Kapitel 2.5 eingeführte Marktplatz Schnittstelle um über diese mit dem Cloud- Betreiber zu interagieren. Die restliche Definition entspricht der des Marktplatzbetreibers. TOSCA-Enabled-Cloud-Betreiber. Die Definition des TOSCA-Enabled-Cloud-Betreibers basiert auf der Definition des Cloud-Providers und erweitert diese um den Einsatz von TOSCA-basierten Cloud-Diensten. Die TOSCA-basierten Cloud-Dienste kann der TOSCA-Enabled-Cloud-Betreiber in Form von TOSCA-Lösungspaketen über den TOSCA- Marktplatz oder direkt bei einem TOSCA-Lösungsanbieter einkaufen. Alternativ können Kunden des TOSCA-Enabled- Cloud-Betreibers auch ihre eigenen TOSCA-Lösungspakete in einer dafür vom TOSCA-Enabled-Cloud-Betreiber für den Kunden bereitgestellten Umgebung installieren. 1 Bei den Interessenten kann es sich sowohl um Kunden als auch um Cloud-Betreiber handeln. 2 D. h. der Marktplatz selbst kann auch ein Cloud-Dienst sein, der von einem Cloud-Betreiber angeboten wird. 10

12 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 TOSCA-Enabled-Mehrwertdienstleister. Der TOSCA-Enabled-Mehrwertdienstleister erweitert die Rolle des Mehrwertdienstleister um TOSCA-bezogene Komponenten wie Security-Plugins, welche die TOSCA-Laufzeitumgebung erweitern, modifizieren oder konfigurieren können. Zusätzlich können diese Art Mehrwertdienstleister Komponenten für die Modellierung von TOSCA-basierten Lösungspaketen bereitstellen, welche den Cloud-Dienst selbst erweitern können. 3.2 Zusätzliche TOSCA-Container bezogene Rollen In diesem Kapitel werden die neuen Rollen eingeführt, welche das bisherige verfeinerte Rollenmodell in Bezug auf die TOSCA-Laufzeitumgebung erweitern: TOSCA-Container-Administrator und TOSCA-Container-Hersteller. TOSCA-Container-Administrator. Der TOSCA-Container-Administrator ist eine neue Rolle, welche für die Administration und Konfiguration einer TOSCA-Laufzeitumgebung beim Cloud-Betreiber verantwortlich ist. Die Rolle kann entweder von einem Mitarbeiter des Cloud-Betreibers übernommen werden oder durch externe auf TOSCA spezialisierte Firmen zur Verfügung gestellt werden. Der Administrator ist vor allem für die Konfiguration und Sicherung der Security Mechanismen in der Laufzeitumgebung verantwortlich. Die TOSCA-Laufzeitumgebung ist gemäß den oben erhobenen Anforderungen erweiterbar. Diese Erweiterungen durch z. B. Plugins werden vom TOSCA- Container-Administrator organisiert, durchgeführt, auf Korrektheit überprüft und überwacht. Die Rolle ist ausdrücklich nur für Aufgaben an der TOSCA-Laufzeitumgebung verantwortlich; nicht für die Administration oder andere Aufgaben bezüglich von Cloud-Diensten oder Lösungspaketen. TOSCA-Container-Hersteller. Die Rolle des TOSCA-Container-Herstellers ist für die Entwicklung einer TOSCA- Laufzeitumgebung auf Basis der TOSCA-Spezifikation zuständig. Der Container-Hersteller darf dabei jede andere Rolle des Rollenmodels gleichzeitig übernehmen. So können Cloud-Betreiber eigene TOSCA-Container gemäß der Spezifikation entwickeln, die besonders auf die vorhandene Infrastruktur optimiert sind und somit für den Cloud- Betreiber die bestmögliche Variante darstellen. In CloudCycle übernehmen zwei Projektpartner die Rolle des TO- SCA-Container-Herstellers, wodurch eine kommerzielle Version und eine Open Source Variante implementiert werden. 3.3 Die Rolle des Kunden Die Rolle des Kunden wird bei der Verfeinerung und Erweiterung des Rollenmodells speziell untersucht. Die Einführung der TOSCA-Technologie in das CloudCycle-Ökosystem hat zu den beiden zusätzlichen Rollen TOSCA-Enabled- Cloud-Betreiber und TOSCA-Enabled-Marktplatzbetreiber geführt. Da der Kunde mit diesen beiden Rollen interagieren kann, könnte man die Rolle eines TOSCA-Enabled-Kunde einführen. Da TOSCA-Lösungspakete abgeschlossene Einheiten sind, die maschinell verarbeitet werden können, ist es im Rollenmodell nicht vorgesehen, dass dem Kunden die Technologie bewusst ist. Somit ist für den Kunden nicht von Bedeutung, um welche Art Lösungspaket es sich beim Handel und Kauf mit Lösungspaketen handelt. Ein Kunde kann ein TOSCA-Lösungspaket bei einem TOSCA-Marktplatz kaufen und verändern. Dieses veränderte Lösungspaket kann nun bei einem TOSCA-Enabled-Cloud-Betreiber installiert werden, um dadurch nutzerspezifische Cloud-Dienste zu realisieren, bei denen der Kunde direkte funktionale oder nicht-funktionale Änderungen am Dienst selbst tätigt. In diesem Fall übernimmt der Kunde bewusst oder unbewusst zusätzlich die Rolle des TOSCA-Enabled- Lösungspaket-Herstellers. 11

13 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 4 Anforderungsanalyse an die Architektur der TOSCA-Laufzeitumgebung Da die Integration der TOSCA-Laufzeitumgebung in das Cloud-Management System des Cloud-Betreibers der zentrale Ansatzpunkt der verfeinerten CloudCycle-Gesamtarchitektur darstellt, werden in diesem Kapitel Anwendungsfälle an die TOSCA-Laufzeitumgebung analysiert, definiert und erklärt. 4.1 Struktur der Anwendungsfälle In diesem Unterkapitel wird die Struktur der Anwendungsfälle definiert und erklärt. Jeder Anwendungsfall hat einen Namen, der den Fall identifiziert. Das Ziel beschreibt, was durch den Anwendungsfall erreicht werden soll. Jeder Anwendungsfall betrifft einen oder mehrere Akteure, welche die beteiligten Rollen am Fall beschreiben. Die Vorbedingungen geben Konditionen und Bedingungen an, die erfüllt sein müssen, dass der Anwendungsfall angewendet werden kann. Sind diese Vorbedingungen nicht erfüllt, ist der Anwendungsfall nicht valide und darf nicht angewendet werden. Die Vorbedingungen stellen möglicherweise Bedingungen an vorhergehende Anwendungsfälle, beispielsweise dass ein System erst installiert sein muss, bevor der Anwendungsfall System starten angewendet werden darf. Nachbedingungen geben den Zustand des Systems bzw. der beteiligten Komponenten an, wenn der Normalablauf des Anwendungsfalls korrekt und ohne Fehler durchgeführt wurde. Sind beim Normalablauf, welcher die einzelnen Schritte des Anwendungsfalls beschreibt, Fehler aufgetreten, gelten die spezifizierten Nachbedingungen nicht mehr oder nur noch teilweise. Anwendungsfälle können Fehlerbehandlung und Unregelmäßigkeiten in einem separat spezifizierten Ablauf bei Fehlerfall dokumentieren, um Fehlerbehandlung explizit zu definieren. 4.2 Anwendungsfälle für die TOSCA-Laufzeitumgebung Die nachfolgenden Unterkapitel beschreiben die Anwendungsfälle für die TOSCA-Laufzeitumgebung im Detail. Die Anwendungsfälle beziehen sich nicht auf das gesamte CloudCycle-Ökosystem, da die zentrale Architekturkomponente, welche zur Erfüllung der CloudCycle-Ziele benötigt wird, ausschließlich die TOSCA-Laufzeitumgebung und deren Plugin-Mechanismen darstellt. Das vollständige CloudCycle-Ökosystem bildet jedoch zusätzliche Komponenten und Interaktionen ab, die nicht im Projekt behandelt werden und somit auch nicht in diesem Dokument diskutiert werden (z. B. Der Marktplatz zum Handeln von Cloud-Diensten). Das Ergebnis dieses Kapitels ist eine Reihe von Anwendungsfällen, die von der TOSCA-Laufzeitumgebung und deren Integration in die Cloud-Managementsysteme der Cloud-Betreiber abgedeckt werden müssen. Die beschriebenen Funktionalitäten werden anschließend als Basis für die Entwicklung der beiden TOSCA- Laufzeitumgebungsarchitekturen verwendet und berücksichtigt. 12

14 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Abbildung 5: Anwendungsfalldiagramm mit beteiligten Akteuren Abbildung 5 zeigt einen Überblick über die 13 Anwendungsfälle und den beteiligten Akteuren. Die Farbgebung der Anwendungsfälle zeigt die logische Zusammengehörigkeit einzelner Anwendungsfälle und soll zur besseren Übersicht dienen. Alle folgenden Anwendungsfälle sind Grundlage für die Implementierung einer minimalen TOSCA- Laufzeitumgebung TOSCA-Lösungspaket installieren Name Ziel TOSCA-Lösungspaket installieren Dieser Anwendungsfall beschreibt die Installation eines TOSCA-Lösungspakets auf die TOSCA-Laufzeitumgebung. Nach der Installation kann der Dienst, welcher durch das Lösungspaket beschrieben wird, über die TOSCA- Laufzeitumgebung instanziiert werden und dem Endkunden zur Verfügung gestellt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystem können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde ein Lösungspaket beim Cloud-Betreiber installieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommuni- 13

15 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Akteure kationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TOSCA- Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung ist so konfiguriert, dass sie alle genutzten Plugins des TOSCA-Lösungspakets unterstützt (z. B. die verwendete Plansprache) Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Die im Lösungspaket verwendeten Systeme zum Management des Dienstes sind verfügbar Nachbedingungen Das TOSCA-Lösungspaket wurde ordnungsgemäß in die TOSCA- Laufzeitumgebung installiert (bei der Installation sind keine Fehler aufgetreten) Der durch das TOSCA-Lösungspaket beschriebene Dienst kann nun instanziiert werden (siehe Anwendungsfall Dienstinstanz instanziieren ) Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Installationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und übergibt ein TOSCA-Lösungspaket und die zugehörigen Meta-Informationen, die zur Installation benötigt werden 2. Nachdem das Lösungspaket übergeben wurde, installiert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Nach der Installation erscheint der Dienst in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann vom TECB (oder einer kapselnden Komponente) in Dienstinstanzen instanziiert werden. Die Zuordnung von Kundeninformationen und Dienstinstanz ist dabei Aufgabe des TECB bzw. seines Management Systems und liegt daher außerhalb dieses Anwendungsfalls Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Installationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und übergibt ein TOSCA-Lösungspaket und die zugehörigen Meta-Informationen, die zur Installation benötigt werden 2. Nachdem das Lösungspaket übergeben wurde, installiert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Bei der Installation des TOSCA-Lösungspakets tritt ein Fehler auf 4. Das Lösungspaket wird nicht installiert und alle bereits installierten Komponenten werden deinstalliert und der Zustand der Laufzeitumgebung zurückgesetzt auf den Standpunkt vor der Installation 14

16 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version TOSCA-Lösungspaket deinstallieren Name TOSCA-Lösungspaket deinstallieren Ziel Dieser Anwendungsfall beschreibt die Deinstallation eines TOSCA- Lösungspakets auf der TOSCA-Laufzeitumgebung. Nach der Deinstallation kann der Dienst, welcher durch das Lösungspaket beschrieben wird, nicht mehr über die TOSCA-Laufzeitumgebung instanziiert werden. Akteure Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystem können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde ein Lösungspaket beim Cloud-Betreiber deinstallieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Alle Dienstinstanzen basierend auf dem zu deinstallierenden TOSCA- Lösungspakets sind beendet Es existiert keine Instanz des Dienstes mehr, andernfalls kann dieser Use Case nicht angewendet werden. Dies muss durch das System verhindert werden. Nachbedingungen Das TOSCA-Lösungspaket wurde ordnungsgemäß aus der TOSCA- Laufzeitumgebung deinstalliert (bei der Deinstallation sind keine Fehler aufgetreten) Alle Laufzeitdaten des Dienstes und zugehöriger Instanzen sind vom System entfernt worden Der durch das TOSCA-Lösungspaket beschriebene Dienst kann nun nicht mehr instanziiert werden (siehe Anwendungsfall Dienstinstanz instanziieren ) Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Deinstallationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert das zu deinstallierende TOSCA-Lösungspaket 2. Nachdem das Lösungspaket spezifiziert wurde, deinstalliert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Nach der Deinstallation erscheint der Dienst nicht mehr in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nun nicht mehr in Dienstinstanzen instanziiert werden. 15

17 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Deinstallationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert das zu deinstallierende TOSCA-Lösungspaket 2. Nachdem das Lösungspaket spezifiziert wurde, tritt bei der Deinstallation ein Fehler auf 3. Der TOSCA-Container-Admin wird beauftragt, die Fehlerursache zu untersuchen und gegebenenfalls den Dienst von Hand zu deinstallieren TOSCA-Laufzeitumgebung installieren Name TOSCA-Laufzeitumgebung installieren Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß installiert wird um anschließend für die Installation von TOSCA- Lösungspaketen und Instanziierung von Dienstinstanzen zur Verfügung zu stehen TOSCA-Container-Administrator (TCA) Vorbedingungen Der TOSCA-Enabled-Cloud-Betreiber stellt alle nötigen Infrastruktursysteme, welche für die Installation der TOSCA-Laufzeitumgebung benötigt werden, zur Verfügung Nachbedingungen Die TOSCA-Laufzeitumgebung ist installiert und kann anschließend für die Installation von TOSCA-Lösungspaketen und Instanziierung von Dienstinstanzen benutzt werden Normalablauf 1. Der TOSCA-Container-Administrator installiert alle Komponenten der TOSCA- Laufzeitumgebung und konfiguriert sie 2. Der TOSCA-Container-Administrator installiert nötige Plugins, die ihm vom TOSCA-Enabled-Cloud-Betreiber vorgegeben werden 3. Die TOSCA-Laufzeitumgebung ist installiert TOSCA-Laufzeitumgebung konfigurieren Name TOSCA-Laufzeitumgebung konfigurieren Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung konfiguriert werden kann. Beispiele für Konfiguration sind die Auswahl der Systemkomponenten, z. B. verschiedene Datenspeicher zum Ablegen der Lösungspakete, oder die Konfiguration der grafischen Oberfläche der TOSCA- Laufzeitumgebung TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Nachbedingungen Die neue Konfiguration der TOSCA-Laufzeitumgebung wurde übernommen 16

18 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Normalablauf 1. Der TOSCA-Container-Administrator konfiguriert die TOSCA- Laufzeitumgebung über die Konfigurationsschnittstelle des Systems 2. Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß konfiguriert und das System nimmt die neue Konfiguration an und setzt diese um TOSCA-Laufzeitumgebung deinstallieren Name Ziel TOSCA-Laufzeitumgebung deinstallieren Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß deinstalliert wird Akteure TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Alle Dienste und Dienstinstanzen wurden deinstalliert / terminiert Es sind keine Laufzeitdaten von Dienst bzw. Dienstinstanz mehr auf dem System Nachbedingungen Die TOSCA-Laufzeitumgebung wurde mit allen zugehörigen Laufzeitdaten, Teilsystemen und Plugins deinstalliert Normalablauf 1. Der TOSCA-Container-Administrator deinstalliert alle Komponenten der TO- SCA-Laufzeitumgebung und löscht zugehörige Laufzeitdaten 2. Die TOSCA-Laufzeitumgebung ist vollständig deinstalliert TOSCA-Laufzeitumgebung starten Name TOSCA-Laufzeitumgebung starten Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß gestartet wird, um anschließend für die Installation von TOSCA- Lösungspaketen und Instanziierung von Dienstinstanzen zur Verfügung zu stehen TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA-Laufzeitumgebung installieren ) Nachbedingungen Die TOSCA-Laufzeitumgebung wurde gestartet und kann nun für die Installation von TOSCA-Lösungspaketen und Instanziierung von Dienstinstanzen benutzt werden Normalablauf 1. Der TOSCA-Container-Administrator startet alle Komponenten der TOSCA- Laufzeitumgebung 2. Der TOSCA-Container-Administrator führt eine Test-Suite aus, welche die korrekte Funktionsweise der TOSCA-Laufzeitumgebung prüft 3. Bei erfolgreicher Prüfung ist die Umgebung gestartet und wird für die Managementsysteme des Cloud-Betreibers freigegeben 17

19 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator startet alle Komponenten der TOSCA- Laufzeitumgebung 2. Der TOSCA-Container-Administrator führt eine Test-Suite aus, welche die korrekte Funktionsweise der TOSCA-Laufzeitumgebung prüft 3. Bei fehlgeschlagener Prüfung wird die Umgebung nicht freigegeben und der TCA wird mit der Suche und Beseitigung der Fehlerursache beauftragt TOSCA-Laufzeitumgebung herunterfahren Name Ziel TOSCA-Laufzeitumgebung herunterfahren Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß gestoppt bzw. heruntergefahren Akteure TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA-Laufzeitumgebung installieren ) und wird ausgeführt Alle Dienstinstanzen von installierten Diensten wurden ordnungsgemäß beendet (siehe Anwendungsfall Dienstinstanz terminieren ) Nachbedingungen Die TOSCA-Laufzeitumgebung wurde heruntergefahren Normalablauf 1. Der TOSCA-Container-Administrator beendet alle Komponenten der TOSCA- Laufzeitumgebung 2. Die TOSCA-Laufzeitumgebung wurde vollständig heruntergefahren TOSCA-Laufzeitumgebung Plugin installieren Name TOSCA-Laufzeitumgebung Plugin installieren Ziel Dieser Anwendungsfall beschreibt die Installation eines TOSCA- Laufzeitumgebung Plugins in die TOSCA-Laufzeitumgebung. Nach der Installation übernimmt das Plugin die konzipierten Aufgaben und kann so beispielsweise Sicherheitsanforderungen umsetzen. Akteure Plugins stellen Erweiterungen der Funktionalität einer TOSCA- Laufzeitumgebung dar. Sie können dadurch beispielsweise Management- Funktionalitäten von Anwendungen unterstützen oder überhaupt erst ermöglichen. Plugins stellen dabei Funktionalitäten, wie zum Beispiel weitere Workflow-Engines, die zur Ausführung von Management-Plänen verwendet werden oder Laufzeitumgebungen, welche benötigt werden, um Services, die von Management-Plänen benötigt werden, bereitzustellen. TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu installierende Plugin ist noch nicht in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin ist in der TOSCA-Laufzeitumgebung installiert und kann verwendet werden 18

20 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Die Installation eines Plugins bietet möglicherweise Funktionen, welche von Anwendungen zu deren Management benötigt werden. Nach der Installation eines Plugins kann es somit möglich sein, dass Anwendungen, welche vorher aufgrund eines fehlenden Plugins nicht verwaltet werden konnten, nun betrieben werden können. Normalablauf 1. Der TOSCA-Container-Administrator installiert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Der TOSCA-Container-Administrator schaltet das Plugin nach erfolgreicher Installation über die Management Oberfläche der TOSCA-Laufzeitumgebung frei. Anschließend kann es von der Laufzeitumgebung benutzt werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator installiert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Installation tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig TOSCA-Laufzeitumgebung Plugin konfigurieren Name TOSCA-Laufzeitumgebung Plugin konfigurieren Ziel Dieser Anwendungsfall beschreibt die Konfiguration eines TOSCA- Laufzeitumgebung Plugins der TOSCA-Laufzeitumgebung. Ein Beispiel für eine Konfiguration ist das Einstellen des Sicherheitsniveaus für bestimmte Anwendungstopologien. Akteure TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu konfigurierende Plugin ist in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin wurde neu konfiguriert und beeinflusst fortan das Verhalten des Plugins Da das Management von Anwendungen auf Funktionalitäten von Plugins basieren kann, hat die Konfiguration eines Plugins und damit dessen Funktionalität möglicherweise Auswirkungen auf den Betrieb einer (installierten) Anwendung. Wird ein Plugin neu konfiguriert, können möglicherweise betroffene Management-Funktionalitäten der Anwendung nicht mehr lauffähig sein oder ein anderes Verhalten zeigen. Normalablauf 1. Der TOSCA-Container-Administrator konfiguriert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Der TOSCA-Container-Administrator schaltet das Plugin nach erfolgreicher Konfiguration über die Management Oberfläche der TOSCA- Laufzeitumgebung frei. Anschließend sind die getätigten Änderungen aktiv und kann von der Laufzeitumgebung benutzt werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator konfiguriert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Konfiguration tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig 19

21 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE TOSCA-Laufzeitumgebung Plugin deinstallieren Name TOSCA-Laufzeitumgebung Plugin deinstallieren Ziel Dieser Anwendungsfall beschreibt die Deinstallation eines TOSCA- Laufzeitumgebung Plugins aus der TOSCA-Laufzeitumgebung. Akteure TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu deinstallierende Plugin ist in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin ist in der TOSCA-Laufzeitumgebung deinstalliert und kann nicht mehr verwendet werden Da das Management von Anwendungen auf Funktionalitäten von Plugins basieren kann, hat die Deinstallation eines Plugins und damit dessen Funktionalität möglicherweise Auswirkungen auf den Betrieb einer (installierten) Anwendung. Fehlt ein Plugin, können Management-Funktionalitäten der Anwendung möglicherweise nicht mehr lauffähig sein. In diesem Fall teilt die TOSCA-Laufzeitumgebung dem Nutzer mit, dass aufgrund eines fehlenden Plugins die Management-Funktionalität nicht verwendet werden kann. Normalablauf 1. Der TOSCA-Container-Administrator deinstalliert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Das Plugin ist nicht mehr in der TOSCA-Laufzeitumgebung installiert und kann nicht mehr verwendet werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator deinstalliert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Deinstallation tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig Dienstinstanz starten Name Ziel Dienstinstanz starten Dieser Anwendungsfall beschreibt die Instanziierung einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Nach der Instanziierung kann die Dienstinstanz konfiguriert und vom Endnutzer genutzt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß des CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber instanziieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. 20

22 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Akteure TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu instanziierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Nachbedingungen Die Dienstinstanz wurde ordnungsgemäß instanziiert und kann nun konfiguriert und vom Endnutzer genutzt werden Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Methode, welche für die Dienstinstanziierung verantwortlich ist, an der Kommunikationsschnittstelle der TO- SCA-Laufzeitumgebung auf und referenziert den zu instanziierenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird 2. Die TOSCA-Laufzeitumgebung leitet die vollautomatische Instanziierung des referenzierten Dienstes ein 3. Nach der Instanziierung erscheint die Dienstinstanz in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nun konfiguriert und vom Endnutzer genutzt werden Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstinstanziierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu instanziierenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird 2. Die TOSCA-Laufzeitumgebung instanziiert vollautomatisch den referenzierten Dienst. Dabei kommt es zu einem Fehler und die Dienstinstanz kann nicht ordnungsgemäß instanziiert werden 3. Der TOSCA-Container-Administrator wird mit der Ursachenforschung und Behebung des Fehlers beauftragt Dienstinstanz verwalten Name Ziel Dienstinstanz verwalten Dieser Anwendungsfall beschreibt die Verwaltung einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Die Verwaltung der Dienstinstanz kann dabei unterschiedlichste Ausprägungen annehmen. Beispiele sind das Skalieren einer Dienstinstanz um die Performanz der Applikation zu erhöhen, das Aktualisieren von Sicherheitsmechanismen oder Einspielen von Updates, bis hin zur Erstellung von Datenbackups. Die Verwaltungsaufgaben sind daher anwendungsspezifisch bezüglich des Cloud-Dienstes und werden über die TOSCA-Laufzeitumgebung aufgerufen. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber verwalten, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Ma- 21

23 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Akteure nagement Systemen des Cloud-Betreibers integriert. Somit ist nur der TOSCA- Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu terminierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Die zu terminierende Dienstinstanz (Instanziierter Dienst welcher durch ein TOSCA-Lösungspaket beschrieben wird) wurde ordnungsgemäß instanziiert (siehe Anwendungsfall Dienstinstanz starten ) Nachbedingungen Die intendierte Verwaltungsaufgabe wurde erfolgreich an der Dienstinstanz ausgeführt Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die generische Dienstverwaltungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu verwaltenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird, und die beabsichtigte Verwaltungsaufgabe 2. Die TOSCA-Laufzeitumgebung führt die spezifizierte Verwaltungsaufgabe vollautomatisch an der referenzierten Dienstinstanz durch Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die generische Dienstverwaltungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu verwaltenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird, und die beabsichtigte Verwaltungsaufgabe 2. Bei der Durchführung der spezifizierten Verwaltungsaufgabe tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und führt die Verwaltungsaufgabe möglicherweise manuell an der Dienstinstanz durch Dienstinstanz terminieren Name Ziel Dienstinstanz terminieren Dieser Anwendungsfall beschreibt die Terminierung (Beenden) einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Nach der Terminierung wird die Instanz des Dienstes beendet und kann nicht weiter vom Endnutzer genutzt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber terminieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber 22

24 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Akteure spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu terminierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Die zu terminierende Dienstinstanz (Instanziierter Dienst welcher durch ein TOSCA-Lösungspaket beschrieben wird) wurde ordnungsgemäß instanziiert (siehe Anwendungsfall Dienstinstanz starten ) Nachbedingungen Die Dienstinstanz wurde terminiert Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstterminierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert die zu terminierende Dienstinstanz 2. Die TOSCA-Laufzeitumgebung terminiert vollautomatisch die referenzierte Dienstinstanz 3. Nach der Terminierung erscheint die Dienstinstanz nicht mehr in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nicht mehr vom Endnutzer genutzt werden Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstterminierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert die zu terminierende Dienstinstanz 2. Die TOSCA-Laufzeitumgebung versucht die referenzierte Dienstinstanz zu terminieren. Dabei tritt ein Fehler auf. 3. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und versucht die Dienstinstanz manuell zu terminieren 23

25 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 5 Open Source TOSCA-Container OpenTOSCA (Universität Stuttgart) In diesem Kapitel werden Architektur (5.1), Grobdesign (5.2) und Feindesign (5.3) des OpenTOSCA-Containers (in den vorherigen Kapiteln TOSCA-Laufzeitumgebung bzw. CloudCycle- Laufzeitumgebung genannt) detailliert beschrieben. Der Container ist eine Laufzeitumgebung zur Ausführung von TOSCA Service Templates und implementiert in der aktualisierten Version die TOSCA-Spezifikation in der Version 1.0, welche die aktuell von OASIS standardisierte Version ist. OpenTOSCA wird von der Universität Stuttgart im Rahmen des CloudCycle-Projekts entwickelt und wird als Open Source Software bereitgestellt. Dies ermöglicht einer breiten Masse an Entwicklern und Nutzern von den neuen Technologien im Bereich Cloud Computing zu profitieren und OpenTOSCA bei Bedarf anzupassen oder weiterzuentwickeln. Die Modellierung und Sicherstellung von Sicherheits- und Compliance-Policies wird in diesem Dokument nicht explizit betrachtet. Die in CloudCycle dafür entwickelten Konzepte und in OpenTOSCA implementierten Lösungen sind in den publizierten wissenschaftlichen Beiträgen [CC-Policy1, CC-Policy2] zu finden. 5.1 Architektur Im Laufe der Definition der Architektur wurden verschiedene Open Source Komponenten identifiziert und evaluiert, welche vom OpenTOSCA-Container genutzt werden. Für die Datenbank ist das selbstverständlich, daneben werden zur Ausführung von Plänen, also Workflows, und Implementation Artifacts existierende Komponenten verwendet, wie in Abbildung 6 dargestellt. Diese werden durch eine generische Schnittstelle vom Container getrennt, sind also austauschbar und kombinierbar, um die Erweiterbarkeit und lose Kopplung des Containers zu erreichen. In Zukunft können damit einfach weitere Workflow Engines und Implementation Artifact Runtimes integriert werden. Dies entspricht den gestellten Anforderungen aus Kapitel Die Komponente OpenTOSCA-Container in Abbildung 6 wird somit neu entwickelt, die in Grau dargestellten Teile stellen bestehende externe Komponenten dar, genannt Umsysteme, welche nicht direkter Bestandteil des Containers sind und nur entsprechend konfiguriert und integriert werden. Im Folgenden zeigen wir die Architektur des OpenTOSCA-Containers, ihre Komponenten (5.1.1), sowie die Integration der Umsysteme. In Kapitel die Schnittstellen des Containers diskutiert. Abbildung 6: OpenTOSCA-Container und seine Umsysteme 24

26 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version Komponenten der Architektur In der in Abbildung 7 dargestellten Architektur werden TOSCA-Lösungspakete über die Container API in den Open- TOSCA-Container importiert. Dies kann direkt aus einem Modellierungs-Tool, über die grafische Administrations Oberfläche des Containers oder über andere in Zukunft entwickelte Werkzeuge geschehen. Im Container installierte TOSCA-Lösungspakete können über das Self-Service Portal vom Kunden instanziiert werden, wenn die entsprechenden Daten im TOSCA-Lösungspaket enthalten sind. Der Container besteht aus fünf großen logischen Teilen, wie abgebildet in Abbildung 7: (i) Die Control-Komponente steuert den ganzen Container, indem sie die anderen Komponenten orchestriert, je nach Zustand der verwalteten Dienste. (ii) Die Core-Komponente bietet eine Reihe von Funktionalitäten, welche von allen anderen Komponenten gebraucht werden, insbesondere die Verwaltung der Daten, Dateien und Modellen. (iii) Implementation Artefakte, welche die Management Operationen der verschiedenen TOSCA Node Types implementieren, werden von der Implementation Artifact Engine in Abhängigkeit des Types an eines der Plugins übergeben. Die Implementation Artifact Engine stellt außerdem sicher, dass der Container die benötigten Anforderungen der Implementation Artifacts bietet und entscheidet somit, welche Implementation Artifacts deployed werden, insbesondere dann, wenn das TOSCA-Lösungspaket verschiedene Alternativen beinhaltet. (iv) Nach einem ähnlichen Prinzip funktioniert die Plan Engine, in der ein auf die Workflow Engine abgestimmtes Plugin die Management Pläne verarbeitet: Zuerst werden die Pläne analysiert, d.h. es wird untersucht, welche Services ein Plan aufruft. Da diese Aufrufe nur durch Service-Schnittstellen definiert sind, müssen konkrete Service-Endpunkte in den Deployment-Descriptor des Plans geschrieben werden. Diese Informationen werden anschließend bei der Ausführung des Plans verwendet, um die Services aufzurufen. (iv) Der Service Invoker stellt die Verbindung zwischen den Plänen und den von ihnen aufgerufenen Operationen (egal ob durch Implementation Artefakte Implementier oder in der Container oder Portability API angeboten) her. In den nachfolgenden Kapiteln zum Design und Implementierung gehen wir nochmals detailliert auf die Funktionsweise und Realisierung der einzelnen Komponenten ein. Admin UI Self-Service Portal Modeling Tool Container API Operation Control Implementation Artifact Engine Plugin Implementation Artifact Runtime Service Invoker Core Datenspeicher Plugin Plan Engine Plan Portability API Management Plan Plan Runtime Komponente Plugin Umsystem Extene APIs Abbildung 7: Architektur des OpenTOSCA-Containers Externe Schnittstellen und APIs Aktuell bietet der OpenTOSCA-Container drei Arten von Schnittstellen nach außen bzw. für die Pläne an, welche im Folgenden näher beschrieben werden: 25

27 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Plan Portability API Damit Pläne portabel zwischen verschiedenen TOSCA-Laufzeitumgebungen sind, dürfen sie keine Abhängigkeiten zu Schnittstellen einer speziellen Laufzeitumgebung haben. Pläne brauchen jedoch Zugriff auf die Modell- und Instanz- Daten der Laufzeitumgebung. Damit Management Pläne die Struktur des Dienstes interpretieren und entsprechend darauf reagieren können, ist ein API nötig, welches den Plänen lesenden Zugriff auf die Topologie des Dienstes, wie im TOSCA Service Template beschrieben, gibt. Instanzdaten hingegen sind die Eigenschaften der Knoten und Kanten der Topologie (z. B. die IP Adresse, Benutzernamen) einer Dienstinstanz, also eines laufenden, instanziierten Dienstes. Pläne müssen diese Instanzdaten sowohl lesen als auch schreiben können, beispielsweise wenn eine Management Aktion den Zustand eines Dienstes geändert hat. Da diese Art von Daten für Management Pläne nötig sind, Pläne jedoch nicht von einer bestimmten Laufzeitumgebung abhängig sein dürfen, sollte diese sogenannte Plan Portability API in Zukunft standardisiert werden. Container API Die Container API ist spezifisch für den OpenTOSCA-Container und ermöglicht die Steuerung des Containers. Hier sind Funktionalitäten wie der Import, das Auflisten und das Löschen von TOSCA-Lösungspaketen möglich, sowie die Verwaltung der Container Plugins. Service Invoker Der Service Invoker ist die zentrale Anlaufstelle für Pläne wenn diese Operationen welche durch Implementation Artifacts oder durch die Container API bereitgestellt werden aufrufen. Der Pläne können somit ausschließlich gegen diese Schnittstelle implementiert werden und der Service Invoker reicht die Anfragen dann an die entsprechenden Operationen weiter. Dies entkoppelt die Pläne komplett von der Implementierung des TOSCA Containers welcher die Implementation Artifacts an einer beliebigen Stelle deployen kann, dazu macht TOSCA und die CSAR keine Vorgaben Erweiterbarkeit des Containers Um die Anforderungen aus Kapitel zu erfüllen, verwendet der OpenTOSCA-Container die Softwareplattform und das Komponentenmodell von OSGi, dem Industrie Standard für Komponenten-basierte Anwendungen im Java- Umfeld. Die verschiedenen Komponenten werden als OSGi Bundles in der OSGi Plattform ausgeführt und bieten ihre Funktionalität als Dienst für andere Komponenten an. Zwei Vorteile von OSGi sind dabei (1) das dynamische Hinzufügen und Entfernen von Diensten zur Laufzeit und (2) das Management der Abhängigkeiten verschiedener Bundles, sowie diese zu konfigurieren und zu binden. Der Container ist komplett durch OSGi realisiert und die gesamte Funktionalität durch OSGi Bundles implementiert. Somit ist es möglich, den Container schnell und einfach zu erweitern, was für den OpenTOSCA Architekturansatz von zentraler Bedeutung ist, da sehr viel Logik in Plugins ausgelagert wird. Schnittstelle für Plan Engine und Implementation Artifact Engine Plugins Sowohl Pläne als auch Implementation Artifacts erlauben es dem Modellierer verschiedene Sprachen und Formate (gemeinsam im Folgenden Typ genannt) in das TOSCA-Lösungspaket zu integrieren. Pläne können in verschiedenen Workflow Sprachen definiert sein, beispielsweise BPEL oder BPMN. Gleiches gilt für Implementation Artifacts, also die Implementierungen von Management Operationen, die beispielsweise in Java, Perl, PHP,.Net etc. implementiert sein können. Diese verschiedenen Optionen sollten selbstverständlich nicht in den eigentlichen Kern des Containers hineingezogen werden, was Abhängigkeiten schaffen und die Erweiterbarkeit erschweren würde. Aus diesem Grund wird bei OpenTOSCA typspezifische Logik durch Plugins integriert, welche, wie alle anderen Container Komponenten auch, als OSGi-Bundles realisiert werden. Konzeptionell implementieren wir damit das sogenannte SOA-Dreieck ( publish, find, bind ), wie in Abbildung 8 am Beispiel der Plan Engine Plugins dargestellt. Ein Plan Engine Plugin, welches das entsprechende Interface implementiert, registriert sich beim OSGi Framework und teilt diesem mit, welche Dienste es anbietet ( publish -Phase). Die Plan Engine erhält entsprechende Anforderungen des Containers, um bestimmte Pläne zu deployen. Daraufhin sucht die generische Plan Engine nach einem passenden Plugin für die Verarbeitung eines bestimmten Plan-Typs ( find -Phase). Die Plan Engine stellt nun, mithilfe des OSGi 26

28 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Frameworks, eine Verbindung mit dem jeweiligen Plugin her und tauscht die nötigen Informationen aus, um den entsprechenden Plan zu deployen ( bind -Phase). Die Verarbeitung von Implementation Artefakten ist analog dazu gelöst und wird deshalb hier nicht nochmals explizit erklärt. OSGi Framework <<ServiceDiscovery>> (2) find (1) publish Plan Engine <<ServiceRequestor>> (3) bind Engine Plan Plugin <<ServiceProvier>> Abbildung 8: Umsetzung des SOA-Dreiecks in der Plan Engine Container Plugins für Container Capabilities Zu den beiden bereits erwähnten Schnittstellen ist es jederzeit möglich, weitere OSGi Bundles für neue Container- Funktionalitäten zu installieren bzw. existierende Komponenten zu ersetzen. Falls Management Operationen eine dieser Funktionalität benötigen, können die Bundles diese als Container-Capability beim Container registrieren und zur Verfügung stellen. 5.2 Grobdesign Basierend auf der in Kapitel 5.1 definierten Architektur wurden die in Abbildung 9 dargestellte OSGi Packages definiert, insbesondere deren Abhängigkeiten untereinander. Das Control-Package empfängt Befehle der ContainerAPI und orchestriert die OSGi-Dienste, welche den Container bilden. Die TOSCAEngine ist für die Bearbeitung des TOSCA Service Templates verantwortlich, beispielsweise das Auflösen von Imports und Ähnlichem. Auf der rechten Seite von Abbildung 9 ist die PortabilityAPI dargestellt, sowie die verschiedenen Implementation Artifact und Plan Plugins, welche mit Laufzeitumgebungen außerhalb des Containers kommunizieren. Die Core-Packages verwalten die verschiedenen Arten von Daten und deren Modelle. Außerdem wird hier der Fortschritt des Deployments persistiert. 27

29 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 9: OpenTOSCA-Container Design der OSGi Packages Datenspeicher OpenTOSCA verwendet eine Reihe von Datenspeichern, um verschiedene Klassen von Informationen abzulegen. Diese sind durch die Core Functionalities gekapselt und werden durch diese den anderen Komponenten des Containers angeboten. Im Folgenden diskutieren wir, welche Informationen in den jeweiligen Datenspeichern abgelegt werden. Dateien Alle Dateien, die in einem TOSCA-Lösungspaket enthalten sind, werden unabhängig von ihrem Typ persistent abgespeichert. Diese können zu einem späteren Zeitpunkt über die sogenannte FileAPI mithilfe ihres relativen Pfads im TOSCA-Lösungspaket wieder abgerufen werden. Dieser Datenspeicher kann auf verschiedene Arten realisiert werden, muss jedoch transparent für die darüber liegenden Management Pläne sein. Im aktuellen Design werden die Dateien auf dem lokalen Dateisystem des Servers gespeichert, welcher den OpenTOSCA-Container ausführt. Somit ist es möglich, auf die Dateien einfach mit ihrem relativen Pfad zuzugreifen. Zusätzlich können Referenzen auf diese Dateien auch über die ModelAPI abgerufen werden. Die Verwendung des lokalen Dateisystems bringt für die aktuelle Version die Einschränkung mit sich, dass alle Komponenten, die Zugriff auf die Dateien brauchen, auf dem gleichen Server laufen müssen wie der Container selbst (z. B. Management Operationen, welche durch Implementation Artefakte implementiert sind oder Pläne selbst). Model In der Modell Datenbank wird das konsolidierte, normalisierte und validierte TOSCA Modell des kompletten TOSCA Service Templates gespeichert. Dieses Modell wird benötigt, um beispielsweise den verschiedenen Komponenten Zugriff auf die Topologie und die Pläne zu ermöglichen. Der Einsatz eines Object Relational Mappers (ORM) bietet sich an, um die Java Objekte, welche das Modell repräsentieren, in die Datenbank zu schreiben oder zu lesen. 28

30 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Instanz Der Instanzdaten-Datenspeicher wird über die PortabilityAPI bereitgestellt und soll hauptsächlich von den Plänen verwendet werden. Sie verwaltet die Dienstinstanzen, die darin enthaltenen Nodes und Relationen sowie deren ID, Properties und Status. Für eine virtuelle Maschine bei Amazon EC2 könnte hier, in Abhängigkeit von den auf dem Node Type definieren Properties, beispielsweise IP Adresse, Passwort und Ähnliches gespeichert werden. Endpunkte Wenn ein Implementation Artefakt von dem entsprechenden Plugin installiert wird, muss der Container den Endpunkt, unter dem es seine Funktionalität zur Verfügung stellt, speichern. Bei Web Services, welche über eine WSDL beschrieben werden, werden PortType, Operation und eine URL gespeichert, über die diese Operation aufgerufen wird. Gleiches gilt für APIs, welche der Container anbietet, die also nicht durch Implementation Artifacts bereitgestellt werden, wie beispielsweise die PortabilityAPIs. Die hier gespeicherten Informationen werden beim Deployment der Pläne zum Binden der Dienste benötigt, wie in Kapitel 5.3 im Detail beschrieben. Plan Metadaten Auch für Management Pläne müssen Informationen persistiert werden, genauso wie für die Endpunkte. Wenn ein Plan Engine Plugin einen Management Plan auf der entsprechenden Workflow Maschine installiert hat, speichert er ab, welcher Plan wo deployed wurde und unter welchem Endpunkt er aufgerufen bzw. instanziiert werden kann. Aktuell werden die Informationen nicht genutzt, in Zukunft soll es jedoch möglich sein, Management Pläne direkt von der Container Benutzeroberfläche starten zu können. 5.3 Entwurf, Feindesign und Implementierung In diesem Kapitel gehen wir detailliert auf die Umsetzung der Architektur (Kapitel 5.1) und des Grobdesigns (Kapitel 5.2) des Containers ein und verdeutlichen die Schnittstellen und Arbeitsweise Arbeitsweise des Containers Im Folgenden beschreiben wir anhand von sechs Schritten die Funktionsweise des Containers bezüglich des Deployments eines Dienstes und dessen Instanziierung anhand der Architektur-Übersichtsgrafik, welche die verschiedenen OSGi-Komponenten beinhaltet. Jede weiße Box entspricht einem OSGi-Bundle, meistens sogar zwei Bundles, weil Interface und Implementierung des Dienstes separat gehalten werden, um Implementierungen flexibel austauschen zu können. Alle anderen Boxen, beispielsweise Core und Engines, dienen nur der Gruppierung und Zuordnung der Bundles zu einem bestimmten Teil der Architektur. Relationen, über welche im jeweiligen Schritt kommuniziert wird, sind in der jeweiligen Abbildung in Rot hervorgehoben. Schritt 1: Import Über die Benutzeroberfläche des Containers wird ein TOSCA-Lösungspaket importiert und an den Container weitergegeben. Auch wenn ein anderes System oder Client als die Benutzeroberfläche verwendet wird, beispielsweise ein Marktplatz oder ein Modellierungstool, wird dieses immer integriert, indem ein TOSCA-Lösungspaket über die ContainerAPI an den Container gesendet wird. 29

31 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 10: OpenTOSCA-Container Kontrollfluss von Schritt 1 Schritt 2: Entpacken, Analysieren und Auflösen Das TOSCA-Lösungspaket wird an die Core-Komponente geschickt, welche dieses entpackt und im Dateisystem ablegt. Daraufhin werden im nächsten Schritt die Inhalte analysiert. In allen hier definierten Schritten speichert Control den aktuellen Zustand bzw. Fortschritt des Service Template Deployments mithilfe des Deployment Trackers. Abbildung 11: OpenTOSCA-Container Kontrollfluss von Schritt 2 30

32 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Schritt 3: Verarbeitung der TOSCA Service Definition Eine spezielle Datei mit Metadaten über das Lösungspaket verweist auf die Wurzel TOSCA Service Definition, welche zuerst verarbeitet werden muss und ggf. weitere Service Definitions importiert. Die TOSCA Service Definitionen werden in ihr Java Modell transformiert und die Imports aufgelöst. Diese Service Definition wird in der Model Datenbank gespeichert. Abbildung 12: OpenTOSCA-Container Kontrollfluss von Schritt 3 Schritt 4: Implementation Artifacts deployen Control holt nun alle Node Templates von Core und ruft die Implementation Artifact Engine (IAEngine) auf, um diese zu deployen. Die IAEngine wertet die Required Container Features und den Typ des Implementation Artifacts aus und ruft damit das entsprechende Plugin auf. Diese Plugins holen sich die zum Implementation Artifact gehörenden Dateien und sind für deren Deployment verantwortlich. Dies kann zum Beispiel realisiert werden, indem das Plugin für WAR-Dateien einen Apache Tomcat kennt und das Implementation Artifact auf diesem deployed. 31

33 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 13: OpenTOSCA-Container Kontrollfluss von Schritt 4 Schritt 5: Pläne binden und deployen In diesem Schritt holt sich Control die im Service Template definierten Pläne und ruft mit diesen die Plan Engine auf. Diese holt die dazugehörigen Dateien über die FileAPI und leitet die Anfrage an das entsprechende Plugin weiter. Dieses Plugin muss die abstrakten Aufrufe von Diensten in den Workflows an die entsprechenden Endpunkte binden. In der aktuellen Version von OpenTOSCA ist dies ausschließlich der Endpunkt des Service Invokers über welchen alle anderen Aufrufe von Operationen laufen. In früheren Versionen musste dies für jeden Operationsaufruf der verschiedenen Node Types durchgeführt werden. Das Binden der Pläne an die konkreten Endpunkte wird realisiert indem das Plugin den Workflow analysiert und die abstrakten Dienstaufrufe an den entsprechenden konkreten Endpunkt aus der Endpunkt Datenbank bindet. Da dieser Prozess abhängig von der genutzten Sprache, Format und Ziel-Workflow-Engine des Planes ist muss dies im entsprechenden Plugin realisiert werden (z.b. in dem aktuell implementierten Plugin für BPEL Workflows auf dem WSO2 Business Process Server). Anschließend wird der Workflow auf einer, dem Typ entsprechenden Workflow Engine, deployed. Die deployten Pläne werden nun wiederum in der Datenbank für Pläne abgespeichert. Anschließend ist der Import des TOSCA-Lösungspakets im Container abgeschlossen und neue Instanzen können erstellt werden, wie im nächsten Schritt beschrieben. 32

34 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Abbildung 14: OpenTOSCA-Container Kontrollfluss von Schritt 5 Schritt 6: Ausführung Build Plan Dieser Schritt wird angestoßen, wenn eine neue Instanz des in Schritt 1-5 importierten Cloud Dienstes gestartet werden soll. Dazu muss der Build Plan aufgerufen werden, ein spezieller Management Plan, welcher die Logik zum Instanziieren einer neuen Dienstinstanz enthält. Dies wird durch das Senden einer Nachricht an den Web Service Endpunkt des Plans angestoßen. Während seiner Laufzeit ruft der Build Plan Operationen über den Service Invoker auf und greift über die Plan Portability API auf die Instanzdaten zu, welche vom Container verwaltet werden. Das Senden einer Nachricht zur Instanziierung des Build Plans ist die technische Realisierung welche jedoch nicht von nicht-technisch versierten Benutzer verwendet werden kann. Um die deployten TOSCA-Lösungspakete Nutzer zur Instanziierung zur Verfügung zu stellen wurde das Self-Service Portal Vinothek entwickelt welches in Abbildung 15 dargestellt ist. Dieses stellt dem Nutzer im ersten Schritt eine Liste aller deployten TOSCA-Lösungspakete zur Verfügung. Im zweiten Schritt wird für jedes TOSCA-Lösungspaket eine Detailansicht (dargestellt in Abbildung 15) bereitgestellt, welche weitergehende Informationen zum darin enthaltenen Dienst enthält. Durch einen Klick auf den entsprechenden Button kann der Benutzer die Instanziierung des gewählten TOSCA-Lösungspaketes anstoßen. Im Hintergrund wird dazu eine im TOSCA-Lösungspaket vordefinierte Nachricht an den Build Plan geschickt, dieser ausgeführt und am Ende die Adresse der instanziierten Anwendung dem Nutzer wieder in der Vinothek angeboten, ohne dass dieser etwas von den technischen Details im Hintergrund mitbekommt. Um dies zu ermöglichen muss das TOSCA-Lösungspaket um zusätzliche Informationen wie Icon, Abbildung und beschreibender Text erweitert werden. Diese Erweiterung wird von Winery, dem im Rahmen von CloudCycle entwickelten Modellierungswerkzeug unterstützt. 33