Beispiele kommerzieller Managementl ¨ osungen

Grenze zwischen zwei ISPs, vereinbart werden. M¨ogliche Dienstg¨uteparameter sind beispiels-weise die Latenz beim Transport von IP-Paketen, die Fehler-/Verlustrate, der Durchsatz in IP-Paketen bzw. Oktetten sowie die Verf¨ugbarkeit eines IP-Dienstes. Eine ausf¨uhrlichere Be-schreibung der definierten Dienstg¨uteparameter findet sich in [SP01].

Bewertung

Die in diesem Abschnitt beschriebenen Ans¨atze beschr¨anken sich auf die Definition von IP-basierten Dienstg¨uteparametern f¨ur die Netzwerkschicht. Damit wird einerseits ein wichtiges Problemfeld adressiert, beispielsweise bei der Etablierung von Service Level Agreements zwi-schen ISPs oder zwizwi-schen Kunden und ISPs. Andererseits wird dabei nur ein sehr isolierter Problembereich betrachtet (siehe AnforderungCOM1). Die Integration mit h¨oheren Schich-ten, wie beispielsweise der Anwendungs- und Dienstschicht, steht hierbei nicht im Mittel-punkt und ist daher weitgehend ungel¨ost. Vor allem die Korrelation von Netzwerkverkehr auf der IP-Ebene mit Metriken aus h¨oheren Schichten ist schwierig. F¨ur zuk¨unftige Manage-mentl¨osungen ist die Korrelation von Metriken ¨uber verschiedene Ebenen hinweg allerdings ein essentieller Bestandteil. Weiterhin fehlt ein Vorgehensmodell (AnforderungCOM2), und die Modellierung ist nicht von der Etablierung getrennt (AnforderungCOM3).

Die allgemeinen Modellierungsanforderungen (AnforderungenMOD1–MOD3) werden weit-gehend erf¨ullt; die Dienstmodelle weisen allerdings Defizite auf. Die Dienststruktur Anfor-derungSM3) l¨asst sich nur bedingt modellieren; Dienstg¨uteparameter, Metriken und Abbil-dungsfunktionen (AnforderungenSM4–SM6) fehlen komplett; Dienstg¨uteziele (Anforderung SM7) k¨onnen ¨uber Policies beschrieben werden.

Von den funktionalen Anforderungen wird lediglich die Anwendungsunabh¨angigkeit (An-forderungFUN2) erf¨ullt. Die Anforderungen an den Modellierungsprozess (Anforderungen MPRO1–MPRO3) und dessen Effektivit¨at (AnforderungenEFF1–EFF4) werden nicht ein-gehalten.

Von den Anforderungen an das Rahmenwerk werden lediglichFRA2und FRA4(teilweise) erf¨ullt.

3.2 Beispiele kommerzieller Managementl ¨ osungen

Dieser Abschnitt stellt exemplarisch zwei kommerzielle Managementl¨osungen f¨ur das Service Level Management vor. Abschnitt3.2.1beschreibt Internet Services von Hewlett-Packard und Abschnitt3.2.2stellt den Service Level Advisor von IBM Tivoli vor.

3 Service Level Management: Status Quo 3.2.1 HP OpenView Internet Services

