DE60103215T2 - Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System - Google Patents

Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System Download PDF

Info

Publication number
DE60103215T2
DE60103215T2 DE60103215T DE60103215T DE60103215T2 DE 60103215 T2 DE60103215 T2 DE 60103215T2 DE 60103215 T DE60103215 T DE 60103215T DE 60103215 T DE60103215 T DE 60103215T DE 60103215 T2 DE60103215 T2 DE 60103215T2
Authority
DE
Germany
Prior art keywords
identifiers
selected block
block
requesting node
centralized server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60103215T
Other languages
English (en)
Other versions
DE60103215D1 (de
Inventor
Kenneth W. Shirriff
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60103215D1 publication Critical patent/DE60103215D1/de
Publication of DE60103215T2 publication Critical patent/DE60103215T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166IP fragmentation; TCP segmentation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5061Pools of addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015Access to distributed or replicated servers, e.g. using brokers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • HINTERGRUND
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft verteilte Computersysteme. Genauer betrifft die vorliegende Erfindung ein Verfahren und eine Vorrichtung für die Verwendung eines zentralisierten Servers, um die Zuweisung von Kennungen von mehreren Knoten in einem verteilten Computersystem zu koordinieren.
  • Verwandte Technik
  • Computer verwenden gemeinhin TCP/IP (Übertragungssteuerungs-Protokoll/Internet-Protokoll), um Daten in Form von Paketen über ein Netz zu schicken. Jedoch kann je nach der Struktur des Netzes zwischen dem Sender und dem Empfänger ein Datenpaket bei einem Verfahren, das als "Fragmentierung" bekannt ist, in kleinere Teile, die so genannten "Fragmente", gebrochen werden. Der Empfänger muss dann diese Fragmente wieder zusammenfügen, um das ursprüngliche Paket wiederherzustellen. Es ist zu beachten, dass Fragmente in einer beliebigen Reihenfolge ankommen können und dass Fragmente mehrmals oder möglicherweise nicht ankommen können.
  • Zur Unterstützung einer Fragmentierung enthält ein IP-Paket ein 16-Bit-Kennungsfeld, das jedes Paket, das der Sender abschickt, eindeutig identifiziert. Das Kennungsfeld wird verwendet, um Fragmente zu identifizieren, die wieder zu einem einzigen Paket zusammengefügt werden sollen, und um sicherzustellen, dass nicht Fragmente von zwei verschiedenen Paketen miteinander kombiniert werden.
  • Um dieses Ziel zu erreichen muss das Kennungsfeld für ein bestimmtes Sender-Empfängerpaar eindeutig sein, wobei für den Zeitraum, in dem das zugehörige Paket in dem System aktiv sein könnte, ein besonderes Protokoll verwendet wird. Statt die Kennungsnummern für jeden Empfänger gesondert zu verfolgen, verwendet der Sender typisch sequentielle Kennfeldwerte für jedes gesendete Paket unter der Annahme, dass die Zeit zwischen wiederholten Verwendungen eines Kennfeldwertes länger als die Lebensdauer eines Pakets in dem Netz sein wird.
  • Diese einfache Zuweisung von IP-Kennungsnummern könnte nicht gut funktionieren, wenn der Sender nicht ein einzelner Computer, sondern stattdessen ein Cluster von Computern ist. Ein Cluster könnte viele Computer enthalten, die zusammenarbeiten, um Netzanforderungen abzuwickeln.
  • Für viele Zwecke ist es wünschenswert, dass das Cluster gegenüber den Netz-Clients als eine einzige Maschine in Erscheinung tritt. Dazu wird allen abgehenden Datenpaketen eine IP-Adresse gegeben. Bei einer derartigen Architektur genügt es nicht länger, jedem Knoten sequentielle IP-Kennungsnummern zuzuweisen, da zwei Knoten die gleiche Nummer nahezu gleichzeitig verwenden könnten, wodurch die Wahrscheinlichkeit verstümmelter Daten zunimmt, wenn ein Empfänger versucht, die Fragmente wieder zu einem Paket zu kombinieren.
  • Eine Alternative ist, dass ein Knoten in dem Cluster die gesamte TCP/IP-Verarbeitung einschließlich der Zuordnung von Kennungsnummern übernimmt. Dadurch wird jedoch ein Engpass an diesem Knoten geschaffen. Die Leistungsfähigkeit des Clusters wird verbessert, wenn alle Knoten parallel die TCP/IP-Verarbeitung durchführen können.
  • Eine Lösung dieses Problems ist die Aufteilung der Kennungsnummern unter den Serverknoten in dem Cluster. Beispielsweise kann ein erster Knoten die Nummern 1 bis 100 verwenden, ein zweiter Knoten kann die Nummern 101 bis 200 verwenden, usw. Diese Lösung stellt jedoch nicht sicher, dass die Kennungsnummern eindeutig sind, da nur 16 Bits für die Kennungsnummern zur Verfügung stehen. Folglich werden die Kennungsnummern zu schnell wiederverwendet. Wenn es beispielsweise 100 Server gibt, würde jeder Server nur 216/100 = 655 Werte erhalten und diese Werte kurz hintereinander wiederholt verwenden, wodurch sich die Wahrscheinlichkeit von unrichtig kombinierten Fragmenten erhöht.
  • Eine weitere Alternative ist, dass jeder Knoten in dem Cluster eine eindeutige Kennungsnummer für jedes Paket von einem zentralisierten Server erhält. Dies führt jedoch zu einem Leistungsengpass, da jedes abgehende Paket um die Zeit verzögert ist, die erforderlich ist, um die nächste Nummer von dem zentralisierten Server abzurufen. Außerdem ist es wahrscheinlich, dass der zentralisierte Server mit der Verarbeitung von Anforderungen von vielen Knoten überlastet wird.
  • Es wird also ein Verfahren und eine Vorrichtung für eine effiziente Zuweisung von Paket-Kennungen zu Paketen von mehreren Knoten in einem verteilten Computersystem gebraucht.
  • WO-95/32 463 (Ontos Inc.) beschreibt ein System für eine globale Erzeugung eindeutiger Objektkennungen in einer verteilten, objektorientierten Datenbank. Eine Server-Verarbeitung liefert global eindeutige Kennungen für Objekte überall in dem Netz in Reaktion auf Anforderungen, die von Client-Verarbeitungen gesendet werden, wovon jede Transaktionen gegenüber der Datenbank zu laufen haben kann. Der Server sendet eine Reihe von global eindeutigen Kennungen an eine anfordernde Client-Verarbeitung, aus welcher die Client-Verarbeitung dann den Objekten, die sie erzeugt, lokal eindeutige Kennungen zuweisen kann. Ungenutzte Abschnitte der reservierten Reihen können zur späteren Wiederverwendung durch dieselben oder andere Client-Verarbeitungen an den Server zurückgegeben werden.
  • EP-A-0 605 339 (IBM Corporation) ist repräsentativ für den Stand der Technik, der einem Cluster von Computern ermöglicht, gegenüber Hostcomputern außerhalb des Clusters in einem Computernetz als ein einziger Computer in Erscheinung zu treten. Ein Hostcomputer kommuniziert nur mit einer Überleiteinrichtung, um auf Zielknoten und -verarbeitungen innerhalb des Clusters zuzugreifen. Es ist ein Verfahren beschrieben, um Nachrichten so über die Clustergrenze oder Überleiteinrichtung zu leiten, dass Arbeitsanforderungen von außerhalb des Clusters gleichmäßig unter den Computerknoten in dem Cluster verteilt werden können, indem die Nachrichtenkopfinformationen geändert werden. Eine Beschreibung der TCP/IP-Paketfragmentierung des Standes der Technik und von Verfahren zum Wiederzusammenfügen ist ebenfalls enthalten.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung schafft ein Verfahren, eine Vorrichtung und ein Computerprogramm gemäß den nachfolgenden Ansprüchen, die einen zentralisierten Server verwenden, um die Zuweisung von Kennungen in einem verteilten Computersystem zu koordinieren. Das System arbeitet so, dass es eine Anforderung für einen Block von Kennungen bei dem zentralisierten Server von einem anfordernden Knoten in dem verteilten Computersystem empfängt. In Reaktion auf diese Anforderung wählt das System einen Block von Kennungen aus einem globalen Verbund von Kennungen aus und markiert dann den globalen Verbund von Kennungen, um anzugeben, dass der ausgewählte Block von Kennungen zugewiesen worden ist. Das System sendet den ausgewählten Block von Kennungen zu dem anfordernden Knoten, um dem anfordernden Knoten zu ermöglichen, Kennungen. aus dem ausgewählten Block von Kennungen zuzuweisen, ohne mit dem zentralisierten Server kommunizieren zu müssen.
  • In einer Ausführungsform der vorliegenden Erfindung markiert das System bei Empfang eines Hinweises, dass der ausgewählte Block von Kennungen von dem anfordernden Knoten nicht mehr länger verwendet wird, den globalen Verbund von Kennungen, um anzugeben, dass der ausgewählte Block von Kennungen nicht länger zugewiesen ist.
  • In einer Ausführungsform der vorliegenden Erfindung empfängt das System eine nachfolgende Anforderung für einen nachfolgenden Block von Kennungen von dem anfordernden Knoten zusammen mit dem Hinweis, dass der ausgewählte Block von Kennungen nicht länger verwendet wird.
  • In einer Ausführungsform der vorliegenden Erfindung stellt der zentralisierte Server sicher, dass, wenn der ausgewählte Block von Kennungen zu dem zentralisierten Server zurückgeleitet wird, der ausgewählte Block von Kennungen nicht sofort wieder dem anfordernden Knoten zugewiesen wird. Dies wird durch Markieren des ausgewählten Blocks von Kennungen in dem globalen Verbund mit einer Kennung für den anfordernden Knoten verwirklicht.
  • In einer Ausführungsform der vorliegenden Erfindung enthält der ausgewählte Block von Kennungen eine Internet-Protokoll-Kennung (IP-Kennung), die in einen Kopfsatz eines IP-Pakets einzubauen ist, um die Wiederzusammenfügung des IP-Pakets zu erleichtern.
  • In einer Ausführungsform der vorliegenden Erfindung ist das verteilte Computersystem ein Cluster-Computersystem, das mehrere Knoten enthält, die dieselbe IP-Adresse gemeinsam nutzen.
  • In einer Ausführungsform der vorliegenden Erfindung ist der globale Verbund von Kennungen als verknüpfte Liste, die Blöcke von Kennungen enthält, strukturiert.
  • In einer Ausführungsform der vorliegenden Erfindung enthält der ausgewählte Block von Kennungen eine Menge aufeinander folgender Kennungsnummern.
  • In einer weiteren Ausführungsform der vorliegenden Erfindung enthält der ausgewählte Block von Kennungen eine Menge von nicht aufeinander folgenden Kennungsnummern.
  • In einer Ausführungsform der vorliegenden Erfindung umfasst das Senden des ausgewählten Blocks von Kennungen an den anfordernden Knoten das Senden eines Spezifizierers für einen Bereich aufeinander folgender Kennungsnummern, wobei der Spezifizierer einen Startwert für den Bereich und einen Endwert für den Bereich enthält.
  • Folglich weist die vorliegende Erfindung nicht das Prablem auf, dass der zentralisierte Server überlastet wird, da der zentralisierte Server für jeden Block von Kennungen nur einmal kontaktiert werden muss. Dies verringert die Belastung des zentralisierten Servers erheblich. Außerdem wird dadurch die Zeit verkürzt, die erforderlich ist, um ein Paket zu senden, da der zentralisierte Server nicht kontaktiert werden muss, bevor das Paket gesendet wird.
  • Außerdem weist die vorliegende Erfindung nicht das Problem auf, dass in dem Fall, in dem nur eine kleine Anzahl von Knoten die Kennungsnummern rasch einsetzt, die IP-Kennungsnummern zu schnell aufgebraucht sind. Wenn beispielsweise ein Cluster von 100 Knoten zwei Knoten hat, die laufend Netzdienste verrichten, würde die oben beschriebene Aufteilungslösung nur 655 Paketkennungen für jeden Knoten liefern, bevor die Nummern wiederverwendet werden. Hingegen würde die Blocklösung 216/2 = 32768 Paketkennungen für jeden momentan aktiven Knoten liefern. Es ist zu beachten, dass es typisch nicht möglich ist, im Voraus zu bestimmen, welche Knoten Netzaktivitäten entfalten werden. Folglich müssen bei der Aufteilungslösung die Kennungsnummern unter allen 100 Knoten und nicht nur zwischen den zwei momentan aktiven Knoten aufgeteilt werden.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • 1 veranschaulicht ein Cluster-Computersystem, das gemäß einer Ausführungsform der vorliegenden Erfindung an Client-Computersysteme gekoppelt ist;
  • 2 veranschaulicht den inneren Aufbau eines Schnittstellen-/Server-Knotens und zweier Serverknoten in einem Cluster-Computersystem gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3 veranschaulicht einen zentralisierten Server und einen lokalen Mechanismus zum Zuweisen von Kennungen gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist ein Ablaufplan, der die Funktion eines fokalen Mechanismus zum Zuweisen von Kennungen gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 5 ist ein Ablaufplan, der zeigt, wie der zentralisierte Server Blöcke von Kennungen gemäß einer Ausführungsform der vorliegenden Erfindung zuweist;
  • 6 veranschaulicht die Struktur eines Blocks von Kennungen gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 7 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus Kennungen anfordert und zurückgibt;
  • 8 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus eine Kennung aus einem Block von Kennungen entnimmt;
  • 9 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus eine Kennung an einen Block von Kennungen zurückgibt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgende Beschreibung wird präsentiert, um einen Fachmann auf dem Gebiet in die Lage zu versetzen, die Erfindung nachzuvollziehen und anzuwenden, wobei sie im Kontext einer besonderen Anwendung und ihrer Erfordernisse gegeben wird. Einem Fachmann auf dem Gebiet werden verschiedene Modifikationen der offenbarten Ausführungsformen ohne weiteres offensichtlich sein, und die allgemeinen Prinzipien, die hier definiert sind, können auf andere Ausführungsformen und Anwendungen übertragen werden, ohne von der Idee und vom Geltungsbereich der vorliegenden Erfindung abzukommen. Folglich soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt sein, sondern ihr soll der weiteste Geltungsbereich, der mit den hier offenbarten Prinzipien und Merkmalen verträglich ist, gewährt werden.
  • Die in dieser ausführlichen Beschreibung angegebenen Datenstrukturen und Codes sind typisch auf einem computerlesbaren Speichermedium gespeichert, das jede Vorrichtung oder jedes Medium sein kann, die bzw. das Code und/oder Daten für die Verwendung durch ein Computersystem speichern kann. Dies umfasst, ohne jedoch hierauf beschränkt zu sein, magnetische und optische Speichervorrichtungen wie etwa Plattenlaufwerke, Magnetbänder, CDs (Compactdiscs) und DVDs (Digitale Videodiscs) und Computerbefehlssignale, die in einem Übertragungsmedium verkörpert sind (mit oder ohne eine Trägerwelle, auf welche die Signale moduliert sind). Beispielsweise kann das Übertragungsmedium ein Kommunikationsnetz wie etwa das Internet einbeziehen.
  • Cluster-Computersystem
  • 1 veranschaulicht ein Cluster-Computersystem 100, das gemäß einer Ausführungsform der vorliegenden Erfindung an Clients 121 bis 123 gekoppelt ist. Die Clients 121 bis 123 können jeden Knoten eines Netzes 120 umfassen, Rechenkapazität und ein Mechanismus, um über das Netz 120 zu kommunizieren, eingeschlossen. Die Clients 121 bis 123 kommunizieren mit dem Cluster-Computersystem 100, indem sie Pakete zu dem Cluster-Computersystem 100 senden, um Dienste von dem Cluster-Computersystem anzufordern.
  • Das Netz 120 kann einen beliebigen Typ eines drahtgebundenen oder drahtlosen Kommunikationskanals enthalten, der in der Lage ist, Verarbeitungsknoten zusammenzuschalten. Dies umfasst, ohne jedoch hierauf beschränkt zu sein, ein lokales Netz, ein Weitverkehrsnetz oder eine Kombination von Netzen. In einer Ausführungsform der vorliegenden Erfindung bezieht das Netz 120 das Internet ein.
  • Das Cluster-Computersystem 100 umfasst eine Menge von Knoten, die durch private Querverbindungen 119 miteinander gekoppelt sind. Diese Knoten umfassen sowohl Serverknoten 102 und 104, als auch einen Schnittstellenknoten/ Serverknoten 103.
  • Die Knoten 102 bis 104 sind mittels privater Querverbindungen 119 miteinander gekoppelt, die im Allgemeinen einen beliebigen Typ von Kommunikationsmechanismus umfassen können. In einer Ausführungsform der vorliegenden Erfindung hält sich die private Querverbindung 19 an die Ethernet-Norm. In einer weiteren Ausführungsform hält sich die private Querverbindung 119 an die Norm des Scalable Coherent Interconnect (SCI-Norm). Es ist zu beachten, dass die vorliegende Erfindung nicht auf Systeme beschränkt werden soll, die Ethernet- oder SCI-Normen verwenden. Im Allgemeinen kann die vorliegende Erfindung mit jedem beliebigen Netzprotokoll angewendet werden.
  • Es ist zu beachten, dass der Schnittstellenknoten 103 eine oder mehrere gemeinsame IP-Adressen für das Cluster-Computersystem beherbergen kann. Außerdem ist zu beachten, dass in dem Cluster-Computersystem 100 mehr als ein Knoten als Schnittstellenknoten für einen bestimmten Dienst agieren kann. Dies ermöglicht, dass ein Ausweichschnittstellenknoten die Aufgabe eines Schnittstellenknotens, der ausfällt, übernimmt.
  • Es ist zu beachten, dass die Knoten 102 bis 104 in dem Cluster-Computersystem 100 skalierbare Dienste liefern können, wobei zusätzliche Verarbeitungsbetriebsmittel eingesetzt werden können, um einen Dienst zu liefern, wenn die Nachfrage für den Dienst zunimmt. Aus der Sicht der Clients 121 bis 123 verhält sich jeder skalierbare Dienst wie ein einziges logisches Objekt. Außerdem ist zu beachten, dass die Clients 121 bis 123 über eine Übertragungssteuerungs-Protokoll-Verbindung (TCP-Verbindung, TCP: Transmission Control Protocol) oder über eine Benutzer-Datenpaket-Protokoll-Sitzung (UDP-Sitzung, UDP: User Datagram Protocol) mit dem Cluster-Computersystem 100 kommunizieren können. (Es ist zu beachten, dass mit der vorliegenden Erfindung auch andere Protokolle verwendet werden können.)
  • Das Cluster-Computersystem 100 arbeitet im Allgemeinen wie folgt: Wenn am Schnittstellenknoten 103 Pakete von den Clients 121 bis 123 eintreffen, wird auf der Grundlage der Zieladresse in dem Paket ein Dienst ausgewählt. Als Nächstes wird für das Paket auf der Grundlage sowohl der Herkunftsadresse des Pakets als auch der Zieladresse des Pakets eine Diensteinstanz ausgewählt. Es ist zu beachten, dass das System sicherstellt, dass Pakete, die zu derselben TCP-Verbindung oder UDP-Instanz gehören, zu derselben Diensteinstanz gesendet werden. Schließlich wird das Paket zu der ausgewählten Diensteinstanz gesendet.
  • Außerdem ist zu beachten, dass die Serverknoten 102 bis 104 Mechanismen für eine Zuweisung von Kennungen enthalten. Genauer beherbergt der Serverknoten 104 einen zentralisierten Server für Kennungen 130 und lokale Mechanismen für Kennungen 131, der Serverknoten 102 beherbergt einen lokalen Mechanismus, um Kennungen 132 zuzuweisen, und der Serverknoten 103 beherbergt einen lokalen Mechanismus, um Kennungen 133 zuzuweisen. Während des Betriebs fordern die lokalen Mechanismen 132 bis 133 Blöcke von Kennungen von dem zentralisierten Server 130 an. In Reaktion auf diese Anforderungen weist der zentralisierte Server 130 den lokalen Mechanismen 132 und 133 Blöcke von Kennungen aus einem globalen Verbund von Kennungen 302 zu (siehe 3). Nachdem die lokalen Mechanismen 132 und 133 das Zuweisen von Kennungen für einen Block beendet haben, wird der Block an den zentralisierten Server 130 zurückgegeben, und der zentralisierte Server 130 gibt den Block an den globalen Verbund 302 zurück. Dieses Verfahren ist weiter unten mit Bezug auf 3 bis 9 ausführlicher beschrieben.
  • Es ist zu beachten, dass die Blockgröße in Abhängigkeit von der Anzahl der Knoten in dem Cluster verändert werden kann. Um zu ermöglichen, dass jeder Knoten in dem Cluster gleichzeitig einen Block besitzt, muss es wenigstens so viele Blöcke wie Knoten geben. Folglich müssen die Blöcke kleiner als die Anzahl der Kennungen dividiert durch die Anzahl der Knoten in dem Cluster sein. Es ist jedoch zu beachten, dass eine geringere Blockgröße den Vorteil hat, dass sich der Zeitraum zwischen Wiederverwendungen der Kennungen vergrößert, da die Kennungen nicht an einen Knoten gebunden sein werden, der sie sehr langsam verwendet. Andererseits, wenn die Blöcke kleiner sind, müssen sie häufiger angefordert werden, wodurch sich der Systemverwaltungsaufwand erhöht. Folglich hängt die optimale Blockgröße von den spezifischen Parametern eines spezifischen Systems und der Anwendung ab.
  • Außerdem ist zu beachten, dass, obwohl die vorliegende Erfindung im Kontext einer spezifischen Cluster-Computersystemarchitektur beschrieben ist, die vorliegende Erfindung allgemein auf jedes System angewendet werden kann, in dem mehr als eine Einheit eine Menge von Kennungen zuweist.
  • Innerer Aufbau von Schnittstellenknoten und Serverknoten
  • 2 veranschaulicht den inneren Aufbau des Schnittstellenknotens 103 sowie der Server-Knoten 102 und 104 in dem Cluster-Computersystem 100 gemäß einer Ausführungsform der vorliegenden Erfindung. Der Client 121 sendet Pakete zu dem Cluster-Computersystem 100, um einen Dienst von dem Cluster-Computersystem 100 zu erhalten. Diese Pakete gelangen in die öffentliche Schnittstelle 221 in dem Schnittstellenknoten 103 in dem Cluster-Computersystem 100. Die öffentliche Schnittstelle 221 kann jeden Schnittstellentyp aufweisen, der in der Lage ist, Pakete von dem Netz 120 zu empfangen.
  • Wenn über die öffentliche Schnittstelle 221 Pakete an dem Schnittstellenknoten 103 ankommen, durchlaufen sie den Netzverbund-Multiplexer 218 des Clusters. Der Netzverbund-Multiplexer 218 des Clusters leitet die Pakete auf der Grundlage von Belastungsausgleichsentscheidungen und anderen Überlegungen zu verschiedenen Knoten innerhalb des Cluster-Computersystems 100 weiter.
  • Die Pakete werden von dem Schnittstellenknoten 103 zu anderen Knoten in dem Cluster-Computersystem 100, einschließlich der Serverknoten 102 und 104, über private Schnittstellen 224 und 225 weitergeleitet. Die privaten Schnittstellen 224 und 225 können eine beliebige Schnittstelle enthalten, die Kommunikationen zwischen den Knoten innerhalb des Cluster-Computersystems 100 abwickeln kann. Beispielsweise können Pakete von der privaten Schnittstelle 224 zu der privaten Schnittstelle 226 am Serverknoten 104 oder von der privaten Schnittstelle 225 zu der privaten Schnittstelle 228 am Serverknoten 102 weitergeleitet werden. Es ist zu beachten, dass die privaten Schnittstellen 224 und 225 keine Kommunikationen mit Einheiten außerhalb des Cluster-Computersystems 100 abwickeln.
  • In einigen Ausführungsformen der vorliegenden Erfindung benutzen die private Schnittstelle 224 (und 225) und die öffentliche Schnittstelle 221 teilweise gemeinsam dieselbe Kommunikations-Hardware und senden Nachrichten teilweise über dieselben physischen Datenwege. In einigen dieser Ausführungsformen können die private Schnittstelle 224 und die öffentliche Schnittstelle 221 auch teilweise dieselbe Schnittstellensoftware gemeinsam benutzen. Folglich brauchen die private Schnittstelle 224 und die öffentliche Schnittstelle 221 keine verschiedenen Kommunikationsmechanismen darzustellen. Deshalb kann die Unterscheidung zwischen privater Schnittstelle 224 und öffentlicher Schnittstelle 221 lediglich eine Unterscheidung darin sein, ob die Kommunikationen mit einer Einheit außerhalb des Cluster-Computersystems 100 oder mit einer Einheit innerhalb des Cluster-Computersystems 100 erfolgen.
  • Die in die Serverknoten 102 und 104 gelangenden Pakete passieren die IP-Stapelspeicher 214 bzw. 216. Der Netzverbund-Multiplexer 218 des Clusters kann die Pakete auch zu dem IP-Stapelspeicher 215 in dem Schnittstellenknoten/ Serverknoten 103 senden, da der Knoten 103 ebenfalls in der Lage ist, als Server zu agieren. Im Serverknoten 102 gelangen die Pakete durch den IP-Stapelspeicher 214 in das TCP-Modul 206, das TCP-Verbindungen unterstützt, oder in das UDP-Modul 210, das UDP-Sitzungen unterstützt. Genauso gelangen am Schnittstellenknoten/ Serverknoten 103 Pakete durch den IP-Stapelspeicher 215 in das TCP-Modul 207 oder in das UDP-Modul 211. Am Serverknoten 104 gelangen Pakete durch den IP-Stapelspeicher 216 in das TCP-Modul 208 oder in das UDP-Modul 212. Anschließend werden die Pakete jeweils von den Diensteinstanzen 201 bis 203 an den Knoten 102 bis 104 verarbeitet.
  • Es ist zu beachten, dass Rückmeldungen für die Serverknoten 102 und 104 nicht demselben Weg folgen. Rückmeldungen werden vom Serverknoten 102 durch den IP-Stapelspeicher 214, über die öffentliche Schnittstelle 220 zu dem Client 121 weitergegeben. Genauso werden Rückmeldungen vom Serverknoten 104 durch den IP-Stapelspeicher 216, über die öffentliche Schnittstelle 222 an den Client 121 weitergegeben. Dies befreit den Schnittstellenknoten 103 von der Abwicklung von Rückmeldungsverkehr.
  • Bei Web-Server-Anwendungen (und einigen anderen Anwendungen) kann dieser Rückmeldemechanismus für einen Belastungsausgleich hinsichtlich des Rückwärtsverkehrs sorgen. Es ist zu beachten, dass Web-Server typisch Navigationsbefehle von einem Client empfangen und in Reaktion darauf große Mengen von Website-Inhalten (wie etwa graphische Darstellungen) an den Client zurücksenden. Bei diesen Anwendungen ist es vorteilhaft, den Rückwärtsverkehr über mehrere Rückwärtswege zu verteilen, um die große Menge an Rückwärtsverkehr abzuwickeln.
  • Zentralisierter Server und lokaler Mechanismus, um Kennungen zuzuweisen
  • 3 zeigt genauer einen zentralisierten Server für Kennungen 130 sowie den lokalen Mechanismus, um die Kennungen 132 von 1 gemäß einer Ausführungsform der vorliegenden Erfindung zuzuweisen. Der zentralisierte Server 130 steht mit einem globalen Verbund von Kennungen 302 in Verbindung.
  • Der globale Verbund von Kennungen 302 verfolgt, welche Kennungen den lokalen Mechanismen 132 und 133 zugewiesen worden sind. In einer Ausführungsform der vorliegenden Erfindung umfasst der globale Verbund von Kennungen 302 eine Freiliste 304, die Blöcke von Kennungen 306 bis 308 enthält, die nicht zugeordnet worden sind. Obwohl in 3 der globale Verbund von Kennungen 302 als eine verkettete Liste organisiert ist, ist zu beachten, dass im Allgemeinen jeder Typ indizierender Struktur verwendet werden kann, um die Kennungen zu verfolgen. Außerdem ist zu beachten, dass die Blöcke von Kennungen 306 bis 308 Bereiche fortlaufender Kennungsnummern enthalten. Dadurch ist es möglich, nur zwei Werte für jeden Bereich, statt aller Nummern in jedem Bereich zu speichern. Beispielsweise kann ein Bereich aufeinander folgender Kennungen 3, 4, 5, 6, 7 als Endwerte (3, 7) oder als der erste Wert und eine Länge (3, 5) gespeichert werden.
  • Der zentralisierte Server 130 umfasst außerdem einem Empfangsmechanismus 312, einen Auswahlmechanismus 314, einen Markierungsmechanismus 316 und einen Sendemechanismus 318. Es ist zu beachten, dass jeder dieser Mechanismen softwaremäßig als Funktionen oder Verfahren implementiert sein kann. Der Empfangsmechanismus 312 empfängt eine Anforderung 324 für einen Block von Kennungen von dem lokalen Mechanismus 132. Die Anforderung 324 bewirkt, dass der Auswahlmechanismus 314 einen Block von Kennungen 320 aus dem globalen Verbund 302 auswählt, und der Markierungsmechanismus 316 markiert den globalen Verbund 302, um anzugeben, dass der Block von Kennungen 320 zugewiesen worden ist. Schließlich sendet der Sendemechanismus 318 den Block von Kennungen 320 zu dem lokalen Mechanismus 132.
  • Der lokale Mechanismus 132 weist nach Bedarf Kennungen vom Block 320 zu. Dabei benutzt der lokale Mechanismus 132 einen Zeiger 322, um auf die nächste Position (oder auf den nächsten Bereich) zu zeigen, von der (dem) eine Kennung zuzuweisen ist.
  • Verfahren der Zuweisung von Kennungen in dem lokalen Mechanismus
  • 4 ist ein Ablaufplan, der die Funktion eines lokalen Mechanismus zum Zuweisen von Kennungen 132 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Der lokale Mechanismus 132 startet mit dem Empfang eines IP-Pakets, das an einen entfernten Ort, wie etwa an den Client 121, zu senden ist (Schritt 402). Der lokale Mechanismus 132 ermittelt zuerst, ob er einen nicht leeren Block von Kennungen besitzt (Schritt 404). Wenn nicht, fordert der lokale Mechanismus 132 einen neuen Block von Kennungen von dem zentralisierten Server 130 an (Schritt 406) und empfängt dann einen neuen Block von Kennungen 320 von dem zentralisierten Server 130 (Schritt 408).
  • Als Nächstes entnimmt der lokale Mechanismus 132 eine Kennung aus seinem Block von Kennungen 320 (Schritt 410) und sendet danach das IP-Paket mit der Kennung (Schritt 412). Wenn an diesem Punkt der Block von Kennungen 320 vollständig aufgebraucht ist, informiert der lokale Mechanismus den zentralisierten Server 130, damit der zentralisierte Server 130 den Block 320 in den globalen Verbund 302 zurückgeben kann (Schritt 414). In einer Ausführungsform der vorliegenden Erfindung fordert der lokale Mechanismus 132 zusätzlich einen neuen Block von Kennungen zu dem gleichen Zeitpunkt an, zu dem er den zentralisierten Server 130 darüber informiert, dass der lokale Mechanismus 132 den Block 320 abgearbeitet hat.
  • Verfahren der Zuweisung von Kennungen im zentralisierten Server
  • 5 ist ein Ablaufplan, der zeigt, wie der zentralisierte Server 130 Blöcke von Kennungen gemäß einer Ausführungsform der vorliegenden Erfindung zuweist. Bei Empfang einer Anforderung (Schritt 502) ermittelt der zentralisierte Server 130 zuerst, ob die Anforderung das Erhalten eines Blocks oder das Freigeben eines Blocks betrifft.
  • Wenn die Anforderung ist, einen Block zu erhalten, wählt der Server 130 einen Block von Kennungen 320 aus dem globalen Verbund von Kennungen 302 aus (Schritt 504) und markiert dann den globalen Verbund 302, um anzugeben, dass der ausgewählte Block von Kennungen 320 zugewiesen worden ist (Schritt 506). Dies kann möglicherweise das Aufzeichnen einer Kennungsnummer für den Anforderer in dem globalen Verbund 302 einschließen.) Der zentralisierte Server 130 sendet dann den ausgewählten Block von Kennungen 320 zu dem Knoten, der den Block anforderte (Schritt 508).
  • Wenn die Anforderung ist, einen Block freizugeben, markiert der zentralisierte Server 130 den globalen Verbund 302, um anzugeben, dass der ausgewählte Block 320 nicht länger zugewiesen ist (Schritt 514). Wenn diese Angabe außerdem eine Anforderung eines zusätzlichen Blocks von Kennungen enthält, wiederholt der zentralisierte Server 130 die Schritte 504, 506 und 508, um den zusätzlichen Block von Kennungen zu senden.
  • Es ist zu beachten, dass die Zeit zwischen wiederholten Verwendungen eines Blocks für den Fall, in dem ein Client 121 mit demselben Knoten 102 in dem Cluster-Computersystem 100 kommuniziert, verbessert werden kann. Beispielsweise kann das Cluster-Computersystem 100 ankommende Client-Anforderungen auf der Grundlage der IP-Adresse des Clients zu einem bestimmten Knoten leiten. In diesem Fall markiert der Schritt 506 außerdem jeden Block in dem globalen Verbund 302 mit einer Kennung für den Knoten, der den Block zuletzt verwendet hat (oder die Knoten, die den Block zuletzt verwendet haben). Wenn der zentralisierte Server im Schritt 504 einen Block von Kennungen auswählt, stellt der zentralisierte Server sicher, dass er einen Block auswählt, der zuletzt von einem anderen Knoten verwendet wurde.
  • Es ist zu beachten, dass eine Wiederverwendung von Nummern nur dann ein Problem ist, wenn eine Nummer im Zusammenhang mit einem Client verwendet wird, der die Nummer zuvor verwendet hat. Folglich werden durch Anwenden der oben beschriebenen Verbesserung die Nummern mit verschiedenen Clients verwendet, wodurch sich die Zeit zwischen möglichen Wiederverwendungen verlängert. Außerdem ist zu beachten, dass ein Block in dem globalen Verbund 302 entweder mit dem letzten Knoten, der ihn benutzte, oder mit einer Liste der letzten n Knoten, die ihn benutzten, markiert werden kann.
  • Zuweisung von Prozesskennungen
  • Die vorliegende Erfindung ist nicht nur auf die Zuweisung von IP-Paketkennungen, sondern auch auf andere Anwendungen in einem verteilten System anwendbar. Beispielsweise erfordert ein verteiltes System, das das Bild eines Einzelsystems liefert, für jeden Prozess in dem verteilten System eine eindeutige Prozesskennung (PID: Process Identifier). Wie bei IP-Sequenznummern könnte eine feste Aufteilung des Prozesskennungsraums nicht ausreichend viele Prozesskennungen (PIDs) für jeden Knoten lassen, da verschiedene Knoten einen verschiedenen Bedarf haben können. Auch kann der Systemverwaltungsaufwand, der am Kontaktieren eines zentralen Servers beteiligt ist, um jede PID zuzuweisen, zu hoch sein. Folglich kann die Technik der Zuweisung von Blöcken von Kennungen sowohl für die Zuweisung von Prozesskennungen als auch für die Zuweisung von IP-Paketkennungen vorteilhaft sein.
  • Eine Schwierigkeit bei der Zuweisung von PIDs ist, dass ein Knoten eine PID über einen langen Zeitraum benutzen kann, in dem die PID von einem anderen Knoten nicht benutzt werden kann. Dies hindert den zentralisierten Server 130 darin, Blöcke fester Größe mit aufeinander folgenden Kennungen zuzuweisen, da die fortdauernde Verwendung einer einzigen PID aus einem Block die Weiterverwendung des Blocks verhindert. Dieses Problem kann schließlich alle Blöcke binden.
  • Um dieses Problem zu lösen, kann die Erfindung wie folgt erweitert werden. Statt den zentralisierten Server 130 darüber zu informieren, dass er mit einem gesamten Block von aufeinander folgenden PIDs fertig ist, informiert der Knoten den zentralisierten Server 130 darüber, welche PIDs nicht länger im Gebrauch sind. Auch kann der zentralisierte Server 130, statt den anfordernden Knoten einen Block fester Größe aufeinander folgender PIDs zu liefern, einen variablen Block von PIDs liefern, der PIDs enthält, die von anderen Knoten nicht länger gebraucht werden.
  • In einigen Fällen ist es wünschenswert, den Umfang der PIDs aus Gründern der Anwenderfreundlichkeit möglichst gering zu halten. Dies kann durch Verwenden einer Teilmenge des möglichen Kennnummernbereichs erreicht werden, die erweitert werden kann, wenn zusätzliche PIDs erforderlich sind, und die zeitlichen Beschränkungen hinsichtlich der Wiederverwendung unterliegt.
  • 6 veranschaulicht die Struktur eines Blocks von Kennungen 320 gemäß einer Ausführungsform der vorliegenden Erfindung. Um den Speicherplatzbedarf zu verringern verfolgt der zentralisierte Server 130 freie PIDs als Sequenzen und übergibt anfordernden Knoten eine Menge von Sequenzen. Der Block von Kennungen 320 umfasst eine Verfügbarkeitsliste 600, die als verkettete Liste strukturiert ist, die Bereiche von Kennungen 1–10, 20–20, 25–99 und 103–700 enthält.
  • 7 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus 132 Kennungen anfordert und zurückgibt. Wenn die Verfügbarkeitsliste 600 leer ist, fordert der lokale Mechanismus 132 mehr Kennungen an (Schritt 702). Wenn andererseits die Verfügbarkeitsliste 600 zu lang wird (einen im Voraus definierten Schwellenwert überschreitet), gibt der lokale Mechanismus 132 Kennungen an den zentralisierten Server 130 zurück (Schritt 704). Wenn der lokale Mechanismus 132 einen Block von Kennungen an den zentralisierten Server 130 zurückgibt, wird die Liste von Bereichen in dem Block unter Verwendung wohl bekannter Techniken für die Verbindung von Bereichen von Nummern mit einer ähnlichen Liste in dem globalen Verbund 302 verbunden.
  • 8 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus 132 eine Kennung aus einem Block von Kennungen 320 entnimmt. Der lokale Mechanismus 132 erhält die erste Nummer aus dem ersten Bereich in der Verfügbarkeitsliste 600 (Schritt 802). Nachdem die Nummer abgerufen ist, entfernt der lokale Mechanismus 132, wenn der erste Bereich leer wird, den ersten Bereich von der Verfügbarkeitsliste 600 (Schritt 804).
  • 9 ist ein Ablaufplan, der zeigt, wie gemäß einer Ausführungsform der vorliegenden Erfindung ein lokaler Mechanismus 132 eine Kennung an einen Block von Kennungen zurückgibt: Der lokale Mechanismus 132 beginnt mit dem ersten Bereich. Der lokale Mechanismus 132 ermittelt zuerst, ob die Kennung vor dem Bereich auftritt (Schritt 902). Wenn ja, ermittelt der lokale Mechanismus 132, ob die Kennung unmittelbar vor dem Bereich auftritt (Schritt 904). Wenn ja, fügt der lokale Mechanismus 132 die Kennung an den Anfang des Bereichs an (Schritt 908). Wenn die Kennung dem Bereich nicht unmittelbar vorausgeht, fügt der Iokale Mechanismus 132 die Kennung vor dem Bereich in der Verfügbarkeitsliste 600 ein (Schritt 912).
  • Wenn die Kennung nicht vor dem Bereich ist, ermittelt der lokale Mechanismus 132, ob die Kennung unmittelbar hinter dem Bereich ist (Schritt 906). Wenn ja, ermittelt der lokale Mechanismus 132, ob die Kennung unmittelbar vor dem nächsten Bereich ist (Schritt 907). Wenn ja, führt der lokale Mechanismus 132 den Bereich mit dem nächsten Bereich zusammen (Schritt 908). Wenn die lokale Kennung nicht unmittelbar vor dem nächsten Bereich ist, fügt der lokale Mechanismus 132 die Kennung an das Ende des Bereichs an (Schritt 910).
  • Wenn die lokale Kennung nicht unmittelbar hinter dem Bereich ist, ermittelt der lokale Mechanismus 132, ob der Bereich der letzte Bereich in der Verfügbarkeitsliste 600 ist (Schritt 914). Wenn ja, fügt der lokale Mechanismus 132 die Kennung dem Ende der Verfügbarkeitsliste 600 hinzu (Schritt 916). Ansonsten geht der lokale Mechanismus 132 zum nächsten Bereich in der Verfügbarkeitsliste 600 weiter (Schritt 918) und kehrt zum Schritt 902 zurück, um das Verfahren zu wie derholen.
  • Die vorangehenden Darstellungen von Ausführungsformen der Erfindung sind nur zum Zweck der Veranschaulichung und Beschreibung gegeben worden.
  • Dementsprechend werden dem Fachmann auf dem Gebiet viele Modifikationen und Variationen offensichtlich sein. Außerdem soll die oben gegebene Darstellung die vorliegende Erfindung nicht einschränken. Der Schutzumfang der vorliegenden Erfindung ist durch die beigefügten Ansprüche definiert.

