DE60101841T2

DE60101841T2 - Verfahren und vorrichtung zum verteilen der last in einer rechnerumgebung

Info

Publication number: DE60101841T2
Application number: DE60101841T
Authority: DE
Inventors: J. Robert BLOCK; G. James HANKO; Kent J. PEACOCK
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-02-25
Filing date: 2001-02-23
Publication date: 2004-11-11
Anticipated expiration: 2021-02-24
Also published as: WO2001063403A2; US6658473B1; AU2001241686A1; WO2001063403A3; EP1257910A2; DE60101841D1; EP1257910B1

Description

GEBIET DER ERFINDUNG
Diese Erfindung bezieht sich auf den Bereich von vernetzten Computersystemen in einer Mehrfach-Server-Umgebung.
2. HINTERGRUND DER ERFINDUNG
Computerbenutzer wünschen sich fortgesetzt leistungsstärkere Verarbeitungsvorgänge in sich ständig ändernden Computerumgebungen. Das Verarbeitungsparadigma verschiebt sich. Neue Architekturen kommen auf, die neue Lösungen erfordern, um den Bedarf an hochleistungsfähigen Verarbeitungsvorgängen zu bewältigen. Eine solche Architektur ist diejenige des Thin-Client-Verarbeitungssystems. In dieser Architektur wird die Funktionalität des Endbenutzer-Computers bis zu dem Punkt reduziert, daß überwiegend nurmehr die Fähigkeiten zur Eingabe- und Ausgabe vorhanden sind. Die Endbenutzer-Einrichtung ist über ein Computernetzwerk mit hoher Bandbreite mit einem leistungsfähigeren Server-Computer verbunden, der alle Funktionen durchführt, die traditionell dem Personal-Computer zugeordnet waren, wie das Ausführen von Computerprogrammen und das Verarbeiten von Daten.
In dieser Art von Architektur kann eine große Anzahl von Endbenutzern mit einer begrenzten Anzahl von Servern verbunden sein. Darüber hinaus ist die begrenzte Anzahl von Servern untereinander verbunden, wobei sie etwas bilden, das mit Mehrfachserver-Umgebung bezeichnet wird, worin jedes der Endbenutzer-Terminals möglicherweise mit jedem beliebigen von den Servern verbunden sein könnte. In Mehrfachserver-Umgebungen ist es üblich, daß die Umgebung heterogen ist, wobei jeder Server über unterschiedliche Ressourcen-Fähigkeiten verfügt. In solchen komplexen Mehrfachserver-Umgebungen ist die Last auf den Ressourcen der Server oft unausgewogen, was bedeutet, daß zum Beispiel ein Server im Wesentlichen bei der maximalen Kapazität arbeitet, während ein anderer Server relativ unbenutzt ist. Diese Unausgeglichenheit der Last zu überwinden, wird daher ro einem extrem wichtiges Anliegen, wenn Hochleistungs-Verarbeitungserlebnisse zur Verfügung gestellt werden sollen.
Die Entwicklung, die zu diesem Problem geführt hat, versteht man besser, wenn man die Entwicklung der Verarbeitung im Netzwerk bzw. Netzwerk-EDV betrachtet. Das Wachsen des Internet hat zur vorgeschlagenen Verwendung sogenannter "Netzwerk-Computer" geführt. Ein Netzwerk-Computer ist eine abgespeckte Version eines Personal-Computers mit weniger Speicherplatz, weniger Hauptspeicher und häufig weniger Verarbeitungsleistung. Die Idee ist, daß Netzwerk-Computer über ein Computernetzwerk wie das Internet, ein Intranet, ein lokales Netzwerk oder ein Weitver kehrsnetzwerk auf Daten und Anwendungen zugreifen. Nur diejenigen Anwendungen, die für eine bestimmte Aufgabe benötigt werden, werden dem Netzwerk-Computer zur Verfügung gestellt. Wenn die Anwendungen nicht mehr benötigt werden, werden sie nicht auf dem Netzwerk-Computer gespeichert.
In jüngster Zeit ist eine neue Computersystemarchitektur entstanden, die als die virtuelle Desktop-Architektur bezeichnet wird. Dieses System sieht eine Neuaufteilung der Funktionalität zwischen einer zentralen Serveranlage und der Benutzerhardware vor. Daten- und Berechnungsfunktionalität werden von Datenquellen über eine zentralisierte Verarbeitungsanordnung zur Verfügung gestellt. Auf Seiten des Benutzers wird die gesamte Funktionalität im Wesentlichen entfernt mit Ausnahme derjenigen, die eine Ausgabe an den Benutzer erzeugt (z. B. Anzeige und Lautsprecher), eine Eingabe vom Benutzer entgegennimmt (z. B. Maus und Tastatur), oder anderer Peripheriegeräte, mit denen der Benutzer interagieren kann (z. B. Scanner, Kameras, entfernbarer Speicher, etc.).
Die gesamte Verarbeitung wird von einem oder mehreren zusammengeführten Client-Servern vorgenommen, die als zentrale Datenquellen fungieren, und die Berechnung wird unabhängig von dem Ziel bzw. der Bestimmung der erzeugten Daten vorgenommen. Die Ausgabe einer Datenquelle wird an ein Terminal übergeben, das hier als eine "Desktop-Einheit" (Desktop Unit, DTU) bezeichnet wird. Die DTU ist in der Lage, die Daten zu empfangen und die Anzeigedaten anzuzeigen, die von den auf den zusammengeführten Client-Servern ausgeführten Programmen erzeugt werden.
Die virtuelle Desktop-Systemarchitektur kann in Analogie zu anderen in hohem Maße aufgeteilten Systemen gesehen werden. Zum Beispiel hält eine öffentliche Telefongesellschaft leistungsfähige und hoch entwickelte Verarbeitungsleistung und große Datenbanken in Vermittlungsstellen vor. Jedoch ist die DTU (z. B. der Telefonhörer) relativ einfach und erfordert keine Aktualisierung bzw. Aufrüstung, wenn neue Eigenschaften oder Dienste durch die Telefongesellschaft hinzugefügt werden. Das Telefon selbst wird zu einer Einrichtung bzw. einem Gerät mit niedrigen Kosten und das extrem wenig veraltet. In ähnlicher Weise veraltet der Anzeigebildschirm der meisten Computersysteme kaum und kann typischerweise über die meisten Aktualisierungen bzw. Aufrüstungen von Desktop-Systemen hinweg beibehalten werden.
Die Bereitstellung von Diensten in der virtuellen Desktop-Serverarchitektur dreht sich um eine Abstraktion, die hier als eine "Sitzung" bzw. "Sitzung" bezeichnet wird. Eine Sitzung ist eine Repräsentation derjenigen Dienste, die im Namen des Benutzers zu irgendeinem Zeitpunkt ausgeführt werden. Die Sitzungenabstraktion wird durch Einrichtungen aufrecht erhalten, die als die Authentisierungs- und Sitzungsmanager bekannt sind, deren Aufgabe es ist, die Datenbankabbildungen zwischen Tokens (d. h. eindeutigen Bezeichnern bzw. Kennungen, die an Smartcards oder andere Mechanismen zur Authentisierung gebunden sind) und Sitzungen aufrecht zu erhalten und die Dienste, die jede Sitzung ausmachen, zu verwalten. Für jeden Benutzer, dessen das System gewahr ist, kann es eine oder mehrere Sitzungen geben. Der Sitzungsmanager bietet dem Benutzer einen Dienst, der es ermöglicht, daß Sitzungen konfiguriert und neue Sitzungen gestartet bzw. erzeugt werden.
In einer Mehrfach-Server-Umgebung können viele Sitzungen auf jedem Server ablaufen. Diese Sitzungen werden von mehreren Benutzern eingeleitet, die auf die DTUs zugreifen. Wenn einer von diesen Servern ausfällt (z. B. durch Stromausfall), wird jede von den mit ihm verbundenen DTUs auf einen der überlebenden Server "umgehängt". Das die Rechner- und Speicherressourcen, die den von den DTUs angeforderten Diensten zugeordnet sind, über eine Gruppe von Servern verteilt sind, ist es möglich, daß Ressourcen ungleichmäßig zugeordnet werden, wodurch die Leistungskapazität auf übermäßig genutzten Servern nachlässt, während Ressourcen auf zuwenig genutzten Servern vergeudet werden. Dies gilt besonders in heterogenen Server-Konfigurationen, bei denen die Aufnahmekapazität der Server (d. h. zum Beispiel Anzahl und Geschwindigkeit von Verarbeitungseinheiten, Menge von installiertem Speicher und verfügbare Netzwerkbandbreite) nicht gleichmäßig (verteilt) ist. Darüber hinaus kann jede Sitzung unterschiedliche Mengen von Ressourcen anfordern, was zur Ungleichmäßigkeit der zugeordneten Ressourcen beiträgt.
Darüber hinaus verkompliziert die Gegenwart bzw. das Auftreten von Fehlern bzw. Ausfällen das Lastverteilungsproblem, weil alle DTUs versuchen werden, innerhalb einer kurzen Zeitspanne umzuschalten, wenn ein Server, der eine große Anzahl von DTUs beherbergt, ausfällt. Es ist in dieser Situation entscheidend, die verbleibenden Server nicht aus dem Gleichgewicht zu bringen, indem im Fehlerfall umgeschaltete Sitzungen zu einem einzigen Server oder einem bereits überlasteten Senner umgeschaltet werden. Natürlich wird eine intelligentere Lastausgleichsstrategie benötigt, um in dieser komplexen Mehrfach-Server-Umgebung eine optimale Ressourcenzuordnung zu erhalten.
WO 99/18534 offenbart ein System zum Ausgleich von Lasten unter einer Gruppe von Netzwerk-Servern. Das System empfängt an einem ersten Netzwerk-Server eine Anforderung von einer entfernten Quelle und stellt fest, ob die Anforderung in dem ersten Netzwerk-Server zu bearbeiten ist oder ob sie an einen zweiten Netzwerk-Server zu leiten ist, um dort bearbeitet zu werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung zur Lastverteilung in einer Mehrfach-Server-Computerumgebung zur Verfügung. Nach einer Ausführungsform ermittelt ein Gruppenmanagerprozeß auf jedem Server periodisch die Kapazität und die Last (d. h. die Nutzung) des Servers bezüglich der verschiedenen Ressourcen. Die Kapazitäts- und Lastinformation wird an die anderen Server in der Gruppe rundgesendet, so daß jeder Server eine globale Übersicht über die Kapazität und die aktuelle Last jedes Servers hat.
Wenn ein Benutzer versucht, auf eine DTU zuzugreifen, setzt der Benutzer eine Kennung in die DTU ein, die ein eindeutiges Token enthält. Diese Kennung ist in einer Ausführungsform eine Smartcard. Sobald die Kennung eingesetzt ist, verwendet die DTU das Token, um zu versuchen, die Kommunikation mit den Servern zum Start oder zur Wiederaufnahme einer oder mehrerer Sitzungen aufzubauen. Wenn eine gegebene DTU erfolgreich eine gegebene Sitzung startet oder wieder auf nimmt, stellt der Gruppenmanagerprozeß auf diesem Senner zuerst fest, ob einer der Server in der Gruppe bereits die Sitzung für dieses Token beherbergt. Wenn dies der Fall ist, leitet eine Ausführungsform die DTU zu diesem Server um und die Lastausgleichsstrategie wird nicht eingesetzt. Ansonsten werden für jede Ressource und jeden Server die passenden Lastausgleichsstrategien durchgeführt, um festzustellen, welcher Server am besten in der Lage ist, diese bestimmte Sitzung zu behandeln.
Die Lastausgleichsstrategien sind dafür ausgelegt, einen oder mehrere Faktoren in Betracht zu ziehen, wie die Anzahl und die Geschwindigkeit der Mikroprozessoren in einem gegebenen Server, die Menge von wahlfrei zugreifbarem Speicher (Random Access Memory, "RAM") in einem gegebenen Server, der Betrag an Netzwerkbandbreite, die dem gegebenen Server zur Verfügung steht, die Anzahl von Sitzungen, die auf einem gegebenen Server im vergleich zu der Aufnahmekapazität dieses Servers ablaufen (z. B. die maximale Anzahl von Sitzungen, die dieser Server beherbergen kann), die Zustände der auf einem Server ablaufenden Sitzungen (z. B. aktiv oder inaktiv) und die erwarteten Nutzungsgewohnheiten gewisser Benutzer. Die Lastausgleichsstrategie stellt die relative Erwünschtheit der Zuweisung einer neuen Sitzung zu diesem Server fest und weist die Sitzung dem am meisten wünschenswerten Server zu.
Sitzungen werden Servern in einer pseudo-zufälligen Art und Weise zugewiesen, wobei die relative Wahrscheinlichkeit der Auswahl eines Servers mit seiner relativen Erwünschtheit gewichtet wird. Ein pseudo-zufällige Auswahl wird in erster Linie in Störfallsituationen verwendet, bei denen viele Sitzungen gleichzeitig authentisiert werden. Nach einer anderen Ausführungsform wird eine hybride Strategie verwendet, die die Verwendung der Strategie der relativen Erwünschtheit und die Verwendung der pseudo-zufälligen Strategie in Abhängigkeit von dem Zustand des Servers zu diesem Zeitpunkt kombiniert. Somit führen die Lastausgleichsstrategien zu einem leistungsfähigeren Computererlebnis für den Endbenutzer.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 stellt die virtuelle Desktop-Systemarchitektur der vorliegenden Erfindung dar.
2 ist ein Blockdiagramm eines Beispiel-Computersystems, das mit der vorliegenden Erfindung verwendet werden kann.
3 ist ein Blockdiagramm einer Ausführungsform einer DTU der vorliegenden Erfindung.
4 stellt eine Einzelchip-DTU-Ausführungsform der vorliegenden Erfindung dar.
5 stellt ein Beispiel einer Sitzungenverwaltung und -authentisierung in der vorliegenden Erfindung dar.
6 stellt die virtuelle Desktop-Systemarchitektur dar, die den Gruppenmanagerprozeß gemäß der vorliegenden Erfindung implementiert.
7 ist ein Diagramm, das ein Beispiel einer Serverumleitung gemäß der vorliegenden Erfindung veranschaulicht.
8a ist ein Kontrollflußdiagramm der Serverumleitung gemäß der vorliegenden Erfindung.
8b ist ein Nachrichtenflußdiagramm der Serverumleitung gemäß der vorliegenden Erfindung.
9 ist ein Kontrollflußdiagramm der Lastausgleichsstrategie im stationären Zustand.
10a und 10b sind Kontrollflußdiagramme der Lastausgleichsstrategie im nichtstationären Zustand.
11 ist ein Steuerungsflußdiagramm der hybriden Strategie.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
In der folgenden Beschreibung werden zahlreiche besondere Details dargelegt, um eine genauere Beschreibung von Ausführungsformen der Erfindung bereitzustellen. Es ist jedoch für Fachleute auf diesem Gebiet offenkundig, daß die Erfindung auch ohne diese besonderen Details in die Praxis umgesetzt werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht im Detail beschrieben, um die Erfindung nicht zu verschleiern.
Eine oder mehrere Ausführungsformen der Erfindung können die Mechanismen zur verbesserten Ressourcennutzung implementieren, die in EP-A-1257909 mit dem Titel "Method and Apparatus for Improving Utilization of a Resource on a Shared Client" beschrieben und auf den Inhaber des vorliegenden Patentes übertragen worden ist.
Eine oder mehrere Ausführungsformen der Erfindung können auch die Mechanismen implementieren, um einen Rechen- bzw. Verarbeitungsdienst hochverfügbar zu machen, der in EP-A-1258127 mit dem Titel "Method and Apparatus for Making a Computational Service Highly Available" beschrieben und auf den Inhaber des vorliegenden Patentes übertragen worden ist.
Die vorliegende Erfindung sieht ein Verfahren und eine Vorrichtung zur Lastverteilung in einer Rechnerumgebung mit mehreren Servern vor, indem ein Gruppenmanagerprozeß auf jedem Server implementiert wird, der periodisch die Kapazität und die Last (d. h. die Nutzung) des Servers bezüglich mehrerer Ressourcen ermittelt. Die Kapazitäts- und Lastinformation wird an die anderen Server in der Gruppe rundgesendet, so daß jeder Server eine globale Übersicht über die Kapazität und die aktuelle Last jedes Servers hat.
Wenn ein Benutzer versucht, auf eine DTU zuzugreifen, setzt der Benutzer eine eindeutigen Identifizierer bzw. eine Kennung in die DTU ein. Dieser Identifizieren kann eine Smartcard, ein biometrischer Mechanismus oder ein anderer Mechanismus sein, der die Identifikation eines Benutzers ermöglicht. Sobald der Identifizierer eingesetzt ist, versucht die DTU die Kommunikation mit den Servern zum Start oder zur Wiederaufnahme einer oder mehrerer Sitzungen aufzubauen. Wenn eine gegebene DTU erfolgreich eine Sitzung startet oder wieder aufnimmt, stellt der Gruppenmanagerprozeß auf diesem Server zuerst fest, ob einer der Server in der Gruppe bereits die Sitzung für diesen Benutzer beherbergt. Wenn dies der Fall ist, leitet eine Ausführungsform die DTU zu diesem Server um und die Lastausgleichsstrategie wird nicht eingesetzt. Ansonsten werden für jede Ressource und jeden Server die passenden Lastausgleichsstrategien durchgeführt, um zu festzustellen, welcher Server am besten in der Lage ist, diese bestimmte Sitzung zu behandeln.
Virtuelle Desktop-Systemarchitektur
Nach einer Ausführungsform wird die vorliegende Erfindung in der Computer-Systemarchitektur implementiert, die als die virtuelle Desktop-Systemarchitektur bezeichnet wird. Dieser Gegenstand wird in der gleichzeitig anhängigen U.S. Patentanmeldung 09/063.335 beschrieben, die am 20. April 1998 eingereicht wurde, mit dem Titel "Method and Apparatus for Providing a Virtual Desktop System Architecture" und die dem Inhaber des vorliegenden Patents übertragen wurde.
Die virtuelle Desktop-Systemarchitektur sorgt für eine Neuaufteilung der Funktionalität zwischen einer zentralen Serveranlage und der Benutzerhardware. Daten- und Berechnungsfunktionalität werden von Servern mittels einer zentralisierten Verarbeitungsanordnung zur Verfügung gestellt. Auf Seiten des Benutzers wird die gesamte Funktionalität entfernt mit Ausnahme derjenigen, die eine Ausgabe an den Benutzer erzeugt (z. B. Anzeige und Lautsprecher), eine Eingabe vom Benutzer entgegennimmt (z. B. Maus und Tastatur), oder anderer Peripheriegeräte, mit denen der Benutzer interagieren kann (z. B. Scanner, Kameras, entfernbarer Speicher, etc.).
Die gesamte Verarbeitung wird von dem zentralen Servern vorgenommen, und die Berechnung wird unabhängig von dem Ziel bzw. dem Bestimmungsort der erzeugten Daten vorgenommen. Die Ausgabe des Servers wird an eine DTU übergeben. Die DTU ist in der Lage, die Daten zu empfangen und die Daten anzuzeigen. Die Funktionalität des Systems ist zwischen einer Anzeige- und Eingabeeinrichtung und Servern aufgeteilt. Die Anzeige- und Eingabeeinrichtung ist die DTU. Die Aufteilung dieses Systems ist so, daß Zustands- und Berechnungsfunktionen aus der DTU entfernt wurden und sich in den Servern befinden. Nach euer Ausführungsform der Erfindung kommunizieren ein oder mehrere Server mit einer oder mehreren DTUs über eine Zwischenverbindungsstruktur wie ein Netzwerk.
Ein Beispiel eines solchen Systems ist in 1 dargestellt. In 1 besteht das System aus Servern 100, die Daten durch die Zwischenverbindungsstruktur 101 an DTUs 102 kommunizieren. Es sollte jedoch beachtet werden, daß die Ressourcennutzungsstrategien nicht auf die virtuelle Desktop-Systemarchitektur beschränkt ist. Ausführungsformen der vorliegenden Erfindung werden in Verbindung mit einem Allzweckcomputer, wie dem in 2 beschriebenen, implementiert.
Ausführungsform der Allzweckcomputer-Umgebung
Eine Ausführungsform der Erfindung kann als Computersoftware in der Form von computerlesbarem Programmcode implementiert werden, der auf einem Allzweckcomputer wie dem in 2 abgebildeten Computer 200 ausgeführt wird. Eine Tastatur 210 und eine Maus 211 sind mit einem bidirektionalen Systembus 218 verbunden. Die Tastatur und die Maus sind zum Einbringen von Benutzereingaben in das Computersystem und zum Kommunizieren dieser Benutzereingaben an die zentrale Verarbeitungseinheit (Central Processing Unit, CPU) 213. Andere geeignete Eingabeeinrichtungen können zusätzlich zu oder an Stelle der Maus 211 und der Tastatur 210 verwendet wer den. Die I/O (Input/output, Eingabe/Ausgabe) Einheit 219, die an den bidirektionalen Systembus 218 angeschlossen ist, stellt solche I/O-Elemente wie einen Drucker, A/V (Audio/Video) I/O, etc. dar.
Der Computer 200 beinhaltet einen Videospeicher 214, einen Hauptspeicher 215 und einen Massenspeicher 212, die alle an den bidirektionalen Systembus 218 zusammen mit der Tastatur 210, der Maus 211 und der CPU 213 angeschlossen sind. Der Massenspeicher 212 kann sowohl feste als auch auswechselbare Medien wie magnetische, optische oder magneto-optische Speichersysteme oder jede andere verfügbare Massenspeichertechnologie enthalten. Der Bus 218 kann zum Beispiel zweiunddreißig Adreßleitungen zum Adressieren des Videospeichers 214 oder des Hauptspeichers 215 beinhalten. Der Systembus 218 enthält zum Beispiel auch einen 32-Bit-Datenbus zum Übertragen von Daten zwischen und unter den Komponenten wie der CPU 213, dem Hauptspeicher 215, dem Videospeicher 214 und dem Massenspeicher 212. Alternativ können statt separater Daten- und Adreßleitungen Multiplex-Daten/Adreßleitungen verwendet werden.
Nach einer Ausführungsform der Erfindung ist die CPU 213 ein von Motorola hergestellter Mikroprozessor wie der 680X0-Prozessor oder ein von Intel hergestellter Mikroprozessor wie der 80X86- oder Pentium-Prozessor oder ein SPARC-Mikroprozessor von Sun Microsystems. Jedoch kann jeder geeignete Mikroprozessor oder Mikrocomputer eingesetzt werden. Der Hauptspeicher 215 besteht aus dynamischem, wahlfrei zugreifbarem Speicher (Dynamic Random Access Memory, DRAM). Der Videospeicher 214 ist ein zweiseitig zugänglicher, wahlfrei zugreifbarer Videospeicher (Dual-Ported Video Random Access Memory). Ein Zugang des Videospeichers 214 ist an den Videoverstärker 216 angeschlossen. Der Videoverstärker 216 wird verwendet, um den Kathodenstrahlröhren-(Cathode Ray Tube, CRT)-Rastermonitor 217 zu betreiben. Der Videoverstärker 216 ist nach dem Stand der Technik wohlbekannt und kann durch jede geeignete Vorrichtung implementiert werden. Diese Schaltung wandelt Pixeldaten, die in dem Videospeicher 214 gespeichert sind, in Rastersignale um, die zur Verwendung durch den Monitor 217 geeignet sind. Der Monitor 217 ist eine Art von Monitor, die zur Anzeige von grafischen Bildern geeignet ist.
Der Computer 200 kann auch eine Kommunikationsschnittstelle 220 beinhalten, die an den Bus 218 angeschlossen ist. Die Kommunikationsschnittstelle 220 sorgt für eine Zweiwege-Datenkommunikationskopplung mittels einer Netzwerkverbindung 221 an ein lokales Netzwerk 222. Wenn zum Beispiel die Kommunikationsschnittstelle 220 eine ISDN-(Integrated Services Digital Network, Dienste-integrierendes, digitales Netzwerk)-Karte oder ein Modem ist, stellt die Kommunikationsschnittstelle 220 eine Datenkommunikationsverbindung zu der entsprechenden Art von Telefonleitung bereit, die einen Teil der Netzwerkverbindung 221 umfaßt. Wenn die Kommunikationsschnittstelle 220 eine LAN-(Local Area Network, lokales Netzwerk)-Karte ist, stellt die Kommunikationsschnittstelle 220 eine Datenkommunikationsverbindung über die Netzwerkverbindung 221 zu einem kompatiblen LAN bereit. Drahtlose Verbindungen sind ebenso möglich. In jeder solchen Implementierung sendet und empfängt die Kommunikationsschnittstelle 220 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme befördern, welche verschiedene Arten von Information darstellen.
Die Netzwerkverbindung 221 stellt typischerweise Datenkommunikation durch ein oder mehrere Netzwerke hindurch zu anderen Dateneinrichtungen bereit. Zum Beispiel kann die Netzwerkverbindung 221 eine Verbindung durch das lokale Netzwerk 222 zu dem Hostcomputer 223 oder zu einer Datenanlage, die von einem Internet-Dienstanbieter (Internet Service Provider, ISP) 224 betrieben wird, zur Verfügung stellen. Der ISP 224 seinerseits stellt Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetzwerk bereit, das heutzutage gemeinhin als das "Internet" 225 bezeichnet wird. Das lokale Netzwerk 222 und das Internet 225 verwenden beide elektrische, elektromagnetische oder optische Signale, die digitale Datenströme befördern. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbindung 221 und durch die Kommunikationsschnittstelle 220, die digitale Daten zu und von dem Computer 200 befördern, sind beispielhafte Formen von Trägerwellen, die Information transportieren.
Der Computer 200 kann durch das Netzwerk bzw. die Netzwerke, die Netzwerkverbindung 221 und die Kommunikationsschnittstelle 220 Nachrichten senden und Daten empfangen, einschließlich Programmcode. In dem Internetbeispiel könnte der Server 226 einen angeforderten Code für ein Anwendungsprogramm durch das Internet 225, den ISP 224, das lokale Netzwerk 222 und die Kommunikationsschnittstelle 220 übertragen. Im Einklang mit der Erfindung ist das Verwenden von und der Zugriff auf Information aus Zeichensätzen in verschiedenen Formaten eine solche heruntergeladene Anwendung, wie sie hier beschrieben wird.
Der empfangene Code kann von der CPU 213 ausgeführt werden, sowie er empfangen wird, und/oder in dem Massenspeicher 212 oder anderem nicht-flüchtigen Speicher zur späteren Ausführung gespeichert werden. Auf diese Weise kann der Computer 200 Anwendungscode in der Form einer Trägerwelle erhalten.
Die oben beschriebenen Computersysteme dienen nur als Beispiele. Eine Ausführungsform der Erfindung kann in jeder Art von Computersystem oder Programmier- oder Verarbeitungsumgebung implementiert werden.
Rechendienstanbieter
Unter Hinweis auf die virtuelle Desktop-Systemarchitektur finden sich Rechenleistung und Zustandspflege bzw. -fortschreibung in den Dienstanbietern oder Diensten. Die Dienste sind nicht an einen spezifischen Computer gebunden, sondern können über ein oder mehrere traditionelle Desktop-Systeme, wie in Verbindung mit 2 beschrieben, oder mit traditionellen Servern verteilt werden. Ein Computer kann über einen oder mehrere Dienste verfügen, oder ein Dienst kann durch einen oder mehrere Computer implementiert werden. Der Dienst stellt für die DTUs Berechnung, Status und Daten bereit und der Dienst steht unter der Kontrolle bzw. Steuerung einer gemeinsamen Befehlsgewalt oder eines gemeinsamen Managers. In 1 befinden sich die Dienste auf den Computern 110, 111, 112, 113 und 114. Es ist wichtig zu beachten, daß die zentrale Datenquelle auch Daten bereitstellen kann, die von außerhalb der zentralen Datenquelle 129 kommen, wie zum Beispiel das Internet oder das World Wide Web 130. Die Datenquelle könnte ebenso Rundfunkein heiten sein wie jene, die Daten wie Fernseh- oder Radiosignale 131 rundsenden. Ein Dienst ist hier ein Prozeß, der Ausgabedaten bereitstellt und auf Benutzeranforderungen und -eingaben antwortet.
Es liegt in der Verantwortung des Dienstes, die Kommunikation mit der DTU zu handhaben, die aktuell verwendet wird, um auf den gegebenen Dienst zuzugreifen. Dies bringt es mit sich, die Ausgabe von dem Rechendienst entgegenzunehmen und sie in ein Standardprotokoll für die DTU umzuwandeln. Diese Datenprotokollumwandlung wird nach einer Ausführungsform der Erfindung von einer Middleware-Schicht behandelt, wie dem X11-Server, der Microsoft-Windows-Schnittstelle, einem Videoformat-Codeumsetzer bzw. -Transcoder, der OpenGL-Schnittstelle oder einer Variante der java.awt.graphics-Klasse innerhalb der Maschine, die den Dienst erzeugt, obwohl auch andere Ausführungsformen im Schutzbereich der Erfindung liegen. Die Dienstmaschine behandelt die Übersetzung in das und aus dem virtuellen Desktop-Architektur-Leitungsprotokoll (Virtual Desktop Architecture Wire Protocol).
Die diensterzeugenden Computersysteme sind durch die Zwischenverbindungsstruktur direkt mit den DTUs verbunden. Es ist ebenso möglich, daß der Diensterzeuger ein Proxy für eine andere Einrichtung ist, die den Berechnungsdienst bereitstellt, wie ein Datenbankcomputer in einer Drei-Stufen-Architektur (Three Tiered Architecture), wobei der Proxy-Computer nur Anfragen erzeugen und Benutzerschnittstellencode ausführen könnte.
Zwischenverbindungsstruktur
Die Zwischenverbindungsstruktur ist irgendeiner von mehreren geeigneten Kommunikationspfaden zum Übertragen von Daten zwischen den Diensten und den DTUs. Nach einer Ausführungsform ist die Zwischenverbindungsstruktur ein lokales Netzwerk, das als ein Ethernet-Netzwerk implementiert ist. Jedes andere lokale Netzwerk kann ebenso eingesetzt werden. Die Erfindung betrachtet auch die Verwendung von Weitverkehrsnetzwerken (Wide Area Networks), des Internet, des Word Wide Web, eines Intranet, eines lokalen Netzwerks und anderer. Die Zwischenverbindungsstruktur kann mit einem physikalischen Medium wie einem Draht- oder Glasfaserkabel implementiert werden oder sie kann in einer drahtlosen Umgebung implementiert werden.
Desktop-Einheiten
Die DTU ist die Einrichtung, durch die Benutzer auf die Dienste zugreifen. 1 stellt die DTUs 121, 122 und 123 dar. Eine DTU kann aus einer Anzeige 126, einer Tastatur 124, einer Maus 125 und Audiolautsprechern 127 bestehen. Die DTU beinhaltet die benötigte Elektronik, um diese Einrichtungen mit der Zwischenverbindungsstruktur über Schnittstellen zu verbinden und Daten zu und von den Diensten zu übertragen und zu empfangen.
Eine Blockdiagramm einer DTU ist in 3 dargestellt. Die Komponenten der DTU sind intern an einen PCI-Bus 319 angeschlossen. Ein Netzwerk-Controller 302 kommuniziert mit der Zwischenverbindungsstruktur wie einem Ethernet über die Leitung 314. Eine Audio-Codec 303 empfängt Audiodaten auf der Schnittstelle 316 und ist an den Netzwerk-Controller 302 angeschlossen. USB-Datenkommunikation wird auf den Leitungen 313 zum USB-Controller 301 bereitgestellt.
Ein eingebetteter Prozessor 304 kann zum Beispiel ein Sparc2ep mit angeschlossenem Flashspeicher 305 und DRAM 306 sein. Der USB-Controller 301, der Netzwerk-Controller 302 und der eingebettete Prozessor 304 sind alle an den PCI-Bus 319 angeschlossen. Ebenso angeschlossen an den PCI-Bus 319 ist der Video-Controller 309 mit zugeordnetem SGRAM 307. Der Video-Controller 309 kann zum Beispiel ein ATI RagePro+ Framepuffer-Controller sein, der SVGA-Ausgabe auf der Leitung 315 bereitstellt. Daten werden optional in den und aus dem Video-Controller durch den Video-Decoder 310 bzw. den Video-Encoder 311 übergeben. Diese Daten können digitale oder analoge Videosignale umfassen (z. B. NTSC (National Television Systems Committee), PAL (Phase Alternate Line), etc.). Eine Smartcard-Schnittstelle 308 kann ebenso an den Video-Controller 309 angeschlossen sein.
Alternativ kann die DTU unter Verwendung einer Einzelchip-Lösung implementiert werden wie in 4 dargestellt. Die Einzelchip-Lösung enthält die benötigte Verarbeitungsfähigkeit, die mittels der CPU 401 und des Grafik-Wiedergebers bzw. Bilderzeugers 405 implementiert ist. Der Chipspeicher 407 wird zusammen mit dem bzw. der Video-Contoller/Schnittstelle 406 zur Verfügung gestellt. Ein universeller serieller Bus- (Universal Serial Bus, USB) -Controller 402 ist vorgesehen, um die Kommunikation mit einer Maus, einer Tastatur und anderen lokalen Einrichtungen, die an die DTU angeschlossen sind, zuzulassen. Ein Sound-Controller 403 und eine Verbindungsschnittstelle 404 sind ebenso vorgesehen. Die Video-Schnittstelle teilt sich den Speicher 407 mit der CPU 401 und dem Grafik- bzw. Bilderzeuger 405. Die in dieser Ausführungsform verwendete Software könnte sich lokal in nicht-flüchtigem Speicher befinden, oder sie kann durch die Verbindungsschnittstelle geladen werden, wenn das Gerät bzw. die Einrichtung eingeschaltet ist.
BETRIEB DER VIRTUELLEN DESKTOP-SYSTEMARCHITEKTUR
Sitzungen-Behandlung bzw. -Handhabung
Die Bereitstellung von Diensten in der virtuellen Desktop-Systemarchitektur dreht sich um eine Abstraktion, die hier als eine Sitzung bzw. Sitzung bezeichnet wird. Eine Sitzung ist eine Repräsentation derjenigen Dienste, die im Namen eines Benutzers zu irgendeinem Zeitpunkt ausgeführt werden. Eine neue Sitzung kann angelegt bzw. geschaffen werden, wenn ein neues Token dem Authentisierungsmanager durch die DTU übergeben wird. Ein Token ist ein eindeutiger Bezeichner bzw. eine eindeutige Kennung, der bzw. die eine Ethernet-Adresse einer DTU (Pseudo-Token) oder die Seriennummer auf einer Smartcard sein kann.
Die Sitzungenabstraktion wird durch Einrichtungen aufrecht erhalten, die als die Authentisierungs- und Sitzungsmanager bekannt sind, deren Aufgabe es ist, die Datenbank der Abbildungen zwischen Tokens und Sitzungen aufrecht zu erhalten und die Dienste, die jede Sitzung ausmachen, zu verwalten. Für jedes Token, von dem das System weiß, gilt, daß es eine oder mehrere Sitzungen gibt, bietet der Sitzungsmanager dem Benutzer oder Administrator einen Dienst, der es ermöglicht, daß Sitzungen konfiguriert und neue Sitzungen erzeugt werden.
Eine Sitzung ist nicht an irgendeine bestimmte DTU gebunden. Ein Token ist einer Benutzersitzung zugeordnet, und die Sitzung kann auf jeder beliebigen DTU angezeigt werden, an der der Benutzer seine Smartcard einsetzt bzw. einsteckt. Ein Softwareprozeß, der als der Authentisierungsmanager bekannt ist, ist dafür verantwortlich, die Legitimität eines Tokens sicherzustellen und ein Token einer gewünschten Sitzung zuzuordnen. Die DTU ist typischerweise im Schlaf-, Bereitschafts- bzw. Standby- oder ausgeschalteten Betriebszustand, wenn sie nicht in Verwendung ist. Wenn ein Benutzer eine bestimmte DTU zu benutzen wünscht, wird der Zugang bzw. Zugriff des Benutzers in einem Authentisierungsaustausch validiert bzw. für gültig erklärt, der eines oder mehrere der folgenden umfaßt: eine Smartcard, einen Schlüssel, ein Paßwort, einen biometrischen Mechanismus oder irgendeinen anderen geeigneten Authentisierungsmechanismus. Das Token, das aus diesem Austausch extrahiert wird, wird daraufhin verwendet, um eine Verbindung zu der passenden Sitzung aufzubauen.
Wenn der Authentisierungsmanager ein Token validiert, benachrichtigt er den Sitzungsmanager des Servers, der seinerseits sämtliche Dienste innerhalb der ausgewählten Sitzung benachrichtigt, und die Anzeige der Sitzung wird beim Server zusammengefügt und zum Desktop des Benutzers übertragen. Aus einer Sitzung heraus kann ein Benutzer mit vorhandenen Diensten interagieren, neue Dienste einleiten oder Dienste, die ausgeführt werden, beenden bzw. löschen. Wenn der Benutzer die DTU verläßt (z. B. durch Wegnehmen einer Smartcard), bemerkt der Authentisierungsmanager dies und benachrichtigt den Sitzungsmanager, der seinerseits sämtliche ihm zugehörige Dienste benachrichtigt, die ihre Anzeigefunktionen anhalten, und die DTU kehrt in ihren Ruhezustand zurück. Die Wirkung der Aktivierung und Deaktivierung eine DTU ist ähnlich dem Ausschalten des Anzeigemonitors an einem Desktop-System. Die Dienste der Benutzersitzung sind noch verfügbar und werden vielleicht ausgeführt, aber es wird keine Anzeige erzeugt. Ein Vorteil der vorliegenden Erfindung ist es, daß auf die in einer Sitzung verfügbaren Dienste an irgendeiner angeschlossenen DTU zugegriffen werden kann.
5 liefert ein Beispiel der Sitzungenverwaltung und -authentisierung in der vorliegenden Erfindung. Dieser Gegenstand wird in der gleichzeitig anhängigen U. S. Patentanmeldung mit der Seriennummer 09/063.339, eingereicht am 20. April 1998, mit dem Titel "Method and Apparatus for Sitzung Management and User Authentication", beschrieben, und ist auf den Inhaber der vorliegenden Patentes übertragen worden und wird hier durch die Bezugnahme aufgenommen. Das Netzwerkterminal 502 ist eine DTU, das die Aufgabe hat, die Ausgabe von Diensten einem Benutzer anzuzeigen und die Eingaben an Dienste von dem Benutzer anzunehmen. Das Netzwerkterminal 502 hat die Fähigkeit, auf ein Kommando (z. B. ein Anzeigekommando), das zum Beispiel von einem auf einem Rechendienstanbieter ausgeführten Softwareprogramm (z. B. den Diensten 530–-538, dem Authentisierungsmanager 504 und dem Sitzungsmanager 506) empfangen wurde, zu antworten. Die von einem Benutzer empfangene Eingabe wird zum Beispiel an einen Dienst weitergeleitet, der eine Benutzeranforderung erfüllt bzw. ausführt
Ein Dienst ist ein Programm, das einige Funktionen für einen Benutzer durchführt. Mehr als ein Server kann die Dienste ausführen, aus denen eine Sitzung besteht. Zum Beispiel werden in Sitzung 508 der Dienst 530 auf dem Server 510, die Dienste 532 und 534 auf dem Server 512 und die Dienste 536 und 538 auf dem Server 514 ausgeführt.
Ein Benutzer greift auf ein System (z. B. einen Server, eine Sitzung, einen Dienst und ein Netzwerkterminal) zu, indem er ein Login einleitet. Während des Login wird der Benutzer vom Authentisierungsmanager 504 validiert. Verschiedene Techniken können verwendet werden, um es dem Benutzer zu ermöglichen, ein Login einzuleiten. Zum Beispiel kann der Benutzer ein Login einleiten, indem er eine Taste auf dem Netzwerkterminal 502 drückt.
Nach einer Ausführungsform greift ein Benutzer auf das System zu, indem er eine Smartcard in einen Kartenleser (z. B. den Kartenleser 516) einführt, der am Netzwerkterminal 502 angebracht ist. Eine Smartcard ist eine Karte, die in der Lage ist, Information zu speichern wie zum Beispiel in einem Magnetstreifen oder Speicher der Smartcard. Die Smartcard kann Benutzerinformation wie eine Benutzerkennung (d. h. Benutzer-ID wie eine 64-Bit-Zahl) und optional einen geheimen Code (z. B. eine 128-Bit-Zufallszahl) speichern, die an das Netzwerkterminal 502 übermittelt wird. Der geheime Code kann während der Authentisierung verwendet werden.
Das Netzwerkterminal 502 ist sich seiner Verbindungsnetzwerkadresse und der Adresse des Authentisierungsmanagers 504 bewußt (oder kann sie sich verschaffen). Wenn ein Benutzer ein Login einleitet, leitet das Netzwerkterminal 502 eine Verbindung mit dem Authentisierungsmanager 504 ein, um die Authentisierung zu beginnen. Der Authentisierungsmanager 504 ist ein Programm, das auf einem Server aktiv ist (z. B. ausgeführt wird), der mittels eines Verbindungsnetzwerks wie zum Beispiel einem lokalen Netzwerk (Local Area Network, LAN) mit dem Netzwerkterminal 502 verbunden ist. Es sollte jedoch klar sein, daß das Netzwerkterminal 502 mit dem Authentisierungsmanager 504 unter Verwendung anderer Verbindungsnetzwerktechnologien wie einer Glasfaserschleife, einem Punkt-zu-Punkt-Kabel oder drahtloser Technologien verbunden sein kann. Das Netzwerkterminal 502 sendet eine Start- bzw. Inbetriebsetzungsanforderung, die eine Benutzerkennung (Benutzer-ID) beinhaltet, an den Authentisierungsmanager 504.
Wenn das erwartete Ergebnis vom Benutzer empfangen wurde, benachrichtigt der Authentisierungsmanager 504 den Sitzungsmanager 506 (mittels einer Verbindungsnachricht), daß der Benutzer sich in das System auf dem Netzwerkterminal 502 eingeloggt hat. Die in der Authentisierungsdatenbank 518 enthaltene Sitzungeninformation wird verwendet, um den Server, den Anschluß und den Sitzungenbezeichner (1D) für den Sitzungsmanager 506 anzugeben. Der Sitzungsmanager 506 ist ein Programm, das auf einem Rechendienstanbieter aktiv ist und mit dem Authentisierungsmanager 504 und dem Netzwerkterminal 502 zum Beispiel über ein Verbindungsnetzwerk verbunden ist. Der Authentisierungsmanager 504 sendet eine Nachricht an den Sitzungsmanager 506, indem er die in der Authentisierungsdatenbank 518 enthaltene Server- und Portinformation des Sitzungsmanagers 506 verwendet.
Als Reaktion auf die Verbindungsnachricht vom Authentisierungsmanager 504 benachrichtigt der Sitzungsmanager 506 die Dienste in der aktuellen Sitzung des Benutzers (d. h. die Dienste in der Sitzung 508), daß der Benutzer dem Netzwerkterminal 502 zugeordnet ist. Das heißt, der Sitzungsmanager 506 sendet eine Verbindungsnachricht an die Dienste 530–538, um die Ausgabe an das Netzwerkterminal 502 zu lenken. Der Sitzungsmanager 506 stellt sicher, daß die Dienste, die als notwendige Dienste der Sitzung betrachtet werden, gerade ausgeführt werden. Falls nicht, ver anlaßt der Sitzungsmanager 506, daß sie eingeleitet werden. Der Benutzer kann mit den Diensten 530–538 innerhalb einer Sitzung (z.B. Sitzung 508) interagieren. Das Netzwerkterminal 502 wird mit den Servern 510, 512 und 514 (und den Diensten 530–538) über ein Verbindungsnetzwerk, wie z.B. ein lokales Netzwerk oder andere Verbindungstechnologien, verbunden. Der Benutzer kann auch neue Dienste starten und vorhandene Dienste beenden.
Der Benutzer kann aufhören, das System zu verwenden, indem er die Karte aus dem Kartenleser 516 entfernt. Andere Mechanismen, um das System zu verlassen, können ebenso bei bzw: mit der Erfindung verwendet werden (z. B. eine "Abmelde"- bzw. "Sign-Off"-Taste bzw. -Knopf am Netzwerkterminal 502). Die Dienste 530–538 können weiterlaufen, auch nachdem der Benutzer die Karte aus dem Kartenleser 516 entfernt hat. Das heißt, eine zugeordnete Sitzung bzw. Sitzungen des Benutzers und die Dienste, aus denen eine Sitzung besteht, können während der Zeitspanne, in der der Benutzer vom System abgemeldet ist, weiterhin existieren. Wenn der Benutzer die Karte aus dem Kartenleser 516 entfernt, benachrichtigt das Netzwerkterminal 502 den Authentisierungsmanager 504 (z. B. mittels einer Verbindungsabbaunachricht), der den Sitzungsmanager 506 (z. B. mittels einer Verbindungsabbaunachricht) benachrichtigt. Der Sitzungsmanager 506 benachrichtigt die Dienste 530–538 (z. B. mittels einer Verbindungsabbaunachricht), was deren Übermittlung von Anzeigekommandos an das Netzwerkterminal 502 beendet. Die Dienste 530–538 setzen die Ausführung jedoch während der Zeit fort, in der der Benutzer vom Netzwerkterminal 502 weg ist. Der Benutzer kann sich wieder einloggen, indem er ein Netzwerkterminal wie das Netzwerkterminal 502 verwendet, um sich mit der Sitzung 508 zu verbinden und mit den Diensten 530–538 zu interagieren.
BETRIEB BZW. FUNKTIONSWEISE DER LASTAUSGLEICHSSTRATEGIEN
Die Erfindung implementiert verschiedene Strategien, die Sitzungsservern gemäß deren Kapazität, der aktuellen Last und dem Zustand der Mehrfach-Server-Umgebung zuweisen (z. B. ob die Ankunftsrate neuer Sitzungen hoch oder niedrig ist). In 6 läuft auf jedem Server 600a und 600b ein Gruppenmanagerprozeß 601a und 601b ab, wenn die auf dem Server ablaufende Software (z. B. der Dienst) gestartet wird. Die Gruppenmanagerprozesse 601a und 601b auf jedem Server stellen periodisch die Systemkapazität und die Nutzung auf jedem Server 600a und 600b bezogen auf die verschiedenen Ressourcen fest, zum Beispiel durch Anfragen an das Betriebssystem.
Die von den Gruppenmanagerprozessen eingesetzten Lastausgleichsstrategien sind dafür ausgelegt, einen oder mehrere Faktoren in Betracht zu ziehen wie die Anzahl von Prozessoren, die Geschwindigkeit der Mikroprozessoren in einem gegebenen Server (gemessen in CPU-Taktzyklen), der Umfang von wahlfrei zugreifbarem Speicher (Random Access Memory, "RAM") in einem gegebenen Server (gemessen in Megabyte), der Betrag an Netzwerkbandbreite, die für einen gegebenen Server verfügbar ist (gemessen in Megabit pro Sekunde), die Anzahl von Sitzungen, die auf einem gegebenen Server relativ zu der Aufnahmekapazität dieses Servers ablaufen (z. B. die maximale Anzahl von Sitzungen, die dieser Server beherbergen kann), die Zustände der auf einem Server ablaufenden Sitzungen (z. B. aktiv oder inaktiv) und die erwarteten Nutzungsgewohnheiten gewisser Benutzer.
In 7 stellt der Gruppenmanagerprozeß 601a zuerst fest, ob einer von den Servern 701a oder 701b in der Gruppe bereits eine Sitzung für diese DTU 700 beherbergt, wenn eine gegebene DTU 700 eine Kommunikation mit einem Server 701a aufzunehmen versucht. Zum Beispiel kann ein Benutzer eine Smartcard 707 in die DTU 700 einsetzen und versuchen, sich dem Server 701a gegenüber über die Zwischenverbindungsstruktur 702 zu dem Switch 703 über die Zwischenverbindungsstruktur 704 und schließlich zum Server 701a zu authentisieren.
Da die Gruppenmanagerprozesse 601a und 601b periodisch miteinander bezüglich der Sitzungen, die sich auf jedem Server befinden, kommuniziert haben, weiß der Gruppenmanagerprozeß 601a, der auf dem Server 701a abläuft, mit dem die DTU 700 eine Kommunikation aufzunehmen versucht hat, ob sich die Sitzung bereits auf dem Server 701b befindet. Wenn sich die Sitzung bereits auf dem Server 701b befindet, leitet der Server 701a nach einer Ausführungsform die DTU 700 zu dem Server 701b über die Zwischenverbindungsstruktur 702 an den Switch 703 und über die Zwischenverbindungsstruktur 705 an den Server 701b um, wo sich die Sitzung befindet. In diesem Fall wird die Lastausgleichsstrategie nicht eingesetzt. Ansonsten wird für jede Ressource und jeden Server, die relative Erwünschtheit der Zuweisung einer neuen Sitzung zu diesem Server berechnet.
Der Ablauf bzw. Steuerungsfluß des Umleitungsprozesses ist in 8a abgebildet. Der Gruppenmanagerprozeß 601 läuft auf Server s1 ab. Eine DTU versucht, eine Sitzung auf dem ersten verfügbaren Server einzuleiten, der ihre Rundsendenachricht empfängt, zum Beispiel auf Server s1, Schritt 801, indem sie ein "Einfüge"- bzw. "insert"-Ereignis mit einem Token sendet. Der Gruppenmanagerprozeß 601 liest daraufhin das Paket, um festzustellen, ob eine Umleitung stattgefunden hat, siehe Schritt 802. Wenn dies der Fall ist, stellt der Gruppenmanagerprozeß 601 fest, ob auf s1 eine Sitzung für dieses Token vorliegt, siehe Schritt 803. Wenn eine Sitzung existiert, wird die DTU mit dieser Sitzung verbunden, s. Schritt 804. Wenn keine Sitzung existiert, wird eine neue Sitzung eingerichtet, s. Schritt 805.
Wenn bei Schritt 802 keine Umleitung stattgefunden hat, ermittelt der Gruppenmanagerprozeß 601 die anderen Server (s2,...,sx), mit denen die DTU in Verbindung treten kann, Schritt 806. Als nächstes werden an die Server (s1,...,sx), mit denen die DTU Verbindung aufnehmen kann, von dem Gruppenmanagerprozeß 601 Nachrichten gesendet, die das Token von der DTU angeben, s. Schritt 807. Danach empfängt der Server s1 Antworten von den Servern (s1,...,sx) (Schritt 808), die das Vorliegen (oder Nicht-Vorliegen) einer Sitzung für das gegebene Token angeben.
Der Gruppenmanagerprozeß 601 stellt fest, ob zumindest auf einem Server die Sitzung für das Token existiert, s. Schritt 809. Wenn keine Sitzung existiert, wird eine neue Sitzung für das Token auf Server s1 kreiert, s. Schritt 805. Wenn eine Sitzung existiert, ist der ausgewählte Zielserver derjenige mit der jüngsten Sitzung, der für das Token verfügbar ist, s. Schritt 809. Der Gruppenmanagerprozeß 601 stellt daraufhin fest, ob der Zielserver der aktuelle Server ist, Schritt 811. Wenn der Zielserver nicht der aktuelle Server s1 ist, wird eine Umleitungsnachricht an die DTU gesendet, die ihr mitteilt, zu dem Zielserver umzuleiten, s. Schritt 812. Wenn der Zielserver der aktuelle Server s1 ist, erfolgt ein Übergang zu Schritt 803.
8b zeigt ein Nachrichtenflußdiagramm für eine Serverumleitung. Die Server s1 813, s2 814 und s3 815 und die DTU 816 übergeben Nachrichten. Die DTU 816 sendet ein Einfüge-Ereignis 817 (mit dem Grund = "insert" = „Einfügen") an den Server 813. Nach Übergabe der tokenQ- und tokenR-Nachrichten wird der Server 813 der Tatsache gewahr, daß eine Sitzung für das Token t1 auf dem Server 814 existiert. Der Server 813 sendet daher eine Umleitungsnachricht an die DTU 816. Danach sendet die DTU 816 ein insert-Ereignis 818 an den Server 815. Man beachte, daß ein Teil der Nachricht anzeigt, daß dies eine Umleitung ist (z. B. Grund = "redirect"), wodurch eine wiederholter Authentisierungsversuch umgangen wird.
a. Lastausgleichsstrategie im stationären Zustand
Ein eingeschwungener bzw. stationärer Zustand (steady state) liegt vor, wenn Daten konstant sind und die Ankunftsrate neuer Sitzungen niedrig ist. Eine Ausführungsform der vorliegenden Erfindung implementiert die Lastausgleichsstrategie in einem eingeschwungenen Zustand durch das Ermitteln der relativen Erwünschtheit der Zuweisung einer Sitzung an einen Server. Der Gruppenmanagerprozeß erhält ein Verhältnis, das die Kapazität jeder beliebigen gegebenen Ressource geteilt durch die gesamte aktuelle Nutzung der Ressource addiert zu der gesamten erwarteten hinzukommenden Nutzung durch diese Ressource darstellt.
Nach einer Ausführungsform berechnet jeder Gruppenmanagerprozeß, der sich auf jedem Server befindet, unabhängig die Erwünschtheit und kommuniziert die Erwünschtheit an alle anderen Gruppenmanagerprozesse. Nach einer anderen Ausführungsform ermittelt jeder Gruppenmanagerprozeß, der sich auf jedem Server befindet, die Kapazität und die Belastung der Ressource. Der Gruppenmanagerprozeß übergibt daraufhin die Nutzung und die Belastung der Ressource an alle anderen Gruppenmanagerprozesse, die ihrerseits die Erwünschtheitswerte berechnen. Auf diese Weise erzeugt jeder Gruppenmanagerprozeß eine globale Sicht des Systemzustandes. Diese Strategie wird durch den folgenden seudo-Code veranschaulicht:
In 9 ermittelt der Gruppenmanagerprozeß 601 für einen gegebenen Server s gemäß Schritt 901 die Ressourcenkapazität bezogen auf den Server s. Als nächstes ermittelt der Gruppenmanagerprozeß gemäß Schritt 902 die Ressourcennutzung bezogen auf den Server s. Danach ermittelt der Gruppenmanagerprozeß gemäß Schritt 903 die erwartete Nutzung durch eine Sitzung basierend auf empirischen Meßwerten. Nach einer Ausführungsform wird dieser Meßwert dadurch erhalten, daß der Gruppenmanagerprozeß unter der Annahme arbeitet, daß für eine große Gruppe von Sitzungen die durchschnittliche Ressourcennutzung durch die Sitzungen relativ konstant ist.
Sobald diese Daten vorliegen, berechnet der Gruppenmanagerprozeß in Schritt 904 die Erwünschtheit der Zuweisung einer Sitzung zum gegebenen Server s bezogen auf die getestete Ressource r. Als nächstes ermittelt der Gruppenmanagerprozeß in Schritt 905, ob es andere zu betrachtende Ressourcen gibt. Andere Ressource können umfassen: die Anzahl von Mikroprozessoren bei einem gegebenen Server (da ein Server mehrere Prozessoren haben kann), die Anzahl der auf einem gegebenen Server ablaufenden Sitzungen relativ zu der Aufnahmekapazität dieses Servers (z. B. die maximale Anzahl von Sitzungen, die dieser Server beherbergen kann), die Zustände der auf einem Server ablaufenden Sitzungen (z. B. aktiv oder inaktiv) und die besonderen, erwarteten Anforderungen bestimmter Benutzer.
Wenn es andere Ressourcen zu betrachten gibt, geht der Ablauf entlang des Übergangs 906 weiter, und der Prozeß wird wiederholt. Ansonsten geht der Ablauf entlang des Übergangs 907 weiter, und die Erwünschtheit jeder Ressource bezogen auf den Server s wird ausgegeben, s. Schritt 908. Diese Strategie wird für jeden von den Servern in der Umgebung wiederholt.
Der Gruppenmanager kann die Daten sammeln, die zur Definition von C[r,s], U[r,s] und A[r,s] benötigt werden, zum Beispiel durch Anfragen an das Betriebssystem bezogen auf diesen Server. Zum Beispiel kann das Betriebssystem die Systemlast bezogen auf die Prozessornutzung durch Ermitteln der Anzahl von Prozessen in der Ablaufwarteschlange zu jedem gegebenen Zeitpunkt zur Verfügung stellen. Das Betriebssystem kann die Speichernutzung durch Ermitteln der Menge des benutzten Speichers im Vergleich zum gesamten Speicher in dem System zur Verfügung stellen. Das Betriebssystem kann die Bandbreitennutzung durch Abfragen der Netzwerkstatistiken bezogen auf die gegebenen Schnittstellen zur Verfügung stellen.
Nach einer Ausführungsform wird ein Erwünschtheitswert D für jede von drei Hauptressourcen ermittelt, als da sind: die Prozessorleistung (gemessen in CPU-Taktzyklen), der Hauptspeicher (gemessen in Megabyte von RAM) und die Netzwerkbandbreite (gemessen in Megabit pro Sekunde). Sobald die Ressourcen-spezifischen Erwünschtheitswerte berechnet sind, wird das Minimum der drei Werte für jeden Server als die Gesamt-Erwünschtheit gewählt. Die Motivation dafür, den minimalen Wert herauszugreifen, liegt darin, daß dieser die Ressource repräsentiert, die der größten Konkurrenzsituation auf diesem Server unterworfen ist. Diese Ressource (diejenige, die am stärksten belastet ist) repräsentiert die Ressource, die mit der größten Wahrscheinlichkeit als erste völlig ausgeschöpft wird und die daher bei der Entscheidung, wie die Last zu verteilen ist, am wichtigsten ist.
Das Minimum der Ressourcen-spezifischen Erwünschtheit wird durch Implementieren des folgenden Pseudo-Codes erhalten:
Sobald die minimalen Ressourcen-spezifischen Erwünschtheitswerte ermittelt sind, wird jedem Server nach der Stufe der Erwünschtheit ein Rang zugewiesen, und das am meisten wünschenswerte Ziel kann ausgewählt werden.
b. Lastausgleichsstrategie für nicht-stationären Zustand
Die vorliegende Erfindung ermöglicht es, daß zwei oder mehrere lose gekoppelte, redundante Server gleichzeitig Sitzungen für einen Satz von DTUs beherbergen. Wenn einer dieser Server ausfällt oder einen nicht-eingeschwungenen bzw. nicht-stationären Zustand erreicht (wenn z. B. der Server die Fähigkeit verliert, die darin befindlichen Sitzungen aufrecht zu halten, zum Beispiel im Fall eines Stromausfalls), "schwenkt" jede der mit ihm verbundenen DTUs auf einen der verbleibenden Server "um". Dieses Szenario erzeugt einen instabilen Zustand, da die Ankunftsrate neuer Sitzungen an den verbleibenden Servern augenblicklich sehr groß wird. Es ist in dieser Situation entscheidend, die neuen DTUs proportional unter den übrigen Servern zu verteilen (im nicht-trivialen Fall, in dem es mehr als einen Überlebenden gibt) entsprechend ihrer jeweiligen Aufnahmekapazität.
Da die den Diensten zugeordneten Rechen- und Speicher-Ressourcen, die von den DTUs angefordert werden, über die Gruppe von Servern verteilt ist, ist es möglich, daß Ressourcen ungleichmäßig zugeordnet werden, wodurch die Leistungsfähigkeit auf übermäßig genutzten Servern abfällt, während Ressourcen auf zuwenig genutzten Servern vergeudet werden. Dies gilt besonders in heterogenen Server-Konfigurationen, bei denen die Aufnahmekapazität der Server (d. h. zum Beispiel Anzahl und Geschwindigkeit von Verarbeitungseinheiten, Menge von installiertem Speicher und verfügbare Netzwerkbandbreite) nicht gleich ist. In diesem Fall könnten dann, wenn ein Server mit der niedrigsten Kapazität als erster antwortet, alle im Fehlerfall umgeleiteten DTUs zu diesem am wenigsten leistungsfähigen Server umgeleitet werden, wodurch eine ernsthaft unausgeglichene Lastverteilung und das Risiko weiterer Serverausfälle aufgrund von Überlast herbeigeführt werden würden.
Ein Lastausgleichsschema nach dem Stand der Technik weist eine Sitzung dem am wenigsten belasteten Server zu dem Zeitpunkt zu, zu dem der Benutzer eine Sitzung beginnt (oder wieder aufnimmt). Diese Strategie kann jedoch scheitern, wenn sie mit einer Flut von Sitzungen konfrontiert wird, weil die Systemlast möglicherweise über relativ lange Zeiträume hinweg erfaßt und Bemittelt wird, was zu einer Lastmetrik führt, die in ungenügendem Maße auf eine große Anzahl von Sitzungen, die im Wesentlichen gleichzeitig hinzukommen (z. B. im Fehlerfall umschwenken), zu reagieren im Stande ist.
Da im Fehlerfall innerhalb von Sekunden eine große Anzahl von Sitzungen umgeleitet werden kann, wenn jede Sitzung dem Server mit der geringsten gemeldeten Last zugewiesen würde, ist es möglich, daß im Fehlerfall eine überproportionale Anzahl von Sitzungen auf diesen Server umgeleitet wird, bevor dessen gemeldete Last Zeit hatte, sich entsprechend anzupassen, was möglicherweise zu einer stark unausgewogenen Lastverteilung führt.
In diesem Fall ist die Zuweisung zu dem am wenigsten belasteten Server nicht immer das effizienteste Verfahren. Eine pseudo-zufällige Strategie wird in nicht-eingeschwungenen bzw. nichtstationären Zuständen verwendet. Die 10a und 10b stellen ein Steuerungs-flußdiagramm der pseudo-zufälligen Strategie dar, die in nicht-stationären Zuständen verwendet wird. Anfangs folgt der Gruppenmanagerprozeß 601 den in 9 dargestellten Schritten, um die Erwünschtheit der Zuweisung einer Sitzung zu einem gegebenen Server zu berechnen, Schritt 908, indem die Schritte 901, 902, 903, 904, 905 und 906 durchschritten werden und bei Schritt 906 ein Übergang erfolgt, wenn andere Ressourcen vorhanden sind, oder bei Schritt 907 ein Übergang erfolgt, wenn alle Ressourcen getestet wurden.
Sobald alle Ressourcen ermittelt sind, stellt die Strategie fest, ob andere Server vorhanden sind (Schritt 1000), Wenn dies der Fall ist, geht der Ablauf entlang 1001 weiter und der Prozeß wiederholt sich, indem die Erwünschtheit für andere Server berechnet wird. Wenn keine anderen Server zum Testen übrigbleiben, geht der Ablauf entlang dem Pfad 1002 weiter, und die relativen Erwünschtheitswerte werden durch die folgenden Schritte auf einen zuvor festgelegten Bereich normalisiert. Bei Schritt 1003 wird die Summe der Erwünschtheitswerte durch Addieren jeder Erwünschtheit berechnet. Bei Schritt 1004 werden wahrscheinlichkeitstheoretische Wichtungen angefügt, indem die Summe durch die individuelle Erwünschtheit dividiert wird. Wenn es andere Server gibt, geht gemäß Schritt 1005 der Ablauf entlang des Übergangs 1006 weiter, und der Prozeß wiederholt sich für jeden Server. Wenn die Wichtungen für alle verfügbaren Server ermittelt sind, wird in Schritt 1007 jede wahrscheinlichkeitstheoretische Wichtung in einen Teilbereich z aufgeteilt. Danach wird in Schritt 1008 eine Zufallszahl zwischen 0 und z erzeugt. In welchen Teilbereich auch immer die Zufallszahl fällt, der erhält die Sitzung, siehe Schritt 1009.
Mittels dieser Vorgehensweise werden zum Beispiel eher erwünschte Server in einer Weise gewichtet, die es wahrscheinlicher macht, daß sie im Fehlerfall eine Umleitung in Empfang nehmen. In ähnlicher Weise erhalten Server, die als stärker belastet ermittelt wurden, eine niedrigere Wahrscheinlichkeit. Man nehme zum Beispiel den Fall zweier Server, Server a mit einer Erwünschtheit von 8 und Server b mit einer Erwünschtheit von 2. In diesem Szenario normalisiert eine Ausführungsform der Erfindung die Erwünschtheitswerte in einem Bereich zwischen 0 und 1. Daher erhält der Server a den Bereich 0 bis 0,8, während der Server b den Bereich zwischen 0,8 und 1 erhält. Eine Zufallszahl wird zwischen 0 und 1 erzeugt. Die Zufallszahl legt die Zuweisung zu dem Server fest, zum Beispiel bekommt Server a die Sitzung, wenn 0,6 erzeugt wird. Somit gewichtet die Pseudo-Zufallsstrategie die Wahrscheinlichkeit jedes Servers s, ausgewählt zu werden, durch dessen berechnete Erwünschtheit D[s]. Daher sendet der Gruppenmanagerprozeß auf Server a in dem dargestellten Beispiel dann, wenn die Sitzung auf Server b vorhanden ist, eine Umleitungsnachricht an die DTU, die ihr mitteilt, erneut eine Verbindung mit dem Server b aufzunehmen.
c. Zusätzliche betrachtete Faktoren bei Lastausgleichs- und Hybrid-Strategien
Nach einer Ausführungsform kann der Gruppenmanagerprozeß die Anzahl von Mikroprozessoren bei einem gegebenen Server beim Lastausgleich in Betracht ziehen. Mit Bezug auf 9 schreitet der Ablauf zur Ermittlung der Erwünschtheit durch Einbeziehen der Anzahl von Mikroprozessoren entlang der Schritte 901–904 voran. Nach einer anderen Ausführungsform ist die Anzahl von Sitzungen, die auf einem gegebenen Server relativ zur Aufnahmekapazität dieses Server (z. B. die maximale Anzahl von Sitzungen, die dieser Server beherbergen kann) ablaufen, ein Faktor. Folglich schreitet der Ablauf in 9 entlang der Schritte 901–904 voran. Nach einer anderen Ausführungsform ist die Anzahl von Sitzungen, die auf einem gegebenen Server ablaufen, gemäß Schritt 904 ein Faktor beim Berechnen der Erwünschtheit. Eine genaue Momentaufnahme der Anzahl von Sitzungen zu einem gegebenen Zeitpunkt ist dem auf dem Server ablaufenden Sitzungsmanager bekannt. Diese Ausführungsform kann unterstellen, daß die Art und Menge von Ressourcen, die von den Sitzungen verwendet werden, über eine große Ansammlung gleich bzw. ähnlich ist, und die Last auf der Grundlage dieser Annahme ausgleichen.
Nach anderen Ausführungsformen sind die Zustände der auf einem Server ablaufenden Sitzungen (z. B. aktiv oder inaktiv) ein Faktor. Zum Beispiel kann ein Server eine Sitzung beibehalten, jedoch der Benutzer verwendet keine DTU. Wenn der Benutzer zum Beispiel eine Smartcard entfernt, zeigt dies dem Server an, daß der Benutzer nicht länger mit ihm interagieren wird, und dennoch die Sitzung fortgeführt wird. Dies ist analog dazu, den Monitor an einem herkömmlichen Computer auszuschalten, jedoch die CPU laufen zu lassen. In diesem Fall kann einem Prozeß, der für eine solche Sitzung ausgeführt wird, eine niedrigere Priorität gegenüber lebendigen Sitzungen gegeben werden, um die Last zu diesem Zeitpunkt zu reduzieren. Somit kann unter Bezug auf 9 beim Voranschreiten des Prozesses entlang der Schritte 901–904 die Erwünschtheit auf den Sitzungszuständen basieren. Daher kann der Server von der Annahme ausgehen, daß der Benutzer eine geringere Last auf das System bringt, und die Last dementsprechend verteilen.
Nach einer Ausführungsform implementiert der Server bezogen auf jede Sitzung einen anpaßbaren Parameter, weil bestimmte Sitzungen vorhersehbar sind. Zum Beispiel werden Benutzer, die im Tagdienst arbeiten und ihre Smartcard am Ende des Arbeitstages entfernen, so gut wie nie in der Nacht eine Sitzung erneut einleiten. Andererseits können andere Sitzungen unvorhersehbar sein bei einem Benutzer, der sich zu unvorhersehbaren Zeiten ein- und ausloggt. Mit dieser Art von Überlegungen kann der anpaßbare Parameter den Zeiten, zu denen die vorhersehbare Sitzung nicht aktiv ist, eine niedrigere Wichtung geben.
Nach anderen Ausführungsformen können Benutzern Kennungen zugewiesen werden, die das System auf die besonderen erwarteten Anforderungen bestimmter Benutzer aufmerksam machen. Zum Beispiel sind bestimmte Benutzer starke Benutzer und benötigen für gewöhnlich CPU-, Speicher- und Bandbreiten-intensive Ressourcen, während andere weniger intensive Aktivitäten durchführen, wie das Prüfen von E-Mail. Daher kann die Identität des Benutzers als ein genaues Verfahren zur Ermittlung der erwarteten Last auf dem System verwendet werden, zum Beispiel als ein Faktor in den Schritten 901–904 in 9.
Nach einer anderen Ausführungsform werden die Kosten bzw. der Aufwand der Umleitung betrachtet. Umleitung verursacht Kosten, weil die DTU zum Initiieren einer Sitzung auf einem Server eine Authentisierung für den Server anfordern muß, was bis zu einige Sekunden dauern kann. Sobald der Server die Authentisierungsanforderung empfängt, stellt der Gruppenmanager fest, ob die Anforderung angenommen werden soll, ob die Sitzung bereits auf einem anderen Server existiert, wobei er in diesem Fall die DTU zu diesem Senner umleitet, oder ob andere Server mehr verfügbare Ressourcen haben, was dazu führt, daß die Lastausgleichsstrategie angewendet wird.
Wenn das Ergebnis der Entscheidung des Gruppenmanagers darin besteht, die DTU zu einem anderen Server umzuleiten, muß sich die DTU ein zweites Mal auf dem gewählten Zielserver authentisieren lassen. Da das Authentisieren eine nicht vernachlässigbare Zeitdauer benötigt, werden in dieser Ausführungsform die Kosten des mehrfachen Authentisierens betrachtet. Ein variabler Faktor wird von dem Server in Betracht gezogen, bei dem das versuchte Authentisieren aufgetreten ist. Zum Beispiel kann der variable Faktor zwanzig Prozent betragen. Daher muß der potentielle Zielserver für die Umleitung mindestens zwanzig Prozent mehr verfügbare Ressourcen als der zunächst versuchte Server haben. Wenn der zunächst versuchte Server und der Zielserver in ihrer Verfügbarkeit einer gegebenen Ressource näher als der variable Faktor beieinander liegen, wird die Umleitung nicht stattfinden, und die mit der Umleitung verbundenen Kosten werden eingespart.
Eine Ausführungsform der vorliegenden Erfindung implementiert eine hybride Strategie beim Einsatz der Lastausgleichsstrategie. In 11 kombiniert die hybride Strategie die Verwendung der Strategien im stationären Zustand und die Verwendung der Strategien im nicht stationären Zustand. Daher kann die Information, die von der Lastausgleichsstrategie im stationären Zustand wie Prozessor-, Speicher- oder Bandbreitennutzung verwendet werden, wenn der Gruppenmanagerprozeß feststellt, daß der Server sich in einem stationären Zustand befindet (d. h, die Ankunftsrate neuer Sitzungen niedrig ist). Der Gruppenmanagerprozeß 601 ermittelt in Schritt 1100, ob sich der Server in einem stationären oder in einem nicht stationären Zustand befindet. Wenn sich dieser Server in einem nicht stationären Zustand befindet, geht der Ablauf entlang des Übergangs 1101 weiter, und die Pseudo-Zufallsstrategie in Schritt 1102 und in 10 wird implementiert, um die im Fehlerfall umgeschalteten Sitzungen gleichmäßiger unter den verfügbaren Ressourcen zu verteilen, Schritt 1105. Wenn sich der Server in einem stationären Zustand befindet (d. h. die Daten konstant sind und die Ankunftsrate neuer Sitzungen niedrig ist), geht der Ablauf entlang des Übergangs 1103 weiter, und die Strategie im stationären Zustand in Schritt 1104 und in 9 wird implementiert, um die Sitzungen gleichmäßiger unter den verfügbaren Ressourcen zu verteilen, Schritt 1105.
Es wurden demnach ein Verfahren und eine Vorrichtung zum Implementieren von Lastausgleichsstrategien in Verbindung mit einer oder mehreren speziellen Ausführungsformen bereitgestellt. Die Erfindung ist durch die Ansprüche und deren vollen Schutzumfang einschließlich Äquivalenten definiert.

Claims

Verfahren zum Umleiten einer Sitzung in einer Rechnerumgebung mit mehreren Servern, mit den Schritten: – Aufbauen einer ersten Verbindung zwischen einem ersten Server (600a, 701a oder 813) und einer ersten Station (700 oder 816), – Austauschen von Informationen zwischen dem ersten Server (600a, 701a oder 813) und einem zweiten Server (600b, 701b oder 814) und – Umleiten der ersten Station (700 oder 816) auf den zweiten Server (600b, 701b oder 814) auf der Basis dieser Information, wobei der Schritt des Umleitens aufweist: – Bestimmen, inwieweit es für den ersten Server (600a, 701a oder 813) ein erstes Maß an Attraktivität gibt, – Bestimmen für den zweiten Server (600b, 701b oder 814), inwieweit es für diesen ein zweites Maß an Attraktivität gibt, und – pseudozufälliges Auswählen eines Zielservers auf der Basis der ersten und zweiten Attraktivitäten.
Verfahren nach Anspruch 1, wobei das Bestimmen des Ausmaßes der ersten und zweiten Attraktivitäten das Bestimmen einer erwarteten Ressourcennutzung aufweist.
Verfahren nach Anspruch 1 oder 2, wobei das Bestimmen der ersten Attraktivität aufweist: Bestimmen einer Ressourcenkapazität und Auswerten einer Funktion der Ressourcenkapazität und der erwarteten Ressourcennutzung.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Bestimmen der zweiten Attraktivität aufweist: Bestimmen einer zweiten Ressourcenkapazität und Auswerten einer zweiten Funktion der zweiten Ressourcenkapazität und der erwarteten Ressourcennutzung.
Verfahren nach den Ansprüchen 3 oder 4, wobei das Bestimmen der Ressourcenkapazität, das Bestimmen der erwarteten Ressourcennutzung und die Schritte des Auswertens für jede aus einer Mehrzahl von Ressourcen ausgeführt werden.
Verfahren nach einem der vorstehenden Ansprüche, wobei der erste Server (600a, 701a oder 813) eine Auswahlwahrscheinlichkeit hat, die durch die erste Attraktivität gewichtet wird und der zweite Server (600b, 701b oder 814) eine Auswahlwahrscheinlichkeit hat, die durch die zweite Attraktivität gewichtet ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Information einen Betrag an verfügbarer zentraler Prozessoreinheit (CPU) aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Information einen Betrag an verfügbarem Speicher mit wahlfreiem Zugriff (RAM) aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Information einen Betrag an verfügbarer Bandbreite aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Information eine Anzahl von Sitzungen aufweist.
Vorrichtung mit: einem ersten Server (600a, 701a oder 813), einer ersten Station (700 oder 816), die eine Verbindung zu dem ersten Server (600a, 701a oder 813) hat, wobei der erste Server (600a, 701a oder 813) so ausgestaltet ist, daß er eine erwartete Ressourcennutzung bestimmt, und einem zweiten Server (600b, 701b oder 814), wobei die ersten und zweiten Server (701, 600, 813 oder 814) Information austauschen und wobei der erste Server (600a, 701a oder 813) so ausgestaltet ist, daß er die erste Station (700 oder 816) auf den zweiten Server (600b, 701b oder 814) umlenkt auf der Basis der Information und der erwarteten Ressourcennutzung.
Vorrichtung nach Anspruch 11, wobei der erste Server (600a, 701a oder 813) dafür ausgelegt ist, daß er: eine erste Attraktivität für den ersten Server (600a, 701a oder 813) bestimmt, eine zweite Attraktivität für den zweiten Server (600b, 701b oder 814) bestimmt, und einen Zielserver auf der Basis der ersten und zweiten Attraktivitäten auswählt.
Vorrichtung nach Anspruch 11 oder 12, wobei der erste Server (600a, 701a oder 813) dafür ausgelegt ist, daß er: eine Ressourcenkapazität bestimmt, und eine Funktion der Ressourcenkapazität und der erwarteten Ressourcennutzung auswertet.
Vorrichtung nach einem der Ansprüche 11 bis 13, wobei der erste Server (600a, 701a oder 813) dafür ausgelegt ist, daß er: eine Ressourcenkapazität für jede von einer Mehrzahl von Ressourcen bestimmt, eine entsprechende erwartete Ressourcennutzung für jede der Ressourcen bestimmt, und eine Funktion für jede der Ressourcenkapazitäten und der entsprechenden erwarteten Ressourcennutzungen auswertet.
Vorrichtung nach einem der Ansprüche 11 bis 14, wobei der erste Server (600a, 701a oder 813) dafür ausgelegt ist, einen Server als den Zielserver auszuwählen, welchem eine höchste Attraktivität zugeordnet ist.
Vorrichtung nach einem der Ansprüche 11 bis 15, wobei der erste Server (600a, 701a oder 813) dafür ausgelegt ist, einen Zielserver nach einer Pseudozufallsfunktion auszuwählen.
Vorrichtung nach einem der Ansprüche 11 bis 16, wobei der erste Server (600a, 701a oder 813) eine Auswahlwahrscheinlichkeit hat, die durch die erste Attraktivität gewichtet ist und der zweite Server (701 oder 600) eine Auswahlwahrscheinlichkeit hat, die durch die zweite Attraktivität gewichtet ist.
Computerprogramm zur Implementierung des Verfahrens nach einem der Ansprüche 1 bis 10.