DE69733498T2

DE69733498T2 - Verteiltes rechnersystem und verfahren zur aufteilung von benutzeranfragen auf duplizierte netzwerkserver

Info

Publication number: DE69733498T2
Application number: DE69733498T
Authority: DE
Inventors: Lance Rodney JOFFE; Alan Jason BRITTAIN; Everett Brian PETTINGELL; Burke Ian VANDEVENTER; Michael Steven HOTZ; Barry A. Dykes; Joseph Victor OPPELMAN; Joseph James LIPPARD; Dean Brett WATSON; Herbert Nils MCCARTHY
Original assignee: Verizon Corporate Services Group Inc; Genuity Inc
Current assignee: Verizon Corporate Services Group Inc; Genuity Inc
Priority date: 1996-12-09
Filing date: 1997-12-09
Publication date: 2005-11-03
Anticipated expiration: 2017-12-10
Also published as: ATE297628T1; AU724096B2; JP2001509925A; DK1016253T3; US8683075B1; WO1998026559A1; US6185619B1; DE69733498D1; ES2258800T3; EP1016253A1; CA2274496C; NZ336187A; PT1016253E; AU5692498A; JP4354532B2; EP1016253B1; CA2274496A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der verteilten Rechnersysteme und insbesondere auf Rechensysteme und Verfahren zum Zuweisen von Anforderungen zu einem von mehreren Netzservern auf der Grundlage bester Kriterien, wie beispielsweise der Geschwindigkeit der unterlegten Netz-Infrastruktur.
Das explosive Wachstum des World Wide Web verlangt wenig Einführung. Nicht nur die Mitglieder der technisch versierten Gemeinschaft, der eine immer größere Anzahl technischer und Informationsquellen im World Wide Web verfügbar ist, sondern auch die allgemeine Bevölkerung findet bevorzugte Restaurants, Fahrzeugwerkstätten und Kirchen, die neue Webseiten erstellen. Die Popularität des World Wide Web als Kommunikationsmedium liegt in der Fülle seines Informationsinhalts und der Einfachheit seines Gebrauchs. Information in diesem Medium existiert als Objekte in einer breit verteilten Sammlung von im Internet arbeitenden Servern, wobei jedes Objekt durch seinen eigenen, einheitlichen Quellenlokator (URL) eindeutig adressierbar ist. Seit seiner Einführung hat das World Wide Web eine weltweite Vorrangstellung im täglichen Leben und der Wirtschaft gefunden.
Dieses explosive Wachstum ist jedoch nicht komplikationslos verlaufen. Die ungebremste Ausweitung kommerzieller Anwendungen bringt eine immer weiter wachsende Zahl Benutzer mit sich, die eine immer weiter wachsende Zahl Anfragen starten. Die Probleme der Wartezeit und der Bandbreitenbegrenzungen äußern sich in Verzögerungen, Informationsverlust und genervten Benutzern.
Netzarchitekten antworten mit der Benutzung einer Gruppe von Lösungen. Viele Antworten fallen in die Kategorie von Lösungen, die auf der Zurverfügungstellung von mehr Rechnerleistung basieren. Dieses kann Alternativen umfassen, die verschiedene Webserver-Software, Webserver-Hardware oder Plattform, Vergrößerungen an RAM oder CPU im Server, Anwendungsüberschreibungen oder vergrößerte Netzbandbreite durch aufgerüstete Hardware. Eine andere Lösungsklasse umfasst die Verwendung mehrerer Server oder eine strategische Verteilung von Servern. Ein Verfahren in dieser Klasse besteht darin, den Server am Internet-Serviceprovider anzuordnen. Durch Auswahl eines Serviceproviders mit optimal passender Kapazität kann die Anordnung des Servers am Platz des Serviceproviders zu einer viel besseren Verbindung zum Rest des Internet führen. Eine weitere Möglichkeit ist die Verwendung verteilter Server. Server mit identischem Inhalt werden an strategischen Orten rund um die Welt angeordnet, beispiels weise einer in New York, einer San Francisco und einer in London. Dieses verteilt die Last auf mehrere Server und hält den Verkehr näher am Benutzer. Eine weitere Lösung ist es, Server zusammenzupacken. Eine Zusammenpackung ermöglicht die gemeinsame Verwendung von Festplattengruppen über mehrere Server. Eine weitere Lösung ist die Serverfarm. Dieses umfasst die Verwendung mehrerer Webserver mit identischem Inhalt oder die Segmentierung auf der Grundlage der Funktionalität. Beispielsweise zwei Server für Webfunktionen, zwei für FTP, zwei als Datenbank, usw.. Eine Variante der Serverfarm ist die verteilte Serverfarm. Dieses installiert Server an strategischen Orten – kombiniert im Wesentlichen die Serverfarmlösung mit der Verteilte-Server-Lösung.
Die Lösungen mit mehreren und verteilten Servern lösen ein Problem auf Kosten der Schaffung eines neuen Problems. Wenn mehrere Server vorhanden sind, wie bestimmt der Endbenutzer den Ort Ihrer Seite? Gegenwärtig werden Namen und universale Quelllokatoren (URLs) in eindeutige Einzeladresse durch einen Domainnamensservice (DNS) aufgelöst. DNS-Server unterhalten eine Liste von Domainnamen, die einen Bezug zu individuellen IP-Adressen haben. Wenn jedoch mehrere Webserver oder Serverfarmen verwendet werden, muss das DNS-System modifiziert werden. Eine übliche Lösung für dieses Problem ist es, das DNS-System auf ein Eins-zu-viel-Abbildung von Namen auf IP-Adressen zu modifizieren. Das DNS gibt somit eine Liste von IP-Adressen für jedes spezielle Web-Objekt zurück. Dieses können dann an die verschiedenen Kunden in einer Weise jeder gegen jeden ausgegeben werden. Diese Lösung hat jedoch einige Nachteile. Das Jeder-gegen-Jeden-Paradigma gibt IP-Adressen in einer strengen Reihenfolge mit wenig Rücksicht auf den Ort des Anforderers oder des Servers aus. Das Schema hat keine Kenntnis von der Server-Architektur oder -Belastung. Die Auswahl ergibt lediglich eine einfache Liste. Ein Server kann alle Hochlastbenutzerempfangen. Außerdem bestimmt das schwächste Glied die Gesamtleistung, so dass Serverplattformen relativ gleichwertig sein müssen. Ein weiteres Problem besteht darin, dass das DNS einfach IP-Adressen ausgibt, ohne Rücksicht darauf, ob der Server, zu dem die Adresse gehört, in Betrieb ist. Wenn daher einer der Jeder-gegen-Jeden-Server zufälligerweise wegen Wartungsarbeiten abgeschaltet ist, gibt das DNS die Adresse aus, und mögliche Benutzer erhalten weiterhin Auszeit-Fehlerantworten. Die Jeder-gegen-Jeden-Modifikation des DNS macht also einen breiten Versuch, das Problem verteilter Server zu lösen. Es wird jedoch keine Rücksicht auf den Netzverkehr, auf geringen Lastausgleich unter den Servern oder auf die Zuverlässigkeit genommen.
Mehrere Erzeugnisse auf dem Markt befassen sich mit diesen Problemen, jedoch leiden alle frühere Bemühungen an dem Nachteil, dass sie verlangen, dass die Benutzersoftwareumgebung modifiziert wird, um eine nachgebildete Serverauswahl zu erleichtern. Ein Schema, das Modifikationen an der Benutzersoftware erfordert, ist wegen praktischer Probleme der Sicher stellung einer breiten Softwareverteilung weniger wünschenswert. Solche Schemata sind höchstens als Optimierungstechniken nützlich.
Eine solche Lösungsklasse besteht aus jenen, die auf expliziter Benutzerauswahl zur Zuweisung einer Benutzeranforderung an einen Server beruhen. Die Benutzeranwendung kann zusätzliche Schritte beinhalten, die vom Benutzer ausreichende Kenntnis, Erfahrung und Geduld verlangen, die eigene Serverauswahl auszuführen. Solche Schemata sind aus mehreren Gründen nicht immer wünschenswert.
Eine Technik, die auf der selektiven Host-Leitwegbestimmung beruht, verwendet mehrere nachgebildete Server, sämtlich mit der gleichen Netzadresse, die an unterschiedlichen Punkten in der Netztopologie angeordnet sind. Ein jedem Server zugeordneter Router nimmt den einlaufenden Netzverkehr zu den gemeinsamen Serveradressen auf und liefert den Verkehr an den speziellen Server. Diese Technik kann nur statisch die Benutzeranforderungslast auf den benachbarten Server ohne Berücksichtigung der Serverlast oder anderer Netzcharakteristika statisch verteilen.
Die BIND-Ausführung des DNS-Servers kann Techniken einschließen, um Servernamen an verschiedenen Netzadressen zu binden, wo eine aus einem Satz unterschiedlicher Mehrfachadressen entweder der Reihenfolge nach oder wahlfrei zugewiesen wird. Serviceprovider weisen eine andere Adresse jedem nachgebildeten Server zu, und BIND richtet Benutzeranforderungen an die alternativen Server. Diese Technik kann nur statisch die Benutzeranforderungslast auf einen beliebigen Server verteilen ohne Rücksicht auf die Serverlast oder andere Netzcharakteristika.
SONAR ist ein emporkommendes IETF (Internet Engineering Task Force)-Protokoll zum Verteilen von Netzcharakteristika, insbesondere für topologische Nachbarschaft. SONAR enthält ein Datenformat zum Darstellen von Frageanforderungen und Antworten, es spezifiziert aber keinen Mechanismus zum Bestimmen der Netzcharakterstika.
Der Cisco Local Director ist ein Produkt, das als ein Netzverkehrsmultiplexer arbeitet, der vor mehreren örtlichen Servern sitzt und neue Transportverbindungen an jeden Server auf der Grundlage des Umfangs an Verkehr verteilt, der zu den Servern fließt. Dieses Produkt berücksichtigt bei seiner Entscheidung die Netzcharakterstika nicht, und es erfordert, dass die nachgebildeten Server zusammen angeordnet sind. Cisco Systems ist eine Gesellschaft mit Sitz in San Jose, Kalifornien.
Der Cisco Distributed Director leitet Benutzeranforderungen auf topologisch entfernte Server auf der Grundlage von Information um, die von Netzroutingprotokollen erhalten werden. Der Distributed Director nimmt entweder ankommende DNS-Anforderungen oder HTTP-Anforderungen auf, und liefert die für die Weitersendung geeignete Antwort. Dieses Produkt berücksichtigt nicht die Serverlast und berücksichtigt nur den beschränkten Satz an Information, der aus Routingprotokollen verfügbar ist; diese Information hat durch die Aggregationstechniken, die erforderlich sind, um ein skalierbares Internetrouting zu ermöglichen, auch nur beschränkte Genauigkeit.
EP-A-0 648 038 beschreibt ein Datenverarbeitungssystem zum Erleichtern einer Verbindung eines Programms auf einem Clientenrechner mit Serverrechnern mit gemeinsamen Quellen. Alle diese Rechner befinden sich in einem örtlichen Netz. Es wird eine Entscheidungslogik verwendet, um den Serverrechner unter Verwendung spezieller Testkriterien in Intervallen zu untersuchen. Dies bedeutet, dass nur die Serverrechner, nicht aber das gesamte Netz überwacht werden.
US-A-5 452 294 beschreibt ein Übertragungsnetz mit mehreren verfügbaren Leitwegen. Es wird eine adaptive Leitwegauswahl verwendet, um den besten Leitweg (Route) zwischen einer Quelle und einem Bestimmungsknoten zu finden, indem die Verbindungszustandsvariablen überwacht werden.
Obgleich diese Produkte zusammen die Serverlast und die Netzcharakteristika in Betracht ziehen, führen sie doch keine integrierte Serverauswahl durch. Für all diese Bemühungen klingt die Kritik des Fachmanns richtig, es ist noch immer das "weltweite Warten". Daher wird ein System benötigt, das automatisch einen geeigneten Server auswählt, von dem ein Datenobjekt für einen Benutzer ermittelt wird auf der Grundlage der Benutzeranforderung und der Fähigkeiten und der Topologie des zugrundeliegenden Netzes.
ÜBERSICHT ÜBER DIE ERFINDUNG
Die vorliegende Erfindung schafft die Möglichkeit, Anforderungen nach Datenobjekten durch Clienten unter vielen Netzservern zuzuweisen. Die Erfindung schafft ein verteiltes Rechensystem und Verfahren zum Zuweisen von Benutzeranforderungen zu nachgebildeten Servern, die in dem verteilten Rechensystem enthalten sind, in einer Weise, die danach trachtet, die Ziele einer speziellen Leitwegrichtlinie zu befriedigen. Diese Richtlinien können das Minimieren des Zeitaufwandes für die abzuschließende Anforderung enthalten. Beispielsweise kann ein System nach der Erfindung so konfiguriert sein, dass Datenobjekte an Benutzer in Übereinstimmung mit dem kürzesten verfügbaren Netzweg übermittelt werden.
Die Erfindung gibt insbesondere ein System zum Leiten von Anforderungen nach Datenobjekten von jeder Zahl Clienten zu einem von mehreren Datenservern auf der Grundlage einer "Bester Server"-Leitwegrichtlinie an. Datenserver liefern Datenobjekte, indem sie auf Teilnehmer-anforderungen über einen oder mehrere Netzzugangspunkte ansprechen, entsprechend der Entscheidung eines Direktors. Der Direktor bestimmt auf der Grundlage der Leitwregrichtlinien den Leitweg der Anforderung nach Datenobjekten zu einem bestimmten Datenserver.
In Übereinstimmung mit einem besonderen Aspekt der Erfindung kann die Leitwegrichtlinie eines der nachfolgenden oder eine beliebige Kombination der nachfolgenden oder keine der nachfolgenden Kriterien enthalten: 1) die letzte Nummer offener TCP-Verbindungen; 2) das am meisten verfügbare freie RAM; 3) das am meisten verfügbare freie SWAP (virtueller Speicher); 4) der größte Umfang an CPU-Leerlaufzeit; oder 5) der schnellste ICMP-Leitweg zur Teilnehmermaschine.
Vorteile der Lösungen gemäß der Erfindung sind gesteigerte Toleranz gegenüber Fehlern, die in der zugrundeliegenden Hardware auftreten, und Zuverlässigkeit gegenüber bekannten Web-Servern. Die Erfindung wird besser durch Bezugnahme auf die folgende detaillierte Beschreibung und ihre begleitenden Zeichnungen verstanden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1A zeigt ein repräsentatives Teilnehmer-Server-Verhältnis in Übereinstimmung mit einer speziellen Ausführungsform der Erfindung;
1B zeigt eine Funktionsperspektive des beispielhaften Teilnehmer-Server-Verhältnisses gemäß einer speziellen Ausführungsform der Erfindung;
1C zeigt eine beispielhafte Internet-Arbeitsumgebung gemäß einer speziellen Ausführungsform der Erfindung;
1D zeigt ein Beziehungsdiagramm der Ebenen der TCP/IP-Protokollfolge;
2A zeigt eine verteilte Rechnerumgebung in Übereinstimmung mit einer speziellen Ausführungsform der Erfindung;
2B zeigt eine verteilte Rechnerumgebung in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung;
3A zeigt die Beziehung von Prozessen in Übereinstimmung mit einer beispielhaften Ausführungsform der Erfindung;
3B zeigt die Beziehung von Prozessen in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung;
3C zeigt die Beziehung von Prozessen in Übereinstimmung mit einer bevorzugten Ausführungsform der Erfindung;
4A zeigt Prozessschritte in Übereinstimmung mit einer speziellen Ausführungsform der Erfindung;
4B zeigt Prozessschritte in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung;
4C zeigt Prozessschritte in Übereinstimmung mit einer bevorzugten Ausführungsform der Erfindung; und
5A bis 5C zeigen Flussdiagramme des Optimierungsprozesses innerhalb einer Direktorkomponente in Übereinstimmung mit einer speziellen Ausführungsform der Erfindung.
BESCHREIBUNG DER SPEZIELLEN AUSFÜHRUNGSFORMEN
1.0 Einleitung
Eine bevorzugte Ausführungsform eines Serverlastausgleichssystems gemäß der Erfindung ist in die Praxis umgesetzt worden und wird unter dem Handelsnamen "HOPSCOTCH^®" verfügbar.
Ein Wort über Nomenklatur ist angebracht. Systeme gemäß der vorliegenden Erfindung umfassen eine Vielzahl Prozesse, die in alternativen Ausführungsformen in irgendeinem von vielen Rechnern in einer verteilten Netzumgebung vorhanden sein können, oder als konkurrierende Prozesse, die in virtuellen Maschinen oder Adressräumen am gleichen Rechner ablaufen kön nen. Um das exponentielle Wachstum von Namen zu begrenzen, sind die folgenden Abmachungen verwendet worden, um die Lesbarkeit zu verbessern. Individuelle Abweichungen werden angegeben, wo sie auftreten. Ein 'xyz-Server' ist ein Rechner oder eine virtuelle Maschine, die eine Sammlung von Prozessen enthält, die xyz bilden. Eine 'xyz-Komponente' ist eine Sammlung Prozesse, die einen Satz Funktionen durchführen, die gemeinsam als xyz bezeichnet werden. Eine 'xyz' ist ein Satz Funktionen, die durch die xyz-Komponente auf der xyz-Maschine ausgeführt werden.
1.1 Hardware-Übersicht
Das verteilte Rechensystem für den Serverlastausgleich (das "System") der vorliegenden Erfindung ist in der Perl-Programmiersprache ausgeführt und wird auf einem Rechnersystem betrieben, wie in 1A gezeigt. Diese Erfindung kann in einer Teilnehmer-Server-Umgebung ausgeführt werden, jedoch ist eine Teilnehmer-Server-Umgebung nicht wesentlich. 1A zeigt ein konventionelles Teilnehmer-Server-Rechnersystem, das einen Server 20 und zahlreiche Clienten enthält, von denen einer als Teilnehmer 25 gezeigt ist. Die Verwendung des Ausdrucks "Server" wird im Kontext der Erfindung verwendet, in dem der Server Anfragen von (typischerweise entfernten) Clienten empfängt, im Wesentlichen die gesamte Verarbeitung ausführt, die zur Formulierung von Antworten auf die Anfragen notwendig ist, und diese Anforderungen an die Clienten abgibt. Der Server 20 kann jedoch selbst in der Eigenschaft als ein Teilnehmer wirken, wenn er auf entfernte Datenbanken zugreift, die an einem anderen Knoten angeordnet sind, der als Datenbank-Server arbeitet.
Die Hardwarekonfigurationen sind im Allgemeinen Standard und werden nur kurz beschrieben. In Übereinstimmung mit bekannter Praxis enthält der Server 20 einen oder mehrere Prozessoren 30, die mit mehreren Peripheriegeräten über ein Bus-Untersystem 32 kommunizieren. Diese Peripheriegeräte enthalten typischerweise ein Speicher-Untersystem 35, das aus einem Speicher-Untersystem 35a und einem Datenspeicher-Untersystem 35b besteht, die Rechnerprogramme (z. B. Kode oder Befehle) und Daten enthalten, einen Satz Benutzerschnittstellen-Eingabe- und -Ausgabevorrichtungen 37 und eine Schnittstelle zu äußeren Netzen, die Ethernet, Tornring, ATM, IEEE 802.3, ITU X.25, Serial Link Internet Protocol (SLIP) oder das öffentliche Telefonvermittlungsnetz verwenden können. Diese Schnittstelle ist schematisch als ein "Netzschnittstelle"-Block 40 gezeigt. Sie ist mit entsprechenden Verschachtelungsvorrichtungen in Clientenrechnern über eine Netzverbindung 45 gekoppelt.
Der Teilnehmer 25 hat den gleichen allgemeinen Aufbau, obgleich typischerweise mit weniger Speicher- und Prozessorkapazität. Während der Clientenrechner ein Endgerät oder ein Klein- PC sein kann, ist der Serverrechner somit im Allgemeinen eine Groß-Workstation oder Hauptrechner, beispielsweise ein Server vom Typ SUN SPARC^®. Entsprechende Elemente und Untersysteme im Clientenrechner sind mit entsprechenden Bezugszeichen dargestellt, die jedoch mit einem Apostroph versehenen sind.
Die Benutzerschnittstellen-Eingabevorrichtungen sind typischerweise eine Tastatur und können weiterhin eine Zeigervorrichtung und ein Scanner sein. Die Zeigervorrichtung kann eine indirekte Zeigervorrichtung, wie beispielsweise eine Maus, ein Trackball, ein Berührungsfeld oder ein Graphiktablett sein, oder sie kann eine direkte Zeigervorrichtung sein, z. B. ein Berührungsschirm, der in die Anzeigevorrichtung integriert ist. Andere Arten von Benutzerschnittstellen-Eingabevorrichtungen, wie Spracherkennungssysteme, sind ebenfalls möglich.
Die Benutzerschnittstellen-Ausgabevorrichtungen enthalten typischerweise einen Drucker und ein Anzeige-Untersystem, das einen Anzeigesteuerer und eine Anzeigevorrichtung umfasst, die mit dem Steuerer verbunden ist. Die Anzeigevorrichtung kann eine Kathodenstrahlröhre (CRT), ein Flachbildschirm, wie beispielsweise ein Flüssigkristallschirm (LCD) oder eine Projektionsvorrichtung sein. Der Anzeigesteuerer liefert Steuersignale an die Anzeigevorrichtung und enthält normalerweise einen Anzeigespeicher zum Speichern der Pixel, die auf der Anzeigevorrichtung erscheinen. Das Anzeigeuntersystem kann auch eine unsichtbare Anzeige liefern, wie beispielsweise eine akustische Ausgabe.
Das Speicheruntersystem enthält typischerweise mehrere Speicher mit einem Haupt-Arbeitsspeicher (RAM) zur Speicherung von Befehlen und Daten während der Programmausführung und einem Festspeicher (ROM), in dem feste Befehle gespeichert sind. Im Falle von Macintosh-kompatiblen PCs würde der ROM Teile des Betriebssystems enthalten; im Fallen von IBM-kompatiblen PCs würde er das BIOS (Basic Input/Output System) enthalten.
Das Dateispeicheruntersystem bietet eine dauerhafte (nicht flüchtige) Speicherung für Programm- und Daten-Dateien und enthält typischerweise wenigstens ein Festplattenlaufwerk und wenigstens ein Diskettenlaufwerk (mit zugehörigen entnehmbaren Medien). Es können auch andere Vorrichtungen, wie beispielsweise ein CD-ROM-Laufwerk und optische Laufwerke (sämtlich mit ihren zugehörigen entnehmbaren Medien) vorhanden sein. Außerdem kann das Rechnersystem Laufwerke enthalten, die mit entnehmbaren Speicherkassetten arbeiten. Die entnehmbaren Speicherkassetten können beispielsweise Festplattenkassetten sein, wie beispielsweise jene, die von Syquest und anderen angeboten werden, und solche mit flexiblen Disketten, wie jene, die von Iomega vertrieben werden. Eine oder mehrere der Laufwerke kön nen an einer entfernten Stelle angeordnet sein, wie beispielsweise in einem Server oder in einem örtlichen Netz (LAN) oder an einem Platz des World Wide Web des Internet.
In diesem Kontext wird der Ausdruck "Bus-Untersystem" generisch verwendet, so dass er jeden Mechanismus einschließt, der die zahlreichen Komponenten und Untersysteme miteinander kommunizieren lässt, wie es beabsichtigt ist. Mit Ausnahme der Eingabevorrichtungen und der Anzeige brauchen die anderen Komponenten nicht am gleichen physikalischen Ort zu sein. So könnten beispielsweise Teile des Dateispeichersystems über zahlreiche örtliche oder überörtliche Netzmedien, einschließlich Telefonleitungen, angeschlossen sein. In gleicher Weise brauchen die Eingabevorrichtungen und die Anzeige nicht am gleichen Ort wie der Prozessor zu sein, obgleich vorausgesetzt wird, dass die vorliegende Erfindung am häufigsten im Kontext von PCs und Workstations ausgeführt wird.
Das Bus-Untersystem 32 ist schematisch als ein einzelner Bus gezeigt, jedoch hat ein typisches System mehrere Busse, wie beispielsweise einen örtlichen Bus und einen oder mehrere Erweiterungsbusse (z. B. ADB, SCSI, ISA, EISA, MCA, NuBus oder PCI), sowie serielle und parallele Anschlüsse. Netzverbindungen werden gewöhnlich über eine Vorrichtung, wie beispielsweise einen Netzadapter, an einem dieser Ausdehnungsbusse, oder über ein Modem an einem seriellen Anschluss eingerichtet. Der Clientenrechner kann ein Tischrechner oder ein tragbares System sein.
Der Benutzer arbeitet mit dem System unter Verwendung von Schnittstellenvorrichtungen 37' (oder Vorrichtungen 37 in einem Einzelsystem) zusammen. Beispielsweise werden Clientenanfragen über eine Tastatur eingegeben, dem Clientenprozessor 30' übermittelt und dann über das Bus-Untersystem 32' zu einer Netzschnittstelle 40' geleitet. Die Anfrage wird dann über die Netzverbindung 45 an den Server 20 übermittelt. In gleicher Weise werden die Ergebnisse der Anfrage vom Server an den Clienten über die Netzverbindung 45 zur Ausgabe auf einer der Vorrichtungen 37' (beispielsweise eine Anzeige oder ein Drucker) übermittelt, oder können in einem Speicher-Untersystem 35' gespeichert werden.
1B ist ein Funktionsdiagramm des Rechnersystems von 1A. 1B zeigt einen Server 20 und einen repräsentativen Clienten aus mehreren Clienten, die mit dem Server 20 über das Internet 45 oder irgendwelchen anderen Kommunikationsverfahren zusammenwirken können. Blöcke auf der rechten Seite des Servers stehen für die Prozesskomponenten und -funktionen, die im Serverprogramm und im Datenspeicher, auftreten, der durch den Block 35a in 1A gezeigt ist. Ein TCP/IP-"Stapel" 44 arbeitet mit dem Betriebssystem 42 zusammen, um mit Prozessen über ein Netz oder eine serielle Verbindung zu kommunizieren, die den Server 20 an das Internet 45 anschließt. Webserversoftware 46 läuft gleichzeitig und in Zusammenarbeit mit anderen Prozessen im Server 20 ab, um Datenobjekte 50 und 51 den anfordernden Clienten verfügbar zu machen. Ein Common Gateway Interface (CGI)-Skript 51 ermöglicht es Information von Benutzern vom Webserver 46 oder anderen Prozessen im Server 20 verarbeiten zu lassen. Antworten auf Clientenanfragen können an die Clienten in Form von Hypertext Markup Language (HTML)-Dokumentenausgaben zurückgegeben werden, die dann über das Internet 45 zum Benutzer übertragen werden.
Der Teilnehmer 25 in 1b besitzt Software, die Funktionsprozesse ausführt, die operativ in ihrem Programm- und Datenspeicher angeordnet ist, wie durch den Block 35a' in 1A angegeben ist. Der TCP/IP-Stapel 44' arbeitet zusammen mit dem Betriebssystem 42', um mit Prozessen über ein Netz oder eine Serienverbindung, die den Clienten 25 an das Internet 45 anschließt, zu kommunizieren. Software, die die Funktion eines Webbrowsers 46' ausführt, läuft gleichzeitig und in Zusammenarbeit mit anderen Prozessen beim Clienten 25 ab, um Anfragen des Servers 20 nach Datenobjekten 50 und 51 zu machen. Der Benutzer des Clienten kann über den Webbrowser 46' interagieren, um solche Anfragen des Servers 20 über Internet 45 zu machen und die Antworten vom Server 20 über das Internet 45 am Webbrowser 46' zu betrachten.
1.2 Netzübersicht
1C zeigt den Internetverkehr mehrerer Clienten, wie Teilnehmer 25 der 1A und 1B und mehrerer Server, wie Server 20 der 1A und 1B, wie oben beschrieben. In 1C ist ein Netz 70 beispielsweise ein Tokenring oder rahmenorientiertes Netz. Das Netz 70 verbindet einen Host 71, wie beispielsweise eine Workstation IBM RS6000 R1SC, in der das AIX-Betriebssystem laufen kann, mit einem Host 72, der ein PC ist und mit Windows 95, IBM OS/2 oder 1)05 als Betriebssystem läuft, mit einem Host 73, der ein Rechner IBM AS/400 sein kann und mit OS/400 als Betriebssystem läuft. Das Netz 70 ist über Internet mit einem Netz 60 über ein Systemgateway verbunden, das hier als Router 75 dargestellt ist, das aber auch ein Gateway sein kann, das eine Firewall oder eine Netzbrücke hat. Das Netz 60 ist ein Beispiel eines Ethernet-Netzes, das einen Host 81, der eine SPARC Workstation ist und mit SUNOS als Betriebssystem läuft, mit einem Host 62 verbindet, der ein Rechner VAX6000 von Digital Equipment sein kann und mit VMS als Betriebssystem laufen kann.
Der Router 75 ist ein Netzzugangspunkt (NAP) des Netzes 70 und des Netzes 60. Der Router 75 verwendet einen Tokenring-Adapter und einen Ethernet-Adapter. Dieses ermöglicht es dem Router 75, mit den zwei heterogenen Netzen verbunden zu werden. Der Router 75 kennt auch die Inter-Netzprotokolle, wie beispielsweise ICMP ARP und RIP, die unten beschrieben werden.
1D zeigt die Bestandteile der Transmission Control Protocol Internet Protocol (TCP/IP)-Protokollfolge. Die Grundebene der TCP/IP-Protokollfolge ist die physikalische Ebene 80, die die mechanischen, elektrischen funktionalen und Prozedurstandards für die physikalische Datenaussendung über Kommunikationsmedien, wie beispielsweise die Netzverbindung 45 von 1A definiert. Die physikalische Ebene kann elektrische, mechanische oder funktionale Standards enthalten, beispielsweise ob ein Netz ein paketschaltendes oder ein flammenschaltendes Netz ist, oder ob ein Netz auf einem Carrier Sense Multiple Access/Collision Detection (CSMA/CD)- oder einem Rahmenrelais-Paradigma beruht.
Über der physikalischen Ebene liegt die Datenverbindungsebene 82. Die Datenverbindungsebene liefert die Funktion und Protokolle zur Übertragung von Daten zwischen Netzquellen und ermittelt Fehler, die in der physikalischen Ebene auftreten können. Betriebsarten in der Datenverbindungsebene umfassen solche standardisierten Netztopologien, wie IEEE 802.3 Ethernet, IEEE 802.5 Tokenring, ITU X.25 oder serielle (SLIP) Protokolle.
Netzebenenprotokolle 87 liegen über der Datenverbindungsebene und bilden die Einrichtung zum Erstellen von Verbindungen zwischen Netzen. Die Standards der Netzebenenprotokolle liefern Betriebssteuerprozeduren für Internetverbindungen und Leitweginformation durch mehrere heterogene Netze. Beispiele von Netzebenenprotokolle sind das Internetprotokoll (IP) und das Internet Control Message Protocol (ICMP). Das Address Resolution Protocol (ARP) dient der Korrelierung einer Internetadresse und einer Media Access Adresse (MAC) eines speziellen Host. Das Routing Information Protocol (RIP) ist ein dynamisches Leitwegprotokoll für die Vermittlung von Leitweginformation zwischen Hosts auf Netzen. Das Internet Control Message Protocol (ICMP) ist ein internes Protokoll zum Durchleiten von Steuermitteilungen zwischen Hosts auf zahlreichen Netzen. ICMP-Mitteilungen schaffen Rückmeldung über Ereignisse in der Netzumgebung oder können bei der Ermittlung helfen, ob zu einem speziellen Host in der Netzumgebung ein Weg vorhanden ist. Letztere wird ein "Ping" genannt. Das Internet Protocol (IP) schafft den Grundmechanismus für das Leiten von Informationspaketen im Internet. IP ist ein unzuverlässiges Übertragungsprotokoll. Es schafft einen "bestmöglichen" Lieferservice und vertraut keine Netzquelle einer speziellen Transaktion an, noch führt sie wiederholte Aussendungen durch oder gibt sie Bestätigungen ab.
Die Transportebenenprotokolle 86 schaffen Transportdienste von Ende zu Ende über mehrere heterogene Netze. Das User Datagram Protocol (UDP) bietet einen verbindungslosen, Da tagramm-orientierten Service, der einen unzuverlässigen Liefermechanismus für Informationsströme bereitstellt. Das Transmission Control Protocol (TCP) bietet einen zuverlässigen Service auf Session-Grundlage zur Lieferung von seriellen Informationspaketen über das Internet. TCP schafft einen Verbindungs-orientierten, zuverlässigen Mechanismus für die Informationsübermittlung.
Die Sessions-Anwendungsebene 88 liefert eine Liste von Netzanwendungen und Werkzeugen, von denen einige hier dargestellt sind. Beispielsweise ist das File Transfer Protocol (FTP) ein Standard-TCP/IP-Protokoll zur Übertragung von Dateien von einer Maschine zu einer anderen. FTP-Teilnehmer richten Sessionen über TCP-Verbindungen mit FTP-Servern ein, um Dateien zu erhalten. Telnet ist ein Standard-TCP/IP-Protokoll für ferne Endgerätverbindung. Ein Telnet-Teilnehmer wirkt als ein Endgerät-Emulator und richtet eine Verbindung unter Verwendung von TCP als Transportmechanismus mit einem Telnet-Server ein. Das Simple Network Management Protocol (SNMP) ist ein Standard zur Verwaltung von TCP/IP-Netzen. SNMP-Aufgaben, genannt "Agenten" überwachen Netzstatusparameter und senden diese Statusparameter an SNMP-Aufgaben, genannt "Manager". Die Manager verfolgen den Status zugehöriger Netze. Ein Remote Procedure Call (RPC) ist eine Programmierschnittstelle, die es Programmen ermöglichen, entfernte Funktionen auf Servermaschinen aufzurufen. Das Hypertext Transfer Protocol (HTTP) erleichtert die Übertragung von Datenobjekten über Netze über ein System von gleichen Quellindikatoren (URI).
Das Hypertext Transfer Protocol ist ein einfaches Protokoll, das auf der Transmission Control Protocol (TCP) aufgesetzt ist. Das HTTP liefert ein Verfahren für Benutzer, um Datenobjekte von zahlreichen Hosts zu erhalten, die als Server im Internet arbeiten. Benutzeranfragen nach Datenobjekten werden mittels einer HTTP CET-Anforderung gemacht. Eine GET-Anforderung, wie unten dargestellt, enthält 1) einen HTTP-Kopf des Formats "http://", gefolgt von 2) einem Identifizierer des Servers, bei dem sich das Datenobjekt befindet, gefolgt von 3) dem vollständigen Pfad des Datenobjekts, gefolgt von 4) dem Namen des Datenobjekts. In der unten gezeigten GET-Anforderung wird eine Anforderung des Servers "www.w3.org" für das Datenobjekt mit einem Pfadnamen "/pub/" und dem Namen "MyData.html" gemacht:
GET http://www.w3.org/pub/My/Data.html (1)
Die Verarbeitung einer GET-Anforderung zieht die Einrichtung einer TCP/IP-Verbindung mit dem Servernamen in der GET-Anforderung und dem Empfang des spezifizierten Datenobjekts vom Server nach sich. Nach Empfang und Interpretation einer Anforderungsmitteilung antwortet ein Server in Form einer HTTP RESPONSE-Mitteilung.
Antwortmitteilungen beginnen mit einer Statuszeile, die eine Protokollversion enthält, gefolgt von einem numerischen Status Code und einer zugehörigen Text Reason Phrase. Diese Elemente sind durch Zwischenraumzeichen getrennt. Das Format einer Statuszeile ist in Zeile (2) aufgetragen:
Statuszeile = HTTP-Version Status-Code Reason-Phrase (2)
Die Statuszeile beginnt stets mit einer Protokollversion und einem Statuskode, z. B. "HTTP/1.0 200". Das Statuskodeelement ist ein dreistelliger, ganzzahliger Ergebniskode des Versuchs, die vorangehende Anforderungsmitteilung zu verstehen und zu befriedigen. Die Grundphrase soll eine kurze Textbeschreibung des Statuskodes geben. Die erste Stelle des Statuskodes bestimmt die Antwortklasse. Es gibt fünf Kategorien für die erste Stelle. 1XX ist eine Informationsantwort. Sie wird gegenwärtig nicht verwendet. 2XX ist eine erfolgreiche Antwort, die Aktion wurde erfolgreich empfangen, verstanden und akzeptiert. 3XX ist eine Weitersendeantwort, die anzeigt, dass weitere Aktion notwendig ist, um die Anforderung zu vervollständigen. Es ist diese Antwort, die von manchen Ausführungsformen der vorliegenden Erfindung verwendet wird, um einen Clienten zu veranlassen, sich erneut an einen ausgewählten Serverplatz zu wenden. 4XX ist eine Clientenfehlerantwort. Diese zeigt eine schlechte Syntax in der Anforderung an. Schließlich ist 5XX ein Serverfehler. Dieses zeigt an, dass der Server eine offensichtlich gültige Anforderung nicht erfüllt hat.
Spezielle Formate von HTTP-Mitteilungen sind beschrieben in D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD II, RFC 822, UDEL, August 1982, die hier für alle Zwecke durch Bezugnahme eingeschlossen wird.
2.0 Spezielle Konfigurationen
2A zeigt ein repräsentatives, verteiltes Berechnungssystem gemäß der vorliegenden Erfindung. In 2A verbindet ein Netz 200 mehrere Servermaschinen miteinander und mit einer äußeren Internetumgebung über mehrere Netzzugangspunkte (NAPs). Die Topologie dieses internen Netzes ist vollständig willkürlich bezüglich der Erfindung. Es kann Ethernet, Tokenring, Asynchronous Transfer Mode (ATM) oder jede andere geeignete Netztopologie sein. Die Netzzugangspunkte sind Verbindungspunkte zwischen großen Netzen und können Router, Gateways, Brücken oder andere Verfahren enthalten, um Netze in Übereinstimmung mit speziellen Netztopologien miteinander zu verbinden.
Netzzugangspunkte 202, 204, 206 und 208 schaffen eine Netzerreichbarkeit zu äußeren Netzen A, B, C und D für die Verbindung mit Clientenmaschinen über mehrere äußere Netzpfade. In einer speziellen Ausführungsform enthalten diese Netzzugangspunkte einen Teil der Leitwegkonfigurationskomponente. In einer bevorzugten Ausführungsform sind diese NAPs Router 222, 224, 226 und 228, die zu anderen Netzen passen und für Open Shortest Path First (OSPF)-Leitwegalgorithmus offen sind. OSPF ist in der Lage, den Fall zu behandeln, bei dem mehrere Maschinen exakt die gleiche IP-Adresse haben, indem Pakete zur nächsten Maschine geleitet werden. Hingegen würde ein alternativer Leitwegmechanismus, Routing Information Protocol (RIP), diesen Fall nicht handhaben.
Weiterhin verwenden diese Router IP-Tunnelungstechniken, die dem Fachmann allgemein bekannt sind, und sind für die Schaffung von Leitwegen nach Vorgabe in der Lage, d. h. sie können Pakete zum Teil auf der Grundlage ihrer Quellenadresse leiten. Jede ist so gestaltet, dass IP-Tunnelung verwendet wird, um Pakete aus dem Netz über einen speziellen Router an eine spezielle NAP auf der Grundlage von Mantelquellenadressen und Serververfügbarkeit zu leiten.
2A zeigt Frontende-Server 212, 214, 216 und 218, die an jeder NAP angeordnet sind. Diese Frontende-Server enthalten einen Frontende-Komponentenprozess. In einer bevorzugten Ausführungsform enthalten die Frontendeserver auch einen IP-Relaiskomponentenprozess. Die Funktionen dieser Prozesse werden unten beschrieben.
Ein Direktor-Server 250 enthält mehrere Softwarekomponenten, die in einer bevorzugten Ausführungsform eine Direktokomponente, eine Ping-Manager-Komponente und eine Lastmanager-Komponente enthalten, die jeweils unten beschrieben werden.
Einer oder mehrere Inhaltsserver 232, 234, 236 und 238 führen die wirkliche Abgabe von Inhalt durch, d. h. von Webseiten oder FTP-Dateien. Jedem sind eine oder mehrere Beispiele einer Inhaltsserverkomponente zugeordnet, die in der Lage ist, Daten abzugeben, beispielsweise, dass ausgehende Pakete eine Quellenadresse haben, die durch die Direktorkomponente auswählbar ist.
Jeder Inhaltsserver hat eine Netzpseudonym-IP-Adresse für jeden Router, die durch das System gesteuert ist. Beispielsweise hat in einem System mit vier Routern ein spezieller Inhaltsserver vier getrennte Netzpseudonym-IP-Adressen. Die Leitwegbestimmung innerhalb des Systems wird für die "Richtlinien-Leitwegbestimmung" konfiguriert, d. h. ein Leitweg auf der Grundlage der Quellenadressen von Paketen bestimmt, so dass in Abhängigkeit davon, woher die Netzpseudonym-IP-Adresse stammt, sie durch einen speziellen Systemrouter geleitet werden, der von dem Direktor ausgewählt wird. Eine Serie wählbarer IP-Tunnel ermöglichen es den Inhaltsservern, Daten an Clienten unter Verwendung eines "besten Leitwegs" zu senden. IP-Tunnel sind so konfiguriert, dass jeder Server Daten über einen gewählten Netzzugangspunkt anbieten kann. Hingegen liefern allgemein bekannte Systeme Daten, die vom Netz über einen Standardbeobachtungspunkt ausgeleitet werden, d. h. Netzausgangspunkte, die zu anderen Netzen führen, die das Internet bilden. Typischerweise ist der Netzbeobachtungspunkt der einzige Beobachtungspunkt für das Netz. Jeder IP-Tunnel ist so konfiguriert, dass er alle Daten zu einem anderen Beobachtungsrouter sendet. Jeder IP-Tunnel startet an einem Router und endet an einem anderen (entfernten) Router. Dieses ermöglicht es einer Inhaltsserverfarm (einer oder mehrere Inhaltsserver am gleichen physikalischen Ort, die hinter einem Router arbeiten), Daten über den Router einer anderen Inhaltsserverfarm anzubieten, wenn der Direktor bestimmt hat, dass dieses der optimale Pfad ist.
Router sind statistisch so konfiguriert, dass sie Pakete abwärts eines IP-Tunnels senden, wenn die Pakete eine Quellenadresse haben, die diesem IP-Tunnel zugeordnet sind. Beispielsweise in einem Netz, das drei Beobachtungspunkte hat, würde der Router am ersten Beobachtungspunkt, er sei "A" genannt, zwei ausgehende Tunnel haben, "Tunnel 1" und "Tunnel 2". Diese ausgehenden Tunnel führen zu den anderen beiden Routern, die jeweils in einem der anderen beiden Beobachtungspunkte, B und C, liegen. Der Router am Beobachtungspunkt A wäre so konfiguriert, dass er alle Pakete, die eine Quellenadresse von 1.1.1.1 haben, den Tunnel 1 hinableiten, und alle Pakete, die eine Quellenadresse 2.2.2.2 haben, den Tunnel 2 hinableiten. Tunnel 1 sendet alle Pakete an einen zweiten Beobachtungspunkt B, und Tunnel 2 sendet alle Pakete zu einem dritten Beobachtungspunkt C. Diese Leitwegbestimmung auf Quellenbasis ist allgemein als "Richtlinien-Leitwegbestimmung" (Policy Routing) bekannt.
Ein Inhaltsserver, der dem Router am Beobachtungspunkt A zugeordnet ist, läuft mit Serversoftware, die die örtliche Seite seiner Serverfassungen an Adressen 1.1.1.1 und 2.2.2.2 bindet, was es ihm ermöglicht, aus beiden Adressen zu bedienen. Die Direktorsoftware besitzt Konfigurationsinformation über diesen Inhaltsserver und seine Serveradressen. Dieses ermöglicht es dem Direktor zu bestimmen, dass wenn der Inhaltsserver von der 1.1.1.1-Adresse bedient, alle Pakete über Tunnel 1 zum Netzzugangspunkt B geleitet werden, und wenn der Inhaltsserver von der 2.2.2.2-Adresse bedient, alle Pakete über Tunnel 2 zum Netzzugangspunkt C geleitet werden. Die Direktorsoftware ist in der Lage, den NAP zu wählen, über den jeder Inhaltsserver seine Daten anbietet, indem der Teilnehmer informiert wird, welcher voll taugliche Domainname entsprechend einer IP-Adresse den Zugang ermöglicht, da dieses die Quellenadresse der Antwortpakete auf die Anforderung ist. Die Antwortpakete werden automatisch durch den von der Direktorsoftware gewählten NAP geleitet.
Diese Konfiguration der Richtlinien-Leitwegbestimmung wird für jedes System bei der Installation einmal eingerichtet. Der Direktor hat Zugang zu einer Tabelle IP-Adressen für jeden Inhaltsserver und den entsprechenden Systemrouter für jede der IP-Adressen eines speziellen Inhaltsservers. Dieses ermöglicht es dem Direktor, eine Inhaltsserver-IP-Adresse zu wählen, die durch den Systemrouter der Wahl des Direktors leitet. Der Direktor muss zunächst entscheiden, welcher Inhaltsserver die geringste Last hat. Er formuliert dieses aus den Daten, die ihm durch den Lastmanager gegeben wird (der seinerseits die Daten von jedem der Last-Deamons sammelt). Sobald der Direktor die am geringsten belastete Inhaltsservermaschine gewählt hat, wählt er eine Adresse aus dem Satz Netzpseudonym-IP-Adressen dieser Maschine, die durch einen Router führt, der die beste ICMP-Einweglaufzeit zum abprüfenden Teilnehmer hat. Er macht diese Entscheidung auf der Grundlage von Daten, die ihm vom Ping-Manager gegeben werden (der seinerseits seine Daten von den Ping-Daemons sammelte).
2B zeigt eine alternative Ausführungsform eines verteilten Rechensystems gemäß der vorliegenden Erfindung. Die Ausführungsform von 2B unterscheidet sich von der Ausführungsform von 2A vor allem darin, dass die Ausführungsform von 2B keinen getrennten Direktorserver hat. Vielmehr sind in der alternativen Ausführungsform von 2B die Prozesse, die am Direktorserver 250 in 2A abliefen, unter den Frontende-Servern 212, 214, 216 und 218 in 2B verteilt.
3.0 Spezielle Prozesse
3A zeigt die Prozesskomponenten einer repräsentativen Ausführungsform gemäß der vorliegenden Erfindung.
3.1 Prozesskomponenten
Das Frontende – Eine Ausführungsform einer Frontende-Komponente 360 empfängt Clientenanforderungen nach Datenobjekten. Es kann eine ankommende HTTP-Anforderung in der bevorzugten Ausführungsform sein. Das Frontende ermittelt zunächst "Rat" von den Direktorkomponenten 362, falls verfügbar, indem sofort die IP-Adresse des suchenden Clienten zum Direktor gesandt wird, und wartet darauf, dass der Direktor den "besten" Server auswählt. Schließlich sendet er eine Antwort zum anfordernden Clienten, die den Clienten anweist, einen speziellen Server für die weitere Verarbeitung der Anforderung anzusprechen. Das Frontende muss das Protokoll der Clientenanforderung verstehen und wird anwendungsspezifische Mechanismen verwenden, um den Clienten zum speziellen Server zu leiten. In einer speziellen Ausführungsform sendet das Frontende dem suchenden Clienten eine HTTP-Weitersendungsantwort zum URL des besten Servers. Eine Ausführungsform dieser Erfindung kann mehrere Frontende-Komponenten enthalten, die ein oder mehrere Benutzerebenenprotokolle verstehen.
Der Direktor – Eine Ausführungsform einer Direktorkomponente 362 empfängt Datenanfragen von Frontende-Komponenten 360 und unter Verwendung von Daten über die Quelle des Clienten, vorzugsweise die IP-Adresse des anfragenden Clienten sowie von nachgebildeten Serverstatus- und Netzpfadcharakteristika, vorzugsweise ICMP-Echoantwortzeiten, die von den Kollektorkomponenten empfangen werden, wie beispielsweise dem Ping-Manager 364 und dem Last-Manager 366, gibt sie Information zurück, die es den Frontenden ermöglicht, Benutzeranforderungen zu leiten. Die Entscheidung berücksichtigt alle Daten und sendet dem Frontende die IP-Adresse des "besten" Servers. Direktorkomponenten enthalten die Entscheidungsverfahren zur Bewertung alternativer Serverwahlen und schaffen eine Koordination für das gesamte System. Eine Ausführungsform dieser Erfindung enthält eine oder mehrere Direktorkomponenten.
Die Kollektorkomponenten – Eine Ausführungsform einer Kollektorkomponente überwacht eine oder mehrere Charakteristika von Netzpfaden oder Inhaltsserverlast und macht diese Information der Direktorkomponente zur Verwendung bei der Serverauswahlentscheidung verfügbar. Eine Ausführungsform dieser Erfindung enthält eine oder mehrere Kollektorkomponenten, vorzugsweise eine Ping-Manager-Komponente 364, eine Ping-Daemon-Komponente (nicht gezeigt), eine Last-Manager-Komponente 366 und eine Last-Daemon-Komponente (nicht gezeigt).
Der Ping-Manager unterrichtet den Direktor, welcher Inhaltsserver den schnellsten ICMP-Echopfad hat. Diese Daten werden vom Ping-Manager 364 gesammelt. Der Ping-Manager erhält seine Pingzeitdaten von einzelnen Servermaschinen, die jeweils ICMP-Pings verwenden, um die ICMP-Leitwegbestimmungszeit zwischen sich selbst und der Maschine des suchenden Clienten zu bestimmen. Der Ping-Manager speichert dann diese Information und berichtet sie an den Direktor, der sie bei den Entscheidungen über den besten Leitweg verwendet.
Der Ping-Daemon läuft auf Servermaschinen, die jeder Inhaltsservermaschinenansammlung zugeordnet sind. Eine Inhaltsservermaschine (oder Ansammlung von ihnen) befindet sich nahe jedem der Netzzugangspunkte (NAPs). Der Ping-Daemon wartet auf eine Ping-Anforderung (und seine entsprechende IP-Adresse, die die IP-Adresse des suchenden Clienten ist) und "pingt" dann die IP-Adresse des suchenden Clienten, um die ICMP-Leitwegbestimmungszeit durch den eigenen, nächsten Grenzrouter aufzuzeichnen. Er sendet dann diese Daten zurück zum Ping-Manager.
Die Lastmanager-Software ist ähnlich dem Ping-Manager, berichtet und speichert aber Information vom Last-Daemon über jede laufende Belastung der Inhaltsservermaschinen. Sie sendet diese Daten auch zum Direktor.
Der Last-Daemon läuft zusammen mit jedem Inhaltsserver 368 und berichtet periodisch zurück zum Lastmanager. Er sendet Daten über die Anzahl gegenwärtig offener TCP-Verbindungen, freier RAM-, freier SWAP- und CPU-Leerlauf-Zeit.
3B zeigt die Softwarekomponenten einer alternativen Ausführungsform gemäß der vorliegenden Erfindung. Wenn man das Softwarekomponentendiagramm der alternativen Ausführungsform von 3B mit dem der Ausführungsform von 3A vergleicht, dann besteht der Hauptunterschied zwischen zwei Ausführungsformen darin, dass in der alternativen Ausführungsform von 3B der Direktorprozess 362 auf zahlreiche Server verteilt ist. In 3B ist der Direktorprozess 363 daher als drei separate Direktorprozessinstanzen gezeigt. In 3A hingegen ist der Direktorprozess 362 als ein einziger Direktorprozess gezeigt, der mit anderen Prozessen auf mehreren Servern in Verbindung ist.
3C zeigt die Softwarekomponenten einer bevorzugten Ausführungsform gemäß der vorliegenden Erfindung. Im Vergleich des Softwarekomponentendiagramms der Ausführungsform von 3B mit dem der Ausführungsform von 3C besteht der Hauptunterschied zwischen den zwei Ausführungsformen darin, dass in der Ausführungsform von 3C der Frontende-Prozess 360 eine IP-Relais-Funktion enthält.
Das Frontede/IP-Relais – Eine Ausführungsform einer Frontende/IP-Relais-Komponente 360 empfängt einlaufende IP-Pakete für jeglichen IP-Verkehr. Wie in den Ausführungsformen der 3A und 3B erbittet das Frontende zunächst "Rat" von den Direktorkomponenten 362, falls verfügbar, indem sofort die IP-Adresse des Clienten zum Direktor gesandt und darauf gewartet wird, dass der Direktor den "besten" Server wählt. Anstatt jedoch den Clienten anzuweisen, einen speziellen Server für weitere Anforderungsverarbeitung zu kontaktieren, wie von den Frontende-Komponenten der Ausführungsformen der 3A und 3B durchgeführt, leitet das IP-Relais die Pakete zum gewählten "besten" Server in Übereinstimmung mit der Bestimmung, die durch den Direktor getroffen wurde. Eine Ausführungsform dieser Erfindung kann mehrere Frontende-Komponenten enthalten, die als die IP-Ebene funktionieren.
3.2 Schritte zur Bedienung einer Anforderung
4A zeigt einen Satz Schritte, die bei der Verarbeitung bei Empfang, Bewertung und Beantwortung einer Kundenanforderung in einer speziellen Ausführungsform der Erfindung auftreten. In einem Schritt 402 aktualisiert ein Last-Daemon-Prozess, der sich bei einem Inhaltsserver befindet, wie 232 von 2A, periodisch Information direkt an einem Lastmanagerprozess 366, der an einem Direktorserver 250 wirkt. Anschließend aktualisiert im Schritt 404 der Lastmanagerprozess Lastinformation, die von allen Inhaltsservern gewonnen wurde, die Last-Daemon-Prozesse haben. Dieses ermöglicht es dem Direktorprozess 362, die am geringsten belastete Inhaltsservermaschine auszuwählen, in Abhängigkeit von einer einlaufenden Anforderung, wie in den Schritten 410 und 412.
Im Schritt 410 wird eine einlaufende Clientenanforderung, die eine HTTP-Anforderung von beispielsweise einem Webbrowser sein kann oder eine FTP-Anforderung von einem FTP-Clienten, über einen wahlfreien äußeren Pfad zu einem System Grenzgateway geleitet, typischerweise ein Router an einem Netzzugangspunkt. An diesem Punkt wird die Clientenanforderung eine Eingabe in die Serverlast, die das verteilte Rechensystem der vorliegenden Erfindung vergleichmäßigt. Sie wird durch IP-Aktion einer Frontende-Komponente 360 in Übereinstimmung mit der Leitwegtabelle übermittelt, die einem an diesem Netzzugangspunkt gelegenen Router zugeordnet ist. Im Schritt 412 betätigt im Ansprechen auf den Empfang der Clientenanwendungsanforderung die Frontende-Komponente eine Anforderung an die Direktorkomponente 362 nach einem bevorzugten Server. Der Direktor, der die Frontende-Anforderung nach Information über Clientenanforderung im Schritt 412 empfangen hat, fordert Information, wie beispielsweise den zweckmäßigsten Pfad zwischen Servern und Clienten, von einer Kollektorkomponente an, beispielsweise einen Ping-Manager 364, in einem Schritt 413. In der Ausführungsform von 4A ist der zweckmäßigste Pfad jeder mit der schnellsten ICMP-Echoantwort (Ping), der durch eine Ping-Mangager-Kollektorkomponente 364 bestimmt wird, die zusammen mit einer oder mehreren Ping-Daemon-Komponenten wirkt, die zusammen an den zahlreichen Netzzugangspunkten im Systemnetz angeordnet sind, in einem Schritt 414. Diese Ping-Daemons bestimmen den schnellsten ICMP-Echopfad zwischen ihrem speziellen Frontende-Server und dem Clienten durch Übertragung aufeinanderfolgender Pings zum Clienten über den ihrem speziellen Frontende-Server zugeordneten Netzzugangspunkt und durch Zeitbestimmung der Antwort, wie in einem Schritt 415 gezeigt. Jeder Ping-Daemon überträgt von Zeit zu Zeit die Zeit zu einem Clienten über seinen speziellen Netzzugangspunkt zum Ping-Manager in einem Schritt 416. Die Ping-Manager-Komponente liefert Rückkehrwerte für den Netzzugangspunkten des Systems zugeordnete Pfade im Schritt 417 an den Clienten zurück. In speziellen Ausführungsformen kann die Ping-Manager-Komponente pro-aktive Statusanfragen (nicht dargestellt) auslösen oder kann Statusinformation zu jeder Zeit zurückgeben, ohne ausdrückliche Anforderungen von der Direktorkomponente. Die Direktorkomponente gibt den richtigen Inhaltsserver an, der für den Clienten zu benutzen ist, an die FrontendeKomponente in einem Schritt 418. Die Frontende-Komponente leitet den Clienten zum richtigen Inhaltsserver unter Verwendung eines Anwendungsebenenprotokolls, vorzugsweise einer HTTP-Leitantwort in einem Schritt 419. Die Frontende-Antwort wird über einen Netzzugangspunkt an die Clientenmaschine durch das Internetz geleitet, beispielsweise unter Verwendung des IP-Protokolls. Anschließend werden, wie im Schritt 420 gezeigt, Anforderungen vom Clienten nach dem besten Inhaltsserver, z. B. 232, über den besten Leitweg zu seiner Maschine gemacht. (Was auch der beste Platz ist, um in das externe Netz einzutreten, um den dem suchenden Clienten eigenen Netzprovider zu erhalten.)
4B zeigt einen Satz Schritte, die beim Prozess des Empfangens, Bewertens und Antwortens einer Clientenanforderung in einer alternativen Ausführungsform der Erfindung auftreten. Vergleicht man die Verarbeitungsschritte der in 4B gezeigten Ausführungsform mit jenen der Ausführungsform von 4A, wird klar, dass die besonderen Schritte identisch sind. Es ist jedoch anzumerken, dass die Schritt 412, 414, 416 und 418 keine Netztransaktionen sind, wie es in 4A der Fall war, sondern Transaktionen zwischen Prozessen, die gemeinsam innerhalb einer Servermaschine ablaufen.
4C zeigt einen Satz Schritte, die beim Prozess des Empfangens, Bewertens und Beantwortens einer Clientenanforderung in einer bevorzugten Ausführungsform der Erfindung auftreten. Vergleicht man die Verarbeitungsschritte der in 4B gezeigten Ausführungsform mit jenen der Ausführungsform von 4C, wird klar, dass der Hauptunterschied darin besteht, dass die Schritte 419 und 420 von 4B, die Weitersendeantwort und die nachfolgenden HTTP-Umwandlungschritte durch einen neuen Schritt 422 ersetzt worden sind. Wir im Schritt 422 wird der IP-Verkehr vom Clienten entsprechend der Bestimmung durch den Direktor zum "besten Server" weitergeleitet. Dieses nimmt den Platz des Weitersendeantwortschritt 419, der durch den Frontende-Prozess getan wird, zum Clienten ein, wie in 4B gezeigt. Es ist anzumerken, dass die Schritte 402, 402, 410, 412, 413, 414, 415, 416, 417 und 418 in der bevorzugten Ausführungsform von 4C die gleichen bleiben, wie bei den Ausführungsformen der 4A und 4B.
4C zeigt die Verarbeitungsschritte in der bevorzugten Ausführungsform. In einem Schritt 410 nimmt ein Frontende-Relais 360 in das Netz eintretende Pakete auf. Auf der Grundlage von Adressinformation, die im IP-Kopfteil enthalten ist, bestimmt das Frontende-Relais den ursprünglichen Zielserver des Pakets. Als nächstes ruft im Schritt 412 das Frontende-Relais den Direktor 362 auf, die Leitwegentscheidung zum "besten Server" zu treffen. In den Schritten 413, 414, 415, 416, 417 und 418 bestimmt der Direktor im Zusammenwirken mit dem Lastmanager 366, dem Ping-Mananger 364, den Last-Daemon- und Ping-Daemon-Komponenten einen "besten Server" für den IP-Verkehr und teilt diese Maschinenadresse dem Frontende/Relais mit. Der Entscheidungsprozess ist identisch mit jenem der Ausführungsformen der 4A und 4B. In einem Schritt 422 leitet das Frontende/Relais alle Pakete zur "besten" Servermaschine. Da die Paketweitergabe in der IP-Ebene stattfindet, können Pakete für jeden Service, der über die IP-Ebene läuft, durch die Verfahren der vorliegenden Erfindung geleitet werden.
4.0 Entscheidungsfindungsverfahren
4.1 Direktor
Der Direktor trifft Entscheidungen darüber, welcher Inhaltsserver und welcher Router der beste für jede Anforderung durch einen Clienten ist. 5A zeigt ein Flussdiagramm 500 der Prozessschritte, die von einem Direktor in einer speziellen Ausführungsform der Erfindung unternommen werden. In einem Schritt 501 wird ein Netzmaß für jede Kombination von "Inhaltsserver" und "Ausgehender Router" berechnet. Eine Sortierliste wird aus diesen Maßen konstruiert, mit dem Format:
(Platz 1 Grenze 1 Maß 1, ... Platz N Grenze N Maß N) (3)
In einem Schritt 502 werden die Serverkandidaten für die besten Plätze aus der im obigen Schritt 501 erzeugten Liste ausgewählt. Die Verarbeitung durchquert die Liste, wählt das Maß obersten Rangs sowie alle Kandidaten, die innerhalb eines gewissen Prozentsatzes (beispielsweise X%) des höchsten Maßes liegen. Merke, dass jeder Inhaltsserver mit allen Kombinationen ausgehender Router in der Liste aufgeführt ist. Da es nicht notwendig ist, Server-Router-Kombinationen in Betracht zu ziehen, die nicht sinnvoll sind, beispielsweise braucht der Server von LA, der durch die Grenze von NY geht, nicht betrachtet zu werden, wenn eine Kombination eines LA-Servers, der durch die LA-Grenze geht, vorhanden ist, muss nur die "beste" in Betracht gezogen werden. Beispielsweise mit X = 5 und der sortierten Liste von Kombinationen (Platz, Grenze, Maß) wie in Zeile (4) gezeigt:
@network = (ny ny 300 sj) la 305 sj sj 312 ny sj 380 dc ny 400 ...) (4)
Die ersten drei Eingaben sind:
ny ny 300
sj la 305
sj sj 312
Da diese alle innerhalb 5% von einander sind, zieht das System alle drei in Betracht. Es ist jedoch anzumerken, dass San Jose zweimal aufgeführt ist, und dass die Zeit der zweiten Listung länger ist, als die Zeit der ersten. Das erste Erscheinen des Servers von San Jose ist daher gegenüber dem zweiten bevorzugt, so dass das zweite zugunsten des ersten ausgeschieden wird. Es wird ein Server entweder in NY oder SJ gewählt. Wenn ein Server in NY gewählt wird, wird auch die Grenze in NY gewählt. Wenn ein Server in SJ gewählt wird, ist die Grenze in LA die "beste".
In einem Schritt 503 wird der "beste" Server aus den Kandidaten ausgewählt. Es wird eine Liste aller Maße für Kandidatenserver erstellt und ein statistischer Algorithmus angewendet, um den besten Server aus den Kandidaten auszuwählen. Das Ergebnis dieses Schritts ist der Platz für den ausgewählten Server und ein Identifizierer für den speziellen Server (es können mehrere Server an jedem Platz sein).
In einem Schritt 504 ruft vom Platz des oben gewählten Servers das System auf, welche Grenze für den im Schritt 502 bestimmten Platz zu verwenden ist. Aus dem Serveridentifizierer und der ausgehenden Grenze wird dann der richtige, voll geeignete Domainname, der die geeignete IP-Adresse für die interne Richtlinien-Leitwegbestimmung ermittelt.
4.2 Ping-Manager
Der Ping-Manager ruft konstant Ping-Information von einem oder mehreren Ping-Daemans ab. Der Ping-Manager sendet an den Direktor eine Folge von Werten, die für die Hin- und Zurück-Zeit zu und von jedem Clientenplatz repräsentativ sind. Nicht antwortende Clientenplätze werden durch einen beliebig langen Wert dargestellt, wenn ein Ping-Daemon nicht antwortet. In einer speziellen Ausführungsform sendet ein Ping-Manager an einen Direktor eine Folge, wie sie unten durch Zeilen (5) und (6) aufgetragen sind.
"client_address metric_site_1 metric_site2...metric_site_N\n" (5)
"128.9192.44 3009999999 280 450\n" (6)
In einer bevorzugten Ausführungsform werden die Platzmaße geordnet.
@incoming_metric_order = ('ny', 'la', 'dc', 'sj') (7)
5B zeigt ein Flussdiagramm 510 der Prozessschritte, die vom Direktor im Ansprechen auf dem Empfang der Informationsfolge nach den Zeilen (5) und (6) vom Ping-Manager ausgeführt werden. In einem Schritt 512 des Flussdiagramms 510 führt der Direktor die Verarbeitung der einlaufenden Information vom Ping-Manager aus, um die Information in einem verwendbaren Format zu speichern, wie durch den Pseudokode in Zeilen (8) unten aufgetragen ist.
Als nächstes ermittelt in einem Schritt 514 im Ansprechen auf eine von einem Frontende-Prozess empfangene Anforderung der Direktor Information über diese zu beantwortende Anforderung. Zeile (9) zeigt den Pseudokode für den Verarbeitungsschritt 514:
In einem Schritt 516 berechnet der Direktor Einwegmaße aus den Zweiwegmaßen, die vom Ping-Manager geliefert werden, entsprechend dem folgenden Pseudokode in Zeile (10):
Als nächstes berechnet im Schritt 518 der Direktor Pfadmaße für alle Platz- und Grenzkombinationen entsprechend dem folgenden Pseudokode in Zeilen (11)
Als nächstes sortiert in einem Schritt 520 der Direktor die Maße und baut eine geordnete Liste unter Verwendung des folgenden Pseudokode in Zeilen (12) auf:
An diesem Punkt enthält die Variable @sorted_list alle Information, die notwendig ist, um Paare von Plätzen und Kandidatenservern auszuwählen.
4.3 Lastmanager
Der Lastmanager sendet Mitteilungen an den Direktor etwa einmal alle zwei Sekunden, in dem in Zeile (13) gezeigten Format:
"server1 load1 server2 load2 ... server N load N"; (13)
5C zeigt ein Flussdiagramm 521 von Ziegelprozessschritten, die vom Direktor bei der Wahl eines "besten" Servers unter Verwendung der Information ausgeführt werden, die vom Lastmanager, aufgetragen in Zeile 13 oben, und vom Ping-Manager, aufgetragen in den Zeilen (5) und (6) oben ausgeführt werden.
Der Direktor hält mehrere innere Datenstrukturen aufrecht, einschließlich einer assoziativen Gruppe von Serverlasten, Paarlastwerte mit Serverindentifizierern:
$load_array{$serverID} = $load;
eine Liste von Servern an jedem Platz:
$servers {'la'} = www.la1.test.com www.la2.testcom;
$servers{'dc'} = www.dcl.test.com www.dc2.test.com";
eine Abbildung von Servern und Grenzen in einen richtigen Namen, der eine entsprechende Quellenadresse hat:
$server_map {"www.la1.test.com la"} = www.la1-la.test.com;
$server_map {"www.la1.test.com dc"} = www.la1-dc.test.com;
die oben erzeugte @sorted_list enthält Tripel aus Plätzen, Grenzen und Pfadmaßstäben. Aus diesen Datenstrukturen kann der Direktor einen optimalen Server unter Verwendung der in 5C gezeigten Schritte wählen. Ein Entscheidungsschritt betätigt, dass alle Eingaben in die @sorted_list nicht verarbeitet worden sind, und initialisiert die "best_metric"-Variable zum Maß des ersten Elements der @sorted_list. Diese Schritte sind im folgenden Pseudokode aufgetragen:
Wie in 5C gezeigt, führen ein Entscheidungsschritt 522, ein Prozessschritt 524, ein Entscheidungsschritt 526 und ein Prozessschritt 528 einen Schleifendurchgang zum Auswählen von Tripeln aus Platz, Grenze und Maß von der @sorted_list und ein Hinzufügen der Grenzinformation zu einer Platzgrenzliste und des Platzes zu einer Serverliste aus. Dieses ist ebenfalls im folgenden Pseudokode aufgetragen:
Sobald diese Schleife alle Glieder der @sorted_list verarbeitet hat, nimmt der Entscheidungschritt 522 den "ja"-Pfad, und die Verarbeitung wird mit einem Entscheidungsschritt 530 fortgesetzt, der zusammen mit den Prozessschritten 532 und 534 einen Scheifendurchgang zur Verarbeitung aller Server in der oben erzeugten Serverliste ausführt und die Last jedes Servers zu einer Serverlastliste hinzufügt und die Lasten aller Server in $total-Variablen zusammenfasst. Dieses ist auch im folgenden Pseudokode aufgetragen:
Sobald diese Schleife alle Glieder der @sorted_list verarbeitet hat, nimmt der Entscheidungsschritt 530 von 5C den ja"-Pfad, und die Verarbeitung wird mit einem Prozessschritt 536 fortgesetzt, der eine beliebige Zahl zwischen 1 und der Gesamtserverlast bestimmt. Als nächstes vollzieht sich die Verarbeitung in der Schleife, die von den Entscheidungsschritten 538 und 544 und den Verarbeitungsschritten 540, 542 und 546 gebildet wird. Diese Schleife wandert durch die Server @server_list, summiert deren Lasten bis dieses laufende Gesamtergebnis die beliebige Zahl überschreitet, die im Prozessschritt 536 gewählt wurde, oder bis das letzte Glied der @server_list verarbeitet worden ist. In jedem Falle ist es jener Server, der darauf geprüft wird, ob eine diese beiden Bedingungen erfüllt ist, der Server, der von dem Direktor als der "beste" Server ausgewählt wird. Dieses ist auch im folgenden Pseudokode aufgetragen:
Sobald der Direktor einen "besten" Server gewählt hat, wird die Verarbeitung fortgesetzt, wie im Schritt 504 von 5A beschrieben, und es gilt der folgende Pseudokode:
5.0 Zusammenfassung
Zusammenfassend kann man sehen, dass die vorliegende Erfindung ein intervernetztes System schafft, in dem Datenobjekte an Benutzer entsprechend dem kürzesten verfügbaren Netzpfad geliefert werden. Ein weiterer Vorteil der Lösungen gemäß der Erfindung besteht darin, dass diese Verfahren Toleranz gegenüber Fehlern haben, die in der Hardware enthalten sind. Außerdem wird die Zuverlässigkeit von System gemäß der Erfindung gegenüber bekannten Webservern vergrößert. Andere Ausführungsformen der vorliegenden Erfindung und ihre Einzelnen Komponenten liegen für den Fachmann aus dem Studium der detaillierten Beschreibung auf der Hand, in der Ausführungsformen der Erfindung durch Erläuterung der besten Art zur Ausführung der Erfindung beschrieben sind. Wie man erkennt, sind weitere und andere Ausführungsformen der Erfindung möglich und es sind viele Details von Modifikationen zahlreicher, auf der Hand liegender Beziehung möglich, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Dementsprechend sollen die Zeichnungen und die detaillierte Beschreibung als in ihrer Art beispielhaft und nicht einschränkend betrachtet werden. Es ist daher nicht beabsichtigt, dass die Erfindung eingeschränkt wir, mit Ausnahme wie in beigefügten Ansprüchen beschrieben.

