Gebšudetechnik

deutsch english francais italinao

 Suche

 Startseite
 Organisation
 Know How
 Online Forum
 Links

 Anmeldung

 Passwort vergessen?

Partner Login

Partner ID
 
 Passwort
 ‹ber fmswiss.ch
 FAQ & Hilfe Tool
 Ziele
 Bedingungen
 eMail

  Online Forum
Startseite | Online Hilfe 
Ihr Status : Gast
Version : 1.5
 
   Suche :  
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
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.