Service-Level-bewusste Ressourcenverwaltung für Multi-Tenancy-Datenbanken mittels Replikation

Transkript

1 Service-Level-bewusste Ressourcenverwaltung für Multi-Tenancy-Datenbanken mittels Replikation Andreas Göbel Lehrstuhl für Datenbanken und Informationssysteme Friedrich-Schiller-Universität Jena Ernst-Abbe-Platz Jena andreas.goebel@uni-jena.de Abstract: Das an Bedeutung gewinnende Anwendungsvertriebsmodell Software as a Service stellt Dienstleister vor neue Herausforderungen in Bezug auf die Entwicklung und Verwaltung ihrer Anwendungen und deren Datenhaltung. Multi-Tenancy- Datenbanken ermöglichen ihnen die Reduzierung operativer Kosten bei gegebener Erfüllung individueller Dienstgütevereinbarungen. Dieser Beitrag motiviert, dass eine mandantenbewusste Replikation ein adäquates Hilfsmittel für die Dienstgüte-bewahrende Ressourcenverwaltung darstellt. Die wesentlichen Herausforderungen eines Ressourcen-Controllers mit dieser Zielstellung sowie seine Einbettung in einen Architekturentwurf werden vorgestellt. 1 Einleitung Software as a Service (SaaS) bezeichnet das Bereitstellen von Web-Anwendungen auf Basis einer Cloud-Infrastruktur. Während der Dienstleister die Verantwortung für die Verwaltung und Pflege einer Anwendung und der nötigen Infrastruktur besitzt, greifen Kunden (Mandanten) in der Regel über das Internet und via Web-Browser auf die Anwendung zu. Dienstgütevereinbarungen legen zu erreichende Kennzahlen (Service Level Objectives, SLOs) technischer Aspekte wie dem Durchsatz oder der Latenz von Anweisungen sowie der Dienstverfügbarkeit fest und verknüpfen die Nichteinhaltung mit Vertragsstrafen für den Dienstleister [Gro10]. In Multi-Tenancy-Anwendungen nutzen Mandanten eine gemeinsame DBMS- und Anwendungsinstanz. Durch die gesteigerte Ressourcennutzung bzw. die Ausnutzung von Skaleneffekten kann somit eine hohe Wirtschaftlichkeit des Dienstes erzielt werden. Abbildung 1 verdeutlicht gemäß [Rei10] das Spektrum der Mandantenkonsolidierung auf einem Datenbankserver. Es erstreckt sich von keiner Konsolidierung (Separate Hardware) bis hin zur Konsolidierung in Datenbankobjekten (Shared Table). In SaaS-Angeboten wird meist ein Basis-Datenbankschema für alle Mandanten vorgegeben, welche es erweitern können, um die Anwendung an ihre Bedürfnisse anzupassen. Bei den Ansätzen Shared Database und Shared Table kann man sich diese Ähnlichkeit der Datenbankschemata