Das Produkt OpenView Internet Services (OVIS) von Hewlett-Packard bietet die M¨oglichkeit, Dienstg¨utevereinbarungen f¨ur Netzwerk- und Anwendungsdienste zu definieren und zu ¨uber-wachen. Abbildung3.11zeigt die Architektur von Internet Services. Zentraler Bestandteil ist der Management Server, der die ¨Uberwachung von Diensten steuert und die ¨Uberpr¨ufung ver-einbarter Service Level Agreements durchf¨uhrt. Die ¨Uberpr¨ufung von Diensten erfolgt mit Hilfe sogenannter Probes, d.h. mit Programmen, die f¨ur den Test eines Dienstes verantwort-lich sind. Hierbei ist eine Menge von Probes f¨ur Standarddienste, wie z.B. ftp, DNS, HTTP, etc., bereits vordefiniert; eigene Probes k¨onnen entwickelt und in Internet Services integriert werden. Diese Probes k¨onnen entweder lokal auf dem Management Server ablaufen, oder sie werden auf entfernten UNIX- oder Windows-Systemen ausgef¨uhrt. Die Ergebnisse der Probes werden in der Datenbank des Management Servers abgelegt und bilden die Datengrundlage f¨ur die ¨Uberpr¨ufung von Dienstg¨utezielen. Neben den durch die Probes ermittelten Daten kann die Datenbank auch Antwortzeiten speichern, die mit Hilfe des OpenView Transaction Ana-lyzers (OVTA) [HP04] ermittelt wurden, der eine Vermessung von Antwortzeiten f¨ur Web-,

Abbildung 3.11: Architektur von HP Open View Internet Services (aus [HP03])

3.2 Beispiele kommerzieller Managementl¨osungen

J2EE- und COM-Anwendungen erm¨oglicht. Die in der Datenbank gespeicherten Informa-tionen k¨onnen mit Hilfe des Dashboards jederzeit ¨uberpr¨uft werden, oder es k¨onnen t¨aglich Reports daraus generiert werden. Falls vereinbarte Dienstg¨uteziele verletzt werden, bietet In-ternet Services die M¨oglichkeit, einen Alarm zu generieren, um andere Managementsysteme, wie z.B. den Network Node Manager (NNM), zu benachrichtigen.

Mit Hilfe des Configuration Managers k¨onnen die zu ¨uberwachenden Dienste konfiguriert werden. Die Struktur der im Rahmen von Internet Services zu ¨uberwachenden Dienste ist in Abbildung3.12 dargestellt. F¨ur jeden Kunden sind ein oder mehrere Gruppen von Diensten (Service Groups) definiert, die jeweils mehrere Dienste des gleichen Typs enthalten. F¨ur jeden Diensttyp sind die folgenden Elemente festgelegt:

Service Target : Dies definiert den zu ¨uberwachenden Dienst einschließlich des Rechners, auf dem der Dienst l¨auft, und dem Port, unter dem der Dienst erreichbar ist.

Objectives : Die Dienstg¨uteziele stellen die von dem Dienst zu erf¨ullenden Anforderungen dar. Dies schließt beispielsweise die Definition der zu messenden Metriken sowie der geforderten Zielwerte ein.

Probes : Die Probes definieren die Informationen, die f¨ur die technische ¨Uberpr¨ufung der Objectives notwendig sind. Dazu geh¨oren unter anderen die Lokation des Probes (lokal oder entfernt) und das Intervall, in dem der Probe von Internet Services ausgef¨uhrt wird.

Abbildung 3.12: Struktur der Dienste innerhalb HP OVIS (aus [HP03])

3 Service Level Management: Status Quo

Internet Services erlaubt eine automatisierte Konfiguration einer großen Menge von zu ¨uber-wachenden Diensten mit Hilfe einer Batch-Schnittstelle. Hierbei wird eine in XML kodierte Konfigurationsdatei eingelesen.

Bewertung

HP OpenView Internet Services erlaubt eine einfache und flexible ¨Uberwachung von Diens-ten im Rahmen des Service Level Managements. Hierbei erlaubt HP OVIS die ¨Uberwachung beliebiger Dienste (AnforderungCOM1). Es wird f¨ur die Modellierung von Dienstg¨utever-einbarungen zwar kein Vorgehensmodell (Anforderung COM2) definiert, aber OVIS bietet die men¨ugef¨uhrte Definition von SLAs mit Hilfe von Wizards. Eine Trennung von Modellie-rung und EtablieModellie-rung (AnfordeModellie-rungCOM3) kann allerdings nur bei Verwendung der Batch-Schnittstelle erreicht werden.

