DE69837938T2 - Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung - Google Patents

Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung Download PDF

Info

Publication number
DE69837938T2
DE69837938T2 DE69837938T DE69837938T DE69837938T2 DE 69837938 T2 DE69837938 T2 DE 69837938T2 DE 69837938 T DE69837938 T DE 69837938T DE 69837938 T DE69837938 T DE 69837938T DE 69837938 T2 DE69837938 T2 DE 69837938T2
Authority
DE
Germany
Prior art keywords
servers
network
address
flow switch
packet
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 - Lifetime
Application number
DE69837938T
Other languages
English (en)
Other versions
DE69837938D1 (de
Inventor
Sajit Sunnyvale BHASKARAN
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.)
Avaya Technology LLC
Original Assignee
Avaya Technology LLC
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 Avaya Technology LLC filed Critical Avaya Technology LLC
Publication of DE69837938D1 publication Critical patent/DE69837938D1/de
Application granted granted Critical
Publication of DE69837938T2 publication Critical patent/DE69837938T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/557—Error correction, e.g. fault recovery or fault tolerance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/60—Software-defined switches
    • H04L49/602—Multilayer or multiprotocol switching, e.g. IP switching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/60—Software-defined switches
    • H04L49/608—ATM switches adapted to switch variable length packets, e.g. IP packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2596—Translation of addresses of the same type other than IP, e.g. translation from MAC to MAC addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1017—Server selection for load balancing based on a round robin mechanism
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5625—Operations, administration and maintenance [OAM]
    • H04L2012/5627—Fault tolerance and recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5678—Traffic aspects, e.g. arbitration, load balancing, smoothing, buffer management
    • H04L2012/568—Load balancing, smoothing or shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3009—Header conversion, routing tables or routing tags
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/40—Constructional details, e.g. power supply, mechanical construction or backplane
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/50—Overload detection or protection within a single switching element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Computernetze und spezieller Netzvermittlungseinrichtungen für hohe Bandbreite.
  • Beschreibung des Standes der Technik
  • Der zunehmende Verkehr über Computernetze wie beispielsweise das Internet sowie Intranets von Unternehmen, WANs und LANs erfordert oft die Verwendung mehrerer Server, um den Bedürfnissen eines einzelnen Diensteanbieters oder einer MIS-Abteilung zu entsprechen. Beispielsweise ist es möglich, dass ein Unternehmen, das eine Suchmaschine für das Internet bereitstellt, täglich 80 Millionen Treffer (d. h. Zugriffe auf die Web-Page des Unternehmens) behandelt. Ein einzelner Server kann ein solch großes Volumen an Diensteanforderungen nicht innerhalb einer akzeptablen Ansprechzeit abwickeln. Daher ist es für Diensteanbieter mit hohem Verkehrsvolumen wünschenswert, mehrere Server nutzen zu können, um Diensteanforderungen zu befriedigen.
  • Beispielsweise wird beim Internetprotokoll (IP), welches genutzt wird, um Computer zu identifizieren, die mit dem Internet und anderen globalen, Weiterverkehrs- oder lokalen Netzen verbunden sind, jedem Computer, der mit dem Netz verbunden ist, eine eindeutige IP-Adresse zugewiesen. Wenn also mehrere Server genutzt werden, muss auf jeden Server unter Verwendung der eigenen IP-Adresse des Servers zugegriffen werden.
  • Andererseits ist es wünschenswert, Nutzer in die Lage zu versetzen, auf alle Server eines Diensteanbieters unter Verwendung einer einzigen IP-Adresse zuzugreifen. Ansonsten müssten die Nutzer die Server verfolgen, die von dem Diensteanbieter unterhalten werden, sowie deren relative Arbeitslasten, um schnellere Ansprechzeiten zu erzielen. Durch Nutzung einer einzigen "virtuellen" IP-Adresse (d. h. einer IP-Adresse, die keinem der IP-Server entspricht, sondern vielmehr die gesamte Gruppe von IP-Servern bezeichnet), sind Diensteanbieter in der Lage, die Diensteanforderungen auf die Server aufzuteilen. Durch Nutzung dieses Schemas können IP-Server sogar zu der Gruppe von IP-Servern, die der virtuellen IP-Adresse entspricht, hinzugefügt werden oder aus dieser entfernt werden, um sich ändernde Verkehrsvolumina zu kompensieren. Mehrere Server, die auf diese Weise genutzt werden, werden bisweilen als ein "Cluster" bezeichnet.
  • Ein beispielhaftes System, das einen Hybriden der beiden vorstehend beschriebenen Schemata darstellt, ist in der EP 0 605 339 A2 offenbart. Während jeder Server (Knoten) in einem Cluster seine eigene eindeutige IP-Adresse besitzt, werden alle eingehenden Nachrichten an die IP-Adresse eines der Server adressiert, der als "Gateway" bezeichnet wird. Das Gateway verteilt die Nachrichten auf die Server des Clusters, indem es die IP-Adresse des Gateways in der Nachricht durch die eindeutige IP-Adresse des Zielservers ersetzt oder mit dieser ergänzt.
  • 1 stellt einen Cluster aus IP-Servern gemäß dem Stand der Technik dar. Ein Server-Lastausgleicher 100 leitet Pakete zwischen IP-Servern 110, 120, 130, 140 sowie 150 und Netzroutern 160, 170 sowie 180 weiter. Jeder der IP-Server 110, 120, 130, 140 und 150 sowie Netzrouter 160, 170 und 180 weist eine unterschiedliche IP-Adresse auf, jedoch kann von Netzwerken aus, die mit den Netzroutern 160, 170 und 180 verbunden sind, auf jeden der IP-Server 110, 120, 130, 140 und 150 über eine (nicht gezeigte) virtuelle IP-Adresse zugegriffen werden. Wenn ein Paket, das an die virtuelle IP-Adresse adressiert ist, von dem Server-Lastausgleicher 100 empfangen wird, wird die virtuelle IP-Adresse in die einzelnen IP-Adressen eines der IP-Server übersetzt und das Paket wird zu diesem IP-Server weitergeleitet. Mit der Übersetzung ist jedoch das Erzeugen einer neuen Prüfsumme für das Paket sowie das Umschreiben der Felder für die Quell/Ziel-IP-Adresse und die Prüfsumme, des IP-Header-Felds wie auch der TCP- und UDP-Header-Felder verbunden. Sowohl die IP-Header-Prüfsumme, welche die ISO-Schicht-3- oder Netzschicht-Header-Prüfsumme darstellt, als auch die TCP- oder UDP-Header-Prüfsummen, welche die ISO-Schicht-4- oder Transportschicht-Header-Prüfsummen darstellen, müssen für jedes Paket neu berechnet werden. Typischerweise erfordern diese Vorgänge die Intervention eines Prozessors des Server-Lastausgleichers.
  • Wenn ein großes Volumen an Anforderungen verarbeitet wird, hat der Overhead, der durch die Übersetzung entsteht, einen beträchtlichen Einfluss auf die Ansprechzeit der IP-Server. Wenn außerdem eine große Anzahl von IP-Servern genutzt wird, entsteht durch die Zeit, die zum Ausführen der Übersetzung erforderlich ist, ein Engpass im Leistungsverhalten des Server-Lastausgleichers, da die IP-Adresse für jedes Paket, das zu den IP-Servern oder von diesen weg übertragen wird, von der Vermittlungseinrichtung übersetzt werden muss. Daher besteht ein Bedarf an einem schnelleren Verfahren zum gemeinsamen Nutzen einer einzigen IP-Adresse durch mehrere IP-Server.
  • Es gibt andere Fälle, bei denen mehrere IP-Adressen genutzt werden und typischerweise ein Client versucht, auf einen primären IP-Server zuzugreifen. Wenn der primäre IP-Server nicht innerhalb einer festgelegten Zeitspanne antwortet, versucht der Client, auf Reserve-IP-Server zuzugreifen, bis eine Antwort empfangen wird. Wenn also der primäre IP-Server nicht verfügbar ist, erlebt der Client eine schlechte Reaktionszeit. Derzeitige Serverreplikationssysteme wie solche, die bei DNS- und RADIUS-Servern genutzt werden, sind von diesem Problem betroffen. Es besteht also ein Bedarf an einem Verfahren zum Zugreifen auf mehrere IP-Server, bei dem keine schlechten Ansprechzeiten auftreten, wenn der primäre IP-Server nicht verfügbar ist.
  • Ein weiterer potenzieller Nachteil des Stands der Technik besteht darin, dass jeder replizierte Server eine physisch in dem Server konfigurierte eindeutige IP-Adresse erfordert. Da sämtliche IP-Netze Teilnetz-Maskierungsregeln unterliegen (welche oft durch einen externen Administrator bestimmt werden), ist die Skalierbarkeit der Replikation stark eingeschränkt. Wenn beispielsweise das Teilnetz-Präfix 28 Bits einer IP-Adresse mit 32 Bits ausmacht, beträgt die maximale Anzahl von replizierten Servern 16 (2(32-28)). Es besteht ein Bedarf an einem Verfahren zum Replizieren von Servern, das eine Replikation von IP-Servern unabhängig von Teilnetz-Maskierungsregeln ermöglicht.
  • Adressen für IP Version 4 sind momentan im Internet knapp, somit ist jedes Verfahren der IP-Server-Replikation, das einen proportionalen Verbrauch an diesen knappen IP Adressen erfordert, von Natur aus verschwenderisch. Beispielsweise stellt ein Lastausgleich auf Basis des Domain Name Service (DNS) ein Beispiel für den Stand der Technik dar. DNS-Server werden zum Auflösen eines Servernamens (z. B. www.companyname.com) in eine global eindeutige IP-Adresse (z. B. 192.45.54.23) genutzt. Bei einem DNS-basierten Server-Lastausgleich werden viele eindeutige IP-Adressen pro Servername vorgehalten und sparsam ausgeteilt, um einen Lastausgleich zu ermöglichen. Dadurch reduziert sich jedoch die Anzahl der verfügbaren Adressen für IP Version 4. Es besteht daher ein Bedarf an einem Verfahren zur Clusterbildung mit IP-Servern, bei dem der Verbrauch des knappen IP-Adress-Raums minimiert wird.
  • Darüber hinaus kann, wenn die IP-Nutzlast eines Pakets verschlüsselt wird, um sichere Übertragungen über das Internet bereitzustellen, die Übersetzung der IP-Adresse nicht ausgeführt werden, ohne dass zunächst die IP-Nutzlast entschlüsselt wird, (welche die TCP- oder UDP-Header-Prüfsummen enthält). Bei den momentanen Rahmenbedingungen für IP-Sicherheit, die als IPSEC bezeichnet wird, stellt die Transportschicht einen Teil der Netzschicht-Nutzlast dar, die in einer Netzanwendung, welche IPSEC implementiert, vollständig verschlüsselt wird. IPSEC ist in RFCs 1825–1827, veröffentlicht von der Internet Engineering Taskforce, beschrieben. Die Verschlüsselung wird von dem Client ausgeführt, und die Entschlüsselung wird von dem Server ausgeführt, und zwar mit Hilfe geheimer Cryptoschlüssel, welche für jede Client-Server-Verbindung eindeutig sind. Wenn daher eine solche Verschlüsselung bei Client-Server-Kommunikationen ausgeführt wird, wie bei IPSEC, werden die Server-Lastausgleicher gemäß dem Stand der Technik nicht in der Lage sein, Lastausgleichsvorgänge auszuführen, ohne die IPSEC-Regeln zu verletzen. Dies ist der Fall, weil die Server-Lastausgleicher nicht auf die Transportschicht-Informationen zugreifen können (die als Teil der IP-Nutzlast verschlüsselt sind), ohne zunächst die IP-Nutzlast zu entschlüsseln. Da die zwischen dem Client und dem Server eingerichteten Cryptoschlüssel per Definition nicht öffentlich sind, kann die IP-Nutzlast von dem Server-Lastausgleicher nicht entsprechend IPSEC entschlüsselt werden (tatsächlich wird der Server-Lastausgleicher für sämtliche praktische Zwecke für verschlüsselte Pakete überhaupt nicht funktionieren).
  • Es besteht daher ein Bedarf an einem System, das nicht nur die Übertragungen von verschlüsselten Datenpaketen entsprechend dem IPSEC-Modell ermöglicht, sondern das auch Netzwerkadministratoren ermöglicht, sowohl einen Server-Lastausgleich als auch IPSEC in ihren Netzen auszuführen.
  • Darüber hinaus funktionieren derzeitige Server-Lastausgleicher typischerweise nur bei TCP-Paketen. Im Gegensatz dazu weisen IP-Header ein Protokollfeld von 8 Bit auf, das theoretisch bis zu 256 Transportprotokolle auf der Schicht 4 gemäß ISO unterstützt. Es besteht daher ein Bedarf an einem Server-Lastausgleichssystem, welches andere Transportprotokolle auf der Schicht 4 gemäß ISO als TCP unterstützt (z. B. UDP, IP_in_IP, usw.).
  • Systeme gemäß dem Stand der Technik ermöglichen einen Lastausgleich und bisweilen eine Fehlertoleranz für Netzverkehr nur in der Eingangsrichtung (d. h. Client-Router-Server). Ein Lastausgleich und eine Fehlertoleranz in der umgekehrten (abgehenden) Richtung (d. h. Server-Router-Client) wird nicht unterstützt. Speziell wird, wenn mehrere Router-Verbindungen für den Server bereitstehen, um Informationen an Clients zurückzusenden, kein Versuch unternommen, die Verkehrsflusslast über die Router-Verbindungen auszugleichen. Außerdem erfolgt, wenn ein spezieller IP-Server dafür konfiguriert ist, eine spezielle Standard-Router-IP-Adresse bei den abgehenden Übertragungen zu nutzen, keine Fehlertoleranz oder transparente Umleitung von Paketen, wenn der Router ausfällt. Es besteht daher ein Bedarf an einem System, das Clusterbildungsdienste für Verkehrsfluss in sowohl der Eingangs- als auch der Ausgangsrichtung ermöglicht.
  • Ein beispielhaftes System dieser Art ist beschrieben in "Load Balancing for Multiple Interfaces for Transmission Control Protocol/Internet Protocol for VM/MVS", IBM Technical Disclosure Bulletin (IBM Corp. New York, USA), Bd. 38, Nr. 9 (1. September 1995), S. 7–9, XP000540166, ISSN 0018–8689. Es offenbart das Zuordnen von eindeutigen MAC-Adressen und der gleichen IP-Adresse für mehrere Schnittstellen. Abgesetzte Hosts nutzen immer die gleiche IP-Adresse und kümmern sich nicht darum, welche Schnittstelle sie nutzen, wenn aber ein abgesetzter Host die IP-Adresse des Hosts über ARP anfragt, erhält er die MAC-Adresse einer der verfügbaren Schnittstellen. Um das Problem zu beheben, dass eine Schnittstelle ausfällt, müssen ARP-Zwischenspeicher in den abgesetzten Hosts, welche die ausgefallene Schnittstelle genutzt haben, aktualisiert werden.
  • Damit abgehend ein Lastausgleich stattfindet, muss die Möglichkeit gegeben sein, dem TCP/IP-Server zu sagen, dass es für einen gegebenen Bestimmungsort mehrere Schnittstellen gibt, und der TCP/IP-Server muss modifiziert werden, um den Verkehr zwischen allen verfügbaren Schnittstellen gleichmäßig auszugleichen. In dem Dokument sind zwei Alternativen zum Ausgleich des Verkehrs offenbart. Die eine besteht darin, mehrere Routen zu dem gleichen Bestimmungsort in der Wegelenkungstabelle des Gateways zuzulassen. Der TCP/IP muss eine davon herausgreifen, worauf für den abgesetzten Host über diese Schnittstelle ein ARP-Vorgang erfolgen muss, um die MAC-Adresse dieser Schnittstelle zu erhalten. Außerdem verfolgt ein neues Feld in dem ARP-Zwischenspeicher, welche Schnittstelle der TCP/IP-Server nutzt, um den abgesetzten Host zu kontaktieren. Auf diese Weise werden alle Daten, die zu diesem speziellen abgesetzten Host gesendet werden, immer von der gleichen MAC-Adresse ausgehen. Die andere Alternative komplettiert die erste, indem das Kombinieren sämtlicher Schnittstellen für ein gemeinsames Ziel zu einer Schnittstellengruppe ermöglicht wird. Der Vorteil besteht darin, dass nur eine einzige Route zu der Wegelenkungstabelle pro Ziel hinzugefügt zu werden braucht, anstatt eine Route pro Schnittstelle. Im Hinblick auf einen automatischen Lastausgleich überwacht der TPC/IP-Server die Verkehrslast, und wenn diese nicht gleich ist, kann der Server Verkehr von einem Adapter zu einem anderen verschieben, indem er seinen eigenen ARP-Zwischenspeicher aktualisiert und den abgesetzten Host über ARP anfragt, damit dieser seinen ARP-Zwischenspeicher aktualisiert.
  • Die Lösungen gemäß dem Stand der Technik stellen Hardware-Einrichtungen dar, die derart konfiguriert sind, dass sie für den Cluster von Servern, für den ein Last ausgleich erfolgt, als IP-Router erscheinen. Infolgedessen kommt zu der Domain des Administrators der Router für verwaltete IP-Router eine weitere Klasse von IP-Router-Einrichtungen hinzu. Dies stellt eine Einschränkung bezüglich einer zukünftigen Entwicklung des Routernetzes sowohl hinsichtlich des Hinzufügens von Routern neuer Anbieter in der Zukunft als auch in Bezug auf das Hinzufügen von neuen und weiterentwickelten Wegelenkungsmerkmalen dar. Das Suchen und Beheben von Wegelenkungsproblemen wird ebenfalls schwieriger. Es wäre somit vorzuziehen, ein vollständig transparentes Hardwareelement wie beispielsweise einen LAN-Switch oder -Hub als lastausgleichende Einrichtung anzuwenden. Gemäß dem Stand der Technik sind Server und etwaige externe Router mit der Lastausgleichseinrichtung unter Nutzung eines Shared Media Ethernets verbunden (d. h. einem Rundsendemedien-Netzwerk). Es besteht ein Bedarf an einer besseren Lösung, welche es ermöglicht, vermittelte Leitungen zu nutzen (z. B. Switched (vermitteltes) Ethernet, SONST), da vermittelte Leitungen von Natur aus (a) eine bestimmte Bandbreite bereitstellen und (b) Vollduplex bereitstellen (d. h. gleichzeitige Sende- und Empfangsvorgänge) für Geräte mit hergestellter Rufverbindung.
  • Zusammenfassung der Erfindung
  • Entsprechend der vorliegenden Erfindung wird eine Netzfluss-Vermittlungseinrichtung entsprechend Anspruch 1 zur Verfügung gestellt.
  • Entsprechend der vorliegenden Erfindung wird ein Verfahren entsprechend Anspruch 4 zur Verfügung gestellt.
  • Die vorliegende Erfindung stellt eine Netzfluss-Vermittlungseinrichtung (sowie ein Verfahren zum Betrieb selbiger) zum Verbinden eines Pools von IP-Routern mit einem Cluster von IP-Servern, die eine einzige IP-Adresse gemeinsam nutzen, zur Verfügung, ohne dass eine Übersetzung der IP-Adresse erforderlich ist und wobei eine bidirektionale Clusterbildung ermöglicht wird. Die Netzfluss-Vermittlungseinrichtung ermöglicht, indem sie transparent auf den ISO-Schichten 2 und 3 arbeitet, eine Cross-Plattform-Clusterbildung von Servern und Routern, wobei diese Router die so genannten "First-Hop-" Router darstellen, die von den Servern genutzt werden, um mit der Außenwelt zu kommunizieren. Das bedeutet, dass die Server in einem einzelnen Cluster von einem beliebigen Hersteller von Computer-Hardware stammen können und auf diesen ein beliebiges Betriebssystem laufen kann (z. B. WINDOWS NT von Microsoft, Unix, MACOS). WINDOWS NT stellt eine eingetragene Marke der Microsoft Corp. Redmond, Washington dar; MACOS ist eine eingetragene Marke der Apple Computer Inc., Cupertino, Kalifornien. Das bedeutet auch, die Router können von einem beliebigen Anbieter von Wegelenkungsausrüstung kommen. Die Netzfluss-Vermittlungseinrichtung ermöglicht daher den Kunden eine freie Auswahl bezüglich der Betriebssysteme der Server als auch der Routersysteme bei der Gestaltung ihrer Server-Clusterbildungsstrukturen. Die einzigen Anforderungen für diese Server und Router bestehen darin, dass sie alle die standardmäßigen TCP/IP-Kommunikationsprotokolle oder einen gewissen anderen Protokollstapel entsprechend dem 7-Schichten-Modell der ISO/OSI für Computerkommunikation implementieren. Die Netzfluss-Vermittlungseinrichtung leitet Pakete zu einzelnen Servern weiter, indem sie die Sicherungsschicht(Data Link Layer)-Adresse des Ziel-IP-Servers in das Ziel-Adressfeld der Sicherungsschicht des Pakets schreibt. Pakete, die von den IP-Servern zu den IP-Routern übertragen werden, erfordern andererseits keine Modifikation des Sicherungsschicht-Adressfeldes.
  • Da in einer typischen Client-Server-Umgebung die Mehrzahl der Pakete, die durch die Netzfluss-Steuerungsvermittlungseinrichtung fließen, von dem Server zum Client übertragen wird, werden durch das Überflüssigmachen einer Prozessorintervention bei der Weiterleitung abgehender Pakete beträchtliche Verbesserungen im Leistungsverhalten möglich. Infolgedessen verringert sich die Wahrscheinlichkeit, dass die Netzfluss-Vermittlungseinrichtung zu einem Engpass wird, deutlich.
  • In einer einzigen Netzfluss-Vermittlungseinrichtung werden mehrere Cluster (ein oder mehrere IP-Server, die eine einzige IP-Adresse gemeinsam nutzen) unterstützt. Auf jeder einzelnen Verbindung, die an jeden der IP-Server angekoppelt ist, können mehrere Cluster unterstützt werden, wenn das Betriebssystem des IP-Servers mehrere IP-Adressen auf einer physischen Verbindung unterstützt.
  • Bei einigen Ausführungsformen führt die Netzfluss-Vermittlungseinrichtung zusätzlich dazu, dass sie die Pakete weiterleitet, einen Lastausgleich sowie eine Fehlertoleranzfunktion aus. Bei diesen Ausführungsformen führt ein Prozessor der Netzfluss-Vermittlungseinrichtung periodisch eine Lastausgleichsroutine aus, um die relative Arbeitslast für jeden der IP-Server festzustellen. Wenn die Netzfluss-Vermittlungseinrichtung ein Paket empfängt, das für den Cluster von IP-Servern bestimmt ist, wird das Paket zu demjenigen IP-Server mit einer optimalen Arbeitslast weitergeleitet, sodass sichergestellt wird, dass die Arbeitslast gleichmäßig auf die IP-Server verteilt wird. Außerdem wird, wenn ein Ausfall eines Netzrouters erkannt wird, ein Paket, das an diesen Netzrouter adressiert ist, zu einem anderen Netzrouter umgeleitet, indem die Sicherungsschicht-Zieladresse des Pakets umgeschrieben wird. Da die Netzfluss-Vermittlungseinrichtung kontinuierlich den Status der IP-Server überwacht, wird keine längere Zeitverzögerung in die Client-Server-Kommunikationen eingetragen, wenn ein IP-Server funktionsunfähig wird.
  • Da der IP-Header nicht modifiziert wird, arbeitet die Netzfluss-Vermittlungseinrichtung gemäß der vorliegenden Erfindung an Paketen, die gemäß einem beliebigen ISO-Schicht-4-Protokoll kodiert sind, und ist im Gegensatz zu Server- Lastausgleichern entsprechend dem Stand der Technik nicht auf TCP-kodierte Pakete beschränkt. Außerdem kann die Netzfluss-Vermittlungseinrichtung auch eine Umleitung, einen Lastausgleich und eine Fehlertoleranz für verschlüsselte Pakete transparent für sowohl den Server als auch den Client abwickeln.
  • Bei einigen Ausführungsformen wird der Lastausgleich auch für abgehende Pakete ausgeführt, sodass Pakete zu dem Router mit einer optimalen Arbeitslast geleitet werden.
  • Es werden somit ein Verfahren und eine Vorrichtung zum Ermöglichen einer bidirektionalen Clusterbildung im Hinblick aus Lastausgleich und Fehlertoleranz in der Eingangsrichtung (d. h. Client-Router-Server) als auch in der Abgangsrichtung (d. h. Server-Router-Client) bereitgestellt.
  • Kurze Beschreibung der Zeichnungen
  • 1 stellt einen Cluster von IP-Servern, die jeweils eine unterschiedliche IP-Adresse aufweisen, gemäß dem Stand der Technik dar, sowie eine Netzfluss-Vermittlungseinrichtung gemäß dem Stand der Technik zum Übersetzen einer virtuellen IP-Adresse, die von sämtlichen IP-Servern in dem Cluster gemeinsam genutzt wird, in die einzelnen IP-Adressen der IP-Server.
  • 2 stellt ein Cluster von IP-Servern sowie eine Netzfluss-Vermittlungseinrichtung entsprechend einer Ausführungsform der vorliegenden Erfindung dar. Jeder IP-Server weist die gleiche IP-Adresse auf. Eine Sicherungsschicht-Adresse wird genutzt, um jeden IP-Server in dem Cluster zu identifizieren.
  • 3A stellt das Format für ein Paket dar, das durch die Netzfluss-Vermittlungseinrichtung 205 aus 2 zu/von dem Cluster von IP-Servern geleitet wird.
  • 3B zeigt das Format des Verbindungsfelds 320 aus 3A.
  • 4A stellt die Struktur der Netzfluss-Vermittlungseinrichtung 205 aus 2 dar.
  • 4B stellt ein Flussdiagramm für den Prozess des Weiterleitens von Paketen von einem der Netz-Clients zu einem der IP-Server aus 2 über die Netzfluss-Vermittlungseinrichtung 205 aus 4A entsprechend einer Ausführungsform der vorliegenden Erfindung dar.
  • 4C stellt ein Flussdiagramm für den Prozess des Weiterleitens von Paketen von einem der IP-Server zu einem der Netz-Clients aus 2 über die Netzfluss-Vermittlungseinrichtung 205 aus 4A entsprechend einer Ausführungsform der Erfindung dar.
  • 5A stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe mehrerer Allzweck-Schaltungskarten implementiert ist, entsprechend einer Ausführungsform der Erfindung dar.
  • 5B stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe einer Allzweck-CPU-Karte und einer Spezial-Netzkarte implementiert ist, entsprechend einer Ausführungsform der Erfindung dar.
  • 5C stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe zweier Spezial-Schaltungskarten implementiert ist, entsprechend einer Ausführungsform der Erfindung dar.
  • 5D stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe einer einzigen Spezial-Schaltungskarte implementiert ist, entsprechend einer Ausführungsform der Erfindung dar.
  • 5E stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe einer Kombination aus Spezial- und Allzweck-Schaltungskarten implementiert ist, entsprechend einer Ausführungsform der vorliegenden Erfindung dar.
  • 5F stellt ein Blockdiagramm einer Netzfluss-Vermittlungseinrichtung, die mit Hilfe eines Crossbar-Switch implementiert ist, entsprechend einer Ausführungsform der Erfindung dar.
  • Detaillierte Beschreibung der Erfindung
  • Das Verfahren und die Vorrichtung gemäß der vorliegenden Erfindung ermöglichen, dass mehrere IP-Server eine gleiche IP-Adresse gemeinsam nutzen, und es wird eine Netzfluss-Vermittlungseinrichtung verwendet, um Pakete zwischen den IP-Servern basierend auf der Sicherungsschicht-Adresse der IP-Server weiterzuleiten (z. B. wird die Zieladresse der Pakete in die Sicherungsschicht-Adresse eines der IP-Server übersetzt). Da IP-Netze das Quell-Adressfeld der Sicherungsschicht der Pakete, die über das Netz übertragen werden, nicht kennen, wird eine Übersetzung der Sicherungsschicht-Adresse nur für Pakete ausgeführt, die von einem IP-Client zu einem IP-Server fließen. In der Rückflussrichtung, das heißt von einem IP-Server zu einem IP-Client, ist keine Übersetzung der Sicherungsschicht-Adresse erforderlich, somit wird ein sehr schneller Durchsatz durch die Netzfluss-Vermittlungseinrichtung ermöglicht.
  • Ein Cluster von IP-Servern 200 und eine Netzfluss-Vermittlungseinrichtung 205 entsprechend einer Ausführungsform der Erfindung sind in 2 gezeigt. Die Netzfluss-Vermittlungseinrichtung 205 leitet Pakete zwischen IP-Servern 210, 220, 230, 240 sowie 250 und Netzroutern 260, 270 und 280 weiter. Die IP-Server 210, 220, 230, 240 und 250 sind identisch konfiguriert und besitzen eine virtuelle IP-Adresse 290. Außerdem besitzt jeder der IP-Server 210, 220, 230, 240 und 250 eine unterschiedliche Sicherungsschicht-Adresse und einen unterschiedlichen Verbindungsnamen. Der Verbindungsname wird genutzt, um den einzelnen Server in dem Cluster von Servern, welche die gleiche IP-Adresse gemeinsam nutzen, zu identifizieren. Wie noch später erklärt wird, wird die Sicherungsschicht-Adresse genutzt, um eine virtuelle Sicherungsschicht-Adresse in eine physische Sicherungsschicht-Adresse zu übersetzen, nachdem ein IP-Server von der Netzfluss-Vermittlungseinrichtung 205 zum Empfang des Pakets ausgewählt worden ist. Die IP-Adresse 290 ist für Einrichtungen, die mit dem Cluster 200 kommunizieren, sichtbar, während die einzelnen Sicherungsschicht-Adressen jedes IP-Servers nicht sichtbar sind. Die Netzfluss-Vermittlungseinrichtung 205 führt eigentlich eine stellvertretende Adress Resolution Protocol (ARP – Adressauflösungsprotokoll)-Funktion aus, durch welche eine "virtuelle" (nicht gezeigte) Sicherungsschicht-Adresse an eine mit dem Netz verbundene Einrichtung in Reaktion auf eine standardmäßige ARP-Anfrage zurückgesendet wird. Infolgedessen sehen an das Netz angeschlossene Einrichtungen den Cluster 200, als hätte dieser eine einzige IP-Adresse 290 und eine einzige Sicherungsschicht-Adresse (nicht gezeigt).
  • Die Netzrouter 260, 270 und 280 andererseits haben jeweils eine unterschiedliche IP-Adresse und eine unterschiedliche Sicherungsschicht-Adresse. Die Router werden genutzt, um den Cluster 200 über die Netzfluss-Vermittlungseinrichtung 205 mit (nicht gezeigten) externen Netzen zu verbinden. Somit wird eine Einrichtung, die mit einem der externen Netze verbunden ist (z. B. ein Router), um Informationspakete an den Cluster 200 zu übertragen, eine standardmäßige ARP-Anfrage an die Netzfluss-Vermittlungseinrichtung 205 ausgeben, um die virtuelle Sicherungsschicht-Adresse des Clusters 200 zu erhalten; die Netzfluss-Vermittlungseinrichtung 205 sendet eine Sicherungsschicht-Adresse der ausgewählten Empfangseinrichtung (z. B. eines der IP-Server) an die anfordernde Einrichtung (z. B. den Router) zurück. Die mit dem Netz verbundene Einrichtung sendet dann eine Reihe von Paketen an die Netzfluss-Vermittlungseinrichtung 205 (z. B. über einen der Netzrouter 260, 270 oder 280, die mit dem externen Netz verbunden sind). Die Pakete werden dann von der Netzfluss-Vermittlungseinrichtung 205 zu exakt einem der IP-Server 210, 220, 230, 240 und 250 umgeleitet.
  • Da sämtliche Ausführungsformen der Netzfluss-Vermittlungseinrichtung sicherstellen, dass sich nicht zwei Server in demselben Cluster in dem demselben Flussvermittlungsteil befinden, wird eine Rundsendeisolation der replizierten Server möglich. Daher werden IP-Adresskonflikte vermieden, durch die aktive Intervention der Flussvermittlungseinrichtung für den Fall, dass wie vorstehend beschrieben ARP-Anforderungspakete von der Netzfluss-Vermittlungseinrichtung empfangen werden.
  • Das Format eines Pakets 300, das über das externe Netz übertragen wird, ist in 3A dargestellt. Das Paket 300 weist ein Header-Feld 310, ein Verbindungsfeld 320, einen IP-Header 330, einen TCP-Header 340, eine Daten-Nutzlast 350, ein CRC-Feld 360 und ein auch als Trailer bezeichnetes Endfeld 370 auf. Der Header 310 und der Trailer 370 stellen 8-Bit breite Felder mit "Private" Tag (Kennzeichnung "privat") dar: diese werden nicht über das externe Netz übertragen, sondern werden nur innerhalb der Netzfluss-Vermittlungseinrichtung genutzt. Der IP-Header 330 und der TCP-Header 340 stellen standardmäßige IP- und TCP-Header dar. Der IP-Header 330 umfasst neben anderen Informationen eine IP-Zieladresse und eine IP-Quelladresse für das Paket 300. Das CRC-Feld 360 enthält einen Prüfsummen-Korrekturcode, der genutzt wird, um zu verifizieren, dass das Paket 300 ohne Fehler übertragen worden ist. Würde der IP-Header 330 modifiziert werden, wie es für Verfahren gemäß dem Stand der Technik zum gemeinsamen Nutzen einer einzigen IP-Adresse zwischen mehreren IP-Servern erforderlich ist, müsste die Prüfsumme für das CRC-Feld 360 neu berechnet werden, ein Vorgang, der die Intervention eines Prozessors erforderlich macht. Außerdem ist, wenn verschlüsselte Daten entsprechend den IPSEC-Sicherheitsrichtlinien übertragen werden, eine Entschlüsselung der IP-Nutzlast erforderlich. Es wird also dadurch, dass die Notwendigkeit der Neuberechnung der Prüfsumme für jedes Paket wegfällt, mit der Netzfluss-Vermittlungseinrichtung gemäß der vorliegenden Erfindung ein besserer Durchsatz als bei Einrichtungen gemäß dem Stand der Technik erreicht. Die Netzbesitzer können ferner IPSEC-Sicherheitsmechanismen transparent und ohne Befürchtung, dass die Kommunikation unterbrochen wird, anwenden.
  • 3B stellt das Format des Verbindungsfelds 320 dar. Das Verbindungsfeld 320 weist ein Sicherungsschicht-Quelladressfeld 380, ein Sicherungsschicht-Zieladressfeld 390 und ein Typenfeld 395 auf. Da das Verbindungsfeld 320 nicht Teil des IP-Protokolls ist, besteht keine Notwendigkeit, die Prüfsumme für das CRC-Feld 360 neu zu berechnen, wenn das Verbindungsfeld 320 modifiziert wird. Dementsprechend wird eine Umleitung von Paketen entsprechend der vorliegenden Erfindung dadurch erreicht, dass die Sicherungsschicht-Zieladresse in dem Sicherungsschicht-Zieladressfeld 390 des Pakets 300 umgeschrieben wird. Weder der IP-Header 330 noch das CRC-Feld 360 werden modifiziert, wodurch sich die Verarbeitungszeit verringert, die erforderlich ist, um Pakete zu dem Cluster von IP-Servern und von diesem weg weiterzuleiten.
  • Eine Ausführungsform der Netzfluss-Vermittlungseinrichtung 205 (2) wird durch das Blockdiagramm aus 4A veranschaulicht. Die Netzfluss-Vermittlungseinrichtung 205 weist eine CPU-Karte 400 sowie vier Ethernetkarten 415, 416, 417 und 418, die durch einen PCI-Bus 410 verbunden sind, auf. Die CPU-Karte 400 wiederum umfasst eine CPU 402, einen Speicher 404 und einen Speicher-Controller 406 zum Kontrollieren des Zugriffs auf den Speicher 404. Jede der Ethernet-Karten 415, 416, 417 und 418 weist einen Ethernet-Controller und zwei Eingangs-/Ausgangsports 411 und 413 auf.
  • Eine Netzfluss-Vermittlungseinrichtung entsprechend einer Ausführungsform der Erfindung kann vollständig aus serienmäßig produzierten ASICs (anwendungsspezifischen integrierten Schaltungen) aufgebaut werden, die von einer Allzweck-CPU gesteuert werden, welche ein Softwareprogramm ausführt. Da viele kommerziell verfügbare Ethernet-Switche Allzweck-CPUs zum Vermittlungsmanagement bereitstellen (z. B. zum Ausführen SNMP- und IEEE 802.1D Spanning-Tree-Protokollen) kann eine Netzvermittlungseinrichtung entsprechend einer Ausführungsform der Erfindung in einfacher Weise auf solchen Hardwareplattformen implementiert werden. Die einzige Anforderung besteht darin, dass der ASIC in der Lage ist, eine bestimmte Art von "CPU-Intervention" zu unterstützen, die ausgelöst wird, wenn ein Paket mit einer bestimmten Sicherungsschicht-Zieladresse durch die Netzfluss-Vermittlungseinrichtung geleitet wird. ASICs, die diese Form von CPU-Intervention unterstützen, sind unter anderem erhältlich bei der Galileo Technology Ltd., Kormiel, Israel, der MMC Networks, Inc., Sunnyvale, Kalifornien und der I-Cube, Inc., Campbell, Kalifornien.
  • Der Prozess des Weiterleitens eines Pakets 300 (3A), das von einem der Netzrouter 260, 270 oder 280 empfangen wird, an einen der IP-Server 210, 220, 230, 240 oder 250 aus 2, wird durch das Ablaufdiagramm aus 4B dargestellt. Zu Beginn wird ein Paket an einem Port einer der Ethernet-Karten 415, 416, 417 oder 418 empfangen, und zwar bei Stufe 420. Bei Stufe 425 überprüft der Ethernet-Controller 412 dann ein CPU-Interventions-Bit, um festzustellen, ob das Paket zur Weiterverarbeitung an die CPU-Karte 400 gesendet werden muss. In einem solchen Fall wird das Paket über den PCI-Bus 410 an die CPU-Karte 400 übertragen und von dem Speicher-Controller 406 in dem Speicher 404 gespeichert, und zwar bei Stufe 430. Wenn das CPU- Interventions-Bit jedoch nicht gesetzt ist, wird die Verarbeitung mit Stufe 445 fortgesetzt. Bei Stufe 435 wird ein optionaler Lastausgleichsvorgang ausgeführt, um zu bestimmen, zu welchem IP-Server 210, 220, 230, 240 oder 250 das Paket 300 weitergeleitet werden soll. Bei dem Lastausgleichsvorgang auf Stufe 435 wird versucht, die zu verarbeitenden Pakete entsprechend der Kapazität und der momentanen Nutzung jedes Servers auf die IP-Server aufzuteilen. Ein Lastausgleichsschema, das zur Nutzung in der vorliegenden Erfindung geeignet ist, ist beschrieben in einer verwandten Anmeldung mit dem Titel "Dynamic Load Balancer for Multiple Network Servers" von Sajit Bhaskaran und Abraham Matthews, mit dem Aktenzeichen 08/992,038 und dem Anwaltsaktenzeichen M-4969 US, welche hier vollumfänglich durch Bezugnahme einbezogen wird. Bei Stufe 440 wird dann das Sicherungsschicht-Zieladressenfeld des Pakets 300 umgeschrieben, sodass es angibt, zu welchem der IP-Server 210, 220, 230, 240 oder 250 das Paket 300 weitergeleitet werden soll. Schließlich wird das Paket zu einer der Ethernet-Karten 415, 416, 417 oder 418, mit welcher der durch das Sicherungsschicht-Zieladressenfeld des Pakets 300 spezifizierte IP-Server verbunden ist, übertragen, und zwar bei Stufe 445.
  • Der Vorgang des Weiterleitens eines Pakets 300 (3A) von einem der IP-Server 210, 220, 230, 240 oder 250 zu einem der Netzrouter 260, 270 oder 280 (2) wird durch das Ablaufdiagramm aus 4C dargestellt. Zu Beginn wird ein Paket an einem Port einer der Ethernet-Karten 415, 416, 417 oder 418, die mit einem der IP-Server 210, 220, 230, 240 oder 250 verbunden ist, empfangen, und zwar bei Stufe 450. Optional wird dann in Stufe 455 überprüft, ob der Netzrouter, zu welchem das Paket 300 weitergeleitet werden soll, in Betrieb ist, in welchem Fall die Verarbeitung mit Stufe 465 fortgesetzt wird. Ein Fehlertoleranzschema, das zur Verwendung bei der vorliegenden Erfindung geeignet ist, ist beschrieben in einer verwandten Patentanmeldung mit dem Titel "Router Pooling in a Network Flowswitch" von Sajit Bhaskaran, mit dem Aktenzeichen 08/994,405 und dem Anwaltsaktenzeichen M-4971 US, welche hier durch Bezugnahme vollumfänglich einbezogen wird. Ansonsten überträgt der Ethernet-Controller 412 in der optionalen Stufe 460 das Paket 300 über den PCI-Bus 410 zu der CPU-Karte 400, und der Speicher-Controller 406 speichert das Paket 300 in dem Speicher 404. Noch in Stufe 460 schreibt die CPU 402 das Sicherungsschicht-Zieladressfeld 390 des Pakets 300 um, sodass dieses angibt, zu welchem der Netzrouter 260, 270 oder 280 das Paket 300 weitergeleitet werden soll. Schließlich überträgt der Speicher-Controller 406 das Paket 300 über den PCI-Bus 410 zu einer der Ethernet-Karten 415, 416, 417 oder 418, in Abhängigkeit von dem Inhalt des Sicherungsschicht-Zieladressenfeldes 390 des Pakets 300, und zwar in Stufe 465.
  • Bei einigen Ausführungsformen ermöglicht die Netzfluss-Vermittlungseinrichtung einen Lastausgleich und eine Clusterbildung für abgehende Pakete. In einem solchen Fall werden die Netzrouter in "Router-Pools" gruppiert, genauso wie die IP-Server für die eingehende Verarbeitung in Clustern gruppiert wurden. Verkehr von den IP-Servern, der zu den IP-Clients läuft, erfährt einen Lastausgleich, wenn mehrere Netzrouter und/oder mehrere Netzrouterverbindungen vorhanden sind. Wenn beispielsweise vier Netzrouter, jeder mit einem 100 Mbit/s-Ethernetport, mit der Netzfluss-Vermittlungseinrichtung verbunden sind, wird die Verkehrslast ungefähr auf die vier Verbindungen aufgeteilt, was einen Durchsatz von nahezu 400 Mbit/s ermöglicht, selbst wenn alle IP-Server jeweils mit einer einzigen und identischen Standard-Router-IP-Adresse konfiguriert sind.
  • Dies wird erreicht, indem die Netzfluss-Vermittlungseinrichtung derart programmiert wird, dass sie auf ARP-Anforderungen von den IP-Servern in Hinsicht auf eine IP-Adresse eines speziellen Netzrouters wie folgt antwortet. Die Netzfluss-Vermittlungseinrichtung verfolgt die Last, die zu allen Netzroutern in einem Router-Pool geht (z. B. indem sie die Vektoren <Pakete ein, Pakete aus, Bytes ein, Bytes aus> verfolgt). Die IP-Server unterhalten ARP-Zwischenspeicher für die IP-Adresse der Netzrouter. Der ARP-Zwischenspeicher wird aktualisiert, indem periodisch eine ARP-Anforderung nach einer IP-Adresse eines Netzrouters ausgegeben wird. Die Netzfluss-Vermittlungseinrichtung fängt die Anforderung ab, untersucht die IP-Adresse des IP-Servers und antwortet auf die Anforderung, indem sie die Sicherungsschicht-Adresse desjenigen Netzrouters in dem Pool zuordnet, der am besten in der Lage ist, die Last, die von diesem speziellen Server kommt, zu bedienen (der "beste" wird durch Messwerte der Verkehrslast in Echtzeit oder mit Hilfe eines einfachen zyklischen Schemas basierend auf den Server-IP-Quelladressen bestimmt).
  • Für die Zwecke des Ausgleichs der abgehenden Last werden die Netzrouter im Gegensatz zum Ausgleich für die eingehende Last mit eindeutigen IP-Adressen anstatt einer einzigen IP-Adresse konfiguriert.
  • Bei einigen Ausführungsformen kann die Netzfluss-Vermittlungseinrichtung dafür konfiguriert sein, nur eine "Verfügbarkeits-Clusterbildung" auszuführen. Bei der Verfügbarkeits-Clusterbildung dient ein Server als der primäre IP-Server, während alle anderen IP-Server in dem Cluster jeweils als sekundäre IP-Server wirken ("sekundär – betriebsfähig" oder "sekundär – ausgefallen"). Der Verkehr wird immer zu dem primären IP-Server weitergeleitet. Wenn der primäre IP-Server ausfällt, wird der Ausfall von der Netzfluss-Vermittlungseinrichtung automatisch erkannt, und der Status des ausgefallenen IP-Servers wird in "sekundär – ausgefallen" umgewandelt. Einer der verfügbaren IP-Server mit dem Status "sekundär – betriebsfähig" wird dann in den Status "primär" umgewandelt. Die Netzfluss-Vermittlungseinrichtung fährt fort, den Status der Server mit dem Status "sekundär – ausgefallen" zu überwachen und erkennt automatisch, wenn diese wieder betriebsfähig werden. Wenn dies geschieht, wird deren Status in "sekundär – betriebsfähig" geändert. Daher wird ein ausgefallener primärer IP-Server, der wiederhergestellt wird, nachdem er für gewisse Zeit den Status "sekundär – ausgefallen" hatte, niemals den momentan primären Server verdrängen, sondern vielmehr in den Status "sekundär – betriebsfähig" kommen.
  • Außerdem wird der Status jedes Netzrouters in einem Router-Pool überwacht. Wenn der Netzrouter ausfällt, wird der gesamte Verkehr, der an diesen Netzrouter gerichtet ist, transparent zu einem anderen Netzrouter in dem Router-Pool umgeleitet, bis der Netzrouter wiederhergestellt ist. Es ist keine Intervention von den IP-Servern aus erforderlich, da die Umleitung vollständig durch die Netzfluss-Vermittlungseinrichtung abgewickelt wird.
  • Die 5A–5C stellen mehrere mögliche Hardware-Implementierungen der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) dar. Jede der Hardware-Implementierungen aus den 5A–5C stellt einen anderen Kompromiss zwischen einer einfachen Implementierung und der Leistungsfähigkeit der Netzfluss-Vermittlungseinrichtung dar. Beispielsweise erfordert die Hardware-Implementierung aus 5A keinerlei spezielle Hardware und kann mit Hilfe von handelsüblichen Komponenten implementiert werden.
  • In den 5A–5D stellt die CPU einen Prozessor Modell R-4700 dar, der bei der Integrated Devise Technology Inc., San Jose, Kalifornien erhältlich ist, der Speicher-Controller stellt einen Controller Modell GT-64010 dar, der von der Galileo Technologies Ltd., Karmiel, Israel erhältlich ist, und die Ethernet-Controller stellen Ethernet-Controller Modell GT-48002 dar, die ebenfalls bei der Galileo Technologies erhältlich sind. Wenngleich diese speziellen Hardware-Komponenten der Deutlichkeit halber beschrieben sind, ist die Erfindung nicht auf die speziellen Komponenten, Hersteller oder Modellnummern begrenzt. Anstatt der in den
  • 5A–5C beschriebenen Komponenten können auch andere Komponenten, die von anderen Herstellern hergestellt werden, und mit anderen Modellnummern, verwendet werden.
  • 5A zeigt eine erste Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 mit einer CPU-Karte 500 und mehreren Ethernet-Karten 510, 520, 530 und 540. Die CPU-Karte 500 weist einen Prozessor R-4700 auf, der mit einem asynchronen E/A-Controller 85C30 und mit einem Speicher-Controller GT-64010 verbunden ist. Der asynchrone Controller ist wiederum mit einem Paar Eingangs-/Ausgangs-Ports RS232/DB-25 verbunden, zur Kopplung mit anderen Einrichtungen. Der Speicher-Controller ist außer mit dem PCI-Bus 410 auch mit einem EPROM mit 512 kB, einem RAM mit 8 MB und einem Flash-Speicher mit 2MB verbunden. Die Ethernet-Karten 510, 520, 530 und 540 weisen einen Ethernet-Controller GT-48002, einen EDO RAM mit 1 MB und ein Paar Eingangs-/Ausgangs-Ports auf. Die CPU-Karte 500 und die Ethernet-Karten 510, 520, 530 und 540 stellen Allzweck-Schaltungskarten dar, die bei der Galileo Technologies erhältlich sind. Infolgedessen kann die Netzfluss-Vermittlungseinrichtung 205 nur mit Hilfe von Allzweck-Komponenten implementiert werden, wie in 5A dargestellt ist.
  • 5B stellt eine zweite Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) dar. In 5B wird anstelle der Allzweck-Netzkarten aus 5A eine Spezial-Netzkarte 560 genutzt. Somit sind die Ethernet-Karten 510, 520, 530 und 540 durch eine einzige Netzkarte 560 ersetzt. Die Netzkarte 650 umfasst ihrerseits mehrere Ethernet-Controller, die jeweils mit einem Paar Eingangs-/Ausgangs-Ports sowie mit einem karteninternen PCI-Bus verbunden sind. Der externe PCI-Bus aus 5A fällt vollständig weg. Die Hardware-Implementierung aus 5B bietet ein verbessertes Leistungsverhalten sowie eine Kostenreduzierung gegenüber der Hardware-Implementierung aus 5A, auf Kosten des Hinzufügens von Spezial-Hardware.
  • 5C stellt eine dritte Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) dar. In 5C werden anstelle der Allzweck-Schaltungskarten aus 5A zwei Spezial-Schaltungskarten genutzt. Die CPU-Karte 550 weist die gleichen Komponenten wie die CPU-Karte 500 aus 5A auf, außer dass ein FSRAM mit 4 MB hinzugefügt ist. Zusätzlich könnten ein inhaltsadressierbarer Speicher (CAM) sowie schnelle PLDs hinzugefügt werden, um das Leistungsverhalten der CPU-Karte 550 zu beschleunigen. Die Ethernet-Karten 510, 520, 530 und 540 sind jedoch durch eine einzige Netzkarte 560 ersetzt, wie mit Bezug auf 5B erklärt worden ist. Die Hardware-Implementierung aus 5C bietet ein besseres Leistungsverhalten gegenüber der Hardware-Implementierung aus den 5A und 5B (d. h. eine Unterstützung für Übertragungsraten von 100 Mbit/s und ein schnelleres CPU-Verhalten), auf Kosten des Hinzufügens von Spezial-Hardware.
  • 5D stellt noch eine dritte Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) dar, bei welcher die gesamte Vermittlungseinrichtung auf einer einzigen Schaltungskarte 570 bereitgestellt wird. Die Schaltungskarte 570 weist sämtliche Komponenten der CPU-Karte 550 und der Netzkarte 560 aus 5C auf, außer dass der karteninterne PCI-Bus durch einen Pufferspeicher-Arbiter ersetzt ist. Das Eliminieren des PCI-Busses ermöglicht ein noch weiter verbessertes Leistungsverhalten (Übertragungsraten von mehr als 1 Gbit/s), auf Kosten einer teureren Spezial-Hardware.
  • 5E stellt eine weitere Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) dar, bei welcher eine Spezial-Schaltungskarte 575 in Kombination mit Ethernet-Karten 510, 520, 530 und 540 (5A) genutzt wird. Die Schaltungskarte 575 weist die gleichen Komponenten wie die Schaltungskarte 500 aus 5A auf, außer dass ein CPLD 585 und ein Doppelport-SRAM 580 hinzugefügt sind. Die Schaltungskarte 575 ist mit den Ethernet-Karten 510, 520, 530 und 540 über den PCI-Bus 410 verbunden. Bei dieser Ausführungsform erfolgen die Übersetzungen der Sicherungsschicht-Adresse durch den CPLD 585 anstatt durch die CPU R-4700, was eine schnellere Verarbeitung von Paketen ermöglicht. Die CPU R-4700 führt immer noch Verwaltungsaufgaben aus, beispielsweise das periodische Überprüfen der Lasten an jedem der IP-Server, das Erkennen von Ausfällen von IP-Servern und Netzroutern, usw.
  • 5F stellt eine weitere Hardware-Implementierung der Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) mit Hilfe eines Crossbar-Switch anstelle des PCI-Busses 410 dar. In 5F verbindet der Crossbar-Switch 594 die Verwaltungsprozessorkarten 590 und 592 mit Ethernet-Karten 582 und 584 sowie Schaltungskarten 586 und 588. Jede der Schaltungskarten 586 und 588 umfasst einen ASIC 596, welcher eine Nachschlagetabelle 598 mit einem Sicherungsschicht-Chip 595 verbindet. Bei dieser Ausführungsform werden die Verwaltungsprozessorkarten 590 und 592 genutzt, um Verwaltungsaufgaben auszuführen, wie zuvor im Zusammenhang mit 5E beschrieben, die Ethernet-Karten 582 und 584 werden für den abgehenden Paketfluss genutzt, wie zuvor im Zusammenhang mit 5A beschrieben, und die Schaltungskarten 586 und 588 werden genutzt, um die Sicherungsschicht-Adressfelder der eingehenden Pakete zu übersetzen. Dies wird erreicht, indem das Sicherungsschicht-Zieladressfeld des Pakets in dem Sicherungsschicht-Chip 595 extrahiert wird und ein schneller Suchvorgang in der Nachschlagtabelle 598 erfolgt, in welcher die Sicherungsschicht-Adresse des IP-Servers mit einer optimalen Last gespeichert ist. Sicherungsschicht-Chips, die zur Nutzung bei der vorliegenden Erfindung geeignet sind, sind unter anderem bei der Galileo Technologies, bei I-Cube und bei der MMC Networks erhältlich. Wenn eine Fehlertoleranz für die Netzrouter bereitgestellt wird, werden die Schaltungskarten 586 und 588 außerdem genutzt, um das Sicherungsschicht-Adressfeld abgehender Pakete, die aufgrund eines Netzrouter-Ausfalls umgeleitet werden, zu übersetzen.
  • Um das Leistungsverhalten zu verbessern, sollte jeder der IP-Server 210, 220, 230, 240 und 250 sowie der Router 260, 270 und 280 (entweder direkt oder über ein Netzwerk) mit der Netzfluss-Vermittlungseinrichtung 205 über einen Vermittlungsport (Switched Port) mit fest zugeordneter Vollduplex-Bandbreite verbunden sein. Die Netzfluss-Vermittlungseinrichtung 205 (2 und 4A) funktioniert jedoch selbst für den Fall gut, dass sie mit einem der IP-Server über einen gemeinsam genutzten Medienport (Shared Media) verbunden ist. Jeder der IP-Server 210, 220, 230, 240 und 250 ist somit anders konfiguriert, in Abhängigkeit davon, ob der Server mit der Netzfluss-Vermittlungseinrichtung 205 über einen gemeinsam genutzten anstatt einen Vermittlungsport verbunden ist. Jeder IP-Server wird automatisch im Moment des Hochfahrens konfiguriert, indem in dem Server ein Computerprogramm ausgeführt wird.
  • Bei einer Ausführungsform der Erfindung sind alle oder einige der Router und Server mit Hilfe von Vermittlungsleitungen auf der Sicherungsschicht verbunden. Damit wird für jede Einrichtung, die mit der Flussvermittlungseinrichtung verbunden ist, (a) eine dedizierte Bandbreite und (b) ein Vollduplex-Betrieb zur Verfügung gestellt. Fachleute auf dem Gebiet werden jedoch erkennen, dass die Netzfluss-Vermittlungseinrichtung gemäß der vorliegenden Erfindung auch auf nicht vermittelte Umgebungen angewendet werden kann (z. B. Ethernet-Hubs mit gemeinsam genutzten Medien (Shared Media) oder gemeinsam genutzte Ports unter Verwendung von kaskadierten Ethernet-Switchen.
  • Die vorstehend beschriebenen Ausführungsformen veranschaulichen die Erfindung, schränken diese aber nicht ein. Insbesondere ist die Erfindung nicht auf irgendwelche spezielle Hardware beschränkt, die genutzt wird, um die Netzfluss-Steuerungsvermittlungseinrichtung zu implementieren. Die Erfindung ist in jedem Fall nicht auf irgendeine spezielle Anzahl von Ethernet-Karten oder irgendeine spezielle Art von Prozessor, Speicher-Controller oder Bus eingeschränkt. Insbesondere kann eine beliebige Anzahl von Ethernet-Cards mit einer beliebig großen Anzahl von physischen Verbindungsports entsprechend der vorliegenden Erfindung genutzt werden. Erfindungsgemäß können auch andere Prozessoren als der R-4700 und der GT-64010 genutzt werden. Es können andere Ethernet-Vermittlungs-ASICs als der GT-48002A von Galileo genutzt werden, von Galileo oder von anderen Anbietern wie beispielsweise I-Cube oder MMC Networks. Darüber hinaus kann anstelle der CPU 402 und des Speicher-Controllers 406 (4A) ein einziger Prozessor genutzt werden. Anstelle eines PCI-Busses 410 (4A) können andere Busse als ein PCI-Bus (z. B. SCSI-Busse) oder sogar Crossbar-Switche genutzt werden. Schließlich können anstelle der Ethernet-Karten 415, 416, 417 und 418 (4A) andere Netzkarten als Ethernet-Karten genutzt werden. Darüber hinaus ist die Erfindung nicht auf irgendeine Art oder Anzahl von Netzkarten eingeschränkt. Tatsächlich kann die Erfindung auf eine beliebige Anzahl von Netzkarten angewandt werden, die mit einer beliebigen Anzahl von Netzen verbunden sind. Auch andere Ausführungsformen und Varianten fallen in den Schutzumfang der Erfindung, wie er durch die folgenden Ansprüche definiert wird.

Claims (10)

  1. Netzfluss-Vermittlungseinrichtung (205) zum Weiterleiten von Paketen zu einer Mehrzahl (200) von IP-Servern (210–250) und von diesen weg, wobei jeder der IP-Server eine gleiche IP-Adresse (290) sowie eine Sicherungsschicht(Data Link Layer)-Adresse, die sich von der Sicherungsschicht-Adresse der anderen IP-Server unterscheidet, aufweist, und wobei die Netzfluss-Vermittlungseinrichtung umfasst: einen Prozessor (402); einen Speicher (404), der mit dem Prozessor verbunden ist; und eine Mehrzahl von Netzports (415–418), die mit einem Netzwerk verbunden sind; dadurch gekennzeichnet, dass die Netzfluss-Vermittlungseinrichtung dafür ausgelegt ist, ein Paket (300), das an einem ersten Netzport empfangen (420) wird, zu einem zweiten Netzport weiterzuleiten (445), indem sie eine Sicherungsschicht Adresse eines der IP-Server in das Paket schreibt (440).
  2. Vermittlungseinrichtung nach Anspruch 1, bei welcher jeder Netzport (510–540) ferner einen Controller und einen Speicher umfasst und bei welcher das Weiterleiten von Paketen von einem der IP-Server zu einem Netzwerk-Ziel keine Intervention durch den Prozessor erfordert.
  3. Vermittlungseinrichtung nach Anspruch 1, bei welcher das Paket entsprechend einem anderen ISO-Schicht-4-Transportprotokoll als TCP kodiert ist.
  4. Verfahren zum Weiterleiten von Paketen zu einer Mehrzahl (200) von IP-Servern (210–250) und von diesen weg, wobei jeder der IP-Server eine gleiche IP-Adresse (290) sowie eine Sicherungsschicht-Adresse, die sich von der Sicherungsschicht-Adresse der anderen IP-Server unterscheidet, aufweist, wobei das Verfahren umfasst: Empfangen eines Pakets (300) für die IP-Adresse der IP-Server; und Weiterleiten des Pakets an zumindest einen der IP-Server; dadurch gekennzeichnet, dass das Empfangen umfasst: Empfangen (420) des Pakets in einer Netzfluss-Vermittlungseinrichtung (205), welche der IP-Adresse der IP-Server entspricht; und das Weiterleiten umfasst: Weiterleiten (445) des Pakets an den zumindest einen der IP-Server durch Schreiben (440) der Ziel-Sicherungsschicht-Adresse des IP-Servers in das Paket in der Netzfluss-Vermittlungseinrichtung.
  5. Verfahren nach Anspruch 4, ferner umfassend: Empfangen (450) eines Pakets in der Netzfluss-Vermittlungseinrichtung von einem der IP-Server; Extrahieren (465) einer Zieladresse aus dem Paket; und Weiterleiten (465) des Pakets zu einem Netzwerk-Ziel basierend auf der Zieladresse des Pakets.
  6. Verfahren nach Anspruch 5, bei welchem das Weiterleiten des Pakets keine Intervention durch einen Prozessor (402) der Netzfluss-Vermittlungseinrichtung erfordert.
  7. Verfahren nach Anspruch 4, bei welchem das Paket entsprechend einem anderen ISO-Schicht-4-Transportprotokoll als TCP kodiert wird.
  8. Verfahren nach Anspruch 4 zum Ausführen einer fehlertoleranten Lenkung von Paketen zu einem von einer Mehrzahl von IP-Servern und von diesem weg, ferner umfassend: Senden eines oder mehrerer Pakete von einem Client aus, der mit einem Netzwerk mit einem Netzrouter (260–280) verbunden ist; kontinuierliches Überwachen (425–435), und zwar in einer Netzfluss-Vermittlungseinrichtung, eines Status' jedes der Mehrzahl von IP-Servern, welche die gleiche IP-Adresse sowie eine Sicherungsschicht-Adresse, die sich von der Sicherungsschicht-Adresse der anderen IP-Server unterscheidet, aufweisen; und Weiterleiten (420, 440, 445) der Pakete durch die Netzfluss-Vermittlungseinrichtung von dem Netzrouter zu einem der Mehrzahl von IP-Servern in einem Betriebsstatus.
  9. Verfahren nach Anspruch 8, bei welchem die Pakete entsprechend einem anderen ISO-Schicht-4-Transportprotokoll als TCP kodiert werden.
  10. Computerlesbares Medium (404), welches Anweisungen enthält, die, wenn sie in einem Computer (205) ausgeführt werden, bewirken, dass der Computer alle Verfahrensschritte gemäß einem der Ansprüche 4 bis 9 ausführt.
DE69837938T 1997-12-19 1998-12-04 Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung Expired - Lifetime DE69837938T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/994,709 US6266335B1 (en) 1997-12-19 1997-12-19 Cross-platform server clustering using a network flow switch
US994709 1997-12-19
PCT/US1998/025688 WO1999033227A1 (en) 1997-12-19 1998-12-04 Cross-platform server clustering using a network flow switch

Publications (2)

Publication Number Publication Date
DE69837938D1 DE69837938D1 (de) 2007-07-26
DE69837938T2 true DE69837938T2 (de) 2008-02-14

Family

ID=25540967

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69837938T Expired - Lifetime DE69837938T2 (de) 1997-12-19 1998-12-04 Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung

Country Status (6)

Country Link
US (1) US6266335B1 (de)
EP (1) EP1048145B1 (de)
AU (1) AU760125B2 (de)
CA (1) CA2319436C (de)
DE (1) DE69837938T2 (de)
WO (1) WO1999033227A1 (de)

Families Citing this family (134)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE536588T1 (de) * 1996-07-25 2011-12-15 Xcelera Inc Web-server system mit primären und sekundären servern
US7055173B1 (en) 1997-12-19 2006-05-30 Avaya Technology Corp. Firewall pooling in a network flowswitch
US6418493B1 (en) * 1997-12-29 2002-07-09 Intel Corporation Method and apparatus for robust addressing on a dynamically configurable bus
JP4273535B2 (ja) * 1998-05-12 2009-06-03 ソニー株式会社 データ伝送制御方法、データ伝送システム、データ受信装置及びデータ送信装置
US6377990B1 (en) * 1998-06-15 2002-04-23 Lodgenet Entertainment Corporation System for providing internet access from locations different from those for which the user's software was configured
US6665702B1 (en) 1998-07-15 2003-12-16 Radware Ltd. Load balancing
US6691165B1 (en) 1998-11-10 2004-02-10 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US7194554B1 (en) 1998-12-08 2007-03-20 Nomadix, Inc. Systems and methods for providing dynamic network authorization authentication and accounting
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US6912590B1 (en) * 1998-12-18 2005-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Single IP-addressing for a telecommunications platform with a multi-processor cluster using a distributed socket based internet protocol (IP) handler
US6587431B1 (en) * 1998-12-18 2003-07-01 Nortel Networks Limited Supertrunking for packet switching
US6665304B2 (en) * 1998-12-31 2003-12-16 Hewlett-Packard Development Company, L.P. Method and apparatus for providing an integrated cluster alias address
US6671273B1 (en) 1998-12-31 2003-12-30 Compaq Information Technologies Group L.P. Method for using outgoing TCP/IP sequence number fields to provide a desired cluster node
US6549538B1 (en) 1998-12-31 2003-04-15 Compaq Information Technologies Group, L.P. Computer method and apparatus for managing network ports cluster-wide using a lookaside list
US6618377B1 (en) * 1999-03-30 2003-09-09 Cisco Technology, Inc. Flexible scheduling of network devices within redundant aggregate configurations
US6671259B1 (en) * 1999-03-30 2003-12-30 Fujitsu Limited Method and system for wide area network load balancing
US6801949B1 (en) 1999-04-12 2004-10-05 Rainfinity, Inc. Distributed server cluster with graphical user interface
US7299294B1 (en) 1999-11-10 2007-11-20 Emc Corporation Distributed traffic controller for network data
AU4344900A (en) * 1999-04-12 2000-11-14 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US6754220B1 (en) * 1999-05-31 2004-06-22 International Business Machines Corporation System and method for dynamically assigning routers to hosts through a mediator
US7346695B1 (en) 2002-10-28 2008-03-18 F5 Networks, Inc. System and method for performing application level persistence
US6970933B1 (en) 1999-07-15 2005-11-29 F5 Networks, Inc. Enabling application level persistence between a server and another resource over a network
US7287084B1 (en) 1999-07-15 2007-10-23 F5 Networks, Inc. Enabling encryption of application level persistence between a server and a client
US6901517B1 (en) * 1999-07-16 2005-05-31 Marconi Communications, Inc. Hardware based security groups, firewall load sharing, and firewall redundancy
US6430622B1 (en) * 1999-09-22 2002-08-06 International Business Machines Corporation Methods, systems and computer program products for automated movement of IP addresses within a cluster
FI107972B (fi) * 1999-10-11 2001-10-31 Stonesoft Oy Tiedonsiirtomenetelmä
US6667980B1 (en) * 1999-10-21 2003-12-23 Sun Microsystems, Inc. Method and apparatus for providing scalable services using a packet distribution table
WO2001031885A2 (en) 1999-10-22 2001-05-03 Nomadix, Inc. Gateway device having an xml interface and associated method
AU4347600A (en) * 1999-11-10 2001-06-06 Rainfinity, Inc. Distributed traffic controlling system and method for network data
US6917626B1 (en) * 1999-11-30 2005-07-12 Cisco Technology, Inc. Apparatus and method for automatic cluster network device address assignment
US6636499B1 (en) 1999-12-02 2003-10-21 Cisco Technology, Inc. Apparatus and method for cluster network device discovery
US6493341B1 (en) * 1999-12-31 2002-12-10 Ragula Systems Combining routers to increase concurrency and redundancy in external network access
US6687748B1 (en) * 2000-01-04 2004-02-03 Cisco Technology, Inc. Network management system and method of operation
US6748429B1 (en) 2000-01-10 2004-06-08 Sun Microsystems, Inc. Method to dynamically change cluster or distributed system configuration
US6735205B1 (en) * 2000-01-10 2004-05-11 Sun Microsystems, Inc. Method and apparatus for fast packet forwarding in cluster networking
US6862613B1 (en) 2000-01-10 2005-03-01 Sun Microsystems, Inc. Method and apparatus for managing operations of clustered computer systems
US6789213B2 (en) 2000-01-10 2004-09-07 Sun Microsystems, Inc. Controlled take over of services by remaining nodes of clustered computing system
US6735206B1 (en) 2000-01-10 2004-05-11 Sun Microsystems, Inc. Method and apparatus for performing a fast service lookup in cluster networking
US6725264B1 (en) * 2000-02-17 2004-04-20 Cisco Technology, Inc. Apparatus and method for redirection of network management messages in a cluster of network devices
US6785273B1 (en) * 2000-03-20 2004-08-31 International Business Machines Corporation Traffic engineering for an application employing a connectionless protocol on a network
US6880089B1 (en) 2000-03-31 2005-04-12 Avaya Technology Corp. Firewall clustering for multiple network servers
DE10016236C2 (de) * 2000-03-31 2003-12-24 Infineon Technologies Ag Modular aufgebauter Server
US6779039B1 (en) * 2000-03-31 2004-08-17 Avaya Technology Corp. System and method for routing message traffic using a cluster of routers sharing a single logical IP address distinct from unique IP addresses of the routers
US6732175B1 (en) 2000-04-13 2004-05-04 Intel Corporation Network apparatus for switching based on content of application data
US7146422B1 (en) 2000-05-01 2006-12-05 Intel Corporation Method and apparatus for validating documents based on a validation template
GB2362538B (en) * 2000-05-20 2002-05-08 3Com Corp Method for synchronising databases in stacked network units
US6760859B1 (en) 2000-05-23 2004-07-06 International Business Machines Corporation Fault tolerant local area network connectivity
US7318107B1 (en) 2000-06-30 2008-01-08 Intel Corporation System and method for automatic stream fail-over
US7020709B1 (en) 2000-06-30 2006-03-28 Intel Corporation System and method for fault tolerant stream splitting
US6735220B1 (en) 2000-08-01 2004-05-11 Sun Microsystems, Inc. Using a centralized server to coordinate assignment of identifiers in a distributed system
US6772226B1 (en) * 2000-08-15 2004-08-03 Avaya Technology Corp. VPN device clustering using a network flow switch and a different mac address for each VPN device in the cluster
US6731598B1 (en) 2000-09-28 2004-05-04 Telefonaktiebolaget L M Ericsson (Publ) Virtual IP framework and interfacing method
US8250570B2 (en) 2000-10-31 2012-08-21 Hewlett-Packard Development Company, L.P. Automated provisioning framework for internet site servers
US20020082821A1 (en) * 2000-10-31 2002-06-27 Glenn Ferguson Data model for automated server configuration
WO2002061525A2 (en) * 2000-11-02 2002-08-08 Pirus Networks Tcp/udp acceleration
US20020167945A1 (en) * 2000-11-22 2002-11-14 Yeshik Shin Method and system for packet ordering based on packet type
US7002973B2 (en) 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7072303B2 (en) 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US20020087724A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A Fatpipe Networks Combining connections for parallel access to multiple frame relay and other private networks
US20020087722A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A/ Fatpipe Networks Domain name resolution making IP address selections in response to connection status when multiple connections are present
US6651141B2 (en) 2000-12-29 2003-11-18 Intel Corporation System and method for populating cache servers with popular media contents
US8615652B2 (en) * 2001-01-02 2013-12-24 Scott D. Redmond System and method for providing load balanced secure media content and data delivery in a distributed computing environment
US7587500B2 (en) * 2001-01-10 2009-09-08 Xcelera Distributed selection of a content server
US7340530B2 (en) * 2001-01-17 2008-03-04 International Business Machines Corporation Methods, for providing data from network secure communications in a cluster computing environment
US20020103921A1 (en) * 2001-01-31 2002-08-01 Shekar Nair Method and system for routing broadband internet traffic
US7743147B2 (en) * 2001-04-20 2010-06-22 Hewlett-Packard Development Company, L.P. Automated provisioning of computing networks using a network database data model
US7237033B2 (en) * 2001-04-30 2007-06-26 Aol Llc Duplicating switch for streaming data units to a terminal
US7292571B2 (en) * 2001-04-30 2007-11-06 Aol Llc, A Delaware Limited Liability Company Load balancing with direct terminal response
US8572278B2 (en) 2001-04-30 2013-10-29 Facebook, Inc. Generating multiple data streams from a single data source
US7266609B2 (en) * 2001-04-30 2007-09-04 Aol Llc Generating multiple data streams from a single data source
US7124166B2 (en) 2001-04-30 2006-10-17 Aol Llc Duplicating digital streams for digital conferencing using switching technologies
WO2003105006A1 (en) * 2001-04-30 2003-12-18 America Online, Inc. Load balancing with direct terminal response
US7430609B2 (en) * 2001-04-30 2008-09-30 Aol Llc, A Delaware Limited Liability Company Managing access to streams hosted on duplicating switches
TW576061B (en) * 2001-08-13 2004-02-11 Via Tech Inc Device and method for load balancing of packet switching
JP3539413B2 (ja) * 2001-08-31 2004-07-07 ソニー株式会社 ネットワーク接続装置、ネットワーク接続システム及びネットワーク接続方法
JP2005502239A (ja) * 2001-09-05 2005-01-20 エリ・アビル クライアント側の動的な負荷バランシングシステムの方法および機器
US7475157B1 (en) * 2001-09-14 2009-01-06 Swsoft Holding, Ltd. Server load balancing system
EP1294137A1 (de) * 2001-09-17 2003-03-19 Ragula Systems (dba Fatpipe Networks) Parallelle Benutzung von Routern zur Erhöhung der Brandbreite und Redundanz zu einem externen Netzwerk
US20030079018A1 (en) * 2001-09-28 2003-04-24 Lolayekar Santosh C. Load balancing in a storage network
US7421509B2 (en) * 2001-09-28 2008-09-02 Emc Corporation Enforcing quality of service in a storage network
US20030069981A1 (en) * 2001-10-09 2003-04-10 Koninklijke Philips Electronics N.V. IP hopping for secure data transfer
US7359378B2 (en) 2001-10-11 2008-04-15 International Business Machines Corporation Security system for preventing unauthorized packet transmission between customer servers in a server farm
US7958199B2 (en) * 2001-11-02 2011-06-07 Oracle America, Inc. Switching systems and methods for storage management in digital networks
JP3898498B2 (ja) * 2001-12-06 2007-03-28 富士通株式会社 サーバ負荷分散システム
US7028224B2 (en) * 2002-01-09 2006-04-11 International Business Machines Corporation Network router having an internal automated backup
US7149808B2 (en) * 2002-01-14 2006-12-12 Array Networks, Inc. Application protocol offloading
US6950855B2 (en) 2002-01-18 2005-09-27 International Business Machines Corporation Master node selection in clustered node configurations
US9167036B2 (en) 2002-02-14 2015-10-20 Level 3 Communications, Llc Managed object replication and delivery
JP4080765B2 (ja) * 2002-03-01 2008-04-23 株式会社日立製作所 ネットワークシステム
US7260647B2 (en) * 2002-03-28 2007-08-21 International Business Machines Corporation Method of load balancing traffic among routers in a data transmission system
US7203192B2 (en) * 2002-06-04 2007-04-10 Fortinet, Inc. Network packet steering
US8447963B2 (en) 2002-06-12 2013-05-21 Bladelogic Inc. Method and system for simplifying distributed server management
US8028092B2 (en) 2002-06-28 2011-09-27 Aol Inc. Inserting advertising content
US7167912B1 (en) * 2002-08-09 2007-01-23 Cisco Technology, Inc. Method and apparatus for detecting failures in network components
US7289500B1 (en) 2003-07-17 2007-10-30 Novell, Inc. Method and system for reliable multicast data transmission
US8438302B2 (en) * 2002-08-22 2013-05-07 International Business Machines Corporation Splitting and sharing routing information among several routers acting as a single border router
US7430755B1 (en) 2002-09-03 2008-09-30 Fs Networks, Inc. Method and system for providing persistence in a secure network access
US7529842B2 (en) * 2002-12-17 2009-05-05 International Business Machines Corporation Method, system and program product for detecting an operational risk of a node
US20040199569A1 (en) * 2003-02-18 2004-10-07 Mohan Kalkunte Method and system for handling traffic for server systems
JP4087271B2 (ja) * 2003-03-19 2008-05-21 株式会社日立製作所 代理応答装置およびネットワークシステム
US7710867B1 (en) 2003-05-23 2010-05-04 F5 Networks, Inc. System and method for managing traffic to a probe
US7650402B1 (en) * 2003-06-25 2010-01-19 Cisco Technology, Inc. System and method for tracking end users in a loadbalancing environment
US7668935B2 (en) * 2003-08-29 2010-02-23 Kabushiki Kaisha Toshiba Computer system and method for service load distributing
US7376859B2 (en) * 2003-10-20 2008-05-20 International Business Machines Corporation Method, system, and article of manufacture for data replication
US8526427B1 (en) 2003-10-21 2013-09-03 Cisco Technology, Inc. Port-based loadsharing for a satellite switch
CN1312889C (zh) * 2003-12-17 2007-04-25 浪潮电子信息产业股份有限公司 集群网络的单一地址流量分发器
US8990430B2 (en) 2004-02-19 2015-03-24 Cisco Technology, Inc. Interface bundles in virtual network devices
JP2005301436A (ja) * 2004-04-07 2005-10-27 Hitachi Ltd クラスタシステムおよびクラスタシステムにおける障害回復方法
US7889733B2 (en) * 2004-04-28 2011-02-15 Cisco Technology, Inc. Intelligent adjunct network device
US7808983B2 (en) 2004-07-08 2010-10-05 Cisco Technology, Inc. Network device architecture for centralized packet processing
US8730976B2 (en) * 2004-08-17 2014-05-20 Cisco Technology, Inc. System and method for preventing erroneous link aggregation due to component relocation
US8009668B2 (en) * 2004-08-17 2011-08-30 Hewlett-Packard Development Company, L.P. Method and apparatus for router aggregation
US20060120291A1 (en) * 2004-12-03 2006-06-08 Chao-Hung Wu System structure for increasing the performance of data transmission on the internet
JP4398354B2 (ja) * 2004-12-20 2010-01-13 富士通株式会社 中継システム
US8072978B2 (en) * 2005-03-09 2011-12-06 Alcatel Lucent Method for facilitating application server functionality and access node comprising same
US7895308B2 (en) * 2005-05-11 2011-02-22 Tindall Steven J Messaging system configurator
EP1744515B1 (de) 2005-07-12 2011-07-13 Fujitsu Siemens Computers, Inc. Methode, Clustersystem und Computer lesbares Medium zur Verteilung von Datenpaketen
US8566452B1 (en) 2006-08-03 2013-10-22 F5 Networks, Inc. Intelligent HTTP based load-balancing, persistence, and application traffic management of SSL VPN tunnels
US9137287B2 (en) * 2006-08-28 2015-09-15 Avaya Inc. High availability for voice enabled applications
US8626936B2 (en) * 2008-01-23 2014-01-07 International Business Machines Corporation Protocol independent server replacement and replication in a storage area network
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US9762692B2 (en) 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
CN102047244B (zh) 2008-04-04 2013-02-27 第三雷沃通讯有限责任公司 在内容分发网络(cdn)中处理长尾内容
WO2010071884A2 (en) * 2008-12-19 2010-06-24 Watchguard Technologies, Inc. Self-monitoring cluster of network security devices
KR100938738B1 (ko) * 2009-08-13 2010-01-26 삼성에스디에스 주식회사 전자 패치 장치, 네트워크 시스템 및 네트워크 시스템에서의 동작 방법
US20120066487A1 (en) * 2010-09-09 2012-03-15 Novell, Inc. System and method for providing load balancer visibility in an intelligent workload management system
US9705977B2 (en) * 2011-04-20 2017-07-11 Symantec Corporation Load balancing for network devices
US20120297066A1 (en) * 2011-05-19 2012-11-22 Siemens Aktiengesellschaft Method and system for apparatus means for providing a service requested by a client in a public cloud infrastructure
US9148367B2 (en) * 2012-10-02 2015-09-29 Cisco Technology, Inc. System and method for binding flows in a service cluster deployment in a network environment
US9661031B1 (en) * 2012-11-27 2017-05-23 Cisco Technology, Inc. Method and apparatus to establish communication for layer 2 switched packets with network address translation (NAT)
US9397939B2 (en) * 2014-06-24 2016-07-19 International Business Machines Corporation Hybrid approach for performance enhancing proxies
WO2015196495A1 (zh) * 2014-06-28 2015-12-30 华为技术有限公司 网络资源均衡的方法和装置
CN114785762A (zh) * 2022-03-23 2022-07-22 深圳市飞泉云数据服务有限公司 云计算系统的实现方法、装置、终端设备以及存储介质

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5283897A (en) 1990-04-30 1994-02-01 International Business Machines Corporation Semi-dynamic load balancer for periodically reassigning new transactions of a transaction type from an overload processor to an under-utilized processor based on the predicted load thereof
FR2686755A1 (fr) 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
US5301226A (en) * 1992-02-05 1994-04-05 Octel Communications Corporation Voice processing systems connected in a cluster
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
US5634125A (en) 1993-09-02 1997-05-27 International Business Machines Corporation Selecting buckets for redistributing data between nodes in a parallel database in the quiescent mode
US5687369A (en) 1993-09-02 1997-11-11 International Business Machines Corporation Selecting buckets for redistributing data between nodes in a parallel database in the incremental mode
JPH07115428A (ja) * 1993-10-20 1995-05-02 Hitachi Ltd 遠隔電源制御方式
EP0750768B1 (de) * 1994-03-15 2002-08-28 Digi International Inc. System und verfahren zur kommunikation mit einem entfernten netzwerk-apparatus
US5473599A (en) 1994-04-22 1995-12-05 Cisco Systems, Incorporated Standby router protocol
US5608447A (en) * 1994-05-27 1997-03-04 Bell Atlantic Full service network
FR2722591B1 (fr) 1994-07-13 1996-08-30 Bull Sa Systeme informatique ouvert a serveurs multiples
US5655140A (en) 1994-07-22 1997-08-05 Network Peripherals Apparatus for translating frames of data transferred between heterogeneous local area networks
JP3224963B2 (ja) * 1994-08-31 2001-11-05 株式会社東芝 ネットワーク接続装置及びパケット転送方法
WO1996017306A2 (en) * 1994-11-21 1996-06-06 Oracle Corporation Media server
US5764895A (en) * 1995-01-11 1998-06-09 Sony Corporation Method and apparatus for directing data packets in a local area network device having a plurality of ports interconnected by a high-speed communication bus
US5513314A (en) 1995-01-27 1996-04-30 Auspex Systems, Inc. Fault tolerant NFS server system and mirroring protocol
JP2708009B2 (ja) 1995-03-17 1998-02-04 日本電気株式会社 Ｌａｎ間接続装置及び接続方式
US5586121A (en) 1995-04-21 1996-12-17 Hybrid Networks, Inc. Asymmetric hybrid access system and method
US5612865A (en) 1995-06-01 1997-03-18 Ncr Corporation Dynamic hashing method for optimal distribution of locks within a clustered system
US5812819A (en) * 1995-06-05 1998-09-22 Shiva Corporation Remote access apparatus and method which allow dynamic internet protocol (IP) address management
US5774668A (en) * 1995-06-07 1998-06-30 Microsoft Corporation System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing
US5666487A (en) * 1995-06-28 1997-09-09 Bell Atlantic Network Services, Inc. Network providing signals of different formats to a user by multplexing compressed broadband data with data of a different format into MPEG encoded data stream
US6097882A (en) * 1995-06-30 2000-08-01 Digital Equipment Corporation Method and apparatus of improving network performance and network availability in a client-server network by transparently replicating a network service
US5835696A (en) 1995-11-22 1998-11-10 Lucent Technologies Inc. Data router backup feature
US5740375A (en) * 1996-02-15 1998-04-14 Bay Networks, Inc. Forwarding internetwork packets by replacing the destination address
US5781549A (en) * 1996-02-23 1998-07-14 Allied Telesyn International Corp. Method and apparatus for switching data packets in a data network
US5959990A (en) * 1996-03-12 1999-09-28 Bay Networks, Inc. VLAN frame format
US5612897A (en) * 1996-03-21 1997-03-18 Digital Equipment Corporation Symmetrically switched multimedia system
US5754752A (en) * 1996-03-28 1998-05-19 Tandem Computers Incorporated End-to-end session recovery
JPH09321789A (ja) 1996-05-30 1997-12-12 Hitachi Ltd ルータが２重化されたネットワークシステムおよびルータが２重化されたネットワークシステムの障害対策方法
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US5796941A (en) 1996-09-06 1998-08-18 Catalyst Semiconductor, Inc. Method for supervising software execution in a license restricted environment
US5920699A (en) * 1996-11-07 1999-07-06 Hewlett-Packard Company Broadcast isolation and level 3 network switch
JP3638742B2 (ja) * 1996-11-29 2005-04-13 アンリツ株式会社 ルータ
US5862338A (en) * 1996-12-30 1999-01-19 Compaq Computer Corporation Polling system that determines the status of network ports and that stores values indicative thereof
CA2206737C (fr) * 1997-03-27 2000-12-05 Bull S.A. Architecture en reseau de machine informatique
US5949753A (en) * 1997-04-11 1999-09-07 International Business Machines Corporation Redundant internet protocol gateways using local area network emulation
US5936936A (en) * 1997-04-11 1999-08-10 International Business Machines Corporation Redundancy mechanisms for classical internet protocol over asynchronous transfer mode networks
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6601084B1 (en) 1997-12-19 2003-07-29 Avaya Technology Corp. Dynamic load balancer for multiple network servers

Also Published As

Publication number Publication date
DE69837938D1 (de) 2007-07-26
WO1999033227A1 (en) 1999-07-01
CA2319436C (en) 2007-01-16
EP1048145B1 (de) 2007-06-13
US6266335B1 (en) 2001-07-24
EP1048145A4 (de) 2005-08-10
CA2319436A1 (en) 1999-07-01
AU1803099A (en) 1999-07-12
EP1048145A1 (de) 2000-11-02
AU760125B2 (en) 2003-05-08

Similar Documents

Publication Publication Date Title
DE69837938T2 (de) Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung
DE60026231T2 (de) Verfahren und Vorrichtung zur Durchführung eines Schnellen Dienstnachschlagen in einem Neztwerkgruppen
DE69827201T2 (de) Verfahren und system zur server-netzwerkvermittlung-mehrverbindung
DE60203433T2 (de) Externer Zugriff auf eine gesicherte Vorrichtung in einem privaten Netzwerk
DE60303026T2 (de) System, verfahren und produkt zur verwaltung des datenverkehrs in einem netzwerk
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
DE60221556T2 (de) Verfahren und system zur zustandslosen lastverteilung für ein server-cluster in einem auf ip basierenden telekommunikationsnetz
DE60019640T2 (de) Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
US7343413B2 (en) Method and system for optimizing a network by independently scaling control segments and data flow
DE602005005134T2 (de) Fehlertolerante Netzwerkarchitektur
DE69837691T2 (de) Lastverteilung zwischen Servern in einem TCP/IP-Netz
DE60212626T2 (de) Endknotenunterteilung mittels lokaler identifikatoren
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE112013004187B4 (de) Technologie für Netzwerk-Datenübertragung durch ein Computersystem unter Verwendung von mindestens zwei Datenübertragungsprotokollen
DE69836673T2 (de) Verfahren und Vorrichtung zur Konfigurierung eines Netzknotens um sich selbst Netzübergang zu sein
DE60103088T2 (de) Verfahren zur Herstellung von Weiterleitungslisten für Netzwerkgruppe
DE69915871T2 (de) Verfahren und vorrichtung für ein tcp/ip lastausgleich und wiederherstellung eines prozesses in einem internet protocol (ip) netzwerkgruppensystem.
DE69830491T2 (de) Cut-through -durchschaltung und paketfilterung in einem rechnersystem
DE60025129T2 (de) Verfahren und Vorrichtung zur Bereitstellung von skalierbaren Diensten unter Benutzung einer Paketverteilungstabelle
US6370583B1 (en) Method and apparatus for portraying a cluster of computer systems as having a single internet protocol image
DE10296675T5 (de) Virtuelles Vernetzungssystem und -verfahren in einem Verarbeitungssystem
US20030031183A1 (en) Queue pair resolution in infiniband fabrics
DE102015102871A1 (de) Technologien für verteilten Leitweglenkungstabellennachschlag
DE112019005826T5 (de) Lastverteilter Zugang zu verteilten Endpunkten unter Verwendung globaler Netzwerkadressen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition