Thomas Nau & Janne Schulz 24. Juli 2018

bwCloud – Mehr als nur eine Cloud für tausende virtueller Maschinen

Das Geschäft mit "der Cloud" wächst nach wie vor ungebrochen stark. © Gorodenkoff / Fotolia.com — © Gorodenkoff / Fotolia.com

Kooperationen im IT-Bereich der Hochschulen und Universitäten in Baden-Württemberg haben eine lange Tradition. Die Anfänge, bis heute stets stark gefördert und unterstützt durch das Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg (MWK) [1], reichen hierbei mehrere Jahrzehnte zurück. Standen zu Beginn die gemeinsame Beschaffung, insbesondere von Software, sowie der enge Erfahrungsaustausch im Vordergrund, so entwickelten sich die Kooperationen, getragen durch den kontinuierlichen Ausbau des Landeshochschulnetzes BelWü [2], immer mehr zu einem verteilten Betriebsmodell. Die Verbindung der Hochschulstandorte mit Bandbreiten von bis zu 100 Gbit/s schuf eine der zentralen Voraussetzungen, um Hardware und betriebliches Know-how, jeweils auf spezifische Anforderungen bezogen, auf wenige Standorten zu konsolidieren und gleichzeitig allen anderen beispielsweise als Service zur Verfügung zu stellen.

Die zweite wesentliche Voraussetzung für die Entwicklung eines verteilten Betriebsmodells ist die Verfügbarkeit eines gemeinsamen und gleichzeitig verteilten Identitätsmanagements. Das auf Basis von Shibboleth [3] etablierte föderierte Identitätsmanagement bwIDM [4] belässt die Verantwortung für Autorisierung und Authentifizierung bei den jeweiligen Heimateinrichtungen. Gleichzeitig ermöglicht es aber den weit über 100.000 Nutzern die einfache Nutzung kooperativ erbrachter Dienste. Zu diesen zählen neben der bwCloud u. a. auch die HPC-Cluster oder Literaturdatenbanken. Darüber hinaus ist bwIDM auch an die deutschlandweite Authentifizierungs- und Autorisierungs-Infrastruktur des DFN (DFN-AAI) [5] angebunden.

Dieser Artikel fasst die Gründe für die Schaffung einer eigenen Cloud-Infrastruktur, deren Entstehungsgeschichte sowie die gemachten Erfahrungen aus der Sicht der Betreiber-Infrastruktur zusammen.

Motivation

Aktuelle Wachstumszahlen belegen, dass das Geschäft mit "der Cloud" nach wie vor ungebrochen stark wächst. Vermutlich denken die meisten hierbei in erster Linie an die Speicherung von Daten ("Storage-Cloud"), jedoch beziehen immer mehr Unternehmen heute schon ihre Rechner- und Serverinfrastruktur in virtueller Form von großen Anbietern wie Amazon oder Microsoft. Aber auch im privaten Umfeld erfreuen sich die Angebote der Cloud-Anbieter und -Hoster steigender Nachfrage, zu oft erfreulich günstigen Konditionen. Die Vorteile für die Nutzenden solcher Angebote liegen auf der Hand: die Systeme werden "per Knopfdruck" bereitgestellt und es entfällt die Notwendigkeit, sich um die darunter liegende Hardwareinfrastruktur, deren Vernetzung und deren Anbindung an Speichersysteme zu kümmern. Sobald der Bedarf nach den virtuellen Maschinen nicht mehr besteht, können diese ebenso schnell wieder abgeschaltet werden.

Dennoch lohnt sich die Frage für Rechenzentren und Hardwarebetreiber, ob der Betrieb einer eigenen Cloud-Infrastruktur, besonders bei spezifischen oder stark heterogenen Anforderungen und Anwendungsszenarien, durchaus eine bessere und effizientere Lösung darstellen kann als die Nutzung entsprechender Dienste von Dritten. Diese Aussage gilt durchaus selbst dann, wenn die in Deutschland häufig gestellte Frage nach der Lokalität der Daten – hinsichtlich des Datenschutzes und der Vertraulichkeit – ausgeklammert wird.

Unserer Erfahrung nach überwiegen in komplexen Umgebungen, wie etwa an Forschungs- und Lehreinrichtungen, die Vorteile einer eigenen Infrastruktur auch ohne besondere Berücksichtigung dieser Problematiken deutlich. Ein zur Komplexität erheblich beitragender Punkt sind die im universitären Umfeld eingesetzten Softwareprodukte mit den zugehörigen Lizenzbestimmungen. Deren Anbieter sind oft nicht auf Cloud-Lösungen bei externen Anbietern vorbereitet.

