5 UML-Metamodell f ¨ ur Service Level Agreements
5.1 Grundlegende Modellierung
5.1.3 Kundenspezifische Dienstg ¨ uteparameter
H¨aufig reicht die Verwendung von vordefinierten Dienstg¨uteparametern innerhalb von Ser-vice Level Agreements nicht aus. Kundenspezifische Dienstg¨uteparameter erm¨oglichen die Definition von SLA-Parametern, die exakt auf die Bed¨urfnisse einzelner Dienstnehmer zuge-schnitten werden k¨onnen.
Im Gegensatz zu den vordefinierten Dienstg¨uteparametern, deren Berechnung nicht model-liert wird, sondern als Black-Box betrachtet wird, ist bei kundenspezifischen SLA-Parametern die Festlegung der Berechnungsvorschrift Teil der Modellierung, die dadurch aufwendiger wird.
Allgemein werden Dienstg¨uteparameter mit Hilfe von Metriken der Dienstelemente berech-net. Abbildung5.4 zeigt das Metamodell zur Definition kundenspezifischer Dienstg¨utepara-meter. Das Metamodell enth¨alt die folgenden Klassen:
Metric Die zentrale Klasse f¨ur die Modellierung von Kenngr¨oßen des Systems ist die Klas-se Metric, die von der UML-Metaklasse Classifier abgeleitet ist. Das Attribut units definiert die Einheiten, in denen der Wert der Metrik angegeben wird, z.B.
Transaktionen pro Sekunde bei der Berechnung des Durchsatzes. Das Attribut type
5 UML-Metamodell f¨ur Service Level Agreements
Abbildung 5.4: UML-Metamodell zur Definition kundenspezifischer Dienstg¨uteparameter legt den Datentyp der Metrik fest. G¨ultige Werte dieses Attributs sind durch die Auf-z¨ahlung MetricDataTypedefiniert, der einfache Standarddatentypen wieintund floatdefiniert.
Die abstrakte Klasse Metric bildet die Basisklasse f¨ur weitere spezialisierte Metrik-klassen.
Constant Die KlasseConstantrepr¨asentiert eine Konstante, deren Wert ¨uber ihr Attribut valuedefiniert ist. Hierbei wird der Wert der Konstanten als Zeichenkette repr¨asentiert und muss dann zur Laufzeit entsprechend des Datentyps der Konstante umgewandelt werden.
ElementMetric Die Klasse ElementMetricbeschreibt eine einfache Kenngr¨oße, die direkt von einem Dienstelement erfragt werden kann, z.B. die Anzahl der empfangenen Pakete, die von einem SNMP-Agenten im Rahmen der MIB-II [MR91] zur Verf¨ugung gestellt werden. Der Zugriff auf eine solche Metrik wird nicht im Rahmen des
SLA-5.1 Grundlegende Modellierung
Musters beschrieben, sondern erst w¨ahrend der Transformation des SLA-Musters in eine SLA-Instanz festgelegt. Dies erm¨oglicht die Bindung eines SLA-Musters an un-terschiedliche Plattformen, d.h. es ist nicht zwingend erforderlich, dass die Metrik von einem SNMP-Agenten zur Verf¨ugung gestellt wird, sondern sie kann ebenso von einem CIM Object Manager bereitgestellt werden, ohne dass dies Einfluss auf die Struktur des SLA-Musters hat. Typischerweise wird der Wert einer solchen Metrik in regelm¨aßigen Intervallen erfragt. Das Abfrageintervall wird durch das Attributintervaldefiniert, welches das Intervall in Sekunden spezifiziert.
ArithmeticMetric Die KlasseArithmeticMetric beschreibt eine Kenngr¨oße, de-ren Wert mit Hilfe einfacher mathematischer Operationen berechnet wird. Die zul¨assi-gen Operationen sind in der Aufz¨ahlungArithmeticOperatordefiniert:+(Plus), - (Minus), * (Times) und / (Divide). Die f¨ur eine Instanz von Arithmetic-Metriczu verwendende Operation wird durch ihr Attributoperatorfestgelegt. Der Datentyp der Berechnung wird durch das Attribut calcResultTypedefiniert, wel-ches vom TypMetricDataTypeist. Hierdurch kann eine Typkonvertierung des Er-gebnisses erreicht werden. Beispielsweise kann durchCalcResultType festgelegt werden, dass das Ergebnis der Berechnung als Integer-Zahl dargestellt wird, obwohl die Berechnung zu einer rationalen Zahl f¨uhrt. Der Datentyp der Berechnung (Attri-but calcResultType) und der Wert der Metrik (geerbtes Attribut type) k¨onnen unterschiedliche Werte haben. Dies f¨uhrt dann zur Laufzeit zu einer entsprechenden Konvertierung.
Eine arithmetische Metric besitzt genau zwei Operanden, die wiederum ein Subtyp der Klasse Metric sind. Diese Operanden werden mit Hilfe zweier Assoziationen zwi-schen der arithmetizwi-schen Metrik und beliebigen anderen Metriken realisiert. Da die Operationen Minus und Divide nicht kommutativ sind, muss im Metamodell spe-zifizierbar sein, welche Operand der erste ist und welcher der zweite. Dies wird durch den Einsatz von Rollennamen erreicht. Hierbei identifiziert die Metrik in der RolleOp1 den ersten Operanden und die Metrik in der RolleOp2den zweiten Operanden.
F¨ur die kommutativen OperationenPlusundTimesm¨ussen ebenfalls die beiden Rol-len angegeben werden. Dies erscheint auf den ersten Blick ¨uberfl¨ussig, l¨ost aber ein an-deres Problem. Bei der Definition von Metriken entstehen schnell komplexe Graphen.
Um diese maschinell bearbeiten zu k¨onnen, m¨ussen die Kanten des Graphen (zwischen den Metriken) gerichtet sein, damit die Berechnungsbeziehungen korrekt erfasst werden k¨onnen. Dies ließe durch die Angabe einer Navigationsrichtung f¨ur eine Assoziation zwischen Metriken realisieren. Da durch die Nicht-Kommutativit¨at der arithmetischen OperationenMinusundDivideder Einsatz von Rollennamen ohnehin notwendig ist, werden diese auch dazu verwendet, um die Navigationsrichtung festzulegen. Auf die-se Weidie-se kann auf die explizite Festlegung der Navigationsrichtung im UML-Modell verzichtet werden. Prinzipiell bekommt immer die abh¨angige Klasse den Rollennamen
5 UML-Metamodell f¨ur Service Level Agreements
zugewiesen, d.h. im Falle einer arithmetischen Metrik, die Metrikklassen, die die Ope-randen repr¨asentieren.
CustomMetric Die KlasseCustomMetricerlaubt die Berechnung einer Kenngr¨oße mit Hilfe eines Ausdrucks, der in dem Attribut calcExpressionals String gespeichert ist. Abschnitt5.2.1beschreibt die Verwendung der Object Constraint Language zur For-mulierung dieser Ausdr¨ucke, mit denen Berechnungen kompakt beschreibbar sind.
TimeSeries Die statistischen Funktionen operieren ¨uber einer Wertemenge, die von der Klasse TimeSeries zur Verf¨ugung gestellt werden. Das Attribut windowdefiniert die Anzahl der Elemente innerhalb der Wertemenge, d.h. eine TimeSeries-Instanz speichert immer diewindow-letzten Werte einer Metrik. Eine TimeSeries-Instanz repr¨asentiert damit einen bestimmten Ausschnitt der historischen Metrikdaten. Wird das Attributwindowauf den Wert 0 gesetzt, werden alle Daten gespeichert.
Da eineTimeSeriesdie Werte von Metriken speichert, muss einerTimeSeries ei-ne andere Metrik mit Hilfe eiei-ner Assoziation zugewiesen werden. Die assoziierte Metrik agiert hierbei in der RolleValues. Zul¨assig sind Assoziationen zu Konstanten, einfa-chen Metriken sowie arithmetiseinfa-chen und statistiseinfa-chen Metriken. Da eineTimeSeries nicht von der abstrakten Basisklasse Metricabgeleitet ist, ist eine Assoziation zwi-schen einzelnenTimeSeriesnicht m¨oglich.
TSSelect Mit Hilfe der Klasse TSSelect k¨onnen einzelne Elemente aus einer Time-Seriesentnommen werden. Dabei spezifiziert das Attributelement, das wievielte Element der TimeSeriesentnommen werden soll. Hierbei definiert der Attributwert 0 das zuletzt in dieTimeSerieseingef¨ugte Element. Negative Attributwerte bezeich-nen zur¨uckliegende Elemente der TimeSeries, z.B. bezeichnet -1 das Element vor dem letzten, usw.
StatisticalMetric Die KlasseStatisticalMetricf¨uhrt statistische Berechnun-gen durch. Die verf¨ugbaren statistischen Funktionen werden mit Hilfe der Aufz¨ahlung StatisticalFunctionTypedefiniert (vgl. [LKD+03]):
• Min: Berechnung des Minimalwerts aus einer Wertemenge
• Max: Berechnung des Maximalwerts aus einer Wertemenge
• Mean: Berechnung des arithmetischen Mittels einer Wertemenge
• Median: Berechnung des Medians einer Wertemenge
• StdDev: Berechnung der Standardabweichung einer Wertemenge
• Size: Anzahl der Elemente in einer Wertemenge
• Mode: Modalwert einer Wertemenge
• Round: Rundung eines Gleitkommawerts auf eine angegebene Anzahl von Stellen
5.1 Grundlegende Modellierung
• Sum: Summe der Elemente in einer Wertemenge
• ValueOccurs: Anzahl des Auftretens eines Wertes in einer Wertemenge
• Span: Anzahl, wie h¨aufig ein Wert innerhalb einer Wertemenge hintereinander aufgetreten ist
• RateOfChange: ¨Anderungsh¨aufigkeit von Werten in einer Wertemenge
• PercentageLessThanThreshold: Prozentsatz der Elemente in einer Wer-temenge, die kleiner als ein Referenzwert sind
• PercentageGreaterThanThreshold: Prozentsatz der Elemente in einer Wertemenge, die gr¨oßer als ein Referenzwert sind
• NumberLessThanThreshold: Anzahl der Elemente in einer Wertemenge, die kleiner als ein Referenzwert sind
• NumberGreaterThanThreshold: Anzahl der Elemente in einer Wertemen-ge, die gr¨oßer als ein Referenzwert sind
Das Attributfunctionlegt fest, welche statistische Funktion eine Instanz von Sta-tisticalMetricverwendet. Der Datentyp der statistischen Berechnung wird durch das AttributfunctionReturnTypedefiniert, welches von TypMetricDataType ist. Analog zur KlasseArithmeticMetricwird zur Laufzeit eine Typkonvertierung durchgef¨uhrt, wenn sich die durchTypeundFunctionReturnTypedefinierten Da-tentypen unterscheiden.
Eine StatisticalMetric wird auf der Basis der Werte berechnet, die in einer TimeSeriesgespeichert sind. Die jeweiligeTimeSerieswird mit Hilfe einer As-soziation bestimmt, wobei dieTimeSeriesin der RolleTSagiert. Hierbei kann eine TimeSeries von mehreren StatisticalMetric-Instanzen verwendet werden.
Im Idealfall werden die Werte f¨ur die statistischen Berechnungen damit nur einmal ge-halten, wodurch zum einen eine konsistente Datenbasis zur Verf¨ugung steht und zum anderen Redundanzen vermieden werden. Zu beachten ist allerdings, dass hier nur die Modellierung betrachtet wird, d.h. beim Binden an eine konkrete Plattform kann es trotzdem zur redundanten Speicherung von Daten kommen, wenn die Plattform eine gemeinsame Nutzung der Datenbasis durch mehrere Metriken nicht unterst¨utzt.
Wie in Abbildung5.4dargestellt, wird die KlassePreDefSLAParammit der Klasse Ele-mentMetric assoziiert. Dies bedeutet, dass der Wert des vordefinierten Dienstg¨utepara-meters durch die assoziierteElementMetric bestimmt wird. Die Berechnung des Kenn-gr¨oßenwertes ist hierbei durch die Klasse ElementMetric gekapselt und erscheint als Black-Box.
Tabelle 5.4 (Stereotypen) und Tabelle 5.5 (Tagged Values) beschreiben das UML-Profil zur Beschreibung kundenspezifischer Dienstg¨uteparameter.
5 UML-Metamodell f¨ur Service Level Agreements
Metamodell-Element Stereotype UML-Basisklasse Parent Tags
Metric Metric Classifier N/A description
units type value ElementMetric ElementMetric Classifier Metric interval ArithmeticMetric ArithmeticMetric Classifier Metric operator
calcResultType
TimeSeries TimeSeries Classifier N/A window
TSSelect TSSelect Classifier Metric element
StatisticalMetric StatisticalMetric Classifier Metric function
funcReturnType CustomMetric CustomMetric Classifier Metric calcExpression enumeration MetricDataType Enumeration N/A
MetricDataType
enumeration StatisticalFunction Enumeration N/A StatisticalFunction
enumeration ArithmeticOperator Enumeration N/A ArithmeticOperator
Tabelle 5.4: Stereotypen zur Modellierung kundenspezifischer Dienstg¨uteparameter
Metamodell- Tag Stereotype Typ Multiplizit¨at
Attribut
description description Metric String 0..1
units units Metric String 1
type type Metric MetricDataType 1
value value Metric String 1
interval interval ElementMetric long 1
operator operator ArithmeticMetric ArithmeticOperator 1 calcResultType calcResultType ArithmeticMetric MetricDataType 1
window window TimeSeries integer 1
element element TSSelect integer 1
function function StatisticalMetric StatisticalFunction 1 funcReturnType funcReturnType StatisticalMetric MetricDataType 1
calcExpression calcExpression CustomMetric String 1
Tabelle 5.5: Tagged Values zur Modellierung kundenspezifischer Dienstg¨uteparameter Abbildung5.5 zeigt die Modellierung der Dienstg¨uteparameter TradingAvailability undQueryAvailability aus dem in Abbildung 5.2 dargestellten Beispiel in Abschnitt 5.1.1. Den Dienstg¨uteparametern ist jeweils eine Metrik zugeordnet (QueryUptimeRatio undTradingUptimeRatio), mit deren Hilfe der Wert des jeweiligen Dienstg¨uteparame-ters berechnet wird.
5.1 Grundlegende Modellierung
Abbildung 5.5: Beispiel f¨ur die Modellierung der SLA-Parameter
Da f¨ur den SLA-Parameter QueryAvailabilityein vordefinierter Dienstg¨uteparameter (siehe Abschnitt 5.1.2) gew¨ahlt wurde, ist die weitere Modellierung trivial. Entsprechend dem in Abbildung 5.3 dargestellten Metamodell wird ein vordefinierter
Dienstg¨uteparame-5 UML-Metamodell f¨ur Service Level Agreements
ter mit einerElementMetricassoziiert. Im vorliegenden Beispiel ist dies die Kenngr¨oße QueryUptimeRatio, die in einem Intervall von 60 Sekunden aktualisiert wird. Wie die Be-rechnung des Metrikwertes erfolgt, ist hierbei verborgen und liegt nicht in der Verantwortung des Systems, das mit dem SLA-Muster, bzw. mit einer SLA-Instanz davon, parametrisiert wird. Es wird vorausgesetzt, dass eine entsprechende Informationsquelle existiert, z.B. ein SNMP-Agent oder ein CIM Object Manager, der die Kenngr¨oße bestimmt und zur Verf¨ugung stellt.
Im vorliegenden Beispiel wird davon ausgegangen, dass f¨ur die Bestimmung des kundenspezi-fischen Dienstg¨uteparametersTradingAvailabilitykeine Kenngr¨oße existiert, die un-mittelbar den Wert des SLA-Parameters bestimmt. W¨urde in eine solche Kenngr¨oße existieren, k¨onnte sie auch direkt mitTradingAvailabilityassoziiert werden, wie dies f¨ur vorde-finierte Dienstg¨uteparameter der Fall ist. Im vorliegenden Beispiel wird davon ausgegangen, dass die mit einer Instanz des SLA-Musters parametrisierte Managementplattform f¨ur die Be-rechnung der SLA-Parameterwerte selbst verantwortlich ist. Daher muss die BeBe-rechnungsvor- Berechnungsvor-schrift im Rahmen des SLA-Musters definiert werden.
Die mit TradingAvailability assoziierte arithmetische Metrik TradingUptime-Ratio repr¨asentiert die Verf¨ugbarkeit des TradingService-Teildienstes. Hierbei wird die Verf¨ugbarkeit auf der Basis der Messwerte der letzten Stunde ermittelt. Die Metrik Trad-ingUptimeRatiowird berechnet, indem zuerst jede Minute die Verf¨ugbarkeit des Diens-tes ¨uberpr¨uft wird. Dieser Wert wird durch die MetrikServiceStatuszur Verf¨ugung ge-stellt, deren aktueller Wert alle 60 Sekunden in der ZeitreiheHourlyStatusTSgespeichert wird. Diese Zeitreihe definiert ein Sliding Window mit 60 Werten. Die statistische Metrik NumHourlyFailuresbestimmt die Anzahl der F¨alle, in denen der Dienst nicht erreichbar war. Dies geschieht durch die Bestimmung der Anzahl der Elemente vonHourlyStatusTS, die dem Referenzwert Null (definiert durch den Wert den KonstanteC3) entsprechen. Diese Anzahl wird durch 60 (Wert der Konstante C2) geteilt und ergibt den Wert der arithmeti-schen Metrik HourlyDowntimeRatio. Um die Verf¨ugbarkeit des TradingService-Teildienstes (arithmetische MetrikTradingUptimeRatio) zu bestimmen, muss der Wert der Metrik HourlyDowntimeRatio von Eins (Wert der Konstante C1) subtrahiert wer-den. Befinden sich beispielsweise 15 mal der Wert 0 in der ZeitreiheHourlyStatusTS, so ergibt sich eine Verf¨ugbarkeit von1− 1560 = 0,75.
Zu erw¨ahnen ist, dass bei der Definition der Metrikabh¨angigkeiten Kenngr¨oßen zur Berech-nung mehrerer h¨oherwertiger Metriken herangezogen werden k¨onnen, indem Teilausdr¨ucke gemeinsam genutzt werden k¨onnen. Beispielsweise k¨onnte eine weitere statistische Metrik eine andere Auswertung auf den Werten der ZeitreiheHourlyStatusTSdurchf¨uhren. Auf diese Weise k¨onnen Redundanzen in der Modellierung vermieden und ein konsistentes Modell gew¨ahrleistet werden.