DE112008001682B4

DE112008001682B4 - Speicherbereichsnetzwerk mit Erkennung auf der Zielseite und dem Hochladen einer Routing- Tabelle

Info

Publication number: DE112008001682B4
Application number: DE112008001682.8T
Authority: DE
Inventors: Daniel E. Suman; Eric R. Schott; Lazarus J. Vekiarides; Neil A. Swinton
Original assignee: Dell Products LP
Current assignee: Dell Products LP
Priority date: 2007-06-25
Filing date: 2008-06-25
Publication date: 2022-01-05
Anticipated expiration: 2028-06-26
Also published as: US8447860B2; BRPI0813883A2; WO2009002514A2; CN101821725B; WO2009002514A3; DE112008001682T5; GB2462787A; CN101821725A; GB2462787B; GB0922445D0; US20090019157A1

Abstract

Ein vernetztes System von Datenprozessoren zum Bereitstellen von Zugriff auf eine gemeinsame Ressource, aufweisend:einen Client-Datenprozessor, von dem Anfragen für einen Zugriff auf eine Ressource ausgehen, wobei der Client (12) eine Mehrpfad-Eingabe/Ausgabefunktionalität, MPIO, aufweist und wobei der Client (12) auf Anfrage Information bereitstellt, die die Ressourcen-Objekte betrifft, die die MPIO Funktionalität verwenden; undeine Mehrzahl von Server-Datenprozessoren, auf denen die Ressource partitioniert ist, wobei zumindest ein Server (16) MPIO-Objekt Information von dem Client (12) empfängt und wobei er zumindest eine Server-Information an den Client (12) zurückgibt, betreffend eine Gruppe von Verbindungen, die der Client (12) verwenden kann, um auf die Ressource Zugriff zu erhalten;wobei die Ressource ein partitioniertes Datenlaufwerk ist;wobei der Client (12) ein iSCSI-Initiator ist und wobei die Server (16) iSCSI-Ziele sind;wobei die Information, die von dem iSCSI-Initiator-Client an den iSCSI-Ziel-Server übertragen wird, mehrere Verbindungen identifiziert als Verbindungen, die zu einem speziellen MPIO-Datenlaufwerk gehören; undwobei ein Verteiler der Verbindungsbelastung auf den iSCSI-Ziel-Servern die identifizierten mehrfachen Verbindungen behandelt als Verbindungen, die miteinander in Beziehung stehen und die jeweils einer unterschiedlichen Netzwerkschnittstelle, NIC, in den iSCSI-Speicher-Servern zugewiesen werden.

Description

VERWANDTE ANMELDUNG(EN)
Die Anmeldung beansprucht die Priorität der U.S. Provisionalanmeldung Nr. 60937,058 , die am 25.06.2007 eingereicht worden ist. Die gesamte Lehre der obigen Anmeldung(en) wird hiermit durch Referenz mit aufgenommen.
HINTERGRUND DER ERFINDUNG
Die Erfindung betrifft vernetzte Datenspeicherung und insbesondere eine Zielseitenerkennung und das Update einer Host-Page-Routing-Tabelle, angepasst zur Verwendung mit Multi-Path Input Output (MPIO) oder ähnlichen Protokollen.
In dem Maße wie Computer-Anwender sich immer mehr auf den Zugriff auf entfernt gespeicherte Information verlassen, wie z.B. Datenbanken, Web-Anwendungen, E-Commerce, Online-Transaktionsverarbeitung und Ähnliches, nimmt die Menge an entfernt lokalisierter Information, die verwaltet und gespeichert werden muss, zu. Die Verwaltung dieser Information führt dauerhaft zu Herausforderungen an die Administratoren von Informationssystemen.
Obwohl Standard-Platten-Server durchaus in der Lage sind, Daten zu speichern, ist ihre Kapazität begrenzt. Sie können auch zu einem Flaschenhals werden, wenn zu viele Anwender gleichzeitig versuchen, auf dasselbe Speichergerät zuzugreifen. Ein traditioneller Ansatz für die Lösung dieses Problems liegt darin, eine große Anzahl von Speichergeräten mit einem einzigen Netzwerk-Server zu verbinden. Ein Netzwerk-Administrator kann dann eine „Farm“ solcher Server für eine gegebene Anwendung erzeugen.
In dem Maße jedoch, in dem die Größe von Server-Farmen zunimmt und Firmen sich mehr und mehr auf datenintensive Anwendungen verlassen, ist jedoch auch dieses Speichermodell nicht mehr vollkommen nützlich. Vor kurzem hat eine Anzahl von Herstellern zusammengearbeitet, um die sogenannte Speicherbereich-Netzwerk-Technologie (SAN-Technologie) zu entwickeln. SANs stellen mehr Optionen zur Netzwerkspeicherung bereit, einschließlich eines deutlich schnelleren Zugriffs als Peripheriegeräte, die als netzwerkverbundene Speicher (Network Attached Storage, NAS) betrieben werden. SANs stellen darüber hinaus die Flexibilität bereit, separate Netzwerke zu erzeugen, um große Datenmengen zu verarbeiten.
Ein SAN ist ein Netzwerk für einen speziellen Zweck mit hoher Geschwindigkeit, das verschiedene Arten von Speichergeräten mit zugeordneten Daten-Servern im Auftrag eines größeren Netzwerks von Anwendern verbindet. Ein SAN kann in unmittelbarer Nähe zu anderen Computer-Ressourcen geclustert werden, es kann sich aber auch an entfernte Orte erstrecken unter Verwendung von Wide-Area-Netzwerk-Technologien, wie z.B. Asynchronous Transfer Mode (ATM), Fiber Channel, Internet Small Computer Systems Interface (ISCSI), etc..
SANs unterstützen typischerweise das Spiegeln von Festplatten, Back-up und die Wiederherstellung, Archivierung und das Auffinden von archivierten Daten, die Daten-Migration von einem Speichergerät auf ein anderes und das Aufteilen von Daten unter verschiedenen Servern. SANs können ebenfalls Unternetzwerke innerhalb des angeschlossenen Speicherbereichssystems umfassen.
Bestimmte Verbesserungen sind für SANs entwickelt worden, so wie sie beispielsweise in der U.S. Patentanmeldung mit der Nr. 2004/0143637 beschrieben sind, mit dem Titel „Adaptive Storage Block Data Distribution“, die hiermit in ihrer Gesamtheit durch Referenz mit aufgenommen wird. Dieses Design ermöglicht dem Administrator eines Speicherbereichsnetzwerks zu kontrollieren, wie Daten gespeichert und verwaltet werden, ohne ein Gateway zu benötigen, um den gesamten hereinkommenden Anfrageverkehr zu überwachen. Die spezifischen Systeme, die in dieser Patentanmeldung beschrieben sind, ermöglichen beispielsweise Block-Level-Datenspeicherdienste in einer iSCSI-Umgebung. Solch ein Dienst kann verwendet werden, um den zur Verfügung stehenden Datenspeicher über eine Vielzahl von äquivalenten Servern (die in der „iSCSI“-Terminologie auch „Targets“ genannt werden), zu partitionieren. Jeder der äquivalenten Server stellt eine gleiche Schnittstelle für einen Client bereit (die in der iSCSI-Terminologie als „Initiatoren“ bezeichnet werden), und jeder äquivalente Server präsentiert dieselbe Antwort auf dieselbe Anfrage vom Client. Jeder Server kann daher mit anderen Servern kommunizieren, um sich wechselseitig zu benachrichtigen, wenn die Verantwortung für bestimmte Datenblöcke von einem Server zu einem anderen Server verschoben wird.
Um ein Verständnis für den Ort von verschiedenen Datenblöcken über verschiedene Partitionen und über verschiedene Plattenlaufwerke, die von dem Datenblockspeichersystem unterhalten werden, aufrechtzuerhalten, hält jeder äquivalente Server eine Routing-Tabelle aufrecht. Zu diesem Zweck führt jeder äquivalente Server einen Routing-Tabellen-Prozess aus, der die unterschiedlichen Datenblöcke nachverfolgt, die in dem Datenblockspeichersystem gespeichert werden und den jeweiligen äquivalenten Server, der für jeden Datenblock verantwortlich ist. Veränderungen an der Routing-Tabelle können über den Routing-Tabellen-Prozess mitgeteilt werden. Da sich der Ort der Datenblöcke im Laufe der Zeit ändern kann, müssen Routing-Tabellen insbesondere aktualisiert werden, um diese Veränderungen widerzuspiegeln.
In diesem System zeigt die Routing-Tabelle somit, welcher Teil eines gegebenen Laufwerks bzw. Volumens (welche Seite) auf welchem Server vorhanden ist; jeder der Server wird als ein Mitglied einer speziellen Gruppe von Servern betrachtet. Die Routing-Tabellen enthalten jedoch nicht notwendigerweise alle Mitglieder einer Gruppe, und das Nachverfolgen der Gruppenmitgliedschaft ist keine Funktion der Routing-Tabellen.
„MIPO“, so wie es in bestimmten Versionen von Microsoft™ Windows implementiert ist, hat sich jüngst als eine Lösung erwiesen, um höhere Verfügbarkeit und höhere Leistungsfähigkeit in der Verbindung zu einem Speicherbereich bereitzustellen, wobei sogenannte Multipfad-I/O-Protokolle verwendet werden.
Multipfad Eingabe/Ausgabe (Multi-Path Input/Output, MPIO) bezeichnet die Konfiguration eines Servers, eines Netzwerks und eines Speichers, die mehrere physikalische Verbindungen zwischen einem Hostcomputer und einem Zielspeicherfeld ermöglicht. Der Vorteil dieser Konfiguration ist die erhöhte Verfügbarkeit über mehrere redundante Kommunikationspfade und die verbesserte Leistungsfähigkeit, indem alle zur Verfügung stehenden Pfade simultan verfügbar gemacht werden.
Unter Verwendung von MPIO können Speicherfelder mehrere Netzwerkverbindungen unterstützen und Netzwerke können konfiguriert werden, um mehrere physikalische Verbindungen zu unterstützen. Host-Systeme können ferner mehrere Initiator-Prozesse aufweisen. MPIO kann in verschiedenen Standard-Betriebssystem-Konfigurationen arbeiten, wie z.B. alleinstehenden Systemen und Clustern.
Die Implementierung von MPIO ist jedoch etwas komplex da Mehr-Pfad-Software-Initiatoren, Netzwerkelemente und Speicherfeld-Software zusammenarbeiten müssen um eine robuste Lösung bereitzustellen. Fehler in irgendeiner Komponente können dazu führen, dass die Lösungen die Anforderungen an die hohe Verfügbarkeit, die schnelle Wiederherstellung und den Hochleistungsbetrieb nicht erfüllen.
MPIO-Lösungen sind historisch so implementiert worden, dass jeder Speicherfeld-Hersteller eine individuelle Software-Lösung hat. Dies erzeugt Schwierigkeiten beim Konfigurations-Management durch den Endanwender für den Fall, dass der Endanwender verschiedene Lösungen verwenden möchte.
Microsoft hat vor Kurzem sein eigenes Mehrfach-Pfad-Eingabe/Ausgabe-Framework zur Verwendung innerhalb vom Windows Umgebungen entwickelt. Die Microsoft MPIO Architektur ermöglicht, dass sich mehrere Speichersysteme die gleiche MPIO Lösung teilen können. Dieses Framework ermöglicht beispielsweise, dass mehrere physikalische Geräte-Objekte miteinander verbunden werden, um ein einziges funktionales Geräte-Objekt zu bilden, das als „MPIO Festplatte“ bezeichnet wird. Dieses Framework verlangt jedoch, dass Speicher-Hersteller ein Geräte-spezifisches Modul (Device Specific Module, DSM) für jedes Produkt erzeugen, um physikalische Objekte als ein einziges funktionales Objekt zu „beanspruchen“.
In einer Standard MPIO-Lösung ist der Server (das „iSCSI target“) in der Lage, solche MPIO-Plattenstrukturen zu erkennen. Dies wird dadurch unterstützt, dass das DSM iSCSI-Portnamen ändern kann, wobei beispielsweise Herstellerspezifische SCSI op Codes verwendet werden, so dass alle Verbindungen einer MPIO-Platte denselben iSCSI-Portnamen verwenden. Allerdings gehen selbst mit diesem Ansatz mindestens einige Probleme einher:

1. Diese Information alleine kann nicht verwendet werden, um ein Load-Balancing unter mehreren physikalischen Verbindungen bereitzustellen. Es ist daher nicht möglich, Verbindungen von einer einzelnen MPIO-Platte über alle Laufwerks-Mitglieder zu verteilen; ebenso ist es nicht möglich, zwei Verbindungen an derselben Schnittstelle eines einzigen Laufwerk-Mitglieds zu lokalisieren. Mit anderen Worten kann ein Versuch des Load-Balancings eine Situation, in der man idealerweise den Satz von Verbindungen über andere zur Verfügung stehende Laufwerke verteilen würde, nicht berücksichtigen. Im Fall eines Netzwerk-Ausfalls könnten mehrere Verbindungen auf einem gemeinsamen physikalischen Pfad angeordnet sein, der ausgefallen ist, wobei dieser Pfad jedoch nicht gelöscht werden kann. Es wäre besser, die zur Verfügung stehenden Verbindungen unabhängig voneinander über alle zur Verfügung stehenden physikalischen Pfade zu verteilen.
2. Darüber hinaus empfängt das Standard-DSM nicht immer eine Benachrichtigung vom MPIO-Prozess einer höheren Ebene, dass erneut eine iSCSI-Verbindung hergestellt worden ist. In diesem Szenario wird die iSCSI-Reservierung nicht korrekt funktionieren. Dies bedeutet, dass die Cluster ebenfalls nicht korrekt arbeiten.

US 2006 / 0 277 383 A1 offenbart ein über ein Netzwerk verteiltes Speichersystem, das die Fähigkeit bereitstellt, Informationen an mehreren Netzwerk-Speicher-Servern zu senden und gespeicherte Informationen von diesem zu empfangen unter Verwendung von iSCSI Befehlen. Ein Speicher-Server-System umfasst zumindest zwei Datenspeicher-Server, die ein oder mehrere logische Datenträger umfassen. Ein Host-Computer empfängt einen Speicherbefehl von einer Host-Applikation und bestimmt einen oder mehrere Speicher-Server, die Informationen aufweisen, um den Speicherbefehl zu komplettieren. Der Host-Computer erzeugt einen oder mehrere iSCSI Netzwerkbefehle, um den Speicherbefehl auszuführen und überträgt die iSCSI Netzwerkbefehle direkt an jeden Datenspeicher-Server, der die benötigten Informationen aufweist. Die Speicher-Server empfangen die iSCSI Netzwerkbefehle und geben eine Antwort an den Host. Der Host und die Speicher-Server verifizieren die Konfiguration des Speichernetzwerks und sind in der Lage - falls notwendig - die Konfiguration zu korrigieren oder zu aktualisieren.
US 2005 / 0 283 545 A1 offenbart ein Verfahren zur Handhabung von Daten durch eine TCP Offload Engine. Die TCP Offload Engine kann angepasst werden zum Durchführen von SCSI Schreib-Operationen und kann das Empfangen eines iSCSI Schreibbefehls von einem iSCSI Port-Treibers umfassen. Zumindest ein Zwischenspeicher kann zur Handhabung der Daten, die mit dem empfangenen iSCSI Schreibbefehl von dem iSCSI Port-Treiber assoziiert sind, allokiert werden. Der empfangene iSCSI Schreibbefehl kann in zumindest ein TCP Segment formatiert werden. Eine Anfrage zum Übertragen eines (R2T, request to transmit) Signals kann von dem Target an den Initiator kommuniziert werden. Die Schreib-Daten können ohne kopiert zu werden von dem zumindest einen allokierten Zwischenspeicher in einem Server an den Initiator übertragen werden. Ein Hashwert kann berechnet werden, der an das TCP Segment angehängt von dem Initiator an das Target übertragen werden kann.
US 2004 / 0 215 792 A1 offenbart Systeme und Verfahren zur Bereitstellung eines effizienten partitionierten Ressourcen-Servers. In einer Ausführungsform umfasst der partitionierte Ressourcenserver eine Vielzahl von einzelnen Servern, und die einzelnen Server erscheinen als Äquivalent zu einem Client. Jeder der einzelnen Server kann eine Routing-Tabelle enthalten, die eine Referenz für jede Ressource enthält, die auf dem partitionierten Ressourcenserver gepflegt wird. Anfragen von einem Client werden in Abhängigkeit von der Routing-Tabelle verarbeitet, um die Anfrage an den individuellen Server zu leiten, der die betreffende Ressource verwaltet oder die Kontrolle darüber hat.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung wird durch den unabhängigen Systemanspruch 1 bzw. durch den unabhängigen Verfahrensanspruch 8 definiert. Weiter bevorzugte erfindungsgemäße Ausführungsformen werden in den abhängigen Ansprüchen definiert. Im Folgenden werden einige Aspekte beschrieben, die zum Verständnis der vorliegenden Erfindung beitragen.
Die hier beschriebenen Vorrichtungen und Verfahren umfassen Datenbetriebssysteme, die Anfragen für eine Vielzahl von Clients zum Zugriff auf einen Satz von Ressourcen verwalten. In einem Ausführungsbeispiel umfassen die Systeme eine Vielzahl von Servern, wobei der Satz von Ressourcen über die Vielzahl von Servern partitioniert wird. Die Server führen einen Prozess zur Belastungsüberwachung aus, der in der Lage ist, mit anderen Prozessen zur Belastungsüberwachung zu kommunizieren, um ein Maß der Client-Belastung auf dem gesamten System und der Client-Belastung auf jedem entsprechenden Server zu erzeugen. Die Server tauschen ferner zur Verfügung stehende Pfad-Informationen mit den Client-Prozessen aus. Genauer gesagt stellt ein Client-Prozess für den Server-Prozess ferner Information bezüglich denjenigen Verbindungen bereit, welche Mehr-Pfad-Objekte bedienen, so dass der Server diese Information berücksichtigen kann, wenn er Pfad-Information zurück an die Clients liefert.
In einem bevorzugten Ausführungsbeispiel, so wie es beispielsweise in einem Speicherbereich-Netzwerk implementiert wird, das iSCSI und Mircosoft MPIObasierte Netzwerk-Kommunikationsprotokolle verwendet, umfasst dies im Allgemeinen:

(a) auf der Ziel-Seite (Server), die Berücksichtigung von MPIO-Plattenstrukturen, beispielsweise indem die Zielseite über die MPIO-Plattenstruktur-Information über ein iSCSI-Session-Objekt informiert wird, das durch eine Service-Handlung gesetzt werden kann; und/oder
(b) das Hochladen von Routing-Tabellen von der iSCSI-Ziel-Seite an die iSCSI-Initiator-Seite, beispielsweise zu einem Geräte-spezifischen Modul (Device Specific Module, DSM) auf der iSCSI-Initiator-Seite.

In bevorzugten Ausführungsbeispielen können Implementierungen femer umfassen:

(1) Die Anfrage, dass die Inhalte der Routing-Tabelle von den Speicherservern der iSCSI-Ziel-Seite an die iSCSI-Initiatoren bereitgestellt werden und die Verwendung dieser als einer der Faktoren, welche die Pfad-Auswahl beeinflussen, so wie es auf der Initiator-Seite in dem MPIO-DSM durchgeführt wird und/oder
(2) das Übertragen von dem iSCSI-Initiator an den Speicher-Server des iSCSI-Ziels von Information, die Verbindungen identifiziert, die zu derselben MPIO-Platte gehören und umgekehrt das Empfangen von Information vom Speicher-Server des iSCSI-Ziels über die Verbindungen, die erzeugt werden sollen, und ferner die Verwendung dieser Verbindungen durch den Verbindungs-Load-Balancer auf den Speicher-Server als verwandte Verbindungen, die jeweils einem unterschiedlichen Netzwerk-Interface (NIC) auf den Speicher-Servern zugeordnet werden müssen.

Weitere Implementierungs-Details und Vorteile dieser Merkmale werden nachfolgend diskutiert.
Figurenliste
Das Vorangegangene erkennt man aus der folgenden genaueren Beschreibung beispielhafter Ausführungsbeispiele der Erfindung so wie sie in den beigefügten Figuren dargestellt sind. Übereinstimmende Bezugszeichen betreffen gleiche Teile über verschiedene Darstellungen hinweg. Die Zeichnungen sind nicht notwendigerweise maßstabsgerecht. Die Betonung liegt stattdessen auf der Erläuterung von Ausführungsbeispielen der vorliegenden Erfindung.

1 ist ein High-Level-Diagramm eines Speicherbereich-Netzwerks mit MPIO-Fähigkeiten, in dem die Erfindung implementiert werden kann.
2 erläutert mehr im Detail den Prozess auf der Zielseite, der mit dem Netzwerk aus 1 verwendet wird.
3 erläutert eine Routing-Tabelle.
4 erläutert die Schritte, die von einem Client auf der Initiator-Seite durchgeführt werden.
5 erläutert eine Sequenz von Schritten, die von dem Server auf der Zielseite durchgeführt werden.
6 erläutert die Behandlung mehrerer Verbindungen.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es folgt eine Beschreibung eines beispielhaften Ausführungsbeispiels der Erfindung.
I. EINLEITUNG
1 erläutert ein beispielhaftes System, in dem die Erfindung implementiert werden kann. Im Allgemeinen kann das System ein Speicherbereich-Netzwerk (SAN) sein, so wie es beispielsweise in der US-Patentveröffentlichung 2004/0030755 mit dem Titel „Transparent Request Routing for a Partitioned Application Server“ beschrieben ist, die am 12. August 2003 von Koning et al. eingereicht worden ist; der US-Patentveröffentlichung 2004/0143637 mit dem Titel „Adaptive Storage Block Data Distribution“ die am 20. Januar 2003 von Koning et al. eingereicht worden ist und/oder die US-Patentveröffentlichung 2004/0215792 mit dem Titel „Client Load Distribution“, die am 21. Januar 2004 von Koning et al. eingereicht worden ist. Jede dieser Veröffentlichungen wird hiermit durch Referenz in ihrer Gesamtheit mit aufgenommen.
Unter besonderer Bezugnahme auf 1 sind einer oder mehrere Clients 12-1, 12-2, ...12-c (die gemeinsam als die Clients 12 bezeichnet werden) über ein Netzwerk 14 wie z.B. das Internet, ein Intranet, ein Wide Area Network (WAN) oder ein Local Area Network (LAN) oder über irgendeine andere Verbindung mit Servers 16-1, 16-2, 16-3... 16-c verbunden, die Teil einer Servergruppe 16 sind.
Die Clients 12 können irgendwelche geeigneten Datenverarbeitungssysteme, wie z.B. ein Personalcomputer (PC), eine Workstation, ein tragbares Computergerät, ein drahtloses Kommunikationsgerät oder irgendein anderes Gerät dieser Art sein, welches mit einem Netzwerk-Client-Prozess ausgerüstet ist, der in der Lage ist, auf die Servergruppe 16 zuzugreifen und mit ihr zusammenzuwirken, um Informationen mit der Servergruppe 16 auszutauschen. Der Netzwerk-Client 12 kann irgendeine Client-Anwendung sein, die es dem Anwender ermöglicht, Daten mit dem Server auszutauschen.
Vorzugsweise werden mehrere Netzwerk-Schnittstellen für jeden Client 12 und Server 16 bereitgestellt, so dass mehrere Kommunikationspfade 20-p zwischen ihnen existieren; diese Mehrfach-Pfade werden detaillierter weiter unten beschrieben.
Die Clients 12 und die Servergruppe 16 können unsichere Kommunikationspfade verwenden, um auf Dienste bei der entfernten Servergruppe 16 zuzugreifen. Um bei solch einer Anwendung Sicherheit hinzuzufügen können die Clients und die Server irgendeinen bekannten Sicherheitsgruppen-Mechanismus verwenden, so wie z.B. den Netscape Secured Socket Layer (SSL).
In einem bevorzugten Ausführungsbeispiel verwenden die Hosts und die Ziele Speichernetzwerkskommunikationsprotokolle, vorzugsweise iSCSI, das auf TCP/IP läuft, das mehrere Kommunikationspfade 20-P unterstützt. Daher umfasst jeder Client 12 vorzugsweise auch einen Mehrfachpfadprozess, so wie beispielsweise Microsoft-Mehrpfad-Eingabe-Ausgabe (Multi-Path Input OutPut, MPIO) 42, einen gerätespezifischen Modulprozess (Device Specific Module, DSM) 44, einen iSCSI Initiatorprozess 46 und einen Netzwerkstapel, so wie er von einer oder mehreren TCP/IP Netzwerkschnittstellen (NICs) 48-1... bis 48-m bereitgestellt wird. Die Clients 12 werden hier manchmal auch als iSCSI-Initiatoren bezeichnet und die Server werden manchmal auch als iSCSI-Ziele bezeichnet.
Jeder Server 16-1, 16-12 und 16-3 kann eine kommerziell erhältliche Server-Plattform umfassen, wie z.B. ein Sun Sparc System, auf dem eine Version des Unix Betriebssystems läuft. Jeder Server 16 kann ferner andere Software-Komponenten umfassen, die ihren Betrieb erweitern, um die folgenden Transaktionen durchzuführen, und die Architektur der Server kann je nach der Anwendung variieren.
Beispielsweise kann jeder Server 16 eingebaute Erweiterungen enthalten, auf die typischerweise als Module Bezug genommen wird, um zu ermöglichen, dass die Server 16 die nachfolgend beschriebenen Operationen durchführen. Ferner können die Server 16 Zugriff auf ein Verzeichnis von ausführbaren Dateien haben, von denen jede dazu verwendet werden kann, die Operationen durchzuführen oder Teile der nachfolgend beschriebenen Operationen. Bestimmte der für die vorliegende Erfindung interessanten Module, sowie in 1 dargestellt, sind ein iSCI-Zielprozess 28-3, und eines oder mehrere TCP/IP-Netzwerk-Schnittstellen-Module (NICs) 26-3.
In anderen Ausführungsbeispielen können die Server 16-1, 16-2 und 16-3 eine Software-Architektur verwenden, die bestimmte der unten beschriebenen Prozesse in das Betriebssystem des Servers einbindet, in einen Gerätetreiber oder in einen Software-Prozess, der auf einem Peripherie-Gerät arbeitet, wie z.B. eine Bandbibliothek, ein RAID-Speichersystem oder irgendein anderes Gerät. In jedem Fall versteht es sich für den Fachmann, dass die hier beschriebenen Systeme und Verfahren durch eine Vielzahl verschiedener Ausführungsbeispiele und Praktiken realisiert werden können und dass das spezielle Ausführungsbeispiel und die spezielle Praxis in Abhängigkeit von der interessierenden Anwendung variieren werden kann, und dass sämtliche dieser Ausführungsbeispiele und Praktiken in den Schutzbereich fallen.
Im Betrieb müssen die Clients 12 auf die Ressourcen zugreifen, die über die Server-Gruppe 16 partitioniert worden sind. Dementsprechend wird jeder der Clients 12 Anfragen an die Server-Gruppe 16 schicken. Bei einem typischen Betrieb wird einer der Clients 12-2 einen der Server - beispielsweise den Server 16-2 - in der Gruppe 16 kontaktieren, um auf eine Ressource zuzugreifen, wie z.B. einen Datenblock, eine Seite, eine Datei, eine Datenbank, eine Anwendung oder eine andere Ressource. Der kontaktierte Server 16-2 selbst hat möglicherweise keine Kontrolle über die gesamte angefragte Ressource. Zu diesem Zweck ist die Server-Gruppe 16 konfiguriert, um die partitionierten Ressourcen dem Client 12 zur Verfügung zu stellen. Zur Erläuterung zeigt das Diagramm zwei Ressourcen, eine Ressource 18, die über alle drei Server partitioniert worden ist, die Server 16-1, 16-2 und 16-3, und eine weitere Ressource 17, die nur über zwei Server partitioniert worden ist, die Server 16-1 und 16-2. In der beispielhaften Anwendung der Server-Gruppe 16, die ein Blockdatenspeichersystem ist, kann jede Ressource 17 und 18 ein partitioniertes Blockdatenlaufwerk sein. Die Ressourcen, die über mehrere Server 16 verteilt sind, können Verzeichnisse sein, Dateien innerhalb eines Verzeichnisses oder sogar Blöcke innerhalb einer Datei.
Andere partitionierte Dienste sind ebenfalls vorstellbar. Beispielsweise ist es möglich, eine Datenbank in analoger Weise zu partitionieren, um ein verteiltes Dateisystem bereitzustellen oder einen verteilten oder partitionierten Server, der Anwendungen unterstützt, die über das Internet geliefert werden. Im Allgemeinen kann der Ansatz auf irgendeinen Dienst angewendet werden, wobei eine Client-Anfrage als eine Anfrage nach einem Teil der Gesamtressource interpretiert wird und Vorgänge auf diesen Teilen keine globale Koordination unter allen Teilen verlangen.
In dem Ausführungsbeispiel aus 1 stellt die Server-Gruppe 16 einen Blockdatenspeicherdienst bereit, der als ein Speicherbereichnetzwerk (SAN) arbeiten kann, das eine Vielzahl äquivalenter Server umfasst, die Server 16-1, 16-2 und 16-3. Jeder der Server 16-1, 16-2 und 16-3 kann einen oder mehrere Teile der partitionierten Blockdatenlaufwerke 18 und 17 unterstützen. In dem dargestellten System 10 gibt es zwei Datenlaufwerke und drei Server. Es gibt jedoch keine spezifische Grenze für die Anzahl der Server. In ähnlicher Weise gibt es keine spezifische Grenze für die Anzahl der Ressourcen oder der Datenlaufwerke. Darüber hinaus kann jedes Datenlaufwerk vollständig auf einem einzigen Server enthalten sein oder es ist partitioniert über mehrere Server, entweder alle der Server in der Server-Gruppe oder eine Teilmenge der Server-Gruppe. In der Praxis gibt es jedoch Grenzen aufgrund von Implementierungsüberlegungen, beispielsweise der Menge an Speicher, die in den Servern 16-1, 16- und 16-3 zur Verfügung steht oder Grenzen der Rechenleistung der Server 16-1, 16-2 und 16-3. Darüber hinaus kann das Gruppieren selbst, d.h. die Entscheidung, aus welchen Servern die Gruppe 16 aufgebaut wird, in einem Ausführungsbeispiel eine administrative Entscheidung umfassen. In einem typischen Szenario könnte eine Gruppe zunächst nur wenige Server, beispielsweise nur einen, umfassen. Das System würde Server zu einer Gruppe hinzufügen, so wie sie gebraucht werden, um das gewünschte Service-Niveau zu erreichen. Die Zunahme der Server erzeugt mehr Raum (Speicher, Laufwerkspeicher) für Ressourcen, die gespeichert werden, mehr CPU-Verarbeitungskapazität, um auf Client-Anfragen zu reagieren und mehr Netzwerkkapazität (Netzwerkschnittstellen), um die Anfragen und Antworten von den Clients zu übertragen. Es versteht sich für den Fachmann, dass die hier beschriebenen Systeme leicht skaliert werden können, um gestiegene Client-Anforderungen zu adressieren, indem zusätzliche Server in die Gruppe 16 mit aufgenommen werden.
II. LASTVERTEILUNG IM ALLGEMEINEN
Die Clients arbeiten typischerweise unabhängig, so dass die Clientbelastung auf die Servergruppe 16 sich im Laufe der Zeit verändert. Wenn die Client-Anfrage nach Zugriff auf die Ressourcen sich verändert, kann das System die Client-Belastung erneut verteilen, um die zur Verfügung stehenden Ressourcen in der Server-Gruppe 16 besser zu nutzen. Zu diesem Zweck umfasst das System 10 in einem Ausführungsbeispiel eine Mehrzahl von äquivalenten Servern. Wenn die Client-Anfragen an die äquivalenten Server geliefert werden, findet eine Koordination zwischen den äquivalenten Servern statt, um ein Maß für die Systembelastung zu erzeugen und um ein Maß für die Client-Belastung auf jedem der äquivalenten Server zu erzeugen. Vorzugsweise wird diese Koordination so durchgeführt, dass sie für die Clients 12 so transparent ist, so dass die Clients 12 nur die Anfragen und die Antworten sehen, die zwischen den Clients 12 und der Server-Gruppe 16 ausgetauscht werden.
In einem bevorzugten Ausführungsbeispiel sieht ein gegebener Client 12, der sich mit einem speziellen Server 16-1 verbindet, die Ressourcen, die von der gesamten Server-Gruppe 16 verwaltet werden, so als ob die Gruppe einen einzelnen Server 16-1 bilden würde. Der Client 12 weiß nicht, dass die Server-Gruppe 16 tatsächlich aus einer möglicherweise großen Anzahlt von Servern 16-1, 16-2, ... 16-s aufgebaut ist, noch, dass die Blockdatenlaufwerke 17 und 18 über mehrere Server 16-1, 16-2, ... 16-s partitioniert sind. Im Ergebnis kann die genaue Anzahl der Server und die Art, in der die Ressourcen über die Server 16 partitioniert werden, verändert werden, ohne die Netzwerkumgebung, die vom Client 12 gesehen wird, zu beeinflussen.
Unter weiterer Bezugnahme auf 1 kann in der partitionierten Server-Gruppe 16 jedes Laufwerk über eine Anzahl von Servern innerhalb der Gruppe 16 verteilt sein. In dem o.g. Beispiel wird ein Laufwerk 17 (Ressource 1) über zwei Server 16-1, 16-2 verteilt, wohingegen ein anderes Laufwerk 18 (Ressource 2) über drei Server 16-1, 16-2, 16-3 verteilt ist. Vorzugsweise sind die entsprechenden Laufwerke in Gruppen von Blöcken fester Größe angeordnet, die auch als „Seiten“ bezeichnet werden, wobei eine beispielhafte Seite 8192 Blöcke enthält. Andere geeignete Seitengrößen können ebenfalls verwendet werden.
Jeder Server in der Gruppe 16 enthält vorzugsweise eine entsprechende Routing-Tabelle 15 für jedes Laufwerk, wobei die Routing-Tabelle 15 den Server identifiziert, auf dem eine spezifische Seite eines spezifischen Laufwerks gefunden werden kann. Wenn beispielsweise der Server 16-1 eine Anfrage von einem Client 12 nach einem partitionierten „Laufwerk 18, Block 93847“ empfängt, berechnet der Server 16-1 die Seitenzahlen (die Seitennummer 11 in diesem Beispiel für eine Seitengröße von 8192), indem er die angefragte Blocknummer durch die Seitengröße dividiert und schaut in seiner entsprechenden Routing-Tabelle 15-1 die Nummer des Servers nach, der die angeforderte Seitennummer 11 enthält. Wenn der Server 16-3 die Seitennummer 11 enthält, wird die Anfrage an den Server 16-3 weitergeleitet, der die Daten liest und die Daten an den Server 16-1 zurückgibt. Der Server 16-1 sendet daraufhin die angefragten Daten an den Client 12. In anderen Worten wird die Antwort an den Client 12 immer über denselben Server 16-1 zurückgegeben, der die Anfrage vom Client 12 erhalten hat. Es ist daher für den Client 12 transparent, mit welchem Server 16-1, 16-2 und 16-3 er tatsächlich verbunden ist. Stattdessen „sieht“ der Client nur die Server-Gruppe 16 und fragt Ressourcen von der Server-Gruppe 16 ab.
Es versteht sich hierbei, dass das Routen der Client-Anfragen für jede Anfrage unabhängig durchgeführt wird. Dies ermöglicht, dass Teile einer Ressource bei unterschiedlichen Servern existieren. Es ermöglicht ferner Ressourcen oder Teilen davon, verschoben zu werden, während der Client mit der Server-Gruppe 16 verbunden ist. Um dies zu erreichen, werden die Routing-Tabellen 15-1, 15-2, 15-3, ... 15-s wie erforderlich aktualisiert und nachfolgende Client-Anfragen werden an den neuen Server weitergeleitet, der nunmehr für die Bearbeitung der Anfrage verantwortlich ist.
Zumindest für eine gegebene Ressource 17 sind die Routing-Tabellen 15 identisch. Beispielsweise sind die Einträge in den Routing-Tabellen 15-1 und 15-2 für die Server 16-1 und 16-2 identisch für die Ressource 17.
Das System unterscheidet sich daher von einem „Redirect“-Mechanismus, in dem ein Server 16 feststellt, dass er nicht in der Lage ist, eine Anfrage eines Clients zu bearbeiten und den Client an den Server verweist, der dazu in der Lage ist. Der Client müsste dann eine neue Verbindung zu einem anderen Server aufbauen. Da das Aufbauen einer Verbindung vergleichsweise ineffizient ist, ist ein Redirect-Mechanismus für die Bearbeitung von häufigen Anfragen schlecht geeignet. Wie in 1 gezeigt, umfasst ein beispielhafter Server 16-3 auch eine oder mehrere Netzwerkschnittstellen ((Network-Interfaces NICs) 26-3-1, 26-3-2, ... 26-3-q, einen iSCSI-Zielprozess 28-3, einen Anfragebearbeitungsprozess 40-3, einen Belastungsmonitorprozess 22-3, einen Client Distribution Process 30-3. Der Anfragebearbeitungsprozess 40-3 behandelt Client-Anfragen an die partitionierte Umgebung des Servers 16, indem überprüft wird, ob die angefragte Ressource am anfänglichen Server vorhanden ist, der die Anfrage von dem Client-Server erhalten hat. Der Anfragebearbeitungsprozess überprüft darauf hin seine Routing-Tabelle 15-3, um festzustellen, auf welchem Server die angefragte Ressource angeordnet ist. Wenn die angefragte Ressource auf dem anfänglichen Server 16-3 vorhanden ist, gibt der anfängliche Server 16-3 die angefragte Ressource an den Client 12. Wenn umgekehrt die angefragte Ressource bei dem anfänglichen Server 16-3 nicht vorhanden ist, wird der Anfangsserver Daten von seiner Routing-Tabelle 15-3 verwenden, um festzustellen, welcher Server gegenwärtig die Ressourcen enthält, die vom Client angefragt werden. Die Anfrage wird dann an den Server weitergeleitet, der die angefragte Ressource aufweist, welcher daraufhin die angefragte Ressource an den Anfangsserver zurückgibt. Der Prozess 40-3 zum Bearbeiten von Anfragen veranlasst daraufhin den anfänglichen Server, die angefragte Ressource an den Client 12 weiterzuleiten.
2 zeigt detaillierter ein besonderes Ausführungsbeispiel eines Blockdatenservicesystems 10. Genauer ausgedrückt, zeigt 2 ein System 10, in dem der Client 12 mit der Server-Gruppe 16 kommuniziert. Die Server-Gruppe 16 umfasst drei Server, die Server 16-1, 16-2 und 16-3. Jeder Server umfasst eine Routing-Tabelle, die als die Routing-Tabellen 15-1, 15-2 und 15-3 dargestellt sind (welche den Routing-Tabellen 15 in 1 entsprechen). Zusätzlich zu den Routing-Tabellen enthält jeder der äquivalenten Server 16-1, 16-2 und 16-3 einen Belastungsmonitorprozess 22-1, 22-2 bzw. 22-3.
Jeder der Server 16-1, 16-2 und 16-3 kommuniziert mit andern Servern der entsprechenden Gruppe 16, so dass es gemeinsame Routing-Tabellen 15-1, 15-2 und 15-3 gibt. Wie oben beschrieben, zeigen die Routing-Tabellen 15, welche der individuellen äquivalenten Server für eine jeweilige Ressource verantwortlich sind, die von der Server-Gruppe 16 bereitgehalten wird. In dem gezeigten Ausführungsbeispiel kann die Server-Gruppe 16 ein SAN oder Teil eines SAN sein, wobei jeder der äquivalenten Server 16-1, 16-2 und 16-3 eine individuelle IP-Adresse hat, die von einem Client 12 verwendet werden kann, um auf den jeweiligen äquivalenten Server des SAN zuzugreifen.
Wie weiter oben beschrieben, ist jeder der äquivalenten Server 16-1, 16-2 und 16-3 in der Lage, dieselbe Antwort auf dieselbe Anfrage von einem Client 12 bereitzustellen. Dazu erfolgt eine Koordination der Routing-Tabellen der individuellen äquivalenten Server 16-1, 16-2 und 16-3 untereinander, um eine globale Datenbank der unterschiedlichen Ressourcen bereitzustellen. In beispielhaften Ausführungsbeispielen umfassen die Server Datenblöcke, Seiten oder andere Organisationen von Datenblöcken und die individuellen äquivalenten Server, die für die entsprechenden Datenblöcke, Seiten, Dateien oder andere Speicherorganisationen verantwortlich sind.
3 zeigt eine beispielhafte Routing-Tabelle 15. Jede Routing-Tabelle 15 der Server-Gruppe 16, wie z.B. die Tabelle 15-1, umfasst einen Identifizierer (Server ID) für jeden der äquivalenten Server 16-1, 16-2 und 16-3, der den partitionierten Datenblockspeicherdienst unterstützt. Zusätzlich umfasst jede Routing-Tabelle 15 Information, die diejenigen Datenblöcke und Seiten identifiziert, die jedem der entsprechenden äquivalenten Server zugeordnet sind. In dem Ausführungsbeispiel aus 3 unterstützen die äquivalenten Server zwei partitionierte Laufwerke. Ein erstes Laufwerk, das Laufwerk 18, wird verteilt oder partitioniert über alle drei äquivalenten Server 16-1, 16-2 und 16-3. Das zweite partitionierte Laufwerk, das Laufwerk 17, wird über zwei der äquivalenten Server partitioniert, nämlich die Server 16-2 und 16-3.
Die Routing-Tabellen 15 können vom System 10 verwendet werden, um die Client-Belastung über die zur Verfügung stehenden Server zu verteilen. Insbesondere beobachten die Prozesse 22-1, 22-2 und 22-3 zur Lastüberwachung jeweils Anfragemuster, die an ihren entsprechenden äquivalenten Servern ankommen, um festzustellen, welche Muster oder Anfragen von den Clients 12 an das SAN weitergeleitet werden und ob diese Muster effizienter oder zuverlässiger durch eine geänderte Anordnung der Client-Verbindungen zu den mehreren Servern bedient werden können. In einem Ausführungsbeispiel überwachen die Prozesse 22-1, 22-2 und 22-3 zur Belastungsüberwachung Anfragen, die zu den entsprechenden äquivalenten Servern kommen.
In einem Ausführungsbeispiel baut jeder der Prozesse 22 zur Belastungsüberwachung eine Tabelle, die die verschiedenen Anfragen darstellt, die von dem individuellen Prozess zur Anfrageüberwachung gesehen worden sind. Jeder der Prozesse 22-1, 22-2 und 22-3 zur Belastungsüberwachung ist in der Lage, mit den anderen zu kommunizieren, um eine globale Datenbasis der Anfragen aufzubauen, die von jedem der äquivalenten Servern gesehen wird. Dementsprechend ist in diesem Ausführungsbeispiel jeder der Prozesse zur Belastungsüberwachung in der Lage, Anfragedaten von jedem der äquivalenten Server 16-1, 16-2 und 16-3 zu integrieren, um eine globale Anfragedatenbank zu erzeugen, die für den Anfrageverkehr repräsentativ ist, der von dem gesamten Blockdatenspeichersystem 10 gesehen wird. In einem Ausführungsbeispiel wird diese globale Anfragedatenbank dem Client-Verteilungsprozess 30-1, 30-2 und 30-3 zur Verfügung gestellt zur Verwendung bei der Festlegung, ob eine effizientere oder zuverlässigere Anordnung der Client-Verbindungen zur Verfügung steht.
2 zeigt ferner, dass die Server-Gruppe 16 in der Lage sein kann, die Client-Belastung umzuverteilen, indem der Client 12-3, der ursprünglich mit dem Server 16-1 verbunden war (und mit ihm kommuniziert hat), umverteilt wird an den Server 16-2. Zu diesem Zweck zeigt 2 einen Ausgangszustand, in dem der Server 16-1 mit den Clients 12-1, 12-2 und 12-3 kommuniziert. Dies ist durch bidirektionale Pfeile dargestellt, die den Server 16-1 mit den entsprechenden Clients 12-1, 12-2 und 12-3 verbinden. Ferner ist in einem Anfangszustand dargestellt, dass die Clients 12-4 und 12E mit dem Server 16-3 kommunizieren und dass kein Client (während des Anfangszustandes) mit dem Server 16-2 kommuniziert. Dementsprechend bedient der Server 16-1 während dieses Anfangszustandes Anfragen von drei Clients, den Clients 12-1, 12-2 und 12-3. Der Server 16-2 bedient oder antwortet auf Anfragen von keinem der Clients.
Dementsprechend könnte die Server-Gruppe 16 feststellen, dass in diesem Anfangszustand der Server 16-1 überlastet ist. Diese Feststellung könnte sich aus der Analyse ergeben, dass der Server 16-1 im Vergleich zu seinen Fähigkeiten zu stark genutzt wird. Beispielsweise könnte es sein, dass der Server 16-1 Speichergrenzen hat, und dass die von den Clients 12-1, 12-2 und 12-3 erzeugten Anfragen die dem Server 16-1 zur Verfügung stehenden Speichermittel überlasten. Der Server 16-1 könnte daher auf die Client-Anfragen mit einem Leistungsniveau antworten, das unterhalb einer akzeptablen Grenze liegt. Alternativ könnte festgestellt werden, dass der Server 16-1, obwohl er eine hinreichende Leistungsfähigkeit hat und das Antworten auf Client-Anfragen mit einem akzeptablen Niveau durchführt, im Hinblick auf die Client-Überlastung (oder Bandbreite), die vom Server 16-2 getragen wird, überbelastet ist. Dementsprechend könnte der Client-Verteilungsprozess30 der Server-Gruppe 16 die Entscheidung treffen, dass die Gesamteffizienz verbessert werden könnte, indem die Client-Belastung von ihrem Anfangszustand umverteilt wird zu einem Zustand, in dem der Server 16-2 Anfragen des Client 12-3 bedient.
Die Überlegungen, die die Entscheidung zur Belastungsverteilung der Verbindung bestimmen, können variieren. Ein Beispiel kann der Wunsch sein, das Routen zu verringern: Wenn beispielsweise ein Server das Ziel eines signifikant größeren Anteils von Anfragen ist als andere, auf denen Teile der Ressourcen (beispielsweise des Laufwerks) angeordnet sind, kann es vorteilhaft sein, die Verbindung auf diesen Server zu verschieben. Ein weiteres Beispiel kann darin liegen, die Kommunikationsbelastung für einen Server auszugleichen: Wenn die gesamte Kommunikationsbelastung auf einem Server substantiell größer ist als diejenige auf irgendeinem anderen Server, kann es sinnvoll sein, einige der Verbindungen von dem hoch belasteten Server zu einem gering belasteten Server zu verschieben und die Ressourcenzugriffsbelastung (beispielsweise die Festplatte I/O-Belastung) auszugleichen - ebenso wie in dem vorangegangenen Beispiel, jedoch für die Platten-Eingabe/Ausgabe-Belastung anstelle der Kommunikationsbelastung. Dies ist ein Optimierungsvorgang, der verschiedene Dimensionen umfasst und die spezifischen Entscheidungen für einen gegebenen Satz von Messungen kann von Verwaltungsstrategien, historischen Daten über Client-Aktivität, die Fähigkeit der verschiedenen Server und Netzwerkkomponenten, etc., abhängen.
Zu diesem Zweck zeigt 2 die Umverteilung von Client-Belastung, indem eine Verbindung 325 erläutert wird (die durch einen gepunkteten bidirektionalen Pfeil dargestellt ist) zwischen dem Client 12-3 und dem Server 16-2. Es versteht sich, dass nach der Verteilung der Client-Belastung der Kommunikationspfad zwischen dem Client 12-3 und dem Server 16-1 beendet sein kann.
Das Verteilen der Client-Belastung kann auch auf neue Verbindungen von neuen Clients angewendet werden. Wenn ein Client 12-6 feststellt, dass er einen Zugriff auf die Ressourcen benötigt, die von der Server-Gruppe 16 bereitgestellt werden, erzeugt er eine anfängliche Verbindung zu dieser Gruppe 16. Diese Verbindung endet an einem der Server 16-1, 16-2 und 16-3. Da die Gruppe als ein Einzelsystem gegenüber dem Client erscheint, hat der Client keine Kenntnisse vom Unterschied zwischen den Adressen für die Server 16-1, 16-2 und 16-3. Die Auswahl des Verbindungsendpunktes kann daher zufällig, zyklisch oder fest sein und ist unabhängig von den gegenwärtigen Belastungsmustern auf den Servern in der Gruppe 16.
Wenn diese anfängliche Client-Verbindung empfangen wird, kann der empfangende Server zu diesem Zeitpunkt eine Entscheidung über das Verteilen der Client-Belastung treffen. Wenn dies erfolgt, kann das Ergebnis sein, dass ein geeigneter Server als Endpunkt für die neue Verbindung ausgewählt wird und die Client-Verbindung wird entsprechend verschoben. Die Entscheidung zur Lastverteilung kann in diesem Fall basieren auf dem allgemeinen Belastungsniveau bei den verschiedenen Servern, der spezifischen Kategorie von Ressource, die von dem Client 12-6 angefragt wird, wenn er die Verbindung erzeugt, historische Daten, die den Einrichtungen zur Belastungsüberwachung in der Server-Gruppe 16 zur Verfügung stehen und die früheren Zugriffsmuster des Servers 12-6 betreffen, Strategieeinstellungen, die vom Administrator der Server-Gruppe 16 festgelegt worden sind, etc..
Eine weitere Überlegung bei der Verwaltung anfänglicher Client-Verbindungen ist die Verteilung der angefragten Ressource. Wie früher ausgeführt, kann eine gegebene Ressource über eine geeignete Untergruppe der Servergruppe verteilt sein. In diesem Fall kann es sein, dass der zunächst vom Client 12-6 für die Verbindung ausgewählte Server keinen Teil der angefragten Ressource bedient. Obwohl es möglich ist, solch eine Verbindung anzunehmen, ist es keine besonders effiziente Anordnung, da in diesem Fall alle Anfragen vom Client, nicht nur ein Teil davon, weitergeleitet werden müssen. Aus diesem Grund ist es nützlich, einen Server für die ursprüngliche Client-Verbindung auszuwählen, der innerhalb der Teilmenge der Server in der Servergruppe 16 ist, die tatsächlich zumindest einen Teil der Ressourcen bedienen, die vom neuen Client 12-6 angefragt wird.
Diese Entscheidung kann effizienter gestaltet werden durch das Einführen einer zweiten Routing Datenbank. Die erste Routing Datenbank 15, die oben beschrieben worden ist, spezifiziert den genauen Ort jedes separat verfügbaren Teils der Ressource von Interesse. Kopien dieser ersten Routing Datenbank müssen jedem Server zur Verfügung stehen, der das Ende einer Client-Verbindung bildet, auf welcher dieser Client Zugriff auf die fragliche Ressource anfragt. Die zweite Routing Datenbank zum „Verteilen der Verbindung“ gibt für eine gegebene Ressource (in ihrer Gesamtheit) einfach an, welche Server der Servergruppe 16 gegenwärtig einen Teil dieser Ressource bereitstellen. Beispielsweise besteht eine Routing Datenbank zum Verteilen einer Verbindung, welche die Ressourcenanordnung aus 1 beschreibt, aus zwei Einträgen: einer für die Ressource 17, welcher die Server 16-2 und 16-3 auflistet, und einer für die Ressource 18, welcher die Server 16-1, 16-2 und 16-3 auflistet. Die Server, die an dem Laufwerk teilnehmen, haben die gesamte Routing Tabelle für dieses Laufwerk, wie in 3 gezeigt, während nicht teilnehmende Server nur den Endabschnitt der dargestellten Routing Tabelle aufweisen. Bei einem Partitionieren der beiden Laufwerke, wie in 1 dargestellt, bedeutet dies, dass der Server 16-1 die in 3 gezeigte Tabelle am Ende links aufweist und beide Tabellen auf der rechten Seite der Figur während die Server 16-1 und 16-2 mit allen vier Tabellen dargestellt sind.
III. VERTEILEN DER VERBINDUNGSBELASTUNG MIT EINER MPIO-ERKENNUNG AUF DER ZIELSEITE UND DEM HOCHLADEN EINER ROUTING TABELLE
Wie bereits zuvor in Verbindung mit 1 erwähnt, kann der Client 12 vorzugsweise ein iSCSI-kompatibler Host 40 sein, auf dem Microsoft's MPIO 42 läuft, ein DSM 44 und ein iSCSI-Initiatorprozess 46. MPIO-Lösungen verwenden redundante physikalische Netzwerk-Komponenten, wie z.B. mehrere Netzwerk-Schnittstellen 26, Kabel und Switches zum Erzeugen von mehreren logischen und physikalischen Pfaden zwischen jedem Client 12 (Host) und den Servern (Speichergeräten) 16. Beispielsweise kann ein gegebener Server 16-3 tatsächlich drei NICs 26-3-1, 26-3-2 und 26-3-3 aufweisen. Zusätzlich zur Verwendung für weitere Lastverteilung kann die durch das MPIO-Modul 42 implementierte Logik für den Fall, dass eine oder mehrere Komponenten ausfallen, so dass der Pfad ausfällt, einen anderen Eingabe/Ausgabe-Pfad verwenden, so dass die Anwendungen immer noch auf ihre Daten zugreifen können. Mehrere physikalische Netzwerkverbindungen 20-1, 20-2...20-n werden daher zwischen einem gegebenen Host 40 (auf dem Client 12-1) und einem gegebenen Server 16-2 bereitgestellt.
Die zusätzlichen Verbindungen können in einer sicheren Umgebung auf verschiedene Weisen bereitgestellt werden. In einem bevorzugten Ausführungsbeispiel kann dies erfolgen unter Verwendung eines Diffie-Hellman (DH) Algorithmus, wodurch die Notwendigkeit zur Verwaltung von Host-Passwörtern und Ähnlichem vermieden wird. Beispielsweise werden zusätzliche Verbindungen als sichere Kanäle installiert unter der Verwendung bekannter DH-Protokolle in IPsec, sobald der Anwender sich einloggt unter Verwendung Host-seitiger Sicherheitsprotokolle. Eine ideale Lösung für Routing Anfragen verteilt daher die Anfragen auch über die verfügbaren mehrfachen MPIO-Verbindungen.
I. Zielseitige Erkennung von MPIO-Platten
Es ist wünschenswert eine Verbesserung früherer MPIO-Lösungen bereitzustellen, indem ein Sitzungsobjekt (bzw. Session Object) in einen Prozess eingefügt wird, der auf einem iSCSI-Initiator 12 abläuft. Das Session Object kann Identifizierer für MPIO-Strukturen für die iSCSI-Ziele 16 übertragen.
In einem Ausführungsbeispiel können die MPIO-Identifizierer gesetzt werden durch eine neue Service-Handlung eines iSCSI-herstellerspezifischen op Codes.
In einem bevorzugten Ausführungsbeispiel kann das Informieren der Zielseite der MPIO-Plattenstruktur die Kooperation zwischen verschiedenen Modulen auf dem Client (iSCSI-Initiator) 12, wie z.B. dem Kernel DSM 44 und einem spezifischen Windows Dienst (EHCM 49) und anderen Modulen auf dem Server (iSCSI-Ziel 16), insbesondere ein Teil eines Verbindungsbelastungs-Verteilers (Connection Load Balancer, CLB) 33 des Prozesses 30-3 zur Client-Verteilung umfassen. Insbesondere wird ein Dialog zwischen dem Host-EHCM-Prozess und dem CLB in dem Ziel hergestellt. Das Ziel muss daher nicht automatisch MPIO-Plattenstrukturen „erkennen“, sondern wird vorzugsweise speziell für die Existenz von MPIO-Plattenstrukturen informiert. In einem Ausführungsbeispiel kann dies wie folgt durchgeführt werden.
Das EHCM-Servermodul 49 im Client sendet eine Job-Anfrage:
(IOCTL_EQLDSM_EHCM_WORK_RQST ioctl) an den DSM 44 auf dem Host. Die Antwort verrät dem EHCM 49, welche Art von Job angefragt wird. Zusammen mit jeder Antwort auf eine Job-Anfrage kann der DSM-Kernel auch die Zeit zurückgeben, zu welcher der EHCM die nächste Anfrage senden soll.
Zwei Jobs auf der Client-Seite sind hier relevant:
EqlDsmIoctlJob::CONNECTION_SETUP und
EqlDsmIoctlJob::TABLE_UPLOAD;
die beide nachfolgend im Detail in Zusammenhang mit 4 beschrieben werden.
EqlDsmIoctlJob::CONNECTION_SETUP
Schritt 401: Zusätzliche MPIO- und iSCSI-Information wird aus verschiedenen Quellen des Anwender-Raums erhalten.
Schritt 402: Die Verwendung einer speziellen Service-Handlung eines Herstellerspezifischen op Codes (wie z.B. der op Code 20h) führt dazu, dass die notwendigen Korrekturen an der DSM-Endpunkt-Information durchgeführt werden (beispielsweise wenn iSCSI eine Verbindung verschoben hat).
Schritt 403: Die gesamte Information wird daraufhin an das Ziel 16 gesandt (den CLB 33).
Schritt 404: Das Ziel 16 bestimmt eine optimale MPIO-Konfiguration und sendet seine Empfehlung zurück an den Client 12.
Schritt 405: Der EHCM 49 (der sich natürlich im Anwender-Raum des Clients 12 befindet) entfernt Verbindungen und fügt diese hinzu, wie erforderlich.
EqlDsmIoctlJob::TABLE _UPLOAD
Schritt 410: Eine Anfrage für das Hochladen einer Tabelle wird an das Ziel übertragen.
Schritt 411: Korrekturen werden daraufhin an der DSM-Endpunkt-Information wie benötigt durchgeführt (so wie oben).
Schritt 412: Die gesamte Routing Tabelle wird daraufhin gelesen (beispielsweise in Stücken zu 64 KB).
Schritt 413: Die Routing Tabelle wird auf das DSM 44 heruntergeladen unter Verwendung des ioctol
IOCTL_EQLDSM_ROUTING_TABELLE_UPLOAD.
5 erläutert im Detail den entsprechenden Antwortprozess auf der Zielseite, welcher die TCP/IP Endpunkte der Verbindungen zurückgeben soll, die von dem Client iSCSI-Initiator verwendet werden sollen. Ausgelöst durch eine Service-Handlung eines herstellerspezifischen op Codes wird in einem ersten Schritt 500 bestimmt, welche Server 16 einen Teil der angefragten Ressource beinhalten, beispielsweise durch die Abfrage der Routing-Tabelle(n) 15. Als nächstes wird im Schritt 502 festgestellt, welche NICs 26-3 tatsächlich auf den entsprechenden Servern 16 vorhanden sind. In Schritt 504 werden diejenigen NICs, die gegenwärtig nicht arbeiten oder nicht für die Zuweisung an den fraglichen Initiator (gemäß dem CLB-Prozess 33-3) zur Verfügung stehen, aus der Liste ausgelassen. Schließlich wird im Schritt 406 die resultierende Liste an den Initiator 12 zurückgegeben.
Die Rückgabe einer Liste von Verbindungen (TCP/IP-Adresspaare), die erzeugt werden sollen, impliziert für den Initiator 12, dass jegliche andere existierende Verbindung beendet werden soll.
Auf diese Art wird der Initiator 12 über erlaubte Verbindungsinformation informiert, ohne dass er über die Information in den Tabellen 15 informiert werden muss, die die Server 16 untereinander verwenden. Der Initiator 12 kann daraufhin jeglichen Algorithmus (beispielsweise round robin, geringste Länge der Warteschlange, geringste Latenz, etc.) verwenden, der geeignet ist, die Verbindungen, die ihm mitgeteilt worden sind, zu verwalten.
6 zeigt das Ergebnis. Hier kann ein gegebener iSCSI-Initiator 12 nunmehr vier (4) physikalische NICs verwenden, ohne weitere Details der zur Verfügung stehenden drei (3) Server in der Gruppe 16 auf dem sSCSI-Target zu kennen, die jeweils drei (3) verfügbare NICs haben für eine Gesamtheit von neun (9) physikalische Verbindungen. Der MPIO-Prozess beim Initiator 12 kann nun einfach die Last unter diesen zur Verfügung stehenden Verbindungen, die ihm mitgeteilt worden sind, verteilen.
Es versteht sich nunmehr, dass die folgenden Vorteile durch diese Implementierung bereitgestellt werden.

1. Information über MPIO-Platten kann nunmehr von der Komponente zur Verteilung der Verbindungsbelastung (CLB 33) verwendet werden, welche logisch eine Funktion der Gruppe 16 ist. Wenn daher der Verbindungsvorgang den Netzwerkprotokollstapel 26 auf jedem gegebenen Speicher-Server 16 nach Information fragt, kann er Paare zurückgeben [Verbindung, MPIO-Identifizierer]. Da der EHCM 49 nun die MPIO-Konfigurationsinformation direkt an den CLB 33 überträgt, muss dem Rest des Systems die MPIO-Identifiziererinformation nicht bekannt sein. Mit andern Worten weiß der Verteiler für die Verbindungsbelastung auch, dass eine Gruppe von Verbindungen miteinander verwandt ist und dass sie für mehrere zur Verfügung stehende physikalische Verbindungen 20 verteilt werden sollen, die voneinander entfernt sind. Dies kann implementiert werden, indem die Verbindungen so erzeugt werden, dass sie zu verschiedenen Speicherfeldern laufen (unterschiedlichen Servern 16), oder zu verschiedenen NICs 26, die einen gegebenen Server 16 bedienen.
2. Wenn eine Verbindung von einem Initiator 12 geschlossen wird, kann er jetzt eine andere Sitzung informieren, die der gleichen MPIO-Platte entspricht und diese Sitzungen können eine herstellerspezifische Prüfbedingung zurück an das DSM 44 geben. Das DSM 44 bekommt damit eine zuverlässige Benachrichtigung für seine Verbindungsveränderungen.

II. Hochladen der Routing-Tabelle
Das DSM-Modell, so wie es in Microsofts MPIO spezifiziert worden ist, ermöglicht einem Hardwarehersteller, eine gerätespezifische Lastverteilung durchzuführen. Beim Stand der Technik kann dies beispielsweise dazu führen, dass ein iSCSI-Befehl an den am wenigsten beschäftigten NIC 26 geroutet wird. In diesem Fall besteht eine Möglichkeit darin, Befehle direkt an den Server 16 zu routen, wo die angefragten Daten sich befinden, anstatt die iSCSI-Zielseite (d.h. die Server 16) dazu zu zwingen, das Routen so wie oben beschrieben untereinander durchzuführen.
Dieser Ansatz verlangt das Hochladen einer Routing-Tabelle an den DSM-Prozess 44 im Host, vorzugsweise auf Verlangen des DSM 44. Dies kann periodisch sein oder jedes Mal, wenn Veränderungen durchgeführt werden. Dies ist ein kostengünstiger Vorgang, weil die Routing-Tabelle typischerweise sehr klein ist. Mit diesem Ansatz ist es nicht erforderlich, dass der DSM 44 tatsächlich die Verbindung verteilt, da er nicht die notwendige schnittstellenbezogene Information hat. Der DSM 44 kann nunmehr zumindest so viele Verbindungen erzeugen, wie es Laufwerkmitglieder gibt. Es ist daher immer möglich, clientseitig zu routen, aber den besten Endpunkt auf der Zielseite zu bestimmen.
Sobald eine Verbindung erzeugt worden ist, kann der DSM 44 eine Service-Handlung verwenden (einen herstellerspezifischen op Code 20h und eine Service-Handlung 03h, wie unten beschrieben), um die Situation zu bewerten. Dies kann jedoch ein Routen auf der Zielseite umfassen. Es kann Überlegungen zum Verteilen der Last oder Netzwerküberlegungen, d.h. Sub-Netzwerküberlegungen, geben, die wichtiger sind, als alles Routen auf dem Client 12 durchzuführen.
Die neue Zielfunktionalität kann implementiert werden als neue Service-Handlung für herstellerspezifischen SCSI op Code 20h, so wie er vom Initiator (DSM 44) an die iSCSI-Ziele gesandt wird. Die neue Zielfunktionalität kann daher drei op Code Service-Handlungen 20h wie folgt definieren:

 Enum SCSI_VENDOR_SPECIFIC_20_SERVICE_ACTIONS {
 EQLCDB_SA_GET_PAGE_TABLES=0, /* Lesen der Sitzungsseitentabellen */
 EQLCDB_SA_SET_MPIO_ID=1, /* Payload is binär uuid */
 EQLCDB_S_GET_TCPIP_INFO=2, /* Lesen der Host/Ziel tcp/ip port information */
 };

ZUWEISUNGEN FÜR SERVICE-HANDLUNGEN

A. Service-Handlung 0

Dies ist die Standard-Service-Handlung, die für den op Code 20h implementiert wird. Sie sendet eine Nachricht an den Laufwerksführer mit der Mitteilung einer Namensveränderung und aktualisiert daraufhin den Sitzungs-iSCSI-Port-Namen. Diese Service-Handlung kann unverändert bleiben für eine Abwärtskompatibilität, obwohl sie nicht weiter verwendet wird.

B. Service-Handlung 1

In Antwort auf diese Service-Handlung werden die folgenden Handlungen durchgeführt:

1. Information betreffend die Verbindungen, für die ein besonderes MPIO-Objekt verwendet wird, wird an das Ziel gesandt. Sie kann als eine Liste von Verbindungen versandt werden. In einer optionalen Konfiguration kann jedoch anstelle der Bereitstellung solch einer Liste ein global eindeutiger Identifizierer (GUID) definiert werden und nachfolgend für jedes MPIO-Objekt verwendet werden.
2. Die Standard-Service-Handlung 0 ist daraufhin Laufen (run). Dies bringt das Senden einer Nachricht an den Laufwerksführer mit sich, damit er seine Tabellen aktualisieren kann, so dass irgendwelche Reservierungen, die bereits von dieser Sitzung gehalten werden, nicht verwaisen.

C. Service-Handlung 2

Diese Service-Handlung hat ebenfalls keine Eingabe-Parameter. Die Antwortdaten sind die Routing-Tabelle. In einem Ausführungsbeispiel kann dies eine Nachricht sein, die mit einem Header beginnt, der die Anzahl der Laufwerksseiten angibt, die Laufwerksmitglieder und den Speicherfeldidentifizierer von jedem Laufwerksmitglied, wobei dem Header Bit-Felder für jedes Laufwerkmitglied folgen. Andere Formate sind jedoch ebenfalls möglich.

D. Service-Handlung 3

Diese Service-Handlung hat keine Eingabe. Sie gibt einen universellen Speicherfeldidentifizierer (UUID) des Laufwerksmitglieds zurück, an dem die Verbindung endet.

Darüber hinaus werden ferner die folgenden zwei Anfrage/Antwort-Nachrichten ebenfalls zwischen den Prozessen bereitgestellt:

CDHKeyExchReq / CDHKeyExchRsp; und
CHostConnectionReconfigurationReq /
CHostConnectionReconfigurationRsp

Das erste dieser Nachrichtenpaare wird verwendet, um dynamisch temporäre Sicherheit/Login-Beglaubigungen (security/login credentials, CHAP) zu erzeugen, die dazu verwendet werden, um in einer sicheren Weise die anfängliche iSCSI Verbindung zu „klonen“, die direkt vom Anwender erzeugt worden ist (unter Verwendung des Diffie-Hellman-Algorithmus, wie oben erläutert).

Das zweite der Nachrichtenpaare betrifft, wie der Host MPIO-Konfigurationsinformation an das Ziel überträgt (d.h. an den CLB-Prozess 33), und daraufhin Anweisungen empfängt, wie das MPIO-Verbindungsgitter optimal eingestellt wird.

Durch das Senden der aktualisierten Routing-Tabellen an den Host kann der Host DSM 44 daraufhin Routing-Überlegungen berücksichtigen, wenn er eine Pfadauswahl durchführt.

Femer informiert dieser Vorgang den Host 12 über die Anzahl der Speicher-Server 16, die an der Bereitstellung des Laufwerks 17 oder 18 teilnehmen (dies ist Teil der Routing-Daten). Dies ermöglicht dem Host 12, zumindest eine gleiche Anzahl Verbindungen zu öffnen. Wenn er das tut, erkennt die Speichergruppe, dass diese Verbindungen alle vom gleichen Host 12 kommen und kann sie nun über die Speicher-Server verteilen, anstatt einfach ein Verteilen der Verbindungsbelastung separat für jede Verbindung durchzuführen.

Insbesondere werden alle Verbindungen gekennzeichnet, dass sie zu der MPIO-Platte gehören, beispielsweise über die Information, die in der Service-Handlung 1 übertragen wird. Dies ermöglicht dem Verteiler 33, für die Verbindungsbelastung zu wissen, dass sie miteinander in Beziehung stehen, so dass er die Verteilung in anderer Weise vornehmen kann als er es sonst tun würde. Normalerweise würde der Verteiler 33 für die Verbindungsleistung, wenn ihm eine Gruppe von Verbindungen präsentiert wird, jede Verbindung individuell anordnen, da er nicht weiß oder annimmt, dass es eine Beziehung zwischen den Verbindungen gibt. Im Ergebnis könnten, abhängig von dem gegenwärtigen Belastungsmuster in der Gruppe, mehrere Verbindungen sich Ressourcen teilen (wie z.B. die NICs eines Speicher-Servers).

Wenn jedoch der Verteiler 33 der Verbindungsbelastung eine Gruppe von Verbindungen behandelt, die sich alle auf eine einzige MPIO-Platte beziehen, kann er nunmehr vermeiden, sie derselben NIC zuzuweisen. Dies stellt sicher, dass mehrere MPIO-Verbindungen nicht tatsächlich einen gemeinsamen Pfad verwenden, was die Fehlertoleranz verhindern würde und die Verbesserung der Leistung, die MPIO erreichen gerade möchte. Dem MPIO-Client wird vom Speicherserver (durch den Verbindungsverteiler) mitgeteilt, wie viele Verbindungen er erzeugen soll, wobei Gesichtspunkte wie ausgefallene Schnittstellen berücksichtigt werden. Im Ergebnis sollte es normalerweise der Fall sein, dass der Client so viele Verbindungen öffnet, wie über die verfügbaren Schnittstellen verteilt können, und nicht mehr als das. Der Verteiler 33 für die Verbindungsbelastung kann in der Tat die Verbindungen in dieser Weise verteilen, da er weiß, dass sie sich alle auf die gleiche MPIO-Platte beziehen.

Claims

Ein vernetztes System von Datenprozessoren zum Bereitstellen von Zugriff auf eine gemeinsame Ressource, aufweisend: einen Client-Datenprozessor, von dem Anfragen für einen Zugriff auf eine Ressource ausgehen, wobei der Client (12) eine Mehrpfad-Eingabe/Ausgabefunktionalität, MPIO, aufweist und wobei der Client (12) auf Anfrage Information bereitstellt, die die Ressourcen-Objekte betrifft, die die MPIO Funktionalität verwenden; und eine Mehrzahl von Server-Datenprozessoren, auf denen die Ressource partitioniert ist, wobei zumindest ein Server (16) MPIO-Objekt Information von dem Client (12) empfängt und wobei er zumindest eine Server-Information an den Client (12) zurückgibt, betreffend eine Gruppe von Verbindungen, die der Client (12) verwenden kann, um auf die Ressource Zugriff zu erhalten; wobei die Ressource ein partitioniertes Datenlaufwerk ist; wobei der Client (12) ein iSCSI-Initiator ist und wobei die Server (16) iSCSI-Ziele sind; wobei die Information, die von dem iSCSI-Initiator-Client an den iSCSI-Ziel-Server übertragen wird, mehrere Verbindungen identifiziert als Verbindungen, die zu einem speziellen MPIO-Datenlaufwerk gehören; und wobei ein Verteiler der Verbindungsbelastung auf den iSCSI-Ziel-Servern die identifizierten mehrfachen Verbindungen behandelt als Verbindungen, die miteinander in Beziehung stehen und die jeweils einer unterschiedlichen Netzwerkschnittstelle, NIC, in den iSCSI-Speicher-Servern zugewiesen werden.
System nach Anspruch 1, wobei die MPIO-Information als ein Teil eines iSCSI-Sitzungsobjekts bereitgestellt wird.
System nach Anspruch 2, wobei die MPIO-Information als eine einstellbare Service-Handlung in dem iSCSI-Sitzungsobjekt bereitgestellt wird.
System nach Anspruch 1, wobei die MPIO-Objektinformation von einem Verteiler der Verbindungsbelastung in zumindest einem der Server (16) empfangen wird.
System nach Anspruch 1, wobei eine Routing-Tabelle, die definiert, welcher Server die Ressource enthält, von den Speicher-Servern der iSCSI-Zielseite zu dem iSCSI-Initiator-Client hochgeladen wird.
System nach Anspruch 5, wobei die Routing-Tabelle zu einem DSM-Modul in dem iSCSI-Initiator-Client hochgeladen wird.
System nach Anspruch 6, wobei die Routing-Tabelle verwendet wird, um eine Pfadauswahl zu bestimmen, die in dem DSM-Modul durchgeführt wird.
Verfahren zum Betreiben eines Server-Datenprozessors in einem Netzwerk von Servern, die Zugriff auf eine gemeinsame Ressource bereitstellen, aufweisend: Empfangen einer Anfrage für einen Zugriff auf die Ressource von einem Client-Datenprozessor; Empfangen von dem Client (12) Information betreffend Ressourcen-Objekte, die eine Mehrfachpfad-Eingabe/Ausgabe, MPIO,-Funktionalität verwenden; und Rückgabe an den Client (12) von Informationen betreffend eine Gruppe von Verbindungen, die der Client (12) verwenden kann, um Zugriff auf die Ressource von dem Server (16) zu erhalten; wobei die Ressource ein partitioniertes Datenlaufwerk ist; wobei der Client (12) ein iSCSI-Initiator ist und wobei die Server (16) iSCSI-Ziele sind; wobei die Ressourcen-Objektinformation, die von dem iSCI-Initiator-Client empfangen wird, mehrere Verbindungen identifiziert, die zu einem speziellen MPIO-Datenlaufwerk gehören; und ferner aufweisend: Behandeln der angegebenen mehreren Verbindungen als verwandte Verbindungen, die jeweils einem unterschiedlichen Netzwerk-Interface, NIC, zugeordnet werden.
Verfahren nach Anspruch 8, wobei die MPIO-Information als ein Teil eines iSCSI-Sitzungsobjekts bereitgestellt wird.
Verfahren nach Anspruch 9, wobei die MPIO-Information bereitgestellt wird als eine einstellbare Service-Handlung in dem iSCSI-Sitzungsobjekt.
Verfahren nach Anspruch 8, ferner aufweisend: Empfangen der MPIO-Objektinformation an einem Verteiler für die Verbindungsbelastung.
Verfahren nach Anspruch 8, ferner aufweisend: Hochladen einer Routing-Tabelle, die definiert, welcher Server die Ressource enthält, wobei die Routing-Tabelle zu dem iSCSI-Initiator-Client hochgeladen wird.
Verfahren nach Anspruch 12, wobei die Routing-Tabelle an ein DSM-Modul in dem iSCSI-Initiator-Client hochgeladen wird.