-
HINTERGRUND DER ERFINDUNG
-
Die
Erfindung betrifft im Allgemeinen Systeme zur hierarchischen Speicherverwaltung
und insbesondere eine Methode und ein System zum Verwalten einer
Umgebung für
die hierarchische Speicherverwaltung (Hierarchical Storage Management, HSM),
die mindestens einen HSM-Server und mindestens einen Dateiserver
enthält,
auf dem ein Dateisystem gespeichert ist, wobei der mindestens eine HSM-Server
und der mindestens eine Dateiserver über ein Netz miteinander verbunden
sind und wobei Dateien mit digitalen Daten vorübergehend von dem mindestens
einen Dateiserver auf den mindestens einen HSM-Server migriert werden.
-
Die
hierarchische Speicherverwaltung soll teurere Speichereinheiten – in der
Regel magnetische Speicherplatten mit begrenzter Kapazität – entlasten,
indem Datendateien unter bestimmten Kriterien wie dem Alter der
Datei oder der Dateigröße auf kostengünstigere
Speichermedien wie Bänder
migriert werden, wodurch praktisch unbegrenzter Speicherplatz geschaffen
wird. Eine kleine „Rumpfdatei" ersetzt die migrierte
Datei in dem verwalteten Dateisystem, damit ein transparenter Zugriff
auf alle Datendateien möglich
ist. Für
den Benutzer ist diese Rumpfdatei nicht von der vollständig residenten
Originaldatei zu unterscheiden, aber dem HSM-System liefert die
Rumpfdatei wichtige Informationen, z. B. über die Position der tatsächlichen
Daten auf dem Server.
-
Zwischen
der Perspektive des Benutzers und derjenigen des HSM-Systems besteht hinsichtlich
einer migrierten Datei ein wesentlicher Unterschied darin, dass
der Benutzer nicht die neue „physische” Größe der Datei
erkennen kann, bei der es sich nach der Migration einer Datei um
die Größe der Rumpfdatei
handelt, aber weiterhin die „logische" Größe erkennen
kann, die der Größe der Datei
vor ihrer Migration entspricht.
-
Eine
Implementierung eines HSM-Systems nutzt eine Client-Server-Konfiguration, bei
welcher der Client auf demjenigen System ausgeführt wird, auf dem Dateisysteme
verwaltet werden sollen, und bei welcher der Server die Verwaltung
migrierter Datendateien und der darin enthaltenen Informationen ermöglicht.
-
Ein
HSM-System muss traditionell folgende Aufgaben ausführen:
- a) Bestimmen, welche Datendateien (bezeichnet als „Kandidaten") in dem Dateisystem
für eine
Migration in Frage kommen. Zur Bestimmung der „besten" Kandidaten (hinsichtlich Alter und
Größe) ist
eine vollständige
Dateisystem-Traversierung erforderlich;
- b) Bestimmen, welche früher
migrierten Dateien im Clientdateisystem geändert oder aus diesem entfernt
wurden, damit ihre migrierten Kopien aus dem Serverspeicherpool
entfernt werden können, sodass
der zuvor von ihnen belegte Speicherplatz für eine erneute Nutzung bereitsteht
(bezeichnet als „Abgleich"). Hierzu ist für gewöhnlich eine
Traversierung des gesamten Dateisystembaums notwendig.
-
Bei
nicht ausreichendem verfügbaren
Speicherplatz im Clientdateisystem müssen Datendateien zur Minimierung
der Anwendungslatenzzeit schnell von der Platte migriert werden – ein Vorgang, der
in diesem Dokument als „Automigration" bezeichnet wird.
Wenn es einem verwalteten Dateisystem an Speicherplatz mangelt,
werden alle Anwendungen, die Schreibanforderungen an dieses Dateisystem stellen,
so lange blockiert, bis durch die Migration von Dateien wieder genügend Speicherplatz
auf der Platte zur Verfügung
gestellt wurde, um die Schreibanforderungen der Anwendungen zu erfüllen. In
traditionellen HSM-Systemen werden Dateien eines verwalteten Dateisystems
seriell, d. h. nacheinander, migriert.
-
Eine
entsprechende Datenmigrationseinrichtung ist auf den Seiten 205–208 des
im Juni 1973 veröffentlichten
IBM Technical Disclosure Bulletin beschrieben. Es befasst sich mit
einem Supervisor-Controller für
die automatische Verwaltung und Steuerung der sekundären Speicherressourcen
eines Computersystems. Eine Migrationsüberwachung wird durch Laufzeitereignisse
gesteuert und fungiert als Ereignisprozessor der ersten Ebene. Die
Migrationsüberwachung
erfasst Ereignisse und fasst die Datenmigrationsaktivität zusammen.
Nach dem Empfang einer Anforderung leitet die Migrationsüberwachung
eine Migrationstask ein. Die Migrationstask durchsucht einen Bestand
autorisierter Daten im System und ruft einen gegebenen Algorithmus
auf, um zu entscheiden, welche Daten zu migrieren sind.
-
Da
die Datenmenge und die Anzahl der Datendateien in einem üblichen
verwalteten Dateisystem, wie in 2 dargestellt,
mit der Zeit logarithmisch zunehmen, wird die Skalierbarkeit des HSM-Systems
zu einem Problem. Typische Dateisystemumgebungen mit einem solchen
Verhalten sind die Umgebungen von Internet-Providern, welche die Dateien Tausender
Kunden handhaben und Videoverarbeitungsszenarios wie die von einem
Video-on-Demand-Server
bereitgestellten oder die Verarbeitung von Wettervorhersagekarten
ermöglichen,
bei der täglich
Millionen hochaufgelöster
Bilder von Wettersatelliten generiert werden. In diesen Umgebungen
sind häufig über eine
Million Dateien zu handhaben, und die Anzahl nimmt kontinuierlich
zu.
-
Angesichts
der oben genannten Gründe
besteht eine starke Nachfrage nach HSM-Systemen, die diese großen Dateisysteme
handhaben können.
-
Die
meisten bekannten HSM-Ansätze
sehen ein Traversieren des gesamten Dateisystems vor, um die in
Frage kommenden Kandidaten für
die Automigration in einen fernen Speicher zu erfassen. Dieses System
funktionierte in relativ kleinen Umgebungen gut, aber wegen der übermäßig langen
Verarbeitungszeit für
die Millionen von Dateien lässt
es sich nicht mehr für
die aktuellen Dateisystemlayouts nutzen. Daher ist die Bereitstellung
eines besser skalierbaren Mechanismus erforderlich, der weniger
Systemressourcen verbraucht.
-
Ein
bekannter HSM-Ansatz für
ein oben genanntes Migrationsszenario ist in der
US-Patentanmeldung 5,832,522 dargelegt
und schlägt
einen Platzhaltereintrag (Rumpfdatei) vor, der zum Abrufen des Status
einer migrierten Datendatei dient. Es wird insbesondere ein Zeiger
bereitgestellt, mit dessen Hilfe ein anfordernder Prozessor eine
angeforderte Datendatei effizient lokalisieren und abrufen kann. Ferner
kann der Platzhaltereintrag die Migration einer Datendatei auf einen
HSM-Server anzeigen.
-
Als
weiterer Ansatz wird in der
US-Patentanmeldung
5,367,698 ein Migrationssystem für Netzdateien beschrieben.
Das beschriebene System umfasst eine Reihe von Clienteinheiten,
die über
ein Netz miteinander verbunden sind. Ein lokales Speicherelement
für Datendateien
ermöglicht
das lokale Speichern von und den Zugriff auf Dateien mit digitalen
Daten, die in einem oder mehreren der Clientdateisysteme gespeichert
sind. Ein Migrationsdateiserver enthält ein Migrationsspeicherelement,
das Datenteile von Dateien aus den Clienteinheiten speichert, ein
Element zur Erkennung der Speicherkapazität, das den Speichernutzungsgrad
im Speicherelement erkennt, und ein auf den Nutzungsgrad reagierendes Übertragungselement,
das Datenteile von Dateien aus der Clienteinheit selektiv an das
Speicherelement überträgt.
-
Bekannte
HSM-Anwendungen traversieren den gesamten Dateisystembaum, um in
Frage kommende Kandidaten für
die Automigration in einen fernen Speicher zu erfassen. Dieses System
funktionierte in relativ kleinen Umgebungen gut, aber wegen der übermäßig langen
Verarbeitungszeit für
die Millionen von Dateien lässt
es sich nicht mehr für
die aktuellen Dateisystemlayouts nutzen. Eine vollständige Baumtraversierung
schränkt
die Skalierbarkeit in unvorteilhafter Weise sowohl hinsichtlich
der Dauer als auch in Bezug auf den Ressourcenbedarf ein, die beide
mit der Anzahl der in einem Dateisystem enthaltenen Dateien logarithmisch
zunehmen. Darüber hinaus
lässt sich
freier Speicherplatz durch eine serielle Automigration häufig nicht
so schnell bereitstellen wie es die heutigen Anforderungen verlangen. Daher
ist die Bereitstellung eines besser skalierbaren Mechanismus erforderlich,
der weniger Systemressourcen verbraucht.
-
Aufgrund
des ständig
zunehmenden Speichervolumens und der reinen Anzahl von Speicherobjekten
wird es für
Datenverwaltungsanwendungen immer schwieriger, ihren Service bereitzustellen, ohne
dass es zu einem wachsenden Bedarf an Systemressourcen kommt, der
offensichtlich nicht wünschenswert
ist.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, eine Methode
und ein System für
die effiziente Handhabung großer
Mengen von dateibasierten Informationen in einer Umgebung für die hierarchische
Speicherverwaltung bereitzustellen.
-
Eine
andere Aufgabe besteht darin, diese Methode und dieses System im
Automigrationskontext einer Datenverwaltungsanwendung bereitzustellen.
-
Noch
eine weitere Aufgabe besteht darin, die Leistung eines HSM-Systems zu verbessern.
-
Eine
weitere Aufgabe besteht darin, eine solche Methode und ein solches
System zur Handhabung großer
Mengen von dateibasierten Informationen in einer HSM-Umgebung bereitzustellen,
die im Hinblick auf die Menge der dateibasierten Informationen hochskalierbar
ist.
-
Die
oben genannten Aufgaben werden von den in den unabhängigen Ansprüchen dargelegten Merkmalen
erfüllt.
Vorteilhafte Anordnungen und Ausführungsarten sind Gegenstand
der Unteransprüche.
-
Das
der Erfindung zugrunde liegende Konzept sieht vor, nicht alle „besten" Migrationskandidaten
auf einmal zu ermitteln, sondern das Dateisystem nur so lange zu
durchsuchen, bis eine bestimmte Anzahl von Migrationskandidaten
ermittelt wurde. Ferner besteht der Grundgedanke darin, dass der
Prozess zum Bestimmen von Kandidaten angehalten wird, bis eines
von zwei Ereignissen eintritt, d. h., bis ein festgelegtes Warteintervall
abläuft
oder bis ein Automigrationsprozess startet. Der Prozess zur Kandidatenbestimmung
kann in vorteilhafter Weise die Durchsuchung des Dateisystems an
der Stelle fortsetzen, an der er einen vorherigen Suchlauf gestoppt hat,
und so lange weiter nach Migrationskandidaten suchen, bis eine bestimmte
Anzahl von Kandidaten gefunden wurde.
-
Der
besondere Schritt, das verwaltete Dateisystem nur so lange zu durchsuchen,
bis eine vorab festgelegte Anzahl von Kandidatendateien für die Migration
erkannt wurde, ermöglicht
es in vorteilhafter Weise, dass Migrationskandidaten früher für den Migrationsprozess
zur Verfügung
stehen, wobei die Migration als Automigrationsprozess ausgeführt werden
kann, der keine Bediener- oder Benutzerinteraktion erfordert. Als
das mindestens eine Attribut kann die Dateigröße und/oder eine Zeitmarke
der Datei dienen.
-
In
einer Ausführungsart
wird der Automigrationsprozess von einem Master/Slave-Konzept ausgeführt, bei
dem der Master den Automigrationsprozess steuert und mindestens
einen Slave für
die Migration von Kandidaten-Datendateien auswählt, die vom Master bereitgestellt
werden.
-
Eine
andere Ausführungsart
umfasst als zusätzliche
Schritte, die in der mindestens einen Liste zum Ermitteln von Kandidaten-Datendateien enthaltenen
Datendateien insbesondere hinsichtlich ihrer Dateigröße und/oder
ihrer Zeitmarke zu hierarchisieren und zu sortieren. Dabei kann
die Reihenfolge der zu migrierenden Kandidaten-Datendateien bestimmt werden.
-
Vor
allem macht der vorgeschlagene Mechanismus den Prozess zur Kandidatenbestimmung
daher praktisch unabhängig
von der Anzahl der Dateien im Dateisystem und von der Größe des Dateisystems.
Die Erfindung ermöglicht
somit die parallele Abwicklung der Bestimmung von Kandidaten-Datendateien
für die
Migration und des eigentlichen Automigrationsprozesses.
-
Außerdem generiert
der Automigrationsprozess eine eindeutige, auf dem HSM-Server zu
speichernde ID, die während
eines späteren
Abgleichprozesses den direkten Zugriff auf migrierte Datendateien
ermöglicht.
-
Der
vorgeschlagene Suchlaufprozess senkt daher den Ressourcenbedarf
erheblich, da z. B. die Speicherressourcen für die Kandidaten-Dateiliste und
die erforderlichen Verarbeitungsressourcen zum Verwalten der Kandidaten-Dateiliste
deutlich verringert werden. Auch die Suchlaufzeit wird deutlich
verkürzt.
-
Das
Grundprinzip dieser Erfindung besteht darin, dass es bei der Bestimmung
in Frage kommender Migrationskandidaten nicht mehr auf eine hundertprozentige
Genauigkeit ankommt. Anstatt eine Analyse anhand einer vollständigen Liste
von Migrationskandidaten anzustreben, kann davon ausgegangen werden,
dass der Dienst auch dann funktional ist, wenn er auf einer bestimmten
Teilmenge von Dateien innerhalb eines verwalteten Dateisystems basiert.
-
Die
Erfindung ermöglicht
demzufolge das Handshaking zwischen dem Prozess zum Bestimmen oder
Suchen von Migrationskandidaten und dem Prozess der Automigration.
-
Infolgedessen
sorgt die Erfindung für
die Skalierbarkeit und für
eine deutliche Leistungsverbesserung eines solchen HSM-Systems.
Demzufolge ist dank der eindeutigen ID eine sichere Synchronisation
bzw. ein sicherer Abgleich von Client- und Serverspeicher möglich, ohne
dass ein Traversieren des gesamten Clientdateisystems erforderlich
ist.
-
Gemäß einer
Ausführungsart
werden mindestens zwei Listen zum Ermitteln von Kandidaten-Datendateien
bereitgestellt, wobei die erste Liste vom Suchlaufprozess generiert
und/oder aktualisiert und die zweite Liste vom Automigrationsprozess
verwendet wird. Der Automigrationsprozess übernimmt die erste Liste vom
Suchlaufprozess, wenn alle Kandidaten-Datendateien der zweiten Liste
migriert sind. Beide Listen werden parallel bearbeitet, was die
Parallelität
zwischen Suchlauf und Automigration widerspiegelt.
-
Es
ist ferner festzustellen, dass außer dem oben beschriebenen
Status „migriert" für Datendateien
im verwalteten Dateisystem auch ein Status „vormigriert" verwendet werden
kann, bei dem das auf dem HSM-Server gespeicherte migrierte Exemplar mit
dem residenten Exemplar der Datendatei im verwalteten Dateisystem
identisch ist.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
Erfindung wird im Folgenden anhand einer bevorzugten Ausführungsart
der Erfindung detaillierter beschrieben, aus der weitere Merkmale
und Vorteile ersichtlich werden, wobei auf die beiliegenden Zeichnungen
Bezug genommen wird.
-
1 ist ein Blockdiagramm, das eine typische
Umgebung für
die hierarchische Speicherverwaltung darstellt, auf welche die vorliegende
Erfindung angewendet werden kann;
-
2 veranschaulicht die bekannte logarithmische
Zunahme der Datenmenge und der Anzahl der Datendateien in einem
typischen verwalteten Dateisystem;
-
3 ist ein Flussdiagramm zur Veranschaulichung
des Basismechanismus für
die Verwaltung eines HSM-Systems gemäß der Erfindung;
-
4 ist ein weiteres Flussdiagramm zur Veranschaulichung
des Basismechanismus für
das Abgleichen eines von einem Dateiserver auf ein HSM-System migrierten
verwalteten Dateisystems;
-
5 ist ein weiteres Flussdiagramm zur Darstellung
einer Basislogik einer Automigrationsumgebung gemäß der Erfindung;
und
-
6a und b veranschaulichen eine bevorzugte
Ausführungsart
des Mechanismus gemäß der Erfindung.
-
DETAILLIERTE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 zeigt einen typischen Dateiserver 101, der
ein oder mehrere Dateisysteme 102 verwaltet. Jedes Dateisystem
ist in der Regel in Form von mehr oder weniger komplexen und mehr
oder weniger tief verschachtelten Dateibäumen 103 organisiert.
Der Dateiserver 101 ist über ein Netz 104,
bei dem es sich in der Regel um eine lokales Netz (local area network,
LAN) oder ein Weitverkehrsnetz (wide area network, WAN) handelt,
mit einem anderen Serversystem 105 verbunden, das einen
HSM-Server 106 enthält.
An das Serversystem 105 sind ein oder mehrere externe Speichereinheiten 107 – in diesem
Beispiel Bandspeichereinheiten – angeschlossen.
Der HSM-Server 106 speichert die vom Dateiserver 101 zu
den Bandspeichereinheiten 107 migrierten Daten.
-
2 veranschaulicht, dass die Datenmenge
und die Anzahl der Datendateien in einem typischen verwalteten Dateisystem
wie zuvor erwähnt
logarithmisch zunehmen.
-
Das
in 3 dargestellte Flussdiagramm veranschaulicht
den Basismechanismus für
die Verwaltung eines HSM-Systems gemäß der Erfindung.
-
In
Schritt 200 wird eine Dateimenge, z. B. die Anzahl der
Dateien oder die Gesamtgröße mehrerer Dateien,
vorab festgelegt, für
die ein Suchlauf im Dateisystem ausgeführt werden soll. Je nach vorab festgelegter
Menge wird mindestens ein Teil des Dateisystems durchsucht 201.
Ein wichtiger Aspekt der Erfindung besteht darin, dass nicht das
gesamte Dateisystem durchsucht wird, sondern nur ein Teil davon,
der von der vorab festgelegten Menge bestimmt wird.
-
Im
nächsten
Schritt 202 werden anhand eines oder mehrerer Attribute
wie der Dateigröße oder einer
Zeitmarke der Datei (Dateialter oder dergleichen) die Kandidatendateien
bestimmt, die vom Dateiserver auf den HSM-Server migriert werden
sollen. Die bestimmten Kandidatendateien werden in einer Kandidatenliste 203 zusammengestellt.
Hierbei ist anzumerken, dass in einer anderen Ausführungsart der
Erfindung zwei Listen bereitgestellt werden. Eine solche Ausführungsart
wird weiter unten detaillierter beschrieben.
-
Der
Schritt 204 ist ein optionaler Schritt (angezeigt durch
den gestrichelten Rahmen), bei dem die in der Kandidatenliste enthaltenen
Dateien zusätzlich
hierarchisiert werden, damit die nachfolgend für die Migration ausgewählten Dateien
in einer bestimmten Reihenfolge migriert werden können.
-
Parallel
zu den oben beschriebenen Schritten 200–204 wird das Dateisystem überwacht 205, und
der aktuelle Status des Dateisystems wird bestimmt 206.
In Schritt 207 wird eine Automigration ausgewählter und
wahlweise hierarchisierter Kandidaten-Datendateien in Abhängigkeit
vom bestimmten Dateisystemstatus eingeleitet oder ausgelöst. In der nachfolgenden
Beschreibung wird auf die Details dieses Dateisystemstatus eingegangen.
-
Nach
der Einleitung der Automigration wird diese ausgeführt 208,
indem Datendateien physisch an den HSM-Server übertragen werden und indem insbesondere
jeder migrierten Datei eine eindeutige ID zugewiesen wird. Das Konzept
und die Bedeutung dieser eindeutigen ID sind aus den nachfolgenden Teilen
der Beschreibung ersichtlich. Schließlich wird die eindeutige ID
an den HSM-Server gesendet.
-
In
dem in 4 dargestellten Flussdiagramm
soll der erfindungsgemäße Basismechanismus
für das
Abgleichen eines verwalteten Dateisystems veranschaulicht werden,
das von einem Dateiserver auf ein HSM-System migriert wird. In einem ersten
Schritt 301 wird eine Liste bereits migrierter Dateien
vom HSM-Server über das
Netz übertragen. Die übertragene
Liste enthält
insbesondere die eindeutige ID, die in dem in 3 beschriebenen
Prozess generiert wurde. Anschließend fragt ein Abgleichprozess
die übertragene
Liste migrierter Dateien ab 302 und vergleicht 303 die
migrierten Dateien, die durch ihre entsprechende eindeutige ID gekennzeichnet
sind, mit den entsprechenden Dateien, die im verwalteten Dateisystem
enthalten sind. Schließlich
aktualisiert 304 der Abgleichungsprozess die verwalteten
Daten entsprechend auf dem HSM-Server.
-
Das
in 5 dargestellte Flussdiagramm zeigt
eine Basislogik einer automatisierten HSM-Umgebung. Ein Überwachungsdämon 501 startet
einen Master-Scoutprozess 502 und überwacht kontinuierlich ein
oder mehrere Dateisysteme. Der Master-Scoutprozess 502 startet pro
Dateisystem einen Slave-Scoutprozess 503.
Jeder Slave-Scoutprozess 503 durchsucht sein Dateisystem
nach zu migrierenden Kandidaten-Datendateien.
-
Wenn
der Überwachungsdämon 501 erkennt,
dass die Schwellenwerte des Dateisystems überschritten wurden, startet
er einen Master-Automigrationsprozess 504,
der weiter unten ausführlicher
beschrieben wird.
-
Beim Überschreiten
des Werts für
ein Abgleichintervall wird vom Überwachungsdämon 501 ein
Abgleichprozess 505 gestartet. Der Abgleichprozess 505 wird
im Folgenden ebenfalls ausführlicher beschrieben.
-
Die
in den 6a und 6b dargestellten Flussdiagramme
veranschaulichen eine bevorzugte Implementierung, die auf unabhängigen Migrationskandidatenpools 601, 602 für die Automigration 603 und
den Suchlaufprozess 604 basiert, wobei Letzterer häufig (und
auch im Folgenden) als „Scoutprozess" bezeichnet wird.
-
In
dieser Ausführungsart
wird die Automigrationsfunktion 603 (Automigrator) von
einem anderen Prozess aktiviert, z. B. von einem Überwachungsprozess,
der Dateisystemereignisse verfolgt und geeignete Maßnahmen
einleitet, falls bestimmte Schwellenwerte überschritten werden. Bei der Überschreitung
eines definierten Schwellenwerts beginnt die Automigrationsfunktion 603 dann,
Migrationskandidaten in einen fernen Speicher zu migrieren 605.
Vor der Migration 605 der Dateien führt der Automigrationsprozess 603 Überprüfungen 606 des
HSM-Servers hinsichtlich der Managementklasse (management class,
MC) aus, um sicherzustellen, dass eine potenzielle Migration keine
für den
HSM-Server geltenden Regeln verletzt.
-
Wenn
dem Automigrationsprozess 603 keine Kandidaten mehr zur
Verfügung
stehen, d. h. nach dem Abarbeiten der Liste mit den ermittelten
Kandidaten 602, setzt 607 er eine Markierung,
um dem Scoutprozess 604 die Anforderung einer neuen Kandidatenliste 601 zu
signalisieren. Der Scoutprozess 604 empfängt 608 die
Markierung, übermittelt 609 die neu
generierte Liste 601 an die Automigrationsfunktion 603 und
setzt dabei 609 eine weitere Markierung, die der Automigrationsfunktion
signalisiert, mit der Migration der Dateien fortzufahren.
-
Der
Scoutprozess 604 selbst beginnt mit dem Sammeln 610 neuer
Migrationskandidaten. Nach der Durchsuchung wartet der Scoutprozess 604 so
lange, bis er ein weiteres Signal der Automigrationsfunktion empfängt oder
bis ein definierbarer Wert CANDIDATESINTERVAL 611 überschritten wird.
Der Wert CANDIDATESINTERVAL 611 definiert den Zeitraum,
in dem der Scoutprozess 604 nach einer Aktivitätsphase
inaktiv im Hintergrund bleibt.
-
Im
letztgenannten Fall der Überschreitung des
Werts CANDIDATESINVERVAL 611, startet er die Optimierung
seiner Kandidatenliste mit Hilfe eines weiteren Suchlaufs. Falls
der Scoutprozess vom Automigrationsprozess kein entsprechendes Signal empfängt, startet
er zur qualitativen Verbesserung der Kandidatenliste zu jedem Intervall
CANDIDATESINTERVAL 611 einen Suchlauf nach einer neuen Kandidatengruppe.
Diese Kandidatengruppe ist durch einen anderen Wert MAXCANDITATES 612 definiert,
der eine Anzahl erforderlicher Kandidaten festlegt, die den Kandidatenkriterien
entsprechen. In Kombination mit der vorhandenen Migrationskandidatenliste 601 kann
der Scoutprozess 604 entweder alle Kandidaten zusammenstellen
oder nur die „beste" Teilmenge verwenden,
um den erforderlichen Speicherplatz zu begrenzen. Folglich traversiert
der Scoutprozess das verwaltete Dateisystem auf der Suche nach Kandidaten,
die für
die Automigration in Frage kommen. Statt das gesamte Dateisystem
zu traversieren, stoppt der Prozess, sobald eine dem Wert MAXCANDIDATES 612 entsprechende
Anzahl in Frage kommender Kandidaten gefunden wurde. Danach wartet
der Prozess entweder auf das Eintreten eines vom Automigrationsprozess
ausgelösten dedizierten
Ereignisses oder er bleibt so lange inaktiv, bis der Zeitraum CANDIDATESINTERVAL 611 verstrichen
ist.
-
Der
oben beschriebene Scoutprozess bietet folgende Vorteile:
- • minimaler
Verbrauch von Systemressourcen (Speicher, Verarbeitungszeit), die
zur Ermittlung in Frage kommender Kandidaten erforderlich sind;
- • hohe
Skalierbarkeit bei minimaler Abhängigkeit von
der Anzahl der Objekte innerhalb eines Dateisystems;
- • höhere Kandidatenqualität bei normaler
Dateisystemaktivität.
-
Als
Nachteil erweist sich die Möglichkeit, dass
die je nach Auswahlstrategie potenziell besten Migrationskandidaten
nicht vom Automigrationsprozess verwendet werden, weil der Scoutprozess
die entsprechende Unterverzeichnisstruktur noch nicht traversiert
hat.
-
Die
oben genannten Vorteile wiegen die Nachteile jedoch mehr als auf.
-
Im
Folgenden werden die verschiedenen Prozessschritte des gesamten,
von der Erfindung vorgeschlagenen Migrationsmechanismus ausführlicher
beschrieben.
-
Kandidatenbestimmung
-
Traversierung des gesamten Dateisystems
vermeiden:
-
Statt
die „besten" Migrationskandidaten
auf einmal zu finden, wird das Dateisystem nur so lange durchsucht,
bis eine bestimmte Anzahl Migrationskandidaten gefunden wurde. Anschließend wartet der
Prozess zur Kandidatenbestimmung auf das Eintreten eines der folgenden
zwei Ereignisse:
- • den Ablauf eines festgelegten
Warteintervalls oder
- • den
Start der Automigration.
-
In
diesem Fall setzt der Prozess die Durchsuchung des Dateisystems
an der Stelle fort, an der er einen vorherigen Suchlauf abgebrochen
hat, und sucht so lange weiter nach Migrationskandidaten, bis eine
bestimmte Anzahl von Kandidaten gefunden wurde. Diese Kandidaten
werden in die vorhandene Kandidatenliste aufgenommen und dann „qualitativ" (hinsichtlich Alter
und Größe) hierarchisiert,
sodass die Qualität
der Migrationskandidaten im System schrittweise verbessert wird.
-
Der
Vorteil dieses Ansatzes besteht darin, dass die Migrationskandidaten
dem Automigrationsprozess früher
zur Verfügung
stehen und dass der Ressourcenbedarf deutlich gesenkt wird, sodass
der Prozess zur Kandidatenbestimmung von der Anzahl der im Dateisystem
befindlichen Dateien und von der Größe des Dateisystems praktisch
unabhängig
ist.
-
Schnelle Eignungsprüfung:
-
Für die Migration
kommen nur Dateien in Frage, die nicht bereits migriert wurden.
In Dateisystemen wie dem Journaled File System (JFS) für AIX, die
keine XDSM-API (X/Open Data Storage Management API) besitzen, muss
der Migrationsstatus üblicherweise
durch das Lesen einer Rumpfdatei bestimmt werden. Zur Begrenzung
der Anzahl von Dateien, die der Prozess zur Kandidatenbestimmung
lesen muss, werden in der Regel nur diejenigen Dateien gelesen,
deren physische Größe den Kriterien
einer Rumpfdatei entspricht, wobei selbst dann die Leistungseinbußen bei
Dateisystemen mit einem hohen Anteil migrierter Dateien beträchtlich
sind, da der Lese-/Schreibkopf der Festplatte ständig zwischen dem Inode-Bereich
des Dateisystems und den tatsächlichen
Datenblöcken
hin- und herspringen muss. Um Abhilfe zu schaffen, fordert die vorliegende
Erfindung, dass alle Rumpfdateien ein bestimmtes Merkmal aufweisen
sollen, beispielsweise eine spezifische physische Dateigröße. Der
Prozess zur Kandidatenbestimmung kann dann davon ausgehen, dass alle
Dateien, deren physische Größe mit der
Größe der Rumpfdatei übereinstimmt,
migriert werden, und diese Dateien bei weiteren Eignungsprüfungen ignorieren,
die das Lesen der Rumpfdatei erfordern würden. Hiervon ausgeschlossen
sind residente Dateien, deren Größe sie wie
Rumpfdateien aus der Migration erscheinen lassen, aber es wird von
der Annahme ausgegangen, dass der prozentuale Anteil dieser Dateien
in einem typischen Dateisystem klein genug ist, um eine praktikable
Vereinfachung zu erzielen.
-
Der
Automigrationsprozess signalisiert zudem den Bedarf an zusätzlichen
Migrationskandidaten. Sobald das Dateisystem eine bestimmte Füllmenge überschreitet
oder nicht mehr über
genug Speicherkapazität
verfügt,
wird der Automigrationsprozess gestartet – in der Regel vom Überwachungsdämon, der
permanent im Hintergrund ausgeführt wird.
Dabei liest er Migrationskandidaten aus einem dedizierten Automigrationspool
ein und signalisiert dem Scoutprozess, seine Gruppe von Migrationskandidaten
auf der Festplatte abzulegen oder über den gemeinsam genutzten
Speicher in eine Migrationswarteschlange zu stellen. Anhand der
neu abgelegten Kandidatenliste kann der Automigrationsprozess dann
die Migration von Daten auf den fernen HSM-Server starten – vorzugsweise über mehrere Threads
und über
mehrere Prozesse, bei denen jede Instanz der Migrationsfunktion
für eine
bestimmte Dateigruppe zuständig
ist.
-
Damit
maximale Gleichzeitigkeit garantiert ist, kann der Scoutprozess
nach der Übertragung
seiner aktuellen Liste an den Automigrationsprozess sofort mit der
Suche nach neuen Migrationskandidaten beginnen. Die sofortige Generierung
einer neuen Kandidatenliste minimiert die Wartezeit bzw. gewährleistet,
dass dem Automigrationsprozess genügend Migrationskandidaten zur
Verfügung
stehen. Unter normalen Bedingungen werden neue Kandidaten viel schneller
gefunden als die Netzübertragung
der bereits gefundenen Kandidaten dauert, sodass angenommen werden
kann, dass dieser Vorgang in dieser Umgebung keinen Leistungsengpass
erzeugt.
-
Automigration
-
Parallele Automigration
-
Zur
Aufhebung der Skalierbarkeitseinschränkungen der traditionellen
seriellen Automigration schlägt
die vorliegende Erfindung ein Master/Slave-Konzept vor, dass die
parallele Automigration von Dateien desselben Dateisystems ermöglicht.
Bei diesem Konzept liest ein Master-Automigrationsprozess eine vom
Prozess zur Kandidatenbestimmung erstellte Liste der Migrationskandidaten
ein und verteilt Einträge
aus dieser Datei an eine bestimmte Anzahl von Automigrations-Slaves
(„Migrationsfunktionen"). Diese Slaves migrieren
die ihnen zugewiesene Datei zum HSM-Server und stehen dann wieder
für Migrationen
zur Verfügung,
die ihnen vom Masterprozess zugewiesen werden.
-
Der
entscheidende Vorteil ist, dass das Definieren der Anzahl parallel
arbeitender Automigrations-Slaves die Skalierbarkeit der Geschwindigkeit ermöglicht,
mit der die Dateien aus dem Dateisystem migriert werden können. Die
vollständige
Steuerung des Automigrationsprozesses bleibt sequenziell (Master-Automigrationsprozess),
sodass kein zusätzlicher
Synchronisationsaufwand erforderlich ist, wie es in anderen typischen
parallel arbeitenden Systemen der Fall wäre. Die „tatsächliche Arbeit”, d. h. die
eigentliche Migration der Dateien, die während des gesamten Automigrationsprozesses
die meiste Zeit in Anspruch nimmt, wird parallelisiert.
-
Abgleich
-
Unmittelbare Synchronisation:
-
Für den Abgleich
eines Client/Server-basierten HSM-Systems, muss der HSM-Client gemäß dem Stand
der Technik die folgenden Schritte ausführen:
- • Abrufen
der Liste („Serverliste") migrierter Dateien
eines gegebenen Dateisystems vom HSM-Server und
- • Traversieren
des Dateisystembaums und dabei Kennzeichnen jeder ungeänderten
migrierten Datei in der Serverliste als „gefunden".
-
Nach
Abschluss der Traversierung werden alle nicht als „gefunden" gekennzeichneten
Dateien in der Serverliste als aus einem Serverspeicherpool zu entfernende
Dateien gekennzeichnet, da entweder die Dateien aus dem Clientdateisystem
entfernt wurden oder ihre Clientkopie geändert wurde und dadurch die
Serverkopie ungültig
gemacht hat. Der dem Stand der Technik entsprechende Abgleichungsprozess
erfordert daher eine vollständige
Traversierung des Dateisystembaums, was die oben beschriebenen Skalierbarkeitsprobleme
aufwirft. Zur Vermeidung einer vollständigen Traversierung schlägt die Erfindung
den folgenden Verarbeitungsprozess vor:
- • Bei der
Migration von Dateien speichert der HSM-Client eine eindeutige,
für das
Dateisystem spezifische ID („Datei-ID") mit der Datei auf
dem HSM-Server.
- • Während des
Abgleichs ruft der HSM-Client die Liste migrierter Dateien, insbesondere
mit Hilfe der in der Liste oder Tabelle gespeicherten eindeutigen
ID, wie zuvor vom Server ab, wobei die Serverliste nun jedoch zu
jedem Eintrag die Datei-ID enthält.
- • Für jeden
Eintrag in der empfangenen Serverliste ruft der HSM-Client eine
plattformspezifische Funktion auf, welche die Dateiattribute einer
anhand ihrer Datei-ID ermittelten Datei zurückgibt. In IBM AIX (UNIX-Derivat)
wird der VFS-Einstiegspunkt
vfs_vget genutzt, der aufgerufen werden sollte, damit die Attribute
direkt aus dem zugrunde liegenden physischen Dateisystem eingelesen werden,
um das Lesen der Rumpfdatei zu vermeiden, wohingegen in DMAPI-fähigen Dateisystemen die API
dm_get_fileattr verwendet wird.
- • Wenn
die Attribute ermittelt werden konnten und mit den in der Serverliste
gespeicherten übereinstimmen,
wird der Verarbeitungsprozess mit Schritt 3 fortgesetzt, bis alle
Eintrage empfangen wurden. Andernfalls wird der Eintrag einer Liste („Löschliste") im Clientspeicher
hinzugefügt,
in der die vom Server zu entfernenden Dateien gekennzeichnet werden.
- • Wenn
alle Einträge
aus der Serverliste empfangen und verarbeitet wurden, geht der HSM-Client die
Löschliste
durch, und kennzeichnet jeden einzelnen von ihnen als aus dem Serverspeicherpool zu
entfernenden Eintrag.
-
Schnelle Vormigrationsprüfung:
-
Neben
den Dateistatus „migriert" und „resident" vergeben einige
HSM-Systeme einen dritten Status: „vormigriert". Eine Datei weist
den Status „vormigriert" auf, wenn ihre Kopie
auf dem Server (nach der Migration) mit der (residenten) Kopie der Datei
im Clientdateisystem identisch ist. Dies ist beispielsweise unmittelbar
nach dem Rückkopieren
einer migrierten Datei auf die lokale Platte der Fall: Die Datei
ist resident, aber ihre migrierte Kopie ist weiterhin im Serverspeicherpool
enthalten, und beide Kopien sind identisch.
-
Der
Vorteil des Vormigrationsstatus besteht darin, dass es zum Migrieren
dieser Dateien ausreicht, sie durch eine Rumpfdatei zu ersetzen,
ohne dass es erforderlich ist, die tatsächlichen Daten auf den HSM-Server
zu migrieren. In Dateisystemen ohne XDSM-API muss der HSM-Client
die vormigrierten Dateien in einer Umsetzdatenbank (als „Vormigrationsdatenbank" bezeichnet) erfassen,
da vormigrierten Dateien keine Rumpfdatei zugeordnet ist, die zum
Speichern der Vormigrationsinformationen verwendet werden könnte.
-
Diejenigen
HSM-Clients, die auf einer Umsetzdatenbank basieren, müssen das
lokale Dateisystem traversieren, um den Inhalt der Vormigrationsdatenbank
zu überprüfen. Wenn
jedoch das im vorherigen Abschnitt „Unmittelbare Synchronisation" vorgeschlagene Prinzip
angewendet wird, lässt
sich auch in diesem Fall eine vollständige Traversierung der Baumstruktur
vermeiden, indem eine eindeutige ID für jede vormigrierte Datei in
der Vormigrationsdatenbank gespeichert und dann eine direkte Zuordnung
ihrer Einträge
in das Dateisystem vorgenommen wird. Einträge, deren Zuordnung nicht mehr
erfolgreich ist, können
aus der Vormigrationsdatenbank entfernt werden.
-
Abschließend ist
zu betonen, dass die vorgeschlagenen Maßnahmen in ihrer Kombination
die dringlichsten Skalierbarkeitsprobleme und Leistungsengpasse
in traditionellen Client/Server-basierten HSM-Systemen lösen.