Claims (24)

  1. Verfahren für die Verwendung eines zentralisierten Servers (130), um die Zuweisung von Kennungen in einem verteilten Computersystem zu koordinieren, wobei das Verfahren umfasst: Empfangen einer Anforderung (502) für einen Block von Kennungen (306, 307, 308) bei dem zentralisierten Server in dem verteilten Computersystem; wobei die Anforderung von einem anfordernden Knoten in dem verteilten Computernetz empfangen wird; Auswählen (504) des Blocks von Kennungen aus einem globalen Verbund eindeutiger Kennungen (302) bei dem zentralisierten Server; Markieren (506) des globalen Verbundes von Kennungen, um anzugeben, dass der ausgewählte Block von Kennungen (320) zugewiesen worden ist; Senden (508) des ausgewählten Blocks von Kennungen zu dem anfordernden Knoten; und Zulassen, dass der anfordernde Knoten Kennungen von dem ausgewählten Block von Kennungen zuweist, ohne dass er mit dem zentralisierten Server kommunizieren muss; dadurch gekennzeichnet, dass das Markieren (506) des globalen Verbundes von Kennungen, um anzugeben, dass der ausgewählte Block von Kennungen (320) zugewiesen worden ist, das Markieren des ausgewählten Blocks von Kennungen mit einer Kennung für den anfordernden Knoten umfasst und dass beim Auswählen (504) des Blocks von Kennungen aus einem globalen Verbund eindeutiger Kennungen (302) bei dem zentralisierten Server der Server sicherstellt, dass er einen Block auswählt, der zuletzt von einem anderen Knoten verwendet wurde.
  2. Verfahren nach Anspruch 1, das ferner umfasst: Empfangen eines Hinweises, dass der ausgewählte Block von Kennungen (320) von dem anfordernden Knoten nicht mehr länger verwendet wird; und Markieren (514) des globalen Verbundes von Kennungen, um anzugeben, dass der ausgewählte Block von Kennungen nicht länger zugewiesen ist.
  3. Verfahren nach Anspruch 2, bei dem das Empfangen des Hinweises, dass der ausgewählte Block von Kennungen (320) nicht länger von dem anfordernden Knoten verwendet wird, das Empfangen einer nachfolgenden Anforderung für einen nachfolgenden Block von Kennungen von dem anfordernden Knoten umfasst.
  4. Verfahren nach Anspruch 1, bei dem der zentralisierte Server dann, wenn der ausgewählte Block von Kennungen (320) zu dem zentralisierten Server (130) zurückgeleitet und anschließend erneut zugewiesen wird, sicherstellt, dass der ausgewählte Block von Kennungen nicht sofort wieder dem anfordernden Knoten zugewiesen wird.
  5. Verfahren nach Anspruch 1, bei dem der ausgewählte Block von Kennungen (320) eine Internet-Protokoll-Kennung (IP-Kennung) enthält, die in einen Kopfsatz eines IP-Pakets einzubauen ist, um die Wiederzusammenfügung des IP-Pakets zu erleichtern.
  6. Verfahren nach Anspruch 5, bei dem das verteilte Computersystem ein Cluster-Computersystem (100) ist, das mehrere Knoten (102, 103, 104) enthält, die dieselbe IP-Adresse gemeinsam nutzen.
  7. Verfahren nach Anspruch 1, bei dem der ausgewählte Block von Kennungen (320) mehrere Prozesskennungen enthält, um Prozesse in dem verteilten Computersystem eindeutig zu identifizieren.
  8. Verfahren nach Anspruch 1, bei dem der globale Verbund von Kennungen (302) als verknüpfte Liste, die Blöcke von Kennungen enthält, strukturiert ist.
  9. Verfahren nach Anspruch 1, bei dem der ausgewählte Block von Kennungen (320) eine Menge aufeinander folgender Kennungsnummern enthält.
  10. Verfahren nach Anspruch 1, bei dem der ausgewählte Block von Kennungen (320) eine Menge (600) nicht aufeinander folgender Kennungsnummern enthält.
  11. Verfahren nach Anspruch 1, bei dem das Senden des ausgewählten Blocks von Kennungen (320) an den anfordernden Knoten das Senden (900) eines Spezifizierers für einen Bereich aufeinander folgender Kennungsnummern umfasst, wobei der Spezifizierer einen Startwert für den Bereich und einen Endwert für den Bereich enthält.
  12. Vorrichtung, die einen zentralisierten Server (130) verwendet, um die Zuweisung eindeutiger Kennungen in einem verteilten Computersystem zu koordinieren, und umfasst: einen Empfangsmechanismus (312), der so konfiguriert ist, dass er eine Anforderung für einen Block von Kennungen (306, 307, 308) bei dem zentralisierten Server in dem verteilten Computersystem empfängt; wobei die Anforderung von einem anfordernden Knoten in dem verteilten Computersystem empfangen wird; einen Auswahlmechanismus (314), der so konfiguriert ist, dass er den Block von Kennungen (320) von einem globalen Verbund eindeutiger Kennungen (302) bei dem zentralisierten Server auswählt; einen Markierungsmechanismus (316), der so konfiguriert ist, dass er den globalen Verbund von Kennungen markiert, um anzugeben, dass der ausgewählte Block von Kennungen zugewiesen worden ist; einen Sendemechanismus (318), der so konfiguriert ist, dass er den ausgewählten Block von Kennungen zu dem anfordernden Knoten sendet, so dass der anfordernde Knoten Kennungen von dem ausgewählten Block von Kennungen zuweisen kann, ohne mit dem zentralisierten Server kommunizieren zu müssen, dadurch gekennzeichnet, dass der Markierungsmechanismus weiterhin so konfiguriert ist, dass er den ausgewählten Block von Kennungen in dem globalen Verbund von Kennungen (302) mit einer Kennung für den anfordernden Knoten markiert; und dass der Auswahlmechanismus weiterhin so konfiguriert ist, dass sichergestellt ist, dass er einen Block auswählt, der zuletzt von einem anderen Knoten verwendet wurde.
  13. Vorrichtung nach Anspruch 12, bei der der Empfangsmechanismus (312) weiterhin so konfiguriert ist, dass er einen Hinweis empfängt, dass der ausgewählte Block von Kennungen (320) nicht länger von dem anfordernden Knoten verwendet wird; und bei der der Markierungsmechanismus (316) weiterhin so konfiguriert ist, dass er den globalen Verbund von Kennungen markiert, um anzugeben, dass der ausgewählte Block von Kennungen nicht länger zugewiesen ist.
  14. Vorrichtung nach Anspruch 13, bei der der Empfangsmechanismus (312) weiterhin so konfiguriert ist, dass er eine einzelne Nachricht empfängt, die sowohl den Hinweis, dass der ausgewählte Block von Kennungen von dem anfordernden Knoten nicht länger verwendet wird, als auch eine nachfolgende Anforderung für einen nachfolgenden Block von Kennungen von dem anfordernden Knoten enthält.
  15. Vorrichtung nach Anspruch 12, bei der der Auswahlmechanismus (314) so konfiguriert ist, dass dann, wenn der ausgewählte Block von Kennungen (320) zu dem zentralisierten Server (130) zurückgeleitet und anschließend erneut zugewiesen wird, sichergestellt ist, dass der ausgewählte Block von Kennungen nicht sofort wieder dem anfordernden Knoten zugewiesen wird.
  16. Vorrichtung nach Anspruch 12, bei der der ausgewählte Block von Kennungen (320) eine Internet-Protokoll-Kennung (IP-Kennung) enthält, die in einen Kopfsatz eines IP-Pakets einzubauen ist, um die Wiederzusammenfügung des IP-Pakets zu erleichtern.
  17. Vorrichtung nach Anspruch 16, bei der das verteilte Computersystem ein Cluster-Computersystem (100) ist, das mehrere Knoten (102, 103, 104) enthält, die dieselbe IP-Adresse gemeinsam nutzen.
  18. Vorrichtung nach Anspruch 12, bei der der ausgewählte Block von Kennungen (320) mehrere Prozesskennungen enthält, die Prozesse in dem verteilten Computersystem eindeutig identifizieren.
  19. Vorrichtung nach Anspruch 12, bei der der globale Verbund von Kennungen (302) als eine verknüpfte Liste, die Blöcke von Kennungen enthält, strukturiert ist.
  20. Vorrichtung nach Anspruch 12, bei der der ausgewählte Block von Kennungen (320) eine Menge aufeinander folgender Kennungsnummern enthält.
  21. Vorrichtung nach Anspruch 12, bei der der ausgewählte Block von Kennungen (320) eine Menge (600) nicht aufeinander folgender Kennungsnummern enthält.
  22. Vorrichtung nach Anspruch 12, bei der der Sendemechanismus (318) so konfiguriert ist, dass er den ausgewählten Block von Kennungen an den anfordernden Knoten sendet, indem er einen Spezifizierer für einen Bereich aufeinan der folgender Kennungsnummern sendet (900), wobei der Spezifizierer einen Startwert für den Bereich und einen Endwert für den Bereich enthält.
  23. Computerprogramm, das, wenn es in einem Computer oder in einem Computernetz ausgeführt wird, das Verfahren nach einem der Ansprüche 1 bis 11 ausführen kann.
  24. Computerprogramm nach Anspruch 23, wenn auf einem computerlesbaren Speichermedium verwirklicht.
