DE19924822A1 - Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen - Google Patents

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 Informationen ü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...

Description

Die vorliegende Erfindung betrifft allgemein Katastrophen- Behebungssysteme für Dateisysteme und insbesondere geographi­ sche Replikationssysteme.

HINTERGRUND DER ERFINDUNG

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.

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

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.

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

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 Verzeichnishirarchie 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

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ß.

ZUSAMMENFASSUNG DER ERFINDUNG

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.

KURZBESCHREIBUNG DER ZEICHNUNGEN

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.

BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGEN

Gemeinsame Aspekte bevorzugter Ausführungen werden mit den Begriffen Systemtopologie, Funktionalität, Versagenscharakteri­ stika, Verwaltung und Leistung beschrieben; diese Konzepte werden nun definiert.

Topologie (Topology)

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 (Functionality)

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.

Versagenscharakteristika (Failure Characteristics)

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.

Verwaltung (Administration)

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.

Leistung (Performance)

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. Buse 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 160R ü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).

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.

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 bereitsgestellt: 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 inode-, snode- und rnode-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 Mechansimen (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 aoproach). 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­ ven 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 Telescope-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 nutzen (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 mode 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 Initilisierung 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 Abbildungst 65229 00070 552 001000280000000200012000285916511800040 0002019924822 00004 65110abelle 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.

Synchronisation

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 äls 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 Netzwerkresourcen deutlich weniger belastend (draining) ist als eine komplette Däteisystemkopie. 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.

Erfassung von Datenaktualisierungen (Capturing Data Updates)

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.

TABELLE 1

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.

Protokollierung (Logging)

Wieder mit Bezug auf Fig. 3 ist das Replikationsprotokoll 264 eine der wichtigsten Komponenten des Telescope-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 vorhergehenden 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 Systemausfalles.

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ügbaren Platz für einen Protokolleintrag 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 aktuellen 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.

Integration der Protokollierung in den PXFS-Server

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.

Kodierungsoperationen in das Protokoll

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.

HA-PXFS

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 Telescope 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, 122s (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 122s 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 122s 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 122s 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 122s 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 122s, 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 (die hinzugefügten Schritte sind fett gedruckt):

• 1. Klient schickt Anforderung.
• 2. 1.1 Der Primäre 122p gibt die Anforderung in das Proto­ koll ein und empfängt eine transaction id.
• 3. Der Primäre sendet Checkpoint mit Zustandsdaten.
• 4. Der Sekundäre weist Zustandsobjekt zu und quittiert Checkpoint.
• 5. Der Primäre aktualisiert Speicher.
• 6. 4.1 Der Primäre 122p trägt abhängig davon, ob eine Operation erfolgreich war, eine Übergabe- oder Invalidisierungsnachricht in das Protokoll ein.
• 7. Der Primäre gibt Ergebnisse zurück.
• 8. Klient sendet eine asynchrone Vergessen-Nachricht (forget message) zum Sekundären.

Dieser Algorithmus garantiert, daß der sekundäre Server 122s 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 122s) zu leiten.

Datenübertragung

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.

Einrichten einer Verbindung

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­ tionsresourcen 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.

Datenübertragung zum entfernten Standort

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ß Telescope 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 Telescope 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.

Synchronisation

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) und gemeinsam übertragen werden.

Entfernter Standort (Remote Site)

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.

Fehler bzw. Störung oder Versagen (Failure)

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.

Anhang A. Kodierte Operationen und Parameter

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.

A.1 create fobj

sol::error_t
dirprovii::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.

A.2 remove_fobj

sol::error_t
dirprov_ii::remove_fobj(const char*nary, solobj::cred_ptr credobj, Environment);
Übertrage: this, nm.

A.3 create_symlink

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.

A.4 create_dir

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.

A.5 remove_dir

sol::error t
dirprov_ii::remove_dir(const char*dirnm, fs::unixdir_ptr cur_dir, solobj::cred_ptr credobj, Environment);
Übertrage: this, dirnm, cur_dir.

