DE112012005625B4

DE112012005625B4 - Datenflusssteuerung für einen Speicherserver

Info

Publication number: DE112012005625B4
Application number: DE112012005625.6T
Authority: DE
Inventors: Ellezer Tamir; Phil C. Cayton; Ben-Zion Friedman; Robert O. Sharp; Donald E. Wood; Vadim Makhervaks
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-01-10
Filing date: 2012-01-10
Publication date: 2018-08-02
Anticipated expiration: 2032-01-11
Also published as: US20140223026A1; DE112012005625T5; WO2013105932A1; CN104040524A; CN104040524B

Abstract

Im Allgemeinen betrifft diese Offenbarung ein Verfahren zur Datenflussteuerung. Das Verfahren kann das Bestimmen einer Serverauslastung als Reaktion auf eine Anfrage von einem Client, das Auswählen eines Kredittyps, mindestens teilweise auf Serverauslastung basierend, sowie das Senden eines Kredits zu dem Client mindestens teilweise basierend auf Serverauslastung aufweisen, wobei Serverauslastung einem Nutzungsniveau eines Servers entspricht, und wobei Kredit einer Datenmenge entspricht, die zwischen dem Server und dem Client übertragen werden kann, und wobei der Kredit konfiguriert ist, um sich im Laufe der Zeit zu verringern, falls der Kredit von dem Client nicht verwendet wird.

Description

GEBIET
Die vorliegende Offenbarung betrifft eine Datenflusssteuerung für Speicherserver.
STAND DER TECHNIK
Ein Speichernetzwerk weist typischerweise eine Mehrzahl vernetzter Speichergeräte auf, die mit einem Server gekoppelt oder in ihn integriert sind. Remote-Clients können konfiguriert werden, um auf ein oder mehrere Speichergeräte über den Server zuzugreifen. Beispiele für Speichernetzwerke umfassen, ohne auf sie beschränkt zu sein, Storage Area Networks (SANs) und Network-Attached Storage (NAS).
Eine Mehrzahl von Clients kann Verbindungen mit dem Server aufbauen, um auf ein oder mehrere Speichergeräte zuzugreifen. Datenflusssteuerung kann verwendet werden, um sicherzustellen, dass der Server ausreichend Ressourcen hat, um alle Anfragen zu erfüllen. Ein Server kann zum Beispiel auf die Menge verfügbaren RAM beschränkt sein, die erforderlich ist, um eingehende Anfragen zwischenzuspeichern. In diesem Fall sollte ein gut ausgelegter Server keine gleichzeitigen Anfragen erlauben, die mehr als die insgesamt verfügbaren Pufferspeicher erfordern. Beispiele für Datenflusssteuerung umfassen, ohne auf sie beschränkt zu sein, die Ratensteuerung und Systeme auf Kreditbasis. Bei einem System auf Kreditbasis, kann ein Client mit einem Kredit für den Server versehen werden, wenn der Client eine Verbindung mit dem Server aufbaut.
In einem Fiber Channel-Netzwerkprotokoll, wird Kredit zum Beispiel zwischen Geräten (zum Beispiel Client und Server) beim Einloggen ausgetauscht. Der Kredit entspricht einer Anzahl von Frames, die zwischen dem Client und dem Server übertragen werden kann. Sobald der Kredit abgelaufen ist (das heißt aufgebraucht wurde), kann ein Quellengerät keine neuen Frames senden, bis das Zielgerät angezeigt hat, dass es in der Lage ist, ausstehende empfangene Frames zu verarbeiten und bereit ist, die neuen Frames zu empfangen. Das Zielgerät meldet, dass es bereit ist, indem dem Quellengerät (das heißt dem Client) bekannt gegeben wird, dass er mehr Kredit hat. Verarbeitete Frames oder Sequenzen von Frames können dann bestätigt werden, was anzeigt, dass das Zielgerät zum Empfangen weiterer Frames bereit ist. Bei einem anderen Beispiel kann in dem iSCSI-Netzwerkprotokoll ein Ziel (zum Beispiel ein Server) den Strom über den Überlastungsfenstermechanismen von TCP regeln.
Ein Nachteil existierender Systeme auf Kreditbasis besteht darin, dass Kredit, sobald er einem angeschlossenen Client gewährt wurde, für diesen Client verfügbar bleibt, bis er verwendet wird. Das kann in mehr ausstehenden Krediten unter angeschlossenen Clients resultieren, als der Server bedienen kann. Wenn daher eine Anzahl von Clients ihren Kredit gleichzeitig verwendet, ist es möglich, dass der Server nicht über die internen Ressourcen verfügt, um alle zu bedienen. Ein anderer Nachteil existierender Systeme auf Kreditbasis besteht darin, dass die Datenflusssteuersysteme statisch bleiben. Server können sich an höhere Client-Anschlüsse oder gesteigerten Verkehr anpassen, indem sie entweder Frames fallen lassen oder zukünftige Kreditgewährungen verringern. Einfache, auf Kredit basierende Systeme kommen daher eventuell nicht gut mit großen Anzahlen angeschlossener Clients, die ein „burstweises“ Nutzungsmuster haben, zurecht.
Aus US 7,035,220 B1 ist ein Verfahren zu Datenflussteuerung bekannt umfassend das Bestimmen einer Serverauslastung als Reaktion auf einen Datenaustausch von einem Client, das Senden eines Kredites zu dem Client, mindestens teilweise basierend auf Serverauslastung, wobei der Kredit einer Datenmenge entspricht, die zwischen zwei Servern übertragen werden kann. Aus „BONOMI, Flavio; Fendick, Kerry W.: The rate-based control-framework for the available bit rate ATM service. iEEE Network, 1995, 9. Jg., Nr. 2, S. 25-39." ist bekannt, während des Datenaustausches zwischen Client und Server den Datendurchsatz zu messen und daraus eine Serverauslastung zu bestimmen.
Aus „WALTHALL, Robert: Using rate based flow control to manage available bit rate in asyncrounous transfer mode networks, 1995“ ist bekannt, vergebene Kredite mit einem „use-it-or-loose-it-Algorithmus“ zu versehen, der einen zeitabhängigen Verfall steuert.
Es besteht die Aufgabe, kredit-basierte Datenflusssteuermechanismen hinsichtlich der Anbindung einer großen Anzahl von Client-Geräten zu verbessern. Diese Aufgabe wird durch die in den unabhängigen Ansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausgestaltungen sind den Unteransprüchen zu entnehmen.
Figurenliste
Merkmale und Vorteile des beanspruchten Gegenstands ergeben sich aus der folgenden ausführlichen Beschreibung von Ausführungsformen, die damit übereinstimmen, wobei die Beschreibung unter Bezugnahme auf die begleitenden Zeichnungen betrachtet werden sollten, auf welchen:

1 eine beispielhafte Systemausführungsform, die der vorliegenden Offenbarung entspricht, veranschaulicht,
2 ein beispielhaftes Flussdiagramm ist, das Operationen eines Servers, die der vorliegenden Offenbarung entsprechen, veranschaulicht,
3A ein beispielhafter endlicher Client-Automat für eine Ausführungsform ist, die der vorliegenden Offenbarung entspricht,
3B ein beispielhafter endlicher Server-Automat für eine Ausführungsform ist, die der vorliegenden Offenbarung entspricht,
4A ein beispielhaftes Flussdiagramm ist, das Operationen eines Client für eine Ausführungsform, die der vorliegenden Offenbarung entspricht, veranschaulicht,
4B ein beispielhaftes Flussdiagramm ist, das Operationen eines Servers veranschaulicht, der für dynamische Datenflusssteuerung, die der vorliegenden Offenbarung entspricht, konfiguriert ist,
5 ein beispielhafter endlicher Server-Automat für eine Ausführungsform ist, die der vorliegenden Offenbarung entspricht, und
6 ein beispielhaftes Flussdiagramm von Operationen eines Servers für die in 5 veranschaulichte Ausführungsform ist.

