DE202014010953U1 - Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien - Google Patents

Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien Download PDF

Info

Publication number
DE202014010953U1
DE202014010953U1 DE202014010953.2U DE202014010953U DE202014010953U1 DE 202014010953 U1 DE202014010953 U1 DE 202014010953U1 DE 202014010953 U DE202014010953 U DE 202014010953U DE 202014010953 U1 DE202014010953 U1 DE 202014010953U1
Authority
DE
Germany
Prior art keywords
protocol
instance
placement
stored
object data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE202014010953.2U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of DE202014010953U1 publication Critical patent/DE202014010953U1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/285Clustering or classification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604Improving or facilitating administration, e.g. storage management
    • G06F3/0605Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656Data buffering arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Abstract

Computersystem zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem mit einer Vielzahl von Instanzen, wobei jede der jeweiligen Instanzen Folgendes umfasst: einen Prozessor oder mehrere Prozessoren; Speicher; und ein oder mehrere Programme, die in dem Speicher gespeichert sind, wobei ein oder mehrere Programme Anweisungen umfassen, die von einen oder mehreren Prozessoren ausgeführt werden können, um ein Verfahren zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem durchzuführen, welches Folgendes umfasst: In einer ersten Instanz des verteilten Datenspeichersystems mit einem oder mehreren Prozessoren und einem Speicher, worin der Speicher eine Vielzahl von Objekten und ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren speichert: das Öffnen eines oder mehrerer Protokolle zum Speichern von Objektdatenblöcken, wobei jedem Protokoll eine einzelne entsprechende Platzierungsrichtlinie zugewiesen ist; das Empfangen eines ersten Objekts, das mindestens einen ersten Objektdatenblock umfasst, wobei dem ersten Objekt eine erste Platzierungsrichtlinie zugewiesen ist; das Speichern des ersten Objektdatenblocks in einem ersten Protokoll, dessen zugewiesene Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt, wobei das erste Protokoll nur Objektdatenblöcke für Objekte speichert, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen; für das erste Protokoll, Wiederholen der Empfangs- und Speichervorgänge für eine erste Vielzahl von Objekten, deren zugehörige Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen, bis eine erste Abbruchbedingung auftritt; nachdem die erste Abbruchbedingung auftritt, das Schließen des ersten Protokolls, wodurch verhindert wird, dass zusätzliche Objektdatenblöcke in dem ersten Protokoll gespeichert werden; und das Replizieren des ersten Protokolls zu einer zweiten Instanz des verteilten Datenspeichersystems gemäß der ersten Platzierungsrichtlinie.