Neben der notwendigen Weiterentwicklung von technischem Wissen über den Betrieb verschiedener Systeme und Umgebungen innerhalb der Rechenzentren, ist die Teilnahme an Kooperationsprojekten zur gemeinschaftlichen Erbringung komplexer Dienste zudem ein möglicher praktischer Ausweg aus der Situation, dass die Rechenzentren mit gestiegenen Anforderungen seitens der Nutzerinnen und Nutzer konfrontiert werden, die Strukturen bezogen auf Umfang und Ausrichtung des Personals sowie die finanzielle Ausstattung diesen aber nicht im gleichen Maße folgen. Entsprechende Kooperationsprojekte können, bei einer sinnvollen Aufgabenstellung und -verteilung und einer entsprechend vertrauensvollen Arbeitsatmosphäre, in ziemlich kurzer Zeit gute Resultate erzielen – so wie die bwCloud, die im Rahmen einer Kooperation von vier Betriebsstandorten aufgebaut und betrieben wird.

Die bwCloud

Im Rahmen des 2015 gestarteten und vom MWK geförderte Landesprojekt "bwCloud: Standortübergreifende Servervirtualisierung" wurde von den Projektpartnern BelWü, sowie den Rechen- und Informationszentren des KIT und der Universitäten Freiburg, Mannheim und Ulm der Grundstein für einen stabilen und nachhaltigen Betrieb des Landesdienstes gelegt. Zentrale Aufgabe der bwCloud ist die Bereitstellung von Ressourcen zum Betrieb von virtuellen Maschinen und Servern. Diese (virtuellen) Ressourcen sollen weitestgehend von den Nutzerinnen und Nutzern selbständig im Rahmen von Self-Service-Funktionalitäten gemanagt und betrieben werden.

Neben der Auswahl einer Infrastructure as a Service (Iaas)-Lösung und deren prototypischen Umsetzung wurden im Verlauf des Projektes insbesondere die folgenden grundlegenden Fragen beantwortet:

Welche Vorteile lassen sich aus einer Cloud-Infrastruktur für die Bereiche Forschung und Lehre ziehen?
In welchem Umfang ist eine eine Cloud-Infrastruktur heute in der Lage, "herkömmliche" Virtualisierungsumgebungen in Hochschulrechenzentren zu ersetzen? Welche Vor- aber auch Nachteile und Aufwände sind hier zu erwarten?
Wie hoch ist das Potential für die Konsolidierung von physikalischen Klein- und Kleinstinstallationen in Instituten und Arbeitsgruppen in virtuelle Umgebungen unter Berücksichtigung von Self-Service-Mechanismen?
Welche technischen aber auch personellen Voraussetzungen und Aufwände sind für einen sicheren Betrieb zu erfüllen?
Wie sieht ein tragfähiges Betriebsmodell für eine verteilte Ressource aus, das sowohl die Bedürfnisse und Anforderungen der beteiligten Rechenzentren als auch die der Nutzerinnen und Nutzer ausreichend berücksichtigt?

Die (Vor-)Auswahl

Bereits nach kurzer anfänglicher Diskussion war klar, dass sich nachhaltige Synergien nur dann erreichen lassen, wenn ein einheitliches Betriebsmodell entwickelt und zu Grunde gelegt und dieses von einer landesweit aufgestellten Betriebsgruppe umgesetzt wird. Der Standort der Hardware wird hierbei, insbesondere durch die hohe Leistungsfähigkeit des Landeshochschulnetzes BelWü, irrelevant. Lediglich die notwendigen Redundanzen waren zu beachten. Das Betriebsmodell muss so aufgebaut sein, dass im weiteren Verlauf bestehende Betriebsstandorte ausscheiden oder neue eingegliedert werden können.

Als technische Grundlagen standen sowohl hinsichtlich der möglichen Linux-Plattform als auch der eigentlichen "Cloud-Lösung" etliche Möglichkeiten und Produkte zur Auswahl: OpenNebula, CloudStack und OpenStack, das hinsichtlich Popularität im Sinne von Hype sicherlich ganz vorne einzuordnen ist, wurden untersucht und evaluiert. Auf Grund von bereits vorhandenem Know-how und wegen seiner sehr aktiven Nutzer- und Entwicklergemeinde fiel die Entscheidung letztlich für OpenStack [6], wenngleich es sich hier mehr um ein Framework als um ein "fertiges Produkt" handelt (Kritiker bezeichnen OpenStack gelegentlich auch als "Python-Skript mit Ambitionen"). Der Framework-Charakter von OpenStack bietet aber letztendlich die notwendige Flexibilität, die bei der Entwicklung einer Cloudumgebung mit mehreren Betriebsstandorten unumgänglich ist.