2 Isolation Hardware Virtuelle Maschine Betriebssystemnutzer Datenbank- Instanz Datenbank Schema / Tablespace Zeile Bewertung niedrig hoch Komplexität, Ressourcenausnutzung, max. Mandantenanzahl, Skalierbarkeit Kosten je Mandant, Sicherheit, Wartungsaufwand hoch niedrig Abbildung 1: Ansätze zur Mandantenkonsolidierung auf einem Datenbankserver zunutze machen, um den Speicherbedarf für Schemainformationen zu reduzieren. Dies führt in Verbindung mit der hohen Ressourcenausnutzung zu geringen Kosten je Mandant, weshalb diese Ansätze für SaaS-Anwendungen besonders geeignet sind. Eine gemeinsame Nutzung von Ressourcen bringt jedoch auch neue Herausforderungen für den Dienstleister mit sich, beispielsweise bezüglich der Isolation von Mandantendaten, der SLO-Einhaltung, mandantenspezifischer und nutzungsgerechter Abrechnung und schneller Anpassung an Laständerungen. Um diese Elastizität zu erzielen und die operativen Kosten für Hardware, Administration und Vertragsstrafen gering zu halten, bedarf es gemäß [Göb12] einer automatisierten und SLO-bewussten Allokation und Verwaltung vorhandener Ressourcen. Der Dienstleister muss die Daten üblicherweise in einer Serverfarm verteilen und die Verteilung bei erkannten oder prognostizierten Verletzungen der Dienstgütevereinbarungen dynamisch anpassen. Aufgrund der disjunkten Arbeitsbereiche von Mandanten ist hierbei eine Partitionierung nach Mandanten zu empfehlen. Sie erlaubt Isolation und reduziert serverübergreifende Transaktionen, welche die Skalierbarkeit verteilter OLTP-Systeme typischerweise stark beeinträchtigen. Abhängig vom gewählten Konsolidierungsgrad kann sie beispielsweise durch Tabellenpartitionierung (Shared Table) oder eine Verteilung der Mandantentabellen (Shared Database) realisiert werden. Replikation stellt laut [AJKS09] ein mächtiges Werkzeug dar, um die Verfügbarkeit und unter Umständen die Skalierbarkeit eines Datenbanksystems zu erhöhen. In diesem Beitrag wird motiviert, dass die Replikation bei einer geeigneten Planung des Dienstleisters zudem ein hilfreiches Mittel zur dynamischen Ressourcenverwaltung darstellt. Hierzu sind die auf mehrere Server verteilten Replikate der Mandantendaten bei der Ressourcenumverteilung zu berücksichtigen. Auf weitere Herausforderungen im Multi-Tenancy-Umfeld wie Sicherheit und individuelle Datenbankschemata wird dabei nicht eingegangen. Der Beitrag ist wie folgt aufgebaut: Abschnitt 2 gibt einen Überblick über die Verwendbarkeit der Replikation für die dynamische Ressourcenverwaltung. Abschnitt 3 stellt einen Systementwurf zur SLO-basierten Ressourcenkontrolle vor. In Abschnitt 4 wird auf wesentliche Herausforderungen des Ressourcen-Controllers im Zusammenhang mit der Platzierung von Replikaten, der Festlegung einer Migrationsstrategie und der Implementierung von Migrationsverfahren eingegangen. Abschnitt 5 befasst sich mit vergleichbaren Arbeiten und Abschnitt 6 fasst die Arbeit zusammen.

3 2 Dynamische Ressourcenverwaltung mittels Replikation Heutige SaaS-Implementierungen verwenden meist von Datenbanksystemen vorgegebene Replikationsverfahren zur Gewährleistung der Verfügbarkeit. Soll ein Datenverlust ausgeschlossen werden, so ist der Einsatz synchroner Replikation unabdingbar. Sie verzögert jedoch die Verarbeitung modifizierender Datenbankanfragen deutlich, weshalb zugunsten der Antwortzeiten häufig die Einschränkungen der asynchronen Master-Slave-Replikation der Datenbank in Kauf genommen werden. Die Last wird dabei häufig nicht auf Sekundärreplikate verteilt, um Inkonsistenzen zu vermeiden und um sicherzustellen, dass die Slaves den Master im Falle seines Ausfalls ohne Einschränkungen ersetzen können [SJKP12]. In der Folge werden erhebliche Ressourcen für einen Ausfall vorgehalten. Diese Problematik kann durch die Verwendung des Mandanten als Partitionierungs- und Replikationsgranulat deutlich reduziert werden. Bei einer lokalen Verteilung der Replikate jedes Mandanten werden die Datenbankserver beispielsweise in Form eines logischen Rings verkettet und Mandantenreplikate in Anlehnung an das Verfahren Chained Declustering [HD90] in lokaler Nachbarschaft gespeichert. Beim Ausfall eines Ringknotens wird die Last somit auf dessen Nachbarschaft verteilt und das System muss anschließend durch aufwändige Migrationen rebalanciert werden. Zudem ist diese Strategie problematisch bei parallelen Ausfällen benachbarter Server. Im Gegensatz dazu verfolgt eine globale Verteilung das Ziel, die Sekundärreplikate der Mandanten eines Servers gemäß dem von Teradata eingeführten Interleaved Declustering [CK89] möglichst gleichmäßig auf alle anderen Knoten zu verteilen. Bei Knotenausfällen wird somit auch die entstehende Last auf alle anderen Knoten verteilt und eine Rebalancierung entfällt. Die gemäß ihrem Ressourcenbedarf auf der Serverfarm verteilten Sekundärreplikate können als Ausgangspunkt von Umverteilungen im Zuge der Ressourcenverwaltung dienen. Eine Umverteilung führt Migrationen aus, welche die Verlagerung der Daten und Transaktionsverarbeitung eines Mandanten auf einen anderen Datenbankserver vollziehen. Die Migration ist somit eine Schlüsselkomponente zur Elastizität, Lastbalancierung und Wartung des Systems. Neben Punkten wie Korrektheit, Fehlertoleranz, autonomer Arbeitsweise und Unterbrechungsfreiheit sind eine schnelle Durchführung und eine geringe Belastung des Quell- und Zielservers wesentliche Anforderungen an die Migration. Diese beiden Anforderungen sind von der Menge der zu verschiebenden Daten abhängig, welche durch ein auf dem Zielserver bestehendes Replikat deutlich reduziert werden kann. 3 Architekturentwurf Als Ausgangspunkt für die weiteren Abschnitte dient der in Abbildung 2 dargestellte Architekturentwurf eines Systems zur autonomen, SLO-basierten Ressourcenkontrolle von Multi-Tenancy-Datenbanken. Als Grundlage für die Ressourcenkontrolle dienen aus den Latenzvorgaben der Mandanten-SLOs abgeleitete Ressourcenanforderungen. Das System enthält mehrere Datenbankserver, die jeweils persistente Daten diverser Mandanten in einer Instanz des relationalen Open-Source-DBMS H2 1 verwalten. Dabei wird 1

4 A,D,E B,C Anwendungsserver Datenbank- Server Anweisungszuteiler Ausführungszeiten Verteilungsvorschrift Ressourcen- Controller Statistiken A P E S E P C S D P A S C P E S B P D S B S Migration Server 1 Server 2 Server 3... Server n Abbildung 2: Überblick der Systemarchitektur der Konsolidierungsansatz Shared Database verwendet, der bei effizienter Schemaverwaltung in einem Multi-Tenancy-DBMS für SaaS-Anwendungen einen guten Kompromiss aus Isolation, Redundanz und Flexibilität darstellt [AJKS09]. Die Datenbank wird entsprechend nach Mandanten partitioniert, indem jedem Mandanten eigene Tabellen sowie ein separates Schema zugeordnet werden. Die Mandantendaten werden zudem asynchron repliziert, in Abbildung 2 verfügt beispielsweise Server 1 über die Primärreplikate der Mandanten A und B sowie ein Sekundärreplikat von Mandant E. Das DBMS muss entsprechend Replikation und Ressourcenüberwachung auf Schema-Ebene unterstützen, was durch eine H2-Erweiterung realisiert wird. Die Partitionierung eines Mandanten sowie die Unterstützung synchroner Replikation auf Wunsch von Mandanten kennzeichnen mögliche Erweiterungen. Der Anweisungszuteiler koordiniert den Zugriff der Anwendungs- auf die Datenbankserver. Mittels einer dynamischen Verteilungsvorschrift leitet dieser Datenbank-Proxy die Anweisungen der Mandanten an die zuständigen Datenbankserver weiter. Zu prüfen ist, ob mittels redundanter Auslegung der Komponente ein Flaschenhals und SPoF vermieden werden kann. Alternativ kann die Verteilung durch die Datenbankserver selbst erfolgen. Eine mögliche Erweiterung besteht in der Lastbalancierung bezüglich der Replikate eines Mandanten, welche aufgrund der asynchronen Replikation zu Inkonsistenz führen kann. Ein Multi-Tenancy-Benchmark soll die Dynamik der typischen Arbeitslast eines SaaS- Produkts simulieren und somit zur Messung der Elastizität, Skalierbarkeit und insbesondere SLO-Gewährleistung des Systems dienen. In konfigurierbaren Szenarien können durch das Terminieren von Aktionen zur Änderung der Anzahl und Charakteristika aktiver Mandanten verschiedene Lastsituationen modelliert werden. Ein Mandant wird durch eine Instanz des Open-Source-Frameworks OLTP-Bench 2 simuliert. Das Framework kann die Daten und Arbeitslast diverser OLTP- und Web-Benchmarks erzeugen und ist kompatibel zu relationalen Datenbanksystemen mit einer JDBC-Schnittstelle. Der Ressourcen-Controller platziert die Daten der Mandanten auf die Datenbankserver 2

5 unter Minimierung der Anzahl benötigter Server und SLO-Verletzungen der Mandanten. Seine Entscheidungen trifft er auf Grundlage der SLOs sowie deren Erfüllungsgrade, Latenz-Informationen, Statistiken zur Auslastung der Datenbankserver und dem Ressourcenverbrauch der Mandanten. Zudem kontrolliert er die Betriebsfähigkeit der Datenbankserver und koordiniert die Ausfallsicherung. Die wesentlichen Herausforderungen des Ressourcen-Controllers werden im folgenden Abschnitt zusammengefasst. 4 Herausforderungen des Ressourcen-Controllers 4.1 Platzierung von Mandantenreplikaten Im Folgenden wird das Problem der Mandantenplatzierung mit Replikaten zusammengefasst und anschließend formal definiert: Gegeben seien Server mit Kapazitäten bezüglich mehrerer Ressourcen (CPU-Leistung, RAM-Größe, Speichermenge und -bandbreite, etc.) sowie Mandanten (Menge von Tabellen und Indizes) mit Ressourcenbedürfnissen und beliebig vielen Replikaten. Gesucht ist eine Platzierung aller Replikate unter Einhaltung der Serverkapazitäten, wobei die Replikate eines Mandanten auf verschiedene Server zu platzieren und die Server-Auslastungsgrade zu homogenisieren sind. Definition 1 Sei S eine Menge von Servern mit S = { s 1, s 2,..., s S }. Betrachtet werden verschiedene Ressourcentypen R = { r 1, r 2,..., r R }, wobei auf dem Server s i die Menge o i,j der Ressource r j zur Verfügung steht. Definition 2 Sei C die Menge aller Replikate mit C = { c 1, c 2,..., c C } und T die Menge der Mandanten mit T = { t 1, t 2,..., t T }. Für jedes Replikat und jeden Mandant gilt: Gehört das Replikat c k zum Mandanten t l, so ist a k,l = 1, sonst gilt a k,l = 0. Zudem bedarf das Replikat c k die Menge n k,j der Ressource r j. Definition 3 Eine Platzierungsvorschrift von Replikaten auf Server sei definiert als P = { p1,1, p 1,2,..., p S, C }, wobei gilt pi,k = 1, falls das Replikat c k auf dem Server s i platziert wurde, sonst gilt p i,k = 0. Eine zulässige Zuordnungsvorschrift muss eine Reihe von Nebenbedingungen erfüllen: Jedes Replikat wird genau einem Server und genau einem Mandanten zugeordnet: S p i,k = 1 i=1 bzw. T a k,l = 1, l=1 mit 1 k C Die Replikate eines Mandanten müssen auf verschiedene Server platziert werden: C p i,k a k,l 1, mit 1 i S, 1 l T k=1

