=Paper=
{{Paper
|id=None
|storemode=property
|title=SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
|pdfUrl=https://ceur-ws.org/Vol-850/paper_goebel.pdf
|volume=Vol-850
|dblpUrl=https://dblp.org/rec/conf/gvd/Gobel12
}}
==SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung==
https://ceur-ws.org/Vol-850/paper_goebel.pdf
SLO-basiertes Management in relationalen
Datenbanksystemen mit nativer
Multi-Tenancy-Unterstützung
Andreas Göbel
Lehrstuhl für Datenbanken und Informationssysteme
Fakultät für Mathematik und Informatik
Friedrich-Schiller-Universität Jena
Ernst-Abbe-Platz 2, 07743 Jena
andreas.goebel@uni-jena.de
KURZFASSUNG 1. EINLEITUNG
Das an Bedeutung und Akzeptanz gewinnende Geschäfts- Software as a Service (SaaS) bezeichnet ein Geschäftsmo-
modell Software as a Service ermöglicht Unternehmen die dell, bei dem Unternehmen von einem Drittanbieter Anwen-
Konzentration auf ihr Kerngeschäft durch das Beziehen von dungen in Form von Services über das Internet beziehen.
Dienstleistungen über das Internet. Die Festlegung von Ser- Der Ansatz steht dem herkömmlichen On-Premise-Modell
vice Level Agreements gewährleistet eine hohe Qualität des gegenüber, bei dem Unternehmen die Lizenzen für Software
Dienstes. Um die operationalen Kosten des Service Providers käuflich erwerben und die Anwendungen anschließend auf
gering zu halten, bedarf es des Einsatzes einer Multi-Tenancy- eigener Hardware betreiben. Durch das Betreiben und War-
Architektur, die zu neuen Herausforderungen für den Einsatz ten der Anwendung sowie der notwendigen Hardware durch
von Datenbankverwaltungssystemen führt. den Drittanbieter (SaaS-Anbieter) können die als Mandanten
In diesem Beitrag werden die Problemstellungen der Rea- bezeichneten Unternehmen auf den Erwerb und die Wartung
lisierung von Multi Tenancy in heutigen Datenbankverwal- der Hardware verzichten. Service Level Agreements (SLAs)
tungssystemen aufgezeigt und eine native Unterstützung legen dabei als Bestandteil der Dienstleistungsverträge durch
von Multi Tenancy in jenen Systemen motiviert. Es wird die Definition verschiedener Service Level Objects (SLOs)
hervorgehoben, dass die Integration von mandantenspezi- die Qualität der Services fest.
fischen Service Level Agreements zur Steigerung der Qua- Laut Studien renommierter Marktanalyseunternehmen
lität des Dienstes beiträgt. Hierzu wird die Verwendung wird die Bedeutung von SaaS in den nächsten Jahren wei-
dieser bereitgestellten Daten zur Ressourcenverwaltung und ter zunehmen. So prognostiziert Pierre Audoin Consultants
-überwachung sowie der Lastverteilung von Mandanten ver- SaaS für das Jahr 2015 einen Umsatzanteil am Software-
deutlicht. Markt in Höhe von zehn Prozent und begründet die zu-
nehmende Bedeutung u.a. mit entsprechenden Anpassungen
Kategorien und Themenbeschreibung der Produktportfolios sowie Akquisitionen von bedeutenden
Software-Anbietern wie Oracle, SAP und Microsoft [18].
H.2.7 [Database Management]: Database Administrati- SaaS-Angebote sind aktuell insbesondere in den Bereichen
on—Data dictionary/directory; H.2.1 [Database Manage- E-Commerce, Kundenbeziehungsmanagement und bei kolla-
ment]: Logical Design—Schema and subschema borativen Aufgaben wie E-Mail zu finden. Zunehmend werden
Produkte in den Bereichen Humankapital-Management und
Allgemeine Begriffe Unternehmensressourcenplanung angeboten. Um einen mög-
lichst großen Markt ansprechen zu können, ermöglichen SaaS-
Design, Management, Measurement
Anbieter eine individuelle Anpassung des Services. Die Ange-
bote richten sich auch an kleine und mittlere Unternehmen
Stichworte (KMU), denen aufgrund begrenzter finanzieller Möglichkeiten
Relational Database, Multi Tenancy, Service Level Agree- die Mittel für den Erwerb und Support einer vergleichbaren
ment On-Premise-Lösung fehlen. Dieser so genannte Long Tail [3]
kann durch Preisvorteile gegenüber On-Premise-Angeboten
und entfallende Kosten der Mandanten für die Beschaffung
und Wartung von Hardware bedient werden [10]. Es bedarf
hierzu einer hohen Wirtschaftlichkeit des Services durch eine
Konsolidierung von Mandanten auf physischen Ressourcen
in Form von Multi-Tenancy-Anwendungen.
2. MULTI TENANCY
Die Architektur von SaaS-Angeboten ist in großem Ma-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. ße vom Geschäftsmodell des Anbieters abhängig. Sie wird
Copyright is held by the author/owner(s). beispielsweise beeinflusst durch das zur Verfügung stehende
Virtuelle Betriebssys- Datenbank- Schema /
Isolation Hardware Datenbank Zeile
Maschine temnutzer instanz Tablespace
niedrig Komplexität, Ressourcenausnutzung, max. Mandantenanzahl, Skalierbarkeit hoch
Bewertung
hoch Kosten je Mandant, Sicherheit, Wartungsaufwand niedrig
Abbildung 1: Ansätze zur Mandantenisolation im DB-Layer, angelehnt an [19]
Entwicklungskapital, den Zielmarkt sowie die Anzahl und ten sowie mandantenspezifische Schemaänderungen bedürfen
Charakteristika der Mandanten. Zu den Charakteristika ge- bei diesem Ansatz das Absetzen von DDL-Statements, die bei
hören u.a. die benötigte Datenmenge, die voraussichtliche einigen DBMS zu Problemen mit dem fortlaufenden Betrieb
Workload und die Anforderungen der Mandanten bezüglich führen können. Die hohe Anzahl an Tabellen führt zudem
Verfügbarkeit, Performance, Datenisolation und Individuali- zu einem hohen Hauptspeicherbedarf sowie partiell gefüllten
sierung der Anwendung. Seiten des Datenbankpuffers. [6, 12]
Um die in der Einleitung motivierte hohe Wirtschaft- Bei dem Ansatz Shared Table werden Objekte der Da-
lichkeit eines SaaS-Angebots zu erzielen, werden vermehrt tenbank von Mandanten gemeinsam genutzt. Tabellen ent-
Multi-Tenancy-Architekturen eingesetzt. Diese erlauben allen halten somit Tupel verschiedener Mandanten, weshalb die
Service-Nutzern die gemeinsame Verwendung von Hardware- Verwendung einer zeilenbasierten Zugriffskontrolle nötig ist.
Ressourcen durch das Anbieten einer gemeinsamen Anwen- Eine zusätzliche Tabellenspalte legt hierbei die Zugehörig-
dungsinstanz [9]. Sowohl auf der Applikations- als auch der keit des Tupels zum entsprechenden Mandanten fest. Durch
Datenbankseite sind verschiedene Ansätze zur Separierung den Verzicht auf mandantenspezifische Datenbankobjekte ist
von Mandanten denkbar. die Größe des Datenbankkatalogs nahezu unabhängig von
der Mandantenanzahl. Die maximale Anzahl unterstützter
2.1 Multi Tenancy in DBMS Mandanten ist somit laut [12] lediglich durch die maxima-
Es existiert ein breites Realisierungspektrum für Multi le Anzahl unterstützter Tabellenzeilen beschränkt, was den
Tenancy in einem Datenbankserver. In Abbildung 1 werden Ansatz für das Bedienen des im Abschnitt 1 angesprochenen
die wichtigsten Ansätze zusammengefasst sowie Vorteile und Long Tails prädestiniert. Durch die hohe Ressourcenaus-
Herausforderungen aufgezeigt. Neben der Möglichkeit, auf nutzung reduziert sich der Overhead bezüglich Fest- und
eine Mandantenkonsolidierung zu verzichten (Separate Hard- Hauptspeicherbedarf pro Mandant auf ein Minimum. Admi-
ware), können Mandanten beispielsweise durch die Zuweisung nistrative Operationen und Updates der Anwendung werden
separater virtueller Maschinen (Shared HW ), durch die Nut- bei diesem Ansatz in der Regel für alle Mandanten ausge-
zerverwaltung des Betriebssystems (Shared VM ) oder durch führt, was den Wartungsaufwand des Anbieters reduziert,
die Verwendung getrennter Datenbankinstanzen (Shared OS die Individualität des Services jedoch einschränkt. So können
Level ) bzw. Datenbanken (Shared DB Instance) voneinander die in [11] angesprochenen individuellen Anforderungen von
isoliert und dennoch auf einem Datenbankserver verwaltet Mandanten in Bezug auf Aspekte der Datenbankadministra-
werden. Aufgrund des initialen Ressourcenbedarfs und der tion und -konfiguration wie Backup-Strategien und Archi-
gesonderten Administration dedizierter Datenbanken, Daten- vierungsintervalle, die Replikationsart und Replikatanzahl
bankinstanzen, Betriebssysteme oder virtueller Maschinen oder Vorgaben zur Arbeitsweise des Datenbankoptimierers
führen diese Ansätze für den SasS-Anbieter zu hohen Kosten nicht erfüllt werden. Aufgrund der Konsolidierung von vielen
je Mandant. Sie sollten daher nur bei zwingender Notwendig- Mandantendaten innerhalb einer Tabelle liegen die größten
keit eines hohen Isolations- bzw. Sicherheitslevels oder bei Herausforderungen dieses Ansatzes in der Gewährleistung
einer geringen Anzahl von Mandanten verwendet werden. der Isolation der Mandantendaten und -Performance sowie
Der Ansatz Shared Database erlaubt durch die Mandanten- der Erarbeitung eines Datenbankschemas, welches den Man-
konsolidierung in einer Datenbank die gemeinsame Nutzung danten die Anpassung der vom SaaS-Anbieter zur Verfügung
von Datenbankprozessen und Hauptspeicherinhalten. Die gestellten Anwendungen erlaubt.
Zuweisung zu eigenen Datenbankobjekten wie Tabellen und
Indizes führt bei Nutzung der Datenbankzugriffskontrollen 2.2 Schemaflexibilität
zu einer logischen Isolation der Mandanten. Durch die Zuwei- Um seinen Service einer möglichst breiten Zielgruppe an-
sung der mandantenspezifischen Objekte zu separaten Spei- bieten zu können, sind SaaS-Anbieter bemüht, Mandanten
cherorten (Tablespaces) kann zudem eine physische Trennung weitreichende Anpassungsmöglichkeiten zu bieten. Diese um-
erreicht werden. Das Hinzufügen und Löschen von Mandan- fassen laut [10] unter anderem eine Anpassung der Benutzer-
oberfläche im Sinne eines Corporate Identity, die Anpassung paralleler Basisschema-Versionen einen verzögerten Wech-
an Geschäftsabläufe durch Modifikation von Geschäftsregeln, sel auf eine neue Version der SaaS-Applikation und dessen
individuelle Regelungen bezüglich der Zugangskontrollen so- Erweiterungen erlaubt.
wie die Möglichkeit zur Erweiterung des Datenbankschemas
durch zusätzliche Tabellenspalten oder komplette Tabellen. 3. SLO-BASIERTE VERWALTUNG
Diese Anforderung stellt sich aufgrund des notwendigen Zu-
sammenführens individueller Datenbankschemata der Man- Ein bisher kaum betrachtetes, jedoch nicht minder bedeut-
danten auf ein Gesamtschema der Datenbank insbesondere sames Forschungsgebiet im Zusammenhang mit der nativen
beim Ansatz Shared Table als Herausforderung dar. Aulbach Unterstützung von Multi Tenancy in Datenbanksystemen
et al. stellen in [4, 5] eine Reihe von Ansätzen vor, die in ist die Integration von abgeleiteten Richtlinien aus den Ser-
folgende Kategorien eingeteilt werden können: vice Level Agreements (SLAs) der Mandanten sowie die
Verwaltung der Mandantendaten auf Basis jener Richtlinien.
Vertikale Speicherung: Dieser Ansatz basiert auf dem Durch die zentrale Haltung der Richtlinien als Bestandteil
Entity-Attribute-Value-Modell [17], welches beispiels- des Datenbankkatalogs können sie von verschiedenen DBMS-
weise im medizinischen Bereich Anwendung findet. Je- Komponenten und externen Werkzeugen zur Verbesserung
der Attributwert eines mandantenspezifischen Daten- der Dienstqualität verwendet werden.
satzes wird auf einen Datensatz des Gesamtschemas SLO-basiertes Management kann mittels automatisiertem
abgebildet, der zur Identifizierung neben dem Attri- und proaktivem Agieren den Administrationsaufwand für den
butwert den zugehörigen Mandanten-, Tabellen- und SaaS-Anbieter reduzieren. Zudem kann es die Lastverteilung
Spaltenname sowie die Zeilennummer enthält. Ein man- und Migration von Mandanten unterstützen, um Mandan-
dantenspezifischer Datensatz muss hierbei zur Laufzeit ten stets die Ressourcen zur Verfügung zu stellen, die ihren
durch Verbundoperationen erzeugt werden, um die At- Anforderungen genügen. Die Priorisierung von Mandanten
tributwerte zu einem Datensatz zusammenzufügen. bei der Verarbeitung ihrer Systemanfragen kann durch eine
SLO-basierte Ressourcenverwaltung und -überwachung rea-
Horizontale Speicherung: Ein mandantenspezifischer Da- lisiert werden. Das SLO-basierte Management ist somit ein
tensatz wird direkt auf Datensätze des Gesamtschemas essentielles Mittel, um auf der einen Seite die Betriebskosten
abgebildet. Flexibilität kann beispielsweise durch die der SaaS-Anbieter durch eine hohe Ressourcenausnutzung
Nutzung einer universellen Tabelle geboten werden, gering zu halten und auf der anderen Seite den Mandanten
welche durch eine Vielzahl von generischen Spalten mit eine möglichst hohe Service-Qualität zu bieten.
flexiblen Datentypen die Speicherung beliebiger Daten- Die Einsetzbarkeit in verschiedenen Aufgabenfeldern so-
sätze erlaubt und die Verwaltung des Schemas in die wie die damit verbundenen Vorzüge für Administratoren
Anwendung verschiebt. und Mandanten begründen intensive Forschung in folgenden
XML: Heutige Datenbankmanagementsysteme bieten zu- Themengebieten:
nehmend native Unterstützung des XML-Datentyps zur
• Ableitung von geeigneten mandantenspezifischen Richt-
Speicherung semistrukturierter Daten. Durch dessen
linien aus Dienstleistungsverträgen,
Verwendung können verschiedene mandantenspezifische
Schemata innerhalb einer Tabelle verwaltet werden. • Repräsentation der Richtlinien im Katalog des Daten-
bankverwaltungssystems,
Hybride Speicherung: Die vorherigen Speicherformen kön-
nen miteinander verbunden werden, um ihre Stärken • Omnipräsentes Monitoring der Einhaltung von Richtli-
zu kombinieren. nien,
2.3 Native Unterstützung durch DBMS • Entwicklung und Realisierung geeigneter Algorithmen
Die in Abschnitt 2.2 vorgestellten Ansätze zur Unterstüt- zur Sicherstellung der Richtlinien.
zung individueller Mandantenschemata können bei heutigen
Datenbanksystemen nur mit Hilfe einer überhalb des DBMS 3.1 Service Level Objects
liegenden Schicht zur Transformation der mandantenspe- Als Bestandteil des Dienstleistungsvertrags zwischen dem
zifischen Datenbankanfragen und vom DBMS erhaltenen SaaS-Anbieter und den Mandanten legen Service Level Agree-
Ergebnisse realisiert werden. Diese Schicht regelt die Zugriffs- ments die zugesicherte Qualität des SaaS-Angebots fest. Hier-
kontrolle und verwaltet die Schemata der Mandanten, sodass zu spezifizieren sie beispielsweise Kennzahlen oder Abstufun-
die Schemainformationen vom DBMS nicht zur Optimie- gen bezüglich der folgenden Anforderungen an den Services
rung genutzt werden können. Zudem führt sie zu erhöhten in Form von Richtlinien, welche als Service Level Objects
Wartungsaufwand und beeinflusst unter Umständen die Ska- (SLOs) bezeichnet werden.
lierbarkeit des Systems. [6, 20]
Bisherige Konzepte und prototypische Implementierungen • Verfügbarkeit: Systemzugänglichkeit, Wartungsfenster,
[6, 20] zur nativen Unterstützung von Mandanten in rela- Wiederherstellungszeiten in Fehlerfällen
tionalen Datenbanksystemen verlagern im Wesentlichen die
• Performance: Geschwindigkeit der Datenverarbeitung,
Transformationsschicht inklusive der benötigten Metadaten
Reaktionszeiten der Schnittstellen
ins Datenbanksystem. Sie verfolgen hiermit das Ziel einer
effizienten Mandantenkonsolidierung sowie der Abbildung • Sicherheit: Datenschutz, Datensicherheit, Art der Iso-
mandantenspezifischer Schemata auf ein Gesamtschema, um lation von anderen Mandanten
die oben aufgezeigten Nachteile einer externen Transformati-
on anzugehen. Des Weiteren wird in [7] ein Konzept vorge- Die SLOs sollten u.a. aussagekräftig, erreichbar, messbar und
stellt, welches Mandanten durch die Unterstützung mehrerer verständlich sein [22]. Bestandteil der SLAs sind neben den
DBMS
DBMS Core
Tenant Query
SaaS-Workload
Assignment Transformation
Execution Engine
SLO-based Management Performance
Data Dictionary Monitor
Extension
Workload Manager
Tenants
Resource Manager
SLOs
Load Balancer
Replication
Manager
Abbildung 2: Integration von SLO-basiertem Management ins DBMS
SLOs entsprechende Regelungen für den Fall, dass der SaaS- wiederum einer Erweiterung des Katalogs um die SLOs jedes
Anbieter die zugesicherten SLOs nicht erfüllen kann. In der Mandanten sowie seiner zugewiesenen Bedeutsamkeit bzw.
Regel erfolgt dies über gestaffelte Strafzahlungen oder ledig- Priorität. Durch die Zuordnung eines Mandanten zu einer
lich über die Verminderung der anfallenden Grundgebühren SLO-Kategorie wie ’Standard’, ’Premium’ oder ’Individuell’
für Mandanten. kann bei der SLO-Zuweisung der Overhead bezüglich des
Fest- und Hauptspeicherbedarfs je Mandant reduziert werden.
3.2 SLO-Repräsentation Abbildung 2 verdeutlicht diese Erweiterung und kennzeichnet,
Nach der Einigung der SaaS-Anbieter und Mandanten über dass Katalogerweiterungen beispielsweise für die Zuweisung
zu gewährleistende SLOs und dem Vertragsabschluss erfolgt von Mandanten zu Anfragen (Tenant Assignment) und die
die Überführung der finalen Bestimmungen in Anforderun- in Abschnitt 2.3 angesprochene Transformationskomponente
gen an die zugrunde liegende Technologie und Hardware des (Query Transformation) benötigt wird.
Anbieters. SLOs werden vorrangig technologieunabhängig
definiert und gelten in der Folge für den gesamten Service,
3.3 Workload Management
weshalb eine adäquate Ableitung von mandantenspezifischen Einige Datenbankverwaltungssysteme bieten mittels Work-
Richtlinien für die einzelnen Systemkomponenten wie dem load Management die Möglichkeit zur Überwachung von
Datenbanksystem eine bedeutsame und komplexe Aufgabe Abfragen und den von ihnen benötigten Ressourcen. IBM
darstellt. Zudem verdeutlicht dieser Sachverhalt, dass die DB2 for Linux, UNIX and Windows stellt hierfür beispiels-
Einhaltung jener Richtlinien, analog zu Multi Tenancy, in weise den DB2 Workload Manager [1] und Oracle den Oracle
allen Schichten des Gesamtsystems von Bedeutung ist. Mit Database Resource Manager und Oracle Scheduler [2] bereit.
zunehmender Mandantenkonsolidierung auf den zur Verfü- Diese Anwendungen bieten ein breites Spektrum an Mitteln
gung stehenden Systemressourcen nimmt die Beeinflussung zur Überwachung von Anfragen, welches u.a. das Aufteilen
unter Mandanten bezüglich der Performance zu, was die von Systemressourcen zwischen Abfragen, die Priorisierung,
Erstellung passender Richtlinien weiter erschwert. Ab- und Unterbrechung von Abfragen sowie eine Zeitplanung
Die resultierenden Richtlinien sollten entsprechend einem von Abfragen enthalten kann.
adäquaten Modell erstellt werden. Sie bestehen aus einer Das DBMS muss fortwährend den Auslastungszustand der
Kombination aus Anforderungen, beispielsweise bezüglich Ressourcen messen und für das Workload Management bereit-
der Performance, Verfügbarkeit oder Sicherheit sowie einer stellen. Abbildung 2 verdeutlicht, mit welchen Komponenten
Priorität. Diese spiegelt die Bedeutsamkeit des Mandanten des DBMS-Kerns der Workload Manager typischerweise kom-
für das Unternehmen wider und basiert typischerweise auf muniziert, um die Verarbeitung von Abfragen zu steuern und
der Größenordnung der entsprechenden Vertragsstrafen eines zu überwachen [14]:
Mandanten [14]. Unter Umständen können hierbei jedoch • Execution Engine (Verwaltung der Ausführung von
Aspekte eine Rolle spielen, die nicht direkt aus dem Dienst- Abfragen),
leistungsvertrag abgeleitet werden können wie die Reputation
des Mandanten oder seine Bedeutung als strategischer Part- • Performance Monitor (Überwachung der Verarbeitung
ner des SaaS-Anbieters. von Abfragen),
Die native Unterstützung von Multi Tenancy im DBMS
• Resource Monitor (Regelung der Ressourcenallokation
bringt in der Regel eine Katalogerweiterung [20] um Tabellen
der Abfragen).
zur Repräsentation der Mandanten und der zugehörigen
Datenbankobjekte wie Tabellen oder Indizes mit sich. Die Die Erweiterung des Datenbankkatalogs um Mandanten
Definition und anschließende Überwachung der SLOs bedarf und SLOs stellt dem Datenbankverwaltungssystem die nöti-
gen Mittel zur Verfügung, um neben der korrekten Ausfüh- lung der Mandanten durch einen Load Balancer kann zudem
rung nebenläufiger Transaktionen eine auf SLOs basierende gemäß Abschnitt 3.3 zur Abfederung von Lastspitzen genutzt
Parallelisierung von Mandanten zu erzielen. Verschiedene werden. Entgegen statischer Ansätze [15] zur Berechnung
Nutzungsprofile und -zeiträume der Mandanten sowie üb- einer optimalen Verteilung von Mandantendaten auf eine
liche Nutzungsschwankungen erlauben eine Überbuchung Menge von Datenbankknoten sollte die Lastverteilung analog
der zur Verfügung stehenden physischen Systemressourcen zum Workflow Management dynamisch agieren.
wie der CPU, dem Hauptspeicher oder der Bandbreite zum Um unnötige Kommunikation zwischen Datenbankknoten
Festspeicher. Dies ermöglicht eine ausgezeichnete Auslastung zu vermeiden, sind die Daten eines Mandanten nicht über
der Ressourcen und hält somit die operativen Kosten des mehrere Knoten zu verteilen. Dies sollte nur möglich sein,
SaaS-Anbieters gering. Im (Ausnahme-)Fall hoher Lastspit- wenn die Anforderungen des Mandanten die zur Verfügung
zen durch einen parallelen intensiven Zugriff einer Großzahl stehenden Ressourcen des Rechners übersteigen.
von Mandanten, welche die Ressourcen gemeinsam nutzen, Die Mandanten legen durch die Nutzung einer SaaS-An-
kann die Einhaltung aller offerierten SLOs nicht gewährleis- wendung ihre Daten in die Hände des Anbieters und dessen
tet werden. Lastspitzen können aufgrund von regelmäßigen auf Sicherheit spezialisierte IT-Abteilung [11]. Durch die Ver-
Vorgängen wie Gehaltsbuchungen oder beispielsweise auf- teilung von Mandanten auf verschiedene Rechner ist neben
grund von unvorhergesehenen Nutzungsschwankungen unre- dem verringerten Einfluss der Mandanten bezüglich ihrer Per-
gelmäßig auftreten [6]. Um die Häufigkeit dieser Situation zu formance (Performance-Isolation zwischen Mandanten [8])
reduzieren und beim Auftreten adäquat zu reagieren, bedarf ein höherer Isolationsgrad der auf dem Festspeicher abgeleg-
es geeigneter Strategien zur Ablaufplanung der Abfragen ten Mandantendaten erreichbar bis hin zu einer physischen
sowie der Ressourcenzuteilung. Aus ökonomischer Sicht des Isolation. Der Isolationsgrad spiegelt sich zum Teil in ent-
Anbieters gilt es hierbei, die Summe der zu zahlenden Ver- sprechenden SLOs der Dienstverträge wider. Er kann durch
tragsstrafen zu minimieren. In [13] wird dieses Ziel durch die in Abbildung 2 dargestellte SLO-Katalogerweiterung im
einen dynamischen Controller und der Zuhilfenahme zwei- DBMS hinterlegt und vom Lastbalancierer bei der Verteilung
er Kostenfunktionen verfolgt, womit zudem eine dauerhafte der Mandanten auf Rechner berücksichtigt werden.
Übererfüllung der SLOs von Mandanten mit hoher Priorität
auf Kosten von Mandanten mit geringer Priorität vermieden Kosten
wird.
Häufig wird in diesen Modellen lediglich die Minimierung Mögliche
von Strafzahlen bezüglich der aktuellen Überauslastung be- Zielstellung
trachtet und die Korrelation von Entscheidungen bei verschie-
denen Lastspitzen außer Acht gelassen. So ist es möglich, dass
die SLOs eines Mandant mit geringer Priorisierung bei Last-
spitzen wiederholt nicht erreicht werden können. Aus ökono- Performance Verfügbarkeit
mischer Sicht ist dies für den SaaS-Anbieter augenscheinlich
eine optimale Strategie, sie kann jedoch zur Verärgerung Abbildung 3: Zielkonflikte des SaaS-Anbieters
oder gar Kündigung des Mandanten führen. Folglich gilt es,
frühere Entscheidungen in die Priorisierung von Mandanten
Verfügbarkeit besitzt gemäß Abschnitt 3.1 eine außeror-
und Ressourcenzuweisung bei Lastspitzen einzubeziehen. Die-
dentliche Bedeutsamkeit bei Dienstleistungsverträgen im
ses Ziel kann nur mit Hilfe einer dynamischen Priorisierung
SaaS-Umfeld. Ist der Dienst für die Mandanten nicht er-
erreicht werden.
reichbar, so kann dies schwerwiegende Folgen haben, die von
Neben der Ablaufsteuerung und Überwachung von Abfra-
einer Verzögerung der Arbeitsprozesse bei Mandanten bis
gen sowie dem Eingreifen im Falle einer Überlastung besteht
hin zu finanziellen Einbußen reichen. Entsprechend werden
eine wesentliche Aufgabe des SLO-basierten Managements
in den Dienstleistungsverträgen nur geringe (geplante und
in dem Verhindern von häufigen Überlastungen eines Sys-
ungeplante) Ausfallzeiten des Services zugelassen, bei deren
tems. Hierzu sind die Ressource sowie der Schweregrad, die
Verletzung der SaaS-Anbieter mit erheblichen Strafzahlungen
Häufigkeit und eine gegebenenfalls existierende Regelmäßig-
rechnen muss. Entsprechend liegt es im Interesse des An-
keit der Überlastungen zu beobachten. Durch ein proaktives
bieters, eine hohe Verfügbarkeit des Dienstes sicherzustellen.
Vorgehen kann zukünftigen Überlastungen vorgebeugt wer-
Abbildung 3 verdeutlicht, dass die Erreichung eines hohen
den, indem Maßnahmen autonom ergriffen werden oder der
Verfügbarkeitsniveaus auf der einen Seite zu zusätzlichen
Administrator in Form von Hinweisen bei seiner Tätigkeit
Kosten für den Anbieter führt und auf der anderen Seite die
unterstützt wird. Ein mögliches Vorgehen ist die Zuweisung
Performance des Services einschränkt. Eine hohe Verfügbar-
von Mandanten zu anderen physischen Ressourcen durch
keit fordert das Vermeiden von Single Points of Failures und
das Verschieben auf einen anderen Server mit dem Ziel einer
kann beispielsweise durch verschiedene Formen der Replika-
Lastverteilung.
tion erreicht werden. Der SaaS-Anbieter könnte durch einen
Replication Manager die Art und den Umfang der Replikati-
3.4 Verteilung von Mandantendaten on von Mandantendaten aufgrund von verschiedenen SLOs
Ein SaaS-Anwendung sollte die maximale Anzahl an un- der Mandanten variieren, um individuelle Anforderungen zu
terstützten Mandanten möglichst nicht beschränken. Um unterstützen.
auch bei vielen Mandanten eine ausreichende Performan-
ce zu erreichen, müssen die Daten der Mandanten mittels 3.5 SLA-Management in DaaS
Tabellen- und Indexpartitionierung auf verschiedene Fest- Die Verwendung von Datenbanksystemen zur Datenver-
speicher oder gemäß eines verteilten Datenbanksystems auf waltung einer SaaS-Anwendung stellt nur eine Möglichkeit
verschiedene Datenbankknoten verteilt werden. Die Vertei- zur Bereitstellung von Datenbanksystemen als Dienst inner-
halb einer Cloud dar, was als Database as a Service (kurz [3] C. Anderson. The Long Tail: Why the Future of
DaaS oder DbaaS [21]) betitelt wird. Sowohl in kommerziel- Business Is Selling Less of More. Hyperion, 2006.
len DaaS-Angeboten als auch in der DaaS-Forschung spielt [4] S. Aulbach, T. Grust, D. Jacobs, A. Kemper, and
Multi Tenancy eine bedeutende Rolle, um die operationalen J. Rittinger. Multi-tenant databases for software as a
Kosten von DaaS-Anbietern zu senken. Die Bereitstellung service: schema-mapping techniques. In SIGMOD,
von Daten für eine SaaS-Anwendung unterscheidet sich je- pages 1195–1206. ACM, 2008.
doch im Zusammenhang mit Multi Tenancy erheblich von [5] S. Aulbach, D. Jacobs, A. Kemper, and M. Seibold. A
anderen Dienstmodellen. comparison of flexible schemas for software as a service.
In SIGMOD, pages 881–888. ACM, 2009.
• Mandanten in einer SaaS-Anwendung besitzen und
[6] S. Aulbach, D. Jacobs, J. Primsch, and A. Kemper.
erweitern ein gemeinsames Basisschema und greifen zu-
Anforderungen an Datenbanksysteme für
dem in der Regel lesend auf gemeinsame Anwendungs-
Multi-Tenancy- und Software-as-a-Service-
daten zu. Bei anderen DaaS-Dienstmodellen existieren
Applikationen. In BTW, pages 544–555. GI, 2009.
meist keine mandantenübergreifenden Daten und keine
oder vernachlässigbare Ähnlichkeit der Datenbanksche- [7] S. Aulbach, M. Seibold, D. Jacobs, and A. Kemper.
mata von Mandanten. Dies wirkt sich auf die Kon- Extensibility and Data Sharing in evolving multi-tenant
solidierungsmöglichkeiten innerhalb einer Datenbank databases. In ICDE, pages 99–110, 2011.
aus. [8] D. Banks, J. Erickson, M. Rhodes, and J. S. Erickson.
Multi-tenancy in Cloud-based Collaboration Services.
• SaaS-Anwendungen bestimmen die Art der Workload Information Systems Journal, 2009.
für das verwendete Datenbanksystem, was sich das [9] C.-P. Bezemer, A. Zaidman, B. Platzbeecker,
SLO-basiertes Management zu Nutze machen kann. T. Hurkmans, and A. ’t Hart. Enabling multi-tenancy:
Bei anderen DaaS-Dienstmodellen ist die Workload An industrial experience report. In ICSM, pages 1–8,
hingegen mandantenspezifisch und unvorhersehbar. 2010.
[10] F. Chong and G. Carraro. Architecture Strategies for
• SLOs sind bei SaaS-Angeboten mit der kompletten An- Catching the Long Tail. 2006.
wendung verknüpft, während bei anderen DaaS-Dienst- [11] A. Göbel. Anforderungen von Cloud-Anwendungen an
modellen meist konkrete Vorgaben für das DBMS defi- Datenbanksysteme. In Workshop Database as a Service,
niert sind. 2010.
[12] D. Jacobs and S. Aulbach. Ruminations on
Diese Punkte verdeutlichen, dass Ergebnisse aktueller For- Multi-Tenant Databases. In BTW, pages 514–521, 2007.
schung im Bereich SLO-basierter Hardware-Provisionierung [13] S. Krompass, D. Gmach, A. Scholz, S. Seltzsam, and
und Steuerung der Abfrageverarbeitung für DaaS [16] nur A. Kemper. Quality of Service Enabled Database
sehr eingeschränkt auf Datenbankdienste für SaaS-Anwen- Applications. In ICSOC, pages 215–226, 2006.
dungen übertragen werden können und gesonderte Forschung
[14] S. Krompass, A. Scholz, M.-C. Albutiu, H. A. Kuno,
für jenen Bereich vonnöten ist.
J. L. Wiener, U. Dayal, and A. Kemper. Quality of
Service-enabled Management of Database Workloads.
4. ZUSAMMENFASSUNG UND NÄCHSTE IEEE Data Eng. Bull., 31(1):20–27, 2008.
SCHRITTE [15] T. Kwok and A. Mohindra. Resource Calculations with
Constraints, and Placement of Tenants and Instances
In diesem Beitrag wurde gezeigt, dass eine Integration von
for Multi-tenant SaaS Applications. In ICSOC, pages
Service Level Objects in ein Multi-Tenancy-Datenbanksystem
633–648. Springer-Verlag, 2008.
in Form einer Erweiterung des Datenbankkatalogs von ver-
schiedenen DBMS-Komponenten verwendet werden kann, [16] W. Lang, S. Shankar, J. Patel, and A. Kalhan. Towards
um die Überwachung der SLOs während des Betriebs zu Multi-Tenant Performance SLOs. In ICDE ’12, 2012.
gewährleisten. Als mögliche Verwendungsbeispiele wurden [17] P. M. Nadkarni and C. Brandt. Data extraction and ad
das Workload Management, die Lastverteilung und eine in- hoc query of an entity–attribute–value database.
dividuelle Replikationssteuerung aufgeführt. Journal of American Medical Informatics Association,
In den weiteren Arbeiten soll der Entwurf der SLO-Integra- 5(6):511–527, 1998.
tion konkretisiert, verschiedene Implementierungsvarianten [18] Pierre Audoin Consultants. Entry of the global players
verglichen und die Realisierbarkeit anhand eines Prototyps confirms Global SaaS Trends. 2012.
gezeigt werden. Anschließende Performance-Tests sollen Auf- [19] B. Reinwald. Database support for multi-tenant
schluss darüber geben, ob der zusätzliche Overhead durch applications. IEEE Workshop on Information and
die mandantenspezifischen Metadaten und das SLO-basierte Software as Services, 1:2, 2010.
Management die Skalierbarkeit und den laufenden Betrieb [20] O. Schiller, B. Schiller, A. Brodt, and B. Mitschang.
des Datenbanksystems beeinträchtigen. Native support of multi-tenancy in RDBMS for
software as a service. In EDBT/ICDT, pages 117–128.
ACM, 2011.
5. LITERATUR [21] M. Seibold and A. Kemper. Database as a Service.
[1] DB2 Workload Manager for Linux, Unix, and Windows. Datenbank-Spektrum, 12(1):59–62, 2012.
IBM Corp., 2008. [22] R. Sturm, W. Morris, and M. Jander. Foundations of
[2] Oracle�R Database Administrator’s Guide 11g Release Service Level Management. SAMS Publishing, Apr.
2. Oracle, 2011. 2000.