Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.10.1990 - 

DEC: EMA-Architektur zielt primär auf heterogene Konfigurationen

Offene Systeme fordern das Netz-Management heraus

Die unterschiedliche Komplexität der Netze stellt immer höhere Anforderungen an das Netzwerk-Management. Deshalb beginnen alle namhaften Hersteller mit Ausnahme der IBM ihre Netz-Management-Systeme auf die zunehmende Nachfrage nach heterogenen Netz-Lösungen abzustimmen. Der fünfte Beitrag einer Serie von Franz-Joachim Kauffels* beleuchtet die Struktur der Enterprise Management Architecture (EMA) von Digital Equipment (DEC).

Nachdem die letzte Folge das Netz-Management-Konzept von AT&T beleuchtete, wird dieser Artikel die EMA-Struktur von DEC behandeln. Abschließend wird dann in der kommenden Woche analysiert werden, wie Hewlett-Packard mit Open View OSI-Standards abdeckt.

Die Konzepte der drei Unternehmen AT&T, DEC und Hewlett-Packard sind im Gegensatz zu IBM nicht auf eine herstellerabhängige Kommunikations-Infrastruktur ausgerichtet. Sie migrieren ihre hauseigenen Management-Systeme in einem längerfristigen Prozeß in Richtung OSI. Dabei gehen sie von der Vorstellung aus, daß sowohl herstellerspezifische wie auch OSl- Lösungen mindestens für das nächste Jahrzehnt koexistieren werden. Deshalb gestalten sie ihr Netzwerk-Management so, daß die unterschiedlichen Systemwelten von einer gemeinschaftlichen Oberfläche aussteuerbar sind, wenn schon die vollständige Integration nicht erreichbar ist.

Die Enterprise Management Architecture (EMA) ist Digitals strategischer Plan für ein integriertes Netzwerk-, System- und Anwendungs-Management. Schon in Decnet Phase IV waren die Begriffe System, Netz und Anwendung enger verwoben als zum Beispiel bei IBM. Dies hat vor allem die Ursache darin, daß Decnet primär für die Kooperation zwischen DEC-Rechnern und erst sekundär zur Einheitensteuerung gedacht war, also eine ganz andere Entwicklung als SNA hinter sich hat. Daher ist auch zu verstehen, daß Decnet und Digitals Netzwerk-Architektur DNA besser zu OSI passen, denn auch hier steht primär die Kommunikation zwischen heterogenen Systemen auf der Basis anwendungsorientierter Grunddienste im Vordergrund.

EMA enthält das OSI-Management Standardprotokoll CMIP (Common Management Information Protocol) für den Informationsaustausch zwischen Netz-Management-Arbeitseinheiten, um die Kommunikation zwischen EMA-Komponenten und Fremdkomponenten zu erleichtern.

Die Architektur von DEC ist dezentral organisiert. Die Basiselemente können auf verschiedenen Rechnern implementiert werden, wobei vielfach auch ein einziges Grundelement auf mehreren Systemen verteilt werden kann. EMA basiert auf einem Modell mit Arbeitseinheiten (Entities), die von Direktoren (Directors) gemanagt werden. Die Direktoren haben die gleiche Rolle wie Netview, sind jedoch völlig anders implementiert.

Eine Arbeitseinheit besteht aus zwei Teilen: dem Ziel-Objekt (Managed Object) wie zum Beispiel einem Modem oder dem Kommunikationsweg und seinem Agenten (Agent) sowie der Management-Software für das zu verwaltende Objekt. Der Agent kann einen gewissen Grad von lokalen Management-Fähigkeiten besitzen. Primär ist er jedoch ausführendes Organ für Management-Operationen. Diese untergliedern sich in Ereignisse und Direktiven (Events and Directives). Nach den Richtlinien von EMA brauchen Agent und Ziel-Objekt nicht auf dem gleichen System implementiert zu sein. So kann der Agent über einen fast beliebigen Kommunikationsweg und ein entsprechendes Protokoll mit seinem Ziel-Objekt kommunizieren. Wichtig ist nur, daß der Direktor, dem der Agent nachgeordnet ist, die entsprechenden Informationen auch erhält.

