Unangenehme Erfahrungen zum Netzwerk-Management

Kommentieren Drucken
Teil 69 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Die praktische Erfahrung mit Netzwerk-Management-Projekten zeigt leider eine Menge unangenehmer Erfahrungen, die wir im Folgenden formulieren und jeweils kurz begründen. Die Lage in den Unternehmen und Organisationen ist in dieser Hinsicht sehr unterschiedlich. Festzuhalten ist jedoch, dass die angesprochenen, meist organisatorischen, Probleme unbedingt gelöst werden müssen, bevor man über die Einführung neuer Technologien, wie Virtualisierung, nachdenkt.

Für den Anfang gibt es sechs fundamentale Problembereiche die auftreten, sobald man die Theorie verlässt:

  • Organisationsproblem,
  • Datenerfassungsproblem,
  • Isolationsproblem,
  • Datendarstellungsproblem,
  • Kostenproblem,
  • Integrationsproblem.

Dazu treten natürlich noch mehr eher theoretisch begründbare Problembereiche, die aber in dieser Reihe eine nur untergeordnete Rolle spielen sollen.

Organisationsproblem

Netzwerk-Management ist eine organisatorische Problemstellung, die mit technischen Mitteln lediglich unterstützt wird.

Bevor man auch nur einen müden Euro für Management-Instrumente ausgibt, sollte klar sein, was das Ziel der Informationsverarbeitung im Unternehmen ist, wie der Betriebsablauf und die Organisation desselben aussieht und was das im Einzelnen bedeutet. Dies ist richtige Arbeit und kann den Verantwortlichen nicht abgenommen werden. Externe Berater können zwar strukturierte Anregungen geben, indem sie z. B. Problembereiche identifizieren und zeigen, dass im Rahmen der bisherigen Organisation viele Dinge von mehreren Gruppen gleichzeitig getan werden, was zu unnützem Abstimmungsaufwand führt, andere Dinge aber einfach liegenbleiben, weil niemand hierfür zuständig ist. Es ist aber immer eine Sache der individuellen Verhandlungen in einer Organisation, zu einem Ergebnis zu kommen. Teilweise führen gleichartige Problemstellungen z. B. bei verschiedenen Werken ein und desselben Industriebetriebes zu völlig unterschiedlichen Lösungen in Abhängigkeit von der früheren Kompetenzverteilung. Das Schlimmste ist eine Reißbrettlösung, die anschließend niemand akzeptiert. Erst nach einem abgeschlossenen Organisationskonzept kann man ein Lastenheft z. B. für eine Netzwerk-Management-Plattform erstellen und ein entsprechendes System beschaffen. Stellt man sich die Plattform einfach hin, wird man nie zu einem befriedigenden Ergebnis kommen. Letztlich ist ein unternehmensübergreifendes Betriebskonzept zu fordern, weil sonst die Gefahr besteht, dass vor lauter Kompetenzrangeleien nichts Sinnvolles mehr entsteht. Führende Beratungsfirmen, wie z. B. ComConsult Kommunikationstechnik Aachen, gehen im Rahmen eines vierstufigen Modells vor:

  • Organisationsmodell,
  • Datenmodell,
  • Toolmodell,
  • Integrations-Lösung.

Das Organisationsmodell beschreibt die Zuständigkeiten der einzelnen Funktionserbringer im Rahmen des Gesamtprozesses, das Datenmodell legt die Struktur der Daten fest und welche NM-Anwendungen in welcher Weise auf welche Daten zugreifen. Das Toolmodell beschreibt die NM-Hilfsmittel wie Plattformen und deren Zusammenwirken. Und die Integrationslösung zielt darauf ab, die verschiedenen Tools unter einer einheitlichen Benutzungsoberfläche zusammenzufassen. Sie können jetzt glauben, dies alles sei nur etwas für Großunternehmen. Aber selbst wenn nur ein kleines Netz mit lediglich einem Administrator vorliegt, kann es nur nützen, sich an dieser generellen Vorgehensweise zu orientieren.

Datenerfassungsproblem

Netzwerk-Management bedeutet die zeitintensive und mühsame Erfassung vieler einzelner Daten sowie die noch mühsamere Festlegung von Relationen zwischen diesen Daten.

Ein Netzwerk besteht aus einer großen Menge physischer und logischer Einzelteile von Kabel und Steckern bis zu Benutzern und Netzwerkbetriebssystemen. Des Weiteren bestehen zwischen all diesen Komponenten Beziehungen unterschiedlicher Natur. Heute blendet man im Grunde genommen die meisten dieser Komponenten und Beziehungen aus. Man betrachtet z. B. nur einen Server, seine logischen Betriebsmittel und die Benutzer und verwaltet diese. Oder man betrachtet nur das physikalische Netzwerk und wie die Pakete darin herum sausen. Das kann man sich leisten, solange man keine Anforderungen an die Betriebssicherheit und kurze Fehlersuchzyklen stellt. Insgesamt führt diese Vorgehensweise zu Brüchen zwischen den Management-Teilsystemen, die ein systematisches Vorgehen behindern. Gefragt ist hier eine Gesamtintegration.

Isolationsproblem

Die heute angebotenen sogenannten integrierenden Multivendor-Management-Plattformen decken jeweils nur einen kleinen Teil des Netzwerk- und System- Produktspektrums ab. Die meisten haben noch nicht einmal eine vernünftige Datenbank. Jede Plattform hat natürlich eine eigene Schnittstelle (API) für Management-Anwendungen Dritter.

Das führt dazu, dass Sie heute in vielen Fällen gar keine Chance haben, die notwendigen Daten und ihre Relationen ordentlich zusammenzuführen; dies wird umso deutlicher, je heterogener die zu verwaltende Umgebung ist. Außerdem hindert die API-Situation Sie heute daran, schöne Management- Anwendungen freizügig über verschiedene Plattformen hinweg einzusetzen. Anbieter von Management-Anwendungen müssen hingegen darauf achten, daß sie Anwendungen für Plattformen schreiben, die es morgen noch auf dem Markt gibt. Und dies hängt nicht von der Größe eines Anbieters ab. So hat z. B. Digital Equipment seine Plattform DECmcc einfach vom Markt genommen, weil das angestrebte Ziel für den Marktanteil nicht erreicht wurde. Außerdem kann man zeigen, dass für eine universelle Anwendbarkeit von Management-Anwendungen über Plattformen hinweg eine Objektorientierung für die Management-Daten notwendig ist. Erst dann könnte man in Rahmen objektorientierter Datenbanken wirklich sauber und freizügig arbeiten.

Datendarstellungsproblem

Die notwendige Objektorientierung ist heute immer noch Utopie. Dies bedeutet, dass mühsam geschaffene Datenbestände und Relationen mit hoher Wahrscheinlichkeit gegebenenfalls mehrfach neu formuliert und erfasst werden müssen.

»Erfahrene« Netzwerk-Manager haben dies heute schon mehrfach hinter sich. In größeren Netzen greifen viele verschiedene Betreuer/Planer/Betreiber auf dieselben Informationen zu. Auf Dauer kann dies nur gutgehen, wenn das Datenmodell hinreichend strukturiert ist und ein Mehrplatz-Zugriff auf die Datenbank besteht. Der Umfang von Zugriff und Veränderung ist von jedem Arbeitsplatz aus unterschiedlich. Viele Informationen wird man selbst in die Datenbank bringen müssen, denn die typischen Netzwerk-Management-Tools liefern nur eine Teilmenge der benötigten Informationen, sind aber groß darin, Informationen zu verlangen, um überhaupt arbeiten zu können. Da die Datenerfassung ohnehin aufwendig ist, muss die doppelte Datenhaltung genauso unbedingt vermieden werden wie inkonsistente Informationen. Eine Integration aller Informationen ist unbedingt notwendig, damit »Netzwerk-Management« überhaupt ablaufen kann. Netzwerk-Management-Tools (also Plattformen und Anwendungen) selbst sind aber nicht geeignet, diese Voraussetzungen zu schaffen (Henne-Ei-Problem).

Kostenproblem

Die Realisierung eines Netzwerk- und DV-Betriebes erfordert eine Vielzahl von Arbeitsplätzen und ist damit teuer.

Es gibt mittlerweile viele mehr oder minder nütze Abschätzungen darüber, wie hoch der Gesamtaufwand für das NM ist und wie viele Administratoren man für die Versorgung wie vieler Arbeitsplätze benötigt. Insgesamt hängen die Gesamtkosten von vielen Faktoren ab. Bei der Bewertung von Tools muss man berücksichtigen, wie hoch ein gegebenenfalls vorhandener Einarbeitungsaufwand ist, welches Niveau ich vom Mitarbeiter verlangen muss usf. Insgesamt ist aber die Betriebsorganisation an sich der wichtigste Faktor.

Integrationsproblem

Die technisch orientierten Einzelansätze führen auch heute noch zu lückenhaftem, dezentralem, nicht integriertem Management mit aufwendigen, ungeordneten Betriebs-Strukturen. Hier kann nur weitest gehende Integration helfen.

Wir haben uns schon daran gewöhnt, für jeden Netzwerk-Server ein Verzeichnis aller seiner Benutzer anzulegen, mit der Konsequenz, dass es Benutzer, die auf mehreren Servern arbeiten möchten, auch mehrfach geben muss, wir streuen Analysetools übers Netz, die irgendwo zufällig Pakete absuchen und zufällige Meldungen erzeugen, wir steuern einen Switch mit seinem eigenen Management-System, welches eine andere Konsole benötigt wie die Steuerung der Brücken oder Netzwerk-Server, wir schreiben dem Repairman Zettel, wo er reparieren kann, und dokumentieren das physikalische Netz zum einen mit Fähnchen, die wir an die Kabel hängen und zum anderen mit einer Topologie-Erfassung auf einer teuren Netz-Management-Plattform, die noch nichts anderes kann. Die dabei entstehenden Unterschiede sind eben durch den Fortschritt der Technik bedingt. Nach den Kosten pro Benutzer gefragt, schlagen wir eine Kladde auf und rechnen die letzten Positionen zusammen, bevor wir sie durch die Anzahl der Benutzer teilen. Man könnte das Ergebnis in vielen Fällen mit höherer Präzision auslosen!

Wenn Sie, lieber Leser, sich nicht teilweise in den obigen Darstellungen wiederfinden, machen Sie entweder kein Netzwerk-Management oder gehören zu den wenigen Auserwählten, bei denen das Netz und die Benutzer und die Anwendungen und die Systeme so stromlinienförmig homogen sind, dass diese üblichen Probleme nicht auftauchen.

« Teil 68: Wandel der Bedarfsentwicklung im Netzwerk-ManagementTeil 70: Unangenehme Erfahrungen zum Netzwerk-Management »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.