6 Die Ressourcenkapazitäten aller Server sind einzuhalten: C p i,k n k,j o i,j, k=1 mit 1 i S, 1 j R Zielfunktion: Homogenisierung von Auslastungsgraden (AG) der Ressourcen aller Server (durch Minimierung der Varianz) zur Vermeidung unausgewogener Ressourcennutzung innerhalb eines Servers und stark abweichender Auslastungsgrade zwischen Servern: C AG i,j := p i,k n k,j /o i,j, mit 1 i S, 1 j R k=1 min Var ( AG 1,1, AG 1,2,..., AG S, R ) Denkbare Erweiterungen sind Überbuchungen und minimale Auslastungsgrade von Servern, die Minimierung identischer Platzierungen zweier Mandanten und die Einführung und Maximierung individueller Profite bei einer Ressourcen-Erfüllung. Es handelt sich um ein mehrdimensionales Behälterproblem mit Konflikten (bin packing problem). Server, Mandanten und Ressourcen können den Behältern, Objekten und Gewichten zugeordnet werden, die Replikate führen zu einem Konfliktgraphen. Das Problem ist NP-schwer, auf einen Beweis sei an dieser Stelle verzichtet. [SJKP12] zeigt, dass der Suchraum gültiger Platzierungen bereits bei wenigen Datenbankservern und Mandanten sehr groß werden kann. Eine wesentliche Herausforderung ist demnach die Entwicklung effizienter Algorithmen zum Finden adäquater Platzierungen. Nicht weniger anspruchsvoll gestaltet sich die Kalkulation des Ressourcenbedarfs von Mandanten, insbesondere unter Wechselwirkung mit anderen Mandanten in einem Datenbanksystem. 4.2 Festlegung der Migrationsstrategie Die Aufgabe des Ressourcen-Controllers besteht in der Überwachung der Systemressourcen und Anpassung der Ressourcenallokation. Folgende Situationen können beispielsweise den Bedarf einer Umstrukturierung durch Mandantenmigrationen hervorrufen: Anpassung einer unausgewogenen initialen Mandatenplatzierung, SLO-Verletzungen eines Mandanten als Folge höherer Ressourcenanforderungen von ihm oder anderen Mandanten des Servers, Entfernung eines Servers mit dem Ziel der Kostenoptimierung oder Wartung, Schaffung freier Ressourcenkapazitäten des Servers für neue Mandanten, Änderung der SLOs von Mandanten. Die Migration von Mandanten bindet Ressourcen auf dem Quell- und Zielserver, welche dort anderen Mandanten während der Migration nicht zur Verfügung stehen. Während bei

7 SLO-Verletzungen das Quellsystem durch Migrationen minimal belastet werden sollte, spielt dies beim Entfernen von Servern meist eine untergeordnete Rolle. Jede Migrationsursache besitzt somit spezielle Anforderungen. Sie sind bei der Planung der Migrationsstrategie, bei welcher die zu migrierenden Mandanten, die Zielserver, der Migrationsbeginn und das -verfahren festgelegt werden, zu berücksichtigen. Aufbauend auf dem Problem der Replikatplatzierung in Abschnitt 4.1 muss der Ressourcen-Controller unter Zuhilfenahme des aktuellen Systemzustands (SLO-Erfüllungsgrade, Serverauslastungen und Mandantenverteilung) eine kosten- und nutzenoptimierende Migrationsstrategie bestimmen. Zu berücksichtigen sind dabei reduzierte Laufzeiten und Systembelastungen der Migration auf ein bestehendes Mandantenreplikat als Folge der geringen zu transferierenden Datenmenge. Hierdurch können gegebenenfalls kurzfristige Verbesserungen ohne große Systembelastungen erzielt werden. Migrationsverfahren erfüllen die an sie gestellten Anforderungen wie ununterbrochene Verfügbarkeit, schnelle Durchführung und geringe Belastung des Quell- und Zielservers unterschiedlich gut (siehe Abschnitt 4.3). Idealerweise bietet das System verschiedene Migrationsverfahren und der Ressourcen-Controller kann unter Kenntnis der Vor- und Nachteile jedes Verfahrens das geeignetste Verfahren für den gewünschten Einsatzzweck auswählen. Gemäß [BCM + 12] sollten zudem die für den Migrationsvorgang zur Verfügung stehenden Ressourcen beschränkt werden, um die SLO-Einhaltung anderer Mandanten nicht zu gefährden. 4.3 Verfahren zur Live-Migration Der Migrationsvorgang beinhaltet das Kopieren der persistenten Mandantendaten von einem Quell- zu einem Zielsystem sowie die Synchronisation laufender Transaktionen. Eine Live-Migration verfolgt gemäß [EDAA11] die Ziele, während der Migration nur eine minimale Anzahl an Transaktionen nicht ausführen zu können und die Erreichbarkeit der Mandantendaten nicht zu beeinträchtigen. Hierzu werden beispielsweise während der Synchronisation die vom Quellserver benötigten Daten schrittweise zum Zielserver kopiert. In der einschlägigen Literatur wurden mehrere Verfahren zur Live-Migration publiziert. Jedoch wurde lediglich beim Verfahren Zephyr [EDAE11] die Verringerung der Migrationsdauer auf bestehende Replikate beschrieben und implementiert, alle Schritte des Verfahrens werden hierdurch beschleunigt oder entfallen gar. Der in [EDAE11] angestellte Vergleich von Zephyr mit anderen Migrationsverfahren verdeutlicht, dass die Verfahren unterschiedliche Stärken und Schwächen besitzen und sich somit für spezielle Einsatzbereiche eignen. Jedoch existiert bisher kein umfassender und strukturierter Vergleich möglicher Verfahren zur Live-Migration und existierende Verfahren bieten Verbesserungspotenzial. Jene Untersuchungen wären nicht nur im Kontext der Migration in Multi-Tenancy-Datenbanken von Interesse, da jene Verfahren nicht auf dieses Einsatzgebiet beschränkt sind. Zudem gilt es zu untersuchen, inwieweit die Verfahren von synchronen oder asynchronen Replikaten profitieren können.

