DE60316466T2

DE60316466T2 - Unterstüzung von mehreren nativen netzwerkprotokollimplementiurungen in einem einzigen system

Info

Publication number: DE60316466T2
Application number: DE60316466T
Authority: DE
Inventors: Windsor Wee Sun c/o IBM Unit Winchester HSU; Jaishankar Moothedath San Jose MENON; Honesty Cheng Saratoga YOUNG
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-11-26
Filing date: 2003-10-15
Publication date: 2008-06-19
Anticipated expiration: 2023-10-16
Also published as: EP1566035B1; DE60316466D1; JP4521278B2; US7797392B2; KR100834361B1; KR20050071673A; CN1742472A; US20040103206A1; CN100544347C; WO2004049670A3; TWI251148B; EP1566035A2; AU2003278310A1; AU2003278310A8; ATE373918T1; WO2004049670A2; TW200421107A; JP2006507591A

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf verteilte Objektspeichersysteme, die in heterogenen Umgebungen verwendet werden. Im Besonderen bezieht sich diese Erfindung auf ein System und Verfahren, das Benutzern mit verschiedenen Netzwerkprotokollen den ursprünglichen Datenaustausch mit einem einzigen System ermöglicht, um einen Dienst abzurufen.
Hintergrund der Erfindung
Ein großes Unternehmen wie z. B. ein Unternehmen mit vielen Beschäftigten arbeitet üblicherweise mit einer Vielzahl von vernetzten Computern. Die Computer müssen ihre Daten auf eine Art und Weise speichern, die einen Zugriff von anderen Computern in dem Unternehmen aus ermöglicht. Meist wird dies erreicht, indem ein Dateisystem und Dateiserver verwendet und die gemeinsam genutzten Dateien in einem gemeinsamen Speichersystem gespeichert werden. Dateisystemclients verwenden ein klar definiertes Netzwerkdateiprotokoll, um Daten mit dem Dateiserver auszutauschen. Wenn eine Datei von einem Computer erzeugt wird, wird sie über einen Dateiserver auf die Festplatten geschrieben. Wenn diese Datei von demselben oder einem anderen Computer gelesen wird, werden die Daten von den Festplatten gelesen, durchlaufen den Dateiserver und werden anschließend dem Computer bereitgestellt, der den Zugriff auf die Datei angefordert hat.
Die auf Dateien zugreifenden Computer sind häufig unterschiedlicher Natur und können viele verschiedene Betriebssysteme wie AIX^®, Microsoft Windows^®, Solaris^®, HP-UX^® und Linux^® ausführen. Abhängig vom ausgeführten Betriebssystem verwenden sie unter Umständen unterschiedliche Protokolle für den Zugriff auf den Dateiserver. So verwenden Systeme mit Microsoft Windows^® in der Regel das CIFS-Protokoll (Common Internet File System), während Systeme, auf denen Unix^®-Varianten ausgeführt werden, häufig das NFS-Protokoll (Network File System) verwenden. Dabei benötigen jedoch alle gleichermaßen Zugriff auf dieselben Dateien. Selbst wenn sie auf unterschiedliche Gruppen von Dateien zugreifen, ist es sehr viel praktischer, wenn ein und derselbe Dateiserver verwendet werden kann.
Es gibt Versuche zum Aufbau eines Dateiservers, der in der Lage ist, verschiedene Netzwerkprotokolle zu "verstehen". Diese Systeme werden als NAS-Systeme (Network Attached Storage) bezeichnet. Allerdings setzt jedes NAS-System auf einem bestimmten Betriebssystem auf, das höchstens ein Original-Protokoll (native protocol) aufweist. Dabei werden CIFS-Server unter Microsoft Windows^® und der NFS-Server unter Linux^® (oder einer anderen Unix^®-Variante) als die "Original-" Ausführungen der betreffenden Protokolle betrachtet.
Aus diesem Grund muss das NAS-System die anderen Protokolle verarbeiten, indem es sie emuliert. So wurden beispielsweise emulierte CIFS- und NFS-Protokolle durch das NAS-Produkt von Network Appliance realisiert. Ursprüngliche CIFS- und emulierte NFS-Protokolle wurden durch das NAS 200-Produkt von IBM realisiert. Emulierte CIFS- und ursprüngliche NFS- Protokolle wurden vom Veritas ServPoint^®-System für NAS realisiert.
Im Allgemeinen sind emulierte Protokolle hinsichtlich Funktion und/oder Leistung nicht vollständig verträglich mit der Original-Ausführung, wodurch Schwierigkeiten bei Betrieb und Datenaustausch entstehen. Außerdem müssen für die Entwicklung des Emulatorprogramms Zeit und Arbeit aufgewendet werden, so dass bei der Einführung eines neuen Protokolls oder einer neuen Version eines bestehenden Protokolls die Unterstützung durch das NAS-System womöglich während einiger Zeit nicht gegeben ist, so sie denn überhaupt erreicht wird.
Eine Möglichkeit zur Lösung dieser Probleme besteht in der Verwendung eines heterogenen Dateisystems (Heterogeneous File System, HFS). Ein derartiges System gestattet die gemeinsame Dateinutzung durch verschiedenartige Systeme, so dass jeder seiner Dateisystemclients (HFS-Clients) auf alle Dateien zugreifen kann. Die HFS-Clients können unterschiedliche Betriebssysteme ausführen, wobei jedes über sein eigenes Original-Netzwerkprotokoll verfügt. Diese Clients können somit als Original-Server (native server) für ihre jeweiligen Protokolle dienen.
Dabei sind die HFS-Clients allerdings getrennte Systeme mit verschiedenen IP-Netzwerkadressen. Daher müsste ein Benutzer wissen, welches Protokoll sein Computer verwendet, welche Protokolle von den einzelnen HFS-Clients unterstützt werden, und müsste die Anforderung gezielt an den betreffenden HFS-Client richten. Dies wird noch dadurch erschwert, dass die Informationen zu den HFS-Clients sich ändern können, wenn HFS-Clients nicht mehr verfügbar sind oder aktualisiert bzw. ersetzt werden. Darüber hinaus ist mit einer unzureichenden Leistung zu rechnen, da das Durchlaufen des HFS-Client und anschließend des HFS-Server einen zusätzlichen Arbeitsschritt mit sich bringt.
Wenn zu viele Daten von einem einzigen Dateiserver verarbeitet werden müssen, sind außerdem mehrere Server erforderlich, und die Benutzer müssen wissen, auf welchem Dateiserver sich ihre Daten befinden. Wenn mehrere Server verwendet werden, lässt sich nur schwer eine gleichmäßige Auslastung dieser Server erzielen.
Aus diesem Grund wird ein System benötigt, das gegenüber den Benutzern als eine einzige Einheit erscheint (d. h. sich ihnen als ein einziges Systemabbild darstellt) und das in der Lage ist, alle Dienstanforderungen (d. h. Dateien) der Benutzer auf eine leistungsfähige und ursprüngliche Art und Weise zu verarbeiten, unabhängig von dem Protokoll, das die Benutzer verwenden, und unabhängig davon, wo sich ihre Dateien befinden. Für ein derartiges System besteht nach wie vor Bedarf. Ein Beispiel eines Speichersystems nach dem Stand der Technik kann WO 02/069166 entnommen werden.
Die vorliegende Erfindung entspricht diesem Bedarf und legt ein Verfahren, ein Computerprogrammprodukt und ein System gemäß den Nebenansprüchen vor.
Die vorliegende Erfindung verwendet als heterogenes Dateisystem vorzugsweise ein kürzlich entwickeltes Storage Tank^TM-System, wie es in "IBM Storage Tank^TM A Distributed Storage System", 25. Januar 2002, unter
<http://www.almaden.ibm.com/cs/storagesystems/stortank/ExtStorageTankPaper01_24_02.pdf> beschrieben wird.
Das System der vorliegenden Erfindung besteht vorzugsweise aus einem HFS, genauer gesagt einem Storage Tank^TM-System, und einem oder mehreren intelligenten Leitwegprogrammen. Die HFS-Clients fungieren als Original-Server für ihre jeweiligen Netzwerkprotokolle. So können der Microsoft Windows^®-HFS-Client und ein Linux^®-HFS-Client beispielsweise die Aufgabe eines CIFS- bzw. NFS-Servers übernehmen. Dabei sind die Microsoft Windows^®- und Linux^®-Clients allerdings getrennte Systeme mit unterschiedlichen IP-Netzwerkadressen. Ohne ein intelligentes Leitwegprogramm müsste ein Benutzer daher wissen, welches Protokoll sein Computer verwendet, welche Protokolle von den einzelnen HFS-Clients unterstützt werden, und er müsste dann die Anforderung gezielt an den betreffenden HFS-Client richten. Das intelligente Leitwegprogramm leitet den Benutzer automatisch an den richtigen HFS-Client weiter, ohne dass von Seiten des Benutzers ein Befehl oder ein Eingreifen notwendig ist. Das intelligente Leitwegprogramm leitet den Benutzer an denjenigen HFS-Client weiter, der mit hoher Wahrscheinlichkeit eine gute Leistung bietet.
Das intelligente Leitwegprogramm tritt gegenüber dem Benutzer vorzugsweise als eine einzige Einheit mit einer einzigen IP-Netzwerkadresse auf. Wenn das intelligente Leitwegprogramm eine Anforderung empfängt, überprüft es den Protokolltyp, z. B. CIFS oder NFS, und leitet die Anforderung an einen der geeigneten HFS-Clients weiter. Dabei leitet es eine CIFS-Anforderung an einen CIFS-Server und eine NFS-Anforderung an einen NFS-Server weiter.
Wie bereits beschrieben, kann bei diesem Ansatz ein Leistungsproblem auftreten, da sich auf dem Pfad zu den Daten ein zusätzlicher Server befindet und somit die Antwortzeit erhöht. Daher verwendet die Erfindung als HFS bevorzugt beispielsweise das Storage Tank^TM-System (im Folgenden als ST- oder Storage-Tank-System bezeichnet). Bei einem ST-System sind die HFS-Clients (ST-Clients) unter Verwendung eines Speichernetzwerks direkt mit den Speicherplatten verbunden. Über ein anderes Netzwerk sind sie außerdem mit einer Gruppe von Metadatenservern (ST-Servern) verbunden.
Das ST-Protokoll ist ein bevorzugtes Protokoll, das für den Datenaustausch zwischen ST-Clients und ST-Servern verwendet wird. Das Protokoll verwendet ein Sperr- und Datenkonsistenzmodell, das es dem verteilten Storage-Tank-Speichersystem gestattet, wie ein einziges Dateisystem auszusehen und sich entsprechend zu verhalten. Der ST-Client greift auf den ST-Server nur zu, um die Metadaten zu lesen und die Speicherstelle der relevanten Daten zu erfahren. Anhand der Informationen in den Metadaten greift der ST-Client direkt auf die Daten zu. Indem der Server aus dem Pfad zwischen dem ST-Client und den Daten entfernt wird, ist eine sehr viel schnellere und leistungsfähigere Datenübertragungsverbindung möglich.
Bei einer bevorzugten Ausführungsform nutzt die vorliegende Erfindung eine Gruppe von intelligenten Leitwegprogrammen zusammen mit einer heterogenen Umgebung für die gemeinsame Dateinutzung, um eine einzige Systemabbild-Architektur zu erhalten, die mehrere Netzwerkprodukte unterstützt. Die intelligenten Leitwegprogramme treten gegenüber den Benutzern mit einer einzigen IP-Netzwerkadresse auf und führen eine Wegeleitung auf Protokollbasis durch. Anstelle von emulierten Versionen für einige Versionen ermöglicht das intelligente Leitwegprogramm eine Systemarchitektur mit "ursprünglicher" Protokollausführung für jeden einzelnen Servertyp. Das intelligente Leitwegprogramm unterstützt so eine Systemarchitektur, die mehreren verschiedenartigen Benutzern erlaubt, alle Dateien in einem einzigen Dateinamensbereich gemeinsam zu nutzen.
Der ST-Client leitet alle Metadatenoperationen an die ST-Server weiter und leitet darüber hinaus alle Datenoperationen an Speichereinheiten weiter, die mit einem Hochgeschwindigkeitsnetzwerk verbunden sind. Außerdem lässt der ST-Client die für das Betriebssystem des Benutzers (und für alle übrigen auf dem System ausgeführten Anwendungen) sichtbaren Metadaten mit denjenigen Metadaten, die aus einem nativen, lokal verbundenen Dateisystem gelesen werden, identisch erscheinen.
Wenn eine Nachricht oder eine Anforderung als Eingabe in das System empfangen wird, ermittelt das intelligente Leitwegprogramm, welches Protokoll mit dem von dem Benutzer verwendeten Protokoll übereinstimmt, und leitet die Nachricht dann an den geeigneten ST-Client weiter. Wenn der ST-Client die Daten abruft, werden sie nicht notwendigerweise über das intelligente Leitwegprogramm an den Benutzer zurückgegeben. Allerdings können die abgerufenen Daten bei anderen Ausführungsformen bei Bedarf auch über das intelligente Leitwegprogramm geleitet werden.
Bei der Realisierung des intelligenten Leitwegprogramms hört eine Servereinrichtung nur an ausgewählten Anschlüssen, z. B. an Anschluss 139 für das CIFS- und an Anschluss 2049 für das NFS-Protokoll. Wenn an einem der Anschlüsse eine Anforderung ankommt, ermittelt das intelligente Leitwegprogramm anhand eines eindeutigen Bezeichners für die Quelleinheit wie beispielsweise der MAC-Adresse (Media Access) und des Protokolltyps das Ziel der Nachricht. Hierdurch wird sichergestellt, dass ein und derselbe ST-Client alle Anforderungen von derselben Quelleinheit verarbeitet, wodurch das intelligente Leitwegprogramm keine Zustandsinformationen für die Protokolle verwalten muss.
Da das intelligente Leitwegprogramm keine Änderungen am Nachrichteninhalt vornimmt, wissen die ST-Clients nichts von seiner Existenz. Somit müssen etwaige Rückgabenachrichten nicht über das intelligente Leitwegprogramm geleitet werden. Anhand von für den Webserver-Lastausgleich entwickelten Technologien kann veranlasst werden, dass eine Gruppe von miteinander verbundenen intelligenten Leitwegprogrammen als ein einziges System mit ein und demselben Hostnamen und/oder ein und derselben IP-Adresse erscheint.
Die verschiedenen Merkmale der vorliegenden Erfindung und die Art und Weise ihrer Realisierung werden nun mit Blick auf die folgende Beschreibung, die Ansprüche und Zeichnungen ausführlicher beschrieben, wobei Bezugsziffern gegebenenfalls mehrfach verwendet werden, um anzugeben, dass sich die Einheiten, auf die Bezug genommen wird, entsprechen und wobei:
1 eine schematische Darstellung einer beispielhaften Betriebsumgebung ist, in der die vorliegende Erfindung verwendet werden kann;
2. ein Übersichts-Blockschaubild der Architektur des intelligenten Leitwegprogramms aus 1 ist; und
3 ein Prozessablaufdiagramm ist, das ein Verfahren für den Betrieb des intelligenten Leitwegprogramms aus den 1 und 2 zeigt.
Die folgenden Definitionen und Erläuterungen stellen Hintergrundinformationen zum technischen Gebiet der vorliegenden Erfindung bereit und sollen zum besseren Verständnis der vorliegenden Erfindung dienen, ohne jedoch deren Geltungsumfang einzuschränken:

