gms | German Medical Science

Einleitung und Fragestellung: In großen epidemiologischen Studien, wie z.B. LIFE an der Universität Leipzig, wird häufig ein Anteil an Spezialsoftware benötigt. Solche Software tangiert typischerweise Bereiche wie die Verwaltung von Identifikationsdaten, das Ambulanzmanagement, Datenerhebungen am Probanden, Bioprobenverfolgung, Biobankverwaltung, Datenintegration und Datenbereitstellung. Oftmals werden diese Anwendungen während der Laufzeit einer Studie entwickelt und ständig den aktuellen Anforderungen angepasst. Gleichzeitig werden hohe Anforderungen an den Betrieb dieser Software-Anwendungen gestellt. Im Falle eines Ausfalls einer kritischen Anwendung ist der reguläre Ambulanzbetrieb gestört, so dass die Ambulanzprozesse sowie die Datenerhebung negativ beeinflusst werden.

Ein wesentlicher Faktor für den Betrieb von Spezialsoftware ist die Infrastruktur, auf der die Anwendungen ausgebracht und installiert (Deployment) werden. In LIFE werden zwei VMWare ESX-Server eingesetzt, die ca. 50 virtuelle Maschinen beherbergen. Das Einrichten einer neuen virtuellen Maschine erfordert einen erheblichen manuellen Aufwand, da dazu Schritte in verschiedenen Softwareprodukten durchzuführen sind. Dazu zählt nicht nur das Anlegen der virtuellen Maschine im VMware System, sondern beispielsweise auch die Vergabe von IP-Adressen und DNS-Einträgen. Damit werden nicht nur personelle Ressourcen gebunden. Vielmehr steht dieses Know-how nur den Administratoren zur Verfügung, die sich mit der Materie beschäftigen. Dies führt dazu, dass Softwareentwickler nicht in der Lage sind, ihre Anwendungen selbstständig zu installieren.

Material und Methoden: In LIFE wird das beschriebene Problem seit ca. 2 Jahren mit dem Konfigurationsmanagementsystem Puppet (http://puppetlabs.com/) begegnet. Mit Hilfe von Puppet ist es möglich, eine neue virtuelle Maschine automatisiert mit einem definierten Software- und Konfigurationsstand zu installieren und damit bereitzustellen. Die Installation und Konfiguration eines Servers dauert in Abhängigkeit von der auf ihm zu installierenden Software zwischen 30 und 40 Minuten. Im Anschluss werden die eigentlich benötigten Software-Applikationen installiert.

Typischerweise werden mehrere Software-Applikationen auf einem virtuellen Server installiert. Damit ist nicht nur eine weitere Erhöhung der Fertigstellungszeit verbunden. Vielmehr sind bei einem Ausfall der virtuellen Maschine alle auf dem Server installierten Applikationen betroffen. Dies gilt nicht nur im Fehlerfall, sondern auch, wenn eine neue Version einer Software-Applikation bereitgestellt wird. Die Installation und Ausbringung einer eigenen virtuellen Maschine je Software-Applikation ist auf Grund der limitierten technischen Ressourcen sowie der derzeit hohen Auslastung der zugrunde liegenden ESX-Server nicht durchführbar.

Wir haben begonnen, dieses Problem mit der Nutzung einer Cloud-basierten Diensteinfrastruktur zu adressieren. Typicherweise werden im Cloud-Computing drei Service-Arten unterschieden: IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service) und SaaS (Software-as-a-Service). Das IaaS stellt eine Basis-Infrastruktur als Dienst bereit. Oftmals werden diese Dienste als virtuelle Maschinen realisiert. In vielen universitären Rechenzentren ist die Virtualisierung heutzutage Standard. Eine PaaS-Cloud abstrahiert von der Infrastrukturebene, in dem zusätzlich spezielle Software und Systemkomponenten zur Verfügung stehen, wie z.B. Datenbanken und Web-Server. Damit kann ein Softwareentwickler seine Anwendung ohne Installation weiterer benötigter Software ausbringen. SaaS ist die höchste Form eines Dienstes, in dem das Software-System selbst als Dienst agiert, unabhängig von der zugrundeliegenden Infrastruktur und Zusatzsoftware (Plattform).