Diese Problematik und die Gefahr der Schnelllebigkeit zeigt sich auch bei Projekten rund um OpenStack. Von diesen wird eine nicht unerhebliche Anzahl bereits nach wenigen OpenStack-Release-Zyklen nicht mehr unterstützt oder die Weiterentwicklung stagniert.

Für die Versorgung der OpenStack-Komponenten "Cinder" (block-storage), "Glance" (image-storage) und "Swift" (object-storage) mit schnellem Plattenplatz fiel die Wahl auf Ceph [7], das ebenso wie OpenStack auf Basis des Betriebssystems CentOS [8] betrieben werden kann.

Evaluation und erste Schritte

Im Rahmen der Projektförderung wurde an den vier Betriebsstandorten x86_64-basierte Hardware zu Evaluationszwecken, auch für größere Nutzerzahlen, beschafft. Hiermit wurden auf Seite des OpenStack-Compute Moduls "Nova" die Einflüsse unterschiedlicher CPU-Leistungsklassen, der Gesamtzahl der Rechenkerne pro Server und des Verhältnisses RAM/Core in Vorbereitung des Produktivsystems untersucht.

In der für das Gesamtsystem kritischen Netzwerk- und Storage-Umgebung ließen sich erhebliche Unterschiede in der Performance nachweisen. So erlaubt beispielsweise das Offloading von VXLAN-Operationen [9] an die Hardware der Netzwerkkarte ebenso deutlich höhere Bandbreiten wie die Nutzung der embedded switches, die einige NICs (Network Interface Card) mitbringen.

Vergleichbares konnte bei den unterschiedlichen Techniken zum Caching in Ceph beobachtet werden. Hierbei haben auch die Einflüsse der jeweiligen Softwareversionen überrascht. Der auf Basis von Linux operierende block-cache Bcache [10] liefert im Zusammenspiel mit aktuellen SSDs sehr gute Performance. Auf Grund der Optimierungen in neueren Ceph-Versionen als auch der deutlich höheren Komplexität des bcache-Ansatzes wurde dieser letztendlich zugunsten einer "Standard Ceph"-Konfiguration verworfen, die sich in einem modifizierten Hardwarelayout widerspiegelt.

Letztendlich umfasste das Testsystem akkumuliert über die vier Betriebsstandorte rund 400 CPU-Cores, 4 TByte an RAM, 180 TByte an Plattenspeicher und etliche 10- bzw. 40-Gbit-links. Ein Großteil dieser Ressourcen diente auf Grund von Verzögerungen bei der Beschaffung vielen Nutzern im Land als Basis für einen Quasi-Produktivbetrieb. Die Nutzungs- und Auslastungszahlen verdeutlichen dies (s. Abb. 2).

Die für die Planung des neuen Systems wichtigste Kennzahl – die Verteilung der virtuellen Maschinen hinsichtlich Speicher- und CPU-Bedarf – konnte aufgrund der großen Datenbasis daher sehr gut ermittelt werden. Überraschend für alle Beteiligten war die Erkenntnis, dass über 80 Prozent der VMs lediglich maximal 4 GByte an Hauptspeicher und maximal 2 virtuelle CPUs (vCPU – 16 vCPU- entsprechen 1 CPU-Kern) anfordern. Knapp 30 Prozent kommen sogar mit nur einer vCPU und 1 GByte bzw. 512 MByte an Hauptspeicher aus.

Abb. 2: Die grüne Kurve gibt die Zahl der virtuellen Maschinen wieder, die blauen Balken die Zahl der registrierten Nutzer aus den aktiven 25 Hochschulen und Universitäten. Stand: 03/18. © Thomas Nau & Janne Schulz

Die Technik im Detail

OpenStack

Wie eingangs erwähnt versteht sich OpenStack als Framework, dessen einzelnen Dienste und Funktionen in Komponenten gekapselt sind. Die Kommunikation zwischen den Komponenten geschieht mittels einer definierten REST-API [11] auf Basis von HTTPS. Diese Architektur ist eine perfekte Voraussetzung für Scripting und Automatisierung. Auch die Interaktion von OpenStack-Umgebungen und -Regionen miteinander – dazu gleich mehr – ist dank dieser Mechanismen über weite Strecken möglich – eine leistungsstarke Vernetzung vorausgesetzt. Der vernetzte Charakter der Komponenten von OpenStack stellt jedoch auch einen möglichen Schwachpunkt dar: die gesamte Umgebung ist massiv von der Netzwerkinfrastruktur abhängig, was sich in einer deutlich komplexeren Ursachenforschung im Falle von Fehlern äußert.

