Erweiterung der D Grid Basis für die kommerzielle Nutzung

Transkript

1 Erweiterung der D Grid Basis für die kommerzielle Nutzung Bericht zur Kundenakquise Koordination Andreas Eberhart (andreas.eberhart@fluidops.com) Datum 22. März 2012 Version Status Referenz Final dortmund.de/cms/de/it/projekte/d Grid_IaaS/D Grid_IaaS_Bericht_zur_Kundenakquise.pdf

2 Autoren: Stefan Freitag (Technische Universität Dortmund) Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 01IS10019B gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. Seite 2

3 Inhaltsverzeichnis Vorbemerkung... 4 Voraussetzungen... 4 Bereitstellung virtueller Appliances... 4 Zugriff auf die virtuellen Appliances... 4 Abrechnung... 5 Status... 5 Aktualisierter Status... 6 Seite 3

4 Vorbemerkung Wie in der Vorhabenbeschreibung 1 angegeben soll während der Phasen des Arbeitspakets 3 und Arbeitspakets 4 des Projekts der Kontakt zu potentiellen Kunden aus dem wissenschaftlichen und kommerziellen Umfeld etabliert werden. Diese Kunden sollen zum einen als Tester in einer späteren Beta Phase und zum anderen als Referenzkunden dienen. Ein möglicher Kundenkreis besteht in den Physik Fachbereichen der Universitätsallianz Metropole Ruhr 2, die über die EC2 Schnittstelle einen vereinfachten Zugriff auf die Ressourcen des D Grid erhalten können. Des Weiteren sind Kunden aus anderen D Grid Projekten denkbar. Im Gegensatz zu den bisherigen D Grid Ressourcen, zu denen lediglich so genannte Batch Jobs geschickt werden können, erlauben Cloud Ressourcen den Betrieb von Community Diensten. Voraussetzungen Bevor Testkandidaten bzw. spätere Kunden auf die prototypisch an der TU Dortmund implementierte D Grid Cloud Ressource zu greifen können, müssen eine Reihe von Vorbedingungen erfüllt seien. Diese sind nachfolgend kurz erläutert. Bereitstellung virtueller Appliances Um Kunden den Einstieg in die Nutzung einer D Grid Cloud Ressource zu erleichtern, wurden im Rahmen des Projektes verschiedene virtuelle Maschinen inklusive einer rudimentären Betriebssystem Installation vorbereitet: CentOS 5.4 Scientific Linux 5.7 Scientific Linux 6.0 Debian Aus dieser Liste können sich Kunden eine virtuelle Maschine aussuchen und starten. Danach haben sie die Möglichkeit sich mit der Maschine zu verbinden und weitere Software zu installieren und entsprechend auch zu konfigurieren. Die während der Erzeugung der virtuellen Maschinen durchgeführten Einzelschritte wurden dokumentiert und werden Interessierten gerne zur Verfügung gestellt. Mit diesem Schritt sollen Kunden in die Lage versetzt werden, zügig eigene virtuelle Maschinen installieren zu können. Des Weiteren soll diese Offenheit das Vertrauensverhältnis zwischen dem Nutzer und dem Ressourcenanbieter fördern. Zugriff auf die virtuellen Appliances Die Kunden müssen neben dem Starten und Stoppen ihrer virtuellen Appliances ebenso über Möglichkeiten zu verfügen, sich mit diesen Appliances über das Netzwerk zu verbinden. Die Verbindung selbst kann hierbei auf unterschiedliche Arten und Weisen erfolgen, wobei zwei von ihnen aufgrund ihres hohen Verbreitungsgrades von besonderem Interesse sind. Verbindung per ssh Klient 1 dortmund.de/cms/de/it/projekte/d Grid_IaaS/Vorhabenbeschreibung.pdf 2 Seite 4

