Cloud Extender - Flexible Ressourcenbuchung

Transkript

1 Cloud Extender - Flexible Ressourcenbuchung

2 Die Herausforderung Immer mehr Unternehmen entscheiden sich dafür Ressourcen dynamisch aus der Cloud zu buchen. Gemeint ist damit in vielen Fällen die sogenannte Public Cloud, also eine öffentlich zugängliche Rechner-Wolke. Typischerweise kann dabei innerhalb von wenigen Minuten die erforderliche Rechnerkapazität je nach Bedarf gebucht und genutzt werden. Gezahlt wird nur für die Ressourcen, die tatsächlich in Anspruch genommen werden. Alternativ hierzu können aber auch die benötigten Rechnerressourcen aus einer Private Cloud oder auch einer Enterprise bzw. Corporate Cloud kommen. Im Gegensatz zur öffentlichen Cloud bieten die privaten Angebote mehr Sicherheit, insbesondere in Hinblick auf Datenschutz und Kontrollmöglichkeiten. Das geht allerdings zu Lasten der Flexibilität und oft auch der Kosten. Die Angebote in der Private Cloud sind zumeist nicht innerhalb von Minuten buchbar und auch nicht für eine nur temporäre Nutzung ausgelegt. Je nach Sicherheitsbedürfnis und Anwendungsfall muss sich ein Unternehmen für das passende Cloud-Angebot entscheiden. In vielen Fällen wird sich eine hybrid ausgelegte Cloud-Strategie anbieten, bei der unterschiedliche Cloud-Angebote bedarfsgerecht kombiniert werden. Um eine optimale, aufgabenspezifische Ressourcensteuerung zu ermöglichen, wird eine intelligente und weitgehend automatisierte Steuerungsinstanz benötigt. Corporate Cloud Sicherheit Private Cloud Hybrid Cloud Public Cloud Flexibilität Abbildung 1: Cloud-Typologie Unsere Lösung Der Cloud Extender von StoneOne stellt eine funktionale Erweiterung der Web Service Factory zur Expansion in eine heterogene Cloud-Umgebung dar. Je Server laufen eine oder mehrere Enterprise Service Bus (ESB) Instanzen. Diese Instanzen (typischerweise eine VM) werden jeweils von einem Bus Controller intern administriert. Über diesen Controller sind die verschiedenen Instanzen miteinander verbunden jede Instanz enthält einen Bus, gegebenenfalls mit einer jeweils unterschiedlichen Auswahl an Komponenten. In diesem verteilten System ist ein Controller jeweils der Master Controller. Dieser Master Controller stellt auf Anforderung über den Cloud Extender die Verbindung zu einer ausgewählten Cloud her. Generell bietet der Cloud Extender eine Reihe von Funktionalitäten, wie die Verbindung zu unterschiedlichen Clouds herzustellen, dort Ressourcen zu buchen, geeignete ESB-Instanzen für die jeweilige Ressource zu deployen und dann diese Instanz mit dem bereits aktiven System zu verbinden.

3 In diesem Kontext kommen auch weitere Komponenten der Web Service Factory zum Einsatz: Bus Controller, der Master Controller, Billing&Tracking und gegebenenfalls auch Payment. Technische Abläufe Eine ESB Applikation besteht aus einer Reihe von Komponenten, die technische Aufgabenpakete nach einem definierten Workflow verarbeiten. Für jeden Verarbeitungsschritt werden diese Pakete in eine entsprechende Queue gestellt und nacheinander von der jeweiligen Komponente verarbeitet. Dabei ist es prinzipiell egal, wo die Komponenten lokalisiert sind. Das bedeutet, dass sich eine logische Applikation über unterschiedliche ESB Instanzen verteilen kann. Ebenso können sich die ESB Instanzen auf unterschiedliche Provider verteilen. Das ermöglicht eine dynamische Verteilung und Skalierung. Ein ESB Controller überwacht die Queues und Durchlaufzeiten seiner ESB Instanz und kommuniziert mit einem ESB Master Controller. Der ESB Master Controller erhält bei Überschreiten eines eingestellten Thresholds den Alert eines ESB Controllers. Der Master Controller weiß, ob es eine oder mehrere ESB Instanzen mit adäquater Konfiguration gibt, und fordert sie zur Mitarbeit auf. Abbildung 2: Auslastungsübersicht / Trends

