DE69332370T2

DE69332370T2 - Netzwerkanalyseverfahren

Info

Publication number: DE69332370T2
Application number: DE69332370T
Authority: DE
Inventors: Neil Mckee; Peter Phaal
Original assignee: Agilent Technologies Inc; Hewlett Packard Co
Current assignee: Agilent Technologies Inc
Priority date: 1993-03-08
Filing date: 1993-03-08
Publication date: 2003-06-18
Anticipated expiration: 2013-03-09
Also published as: EP1130847B1; JP3709209B2; EP0615362B1; EP1130847A3; JPH06348622A; EP0615362A1; EP1130848A2; EP1130847A2; DE69332370D1; EP1130848B1; EP1130848A3; US5712981A

Description

Die vorliegende Erfindung bezieht sich auf ein Netzanalyseverfahren zur Verwendung hinsichtlich eines Netzes des Typs, der eine Mehrzahl von Unternetzen aufweist, wobei jedes derselben eine Mehrzahl von Knoten aufweist.
Das Netzanalyseverfahren der Erfindung findet insbesondere bei Netzen Anwendung, bei denen die Bestandteils-Unternetze Logiksegmente sind, die durch Brücken verbunden sind, die auf der Ebene 2 des 7-Schicht-OSI-Referenzmodells arbeiten. Das Netzanalyseverfahren jedoch kann in geeigneten Umständen auch mit anderen Netzen, wie z. B. Internet-Netzen, mit "IP"-Unternetzen verwendet werden, die durch Router bzw. Leitwegeinrichtungen oder Gateways verbunden sind, die auf der Ebene 3 des OSI-Referenzmodells arbeiten.
Da Netzüberwachungssysteme immer hochentwickelter und umfassender werden, hat der Netzbediener ein wachsendes Problem beim Identifizieren signifikanter Daten unter den Datenvolumen bei einem Netzbetrieb, der durch derartige Überwachungssysteme geliefert wird. Dies ist insbesondere der Fall, wenn das betroffene Netz mehrere Unternetze aufweist, wobei bestimmte Knoten als globale Server über alle Unternetze wirken, da es in derartigen Fällen schwierig ist, ein wahres Bild dessen zu erhalten, was tatsächlich in jedem Unternetz geschieht.
Eine Aufgabe der vorliegenden Erfindung besteht darin, ein Netzanalyseverfahren zu schaffen, das eine Einschätzung eines Betriebs des Netzes auf einer Unternetzebene erleichtert.

Zusammenfassung der Erfindung

Zu diesem Zweck liefert die vorliegende Erfindung bei einem Aspekt ein Netzanalyseverfahren, das dazu dient, Knoten, die als lokale Server agieren, zu identifizieren, d. h. Knoten, die hauptsächlich mit einem bestimmten Unternetz zu tun haben. Insbesondere liefert die vorliegende Erfindung bei diesem Aspekt ein Netzanalyseverfahren zur Verwendung hinsichtlich eines Netzes des Typs, der eine Mehrzahl von Unternetzen aufweist, wobei jedes derselben eine Mehrzahl von Knoten aufweist, wobei das Verfahren folgende Schritte aufweist:
(1) Überwachen des Netzes, um Verkehrsdaten zu sammeln und zu speichern, die das Verbindungsmaß zwischen Knoten anzeigen, beurteilt nach einem Verkehr zwischen denselben; und
(2) Verarbeiten der Verkehrsdaten durch ein Entfernen eines Verkehrs, der Knoten zugeordnet ist, die identifiziert sind, um als globale Server zu agieren, und Verwenden des verbleibenden Verkehrs, um Knoten zu identifizieren, die als lokale Server agieren.
Die bevorzugte Entfernung des Globalserververkehrs demaskiert effektiv die lokalen Server, was es ermöglicht, daß dieselben identifiziert werden.
Schritt (2) des Verfahrens beinhaltet vorzugsweise ein Untersuchen der Verkehrsdaten, um einen in Frage kommenden globalen Server unter den Knoten zu identifizieren, wobei ein in Frage kommender globaler Server ein Knoten ist, dessen Verbindungsmaß zu einem der Unternetze kleiner als ein erster vorbestimmter Abschnitt (allgemein 50%) seines Gesamtverbindungsmaßes zu allen Knoten ist, und
- wenn der in Frage kommende globale Server identifiziert wird, Identifizieren des in Frage kommenden globalen Servers mit dem höchsten Gesamtverbindungsmaß, Entfernen seines zugeordneten Verkehrs aus den Verkehrsdaten und Zurückkehren zu dem Start von Schritt (2), um den Schritt unter Verwendung der so modifizierten Verkehrsdaten zu wiederholen;
- wenn kein derartiger, in Frage kommender globaler Server identifiziert wird, Untersuchen der Verkehrsdaten, um einen in Frage kommenden lokalen Server unter den Knoten zu identifizieren, wobei ein in Frage kommender lokaler Server ein Knoten ist, für den für das Unternetz mit dem höchsten Verbindungsmaß zu demselben dieses Verbindungsmaß gleich oder größer als ein zweiter vorbestimmter Abschnitt (wieder allgemein 50%) des Gesamtverbindungsmaßes dieses in Frage kommenden lokalen Servers ist, und
- wenn der in Frage kommende lokaler Server identifiziert wird, Identifizieren des in Frage kommenden lokalen Servers mit dem höchsten Verbindungsmaß (vorzugsweise höchstes Gesamtverbindungsmaß, alternativ jedoch höchstes Verbindungsmaß zu einem der Unternetze), Aufzeichnen dieses Kandidaten als einen lokalen Server, Entfernen seines zugeordneten Verkehrs aus den Verkehrsdaten und Zurückkehren zu dem Start von Schritt (2), um den Schritt unter Verwendung der so modifizierten Verkehrsdaten zu wiederholen;
- wenn kein in Frage kommender lokaler Server identifiziert wird, Verlassen von Schritt (2).
Das Verbindungsmaß eines Knotens mit anderen zugeordneten Knoten wird allgemein hinsichtlich zumindest eines der folgenden Merkmale gemessen: Anzahl zugeordneter Knoten; Anzahl von Rahmen, die bei dem Verkehr mit den zugeordneten Knoten betroffen sind; Anzahl von Bytes, die bei dem Verkehr mit den zugeordneten Knoten betroffen sind. Das Verbindungsmaß kann z. B. hinsichtlich der Anzahl zugeordneter Knoten gemessen werden, wobei jedoch eine Verkehrsvolumenmessung (Rahmen/Bytes) verwendet wird, um Situationen zu lösen, in denen es eine Gleichheit zwischen zwei Verbindungsmaßwerten gibt, die verglichen werden.
Obwohl eine Beurteilung hinsichtlich dessen, ob ein Knoten als ein Server agiert, gänzlich auf relativen Verkehrsverbindungsmaßen basieren kann, wird vorzugsweise die Überwachung des Netzes auf eine derartige Weise ausgeführt, um es zu ermöglichen, daß Rolleninformationen gesammelt werden, die anzeigen, ob ein Knoten in einer Server- oder Clientenrolle hinsichtlich einzelner Verkehrsgegenstände agiert, die demselben zugeordnet sind. In diesem Fall wird die Identifizierung eines Knotens als einen globalen oder lokalen Server in Schritt (2) ohne Bezugnahme auf einen Verkehr bewirkt, für den der Knoten als ein Client agiert, wie durch die Rolleninformationen angezeigt ist. Die Rolleninformationen sind z. B. auf der Basis des "bekannten Port"-Status der Knotenendpunkte abgeleitet, die einem Verkehr zugeordnet sind, der zwischen einem Paar von Knoten verläuft, wobei ein Knoten dieses Paars identifiziert wird, um in einer Serverrolle zu agieren, wobei der andere Knoten identifiziert wird, um in einer Clientenrolle zu agieren, wobei der Endpunkt für den einen Knoten ein bekannter Port ist, während der andere Punkt dies nicht ist.
Sobald die lokalen Server identifiziert wurden, kann eine weitere Analyse ausgeführt werden, um zu bestimmten, wie eine Netzleistung verbessert werden kann. So wird vorzugsweise für zumindest einen der lokalen Server, die in dem Hauptverfahrensschritt (2) identifiziert werden, eine Bestimmung hinsichtlich des optimalen Unternetzes für diesen lokalen Server durchgeführt, wobei diese Bestimmung wiederum ein angenommenes Anordnen des betroffenen lokalen Servers auf jedem Unternetz und ein Auswerten einer vorbestimmten Optimaler-Ort-Funktion für jeden derartigen Ort des lokalen Servers umfaßt, die ein Maß des Verkehrs zwischen Unternetzen liefert, die dem lokalen Server an seinem gegenwärtigen angenommenen Ort zugeordnet wären, wobei eine derartige Bestimmung ferner ein Identifizieren des Unter netzes als das optimale Unternetz umfaßt, für das eine Auswertung der Funktion ein Minimum für den Verkehr zwischen Unternetzen anzeigt. Zur Vereinfachung und Beschleunigung ist die Optimaler-Ort-Funktion vorzugsweise ein Zählwert von Knoten, die ein Verbindungsmaß zu dem betroffenen lokalen Server haben und auf anderen Unternetzen als dem angeordnet sind, das dem gegenwärtigen angenommenen Ort des lokalen Servers entspricht.
Daraufhin, daß das optimale Unternetz für einen lokalen Server bestimmt ist, wird vorzugsweise außerdem eine Bestimmung hinsichtlich dessen geführt, ob, wenn dieser lokale Server in seinem optimalen Unternetz angeordnet ist, einer der Knoten, zu dem er ein Verbindungsmaß als ein Server aufweist, auch zu dem optimalen Unternetz bewegt werden sollte. Diese Bestimmung beinhaltet ein Testen für jeden Knoten, ob das Verbindungsmaß zwischen diesem Knoten und dem lokalen Server im wesentlichen die Hälfte oder mehr des Gesamtverbindungsmaßes dieses Knotens ist.
Eine weitere nützliche Analyse, die ausgeführt werden kann, sobald die lokalen Server identifiziert wurden, besteht darin, die lokalen Server und ihre Clientenknoten Arbeitsgruppen zuzuordnen. Zu diesem Zweck wird wiederum jeder lokale Server in der Reihenfolge eines absteigenden Verbindungsmaßes innerhalb der Gruppe lokaler Server genommen, wobei für jeden derartigen Server:
(i) eine jeweilige Arbeitsgruppe für denselben erzeugt wird, es sei denn, der betroffenen lokale Server wurde bereits einer anderen Arbeitsgruppe zugeordnet, die hinsichtlich eines lokalen Servers, der weiter oben in der Reihenfolge ist, erzeugt wurde,
(ii) wenn die jeweilige Arbeitsgruppe in (i) für den betroffenen lokalen Server erzeugt wurde, der Server dieser Arbeitsgruppe zugewiesen wird, und
(iii)jeder Knoten, dessen Verbindungsmaß mit dem lokalen Server zumindest die Hälfte des Gesamtverbindungsmaßes dieses Knotens ist, der gleichen Arbeitsgruppe wie der lokale Server zugeordnet wird.
Es ist zu erkennen, daß eine Arbeitsgruppe für den Fall mehr als einen lokalen Server enthalten kann, daß ein derartiger Server ein gut verbundener Client eines anderen derartigen Servers ist.
Unter Verwendung der Arbeitsgruppen, die auf diese Weise festgelegt sind, kann dann eine Bestimmung hinsichtlich dessen durchgeführt werden, ob es sich lohnt, das Unternetz in zwei Unternetze aufzuteilen, wobei diese Bestimmung folgende Schritte beinhaltet:
(a) Abschneiden der oder jeder Arbeitsgruppe, die hinsichtlich eines lokalen Servers erzeugt wurde, der sich auf dem Unternetz von Interesse befindet, durch ein Entfernen jedes Knotens, der sich auf einem unterschiedlichen Unternetz als dem von Interesse befindet, und jedes Knotens, dessen Einschluß in die Arbeitsgruppe direkt oder indirekt auf seiner Zuordnung zu einem Knoten beruht, der auf einem unterschiedlichen Unternetz als dem von Interesse angeordnet ist, aus der Arbeitsgruppe;
(b) Bilden einer jeweiligen weiteren Arbeitsgruppe für jeden Knoten des Unternetzes von Interesse, wobei dieser Knoten noch nicht in einer Arbeitsgruppe ist, die dem Unternetz zugeordnet ist;
(c) Zusammenführen der Arbeitsgruppen, die dem Unternetz von Interesse zugeordnet sind, bis nur zwei derartige Arbeitsgruppen verbleiben; und
(d) Entscheiden, ob es sich lohnt, das Unternetz aufzuteilen, indem die Verkehrsmenge zwischen den beiden Ar beitsgruppen, die nach Schritt (c) verbleiben, mit dem Gesamtverkehr verglichen wird, der jeder derartigen Arbeitsgruppe zugeordnet ist.
Die Analyseaufgaben, die nach einer Identifizierung der lokalen Server ausgeführt werden, werden natürlich vorzugsweise unter Verwendung der Verkehrsdaten ausgeführt, die in Schritt (1) des Hauptverfahrens gesammelt werden, wobei jedoch der gesamte Globalserververkehr entfernt ist. Selbst wenn der gesamte Globalserververkehr jedoch nicht entfernt ist, erzeugen diese Analyseaufgaben allgemein dennoch einige nützliche Informationen.