8 5 Verwandte Arbeiten Platzierung von Mandanten: Der Großteil bisheriger Forschung [MFD11, CRV10, BGC11] zur Platzierung von Mandanten auf Server ( Tenant Placement Problem oder Resource Allocation Problem ) konzentriert sich auf mathematische Modelle und Algorithmen zur Platzierung virtueller Maschinen auf Server eines Cloud-Anbieters. Diese Arbeiten betrachten die virtuellen Maschinen als Black Box und ignorieren somit zumeist die Charakteristika enthaltener Anwendungen wie I/O-intensive DBMS. Der Ansatz Shared Hardware ist zudem aufgrund der hohen Kosten je Mandant unvereinbar mit SaaS- Angeboten. Weitere Arbeiten [YQR + 12, LSPK12, MMC + 12] beinhalten kosteneffiziente Algorithmen für die Platzierung von Mandanten innerhalb einer Datenbankinstanz auf Basis des Ansatzes Shared Instance. Im Gegensatz zu all den bisher genannten Arbeiten wird in [SJKP12] die Replikation von Mandanten bei der Platzierung berücksichtigt. Das Problem wird abstrahiert auf Gegenstände mit Eigenschaften, die unter Beachtung von Regeln auf Körbe mit einer Kapazität aufgeteilt werden. Das formulierte Problem ist jedoch auf zwei Replikate je Mandant und lediglich eine Kenngröße für die Kapazität der Server und den Bedarf der Mandanten festgelegt. SLO-basierende Ressourcenkontrolle: Relational Cloud [CJP + 11] verfolgt unter anderem das Ziel der Partitionierung, Verteilung und Migration von Mandantendaten mittels Kalkulation ihres Ressourcenbedarfs. Die hierfür verwendete Engine zur Datenbankkonsolidierung Kairos [CJMB11] basiert jedoch auf dem Ansatz Shared Instance und ist beschränkt auf die Gewährleistung eines minimalen Datenbankdurchsatzes, während die Latenz keine Beachtung findet. Ebenfalls auf dem Ansatz Shared Instance basiert der in [EDAA11] nur skizzierte Entwurf eines autonomen Controllers zur SLO-basierenden Mandantenplatzierung und Migration namens ilandlord. [KM08, YQR + 12] greifen die Herausforderungen der Abschätzung von Ressourcenanforderungen und der geeigneten Platzierung hinzuzufügender Mandanten in ein bestehendes System auf. Zudem befasst sich eine Vielzahl von Publikationen mit SLO-basiertem Workload-Management. In [XCZ + 11] werden die Anweisungen von Mandanten bei einer prognostizierten SLO-Verletzung abgewiesen. In anderen Verfahren werden die Anweisungen in Warteschlangen verschoben und ihre Verarbeitungsreihenfolge gemäß dem aktuellen SLO- Erfüllungsgrad bzw. profitorientiert umsortiert [KGS + 06, CMH11, MCH11]. In Bezug auf die in Abschnitt 3 vorgestellte Architektur kann das SLO-basierte Workload-Management sowohl global in der Anweisungszuteilung als auch lokal in den Datenbankservern genutzt werden. Systemüberlastungen können hierdurch erkannt, teilweise gelöst und an den Ressourcen-Controller weitergeleitet werden. Live-Migration in Multi-Tenancy-Datenbanken: Die einfachste Form der Migration besteht in der Erstellung und Verschiebung einer Momentaufnahme der Mandantendaten nach Blockierung aller modifizierenden Anfragen auf dem Quellserver. Dieses als Stop & Copy [EDAE11] bezeichnete Verfahren schränkt unweigerlich die Erreichbarkeit ein und belastet das System während der Migration. An Albatros [DNAE11] angelehnte Ver-

