DE202009019149U1

DE202009019149U1 - Asynchron verteilte Speicherbereinigung für replizierte Speichercluster

Info

Publication number: DE202009019149U1
Application number: DE202009019149.4U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2008-12-22
Filing date: 2009-12-22
Publication date: 2017-01-30
Anticipated expiration: 2019-12-23
Also published as: WO2010075401A2; JP2012513639A; CA2747786A1; AU2009330067A1; US20130124470A1; JP5479490B2; EP2380101A2; US9081841B2; CA2747786C; CN102317939B; US8346820B2; US20100161688A1; EP2380101B1; BRPI0922542B1; WO2010075401A3; AU2009330067B2; CN102317939A

Abstract

Gerät oder eine Vielzahl an Geräten in einem verteilten System zur Datenreplizierung, wobei das System Folgendes umfasst: Mittel zum Identifizieren eines Objektes in einem Datenspeicher, das mit einer Verhandlungsnachricht in Verbindung steht; Mittel zum Verknüpfen einer neuen Verhandlungsnachricht mit dem Objekt, wobei die neue Verhandlungsnachricht auf dem Status des Objekts basiert; Mittel zum Replizieren der neuen Verhandlungsnachricht in einem Speichercluster; Mittel zum Empfangen anderer Verhandlungsnachrichten, die mit der Kopie des Objekts verknüpft sind; und Mittel zum Löschen des Objekts, wenn die andere Verhandlungsnachricht auf eine erfolgreiche Verhandlung hindeutet.

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. Da Unternehmen zusehend nach Möglichkeiten suchen, um ihre Speichereffizienz zu erhöhen, können derartige Cluster aus Commodity-Computern eine hohe Leistung, Verfügbarkeit und Skalierbarkeit für neue, datenintensive Anwendungen zu einem Bruchteil der Kosten von monolithischen Disk Arrays bieten. Um das vollständige Potential von Speicherclustern auszuschöpfen, werden die Daten über mehrere geografische Standorte repliziert, um die Verfügbarkeit zu steigern und den Netzwerkabstand von Clients zu reduzieren.
Speicherbereinigung bei administrativ dezentralisierten Speichersystemen, die große Mengen verteilter Objekte verwalten, könnte ein Problem darstellen. Ein Garbage Collector ist verantwortlich für die Speicherbereinigung auf Laufwerken durch das Löschen von nicht länger benötigten Objekten. Die verteilte Speicherbereinigung in Speicherclustern wird durch normales Maschinenversagen und Netzwerkpartitionierungen weiter erschwert, die es schwer, wenn nicht sogar unmöglich machen, eine unternehmensweite synchrone Ansicht der Objekte und deren Referenzen zu erhalten.
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ät oder eine Gruppe an Geräten in einem verteilten System zur Datenreplizierung durchgeführt werden. Das Verfahren könnte auch Folgendes umfassen: Die Speicherung von Objekten in einem Datenspeicher, das Replizieren von mindestens einem Objekt mit dem verteilten System zur Datenreplizierung; die Durchführung eines Scans der Objekte im Datenspeicher, die Identifizierung eines Objekts ohne darauf verweisende Referenz; die Speicherung einer Löschverhandlungsnachricht als Metadaten in Verbindung mit einem der Objekte sowie das Replizieren von Metadaten mit der Löschverhandlungsnachricht auf einem oder mehreren Geräten der Gruppe an Geräten.
Laut einer anderen Implementierung könnte ein Gerät aus einer Gruppe an Geräten in einem verteilten System zur Datenreplizierung auch Mittel zur Identifizierung eines Objektes in einem Datenspeicher umfassen, wobei das Objekt über eine Löschverhandlungsnachricht verfügt. Gleichzeitig umfasst es aber auch Wege zur Zuweisung einer neuen Verhandlungsnachricht zu dem Objekt, wobei die neue Verhandlungsnachricht auf dem Status des Objektes basiert; Mittel für das Replizieren der neuen Verhandlungsnachricht auf einem Speichercluster; Mittel zum Empfang anderer Verhandlungsnachrichten in Verbindung mit der Nachbildung des Objekts, sowie Mittel zum Löschen des Objektes, wenn die anderen Verhandlungsnachrichten auf eine erfolgreiche Verhandlung hinweisen.
Laut einer wieder anderen Implementierung könnte ein System einen Speicher zur Speicherung von Anweisungen umfassen, sowie einen Datenspeicher und einen Prozessor. Der Prozessor kann Anweisungen im Speicher umsetzen, um einen Status eines Objektes innerhalb des Datenspeicher zu identifizieren, den Status in Verbindung mit einer bestehenden Referenz des Objektes identifizieren und bestimmen, ob eine Löschverhandlungsnachricht mit dem Objekt in Verbindung steht. Gleichzeitig kann er eine neue Verhandlungsnachricht an die Objektmetadaten basierend auf dem Status des Objektes schreiben, die Metadaten mit der neuen Verhandlungsnachricht an ein oder mehrere Geräte replizieren und von einem oder mehreren Geräten anderen Verhandlungsnachrichten in Verbindung mit dem Objekt empfangen, sofern die neue Verhandlungsnachricht und die anderen Verhandlungsnachrichten zu einer Übereinstimmung für eine Löschverhandlung für das Objekt kommen.
Laut einer noch anderen Implementierung könnte ein Verfahren Folgendes umfassen: Austausch von einer oder mehreren Löschverhandlungsnachrichtungen zwischen Speicherclustern innerhalb eines verteilten, Multimaster-Systems zur Datenreplizierung, wobei jede der Löschverhandlungsnachrichten in die Metadaten des Objektes integriert werden, das der Löschverhandlungsnachricht unterliegt, und wobei die Löschverhandlungsnachricht unter den Speicherclustern mithilfe einer Replikationsebene des verteilten Multimaster-Systems zur Datenreplizierung verschickt wird, wenn es zu einer Übereinstimmung zwischen den Speicherclustern basierend auf einer oder mehreren Löschverhandlungsnachrichten kommt.
Laut einer anderen Implementierung könnte ein durch den Computer lesbarer Speicher Anweisungen umfassen, die vom Computer ausgeführt werden können. Der durch den Computer lesbare Speicher könnte Folgendes umfassen: Eine oder mehrere Anweisungen zur Identifizierung eines Objektstatus in einem Datenspeicher, wobei sich der Status darauf bezieht, ob eine Löschverhandlungsnachricht mit dem Objekt in Verbindung steht; eine oder mehrere Anweisungen, um eine neue Verhandlungsnachricht zu den Metadaten eines Objektes zu schreiben, die auf dem Status des Objektes basiert; eine oder mehrere Anweisungen zur Replikation der Objektmetadaten mit der neuen Verhandlungsnachricht auf einem Speichercluster; eine oder mehrere Anweisungen zum Empfang anderer Verhandlungsnachrichten von einem oder mehreren Geräten in Verbindung mit dem Objekt; sowie eine oder mehrere Anweisungen zur Feststellung, ob es eine Übereinstimmung für eine Löschverhandlung des Objektes basierend auf den anderen Verhandlungsnachrichten in Verbindung mit dem Objekt gibt.
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 Netzwerks, in dem 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 von 1;
4 ist ein Funktionsblockschaltbild eines exemplarischen Speicherclusters von 1;
5 ist ein exemplarisches Diagramm einer Nachrichtenstruktur, die laut einer Implementierung verwendet werden könnte, die mit den hierin beschriebenen Systemen und Verfahren konsistent ist;
6 ist ein Flussdiagramm eines exemplarischen Prozesses zur Durchführung einer Speicherbereinigung in einem verteilten Multimaster-System zur Datenreplizierung in Übereinstimmung mit einer Implementierung, die den hierin beschriebenen Systemen und Verfahren entspricht;
7 ist ein Flussdiagramm für einen exemplarischen Prozess zum Schreiben einer Verhandlungsnachricht in Übereinstimmung mit einer Implementierung, die mit den hierin beschriebenen Systemen und Verfahren konsistent ist;
8 ist ein Flussdiagramm für einen exemplarischen Prozess zum Erstellen einer neuen Referenz für ein Objekt in Übereinstimmung mit einer Implementierung, die mit den hierin beschriebenen Systemen und Verfahren konsistent ist;
9 ist ein Diagramm zur Darstellung eines Teils einer exemplarischen Löschverhandlung in Übereinstimmung mit einer Implementierung.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende detaillierte Beschreibung bezieht sich auf die begleitenden Zeichnungen. Die gleichen Bezugsziffern in verschiedenen Zeichnungen können die gleichen 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önnten eine asynchron verteilte Speicherbereinigung für replizierte Speichercluster ausführen. Die hierin beschriebenen Implementierungen könnten die zugrundeliegende Replizierungsebene eines verteilten Multimaster-Systems zur Datenreplizierung nutzen, um Löschverhandlungsnachrichten zwischen verschiedenen Clustern des verteilten Multimaster-Systems zur Datenreplizierung zu transportieren. Ein Objekt kann gelöscht werden, wenn ein verteiltes Einvernehmen erreicht wird, dass weder aktive Referenzen noch replizierte Referenzen im System vorhanden sind.
EXEMPLARISCHE NETZWERKONFIGURATION
1 ist ein Diagramm eines exemplarischen Systems 100, in dem die hierin beschriebenen Systeme und Verfahren implementiert sein können. System 100 könnte die Clients 110-1 bis 110-N (zusammen nachstehend Clients 110 genannt) und die Speichercluster 120-1 bis 120-1 (zusammen nachstehend Speichercluster 120 genannt) umfassen, die über ein Netzwerk 130 verbunden sind. Speichercluster 120 können ein Dateisystem 140 formen (wie durch die gepunktete Linie in 1 gezeigt).
Netzwerk 130 könnte 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.
Clients 110 könnten eines oder mehrere Arten an Geräten umfassen, wie einen PC, ein Schnurlostelefon, einen Minicomputer (PDA), einen Laptop oder anderen Arten an Kommunikationsgeräten, einen Thread oder einen Prozess, der auf einem dieser Geräte läuft und/oder Objekte, die durch diese Geräte ausgeführt werden können. In einer Implementierung enthält Client 110 eine Anwendung oder ist mit einer Anwendung verknüpft, in dessen Auftrag Client 110 mit dem Speichercluster 120 kommuniziert, um Dateidaten zu lesen oder zu verändern (z. B. schreiben).
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. Wie hier verwendet, könnte eine Komponente Hardware oder eine Kombination aus Hardware und Software umfassen. 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 Referenzen dynamisch erstellt, mutiert, geclont und in verschiedenen Speicherclustern 120 gelöscht werden und eine zugrundeliegende Ebene zur Datenreplizierung (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.
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. In wieder anderen Implementierungen könnten eine oder mehrere Komponenten des Dateisystems 140 eine oder mehrere der Aufgaben durchführen, die laut Beschreibung von einer oder mehreren der Komponenten von Dateisystem 140 durchgeführt werden.
3 ist ein Diagramm von exemplarischen Komponenten von Speichercluster 120. Speichercluster 120 könnte einen Bus 310, einen Prozessor 320, einen Hauptspeicher 330, einen ROM 340, ein Speichergerät 350, ein Eingabegerät 360, ein Ausgabegerät 370 und eine Kommunikationsschnittstelle 380 umfassen. 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 könne einen RAM oder eine andere Art dynamischen Speichergerätes umfassen, das Informationen und Anweisungen für die Ausführung durch den Prozessor 320 speichern könnte. 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 könnte ein Speichercluster 120 Metadaten für gespeicherte Objekte pflegen, die im Dateisystem 140, auf einem oder mehreren durch den Computer lesbaren Medien, sowie auf einem Hauptspeicher 330 und/oder einem Speichergerät 350 gespeichert sind. Ein Speichercluster 120 könnte beispielsweise die Versionsnummer, Zeitstempel, Kategorien und/oder Referenzindikatoren für Objekte innerhalb des Speichergerätes 350 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 könnte einen oder mehrere Mechanismen umfassen, die Informationen für den Betreiber ausgeben, einschließlich eines Displays, einer Leuchtdiode (LED) etc. Die Kommunikationsschnittstelle 380 könnte alle empfangerä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 ist, können Speichercluster 120 auch einen Datenspeicher 410 und eine Speicherbereinigungslogik 420 umfassen. In einer Implementierung, wie in 4 gezeigt, könnte ein Datenspeicher 410 mit einem Speichercluster 120 bereitgestellt werden. In anderen Implementierungen könnte ein Datenspeicher 410 in einem oder mehreren anderen Geräten von System 100 bereitgestellt werden, die mit dem Speichercluster 120 kommunizieren, wie externe Speichergeräte oder Geräte, die mit einem Indexsystem verbunden sind (nicht angezeigt).
Der Datenspeicher 410 kann eine Dokumenttabelle und sekundäre Tabellen umfassen, um einen oder mehrere Indexe für ein Suchsystem bereitzustellen. In einem Beispiel können die Dokumenttabelle und die sekundären Tabellen durch eine Eigenschaft einer URL verschlüsselt werden, um beim Zugriff und/oder der Aktualisierung von Informationen in Verbindung mit der URL zu helfen. Mindestens ein Teil jedes Datenspeichers 410 kann auf mehreren Speicherclustern 120 repliziert werden. Die Anzahl an Repliken für jeden Datenspeicher 410 kann durch den Benutzer vorgegeben werden.
Die Garbage Collector Logik 420 kann eine Logik zum Entfernen von nicht referenziertem Inhalt, wie zuvor gelöschte Dateien, umfassen. Die Garbage Collector Logik 420 kann nicht referenzierten Inhalt zum Beispiel von einem Datenspeicher 410 entfernen. Die Garbage Collector Logik 420 kann beispielsweise bestimme, ob ein Objekt (z. B. ein Dokument) in einem Datenspeicher 410 nicht länger referenziert ist (d. h. ein Objekt ohne Links, die auf das Objekt verweisen) und kann aus dem Speichercluster 120 jegliche Objekte (z. B. ein Dokument) entfernen, die nicht länger über eine Funktion referenziert werden (z. B. eine MapReduce-Funktion), die Speichercluster 120 durchläuft und nicht referenzierte Objekte entfernt. Ein Objekt ist „referenziert” oder „aktiv”, wenn eine Verknüpfung auf dieses Objekt besteht. Somit kann die Garbage Collector Logik 420 unnötige Informationen von Speicherclustern 120 entfernen, während aktive Objekte erhalten bleiben.
Das Entfernen eines Objektes ist nicht so einfach, wie das Löschen des Objektes, da das Objekt in anderen Speicherclustern 120 bestehen könnte. Somit kann die Garbage Collector Logik 420 Löschverhandlungsnachrichten zusammenstellen, die zwischen verschiedenen Speicherclustern 120 von Dateisystemen 140 verschickt werden können. Die Garbage Collector Logik 420 kann ein Objekt löschen, wenn ein verteiltes Einvernehmen erreicht wird (z. B. zwischen allen Speicherclustern 120 an Dateisystemen 140, die eine Replika des Objektes enthalten), dass weder aktive Referenzen noch replizierte Referenzen im System vorhanden sind. Die Garbage Collector Logik 420 kann die Löschverhandlungsnachrichten aus den Metadaten des Objektes löschen, das der Löschverhandlung unterliegt. Die Nachrichten können dann asynchron auf alle anderen Speichercluster 120 repliziert werden, die Repliken dieses Objektes enthalten.
Eine von der Garbage Collector Logik 420 erstellte Nachricht könnte beispielsweise einen „Löschen”-Indiz zum Einleiten einer Löschverhandlung, eine Bestätigungsindiz („ACK”) zur Bereitstellung einer positiven Bestätigung für eine Löschverhandlung, eine negative Bestätigungsindiz („NACK”) für die Bereitstellung einer negativen Bestätigung für eine Löschverhandlung und eine Synchronisationsindiz („GotAll”) zur Bereitstellung einer Zusage umfassen, dass die Bestätigungen von anderen Speicherclustern 120 empfangen wurden. In einer Implementierung können einem Objekt keine neuen Referenzen hinzugefügt werden, für das eine Lösch- oder ACK-Nachricht ausstehend ist. Die Nachrichtenformate und Verwendungen sind nachstehend detaillierter erläutert.
Obwohl 3 exemplarische Funktionskomponenten des Speicherclusters 120 zeigt, könnten die Speichercluster 120 in anderen Implementierungen weniger, weitere, unterschiedliche oder anders angeordnete Funktionskomponenten haben, als in 3 dargestellt ist. 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 NACHRICHTENSTRUKTUR
5 bietet eine Darstellung einer exemplarischen Nachrichtenstruktur 500 für eine Verhandlungsnachricht, die in einer exemplarischen Implementierung verwendet werden kann. Wie in 5 gezeigt, könnte eine Nachrichtenstruktur 500 einen Nachrichtenteil 510, einen Teil zur Speicherclusteridentifizierung 520 und einen Teil zur Verhandlungsanfragenidentifizierung 530 enthalten. Der Nachrichtenteil 510 könnte beispielsweise eine „Delete”-Indiz, eine „ACK”-Indiz, eine „NACK”-Indiz oder eine „GotAll”-Indiz umfassen. Der Teil zur Speicherclusteridentifizierung 520 könnte eine eindeutige Kennung (z. B. eine Cluster-ID) für den Speichercluster 120 umfassen, die die Nachricht im Nachrichtenteil 510 initiiert. Der Teil zur Verhandlungsanfragenidentifizierung 530 könnte eine einmalige Kennung (z. B. ReqID) für die ursprüngliche Löschverhandlung umfassen.
Die Nachrichtenstruktur 500 könnte aufgelistet sein in Form von Nachricht:Cluster:ID:ReqID. Eine Löschverhandlung für ein Objekt könnte beispielsweise durch das Speichercluster 120-1 initiiert werden, mit der Nachricht „Delete:01:5555”, wobei „01” die Cluster-ID für das Speichercluster 120-1 ist und „5555” die ReqID. Eine Bestätigung für die Verhandlung von Speichercluster 120-2 könnte „ACK:02:5555” sein, wobei „02” die Cluster-ID für das Speichercluster 120-2 ist und „5555” die ReqID für die Bestätigung bleibt (und alle zukünftigen Nachrichten, die zur ursprünglichen Verhandlung gehören).
EXEMPLARISCHE PROZESSABLÄUFE
6 ist ein Flussdiagramm eines exemplarischen Prozesses 600 zur Durchführung einer Speicherbereinigung in einem verteilten Multimaster-System zur Datenreplizierung (z. B. Dateisystem 140). In einer Implementierung kann der Prozess 600 durch einen der Speichercluster 120 durchgeführt werden. In einer anderen Implementierung können einige oder alle Bestandteile von Prozess 600 von einem anderen Gerät oder einer Gruppe an Geräten durchgeführt werden, inklusive oder exklusive des Speicherclusters 120. Der Prozess 600 kann periodisch in jedem Speichercluster 120 implementiert werden und könnte einen Scan aller oder eines Teils der Objekte im Speichercluster 120 umfassen. Für spezielle, unten beschriebene Beispiele des Prozesses 600 kann auf das Speichercluster 120-1 des Dateisystems 140 verwiesen werden, wobei das Speichercluster 120-1 eine Cluster-ID von „01” umfasst.
Wie in 6 gezeigt ist, kann der Prozess 600 mit der Durchführung eines Scans der Objekte (Block 610) und der Identifizierung nicht-referenzierter und verhandelter Objekte (Block 620) beginnen. Beispielsweise könnte das Speichercluster 120-1 (beispielsweise mithilfe der Garbage Collector Logik 420) einen Scan aller oder eines Teils der Objekte durchführen, die im Speichercluster 120-1 (z. B. im Datenspeicher 410) gespeichert sind. Der Scan könnte beispielsweise Objekte ohne Referenzen sowie Objekte mit Löschverhandlungsnachrichten identifizieren, indem die Metadaten der entsprechenden Objekte ausgelesen werden.
Es könnte bestimmt werden, ob eine abgeschlossene Löschverhandlung für ein Objekt identifiziert wurde (Block 630). Eine abgeschlossene Löschverhandlung könnte beispielsweise auf eine erfolgreiche oder fehlgeschlagene Löschverhandlung hinweisen. Beispielsweise könnte Speichercluster 120-1 ein Objekt mit Metadaten identifizieren, die entweder eine erfolgreiche oder eine fehlgeschlagene Löschverhandlung bestätigen.
Wenn eine abgeschlossene Löschverhandlung für ein Objekt identifiziert wird (Block 630 – YES), kann das Objekt von der erfolgreichen Löschverhandlung oder der fehlgeschlagenen Löschverhandlungsnachricht durch Einleitung von Speichercluster (Block 640) gelöscht werden. Wenn das Speichercluster 120-1 in einer exemplarischen Implementierung Metadaten in einem Objekt identifiziert, die darauf hinweisen, dass das Speichercluster 120-1 zuvor eine Löschverhandlung für das Objekt eingeleitet hat und wenn alle anderen Speichercluster, die eine Replika des Objektes gespeichert haben, die Löschung des Objektes anerkennen (z. B. durch das Schreiben einer ACK-Nachricht und/oder einer GotAll-Nachricht an die Objektmetadaten), kann Speichercluster 120-1 das Objekt und die dazugehörigen Metadaten löschen. Wenn der Scan in Speicher 120-1 beispielsweise ein Objekt mit „Delete:01:ReqID” und „GotAll:*:ReqID” (wobei „*” die Speichercluster-ID für jeden Speichercluster 120) in allen anderen Speicherclustern erkennt, in denen eine Replika des Objektes gespeichert ist (z. B. Speichercluster 120-2, 120-3 und 120-4) können das Objekt und die Metadaten gelöscht werden. Somit kann das Speichercluster 120-1 der Initiator einer erfolgreichen Verhandlung sein.
Weiterhin in Referenz zu Block 640 aber in einer anderen exemplarischen Implementierung, wenn ein Speichercluster Metadaten in einem Objekt identifiziert, die darauf hinweisen, dass Speichercluster 120-1 zuvor eine Löschverhandlung für das Objekt eingeleitet hat und mindestens ein anderes Speichercluster 120 darauf hingewiesen hat, dass das Objekt nicht gelöscht werden darf (durch das Schreiben einer NACK-Nachricht), kann das Speichercluster 120-1 die Metadaten löschen, die die originale Verhandlungsnachricht enthalten, sowie alle dazugehörigen Nachrichten von dem anderen Speichercluster 120. Wenn der Scan in Speichercluster 120-1 beispielsweise ein Objekt mit „Delete:01:ReqID”, „ACK:*:ReqID” und „NACK:*:ReqID” (wobei „*” die Speichercluster-ID angibt) von allen anderen Speicherclustern 120 erkennt und es mindestens eine NACK-Nachricht gibt, können alle entsprechenden Delete-, ACK- und NACK-Nachrichten aus den Metadaten des entsprechenden Objekts gelöscht werden. Somit kann das Speichercluster 120-1 der Initiator einer fehlgeschlagenen Verhandlung sein.
Wenn keine abgeschlossene Löschverhandlung für ein Objekt (Block 630 – NO) identifiziert wird, kann eine Verhandlungsnachricht basierend auf dem Objektstatus (Block 650) an die Objektmetadaten geschrieben werden. Wie hierin weiter beschrieben ist, können Nachrichten basierend auf einem Objektstatus (z. B. „Delete”, „ACK”, „NACK”, „GotAll”) für die Objektmetadaten in einem Cluster geschrieben und für alle Cluster repliziert werden, die eine Replika des Objektes enthalten. In Abhängigkeit mit dem Objektstatus kann Speichercluster 120-1 beispielsweise eine neue Verhandlungsnachricht zum Löschen eines Objektes schreiben. Das Speichercluster 120-1 kann alternativ eine ACK-Nachricht, eine NACK-Nachricht oder eine GotAll-Nachricht als Antwort auf eine laufende Verhandlung schreiben. Verwendung von Verhandlungsnachrichten gemäß weiterer Beschreibung in Bezug auf 7.
Die Objektmetadaten können für andere Speichercluster (Block 660) repliziert werden. Speichercluster 120-1 könnte beispielsweise die zugrundeliegende Replizierungsebene des verteilten Multimaster-Systems zur Datenreplizierung 140 nutzen, um die Verhandlungsnachrichten) für Speichercluster 120-2, Speichercluster 120-3, Speichercluster 120-4 etc. zu replizieren. Somit können die Verhandlungsnachrichten an andere Cluster mit Repliken der Objektmetadaten verteilt werden und müssen nicht als separate Nachrichten verteilt werden.
Der Prozess 600 kann wiederholt werden, bis alle Objekte im Speichercluster (z. B. Speichercluster 120-1) gescannt wurden und kann periodisch wiederholt werden. Der Prozess 600 kann von jedem der anderen Speichercluster (z. B. Speichercluster 120-2, 120-3, ..., 120-M) im verteilten Multimaster-System zur Datenreplizierung (z. B. Dateisystem 140) ähnlich durchgeführt werden. Somit können die von anderen Speicherclustern replizierten Objektmetadaten Verhandlungsnachrichten als Antwort auf die Verhandlungsnachrichten von Speichercluster 120-1 enthalten. Jedes der Speichercluster könnte auch weiterhin Verhandlungsnachrichten in der Replizierungsebene des Dateisystems austauschen, um asynchrone Verhandlungen für Objekte auszuführen, die durch ein anderes Speichercluster zur Löschung markiert wurden.
7 ist ein Flussdiagramm für einen exemplarischen Prozess 650 zum Schreiben der Verhandlungsnachricht aus 6. Der Prozess 650 kann von einem Speichercluster (z. B. einem der Speichercluster 120) im verteilten Multimaster-System zur Datenreplizierung (z. B. Dateisystem 140) durchgeführt werden. Für spezielle Beispiele des Prozesses 650, kann auf das Speichercluster 120-1 (mit Cluster-ID „01 ”) und Speichercluster 120-2 (mit Cluster-ID „02”) des verteilten Multimaster-Systems zur Datenreplizierung verwiesen werden.
Es kann bestimmt werden, ob es laufende Verhandlungen gibt (Block 710). Beispielsweise kann das Speichercluster 120-1 (mithilfe von z. B. Garbage Collector Logik 420) bestimmen, ob die Metadaten für ein Objekt eine Löschverhandlungsnachricht umfassen. In einer Implementierung könnte eine Löschverhandlung für ein Objekt zuvor von Speichercluster 120-1 oder beispielsweise auch durch ein anderes Speichercluster (z. B. Speichercluster 120-2, 120-3 oder 120-4) eingeleitet worden sein.
Wenn bestimmt wurde, dass es keine laufenden Verhandlungen gibt (Block 710 – NO) kann bestimmt werden, ob Referenzen auf das Objekt (Block 715) verweisen. Beispielsweise könnte Speichercluster 120-1 (z. B. mithilfe der Garbage Collector Logik 420) bestimmen, ob ein bestimmtes Objekt über Referenzen verfügt (z. B. durch Analyse eines gerichteten Referenzdiagramms). Wenn bestimmt wird, dass keine Referenzen auf das Objekt verweisen (Block 715 – NO), kann eine neue „Delete”-Nachricht geschrieben werden (Block 720). Wenn der Scan in Speichercluster 120-1 beispielsweise ein Objekt ohne Referenz findet und keine laufende Verhandlung besteht (z. B. keine „Delete”-Nachricht), kann das Speichercluster 120-1 eine einmalige ReqID erstellen und eine neue Löschverhandlungsnachricht (z. B. „Delete:01:ReqID”) für das Objekt schreiben. Wenn bestimmt wird, dass Referenzen auf das Objekt verweisen (Block 715 – JA), ist keine Nachricht erforderlich (Block 790). Wenn der Scan im Speichercluster 120-1 beispielsweise ein Objekt mit einer Referenz findet und es keine laufenden Löschverhandlungen gibt, erfordert da Objekt zu diesem Zeitpunkt möglicherweise keine weitere Bearbeitung.
Wenn bestimmt wurde, dass es laufende Verhandlungen gibt (Block 710 – JA) kann bestimmt werden, ob Referenzen auf das Objekt verweisen (Block 730). Beispielsweise könnte Speichercluster 120-1 (z. B. mithilfe der Garbage Collector Logik 420) bestimmen, ob ein bestimmtes Objekt über Referenzen verfügt. Wenn bestimmt wird, dass Referenzen auf das Objekt verweisen (Block 730 – JA), kann bestimmt werden, ob eine vorherige negative Bestätigung bereits in den Metadaten des Objekts gespeichert ist (Block 735). So könnte beispielsweise Speichercluster 120-1 (z. B. mithilfe der Garbage Collector Logik 420) bestimmen, bereits eine NACK-Nachricht von Speichercluster 120-1 (z. B. „NACK:01:ReqID”) in die Metadaten des Objekts integriert ist.
Wenn festgestellt wird, dass noch keine vorherige negative Bestätigung in den Metadaten des Objekts gespeichert wurde (Block 735 – NEIN), kann eine negative Bestätigung („NACK”-Nachricht) geschrieben werden (Block 740). Wenn der Scan in Speichercluster 120-1 beispielsweise ein Objekt mit Referenzen und einer laufenden Verhandlung (z. B. „Delete:02:ReqID”) von einem anderen Speichercluster (z. B. Speichercluster 120-2) findet, kann das Speichercluster 120-1 eine negative Bestätigung (z. B. „NACK:01-.ReqID”) in die Metadaten des Objektes schreiben. Wenn bestimmt wird, dass eine vorherige negative Bestätigung bereits in den Metadaten des Objekts gespeichert ist (Block 735 – JA), ist zu diesem Zeitpunkt keine weitere Bearbeitung des Objektes erforderlich (Block 790).
Wenn bestimmt wurde, dass es keine Referenzen auf das Objekt verweisen (Block 730 – NEIN) kann bestimmt werden, ob alle ACKs empfangen wurden (Block 750). So könnte beispielsweise Speichercluster 120-1 (z. B. mithilfe der Garbage Collector Logik 420) bestimmen, ob Bestätigungen von allen Speicherclustern 120 im System 140 (z. B. „ACK:*:ReqID”, wobei „*” die Cluster-ID ist) in die Metadaten des Objekts integriert wurden. Wenn bestimmt wird, dass alle ACKs empfangen wurden (Block 750 – JA), kann eine „GotAll”-Nachricht geschrieben werden (Block 760).
Wenn ein Scan in Speichercluster 120-1 beispielsweise ein Objekt mit einer Delete-Nachricht (z. B. „Delete:02:ReqID”) und Bestätigungen von jedem Speichercluster 120 im System 140 findet (z. B. „ACK:*:ReqID”, wobei „*” die Cluster-ID ist), kann das Speichercluster 120-1 eine Bestätigungsnachricht (z. B. „GotAlkOl:ReqID”) zur Verwendung durch das einleitende Speichercluster 120-2 schreiben. Wenn bestimmt wird, dass alle ACKs nicht empfangen wurden (Block 750 – NEIN), kann bestimmt werden, ob eine vorherige Bestätigung bereits in den Metadaten des Objekts gespeichert ist (Block 770). So könnte beispielsweise Speichercluster 120-1 (z. B. mithilfe der Garbage Collector Logik 420) bestimmen, ob bereits eine ACK-Nachricht von Speichercluster 120-1 (z. B. „ACK:01:ReqID”) in die Metadaten des Objekts integriert ist.
Wenn festgestellt wird, dass noch keine vorherige Bestätigung in den Metadaten des Objekts gespeichert wurde (Block 770 – NEIN), kann eine neue Bestätigung („ACK”-Nachricht) geschrieben werden (Block 780). Wenn der Scan in Speichercluster 120-1 beispielsweise ein Objekt ohne Referenzen und eine laufende Verhandlung (z. B. „Delete:02:ReqID”) von einer anderen Replika (z. B. Speichercluster 120-2) findet, kann das Speichercluster 120-1 eine Bestätigung (z. B. „ACK:01:ReqID”) in die Metadaten des Objektes schreiben. Wenn bestimmt wird, dass eine vorherige Bestätigung bereits in den Metadaten des Objekts gespeichert ist (Block 770 – JA), ist zu diesem Zeitpunkt keine weitere Bearbeitung des Objektes erforderlich (Block 790).
8 ist ein Flussdiagramm für einen exemplarischen Prozess 800 zum Erstellen einer neuen Referenz für ein Objekt in Übereinstimmung mit einer Implementierung, die mit den hierin beschriebenen Systemen und Verfahren konsistent ist. Der Prozess 800 kann von einem Speichercluster (z. B. einem der Speichercluster 120) im verteilten Multimaster-System zur Datenreplizierung (z. B. Dateisystem 140) durchgeführt werden. Für spezielle Beispiele des Prozesses 800 kann auf das Speichercluster 120-1 (mit einer Cluster-ID von „01”) des Dateisystems 140 verwiesen werden.
Ein Referenzindiz für ein Objekt könnte empfangen werden (Block 810). Beispielsweise könnte Speichercluster 120-1 eine Anfrage zum Hinzufügen einer neuen Referenz für ein Objekt erhalten. Die Objektmetadaten können für die Verhandlungsnachrichten geprüft werden, die durch das Speichercluster eingeleitet wurden (Block 820). Speichercluster 120-1 könnte beispielsweise die Metadaten des Objektes prüfen, um jegliche Löschverhandlungsnachrichten sowie insbesondere Delete- oder ACK-Verhandlungsnachrichten zu identifizieren, die zuvor durch das Speichercluster 120-1 eingeleitet wurden (z. B. „Delete:01:ReqID” oder „ACK:01:ReqID”). In hierin beschriebenen Implementierungen könnte Speichercluster 120-1 keine neue Referenz zu einem Objekt schreiben, für das eine laufende Verhandlung in den Objektmetadaten existiert, mit einer Delete- oder ACK-Nachricht, die durch das Speichercluster 120-1 eingeleitet wurde.
Es könnte bestimmt werden, ob Delete- oder ACK-Nachrichten vorliegen (Block 830). Wenn eine Delete- oder ACK-Nachricht vorliegt (Block 830 – JA), kann eine Replika in einem anderen Speichercluster als Failover verwendet werden (Block 840). Wenn Speichercluster 120-1 beispielsweise eine „Delete:01:ReqID”-Nachricht in den Metadaten des Objektes identifiziert, blockiert die Nachricht das Speichercluster 120-1 vom Schreiben einer neuen Referenz für das Objekt. Somit wird eine Anfrage zum Schreiben einer Referenz für ein Objekt im Speichercluster 120-1 an ein anderes Speichercluster (z. B. Speichercluster 120-2) weitergeleitet.
Wenn keine Delete- oder ACK-Nachrichten vorhanden sind (Block 830 – NEIN), kann eine neue Referenz für das Objekt geschrieben werden (Block 850). Beispielsweise könnte Speichercluster 120-1 einfach die angeforderte Referenz für das aktive Objekt schreiben.
BEISPIELE
9 bietet ein exemplarisches Netzwerk, das einen Teil einer exemplarischen Löschverhandlung in Übereinstimmung mit den hierin beschriebenen Implementierungen implementiert. Ein Algorithmus zur Bereinigung könnte periodisch auf allen Speicherclustern XX, YY und ZZ ausgeführt werden und könnte alle Objekte in dem Speichercluster scannen. Nachrichten (z. B. Delete, ACK, NACK, GotAll) können vom Garbage Collector für die Metadaten eines Objektes in einem Cluster (z. B. Speichercluster YY) geschrieben und auf alle anderen Cluster (z. B. Speichercluster XX und ZZ) repliziert werden, die Objektrepliken enthalten.
Der Algorithmus der Speicherbereinigung, der mit dem Garbage Collector verwendet wird, kann in Übereinstimmung mit Richtlinien verwendet werden, die auf den hierin beschriebenen Prinzipien basieren. Wenn der Garbage Collector Scan in Speichercluster YY ein Objekt ohne Referenz findet und keine laufende Verhandlung besteht (z. B. keine „Delete:YY:ReqID”-Nachricht), kann der Garbage Collector in Speichercluster YY eine einmalige ReqID (z. B. 22222) erstellen und „Delete:YY:22222” für die Metadaten des Objektes schreiben. Wenn der Garbage Collector Scan im Speichercluster XX zum ersten Mal eine Löschverhandlung (z. B. Delete:YY:22222) von einer anderen Replika (z. B. von Speichercluster YY) findet, schreibt der Garbage Collector „ACK:XX:22222” wenn das Objekt keine Referenz hat, oder anderenfalls „NACK:XX:22222”. Der Speichercluster XX kann einem Objekt keine neuen Referenzen hinzufügen, für das eine Delete:XX:ReqID- oder 20 ACK:XX:ReqID-Nachricht ausstehend ist. Wenn der Garbage Collector Scan im Speichercluster XX zum ersten Mal Delete:YY:22222 und ACK:*:22222 von allen anderen Repliken findet, könnte der Gasgabe Collector GotAll:XX:22222 schreiben. In diesem Fall ist das Speichercluster XX nicht der Initiator. Wenn der Garbage Collector Scan in Speichercluster YY Delete:YY:22222 und GotAll:*:22222 von allen anderen Repliken findet, werden das Objekt und die Metadaten gelöscht. (Speichercluster YY ist der Initiator einer erfolgreichen Verhandlung.) Wenn der Garbage Collector Scan in Speichercluster YY Delete:YY:22222, ACK:XX:22222 und NACK:ZZ:22222 von allen anderen Repliken findet und es mindestens eine NACK-Nachricht gibt, werden alle Delete-, ACK- und NACK-Nachrichten gelöscht, die zu ReqID 22222 gehören, aus den Metadaten des Objekts gelöscht. In diesem Fall ist das Speichercluster YY der Initiator einer fehlgeschlagenen Verhandlung.
Im Dateisystem aus 9 können die Speichercluster XX, YY und ZZ jeweils zum Speichern von Repliken der Objektdaten zugewiesen sein. 9 zeigt eine Replika („Metadaten 1A”) der Metadaten eines Objektes, „Objekt 1”. Metadaten 1A umfassen eine Löschverhandlung, die von Speichercluster YY eingeleitet wird und an Speichercluster XX geschickt wird. Als Antwort könnte Speichercluster XX eine Antwortnachricht zu den Metadaten des Objekts hinzufügen und die Metadaten-Replika („Metadaten 1B”) an das Speichercluster YY schicken. In dem Dateisystem von 9 würden die Metadaten 1A und Metadaten 1B auch an Speichercluster ZZ repliziert (nicht gezeigt). Anschließende Metadaten-Repliken (nicht gezeigt), die zwischen Speicherclustern XX, YY und ZZ verschickt werden, könnten weitere Verhandlungsnachrichten in den Metadaten von Objekt 1 umfassen, bis eine verteilte Übereinstimmung zur Löschung von Objekt 1 oder zum Belassen von Objekt 1 sowie dem Löschen der Nachrichten in Verbindung mit der Verhandlung, die von Speichercluster YY eingeleitet wurde, erreicht wird.
Die Anwendung der hierin beschriebenen Systeme und/oder Verfahren kann eine Garantie zur Protokollverfügbarkeit bieten, sodass ein Objekt mit einer aktiven Replika nicht gelöscht werden kann und immer verfügbar ist. Wenn es beispielsweise, weiterhin in Bezug auf 9, eine aktive Replika von Objekt 1 im Speichercluster XX gibt, wird die Löschverhandlung des Objektes nicht positiv durch das Speichercluster XX bestätigt, sodass Objekt 1 nicht gelöscht werden kann. Auch wenn eine Löschverhandlung, die von Speichercluster YY eingeleitet wurde, im Gange ist, werden Clone-Anfragen (z. B. Anfragen zum Erstellen einer neuen Objektreferenz) im Speichercluster YY per Failover (z. B. automatisches Umschalten) an die aktive Replika von Objekt 1 im Speichercluster XX fortgesetzt.
Die Anwendung der hierin beschriebenen Systeme und/oder Verfahren kann eine Garantie zur Protokollaktivität bieten. Für eine eingeleitete Löschverhandlungsanfrage, Delete:XX:ReqID, wird der Garbage Collector Scan-Prozess in Speichercluster YY beispielsweise letztendlich ACK:YY:ReqID oder NACK:YY:ReqID schreiben und der Verhandlungsprozess im Speichercluster XX wird mit einer Ja/Nein-Entscheidung abgeschlossen, wenn alle diese ACKs und/oder NACKs repliziert wurden. Dann kann GotAll:*:ReqID durch alle Speichercluster in die Metadaten des Objekts geschrieben werden, wenn die Entscheidung positiv ist, was letztendlich die tatsächliche Löschung durch Speichercluster XX auslösen wird, dass dies über die zugrundeliegenden Replizierungsebene an die anderen Speichercluster YY und ZZ verbreiten wird. Sollte eine aktive Replika bestehen, beispielsweise in Speichercluster ZZ, wird die Entscheidung negativ sein und der Initiator (z. B. Speichercluster XX) kann die Objektmetadaten durch Löschen der Verhandlungsnachrichten bereinigen. Die bereinigten Metadaten werden letztendlich an alle Speichercluster verbreitet, die ACK geschrieben haben und das Objekt wird dort verfügbar gemacht.
Die hierin beschriebene Anwendung der Systeme und/oder Verfahren kann auch eine Garantie dafür bieten, dass keine Phantomreferenzen erneut auftauchen können, nachdem ein Objekt gelöscht wurde. Wenn beispielsweise Objekt 1 zunächst in XX gelöscht wurde. Basierend auf dem Garbage Collection Algorithmus muss es der Fall sein, dass GotAll:*:ReqID von den anderen Speicherclustern auf Speichercluster XX repliziert wurde, bevor die Löschung durchgeführt wurde. Gemäß dieser Schlussfolgerung sind alle Replizierungsdaten, die für Speichercluster YY vorgesehen sind, frei von Phantomreferenzen, die von einem wieder anderen Speichercluster ZZ repliziert werden. Das liegt an der Tatsache, dass der Speichercluster YY GotAll:YY:ReqID schreibt, wenn alle ACKs von den anderen Speicherclustern, insbesondere Speichercluster ZZ, empfangen wurden, während in Speichercluster ZZ nach dem Schreiben von ACK:ZZ:ReqID keine neuen Referenzen hinzugefügt werden konnten und es zu diesem Zeitpunkt keine aktiven Referenzen in Speichercluster ZZ gab. Beachten Sie, dass es weiterhin Referenzen geben könnte, die von Speichercluster ZZ auf Speichercuster YY repliziert werden, nachdem ACK:YY:ReqID geschrieben und bevor ACK:ZZ:ReqID repliziert wurde, aber alle diese Referenzen können gelöscht werden, wenn ACK:ZZ:ReqID auf Speichercluster YY repliziert wird, da die Replizierungsebene die Reihenfolge der Schreibvorgänge auf eine einzelne Replika respektiert.
Die Anwendung der hierin beschriebenen Systeme und/oder Verfahren kann darüber hinaus keine Garantie zur Protokollbereinigung bieten. Wenn eine Löschverhandlung beispielsweise fehlschlägt, wird der Initiator die Delete-, ACK- und NACK-Verhandlungsnachrichten löschen und die Löschung wird an die anderen Objektrepliken per Replizierung verbreitet. Jeglicher Datenabfall wird entfernt, dass der Algorithmus so konfiguriert ist, dass alle relevanten Nachrichten von dem Initiator empfangen werden müssen, bevor die Löschung durch den Initiator durchgeführt werden kann.
SCHLUSSFOLGERUNG
Die hierin beschriebenen Systeme und/oder Verfahren könnten einen asynchron verteilten Algorithmus zur Speicherbereinigung für replizierte Speichercluster bereitstellen, die Garantien für die Verfügbarkeit, Aktivität und Konsistenz bieten. Der Algorithmus verwendet die zugrundeliegende Replizierungsebene zum Transport der Nachrichten zwischen verschiedenen Clustern. Jede Löschverhandlung wird durch die Garbage Collector Logik in einem der Cluster eingeleitet und hat eine einmalige Kennung. Der Algorithmus unterstützt mehrere gleichzeitige Verhandlungen. Ein Objekt kann durch den Initiator gelöscht werden, wenn eine verbreitete Übereinstimmung erreicht wird; anderenfalls wird die Verhandlung ungültig.
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 Garbage Collector Algorithmus verwendet werden, in der Garbage Collectors in verschiedenen Speicherclustern direkt kommunizieren und nicht über die Replizierungsebene.
Dazu kommt, dass die Serie der Blöcke zwar in Bezug auf 6 und 7 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. Somit wurde der Betrieb und das Verhalten der Ausführungsformen ohne Referenz auf den speziellen Softwarecode beschrieben – da davon ausgegangen wird, dass die Software und Steuerungshardware zur Implementierung der Ausführungsformen basierend auf der hier enthaltenen Beschreibung entworfen sind.
Darüber hinaus könnten bestimmte hierin beschriebenen Implementierungen als „Logik” implementiert wird, die eine oder mehr Funktionen ausführen. Diese Logik kann Hardware, wie einen Prozessor, Mikroprozessor, einen anwendungsspezifischen integrierten Schaltkreis oder ein feldprogrammierbares Gate-Array sowie eine Kombination aus Hardware und Software umfassen (z. B. Software, die über einen 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

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

Claims

Gerät oder eine Vielzahl an Geräten in einem verteilten System zur Datenreplizierung, wobei das System Folgendes umfasst: Mittel zum Identifizieren eines Objektes in einem Datenspeicher, das mit einer Verhandlungsnachricht in Verbindung steht; Mittel zum Verknüpfen einer neuen Verhandlungsnachricht mit dem Objekt, wobei die neue Verhandlungsnachricht auf dem Status des Objekts basiert; Mittel zum Replizieren der neuen Verhandlungsnachricht in einem Speichercluster; Mittel zum Empfangen anderer Verhandlungsnachrichten, die mit der Kopie des Objekts verknüpft sind; und Mittel zum Löschen des Objekts, wenn die andere Verhandlungsnachricht auf eine erfolgreiche Verhandlung hindeutet.
System nach Anspruch 1, des Weiteren umfassend: Mittel zum Löschen der neuen Verhandlungsnachricht und der anderen Verhandlungsnachrichten, wenn die anderen Verhandlungsnachrichten auf eine fehlgeschlagene Verhandlung hinweisen.
System, umfassend: einen Speicher zum Speichern von Befehlen und einen Datenspeicher; und einen Prozessor zur Ausführung der Befehle aus dem Speicher zum: Ermitteln des Status eines Objekts im Datenspeicher, sowie des Status hinsichtlich der Frage, ob das Objekt eine Referenz aufweist und ob mit dem Objekt eine Löschverhandlungsnachricht verbunden ist; Schreiben einer neuen Verhandlungsnachricht in die Objektmetadaten je nach Status des Objekts, Replizieren der Metadaten mit der neuen Verhandlungsnachricht auf einem oder mehreren Geräten, und zum Empfangen von anderen Verhandlungsnachrichten, die mit dem Objekt verknüpft sind, über das oder mehrere Geräte, wobei die neue Verhandlungsnachricht und die anderen Verhandlungsnachrichten eine Übereinstimmung hinsichtlich einer Löschverhandlung des Objekts beinhalten.
System nach Anspruch 3, worin die neuen Verhandlungsnachrichten sowie die anderen Verhandlungsnachrichten in mit dem Objekt verknüpften Metadaten enthalten sind und worin die Verhandlungsnachrichten in einer verteilten Datenreplikationsumgebung mit mehreren Masterkopien mittels einer Replikationsschicht ausgetauscht werden.
System nach Anspruch 4, wobei der Prozessor des Weiteren so konfiguriert ist, dass er: die neue Verhandlungsnachricht aus den Metadaten des Objekts löscht, wenn der endgültige Status auf eine fehlgeschlagene Verhandlung hindeutet.
System nach Anspruch 4, wobei der Prozessor des Weiteren so konfiguriert ist, dass er: das Objekt löscht, wenn der endgültige Status auf eine erfolgreiche Löschverhandlung hinweist.
System nach Anspruch 3, wobei die neue Verhandlungsnachricht Folgendes umfasst: einen Indikator für Verhandlungsnachrichten; eine Speichercluster-ID, und eine eindeutige ID der Verhandlungsanforderung.
System nach Anspruch 7, wobei der Indikator für Verhandlungsnachrichten eines der folgenden Elemente enthält: einen Löschindikator zum Initiieren einer Löschverhandlung, einen Bestätigungsindikator zur Bereitstellung einer positiven Bestätigung für die Löschverhandlung, einen negativen Bestätigungsindikator zur Bereitstellung einer negativen Bestätigung für die Löschverhandlung oder einen Synchronisierungsindikator zur Bereitstellung eines Nachweises, dass Bestätigungen von anderen Speicherclustern empfangen wurden.
Computerlesbarer Speicher, der von Computer ausführbare Befehle enthält, wobei der computerlesbare Speicher Folgendes beinhaltet: einen oder mehrere Befehle zum Ermitteln des Status eines Objekts in einem Datenspeicher sowie des Status hinsichtlich der Frage, ob das Objekt eine Referenz aufweist und ob mit dem Objekt eine Löschverhandlungsnachricht verbunden ist; einen oder mehrere Befehle zum Schreiben einer neuen Verhandlungsnachricht, die mit dem Objekt verbunden ist, in die Metadaten des Objekts – je nach Status des Objekts; einen oder mehrere Befehle zum Replizieren der Objektmetadaten mit der neuen Verhandlungsnachricht in einem Speichercluster; einen oder mehrere Befehle zum Empfangen anderer Verhandlungsnachrichten, die mit dem Objekt verknüpft sind, von einem oder mehreren anderen Geräten; und einen oder mehrere Befehle zum Ermitteln der Übereinstimmung für eine Löschverhandlung des Objekts basierend auf anderen mit dem Objekt verknüpften Verhandlungsnachrichten.
Computerlesbarer Speicher nach Anspruch 9, der ferner Folgendes umfasst: einen oder mehrere Befehle zum Löschen der neuen Verhandlungsnachricht sowie der anderen Verhandlungsnachrichten, wenn die Übereinstimmung auf eine fehlgeschlagene Verhandlung hindeutet; und einen oder mehrere Befehle zum Löschen des Objekts, wenn die Übereinstimmung auf eine erfolgreiche Verhandlung hindeutet.
Computerlesbarer Speicher nach Anspruch 9, der ferner Folgendes umfasst: einen oder mehrere Befehle zum Bewahren der Schreibreihenfolge der neuen Verhandlungsnachricht sowie der anderen Verhandlungsnachrichten.
Computerlesbarer Speicher nach Anspruch 9, der ferner Folgendes umfasst: einen oder mehrere Befehle zum Verhindern, dass dem Objekt nach dem Initiieren einer Löschverhandlungsnachricht neue Referenzen hinzugefügt werden.