DE60103215T 2000-08-01 2001-06-29 Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System Expired - Fee Related DE60103215T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/629,936 US6735220B1 (en) 2000-08-01 2000-08-01 Using a centralized server to coordinate assignment of identifiers in a distributed system
US629936 2000-08-01

Publications (2)

Publication Number Publication Date
DE60103215D1 DE60103215D1 (de) 2004-06-17
DE60103215T2 true DE60103215T2 (de) 2005-05-04

Family

ID=24525086

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60103215T Expired - Fee Related DE60103215T2 (de) 2000-08-01 2001-06-29 Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System

Country Status (3)

Country Link
US (1) US6735220B1 (de)
EP (1) EP1178643B1 (de)
DE (1) DE60103215T2 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE518479C2 (sv) * 2000-10-13 2002-10-15 Ericsson Telefon Ab L M Kommunikationssystem som stödjer trådlös kommunikation av paketdata och förfarande och anordning relaterande därtill
US6662191B1 (en) * 2000-12-21 2003-12-09 Amdocs Software Systems Limited Method and apparatus for caching and reusing object identifiers
JP4150923B2 (ja) * 2003-12-09 2008-09-17 富士ゼロックス株式会社 データ出力システムおよびその方法
JP2005173811A (ja) * 2003-12-09 2005-06-30 Fuji Xerox Co Ltd データ管理システムおよびその方法
US7590672B2 (en) * 2006-12-11 2009-09-15 Bycast Inc. Identification of fixed content objects in a distributed fixed content storage system
US7899850B2 (en) 2008-02-22 2011-03-01 Bycast, Inc. Relational objects for the optimized management of fixed-content storage systems
US8898267B2 (en) 2009-01-19 2014-11-25 Netapp, Inc. Modifying information lifecycle management rules in a distributed system
US20120008627A1 (en) * 2010-07-09 2012-01-12 Yung-Han Chen Method and apparatus for assigning device identifier with collision avoidance
EP2525557B1 (de) * 2011-05-19 2018-10-24 Deutsche Telekom AG Telekommunikationssystem und Verfahren zum Bereitstellen von Diensten in einem Telekommunikationssystem
US9355120B1 (en) 2012-03-02 2016-05-31 Netapp, Inc. Systems and methods for managing files in a content storage system
RU2015102736A (ru) 2015-01-29 2016-08-20 Общество С Ограниченной Ответственностью "Яндекс" Система и способ обработки запроса в сети распределенной обработки данных
CN111083244B (zh) * 2018-10-22 2022-09-06 浙江宇视科技有限公司 集群地址分配方法及装置
CN111741081A (zh) * 2020-06-05 2020-10-02 安徽三实信息技术服务有限公司 一种分布式服务器管理系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5371852A (en) 1992-10-14 1994-12-06 International Business Machines Corporation Method and apparatus for making a cluster of computers appear as a single host on a network
US5522077A (en) 1994-05-19 1996-05-28 Ontos, Inc. Object oriented network system for allocating ranges of globally unique object identifiers from a server process to client processes which release unused identifiers
US5815516A (en) 1996-04-05 1998-09-29 International Business Machines Corporation Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation
US6266335B1 (en) 1997-12-19 2001-07-24 Cyberiq Systems Cross-platform server clustering using a network flow switch
US6601101B1 (en) * 2000-03-15 2003-07-29 3Com Corporation Transparent access to network attached devices

Also Published As

Publication number Publication date
DE60103215D1 (de) 2004-06-17
EP1178643B1 (de) 2004-05-12
EP1178643A1 (de) 2002-02-06
US6735220B1 (en) 2004-05-11

Similar Documents

Publication Publication Date Title
DE60211524T2 (de) Verfahren und vorrichtung zur verteilten lieferung von inhalten innerhalb eines computernetzwerkes
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE60111551T2 (de) Mechanismus zur vervollständigung von nachrichten im speicher
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE69919994T2 (de) Reduzierter paketkopf im drahtlosen nachrichtennetz
DE60103088T2 (de) Verfahren zur Herstellung von Weiterleitungslisten für Netzwerkgruppe
DE60103215T2 (de) Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System
DE60221228T2 (de) Verfahren und system zur anycast-wegleitung zwischen mehreren wirtsrechnern
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE69821050T2 (de) Datenstromdifferenzierungssystem für Endgerätemulator
DE60025129T2 (de) Verfahren und Vorrichtung zur Bereitstellung von skalierbaren Diensten unter Benutzung einer Paketverteilungstabelle
DE69534411T2 (de) Offenes Transaktionverwaltungszugriffsystem und Verfahren
DE602005005219T2 (de) Paketzusammenführung
DE69736422T2 (de) Verfahren und Vorrichtung für eine hybride Serverkommunikationsstruktur zwischen gleichen Schichten
DE60112759T2 (de) Vorrichtungen und verfahren zur datenübertragung
DE69826680T2 (de) Hochintegrierte mehrschichtige Vermittlungsstellenelementarchitektur
DE69922693T2 (de) Systemem und verfahren für netzwerkvorrichtung und ein-ausgabegerätetreiber
DE10108896B4 (de) Computersystem und Verfahren zum Verwalten von Speicherressourcen in einer geclusterten Computerumgebung
DE60221557T2 (de) Methode und gerät zur adressenübersetzung für gesicherte verbindungen
DE69433860T2 (de) System zur umgekehrten adressenauflösung für entfernte netzwerkvorrichtung
DE602004008099T2 (de) Verfahren, system und artikel zur dynamischen echtzeit-stream-aggregation in einem netzwerk
DE60310645T2 (de) Verhinderung von Paketzerteilung
DE60303309T2 (de) Snmp systemeinzelabbild eines am netzwerk angeschlossenen speichers
DE112015006397B4 (de) DNS Optimierung für Multi-Source Download bei Hybridzugriff
DE10296675T5 (de) Virtuelles Vernetzungssystem und -verfahren in einem Verarbeitungssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee