DE102004019854B4

DE102004019854B4 - Datenspeicher- und Zugriffssystem

Info

Publication number: DE102004019854B4
Application number: DE102004019854A
Authority: DE
Inventors: Joachim Worringen
Original assignee: NEC Europe Ltd
Current assignee: NEC Corp
Priority date: 2004-04-23
Filing date: 2004-04-23
Publication date: 2010-09-16
Anticipated expiration: 2024-04-24
Also published as: DE102004019854A1; GB2413410A; FR2870951A1; AU2005200656A1; GB0504446D0; GB2413410B; AU2005200656B2; FR2870951B1

Abstract

Datenspeicher- und Zugriffssystem zur Verwendung mit einem oder mehreren Parallelverarbeitungssystemen mit mehreren Knoten (1-1, 1-2, ..., 1-n) für Anwendungen (3) zur parallelen Datei-Ein-/Ausgabe, wobei
a) eine Datendatei (2), die für die Anwendung (3) zugänglich ist, in mehrere Dateifragmente (2-1, 2-2, ..., 2-m) unterteilt ist,
b) die Dateifragmente (2-1, 2-2, ..., 2-m) verteilt auf mehreren Speichereinrichtungen (5-1, 5-2, ..., 5-L) gespeichert sind, die innerhalb des Parallelverarbeitungssystems zugänglich sind, wobei die Unterteilung und Verteilung der Dateifragmente individuell von einem Benutzer definierbar ist,
c) die Anwendung (3) in mehrere individuelle Anwendungen (3-1, 3-2, ..., 3-k) unterteilt ist und jede der individuellen Anwendungen (3-1, 3-2, ..., 3-k) auf einem individuellen Knoten (1-1, 1-2, ..., 1-n) laufen kann,
d) wenigstens eine Verteilungsinformationseinrichtung (6) dafür eingerichtet ist, Informationen über die Verteilung der Dateifragmente (2-1, 2-2, ..., 2-m) wenigstens einer der individuellen Anwendungen (3-1, 3-2, ..., 3-k) zur Verfügung zu stellen, und...

Description

Die vorliegende Erfindung betrifft ein Datenspeicher- und Zugriffssystem zur Verwendung mit einem oder mehreren Parallelverarbeitungssystemen. Die Erfindung betrifft insbesondere ein auf der Benutzerebene arbeitendes bzw. zu bedienendes Datenspeichersystem (User-level Data-storage System – UDS) zum Erhöhen der Leistungsfähigkeit einer Anwendung, welche eine parallele Datei-Ein-/Ausgabe ausführt.
Wenngleich die Rechen- und Kommunikationsleistung vieler Hochleistungs-Computersysteme (HPC) auf einem sehr hohen Niveau liegt, wodurch eine wirksame Ausführung massiv paralleler Anwendungen ermöglicht wird, kann beobachtet werden, daß die effektive Ein- und Ausgabebandbreite (E/A-Bandbreite) für diese Anwendungen hinter diesem Leistungsniveau zurückbleibt. Mit gegenwärtigen Lösungen wird das heutige Leistungspotential der installierten E/A-Hardware nicht gut ausgenutzt.
Um eine ausreichende akkumulierte Bandbreite für parallele Anwendungen selbst mit der verfügbaren E/A-Infrastruktur zu erreichen, verwenden Benutzer und Systemoperatoren häufig ”Auswege” bzw. Hilfskonstruktionen. Ein typisches Verfahren besteht darin, die Eingabe für eine Anwendung in eine oder mehrere Teildateien für jeden Prozeß einer parallelen Anwendung zu unterteilen oder zu partitionieren. Jeder Prozeß liest oder schreibt dann nur diese Teildatei unter Verwendung einer sequentiellen E/A-Schnittstelle ähnlich wie eine Fortran-E/A-Schnittstelle, während kein anderer Prozeß auf diese Teildatei zugreift. Das Problem bei diesem Ansatz besteht in der statischen Abbildung der Teildateien auf die Prozesse und dem hohen Zusatzaufwand vor und nach der Verarbeitung. Weiterhin ist es zum Erreichen der maximalen Leistungsfähigkeit häufig erforderlich, die Teildateien über mehrere Dateisysteme zu verteilen, wodurch die Komplexität sogar noch weiter vergrößert wird. Falls auf diese Dateisysteme nicht von allen Rechenknoten zugegriffen werden kann, beispielsweise in dem Fall, in dem die schnellen lokalen Dateisysteme auf den Rechenknoten verwendet werden, läuft die Anwendung nicht einmal, falls die Verteilung der Dateien nicht mit der Anordnung der Prozesse übereinstimmt. Weil die Anordnung der Prozesse durch das Planungssystem und damit beliebig ausgeführt wird, ist es sehr schwierig, auf diese Weise die optimale Leistungsfähigkeit zu erreichen.
Verteilte Dateisysteme, wie das Netzwerk-Dateisystem (Network File System – NFS), das Andrew-Dateisystem (Andrew File System – AFS) oder das globale Dateisystem (Global File System – GFS) sind nur dafür ausgelegt, einen verteilten Zugriff auf Dateien von mehreren Client-Maschinen bereitzustellen. Verteilte Dateisysteme sind jedoch nicht für gleichzeitige Schreibvorgänge hoher Bandbreite ausgelegt, die parallele Anwendungen typischerweise benötigen.
Im Handel erhältliche parallele Dateisysteme, wie PES, PIOFS und GPFS sind häufig nur für spezifische Plattformen erhältlich. Wie beispielsweise in US 6 032 216 A beschrieben ist, weist dieses System ein gemeinsam verwendetes Plattendateisystem auf, das auf mehreren Computern läuft, die jeweils ihre eigene Instanz eines Betriebssystems aufweisen und für einen parallelen gemeinsamen Datenzugriff auf Dateien gekoppelt sind, die auf im Netzwerk verbundenen gemeinsam verwendeten Platten vorhanden sind. Ein Metadaten-Knoten verwaltet Datei-Metadaten für parallele Lese- und Schreibaktionen. Metadaten-Tokens werden für einen gesteuerten Zugriff auf die Metadaten und zur anfänglichen Auswahl sowie zum Ändern des Metadaten-Knotens verwendet.
In der Anmeldung EP 1 298 536 A1 wird ein komplexes verteiltes Dateisystem beschrieben. In diesem Dateisystem werden beliebig verschachtelte Vektoren (sogenannte PITFALLS) verwendet, um die Datenaufteilung eines globalen Feldes im Speicher der Prozessse einer parallelen Applikation identisch auf die Verteilung der Daten der Datei anzuwenden, in der dieses globale Feld abgespeichert wird.
Ein paralleles Dateisystem für Linux-Cluster, das als paralleles virtuelles Dateisystem (Parallel Virtual File System – PVFS) bezeichnet wird, hat die primäre Aufgabe, einen schnellen Zugriff auf Dateidaten für auf Linux beruhende parallele Anwendungen bereitzustellen. PVFS stellt einen Linux-Cluster-weiten konsistenten Namensraum bereit, ermöglicht ein benutzergesteuertes Zerlegen von Dateien über Platten auf verschiedenen E/A-Knoten und ermöglicht es, daß existierende Binärdateien auf PVFS-Dateien arbeiten, ohne daß ein Rekompilieren erforderlich wäre. PVFS ist als ein Client-Server-System mit mehreren als E/A-Dämonen bezeichneten Servern ausgelegt. E/A-Dämonen werden statisch zugewiesen, um auf gesonderten bzw. separaten vorbestimmten Knoten in den Clustern zu laufen, welche als E/A-Knoten bezeichnet werden, mit denen Platten verbunden sind. Jede PVFS-Datei ist über die Platten an den E/A-Knoten verteilt. Zu der Zeit, zu der das Dateisystem installiert wird, spezifiziert der Benutzer, welche Knoten in dem Cluster als ein E/A-Knoten dienen. Anwendungsprozesse tauschen sich mit PVFS über eine Client-Bibliothek aus. Anwendungsprozesse kommunizieren direkt über das relativ langsame TCP mit dem PVFS-Manager, wenn Operationen, wie das Öffnen, Erzeugen, Schließen und Entfernen von Dateien ausgeführt werden. Wenn eine Anwendung eine Datei öffnet, gibt der Manager zu der Anwendung die Orte der vorbestimmten statischen E/A-Knoten zurück, an denen Dateidaten gespeichert sind.
Zudem werden im Artikel ”Implementation and Performace of a Parallel File System for High Performance Distributed Applications” von W. B. Ligon III und R. B. Ross; Proceedings des 5. Internationalen IEEE Symposiums für ”High Performace Disributed Computing” (HPDC '96), 196 bzw. in dem Artikel ”AVAKI Grid Software: Concepts and Archiceture”; von der Avaki Corporation; März 2002, PVFS bzw. Grid basierte verteilte Dateisysteme beschrieben.
Die vorliegende Erfindung stellt eine Lösung für die vorstehend erörterten Probleme bereit. Das System gemäß der vorliegenden Erfindung ist kein Kernel-betriebenes Dateisystem, sondern es arbeitet statt dessen im Benutzerraum, wobei die verfügbaren Dateisysteme in der bestmöglichen Weise verwendet werden, um eine hohe akkumulierte parallele E/A-Bandbreite zu erreichen.
Das System gemäß der vorliegenden Erfindung, das nachstehend auch als auf der Benutzerebene arbeitender Datenspeicher (Userlevel Data Storage – UDS) bezeichnet wird, weist eine hohe E/A-Bandbreite für parallele Anwendungen auf unter bevorzugter Verwendung einer MPI-IO-Schnittstelle, welche das Skalieren der Anzahl der beteiligten Prozesse ermöglicht. MPI-IO ist der Teil des Nachrichtenübertragungsschnittstellen-Standards (Message Passing Interface (MPI) Standard), der spezifiziert, wie parallel mit einer MPI-Anwendung auf Dateien zuzugreifen ist. Für einen Dateizugriff, der keine hohe Leistungsfähigkeit benötigt, beispielsweise für Verwaltungsaufgaben, können andere Wege für Datenzugriffe verwendet werden. Das System kann von jeder gegebenen E/A-Infrastruktur profitieren, ohne daß eine Abhängigkeit vom tatsächlichen Dateisystem besteht, das zum Speichern der Daten verwendet wird. Seine Flexibilität ermöglicht es dem Benutzer, aus jedem Speicherort auszuwählen, der in dem System sichtbar ist, ob zwischen den Knoten gemeinsam genutzt oder nicht, je nach dem, was am besten zu den Erfordernissen der spezifischen Anwendung paßt.
Die Aufgabe der Erfindung wird mit den Merkmalen des unabhängigen Anspruchs 1 gelöst. Weitere bevorzugte Ausführungsformen werden in den abhängigen Ansprüchen beansprucht.
Das System gemäß der vorliegenden Erfindung ist ein System, das es dem Benutzer, insbesondere eines Hochleistungs-Computersystems, ermöglicht, die Leistungsfähigkeit seiner eine parallele Datei-Ein-/Ausgabe ausführenden Anwendung zu erhöhen. Eine parallele Anwendung wird in mehrere individuelle Anwendungen (APs) unterteilt, die als gesonderte Prozesse, möglicherweise auf verschiedenen Knoten bzw. Rechnern, laufen sollen. Das Grundkonzept zum Erhöhen der Leistungsfähigkeit besteht darin, daß eine Datei über schnelle, beispielsweise lokale Speichervorrichtungen mehrerer Rechner bzw. Rechenknoten in dem System in Dateifragmente zerlegt wird. Die mehreren Rechenknoten oder ein Teil von diesen soll die individuellen Anwendungen der parallelen Anwendung ausführen. Das System gemäß der vorliegenden Erfindung ist kein herkömmliches Dateisystem, sondern ein Verfahren zum Speichern und Zugreifen auf Daten in einer vom Benutzer gesteuerten Weise. Daher sind die Dateifragmente prinzipiell noch durch die jeweiligen nativen Dateisysteme zugänglich.
Weil es erforderlich ist, auch auf Teile einer Datei, d. h. die Dateifragmente, zuzugreifen, die sich auf keinen der gegenwärtig Prozesse ausführenden Knoten befinden, wird ein ”Dritte-Partei”-Übertragungsmodell verwendet. Vorzugsweise wird ein gesonderter E/A-Prozeß (IOP) auf jedem Knoten gestartet, der einen Teil der Datei, d. h. ein Dateifragment, worauf zuzugreifen ist, enthält. Es kann für manche spezifische Situationen auch wünschenswert sein, mehr als einen gesonderten E/A-Prozeß auf einem einzigen Knoten zu starten. Die laufenden Prozesse, d. h. die individuellen Anwendungen (APs) und die IOPs, kommunizieren vorzugsweise über MPI-Nachrichten, wobei MPI-Nachrichten im wesentlichen die schnellste Art des Kommunizierens zwischen Prozessen in einem HPC-System bereitstellen und UDS in der Lage ist, diese Leistungsfähigkeit auszunutzen. Die effektive Bandbreite zum Zugreifen auf eine solche Datei kann demgemäß die akkumulierte Bandbreite der unabhängigen Dateisysteme erreichen, weil die Bandbreite von MPI-Nachrichten typischerweise erheblich höher ist als die Bandbreite von E/A-Operationen.
Als ein auf der Benutzerebene arbeitendes System kann die Art, in der UDS Daten speichert, vom Benutzer völlig beliebig eingerichtet werden. Dies ist möglich, weil UDS kein festes Dateisystem ist, sondern auf ein verfügbares Dateisystem aufsetzt. Der Benutzer kann UDS mitteilen, welche Dateisysteme und welche Knoten verwendet werden sollten, um eine spezifische Datei zu speichern, während die nächste Datei im Namensraum wieder auf einem ganz verschiedenen Satz von Dateisystemen gespeichert werden kann. Diese Dateisysteme können über eine beliebige Teilmenge der Rechenknoten in dem System, die MPI-Anwendungen ausführen können, verteilt werden. Die Datei wird über alle spezifizierten Dateisysteme mit einer vom Benutzer definierbaren Blockgröße (Streifengröße), die am besten zu den Eigenschaften der Anwendung, des Dateisystems und der zugrundeliegenden Speichervorrichtungen paßt, Block für Block unterteilt (zerlegt). Es ist nicht erforderlich, daß die zum Zerlegen einer Datei verwendeten Dateisysteme zwischen irgendwelchen zwei Rechenknoten gemeinsam verwendet werden. Dies ermöglicht das Ausnutzen der Leistungsfähigkeit knotenlokaler Dateisysteme. Jede nachstehend auch als UDS-Datei bezeichnete Datei ist jedoch für UDS-geeignete Anwendungen unabhängig davon, auf welchem Rechenknoten sie laufen, stets global sichtbar und zugänglich. Dies kombiniert einen lokalen Dateizugriff hoher Bandbreite mit der Verwendbarkeit eines gemeinsam verwendeten Dateisystems. Zu diesen zwei Eigenschaften fügt UDS die Zwischenzugriffskommunikation hoher Leistungsfähigkeit von MPI, eine enge Integration des Dateizugriffs in die MPI-Bibliothek und die Flexibilität eines auf der Benutzerebene arbeitenden Systems hinzu.
Weil UDS Dateien unterteilt und die Dateifragmente in abgesetzten Dateisystemen (oder abgesetzten Orten im selben Dateisystem) speichert, arbeitet es in einem gesonderten Namensraum, der durch eine nachstehend auch als UDS-Namensserver bezeichnete Verteilungsinformationseinrichtung verwaltet wird. Zu diesem Zweck unterhält der Namensserver eine Datenbank, die für jede UDS-Datei einen Datensatz und einen globalen Zustand enthält. Daher werden durch UDS erzeugte Dateien innerhalb dieses Namensraums angeordnet, so daß alle Informationen der Dateiverteilung in der Datenbank des Namensservers gespeichert werden, während die physikalischen Dateifragmente auf den verteilten Speicherplatten gespeichert werden. Es ist folglich nicht möglich, eine Datei außerhalb dieses Namensraums (beispielsweise eine Datei, die sich in einem Ausgangsverzeichnis des Benutzers befindet) über UDS direkt zu öffnen. Um dies auszuführen, muß die Datei zuerst in den UDS-Namensraum importiert werden. Die UDS-Umgebung bietet verschiedene Arten zum Ausführen eines solchen Imports. Ebenso kann auf eine Datei, die sich innerhalb des UDS-Namensraums befindet, nicht direkt unter Verwendung von Programmen zugegriffen werden, die nicht für UDS geeignet sind, so daß es beispielsweise nicht möglich ist, einen Kopiervorgang einer UDS-Datei unter Verwendung des standard cp-Befehls von Unix auszuführen. Die Datei muß zuerst aus dem UDS-Namensraum exportiert werden oder es muß innerhalb des UDS-Namensraums unter Verwendung eines UDS-Befehlszeilentools, wie udscp, das die Entsprechung von cp für UDS ist, auf sie zugegriffen werden.
Das System gemäß der vorliegenden Erfindung bietet durch die folgenden Mittel die höchste E/A-Leistungsfähigkeit und eine gute Verwendbarkeit: (i) Lokalität, wodurch ermöglicht wird, die schnellsten Speichervorrichtungen in dem System auszunutzen. Hierbei kann es sich um eine lokale Festplatte in den Knoten oder eine andere Speichervorrichtung handeln, die für einen Prozeß einer MPI-Anwendung zugänglich ist. (ii) Eine hohe effektive Dateizugriffsbandbreite: weil eine Datei über eine Anzahl von Knoten oder Dateisystemen zerlegt wird und jede Zerlegungseinheit durch einen gesonderten E/A-Prozeß betrieben wird. Weil sich die Bandbreite der gleichzeitigen Zugriffe der E/A-Prozesse auf die unabhängigen Dateisysteme zu der E/A-Bandbreite der Anwendung aufsummiert, ergibt sich eine hohe effektive Bandbreite. (iii) Eine hohe Zwischenprozeßbandbreite: Weil die gesamte Zwischenprozeßkommunikation vorzugsweise über MPI-Nachrichten erfolgt, sind eine sehr geringe Latenz und eine hohe Bandbreite verfügbar, und ein großer Teil der von den E/A-Prozessen auf den, beispielsweise lokalen, Dateisystemen erreichten E/A-Bandbreite kann der Anwendung zugeführt werden. Das TCP/IP-Protokoll ist im Datenkommunikationspfad nicht unbedingt erforderlich. (iv) Flexibilität: Weil jeder beliebige gültige Pfad auf den Rechenknoten für das Halten der Dateifragmente gewählt werden kann, hat der Benutzer volle Flexibilität für die Art des Speicherns der Daten, wie beispielsweise die Verwendung einer sehr schnellen Speichervorrichtung Hilfs-Dateien (scratch files) oder einer permanenten Speichervorrichtung für andere Dateitypen. Es wird dadurch auch ein Ausgleich zwischen der maximalen Leistungsfähigkeit und einer verbesserten externen Zugänglichkeit der Dateien ermöglicht.
Das System gemäß der vorliegenden Erfindung unterstützt wenigstens drei Arten des Spezifizierens, wo die Dateifragmente zu speichern sind, welche eine Datei in UDS ausmachen. Sie sind durch den Namen der Datei bestimmt, wenn sie im UDS-Speichersystem erzeugt wird. Diese Erzeugung kann mit einer MPI-Anwendung (durch Aufrufen von MPI_File_open()) oder durch ein externes Tool ausgeführt werden. Bei einem ersten möglichen Verfahren wird eine Datei über einen Ausgangspfad, beispielsweise einen Pfad, der mit ”~” beginnt, spezifiziert, oder ”Benutzername” spezifiziert das Ausgangsverzeichnis der aktuellen oder gegebenen Benutzer auf jedem zum Speichern eines Dateifragments verwendeten Rechenknoten. Falls die Ausgangsverzeichnisse von einem fernen Server auf jedem Rechenknoten gemounted werden, führt dies gewöhnlich zu einer geringen Bandbreite und sollte nur für kleine Dateien verwendet werden. Einige Systeme sind jedoch konfiguriert, um dem Benutzer ein Ausgangsverzeichnis auf einem lokalen Dateisystem auf jedem Knoten zu geben. In diesen Fällen kann eine hohe Bandbreite erreicht werden. Ein zweites Verfahren bezieht sich auf einen expliziten Pfad, wobei beispielsweise ein Pfad, der mit ”/” beginnt, einen aktuellen Pfad spezifiziert, der auf allen Rechenknoten verwendet wird. Dies bedeutet, daß der spezifizierte Pfad auf all diesen Knoten gültig sein muß, jedoch nicht notwendigerweise auf ein lokales Dateisystem zeigt. Es wird jedoch nur dann eine hohe Bandbreite erreicht, wenn der Pfad zu einem lokalen Dateisystem führt. Ein drittes Verfahren betrifft einen impliziten Pfad, beispielsweise Pfade, die mit einem Meta-Zeichen und einer systemabhängigen Zeichenkette beginnen, wie beispielsweise ”#local/” oder ”#fcraid/”. Diese virtuellen Pfade werden dann durch UDS unter Verwendung einer komplexeren (kundenspezifischen oder sogar dynamischen) Zuordnung von Knoten zu Dateisystemen aufgelöst.
Es gibt im wesentlichen zwei verfügbare Schnittstellen für das Zugreifen auf Dateien, nämlich die Verwendung der MPI-IO-Schnittstelle und der ”Befehlszeilen”-Tools. Es wird die vollständige MPI-IO-Schnittstelle, wie sie im MPI-2-Standard definiert ist, unterstützt. Hierdurch kann der Benutzer Dateien erzeugen und öffnen, Daten von einer offenen Datei mit verschiedenen Lese- und Schreibfunktionen lesen und schreiben, Informationen über die Datei zusammenstellen und ihre Größe manipulieren, eine Datei schließen und eine Datei löschen. Operationen, wie das Auflisten des Inhalts eines Verzeichnisses, das Umbenennen, Bewegen oder Kopieren einer Datei, werden möglicherweise nicht direkt von dieser Schnittstelle unterstützt. Zum Ausführen von Dateioperationen über MPI-IO muß der Benutzer eine MPI-Anwendung auf dem System ausführen.
Wenn eine Datei durch den von MPI bereitgestellten MPI_File_open()-Befehl geöffnet wird, werden die folgenden Aktionen von UDS ausgeführt: 1) Vorzugsweise kontaktiert eine einzige individuelle Anwendung AP der Gruppe von Prozessen, welche die Datei öffnet (Gruppenführer) den UDS-Namensserver, wobei die Liste der Knoten zugeführt wird, auf denen Prozesse der Gruppe laufen. Die Kommunikation zwischen dem Gruppenführer und dem Namensserver wird vorzugsweise unter Verwendung eines verschlüsselten Sockets oder eines anderen Verschlüsselungsmittels über TCP/IP ausgeführt, wodurch die Authentizität auf einer Sicherheitsebene des Dateisystems gewährleistet wird. 2) Der Namensserver bildet den gegebenen Dateinamen auf seine lokale Meta-Darstellung des ganzen UDS-Namensraums ab, der in einer Hierarchie von Verzeichnissen und Dateien auf einem lokalen Dateisystem gespeichert ist. Jede UDS-Datei ist durch eine Meta-Datei in dieser Hierarchie dargestellt, welche alle Informationen zum Zugreifen auf die echte, verteilte UDS-Datei und ihre Attribute enthält. 3) Falls der Namensserver eine passende Meta-Datei findet, bedeutet dies, daß die Datei bereits existiert, und er übergibt die erforderlichen Informationen an den Gruppenführer. Diese Informationen bestehen zum größten Teil aus einer Liste von <Knoten, Pfad>-Tupeln, welche den Ort der Dateifragmente beschreibt. 4) Falls der Namensserver keine passende Meta- Datei findet, bedeutet dies, daß die Datei nicht existiert. Falls die Anwendung die Datei erzeugen möchte, erzeugt der Namensserver die passende Meta-Datei und gibt eine Liste von <Knoten, Pfad>-Tupeln auf der Grundlage des spezifizierten Pfads und der Liste von Knoten zurück, die in der anfänglichen Öffnungsanforderung des Gruppenführers enthalten waren. 5) Der Gruppenführer übergibt die Antwort an alle Prozesse in den Gruppen (die APs), die dann gemeinsam die erforderlichen E/A-Prozesse auslösen. Vorzugsweise wird in der Liste genau ein gesonderter E/A-Prozeß (IOPs) je Knoten bereitgestellt. Aus manchen Gründen kann es jedoch vorteilhaft sein, mehr als einen gesonderten E/A-Prozeß auf einem Knoten auszuführen. Die gesamte Kommunikation zwischen den APs und den IOPs wird vorzugsweise über MPI ausgeführt, wodurch eine hohe Leistungsfähigkeit gewährleistet wird. 6) Die IOPs öffnen (oder erzeugen) die lokalen Dateifragmente und melden beim Erfolg dieses Vorgangs an die APs zurück. Falls auf alle Dateifragmente zugegriffen werden kann, warten die IOPs auf ankommende Lese-/Schreibanforderungen (oder andere Anforderungen) der Anwendungsprozesse. 7) Jeder Dateiöffnungsvorgang wird vom Gruppenführer, der die Ergebnisse der Operation aller APs und IOPs sammelt, genehmigt oder aufgehoben. Falls ein Fehler auftritt, falls beispielsweise wenigstens ein IOP nicht auf ein Dateifragment zugreifen kann, wird dieses Problem dem UDS-Namensserver mitgeteilt. Falls sich die MPI_File_open()-Operation auf eine Datei bezieht, die bereits existierte, markiert der Namensserver die Datei als beschädigt. Der Administrator kann dann versuchen, die entsprechenden Dateifragmente wiederzugewinnen. Falls die MPI_File_open()-Operation vorgesehen war, um eine neue Datei zu erzeugen, war die Pfadspezifikation wahrscheinlich nicht auf allen Knoten gültig, und die Meta-Datei, die erzeugt worden war, wird wieder entfernt.
Wenn auf Daten beispielsweise durch Lese- oder Schreibzugriffsoperationen zugegriffen wird, werden die folgenden Schritte in UDS ausgeführt: 1) Auf der Grundlage der Position des Zugriffs in der Datei und des Zerlegungsmusters der Dateifragmente, das festgelegt wurde, als die Datei erzeugt wurde, kann jede individuelle Anwendung AP berechnen, welcher Satz von IOPs erforderlich ist, um der Anforderung zu entsprechen. 2) Falls die Anwendung AP einen individuellen Dateizugriff ausführt, sendet sie Anforderungen zu jedem der entsprechenden IOPs und überprüft ihre Antwort auf eine blockierende oder nicht blockierende Weise. 3) Für kollektive Dateizugriffe, wenn beispielsweise alle APs einen gemeinsamen, synchronisierten Dateizugriff ausführen, kommuniziert eine AP je Rechenknoten mit einer Anzahl (nicht unbedingt allen) IOPs für die anderen Anwendungsprozesse auf dem Knoten. Die Daten von oder zu den IOPs werden dann innerhalb der APs unter Verwendung der Innerknoten- und Zwischenknoten-MPI-Kommunikation umverteilt. Diese Optimierungen sind nur mit einem kollektiven Dateizugriff möglich. Dies ist der Grund dafür, daß ein kollektiver Dateizugriff wenn immer möglich verwendet werden sollte. 4) Die von den IOPs verarbeiteten Transportprotokolle weisen vorzugsweise eine MPI-Kommunikation und einen Dateizugriff auf. Diese Operationen können in einem Pipeline-Betrieb ausgeführt werden, um den Durchsatz zu erhöhen. Zusätzlich können die IOPs asynchrone E/A-Operationen verwenden (falls auf dem gegebenen Dateisystem verfügbar), um die MPI-Kommunikation und Dateizugriffe zu überlappen.
Die zweite verfügbare Schnittstelle für das Zugreifen auf Dateien wird durch ”Befehlszeilen”-Tools bereitgestellt. Das UDS-Dateisystem setzt auf ein natives Dateisystem auf und ist als solches nicht sichtbar, wenn herkömmliche Unix-Befehle verwendet werden, die Dateioperationen, wie das Auflisten (ls), Entfernen (rm), Kopieren (cp) oder Bilden (mkdir) von Verzeichnissen, ausführen. Diese Tools können nur auf die verteilten Dateifragmente einwirken, die eine UDS-Datei ausmachen, sie haben jedoch keine Kenntnis dieser Verteilung. Ein Benutzer könnte versehentlich einige der Dateifragmente entfernen, ohne zu wissen, daß die Dateifragmente zu einer verteilten Datei gehören. Aus diesem Grund benennt UDS die Dateifragmente auf eine Art, bei der es dem Benutzer klar ist, daß es sich um einen Teil einer UDS-Datei handelt. Weiterhin weist UDS eine Reihe von Befehlszeilen-Utilities auf, welche diese Standardfunktionen zum Verwalten der Dateien im Dateisystem bieten. Neben diesen Standardfunktionen sind zusätzliche Tools zum Importieren oder Exportieren einer Datei vom UDS-Dateisystem verfügbar, wie beispielsweise das Kopieren einer Datei von einem Standard-Dateisystem, das auf einem Frontend sichtbar ist, zu einem spezifizierten Ort innerhalb des UDS-Dateisystems und umgekehrt, abfragen UDS-spezifischer Informationen zu einer Datei oder sogar die Verteilung oder Zerlegung einer UDS-Datei.
Die vorliegende Erfindung wird weiter mit Bezug auf die anliegende Zeichnung beschrieben, wobei sich gleiche Bezugszahlen in den verschiedenen Ansichten auf gleiche Teile beziehen. Es zeigen:
1 eine Konfiguration einer ersten Ausführungsform eines Datenspeicher- und Zugriffssystems gemäß der vorliegenden Erfindung,
2 eine Konfiguration einer anderen Ausführungsform gemäß der vorliegenden Erfindung,
3 eine Konfiguration einer weiteren Ausführungsform gemäß der vorliegenden Erfindung,
4 Beispiele permanenter Komponenten auf Rechenknoten gemäß der vorliegenden Erfindung,
5 eine Anwendung, die auf eine neu erzeugte Datei zugreift,
6 eine mögliche Situation, wenn eine Anwendung eine existierende Datei öffnet,
7 die Situation, wenn eine Datei unter Verwendung eines Befehlszeilentools in den UDS-Namensraum importiert wird,
8 die Situation, in der ein Befehlszeilentool einen Namensserver auf einen Dateistatus abfragt,
9 die Situation, in der ein Befehlszeilentool eine Datei ansteuert, und
10 eine über mehrere Knoten zerlegte Datei.
Die Architektur eines Datenspeicher- und Zugriffssystems gemäß der vorliegenden Erfindung ist in 1 dargestellt, und es sind darin die Kommunikation und der Datenfluß zwischen den UDS-Komponenten für eine typische Einrichtung eines Hochleistungs-Rechenzentrums dargestellt. 1 zeigt zwei typische Szenarien für ein Hochleistungs-Computersystem mit sechs Rechenknoten 1-1 bis 1-6, die jeweils eine lokale Speichervorrichtung 5-1 bis 5-6 aufweisen. Die parallele Anwendung AP1 besteht aus zwei individuellen Anwendungen 3-1 (AP1#0) und 3-2 (AP1#1), die auf den Knoten 1-1 und 1-2 laufen. Diese zwei individuellen Anwendungen oder Prozesse haben gerade eine neue Datei erzeugt, die über die zwei Knoten 1-1 und 1-2 zerlegt ist, auf denen die Anwendung läuft. Die Datei besteht aus zwei Dateifragmenten, die jeweils auf der lokalen Speichervorrichtung 5-1 bzw. 5-2 gespeichert sind. Zum Zugreifen auf die Datei, d. h. auf die zwei Dateifragmente, werden zwei gesonderte E/A-Prozesse IOPs 4-1 (IOP1#0) und 4-2 (IOP1#1) hervorgebracht. Diese Einrichtung liefert gewöhnlich die bestmögliche Bandbreite. Ein zweites Szenario ist mit einer Anwendung AP2 dargestellt, die aus AP2 #0, #1 und #2 besteht. Sie haben eine Datei geöffnet, die bereits existierte. Sie wurde auf den Knoten 1-3 und 1-4 erzeugt. Zum Zugreifen auf diese Datei, d. h. zwei auf den Speichervorrichtungen 5-3 und 5-4 gespeicherte Dateifragmente, wurden zwei gesonderte E/A-Prozesse, nämlich IOP2#0 und IOP2#1, auf diesen Knoten 1-3 und 1-4 hervorgebracht. Der Ort der Teile der Datei, nämlich der Dateifragmente, kann vom Benutzer frei gewählt werden, und Administratorrechte sind nicht unbedingt erforderlich. Die Verwaltung von UDS, nämlich das permanente Speichern des Namensraums des Dateisystems, erfolgt durch den Namensserver 6, der vorzugsweise auf einem externen System läuft. Dieser Namensserver liefert einer Anwendung, d. h. wenigstens einer der individuellen Anwendungen 4-x, die Informationen dazu, wie auf eine Datei zuzugreifen ist, die zuvor von einer anderen ausgeführten Anwendung gespeichert wurde.
Eine andere Hardwareeinrichtung gemäß der vorliegenden Erfindung ist in 2 dargestellt. Eine Anzahl n von Rechenknoten 1-1 bis 1-n dient dem Ausführen einer parallelen Anwendung, und sie sind durch einen IXS-Switch mit hoher Bandbreite und geringer Latenz verbunden. Vorzugsweise ist jeder Knoten 1-1 bis 1-n mit einem lokalen Speichersystem 5-1 bis 5-y versehen, das nur auf diesem Knoten sichtbar ist, wobei x gleich n ist, falls auf jedem Knoten genau ein Speichersystem bereitgestellt ist. Der Zugriff auf die lokale Speichervorrichtung, der beispielsweise über SFS (Super-UX File System – Super-UX-Dateisystem) erfolgt, bietet selbst für kleine Blöcke eine hohe Bandbreite, einschließlich eines Cache-Speicherns. Zusätzlich können alle Knoten 1-1 bis 1-n über Faseroptische- bzw. Faserkanalverbindungen (FC-Verbindungen) unter Verwendung beispielsweise eines globalen Netzwerk-Dateisystems (Global network File System (GFS)), das von den Speicherknoten angeboten wird, auf eine Anzahl großer, ferner, gemeinsam verwendeter Speicherfelder 5-(y + 1) bis 5-l zugreifen. Der Zugriff auf das ferne GFS-Dateisystem ist gewöhnlich erheblich langsamer als bei SFS, was insbesondere bei kleinen Datenblöcken gilt. Auf diese Speicherfelder kann jedoch auch direkt von den Speicherknoten zugegriffen werden, welche auch als Frontend-Knoten für einen interaktiven Benutzerzugriff dienen. Die direkte Verbindung zwischen Frontend-Systemen 6-1 bis 6-p und den Knoten 1-1 bis 1-n ist vorzugsweise eine TCP/IP-Verbindung geringer Bandbreite in der Art eines Gb-Ethernet-Switch. Wenigstens auf einem dieser Frontend-Knoten 6-x läuft ein USD-Namensserver.
Der erste Weg des Ausnutzens eines solchen Systems über UDS besteht darin, Dateien und/oder Dateifragmente auf den lokalen SFS-Dateisystemen, beispielsweise speicher- oder plattenbasiert, zu speichern. Um dies zu spezifizieren, kann ein expliziter UDS-Pfad, wie ”/uds” oder ”/xmu”, der auf allen Knoten vorhanden wäre, verwendet werden. Falls UDS dementsprechend konfiguriert wird, kann auch ein impliziter Pfad mit der gleichen Funktionsweise verwendet werden. Ein Home- bzw. Ausgangspfad ist für eine Ein-/Ausgabe großen Umfangs nicht empfehlenswert, weil die Ausgangsverzeichnisse gewöhnlich durch NFS gemounted werden. Das Einschlagen dieses Wegs mit impliziten oder expliziten Pfaden bietet die höchste Leistungsfähigkeit für den Zugriff über MPI-IO. Das Importieren oder Exportieren einer Datei erfolgt jedoch langsamer, weil die Dateien auf den gemeinsam verwendeten GFS-Dateisystemen stufenweise angeordnet werden müssen. Bei einer Einrichtung, die keinen gemeinsam verwendeten Speicher zwischen dem Frontend 6-1 bis 6-p und den Rechenknoten 1-1 bis 1-n aufweist, wäre es erforderlich, den Import/Export über die TCP/IP-Verbindung zwischen diesen beiden Einheiten auszuführen, was zu geringen Bandbreitewerten für Import/Exportoperationen führt.
Der ferne Speicher 5-(y + 1) bis 5-1 kann über das GFS auch zur Dateispeicherung mit dem UDS verwendet werden. Dies bedeutet jedoch gewöhnlich, daß das Abbilden eines Rechenknotens auf ein Dateisystem nicht mehr unbedingt 1:1 ist. Eine feste umlaufende Abbildung von Rechenknoten auf Dateisysteme bietet in allen Fällen, in denen eine Anwendung auf einer Anzahl von Rechenknoten läuft, die auf dasselbe Dateisystem abgebildet sind, eine suboptimale Leistungsfähigkeit. Statt dessen muß das UDS versuchen, unter Verwendung einer dynamischen Abbildung von Rechenknoten auf Dateisysteme die Datei gleichmäßig über die verfügbaren Dateisysteme zu verteilen. Dies kann ein Dateisystem je Rechenknoten bedeuten, es sind jedoch auch andere Verteilungen, beispielsweise mehr als ein Dateisystem je Knoten und IOP, oder eine Einrichtung, bei der nur ein Teilsatz der Knoten einen IOP ausführt, möglich. Ob es wirksam ist, mehr Dateisysteme als (aktive) Rechenknoten zu verwenden, hängt von der Fähigkeit des fernen Dateisystems ab, eine synchrone Ein-/Ausgabe auszuführen, oder es ist dafür eine zusätzliche Funktionalität (Teilprozesse) bei den E/A-Prozessen erforderlich.
Das UDS unterstützt auch Legacy-E/A-Anwendungen so gut wie möglich. Es ist jedoch das Ändern der Standard-E/A-Aufrufe (open(), read(), write(), close()) zu den entsprechenden MPI-E/A-Entsprechungen (MPI_File_open(), MPI_File_read(), MPI_File_write(), MPI_File_close()) erforderlich. Gewöhnlich ist dies eine sehr einfache Aufgabe. Eine typische E/A-Technik in einer Legacy-Anwendung besteht darin, jeden Prozeß auf eine unabhängige Datei zugreifen zu lassen. Für einen Lesezugriff müssen diese Dateien oder Dateifragmente an einem Ort angeordnet werden, der für einen Prozeß erreichbar ist. Ohne das UDS bedeutet dies, daß die Dateien oder Dateifragmente entweder auf einem einzigen fernen Dateisystem angeordnet werden, das dann typischerweise nicht in der Lage ist, ausreichend Bandbreite für alle Prozesse bereitzustellen, die auf ihre Datei zugreifen, oder daß sie auf verschiedene Dateisysteme kopiert werden müssen, die eine höhere angesammelte Bandbreite für die gleichzeitigen Dateizugriffe liefern können. Für einen Schreibzugriff muß der Benutzer nach dem Programmlauf dafür sorgen, daß alle individuellen Dateien oder Dateifragmente von den verschiedenen Dateisystemen gesammelt werden und sie möglicherweise zu einer einzigen Datei verbunden werden. Diese manuelle Verteilung kann sehr komplex werden, insbesondere falls nicht alle Prozesse auf alle Dateisysteme zugreifen können, was der Fall ist, wenn lokale Dateisysteme der Rechenknoten verwendet werden. Dies kann dazu führen, daß viele Benutzer das langsamere Verfahren verwenden. Für solche Anwendungen kann das UDS, verglichen mit der optimalen manuellen Verteilung der Dateien, die Bandbreite nicht erhöhen. Es kann jedoch die Prozedur zum Erreichen einer ähnlichen Leistungsfähigkeit sehr stark vereinfachen. Dies wird durch Importieren des Verzeichnisses mit den eingegebenen Dateien auf eine Weise erreicht, bei der die vollständigen Dateien (keine Zerlegung angewendet) über die verfügbaren Dateisysteme verteilt werden. Die Anwendung kann dann auf alle Dateien unter Verwendung einer einzigen impliziten (virtuellen) UDS-Pfadspezifikation zugreifen. Wenngleich die Verteilung, die während der Importoperation ausgeführt wird, in den meisten Fällen keine optimale Lokalität (das Anordnen der Dateien auf dem Knoten, auf dem ein Prozeß ausgeführt wird) bereitstellen kann, gewährleistet das Dritte-Partei-Übertragungskonzept, daß jeder Prozeß entweder mit einer MPI- oder lokalen E/A-Bandbreite (je nach dem, welche kleiner ist) auf die Datei zugreifen kann.
Die Architektur aus 3 veranschaulicht eine typische Einrichtung eines Hochleistungs-Rechenzentrums. Die Ausführungsform aus 3 weist vier Rechenknoten 1-1 bis 1-4 auf, auf denen die parallelen Anwendungen ausgeführt werden. Sie weisen eine Anzahl von CPUs, Speicher- und lokale Speichervorrichtungen 5-1 bis 5-4 auf. Die Zugriffsbandbreite für diese Speichervorrichtungen 5-1 bis 5-4 ist selbst für kleinere Blöcke sehr hoch, weil das Dateisystem in der Lage ist, eine wirksame Cache-Speicherung auszuführen. Der Zugriff kann jedoch nur von auf diesem Knoten ablaufenden Prozessen ausgeführt werden. Typischerweise wird nur ein kleiner Teil der lokalen Speicherkapazität für das Betriebssystem verwendet, wobei bei Verwendung des UDS die volle Kapazität für global sichtbare und zugängliche Dateien verwendet werden kann. Die Rechenknoten 1-1 bis 1-4 sind über eine Nachrichtenübertragungsverbindung 8 hoher Bandbreite und geringer Latenz, gewöhnlich durch MPI-Nachrichten, verbunden. Ein Frontend 10 wird zum Anmelden, zur Datenübertragung, zum Editieren und zum Kompilieren und möglicherweise zum Sichtbarmachen verwendet. Dies ist ein System mit einem für den Benutzer begrenzt zugänglichen Speicher, beispielsweise in der Art von Ausgangsverzeichnissen des Benutzers. Das Frontend 10 ist über ein (Gigabit)-Ethernet mit den Rechenknoten 1-1 bis 1-4 verbunden. Ein externes Speichersystem 11 enthält die größeren Datendateien des Benutzers und gewöhnlich verschiedene Scratch-Bereiche. Dieses Speichersystem 11 besteht aus einer großen Anzahl unabhängiger Laufwerksfelder 5-5. Es ist über mehrere Faserkanalverbindungen (FC-Verbindungen) 9 mit den Rechenknoten 1-1 bis 1-4 und dem Frontend-Knoten 10 verbunden. Die maximale Bandbreite, die ein einzelner Prozeß auf einem Rechenknoten über diese Verbindung 9 erreichen kann, ist jedoch kleiner als für die lokalen Speichervorrichtungen 5-1 bis 5-4 des Rechenknotens 1-1 bis 1-4, insbesondere für kleine Zugriffsgrößen. Neben diesen Komponenten, die jedes Rechenzentrum benutzt, wird ein gesondertes System zum Betreiben des UDS-Namensservers 6 verwendet. Der Namensserver 6 verwaltet alle verteilten UDS-Dateien und führt seinen Clients die Informationen zu, die erforderlich sind, um die Fragmente abzurufen, die eine Datei bilden. Wenngleich der Namensserver 6 auf dem Frontend 10 oder sogar auf einem der Rechenknoten 1-1 bis 1-4 laufen könnte, ist es ratsam, ihn auf einem gesonderten System laufen zu lassen. Ohne einen laufenden UDS-Namensserver 6 kann keine UDS-Datei geöffnet werden, und es sind keine Informationen auf dem UDS-Namensraum zugänglich. Es ist daher wichtig, die Verfügbarkeit des UDS-Namensserver betreibenden Systems zu erhöhen. Um dies zu erreichen, ist es bevorzugt, mehrere, beispielsweise redundante, Namensserver 6-1 und 6-2 auf gesonderten Host-Systemen laufen zu lassen, wie in der Ausführungsform in 3 dargestellt ist. Diese Host-Systeme 6-1 bis 6-2 müssen auf eine gemeinsame Datenbank zugreifen, die vorzugsweise über ein gesondertes Speichersystem 12 mit hohen Verfügbarkeitseigenschaften verwirklicht wird. Der Namensserver 6 ist über ein (Gigabit)-Ethernet mit den Rechenknoten 1-1 bis 1-4 und dem Frontend 10 verbunden. Ein weiterer Vorteil, der darin besteht, den Namensserver 6 nicht auf einem der Rechenknoten 1-1 bis 1-6 laufen zu lassen, besteht in der Verringerung der Rechenbelastung, die nicht auf die Anwendungen bezogen ist, die auf dem Knoten laufen. Es ist auch möglich, daß externe Host-Systeme 13 in der Art von Benutzerarbeitsstationen nur über das (Gigabit)-Ethernet-Netzwerk Zugang zum Rest des Systems haben.
4 zeigt die gleiche Architektur wie 3, es sind darin jedoch einige zusätzliche Softwarekomponenten des UDS dargestellt. Die permanenten Komponenten laufen vorzugsweise ständig unter einem speziellen Benutzerkonto oder unter ”root” (Administrator), und sie sind in 4 als 7-1 bis 7-4 dargestellt. Andere Komponenten des UDS laufen vorzugsweise auf Anforderung und sind in den Szenariobeispielen aus den 5 bis 9 ersichtlich. Der UDS-Namensserver 6 verwaltet den UDS-Namensraum. Zu diesem Zweck unterhält er eine Datenbank, die einen Datensatz für jede UDS-Datei und die Dateifragmente enthält. Zusätzlich wird irgendein globaler Zustand in dieser Datenbank permanent beibehalten. Es kann mehr als ein Namensserver 6-1 und 6-2, wie in den 4 bis 10 dargestellt ist, verwendet werden, um das UDS verfügbar zu halten, selbst wenn ein Namensserver aus irgendeinem Grund ausfallen sollte. Der Namensserver 6 wird jedesmal dann abgefragt, wenn eine UDS-Datei erzeugt, erneut geöffnet, geschlossen, bewegt oder gelöscht wird oder wenn Informationen zum aktuellen Zustand einer UDS-Datei erforderlich sind. Der Namensserver 6 ist nicht für den wirksamen Zugriff auf die Dateidaten erforderlich. Die gesonderten E/A-Prozesse 4-x (IOPs) sind tatsächlich Teil der MPI-Anwendung (AP) des Benutzers, wobei x eine natürliche Zahl ist, sie sind jedoch für den Benutzer nicht sichtbar. Die gesonderten E/A-Prozesse werden durch eine UDS-Komponente innerhalb der MPI-Bibliothek genau in dem Moment hervorgebracht, in dem die Anwendung eine UDS-Datei öffnet. Wenigstens ein gesonderter E/A-Prozeß 4-x wird auf jedem Knoten aktiviert, auf dem sich Fragmente der UDS-Datei befinden. In manchen spezifischen Situationen kann es auch bevorzugt sein, daß mehr als ein gesonderter E/A-Prozeß auf einem Knoten aktiviert wird oder daß ein gesonderter E/A-Prozeß auf einem Knoten, auf dem sich das gewünschte Dateifragment nicht selbst befindet, sondern auf einer gemeinsam verwendeten Platte, die mit diesem Knoten verbunden ist, aktiviert wird. Für eine neue Datei sind diese (standardmäßig) die Knoten, auf denen die Anwendung, d. h. die individuellen Anwendungen 3-x, läuft. Die gesonderten E/A-Prozesse kommunizieren mit den Anwendungsprozessen über MPI-Nachrichten. Die UDS-Dämonen 7-x (udsd) laufen auf den Rechenknoten 1-x als ein Dienstprozeß. Sie sind erforderlich, um Informationen über UDS-Dateifragmente dem Namensserver 6 und den UDS-Befehlszeilentools 8 zuzuführen. Sie werden zusätzlich verwendet, um einen begrenzten Satz von Aktionen, wie Löschen, Kopieren usw., an den Fragmenten auszuführen. Die Dämonen laufen als residente Prozesse unter root, sie können jedoch auch auf Anforderung, beispielsweise unter dem jeweiligen Benutzerkonto, gestartet werden, falls residente Prozesse nicht erwünscht sind. Die UDS-Befehlszeilentools 8 ermöglichen es dem Benutzer, den UDS-Namensraum auch von externen, beispielsweise nicht rechnenden Host-Systemen 13 zu verwalten. Die Befehlszeilentools 8 führen Verzeichnisauflistungen aus und liefern Dateistatusinformationen, und sie werden auch verwendet, um Dateien zwischen dem UDS-Namensraum und einem externen Dateisystem auszutauschen. Die Befehlszeilentools 8 können auf jedem externen Knoten 10, 13 ausgeführt werden, der eine Verbindung zum Namensserver 6 und den Rechenknoten 1-x, beispielsweise über TCP/IP, herstellen kann. Die in den 5 bis 9 angegebenen Beispielsszenarien zeigen die aktiven UDS-Komponenten, ihre Relationen und Dateizugriffsaktivitäten, die an der Ausführung einer bestimmten Aufgabe beteiligt sind. Diese Aktivitäten werden nachstehend erklärt, um die Interaktion der UDS-Komponenten für die von einem Benutzer ausgeführten typischen Aufgaben zu erläutern.
MPI-Anwendungen, die auf eine neu erzeugte UDS-Datei zugreifen, sind in 5 dargestellt. Eine MPI-Anwendung des Benutzers, beispielsweise Larry, besteht in diesem Beispiel aus sechs Prozessen oder individuellen Anwendungen 3-1 bis 3-6, die auf den Rechenknoten 1-2, 1-3 und 1-4 laufen. Die Anwendung öffnet eine Datei mit dem Namen uds:/uds/larry/output_data.dat. Weil der Namensserver 6 diese Datei nicht kennt, wird eine neue Datei erzeugt. Die Datei wird vorzugsweise über alle Knoten 1-2 bis 1-4 zerlegt, auf denen die Anwendung gegenwärtig läuft. Es ist jedoch, falls gewünscht, auch möglich, die Datei über alle gewünschten Knoten zu zerlegen, wie beispielsweise in 1 dargestellt ist. Der Dateiname impliziert, daß die Datei in dem Pfad/uds/larry gespeichert wird, der auf jedem Rechenknoten 1-2, 1-3 und 1-4 auf ein lokales Dateisystem abgebildet ist. Daher muß dieses Verzeichnis existieren und für den Benutzer auf allen beteiligten Knoten zugänglich sein. Alle E/A-Aktivitäten werden von den gesonderten E/A-Prozessen 4-x (IOPs) ausgeführt, welche vom UDS hervorgebracht wurden, als die Datei geöffnet wurde. Sobald die gesonderten E/A-Prozesse 4-x die Dateifragmente auf den Knoten 1-2 bis 1-4 erzeugt haben, führen sie alle Dateizugriffe für die Anwendungsprozesse 3-x aus. Der Dateiaustausch zwischen den individuellen Anwendungen 3-x und den gesonderten E/A-Prozessen 4-x erfolgt, sowohl innerhalb eines Knotens als auch zwischen Prozessen auf verschiedenen Knoten, über MPI-Nachrichten.
Die Situation, in der eine MPI-Anwendung eine existierende UDS-Datei öffnet, ist in 6 dargestellt. In diesem Beispiel läuft eine aus zwei Prozessen 3-1 und 3-2 bestehende MPI-Anwendung auf dem Rechenknoten 1-1. Er öffnet gegenwärtig eine existierende UDS-Datei, die zuvor von einer anderen Ausführung einer Anwendung erzeugt wurde. Der Prozeß 3-1 der Anwendung stellt eine Verbindung zum Namensserver 6-2 her, um die Informationen zu bekommen, wie auf die Datei zuzugreifen ist. Der Namensserver 6-2 teilt der individuellen Anwendung 3-1 mit, daß die Datei aus einem einzigen Fragment besteht, das sich auf dem Rechenknoten 1-2 befindet. Zum Zugreifen auf diese Datei bringt das UDS den gesonderten E/A-Prozeß 4-1 auf diesem Rechenknoten 1-2 hervor, der auf die Datei zugreift und die Daten mit der Anwendung 3-1, 3-2 unter Verwendung von MPI-Nachrichten austauscht.
Die Verwendung eines Befehlszeilentools 8 in der Art des Importierens einer Datei in den UDS-Namensraum ist in 7 dargestellt. In diesem Beispiel möchte der Benutzer Harry eine Eingangsdatei, die sich gegenwärtig in ihrem nativen Format auf dem externen Speichersystem (Dateiname/ext/home/harry/input.dat) befindet, in den UDS-Namensraum übertragen. Weil der Benutzer wiederholt aus dieser großen Datei lesen muß, möchte er, daß sie sich so dicht wie möglich bei den Anwendungsprozessen befindet. Sie befindet sich daher vorzugsweise auf den lokalen Platten 5-x. Weil der Benutzer seine Anwendung 3-x typischerweise auf den zwei Rechenknoten 1-1 und 1-4 ausführt, entscheidet er, auch die Datei über zwei Knoten zu zerlegen. Um dies zu erreichen, ruft er den Befehl 8-1: udscp -p -f 2 -n 1-1, 1-4/ext/home/harry/input.dat uds:/uds/harry aus dem Frontend-Knoten 10 auf. Die Option -f 2 legt die Anzahl der Dateifragmente (Zerlegungsfaktor) auf zwei. Der Kopierbefehl (udscp) des Befehlszeilentools kontaktiert den Namensserver 6 (6-1), der mitteilt, welche Knoten zu verwenden sind. Anschließend stellt der Kopierbefehl (udscp) eine Verbindung zum Dämon 7-1 und 7-4 (udsd) auf jedem dieser Knoten 1-1 und 1-4 her, welche einen untergeordneten Prozeß 70-1 und 70-4 als einen Dienstprozeß zum Ausführen der Anforderungen dieses Benutzers hervorbringen, wobei der Dienstprozeß 70-1 und 70-4 im Kontext des aufrufenden Benutzers ausgeführt wird. Zum Ausführen der angeforderten Aktion übertragen die Dienstprozesse 70-1 und 70-4 die jeweiligen Teile der Eingangsdatei zum spezifischen Ort auf den lokalen Platten 5-1 und 5-4 (/uds/harry). Weil der Benutzer die -p-Option verwendet hat, greifen die Dienstprozesse 70-1 und 70-4 beide direkt auf die Eingangsdatei zu und lesen sie parallel über das Speichernetzwerk. Die Dienstprozesse brauchen während dieses Imports keine Daten miteinander auszutauschen. Falls die Eingangsdatei nicht direkt für die Dienstprozesse zugänglich ist, wie es der Fall wäre, falls sie auf einer lokalen Platte des Frontend-Knotens gespeichert wäre, würde der Kopierbefehl 8-1 (udscp) die Datei über die gleiche Verbindung, die zum Senden der Anforderung zum Dämon 7-x verwendet wird, zum Dienstprozeß senden.
Die Situation, in der ein Befehlszeilentool 8 den Namensserver 6 abfragt, ist in 8 dargestellt. Ein anderer Benutzer möchte Statusinformationen zu einer spezifischen UDS-Datei haben. Der Benutzer verwendet zu diesem Zweck ein anderes UDS-Befehlszeilentool 8-1 (udsls). Der Befehl 8-1 (udsls) stellt einen Kontakt zum Namensserver 6 her und übergibt die Informationen an den Benutzer. Falls der Benutzer die Option -n zu diesem Befehl hinzugefügt hätte, würde udsls die vom Namensserver empfangenen Informationen anhand des tatsächlichen Zustands der Dateifragmente auf den Knoten prüfen. Diese Überprüfung kann durch Kontaktieren der UDS-Dämonen ausgeführt werden.
Ein weiteres Beispiel der Verwendung eines Befehlszeilentools 8 zum Abfragen einer UDS-Datei ist in 9 dargestellt. Ebenso wie im vorstehenden Beispiel gab der Benutzer an, daß er nicht fordert, daß die zurückgegebenen Informationen die aktuellsten verfügbaren Informationen sind und daß es ausreichend ist, die Informationen zurückzugeben, die der Namensserver 6 in seiner Datenbank verfügbar hat. Falls jedoch eine Anwendung gegenwärtig die Datei zum Anhängen von Daten geöffnet hat, würden manche Informationen, wie die vom Namensserver 6 zurückgegebene Dateigröße, nicht mit der tatsächlichen angesammelten Größe der Fragmente an den Knoten übereinstimmen. Um diese aktualisierten Informationen zu bekommen, kontaktiert der Befehl udsls die Dämonen 7-x an den jeweiligen Knoten 1-x. Dieser Fall ist für das UDS-Befehlszeilentool 8-1, das beispielsweise auf dem externen System 13 ausgeführt wird, dargestellt. Neben der Verbindung mit dem Namensserver 6-1 weist dieses Tool auch eine Verbindung zu einem vom Dämon erzeugten Dienstprozeß 70-1 am Rechenknoten 1-1 auf. Dieser Dienstprozeß sammelt aktuelle Informationen zu dem auf der lokalen Platte 5-1 gespeicherten Dateifragment und gibt sie zu udsls zurück.
Es ist zu verstehen, daß die Verwendung des UDS in keiner Weise auf die vorstehende Beispielkonfiguration und die angegebenen Aktivitäten beschränkt ist. Infolge seiner Flexibilität könnte der Benutzer auch UDS-Dateien auf dem externen Speichersystem dieser Konfiguration erzeugen oder irgendeine andere Konfiguration ausnutzen, die nicht von diesen Beispielen abgedeckt wird.
Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung besteht eine Aufgabe darin, eine skalierbare E/A-Bandbreite zum Zugreifen auf eine einzige Datei mit einer MPI-Anwendung bereitzustellen. Die Bandbreite sollte daher mit der Größe der Anwendung skalieren. In diesem Zusammenhang wird die Größe einer Anwendung als die Anzahl der auch als individuelle Anwendungen bezeichneten Prozesse angesehen, die zum Ausführen der Anwendung verwendet werden. Dies steht typischerweise in direkter Beziehung zur Größe des von dieser Anwendung verarbeiteten Problems und zum E/A-Umfang, den diese Anwendung ausführen muß. Die Verwendung einer zunehmenden Anzahl von Prozessen für eine Anwendung bedeutet die Verwendung einer größeren Anzahl von Rechenknoten, weil es häufig ein festes systemabhängiges Verhältnis zwischen der Anzahl der Prozesse und der Anzahl der Knoten gibt, die zum Ausführen der Prozesse verwendet werden. Zum Skalieren der E/A-Bandbreite mit der Anzahl der Knoten 1-x wird jede UDS-Datei in regelmäßiger Weise über eine beliebige Anzahl von Knoten verteilt: Die Datei wird vorzugsweise linear in Blöcke einer festen Größe eingeteilt, und der erste Datenblock wird auf dem ersten Knoten gespeichert, der zweite Block wird auf dem zweiten Knoten gespeichert usw. Für n Knoten, die Blöcke der Datei enthalten, wird der (n + 1)-te Block wiederum auf dem ersten Knoten gespeichert, wobei ein umlaufendes Verteilungsmuster verwendet wird. Dieser Verteilungstyp wird als Zerlegung bezeichnet. Die Größe der Blöcke wird als Zerlegungseinheit bezeichnet, und die Anzahl der zum Verteilen der Datei verwendeten Knoten wird als der Zerlegungsfaktor bezeichnet. 10 zeigt die zerlegte Verteilung einer einzigen Datei 20 auf eine Anzahl von drei Knoten 1-1 bis 1-3, beginnend vom Knoten 1-1. Die sich ergebenden Teildateien 20-1, 20-2 und 20-3 auf jedem Knoten sind die Fragmente oder Dateifragmente.
Weil jeder Knoten 1-x unabhängig von den anderen Knoten auf seine Datenblöcke zugreift, addiert sich die Bandbreite all dieser gleichzeitigen Zugriffe zur für die Anwendung verfügbaren Gesamtbandbreite. Zur vollen Ausnutzung dieses Effekts ist es jedoch erforderlich, daß jeder Knoten ein Speichersystem verwendet, das von allen anderen Knoten unabhängig ist. Dies kann unter Verwendung der lokalen Platten der Knoten erreicht werden, die außerhalb des Knotens nicht sichtbar sind. Falls die Knoten 1-x Speichervorrichtungen 11 verwenden, die zwischen Knoten gemeinsam verwendet werden, kann die von der Anwendung erfahrene effektive Bandbreite kleiner sein als die Bandbreite, die ein einziger Knoten erfährt, multipliziert mit der Anzahl der Knoten. Der Grad dieser Beeinträchtigung hängt von den Eigenschaften der verwendeten Speichervorrichtung und der Art, in der die Anwendung auf die Datei zugreift, ab. Im schlimmsten Fall können die mehreren Knoten auf die Datei mit einer angesammelten Bandbreite zugreifen, die nicht höher ist als die von einem einzigen Knoten erfahrene Bandbreite. Bei dieser bevorzugten Ausführungsform erzeugt UDS eine neue Datei auf allen Knoten, auf denen die MPI-Anwendung läuft. Der beste Ort für die Datei sind die lokalen Platten 5-1 bis 5-4 eines Knotens. Das UDS ist jedoch nicht darauf beschränkt, eine neue Datei an jedem vordefinierten Ort auf den Knoten zu erzeugen. Weil die Fragmente lediglich gewöhnliche Dateien sind, können sie statt dessen auf jedem Dateisystem angeordnet werden und auf eine Speichervorrichtung darunter abgebildet werden, welche auf den Knoten sichtbar ist. Der Benutzer hat völlige Freiheit für das Anordnen einer UDS-Datei, wo immer er dies möchte, wobei die Anforderungen an die E/A-Bandbreite, die Kapazität, die externe Zugänglichkeit und andere Faktoren, wie beispielsweise eine begrenzte Dauerhaftigkeit der Dateisysteminhalte infolge von Systemvereinbarungen, zu berücksichtigen sind. Um den Benutzer bei der Spezifikation der Speicherorte für eine Datei zu unterstützen, unterstützt UDS wenigstens drei verschiedene Typen von Pfadspezifikationen, wie vorstehend detailliert beschrieben wurde.
Aus der Sicht eines Benutzers ist die Verwendung von UDS von einer MPI-Anwendung sehr einfach und erfordert nur die Verwendung eines UDS-Dateinamens. Alle MPI-Objekte werden noch unterstützt, wenn UDS verwendet wird. Die MPI-Anwendungen, die UDS verwenden, sind noch normale MPI-Anwendungen und werden wie gewöhnlich unter Verwendung der mpirun- oder mpiexec-Einleitungsbefehle gestartet. Um von MPI auf UDS-Dateien zuzugreifen, ist es lediglich erforderlich, den betreffenden MPI-Funktionen, wie ”MPI_File_open()”, einen Dateinamen zuzuführen, der eine UDS-Pfadspezifikation impliziert, wie vorstehend detailliert erörtert wurde. Eine neue Datei wird dann über alle Knoten 1-x zerlegt, auf denen Prozesse laufen, die Teil des an ”MPI_File_open()” übergebenen Kommunikators sind. Falls ein impliziter Pfad verwendet wurde, wird die Datei über alle Knoten 1-1 bis 1-n zerlegt, die diesem impliziten Pfad zugeordnet sind. Es ist auch möglich, explizit die zu verwendenden Knoten oder den Zerlegungsfaktor zu spezifizieren. Falls eine existierende Datei geöffnet wird, bleibt sie vorzugsweise über diese Knoten zerlegt, auf die sie bei der Erzeugung zerlegt wurde. UDS gewährleistet, daß die Daten zwischen den Knoten, auf denen die individuellen Anwendungen 3-x der Anwendung 3 laufen, und den Knoten, welche die Datei speichern, wirksam ausgetauscht werden. Zusätzliche Dateiinformationen können durch die Anwendung 3 unter Verwendung von ”MPI_Info”-Objekten der MPI-Bibliothek zugeführt werden, wenn eine Datei geöffnet wird. Umgekehrt liefert die MPI-Bibliothek auch Informationen über eine offene UDS-Datei, die unter Verwendung von MPI_Info-Objekten abgerufen werden kann. MPI-IO definiert ein gemeinsames Datenformat für die einzelnen in eine Datei geschriebenen Elemente vom MPI-Typ. Dieses Datenformat kann unter Verwendung der external32-Datendarstellung gewählt werden. Für einen einzigen UDS-Namensraum, auf den von mehr als einem System zugegriffen wird, auf dem MPI-Anwendungen auf der Grundlage einer MPI-Bibliothek ausgeführt werden, kann das UDS beispielsweise das Endian-bezogene Datenformat der Dateien automatisch verwalten, um jeder Anwendung eine korrekte Sicht der Daten in der Datei zu bieten, selbst wenn die Standard-Datendarstellung verwendet wird.
Das UDS ist in der Lage, verschiedene Datenformate zu verwalten, wobei eine bestimmte Verwaltung in weiteren Einzelheiten beschrieben wird. Gemäß einer Ausführungsform legt das UDS die Byte-Reihenfolgeeinstellungen (Big-Endian oder Little-Endian) von UDS-Dateien im Moment der Erzeugung durch die MPI-IO-Schnittstelle fest. Wenn eine Datei zum ersten Mal erzeugt wird, ist der Endian-Typ (Big oder Little) für die Daten, die von dieser Anwendung in diese Datei geschrieben werden der native Endian-Typ der verwendeten Maschine. Dies bedeutet, daß der Inhalt einer neu erzeugten Datei eine genaue binäre Kopie der Daten im Speicher wird. Der Endian-Typ einer UDS-Datei kann unter Verwendung des Befehlszeilentools udsstat bestimmt werden. Es ist vorzugsweise nicht ratsam, den Endian-Typ einer UDS-Datei zu ändern, weil dies bei inkonsistenter Verwendung zu einer Datenverfälschung führt. Das Befehlszeilentool udsadmin ermöglicht jedoch das Festlegen des Endian-Typs einer UDS-Datei. Manche Plattformen unterstützen einen Modus mit erweiterter Breite, wodurch die Größe der Integral- und Gleitkomma-Datentypen auf mindestens 8 Bytes erhöht wird. Falls eine neue Datei erzeugt wird und die Datendarstellung auf external32 gesetzt wird, bevor Daten in die Datei geschrieben wurden, speichert das UDS auch die relevanten Datenformateigenschaften. In beiden Fällen verwaltet das UDS dieses erweiterte Datenformat in der gleichen Weise, in der es verschiedene Endian-Formate behandelt. Ebenso können diese Dateiattribute über die Befehlszeilentools udsstat und udsadmin abgerufen und extern festgelegt werden. Für UDS-Dateien, die nicht durch die MPI-IO-Schnittstelle, sondern über eine externe Schnittstelle erzeugt werden, müssen diese Dateiattribute möglicherweise explizit spezifiziert werden. Wenn eine existierende UDS-Datei über MPI-IO zum Lesen oder Schreiben geöffnet wird, wird das Endian-Format der Daten automatisch umgewandelt, so daß es sowohl mit der erforderlichen Darstellung der Daten im Speicher der Maschine, auf der die Anwendung läuft, als auch mit der gespeicherten Endian-Einstellung der UDS-Datei übereinstimmt. Dies gilt für alle vordefinierten Mehrbyte-MPI-Datentypen und auch für die entsprechenden Elemente abgeleiteter MPI-Datentypen. Dies bedeutet, daß, wenn das native Endian-Format der Maschine von der Endian-Einstellung der Datei verschieden ist, die Bytereihenfolge aller Datenelemente bei allen Lese- und Schreibvorgängen geändert wird. Falls beide, nämlich das Endian-Format der Maschine und die Endian-Einstellung der Datei, identisch sind, werden die Daten direkt zwischen dem Speicher und der Datei übertragen. Die Dateizugriffsbandbreite ist natürlich für einen Dateizugriff höher, bei dem keine Byteumordnung auftritt.
Es ist möglich, die implizite Datentransformation durch Erzwingen eines bestimmten Endian-Typs einer Datei zu überschreiben. Dies kann geschehen, indem ein geeignetes ”MPI_Info”-Objekt an ”MPI_File_open()” oder ”MPI_File_set_info()” übergeben wird. Dieses Objekt muß den Schlüssel endian_file enthalten, wodurch die Werte Big, Little und Nativ unterstützt werden. Die Werte Big und Little bewirken, daß alle geschriebenen Daten in das jeweilige Endian-Format umgewandelt werden, bevor sie in der Datei gespeichert werden. Ebenso wird angenommen, daß aus der Datei gelesene Daten das angegebene Endian-Format aufweisen und in das native Endian-Format der Maschine umgewandelt werden, bevor sie im Speicher gespeichert werden. Für den Wert Nativ werden die äquivalenten Operationen auf der Grundlage des nativen Endian-Formats der Maschine ausgeführt. Weil bei der Verwendung dieses Verfahrens das Endian-Format der vom UDS verwalteten Datei explizit überschrieben wird, ändert UDS nicht die permanente Einstellung des Endian-Formats der Datei beim Namensserver. Dies impliziert das Risiko des Verfälschens von Daten einer Datei, falls die explizite Datentransformation inkorrekt verwendet wird. Die implizite Endian-Transformation gilt gemäß dieser Ausführungsform nur für Dateien, auf welche unter Verwendung der nativen Datendarstellung über die MPI-IO-Schnittstelle zugegriffen wird. Falls auf eine Datei über die externe Schnittstelle zum UDS zugegriffen wird, werden die Daten ohne eine Transformation aus dem Speicher gelesen oder in diesen geschrieben. Falls auf die Datei durch die MPI-IO-Schnittstelle über eine andere Datendarstellung als die native zugegriffen wird, werden die Daten nur entsprechend der verwendeten Datendarstellung transformiert, ohne daß eine implizite Endian-Transformation ausgeführt wird. Falls bei dieser Gelegenheit Daten in die Datei geschrieben werden, markiert das UDS die Endian-Einstellung dieser Datei als unbekannt. Das Gleiche gilt für UDS-Dateien, die nicht durch die MPI-IO-Schnittstelle, sondern über die externe Schnittstelle erzeugt worden sind. Das Zugreifen auf UDS-Dateien mit einer unbekannten Endian-Einstellung durch die MPI-IO-Schnittstelle führt dazu, daß die Lese-/Schreiboperation den Fehler MPI_ERR_FORMAT erzeugt, falls die native Datendarstellung gegeben ist und die Lese-/Schreiboperation einen MPI-Datentyp verwendet, der eine Endian-Transformation erfordert. Die Daten werden zwischen dem Speicher und einer Datei übertragen, ohne daß eine Datentransformation ausgeführt wird. Dies bedeutet, daß, falls die Anwendung weiß, wie die Daten richtig zu behandeln sind, diese trotz dieser Fehlerbedingung fortgesetzt werden kann.
Falls der Endian-Typ der Knoten, auf denen Prozesse einer einzigen MPI-Anwendung ablaufen, nicht für alle Knoten gleich ist, ist die Endian-Einstellung dieser Datei von Beginn an unbekannt, falls die native Datendarstellung verwendet wird. Es ist in diesem Fall empfehlenswert, die external32-Datendarstellung zu verwenden, wodurch der Endian-Typ auf Big gesetzt wird.
Die vorstehende detaillierte Beschreibung soll nur bestimmte bevorzugte Ausführungsformen der vorliegenden Erfindung erläutern. Sie soll in keiner Weise den Schutzumfang der Erfindung gemäß den Ansprüchen beschränken.

Claims

Datenspeicher- und Zugriffssystem zur Verwendung mit einem oder mehreren Parallelverarbeitungssystemen mit mehreren Knoten (1-1, 1-2, ..., 1-n) für Anwendungen (3) zur parallelen Datei-Ein-/Ausgabe, wobei a) eine Datendatei (2), die für die Anwendung (3) zugänglich ist, in mehrere Dateifragmente (2-1, 2-2, ..., 2-m) unterteilt ist, b) die Dateifragmente (2-1, 2-2, ..., 2-m) verteilt auf mehreren Speichereinrichtungen (5-1, 5-2, ..., 5-L) gespeichert sind, die innerhalb des Parallelverarbeitungssystems zugänglich sind, wobei die Unterteilung und Verteilung der Dateifragmente individuell von einem Benutzer definierbar ist, c) die Anwendung (3) in mehrere individuelle Anwendungen (3-1, 3-2, ..., 3-k) unterteilt ist und jede der individuellen Anwendungen (3-1, 3-2, ..., 3-k) auf einem individuellen Knoten (1-1, 1-2, ..., 1-n) laufen kann, d) wenigstens eine Verteilungsinformationseinrichtung (6) dafür eingerichtet ist, Informationen über die Verteilung der Dateifragmente (2-1, 2-2, ..., 2-m) wenigstens einer der individuellen Anwendungen (3-1, 3-2, ..., 3-k) zur Verfügung zu stellen, und e) wenigstens ein gesonderter E/A-Prozeß (4-1, 4-2, ..., 4-c) von einer oder mehreren individuellen Anwendung (3-1, 3-2, ..., 3-k) in Abhängigkeit der Verteilung der gespeicherten Dateifragmente (2-1, 2-2, ..., 2-m) gestartet wird, wenn die Anwendung (3-1, 3-2, ..., 3-k) die Datendatei (2) für den späteren Zugriff öffnet, wobei die Gesamtheit der E/A-Prozeße einen Zugang zu den gespeicherten Dateifragmenten (2-1, 2-2, ..., 2-m) auf den Speichereinrichtungen (5-1, 5-2, ..., 5-L) hat, und jeder der E/A-Prozesse (4-1, 4-2, ..., 4-c) über Nachrichten einer Nachrichtenübertragungsschnittstelle (Message Passing Interface – MPI) mit den individuellen Anwendungen (3-1, 3-2, ..., 3-k) kommunizieren, und f) das Datenspeicher- und Zugriffssystem auf ein natives, verfügbares Dateisystem der Knoten (1-1, 1-2, ..., 1-n) aufsetzt.
Datenspeicher- und Zugriffssystem nach Anspruch 1, wobei die Daten der Datendatei (2) in bzw. zwischen Datentypdarstellungen im Speicher gelesen und/oder gespeichert und/oder erzeugt und/oder transformiert werden können und die Datei (2) in den verschiedenen Speichereinrichtungen gespeichert wird.
System nach Anspruch 2, wobei die Daten transformiert werden, wenn sie vom Speicher zu den Speichereinrichtungen übertragen werden.
System nach einem der Ansprüche 2 oder 3, wobei die Daten transformiert werden, wenn sie von den Speichereinrichtungen zum Speicher übertragen werden.
System nach einem der Ansprüche 2 bis 4, wobei die Datentransformation für Dateien bereitgestellt wird, auf die über die MPI-IO-Schnittstelle zugegriffen wird.
System nach einem der Ansprüche 2 bis 5, wobei das System eine implizite Datentransformation zwischen verschiedenen Datentypdarstellungen bereitstellt.
System nach einem der Ansprüche 2 bis 6, wobei ein Benutzer eine Datentransformation explizit über die MPI-IO-Schnittstelle spezifizieren kann.
System nach einem der Ansprüche 2 bis 7, wobei der native Endian-Datentyp der Maschine, auf der die Anwendung läuft, verwendet wird, wenn eine neue Datei (2) mit der MPI-IO-Schnittstelle erzeugt wird.
System nach einem der Ansprüche 2 bis 8, wobei, wenn eine existierende Datei (2) über MPI-IO zum Lesen oder Schreiben geöffnet wird, das Endian-Format der Daten automatisch transformiert wird, so daß es sowohl mit der Darstellung der Daten im Speicher der Maschine, auf der die Anwendung läuft, als auch mit der gespeicherten Endian-Einstellung der Datei übereinstimmt.
System nach einem der Ansprüche 2 bis 9, wobei die Byte-Reihenfolge aller Datenelemente bei allen Lese- und Schreiboperationen geändert wird, wenn das native Endian-Format der Maschine von der Endian-Einstellung der Datei verschieden ist.
System nach einem der Ansprüche 2 bis 10, wobei die Daten direkt zwischen dem Speicher und der Datei übertragen werden, wenn das native Endian-Format der Maschine mit der Endian-Einstellung der Datei identisch ist.
System nach einem der Ansprüche 2 bis 11, wobei Dateiattribute verschiedener Datentypdarstellungen über Befehlszeilentools abgerufen und extern festgelegt werden können.
System nach einem der Ansprüche 2 bis 12, wobei, wenn über eine externe Schnittstelle auf eine Datei zugegriffen wird, die Daten ohne eine Transformation in den Speicher geschrieben oder aus dem Speicher gelesen werden.
System nach einem der Ansprüche 2 bis 13, wobei das Datenformat eines vom Endian-Typ Big, Endian-Typ Little, external32 oder eine andere übliche Datentypdarstellung sein kann.
System nach einem der Ansprüche 1 bis 14, wobei es jeder individuellen Anwendung (3-1, 3-2, ..., 3-k) erlaubt werden kann, auf die ganze Datendatei (2) zuzugreifen.
System nach einem der Ansprüche 1 bis 15, wobei nur ein gesonderter E/A-Prozeß (4-1, 4-2, ..., 4-0) von der Anwendung auf einem Knoten (1-1, 1-2, ..., 1-n) gestartet wird, der einen Zugang zu den Speichereinrichtungen (5-1, 5-2, ..., 5-l) aufweist, welche das Dateifragment (2-1, 2-2, ..., 2-m) aufweisen, auf das von der Anwendung (3) zugegriffen wird.
System nach einem der Ansprüche 1 bis 16, wobei das Datenspeichersystem nicht auf die Verwendung vordefinierter Knoten (1-1, 1-2, ..., 1-n), Speichereinrichtungen (5-1, 5-2, ..., 5-l) und Pfade auf diesen Knoten (1-1, 1-2, ..., 1-n) beschränkt ist.
System nach einem der Ansprüche 1 bis 17, wobei wenigstens eine der Speichereinrichtungen (5-1, 5-2, ..., 5-l) eine lokale Speichervorrichtung eines Knotens (1-1, 1-2, ..., 1-n) ist.
System nach einem der Ansprüche 1 bis 18, wobei wenigstens eine der Speichereinrichtungen (5-1, 5-2, ..., 5-l) eine gemeinsam verwendete Speichervorrichtung mehrerer Knoten (1-1, 1-2, ..., 1-n) ist.
System nach einem der Ansprüche 1 bis 19, wobei der Benutzer und/oder der Systemadministrator spezifizieren darf, wo die Dateifragmente (2-1, 2-2, ..., 2-m) zu speichern sind.
System nach einem der Ansprüche 1 bis 20, wobei der Dateizugriff der Anwendung (3) durch die Anwendung (3) und die individuellen Anwendungen (3-1, 3-2, ..., 3-k) selbst gesteuert wird.
System nach einem der Ansprüche 1 bis 21, wobei das System eine globale Sichtbarkeit jeder aus mehreren Dateifragmenten (2-1, 2-2, ..., 2-m) bestehenden Datendatei (2) bereitstellt.
System nach einem der Ansprüche 1 bis 22, wobei das System mehrere Verteilungsinformationseinrichtungen (6-1, 6-2, 6-p) aufweist.
System nach einem der Ansprüche 1 bis 23, wobei das System Dienstprogramme (8) bereitstellt, um auf die Datendatei (2) durch globale Befehle zuzugreifen, sie aufzulisten, zu löschen und zu modifizieren.
System nach einem der Ansprüche 1 bis 24, wobei die Anwendung auf einem Parallelcomputer oder auf mehreren über ein Netzwerk verbundenen Computern laufen kann.
System nach einem der Ansprüche 1 bis 25, wobei die Dateifragmente (2-1, 2-2, ..., 2-m) und Speichervorrichtungen über ein natives Dateisystem zugänglich sind.
System nach einem der Ansprüche 1 bis 26, wobei jeder Knoten (1-1, 1-2, ..., 1-n) in der Lage ist, die individuellen Anwendungen (3-1, 3-2, ..., 3-k) auszuführen, und in der Lage ist, einem gewünschten Dateifragment (2-1, 2-2, ..., 2-m) einen E/A-Zugriff bereitzustellen.
System nach einem der Ansprüche 1 bis 27, wobei die Verteilungsinformationseinrichtung (6) auf einem oder mehreren der Knoten (1-1, 1-2, ..., 1-n) oder auf wenigstens einem zusätzlichen Knoten läuft.
System nach einem der Ansprüche 1 bis 28, wobei die Verteilungsinformationseinrichtung (6) eine Datenbank unterhält, welche einen Datensatz für jede Datei (2) und das entsprechende Dateifragment ((2-1, 2-2, ..., 2-m) enthält.
System nach einem der Ansprüche 1 bis 29, wobei die Verteilungsinformationseinrichtung (6) einen Systemnamensraum zum Verwalten des Speicherns der Dateien (2) und des Zugriffs auf diese bereitstellt.
System nach einem der Ansprüche 1 bis 30, wobei auf jedem Knoten (1-1, 1-2, ..., 1-n) ein Dämon (7-1, 7-2, ..., 7-n) bereitgestellt ist, um Informationen von den Dateifragmenten der Verteilungsinformationseinrichtung (6) bereitzustellen.
System nach Anspruch 31, wobei jeder Dämon als ein residenter Prozeß läuft oder auf Anfrage unter dem jeweiligen Benutzerkonto gestartet werden kann.
System nach einem der Ansprüche 1 bis 32, wobei die Kommunikation zwischen der Anwendung (3) der individuellen Anwendungen (3-1, 3-2, ..., 3-k) und der Verteilungsinformationseinrichtung (6) über TCP/IP erfolgt.
System nach Anspruch 33, wobei verschlüsselte Sockets für die TCP/IP-Kommunikation verwendet werden.
System nach einem der Ansprüche 1 bis 34, wobei die Verteilungsinformationseinrichtung (6) einen Namen einer Datei (2) in einer lokalen Metadarstellung abbildet, die alle Informationen zum Zugreifen auf die verteilten Dateifragmente (2-1, 2-2, ..., 2-m) aufweist.