AutoGlobe: Automatiche Adminitration von dientbaierten Datenbankanwendungen Daniel Gmach, Stefan Seltzam, Martin Wimmer, Alfon Kemper Techniche Univerität München Lehrtuhl für Informatik III 85748 Garching bei München gmach eltzam wimmerma kemper @in.tum.de Abtract: Derzeit lät ich ein Trend weg von monolithichen Sytemen hin zu Service Oriented Architecture (SOA) beobachten. Dieer Paradigmenwechel erfordert neue Adminitrationtechniken, um die auf SOA baierenden verteilten Datenbankanwendungen zuverläig und kotengüntig betreibenzukönnen. Zu dieem Zweck entwickeln wir neue Selbtadminitrierungkonzepte. Die Grundlage hierfür bilden die Virtualiierung von Hardware und Dienten, owie ein kontinuierliche Monitoring. Dadurch it e möglich, die Verteilung der Diente auf die zur Verfügung tehende Hardware durch tatiche und dynamiche Allokationtechniken zu optimieren. Statiche Allokationalgorithmen liefern eine optimierte a priori Verteilung der Diente auf die Hardware. Dazu werden Diente mit komplementären Reourcenanforderungen möglicht gemeinam auf einem Rechner augeführt. Eine rein tatiche Optimierung kann allerding nicht zeitnah auf unvorheragbare Ereignie, wie etwa Überlat- oder Fehlerituationen, reagieren. Dehalb etzen wir zuätzlich eine auf Fuzzy-Logik baierende Kontrollkomponente ein, die zur Laufzeit dynamich Anpaungen der Dientallokation vornimmt. Beipielweie werden abgetürzte Diente neu getartet und Überlatituationen durch Hinzunahme weiterer Intanzen oder den Umzug einer Intanz auf einen leitungfähigeren Rechner behoben. Die vorgetellten Technologien tellen damit einen erten Schritt in Richtung eine durchgängigen Quality of Service-Management (QoS-Management) in einer derartigen Infratruktur dar. AutoGlobe it die prototypiche Umetzung der in dieem Beitrag bechriebenen Konzepte für eine adaptive Infratruktur, die ich durch Selbtkonfiguration, Selbtoptimierung und eigentändige Fehlerbehebung auzeichnet. 1 Einleitung Die Architektur der Syteme, auf denen Datenbankanwendungen wie Enterprie Reource Planning-Syteme (ERP) typicherweie augeführt werden, unterzieht ich derzeit einem dratichen Wandel. Waren biher monolithiche Softwarearchitekturen vorherrchend, geht der Trend heutzutage zu feingranularen Dienten, die in Service Oriented Architecture-Umgebungen augeführt werden. Beobachten lät ich dieer Wandel etwa anhand der Entwicklung von SAP R/3 über mysap hin zu SAP NetWeaver. Der Einatz von SOA hat allerding tiefgreifende Auwirkungen auf Adminitration- und Optimierungtechniken für Anwendungen. Deren feingranulare Zerlegung in eine Vielzahl interagierender Diente erlaubt inbeondere den
Einatz von Rechnerclutern und eine flexible Dient-Rechner-Allokation. Durch die Virtualiierung der Diente, d.h. der Einführung einer dynamichen Dient- Rechner-Zuweiung, können Anpaungen dieer Allokation zur Laufzeit durchgeführt werden, um etwa lokale Leitungengpäe und Fehlerzutände, wie Rechneroder Dientaufälle, zu kompenieren. Der Zuwach an Flexibilität geht allerding einher mit einer ignifikanten Steigerung der Sytemkomplexität, der nur durch eine weitgehende Automatiierung der Adminitration begegnet werden kann. Au dieem Grund haben wir eine Kontrollkomponente zur kontinuierlichen Allokationund damit Leitungoptimierung von Anwendungen auf der Bai von SOA entwickelt. Diee Softwarekontrollkomponente bildet den Kern unerer adaptiven Infratruktur AutoGlobe, die ich durch Selbtkonfiguration, Selbtoptimierung und eigentändige Fehlerbehebung auzeichnet. Sie orgt für eine zuverläige Auführung der Diente und eine möglicht effiziente Aulatung der zur Verfügung tehenden Reourcen. Dadurch wird zum einen die Komplexität de Geamtytem handhabbar. Zum anderen wird eine Reduktion der Geamtbetriebkoten (Total Cot of Ownerhip, TCO) erreicht, da bilang zeitweie ungenutzte Reourcen 1,wieie typicherweie in unoptimierten Sytemen auftreten, effizient genutzt werden. In vielen Fällen können dadurch andernfall notwendige Neuanchaffungen entfallen, da mit der vorhandenen Hardware ein höherer Durchatz erzielt werden kann. Uner Anatz zur Optimierung der Dient-Rechner-Allokation baiert auf einer tatichen und einer dynamichen Phae. Da Ergebni der tatichen Allokationoptimierung, die auf der Grundlage von verdichteten hitorichen Latdaten durchgeführt wird, it eine längerfritig augelegte Verteilung der Diente auf die zur Verfügung tehenden Rechner. Dazu werden Diente mit komplementären Reourcenanforderungen möglicht gemeinam auf einem Rechner augeführt. Eine rein tatiche Optimierung kann allerding nicht zeitnah auf unvorheragbare Ereignie, wie etwa Überlat- oder Fehlerituationen, reagieren. Dehalb etzen wir zuätzlich eine auf Fuzzy-Logik baierende Kontrollkomponente ein, die zur Laufzeit dynamich Anpaungen der Allokation vornehmen kann. Zur Entcheidungfindung tehen der Kontrollkomponente dabei die aktuellen Latdaten der Diente und Rechner zur Verfügung. So werden beipielweie abgetürzte Diente neu getartet und Überlatituationen durch Hinzunahme weiterer Intanzen auf biher wenig belateten Rechnern oder den Umzug einer Intanz auf einen leitungfähigeren Rechner behoben. Wir benutzen einen Fuzzy Controller wegen einer Robutheit, Anpabarkeit und der intuitiven Spezifizierbarkeit einer Regelbai. Durch den Einatz der bechriebenen Kontroll- und Monitoringmechanimen wird eine gleichmäßige Aulatung der Hardware owie eine zuverläige Auführung der Diente erreicht. Somit bilden ie die Grundlage für ein durchgängige Quality of Service-Management [Wei99] für eine derartige Infratruktur. Die Anforderungen und Möglichkeiten von Dienten und Rechnern werden mittel einer deklarativen XML-Sprache bechrieben. Diee baiert auf einer frühen Verion der XML-Sprache zur Bechreibung von Dienten und Rechnern der Projektgruppe 1 Ein Großteil der Rechner, auf denen betriebwirtchaftliche Anwendungen augeführt werden, haben erfahrunggemäß eine geringere Durchchnittaulatung al 40%.
Scheduling and Reource Management (iehe [GGFb]) de Global Grid Forum. Damit können z.b. die maximale und minimale Anzahl der Intanzen eine Diente fetgelegt, die Leitung der Rechner untereinander in Beziehung geetzt oder die Regeln de Fuzzy Controller pezifiziert werden. Dieer Beitrag it wie folgt trukturiert: In Abchnitt 2 wird die Architektur von AutoGlobe vorgetellt, die auf unerer ServiceGlobe-Plattform zur rechnerunabhängigen Auführung von Web Service baiert. In Abchnitt 3 bechreiben wir die dynamiche und in Abchnitt 4 die tatiche Optimierung der Dient-Rechner- Allokation. In Abchnitt 5 tellen wir verwandte Arbeiten vor, ehe wir in Abchnitt 6 eine Zuammenfaung und einen Aublick liefern. 2 AutoGlobe: Eine elbtadminitrierende IT-Infratruktur AutoGlobe etzt auf unerer Web Service-Plattform ServiceGlobe [KSK03] auf. ServiceGlobe it volltändig in Java Verion 2 implementiert und baiert auf Web Service-Standard [KL04, ACKM03] wie SOAP, UDDI und WSDL. ServiceGlobe untertützt Standardfunktionalitäten einer Dientplattform wie ein Tranaktionund ein Sicherheitytem [SBK01] und zeichnet ich durch die Untertützung von mobilem Code au. Die Infratruktur ermöglicht omit die Auführung von Dienten auf beliebigen Rechnern zur Laufzeit. AutoGlobe ergänzt dieen Anatz durch eine Kontrollkomponente zur zuverläigen Auführung von Dienten und zur automatichen Optimierung der Dient-Rechner-Allokation. Vorauetzung für dynamiche Änderungen der Allokation it die Virtualiierung von Dienten. Dazu wird jedem Dient eine individuelle IP-Adree zugewieen, die immer an die phyikaliche Netzwerkkarte (engl. NIC) de auführenden Rechner gebunden it. Wird der Dient von einem Rechner auf einen anderen umgezogen, o wird die IP-Adree von der NIC de biherigen Rechner gelöt und anchließend an die NIC de neuen Rechner gebunden. AutoGlobe it für den Einatz auf heterogenen, verteilten und flexiblen Sytemen mit zentraler Datenhaltung bereitgetellt etwa über ein Network Attached Storage (NAS) oder ein Storage Area Network (SAN) konzipiert. Bei dieer Art der Datenhaltung können Diente auf beliebigen Rechnern augeführt werden, elbt wenn ie Zugriff auf peritente Daten benötigen, die nicht in einer Datenbank gepeichert ind. Blade-Server-Syteme ind moderne Vertreter dieer Sytemarchitektur. Sie zeichnen ich durch im Vergleich zu traditionellen Mainframe-Architekturen geringere Anchaffungkoten und geringere Adminitrationkoten al bei herkömmlichen Clutern au. Zudem können Rechen- und Speicherkapazität unabhängig voneinander flexibel an den jeweiligen Bedarf angepat werden. Ertere lät ich durch die Anzahl der Blade, letztere durch die Anzahl bzw. den Aubau der SAN/NAS-Löung teuern. Ein derartige Sytem dient al Tetumgebung für AutoGlobe. Virtualiierte Diente auf einem Blade-Server-Sytem ind auch Grundlage kommerzieller Syteme, wie beipielweie FlexFrame [Fle].
(1) Initiale tatiche Allokation (6) Übernahme der tatichen Allokation Ja Beere Allokation? (3) Dynamiche Optimierung der Allokation (2) Monitoring chreiben Latdatenarchiv leen (4) Muterextraktion (5) Berechnung einer tatichen Allokation Dynamiche Optimierung Statiche Optimierung Abbildung 1: Zuammenpiel taticher und dynamicher Allokationoptimierung 2.1 Statiche und Dynamiche Allokation Abbildung 1 zeigt da grundlegende Zuammenpiel der tatichen und der dynamichen Optimierung der Dient-Rechner-Allokation. Die dynamiche Optimierung orgt für lokale Verbeerungen der Allokation während der Laufzeit, um beipielweie Überlat- und Fehlerituationen zeitnah zu beheben. Die tatiche Optimierung wird eingeetzt, um eine globale, längerfritig augelegte neue Allokation zu berechnen, die dann wiederum al Grundlage für die dynamiche Optimierung dient. Die Übernahme einer tatichen Allokation bedingt eventuell eine aufwändigere Reallokation der Diente und damit eine kurzfritige Unterbrechung der Auführung von Teilen de Sytem. Da die aufgrund de Aufwand in der Regel nur in größeren Zeitabtänden durchgeführt werden kann, wird die kontinuierliche dynamiche Optimierung in Kombination dazu durchgeführt, um zeitnah auf unvorherehbare Probleme reagieren zu können. Die Inbetriebnahme de Sytem erfolgt baierend auf einer initialen tatichen Allokation (1). Diee kann von einem Adminitrator vorgegeben werden, oder auch automatich betimmt werden. Letztere it dann möglich, wenn der Reourcenbedarf der auzuführenden Diente beipielweie aufgrund von Adminitrator- oder Entwicklervorgaben bekannt it. Auf der Grundlage der aktuellen Allokation wird ein Monitoring der Diente und Rechner durchgeführt (2). Die dabei geammelten Informationen werden einereit zur kontinuierlichen dynamichen Optimierung (3) verwendet. Anderereit werden die Daten in verdichteter Form im Latdatenarchiv gepeichert und bilden die Grundlage für die tatiche Optimierung (4-6). Die dynamiche Optimierung (3) baiert im Weentlichen auf einem Fuzzy Controller, der eine Entcheidungen regelbaiert trifft. Mit dieem Controller it e möglich, Aunahmeituationen, wie etwa Überlat- oder Fehlerituationen, zu erkennen und automatich zu beheben. Die tatiche Optimierung berückichtigt zykliche Latmuter der Diente. Dazu werden die archivierten Latdaten regelmäßig augewertet und charakteritiche Latmuter extrahiert (4). Baierend auf dieen Mutern werden Diente mit komplementären Reourcenanforderungen ermittelt und eine optimierte Allokation berechnet (5). Beipielweie werden OLAP-Prozee, die hauptächlich nacht Lat verurachen, mit überwiegend tageaktiven OLTP-Dienten kombiniert. Die neu berechnete Dient-Rechner-Allokation wird danach mit der betehenden verglichen
Replizierbarkeit Scale-outfähig Nicht caleout-fähig increae-priority decreae-priority cale-out cale-in increae-priority decreae-priority Statich Verchiebbarkeit increae-priority decreae-priority cale-out cale-in increae-priority decreae-priority Abbildung 2: Einteilung der Diente Dynamich move cale-up cale-down move cale-up cale-down und die zu erwartende Verbeerung de Sytemverhalten wie auch die enttehenden Koten für ihre Umetzung abgechätzt. Bei geeignetem Koten-Nutzen- Verhältni wird die neu berechnete tatiche Allokation umgeetzt (6) und dient damit al neue Augangbai für die weitere kontinuierliche dynamiche Optimierung. 2.2 Charakteriierung der Diente Diente werden hinichtlich ihrer Verchiebbarkeit und Replizierbarkeit (cale-out- Fähigkeit) klaifiziert. Je nach Kategorie laen ich verchiedene adaptive Operationen (vgl. Tabelle 1) auf die Diente anwenden (iehe Abbildung 2). Im Hinblick auf Verchiebbarkeit werden tatiche und dynamiche Diente unterchieden. Statiche Diente ind nach einer initialen Allokation einem Rechner fet zugeteilt, wohingegen dynamiche Diente einen Umzug auf einen anderen Rechner (move, cale-down und cale-up) zur Laufzeit untertützen. Die Replizierbarkeit eine Diente gibt an, ob zur Laufzeit neue Intanzen erzeugt bzw. bereit laufende beendet werden können. Mehrintanzfähige Diente, deren Anzahl an Intanzen zur Laufzeit fet it, werden al mehrere tatiche, nicht cale-out-fähige Diente modelliert. Je mehr Aktionen ein Dient untertützt, deto flexibler kann der Fuzzy Controller in Bezug auf Aunahmeituationen reagieren. 3 Dynamiche Allokationoptimierung AutoGlobe Kontrollkomponente (Controller) analyiert kontinuierlich den Zutand de Sytem baierend auf den Monitoringdaten und behebt Aunahmeituationen Aktion Bechreibung tart Starten eine Diente top Stoppen eine Diente cale-in Stoppen einer Dientintanz cale-out Starten einer Dientintanz cale-up Umziehen einer Dientintanz auf einen tärkeren Rechner cale-down Umziehen einer Dientintanz auf einen chwächeren Rechner move Umziehen einer Dientintanz auf einen gleich tarken Rechner increae-priority Erhöhen der Priorität eine Diente reduce-priority Senken der Priorität eine Diente Tabelle 1: Übericht über die Aktionen de Fuzzy Controller
Adaptive Kontrollkomponente (Controller) QoS-Überwachungytem 1 Fuzzy Controller 0,75 0,5 QoS-Monitor 0,25 0 0,25 0,5 0,75 1 Rechner Latituation Advior QoS-Monitor Rechner QoS-Monitor Latdaten-Archiv Rechner Abbildung 3: Architektur de Controller automatich. Der Controller it elbt ein Dient und fügt ich damit nahtlo in die AutoGlobe-Architektur ein. 3.1 Architektur de Controller Abbildung 3 zeigt die Architektur der Kontrollkomponente, die für die dynamiche Allokationoptimierung zutändig it. Für jeden Rechner und jeden Dient 2 it jeweil ein dedizierter QoS-Monitor zutändig. Jeder Monitor ermittelt die relevanten Daten eine Rechner bzw. eine Diente und endet diee an den zugehörigen Advior. Überwacht werden beipielweie die Aulatung eine Rechner und die Antwortzeiten eine Diente. Durch diee Daten hat der Controller tet einen aktuellen Überblick über die Latituation im Sytem und kann die QoS- Parameter überwachen. Überchreitet ein überwachter Parameter (z.b. CPU-Lat) eine Rechner bzw. eine Diente eine eintellbare Schranke, liegt eine Überlatituation vor.solche Überlat- und auch Fehlerituationen werden von den Advioren gemeldet und die entprechenden Latdaten werden dann für eine betimmte Dauer vom QoS-Überwachungytem beobachtet. Dadurch können kurze Latpitzen, die in realen Sytemen häufig auftreten, aber keine kritichen Situationen dartellen, augefiltert werden. Im Falle einer längerfritig andauernden Überlatituation wird der Fuzzy Controller angetoßen. Dieer wählt baierend auf der aktuellen Latituation und einer Regelbai eine Aktion au, um der Überlatituation entgegen zu wirken. Fall beipielweie eine CPU-Überlat eine Rechner fetgetellt wird, kann der Controller Diente von dem überlateten Rechner zu anderen im Moment nicht augelateten Rechnern umziehen. Auch bei Unterlatituationen chreitet der Controller (bei entprechender Regelbai) ein. Da Unterlatituationen konzeptuell wie Überlatituationen behandelt werden, wird im Weiteren nicht näher darauf eingegangen. Fehlerituationen, wie beipielweie der Abturz eine 2 Abbildung 3 zeigt nur die Monitore und Advioren zur Überwachung der Rechner. Au Überichtlichkeitgründen werden Diente, die auf den Rechnern laufen, owie die zugehörigen Monitore und Advioren weggelaen.
Diente, werden vom Controller z.b. durch einen Neutart behoben. Da Latdatenarchiv peichert verdichtete hitoriche Daten. Im Folgenden bechreiben wir die einzelnen Module genauer: QoS-Monitore und Advioren. Jeder Rechner und jeder Dient innerhalb der AutoGlobe-Umgebung wird von einem dedizierten QoS-Monitor überwacht, der die geammelten Daten an den zutändigen Advior de Controller chickt. Monitore ind pezielle Diente zur Überwachung de Reourcenverbrauch von Rechnern bzw. zur Überwachung de Reourcenverbrauch und der Quality of Service- Parameter von Dienten. QoS-Überwachungytem. Diee Komponente wird eingeetzt, um tatächliche Überlatituationen von kurzen, harmloen Latpitzen zu untercheiden. Dadurch werden Überreaktionen de Controller verhindert und ein ruhige, tabile Sytem erreicht. Fall ein Latwert oder ein QoS-Parameter eine eintellbare Schranke überchreitet, erfolgt für einen fetgelegten Zeitraum (watchtime) die Überwachung der entprechenden Daten. Nur fall da arithmetiche Mittel der Daten, die während diee Beobachtungzeitraum erfat werden, oberhalb der vorgegebenen Schranke liegt, wird die drohende QoS-Verletzung an den Fuzzy Controller gemeldet. Fuzzy Controller. Der Fuzzy Controller ermittelt baierend auf einem Regelatz und der aktuellen Latituation eine geeignete Aktion, um einer Überlatituation entgegen zu wirken. Dazu wird die Anwendbarkeit aller möglichen Aktionen (iehe Tabelle 1) betimmt und die bete augewählt. Fall die Aktion (z.b. move) einen Zielrechner zur Durchführung erfordert, bewertet der Fuzzy Controller die möglichen Rechner. Augeführt wird dann die Aktion mit der höchten Anwendbarkeit mit dem geeignetten Rechner al Zielrechner. Finden ich mehrere Aktionen bzw. Rechner mit demelben Wert wird zufällig au dieen augewählt. Latdatenarchiv. Da Latdatenarchiv peichert verdichtete Latdaten bzw. Werte von QoS-Parametern. Diee Daten werden zur Berechnung der Durchchnittlat während der watchtime und al Eingabedaten für den Fuzzy Controller verwendet. Außerdem werden ie zur Betimmung dientpezificher Latmuter herangezogen, die die Grundlage für tatiche Allokationoptimierungen dartellen. 3.2 Grundlagen eine Fuzzy Controller Fuzzy Controller ind pezielle Expertenyteme, die auf Fuzzy-Logik aufbauen [KY94]. Sie werden vor allem zur Regelung komplexer dynamicher Syteme verwendet, für die die Bechreibung de Sytemverhalten durch exakte mathematiche Modelle chwierig oder gar unmöglich it. Statt eine mathematichen Model verwenden Fuzzy Controller da Wien von menchlichen Experten in Form von linguitichen Variablen und Regeln. Eine Alternative zu Fuzzy Controllern tellen neuronale Netze dar. Die Trainingphae derartiger Controller getaltet ich aber ehr chwierig und man kann die erlernten Verhaltenweien al Adminitrator nur ehr chwer beeinfluen. Fuzzy-Logik it die Theorie der uncharfen Mengen, die ertmal von Lotfi Zadeh
cpuload ling. Variable cale-up 1 0.8 0.6 () l medium 0.5 0.4 µ = () l µ = high Zugehörigkeit 0.2 low medium high Auprägungen Zugehörigkeitfunktionen Zugehörigkeit 1 0.8 0.6 0.4 0.2 applicable abgechnittene, uncharfe Menge 0 0.2 0.4 l=0.6 0.8 1 CPU-Lat (a) Linguitiche Variable cpuload 0 0.2 0.4 a=0.6 0.8 1 Anwendbarkeit (b) Linguitiche Variable cale-up Abbildung 4: Zugehörigkeitfunktionen für linguitiche Variablen im Jahr 1965 bechrieben wurde [Zad65]. Die Zugehörigkeit von Elementen zu einer uncharfen Menge liegt zwichen 0 und 1 und wird mit einer Zugehörigkeitfunktion µ fetgelegt. Sei X eine normale Menge, dann it A = {(x, µ A (x)) x X} mit µ A : X [0, 1] eine Fuzzy-Menge bzw. uncharfe Menge auf X. DieZugehörigkeitfunktion µ A weit jedem Element von X eine reelle Zahl in [0, 1] zu. Eine größere Zahl bedeutet dabei einen höheren Zugehörigkeitgrad. Linguitiche Variablen ind Variablen, deren Zutände uncharfe Mengen ind. Die Zutände repräentieren Auprägungen wie z.b. low, medium oder high. Eine linguitiche Variable wird durch ihren Namen, eine Menge von Auprägungen und eine Zugehörigkeitfunktion pro Auprägung definiert. Ein Beipiel hierfür it die linguitiche Variable cpuload, die in Abbildung 4(a) dargetellt it. Die Abbildung zeigt die drei Auprägungen low, medium und high und deren Zugehörigkeitfunktionen. Abbildung 5 zeigt die Architektur eine Fuzzy Controller. Die adaptive Infratruktur wird überwacht (1). Treten Aunahmeituationen auf, tößt der Controller die Fuzzy-Auwertung an. In der Fuzzifizierungphae (2) werden die Medaten in uncharfe Mengen, die Eingabevariablen, überführt. Anchließend erfolgt mit ihnen die Auwertung der Regelbai (3). In der abchließenden Defuzzifizierungphae werden die ermittelten uncharfen Ergebnie in einen Vektor betehend au charfen Werten umgewandelt (4). Im Folgenden erklären wir die Arbeitweie de Fuzzy Controller anhand eine Beipiel zur Regulierung von Überlatituationen. In der Fuzzifizierungphae werden die charfen Mewerte (hier die CPU-Lat eine Rechner) in die entprechenden linguitichen Eingabevariablen (cpuload) überführt, indem die Zugehörigkeitgrade der einzelnen Auprägungen mittel der Zugehörigkeitfunktionen betimmt werden. So it beipielweie ein Rechner mit der gemeenen CPU-Lat l =0.6 zu0.5 mittel (medium) und zu 0.2 tark (high) augelatet (iehe Abbildung 4(a)). In der Inferenzphae wird die Regelbai baierend auf den uncharfen Eingabevariablen augewertet. Die Form der Regeln wird exemplarich anhand zweier einfacher Beipielregeln erklärt. Dabei ind cpuload und performanceindex Eingabe-,
Aktionen Überwachte adaptive Infratruktur (1) Medaten Defuzzifizierung (4) Fuzzifizierung (2) Inferenz (3) Regelbai Fuzzy Controller Abbildung 5: Architektur de Fuzzy Controller [KY94] cale-up und cale-out Augabevariablen. Der performanceindex gibt die relative Leitungfähigkeit von Rechnern an. Ein höherer Index bedeutet einen leitungtärkeren Rechner. IF (cpuload IS high AND (performanceindex IS low OR performanceindex IS medium)) THEN cale-up IS applicable IF (cpuload IS high AND performanceindex IS high) THEN cale-out IS applicable Die erte Regel agt au, da e innvoll it, einen Dient auf einen leitungtärkeren Rechner umzuziehen, fall eine hohe Rechenaulatung auf dem urprünglichen Rechner vorliegt und deen performanceindex low oder medium it. Da Hinzufügen einer zuätzlichen Intanz it der zweiten Regel zufolge dann innvoll, fall der Dient ohnehin bereit auf einem ehr leitungfähigen aber dennoch tark augelateten Rechner läuft. Konjunktionen von linguitichen Variablen in Vorbedingungen von Regeln werden mittel der Minimumfunktion verknüpft, Dijunktionen mit der Maximumfunktion. Al Beipiel ei die cpuload l = 0.9, dann ind die Zugehörigkeiten der Auprägungen µ low =0,µ medium = 0 und µ high =0.8. Bei einem gegebenen performanceindex i = 5 nehmen wir an, da die Zugehörigkeitgrade µ low =0,µ medium =0.6 und µ high = 0.3 ind. Dann ergibt ich für die Vorbedingung der erten Regel min(0.8, max(0.6, 0.3)) = 0.6 und für die der zweiten min(0.8, 0.3) = 0.3. Während in der klaichen Logik die Schlufolgerung wahr it, wenn die Vorbedingung wahr it, exitieren für die Berechnung einer Fuzzy-Schlufolgerung in der Literatur unterchiedliche Anätze. Wir verwenden die bewährte Max-Min- Inferenzfunktion. Mit dieer Funktion wird die uncharfe Ergebnimenge in Höhe der Zugehörigkeit der Vorbedingung abgechnitten. Umfat die Regelbai mehrere Regeln, die dieelbe Augabevariable betreffen, werden alle Ergebnie mittel der Maximumfunktion verknüpft. Die darau reultierenden, uncharfen Mengen ind da Ergebni der Inferenzphae, iehe Abbildung 4(b). In der Defuzzifizierungphae wird au den in der Inferenzphae ermittelten uncharfen Mengen ein Vektor charfer Werte berechnet. Hierfür verwenden wir eine Maximummethode, die den linken Randpunkt de Maximumbereich wählt. In unerem Beipiel it die der charfe Wert a =0.6, d.h. die Aktion cale-up it zu 0.6 anwendbar (iehe Abbildung 4(b)). Analog it die Aktion cale-out zu 0.3 anwendbar. Folglich wird der Controller die Aktion cale-up auführen. 3.3 Fuzzy Controller zur Latbalancierung AutoGlobe Fuzzy Controller-Modul etzt ich au zwei Fuzzy Controllern zuammen. Aufgabe de einen it e, geeignete Aktionen bei Eintreten von Aunahme-
Erkennen einer Aunahmeituation Erkennen einer Aunahmeituation Nein Andere Aktion Auwahl einer Aktion - Fuzzy Controller Fehler Ja Dient veruracht von? Rechner Für alle Diente auf dem Rechner Weiterer Rechner? Ja Auwahl eine Rechner Fuzzy Controller Fehler Weitere Aktion? Auwahl einer Aktion für einen Dient Auwahl einer Aktion für Dient 1 Auwahl einer Aktion für Dient 2... Auwahl einer Aktion für Dient n Fehler Erfolg Auführung der Aktion cale-in oder top Nein Prüfen der Bedingungen und Sortieren der Aktionen Erfolg Erfolg Fehler Geordnete Lite von Aktionen Abbildung 6: Ablaufdiagramm de Fuzzy Controller Modul Abbildung 7: Ablaufdiagramm für die Aktionauwahl ituationen zu betimmen. Fall die jeweilige Aktion einen Zielrechner erfordert, wird dieer mittel de zweiten Controller ermittelt. Abbildung 6 zeigt die Interaktion der beiden Fuzzy Controller Auwahl einer Aktion und Auwahl eine Rechner. NachdemAuführen einer Aktion werden die davon betroffenen Diente und Rechner für eine betimmte Zeit von weiteren Aktionen augechloen (geperrt). Dadurch wird ein Schwingen de Sytem, d.h. ein wiederholte Umziehen von Dienten, verhindert. Die Regelätze zur Steuerung de Fuzzy Controller können von erfahrenen Adminitratoren für einzelne bzw. mehrere Diente einmalig fetgelegt werden. Diee vorkonfigurierten Regelätze werden dann mit den Dienten augeliefert und können bei peziellen Wünchen individuell angepat werden. Analog kann bei den linguitichen Variablen verfahren werden. Dadurch enkt ich der Adminitratoraufwand erheblich. Ablauf der Aktionauwahl: Im erten Schritt werden die Eingabevariablen de Fuzzy Controller initialiiert. Für die beobachteten Mewerte wie CPU-Lat oder Antwortzeiten wird dazu da arithmetiche Mittel über den Beobachtungzeitraum (watchtime) berechnet. Die weiteren Variablen werden mit entprechenden Daten au der Konfiguration de Sytem (z.b. performanceindex) belegt. Eine Übericht über die Eingabevariablen it in Tabelle 2 gegeben. Der Controller untercheidet, ob eine Aunahmeituation durch einen Dient (bzw. Variable cpuload memload performanceindex intanceload erviceload intanceonserver intanceofservice Decription CPU-Lat auf dem Rechner (Durchchnittlat aller CPU) benötigter Hauptpeicher de Rechner Leitungfähigkeit de Rechner Durchchnittliche Lat aller Intanzen de Rechner Durchchnittliche Lat aller Intanzen de Diente Anzahl der Intanzen auf dem Rechner Anzahl der Intanzen de Diente Tabelle 2: Eingabevariablen für den Fuzzy Controller zur Auwahl einer Aktion
<rulebae name="erviceoverloaded"> <rule> <condition>cpuload i high and (performanceindex i low or performanceindex i medium)</condition> <action>cale-up i applicable</action> </rule> <rule> <condition>cpuload i high and performanceindex i high</condition> <action>cale-out i applicable</action> </rule>... </rulebae> Abbildung 8: Auzug der Regelbai für den Aulöer ervice-i-overloaded eine Dientintanz) oder durch einen Rechner augelöt wird (iehe Abbildung 7). Fall ein Dient der Aulöer it, entcheidet der Controller anhand von Informationen über die betroffene Intanz, allen weiteren Intanzen de Diente und dem Rechner auf dem die betroffene Intanz augeführt wird. Andere Diente, die auf demelben Rechner laufen, werden nicht berückichtigt. It ein Rechner der Aulöer, o werden Informationen über alle Diente auf dem entprechenden Rechner verwendet. Da die Auwahl der Aktion von der aulöenden Situation abhängt, verwendet uner Controller verchiedene Regelbaen für die verchiedenen Aulöer. Wir untercheiden derzeit zwichen folgenden Aulöern: Über- und Unterlat einer Diente, bzw. einer Dientintanz (ervice-i-overloaded und ervice-i-idle), owie Überund Unterlat eine Rechner (hot-i-overloaded und hot-i-idle). Durch Hinzufügen neuer Regelbaen können wichtige Diente individuell behandelt werden. Die kann beipielweie genutzt werden, um gechäftkritiche Datenbankdiente vorzugweie auf leitungtarken Rechnern auzuführen. Eine Regelbai etzt ich au mehreren Regeln zuammen, von denen jede au einer Vorbedingung und einer Schlufolgerung beteht. Abbildung 8 zeigt die Regeln au Abchnitt 3.2 al Teil der Regelbai für den Aulöer ervice-i-overloaded in unerer XML-Notation. Änderungen an Regeln und Regelbaen können zur Laufzeit vorgenommen werden. Der Fuzzy Controller zur Auwahl einer Aktion wertet die zutreffende Regelbai au und ermittelt charfe Werte für die Augabevariablen. Diee entprechen den in Tabelle 1 aufgeliteten Aktionen. Von dieen Aktionen kann der Controller allerding nur diejenigen auführen, die keine der von Adminitratoren fetgelegten Bedingungen verletzen. Beipielweie läuft eine traditionelle Datenbank normalerweie exkluiv auf einem Rechner. Aktionen, die derartige Bedingungen verletzen, werden al nicht anwendbar gekennzeichnet und im weiteren Ablauf ignoriert. Alle anderen Aktionen ind mit der Anwendbarkeit laut Regelbai annotiert. Wenn ein Rechner der Aulöer war, führen wir den Fuzzy Controller für jeden Dient auf dem Rechner au und ammeln alle möglichen Aktionen. Die Aktion mit der höchten Anwendbarkeit wird, ofern ie oberhalb einer vom Adminitrator vorgegebenen Schranke liegt, augeführt. Ablauf der Rechnerauwahl: Für die Aktionen cale-out, cale-up, cale-down,
Variable cpuload memload intanceonserver performanceindex numberofcpu cpuclock cpucache memory wapspace tempspace Bechreibung CPU-Lat auf dem Rechner (Durchchnittlat über alle CPU) benötigter Hauptpeicher de Rechner Anzahl der Intanzen auf dem Rechner Leitungfähigkeit de Rechner Anzahl der CPU de Rechner Gechwindigkeit de Prozeor Cache-Größe der CPU Größe de Hauptpeicher auf dem Rechner Größe de Swap Speicher Größe de verfügbaren, temporären Platttenpeicher Tabelle 3: Eingabevariablen für den Fuzzy Controller zur Auwahl eine Rechner move und tart müen jeweil Zielrechner betimmt werden. Dazu werden alle nicht-geperrten, für den Dient geeigneten Rechner mittel de zweiten Fuzzy Controller bewertet. Tabelle 3 zeigt die linguitichen Eingabevariablen de Fuzzy Controller zur Auwahl eine Rechner. Da die Auwahl eine Rechner von der durchzuführenden Aktion abhängt, tehen hier ebenfall verchiedene Regelbaen für die unterchiedlichen Aktionen zur Verfügung. Anhand der paenden Regelbai wird ermittelt, wie gut ich ein Rechner al Zielrechner eignet. Nach der Defuzzifizierung wird der geeignette Rechner augewählt. Umetzen der Entcheidung de Controller: Der Controller bietet einen vollautomatichen und einen halbautomatichen Modu. Im erten Fall werden Aktionen ohne Rückfrage augeführt, im zweiten Fall it eine Betätigung durch den Adminitrator erforderlich. Tritt bei der Auführung einer Aktion ein Fehler auf, wird der nächtbete Rechner al Zielrechner gewählt. Steht kein weiterer Rechner mehr zur Verfügung, wird die nächtbete Aktion gewählt, bi keine Aktion mehr zur Verfügung teht. It da der Fall, wird der Adminitrator über die graphiche Oberfläche de Controller darüber informiert. Die GUI zeigt außerdem da überwachte Sytem überichtlich an und ermöglicht e, Aktionen manuell auzulöen. 3.4 Experimentelle Ergebnie Zur Validierung der Leitungfähigkeitunerer prototypichenimplementierunghaben wir ein umfangreiche Simulationytem entwickelt, da eine typiche ERP- Intallation imuliert. Erte Studien zeigen, da durch den Einatz der dynamichen Optimierung unerer adaptiven Infratruktur bi zu 35% mehr Benutzeranfragen auf derelben Hardware bearbeitet werden können. Eine detailliertere Bechreibung de Simulationytem und der erzielten Ergebnie teht unter [Aut] zur Verfügung. Weitere Studien zeigen, da unere Kombination von dynamicher und taticher Optimierung weitere Leitungteigerungen ermöglichen. 4 Statiche Allokation Viele betriebwirtchaftliche Datenbankanwendungen weien ein regelmäßig wiederkehrende Verhalten auf, wa den Verbrauch an Reourcen wie CPU oder Arbeitpeicher, die Netzwerkaulatung oder auch die Anzahl angemeldeter Benut-
Aufbereitung der Zeitreihe - additive Überlagerung der Reihen der Intanzen - gleichmäßige Abtatung - ggf. Rauchelimination Berechnen d. Muterlänge - Näherunglöung mittel dikr. Frequenzpektrum - Nachiteration Ermitteln augewählter Startpunkte (og. Muldenpunkte) Mittelung - der Muterlänge - de Muterverlauf Aulatung Zeit Intenität m / N Frequenzkoeffizienten Aulatung Zeit Abbildung 9: Extraktion von Latmutern zer und Antwortzeiten betrifft. Kennzeichnend für einen Human Reource (HR)- Dient it etwa die Lat, die durch die Gehaltabrechnung am Ende eine jeden Monat entteht. E treten alo zyklich wiederkehrende Phaen auf, zu denen Diente tark augelatet ind. Anderereit gibt e auch Phaen, während derer Diente kaum benötigt werden. Kennt man da Verhalten der Diente, bietet e ich an, diejenigen mit komplementärer Charakteritik auf denelben und olche bei denen ich die Zeiten mit tarker Aulatung überchneiden auf unterchiedlichen Rechnern auzuführen. Dadurch laen ich kritiche Überlatituationen vermeiden. In dieem Abchnitt tellen wir Verfahren zur Extraktion von Latmutern und zur Berechnung taticher Allokationen vor. 4.1 Analye der Latdaten Zur Laufzeit werden für jede Dientintanz der Reourcenverbrauch bzw. die QoS- Parameter überwacht und gleichzeitig in ein Archiv gechrieben. Die geammelten Daten werden augewertet, um dientpezifiche, zyklich wiederkehrende Latmuter zu extrahieren. Auf welcher Art von Daten die Analye durchgeführt wird, it für die algorithmiche Vorgehenweie ohne Bedeutung, wehalb im Weiteren allgemeine Zeitreihen betrachtet werden. Die Zeitreihe eine Diente erhält man durch additive Überlagerung der Latdaten der einzelnen Intanzen. Für die Analye wird da klaiche Komponentenmodell (iehe [SS01]) der Zeitreihenanalye verwendet. Danach wird eine Reihe (x t ) 1 t N modelliert al x t = m t + k t + t + u t mit t {1,...,N}. Der Trend m t it eine monotone Funktion, die eine mittel- bi langfritige Auf- oder Abwärtbewegung modelliert. Die Retkomponente u t bechreibt Störeinflüe, die die Medaten überlagern und in einer Vorverarbeitungtufe eliminiert werden müen. Die zykliche Komponente etzt ich au der Überlagerung einer Konjunkturkomponente k t,dielängere, nicht notwendig regelmäßige Schwankungen repräentiert, und der Saion t, die regelmäßige und relativ unveränderte Schwankungen modelliert, zuammen. Abbildung 9 zeigt die Schritte zur Extraktion eine Latmuter. Zuert mu die Periode T, d.h. die Dauer eine Zyklu, ermittelt werden. Eine gängige Methode hierfür it die Auwertung de Stichprobenpektrum. Die Reihe (x t ), bzw. deren kontinuierliche Fortetzung, lät ich in eine äquivalente Dartellung von überlagerten harmonichen Schwingungen überführen. Die Funktion I (λ) mit Aulatung Zeit
Aulatung x ( E, xe ) δ ( l, x T ) l T Abbildung 10: Betimmen augewählter Startpunkte ( Muldenpunkte ) [ I (λ) = N C (λ) 2 + S (λ) 2],mitλ R und C (λ) = 1 (x t x) co 2πλt, S (λ) = 1 (x t x) in 2πλt N N 1 t N 1 t N gibt an, mit welcher Intenität die harmoniche Schwingung der Frequenz λ in der um den Mittelwert x bereinigten Reihe auftritt. Unter der biher gemachten Annahme, da ein Dient ein charakteritiche Latmuter aufweit, gilt, da die Intenitätfunktion an der Stelle 1/T ein globale Maximum annimmt. Die rechenintenive Auwertung von I (λ) kann umgangen werden, indem man zuert an den Stellen i/n mit i {1,...,N/2} auwertet und die Stelle m/n, anderda Maximum auftritt, betimmt. Da I (λ) ich mittel der Fouriertranformierten von (x t x) berechnen lät, it die, verwendet man die dikrete FFT (Fat Fourier Tranformation), ehr effizient. Durch eine nachfolgende iterative Auwertung von I (λ) in der Umgebung von m/n lät ich die Periodendauer T gut approximieren. Anchließend lät ich bereit ein Auchnitt der Zeitreihe al Muterapproximation extrahieren. Um ein Muter durch Mittelung der auftretenden Zyklen zu betimmen, müen die einzelnen Wiederholungen zuverläig extrahiert werden. Andernfall führt ein einfache Mitteln über Auchnitte der Länge T aufgrund von Rechenungenauigkeiten und Störungen von (x t ) im Allgemeinen zu getörten Daten. Benötigt werden markante Startpunkte für den Beginn eine jeden Zyklu. Um den Startpunkt de l-ten Zyklu zu finden, geht man wie in Abbildung 10 kizziert vor. Augehend von x lt, dem Mepunkt deen Index am nächten an l T und l T it, betimmt man da darauf folgende lokale Extremum x E. Für den Fall, da x lt x gilt, it die ein lokale Maximum, andernfall ein lokale Minimum. Anchließend betimmt man im Intervall [ lt,e] den Punkt S l mit maximalem Abtand δ zur Geraden, die durch ( lt, x) und (E,x E ) fetgelegt it. Mit dieer Vorgehenweie ratet die Suche anchaulich geprochen in einem Muldenpunkt (S l) ein, der al Startpunkt für den Zyklu verwendet wird. Der Vorteil diee Verfahren it, da keinerlei Parametriierung der Muterextraktion erforderlich it. Hat man die Startpunkte betimmt (vgl. Abbildung 9, Schritt 3), o mittelt man abchließend über die Wiederholungen. Vorauetzung für eine Extraktion it, da mindeten zwei Zyklen in der urprünglichen Zeitreihe auftreten. Um eine Mittelung durchzuführen, bedarf e mindeten vier Wiederholungen, da aufgrund der Verchiebung der Startpunkte und um unvolltändige Zyklen auzuchließen, jeweil da erte und letzte Vorkommen nicht berückichtigt werden. S l Zeit
l Dient t l (,1) Rechner 1 l + l l 1 1 t l Rechner 2 (,2) l l 2 2 t + l Abbildung 11: Greedy -Auwahl eine Rechner 4.2 Statiche Allokation der Datenbankdiente auf Rechner Baierend auf extrahierten Latmutern au Abchnitt 4.1 lät ich eine tatiche Allokation berechnen. Die Berechnung erfolgt dabei für eine eintellbare Zeitpanne der Dauer T, die in äquiditante Abchnitte unterteilt wird. Für dieen Zeitraum wollen wir eine Allokation finden, bei der erten die Rechner einen augewogenen Latverlauf haben und zweiten der Fuzzy Controller o wenig Aktionen wie möglich durchführen mu. Dazu verwenden wir unter anderem eine Greedy- Allokationheuritik. Diee allokiert Diente mit komplementären Reourcenbedürfnien auf dieelben Rechner. Zwei Diente weien beipielweie dann komplementäre Reourcenbedürfnie auf, wenn der eine vor allem tagüber Lat erzeugt während der andere vorwiegend nacht arbeitet. Zu Beginn der Greedy-Heuritik wird eine Sortierung der Diente bezüglich Klaifizierung (Replizierbarkeit und Verteilbarkeit, vgl. Abbildung 2), mittlerem Reourcenbedarf und Priorität ertellt. So werden tatiche, nicht cale-out-fähige Diente zuert eingeplant. Hardwarereourcen ollten bei der tatichen Allokationberechnung nicht volltändig eingeplant werden. Damit die Dientauführung icher getellt werden kann, mu auf jedem Rechner ein Reourcenpuffer vorhanden ein. Die Einplanunggrenze, welche von den Adminitratoren fetgelegt wird, gibt an bi zu welcher relativen Rechneraulatung Diente eingeplant werden. Die Aulatung eine Rechner oberhalb dieer Grenze wird al Überlatituation angeehen. Um die Funktionweie der Heuritik zu zeigen, nehmen wir an, da bereit einige Diente zugewieen ind. In einem nächten Schritt oll der Dient allokiert werden. Deen Reourcenbedarf it durch den Vektor (l (t) ) 1 t T bechrieben. l (t) bezeichnet den Reourcenbedarf de Diente zum Zeitpunkt t. Entprechend teht l c (t) für die bereit eingeplante Lat auf dem Rechner c zur Zeit t. l (t) und l c (t) tellen von einer pezifichen Rechenleitung unabhängige Werte dar. Allokation von nicht cale-out-fähigen Dienten: Betrachten wir zunächt den Fall, da ein nicht cale-out-fähiger Dient it. Dann wird volltändig auf dem Rechner eingeplant, auf dem die Maximallat durch Hinzunahme von am geringten anteigt und die nach der Einplanung unterhalb der vorgegebenen Einplanunggrenze liegt. Der abolute Latantieg durch Einplanung von auf c wird durch Formel (1) abgechätzt. (, c) = max 1 t T { l (t) c + l (t) } max 1 t T { l (t) c } (1)
Hierbei bezeichnet l c (t) die Lat vor der Einplanung de Diente zum Zeitpunkt t. Fall jeder Rechner eine höhere Maximallat al die Einplanunggrenze aufweit, wird derjenige mit der geringten Maximallat augewählt. Abbildung 11 verdeutlicht den Iterationchritt exemplarich anhand zweier Rechner. So fällt der Antieg der Maximallat auf Rechner 1 geringer au al auf Rechner 2. Allokation von cale-out-fähigen Dienten: Die Allokation von cale-outfähigen Dienten bietet mehr Freiheitgrade, da man diee in mehrere Intanzen aufteilen und omit auf mehrere Rechner verteilen kann. Dazu führen wir Variablen x,c ein. x,c bechreibt den Anteil der auf Rechner c augeführten Intanz de Diente am geamten Reourcenbedarf von. Im Folgenden wird x,c auch al Intanzgröße bezeichnet. Sie nimmt Werte zwichen 0 (keine Intanz auf dem Rechner) und 1 (kompletter Dient auf dem Rechner) an. Die tatiche Allokationoptimierung arbeitet in Kombination mit dem Dipatcher, der Benutzeranfragen proportional zu den vorgegebenen Intanzgrößen auf die Intanzen eine Diente verteilt. Bei der Allokation von cale-out-fähigen Dienten können verchiedene Strategien verwendet werden: Verbot von Überlatituationen: Diente dürfen Rechner höchten bi zur Einplanunggrenze aulaten. Begrenzter Zeitraum: Diente dürfen Überlatituationen auf Rechnern für begrenzte Zeit hervorrufen. Maximale Überlat: Diente dürfen Rechner bi zu einer fetgelegten Latgrenze oberhalb der Einplanunggrenze belaten. Begrenzte Durchchnittlat: Die durchchnittliche Aulatung eine Rechner darf die Einplanunggrenze nicht überchreiten. Die Wahl der Strategie hängt von der Verchiebbarkeit der Diente ab. Bei tatichen Dienten eignet ich die erte Strategie. Überlatituationen, die von dynamichen Dienten erzeugt werden, können durch die dynamiche Kontrollkomponente behandelt werden. Für diee Klae von Dienten eignen ich daher die übrigen Strategien. Abbildungen 12(a) und 12(b) verdeutlichen die Strategie Verbot von Überlatituationen anhand eine Beipiel. Fall ein cale-out-fähiger Dient nicht volltändig auf einem Rechner eingeplant werden kann (iehe Abbildung 12(a)), wird aufgeteilt. Dazu wird die maximal einplanbare Intanzgröße betimmt, die den Rechner nicht überlatet (iehe Abbildung 12(b)). Um den Einflu von Intanzgrößen zu berückichtigen wird Formel (1) erweitert zu: (, c) = { max l c (t) 1 t T } { + x,c l (t) max 1 t T l (t) c } x,c (2)
l Dient t l 75% Rechner c l + l c l c t l l Dient, Intanz 1 Dient, Intanz 2 t t l 75%, Intanz 1 Rechner c l + x l c c, l c t (a) Volltändige Einplanung (b) Scale-out Abbildung 12: Einplanen eine cale-out-fähigen Diente Die Auwahl de Rechner, auf den eine Intanz von ich am beten einplanen lät, erfolgt anhand der Kotenfunktion (3). Die Aufteilung von in viele, relativ kleine Intanzen wird verhindert. Die wird zum einen durch die Neudefinition von (, c) berückichtigt und zum anderen erfolgt eine Betrafung einer Aufteilung durch den zweiten Term der Kotenfunktion (3) je kleiner (angegeben durch 0 <x,c 1) eine einzuplanende Intanz it, deto größer ind die durch dieen Term modellierten Koten. Der Einflu lät ich anhand der Gewichte α und β variieren. Θ(, c) =α (, c)+ β x,c (3) Verwendet man eine der anderen Strategien, o mu in die Kotenfunktion eine Betrafung der vorauichtlichen Überlatituationen mit aufgenommen werden. Zwar ind Überlatituationen prinzipiell erlaubt, dennoch müen ie nach Möglichkeit vermieden werden. Die Heuritik wählt in jedem Schritt den Rechner ĉ au, für den die Kotenabchätzung (3) den geringten Wert annimmt. Auf dieen wird eine Intanz der Größe x,ĉ de Diente eingeplant. In den folgenden Iterationchritten werden die retlichen Anteile von auf anderen Rechnern eingeplant. Die Greedy-Heuritik bricht ab, obald alle Diente volltändig eingeplant ind, d.h. eine tatiche Allokation berechnet wurde. 4.3 Übernahme der tatichen Allokation Eine neu berechnete Allokation kann entweder automatich oder manuell übernommen werden. Vor der automatichen Übernahme prüft da Sytem, ob ie der aktuellen Allokation vorzuziehen it. In den Vergleich beider Allokationen fließen Koten für die dazu notwendige Reallokation der Diente ein. Der Vorteil der neuen, alternativen Allokation gegenüber der aktuellen, wird anhand einer Auwertung von (zu erwartenden) Über- und Unterlatituationen der verwendeten Rechner bewertet. Bei manueller Änderung der Allokation dient diee Bewertung den Adminitratoren al Entcheidunghilfe. 5 Verwandte Arbeiten In [WMHZ02] wird der Nutzen automaticher Tuningkonzepte für Datenbankyteme hervorgehoben. Demzufolge oll eine entprechende Überwachungkomponente eingeetzt werden, die folgende drei Phaen abdeckt: Beobachtung, Vorherage und
Reaktion. [MLR03] tellt den Anfrageoptimierer von IBM DB2 vor, der ich durch die eigentändige Optimierung auzeichnet, indem z.b. zugrunde liegende Kotenmodelle und ertellte Statitiken ohne Benutzerinteraktion angepat werden. Merkmale einer adaptiven Infratruktur, wie Selbtkonfiguration, Selbtoptimierung und eigentändige Fehlerbehebung, ind zunehmend in aktuellen bzw. zukünftigen Verionen kommerzieller Datenbankyteme umgeetzt. Neue Adminitration- und Managementanätze von IBM DB2, Microoft SQL Server und Oracle 10g wurden in [CDL04] vorgetellt. Bei dieen Selbtadminitrierung-Konzepten der DBMS- Herteller wird allerding da Datenbankytem ioliert betrachtet. Die reicht aber nicht au um den Endnutzern ein durchgängige Quality-of-Service-Management der datenbankbaierten Diente zu gewährleiten. Hierzu mu man da Geamtytem, alo Datenbankanwendungen inkluive den darunter liegenden Datenbanken, optimieren. Hier etzt uner Projekt an, in dem wir eine adaptive Infratruktur für dientbaierte, heterogene Sytemlandchaften entwickeln. Die Grid-Infratruktur tellt Techniken für die Integration verteilter Datenbanken und allgemeiner Reourcen bereit. Mit der Definition von Monitoring- und Tuning- Konzepten für Grid-Anwendungen befat ich die Performance Working Group de Global Grid Forum [GGFa]. In [Bou01] werden Terminologie und Konzepte von Latbalancierung vorgetellt und auf die Komplexität der Latverteilung für Rechnerlandchaften eingegangen. Methoden der Latbalancierung für parallele Datenbankyteme werden in [RM95, RM96] unterucht. [FA04] präentiert ein neue Konzept zur dynamichen Anpaung einer dientbaierten Software-Architektur, um zur Laufzeit z.b. auf Reourcenengpäe zu reagieren. In [ADZ00] wird eine Methode zur Reourcenverteilung in einem Rechnercluter vorgetellt, welche auf der individuellen Reourcenverteilung der einzelnen Rechner baiert. [RBSS02] befat ich mit der Skalierung von DB-Anwendungen durch Replizierung und behandelt diebezüglich Apekte der Kohärenz (Aktualität) der Daten. Mit Autonomia [DHX + 03] und Automate [ABL + 03] exitieren Forchungprojekte, die Apekte einer adaptiven Infratruktur, wie Selbtoptimierung, und eigentändige Fehlerbehebung realiieren. In dem verteilt aufgebauten Sytem AutoMate teilen die überwachten Diente dem Sytem Informationen wie beipielweie ihren Reourcenbedarf und aktuellen Zutand mit. Die erfordert, im Gegenatz zu AutoGlobe, die Anpaung der Diente an da Sytem. Ferner untercheidet ich AutoGlobe von Autonomia und AutoMate hinichtlich der auf einen Fuzzy Controller baierenden Kontrollkomponente. Dadurch lät ich die kontinuierliche Überwachung und die Reaktion auf Aunahmeituationen flexibel konfigurieren und adminitrieren. 6 Zuammenfaung und Aublick In dieem Beitrag haben wir eine adaptive Infratruktur für dientbaierte Datenbankanwendungen vorgetellt, die die zunehmende Komplexität derartiger Syteme handhabbar macht und eine zuverläige und kotengüntige Bereittellung der Diente ermöglicht. Uner Anatz baiert auf einer Kombination von taticher und dynamicher Optimierung der Dient-Rechner-Allokation. Da Ergebni
der tatichen Optimierung it eine längerfritig augelegte Verteilung der Diente auf die verfügbare Hardware. Zur Laufzeit werden Aunahmeituationen automatich erkannt und durch einen auf Fuzzy-Logik baierenden Controller behoben. Da bei einer guten tatichen Dient-Rechner-Allokation zur Laufzeit weniger Aunahmeituationen auftreten, führt die Kombination von taticher und dynamicher Allokation zu einem augeglicheneren und ruhigeren Sytemverhalten. Die Konzepte zur tatichen und dynamichen Optimierung wurden al Erweiterung de ServiceGlobe-Sytem im Rahmen de AutoGlobe-Projekt prototypich realiiert. Anhand umfangreicher Simulationtudien [Aut] wurde die Leitungfähigkeit der Infratruktur gezeigt. Da bilang größte Sytem, auf dem der Prototyp eingeetzt wurde, um eine volltändige ERP-Intallation zu überwachen, it ein Blade-Sytem mit ingeamt 160 Prozeoren. Die Forchungen im Rahmen von AutoGlobe werden in folgende Richtungen weitergeführt: Zum einen wird unterucht, wie Latmuter, die bei der tatichen Optimierung gewonnen werden, auch zur Verbeerung der dynamichen Optimierung beitragen können. Darüber hinau werden Dipatcher, die Anfragen auf die verchiedenen Intanzen eine Diente verteilen, tärker mit der tatichen und der dynamichen Kontollkomponente verzahnt. Letztendlich oll AutoGlobe die Grundlage für ein umfaende QoS-Management bilden, da Verfügbarkeit (availability), Leitungfähigkeit (performability) und Vorheragbarkeit (predictability) der Datenbankdiente umfat. Dankagung Wir bedanken un bei den Herren Wolfgang Becker, Ingo Bohn, Thorten Dräger und Daniel Scheibli von der SAP Adaptive Computing Infratructure Abteilung für ihre Kooperation. Außerdem danken wir den Herren Stefan Aulbach, Tobia Brandl, Michael Denk, Stefan Krompaß und Thoma Schelchhorn für die Hilfe bei der Implementierung de Sytem. Literatur [ABL + 03] M. Agarwal, V. Bhat, H. Liu, V. Matoan, V. Putty, C. Schmidt, G. Zhang, L. Zhen, M. Parahar, B. Khargharia und S. Hariri. AutoMate: Enabling Autonomic Application on the Grid. In Proceeding of the International Workhop on Active Middleware Service (AMS), Seiten 48 59, Seattle, WA, USA, Juni 2003. [ACKM03] G. Alono, F. Caati, H. Kuno und V. Machiraju. Web Service: Concept, Architecture and Application. Springer Verlag, September 2003. [ADZ00] M. Aron, P. Druchel und W. Zwaenepoel. Cluter Reerve: A Mechanim for Reource Management in Cluter-baed Network Server. In Meaurement and Modeling of Computer Sytem, Seiten 90 101, 2000. [Aut] AutoGlobe Simulation Studie. http://www-db.in.tum.de/reearch/ project/autoglobe. [Bou01] T. Bourke. Server Load Balancing. O Reilly & Aociate, Sebatopol, CA, USA, 2001.
[CDL04] S. Chaudhuri, B. Dageville und G. Lohman. Self-Managing Technology in Databae Management Sytem. Tutorial at the International Conference on Very Large Data Bae (VLDB), Toronto, Canada, September 2004. [DHX + 03] X. Dong, S. Hariri, L. Xue, H. Chen, M. Zhang, S. Pavuluri und S. Rao. Autonomia: An Autonomic Computing Environment. In Proceeding of the International Performance Computing and Communication Conference (IP- CCC), Seiten 61 68, Phoenix, AZ, USA, April 2003. [FA04] P. Falcarin und G. Alono. Software Architecture Evolution through Dynamic AOP. In Proceeding of the Firt European Workhop on Software Architecture (EWSA), Jgg. 3047, Seiten 57 73, St. Andrew Scotland, 2004. [Fle] FlexFrame für mysap Buine Suite. http://www.fujitu-iemen.de/ rl/mobility/flexframe.html. [GGFa] Grid Monitoring Architecture Working Group of the Global Grid Forum (GGF). http://www-didc.lbl.gov/ggf-perf/gma-wg/. [GGFb] Scheduling and Reource Management Area of the Global Grid Forum (GGF). http://forge.gridforum.org/project/rm/. [KL04] D. Komann und F. Leymann. Web Service. In Informatik-Spektrum, Jgg. 27(2), Seiten 117 128, 2004. [KSK03] M. Keidl, S. Seltzam und A. Kemper. ServiceGlobe: Flexible and Reliable Web Service on the Internet (Poter Preentation). In Proceeding of the International World Wide Web Conference (WWW), Budapet, Hungary, Mai 2003. [KY94] G. J. Klir und B. Yuan. Fuzzy Set and Fuzzy Logic: Theory and Application. Prentice Hall, Upper Saddle River, NJ, USA, 1994. [MLR03] V. Markl, G. M. Lohman und V. Raman. LEO: An Autonomic Query Optimizer for DB2. IBM Sytem Journal, 42(1):98 106, 2003. [RBSS02] U. Röhm, K. Böhm, H.-J. Schek und H. Schuldt. FAS a Frehne-Senitive Coordination Middleware for a Cluter of OLAP Component. In Proceeding of International Conference on Very Large Data Bae (VLDB), Seiten 754 765, Hong Kong, China, Augut 2002. Morgan Kaufmann Publiher. [RM95] E. Rahm und R. Marek. Dynamic Multi-Reource Load Balancing in Parallel Databae Sytem. In Proceeding of the International Conference on Very Large Data Bae (VLDB), Seiten 395 406, 1995. [RM96] E. Rahm und R. Marek. Dynamic Load Balancing in Parallel Databae Sytem. In Proceeding of EURO-PAR, Jgg. 1123 of Lecture Note in Computer Science (LNCS), Seiten 37 52, Lyon, 1996. [SBK01] S. Seltzam, S. Börzönyi und A. Kemper. Security for Ditributed E-Service Compoition. In Proceeding of the International Workhop on Technologie for E-Service (TES), Jgg. 2193 of Lecture Note in Computer Science (LNCS), Seiten 147 162, Rome, Italy, September 2001. [SS01] Rainer Schlittgen und Bernd Streitberg. Zeitreihenanalye. R. Oldenbourg Verlag, 9. Auflage, 2001. [Wei99] G. Weikum. Toward Guaranteed Quality and Dependability of Information Service. In Alejandro P. Buchmann, Hrg., 8th GI Fachtagung: Datenbankyteme in Büro, Technik und Wienchaft, Seiten 379 409, Freiburg, Germany, 1999. Springer Verlag. [WMHZ02] G. Weikum, A. Mönkeberg, C. Hae und P. Zabback. Self-tuning Databae Technology and Information Service: from Wihful Thinking to Viable Engineering. In Proceeding of the International Conference on Very Large Data Bae (VLDB), Seiten 20 31, Hong Kong, China, Augut 2002. [Zad65] L. A. Zadeh. Fuzzy Set. Information and Control, 8(3):338 353, 1965.