Description

  • TECHNISCHES GEBIET
  • Die offenbarten Implementierungen beziehen sich im Allgemeinen auf die Gruppierung zusammengehöriger Objekte in einem verteilten Datenspeichersystem, sowie die Replikation der Objekte unter Verwendung der Gruppierungen. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind, 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.
  • HINTERGRUND
  • Innerhalb der IT-Umgebung von Unternehmen kam es zu einem wesentlichen Wandel der Datenspeicherarchitektur, insofern als das die zentralisierte Architektur durch verteilte Datenspeichersysteme ersetzt wurde. Verteilte Datenspeichersysteme, die aus herkömmlichen Computersystemen aufgebaut sind, können im Vergleich zu monolithischen Datenträger-Subsystemen (Disk-Arrays) eine hohe Leistung, Verfügbarkeit und Skalierbarkeit für neue datenintensive Anwendungen zu einem Bruchteil der Kosten bieten. Um das volle Potential der verteilten Speichersysteme freizugeben, werden die Daten über mehrere Instanzen des verteilten Datenspeichersystems an verschiedenen geografischen Standorten repliziert, wodurch die Verfügbarkeit erhöht und die Netzwerkentfernung zu Clients verringert wird.
  • In einem verteilten Datenspeichersystem werden Objekte dynamisch in den verschiedenen Instanzen des verteilten Datenspeichersystems basierend auf Einschränkungen angeordnet (d. h. erstellt, gelöscht bzw. verschoben). Bestehende Methoden, wie z. B. die lineare Programmierung, können dazu verwendet werden, die Platzierung von Objekten, die diesen Einschränkungen unterliegen, für kleinräumige verteilte Datenspeichersysteme zu bestimmen. Es gibt jedoch nur wenige bestehende Methoden zur effizienten Platzierung von Einschränkungen unterliegenden Objekten, die in einem weltweit verteilten Datenspeichersystem, das Trillionen von Objekten und Petabyte von Daten speichert und weltweit Dutzende von Rechenzentren beinhaltet.
  • Ein Ansatz besteht darin, alle Objektmetadaten zu scannen, die Aktion für jedes einzelne Objekt zu bestimmen und dieselbe Aktion umgehend auszuführen. Dieser Ansatz gewährleistet jedoch keine rechtzeitige Erfüllung von Platzierungseinschränkungen. Das Scannen von Trillionen von Objekten könnte beispielsweise Wochen in Anspruch nehmen. Darüber hinaus erschwert dieser Ansatz, eine gute Ausnutzung von Ressourcen zu erreichen (beispielsweise kann die Dichte von Objekten, die eine Aktion erfordern, in der gesamten Reihe von Objekten weitgehend variieren).
  • ZUSAMMENFASSUNG
  • Die offenbarten Implementierungen verwenden ein neuartiges, hochskalierbares Schema, um die Erfüllung von Objekt-Replikat-Platzierungseinschränkungen für eine große Anzahl von Objekten (z. B. Trillionen oder Quadrillionen) zu erreichen und aufrechtzuerhalten, ohne alle Objekte periodisch scannen zu müssen. Anstatt die Platzierungseinschränkungen für einzelne Objekte zu verwalten, werden viele Objekte in einem zusammenhängenden Protokoll gruppiert und das Protokoll als Ganzes repliziert. Da alle Objekte in einem Protokoll die gleiche Platzierungsrichtlinie haben, reduziert das Replizieren eines Protokolls den Ressourcenaufwand, einschließlich den der Prozessoren, des Speichers und der Netzwerkbandbreite. Darüber hinaus müssen, wenn ein Protokoll repliziert wird, nur Metadaten für das einzelne Protokoll aktualisiert werden, auch wenn das Protokoll einen Inhalt speichert, der Millionen von Objekten entspricht. Die Metadaten für die Objekte identifizieren die Protokolle, in denen der Objektinhalt gespeichert ist und sich nicht ändert, wenn ein Protokoll repliziert wird.
  • Jedes Objekt verfügt über eine zugeordnete Platzierungsrichtlinie, die einer Reihe von Einschränkungen entspricht, die die Anzahl und Standorte der Objektreplikate ausnutzen. In der Regel gibt es eine begrenzte Anzahl von unterschiedlichen Platzierungsrichtlinien in dem System (z. B. 10, 20 oder 50). Durch die Gruppierung von Objekten, die die gleiche Platzierungsrichtlinie in einem Protokoll haben, werden alle Objekte in einem Protokoll manipuliert. Selbst wenn ein Protokoll nur ein paar hundert oder ein paar tausend Objekte enthält, wird der Aufwand für die Erfüllung der Platzierungsrichtlinien stark reduziert. Des Weiteren handelt es sich bei vielen Objekten um Duplikate, die vom Datenspeichersystem nachverfolgt werden. Die Mehrfachobjektreferenzen verweisen jedoch auf die gleiche physische Speicherung des Objektinhalts. Das heißt, eine unbegrenzte Anzahl von Duplikaten kann den gleichen physischen Datenspeicher (z. B. Millionen von Objekten, die auf einen einzelnen physischen Standort verweisen) verwenden. Obwohl Metadaten für die unbegrenzte Anzahl von Objekten nachverfolgt werden, werden die Metadaten nicht geändert, wenn deren Protokoll repliziert wird, wodurch Millionen von Metadaten-Aktualisierungen gespeichert werden.
  • Einige Implementierungen teilen größere Objekte in Datenblöcke auf und verwenden anstatt der gesamten Objekte Datenblöcke als die Basiseinheit der Speicherung. Einige Implementierungen legen beispielsweise eine Datenblockgröße von 2 Megabyte, 4 Megabyte oder 8 Megabyte fest. Wenn ein Objekt innerhalb der Datenblockgröße passt, verfügt ein Objekt über einen einzelnen Datenblock. Wenn ein Objekt jedoch größer als die Datenblockgröße ist, wird das Objekt in eine Anzahl von Datenblöcken aufgeteilt, sodass jeder Datenblock innerhalb der bezeichneten Datenblockgröße liegt. Alle Datenblöcke eines Objekts verwenden die Platzierungsrichtlinie des Objekts und können somit in einem einzelnen Protokoll gruppiert werden. Zum Belastungsausgleich verfügen einige Implementierungen jedoch über mehrere Protokolle für dieselbe Platzierungsrichtlinie, die gleichzeitig für Schreibvorgänge geöffnet ist, wodurch unterschiedliche Datenblöcke für dasselbe Objekt in verschiedenen Protokollen gespeichert werden können.
  • Unternehmensweit verteilte Modem-Datenspeichersysteme erzielen eine hohe Verfügbarkeit und Langlebigkeit, indem sie mehrere Replikate jedes Objekts speichern. Die Standorte dieser Replikate sind in der Regel durch Anforderungen der Platzierungsrichtlinie eingeschränkt und können innerhalb dieser Randbedingungen frei gewählt werden, um verschiedene Leistungskennzahlen des Systems unter aktuellen und/oder vorhergesagten Bedingungen (wie z. B. Ressourcen- und Netzverfügbarkeit) zu optimieren. Aufgrund der Variabilität dieser Faktoren müssen Datenspeichersysteme regelmäßig Replikate einiger Objekte von einem Ort zum anderen verschieben.
  • Replikatverschiebungen können jedoch kostspielig sein, da sie in der Regel von Aktualisierungen der Objektmetadaten (z. B. den Standorten der Objektreplikate) begleitet worden sind. Dieses Problem wird durch De-Duping verschärft, was zu mehreren Objekten (z. B. Tausenden oder Millionen) führt, die sich auf denselben gespeicherten Inhalt beziehen. De-Duping ermöglicht eine effiziente Nutzung des Datenspeichers, kann jedoch möglicherweise die Anzahl der Metadaten-Aktualisierungen erhöhen, nur um einen einzelnen Inhaltsabschnitt zu verschieben.
  • Implementierungen erreichen erhebliche Vorteile, indem Replikate mehrerer Objekte zusammen gruppiert und jede Gruppe als Ganzes verschoben werden. Das ursprüngliche Anlegen dieser Gruppen ist jedoch mit einigen Herausforderungen verbunden. Aus der Sicht der Gruppenverwaltung wäre es sinnvoll, wenn jede Gruppe als Aneinanderreihung der Objekt-Datenblöcke in deren Upload-Reihenfolge (manchmal auch als Protokolldatei bezeichnet) erstellt werden würde. Wenn ein Protokoll eine bestimmte Größe oder ein Zeitlimit erreicht, wird das Protokoll für neue Schreibvorgänge geschlossen (mitunter auch als „Versiegelung” des Protokolls bezeichnet). Nachdem ein Protokoll versiegelt ist, wird es gemäß der Platzierungsrichtlinie repliziert.
  • Leider ist dies die übliche Voraussetzung, von Anfang an über mehr als ein Replikat von jedem Objekt zu verfügen. Wenn andererseits an vielen Orten neue Objekte ankommen und jedes an mehrere Protokolle angehängt werden muss, wird die Beibehaltung der Konsistenz über mehrere Replikate desselben Protokolls schwierig, da sich einzelne Objektdatenblöcke in verschiedenen Replikaten des Protokolls unterschiedlich verschachteln.
  • Einige Implementierungen verwenden replizierte Protokolle und beginnen den Objektlebenszyklus mit zwei Replikaten in verschiedenen Instanzen gleichzeitig. Jedes Protokoll-Replikat hat seinen eigenen Datenblock-Index der Datenblöcke, die von demselben gespeichert wurden, weshalb die spezifische Reihenfolge der Datenblöcke in einem Protokoll-Replikat unbedeutend ist.
  • Beispielimplementierung
  • In einigen Implementierungen wird für jede Instanz und jede Platzierungsrichtlinie, die eine Speicherung an der Instanz gestattet, eine Gruppe von geöffneten Protokolldateien verwaltet. Diese werden mitunter als Primärprotokolle bezeichnet. Bei einem Primärprotokoll handelt es sich um ein Masterreplikat.
  • Wenn ein neues Objekt an eine Instanz gelangt, wird es in ein Primärprotokoll aufgenommen, welches dieser Instanz und der Platzierungsrichtlinie des Objekts zugewiesen ist. Im Allgemeinen gibt es mehrere Protokolle in der Instanz, die der Platzierungsrichtlinie des Objekts zugewiesen sind, um die Schreibbelastung über mehrere Protokolle zu verteilen.
  • Es gibt auch Sekundärprotokolle (die Slave-Replikate) an einigen (oder allen) Instanzen. Jedes Sekundärprotokoll entspricht einem einmaligen Primärprotokoll, kann sich jedoch in einer Instanz befinden, die mit der bezeichneten Richtlinie unvereinbar ist. Eine Platzierungsrichtlinie kann beispielsweise ein Replikat in den USA und ein Replikat in Europa erfordern. Ein Primärprotokoll könnte in den USA geöffnet werden und über ein Sekundärprotokoll verfügen, das sich darüber hinaus in den USA (in einer anderen Instanz) befindet. Während des Zeitraums, in dem das Protokoll für neue Objekte geöffnet ist, werden die besagten einzelnen Objekte repliziert und die Kosten der Replikation minimiert, da sich die zweite Instanz in relativer Nähe befindet. Später, wenn das Protokoll geschlossen ist, könnte das gesamte Protokoll zu einer Zeit, in der mehr Bandbreite zur Verfügung steht, in eine Instanz in Europa repliziert werden. Ein Primärprotokoll und das dazugehörige Sekundärprotokoll haben die gleiche Protokoll-ID, da es sich um Replikate mit demselben Inhalt handelt.
  • Sobald ein Objektdatenblock für ein neues Objekt in einem Primärprotokoll gespeichert ist, wird es auch an eine zweite Instanz übertragen, in der sich das entsprechende Sekundärprotokoll befindet. Somit wird jedes neue Objekt in zwei Instanzen gespeichert. In einigen Implementierungen werden die Objektdatenblöcke an die Instanz mit dem Sekundärprotokoll gesendet, sobald das Primärprotokoll identifiziert ist. Das heißt, nachdem ein Primärprotokoll für einen Datenblock ausgewählt worden ist, ist das entsprechende Sekundärprotokoll bekannt, weshalb die Replikation des Datenblocks initiiert werden kann. Der Prozess muss nicht warten, bis der Datenblock tatsächlich im Primärprotokoll gespeichert ist.
  • Obwohl Implementierungen in der Regel Sekundärprotokolle aufweisen, die dem jeweiligen Primärprotokoll entsprechen, sind Sekundärprotokolle nicht in allen Implementierungen (oder für alle Protokolle innerhalb einer einzelnen Implementierung) erforderlich. Einige Implementierungen bieten einen konfigurierbaren Parameter für den Upload-Modus, der angibt, ob jedes Objekt in einem Sekundärprotokoll gespeichert werden soll. In einigen Implementierungen gilt ein einzelner Upload-Parameter für alle Protokolle, während bei anderen Implementierungen mehrere Parameter vorhanden sind, die angeben, welche Primärprotokolle entsprechende Sekundärprotokolle aufweisen.
  • Die Metadaten jedes Objekts geben das Protokoll an, in dem die jeweiligen Datenblöcke gespeichert ist. In einigen Implementierungen beinhalten die Objektmetadaten ein (Datenblock-ID, Protokoll-ID)-Paar für jeden Inhaltsdatenblock innerhalb des Objekts. In einigen Implementierungen entspricht jede Datenblock-ID der Objekt-ID zzgl. eines Adressabstandes innerhalb des Objekts. Wenn das Objekt beispielsweise die Objekt-ID 517799 hat, die Datenblockgröße 2 Meg und der Objektinhalt etwa 9 Megabyte beträgt, gibt es fünf Datenblöcke, die Datenblock-IDs (517799, 0), (517799, 2097152), (517799, 4194304), (517799, 6291456) und (517799, 8388608). In einigen Implementierungen wird ein Inhalts-Hash oder eine Inhaltsübersicht zur Bildung der jeweiligen Datenblock-IDs verwendet.
  • Wenn ein Primärprotokoll eine bestimmte Größe bzw. ein bestimmtes Alter erreicht, wird es versiegelt. Dies bedeutet, dass keine neuen Schreibvorgänge in denselben erlaubt sind. Gleichzeitig wird eine Nachricht an die Instanz gesendet, in der sich das entsprechende Sekundärprotokoll befindet, um das Sekundärprotokoll zu schließen. Sobald die Primär- und Sekundärprotokolle versiegelt sind, sind die Begriffe „primär” und „sekundär” nicht mehr relevant. Es handelt sich um geschlossene Protokollreplikate.
  • Ein geschlossenes Protokoll wird schließlich in Bezug auf seine Platzierungsrichtlinie repliziert. Dieser Prozess erfüllt letztlich die Platzierungsanforderungen für alle Objektdatenblöcke im Protokoll, da alle Objektdatenblöcke dieselbe Richtlinie haben.
  • Jedes Protokollreplikat hat einen eigenen Datenblock-Index, wodurch das gleiche (Datenblock-ID, Protokoll-ID)-Paar verwendet werden kann, um einen Objektdatenblock, unabhängig von dem physischen Standort des Protokollreplikats oder dem physischen Standort des Datenblocks innerhalb des Protokollreplikats, in einem beliebigen Replikat eines Protokolls zu lokalisieren. Dementsprechend müssen die Replikation und/oder Verschiebungen von Protokollen nicht von Objekt-Metadaten-Aktualisierungen begleitet werden.
  • Vereinfachtes Beispielszenario
  • Man erwäge ein Szenario mit vier Instanzen A, B, C, D und zwei Platzierungsrichtlinien P1 und P2. Richtlinie P1 erfordert 3 Replikate von jedem Objekt, von denen eines auf Band erforderlich ist. Der Bandspeicher ist nur in der Instanz B verfügbar. Die Richtlinie P1 gibt nicht an, von welchen Instanzen die jeweiligen Objekte gespeichert werden sollen. Richtlinie P2 erfordert zwei Replikate für jedes Objekt, die in den Instanzen C und D erforderlich sind. Der Einfachheit halber wird es nur ein einzelnes Protokoll für jede Richtlinie in einer Instanz geben und jedes Objekt wird klein genug sein, um aus einem einzelnen Datenlock bestehen zu können. In dieser exemplarischen Ausführungsform werden Protokoll-Subskripte verwendet, um anzugeben, wo ein Protokoll liegt (z. B. ist J1A ein Replikat des in Instanz A gespeicherten Protokolls J1, während J1B ein weiteres Replikat desselben Protokolls ist, dass in Instanz B gespeichert wurde).
  • Ein Objekt X hat eine Platzierungsrichtlinie P1 und gelangt an die Instanz A. Das Objekt X wird in einem Primärprotokoll J1A gespeichert, welches sich in Instanz A befindet. Eine weitere Kopie wird auf Instanz C übertragen und in dem entsprechenden Sekundärprotokoll J1C gespeichert. Beachten Sie, dass das Sekundärprotokoll die gleiche Protokoll-ID wie das Primärprotokoll aufweist. Später gelangt das Objekt Y zu der Instanz A, zudem wird das Objekt Y der Platzierungsrichtlinie P1 zugewiesen. Das Objekt Y wird in den gleichen Protokollen J1A und J1C. gespeichert. Das Journal J1 speichert ausschließlich Objekte mit der P1-Richtlinie.
  • Ein Objekt Z gelangt zu der Instanz A und Objekt Z hat eine Platzierungsrichtlinie P2. Da die Richtlinie P2 eine Speicherung in den Instanzen C und D (nicht in der Instanz A) erfordert, leitet die Instanz A das Objekt Z zur Speicherung im Primärprotokoll J2C, welches sich in der Instanz C befindet, weiter. In einigen Implementierungen muss sich das Primärprotokoll in einer Instanz befinden, die mit der Richtlinie konsistent ist, wie beispielsweise die Instanz C in diesem Fall. In anderen Implementierungen könnte sich das Primärprotokoll in einer Instanz befinden, die von der Richtlinie nicht einmal erlaubt wird. Diese Anomalie ist jedoch nur von kurzer Dauer, da das Protokoll nach dem Schließen eines Protokolls entsprechend der zugewiesenen Platzierungsrichtlinie verschoben oder repliziert wird. In diesem Beispielszenario befindet sich das Sekundärprotokoll J2B in der Instanz B. Das Objekt Z wird in die Instanz B zur Speicherung in dem entsprechenden Sekundärprotokoll repliziert. Obwohl die Instanz B eine Banddatenspeicherung aufweist, werden geöffnete Protokolle aufgrund der physischen Beschaffenheit eines Bandes im Allgemeinen nicht auf dem Band gespeichert (z. B. wäre der Aufwand für das Einlegen des geeigneten Bandes und die Lokalisierung der geeigneten Schreibposition auf dem Band für kleine Schreiboperationen ineffizient). Das Protokoll J2B kann in einem Dateisystem oder einem anderen Datenspeicher, wie beispielsweise einem Big-Table-Datenspeicher, gespeichert sein.
  • Da es zwei Replikate von jedem Objekt X, Y und Z gibt, wären die jeweiligen Objekte immer noch verfügbar, wenn eine der Instanzen ausfällt. Irgendwann werden die Protokolle J1 und J2 geschlossen.
  • Sobald die Protokolle J1 und J2 versiegelt sind, werden ihre Standorte im Vergleich zu ihren Platzierungsrichtlinien ausgewertet. Aktuell verfügt Protokoll J1 über zwei Replikate, von denen keines auf Band gespeichert ist. Daher wird entweder das Replikat in der Instanz A oder das Replikat in der Instanz C zur Speicherung in einem Bandspeicher auf die Instanz B kopiert. Sobald sie fertig sind, gibt es drei Replikate, von denen einer ein Bandspeicher ist. Dies erfüllt die Anforderungen der Richtlinie P1.
  • Für das Protokoll J2 gibt es zwei Replikate, sie befinden sich jedoch in den Instanzen C und B anstatt in den Instanzen C und D, wie es durch die Richtlinie P2 erforderlich ist. Eine Kopie des Protokolls J2 muss auf die Instanz D repliziert werden. Die Quelle für die Replikation könnte von der Instanz C oder der Instanz B kommen. Je nach den verfügbaren Ressourcen (wie z. B. der Netzwerkbandbreite von Instanz B zu Instanz D gegenüber der Netzwerkbandbreite von Instanz C zu Instanz D) wird eine der beiden Quellen ausgewählt, wodurch ein drittes Replikat des Protokolls J2 in der Instanz D erzeugt wird. Sobald dies der Fall ist, kann die Kopie des Protokolls J2 in der Instanz B gelöscht werden.
  • Beachten Sie zudem, dass die Replikation auf Instanz D nicht sofort erfolgen muss. Wenn die Instanz D belegt oder die Netzwerkbandbreite auf der Instanz D sehr begrenzt ist, kann die Replikation des Protokolls J2 auf die Instanz D aufgeschoben werden.
  • Gemäß einigen Implementierungen wird ein Verfahren zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem bei einer ersten Instanz des verteilten Datenspeichersystems durchgeführt. Die erste Instanz verfügt über einen oder mehrere Server mit jeweils einem oder mehreren Prozessoren und Speichern. Der Speicher speichert eine Vielzahl von Objekten, sowie ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren. Zum Speichern von Objektdatenblöcken werden ein oder mehrere Zeitschriften geöffnet. Jedem Protokoll ist eine einzelne jeweilige Platzierungsrichtlinie zugewiesen. In einigen Implementierungen gibt jede Platzierungsrichtlinie eine Zielanzahl von Objektreplikaten und Zielorten für dieselben Replikate an. Die erste Instanz empfängt ein erstes Objekt, das mindestens einen ersten Objektdatenblock umfasst. Dem ersten Objekt ist eine erste Platzierungsrichtlinie zugewiesen. Der erste Objektdatenblock wird in einem ersten Protokoll gespeichert, dessen zugehörige Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt. Das erste Protokoll speichert Objektdatenblöcke nur für Objekte, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen. Für das erste Protokoll werden die Empfangs- und Speichervorgänge für eine erste Vielzahl von Objekten wiederholt, deren zugehörige Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen, bis eine erste Abbruchbedingung auftritt. In einigen Implementierungen tritt die erste Abbruchbedingung nach einer vorgegebenen Zeitspanne auf oder nachdem das erste Protokoll eine vorbestimmte Größenschwelle überschritten hat. Nach der ersten Abbruchbedingung wird das erste Protokoll geschlossen, wodurch verhindert wird, dass zusätzliche Objektdatenblöcke in dem ersten Protokoll gespeichert werden. Anschließend wird das erste Protokoll gemäß der ersten Platzierungsrichtlinie auf eine zweite Instanz des verteilten Datenspeichersystems repliziert.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist eine konzeptionelle Darstellung eines verteilten Datenspeichersystems gemäß einigen Implementierungen.
  • 2 ist ein Blockdiagramm, das die Elemente eines verteilten Datenspeichersystems gemäß einigen Implementierungen darstellt.
  • 3 ist ein Blockdiagramm eines Servers gemäß einigen Implementierungen.
  • 4 ist ein Blockdiagramm eines Instanz-Servers gemäß einigen Implementierungen.
  • 5 veranschaulicht die Verwendung von Protokollen zur Speicherung von Objektdatenblöcken gemäß einigen Implementierungen.
  • 6 veranschaulicht, wie einige Implementierungen die Speicherung eines neuen Objekts verwalten.
  • 7 veranschaulicht die Struktur eines geöffneten Protokolls gemäß einigen Implementierungen.
  • 8 veranschaulicht, was mit Objektmetadaten und Protokollmetadaten geschieht, wenn ein Protokoll gemäß einigen Implementierungen von einer Instanz zur anderen repliziert wird.
  • 9A9C veranschaulichen ein Verfahren zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem gemäß einigen Implementierungen.
  • Gleiche Bezugszeichen beziehen sich auf die entsprechenden Teile in den Zeichnungen.
  • BESCHREIBUNG DER IMPLEMENTIERUNGEN
  • Vor dem Erörtern von Methoden zur Verwaltung der Platzierung von Objekten in einem verteilten Datenspeichersystem ist es aufschlussreich, ein exemplarisches System zu präsentieren, in dem die besagten Methoden verwendet werden können.
  • Übersicht über das verteilte Datenspeichersystem
  • Wie in 1 dargestellt, beschreiben die offenbarten Implementierungen ein verteiltes Datenspeichersystem. Es gibt mehrere Instanzen 102-1, 102-2 ... 102-N an verschiedenen Standorten auf der Welt 100, die durch Netzwerkkommunikationsverbindungen 104-1, 104-2 miteinander vernetzt sind ... 104-M. Beachten Sie, dass eine „Instanz” in dieser Spezifikation auch als „Standort” bezeichnet wird. Es ist zudem anzumerken, dass eine oder mehrere Instanzen (Standorte) an einem bestimmten physischen Standort (z. B. einem Gebäude, einer Gruppe von Gebäuden innerhalb eines vorbestimmten Abstands voneinander usw.) angeordnet sein können. In einigen Implementierungen entspricht eine Instanz (wie z. B. Instanz 102-1) einer Rechenzentrum. In einigen Implementierungen befinden sich mehrere Instanzen physisch im selben Rechenzentrum. Eine einzelne Implementierung kann sowohl einzelne Instanzen von verschiedenen geografischen Standorten als auch einen oder mehrere Cluster von Instanzen aufweisen, wobei jedes Cluster mehrere Instanzen beinhaltet und sich die Instanzen innerhalb jedes Clusters an einem einzelnen geografischen Standort befinden.
  • Obwohl das Konzeptdiagramm von 1 eine bestimmte Anzahl von Netzwerkkommunikationsverbindungen 104-1, usw. veranschaulicht, können typische Implementierungen auch mehr bzw. weniger Netzwerkkommunikationsverbindungen aufweisen. In einigen Implementierungen gibt es zwei oder mehr Netzwerkkommunikationsverbindungen zwischen demselben Paar von Instanzen. Die Netzwerkkommunikationsverbindungen 104-5 und 104-6 stellen beispielsweise eine Netzwerkverbindung zwischen der Instanz 102-2 und der Instanz 102-6 bereit. In einigen Implementierungen beinhalten die Netzwerkkommunikationsverbindungen Glasfaserkabel. In einigen Implementierungen verwenden einige der Netzwerkkommunikationsverbindungen eine drahtlose Technologie, wie z. B. Mikrowellen. In einigen Implementierungen weist jede Netzwerkkommunikationsverbindung eine spezifizierte Bandbreite bzw. spezifizierte Kosten für die Verwendung dieser Bandbreite auf. In einigen Implementierungen werden über eine oder mehrere der Netzwerkkommunikationsverbindungen Statistiken über die Datenübertragung, einschließlich der Durchsatzrate, Verfügbarkeit und Zuverlässigkeit der Verbindungen usw. geführt. Jede Instanz enthält in der Regel Datenspeicher und zugehörige Datenbanken und verwendet eine Farm von Servercomputern („Instanz-Servern”, wie in 4 dargestellt), um alle Aufgaben auszuführen. In einigen Implementierungen haben eine oder mehrere Instanzen des verteilten Datenspeichersystems eine begrenzte Funktionalität. Die eingeschränkte Funktionalität kann beispielsweise beinhalten, dass sie als Repeater für Datenübertragungen zwischen anderen Instanzen fungiert. Beachten Sie, dass eingeschränkte Funktionalitätsinstanzen einen der Datenspeicher beinhalten können oder auch nicht.
  • 2 ist ein Blockdiagramm, das die Elemente eines verteilten Datenspeichersystems 200 gemäß einigen Implementierungen darstellt. Das verteilte Datenspeichersystem 200 beinhaltet Instanzen 102-1, 102-2, 102-3, 102-4 ... 102-N. Eine jeweilige Instanz 102-1 beinhaltet ein Replikationsmodul 220, das die Objektdatenblöcke 238 zwischen den Instanzen repliziert. In einigen Implementierungen werden die Objektdatenblöcke 238 in den Datenspeichern 224 der jeweiligen Instanz 102-1 gespeichert. Jeder Objektdatenblock 238 umfasst, wie in 6 dargestellt, ein Objekt 226 oder einen Teil eines Objekts 226. Die Datenspeicher 224 können verteilte Datenbanken, Dateisysteme, Sicherungsbänder und jegliche andere Art von Speichersystemen oder -geräten umfassen, die in der Lage sind, Objekte zu speichern. In einigen Implementierungen verwendet das Replikationsmodul 220 eine oder mehrere Replikationswarteschlangen 222-1, 222-2 ..., 222-L, um Objekte 226 oder Protokolle 230 zu replizieren. Replikationsanfragen für die zu replizierenden Objekte oder Protokolle werden in eine Replikationswarteschlange 222 platziert und die Objekte oder Protokolle repliziert, sobald Ressourcen (z. B. Bandbreite) verfügbar sind. In einigen Implementierungen haben Replikationsanfragen in einer Replikationswarteschlange 222 zugeordnete Prioritäten, und die Replikationsanfragen mit höchster Priorität werden repliziert, sobald die Bandbreite verfügbar wird.
  • In einigen Implementierungen erzeugt ein Hintergrundreplikationsprozess Kopien von Objekten oder Protokollen, die auf der Platzierungsrichtlinie 212 und den Zugriffsdaten 210 bzw. einem von einen Statistikserver 208 bereitgestellten globalen Zustand 211 basieren. Die Platzierungsrichtlinien 212 legen fest, wie viele Kopien eines Objekts gewünscht werden, wo sich die Kopien befinden sollten, und in welchen Datentypen die Daten gespeichert werden sollen. Unter Verwendung der Platzierungsrichtlinien 212 zusammen mit den Zugriffsdaten 210 (z. B. die Daten, die Standorte betreffen, auf denen auf Replikate von Objekten zugegriffen wurde, Uhrzeiten, zu denen auf Replikate von Objekten in Standorten zugegriffen wurde, die Häufigkeit der Zugriffe von Objekten an den Standorten usw.) bzw. des von dem Statistikserver 208 bereitgestellten globalen Zustands 211 bestimmt ein Standortzuweisungshintergrundprogramm („Location Assignment Daemon – LAD”) 206, wo neue Kopien eines Objekts oder eines Protokolls erstellt werden sollen und welche Kopien gelöscht werden können. Wenn neue Kopien erstellt werden sollen, werden Replikationsanfragen in eine Replikationswarteschlange 222 eingefügt. In einigen Implementierungen verwaltet das LAD 206 Replikate von Objekten oder Protokollen global für das verteilte Datenspeichersystem 200. Mit anderen Worten, es gibt nur ein LAD 206 in dem verteilten Datenspeichersystem 200. Die Verwendung der Platzierungsrichtlinien 212 und der Betrieb eines LAD 206 werden nachfolgend detaillierter beschrieben.
  • Es ist anzumerken, dass im Allgemeinen eine jeweilige Platzierungsrichtlinie 212 die Anzahl von Replikaten eines zu speichernden Objekts spezifizieren kann, in welchen Datentypen die Replikate gespeichert werden sollen, und an welchen Standorten, die Kopien gespeichert werden sollen usw. In einigen Implementierungen beinhaltet eine jeweilige Platzierungsrichtlinie 212 für ein Objekt Kriterien, die aus der Gruppe ausgewählt sind, die aus einer minimalen Anzahl von Replikaten des Objekts besteht, die in dem verteilten Datenspeichersystem vorhanden sein müssen, eine maximale Anzahl von Replikaten des Objekts, die in dem verteilten Datenspeichersystem vorhanden sein dürfen, Speichergerätetypen, auf denen die Replikate des Objekts gespeichert werden sollen, Standorte, an denen die Replikate des Objekts gespeichert werden können, Standorte, an denen die Replikate des Objekts nicht gespeichert werden können, sowie eine Reihe von Zeiträumen für das Objekt, während denen die Platzierungsrichtlinie für das Objekt gilt. Eine erste Platzierungsrichtlinie kann beispielsweise spezifisch festlegen, dass jedes Objekt in einer Webmail-Anwendung mindestens 2 Replikate und maximal 5 Replikate aufweisen muss, wobei die Replikate der Objekte in Rechenzentren außerhalb von China gespeichert werden können und mindestens 1 Replikat der jeweiligen Objekte auf Band gespeichert werden muss. Eine zweite Platzierungsrichtlinie für die Webmail-Anwendung kann zudem festlegen, dass für Objekte, die älter als 30 Tage sind, mindestens ein Replikat und ein Maximum von 3 Replikaten in dem verteilten Datenspeichersystem 200 gespeichert werden, wobei die Replikate der Objekte in Rechenzentren außerhalb von China gespeichert werden können und mindestens 1 Nachbildung der jeweiligen Objekte auf Band gespeichert werden muss.
  • In einigen Implementierungen interagiert ein Benutzer 240 mit einem Benutzersystem 242, das ein Computersystem oder ein anderes Gerät sein kann, das einen Webbrowser 244 ausführen kann. Eine Benutzeranwendung 246 läuft im Webbrowser und verwendet die vom Datenbankclient 248 bereitgestellte Funktionalität, um auf Daten zuzugreifen, die in dem verteilten Datenspeichersystem 200 unter Verwendung eines Netzwerks gespeichert sind. Bei dem Netzwerk kann es sich um das Internet, ein lokales Netzwerk (LAN), ein Großraumnetzwerk (WAN), ein drahtloses Netzwerk (WLAN), ein lokales Intranet oder eine beliebige Kombination derselben handeln. In einigen Implementierungen verwendet der Datenbank-Client 248 Informationen in einem globalen Konfigurationsspeicher 204, zur Identifizierung einer geeigneten Instanz, um auf die Anfrage zu reagieren. In einigen Implementierungen läuft die Benutzeranwendung 246 auf dem Benutzersystem 242 ohne einen Webbrowser 244. Exemplarische Benutzeranwendungen beinhalten eine E-Mail-Anwendung und eine Online-Videoanwendung.
  • In einigen Implementierungen speichert jede Instanz Objektmetadaten 228 für jedes der im verteilten Datenspeichersystem gespeicherten Objekte. Einige Instanzen speichern Objektmetadaten 228 nur für Objekte, deren Replikate in der Instanz gespeichert sind (und als „lokale Instanzen” bezeichnet werden). Einige Instanzen speichern Objektmetadaten 228 für alle Objekte, die irgendwo im verteilten Datenspeichersystem gespeichert sind (und als „globale Instanzen” bezeichnet werden). Die Objektmetadaten 228 werden mit Bezug auf die 3, 4 und 5 näher beschrieben.
  • In einigen Implementierungen speichert jede Instanz Protokoll-Metadaten 236 für jede der in dem verteilten Datenspeichersystem 200 gespeicherten Protokolle. Einige Instanzen speichern Protokoll-Metadaten 236 nur für die Protokolle, deren Replikate in der Instanz gespeichert sind. Einige Instanzen speichern Journal-Metadaten für alle Protokolle, die im verteilten Datenspeichersystem gespeichert sind. Die Protokollmetadaten werden nachstehend mit Bezug auf die 3, 4, 5 und 8 näher beschrieben.
  • In den Datenspeichern 224 werden mehrere Arten von Protokollen gespeichert. Bei der Mehrheit der Protokolle handelt es sich um geschlossene Protokolle 230. Geschlossene Protokolle 230 speichern keine zusätzlichen Objektdatenblöcke, können jedoch Inhalte löschen und komprimieren. In einigen Ausführungsformen können zwei oder mehrere kleine geschlossene Protokolle 230 für die gleiche Platzierungsrichtlinie 212 zusammengefasst werden, um ein einzelnes geschlossenes Ersatzprotokoll 230 zu bilden. Da die Daten in einem geschlossenen Protokoll 230 gelöscht und komprimiert werden können, können die geschlossenen Protokolle 230 im Laufe der Zeit kleiner werden und auf diese Weise für das Zusammenfügen in Frage kommen.
  • Zusätzlich zu den geschlossenen Protokollen 230 kann eine Instanz 102 geöffnete Protokolle 232 und 234 aufweisen. Wie in 2 angedeutet, werden geöffnete Protokolle entweder als Primärprotokolle 232 oder Sekundärprotokolle 234 bezeichnet. Primärprotokolle 232 und Sekundärprotokolle 234 kommen in Paaren und befinden sich in verschiedenen Instanzen. Wie nachfolgend näher beschrieben, empfängt ein Primärprotokoll 232 einen Datenblock 238 zur Speicherung und übermittelt eine Kopie des Datenblocks 238 an die Instanz, in der das entsprechende Sekundärprotokoll 234 gespeichert ist.
  • 3 ist ein Blockdiagramm eines Servers 300 gemäß einigen Implementierungen. Der Server 300 beinhaltet in der Regel eine oder mehrere Verarbeitungseinheiten (CPUs) 302, eine Uhr 303, die das aktuelle Datum bzw. die Uhrzeit angibt, ein oder mehrere Netzwerk- oder andere Kommunikationsschnittstellen 304, einen Speicher 314 und einen oder mehrere Kommunikationsbusse 312, dieselben Komponenten miteinander zu verbinden. Die Kommunikationsbusse 312 können Schaltkreise (mitunter Chipsätze genannt) beinhalten, die die Kommunikation zwischen Systemkomponenten untereinander verbinden und steuern. In einigen Implementierungen handelt es sich bei der Uhr 303 um eine lokale Uhr, die regelmäßig mit einem Uhrzeitserver (z. B. einer Quorum-Uhrzeitserver oder einem anderen Uhrzeitserver in einem Netzwerk usw.) synchronisiert wird. Der Server 300 kann optional eine Benutzerschnittstelle 306 mit einem Anzeigegerät 308 und Eingabegeräten 310 (wie z. B. Tastatur, Maus, Touchscreen, Tastenfeldern usw.) beinhalten. Der Speicher 314 beinhaltet einen Hochgeschwindigkeitsspeicher mit wahlfreiem Zugriff, wie z. B. DRAM, SRAM, DDR-RAM oder andere Festspeichergeräte mit wahlfreiem Zugriff; und kann einen nichtflüchtigen Speicher, wie z. B. eine oder mehrere magnetische Plattenspeichergeräte, optische Plattenspeichergeräte, Flashspeichergeräte oder andere nichtflüchtige Festspeichergeräte beinhalten. Der Speicher 314 kann optional ein oder mehrere Speichergeräte beinhalten, die entfernt von den CPU(s) 302 angeordnet sind. Der Speicher 314 oder alternativ die nichtflüchtige(n) Speichergerät(e) innerhalb des Speichers 314 umfasst bzw. umfassen ein computerlesbares Speichermedium. In einigen Implementierungen speichert der Speicher 314 die folgenden Programme, Module und Datenstrukturen oder eine Teilmenge davon:
    • • ein Betriebssystem 316, das Verfahren zur Abwicklung verschiedener grundlegender Systemdienstleistungen sowie zur Ausführung von Hardware-abhängigen Aufgaben beinhaltet;
    • • Ein Kommunikationsmodul 318, das zum Verbinden des Servers 300 mit anderen Computer über eine oder mehrere Kommunikationsschnittstellen 304 (per Kabel oder drahtlos) und ein oder mehrere Kommunikationsnetzwerke, wie z. B. das Internet, andere Großraumnetzwerke, lokale Netzwerke, regionale Netzwerke, und so weiter verwendet wird;
    • • Ein optionales Benutzerschnittstellenmodul 320, das über die Eingabegeräte 310 Befehle von dem Benutzer empfängt und in dem Anzeigegerät 308 Benutzeroberflächenobjekte erstellt;
    • • die Konfiguration 204, wie hier beschrieben;
    • • das LAD 206, wie hier beschrieben;
    • • Zugriffsdaten 210, wie hier beschrieben;
    • • den globalen Zustand 211, wie hier beschrieben;
    • • die Platzierungsrichtlinien 212, wie hier beschrieben;
    • • Objektmetadaten 228 für die im verteilten Datenspeichersystem gespeicherten Objekte. Die Objektmetadaten 228 können eine Objekt-ID 330 beinhalten, die das Objekt in dem verteilten Datenspeichersystem eindeutig identifiziert. Die Metadaten 228 können den Autor 332 des Objekts beinhalten, bei welchem es sich um einen Namen bzw. eine Kennung einer Person oder Entität (z. B. eine E-Mail-Adresse) handeln kann. In einigen Implementierungen ist die Kennung eindeutig. Die Metadaten können einen Datumsstempel oder Zeitstempel 334 beinhalten, der angibt, wann das Objekt erstellt (z. B. zum verteilten Datenspeichersystem hochgeladen) wurde. Die Metadaten können die Größe 336 des Objekts beinhalten, die in der Regel in Byte oder Zuordnungsblöcken gemessen wird. Die Metadaten beinhalten eine zugewiesene Platzierungsrichtlinie 338, die einzeln oder basierend auf anderen Kriterien zugewiesen werden kann (z. B. können alle aus den USA hochgeladenen Videos dieselbe zugewiesene Platzierungsrichtlinie 338 haben). Die Verwendung von Platzierungsrichtlinien wird nachfolgend mit Bezug auf die 56 und 9A9C näher beschrieben. Die Metadaten 228 beinhalten eine Reihe von Datenblock-IDs 346, die die Inhaltsdatenblöcke für jedes Objekt identifizieren. In einigen Implementierungen wird eine Datenblock-ID als ein Adressabstand innerhalb eines Objekts angegeben. Der erste Datenblock hat beispielsweise einen Adressabstand von 0. In einigen Implementierungen werden die Adressabstände in Megabyte angegeben. In einigen Implementierungen sind die Datenblock-IDs eindeutige Kennungen (wie z. B. eine GUID). In einigen Implementierungen wird jede Datenblock-ID durch Aneinanderreihung der Objekt-ID mit dem Adressabstand des Datenblocks gebildet. In einigen Implementierungen wird die Datenblock-ID unter Verwendung eines Inhalts-Hash oder einer Inhaltsübersicht gebildet. Jeder Datenblock-ID ist eine entsprechende Protokoll-ID 348 zugewiesen, die angibt, in welchem Protokoll der entsprechende Datenblock gespeichert ist; sowie
    • • die Protokoll-Metadaten 236 für jedes im verteilten Datenspeichersystem 200 gespeicherte Protokoll. Die Protokollmetadaten 236 beinhalten eine Protokoll-ID 370 für jedes Protokoll und eine Reihe von Protokollstandorten 372, an denen das Protokoll gespeichert ist. Die Protokollstandorte 372 spezifizieren jede Instanz 102, in der das Protokoll gespeichert ist, und können den Datenspeicher 224 in der Instanz 102 spezifizieren, die das Protokoll speichert. Die Protokollmetadaten 236 beinhaltet zudem die Platzierungsrichtlinien-ID 374, die jedem Protokoll zugewiesen ist. Die Platzierungsrichtlinien-ID 374 identifiziert die eindeutige Platzierungsrichtlinie 212, die dem Protokoll zugewiesen ist.
  • Jedes der oben genannten Elemente kann in einer oder mehreren der zuvor erwähnten Speichergeräte gespeichert sein und entspricht einer Gruppe von Befehlen zum Ausführen einer oben beschriebenen Funktion. Die Gruppe von Befehlen kann von einem oder mehreren Prozessoren (z. B. den CPUs 302) ausgeführt werden. Die oben genannten Module oder Programme (d. h. Gruppen von Befehlen) müssen nicht als separate Softwareprogramme, Prozeduren oder Module implementiert werden, weshalb verschiedene Teilmengen dieser Module in verschiedenen Implementierungen kombiniert oder anderweitig neu angeordnet werden können. In einigen Implementierungen speichert der Speicher 314 ggf. eine Teilmenge der oben identifizierten Module und Datenstrukturen. Des Weiteren kann der Speicher 314 zusätzliche Module und Datenstrukturen speichern, die oben nicht beschrieben sind.
  • Obwohl 3 einen „Server” darstellt, ist 3 vielmehr als funktionelle Beschreibung der verschiedenen Merkmale vorgesehen, die in einer Gruppe von Servern 300 vorhanden sein können, als ein strukturelles Schema der hierin beschriebenen Implementierungen. In der Praxis und wie unter Fachleuten auf dem Gebiet bekannt, könnten gesondert dargestellte Elemente kombiniert und einige getrennt werden. Einige gesondert in 3 dargestellten Elemente könnten beispielsweise auf einzelnen Servern implementiert werden, während einzelne Elemente durch einen oder mehrere Server implementiert werden könnten. Die tatsächliche Serveranzahl und wie die Funktionen unter ihnen zugewiesen werden variiert von einer Implementierung zur anderen und kann teilweise von der Menge des Datenverkehrs abhängen, die das System während der Spitzennutzungszeiträume, sowie während der durchschnittlichen Nutzungszeiträume verarbeiten muss. In einigen Implementierungen befinden sich eine Untermenge des LADs 206, der Zugriffsdaten 210, des globalen Zustands 211 und der Platzierungsrichtlinien 212 auf separaten Servern. Das LAD 206 kann sich beispielsweise in einem Server (oder einer Gruppe von Servern) befinden, wobei sich die Zugriffsdaten 210 und der globale Zustand 211 in einem Statistikserver 208 (oder einer Gruppe von Statistikservern 208) befinden und von demselben bzw. derselben verwaltet werden können; die Platzierungsrichtlinien 212 können sich auf einem anderen Server (oder einer Gruppe von anderen Servern) befinden.
  • 4 ist ein Blockdiagramm eines Instanz-Servers 400 für eine Instanz 102 gemäß einigen Implementierungen. Der Instanz-Server 400 beinhaltet in der Regel eine oder mehrere Verarbeitungseinheiten (CPUs) 402 zum Ausführen von Modulen, eine Uhr 403, die das aktuelle Datum bzw. die Uhrzeit, die im Speicher 414 gespeicherten Programme bzw. Befehle angibt und auf diese Weise Verarbeitungsvorgänge ausführt, eine oder mehrere Netzwerk-Kommunikationsschnittstellen 404, einen Speicher 414 und einen oder mehrere Kommunikationsbusse 412, um diese Komponenten miteinander zu verbinden. In einigen Implementierungen entspricht die Uhr 403 einer lokalen Uhr, die regelmäßig mit einem Uhrzeitserver (z. B. einem Quorum-Uhrzeitserver oder einem anderen Uhrzeitserver in einem Netzwerk usw.) synchronisiert wird. In einigen Implementierungen beinhaltet der Instanz-Server 400 eine Benutzerschnittstelle 406 mit einem Anzeigegerät 408 und einem oder mehreren Eingabegeräten 410. In einigen Implementierungen beinhaltet der Speicher 414 einen Hochgeschwindigkeitsspeicher mit wahlfreiem Zugriff, wie z. B. DRAM, SRAM, DDR-RAM oder andere Festspeichergeräte mit wahlfreiem Zugriff. In einigen Implementierungen beinhaltet der Speicher 414 einen nichtflüchtigen Speicher, wie z. B. ein oder mehrere magnetische Plattenspeichergeräte, optische Plattenspeichergeräte, Flashspeichergeräte oder andere nichtflüchtige Festspeichergeräte. In einigen Implementierungen beinhaltet der Speicher 414 ein oder mehrere Speichergeräte, die entfernt von dem bzw. von den Prozessoren 402 angeordnet sind. Der Speicher 414 bzw. alternativ dazu die nichtflüchtige(n) Speichergerät(e) innerhalb des Speichers 414 umfasst bzw. umfassen ein computerlesbares Speichermedium. In einigen Implementierungen speichert der Speicher 414 oder das computerlesbare Speichermedium des Speichers 414 die folgenden Programme, Module und Datenstrukturen oder eine Teilmenge derselben:
    • • ein Betriebssystem 416, das Verfahren zur Abwicklung von verschiedenen grundlegenden Systemdienstleistungen und zur Ausführung von Hardware-abhängigen Aufgaben;
    • • Ein Kommunikationsmodul 418, das zum Verbinden des Instanz-Servers 400 mit anderen Instanz-Servern oder Computern über eine oder mehrere Kommunikationsnetzwerkschnittstellen 404 (per Kabel oder drahtlos) und ein oder mehrere Kommunikationsnetzwerke, wie z. B. das Internet, andere Großraumnetzwerke, lokale Netzwerke, regionale Netzwerke und so weiter;
    • • Ein optionales Benutzerschnittstellenmodul 420, das über die Eingabegeräte 410 Befehle von dem Benutzer empfängt und im Anzeigegerät 408 Benutzeroberflächenobjekte erstellt;
    • • Ein Replikationsmodul 220 und Replikationswarteschlangen 222, wie hier beschrieben;
    • • Datenspeicher 224 (z. B. verteilte Datenbanken, Dateisysteme, Speicherbänder, Big Tables usw.), die die Objektdatenblöcke 238, wie mit Bezug auf 3 beschrieben, in den Protokollen 230, 232 und 234 speichern;
    • • Objektmetadaten 228 und entsprechende Metadatenelemente 330338, 346 und 348, wie in 3 in Bezug auf Server 300 beschrieben; und
    • • Protokollmetadaten 236 und entsprechenden Protokollmetadatenelemente 370, 372 und 374, wie in 3 in Bezug auf Server 300 beschrieben.
  • Jedes der oben genannten Elemente kann in einem oder mehreren der zuvor erwähnten Speichergeräte gespeichert sein und entspricht einer Gruppe von Befehlen zum Ausführen einer oben beschriebenen Funktion. Die Gruppe von Befehlen kann von einem oder mehreren Prozessoren (z. B. den CPUs 402) ausgeführt werden. Die oben genannten Module oder Programme (d. h. Gruppen von Befehlen) müssen nicht als separate Softwareprogramme, Prozeduren oder Module implementiert werden, weshalb verschiedene Teilmengen dieser Module in verschiedenen Implementierungen kombiniert oder anderweitig neu angeordnet werden können. In einigen Implementierungen speichert der Speicher 414 eine Teilmenge der oben identifizierten Module und Datenstrukturen. Des Weiteren kann der Speicher 414 zusätzliche Module und Datenstrukturen speichern, die nicht oben beschrieben sind.
  • Obwohl 4 einen „Instanz-Server” darstellt, ist 4 vielmehr als funktionelle Beschreibung der verschiedenen Merkmale vorgesehen, die in einer Reihe von Instanz-Servern 400 vorhanden sein können, als ein strukturelles Schema der hierin beschriebenen Implementierungen. In der Praxis und wie unter Fachleuten auf dem Gebiet bekannt, könnten gesondert dargestellte Elemente kombiniert und einige getrennt werden. Einige gesondert in 4 dargestellten Elemente könnten beispielsweise auf einzelnen Servern implementiert werden, während einzelne Elemente durch einen oder mehrere Server implementiert werden könnten. Die tatsächliche Serveranzahl und wie die Funktionen unter ihnen zugewiesen werden variiert von einer Implementierung zur anderen und kann teilweise von der Menge des Datenverkehrs abhängen, die das System während der Spitzennutzungszeiträume, sowie während der durchschnittlichen Nutzungszeiträume verarbeiten muss. In einer einzelnen Instanz 102 können beispielsweise hundert Instanz-Server 400 oder Tausende von Instanz-Servern 400 vorhanden sein.
  • In einigen Implementierungen wird, um den Clients schnellere Reaktionen und Fehlertoleranzen bereitzustellen, jedes Programm bzw. jeder Prozess, der auf einer Instanz ausgeführt wird, auf mehrere Computer verteilt. Die Anzahl der Instanz-Server 400, die jedem der Programme oder Prozesse zugewiesen sind, kann variieren und hängt von der Auslastung ab.
  • 5 zeigt die Verwendung von Protokollen zur Speicherung von Objektdatenblöcken gemäß einigen Implementierungen. 5 zeigt einen Datenspeicher 224, sowie einen Teil der Objektmetadaten 228 und einen Teil der Protokollmetadaten 236 in einer exemplarischen Instanz 102. In diesem Datenspeicher 224 sind viele Protokolle 230, 232 und 234 gespeichert, sodass es sinnvoll ist, sie visuell in einem zweidimensionalen Raster zu strukturieren. (Natürlich ist die visuelle Anzeige für die tatsächliche physische Speicherung von Protokollen in einem Datenspeicher irrelevant.) In der Figur sind die Protokolle in „Protokollzeilen” aufgeteilt, wobei jede Zeile einer einzelnen Platzierungsrichtlinie 212 entspricht. Beispielsweise entspricht die erste Zeile 502-P1 der Platzierungsrichtlinie P1 (212) und schließt geschlossene Protokolle 230, geöffnete Primärprotokolle 232 und geöffnete Sekundärprotokolle 234 ein. Sämtliche dieser Protokolle in der ersten Zeile 502-P1 sind der Platzierungsrichtlinie P1 zugewiesen. Die zweite Zeile 502-P2 entspricht der Platzierungsrichtlinie P2 (212), und die letzte Zeile 502-PN entspricht der Platzierungsrichtlinie PN (212). In der Regel ist die Anzahl der Platzierungsrichtlinien gering, also z. B. 10, 20, 50 oder vielleicht 100. Wächst die Anzahl der Platzierungsrichtlinien, wird die Verwaltung von Objektreplikaten ineffizienter.
  • Die Protokolle in dem Datenspeicher 224 werden in 5 ebenfalls visuell in zwei Spalten aufgeteilt. Die erste Spalte identifiziert die geschlossenen Protokolle 230, die der Mehrzahl der Protokolle entspricht. Die zweite Spalte beinhaltet die geöffneten Primärprotokolle 232 und die geöffneten Sekundärprotokolle 234. Wie durch die verschiedenen Rechtecke 238 in jedem Protokoll dargestellt, enthält jedes Protokoll (ob geschlossen 230, geöffnet und primär 232 oder geöffnet und sekundär 234) Objektdatenblöcke 238. Die Objektdatenblöcke können verschiedene Größen haben, Implementierungen legen jedoch in der Regel eine feste maximale Größe (z. B. 2 Megabyte, 4 Megabyte oder 8 Megabyte) fest. Die Darstellung von Objektdatenblöcken 238 innerhalb eines Protokolls vermittelt die Tatsache in korrekter Weise, dass ein Protokoll mehrere Objektdatenblöcke verschiedener Größen speichert, ansonsten jedoch für die tatsächliche physische Speicherung von Objektdatenblöcken nicht repräsentativ ist (z. B. gibt es im Allgemeinen keinen unbenutzten Speicherplatz zwischen Objektdatenblöcken, da jeder neue Objektdatenblock 238 am Anfang des nicht zugewiesenen Speicherplatzes angefügt wird).
  • 5 veranschaulicht, dass verschiedene Kombinationen von geöffneten Protokollen 232 und 234 für die jeweiligen Platzierungsrichtlinien möglich sind. Um die verschiedenen in den Figuren und Beschreibungen enthaltenen Protokollreplikate zu identifizieren, wird mitunter eine dreiteilige Kennzeichnung, wie z. B. „232.P4.7”, verwendet. Der erste Teil (z. B. „232”) identifiziert die Art des Protokolls (230 = geschlossen, 232 = geöffnet, 234 = geöffnet sekundär); der zweite Teil (z. B. „P4”) spezifiziert die Platzierungsrichtlinie für das Protokoll; und der dritte Teil (z. B. „7”) spezifiziert nur eine fortlaufende Nummer für das Protokoll (z. B. spezifiziert die „7” in „232.P4.7” das siebte geöffnete Protokoll für die Platzierungsrichtlinie P4).
  • Wie in 5 veranschaulicht, gibt es für die Platzierungsrichtlinie P1 ein einzelnes geöffnetes Primärprotokoll 232.P1.1 und keine geöffneten Sekundärprotokolle. Für die Platzierungsrichtlinie P2 gibt es zwei geöffnete Primärprotokolle 232.P2.1 und 232.P2.2. Für die Platzierungsrichtlinie PN gibt es ein geöffnetes Primärprotokoll 232.PN.1 und ein geöffnetes Sekundärprotokoll 234.PN.1. Wie diese exemplarischen Ausführungsformen veranschaulichen, kann die Anzahl der geöffneten Primärprotokolle 232 und der geöffneten Sekundärprotokolle 234 unter den Platzierungsrichtlinien variieren und ist in der Regel für jede Richtlinie 212 basierend auf der erwarteten Anzahl neuer Objekte 226 für jede Platzierungsrichtlinie 212 und den gewünschten Standorten für dieselben Objekte 226 konfiguriert.
  • Jede Instanz 102 speichert zudem, wie zuvor mit Bezug auf 3 beschrieben, sowohl Objektmetadaten 228 als auch Protokollmetadaten 236. Für jedes Objekt 226 beinhalten die Objektmetadaten 228 die Objekt-ID 330 (die das Objekt eindeutig identifiziert), eine Gruppe von einer oder mehreren Datenblock-IDs 346, die die Objekt-Datenblöcke 238 von dem Objekt identifizieren, sowie eine jeder Datenblock-ID 236 zugewiesene Protokoll-ID 348. Wenn ein Objekt mehrere Datenblöcke 238 aufweist, sind die Datenblöcke 238 (z. B. zum Belastungsausgleich) nicht zwangsläufig alle in demselben Protokoll gespeichert, weshalb die jeder Datenblock-ID 346 zugewiesene Protokoll-ID 348 von den Objektmetadaten 228 nachverfolgt werden muss.
  • Jede Instanz 102 speichert auch Protokollmetadaten 236 für jedes in der Instanz 102 gespeicherte Protokoll. Die Metadaten 236 beinhalten eine Protokoll-ID 370 für jedes Protokoll, sowie eine Reihe von Standorten 372. In einigen Implementierungen identifiziert eine Standort-ID eine Instanz, in der das Protokoll gespeichert ist. In einigen Implementierungen identifiziert eine Standort-ID zudem einen Datenspeicher in der spezifizierten Instanz. In einigen Implementierungen werden eine Instanzkennung und eine Datenspeicherkennung als separate Attribute für jedes Protokoll gespeichert. In einigen Implementierungen wird ein Protokoll ggf. in einer einzelnen Instanz (z. B. einem Dateisystemdatenspeicher und einem Sicherungsbanddatenspeicher) in zwei oder mehr Datenspeicher gespeichert. Die Protokollmetadaten 236 beinhalten zudem eine Platzierungsrichtliniendatei 374, die die eindeutige den jeweiligen Protokollen entsprechende Platzierungsrichtlinie 212 spezifiziert. Jedes Protokoll speichert nur Objektdatenblöcke 238, deren Platzierungsrichtlinien 338 mit der Platzierungsrichtlinie des Protokolls übereinstimmen.
  • 6 veranschaulicht, wie einige Implementierungen die Speicherung eines neuen Objekts 226 verwalten. Wie in 6 veranschaulicht, hat jedes neue Objekt einen Objektinhalt (d. h. das Objekt 226 selbst), sowie eine Objekt-ID 330 (z. B. 58440912) und eine zugewiesene Platzierungsrichtlinie 330 (z. B. P3). Das neue Objekt 226 kann von vielen verschiedenen Anwendungen 246 kommen, wie beispielsweise einer Online-E-Mail-Anwendung, einer Video-Sharing-Website und so weiter. Das verteilte Datenspeichersystem 200 empfängt das neue Objekt 226 und leitet (602) das neue Objekt 226 zu einer geeigneten Instanz, wie z. B. der Instanz 102-1. In einigen Implementierungen leitet die Anwendung 246 das neue Objekt 226 zu einer spezifischen Instanz 102-1. Wenn die von der Anwendung 246 ausgewählte Instanz 102-1 nicht richtig ist, leiten einige Implementierungen das Objekt 226 zu einer geeigneten Instanz weiter (wenn z. B. die Platzierungsrichtlinie 212 keine Speicherung in Europa spezifiziert und das Objekt 226 bei einer Instanz in Europa empfangen wird, kann die Instanz das Objekt 226 zu einer anderen Instanz weiterleiten).
  • Obwohl die meisten Objekte eine mäßige Größe aufweisen (z. B. weniger als 300 Kilobyte), gibt es einige große Objekte. Einige Implementierungen teilen (604) große Objekte in mehrere Datenblöcke 238 auf. Im Allgemeinen legt jede Implementierung eine Datenblockgröße oder einen konfigurierbaren Parameter fest, um die Datenblockgröße festzulegen, die in der Regel in Megabyte (z. B. 2, 4, 8, 16 oder 32 Megabyte) angegeben ist. Jedes Objekt, das die Datenblockgröße überschreitet, wird in mehrere Datenblöcke aufgeteilt, und jedes Objekt, das eine Größe aufweist, die gleich oder kleiner als die Datenblockgröße ist, besteht aus einem einzelnen Datenblock. In der Darstellung in 6 gibt es drei Blöcke C1, C2 und C3. In dieser Darstellung hat jeder der Datenblöcke eine alphanumerische Datenblock-ID 346 mit 7 Zeichen, es sind jedoch viele alternative Datenblock-ID-Formate möglich, die die Datenblöcke in den jeweiligen Objekten eindeutig identifizieren. In einigen Implementierungen wird eine Datenblock-ID 346 unter Verwendung eines Inhalts-Hash oder einer Inhaltsübersicht erstellt.
  • In einigen Implementierungen können viele Objektduplikate (z. B. eine E-Mail-Anhang, die an eine Gruppe von Personen gesendet und anschließend an viele zusätzliche Personen weitergeleitet wird) vorhanden sein, sodass eine Deduplizierung für eine effiziente Speicherung angebracht sein kann. Somit wird in einigen Ausführungsformen der Inhalt jedes neuen Datenblocks 238 (z. B. unter Verwendung eines Inhalts-Hash oder einer Inhaltsübersicht) mit vorhandenen Objektdatenblöcken 238 verglichen (606), um ausschließlich (606) „neue” Datenblöcke 238 in einem geöffneten Primärprotokoll zu speichern. Wie in 5 dargestellt, ist der Datenblock C2 neu und entspricht der Platzierungsrichtlinie P3, sodass der Datenblock C2 in einem geöffneten Primärprotokoll 232.P3.1 gespeichert wird, das der Platzierungsrichtlinie P3 entspricht.
  • Unabhängig davon, ob der Objektdatenblock C2 neu ist, speichert die Instanz 102-1 (608) Objektmetadaten 228 für den Datenblock 238. Wie zuvor unter Bezugnahme auf die 3 bis 5 beschrieben, beinhalten die Metadaten 228 die Objekt-ID 330, die Datenblock-ID 346 und die Protokoll-ID 348 für das Protokoll, in dem jeder Datenblock gespeichert wird. In einigen Implementierungen ist die Datenblock-ID 346 für einen Objektdatenblock 238 nur der Adressabstand zum Anfang des Datenblocks 238 innerhalb des Objekts. Die in 6 dargestellten Objektmetadaten 228 veranschaulichen zudem, dass die Datenblöcke für ein einzelnes Objekt nicht in demselben Protokoll gespeichert werden müssen. Die Datenblöcke C1 und C3 (Datenblock-IDs C190056 und C098663) befinden sich im Protokoll 232.P3.2 mit Protokoll-ID J77298045, während sich Datenblock C2 (Datenblock-ID C250116) mit Protokoll-ID J82117094 im Protokoll 232.P3.1 befindet.
  • Der Datenblock C2 wird zur Speicherung in dem Sekundärprotokoll 234.P3.1 zu Instanz 102-2 übermittelt (610), während die Datenblöcke C1 und C3 zur Speicherung in dem Sekundärprotokoll 234.P3.2 zu Instanz 102-2 übermittelt werden (612).
  • 6 veranschaulicht zudem, dass ein Primärprotokoll 232 mit dessen entsprechenden Sekundärprotokoll nicht physisch identisch sein muss. Zuerst sehen wir, dass die Datenblöcke C1 und C3 in dieser Reihenfolge in dem Primärprotokoll 232.P3.2 gespeichert werden, während dieselben Datenblöcke in dem Sekundärprotokoll 234.P3.2 in der umgekehrten Reihenfolge gespeichert werden. Während ein Protokoll geöffnet ist, können die einzelnen Datenblöcke 238 unabhängig repliziert werden, verschiedene Netzwerkpfade durchlaufen oder von verschiedenen Prozessoren 402 verarbeitet werden, sodass keine Garantie dafür besteht, dass sie in derselben Reihenfolge in das Sekundärprotokoll 234.P3.2 geladen werden. Die Tatsache, dass es unterschiedliche Reihenfolgen geben kann, wird, wie nachstehend mit Bezug auf 7 beschrieben, durch den Datenblock-Index innerhalb jedes Protokolls bewältigt. Darüber hinaus zeigt das Protokoll 232.P3.1 das Vorhandensein eines Ausschussdaten-„Datenblocks” 620 an, der in der Figur mit „G” bezeichnet wird. Während eines Uploads kann es mitunter zu Ausfällen oder Störungen kommen, die Speicherplatz in Anspruch nehmen. Während eines Uploads kann der Speicherplatz für ein Objekt beispielsweise zugeordnet, der Datenblock jedoch nicht tatsächlich angehängt sein. Die Software wiederholt den Upload, der dem Datenblock neuen Speicherplatz zuordnet. Dies kann Löcher oder Ausschussdaten in einem Protokoll 232 hinterlassen. In diesem Fall werden die Ausschussdaten 620 nicht an das Sekundärprotokoll übermittelt, sodass sich das Primärprotokoll physisch von dem Sekundärprotokoll unterscheidet.
  • 7 zeigt die Struktur eines geöffneten Protokolls gemäß einigen Implementierungen. Obwohl 7 ein geöffnetes Primärprotokoll 232 beschreibt, wäre die Struktur oder ein geöffnetes Sekundärprotokoll 234 gleich oder ähnlich. Ein Protokoll 232 hat einen Dateikopf 702 und einen Speicherblock 714. Der Speicherplatz 714 beinhaltet einen ausgenutzten Teil 710, der bereits Objektdatenblöcke 238 speichert, und einen ungenutzten Teil 712, der derzeit nicht verwendet wird. Diese Deskriptoren sind aus einigen Gründen nicht vollständig korrekt. Erstens kann der „ausgenutzte” Speicherplatz 710 Ausschussdatenabschnitte 620 beinhalten, die keinen nützlichen Inhalt aufweisen. Zweitens wird der ungenutzte Speicherplatz nicht unbedingt auf einmal zugeordnet. Einige Implementierungen ordnen den gesamten Speicherplatz für das Protokoll auf einmal zu und schließen das Protokoll, sobald es voll ist (wodurch am Ende ggf. eine kleine Menge an ungenutztem Speicherplatz übrig bleibt). In anderen Implementierungen werden jedoch nach Bedarf zusätzliche Speicherblöcke zugeordnet, bis das Protokoll ein bestimmtes Größenlimit erreicht oder eine bestimmte Zeitdauer (z. B. ein Tag) verstrichen ist.
  • Der Dateikopf 702 für das Protokoll beinhaltet wichtige interne Informationen über das Protokoll 232. Der Dateikopf 702 beinhaltet ein Feld 704, das angibt, wo in dem Protokoll der ungenutzte Speicherplatz 712 beginnt. Jedes Mal, wenn ein neuer Datenblock 238 an das Ende des ausgenutzten Speicherplatzes 710 angehängt wird, wird der Adressabstand 704 um die Größe des Datenblocks 238 inkrementiert, sodass das Protokoll 232 darauf vorbereitet wird, den nächsten Datenblock zu speichern.
  • Der Dateikopf 702 beinhaltet zudem einen Datenblock-Index 706. Der Datenblock-Index 706 für ein Protokoll 232 spezifiziert, wo sich jeder Datenblock 238 innerhalb des Protokolls 232 befindet, sowie seine Größe, was ein schnelles Lesen der Datenblockdaten (sowohl aus einem nichtflüchtigen Speichermedium als auch aus dem Cache) ermöglicht. Der Schlüssel für den Datenblock-Index 706 ist die Datenblock-ID 346, die den Datenblock eindeutig identifiziert. Beachten Sie, dass mehrere unterschiedliche Objekt-IDs 330 auf die gleichen physischen Datenblöcke verweisen können. Um einen riesigen Datenblock-Index 704 mit vielen Einträgen zu vermeiden, die auf den gleichen Objektdatenblock 238 verweisen, verwenden Implementierungen in der Regel eine einzelne Datenblock-ID, um auf denselben physischen Inhalt zu verweisen. Bei der Datenblock-ID 346 kann es sich beispielsweise um ein Inhalts-Hash oder eine Inhaltsübersicht (oder eine Kombination derselben) handeln. Für jede Datenblock-ID 346 spezifiziert der Datenblock-Index 720 einen Adressabstand 720 und eine Größe 722 für den Datenblock 238 innerhalb des Speicherplatzes 714. Der Adressabstand 720 kann entweder als ein Adressabstand aus dem Anfang des Protokolls 232 oder ein Adressabstand aus dem Anfang des ausgenutzten Speicherplatzes 710 spezifiziert werden. In einigen Implementierungen hat der Datenblock-Index zusätzliche Informationen, wie z. B. eine Löschmarkierung, die später verwendet wird, wenn Datenblöcke gelöscht werden und der ausgenutzte Speicherplatz 710 komprimiert wird.
  • Der Dateikopf 702 kann zudem andere Protokolldaten 708 enthalten, um Implementierungsdetails zu adressieren. Die anderen Protokolldaten 708 können beispielsweise den Adressabstand vom Anfang des Protokolls bis zum Anfang des Speicherplatzes 714 (d. h. bis zur Größe des Dateikopfes) spezifizieren. In einigen Implementierungen beinhalten die anderen Protokolldaten einen „Laufzeit”-Parameter für Protokolle, die für eine kurze Lebensdauer bestimmt sind.
  • Obwohl die Struktur des Protokolls in 7 für ein geöffnetes Primärprotokoll 232 bestimmt ist, gilt die gleiche Grundstruktur ebenfalls für die geöffneten Sekundärprotokolle 234 und geschlossenen Protokolle 230.
  • 8 veranschaulicht, was mit Objektmetadaten 228 und Protokollmetadaten 236 geschieht, wenn ein Protokoll gemäß einigen Implementierungen von einer Instanz zur anderen repliziert wird. In dieser Darstellung wird das geschlossene Protokoll 230 mit der Protokoll-ID J82117094 von der Instanz 102-1 (mit der Instanz-ID = 723) zu der Instanz 102-4 (mit der Instanz-ID 428) repliziert (820). Da das Protokoll 230 selbst als Einheit repliziert wird, wird der gesamte Inhalt exakt repliziert. Der Datenblock C8 (mit Datenblock-ID C408335) ist z. B. innerhalb des Protokolls genau in der gleichen Position. Nach der Replikation bewältigen Instanz 102-1 und 102-4 die Löschung und Komprimierung natürlich unabhängig, so dass nicht garantiert werden kann, dass deren physische Strukturen nach der Replikation gleich bleiben.
  • 8 zeigt zudem einen Teil der Objektmetadaten 228 und Protokollmetadaten 236 sowohl vor als auch nach der Replikation 820. Wie angegeben, bleiben die Datensätze 802814 in den Objektmetadaten 228 von der Replikation 820 unangetastet. Jedes Objekt 226 hat dieselben Datenblöcke 238 und die Datenblöcke 238 sind in demselben Protokoll 230 gespeichert. Der Datenblock mit Datenblock-ID C408335 (in Zeile 804) bleibt beispielsweise unverändert. Andererseits ändern sich die Protokollmetadaten 236 für das Protokoll 230 mit der Protokoll-ID J82117094 (370-1). Die Gruppe von Protokollstandorten 372 ändert sich von 372-1 (A) zu 372-1 (B), den neuen Standort 428 (beispielsweise 102-4) mit eingeschlossen.
  • 9A9C zeigen ein Verfahren 900 zum Verwalten (902) der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem 200 gemäß einigen Implementierungen. Das Verfahren wird (904) in einer ersten Instanz 102 des verteilten Datenspeichersystems ausgeführt, das einen oder mehrere Prozessoren und Speicher aufweist. Der Speicher speichert (906) eine Vielzahl von Objekten. Der Speicher speichert (908) ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren. In einigen Implementierungen wird das gesamte oder ein Teil des Verfahrens 900 durch das Standortzuweisungshintergrundprogramm 206 ausgeführt. In einigen Implementierungen hat das verteilte Datenspeichersystem mehrere Instanzen (910). In einigen dieser Implementierungen befindet sich zumindest eine Teilmenge der Instanzen (910) an verschiedenen geografischen Standorten. In einigen Implementierungen entspricht jede Instanz einem Rechenzentrum. In einigen Implementierungen umfasst jedes Rechenzentrum ein oder mehrere Instanzen.
  • In der ersten Instanz werden ein oder mehrere Protokolle 232 zum Speichern von Objektdatenblöcken geöffnet (912). Jedem Protokoll ist (914) eine einzelne jeweilige Platzierungsrichtlinie 212 zugewiesen. In einigen Implementierungen spezifiziert jede Platzierungsrichtlinie (926) eine Zielanzahl an Objektreplikaten, sowie eine Zielgruppe von Standorten für die Objektreplikate. In einigen Implementierungen kann eine Platzierungsrichtlinie 212 spezifizieren, welche Art von Datenspeicher 224 in einigen der Instanzen (z. B. auf der Platte oder auf dem Band) zu verwenden ist. In einigen Implementierungen beinhaltet das verteilte Datenspeichersystem 200 (918) Objektmetadaten 228, die spezifizieren, in welchem Protokoll jeder Objektdatenblock 238 gespeichert ist. Dies wurde zuvor mit Bezug auf die 35 beschrieben. In einigen Implementierungen beinhaltet jedes jeweilige Protokoll (920) einen Datenblock-Index 706, der den Standort jedes in dem jeweiligen Protokoll gespeicherten Objekts spezifiziert. Dies wurde in 7 näher beschrieben. Insbesondere wird der Standort der jeweiligen Datenblöcke innerhalb eines Protokolls relativ zum Protokoll selbst identifiziert, weshalb der Datenblock-Index 706 stimmt, unabhängig davon, wo das Protokoll gespeichert ist. Wenn beispielsweise der Standort der Datenblöcke in einem Protokoll als Adressabstände angegeben wird, kann durch relative Adressierung auf die Datenblöcke zugegriffen werden.
  • Offenbar beinhalten Implementierungen in der Regel (922) Protokollmetadaten 236, die jene Standorte 372 spezifizieren, in denen die jeweiligen Protokolle gespeichert sind. Dies wurde zuvor in den 35 und 8 beschrieben.
  • Die Verteilung der geöffneten Primärprotokolle 232 und der geöffneten Sekundärprotokolle 234 hängt von vielen Faktoren ab, einschließlich der verfügbaren Instanzen 102, der Platzierungsrichtlinien 212, der voraussichtlichen Verteilung der neuen Objekte 226 mit der Platzierungsrichtlinie 212, woher die neuen Objekte geladen werden (z. B. Europa, Nordamerika, Asien), die Verarbeitung der Ressourcen in jeder der verfügbaren Instanzen 102, sowie die Netzwerkbandbreite zwischen den verschiedenen Instanzen. Wenn beispielsweise viele Objekte mit einer bestimmten Platzierungsrichtlinie in einer bestimmten Instanz hochgeladen werden, werden in dieser Instanz mehrere Protokolle für dieselbe Platzierungsrichtlinie geöffnet (924). In einigen Szenarien können 5, 10 oder mehr geöffnete Protokolle für dieselbe Platzierungsrichtlinie 212 in einer einzelnen Instanz 102 vorhanden sein, wenn dies zum Belastungsausgleich erforderlich ist.
  • Wie zuvor mit Bezug auf die 5 und 6 beschrieben, übermitteln einige Implementierungen (916) eine Nachricht an eine dritte Instanz des verteilten Datenspeichersystems 200, um Protokolle zu öffnen, die den in der ersten Instanz geöffneten Protokollen entsprechen. In diesem Szenario werden die bei der ersten Instanz geöffneten Protokolle 232 als Primärprotokolle und die bei der dritten Instanz geöffneten Protokolle 234 als Sekundärprotokolle bezeichnet. (Natürlich könnte die erste Instanz auch Sekundärprotokolle und die dritte Instanz Primärprotokolle aufweisen.)
  • Bei der ersten Instanz 102 wird ein erstes Objekt 226 empfangen (928), das (928) mindestens einen ersten Objektdatenblock umfasst. Dies wurde oben mit Bezug auf 6 beschrieben. Dem ersten Objekt 226 ist eine erste Platzierungsrichtlinie 212 zugewiesen und somit sind alle Objektdatenblöcke 238, aus denen sich das Objekt 226 zusammensetzt, der ersten Platzierungsrichtlinie 212 zugewiesen. Der erste Objektdatenblock 238 wird in einem ersten Protokoll 232 gespeichert (930), dessen zugehörige Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie 212 übereinstimmt. Das erste Protokoll 232 speichert nur (932) Objektdatenblöcke für Objekte, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen. In einigen Implementierungen wird jeder in dem ersten Protokoll 232 gespeicherte Objektdatenblock 238 zur Speicherung in einem dritten Protokoll 234 an die dritte Instanz übermittelt (934).
  • Wenn das empfangene Objekt die Datenblockgröße überschreitet, wird das Objekt in mehrere Datenblöcke 238 aufgeteilt. In diesem Fall umfasst (936) das erste Objekt 226 zwei oder mehr Objektdatenblöcke. In der Regel unterscheidet sich der zweite Objektdatenblock von (936) dem ersten Objektdatenblock. (Zwei identische Datenblöcke innerhalb eines einzelnen Objekts sind selten, könnten aber zum Beispiel auftreten, wenn ein Objekt einen sehr großen Teil des leeren Speicherplatzes aufweist.) Unter bestimmten Umständen wird der zweite Objektdatenblock in einem zweiten Protokoll 232 gespeichert (938), das sich von dem ersten Protokoll unterscheidet und dessen zugehörige Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt. Das zweite Protokoll speichert nur (938) Objektdatenblöcke für Objekte, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen. Auf diese Weise könnte ein Objekt, das viele Datenblöcke umfasst, die Datenblöcke über viele verschiedene Protokolle verteilt haben.
  • Dieser Vorgang des Empfangens von Objekten 226 und Speichern der Datenblöcke 238 in dem ersten Protokoll 232 wird für eine Vielzahl von Objekten 226 wiederholt (940), deren zugehörige Platzierungsrichtlinien 338 mit der ersten Platzierungsrichtlinie 212 übereinstimmen, bis eine erste Abbruchbedingung auftritt. In einigen Implementierungen tritt die erste Abbruchbedingung auf, wenn (942) die Größe des ersten Protokolls einen vorbestimmten Schwellenwert überschreitet. In einigen Implementierungen tritt die erste Abbruchbedingung auf, wenn (944) das erste Protokoll für eine vorbestimmte Zeitspanne geöffnet war. Einige Implementierungen kombinieren Größe und Zeit in verschiedener Weise. Beispielsweise spezifizieren einige Implementierungen sowohl eine Zeitspanne als auch ein Größenlimit, wobei die Abbruchbedingung jene ist, die zuerst eintritt.
  • Nach Auftreten der Abbruchbedingung wird das erste Protokoll geschlossen (946), wodurch verhindert wird, dass zusätzliche Objektdatenblöcke in dem ersten Protokoll 232 gespeichert werden. Im Allgemeinen bestätigen Implementierungen, dass andere Protokolle 232 für dieselbe Platzierungsrichtlinie noch geöffnet sind (oder eine neue geöffnet wird), bevor das erste Protokoll geschlossen wird. Weil neue Objekte jederzeit dazukommen können, ist es wichtig, dass geöffnete Protokolle zur Verfügung stehen. Wenn ein entsprechendes Sekundärprotokoll 234 in einer anderen Instanz vorliegt, übermittelt die erste Instanz (948) eine Nachricht an die andere Instanz, um das entsprechende Sekundärprotokoll zu schließen, wenn die erste Abbruchbedingung auftritt.
  • Nachdem das erste Protokoll 232 geschlossen ist, unterliegt das Protokoll seiner Platzierungsrichtlinie. Die Erfüllung der Platzierungsrichtlinie 212 erfordert ggf. das Verschieben eines Protokollreplikats, das Erstellen einer neuen Kopie eines Protokollreplikats oder das Löschen eines Protokollreplikats. Unter bestimmten Umständen wird das erste Protokoll 232 gemäß der Platzierungsrichtlinie 212 zu einer zweiten Instanz 102 des verteilten Datenspeichersystems 200 repliziert (950). (In anderen Fällen wird ein Replikat des ersten Protokolls gelöscht.) In Implementierungen, die sowohl geöffnete Primär- als auch Sekundärprotokolle 232 und 234 aufweisen, sind zwei äquivalente geschlossene Protokolle 230 vorhanden, sobald diese geschlossen sind. Aus diesem Grund könnte jedes der Replikate als Quelle für die Replikation 950 verwendet werden. Wenn die Replikation 950 (d. h. als Teil der Transaktion) auftritt, werden die Protokollmetadaten 236 für das erste Protokoll aktualisiert (952), um anzuzeigen, dass eine Kopie des Protokolls in der zweiten Instanz vorhanden ist. Dies wurde oben mit Bezug auf 8 beschrieben.
  • Nachdem ein Protokoll 230 geschlossen ist, können die Objektdatenblöcke 238 gelöscht werden. Ein Objekt kann beispielsweise einem E-Mail-Anhang entsprechen. Wenn der Empfänger der E-Mail die E-Mail löscht, kann der Datenspeicher für den Anhang gelöscht werden. Nach einer Weile gibt es aufgrund der Löschungen Löcher in den jeweiligen Protokollen, weshalb es sinnvoll ist, das Protokoll zu komprimieren, um den verschwendeten Speicherplatz zu entfernen. Dies ähnelt der Fragmentierung des flüchtigen Speichers und dem Prozess der Defragmentierung, um den ungenutzten Speicherplatz in größere fortlaufende Datenblöcke zu konsolidieren.
  • Da ein abgespeicherter Objektdatenblock vielen verschiedenen Objekten (z. B. Hunderten, Tausenden oder Millionen) entsprechen kann, kann ein Objektdatenblock in einem Protokoll nur gelöscht werden, wenn es keine weiteren Verweise darauf gibt. Nachdem ein erstes geschlossenes Protokoll 230 ausgewählt wurde (954), identifiziert der Prozess 900 (956) einen oder mehrere Objektdatenblöcke, die in dem ersten geschlossenen Protokoll 230 gespeichert sind, für die es keine Verweise in den Objektmetadaten 228 gibt. Für diese identifizierten Datenblöcke 238 wird der Datenblock-Index 706 aktualisiert (958), um die entsprechenden Datensätze zu entfernen. In einigen Implementierungen wird der den identifizierten Objektdatenblöcken zuvor zugeordnete Speicherplatz überschrieben (z. B. jedes Byte auf ASCII 0 umgestellt), in anderen Implementierungen wird auf den Speicherplatz jedoch einfach nicht mehr verwiesen. In einigen Implementierungen wird der freigegebene Speicherplatz als Teil der anderen Protokolldaten 708 nachverfolgt. Einige Implementierungen verwalten beispielsweise eine Liste von freigegebenen Speicherplätzen (z. B. Adressabstand und Größe) oder verfolgen die freigegebenen Speicherplätze als eine verkettete Liste nach.
  • In einigen Implementierungen läuft regelmäßig ein Ausschussdaten-Sammelalgorithmus, um die jeweiligen geschlossenen Protokolle zu komprimieren (960). Der Komprimierungsprozess konsolidiert (960) die gespeicherten Objektdatenblöcke in einem fortlaufenden Datenblock, wodurch die Größe des Protokolls 230 reduziert wird. Im Laufe der Zeit können die Protokolle 230 kleiner werden, da mehr Objektdatenblöcke gelöscht werden. Die Verwaltung vieler kleiner Protokolle hat Ähnlichkeit mit dem Aufwand für die Verwaltung einzelner Objekte, wodurch der Nutzen der Protokollspeicherung vermindert wird. Um dieses Problem zu lösen, werden in einigen Implementierungen (962) zwei oder mehr geschlossene Protokolle zusammengefasst, um ein einzelnes Ersatzjournal zu bilden, und Objektmetadaten 228 zu aktualisieren (962), um anzuzeigen, dass Objektdatenblöcke, die zuvor in den zwei oder mehr Protokollen gespeichert wurden, nunmehr in dem Ersatzprotokoll gespeichert werden. Da ein Zusammenfassungsvorgang die Bildung eines vollständig neuen Protokolls und die Aktualisierung der Metadaten für alle beteiligten Objekte erfordert, ist das Zusammenfassen gewöhnlich auf das Szenario beschränkt, in dem die Protokolle relativ klein geworden sind.
  • Die vorstehende Beschreibung wurde zum Zweck der Erklärung unter Bezugnahme auf spezifische Implementierungen beschrieben. Die oben erläuternden Erörterungen sind jedoch nicht als erschöpfend zu betrachten und beschränken die Erfindung in keiner Weise auf die offenbarten präzisen Formen. Angesichts der obigen Lehren sind viele Modifikationen und Variationen im Rahmen des Möglichen. Die Implementierungen wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und deren praktische Anwendungen so gut wie möglich zu erklären, um dadurch andere Fachkräfte zu befähigen, die Erfindung und unterschiedlichen Implementierungen mit verschiedenen Modifizierungen für die spezielle in Betracht gezogene Verwendung in geeigneter Weise einsetzen zu können.