Der Direktor ist ein Software-System, welches als Interface zwischen Benutzer und den gemanagten Einheiten und Systemen (Arbeitseinheiten) lokalisiert ist. Der Direktor besteht aus fünf Komponenten: der Exekutive (Executive), der "Management Informations-Fundgrube" MIR (Management Information Repository) und folgenden drei Arten von Management-Modulen:

- Darstellungs-Module (Presentation Modules)

- Funktions-Module (Function Modules)

- Zugriffs-Module (Access Modules).

Remote Procedure Call birgt Risiko des Zugriffs

Während sich eine Arbeitseinheit mehr auf ein konkretes Betriebsmittel vom Modem bis zum Decnet-Knoten bezieht, ist ein Direktor ein mehr logisches Konzept. Es beruht auf einer Menge von Software-Komponenten, die in einem physischen Knoten implementiert werden können.

Die Exekutive, der Kern von EMA, ist ein Hauptkontrollprogramm von DEC mit verschiedenen Standard-Interfaces als Unterstützungs-Routinen zur Koordination der Arbeit der Management-Module. Diese Unterstützungs-Routinen sind durch einen Remote Procedure Call realisiert, - eine Eigenschaft, die relativ kritisch ist, da EMA vielen verteilten Direktoren erlaubt, gleichberechtigt (peer-to-peer) zu kommunizieren. Ein Direktor kann Informationen von einem Zugriffsmodul eines anderen Direktors holen oder Funktionen eines Funktionsmoduls eines anderen Direktors benutzen. Ein Direktor kann demnach Objekte benutzen, die auf entfernten Stellen implementiert sind.

Der Kommunikations-Support der Exekutive für die Intermodul-Kommunikation ist daher ein wesentliches, häufig benutztes Instrument für die Realisierung der gewünschten Flexibilität des EMA-Designs. Zur Unterstützung der Intermodul Kommunikation benutzt die Exekutive einen Verteilmechanismus. Er bestimmt die Zielprozedur, übergibt die Kontrolle an die Zielprozedur, und leitet die Antwort an die Quellprozedur zurück. Die Exekutive erzeugt und pflegt Informationen in der "Management-Informations-Fundgrube" MIR.

Die Management-Module sind die Erweiterungseinheiten eines Direktors. Diese Einheiten sollen ohne spezifisches, vorher definiertes Wissen voneinander zusammenarbeiten können. Die Exekutive kontrolliert die Intermodul-Kommunikation.

Darstellungs-Module sind das Benutzer-Interface für EMA-Direktoren. Ein Darstellungs-Modul kann so geschrieben werden, daß es einen bestimmten Konsolentyp, eine bestimmte Anwendung oder auch die Kommunikation mit Nicht-EMA-Komponenten unterstützt. Ein Direktor kann mehrere Darstellungs-Module besitzen. Der Vorteil dieser Konstruktion liegt vor allem darin, daß die Unterstützung von äußeren Einheiten und Objekten unabhängig von den verwalteten Arbeitseinheiten ist. Dies dynamisiert zum Beispiel auch die Möglichkeiten der Benutzeranpassung oder Weiterverarbeitung der Management-Informationen. Die Funktions- Module decken die fünf funktionalen Bereiche Konfigurations-, Fehler-, Leistungs-, Abrechnungs- und Sicherheits-Management ab, die von OSI-Management-Standards vorgeschrieben werden. EMA erlaubt einem Modul jedoch, mehr als eine Funktion auszuführen. Das ist strenggenommen bei OSI-MGMT nicht vorgesehen; - verständlicherweise, weil sich die OSI-Gremien in der Vergangenheit sehr schwer getan haben, deutliche Trennlinien zwischen den funktionalen Bereichen zu ziehen.

Zugriffs-Module kommunizieren unmittelbar mit typischen Übertragungs-Komponenten wie Nebenstellenanlagen, Multiplexern, Modems, LAN-Bridges und logischen Komponenten im Netz, wie Systeme und Anwendungen. Dazu benutzen sie spezifische Protokolle und erlauben gleichzeitig dem Direktor, Protokoll-unabhängig zu bleiben. Zugriffs-Module sind funktional vergleichbar mit den Programmen, die Dritte schreiben müssen, um mit Netview/PC kommunizieren zu können.