Die in der bwCloud aufgebauten und betriebenen vier OpenStack-Regionen werden nach dem Ansatz "Multi-Site-Multi-Region" betrieben, d. h. jeder Betriebsstandort ("Site") betreibt eine eigene OpenStack-Region, und bilden logisch jeweils eigene Umgebungen mit einer individuellen Konfiguration hinsichtlich der Netzanbindung. Dazu gehört auch der eigenständige Betrieb einiger OpenStack-Basisdienste wie "Nova" (Compute), "Swift" (Blockspeicher) und "Neutron" (Netzwerk). Gemeinsam genutzt werden dagegen das grafische Nutzerinterface oder auch Dashboard "Horizon", sowie die Authentifizerungskomponente "Keystone". Einen Sonderfall bildete das Image-Repository "Glance". Dieses wird zentral am RZ in Freiburg bereitgestellt, jedoch an die anderen drei Standorte regelmäßig repliziert. Dies verbessert die Performance und reduziert die Komplexität im Netzwerk und Sicherheitsbereich. Daneben können auch eigene Images in der bwCloud verwendet werden.

Die Entscheidung jeweils zugunsten des "Multi-Site-Multi-Region"-Ansatzes (eine Region pro Betriebsstandort) fiel nach Abwägung folgender Eigenschaften:

Vorteile

Einbindung lokaler Infrastruktur, etwa Active-Directory beziehungsweise LDAP aber auch Fileserver, ist einfacher möglich, da in aller Regel Firewalls diese Dienste nach außen schützen.
Verwendung von IP-Adressen aus dem lokalen Adressbereich der Betreiber. Damit ist der Zugriff auf entsprechend beschränkte lizenzierte Software aus einer VM möglich.
Die Hardware darf zwischen den Regionen deutliche Unterschiede ausweisen.

Nachteile

Eine Live-Migration von virtuellen Maschinen über die Grenzen einer Region hinweg ist nicht möglich.
Die Regionen müssen hinsichtlich der Softwareversionen durch das Betriebsteam koordiniert und synchron gehalten werden.
Quotas oder deren Anteile müssen bei Nutzung mehrerer Regionen manuell transferiert werden.
Die gemeinsam benutzten Komponenten "Keystone" und "Horizon", bzw. deren Netzanbindung, bilden single points of failure und müssen entsprechend abgesichert werden.
Die Idee einer "Multi-Site-Single-Region", also das Aufspannen einer Region über zwei oder mehr Betriebsstandorte, wurde nach der ersten Testphase verworfen. Zwar ist bei diesem Betriebsmodell eine Live-Migration von virtuellen Maschinen möglich, jedoch zeigte sich das System insgesamt als zu anfällig hinsichtlich kleinster Störungen, was einen stabilen Betrieb nicht möglich machte.

Ceph

Ähnliche Abwägungen hinsichtlich der Vor- und Nachteile führten zu Beginn schnell zu einer Entscheidung für den Einsatz von Ceph im Bereich der Speicherorganisation und -anbindung. Allerdings steht den ausschlaggebenden Vorteilen einer kostenfreien Software, die auch auf commodity-Hardware gut skalieren kann, eine nicht triviale Konfiguration entgegen, deren Entwicklung einige Zeit in Anspruch nahm und zudem eine sehr steile Lernkurve erforderte – oft den Einsatz von Learning-by-doing oder gar Trial-and-error-Methoden, um die besten Parameterwerte zu ermitteln.

Jedoch gibt es auch hier, wie bei OpenStack, sowohl kommerzielle als auch kostenfreie Alternativen die ggf. in anderen Umgebungen schneller zum Ziel führen.

Eine weitere Grundsatzentscheidung betrifft die Art und Weise in der Compute- und Storage-Knoten miteinander verwoben sind. Für kleinere Installationen, etwa unser Testsystem, bietet sich eine Hyper-converged-Lösung an. Dabei ist jeder Server mit genügend Plattenspeicher bzw. SSDs aber auch RAM und CPUs ausgerüstet, um sowohl die Aufgaben von Ceph als auch die von OpenStack parallel übernehmen zu können. So lässt sich mit recht geringem (Hardware-)Aufwand ein System aufbauen, in dem einzelne Szenarien erprobt werden können.

Durch die enge Verzahnung von Compute- und Speicherhardware ist jedoch die Aufrüstung einzelner Bereiche, etwa mehr Compute-Leistung oder mehr SSD Caching, nur schwer umsetzbar. Langfristig haben sich getrennte Investitionspfade, also der klassische Ansatz einer physischen Trennung von Compute und Storage, als die bessere Lösung herausgestellt. Konsequent liegen daher in der neuen bwCloud-Umgebung alle Speicherbereiche der Nutzer im Ceph-Pool.

Neben den separierten Investitionspfaden für Storage und Compute ist auch die Optimierung der Hardware hinsichtlich des Einsatzzweckes ein Vorteil. Dieser ist jedoch mit höheren Anfangsinvestitionen und einer komplexeren Vernetzung zu erkaufen.

Abb. 3&4: Klassischer Aufbau der OpenStack-Umgebung: Die Compute-Knoten umfassen bis auf eine lokale Festplatte keinen weiteren Speicher.

Dieser ist in großen Storage-Knoten mit entsprechenden Köpfen ausgelagert und intern vernetzt. © Thomas Nau & Janne Schulz

Betriebliche Aspekte

Release-Zyklen von OpenStack

Die hohe Frequenz an OpenStack-Releases spricht für die stetige Weiterentwicklung und Verbesserung der Software. Für einen Produktivbetrieb stellen die verhältnismäßig schnellen Release-Zyklen von nur sechs Monaten aber eine große Herausforderung dar, die eine agile DevOps-Gruppe voraussetzt. Während der Testphase wurden daher Updates häufiger eingespielt, um die betrieblichen Abläufe zu automatisieren, zu testen und zu verbessern. Eine wesentliche Erfahrung war, dass ein Release-Upgrade, also ein Wechsel auf ein nächsthöheres Release, einer intensiven Vorbereitung und Überprüfung im Vorfeld bedarf. Erschwerend kommt hinzu, dass das "Überspringen" von Releases nicht empfohlen wird und durchaus Risiken birgt.

Im Produktivbetrieb, der jetzt mit dem neuesten Release gestartet wurde, werden wenn möglich, Updates eher selten erfolgen und genau geplant werden. Ausnahme sind hierbei wie immer sicherheitskritische Releases oder diejenigen, die einen für Nutzer und Betriebsteam spürbaren Zugewinn an Funktionalität bedeuten.

Monitoring und Reporting

Im Bereich des Monitoring mit Hilfe der Bordmittel von OpenStack zeigen sich diese leider nicht von ihrer besten Seite. Zwar steht mit der OpenStack-Komponente "Ceilometer" auch hier ein passendes Modul bereit, jedoch ist dieses unserer Erfahrung nach nicht reif für Produktivumgebungen. So waren selbst in unserer überschaubaren Testumgebung die negativen Einflüsse auf die Gesamtperformance spürbar. Unserer Ansicht nach ist dies der mangelnden Integration und der damit verbundenen schlechten Effizienz geschuldet (letztendlich "belauscht" Ceilometer den Message-Bus (RabbitMQ) über den alle OpenStack-Komponenten ihre Nachrichten miteinander austauschen).

Daher verfolgen wir seit geraumer Zeit den Ansatz eines externen Monitorings. Die Daten werden dazu zentral an allen Standorten erfasst, am KIT zusammengeführt und über ein eigenes "Grafana"-Dashboard visualisiert [12].

Gleiches gilt auch für den Bereich des Reporting, für das es zum heutigen Zeitpunkt keine OpenStack-Komponente gibt, die unseren Anforderungen gerecht wird. Daher wurde im Rahmen des Projektes ebenfalls eine eigene Lösung entwickelt, die periodisch die genutzten Nova- (VMs) und Neutron(Netzwerk)-Ressourcen aus den zugehörigen OpenStack-Datenbanken ausliest. Diese Daten fließen von allen Betriebsstandorten ebenfalls in einer eigenen zentralen Datenbank zusammen. Hieraus lassen sich anschließend neben beliebigen Nutzungsstatistiken für die Planung insbesondere auch Verrechnungs- und Abrechnungsübersichten gewinnen. Nachteilig wirkt sich aus, dass vor jedem OpenStack-Upgrade sorgfältig geprüft werden muss, ob die Datenbank-Schemata verändert wurden. Der direkte Zugriff auf die Datenbank unter Umgehung der API ist notwendig, weil die API nicht alle notwendigen Daten bereitstellt.

Nutzermanagement

Ein ausgefeiltes Nutzer- bzw. auch Rollen- und Rechtemanagement wie es etwa Microsofts Active Directory bietet, sucht man in OpenStack vergeblich. Das mag sich in der Zukunft ändern, bis dahin gilt aber "bist du nicht Admin, bist du Nutzer". Eine weitere Differenzierung findet derzeit nicht statt und stellt, vor allem mit dem Einsatzziel "Operations im RZ", eine hohe Hürde dar. Dort sind feingranulare und hierarchische Rechte- beziehungsweise Rollenkonzepte seit langem etabliert.

In einem ersten Schritt nutzt bwCloud die Authorisierungs-, Verifizierungs- und Authentifizierungsfunktion, die der Landesdienst bwIDM bereitstellt. Mit dessen Hilfe ist sichergestellt, dass sich nur durch die jeweilige Heimateinrichtung berechtigte Personen über die Self-Service-Funktion für die bwCloud-Nutzung registrieren können. Im Rahmen dieser Registrierung werden dann automatisiert alle weiteren Parameter, wie etwa Quota oder der primäre Betriebsstandort, erzeugt und in der OpenStack eigenen Nutzerverwaltung hinterlegt.

Der Nachteil dieser Lösung ist, dass periodisch sich alle Nutzer hinsichtlich ihrer andauernden Zugehörigkeit zur jeweiligen Hochschule über eigene Skripte verifiziert werden müssen.

Herausforderungen im Netzbereich

Die OpenStack-Umgebungen sind darauf ausgerichtet, auf "Knopfdruck" hunderte virtueller Maschinen zu erzeugen und zu starten. Das interne Betriebsmotto lautet daher auch "Wenn die Maschine kaputtgeht, wird einfach eine neue erstellt". Damit kommen auf die betreibenden Rechenzentren auf der Seite der Vernetzung allerdings neue Probleme im Rahmen der Versorgung der virtuellen Maschinen mit IPv4-Adressen zu. Insbesondere, wenn die virtuellen Maschinen weltweit erreichbar sein sollen, müssen entsprechend große freie IPv4-Adressräume zur Verfügung gestellt werden. Da die allgemeine Versorgungslage mit freien IPv4-Adressblöcken zunehmend schwierig wird und die bwCloud-Betriebsstandorte durch die landesweite Nutzerschaft nicht nur ihre eigenen Angehörigen mit Adressen versorgen müssen, ist eine enge Integration der Netzwerkabteilungen bei Planung, Aufbau und Inbetriebnahme der Umgebungen unerlässlich. Gleichzeitig bietet sich die bwCloud jedoch auch als praktisches IPv6-Testfeld an, bei dem gemeinsam mit den Fachabteilungen der Betriebsstandorte und denen der Standorte der Nutzerinnen und Nutzer die Infrastrukturen auf ihre IPv6-Tauglichkeit hin untersucht und gegebenenfalls ausgebaut werden.

Übergang in den Produktivbetrieb

Die zweite vom MWK geförderte Projektphase mit Namen "bwCloud SCOPE – Science, Operations and Education" fokussiert sich seit dem 1. Januar 2017 mit der Inbetriebnahme eines deutlich größeren Systems auf einen produktiven Betrieb. Dieser basiert auf den Erkenntnissen der Testphase und setzt die dort etablierten und entwickelten Best Practices konsequent um, insbesondere auch ein einheitliches Betriebsmodell.

Mit der neuen, auf AMD Epyc-Prozessoren basierenden Hardware, stehen seit kurzem an jedem der vier Betriebsstandorte mindestens sechs TByte Hauptspeicher und 400 CPU-Kerne zur Verfügung. Dazu kommen mindestens 0,5 PByte pro Betriebsstandort an Plattenspeicher zuzüglich moderner NVME-basierter Caches. Als Netzwerkverbindungen dienen im Backend optische 40 Gbit Ethernet NICs. Damit konnte die Leistung des Testsystems vervielfacht und insbesondere die seit einigen Monaten auftretenden Engpässe beseitigt werden. Basierend auf den gemachten Erfahrungen erlaubt der aktuelle Ausbau den Betrieb einiger tausend VMs aller Ausprägungen.

Das Akronym SCOPE spiegelt dabei die in der vorherigen Phase identifizierten Nutzungsszenarien und ihre unterschiedlichen Anforderungen wider.

Science – Instituts-/Wissenschaftler-/Projekt-VM

Der Use-Case "Science" richtet sich an Mitarbeiter und Wissenschaftler an den Einrichtungen im Land, die für Forschung oder andere Zwecke Ressourcen in Form von virtuellen Maschinen benötigen. Anwender dieser Gruppe sind hinsichtlich der angefragten Ressourcen nicht beschränkt: Sie können individuell die Anzahl der virtuellen Maschinen steuern und selbständig entscheiden, wie die angefragten Ressourcen genutzt werden sollen (Aufbau des virtuellen Netzwerks, Anzahl der instanziierten virtuellen Maschinen etc.). Auf diese Weise ist der Aufbau von komplexen temporären Analyse- und Auswertungssystemen genauso möglich wie der kontinuierliche Betrieb von Servern beispielsweise für die Organisation eines verteilten Projektes. Durch den Betrieb der Hardware in den geschützten Umgebungen der Rechenzentren kann "externe" Hardware, wie beispielsweise lokal vorhandene Speicherhardware, an die Cloud-Umgebung angeschlossen und bestimmten Anwendern zur Verfügung gestellt werden. Die Vorteile für die Anwender liegen in der schnellen Bereitstellung der angefragten Ressourcen sowie der Möglichkeit, große und sehr große virtuelle Maschinen nach Bedarf einzurichten und zu betreiben.

Operations – Betrieblicher Dienst/ Service

Auch die Rechenzentren selbst sind eine Nutzergruppe der bwCloud. Sie unterliegen wie die Anwender im Use-Case "Science" keinen Restriktionen hinsichtlich Anzahl oder Leistungsfähigkeit der benötigten Ressourcen. Denkbar ist die Verlagerung einiger Rechenzentrums-Dienste aus den klassischen Virtualisierungsumgebungen in die bwCloud-Infrastruktur. Dies gilt insbesondere für Dienste, die keine hohen Anforderungen an Hochverfügbarkeit und Ausfallsicherheit stellen. So könnten die im betrieblichen Einsatz verwendeten Virtualisierungsumgebungen entlastet werden, was den übrigen dort laufenden Instanzen zugute kommt und den finanziellen Aufwand reduziert. Die Verschiebung entsprechender Ressourcen kann auch Überlegungen zu einer Neudimensionierung der betrieblichen Virtualisierungsumgebung unterstützen – als Stichwort sei hier das "Lizenzmanagement" genannt. Ein weiteres Themenfeld bildet die Möglichkeit der campusweiten Hardwarekonsolidierung. Serversysteme können sukzessive eingesammelt und in die bwCloud umgezogen werden. Die frei werdende Hardware kann anschließend bei entsprechendem Betriebsalter entsorgt werden. Alternativ können Erstbeschaffungen durch die bwCloud ersetzt werden.

Education – Studi-VM

Eine Befragung der Rechenzentren zu Einsatz und Angebot von Virtualisierungsumgebungen hat ergeben, dass Studierende als bislang größte Anwendergruppe derzeit keinen oder nur in sehr beschränktem Umfang Zugang zu Ressourcen wie eigener Hardware oder virtuellen Maschinen haben, die sie im Rahmen ihres Studiums nutzen können. Demgegenüber ist in nahezu allen Studiengängen eine stetige Zunahme an Einsatz und Bedarf von IT-gestützten Systemen festzustellen. Die Anwendergruppe für eine "Studi-VM" sind Studierende, die Ressourcen in Form von virtuellen Maschinen im Rahmen des Studiums beispielsweise für Projekt- oder Abschlussarbeiten benötigen. Diese virtuellen Maschinen umfassen eine einfache Ausstattung und sind in ihrer Anzahl pro Anwender limitiert. Dieses Nutzungsszenario schließt auch den Einsatz von virtuellen Maschinen im Rahmen von Lehr- und Lernveranstaltungen ein. Dazu können Gruppenleiter entsprechende Vorlagen ("Templates") bauen, die an die Studierenden im Rahmen der Veranstaltung verteilt werden. Diese starten dann gemäß der vordefinierten Einstellungen und Konfigurationen ihre Umgebungen und können so dem Unterrichtsverlauf folgen und gemeinsam Aufgaben lösen.

Ausblick