A.6 rename_fObj

sol::error_t
dirprovii::rename_fobj(const char*sourcenm, fs::unixdir_ptr target_dir, const char*targetnm, solobj::cred_ptr credobj, Environment);
Übertrage: this, sourcenm, target_dir, targetnm.

A.7 page_out

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.

A.8 write_out

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.

A.9 sync

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.

A.10 uiowrite

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.

A.11 fsync

sol::error_t io_ii::faync(Long syncflag, solobj::cred_ptr credobj, Environment);
Übertrage: this, syncflag.

A.12 set_attributes

sol::error_t fobj_ii::set_attributes(const sol::vattr_t& attr, solobj::cred_ptr credobj, Environment);
Übertrage: this, attr.

A.13 set secattributes

sol::error t fobj_ii::set secattributes(const fs::secattr& sattr, Long secattrflag, solobj::cred_ptr credobj, Environment­ vironment);
Übertrage: this, sattr, secattrflag.

A.14 write_all_attr

void fobjprov_ii::write_all attr(sol::vattr_t& attributes, solobj::cred_ptr credobj, Environment);
Übertrage: this, attributes.

A.15 ioctl

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 (19)

1. Geographisches Datenreplikationssystem mit:
einem lokalen Standort mit mindestens einem lokalen Server, auf dem ein erstes Dateisytem, mindestens ein erster Klient und erster stabiler Dateispeicher läuft, wobei der lokale Server so konfiguriert ist, daß er über das erste Dateisystem Dateianforderungen von dem minde­ stens einen Klienten bedient;
einem entfernten Standort mit mindestens einem ent­ fernten Server, auf dem ein zweites Dateisystem und zweiter stabiler Dateispeicher läuft;
einem Netzwerk, das den lokalen und den entfernten Standort verbindet;
wobei der lokale Server so konfiguriert ist, daß er die Dateianforderungen abfängt und bestimmt, welche der Dateianforderungen eine aus einem ersten Satz von Datei­ anforderungen ist, die den Dateistatus des ersten Datei­ systems ändern; und
einer auf dem ersten stabilen Dateispeicher gespei­ cherten Protokolldatei, in die der lokale Server Opera­ tionen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server so konfiguriert ist, daß er die Proto­ kolldatei periodisch zum entfernten Standort räumt;
wobei der entfernte Server so konfiguriert ist, den Zustand des zweiten Dateisystems entsprechend der ge­ räumten Protokolldatei durch Durchführung der in der ge­ räumten Protokolldatei repräsentierten Operationen auf die Daten zu aktualisieren;
derart, daß, wann immer ein Failover vom lokalen zum entfernten Server auftritt, der entfernte Server in der Lage ist, die Anforderungen der Klienten mit wenig oder keinem Verlust von Dateizustand zu bedienen.

2. Geographisches Datenreplikationssystem nach Anspruch 1, bei dem der lokale Standort einen Cache aufweist, den das erste Dateisystem nutzt, um die Anforderungen zu befriedigen, bevor die Anforderungen auf den ersten stabilen Dateispeicher angewendet werden;
derart, daß der lokale Server so konfiguriert ist, daß er nur solche Dateianforderungen abfängt, die durch das erste Dateisystem auf den ersten stabilen Dateispei­ cher angewendet werden.

3. Geographisches Datenreplikationssystem nach Anspruch 1, weiterhin mit:
einem durch das erste Dateisystem aufrechterhalte­ nen bereitgehaltenen Kennzeichen für jede der Dateien auf dem ersten stabilen Dateispeicher, wobei das erste Kennzeichen durch den lokalen Server für jede der ge­ räumten Dateien zum entfernten Server übertragen wird;
einem durch das zweite Dateisystem aufrechterhalte­ nen zweiten Kennzeichen für jede der geräumten Dateien, die auf dem entfernten Server repliziert sind; und
einer Abbildungstabelle am entfernten Server, die eine Abbildung zwischen dem ersten und dem zweiten Kenn­ zeichen aufrechterhält, die es dem entfernten Server ermöglicht, die Anforderungen der Klienten zu bedienen.