Claims (28)

  1. Computersystem zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem mit einer Vielzahl von Instanzen, wobei jede der jeweiligen Instanzen Folgendes umfasst: einen Prozessor oder mehrere Prozessoren; Speicher; und ein oder mehrere Programme, die in dem Speicher gespeichert sind, wobei ein oder mehrere Programme Anweisungen umfassen, die von einen oder mehreren Prozessoren ausgeführt werden können, um ein Verfahren zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem durchzuführen, welches Folgendes umfasst: In einer ersten Instanz des verteilten Datenspeichersystems mit einem oder mehreren Prozessoren und einem Speicher, worin der Speicher eine Vielzahl von Objekten und ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren speichert: das Öffnen eines oder mehrerer Protokolle zum Speichern von Objektdatenblöcken, wobei jedem Protokoll eine einzelne entsprechende Platzierungsrichtlinie zugewiesen ist; das Empfangen eines ersten Objekts, das mindestens einen ersten Objektdatenblock umfasst, wobei dem ersten Objekt eine erste Platzierungsrichtlinie zugewiesen ist; das Speichern des ersten Objektdatenblocks in einem ersten Protokoll, dessen zugewiesene Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt, wobei das erste Protokoll nur Objektdatenblöcke für Objekte speichert, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen; für das erste Protokoll, Wiederholen der Empfangs- und Speichervorgänge für eine erste Vielzahl von Objekten, deren zugehörige Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen, bis eine erste Abbruchbedingung auftritt; nachdem die erste Abbruchbedingung auftritt, das Schließen des ersten Protokolls, wodurch verhindert wird, dass zusätzliche Objektdatenblöcke in dem ersten Protokoll gespeichert werden; und das Replizieren des ersten Protokolls zu einer zweiten Instanz des verteilten Datenspeichersystems gemäß der ersten Platzierungsrichtlinie.
  2. Computersystem nach Anspruch 1, worin das erste Objekt zwei oder mehr Objektdatenblöcke umfasst, einschließlich eines zweiten Objektdatenblocks, der von dem ersten Objektdatenblock verschieden ist, und worin der zweite Objektdatenblock in einem zweiten Protokoll gespeichert ist, das sich von dem ersten Protokoll unterscheidet, dessen zugewiesene Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt und nur Objektdatenblöcke für Objekte speichert, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen.
  3. Computersystem nach Anspruch 1, des Weiteren umfassend: das Übermitteln einer Nachricht an eine dritte Instanz des verteilten Datenspeichersystems, um ein Replikat des ersten Protokolls in der dritten Instanz zu öffnen; für jeden in dem ersten Protokoll gespeicherten Objektdatenblock, Übermitteln des Objektdatenblocks an die dritte Instanz zum Speichern in dem Replikat des ersten Protokolls in der dritten Instanz; und wenn die erste Abbruchbedingung auftritt, Übermitteln einer Nachricht an die dritte Instanz zum Schließen des Replikats des ersten Protokolls in der dritten Instanz.
  4. Computersystem nach Anspruch 1, worin das verteilte Datenspeichersystem Objektmetadaten beinhaltet, die spezifizieren, in welchem Protokoll jeder Objektdatenblock gespeichert ist, und die jeweiligen Protokollreplikate einen Datenblock-Index beinhalten, der den Standort der jeweiligen Objekt-Datenblöcke spezifiziert, die in den entsprechenden Protokollreplikaten gespeichert sind.
  5. Computersystem nach Anspruch 4, in der ersten Instanz zudem Folgendes umfassend: das Auswählen eines Replikats eines ersten geschlossenen Protokolls; das Identifizieren eines oder mehrerer Objektdatenblöcke, die in dem Replikat gespeichert sind, für die es keine Verweise in den Objektmetadaten gibt; und das Aktualisieren des Datenblock-Index in dem Replikat, um den Speicherplatz eines oder mehrerer identifizierter Objektdatenblöcke freizugeben.
  6. Computersystem nach Anspruch 5, des Weiteren umfassend das Komprimieren des Replikats, wodurch die in dem Replikat gespeicherten Objektdatenblöcke in einen fortlaufenden Datenblock konsolidiert werden.
  7. Computersystem nach Anspruch 1, worin die erste Abbruchbedingung auftritt, wenn die Größe des ersten Protokolls einen vorgegebenen Schwellenwert überschreitet.
  8. Computersystem nach Anspruch 1, worin die erste Abbruchbedingung auftritt, wenn das erste Protokoll für eine vorbestimmte Zeitspanne geöffnet wurde.
  9. Computersystem nach einem der Ansprüche 1 bis 8, worin das verteilte Datenspeichersystem Protokollmetadaten beinhaltet, die die Standorte spezifizieren, in denen die jeweiligen Protokolle gespeichert sind, wobei das Verfahren des Weiteren das Aktualisieren der Protokollmetadaten umfasst, wenn das erste Protokoll zu der zweiten Instanz repliziert wird.
  10. Computersystem nach einem der Ansprüche 1 bis 8, worin das eine oder die mehreren geöffneten Protokolle in der ersten Instanz zwei oder mehr Protokolle beinhalten, die der gleichen Platzierungsrichtlinie zugeordnet sind.
  11. Computersystem nach Anspruch 1, des Weiteren umfassend das Zusammenfassen von zwei oder mehreren geschlossenen Protokollen, um ein einzelnes Ersatzprotokoll zu bilden, sowie das Aktualisieren von Objektmetadaten, um anzuzeigen, dass Objektdatenblöcke, die zuvor in den zwei oder mehr Protokollen gespeichert wurden, nunmehr in dem Ersatzprotokoll gespeichert sind.
  12. Computersystem nach irgendeinem der Ansprüche 1 bis 8, worin jede Platzierungsrichtlinie eine Zielanzahl an Objektreplikaten und eine Zielgruppe von Standorten für Objektreplikate spezifiziert.
  13. Computersystem nach Anspruch 1, worin das verteilte Datenspeichersystem mehrere Instanzen aufweist.
  14. Computersystem nach Anspruch 13, worin sich zumindest eine Teilmenge der Instanzen an verschiedenen geografischen Standorten befindet.
  15. Permanentes computerlesbares Speichermedium, das ein oder mehrere Programme speichert, die für die Ausführung durch einen oder mehrere Prozessoren eines Computersystems konfiguriert sind, um die Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem mit einer Vielzahl von Instanzen zu verwalten, wobei ein oder mehrere Programme an jeder der jeweiligen Instanzen Anweisungen zur Durchführung eines Verfahrens zum Verwalten der Platzierung von Objektreplikaten in einem verteilten Datenspeichersystem, welches Folgendes umfasst: In einer ersten Instanz des verteilten Datenspeichersystems mit einem oder mehreren Prozessoren und einem Speicher, worin der Speicher eine Vielzahl von Objekten und ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren speichert: das Öffnen eines oder mehrerer Protokolle zum Speichern von Objektdatenblöcken, wobei jedem Protokoll eine einzelne entsprechende Platzierungsrichtlinie zugewiesen ist; das Empfangen eines ersten Objekts, das mindestens einen ersten Objektdatenblock umfasst, wobei dem ersten Objekt eine erste Platzierungsrichtlinie zugewiesen ist; das Speichern des ersten Objektdatenblocks in einem ersten Protokoll, dessen zugewiesene Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt, wobei das erste Protokoll nur Objektdatenblöcke für Objekte speichert, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen; für das erste Protokoll, Wiederholen der Empfangs- und Speichervorgänge für eine erste Vielzahl von Objekten, deren zugehörige Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen, bis eine erste Abbruchbedingung auftritt; nachdem die erste Abbruchbedingung auftritt, das Schließen des ersten Protokolls, wodurch verhindert wird, dass zusätzliche Objektdatenblöcke in dem ersten Protokoll gespeichert werden; und das Replizieren des ersten Protokolls zu einer zweiten Instanz des verteilten Datenspeichersystems gemäß der ersten Platzierungsrichtlinie.
  16. Speichermedium nach Anspruch 15, worin das erste Objekt zwei oder mehr Objektdatenblöcke umfasst, einschließlich eines zweiten Objektdatenblocks, der von dem ersten Objektdatenblock verschieden ist, und worin der zweite Objektdatenblock in einem zweiten Protokoll gespeichert ist, das sich von dem ersten Protokoll unterscheidet, dessen zugewiesene Platzierungsrichtlinie mit der ersten Platzierungsrichtlinie übereinstimmt und nur Objektdatenblöcke für Objekte speichert, deren Platzierungsrichtlinien mit der ersten Platzierungsrichtlinie übereinstimmen.
  17. Speichermedium nach Anspruch 15, des Weiteren umfassend: das Übermitteln einer Nachricht an eine dritte Instanz des verteilten Datenspeichersystems, um ein Replikat des ersten Protokolls in der dritten Instanz zu öffnen; für jeden in dem ersten Protokoll gespeicherten Objektdatenblock, Übermitteln des Objektdatenblocks an die dritte Instanz zum Speichern in dem Replikat des ersten Protokolls in der dritten Instanz; und wenn die erste Abbruchbedingung auftritt, Übermitteln einer Nachricht an die dritte Instanz zum Schließen des Replikats des ersten Protokolls in der dritten Instanz.
  18. Speichermedium nach Anspruch 15, worin das verteilte Datenspeichersystem Objektmetadaten beinhaltet, die spezifizieren, in welchem Protokoll jeder Objektdatenblock gespeichert ist, und die jeweiligen Protokollreplikate einen Datenblock-Index beinhalten, der den Standort der jeweiligen Objekt-Datenblöcke spezifiziert, die in den entsprechenden Protokollreplikaten gespeichert sind.
  19. Speichermedium nach Anspruch 18, in der ersten Instanz zudem Folgendes umfassend: das Auswählen eines Replikats eines ersten geschlossenen Protokolls; das Identifizieren eines oder mehrerer Objektdatenblöcke, die in dem Replikat gespeichert sind, für die es keine Verweise in den Objektmetadaten gibt; und das Aktualisieren des Datenblock-Index in dem Replikat, um den Speicherplatz eines oder mehrerer identifizierter Objektdatenblöcke freizugeben.
  20. Speichermedium nach Anspruch 19, des Weiteren umfassend das Komprimieren des Replikats, wodurch die in dem Replikat gespeicherten Objektdatenblöcke in einen fortlaufenden Datenblock konsolidiert werden.
  21. Speichermedium nach Anspruch 15, worin die erste Abbruchbedingung auftritt, wenn die Größe des ersten Protokolls einen vorgegebenen Schwellenwert überschreitet.
  22. Speichermedium nach Anspruch 15, worin die erste Abbruchbedingung auftritt, wenn das erste Protokoll für eine vorbestimmte Zeitspanne geöffnet wurde.
  23. Speichermedium nach einem der Ansprüche 15 bis 22, worin das verteilte Datenspeichersystem Protokollmetadaten beinhaltet, die die Standorte spezifizieren, in denen die jeweiligen Protokolle gespeichert sind, wobei das Verfahren des Weiteren das Aktualisieren der Protokollmetadaten umfasst, wenn das erste Protokoll zu der zweiten Instanz repliziert wird.
  24. Speichermedium nach einem der Ansprüche 15 bis 22, worin das eine oder die mehreren geöffneten Protokolle in der ersten Instanz zwei oder mehr Protokolle beinhalten, die der gleichen Platzierungsrichtlinie zugeordnet sind.
  25. Speichermedium nach Anspruch 15, des Weiteren umfassend das Zusammenfassen von zwei oder mehreren geschlossenen Protokollen, um ein einzelnes Ersatzprotokoll zu bilden, sowie das Aktualisieren von Objektmetadaten, um anzuzeigen, dass Objektdatenblöcke, die zuvor in den zwei oder mehr Protokollen gespeichert wurden, nunmehr in dem Ersatzprotokoll gespeichert sind.
  26. Speichermedium nach irgendeinem der Ansprüche 15 bis 22, worin jede Platzierungsrichtlinie eine Zielanzahl an Objektreplikaten und eine Zielgruppe von Standorten für Objektreplikate spezifiziert.
  27. Speichermedium nach Anspruch 15, worin das verteilte Datenspeichersystem mehrere Instanzen aufweist.
  28. Speichermedium nach Anspruch 27, worin sich zumindest eine Teilmenge der Instanzen an verschiedenen geografischen Standorten befindet.
