   
|
| Online Forum |
Startseite - Facility Management Forum - Facility Management Markt Trends Pottenzial Lifecycle Publikationen Literatur Studien
Facility Management Markt Trends Pottenzial Lifecycle Publikationen Literatur Studien
| Text |
Datum |
Benutzer |
Facility Management Markt Trends Pottenzial Lifecycle Publikationen Literatur Studien
Guten Morgen,
wir suchen Publikationen, Studien,Literatur zum Thema "wie gross ist der Facility Management Markt, "HEUTE MORGEN und ÃœBERMORGEN".
Vielen Dank zum voraus.
Gruss Freuler
|
22 Feb 2005
08:26:00 |
Freuler |
Facility Management Markt Trends Pottenzial Lifecycle Publikationen Literatur Studien
Tag,
aus meinem Trend Fundus Text und Links,viel Erfolg!
Gruss Traugott
Trends im FM-Markt
Entwicklung der IT-Technologie
Erst mit der "Dokumentation der Wahrheit" über die Facilities lassen sich wesentliche Einsparpotenziale im Anlagenbetrieb erschließen. Die Entwicklung der IT-Technologien fördert die kostengünstige Erarbeitung der Grundlagen für den FM-Prozess.
Steigerung der Effektivität
Wird der FM-Manager frühzeitig in den Prozess der Planung und Realisierung integriert, können die Wünsche des Betreibers einbezogen werden. Reklamationen, Umbauten etc. können eingeschränkt werden.
Wachsender Automatisierungsgrad
Der wachsende Automatisierungsgrad der Gebäude bis hin zur künstlichen Intelligenz" verlangt nach Servicekonzepten, die dem Nutzer helfen, die den Facilities innewohnenden baulichen und technischen Möglichkeiten zu erschließen.
Integration der Interessen
Interessen der Eigentümer, Nutzer und Betreiber werden durch integriertes FM berücksichtigt.
Im Zusammenhang mit den Leistungsbildern vorwiegend im Immobilienbetrieb hat in den letzten Jahren der Begriff „Facility Management“ (FM) Furore gemacht. Einen bis anfänglich zu 800 Mrd. DM hochstilisierten Markt vor Augen, haben eine Vielzahl tra-ditioneller Anbieter von Dienstleistungen rund um das Gebäude ihre Kapazitäten stark erweitert. Auch drängen immer neue Anbieter aus den verschiedensten Bran-chen und Organisationsstrukturen auf den Markt. Während die einen erst losmarschieren, verlassen andere schon wieder das Kampf-feld um die Marktanteile, enttäuscht vom bisherigen Ergebnis ihres Engagements. Abgesehen von den bekannten infrastrukturellen Dienstleistungen, die sich offen-sichtlich mit dem vermeintlichen „Qualitätssiegel“ Facility Management besser ver-kaufen lassen, tun sich die Anbieter schwer, ihren Kunden einen nachhaltigen Nut-zen der von ihnen angebotenen breiten Leistungspalette nachzuweisen. Doch solan-ge dieser angeblich zu generierende Nutzen für den Kunden nicht greifbar wird, und überzeugende Konzepte für kundenspezifische Problemlösungen nicht vorliegen, wird man mit „Facility Management“ wenig verdienen können. Diese Erkenntnis be-deutet aber auch, dass der Markt überhaupt erst noch gestaltet werden muss! Was verbindet sich mit dem Begriff Facility Management? Zuerst einmal ist festzustellen, dass immer mehr Klarheit darüber besteht, was man von FM erwarten darf und welchen Zielen es dient. Die beiden Fachverbände GEF-MA (Deutscher Verband für Facility Management e.V. – www.gefma.de) und IFMA (International Facility Management Association – www.ifma-deutschland.de) haben hier in den letzten Jahren intensive Arbeit geleistet und im deutschsprachigen Raum speziell der GEFMA mit seiner Richtlinienarbeit wesentlich zum FM-Verständnis so-wie zur Bereitstellung von Wissensbausteinen (Richtlinien) für den FM-Prozess bei-getragen. Besonders anerkennenswert dabei sind die erarbeiteten Grundlagen für die Aus- und Weiterbildung und deren Normative sowie in diesem Zusammenhang auch die Unterstützung für die Herausarbeitung spezieller Berufsbilder im FM Pro-fessionelle Ausbildungseinrichtungen, also Hochschulen, Universitäten und aner-kannte Aus- und Weiterbildungseinrichtungen privater Anbieter vermitteln in ihren Kursen die Definitionen des FM auf Grundlage der Verbandsvorgaben. Bei hier aus-gebildeten Fachkräften darf man das entsprechende Selbstverständnis schon erwar-ten.“ Insofern besteht Optimismus, dass für FM immer mehr qualifizierte Kräfte zur Verfügung stehen werden. Problematisch bleibt der Umgang mit dem Begriff „Facility Management“ dennoch. Die seit Jahren spürbare Inflation der Managementbegriffe hat eine Deflation des Anspruchs zur Folge, d. h. es wird immer weniger reflektiert, was es heißt zu mana-gen, denn die Aktion bestimmt zunehmend das Sein und leider auch das Bewußt-sein. Auch der Begriff "Facility Management" läuft Gefahr, vom (sinnbildlich gespro-chen) Degradieren des Managements erfasst zu werden. So ist für die einen FM nur "eine dieser neumodischen Bezeichnungen für das was wir schon lange tun" z.B. Hausmeister, Instandhalter, Gebäudereiniger usw. für andere vordergründig ein Re-putationsbegriff. Aus dieser Fehleinschätzung resultiert letztlich auch die besonders
10.01.02 1
in Deutschland verbreitete Identifizierung des Facility Management mit den klassi-schen Dienstleistungen für den Gebäudebetrieb schlechthin. Tatsächlich ist FM eine unternehmerische Aufgabe im gesamten Lebenszyklus1 der Facilities2, die höchste Ansprüche an die Managementqualitäten der Führungskräfte stellt. Facility Management verlangt ganzheitliches Denken und Handeln sowie eine an den Zielen der FM-Organisation orientierte Managementphilosophie. Der Sinnbezug im FM wird geprägt durch bewusstes "Dienen" - hier als eine Leistung mit der das wirtschaftliche Ergebnis aus der Nutzung der Facilities verbessert und gleichzeitig das Business/Kerngeschäft der Nutzer von Facilities unterstützt wird. Bild 1: Komponenten des Führungsprozesses [1] Der Facility Manager versteht sich damit als Dienstleister und/oder Consulter für Ei-gentümer und Nutzer von Facilities. Das Managen des Dienstleistungs- oder Consul-tingprozesses hat, wie bei anderen Führungsprozessen auch, jeweils eine strategi-sche, normative und operative Dimension (Bild 1), deren Gewichtung in Abhängigkeit der Lebenszyklusphase der Facilities zu sehen ist, in der die FM-Organisation tätig wird.
1 Zeitabschnitt zwischen Idee, Planung, Realisierung, Nutzung, ggf. Umbau und Umnutzung bis zum Rückbau und Recycling von Facilities 2 Sammelbegriff für Liegenschaften, Gebäude, bauliche und technische Anlagen; auch als Synonym für Anlagen allgemein bzw. im Zusammenhang mit dem Begriff Anlagenwirtschaft
10.01.02 2
Facilities zu managen bedeutet: „Ganzheit normativer, strategischer und operativer Management-leistungen der Führung von Dienstleistungsprozessen bei der Entwicklung, Bereitstellung, Nutzung und Umnutzung von Facili-ties (Gebäude, technische Anlagen...). Die strategische Erfolgsposition besteht in der Optimierung der wirtschaftlichen und ökologischen Nutzungsergebnisse im ge-samten Lebenszyklus der Facilities.“ Diese FM-Organisation wiederum wird bestimmt durch eine Vielzahl von Einflussfak-toren auf den Facility Managementprozess, klassifizierbar in gesellschaftliche, mak-rostrukturelle und mikrostrukturelle Einflüsse. Der Facility Managementprozess ist also von außerordentlicher Dynamik gekennzeichnet, bei dem es darauf ankommt, dass die FM-Organisation, aufbauend auf ihrer jeweiligen Kernkompetenz, sich an den objektkonkreten Bedingungen orientiert und den sich verändernden Leistungs-schwerpunkten und Bedürfnissen schnell anpassen kann. Bild 2: FM im Spannungsfeld von Major Players und Kerngeschäft Aus seiner Stellung gegenüber den Major Players3 der Anlagenwirtschaft wird auch das komplexe Anforderungsbild an den Facility Manager erahnbar. Der Facility Manager benötigt zur Führung der integrierten FM-Prozesse ein breites Spektrum an Kenntnissen in deren Mittelpunkt eine ausgeprägte soziale Führungs-kompetenz steht. Diese Fähigkeiten müssen auf einem soliden Wissen in den Berei-chen der Anlagenplanung und des Anlagenbetriebes sowie der Prozessorganisation aufbauen. Zur Durchführung dieser Aufgaben und zur Erfüllung der Anforderungen ist das Beherrschen moderner Managementwerkzeuge sowie der sichere Umgang mit Recht, insbesondere bei der Gestaltung der Liefer- und Leistungsbeziehungen zwischen den Akteuren der Anlagenwirtschaft, erforderlich.
10.01.02 3
3 Major Players - Gruppe der Hauptbeteiligten
Wie geht es aber nun mit dem FM- Markt weiter? In einer vielbeachteten Studie von Helbling MC „ Facility Management in Deutschland – Marktstruktur 2000“ wird der Markt als relativ stabil bei ca. 100 Mrd. DM/a gesehen. Über diese Zahl mag man sich streiten können, richtig ist aber die Grundaussage, dass es sich nicht um einen boomenden Markt handelt und dass sich die Entwicklung vor allem in veränderter Marktstruktur vollzieht, hin zu einer sich immer mehr verstär-kenden Nachfrage nach komplexer, integrierter FM-Leistung. Bild 3: Tendenzen der FM-Marktentwicklung Absehbar ist weiterhin, dass die Zahl der Anbieter sinken wird. Zum einen verstärkt sich noch der Fusionstrend zu immer größeren Organisationen, zum anderen werden immer nachhaltiger die KMU organisiert in Netzwerken (Virtuellen Unternehmen) ihre Chance suchen. Welche weiteren Trends sind erkennbar? 1. Die rasante Entwicklung der IT-Technologien befördert die kostengünstige Erar-beitung der Grundlagen für den FM-Prozess, die in erster Linie in der kompro-misslosen Datenintegration der Facility-Objektbeschreibung (Bild 4) und dem Aufbau von FM- Informationssystemen (in der Regel als Kombination von Daten-bank und CAD-Grafik) bestehen. Erst mit. der "Dokumentation der Wahrheit" über die Facilities lassen sich we-sentliche Einsparpotentiale im Anlagenbetrieb erschließen. Gleichzeitig wächst die Tendenz zum Fernmanagement bei Organisationen mit geografisch verteilten Liegenschaften und Objekten. Datenbestände der Facilities großer Organisatio-nen werden zentral verwaltet, in der Zentrale die aktuellen Zustände der Facili-ties überwacht und Handlungsstrategien durch die FM-Führungsorganisation entwickelt. 10.01.02 4
01.02 5
Bild 4: Integrierte Datenbasis im FM 2. Es wächst die Erkenntnis, dass z.B. bei Neubauplanung, Umplanung und Rekon-struktionen dann ein hoher FM-Nutzen generiert werden kann, wenn der Facility Manager von Anfang an in den Planungs- und Realisierungsprozess einbezogen wurde (Bild 5) und dieser die internen Prozessstrukturen des Betreibers der neu-en Facilities aber auch die Nutzerwünsche in die Planung einbringen konnte. Damit werden sich letztlich mit der Hinwendung zum FM neue Berufsbilder bei Architekten, Projektmanagern, beratenden Ingenieuren u.a. ergeben. Die den Planungsprozess begleitenden Facility Manager werden mit solchen Leistungen wie nutzungsorientierte Wirtschaftlichkeitsberechnungen, Bewertung der Pla-nungsergebnisse hinsichtlich späterer Nutzungskosten und deren Reduktion, Si-mulation von Nutzungsszenarien an virtuellen Facilities (Gebäude, Anlagen,...), Erarbeitung von Betreiberkonzepten sowie von Objektdokumentationssystemen usw. wesentlich zur Steigerung der Effektivität der Planungsergebnisse beitragen. Nach dem Selbstverständnis der Verbände zeichnet der Facility Manager verant-wortlich für die Entwicklung und Pflege der integrierten Datenbasis der Facilities, welche eine wichtige Grundlage für die bedarfsgerechte Erfüllung der FM-Leitungsvorgaben darstellt. Er setzt somit die primär objektbezogenen Daten in ein prozessorientiertes Managementinformationssystem um. 3. Erfolg als Facility Manager zu haben bedeutete zwangsläufig die Realisierung einer solchen Dienstleisstungskultur, die sich komptomisslos an den Kundenbe-dürfnissen und am Kundennutzen orientiert. Kostensenkung und gelebtes Qualitäts- und Umweltmanagement sind Leistungs-prämissen der FM-Organisation. Dies bedeutet gleichzeitig die Bewältigung viel-fältiger sozialer und technischer Herausforderungen durch die Führungskräfte im FM. Dazu zählt auch die Beherrschung der Outsourcing- Prozesse einschl. der damit verbundenen arbeitsrechtlichen Problemstellungen. 10.
Bild 5: FM im Planungsprozess Es darf nicht übersehen werden, dass mit der Einführung von FM in Unterneh-men eine durchgreifende Rationalisierung der Organisation in der Bewirtschaf-tung und Verwaltung von Liegenschaften, Gebäuden und Anlagen erfolgt, die vielfach mit einem erheblichen Personalabbau verbunden ist. Gleichzeitig steigen die Qualifikationsanforderungen an die Beschäftigten bei der FM-Leistungser-bringung. Die FM-Organisation muss den Technologiesprüngen der Informati-ons-, Kommunikations- und Automatisierungstechnik sowie den sich verändern-den Anspruchshaltungen der Kunden und damit den notwendigen Anpassungen der Facilities folgen können. Damit verbunden ist das Bewusstsein, dass es um eine ständige Neubewertung und Weiterentwicklung der objektspezifischen Wertschöpfungsketten im Facility Management geht. 6
den
4. Der wachsende Automatisierungsgrad der Gebäude und Anlagen bis hin zur "künstlichen Intelligenz" verlangt nach Servicekonzepten, die dem Nutzer hilft, die den Facilities innewohnenden baulichen und technischen Möglichkeiten zu erschließen. Kundenbedürfnisorientierter IT-Immobilienservice entwickelt sich zum Standardangebot im Bereich des FM. Online-Servicedienste erschließen Nutzern einen neuen Komfort, der wiederum bei diesen einen Produktivitätsschub generiert. 10.01.02
Bild 6: Prozessketten der Wertschöpfung im Facility Management, hier Leistungsbereich Gebäudemanagement 5. Anbieter von integrierten FM-Leistungen werden in Zukunft den Markt dominie-ren. Integriertes FM steht für eine komplexe Angebots- bzw. Leistungsform, bei der ganzheitlich über den Lebenszyklus der Facilities hinweg FM in die jeweiligen Planungs- und Nutzungsprozesse integriert ist. Integriertes FM fokussiert die Inte-ressen der Eigentümer, Nutzer und Betreiber auf die Maximierung des Nutzens aus den Facilities und gewährleistet die Optimierung der Aufbau- und Ablaufor-ganisation in den FM-Leistungsprozessen. Das bedeutet gleichzeitig die am kon-kreten Objekt orientierte Wahl und Optimierung der Wertschöpfungskette (Bild 6). Große Unternehmungen, insbesondere solche in Konzernstrukturen, werden ihre verteilten FM-Leistungskom-petenzen weiterentwickeln bzw. ergänzen und je-weils aufgabenbezogen beim Kunden in vernetzten Strukturen zusammenführen. Die Anforderungen an die Mobilität und Flexibilität der Führungskräfte steigen sprunghaft. Diese Organisationen werden den Wettbewerb dominieren. Im über-geordneten Interesse der Gesamtunternehmung werden besonders im FM-Servicebereich auch zeitweise negative Ergebnisbeiträge hingenommen. Der Preisdruck am Markt nimmt drastisch zu. 10.01.02 7
Auch wenn heute kleinere Unternehmen mit Leistungszukauf komplexe Leis-tungsangebote unterbreiten, so besitzen die sogenannten KMU längerfristig nur dann eine Marktchance, wenn es ihnen gelingt, sich zu kunden- bzw. auftragsori-entierten virtuellen Netzwerken zusammenzuschließen, mit denen integrierendes FM abgesichert werden kann. Mit dem gezielten Einsatz der Kernkompetenzen der Netzwerkteilnehmer gelingt es ihnen, flexibel und effizient die Kundenbedürf-nisse zu befriedigen. Die Kreativität der beteiligten Unternehmen, ihr natürliches Streben dem Kunden "Zusatznutzen" anzubieten, ist auf Dauer gesehen ein deut-licher Wettbewerbsvorteil mit dem sich auch am Markt ein entsprechender Preis durchsetzen lässt. 6. Die beschriebenen Entwicklungstendenzen sind unmittelbar und aus vielfachen Ursachen heraus mit steigenden Qualitätsanforderungen an die FM-Prozesse und die Dienstleister verbunden. Gleichzeitig bewirkt FM in den Unternehmungen mit seinen Schnittstellen zu den am Kerngeschäft orientierten Qualitäts- und Umweltmanagementsystemen eine spürbare Unterstützung der damit verbundenen wirtschaftlichen Zielstellungen. Bleibt zusammenfassend festzustellen, dass die eigentliche Entwicklung im Facility Management, hin zu einer die Performance der Gebäude und Anlagen sowie das Nutzerbusiness nachhaltig positiv beeinflussende Dienstleistungsfunktion erst be-gonnen hat. Für den am Kundennutzen orientierten Dienstleister lohnt sich der Ein-stieg allemal.
Quellen: [1] Bleicher, K., Das Konzept Integriertes Management. Frankfurt/New York 1992 [2] Frutig, D., Reiblich, D., Facility Management: Objekte erfolgreich verwalten und bewirtschaften Zürich 1995 Autor: Prof. Dr.-Ing. Dietrich Reiblich Technische Fachhochschule Wildau Fachbereich Ingenieur-/Wirtschaftsingenieurwesen FMK Ges. für Facility Management und Kommunikationsversorgung mbH
http://www.4managers.de/01-Themen/..%5C10-Inhalte%5Casp%5CFacilityManagement.asp?hm=1&um=F
|
28 Feb 2005
20:42:13 |
Traugott Heinz |
Facility Management Netzwerke Rechennetze Anwendung Pottenzial Lifecycle Publikationen Literatur Studien
Guten Tag,
im Anhang eine Diplomarbeit, als Ergänzung zum oben genannten.
Viel Erfolg
Gruss M.Lardan
Auszug aus: http://www.walther-it.de/projects/diplom/diplom_final.html#Lit_PlattNM
Ingenieurbüro Prof. Dr.-Ing. H. Löffler
Rechnernetze, Telekommunikation, Facility-Management
Wechselbeziehungen zwischen Netzwerk-
und Facility-Management
Diplomarbeit
an der
Technischen Universität Dresden
Fakultät Informatik
von
Thomas Walther
Verantwortliche Hochschullehrerin:
Frau Doz. Dr.-Ing. habil. Barbara Hackler
Betrieblicher Betreuer:
Herr Prof. Dr.-Ing. habil. Helmut Löffler
Eingereicht am:
20. Januar 1997
Aufgabenstellung
Deklaration
Hiermit erkläre ich, daß ich die vorliegende Diplomarbeit selbständig und ausschließlich mit den angegebenen Hilfsmitteln angefertigt habe. Die von mir aus anderen Quellen unmittelbar oder mittelbar entnommenen Gedanken wurden entsprechend gekennzeichnet und sind durch klare Verweise zu Autor, Arbeit und Seiten ersichtlich.
Dresden, den 20. Januar 1997
Thomas Walther
Danksagungen
An dieser Stelle möchte ich die Möglichkeit nutzen, mich für die ausgiebig erhaltene Unterstützung bei der Erstellung dieser Diplomarbeit zu bedanken.
Den dabei größten Dank verdient mein betrieblicher Betreuer, Prof. Dr.-Ing. Helmut Löffler, der mich in die Netz- und Facility-Management-Thematik einführte und mir die größtmögliche Unterstützung während der gesamten Zeit der Erstellung der Diplomarbeit gab. Ohne seinen fachlichen Rat und seine Hilfe wäre die Entwicklung der Bestandteile des Projekts und die Diplomarbeit selbst nicht möglich gewesen. Ebenso möchte ich mich bei dem ganzen Team des Ingenieurbüros bedanken, von dem mir gleichermaßen große Unterstützung zuteil wurde.
Ein speziellen Dank verdient auch meine Betreuerin an der Technischen Universität, Frau Doz. Dr.-Ing. Barbara Hackler, die mir mit zahlreichen Diskussionen zu speziellen Problemen der Diplomarbeit zur Seite stand.
Ganz herzlich möchte ich mich bei der Firma Grafcom, im Speziellen Herrn Grisl, bedanken, der mir die Entwicklungsumgebung zur Realisierung von Anwendungen für die Plattform Mountain-Top zur Verfügung stellte, ohne die die Integration der Anwendungsmodule in die Plattform nicht möglich gewesen wäre.
Einen besonderen Dank verdient auch die Abteilung IuK des Landtags von Sachsen-Anhalt, die mir die Möglichkeit gab, das Netzwerkmanagement einer großen Verwaltung unter der Plattform OpenView zu analysieren. Dabei möchte ich mich speziell bei meinem Vater, Dipl.-Ing. Manfred Walther bedanken, der mir die dazu notwendige Unterstützung gab.
Ganz besonders möchte ich mich bei meiner Freundin, Dana Frohwieser, bedanken, die während der Erstellung der Diplomarbeit in mein Leben platzte und mir zugleich die größtmögliche Hilfe gab; die aber auch für die von Zeit zu Zeit notwendige Ablenkung sorgte.
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 Disk
|
29 Aug 2007
14:00:16 |
Lardan |
Auf diesen Beitrag anworten
|
|
|
|
