-
VERWANDTE ANMELDUNG(EN)
-
Die
Anmeldung beansprucht die Priorität der U.S. Provisionalanmeldung
Nr. 60(937,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 verbin den. 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 betrach tet. 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 MicrosoftTM 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 Cluster.
-
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.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
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 Server, 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 MPIO- basierte 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
ferner 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.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
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
Ap plication 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 Netz werkkapazitä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 Server. 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 Ser ver 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 Daten bank 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 indivi duellen 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 Server 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-Verteilungsprozess 30 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 Server 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:
EglDsmIoctlJob::CONNECTION_SETUP
und
EglDsmIoctlJob::TABLE_UPLOAD;
die beide nachfolgend
im Detail in Zusammenhang mit 4 beschrieben
werden.
EglDsmIoctlJob::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.
EglDsmIoctlJob::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:
-
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.
-
Ferner
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.
-
Obwohl
die Erfindung gezeigt und beschrieben worden ist mit Bezugnahme
auf exemplarische Ausführungsbeispiele, versteht es sich
für den Fachmann, dass zahlreiche Veränderungen
in Form und Details daran durchgeführt werden können,
ohne den Schutzbereich der Erfindung zu verlassen, wie er in den
nachfolgenden Ansprüchen angegeben ist.
-
ZUSAMMENFASSUNG
-
Ein
Netzwerk von Datenprozessoren zum Breitstellen von Zugriff auf eine
Ressource, beispielweise zur Implementierung eines Speicherbereichsnetzwerk,
das iSCSI und Microsoft MPIO-basierte Netzwerkprotokolle verwendet.
In bevorzugten Ausführungsformen verwendet das System oder
Verfahren (a) zielseitige Berücksichtigung der MPIO Plattenstrukturen,
beispielsweise indem iSCSI Initiatoren iSCSI Ziele über
ein iSCSI Sitzungsobjekt informieren, das durch eine Servicehandlung
eingestellt werden kann.; und/oder (b) Hochladen von Routingtabellen
von iSCSI Zielen zu iSCSI Initiator(en), beispielsweise zu einem
gerätespezifischen Modul (DSM). Implementierungen können
ferner in einem bevorzugten Ausführungsbeispiels umfassen:
(1) Anfragen nach der Bereitstellung der Inhalte der Routingtabellen
von den Speicherservern der iSCSI Zielseite an die iSCSI Initiatoren
und Verwenden dieser Information als ein Faktor, der die Pfadauswahl
beinflusst, die von dem MPIO DSM auf der Initiatorseite durchgeführt
wird; und/oder (2) Übertragen von Information von dem iSCSI
Initiator an den iSCSI Speicherserver, die Verbindungen identifiziert,
die zur selben MPIO Platte gehören und daraufhin Empfangen
zurück vom iSCSI Zielspeicherserver Information über
zu erzeugenden Verbindungen und daraufhin Verwalten dieser Verbindungen
durch einen Verteiler der Verbindungsbelastung als verwandte Verbindungen,
die jeweils verschiedenen Netzwerkschnittstellen (NIC) auf den Speicherservern
zugeordnet werden müssen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - US 2004/0030755 [0030]
- - US 2004/0143637 [0030]
- - US 2004/0215792 [0030]