Die allgemeinen Modellierungsanforderungen (AnforderungenMOD1–MOD3) werden von HP OVIS erf¨ullt. Beim Dienstmodell existieren allerdings einige Defizite, da keine Dienst-struktur (AnforderungSM3), keine Metriken (AnforderungSM5) und keine Abbildungsfunk-tionen (AnforderungSM6) beschrieben werden k¨onnen.

Von den funktionalen Anforderungen sind nur die Anwendungsunabh¨angigkeit (Anforderung FUN2) sowie die Verifizierbarkeit (Anforderung FUN6) erf¨ullt. Diese wird durch die Ver-wendung der Wizards bzw. durch die VerVer-wendung von XML-Dokumenten in Zusammenhang mit der Batch-Schnittstelle sichergestellt.

Bez¨uglich des Modellierungsprozesses (AnforderungenMPRO1–MPRO3) erf¨ullt HP OVIS alle Anforderungen nur bedingt. So gibt es bei Verwendung der Batch-Schnittstelle keine Mo-dellierungsmethodik und die Vorgehensweise bei Anwendung der Wizards ist nicht streng Bottom-Up bzw. Top-Down. Die Wiederverwendbarkeit (Anforderung EFF1) modellierter Dienstg¨utevereinbarungen ist beschr¨ankt; lediglich Fragmente aus den XML-Dokumenten f¨ur die Batch-Schnittstelle k¨onnen als Vorlage wiederverwendet werden. Langlebigkeit (Anfor-derung EFF2) wird nicht gew¨ahrleistet, da die Modelle Konfigurationsinformationen ent-halten. Die Modellierung wird durch die bereitgestellten Wizards und XML-Editoren un-terst¨utzt.

HP OVIS erlaubt keine dynamische Bindung an unterschiedliche Konfigurationen (Anforder-ungenEPRO1undEPRO1), erm¨oglicht aber mit Hilfe der Batch-Schnittstelle eine automa-tisierte Etablierung von Dienstg¨utevereinbarungen (AnforderungEPRO3). Weiterhin erf¨ullt HP OVIS die Forderung nach Werkzeugintegration (FRA1) sowie die Erweiterbarkeit (An-forderungFRA4) mit Hilfe von Custom Probes.

3.2 Beispiele kommerzieller Managementl¨osungen

3.2.2 IBM Tivoli Service Level Advisor

Der IBM Tivoli Service Level Advisor (ITSLA) [MBG⁺02] ist ein Werkzeug zur Analyse von Daten, die ¨uber bereitgestellte Dienste gesammelt werden. Hierbei wird die Datensammlung nicht von ITSLA selbst durchgef¨uhrt, sondern an andere Werkzeuge delegiert. Abbildung 3.13 zeigt einen typischen Aufbau einer ITSLA-Umgebung. Die notwendigen Daten ¨uber die Verf¨ugbarkeiten und die Antwortzeiten von Diensten werden lokal ermittelt und dort zun¨achst in Datenbanken gespeichert. Mit Hilfe von Extract, Transform, and Load data (ETL)-Werkzeugen werden die lokalen Daten in dem Tivoli Enterprise Data Warehouse (TEDW) zentral zusammengef¨uhrt. Dieses zentrale Data Warehouse stellt die Datengrundlage f¨ur den Service Level Advisor zur Verf¨ugung. Mittels der sogenannten Registration ETL werden die notwendigen Typinformationen von dem zentralen Data Warehouse in die als Measurement Data Mart bezeichnete Datenbank des Service Level Advisors ¨ubertragen. Dies geschieht le-diglich einmalig, bzw. dann, wenn neue Typen definiert wurden. Mit Hilfe des Process ETL werden t¨aglich Messdaten aus dem zentralen Data Warehouse in den Measurement Data Mart transferiert. Diese Daten werden vom ITSLA f¨ur die Evaluation von Dienstg¨utezielen verwen-det.

