Linux-Magazin_-_Januar_2019

terlegt der Admin für die DB noch eine
Konfiguration, erstellt Benutzerzugänge
und schlägt sich mit der Syntax des SQL-
Befehls »GRANT« herum, um Zugriffs-
rechte zu verteilen. Am Ende steht eine
lauffähige Datenbank, deren Zugangsda-
ten er dann noch in seine Applikation
einträgt – fertig ist der Lack.
Die Wartungsarbeiten, die ein solches
Setup hervorruft, sind allerdings be-
achtlich: Regelmäßige Updates in Sa-
chen Security stehen ebenso wie Major
Upgrades an. Auch Monitoring ist ein
Thema, und eigentlich muss man ein
solches Setup ja auch mit einem Hoch-
verfügbarkeitskonzept verbinden, zum
Beispiel mit Galera, was jedoch den War-
tungsaufwand kurzerhand verdreifacht.
(Wer alternativ auf Pacemaker setzt, wird
schnell feststellen, dass das keine so gute
Idee ist.)
Die Idee hinter As-a-Service-Angeboten
ist, all diese Schritte aus dem Pflichten-
heft des Kunden-Admin zu entfernen.
Dafür bietet der Cloudprovider eine API-
Schnittstelle an, die im Hinblick auf Da-
tenbanken ähnlich arbeitet wie ein Au-
tomat: Der Kunde gibt nur an, welchen
Datenbanktyp er benötigt (Abbildung
1 ) und wie die Datenbank erreichbar
sein soll – wenig später bekommt er die
IP-Adresse sowie die nötigen Benutzerda-
ten angezeigt, und schon steht die Daten-
bank zur Nutzung parat.
Das Hinzufügen neuer Benutzer erledigt
der Kunde ebenso per Cloud-API wie

das Feintuning der

Datenbank – falls

gewünscht. Die

Methode hat ei-

nen unschlagbaren Vorteil: Sie ist aus

Kundensicht agnostisch im Hinblick auf

die genutzte Datenbank: Die API-Befehle

zum Anlegen von Benutzern (Abbildung

2 ) unterscheiden etwa zwischen Post-

greSQL, Mongo DB und Maria DB nicht.

Unter der Haube viel

Aufwand

Damit dieser Ablauf funktioniert, erle-

digt die in der Cloud verantwortliche

Komponente im Hintergrund eine ganze

Reihe von Arbeiten, die den Augen des

Nutzers gewollt verborgen bleiben. Denn

natürlich ist auch eine als DBaaS gestar-

tete Datenbank ein normales Maria DB

oder PostgreSQL, das in einer virtuellen

Maschine läuft. Die DBaaS-Komponente

nimmt dem Admin aber die vielen Integ-

rationsschritte ab.

Bevor Trove in Open Stack etwa eine

DBaaS startet, legt es ein persistentes

Blockgerät an, auf dem die Daten der

DB später zu speichern sind. Dann star-

tet Trove eine ganz normale VM-Instanz

über Nova, das für die Verwaltung von

virtuellen Maschinen verantwortlich

ist. Dafür nutzt es allerdings nicht die

Standard-Betriebssystemabbilder, die für

reguläre VMs von Kunden zum Einsatz

kommen.

Stattdessen setzt Trove auf eigene Ima-

ges, die explizit für Trove vorbereitet sind

und einen Agenten mit an Bord haben.

Dieser verbindet sich mit der Metadaten-

Komponente von Nova, wo die zuvor

vom Nutzer hinterlegten Konfigurati-

onswerte gespeichert sind, und liest sie

aus. Danach bereitet es die frische VM

vor, indem es das persistente Volume

einhängt, die Datenbank entsprechend

konfiguriert und schließlich startet. Im

Grunde ist Trove also nichts anderes als

eine Automatisierungslösung für den Be-

trieb von Datenbanken in Open Stack, die

auf vorhandene Infrastruktur setzt und

gegebene Funktionen nutzt.

Ähnlich verhält es sich mit anderen An-

geboten aus dem AaS-Dunstkreis: Moni-

toring-as-a-Service etwa, das Open Stack

über seine Komponente Monasca reali-

siert, funktioniert ganz ähnlich. Am Ende

geht es bei AaS-Diensten stets darum,

Komplexität vor dem Nutzer zu verber-

gen und sie möglichst effizient wegzuau-

tomatisieren. Das senkt für den Kunden

nämlich die Einstiegshürde und steigert

die Effektivität der Umgebung enorm.

Nur wenige Zugriffs­

möglichkeiten

Die Medaille hat freilich auch eine Kehr-

seite. Denn je unselbstständiger der

Kunde ist, desto weniger Möglichkeiten

hat er auch, im Falle des Falles genauer

hinzusehen und selbst zu handeln. Wo-

bei das Level an Abschirmung sich hier

durchaus zwischen verschiedenen Cloud-

anbietern unterscheidet.

Klickt sich der Admin etwa bei Amazon

eine DBaaS-Instanz, erscheint es nahezu

unmöglich, irgendwie an die unter der

Datenbank existierende VM heranzukom-

men. Das ist im Konzept einfach nicht

47

http://www.linux-magazin.de

Titelthema

Cloud-Forensik

Abbildung 1: Wer Dienste wie DBaaS (hier am Beispiel Open Stack) verwendet,
der gibt einen großen Teil der Kontrolle auf.

Abbildung 2: Zwar sind Ansätze wie DBaaS bequem und komfortabel, allerdings

machen sie Vorgänge – etwa Forensik – viel komplexer.