4. Geographisches Datenreplikationssystem nach Anspruch 3, bei dem:
das erste Kennzeichen ein beständiges lokales Kennzeichen der geräumten Datei am lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei am entfernten Standort ist.

5. Geographisches Datenreplikationssystem nach Anspruch 3, bei dem:
das erste Kennzeichen ein beständiges lokales Ver­ zeichniskennzeichen eines Verzeichnisses am lokalen Standort aufweist, in dem die geräumte Datei gespei­ chert ist, und ein beständiges lokales Namenskennzei­ chen, das einem die geräumte Datei identifizierenden Namen am lokalen Standort zugeordnet ist; und
das zweite Kennzeichen ein entferntes Verzeichnis­ kennzeichen eines Verzeichnisses am entfernten Standort aufweist, in dem die geräumte Datei gespeichert ist, und ein entferntes Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen am entfernten Standort zugeordnet ist.

6. Verfahren zur geographischen Datenreplikation, das in einem Computernetzwerk implementierbar ist, das einen lokalen Standort mit einem lokalen Server und mindestens einem Klienten aufweist, der so konfiguriert ist, daß er Dateianforderungen an das auf dem lokalen Server laufen­ de erste Dateisystem abgibt, und einen entfernten Stand­ ort mit einem entfernten Server, auf dem ein zweites Dateisystem läuft, das mit dem ersten Dateisystem zusam­ men operationsfähig ist (is interoperable with), bei dem:
der lokale Server:
die Dateianforderungen abfängt;
bestimmt, welche der Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des ersten Dateisystems ändern wird;
in eine beständige Protokolldatei Operationen und Daten schreibt, die für eine Bedienung des ersten Satzes von Dateianforderungen erforderlich sind;
periodisch die Protokolldatei zum entfernten Standort räumt; und
der entfernte Server:
den Zustand des zweiten Dateisystems gemäß der geräumten Protokolldatei aktualisiert;
derart, daß, wann immer ein Failover von dem lokalen zu dem entfernten Server auftrifft, der entfernte Server in der Lage ist, die Anforderun­ gen von den Klienten mit wenig oder keinem Verlust von Dateizustand zu bedienen.

7. Verfahren nach Anspruch 6, bei dem der durch den ent­ fernten Server durchgeführte Aktualisierungsschritt aufweist:
eine Ausführung der Operationen auf den in der geräumten Protokolldatei repräsentierten Daten.

8. Verfahren nach Anspruch 6, bei dem:
der lokale Standort einen Cache aufweist, den das erste Dateisystem zur Befriedigung der Anforderungen verwendet, bevor die Anforderungen auf einen ersten stabilen Dateispeicher angewendet werden; und
der Abfangschritt nur bei solchen Dateianforderun­ gen ausgeführt wird, die durch das erste Dateisystem auf den ersten stabilen Dateispeicher angewendet werden.

9. Verfahren nach Anspruch 6, weiterhin mit:
der lokale Server überträgt an den entfernten Server für jede der geräumten Dateien ein durch das erste Dateisystem aufrechterhaltenes erstes Kennzeichen für jede der Dateien auf dem ersten stabilen Dateispei­ cher;
der entfernte Server bildet das erste Kennzeichen auf ein durch das zweite Dateisystem für jede der ge­ räumten Dateien aufrechterhaltenes zweites Kennzeichen ab, was es dem entfernten Server ermöglicht, die Anfor­ derungen der Klienten zu bedienen.

10. Verfahren nach Anspruch 9, bei dem:
das erste Kennzeichen ein beständiges lokales Kennzeichen der geräumten Datei am lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei am entfernten Standort ist.

11. Verfahren nach Anspruch 9, bei dem:
das erste Kennzeichen ein beständiges lokales Ver­ zeichniskennzeichen eines Verzeichnisses am 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 am lo­ kalen Standort zugeordnet ist; und
das zweite Kennzeichen ein entferntes Verzeichnis­ kennzeichen eines Verzeichnisses am entfernten Standort aufweist, in das die geräumte Datei gespeichert wird, und ein entferntes Namenskennzeichen, das einem die ge­ räumte Datei identifizierenden Namen am entfernten Standort zugeordnet ist.

12. Computerprogrammprodukt zur Bereitstellung einer geogra­ phischen Datenreplikation in einem Computernetzwerk, das einen lokalen Standort mit einem lokalen Server mit min­ destens einem Klienten aufweist, der so konfiguriert ist, daß er Dateianforderungen an ein auf dem lokalen Server laufendes erstes Dateisystem abgibt, und einem entfernten Standort mit einem entfernten Server, auf dem ein zweites Dateisystem läuft, das interoperabel ist, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium und einen darin eingebetteten Computer­ programm-Mechanismus aufweist, der Computerprogramm- Mechanismus mit:
lokaler geographischer Datenreplikationssoftware, die den lokalen Server dazu konfiguriert:
die Dateianforderungen abzufangen;
zu bestimmen, welche der Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des ersten Dateisytems ändern wird;
in eine beständige Protokolldatei Operationen und Daten zu schreiben, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind; und
die Protokolldatei periodisch zum entfernten Standort zu räumen; und
entfernter geographischer Replikationssoftware, die den entfernten Server dazu konfiguriert:
den Zustand des zweiten Dateisystems gemäß der ge­ räumten Protokolldatei zu aktualisieren, indem die Ope­ rationen auf den in der geräumten Protokolldatei reprä­ sentierten Daten ausgeführt werden;
derart, daß, wann immer ein Failover vom lokalen zum entfernten Server stattfindet, der entfernte Server in der Lage ist, die Anforderungen von dem Klienten mit wenig oder keinem Verlust von Dateizustand zu bedienen.

13. Computerprogrammprodukt nach Anspruch 12, bei dem:
der lokale Standort einen Cache aufweist, den das erste Dateisystem zur Befriedigung der Anforderungen nutzt, bevor die Anforderungen auf einen ersten stabi­ len Dateispeicher angewendet werden; und
der lokale Server so konfiguriert ist, nur solche Anforderungen abzufangen, die durch das erste Datei­ system auf den ersten stabilen Dateispeicher angewendet werden.

14. Computerprogrammprodukt nach Anspruch 12, bei dem:
das erste Dateisystem für jede der Dateien auf dem ersten stabilen Dateispeicher ein erstes Kennzeichen aufrechterhält,
der lokale Server so konfiguriert ist, daß er das erste Kennzeichen für jede der geräumten Dateien an den entfernten Server weitergibt;
das zweite Dateisystem für jede der geräumten Da­ teien, die auf dem entfernten Server repliziert werden, ein zweites Kennzeichen pflegt; und
der entfernte Server so konfiguriert ist, daß er auf dem entfernten Server eine Abbildungstabelle auf­ rechterhält, die eine Abbildung zwischen dem ersten und dem zweiten Kennzeichen aufrechterhält, um es dem ent­ fernten Server zu ermöglichen, die Anforderung von den Klienten zu bedienen.

15. Computerprogrammprodukt nach Anspruch 14, bei dem:
das erste Kennzeichen ein beständiges erstes Kenn­ zeichen der geräumten Datei am lokalen Standort ist; und
das zweite Kennzeichen ein entferntes Kennzeichen der geräumten Datei an dem entfernten Standort ist.

16. Computerprogrammprodukt nach Anspruch 14, bei dem:
das erste Kennzeichen ein beständiges lokales Ver­ zeichniskennzeichen eines Verzeichnisses am lokalen Standort aufweist, in dem die geräumte Datei gespei­ chert ist, und ein beständiges lokales Namenskennzei­ chen, das einem die geräumte Datei identifizierenden Namen am lokalen Standort zugeordnet ist; und
das zweite Kennzeichen ein entferntes Verzeichnis­ kennzeichen eines Verzeichnisses am entfernten Standort aufweist, in dem die geräumte Datei gespeichert ist, und ein entferntes Namenskennzeichen, das einem die geräumte Datei identifizierenden Namen am entfernten Standort zugeordnet ist.

17. Ein geographisches Replikationssystem mit:
einem lokalen Server, der so konfiguriert ist, daß er an ein erstes Dateisystem gerichtete Dateianforderun­ gen abfängt und bestimmt, welche der Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des ersten Dateisystems ändern wird; und
einer beständigen Protokolldatei, in die der lokale Server Operationen und Daten schreibt, die zur Bedienung des ersten Satzes von Dateianforderungen erforderlich sind, wobei der lokale Server so konfiguriert ist, daß er die Protokolldatei periodisch zum entfernten Server räumt;
der entfernte Server so konfiguriert ist, den Zu­ stand eines zweiten Dateisystems gemäß der geräumten Protokolldatei zu aktualisieren, indem die Operationen auf den in der geräumten Protokolldatei repräsentierten Daten ausgeführt werden;
derart, daß der entfernte Server, wann immer ein Failover von dem lokalen zu dem entfernten Server auf­ tritt, in der Lage ist, die Dateianforderungen mit wenig oder keinem Verlust an Dateizustand zu bedienen.

18. Verfahren für geographische Datenreplikation mit:
an einem lokalen Server:
Abfangen von an ein erstes Dateisystem gerich­ teten Dateianforderungen;
Bestimmung, welche der Dateianforderungen eine eines ersten Satzes von Dateianforderungen ist, die den Dateizustand des ersten Dateisystems ändern wird;
Schreiben in eine beständige Protokolldatei Operationen und Daten, die zur Bedienung des ersten Sat­ zes von Dateianforderungen erforderlich sind; und
periodisches Räumen der Protokolldatei zum entfernten Server; und
auf dem entfernten Server:
Aktualisierung des Zustandes des zweiten Dateisystems gemäß der geräumten Protokolldatei;
derart, daß, wann immer ein Failover vom lokalen zum entfernten Server auftritt, der entfernte Server in der Lage ist, Anforderungen der Klienten mit wenig oder keinem Verlust an Dateizustand zu bedienen.

19. Computerprogrammprodukt zur Bereitstellung geographi­ scher Datenreplikation, wobei das Computerprogrammpro­ dukt ein computerlesbares Speichermedium und einen darin eingebetteten Computerprogramm-Mechanismus aufweist, der Computerprogramm-Mechanismus mit:
lokaler geographischer Datenreplikationssoftware, die den lokalen Server dazu konfiguriert:
an das erste Dateisystem gerichtete Dateian­ forderungen abzufangen;
zu bestimmen, welche der Dateianforderungen eine aus einem ersten Satz von Dateianforderungen ist, die den Dateizustand des ersten Dateisystems ändern wird;
in eine beständige Protokolldatei Operationen und Daten zu schreiben, die dazu erforderlich sind, den ersten Satz von Dateianforderungen zu bedienen; und
periodisch die Protokolldatei an einen ent­ fernten Server zu räumen; und
entfernter geographischer Replikationssoftware, die den entfernten Server dazu konfiguriert:
den Zustand des zweiten Dateisystems gemäß der ge­ räumten Protokolldatei zu aktualisieren, indem die Ope­ rationen auf den in der geräumten Protokolldatei reprä­ sentierten Daten ausgeführt werden;
derart, daß, wann immer ein Failover vom lokalen zum entfernten Server auftritt, der entfernte Server in der Lage ist, die Anforderungen von den Klienten mit wenig oder keinem Verlust an Dateizustand zu bedienen.