4 Dabei handelt es sich grundsätzlich um ein Pull-Verfahren, bei dem die angefragte Instanz entscheidet, ob sie mitarbeiten kann/will oder nicht. Damit wird abgesichert, dass auch bei anbieterübergreifenden Prozessen ein Konsens (automatisch) hergestellt wird. Mastercontroller Controller Controller de.stoneone.eib.mastercontroller Heartbeat Reply Meldet sich beim Mastercontroller an de.stoneone.eib.controller Hilfe (Queue) Lastgrenze erreicht Multicast (IP, Port, Queue) Pull (Queue) While(Queue > 0) Workitem Heartbeat Request Heartbeat Reply shutdown Queue leeren shutdown Abbildung 3: Ablauf einer Verteilung über zwei ESB instanzen Wie bereits angemerkt, können die Instanzen auf unterschiedliche Anbieter verteilt sein. Derzeit gibt es allerdings keinen einheitlichen Standard für die notwendigen Schnittstellen zur Ressourcenbuchung. Der Cloud Extender liefert die spezifische Schnittstelle zum jeweiligen Cloud-Anbieter. Im Kontext des Master Controllers bucht dieser je nach Thresholds und eingestellter Policy eine oder mehrere neue virtuelle Maschinen, die beim Abarbeiten der Aufgabenpakete helfen. Die Unterstützung für die Cloud erfolgt in mehreren Stufen: Einbinden eines ESB, der auf einer anderen Maschine läuft Buchen/Hochfahren einer Maschine, die einen vorkonfigurierten ESB bereitstellt Buchen/Hochfahren einer generischen Maschine mit Installation des ESB Entsprechend der Nutzung zusätzlicher Ressourcen kommt es bei unzureichender Auslastung von gebuchten Ressourcen entsprechend zum Abschalten von Maschinen bzw. Instanzen.

5 Die Steuerung erfolgt über definierte Kriterien (Policies), die z.b. bei Anwendungen mit rasch wachsenden Demo Accounts dafür sorgen, dass deren Antwortzeitverhalten immer bestmöglich bleibt. Das Anfordern weiterer Maschinen wird also sowohl durch technische Gegebenheiten (z.b. garantierte Antwortzeiten) als auch durch wirtschaftliche Gegebenheiten (z.b. der erzielte Gewinn aus dem rechtzeitigen Abarbeiten zusätzlicher Requests übersteigt die Kosten für die Cloud) bestimmt. Der ESB Controller überwacht die Größe der Queues, die Durchlaufzeiten bezüglich einzelner Komponenten und gegebenenfalls weitere Parameter. Der ESB Master Controller steuert anhand der Policies die Expansion des ESB in die hybride Public oder Private Cloud. Sinkt der Bedarf, verkleinert der Cloud Extender das System auch wieder durch Beendigung der Nutzung von Ressourcen. Der Begriff Cloud schließt hier sowohl Public Clouds wie z.b. Amazon EC2 als auch Private Clouds sowie IaaS-Lösungen auf Basis von VMware, VirtualBox usw. ein. Durch die Flexibilität der Policies lassen sich diese jederzeit schnell den Marktgegebenheiten anpassen und so kann der jeweils wirtschaftlichste Betriebsmodus gefahren werden. Abbildung 4: Policies für Anwendungen Policies erlauben dem Cloud Extender im Master Controller, die Wahl zwischen mehreren definierten Cloud Providern zu treffen. Dazu werden pro Provider und pro angebotener Maschinenklasse des Providers entsprechende Profil-Informationen erfasst, die in den Policy-Definitionen entsprechend referenziert werden können. Sowohl Leistungsfähigkeit wie auch Kosten sowie räumliche Nähe oder auch ökologische Parameter wie Energieverbrauch, Temperatur etc. gehören zu den möglichen Parametern eines Profils.

6 Wirtschaftliche Parameter Mögliche Parameter der wirtschaftlichen Steuerung sind: Verfügbares Basis-Budget pro Zeiteinheit (z.b. 500 pro Monat) Zusätzlich nutzbare Einnahmen (über Payment eingezogene Transaktionen) mit einem Prozentsatz zur Budget-Querfinanzierung (z.b. 5% der Einnahmen des Monats der Anwendung CorDesk werden dem laufenden Budget hinzugefügt) Maximal-Budget pro Monat (obere Grenze auch für Querfinanzierung) Randparameter von Ressourcenbuchungen (z.b. Daten nur in Deutschland) Einfache Ausgaben-Policy, wie z.b. - Mindestreserve für verbliebene Tage des Monats pro Tag - Maximalbetrag pro Tag Technische Parameter Parameter für eine technische Steuerung: Maximale Laufzeit der Transaktion X der Anwendung Y: ZZZ millisec (Laufzeit bedeutet hier von der Einsortierung in eine Queue bis zur erfolgten Verarbeitung) Maximale mittlere Laufzeit der Transaktion X der Anwendung Y Cloud-Provider Management Verwaltung der Einstellungen/Angebote pro Provider wie Rechenzentrum (RZ), Cloud-Anbieter: Kosten pro Ressource je nach Granularität: - Anzahl Core - Hauptspeicher - Plattenplatz - Sonstiges Laufzeit einer Buchung (Minuten bis Ressource verfügbar) Einstellungen im Budget erzeugen jeweils Audit-Einträge. Die Eckdaten je verfügbarem Ressourcenanbieter (RZ, Cloud, etc.) sind einsehbar und einstellbar.

7 Reporting Mit Hilfe von übersichtlichen Dashboards wird angezeigt, wie sich die Nutzung von Cloud-Ressourcen über einen Zeitraum zwischen den verschiedenen Anbietern verteilt. Pro Cloud bzw. Ressource wird außerdem der Umfang der Nutzung und der resultierende Preis angezeigt. Abbildung 5: Reporting

8 StoneOne AG Keithstrasse Berlin Fon: +49 (0) Fax: +49 (0) info@stoneone.de