Bewertung
Prinzipiell beschäftigen sich die vorgestellten Werkzeuge mit einer
De-Geringe Aus-
drucksmächtig-keit finition von QoS- bzw. SLA-Parametern und deren Überwachung bzw.
der Erstellung von Reports. Allerdings bieten die zugrundeliegenden Spezifkationskonzepte nur eine geringe Ausdrucksmächtigkeit [HLN01].
Insbesondere wird bei der Betrachtung des imService Quality Managers verwendeten Dienstmodells deutlich, dass sich die Beschreibung vorwie-gend an den Vorgaben des Netz- und Systemmanagements ausrichtet und somit beispielsweise Dienstabhängigkeiten nicht explizit dargestellt werden können.
Weiterhin wurden beide Produkte mit umfangreichen
Ausführungsar-Integration gestatet sich
schwierig chitekturen zur Aggregation von Komponentenparametern bzw. zur Er-stellung von Reports ausgestattet. Diese ermöglichen zwar die Gewin-nung von Daten aus Netz- und Applikationskomponenten bzw. Ausfüh-rung von Berechnungsoperationen, stellen aber keine offenen Schnitt-stellen zur Steuerung dieses Vorgangs zur Verfügung. Es erscheint des-halb nicht möglich, diese Werkzeuge im Hinblick auf die Aktualisierung einer Dienstmanagementinformationsbasis zu erweitern. Zudem wur-den nur unzureichende Möglichkeiten zur Integration mit bestehenwur-den Managementwerkzeugen geschaffen [HLN01], was insbesondere bei In-foVista deutlich wird. Statt auf bestehende Datenbestände anderer Ma-nagementwerkzeuge zurückzugreifen, führt dieInfoVista Engine eigen-ständig Abfragen auf MIB-Variablen betreffender Komponenten durch [Ner01].
Realisierung einer Dienstmanagementinformationsbasis verwendet wer-den kann.
Um die in diesem Kapitel gewonnenen Erkenntnisse strukturiert auf- Ergebnisse der Evaluation
zubereiten, werden nun zunächst die wichtigsten Defizite bestehender Arbeiten dargelegt. Daran anschließend werden Aspekte aufgezeigt, die eine gute Bewertung hinsichtlich eines Teilbereichs von Anforderungen erzielen und deshalb als Vorlage zur Entwicklung einer Dienstmanage-mentinformationsbasis verwendet werden können. Begleitend zu diesen Ausführungen wird in Tabelle3.1eine grafische Zusammenfassung der Evaluationsergebnisse präsentiert, wobei aus Übersichtlichkeitsgründen nur die wichtigsten Arbeiten berücksichtigt wurden. Mit ausgefüllte Felder verdeutlichen dabei Schwachpunkte bestehender Ansätze.
• Konkrete Dientmanagementinformation wurden nicht in ausrei-chendem Maße spezifiziert. Zwar wurden für das Dienstmanage-ment notwendige Entitäten wie Service oderServiceAccessPoint eingeführt, aber gleichzeitig nur mit einer äußerst rudimentären Menge von generischen Attributen und Methoden versehen, die oftmals auf Namen und Beschreibung der Entität beschränkt blei-ben. Zwar sind diese “Container-Objekte” als Basis für die De-finition von konkreter Managementinformation durchaus geeig-net, sind aber zum gegenwärtigen Zeitpunkt aus praktischen Ge-sichtspunkten unzureichend. Eine Verfeinerung der spezifizierten Entitäten hinsichtlich eines konkreten Szenarios führt aufgrund der Unvollständigkeit der vorliegenden Information zwangsläu-fig zu unterschiedlichen Ergebnissen, was einer Vereinheitlichung von Managementinformationen entgegenwirkt (vgl Anforderung MOD4). Dementsprechend fehlt das notwendige Fundament gene-rischer Dienstattribute, die für die angestrebte, einheitliche Sicht auf Dienstmanagementinformationen erforderlich ist. Ferner zeigt sich, dass aufgrund der Zielsetzung ein möglichst umfassendes Mo-dell zu schaffen, eine unübersichtliche und fast nicht beherrschbare Anzahl von Klassen entstanden ist.
• Es wurde bisher noch keine klare Ableitungsmethodik für Dienst-managementinformationen vorgestellt. Dadurch fällt es schwer nachzuvollziehen, welchem Anwendungszweck die spezifizierten
Entitäten und Attribute dienen. Ebenfalls wurden nur unzurei-chende Integrationsmöglichkeiten verschiedener Managementmo-delle geschaffen, was die Anwendung in einem heterogenen Umfeld verkompliziert.
• Es exisistieren keine allgemeinen Konzepte zur Abbildung zwi-schen Komponentenparametern und Dienstattributen. Zwar wur-den innerhalb von Spezifikationssprachen Möglichkeiten zur Be-schreibung von Berechnungsvorschriften geschaffen, diese Arbei-ten beschränken sich aber entwender auf spezifische Anwendungs-domänen (z.B. WSLA) oder können nur in Kombination mit einer bestimmten Managementarchitekturen verwendet werden (z.B: Expression-MIB). Zudem zeigte sich insbesondere in der Be-trachtung kommerzieller Produkte, dass zwar umfassende Ausfüh-rungsarchitekturen zur Aggregation von Komponentenparamtern geschaffen wurden, allerdings aufgrund der verwendeten proprie-tären Schnittstellen keine Anpassungs- und Erweiterungsmöglich-keiten gegeben sind.
Nichstdestrotz zeigten sich eine Reihe interessanter Konzepte, die in die Entwicklung einer Dienstmanagementinformationsbasis einbezogen werden sollten und in Tabelle3.1durch eine entsprechende Bewertung (3) verdeutlicht werden:
• Die IT Infrastructure Library enthält eine umfassende Sammlung von Dienstmanagementaufgaben und eignet sich deshalb zur Ab-leitung von Anforderungen an die Inhalte einer Dienstmanage-mentinformationsbasis.
• In [DR02] findet sich sowohl der Entwurf eines Dienstmodells als auch eine systematische Anforderungsanalyse. Da hierbei eine ge-nerische Sichtweise gewählt wurde, erscheint eine Anpassung die-ser Konzepte sinnvoll.
• Die in [Han07] vorgestellte Abhängigkeitsmodellierung stützt sich auf einen objektorientierten Modellentwurf und stellt bereits Ver-bindungen zu grundlegenden Entitäten im Dienstmanagementum-feld her. Somit kann eine Einbettung dieses Ansatzes in eine
Dienstmanagementinformationsbasis einfach vorgenommen wer-den.
• In [KL03] konnte eine Integration zwischen Spezifikation und Überwachung von Managementinformationen erzielt werden, was für eine Dienstmanagementinformationsbasis ebenfalls wün-schenswert erscheint.
Unter Einbeziehung der genannten Aspekte wird nun im folgenden Ka-pitel der Lösungsansatz dieser Arbeit entwickelt.
CIMSIDeTOMIETFITIL[DR02][Han07]WSLAHPSQM
ALL1(3)3333(3)
ALL2333
MOD133(3)
MOD23333
MOD3(3)
MOD4(3)(3)3
MOD5(3)33
KMI1
KMI233
KMI3
KMI4333
KMI5(3)
KMI6(3)
KMI7(3)
DEP1(3)(3)3
DEP2(3)(3)3
DEP33
AGG1
AGG2
AGG33
AGG433
REA1(3)
REA2(3)3(3)(3)
REA3(3)(3)(3)(3)(3)
REA3(3)(3)(3)(3)
REA5(3)3
Tabelle3.1:BewertungbestehenderArbeiten
Kapitel 4
Lösungsansatz und weiteres Vorgehen
Wie bereits im Rahmen der Anforderungsanalyse dargelegt, gilt es, mehrere Herausforderungen bei der Konzeption einer Managementinfor-mationsbasis für das Dienstmanagement zu berücksichtigen. Aus dem vorigen Kapitel geht weiterhin hervor, dass verwandte Arbeiten nur partiell zur Lösung dieser Herausforderungen beitragen und damit die Notwendigkeit für eine neue Herangehensweise besteht. Die zentrale Lö-sungsidee dieser Arbeit vorzustellen und damit die genannten Defizite zu adressieren, stellt den Gegenstand dieses Kapitels dar. Der entwi-ckelte Ansatz wird dabei von einem methodischen Konzept begleitet, das gleichzeitig das weitere Vorgehen dieser Arbeit bestimmt. Zunächst erfolgt allerdings die Vorstellung der Service-MIB Idee und deren Be-standteile.
4.1 Die Service-MIB Idee
An mehreren Stellen dieser Arbeit werden bestehende Konzepte zur Informationsmodellierung im Netz- und Systemmanagement genannt.
Diese Konzepte bestimmen weitgehend die heutige Managementland-schaft, haben sich über die Jahre hinweg bewährt und gingen zudem in die Betriebserfahrung von Administratoren über. Es erscheint deswegen vernünftig, auf dem Weg zu einem integrierten Service Management auf diese Konzepte zu bauen und sie mit neuen, erforderlichen Bestandtei-len zu erweitern.
Die Service-MIB verfolgt diesen Ansatz: Sie versucht, in ähnlicher Weise
Service-MIB repräsen-tiert Mana-gementsicht auf Dienst
wie bestehende MIBs Netzkomponenten repräsentieren, eine umfassen-de Beschreibung von Diensten zu vermitteln. Auch in diesem Fall stellt Abstraktion das Schlüsselkonzept dar: Es werden managementrelevante Aspekte eines Dienstes identifiziert, durch geeignete Attribute und Ope-rationen charakterisiert und in ein geeignetes Modell überführt. Ferner finden Beziehungen zu grundlegenden Entitäten im Dienstmanagemen-tumfeld wie z.B. Dienstvereinbarungen Berücksichtigung. Es entsteht somit ein Kompositum an dienstorientierter Managementinformation, was sich in der Namensgebung des Ansatzes widerspiegelt.
Gegenüber bestehenden MIBs muss allerdings ein weiterer Aspekt in
Dienst-eigenschaften stehen in Ab-hängigkeit zu Komponenten-parametern
die Betrachtung aufgenommen werden, der Erweiterungen notwendig erscheinen lässt: Die Eigenschaften eines Dienstes sind untrennbar mit den Eigenschaften der Komponenten verbunden, die diesen Dienst rea-lisieren. Effektiv werden deshalb Überwachungs- und Kontrollaktionen auf dem Dienst zu einem großen Teil auf dienstrealisierenden Kom-ponenten durchgeführt. Soll also eine managementorientierte Beschrei-bung eines Dienstes konzipiert werden, müssen derartige Zusammen-hänge berücksichtigt und in die Spezifikation von Diensteigenschaften integriert werden. Hinsichtlich der Informationsmodellierung erwächst daraus vor allem die Notwendigkeit, eine Abbildung von komponente-norientierter auf dienstorientierte Managementinformation zu schaffen.
Abbildung4.1veranschaulicht nocheinmal die genannten Aspekte und ihre Einbettung in den Service-MIB Ansatz, der sich aus zwei grundle-genden Bestandteilen zusammensetzt, wie im rechten oberen Quadran-ten dargestellt:
Service
DNS
Service MIB
Aggregations-vorschriften
wird realisiert
beschreibt
werden abgebildet
beschreiben
Komponenten -parameter
Dienst-attribute
Funktionalität Managementsicht
ServiceKomponenten
Abbildung 4.1:Der Service-MIB Ansatz
• Repräsentation einer Managementsichtauf den Dienst
Wie auf der linken Seite in Abbildung 4.1 ersichtlich, wird die Funktionalität eines Dienstes durch eine Reihe von Komponenten realisiert. Um eine Managementsicht auf diese Komponenten her-zustellen, werden nach gängiger Praxis (vgl. Abschnitt 2.1) ma-nagementrelevante Abstraktionen gebildet (insbesondere in Form geeigneter Kompontenparameter) und in Informationsbasen zu-sammengefasst. Effektiv können in dieser Weise Managementak-tionen durch lesenden und schreibenden Zugriff auf die entspre-chenden Informationsbasen initiiert werden. Wie in der oberen horizontalen Ebene dargestellt, wird mit der Service-MIB das Ziel verfolgt, geeignete Abstraktionen für einen Dienst zu schaffen und somit eine dienstorientierte Managementsicht zu repräsentieren.
• Abbildung von Komponenten- auf Dienstinformationen
Um die erwähnte Abbildung zwischen Komponenten- und Dienst-managementinformation zu ermöglichen, werden zusätzlich
Ag-gregationsvorschriften definiert und in die Service-MIB integriert.
Dies erlaubt insbesondere eine Spezifikation von Dienstattributen in Abhängigkeit von Komponentenparametern und somit eine ein-fachere Überwachung und Kontrolle von Diensten, wie sich in den folgenden Abschnitten zeigen wird.
Um die Verflechtung dieser beiden Bestandteile zu verdeutlichen, wird ein kurzes Beispiel vorgestellt.
Beispiel
Für den im Rahmen der Anforderungsanalyse präsentierten GRID-Computing Dienst (Abschnitt2.2.2) verkörpert die Verfügbarkeit1 eine wichtige Diensteigenschaft: Sie lässt Rückschlüsse auf den Gesamtzu-stand des Dienstes zu, stellt GegenGesamtzu-stand der Dienstvereinbarung dar und wird deshalb als DienstattributOperationalStatus in die Service-MIB mitaufgenommen.
Die Verfügbarkeit dieses Dienstes bzw. der Wert des damit assozier-ten Dienstattributs wird in diesem Beispiel von den Verfügbarkeiassozier-ten der dienstrealisierenden Komponenten beeinflusst, wie in dem verein-fachten Modell in Abbildung4.2ersichtlich. In diesem Fall sind dies die Verfügbarkeiten der Rechnerknoten, auf denen die tatsächlichen Berech-nungen durchgeführt werden, gepaart mit der Verfügbarkeit des Rou-ters und des DNS Servers, die für die Netzkonnektivität des Dienstes verantwortlich sind.
Den Bezug zwischen Komponentenparametern und Dienstattribut
Berechnung des
Dienstattri-butwertes stellt die ServiceAvail Aggregation her: Sie bildet die qualifizierten Komponentenparameter (availDNS,availRout und availNode) auf das gewünschte Dienstattribut (availCS) unter Verwendung der dargestell-ten Formel ab und erlaubt die Berechnung dessen Wertes. Durch die Verflechtung von Dienstattribut und Abbildungsvorschrift wird somit eine feingranulare Beschreibung des Dienstes erzielt und gleichzeitig die Überwachung des Dienstes vereinfacht. Ebenfalls wird in dieser Weise eine szenariospezifische Anpassung inhärent unterstützt.
1Für eine ausführliche Diskussion zu dieser Thematik siehe z.B. [Kai99]
availNode Computing Node
<<resource>>
# status : int
availRout
<<resource>>
Router
# status : int availDNS
<<resource>>
# status : int DNS
<<aggregation>>
ServiceAvail.
availCS
depends on
1
100
1 und mit
Dienstattributs Berechne
availDNS, availNode availRout Wert des
# operationalStatus Computing Service
<<service>>
: float
Abbildung 4.2:Beispielmodell für Dienstattribut und Aggregation
Nach der Skizzierung der Bestandteile des Service-MIB Ansatzes, wird nun im nächsten Abschnitt das methodische Vorgehen zur Realisierung dieser Konzepte vorgestellt.