Claims

System zum Leiten von Anforderungen nach Datenobjekten von mehreren Clienten über ein Netz (200) auf der Grundlage von Richtlinien Politik, die Netzbedingungen berücksichtigen, enthaltend: mehrere Router (222, 224, 226, 228); mehrere Inhaltsserver (232, 234, 236, 238) zum Abgeben der Datenobjekte, die von den Clienten angefordert werden; mehrere Frontende-Server (212, 214, 216, 218) zum Empfangen der Datenobjektanforderungen von den Clienten und zum Leiten der Datenobjektanforderungen an die Inhaltsserver (232, 234, 236, 238) über das Netz (200); einen Direktor (250) zum periodischen Überwachen der Netzbedingungen und zum Identifizieren von Kombinationen der Inhaltsserver (232, 234, 236, 238) und der Router (222, 224, 226, 228) als Kandidaten zum Bearbeiten spezieller Datenobjektanforderungen, wobei der Direktor (250) einige der Kandidaten auf der Grundlage der beobachteten Netzbedingungen auswählt und die Frontende-Server (212, 214, 216, 218) anweist, die speziellen Datenobjektanforderungen den Inhaltsservern der ausgewählten Kandidaten zuzuleiten; wobei die Netzbedingungen Information über eine Zeit zur Durchquerung eines Pfades über das Netz zu jedem der Inhaltsserver (232, 234, 236, 238) enthalten und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit einem Pfad haben, der in einer kürzesten Zeitdauer durchquert werden kann; wobei die Zeit zur Durchquerung des Pfades durch eine ICMP-Echoantwort bestimmt wird.
System nach Anspruch 1, bei dem der Direktor (250) eine Anfrage von den Frontende-Servern (212, 214, 216, 218) empfängt und die Anfrage mit einer Antwortweitersendung an die Inhaltsserver (232, 234, 236, 238) der ausgewählten Kandidaten beantwortet.
System nach Anspruch 1 oder 2, beim die Netzbedingungen Information über eine Last für jeden der Inhaltsserver (232, 234, 236, 238) enthalten und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit der geringsten Last haben.
System nach einem der Ansprüche 1 bis 3, bei dem die Weitersendungsantwort eine HTTP-Weitersendungsantwort ist.
System nach einem der Ansprüche 1 bis 4, bei dem die Last der Inhaltsserver (232, 234, 236, 238) durch die Anzahl offener TCP-Verbindungen für jeden der Inhaltsserver bestimmt wird und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit der geringsten Zahl offener TCP-Bedingungen haben.
System nach einem der Ansprüche 1 bis 5, bei dem die Last der Inhaltsserver (232, 234, 236, 238) durch den Umfang an verfügbarem freien RAM für jeden der Inhaltsserver bestimmt wird und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit dem größten Umfang an verfügbarem freiem RAM haben.
System nach einem der Ansprüche 1 bis 7, bei dem die Last der Inhaltsserver (232, 234, 236, 238) durch den Umfang an verfügbarem freiem SWAP für jeden der Inhaltsserver bestimmt wird und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit dem größten Umfang an verfügbarem freien SWAP haben.
System nach einem der Ansprüche 1 bis, bei dem die Last der Inhaltsserver (232, 234, 236, 238) durch den Umfang an CPU-Leerlaufzeit für jeden der Inhaltsserver bestimmt wird und der Direktor (250) die Kandidaten auswählt, die die Inhaltsserver mit dem größten Umfang an CPU-Leerlaufzeit haben.
Verfahren zum Leiten von Datenobjektanforderungen über ein Netz (200) von mehreren Clienten an mehrere Inhaltsserver (232, 234, 236, 268) über mehrere Router (222, 224, 226, 228) auf der Grundlage von Richtlinien, die Netzbedingungen berücksichtigen, umfassend die Schritte: periodisches Überwachen der Netzbedingungen; Identifizieren von Kombinationen aus den Inhaltsservern (232, 234, 236, 238) mit den Routern (222, 224, 226, 228) als Kandidaten zur Bedienung mit den Datenobjektanforderungen; Auswählen eines besten Kandidaten aus den Kandidaten für eine Datenobjektanforderungen auf der Grundlage der überwachten Netzbedingungen; Zuleitung der einen Datenobjektanforderung an den Inhaltsserver des ausgewählten besten Kandidaten über das Netz (200); wobei der Überwachungsschritt den Unterschritt enthält: Ermitteln einer Zeit zur Durchquerung eines Leitwegs zwischen jedem der Inhaltsserver und einem speziellen der Teilnehmer; und bei dem der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit einem Pfad hat, der in einer kürzesten Zeitdauer durchquert werden kann; wobei die Zeitdauer zur Durchquerung des Pfades durch eine ICM-Echoantwort bestimmt wird.
Verfahren nach Anspruch 9, bei dem der Leitungsschritt die Unterschritte enthält: Empfangen einer Anfrage bezüglich des Inhaltsservers des besten Kandidaten, und Beantworten der Anfrage mit einer Antwortweitersendung zum Inhaltsserver des besten Kandidaten, der im Auswählschritt gewählt wurde.
Verfahren nach Anspruch 9 oder 10, bei der Überwachungsschritt den Unterschritt enthält: Ermitteln einer Last eines jeden der Inhaltsserver; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit der geringsten Last hat.
Verfahren nach einem Ansprüche 9 bis 11, bei dem Weitersendungsantwort eine HTTP-Weitersendungsantwort ist.
Verfahren nach einem der Ansprüche 9 bis 12, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln der Anzahl offener TCP-Verbindungen für jeden der Inhaltsserver; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit der geringsten Zahl offener TCP-Verbindungen hat.
Verfahren nach einem der Ansprüche 9 bis 13, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an verfügbarem, freien RAM für jeden der Inhaltsserver; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit dem größten Umfang an verfügbarem, freiem RAM hat.
Verfahren nach einem der Ansprüche 9 bis 14, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an verfügbarem, freiem SWAP für jeden der Inhaltsserver; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit einem größten Umfang an verfügbarem, freiem SWAP hat.
Verfahren nach einem der Ansprüche 9 bis 15, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an CPU-Leerlaufzeit für jeden der Inhaltsserver; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit einem höchsten Umfang an CPU-Leerlaufzeit.
Verfahren zum Zuleiten von Information von mehreren Clienten aus einer Vielzahl Clienten unter einer Vielzahl Server (232, 234, 236, 238) über mehrere Router (222, 224, 226, 228) auf der Grundlage von Richtlinien, die eine Antwortzeit in einer Paketnetzumgebung berücksichtigen, umfassend die Schritte: Überwachen der Netzantwortzeit; Identifizieren von Kombinationen aus den Servern (2323, 234, 236, 238) und den Routern (222, 224, 226, 228) als Kandidaten für das Empfangen der Information; Auswählen eines besten Kandidaten aus den Kandidaten auf der Grundlage der überwachten Netzantwortzeit; Weiterleiten der Information von einem speziellen Clienten in der Vielzahl Clienten zu dem Server des besten Kandidaten, wobei der Überwachungsschritt den Unterschritt enthält: Ermitteln einer Zeit zur Durchquerung eines Leitwegs zwischen jedem der Server und einem speziellen der Clienten; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Server mit einem Pfad hat, der in einer kürzesten Zeitdauer durchquert werden kann; wobei die Zeitdauer zur Durchquerung des Pfades durch eine ICMP-Echoantwort bestimmt wird.
Verfahren nach Anspruch 17, bei dem der Weiterleitungsschritt den Unterschritt enthält: Übermitteln der Information zu dem Server des besten Kandidaten unter Verwendung von Netzebenenprotokollen.
Verfahren nach Anspruch 17 oder 18, bei der Überwachungsschrit den Unterschritt enthält: Ermitteln einer Last von jedem der Server; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Server mit der geringsten Last hat.
Verfahren nach einem der Ansprüche 17 bis 19, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln der Anzahl offener TCP-Verbindungen für jeden der Server; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Server mit der geringsten Zahl offener TCP-Verbindungen hat.
Verfahren nach einem der Ansprüche 17 bis 20, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an verfügbarem, freiem RAM für jeden der Server; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Server mit dem größten Umfang an verfügbarem, freiem RAM hat.
Verfahren nach einem der Ansprüche 17 bis 21, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an verfügbarem, freiem SWAP für jeden der Server; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Inhaltsserver mit einem größten Umfang an verfügbarem, freiem SWAP hat.
Verfahren nach einem der Ansprüche 17 bis 22, bei dem der Überwachungsschritt den Unterschritt enthält: Ermitteln eines Umfangs an CPU-Leerlaufzeit für jeden der Server; und wobei der Auswählschritt den Unterschritt enthält: Auswählen des besten Kandidaten, der den Server mit einem höchsten Umfang an CPU-Leerlaufzeit hat.