Behälter: Ein Teilbaum des globalen Namensbereichs. Er fasst eine Gruppe von Storage-Tank-Objekten zu Lastausgleichs- und Verwaltungszwecken zusammen.
IP-Netzwerk: Internetprotokoll-Netzwerk. IP gibt das Format von Datenpaketen (auch als Datengramme bezeichnet) sowie das Adressierungsschema an. Die meisten Netzwerke kombinieren IP mit einem übergeordneten Protokoll mit der Bezeichnung Transmission Control Protocol (TCP), das eine virtuelle Verbindung zwischen einem Ziel und einer Quelle herstellt.
Metadaten: Daten über Daten, z. B. Kennungen, die das Thema eines WWW-Dokuments angeben. Metadaten beschreiben beispielsweise, wie, wann und von wem ein bestimmter Datensatz erfasst wurde, wie die Daten formatiert sind und wo sie sich befinden.
Ursprünglich: Sich auf eine ursprüngliche Form beziehend. So können z. B. viele Anwendungen Dateien in verschiedenen Formaten verarbeiten, wobei das ursprüngliche Dateiformat einer Anwendung jedoch dasjenige ist, das von ihr intern verwendet wird. Bei allen anderen Formaten muss die Anwendung die Datei zunächst in ihr ursprüngliches Format umwandeln.
Protokoll: Ein vereinbartes Format für die Übertragung von Daten zwischen zwei Einheiten. Das Protokoll legt Folgendes fest: die Art der zu verwendenden Fehlerprüfung; das Datenkomprimierungsverfahren, sofern vorhanden; die Art und Weise, wie die sendende Einheit angibt, dass sie das Senden einer Nachricht abgeschlossen hat; sowie die Art und Weise, wie die empfangende Einheit angibt, dass sie eine Nachricht empfangen hat.
Server: Ein Computer bzw. eine Einheit in einem Netzwerk, die Netzwerkressourcen verwaltet.
Speicherpool: Eine Zusammenstellung von einem oder mehreren Speichermedien. Sie stellt eine logische Gruppierung der Speichermedien bereit, um so Behältern Speicherplatz zuzuweisen. Dabei können die Dateien in einem Behälter zu unterschiedlichen Speicherpools gehören. Mehrere Behälter können Speicherplatz innerhalb eines einzigen Speicherpool besitzen.
Speichermedium: Eine exportierte Speichereinheit, bei der es sich um eine physische oder eine logische Einheit handeln kann. Speichermedien werden zu Speicherpools hinzugefügt und müssen für alle Server und Clients zugänglich sein, die Zugriff auf die Daten auf das Speichermedium benötigen.

1 zeigt eine beispielhafte Architektur eines Storage-Tank-Systems 100, das ein intelligentes Leitwegprogramm 10 nutzt. Das entweder einzeln oder als Gruppe genutzte intelligente Leitwegprogramm 10 tritt gegenüber dem Benutzer 15 über das Netzwerk 20 mit einer einzigen IP-Netzwerkadresse auf und führt eine protokollbasierte Wegeleitung durch, um so eine einzige Systemarchitektur zu realisieren, die mehrere Netzwerkprotokolle unterstützt.
Das intelligente Leitwegprogramm 10 beinhaltet einen Software-Programmiercode oder ein Computerprogrammprodukt, das üblicherweise in einen Hostserver eingebettet oder darauf installiert ist. Alternativ kann das intelligente Leitwegprogramm 10 auf einem geeigneten Speichermedium wie beispielsweise einer Diskette, einer CD, einer Festplatte oder ähnlichen Einheiten gespeichert sein. Obwohl das System 10 mit Blick auf das World Wide Web beschrieben ist, kann das intelligente Leitwegprogramm 10 auch mit einer eigenständigen Datenbank mit Begriffen verwendet werden, die aus dem WWW und/oder anderen Quellen erhalten wurden.
Das intelligente Leitwegprogramm 10 ist mit einem Block 25 von Storage-Tank-Clients 30, 35, 40, 45, 50 verbunden. Dabei stehen dem intelligenten Leitwegprogramm 10 mehrere unterschiedliche Storage-Tank-Clients in dem Storage-Tank-Client-Block 25 zur Verfügung. Jeder einzelne Storage-Tank-Client kann ein anderes Betriebssystem oder Protokoll verwenden. Das intelligente Leitwegprogramm 10 gestattet eine Systemarchitektur mit einer "ursprünglichen" Protokollausführung für jeden Servertyp anstelle von emulierten Versionen einiger weniger Protokolle. Zur Veranschaulichung verwendet der Storage-Tank-Client 30 das Betriebssystem AIX^®, während der Storage-Tank-Client 35 das Betriebssystem Solaris^®, der Storage-Tank-Client 40 das Betriebssystem HP/UX^®, der Storage-Tank-Client 45 das Betriebssystem Linux^® und der Storage-Tank-Client 50 das Betriebssystem Microsoft Windows^® 2000 verwendet.
Die gezeigten Typen von Betriebssystemen machen die große Bandbreite von Betriebssystemen deutlich, die von dem intelligenten Leitwegprogramm 10 unterstützt werden. Jeder der Storage-Tank-Clients 30, 35, 40, 45, 50 führt eine Storage-Tank-Client-Software aus, die z. B. als VFS-Schnittstelle (Virtual File System) auf dem Unix^®-Storage-Tank-Client und als IFS-Dateisystem (Installable File System) auf dem Microsoft Windows^®-Storage-Tank-Client realisiert ist. Daher werden die Storage-Tank-Clients 30, 35, 40, 45, 50 in der Zeichnung als VFS oder IFS bezeichnet.
Über ein Speichernetzwerk 60 führt der Storage-Tank-Client 25 eine gemeinsame Nutzung von Dateien in mehreren Speicherpools 55 durch. Der Storage-Tank-Client-Block 25 ist auch mit den Metadatenservern 65, 70, 75 verbunden. Die Metadatenserver 65, 70, 75 sind in Gruppen zusammengefasst, um so eine Metadatenserver-Gruppierung 80 zu bilden. Die Metadaten zu den Daten sind in den mehreren Speicherpools 55 gespeichert, die wiederum im Metadatenspeicher 85 gespeichert sind. Die Speichersysteme und -einheiten für die Speicherung von Computerdaten können von den Speichersystemen und -einheiten für die Speicherung von Storage-Tank-Metadaten getrennt werden.
Das Storage-Tank-System 100 aus 1 verwendet zwei logische Netzwerke, das Steuernetzwerk 90 und das Speichernetzwerk 60.
Die Storage-Tank-Clients 25 leiten alle Metadatenoperationen über das Steuernetzwerk 90 an die Storage-Tank-Server 80 weiter. Die Storage-Tank-Clients 30, 35, 40, 45, 50 lassen die für das Betriebssystem des Benutzers 15 sichtbaren Metadaten mit den Metadaten, die aus einem ursprünglichen, lokal verbundenen Dateisystem gelesen werden, identisch erscheinen. Das Steuernetzwerk 90 überträgt lediglich Nachrichten und Metadaten. Die Menge der über das Steuernetzwerk 90 übertragenen Daten ist äußerst gering.
Der Storage-Tank-Client-Block 25 und die Metadatenserver 80, die mehreren Speicherpools 55 und der Metadatenspeicher 85 sind mit dem Hochgeschwindigkeits-Speichernetzwerk 60 verbunden. Das Speichernetzwerk 60 wird für die gesamte Datenübertragung verwendet. Dies entfernt die Storage-Tank-Server 80 aus dem Datenpfad, wodurch der Leistungsüberschuss verringert und mögliche Engpässe bei der Datenübertragung vermieden werden.
Das Storage-Tank-System 100 unterstützt mehrere Speicherpools für seine Dateidaten sowie mehrere Speicherpools für den Metadatenspeicher 85. Im Gegensatz zu den meisten Dateisystemen speichert das Storage-Tank-System Metadaten und Daten getrennt. Metadaten, wozu auch standardmäßige Datei-Metadaten wie Dateiname, Erzeugungsdatum und Daten zur Zugriffssteuerung gehören, beinhalten außerdem auch die Speicherstelle der Dateidaten auf der Festplatte (die Bereichsliste).
Metadaten werden in einem privaten Serverspeicher mit hoher Leistung und Verfügbarkeit abgelegt, der sich in demselben Speichernetzwerk wie der Datenspeicher oder aber in einem getrennten Speichernetzwerk befinden kann und auf den sämtliche Storage-Tank-Server in der Gruppierung zugreifen können. Dabei erfolgt der Zugriff auf die Metadaten nicht unmittelbar durch die Storage-Tank-Clients 30, 35, 40, 45, 50, sondern über das Steuernetzwerk 90 unter Anwendung des Storage-Tank-Protokolls.
Datenblöcke für eine beliebige gegebene Datei werden auf Festplatten in einem der Speicherpools gespeichert. Datenplatten werden im Speichernetzwerk 60 so konfiguriert, dass sowohl ein Zugriff durch die Storage-Tank-Clients 30, 35, 40, 45, 50 als auch durch die Storage-Tank-Server 80 möglich ist. In vielen Situationen würde das Speichernetzwerk 60 mit einem Bereich für die Storage-Tank-Datenplatten, -Clients und -Server konfiguriert werden. Bei Bedarf können auch mehrere Bereiche erzeugt werden, auf die ausschließlich durch die Storage-Tank-Server und eine Teilgruppe von Storage-Tank-Clients zugegriffen werden kann, um so speziellen Sicherheitsanforderungen für den Benutzer 15 zu genügen.
Der Benutzer 15 tauscht über das Netzwerk 20 Daten mit dem intelligenten Leitwegprogramm 10 aus. Dabei kann es sich bei dem Netzwerk 20 um das Internet, ein lokales Netz oder ein beliebiges anderes Netzwerk handeln.
Das System kann über einen Storage-Tank-Server wie beispielsweise den Server 65, eine Gruppierung von Servern wie beispielsweise die Server 80 oder über mehrere Gruppierungen von Servern 80 verfügen. Die in Gruppierungen zusammengefassten Storage-Tank-Server stellen Lastausgleich, Funktionen für die Ausfallsicherung und erhöhte Skalierbarkeit bereit. Die in Gruppierungen zusammengefassten Storage-Tank- Server 80 sind entweder über ihr eigenes Hochgeschwindigkeitsnetzwerk oder über das Steuernetzwerk 90, das für den Datenaustausch mit den Storage-Tank-Clients 30, 35, 40, 45, 50 verwendet wird, miteinander verbunden.
Das Storage-Tank-Protokoll ist das Protokoll, das für den Datenaustausch zwischen den Storage-Tank-Clients 30, 35, 40, 45, 50 und den Storage-Tank-Servern 80 verwendet wird. Das Protokoll realisiert ein Sperr- und Datenkonsistenzmodell, das es den mehreren Speicherpools 55 (oder dem verteilten Storage-Tank-Speichersystem) gestattet, wie ein einziges lokales Dateisystem auszusehen und sich entsprechend zu verhalten. Eine Zielsetzung des Storage-Tank-Protokolls besteht in der Bereitstellung einer hohen Datenkonsistenz zwischen dem Storage-Tank-Client-Block 25 und den Storage-Tank-Servern 80 in einer verteilten Umgebung.
Das intelligente Leitwegprogramm 10 ist über ein Netzwerk, bei dem es sich vorzugsweise um das Steuernetzwerk 90 handelt, mit jedem Storage-Tank-Client 25, 30, 35, 40 und 45 verbunden. Wenn eine Nachricht oder Anforderung von dem Benutzer 15 eingeht, ermittelt das intelligente Leitwegprogramm 10, welches Protokoll mit dem von dem Benutzer 15 verwendeten Protokoll übereinstimmt, und leitet die Nachricht dann an den geeigneten Storage-Tank-Client in dem Storage-Tank-Client-Block 25 weiter. So führt der Benutzer 15 beispielsweise das Betriebssystem Linux^® aus und möchte auf Daten in den Dateien zugreifen, die in den mehreren Speicherpools 55 gespeichert sind. Das intelligente Leitwegprogramm 10 erkennt aus der Nachricht des Benutzers 15, dass dieser das NFS-Protokoll verwendet. Daher leitet es die Anforderungen für den Dateizugriff an einen Storage-Tank-Client 45 weiter, der das NFS-Protokoll unterstützt.
2 stellt eine übergeordnete Hierarchie des intelligenten Leitwegprogramms 10 dar. Das intelligente Leitwegprogramm 10 besteht allgemein aus einem Protokollermittlungsmodul 205, einer Client-Funktionstabelle 210 und einem Modul 215 für die Storage-Tank-Clientauswahl. Dabei sind dem intelligenten Leitwegprogramm 10 viele Storage-Tank-Clients verfügbar, wie dies durch Storage-Tank-Client 1 (225) und Storage-Tank-Client 2 (230) bis Storage-Tank-Client n (235) dargestellt ist.
Während des Betriebs und mit Blick auf Verfahren 300 aus 3 gibt der Benutzer 15 in Schritt 305 eine Anforderung aus bzw. sendet eine Nachricht an das System 10. Das Protokollermittlungsmodul 205 empfängt die Anforderung oder Nachricht in Schritt 310 und ermittelt ihr Protokoll.
Das intelligente Leitwegprotokoll 10 hört nur an ausgewählten Anschlüssen, z. B. an Anschluss 139 für das CIFS- und an Anschluss 2049 für das NFS-Protokoll. Wenn an einem der Anschlüsse eine Anforderung ankommt, ermittelt das intelligente Leitwegprogramm 10 anhand eines eindeutigen Bezeichners für die Quelleinheit wie beispielsweise der MAC-Adresse und dem Protokolltyp das Ziel der Nachricht. Hierdurch wird sichergestellt, dass ein und derselbe Storage-Tank-Client 225, 230 oder 235 alle Anforderungen von demselben übergeordneten Client 15 verarbeitet. Dabei kann der Protokolltyp z. B. CIFS oder NFS lauten. Bei einer bevorzugten Ausführungsform sind die Storage-Tank-Clients 225, 230 und 235 mit einem Modul 236 für die Clientverfügbarkeit und -leistung verbunden, das wiederum mit dem Modul 215 für die Storage- Tank-Clientauswahl verbunden ist. Das Modul 215 für die Storage-Tank-Clientauswahl gibt den ausgewählten Client aus, auf den die Ziffer 237 Bezug nimmt.
Das Protokollermittlungsmodul 205 sendet die Protokolldaten in Schritt 320 für diese Nachricht an das Modul 215 für die Storage-Tank-Clientauswahl. Das Modul 215 für die Storage-Tank-Clientauswahl vergleicht das Nachrichtenprotokoll in Schritt 325 mit den Protokollen, die in der Client-Funktionstabelle 210 aufgeführt sind. Die Client-Funktionstabelle 210 beschreibt, welche Storage-Tank-Clients 225, 230, 235 in dem Storage-Tank-System 100 verfügbar sind, und nennt die Original-Protokolle, die von diesen Storage-Tank-Clients unterstützt werden.
Wenn in Entscheidungsschritt 330 die Anzahl der Storage-Tank-Clients 225, 230, 235, die das Nachrichtenprotokoll unterstützen, den Wert Eins aufweist, leitet das intelligente Leitwegprogramm 10 die Nachricht in Schritt 335 von dem Benutzer 15 an den einzelnen Storage-Tank-Client. So führt der Benutzer 15 beispielsweise das Betriebssystem Linux^® aus. In Entscheidungsschritt 330 findet das intelligente Leitwegprogramm 10 nur einen einzigen Storage-Tank-Client, der eine "ursprüngliche" Ausführung des vom Linux^®-Betriebssystem verwendeten NFS-Protokolls ausführt, z. B. den Storage-Tank-Client 2 (230). Das intelligente Leitwegprogramm 10 leitet die Nachricht dann von dem Benutzer 15 an den Storage-Tank-Client 2 (230) weiter.
In Entscheidungsschritt 330 kann das intelligente Leitwegprogramm 10 auch mehrere Storage-Tank-Clients finden, die eine "ursprüngliche" Version des Protokolls des Benutzers 15 ausführen. Wenn dies der Fall ist, wählt das intelligente Leitwegprogramm 10 in Schritt 340 einen der geeigneten Storage-Tank-Clients aus.
So soll der Benutzer 15 beispielsweise das Betriebssystem Microsoft Windows^® ausführen. In Schritt 330 findet das System 10 zwei Storage-Tank-Clients, die das CIFS-Protokoll von Microsoft Windows^® auf ursprüngliche Weise unterstützen, wie beispielsweise den Storage-Tank-Client 1 (225) und den Storage-Tank-Client 2 (230). Bei einer bevorzugten Ausführungsform der vorliegenden Erfindung wählt das intelligente Leitwegprogramm 10 einen der möglichen Storage-Tank-Clients wie z. B. den Storage-Tank-Client 1 (225) als Empfänger der Nachricht oder Anforderung aus.
Bei einer alternativen Ausführungsform "erinnert" sich das intelligente Leitwegprogramm 10 an den zuvor von dem Benutzer 15 verwendeten Storage-Tank-Client und wählt in Schritt 340 denselben Storage-Tank-Client aus, wobei es sich z. B. um den Storage-Tank-Client 2 (225) handelt. Um sich an den früheren Storage-Tank-Client zu erinnern, verwendet das intelligente Leitwegprogramm 10 einen eindeutigen Bezeichner für die Quelleinheit wie beispielsweise die MAC-Adresse und den Typ des Nachrichtenprotokolls, um so den geeigneten Server für den Empfang der Nachricht oder Anforderung zu ermitteln. Hierdurch wird sichergestellt, dass ein und derselbe Storage-Tank-Client alle Anforderungen von demselben übergeordneten Client 85 verarbeitet. Somit muss das intelligente Leitwegprogramm 10 keine Zustandsinformationen für das Protokoll verwalten.
Bei einer anderen Ausführungsform könnte das intelligente Leitwegprogramm 10 nacheinander die Storage-Tank-Clients auswählen (d. h. diese durchlaufen), die das geeignete Original-Protokoll unterstützen, oder es könnte festlegen, dass der Storage-Tank-Client die Nachricht auf eine andere geeignete Art und Weise empfängt.
Nachdem der Storage-Tank-Client ausgewählt wurde, leitet das intelligente Leitwegprogramm 10 die Nachricht in Schritt 345 an den ausgewählten Storage-Tank-Client weiter. Dabei nimmt das intelligente Leitwegprogramm 10 keine Änderungen am Inhalt der Nachrichten vor, die an die Storage-Tank-Clients übergeben werden. Somit müssen etwaige Rückgabenachrichten nicht über das intelligente Leitwegprogramm 10 geleitet werden. Bei Bedarf könnten Rückgabenachrichten allerdings durchaus über das intelligente Leitwegprogramm geleitet werden.
Obwohl die vorliegende Erfindung aus Gründen der Veranschaulichung lediglich mit Blick auf ein Speicherbereichsnetzwerk beschrieben wird, sollte deutlich sein, dass sie auch auf ein beliebiges anderes Dateisystem anwendbar ist, das die gemeinsame Dateinutzung durch heterogene Systeme gestattet.