Es gibt je Service-Art viele unterschiedliche Angebote und Produkte. Im Bereich der privaten PaaS-Lösungen sind vor allem Cloud Foundry von VMware (http://cloudfoundry.com/) und OpenShift von RedHat (https://www.openshift.com/) hervorzuheben. Diese beiden Produkte werden seit 2011 mit Unterstützung ihrer entsprechenden Mutterunternehmen entwickelt. Neben diesen beiden etablierten Lösungen befinden sich z.Z. weitere Projekte in Entwicklung. Dazu zählen Deis der Firma OpDemand (http://deis.io/) und zum anderen um Flynn (https://flynn.io/).

Wir haben uns entschieden einen ersten Prototypen mit Hilfe von Deis umzusetzen. Dieser Prototyp besteht z.Z. aus einer Entwicklungs- und einer Testumgebung. Eine Produktivumgebung ist für einen späteren Zeitpunkt geplant. Für den Betrieb einer Deis-PaaS sind mehrere virtuelle Maschinen notwendig. Zum einen wird ein Controller-Server benötig, welcher die verschiedenen Umgebungen (Dev, Test, Prod) verwaltet. Dieser Server stellt eine API zur Verfügung, über die der Entwickler seine Applikationen installieren kann. Des Weiteren werden pro Umgebung jeweils eine Proxy-Maschine und eine oder mehrere Anwendungsknoten benötigt. Dabei leiten die Proxy Maschinen HTTP-Requests zu den einzelnen Webanwendungen weiter. Für den Entwickler und natürlich auch die Benutzer ist es damit unerheblich auf welchem Anwendungsknoten eine Applikation läuft.

Ergebnisse: Wir waren bisher in der Lage, vier kleinere Anwendungen in die Cloud zu portieren. Dabei handelt es sich um zwei Services, die sich mit der Autorisierung und dem Benutzermanagement beschäftigen, einer Datenbank-Export-Anwendung und eines Browsers zur Exploration von REST-Services.

Unsere umfangreicheren Anwendungen, die sich beispielsweise mit dem Bioprobenmanagement, der Datenerfassung und dem Forschungsdatenmanagement befassen, mü sen noch portiert werden. Diese Anwendungen laufen z.Z. auf Glassfish v3 Applikationsservern.

Grundsätzlich sind Java-Webanwendungen, die in Applikationsservern laufen auch in PaaS-Clouds lauffähig. Allerdings stellt in diesem Fall die Cloud Dienste wie Service Discovery, Clustering und Backend-Dienste wie Datenbanken und Message Queues zur Verfügung. Diese Bereitstellung unterscheidet sich von der in Applikationsservern. Damit ist eine Anpassung der Anwendungen unumgänglich.

Eine Portierung werden wir im Einzelfall vorsehen, falls unsere Erfahrungen im Umgang mit den neueren Applikationen auf der produktiven Cloud erfolgreich sind.

Diskussion: Wir konnten mit der Einführung einer privaten PaaS-Cloud zu Entwicklungs- und Testzwecken bereits viele der gebotenen Vorteile nutzen. Es ist nun beispielsweise einfach möglich, mehrere Instanzen einer Anwendung zu deployen. Damit kann sich jeder Entwickler und automatische Prozesse wie der Continuous-Integration-Server eine eigene Umgebung schaffen.

Des Weiteren ist der Ressourcenbedarf einer einzelnen Anwendung stark gesunken. Anstatt einen neue virtuelle Maschine inkl. Applikationsserver aufzusetzen läuft nun nur ein weiterer Prozess in einem Anwendungsknoten.

Uns ist allerdings auch bewusst, dass wir weitere Erfahrungen mit solch einer Cloud sammeln müssen und der Portierungsaufwand bestehender Anwendungen nicht vernachlässigt werden kann. Weiterhin stellt letztendlich auch der Betrieb einer Cloud weitreichende Anforderungen an das IT-Personal.

Der Nutzen einer Cloud steigt gegenüber dem operativen Aufwand natürlich mit ihrer Größe. Daher sollte so ein Infrastrukturprojekt idealerweise von größeren Forschungsverbünden umgesetzt werden.