Das an Bedeutung und Akzeptanz gewinnende Gescha¨ftsmodell Software as a Service ermo¨glicht Unternehmen die Konzentration auf ihr Kerngescha¨ft durch das Beziehen von Dienstleistungen u¨ber das Internet. Die Festlegung von Service Level Agreements gewa¨hrleistet eine hohe Qualita¨t des Dienstes. Um die operationalen Kosten des Service Providers gering zu halten, bedarf es des Einsatzes einer Multi-TenancyArchitektur, die zu neuen Herausforderungen fu¨r den Einsatz von Datenbankverwaltungssystemen fu¨hrt. In diesem Beitrag werden die Problemstellungen der Realisierung von Multi Tenancy in heutigen Datenbankverwaltungssystemen aufgezeigt und eine native Unterstu¨tzung von Multi Tenancy in jenen Systemen motiviert. Es wird hervorgehoben, dass die Integration von mandantenspezifischen Service Level Agreements zur Steigerung der Qualita¨t des Dienstes beitra¨gt. Hierzu wird die Verwendung dieser bereitgestellten Daten zur Ressourcenverwaltung und -u¨berwachung sowie der Lastverteilung von Mandanten verdeutlicht.
H.2.7 [Database Management]: Database Administration—Data dictionary/directory; H.2.1 [Database Management]: Logical Design—Schema and subschema
1.
2.
Die Architektur von SaaS-Angeboten ist in großem Maße vom Gescha¨ftsmodell des Anbieters abha¨ngig. Sie wird beispielsweise beeinflusst durch das zur Verfu¨gung stehende
Komplexität, Ressourcenausnutzung, max. Mandantenanzahl, Skalierbarkeit
hoch niedrig
Abbildung 1: Ans¨atze zur Mandantenisolation im DB-Layer, angelehnt an [
Um die in der Einleitung motivierte hohe
Wirtschaftlichkeit eines SaaS-Angebots zu erzielen, werden vermehrt
Multi-Tenancy-Architekturen eingesetzt. Diese erlauben allen
Service-Nutzern die gemeinsame Verwendung von
HardwareRessourcen durch das Anbieten einer gemeinsamen
Anwendungsinstanz [
Es existiert ein breites Realisierungspektrum fu¨r Multi Tenancy in einem Datenbankserver. In Abbildung 1 werden die wichtigsten Ansa¨tze zusammengefasst sowie Vorteile und Herausforderungen aufgezeigt. Neben der Mo¨glichkeit, auf eine Mandantenkonsolidierung zu verzichten (Separate Hardware), ko¨nnen Mandanten beispielsweise durch die Zuweisung separater virtueller Maschinen (Shared HW ), durch die Nutzerverwaltung des Betriebssystems (Shared VM ) oder durch die Verwendung getrennter Datenbankinstanzen (Shared OS Level ) bzw. Datenbanken (Shared DB Instance) voneinander isoliert und dennoch auf einem Datenbankserver verwaltet werden. Aufgrund des initialen Ressourcenbedarfs und der gesonderten Administration dedizierter Datenbanken, Datenbankinstanzen, Betriebssysteme oder virtueller Maschinen fu¨hren diese Ansa¨tze fu¨r den SasS-Anbieter zu hohen Kosten je Mandant. Sie sollten daher nur bei zwingender Notwendigkeit eines hohen Isolations- bzw. Sicherheitslevels oder bei einer geringen Anzahl von Mandanten verwendet werden.
Der Ansatz Shared Database erlaubt durch die
Mandantenkonsolidierung in einer Datenbank die gemeinsame Nutzung
von Datenbankprozessen und Hauptspeicherinhalten. Die
Zuweisung zu eigenen Datenbankobjekten wie Tabellen und
Indizes fu¨hrt bei Nutzung der Datenbankzugriffskontrollen
zu einer logischen Isolation der Mandanten. Durch die
Zuweisung der mandantenspezifischen Objekte zu separaten
Speicherorten (Tablespaces) kann zudem eine physische Trennung
erreicht werden. Das Hinzufu¨gen und Lo¨schen von
Mandanten sowie mandantenspezifische Schemaa¨nderungen bedu¨rfen
bei diesem Ansatz das Absetzen von DDL-Statements, die bei
einigen DBMS zu Problemen mit dem fortlaufenden Betrieb
fu¨hren ko¨nnen. Die hohe Anzahl an Tabellen fu¨hrt zudem
zu einem hohen Hauptspeicherbedarf sowie partiell gefu¨llten
Seiten des Datenbankpuffers. [
Bei dem Ansatz Shared Table werden Objekte der
Datenbank von Mandanten gemeinsam genutzt. Tabellen
enthalten somit Tupel verschiedener Mandanten, weshalb die
Verwendung einer zeilenbasierten Zugriffskontrolle no¨tig ist.
Eine zusa¨tzliche Tabellenspalte legt hierbei die
Zugeho¨rigkeit des Tupels zum entsprechenden Mandanten fest. Durch
den Verzicht auf mandantenspezifische Datenbankobjekte ist
die Gro¨ße des Datenbankkatalogs nahezu unabha¨ngig von
der Mandantenanzahl. Die maximale Anzahl unterstu¨tzter
Mandanten ist somit laut [
Um seinen Service einer mo¨glichst breiten Zielgruppe
anbieten zu ko¨nnen, sind SaaS-Anbieter bemu¨ht, Mandanten
weitreichende Anpassungsmo¨glichkeiten zu bieten. Diese
umfassen laut [
XML: Heutige Datenbankmanagementsysteme bieten zunehmend native Unterstu¨tzung des XML-Datentyps zur Speicherung semistrukturierter Daten. Durch dessen Verwendung ko¨nnen verschiedene mandantenspezifische Schemata innerhalb einer Tabelle verwaltet werden. Hybride Speicherung: Die vorherigen Speicherformen ko¨nnen miteinander verbunden werden, um ihre Sta¨rken zu kombinieren. 2.3
Die in Abschnitt 2.2 vorgestellten Ansa¨tze zur
Unterstu¨tzung individueller Mandantenschemata ko¨nnen bei heutigen
Datenbanksystemen nur mit Hilfe einer u¨berhalb des DBMS
liegenden Schicht zur Transformation der
mandantenspezifischen Datenbankanfragen und vom DBMS erhaltenen
Ergebnisse realisiert werden. Diese Schicht regelt die
Zugriffskontrolle und verwaltet die Schemata der Mandanten, sodass
die Schemainformationen vom DBMS nicht zur
Optimierung genutzt werden ko¨nnen. Zudem fu¨hrt sie zu erho¨hten
Wartungsaufwand und beeinflusst unter Umsta¨nden die
Skalierbarkeit des Systems. [
Bisherige Konzepte und prototypische Implementierungen
[
Ein bisher kaum betrachtetes, jedoch nicht minder bedeutsames Forschungsgebiet im Zusammenhang mit der nativen Unterstu¨tzung von Multi Tenancy in Datenbanksystemen ist die Integration von abgeleiteten Richtlinien aus den Service Level Agreements (SLAs) der Mandanten sowie die Verwaltung der Mandantendaten auf Basis jener Richtlinien. Durch die zentrale Haltung der Richtlinien als Bestandteil des Datenbankkatalogs ko¨nnen sie von verschiedenen DBMSKomponenten und externen Werkzeugen zur Verbesserung der Dienstqualita¨t verwendet werden.
SLO-basiertes Management kann mittels automatisiertem und proaktivem Agieren den Administrationsaufwand fu¨r den SaaS-Anbieter reduzieren. Zudem kann es die Lastverteilung und Migration von Mandanten unterstu¨tzen, um Mandanten stets die Ressourcen zur Verfu¨gung zu stellen, die ihren Anforderungen genu¨gen. Die Priorisierung von Mandanten bei der Verarbeitung ihrer Systemanfragen kann durch eine SLO-basierte Ressourcenverwaltung und -u¨berwachung realisiert werden. Das SLO-basierte Management ist somit ein essentielles Mittel, um auf der einen Seite die Betriebskosten der SaaS-Anbieter durch eine hohe Ressourcenausnutzung gering zu halten und auf der anderen Seite den Mandanten eine mo¨glichst hohe Service-Qualita¨t zu bieten.
Die Einsetzbarkeit in verschiedenen Aufgabenfeldern sowie die damit verbundenen Vorzu¨ge fu¨r Administratoren und Mandanten begru¨nden intensive Forschung in folgenden Themengebieten: • Ableitung von geeigneten mandantenspezifischen Richtlinien aus Dienstleistungsvertra¨gen, • Repra¨sentation der Richtlinien im Katalog des Datenbankverwaltungssystems, • Omnipra¨sentes Monitoring der Einhaltung von Richtlinien, • Entwicklung und Realisierung geeigneter Algorithmen zur Sicherstellung der Richtlinien. 3.1
Als Bestandteil des Dienstleistungsvertrags zwischen dem SaaS-Anbieter und den Mandanten legen Service Level Agreements die zugesicherte Qualita¨t des SaaS-Angebots fest. Hierzu spezifizieren sie beispielsweise Kennzahlen oder Abstufungen bezu¨glich der folgenden Anforderungen an den Services in Form von Richtlinien, welche als Service Level Objects (SLOs) bezeichnet werden.
• Verfu¨gbarkeit: Systemzuga¨nglichkeit, Wartungsfenster,
Wiederherstellungszeiten in Fehlerfa¨llen • Performance: Geschwindigkeit der Datenverarbeitung,
Reaktionszeiten der Schnittstellen
• Sicherheit: Datenschutz, Datensicherheit, Art der
Isolation von anderen Mandanten
Die SLOs sollten u.a. aussagekra¨ftig, erreichbar, messbar und
versta¨ndlich sein [
Abbildung 2: Integration von SLO-basiertem Management ins DBMS SLOs entsprechende Regelungen fu¨r den Fall, dass der SaaSAnbieter die zugesicherten SLOs nicht erfu¨llen kann. In der Regel erfolgt dies u¨ber gestaffelte Strafzahlungen oder lediglich u¨ber die Verminderung der anfallenden Grundgebu¨hren fu¨r Mandanten. 3.2
Nach der Einigung der SaaS-Anbieter und Mandanten u¨ber zu gewa¨hrleistende SLOs und dem Vertragsabschluss erfolgt die U¨berfu¨hrung der finalen Bestimmungen in Anforderungen an die zugrunde liegende Technologie und Hardware des Anbieters. SLOs werden vorrangig technologieunabha¨ngig definiert und gelten in der Folge fu¨r den gesamten Service, weshalb eine ada¨quate Ableitung von mandantenspezifischen Richtlinien fu¨r die einzelnen Systemkomponenten wie dem Datenbanksystem eine bedeutsame und komplexe Aufgabe darstellt. Zudem verdeutlicht dieser Sachverhalt, dass die Einhaltung jener Richtlinien, analog zu Multi Tenancy, in allen Schichten des Gesamtsystems von Bedeutung ist. Mit zunehmender Mandantenkonsolidierung auf den zur Verfu¨gung stehenden Systemressourcen nimmt die Beeinflussung unter Mandanten bezu¨glich der Performance zu, was die Erstellung passender Richtlinien weiter erschwert.
Die resultierenden Richtlinien sollten entsprechend einem
ada¨quaten Modell erstellt werden. Sie bestehen aus einer
Kombination aus Anforderungen, beispielsweise bezu¨glich
der Performance, Verfu¨gbarkeit oder Sicherheit sowie einer
Priorita¨t. Diese spiegelt die Bedeutsamkeit des Mandanten
fu¨r das Unternehmen wider und basiert typischerweise auf
der Gro¨ßenordnung der entsprechenden Vertragsstrafen eines
Mandanten [
Die native Unterstu¨tzung von Multi Tenancy im DBMS
bringt in der Regel eine Katalogerweiterung [
Einige Datenbankverwaltungssysteme bieten mittels
Workload Management die Mo¨glichkeit zur U¨berwachung von
Abfragen und den von ihnen beno¨tigten Ressourcen. IBM
DB2 for Linux, UNIX and Windows stellt hierfu¨r
beispielsweise den DB2 Workload Manager [
Das DBMS muss fortwa¨hrend den Auslastungszustand der
Ressourcen messen und fu¨r das Workload Management
bereitstellen. Abbildung 2 verdeutlicht, mit welchen Komponenten
des DBMS-Kerns der Workload Manager typischerweise
kommuniziert, um die Verarbeitung von Abfragen zu steuern und
zu u¨berwachen [
Abfragen), • Performance Monitor (U¨ berwachung der Verarbeitung von Abfragen), • Resource Monitor (Regelung der Ressourcenallokation der Abfragen).
Die Erweiterung des Datenbankkatalogs um Mandanten
und SLOs stellt dem Datenbankverwaltungssystem die
no¨tigen Mittel zur Verfu¨gung, um neben der korrekten
Ausfu¨hrung nebenla¨ufiger Transaktionen eine auf SLOs basierende
Parallelisierung von Mandanten zu erzielen. Verschiedene
Nutzungsprofile und -zeitra¨ume der Mandanten sowie
u¨bliche Nutzungsschwankungen erlauben eine U¨berbuchung
der zur Verfu¨gung stehenden physischen Systemressourcen
wie der CPU, dem Hauptspeicher oder der Bandbreite zum
Festspeicher. Dies ermo¨glicht eine ausgezeichnete Auslastung
der Ressourcen und ha¨lt somit die operativen Kosten des
SaaS-Anbieters gering. Im (Ausnahme-)Fall hoher
Lastspitzen durch einen parallelen intensiven Zugriff einer Großzahl
von Mandanten, welche die Ressourcen gemeinsam nutzen,
kann die Einhaltung aller offerierten SLOs nicht
gewa¨hrleistet werden. Lastspitzen ko¨nnen aufgrund von regelma¨ßigen
Vorga¨ngen wie Gehaltsbuchungen oder beispielsweise
aufgrund von unvorhergesehenen Nutzungsschwankungen
unregelma¨ßig auftreten [
Ha¨ufig wird in diesen Modellen lediglich die Minimierung von Strafzahlen bezu¨glich der aktuellen U¨berauslastung betrachtet und die Korrelation von Entscheidungen bei verschiedenen Lastspitzen außer Acht gelassen. So ist es mo¨glich, dass die SLOs eines Mandant mit geringer Priorisierung bei Lastspitzen wiederholt nicht erreicht werden ko¨nnen. Aus o¨konomischer Sicht ist dies fu¨r den SaaS-Anbieter augenscheinlich eine optimale Strategie, sie kann jedoch zur Vera¨rgerung oder gar Ku¨ndigung des Mandanten fu¨hren. Folglich gilt es, fru¨here Entscheidungen in die Priorisierung von Mandanten und Ressourcenzuweisung bei Lastspitzen einzubeziehen. Dieses Ziel kann nur mit Hilfe einer dynamischen Priorisierung erreicht werden.
Neben der Ablaufsteuerung und U¨ berwachung von Abfragen sowie dem Eingreifen im Falle einer U¨ berlastung besteht eine wesentliche Aufgabe des SLO-basierten Managements in dem Verhindern von ha¨ufigen U¨berlastungen eines Systems. Hierzu sind die Ressource sowie der Schweregrad, die Ha¨ufigkeit und eine gegebenenfalls existierende Regelma¨ßigkeit der U¨ berlastungen zu beobachten. Durch ein proaktives Vorgehen kann zuku¨nftigen U¨berlastungen vorgebeugt werden, indem Maßnahmen autonom ergriffen werden oder der Administrator in Form von Hinweisen bei seiner Ta¨tigkeit unterstu¨tzt wird. Ein mo¨gliches Vorgehen ist die Zuweisung von Mandanten zu anderen physischen Ressourcen durch das Verschieben auf einen anderen Server mit dem Ziel einer Lastverteilung. 3.4
Ein SaaS-Anwendung sollte die maximale Anzahl an
unterstu¨tzten Mandanten mo¨glichst nicht beschra¨nken. Um
auch bei vielen Mandanten eine ausreichende
Performance zu erreichen, mu¨ssen die Daten der Mandanten mittels
Tabellen- und Indexpartitionierung auf verschiedene
Festspeicher oder gema¨ß eines verteilten Datenbanksystems auf
verschiedene Datenbankknoten verteilt werden. Die
Verteilung der Mandanten durch einen Load Balancer kann zudem
gema¨ß Abschnitt 3.3 zur Abfederung von Lastspitzen genutzt
werden. Entgegen statischer Ansa¨tze [
Um unno¨tige Kommunikation zwischen Datenbankknoten zu vermeiden, sind die Daten eines Mandanten nicht u¨ber mehrere Knoten zu verteilen. Dies sollte nur mo¨glich sein, wenn die Anforderungen des Mandanten die zur Verfu¨gung stehenden Ressourcen des Rechners u¨bersteigen.
Die Mandanten legen durch die Nutzung einer
SaaS-Anwendung ihre Daten in die Ha¨nde des Anbieters und dessen
auf Sicherheit spezialisierte IT-Abteilung [
Kosten
Mögliche
Zielstellung Performance
Verfügbarkeit Abbildung 3: Zielkonflikte des SaaS-Anbieters Verfu¨gbarkeit besitzt gema¨ß Abschnitt 3.1 eine außerordentliche Bedeutsamkeit bei Dienstleistungsvertra¨gen im SaaS-Umfeld. Ist der Dienst fu¨r die Mandanten nicht erreichbar, so kann dies schwerwiegende Folgen haben, die von einer Verzo¨gerung der Arbeitsprozesse bei Mandanten bis hin zu finanziellen Einbußen reichen. Entsprechend werden in den Dienstleistungsvertra¨gen nur geringe (geplante und ungeplante) Ausfallzeiten des Services zugelassen, bei deren Verletzung der SaaS-Anbieter mit erheblichen Strafzahlungen rechnen muss. Entsprechend liegt es im Interesse des Anbieters, eine hohe Verfu¨gbarkeit des Dienstes sicherzustellen. Abbildung 3 verdeutlicht, dass die Erreichung eines hohen Verfu¨gbarkeitsniveaus auf der einen Seite zu zusa¨tzlichen Kosten fu¨r den Anbieter fu¨hrt und auf der anderen Seite die Performance des Services einschra¨nkt. Eine hohe Verfu¨gbarkeit fordert das Vermeiden von Single Points of Failures und kann beispielsweise durch verschiedene Formen der Replikation erreicht werden. Der SaaS-Anbieter ko¨nnte durch einen Replication Manager die Art und den Umfang der Replikation von Mandantendaten aufgrund von verschiedenen SLOs der Mandanten variieren, um individuelle Anforderungen zu unterstu¨tzen. 3.5
Die Verwendung von Datenbanksystemen zur
Datenverwaltung einer SaaS-Anwendung stellt nur eine Mo¨glichkeit
zur Bereitstellung von Datenbanksystemen als Dienst
innerhalb einer Cloud dar, was als Database as a Service (kurz
DaaS oder DbaaS [
• Mandanten in einer SaaS-Anwendung besitzen und erweitern ein gemeinsames Basisschema und greifen zudem in der Regel lesend auf gemeinsame Anwendungsdaten zu. Bei anderen DaaS-Dienstmodellen existieren meist keine mandantenu¨bergreifenden Daten und keine oder vernachla¨ssigbare A¨ hnlichkeit der Datenbankschemata von Mandanten. Dies wirkt sich auf die Konsolidierungsmo¨glichkeiten innerhalb einer Datenbank aus. • SaaS-Anwendungen bestimmen die Art der Workload fu¨r das verwendete Datenbanksystem, was sich das SLO-basiertes Management zu Nutze machen kann. Bei anderen DaaS-Dienstmodellen ist die Workload hingegen mandantenspezifisch und unvorhersehbar. • SLOs sind bei SaaS-Angeboten mit der kompletten Anwendung verknu¨pft, wa¨hrend bei anderen DaaS-Dienstmodellen meist konkrete Vorgaben fu¨r das DBMS definiert sind.
Diese Punkte verdeutlichen, dass Ergebnisse aktueller
Forschung im Bereich SLO-basierter Hardware-Provisionierung
und Steuerung der Abfrageverarbeitung fu¨r DaaS [
In diesem Beitrag wurde gezeigt, dass eine Integration von Service Level Objects in ein Multi-Tenancy-Datenbanksystem in Form einer Erweiterung des Datenbankkatalogs von verschiedenen DBMS-Komponenten verwendet werden kann, um die U¨berwachung der SLOs wa¨hrend des Betriebs zu gewa¨hrleisten. Als mo¨gliche Verwendungsbeispiele wurden das Workload Management, die Lastverteilung und eine individuelle Replikationssteuerung aufgefu¨hrt.
In den weiteren Arbeiten soll der Entwurf der SLO-Integration konkretisiert, verschiedene Implementierungsvarianten verglichen und die Realisierbarkeit anhand eines Prototyps gezeigt werden. Anschließende Performance-Tests sollen Aufschluss daru¨ber geben, ob der zusa¨tzliche Overhead durch die mandantenspezifischen Metadaten und das SLO-basierte Management die Skalierbarkeit und den laufenden Betrieb des Datenbanksystems beeintra¨chtigen.