5 Die Verbindung per ssh (secure shell) stellt eine gängige Variante für die Anmeldung auf entfernten Ressourcen dar. Hierfür wird innerhalb der virtuellen Appliance ein ssh Server benötigt, welcher im Falle von Linux basierten Appliances als Teil des Betriebssystems installierbar ist. Dieser Server muss beim Hochfahren der Appliance automatisch gestartet werden und Verbindungen von außen erlauben. Die Anmeldung am ssh Server kann mittels eines Nutzername/ Passwort Mechanismus oder unter Einsatz eines X.509 Zertifikats erfolgen. Weiterhin muss der Kunde darüber informiert sein, auf welchem Port der ssh Server auf eingehende Verbindungen wartet. Verbindung per VNC/RDP Client Die Verbindung mittels VNC bietet neben dem reinen ssh basierten Zugang zu einer Login Konsole die Möglichkeit des Zugriffs auf eine graphische Benutzeroberfläche. Dies bedeutet einen höheren Komfort bei der Nutzung und scheint insbesondere für Appliances, die ein Microsoft Windows Betriebssystem nutzen, von besonderer Bedeutung. In letzteren steht kein ssh Server zur Verfügung. Ebenso wie beim ssh basierten Zugang müssen auch hier die virtuellen Appliances über einen entsprechenden Server verfügen, der beim Hochfahren der Appliance automatisch mitstartet. Abrechnung Mit dem Begriff des Cloud Computing einhergehend sind oft Begriffe wie Geschäftsmodell und pay per use genannt. Letzterem liegen zwei elementare Bestandteile zugrunde: 1. Feststellung des Verbrauchs 2. Erstellen der Abrechnung In diesem Projekt wurde zur Feststellung bzw. Meldung des Ressourcenverbrauchs eine Komponente entwickelt, die sich in den am RRZN entwickelten DGAS EE 3 integriert. Diese Komponente bestimmt nach Nutzern und virtuellen Appliances getrennt deren Verbrauch in Form von z.b. CPU Stunden. Ein Ressourcenbetreiber hat zudem über ein Feld in den administrativen Einstellungen des ecloudmanagers die Möglichkeit den Preis pro CPU Stunde anzupassen. Basierend auf beiden Größen, der in Anspruch genommenen CPU Stunden und dem vom Administrator festgelegten Betrag pro CPU Stunde, wäre dem Ressourcenbetreiber die Erstellung einer Rechnung gegenüber dem Kunden möglich. Status Es wurden während der Planungsphase des Projekts verschiedene Kundenkreise ausgemacht. Hierzu gehörten u.a. die Physik Fachbereiche der Universitätsallianz Metropole Ruhr. Des Weiteren haben Kollegen aus anderen D Grid Projekten wie etwa PTGrid ihr Interesse an der Nutzung einer Cloud Ressource gezeigt. Am 24. Oktober 2011 fand auf einer D Grid Beiratssitzung die Vorstellung des D Grid IaaS Projekts statt. Die zugehörige Folienpräsentation ist frei zugänglich und online unter dem Link iaas vorstellung abrufbar. 3 hannover.de/d grid_accounting.html Seite 5

6 Bis Anfang Oktober war es für Tester nicht möglich über das SelfService Portal des ecloudmanagers aus so genannten Templates virtuelle Maschinen bzw. Appliances zu erzeugen. Der Start dieser Appliances wurde Testern gegenüber zwar korrekt dargestellt, allerdings wurden die für eine Verbindung zur Appliance notwendigen Daten (z.b. die der virtuellen Appliance zugewiesene IP Adresse) nicht in dem SelfService Portal angezeigt. Da dieses Problem in der Kommunikation zwischen dem ecloudmanager und dessen XenServer Modul lag, betraf es nicht nur das SelfService Portal, sondern auch alle weitern beispielsweise über die ecloudmanager EC2 API zugreifenden Klienten wie das ElasticFox Plug In 4 für den Webbrowser Mozilla Firefox. Daher war es Testern unmöglich sich auf die Appliances zu verbinden. Durch den Projektpartner fluidops wurde Anfang Oktober ein neues Release des ecloudmanagers bereitgestellt, der die eben beschriebene Problematik löst. Die Nutzer des SelfService Portals sind nun in der Lage virtuelle Appliances zu starten und erhalten ebenso die notwendigen Verbindungsinformationen. Im Fall der VNC basierten Verbindung wird beispielsweise die IP Adresse der gestarteten Appliance im Portal dargestellt, wobei der zu verwendende Port auf den Wert 5900 festgelegt ist. Aktuell werden im D Grid für alle registrierten Ressourcen halbjährlich die in Anspruch genommenen CPU Stunden sowie auch die durch Nutzer belegte Speichermenge auf den sog. Storage Elements festgehalten. Es findet also lediglich eine Feststellung des Verbrauchs statt, jedoch keine Erstellung von Rechnungen. Dies wird unter anderem damit begründet, dass die Kunden nur sehr schlecht nachvollziehen können, ob sie auch wirklich die in Rechnung gestellte Leistung erhalten haben. Der Aspekt des Accounting bzw. der Verbrauchserfassung ist im D Grid IaaS Projekt implementiert und kann entsprechend getestet werden. Zusammenfassend sind seit Anfang Oktober somit alle im Abschnitt Voraussetzungen aufgeführten Punkte erfüllt. Aktualisierter Status Dieser Abschnitt beschreibt lediglich die im Vergleich zum ersten Bericht vorhandenen Änderungen. Aufgrund von Verbindungen zum Projekt Initiative for Globus in Europe (IGE, welches durch das 7. Europäische Forschungsrahmenprogramm gefördert wird, hat sich ein neuer möglicher Kundenkreis gezeigt. Das IGE Projekt selbst koordiniert grenzübergreifend innerhalb von Europa die nationalen Globus Aktivitäten und dient so als Sprachrohr zur Weitergabe europäischer Anforderungen an die Entwickler der Globus Alliance. Eine weitere Aufgabe des Projektes entspricht der Bereitstellung von Globus Software Paketen, die z.b. hinsichtlich des Datenschutzes den europäischen Gegebenheiten angepasst sind. Für diese Software Pakete existiert innerhalb von IGE ein Zertifizierungsprozess, der auch die Installation sowie Funktionalitätstests der Client und Server Pakete vorsieht. Beides geschieht momentan noch lokal bei den einzelnen Projektpartnern, allerdings bietet sich eine Nutzung von D Grid IaaS an. 4 Seite 6

7 In Zusammenarbeit mit zwei IGE Projektpartnern (dem Leibniz Rechenzentrum der Bayerischen Akademie der Wissenschaften und der TU Dortmund) sind erste erfolgreiche Versuche unternommen worden, die Zertifizierung von Client Paketen innerhalb virtueller Maschinen auf der D Grid IaaS Ressource durchzuführen. Ebenso konnten Probleme bei der Zertifizierung der Server Komponenten festgestellt werden. Für diese ist die Frage nach der Bereitstellung von gültigen X.509 basierten Host Zertifikaten zu lösen. Weiterhin hat sich durch einen Kontakt zu dem C3Grid INAD Projekt ( inad/c3 inad) eine Nutzungsmöglichkeit der D Grid IaaS Ressource für Entwicklungszwecke gezeigt. In diesem Projekt wird aktuell ein Informationssystem, an das später Compute und Storage Anbieter Daten über die bei Ihnen verfügbaren Ressourcen übermitteln, entwickelt. Ein Teil dieser Entwicklung findet innerhalb einer virtuellen Maschine der D Grid IaaS Ressource statt. Diesen Ergebnissen stehen weiterhin offene Probleme gegenüber. Nach ersten Sondierungen Mitte 2011 ist es bislang nicht gelungen die ecloudmanager Middleware als neuen Middleware Typen in den D Grid GRRS zu integrieren. Nach einer Zusage des DGI2 zur Umsetzung der notwendigen Integrationsarbeiten (Durchführung durch das Forschungszentrum Jülich) aus dem Dezember 2011, gab es bisher keine Rückmeldung des Durchführenden zum Status der Umsetzung. So verlief im Februar 2012 eine explizite Nachfrage beim Leiter des DGI2 ergebnislos. Diese fehlende Registrierung erschwert es potentiellen Kunden die D Grid IaaS Cloud Ressource zu finden und als Teil des D Grid zu identifizieren. Seite 7