Claims

Verfahren für die automatische Durchführung einer protokollbasierten Wegeleitung eines Eingangsbefehls unter Verwendung eines Eingangsprotokolls an einen Dateispeicherclient, der in der Lage ist, dasselbe Protokoll wie das Eingangsprotokoll zu unterstützen, das Folgendes umfasst: Ermitteln des Eingangsprotokolls der Eingangsnachricht; Kenntlichmachen einer Vielzahl von Protokollen, die von einer Vielzahl von Dateispeicherclients unterstützt werden; Vergleichen des Eingangsprotokolls des Eingangsbefehls mit der Vielzahl von Protokollen, die von der Vielzahl von Dateispeicherclients unterstützt werden; Auswählen des Dateispeicherclients, der in der Lage ist, dasselbe Protokoll zu unterstützen wie das Eingangsprotokoll; und automatisches Weiterleiten des Eingangsbefehls an einen ausgewählten Dateispeicherclient.
Verfahren nach Anspruch 1, wobei die Vielzahl von Protokollen nativ und ohne Emulation unterstützt wird.
Verfahren nach Anspruch 1, wobei mindestens einige aus der Vielzahl von Protokollen unterschiedlich sind.
Verfahren nach Anspruch 1, wobei das automatische Weiterleiten des Eingangsbefehls das automatische Weiterleiten des Eingangsbefehls ohne Eingreifen seitens des Benutzers umfasst, der den Eingangsbefehl ausgibt.
Verfahren nach Anspruch 4, wobei der Benutzer ein Computerprogramm umfasst.
Verfahren nach Anspruch 4, wobei das automatische Weiterleiten des Eingangsbefehls das Verwenden eines Leitwegprogramm-Systems umfasst, das gegenüber dem Benutzer als eine einzige Einheit erscheint.
Verfahren nach Anspruch 6, wobei das automatische Weiterleiten des Eingangsbefehls das Herstellen einer Verbindung mit einem Storage-Tank-Client für die Dateispeicherung unter Verwendung einer einzigen Netzwerkadresse umfasst.
Verfahren nach Anspruch 1, wobei eine Vielzahl von Dateispeicherclients ermittelt wird, um das Eingangsprotokoll zu unterstützen, und wobei einer der Dateispeicherclients ausgewählt wird.
Computerprogrammprodukt, das über Befehlscodes für die Durchführung des Verfahrens eines beliebigen vorangegangenen Anspruchs verfügt.
Vorrichtung, die ein Mittel umfasst, das so gestaltet ist, dass es alle Schritte des Verfahrens gemäß einem beliebigen vorangegangenen Anspruch ausführen kann.