Kurze Beschreibung der Zeichnungen

Ein Netzanalyseverfahren gemäß der Erfindung wird nun mittels eines nichteinschränkenden Beispiels Bezug nehmend auf die beigefügten schematischen Zeichnungen beschrieben, in denen:
Fig. 1 ein Knoten-Cluster-Diagramm ist, das ein exemplarisches Netz mit vier Unternetzen darstellt;
Fig. 2 ein Diagramm ist, das dem aus Fig. 1 ähnelt, jedoch einen exemplarischen Gesamtverkehr zwischen Knoten des Netzes aus Fig. 1 für einen bestimmten Überwachungszeitraum zeigt;
Fig. 3 ein Diagramm ist, das die Hauptprogrammgegenstände und Datenstrukturen darstellt, die bei dem Netzanalyseverfahren verwendet werden;
Fig. 4A eine erste Form einer Verkehrselementdatenstruktur zeigt;
Fig. 4B eine zweite Form einer Verkehrselementdatenstruktur zeigt;
Fig. 5 ein Flußdiagramm eines Extrahieren-von-Servern- Programms ist, das in Fig. 3 gezeigt ist;
Fig. 6 ein Diagramm ist, das dem aus Fig. 2 ähnelt, jedoch nur diese Komponente des Gesamtverkehrs zeigt, die einen Knoten N1 beinhaltet;
Fig. 7 ein Diagramm ist, das dem aus Fig. 2 ähnelt, jedoch nur die Komponenten des Gesamtverkehrs zeigt, die nach einer Entfernung eines Verkehrs verbleiben, der globalen Servern zugeordnet ist, wie durch das Extrahieren-von-Servern-Programm aus Fig. 5 identifiziert ist;
Fig. 8 ein Diagramm ist, das dem aus Fig. 2 ähnelt, jedoch nur einen Teil des Netzes und nur die Komponente des Gesamtverkehrs zeigt, die einem Lokalserverknoten N5 zugeordnet ist, wie durch das Extrahieren-von-Servern-Programm aus Fig. 5 identifiziert ist;
Fig. 9 ein Flußdiagramm eines Bewegungsvorschläge- Programms ist, das in. Fig. 3 gezeigt ist;
Fig. 10 ein Flußdiagramm eines Plazieren-von-Server- Programm-Gegenstandes ist, der durch das Bewegungsvorschläge-Programm aus Fig. 9 verwendet wird;
Fig. 11 ein Flußdiagramm eines Plazieren-von-Client- Programm-Gegenstandes ist, der durch das Bewegungsvorschläge-Programm aus Fig. 9 verwendet wird;
Fig. 12 ein Diagramm ist, das dem aus Fig. 2 ähnelt, jedoch nur ein Unternetz und nur die Komponenten des Gesamtverkehrs zeigt, die lokal auf dem Un ternetz sind und lokalen Servern zugeordnet sind, wie durch das Extrahieren-von-Server-Programm aus Fig. 5 identifiziert ist;
Fig. 13 ein Flußdiagramm eines Aufteilungsvorschläge- Programms ist, das in Fig. 3 gezeigt ist;
Fig. 14 ein Flußdiagramm eines Abschneiden-von- Arbeitsgruppen-Programm-Gegenstandes ist, der durch das Aufteilungsvorschläge-Programm aus Fig. 13 verwendet wird,
Fig. 15 ein Flußdiagramm eines Zusammenführen von- Arbeitsgruppen-Programm-Gegenstandes ist, der durch das Aufteilungsvorschläge-Programm aus Fig. 13 verwendet wird; und
Fig. 16 ein Flußdiagramm eines Aufteilungsentscheidung- Programm-Gegenstandes ist, der durch das Aufteilungsvorschläge-Programm aus Fig. 13 verwendet wird.

Beste Ausführungsform der Erfindung

Fig. 1 stellt ein exemplarisches Netz dar, das vier Logik- Segmente (Unternetze) X1, X2, X3 und X4 aufweist, wobei jedes derselben eine Mehrzahl von Knoten N aufweist, wobei die Knoten, die einem bestimmten Logiksegment zugeordnet sind, zusammen gruppiert sind. Die Logiksegmente sind durch aufspannende Vorrichtungen in der Form von Brücken miteinander verbunden, die auf der Ebene 2 des 7-Schicht-OSI- Referenzmodells arbeiten. Jede Brücke erscheint in dem Cluster-Diagramm aus Fig. 1 in der Form eines entsprechenden Knotens in jedem der beiden Logiksegmente, die sie verbindet. Die Struktur der Verbindung der Logiksegmente durch die Brücken ist für die Zwecke der vorliegenden Beschreibung nicht von Bedeutung. Das exemplarische Netz aus Fig. 1 kann durch überbrückte Ethernetze gebildet sein, wobei jeder Knoten durch eine Ethernet-Adresse identifiziert ist, die über alle Logiksegmente des Netzes gültig ist. Die Knoten N sind Quelle und Senke für Verkehr zueinander bzw. voneinander, wobei dieser Verkehr in der Form diskreter Nachrichtenpakete vorliegt, die sowohl Quellen- als auch Zielknotenadressen sowie die Daten tragen, die übertragen werden sollen.
Das Netz aus Fig. 1 wird als die Basis für exemplarische Verkehrverteilungsdiagramme verwendet, die im Folgenden verwendet werden, um die Beschreibung der Netzanalyseverfahren der Erfindung zu erleichtern. Zu Zwecken der folgenden Beschreibung wird angenommen, daß die Topologie des Netzes hinsichtlich dessen, welche Knoten welchen Logiksegmenten zugeordnet sind, bereits bekannt ist.
Fig. 2 stellt den Verkehr über das Netz aus Fig. 1 über einen bestimmten Zeitraum där, wobei der Verlauf von Nachrichtenpaketen zwischen zwei Knoten durch eine zwischen denselben gezogene Linie dargestellt ist, wobei die Dicke der Linie eine grobe Anzeige der Verkehrsmenge liefert. Bei dem vorliegenden Beispiel sind die Verkehrsflüsse durch eine Untersuchung der Schicht-2-Quellen- und. Zieladressen hergeleitet, die jedem Paket zugeordnet sind. Da die Schicht-2-Adressen über das gesamte Netz gültig sind, ergibt ein Untersuchen der Schicht-2-Adressen die wahren Quellen- und Zielknoten eines Paketes unabhängig von dem Weg, der durch das Nachrichtenpaket über das Netz genommen wird.
Trotz des Mangels einer Klarheit in Fig. 2, was aus dem Zusammendrängen der Verkehrslinien resultiert, ist es möglich zu sehen, daß bestimmte Knoten sehr stark mit den anderen Knoten des Netzes kommunizieren. Die Knoten N1 und N2 auf dem Logiksegment X1 z. B. scheinen mit eigentlich allen anderen Knoten des Netzes zu kommunizieren, woraus sinnvoll schlußgefolgert werden kann, daß diese Knoten eine bestimmte Gesamtrolle beim Überwachen oder Steuern des Netzes haben.
Während Diagramme der Form aus Fig. 2 einem Netzbediener einen allgemeinen Eindruck hinsichtlich dessen geben, was in dem Netz passiert, erlauben dieselben keine detaillierte Untersuchung des Verhaltens des Netzes und können leicht mißverstanden werden.
Die Netzanalyseverfahren, die im Folgenden beschrieben sind, analysieren Verkehrsdaten, die ähnlich sind wie die, die verwendet werden, um Diagramme der Form aus Fig. 2 im Hinblick auf ein Liefern hilfreicher Informationen über den Charakter des Netzes und hinsichtlich dessen, wie die Leistung desselben verbessert werden kann, zu erzeugen.
Die allgemeine Philosophie hinter den Netzanalyseverfahren, die noch beschrieben werden, ist die, daß starke Verbesserungen an der Leistung des Netzes allgemein nicht von einem Neupositionieren von Knoten herrühren, die eine globale Struktur von Kommunikationen aufweisen (d. h. ihre Kommunikation ist nicht hauptsächlich mit einem Logiksegment), sondern von einem Modifizieren des Netzes hinsichtlich Knoten, die hauptsächlich mit einem Logiksegment kommunizieren (wenn auch nicht notwendigerweise dem Segment, auf dem sich der Knoten selbst befindet).
Eine wichtige Analyseaufgabe besteht deshalb darin, die Knoten, die hauptsächlich auf einer globalen Basis ("globale Server") kommunizieren, aus den Knoten ausfindig zu machen, die hauptsächlich mit nur einem Segment kommunizieren und Hauptkommunikatoren hinsichtlich dieses Segmentes sind ("lokale Server"). Es ist zu erkennen, daß, während es viele Knoten geben kann, die hauptsächlich mit nur einem Segment kommunizieren, nur einige dieser Knoten eine serverartige Rolle haben. Daraufhin, daß die lokalen Server identifiziert sind, werden die hierin beschriebenen Netzanalyseverfahren dann verwendet, um Vorschläge hinsichtlich dessen zu machen, ob einer dieser lokalen Server zu einem anderen Logiksegment bewegt werden sollte, und hinsichtlich dessen, ob sich ein Aufteilen eines Segmentes zwischen zwei zugeordneten lokalen Servern lohnt.
Fig. 3 zeigt die Hauptprogrammgegenstände und Hauptdatenstrukturen, die bei der im Folgenden beschriebenen Implementierung der vorliegenden Erfindung verwendet werden. Insbesondere sind drei Hauptprogrammkomponenten vorgesehen, wobei diese ein Extrahieren-von-Servern-Programm 10, ein Bewegungsvorschläge-Programm 1 und ein Aufteilungsvorschläge-Programm 12 sind.
Für das Extrahieren-von-Servern-Programm 10 sind sowohl Verkehrsdaten als auch Daten über die logische Anordnung des Netzes verfügbar. Die Verkehrsdaten sind in der Form eines Satzes von Verkehrselementen 22, die einen Knoten-zu- Knoten-Verkehr auf dem Netz über einen bestimmten Zeitraum charakterisieren. Die Daten über die logische Anordnung des Netzes sind in der Form einer Liste von Segmenten 20 und einer Liste von Knoten 21, wobei jede Liste Zuordnungsinformationen zwischen Segmenten und Knoten umfaßt. Das Extrahieren-von-Servern-Programm 10 analysiert die Verkehrsdaten, die in Verkehrselementen 22 dargelegt sind, um eine Globalserverliste 23 und eine Lokalserverliste 24 zu erzeugen.
Das Bewegungsvorschläge-Programm 11 umfaßt Programmgegenstände Plazieren-von-Server 13 und Plazieren-von-Client 14. Das Bewegungsvorschläge-Programm 11 wiederum schaut sich jeden lokalen Server an, der durch das Programm 10 identifiziert wird, um zu entscheiden, ob es von Vorteil wäre, den lokalen Server zu einem anderen Segment zu bewegen, und, falls dies der Fall ist, ob es auch einen Vorteil bei einem Bewegen eines seiner Clientenknoten (d. h. Knoten, mit denen derselbe kommuniziert) zu dem gleichen Segment gibt. Auf der Basis dieser Analyse erzeugt das Programm 11 eine Liste mit Bewegungsvorschlägen (Knotenbewegungsliste 25). Das Programm 11 erzeugt außerdem eine Liste mit Arbeitsgruppen (Arbeitsgruppenliste 26), wobei jede Arbeitsgruppe einen lokalen Server und seine eng verbundenen Clientenknoten, falls vorhanden, aufweist.
Das Aufteilungsvorschläge-Programm 12 umfaßt Programmelemente Abschneiden-von-Arbeitsgruppe 15, Zusammenführen von- Arbeitsgruppe 16 und Aufteilungsentscheidung 17. Das Programm 12 sieht sich jedes logische Element des Netzes an und gruppiert alle Knoten unter Verwendung der Arbeitsgruppen, die in der Arbeitsgruppenliste 26 aufgelistet sind, als einer Basis in zwei Arbeitsgruppen. Das Programm 12 führt dann eine Entscheidung durch, ob es sich lohnt, das Segment zwischen zwei Arbeitsgruppen aufzuteilen, und, wenn es entscheidet, daß es einen Vorteil hieraus gäbe, gibt es einen Aufteilungsvorschlag in eine Segmentaufteilungsliste 27 ein.
Wie im Folgenden klar werden wird, hängt die Ebene der Ausgereiftheit der Programme 10, 11 und 12 (und insbesondere des Programms 10 beim Identifizieren von globalen und lokalen Servern) von der Detailtiefe ab, die durch die Verkehrsdaten geliefert wird (Elemente 22). So können die Verkehrsdaten einfach auf Ebene-2-Paketinformationen basieren, das heißt, auf den Quellen- und Zielknotenadressen von Meldungspaketen, die über das Netz geleitet werden, wobei kein Versuch unternommen wird, auf eine Strukturierung auf höherer Ebene zu schauen, die in dem Datenteil der Pakete enthalten ist. Alternativ können die Verkehrsdaten eine derartige Strukturierung auf höherer Ebene mit einer Betrachtung eines Bereitstellens einer Anzeige berücksichtigen, ob Pakete, die zu und von einem bestimmten Knoten geleitet werden, dies so tun, daß der Knoten in einer Serverrolle oder in einer Clientenrolle agiert. In Abwesenheit dieser detaillierteren Form von Verkehrsdaten muß das Extrahieren-von-Servern-Programm 10 seine Beurteilung darüber, welche Knoten Server sind, einfach auf der Basis von Verkehrsverbindungsmaßgrößen treffen.
Geeignete Netzüberwachungssysteme sind Fachleuten auf diesem Gebiet ersichtlich, welche Ebene von Verkehrsdaten auch immer erforderlich ist. Ein derartiges System ist z. B. in unserer Europäischen Patentspezifizierung EP-A-0 480 555 beschrieben, die auf einem zufälligen Abtasten von Paketen basiert. (es ist ersichtlich, daß bestimmte Details hinsichtlich dessen, wie viele Daten auf jedem abgetasteten Paket erfaßt sind, u. U. von denen, die in dieser Spezifizierung beschrieben sind, verändert werden müssen, wobei eine derartige Veränderung jedoch für Fachleute auf diesem Gebiet eine Routineangelegenheit ist). Andere Überwachungssysteme, einschließlich derer, die jedes an den Überwachungspunkten empfangene Paket aufzeichnen, können ebenfalls verwendet werden.
Für eine Klarheit der Erklärung wird zuerst die Operation der Programme 10, 11 und 12 ohne eine Zuflucht zu einer Untersuchung einer Strukturierung auf höherer Ebene der Paketdaten für den Fall beschrieben, in dem die Verkehrsdaten auf den Ebene-2-Paketinformationen basieren. Die Weiterentwicklungen, die mit Strukturierungsinformationen auf höherer Ebene möglich sind, werden dann besprochen.
Wie bereits angezeigt wurde, weisen die Verkehrsdaten, die durch die Programme 10, 11, 12 analysiert werden, einen Satz von Verkehrselementen 22 auf. Fig. 4A zeigt die Struktur eines Verkehrselementes 22 für den Fall, bei dem die Verkehrsdaten nur auf Ebene-2-Paketinformationen basieren. Wie dies ersichtlich ist, weist jedes Verkehrselement vier Felder auf, nämlich ein Knoten-1-Identität-Feld, eirt Knoten-2-Identität-Feld, ein Gesamtverkehr-Feld und ein "Aktivieren"-Flag-Feld. Wenn Verkehrselemente 22 die Form aus Fig. 4A aufweisen, gibt es ein jeweiliges Verkehrselement 22 für jedes Paar kommunizierender Knoten in dem Netz, wobei die Identität der betroffenen Knoten in dem Knoten-1- und dem Knoten-2-Identitätsfeld aufgezeichnet ist. Jedes derartige Verkehrselement 22 wird verwendet, um den Gesamt verkehr (z. B. angesichts der Anzahl von Paketen und/oder der Anzahl von Bytes) aufzuzeichnen, det zwischen den betroffenen Knoten in beiden Richtungen weitergeleitet wird.
Das Aktivieren-Flag-Feld jedes Verkehrselementes 22 aus Fig. 4A ermöglicht es, daß Elemente zum Einschluß oder Ausschluß aus den Verkehrsdaten markiert werden, die zu einer bestimmten Zeit durch die Programme 10, 11, 12 betrachtet werden. Nach einer Übereinkunft ist, wenn ein Element 22 sein Aktivieren-Flag gesetzt hat, dasselbe in den gegenwärtig relevanten Verkehrsdaten enthalten, während, wenn das Flag rückgesetzt ist, das Element ausgeschlossen ist. Zu Beginn (zu Beginn des Programms 10) sind die Aktivieren-Flags aller Verkehrselemente, die die Verkehrsdaten bilden, in einem Setz-Zustand.
Hinsichtlich der Betrachtung des Extrahieren-von-Servern- Programms 10 ist dieses Programm in Flußdiagrammform in Fig. 5 gezeigt und weist Schritte 30 bis 39 auf. Zu Beginn untersucht das Programm 10 die Verkehrsdaten, die durch die Verkehrselemente 22 dargestellt werden, und erzeugt eine Liste aller aktiver Knoten (Schritt 30), d. h. Knoten, die Verkehr senden oder empfangen. Wenn es tatsächlich keine aktiven Knoten gibt (in Schritt 31 getestet), endet das Programm 10 unmittelbar. Wenn jedoch, wie dies allgemein der Fall sein wird, die Verkehrsdaten zeigen, daß es aktive Knoten gibt, fährt das Programm 10 mit Schritt 32 fort, bei dem dasselbe nach dem Vorliegen von Knoten in der Liste aktiver Knoten sieht, die als globale Server agieren.
In diesem Zusammenhang ist mit "globaler Server" ein Knoten gemeint, dessen Verkehrsverbindungsmaß mit einem der Logiksegmente X1 bis X4 des Netzes kleiner als ein vorbestimmter Anteil des Gesamtverbindungsmaßes dieses Knotens mit allen Segmenten ist. Allgemein ist dieser vorbestimmte Anteil 50% oder ein ähnlicher Prozentsatz. Anders ausgedrückt ist ein globaler Server ein Knoten mit keinem vorherrschenden Verbindungsmaß zu einem bestimmten Logiksegment des Netzes. Das Maß des Verkehrsverbindungsmaßes, das beim Durchführen der Einschätzung hinsichtlich dessen verwendet wird, ob ein Knoten ein globaler Server ist, ist vorzugsweise einfach ein Zählwert der Anzahl von Partnerknoten, d. h. die Zahl von Knoten, mit denen der Knoten von Interesse kommuniziert. Es wäre jedoch auf möglich, die Messung auf dem Verkehrsvolumen hinsichtlich Paketen, Rahmen oder Bytes zu basieren, die mit jedem Logiksegment ausgetauscht werden, vorausgesetzt, das Gesamtverkehrfeld jedes Verkehrselementes 22 zeichnet die geeigneten Informationen auf.
Fig. 6 stellt den Netzverkehr aufgrund eines Globalserverknotens N1 in dem Logiksegment X1 dar. Wie dies ersichtlich ist, kommuniziert der Knoten N1 mit im wesentlichen allen anderen Knoten mit dem Ergebnis, daß seine Kommunikation mit jedem anderen der Logiksegmente X1 bis X4 kleiner als 50% seiner gesamten Kommunikation mit allen Segmenten ist.
Unter der Annahme, daß zumindest ein globaler Server in der Aktivknotenliste in Schritt 32 gefunden wird, führt das Programm 10 als nächstes Schritt 33 aus, bei dem dasselbe den globalen Server in der Aktivknotenliste identifiziert, der das höchste Gesamtverkehrsverbindungsmaß aufweist (wieder vorzugsweise hinsichtlich eines Partnerknotenzählwertes gemessen, wobei, wenn zwei globale Server den gleichen Partnerknotenzählwert aufweisen, dann darauf zurückgegriffen werden kann, daß die Gesamtverkehrsvolumina betrachtet werden). Sobald Schritt 33 den, aktivsten globalen Server identifiziert hat, wird die Identität dieses Servers zu der Globalserverliste 23 hinzugefügt (Schritt 34).
Das Programm 10 fährt als nächstes mit Schritt 35 fort, bei dem der gerade identifizierte Server aus der Aktivknotenliste entfernt wird und seine zugeordneten Verkehrselemente durch ein Rücksetzen des Aktivieren-Flags in jedem dieser Elemente deaktiviert werden.
Das Programm kehrt nun zu Schritt 32 zurück und führt einen Test auf der Basis der modifizierten Verkehrsdaten (d. h. der Verkehrsdaten, wobei bestimmte der Elemente 22 deaktiviert sind) durch, um zu sehen, ob es globale Server gibt, die in der Aktivknotenliste vorhanden sind; falls dies der Fall ist, werden die Schritt 33 bis 35 wiederholt. Dieser Prozeß fährt fort, bis keine globalen Server mehr in der Aktivknotenliste durch den Test aus Schritt 32 identifiziert werden. Für den exemplarischen Verkehr aus Fig. 2 treten drei Iterationen der Schritt 33 bis 35 auf, bevor kein weiterer globaler Server mehr gefunden wird. Die erste Iteration identifiziert den Knoten N1 als einen globalen Server, die zweite Iteration identifiziert den Knoten N2 als einen globalen Server und die dritte Iteration identifiziert N3 als einen globalen Server. Wenn die Verkehrselemente dieser globalen Server deaktiviert sind, stellen die verbleibenden Elemente eine Verkehrsverteilung dar, die in Fig. 7 gezeigt ist.
Wenn Schritt 32 keinen globalen Server identifizieren kann, wird Schritt 36 ausgeführt, um auf das Vorliegen eines lokalen Servers in der Aktivknotenliste hin zu testen. In diesem Zusammenhang ist ein "lokaler Server" ein Knoten, dessen Verkehrsverbindungsmaß mit dem Logiksegment, mit dem derselbe am stärksten verbunden ist, größer als ein vorbestimmter Anteil (allgemein 50% oder dergleichen) seines Gesamtverbindungsmaßes mit allen Segmenten ist. So agieren z. B. die Knoten N4, N5, N6 und N7 aus Fig. 7 als lokale. Server für den Verkehr, der betrachtet wird (tatsächlich gibt es eine Anzahl anderer Knoten, die in Fig. 7 als lokale Server agieren, auf diese wird jedoch zur Klarheit nicht verwiesen). Es ist ersichtlich, daß das Maß des Verkehrsverbindungsmaßes, das beim Testen nach einem lokälen Server verwendet wird, wie bei dem Globalservertest, einfach ein Zählwert von Partnerknoten sein kann oder ein Maß des tatsächlichen Verkehrsvolumens sein kann. Es ist außerdem ersichtlich, daß die Verkehrsverbindungsmaß-Maße auf der Basis der Verkehrsdaten ausgeführt werden, wie dieselben durch das Deaktivieren von Verkehrselementen durch Schritt 35 modifiziert sind.
Unter der Annahme, daß zumindest ein lokaler Server in der Aktivknotenliste identifiziert wird, fährt das Programm 10 dann mit Schritt 37 fort, bei dem dasselbe den lokalen Server mit dem höchsten Verkehrsverbindungsmaß identifiziert (vorzugsweise als ein Zählwert der Gesamtanzahl von Partnerknoten gemessen, wobei ein Gleichstand durch eine Referenz auf Verkehrsvolumen gelöst wird) - Sobald der lokale Server mit dem höchsten Verkehrsverbindungsmaß identifiziert wurde, wird die Identität dieses Servers zu der Lokalserverliste 24 hinzugefügt (Schritt 38). Schritt 35 wird dann ausgeführt, um den identifizierten Server von der Aktivknotenliste zu entfernen und seine zugeordneten Verkehrselemente 22 zu deaktivieren:
Danach kehrt das Programm 10 in einer Schleife zurück zu Schritt 32, um wieder nach dem Vorliegen von globalen Servern in der Aktivknotenliste zu testen (es ist ersichtlich, daß die Deaktivierung der Verkehrselemente, die dem gerade identifizierten lokalen Server zugeordnet sind, zu dem Auftreten eines neuen globalen Servers in der Aktivknotenliste geführt haben kann, obwohl dies für den vorliegenden exemplarischen Verkehr nicht der Fall ist).
Die Identifizierung von globalen und lokalen Servern fährt auf diese Weise mit der bevorzugten Identifizierung von globalen Servern fort, bis keine weiteren globalen oder lokalen Server mehr gefunden werden. Dies führt dazu, daß das Programm von Schritt 36 zu Schritt 39 austritt, bei dem dasselbe alle Verkehrselemente 22 reaktiviert, die während des Laufens des Programms 10 deaktiviert wurden. Das Programm 10 endet dann.
Sobald das Extrahieren-von-Servern-Programm 10 die lokälen Server identifiziert hat, kann das Bewegungsvorschläge- Programm 11 ausgeführt werden, um das optimale Logiksegment X1 bis X4 für jeden Server sicherzustellen und vorzuschlagen, ob als eine Konsequenz ein lokaler Serverknoten gemeinsam mit einem seiner Clientenknoten bewegt werden soll. Eine typische Situation, in der ein lokaler Server nützlich bewegt werden könnte, ist in Fig. 8 dargestellt, die die Logiksegmente X3 und X4 und die Komponente des Verkehrs, der in Fig. 7 dargestellt ist, zeigt, der einem Lokalserverknoten N5 zugeordnet ist. Aus Fig. 8 ist es ersichtlich, daß der Knoten N5 hauptsächlich mit dem Logiksegment X4 kommuniziert, obwohl der Lokalserverknoten N5 auf dem Logiksegment X3 angeordnet ist. Es wäre natürlich von Vorteil, wenn der Lokalserverknoten N5 von dem Logiksegment X3 zu dem Logiksegment X4 bewegt werden würde. Diesen Typ Situation soll das Bewegungsvorschläge-Programm 11 identifizieren.
Fig. 9 ist ein Flußdiagramm des Bewegungsvorschläge- Programms 11. Dieses Programm soll auf die gesammelten Verkehrsdaten wirken, von denen die Verkehrselemente 22, die den identifizierten globalen Servern zugeordnet sind, entfernt wurden. Folglich soll der erste Schritt 40 des Programms 11 die Verkehrselemente deaktivieren, die den globalen Servern zugeordnet sind. Danach betritt das Programm 11 eine Schleifenstruktur, bei der jeder lokale Server der Reihe nach in einer Partnerzählwertgrößenreihenfolge betrachtet wird (Schritt 41), wobei der Austrittstest aus dieser Schleifenstruktur in Schritt 42 ist, der einen Test durchführt, um zu sehen, ob ein lokaler Server übrig ist, der verarbeitet werden soll.
Jeder lokale Server wird Verarbeitungsschritten 44 bis 48 unterzogen, um zu bestimmen, ob derselbe zu einem unterschiedlichen Logiksegment bewegt werden sollte, oder ob einer seiner Clientenknoten bewegt werden sollte.
Insbesondere wird in Schritt 44 der Plazieren-von-Server- Programm-Gegenstand 30 ausgeführt, um zu bestimmen, ob der betrachtete lokale Server (der gegenwärtige "Ziel"-Server) bewegt werden sollte, wobei Bewegungsvorschläge in der Knotenbewegungsliste 25 plaziert werden. Der Plazieren-von- Server-Programm-Gegenstand 13 implementiert angenommenermaßen außerdem eine vorgeschlagene Bewegung für den Zielserver, um es zu ermöglichen, daß der nachfolgende Schritt 46 prüft, ob einer der Clientenknoten des Zielservers ebenfalls bewegt werden sollte.
In Schritt 45 wird eine neue Arbeitsgruppendatenstruktur (im Folgenden einfach als "Arbeitsgruppe" bezeichnet) für den Zielserver erzeugt, wenn derselbe vorher noch nicht eingeschlossen wurde, und zwar als ein Clientenknoten in einer Arbeitsgruppe, die bei einer früheren Iteration der Schritte 44 bis 48 hinsichtlich eines lokalen Servers mit einem höheren Clientenknotenzählwert erzeugt wurde. Die Arbeitsgruppen sind in einer Arbeitsgruppenliste 26 verbunden. Jede Arbeitsgruppe wird betrachtet, um dem Logiksegment zugeordnet zusein, auf dem der lokale Server, der die Erzeugung verursacht, angeordnet ist.
Als nächstes wird in Schritt 46 der Plazieren-von-Client- Programm-Gegenstand 46 ausgeführt, um sicherzustellen, ob einer der Clientenknoten des Zielservers zu dem Logiksegment des Servers bewegt werden sollte (dies ist das Segment, auf dem sich der Server nach einer Implementierung eines Bewegungsvorschlags befindet, der durch Schritt 44 bereitgestellt wird). Jeder Clientenbewegungsvorschlag, der durch das Plazieren-von-Client-Programm erzeugt wird, ist in der Knotenbewegungsliste 25 gespeichert, wobei jeder Vorschlag zeitweilig implementiert ist. Ferner ist jeder Clientenknoten, der gut mit dem Zielserver verbunden ist (d. h. im wesentlichen zumindest die Hälfte des Gesamtverbindungsmaßes des Clienten liegt bei dem Zielserver), in der gleichen Arbeitsgruppe wie der Zielserver plaziert. Es ist ersichtlich, daß ein Einschätzen, ob ein Clientenknoten gut mit seinem zugeordneten lokalen Server ver bunden ist, durch ein Betrachten der Verkehrsvolumenmaße und nicht der Knotenzählwerte ausgeführt wird.
Nachdem alle Clientenknoten des Zielservers geprüft wurden, um zu sehen, ob dieselben vorzugsweise bewegt werden könnten, wird eine angenommene Bewegung des Zielservers und seiner Clienten von ihren ursprünglichen Segmenten durch eine geeignete Aktion in dem relevanten Segment und Knotendatenstrukturen 20 und 21 umgekehrt (Schritt 47 und 48).
Sobald alle lokalen Server, die in der Lokalserverliste 24 aufgezeichnet sind, einer Verarbeitung in den Schritten 44 bis 48 unterzogen wurden, wird die Schleifenstruktur des Bewegungsvorschläge-Programm-Gegenstandes 11 bei Schritt 42 verlassen und alle Globalserververkehrselemente werden wieder aktiviert (Schritt 49), bevor der Programmgegenstand 11 beendet wird.
Es wird angemerkt, daß der Grund, warum die lokalen Server durch den Programmgegenstand 11 in der Reihenfolge ihrer Clientenzählwertgröße verarbeitet werden, darin besteht, die Zuordnung der Knoten in Arbeitsgruppen in Schritt 45 so weit wie möglich zu maximieren. Insbesondere ist es durch ein späteres Verarbeiten der weniger verbundenen lokalen Server möglich, daß dieselben bereits in die Arbeitsgruppe eines stärker verbundenen lokalen Servers eingeschlossen wurden. In diesem Fall ist nicht nur der weniger verbundene lokale Server in der gleichen Arbeitsgruppe wie der stärker verbundene lokale Server eingeschlossen, sondern auch Clientenknoten des weniger verbundenen lokalen Servers, die gut mit dem weniger verbundenen lokalen Server verbunden sind, werden in die Arbeitsgruppe des stärker verbundenen lokalen Servers eingeschlossen.
Fig. 10 ist ein Flußdiagramm des Plazieren-von-Server- Programm-Gegenstandes 13, der in Schritt 44 des Bewegungsvorschläge-Programms 11 ausgeführt wird. Das Plazieren-von- Server-Programm 13 erhält die Identität eines bestimmten Zielservers und fährt dann fort, um zu testen, ob sich ein Bewegen des Servers zu einem unterschiedlichen Segment lohnt. Als ein vorbereitender Schritt jedoch führt das Programm 13 zuerst einen Test durch, um zu sehen, ob der. Server tatsächlich eine aufspannende Vorrichtung (Brücke/Router/Gateway) ist, die nicht ohne weiteres bewegt werden kann, und zu Zwecken des Programms 13 als fest behandelt werden sollte (siehe Schritt 50). Tatsächlich kann Schritt 50 in eine Prüfung einer Liste von Knoten verallgemeinert werden, die aus einem bestimmten Grund als unbewegbar spezifiziert sind.
Das Plazieren-von-Server-Programm 13 fährt als nächstes mit Schritt 51 fort, an dem das optimale Segment für den betrachteten Server sichergestellt wird. Bei dem vorliegenden Beispiel wird dies durch ein Suchen nach dem minimalen Gesamtsprungzählwert zwischen dem Server und seinen Clientenknoten durchgeführt, was auf der Basis funktioniert, daß ein Client auf dem gleichen Segment wie, der Server einen "Null"-Sprungzählwert hat, wohingegen ein Client auf einem unterschiedlichen Segment einen "Eins"-Sprungzählwert hat (unabhängig davon, durch wie viele Segmente tatsächlich auf dem physischen Netz gesprungen werden muß, um eine Meldung von dem Server an diesen Clienten weiterzuleiten). So ist der Server angenommenermaßen wiederum auf jedem Logiksegment angeordnet und der entsprechende Sprungzählwert wird berechnet. Der Segmentort, der den minimalen Sprungzählwert erzeugt, wird dann als das optimale Segment für den betrachteten Server identifiziert.
Es ist zu erkennen, daß andere Maße als die einfache Sprungzählwertmessung, die oben beschrieben wurde, zum Bestimmen des optimalen Segmentes verwendet werden können. Geeignete Maße sind die, die für jeden Ort des Servers empfindlich gegenüber der Zwischensegmentkomponente des Verkehrs zwischen dem Zielserver und seinen Clienten sind. So wäre z. B. ein weiteres geeignetes Maß das Zwischenseg mentverkehrsvolumen in Paketen/Rahmen/Bytes, die für jede Position des Servers erzeugt werden.
Sobald der optimale Segmentort für den Zielserver bestimmt wurde, wird eine Prüfung in Schritt 52 hinsichtlich dessen durchgeführt, ob sich dieses Segment von dem gegenwärtigen Segment des Zielsegmentes unterscheidet. Wenn diese Segmente die gleichen sind, endet das Programm 13. Unter der Annahme jedoch, daß das optimale Segment sich von dem gegenwärtigen Segment für den Server unterscheidet, wird Schritt 53 ausgeführt, bei dem eine Prüfung hinsichtlich dessen durchgeführt wird, ob der Zielserver bereits fest als ein Clientenknoten in einer Arbeitsgruppe ist, die hinsichtlich eines früher betrachteten Servers erzeugt wurde. Wie bereits oben erklärt wurde, ist es möglich, daß ein Server als ein Client gut mit einem besser verbundenen Server verbunden ist und deshalb fest in der Arbeitsgruppe letzteren ist. In diesem Fall wird der weniger gut verbundene Server als unbewegbar betrachtet, wobei das Programm 13 beendet wird, ohne daß ein Bewegungsvorschlag für den Server gemacht wird.
Vorausgesetzt, daß der Zielserver nicht fest als ein Client in der Arbeitsgruppe eines anderen Servers ist, wird Schritt 54 des Plazieren-von-Server-Programms 13 ausgeführt, um einen Bewegungsvorschlag zu der Knotenbewegungsliste 25 hinzuzufügen. Dieser Vorschlag identifiziert den betroffenen Server, sein gegenwärtiges Segment und das vorgeschlagene neue Segment. Die vorgeschlagene Bewegung wird zeitweilig auch angenommenermaßen durch eine geeignete Modifizierung des Servers und Segmentdatenstrukturen ausgeführt, um anzuzeigen, daß der Server sich nun auf dem gerade identifizierten optimalen Segment befindet. Danach endet das Programm 13.
Fig. 11 ist ein Flußdiagramm eines Plazieren-von-Client- Programm-Gegenstandes 14, der in Schritt 46 des Bewegungsvorschläge-Programms 11 ausgeführt wird. Das Programm 14 wird für jeden Clientenknoten des Zielservers ausgeführt, der während einer gegenwärtigen Iteration des Bewegungsvorschläge-Programms 11 betrachtet wird.
Die ersten beiden Schritte 60 und 61 des Programms 14 prüfen, ob der betrachtete Clientenknoten bereits fest in einer Arbeitsgruppe ist, bzw. ob er eine Vorrichtung ist (oder andernfalls allgemeiner unbewegbar), wobei in beiden Fällen der Clientenknoten als unbewegbar betrachtet und das Programm 14 beendet wird.
Vorausgesetzt jedoch, daß der betrachtete Clientenknoten nicht unbewegbar ist, wird ein Test als nächstes in Schritt 62 ausgeführt, um zu sehen, ob der Clientenknoten gut mit dem betroffenen Server verbunden ist. In diesem Zusammenhang bedeutet "gut verbunden", daß das Verbindungsmaß des Clientenknotens mit dem Server mehr als 50% des Gesamtverbindungsmaßes des Knotens dieses Clientes ist (durch Verkehrsvolumina gemessen). Es ist ersichtlich, daß eine bestimmte Abweichung der 50%-Zahl insbesondere in. einer Aufwärtsrichtung möglich ist. Wenn der Clientenknoten nicht gut mit seinem Server verbunden ist, wird es für den Clientenknoten nicht als geeignet betrachtet, zu dem gleichen Segment wie der Server bewegt zu werden, wobei das Programm 14 endet. Wenn jedoch der Clientenknoten gut mit dem betrachteten Server verbunden ist, wird der Clientenknoten zu der Arbeitsgruppe des Servers hinzugefügt und die Identität des Ziels wird in die Datenstruktur des Clientenknotens eingegeben, was den Server als den primären Server für den Clientenknoten identifiziert (Schritt 63). Danach wird in Schritt 64 eine Prüfung hinsichtlich dessen durchgeführt, ob sich das Segment des Clienten von dem Segment des Servers unterscheidet, wobei, falls dies der Fall ist, Schritt 65 ausgeführt wird, um einen Bewegungsvorschlag in die Knotenbewegungsliste 25 hinzuzufügen, der vorschlägt, daß der Clientenknoten zu dem Segment des Servers bewegt wird. Eine Ausführung von Schritt 65 beinhaltet auch ein zeitweiliges Bewegen des Clientenknotens zu dem Segment des Ser vers durch ein Aktualisieren des betroffenen Clientenknotens und der betroffenen Segmentdatenstrukturen.
Nach der Beschreibung der Operation des Bewegungsvorschlägeprogramms 11 und seiner zugeordneten Programmgegenstände 13 und 14 wird nun der Aufteilungsvorschlag- Programm-Gegenstand 12 mit seinen zugeordneten Programmgegenständen 15, 16 und 17 betrachtet.
Das Aufteilungsvorschläge-Programm 12 betrachtet wiederum jedes Logiksegment, um zu entscheiden, ob es von Vorteil wäre, eines der Segmente in zwei aufzuteilen. Fig. 12 stellt eine Situation dar, die aus den exemplarischen Verkehrsdaten genommen ist, wobei ein Logiksegment, in diesem Fall das Segment X2, in zwei Segmente aufgeteilt wird (hier entsprechend Gruppierungen basierend um Lokalserverknoten N6 und N7).
Das Aufteilungsvorschlag-Programm 12 startet von der Basis der Knotengruppierungen, die in der Arbeitsgruppenliste 26 durch das Bewegungsvorschläge-Programm 11 gebildet wurden. Die Arbeitsgruppen jedoch, die in der Liste 26 aufgezeichnet sind, sind nicht unmittelbar verwendbar, um eine Entscheidung hinsichtlich einer Segmentaufteilung durchzuführen, da jede derartige Arbeitsgruppe Knoten von mehr, als einem Segment enthalten kann und zusätzlich nicht alle Netzknoten in den Arbeitsgruppen enthalten sind (nur die Knoten, die gut mit Serverknoten verbunden sind, wurden durch das Programm 11 eingeschlossen).
Bezugnehmend auf Fig. 13 beinhaltet der erste Schritt 70 des Aufteilungsvorschlag-Programms 12 ein Prüfen dessen, ob es Arbeitsgruppen in der Arbeitsgruppenliste 26 gibt. Wenn keine derartige Arbeitsgruppen existieren, wird das Programm 12 beendet, ohne daß Segmentaufteilungsvorschläge gemacht wurden. Allgemein gibt es jedoch mehrere Arbeitsgruppen in der Arbeitsgruppenliste 26, wobei in diesem Fall das Programm 12 mit Schritt 71 fortfährt, in dem der Ab schneiden-von-Arbeitsgruppe-Programm-Gegenstand 15 ausgeführt wird. Der Zweck des Abschneiden-von-Arbeitsgruppe- Programms 15 besteht darin, jede Arbeitsgruppe so abzuschneiden, daß sie auf nur ein Segment bezogen ist und nur Knoten auf diesem Segment umfaßt, deren Verbindungsmaß durch Knoten auf dem Segment zu dem Server, hinsichtlich dessen die Arbeitsgruppe in Schritt 45 aus Programm 11 erzeugt wurde, zurückverfolgt werden kann. Insbesondere entfernt das Programm 15 jeden Knoten aus der Arbeitsgruppe, der nicht auf dem gleichen Logiksegment wie die Arbeitsgruppe ist, und außerdem jeden Knoten, dessen Einschluß in die Arbeitsgruppe entweder direkt oder indirekt ein Ergebnis der ursprünglichen Einschließung eines Knotens ist, der nicht auf dem Logiksegment der Arbeitsgruppe ist. Sobald die Arbeitsgruppen abgeschnitten wurden, wird in eine Schleifenstruktur, die einen Schleifenmechanismus basierend auf den Schritten 72 und 73 aufweist, zum Aufgreifen jedes Segmentes und Ausführen von Verarbeitungsschritten 74 bis 77 eingetreten. Insbesondere wird in Schritt 72 das erste oder nächste Segment in der Liste von Segmenten anvisiert, wobei Schritt 73 prüft, ob das Ende der Liste noch nicht erreicht wurde (falls dies doch der Fall ist, endet das Programm 12).
Für jedes Logiksegment werden die Schritte 74 bis 77 ausgeführt. In Schritt 74 wird eine Sammlung "WGCLTN"'. aus allen Arbeitsgruppen in der Liste 26 gebildet, die relevant für das gegenwärtige Zielsegment sind. Schritt 75 prüft, ob es mehr als eine Arbeitsgruppe in der Sammlung WGCLTN gibt. Falls dies nicht der Fall ist, wird angenommen, daß es sich nicht lohnt, das Logiksegment aufzuteilen, wobei die Verarbeitung zu dem Beginn der Schleife zurückkehrt, um das nächste Segment aufzunehmen. Unter der Annahme jedoch, daß es zumindest zwei Arbeitsgruppen in WGCLTN gibt, fährt das Programm 12 mit Schritt 76 fort, in dem der Zusammenführen- von-Arbeitsgruppen-Programm-Gegenstand 16 ausgeführt wird, was dazu führt, daß alle Knoten auf dem betrachteten Logik segment Arbeitsgruppen zugeordnet werden und die Anzahl der Arbeitsgruppen auf nur zwei reduziert wird.
Danach führt Schritt 77 den Aufteilungsentscheidung- Programm-Gegenstand 17 aus, um zu entscheiden, ob es sich lohnt, das betrachtete Logiksegment entsprechend der endgültigen beiden Arbeitsgruppen, die durch Schritt 76 erzeugt wurden, aufzuteilen. Ein positiver Aufteilungsvorschlag wird in die Segmentaufteilungsliste 27 eingegeben, wobei jeder Eintrag das betroffene Segment und die beiden Gruppierungen von Knotenidentifiziert, in die eine Unterteilung des Segments vorgeschlagen wird.
Fig. 14 ist ein Flußdiagramm des Abschneiden-von- Arbeitsgruppen-Programm-Gegenstandes 15. Dieses Programm 15 weist grundlegend eine Doppelschleifenstruktur auf, durch die Verarbeitungsschritte 85 bis 87 auf jeden Bestandteilsknoten jeder Arbeitsgruppe in Arbeitsgruppenliste 26 angewendet werden. Insbesondere sind die Schritte 80 und 81 Schleifensteuerungsschritte, die bewirken, daß das Programm 15 jede Arbeitsgruppe in der Liste 26 der Reihe nach untersucht, bis alle Arbeitsgruppen untersucht wurden. Für jede neue untersuchte Arbeitsgruppe wird eine Liste "entfernt" in Schritt 82 initialisiert. Danach wird in eine innere Schleifenstruktur eingetreten, bei der jeder Knoten der gegenwärtigen Arbeitsgruppe der Reihe nach betrachtet wird. Ein Fortschreiten nach unten durch die Bestandteilsknoten einer Arbeitsgruppe hängt jedoch davon ab, ob ein Verarbeitungsschritt 86 hinsichtlich eines Knotens ausgeführt wird oder nicht, wobei, falls dies der Fall ist, dieser Knoten aus der Arbeitsgruppe entfernt und in die Entfernt-Liste gegeben wird und die Verarbeitung der Arbeitsgruppenknoten wieder bei Null beginnt. Im Gegensatz dazu geht, wenn Schritt 86 nicht hinsichtlich eines bestimmten Knotens ausgeführt wird, ein Fortschreiten nach unten entlang der Knoten der betrachteten Arbeitsgruppe weiter.
Insbesondere nimmt, nachdem die Liste Entfernt in Schritt 82 initialisiert wurde, Schritt 83 den ersten Bestandteilsknoten der Zielarbeitsgruppe, wobei Schritt 84 prüft, ob es einen derartigen Knoten gibt (falls dies nicht der Fall ist, zeigt dies an, daß alle Knoten in einer Arbeitsgruppe verarbeitet wurden, wobei eine Verarbeitung zu Schritt 80 zurückkehrt, um eine neue Arbeitsgruppe aufzugreifen). Schritt 85 wird dann hinsichtlich des ersten Knotens ausgeführt, wobei dieser Schritt einfach ein Test hinsichtlich dessen ist, ob der betroffenen Knoten auf dem gleichen Segment ist wie die Arbeitsgruppe. Wenn der Zielknoten nicht auf dem gleichen Segment wie eine Arbeitsgruppe ist, wird Schritt 86 ausgeführt, um den Zielknoten aus der Arbeitsgruppe zu entfernern und denselben in die Entfernt- Liste zu geben. Danach kehrt die Verarbeitung zu Schritt 85 zurück, d. h. die gleiche Arbeitsgruppe wird wieder aufgegriffen und ihr erster neuer Knoten gefunden. Andererseits wird, wenn in Schritt 85 herausgefunden wird, daß sich der Zielknoten auf dem gleichen Segment wie die Arbeitsgruppe befindet, Schritt 87 ausgeführt, um sicherzustellen, ob der Primärserver des Zielknotens in der Entfernt-Liste ist, wobei dies, natürlich Bezug nehmend auf den ersten Knoten, der für eine Arbeitsgruppe untersucht wird, nicht der Fall ist. Ein negatives Ergebnis in Schritt 87 führt zu einer Ausführung von Schritt 88, um den Zielknoten zu dem nächsten Knoten in der Arbeitsgruppe fortzubewegen und die Verarbeitung zu Schritt 84 zurückkehren zu lassen. Die Verarbeitung fährt auf diese Weise fort, wobei Knoten aus der gegenwärtigen Arbeitsgruppe in Schritt 86 abgeschnitten werden, wenn sie sich entweder nicht auf dem gleichen Segment wie die Arbeitsgruppe befinden (in Schritt. 85 getestet) oder der Primärserver des betroffenen Knotens in der Entfernt-Liste ist (in Schritt. 87 getestet). Wenn ein Knoten abgeschnitten wird, wird eine Verarbeitung der Knoten der Arbeitsgruppe reinitialisiert.
Fig. 15 ist ein Flußdiagramm des Zusammenführen von- Arbeitsgruppen-Programm-Gegenstandes 16, der in Schritt 26 des Aufteilungsvorschläge-Programms 12 ausgeführt wird. Beim Start dieses Programmgegenstandes können unter Umständen viele der Knoten des betroffenen Segmentes noch nicht den für das Segment relevanten Arbeitsgruppen zugeteilt sein. Der erste Schritt 90 des Programms 16 dient deshalb dazu, einen Satz "AUN" aller aktiver, nicht zugeteilter Knoten auf dem Segment von Interesse zu erzeugen, d. h. Knoten mit zugeordnetem Verkehr, die sich noch nicht in einer Arbeitsgruppe des Segmentes befinden.
Sobald die Liste AUN erzeugt wurde, fährt das Programm 16 mit Schritt 91 fort, bei dem dasselbe eine jeweilige neue Arbeitsgruppe für jeden Knoten in AUN erzeugt, wobei jede derartige Arbeitsgruppe in der Sammlung WGCLTN von Arbeitsgruppen für das betroffene Segment protokolliert wird.
Ein iterativer Prozeß wird dann ausgeführt, um die Anzahl von Arbeitsgruppen in der Sammlung WGCLTN auf zwei zu reduzieren, wobei Schritt 92 ein Test für diesen Zustand ist. Der Prozeß des Reduzierens der Anzahl von Arbeitsgruppen auf zwei wird durch ein Zusammenführen von Arbeitsgruppen bewirkt. So wird in Schritt 93 die kleinste Arbeitsgruppe in WGCLTN entweder hinsichtlich der Anzahl von betroffenen Knoten oder des Verkehrsvolumens, das zwischen diesen Knoten fließt, identifiziert. Sobald diese kleinste Arbeitsgruppe identifiziert ist, wird dieselbe aus der Sammlung WGCLTN entfernt und in die Arbeitsgruppe in WGCLTN hinzugefügt, mit der dieselbe das größte Verbindungsmaß aufweist (angesichts Knoten oder Verkehrsvolumen), wobei diese Hinzufügung in Schritt 94 ausgeführt wird.
Sobald die Anzahl von Arbeitsgruppe in WGCLTN auf zwei reduziert wurde, wird das Zusammenführen on-Arbeitgruppen- Programm 16 beendet.
Fig. 16 ist ein Flußdiagramm des Aufteilungsentscheidung- Programm-Gegenstandes 17, der in Schritt 77 des Aufteilungsvorschläge-Programms 12 ausgeführt wird. Das Programm 17 trifft eine Entscheidung hinsichtlich dessen, ob ein Logikelement in zwei derartige Segmente entsprechend den beiden verbleibenden Arbeitsgruppen in der WGCLTN-Liste für das betroffene Segment aufgeteilt werden sollte. Diese Entscheidung wird auf der Basis von Verkehrsflüssen in und zwischen den beiden Arbeitsgruppen durchgeführt (zur Bequemlichkeit werden diese Arbeitsgruppen als WG1 und WG2 bezeichnet). In dem Flußdiagramm aus Fig. 16 wird angenommen, daß der Verkehrsfluß in Bytes ausgewertet wird, wobei dies natürlich von der Verkehrsmaßeinheit abhängt, die bei dem Verkehrsmaß verwendet wird, das in dem Gesamtverkehrsfeld der Verkehrselemente 22 gesammelt wird.
In Schritt 95 aus Programm 17 wird der interne Verkehr jeder Arbeitsgruppe WG1 und WG2 bestimmt, wobei dieser interne Verkehr der Gesamtverkehr zwischen Knoten innerhalb jeder Arbeitsgruppe ist. Auch in Schritt 95 wird eine. Bestimmung des Verbindungsmaßes zwischen den Arbeitsgruppen WG1 und WG2 durchgeführt. Wie bereits angezeigt wurde, werden die internen Verkehrsmaße und das Arbeitsgruppenverbindungsmaß in dem Flußdiagramm aus Fig. 16 alle hinsichtlich Bytes bestimmt.
Als nächstes wird Schritt 96 ausgeführt, um den gesamten internen Verkehr für das betroffene Segment, wieder in Bytes, zu bestimmen.
Auf der Basis der vorangegangenen Maße wird dann Schritt 97 ausgeführt, um zu bestimmen, ob sich das Aufteilen des betroffenen Segmentes in zwei lohnt. Die für diese Entscheidung verwendeten Kriterien sind, praktisch und können abhängig von den Umständen variieren. Im wesentlichen jedoch lohnt sich ein Aufteilen eines Logiksegmentes nur, wenn das Gesamtverbindungsmaß zwischen den beiden Arbeitsgruppen WG1 und WG2 nicht zu groß ist. Es macht auch wenig Sinn, ein Segment aufzuteilen, wenn eine oder beide der Arbeitsgruppen nur eine kleine Menge des Gesamtverkehrs für das Segment darstellen, oder wenn die Anzahl von Knoten in einer der Arbeitsgruppen klein ist. Schritt 97 gibt Details über das Vorangegangene, indem drei Tests ausgeführt werden und eine Aufteilung des Segmentes nur empfohlen wird, wenn alle drei Tests bestanden sind. Diese drei Tests sind wie folgt:
- ein Test, daß der interne Verkehr, in Bytes, für jede der Arbeitsgruppen WG1 und WG2 größer als ein vorbestimmter Prozentsatz (z. B. 20%) des gesamten internen Verkehrs des Segmentes ist;
- ein Test, daß die. Anzahl von Knoten in jeder der Arbeitsgruppen WG1 und WG2 größer als eine vorbestimmte Schwelle ist (z. B. 4);
- ein Test hinsichtlich dessen, ob das Verbindungsmaß zwischen WG1 und WG2 kleiner als der interne Verkehr für jede Arbeitsgruppe von WG1 und WG2 ist.
Wie bereits zu Beginn erwähnt wurde, ist die obige Beschreibung eine Implementierung des Netzanalyseverfahrens der Erfindung für den Fall, bei dem die Verkehrsdaten keine Anzeige der Server-/Clientenrolle eines Knotens enthalten, der Daten sendet/empfängt. Derartige Informationen können jedoch verfügbar sein. So umfaßt z. B. für Meldungen, die unter dem TCP-Protokoll gesandt werden, jede Meldung eine Quellenknotenportzahl und eine Zielknotenportzahl. Bestimmte Portzahlen sind für die häufigeren Dienste im vorhinein zugewiesen. Portzahlen, die auf diese Weise im vorhinein zugewiesen sind, sind als "bekannte Ports" bekannt. Eine Maschine z. B., die einen Hostnamenserverdienst liefert, tut dies bei einem bekannten Port mit einer Portzahl von 42, wobei ähnlich ein X.400-Maildienst auf einer bekannten Portanzahl 103 bereitgestellt wird.
Allgemein agiert, wenn ein Knoten einen Endpunkt verwendet, der kein bekannter Port ist und mit einem bekannten Port eines anderen Knotens kommuniziert, dieser letztere Knoten als ein Server, während der zuerst erwähnte Knoten als ein Client agiert. Ein Prüfen der Portzahlen der Quellen- und Zielknoten ermöglicht es deshalb, daß eine Einschätzung hinsichtlich der jeweiligen Rollen durchgeführt wird, die durch die Knoten durchgeführt werden.
Es tritt jedoch häufig auf, daß beide Knoten miteinander durch bekannte Ports kommunizieren. In diesem Fall kann entweder keine Beurteilung hinsichtlich dessen durchgeführt werden, welcher Knoten als ein Server und welcher als ein Client agiert, oder es muß auf eine bestimmte Priorisierung bekannter Portzahlen zurückgegriffen werden, um eine Beurteilung hinsichtlich der Rollen der betroffenen Knoten durchzuführen. Natürlich hilft, wenn kein Knoten ein bekanntes Port verwendet, ein Betrachten der Portzahlen nicht beim Bestimmen der Rollen der betroffenen Knoten.
Fig. 4B stellt eine Form einer Verkehrselementdatenstruktur dar, die geeignet zur Verwendung in dem Fall ist, bei dem bekannten Portzahlen verwendet werden, um Knotenrollen zu identifizieren. Die ersten beiden Felder der Datenstruktur aus Fig. 4 enthalten die Identitäten des kommunizierenden Knotenpaars. Das vierte und das fünfte Feld werden verwendet, um zu spezifizieren, welcher der identifizierten Knoten als ein Client agiert und welcher als ein Server agiert (wenn derartige Informationen hergeleitet wurden). Das fünfte Feld identifiziert das betrachtete Protokoll, wobei diesbezüglich die Verwendung des bekannten Ports nicht auf das TCP-Protokoll beschränkt ist und identische oder ähnliche Mechanismen in anderen Protokollen arbeiten. Das sechste Feld der Datenstruktur aus Fig. 4B wird verwendet, um die Portzahl für einen Knoten zu halten, der identifiziert wurde, um als ein Server zu agieren, wobei diese Portzahl natürlich eine bekannte Portzahl ist. Das siebte und das achte Feld enthalten Verkehrsvolumendaten in den beiden Richtungen eines Verkehrsflusses zwischen dem Paar betroffener Knoten. Das letzte Feld ist das Aktiviertes- Flag-Feld, das bereits oben Bezug nehmend auf die Datenstruktur aus Fig. 4A beschrieben wurde.
Es ist zu erkennen, daß, während es in dem Fall, in dem keine Rolleninformationen gesammelt werden, nur notwendig war, ein Verkehrselement für jede Paarung von Knoten zu liefern, wobei derartige Informationen von dem Verkehr hergeleitet werden, zumindest drei Verkehrselemente hinsichtlich jeder Knotenpaarung erforderlich sind, nämlich ein Element zum Aufzeichnen eines Verkehrs hinsichtlich eines ersten der Knoten, der als ein Server agiert, ein zweites Element zur Aufzeichnung eines Verkehrs hinsichtlich eines anderen Knotens, der als ein Server agiert, und ein drittes Element zur Aufzeichnung eines Verkehrs hinsichtlich des Knotens, zu dem keine Zuteilung hinsichtlich einer Rolle gemacht werden konnte. Tatsächlich kann es zweckmäßig sein, ein jeweiliges Verkehrselement für jede Kombination eines bekannten Ports an einem Knoten, der mit einem nichtbekannten Port an dem anderen Knoten kommuniziert, zu liefern.
Die Knotenrolleninformationen, die auf die obige Weise gesammelt werden, sind insbesondere beim Identifizieren der globalen und lokalen Server nützlich, wobei dies die Operation ist, die durch das Extrahieren-von-Server-Programm 10 ausgeführt wird. Bei der Ausführung dieses letzteren Programms basieren die Einschätzungen hinsichtlich dessen, ob ein Knoten ein globaler oder ein lokaler Server ist, auf seinem Verkehrsverbindungsmaß, wenn er in einer Serverrolle im Gegensatz zu einer Clientenrolle agiert, wobei eine derartige Unterscheidung nun durch die Verwendung mehrerer Verkehrselemente für jede Knotenpaarung möglich ist. Insbesondere wird beim Einschätzen, ob ein Knoten als ein Server agiert, eine Referenz auf die Verkehrselemente gemacht, für die dieser Knoten als ein Server identifiziert wird. Tatsächlich wird allgemein außerdem eine Referenz auf die Verkehrselemente gemacht, bei denen die Rolle des betroffenen Knotens nicht definiert ist (anders ausgedrückt, die einzigen ignorierten Verkehrselemente sind die, für die der betroffene Knoten als ein Client identifiziert ist). Der Einschluß des Verkehrs, für den ein Server keine identifizierte Rolle aufweist, ist dahingehend konsistent mit der Beschreibung des Extrahieren-von-Servern-Programms aus Fig. 5, das oben angegeben ist, daß, wenn kein Verkehr vorhanden ist, der bekannte Port beinhaltet, in beiden Fällen das gleiche Ergebnis erhalten wird.
Es ist auch ersichtlich, daß, wenn der Verkehr, der einem Server zugeordnet ist, deaktiviert wird (z. B. in Schritt 35 aus Fig. 5), dies nur ein Deaktivieren der Verkehrselemente beinhaltet, für die der betroffene Knoten als ein Server identifiziert ist, oder für die keine Identifizierung gemacht wurde.
Ähnliche Betrachtungen treffen hinsichtlich dessen zu, wie die Rolleninformationen in Verbindung mit dem Bewegungsvorschläge-Programm 11 und dem Aufteilungsvorschläge-Programm 12 verwendet werden.
Verschiedene Modifizierungen an dem oben beschriebenen Netzanalyseverfahren sind natürlich möglich. So kann, obwohl das Verfahren hinsichtlich eines Netzes beschrieben wurde, das aus Unternetzen besteht, die durch Logiksegmente auf der Ebene 2 des Sieben-Schicht-OSI-Referenzmodells gebildet sind, das Verfahren auch auf Netze angewendet werden, bei denen die Unternetze andere Formen annehmen, z. B. Gruppierungen von Knoten, die durch Router/Gateways getrennt sind, die auf der Ebene 3 des Sieben-Schicht-OSI- Referenzmodells arbeiten.
Ferner können die drei Hauptanalyseaufgaben, die durch das Extrahieren-von-Servern-Programm 10, das Bewegungsvorschläge-Programm 11 und das Aufteilungsvorschläge-Programm 12 dargestellt werden, unabhängig betrieben werden, vorausgesetzt, daß geeignete Anfangsinformationen vorgesehen sind. So kann die Bewegungsvorschläge-Analyseaufgabe unabhängig von der Extrahieren-von-Servern-Aufgabe ausgeführt werden, vorausgesetzt, daß die Bewegungsvorschläge-Aufgabe mit einer Liste lokaler Server und ihrer Clienten und mit geeigneten Verkehrsdaten versehen ist. Ähnlich kann die Aufteilungsvorschläge-Aufgabe auch unabhängig von der Extrahieren-von-Servern-Aufgabe ausgeführt werden. Tatsächlich könnte die Aufteilungsvorschläge-Aufgabe unabhängig von der Bewegungsvorschlag-Aufgabe ausgeführt werden, vorausgesetzt, daß entweder gleichwertige Arbeitsgruppen- Informationen von anderer Stelle verfügbar gemacht werden oder der Betrieb der Aufteilungsvorschlag-Aufgabe modifiziert wurde, um Arbeitsgruppen selbst zu bilden. Zu diesem Zweck können Daten über einen Verkehr im Inneren des betroffenen Unternetzes analysiert werden, um Knoten auf dem Unternetz durch ein iteratives Verfahren in Arbeitsgruppen zu klassifizieren, das für jede Iteration folgende Schritte beinhaltet:
- Zuteilen des Knotens mit dem größten Verkehrsverbindungsmaß zu einer jeweiligen neuen Arbeitsgruppe als einen lokaler Server;
- weiteres Zuteilen der Knoten als Clientenknoten zu der gleichen Arbeitsgruppe, deren Verbindungsmaß zu dem Lokalserverknoten größer als ein vorbestimmter Abschnitt (z. B. 50%) des Gesamtverbindungsmaßes des betroffenen Knotens ist, und
- Modifizieren der Verkehrsdaten durch ein Entfernen von Verkehr, der der neuen Arbeitsgruppe zugeordnet ist.
Diese Arbeitsgruppen können dann auf eine Weise auf zwei reduziert werden, die bereits beschrieben wurde, wobei dann eine Entscheidung hinsichtlich dessen durchgeführt werden kann, ob das Unternetz nützlicherweise aufgeteilt werden kann.