Durch den während des Vorgängerprojektes erfolgten Aufbau eigener Expertise im Aufbau und Betrieb der verteilten OpenStack-Cloud lassen sich für alle drei Nutzergruppen wesentliche monetäre, personelle und organisatorische Verbesserungen erzielen. Die Konsolidierung vieler "Individualrechenzentren" erlaubt nicht nur eine effizientere Nutzung von Server-Hardware sondern darüber hinaus auch effizientere Kühl- und Energieversorgungskonzepte. Zugleich gewinnen die Einrichtungen einen besseren Überblick über die benötigten Ressourcen und können dies in ihren Planungen berücksichtigen.

Im Bereich Operations wird in den Rechenzentren bereits seit geraumer Zeit das Potenzial der Virtualisierung genutzt. Oft sind jedoch die Hardware- und Energiekosten die treibende Kraft und weniger das Bestreben, eine echte DevOps-Kultur zu etablieren. Punkten kann hier eine freie Cloud-Lösung wie OpenStack vorrangig mit einer Reduktion der Lizenzkosten. Allerdings ist OpenStack heute aufgrund der Komplexität im Betrieb und grundlegender Eigenschaften wie dem konsequenten "Cloud-Compute"-Ansatz für einen RZ-Betrieb kein kompletter Ersatz für etablierte Virtualisierungsprodukte sondern vielmehr eine weitere, notwendige Ergänzung bestehender Services.

Ganz neue Möglichkeiten entstehen im Bereich der Lehre. So lassen sich beispielsweise zur Unterstützung von Vorlesungen in kürzester Zeit virtuelle IT-Landschaften ausrollen, die dann von Studenten begleitend nicht nur genutzt sonder aktiv angepasst werden können.

Das Akronym SCOPE spiegelt dabei die in der vorherigen Phase identifizierten Nutzungsszenarien und ihre unterschiedlichen Anforderungen wider.

Fazit

Zusammenfassend darf gesagt werden, dass besonders in Umgebungen mit komplexen Anforderungen der Betrieb einer eigenen Cloud-Infrastruktur absolut seine Berechtigung hat. Bestätigt wird dies durch die sehr hohe Akzeptanz seitens der Nutzer als auch der Bereitstellung der notwendigen Investitionssummen an den Betriebsstandorten sowie der weiteren Förderung von Seiten des MWK.

OpenStack und Ceph stellen eine stabile Basis für einen produktiven Betrieb dar, erfordern aber erhebliche "Startinvestitionen", da beide eher einen Baukasten als eine fertige Lösung darstellen. Daher ist die Verfügbarkeit von geschultem Personal mit dem notwendigen Hintergrundwissen eine zwingende Voraussetzung für den Erfolg dieses oder vergleichbarer Projekte. Dies gilt um so mehr, zumal auch zukünftige Upgrades sicherlich eine Herausforderung darstellen werden und fehlende betriebsrelevante Funktionen selbst implementiert wurden und werden müssen.

Bewährt hat sich der Start mit einer einfachen Umgebung, in der Fehler gemacht werden können, um daraus zu lernen. Nur so ist das Team später in der Lage, die richtigen Fragen zu stellen oder auftretende Probleme zeitnah zu lösen. Der schrittweise Weg von einem Prototypen mit einigen Nutzern hin zu einer großen Umgebung mit vielen Nutzern ist bei der Realisierung komplexer verteilter Systeme die einzige Variante, um sowohl eigene Betriebskenntnisse aufzubauen, als auch die Services kontinuierlich mit den Anforderungen der Nutzer ein Einklang zu bringen.

Die Vorteile für die beteiligten Betriebsstandorte liegen nicht nur im Aufbau von dringend benötigter Expertise im Bereich des Cloud-Computings. Die notwendige intensive Kooperation auf den unterschiedlichsten Ebenen fördert ein Verständnis für die Gemeinsamkeiten miteinander, aber auch der Unterschiede zueinander. Neben der Chance, den Nutzerinnen und Nutzern mit einem modernen und zeitgemäßen Service eine attraktive Alternative zu kommerziellen Angeboten bieten zu können, werden mit der bwCloud kommende Herausforderungen, wie die Versorgung aller Arbeitsplätze mit einer IPv6-basierten Vernetzung nicht nur zu einer "akademischen Übung", sondern bekommen eine ganz reale Dimension. Die Herausforderung für das bwCloud-Projekt besteht nun darin, ein nachhaltiges Betriebs- und Geschäftsmodell aufzubauen, welches zum einen von den Nutzerinnen und Nutzern angenommen wird und zum anderen den dauerhaften Betrieb – auch in Sachen Personal – sicherstellt. Dass die bwCloud offenbar auf dem richtigen Weg ist, zeigen dabei letztlich die kontinuierlich steigenden Nutzerzahlen.

Quellen