AUSFÜHRLICHE BESCHREIBUNG
Diese Offenbarung betrifft allgemein einen Datenflusssteuerungsmechanismus für einen Speicherserver. Ein Verfahren und ein System sind konfiguriert, um Clientkredite bereitzustellen, und um Transaktionsanfragen von Clients basierend auf einer Datenflusssteuerungsstrategie zu beantworten. Ein Kredit entspricht einer Datenmenge, die zwischen dem Client und dem Server übertragen werden kann. Ein Typ eines ausgewählten Kredits und ein Timing einer Antwort (zum Beispiel, wenn Kredite gesendet werden) können mindestens teilweise auf der Datenflusssteuerungsstrategie basieren. Die Datenflusssteuerungsstrategie kann sich dynamisch basierend auf einer Anzahl angeschlossener Clients und/oder einer Serverauslastung ändern. Die Serverauslastung entspricht einem Nutzungsniveau des Servers und umfasst irgendwelche Serverressourcen, zum Beispiel RAM-Pufferspeicherkapazität, CPU-Auslastung, Speichergerät-Bandbreite und/oder andere Serverressourcen. Die Serverauslastung hängt von der Serverkapazität und einer Menge von Anfragen nach Diensten und/oder Transaktionen, die der Server verarbeitet, ab. Wenn die Menge die Kapazität überschreitet, ist der Server überlastet. Die Anzahl angeschlossener Clients und Serverauslastung können als Reaktion auf das Empfangen einer Anfrage, als Antwort auf das Erfüllen einer Anfrage und/oder eines Teils einer Anfrage, als Antwort auf einen Anschluss, der zwischen dem Server und einem Client aufgebaut wird, und/oder vor dem Senden eines Kredits zu dem Client beurteilt werden. Die Datenflusssteuerungsstrategie kann sich daher dynamisch basierend auf der Serverauslastung und/oder der Anzahl angeschlossener Clients ändern. Die besondere Strategie, die an einen Client angewandt wird, kann für den Client transparent sein, was Anpassungsfähigkeit des Servers ermöglicht.
Zu den Kredittypen können, ohne auf diese beschränkt zu sein, Ablaufen, Nur Befehl und Befehl und Daten gehören. Ein Ablaufkredit kann mit der Zeit ablaufen und/oder verfallen. Ein ausstehender, nicht benutzter Ablaufkredit kann zum Beispiel nach einer vorbestimmten Zeitspanne nicht mehr verfügbar sein. Die Voraussehbarkeit der Auslastung kann gesteigert werden, da eine relativ große Anzahl zuvor untätiger Clients einen beschäftigten Server nicht mit einem plötzlichen Burst von Anfragen überhäufen kann.
Der Verkehr zwischen dem Server und einem Client umfasst typischerweise sowohl Befehle als auch Daten. Bei einer Ausführungsform, die der vorliegenden Offenbarung entspricht, können die Befehle Datendeskriptoren aufweisen, die konfiguriert sind, um Daten, die mit dem Befehl verbunden sind, zu identifizieren. Bei dieser Ausführungsform kann der Server konfiguriert werden, um, basierend auf der Datenflusssteuerungsstrategie Daten fallen zu lassen und den Befehl zu behalten. Der Server kann dann die Daten holen, indem er die Deskriptoren von dem Befehl verwendet, wenn die Strategie es erlaubt. Wenn der Server zum Beispiel zu beschäftigt ist, um eine Anfrage zu bedienen, kann der Server den Befehl in eine Warteschlange platzieren und die Daten fallen lassen. Wenn die Auslastung des Servers sinkt, kann der Server die Daten holen und den in der Warteschlange befindlichen Befehl ausführen. Wenn die Daten nicht gespeichert werden, erlaubt es das, die Befehle in der Warteschlange zu speichern, da die Befehle typischerweise etwa ein bis drei Größenordnungen weniger Speicherplatz belegen als die Daten.
Hier wird daher eine Vielfalt von Datenflusssteuerungsoptionen beschrieben, bei der eine besondere Option von dem Server basierend auf einer Datenflusssteuerungsstrategie ausgewählt wird. Die Strategie kann daher wenigstens teilweise auf der Serverauslastung und/oder der Anzahl angeschlossener Clients basieren. Die Strategie ist konfiguriert, um für den Client transparent zu sein und kann dynamisch basierend auf der Momentan-Serverauslastung umgesetzt/ausgeführt werden. Obwohl der Datenflusssteuerungsmechanismus hier in Zusammenhang mit einem Speicherserver beschrieben ist, kann der Datenflusssteuerungsmechanismus auf ähnliche Art an jeden Servertyp angewandt werden, ohne den Geltungsbereich der vorliegenden Offenbarung zu verlassen.
1 veranschaulicht eine beispielhafte Systemausführungsform, die der vorliegenden Offenbarung entspricht. Das System 100 weist im Allgemeinen ein Hostsystem (102 (Server), ein Netzwerk 116, eine Mehrzahl von Speichergeräten 118A, 118B, ... 118N und eine Mehrzahl von Clientgeräten 120A, 120B, ... 120N auf. Jedes Clientgerät 120A, 120B,..., 120N kann einen jeweiligen Netzwerkcontroller 130A, 130B, ... 130N aufweisen, der konfiguriert ist, um dem Netzwerk 1160 Zugriff auf das Clientgerät 120A, 120B,..., 120N bereitzustellen. Das Hostsystem 102 kann konfiguriert sein, um eine/mehrere Anfrage (n) von dem einen oder den mehreren anderen Clientgeräten 120A, 120B, ..., 120N auf Zugriff auf ein oder mehrere Speichergeräte 118A, 118B, ..., 118N zu empfangen, und kann konfiguriert sein, um wie hier beschrieben auf die Anfrage(n) zu reagieren.
Das Hostsystem 102 weist im Allgemeinen einen Hostprozessor „Host CPU“ 104, ein Speichersystem 106, einen Bridge-Chipsatz 108, einen Netzwerkcontroller 110 und einen Speichercontroller 114 auf. Die CPU 104 ist mit dem Systemspeicher 106 und dem Bridge-Chipsatz 108 gekoppelt. Der Systemspeicher 106 ist konfiguriert, um ein Betriebssystem OS 105 und eine Anwendung 107 zu speichern. Der Netzwerkcontroller 110 ist konfiguriert, um das Übertragen und den Empfang von Meldungen zwischen dem Host 102 und den Clientgeräten 120A, 120B, ..., 120N zu verwalten. Der Bridge-Chipsatz 108 ist mit dem Systemspeicher 106, dem Netzwerkcontroller 110 und dem Speichercontroller 114 gekoppelt. Der Speichercontroller 114 ist mit dem Netzwerkcontroller 110 über den Bridge-Chipsatz 108 gekoppelt. Der Bridge-Chipsatz 108 kann Peer-to-Peer-Verbindungen zwischen dem Speichercontroller 114 und dem Netzwerkcontroller 110 bereitstellen. Bei einigen Ausführungsformen können der Netzwerkcontroller 110 und der Speichercontroller 114 integriert sein. Der Netzwerkcontroller 110 ist konfiguriert, um dem Hostsystem 102 Netzwerkverbindungen bereitzustellen.
Der Speichercontroller 114 ist mit einem oder mehreren Speichergeräten 118A, 118B, ..., 118N gekoppelt. Der Speichercontroller 114 ist konfiguriert, um Daten zu speichern (schreiben) und Daten von den Speichergeräten 118A, 118B, ..., 118N zu holen (lesen). Die Daten können als Reaktion auf eine Anfrage von dem/den Clientgerät(en) 120A, 120B, ..., 120N und/oder eine Anwendung, die auf der Host-CPU 104 läuft, gespeichert/geholt werden.
Der Netzwerkcontroller 110 und/oder der Speichercontroller 114 können eine Datenflusssteuerungsverwaltungsmaschine 112, die konfiguriert ist, um eine Datenflusssteuerungsstrategie, wie hier beschrieben, umzusetzen, aufweisen. Die Datenflusssteuerungsverwaltungsmaschine 112 ist konfiguriert, um eine Kreditanfrage und/oder eine Transaktionsanfrage von einem oder mehreren Clientgerät(en) 120A, 120B, ..., 120N zu empfangen. Eine Transaktionsanfrage kann eine Leseanfrage oder eine Schreibanfrage aufweisen. Eine Leseanfrage ist konfiguriert, um den Speichercontroller 114 zu veranlassen, Daten aus einem oder mehreren der Speichergeräte 118A, 118B, ..., 118N zu lesen und die gelesenen Daten zu dem anfragenden Clientgerät 120A, 120B, ..., 120N bereitzustellen. Eine Schreibanfrage ist konfiguriert, um den Speichercontroller 114 zu veranlassen, die von dem anfragenden Clientgerät 120A, 120B, ..., 120N empfangenen Daten zu dem/den Speichergerät (en) 118A, 118B, ..., 118N zu schreiben. Die Daten können unter Verwendung von entferntem direktem Speicherzugriff (RDMA) gelesen oder geschrieben werden. Kommunikationsprotokolle, die für RDMA konfiguriert sind, umfassen zum Beispiel, ohne auf sie beschränkt zu sein, InfiniBand™ und iWARP.
Die Datenflusssteuerungsverwaltungsmaschine 112 kann als Hardware, Software und/oder eine Kombination beider umgesetzt sein. Die Software kann zum Beispiel konfiguriert sein, um einen Kredit zu berechnen und zuzuweisen, und Hardware kann konfiguriert sein, um den Kredit geltend zu machen.
Bei auf Kredit basierender Datenflusssteuerung, kann ein Client eine Transaktionsanfrage nur senden, wenn der Client ausstehende nicht verwendete Kredite hat. Wenn der Client keine nicht verwendete Kredite hat, kann der Client einen Kredit von dem Server anfordern und dann die Transaktionsanfrage, sobald der/die Kredit(e) von dem Server erhalten wurden, senden. Ein Kredit entspricht einer Datenmenge, die zwischen dem Client und dem Server übertragen werden kann. Die Datenmenge, die transferiert wird, basiert daher mindestens teilweise auf der Menge an ausstehendem nicht verwendetem Kredit. Ein Kredit kann zum Beispiel einer Leitungsrate multipliziert durch Serververarbeitungslatenz entsprechen. Ein solcher Kredit ist konfiguriert, um es einem Client zu erlauben, die Leitung von zu nutzen, wenn keine anderen Clients aktiv sind. Ein Kredit kann einer Anzahl von Frames und/oder einer Datenmenge, die transferiert werden können, entsprechen. Ein Client kann Kredit(e) als Reaktion auf das Senden der Kreditanfrage zu dem Server, als Reaktion auf das Aufbauen einer Verbindung mit einem Server und/oder als Reaktion auf eine Transaktion zwischen Client und Server empfangen. Die Kredite sind konfiguriert, um Datenflusssteuerung bereitzustellen.
Bei einer Ausführungsform, die der vorliegenden Offenbarung entspricht, kann eine Mehrzahl von Kredittypen von dem Server verwendet werden, um eine dynamische Datenflusssteuerungsstrategie umzusetzen. Zu den Kredittypen können, ohne auf diese beschränkt zu sein, Ablaufen, Nur Befehl und Befehl und Daten gehören. Eine Datenmenge, die mit einem Ablaufkredit verbunden ist, kann mit der Zeit ausgehend von einem ursprünglichen Wert, wenn der Kredit ausgegeben wird, auf null sinken („ablaufen“), wenn der Kredit verfällt. Eine Rate, mit der der Ablaufkredit abnimmt, kann auf einem oder mehreren Ablaufparametern basieren. Die Ablaufparameter umfassen ein Ablaufzeitintervall, eine Ablaufmenge und ein Verfallintervall. Die Ablaufparameter können von dem Server mindestens teilweise basierend auf Datenflusssteuerungsstrategie ausgewählt werden, wenn der Kredit erteilt wird. Die Ablaufparameter können zum Beispiel mindestens teilweise basierend auf einer Anzahl aktiver angeschlossener Clients ausgewählt werden.
Ein Ablaufkredit kann konfiguriert sein, um sich am Ende einer Zeitspanne, die dem Ablaufzeitintervall entspricht, um die Ablaufmenge zu verringern. Die Ablaufmenge kann zum Beispiel einem Prozentsatz (zum Beispiel 50 %) der ausstehenden Kreditmenge an dem Ende jedes Zeitintervalls entsprechen, oder sie kann einer Anzahl Datenbytes und/oder -Frames entsprechen. Bei einem anderen Beispiel kann die Ablaufmenge einem Prozentsatz (zum Beispiel 10 %) der ursprünglich erteilten Kreditmenge entsprechen.
Ein Ablaufkredit kann konfiguriert sein, um an dem Ende einer Zeitspanne, die dem Verfallintervall entspricht, zu verfallen. Das Verfallintervall kann zum Beispiel einer Anzahl von Ablaufintervallen entsprechen. Bei einem anderen Beispiel kann das Verfallintervall nicht einer Anzahl von Ablaufintervallen entsprechen.
Sobald ein Ablaufkredit erteilt ist, können sowohl der Server als auch der Client konfiguriert werden, um den Ablaufkredit um die Ablaufmenge an dem Ende einer Zeitspanne (zum Beispiel, wenn ein Timer-Timeout erreicht ist), die dem Ablaufzeitintervall entspricht, zu verringern. Ein Server kann daher Ablaufkredite basierend auf Datenflusssteuerungsstrategie, die konfiguriert ist, um die verfügbare Summe an Krediten jederzeit einzuschränken, erteilen. Ausstehende Ablaufkredite können dann ablaufen, wenn sie nicht verwendet werden, wodurch eine Situation vermieden wird, bei der eine Anzahl von Clients, die ruhend waren, Transaktionsanfragen auslösen, die den Server überhäufen können.
Nur-Befehl-Kredite und Befehl- und Datenkredite können verwendet werden, wenn Befehle (und/oder Steuerung) und Daten getrennt bereitgestellt werden können. Diese Trennung kann es dem Server erlauben, die Daten fallen zu lassen, aber den Befehl zu behalten, wenn der Server überlastet ist (das heißt Ressourcen unterhalb eines Schwellenwerts). Der Server kann dann Deskriptoren in dem Befehl verwenden, um die Daten später zu holen. Die Befehle umfassen daher Deskriptoren, die konfiguriert sind, um es dem Server zu erlauben, die entsprechenden Daten basierend auf den Deskriptoren zu holen. Ob der Server die Daten fallen lässt, basiert wenigstens teilweise auf der Datenflusssteuerungsstrategie, der Serverauslastung und/oder der Anzahl angeschlossener Clients, wenn die Kredite erteilt werden. Befehl-Kredite (das heißt zum späteren Holen von Daten) können erteilt werden, wenn der Server relativ stärker überlastet ist, und Befehl-und-Daten-Kredite können erteilt werden, wenn der Server relativ weniger überlastet ist.
2 ist ein beispielhaftes Flussdiagramm 200, das Operationen eines Servers für Ausführungsformen, die der vorliegenden Offenbarung entsprechen, veranschaulicht. Die Operationen des Flussdiagramms 200 können zum Beispiel vom Server 102 (zum Beispiel Datenflusssteuerungsverwaltungsmaschine 112) der 1 ausgeführt werden. Die Operationen des Flussdiagramms 200 können zum Beispiel als Reaktion auf eine Kreditanfrage von einem Client, als Reaktion auf eine Anfrage zum Aufbauen einer Verbindung zwischen dem Server und einem Client (und das Aufbauen der Verbindung) und/oder als Reaktion auf eine Transaktionsanfrage von einem Client ausgelöst werden. Der Strom kann bei Operation 210 beginnen. Operation 215 kann das Bestimmen einer Serverauslastung aufweisen. Bei einigen Situationen kann eine Anzahl aktiver und angeschlossener Clients bei Operation 220 bestimmt werden. Ein Kredittyp kann basierend auf der Strategie bei Operation 225 ausgewählt werden. Der Kredittyp kann zum Beispiel einem Ablaufkredit, einem Nur-Befehl-Kredit und/oder einem Befehl-und-Datenkredit, wie hier beschrieben, entsprechen. Der Kredittyp kann wenigstens teilweise auf der Serverauslastung und/oder der Anzahl aktiver und angeschlossener Clients basieren. Operation 230 kann das Senden des Kredits (des ausgewählten Kredittyps) basierend auf der Strategie aufweisen. In Abhängigkeit von der Serverauslastung, kann der Kredit zum Beispiel beim Empfang einer Transaktionsanfrage von einem Client gesendet werden, oder kann bei Abschließen der dazugehörenden Transaktion gesendet werden. Der Programmstrom kann bei Operation 235 enden.
Die Operationen des Flussdiagramms 200 sind daher konfiguriert, um einen Kredittyp (zum Beispiel Ablaufkredit) und/oder das Timing der Bereitstellung des Kredits basierend auf einer Datenflusssteuerungsstrategie auszuwählen. Die Datenflusssteuerungsstrategie basiert wenigstens teilweise auf der Serverauslastung und kann auf der Anzahl aktiver und angeschlossener Clients basieren. Die Serverauslastung und die Anzahl aktiver und angeschlossener Clients sind dynamische Parameter, die sich mit der Zeit verändern können. Derart kann diese Serverauslastung dynamisch verwaltet werden, und Daten-Bursts von einer Vielzahl zuvor ruhender Clients können vermieden werden.
3A ist ein beispielhafter endlicher Client-Automat 300 für eine Ausführungsform, die der vorliegenden Offenbarung entspricht, Bei dieser Ausführungsform können ausstehende Kredite mit der Zeit ablaufen und/oder verfallen. Der endliche Client-Automat 300 umfasst zwei Zustände: Frei zum Senden 305 und Kein Kredit 310. In dem Zustand Frei zum Senden 305, hat der Client ausstehende nicht verwendete Kredite, die noch nicht verfallen sind. In dem Zustand 310, kann der Client zuvor bereitgestellte Kredite (zum Beispiel durch Transaktionen mit einem Server) aufgebraucht haben, und/oder zuvor bereitgestellte Kredite können Ablaufkredite, die verfallen sind, aufweisen. Während der Client in dem Zustand Frei zum Senden 305 konfiguriert sein kann, um Sendungen (das heißt Sendetransaktionsanfragen, Kreditanfragen, Befehle und/oder Daten zu dem Server) zu verarbeiten und Abschlüsse (zum Beispiel Daten-Lese- oder Datenschreibvorgänge) zu verarbeiten. Der Client kann ferner konfiguriert sein, um ausstehende Kredite (zum Beispiel Ablaufkredite) unter Verwendung von Ablaufparametern und/oder einem lokalen Timer anzupassen.
Die Anpassung ist konfiguriert, um die Menge ausstehender nicht verwendete Kredite wie hier beschrieben zu verringern. Der Client kann von dem Zustand Frei zum Senden 305 auf den Zustand Kein Kredit 310 übergehen, wenn zuvor bereitgestellter Kredit aufgebraucht wurde und/oder verfallen ist. Der Client kann von dem Zustand Kein Kredit beim Empfang von mehr Kredit auf den Sendezustand 305 übergehen.
Ein Client kann daher von einem Zustand Frei zum Senden 305 auf einen Zustand Kein Kredit 310 übergehen, indem er ausstehende Kredite verwendet und/oder beim Ablaufen der nicht verwendeten ausstehenden Kredite. Eine Rate, mit der ausstehende Kredite verfallen, kann von dem Server basierend auf der Datenflusssteuerungsstrategie ausgewählt werden. Die Datenflusssteuerungsstrategie kann zum Beispiel konfiguriert sein, um eine Menge an nicht verwendeten ausstehenden Krediten, die Clients, die an den Server angeschlossen sind, zur Verfügung stehen, einzuschränken. 3B ist ein beispielhafter endlicher Server-Automat 350 für eine Ausführungsform, die der vorliegenden Offenbarung entspricht. Bei dieser Ausführungsform können ausstehende Kredite mit der Zeit ablaufen und/oder verfallen, und das Timing des Sendens von Krediten kann auf Momentan-Serverauslastung basieren. Der endliche Server-Automat 350 weist einen ersten Zustand 355 und einen zweiten Zustand 360 auf. Der erste Zustand (nicht überlastet) 355 entspricht dem Server, der adäquate Ressourcen für seine aktuelle Auslastung und die Anzahl aktiver angeschlossener Clients verfügbar hat. Der zweite Zustand (überlastet) 360 entspricht dem Server, der keine adäquaten Ressourcen für seine aktuelle Auslastung und die Anzahl aktiver angeschlossener Clients verfügbar hat.
Während er in dem nicht überlasteten Zustand 355 ist, ist der Server konfiguriert, um Anfragen (zum Beispiel Transaktionsanfragen und/oder Kreditanfragen von Clients) zu verarbeiten und Kredite als Reaktion auf jede eingehende Anfrage (Transaktion oder Kredit) zu senden. Der Client kann ferner konfiguriert sein, um ausstehende Kredite (zum Beispiel Ablaufkredite) für jeden Client, der ausstehende Ablaufkredite hat, unter Verwendung dazugehörender Ablaufparameter und/oder eines lokalen Timers anpassen. Während er in dem überlasteten Zustand 370 ist, ist der Server konfiguriert, um Anfragen von Clients zu verarbeiten, statt aber Kredite als Reaktion auf jede eingehende Anfrage zu senden, ist der Server konfiguriert, um Kredite für jede abgeschlossene Anfrage zu senden. Derart können Kredite für Clients wenigstens teilweise auf der Serverauslastung basieren, da sich diese Serverauslastung auf das Timing der Abschlüsse und daher auf die Zeit, zu der neue Kredite gesendet werden, auswirken kann. Der Server kann ferner konfiguriert sein, um ausstehende Kredite ähnlich wie der nicht überlastete Zustand 355 anzupassen.
Der Server kann von dem nicht überlasteten Zustand 355 auf den überlasteten Zustand 360 als Reaktion auf das Sinken verfügbarer Serverressourcen 375 unterhalb eines Wasserzeichens übergehen. Der Server kann von dem überlasteten Zustand 360 auf den nicht überlasteten Zustand 355 als Reaktion auf das Ansteigen verfügbarer Serverressourcen über ein Wasserzeichen 380 übergehen. Das Wasserzeichen stellt einen Schwellenwert in Bezug auf die Serverkapazität dar, wie zum Beispiel, dass verfügbare Ressourcen oberhalb des Wasserzeichens dem nicht überlasteten Serverzustand 355 entsprechen, und verfügbare Serverressourcen unterhalb des Wasserzeichens dem überlasteten Zustand des Servers 360 entsprechen. Der beispielhafte endliche Server-Automat 350 der 3B veranschaulicht daher ein Beispiel des Sendens von Krediten (beim Empfang einer eingehenden Anfrage oder bei Abschluss) basierend auf einer Datenflusssteuerungsstrategie, die auf Serverauslastung basiert. Ausstehende Ablaufkredite können ebenfalls sowohl in dem überlasteten Zustand 360 als auch in dem nicht überlasteten Zustand 355 angepasst werden.
4A ist ein beispielhaftes Flussdiagramm 400, das Operationen eines Client für eine Ausführungsform, die der vorliegenden Offenbarung entspricht, veranschaulicht. Bei dieser Ausführungsform können ausstehende Kredite mit der Zeit ablaufen und/oder verfallen. Die Operationen des Flussdiagramms 400 können von einem oder mehreren Clientgeräten 120A, 120B, ..., 120N der 1 ausgeführt werden. Der Strom kann bei Operation 402, bei der der Client ursprünglichen Kredit hat, beginnen. Operation 404 kann das Bestimmen, ob der Kredit verfallen ist, aufweisen. Ein ausstehender nicht verwendeter Ablaufkredit kann zum Beispiel auf null abgelaufen sein. Bei diesem Beispiel kann eine Zeitspanne zwischen der Erteilung des Ablaufkredits und der Operation 404 lang genug gewesen sein, um es dem Ablaufkredit zu erlauben, auf null abzulaufen. Bei einem anderen Beispiel kann der ausstehende nicht verwendete Ablaufkredit verfallen sein. Bei diesem Beispiel kann eine Zeitspanne zwischen der Erteilung des Ablaufkredits und der Zeit, bei der Operation 404 ausgeführt wird, größer oder gleich dem Verfallintervall, wie hier beschrieben, sein.
Falls der Kredit verfallen ist, kann eine Kreditanfrage zu dem Server bei Operation 406 gesendet werden. Der Strom kann dann zu Operation 408 zurückkehren. Falls der Kredit nicht verfallen ist, kann bei Operation 410 eine Transaktionsanfrage zu einem entfernten Speichergerät gesendet werden. Die Transaktion kann zum Beispiel eine Anfrage sein. RDMA kann zum Kommunizieren der Anfrage verwendet werden. Operation 412 kann Verarbeitung eines Abschlusses aufweisen. Das Abschließen kann von dem entfernten Speichergerät empfangen werden, wenn die Daten, die mit der Transaktionsanfrage verbunden sind, erfolgreich übertragen wurden. Der Strom kann dann zu Operation 414 zurückkehren.
4B ist ein beispielhaftes Flussdiagramm, das Operationen eines Servers veranschaulicht, der für dynamische Datenflusssteuerung, die der vorliegenden Offenbarung entspricht, konfiguriert ist. Die Operationen des Flussdiagramms 450 können zum Beispiel von dem Server 102 der 1 ausgeführt werden. Der Strom beginnt bei Operation 452, wenn eine Transaktionsanfrage von einem Client empfangen wird. Die Transaktionsanfrage kann eine RDMA-Transaktion-(zum Beispiel Lese- oder Schreib)-Anfrage sein. Ob der Client ausstehenden nicht verfallenen Kredit hat, kann bei Operation 454 bestimmt werden. Ob zum Beispiel ein ausstehender, nicht verwendeter Ablaufkredit auf null abgelaufen ist und/oder ob ein Verfallintervall seit der Erteilung des dazugehörenden Ablaufkredits abgelaufen ist, kann bestimmt werden. Falls der Client keinen ausstehenden nicht verfallenen Kredit hat, kann eine Ausnahme bei Operation 456 gehandhabt werden.
Falls der Client ausstehenden nicht verfallenen Kredit hat, ob die verfügbaren Ressourcen des Servers oberhalb eines Wasserzeichens sind, kann bei Operation 458 bestimmt werden. Wenn die verfügbaren Ressourcen des Servers oberhalb eines Wasserzeichens (das heißt eines Schwellenwerts) sind, entspricht das einem nicht überlasteten Zustand. Falls die Ressourcen des Servers oberhalb des Wasserzeichens sind, kann bei Operation 466 ein Kredit gesendet werden. Die empfangene Transaktionsanfrage kann dann bei Operation 468 verarbeitet werden. Daten können dann von einem Speichergerät geholt und über RDMA zu dem anfragenden Client bereitgestellt werden. Bei einem anderen Beispiel können Daten von dem anfragenden Client geholt und zu einem Speichergerät geschrieben werden. Der Strom kann bei der Rückkehr von Operation 470 enden. Falls die verfügbaren Ressourcen des Servers nicht oberhalb des Wasserzeichens liegen, kann die Transaktionsanfrage bei Operation 460 verarbeitet werden. Operation 462 kann das Senden von Kredit bei Abschluss aufweisen. Der Strom kann bei der Rückkehr von Operation 464 enden.
Die Datenflusssteuerung, die Ablaufkredite verwendet, kann daher verhindern, dass ein Client ausstehende nicht verwendete Kredite nach einem spezifizierten Zeitintervall verwendet, so dass der insgesamt verfügbare Kredit an irgendeinem Zeitpunkt beschränkt wird. Ferner können Kredite, die als Reaktion auf eine Transaktionsanfrage erteilt wurden, zu dem anfragenden Client bei Empfang der Anfrage oder nach dem Abschließen der Transaktion, die mit der Anfrage verbunden ist, basierend auf der Strategie gesendet werden, die wenigstens teilweise auf Serverauslastung (das heißt Ressourcenniveau) basiert. Die verwendete Strategie kann für den Client transparent sein. Wie durch das Flussdiagramm 400 veranschaulicht, hängt die Tatsache, ob ein Client eine Transaktionsanfrage ausstellen kann, davon ab, ob der Client ausstehenden nicht verwendeten Kredit hat. Der Client kann über die Strategie, die von dem Server beim Erteilen eines Kredits verwendet wird, nicht informiert sein. Bei dieser Ausführungsform kann der Server bestimmen, wann ein Kredit basierend auf Momentan-Serverauslastung gesendet wird. Das Verzögern des Sendens von Krediten zu dem Client kann in einer verringerten Transaktionsanfragerate von dem Client resultieren, wodurch die Datenflusssteuerung basierend auf Serverauslastung umgesetzt wird.
5 ist ein beispielhafter endlicher Server-Automat 500 für eine Ausführungsform, die der vorliegenden Offenbarung entspricht. Bei dieser Ausführungsform können Befehle und Daten getrennt gesendet werden. Das getrennte Senden von Befehlen und Daten kann dem Server relativ mehr Anpassungsfähigkeit bei den Reaktionen auf die Client-Transaktionsanfragen bieten, wenn der Server überlastet ist. Wenn der Server überlastet ist, kann der Server zum Beispiel Daten fallen lassen und Befehle für spätere Verarbeitung behalten. Der behaltene Befehl kann daher Datendeskriptoren enthalten, die konfiguriert sind, um es dem Server zu erlauben, die Daten beim Verarbeiten des Befehls zu holen. Bei einem anderen Beispiel können, wenn der Server relativ weniger überlastet ist, Nur-Befehl-Kredite vor dem Senden von Befehl-und-Datenkrediten gesendet werden.
Der endliche Server-Automat 500 umfasst drei Zustände. Ein erster Zustand (nicht überlastet) 510 entspricht dem Server, der adäquate Ressourcen für seine aktuelle Auslastung und die Anzahl aktiver angeschlossener Clients verfügbar hat. Ein zweiter Zustand (erster überlasteter Zustand) 530 entspricht einer mäßigen Überlastung des Servers. Mäßig überlastet entspricht Serverressourcen unterhalb eines ersten Wasserzeichens und oberhalb eines zweiten Wasserzeichens (wobei das zweite Wasserzeichen unterhalb des ersten Wasserzeichens liegt). Ein dritter Zustand (zweiter überlasteter Zustand) 550 entspricht einer mehr als mäßigen Überlastung des Servers. Der zweite überlastete Zustand 550 entspricht Serverressourcen unterhalb des zweiten Wasserzeichens.
Während er in dem nicht überlasteten Zustand 510 ist, ist der Server konfiguriert, um Anfragen (zum Beispiel Transaktionsanfragen und/oder Kreditanfragen von Clients) zu verarbeiten und einen Befehl-und-Datenkredit als Reaktion auf jede eingehende Anfrage zu senden. Während er in dem nicht überlasteten Zustand 510 ist, kann ein einzelner Client in der Lage sein, eine volle Kapazität eines Servers, zum Beispiel mit einer Leitungsrate zu nutzen. Während er in dem ersten überlasteten Zustand 530 ist, ist der Server konfiguriert, um Anfragen von Clients zu verarbeiten, einen Nur-Befehl-Kredit als Reaktion auf die empfangene Anfrage zu senden und einen Befehl-und-Datenkredit für jede abgeschlossene Anfrage zu senden. Auf diese Art können, wenn der Server in dem ersten überlasteten Zustand 530 ist, Nur-Befehl-Kredite und Befehl-und-Datenkredite zu Clients mindestens zum Teil auf Serverauslastung basierend bereitgestellt werden.
Während er sich in dem zweiten überlasteten Zustand 550 befindet, ist der Server konfiguriert, um eingehende („Push“)-Daten fallen zu lassen und dazugehörende Befehl zu behalten. Der Server ist ferner konfiguriert, um die Befehle zu verarbeiten und Daten zu holen (zum Beispiel unter Verwendung von Datendeskriptoren), wenn der dazugehörende Befehle verarbeitet wird. Der Server kann dann einen Nur-Befehl-Kredit nach Abschließen jeder Anfrage senden. Wenn sich der Server daher in dem zweiten überlasteten Zustand 550 befindet, können eingehende Daten fallen gelassen werden und können später, wenn der dazugehörende Befehl verarbeitet wird, geholt werden, was größere Anpassungsfähigkeit des Servers bietet. Ferner kann das Timing der Bereitstellung von Krediten zu einem Client mindestens teilweise auf der Serverauslastung basieren.
Der Server kann von dem nicht überlasteten Zustand 510 auf den ersten überlasteten Zustand 530 als Reaktion auf das Sinken verfügbarer Serverressourcen unter ein erstes Wasserzeichen 520 übergehen, und kann von dem ersten überlasteten Zustand 530 auf den nicht überlasteten Zustand 510 als Reaktion auf das Ansteigen verfügbar Serverressourcen über das erste Wasserzeichen 525 übergehen. Der Server kann von dem ersten überlasteten Zustand 530 auf den zweiten überlasteten Zustand 550 als Reaktion auf das Sinken verfügbarer Serverressourcen unter ein Wasserzeichen 540 übergehen. Das zweite Wasserzeichen entspricht weniger verfügbaren Serverressourcen als das erste Wasserzeichen. Der Server kann von dem zweiten überlasteten Zustand 550 auf den ersten überlasteten Zustand 530 als Reaktion auf das Ansteigen der verfügbaren Serverressourcen über das zweite Wasserzeichen 545 (und unter das erste Wasserzeichen) übergehen.
Der endliche Server-Automat 500 ist daher konfiguriert, um dem Server Anpassungsfähigkeit bei der Auswahl seiner Reaktion auf eine Transaktionsanfrage von einem Client zu bieten. Bei dieser Ausführungsform können Befehle und Daten getrennt übertragen werden, was das Fallenlassen von Daten und das Senden von Nur-Befehl-Krediten erlaubt, wenn der Server mehr als mäßig überlastet ist. Wenn der Server mäßig überlastet ist, können Daten nicht fallen gelassen werden, ein Nur-Befehl-Kredit kann beim Empfang einer Anfrage gesendet werden, und ein Befehl-und-Datenkredit kann beim Abschließen einer Transaktion in Zusammenhang mit der Anfrage gesendet werden. Die Daten können später geholt werden, wenn der dazugehörende Befehl verarbeitet wird. Ferner können der Nur-Befehl-Kredit und der Befehl-und-Datenkredit einem Client mit einem Timing bereitgestellt werden, das mindestens teilweise auf Serverauslastung basiert.
6 ist ein beispielhaftes Flussdiagramm 600 von Operationen eines Servers für den endlichen Automaten, der in 5 veranschaulicht ist. Die Operationen des Flussdiagramms 600 können zum Beispiel von dem Server 102 der 1 ausgeführt werden. Die Operationen des Flussdiagramms 600 können bei 602 beginnen, wenn ein Befehl und Daten von einem Client empfangen werden. Der Befehl kann zum Beispiel ein RDMA-Befehl sein. Ob der Client ausstehenden nicht verfallenen Kredit hat, kann bei Operation 604 bestimmt werden. Operation 606 weist das Handhaben der Ausnahme auf, falls der Client keine ausstehenden nicht verfallenen Kredite hat. Ob die Serverressourcen oberhalb des ersten Wasserzeichens sind, kann bei Operation 608 bestimmt werden. Ressourcen oberhalb des ersten Wasserzeichens entsprechen dem nicht überlasteten Server. Wenn der Server nicht überlastet ist, kann ein Befehl-und-Datenkredit bei Operation 610 gesendet werden. Die Anfrage kann bei Operation 612 verarbeitet werden, und der Strom kann bei der Rückkehr 614 enden. Falls die Serverressourcen unterhalb des ersten Wasserzeichens sind, kann bei Operation 616 bestimmt werden, ob die Serverressourcen oberhalb des zweiten Wasserzeichens liegen. Serverressourcen unterhalb des ersten Wasserzeichens und oberhalb des zweiten Wasserzeichens entsprechen dem ersten überlasteten Zustand 530 der 5. Falls der Server in dem ersten überlasteten Zustand ist, kann ein Nur-Befehl-Kredit bei Operation 618 gesendet werden. Die empfangene Anfrage kann bei Operation 620 verarbeitet werden. Operation 622 kann das Senden eines Befehl-und-Datenkredits beim Abschließen des Datentransfers in Zusammenhang mit der empfangenen Anfrage umfassen.
Falls die Ressourcen unter dem zweiten Wasserzeichen liegen (das heißt, dass sich der Server in dem zweiten überlasteten Zustand befindet, der stärker überlastet ist als der erste überlastete Zustand), kann die Datennutzlast bei Operation 624 fallen gelassen werden. Der Befehl, der zu den fallen gelassenen Daten gehört, kann zu einer Befehlswarteschlange bei Operation 626 hinzugefügt werden. Operation 628 kann das Verarbeiten einer Befehl-Rückstandwarteschlange umfassen (je nachdem, wie die Serverressourcen es erlauben). Neuer Kredit (das heißt Befehl und/oder Daten) kann gemäß der Datenflusssteuerungsstrategie bei Operation 630 gesendet werden. Der Strom kann zu Operation 634 zurückkehren.
Bei dieser Ausführungsform (Befehl und Daten getrennt) können daher Nur-Befehl-Kredite und Befehl-und-Datenkredite zu unterschiedlichen Zeitpunkten basierend auf der Serverstrategie, die mindestens teilweise auf der Momentan-Serverauslastung basiert, bereitgestellt werden. Wenn sich der Server ferner in dem zweiten überlasteten Zustand (relativ mehr überlastet) befindet, können Daten fallen gelassen und der dazugehörende Befehl behalten werden, um später verarbeitet zu werden. Der dazugehörende Befehl kann in eine Befehlswarteschlange zur Verarbeitung, wenn Ressourcen verfügbar sind, platziert werden. Daten können dann geholt werden, wenn der dazugehörende Befehl verarbeitet wird.
Hier wurde eine Vielfalt von Datenflusssteuerungsmechanismen beschrieben. Ablaufkredite können verwendet werden, um die Anzahl ausstehender Kredite zu beschränken. Ein Server kann konfiguriert sein, um Kredite mindestens teilweise auf Momentan-Serverauslastung basierend zu senden. Wenn der Server nicht überlastet ist, können Kredite als Reaktion auf eine Anfrage, wenn die Anfrage empfangen wird, gesendet werden. Wenn der Server überlastet ist, können Kredite nicht gesendet werden, wenn die Anfrage empfangen wird, sondern können verzögert werden, bis ein Datentransfer, der zu der Anfrage gehört, abgeschlossen wird. Bei der Ausführungsform mit getrenntem Befehl und Daten, können Nur-Befehl-Kredite und Befehl-und-Datenkredite zu unterschiedlichen Zeiten mindestens teilweise auf der Serverauslastung basierend gesendet werden. Wenn sich die Überlastung verschlimmert, können eingehende Daten fallen gelassen und ihr dazugehörender Befehl kann in einer Warteschlange zur späteren Verarbeitung gespeichert werden. Wenn der dazugehörende Befehl verarbeitet wird, können die Daten geholt werden. Der Server kann daher einen besonderen Datenflusssteuerungsmechanismus oder eine Kombination von Mechanismen dynamisch, basierend auf Momentan-Serverauslastung und/oder einer Anzahl aktiver und angeschlossener Clients auswählen.
Obwohl oben Stehendes als beispielhafte grundlegende Systemarchitekturen und Methodologien gilt, sind Änderungen an der vorliegenden Offenbarung möglich. Ein Betriebssystem 105 in einem Hostsystemspeicher kann zum Beispiel Systemressourcen und Steueraufgaben, die zum Beispiel auf dem Hostsystem 102 laufen, verwalten. Das OS 105 kann zum Beispiel unter Verwendung von Microsoft Windows, HP-UX, Linux oder UNIX umgesetzt werden, obwohl andere Betriebssysteme verwendet werden können. Bei einer Ausführungsform kann das OS 105, das in 1 gezeigt ist, durch eine virtuelle Maschine ersetzt werden, die verschiedenen Betriebssystemen, die auf einer oder mehreren Verarbeitungseinheiten laufen, eine Abstraktionsschicht für zugrundeliegende Hardware bereitstellen.
Das Betriebssystem 105 kann einen oder mehrere Protokollstapel umsetzen. Ein Protokollstapel kann ein oder mehrere Programme zum Verarbeiten von Paketen umsetzen. Ein Beispiel für einen Protokollstapel ist ein TCP/IP-(Transport Control Protocol/Internet Protocol)-Protokollstapel, der ein oder mehrere Programme zum Handhaben (zum Beispiel Verarbeiten oder Erzeugen) von Paketen zum Übertragen und/oder Empfangen über ein Netzwerk aufweist. Ein Protokollstapel kann alternativ aus einem dedizierten Subsystem bestehen, wie zum Beispiel eine TCP-Offload-Engine und/oder ein Netzwerkcontroller 110.
Andere Änderungen sind möglich. Der Systemspeicher, zum Beispiel der Systemspeicher 106 und/oder Speicher, der zu dem Netzwerkcontroller gehört, zum Beispiel zum Netzwerkcontroller 110, kann einen oder mehrere der folgenden Speichertypen aufweisen: Halbleiter-Firmware-Speicher, programmierbarer Speicher, nicht flüchtiger Speicher, Nur-Lese-Speicher, elektrisch programmierbarer Speicher, Direktzugriffsspeicher, Flashspeicher, Magnetplattenspeicher und/optischer Plattenspeicher. Entweder zusätzlich oder alternativ, können der Systemspeicher 106 und/oder der Speicher, der zu dem Netzwerkcontroller 110 gehört, andere und/oder später entwickelte Typen computerlesbaren Speichers aufweisen. Ausführungsformen der Verfahren, die hier beschrieben sind, können in einem System umgesetzt werden, das einen oder mehrere Speicherträger aufweist, auf welchen einzeln oder kombiniert Anweisungen gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die Verfahren umsetzen. Hier kann der Prozessor zum Beispiel eine Verarbeitungseinheit und/oder programmierbare Schaltungen in dem Netzwerkcontroller umfassen. Es wird daher beabsichtigt, dass Operationen gemäß den hier beschriebenen Verfahren über eine Mehrzahl physikalischer Geräte, wie zum Beispiel Verarbeitungsstrukturen an mehreren unterschiedlichen physikalischen Lagen verteilt werden können. Der Speicherträger kann irgendeinen Typ konkreten Träger aufweisen, zum Beispiel irgendeinen Typ Diskette, optische Platte, Compact Disc-Nur-Lese-Speicher (CD-ROMs), wieder beschreibbare Compact Disc (CD-RWs) und magneto-optische Platten, Halbleitergeräte, wie zum Beispiel Nur-Lese-Speicher (ROMs), Direktzugriffspeicher (RAMs), wie zum Beispiel dynamische und statische RAMs, löschbaren programmierbaren Nur-Lese-Speicher (EPROMs), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROMs), Flashspeicher, magnetische oder optische Karten oder irgendeinen Trägertyp, der zum Speichern elektronischer Anweisungen geeignet ist.
Das Ethernet-Kommunikationsprotokoll kann in der Lage sein, Kommunikation unter Verwendung eines Transmission Control Protocol/Internet Protocol (TCP/IP)-Protokolls zu erlauben. Das Ethernet-Protokoll kann dem Ethernet-Standard entsprechen, oder mit ihm kompatibel sein, der vom Institute of Electrical and Electronics Engineers (IEEE) mit dem Titel „IEEE 802.3 Standard“ veröffentlicht wurde, herausgegeben im März 2002, und/oder mit späteren Versionen dieses Standards.
Das InfiniBand™-Kommunikationsprotokoll kann mit der InfiniBand-Spezifikation übereinstimmen oder mit ihr kompatibel sein, die von der InfiniBand Trade Association (IBTA) mit dem Titel „InfiniBand Architecture Specification“ veröffentlicht wurde, herausgegeben im Juni 2001, und/oder mit späteren Versionen dieser Spezifikation.
Das iWARP-Kommunikationsprotokoll kann mit dem iWARP-Standard entsprechen oder mit ihm kompatibel sein, der von RDMA Consortium herausgegeben und von der Internet Engineering Task Force (IETF) gepflegt und veröffentlicht wird, mit dem Titel „RDMA over Transmission Control Protocol (TCP) standard“, herausgegeben in 2007, und/oder mit späteren Versionen dieses Standards.
„Schaltungen“, wie hier in irgendeiner Ausführungsform verwendet, können zum Beispiel einzeln oder kombiniert fest verdrahtete Schaltungen, programmierbare Schaltungen, Zustandsmaschinenschaltungen und/oder Firmware umfassen, die Anweisungen, die von programmierbaren Schaltungen ausgeführt werden, speichern.
Bei einem Aspekt wird ein Verfahren zur Datenflusssteuerung bereitgestellt. Das Verfahren weist das Bestimmen einer Serverauslastung als Reaktion auf eine Anfrage von einem Client, das Auswählen eines Kredittyps, mindestens teilweise auf Serverauslastung basierend, sowie das Senden eines Kredits zu dem Client mindestens teilweise basierend auf Serverauslastung auf, wobei die Serverauslastung einem Nutzungsniveau eines Servers entspricht, und wobei Kredit einer Datenmenge entspricht, die zwischen dem Server und dem Client übertragen werden kann, und wobei der Kredit konfiguriert ist, um sich im Laufe der Zeit zu verringern, falls der Kredit von dem Client nicht verwendet wird.
Bei einem anderen Aspekt wird ein Speichersystem bereitgestellt. Das Speichersystem weist einen Server und eine Mehrzahl von Speichergeräten auf. Der Server weist eine Datenflusssteuerungsverwaltungsmaschine auf, wobei die Datenflusssteuerungsverwaltungsmaschine konfiguriert ist, um eine Serverauslastung als Reaktion auf eine Anfrage von einem Client um Zugriff auf mindestens einem der Mehrzahl von Speichergeräten zu bestimmen, einen Kredittyp mindestens teilweise basierend auf Serverauslastung auszuwählen, und einen Kredit zu dem Client mindestens teilweise basierend auf Serverauslastung zu senden, und wobei die Serverauslastung einem Nutzungsniveau des Servers entspricht, und wobei der Kredit einer Datenmenge entspricht, die zwischen dem Server und dem Client übertragen werden kann, und der Kredit konfiguriert ist, um sich im Laufe der Zeit zu verringern, wenn der Kredit von dem Client nicht verwendet wird.
Bei einem anderen Aspekt wird ein System bereitgestellt. Das System weist einen oder mehrere Speicherträger auf, auf welchen einzeln oder in Kombination Anweisungen gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, in Folgendem resultieren: Bestimmen einer Serverauslastung als Reaktion auf eine Anfrage von einem Client, Auswählen eines Kredittyps, mindestens teilweise auf Serverauslastung basierend, sowie Senden eines Kredits zu dem Client mindestens teilweise basierend auf Serverauslastung, wobei Serverauslastung einem Nutzungsniveau eines Servers entspricht, und wobei Kredit einer Datenmenge entspricht, die zwischen dem Server und dem Client übertragen werden kann, und wobei der Kredit konfiguriert ist, um sich im Laufe der Zeit zu verringern, falls der Kredit von dem Client nicht verwendet wird.