Claims

1. Ein Netzanalyseverfahren zur Verwendung hinsichtlich eines Netzes des Typs, der eine Mehrzahl von Unternetzen (X1-X4) aufweist, wobei jedes derselben eine Mehrzahl von Knoten (N) aufweist, wobei das Verfahren folgenden Schritt aufweist:

(1) Überwachen des Netzes, um Verkehrsdaten (22) zu sammeln und zu speichern, die das Verbindungsmaß zwischen Knoten anzeigen, beurteilt nach einem Verkehr zwischen denselben;

und gekennzeichnet durch folgenden Schritt:

(2) Verarbeiten der Verkehrsdaten (22) durch ein Entfernen eines Verkehrs, der Knoten zugeordnet ist, die identifiziert sind, um als Globalserver (N1-N3) zu agieren, und Verwenden des verbleibenden Verkehrs, um Knoten zu identifizieren, die als lokale Server (N4-N7) agieren.

2. Ein Verfahren gemäß Anspruch 1, bei dem der Schritt (2) ein Untersuchen der Verkehrsdaten (22) beinhaltet, um einen in Frage kommenden globalen Server (N1-N3) unter den Knoten (N) zu identifizieren, wobei ein in Frage kommender globaler Server ein Knoten ist, dessen Verbindungsmaß zu einem der Unternetze kleiner als ein erster vorbestimmter Abschnitt seines Gesamtverbindungsmaßes zu allen Knoten ist, und

