DE69837691T2

DE69837691T2 - Lastverteilung zwischen Servern in einem TCP/IP-Netz

Info

Publication number: DE69837691T2
Application number: DE69837691T
Authority: DE
Inventors: Pi-Yu Berkeley Heights Chung; Om P. Austin Damani; Yennun Bridgewater Huang; Chandra M. Warren Kintala; Yi-Min Berkeley Heights Wang
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1997-03-14
Filing date: 1998-03-03
Publication date: 2008-01-10
Anticipated expiration: 2018-03-04
Also published as: CA2230550C; US6470389B1; EP0865180B1; CA2230550A1; DE69837691D1; EP0865180A3; EP0865180A2

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft allgemein Datenkommunikationsnetze, wie zum Beispiel das Internet, und insbesondere Techniken zum Hosten von Netzdiensten auf einem Cluster von Servern, mit dem Daten als Reaktion auf Client-Anforderungen über ein Netz abgeliefert werden, wobei der Cluster von Servern kollektiv von einem Client unter Verwendung eines Einzeladressenbildes identifiziert werden kann.
Allgemeiner Stand der Technik
Mit dem explosiven Wachstum des World Wide Web sind viele populäre Internet-Websites stark mit Client-Anforderungen belastet. Zum Beispiel wurde in S.L. Garfinkel, "The Wizard of Netscape", Webserver Magazine, Juli/August 1996, Seiten 59–63, berichtet, daß Homepages von Netscape Communications mehr als 80 Millionen Client-Anforderungen oder "hits" pro Tag empfangen. Ein einzelner Server, der einen Dienst hustet, reicht gewöhnlich nicht aus, um mit dieser Art von aggressivem Wachstum fertigzuwerden. Folglich können Clients langsame Ansprechzeiten sehen und nicht in der Lage sein, auf bestimmte Websites zuzugreifen. Das Aufrüsten der Server auf leistungsstärkere Maschinen ist möglicherweise nicht immer kosteneffektiv. Bei einem anderen üblichen Ansatz wird eine Menge von Maschinen, die auch als Cluster bezeichnet wird, eingesetzt und die Maschinen werden so konfiguriert, daß sie zusammenarbeiten, um einen einzelnen Dienst zu husten. Ein solcher Server-Cluster sollte vorzugsweise nur einen Servernamen für den gesamten Cluster publizieren, so daß sich eine etwaige Konfigurationsänderung im Innern des Clusters nicht auf Client-Anwendungen auswirkt. Das World Wide Web und andere Teile des Internet benutzen ein Protokoll auf Anwendungsebene, das als Hypertext Transfer Protocol (HTTP) bekannt ist und auf einer Client/Server-Architektur basiert. Das HTTP-Protokoll wird ausführlicher in "Hypertext Transfer Protocol – HTTP/1.0", Network Working Group, Mai 1996, http://www.ics.uci.edu/pub/iet/http, beschrieben.
1 zeigt eine zur Implementierung von Netzdiensten auf HTTP-Basis im Internet geeignete beispielhafte Client/Server-Architektur. Ein Client 12 erzeugt eine HTTP-Anforderung eines bestimmten Dienstes, wie zum Beispiel eine Anforderung von Informationen, die mit einer bestimmten Website assoziiert sind, und dann wird eine TCP/IP-Verbindung (Transmission Control Protocol/Internet Protocol) zwischen dem Client 12 und einem den Dienst hostenden Server 14 hergestellt. Die Client-Anforderung wird in diesem Beispiel über eine TCP/IP-Verbindung über ein erstes Netz 16, einen Router 18 ein zweites Netz 20 an den Server 14 abgeliefert. Das erste Netz 16 kann ein großflächiges Kommunikationsnetz wie etwa das Internet sein, während das zweite Netz 20 ein Ethernet- oder eine andere Art von lokalem Netz (LAN) sein kann, das den Server 14 mit anderen Servern in einem Server-Cluster verbindet. Der Router 18, der auch als Gateway bezeichnet wird, führt eine Weiterleitungsfunktion zwischen dem ersten und dem zweiten Netz aus, die für den Client 12 transparent ist.
Die Client-Anforderung wird durch einen Web-Browser oder ein anderes Anwendungsschicht-Programm erzeugt, das in einer Anwendungsschicht 22-1 des Client 12 operiert und erhält eine Antwort von einem Dateitransfersystem oder einem anderen Programm in einer Anwendungsschicht 22-2 des Servers 14. Der angeforderte Netzdienst kann durch eine URL (Uniform Resource Locator) bezeichnet werden, die einen Domänennamen enthält, der den Server 14 oder ein entsprechendes, den Dienst hostendes Server-Cluster identifiziert. Das Anwendungsebenen-Programm des Client 12 leitet die TCP/IP-Verbindung ein, indem ein lokaler oder abgesetzter Domänennamendienst (DNS) angefordert wird, den Server-Domänennamen auf eine IP-Adresse abzubilden. Die TCP- und IP-Paket-Routing-Funktionen in dem Client 12 und in dem Server 14 werden in den jeweiligen TCP-Schichten 24-1, 24-2 und in den IP-Schichten 26-1, 26-2 bereitgestellt. Die TCP- und IP-Schichten sind im allgemeinen mit der Transport- bzw. Netzschicht des wohlbekannten OSI-Modells (Open Systems Interconnection) assoziiert. Die TCP-Schichten 24-1, 24-2 verabeiten TCP-Pakete der Client-Anforderung und Server-Antwort. Die TCP-Pakete enthalten jeweils einen TCP-Kopfteil, der eine Portnummer der TCP-Verbindung zwischen dem Client 12 und dem Server 14 identifiziert. Die IP-Schichten 26-1, 26-2 verarbeiten aus den TCP-Paketen der TCP-Schichten gebildete IP-Pakete. Die IP-Pakete enthalten jeweils einen IP-Kopfteil, der eine IP-Adresse der TCP/IP-Verbindung zwischen dem Client 12 und dem Server 14 identifiziert.
Die IP-Adresse für einen gegebenen Netzdienst kann wie oben bemerkt bestimmt werden, indem der Client auf einen herkömmlichen DNS zugreift. Die IP-Schicht 26-1 des Client 12 verwendet die resultierende IP-Adresse als Zieladresse in den IP-Paketkopfteilen von Client-Anforderungspaketen. Zusammen mit der TCP-Portnummer stellt die IP-Adresse die vollständige Transportadresse für den HTTP-Serverprozeß bereit. Der Client 12 und der Server 14 enthalten außerdem eine Datenstrecken- und physische Schicht 28-1 zur Durchführung von Framing- und anderen Operationen, um Client-Anforderungen oder Antwortpakete für die Übertragung über die Netze 16 und 20 zu konfigurieren. Der Router 18 enthält eine Datenstrecken- und physische Schicht 28-3 zum Umsetzen von Client-Anforderungs- und Server-Antwortpaketen in das IP-Format und eine IP-Schicht 26-3 zur Durchführung des Paket-Routing auf der Basis von IP-Adressen. Der Server 14 antwortet auf eine gegebene Client-Anforderung, indem er die angeforderten Informationen über die hergestellte TCP/IP-Verbindung in einer Anzahl von Antwortpaketen liefert. Die TCP/IP-Verbindung wird dann geschlossen.
Es gibt viele bekannte Techniken zum Verteilen von HTTP-Client-Anforderungen auf einen Cluster von Servern. 2 und 3 zeigen serverseitige Einzel-IP-Adressen-Bildansätze, die den Clients eine einzige IP-Adresse präsentieren. Ein Beispiel für diesen Ansatz ist der TCP-Router-Ansatz, der in D.M. Dias, W. Kish, R. Mukherjee und R. Tewari, "A Scalable and Highly Available Web Server", Proceedings of COMPCON '96, Seiten 85–92, 1996, beschrieben wird. 2 zeigt den TCP-Router-Ansatz, bei dem ein Client 12 eine TCP/IP-Verbindung über das Internet 30 mit einem serverseitigen Router 32 mit einer IP-Adresse RA herstellt. Der Router 32 ist über ein LAN 36 mit einem Server-Cluster 34 verbunden, das N Server 14-i, i = 1, 2, ... N, mit jeweiligen IP-Adressen S1, S2, ... SN enthält. Jeder Server des Clusters 34 stellt im allgemeinen Zugang zu denselben Inhalten bereit und die Inhalte können auf einer lokalen Platte jedes Servers dupliziert, auf einem Netzdateisystem gemeinsam benutzt oder von einem verteilten Dateisystem versorgt werden.
Das Einzeladressenbild wird erzielt, indem man die Adresse RA des serverseitigen Routers 32 über den DNS zu den Clients publiziert. Der Client 12 verwendet deshalb RA als Ziel-IP-Adresse in seiner Anforderung. Die Anforderung wird zu dem Router 32 geleitet, der dann die Anforderung auf der Basis von Lasteigenschaften wie durch die gestrichelte Linie, die den Client 12 über den Router 32 mit dem Server 14-k verbindet, angegeben zu einem gewählten Server 14-k des Server-Clusters 34 aussendet. Der Router 32 führt diese Aussendungsfunktion durch, indem er die Ziel-IP-Adresse jedes ankommenden IP-Pakets einer gegebenen Client-Anforderung von der Routeradresse RA in die Adresse Sk des gewählten Servers 14-k umändert. Der gewählte Server 14-k antwortet auf die Client-Anforderung, indem er wie durch die gestrichelte Linie, die den Server 14-k mit dem Client 12 verbindet, angegeben Antwortpakete über die hergestellte TCP/IP-Verbindung sendet. Damit die TCP/IP-Verbindung dem Client 12 nahtlos erscheint, ändert der gewählte Server 14-k die Quelle-IP-Adresse in seinen Antwortpaketen von der Adresse Sk in die Routeradresse RA um. Die Vorteile dieses Ansatzes bestehen darin, daß er die Anzahl der TCP-Verbindungen nicht vergrößert und für die Clients völlig transparent ist. Da die oben erwähnte Quellen-IP-Adressenänderung in der IP-Schicht in einem gegebenen Server durchgeführt wird, muß jedoch der Kernel-Code jedes Servers in dem Cluster modifiziert werden, um diesen Mechanismus zu implementieren. Eine vorgeschlagene Hybride des DNS-Ansatzes und des TCP-Router-Ansatzes, bei der ein DNS-Server eines von mehreren Clustern von Servern unter Verwendung einer Reigentechnik auswählt, hat dasselbe Problem.
3 zeigt einen serverseitigen Einzeladressen-Bild-Ansatz, der als Netzadressenübersetzung bekannt ist und ausführlicher in E. Anderson, D. Patterson und E. Brewer, "The Magicrouter, an Application of Fast Packet Interposing", Symposium an Operating Systems Design and Implementation, OSDI, 1996, http://www.cs.berkeley.edu/~eanders/magicrouter/osdi96-mr-submission.ps, und in Cisco Local Director, http://www.cisco.com/warp/public/751/lodir/index.html, beschrieben wird. Wie bei dem TCP-Router-Ansatz von 2 verwendet der Client 12 die Routeradresse RA als Ziel-IP-Adresse in einer Client-Anforderung und der Router 32 sendet die Anforderung zu einem gewählten Server 14-k aus, indem er die Ziel-IP-Adresse jedes ankommenden Anforderungspakets von der Routeradresse RA in die Adresse Sk des gewählten Servers 14-k umändert. Bei dem Netzadressenübersetzungsansatz werden die Quellen-IP-Adressen in den Antwortpaketen von dem gewählten Server 14-k jedoch durch die Server 14-k wie in 2 nicht geändert, sondern werden statt dessen durch den Router 32 geändert. Der durch eine gestrichelte Linie in 2 angezeigte Antwortpaketfluß fließt somit von dem Server 14-k über den Router 32 zu dem Client 12.
Im Vergleich zu dem TCP-Routeransatz von 2 hat die Netzadressenübersetzung den Vorteil der Servertransparenz. Das heißt, es sind keine spezifischen Änderungen an dem Kernel-Code der Server erforderlich, um die Technik zu implementieren. Sowohl der TCP-Router- als auch der Netzadressenübersetzungsansatz erfordern jedoch, daß die Zieladresse in einem Anforderungspaket-Kopfteil in eine Serveradresse umgeändert werden kann, so daß der Server die Anforderung annehmen kann. Diese Ansätze erfordern auch, daß die Quellenadresse in einem Antwortpaket-Kopfteil in die Routeradresse umgeändert wird, so daß der Client die Antwort annehmen kann. Diese Änderungen führen zusätzliches Verarbeitungsoverhead ein und verkomplizieren den Paketablieferungsprozeß unangemessenerweise. Aufgrund der Adressenänderungen können zusätzlich die oben beschriebenen Einzeladressen-Bild-Ansätze nicht für die Verwendung mit Protokollen geeignet sein, die IP-Adressen innerhalb einer Anwendung verwenden, wie zum Bespiel in K. Egevang und P. Francis, "The IP Network Address Translator", Network Working Group, RFC 1631, http://www.safety.net/rfc1631.txt, beschrieben wird. Sowohl bei dem TCP-Router- als auch bei dem Netzadressenübersetzungsansatz muß der Router 32 ferner für jede IP-Verbindung eine IP-Adressenabbildung speichern. Nach dem Empfang eines mit einer existierenden TCP-Verbindung assoziierten ankommenden Pakets muß der Router alle Abbildungen durchsuchen, um zu bestimmen, zu welchem Server das Paket weitergeleitet werden soll. Der Router selbst kann deshalb unter Bedingungen mit großer Last zu einem Engpaß werden, wodurch die Verwendung eines komplexeren Hardware-Entwurfs, wie bei dem oben zitierten Cisco Local Director, notwendig wird.
YEOM H Y ET AL: "IP Multiplexing by Transparent Port-Address Translator", Proceedings of LISA X, Seiten 113–121, beschreibt eine Anordung, bei der sich mehrere Server eine einzige IP-Adresse teilen und die Last unter Verwendung von Portadressenübersetzung zwischen den Servern ausgeglichen wird.
Es ist deshalb ersichtlich, daß verbesserte Techniken zum Hosten eines Netzdienstes auf einem Cluster von Servern benötigt werden, während den Clients ein Einzeladressenbild präsentiert wird, ohne daß die mit den oben beschriebenen herkömmlichen Ansätzen assoziierten Probleme auftreten.
Kurzfassung der Erfindung
Die vorliegende Erfindung liefert Verfahren und Vorrichtungen zum Hosten eines Netzdienstes auf einem Cluster von Servern. Alle Server in einem Server-Cluster, das gemäß der Erfindung konfiguriert ist, können durch eine einzige Clusteradresse designiert werden, die jedem Server als Sekundäradresse zugewiesen wird. Alle Client-Anforderungen einer Website oder eines anderen mit der Cluster-Adresse assoziierten Netzdienstes werden zu dem Server-Cluster gesendet und es wird ein Aussendungsmechanismus verwendet, um sicherzustellen, daß jede Client-Anforderung nur von einem Server in dem Cluster verarbeitet wird. Die Aussendung kann so konfiguriert werden, daß sie operiert, ohne die Anzahl der für jede Client-Anforderung erforderlichen TCP/IP-Verbindungen zu vergrößern. Die Erfindung verteilt die Client-Anforderungslast gleichmäßig auf die verschiedenen Server des Clusters, maskiert den Ausfall eines beliebigen Servers oder von beliebigen Servern des Clusters durch Verteilen von Client-Anforderungen auf die übrigen Server, ohne den Dienst ausfallen zu lassen, und gestattet das Hinzufügen zusätzlicher Server zu dem Cluster, ohne den Dienst ausfallen zu lassen. Obwohl sie für die Verwendung beim Hosten von Website-Diensten gut geeignet sind, können die Techniken der vorliegenden Erfindung auch zur Unterstützung vielfältiger anderer Server-Anwendungen verwendet werden.
Bei einer beispielhaften Ausführungsform der Erfindung wird ein Netzdienst durch einen Server-Cluster gehostet, bei dem jeder Server eine primäre IP-Adresse und eine sekundäre IP-Adresse enthält. Als die sekundäre IP-Adresse für jeden der Server wird eine gemeinsame Cluster-Adresse zugewiesen. Die Cluster-Adresse kann eine IP-Adresse sein, die nicht einer primären IP-Adresse irgendeines der Server entspricht. Bei Servern auf UNIX-Basis kann die Clusteradresse als die Sekundäradresse durch Verwendung einer Option ifconfig alias als die Sekundäradresse für einen gegebenen Server zugewiesen werden. Wenn ein gegebener Server mehrere Netzschnittstellenkarten enthält, kann die Clusteradresse unter Verwendung eines UNIX-Befehls ifconfig ohne die Option alias oder eine andere ähnliche Technik einer der Netzschnittstellenkarten zugewiesen werden. Ein Router wird an ein lokales Netz des Serverclusters angekoppelt und wird außerdem über das Internet an einen Client angekoppelt. Der Router empfängt Client-Anforderungen aus dem Internet und verwendet eine Aussendungstechnik, um Client-Anforderungen, die die Clusteradresse als ein Ziel aufweisen, zu lenken. Die Client-Anforderungen werden so ausgesendet, daß jede der Anforderungen nur von einem der Server in dem Cluster verarbeitet wird. Die Aussendungsfunktion kann auf dem Ergebnis des Anwendens einer Hash-Funktion auf eine IP-Adresse des gegebenen Client basieren. Eine geeignete Hash-Funktion kann durch Verwendung einer Analyse einer Verteilung von Client-IP-Adressen in einer mit einem oder mehreren der Server assoziierten Zugangsprotokollierung bestimmt werden. Falls ein Server ausgefallen ist, kann die Hash-Funktion neu auf die Client-IP-Adresse angewandt werden, um einen anderen Server zu identifizieren.
Zwei beispielhafte Aussendungstechniken zur Bereitstellung eines Einzeladressenbildes für ein Server-Cluster gemäß der Erfindung umfassen Aussendung auf Routing-Basis und Aussendung auf Rundsende-Basis. Bei der auf Routing basierenden Technik wird ein Dispatcher an den Router und an ein lokales Netz des Server-Clusters angekoppelt. Der Router leitet Client-Anforderungen, die die Cluster-Adresse aufweisen, zu dem Dispatcher und der Dispatcher wählt einen bestimmten der Server zur Verarbeitung einer gegebenen Client-Anforderung auf der Basis des Ergebnisses des Anwendens einer Hash-Funktion auf die Client-Adresse aus. Bei der auf Rundsenden basierenden Technik sendet der Router Client-Anforderungen, die die Cluster-Adresse aufweisen, über das lokale Netz des Server-Clusters zu jedem der Server rund. Jeder der Server implementiert eine Filterungsroutine, um sicherzustellen, daß jede Client-Anforderung nur von einem der Server verarbeitet wird. Die Filterungsroutine kann umfassen, eine Hash-Funktion der mit einer gegebenen Client-Anforderung assoziierten Client-IP-Adresse anzuwenden und das Ergebnis mit einer Serverkennung zu vergleichen, um zu bestimmen, ob dieser Server die Client-Anforderung verarbeiten soll.
Die Techniken der vorliegenden Erfindung ermöglichen ein schnelles Aussenden und können mit reduzierten Kosten und reduzierter Komplexität implementiert werden. Die Techniken eignen sich für die Verwendung in TCP/IP-Netzen und auch in Netzen auf der Basis vielfältiger anderer Standards und Protokolle. Im Gegensatz zu den herkömmlichen Einzeladressen-Bild-Ansätzen erfordert die vorliegende Erfindung nicht, daß eine Zieladresse in einem Anforderungspaket-Kopfteil in eine Serveradresse umgeändert wird, so daß der Server die Anforderung annehmen kann, oder daß eine Quellenadresse in einem Antwortpaket-Kopfteil in die Routeradresse umgeändert wird, so daß der Client die Antwort annehmen kann. Außerdem muß der Router nicht für jede IP-Verbindung eine IP-Adressenabbildung speichern und muß nicht eine solche Abbildung durchsuchen, um zu bestimmen, zu welchem Server ein Paket weitergeleitet werden soll. Der Router selbst wird deshalb unter Bedingungen mit großer Last nicht zu einem Engpaß und es sind keine speziellen Router-Hardware-Entwürfe erforderlich. Diese und weitere Merkmale und Vorteile der vorliegenden Erfindung werden aus den beigefügten Zeichnungen und der folgenden ausführlichen Beschreibung deutlicher.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockschaltbild einer herkömmlichen Client-Server-Verbindung gemäß dem TCP/IP-Standard;
2 zeigt eine vorbekannte TCP-Router-Technik zum Hosten eines Netzdienstes auf einem Cluster von Servern;
3 zeigt eine vorbekannte Netzadressen-Übersetzungstechnik zum Hosten eines Netzdienstes auf einem Cluster von Servern;
4 zeigt eine Technik zum Hosten eines Netzdienstes auf einem Cluster von Servern unter Verwendung von Aussendung auf Routing-Basis gemäß einer beispielhaften Ausführungsform der Erfindung; und
5 zeigt eine Technik zum Hosten eines Netzdienstes auf einem Cluster von Servern unter Verwendung von Aussendung auf Rundsendebasis gemäß einer weiteren beispielhaften Ausführungsform der Erfindung.
Ausführliche Beschreibung der Erfindung
Die vorliegende Erfindung wird nachfolgend in Verbindung mit beispielhaften Client-Server-Verbindungen dargestellt, die über das Internet zu einem Server-Cluster unter Verwendung des TCP/IP-Standards (Transmission Control Protocol/Internet Protocol) hergestellt wird. Es versteht sich jedoch, daß die Erfindung nicht auf die Verwendung mit einer bestimmten Art von Netz oder Netzkommunikationsprotokoll beschränkt ist. Die offengelegten Techniken eignen sich für die Verwendung mit vielfältigen anderen Netzen und Protokollen. Der Begriff "Server-Cluster" bedeutet im vorliegenden Gebrauch eine Gruppe oder Menge von Servern, die verbunden oder anderweitig konfiguriert sind, um einen Netzdienst zu hosten. Die Begriffe "Clusteradresse" und "Einzel-Adressenbild" bedeuten allgemein eine mit einer Gruppe von Servern, die zur Unterstützung eines Netzdienstes oder von Netzdiensten konfiguriert ist, assoziierte Adresse. Eine "Geister-IP-Adresse" ist eine Art von Clusteradresse in Form einer IP-Adresse, die nicht als Primäradresse für irgendeinen Server eines gegebenen Server-Clusters verwendet wird. Der Begriff "Netzdienst" soll Websites, Internet-Sites und Datenablieferdienste sowie beliebige andere, einem Client über ein Netz zugängliche Datentransfermechanismen abdecken. Der Begriff "Client-Anforderung" bedeutet eine Kommunikation von einem Client, die den Netzdienst einleitet. Eine gegebene Client-Anforderung kann abhängig von der Beschaffenheit der Anforderung mehrere Pakete oder nur ein einziges Paket enthalten.
Die vorliegende Erfindung liefert einen verbesserten Einzel-Adressen-Bild-Ansatz zur Verteilung von Client-Anforderung auf Server eines Server-Clusters. Bei einer bevorzugten Ausführungsform ermöglicht die Erfindung es allen Servern eines Server-Clusters, sich eine einzige gemeinsame IP-Adresse als Sekundäradresse zu teilen.
Die Sekundäradresse wird hier auch als Clusteradresse bezeichnet und kann unter Verwendung einer Option ifconfig alias hergestellt werden, die auf den meisten auf UNIX basierenden Systemen verfügbar ist, oder unter Verwendung ähnlicher auf anderen Systemen verfügbarer Techniken. Die Clusteradresse kann unter Verwendung des oben erwähnten Domänennamendienstes (DNS) zu Clients publiziert werden, der Domänennamen, die mit URLs (Uniform Resource Locators) assoziiert sind, in IP-Adressen übersetzt. Alle Client-Anforderungen, die zu einem Dienst zu leiten sind, der durch den Server-Cluster gehostet wird, werden zu der einzigen Clusteradresse gesendet und zu einem ausgewählten der Server ausgesendet, wobei Aussendungstechniken auf Routing-Basis oder auf Rundsendebasis verwendet werden, die nachfolgend ausführlicher beschrieben werden. Nachdem ein Server ausgewählt wurde, können zukünftige Anforderungspakete, die mit derselben Client-Anforderung assoziiert sind, zu demselben Server gelenkt werden. Alle anderen Übermittlungen in dem Server-Cluster können primäre IP-Adressen der Server benutzen.
Die oben erwähnte Option ifconfig alias wird in der Regel dazu benutzt, es einem einzelnen Server zu erlauben, mehr als einen Domänennamen zu versorgen. Zum Beispiel erlaubt es die Option ifconfig alias einem einzelnen Server, mehrere IP-Adressen und somit mehrere Domänennamen an eine einzige Netzschnittstelle anzubinden, wie zum Beispiel in "Two Servers, One Interface", http://www.thesphere.com/~dlp/TwoServers/, beschrieben wird. Client-Anforderungen, die an beliebige der mehreren Domänennamen gerichtet sind, können dann durch denselben Server versorgt werden. Der Server bestimmt, mit welchem Domänennamen eine gegebene Anforderung assoziiert ist, indem er die Zieladresse in dem Anforderungspaket untersucht. Die vorliegende Erfindung verwendet die Option ifconfig alias, um es zwei Servern zu ermöglichen, sich dieselbe IP-Adresse zu teilen. Normalerweise können sich zwei Server nicht dieselbe IP-Adresse teilen, weil ein solches Arrangement bewirken würde, daß ein beliebiges Paket, das für die gemeinsam benutzte Adresse bestimmt ist, von beiden Servern angenommen wird und eine Antwort erhält, was den Client verwirrt und möglicherweise zu einer Verbindungsrücksetzung führt. Bevor es einem Server erlaubt wird, eine neue IP-Adresse an seine Netzschnittstelle anzubinden, kann deshalb eine Prüfung durchgeführt werden, um sicherzustellen, daß kein anderer Server auf demselben lokalen Netz (LAN) diese IP-Adresse benutzt. Wenn sich eine Duplikatadresse findet, werden beide Server informiert und Warnungen ausgegeben. Das Aussenden auf Routing-Basis oder Rundsendebasis der vorliegenden Erfindung stellt sicher, daß jedes Paket nur von einem Server des Clusters verarbeitet wird, so daß die oben erwähnten Warnungen kein Problem hervorrufen.
Bei einer alternativen Technik zum Zuweisen einer Sekundäradresse zu einem gegebenen Server eines Server-Clusters gemäß der Erfindung wird der gegebene Server so konfiguriert, daß er mehrere Netzschnittstellenkarten enthält, so daß jeder der Netzschnittstellenkarten eine andere Adresse zugewiesen werden kann. Zum Beispiel kann man bei einem auf UNIX basierenden System herkömmliche ifconfig-Befehle ohne die oben beschriebene Option alias verwenden, um einer der Netzschnittstellenkarten eine primäre IP-Adresse und einer anderen der Netzschnittstellenkarten eine sekundäre IP-Adresse zuzuweisen. Die sekundäre IP-Adresse wird auch als sekundäre IP-Adresse in übrigen Servern in dem Cluster zugewiesen und als Clusteradresse zum Lenken von Client-Anforderungen zu dem Cluster verwendet.
Die nachfolgend zu beschreibenden beispielhaften Ausführungsformen der vorliegenden Erfindung verwenden Aussendungstechniken, bei denen Server auf der Basis eines Hash-Werts der Client-IP-Adresse ausgewählt werden. Der Hash-Wert kann durch Anwenden einer Hash-Funktion auf die Client-IP-Adresse oder durch Anwenden einer anderen geeigneten Funktion erzeugt werden, um einen Hash-Wert aus der Client-IP-Adresse zu erzeugen. Zum Beispiel kann bei gegebenen N Servern und einem Paket von einem Client mit einer Client-Adresse CA eine Aussendungsfunktion gemäß der Erfindung einen Hash-Wert k als CA mod(N-I) berechnen und den Server k zum Verarbeiten des Pakets auswählen. Dadurch wird sichergestellt, daß alle Anforderungs- oder Antwortpakete derselben TCP/IP-Verbindung zu demselben Server in dem Server-Cluster geleitet werden. Eine geeignete Hash-Funktion kann man bestimmen, indem man eine Verteilung von Client-IP-Adressen in tatsächlichen mit den Servern assoziierten Zugangsprotokollierungen analysiert, so daß diese Client-Anforderungen ungefähr gleichmäßig auf alle Server verteilt sind. Wenn ein Server in dem Cluster ausfällt, kann die Teilmenge der diesem Server zugewiesenen Clients nicht mit ihm verbunden werden. Die vorliegende Erfindung behandelt dieses potentielle Problem durch dynamisches Modifizieren der Aussendungsfunktion nach Erkennung eines Serverausfalls. Wenn der Hash-Wert einer gegebenen Client-IP-Adresse auf dem ausgefallenen Server abgebildet wird, wird die Client-IP-Adresse neu gehasht, um auf einem nichtausgefallenen Server abgebildet zu werden, und die Verbindungen der übrigen Clients sind durch den Ausfall nicht betroffen.
4 zeigt eine auf Routing basierende Aussendungstechnik gemäß der vorliegenden Erfindung. Durchgezogene Linien zeigen Netzverbindungen, während gestrichelte Linien den Weg einer beispielhaften Client-Anforderung und der entsprechenden Antwort zeigen. Ein Client 52 sendet eine Client-Anforderung zu einem Server-Cluster 54, der N Server 54-i, i = 1, 2, N, mit IP-Adressen S1, S2, ... SN enthält und durch ein Ethernet- oder anderweitiges LAN 56 verbunden wird.
Die Client-Anforderung wird gemäß dem oben beschriebenen HTTP-Protokoll formuliert und kann eine URL mit einem Domänennamen enthalten, der mit einer Website oder einem anderen von dem Server-Cluster 54 gehosteten Netzdienst assoziiert ist. Der Client greift auf einen DNS zu, um eine IP-Adresse für den Domänennamen des Dienstes zu bestimmen und verwendet die IP-Adresse dann, um eine TCP/IP-Verbindung zur Kommunikation mit einem der Server 54-i des Server-Clusters 54 herzustellen. Gemäß der Erfindung wird eine "Geister-IP-Adresse" zu dem DNS als Clusteradresse für den Server-Cluster 54 publiziert. Die Geister-IP-Adresse wird so ausgewählt, daß keiner der Server 54-i des Clusters 54 diese IP-Adresse als seine Primäradresse besitzt. Deshalb werden jegliche an die Geister-IP-Adresse gerichtete Anforderungspakete mit Client-Anforderungen des Dienstes des Einzeladressen-Bild-Clusters 54 assoziiert. Die Verwendung der Geister-IP-Adresse unterscheidet einen durch den Cluster gehosteten Netzdienst somit von Aktivitäten der Server 54-i, die die primären Serveradressen benutzen und verhindert Störungen dieser Primäradressenaktivitäten.
Der Client 52 verwendet die Geister-IP-Adresse als Clusteradresse zum Lenken seiner Anforderung zu dem Server-Cluster 54. Die Anforderung wird über das Internet 60 zu einem Router 62 mit einer IP-Adresse RA geleitet. Der Router 62 enthält eine Routing-Tabelle mit einem Eintrag oder Datensatz, der alle ankommenden Anforderungspakete mit der Geister-IP-Adresse zu einem mit LAN 56 verbundenen Dispatcher 64 leitet. Der Dispatcher 64 enthält ein Betriebssystem, das dafür konfiguriert ist, in einem Routermodus unter Verwendung eines Routing-Algorithmus, der die hier beschriebene Aussendung durchführt, abzulaufen. Bei alternativen Ausführungsformen könnten die Funktionen des Dispatchers 64 in den Router 62 integriert werden, um zusätzliche Effizienzverbesserungen bereitzustellen.
Jeder der Server 54-i des Clusters 54 verwendet die oben beschriebene Option ifconfig alias zum Setzen der Geister-IP-Adresse als seine Sekundäradresse. Wie bereits erwähnt, erfordert diese Technik zum Setzen einer Sekundäradresse für jeden der Server 54-i im allgemeinen keinerlei Abänderung des auf den Servern ablaufenden Kernel-Codes. Bei alternativen Ausführungsformen können einer oder mehrere der Server 54-i so konfiguriert sein, daß sie mehrere Netzschnittstellenkarten enthalten (wie bereits erwähnt), so daß jeder der Netzschnittstellenkarten eines gegebenen Servers unter Verwendung eines UNIX-Befehls ifconfig oder einer anderen ähnlichen Technik eine andere Adresse zugewiesen werden kann.
Der Router 62 routet alle Pakete mit der Geister-IP-Adresse gemäß dem obenerwähnten Routing-Tabellendatensatz zu dem Dispatcher 64. Der Dispatcher 64 wendet dann eine Hash-Funktion auf die Client-IP-Adresse in einem gegebenen Anforderungspaket an, um zu bestimmen, zu welchem der Server 54-i das gegebene Paket geroutet werden soll. In dem in 4 dargestellten Beispiel wendet der Dispatcher 64 eine Hash-Funktion auf die IP-Adresse des Client 52 an und bestimmt, daß das entsprechende Anforderungspaket zu dem Server 54-2 an der IP-Adresse S2 geroutet werden soll. Der Dispatcher 64 routet das Anforderungspaket dann über das LAN 56 wie durch die gestrichelte Linie angegeben unter Verwendung der Primäradresse S2 des Servers 54-2 zu dem Server 54-2, um ihn von den anderen Servern des Clusters 54 zu unterscheiden. Nachdem die Netzschnittstelle des Servers 54-2 das Paket annimmt, kann die gesamte Verarbeitung auf höherer Ebene auf der Geister-IP-Adresse basieren, weil sie die Zieladresse in dem Paket-IP-Kopfteil und möglicherweise in den Paketinhalten der Anwendungsschicht ist. Nach der Verarbeitung der Anforderung antwortet der Server 54-2 dem Client 52 direkt über den Router 62 über die hergestellte TCP/IP-Verbindung unter Verwendung der Geister-IP-Adresse und ohne den Dispatcher 64 zu durchlaufen.
Es sollte angemerkt werden, daß, wenn ein für die Geister-IP-Adresse bestimmtes Anforderungspaket von der Netzschnittstelle des Dispatchers 64 empfangen und zur Ablieferung an einen der Server 54-i über das LAN 56 wieder auf dieselbe Netzschnittstelle zurückgelegt wird, es bewirken kann, daß eine Host-Umleitungsnachricht des Internet-Steuernachrichtenprotokolls (ICMP) zu dem Router 62 gesendet wird. Diese ICMP-Nachricht ist dafür ausgelegt, den Router 62 anzuweisen, seine Routing-Tabelle so zu aktualisieren, daß alle zukünftigen Pakete mit der Geister-IP-Adresse den Dispatcher 64 umgehen und direkt den Zielserver erreichen können, wie ausführlicher in W. R. Stevens, TCP/IP Illustrated, Band 1, Kap. 6, Seiten 69–93, beschrieben wird. Dieser Effekt ist jedoch in der Routing-Technik von 4 unerwünscht, weil der Dispatcher 64 den Serverauswahlprozeß wie zuvor beschrieben durchführt. Es kann deshalb notwendig sein, die ICMP-Host-Umleitungsnachricht für die Geister-IP-Adresse zu unterdrücken, indem man zum Beispiel den entsprechenden Betriebssystemcode in dem Dispatcher entfernt oder abändert. Bei den oben erwähnten alternativen Ausführungsformen, bei denen die Aussendungsfunktion in dem Router 62 implementiert ist, wird die ICMP-Umleitungsnachricht nicht erzeugt und muß daher nicht unterdrückt werden. Ein weiteres potentielles Problem kann entstehen, wenn ein Antwortpaket von dem gewählten Server 54-2 mit der Geister-IP-Adresse zu dem Client 52 zurückgesendet wird, insofern, als es bewirken kann, daß der Router 62 in seinem Cache des Adressenauflösungsprotokolls (ARP) die Geister-IP-Adresse mit der LAN-Adresse des gewählten Servers assoziiert. Die Funktionsweise des ARP-Cache wird ausführlicher in W. R. Stevens, TCP/IP Illustrated, Band 1, Kap. 4 und 5, Seiten 53–68, worauf hiermit ausdrücklich Bezug genommen wird, beschrieben.
Die beispielhafte Ausführungsform von 4 vermeidet dieses Problem durch automatisches Routen der Anforderungspakete zu dem Dispatcher 64 mit anschließender Aussendung auf der Basis der primären IP-Adresse des Servers, so daß der Router-ARP-Cache nicht benutzt wird.
5 zeigt eine auf Rundsenden basierende Aussendungstechnik gemäß der vorliegenden Erfindung. Wieder geben durchgezogene Linien Netzverbindungen an, während gestrichelte Linien den Weg einer beispielhaften Client-Anforderung und der entsprechenden Antwort zeigen. Wie bei der auf Routing basierenden Ausführungsform von 4 sendet der Client 52 eine Client-Anforderung zu dem Server-Cluster 54, das N Server 54-i, i = 1, 2, ... N, enthält, die mit dem LAN 56 verbunden sind und die IP-Adressen S1, S2, ... SN aufweisen. Der Client 52 verwendet die oben beschriebene Geisteradresse als Cluster-Adresse zum Lenken seiner Anforderung zu dem Server-Cluster 54. Die Anforderung wird über das Internet 60 zu einem Router 70 mit einer IP-Adresse RA geleitet. Der Router 70 sendet alle ankommenden Anforderungspakete mit der Geister-IP-Adresse zu dem LAN 56, das die Server 54-i des Server-Clusters 54 verbindet, rund, so daß das Anforderungspaket von jedem der Server 54-i empfangen wird.
Jeder der Server 54-i des Clusters 54 implementiert eine Filterungsroutine, um sicherzustellen, daß nur einer der Server 54-i eine gegebene Client-Anforderung verarbeitet. Die Filterungsroutine kann zu einem Einrichtungstreiber jedes der Server 54-i hinzugefügt werden. Bei einer beispielhaften Implementierung wird jedem der Server 54-i eine eindeutige Identifikationsnummer (ID) zugewiesen. Die Filterungsroutine eines gegebenen Servers 54-i berechnet einen Hash-Wert der Client-IP-Adresse und vergleicht sie mit der ID-Nummer des gegebenen Servers. Wenn der Hash-Wert und die ID- Nummer nicht übereinstimmen, weist die Filterungsroutine des gegebenen Servers das Paket zurück. Wenn der Hash-Wert und die ID-Nummer übereinstimmen, nimmt der gegebene Server das Paket an und verarbeitet es, als ob er das Paket durch einen herkömmlichen IP-Routing-Mechanismus empfangen hätte. Bei dem Anschauungsbeispiel von 5 wird das mit der Anforderung von dem Client 52 assoziierte Paket durch den Router 70 zu jedem der Server 54-i des Server-Clusters über das LAN 56 wie zuvor erwähnt rundgesendet. Die Filterungsroutine des Servers 54-2 erzeugt einen Hash-Wert der Client-IP-Adresse, der mit der eindeutigen ID-Nummer übereinstimmt, die mit dem Server 14-2 assoziiert ist, und der Server 14-2 nimmt das Paket deshalb an und verarbeitet es. Die Filterungsroutinen der N-1 anderen Server 54-i zeigen jeweils keine Übereinstimmung zwischen der Client-IP-Adresse und der entsprechenden Server-ID-Nummer an und verwerfen deshalb das rundgesendete Paket. Die Antwortpakete werden über den Router 70 wie durch die gestrichelte Linien angegeben unter Verwendung der Geister-IP-Adresse zu dem Client 52 zurückgesendet.
Die auf Rundsenden basierende Aussendungstechnik von 5 kann unter Verwendung eines permanenten ARP-Eintrags in dem Router 70 implementiert werden, um die Geister-IP-Adresse mit der mit dem LAN 56 des Clusters 54 assoziierten Rundsendeadresse des Ethernet oder anderen lokalen Netzes zu assoziieren. Ein potentielles Problem liegt darin, daß jedes Antwortpaket von einem gewählten Server von der Geister-IP-Adresse zu kommen scheint und deshalb bewirken kann, daß der Router 70 den Eintrag in seinem ARP-Cache so überschreibt, daß die Geister-IP-Adresse mit der LAN-Adresse des gewählten Servers assoziiert wird. Dieses potentielle Problem läßt sich behandeln, indem man in dem Router 70 einen Routing-Tabelleneintrag einrichtet, um alle Pakete mit einer Geister-IP-Zieladresse zu einer zweiten Geister-IP-Adresse zu lenken, die eine legale Subnetzadresse in dem LAN 56 des Server-Clusters 54 ist, aber von keinem Server benutzt wird. Zusätzlich wird ein Eintrag in dem ARP-Cache des Routers 70 eingefügt, um die zweite Geister-IP-Adresse mit der Rundsendeadresse des LAN 56 zu assoziieren. Wenn der Router 70 ein Paket zu der zweiten Geister-IP-Adresse routet, sendet er dann tatsächlich das Paket zu jedem der Server 54-i des Clusters 54 rund. Da kein Antwortpaket von der zweiten Geister-IP-Adresse gesendet wird, bleibt der entsprechende Eintrag des Router-ARP-Cache unverändert. Ein anderes potentielles Problem liegt darin, daß bestimmte Betriebssysteme, wie zum Beispiel das Betriebssystem NetBSD, keine Verarbeitung eines TCP-Pakets erlauben, wenn es von einer Rundsendeadresse empfangen wird. Dieses potentielle Problem kann durch eine geeignete Modifikation der Rundsendeadresse in dem an dem Paket angehängten LAN-Paket-Kopfteil vermieden werden.
Die in Verbindung mit 4 und 5 oben beschriebenen Aussendungstechniken auf Routing-Basis und Rundsendebasis wurden auf einem Cluster von Workstations des Typs Sun SPARC implementiert. Es wurde das Betriebssystem NetBSD, beschrieben in NetBSD Project, http://www.NetBSD.org, verwendet, um etwaige notwendige Kernel-Code-Modifikationen bereitzustellen. Das mit beiden Techniken assoziierte Aussendungsoverhead ist minimal, weil die Paketaussendung auf einfacher IP-Adressen-Hash-Transformation basiert, ohne daß es notwendig ist, irgendwelche Adressenabbildungsinformationen zu speichern oder zu durchsuchen. Bei der auf Routing basierenden Aussendungstechnik fügt der zusätzliche Routing-Schritt in den Dispatcher 64 in der Regel eine Verzögerung von etwa 1 bis 2 ms zu der TCP-Gesamtlaufzeit jedes ankommenden Anforderungspakets hinzu. Eine Studie in W. R. Stevens, TCP/IP Illustrated, Band 3, Seiten 185–186, zeigt, daß die Median-TCP-Gesamtlaufzeit 187 ms beträgt. Die auf das auf Routing basierende Aussenden zurückzuführende zusätzliche Verzögerung ist deshalb vernachlässigbar. Obwohl der zusätzliche Routing-Schritt für jedes zu der Geister-IP-Adresse gesendete Anforderungspaket den Verkehr in dem LAN des Server-Clusters vergrößern kann, ist die Größe einer Anforderung bei vielen wichtigen Anwendungen in der Regel viel kleiner als die der entsprechenden Antwort, die direkt ohne das zusätzliche Routing an den Client abgeliefert wird. Bei der auf Rundsenden basierenden Aussendungstechnik vergrößert das Rundsenden jedes ankommenden Anforderungspakets auf dem LAN des Server-Clusters den Netzverkehr nicht wesentlich. Obwohl für jedes ankommende Paket mit der Geister-IP-Zieladresse ein Hash-Wert berechnet wird, wodurch die CPU-Last jedes Servers vergrößert wird, ist dieses zusätzliche Berechnungsoverhead im Vergleich zu der entsprechenden Kommunikationsverzögerung vernachlässigbar.
Die auf Routing basierende und die auf Rundsenden basierende Aussendungstechnik der vorliegenden Erfindung sind beide skalierbar, um relativ große Anzahlen von Servern zu unterstützen. Obwohl der Dispatcher in der auf Routing basierenden Technik in bestimmten Anwendungen einen potentiellen Engpaß darstellen könnte, zeigt eine Studie in der oben zitierten Literaturstelle von D.M. Dias et al. an, daß ein einziger Dispatcher bis zu 75 Serverknoten unterstützen kann und dies ist ausreichend Unterstützung für viele praktische Systeme. Die unterstützten Anzahlen von Servern können mit der vorliegenden Erfindung sogar noch höher sein, da die hier beschriebenen auf Routing basierenden Aussendungsfunktionen im allgemeinen einfacher als die der Literaturstelle von D.M. Dias et al. sind. Außerdem sollte beachtet werden, daß man durch Kombinieren des auf Routing basierenden Aussendens der vorliegenden Erfindung mit einer DNS-Reigentechnik zusätzliche Skalierbarkeit erhalten kann. Zum Beispiel kann ein DNS-Server verwendet werden, um unter Verwendung einer Reigentechnik einen Domänennamen auf eine von mehreren verschiedenen Geister-IP-Adressen abzubilden, die zu verschiedenen Server-Clustern gehören. Bei der auf Rundsenden basierenden Aussendungstechnik besteht kein potentieller Aussendungsengpaß, obwohl die Einrichtungstreiber oder andere Teile der Server möglicherweise modifiziert werden müssen, um die oben beschriebenen Filterungsroutinen bereitzustellen.
Das auf Routing basierende und auf Rundsenden basierende Aussenden der vorliegenden Erfindung kann auch Lastausgleich und Ausfallbehandlungsfähigkeiten bereitstellen. Wenn zum Beispiel N Server und ein Paket von der Clientadresse CA gegeben sind, kann die oben beschriebene Aussendungsfunktion auf Routing-Basis einen Hash-Wert k als CA mod (N-1) berechnen und den Server k zur Verarbeitung des Pakets auswählen. Es können auch kompliziertere Aussendungsfunktionen verwendet werden und können umfassen, die tatsächliche Dienstzugangsprotokollierung zu analysieren, um einen effektiveren Lastausgleich bereitzustellen. Um Ausfälle zu erkennen, kann jeder Server durch einen Watchdog-Dämon überwacht werden, wie zum Beispiel den watchd-Dämon, der ausführlicher in Y. Huang und C. Kintala, "Software Implemented Fault Tolerance: Technologies and Experience", Proceedings of the 23^rd International Symposium an Fault-Tolerant Computing – FTCS, Toulouse, Frankreich, Seiten 2–9, Juni 1993, beschrieben wird. Wenn ein Server ausfällt, leitet der entsprechende watchd-Dämon eine Änderung der Aussendungsfunktion ein, um den Ausfall zu maskieren und die Last neu auszugleichen. Es kann eine Systemaufrufschnittstelle implementiert werden um eine Änderung der Aussendungsfunktion zu erlauben, während die Server online bleiben. Bei der auf Routing basierenden Aussendung kann der watchd-Dämon den Dispatcher benachrichtigen, die Aussendungsfunktion zu ändern, während bei der auf Rundsenden basierenden Aussendung alle Server benachrichtigt werden können, ihre Filterungsroutinen zu modifizieren. Wenn zum Beispiel ein Server k ausfällt, kann die neue Aussendungsfunktion prüfen, ob der Hash-Wert CA mod N gleich k ist. Wenn dies der Fall ist, wird ein neuer Hash-Wert j = CA mod (N-1) berechnet. Wenn j kleiner als k ist, geht das Paket zum Server j. Andernfalls geht das Paket zum Server j+1. Diese Technik wirkt sich nicht auf die Clients nichtausgefallener Server aus, weist die Clients des ausgefallenen Servers gleichmäßig auf die übrigen Server neu zu und kann ohne weiteres erweitert werden, um mit mehreren Serverausfällen fertig zu werden. Es können zusätzliche Server zu dem Cluster hinzugefügt werden, ohne den Dienst ausfallen zu lassen, indem die Aussendungsfunktion von CA mod N in CA mod (N+1) umgeändert wird.
Bei der auf Routing basierenden Aussendung kann der Dispatcher ein einzelner Ausfallpunkt werden und sollte deshalb auch durch einen watchd-Dämon oder einen anderen geeigneten Ausfallüberwachungsmechanismus überwacht werden. Bei Erkennung eines Ausfalls kann der watchd-Dämon einen Transfer der Aussendungsfunktion von dem primären Dispatcher zu einem Backup-Dispatcher auslösen und dann den Router anweisen, den Eintrag in seiner Routing-Tabelle so zu ändern, daß zukünftige ankommende Anforderungspakete zu dem Backup-Dispatcher geroutet werden. Da der primäre Dispatcher keine Abbildungstabelle führt, ist dieser Ansatz im wesentlichen zustandslos. Ein ordungsgemäßes Routen kann sichergestellt werden, indem man einfach einheitliche Routing-Funktionen in dem primären und dem Backup-Dispatcher verwendet, ohne die wesentlichen zusätzlichen Kosten, die mit den auf Abbildung basierenden Ansätzen assoziiert sind.
Die Verwendung der Option ifconfig alias oder einer anderen ähnlichen Technik zur Bereitstellung eines Einzeladressen-Bildes für einen Server-Cluster hat gegenüber zuvor beschriebenen herkömmlichen Techniken mehrere Vorteile. Zum Beispiel vermeidet sie die Notwendigkeit, die Zieladresse in einem Anforderungspaket-Kopfteil so umzuändern, daß ein bestimmter Server die Anforderung annehmen kann, und die Notwendigkeit, die Quellenadresse in einem Antwortpaket-Kopfteil in die Clusteradresse umzuändern, so daß der Client die Antwort annehmen kann. Bei dem Einzeladressen-Bild-Ansatz der vorliegenden Erfindung können alle Server Pakete mit der Clusteradresse annehmen und auf sie antworten, so daß die Adressen in den Anforderungs- und Antwortpaket-Kopfteilen nicht modifiziert werden müssen. Da der Einzelbild-Ansatz der vorliegenden Erfindung keine Abänderung der Paketadressen erfordert, eignet er sich für die Verwendung in vielfältigen Protokollen darunter die Protokolle, die IP-Adressen innerhalb eines Anwendungsprogramms benutzen. Zusätzlich erfordert der Einzel-Adressen-Bild-Ansatz der vorliegenden Erfindung keinen Router zum Speichern oder Durchsuchen einer potentiell großen Anzahl von IP-Adressenabbildungen, um zu bestimmen, welcher Cluster-Server ein Anforderungspaket empfangen soll. Die Erfindung beseitigt somit effektiv die Möglichkeit, daß der Router unter Bedingungen mit großer Last zu einem Engpaß werden kann.
Die oben beschriebenen Ausführungsformen der Erfindung sollen nur veranschaulichen. Fachleute können zahlreiche alternative Ausführungsformen konzipieren, ohne von dem Schutzumfang der folgenden Ansprüche abzuweichen.

Claims

Verfahren zum Routen von Client-Anforderungen zu mehreren Servern (54), die dafür konfiguriert sind, einen Netzdienst über ein Kommunikationsnetz zu unterstützen, wobei jeder der Server eine Primäradresse aufweist, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: Zuweisen einer gemeinsamen Adresse als Sekundäradresse für jeden der mehreren Server dergestalt, daß jeder der Server individuell die Sekundäradresse aufweist; und Verarbeiten von an die gemeinsame Adresse gerichteten Client-Anforderungen dergestalt, daß jede der Anforderungen durch einen bestimmten der mehreren Server ohne Modifikation der gemeinsamen Adresse in der Anforderung verarbeitet wird.
Verfahren nach Anspruch 1, wobei das Netz ein TCP/IP-Protokoll verwendet und die Primär- und Sekundäradressen primäre bzw. sekundäre IP-Adressen sind.
Verfahren nach Anspruch 2, wobei die gemeinsame Adresse eine IP-Adresse ist, die nicht einer primären IP-Adresse irgendeines der mehreren Server entspricht.
Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer der mehreren Server ein auf UNIX basierender Server mit mehreren Netzschnittstellenkarten ist und der Schritt des Zuweisens umfaßt, die gemeinsame Adresse für den mindestens einen Server unter Verwendung eines ifconfig-Befehls zuzuweisen.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die mehreren Server auf UNIX basierende Server sind und der Schritt des Zuweisens umfaßt, die gemeinsame Adresse unter Verwendung einer Option ifconfig alias für mindestens eine Teilmenge der mehreren Server zuzuweisen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Verarbeitungsschritt den Schritt des Versendens einer Anforderung eines gegebenen Clients zu einem der mehreren Server auf der Basis der Anwendung einer Hash-Funktion auf eine IP-Adresse des gegebenen Clients umfaßt.
Verfahren nach Anspruch 6, wobei die Hash-Funktion auf der Basis einer Analyse der Verteilung von Client-IP-Adressen in einer mit einem oder mehreren der Server assoziierten Zugangsprotokollierung bestimmt wird.
Verfahren nach Anspruch 6, wobei der Schritt des Versendens das Neuanwenden der Hash-Funktion auf die Client-IP-Adresse umfaßt, um andere Server zu identifizieren, wenn ein als Ergebnis einer vorherigen Anwendung der Hash-Funktion identifizierter Server ausgefallen ist.
Verfahren nach einem der Ansprüche 1 bis 5, wobei der Schritt des Verarbeitens die folgenden Schritte umfaßt: Routen von an die gemeinsame Adresse gerichteten Client-Anforderungen zu einem Dispatcher (64), der mit einem mit den mehreren Servern assoziierten lokalen Netz (56) verbunden ist; und Auswählen eines bestimmten der Server, um eine gegebene Client-Anforderung zu verarbeiten, auf der Basis der Anwendung einer Hash-Funktion auf eine entsprechende Client-Adresse in dem Dispatcher.
Verfahren nach einem der Ansprüche 1 bis 5, wobei der Schritt des Verarbeitens die folgenden Schritte umfaßt: Rundsenden einer an die gemeinsame Adresse gerichteten gegebenen Client-Anforderung zu allen der mehreren Server über ein mit den Servern assoziiertes lokales Netz; und Implementieren einer Filterungsroutine in jeden der mehreren Server, so daß die gegebene Client-Anforderung nur von einem der Server verarbeitet wird.
Verfahren nach Anspruch 10, wobei der Schritt des Implementierens die folgenden Schritte umfaßt: Anwenden einer Hash-Funktion auf eine Client-IP-Adressen, die mit der gegebenen Client-Anforderung assoziiert ist; und Vergleichen des Ergebnisses des Schritts des Anwendens mit einer Kennung eines bestimmten Servers, um zu bestimmen, ob dieser Server die gegebene Client-Anforderung verarbeiten soll.
Vorrichtung zum Routen von Client-Anforderungen zu mehreren Servern (54), die dafür konfiguriert sind, einen Netzdienst über ein Kommunikationsnetz zu unterstützen, wobei jeder der Server eine Primäradresse aufweist, gekennzeichnet durch: Mittel zum Zuweisen einer gemeinsamen Adresse als Sekundäradresse für jeden der mehreren Server dergestalt, daß jeder der Server individuell die Sekundäradresse aufweist; und Mittel zum Verarbeiten von an die gemeinsame Adresse gerichteten Client-Anforderungen dergestalt, daß jede der Anforderungen durch einen bestimmten der mehreren Server ohne Modifikation der gemeinsamen Adresse in der Anforderung verarbeitet wird.
Vorrichtung nach Anspruch 12, wobei das Verarbeitungsmittel wirkt, um eine Anforderung eines gegebenen Client auf der Basis einer Anwendung einer Hash-Funktion auf eine IP-Adresse des gegebenen Clients zu einem der mehreren Server zu versenden.
Vorrichtung nach Anspruch 13, wobei das Verarbeitungsmittel wirkt, um die Hash-Funktion auf der Basis einer Analyse einer Verteilung von Client-IP-Adressen in einer mit einem oder mehreren der Server assoziierten Zugangsprotokollierung zu bestimmen.
Vorrichtung nach Anspruch 13, wobei das Verarbeitungsmittel ferner wirkt, um die Hash-Funktion neu auf die Client-IP-Adresse anzuwenden, um einen anderen Server zu identifizieren, wenn ein als Ergebnis einer vorherigen Anwendung der Hash-Funktion identifizierter Server ausgefallen ist.
Vorrichtung nach einem der Ansprüche 12 bis 15, wobei das Verarbeitungsmittel ferner einen Dispatcher (64) enthält, der mit einem mit den mehreren Servern assoziierten lokalen Netz (56) verbunden ist, wobei der Dispatcher wirkt, um an die gemeinsame Adresse gerichtete Client-Anforderungen zu empfangen und auf der Basis der Anwendung einer Hash-Funktion auf eine entsprechende Client-Adresse einen bestimmten der Server zur Verarbeitung einer gegebenen Client-Anforderung auszuwählen.
Vorrichtung nach einem der Ansprüche 12 bis 15, wobei das Verarbeitungsmittel ferner folgendes umfaßt: Mittel zum Rundsenden einer an die gemeinsame Adresse gerichteten gegebenen Client-Anforderung zu allen der Server über ein mit den Servern assoziiertes lokales Netz; und Mittel zum Filtern der gegebenen Client-Anforderung in jedem der mehreren Server, so daß die gegebene Client-Anforderung nur von einem der Server verarbeitet wird.
Vorrichtung nach Anspruch 17, wobei das Filtermittel wirkt, um eine Hash-Funktion auf eine Client-IP-Adresse anzuwenden, die mit der gegebenen Client-Anforderung assoziiert ist, und das Ergebnis des Schritts des Anwendens mit einer Kennung eines bestimmten Servers zu vergleichen, um zu bestimmen, ob dieser Server die gegebene Client-Anforderung verarbeiten soll.
System zum Routen von Client-Anforderung eines Netzdienstes über ein Kommunikationsnetz, wobei das System durch folgendes gekennzeichnet ist: mehrere Server (54) die dafür konfiguriert sind, den Netzdienst zu unterstützen, wobei jeder der Server eine Primäradresse und eine Sekundäradresse aufweist, wobei als die Sekundäradresse für jeden der mehreren Server eine gemeinsame Adresse zugewiesen wird, so daß jeder der Server individuell die Sekundäradresse aufweist; und einen Router (62, 70), der an die Server angekoppelt ist und wirkt, um an die gemeinsame Adresse gerichtete Client-Anforderungen so zu routen, daß jede der Anforderungen durch einen bestimmten der mehreren Server ohne Modifikation der gemeinsamen Adresse in der Anforderung verarbeitet wird.
System nach Anspruch 19, wobei der Router ferner wirkt, um Client-Anforderungen so zu routen, daß eine Anforderung eines gegebenen Clients auf der Basis einer Anwendung einer Hash-Funktion auf die IP-Adresse des gegebenen Clients zu einem der mehreren Server geroutet wird.
System nach Anspruch 20, wobei der Router ferner wirkt, um die Hash-Funktion auf der Basis einer Analyse einer Verteilung von Client-IP-Adressen in einer mit einem oder mehreren der Server assoziierten Zugangsprotokollierung zu bestimmen.
System nach Anspruch 20, wobei der Router wirkt, um die Hash-Funktion neu auf die Client-IP-Adresse anzuwenden, um einen anderen Server zu identifizieren, wenn ein als Ergebnis einer vorherigen Anwendung der Hash-Funktion identifizierter Server ausgefallen ist.
System nach einem der Ansprüche 19 bis 22, ferner mit einem Dispatcher (64), der an den Router und an ein lokales Netz (56), das mit den mehreren Servern assoziiert ist, angekoppelt ist, dergestalt, daß der Router Client-Anforderungen, die die gemeinsame Adresse aufweisen, zu dem Dispatcher leitet und der Dispatcher einen bestimmten der Server für die Verarbeitung einer gegebenen Client-Anforderung auf der Basis einer Anwendung einer Hash-Funktion auf eine entsprechende Client-Adresse auswählt.
System nach einem der Ansprüche 19 bis 22, wobei der Router ferner wirkt, um eine gegebene an die gemeinsame Adresse gerichtete Client-Anforderung über ein mit den Servern assoziiertes lokales Netz zu jedem der mehreren Server rundzusenden und wobei ferner jeder der Server eine Filterungsroutine implementiert, so daß die gegebene Client-Anforderung nur von einem der Server verarbeitet wird.
System nach Anspruch 24, wobei die Filterungsroutine das Anwenden einer Hash-Funktion auf eine mit der gegebenen Client-Anforderung assoziierte Client-IP-Adresse und das Vergleichen des Ergebnisses mit einer Kennung eines bestimmten Servers umfaßt, um zu bestimmen, ob dieser Server die gegebene Client-Anforderung verarbeiten soll.
Vorrichtung nach einem der Ansprüche 12 bis 18 oder System nach einem der Ansprüche 19–25, wobei das Netz ein TCP/IP-Protokoll verwendet und die Primär- und Sekundäradressen primäre bzw. sekundäre IP-Adressen sind.
Vorrichtung oder System nach Anspruch 26, wobei die gemeinsame Adresse eine IP-Adresse ist, die nicht einer primären IP-Adresse irgendeines der mehreren Server entspricht.
Vorrichtung oder System nach einem der Ansprüche 19 bis 27, wobei mindestens einer der mehreren Server ein auf UNIX basierender Server mit mehreren Netzschnittstellenkarten ist und die gemeinsame Adresse für den mindestens einen Server unter Verwendung eines ifconfig-Befehls zugewiesen wird.
Vorrichtung oder System nach einem der Ansprüche 19 bis 27, wobei die mehreren Server auf UNIX basierende Server sind und die gemeinsame Adresse als die Sekundäradresse der mehreren Server durch Verwenden einer Option ifconfig alias für mindestens eine Teilmenge der mehreren Server zugewiesen wird.