DE112012002241T5

DE112012002241T5 - Migration eines transparenten Dateisystems zu einem neuen physischen Speicherort

Info

Publication number: DE112012002241T5
Application number: DE112012002241.6T
Authority: DE
Inventors: Alexei Leonidovich Pytel; Thomas Wasik; Kevin James Kathmann; Steven John Simonson; Bruce Talbott
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-05-26
Filing date: 2012-05-24
Publication date: 2014-04-10
Also published as: CN103562879A; CN103562879B; GB2506045B; GB2506045A; GB201322043D0; WO2012160533A1; US20120303913A1; US9003149B2

Abstract

Die Migration eines transparenten Dateisystems schließt ein Verfahren ein, das einen physischen Quellenspeicherort in einem Dateisystem identifiziert, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt. Ein physischer Zielspeicherort im Dateisystem wird identifiziert, und sein Inhalt wird zum physischen Zielspeicherort migriert. Das Migrieren schließt das Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort und das Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort ein. Eine Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wird vor oder während des Migrierens empfangen. Die Schreibanforderung wird gleichzeitig mit dem Migrieren bedient. An den physischen Quellenspeicherort gerichtete Lese- und Schreibanforderungen werden zum physischen Zielspeicherort umgeleitet. Die Umleitung erfolgt in Reaktion auf das Abschließen des Migrierens. Die Anforderungen kommen von den mehreren unabhängigen Prozessen und schließen sowohl logische als auch physische Ein-/Ausgaben ein.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft Dateisysteme und insbesondere die Migration eines transparenten Dateisystems zu einem neuen physischen Speicherort.
Hintergrund der Erfindung
Die meisten modernen Betriebssysteme bieten eine Möglichkeit, druckfertige Objekte in ihrem Dateisystem zu speichern und sie asynchron zum Drucker zu senden. Dies erlaubt Anwendungen, die Druckobjekte erzeugen, die Verarbeitung fortzusetzen, bevor der Drucker die Ausgabe tatsächlich ausdruckt. Dieser Prozess wird als SPOOLing (Simultaneous Peripheral Operations On-Line (gleichzeitiger Betrieb von Peripheriegeräten während der Verarbeitung)) bezeichnet, und die gespeicherten Daten werden als SPOOL-Dateisystem bezeichnet. Das SPOOL-Dateisystem kann auch zum Speichern von Information verwendet werden, die von Eingabeperipherieeinheiten wie z. B. Netzwerkeinheiten in einem System ankommt.
In einer Multi-Image-Betriebssystemumgebung (z. B. mehrere Betriebssysteme in einer verbundenen Umgebung) ist es vorteilhaft, wenn ein einzelnes SPOOL-Dateisystem von allen Betriebssystemimages gemeinsam benutzt wird. Ein Vorteil ist, dass dies Prozessen auf einem Image ermöglicht, auf Peripheriegeräte auf anderen Images zuzugreifen. In der gemeinsamen Umgebung wird von mehreren Prozessen (Threads) auf mehreren unabhängigen Betriebssystemimages gleichzeitig auf das SPOOL-Dateisystem zugegriffen (darin geschrieben oder daraus gelesen).
Ein SPOOL-Dateisystem kann als eine Reihe von Dateien im nativen Dateisystem des Betriebssystems realisiert sein. Es kann aber auch als ein neues logisches Dateisystem implementiert sein, das über dem nativen Dateisystem des Betriebssystems abgebildet ist. Dies erfolgt oft, um Begrenzungen, Einschränkungen und/oder Leistungsprobleme des nativen Dateisystems zu überwinden. Dateien im SPOOL-Dateisystem sind allgemein temporärer Art, werden einmal geschrieben und gelesen und können sehr groß sein. In einem großen Betriebssystem kann das SPOOL-Dateisystem mehrere physische/logische Speichereinheiten umspannen, um nicht nur der Größe der im SPOOL-Dateisystem befindlichen Objekte, sondern auch den erforderlichen Leistungsmerkmalen gerecht zu werden.
Ein SPOOL-Dateisystem, das als Dateisystem realisiert ist, das auf Objekte im nativen Dateisystem des Betriebssystems abgebildet ist, kann als ein logisches Dateisystem (LFS) aufgefasst werden. Wie bei jedem Dateisystem gibt es eine Anforderung, den für SPOOL-Dateien verfügbaren Speicherplatz zu vergrößern und zu verkleinern. Das Vergrößern des Speicherplatzes kann erreicht werden, indem ein neues natives Dateisystemobjekt zum SPOOL-Dateisystem hinzugefügt wird. Das Verkleinern des SPOOL-Dateisystems macht dann die Entfernung eines nativen Dateisystemobjekts aus dem SPOOL-Dateisystem notwendig. Doch bevor ein natives Dateisystemobjekt entfernt werden kann, müssen alle in diesem Objekt befindlichen SPOOL-Dateien aus dem Objekt entfernt werden. Um dies zu erreichen, besteht die herkömmliche Methode darin, das native Dateisystemobjekt als für neue SPOOL-Datensätze nicht verfügbar zu markieren und dann zu warten, bis die in diesem Objekt befindlichen SPOOL-Dateien gelöscht sind, da SPOOL-Dateien temporär sind. Sobald alle SPOOL-Dateien, die das Objekt verwenden, gelöscht wurden, kann das native Dateisystemobjekt aus dem SPOOL-Dateisystem entfernt und gelöscht werden.
Kurzdarstellung
Eine Ausführungsform ist ein Verfahren, das das Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem einschließt, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt. Ein physischer Zielspeicherort im Dateisystem wird identifiziert, und der Inhalt des physischen Quellenspeicherorts wird zum physischen Zielspeicherort migriert. Das Migrieren schließt das Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort und das Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort ein. Eine Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wird vor oder während des Migrierens empfangen. Die Schreibanforderung wird gleichzeitig mit dem Migrieren bedient. An den physischen Quellenspeicherort gerichtete Lese- und Schreibanforderungen werden zum physischen Zielspeicherort umgeleitet. Die Umleitung erfolgt in Reaktion auf den Abschluss der Migration. Die Anforderungen kommen von den mehreren unabhängigen Prozessen und schließen sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A ein.
Eine andere Ausführungsform ist ein System, das einen Prozessor aufweist, der konfiguriert ist, um ein Verfahren durchzuführen. Das Verfahren schließt das Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem ein, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt. Ein physischer Zielspeicherort im Dateisystem wird identifiziert, und der Inhalt des physischen Quellenspeicherorts wird zum physischen Zielspeicherort migriert. Das Migrieren schließt das Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort und das Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort ein. Eine Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wird vor oder während des Migrierens empfangen. Die Schreibanforderung wird gleichzeitig mit dem Migrieren bedient. An den physischen Quellenspeicherort gerichtete Lese- und Schreibanforderungen werden zum physischen Zielspeicherort umgeleitet. Die Umleitung erfolgt in Reaktion auf das Abschließen des Migrierens. Die Anforderungen kommen von den mehreren unabhängigen Prozessen und schließen sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A ein.
Eine weitere Ausführungsform ist ein Computerprogrammprodukt, das ein materielles Speichermedium einschließt, das durch eine Verarbeitungsschaltung lesbar ist und Anweisungen speichert, die zur Durchführung eines Verfahrens von der Verarbeitungsschaltung ausgeführt werden. Das Verfahren schließt das Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem ein, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt. Ein physischer Zielspeicherort im Dateisystem wird identifiziert, und der Inhalt des physischen Quellenspeicherorts wird zum physischen Zielspeicherort migriert. Das Migrieren schließt das Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort und das Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort ein. Eine Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wird vor oder während des Migrierens empfangen. Die Schreibanforderung wird gleichzeitig mit dem Migrieren bedient. An den physischen Quellenspeicherort gerichtete Lese- und Schreibanforderungen werden zum physischen Zielspeicherort umgeleitet. Die Umleitung erfolgt in Reaktion auf das Abschließen des Migrierens. Die Anforderungen kommen von den mehreren unabhängigen Prozessen und schließen sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A ein.
Zusätzliche Merkmale und Vorteile werden durch die Techniken der vorliegenden Erfindung realisiert. Weitere Ausführungsformen und Aspekte der Erfindung werden hierin im Detail beschrieben und als Teil der beanspruchten Erfindung betrachtet. Zum besseren Verständnis der Erfindung mit ihren Vorteilen und Merkmalen, siehe die folgende Beschreibung und die Zeichnungen.
Einem ersten Aspekt gemäß stellt die vorliegende Erfindung ein Verfahren bereit, umfassend: Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt; Identifizieren eines physischen Zielspeicherorts im Dateisystem; Migrieren des Inhalts des physischen Quellenspeicherorts zum physischen Zielspeicherort, wobei das Migrieren aufweist: Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort; Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort; Empfangen einer Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wobei das Empfangen vor oder während des Migrierens erfolgt; Bedienen der Schreibanforderung gleichzeitig mit dem Migrieren; und Umleiten, in Reaktion auf den Abschluss des Migrierens, von an den physischen Quellenspeicherort gerichteten Lese- und Schreibanforderungen zum physischen Zielspeicherort, wobei die Anforderungen von den mehreren unabhängigen Prozessen kommen und sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A aufweisen.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, das außerdem das Entfernen des physischen Quellenspeicherorts aus dem Dateisystem einschließt.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, wobei das Dateisystem ein „Simultaneous Peripheral Operations On-Line”(SPOOL)-Dateisystem ist.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, wobei das Migrieren und Umleiten ohne jede Änderung an den mehreren unabhängigen Prozessen durchgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, wobei die mehreren unabhängigen Prozesse auf mehreren Computersystemen ausgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, wobei das Umleiten mit einem virtualisierten Objekt durchgeführt wird.
Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, wobei das Umleiten mit einem logischen Dateisystem durchgeführt wird.
Einem anderen Aspekt gemäß stellt die vorliegende Erfindung ein System bereit, das einen Prozessor aufweist, der konfiguriert ist, um ein Verfahren durchzuführen, wobei das Verfahren aufweist: Mittel zum Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt; Mittel zum Identifizieren eines physischen Zielspeicherorts im Dateisystem; Mittel zum Migrieren des Inhalts des physischen Quellenspeicherorts zum physischen Zielspeicherort, wobei das Migrieren aufweist: Mittel zum Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort; Mittel zum Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort; Mittel zum Empfangen einer Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wobei das Empfangen vor oder während des Migrierens erfolgt; Mittel zum Bedienen der Schreibanforderung gleichzeitig mit dem Migrieren; und Mittel zum Umleiten, in Reaktion auf den Abschluss des Migrierens, von an den physischen Quellenspeicherort gerichteten Lese- und Schreibanforderungen zum physischen Zielspeicherort, wobei die Anforderungen von den mehreren unabhängigen Prozessen kommen und sowohl logische Ein/Ausgaben (E/A) als auch physische E/A aufweisen.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei das Verfahren außerdem Mittel zum Entfernen des physischen Quellenspeicherorts aus dem Dateisystem einschließt.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei das Dateisystem ein „Simultaneous Peripheral Operations On-Line”(SPOOL)-Dateisystem ist.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei die Mittel zum Migrieren und Umleiten ohne jede Änderung an den mehreren unabhängigen Prozessen durchgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei die mehreren unabhängigen Prozesse auf mehreren unterschiedlichen Computersystemen ausgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei das Mittel zum Umleiten mit einem virtualisierten Objekt durchgeführt wird.
Bevorzugt stellt die vorliegende Erfindung ein System bereit, wobei das Mittel zum Umleiten mit einem logischen Dateisystem durchgeführt wird.
Einem weiteren Aspekt gemäß stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, aufweisend: ein materielles Speichermedium, das durch eine Verarbeitungsschaltung lesbar ist und Anweisungen speichert, die zur Durchführung eines Verfahrens von der Verarbeitungsschaltung ausgeführt werden, wobei das Verfahren aufweist: Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt; Identifizieren eines physischen Zielspeicherorts im Dateisystem; Migrieren des Inhalts des physischen Quellenspeicherorts zum physischen Zielspeicherort, wobei das Migrieren aufweist: Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort; Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort; Empfangen einer Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wobei das Empfangen vor oder während des Migrierens erfolgt; Bedienen der Schreibanforderung gleichzeitig mit dem Migrieren; und Umleiten, in Reaktion auf den Abschluss des Migrierens, von an den physischen Quellenspeicherort gerichteten Lese- und Schreibanforderungen zum physischen Zielspeicherort, wobei die Anforderungen von den mehreren unabhängigen Prozessen kommen und sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A aufweisen.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei das Verfahren außerdem das Entfernen des physischen Quellenspeicherorts aus dem Dateisystem einschließt.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei das Dateisystem ein „Simultaneous Peripheral Operations On-Line”(SPOOL)-Dateisystem ist.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei das Migrieren und Umleiten ohne jede Änderung an den mehreren unabhängigen Prozessen durchgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei die mehreren unabhängigen Prozesse auf mehreren unterschiedlichen Computersystemen ausgeführt werden.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei das Umleiten mit einem virtualisierten Objekt durchgeführt wird.
Bevorzugt stellt die vorliegende Erfindung ein Computerprogrammprodukt bereit, wobei das Umleiten mit einem logischen Dateisystem durchgeführt wird.
Kurze Beschreibung der Zeichnungen
Eine bevorzugte Ausführungsform der vorliegenden Erfindung wird nun Bezug nehmend auf die beiliegenden Zeichnungen lediglich beispielhaft beschrieben, wobei:
1 ein System zeigt, das einer bevorzugten Ausführungsform der vorliegenden Erfindung gemäß realisiert ist.
2 ein Spool-Dateisystem vor der Migration gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
3 einen Gesamt-Prozessablauf zeigt, der einer bevorzugten Ausführungsform der vorliegenden Erfindung entsprechend realisiert ist.
4 ein Prozessablauf einer Migrationskonfigurationsphase gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist.
5 einen Prozessablauf einer ersten Phase in einer Migration gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
6 das SPOOL-Dateisystem von 2 während einer Migration von einem physischen Datenträger zu einem anderen physischen Datenträger gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
7 einen Prozessablauf einer zweiten Phase der Migration gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
8 das SPOOL-Dateisystem von 2 und 6 nach einer Migration von einem physischen Datenträger zu einem anderen physischen Datenträger gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
Ausführliche Beschreibung
Eine Ausführungsform weist ein Verfahren auf, um Daten von einem bestehenden nativen Dateisystemobjekt in einem SPOOL-Dateisystem zu verfügbarem Speicherplatz auf einem anderen Objekt zu kopieren, das im SPOOL-Dateisystem definiert ist. Das Kopieren erfolgt, ohne dass laufende Anwendungen davon Kenntnis haben, und verwendet ein Umadressierungssystem (z. B. einen Umsetzer), das SPOOL-Datenadressen von einem Quellenobjekt auf ein Zielobjekt abbildet. Nach Abschluss des Kopiervorgangs werden die Daten, die im ursprünglichen nativen Dateisystemobjekt im SPOOL-Dateisystem waren, auf einem anderen bestehenden Objekt, das dem SPOOL-Dateisystem zugeordnet ist, virtualisiert, und das ursprüngliche native Dateisystemobjekt wird gelöscht. Das virtualisierte Objekt besteht weiter, bis alle Benutzer des Objekts gelöscht werden. Freier Speicherplatz im virtualisierten (abgebildeten) Objekt ist durch das nicht virtualisierte Zielobjekt verfügbar.
Dies erlaubt die Verkleinerung des physischen Speicherplatzes, der vom SPOOL-Dateisystem belegt wird (das native Dateisystemobjekt wird gelöscht), ohne warten zu müssen, bis alle SPOOL-Dateien im logischen (virtualisierten) SPOOL-Objekt gelöscht sind. Aktive SPOOL-Dateien (solche, die von aktiven Threads oder Prozessen gelesen oder geschrieben werden) werden ohne Auswirkungen auf die Anwendungen, die SPOOL-Dateien benutzen, gehandhabt. Zusätzlich handhabt eine Ausführungsform Anwendungen, die Kenntnis des Speicherorts von Daten im SPOOL-Dateisystem haben (eine SPOOL-Datenadresse im logischen SPOOL-Dateisystem haben), und erlaubt ihnen, auf die Daten zuzugreifen, nachdem das SPOOL-Dateisystem verkleinert wurde. Anwendungen verwenden weiterhin logische Adressen, die an das „alte” SPOOL-Objekt adressiert sind. Dieses „alte” SPOOL-Objekt besteht noch als ein virtualisiertes Objekt, das in einem anderen physischen SPOOL-Objekt abgebildet ist, und die Anwendungen führen E/A mit den „alten” Adressen durch. Die Abbildungsfunktion, die in der SPOOL-E/A-Funktion integriert ist, ist in der Lage, die virtualisierte Umgebung und die physische Ziel-E/A zum korrekten physischen nativen Objekt des Betriebssystems zu erkennen. Zusätzlich hört das „alte” SPOOL-Objekt auf, zu existieren, sobald alle Anwendungen, die den „alten” SPOOL-Datenträger benutzen, die Verarbeitung beenden.
Die Unterstützung beider Anwendungstypen verhindert den simplen Prozess des Verlagerns von SPOOL-Dateien im logischen SPOOL-Dateisystem (LFS), da aktive Prozesse nicht in der Lage wären, Daten, die verlagert wurden, weiterzuverarbeiten, und SPOOL-Datenadressen, die Anwendungen bekannt sind, nicht mehr gültig sind, wenn die Daten verlagert worden sind.
Eine Ausführungsform wird in einer Umgebung verwendet, die mehrere verbundene Betriebssysteme und SPOOL-Daten einschließt, auf die von mehreren Prozessen (Threads) auf diesen Betriebssystemen zugegriffen wird.
Eine Ausführungsform, die hierin beschrieben wird, erlaubt die sofortige Löschung des nativen Betriebssystemobjekts, das verwendet wird, um ein Spool-Objekt unterzubringen. Dies erlaubt den Austausch eines Plattenlaufwerks ohne Auswirkung auf die Daten, die im SPOOL-Dateisystem gespeichert sind. Zudem gibt es keine Auswirkungen auf die Anwendungen, da keine Änderungen an SPOOL-„Zeigern” in Anwendungen und anderen SPOOL-Daten erforderlich sind, wenn das Plattenlaufwerk ausgebaut wird.
Eine Ausführungsform unterstützt sowohl ein LFS, das auf ein natives Dateisystem (wie z. B. ein SPOOL-Dateisystem) abgebildet ist, als auch ein LFS, das auf ein physisches Dateisystem (PFS) abgebildet ist, das auf mehrere physische Einheiten verteilt ist.
Eine Ausführungsform betrifft das Migrieren eines logischen Dateisystems (LFS), das auf einem Satz physischer Datenträger beruht, zu einem neuen Satz physischer Datenträger, auf eine transparente und unterbrechungsfreie Weise. Mehrere Hauptmerkmale des LFS bleiben während des Migrationsprozesses und danach beibehalten. Beispielsweise bleibt das Datenadressierungssystem erhalten, das von Anwendungen verwendet wird, um auf Daten im LFS zuzugreifen. Datenadressen werden auf automatische und transparente Weise umgestellt, um während des Migrationsprozesses und danach auf korrekte physische Datenträger zuzugreifen. Zusätzlich können physische Quellen- und Zieldatenträger mit unterschiedlichen Geometrien definiert werden, und der Umstellungsprozess berücksichtigt diese Unterschiede beim Generieren von physischen Datenadressen automatisch. Zudem sind keine Änderungen an Anwendungsdaten oder Anwendungscode erforderlich, da E/A-Operationen automatisch zum korrekten physischen Zieldatenträger umgeleitet werden. Falls notwendig, werden E/A-Operationen auf transparente Weise wiederholt, wenn Daten von einem physischen Quellendatenträger zu einem physischen Zieldatenträger migriert werden. Ferner wird der gleichzeitige Zugriff auf Daten im LFS aus mehreren Prozessen, die auf mehreren eng verbundenen Computersystemen laufen, während des Fortschritts der Migration unterstützt. Darüber hinaus können mehrere physische Datenträger ohne Änderungen an Daten oder Anwendungen zu einem einzigen physischen Datenträger zusammengeführt werden, wodurch Datenträgerverwaltungsaufgaben potenziell vereinfacht werden.
Der Ausdruck „SPOOL-Dateisystem” oder einfach „SPOOL”, wie hierin verwendet, bezieht sich auf das logische Behältnis für SPOOL-Daten, die von System- und Anwendungsprozessen erzeugt werden, die in einem verteilten Computersystem ausgeführt werden. Das SPOOL-Dateisystem verwaltet die Speicherplatz-Zuweisungen/Freigaben von mehreren Prozessen. Zusätzlich gewährleistet das SPOOL-Dateisystem den gleichzeitigen Zugriff auf Spool-Daten aus mehreren Prozessen, die auf mehreren eng verbundenen Computersystemen ausgeführt werden. Dieser Mehrfachzugriff auf SPOOL-Daten ist ein wichtiges Merkmal des SPOOL-Dateisystems. Der Ausdruck „eng verbundenes Computersystem”, wie hierin verwendet, bezieht sich auf ein verteiltes Computersystem, das mehrere physisch getrennte Betriebssystemimages enthält, die symmetrischen Zugriff auf die gemeinsamen Daten haben und die für Anwendungen ein Einzelsystemimage aufweisen (z. B. ein Sysplex, das auf einem IBM System z^® ausgeführt wird).
Ein SPOOL-Dateisystem schließt ein oder mehrere SPOOL-Datenträger ein, die separat verwaltet werden können (operatives Management). Der Ausdruck „SPOOL-Datenträger”, wie hierin verwendet, bezieht sich auf eine logische Entität, die auf bestimmte Weise auf Datenmanagement-Komponenten des zugrundeliegenden Betriebssystems abgebildet ist. In heutigen Betriebssystemen wird ein einzelner logischer SPOOL-Datenträger in einer Eins-zu-eins-Beziehung auf einen einzelnen physischen Datensatz auf einem physischen Plattendatenträger abgebildet. In Ausführungsformen, die hierin beschrieben werden, können mehrere logische SPOOL-Datenträger als Ergebnis der Migration in einer Viele-zu-eins-Beziehung auf einen einzelnen physischen Datensatz abgebildet werden.
Der Ausdruck „Migration”, wie hierin verwendet, bezieht sich auf die Verschiebung von Daten von einem SPOOL-Datenträger zu einem anderen SPOOL-Datenträger. „Vom” SPOOL-Datenträger bezieht sich hierin auf einen „Quellendatenträger”, und „zum” SPOOL-Datenträger bezieht sich hierin auf einen „Zieldatenträger”. Die Laufzeit-Eingabe/Ausgabe (E/A) zu migrierenden SPOOL-Datenträgern wird von Ausführungsformen, die hierin beschrieben werden, auf transparente Weise gehandhabt. Es ist anzumerken, dass Ausführungsformen, die hierin beschrieben werden, auf Dateisysteme jeden Typs ausgeweitet werden können.
Der Ausdruck „Laufzeit”, wie hierin verwendet, bezieht sich auf einen Einzel- oder Multithread-Benutzerausführungskontext, der eine Benutzeranwendung ausführt und in der Lage ist, E/A zu SPOOL-Datenträgern durchzuführen. Die Laufzeit integriert eine maschinennahe Schnittstelle, die die Kommunikation mit einem Migratorausführungskontext erlaubt. Wie hierin beschrieben, gewährleistet das SPOOL-Dateisystem die zentralisierte Verwaltung von SPOOL-Speicherplatz, doch die Laufzeit-E/A ist dezentralisiert. Das SPOOL-Dateisystem leitet und koordiniert den Zugriff auf SPOOL-Daten, doch für den tatsächlichen Zugriff auf physische Einheiten werden die Datenverwaltungsfunktionen des zugrundeliegenden Betriebssystems verwendet. Die Laufzeit-E/A verwendet ein flaches Adressierungssystem, um auf einzelne Datensätze im SPOOL-Dateisystem zuzugreifen. Die Zuordnung einer logischen Adresse eines Datensatzes zu einem physischen Speicherort wird auf für die Anwendung transparente Weise durchgeführt, auch bei laufender Migration und wenn der logische Datensatz zwischen den physischen Datenträgern verschoben wird.
Der Ausdruck „Migrator”, wie hierin verwendet, bezieht sich auf einen Einzel- oder Multithread-Ausführungskontext, der alle Phasen der Migration koordiniert. Wie oben erwähnt, sind in der Laufzeit „Hooks” vorhanden, um dem Migrator vorher zu melden, dass E/A zu migrierenden Datenträgern durchgeführt werden. Der Migrator gibt Anweisungen an die Laufzeit zurück, wobei die eigentlichen E/A im Laufzeitausführungskontext bleiben. In einer Ausführungsform stellt jeder Migrator eine Migration dar.
Der Ausdruck „Assistent”, wie hierin verwendet, bezieht sich auf einen Einzel- oder Multithread-Ausführungskontext, der mit dem Migrator zusammenarbeitet, um unter eng verbundenen Computersystemen Migrationsfunktionalitäten auszuweiten. In einer Ausführungsform hostet jedes Image im eng verbundenen Computersystem einen Assistenten, und ein Assistent kann mehrere Migrationen handhaben. Der Assistent koordiniert Migrationsphasenübergänge unter der Leitung des Migrators.
Der Ausdruck „Spurbitmap”, wie hierin verwendet, bezieht sich auf eine Bitmap, die in der Konfigurationsphase erzeugt wird und die Quellenspuren darstellt, die von einem SPOOL-Quellendatenträger zu einem SPOOL-Zieldatenträger migriert werden sollen. Es ist anzumerken, dass eine Ausführungsform als kleinste Speichereinheit eine Spur verwendet, doch Ausführungsformen können Speichereinheiten jeden Typs (z. B. Datensätze) unterstützen.
Der Ausdruck „Laufzeitbitmap”, wie hierin verwendet, bezieht sich auf eine Bitmap, die verwendet wird, um zu bestimmen, ob vor dem Durchführen von E/A zum SPOOL-Quellendatenträger eine Kommunikation mit dem Migrator erforderlich ist. In einer Ausführungsform entspricht die Granularität der Laufzeitbitmap einer Spur.
Der Ausdruck „Remigrationsbitmap”, wie hierin verwendet, bezieht sich auf eine Bitmap, die verwendet wird, um zu ermitteln, welche Spuren während einer zweiten Phase erneut migriert werden müssen. In einer Ausführungsform ermittelt der Migrator in Zusammenarbeit mit der Laufzeit, welche Spur(en) erneut migriert werden müssen, und speichert diese Information in der Remigrationsbitmap. In einer Ausführungsform wird die Remigrationsbitmap auch benutzt, um Neustart- und Übernahmefunktionalitäten in einem System innerhalb des eng verbundenen Komplexes bereitzustellen.
1 zeigt ein System, das einer Ausführungsform entsprechend realisiert ist. Wie in 1 gezeigt, wird ein SPOOL-Teilsystem 104 von mehreren Betriebssystemen 102 gleichzeitig benutzt. Das in 1 gezeigte SPOOL-Teilsystem 104 ist auch mit einer E/A-Einheit 106 verbunden. In einer Ausführungsform werden die Betriebssysteme 102 auf Prozessoren ausgeführt, die Teil eines Multiprozessor-Computersystems sind. Die E/A-Einheit 106 schließt Peripherieeinheiten (z. B. Drucker, Festplattenlaufwerke, Personal-Computer usw.) sowie Netzwerke (Internet, lokales Netzwerk usw.) ein (oder ist eine Schnittstelle dazu). Das in 1 gezeigte SPOOL-Teilsystem 104 kann auf jede dem Fachmann bekannte Weise genutzt werden und wird typischerweise verwendet, um große Datensätze zu speichern. Die Daten im SPOOL-Teilsystem 104 schließen Daten ein, die von einem Betriebssystem 102 zu einer E/A-Einheit 106 übertragen werden, und Daten, die durch das Betriebssystem 102 von einer E/A-Einheit 106 empfangen werden.
2 zeigt ein Spool-Dateisystem vor der Migration gemäß einer Ausführungsform. Es gibt „M” Systeme 202, die Anwendungen und Systemprozesse ausführen, welche in 2 gezeigt werden, und „N” physische SPOOL-Datenträger 206 (z. B. native Dateisystemobjekte) und „N” logische SPOOL-Datenträger, die von einer SPOOL-Teilsystemabbildung 204 verwaltet werden. Wie in 2 gezeigt, entspricht jedem physischen SPOOL-Datenträger 206 ein logischer SPOOL-Datenträger in der SPOOL-Teilsystemabbildung 204. 2 zeigt logische E/A 208 durch die Systeme 202 zum SPOOL-Dateisystem und physische E/A 210 durch die Systeme zu den physischen SPOOL-Datenträgern. 2 zeigt auch Zuordnungen 212, durch die SPOOL-Teilsystemabbildung 204, von logischen E/A 208 zu physischen SPOOL-Datenträgern 206.
Wie in 2 gezeigt, sind zwei physische E/A 210a und 210b zum physischen SPOOL-Datenträger 206b vorhanden. Zusätzlich sind zwei logische E/A 208b zum physischen SPOOL-Datenträger 206b vorhanden. Die zwei logischen E/A 208b werden in eine physische Adresse umgesetzt, die auf dem physischen SPOOL-Datenträger 206b liegt, wie durch die Zuordnung 212b gezeigt. Der Ausdruck „physische E/A”, wie hierin verwendet, bezieht sich auf eine E/A-Operation, die auf physische Medien zugreift, auf denen die Daten sich physisch befinden. Bei physischen E/A führen Anwendungen die E/A daher direkt an nativen Betriebssystem-Dateisystemobjekten durch. Der Ausdruck „logische E/A”, wie hierin verwendet, bezieht sich auf eine E/A-Operation, die auf im SPOOL-Teilsystem gespeicherte Daten zugreift, indem sie eine Abbildung 204 verwendet, um eine logische Adresse in eine physische Adresse umzusetzen, die auf einem physischen SPOOL-Datenträger 206 liegt. Um die Anforderung zu erfüllen, führt das SPOOL-Teilsystem im Auftrag des Anforderers eine physische E/A an tatsächlichen physischen Medien durch.
Wie in 3 gezeigt, weist eine Ausführungsform einen Migrationsprozess in vier Phasen auf. Zuerst wird in Block 302 die Migrationskonfiguration durchgeführt, die das Identifizieren der physischen Quellen/Ziel-SPOOL-Datenträger und das Initialisieren von Daten und Systemen einschließt. In Block 304 tritt die Phase eins der Migration auf, und sie schließt ein Durchführen eines ersten Migrationsdurchlaufs ein, in welchem Spuren von der Quelle zum Ziel kopiert werden, sowie das Identifizieren von Spuren, die einer erneuten Migration bedürfen. In Block 306 wird die Phase zwei der Migration durchgeführt, die einen zweiten Migrationsdurchlauf einschließt, in welchem alle Spuren, die als eine erneute Migration erfordernd identifiziert wurden, von der Quelle zum Ziel kopiert werden. In Block 308 wird die Migrationsbereinigung durchgeführt, um die Migration abzuschließen.
4 ist ein Prozessablauf einer Migrationskonfiguration gemäß einer Ausführungsform, um von einem physischen SPOOL-Quellendatenträger zu einem physischen SPOOL-Zieldatenträger zu migrieren. In Block 402 wird auf einem Einzelsystem, das die Migration steuern wird, ein Migratorausführungskontext erzeugt, und auf jedem der Systeme werden Assistentenausführungskontexte erzeugt. In Block 404 wird bestimmt, welche Spuren migriert werden sollen, und eine Migrator-Spurbitmap wird generiert (oder vorbereitet). Zusätzlich wird in Block 406 auf jedem der Systeme im Komplex, die auf das SPOOL-Dateisystem zugreifen, eine Laufzeitbitmap erzeugt. Die Laufzeitbitmap wird mit allen Bits eingeschaltet erzeugt, um die Laufzeit zu informieren, dass dem Migrator vorher zu melden ist, dass E/A zum Quellendatenträger durchgeführt werden. In Block 408 werden keine neuen Zuordnungen auf dem Quellendatenträger mehr zugelassen.
Der Ausdruck „Übergangszähler”, wie hierin verwendet, bezieht sich auf eine Zählung durch den Migrator, um Phase-eins-zu-Phase-zwei-Übergänge zwischen dem Migratorkontext und dem Laufzeitkontext zu verwalten. Der Übergangszähler ist dem Quellendatenträger zugeordnet und auf allen Systemen im eng verbundenen Komplex vorhanden. An geeigneten Zeitpunkten informiert der Migrator die Assistenten, den Übergangszähler um eins (oder um einen anderen festgelegten Wert) zu erhöhen. Ein Beispiel für einen geeigneten Zeitpunkt ist der Übergang des migrierenden Datenträgers von einem Zustand zu einem anderen Zustand. In Ausführungsformen wird der Übergangszähler aktualisiert, wenn der Migrationsprozess Änderungen durchführt, die E/A-Operationen beeinflussen können. Für eine gegebene E/A erfasst der Laufzeitkontext vor jeder E/A eine Kopie des Übergangszählers, führt die E/A durch und vergleicht dann eine Kopie eines aktuellen Übergangszählers mit dem Originalübergangszähler, um festzustellen, ob eine Wiederholung erforderlich ist. In einer Ausführungsform ist bei jeder Änderung des Übergangszählers eine Wiederholung erforderlich. Der Zweck des Übergangszählers besteht darin, der Laufzeit zu signalisieren, dass für eine momentan ausgeführte E/A eine Wiederholung erforderlich ist. Eine Wiederholung kann zum Beispiel erforderlich sein, wenn eine Entscheidung der Laufzeit-E/A, eine physische E/A zu einem Quellendatenträger durchzuführen, nicht mehr gültig ist und dieselbe logische E/A nun einen physischen Zieldatenträger adressieren sollte. Bei einer Wiederholung sendet der Laufzeitkontext eine andere Nachricht an den Migratorkontext, um Anweisungen anzufordern. Dies erlaubt dem Migrator, die Laufzeit zu informieren, sobald die E/A von der Quelle zum Ziel wechselt. Die Verwendung des Übergangszählers dient dazu, die Serialisierung jeder Laufzeit-E/A-Operation mit dem Migratorprozess, die kostenintensiv sein kann, zu vermeiden. Die Laufzeit verwendet den Übergangszähler, um Änderung im Zustand des Datenträgers zu erkennen und eine E/A-Operation zu wiederholen, wenn die Änderung während der E/A-Operation erkannt wurde.
Während der Migration werden Daten von einem physischen Quelldatenträger zu einem spezifischen Speicherort auf dem physischen Zieldatenträger verschoben. Für eine gegebene Quellenspuradresse kann der zugeordnete Wert auf die Quellenspuradresse angewandt werden, um den genauen Speicherort der Daten auf dem physischen Zieldatenträger zu erhalten. Daher braucht die Anwendung sich nicht um Adressierungsdifferenzen während der Migration zu kümmern.
5 zeigt einen Prozessablauf einer ersten Phase einer Migration gemäß einer Ausführungsform. Während dieser Phase werden Daten so schnell wie möglich vom Quellendatenträger zum Zieldatenträger kopiert, ohne Laufzeit-E/A zum Quellen- oder Zieldatenträger zu unterbrechen. Vor dem Schreiben in den Quellendatenträger benachrichtigt der Laufzeitkontext den Migratorkontext über die anstehende Schreiboperation. Der Migrator zeichnet die Schreiboperation in der Remigrationsbitmap auf, damit diese Spuren in Phase zwei erneut migriert werden können. In Block 502 weist der Migrator die Assistenten an, den Quellendatenträger-Status so einzustellen, dass die Laufzeit vor dem Lesen oder Schreiben einer Spur im zugeordneten Quellendatenträger die Laufzeitbitmap abfragt. In Block 504 inkrementieren die Assistenten den Quellendatenträger-Übergangszähler. In Block 506 geht der Migrator dazu über, mit der Spurbitmap als Vorgabe Spuren aus dem Quellendatenträger in den Zieldatenträger zu kopieren. Die Spurbitmap wurde in der Konfigurationsphase erzeugt und gibt Quellenspuren an, die eine Migration erfordern.
Während in Block 506 das Kopieren erfolgt, wird Block 508 durchgeführt, um E/A zum Quellendatenträger zu überwachen. Das Migrieren und das Bedienen von Schreibanforderungen werden daher gleichzeitig durchgeführt. Vor dem Lesen oder Schreiben einer Quellenspur fragt die Laufzeit die Laufzeitbitmap ab. Die Laufzeitbitmap wurde in der Konfigurationsphase mit allen Bits eingeschaltet erzeugt. Für eine gegebene Spur und ein entsprechendes Bit, das eingeschaltet ist, sendet die Laufzeit eine Anforderungs-/Antwortnachricht an den Migrator. In der Nachricht gibt die Laufzeit an, ob die anstehende E/A eine Lese- oder Schreiboperation ist. Wenn die Nachricht eine Schreiboperation betrifft, wird Block 510 durchgeführt, und der Migrator zeichnet diese Tatsache zur Vorbereitung von Phase zwei in der Remigrationsbitmap auf. In Reaktion auf diese Nachricht weist der Migrator die Laufzeit an, in den Quellendatenträger zu schreiben und das zugehörige Bit in der Laufzeitbitmap im eingeschalteten Zustand zu lassen.
In Ausführungsformen, die hierin beschrieben werden, geschieht die physische E/A im Laufzeitausführungskontext, und die Kommunikation mit dem Migrator ist relativ schnell, da sehr wenig Verarbeitung stattfindet.
Wenn die Verarbeitung in Block 506 abgeschlossen ist, ist Phase eins beendet und der Migrator ist bereit, zur Verarbeitung von Phase zwei überzugehen. Es ist anzumerken, dass die Migration während der Verarbeitung in Block 506 ohne Datenverlust abgebrochen werden kann.
6 zeigt das SPOOL-Dateisystem von 2 während einer Migration vom physischen Datenträger 206b zum physischen Datenträger 206d während (oder bei Abschluss) von Phase eins gemäß einer Ausführungsform. Wie in 6 gezeigt, wurden einige der Dateien auf dem physischen Datenträger 206b, auf welche über logische E/A 208 zugegriffen wurde, zum physischen Datenträger 206d verschoben, und der Zugriff erfolgt über die Abbildung 204, während andere (z. B. jene, die in Phase zwei erneut migriert werden müssen, jene, die noch nicht migriert wurden) sich noch auf dem physischen Datenträger 206b befinden und der Zugriff über die Zuordnung 212b erfolgt. Zusätzlich wurde eine physische E/A 602 zum physischen Datenträger 206d hinzugefügt, um die physische E/A 210b zum physischen Datenträger 206b zu ersetzen.
Vor der Migration ist der Datenträger 2 in der Abbildung 204 dem physischen Datenträger 206d zugeordnet, und der Datenträger 1 in der Abbildung 204 ist dem physischen Datenträger 206b zugeordnet. Während der Migration weist der Datenträger 1 in der Abbildung 204 zwei gleichzeitige Zuordnungen auf – eine zum physischen Datenträger 206b und eine andere zu einer Teilmenge des physischen Datenträgers 206d. Diese Zuordnung wird durch Steuerinformation realisiert, die in der Abbildung für den Datenträger 1 verwaltet wird. Abhängig vom Status der Migration verwendet die Laufzeit-E/A die eine oder andere dieser zwei Zuordnungen, wenn sie physische E/A für eine logische E/A zum Datenträger 1 in der Abbildung 204 ausgibt. Nach der Migration wird die Zuordnung vom Datenträger 1 in der Abbildung 204 zum physischen Datenträger 206b entfernt, und nur die Zuordnung vom Datenträger 1 in der Abbildung 204 zu einer Teilmenge des physischen Datenträgers 206 bleibt übrig. Der Datenträger 1 in der Abbildung 204 ist nun virtualisiert, da er nun keinen eigenen physischen SPOOL-Datenträger 206 mehr hat.
7 zeigt einen Prozessablauf der Phase zwei der Migration gemäß einer Ausführungsform. Die Phase zwei wird zum erneuten Migrieren von Spuren benutzt, die zum Abschluss der Migration benötigt werden. In einer Ausführungsform wird die Remigrationsbitmap zu Wiederherstellungszwecken und auch aus Leistungsgründen in den Zieldatenträger geschrieben. Während der Phase zwei werden Spuren, für welche eine erneute Migration angegeben ist, dementsprechend behandelt, und die Laufzeit wird vom Migrator angewiesen, physische E/A auf einem Zieldatenträger durchzuführen. Sobald die Remigrationsbitmap verarbeitet worden ist, ist die Phase zwei abgeschlossen. In einer Ausführungsform werden Maßnahmen ergriffen, um sicherzustellen, dass die Migration neu gestartet werden kann, wenn der Migratorkontext fehlschlagen sollte.
Während der Phase zwei ist der Migrator im Begriff, in Reaktion auf die Laufzeit-Anforderungs-/Antwortnachrichten einen Übergang durchzuführen. Der Übergang weist die Laufzeit an, an Stelle des Quellendatenträgers den Zieldatenträger zu verwenden. Vor Beginn einer E/A zum Ziel müssen alle momentan ausgeführten E/A zum Quellendatensatz abgeschlossen sein, oder es muss mindestens über eine weitere Anforderungs-/Antwortnachricht an den Migrator ermittelt werden, ob die E/A wiederholt werden muss. Um dies zu gewährleisten, wird der Übergangszähler verwendet, der dem Quellendatenträger zugeordnet ist. Beim Start der Migration ist der Übergangszähler auf einen beliebigen Wert gesetzt. Während der Migration erfasst die Laufzeit diesen Zähler und ordnet ihn einer einmaligen E/A zu, bevor sie eine Anforderungs-/Antwortnachricht an den Migrator sendet. Nach Abschluss der E/A vergleicht die Laufzeit den gespeicherten Zähler mit einem aktuellen Zähler, der dem Quellendatenträger zugeordnet ist. Wenn die Werte verschieden sind, muss die E/A mit einer weiteren Anforderungs-/Antwortnachricht an den Migrator wiederholt werden. Im Antwortteil der Nachricht informiert der Migrator die Laufzeit, ob die E/A zum Quellendatenträger oder zum Zieldatenträger durchgeführt werden soll. In Phase eins wurden alle E/A zum Quellendatenträger durchgeführt. In Phase zwei werden E/A umgeleitet, um zum Zieldatenträger durchgeführt zu werden.
Wie in Block 702 von 7 gezeigt, sendet der Migrator beim Start von Phase zwei eine Anforderung „Phase zwei starten” an alle Assistenten aus. Die Assistenten inkrementieren den Übergangszähler für jedes System (z. B. um eins). Zudem stellen die Assistenten auch sicher, dass der zugeordnete Wert des Quellendatenträgers eingestellt wird. Der zugeordnete Wert wird auf die Quellenadresse angewandt, wodurch die zugehörige Zieladresse erzeugt wird. Sobald alle Assistenten angegeben haben, dass sie fertig sind, wird Block 704 durchgeführt, und der Migrator schreibt die Remigrationsbitmap in den Zieldatenträger heraus. In einer Ausführungsform wird in der Konfigurationsphase frühzeitig Speicherplatz für diese Bitmap reserviert.
Die Härtung der Remigrationsbitmap im Zieldatenträger erlaubt die Wiederherstellung und die Migrator-Übernahme, falls das Migratorsystem ausfallen sollte. Die Remigrationsbitmap kann gelesen werden, und die Phase zwei kann nahtlos fortgesetzt werden. Während die Phase zwei fortschreitet, liest jeder Assistent auf jedem System zusätzlich die Remigrationsbitmap aus dem Zieldatenträger und wendet sie automatisch auf die Speicher-Laufzeitbitmap seines Systems an. Wie zuvor beschrieben, lenkt die Laufzeitbitmap die an den Migrator zu sendenden Anforderungs-/Antwortnachrichten. Sobald Spuren erneut migriert worden sind, besteht für die Laufzeit keine Notwendigkeit mehr, den Migrator zu benachrichtigen. Statt dessen verwendet die E/A den zugeordneten Wert und führt die E/A zum Zieldatenträger durch. Der Akt des Lesens und Anwendens der Remigrationsbitmap auf die Laufzeitbitmap reduziert die Anforderungs-/Antwortkommunikation mit dem Migrator stark.
Beim Start von Phase zwei werden keine Anforderungs-/Antwortnachrichten verarbeitet, bis alle Assistenten den Übergangszähler inkrementiert und (z. B. über eine Bestätigungsnachricht) den Abschluss des Inkrementierens bestätigt haben. Dies tritt typischerweise sofort ein, der Algorithmus muss jedoch eine übermäßige Wartezeit berücksichtigen und die Migration bei Bedarf abbrechen. Es ist anzumerken, dass die Migration bis zu diesem Punkt abgebrochen werden kann, da alle E/A zum Quellendatenträger durchgeführt worden sind. Um eine übermäßige Wartezeit zu erkennen, verwendet der Migrator in einer Ausführungsform einen Überwachungssignal-Zeitgeber, um zu erkennen, wenn eine spezifizierte Zeitperiode überschritten wird, und die Migration abzubrechen. Sobald Block 706 in 7 gestartet ist, kann die Migration nicht mehr abgebrochen werden, da die Daten nun sowohl den Quellen- als auch den Zieldatenträger umspannen. Dies bedeutet, dass Wiederherstellungsmechanismen vorhanden sein müssen, um die Migration fortzusetzen, wenn ein Fehler auftritt.
In Block 710 ergreift der Migrator andere Maßnahmen und beantwortet Laufzeit-Anforderungs-/Antwortnachrichten auf andere Weise als in Phase eins der Migration. Für (eine) gegebene Spur(en) in einer Laufzeit-Nachricht fragt der Migrator die Remigrationsbitmap ab. Wenn die Spuren erneut migriert werden müssen, wird (werden) die Quellenspur(en) gelesen und in die zugehörige Zielspur geschrieben, bevor auf die Laufzeit-Nachricht geantwortet wird. Der Migrator schaltet auch die zugehörigen Bits in der Remigrationsbitmap ab, und die Bitmap-Änderung wird in den Zieldatenträger geschrieben. Die E/A-Ordnung zwischen erneut migrierten Spuren und der Bitmap ist hier wichtig, um sicherzustellen, dass die Remigrationsbitmap auf dem Zieldatenträger im Wiederherstellungsmodus genutzt werden kann, wenn das Migratorsystem ausfallen sollte. Die Spur-Schreiboperation von der Quelle zum Ziel tritt zuerst auf, gefolgt von der Bitmap-Schreiboperation zum Zieldatenträger. Wenn ein Ausfall auftritt, nachdem die Spur geschrieben wurde, aber bevor die Bitmap geschrieben wurde, wird der Wiederherstellungscode lediglich die Spur erneut migrieren. Dies gewährleistet, dass keine Remigrationsaktion ausgelassen wird.
Sobald der Migrator in Block 706 eine Remigration gehandhabt hat, wird Block 708 durchgeführt, und die Antwort an die Laufzeit ist, den Zieldatenträger zu aktualisieren und die zugehörigen Bits in der Laufzeitbitmap auszuschalten. Durch Aktualisieren der Laufzeitbitmap nimmt die Zahl der Laufzeit-Anforderungs-/Antwortnachrichten stetig ab. Selbstverständlich wird dadurch nur der Datenverkehr vom betreffenden System verringert. Um den Laufzeit-Verkehr von allen Systemen zu verringern, lesen die Assistenten periodisch in der Remigrationsbitmap vom Zieldatenträger und wenden sie atomar auf die Laufzeitbitmap an.
Wenn die Laufzeit Daten im Quellendatenträger aktualisiert, wird der zugeordnete Wert verwendet, um Quellenadressen auf transparente Weise in Zieldatenträger-Speicherorte umzuwandeln. Mit diesem einzigartigen Mechanismus sind Benutzeranwendungen in der Lage, die bestehende Adressierung während der Migration zu verwenden. Sobald alle Remigrationsaktionen abgewickelt worden sind, ist Phase zwei abgeschlossen.
8 zeigt das SPOOL-Dateisystem von 2 und 6, nachdem eine Migration vom physischen Datenträger 206b zum physischen Datenträger 206d gemäß einer Ausführungsform abgeschlossen wurde. Wie in 8 gezeigt, ist der physische Datenträger 206b aus der SPOOL-Konfiguration entfernt worden. Wie in 8 gezeigt, sind alle Daten, die sich zuvor auf dem physischen Datenträger 206b befanden und auf welche über logische E/A 208 zugegriffen wurde, zum physischen Datenträger 206b verschoben worden, und der Zugriff erfolgt über die Zuordnung 604. Zusätzlich wurde eine physische E/A 802 zum physischen Datenträger 206d hinzugefügt, um die physische E/A 210a zum physischen Datenträger 206b zu ersetzen. Die Zuordnung vom logischen Datenträger zum physischen Datenträger wird in der Steuerinformation für den SPOOL-Datenträger gespeichert. Die logische E/A wird stets auf dem Datenträger 1 in der Abbildung 204 durchgeführt, doch die physische E/A kann abhängig davon, was diese Steuerinformation vorgibt, zu verschiedenen Orten gehen. Auch wenn dies in 8 nicht gezeigt wird, gehen neue Lese- oder Schreiboperationen (logische E/A), die an den logischen Datenträger 1 in der Abbildung 204 gerichtet sind, zum physischen Datenträger 206b.
In einer Ausführungsform wird eines der anderen Systeme zum Migrator, wenn das den Migrator ausführende System ausfällt. Diese Realisierung verwendet ein gesichertes Nachrichtenübermittlungssystem, in welchem alle Laufzeit-Anforderungs-/Antwortnachrichten zum Übernahmesystem weitergeleitet werden. Daher muss der Übernahme-Migrator entscheiden, ob die Migration abgebrochen werden oder fortgesetzt und fertiggestellt werden sollte. In einer Ausführungsform stützt sich diese Entscheidung darauf, ob die Remigrationsbitmap in Phase zwei erfolgreich in den Zieldatenträger geschrieben wurde. Wenn ja, liest der Migrator die Remigrationsbitmap erneut und setzt die Migration im Phase-zwei-Modus fort. Andernfalls, wenn die Remigrationsbitmap nicht geschrieben wurde, wird die Migration abgebrochen und auf den Zustand vor der Migration zurückgesetzt. Die Remigrationsbitmap stellt einzigartige Wiederherstellungs- und Leistungsfähigkeiten bereit.
Zu den technischen Wirkungen und Vorteilen gehört die Fähigkeit, Daten aus einem bestehenden nativen Dateisystemobjekt in einem SPOOL-Dateisystem in verfügbaren Speicherplatz auf einem anderen Objekt zu kopieren, das im SPOOL-Dateisystem definiert ist, ohne dass laufende Anwendungen davon Kenntnis haben.
Die hierin verwendete Terminologie dient lediglich der Beschreibung bestimmter Ausführungsformen und soll die Erfindung in keiner Weise einschränken. Die Singularformen „ein, eine” und „der, die, das”, wie sie hierin verwendet werden, schließen auch die Pluralformen ein, sofern der Kontext nicht eindeutig etwas anderes besagt. Ferner versteht es sich, dass die Ausdrücke „aufweist” und/oder „aufweisend”, wenn sie in dieser Patentschrift verwendet werden, das Vorhandensein der genannten Funktionen, Ganzzahlen, Schritte, Operationen, Elemente und/oder Komponenten angeben, aber das Vorhandensein oder den Zusatz einer oder mehrerer anderer Funktionen, Ganzzahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon nicht ausschließen.
Die entsprechenden Strukturen, Materialien, Vorgänge und Entsprechungen aller Mittel oder Schritte und Funktionselemente in den folgenden Ansprüchen sollen alle Strukturen, Materialien und Vorgänge zur Durchführung der Funktion in Kombination mit anderen beanspruchten Elementen einschließen, wie spezifisch beansprucht. Die Beschreibung der vorliegenden Erfindung soll der Veranschaulichung und Beschreibung dienen, ohne aber erschöpfend oder auf die Erfindung in der offenbarten Form beschränkt zu sein. Dem Fachmann werden viele Modifikationen und Varianten einfallen, ohne vom Umfang und Geist der Erfindung abzuweichen. Die Ausführungsform wurde gewählt und beschrieben, um die Prinzipien der Erfindung und die praktische Anwendung am besten zu erklären, und um anderen Fachleuten das Verständnis der Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifikationen zu ermöglichen, wie sie für die vorgesehene spezifische Anwendung geeignet sind.
Wie der Fachmann erkennen wird, können Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Daher können Aspekte der vorliegenden Erfindung die Form einer kompletten Hardware-Ausführungsform, einer kompletten Software-Ausführungsform (einschließlich Firmware, speicherresidenter Software, Mikrocode usw.) oder einer Ausführungsform annehmen, die Software- und Hardwareaspekte kombiniert, die hierin alle allgemein als „Schaltung”, „Modul” oder „System” bezeichnet werden können. Darüber hinaus können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem computerlesbaren Medium oder in mehreren computerlesbaren Medien mit einem darauf ausgeführten computerlesbaren Programmcode ausgeführt ist.
Jede Kombination eines computerlesbaren Mediums oder mehrerer computerlesbarer Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbarer Signalträger oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann zum Beispiel, ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleiter-System, eine entsprechende Vorrichtung oder Einheit oder jede geeignete Kombination des Vorstehenden sein. Spezifischere Beispiele (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums schließen folgendes ein: eine elektrische Verbindung mit einem Draht oder mehreren Drähten, eine tragbare Computerdiskette, eine Festplatte, einen Arbeitsspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flashspeicher), einen Lichtwellenleiter, eine CD-ROM, eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination des Vorstehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem oder einer entsprechenden Vorrichtung oder Einheit enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein verbreitetes Datensignal mit einem computerlesbaren Programmcode sein, der zum Beispiel im Basisband oder als Teil einer Trägerwelle darin ausgeführt ist. Solch ein verbreitetes Signal kann verschiedene Formen annehmen, einschließlich, ohne darauf beschränkt zu sein, elektromagnetisch, optisch oder jede geeignete Kombination daraus. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem oder einer entsprechenden Vorrichtung oder Einheit übertragen, verbreiten oder transportieren kann.
Der Programmcode, der auf einem computerlesbaren Medium ausgeführt ist, kann durch jedes geeignete Medium übertragen werden, einschließlich, ohne darauf beschränkt zu sein, drahtlos, leitungsgebunden, Glasfaserkabel, HF usw., oder jede geeignete Kombination des Vorstehenden.
Der Computerprogrammcode zur Durchführung von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination einer oder mehrerer Programmiersprachen geschrieben sein, einschließlich einer objektorientierten Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und konventioneller prozeduraler Programmiersprachen wie die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programmcode kann gänzlich auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder gänzlich auf dem fernen Computer oder Server ausgeführt werden. Im letzteren Szenario kann der ferne Computer durch jede Art von Netzwerk einschließlich eines lokalen Netzes (LAN) oder eines Weitverkehrsnetzes (WAN) mit dem Computer eines Benutzers verbunden sein, oder die Verbindung kann zu einem externen Computer hergestellt werden (zum Beispiel über das Internet durch einen Internet-Dienstanbieter).
Aspekte der vorliegenden Erfindung werden im Folgenden Bezug nehmend auf Ablaufpläne und/oder Blockschaltbilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten nach Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaltbilder und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaltbildern durch Computerprogrammbefehle realisiert werden können. Diese Computerprogrammbefehle können einem Prozessor eines Universalcomputers, Spezialcomputers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung zur Herstellung einer Maschine so bereitgestellt werden, dass die Befehle, die über den Prozessor des Computers oder der sonstigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zur Durchführung der Funktionen/Vorgänge ergeben, die im Block oder in Blöcken der Ablaufpläne und/oder Blockschaltbilder angegeben sind.
Diese Computerprogrammbefehle können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder sonstige Einheiten anweisen kann, auf eine bestimmte Weise zu funktionieren, sodass die Befehle, die im computerlesbaren Medium gespeichert sind, ein Erzeugnis mit Befehlen ergeben, die die Funktionen/Vorgänge realisieren, die die im Block oder in Blöcken der Ablaufpläne und/oder Blockschaltbilder angegeben sind.
Die Computerprogrammbefehle können auch in einen Computer, in eine andere programmierbare Datenverarbeitungsvorrichtung oder in sonstige Einheiten geladen werden, um die Durchführung einer Reihe von Arbeitsgängen auf dem Computer, der anderen programmierbaren Vorrichtung oder sonstigen Einheiten zu bewirken, um einen computergestützten Prozess zu ergeben, sodass die Befehle, die auf dem Computer oder der sonstigen programmierbaren Vorrichtung ausgeführt werden, Prozesse zur Ausführung der Funktionen/Vorgänge ergeben, die im Block oder in Blöcken der Ablaufpläne und/oder Blockschaltbilder angegeben sind.
Die Ablaufpläne und Blockschaltbilder in den Figuren veranschaulichen die Architektur, Funktionalität und Arbeitsweise möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern ein Codemodul, ein Codesegment oder einen Codeteil darstellen, der einen oder mehrere ausführbare Befehle zur Realisierung der spezifizierten logischen Funktion(en) aufweist. Es ist auch anzumerken, dass die in den Blöcken genannten Funktionen in einigen alternativen Realisierungen in einer anderen Reihenfolge als der in der Figur genannten auftreten können. Zum Beispiel können zwei Blöcke, die aufeinanderfolgend dargestellt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können abhängig von der beteiligten Funktionalität manchmal in umgekehrter Reihenfolge ausgeführt werden. Es ist auch anzumerken, dass jeder Block der Blockschaltbilder und/oder Ablaufpläne und Kombinationen von Blöcken in den Blockschaltbildern und/oder Ablaufplänen durch Systeme auf der Grundlage von Spezialhardware, die die spezifizierten Funktionen der Vorgänge durchführen, oder durch Kombinationen von Spezialhardware und Computerbefehlen realisiert werden können.

Claims

Verfahren zum Migrieren eines transparenten Dateisystems zu einem neuen physischen Speicherort, wobei das Verfahren aufweist: Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt; Identifizieren eines physischen Zielspeicherorts im Dateisystem; Migrieren des Inhalts des physischen Quellenspeicherorts zum physischen Zielspeicherort, wobei das Migrieren aufweist: Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort; Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort; Empfangen einer Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wobei das Empfangen vor oder während des Migrierens erfolgt; Bedienen der Schreibanforderung gleichzeitig mit dem Migrieren; und Umleiten, in Reaktion auf das Abschließen des Migrierens, von an den physischen Quellenspeicherort gerichteten Lese- und Schreibanforderungen zum physischen Zielspeicherort, wobei die Anforderungen von den mehreren unabhängigen Prozessen kommen und sowohl logische Ein/Ausgaben (E/A) als auch physische E/A aufweisen.
Verfahren nach Anspruch 1, außerdem aufweisend das Entfernen des physischen Quellenspeicherorts aus dem Dateisystem.
Verfahren nach Anspruch 1, wobei das Dateisystem ein „Simultaneous Peripheral Operations On-Line”(SPOOL)-Dateisystem ist.
Verfahren nach Anspruch 1, wobei das Migrieren und das Umleiten ohne jede Änderung an den mehreren unabhängigen Prozessen durchgeführt werden.
Verfahren nach Anspruch 1, wobei die mehreren unabhängigen Prozesse auf mehreren unterschiedlichen Computersystemen ausgeführt werden.
Verfahren nach Anspruch 1, wobei das Umleiten mit einem virtualisierten Objekt durchgeführt wird.
Verfahren nach Anspruch 1, wobei das Umleiten mit einem logischen Dateisystem durchgeführt wird.
System, aufweisend einen Prozessor, der konfiguriert ist, um ein Verfahren durchzuführen, wobei das Verfahren aufweist: Mittel zum Identifizieren eines physischen Quellenspeicherorts in einem Dateisystem, das den gleichzeitigen Zugriff durch mehrere unabhängige Prozesse unterstützt; Mittel zum Identifizieren eines physischen Zielspeicherorts im Dateisystem; Mittel zum Migrieren des Inhalts des physischen Quellenspeicherorts zum physischen Zielspeicherort, wobei das Migrieren aufweist: Mittel zum Nichtzulassen neuer Zuordnungen zum physischen Quellenspeicherort; Mittel zum Kopieren des Inhalts vom physischen Quellenspeicherort zum physischen Zielspeicherort; Mittel zum Empfangen einer Schreibanforderung, Daten in den physischen Quellenspeicherort zu schreiben, wobei das Empfangen vor oder während des Migrierens erfolgt; Mittel zum Bedienen der Schreibanforderung gleichzeitig mit dem Migrieren; und Mittel zum Umleiten, in Reaktion auf das Abschließen des Migrierens, von an den physischen Quellenspeicherort gerichteten Lese- und Schreibanforderungen zum physischen Zielspeicherort, wobei die Anforderungen von den mehreren unabhängigen Prozessen kommen und sowohl logische Ein-/Ausgaben (E/A) als auch physische E/A aufweisen.
System nach Anspruch 8, wobei das Verfahren außerdem Mittel zum Entfernen des physischen Quellenspeicherorts aus dem Dateisystem aufweist.
System nach Anspruch 8, wobei das Dateisystem ein „Simultaneous Peripheral Operations On-Line”(SPOOL)-Dateisystem ist.
System nach Anspruch 10, wobei die Mittel zum Migrieren und Umleiten ohne jede Änderung an den mehreren unabhängigen Prozessen durchgeführt werden.
System nach Anspruch 8, wobei die mehreren unabhängigen Prozesse auf mehreren unterschiedlichen Computersystemen durchgeführt werden.
System nach Anspruch 8, wobei das Mittel zum Umleiten mit einem virtualisierten Objekt durchgeführt wird.
System nach Anspruch 8, wobei das Mittel zum Umleiten mit einem logischen Dateisystem durchgeführt wird.
Computerprogramm, aufweisend Computerprogrammcode, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen, wenn er in ein Computersystem geladen und ausgeführt wird.