Gebäudetechnik
.
deutsch english francais italinao
 Suche

 Startseite
 Organisation
 Know How
 Online Forum Gebäudetechnik
 Links

 Anmeldung

 Passwort vergessen?

Partner Login

Partner ID
 
 Passwort

 Über GBT Gebäudetechnik
 FAQ & Hilfe Tool
 Ziele
 Bedingungen
 eMail
  Online Forum Gebäudetechnik
Startseite | Online Hilfe 
Ihr Status : Gast
Version : 1.5
 
   Suche :  
Startseite - GBT Forum - Diplomarbeit über Facility Management
 

Diplomarbeit über Facility Management

Text Datum Benutzer
Diplomarbeit über Facility Management
Hallo,
ich möchte meine Diplomarbeit über das Thema "Flächenoptimierung im Facility Management"( ausgeführt am Beispiel eines bereits bestehenden Büro-Komplexes) schreiben und bin daher auf der Suche nach aller Art Buch- und Info-Material sowie bereits bestehender Diplomarbeiten bezüglich dieses Themas.Wer kann mir vielleicht Hinweise oder Empfehlungen geben?Vielen Dank im Voraus!
14 Aug 2005
22:47:52
unbekannt
Diplomarbeit über Facility Management
Hallo, im Anhang eine Diplomarbeit zu Ihrem Thema, viel Erfolg.
Gruss Friederich

Auszug ohne Bilder aus:http://www.walther-it.de/projects/diplom/diplom_final.html


Diplomarbeit TU Dresden Fakultät Informatik
Von Thomas Walther
Inhalt
Aufgabenstellung
Deklaration
Danksagungen
Abbildungsverzeichnis
Tabellenverzeichnis

1 Einführung

1.1 Motivation
1.2 Hintergrund
1.3 Ergebnisse der Diplomarbeit
1.4 Struktur
2 Charakteristika des Netzwerkmanagements
2.1 Einführung in die Netzwerkthematik
2.2 Disziplinen des Netzwerkmanagements
2.3 Dimensionen des Netzwerkmanagements
2.4 Anforderungen an das Netzwerkmanagement
2.5 Managementarchitekturen
2.6 Managementwerkzeuge
2.7 Netzwerkmanagementplattformen
2.8 Ausgewählte Netzwerkmanagementarchitekturen
2.8.1 Das OSI-Netzmanagement
2.8.2 Das Internet-Management
2.9 OpenView als ausgewählte Netzwerkmanagementplattform
2.9.1 Struktureller Aufbau
2.9.2 Ein Anwendungsfall
3 Charakteristika des Facility-Managements
3.1 Die Entstehungsgeschichte des Facility-Managements
3.2 Ziele des Facility-Managements
3.3 Definitionen zum Facility-Management
3.4 Disziplinen des Facility-Managements
3.5 Dimensionen des Facility-Managements
3.6 Anforderungen an das Facility-Management
3.7 Facility-Managementarchitekturen
3.8 Facility-Managementplattformen
3.9 Mountain-Top als ausgewählte Facility-Managementplattform
4 Vergleich von Netzwerk- und Facility-Management im Hinblick auf eine Zusammenführung beider
4.1 Die zugrunde liegende Managementtheorie
4.2 Spezielle Konzepte
4.2.1 Managementdisziplinen
4.2.2 Managementdimensionen
4.2.3 Managementarchitekturen
4.3 Managementplattformen
5 Lösungsansätze für eine Verbindung von Netzwerkmanagementplattformen mit Facility-Managementplattformen
5.1 Zielstellung
5.2 Ideales Modell
5.3 Modell auf Basis des OSI-Netzmanagements
5.4 Realisierbares Modell
6 Die Realisierung einer einfachen Plattformverbindung ohne Kommunikationssystem
6.1 Modellarchitektur
6.2 Das Ping-Werkzeug
6.3 Das Ping-FM-Modul
6.4 Schlußfolgerungen
7 Die Realisierung einer komplexen Plattformverbindung mit Kommunikationssystem
7.1 Modellarchitektur
7.2 Der übertragungsorientierte Kommunikationsbaustein
7.2.1 Die Übertragungsschicht
7.2.2 Die Verbindungsschicht
7.2.3 Die Netzwerkschicht
7.2.4 Die Transportschicht
7.3 Der allgemeine Managementbaustein
7.4 Die Anwendungsmodule
8 Ein Anwendungsfall für das Facility-Management
8.1 Überblick
8.2 Der Lageplan
8.3 Die Gebäudepläne
8.4 Das Flächenmanagement
8.5 Das Personalmanagement
8.6 Das Inventarmanagement
8.7 Das Netzwerkmanagement
9 Zusammenfassung und Ausblick
9.1 Vergleichende Analyse der Managementarten
9.2 Untersuchte Plattformen
9.3 Aufgestellte Lösungsansätze
9.4 Ergebnisse der Realisierung
9.5 Vorschläge für eine Fortsetzung des Projektes
Literaturverzeichnis
Stichwortverzeichnis





Abbildungsverzeichnis

Kapitel 2:

Abbildung 2.1: Struktur eines Corporate Networks

Abbildung 2.2: Klassische Disziplinen des integrierten Managements
Abbildung 2.3: Dimensionen des Netzwerkmanagements
Abbildung 2.4: Erweiterte Dimensionen des Netzwerkmanagements
Abbildung 2.5: Funktionsebenen einer Netzwerkarchitektur
Abbildung 2.6: Modelle einer Managementarchitektur nach [HENE95]
Abbildung 2.7: Klassifizierungsschema für Managementwerkzeuge nach [HEAB93]
Abbildung 2.8: Aufbau von Netzwerkmanagementplattformen
Abbildung 2.9: Schematische Darstellung der Map eines Corporate Network
Abbildung 2.10: Dokumente des OSI Management Frameworks
Abbildung 2.11: ISO-Objektidentifikator-Namensbaum und Internet-Registrierungsbaum
Abbildung 2.12: Grundlegende Struktur von HP OpenView
Abbildung 2.13: HP OpenView Produktstruktur (Auszug aus [HPOV93])
Abbildung 2.14: Die Submap Root eines konkreten Anwendungsfalls
Abbildung 2.15: Darstellung der OpenView Alarm Log
Kapitel 3:
Abbildung 3.1: Disziplinen des Facility Managements
Abbildung 3.2: Dimensionen des Facility-Managements
Abbildung 3.3: Einfache Facility-Managementarchitektur
Abbildung 3.4: Umfassende Facility-Managementarchitektur
Abbildung 3.5: Aufbau herkömmlicher Facility-Managementplattformen
Abbildung 3.6: Darstellung eines FM-Systems mittels verbundener CAD-Zeichnungen
Abbildung 3.7: Modularer Aufbau der Facility-Managementplattform Mountain-Top
Kapitel 5:
Abbildung 5.1: Abstraktes Datenmodell für den ideale Ansatz
Abbildung 5.2: Organisationsmodell des idealen Ansatzes
Abbildung 5.3: Organisationsmodell des OSI-Ansatzes
Abbildung 5.4: Organisationsmodell des realisierbaren Ansatzes
Abbildung 5.5: Client-Server-Architektur des modellierten Kommunikationssystems
Kapitel 6:
Abbildung 6.1: Modellarchitektur einer einfachen Verbindung
Abbildung 6.2: Detaillierte Struktur des Ping-Werkzeugs
Abbildung 6.3: Struktur des Ping-FM-Moduls
Kapitel 7:
Abbildung 7.1: Allgemeine Architektur des Kommunikationssystems
Abbildung 7.2: Struktur einer Message-Queue
Abbildung 7.3: Beispielablauf einer Übertragung von Frames mit Primitiven der Verbindungsschicht
Abbildung 7.4: Aufbau eines Pakets
Abbildung 7.5: Ablauf der Übertragung einer Folge von Paketen
Abbildung 7.6: Beispielablauf einer Übertragung von TPDU´s mit Segmentierung von Paketen
Abbildung 7.7: Aufbau der Strukturen zur Verwaltung der Anwendungsinformationen
Abbildung 7.8: Ablauf einer Kommunikation zwischen zwei Anwendungen mit An- und Abmelden
Abbildung 7.9: Darstellung der Funktionsprimitive des Ping-Protokolls
Kapitel 8:
Abbildung 8.1: Dreidimensionale Darstellung des Gewerbegebiets
Abbildung 8.2: Lageplan des Gewerbegebiets
Abbildung 8.3: Darstellung der bautechnischen Zeichnung einer Etage des Gebäudes 4
Abbildung 8.4: Darstellung der Raumflächen mit Möblierung
Abbildung 8.5: Ausschnitt aus dem Personalverzeichnis
Abbildung 8.6: Darstellung von Objekten des Telekommunikationsbereichs
Abbildung 8.7: Auszug aus Mountain-Top nach Aktivierung der Funktion "Status-Table"
Abbildung 8.8: Darstellung der History-Tabelle eines Netzwerkmanagementobjekts
Tabellenverzeichnis
Kapitel 2:

Tabelle 2.1: Schichtenmodelle für Netzwerkarchitekturen

Tabelle 2.2: Gebiete des Netzwerkmanagements nach [HPOV93]
Tabelle 2.3: Ziele des Netzwerkmanagements nach [HPOV93]
Tabelle 2.4: Wichtige Standards im Bereich des Internet-Managements
Kapitel 3:
Tabelle 3.1: Gliederung der Facility Management Disziplinen
Kapitel 6:
Tabelle 6.1: Konfigurationsdatei des Ping-Werkzeugs
Tabelle 6.2: Statustabelle des Ping-Werkzeugs
Tabelle 6.3: Beispielhafte Einbindung von Funktionen in die Mountain-Top Plattform
Tabelle 6.4: Quellcode der Funktion Show_Status
Kapitel 8:
Tabelle 8.1: Gliederung des Lageplans in Ebenendekaden
Tabelle 8.2: SQL-Code der Anfrage von Informationen über Raumflächen einer Etage
Tabelle 8.3: Legende der Netzwerkmanagementsymbole







Einführung







Dieses Kapitel gibt eine kurze Übersicht über die Motivation der Diplomarbeit und beschreibt den dazu notwendigen relevanten Hintergrund. Im Anschluß daran werden die Teile der Diplomarbeit kurz umrissen.



Motivation







Facility-Management (FM) ist ein Begriff, der den Prozeß, mit dem eine Organisation ihre Arbeitsumgebung realisiert und unterhält, beschreibt. Eine Notwendigkeit zur Umsetzung des Facility-Managements läßt sich aus der Prämisse ableiten, Ressourcen stets adäquat zu planen und zu nutzen. Dabei spielt auch der Kostenfaktor eine wichtige Rolle.

Erste praktische Erfahrungen mit Facility-Management im Bau- und Immobiliensektor wurden in den USA bereits gesammelt, während in Europa vor allem Facility-Managementtheorie anzutreffen ist [AFCM96]. Daß die Auseinandersetzung mit dieser Thematik zwingend notwendig ist, beweist bereits die Tatsache, daß nicht einmal die Terminologie des Facility-Managements eindeutig geklärt ist. So beklagt sich zum Beispiel die Sulzer AG aus Winterthur wie folgt: "Facility-Management beschäftigt die Immobilienwelt seit Jahren. Doch anstelle von Klarheit herrscht babylonisches Sprachengewirr über den Begriff. Anstelle der dringendst benötigten Professionalität herrscht Amateurismus" [FRRE95]. Dies wird durch den branchenübergreifenden Charakter des Facility-Managements noch verstärkt, denn Facilities beschreiben Anlagen oder Gebäude, sei es in Bauwirtschaft, im Immobiliensektor, im Computer- und Elektrobereich oder in der Betriebswirtschaft. Deshalb ist die klare Abgrenzung des Aufgabenspektrums des Facility-Managements von höchster Priorität.

Dagegen ist das Netzwerkmanagement bereits klar definiert. Hier herrscht eine eindeutige Meinung vor, welche Aufgabenbereiche es umfaßt, und welche Komponenten es beinhaltet. Jedoch wurde noch längst nicht alles Wünschenswerte in die Realität umgesetzt. Beispielsweise erschweren unzureichende Standards, unterschiedliche Produktstrategien in Konkurrenz stehender Anbieter und natürlich der kurze Produktlebenszyklus der meisten physischen Komponenten die systematische Umsetzung von Netzwerkmanagement in die Praxis. Es beschränken sich viele große Anwender (auch aufgrund der explosionsartigen Expansion heterogener Netze) nur auf einige wenige Funktionsbereiche des Netzwerkmanagements, beispielsweise auf die Erkennung von Störungen im Betrieb (Fehlermanagement).

Es ist offensichtlich, daß Korrespondenzen zwischen beiden Managementarten bestehen. Das ist vor allem in der gemeinsamen Managementtheorie begründet, die beiden Arten zugrunde liegt. Auf der anderen Seite sind strukturelle Verbindungen naheliegend, denn ein Netzwerk und seine Bestandteile kann als eine notwendige Komponente (eine Facility) in einem operierenden Unternehmen betrachtet werden.

Neben einigen schon länger existierenden Softwareprodukten im Bereich Netzwerkmanagement sind in jüngster Zeit eine Vielzahl von Lösungen auf dem Gebiet des Facility-Managements entstanden. Diese werden zumeist unter der Kategorie Computer Aided Facility-Management (CAFM) geführt. Jedoch ist bei den meisten Produkten noch unklar, ob sie in Bezug auf ihren Funktionsumfang den Anforderungen einer branchenübergreifenden Anwendung des Facility-Managements genüge tragen. Insbesondere ist noch nicht geklärt, inwieweit sich die Systeme des Netzwerkmanagements und die des Facility-Managements miteinander verbinden lassen. Auch dazu soll diese Diplomarbeit einen Beitrag leisten.



Hintergrund







Wie bereits erwähnt, existieren verschiedene Lösungsansätze in den beiden Managementbereichen. In der Diplomarbeit wird deshalb versucht, diese zu verwenden und aus ihnen heraus eine Brücke zwischen Netzwerkmanagement und Facility-Management zu schlagen.

Aufbauend auf Netzarchitekturen unterschiedlicher Hersteller sind Netzwerkmanagementwerkzeuge entstanden, die meist nur für die eigenen Geräte konzipiert sind. Solche herstellerspezifischen Netzwerkmanagementwerkzeuge sind beispielsweise NetView im IBM-Umfeld oder OpenView von Hewlett Packard. Als kleinster gemeinsamer Nenner dieser Produkte wird oft nur das Simple Network Management Protocol (SNMP) unterstützt, das ein dringend benötigtes Hilfsmittel für die Integration unterschiedlicher Teilnetze darstellt, jedoch keine übergreifende Netzwerkmanagementstrategie ist [KAUF92]. Als eine solche übergreifende Strategie steht allein das OSI-Management zur Verfügung, das auf dem OSI-Basisreferenzmodell aufbaut und an dem seit Mitte der achtziger Jahre gearbeitet wird [GARB91]. Im Gegensatz zu SNMP ist es funktionell umfangreicher und baut voll auf einem objektorientierten Konzept auf. Aufgrund dieser Unterschiede wird untersucht, welches Konzept in Bezug auf die Aufgabenstellung geeignet ist, und welche Erweiterungen nötig sein werden.

Ebenso wie bei den Netzwerkmanagementwerkzeugen ist auch bei den Facility-Managementprodukten zu prüfen, welche Werkzeuge für den Einsatz in Kombination mit der Netzwerkmanagementsoftware in Betracht zu ziehen sind. Dies gilt insbesondere, da eine große Anzahl von Facility-Managementprodukten in ihrer universellen Anwendung Einschränkungen unterliegen. Um eine optimale Anbindung zu erreichen, muß dabei besonderer Wert auf die vorhandenen Schnittstellen gelegt werden.



Ergebnisse der Diplomarbeit







Um die in der Aufgabenstellung spezifizierten Lösungsvorschläge für eine Zusammenführung von Netzwerkmanagement und Facility-Management aufstellen zu können, wurden in einem ersten Schritt die beiden Managementarten, in diesem Bereich zur Verfügung stehende Softwaresysteme und auf ihnen aufbauende Architekturen analysiert.

In einem zweiten Schritt wurden die daraus resultierenden Charakteristika verglichen. Dabei wurde festgestellt, daß den Managementarten ähnliche Konzepte zugrunde liegen, die Softwaresysteme und speziell ihre Architekturen jedoch weitestgehend inhomogen sind und eine schlechte Ausgangsbasis für eine Zusammenführung bieten.

Aus diesem Grund wurden verschiedene Lösungsvorschläge unterbreitet und die dazu notwendigen Modelle erarbeitet. Diese beziehen sich auf Lösungen mit idealem Charakter und solche, die zum heutigen Zeitpunkt praktisch umsetzbar sind.

Daraufhin wurde ein einfaches Modell beispielhaft umgesetzt, dessen Integrationspunkte sich jedoch als sehr starr und inflexibel erwiesen. Deshalb wurde ein eigenes Managementprotokoll für die Kommunikation mit einem Netzwerkmanagementwerkzeug entworfen und implementiert. Dazu wurde ein eigener Kommunikationsstack auf der Grundlage von Interprozeßmechanismen entwickelt und dieser einerseits in das Werkzeug und andererseits in ein entwickeltes Modul für die Facility-Managementplattform eingebunden. Die entwickelte Lösung, die in einen Anwendungsfall des Facility-Managements integriert wurde, erwies sich als funktionsfähig und für andere Aufgabenbereiche erweiterbar.


Struktur

Die vorliegende Diplomarbeit wurde analog den durchgeführten Arbeitsschritten in acht Kapitel untergliedert:

Nach einer kurzen Einführung in Kapitel Eins werden in den Kapiteln Zwei und Drei die Charakteristika von Netzwerkmanagement und Facility-Management vor allem auf der Grundlage der Auswertung einschlägiger Fachliteratur analysiert. Ebenso werden an dieser Stelle spezielle Softwaresysteme ausgewertet.

Anschließend werden in Kapitel Vier die Gemeinsamkeiten und Unterschiede der Managementarten und deren Softwaresysteme hinsichtlich einer Kopplung beider ausgearbeitet.

Diese Analyse bildet die Grundlage für das Aufstellen von Lösungsansätzen, die die Verbindung beider Managementarten in Kapitel Fünf beschreiben. Dabei wird vor allem auf ein ideales und ein praktisch umsetzbares Modell eingegangen.

In den Kapiteln Sechs und Sieben ist die beispielhafte Realisierung des umsetzbaren Lösungsansatzes aus Kapitel Fünf beschrieben. Dazu wird zuerst ein einfaches und starres Modell realisiert bevor die volle Funktionalität des Lösungsansatzes integriert wird.

Im Kapitel Acht wird die Entwicklung eines Facility-Managementsystems für ein fiktives Gewerbegebiet beschrieben. Die Umsetzung wurde in Mountain-Top vorgenommen. Die Verbindung der Plattform mit dem entwickelten Werkzeug Ping, gelöst in Kapitel Sieben, wurde in dieses System integriert.

Kapitel Neun enthält eine Zusammenfassung der gefunden Ergebnisse und wertet diese aus. Ebenfalls werden Vorschläge für eine Fortsetzung dieser Arbeit gegeben.



Charakteristika des Netzwerkmanagements







Dieses Kapitel dient der Charakterisierung des Bereiches Netzwerkmanagement, wobei in weiten Teilen auf Fachliteratur und Normen eingegangen wird. Am Ende des Kapitels wird das Softwaresystem OpenView beschrieben, welches als typischer Vertreter dieser Managementkategorie zählt.

Bevor jedoch mit der Beschreibung von Netzwerkmanagement begonnen werden kann, wird im nachfolgenden Abschnitt kurz verdeutlicht, was ein Netzwerk ist, woraus es besteht und welche Ziele damit verbunden sind. Dann können Strategien und Konzepte aufgestellt werden, wie ein solches Netzwerk zu verwalten ist.



Einführung in die Netzwerkthematik


In den vergangenen Jahren sind Daten- und Rechnernetze entstanden, die es Nutzern ermöglichen, miteinander zu kommunizieren und Daten verschiedenster Art auszutauschen. Im Gegensatz zu den anfangs entstandenen Rechnernetzen, die proprietäre Systeme darstellten, sind heutige Rechnernetze offene Systeme. Die ISO veröffentlichte hierfür einen Standard, der als Open Systems Interconnection (OSI) bezeichnet wird. Netzwerke werden oft nach ihrer geographischen Ausdehnung klassifiziert. Dabei unterscheidet man sie in Local Area Networks (LAN) im lokalen Bereich, in Metropolitan Area Networks (MAN) im regionalen Bereich und in Wide Area Networks (WAN) für größere Netze.



Neben der physischen Struktur eines Netzwerkes ist die logische Struktur das wichtigste Klassifikationsmerkmal, das nötig ist, um den Grad der Komplexität von modernen, hochstrukturierten Netzwerken möglichst überschaubar zu gestalten. Die logische Struktur beschreibt dabei abstrahierend das funktionelle Wirkprinzip des Netzwerkes [LÖFF95]. Eine Untergliederung in Schichten ist hier verbreitet, wobei jede Schicht auf der ihr untergeordneten Vorgängerschicht aufbaut. In allen Netzwerken hat eine Schicht die Aufgabe, der übergeordneten Schicht einen bestimmten Dienst zu erbringen, wobei Bezeichnungen, Inhalte, konkrete Funktionen und auch die Anzahl der Schichten von Netzwerk zu Netzwerk differieren können [TANE92].

In [SMYT90] sind Schichtenmodelle für einige weit verbreitete Netzwerkarchitekturen beschrieben. Darunter befinden sich das OSI-Referenzmodell der ISO, die Systems Network Architecture (SNA) von IBM, die Distributed Network Architecture (DNA) von DEC, das Schichtenmodell der Defence Advanced Research Projects Agency (DARPA) und verschiedene Schichtenmodelle im LAN-Bereich (auf Basis des Manufacturing Automation Protocol (MAP) bzw. des Technical and Office Protocols (TOP)). Zusammenfassend sind diese in Tabelle 2.1 aufgeführt.




Disziplinen des Netzwerkmanagements


Netzwerkmanagement wurde in der Vergangenheit vor allem durch die verschiedenen Netzwerkarchitekturen und die Werkzeuge, die in ihnen zur Verfügung standen, geprägt (vgl. Abschnitte 1.1 und 1.2). An dieser Stelle wird deshalb allgemein und plattformübergreifend erläutert, welche Gebiete Netzwerkmanagement umfaßt.

Allgemein wird unter Management die zielgerichtete Koordination von Handlungen und Abläufen verstanden [HACK95]. In der Datenverarbeitung werden mit Management auch die Begriffe Verwaltung und Administration assoziiert [GARB91]. Um auf den Begriff Netzwerkmanagement schließen zu können, ist es nötig, die oben genannte allgemeine Definition auf die Objekte, aus denen Netzwerke bestehen, und Personen, die die Netzwerke nutzen, einzuengen. Zusätzlich sollte auch auf Prozesse, die im Netzwerk abgearbeitet werden, eingegangen werden.

Hierbei spricht man oft auch von Teilmanagementbereichen oder Disziplinen des Netzwerkmanagements. Ausgehend von den zu managenden Ressourcen klassifiziert [HENE95] drei klassische Disziplinen: Management der Komponenten des Kommunikationsnetzes (Netzmanagement), Management der Endsysteme und deren Bestandteile (Systemmanagement) und das Management der verteilten Anwendungen (Anwendungsmanagement) (siehe Abbildung 2.2). Neuere Auffassungen beziehen unter anderem auch die Benutzerverwaltung als separate Disziplin ein [HENE94], so daß sich folgende vier Schwerpunkte ergeben:

Management der Netzkomponenten (Peripherie und Übertragungsmedien)
Systemmanagement (Verwalten der Endsysteme und deren Bestandteile)
Nutzerverwaltung (Verteilung der verfügbaren Ressourcen auf die Nutzer)
Anwendungsmanagement (Verwaltung und Anpassung der Anwendungsprogramme auf die Netzwerkumgebung)


Eine allgemeinere Beschreibung der Gebiete des Netzwerkmanagement liefert [HPOV93]. Diese Ansicht umfaßt auch geographische und administrative Gesichtspunkte, Netzwerkprotokolle (vgl. Kapitel 2.1) und bezieht neben den Netzwerknutzern auch Administratoren, Operator und Manager ein. Die erwähnten Funktionsgebiete werden im folgenden Abschnitt näher erläutert.



Dimensionen des Netzwerkmanagements
Eine andere Klassifikation des Netzwerkmanagements ergibt sich aus der Betrachtungsweise von Dimensionen (vgl. [GARB91], [HACK95], [KERN92]). Folgende Dimensionen finden darin Berücksichtigung (siehe Abbildung 2.3):
Objektgruppen
Funktionsbereiche
Lebenszyklusphasen


Die Dimension Objektgruppe ist eng mit den im letzten Abschnitt dargestellten Disziplinen des Netzwerkmanagements verbunden. Sie abstrahiert dabei bezüglich der Betrachtungsweise der in Netzwerken auftretenden Objekten. Diese reichen von einzelnen Netzwerkkomponenten über Systeme, Anwendungen bis hin zum Enterprise Management, das die Teilbereiche des Netzwerkmanagements im Kontext des Unternehmens behandelt. In der Literatur werden häufig noch weitere Untergliederungen vorgenommen; in [GARB91] beispielsweise zwischen anwendungsinvariante Basissoftwaresysteme wie Datenbanken und Anwendungslösungen (Applikationen). In [KERN92] wird in dieser Dimension sogar zwischen Datennetzen und Sprachnetzen unterschieden.

Im Gegensatz dazu beschreiben die Funktionsbereiche die funktionellen Aspekte für die Objektklassen, und zwar in Bezug auf Konfiguration, Fehlerbehandlung, Leistungsbewertung und -abrechnung sowie Sicherheitsaspekte.

Laut [HENE95] umfaßt das Konfigurationsmanagement die Definition, Benennung und Initialisierung von Betriebsmitteln. Weiterhin können ihre Attribute eingestellt und geändert, die Zustandsdaten gesammelt sowie der Normalbetrieb gesichert werden. Der Begriff Betriebsmittel wird dabei synonym für Objekte verwandt, wie sie in den Objektgruppen auftreten, d.h. sie enthalten physikalische Netzwerkkomponenten, Softwareobjekte, aber auch Nutzer und Nutzergruppen [GARB91].

Die Funktion Fehlermanagement wird in [HENE95] mit der Erkennung, Lokalisierung und Behebung von Störungen umrissen. Die Fehlerprophylaxe kann als weiterer Bestandteil angesehen werden [HACK95]. [GARB91] gibt eine noch umfassendere Kategorisierung und definiert sieben Funktionsgruppen:

Entgegennahme und Sammlung von Informationen über anormale Situationen
Bewertung und Klassifikation der Informationen, aus denen Alarmmeldungen abgeleitet werden
Identifikation der Ursachen der Störungen (Störungsdiagnose)
Störungsbehebung durch Rekonfiguration, Reinitialisierung von Software etc.
Störungsregistratur und weitere Diagnose- und Behebungsmaßnahmen
Führen und Bewerten von Störungsstatistiken und Dateien mit Problembeschreibungen
Informieren der Nutzer über die Vorgänge
[GARB91] versteht unter der Funktion Leistungsmanagement die Aktivitäten, die mit der Überwachung und Beeinflussung leistungsrelevanter Parameter (Auslastung, Verbindungsaufbauzeit, Reaktionszeit etc.) zusammenhängen, um einerseits die Überlastung des Netzwerkes zu vermeiden aber andererseits eine sinnvolle Auslastung zu gewährleisten. Dabei ist das Aufstellen eines Modells über den Zusammenhang von Ursachen, Wirkungen und Beeinflussungsmöglichkeiten in Zusammenhang mit Messungen leistungsbezogener Kenngrößen notwendig. Diese Analyse resultiert dann in Konfigurations- bzw. Parameteränderungen oder in der Beeinflussung der Arbeitsleistung. Weiterhin beschreibt [GARB91], daß die Leistungskriterien zueinander in Widerspruch stehen können, beispielsweise die Verbesserung der Services des Rechnernetzes gegenüber der Auslastung der Netzressourcen. Ebenso muß beachtet werden, daß kontinuierliche Messungen die Leistungsparameter negativ beeinflussen können.
Das Abrechnungsmanagement hat zum Ziel, die vom Rechnernetz bereitgestellten Dienste nutzerbezogen zu erfassen und die Grundlage dafür zu schaffen, eine verursachungsgerechte Weiterbelastung zu den damit verbundenen Kosten zu ermöglichen [GARB91]. Dabei ist es eng mit der Benutzerverwaltung verbunden, denn die Netzwerkressourcen müssen für die Nutzer bzw. Nutzergruppen erfaßt, oder, wenn nötig, müssen für diese Limits festgelegt werden. [HENE95] ist sogar der Ansicht, daß die Benutzerverwaltung ein Teilbereich des Abrechnungsmanagements ist.

Das Sicherheitsmanagement beschäftigt sich mit der Authentisierung und der Zugangsüberwachung innerhalb der Rechnernetze, um Datensicherheit zu gewährleisten. [GARB91] unterteilt diesen Funktionsbereich in vier Aspekte: bau- und versorgungstechnische, organisatorische, technologische und programm- bzw. gerätetechnische Maßnahmen. Dabei bilden bau- und versorgungstechnische Maßnahmen den äußeren, physischen Rahmen für die Datensicherheit. Dazu gehören Standortauswahl, Baukonstruktion, Zugangssicherungen u.ä.. Organisatorische Maßnahmen werden mit der Schaffung eindeutiger Verantwortungsbereiche und deren Zuständigkeiten umschrieben. Zu den technologischen Maßnahmen gehören Datensicherungen sowie Kontrollmaßnahmen. Programm- und gerätetechnische Maßnahmen stellen die Autorisierungs- und Zugriffsmechanismen zu Ressourcen dar und stehen damit im engen Zusammenhang zur Benutzerverwaltung.

Die dritte Dimension gibt die Lebenszyklusphasen an. Hierbei wird im allgemeinen zwischen Planung, Installation, Betrieb und Migration unterschieden [GARB91]. Ausgehend von den erwarteten Anforderungen muß in der Planungsphase das Netzwerk hinsichtlich seiner topologischen und physischen Struktur entworfen werden (vgl. Abschnitt 2.1). Darauf basierend müssen dann die notwendigen Hard- und Softwarekomponenten ausgewählt werden, die in der Installationsphase in Betrieb genommen werden. Dazu gehört auch die Verkabelung. Die Überwachung und Steuerung des laufenden Betriebs erfolgt in der Betriebsphase. Mit steigenden bzw. fallenden Anforderungen an das Netzwerk oder bei technischen Neuerungen erfolgt häufig ein sogenanntes Redesign des Netzwerkes oder ein Austausch bzw. eine Weiterentwicklung von einzelnen oder komplexeren Netzwerkbestandteilen. Diese Aktionen ordnet man der Migrationsphase zu, die mit der Planungs- und Installationsphase bei einer existierenden Objektmenge verglichen werden kann.

Aufgrund der Vielzahl der auftretenden Kriterien, die man Netzwerken zuordnen kann, ist es möglich, weitere Dimensionen zu definieren, die über die behandelten hinausreichen. In [MNMT96] wird beispielsweise nach der Art der Kommunikation und anhand der unterschiedlichen Netztopologien in zwei neuen Dimensionen Kommunikationsdienste und Netztypen unterschieden (siehe Abbildung 2.4).







Anforderungen an das Netzwerkmanagement
Nach [KERN92] muß das Netzwerkmanagement das Ziel haben, den effektiven und effizienten Einsatz des Systems sicherzustellen. Dies trifft für das Netzwerkmanagement als Ganzes und für die in Abschnitt 2.2 genannten Teilbereiche oder Disziplinen des Netzwerkmanagements zu. In Bezug auf die konkreten Anforderungen eines Unternehmens können jedoch spezielle Ziele aufgestellt werden, z. B.:
optimale Auslastung des Netzwerkes, um Kosten einzusparen;
Verbesserung des Durchsatzes oder Verringerung der Antwortzeit für spezielle Dienste;
Verringerung der Mean Time to Repair bei auftretenden Problemen oder
Erhöhung der Produktivität der Netzwerkmanagementabteilung
[HPOV93] teilt diese Ziele in zwei allgemeine Bereiche, aus denen Anforderungen an eine Netzwerkmanagementsoftware abgeleitet werden können:
Einsparung von Kosten und
zuverlässige und konsistente Performance


Tabelle 2.3 verdeutlicht diese Ziele durch eine Auflistung der entsprechenden Anforderungen.

In [HEAB93] wird die Forderung eines integrierten Managementkonzepts aufgestellt. Das resultiert vor allem aus den Problemen bei Verwendung von isolierten Managementwerkzeugen in bezug auf Hersteller, Funktionsbereiche, Betrachtungsebenen, Zeitbereiche etc. Solche häufig auftretende Probleme sind:

eine Vielfalt von auftretenden Schnittstellen in heterogenen Netzen und deshalb die Forderung nach herstellerunabhängigen Schnittstellen für Managementfunktionen;
unzureichende globale Netzsicht aufgrund von komponentenorientierten Managementwerkzeugen, deshalb die Forderung nach einer globalen Beschreibungsebene;
redundante Netzbeschreibungen, aus der sich die Forderung nach einer einheitlichen funktionsbereichsunabhängigen Netzdatenbasis ergibt;
fehlende Unterstützung von Sichten auf gleiche Objekte und die damit verbundenen abgestuften Zugriffsrechte;
fehlende Integration der Zeitbereiche mit der daraus resultierenden Forderung nach Dokumentation der Informationen und deren Kontext in einer zeitlichen Abfolge und
fehlende Funktionalität einzelner Werkzeuge
Im Kontext des integrierten Managementkonzepts werden dann folgende Anforderungen gestellt:
Integration von Architekturen bzw. System- und Netztypen
Integration von Management-Funktionsbereichen
Integration von Organisationsaspekten (Domänekonzept)
Einheitliches Konzept für eine Management-Datenbasis
Weitgehend vereinheitlichte Konzepte für Netz- und Systemmanagement
Unterstützung verteilter Anwendungen und verteilter Systeme
Einheitliche Programmierschnittstellen und Bedienoberflächen
Managementarchitekturen
Nach [HEAB93] ist eine Netzwerkmanagementarchitektur ein allgemeines Rahmenwerk, mit dem sich bei einem gegebenen realen Netz mit entsprechenden Betreiberanforderungen ein konkretes Managementsystem entwickeln läßt. Dabei sollte es den in Abschnitt 2.4 genannten Anforderungen möglichst gerecht werden.


[STEV95] gliedert diese Architektur in vier grundsätzliche Funktionsebenen (siehe Abbildung 2.5). Darin hat jede Ebene eine Menge von definierten Aufgaben hinsichtlich der notwendigen Informationsgewinnung und -interpretation. Grundlage sind dabei die zu managenden Objekte (MO's), die Geräte, Systeme Datenbanken oder Applikationen (vgl. Abschnitte 2.2 und 2.3) sind. Grundsätzlich müssen diese Objekte keine physischen Elemente sein, in jedem Fall müssen sie aber Funktionen im Netzwerk bereitstellen, die eine Informationsgewinnung ermöglichen. Element Management Systeme (EMS) steuern diese Informationsgewinnung und verwalten die Erkenntnisse für ein spezifischen Teil des Gesamtnetzwerkes, z.B. ein SNMP Element Management System für alle SNMP-fähigen Objekte. Basis für das integrierte Management (siehe Abschnitt 2.4) sind Manager of Manager Systeme (MoM's), die die Informationen der Element Management Systeme integrieren. Die Benutzeroberfläche ist schließlich ein weiteres wichtiges Element in einer Managementarchitektur, denn alleinige Informationsgewinnung ist nicht ausreichend, wenn sie nicht darstellbar und steuerbar ist.

In der Literatur werden Managementarchitekturen häufig nach vier Gesichtspunkten betrachtet (siehe Abbildung 2.6), aus denen sich folgende Modelle ableiten lassen:

das Organisationsmodell;
das Kommunikationsmodell;
das Informationsmodell und


das Funktionsmodell
Nach [HEAB93] spiegelt sich im Organisationsmodell die räumliche Anordnung der Managementobjekte und deren Zuständigkeiten wieder. Daraus ergibt sich eine gewisse Anordnungsflexibilität hinsichtlich der Aufbau- und Ablauforganisation für den Netzbetreiber. Diese Anordnungsflexibilität ist geprägt durch den möglichen Dezentralisierungsgrad von Managementkomponenten, also die Verteilbarkeit der Funktionen Daten Sammeln, Daten Auswerten, Steuerung und Überwachung. Grundsätzlich unterscheidet man zwei Varianten: das symmetrische Konzept, das ein kooperatives Management gleichberechtigter Systeme vorsieht, und das hierarchische Konzept, das Systeme im Netz verschiedenen Hierarchiestufen mit unterschiedlicher Managementkompetenz zuordnet. Ebenso ist es möglich, Gruppen von Ressourcen aus ablauf- und aufbauorganisatorischen Gründen zu bilden, sogenannte Domänen. Solche Domänen können z.B. für die Funktionsbereiche Abrechnung, Sicherheit oder Konfiguration gebildet werden.
Grundlage für das Netzwerkmanagement ist das Informationsmodell, denn hierin wird die zugrunde liegende Datenbasis für die Managementinformationen definiert. Diese Datenbasis wird auch Management Information Base (MIB) genannt. Die in ihr gehaltenen Daten können nach [HEAB93] hinsichtlich folgender Quellen gewählt werden:

Managementanwendungen (z.B. Strategien, Algorithmen, Modelle, Managementlösungen)
Netzwerkbenutzer (z.B. Verzeichnisse oder Quality of Service Informationen)
Netzwerkbetreiber (z.B. Organisationsformen, Netzwerkinventar, Versionen, Lebenszyklus)
oder
Kommunikationsprotokolle
Hersteller
Netzwerkkomponenten
Auf Basis dieser Quellen unterscheidet man zwischen zwei Vorgehensweisen zur Gewinnung von Managementinformationen: dem Bottom-Up Verfahren, das die verfügbaren Informationen aus Protokollen, Komponenten und Produktvorgaben abstrahiert, und dem Top-Down Verfahren, das die benötigten Informationen aus den Anforderungen von Anwendungen, Betreibern oder Benutzern ableitet. Aufgrund dieser Konzepte kann dann ein konzeptionelles Schema für eine MIB modelliert werden, welches Informationen
zur Identifikation
zum Aufbau (Zusammensetzung)
zum Verhalten
zur Manipulationsfähigkeit
zu Beziehungen mit anderen Objekten und
zur Ansprechbarkeit
des Managed Objects (MO) beinhaltet.
Das Kommunikationsmodell legt Konzepte zum Austausch von Managementinformationen zwischen den Akteuren, z.B. Managed Object vs. Management System fest. Dazu müssen die kommunizierenden Partner festgelegt und die Dienste und Protokolle, mit denen die Kommunikation stattfinden kann, spezifiziert werden. Drei Arten der Kommunikation müssen beachtet werden ([HEAB93]):

der Austausch von Steuerinformationen zum Einwirken auf ein Objekt;
Statusabfragen und
Ereignismeldungen.
Aufgabe des Funktionsmodells ist es, allgemeine Managementfunktionen auf der Grundlage der Funktionsbereiche spezifisch zuzuordnen. Dabei legt es die erwartete Funktionalität, die Dienste, die notwendig sind, um diese Funktionalität zu erbringen und die Managementobjekte, die in dem Bereich von Interesse sind, fest. Laut [HEAB93] wird aufgrund dessen eine modulare Entwicklung von Managementwerkzeugen ermöglicht.


Managementwerkzeuge
Für das Erfüllen der Aufgaben des Netzwerkmanagements sind sogenannte Werkzeuge notwendig. Diese sind aber meist sehr spezifisch und unterstützen oft nur Teilaufgaben. Grundsätzlich unterscheidet man isolierte Werkzeuge und Werkzeuge, die in Managementsysteme integriert sind. Es ist offensichtlich, daß integrierte Werkzeuge für den Netzwerkmanager vorteilhafter sind, da sich alle Werkzeuge innerhalb eines Managementsystems einheitlich steuern lassen und einheitliche Schnittstellen besitzen. In [HEAB93] wird jedoch hervorgehoben, daß speziell bei größeren Kommunikationssystemen auf isolierte Werkzeuge auch bei Verwendung von umfangreichen Managementsystemen nicht verzichtet werden kann.


[TERP92] definiert drei Einsatzgebiete von Netzwerkmanagementwerkzeugen:

zur Unterstützung beim Erfassen von Daten (z.B. Abrechnungsinformationen oder zur Betriebsdatenerfassung);
bei der Reduktion und Analyse von Daten (z.B. Datenfilter oder Tools zur Datenkompression) und
Leistungsvorhersagen (z.B. Lastgeneratoren, Simulationssoftware oder Statistiksoftware)
Grundsätzlich lassen sich die Werkzeuge allen Dimensionen des Netzwerkmanagements (vgl. Abschnitt 2.3) zuordnen, meist werden sie jedoch nach Aufgaben- bzw. Einsatzbereichen klassifiziert (vgl. Abbildung 2.7).



Die Klasse der Prüfgeräte dient voranging der Überprüfung der physischen Übertragung. Das Spektrum reicht dabei vom klassischen Ohmmeter bis zu Bit Error Rate Testern (BERT), welche die Möglichkeit bieten, Multiplexer-Ports, digitale Übertragungseinheiten o.ä. zu überprüfen. Im allgemeinen wird zwischen analogen und digitalen Prüfgeräten unterschieden.

Protokollanalysatoren liefern auf Basis bekannter Protokolle Informationen über Konfiguration, Netzauslastung und Fehlerraten in den einzelnen Schichten des Protokollstacks.

Eine Vielzahl von einfachen, aber äußerst praktikablen Werkzeugen, die für TCP/IP basierte Kommunikationsnetze entwickelt wurden, sind als sogenannte Internet-Werkzeuge bekannt. TCP/IP ist z.Z. der wohl weitverbreitetste Protokollstack und bildet die Grundlage für das Simple Network Management Protocol (SNMP) (vgl. Abschnitt 2.8.2). Beispielsweise können mit Ping, einem Werkzeug dieser Kategorie, aktive Stationen innerhalb des Netzwerkes unter Verwendung des Internet Control Message Protocols (ICMP), ein Transportprotokoll innerhalb des TCP/IP-Stacks (vgl. [SANT95]), ermittelt werden.

Element Manager sind Systeme, die die Verwaltung von Objekten einer bestimmten Klasse, z.B. SNMP-fähige Objekte, unterstützen. Sie besitzen dabei meist eine größere Funktionalität als die vorher besprochenen Internet Werkzeuge, sie sind jedoch oft herstellerspezifisch. Eine Einbindung in eine allgemeine Managementarchitektur ist deshalb auch hier notwendig und wurde bereits im Abschnitt 2.5 erwähnt.

Dokumentationswerkzeuge finden bei der Darstellung und Verwaltung der physischen Infrastruktur des Netzwerkes Verwendung. [HEAB93] hebt hervor, daß die Informationen, die in diesen Werkzeugen gesammelt werden, meist statisch sind und daß deshalb die Komponenten hier nicht als aktive Elemente betrachtet werden. Die häufigste Anwendung von Dokumentationswerkzeugen findet im Bereich des sogenannten Kabelmanagements statt. Dazu gehört die Verwaltung der verwendeten Kabel selbst, aber auch die der Verbindungselemente und Endgeräte. Zusätzlich können organisatorische und geographische Informationen gespeichert werden.

Trouble Ticket Systeme (TTS) sind Werkzeuge zur Fehlerdokumentation. Dabei wird nach jedem entdeckten Problem ein sogenanntes Trouble Ticket erzeugt, das den Fehler und dessen Kontext beschreibt. Nachdem das Problem gelöst ist, wird auch die Information über die Fehlerbeseitigung dem Trouble Ticket angefügt. Die Grundlage eines Trouble Ticket Systems ist meist eine Datenbank, in der die Trouble Tickets verwaltet werden und aus der sie bei Bedarf abgerufen werden können. Dies ist immer dann der Fall, wenn ein neues Problem eintrifft. Das Trouble Ticket System überprüft dann die Datenbank, ob Gemeinsamkeiten mit schon gespeicherten Problembeschreibungen bestehen und kann daraufhin Lösungsvorschläge zur Beseitigung des aktuellen Problems treffen. Mit der Einbindung von entsprechenden KI-Techniken stellt diese Art der Problemlösung eine große Unterstützung für den Netzwerkmanager dar. Zusätzlich können Trouble Ticket Systeme zur Kostenminimierung beitragen, indem bei Neuanschaffungen beispielsweise nur die Geräte in Betracht gezogen werden, bei denen die Ausfallhäufigkeit besonders gering war, oder indem es über das Auslaufen eines Servicevertrages informiert.

Netzwerkmanagementplattformen







Managementplattformen sind Softwaresysteme, die die Grundlage für unterschiedliche Managementanwendungen oder Werkzeuge bieten, indem sie den Zugang zu den managementrelevanten Informationen (den Zugriff auf die Managed Objects) steuern [SEIT94]. Dabei basieren sie auf einer oder mehreren Managementarchitekturen. Gegenüber reinen Managementwerkzeugen bieten sie den Vorteil, eine integrierende Benutzeroberfläche zu besitzen, innerhalb der Managementarchitekturen Ressourcen unterschiedlicher Hersteller zu unterstützen und nicht auf einen bestimmten Funktionsbereich eingeschränkt zu sein. Weitere Funktionalität läßt sich durch Applikationen, die auf definierte Schnittstellen der Plattform zugreifen, ergänzen.

Der modulare Aufbau von Managementplattformen ist in [HEAB93] beschrieben. Darin wird zwischen drei Bereichen unterschieden: dem Oberflächenbaustein, mit dem der Benutzer kommuniziert, der Infrastruktur, die verschiedene Grunddienste bereitstellt, und den Anwendungen, die die beiden erstgenannten Komponenten nutzen, um die eigentliche Funktionalität des Netzwerkmanagements zu implementieren (siehe Abbildung 2.8). Im allgemeinen bieten die Managementplattformen bereits folgende Basisanwendungen: einen Zustandsmonitor, der zu überwachende Ressourcen in bestimmten Abständen hinsichtlich gewisser Schwellwerte überprüft, einen Ereignismanager, der die Annahme und Bearbeitung ankommender Ereignisse steuert, einen Konfigurationsmanager, der die Konfigurationsdaten der zu managenden Ressourcen verwaltet und deren Manipulation ermöglicht, einen Topologiemanager, der die Netzwerktopologie verwaltet und deren Änderungen überwacht, sowie einen Leistungsmonitor, der die Daten des Leistungsmanagements sammelt und bei Bedarf auswertet. Neben diesen Basisanwendungen können weitere Applikationen mit einem auf die Plattform zugeschnittenen Entwicklungswerkzeug entwickelt und in die Plattform integriert werden. Die Managementanwendungen greifen dann mittels Schnittstellen, sogenannter Application Programming Interfaces (API´s), auf die anderen Bereiche der Plattform zu.



Die Infrastruktur stellt den Anwendungen Dienste und Funktionen zur Verfügung, die den Zugriff auf Netzkomponenten und andere Managementstationen (Kommunikationsbaustein) und auf Managementinformationen (Informationsverwaltung) ermöglicht. Im Kommunikationsbaustein werden daher die Managementprotokolle, die für die Kommunikation mit den Komponenten und den Managementstationen notwendig sind, unterstützt. Wenn dennoch herstellerspezifische Systeme eingebunden werden sollen, die diese Protokolle nicht unterstützen, besteht die Möglichkeit, sogenannte Proxy Agents (Management-Gateways) einzusetzen, die die Translation der Aktionen und Informationen in die jeweiligen Protokolle vornehmen. Die Informationsverwaltung bildet die Schnittstelle zur Speicherung der Managementinformationen in einer Datenbasis. Als Datenbasis werden dateisystembasierte, relationale, objektorientierte oder aktive Datenbanken verwendet. Relationale Datenbanken sind vor allem wegen ihrer guten Ansprechbarkeit mit der Structured Query Language (SQL) beliebt, während objektorientierte Datenbanken besser an das objektorientierte Informationsmodell angepaßt sind. Mit aktiven Datenbanken besteht außerdem die Möglichkeit, den Daten Regeln anzufügen, so daß beispielsweise bei Eintritt eines spezifizierten Status automatisch bestimmte Aktionen ausgelöst werden.



Die Benutzeroberfläche ermöglicht den Zugriff auf die in der Plattform integrierten Funktionen und unterstützt diese, indem sie ihrerseits Navigationsfunktionen, Editierfunktionen und Suchfunktionen den Anwendungen zur Verfügung stellt. Die wichtigste Aufgabe ist jedoch die logische bzw. physische Repräsentation der Netztopologie durch Symbole, Maps und Submaps. Dabei repräsentiert ein Symbol ein Objekt (oder mehrere) in der Benutzeroberfläche. Alle darzustellenden Symbole werden in einer sogenannten Map verwaltet. Da jedoch die Topologie von Netzwerken oft stark strukturiert ist, wird die Map in Submaps, die meist hierarchisch miteinander verknüpft sind, unterteilt. Die Submap an der Spitze dieser Hierarchie wird als Submap Root bezeichnet.



Ausgewählte Netzwerkmanagementarchitekturen







Im Abschnitt 2.5 wurden Managementarchitekturen bereits allgemein beschrieben. In diesem Kapitel sollen jetzt die den Managementarchitekturen zugrunde liegenden Modelle für einzelne Architekturen näher erläutert werden.



Das OSI-Netzmanagement


Grundlage für das OSI-Netzmanagement bildet das OSI-Basisreferenzmodell (OSI-RM) [ISO_84], welches erstmalig 1979 veröffentlicht wurde. In diesem Referenzmodell wurden bereits erste Managementvorstellungen eingearbeitet [HACK95], die 1989 in einem Zusatz zum Modell resultierten. Dieser Zusatz [ISO_89] definiert ein sogenanntes Management Framework, das grundlegende Konzepte und Begriffe des OSI-Netzmanagements festgelegt, die in weiteren Dokumenten konkretisiert sind [HEAB93].

Die Architektur des OSI-Netzmanagements baut auf den in Abschnitt 2.5 erläuterten Modellen auf: Informationsmodell, Funktionsmodell, Kommunikationsmodell und Organisationsmodell, die im Management Framework integriert sind. Während das Informationsmodell und das Funktionsmodell schon umfassend standardisiert wurden, ist im Kommunikationsmodell nur das schichtenübergreifende Management ausgeprägt. Das Organisationsmodell ist derzeit nur ansatzweise im Systems Management Overview definiert. Abbildung 2.10 zeigt den architekturellen Zusammenhang der definierten OSI-Dokumente.

Das Informationsmodell basiert auf einem objektorientierten Ansatz. Ein Managementobjekt, das eine reale Ressource widerspiegelt, ist somit ein Objekt, das von einer bestimmten Objektklasse, in der die Attribute und Operationen des Objekts festgelegt sind, instantiiert wird. Die Beziehungen zwischen Objektklassen lassen sich mit Hilfe der Vererbung darstellen, wobei mehrfache Vererbung ausdrücklich erlaubt ist. Dem klassischen Paradigma der objektorientierten Programmierung wurde eine Vielzahl zusätzlicher Beschreibungsmöglichkeiten hinzugefügt, unter anderem auch die Allomorphie. Durch sie kann ein Objekt auf der Instantiierung mehrerer Objektklassen basieren [HEAB93] und sich dadurch entsprechend so verhalten, wie es gerade gefordert ist.

Die Beschreibung der Objekte erfolgt mit einer einfachen Template-Metasprache, der folgende allgemeine Struktur zugrunde liegt:

<template label> TEMPLATE NAME

[CONSTRUCT NAME [<construct argument>];]*

[REGISTERED AS <object identifier>];

Zur Definition eines Objektes wird die Template Struktur Managed Object Class (MOC) benötigt, weitergehende Beschreibungen sind mit Hilfe von acht zusätzlichen Template-Strukturen möglich.

<class label> MANAGED OBJECT CLASS

[DERIVED FROM <class label>[,<class label>]*;]

[ALLOMORPHIC SET <class label>[,<class label>]*;]

[CHARACTERIZED BY <package label>[,<package label>]*;]

[CONDITIONAL PACKAGES

<package label> PRESENT IF <condition definition>

[,<package label> PRESENT IF <condition definition>]*;]

[PARAMETERS <parameter label> [,<parameter label>]*;]

REGISTERED AS <object identifier>

Es ist möglich, Managed Objects Classes als Bestandteile einer übergeordneten Managed Object Class zu definieren und MOC-Enthaltenshierarchien aufzubauen. Dadurch wäre es leicht möglich, vordefinierte MOC-Bibliotheken zu schaffen, jedoch ist deren Standardisierung noch nicht abgeschlossen.

Innerhalb des OSI-Funktionsmodells erfolgt die Zuordnung der System Management Functional Areas analog den in Abschnitt 2.3 beschriebenen Funktionsbereichen des Netzwerkmanagements. Weiterführend wurden sogenannte Systems Management Functions definiert, die den fünf Funktionsbereichen zugeordnet werden können. Als Beispiel sei hier die Funktion Alarm Reporting genannt, die die Erkennung von Fehlern durch eine Reihe klassifizierter Alarmmeldungen unterstützt.

Im Kommunikationsmodell unterscheidet man drei verschiedene Ebenen zum Austausch von Managementinformationen zwischen Instanzen: das Schichtenübergreifende Management, das Schichtenmanagement und das Protokollmanagement. Als Instanzen werden Manager und Agenten vorgesehen. Das Schichtenübergreifende Management betrifft das Management des Systems als Ganzes, also über alle sieben Schichten des OSI-Referenzmodells, während im Schichtenmanagement nur eine Schicht in Betracht gezogen wird. Als Protokollmanagement werden Mechanismen bezeichnet, die ausschließlich einer Kommunikationsinstanz zugeordnet werden können. Im Bereich des Schichtenübergreifenden Managements wurde ein Managementprotokoll zur Kommunikation zwischen Manager und Agent definiert: das sogenannte Common Management Information Protocol (CMIP). Die zugehörigen Dienste sind im Common Management Service (CMIS) genormt. Prinzipiell unterscheidet man zwei Dienstklassen: Management Notification (vom Agenten ereignisbezogen ausgelöst) und Management Operation (vom Manager ausgelöst). Managementoperationen kann man weiter untergliedern in objektbezogene (create, delete, action) und attributbezogene (get, set etc.) Operationen.

Das Organisationsmodell geht aus dem Management Systems Overview (ISO 10040) nur in groben Zügen hervor. Es sind jedoch die Rollen der Akteure ersichtlich: Manager und Agenten. Dabei ist es prinzipiell möglich, daß ein Akteur beide Rollen ausübt. Der Einzugsbereich eines Managers wird Domäne genannt. Hier sind Domänenkonstellationen aus funktionalen und organisatorischen Gesichtspunkten vorgesehen.

Zusammenfassend kann das OSI-Netzmanagement in seinem Umfang als mächtig, aber erheblich komplex angesehen werden. [HEAB93] gibt zu bedenken, daß noch nicht das gesamte Spektrum des OSI-Netzmanagements standardisiert ist. [SEIT94] bezeichnet die Komplexität als den größten Nachteil, der viele Anbieter davon abgehalten hat, in ihren Komponenten das OSI Netzmanagement zu unterstützen. Jedoch ist [KERN92] der Ansicht, daß der OSI-Ansatz der bessere für die Betreiber eines umfangreichen heterogenen Netzes ist.