- wenn der in Frage kommende globale Server (N1-N3) identifiziert wird, Identifizieren des in Frage kommenden globalen Servers mit dem höchsten Gesamtverbindungsmaß, Entfernen seines zugeordne ten Verkehrs aus den Verkehrsdaten (22) und Zurückkehren zu dem Start von Schritt (2), um den Schritt unter Verwendung der so modifizierten Verkehrsdaten zu wiederholen;

- wenn kein derartiger in Frage kommender globaler Server identifiziert wird, Untersuchen der Verkehrsdaten (22), um einen in Frage kommenden lokalen Server (N4-N7) unter den Knoten zu identifizieren, wobei ein in Frage kommender lokaler Server ein Knoten ist, für den für das Unternetz mit dem höchsten Verbindungsmaß zu demselben dieses Verbindungsmaß gleich oder größer als ein zweiter vorbestimmter Abschnitt des Gesamtverbindungsmaßes dieses in Frage kommenden lokalen Servers ist, und

- wenn der in Frage kommende lokale Server (N4-N7) identifiziert wird, Identifizieren des in Frage kommenden lokalen Servers mit dem höchsten Verbindungsmaß, Aufzeichnen dieses Kandidaten als einen lokalen Server, Entfernen seines zugeordneten Verkehrs aus den Verkehrsdaten (22) und Zurückkehren zu dem Start von Schritt (2), um den Schritt unter Verwendung der so modifizierten Verkehrsdaten zu wiederholen;

- wenn kein in Frage kommender lokaler Server identifiziert wird, Verlassen von Schritt (2).

3. Ein Verfahren gemäß Anspruch 2, bei dem der erste und der zweite vorbestimmte Abschnitt jeweils eine Hälfte ist.

4. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Verkehrsdaten als Verkehrselemente (22) gespeichert werden, die jeweils eine Anzeige eines Verkehrs zwischen einem Paar der Knoten liefern, wobei eine Modifizierung der Verkehrsdaten, um einen Verkehr zu entfernen, der dem Server zugeordnet ist, durch ein Markieren der relevanten Verkehrselemente, die gegenwärtig deaktiviert sind, bewirkt wird.

5. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Verbindungsmaß eines Knotens (N) zu anderen zugeordneten Knoten hinsichtlich zumindest eines der folgenden Merkmale gemessen wird:

- Anzahl zugeordneter Knoten;

- Anzahl von Rahmen, die bei dem Verkehr mit den zugeordneten Knoten betroffen sind;

- Anzahl von Bytes, die bei dem Verkehr mit den zugeordneten Knoten betroffen sind.

6. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem in Schritt (1) aus Anspruch 1 das Überwachen des Netzes auf eine derartige Weise ausgeführt wird, um es zu ermöglichen, daß Rolleninformationen gesammelt werden, die anzeigen, ob ein Knoten (N) in einer Server- oder einer Clientenrolle hinsichtlich einzelner Verkehrsgegenstände wirkt, die demselben zugeordnet sind, wobei die Identifizierung eines Knoten als einen globalen oder lokalen Server in Schritt (2) ohne Bezugnahme auf einen Verkehr bewirkt wird, für den der Knoten als ein Client wirkt, was durch die Rolleninformationen angezeigt ist.

7. Ein Verfahren gemäß Anspruch 6, bei dem die Rolleninformationen auf der Basis des bekannten Portstatus der Knotenendpunkte abgeleitet werden, die einem Verkehr zugeordnet sind, der zwischen einem Paar von Knoten (N) verläuft, wobei ein Knoten des Paars identifiziert wird, um in einer Serverrolle zu agieren, wobei der andere Knoten identifiziert wird, um in einer Clientenrolle zu agieren, wobei der Endpunkt für den einen Knoten ein bekannter Port ist, während der andere Punkt dies nicht ist.

8. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem für zumindest einen der lokalen Server (N5), die in Schritt (2) aus Anspruch 1 identifiziert werden, eine Bestimmung hinsichtlich des optimalen Unternetzes (X4) für diesen lokalen Server durchgeführt wird, wobei die Bestimmung wiederum ein angenommenes Anordnen des betroffenen lokalen Servers (N5) auf jedem Unternetz (X1-X4) und ein Auswerten einer vorbestimmten Optimaler-Ort-Funktion für jeden derartigen Ort des lokalen Servers umfaßt, die ein Maß des Verkehrs zwischen Unternetzen liefert, die dem lokalen Server an seinem gegenwärtigen angenommenen Ort zugeordnet, wären, wobei eine derartige Bestimmung ferner ein Identifizieren des Unternetzes (X4) als das optimale Unternetz umfaßt, für das eine Auswertung der Funktion ein Minimum für den Verkehr zwischen Unternetzen anzeigt.

9. Ein Verfahren gemäß Anspruch 8, bei dem die Optimaler- Ort-Funktion eine Zählung von Knoten ist, die ein Verbindungsmaß mit dem betroffenen lokalen Server (N5) aufweisen und auf anderen Unternetzen als dem angeordnet sind, das dem gegenwärtigen angenommenen Ort des lokalen Servers entspricht.

10. Ein Verfahren gemäß Anspruch 8 oder 9, bei dem für den lokalen Server (N5), dessen optimales Unternetz (X4) bestimmt wurde, eine Entscheidung auch hinsichtlich dessen durchgeführt wird, ob, wenn dieser lokale Server (N5) in seinem optimalen Unternetz (X4) angeordnet ist, jeder der Knoten, zu dem er ein Verbindungsmaß als ein Server aufweist, zu dem optimalen Unternetz (X4) bewegt werden sollte, wobei diese Bestimmung ein Testen für jeden Knoten umfaßt, ob das Verbindungsmaß zwischen diesem Knoten und dem lokalen Server (N5) die Hälfte oder mehr des Gesamtverbindungsmaßes dieses Knotens ist.

11. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem für die Gruppe lokaler Server (N4-N7), die in Schritt (2) aus Anspruch 1 identifiziert werden, jeder lokale Server wiederum in der Reihenfolge eines absteigenden Verbindungsmaßes genommen wird, wobei für jeden derartigen Server:

(i) eine jeweilige Arbeitsgruppe (26) für denselben erzeugt wird, es sei denn, der betroffene lokale Server wurde bereits einer anderen Arbeitsgruppe zugeordnet, die hinsichtlich eines lokalen Servers, der weiter oben in der Reihenfolge ist, erzeugt wurde,

(ii) wenn die jeweilige Arbeitsgruppe (26) in (i) für den betroffenen lokalen Server erzeugt wurde, der Server dieser Arbeitsgruppe zugewiesen wird, und

(iii) jeder Knoten, dessen Verbindungsmaß mit dem lokalen Server zumindest die Hälfte des Gesamtverbindungsmaßes dieses Knotens ist, der gleichen Arbeitsgruppe wie der lokale Server zugeordnet wird.

12. Ein Verfahren gemäß Anspruch 11, bei dem für zumindest das eine Unternetz (X2) eine Bestimmung durchgeführt wird, ob es sich lohnt, das Unternetz in zwei Unternetze aufzuteilen, wobei diese Bestimmung folgende Schritte beinhaltet:

(a) Abschneiden der oder jeder Arbeitsgruppe, die hinsichtlich eines lokalen Servers (N6, N7) erzeugt wurde, der sich auf dem Unternetz von Interesse (X2) befindet, durch ein Entfernen jedes Knotens, der sich auf einem unterschiedlichen Unternetz als dem von Interesse befindet, und jedes Knotens, dessen Einschluß in die Arbeitsgruppe direkt oder indirekt auf seiner Zuordnung mit einem Knoten beruht, der auf einem unterschiedlichen Unternetz als dem von. Interesse angeordnet ist, aus der Arbeitsgruppe;

(b) Bilden einer jeweiligen weiteren Arbeitsgruppe für jeden Knoten des Unternetzes von Interesse (X2), wobei dieser Knoten noch nicht in einer Arbeitsgruppe ist, die dem Unternetz zugeordnet ist;

(c) Zusammenführen der Arbeitsgruppen, die dem Unternetz von Interesse zugeordnet sind, bis nur zwei derartige Arbeitsgruppen verbleiben; und

(d) Entscheiden, ob es sich lohnt, das Unternetz (X2) aufzuteilen, indem die Verkehrsmenge zwischen den beiden Arbeitsgruppen, die nach Schritt (c) verbleiben, mit dem Gesamtverkehr verglichen wird, der jeder derartigen Arbeitsgruppe zugeordnet ist.

13. Ein Verfahren gemäß Anspruch 12, bei dem Schritt (c) einen iterativen Prozeß beinhaltet, bei dem während jeder Iteration die Arbeitsgruppe mit der kleinsten Menge zugeordnetem Verkehr mit der Arbeitsgruppe zusammengeführt wird, mit der dieselbe das größte Verbindungsmaß aufweist.

14. Ein Verfahren gemäß einem der Ansprüche 8 bis 13, bei dem die Operationen, die in diesen Ansprüchen spezifi ziert sind, unter Verwendung der Verkehrsdaten ausgeführt werden, die in Schritt (1) aus Anspruch 1 gesammelt wurden, wobei jedoch der gesamte globale Serververkehr entfernt ist.