DE19924900A1 - Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen - Google Patents
Verfahren und Vorrichtung für Katastrophen-Behebung von DateisystemenInfo
- Publication number
- DE19924900A1 DE19924900A1 DE19924900A DE19924900A DE19924900A1 DE 19924900 A1 DE19924900 A1 DE 19924900A1 DE 19924900 A DE19924900 A DE 19924900A DE 19924900 A DE19924900 A DE 19924900A DE 19924900 A1 DE19924900 A1 DE 19924900A1
- Authority
- DE
- Germany
- Prior art keywords
- local
- file
- server
- primary
- remote
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
- G06F11/2074—Asynchronous techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2064—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring while ensuring consistency
Abstract
Ein Dateikatastrophenerholungssystem, das geographische Replikation von Daten von einem lokalen Standort zu einem entfernten Standort in einer derartigen Weise anwendet, daß Dateianforderungen von Klienten des lokalen Standortes durch einen Dateiserver am entfernten Standort nach einem Failover vom lokalen Standort zum entfernten Standort gehandhabt werden können. Geographische Datenreplikationssoftware, die auf einem lokalen Server läuft, checkpointet zu einem Protokoll in lokalem stabilem Speicher alle Information über Dateioperationen, die den Dateizustand des lokalen Dateisystems ändern. Gemäß einem ausgewählten Modus räumt die lokale geographische Datenreplikationssoftware Information in dem Protokoll, die die Dateioperationen seit dem letzten Räumen zum entfernten Standort betrifft. Am entfernten Standort empfängt kompatible entfernte geographische Datenreplikationssoftware, die auf einem entfernten Dateiserver läuft, das geräumte Protokoll und repliziert in aufeinanderfolgender Ordnung die in dem geräumten Protokoll repräsentierten Dateioperationen. Die Ergebnisse der Operationen werden in einem entfernten stabilen Speicher gespeichert. Die lokalen und entfernten Server können Cluster oder einzelne Server sein. Es besteht keine Notwendigkeit für Gemeinsamkeiten (commonality) zwischen dem lokalen und dem entfernten Standort mit Ausnahme der Betriebs- und Dateisysteme. Weil Operationen und keine formatierten Niedrigniveaudaten repliziert werden, können der lokale ...
Description
Die vorliegende Erfindung betrifft allgemein Katastrophen-
Behebungssysteme für Dateisysteme und insbesondere geographi
sche Replikationssysteme.
Computersysteme sind einer beliebigen Anzahl von betrieblichen
und umgebungsmäßigen Fehlern oder Fehlerzuständen bzw. Schäden
oder Störungen (faults) unterworfen, die von Plattenversagen
und Leistungsausfall bis zu Erdbeben und Fluten reichen. Wäh
rend eine Reparatur oder eine Ersetzung von zerstörten Aus
rüstungsgegenständen kostspielig ist, kann die Unterbrechung
des Zuganges zu kritischen Daten viel schwerwiegender sein. Aus
diesem Grunde treffen Betriebe bzw. Geschäfte weitreichende
Vorsichtsmaßnahmen zur Sicherstellung der Zugänglichkeit ihrer
Daten.
Der einfachste Schutz gegen Versagen ist die Replikation. Durch
Replikation einer Systemkomponente ist ein Ersatz zur Übernahme
bereit, falls das Primäre ausfallen sollte. Replikation kann
entsprechend den Schäden, gegen die sie schützt, auf vielen
Niveaus auftreten.
Der einfachste Weg, um nur Daten zu replizieren, ist mit Band-
Backups bzw. -Sicherungen. Band-Backups sind eine populäre Re
plikationsstrategie, weil sie einfach und kostengünstig sind.
Sie stellen sicher, daß Daten gesichert sind, wenn eine Platte
oder eine gesamte Maschine beschädigt oder zerstört wird. Wei
terhin können Band-Backups, wenn die Bänder weggenommen oder
in einem schützenden Gewölbe aufbewahrt werden, Daten gegen
standortweite (site-wide) Katastrophen schützen. Jedoch schüt
zen Band-Backups nur gegen die endgültige Unzugänglichkeit -
Datenverlust. Eine Wiederherstellung von Daten von einem Band
kann Stunden oder sogar Tage dauern und alle Änderungen seit
dem letzten Band-Backup sind verloren.
Eine Replikation von Platten bzw. Disks durch weit verbreitete
Strategien wie z. B. RAID schützt gegen Versagen bzw. Ausfall
einer einzigen Platte. Viele Anbieter bieten Plattenreplika
tionslösungen an, die wirksam und einfach zu handhaben sind.
Mit Plattenreplikation kann eine Wiederherstellung von einem
Plattenversagen schnell und für Anwendungen unsichtbar sein.
Jedoch berücksichtigt Plattenreplikation nicht das Versagen des
Hauptrechners (host machine) oder die Zerstörung eines gesamten
Standortes (site). In Verbindung mit Band-Backups kann Daten
verlust verhindert werden, aber die Verfügbarkeit wird Schäden
auf höherem Niveau erleiden.
Replikation einer Servermaschine schützt gegen Hardware- und
Software-Fehler auf dem Datenserver. Platten können zwei Ports
bzw. Tore aufweisen bzw. zweitorig (dual-ported) sein, was
mehr als einer Maschine einen direkten Zugang zu Rohdaten er
möglicht. Zusammen mit Plattenreplikationsstrategien kann ein
replizierter Server sogar nach Versagen einer einzelnen Platte
oder eines einzelnen Servers eine hohe Verfügbarkeit bereit
stellen. Genau wie bei replizierten Platten können Band-Backups
gegen Datenverlust bei einem standortweiten Versagen schützen,
aber es wird eine ausgedehnte Ausfallzeit auftreten.
Die Replikation eines gesamten Standortes über ausgedehnte
Entfernungen, "geographische Replikation" (geographic replica
tion) genannt, erhöht die Datenverfügbarkeit, indem standort
weite Schäden, wie zum Beispiel ausgedehnte Leistungsausfälle,
Feuer, Erdbeben oder sogar Terroristenangriffe berücksichtigt
werden. In einem geographischen Replikationssystem findet an
einem lokalen Standort normaler Systembetrieb statt. Daten
werden zu einem entfernten Standort gespiegelt (mirrored), der
Systemfunktionen übernehmen kann, wenn der lokale Standort
verloren ist. Geographische Replikation spiegelt nicht Anwen
dungsadressplätze oder irgendwelchen anderen flüchtigen Spei
cher; nur Daten, die in stabile Speichereinrichtungen geschrie
ben sind, werden zu dem entfernten Standort übertragen. Die
Verteilung von Cluster-Speicher über ausgedehnte Entfernungen
ist komplex und zeitaufwendig; entsprechend kann ein Failover
bzw. ein Umschalten oder ein Übergang (failover) zu dem ent
fernten Standort nicht so effektiv und unsichtbar durchgeführt
werden wie ein Failover zu einem sekundären Server oder "hot-
swapping" einer neuen Platte in ein Speicherfeld. Geographische
Replikation stellt flächendeckenden Schutz (blanket protection)
für hohe Verfügbarkeit bereit; d. h., wenn alle anderen Techni
ken versagen, kann unter einem geographischen Replikationsre
gime immer noch ein kompletter Standort-Failover stattfinden.
Ein gattungsgemäßes geographisches Replikationssystem 100 ist
in Fig. 1 gezeigt. Dieses System hat einen lokalen Standort
(local site) 102 mit einem Dateiserver (file server) 104, einem
Dateispeicher 106 (beispielsweise ein Festplattenlaufwerk), und
Klienten 108, 110. Es ist zu bemerken, daß der Ausdruck "lo
kal", wie er in der vorliegenden Anmeldung verwendet wird,
relativ ist; d. h., daß der lokale Standort einfach derjenige
Standort ist, dessen Server normalerweise die Klienten 104
bedient. Der lokale Standort 102 ist mit einem entfernten
Standort 112 (remote site) gekoppelt, möglicherweise durch ein
Großflächennetzwerk (wide area network) (WAN). Der entfernte
Standort 102 umfaßt einen Dateiserver 114 und Dateispeicher
116. Daten werden von der lokalen Platte 106 im Laufe des nor
malen Betriebes des lokalen Servers 104 zu der entfernten Plat
te 116 gespiegelt, so daß, falls ein Versagen auftreten sollte,
der entfernte Server in der Lage ist, Dateianforderungen (file
requests) von den Klienten 108 oder 110 mit minimalem oder
keinem Verlust des Dateisystemzustandes zu bedienen.
Ein geographisches Replikationssystem muß in der Lage sein,
alle Zustandsänderungen (im folgenden als Schreibungen bzw.
Schreibvorgänge (writes) bezeichnet) an Dateisystemen und Roh
einrichtungen zu erfassen (capture). An dem entfernten Standort
muß immer Selbstkonsistenz aufrechterhalten sein. Sogar wenn
der entfernte Standort nicht mit dem Primärstandort aktuell
ist, muß er intern konsistent sein. Geographische Replikation
von Daten muß für Anwendungen unsichtbar sein. Das Replika
tionssystem muß mindestens zwei Niveaus von Datensicherheit
unterstützen: 1-safe und 2-safe (für mehr Information siehe
Jim Gray und Andreas Reuter, "Transaction Processing: Concepts
and Techniques, "Morgan Kaufmann, San Francisco, CA, 1993, was
hierin durch Bezugnahme vollständig aufgenommen wird.
Im 1-safe-Modus oder asynchronen Modus protokolliert ein Repli
kationssystem Arbeitsschritte bzw. Operationen (operations) am
primären Standort und repliziert die Daten periodisch zum ent
fernten Standort. Im 1-safe-Modus muß die Protokollierung von
Arbeitsschritten, die noch nicht auf den entfernten Standort
angewendet wurden, in serielle Reihenfolge gebracht bzw. seria
lisiert und konsistent mit den an dem lokalen Standort angewen
deten Arbeitsschritten gemacht werden. Daher ist es, obwohl der
entfernte Standort hinter dem lokalen Standort hinterherhinken
kann, für eine Operation fast unmöglich, an dem entfernten
Standort angewendet zu werden, die nicht am lokalen Standort
angewandt wurde, und es ist für Operationen fast unmöglich, an
dem entfernten Standort in einer anderen Reihenfolge angewendet
zu werden als wie sie an dem lokalen Standort angewandt wurden.
Beim Starten (start-up) müssen der lokale und der entfernte
automatisch ihre Daten synchronisieren, so daß alle zukünfti
gen, beidseitig angewandten Operationen zu identischen Zustän
den führen. Das geographische Replikationssystem muß mit jeder
Replikationsdienstleistung kompatibel sein, die durch die Da
tenbasis bzw. Datenbank (database) bereitgestellt wird (für
mehr Information siehe Oracle, "Oracle7 Distributed Database
Technology and Symmetric Replication", zugänglich unter:
http://www.oracle.com/products/oracle7/server/whitepapers/rep lication/html/index.html) oder andere Anwendungen.
http://www.oracle.com/products/oracle7/server/whitepapers/rep lication/html/index.html) oder andere Anwendungen.
Der 2-safe-Modus oder synchrone Modus kopiert Daten zum ent
fernten Standort, bevor eine Operation am lokalen Standort
vollendet bzw. abgeschlossen werden darf. Das Replikations
system könnte auch ein zusätzliches Niveau von Datenkonsistenz
unterstützen, das "sehr sicherer Modus" (very safe mode) ge
nannt wird. Der sehr sichere Modus bzw. very-safe-Modus verbes
sert den 2-safe-Modus durch Hinzufügung eines zweiphasigen
Übergabeprotokolls (commit protocol), um die Konsistenz zwi
schen lokalen und entfernten Standorten sicherzustellen. Die
Synchronisation (oder Resynchronisation) von lokalen und ent
fernten Standorten, die im sehr sicheren Modus stattfindet,
sollte es nicht erfordern, daß der lokale Standort off-line
genommen bzw. abgekoppelt wird. Ein Nur-Lese-Zugriff (read-only
access) zum entfernten Standort sollte während des normalen
Betriebes verfügbar sein. Der Replikationsdienst (replication
service) sollte sich beim Hochfahren bzw. Booten des Systems
selbst konfigurieren und starten. Dies kann durch Verwendung
von boot-scripts und Anwenderniveauprogrammen erreicht werden,
die das Replikations-API aufrufen. Die Replikationsdienstlei
stung sollte einen Schutz gegen Dateilöschung bereitstellen.
Die Replikation von Daten zwischen geographisch voneinander
getrennten Standorte ist keine neue Idee. Verschiedene Anbieter
bieten schon Replikationslösungen an, die nun kurz beschrieben
werden.
EMC unterstützt die geographische Replikation in seinem Symme
trix-Produkt (für mehr Information siehe EMC, "Symmetrix 3000
und 5000 ICDA Product Description Guide", zugänglich unter:
http://www.emc.com/products/hardware/enterprise/new5000/
new5000.htm und EMC, "SRDF - Symmetrix Remote Data Facility",
zugänglich unter:
http://www.emc.com/products/software/buscont/srdf/srdf2.htm). Symmetrix ist eine Speicher-Hardwareeinheit, die mit SUN- Servern und dem Solaris-Betriebssystem kompatibel ist. Die Symmetrix Remote Data Facility (SRDF) stellt geographische Replikation für Symmetrix-Kunden bereit. SRDF erfordert die Verwendung eines Symmetrix-Speichersystemes sowohl an lokalen, als auch an entfernten Standorten. Die lokale Symmetrix-Einheit ist mit der entfernten Symmetrix-Einheit über eine ESCON-Faser leitung verbunden. Die ESCON-Grundleitungen sind auf 60 km be grenzt, aber mit einer zusätzlichen Einrichtung am sendenden und am empfangenden Ende können ESCON-Daten über großflächige Netzwerke (wide area networks) übertragen werden.
http://www.emc.com/products/software/buscont/srdf/srdf2.htm). Symmetrix ist eine Speicher-Hardwareeinheit, die mit SUN- Servern und dem Solaris-Betriebssystem kompatibel ist. Die Symmetrix Remote Data Facility (SRDF) stellt geographische Replikation für Symmetrix-Kunden bereit. SRDF erfordert die Verwendung eines Symmetrix-Speichersystemes sowohl an lokalen, als auch an entfernten Standorten. Die lokale Symmetrix-Einheit ist mit der entfernten Symmetrix-Einheit über eine ESCON-Faser leitung verbunden. Die ESCON-Grundleitungen sind auf 60 km be grenzt, aber mit einer zusätzlichen Einrichtung am sendenden und am empfangenden Ende können ESCON-Daten über großflächige Netzwerke (wide area networks) übertragen werden.
SRDF ist vollständig innerhalb der Symmetrix-Einheit implemen
tiert. Schreibvorgänge (writes) werden auf die Platte des loka
len Standortes angewendet und zum entfernten Standort entlang
der ESCON-Verbindung abhängig vom Betriebsmodus entweder syn
chron oder nicht-synchron übertragen. Die SRDF-Dokumentation
erwähnt ein stabiles Protokoll nicht, was bedeutet, daß Vorgän
ge bzw. Transaktionen verlorengehen können, wenn ein Zusammen
bruch auftritt, bevor die Übertragung stattfinden kann.
Weiterhin ist das SRDF bezüglich der Leistungsfähigkeit (per
formance) für große Entfernungen nicht gut geeignet. SRDF
unterstützt nicht-synchrone Replikation auf zwei Arten: halb
synchrone und adaptive Kopie. Im adaptiven Kopiermodus werden
Daten vom lokalen Standort zum entfernten Standort ohne Rück
quittungen (return acknowledgements) übertragen. Im halb
synchronen Modus wird am lokalen Standort eine I/O-Operation
ausgeführt, nach der die Steuerung an die Anwendung übergeben
wird. Die geschriebenen Daten werden dann asynchron zum ent
fernten Standort kopiert. Es werden keine anderen Schreibanfor
derungen für das logische Datenvolumen (logical volume) akzep
tiert, bis die Übertragung der ursprünglichen Anforderung quit
tiert (acknowledged) worden ist. Weil SRDF in die Speicherein
heit implementiert ist, werden I/O-Operationen als Niedrig-
Niveau SCSI- oder ESCON-Anweisungen ausgedrückt. Ein Schreibsy
stemaufruf könnte in verschiedene Kommandos für das Speichersy
stem übersetzt werden, wobei einige Daten und andere Dateisy
stem-Metadaten modifizieren. Wenn jeder dieser individuellen
Befehle über ein großflächiges Netzwerk quittiert werden muß,
bevor der nächste fortfahren kann, wird die Leistungsfähigkeit
am lokalen Standort leiden.
SRDF umfaßt einen synchronen Betriebsmodus. Aktualisierung
(updates) werden zuerst am lokalen Standort vorgenommen. Dann
werden die Daten zum entfernten Standort übertragen. Der Be
trieb am lokalen Standort kann nicht zurückkehren (return), bis
eine Quittung vom entfernten Standort empfangen worden ist.
Dieser synchrone Modus ist 2-safe, aber nicht sehr sicher (very
safe). Wenn der lokale Standort nach Vornahme der Aktualisie
rungen, aber vor deren Übertragung zum entfernten Standort ver
sagen sollte, dann wären die beiden Standorte inkonsistent.
Weiterhin stellt SRDF kein Protokoll bereit, durch welches die
Transaktionen, die bei einem Standortversagen verloren gingen,
bestimmt werden könnten.
Die Implementierung von Replikation auf einem derart niedrigen
Niveau hat andere Nachteile. Erstens wird, weil SRDF zwei Sym
metrix-Speichereinheiten verbindet, nur das Speichersystem am
entfernten Standort repliziert bzw. redupliziert. Wenn eine
Katastrophe den lokalen Standort arbeitsunfähig macht, muß am
entfernten Standort eine Ureingabe bzw. ein Urladen oder boot-
strap-Vorgang durchgeführt werden, um das Dateisystem zu repli
zieren, bevor die Daten verfügbar sein werden. Ein zweites
Problem mit dem Niedrigniveau-Ansatz ist, daß die Replikation
auf der Granularität (granularity) des gesamten Datenträgers
auftritt, anstatt an Dateien oder Verzeichnissen. Außerdem muß
die Hardware für gespiegelte Datenträger an den beiden Standor
ten symmetrisch sein. Schließlich ist SRDF eine gemischte Hard
ware- und Software-Lösung - es müssen alle Komponenten des
Speichersystemes von EMC bezogen werden.
Uniq unternimmt einen Hochniveau-Ansatz zur Replikation mit
einem neuen Dateisystem, das UPFS genannt wird (für mehr
Information siehe Uniq Software Services, "UPFS - A Highly
Available File System", July 21, 1997, White Paper zugänglich
unter: http:www.uniq.com.au/products/upts/UPFS-WhitePaper/UPFS-
WhitePaper-1.html). Auf Basis von VFS erfordert UPFS keine spe
zialisierte Hardware. Es handhabt verschiedene Dateisysteme auf
transparente Weise parallel, wobei lokal ursprüngliche Dateisy
steme und in der Entfernung NFS verwendet wird. Auf diese Weise
wird geographische Replikation unter Verwendung von NFS-Proto
kollen über Unix Netzwerkprotokolle durchgeführt.
Unglücklicherweise könnte NFS für geographische Replikation
nicht ideal geeignet sein. NFS-Protokolle stellen keine gute
Nutzung von großflächigen Netzwerken bereit. Beispielsweise
findet das Aufsuchen bzw. Nachschlagen von Namen (name lookup)
Komponente für Komponente statt. Die Öffnung einer Datei tief
in der Verzeichnishierarchie erfordert eine große Anzahl von
RPCs, was eine signifikante Latenz über eine ausgedehnte Ent
fernung verursacht. Auch gibt jeder erfolgreiche Schreibvorgang
einen kompletten Satz von Dateiattributen zurück, was wertvolle
Bandbreite verbraucht (für mehr Information siehe Nowicki,
Bill, "NFS: Network File System Protocol Specification", RFC
1094, März 1989, zugänglich unter: http://www.internic.net/rfc
/rfc 1094.txt). Ein anderer möglicher Nachteil von NFS ist, daß
es nicht den Export und die Montage bzw. Installation von Roh
einrichtungen unterstützt. Aus Gründen der Effizienz arbeiten
viele Datenbanken (databases) auf Roheinrichtungen anstatt
Dateien in einem strukturierten Dateisystem. Weil NFS keine
Operationen auf Roheinrichtungen unterstützt, kann UPFS für
diese Produkte eine geographische Replikation nicht bereitstel
len.
Zusätzlich erwähnt Uniq keine 2-safe- oder very-safe-Fähigkei
ten. Die Replikation wird asynchron durchgeführt, um die
Leistungsfähigkeit (performance) am lokalen Standort zu opti
mieren.
Qualix implementiert die geographische Replikation in seinem
DataStar-Produkt (für mehr Information siehe Qualix, "Qualix
DataStar Primer and Product Overview", April, 1997, White Paper
zugänglich unter: http://www.qualix.com/html/datastar wp.html).
DataStar verwendet einen speziellen Solaris-Einrichtungstrei
ber, der zwischen dem Dateisystem und regulären Einrichtungs
treibern installiert ist, um Schreibvorgänge (writes) auf Roh-
und Blockeinrichtungen abzufangen. DataStar protokolliert diese
Schreibvorgänge und ein Dämon-Prozess (daemon process) über
trägt das Protokoll über TCP/IP zum entfernten Standort. Das
Protokoll ist für alle Plattendatenträger innerhalb benutzerde
finierter, logischer Gruppen chronologisch geordnet.
DataStar fängt I/O-Kommandos unterhalb des Dateisystemes auf,
was das Layout von Daten und Metadaten auf dem Plattendatenträ
ger steuert bzw. kontrolliert. Dies erfordert eine Restriktion
bei der Symmetrie der lokalen und entfernten Standorte. Insbe
sondere muß eine replizierte logische Einrichtung am lokalen
Standort auf eine logische Einrichtung am entfernten Standort
abgebildet (mapped) werden und natürlich muß die Einrichtung am
entfernten Standort mindestens so groß sein wie die Einrichtung
am lokalen Standort. Die Eins-zu-eins-Abbildung ist nicht be
sonders restriktiv, bis eine Änderung erforderlich ist. Bei
spielsweise könnte die Vergrößerung eines replizierten Dateisy
stems oder die Hinzufügung von neuen replizierten Dateisystemen
eine durchschlagende Repartitionierung (disruptive repartition
ing) am Backup-Standort erfordern.
Qualix erwähnt nicht einen 2-safe-Betriebsmodus oder sehr si
cheren Betriebsmodus. Jedoch protokolliert DataStar replizierte
Operationen am lokalen Standort, was eine Wiedergewinnung der
Transaktionen, die bei einem Standortversagen oder -ausfall
verlorengingen, ermöglicht.
DataStar hat mit anderen Niedrigniveau-Ansätzen bezüglich der
Replikation ein anderes Merkmal bzw. Charakteristikum gemein
sam, indem Entscheidungen auf der Granularität eines gesamten
Datenträgers anstatt an Verzeichnissen oder Dateien durchge
führt werden muß.
Zusammenfassend ist die vorliegende Erfindung ein Dateisystem-
Katastrophenbehebungssystem, das eine geographische Replika
tion von Daten verwendet.
Insbesondere ist die vorliegende Erfindung ein geographisches
Datenreplikationssystem, das es ermöglicht, ausgewählte Datei
systemdaten von einem lokalen Standort an einen entfernten
Standort derart zu replizieren, daß, wenn der lokale Standort
versagt, Klienten des lokalen Standortes in der Lage sind,
Dateioperationen am entfernten Standort mit wenig oder keinem
Verlust von Dateizuständen wieder aufzunehmen. Viele Merkmale
der vorliegenden Erfindung sind in geographischer Replikations
software verkörpert, die sowohl an lokalen, als auch an ent
fernten Standorten ausgeführt wird. Am lokalen Standort wählt
die Software die zu replizierenden Dateisystemdaten aus und
überträgt die Daten gemäß einem besonderen Übermittlungs- bzw.
Übertragungsmodus an den entfernten Standort. Am entfernten
Standort protokolliert und speichert die Software die übertra
genen Daten so, daß Arbeitsvorgänge des lokalen Standortes
(local site operations) zum entfernten Standort übertragen bzw.
übergeben werden können.
Gemeinsame Aspekte bevorzugter Ausführungen werden mit den
Begriffen Systemtopologie (system-topology), Funktionalität
(functionality), Versagenscharakteristika (failure characteri
stics), Verwaltung (administration) und Leistung bzw. Lei
stungsfähigkeit (performance) beschrieben; diese Begriffe
werden in der detaillierten Beschreibung definiert.
Eine bevorzugte Ausführung des geographischen Replikations
systems umfaßt untereinander verbundene entfernte und lokale
Dateiserver, auf denen jeweils die geographische Replikations
software der vorliegenden Erfindung läuft bzw. die diese Soft
ware ausführen, kompatible Betriebssysteme und entsprechende
Dateisysteme (die gleichen oder unterschiedliche). Jeder
Standort hat zugeordneten, stabilen Dateispeicher, wie bei
spielsweise eine oder mehrere Festplatten oder Bandspeicher
einheiten. Die am lokalen Standort laufende geographische Re
plikationssoftware fängt alle Dateisystemanforderungen, die
von lokalen Klienten abgegeben werden, ab (intercepts). Die
Software bestimmt, ob eine angeforderte Operation das Dateisy
stem modifizieren wird (beispielsweise Dateischreibvorgänge)
und, falls dies der Fall ist, versucht sie, die Operation zum
entfernten Standort zu replizieren. Das System arbeitet in
einem besonderen Modus (entweder 1-safe, 2-safe oder very-
safe), der bestimmt, ob die lokale Standortsoftware die Datei
systemanforderung bzw. -aufforderung (request) nach einem Re
plikationsversuch an das lokale Dateisystem lediglich weiter
gibt (1-safe-Modus) oder die Weitergabe der Anforderung an das
lokale Dateisystem verzögert, bis es von der Software des ent
fernten Standortes gehört hat, daß die Replikationsoperation
vollendet war (2-safe, very-safe).
Die Replikationssoftware überträgt nur Dateisystemdaten, die
Dateisystemoperationen, Dateien und Partitionen umfassen und
den Anwendungsstatus bzw. -zustand (application state) aus
schließen. Weil die Software nur Dateisystemdaten überträgt,
kann das Replikationssystem so konfiguriert werden, daß es
Dateisystemoperationen auf jedem beliebigen Niveau des Dateisy
stems wieder ablaufen lassen kann (replay). Beispielsweise
können bei einer bevorzugten Ausführung die lokalen und ent
fernten Dateisysteme vier Niveaus umfassen: ein verteiltes/Clu
ster-Dateisystem (distributed/cluster file system) (PXFS), ein
Unix-Dateisystem (UFS) und Einrichtungstreiber, wie zum Bei
spiel einen Datenträgermanager (volume manager) (VM) und einen
SCSI-Treiber (SD). In einem solchen System können die Operatio
nen bzw. Arbeitsvorgänge von PXFS, UFS, VM oder SD zum entfern
ten Standort repliziert und am entfernten Standort wiedergege
ben bzw. wieder abgespielt (replayed) werden. Darüber hinaus
besteht, weil Operationen und nicht der Anwendungsstatus repli
ziert werden, keine Notwendigkeit, daß der Dateispeicher
gleichartig formatiert ist oder daß die Dateisysteme identisch
sind oder daß die Server gleichartig konfiguriert sind (bei
spielsweise kann einer der Server oder es können beide Server
ein Cluster-Server oder ein Einzelserver sein).
Bei einer bevorzugten Ausführung umfassen die Dateiserver
typischerweise einen Cache-Speicher (cache), wo in aktiver
Nutzung befindliche Dateidaten festgehalten werden, bis sie
zurück in den Dateispeicher geschrieben werden. Die Software
arbeitet mit dem Cache-Speicher so zusammen, daß sie Datei
systemoperationen nur repliziert, wenn diese Operationen tat
sächlich vom Cache-Speicher zum Dateispeicher geschrieben
werden.
Eine bevorzugte Ausführung kann so konfiguriert werden, daß sie
im Kontext eines Dateisystems hoher Verfügbarkeit (high availi
bility file system) arbeitet, bei dem ein primärer Server (bei
spielsweise der oben erwähnte Dateiserver) in Zusammenarbeit
mit einem sekundären Server arbeitet. Bei einer Konfigurierung
in dieser Weise sind die primären und sekundären Server jeweils
mit dem stabilen Dateispeicher gekoppelt, der ein Zwei-Tor-
Speicher ist bzw. zwei Tore hat bzw. zweitorig (dual ported)
ist. Der primäre Server antwortet auf Dateisystem (z. B. PXFS)-
Anforderungen von Klienten und überträgt durch Checkpointing
alle notwendige Information (inklusive Anwendungsstatus) mit
zum Sekundären (checkpoints all necessary information (. . .) to
the secondary), so daß der Sekundäre die Operationen sogar im
Fall eines kleineren Fehlers durch den primären Server überneh
men kann. Sowohl der primäre, als auch der sekundäre Server
sind so konfiguriert, daß sie die Replikationssoftware, wie
oben beschrieben, ausführen können; jedoch läuft die Software
nur in dem Server ab, der Online ist. Im Stand der Technik
kommunizieren der primäre und der sekundäre Server unter Ver
wendung eines Hochverfügbarkeits-Dateisystemprotokolls (bei
spielsweise Sun HA-PXFS). Die vorliegende Erfindung modifi
ziert die Checkpoint-Information, die zwischen dem Primären und
dem Sekundären unter HA-PXFS übertragen wird, so, daß der Se
kundäre die Replikationssoftware im Fall einer Abschaltung des
Primären ausführen kann.
In jeder der Ausführungen kann der Dateispeicher verteilt oder
singulär sein. Beispielsweise kann bei einer Ausführung, bei
der ein Dateiserver eine Ansammlung bzw. ein Cluster von Perso
nalcomputern umfaßt, von denen jeder eine Ein-Tor-Platte hat,
der Dateispeicher über jeden Untersatz (subset) dieser Platten
verteilt sein. Dies wird in der vorliegenden Erfindung durch
die Tatsache ermöglicht, daß Klientenanforderungen an die
Dateiserver unter Verwendung eines verteilten Dateisystems
(PXFS) gemacht werden.
Zusätzliche Ziele und Merkmale der Erfindung werden offensicht
licher werden aus der folgenden detaillierten Beschreibung und
den angehängten Ansprüchen in Verbindung mit den Zeichnungen,
in denen:
Fig. 1 ein Blockdiagramm einer gattungsgemäßen geogra
phischen Replikationssystemsarchitektur ist;
Fig. 2 ein Blockdiagramm einer bevorzugten Ausführung
eines geographischen Replikationssystems ist,
bei dem der lokale und der entfernte Standort
jeweils einen einzelnen Dateiserver verwenden;
Fig. 3 ein Blockdiagramm von Datenstrukturen ist, die
zu der Ausführung von Fig. 2 gehören;
Fig. 4 ein Diagramm ist, das die funktionellen Bezie
hungen zwischen dem Betriebssystem, den Datei
systemkomponenten und den Anwendungen erläutert,
die dem Stand der Technik und der vorliegenden
Erfindung gemeinsam sind;
Fig. 5 ein funktionelles Flußdiagramm ist, das trans
parente Dateizugriffsoperationen über vielfache
Knoten eines Clusters unter Verwendung eines
verteilten Dateisystems, wie beispielsweise
PXFS, verwendet;
Fig. 6 ein Flußdiagramm ist, das eine durch die vorlie
gende Erfindung verwendete erste Methode erläu
tert, Protokollinformation (log information) von
einem lokalen Standort zu einem entfernten
Standort zu übertragen;
Fig. 7 ein Flußdiagramm ist, das eine durch die vorlie
gende Erfindung verwendete zweite Methode erläu
tert, Protokollinformation (log information) von
einem lokalen Standort zu einem entfernten
Standort zu übertragen;
Fig. 8 ein Diagramm der Protokolldatei (log file) 264
einer bevorzugten Ausführung ist;
Fig. 9 ein Diagramm ist, das die Beziehung zwischen der
Protokolldatei 264 von Fig. 8 und dem Protokoll
anker (log anchor) einer bevorzugten Ausführung
zeigt; und
Fig. 10 ein Blockdiagramm einer bevorzugten Ausführung
eines geographischen Replikationssystems ist,
bei dem der lokale und der entfernte Standort
primäre und sekundäre Dateiserver umfassen, die
für eine hohe Verfügbarkeit konfiguriert sind.
Gemeinsame Aspekte bevorzugter Ausführungen werden mit den
Begriffen Systemtopologie, Funktionalität, Versagenscharakteri
stika, Verwaltung und Leistung beschrieben; diese Konzepte
werden nun definiert.
Die Topologie eines geographischen Re
plikationssystemes ist die Art und Weise, in welcher seine Kom
ponenten zusammengebaut bzw. montiert oder assembliert sind.
Die Topologie bevorzugter Ausführungsformen ermöglicht beliebi
ge (arbitrary) Entfernungen zwischen entfernten und lokalen
Standorten. Das heißt, daß der Ort jedes Standortes nur durch
die Reichweite des Netzwerkes begrenzt ist, an das die Standor
te angeschlossen sind. Zusätzlich müssen der lokale und der
entfernte Standort außer dem Erfordernis, daß es am entfernten
Standort ausreichend Speicherplatz für replizierte Daten geben
muß und daß die beiden Standorte in der Lage sein müssen, kom
patible Versionen von geographischer Replikationssoftware zu
nutzen, in der die vorliegende Erfindung verkörpert ist, keine
symmetrische Hardware haben. Das vorliegende System kann auch
so konfiguriert werden, daß eine beliebige Gruppierung von
vielfachen lokalen Standorten und vielfachen entfernten Stand
orten möglich ist. Das heißt, daß ein lokaler Standort Daten zu
mehr als einem entfernten Standort replizieren kann und daß ein
entfernter Standort Daten von mehr als einem lokalen Standort
sichern (backup) kann. Außerdem kann die geographische Replika
tionssoftware so konfiguriert werden, daß unterschiedliche
Netzwerkprotokolle unterstützt werden und daß sie unabhängig
vom Typ der Speicher-Hardware auf jeder Seite ist. Beim Ablauf
in einem global vernetzten Cluster kann der Server am lokalen
Standort so konfiguriert sein, daß er andere als direkte Netz
werkverbindungen verwendet.
Funktionalität bezieht sich
auf den Betrieb bzw. die Arbeitsweise eines geographischen
Replikationssystems. Das geographische Replikationssystem der
vorliegenden Erfindung erfaßt (captures) alle Zustandsänderun
gen (im folgenden als Schreibvorgänge bezeichnet) zu Dateisy
stemen und Roheinrichtungen (raw devices). Eine Selbstkonsi
stenz wird am entfernten Standort immer aufrechterhalten, sogar
wenn der entfernte Standort nicht aktuell (current) mit dem
lokalen Standort ist. Bei einer bevorzugten Ausführung sind die
geographischen Replikationsoperationen für Anwendungen unsicht
bar. Das Replikationssystem der vorliegenden Erfindung kann so
konfiguriert sein, daß es mindestens zwei Niveaus von Daten
sicherheit unterstützt, inklusive den 1-safe-Modus und dem 2-
safe-Modus, die im Hintergrund definiert werden. Im 1-safe-
Modus oder asynchronen Modus protokolliert die vorliegende Er
findung Operationen am lokalen Standort und repliziert die
Daten periodisch zum entfernten Standort. Im 2-safe-Modus oder
synchronen Modus kopiert die vorliegende Erfindung Daten zum
entfernten Standort, bevor erlaubt wird, daß eine Operation am
lokalen Standort vervollständigt wird. Ohne Rücksicht auf den
Modus synchronisieren beim Hochfahren (start-up) der lokale
und der entfernte Standort automatisch ihre Daten, so daß jeg
liche zukünftige, beidseitig angewandte Operationen zu identi
schen Zuständen führen. Zusätzlich kann das geographische Re
plikationssystem so konfiguriert sein, daß es mit jedem durch
eine Datenbank bereitgestellten Replikationsdienst kompatibel
ist (für mehr Information siehe Oracle, "Oracle7 Distributed
Database Technology and Symmetric Replication", zugänglich
unter: http://www.oracle.com/products/oracle7/server/white
papers/replication/html/index.html., was hierin durch Bezugnah
me vollständig aufgenommen wird) oder anderen an den lokalen
oder entfernten Standorten laufenden Anwendungen.
Das Replikationssystem der vorliegenden Erfindung kann auch so
konfiguriert sein, daß es ein zusätzliches Niveau von Daten
konsistenz unterstützt, das sehr sicherer Modus (very safe
mode) genannt wird. Der sehr sichere Modus verbessert den 2-
safe-Modus, indem es ein zweiphasiges Übertragungsprotokoll zur
Sicherstellung der Konsistenz zwischen lokalen und entfernten
Standorten hinzufügt. Zusätzlich kann das Replikationssystem so
konfiguriert sein, daß:
- 1. die Synchronisation (oder Resynchronisation) von lokalen und entfernten Standorten nicht erfordert, daß der lokale Standort off-line genommen wird;
- 2. während normalem Betrieb ein Nur-Lese(read-only)- Zugriff zum entfernten Standort verfügbar ist;
- 3. sich das Replikationssystem beim Herauffahren des Systems selbst konfiguriert und startet; und
- 4. ein Schutz gegen Dateilöschung bereitgestellt wird.
Versagens
charakteristika definieren das Verhalten des geographischen
Replikationssystems bzw. bei Auftreten eines Ausfalls, Ver
sagens oder Fehlers (failure). Im 1-safe-Modus setzt der lokale
Standort den Betrieb nach einem Fehler oder dem Verlust der
Verbindung zum entfernten Standort fort. Nach einem zeitweisen
Verlust der Verbindung mit dem entfernten Standort oder einem
Versagen des entfernten Standortes resynchronisieren sich der
lokale und der entfernte Standort automatisch. Die vorliegende
Erfindung ist so konfiguriert, daß ein manuelles Umschalten auf
den entfernten Standort nach einem Versagen des lokalen Stand
ortes immer möglich ist. Das heißt, daß der entfernte Standort
immer bereit ist, nach einem lokalen Versagen Lese- und
Schreib-Transaktionen bzw. -vorgänge durchzuführen. Sowohl im
1-safe-Modus, als auch im 2-safe-Modus kann das Ausmaß an Da
tenverlust bei einem Versagen des lokalen Standortes im Hin
blick auf die Zeit seit der vorhergehenden Protokoll-Räumung
(log flush), die Größe der nicht geräumten Daten (unflushed
data) oder der Anzahl der nicht an den entfernten Standort
übertragenen Operationen abgeschätzt werden. Beim very safe-
Modus gehen keine Daten verloren.
Zusätzlich kann das vorliegende Wiedergewinnungssystem so kon
figuriert sein, daß ein Protokoll (log) von verlorenen Transak
tionen bereitgestellt wird, das vom lokalen Standort nach sei
ner Wiederherstellung nach einem Versagen verwendet werden
kann. Vorzugsweise übernimmt der entfernte Standort automatisch
nach einem Versagen des lokalen Standortes. Zusätzlich kann bei
einer bevorzugten Ausführung, wenn der ursprüngliche lokale
Standort nach einem Failover zum entfernten Standort wieder
hergestellt ist, er automatisch als der lokale Standort resyn
chronisiert und wieder installiert werden.
Eine Einfachheit bei der Verwal
tung ist kritisch für die Akzeptanz des geographischen Replika
tionssystems. Die Wichtigkeit der Verwaltung nimmt mit der Zu
nahme der Flexibilität und der Anzahl von Merkmalen bzw. fea
tures zu. Der geographische Replikationsdienst der vorliegenden
Erfindung stellt einen API auf Anwenderniveau bereit, um Mana
gement-Programme oder Anwendungen zu unterstützen, die Replika
tionscharakteristika ändern müssen. Voreingestellte Werte (de
fault values) werden für Parameter bereitgestellt, wann immer
dies möglich ist. Alternativ stellt die vorliegende Erfindung
einen Assistenten bzw. ein Assistenzprogramm (wizard) bereit,
um bei der Verwaltung des Replikationssystems zu assistieren.
Der kritische Leistungspunkt ist das
Ausmaß, bis zu dem das vorliegende geographische Replikations
system die Leistung bzw. Leistungsfähigkeit von Vorgängen (z. B.
Lese- und Schreibvorgängen) am lokalen Standort verschlechtert
bzw. degradiert. Wenn das geographische Replikationssystem im
synchronen Modus (2-safe-Modus) ist, werden Schreibvorgänge
stark verlangsamt aufgrund der Notwendigkeit, Schreibvorgänge
zu verzögern, bis relevante Daten an den entfernten Standorten
repliziert sind. Im 1-safe-Modus wird die Leistungsfähigkeit
von Schreibvorgängen am lokalen Standort um nicht mehr als
10 Prozent verschlechtert. In allen normalen Betriebsmoden wird
die Leistungsfähigkeit von Lesevorgängen nur vernachlässigbar
oder überhaupt nicht verschlechtert. Der Systemschreibbetrieb
für den sehr sicheren Modus ist aufgrund des diesem Modus
zugeordneten, zweiphasigen Übergabeprozesses sogar langsamer
als im 2-safe-Modus.
In Bezug auf Fig. 2 ist dort ein Blockdiagramm einer bevorzug
ten Ausführungsform 120 eines geographischen Replikationssyste
mes gezeigt, das zur Replikation von Dateisystemdaten von einem
lokalen Standort zu einem entfernten Standort verwendet werden
kann. Es wird angenommen, daß das auf allen Standorten laufende
Betriebssystem das SUN Solaris-System ist; jedoch sind die
Lehren der vorliegenden Erfindung auch auf andere Netzwerkbe
triebssysteme mit nur geringfügigen, offensichtlichen Modifika
tionen leicht anwendbar. Der lokale Standort umfaßt einen
Dateiserver 122, Klienten 124, stabilen Dateispeicher 126 und
Roheinrichtungen 128. Der Dateiserver umfaßt einen schnellen
Cache-Speicher 130 und hat Dateisystem-Software 148 geladen,
daß Dateisystemanforderungen (2.1) des Nutzers gegen Daten in
dem Cache 130, dem stabilen Dateispeicher 126 und den Rohein
richtungen 128 in herkömmlicher Weise auflöst (resolve). Jeder
der Klienten 124 umfaßt auch einen Cache 132 und Dateisystem
software 150, die kompatibel mit der Dateisystem-Software 148
des Servers ist.
Die Klienten 124 geben die Anforderungen (2.1) unter Verwen
dung eines verteilten Dateisystemprotokolls (distributed file
system (DFS) protocol) ab. Bei SUN Solaris ist das DFS das
Proxy-Dateisystem (Proxy File System (PXFS)), das auch Galileo
genannt wird. Entsprechend umfaßt das Serverdateisystem 148
PXFS-Server-Software 134, das Klientendateisystem 150 umfaßt
PXFS-Klienten-Software 136 und die Dateisystemanforderungen
(2.1) werden an einen PXFS-Server-Eingangspunkt abgegeben. Der
Dateispeicher 126 kann eine einzelne Festplatte oder eine
beliebige Kombination einzelner Festplatten, ein Cluster von
Festplatten, eine Zwei-Tor-Festplatte, ein Bandlaufwerk oder
ein beliebiger anderer Typ einer nicht-flüchtigen Speicherein
richtung oder eine beliebige Kombination dieser Einrichtungen
sein. Bei einer bevorzugten Ausführung greift das Dateisystem
148 auf den Dateispeicher 126 unter Nutzung des Unix File
System-Protokolls (Unix File System (UFS) protocol) und auf die
Roheinrichtungen 128 unter Nutzung des speziellen Dateisystem
protokolls (Spezial File System (SpecFS) protocol) zu. Sowohl
UFS als auch SpecFS sind Teil des Sun Solaris-Betriebssystems.
Der entfernte Standort umfaßt einen Dateiserver 140, stabilen
Dateispeicher 142 und nicht gezeigte, optionale Roheinrichtun
gen. Der Dateiserver 140 umfaßt einen schnellen Cache-Speicher
152 und hat Dateisystem-Software 154 geladen, die Dateianforde
rungen gegen Daten in dem Cache 152, dem stabilen Dateispeicher
142 oder den Rohreinrichtungen auflöst (resolve). Die Dateisy
stem-Software 154 umfaßt auch PXFS-Server-Software 156. Der
Dateispeicher 142, die Roheinrichtungen und Cache-Speicher 152
sind nicht notwendigerweise ähnlich oder artgleich mit den
analogen Elementen 126, 128 und 130 des lokalen Standortes.
Beispielsweise können die Dateispeicher 126 und 142 komplett
unterschiedlich sein, solange der entfernte Dateispeicher 142
alle replizierten Daten von dem lokalen Dateispeicher 126
aufnehmen kann. Der entfernte Server 140 ist vorzugsweise mit
dem lokalen Server 122 über eine großflächige Netzwerkverbin
dung (wide area network, (WAN) connection) verbunden, aber es
wird jeder Typ von Verbindung ausreichen. Wenn der lokale
Server 122 Dateisystemanforderungen (2.1) handhabt, gibt er
Ferndateneinrichtungsnachrichten (remote data facility (RDF)
messages) (2.2) an den entfernten Server 140 ab. Der Zweck der
RDF-Nachrichten (2.2) ist es, genug Information an den Server
140 zu übertragen, um den Server 140 in die Lage zu versetzen,
Dateianforderungen (2.1) von den Klienten 124 zu handhaben,
wann immer ein Failover vom lokalen Server 122 zu dem entfern
ten Server 140 stattfindet.
Der RDF-Prozess wird durch geographische Replikationssoftware
gehandhabt, die "Telescope" 160 genannt wird, und die sowohl am
entfernten, als auch am lokalen Server als eine Erweiterung von
PXFS/Galileo läuft. Neben anderen Dingen bestimmt die Teles
cope-Software 160L am lokalen Server 122, welche Dateisystemda
ten in den RDF-Nachrichten (2.2) übertragen werden. Die Teles
cope-Software 160R am entfernten Server 140 arbeitet mit seinem
Dateisystem 154 zusammen, um die RDF-Daten von dem lokalen
Server 122 in dem Dateispeicher 126 oder den Rohreinrichtungen
zu speichern und bestimmt, wenn ein Failover auftritt, wie ein
konsistenter Dateisystemzustand bei gegebenen übertragenen RDF-
Daten einzurichten bzw. aufzubauen ist. Wenn er einen konsi
stenten Dateisystemzustand aufgebaut hat, ist der entfernte
Server 140 in der Lage, Dateisystemanforderungen (2.1) zu hand
haben, die von dem lokalen Standort nach einem Failover über
tragen wurden.
Bei einer bevorzugten Ausführung ist Telescope 160 eine Verbes
serung oder Optimierung des PXFS-Cluster-Dateisystems (für mehr
Information bzgl. PXFS siehe Vlada Matena, Yousef A. Khalidi,
Ken Shirriff, "Solaris MC File System Framework", Sun Microsy
stems Laboratories Technical Report SMLI TR-96-57, October
1996, der hier vollständig durch Bezugnahme aufgenommen wird).
Telescope 160 befindet sich auf der Serverseite von PXFS (bei
spielsweise am lokalen Server 122), wo es Zustandsänderungen am
PXFS-Dateisystem erfaßt. Zustandsänderungen am Dateisystem 148
am lokalen Standort werden am lokalen Standort durch Telescope
160L als Operationen und ihre Parameter kodiert. Telescope 160L
überträgt die kodierten Operationen an den entfernten Standort
unter Verwendung gattungsgemäßer Unix-Netzwerkhilfsprogramme
(networking utilities). Am entfernten Standort dekodiert der
Telescope-Empfänger 160R die Operationen und wendet die deko
dierten Operationen auf eine Kopie 154 des auf dem entfernten
Server 140 laufenden Dateisystems 148 an. Durch Anwendung der
gleichen Operationen am entfernten Standort, wie sie am lokalen
Standort angewandt wurden, hält Telescope 160 die beiden Stand
orte in den gleichen Zuständen.
Telescope 160 beinhaltet bzw. inkorporiert einige der Vorteile
anderer geographischer Replikationsstrategien. Wie Uniq UPFS
ist Telescope 160 in ein Dateisystem (beispielsweise die Datei
systeme 148, 154) integriert, anstatt in einen Einrichtungs
treiber oder eine Speichereinheit. Der Dateisystemansatz ermög
licht Telescope 160 Flexibilität und Effektivität bei der Hand
habung von Datei- und Verzeichnisoperationen mit hohem Niveau.
Wie Qualix DataStar hat Telescope 160 ein stabiles Protokoll
162 (stable log) (Fig. 2) eingebaut bzw. inkorporiert, um
Operationen zu speichern, die noch nicht an den entfernten
Standort übertragen wurden. Bei einer bevorzugten Ausführung
ist das Protokoll 162 auf einer lokalen Platte 126 gespeichert.
Dies erhöht die Datensicherheit dadurch, daß verlorene Transak
tionen nach einem Systemzusammenbruch wieder gewinnbar gemacht
werden. Schließlich stellt Telescope, wie EMC SDRF, variable
Modi von Konsistenz zwischen lokalem und entferntem Standort
bereit.
Telescope 160 hat 1-safe-, 2-safe- und very safe-Übertragungs
modi. Der sehr sichere Modus (very safe mode) hat zwar schlech
te Latenz, garantiert aber, daß Transaktionen zwischen den
Standorten konsistent sind. Der 2-safe-Modus verbessert die
Latenz bzgl. des sehr sicheren Modus, aber es werden Konsi
stenzgarantien geopfert. Er hält den lokalen und den entfernten
Standort auf Schritt (lockstep), was die Daten, die während
eines Versagens verloren gehen könnten, reduziert. Der 1-safe-
Modus optimiert die Leistung am lokalen Standort, aber garan
tiert keine konstante Konsistenz zwischen dem lokalen und dem
entfernten Standort.
Bei einer bevorzugten Ausführung ist der Failover eine manuelle
Operation. Ein Systemverwalter (system administrator) muß ent
scheiden, daß der lokale Standort heruntergefahren bzw. abge
schaltet (down) ist und dann den PXFS-Dienst (d. h. den PXFS-
Server 156) am entfernten Standort starten. Jedoch sind die
Lehren der vorliegenden Erfindung gleichermaßen anwendbar auf
Systeme mit Cluster-Herzschlag-Fernüberwachungen (long-distance
cluster heartbeat monitors) und verbesserten Verwaltungswerk
zeugen (tools) zur Automatisierung dieser Failover-Aufgaben.
Bevor zusätzliche Details über Telescope 160 bereitgestellt
werden, werden nun die Datenstrukturen und Programme, die dem
lokalen und dem entfernten Standort zugeordnet sind, mit Bezug
auf Fig. 3 beschrieben werden.
In Bezug auf Fig. 3 ist dort ein Blockdiagramm mit Elementen
gezeigt, die den beiden Servern 122, 140, den Roheinrichtungen
128, 158 und den Dateispeichereinrichtungen 126, 156 gemeinsam
sind. Die vorliegende Beschreibung ist auf die Versionen dieser
Elemente am lokalen Standort gerichtet und ist für den entfern
ten Server 140 verallgemeinerbar. Die Beschreibungen dieser
Elemente sind auch allgemein anwendbar auf die Klienten 126 mit
offensichtlichen Ausnahmen (z. B. umfaßt der Klient 126 Klien
tenversionen von Dateisystemkomponenten, anstatt Serverversio
nen). Der Server 122 umfaßt eine Zentraleinheit bzw. einen
Zentralprozessor (central processing unit (CPU)) 202, einen
Hochgeschwindigkeitsspeicher 204, einen Cache-Speicher 130 und
eine Vielzahl von Einrichtungsschnittstellen 206 (z. B. Busse
oder andere elektronische Schnittstellen), die es der CPU 202
ermöglichen, den Speicher 204, die Roheinrichtungen 128 und
Dateispeicher 126 zu steuern und mit diesen Daten auszutau
schen.
Die Roheinrichtungen 128 können Einrichtungen mit hoher Verfüg
barkeit, Drucker, Kernspeicher (kernel memory), Kommunikations
einrichtungen und Speichereinrichtungen (beispielsweise Plat
tenspeicher) umfassen, sind aber nicht auf diese beschränkt.
Drucker und Speichereinrichtungen sind wohlbekannt. Einrichtun
gen mit hoher Verfügbarkeit umfassen Einrichtungen, wie zum
Beispiel Speichereinheiten oder Drucker, die zugeordnete sekun
däre Einrichtungen haben. Solche Einrichtungen sind hochgradig
verfügbar, da die sekundären Einrichtungen für ihre entspre
chenden primären Einrichtungen bei einem Versagen der Primär
einrichtungen einspringen können. Kernspeicher (kernel memory)
ist ein programmierter Bereich des Speichers, der die Sammlung
und den Bericht von Systemleistungsstatistiken (system perfor
mance statistics) umfaßt. Kommunikationseinrichtungen schließen
Modems, ISDN-Schnittstellenkarten, Netzwerkschnittstellenkarten
oder andere Typen von Kommunikationseinrichtungen ein. Die Roh
einrichtungen 128 können auch Pseudo-Einrichtungen umfassen,
die Software-Einrichtungen sind, die nicht einer tatsächlichen
physikalischen Einrichtung zugeordnet sind.
Der Speicher 204 des Servers 122 kann ein Betriebssystem 210,
Anwendungsprogramme 212 und Datenstrukturen 214 speichern. Das
Betriebssystem 210 wird in der CPU 202 ausgeführt, solange der
Computer 122 betriebsbereit (operational) ist und Systemdienste
für die in der CPU 202 ausgeführten Anwendungen 212 bereit
stellt. Das Betriebssystem 210, das auf das auf Sun®-Worksta
tions verwendete v.2.6. Solaris™-Betriebssystem aufgebaut ist,
schließt einen Kern (kernel) 216 und das Dateisystem 148 ein
(Solaris und Sun sind (nicht eingetragene) Marken bzw. einge
tragene Marken von Sun Microsystems, Inc.). Der Kern 216 hand
habt Systemaufrufe von den Anwendungen 212, beispielsweise
Anforderungen für einen Zugriff auf den Speicher 204, das
Dateisystem 148 oder Einrichtungen 128. Das Dateisystem 148
schließt beliebige Dateisystemkomponenten ein, die für den
Server 122 erforderlich sind, inklusive dem UFS 220, einem
Solaris-Netzwerk-Dateisystem (NFS) 222, dem PXFS 224 ein
schließlich dem PXFS-Server 134 und der Telescope-Software
160, dem SpecFS 226 und einem hochgradig verfügbaren Cluster-
Dateisystem (HA-PXFS) 228.
Die Datenstrukturen 214 umfassen einen Protokollanker (log
anchor) 230, der die durch das lokale Telescope-Programm 160L
aufgezeichneten bzw. protokollierten Operationen, die an das
entfernte Telescope-Programm iGOR übertragenen Protokolldaten
sätze (log records) und die Übertragungen (transfers) dokumen
tiert, die durch den entfernten Standort quittiert wurden. Der
Protokollanker 230 ist vorzugsweise für einen schnelleren Zu
griff im Speicher 204 gespeichert, kann aber auch auf der
Platte 126 oder den Roheinrichtungen 128 gespeichert sein. Der
Protokollanker 230 umfaßt die folgenden Felder: next_rec 242,
prev_rec 244, last_flushed 246, last_ACK 248, circular 249 und
timestamp_anchor 250. Diese Felder werden unten im Kontext des
geräumten bzw. abgelassenen (flushed) Protokollankers 280 be
schrieben, der eine auf der Platte 136 gespeicherte Version
des Protokollankers 230 ist. Die Datenstrukturen umfassen auch
einen Systemmodus 232, der anzeigt, ob Telescope 160 im 1-safe-
Modus, 2-safe-Modus oder very_safe-Modus arbeitet.
Die Platte 126 ist eine in Dateien und/oder Partitionen 262
organisierte Sammlung von Daten. Ein Schlüsselelement der vor
liegenden Erfindung ist die Protokolldatei (log file) 264, die
vorzugsweise auf der Platte gespeichert ist, aber optional auf
einer der Roheinrichtungen 128 gespeichert werden könnte. Die
Protokolldatei 264 umfaßt eine Anzahl von Datensätzen bzw. Auf
zeichnungen (records) 266, von denen jede genug Information
über ein an die Platte 126 übertragene Dateisystemanforderung
(2.1) enthält, um zu ermöglichen, daß die Anforderung (2.1)
durch den entfernten Server 140 befriedigt bzw. erledigt
(satisfied) wird (unter der Annahme, daß die Daten über eine
RDF-Nachricht (2.2) übertragen werden). Jede Aufzeichnung 266
umfaßt einen Kopf (header) 268 und einen Körper (body) 279. Der
Kopf wird dazu verwendet, die Protokolldaten zu dekodieren und
umfaßt die Information, die folgendes anzeigt:
die Beziehung eines Datensatzes 266i ("i" ist ein ganz
zahliger Index) zu benachbarten Datensätzen 266i+1, 266i-1
(next_rec 270, prev_rec 272);
wann ein Datensatz geschrieben wurde (timestamp 74);
ein eindeutiges (unique) Transaktionskennzeichen (transac tion_id 276); und
die Länge der Transaktion (transaction_length 278).
wann ein Datensatz geschrieben wurde (timestamp 74);
ein eindeutiges (unique) Transaktionskennzeichen (transac tion_id 276); und
die Länge der Transaktion (transaction_length 278).
Der Körper 279 enthält die durch den Kopf 268 beschriebene,
protokollierte bzw. aufgezeichnete Dateiinformation.
Die Platte 136 umfaßt auch eine geräumte (flushed) log_anchor-
Datenstruktur 280, die Information enthält, die zur Dekodierung
der Protokolldatei 264 und zur Rekonstruktion des Protokolls
(beispielsweise am entfernten Standort) verwendet wird. Die
geräumte log_anchor-Datenstruktur 280 ist identisch mit dem
log_anchor 230 formatiert und umfaßt die folgenden Felder:
next_rec 282, prev_rec 284, last_flushed 286, last_ACK 288 und timestamp_anchor 290. Die Struktur 280 wird als geräumter (flushed) log_anchor bezeichnet, weil sie in den stabilen Spei cher 126 nur geschrieben wird, nachdem Telescope 160 das Proto koll 264 zur entfernten Telescope-Instanz 160R geräumt (flush ed) hat. Vor der weiteren Beschreibung der Arbeitsweise der vorliegenden Erfindung werden nun das Dateisystem 148 und seine Beziehung zur Platte 136 und den Roheinrichtungen 128 mit Bezug auf Fig. 4 beschrieben.
next_rec 282, prev_rec 284, last_flushed 286, last_ACK 288 und timestamp_anchor 290. Die Struktur 280 wird als geräumter (flushed) log_anchor bezeichnet, weil sie in den stabilen Spei cher 126 nur geschrieben wird, nachdem Telescope 160 das Proto koll 264 zur entfernten Telescope-Instanz 160R geräumt (flush ed) hat. Vor der weiteren Beschreibung der Arbeitsweise der vorliegenden Erfindung werden nun das Dateisystem 148 und seine Beziehung zur Platte 136 und den Roheinrichtungen 128 mit Bezug auf Fig. 4 beschrieben.
In Bezug auf Fig. 4 ist dort eine Hochniveau-Darstellung des
Dateisystems 148 gezeigt, das durch v.2.6 und vorherige Versio
nen des Solaris-Betriebssystems und der vorliegenden Erfindung
verwendet wird. Bei Solaris ist das Dateisystem 148 das Medium,
über das auf alle Dateien, Einrichtungen und Netzwerkschnitt
stellen zugegriffen wird. Diese drei unterschiedlichen Typen
von Zugriffen werden jeweils durch drei Komponenten des Datei
systemes 148 bereitgestellt: das UFS 320, das SpecFS 326 und
das NFS 322. Jedes der konstituierenden bzw. am Aufbau betei
ligten Dateisysteme wird durch ein Hochniveau(top level)
vnode-Betriebssystem 298 gesteuert.
Bei Solaris greift eine Anwendung 212 anfänglich auf eine
Datei, eine Einrichtung oder eine Netzwerkschnittstelle (die
hierin alle als Ziel (target) bezeichnet werden), durch Abgabe
einer Öffnen-Anforderung für das Ziel an das Dateisystem 148
über den Kern 216 zu. Das Dateisystem 148 gibt dann die Anfor
derung in geeigneter Weise an das UFS 320, SepcFS 326 oder NFS
322 weiter. Wenn das Ziel erfolgreich geöffnet ist, gibt das
UFS, SpecFS oder NFS dem Dateisystem 148 ein vnode-Objekt 300
zurück, das in die angeforderte Datei, die Einrichtung oder im
Netzwerkknoten abgebildet wird. Das Dateisystem 148 bildet dann
das vnode-Objekt 300 auf einen Dateibeschreiber (file descrip
tor) 301 ab, der über den Kern 216 zur Anwendung 212 zurückge
geben wird. Die anfordernde Anwendung 212 nutzt anschließend
den Dateibeschreiber 301, um auf die entsprechende Datei, die
Einrichtung oder den Netzwerkknoten, der dem zurückgegebenen
vnode-Objekt 300 zugeordnet ist, zuzugreifen.
Die vnode-Objekte 300 stellen einen gattungsgemäßen Satz von
Dateisystemdiensten gemäß dem vnode/VFS-Betriebssystem (VFS)
298 bereit, das als Schnittstelle zwischen dem Kern 216 und dem
Dateisystem 148 dient. Solaris stellt auch mode-, snode- und
mode-Objekte 300i, 300s, 300r bereit, die von den vnode-
Objekten 300 erben (inherit) und auch Verfahren und Datenstruk
turen beinhalten, die an die Typen von Zielen, die mit dem
UFS, SpecFS bzw. NFS zugeordnet sind, angepaßt (customized)
sind. Diese Klassen 300i, 300s und 300r bilden die Niedrigni
veau-Schnittstellen zwischen den vnoden 300 und ihren jeweili
gen Zielen. Daher wird, wenn das UFS, SpecFS oder NFS ein
vnode-Objekt zurückgibt, das Objekt einem entsprechenden inode,
snode oder rnode zugeordnet, das die tatsächliche Zieloperatio
nen ausführt. Ähnliche Prinzipien sind beteiligt, wenn eine
auf einem Knoten (z. B. dem Klienten 124-1) laufende Anwendung
eine Dateioperation auf einer auf einem anderen Knoten (z. B.
dem Klienten 124-2) befindlichen Datei anfordert, wobei beide
Knoten innerhalb eines Clusters unter der Steuerung eines
einzelnen PXFS 324 stehen. Wie das PXFS 324 solch eine Anforde
rung handhabt, ist wohlbekannt, aber wird hier kurz mit Bezug
auf Fig. 5 beschrieben.
Mit Bezug auf Fig. 5 ist dort ein Flußdiagramm von Schritten
gezeigt, die von einem Computersystem ähnlich dem, in dem die
vorliegende Erfindung implementiert ist, als Antwort auf eine
Anforderung (5-1) von einer an einem Knoten 332-1 ausgeführten
Anwendung 212 zur Öffnung einer Datei 324 ausgeführt wird, die
sich auf einem anderen Knoten 332-2 befindet. In diesem Bei
spiel befindet sich das Dateisystem 148 auf dem Knoten 332-2.
Es ist zu bemerken, daß Fig. 5 zwei Kopien des Knotens 332-2
zeigt, um die angewandten Nachrichten und Operationen klarzu
stellen. Die Anwendung 212 gibt die Öffnen-Anforderung an den
lokalen Kern 242 am logischen Namen der Einrichtung. Der Kern
242 fragt dann (queries) das Dateisystem 148 ab, um sich eine
Handhabungsmöglichkeit für die angeforderte Datei 324 zu
beschaffen. Weil das Dateisystem 148 auf einem anderen Knoten
ist als der Kern 242, ist dies ein Vielschrittprozess, der die
Verwendung des PXFS 224 umfaßt.
Ein Objekt, wie beispielsweise der Kern 242 (auf dem Knoten
332-1), das auf das Dateisystem 148 zugreifen muß, gibt zu
nächst die Zugriffsanforderung an seinen lokalen PXFS-Klienten
136 ab. Der PXFS-Klient 136 hält einen Bezug (reference) zu dem
PXFS-Server 134, der mit dem Dateisystem 148 zusammen angeord
net ist (is co-located). Diese Bezugnahme bzw. Referenz ermög
licht es dem PXFS-Klienten 136, die Anforderung des Kerns an
das Dateisystem 148 über den PXFS-Server 134 weiterzugeben.
Das Dateisystem 148 führt den angeforderten Zugriff aus, er
zeugt ein die angeforderte Datei repräsentierendes vnode-Objekt
300-1 und gibt eine Bezugnahme (Referenz) auf das vnode-Objekt
300-1 an den PXFS-Server 134 zurück. Weil die Knoten 332-1 und
332-2 unterschiedliche Adressplätze sind, ist die Bezugnahme
auf den vnode 300-1 für den PXFS-Klienten 136 und den Kern 242
im Knoten 332-1 nutzlos. Folglich erzeugt der PXFS-Server 134
eine mit dem vnode 252 verbundene Dateiimplementierung (file
implementation) (f_obj) 340 und gibt eine Referenz bzw. Bezug
nahme 342 auf das f_obj 340 an den PXFS-Klienten 136 zurück.
Bei Empfang der f_obj-Referenz 342 erzeugt der PXFS-Klient 136
ein proxy vnode (px_vnode) 344, das mit dem f_obj 340 über ein
(nicht gezeigtes) f_obj_ref verbunden ist, welches eine klien
tenseitige Repräsentation von f_obj ist. Der Kern 242 kann dann
auf die durch vnode 300-1 repräsentierte Dateiinformation durch
einfachen Zugriff auf den lokalen px_vnode 344 zugreifen.
Unter Nutzung dieses Mechnismus gibt der Kern 242 eine Nach
schlage- bzw. Aufsuchnachricht (lookup message) (5-2) an den
logischen Namen der zu öffnenden Einrichtung zum PXFS-Klienten
136, der eine ähnliche Nachschlagenachricht (5-3) an den PXFS-
Server 134 weitergibt. Der PXFS-Server 134 gibt an das Dateisy
stem 148 eine get_vnode-Nachricht (5-4) weiter, die das Datei
system 148 auffordert, den logical_name auf den entsprechenden
physical_name abzubilden und eine Referenz an v_node 300-1 zu
rückzugeben, die die durch diesen physical_name identifizierten
UFS-Datei repräsentiert. Wie oben beschrieben, gibt das Datei
system 148 dann das vnode an den PXFS-Server 134 (5-5) zurück
und der PXFS-Server 134 erzeugt ein entsprechendes f_obj 340
und gibt die f_obj-Referenz 342 an den PXFS-Klienten 136 zurück
(5-6). Der PXFS-Klient 136 erzeugt dann ein px_vnode 344 und
gibt die px_vnode-Referenz 346 an Kern 242 weiter (5-7). An
diesem Punkt gibt der Kern 242 eine Öffnen-Nachricht (open
message) (5-8) an den PXFS-Klient 135 für den px_vnode 344 ab.
Bei Empfang dieser Nachricht bestimmt der PXFS-Klient 136 aus
den Attributen bzw. Eigenschaften des px_vnode 344, wie die
Öffnungsanforderung zu befriedigen ist und öffnet die Datei.
Dies ist möglich, weil der px_vnode 344 sich auf f_obj 340-2
auf Knoten 320-3 bezieht, der der angeforderten Datei 324 über
eine vnode 300 und eine inode 300i zugeordnet ist, wie in Bezug
auf Fig. 4 beschrieben. Insbesondere gibt der Kern 242 eine
open(f_obj_ref)-Anforderung (5-9) an den PXFS-Server 134-3 ab,
wobei f_obj_ref eine Objekt-Referenz auf f_obj ist, das der
Datei 242 zugeordnet ist. Nach (nicht gezeigten) zusätzlichen
Schritten, die sowohl eine lokale Kopie von UFS 220-3, als
auch von PXFS-Server 134-3 betrifft, gibt der PXFS-Server 134-3
(5-10) den Dateibeschreiber der Datei 242 zurück, falls die
Öffnung erfolgreich war. Ein ähnlicher Prozess wird für alle
Dateioperationen, wie beispielsweise Schreibvorgänge, Löschvor
gänge und Anhängvorgänge (appends) durchgeführt, die, im Gegen
satz zu einer Öffnungsoperation, den Zustand des Dateisystems
beeinflussen.
Nachdem einige Grundaspekte des PXFS-Dateisystems beschrieben
wurden, wird nun das geographische Replikationssystem Telescope
160 im Detail beschrieben, das in einer bevorzugten Ausführung
als Erweiterung zu PXFS implementiert ist.
Wieder mit Bezug auf Fig. 2 ist der Telescope-Dienst 160 über
viele Komponenten des Clusters verteilt. Zum Beispiel greift
der Telescope-Dienst 160 in Dateisystem-Aktualisierungen (file
system updates) ein bzw. fängt diese ab, zeichnet ein Protokoll
(log) auf, verbraucht Netzwerkressourcen und exportiert Managa
ment-Schnittstellen, und dies alles an unterschiedlichen Orten.
Dieser Abschnitt konzentriert sich auf zwei besondere Ortsas
pekte (location issues): wo Dateisystemaktualisierungen abge
fangen (intercepted) werden und wo Implementationsobjekte vom
Telescope lokalisiert sind.
Bei einer bevorzugten Ausführungsform werden die Dateisystemak
tualisierungen und Aufforderungen (2.1) in dem PXFS-Server 134
abgefangen. Dieser Ansatz hat verschiedene Vorteile:
- 1. Zustandsänderungen werden als Operationen mit ziemlich
hohem Niveau (fairly high-level operations) erfaßt.
Das heißt, daß Telescope 160 Änderungen an Dateien oder Verzeichnissen, und nicht an Plattensektoren oder Daten trägern aufzeichnet. Die Arbeit mit Hochniveau-Operationen vergrößert im Vergleich zu Niedrigniveau-Ansätzen die Flexibilität. Beispielsweise ist der entfernte Standort nicht auf die gleiche Plattengeometrie wie der primäre Standort beschränkt. Die Replikation kann auf einer Pro- Verzeichnis oder Pro-Datei-Basis geschaltet bzw. gehand habt werden (can be toggled on a per-directory or per-file basis). Auch kann das Datenübertragungsformat optimiert werden. Anstatt ganze Blocks von Daten zu senden, können Operationen so kodiert werden, daß die Netzwerkbandbreite gedehnt wird. - 2. Der PXFS-Server 134 ist unterhalb des Cache 160.
Mit Bezug auf Fig. 2 ist das Cachespeichern (caching) in PXFS auf der Klientenseite 124 implementiert, mit dem lokalen Ser ver 122 als Bereitsteller der Daten. Wenn Aktualisierungen (updates) den Punkt erreichen, an dem sie der PXFS-Server 134 an das darunterliegende Dateisystem 148 abgibt, sind sie fertig (are bound) für einen stabilen Speicher 126. Das Fangen (trapping) von Aktualisierungen im PXFS-Server 134 ermöglicht es Telescope 160 sicherzustellen, daß keine Cache-Effekte die Konsistenz zwischen lokaler und entfern ter Position verhindern. - 3. Der PXFS-Server 134 ist mit Mechanismen (HA-PXFS genannt)
für eine hohe Verfügbarkeit ausgerüstet (instrumented).
Im Hochverfügbarkeitsmodus werden Vorgänge bzw. Operationen von einer primären Servermaschine zu einer sekundären Ser vermaschine durch Checkpointing übertragen bzw. gecheck pointet (checkpointed). Bei einer alternativen Ausführung, die mit Bezug auf Fig. 10 beschrieben wird, ist in Teles cope 160 dieses Checkpointing-Schema (checkpointing scheme) hoher Verfügbarkeit integriert, was es der geogra phischen Replikation ermöglicht fortzubestehen, sogar wenn ein Server 122 betriebsunfähig ist. - 4. Die Implementierung bzw. Durchführung von Telescope 160 im
PXFS-Server 134 ermöglicht einen ausschließlich software
mäßigen Ansatz (software-only approach).
Es sind keine speziellen Speichereinrichtungen erforderlich und es kön nen gattungsgemäße Vernetzungs-Hilfsprogramme (networking utilities) zur Übermittlung von Daten zwischen Standorten genutzt werden.
Bei gegebenem Einbau bzw. gegebener Inkorporation eines Teles
cope-Dienstes 160 in den PXFS-Server 134 gibt es immer noch
verschiedene unterschiedliche Weisen, in denen das Telescope
160 konfiguriert werden kann, um den geographischen Replika
tionsdienst durchzuführen bzw. zu implementieren. Insbesondere
gibt es verschiedene unterschiedliche Weisen, in denen der
Telescope-Dienst 160 auf Cluster bzw. Ansammlungen, Knoten,
Dateisystemen, Verzeichnisse oder Dateien abbildet. Einige we
nige dieser alternativen Arrangements werden nun beschrieben.
Es ist zu bemerken, daß ein Clustersystem nicht besonders in
Fig. 2 erläutert ist. Es sollte jedoch angenommen werden, daß
der lokale Server 122 einen oder viele Clusterknoten repräsen
tiert und die PXFS-Server-Software 134 eine oder mehrere PXFS-
Serverinstanzen repräsentiert, die auf den jeweiligen Cluster
knoten laufen können.
- 1. Ein Telescope-Dienst pro Cluster:
In diesem Fall repli zieren die verschiedenen PXFS-Serverinstanzen 134 über ein Cluster durch eine zentrale Telescope-Instanz 160. Dieser Ansatz bzw. diese Herangehensweise (approach) vereinfacht die Verwaltung, hat aber Nachteile für die hohe Verfügbar keit (einzelner Versagenspunkt) und die Effektivität (alle replizierten Daten müssen möglicherweise mehrmals durch den ORB bewegt werden). Bemerkung: ein ORB, oder Objekt Resource Broker, ist ein verteilter Mechanismus zur Hand habung von Prozedur-Fernaufrufen, die durch Anwender (bei spielsweise einen Klienten), erzeugt werden, die die Aus führung von Verfahren anfordern, denen Objekte auf unter schiedlichen Computern (z. B. einem Server) zugeordnet sind. - 2. Ein Telescope-Dienst pro Knoten:
In diesem Fall replizie ren die verschiedenen PXFS-Serverinstanzen 134 auf dem Knoten durch eine einzelne Telescope-Instanz 160. Diese Herangehensweise ist immer noch relativ einfach für die Verwaltung und sie vermeidet die Möglichkeit von exzessi vem Datentransfer zwischen Maschinen durch den ORB. - 3. Ein Telescope-Dienst pro PXFS-Serverinstanz:
In diesem Fall kann es viele Telescope-Instanzen 160 an jedem Knoten geben. Jede Telscope-Instanz 160 ist einem PXFS-Klienten- Dateisystemobjekt 134 zugeordnet, das an ein darunter lie gendes Dateisystem (beispielsweise das UFS 148) gebunden ist. Diese Herangehensweise macht die Verwaltung schwie rig, weil die Replikationsinstanzen potentiell zahlreich und weit verteilt sind. Darüber hinaus sollte in einem transparenten globalen Dateisystem, wie beispielsweise PXFS 224 (Fig. 3) der tatsächliche Ort von Dateien für Anwendungen unsichtbar sein. Jedoch paßt diese Konfigura tion gut zu HA-PXFS und ermöglicht, daß Replikation und Protokollvorgänge durch Checkpointing an einen sekundären Server gegeben werden (checkpointed to a secondary ser ver). - 4. Ein Telescope-Dienst pro PXFS-Dateisystem:
Weil das glo bale Dateisystem in Galileo-Clustern immer mehr um sich greift, ist die Bereitstellung von einem Telescope-Dienst 160 pro PXFS-Dateisystem 224 äquivalent mit der Bereit stellung eines Telescope-Dienstes 160 pro Cluster. Dies ist die Konfiguration, die in Fig. 2 besonders erläutert ist. Diese Konfiguration ist aus Verwaltungsgründen bevor zugt, weil durch Zuordnung von Telescope 160 zu einem Dateisystem 148 alle Telescope-Instanzen 160 durch Itera tion durch Dateisysteme lokalisiert werden können. Diese Konfiguration ist auch aus Managementgründen bevorzugt, weil sie typischerweise nur ein einziges PXFS-Dateisystem 224 verwendet. Diese Konfiguration schafft auch technische Vorteile. Beispielsweise können Operationen am Dateisystem 148 in der Reihenfolge oder Ordnung serialisiert oder in Reihe geordnet werden, in der sie den Telescope-Dienst 160 zugeführt werden.
Wie oben erwähnt, bietet eine bevorzugte Ausführung drei unter
schiedliche Systemmodi 232: 1-safe, 2-safe und very_safe. Jedes
Paar von Servern in geographischer Replikationbeziehung (bei
spielsweise die Server 122, 140) können so konfiguriert sein,
daß sie einen unterschiedlichen Grad von Kohärenz in Abhängig
keit vom Systemmodus 232 haben, der für dieses Paar ausgewählt
wird. (Für mehr Information zu Kohärenz-Modi siehe Gray und
Reuter). Die verschiedenen Modi 232 werden nun beschrieben.
Der 1-safe-Modus optimiert die Leistung am lokalen Standort.
Wieder mit Bezug auf Fig. 2 und 3 werden in diesen Modus durch
den Telescope-Dienst 160 abgefangene Vorgänge auf das lokale
Dateisystem 148 angewendet und im stabilen Speicher 126 (oder
128) protokolliert. Der I/O-Aufruf (d. h. die Dateioperation) am
lokalen Standort wird dann für vollständig erklärt, was ermög
licht, daß der Durchsatz und die Latenz ziemlich nahe bei denen
eines nicht-replizierten Dateisystems liegen. Periodisch werden
die protokollierten Operationen gestapelt (batched) und an den
entfernten Standort übertragen, wo sie auf die Fernkopie des
Dateisystems 152 angewendet werden. Obwohl der entfernte Stand
ort hinter dem lokalen Standort hinterherhinken kann, ist das
Protokoll 264 an den lokalen Standort so konstruiert, daß er
immer den Unterschied zwischen den beiden festhält. Daher
können, wenn der lokale Standort zusammenbricht und die noch
nicht übermittelten Transaktionen verloren sind, diese wieder
hergestellt werden, sobald das Protokoll 162 des lokalen Stand
ortes zugänglich gemacht ist. Damit der 1-safe-Modus effektiv
ist, müssen die Operationen bzw. Vorgänge in dem Protokoll
gemäß den oben in der Zusammenfassung spezifizierten Anforde
rungen aufgezeichnet werden. Das Protokoll 264 wird unten
genauer beschrieben.
Der 2-safe-Modus verbessert die Konsistenz zwischen lokalem und
entferntem Standort, opfert aber Leistung. Durch Telescope 160
abgefangene Operationen werden zuerst auf das lokale Dateisy
stem 148 angewendet und dann sofort zum entfernten Standort
übertragen. Die I/O-Operation am lokalen Standort kann nicht
erfolgreich zurückkehren, bis vom entfernten Standort eine
Quittung (acknowledgment) empfangen wurde. Mit Bezug auf die
Anwendungen 212 werden die I/O-Operationen am lokalen und am
entfernten Standort synchron ausgeführt; jedoch verschlechtert
die durch die Übertragung der Daten an den entfernten Standort
herbeigeführte Latenz die Leistung signifikant.
Der 2-safe-Modus nutzt das gleiche Verfahren von Kodierungsope
rationen wie der 1-safe-Modus. Kodierte Operationen werden ge
nau wie im 1-safe-Modus in einem stabilen Protokoll 264 aufge
zeichnet. Daher kann, falls der lokale Standort zusammenbrechen
sollte, bevor die synchrone Übertragung auftreten kann, die
eine verlorene Transaktion wieder hergestellt werden. Sobald
eine Quittung vom entfernten Standort empfangen ist, kann die
protokollierte Operation verworfen werden.
Es ist zu bemerken, daß sogar, obwohl der Telescope-Dienst 160
im 2-safe-Modus Operationen synchron ausführt, es möglich ist,
daß der lokale und der entfernte Standort unterschiedliche Zu
stände haben. Wenn beispielsweise der lokale Standort versagt,
nachdem eine Operation lokal angewandt wurde, aber vor Übertra
gung der RDF-Nachricht (2.2), dann wird der entfernte Standort
die Operation nicht empfangen. Obwohl die Transaktion in einem
Protokoll am lokalen Standort gespeichert ist, ist das Dateisy
stem nicht synchronisiert. Der very safe-Modus vermeidet dieses
Problem, indem ein zweiphasiges Übergabe- bzw. Übertragungspro
tokoll (commit protocol) verwendet wird.
Gemäß dem zweiphasigen Übertragungsprotokoll wird eine von
Telescope 160 abgefangene Operation nicht sofort auf den loka
len Standort angewandt. Statt dessen wird sie, genau wie im 1-
safe-Modus, protokolliert und zum entfernten Standort übertra
gen. Der entfernte Standort dekodiert die Operation, protokol
liert sie und sendet eine "fertig zur Übertragung"-Nachricht
("ready to commit" message) zurück. Beim Empfang der "ready to
commit"-Nachricht antwortet der lokale Standort mit einer
"übertrage"-Nachricht ("commit" message) und fährt damit fort,
die Operation auf sein lokales Dateisystem 148 anzuwenden.
Das zweiphasige Übertragungsprotokoll garantiert, daß die zwei
Dateisysteme 148, 154 synchron bleiben. Weil die Extranachrich
ten die Latenz über diejenige des 2-safe-Modus vergrößern, ist
es nicht wahrscheinlich, daß der very safe-Modus für die mei
sten Anwendungen praktikabel ist. Tatsächlich bemerken Gray und
Reuter, daß nur wenige Systeme den very safe-Modus anbieten
und sie kennen keine Kunden, die ihn n 74792 00070 552 001000280000000200012000285917468100040 0002019924900 00004 74673utzen (für mehr Informa
tion siehe Gray und Reuter).
Die Namensgebung (naming) ist ein wichtiger Punkt bei jedem auf
ein Dateisystem bezogenen Projekt. Das Namensgebungs-Schema des
Telescope-Dienstes 160 hat die folgenden Beschränkungen:
- 1. Ein Bezeichner bzw. Kennzeichen (identifier) kann sich auf eine Datei am lokalen Standort und am entfernten Standort beziehen.
- 2. Das Kennzeichen ist klein und verbraucht minimalen Protokollplatz und minimale Netzwerk-Bandbreite.
- 3. Das Kennzeichen einer Datei übersetzt sich effektiv in und von seinem Pfadnamen und PXFS-Dateiobjekt.
- 4. Das Kennzeichen einer Datei sollte über ein Wiederan fahren hinaus aufrechterhalten bleiben.
Ein bevorzugtes Namensgebungsschema, das alle der obigen Erfor
dernisse bzw. Bedingungen erfüllt, wird nun beschrieben. Jedoch
sollte diese Beschreibung nicht als Beschränkung des Umfangs
der vorliegenden Erfindung interpretiert werden, die alle mög
lichen Namensgebungssysteme umfaßt, die in ähnlichen Kontexten
verwendet werden.
Es existiert schon eine Anzahl von Techniken zur Identifizie
rung bzw. Kennzeichnung von Dateien. Unix-Dateikennzeichen
befriedigen das zweite und dritte Erfordernis, sind aber pro
zess- und maschinenabhängig. Datei-Pfadnamen erfüllen die
erste Forderung in replizierten Dateisystemen, aber lange
Zeichenfolgen (character strings) verbrauchen Platz und der
Pfadname ist nicht immer zugänglich (obwohl Hilfsprogramme zur
Abbildung von Pfadnamen auf vnodes existieren, ist die Abbil
dung von einem vnode auf einen Pfadnamen alles andere als
trivial).
Ein bevorzugtes Telescope-Namensgebungsschema verwendet den
fobjid_t-Typ, der vom fid_t-Typ des darunterliegenden vnodes
abgeleitet ist. Ein fobjid_t ist ein eindeutiges und beständi
ges (persistent) Kennzeichen für eine Datei. Dateien können auf
fobjid_t's abgebildet werden und fobjid_t's können zurück zu
Dateien abgebildet werden. Weil fobjid_t's von einem inode
einer Datei auf der Platte abgeleitet werden, wird das fobjid_t
auch nach einem Wiederanfahren das Gleiche bleiben. Die
fobjid_t- und fid_t-Typen dienen dem gleichen Zweck wie die
gleichnamigen Elemente von Fig. 5.
Jedoch sind fobjid_t's nur auf einer einzelnen Maschine eindeu
tig; daher hält die vorliegende Erfindung eine Abbildungstafel
aufrecht, die lokale fobjid_t's auf entfernte fobjid_t's abbil
det (Bemerkung: die Abbildungstafel kann tatsächlich lokale
fobjid_t's auf entfernte Pfadnamen, entfernte fobjid_t's, Zei
ger oder fobj's am entfernten Standort abbilden oder sogar auf
Zeiger zu darunterliegenden vnodes am entfernten Standort was
immer am effektivsten ist). Bei einer bevorzugten Ausführung
ist die Abbildungstafel am entfernten Standort gespeichert, was
bedeutet, daß Einträge im Protokoll 264 Dateien anhand ihrer
fobjid_t's am lokalen Standort identifizieren. Der Grund für
die Aufrechterhaltung bzw. Pflege der Abbildungstafel am ent
fernten Standort ist ein zweifacher:
- 1. Es senkt I/O-Latenz am primären Standort durch Wegnahme der fobjid_t-Übersetzung vom kritischen Pfad.
- 2. Es ermöglicht eine größere Asynchronität. Das heißt, falls Einträge im Protokoll 264 sich auf Dateien durch fobjid_t's am entfernten Standort bezogen, dann wäre für jede neue Datei, auf die am primären Standort zugegriffen wird, ein synchroner Ruf bzw. Aufruf zum entfernten Standort erforderlich, um die geeignete fobjid_t zur Identifizierung der Datei zu bestimmen.
Zwei unterschiedliche Abbildungsschemata von Dateien auf
fobjid_t's werden nun mit Bezug auf Fig. 6 und 7 beschrieben.
Jede dieser Figuren zeigt, wie die Abbildung für einen Schreib
vorgang durchgeführt wird, was Vorgänge typifiziert, die den
Dateisystemzustand modifizieren und die daher durch den Teles
cope-Dienst 160 gecheckpointet und repliziert werden. Beide
Ausführungen umfassen einen lokalen Standort mit Anwendungen
212, Telescope-Dienst 160L, Dateien 260L, die durch fobjid_t's
402 von einem oder mehreren Typen identifiziert werden, und
eine Protokolldatei 264. Beide Ausführungen umfassen auch einen
entfernten Standort mit einem Telescope-Empfänger 160R, Dateien
260R, die durch fernseitige und lokalseitige Kennzeichen (iden
tifiers) 404, 402 identifiziert werden (beispielsweise fobjid_t
bzw. f_obj) und eine Abbildungstafel 408, die die Abbildung
zwischen den Kennzeichen 404 und 402 des entfernten und des
lokalen Standortes definiert.
Mit Bezug auf Fig. 6 sind dort die Schritte eines Dateischrei
bevorgangs und eines geographischen Daten-Replikationsvorganges
für ein erstes bevorzugtes Abbildungssystem erläutert. Der Re
plikationsprozess (d. h. Telescope 160L) wird aufgelöst, wenn
eine Datei 260L in den Dateispeicher 126 des lokalen Standortes
geschrieben wird (6.1). Telescope 160L erhält dann durch Ver
wendung des getfobjid-Befehls (6.2) die fobjid_t 402 der Datei
(6.2) und überträgt durch Checkpointing Information über den
Schreibvorgang (beispielsweise die fobjid_t) zum Protokoll 264
(6.3). Telescope 160L repliziert dann Dateizustandsinformation
(beispielsweise den Inhalt von Datei 260L und protokollierte
Schreibinformation, wie beispielsweise das fobjid_t) entspre
chend dem ausgewählten Telescope-Modus 232 (6.4) zum entfernten
Standort.
Am entfernten Standort schreibt der Telescope-Empfänger 160R
die replizierten Dateidaten als eine entfernte Datei bzw. Fern
datei 260R in den Dateispeicher 142 des entfernten Standortes
(6.6) und übersetzt das fobjid_t 402 unter Verwendung der Ab
bildungstafel bzw. Abbildungstabelle 408 (6.5) in ein Datei
objekt 404 des entfernten Standortes (z. B. f obj). Die in Fig.
6 demonstrierte Übersetzung kann nur durchgeführt werden, wenn
die Abbildungstafel 408 richtig aufrechterhalten bzw. gepflegt
wird. Insbesondere gibt es zwei bevorzugte Ansätze zum Aufbau
und zur Pflege bzw. Aufrechterhaltung der Namensabbildungsta
belle 408:
- 1. Jedesmal, wenn am lokalen Standort auf eine Datei 260L zum ersten Male zugegriffen wird, trägt Teles cope einen pathname-to-fobjid_t-Abbildungseintrag 402 in das Protokoll 264 ein. Wenn Telescope 160R am ent fernten Standort den Abbildungseintrag empfängt, trägt es ihn in seine primäre fobjid_t-to-remote file-Abbildungstabelle 408 ein.
- 2. Als Teil der Initialisierung von Telescope 160 wird ein pathname-to-fobjid_t-Abbildungseintrag 402 für jede existierende Datei und jedes zu replizierende Verzeichnis in das Protokoll 264 eingetragen. Danach werden Abbildungseinträge nur protokolliert, wenn eine neue Datei 260L erzeugt oder ihr Name geändert wird. In diesen Fällen ist es für Telescope 260L ausreichend, den Dateinamen, das fobjid_t des Ver zeichnisses und das fobjid_t der Datei zu protokol lieren.
Mit Bezug auf Fig. 7 wendet das zweite Abbildungsschema zusätz
lich zu den Elementen, die es mit der Ausführungsform von
Fig. 6 gemeinsam hat, lokale und replizierte Verzeichnisse 410,
412 am lokalen und am entfernten Standort an. Bei einem anderen
Unterschied zu Fig. 6 umfaßt die für eine Datei 260L protokol
lierte Information ihren Namen ("name"), ein namefobjid 402n
und ein dirfobjid 402d. Die namefobjid- und dirfobjid-Elemente
402n, 402d sind eindeutige und beständige Kennzeichen für den
"Namen" der Datei und des Verzeichnisses, in dem sich die Datei
befindet.
Dieses Schema erfordert mehr Arbeit zum Zeitpunkt der Initiali
sierung, aber es berücksichtigt eine Anzahl von Problemen, die
beim ersten Schema existieren. Beispielsweise kann die Verfol
gung der ersten Zeit, zu der auf eine Datei zugegriffen wird,
wie im ersten Schema, schwierig sein, insbesondere wenn während
des Betriebes ein entfernter Standort der Topologie zugefügt
wird. Auch ist der Zugriff auf den kompletten Dateinamen vom
PXFS-Server 134 nicht leicht von Dateioperationen aus, die den
Namen der Datei nicht manipulieren (beispielsweise die Lese-
und Schreib-Systemaufrufe). Der einzige Nachteil der zweiten
Herangehensweise ist der bei der Initialisierung gezahlte Preis
und die Initialisierung wird komplex und zeitaufwendig sein,
egal, ob Namensgebung involviert ist oder nicht.
Bei der Ausführung von Fig. 7 wird, wenn eine Datei am primären
Standort erzeugt wird, ihr entsprechendes fobjid_t 402n (das in
Fig. 2 in Fig. 7 als namefobjid gezeigt ist) zusammen mit sei
nem "Namen" und seinem Stammverzeichnis-fobjid_t 402d (in Fig.
7 als dirfobjid gezeigt) protokolliert. Am entfernten Standort
wird die Verzeichnis-fobjid_t 402d durch die Abbildungstabelle
auf das replizierte Verzeichnis 412 abgebildet. Eine Kopie 260R
der neuen Datei wird in diesem Verzeichnis erzeugt und dann
wird die zurückgegebene Referenz 404n zusammen mit dem fobjid_t
402n von dem lokalen Standort in die Abbildungstabelle einge
tragen. Wenn dieses Schema gegeben ist, werden jedesmal, wenn
Dateioperationen am lokalen Standort nicht möglich sind, Datei
anforderungen von den lokalen Klienten über das WAN zum ent
fernten Telescope-Empfänger 160R umgeleitet (routed). Die An
forderungen identifizieren Dateien durch ihre dirobjids und
nameobjids des lokalen Standortes, die der Telescope-Empfänger
160R unter Verwendung der Abbildungstabelle auf die entspre
chenden namefobjs und dirfobjs der replizierten Verzeichnisse
412 bzw. Dateien 260R abbildet.
Im normalen Betrieb werden Änderungen an einem primären Datei
system aufgezeichnet und an das entfernte System übertragen.
Dieses Verfahren zur Übertragung von Änderungen ist beträcht
lich effizienter als eine periodische Übertragung des gesamten
Dateisystems; jedoch arbeitet es nur, wenn die beiden Standorte
bei identischen Zuständen beginnen.
Synchronisation ist ein Prozess, der das Dateisystem des ent
fernten Standortes in den gleichen Zustand bringt wie das
Dateisystem des primären Standortes. Eine Synchronisation muß
durchgeführt werden, wann immer das primäre und das entfernte
Dateisystem nicht auf den gleichen Zustand zulaufen. Eine
Synchronisation ist bei den folgenden Szenarios erforderlich:
- 1. Wenn die Telescope-Replikation bei einem neuen Dateisystem beginnt, muß das Fernreplikat mit dem zu replizierenden Dateisystem snchronisiert werden.
- 2. Nachdem ein primärer und ein entfernter Standort für einen Zeitintervall den Kontakt verloren haben, muß der entfernte Standort mit dem primären Standort resynchronisiert werden.
- 3. Wenn ein Failover zu einem entfernten Standort auf tritt und der primäre Standort später wieder herge stellt wird, muß der ursprüngliche Primäre mit den Änderungen synchronisiert werden, die am nach dem Failover Primären aufgetreten sind (that have occur red at the post-failover primary).
Konzeptuell beinhaltet die einfachste Methode zur Synchronisa
tion eine komplette Kopie des primären Dateisystems zum ent
fernten Dateisystem. In der Praxis jedoch ist die Gewaltmethode
(brute force method) nicht immer notwendig. Beispielsweise
werden bei dem in Bezug auf Fig. 7 beschriebenen Replikations
prozess, wenn Telescope 160 im 1-safe-Modus funktioniert und
das Protokoll 264 ausreichend Kapazität hat, alle Änderungen,
die zur Resynchronisation des entfernten Standortes angewendet
werden müssen, bequem aufgezeichnet. Resynchronisation ist so
einfach wie die Übertragung und die Anwendung des Protokolls
264, was für die CPU und die Netzwerkressourcen deutlich weniger
belastend (draining) ist als eine komplette Dateisystemkopie.
Gleichermaßen wird es in dem dritten Szenario, wenn der nach
dem Failover primäre Standort (post-failure primary site) nach
dem Versagen alle Änderungen, die angewandt wurden, solange der
ursprüngliche Ort off-line war, aufzeichnen kann, immer eine
Aufzeichnung des Unterschiedes zwischen den beiden Standorten
geben. Dieses Szenario ist komplexer als das vorherige, weil
eine oder mehrere Transaktionen am ursprünglichen lokalen
Standort vorgenommen worden und nicht vor dem Failover zum
Nach-Failover (entfernten) Standort übertragen worden sein
können. Protokollerfordernisse diktieren, daß diese Transaktio
nen im Protokoll des lokalen Standortes (wenn dieses wiederher
gestellt werden kann) verfügbar sind. In diesem Fall kann es
erforderlich sein, daß ein Verwalter einschreiten und auswählen
muß, welche Transaktionen im neuen, synchronisierten Zustand
existieren.
Unglücklicherweise gibt es Fälle, bei denen eine komplette
Kopie der einzige Weg zur Sicherstellung einer Synchronisation
ist. Das erste beschriebene Szenario, bei dem ein Dateisystem
erst durch Telescope 160 repliziert wird, ist ein Beispiel. Das
Kopieren eines gesamten Dateisystems über ein ausgedehntes
Netzwerk kann ein zeitaufwendiger Prozess sein. Um die von der
Synchronisation geforderte Konsistenz zu garantieren, sollten
am Dateisystem des lokalen Standortes keine Modifikationen
auftreten, während es zum entfernten Standort kopiert wird.
Dies jedoch steht in Konflikt mit dem Ziel minimaler Ausfall
zeiten (downtime) am lokalen Standort während einer Synchroni
sation.
Es kann eine Anzahl von Techniken von anderen Technologien
ausgeborgt werden, um zu vermeiden, den lokalen Standort wäh
rend der Synchronisation off-line zu nehmen. Beispielsweise
erfordern Online-Sicherungsprozeduren auch eine konsistente
Kopie eines Dateisystems 148, während die Ausfallzeit mini
miert wird. Eine Telescope 160-Synchronisation von einer lokal
gespiegelten Platte erfordert gesonderte Hardware; das Spei
chersystem muß von Anfang an gespiegelte bzw. spiegelgleiche
Platten benutzen. Alle anstehenden Schreibvorgänge auf die
gespiegelte Platte müssen vor Beginn der Synchronisation ge
räumt (flushed) werden und während der Synchronisation können
keine Schreibvorgänge auf die gespiegelte Platte stattfinden.
Die zweite Technik, Dateisystem-Schnappschüsse, erfordert auch
zusätzliche Hardware, aber die kann so einfach sein wie Extra
platz auf der gleichen Platte. Vor Beginn der Telescope 160R-
Synchronisation wird ein Schnappschuß (snapshot) des Dateisy
stems 148 erzeugt. Der Schnappschuß besteht ursprünglich aus
einem leeren Haltebereich. Während der Synchronisation werden
Schreibvorgänge durch andere Anwendungen auf das Dateisystem
angewandt, aber beim ersten Zugriff auf jeden beeinflußten
Block wird der Block in den Schnappschuß-Haltebereich kopiert.
Daher wird für jeden zu kopierenden Block Telescope 160 erst in
dem Schnappschuß-Haltebereich nachsehen. Falls der Block nicht
vorhanden ist, ist er nicht modifiziert worden, und Telescope
160 kann ihn vom lokalen Dateisystem 148 kopieren.
Von den zwei Online-Sicherungsstrategien ist die Schnappschuß-
Methode am besten für Telescope geeignet. Sie ist ein Soft
ware-Ansatz mit minimalem Overhead und niedriger Komplexität
bei der Durchführung (implementation complexity). Das Schnapp
schußverfahren wird für die Verwendung mit Telescope 160 ver
bessert. Der Unterschied zwischen der Durchführung von Siche
rungen (backups) und der Synchronisation für Telescope ist die
Handhabung der Schreibvorgänge, die während des Kopierens des
Dateisystems erfolgen. In einem Sicherungsprozess können diese
Schreibvorgänge ignoriert werden. Vom Backup wird angenommen,
daß es das Dateisystem repräsentiert, bevor irgendeiner dieser
Schreibvorgänge auftrat. Mit Telescope 160 jedoch müssen der
lokale und der entfernte Standort vollständig synchronisiert
sein, wenn die Replikation beginnt. Daher müssen die Schreib
vorgänge, die während der großen Dateisystemkopie auftreten,
auch an den entfernten Standort gebracht (conveyed) werden. Die
beste Methode zur Durchführung dieser Schreibvorgänge ist die
Addition eines Protokollierungsschrittes (log step) zum
Schnappschuß-Verfahren. Wenn ein Block während der Zeitdauer
einer Synchronisation geschrieben wird, wird der ursprüngliche
Block in den Haltebereich geschrieben und der Schreibvorgang
wird protokolliert. Nachdem die Synchronisation abgeschlossen
ist, kann das Protokoll auf den entfernten Standort angewendet
werden. Die Prokollierung (logging) wird weiter unten disku
tiert.
Andere Technologien können auch Lösungen für das Online-Syn
chronisationsproblem anbieten. Die meisten RAID-Produkte können
Platten ohne Unterbrechung des normalen Betriebes synchronisie
ren. In diesen Produkten verwendete Untersuchungsalgorithmen
können auch zusätzliche Lösungen bereitstellen.
Der Schlüssel zur Erfassung von Datenaktualisierungen liegt in
der Identifizierung der Arbeitsschritte bzw. Operationen des
PXFS-Servers, die zu Modifikationen des zugrundeliegenden Da
teisystems führen. Diese Operationen fallen in drei Katego
rien: Dateidatenverfahren (file data methods), Dateieigen
schaftsverfahren (file attribute methods), und Verzeichnisver
fahren (directory methods). Verfahren an Verzeichnisobjekten
befassen sich mit der Schaffung, Löschung und Kennzeichnung von
Dateien und anderen Verzeichnisobjekten. Dateidatenverfahren
schreiben Dateidaten in das zugrundeliegende Dateisystem.
Dateieigenschaftsverfahren ändern die Eigenschaften von Dateien
in dem zugrundeliegenden Dateisystem. Tabelle 1 listet die
PXFS-Operationen, die zum entfernten Standort repliziert werden
müssen, um sicherzustellen, daß der Dateizustand wieder herge
stellt werden kann, nachdem ein Failover auftritt, auf. Dieses
sind Standard-PXFS-Operationen und sie werden aus diesem Grunde
hier nicht definiert; Anhang A zeigt sie jedoch.
Wenn diese Operationen identifiziert sind, gibt es zwei Heran
gehensweisen bzw. Ansätze zur Erfassung von Zustandsänderungen
und zu ihrer Aufzeichnung im Protokoll 264, das in Telescope
160 implementiert werden kann:
- 1. Simuliere den Klientenaufruf zum PXFS-Server 134. Das heißt, zeichne das aufgerufene PXFS-Serververfahren mit ausreichenden Argumenten auf, so daß der gleiche Aufruf am entfernten Standort reproduziert werden kann.
- 2. Zeichne nur Aktualisierungen auf, die an das zugrun deliegende Dateisystem durch eine vnode-Operation gesandt wurden. Operationen des PXFS-Servers 134, die den Zustand des zugrundeliegenden Dateisystems än dern, müssen dies durch eine vnode-Operation tun. Der Aufruf dieser vnode-Operationen kann aufgezeichnet und am entfernten Standort reproduziert werden.
Der erste Ansatz stellt ein stärker hochverfügbares Failover
szenario dar. Bei dieser Herangehensweise werden PXFS-Server-
134-Methoden kodiert und an den entfernten Standort übertragen.
Der entfernte Telescope-Dienst 160R dekodiert diese Methoden
und ruft sie an der entfernten Instanz eines PXFS-Servers 156
auf. Auf diese Weise simuliert der entfernte Telescope-Dienst
160R einen PXFS-Klienten 136. Dieser ist auch der einzige PXFS-
Klient 136, der zum entfernten PXFS-Server 156 schreibt. Daher
wird, wenn ein Failover zum entfernten Standort notwendig wird,
am entfernten Standort schon eine PXFS-Serverinstanz 156 exi
stieren und sie wird bereit sein, Anforderungen vom PXFS-Klien
ten 136 anzunehmen. Weiterhin können während normalem Betrieb
zusätzliche PXFS-Klienten 136 einen Nur-Lese-Zugriff am ent
fernten Standort bereitstellen. Dies ist nützlich für CPU- und
IO-intensive Prozeduren, wie beispielsweise Online-Sicherungen
(backups), die am lokalen Standort, wenn überhaupt möglich,
vermieden werden sollten.
Der Nachteil des ersten Ansatzes ist seine Komplexität. Bei
spielsweise sind die beim zweiten Ansatz verwendeten Parameter
von vnode-Methoden weniger und leichter zu kodieren als die
Parameter von im ersten Ansatz verwendeten Methoden des PXFS-
Servers 134. Zusätzlich sind Aufrufe vom PXFS-Server 134 zum
darunterliegenden Dateisystem 148 am lokalen Standort, die im
zweiten Ansatz verwendet werden, einfach zu isolieren. Fehler
bedingungen können geprüft werden, wenn die vnode-Methoden
zurückkehren, um zu bestimmen, ob die Operation erfolgreich war
und zum entfernten Standort übertragen werden sollte. Am ent
fernten Standort werden dekodierte Operationen direkt auf das
darunterliegende Dateisystem angewandt. Auf diese Weise arbei
tet bzw. wirkt der entfernte Telescope-Dienst 160R als ein
PXFS-Server 156 anstatt als ein PXFS-Klient 136, weil er direkt
mit dem darunterliegenden Dateisystem zusammenarbeitet bzw. in
teragiert. Obwohl der Telescope-Dienst 160R in dieser Beziehung
als PXFS-Server 156 arbeitet, ist er nicht in der Lage, irgend
welche anderen PXFS-Server-Funktionalitäten, wie beispielsweise
den Empfang von Aufforderungen von PXFS-Klienten, auszuführen.
Daher muß im Falle eines Failovers ein PXFS-Server 156 aus dem
darunterliegenden Dateisystem 154 konstruiert werden.
Jedoch beeinflußt die Instantiierung (instantiating) des PXFS-
Servers 156 den Failover nicht zu schwer, weil Failover schon
ein zeitaufwendiger Prozess ist. Auf der anderen Seite braucht
der entfernte Standort, wenn vnode-Methoden anstatt PXFS-
Server-Methoden übertragen werden, kein Galileo-Cluster zu
sein. Auch ist am entfernten Standort keine PXFS-Software
erforderlich.
Wieder mit Bezug auf Fig. 3 ist das Replikationsprotokoll 264
eine der wichtigsten Komponenten des Telscope-Dienstes 160. Der
very safe-Modus, der 2-safe-Modus und der 1-safe-Modus nutzen
alle ein Protokoll, um den Verlust von Transaktionen zu verhin
dern. Das Protokoll-Eintragsformat ist auch das Format, in dem
Daten gepackt und zum entfernten Standort übertragen werden.
Dieser Abschnitt beschreibt das Design bzw. den Aufbau des
Protokolls inklusive seinem Format und wie die Protokollie
rungsoperationen in die Dateisystemoperationen integriert sind.
Diese Information ist am besten geeignet für den 1-safe-Modus,
aber überträgt sich allgemein zum 2-safe-Modus und very safe-
Modus.
Der erste Punkt beim Design des Protokolls ist sein Platz
(location). Es ist wichtig, daß sich das Protokoll auf dersel
ben physikalischen Maschine wie der PXFS-Server 134 befindet.
Dies vermeidet die Übertragung von allen Protokolleinträgen
durch ORB-Aufrufe. Falls der PXFS-Server 134 unter Verwendung
von HA-PXFS repliziert wird, sollten Einträge zum Protokoll 264
auch repliziert werden. Daher sollte das Protokoll sich auf
einer zweitorigen bzw. Zwei-Tor-Platte, wie beispielsweise
Platte 126, befinden.
Das Protokoll 264 kann als eine reguläre Datei implementiert
werden. Die Protokollgröße wird vorzugsweise bei seiner Erzeu
gung spezifiziert, was eine Vor-Zuweisung (pre-allocation) der
Protokolldatei 264 erlaubt. Wenn das Protokoll 264 in dem ge
rade replizierten Dateisystem angeordnet ist, ist es wichtig,
daß die Replikation der Protokolldatei ausgeschaltet wird. Das
Protokoll 264 kann auch als eine Roheinrichtung 128 implemen
tiert werden, etwa so wie eine Austauschpartition (swap parti
tion). Der Einfachheit halber wird der Rest dieses Dokumentes
annehmen, daß das Protokoll 264 als eine reguläre Datei imple
mentiert ist, die für den Kern 216 durch die vnode-Schnittstel
le 298 zugänglich ist. Diese Dateizugriffsmethode wird mit Be
zug auf Fig. 4 und 5 beschrieben.
Es gibt Vorteile, wenn das Protokoll 264 an einem wohlbekannten
Ort platziert wird, ob im Dateisystem oder auf eine Roheinrich
tung. Erstens würde es, falls dieser wohlbekannte Platz sich im
gerade replizierten Dateisystem befindet, es leicht sein, si
cherzustellen, daß Telescope 160 nicht versucht, das Protokoll
zu replizieren. Wichtiger jedoch ist, daß das Protokoll 264
nach einem Systemzusammenbruch wiederherstellbar sein muß. Das
bedeutet, daß sein Platz entweder in den Wiederherstellungscode
hart-kodiert sein muß (hard-coded into the retrieval code) oder
an einem Platz aufgezeichnet werden muß, der in den Wiederher
stellungscode hart-kodiert ist. Ein möglicher Ort zur Aufzeich
nung des Ortes der Protokolldatei ist der Protokollanker 230
(Fig. 3), der unten beschrieben wird. Der Protokollanker 230
ist beträchtlich kleiner als das Protokoll selbst, insbesondere
im 1-safe-Modus.
Protokolleinträge sind entweder physikalisch, logisch oder ein
Hybrid aus beiden. Ein physikalischer Eintrag zeichnet die Än
derung bei den Daten an einem bestimmten Ort auf der physika
lischen Einrichtung oder in einer Datei auf. Ein logischer Ein
trag zeichnet die Operation auf, die die Veränderung verur
sachte. Weil PXFS ein Hochniveau-Dateisystem ist, arbeitet es
meist in logischen Operationen. Das heißt, daß es Operationen
auf dem darunterliegenden Dateisystem aufruft, anstatt das
Layout von bits auf einer Platte zu spezifizieren. Aus diesem
Grund ist ein logischer Protokollierungsansatz für Telescope
160 besser geeignet.
Das Format eines Protokolleintrages 256 ist in Fig. 3 und in
Fig. 7 gezeigt. Ein Protokolleintrag 266 besteht aus einem Kopf
(header) 268 und einem Körper (body) 279. Alle Protokolleinträ
ge 266 haben Köpfe 268 mit identischer Größe und identischem
Layout, während die Körper 279 variieren können. Der Protokoll
datensatzkopf 268 muß genug Information enthalten, um es Teles
cope 160 zu ermöglichen, die folgenden Funktionen durchzufüh
ren:
- 1. Überquere (Traverse) das Protokoll vorwärts.
- 2. Überquere das Protokoll rückwärts.
- 3. Finde alle Protokolleinträge für eine gegebene Transaktion bzw. einen gegebenen Vorgang.
- 4. Bestimme die Zeit, zu der eine Transaktion begann und beendet wurde.
In Bezug auf Fig. 3 umfaßt der Kopf 268 die folgenden Felder,
die es Telescope zu ermöglichen, die notwendigen Funktionen
auszuführen:
- next_rec 270 zeigt auf den Kopf des nächsten
Protokolleintrages;
prev_rec 272 zeigt auf den Kopf des vorher gehenden Protokolleintrages;
timestamp_rec 274 der Tag und die Zeit des aktuellen Eintrages;
transaction_id 276 eine eindeutige Identifizierung (id), die dem aktuellen (Eintrag) zugeordnet ist;
transaction_length 278 die Länge des aktuellen Eintrags.
Wie aus den vorhergehenden Feldern offensichtlich ist, organi
sieren die Protokollköpfe 268 Protokolldaten in einer verbunde
nen Liste. Zeiger (pointers) zu anderen Elementen in der Liste
werden mit Protokollsequenznummern (log sequence numbers)
(LSNs) implementiert. Eine LSN wird verwendet, um einen Proto
kolldatensatzkopf durch Kodierung seines Ortes in der Proto
kolldatei zu identifizieren.
Die transaction_id 276 identifiziert die Transaktion, der der
Protokolleintrag zugeordnet ist. Sie wird durch das Protokoll
modul zugewiesen, wenn eine Operation durch den PXFS-Server 134
an das Protokoll 264 für einen Eintrag übermittelt wird. Sie
wird an den PXFS-Server 134 als Ergebnis der Übermittlungs
methode (submission method) zurückgegeben. Nach Vollendung der
Operation sendet der PXFS-Server 134 die transaction_id 276 als
ein Argument zu einer Übergabenachricht zum Protokollmodul. Bei
einer bevorzugten Ausführung werden die transaction_id's 276
als monoton steigende 64-bit-Ganzzahlen implementiert, was
sicherstellt, daß die gleiche Transaktion-id nicht zweimal ver
wendet wird. Jedoch kann auch jeder andere Typ von eindeutiger
id verwendet werden.
Während es Protokollköpfe ermöglichen, die nächste und vorher
gehende Aufzeichnung von der aktuellen aus zu lokalisieren,
zeigen sie nicht an, wo die Überquerung des Protokolls (log
traversal) beginnen sollte. Diese Information wird in einer
speziellen Datenstruktur gehalten, die Protokollanker 230 ge
nannt wird und die in Fig. 3 und Fig. 8 erläutert ist (die die
Beziehung zwischen dem Protokollanker 230 und der zugehörigen
Protokolldatei 264 zeigt). Der Protokollanker 230 speichert
die notwendigerweise verwendete Information zur Dekodierung der
Protokolldatei und zur Rekonstruktion des Protokolls im Fall
eines Systemsausfalles.
Beispielsweise wird die LSN des zuletzt geschriebenen Proto
kolleintragkopfes im Anker gespeichert. Auch umfaßt ist die LSN
des letzten Eintrages (most recent entry) der zum entfernten
Standort geräumt (flushed) wurde und des letzten Eintrages,
der am entfernten Standort quittiert wurde. Diese Einträge er
möglichen Telescope eine Rückwärtsverfolgung durch die Proto
kolleinträge zur Bestimmung, welche Transaktionen beim System
ausfall verloren wurden. Insbesondere umfaßt der log_anchor 230
die folgenden Felder:
next_rec 242 zeigt den nächsten verfüg
baren Platz für einen Proto
kolleintrag an;
prev_rec 244 zeigt den Kopf des zuletzt geschriebenen Eintrages an;
last_flushed 246 zeigt zum Kopf des zuletzt geräumten Protokolleintrages;
last_ACK 248 zeigt auf den Kopf des letzten Protokolleintrages, der durch die entfernte Telescope-Instanz 160R quittiert wurde;
circular 249 ein Boolescher Operator (boolean), der anzeigt, ob das Protokoll zirkulär ist;
timestamp_anchor 250 der Tag und die Zeit des aktuel len Eintrags.
prev_rec 244 zeigt den Kopf des zuletzt geschriebenen Eintrages an;
last_flushed 246 zeigt zum Kopf des zuletzt geräumten Protokolleintrages;
last_ACK 248 zeigt auf den Kopf des letzten Protokolleintrages, der durch die entfernte Telescope-Instanz 160R quittiert wurde;
circular 249 ein Boolescher Operator (boolean), der anzeigt, ob das Protokoll zirkulär ist;
timestamp_anchor 250 der Tag und die Zeit des aktuel len Eintrags.
In Bezug auf Fig. 9 ist dort die Beziehung zwischen dem Proto
koll 264 und dem log-anchor-Feldern unmittelbar nach einem
Räumen des Protokolls (log flush) dargestellt. In diesem Bei
spiel sind alle zum entfernten Standort geräumten bzw. abgelas
senen Daten quittiert worden, weil die last flushed- und last
ACK-Zeiger 246, 248 auf den gleichen Protokolleintrag zeigen.
Ein Räumvorgang (flush) schreibt die Daten vom last-flushed-
Zeiger 246 zum next_rec-Zeiger 242. Der Platz in der Protokoll
datei 214 nach next_rec 242 ist frei für neue Protokolleinträ
ge. Zusätzlich ist, falls Circular 249 wahr ist, der Platz in
der Protokolldatei vor last_ACK 248 auch frei zur Wiederverwen
dung. Falls die Protokolldatei nicht auf einen wohlbekannten
Ort beschränkt ist, kann der Protokollanker auch den Pfadnamen
der Protokolldatei enthalten.
Der Protokollanker ist eine Datenstruktur, auf die häufig
zurückgegriffen wird. Für jeden Protokolleintrag wird auf die
Felder next_rec 242, prev_rec 244 und timestamp 250 zugegriffen
und sie werden geändert. Für die Effizienz wird der Protokoll
anker 230 im Speicher 204 gehalten. Zum Schutz der Protokoll
daten wird der Protokollanker 230 periodisch zur Platte 136
geräumt, wo er, zum Zwecke dieser Beschreibung,
flushed_log_anchor 280 genannt wird. Daher repräsentiert
möglicherweise nach einem Systemversagen der Protokollanker,
auf den durch Telescope 160L zugegriffen wird, nicht tatsäch
lich den jüngsten (most recent) Zustand des Protokolls 264.
Statt dessen überquert Telescope 160 das Protokoll 264 in der
Vorwärtsrichtung, wobei am Eintrag gestartet wird, der durch
das prev_rec-Feld 284 des geräumten Protokollankers 280 ange
zeigt wird, bis es den wahren letzten Protokolleintrag findet.
Der letzte Protokolleintrag kann auf unterschiedliche Weisen
markiert werden. Es kann ihm unmittelbar nachfolgend ein
Pseudo- oder Dummy-Datensatzkopf geschrieben werden mit einem
timestamp-Eintrag vor dem aktuellen Anker-timestamp 290. Alter
nativ kann eine spezielle Markierung am Ende des Protokolls
geschrieben werden, die gelöscht wird, wenn ein neuer Eintrag
angehängt wird.
Der Protokollanker 230 muß zu einem wohlbekannten Ort auf der
Platte 136 geräumt werden, so daß er nach einem Systemzusam
menbruch leicht wiedergewonnen bzw. abgerufen werden kann.
Falls die Programmdatei 264 nicht an einem wohlbekannten Ort
ist, dann sollte der abgelassene Protokollanker 280 auch dessen
Pfadnamen enthalten. Es gibt eine Anzahl von Techniken zur
Sicherstellung, daß die Protokollanker 230, 280 und die Proto
kolldatei 264 immer in einem konsistenten Zustand gehalten
werden. Diese Techniken sind wichtig, weil Schreibvorgänge in
diese Dateien in Bezug auf unvorhersagbare Ereignisse, wie zum
Beispiel Leistungsversagen, nicht atomistisch (atomic) sind.
Für eine sorgfältige Diskussion von Protokolltechniken, siehe
Kapitel 9 von Gray und Reuter, daß hierin durch Bezugnahme
vollständig aufgenommen wird.
Eines der Erfodernisse von Telescope 160 ist es, daß der lokale
und der entfernte Standort dieselben Zustände erreichen, obwohl
im 1-safe-Modus der entfernte Standort hinter dem lokalen
Standort herhinken bzw. zurückbleiben kann. Ein Weg, diese Er
fordernisse anzusehen, ist, daß der Zustand am lokalen Standort
gleich der Zusammensetzung des Zustandes am entfernten Standort
mit den Operationen im Protokoll 264 ist. Ein Szenario, bei dem
dieses Erfordernis gefährdet ist, ist es, wenn ein Fehler am
lokalen Standort eine Ausfallzeit verursacht, die nicht lange
genug dauert, um einen Standort-Failover zu verursachen. In
dieser Situation sollte das Protokoll 264 nicht außer Synchro
nisation mit dem Dateisystem 148 fallen, weil das dazu führen
würde, daß der entfernte Standort außer Synchronisation mit dem
lokalen Standort fällt. Dies kann mit drei Regeln erzwungen
werden:
- 1. Am lokalen Standort muß die Reihenfolge oder Ordnung, in der Operationen im Protokoll aufgezeichnet werden, jede Sperre auf höherem Niveau (higher-level locking) oder Ordnungserfordernisse bzw. -beschränkungen res pektieren, die die Reihenfolge kontrollierten bzw. steuerten, in der sie auf das Dateisystem angewendet wurden. Das heißt, daß das Protokoll möglicherweise nicht die exakte Reihenfolge repräsentiert, in der Operationen auf das Dateisystem angewandt wurden, weil es keine zentrale Dateisystemsperre (central file system lock) gibt, die für jede Operation erfas sen bzw. gegriffen (grabbed) wird. Auf der anderen Seite wird das Protokoll 264 durch Sperren (locks) geordnet werden, die auf Dateisystemen und Verzeich nissen erlangt (acquired) wurden;
- 2. Operationen müssen auf das entfernte Dateisystem in der gleichen Reihenfolge angewandt werden, in der sie im Protokoll aufgezeichnet sind;
- 3. Am lokalen Standort wird eine Operation an das Proto koll dann und nur dann übergeben, wenn sie an das Dateisystem übergeben wird.
Die erste Regel garantiert nicht vollständig, daß Operationen
in dem Protokoll in genau der gleichen Reihenfolge aufgezeich
net werden, wie sie auf das Dateisystem angewendet werden.
Operationen auf unterschiedlichen Dateien und Verzeichnissen
können in unterschiedlichen Reihenfolgen aufgezeichnet und
angewendet werden. Operationen auf der gleichen Datei oder dem
gleichen Verzeichnis jedoch werden durch das Dateisystem oder
eine Anwendungsniveau-Sperre (application-level locking) ge
schützt. Beispielsweise wird es zwei Threads bzw. Teilprozes
sen (threads) nicht erlaubt sein, das gleiche Verzeichnis
gleichzeitig zu modifizieren, weil das Dateisystem irgendeine
Art von Sperre auferlegen wird. Ohne dieses Sperrschema könnte
das Verzeichnis durcheinander geraten. Solange die Operationen
in den Protokollen aufgezeichnet werden, während die Verzeich
nissperre aufrechterhalten wird, wird das Protokoll die gleiche
Ordnung wie das Dateisystem repräsentieren.
Die durch die erste Regel auferlegte Ordnung ist wenig Wert,
wenn sie nicht am entfernten Standort beachtet wird. Es kann
sein, daß der entfernte Standort Operationen asynchron mit
verschiedenen Threads durchführen möchte, um die Effektivität
zu verbessern, aber Regel Nummer zwei fordert, daß die Proto
kollordnung aufrechterhalten (preserved) wird. Falls nicht,
kann dies zu Inkonsistenzen zwischen dem lokalen und dem ent
fernten Standort führen.
Das Ordnen ist irrelevant, wenn in dem Protokoll Operationen
aufgezeichnet werden, die auf das Dateisystem nicht angewendet
wurden, oder umgekehrt. Wenn beispielsweise eine Operation auf
das Dateisystem angewandt würde und das System zusammenbricht,
bevor sie in das Protokoll eingetragen wird, wird das Protokoll
nicht den Unterschied zwischen dem lokalen und dem entfernten
Standort repräsentieren. Gleichermaßen sollte, wenn eine Opera
tion im Protokoll aufgezeichnet wird, sie aber aus irgendeinem
Grunde bei der Anwendung auf das Dateisystem versagt, der Pro
tokolleintrag gestrichen oder unwirksam gemacht werden.
Vorzugsweise wird ein Fertigübergabeprotokoll (ready-commit
protocol) verwendet, um Operationen im Protokoll 264 aufzu
zeichnen. Für den 1-safe-Modus würde das Fertigübergabeproto
koll etwa so ablaufen:
- 1. Erhalte die Dateisystemdatei- oder Verzeichnissperre.
- 2. Zeichne die Operation im Protokoll 264 auf.
- 3. Führe die Operation auf dem Dateisystem 148 aus.
- 4. Falls die Operation erfolgreich war, zeichne eine Übergabenachricht (commit message) in dem Protokoll 264 auf. Anderenfalls zeichne eine Invalidisierungs nachricht auf.
- 5. Gebe die Dateisystemdatei- oder Verzeichnissperre frei.
- 6. Gebe bzw. sende die Ergebnisse zurück.
Dieses Protokoll schützt gegen Fehler in irgendeinem Stadium
einer Dateisystem-Zustandsänderung. Es macht eine wichtige
Annahme: Aktualisierungen an dem Dateisystem müssen entweder
idempotent oder prüffähig (testable) sein. Idempotente Opera
tionen haben den gleichen Effekt, ob sie einmal oder mehrmals
angewendet werden. Es kann ohne eine Wiederausführung der
Operation bestimmt werden, ob eine prüffähige Operation ausge
führt worden ist. Diese Annahme wird benötigt, um mit einem
Fehler oder Ausfall umzugehen, der nach Schritt 2 und vor
Schritt 4 auftritt. Darüber hinaus ist, wie mit Bezug auf Fig.
10 beschrieben, dieses Protokoll konsistent mit HA-PXFS, das
die gleiche Annahme macht.
Wenn eine Operation in das Protokoll 264 aufgezeichnet wird und
es keine entsprechende Übergabe- oder Invalidisierungsnachricht
gibt, ist es unbekannt, ob die Operation auf das Dateisystem
148 angewendet wurde. Wenn die Operation prüffähig ist, kann
bestimmt werden, ob sie ausgeführt wurde. Wenn sie nicht prüf
fähig ist, wird die Operation einfach noch einmal ausgeführt,
anstatt zu raten, ab sie ausgeführt wurde. Eine Idempotenz
garantiert, daß dann, wenn sie schon angewandt wurde, der re
sultierende Zustand sich nicht ändert; jedoch wird bei einigen
Operationen von dem zugrundeliegenden Dateisystem ein Fehler
zurückgegeben werden. Beispielsweise wird, wenn die Operation
mkdir war und Schritt 3 schon abgeschlossen worden ist, EEXIST
durch das Dateisystem 148 zurückgegeben werden. An diesem Punkt
weiß Telescope 160 nicht, ob die ursprüngliche Operation oder
der Wiederholungsversuch versagte; folglich sollte die Opera
tion auch am entfernten Standort durchgeführt werden. Dort war,
wenn die Operation erfolgreich ist, die ursprüngliche Operation
am lokalen Standort abgeschlossen gewesen. Wenn sie versagt,
dann war die ursprüngliche Operation am lokalen nicht abge
schlossen gewesen und ein Fehler wäre zurückgegeben worden,
wenn sie es gewesen wäre. Es sollte eine Markierung im Proto
kolleintrag angeordnet werden, die anzeigt, daß eine Operation
ein Wiederholungsversuch ist und am lokalen möglicherweise
nicht erfolgreich war. Falls diese Markierung vorhanden ist,
muß der entfernte Standort keinen Alarm abgeben, falls die
Operation versagt, weil er in einem konsistenten Zustand mit
dem lokalen verblieben sein wird.
Die oben beschriebene Protokollierungsprozedur unterscheidet
sich leicht vom 2-safe-Modus. Man erinnere sich, daß im 2-
safe-Modus die Operation übertragen und am entfernten Standort
angewandt sein muß, bevor sie zum lokalen Standort zurückkehren
kann. Daher wird, anstatt daß eine Übergabenachricht in das
Protokoll in Schritt 4 oben geschrieben wird, der in Schritt 2
aufgezeichnete Eintrag an den entfernten Standort übertragen.
Schritt 5 wird blockiert, bis eine Quittung vom entfernten
Standort empfangen wurde.
Die Protokollierungsprozedur für den very-safe-Modus ist ähn
lich der für den 2-safe-Modus, außer daß sie ein zweiphasiges
Übergabeprotokoll verwendet.
Bei einer bevorzugten Ausführung werden alle Operationen in das
Protokoll 264 mit dem in Fig. 8 erläuterten, gleichen Format
kodiert. Protokolleinträge/-datensätze 266 beginnen alle mit
einem Protokolldatensatzkopf 268, der mit Bezug auf Fig. 3 be
schrieben wurde. Der Protokolldatensatzkopf 268 stellt die
timestamp 274, die transaction id 276 und die Länge 278 des
Protokolleintrages bereit. Der Körper 279 des Eintrages beginnt
mit einem Operationscode (opcode) 452, der die kodierte Opera
tion identifiziert. Das nächste ist eine Wiederholungsversuch
markierung (retry marker) 454, die anzeigt, ob die Operation
möglicherweise ein Wiederholungsversuch ist und daher, ob der
Fehler am entfernten Standort unberücksichtigt bleiben kann.
Dem Operationscode 452 und der Wiederholungsversuchmarkierung
454 folgt die Liste von Parametern. Jeder Parameter ist in
einer Struktur enthalten, die einen Typcode 456, die Länge des
Parameters 458 und die Parameterdaten 460 enthält. Mit dieser
Struktur ist es einfach, beliebige Parameter effizient zu
übertragen, solange sein Typcode 456 sowohl am lokalen, als
auch am entfernten Standort bekannt ist.
Es müssen nicht alle Parameter einer Operation übertragen
werden. Manche Parameter können am entfernten Standort simu
liert werden. Beispielsweise müssen credobjs nicht weitergege
ben werden. (Bemerkung: ein credobj ist ein Objekt, das Nutzer
referenzen bzw. -ausweise (credentials) enthält; beispielsweise
user id, group id, usw.). Das ist so, weil der entfernte Teles
cope-Dienst 160R in der Lage sein sollte, credobj's zu erzeu
gen, um auf sein lokales Dateisystem 154 zuzugreifen. Anhang A
listet die Verfahrens- bzw. Methodenprototypen von Tabelle I
zusammen mit den Parametern auf, die für jede Methode übertra
gen werden müssen. Diese Verfahrensprototypen werden in Stan
dard C++ geschrieben, wobei die Beschreibung von deren Konven
tionen außerhalb des Umfanges der vorliegenden Erfindung liegt.
Übergabe- und Invalidisierungsnachrichten werden auch in das
Protokoll 264 mit dem in Fig. 8 erläuterten Format kodiert.
Übergabe- und Invalidisierungsnachrichten bekommen jeweils
einen speziellen Operationscode bzw. opcode 452 zugewiesen. Sie
sind mit dem gerade übergebenen oder invalidisierten Protokoll
eintrag 266 durch die transaction id 276 im Protokolldatensatz
kopf 268 verknüpft. Beim aktuellen Design beteiligen Invalidi
sierungsnachrichten keine Parameter. Übergabenachrichten jedoch
umfassen vorzugsweise Namensgebungsinformation. Wie oben be
schrieben, wird der Namengebungsrahmen (naming framework) mit
den Protokollnachrichten (Fig. 2, 6, 7) aufrechterhalten und
zeigt Veränderungen im Namensraum des Dateisystems 148 an.
Jedes Mal, wenn am lokalen Standort eine Operation aufgerufen
wird, die den Namen (oder Zustand) eines Dateisystemobjektes
ändert, wird eine name-to-fobjid_t-Abbildung in das Protokoll
264 eingetragen (unter der Annahme, daß die Namensgebungs-
/Protokollierungs-Methode von Fig. 7 angewendet wird). In der
oben beschriebenen Protokollierungsprozedur werden die Details
der Operation (beispielsweise opcode und Parameter) vor deren
Abschluß aufgezeichnet. Daher ist die neue fobjid_t, die an den
entfernten Standort übertragen werden muß, am lokalen Standort
nicht bekannt, bis der ursprüngliche Protokolleintrag geschrie
ben ist. Als eine Optimierung wird, anstatt einen neuen Proto
kolleintrag zu erzeugen, die neue fobjid_t in der Übergabenach
richt für die Transaktion, die sie verursacht hat, aufgezeich
net. Die Operationen, die eine Namensgebung für Daten in der
Übergabenachricht erfordern, sind in Anhang A notiert. Diese
und ähnliche Nachrichten werden bei den mit Bezug auf Fig. 6
oder 7 beschrieben oder anderen, ähnlichen Methoden in die
Protokolldatei geschrieben.
Bei einer anderen Ausführung wird die Telescope-Software 160
modifiziert, um im Kontext von HA-PXFS 228 (Fig. 3) zu funktio
nieren, das den PXFS-Server 134 erweitert, um Fehler mit einer
relativ kurzen Dienstunterbrechung zu handhaben. Weil Telescope
160 in den PXFS-Server 134 implementiert ist, kann es den
Schutz nutzen, der durch HA-PXFS 228 angeboten wird. Der Teles
cope-Dienst 160L muß nicht mit einigen der komplexen Hochver
fügbarkeitsthemen (issues) umgeben, die für HA-PXFS 228 wichtig
sind. Beispielsweise überträgt Telscope 160 nicht Sperren
durch Checkpointing zum entfernten Standort. Der Telescope-
Service 160L repliziert Daten anstatt den Anwendungszustand;
nach einem Standortausfall müssen Anwendungen wieder gestartet
werden. Weil HA-PXFS 228 einen Failover bereitstellt, der für
Klienten 124 transparent ist, kann es diese Punkte nicht unbe
rücksichtigt lassen (does not have the luxury of disregarding
these issues). Die HA-PXFS-Architektur und erforderliche Modi
fikationen an Telescope 160 werden nun mit Bezug auf Fig. 10
beschrieben.
Mit Bezug auf Fig. 10 basiert die HA-PXFS-Architektur auf einem
primären und einem sekundären Server 122p, 122 s (die nicht mit
den lokalen und sekundären Standorten von Telescope verwechselt
werden dürften), die sich eine Zwei-Tor-Platte 126d teilen bzw.
eine solche gemeinsam haben. Dieses System arbeitet ähnlich
wie die mit Bezug auf Fig. 3 beschriebene, bevorzugte Ausfüh
rung mit Ausnahme von Unterschieden, die nun beschrieben wer
den. Anforderungen vom PXFS-Serveranforderungen werden durch
den primären Server 122p gehandhabt. Jede Anforderung wird an
den sekundären Server 122 s gecheckpointed, so daß dieser trans
parent übernehmen kann, falls der primäre Server versagt. Wenn
der Mitgliedschaftsmonitor 480 des Galileo-Clusters einen Feh
ler des primären Servers 122p detektiert, wird der sekundäre
Server 122 s benachrichtigt. Der sekundäre Server 122 instal
liert (mounts) das Dateisystem 148 und enthält PXFS-Dateiobjek
te von gecheckpointeten fobjid_t-Zeigern. Falls eine Operation
zum Zeitpunkt des Versagens im Ablauf befindlich war, schließt
der sekundäre Server 122 s diese ab. Operationen werden in Mini-
Transaktionen gekapselt, um eine Genau-Einmal-Semantic (exact
ly-once semantics) zu garantieren. Mini-Transaktionen werden im
Detail in der US-Patentanmeldung mit Seriennr. 08/829,156,
"Method and System for Achieving High Availability in Networked
Computer Systems", von Matena et al., eingereicht am 31. März
1997 beschrieben, die hier durch Bezugnahme vollständig aufge
nommen wird.
Die Integration von Telescope mit HA-PXFS konzentriert sich auf
drei Probleme:
- 1. Das Checkpointing des richtigen Telescope-Zustandes vom primären zum sekundären Server.
- 2. Einsetzen von Protokolleinträgen oder Übermittlungen in Mini-Transaktionen.
- 3. Wiedererlangung von Zugang zum Telescope-Protokoll vom sekundären Server nach einem Ausfall.
Der Telescope-Zustand, der vom primären Server 122p zum sekun
dären Server 122 s gecheckpointet bzw. mit Checkpointing über
tragen wird (Nachrichten (8.1)), umfaßt die transaction id 276
und den Protokollanker 230. Beide gecheckpointeten Elemente
sind notwendig für eine effiziente Wiederherstellung des Teles
cope-Protokolls 264. Sie werden beide im Speicher beim primären
Server 122p gehalten und daher ist eine Plattenablesung zur
Registrierung des Checkpoints nicht notwendig. Der Protokollan
ker (der mit Bezug auf Fig. 3 beschrieben ist) enthält Daten,
um die Protokolldatei zu finden und den nächsten Ort für einen
Eintrag zu lokalisieren. Die transaction id ermöglicht es dem
sekundären Server 122 s, das Ansteigen von transaction_id-Werten
zu verfolgen, wodurch eine zufällige Wiederverwendung von
transaction id 276 verhindert wird. Es ermöglicht es Telescope
160L auch zu prüfen, ob eine Operation, die während des Aus
falls des primären Servers gerade ablief, an das Telescope-
Protokoll 264 übergeben wurde.
Telescope-Protokolleinträge können mit den Operationen in HA-
PXFS-Mini-Transaktionen integriert sein. Ohne Telescope 160 ist
die Abfolge an Ereignissen in HA-PXFS zur Befriedigung der
Anforderung eines Klienten wie folgt:
- 1. Klient schickt Anforderung (request).
- 2. Der Primäre sendet Checkpoint mit Zustandsdaten.
- 3. Der Sekundäre weist Zustandsobjekt zu und quittiert Checkpoint.
- 4. Der Primäre aktualisiert Speicher.
- 5. Der Primäre gibt Ergebnisse zurück.
- 6. Klient sendet eine asynchrone Vergessen-Nachricht (forget message) zum Sekundären.
Die (oben beschriebene) Telescope-Protokollprozedur verbessert
diese Folge durch Hinzufügen eines zusätzlichen Schrittes nach
Schritten 1 und 4 wie folgt:
- 1. Klient schickt Anforderung.
- 1. 1.1 Der Primäre 122p gibt die Anforderung in das Proto koll ein und empfängt eine transaction id.
- 2. Der Primäre sendet Checkpoint mit Zustandsdaten.
- 3. Der Sekundäre weist Zustandsobjekt zu und quittiert Checkpoint.
- 4. Der Primäre aktualisiert Speicher.
- 1. 4.1 Der Primäre 122p trägt abhängig davon, ob eine Operation erfolgreich war, eine Übergabe- oder Invalidisierungsnachricht in das Protokoll ein.
- 5. Der Primäre gibt Ergebnisse zurück.
- 6. Klient sendet eine asynchrone Vergessen-Nachricht (forget message) zum Sekundären.
Dieser Algorithmus garantiert, daß der sekundäre Server 122 s in
der Lage ist, den Telescope-Dienst 160 in einem konsistenten
Zustand erneut zu starten. Fehler können an verschiedenen Stel
len in Bezug auf die Telescope-Protokolloperationen passieren:
- 1. Falls der primäre Server vor Schritt 2 versagt, wird es keine Aufzeichnung geben, daß die Anforderung jemals empfangen wurde. Der Galileo-Replikationsrah men bzw. die Galileo-Replikationsumgebung (Galileo replication framework) wird die Anforderung erneut zum sekundären Server schicken.
- 2. Wenn der Primäre zwischen Schritten 2 und 3 versagt, wird die Anforderung im Protokoll, aber nicht im Dateisystem erscheinen und es wird kein Zustand an den sekundären Server gecheckpointet werden. In diesem Fall sollte der sekundäre Server seinen zu letzt gecheckpointeten Protokollanker konsultieren bzw. befragen. Falls zusätzliche Protokolleinträge vorgenommen, aber nicht gecheckpointet wurden, werden diese am next_rec-Zeiger 242 (Fig. 3) im Protokollan ker gefunden werden. Weil die Anforderung durch die Galileo-Replikationsumgebung erneut gesendet werden wird, sollten alle derartigen Protokolleinträge durch den sekundären Server mit einem Invalidisierungspro tokolleintrag nullifiziert bzw. aufgehoben werden.
- 3. Wenn die Transaktion-id der aktuellen Operation zum sekundären Server gecheckpointet wird, werden primär seitige Versagen einfacher. Falls der Sekundäre die Operation erneut versucht, muß kein neuer Protokoll eintrag aufgezeichnet werden, weil schon einer exi stiert. Es wird abhängig davon, ob von der Operation angenommen wird, daß sie erfolgreich ist oder nicht, eine Übergabe- oder Invalidisierungsnachricht aufge zeichnet. Falls der frühere Primäre eine Übergabe nachricht aufgezeichnet hatte (folglich trat das Ver sagen zwischen Schritten 6 und 7 auf), bleibt eine zusätzliche Übergabenachricht unberücksichtigt.
Folglich ist der Failover-Algorithmus zum Wiederstarten von
Telescope 160 nach einem Versagen bzw. Ausfall des Primären
122p wie folgt:
- 1. Führe ein HA-PXFS-Failover durch inklusive der Aussperrung von Operationen, einer Installation (mounting) des Dateisystems und des Erhaltens von vnode-Zeigern.
- 2. Lokalisiere die Protokolldatei 214 entweder von dem letzten gecheckpointeten Protokollanker 230 oder von einem wohlbekannten Ort auf der geteilten bzw. ge meinsamen Platte 126.
- 3. Prüfe unter Verwendung des next_rec-Zeigers 242 vom letzten gecheckpointeten Protokollanker 230, ob zusätzliche Protokolleinträge gemacht worden sind, ohne gecheckpointet worden zu sein. Falls dies der Fall ist, erhalte die transaction_id's 276 von diesen Einträgen und protokolliere Invalidisierungsnachrich ten (die Anforderung wird erneut versucht werden).
- 4. Aktualisiere die Protokollanker-Datenstruktur 230.
Die in diesem Abschnitt beschriebenen Algorithmen konzentrieren
sich auf den 1-safe-Betriebsmodus. Sie ändern sich wenig für
den 2-safe-Modus. Zum Beispiel überträgt der primäre Standort,
anstatt eine Übergabenachricht in das Protokoll 264 in Schritt
4.1 oben einzutragen, den in Schritt 2 erzeugten Protokollein
trag 266 an den entfernten Standort. Der Primäre 122p gibt so
lange keine Ergebnisse zurück (Schritt 5), bis vom entfernten
Standort eine Quittung empfangen wurde. Wenn vielfache Kopien
des Protokolleintrages 266 während eines Failovers an den ent
fernten Standort übertragen werden, werden sie durch die trans
action id als Duplikate identifiziert werden und es wird nur
die erste ausgeführt. Es ist zu bemerken, daß sich Telescope
160 auf die Galileo-Replikationsumgebung verläßt, um nach einem
Ausfall alle Nachrichten vom entfernten Standort zu neuem pri
mären Server (beispielsweise dem sekundären lokalen Server
122 s) zu leiten.
Bei einer bevorzugten Ausführung überträgt Telescope 160 Daten
unter Verwendung von Standard-Unix-Socket-Hilfsprogrammen
(standard Unix socket utilities). Die Verwendung einer Hochni
veau-Schnittstelle ermöglicht es Telescope, über jede beliebige
Anzahl von physikalischen Netzwerken über jede beliebige Anzahl
von Vernetzungsprotokollen zu funktionieren. TCP/IP wird auf
grund seiner Zuverlässigkeit und des Durchsatzes vorgeschlagen.
Falls eine zweckgebundene (dedicated) Verbindung zwischen dem
lokalen und dem entfernten Standort eingerichtet werden kann,
verbessert sich die Leistung von Telescope, insbesondere im 2-
safe- oder very safe-Modus wesentlich. In jedem Fall ist es
wichtig, von vornherein festzulegen, daß die Netzwerkbandbreite
mit der Bandbreite des genutzten Speichersystems zusammenpassen
kann. Techniken, wie beispielsweise Datenkompression können ge
nutzt werden, um Netzwerkbandbreitenprobleme zu lindern, aber
auf Kosten einer erhöhten Latenz.
Die Details des Aufbaues und der Aufrechterhaltung einer Ver
bindung zwischen den Standorten hängt von den globalen Vernet
zungsfähigkeiten von Galileo ab. Die vorliegende Erfindung
schließt keine Art und Weise der Einrichtung und Aufrecht
erhaltung einer solchen Verbindung aus.
Die Verbindungseinrichtungsprozedur ist eine, die sich über
aufeinanderfolgende Telescope-Versionen entwickeln kann. Die
einzige erforderliche Fähigkeit ist irgendein Mittel zur Ein
richtung eines Paares von Socket-Verbindungen (a pair of socket
connections) zwischen den primären und entfernten Standorten.
Anfänglich können IP-Adressen und Tor-Namen (port names) an
beiden Standorten manuell eingegeben werden. Im Laufe der Zeit
kann ein automatisches Einrichtungsprotokoll eingerichtet bzw.
aufgebaut werden.
Das automatische Einrichtungsprotokoll würde wahrscheinlich auf
einem wohlbekannten Telescope-Steuerungstor (control port) ba
sieren. Der Steuerungsport bzw. Steuerungseingang würde exklu
siv zum Aufbau von Verbindungen zwischen primären und entfern
ten Standorten benutzt werden. Um einen entfernten Standort zu
ermöglichen, würde der (in Abschnitt 4.9) beschriebene, ent
fernte Telescope-Dienst auf einem Galileo-Cluster gestartet
werden. Er würde auf eine Verbindungsanforderung an den Steuer
eingang warten. Nach Empfang einer Verbindungsanforderung würde
der entfernte Telescope-Dienst auf irgendeine Weise die Repli
kationsressourcen, die es verfügbar hatte, anzeigen - zum Bei
spiel freie Plattenpartitionen und deren Größe und auch die
wahrgenommene bzw. erfaßte Netzwerkbandbreite und Latenz zwi
schen den Standorten. Der primäre Standort würde die Replika
tionsressourcen anzeigen, die er benötigt und ein Paar von
Socket-Verbindungen (a pair of socket connections) für eine
Zwei-Wege-Verbindung zwischen den Standorten würde aufgebaut
werden.
Vor den Replikationsdaten befindet sich ein Telescope-Kopf. Der
Telescope-Kopf zeigt den Übertragungsmodus (1-safe, 2-safe oder
very-safe) und die Länge der Übertragung an. Der Übertragungs
modus zeigt an, welche Aktion der entfernte Standort bei Emp
fang des Paketes ausführen sollte. Beim 2-safe- und very-safe-
Modus ist Latenz kritisch. Der entfernte Standort sollte so
schnell wie möglich die kodierte Operation durchführen und eine
Quittung zurücksenden. Im 1-safe-Modus ist Latenz nicht so
wichtig und es ist manchmal notwendig, den gesamten Inhalt
einer großen Übertragung zu empfangen, bevor irgendeine Aktion
ausgeführt werden kann. Das Längenfeld im Kopf zeigt an, wie
viele Bytes der Empfänger vom Körper der Übertragung erwarten
sollte. Dies vereinfacht den Empfang der Daten von einer Strom
schnittstelle (streams interface).
Der Kopf sollte zwei andere Felder umfassen, die möglicherweise
nicht in die ursprüngliche Version von Telescope inkorporiert
sind, aber später wichtig sein können. Zunächst können übertra
gene Daten komprimiert werden, um Netzwerkbandbreite zu sparen.
Falls Kompressionsalgorithmen variieren, kann ein Kopffeld not
wendig sein, um den richtigen Dekompressionsalgorithmus anzu
zeigen. Zweitens muß Telscope möglicherweise seine eigenen
Authentisierungs- und Verschlüsselungsdienste bereitstellen.
Falls dies notwendig ist, kann ein Kopffeld für einen Authenti
sierungs- oder Verschlüsselungsschlüssel notwendig sein.
Der Körper der Übertragung besteht aus Protokolleinträgen. Im
2-safe- und very-safe-Modus sollte nur ein Eintrag auf einmal
übermittelt werden, obwohl Optimierungen möglicherweise gleich
zeitige Übertragungen für gleichzeitige Zugriffe ermöglichen
können. Im 1-safe-Modus kann der Inhalt des Protokolls in gro
ßen Fragmenten übertragen werden. Telescope stellt keine Grö
ßengrenze für den Körper der Übertragung auf; jedoch sollten
Beschränkungen beim Pufferraum auf der Sendeseite und der Emp
fangsseite berücksichtigt werden.
Die Übertragung im 2-safe- und very-safe-Modus wird durch deren
Algorithmen bedingt. Der 1-safe-Modus ist dagegen viel flexib
ler. Der Zeitabstand, in dem Übertragungen stattfinden, sollte
durch verschiedene Faktoren beeinflußt sein:
- - Die Größe des Protokolls.
- - Die Rate oder Geschwindigkeit, mit der Einträge im Proto koll ausgezeichnet werden.
- - Die Rate oder Geschwindigkeit, mit der das Protokoll abge lassen bzw. geräumt werden kann, wenn die Übertragung be ginnt.
- - Die akzeptierbare Konsistenzverzögerung (concistency lag) zwischen primärem und sekundärem Standort.
Unter normalen Umständen wird Telscope 160 ein zirkuläres
Protokoll 264 verwenden. Zirkuläre Protokolle verwenden Platz
wieder, indem Teile des Protokolles, die nicht mehr benötigt
werden, wieder verwendet werden. Beispielsweise kann, wenn der
Inhalt eines Bereiches der Protokolldatei an den entfernten
Standort übertragen und quittiert wurde, dieser Bereich der
Protkolldatei wieder verwendet werden. Es gibt Gründe, zirkulä
re Protokolle nicht zu verwenden. Zum Beispiel kann der Inhalt
des Protokolls dazu benutzt werden, die auf das Dateisystem
angewendeten Operationen zu prüfen (audit). In diesem Fall muß
die Protokolldatei 264 in der Lage sein, unendlich zu wachsen
oder es sollten viele Protokolldateien verwendet werden. Im
zirkulären wie im nicht-zirkulären Fall wären die Übertragungs
parameter nicht richtig konfiguriert, wenn sich das Protokoll
wieder auffüllt. Das Telescope-Management API (welches hier
nicht beschrieben wird), enthält Methoden zum Einstellen
(setting) des 1-safe-Übertragungsabstandes (transmission
interval).
Übertragung im 1-safe-Modus basiert auf Parametern, die im
Protokollanker gespeichert sind. Wenn eine Übertragung einge
leitet wird, wird von den last_flush- und prev_lsn-Feldern ein
Schnappschuß genommen. Diese LSNs definieren den Bereich des
Protokolles, der übertragen werden wird. Weil die Übertragung
das Ende des Protokolls nicht beeinflußt, ist keine Sperre des
Protokolls erforderlich, um Daten von dem Übertragungsbereich
zu lesen. Es wird empfohlen, daß die Übertragung durch einen
zweckgebundenen (dedicated) Thread bzw. Teilprozess durchge
führt wird, so daß Dateisystemoperationen, die neue Aufzeich
nungen zum Protokoll hinzufügen, nicht beeinflußt werden.
Der zweckgebundene Thread überträgt den Bereich des Protokolls
durch die schon eingerichtete Socket-Verbindung. Er wartet auf
Quittierung aller übertragenen Daten, bevor er sich selbst für
das nächste Räumen des Protokolls (next log flush) verfügbar
macht. Einfache Netzwerkprotokollquittierungen sind nicht
ausreichend - es muß von dem entfernten Telescope-Dienst 160R
eine Quittierung empfangen werden, daß die übertragenen Opera
tionen auf das Dateisystem am entfernten Standort angewandt
wurden.
Dieses Übertragungsschema kann verbessert werden, indem ermög
licht wird, daß mehrere gleichzeitige Threads Daten an den
entfernten Standort übertragen. Während der entfernte Standort
einen Satz von Operationen auf das entfernte Dateisystem anwen
det, kann ein anderer den nächsten Satz von Operationen durch
das Netzwerk bewegen. Dieses Schema ist komplizierter in Bezug
auf die Identifikation verlorener Übertragungen. Weil der
Telescope-Dienst 160R die chronologische Reihenfolge des Proto
kolls 264 aufrechterhält bzw. konserviert, kann es Protokollbe
reichen, die durch getrennte Threads übermittelt werden, nicht
ermöglicht werden, beim Übergang aneinander vorbeizulaufen.
Mit Bezug auf Fig. 3 wird der Protokollanker während der Proto
kollablaßprozedur aktualisiert, um den aktuellen Status der
Übertragung widerzugeben. Das last_ACK-Feld 248 wird geschrie
ben, wann immer der primäre Standort eine Quittung empfängt,
daß Operationen am entfernten Standort angewendet wurden. Das
last_flush-Feld 246 wird geschrieben, wann immer Daten übertra
gen werden. Es ist fast unmöglich für last_ACK 248, auf eine
chronologisch spätere Position in dem Protokoll zu zeigen als
das last_flush-Feld. Im Falle eines einzelnen Threads kann ein
erneutes Räumen bzw. Ablassen des Protokolls nicht beginnen,
bis die last_ACK- und last_flush-Felder 248, 246 die gleichen
sind.
Synchronisationsdaten können in einem speziellen Protokoll
übertragen werden oder sie können als Protokolleinträge kodiert
sein. Die Verwendung von Protokolleinträgen sollte der einfa
chere Ansatz sein, weil es für eine andere Methode die Notwen
digkeit vermeidet, Daten zu kapseln. Beispielsweise könnten zur
Anzeige, daß eine Datei vom primären Standort zum entfernten
Standort kopiert werden soll, zwei Protokolleinträge 266 wie
folgt benutzt werden:
- 1. Ein Dateierzeugungseintrag (file create entry) wird den Pfadnamen der Datei und das Kennzeichen (identi fier) anzeigen, daß der primäre Standort bei zukünf tigen Übertragungen bzgl. dieser Datei verwenden wird; und
- 2. ein Dateischreibeeintrag (file write entry) kann verwendet werden, um den Inhalt der Datei an den entfernten Standort zu übertragen.
Falls Datei-Timestamps aufbewahrt werden müssen, können diese
über Eigenschafts-Protokolleinträge übertragen werden. Für eine
größere Effizienz können viele kodierte Einträge zusammengefaßt
(batched) undgemeinsam übertragen werden.
Die meisten der am entfernten Standort erforderlichen Teles
cope-Dienste 160R sind schon diskutiert worden, aber sie werden
hier kurz zusammengefaßt.
Der entfernte Standort hat die folgenden Pflichten bzw. Aufga
ben:
- 1. Akzeptierung bzw. Annahme von Anforderungen zur Replikation;
- 2. Dekodierung und Wiederabspielung (replay) von Proto kolleinträgen; und
- 3. Bereitstellung eines PXFS-Servers für einen Nur- Lese-Zugriff während normalem Betrieb und Lese- Schreib-Zugriff nach Failover.
Es gibt verschiedene unterschiedliche Typen von Fehlern, die
Telescope berücksichtigen muß. Einer, das Versagen bzw. der
Ausfall eines PXFS-Servers am primären Standort, ist schon
diskutiert worden. Ein anderer, ein Versagen bzw. Fehler beim
primären Standort, ist der prinzipielle Grund, warum Telescope
existiert. Andere Fehler, die Telescope 160 berücksichtigt,
umfassen:
- 1. Fehler bei einer Operation, die am primären Standort erfolgreich war, bei der Anwendung am entfernten Standort;
- 2. Versagen der Synchronisationsprozedur;
- 3. Versagen des entfernten Telescope-Dienstes (inklusive Versagen des Knotens, auf dem sich der entfernte Telescope-Service befindet);
- 4. Versagen bzw. Ausfall des entfernten Standortes; und
- 5. Versagen bzw. Ausfall der Verbindung zwischen dem primären und entfernten Standort.
Obwohl die vorliegende Erfindung nicht beschreibt, wie diese
Fehler speziell von Telescope 160 behandelt werden, sollte es
von der vorhergehenden Diskussion ersichtlich sein, wie solche
Fehler durch den Telescope-Dienst 160 berücksichtigt werden.
Während die vorliegende Erfindung mit Bezug auf wenige besonde
re Ausführungen beschrieben wurde, erklärt die Beschreibung die
Erfindung und soll nicht zur Beschränkung der Erfindung ausge
legt werden. Verschiedene Modifikationen werden dem Fachmann
ersichtlich werden, ohne daß vom wahren Geist und dem Umfang
der Erfindung, wie sie in den angehängten Ansprüchen definiert
ist, abgewichen wird.
Das Folgende listet die C++-Prototypen für die gecheckpointeten
Methoden in Tabelle 1 auf und zeigt an, welche Parameter durch
die geographische Replikationssoftware (d. h. den Telescope-
Dienst 160) zum entfernten Standort übertragen werden müssen.
Alle f_obj und abgeleiteten Typen werden als fobjid_t's ge
sandt. Jeder Prototyp zeigt auch die Klasse an, deren Mitglied
er ist. Die Klasseninstanz, auf der die Methode aufgerufen
wird, wird als "this" bezeichnet. Andere in diesem Anhang ver
wendeten Begriffe umfassen:
sol: die Klasse, die Solaris-Fehler, -Typen usw.
definiert.
dirprov: die Klasse, die Verzeichnisoperationen implementiert.
mempager: die Klasse, die Seitenwechsel(paging)- Operationen implementiert.
io_ii: die Klasse, die Eingabe/Ausgabe (i/o (input/output))-Operationen implementiert.
fobj_ii: die Klasse, die alle gattungsgemäßen Dateioperationen implementiert.
dirprov: die Klasse, die Verzeichnisoperationen implementiert.
mempager: die Klasse, die Seitenwechsel(paging)- Operationen implementiert.
io_ii: die Klasse, die Eingabe/Ausgabe (i/o (input/output))-Operationen implementiert.
fobj_ii: die Klasse, die alle gattungsgemäßen Dateioperationen implementiert.
sol::error_t
dirprov_ii::create_fobj(const char*nm, const sol::vattr_t& attr, sol::vcexcl_t exciflag, Long mode, fs::fobj_out fobj, fs::fobj_info& fobjinfo, Ulong& key, solobj::cred_ptr credobj, Long flag, Environment );
Übertrage.this, nm, attr, exclf lag, mode. Bei Übergabe, transmit f obj.
dirprov_ii::create_fobj(const char*nm, const sol::vattr_t& attr, sol::vcexcl_t exciflag, Long mode, fs::fobj_out fobj, fs::fobj_info& fobjinfo, Ulong& key, solobj::cred_ptr credobj, Long flag, Environment );
Übertrage.this, nm, attr, exclf lag, mode. Bei Übergabe, transmit f obj.
sol::error_t
dirprov_ii::remove_fobj(const char*nary, solobj::cred_ptr credobj, Environment);
Übertrage: this, nm.
dirprov_ii::remove_fobj(const char*nary, solobj::cred_ptr credobj, Environment);
Übertrage: this, nm.
sol::error_t
dirprov_ii::create_symlink(const char*nary, const sol:: vattr_t& attr, const char*targetpath, solobj::cred_ptr credobj, Environment);
Übertrage: this, nm, attr, targetpath.
dirprov_ii::create_symlink(const char*nary, const sol:: vattr_t& attr, const char*targetpath, solobj::cred_ptr credobj, Environment);
Übertrage: this, nm, attr, targetpath.
sol::error_t
dirprov_ii::create_dir(const char*dirnm, const sol::vattr_t& attr, fs::unixdir_out newdir, ULong& key, solobj::cred_ptr credobj, Environment);
Übertrage: this, dirnm, attr. Bei Übergabe, transmit newdir.
dirprov_ii::create_dir(const char*dirnm, const sol::vattr_t& attr, fs::unixdir_out newdir, ULong& key, solobj::cred_ptr credobj, Environment);
Übertrage: this, dirnm, attr. Bei Übergabe, transmit newdir.
sol::error_t
dirprov_ii::remove_dir(const char*dirnm, fs::unixdir_ptr cur_dir, solobj::cret_ptr credobj, Environment); Übertrage: this, dirnm, cur_dir.
dirprov_ii::remove_dir(const char*dirnm, fs::unixdir_ptr cur_dir, solobj::cret_ptr credobj, Environment); Übertrage: this, dirnm, cur_dir.
sol::error_t
dirprov_ii::rename_fobj(const char*sourcenm, fs::unixdir_ptr target_dir, const char*targetnm, solobj::cred_ptr credobj, Environment);
Übertrage: this, sourcenm, target_dir, targetnm.
dirprov_ii::rename_fobj(const char*sourcenm, fs::unixdir_ptr target_dir, const char*targetnm, solobj::cred_ptr credobj, Environment);
Übertrage: this, sourcenm, target_dir, targetnm.
void mempager_ii::page_out(sol::u_offset_t offset, sol::size_t
length, Boolean set_size, bulkio::in_pages_ptr pglobj,
solobj::cred_ptr credobj, Environment);
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
void mempager_ii::write_out(sol::u_offset_t offset, sol::size_t
length, Boolean set_size, bulkio::in_pages_ptr pglobj,
solobj::cred_ptr credobj, Environment);
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
void mempager_ii::sync(sol::u_offset_t offset, sol::size_t
length, Boolean set_size, Long, bulkio::in_pages_ptr pglobj,
solobj::cred_ptr credobj, Environment);
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
Übertrage: this, offset, length, set_size, extrahiere Daten von Seiten.
sol::error_t io_ii::uiowrite(sol::u_offset_t off, sol::size_t&
len, bulkio::in_uio_ptr uioobj, Long ioflag, solobj::cred_ptr
credobj, Environment);
Übertrage: this, off, len.
Übertrage: this, off, len.
sol::error_t io_ii::faync(Long syncflag, solobj::cred_ptr
credobj, Environment);
Übertrage: this, syncflag.
Übertrage: this, syncflag.
sol::error_t fobj_ii::set_attributes(const sol::vattr_t& attr,
solobj::cred_ptr credobj, Environment);
Übertrage: this, attr.
Übertrage: this, attr.
sol::error t fobj_ii::set_secattributes(const fs::secattr&
sattr, Long secattrflag, solobj::cred_ptr credobj, Environment&
_environment);
Übertrage: this, sattr, secattrflag.
Übertrage: this, sattr, secattrflag.
void fobjprov_ii::write_all_attr(sol::vattr_t& attributes,
solobj::cred ptr credobj, Environment);
Übertrage: this, attributes.
Übertrage: this, attributes.
sol::error_t fobj_ii::ioctl(Long noeid, Long pid, Long iocmd,
Long arg, Long flag, Long& result, solobj::cred_ptr credobj,
Environment);
Übertrage: iocmd, arg, flag.
Claims (24)
1. Geographisches Datenreplikationssystem mit:
einem lokalen primären Server, der so konfiguriert ist, daß auf ihm ein erstes Dateisystem hoher Verfügbar keit (first high availability file system (FHAFS)) und ein lokales Dateisystem läuft;
einem mit dem lokalen primären Server gekoppelten lokalen sekundären Server, der so konfiguriert ist, daß auf ihm das lokale Dateisystem läuft und daß er auf durch den lokalen Primären eingeleitete FHAFS-Mini- Transaktionen antwortet;
mit den lokalen Servern gekoppeltem, erstem Zwei- Tor-Dateispeicher, mit dem die lokalen Server über das lokale Dateisystem interagieren;
mindestens einem Klienten, der so konfiguriert ist, daß er an den lokalen Primären lokale Dateisystemanfor derungen abgibt;
wobei der lokale Primäre entsprechend dem FHAFS konfiguriert ist, um an den lokalen Sekundären den An wendungszustand übertragende Mini-Transaktionen durch Checkpointing zu übermitteln, um den lokalen Sekundären in die Lage zu versetzen, wenn der lokale Primäre aus fällt, Operationen des lokalen Primären entsprechend dem durch Checkpointing übermittelten Anwendungszustand zu übernehmen, wobei der lokale Sekundäre nur aktiv ist, wenn der lokale Primäre inaktiv ist;
einem lokalen Server, der derjenige vom ersten Pri mären und Sekundären ist, der aktiv konfiguriert ist, zum Abfangen der lokalen Dateianforderungen und zur Be stimmung, welche der lokalen Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des lokalen Dateisystems ändern wird; und
einer in dem ersten Zwei-Tor-Dateispeicher gespei cherten Protkolldatei, in die der lokale Server Opera tionen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server dazu konfiguriert ist, die Protokoll datei periodisch zu einem entfernten Standort zu räumen, was den entfernten Standort in die Lage versetzt, die lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand zu bedienen, wenn der lokale Standort ausfällt;
derart, daß, wenn er aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints in Verbindung mit den durch das FHAFS abgegebenen Mini-Transaktions-Checkpoints weiterzugeben, was den lokalen Sekundären in die Lage versetzt, wenn der lokale Primäre ausfällt, unvollendete lokale Datei anforderungen zu vollenden und nachfolgende lokale Da teianforderungen entsprechend dem Datei- und Anwendungs zustand zu handhaben.
einem lokalen primären Server, der so konfiguriert ist, daß auf ihm ein erstes Dateisystem hoher Verfügbar keit (first high availability file system (FHAFS)) und ein lokales Dateisystem läuft;
einem mit dem lokalen primären Server gekoppelten lokalen sekundären Server, der so konfiguriert ist, daß auf ihm das lokale Dateisystem läuft und daß er auf durch den lokalen Primären eingeleitete FHAFS-Mini- Transaktionen antwortet;
mit den lokalen Servern gekoppeltem, erstem Zwei- Tor-Dateispeicher, mit dem die lokalen Server über das lokale Dateisystem interagieren;
mindestens einem Klienten, der so konfiguriert ist, daß er an den lokalen Primären lokale Dateisystemanfor derungen abgibt;
wobei der lokale Primäre entsprechend dem FHAFS konfiguriert ist, um an den lokalen Sekundären den An wendungszustand übertragende Mini-Transaktionen durch Checkpointing zu übermitteln, um den lokalen Sekundären in die Lage zu versetzen, wenn der lokale Primäre aus fällt, Operationen des lokalen Primären entsprechend dem durch Checkpointing übermittelten Anwendungszustand zu übernehmen, wobei der lokale Sekundäre nur aktiv ist, wenn der lokale Primäre inaktiv ist;
einem lokalen Server, der derjenige vom ersten Pri mären und Sekundären ist, der aktiv konfiguriert ist, zum Abfangen der lokalen Dateianforderungen und zur Be stimmung, welche der lokalen Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des lokalen Dateisystems ändern wird; und
einer in dem ersten Zwei-Tor-Dateispeicher gespei cherten Protkolldatei, in die der lokale Server Opera tionen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server dazu konfiguriert ist, die Protokoll datei periodisch zu einem entfernten Standort zu räumen, was den entfernten Standort in die Lage versetzt, die lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand zu bedienen, wenn der lokale Standort ausfällt;
derart, daß, wenn er aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints in Verbindung mit den durch das FHAFS abgegebenen Mini-Transaktions-Checkpoints weiterzugeben, was den lokalen Sekundären in die Lage versetzt, wenn der lokale Primäre ausfällt, unvollendete lokale Datei anforderungen zu vollenden und nachfolgende lokale Da teianforderungen entsprechend dem Datei- und Anwendungs zustand zu handhaben.
2. Geographisches Datenreplikationssystem nach Anspruch 1,
weiterhin mit einem Mitgliedschaftsmonitor, der konfigu
riert ist, einen Ausfall des lokalen Primären zu detek
tieren und den lokalen Sekundären zu aktivieren, wenn
der lokale Primäre ausfällt.
3. Geographisches Datenreplikationssystem nach Anspruch 2,
bei dem der lokale Sekundäre, wenn er durch den Mit
gliedschaftsmonitor aktiviert ist, dazu konfiguriert
ist:
das lokale Dateisystem aufzubauen (mount);
Zeiger zu lokalen Dateisystemobjekten zu erhalten, die in den Dateicheckpoints repräsentiert sind; und
Dateioperationen zu vollenden, die zum Zeitpunkt des Ausfalls des lokalen Primären in Gang waren.
das lokale Dateisystem aufzubauen (mount);
Zeiger zu lokalen Dateisystemobjekten zu erhalten, die in den Dateicheckpoints repräsentiert sind; und
Dateioperationen zu vollenden, die zum Zeitpunkt des Ausfalls des lokalen Primären in Gang waren.
4. Geographisches Datenreplikationssystem nach Anspruch 1,
bei dem:
der lokale Server konfiguriert ist, in die Proto kolldatei eine eindeutige Transaktions-id (transaction id) entsprechend jeder der Dateisystemanforderungen einzutragen;
der durch den lokalen Primären an den lokalen Sekundären für eine bestimmte Dateisystemanforderung gesendete Dateicheckpoint eine jeweilige, besondere Transaktions-id aufweist;
der lokale Sekundäre beim Empfang des Dateicheck points konfiguriert ist, ein mit der besonderen Transak tions-id in Verbindung stehendes Zustandsobjekt zuzuwei sen und den Dateicheckpoint zu quittieren;
nach Versendung des Dateicheckpoints der lokale Primäre dazu konfiguriert ist, den Zwei-Tor-Speicher gemäß der besonderen Dateisystemanforderung zu aktuali sieren;
der lokale Primäre dazu konfiguriert ist, eine Übergabenachricht in die Protokolldatei einzugeben, wenn die besondere Dateisystemanforderung erfolgreich abge schlossen ist, und anderenfalls eine Ungültigkeitsnach richt (invalidate message);
der lokale Primäre das Ergebnis einer besonderen Dateisystemanforderung an den anfordernden Klienten zurückgibt; und
der Klient eine asynchrone Vergessen-Nachricht (forget message) an den lokalen Sekundären sendet.
der lokale Server konfiguriert ist, in die Proto kolldatei eine eindeutige Transaktions-id (transaction id) entsprechend jeder der Dateisystemanforderungen einzutragen;
der durch den lokalen Primären an den lokalen Sekundären für eine bestimmte Dateisystemanforderung gesendete Dateicheckpoint eine jeweilige, besondere Transaktions-id aufweist;
der lokale Sekundäre beim Empfang des Dateicheck points konfiguriert ist, ein mit der besonderen Transak tions-id in Verbindung stehendes Zustandsobjekt zuzuwei sen und den Dateicheckpoint zu quittieren;
nach Versendung des Dateicheckpoints der lokale Primäre dazu konfiguriert ist, den Zwei-Tor-Speicher gemäß der besonderen Dateisystemanforderung zu aktuali sieren;
der lokale Primäre dazu konfiguriert ist, eine Übergabenachricht in die Protokolldatei einzugeben, wenn die besondere Dateisystemanforderung erfolgreich abge schlossen ist, und anderenfalls eine Ungültigkeitsnach richt (invalidate message);
der lokale Primäre das Ergebnis einer besonderen Dateisystemanforderung an den anfordernden Klienten zurückgibt; und
der Klient eine asynchrone Vergessen-Nachricht (forget message) an den lokalen Sekundären sendet.
5. Geographisches Datenreplikationssystem nach Anspruch 1,
bei dem der entfernte Standort mindestens einen entfern
ten Server aufweist, auf dem ein zweites Dateisystem und
ein zweiter stabiler Dateispeicher läuft; weiterhin mit:
der entfernte Server ist dazu konfiguriert, den Zu stand des zweiten Dateisystems entsprechend der geräum ten Protokolldatei durch Durchführung der Operationen auf den in der geräumten Protokolldatei repräsentierten Daten zu aktualisieren;
derart, daß, wann immer ein Failover von dem loka len zu dem entfernten Standort auftritt, der entfernte Server in der Lage ist, die Anforderungen von den Klien ten mit wenig oder keinem Verlust an Dateizustand zu bedienen.
der entfernte Server ist dazu konfiguriert, den Zu stand des zweiten Dateisystems entsprechend der geräum ten Protokolldatei durch Durchführung der Operationen auf den in der geräumten Protokolldatei repräsentierten Daten zu aktualisieren;
derart, daß, wann immer ein Failover von dem loka len zu dem entfernten Standort auftritt, der entfernte Server in der Lage ist, die Anforderungen von den Klien ten mit wenig oder keinem Verlust an Dateizustand zu bedienen.
6. Geographisches Datenreplikationssystem nach Anspruch 5,
bei dem:
der mindestens eine entfernte Server einen entfern ten primären Server und einen entfernten sekundären Ser ver aufweist;
das zweite Dateisystem ein zweites Dateisystem mit hoher Verfügbarkeit (second high availability file system (SHAFS)) ist; und
der zweite stabile Dateispeicher einen zweiten Zwei-Tor-Dateispeicher aufweist, der sowohl für den ent fernten primären, als auch für den sekundären Server zu gänglich ist.
der mindestens eine entfernte Server einen entfern ten primären Server und einen entfernten sekundären Ser ver aufweist;
das zweite Dateisystem ein zweites Dateisystem mit hoher Verfügbarkeit (second high availability file system (SHAFS)) ist; und
der zweite stabile Dateispeicher einen zweiten Zwei-Tor-Dateispeicher aufweist, der sowohl für den ent fernten primären, als auch für den sekundären Server zu gänglich ist.
7. Geographisches Datenreplikationssystem nach Anspruch 1,
bei dem der lokale Standort einen Cache (cache) umfaßt,
den das lokale Dateisystem dazu nutzt, die Anforderung
vor Anwendung der Anforderungen auf den ersten Zwei-
Tor-Dateispeicher zu befriedigen;
derart, daß der lokale Server dazu konfiguriert ist, nur diejenigen Dateianforderungen abzufangen, die durch das lokale Dateisystem auf den ersten Zwei-Tor- Dateispeicher angewendet werden.
derart, daß der lokale Server dazu konfiguriert ist, nur diejenigen Dateianforderungen abzufangen, die durch das lokale Dateisystem auf den ersten Zwei-Tor- Dateispeicher angewendet werden.
8. Geographisches Datenreplikationssystem nach Anspruch 5,
weiterhin mit:
einem durch das erste Dateisystem mit hoher Verfüg barkeit aufrechterhaltenen ersten Kennzeichen (first identifier) für jede der Dateien auf dem ersten Zwei- Tor-Dateispeicher, wobei das erste Kennzeichen durch den lokalen Server für jede der geräumten Dateien zu dem entfernten Server übertragen wird;
einem durch das zweite Dateisystem aufrechterhalte nen zweiten Kennzeichen für jede der auf dem entfernten Server replizierten, geräumten Dateien; und
eine Abbildungstabelle auf dem entfernten Server, die eine Abbildung zwischen dem ersten und dem zweiten Kennzeichen aufrechterhält, um den entfernten Server in die Lage zu versetzen, die Anforderungen von den Klien ten zu bedienen.
einem durch das erste Dateisystem mit hoher Verfüg barkeit aufrechterhaltenen ersten Kennzeichen (first identifier) für jede der Dateien auf dem ersten Zwei- Tor-Dateispeicher, wobei das erste Kennzeichen durch den lokalen Server für jede der geräumten Dateien zu dem entfernten Server übertragen wird;
einem durch das zweite Dateisystem aufrechterhalte nen zweiten Kennzeichen für jede der auf dem entfernten Server replizierten, geräumten Dateien; und
eine Abbildungstabelle auf dem entfernten Server, die eine Abbildung zwischen dem ersten und dem zweiten Kennzeichen aufrechterhält, um den entfernten Server in die Lage zu versetzen, die Anforderungen von den Klien ten zu bedienen.
9. Geographisches Datenreplikationsverfahren zur Verwendung
in einem Netzwerk mit: einem lokalen primären Server,
der so konfiguriert ist, daß auf ihm ein erstes Datei
system hoher Verfügbarkeit (first high availability file
system (FHAFS)) und ein lokales Dateisystem läuft, einem
mit dem lokalen primären Server gekoppelten lokalen se
kundären Server, der so konfiguriert ist, daß auf ihm
das lokale Dateisystem läuft und daß er auf durch den
lokalen Primären eingeleitete FHAFS-Mini-Transaktionen
antwortet, mit den lokalen Servern gekoppeltem, erstem
Zwei-Tor-Dateispeicher, mit dem die lokalen Server über
das lokale Dateisystem interagieren und mindestens einem
Klienten, der so konfiguriert ist, daß er an den lokalen
Primären lokale Dateisystemanforderungen abgibt, wobei
der lokale Primäre entsprechend dem FHAFS konfiguriert
ist, um an den lokalen Sekundären den Anwendungszustand
übertragende Mini-Transaktionen durch Checkpointing zu
übermitteln, um den lokalen Sekundären in die Lage zu
versetzen, wenn der lokale Primäre ausfällt, Operationen
des lokalen Primären entsprechend dem durch Checkpoint
ing übermittelten Anwendungszustand zu übernehmen, wobei
der lokale Sekundäre nur aktiv ist, wenn der lokale Pri
märe inaktiv ist, das Verfahren mit:
auf demjenigen des lokalen Primären und Sekundären, der aktiv ist:
Abfangen (intercepting) der lokalen Dateian forderungen;
Bestimmung, welche der lokalen Dateianforde rungen eine aus einem ersten Satz von Dateianforderun gen ist, die den Dateizustand des lokalen Dateisystems ändern wird;
Schreiben von Operationen und Daten, die zur Bedienung des ersten Satzes von Dateianforderungen er forderlich sind, in eine auf dem ersten Zwei-Tor-Datei speicher gespeicherte Protokolldatei; und
periodischer Räumung (flushing) der Protokoll datei zu einem entfernten Standort;
auf dem entfernten Standort:
unter Verwendung der Information in der Proto kolldatei Bedienung der lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand, wenn der lo kale Standort ausfällt; und
auf dem lokalen Primären, wenn er aktiv ist:
Weitergabe (passing) von Dateicheckpoints an den lokalen Sekundären in Verbindung mit den durch das FHAFS abgegebenen Mini-Transaktions-Checkpoints, um den lokalen Sekundären in die Lage zu versetzen, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianfor derungen zu vollenden und darauffolgende lokale Dateian forderungen entsprechend dem Datei- und Anwendungszu stand zu handhaben.
auf demjenigen des lokalen Primären und Sekundären, der aktiv ist:
Abfangen (intercepting) der lokalen Dateian forderungen;
Bestimmung, welche der lokalen Dateianforde rungen eine aus einem ersten Satz von Dateianforderun gen ist, die den Dateizustand des lokalen Dateisystems ändern wird;
Schreiben von Operationen und Daten, die zur Bedienung des ersten Satzes von Dateianforderungen er forderlich sind, in eine auf dem ersten Zwei-Tor-Datei speicher gespeicherte Protokolldatei; und
periodischer Räumung (flushing) der Protokoll datei zu einem entfernten Standort;
auf dem entfernten Standort:
unter Verwendung der Information in der Proto kolldatei Bedienung der lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand, wenn der lo kale Standort ausfällt; und
auf dem lokalen Primären, wenn er aktiv ist:
Weitergabe (passing) von Dateicheckpoints an den lokalen Sekundären in Verbindung mit den durch das FHAFS abgegebenen Mini-Transaktions-Checkpoints, um den lokalen Sekundären in die Lage zu versetzen, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianfor derungen zu vollenden und darauffolgende lokale Dateian forderungen entsprechend dem Datei- und Anwendungszu stand zu handhaben.
10. Geographisches Datenreplikationsverfahren nach Anspruch
9, weiterhin mit:
Detektion eines Ausfalls des lokalen Primären;
Aktivierung des lokalen Sekundären, wenn der lokale Primäre ausfällt;
nachfolgend zum Aktivierungsschritt auf dem lokalen Sekundären:
Aufbau (mounting) des lokalen Dateisystems;
Erhalten von Zeigern auf in den Dateicheck points repräsentierten, lokalen Dateisystemobjekte; und
Vollendung der Dateioperationen, die zum Zeitpunkt des Ausfalls des lokalen Primären im Gange waren.
Detektion eines Ausfalls des lokalen Primären;
Aktivierung des lokalen Sekundären, wenn der lokale Primäre ausfällt;
nachfolgend zum Aktivierungsschritt auf dem lokalen Sekundären:
Aufbau (mounting) des lokalen Dateisystems;
Erhalten von Zeigern auf in den Dateicheck points repräsentierten, lokalen Dateisystemobjekte; und
Vollendung der Dateioperationen, die zum Zeitpunkt des Ausfalls des lokalen Primären im Gange waren.
11. Geographisches Datenreplikationsverfahren nach Anspruch
9, weiterhin mit:
auf dem lokalen Primären, vor dem Dateicheckpoint- Weitergabeschritt, Eingabe einer eindeutigen Transak tions-id in die Protokolldatei entsprechend jeder der Dateisystemanforderungen derart, daß der Dateicheck point-Weitergabeschritt für eine bestimmte Dateisystem anforderung eine Weitergabe einer entsprechenden Trans aktions-id für diese Anforderung umfaßt;
auf dem lokalen Sekundären, beim Empfang des Da teicheckpoints,
Zuweisung eines der bestimmten Transaktions-id zugeordneten Zustandsobjekts; und
Quittierung des Dateicheckpoints; auf dem lokalen Primären, nach Senden des Datei checkpoints;
Aktualisierung des Zwei-Tor-Speichers entspre chend der bestimmten Dateisystemanforderung;
Eingabe einer Übergabenachricht in die Proto kolldatei, wenn die bestimmte Dateisystemanforderung er folgreich vollendet ist und anderenfalls eine Invalidi sierungsnachricht (invalidate message); und
Zurückgabe des Ergebnisses der bestimmten Da teisystemanforderung an den anfordernden Klienten; und
bei Empfang des Ergebnisses der besonderen Datei systemanforderung Sendung einer asynchronen Vergessen- Nachricht (forget Message) an den lokalen Sekundären durch den Klienten.
auf dem lokalen Primären, vor dem Dateicheckpoint- Weitergabeschritt, Eingabe einer eindeutigen Transak tions-id in die Protokolldatei entsprechend jeder der Dateisystemanforderungen derart, daß der Dateicheck point-Weitergabeschritt für eine bestimmte Dateisystem anforderung eine Weitergabe einer entsprechenden Trans aktions-id für diese Anforderung umfaßt;
auf dem lokalen Sekundären, beim Empfang des Da teicheckpoints,
Zuweisung eines der bestimmten Transaktions-id zugeordneten Zustandsobjekts; und
Quittierung des Dateicheckpoints; auf dem lokalen Primären, nach Senden des Datei checkpoints;
Aktualisierung des Zwei-Tor-Speichers entspre chend der bestimmten Dateisystemanforderung;
Eingabe einer Übergabenachricht in die Proto kolldatei, wenn die bestimmte Dateisystemanforderung er folgreich vollendet ist und anderenfalls eine Invalidi sierungsnachricht (invalidate message); und
Zurückgabe des Ergebnisses der bestimmten Da teisystemanforderung an den anfordernden Klienten; und
bei Empfang des Ergebnisses der besonderen Datei systemanforderung Sendung einer asynchronen Vergessen- Nachricht (forget Message) an den lokalen Sekundären durch den Klienten.
12. Geographisches Datenreplikationssystem nach Anspruch 9,
bei dem der entfernte Standort mindestens einen entfern
ten Server aufweist, auf dem ein zweites Dateisystem und
ein zweiter stabiler Dateispeicher laufen, weiterhin
mit:
auf dem entfernten Server
Aktualisierung des Zustandes des zweiten Da teisystems entsprechend der geräumten Protokolldatei durch Durchführung der Operationen auf dem in der ge räumten Protokolldatei repräsentierten Daten; und
nachfolgend zu einem Failover von dem lokalen zu dem entfernten Standort Bedienung der Anforderungen von den Klienten mit wenig oder keinem Verlust an Datei zustand.
auf dem entfernten Server
Aktualisierung des Zustandes des zweiten Da teisystems entsprechend der geräumten Protokolldatei durch Durchführung der Operationen auf dem in der ge räumten Protokolldatei repräsentierten Daten; und
nachfolgend zu einem Failover von dem lokalen zu dem entfernten Standort Bedienung der Anforderungen von den Klienten mit wenig oder keinem Verlust an Datei zustand.
13. Geographisches Datenreplikationssystem nach Anspruch 9,
bei dem:
der mindestens eine entfernte Server einen entfern ten primären Server und einen entfernten sekundären Server aufweist;
das zweite Dateisystem ein zweites Dateisystem ho her Verfügbarkeit (second high availability file system (SHAFS)) ist; und
der zweite stabile Dateispeicher einen zweiten Zwei-Tor-Dateispeicher aufweist, der sowohl für den ent fernten primären als auch für den sekundären Server zu gänglich ist.
der mindestens eine entfernte Server einen entfern ten primären Server und einen entfernten sekundären Server aufweist;
das zweite Dateisystem ein zweites Dateisystem ho her Verfügbarkeit (second high availability file system (SHAFS)) ist; und
der zweite stabile Dateispeicher einen zweiten Zwei-Tor-Dateispeicher aufweist, der sowohl für den ent fernten primären als auch für den sekundären Server zu gänglich ist.
14. Geographisches Datenreplikationssystem nach Anspruch 9,
weiterhin mit:
Befriedigung der Anforderungen von einem Cache durch das lokale Dateisystem vor Anwendung der Anforde rungen auf den ersten Zwei-Tor-Dateispeicher; und
Abfangen nur von solchen Dateianforderungen, die von dem lokalen Dateisystem auf den ersten Zwei-Tor- Dateispeicher angewendet werden.
Befriedigung der Anforderungen von einem Cache durch das lokale Dateisystem vor Anwendung der Anforde rungen auf den ersten Zwei-Tor-Dateispeicher; und
Abfangen nur von solchen Dateianforderungen, die von dem lokalen Dateisystem auf den ersten Zwei-Tor- Dateispeicher angewendet werden.
15. Geographisches Datenreplikationssystem nach Anspruch 14,
weiterhin mit:
an dem lokalen Standort:
in dem ersten Dateisystem hoher Verfügbarkeit Aufrechterhaltung eines ersten Kennzeichens für jede der Dateien auf dem ersten Zwei-Tor-Dateispeicher, und
Übertragung des ersten Kennzeichens an den entfernten Server für jede der geräumten Dateien; und
an dem entfernten Standort:
in dem zweiten Dateisystem Aufrechterhaltung eines zweiten Kennzeichens für jede der auf dem entfern ten Server replizierten, geräumten Dateien;
Aufrechterhaltung einer die ersten und zweiten Kennzeichen verknüpfenden (associating) Abbildungstabel le; und
unter Verwendung der Abbildungstabelle Bedie nung der Anforderungen von den Klienten, wenn ein Fail- over auf den entfernten Standort auftritt.
an dem lokalen Standort:
in dem ersten Dateisystem hoher Verfügbarkeit Aufrechterhaltung eines ersten Kennzeichens für jede der Dateien auf dem ersten Zwei-Tor-Dateispeicher, und
Übertragung des ersten Kennzeichens an den entfernten Server für jede der geräumten Dateien; und
an dem entfernten Standort:
in dem zweiten Dateisystem Aufrechterhaltung eines zweiten Kennzeichens für jede der auf dem entfern ten Server replizierten, geräumten Dateien;
Aufrechterhaltung einer die ersten und zweiten Kennzeichen verknüpfenden (associating) Abbildungstabel le; und
unter Verwendung der Abbildungstabelle Bedie nung der Anforderungen von den Klienten, wenn ein Fail- over auf den entfernten Standort auftritt.
16. Geographisches Datenreplikationssystem nach Anspruch 15,
bei dem:
das erste Kennzeichen ein beständiges lokales Kenn zeichen der geräumten Datei an dem lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei auf dem entfernten Standort ist.
das erste Kennzeichen ein beständiges lokales Kenn zeichen der geräumten Datei an dem lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei auf dem entfernten Standort ist.
17. Computerprogrammprodukt zur Bereitstellung von geogra
phischer Datenreplikation in einem Computernetzwerk, das
aufweist: einen lokalen primären Server, der so konfigu
riert ist, daß auf ihm ein erstes Dateisystem hoher Ver
fügbarkeit (first high availability file system (FHAFS))
und ein lokales Dateisystem läuft, einen mit dem lokalen
primären Server gekoppelten lokalen sekundären Server,
der so konfiguriert ist, daß auf ihm das lokale Datei
system läuft und daß er auf durch den lokalen Primären
eingeleitete FHAFS-Mini-Transaktionen antwortet, mit den
lokalen Servern gekoppelten, ersten Zwei-Tor-Dateispei
cher, mit denen die lokalen Server über das lokale Da
teisystem interagieren, und mindestens einen Klienten,
der so konfiguriert ist, daß er an den lokalen Primären
lokale Dateisystemanforderungen abgibt, wobei der lokale
Primäre entsprechend dem FHAFS konfiguriert ist, um an
den lokalen Sekundären den Anwendungszustand übertragen
de Mini-Transaktionen durch Checkpointing zu übermit
teln, um den lokalen Sekundären in die Lage zu verset
zen, wenn der lokale Primäre ausfällt, Operationen des
lokalen Primären entsprechend dem durch Checkpointing
übermittelten Anwendungszustand zu übernehmen, wobei der
lokale Sekundäre nur aktiv ist, wenn der lokale Primäre
inaktiv ist; das Computerprogrammprodukt mit einem com
puterlesbaren Speichermedium und einem darin eingebet
teten Computerprogramm-Mechanismus, der Computerpro
gramm-Mechanismus mit:
lokaler geographischer Datenreplikationssoftware, die einen lokalen Server, der derjenige von einem loka len Primären und Sekundären ist, der aktiv ist, dazu konfiguriert:
die lokalen Dateianforderungen abzufangen;
zu bestimmen, welche der lokalen Dateianfor derungen eine von einem ersten Satz von Dateianforde rungen ist, die den Dateizustand des lokalen Dateisy stems ändern wird;
in eine auf dem ersten Zwei-Tor-Dateispeicher gespeicherte Protokolldatei Operationen und Daten zu schreiben, die zur Bedienung des ersten Satzes von Da teianforderungen erforderlich sind; und
periodisch die Protokolldatei zu einem ent fernten Server zu räumen, wodurch der entfernte Server in die Lage versetzt wird, wenn der lokale Standort aus fällt, die lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand zu bedienen; und
wenn er aktiv ist, daß der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Da teicheckpoints in Verbindung mit den durch das FHAFS ab gegebenen Mini-Transaktions-Checkpoints weiterzugeben, wodurch der lokale Sekundäre in die Lage versetzt wird, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianforderungen zu vollenden und darauffolgende lokale Dateianforderungen entsprechend dem Datei- und Anwendungsstatus zu handhaben.
lokaler geographischer Datenreplikationssoftware, die einen lokalen Server, der derjenige von einem loka len Primären und Sekundären ist, der aktiv ist, dazu konfiguriert:
die lokalen Dateianforderungen abzufangen;
zu bestimmen, welche der lokalen Dateianfor derungen eine von einem ersten Satz von Dateianforde rungen ist, die den Dateizustand des lokalen Dateisy stems ändern wird;
in eine auf dem ersten Zwei-Tor-Dateispeicher gespeicherte Protokolldatei Operationen und Daten zu schreiben, die zur Bedienung des ersten Satzes von Da teianforderungen erforderlich sind; und
periodisch die Protokolldatei zu einem ent fernten Server zu räumen, wodurch der entfernte Server in die Lage versetzt wird, wenn der lokale Standort aus fällt, die lokalen Dateianforderungen mit wenig oder keinem Verlust an Dateizustand zu bedienen; und
wenn er aktiv ist, daß der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Da teicheckpoints in Verbindung mit den durch das FHAFS ab gegebenen Mini-Transaktions-Checkpoints weiterzugeben, wodurch der lokale Sekundäre in die Lage versetzt wird, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianforderungen zu vollenden und darauffolgende lokale Dateianforderungen entsprechend dem Datei- und Anwendungsstatus zu handhaben.
18. Computerprogrammprodukt nach Anspruch 17, bei dem:
wenn der lokale Standort einen Cache aufweist, den das erste Dateisystem dazu nutzt, die Anforderungen vor Anwendung der Anforderungen auf den ersten stabilen Da teispeicher zu befriedigen, der lokale Server dazu kon figuriert ist, nur solche Anforderungen abzufangen, die durch das erste Dateisystem auf den ersten stabilen Da teispeicher angewendet werden.
wenn der lokale Standort einen Cache aufweist, den das erste Dateisystem dazu nutzt, die Anforderungen vor Anwendung der Anforderungen auf den ersten stabilen Da teispeicher zu befriedigen, der lokale Server dazu kon figuriert ist, nur solche Anforderungen abzufangen, die durch das erste Dateisystem auf den ersten stabilen Da teispeicher angewendet werden.
19. Computerprogrammprodukt nach Anspruch 17, bei dem:
der lokale Server dazu konfiguriert ist, an den entfernten Server ein für jede der Dateien auf dem er sten stabilen Dateispeicher aufrechterhaltenes erstes Kennzeichen für jede der geräumten Dateien zu übertra gen; weiterhin mit
entfernter geographischer Datenreplikationssoft ware, die den entfernten Server dazu konfiguriert, auf dem entfernten Server eine Abbildungstabelle aufrechtzu erhalten, die das erste Kennzeichen auf ein zweites Kennzeichen, das durch ein auf dem entfernten Server laufendes zweites Dateisystem aufrechterhalten wird, für jede der auf dem entfernten Server replizierten, geräum ten Dateien abzubilden, wodurch der entfernte Server in die Lage versetzt wird, die Anforderungen von den Klien ten zu bedienen.
der lokale Server dazu konfiguriert ist, an den entfernten Server ein für jede der Dateien auf dem er sten stabilen Dateispeicher aufrechterhaltenes erstes Kennzeichen für jede der geräumten Dateien zu übertra gen; weiterhin mit
entfernter geographischer Datenreplikationssoft ware, die den entfernten Server dazu konfiguriert, auf dem entfernten Server eine Abbildungstabelle aufrechtzu erhalten, die das erste Kennzeichen auf ein zweites Kennzeichen, das durch ein auf dem entfernten Server laufendes zweites Dateisystem aufrechterhalten wird, für jede der auf dem entfernten Server replizierten, geräum ten Dateien abzubilden, wodurch der entfernte Server in die Lage versetzt wird, die Anforderungen von den Klien ten zu bedienen.
20. Computerprogrammprodukt nach Anspruch 19, bei dem:
das erste Kennzeichen ein beständiges lokales Kenn zeichen der geräumten Datei am lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei auf dem entfernten Standort ist.
das erste Kennzeichen ein beständiges lokales Kenn zeichen der geräumten Datei am lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei auf dem entfernten Standort ist.
21. Computerprogrammprodukt nach Anspruch 19, bei dem:
das erste Kennzeichen ein beständiges lokales Ver zeichniskennzeichen eines Verzeichnisses auf dem lokalen Standort aufweist, in das die geräumte Datei gespeichert wird, und ein beständiges, lokales Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen auf dem lokalen Standort zugeordnet ist; und
das zweite Kennzeichen ein entferntes Verzeichnis kennzeichen eines Verzeichnisses auf dem entfernten Standort aufweist, in das die geräumte Datei gespeichert wird, und ein entferntes Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen auf dem ent fernten Standort zugeordnet ist.
das erste Kennzeichen ein beständiges lokales Ver zeichniskennzeichen eines Verzeichnisses auf dem lokalen Standort aufweist, in das die geräumte Datei gespeichert wird, und ein beständiges, lokales Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen auf dem lokalen Standort zugeordnet ist; und
das zweite Kennzeichen ein entferntes Verzeichnis kennzeichen eines Verzeichnisses auf dem entfernten Standort aufweist, in das die geräumte Datei gespeichert wird, und ein entferntes Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen auf dem ent fernten Standort zugeordnet ist.
22. Geographisches Datenreplikationssystem mit:
einem lokalen Server, der derjenige von einem loka len primären Server und einem sekundären Server ist, der dazu aktiv konfiguriert ist, an ein lokales Dateisystem gerichtete lokale Dateianforderungen abzufangen und zu bestimmen, welche der lokalen Dateianforderungen eine aus einem ersten Satz von Dateianforderungen ist, die den Dateizustand des lokalen Dateisystems ändern wird; und
einer für den lokalen Primären und den lokalen Sekundären zugänglichen, beständigen Protokolldatei, in die der lokale Sever Operationen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server dazu konfigu riert ist, die Protokolldatei periodisch zu einem ent fernten Server zu räumen, was den entfernten Server in die Lage versetzt, wenn der lokale Server ausfällt, die lokalen Dateianforderungen mit wenig oder keinem Ver lust an Dateizustand zu bedienen;
derart, daß, wenn der lokale Primäre aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints in Verbindung mit durch ein auf dem lokalen Primären laufendes, erstes Dateisystem hoher Verfügbarkeit (FHAFS) abgegebenen Mini-Transaktions-Checkpoints, weiterzugeben, wodurch der lokale Sekundäre in die Lage versetzt wird, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianfor derungen zu vollenden und nachfolgende lokale Dateian forderungen entsprechend dem Datei- und Anwendungszu stand zu handhaben.
einem lokalen Server, der derjenige von einem loka len primären Server und einem sekundären Server ist, der dazu aktiv konfiguriert ist, an ein lokales Dateisystem gerichtete lokale Dateianforderungen abzufangen und zu bestimmen, welche der lokalen Dateianforderungen eine aus einem ersten Satz von Dateianforderungen ist, die den Dateizustand des lokalen Dateisystems ändern wird; und
einer für den lokalen Primären und den lokalen Sekundären zugänglichen, beständigen Protokolldatei, in die der lokale Sever Operationen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server dazu konfigu riert ist, die Protokolldatei periodisch zu einem ent fernten Server zu räumen, was den entfernten Server in die Lage versetzt, wenn der lokale Server ausfällt, die lokalen Dateianforderungen mit wenig oder keinem Ver lust an Dateizustand zu bedienen;
derart, daß, wenn der lokale Primäre aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints in Verbindung mit durch ein auf dem lokalen Primären laufendes, erstes Dateisystem hoher Verfügbarkeit (FHAFS) abgegebenen Mini-Transaktions-Checkpoints, weiterzugeben, wodurch der lokale Sekundäre in die Lage versetzt wird, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianfor derungen zu vollenden und nachfolgende lokale Dateian forderungen entsprechend dem Datei- und Anwendungszu stand zu handhaben.
23. Geographisches Datenreplikationsverfahren mit:
auf einem lokalen Server, der derjenige eines lokalen primären Servers und eines sekundären Servers ist, der aktiv ist:
Abfangen von an ein lokales Dateisystem ge richteten lokalen Dateianforderungen;
Bestimmung, welche der lokalen Dateianforde rungen eine von einem ersten Satz von Dateianforderun gen ist, die den Dateizustand des lokalen Dateisystems ändern wird;
Schreiben von Operationen und Daten, die zur Bedienung des ersten Satzes von Dateianforderungen er forderlich sind, in eine für den lokalen Primären und den lokalen Sekundären zugängliche Protokolldatei; und
periodische Räumung der Protokolldatei zu einem entfernten Server;
auf dem entfernten Server:
unter Verwendung der Information in der Proto kolldatei, Bedienung der lokalen Dateianforderungen mit wenig oder keinem Verlust von Dateizustand, wenn der lo kale Server ausfällt; und
auf dem lokalen Primären, wenn er aktiv ist:
Weitergabe von Dateicheckpoints an den lokalen Serkundären in Verbindung mit den durch ein erstes Da teisystem hoher Verfügbarkeit (FHAFS), das auf dem loka len Primären läuft, abgegebenen Mini-Transaktions- Checkpoints, was den lokalen Sekundären in die Lage ver setzt, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianforderungen zu vollenden und nachfolgende lokale Dateianforderungen entsprechend dem Datei- und Anwendungszustand zu handhaben.
auf einem lokalen Server, der derjenige eines lokalen primären Servers und eines sekundären Servers ist, der aktiv ist:
Abfangen von an ein lokales Dateisystem ge richteten lokalen Dateianforderungen;
Bestimmung, welche der lokalen Dateianforde rungen eine von einem ersten Satz von Dateianforderun gen ist, die den Dateizustand des lokalen Dateisystems ändern wird;
Schreiben von Operationen und Daten, die zur Bedienung des ersten Satzes von Dateianforderungen er forderlich sind, in eine für den lokalen Primären und den lokalen Sekundären zugängliche Protokolldatei; und
periodische Räumung der Protokolldatei zu einem entfernten Server;
auf dem entfernten Server:
unter Verwendung der Information in der Proto kolldatei, Bedienung der lokalen Dateianforderungen mit wenig oder keinem Verlust von Dateizustand, wenn der lo kale Server ausfällt; und
auf dem lokalen Primären, wenn er aktiv ist:
Weitergabe von Dateicheckpoints an den lokalen Serkundären in Verbindung mit den durch ein erstes Da teisystem hoher Verfügbarkeit (FHAFS), das auf dem loka len Primären läuft, abgegebenen Mini-Transaktions- Checkpoints, was den lokalen Sekundären in die Lage ver setzt, wenn der lokale Primäre ausfällt, unvollendete lokale Dateianforderungen zu vollenden und nachfolgende lokale Dateianforderungen entsprechend dem Datei- und Anwendungszustand zu handhaben.
24. Computerprogrammprodukt zur Bereitstellung geographi
scher Datenreplikation, das Computerprogrammprodukt mit
einem computerlesbaren Speichermedium und einem darin
eingebetteten Computerprogramm-Mechanismus, der Compu
terprogramm-Mechanismus mit:
lokaler geographischer Datenreplikationssoftware, die einen lokalen Server, der dejenige von einem lokalen Primären und einem lokalen Sekundären ist, der aktiv ist, dazu konfiguriert:
an ein auf dem lokalen Server laufendes loka les Dateisystem gerichtete lokale Dateianforderungen abzufangen;
zu bestimmen, welche der lokalen Dateianfor derungen eine von einem ersten Satz von Dateianforde rungen ist, die den Zustand des lokalen Dateisystems ändern wird;
in eine für den lokalen Primären und den lokalen Sekundären zugängliche, beständige Protokollda tei Operationen und Daten zu schreiben, die zur Bedie nung des ersten Satzes von Dateianforderungen erforder lich sind; und
periodisch die Protokolldatei zu einem ent fernten Server zu räumen, was den entfernten Server in die Lage versetzt, wenn der lokale Server ausfällt, die lokalen Dateianforderungen mit wenig oder keinem Ver lust von Dateizustand zu bedienen; und
wenn er aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints weiterzugeben in Verbindung mit Mini- Transaktions-Checkpoints, die durch ein auf dem lokalen Primären laufendes erstes Dateisystem hoher Verfügbar keit (FHAFS) abgegeben werden, was den lokalen Sekundä ren in die Lage versetzt, wenn der lokale Primäre aus fällt, unvollendete lokale Dateianforderungen zu voll enden und nachfolgende lokale Dateianforderungen ent sprechend dem Datei- und Anwendungszustand zu handha ben.
lokaler geographischer Datenreplikationssoftware, die einen lokalen Server, der dejenige von einem lokalen Primären und einem lokalen Sekundären ist, der aktiv ist, dazu konfiguriert:
an ein auf dem lokalen Server laufendes loka les Dateisystem gerichtete lokale Dateianforderungen abzufangen;
zu bestimmen, welche der lokalen Dateianfor derungen eine von einem ersten Satz von Dateianforde rungen ist, die den Zustand des lokalen Dateisystems ändern wird;
in eine für den lokalen Primären und den lokalen Sekundären zugängliche, beständige Protokollda tei Operationen und Daten zu schreiben, die zur Bedie nung des ersten Satzes von Dateianforderungen erforder lich sind; und
periodisch die Protokolldatei zu einem ent fernten Server zu räumen, was den entfernten Server in die Lage versetzt, wenn der lokale Server ausfällt, die lokalen Dateianforderungen mit wenig oder keinem Ver lust von Dateizustand zu bedienen; und
wenn er aktiv ist, der lokale Primäre dazu konfiguriert ist, an den lokalen sekundären Server Dateicheckpoints weiterzugeben in Verbindung mit Mini- Transaktions-Checkpoints, die durch ein auf dem lokalen Primären laufendes erstes Dateisystem hoher Verfügbar keit (FHAFS) abgegeben werden, was den lokalen Sekundä ren in die Lage versetzt, wenn der lokale Primäre aus fällt, unvollendete lokale Dateianforderungen zu voll enden und nachfolgende lokale Dateianforderungen ent sprechend dem Datei- und Anwendungszustand zu handha ben.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/087,261 US6144999A (en) | 1998-05-29 | 1998-05-29 | Method and apparatus for file system disaster recovery |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19924900A1 true DE19924900A1 (de) | 2000-02-17 |
Family
ID=22204095
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19924900A Withdrawn DE19924900A1 (de) | 1998-05-29 | 1999-05-31 | Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen |
Country Status (3)
Country | Link |
---|---|
US (1) | US6144999A (de) |
DE (1) | DE19924900A1 (de) |
GB (1) | GB2341958B (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002021275A1 (en) * | 2000-09-06 | 2002-03-14 | Unisys Corporation | Method and apparatus for ensuring data integrity |
Families Citing this family (155)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6029168A (en) * | 1998-01-23 | 2000-02-22 | Tricord Systems, Inc. | Decentralized file mapping in a striped network file system in a distributed computing environment |
US7047300B1 (en) | 1998-02-10 | 2006-05-16 | Sprint Communications Company L.P. | Survivable and scalable data system and method for computer networks |
US6963914B1 (en) * | 1998-09-01 | 2005-11-08 | Lucent Technologies Inc. | Method and apparatus for retrieving a network file using a logical reference |
US6411991B1 (en) * | 1998-09-25 | 2002-06-25 | Sprint Communications Company L.P. | Geographic data replication system and method for a network |
US8010627B1 (en) | 1998-09-25 | 2011-08-30 | Sprint Communications Company L.P. | Virtual content publishing system |
US6397351B1 (en) * | 1998-09-28 | 2002-05-28 | International Business Machines Corporation | Method and apparatus for rapid data restoration including on-demand output of sorted logged changes |
US6389550B1 (en) * | 1998-12-23 | 2002-05-14 | Ncr Corporation | High availability protocol computing and method |
US6516327B1 (en) * | 1998-12-24 | 2003-02-04 | International Business Machines Corporation | System and method for synchronizing data in multiple databases |
US6389552B1 (en) * | 1998-12-31 | 2002-05-14 | At&T Corp | Methods and systems for remote electronic vaulting |
JP3763992B2 (ja) * | 1999-03-30 | 2006-04-05 | 富士通株式会社 | データ処理装置及び記録媒体 |
US6775830B1 (en) * | 1999-09-24 | 2004-08-10 | Hitachi, Ltd. | Computer system and a program install method thereof |
US9066113B1 (en) | 1999-10-19 | 2015-06-23 | International Business Machines Corporation | Method for ensuring reliable playout in a DMD system |
TW454120B (en) * | 1999-11-11 | 2001-09-11 | Miralink Corp | Flexible remote data mirroring |
US6418449B1 (en) * | 2000-01-06 | 2002-07-09 | Inventec Corporation | Method of cloning the file system of a window web operating system by using a bitmap file |
US6636988B1 (en) | 2000-03-03 | 2003-10-21 | International Business Machines Corporation | Application of automation and procedures to enable high-speed recovery and relocation of computer workloads |
US6654794B1 (en) * | 2000-03-30 | 2003-11-25 | International Business Machines Corporation | Method, data processing system and program product that provide an internet-compatible network file system driver |
US6578041B1 (en) * | 2000-06-30 | 2003-06-10 | Microsoft Corporation | High speed on-line backup when using logical log operations |
US7730213B2 (en) * | 2000-12-18 | 2010-06-01 | Oracle America, Inc. | Object-based storage device with improved reliability and fast crash recovery |
US6820097B2 (en) | 2001-01-16 | 2004-11-16 | Sepaton, Inc. | System and method for cross-platform update propagation |
WO2002057957A1 (en) * | 2001-01-16 | 2002-07-25 | Sangate Systems, Inc. | System and method for cross-platform update propagation |
US7260785B2 (en) | 2001-01-29 | 2007-08-21 | International Business Machines Corporation | Method and system for object retransmission without a continuous network connection in a digital media distribution system |
US7689598B2 (en) * | 2001-02-15 | 2010-03-30 | International Business Machines Corporation | Method and system for file system synchronization between a central site and a plurality of remote sites |
US6985915B2 (en) | 2001-02-28 | 2006-01-10 | Kiran Somalwar | Application independent write monitoring method for fast backup and synchronization of files |
US6847983B2 (en) | 2001-02-28 | 2005-01-25 | Kiran Somalwar | Application independent write monitoring method for fast backup and synchronization of open files |
US20020178439A1 (en) * | 2001-04-02 | 2002-11-28 | Rich L. Scott | Method and system for providing a programming interface for loading and saving archives in enterprise applications |
TW523667B (en) * | 2001-05-31 | 2003-03-11 | Taiwan Semiconductor Mfg | Shared directory management system and method of the same |
US7640582B2 (en) | 2003-04-16 | 2009-12-29 | Silicon Graphics International | Clustered filesystem for mix of trusted and untrusted nodes |
US20040139125A1 (en) | 2001-06-05 | 2004-07-15 | Roger Strassburg | Snapshot copy of data volume during data access |
US7617292B2 (en) | 2001-06-05 | 2009-11-10 | Silicon Graphics International | Multi-class heterogeneous clients in a clustered filesystem |
US6643654B1 (en) | 2001-06-25 | 2003-11-04 | Network Appliance, Inc. | System and method for representing named data streams within an on-disk structure of a file system |
US9659292B1 (en) * | 2001-08-30 | 2017-05-23 | EMC IP Holding Company LLC | Storage-based replication of e-commerce transactions in real time |
US6477051B1 (en) * | 2001-09-20 | 2002-11-05 | Hewlett-Packard Company | Socket activation interlock |
US6910075B2 (en) * | 2001-11-14 | 2005-06-21 | Emc Corporation | Dynamic RDF groups |
US8312117B1 (en) * | 2001-11-15 | 2012-11-13 | Unisys Corporation | Dialog recovery in a distributed computer system |
US7007152B2 (en) * | 2001-12-28 | 2006-02-28 | Storage Technology Corporation | Volume translation apparatus and method |
US7024429B2 (en) * | 2002-01-31 | 2006-04-04 | Nextpage,Inc. | Data replication based upon a non-destructive data model |
US6968345B1 (en) * | 2002-02-27 | 2005-11-22 | Network Appliance, Inc. | Technique to enable support for symbolic link access by windows clients |
US7467167B2 (en) * | 2002-03-19 | 2008-12-16 | Network Appliance, Inc. | System and method for coalescing a plurality of snapshots |
US7404145B1 (en) | 2002-03-28 | 2008-07-22 | Emc Corporation | Generic mechanism for reporting on backups |
US7350149B1 (en) * | 2002-03-28 | 2008-03-25 | Emc Corporation | Backup reporting framework graphical user interface |
US7228353B1 (en) * | 2002-03-28 | 2007-06-05 | Emc Corporation | Generating and launching remote method invocation servers for individual client applications |
US20030212761A1 (en) * | 2002-05-10 | 2003-11-13 | Microsoft Corporation | Process kernel |
WO2003096209A1 (en) * | 2002-05-10 | 2003-11-20 | Microsoft Corporation | Cooperation of concurrent, distributed networks of resources |
US20040068523A1 (en) * | 2002-10-07 | 2004-04-08 | Keith Robert Olan | Method and system for full asynchronous master-to-master file synchronization |
US7707184B1 (en) * | 2002-10-09 | 2010-04-27 | Netapp, Inc. | System and method for snapshot full backup and hard recovery of a database |
US7814050B2 (en) * | 2002-10-22 | 2010-10-12 | Brocade Communications Systems, Inc. | Disaster recovery |
JP4186602B2 (ja) * | 2002-12-04 | 2008-11-26 | 株式会社日立製作所 | ジャーナルログを利用した更新データ書込方法 |
JP2004213435A (ja) | 2003-01-07 | 2004-07-29 | Hitachi Ltd | 記憶装置システム |
CA2419883A1 (en) * | 2003-02-26 | 2004-08-26 | Ibm Canada Limited - Ibm Canada Limitee | Discriminatory replay of log files during table space recovery in a database management system |
JP2004280283A (ja) * | 2003-03-13 | 2004-10-07 | Hitachi Ltd | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 |
JP2004302512A (ja) * | 2003-03-28 | 2004-10-28 | Hitachi Ltd | クラスタコンピューティングシステム、および、そのフェールオーバー方法 |
US7523139B1 (en) | 2003-05-02 | 2009-04-21 | Symantec Operating Corporation | Volume server and volume owner communication protocol in a distributed storage management system |
US7149919B2 (en) * | 2003-05-15 | 2006-12-12 | Hewlett-Packard Development Company, L.P. | Disaster recovery system with cascaded resynchronization |
US7194655B2 (en) * | 2003-06-12 | 2007-03-20 | International Business Machines Corporation | Method and system for autonomously rebuilding a failed server and a computer system utilizing the same |
US7043665B2 (en) * | 2003-06-18 | 2006-05-09 | International Business Machines Corporation | Method, system, and program for handling a failover to a remote storage location |
JP4349871B2 (ja) * | 2003-09-09 | 2009-10-21 | 株式会社日立製作所 | ファイル共有装置及びファイル共有装置間のデータ移行方法 |
US7330859B2 (en) * | 2003-09-10 | 2008-02-12 | International Business Machines Corporation | Database backup system using data and user-defined routines replicators for maintaining a copy of database on a secondary server |
US20050071391A1 (en) * | 2003-09-29 | 2005-03-31 | International Business Machines Corporation | High availability data replication set up using external backup and restore |
US7284018B1 (en) * | 2003-10-15 | 2007-10-16 | Sun Microsystems, Inc. | Logless transaction coordination |
US7287078B2 (en) * | 2003-10-31 | 2007-10-23 | Hewlett-Packard Development Company, L.P. | Restoration of lost peer-to-peer offline transaction records |
US20050125486A1 (en) * | 2003-11-20 | 2005-06-09 | Microsoft Corporation | Decentralized operating system |
US6859811B1 (en) * | 2004-01-15 | 2005-02-22 | Oracle International Corporation | Cluster database with remote data mirroring |
US7299378B2 (en) | 2004-01-15 | 2007-11-20 | Oracle International Corporation | Geographically distributed clusters |
JP4476683B2 (ja) * | 2004-04-28 | 2010-06-09 | 株式会社日立製作所 | データ処理システム |
US7370163B2 (en) * | 2004-05-03 | 2008-05-06 | Gemini Storage | Adaptive cache engine for storage area network including systems and methods related thereto |
US8185663B2 (en) * | 2004-05-11 | 2012-05-22 | Hewlett-Packard Development Company, L.P. | Mirroring storage interface |
JP2006004031A (ja) * | 2004-06-16 | 2006-01-05 | Hitachi Ltd | データ処理方法およびシステム並びにストレージ装置方法およびその処理プログラム |
US7467267B1 (en) * | 2004-07-23 | 2008-12-16 | Sprint Communications Company L.P. | Method and system for backing up or restoring data in remote devices over a communications network |
US8122280B2 (en) | 2004-08-26 | 2012-02-21 | Open Invention Network, Llc | Method and system for providing high availability to computer applications |
US7680839B1 (en) * | 2004-09-30 | 2010-03-16 | Symantec Operating Corporation | System and method for resynchronizing mirrored volumes |
US7412576B2 (en) * | 2004-12-08 | 2008-08-12 | Hitachi, Ltd. | Remote copy system having multiple data centers |
US9020887B2 (en) | 2004-12-21 | 2015-04-28 | Proofpoint, Inc. | Managing the status of documents in a distributed storage system |
US8572431B2 (en) * | 2005-02-23 | 2013-10-29 | Barclays Capital Inc. | Disaster recovery framework |
US7885817B2 (en) * | 2005-03-08 | 2011-02-08 | Microsoft Corporation | Easy generation and automatic training of spoken dialog systems using text-to-speech |
US7734471B2 (en) | 2005-03-08 | 2010-06-08 | Microsoft Corporation | Online learning for dialog systems |
US7707131B2 (en) * | 2005-03-08 | 2010-04-27 | Microsoft Corporation | Thompson strategy based online reinforcement learning system for action selection |
US9195397B2 (en) | 2005-04-20 | 2015-11-24 | Axxana (Israel) Ltd. | Disaster-proof data recovery |
EP2395432B1 (de) * | 2005-04-20 | 2013-07-24 | Axxana (Israel) Ltd. | Ferndatenspiegelsystem |
US8417782B2 (en) * | 2005-07-14 | 2013-04-09 | Yahoo! Inc. | Universal calendar event handling |
US7631045B2 (en) | 2005-07-14 | 2009-12-08 | Yahoo! Inc. | Content router asynchronous exchange |
US7849199B2 (en) | 2005-07-14 | 2010-12-07 | Yahoo ! Inc. | Content router |
US8112549B2 (en) | 2005-07-14 | 2012-02-07 | Yahoo! Inc. | Alert mechanism for notifying multiple user devices sharing a connected-data-set |
US7788352B2 (en) | 2005-07-14 | 2010-08-31 | Yahoo! Inc. | System and method for servicing a user device |
US7623515B2 (en) | 2005-07-14 | 2009-11-24 | Yahoo! Inc. | Content router notification |
US20070016632A1 (en) * | 2005-07-14 | 2007-01-18 | Yahoo! Inc. | System and method for synchronizing between a user device and a server in a communication network |
US7698593B2 (en) * | 2005-08-15 | 2010-04-13 | Microsoft Corporation | Data protection management on a clustered server |
US8752049B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and computer readable medium for providing checkpointing to windows application groups |
US8195722B1 (en) * | 2008-12-15 | 2012-06-05 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
US8082468B1 (en) | 2008-12-15 | 2011-12-20 | Open Invention Networks, Llc | Method and system for providing coordinated checkpointing to a group of independent computer applications |
US7496609B2 (en) * | 2005-09-01 | 2009-02-24 | Microsoft Corporation | Dirty shutdown recovery of file system filters |
US7870288B2 (en) * | 2005-10-28 | 2011-01-11 | Yahoo! Inc. | Sharing data in scalable software blade architecture |
US7779157B2 (en) * | 2005-10-28 | 2010-08-17 | Yahoo! Inc. | Recovering a blade in scalable software blade architecture |
US7873696B2 (en) * | 2005-10-28 | 2011-01-18 | Yahoo! Inc. | Scalable software blade architecture |
US8024290B2 (en) | 2005-11-14 | 2011-09-20 | Yahoo! Inc. | Data synchronization and device handling |
US8065680B2 (en) | 2005-11-15 | 2011-11-22 | Yahoo! Inc. | Data gateway for jobs management based on a persistent job table and a server table |
US20070162516A1 (en) * | 2005-12-30 | 2007-07-12 | Microsoft Corporation | Computing asynchronous transaction log replication progress based on file change notifications |
US9367832B2 (en) | 2006-01-04 | 2016-06-14 | Yahoo! Inc. | Synchronizing image data among applications and devices |
US20070220302A1 (en) * | 2006-02-28 | 2007-09-20 | Cline Brian G | Session failover management in a high-availability server cluster environment |
US9015520B2 (en) | 2006-06-29 | 2015-04-21 | Dssdr, Llc | Data transfer and recovery |
US7487383B2 (en) | 2006-06-29 | 2009-02-03 | Dssdr, Llc | Data transfer and recovery process |
US8990613B2 (en) | 2006-06-29 | 2015-03-24 | Dssdr, Llc | Data transfer and recovery |
US8949383B1 (en) * | 2006-11-21 | 2015-02-03 | Cisco Technology, Inc. | Volume hierarchy download in a storage area network |
US8090792B2 (en) * | 2007-03-08 | 2012-01-03 | Nec Laboratories America, Inc. | Method and system for a self managing and scalable grid storage |
US7925629B2 (en) * | 2007-03-28 | 2011-04-12 | Netapp, Inc. | Write ordering style asynchronous replication utilizing a loosely-accurate global clock |
US8290899B2 (en) * | 2007-03-28 | 2012-10-16 | Netapp, Inc. | Group stamping style asynchronous replication utilizing a loosely-accurate global clock |
US8150800B2 (en) | 2007-03-28 | 2012-04-03 | Netapp, Inc. | Advanced clock synchronization technique |
US7757111B2 (en) | 2007-04-05 | 2010-07-13 | International Business Machines Corporation | Method and system for insuring data integrity in anticipation of a disaster |
US8015427B2 (en) * | 2007-04-23 | 2011-09-06 | Netapp, Inc. | System and method for prioritization of clock rates in a multi-core processor |
US7895474B2 (en) * | 2007-05-03 | 2011-02-22 | International Business Machines Corporation | Recovery and restart of a batch application |
US7870169B2 (en) * | 2007-06-29 | 2011-01-11 | International Business Machines Corporation | Method for enabling traceability and recovery from errors during migration of software applications |
WO2009047751A2 (en) * | 2007-10-08 | 2009-04-16 | Axxana (Israel) Ltd. | Fast data recovery system |
JP5153315B2 (ja) * | 2007-12-19 | 2013-02-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ルートファイルシステムを管理するシステム及び方法 |
WO2009141752A2 (en) * | 2008-05-19 | 2009-11-26 | Axxana (Israel) Ltd. | Resilient data storage in the presence of replication faults and rolling disasters |
US7840730B2 (en) * | 2008-06-27 | 2010-11-23 | Microsoft Corporation | Cluster shared volumes |
US8099571B1 (en) | 2008-08-06 | 2012-01-17 | Netapp, Inc. | Logical block replication with deduplication |
US8775394B2 (en) * | 2008-09-11 | 2014-07-08 | Netapp, Inc. | Transactional failover of data sets |
US9158579B1 (en) | 2008-11-10 | 2015-10-13 | Netapp, Inc. | System having operation queues corresponding to operation execution time |
US8281317B1 (en) | 2008-12-15 | 2012-10-02 | Open Invention Network Llc | Method and computer readable medium for providing checkpointing to windows application groups |
US8752048B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and system for providing checkpointing to windows application groups |
US8539488B1 (en) | 2009-04-10 | 2013-09-17 | Open Invention Network, Llc | System and method for application isolation with live migration |
US8904004B2 (en) * | 2009-04-10 | 2014-12-02 | Open Invention Network, Llc | System and method for maintaining mappings between application resources inside and outside isolated environments |
US8880473B1 (en) | 2008-12-15 | 2014-11-04 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
US8464256B1 (en) | 2009-04-10 | 2013-06-11 | Open Invention Network, Llc | System and method for hierarchical interception with isolated environments |
US8341631B2 (en) | 2009-04-10 | 2012-12-25 | Open Invention Network Llc | System and method for application isolation |
US8782670B2 (en) | 2009-04-10 | 2014-07-15 | Open Invention Network, Llc | System and method for application isolation |
WO2010076755A2 (en) * | 2009-01-05 | 2010-07-08 | Axxana (Israel) Ltd | Disaster-proof storage unit having transmission capabilities |
US9577893B1 (en) | 2009-04-10 | 2017-02-21 | Open Invention Network Llc | System and method for cached streaming application isolation |
US9058599B1 (en) | 2009-04-10 | 2015-06-16 | Open Invention Network, Llc | System and method for usage billing of hosted applications |
US8418236B1 (en) | 2009-04-10 | 2013-04-09 | Open Invention Network Llc | System and method for streaming application isolation |
US10419504B1 (en) | 2009-04-10 | 2019-09-17 | Open Invention Network Llc | System and method for streaming application isolation |
US11538078B1 (en) | 2009-04-10 | 2022-12-27 | International Business Machines Corporation | System and method for usage billing of hosted applications |
US8555360B1 (en) | 2009-04-10 | 2013-10-08 | Open Invention Network Llc | System and method for on-line and off-line streaming application isolation |
US8655848B1 (en) | 2009-04-30 | 2014-02-18 | Netapp, Inc. | Unordered idempotent logical replication operations |
US8321380B1 (en) | 2009-04-30 | 2012-11-27 | Netapp, Inc. | Unordered idempotent replication operations |
US8671072B1 (en) | 2009-09-14 | 2014-03-11 | Netapp, Inc. | System and method for hijacking inodes based on replication operations received in an arbitrary order |
US8473690B1 (en) | 2009-10-30 | 2013-06-25 | Netapp, Inc. | Using logical block addresses with generation numbers as data fingerprints to provide cache coherency |
US8799367B1 (en) | 2009-10-30 | 2014-08-05 | Netapp, Inc. | Using logical block addresses with generation numbers as data fingerprints for network deduplication |
US9021124B2 (en) | 2009-12-02 | 2015-04-28 | Axxana (Israel) Ltd. | Distributed intelligent network |
US8751598B1 (en) * | 2010-11-03 | 2014-06-10 | Netapp, Inc. | Method and system for implementing an unordered delivery of data between nodes in a clustered storage system |
US9971656B2 (en) * | 2010-12-13 | 2018-05-15 | International Business Machines Corporation | Instant data restoration |
US8656211B2 (en) | 2011-02-18 | 2014-02-18 | Ca, Inc. | Avoiding failover identifier conflicts |
US20130138615A1 (en) | 2011-11-29 | 2013-05-30 | International Business Machines Corporation | Synchronizing updates across cluster filesystems |
US8943372B2 (en) | 2012-03-30 | 2015-01-27 | International Business Machines Corporation | Systems and methods for open and extensible integration of management domains in computation and orchestration of resource placement |
WO2015056169A1 (en) | 2013-10-16 | 2015-04-23 | Axxana (Israel) Ltd. | Zero-transaction-loss recovery for database systems |
US9830329B2 (en) * | 2014-01-15 | 2017-11-28 | W. Anthony Mason | Methods and systems for data storage |
US10229105B1 (en) * | 2014-09-30 | 2019-03-12 | EMC IP Holding Company LLC | Mobile log data parsing |
US9697227B2 (en) | 2014-10-27 | 2017-07-04 | Cohesity, Inc. | Concurrent access and transactions in a distributed file system |
US9612925B1 (en) * | 2014-12-12 | 2017-04-04 | Jpmorgan Chase Bank, N.A. | Method and system for implementing a distributed digital application architecture |
CN106294357B (zh) * | 2015-05-14 | 2019-07-09 | 阿里巴巴集团控股有限公司 | 数据处理方法和流计算系统 |
US10379958B2 (en) | 2015-06-03 | 2019-08-13 | Axxana (Israel) Ltd. | Fast archiving for database systems |
US10592326B2 (en) | 2017-03-08 | 2020-03-17 | Axxana (Israel) Ltd. | Method and apparatus for data loss assessment |
US10942974B2 (en) | 2017-10-20 | 2021-03-09 | Bank Of America Corporation | System for synchronous document captures into an asynchronous archive and document-level archiving reconciliation |
US10795867B2 (en) | 2017-11-06 | 2020-10-06 | International Business Machines Corporation | Determining available remote storages in a network to use to replicate a file based on a geographical requirement with respect to the file |
CN112749123A (zh) * | 2019-10-30 | 2021-05-04 | 伊姆西Ip控股有限责任公司 | 用于管理文件系统的方法、设备和计算机程序产品 |
CN111614753B (zh) * | 2020-05-20 | 2023-04-18 | 京东科技控股股份有限公司 | 用于发送日志的方法、系统和装置 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5434994A (en) * | 1994-05-23 | 1995-07-18 | International Business Machines Corporation | System and method for maintaining replicated data coherency in a data processing system |
US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
US5832514A (en) * | 1996-06-26 | 1998-11-03 | Microsoft Corporation | System and method for discovery based data recovery in a store and forward replication process |
US6052718A (en) * | 1997-01-07 | 2000-04-18 | Sightpath, Inc | Replica routing |
US6047289A (en) * | 1997-11-07 | 2000-04-04 | Novell, Inc. | Method and apparatus for directed data propagation |
US6029178A (en) * | 1998-03-18 | 2000-02-22 | Bmc Software | Enterprise data movement system and method which maintains and compares edition levels for consistency of replicated data |
-
1998
- 1998-05-29 US US09/087,261 patent/US6144999A/en not_active Expired - Fee Related
-
1999
- 1999-05-31 DE DE19924900A patent/DE19924900A1/de not_active Withdrawn
- 1999-06-01 GB GB9912738A patent/GB2341958B/en not_active Expired - Fee Related
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002021275A1 (en) * | 2000-09-06 | 2002-03-14 | Unisys Corporation | Method and apparatus for ensuring data integrity |
US6505307B1 (en) | 2000-09-06 | 2003-01-07 | Unisys Corporation | Method and apparatus for ensuring data integrity |
Also Published As
Publication number | Publication date |
---|---|
GB2341958A (en) | 2000-03-29 |
US6144999A (en) | 2000-11-07 |
GB2341958B (en) | 2002-12-18 |
GB9912738D0 (en) | 1999-08-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19924900A1 (de) | Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen | |
DE19924822A1 (de) | Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen | |
DE60312746T2 (de) | Wiederherstellung nach fehlern in datenverarbeitungsanlagen | |
DE602005002532T2 (de) | Cluster-datenbank mit ferndatenspiegelung | |
EP1782289B1 (de) | Metadatenverwaltung für verteilte datenspeicherung von festinhalt | |
DE60018872T2 (de) | System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen | |
US8935211B2 (en) | Metadata management for fixed content distributed data storage | |
US7383463B2 (en) | Internet protocol based disaster recovery of a server | |
EP1695220B1 (de) | System und verfahren zur unterstützung der asynchronen dataduplikation mit sehr kurzen aktualisierungsintervallen | |
DE602004008808T2 (de) | Verfahren und vorrichtung zur durchführung von operationen an gewählten daten in einem speicherbereich | |
EP1556793B1 (de) | Verteiltes dateisystem und -verfahren | |
US7593966B2 (en) | Method and apparatus for server share migration and server recovery using hierarchical storage management | |
US6671705B1 (en) | Remote mirroring system, device, and method | |
DE602004005344T2 (de) | Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort | |
DE60113586T2 (de) | Übertragen von miteinander verbundenen Datenobjekten in einer verteilten Datenspeicherumgebung | |
US8255364B2 (en) | System for emulating a virtual boundary of a file system for data management at a fileset granularity | |
EP1955208B1 (de) | Zirkuläre und bidirektionale spiegelung von flexiblen volumen | |
DE10393771T5 (de) | Schnelle Datensicherungsspeicherung und schnelle Datenwiederherstellung (FBSRD) | |
DE60313468T2 (de) | Speicherdienste und -systeme | |
Baker et al. | Availability in the Sprite distributed file system | |
US11461018B2 (en) | Direct snapshot to external storage | |
Peyrouze et al. | FT-NFS: An efficient fault-tolerant NFS server designed for off-the-shelf workstations | |
Dell | ||
AU2011265370B2 (en) | Metadata management for fixed content distributed data storage | |
US11656946B2 (en) | Cloud-native global file system with reshapable caching |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8141 | Disposal/no request for examination |