Das Internet-Management
Ähnlich wie das OSI-Netzmanagement bietet das Internet-Management Lösungsansätze für herstellerübergreifende Managementlösungen. Jedoch werden hier im Gegensatz zum OSI-Netzmanagement einfache und implementierungsfreundliche Konzepte angestrebt.
Standard-Nr. Name Bemerkung
RFC 1155 Structure of Management Information Full Standard
RFC 1156 Management Information Base for Network Management of TCP/IP-based Internets Full Standard
RFC 1213 Management Information Base for Network Management of TCP/IP-based Internets (MIB II) Full Standard
RFC 1212 Concise MIB Definitions Draft Standard
RFC 1157 Simple Network Management Protocol (SNMP) Full Standard
RFC 1095 Common Management Information Protocol over TCP (CMOT) Draft Standard


Nach Entstehung des Internets in den 70er Jahren wurde relativ schnell die Notwendigkeit der rechnergestützten Verwaltung in diesem sehr umfangreichen Netz erkannt. Innerhalb des Internet Activities Board (IAB), einer Organisation, die Forschungen und Standardisierungen innerhalb des Internets betreibt, wurden dann nach und nach sogenannte Request for Comments (RFCs) veröffentlicht, die Standards im Internetbereich darstellen. Die wichtigsten RFCs, die den Internet-standard Management Framework bilden [HEAB93], umfassen zwei Teilgebiete: das Informationsmodell mit dem Standard über die Informationsstruktur (RFC1155) und den Definitionen zur Management Information Base (RFC1156 bzw. RFC1213); und das Kommunikationsmodell mit den Managementprotokollen SNMP (RFC1157) bzw. CMOT (RFC1095).
[ROCL90] legt die Struktur der Managed Objects fest, die im Gegensatz zum OSI-Ansatz keinem objektorientierten Konzept unterliegen das ein explizites Klassenkonzept mit Vererbungstechniken unterstützt [HEAB93]. Dennoch können die Managed Objects aus einer Art Klassendefinition instantiiert werden. Diese Klassendefinition, in [ROCL90] Object Type Definition genannt, beinhaltet wenige, elementare Attribute: eine Objektidentifikation, seine Syntax, eine allgemeine textuelle Beschreibung, die Zugriffsart und einen Objektstatus. Es wird ausdrücklich darauf hingewiesen, daß diese Spezifikation, wie das gesamte Konzept des Internet Managements, einer einfachen aber ausbaufähigen Struktur folgt. Somit sind weitere Attribute, die in der Zukunft hinzugefügt werden könnten, möglich.

Die Registrierung der Objekte erfolgt mit Hilfe der Objektidentifikation der Klassendefinition innerhalb eines Registrierungsbaumes. Dieser Registrierungsbaum ist dem Objektidentifikator-Namensbaum der ISO bzw. CCITT konform und deshalb dort im Zweig iso org dod mit dem Namen internet plaziert (im Auftrag des DoD, Department of Defence der USA, wurde das Internet erstmalig realisiert) (siehe Abbildung 2.11). Der Internet-Registrierungsbaum strukturiert sich wiederum in mehrere Zweige, sogenannte Subtrees. Die wichtigsten sind mgmt, in dem Standard-MIBs definiert sind, und private enterprise, in dem herstellerspezifische Objekte registriert werden können.



Wie bereits angedeutet, sieht das Internet-Management zwei Protokolle zur Kommunikation vor: das Simple Network Management Protocol (SNMP) und das Common Management Information Protocol over TCP (CMOT). Grundsätzlich basieren beide Protokolle auf der organisatorischen Vorgabe, daß Manager und Agenten zur Kommunikation vorhanden sein müssen. Das Organisationsmodell beschränkt sich jedoch darauf, daß ausschließlich Manager und Agenten miteinander kommunizieren können, nicht aber Manager mit Managern oder Agenten mit Agenten [HEAB93]. Mit dem Protokoll CMOT wurde versucht, das OSI-Managementprotokoll CMIP (vgl. Abschnitt 2.8.1) in die Internet-Architektur einzubinden. In der Folgezeit hat man sich jedoch auf SNMP konzentriert, so daß für CMOT nur ein sogenannter Draft Standard existiert. Innerhalb des TCP/IP Stacks setzt SNMP auf dem User Datagram Protocol (UDP), einem verbindungslosen Transportprotokoll, auf. Es besitzt fünf Operationen und zugehörige Protokolldateneinheiten: GetRequest, GetNextRequest, SetRequest, GetResponse und Trap [CAFE90]. Der Manager kann GetRequests und Get-NextRequests senden, der Agent mit einem GetResponse antworten oder einen Trap (Ereignismeldung) im Ausnahme- oder Fehlerfall übermitteln. Zur Vereinfachung wurde in SNMPv2, einer Erweiterung des Standards (siehe RFC1441 ff.), die Möglichkeit gegeben, aufeinanderfolgende GetNextRequests durch eine einzelne GetBulk Operation zu ersetzen [SEIT94]. Zusätzlich wird mit einem sogenannten Inform-Dienst die Kommunikation zwischen Managern ermöglicht, wodurch Domänenbildungen denkbar werden.

Das Ziel, einen einfachen Netzwerkmanagementstandard zu schaffen, der in vergleichsweise kurzer Zeit realisierbar ist, wurde mit dem Internet-Management und SNMP erreicht, denn im Gegensatz zum OSI-Ansatz unterstützen derzeit alle marktrelevanten Netzwerkmanagementplattformen SNMP (vgl. Kapitel 2.9). Somit ist SNMP, das anfangs als Übergangslösung angedacht war, zum de-facto Standard im Bereich des Netzwerkmanagements geworden [ROSE91], [SEIT94]. Dessen Nachteile liegen in seinem einfachen Aufbau begründet, der viele Aspekte des Netzwerkmanagements, die im Kapitel 2 erläutert wurden, ausschließt. Aus diesem Grund ist [HEAB93] der Meinung, daß das Internet-Managementkonzept gegenüber dem OSI-Konzept das schwächere und für komplexe Managementaufgaben das weniger geeignete ist.


OpenView als ausgewählte Netzwerkmanagementplattform

Nachdem Managementplattformen im Abschnitt 2.7 allgemein diskutiert wurden, soll in diesem Kapitel ein spezielles Softwareprodukt dieser Art vorgestellt werden. Bei der Auswahl des Produkts wurden nur herstellerübergreifende Plattformen in Betracht gezogen, denn nur mit diesen ist das Management von heterogenen Netzwerken möglich. Wie in Abschnitt 2.7 erläutert, können Netzwerkmanagementplattformen mehrere Managementarchitekturen unterstützen. Jedoch mußte beim Vergleich der marktrelevanten Produkte festgestellt werden, daß dies nur angedacht ist; praktisch umgesetzt ist nur eine Architektur: des Internet-Management. Wegen des gemeinsamen Ansatzes des Internet-Managements der konventionellen Plattformen soll hier nur eines der wichtigsten besprochen werden: HP OpenView, das nach Meinung von [BOAR96] eines der derzeit ausgereiftesten Produkte hinsichtlich der offenen Systemunterstützung ist.



Struktureller Aufbau


HP OpenView ist eine modular aufgebaute Managementplattform für TCP/IP basierte Netze. Genauer betrachtet besteht sie aus einem Kernsystem, der OpenView Management Plattform, in die zahlreiche Managementanwendungen integriert werden können. HP OpenView wurde für eine Vielzahl von Betriebssystemen entwickelt, darunter verschiedene Unix-Derivate und Microsoft Windows. Je nach Betriebssystem sind die interne Architektur und mitgelieferte Tools unterschiedlich, z.B. unterliegt OpenView für Unix-Systeme mit X-Windows Oberfläche der Struktur in Abbildung 2.12, die [EIHO93] entnommen wurde. Die Managementplattform benutzt zur Kommunikation mit SNMP-Agenten den Direct SNMP Stack. Anwendungen können mittels der Consolidated Management Schnittstelle auf interne Funktionen wie Object Registration Service (ORS) und Event and Data Management Services (EMS) sowie auf die Distributed Management Infrastructure zugreifen. Außerdem bietet die API Funktionen, um externe Managementprotokolle anzusprechen - eine CMIP Managementapplikation wäre nach dieser Darstellung integrierbar. Zum relationalen Datenbankmanagementsystem muß bemerkt werden, daß es nach den vorliegenden Informationen nicht als offene Datenbank benutzt werden kann und nicht standardmäßig mitgeliefert wird (Dateiimplementation ist Standard).

Nach [HPOV93] sind als Basisanwendungen der Plattform die Oberfläche OpenView Windows, die Module IP Discovery and Layout, SNMP Event Handling and Browsing, SNMP MIB Loader and Browser, ein Grapher Tool sowie Data Presentation Commands und ein Remote Telnet vorhanden.



Die Benutzeroberfläche unterstützt die Darstellung von hierarchischen Maps in jeweils eigenen Fenstern, wobei Symbole mehreren Submaps zugeordnet werden können. Es ist ebenfalls möglich, Domänen zu bilden (verschiedene Maps für eine Menge von Netzwerkobjekten) und so das Netzwerk aus mehreren Gesichtspunkten zu betrachten. OpenView Windows unterstützt das Aktualisieren der Maps in Echtzeit durch entsprechende Deamons (Applikationen, die im Hintergrund arbeiten und einen bestimmten Kontext überwachen). Managementapplikationen können durch Menüs angesprochen werden.

Verantwortlich für den Bereich IP Discovery and Layout sind die Prozesse Internet Protocol Map Application (IP Map), IP Topology Manager und IP Discovery & Status. IP Map bildet die Schnittstelle zur Benutzeroberfläche, indem es die Maps verwaltet (zentrale Aufgabe), durch zwei Hintergrundprozesse addressierbare Knoten im Netz überwacht (Netmon) und wenn nötig, die Aktualisierung der Oberfläche veranlaßt (Ovtopmd).

Zur Überwachung des Netzwerks (Monitoring) bietet OpenView Funktionen zum Ansehen von SNMP-Ereignissen, Gerätekonfigurationen, der Aktivität in den einzelnen Stationen sowie der Auslastung des Netzwerks. Unterstützt werden diese Funktionen durch das Graph Utility, das die Ergebnisse grafisch darstellen kann.

Die Ereignisverwaltung ist zentraler Bestandteil des Eventmanagers. Er ermöglicht es weiterhin, die Ereignisse zu kategorisieren, zu filtern oder einfach durch sie zu "browsen". Zusätzlich besteht die Möglichkeit, bei Auftreten bestimmter Ereignisse Aktionen auszulösen, die auch das Ausführen externer Programme (z.B. Shell-Scripts o.ä.) beinhalten. Der Zusammenhang einiger der genannten Module ist in Abbildung 2.13 ersichtlich.



Ein Anwendungsfall


Zur genaueren Untersuchung stand das System OpenView für Microsoft Windows zur Verfügung. Hierin wurde ein fiktiver Anwendungsfall dargestellt, der die Verwaltung des Netzwerkes eines Gewerbegebiets beinhaltet. Die dazu notwendigen Maps und Submaps wurden mit den in OpenView zur Verfügung stehenden Funktionen kreiert.

Abbildung 2.14 stellt die Submap Root dar, die basierend auf dem Lageplan, der durch Einfügen einer speziellen Grafik entstand, die Netzwerkelemente eines FDDI-Doppelrings enthält. Da das Netzwerk nicht real existiert, wurden diese Elemente manuell mit den Editierfunktionen erstellt und an die entsprechenden Stellen verschoben. Die Verknüpfungen zu den jeweiligen Submaps, die sich an den Haushubs befinden, wurden ebenfalls manuell erstellt.



Abbildung 2.15 zeigt eine solche Submap, die eine Etage eines Gebäudes darstellt. Ebenso wie in der Submap Root wurde hier eine Grafik unterlegt - die entsprechenden Netzwerkelemente, die durch die Auto-Discovery-Funktionen von OpenView entstanden, entsprechen jedoch denen eines real existierenden lokalen Netzwerkes. Dabei wurde festgestellt, daß die Auto-Discovery-Funktionen akkurat das reale Netzwerk widerspiegeln. Die entsprechenden Konfigurationsparameter, darunter die Internet-Adresse und der Systemname, wurden den Elementen ebenfalls automatisch zugeordnet.

An einigen dieser Elemente, eine HP Workstation und verschiedene PC´s, wurde die Funktionalität zum Überwachen des Netzwerkes näher untersucht. Als Erstes wurden die SNMP-Funktionen getestet. Im Gegensatz zur Workstation, die schon ein entsprechenden SNMP-Deamon besaß, mußten auf den PC´s spezielle Public-Domain SNMP-Agenten installiert werden, die hinsichtlich ihrer Konfiguration jedoch zu wünschen übrig ließen. Damit wurde es allerdings möglich, SNMP-Reuests aus OpenView an alle Stationen abzusetzen. Die dazu notwendigen MIB´s waren bereits im System vorhanden. Durch eine entsprechende Menüstruktur bei OpenView war es möglich, durch alle Zweige des Internet-Baumes (vgl. Abschnitt 2.8.2) zu browsen.

Ein weiteres wichtiges Anwendungsgebiet des Netzwerkmanagements ist die Überwachung hinsichtlich Störungen und Ausfällen (Fehlermanagement). OpenView bietet dazu ein Polling-Mechanismus, der alle aktiven Elemente in Abständen überprüft und die dabei entstandenen Ergebnisse protokolliert. Die Variation der Intervalle kann dabei für jede Station individuell angepaßt werden. Ebenso ist es möglich, die Art des eventuellen Ausfalls für ein Gerät spezifisch festzulegen. Bei Eintritt wird dann automatisch dieser Fehler protokolliert und die Map entsprechend neu dargestellt. Abbildung 2.15 verdeutlicht einen solchen Fall. Es wurde festgestellt, daß bei ausschließlicher Nutzung der Managementstation für OpenView die Anzeigen korrekt erschienen - ein simples Kopieren einer Diskette im Hintergrund war jedoch für die Managementanwendung Anlaß genug, den Totalausfall des Netzwerks zu melden.

Zusammenfassend muß bemerkt werden, daß die untersuchte Basisversion von OpenView für Microsoft Windows zwar grundlegende Managementanwendungen mitbringt, die Anwendungsvielfalt, die für Unix-Plattformen zur Verfügung steht, aber nicht erreicht. Aus diesem Grund und den genannten Abstrichen hinsichtlich der Robustheit erscheint es für große Netzwerksysteme nur bedingt geeignet.


Charakteristika des Facility-Managements

Facility-Management ist eine Managementdisziplin, die in den 70er Jahren aus einem praxisorientierten Kontext heraus entstand, die jedoch bis heute nicht eindeutig definiert wurde. Deshalb wird in diesem Kapitel versucht, die Entstehungsgeschichte kurz zu erläutern und im weiteren eine Definition zu Facilities und den Funktionsgebieten des Facility-Managements zu geben.


Die Entstehungsgeschichte des Facility-Managements







Der Begriff Facility-Management entstand in den USA bei dem Versuch komplexe Anlagen unternehmensweit zu bewirtschaften. Im Vordergrund stand dabei das Ziel, Kosteneinsparungen durch zielgerichtete Planung, Realisierung und Bewirtschaftung von verschiedenartigen Anlagen zu erreichen. Im Englischen wird dies oft durch die Schlagworte "meet the organisations objectives at best cost" repräsentiert [UGLA94]. Je nach Unternehmensart wurden dann unterschiedliche Schwerpunkte gesetzt, so beschränkte man sich beispielsweise in der Immobilienbranche auf das Verwalten von Flächen und Räumen. Ebenso traten unterschiedliche Ansichten bezüglich des Zeithorizonts auf, z.B. wurde in der Baubranche der Schwerpunkt auf Planung und Realisierung von Facilities gesetzt. 1980 wurde die International Facility Management Association (IFMA) in den USA gegründet, die sich vorrangig mit den praktischen Problemen der Facility-Manager, einer Berufsbezeichnung, die inzwischen entstanden war, beschäftigt.

Nach der Übernahme des Modewortes Facility-Management in Europa in den 80er Jahren versuchte man hier, eher theoretisch als praktisch an den Begriff Facility-Management heranzugehen. 1988 versuchte die Europäische Facility-Management Vereinigung (EUROFM) erstmalig, den Begriff Facility-Management (in einem jedoch unveröffentlichten Manuskript) zu definieren [FRRE95]. Darin heißt es: Facility-Management ist ein "ganzheitlicher strategischer Rahmen für koordinierte Programme, um Gebäude, ihre Systeme und Inhalte kontinuierlich bereitzustellen, funktionsfähig zu halten und an die wechselnden organisatorischen Bedürfnisse anpassen zu können". In der Folgezeit sind noch weitere Definitionen entstanden, die in den folgenden Abschnitten vorgestellt werden.



Ziele des Facility-Managements

Ein bereits erwähntes Ziel des Facility-Managements ist die Minimierung von Kosten durch eine ganzheitliche Betrachtung der Einric
16 Aug 2005
08:34:57
Friederich
Diplomarbeit über Facility Management
Hallo, Ich möchte mein Diplomarbeit über FM schreiben. Eine Richtung habe ich schon ausgesucht. Es ist Lebenszykluskosten im FM. Ich suche mir jetzt Bücher, Matreialen oder eine Diplomarbeit dafür. Vielleicht kann einer mir da weiter helfen. Vielen Dank im Voraus!
16 May 2007
00:07:33
annasun
Diplomarbeit über Facility Management
Hey, ich möchte meine Diplomarbeit auch gerne über das Thema "Flächenoptimierung im Facility Management"( ausgeführt am Beispiel eines bereits bestehenden Büro-Komplexes) schreiben und bin daher auch auf der Suche nach aller Art Buch- und Info-Material sowie bereits bestehender Diplomarbeiten bezüglich dieses Themas.Wer kann mir vielleicht Hinweise oder Empfehlungen geben?Vielen Dank im Voraus!
10 Mar 2009
16:53:45
Pierre

Auf diesen Beitrag anworten
Sie sind nicht eingeloggt. Geben Sie daher bitte Ihren Namen an. (freiwillig)
Ihr Name 
Betreff
Text

Um unerlaubte Einträge in diesem Forum zu vermeiden müssen Sie jetzt diesen Code in das daneben stehende Fenster eintragen.
Nur wenn der Code richtig ist, wird der Eintrag gespeichert.
Vielen Dank für Ihr Verständnis.