DE69533733T2

DE69533733T2 - Netzwerkverwaltungsverfahren

Info

Publication number: DE69533733T2
Application number: DE69533733T
Authority: DE
Inventors: Brendan Fee; Kurt Dobbins; David Arneson; Pat Mullaney
Original assignee: Cabletron Systems Inc
Current assignee: Cabletron Systems Inc
Priority date: 1994-01-28
Filing date: 1995-01-26
Publication date: 2005-10-27
Anticipated expiration: 2015-01-27
Also published as: JPH09508727A; WO1995020852A1; DE69533733D1; EP0741938A1; US6415314B1; AU2399299A; AU701748B2; DE69518066T2; US5522042A; US6618762B2; ATE194898T1; US20020133583A1; EP1014621B1; DE69518066D1; EP1014621A3; EP1014621A2; US5812771A; AU1695195A; EP0741938B1; AU717656B2

Description

Diese Erfindung bezieht sich auf ein Verfahren und ein System zum Netzwerk-Managen und insbesondere auf ein Verfahren und System zum Netzwerk-Managen durch Bereitstellen einer Vielzahl von Netzmodulen bzw. Netzwerkmodulen, wenn in einem System Managementfunktionen zwischen unterschiedlichen Modulen in einem Netzwerkgehäuse bzw. Netzwerkgestell zugeteilt werden.
US-A-5 226 120 offenbart eine Vorrichtung zum Überwachen und Anzeigen eines Status eines lokalen Bereichsnetzwerks (LAN) mit einem Hub mit Anschlüssen zum Verbinden an eine Datenendgeräteinrichtung und an andere Hubs. Die Hubs weisen jeweils verschiedene Arten von Plug-In-Modulen mit verschiedenen Anschlüssen zum Verbinden mit verschiedenen Arten von Netzwerkkabeln auf. Informationen werden einer Steuerkonsole automatisch bereitgestellt, die die Arten von Modulen und den Ort in dem Hub kennzeichnen.
EP-A-0384339 offenbart zum Bereitstellen in einem Computernetzwerk einen Broker- bzw. Vermittlermechanismus, der eine Vielzahl von Servern einer Vielzahl von Klienten (Clients) zuteilt. Der Broker arbeitet durch Überwachen einer Teilmenge von allen vorhandenen Servern, die zum Liefern eines angeforderten Diensten in der Lage sind. Er empfängt Anforderungen von einem Klient für die Dienste und schlägt einen der Server für einen der eine Anforderung machenden Clients vor.
WO 92/19054 offenbart, eine Überwachung der Kommunikation auszuführen, die in einem Knotennetzwert auftritt, wobei eine Kommunikation durch eine Übertragung von einem oder mehrere Paketen zwischen zwei oder mehreren Kommunikationsknoten beeinflusst wird, wobei ein vordefiniertes Kommunikationsprotokoll, das unter in dem Netzwerk vorhandenen Protokollen ausgewählt wird, befolgt wird.
Im allgemeinen stellt ein Computernetzwerk-Managementsystem typischerweise eine oder mehrere der folgenden Funktionen zur Verfügung: Überwachen einer Aktivität auf dem Netzwerk, Erfassen von Fehlern, Erzeugen von Alarm und/oder Isolieren von Fehlern, Zuteilen von Netzwerkmitteln, Lenken bzw. Leiten eines Verkehrs und Bestimmen oder Rekonfigurieren der Netzwerktopologie. Mit dem Anwachsen der Komplexität von Computernetzwerken gibt es eine ansteigende Notwendigkeit für verbesserte Managementsysteme. Insbesondere gibt es Überlegungen über ein "Zusammenbrechen" des gesamten Systems oder des Teilsystems (d. h. ein Verlust an einer Netzwerkfunktion), das durch eine Fehlfunktion im Managementsystem, der Übertragung und der Verarbeitungsverzögerungen verursacht wird, und eine Reduktion in bezug auf Speicherplatz, die durch die Managementoperationen selbst verursacht wird, und die Unfähigkeit, das Netzwerk zu erweitern und/oder größere Ausgaben zum Ersetzen oder zum Erneuern des Managementsystems zur Anpassung an ein größeres Netzwerk.
Bei einem System nach dem Stand der Technik sind alle Managementfunktionen auf einem Modul ("dem Managementmodul") vorgesehen, das in das Netzwerkgehäuse eingesteckt wird. Ein "Netzwerkgehäuse" ist ein Gehäuse und eine Rückwand, die "Netzwerkkarten" aufnimmt, die verschiedene Netzwerkdienste durchführen, wie beispielsweise ein Wiederholen, eine Brückenbildung und ein Leiten. Jede Netzwerkkarte oder jedes Modul enthält ihren bzw. seinen eigenen Mikroprozessor. Bei diesem System nach dem Stand der Technik hat das "Managementmodul" die gesamte Hardware und Firmware, die zum Sammeln, Speichern und Verarbeiten aller Daten nötig sind, die zum Managen des Systems erforderlich sind. Dies erzeugt ein ernsthaftes Problem, wenn es eine Fehlfunktion im Managementmodul gibt und es herausgezogen werden muss, d. h. es gibt dann nichts mehr, was zum Managen des Systems zurückgelassen ist. Zum Schützen gegenüber dieser Katastrophe kann der Anwender ein Reservemodul kaufen, aber dies ist ein teures Verfahren für eine Sicherstellung. Ebenso erzeugt selbst während einer normalen Operation ein Konsolidieren aller Managementfunktionen in einem Modul einen potentiellen Engpass, wenn es ein steigendes Ausmaß an Übertragungen und/oder Verarbeitungen gibt. Weiterhin hat das Managementmodul eine definierte Kapazität, und es muss somit eine obere Grenze in bezug auf das Ausmaß einer zulässigen Netzwerkerweiterung geben (d. h. einer Erhöhung in bezug auf die Anzahl von Anschlussstellen und/oder den Verkehr). Aus diesem Grund muss der Käufer des Systems entscheiden, ob er ein größeres Managementsystem kauft, als es gegenwärtig nötig ist, das aber eine zukünftige Erweiterung unterbringen wird, oder ein adäquates System, das möglicherweise vollständig ersetzt werden muss, wenn es eine weitere Erweiterung gibt.
Bei einem anderen System nach dem Stand der Technik managt jedes Modul im Gehäuse seine eigenen Funktionen getrennt. In diesem Fall ist das Gehäuse lediglich ein "Gehäuse", das unabhängige Netzwerksysteme enthält. Zusätzlich zu den Komplexitäten eines getrennten Managements hat dieses Problem Probleme, die gleich dem System mit "einem Managementmodul" in bezug auf den Verlust an Netzwerkdienst sind, der jede Management-Fehlfunktion begleitet, in bezug auf einen potentiellen Engpass, wo jedes Modul sein eigenes Management durchführen muss, und in bezug auf eine begrenzte Erweiterungskapazität.
Es ist eine Aufgabe der vorliegenden Erfindung, einen neuen Typ von Netzwerkmanagementsystem zu schaffen, wobei das System "als Ganzes" gemanagt wird, aber die Managementfunktionen über das System "verteilt" sind.
Es ist eine Aufgabe, eine Vielzahl von Modulen in einem Netzwerkgehäuse zur Verfügung zu stellen, die die Managementfunktionen miteinander handhaben, und wobei eine Fehlfunktion in einem Modul die Funktionen der anderen Module und das Gesamtmanagement des Netzwerks nicht wesentlich beeinflussen wird.
Es ist eine weitere Aufgabe, ein System zu schaffen, das eine direkte Erweiterung des Netzwerks zulässt, ohne ein Ersetzen des Managementsystems zu benötigen.
Es ist eine weitere Aufgabe, ein System zu schaffen, das eine Modifikation der Managementfunktionen zulässt, ohne ein Ersetzen des gesamten Managementsystems zu benötigen.
Es ist eine weitere Aufgabe, ein Verfahren und ein System mit einer besseren Zuteilung von Betriebsmitteln für Managementfunktionen zu schaffen, um einen höheren Durchsatz zu erhalten.
Diese und andere Aufgaben der vorliegenden Erfindung werden durch das Verfahren nach Anspruch 1 bzw. durch das System nach Anspruch 4 erzielt.
Ein verteiltes Gehäusemittel bzw. Gehäuseagent ("DCA") für ein Netzwerk ist vorgesehen, das ermöglicht, dass das Gehäuse als einzelnes System gemanagt wird, und wobei jedes Modul die Managementfunktion durchführen kann oder sie durch mehrere Module gleichzeitig durchgeführt werden kann. Das System skaliert zu einer größer werdenden Modulkomplexität und Anzahl, wenn es seine Arbeitsbelastung über die Module ausbreitet, die innerhalb des Gehäuses enthalten sind, wodurch es sich gegenüber den meisten verwendeten Modulen unterscheidet. Unter Verwendung dieses Systems ist das Ausmaß einer Fehlertoleranz für das Management des Gehäuses gleich der Anzahl von Modulen, die innerhalb des Gehäuses enthalten sind, wenn jedes Modul dazu fähig sein kann, die Managementfunktion für das gesamte Gehäuse durchzuführen.
Die Managementfunktion kann beispielsweise unter Verwendung des SNMP-Protokolls durchgeführt werden, das ein Teil der TCP/IP-Protokoll-Programmfamilie ist. Auf das Managementsystem wird über eine Netzwerkadresse zugegriffen, die als die "Gehäuseadresse" bekannt ist. Die Managementfunktion kann auf einem oder mehreren Modulen innerhalb des Gehäuses laufengelassen werden, aber auf sie wird immer über dieselbe Geräteadresse zugegriffen.
Drei neue Funktionen des Gehäusemittels sind folgende: a) eine Entdeckungsfunktion, die durch jedes Modul durchgeführt wird, um Information, die für dieses Modul spezifisch ist, zu bestimmen, zu speichern und zu den anderen Modulen zu senden, und um auf die Nachrichten anderer Module zu hören und ähnliche Information in bezug auf die anderen Module zu speichern; b) eine Auswahlfunktion, die durch jedes Modul durchgeführt wird, um zu bestimmen, welches Modul (welche Module) eine spezifische Managementfunktion durchführen sollte(n); und (c) verteilte MIBS, wobei jedes Objekt im MIB einen Identifizierer (der als OID bekannt ist) hat, der sowohl lokal (d. h. auf dem Modul, auf dem er sitzt) als auch entfernt (auf allen anderen Modulen im Gehäuse) in einem Namensgebungsbaum (MIB) registriert ist, der an jedem Modul angeordnet ist, während die Daten für jedes Objekt nur in einem Modul gespeichert sind. Diese und andere neue Funktionen des Gehäusemittels werden nachfolgend ausführlicher beschrieben. Das Gehäusemittel kann in einer objektorientierten Software-Sprache, wie beispielsweise C++, implementiert sein.
Einer der Vorteile des neuen Systems besteht darin, daß es ohne Synchronisierung der Module arbeiten kann. Dies vermeidet die Probleme und Komplexitäten, die einem synchronisierten System eigen sind. Somit kann jedes Modul während einer Entdeckung und anderer Funktionen seinen eigenen Takt haben und auf asynchrone Weise rundsenden (nach einer spezifizierten Ankündigungsperiode von beispielsweise einer Sekunde). Jedes Modul wird kontinuierlich Information von den anderen Modulen empfangen und seine eigene Schlitztabelle von Modulinformationen einem Updaten unterziehen. Das System ist in einem kontinuierlichen Zustand einer "gesteuerten Instabilität", so dass das nötige Updaten der Datenbank und eine Zuteilung von Managementfunktionen innerhalb weniger Taktskalierungen durch jedes der Module erreicht werden.
Damit das Netzwerkgehäuse als einzelnes System funktioniert (d. h. angesichts des Netzwerks und seiner Anwender), müssen die Netzwerkmodule und andere Komponenten (z. B. die Leistungsversorgung) innerhalb des Gehäuses einander entdecken. Es ist für jedes Modul erforderlich, das Vorhandensein oder Nichtvorhandensein anderer Module und Komponenten innerhalb desselben Gehäuses und anderer Betriebsparameter jedes Moduls/jeder Komponente zu verfolgen. Eine Modulentdeckung ist ein kontinuierlicher Prozess, wobei jedes Modul auf einer zeitlichen Basis (in der Größenordnung von Sekunden) eine unverlangte Nachricht an der Rückwand des Gehäuses ausgibt. Die Nachricht enthält Grundinformation über das Modul, wie beispielsweise seine Schlitz-ID innerhalb des Gehäuses, interne Management- und externe Datenverbindungsadressen und den Status verschiedener Objekte am Modul. Jedes Modul verwendet diese Information zum Bilden seiner eigenen Schlitztabelle, die die Grundinformation über sich selbst und gleiche Information in bezug auf die anderen Module enthält. Diese Information wird durch ein Modul verwendet, um zu entdecken, in welchem Gehäuse es gegenwärtig eingebaut ist. Wenn das Modul einmal entdeckt und in die Schlitztabelle eingegeben ist, kann das Modul nach Information über seine Mittel abgefragt werden. Jedes Modul enthält seinen eigenen Prozessor (CPU), seinen eigenen Speicher und seine eigenen Schnittstellen. Die Information in der Schlitztabelle, die durch jedes Modul kompiliert ist, kann Information in bezug auf den Typ, die Geschwindigkeit und die Anwendung seiner CPU, den Typ, die Größe und die verbrauchte Menge von seinem Speicher und den Typ und die Geschwindigkeit seiner Schnittstellen enthalten. Die Information kann weiterhin Anwendungen an jenem Modul beschreiben, wie beispielsweise den Typ einer Anwendung (alleinstehend oder verteilt), und seinen Status (freigegeben, gesperrt, standby). Wie es hierin nachfolgend beschrieben wird, kann dann, wenn die Module einander einmal entdeckt haben, eine zusätzliche Entdeckung in bezug auf die gemanagten Objekte innerhalb der Datenbank des Gehäuses stattfinden, und eine Auswahl von Modulen wird durchgeführt, um jede spezifische Managementanwendung durchzuführen.
Beim Hochfahren des Systems oder nach einer Systemänderung (einem Modulausfall/einer Modulentfernung, etc.) ist ein Auswahlprozess erforderlich, um die beste Stelle (die besten Stellen) zum Laufenlassen einer Managementanwendung (von Managementanwendungen) zu entdecken. Die Entscheidung darüber, wo eine Anwendung (d. h. welches Modul) innerhalb des Gehäuses anzuordnen ist, kann auf dem folgenden basieren: verfügbare Betriebsmittel des Moduls, gegenwärtige Anwendungen, ein gegenwärtiges Profil (d. h. eine gegenwärtige Verarbeitungsbelastung), einem Modultyp und einer Schlitznummer. Jede Anwendung kann ihre eigene Gruppe von Befehlen zum Auswählen der besten Stelle haben, an welcher auszuführen ist. Die Auswahlbefehle werden durch jedes Modul unter Verwendung der Daten durchgeführt, die in seiner Schlitztabelle gefunden werden. Wenn jedes Modul denselben Überblick über das System hat, wird jeder Auswahlprozess zum selben Ergebnis kommen. Das ausgewählte Modul wird eine unverlangte Nachricht mit dem neuen Status seiner Anwendungsliste ausgeben.
In bezug auf verteilte MIBs wird bei einem Ausführungsbeispiel ein MIB-Baum an jedem Modul mit lokalen oder entfernten Adressen (in der Form von OIDs) für jedes gemanagte Objekt im System unterhalten, aber die Daten für jedes Objekt im MIB werden an nur dem lokalen Modul verteilt und gehalten (d. h. dem Modul, an welchem es sitzt). Dies spart Platz in bezug darauf, dass die Daten nicht an jedem Modul gespeichert werden. Jedoch kann jedes Modul durch Registrieren jedes Objekts sowohl lokal als auch entfernt eine Einzelne-Stelle-eines-Zugriffs für alle der Objekte im Managementsystem zur Verfügung stellen. Zwischenzeitlich ist das System fehlertolerant insoweit, dass die Daten für alle Objekte nicht an einem Modul gespeichert werden. Bei einem alternativen Ausführungsbeispiel ist der MIB-Baum an nur einem Modul vorgesehen, während die Daten verteilt bleiben. Dieses System ist in bezug auf die Daten fehlertolerant, aber stellt keine Einzelne-Stelle-eines-Zugriffs an jedem Modul zur Verfügung.
Ein Verfahren, durch welches das vorliegende Ausführungsbeispiel eine Fehlertoleranz erreicht, besteht darin, dass Fehler in den Modulen durch die anderen Module unter Verwendung einer Modulentdeckung erfasst werden. Eine Modulentdeckung lässt zu, dass die Module das Vorhandensein oder das Nichtvorhandensein von anderen Modulen im Gehäuse und ihren Status entdecken. Das System ist derart entworfen, dass es einen Vorteil aus der Modulentdeckungsinformation durch dynamisches Rekonfigurieren mit einem minimalen Verlust an Netzwerkdienst bzw. Netzwerkservice zieht, wenn ein Modul erfasst oder verloren wird.
Eine weitere Maßnahme einer Fehlertoleranz wird durch Vorsehen von zwei Rückwänden für intermodulare Managementkommunikationen erreicht. Die Modulentdeckungsnachrichten können an beiden Rückwänden ausgesendet werden, wobei eine Entscheidung durch das empfangende Modul gefällt wird, um eine Rückwand (z. B. die schnellste) für eine weitere Kommunikation mit jedem Modul auszuwählen, bis irgendein Fehler eine neue Auswahl nötig macht. Die Fähigkeit zum sofortigen Umschalten zur alternativen Rückwand verhindert einen Verlust an Netzwerkdiensten.
Diese und andere Funktionen und Vorteile der vorliegenden Erfindung werden detaillierter in der folgenden detaillierten Beschreibung beschrieben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 eine perspektivische Ansicht eines Netzwerkgehäuses gemäß der vorliegenden Erfindung ist;
2 eine logische Ansicht des Netzwerkgehäuses ist;
3 eine schematische Darstellung ist, die die Netzwerkmodule zeigt, die durch zwei Systemmanagementbusse (SMB1 und SBM10) verbunden sind;
4 eine schematische Darstellung einer Paketeinkapselung für eine Übertragung auf SMB10 ist;
5 eine schematische Darstellung einer intermodularen Entdeckung ist, die die Übertragung von Modulentdeckungsnachrichten auf den SMBs und die Bildung einer Schlitztabelle zeigt;
6 eine schematische Darstellung ist, die die lokale und entfernte Registrierung eines verteilten gemanagten Objekts an den Gehäusemodulen (Einheiten) zeigt;
7 eine schematische Darstellung ist, die allgemein die Wiedergewinnung eines gemanagten Objekts (MO) in Antwort auf Befehle zeigt, die an sowohl dem lokalen als auch dem entfernten Modul empfangen werden; und
8 eine schematische Darstellung gleich der 7 ist, die ein Verfahren zum Wiedergewinnen eines gemanagten Objekts spezifischer zeigt, das an einem lokalen oder einem entfernten Modul gehalten wird.
Wie es in 1 gezeigt ist, ist ein Netzwerkgehäuse 10 ein mechanisches Gehäuse 12, das zum Unterbringen von Netzwerkmodulen 14, wie beispielsweise Repeatermodulen, Brückenbildungsmodulen, Anschlussservern, Dateiservern, etc., verwendet wird. Das Gehäuse stellt Schlitze zur Verfügung, in welche Netzwerkmodule eingefügt werden. Jedes Modul besetzt einen oder mehrere Schlitze innerhalb des Gehäuses.
Das Gehäuse stellt zusätzlich dazu, daß es ein mechanisches Gehäuse ist, eine Rückwand 16 zur Verfügung, durch welche die in das Gehäuse eingefügten Module mit Leistung von der Leistungsversorgung 18 des Gehäuses versorgt werden. Die Rückwand wird auch zum Bereitstellen einer Netzwerk-Verbindungsfähigkeit zwischen Modulen verwendet.
Die Gehäuse-Leistungsversorgungen sind modulare Einheiten, die auch in das Gehäuse eingefügt sind, und zwar entweder an der Rückseite des Gehäuses oder an der Unterseite des Gehäuses. Das Netzwerkgehäuse unterstützt drei Typen von Leistungsversorgungen:

• Herkömmliche Leistungsversorgungen (Wechselstrom- bzw. Gleichstrom-Versorgungen)
• Nichtunterbrechbare Leistungsversorgungen (Wechselstrom-zu-Gleichstrom/Gleichstrom-Versorgungen)
• Batterieunterstützte Einheiten (Gleichstrom-Versorgungen)

Logischerweise kann ein herkömmliches Netzwerkgehäuse als eine Ansammlung von Netzwerkdienst-Providern angesehen werden, die über ein gemeinsames Netzwerk (oder Netzwerke) verbunden sind. Das gemeinsame Netzwerk (oder die Netzwerke) ist bzw. sind durch die Rückwand des Gehäuses vorgesehen. 2 ist eine logische Ansicht eines Netzwerkgehäuses, die ein Paar von Rückwänden 20, 22 mit Verbindungen zu drei Modulen 24, 26, 28 zeigt, und wobei jedes der Module eine Reihe von jeweiligen Vorderwand-Anschlussstellen 25, 27, 29 hat.
Netzwerkmodule basieren auf einem Mikroprozessor (CPUs 24A, 26A, 28A in 2) und sind allgemein mit zwei oder mehreren Netzwerk-Anschlussstellen aufgebaut; die Netzwerk-Anschlussstellen können an der Vorderwand des Moduls (Anschlussstellen 25, 27, 29) erscheinen, oder können Anschlussstellen sein, die eine Verbindung zur Gehäuserückwand haben (Anschlussstellen 19, 21, 23). Die Netzwerk-Anschlussstellen werden für zwei Zwecke verwendet, und zwar erstens zum Durchführen von Netzwerkdiensten, wie ein Wiederholen, eine Brückenbildung und ein Leiten, und zweitens zum Vorsehen eines Zugriffs auf den Mikroprozessor der Module für Managementzwecke. Module werden herkömmlich unter Verwendung des SNMP-Protokolls gemanagt, nämlich eines Protokolls, das ein Teil der TCP/IP-Protokoll-Programmfamilie ist. Es ist erforderlich, dass jedes Modul seine eigene Netzwerkadresse hat, die als IP-Adresse bekannt ist. Jedes Modul hat auch eine Datenverbindungsadresse, die als MAC-Adresse bekannt ist.
Das SNMP-Protokoll wurde durch die IETF (Internet Engineering Task Force = Sondereinheit für Technik und Ingenieurwesen im Internet) entwickelt und ist in der folgenden RFC (request for comments = Bitte um Kommentare) spezifiziert:

• RFC 1155 Struktur der Managementinformation
• RFC 1157 Einfaches Netzwerkmanagementprotokoll
• RFC 1212 Präzise MIB-Definitionen
• RFC 1213 Managementinformationsbasis II (MIB-II)

Das Gerät des Ausführungsbeispiels der vorliegenden Erfindung, das hierin nachfolgend "Verteiltes Gehäusemittel" (DCA) genannt wird, baut dieses Modell unter Verwendung des SNMP-Prozesses in jedem Modul auf, benötigt aber nur eine einzige IP- und MAC-Adresse für das gesamte Gehäuse. Ebenso lässt das DCA zu, daß MIBs über alle Module im Gehäuse verteilt sind und auf sie durch einen SNMP-Prozess jedes Moduls zugegriffen werden kann. Dies lässt zu, dass das Gehäuse eher als ein einziges System für Managementzwecke angesehen wird, als eine Ansammlung von Systemen. Dieses Gehäuse und alles, was es enthält, kann über ein einziges Mittel gemanagt werden, dessen Arbeitsbelastung über alle Module im Gehäuse verteilt ist. Der Aufbau des DCA ist in die folgenden Teile aufgeteilt:

1. Zwischenmodulkommunikationen
2. Entdeckung
3. Gehäuseauswahl
4. Gehäusemittelzugriff
5. MIB-Verteilung

1. Zwischenmodulkommunikationen
Eine Hauptkomponente des DCA ist irgendeine Form einer Zwischenmodulkommunikation. Während das DCA als einzelne Gesamtheit zur Außenwelt erscheint, ist es intern zum Gehäuse eine Ansammlung von Programmen, die auf einer Ansammlung von Modulen laufen. Dafür, dass das DCA als einzelnes Mittel erscheint, müssen die einzelnen Module zum Kommunizieren miteinander fähig sein. Dafür, dass diese Kommunikation stattfindet, muss ein gemeinsamer Bus oder ein gemeinsames Netzwerk für alle Module verfügbar sein. Bei der vorliegenden Implementierung muss ein gemeinsames Kommunikationsprotokoll von allen Modulen verwendet werden.
Zwischenmodulkommunikationen werden bei der vorliegenden Implementierung über einen System-Managementbus (SMB) erreicht. Wie es in 3 gezeigt ist, ist der SMB 30 aus zwei LANs zusammengesetzt -- dem SMB10 (der auf ETHERNET basiert) und dem SMB1 (der auf LOCALTALK basiert). Der SMB ist eine Einrichtung für eine Kommunikation zwischen Netzwerkmodulen 32–36 und sorgt auch für eine Verbindung "außerhalb eines Bandes" zu NMSs (Netzwerkmanagementstationen) und Datei-Servern. Die Verwendung von zwei gemeinsamen Netzwerken sorgt für ein Maß an Fehlertoleranz; der SMB1 wirkt als Sicherung für den SMB10 und umgekehrt. Der SMB führt keine Form einer Lastaufteilung durch. Das DCA erfordert nur, dass ein gemeinsames Netzwerk verfügbar ist. Mehr als zwei gemeinsame Netzwerke können vorgesehen sein, um eine noch größere Fehlertoleranz zu gewinnen.
Wie es in 4 dargestellt ist, wird eine Zwischenmodulkommunikation durch Anwendungen unter Verwendung des TCP/IP-Protokollstapels 40 durchgeführt. Der Protokollstapel lässt zu, dass Anwendungen auf den Modulen 32–36 laufen, um unter Verwendung von entweder UDP-Sockeln oder DCP-Sockeln zu kommunizieren. Die meisten Anwendungen, die über den SMB kommunizieren, verwenden UDP-Sockel, welche einen verbindungslosen Service zur Verfügung stellen. TCP liefert einen verbindungsorientierten Service. TCP- und UDP-Sockel sind in einer Dokumentation für Berkeley 4BSD UNIX beschrieben und sind Fachleuten auf dem Gebiet bereits bekannt.
TCP und UDP laufen über eine IP-Schicht, die die Netzwerkadressierungsfunktion durchführt. Jedes Modul/jede Komponente auf dem SMB erfordert eine interne IP-Adresse, die bei diesem Ausführungsbeispiel die folgende Form annimmt:

• 127.chassis id.slot.host

Jedes Modul ordnet seine eigene interne IP-Adresse basierend auf seiner eigenen Information über das Gehäuse, in welchem es eingebaut ist, den Schlitz, den es besetzt, und die Anzahl von Hosts, die es unterstützt, automatisch zu. Eine Netzwerknummer 127.xx.xx.xx Klasse A wird dazu verwendet, sicherzustellen, daß intern zugeordnete IP-Adressen nicht mit irgendeiner extern zugeordneten IP-Adresse kollidieren werden. IP-Datagramme verwenden dann, wenn sie zur Übertragung über Ethernet eingekapselt sind, den Ethernet-Protokolltyp, der für das IP-Protokoll zugeordnet ist, nämlich den Typ 080OH. IP-Datagramme, die die intern zugeordneten Adressen verwenden, verwenden dann, wenn sie zur Übertragung über den SMB10 eingekapselt sind, den Ethernet-Protokolltyp 81CFh. IP-Datagramme, die die intern zugeordneten Adressen verwenden, verwenden dann, wenn sie zur Übertragung über den SMB1 eingekapselt sind, den LLPA-Protokolltyp 3. Diese Protokolle sind im Stand der Technik beschrieben und sind Fachleuten auf dem Gebiet bereits bekannt. Anhand einer Darstellung zeigt 4 (auf der linken Seite) ein "extern" adressiertes IP-Paket 42, das für Ethernet eingekapselt ist, wobei ein SMB10-Treiber 44 auf die Zielortadresse DA (43) im Anfangsblock des Pakets 42 zugreift. 4 zeigt auf der rechten Seite ein "intern" adressiertes IP-Paket 46, das für Ethernet eingekapselt ist, wobei der SMB10-Treiber 44 auf das IP-Paket oder einen Datenteil 47 des Pakets 46 zugreift.
Jedes Modul auf dem SMB10 ist auch einer Datenverbindungs-MAC-Adresse durch den Adressen-PROM des Moduls zugeordnet. MAC-Adressen sind global eindeutig und sind durch IEEE zugeordnet.
Jedes Modul ordnet weiterhin sich selbst eine LOCALTALK-Adresse basierend auf dem Schlitz zu, den es im Gehäuse besetzt.
2. Entdeckung
Damit das Gehäuse als einzelnes System funktioniert (d. h. für den Rest der Welt), müssen die Module und andere Komponenten (z. B. die Leistungsversorgungen) innerhalb des Gehäuses das Gehäuse entdecken, in welchem sie eingebaut sind, das Vorhandensein oder Nichtvorhandensein anderer Module und Komponenten innerhalb desselben Gehäuses und andere Betriebsparameter innerhalb jedes Moduls/jeder Komponente.
2.1. Schlitztabelle
Eine Modulentdeckung ist ein kontinuierlicher Prozeß. Jedes Modul gibt auf einer zeitlichen Basis (in der Größenordnung von Sekunden) eine unverlangte Nachricht auf sowohl dem SMB1-Netzwerk (in der Form eines Rundsendens) als auch dem SMB10-Netzwerk (in der Form eines Mehrfachsendens) aus. Dies ist in 5 dargestellt, wobei ein repräsentatives Modul 50 seine Modulentdeckungsnachricht auf sowohl dem SMB1 als auch dem SMB10 für einen Empfang durch die anderen Module 52 und 54 sendet. Die Nachricht ist eine NVMP-(Network Variable Monitor Protocol = Netzwerkvariablen-Überwachungsprotokoll)-Netzwerkvariable, die Grundinformation über das Modul 50 enthält, wie beispielsweise:
Schlitz-ID
LLAP-Adresse
MAC-Adresse
IP-Adresse
Modultyp
Geräte-IP-Adresse
Geräte-MAC-Adresse
Geräte-Seriennummer
SMB-Steuerungsstatus
Modell-CPU-Status
Modell-CPU-Profil (d. h. die aktuelle Verarbeitungsbelastung der CPU)
Die obige Information wird zum Bilden einer Schlitztabelle mit einem Eintrag für jedes der entdeckten Module verwendet. Beispielsweise ist in 5 eine Schlitztabelle 60 gezeigt, die (von links nach rechts) die folgenden Kategorien enthält:

• Schlitz: die Schlitznummer am Gerät, das durch das Modul besetzt ist
• SMB1, SMB10: ob das Modul über einen oder beide der SMBs erreicht werden kann, und welcher bevorzugt ist
• IP: die IP-Adresse des Moduls
• MAC: die MAC-Adresse des Moduls
• Anderer Stoff: andere Information in bezug auf das Modul, wie beispielsweise einen CPU-Status, ein CPU-Profil, einen Modultyp, etc.

Jedes Modul (50, 52, 54) bildet seine eigene Schlitztabelle. Jedes Modul überwacht den SMB in bezug auf Nachrichten von anderen Modulen, um folgendes zu bestimmen:

• Das Vorhandensein oder Nichtvorhandensein eines Moduls
• Die Fähigkeit, mit einem Modul über den SMB1 zu kommunizieren
• Die Fähigkeit, mit einem Modul über den SMB10 zu kommunizieren
• Den aktuellen Status, das aktuelle Profil, den aktuellen Typ, etc., Information für andere Module

Eine Entdeckung behält nur den "aktuellen Zustand" des Geräts bei. Es wird kein Versuch unternommen, irgendeine historische Information über die Geräteschlitze beizubehalten.
2.2 Betriebsmittelentdeckung
Wenn einmal ein Modul entdeckt und in die Schlitztabelle eingegeben ist, kann das Modul in bezug auf Information über seine Betriebsmittel abgefragt werden, wie beispielsweise:

• CPUs (Typ, Geschwindigkeit, Anwendung)
• Speicher (Typ, Größe, verbrauchter Speicher)
• Schnittstellen (Typ, Geschwindigkeit)

2.3 Anwendungsentdeckung
Wenn einmal ein Modul entdeckt und in die Schlitztabelle eingegeben ist, kann das Modul in bezug auf Information über seine Anwendungen abgefragt werden, wie beispielsweise:

• Anwendungsliste
– Typ (verteilt oder nicht verteilt)
– Status (freigegeben, gesperrt, standby)

3. Geräteauswahl
Bestimmte Anwendungen müssen durch das Gerät unterstützt werden, können aber an irgendeinem Modul ausgeführt werden (z. B. dem verteilten Gerätemittel). Beim Hochfahren oder nach einer Systemänderung (einem Modulausfall/einer Modulentfernung etc.) ist ein Auswahlprozess erforderlich, um die beste Stelle (besten Stellen) zu entdecken, an welcher (welchen) die Geräteanwendungen) laufengelassen wird (werden). Die Entscheidung darüber, wo eine Anwendung (d. h. welches Modul) innerhalb des Geräts anzuordnen ist, basiert auf dem folgenden:

• Verfügbare Betriebsmittel des Moduls
• Aktuelle Anwendungen
• Aktuelles Profil (d. h. die aktuelle Verarbeitungsbelastung der CPU)
• Modultyp
• Schlitznummer

Jede Anwendung kann ihre eigene Gruppe von Befehlen zum Auswählen der besten Stelle für eine Ausführung haben. Die Auswahlbefehle werden durch jedes Modul unter Verwendung der Daten durchgeführt, die in seiner Schlitztabelle gefunden werden. Da jedes Modul dieselbe Übersicht über das Gerät hat, wird jeder Auswahlprozeß zum selben Ergebnis führen. In dem Fall einer Zweckbindung (zwei Module mit genau denselben Betriebsmitteln) kann dann das Modul mit der niedrigeren Schlitznummer ausgewählt werden (oder es werden irgendwelche anderen Kriterien zum Lösen der Zweckverbindung verwendet). Das ausgewählte Modul wird eine unverlangte Nachricht (eine Anwendungsentdeckung) ausgeben, die den neuen Status seiner Anwendungsliste zeigt.
4. Gehäusemittelzugriff
Das "Gehäusemittel" ist die Software, die zulässt, dass das Netzwerkgehäuse als einzelnes System gemanagt wird. Auf sie wird über die Netzwerkadresse zugegriffen, die als die "Gehäuseadresse" bekannt ist. Wenn Kommunikationen mit dem Gehäuse unter Verwendung von Mehrfachzugriffsnetzwerken, wie dem Ethernet, durchgeführt werden, muss das Gehäuse auch eine Datenverbindungsadresse (oder "MAC-Adresse") haben. Die Gehäuseadresse ist eine Kombination aus seinem IP-Netzwerk und seiner MAC-Adresse und wird als die Gehäuse-IP-MAC-Adresse bezeichnet. Das Modul, das als das DCA handelt, hört auf Pakete mit der Gehäuse-IP-MAC-Adresse.
Die Software kann auf einem oder mehreren Modulen innerhalb des Gehäuses laufen, aber auf sie wird immer über dieselbe Gehäuseadresse zugegriffen. Die Software ist nicht von irgendeinem Modul zum Durchführen ihrer Funktion abhängig. Jedes Modul kann auch seine eigene Netzwerkadresse haben, die als "IP-Adresse" bekannt ist. Jedes Modul muss eine Datenverbindungsadresse haben, die als "MAC-Adresse" bekannt ist. Das Gehäusemittel benutzt, ungeachtet dessen, wo (auf welchem Modul) es sitzt, immer dieselbe Gehäuse-IP-MAC-Adresse.
Pakete, die für das verteilte Gehäusemittel DCA bestimmt sind (d. h. Pakete, die die Gehäuse-IP/MAC-Adresse als die Zielortadresse verwenden), können am Gehäuse über irgendeine (oder mehrere) seiner Vorderwand-Anschlussstellen (siehe die Anschlussstellen 25, 27, 29 in 2) ankommen, oder in dem Fall der vorliegenden Implementierung können sie auch über den SMB10 ankommen, wenn der SMB10 nach außen verlagert ist. Das Paket wird (vom Netzwerk aus gesehen) an der Eintrittsstelle zum Gehäuse beendet. Das Modul, das das Paket beendet, hat zwei Wahlen, nachdem es ein zum DCA bestimmtes Paket beendet hat:

a) Es kann das Paket selbst bedienen (d. h. als das DCA handeln) oder
b) Es kann das Paket zu einem anderen Modul für einen Dienst weiterleiten.

Die vorliegende Implementierung lässt zu, dass auf den SMB10, der für das Netzwerk gemeinsam ist, von außerhalb des Gehäuses zugegriffen wird. Der SMB10 kann durch eine Netzwerkmanagementstation (NMS) als Kanal verwendet werden, auf welchem das Gerät zu managen ist. In dem Fall, dass eine NMS an dem SMB10 angeordnet ist, wird ein einzelnes Modul ausgewählt, um als das DCA zu handeln, wenn alle Module Pakete empfangen werden, die zum DCA bestimmt sind (d. h. der SMB10 ist ein Mehrfachzugriffsnetzwerk).
5. MIB-Verteilung
Das DCA verwendet MIBs zum Sammeln von Information über das Gerät und zum Bewirken einer Steuerung am Gerät. Ein MIB ist eine Sammlung von gemanagten Objekten (MOs), die in einen Namensgebungs-(MIB)-Baum organisiert sind, wobei jedes Objekt einen eindeutigen Namen oder Identifizierer innerhalb des Baums hat. Der Identifizierer ist als OID oder als ObjektIDentifizierer bekannt. Damit das DCA als einzelne Einheit über alle Module im Gerät arbeitet, müssen alle durch das Gerät unterstützten MIBs über alle Module verteilt sein.
5.1 MIB-Baum
Der MIB-Baum ist über alle Module innerhalb des Geräts verteilt. Die innerhalb des verteilten MIB enthaltenen Daten sind nicht vollständig verteilt, sondern vielmehr behält jedes Modul einige der Daten lokal und holt den Rest von den entfernten Modulen. Die Daten innerhalb eines verteilten MIB können in die folgenden Typen unterteilt sein:

• Lokale Daten
• Entfernte Daten

Der MIB-Baum enthält Daten, die lokal beibehalten sind, und Zeiger zu entfernten Daten (Zeiger zu Daten an anderen Modulen).
5.2 Verteilte gemanagte Objekte
Zum Implementieren eines verteilten MIB ist ein entfernter Registrierungsprozeß nötig. Bei diesem entfernten Registrierungsprozeß, wie er in 6 dargestellt ist, registriert jedes Registrierungsmodul oder jede Einheit 72, 74, 76, 78 im Gehäuse unter einer bestimmten Verzweigung (OID) an jeder anderen Einheit sowie lokal.
Dasselbe gemanagte Objekt MO (70) erscheint jeweils in jedem MIB-Objekt 73, 75, 77, 79 unter derselben Verzweigung. Ein entfernter oder lokaler Zugriff auf das gemanagte Objekt ist für eine SNMP-Operation transparent. Eine SET-, GET- oder GETNEXT-Operation handelt so, als ob das entfernt registrierte Objekt lokal wäre.
Zum Lösen einer SNMP-Operation am MIB-Objekt durchsucht das SNMP-Mittel den MIB (über das MIB-Objekt) und findet das MO, das für den OID registriert ist, bei der Operation. Wenn das MO einmal gefunden ist, wird die Elementenfunktion des MO entsprechend der bestimmten Operation (GET, GETNEXT, SET) aufgerufen. Vor einem Verteilen von MOs war dies ein "lokaler" Verfahrensaufruf, was bedeutet, dass der gesamte Softwarecode, der als Ergebnis dieses Aufrufs lief, für diesen Prozessor (in einem lokalen Speicher) lokal war. Nun ist dies mit verteilten MOs nicht der Fall. Wenn eine SNMP-Operation zu einer Operation an einem entfernten MO auflöst, wird ein MORPC (Managed Object Remote Procedure Call = entfernter Verfahrensaufruf eines gemanagten Objekts) durchgeführt werden. Die 7–8 zeigen diese Situation, wobei angenommen ist, dass das MO erfolgreich bei allen Gehäuseeinheiten registriert worden ist.
Der oben beschriebene Typ einer Registrierung ist nicht auf Blattobjekte begrenzt. Tabellenobjekte können auch auf diese Weise registriert werden.
5.3 RPCs eines verteilten gemanagten Objekts
Wie es im vorherigen Abschnitt erörtert ist, können gemanagte Objekte durch die Verwendung von MORPCs über mehrere Einheiten verteilt werden. Es gibt sechs MORPCs, die durch ein SNMP-Mittel erzeugt werden können: REGISTER, UNREGISTER, GET, GETNEXT, SETVALIDATE und SET. Ein Antwortpaket für einen MORPC wird durch den MORPC-"Server" an der entfernten Seite eines Aufrufs erzeugt. Die ist vollständig analog zu einem Rücksprungwert für einen lokalen MO-Aufruf und ist in 8 dargestellt.
Ein MORPC kann über irgendein Transportschichtenprotokoll implementiert sein. Die einzige Änderung wäre im Adressenfeld des MIB-Knotenobjekt (das die entfernte Adresse des gemanagten Objekts anzeigt). Die vorliegende Implementierung verwendet UDP, welches ein Teil der TCP/IP-Protokoll-Programmfamilie ist.
MORPC-REGISTER-Operationen treten bei allen Gehäuseeinheiten auf, wenn ein MO als verteiltes MO registriert. Eine Registrierung ist eine garantierte Operation. Ein MO kann nicht teilweise registriert werden (d. h. bei einer Untergruppe von Gehäuseeinheiten registriert werden). Wenn eine Gehäuseeinheit aktiv wird, nachdem ein MO registriert ist, wird das MO (oder eine Gruppe von MOs) bei ihr während des Hochfahrens der Einheit (einer Modulentdeckung) registriert.
MORPC-UNREGISTER-Operationen treten bei allen Gehäuseeinheiten auf, wenn ein verteiltes MO eine Registrierung rückgängig macht. Die Entregistrierungsoperation ist auch garantiert. Ein MO kann nicht teilweise entregistriert werden.
GET, GETNEXT, SET und SETVALIDATE von MORPC sind keine garantierten Operationen. Wenn sie nach einer spezifizierten Auszeitperiode fehlschlagen, wird das gesamte SNMP-Paket fallengelassen.
7 zeigt allgemein vier Gehäusemodule oder Einheiten 100, 102, 104, 106. Ein MIB-Objekt 101 ist lokal am Modul 100 registriert und entfernt als MIB-Objekt 103, 105, 107 jeweils an den Modulen 102, 104, 106. Ein gemanagtes Objekt (MO) 110 wird lokal am Modul 100 beibehalten. Eine GET-Operation 111 am Modul 100 findet das MO 110 lokal und gibt ein lokales Aufrufverfahren (lokales get 120) zum Auflösen der Operation aus. Gegensätzlich dazu findet eine SET-Operation 112, die am Modul 102 empfangen wird, das MO 110 entfernt angeordnet und gibt einen entfernten Verfahrensaufruf (set-RPC 122) zum Auflösen der Operation aus. Gleichermaßen wird eine GET-Operation 113, die am Modul 104 empfangen wird, über einen entfernten Verfahrensaufruf (get-RPC 124) aufgelöst, und eine GETNEXT-Operation 114 am Modul 106 wird als ein entfernter Verfahrensaufruf (getnext-RPC 126) aufgelöst.
8 stellt spezifischer das Verfahren einer lokalen und entfernten Wiedergewinnung und einer Aufrufverarbeitung dar. Auf der rechten Seite dargestellt wird eine SNMP-Operation durch ein SNMP-Mittel 142 in der Gehäuseeinheit 140 empfangen. Das Mittel lokalisiert einen entfernten MIB-Knoten 146 in einem MIB-Baum 144 und initiiert eine entfernte Operation über einen MORPC-Klienten 148. Dann gibt der MORPC-Klient 148 einen Aufruf zum MORPC-Server 158 an der Gehäuseeinheit 150 aus, wo das gemanagte Objekt 160 beibehalten ist. Der MORPC-Server 158 liest das gemanagte Objekt 160 aus und sendet eine MORPC-Antwort zum MORPC-Klienten 148, der die Rücksprungwerte vom MO 160 zurück zum SNMP-Mittel 142 sendet. In dem Fall einer lokalen SNMP-Operation (auf der linken Seite) entdeckt das SNMP-Mittel 152 den lokalen MIB-Knoten 156 im MIB-Baum 154 und liest das MO 160 lokal an der Gehäuseeinheit 150 aus. Die Rücksprungwerte werden zum SNMP-Mittel 152 gesendet, ohne daß eine Verwendung des MORPC-Servers erforderlich ist.
Die vorliegende Erfindung ist nicht auf die Zuteilung von Managementfunktionen über das Gehäuse beschränkt, sondern kann zum Zuteilen irgendeines Typs einer Anwendung über eines oder mehrere Module im Gehäuse verwendet werden.
Die vorliegende Erfindung ist besonders nützlich in Kombination mit dem Gegenstand, der in zwei zugehörigen Anmeldungen vom selben Anmelder offenbar ist:

– US-Seriennr. 08/188,238, eingereicht am 28. Januar 1994, mit dem Titel "Network Having Secure Fast Packet Switching and Guaranteed Quality of Service" von Kurt Dobbins et al., erteilt als US-A-5,485,455; und
– US-Seriennr. 08/188,033, eingereicht am 28. Januar 1994, mit dem Titel "Fault Tolerant System Management Bus Architecture", von Brendan Fee et al., erteilt als US-A-5,485,576,

Während mehrerer Ausführungsbeispiele der vorliegenden Erfindung gezeigt und beschrieben worden sind, wird es Fachleuten auf dem Gebiet klar werden, dass verschiedene Änderungen und Modifikationen dabei durchgeführt werden können, ohne vom Schutzumfang der Erfindung abzuweichen, wie sie durch die beigefügten Ansprüche definiert ist.

Claims

Verfahren des Netzmanagements in einer Vielzahl von Netzmodulen (14; 24, 26, 28; 32, 33, 34, 35, 36; 50, 52, 54), wobei jedes Netzmodul mit anderen Netzmodulen Modulinformation austauscht einschließlich einer oder mehrerer Ressourcen und Anwendungen der jeweiligen Netzmodule; jedes Netzwerkmodul basierend auf Modulinformation auswählt, welches der Netzmodule eine verteilte Anwendung ausführen wird; und eine einzelne Agent-Adresse vorgesehen ist für den Zugriff auf eine verteilte Anwendung, wobei die jeweilige Agent-Adresse eine Kombination einer Gehäuse-IP-Netzadresse und einer Gehäuse-MAC-Adresse ist.
Verfahren nach Anspruch 1, wobei jedes die verteilte Anwendung ausführende Netzmodul auf Pakete mit der Agent-Adresse hin mithört.
Verfahren nach Anspruch 1 oder 2, wobei die Netzmodule in Schlitzen eines Gestells angeordnet sind und die verteilte Anwendung eine Netzmanagementanwendung ist, die das Managen des Gestells als ein ganzes ermöglicht.
System für Netzwerkmanagement, umfassend eine Vielzahl von Netzmodulen (14; 24, 26, 28; 32, 33, 34, 35, 36; 50, 52, 54), wobei jedes Netzmodul angepasst ist, um mit anderen Netzmodulen Modulinformation auszutauschen einschließlich einer oder mehrerer Ressourcen und Anwendungen des jeweiligen Netzmoduls; und jedes Netzmodul eingerichtet ist, um basierend auf der Modulinformation auszuwählen, welches der Netzmodule eine verteilte Anwendung ausführen wird; wobei die verteilte Anwendung eine einzelne Agent-Adresse für einen Zugriff hat und die Agent-Adresse eine Kombination einer Gestell-IP-Netzadresse und einer Gestell-MAC-Adresse ist.
System nach Anspruch 4, wobei jedes die verteilte Anwendung ausführende Netzmodul auf Paketen mit der Agent-Adresse hin mithört.
System nach Anspruch 4 oder 5, wobei die Netzmodule in Schlitzen eines Gestells (10) angeordnet sind und die verteilte Anwendung eine Netzmanagementanwendung ist, die das Managen des Gestells als ein Ganzes ermöglicht.