Claims

Verfahren zur Datenflusssteuerung, wobei das Verfahren Folgendes aufweist: Bestimmen einer Serverauslastung als Reaktion auf eine Anfrage von einem Client, wobei die Serverauslastung einem ersten oder zweiten oder dritten Nutzungsniveau entspricht Auswahl, durch den Server, eines Kredittyps, wenigstens teilweise auf dem Nutzungsniveau basierend, wobei der Kredittyp Nur-Befehl-Kredite oder Daten-Befehl-Kredite umfasst und Senden eines Kredits zu dem Client, wobei der Kredit konfiguriert ist, um sich mit der Zeit zu verringern, falls der Kredit von dem Client nicht verwendet wird und wobei der Kredit einer Datenmenge entspricht, die zwischen dem Server und dem Client übertragen werden kann, und abhängig von dem bestimmten Nutzungsniveau: in dem ersten Nutzungsniveau: Empfangen von Anfragen und Senden eines Daten-Befehl-Kredites als Reaktion auf jede empfangene Anfrage; in dem zweiten Nutzungsniveau: Empfangen von Anfragen und Senden eines Nur-Befehl-Kredites als Reaktion auf jede empfangene Anfrage, sowie Senden eines Daten-Befehl-Kredites für jede abgeschlossene Anfrage; und in dem dritten Nutzungsniveau: Fallenlassen von zu einer Anfrage gehörenden eingehenden Push-Daten, Senden eines Nur-Befehl-Kredites für jede abgeschlossene Anfrage und Holen der fallengelassenen Daten bei Verarbeitung des dazugehörenden Befehls zu einem späteren Zeitpunkt.
Verfahren nach Anspruch 1, wobei die Anfrage eine Anschlussanfrage und/oder eine Transaktionsanfrage und/oder eine Kreditanfrage aufweist.
Verfahren nach Anspruch 1, wobei der Kredit zu dem Client beim Empfang der Anfrage von dem Server gesendet wird, falls die Serverauslastung verfügbaren Serverressourcen oberhalb eines Wasserzeichens entspricht, oder der Kredit bei Abschluss einer Transaktion, die zu der Anfrage gehört, zu dem Client gesendet wird, falls die Serverauslastung verfügbaren Serverressourcen unterhalb des Wasserzeichens entspricht.
Verfahren nach Anspruch 1, das ferner das Verringern des Kredits durch eine Ablaufmenge für jedes Ablaufzeitintervall, in dem der Kredit nicht verwendet wird, aufweist.
Verfahren nach Anspruch 1, das ferner das Veranlassen des Verfallens des Kredits nach einem Verfalldatum aufweist, falls der Kredit nicht verwendet wird.
Verfahren nach Anspruch 1, wobei der Kredittyp mindestens teilweise basierend auf einer Anzahl anderer an den Server angeschlossener Clients ausgewählt wird.
Verfahren nach Anspruch 1, wobei eine Transaktion zwischen dem Server und dem Client einen Befehl und dazugehörende Daten aufweist und die dazugehörenden Daten fallen gelassen werden, falls die Serverauslastung verfügbaren Serverressourcen unterhalb eines Wasserzeichens entspricht, und die dazugehörenden Daten später geholt werden, wenn die verfügbaren Serverressourcen über das Wasserzeichen ansteigen.
Speichersystem, das Folgendes aufweist: einen Server, der eine Datenflussverwaltungsmaschine aufweist und eine Mehrzahl von Speichergeräten, wobei die Datenflussverwaltungsmaschine konfiguriert ist, um ein Verfahren nach den Ansprüchen 1-7 auszuführen.
System, das einen oder mehrere Speicherträger aufweist, auf welchen einzeln oder in Kombination Anweisungen gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, in der Ausführung eines Verfahrens nach den Ansprüchen 1-7 resultieren.