Abbildung 3.13: Service Level Management mit ITSLA (aus [MBG⁺02])

Der Service Level Advisor erlaubt die graphische Definition von Dienstangeboten, soge-nannten Service Offerings, die als Bausteine f¨ur Dienstg¨utevereinbarungen verwendet werden k¨onnen. Ein Service Offering beinhaltet zun¨achst einen sogenannten Schedule, der die f¨ur das Dienstangebot g¨ultigen Zeitr¨aume festgelegt. Anschließend werden die das Dienstangebot er-bringenden Komponenten spezifiziert, wie beispielsweise Firewalls, Server, Router etc. F¨ur jede Komponente werden die Messdaten definiert, die f¨ur die Evaluation der Dienstg¨uteziele

3 Service Level Management: Status Quo

notwendig sind. Dienstg¨uteziele werden mit Hilfe sogenannter Breach Values spezifiziert, die die Festlegung von g¨ultigen Minim, Maxim, Durchschnitts- und Summenwerten um-fassen. Bei der Verletzung der definierten Breach Values kann eine Benachrichtigung gesendet werden.

ITSLA unterscheidet drei Arten von SLAs, die abh¨angig von dem Problembereich festgelegt werden k¨onnen. Externe SLAs werden f¨ur Dienste definiert, die gegen¨uber Endanwendern erbracht werden. Diese haben dabei Einsicht in die von ITSLA generierten Reports. Interne SLAs werden verwendet, um Abl¨aufe innerhalb einer Organisation, beispielsweise zwischen Abteilungen, zu modellieren und nachvollziehen zu k¨onnen. Sogenannte Outsourced SLAs werden verwendet, wenn der Anwender von ITSLA Dienste eines anderen Dienstanbieters in Anspruch nimmt. In diesem Fall muss ITSLA nicht selbst die ¨Uberwachung des Dienstes durchf¨uhren, sondern dies wird durch den Betreiber des Dienstes erbracht.

Bewertung

ITSLA erm¨oglicht die ¨Uberwachung von Dienstg¨utevereinbarungen f¨ur beliebige IT-Dienste (AnforderungCOM1). Ein Vorgehensmodell (AnforderungCOM2) existiert nicht; Dienstg¨u-tevereinbarungen k¨onnen lediglich men¨ugef¨uhrt erstellt werden, wodurch keine Trennung zwischen Modellierung und Etablierung (AnforderungCOM3) erreicht wird.

Die allgemeinen Modellierungsanforderungen (AnforderungenMOD1–MOD3) werden von ITSLA erf¨ullt. Aber wie bei HP OVIS gibt es auch beim ITSLA-Dienstmodell einige Defizi-te. Es fehlt die M¨oglichkeit, die Dienststruktur (AnforderungSM3), Metriken (Anforderung SM5) und Abbildungsfunktionen (AnforderungSM6) modellieren zu k¨onnen.

Im Bereich der funktionalen Anforderungen werden die Anwendungsunabh¨angigkeit (Anfor-derungFUN2) sowie die Verifizierbarkeit (AnforderungFUN6) erf¨ullt.

Eine explizite Modellierungsmethodik existiert nicht, aber durch die men¨ugef¨uhrte Definition von Dienstg¨utevereinbarungen wird der Anwender angeleitet. Wie HP OVIS erfolgt die Mo-dellierung weder streng nach dem Bottom-Up-Prinzip, noch Top-Down. Damit sind alle An-forderungen an dem Modellierungsprozess (MPRO1–MPRO3) zumindest teilweise erf¨ullt.

Bez¨uglich der Effektivit¨at der Modellierung ist allerdings nur die Forderung nach der Werk-zeugunterst¨utzung (EFF3) eingehalten.

Im Bereich des Rahmenwerks erf¨ullt ITSLA lediglich die Anforderungen bez¨uglich der Werk-zeugintegration (FRA1) sowie der Erweiterbarkeit (FRA4).