DE202010018481U1

DE202010018481U1 - Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster

Info

Publication number: DE202010018481U1
Application number: DE202010018481.9U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2009-04-21
Filing date: 2010-04-16
Publication date: 2017-01-17
Anticipated expiration: 2020-04-17
Also published as: US20100268902A1; WO2010123773A1; US8171202B2; US20120259948A1; AU2010239529B2; AU2010239529A1; CA2758518A1; BRPI1011326B1; EP2422282B1; US20130268486A1; JP5433074B2; JP2012524943A; CN102395967A; BRPI1011326A2; CN102395967B; CA2758518C; EP2422282A1; US8468291B2; US8683112B2

Abstract

Gerät oder eine Vielzahl an Geräten in einem verteilten System zur Datenreplizierung, wobei das System Folgendes umfasst: Mittel zur Speicherung eines Indexes von Objekten im verteilten Datenreplikationssystem; Mittel zum Empfangen eines Blocks eines neuen Objekts für das verteilte Datenreplikationssystem; dabei umfasst der Block einen letzten Block einer Vielzahl von Blöcken, die das neue Objekt bilden, wobei jeder Block der Vielzahl von Blöcken die gleiche temporäre Kennung enthält; Mittel zum Schreiben der temporären Kennung für das neue Objekt in den Index; Mittel zum Sperren des neuen Objekts, sodass keine weiteren Änderungen am Inhalt des neuen Objekts mehr möglich sind; Mittel zum Berechnen einer inhaltsbasierten Kennung für das neue Objekt; und Mittel zum Aktualisieren des Index, um den Zugriff auf das neue Objekt über die inhaltsbasierte Kennung zu ermöglichen.

Description

HINTERGRUND
Innerhalb der Computerumgebung von Unternehmen kam es zu einem wesentlichen Wandel der Speicherarchitektur, insofern als das die zentralisierte Architektur durch verteilte Speichercluster ersetzt wurde. Wenn Unternehmungen auf der Suche nach Wegen sind, die Speicherplatz-Effizienz zu erhöhen, können Speichercluster die von herkömmlichen Computern aufgebaut werden, eine hohe Leistung, Verfügbarkeit und Skalierbarkeit für neue datenintensive Anwendungen zu einem Bruchteil der Kosten im Vergleich zu monolithischen Plattenfeldern bieten. Um das volle Potenzial der Speichercluster freizugeben, werden die Daten über mehrere geografische Standorte repliziert, erhöhen damit die Verfügbarkeit und reduzieren die Netzwerkentfernung zum Kunden.
In diesen Systemen können verteilte Objekte und Verweise in verschiedenen Speicherclustern dynamisch erstellt, geklont und gelöscht werden (unter Verwendung eines Multimaster-Modells) und die zugrunde liegende Datenreplikationsschicht behält die Write-Order-Fidelity bei, um sicherzustellen, dass alle Cluster die gleiche Version der Daten erhalten.
Einige aktuelle Visualisierungs-, Multimedia- und andere datenintensive Anwendungen verwenden sehr große Objekte – in der Regel Hunderte Gigabyte oder sogar Terabyte groß. Das Hochladen solcher Objekte in ein verteiltes Speichersystem wird in der Regel im Streamingmodus durchgeführt, indem das Objekt in Blöcke aufgeteilt und jeder Block einzeln hochgeladen wird. Dieser Prozess kann lange Verzögerungen beim Upload zur Folge haben, die durch potenzielle Client- und/oder Serverausfälle verschärft werden können. Folglich gewinnt der effiziente verteilte Objekt-Upload im Streamingmodus, der eine Konsistenzgewähr bietet, zunehmend an Bedeutung für die Speicherbranche, angetrieben durch die Anforderungen großer Systeme, die es Clients erlauben, eine Verbindung zu jedem zu einem bestimmten Zeitpunkt verfügbaren Cluster herzustellen. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
ZUSAMMENFASSUNG
Laut einer Implementierung könnte ein Verfahren durch ein Geräte oder eine Gruppe an Geräten in einem verteilten System zur Datenreplizierung durchgeführt werden. Das Verfahren kann das Empfangen einer Anforderung zum Upload eines Objekts von einem Client auf einem oder mehreren Geräten umfassen; das Senden einer eindeutigen temporären Kennung für das Objekt durch ein oder mehrere Geräte als Antwort auf die Anforderung; das Empfangen einer Gruppe von Blöcken mit der eindeutigen temporären Kennung auf einem oder mehreren Geräten, wobei die Gruppe von Blöcken das hochgeladene Objekt umfasst; das Erstellen durch ein oder mehrere Geräte eines Eintrags für das Objekt in einem Index für das verteilte Datenreplikationssystem, wobei der Eintrag durch die eindeutige temporäre Kennung verschlüsselt ist; das Empfangen einer Anforderung vom Client auf einem oder mehreren Geräten, das hochgeladene Objekt zu finalisieren; das Rekonstruieren des Objekts auf einem oder mehreren Geräten aus der Gruppe von Blöcken; das Zuweisen einer inhaltsbasierten Kennung zum hochgeladenen Objekt; sowie das Erstellen durch ein oder mehrere Geräte eines weiteren Eintrags für das Objekt in dem Index für das verteilte Datenreplikationssystem, wobei der weitere Eintrag durch die inhaltsbasierte Kennung verschlüsselt ist.
Laut einer anderen Implementierung kann ein Gerät in einer Gruppe von Geräten in einem verteilten Datenreplikationssystem Mittel zum Speichern eines Index von Objekten in dem verteilten Datenreplikationssystem umfassen; Mittel zum Empfangen eines Blocks in dem angegebenen Versatz innerhalb eines neuen Objekts für das verteilte Datenreplikationssystem, wobei jede Gruppe von Blöcken die gleiche temporäre Kennung hat; Mittel zum Schreiben der temporären Kennung für das neue Objekt in den Index; Mittel zum Sperren des neuen Objekts, sodass keine weiteren Änderungen des Inhalts des neuen Objektinhalts möglich sind; Mittel zum Berechnen einer inhaltsbasierten Kennung für das neue Objekt; sowie Mittel zum Aktualisieren des Index, die den Zugriff auf das neue Objekt durch die inhaltsbasierte Kennung erlauben.
Laut einer wieder anderen Implementierung kann ein System einen Speicher zur Speicherung von Anweisungen, einen Datenspeicher von Objekten und einen Index der Objekte im Datenspeicher umfassen. Das System kann auch einen Prozessor zur Ausführung der Anweisungen im Speicher umfassen, um eine Gruppe von Blöcken mit der gleichen eindeutigen temporären Kennung zu empfangen, wobei die Gruppe von Blöcken ein hochzuladendes Objekt umfasst; zum Erstellen eines Eintrag für das Objekts im Index, wobei der Eintrag durch die eindeutige temporäre Kennung verschlüsselt ist; zum Berechnen einer inhaltsbasierten Kennung für das Objekt; zum Erstellen eines weiteren Eintrags für das neue Objekt im Index, wobei der weitere Eintrag durch die permanente inhaltsbasierte Kennung verschlüsselt ist; und zum Aktualisieren des Index, damit dieser von der eindeutigen temporären Kennung auf die inhaltsbasierte Kennung verweist.
Laut noch einer anderen Implementierung kann ein von zwei oder mehr Geräten durchgeführtes Verfahren den Empfang einer Gruppe von Blöcken mit derselben temporären Kennung durch zwei oder mehr Geräte umfassen, wobei die Gruppe von Blöcken ein hochzuladendes Objekt umfasst; das Erstellen an den zwei oder mehr Geräten eines Eintrags für das Objekt in einem replizierten Index, wobei der Eintrag durch die eindeutige temporäre Kennung verschlüsselt ist, und wobei der replizierte Index an jedem der zwei oder mehr Geräte repliziert wird; das Ermitteln durch das initiierende Gerät der zwei oder mehr Geräte, dass eine Vereinigung der Gruppe von Blöcken alle Daten des Objekts enthält; das Erstellen auf zwei oder mehr Geräten eines weiteren Eintrags für das Objekt im replizierten Index, wobei der weitere Eintrag durch die inhaltsbasierte Kennung verschlüsselt ist; sowie das Aktualisieren des Index durch die zwei oder mehr Geräte, damit dieser von der eindeutigen temporären Kennung auf die inhaltsbasierte Kennung verweist.
Laut einer anderen Implementierung könnte ein durch den Computer lesbarer Speicher Anweisungen umfassen, die vom Computer ausgeführt werden können. Der computerlesbare Speicher kann Anweisungen zum Empfang eines Blocks eines hochgeladenen Objekts am angegebenen Versatz umfassen, wobei das hochgeladene Objekt eine Gruppe von Blöcken mit der gleichen eindeutigen temporären Kennung umfasst; Anweisungen zum Ermitteln, ob die Vereinigung der Gruppe von Blöcken alle Daten des hochgeladenen Objekts enthält; Anweisungen zum Sperren des hochgeladenen Objekts hinsichtlich zukünftiger Änderungen des Inhalts des hochgeladenen Objekts; Anweisungen zum Berechnen einer inhaltsbasierten Kennung für das hochgeladene Objekt; Anweisungen zum Erstellen eines Eintrags für das hochgeladene Objekt in einem replizierten Index, wobei der Eintrag durch die inhaltsbasierte Kennung verschlüsselt wird; sowie Anweisungen zum Aktualisieren des replizierten Index, um Verweise auf die eindeutige temporäre Kennung im replizierten Index von der eindeutigen temporären Kennung in die inhaltsbasierte Kennung zu ändern.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die beiliegenden Zeichnungen, die in diese Spezifikation integriert sind und einen Teil dieser Spezifikation darstellen, veranschaulichen eine oder mehrere der hierin beschriebenen Ausführungsformen und dienen zusammen mit der Beschreibung als Erklärung der Ausführungsformen. Die Zeichnungen umfassen Folgendes:
1 ist ein Diagramm eines exemplarischen Systems, in das die hierin beschriebenen Systeme und Verfahren implementiert werden können;
2 ist ein Diagramm einer exemplarischen Konfiguration eines Dateisystems von 1;
3 ist ein Diagramm von exemplarischen Komponenten eines Speicherclusters aus 1;
4 ist ein Funktionsblockschaltbild eines exemplarischen Speicherclusters von 1;
5 ist ein Diagramm einer exemplarischen finalisierten Datensatzstruktur, die in einem Index eines verteilten Multimaster-Datenreplikationssystems verwendet werden kann;
6 ist ein Flussdiagramm eines exemplarischen Prozesses für die Verwaltung Client-initiierter Upload-Vorgänge gemäß einer hierin beschriebenen Implementierung;
7 ist ein Flussdiagramm eines exemplarischen Prozesses für den Empfang Client-initiierter Uploads in einem Multimaster-Datenreplikationssystem;
8 ist ein Flussdiagramm eines exemplarischen Prozesses für die Verarbeitung einer Finalisierungsanforderung für ein hochgeladenes Objekt;
9 ist ein Flussdiagramm eines exemplarischen Prozesses für die Durchführung von Scanvorgängen in einem Speichercluster gemäß einer hierin beschriebenen Implementierung;
10 ist ein Flussdiagramm eines exemplarischen Prozesses für die Erstellung neuer Verweise auf einen globalen Index von replizierten Speicherclustern; und
11 ist ein Diagramm zur Darstellung eines Teils eines exemplarischen globalen Index gemäß einer hierin beschriebenen Implementierung.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende detaillierte Beschreibung bezieht sich auf die begleitenden Zeichnungen. Dieselben Referenznummern in unterschiedlichen Zeichnungen können dieselben oder ähnliche Elemente identifizieren. Darüber hinaus soll die folgende detaillierte Beschreibung nicht als Beschränkung der Erfindung angesehen werden.
Die hierin beschriebenen Systeme und/oder Verfahren können einen asynchron verteilten Algorithmus zum Objekt-Upload im Streamingmodus für replizierte Speichercluster bereitstellen, der Garantien für die Verfügbarkeit, Aktivität und Konsistenz für große unveränderliche Objekte bietet. Ein Objekt kann in Blöcke aufgeteilt werden, die durch die Anwendung asynchron in die verfügbaren Cluster geladen werden. Die hierin beschriebenen Implementierungen können die zugrunde liegende Replikationsschicht eines verteilten Multimaster-Datenreplikationssystems verwenden, um die Blockpositionen in einem inhaltsadressierbaren Index (auch als ”globaler Index” bezeichnet) zwischen verschiedenen Speicherclustern zu replizieren. Sobald das Objekt durch die Anwendung finalisiert wurde, kann ein eindeutiger Inhalts-Handle (z. B. ein Hash-Wert oder eine digitale Signatur) auf der Basis des Blockinhalts berechnet werden, und das Objekt wird als unveränderliches Objekt in den inhaltsadressierbaren Index eingefügt.
Der Begriff ”Objekt” wie hierin verwendet kann sich auf ein Element oder eine Sammlung von Daten beziehen, die einzeln ausgewählt oder bearbeitet werden können, beispielsweise eine Multimedia-Datei, ein Bild, eine Datendatei, eine Gruppierung von Text usw. Der Begriff ”Block” wie hierin verwendet kann sich auf einen Teil eines durch seinen Versatz und seine Größe eindeutig identifizierten Objekts beziehen, der einzeln hochgeladen und später mit anderen Blöcken gruppiert werden kann, um das Objekt zu rekonstruieren.
EXEMPLARISCHE NETZWERKONFIGURATION
1 ist ein Diagramm eines exemplarischen Systems 100, in dem die hierin beschriebenen Systeme und Verfahren implementiert sein können. Das System 100 kann die Clients 110-1 bis 110-N enthalten (gemeinsam als Clients 110 benannt und individuell als Client 110) sowie Speichercluster 120-1 bis 120-M (gemeinsam als die Speichercluster 120 benannt und individuell als das Speichercluster 120), die via Netzwerk 130 verbunden sind. Speichercluster 120 können ein Dateisystem 140 formen (wie durch die gepunktete Linie in 1 gezeigt).
Netzwerk 130 kann eines oder mehrere Netzwerke umfassen, sowie ein lokales Netzwerk (LAN), ein Wide Area Network (WAN), ein Telefonnetzwerk, wie ein öffentliches Telefonnetzwerk (PSTN), ein Intranet, das Internet, ein gleiches oder ungleiches Netzwerk oder eine Kombination aus Netzwerken. Clients 110 und Speichercluster 120 können über Kabel- und/oder drahtlose Verbindungen mit dem Netzwerk 130 verbunden werden.
Die Clients 110 können eine oder mehrere Arten von Geräten beinhalten wie einen PC, ein schnurloses Telefon, einen persönlichen digitalen Assistenten (PDA), einen Laptop oder eine andere Art von Kommunikationsgerät und/oder einen Themenstrang oder Prozess, der auf einem dieser Geräte ausgeführt ist. In einer Implementierung enthält ein Client 110 eine Anwendung oder ist mit einer Anwendung verknüpft, in deren Auftrag Client 110 mit dem Speichercluster 120 kommuniziert, um Dateidaten hochzuladen, zu lesen oder zu löschen.
Speichercluster 120 können ein oder mehrere Servergeräte oder andere Arten an Rechen- oder Kommunikationsgeräten umfassen, die Informationen auf die hierin beschriebene Art speichern, verarbeiten, suchen und/oder bereitstellen können. In einer Implementierung könnten Speichercluster 120 einen oder mehrere Server (z. B. Computersysteme und/oder Anwendungen) umfassen, die einen großen Datenspeicher für Dateien mit zufälligem Lese-/Schreibzugriff pflegen können. Der Datenspeicher von Speichercluster 120 könnte ein Indexsystem zulassen, um bei Änderungen schnell Teile eines Index aktualisieren zu können. Der Datenspeicher von Speichercluster 120 könnte eine oder mehrere Tabellen umfassen (z. B. eine Dokumenttabelle, die eine Zeile pro Uniform Resource Locator (URL) umfassen kann oder Hilfstabellen, die durch andere Werte als URLs verschlüsselt werden etc.). In einem Beispiel könnte Speichercluster 120 in einem verteilten Speichersystem integriert sein (z. B. „Bigtable" gemäß Chang et al. „Bigtable: A Distributed Storage System for Structured Data", Proc. of the 7th OSDI, Seiten 205–218 (Nov. 2006) für die Verwaltung strukturierter Daten (z. B. einem Direktzugriffs-Speichercluster von Dokumenten), die zur Erweiterung auf eine sehr große Größe entwickelt wurden (z. B. Petabyte an Daten innerhalb von tausenden an Servern).
Obwohl nicht in 1 gezeigt, könnte das System 100 eine Reihe anderer Komponenten umfassen, wie beispielsweise einen oder mehrere dedizierte Verbraucherserver oder Hubs. Ein Verbraucherserver könnte beispielsweise eine Kopie der Daten mit reinem Lesezugriff von einem oder mehreren Speicherclustern 120 auf einem Datenspeicher speichern, um Zugriff für die Clients 110 zu ermöglichen. Ein Hub könnte beispielsweise eine Kopie der Daten mit reinem Lesezugriff von einem oder mehreren Speicherclustern 120 auf einem Datenspeicher speichern, um an einen oder mehrere Verbraucherserver verteilt zu werden.
EXEMPLARISCHE SPEICHERCLUSTER-KONFIGURATION
2 ist ein Diagramm einer exemplarischen Konfiguration eines Dateisystems 140. Wie in 2 gezeigt, könnte das Dateisystem 140 die Speichercluster 120-1, 120-2, 120-3 und 120-4 umfassen. In einer Implementierung könnte das Dateisystem 140 ein verteiltes Multimaster-System zur Datenreplizierung sein, wobei jeder Speichercluster 120-1, 120-2, 120-3 und 120-4 als Master-Server für die anderen Speichercluster agieren könnte. Im Dateisystem 140 können Daten aus den Speicherclustern 120-1, 120-2, 120-3 und 120-4 repliziert werden (z. B. an mehreren geografischen Standorten), um die Datenverfügbarkeit zu erhöhen und den Netzwerkabstand von den Clients (z. B. Clients 110) zu verringern. Im Allgemeinen können verteilte Objekte und Verweise dynamisch erstellt, geklont und in verschiedenen Speicherclustern 120 gelöscht werden und eine zugrundeliegende Datenreplikationsschicht (nicht gezeigt) erhält die Write-Order-Fidelity, um sicherzustellen, dass alle Speichercluster 120 die gleiche Version der Daten erhalten. Somit respektiert die Datenreplizierungsebene die Reihenfolge der Schreibvorgänge für die gleiche Replika eines einzelnen Objektes.
Ein globaler Index von allen Objekten im verteilten Multi-Master-Datenreplikationssystem kann mit jedem Speichercluster 120 verknüpft werden. Jedes gespeicherte Objekt kann durch einen einzigartigen Inhaltshandle im globalen Index gelistet werden (wie ein Hash-Wert, digitale Signatur usw.) In hierin beschriebenen Implementierungen kann neuen Objekten, die von einem Client hochgeladen werden, eine eindeutige temporäre Kennung (ID) im globalen Index zugewiesen werden, die jedem Block des neuen Objekts zugeordnet ist. Wenn alle Blöcke eines hochgeladenen Objekts empfangen wurden, kann einer der Speichercluster dem hochgeladenen Objekt einen permanenten Inhalts-Handle zuweisen und den globalen Index so aktualisieren, dass der Zugriff auf das Objekt über den permanenten Inhalts-Handle möglich ist. Änderungen am globalen Index, die durch einen Speichercluster vorgenommen wurden, können in andere Speichercluster repliziert werden.
Obwohl 2 exemplarische Funktionskomponenten des Dateisystems 140 zeigt, könnte das Dateisystem 140 in anderen Implementierungen weniger, weitere, unterschiedliche oder anders angeordnete Komponenten haben, als in 2 dargestellt ist. Bei noch weiteren Implementierungen können eine oder mehrere Komponenten des Dateisystems 140 eine oder mehrere Aufgaben leisten, wie sie als geleistet von einem oder mehreren weiteren Komponenten des Dateisystems 140 beschrieben sind.
3 ist ein Diagramm von exemplarischen Komponenten von Speichercluster 120. Der Speichercluster 120 kann einen Bus 310 enthalten, einen Prozessor 320, einen Hauptspeicher 330, einen Festwertspeicher (ROM) 340, ein Speichergerät 350, ein Eingabegerät 360, ein Ausgabegerät 370 und eine Kommunikationsoberfläche 380. Bus 310 könnte eine oder mehrere Leiter umfassen, die eine Kommunikation zwischen den Komponenten des Speicherclusters 120 zulassen.
Prozessor 320 könnte eine Art Prozessor oder Mikroprozessor umfassen, der Anweisungen interpretiert und ausführt. Der Hauptspeicher 330 kann einen Arbeitsspeicher (RAM) oder eine andere Art von dynamischem Speichergerät enthalten, auf dem Informationen und Anweisungen zur Ausführung durch Prozessor 320 gespeichert werden könnten. Der ROM 340 könne einen ROM-Gerät oder eine andere Art statischen Speichergerätes umfassen, das Informationen und Anweisungen für die Verwendung durch den Prozessor 320 speichern könnte. Das Speichergerät 350 könnte ein magnetisches und/oder optisches Aufzeichnungsmedium sowie das dazugehörige Laufwerk umfassen. Ein Speichergerät 350 könnte beispielsweise eine oder mehrere lokale Festplatten 355 umfassen, die eine dauerhafte Speicherung bieten. In einer Implementierung kann ein Speichercluster 120 Metadaten für gespeicherte Objekte pflegen, die im Dateisystem 140, auf einem oder mehreren computerlesbaren Medien, sowie auf einem Hauptspeicher 330 und/oder einem Speichergerät 350 gespeichert sind. Zum Beispiel könnte der Speichercluster 120 einen globalen Index innerhalb des Speichergeräts 350 für alle die Objekte, die innerhalb eines verteilten Multi-Master-Datenreplikationssystems gespeichert sind, speichern.
Das Eingabegeräte 360 könne einen oder mehrere Mechanismen umfassen, über die der Betrieb Informationen in das Speichercluster 120 eingeben kann, wie eine Tastatur, ein Tastenfeld, eine Taste, eine Maus, einen Stift etc. Das Ausgabegerät 370 kann einen oder mehrere Mechanismen umfassen, die Informationen für den Betreiber ausgeben, einschließlich eines Displays, einer Leuchtdiode (LED) usw. Die Kommunikationsschnittstelle 380 könnte alle empfängerähnlichen Mechanismen umfassen, die Speicherclustern 120 die Kommunikation mit anderen Geräten und/oder Systemen ermöglichen. Die Kommunikationsschnittstelle 380 könnte beispielsweise Mechanismen zur Kommunikation misst anderen Speicherclustern 120 und/oder Clients 110 umfassen.
4 ist ein Funktionsblockschaltbild eines Speicherclusters 120. Wie in 4 gezeigt kann der Speichercluster 120 auch einen Datenspeicher 410 und eine Blockverarbeitungslogik 420 umfassen. In einer Implementierung, wie in 4 gezeigt, könnte ein Datenspeicher 410 mit einem Speichercluster 120 bereitgestellt werden. In anderen Implementierungen können einiges oder alles vom Datenspeicher 410 innerhalb eines oder mehrerer anderer Geräte des Systems 100 in Kommunikation mit Speichercluster 120 gespeichert werden wie etwa externe Speichergeräte oder Geräte, die mit einem Indexierungssystem (nicht gezeigt) verknüpft sind.
Der Datenspeicher 410 kann einen replizierten Indexspeicher 412 und einen lokalen Objektspeicher 414 enthalten. Der replizierte Indexspeicher 412 kann als Teil der Replikationsschicht des verteilten Multi-Master-Datenreplikationssystems integriert werden. Der replizierte Indexspeicher 412 kann Informationen speichern, die mit dem globalen Index verknüpft sind. Mindestens ein Teil des replizierten Indexspeichers 412 kann auf den mehrfachen Speicherclustern 120 repliziert werden. Die Anzahl der Replikate für jeden replizierten Datenspeicher 412 kann benutzerkonfigurierbar sein. Der lokale Objektspeicher 414 kann Objekte lokal innerhalb des Speicherclusters 120 speichern. Der lokale Objektspeicher 414 kann Dateien beinhalten wie etwa durch Clients hochgeladene Bilder oder Videos (z. B. Clients 110).
Die Blockverarbeitungslogik 420 kann Logik zum Empfangen der von einem Client hochgeladenen Blöcke (wobei jeder Block durch seinen Versatz innerhalb des Objekts definiert ist) und/oder zum automatischen Rekonstruieren von Objekten aus mehreren Blöcken innerhalb des verteilten Multimaster-Datenreplikationssystems umfassen (z. B. Speichercluster 120-1, 120-2, 120-3 und 120-4). Wenn ein Client (z. B. Client 110) mit dem Hochladen des Objekts beginnt, kann die Blockverarbeitungslogik 420 dem Objekt eine eindeutige temporäre Kennung zuweisen, die der Client zum Hochladen aller Blöcke des Objekts verwenden kann. Wenn der Client (z. B. Client 110) das Hochladen aller Blöcke des Objekts beendet hat, kann der Client eine Finalisierungsfunktion aufrufen, die durch die Blockverarbeitungslogik 420 an einem der Cluster 120 durchgeführt werden soll. Die Blockverarbeitungslogik 420 kann Änderungen am globalen Index vornehmen, um das Objekt zu sperren (oder zu blockieren) (d. h. um sicherzustellen, dass keine weiteren Änderungen am Objektinhalt möglich sind). Die Blockverarbeitungslogik 420 kann auch den Hashwert für den Objektinhalt berechnen (d. h. eine alphanummerische Zeichenkette auf der Basis des Objektinhalts) und auf der Basis des Hashwerts dem Objekt eine permanente Kennung zuordnen. Die Blockverarbeitungslogik 420 kann ferner den globalen Index so aktualisieren, dass auf das Objekt in dem verteilten Multimaster-Datenreplikationssystem unter Verwendung der permanenten Kennung zugegriffen werden kann.
Um die Finalisierung eines Objekts aus mehreren hochgeladenen Blöcken zu erleichtern, können Datensätze (z. B. Metadaten) durch die Blockverarbeitungslogik 420 generiert werden und an einen Teil des globalen Index angehängt werden, verbunden mit einem bestimmten Inhalts-Handle oder einer temporären ID. Durch einen Cluster generierte Datensätze können schließlich an die Indexreplikate in den anderen Cluster in einem verteilten Multimaster-Datenreplikationssystem verbreitet werden. Die Datensätze können beispielsweise einen Bezeichner ”FinStarted” zur Angabe, dass die Objektfinalisierung gestartet wurde, einen Bezeichner ”FinSealed” zur Angabe, dass alle Metadaten der hochgeladenen Objektblöcke durch den Index repliziert wurden und keine weiteren Änderungen am Objektinhalt mehr vorgenommen werden können, einen Bezeichner ”FinRefCopy” zur Angabe, dass ein Querverweis auf eine permanente ID in die globale Indexreplik eingeschlossen werden sollte und die Objektverweise von der temporären ID in den permanenten ID-Indexeintrag kopiert werden sollten, einen Bezeichner ”FinRefCopyDone” zur Angabe, dass ein Querverweis zur globalen Indexreplik hinzugefügt wurde und alle Objektverweise von der temporären ID in den permanenten ID-Indexeintrag kopiert wurden, sowie einen Bezeichner ”FinDone” enthalten, um zukünftige Verweise von der temporären ID zu dem permanenten ID-Indexeintrag umzuleiten. Datensatzformate und -anwendungen sind untenstehend detaillierter beschrieben.
Obwohl 4 die exemplarischen Funktionskomponenten des Speicherclusters 120 zeigt, kann in anderen Implementierungen der Speichercluster 120 weniger, mehr, verschiedene oder unterschiedlich arrangierte Funktionskomponenten enthalten, als sie in 4 abgebildet sind. In wieder anderen Implementierungen könnten eine oder mehrere Funktionskomponenten des Speicherclusters 120 eine oder mehrere der Aufgaben durchführen, die laut Beschreibung von einer oder mehreren der Funktionskomponenten durchgeführt werden.
EXEMPLARISCHE DATENSATZSTRUKTUR
5 ist eine Darstellung einer exemplarischen Datensatzstruktur 500 für einen Finalisierungsdatensatz, der in den globalen Index in einer exemplarischen Implementierung geschrieben werden kann. Dem Finalisierungsdatensatz kann im globalen Index eine bestimmte temporäre ID einer Objektreplik zugeordnet werden.
Wie in 5 dargestellt kann die Datensatzstruktur 500 einen Bezeichnungsabschnitt 510 und einen Positionsabschnitt 520 umfassen. Der Bezeichnungsabschnitt 510 kann beispielsweise einen Bezeichner ”FinStarted”, einen Bezeichner ”FinSealed”, einen Bezeichner ”FinRefCopy”, einen Bezeichner ”FinRefCopyDone” oder einen Bezeichner ”FindOne” enthalten. Der Speicher-Cluster 120, der vom Client (z. B. Client 110) bei Abschluss des Uploads eine Finalisierungsanforderung empfängt (hierin als ”initiierender Cluster” bezeichnet), kann einen Datensatz ”FinStarted” an die Metadaten des Objekts anfügen, verschlüsselt durch eine temporäre ID.
Der Bezeichner ”FinSealed” kann durch jeden Speichercluster (einschließlich des initiierenden Clusters) hinzugefügt werden, der auf einen Datensatz ”FinStarted” trifft. Der Bezeichner ”FinSealed” kann verwendet werden, um anzugeben, dass keine weiteren Änderungen (d. h. Hinzufügungen, Aktualisierungen oder Löschungen) an der Objektreplik vorgenommen werden können, der der Datensatz ”FinSealed” zugeordnet ist.
Der Bezeichner ”FinRefCopy” kann von dem initiierenden Cluster verwendet werden, um einen Querverweis von der temporären ID auf eine permanente ID anzugeben (z. B. auf der Basis eines Inhalts-Hashwerts für ein Objekt). Der initiierende Cluster kann eine Meldung ”FinRefCopy” in die Metadaten des Objekts im globalen Index schreiben. Der Bezeichner ”FinRefCopy” kann mit dem globalen Index repliziert werden, um für andere Speichercluster 120 anzugeben, dass eine permanente ID für das Objekt verfügbar ist und dass Verweise, die mit der temporären ID verknüpft sind, in den permanenten ID-Indexeintrag kopiert werden sollten. Der Bezeichner ”FinRefCopy” kann auch angeben, dass keine neuen Verweise dem temporären ID-Indexeintrag hinzugefügt werden können.
Der Bezeichner ”FinRefCopyDone” kann verwendet werden, um anzugeben, dass ein Cluster alle mit der temporären ID verknüpften Verweise in den permanenten ID-Eintrag in der globalen Indexreplik kopiert hat. Wenn der initiierende Cluster einen Bezeichner ”FinRefCopyDone” für alle Speichercluster im verteilten Multimaster-Datenreplikationssystem erkennt, können die mit der temporären ID verknüpften Datensätze ”FinStarted”, ”FinSealed” und ”FinRefCopyDone” gelöscht werden. In einer Implementierung kann der Bezeichner ”FinRefCopy” im globalen Index zurückgelassen werden, um einen Querverweis zu liefern, über den zukünftige Verweise auf die temporäre ID an die permanente ID weitergeleitet werden. In einer anderen Implementierung kann der Bezeichner ”FinRefCopy” zusammen mit den anderen Datensätzen gelöscht werden und ein neuer Datensatz ”FinDone” kann hinzugefügt werden.
Der Bezeichner ”FinDone” kann von dem initiierenden Cluster verwendet werden, um einen permanenten Querverweis von dem durch die temporäre ID verschlüsselten Eintrag auf eine permanenten ID (d. h. auf der Basis eines Inhalts-Hashwerts für ein Objekt) für die entsprechende Objektreplik anzugeben. Der initiierende Cluster kann eine Meldung ”FinDone” in die Metadaten des Objekts im globalen Index schreiben. Der Bezeichner ”FinDone” kann mit dem globalen Index repliziert werden, um für andere Speichercluster 120 anzugeben, dass eine permanente ID für das Objekt verfügbar ist und dass Verweise, die mit der temporären ID verknüpft sind, in den permanenten ID-Indexeintrag kopiert werden sollten.
In einer Implementierung kann der Positionsabschnitt 520, wenn der Bezeichnungsabschnitt 510 die Bezeichnungen ”FinStarted”, ”FinSealed” oder ”FinRefCopyDone” enthält, eine eindeutige Kennung (d. h. Cluster-ID) für den Speichercluster 120 enthalten, die der Bezeichnung im Bezeichnungsabschnitt 510 zugeordnet ist. In einer anderen Implementierung kann der Positionsabschnitt 520, wenn der Bezeichnungsabschnitt 510 eine Bezeichnung ”FinRefCopy” oder ”FinDone” enthält, einen Querverweis auf eine permanente ID enthalten, die der temporären ID der Objektreplik zugeordnet ist.
Die Datensatzstruktur 500 kann in der Form ”Designation:Location” (Bezeichnung:Position) aufgeführt sein. Beispielsweise kann ein Datensatz für ein bestimmtes Objekt mit einer temporären ID durch den Speichercluster 120-1 mit dem Datensatz ”01:FinStarted” dem globalen Index hinzugefügt werden, wobei ”FinStarted” der Bezeichner und ”01” die Cluster-ID für den Speichercluster 120-1 ist. Ein Datensatz für eine andere Replik des gleichen Objekts im Speichercluster 120-2 kann ”FinRefCopy:catl324” sein, wobei ”FinRefCopy” der Bezeichner und ”catl324” ist die permanente ID für das Objekt ist.
EXEMPLARISCHE PROZESSABLÄUFE
6 ist ein Flussdiagramm eines exemplarischen Prozesses 600 für die Verwaltung Client-initiierter Upload-Vorgänge gemäß einer hierin beschriebenen Implementierung. In einer Implementierung kann der Prozess 600 durch einen der Clients 110 durchgeführt werden. In einer anderen Implementierung können einige oder alle Bestandteile von Prozess 600 von einem anderen Gerät oder einer Gruppe von Geräten durchgeführt werden, inklusive oder exklusive Client 110.
Bezugnehmend auf 6 kann der Prozess 600 damit beginnen, das Hochladen eines Objekts (Block 610) anzufordern und eine temporäre ID für das Objekt (Block 620) zu empfangen. Beispielsweise kann Client 110 eine Anforderung zum Hochladen einer Datei in ein verteiltes Multimaster-Datenreplikationssystem an den Speichercluster 120 übermitteln. Der Speichercluster kann die Anforderung empfangen und eine eindeutige temporäre ID für die Datei zuweisen. Die temporäre ID kann in einem beliebigen Format angegeben werden, das sich vom im globalen Index verwendeten Format einer permanenten ID (d. h. ein inhaltsbasierter Hashwert) unterscheidet. Client 110 kann die temporäre ID aus dem Speichercluster 120 empfangen.
Das Objekt kann in Blöcke unterteilt sein (Block 630). Beispielsweise kann Client 110 die Datei in mehrere Blöcke unterteilen, die keine überlappenden Daten aufweisen. In einer Implementierung kann jeder Block einen entsprechenden Byte-Bereich haben, der durch seinen Versatz und seine Datengröße identifiziert ist (z. B. für einen ersten Block kann ein Anfangsversatz 0 und eine Blockgröße von 63.900.000 Byte angegeben sein, für einen zweiten Block kann ein Versatz von 63.900.000 und eine Blockgröße von 63.989.050 Byte angegeben sein ein, für einen dritten Block kann ein Versatz von 127.889.049 und eine Blockgröße von 62.800.000 Byte angegeben sein usw.).
Die Blöcke können asynchron hochgeladen werden (Block 640) und eine Finalisierungsanforderung kann initiiert werden (Block 650). Beispielsweise kann Client 110 die Blöcke in jeden verfügbaren Speichercluster 120 im verteilten Multimaster-Datenreplikationssystem hochladen. Die Blöcke können so hochgeladen werden, dass jeder Block mit der gleichen zugewiesenen temporären ID gekennzeichnet ist und so die Vereinigung der Byte-Bereiche der hochgeladenen Blöcke die gesamte Datei abdeckt. Wenn der letzte Block hochgeladen ist, kann Client 110 eine Finalisierungsfunktion aufrufen, um eine Aktivität im verteilten Multimaster-Datenreplikationssystem zu initiieren, durch die die Datei gesperrt, der Inhalts-Hashwert der Datei berechnet und eine permanente ID auf der Basis des Hashwerts zugewiesen wird. Die Finalisierungsanforderung kann von jedem Speichercluster 120 empfangen werden, der eine Metadatenreplik des hochgeladenen Objekts hat. Der Speichercluster 120, der die Finalisierungsanforderung empfängt, kann als initiierender Cluster hinsichtlich der spezifischen hochgeladenen Datei für nachfolgende Finalisierungsaktivitäten im verteilten Multimaster-Datenreplikationssystem fungieren.
Ein Erfolgscode kann eingehen (Block 660). Beispielsweise kann Client 110 einen Erfolgscode von einem der Speichercluster 120 empfangen (z. B. vom initiierenden Cluster), durch den angegeben wird, dass die Datei erfolgreich in das verteilte Multimaster-Datenreplikationssystem hochgeladen wurde.
7 ist ein Flussdiagramm eines exemplarischen Prozesses 700 für den Empfang Client-initiierter Uploads in einem verteilten Multimaster-Datenreplikationssystem (z. B. Dateisystem 140). In einer Implementierung kann der Prozess 700 durch einen oder mehrere Speichercluster 120 durchgeführt werden. In einer anderen Implementierung können einige oder alle Bestandteile von Prozess 700 von einem anderen Gerät oder einer Gruppe von Geräten durchgeführt werden, inklusive oder exklusive des Speicherclusters 120. Der Prozess 700 kann periodisch in jedem Speichercluster 120 implementiert werden und kann einen Scan aller oder eines Teils der Objekte im Speichercluster 120 umfassen. Für bestimmte Beispiele des Prozesses 700 wie hierin beschrieben, kann sich auf die Speichercluster 120-1 und 120-2 des Dateisystems 140 bezogen werden, wobei der Speichercluster 120-1 eine Cluster-ID von ”01” beinhaltet und der Speichercluster 120-2 eine Cluster-ID von ”02” beinhaltet.
Wie in 7 dargestellt kann der Prozess 700 damit beginnen, das Hochladen eines Objekts (Block 710) und das Empfangen einer temporären ID für das Objekt anzufordern. Beispielsweise kann Speichercluster 120-1 eine Upload-Anforderung für ein Objekt von einem der Clients 110 empfangen. Der Speichercluster 120 kann eine eindeutige temporäre ID für das Objekt zuweisen, die Client 110 verwenden kann, um jeden Block des Objekts beim Hochladen zu bezeichnen. Die temporäre ID kann als Schlüssel im globalen Index für das hochgeladene Objekt verwendet werden. Die temporäre ID kann in einem beliebigen Format angegeben werden, das sich vom im globalen Index verwendeten Format einer permanenten ID (d. h. ein inhaltsbasierter Hashwert) unterscheidet.
Die hochgeladenen Blöcke können empfangen werden (Block 730). Beispielsweise können ein oder mehrere Speichercluster 120 Blöcke von Client 110 empfangen. Blöcke können in jeden verfügbaren Cluster 120 im verteilten Multimaster-Datenreplikationssystem hochgeladen werden, sodass verschiedene Blöcke des gleichen Objekts in verschiedenen Speicherclustern 120 empfangen werden können. Die Blöcke können so hochgeladen werden, dass jeder Block mit der gleichen zugewiesenen temporären ID gekennzeichnet ist und so die Vereinigung der Byte-Bereiche der hochgeladenen Blöcke die gesamte Datei abdeckt.
Eine Finalisierungsanforderung kann empfangen werden (Block 740). Beispielsweise kann einer der Speichercluster 120 eine Finalisierungsanforderung von dem Client 110 empfangen, der die Objektblöcke hochgeladen hat. Die Finalisierungsanforderung kann empfangen werden, nachdem alle Blöcke des Objekts hochgeladen wurden. Der Speichercluster 120, der die Finalisierungsanforderung empfängt, kann als der initiierende Cluster bezeichnet werden.
Das Objekt kann aus den hochgeladenen Blöcken rekonstruiert werden (Block 750). Beispielsweise kann einer der Speichercluster 120 (z. B. der initiierende Cluster) durch die zugrunde liegende Replikationsschicht des verteilten Multimaster-Datenreplikationssystems die Positionen aller Blöcke empfangen, die mit einem hochgeladenen Objekt verknüpft sind. Unter Verwendung der eindeutigen temporären ID und der Byte-Bereichssequenz für jeden Block kann der Speichercluster 120 die Blöcke von ihren aktuellen Positionen kopieren und sie zusammenfügen, um das hochgeladene Objekt zu rekonstruieren.
Die Finalisierungsanforderung kann verarbeitet werden (Block 760). Beispielsweise kann der initiierende Cluster eine Serie asynchroner Aktivitäten initiieren, um das Objekt zu sperren (d. h. sicherzustellen, dass keine weiteren Änderungen am Objektinhalt mehr möglich sind), den Hashwert für den Objektinhalt (d. h. eine alphanummerische Zeichenkette, die auf der Basis des Objektinhalts) zu berechnen und dem Objekt eine permanente ID auf der Basis des Hashwerts zuzuordnen. Die Finalisierungsaktivitäten können auch den globalen Index aktualisieren, damit sowohl über die permanente ID als auch über die temporäre ID im verteilten Multimaster-Datenreplikationssystem auf das Objekt zugegriffen werden kann. Die Verarbeitung der Finalisierungsanforderung wird bezüglich 8–10 näher diskutiert.
8 ist ein Flussdiagramm eines exemplarischen Prozesses für die Verarbeitung einer Finalisierungsanforderung für ein hochgeladenes Objekt in Block 760 oben. In einer Implementierung kann der Prozess durch einen initiierenden Cluster (z. B. einen der Speichercluster 120) durchgeführt werden. In einer anderen Implementierung können einige oder alle Bestandteile des Prozesses von einem anderen Gerät oder einer Gruppe von Geräten durchgeführt werden, inklusive oder exklusive des initiierenden Clusters. Für bestimmte Beispiele des Prozesses in 8 kann Bezug auf das verteilte Multimaster-Dateireplikationssystem (z. B. Dateisystem 140) genommen werden, welches drei Speichercluster enthält, die Speichercluster 120-1, 120-2 und 120-3. Angenommen, Speichercluster 120-1 ist der initiierende Cluster mit einer Cluster-ID ”01”, dann sind die Speichercluster 120-2 und 120-3 getrennte Speichercluster mit den Cluster-IDs ”02” bzw. ”03”.
Eine Meldung, dass die Finalisierung gestartet wurde, kann den Objektmetadaten hinzugefügt werden (Block 800). So kann beispielsweise der initiierende Cluster 120-1 (z. B. Blockverarbeitungslogik 420) ”FinStarted:01” zu den Objektmetadaten in der globalen Indexreplik hinzufügen, die im initiierenden Cluster 120-1 gespeichert ist. Wie bei jeder Aktualisierung des globalen Index kann die Meldung, dass die Finalisierung gestartet wurde, schließlich an alle globalen Indexrepliken in anderen Speicherclustern im verteilten Multimaster-Datenreplikationssystem verbreitet werden (d. h. einschließlich Speichercluster 120-2 und 120-3).
Ein Erfolgscode kann an den Client gesendet werden (Block 810). So kann beispielsweise der initiierende Cluster 120-1 einen Erfolgscode an Client 110 senden, der den Objekt-Upload initiiert hat. Der Erfolgscode kann angeben, dass alle Blöcke des Objekts erfolgreich hochgeladen wurden und dass der Upload-Prozess aus Sicht von Client 110 abgeschlossen ist.
Asynchrone Scanvorgänge der globalen Indexreplik können bei jedem Cluster durchgeführt werden (Block 820). So kann beispielsweise jeder der Speichercluster 120-1, 120-2 und 120-3 regelmäßig einen Scan aller oder eines Teils seiner jeweiligen globalen Indexrepliken durchführen und/oder in diese schreiben. Scanvorgänge werden bezüglich 9 näher diskutiert.
9 ist ein Flussdiagramm eines exemplarischen Prozesses für die Durchführung von Scanvorgängen in einem Speichercluster gemäß einer hierin beschriebenen Implementierung. In einer Implementierung kann der Prozess durch einen der Speichercluster 120 (z. B. Speichercluster 120-1, 120-2 oder 120-3) durchgeführt werden. Jeder Speichercluster 120 innerhalb eines verteilten Multimaster-Datenreplikationssystems kann den Prozess asynchron durchführen, bis die Finalisierung des hochgeladenen Objekts abgeschlossen ist. Für bestimmte Beispiele des Prozesses in 9 kann Bezug auf das verteilte Multimaster-Dateireplikationssystem (z. B. Dateisystem 140) genommen werden, welches drei Speichercluster enthält, die Speichercluster 120-1, 120-2 und 120-3. Angenommen, Speichercluster 120-1 ist der initiierende Cluster mit einer Cluster-ID ”01”, dann sind die Speichercluster 120-2 und 120-3 getrennte Speichercluster mit den Cluster-IDs ”02” bzw. ”03”.
Ein Scan der globalen Indexreplik kann initiiert werden (Block 900). Beispielsweise kann Speichercluster 120-2 einen Offline-Scan der globalen Indexreplik durchführen, die in Speichercluster 120-2 gespeichert ist. Der Scan kann alle Indexeinträge in Speichercluster 120-2 prüfen.
Es kann ermittelt werden, ob ein durch eine temporäre ID verschlüsselter Eintrag eine Meldung hat, dass die Finalisierung gestartet wurde (Block 910). So kann beispielsweise Speichercluster 120-2 auf ein Objekt in der globalen Indexreplik treffen, das durch eine temporäre ID verschlüsselt ist und eine Meldung von einem anderen Speichercluster (z. B. von Speichercluster 120-1) enthält, dass die Finalisierung gestartet wurde (z. B. ”FinStarted:01”). Wenn der durch eine temporäre ID verschlüsselte Eintrag keine Meldung enthält, dass die Finalisierung gestartet wurde (Block 910 – NO), kann der Prozess zu Block 900 zurückkehren, um den Scan fortzusetzen, oder schließlich einen weiteren Scan der globalen Indexreplik initiieren.
Wenn der durch eine temporäre ID verschlüsselte Eintrag eine Meldung enthält, dass die Finalisierung gestartet wurde (Block 910 – YES), kann eine Objektsperrungsmeldung zu den Objektmeldungsdaten hinzugefügt werden, wenn für den Speichercluster, der den Scan durchführt noch keine Objektsperrungsmeldung vorhanden ist (Block 920). Wenn der Scan in Speichercluster 120-2 beispielsweise ”FinStarted:01” in einem durch eine temporäre ID verschlüsselten Eintrag erkennt, kann der Speichercluster 120 ”FinSealed:02” zu den Metadaten des Objekts in der globalen Indexreplik in Speichercluster 120-2 hinzufügen. Das Vorhandensein der Meldung ”FinSealed” verhindert, dass andere Systemkomponenten des entsprechenden Speicherclusters Änderungen (Hinzufügungen, Aktualisierungen, Lösungen) an den hochgeladenen Objektbytes vornehmen können.
Es kann ermittelt werden, ob ein durch eine temporäre ID verschlüsselter Eintrag eine Objektsperrungsmeldung von allen Speicherclustern im verteilten Multimaster-Datenreplikationssystem hat (Block 930). Beispielsweise kann der initiierende Cluster 120-1 auf ein Objekt in der globalen Indexreplik treffen, das durch eine temporäre ID verschlüsselt ist und Objektsperrungsmeldungen (z. B. ”FinSealed:01”, ”FinSealed:02”, ”FinSealed:03”) von allen Speicherclustern im verteilten Multimaster-Datenreplikationssystem (z. B. von den Speicherclustern 120-1, 120-2 und 120-3) enthält. Wenn der durch eine temporäre ID verschlüsselte Eintrag keine Objektsperrungsmeldungen enthält (Block 930 – NO), kann der Prozess zu Block 900 zurückkehren, um den Scan fortzusetzen, oder schließlich einen weiteren Scan der globalen Indexreplik initiieren.
Wenn der durch eine temporäre ID verschlüsselte Eintrag keine Objektsperrungsmeldung aus allen Speicherclustern enthält (Block 930 – NO), können ein permanenter ID-Eintrag und ein Kopieverweis auf die permanente ID hinzugefügt werden, wenn noch nicht vorhanden (Block 940). Wenn beispielsweise der Scan im initiierenden Cluster 120-1 Objektsperrungsmeldungen für alle Speichercluster in einem durch eine temporäre ID verschlüsselten Eintrag auffindet (z. B. ”FinSealed:01”, ”FinSealed:02”, ”FinSealed:03”), kann der Speichercluster 120-1 (z. B. Blockverarbeitungslogik 420) den Hashwert für den Objektinhalt berechnen auf der Basis des Hashwerts die permanente Objekt-ID erstellen. Der Speichercluster 120-1 kann dann ”FinRefCopy:PermID” zu den Metadaten des Objekts im Speichercluster 120-1 hinzufügen (wobei PermID die auf der Basis des Inhalts-Hashwerts neu generierte permanente ID ist). Das Vorhandensein der Meldung ”FinRefCopy:PermID” kann auch verhindern, dass andere Systemkomponenten in den anderen Speicherclustern (z. B. Speichercluster 120-2 und 120-3) Änderungen (Hinzufügungen, Aktualisierungen, Lösungen) an den Bytes des Objekts vornehmen, ebenso wie an den Verweisen, die in den Metadaten des Objekts gespeichert sind.
Es kann ermittelt werden, ob ein durch eine temporäre ID verschlüsselter Eintrag einen Kopieverweis auf eine permanente ID hat (Block 950). Beispielsweise kann jeder Speichercluster 120 (d. h. jeder der Speichercluster 120-1, 120-2 oder 120-3) auf ein Objekt in der globalen Indexreplik treffen, das durch eine temporäre ID verschlüsselt ist und eine Kopieverweismeldung enthält (z. B. ”FinRefCopy:PermID”). Wenn der durch eine temporäre ID verschlüsselte Eintrag keinen Kopieverweis auf eine permanente ID enthält (Block 950 – NO), kann der Prozess zu Block 900 zurückkehren, um den Scan fortzusetzen, oder schließlich einen weiteren Scan der globalen Indexreplik initiieren.
Wenn der durch eine temporäre ID verschlüsselte Eintrag einen Kopieverweis auf eine permanente ID enthält (Block 950 – YES), können Objektverweise im temporären ID-Eintrag in den permanenten ID-Eintrag kopiert und eine Meldung eingefügt werden, dass das Kopieren durchgeführt wurde, wenn diese noch nicht vorhanden ist (Block 960). Wenn beispielsweise der Scan im Speichercluster 120-2 in einem durch eine temporäre ID verschlüsselten Eintrag ”FinRefCopy:PermID” auffindet, kann Speichercluster 120-2 alle im temporären ID-Eintrag aufgeführten Objektverweise in den Eintrag kopieren, der durch die entsprechende permanente ID verschlüsselt ist. Sobald das Kopieren abgeschlossen ist, kann Speichercluster 120-2 ”FinRefCopyDone:02” zu dem durch die temporäre ID verschlüsselten Eintrag in Speichercluster 120-2 hinzufügen.
Es kann ermittelt werden, ob ein durch eine temporäre ID verschlüsselter Eintrag Meldungen aus allen Clustern enthält, dass das Kopieren durchgeführt wurde (Block 970). Beispielsweise kann der initiierende Cluster 120-1 auf ein Objekt in der globalen Indexreplik treffen, das durch eine temporäre ID verschlüsselt ist und Meldungen, dass das Kopieren durchgeführt wurde (z. B. ”FinRefCopyDone:01”, ”FinRefCopyDone:02”, ”FinRefCopyDone:03”), von allen Speicherclustern im verteilten Multimaster-Datenreplikationssystem (z. B. von den Speicherclustern 120-1, 120-2 und 120-3) enthält. Wenn der durch eine temporäre ID verschlüsselte Eintrag keine Meldung enthält, dass das Kopieren durchgeführt wurde (Block 970 – NO), kann der Prozess zu Block 900 zurückkehren, um den Scan fortzusetzen, oder schließlich einen weiteren Scan der globalen Indexreplik initiieren.
Wenn der durch eine temporäre ID verschlüsselte Eintrag eine Meldung enthält, dass das Kopieren durchgeführt wurde (Block 970 – YES), können die mit der temporären ID verbundenen überzähligen Metadaten entfernt und eine Meldung hinzugefügt werden, dass die Finalisierung abgeschlossen ist (Block 980). Wenn beispielsweise der Scan im initiierenden Cluster 120-1” FinRefCopyDone” für alle Speichercluster in einem durch eine temporäre ID verschlüsselten Eintrag auffindet (z. B. ”FinRefCopyDone:01”, ”FinRefCopyDone:02”, ”FinRefCopyDone:03”), kann der initiierende Cluster 120-1 alle Meldungen, dass die Finalisierung gestartet wurde (”FinStarted”), alle Objektsperrungsmeldungen (”FinSealed”), Kopieverweismeldungen (”FinRefCopy”) und alle Meldungen, dass die Kopie abgeschlossen wurde (”FinRefCopyDone”), aus dem durch die temporäre ID verschlüsselten Eintrag entfernen. Der initiierende Cluster kann auch eine Meldung ”FinDone:PermID” hinzufügen, um einen permanenten Querverweis von dem durch die temporäre ID verschlüsselten Eintrag auf einen durch die permanente ID verschlüsselten Eintrag anzugeben (z. B. auf der Basis eines Inhalts-Hashwerts für ein Objekt). Es ist zu beachten, dass der Finalisierungsprozess keine Auswirkungen auf die Gültigkeit bereits bestehender Objektverweise auf die temporäre ID hat. Die Entfernung der überzähligen Metadaten kann den Finalisierungsprozess für ein hochgeladenes Objekt abschließen. Der Prozess kann zu Block 900 zurückkehren, um den Scan fortzusetzen, oder schließlich einen weiteren Scan der globalen Indexreplik durchzuführen.
In einer anderen Implementierung kann der oben genannte Prozess optimiert werden, wenn der Client (z. B. Client 110) die permanente Objekt-ID vorab berechnet, bevor der Upload-Prozess gestartet wird. In dieser Variante kann das Kopieren von Verweisen (d. h. ”FinRefCopy”-Meldungen) in einen durch eine neue permanente ID verschlüsselten Eintrag eliminiert werden. Stattdessen kann der initiierende Cluster 120 einfach das hochgeladene Objekt als finalisiert markieren, sobald ”FinSealed”-Meldungen von allen Speicherclustern 120 eingegangen sind. Es ist zu beachten, dass die temporäre ID in dieser Variante gleich der permanenten ID ist.
10 ist ein Flussdiagramm eines exemplarischen Prozesses 1000 für die Erstellung neuer Objektverweise auf einen globalen Index von replizierten Speicherclustern. Allgemein kann jede Systemkomponente in einem verteilten Multimaster-Datenreplikationssystem, die beabsichtigt, einen Verweis auf einen durch eine temporäre ID verschlüsselten Eintrag hinzuzufügen, zuerst prüfen, ob eine Kopieverweismeldung in diesem Eintrag vorhanden ist. Wenn eine Kopieverweismeldung gefunden wird, dann wird stattdessen der neue Verweis dem durch die entsprechende permanente ID verschlüsselten Eintrag hinzugefügt. In einer Implementierung kann der Prozess durch einen der Speichercluster 120 (z. B. Speichercluster 120-1, 120-2 oder 120-3) durchgeführt werden. Jeder Speichercluster 120 in einem verteilten Multimaster-Datenreplikationssystem kann den Prozess asynchron durchführen, bis der neue Verweis in jedem Speichercluster 120 repliziert worden ist.
Eine Verweisanforderung für ein durch eine temporäre ID verschlüsseltes Objekt kann empfangen werden (Block 1010). Beispielsweise kann Speichercluster 120-1 eine Anforderung zum Hinzufügen eines neuen Verweises zu einem durch eine temporäre ID verschlüsselten Eintrag ”TempID3” empfangen (d. h. ein Verweis auf der Basis eines Objekts, das hochgeladen, jedoch noch nicht finalisiert wurde).
Es kann ermittelt werden, ob der durch eine temporäre ID verschlüsselter Eintrag einen Querverweis auf eine permanente ID hat (Block 1020). Beispielsweise kann Speichercluster 120-1 den durch ”TempID3” verschlüsselten Eintrag scannen, um ”FinRefCopy”- oder ”FinDone”-Meldungen in dem Eintrag zu identifizieren. Wenn der durch die permanente ID verschlüsselte Eintrag einen Querverweis auf eine permanente ID hat (Block 1020 – YES), kann der Verweis zu dem durch die permanente ID verschlüsselten Eintrag hinzugefügt werden (Block 1030). Beispielsweise kann Speichercluster 120-1 eine ”FinRefCopy:PermID4”-Meldung identifizieren und den neuen Verweis zu dem durch ”PermID4” verschlüsselten Eintrag hinzufügen. Wenn der durch die permanente ID verschlüsselte Eintrag keinen Querverweis auf eine permanente ID hat (Block 1020 – NO), kann der Verweis zu dem durch die temporäre ID verschlüsselten Eintrag hinzugefügt werden (Block 1040). Beispiel: Wenn keine ”FinRefCopy”- bzw. ”FinDone”-Meldung aufgefunden wird, kann der Speichercluster 120-1 den neuen Verweis zu dem durch ”TempID3” verschlüsselten Eintrag hinzufügen.
BEISPIEL
11 zeigt den Teil 1100 einer exemplarischen globalen Indexreplik gemäß einer hierin beschriebenen Implementierung. Der Index kann eine Spalte 1110 Inhalts-Handle und eine Spalte 1120 Finalisierungsdatensatz enthalten. Weitere Informationen wie Objektverweise und Metadaten der Blöcke (nicht gezeigt) können auch in die globale Indexreplik aufgenommen werden. Die Spalte 1110 Inhalts-Handle und die Spalte 1120 Finalisierungsdatensatz werden in Teil 1100 zur Klarstellung gezeigt. In anderen Implementierungen können Finalisierungsdatensätze in der globalen Indexreplik mit anderen Datensätzen vermischt und durch Trennzeichen (z. B. Kommas, Leerzeichen usw.) mit oder ohne Verwendung von Spalten voneinander getrennt werden. Auch andere Datenstrukturen können für die globale Indexreplik verwendet werden.
Angenommen, in Teil 1100 der exemplarischen Indexreplik umfasst ein verteiltes Multimaster-Datenreplikationssystem drei Speichercluster XX, YY und ZZ. Ein Finalisierungsalgorithmus kann periodisch für jeden der Speichercluster XX, YY und ZZ ausgeführt werden, und dabei kann ein Teil des globalen Index oder der globale Index insgesamt gescannt werden. Außerdem können Meldungen (z. B. FinStarted, FinSealed, FinRefCopy und FinRefCopyDone) durch einen der Speichercluster XX, YY und ZZ in die globale Indexreplik geschrieben werden, die mit dem Inhalts-Handle eines bestimmten Objekts verbunden ist. Modifizierungen am globalen Index können an allen teilnehmenden Cluster repliziert werden (z. B. den Verbleibenden der Speichercluster XX, YY und ZZ).
Wie in 11 gezeigt enthält der Indexteil 1100 Inhalts-Handles und verbundene Finalisierungsdatensätze für die drei Objekte. Eine durch ”TempID06” verschlüsselte Zeile 1130 enthält Datensätze, die darauf hinweisen, dass ein Finalisierungsprozess durch den initiierenden Cluster XX für das mit ”TempID06” verbundene Objekt gestartet wurde. Zeile 1130 enthält auch Datensätze, die angeben, dass das Objekt im Speichercluster XX (d. h. ”FinSealed:XX”), im Speichercluster YY (d. h. ”FinSealed:YY”) und im Speichercluster ZZ (d. h. ”FinSealed:ZZ”) gesperrt wurde. Nachdem der initiierende Cluster XX die ”FinSealed”-Meldungen für alle Speichercluster im verteilten Multimaster-Datenreplikationssystem identifiziert und bestätigt hat, dass alle Bytes des ”TempID06” entsprechenden Objekts auf XX, YY und ZZ hochgeladen wurden, hat er einen Inhalts-Hashwert (d. h. ”PermID07”) für das Objekt berechnet. Der Speichercluster XX hat somit ”FinRefCopy:PermID07” zum Finalisierungsdatensatz in Zeile 1130 hinzugefügt und eine neue Zeile 1150, verschlüsselt durch ”PermID07” erstellt, die die Objektverweise von Zeile 1130 enthält. Eine Meldung, dass das Kopieren durchgeführt wurde (d. h. ”FinRefCopyDone:XX”), wurde ebenfalls in Zeile 1130 eingefügt, um anzugeben, dass der Speichercluster XX den Kopierprozess abgeschlossen hat. Sobald eine ”FinRefCopy”-Meldung von den anderen Speicherclustern YY und ZZ geliefert wird (und auf den initiierenden Cluster XX repliziert wird), können die überzähligen Meldungsdaten (d. h. ”FinStarted:XX”, ”FinSealed:XX”, ”FinSealed:YY”, ”FinSealed:ZZ”, ”FinRefCopy:PermID07”, ”FinRefCopyDone:XX” und die anderen ”FinRefCopyDone”-Meldungen) durch den initiierenden Cluster XX gelöscht werden (und die Löschungen auf den übrigen Cluster repliziert werden).
Eine durch ”TempID08” verschlüsselte Zeile 1140 enthält Datensätze, die darauf hinweisen, dass ein Finalisierungsprozess für das mit ”TempID08” verbundene Objekt abgeschlossen wurde. Überzählige Daten aus dem Finalisierungsprozess wurden gelöscht und nur der Querverweis auf die permanente ID (d. h. ”FinDone:PermID09”) verbleibt im Finalisierungsdatensatz. Eine neue Zeile 1160, verschlüsselt durch ”PermID09”, enthält die Objektverweise aus Zeile 1140.
Wie bei den Implementierungen oben gezeigt gewährleisten die hierin beschriebenen Systeme und Verfahren den letztendlichen Übergang von der temporären ID zu der neuen permanenten ID. Alle Verweise, die jemals unter der temporären ID des Objekts aufgezeichnet wurden, können in die permanente ID des Objekts kopiert werden, und es können zukünftig keine neuen Verweise unter der temporären ID des Objekts mehr aufgezeichnet werden.
SCHLUSSFOLGERUNG
Die hierin beschriebenen Systeme und/oder Verfahren können einen asynchronen verteilten Objekt-Upload-Algorithmus für die replizierte Verwendung in Assoziativspeicherclustern integrieren. Dieser Algorithmus verwendet die zugrunde liegende Replikationsschicht zur Replikation des Index, der die Positionen der Blöcke enthält, aus denen das Objekt besteht. Die Blöcke können im Zeitablauf in verschiedene Cluster hochgeladen werden, bis das Objekt explizit finalisiert wird. Nachdem alle Blöcke hochgeladen wurden, kann das Objekt in das inhaltsadressierbare Indexsystem eingefügt werden.
Die vorstehende Beschreibung der Implementierungen bietet eine Veranschaulichung und Beschreibung; sie ist in keiner Weise dazu gedacht, den Umfang der Erfindung auf die präzisen beschriebenen Formen einzuschränken. In Bezug auf die obigen Anleitungen sind viele Modifizierungen und Varianten möglich oder können aus der Praxis mit der Erfindung erworben werden.
In einer anderen Implementierung kann zum Beispiel eine synchrone Version des Finalisierungsalgorithmus verwendet werden, in der verschiedene Speichercluster direkt kommunizieren und nicht über die Replikationsschicht in einem verteilten Datenreplikationssystem.
Desweiteren, obwohl eine Blockreihe im Hinblick auf die 6–10 beschrieben wurden beschrieben wurde, die Reihenfolge der Block jedoch in anderen Implementierungen modifiziert werden kann. Darüber hinaus können unabhängige Blöcke parallel durchgeführt werden.
Es wird auch offensichtlich, dass die hier beschriebenen Ausführungsformen in vielen verschiedenen Formen von Software, Firmware und Hardware in den abgebildeten Figuren implementiert werden können. Der tatsächliche Softwarecode oder die spezialisierte Hardwaresteuerung für die Implementierung von hierin beschriebenen Ausführungsformen wird die Erfindung nicht beschränken. Daher werden Betrieb und Verhalten der Ausführungsform ohne Verweis auf den spezifischen Software-Code beschrieben – es ist so zu verstehen, dass die Software und die Steuerungs-Hardware so entwickelt werden können, dass sie die Ausführungsform auf Grundlage der hierin gegebenen Beschreibung implementieren.
Darüber hinaus können gewisse Implementierungen, die hierin beschrieben sind, als ”Logik” oder eine ”Komponente” implementiert werden, die eine oder mehrere Funktionen erfüllt. Diese Logik oder Komponente kann Hardware enthalten wie einen Prozessor, einen Mikroprozessor, einen Anwendungs-spezifischen integrierten Schaltkreis oder einen feldprogrammierbaren Gate-Array oder eine Kombination von Hardware und Software (z. B. Software, die von einem Prozessor ausgeführt wird);
Es sollte betont werden, dass die Begriffe „umfasst”, „beinhaltet”, „enthält”, „aufweist”, „verfügt über”, „ausgestattet mit”, „einschließlich” und „hat” in dieser Spezifikation nicht ausschließlich sind und daher das Vorhandensein der angegebenen Funktionen, ganzheitlichen Einheiten, Schritte oder Komponenten angeben, aber nicht das Vorhandensein oder das Hinzufügen von weiteren Funktionen, ganzheitlichen Einheiten, Schritten, Komponenten oder Gruppen hiervon ausschließen.
Auch wenn besondere Kombinationen an Funktionen in den Ansprüchen aufgeführt und/oder in dieser Spezifikation offengelegt werden, sollen diese Kombinationen die Offenlegung der Erfindung nicht beschränken. Tatsächlich können viele dieser Funktionen in Arten kombiniert werden, die in diesen Ansprüchen nicht genau aufgeführt und/oder in dieser Spezifikation offengelegt wurden.
Kein Element, Handlung oder Anweisung, die in der Beschreibung der vorliegenden Anwendungen verwendet wird, gilt als kritisch oder wesentlich für die Erfindung, sofern dies nicht ausdrücklich definiert wurde. Darüber hinaus wird der Artikel „ein” dafür verwendet, um auf eine oder mehr Elemente zu verweisen, während nur ein Artikel gemeint ist, wenn die Begriffe „das/die/einer/eine” oder eine ähnliche Sprache verwendet wird. Darüber hinaus meint der Ausdruck „basierend auf” gemäß der Nutzung in diesem Dokument „basierend, zumindest in Teilen, auf”, sofern nicht ausdrücklich anderweitig angegeben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

„Bigtable” gemäß Chang et al. „Bigtable: A Distributed Storage System for Structured Data”, Proc. of the 7th OSDI, Seiten 205–218 (Nov. 2006) [0027]

Claims

Gerät oder eine Vielzahl an Geräten in einem verteilten System zur Datenreplizierung, wobei das System Folgendes umfasst: Mittel zur Speicherung eines Indexes von Objekten im verteilten Datenreplikationssystem; Mittel zum Empfangen eines Blocks eines neuen Objekts für das verteilte Datenreplikationssystem; dabei umfasst der Block einen letzten Block einer Vielzahl von Blöcken, die das neue Objekt bilden, wobei jeder Block der Vielzahl von Blöcken die gleiche temporäre Kennung enthält; Mittel zum Schreiben der temporären Kennung für das neue Objekt in den Index; Mittel zum Sperren des neuen Objekts, sodass keine weiteren Änderungen am Inhalt des neuen Objekts mehr möglich sind; Mittel zum Berechnen einer inhaltsbasierten Kennung für das neue Objekt; und Mittel zum Aktualisieren des Index, um den Zugriff auf das neue Objekt über die inhaltsbasierte Kennung zu ermöglichen.
System nach Anspruch 1, des Weiteren umfassend: Mittel zum Kopieren von Verweisen auf die temporäre Kennung im Index in die inhaltsbasierte Kennung im Index.
System, umfassend: einen Speicher zur Speicherung von Anweisungen, einen Datenspeicher von Objekten und einen Index von Objekten im Datenspeicher; und einen Prozessor zur Ausführung der Befehle aus dem Speicher zum: das Empfangen einer Vielzahl von Blöcken, die die gleiche eindeutige temporäre Kennung haben, wobei die Vielzahl von Blöcken ein Objekt bildet, das hochzuladen ist, das Erstellen eines Eintrags für das Objekt im Index, wobei der Index durch die eindeutige temporäre Kennung verschlüsselt ist, das Berechnen einer inhaltsbasierten Kennung für das Objekt, das Erstellen eines weiteren Eintrags für das neue Objekt im Index, wobei der weitere Eintrag durch die permanente inhaltsbasierte Kennung verschlüsselt ist, und das Aktualisieren des Index, um von der eindeutigen temporären Kennung auf die inhaltsbasierte Kennung zu verweisen.
System nach Anspruch 3, wobei der Prozessor ferner Anweisungen im Speicher ausführt, um: eine Anforderung zum Hochladen des Objekts zu empfangen, und die eindeutige temporäre Kennung für das hochzuladende Objekt zuzuweisen.
System nach Anspruch 3, wobei der Prozessor ferner Anweisungen im Speicher ausführt, um: eine Anforderung zum Finalisieren des Objekts zu empfangen, und das Objekt aus der Vielzahl der Blöcke zu rekonstruieren.
System nach Anspruch 3, wobei der Prozessor ferner Anweisungen im Speicher ausführt, um: einen Erfolgscode zur Bestätigung des Empfangs an die Vielzahl der Blöcke zu senden.
System nach Anspruch 3, wobei der Prozessor ferner Anweisungen im Speicher ausführt, um: das Objekt zu sperren, um zukünftige Änderungen des Inhalts des neuen Objekts zu verhindern.
System nach Anspruch 3, wobei der Prozessor ferner Anweisungen im Speicher ausführt, um: Verweise im Index auf die eindeutige temporäre Kennung aus dem durch die eindeutige temporäre Kennung verschlüsselten Eintrag in den Eintrag zu kopieren, der durch die permanente inhaltsbasierte Kennung im Index verschlüsselt ist.
Ein computerlesbarer Speicher, der computerausführbare Anweisungen umfasst, wobei der computerlesbare Speicher Folgendes umfasst: Anweisungen zum Empfangen eines Blocks eines hochgeladenen Objekts, wobei das hochgeladene Objekt aus einer Vielzahl von Blöcken besteht, die die gleiche eindeutige temporäre Kennung haben; Anweisungen zum Ermitteln, ob eine Vereinigung der Vielzahl von Blöcken alle Daten des hochgeladenen Objekts enthält; Anweisungen zum Sperren des hochgeladenen Objekts zur Verhinderung von zukünftigen Änderungen am Inhalt des hochgeladenen Objekts; Anweisungen zum Berechnen einer inhaltsbasierten Kennung für das hochgeladene Objekt; Anweisungen zum Erstellen eines Eintrags für das hochgeladene Objekt in einem replizierten Index, wobei der Eintrag durch die inhaltsbasierte Kennung verschlüsselt ist; und Anweisungen zum Aktualisieren des replizierten Index, um Verweise auf die eindeutige temporäre Kennung im replizierten Index in die inhaltsbasierte Kennung zu ändern.
Computerlesbarer Speicher nach Anspruch 9, der ferner Folgendes umfasst: Anweisungen zum Empfangen einer Anforderung zum Hochladen des Objekts, und Anweisungen zum Zuweisen einer eindeutigen temporären Kennung für das Objekt vor dem Hochladen.
Computerlesbarer Speicher nach Anspruch 9, der ferner Folgendes umfasst: Anweisungen zum Kopieren von Verweisen auf die temporäre Kennung im Index in die inhaltsbasierte Kennung im Index.