DE202014010953.2U 2013-06-25 2014-06-23 Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien Active DE202014010953U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/927,010 2013-06-25
US13/927,010 US9600558B2 (en) 2013-06-25 2013-06-25 Grouping of objects in a distributed storage system based on journals and placement policies

Publications (1)

Publication Number Publication Date
DE202014010953U1 true DE202014010953U1 (de) 2017-01-31

Family

ID=51212975

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202014010953.2U Active DE202014010953U1 (de) 2013-06-25 2014-06-23 Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien

Country Status (4)

Country Link
US (1) US9600558B2 (de)
EP (1) EP3014487B1 (de)
DE (1) DE202014010953U1 (de)
WO (1) WO2014209911A1 (de)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8942543B1 (en) 2010-10-06 2015-01-27 Verint Video Solutions Inc. Systems, methods, and software for improved video data recovery effectiveness
US9600558B2 (en) 2013-06-25 2017-03-21 Google Inc. Grouping of objects in a distributed storage system based on journals and placement policies
US9158472B2 (en) 2013-06-25 2015-10-13 Google Inc. Hierarchical chunking of objects in a distributed storage system
US9396202B1 (en) * 2013-12-27 2016-07-19 Google Inc. Weakly synchronized garbage collection and compaction for aggregated, replicated object stores
US9563383B2 (en) * 2014-05-12 2017-02-07 Hitachi, Ltd. Storage system with primary and secondary data storage groups and control method thereof
US20160378846A1 (en) * 2015-06-26 2016-12-29 Intel Corporation Object based storage cluster with multiple selectable data handling policies
US9817729B2 (en) * 2015-07-30 2017-11-14 Zerto Ltd. Method for restoring files from a continuous recovery system
US10346434B1 (en) * 2015-08-21 2019-07-09 Amazon Technologies, Inc. Partitioned data materialization in journal-based storage systems
US10031935B1 (en) * 2015-08-21 2018-07-24 Amazon Technologies, Inc. Customer-requested partitioning of journal-based storage systems
US10324905B1 (en) * 2015-08-21 2019-06-18 Amazon Technologies, Inc. Proactive state change acceptability verification in journal-based storage systems
US10248678B2 (en) 2015-08-25 2019-04-02 International Business Machines Corporation Enabling placement control for consistent hashing-based object stores
US10565059B2 (en) * 2015-10-26 2020-02-18 International Business Machines Corporation Adaptive optimization of a computer database journal
CN105824720B (zh) * 2016-03-10 2018-11-20 中国人民解放军国防科学技术大学 一种面向数据连续读取的重删纠删混合系统的数据放置方法
US11080242B1 (en) * 2016-03-30 2021-08-03 EMC IP Holding Company LLC Multi copy journal consolidation
WO2019036045A1 (en) 2017-08-16 2019-02-21 Mapr Technologies, Inc. MULTINIVE STORAGE IN A DISTRIBUTED FILE SYSTEM
US11507313B2 (en) * 2017-12-20 2022-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Datafall: a policy-driven algorithm for decentralized placement and reorganization of replicated data
US10809934B2 (en) * 2018-12-11 2020-10-20 Intel Corporation NAND direct access horizontal queue
JPWO2022038934A1 (de) * 2020-08-18 2022-02-24
WO2022038933A1 (ja) * 2020-08-18 2022-02-24 富士フイルム株式会社 情報処理装置、情報処理方法及び情報処理プログラム
US11868407B2 (en) * 2020-09-24 2024-01-09 Dell Products L.P. Multi-level data structure comparison using commutative digesting for unordered data collections
US20230237048A1 (en) * 2022-01-27 2023-07-27 Hewlett Packard Enterprise Development Lp Journal groups for metadata housekeeping operation
US11940882B2 (en) * 2022-07-25 2024-03-26 Hewlett Packard Enterprise Development Lp Migration of journal groups in a storage system

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7085789B1 (en) 2001-07-30 2006-08-01 Microsoft Corporation Compact garbage collection tables
US7574699B1 (en) 2003-03-19 2009-08-11 Sun Microsystems, Inc. Compact type format data system and method
US8180742B2 (en) 2004-07-01 2012-05-15 Emc Corporation Policy-based information management
US7778984B2 (en) 2004-11-19 2010-08-17 Microsoft Corporation System and method for a distributed object store
US7464247B2 (en) 2005-12-19 2008-12-09 Yahoo! Inc. System and method for updating data in a distributed column chunk data store
US7647329B1 (en) 2005-12-29 2010-01-12 Amazon Technologies, Inc. Keymap service architecture for a distributed storage system
US7856437B2 (en) 2007-07-31 2010-12-21 Hewlett-Packard Development Company, L.P. Storing nodes representing respective chunks of files in a data store
US8103628B2 (en) 2008-04-09 2012-01-24 Harmonic Inc. Directed placement of data in a redundant data storage system
BRPI0922542B1 (pt) 2008-12-22 2020-10-13 Google Llc Método realizado por um dispositivo de pluralidade de dispositivos num sistema distribuído de replicação de dados, sistema e memória legível em computador
US8301671B1 (en) 2009-01-08 2012-10-30 Avaya Inc. Method and apparatus providing removal of replicated objects based on garbage collection
US8560639B2 (en) 2009-04-24 2013-10-15 Microsoft Corporation Dynamic placement of replica data
US20100306171A1 (en) 2009-06-02 2010-12-02 Microsoft Corporation Timeline Experience for Restore User Interface
US8261033B1 (en) * 2009-06-04 2012-09-04 Bycast Inc. Time optimized secure traceable migration of massive quantities of data in a distributed storage system
US8341118B2 (en) * 2010-02-09 2012-12-25 Google Inc. Method and system for dynamically replicating data within a distributed storage system
US8886602B2 (en) * 2010-02-09 2014-11-11 Google Inc. Location assignment daemon (LAD) for a distributed storage system
US8868508B2 (en) 2010-02-09 2014-10-21 Google Inc. Storage of data in a distributed storage system
US8898798B2 (en) 2010-09-01 2014-11-25 Apixio, Inc. Systems and methods for medical information analysis with deidentification and reidentification
US8380681B2 (en) 2010-12-16 2013-02-19 Microsoft Corporation Extensible pipeline for data deduplication
US8874515B2 (en) 2011-04-11 2014-10-28 Sandisk Enterprise Ip Llc Low level object version tracking using non-volatile memory write generations
EP2780834B1 (de) 2011-11-14 2020-07-08 Google LLC Verarbeiten von datenänderungen für verteilte replizierte datenbanken
KR20150021117A (ko) 2012-06-18 2015-02-27 액티피오 인크. 강화형 데이터 관리 가상화 시스템
KR102050723B1 (ko) 2012-09-28 2019-12-02 삼성전자 주식회사 컴퓨팅 시스템 및 그 데이터 관리 방법
US20140201151A1 (en) 2013-01-11 2014-07-17 Commvault Systems, Inc. Systems and methods to select files for restoration from block-level backup for virtual machines
US8775485B1 (en) 2013-03-15 2014-07-08 Joyent, Inc. Object store management operations within compute-centric object stores
US9600558B2 (en) 2013-06-25 2017-03-21 Google Inc. Grouping of objects in a distributed storage system based on journals and placement policies

Also Published As

Publication number Publication date
EP3014487A1 (de) 2016-05-04
WO2014209911A1 (en) 2014-12-31
US20140379715A1 (en) 2014-12-25
EP3014487B1 (de) 2020-04-29
US9600558B2 (en) 2017-03-21

Similar Documents

Publication Publication Date Title
DE202014010953U1 (de) Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien
DE202014010898U1 (de) Hierarchische Stückelung von Objekten in einem dezentralen Speichersystem
DE112018004178B4 (de) Mehrstufige speicherung in einem verteilten dateisystem
DE112018000193B4 (de) Daten sequenziell in Zonen in einem verstreuten Speichernetzwerk speichern
US9396202B1 (en) Weakly synchronized garbage collection and compaction for aggregated, replicated object stores
DE102013215535B4 (de) Sicherung oder wiederherstellung von daten mit hilfe eines hauptspeichers und nichtflüchtiger speichermedien
DE202009019149U1 (de) Asynchron verteilte Speicherbereinigung für replizierte Speichercluster
DE602004006404T2 (de) Flashback-datenbank
DE112020000749T5 (de) Indexerstellung für sich entwickelnde umfangreiche Datensätze in Hybriden Transaktions- und Analysenverarbeitungssystemen mit mehreren Mastern
DE112017005868T5 (de) Verwaltung von e/a-abläufen für datenobjekte in einem speichersystem
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE112011101793T5 (de) Gemeinsame Datennutzung bei Dateiklonen
DE202019005483U1 (de) Datenreplikation und Datenausfallsicherung in Datenbanksystemen
DE102013215009A1 (de) Verfahren und System zur Optimierung der Datenübertragung
EP1708095A1 (de) Rechnernetzwerksystem zum Aufbauen, Synchronisieren und/oder Betreiben einer zweiten Datenbank aus/mit einer ersten Datenbank sowie Vorgehensweisen hierfür
EP1708096A1 (de) Rechnernetzwerksystem zum Synchronisieren einer zweiten Datenbank mit einer ersten Datenbank sowie Vorgehensweisen hierfür
DE102019111068A1 (de) Datenspeichersystem mit LUN-Archivierung in die Cloud unter Verwendung einer Volume-to-Object(Volumen-zu-Objekt)-Umsetzung
EP1708097A1 (de) Rechnernetzwerksystem zum Synchronisieren einer zweiten Datenbank mit einer ersten Datenbank sowie Vorgehensweise hierfür
DE102012223167B4 (de) Gemeinsame Nutzung von Artefakten zwischen kollaborativen Systemen
WO2015090668A1 (de) Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung
DE602004013397T2 (de) Verfahren und Apparat zum Verschieben von Daten zwischen Speichersystemen
DE112012000282T5 (de) Anwendungswiederherstellung in einem Dateisystem
DE102021125630A1 (de) Datensynchronisation in einem datenanalysesystem
DE112018000227B4 (de) Verfahren zum teilweisen Aktualisieren von Dateninhalten in einem verteilten Speichernetzwerk
DE112012000274B4 (de) Schutz der Unversehrtheit von Daten auf Speicherdatenträgern

Legal Events

Date Code Title Description
R207 Utility model specification
R150 Utility model maintained after payment of first maintenance fee after three years
R081 Change of applicant/patentee

Owner name: GOOGLE LLC (N.D.GES.D. STAATES DELAWARE), MOUN, US

Free format text: FORMER OWNER: GOOGLE INC., MOUNTAIN VIEW, CALIF., US

R082 Change of representative

Representative=s name: BETTEN & RESCH PATENT- UND RECHTSANWAELTE PART, DE

R151 Utility model maintained after payment of second maintenance fee after six years
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0017300000

Ipc: G06F0016270000

R152 Utility model maintained after payment of third maintenance fee after eight years