9 fahren mindern zwar diese Nachteile durch iteratives Versenden der Momentaufnahme und weiterer Datenmodifikationen, sie erhöhen jedoch in der Folge die Belastung für den Quellserver und das Netzwerk. Ist der Zielserver nahezu synchron, erfolgt eine kurze Blockierung auf dem Quellserver und die finale Umschaltung. Diese Verfahren können analog zum in Abschnitt 4.3 aufgegriffenen Zephyr ungemein von einer bestehenden asynchronen Replikation profitieren. [Fic11] zeigt alternative Ansätze zur Live-Migration auf und bietet somit Ansatzpunkte für die Entwicklung weiterer Verfahren. 6 Zusammenfassung und Ausblick Dieser Beitrag motivierte, dass bei einer adäquaten Planung die Replikation auf Mandantenebene ein geeignetes Hilfsmittel zur Unterstützung der SLO-basierten Ressourcenverwaltung in Multi-Tenancy-Datenbanken darstellt. Hierzu bedarf es eines Ressourcen- Controllers, der Umverteilungen unter Berücksichtigung der Replikatverteilung plant. Ein Architekturentwurf zeigte, wie sich der Ressourcen-Controller in ein System einbinden lässt. Zudem wurden wesentliche Herausforderungen des Controllers bezüglich der Platzierung der Mandanten und Festlegung einer Migrationsstrategie unter Berücksichtigung der Replikat- und Mandantenplatzierung vorgestellt. Hierzu wurde das Problem der Mandantenplatzierung mit Replikaten formal definiert, welches eines der zu lösenden Schlüsselprobleme darstellt. Zudem wurde aufgezeigt, dass im Zusammenhang mit Verfahren zur Live-Migration noch großer Forschungsbedarf herrscht. Das zentrale Ziel zukünftiger Tätigkeiten besteht in der prototypischen Realisierung des beschriebenen Systementwurfs und insbesondere des Ressourcen-Controllers. Dies dient als Ausgangspunkt für Untersuchungen und Bewertung verschiedener Verfahren zur Migration auf bestehende Replikate eines Mandanten. Literatur [AJKS09] [BCM + 12] [BGC11] [CJMB11] [CJP + 11] [CK89] S. Aulbach, D. Jacobs, A. Kemper und M. Seibold. A comparison of flexible schemas for software as a service. In SIGMOD, Seiten , S. K. Barker, Y. Chi, H. J. Moon, H. Hacigümüş und P. J. Shenoy. Cut me some slack : latency-aware live migration for databases. In EDBT, Seiten , R. Buyya, S. K. Garg und R. N. Calheiros. SLA-oriented resource provisioning for cloud computing: Challenges, architecture, and solutions. In CSC, Seiten 1 10, C. Curino, E. Jones, S. Madden und H. Balakrishnan. Workload-aware database monitoring and consolidation. In SIGMOD, Seiten , C. Curino, E. Jones, R. Popa, N. Malviya, E. Wu, S. Madden, H. Balakrishnan und N. Zeldovich. Relational Cloud: a Database Service for the cloud. In CIDR, Seiten , G. Copeland und T. Keller. A comparison of high-availability media recovery techniques. In SIGMOD, Seiten , 1989.

10 [CMH11] [CRV10] [DNAE11] [EDAA11] [EDAE11] [Fic11] [Göb12] [Gro10] [HD90] [KGS + 06] [KM08] [LSPK12] [MCH11] [MFD11] Y. Chi, H. J. Moon und H. Hacigümüş. icbs: incremental cost-based scheduling under piecewise linear SLAs. VLDB Endowment, 4(9): , F. Chang, J. Ren und R. Viswanathan. Optimal Resource Allocation in Clouds. In CLOUD, Seiten , S. Das, S. Nishimura, D. Agrawal und A. El Abbadi. Albatross: lightweight elasticity in shared storage databases for the cloud using live data migration. VLDB Endowment, 4(8): , A. J. Elmore, S. Das, D. Agrawal und A. El Abbadi. Towards an Elastic and Autonomic Multitenant Database. In NetDB, A. J. Elmore, S. Das, D. Agrawal und A. El Abbadi. Zephyr: live migration in shared nothing databases for elastic cloud platforms. In SIGMOD, Seiten , U. Ficht. Effiziente, dynamische Pufferskalierung für Mandanten. Diplomarbeit, Universität Stuttgart, A. Göbel. SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung. In Grundlagen von Datenbanken, Seiten 53 58, Cloud Computing Use Case Discussion Group. Cloud Computing Use Cases. Version 4.0, Computing Use Cases Whitepaper-4 0.pdf, Abrufdatum: , H.-I. Hsiao und D. J. Dewitt. Chained Declustering: A New Availability Strategy for Multiprocssor Database machines. In ICDE, Seiten , S. Krompass, D. Gmach, A. Scholz, S. Seltzsam und A. Kemper. Quality of service enabled database applications. In ICSOC, Seiten , T. Kwok und A. Mohindra. Resource Calculations with Constraints, and Placement of Tenants and Instances for Multi-tenant SaaS Applications. In ICSOC, Seiten , W. Lang, S. Shankar, J. M. Patel und A. Kalhan. Towards Multi-tenant Performance SLOs. In ICDE, Seiten , H. J. Moon, Y. Chi und H. Hacigümüş. Performance evaluation of scheduling algorithms for database services with soft and hard SLAs. In DataCloud-SC, Seiten 81 90, K. Mills, J. Filliben und C. Dabrowski. Comparing VM-Placement Algorithms for On-Demand Clouds. In CLOUDCOM, Seiten 91 98, [MMC + 12] H. A. Mahmoud, H. J. Moon, Y. Chi, H. Hacigümüş, D. Agrawal und A. El-Abbadi. Towards Multitenancy for IO-bound OLAP Workloads. Bericht, University of California, Santa Barbara, [Rei10] B. Reinwald. Database support for multi-tenant applications. WISS, 1:2, [SJKP12] [XCZ + 11] [YQR + 12] Jan Schaffner, D. Jacobs, T. Kraska und Hasso Plattner. The Multi-Tenant Data Placement Problem. In DBKDA, Seiten , P. Xiong, Y. Chi, S. Zhu, J. Tatemura, C. Pu und H. Hacigümüş. ActiveSLA: a profitoriented admission control framework for database-as-a-service providers. In SOCC, Seiten 15:1 15:14, T. Yu, J. Qiu, B. Reinwald, L. Zhi, Q. Wang und N. Wang. Intelligent Database Placement in Cloud Environment. In ICWS, Seiten , 2012.