DE112019000143T5 - Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern - Google Patents

Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern Download PDF

Info

Publication number
DE112019000143T5
DE112019000143T5 DE112019000143.4T DE112019000143T DE112019000143T5 DE 112019000143 T5 DE112019000143 T5 DE 112019000143T5 DE 112019000143 T DE112019000143 T DE 112019000143T DE 112019000143 T5 DE112019000143 T5 DE 112019000143T5
Authority
DE
Germany
Prior art keywords
versioning
response
data
invalid
version
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.)
Pending
Application number
DE112019000143.4T
Other languages
English (en)
Inventor
Tomy Ammuthan Cheru
Vibhor Arunkumar PATALE
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.)
Western Digital Technologies Inc
Original Assignee
Western Digital Technologies Inc
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 Western Digital Technologies Inc filed Critical Western Digital Technologies Inc
Publication of DE112019000143T5 publication Critical patent/DE112019000143T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24573—Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2474—Sequence data queries, e.g. querying versioned data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Fuzzy Systems (AREA)
  • Multimedia (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Beispielhafte verteilte Speichersysteme, Replikations-Manager und Verfahren, die eine Versionierungsvalidierung für die Datenübertragungen zwischen heterogenen Datenspeichern bereitstellen. Ein erster Objektdatenspeicher schließt ein versioniertes Datenobjekt mit einer Vielzahl von sequentiellen Versionen, die dem versionierten Datenobjekt entspricht, ein. Eine versionierte Schreibanforderungsnachricht wird an einen zweiten Objektdatenspeicher gesendet und eine Antwort wird empfangen. Der Versionierung-aktiviert-Status des zweiten Objektdatenspeichers wird von der Antwortnachricht bestimmt und, wenn der Versionierung-aktiviert-Status ungültig ist, werden alle Restobjektversionen in dem zweiten Objektdatenspeicher basierend auf einer Löschanforderung gelöscht.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Offenbarung bezieht sich allgemein auf Datenspeicherung und in einem spezielleren Beispiel auf die Versionierungssteuerung für die Datenübertragung zwischen heterogenen Datenspeichern.
  • HINTERGRUND
  • Häufig werden verteilte Speichersysteme verwendet, um große Mengen (z. B. Terabytes, Petabytes, Exabytes usw.) von Daten, wie Objekte oder Dateien, in einer verteilten und fehlertoleranten Weise mit einem vorbestimmten Grad an Redundanz zu speichern.
  • Einige bestehende Objektspeichersysteme speichern Datenobjekte, die durch einen Objekt-Identifier gegenüber Dateisystemen referenziert werden. Dies kann es Objektspeichersystemen allgemein ermöglichen, die maximalen Speicherkapazitätsgrenzen von Dateisystemen in einer flexiblen Weise derart zu überschreiten, dass zum Beispiel Speicherkapazität in Abhängigkeit von den Anwendungen, Systemen und/oder Unternehmensanforderungen hinzugefügt oder entfernt werden kann, während eine Leistungsverschlechterung, wenn das System wächst, reduziert wird. Dadurch werden Objektspeichersysteme häufig für umfangreiche Speichersysteme ausgewählt.
  • Diese umfangreichen Speichersysteme können eine Vielfalt von Speichersystemen an verschiedenen Speicherorten und verschiedenen Alters und Konfigurationen einschließen. Als ein Ergebnis können nicht alle Objektdatenspeicher innerhalb eines umfangreichen Speichersystems eingerichtet sein, um Datenobjekte und ihre verwandten Metadaten in der gleichen Weise zu verwalten. Diese ungleichen Konfigurationen innerhalb des gleichen Speichersystems können als heterogene Datenspeicher bezeichnet werden. Innerhalb oder zwischen Objektspeichersystemen können einzelne Buckets auch anders eingerichtet und als heterogen beschrieben sein.
  • Diese umfangreichen Speichersysteme verteilen die gespeicherten Daten allgemein über mehrere Speicherelemente, wie zum Beispiel Solid-State-Laufwerke oder mehrere Komponenten, wie Speicherknoten, die eine Vielzahl solcher Speicherelemente aufweisen. Mit der zunehmenden Anzahl von Speicherelementen in solch einem verteilten Speichersystem nimmt jedoch die Wahrscheinlichkeit eines Ausfalls von einem oder mehreren dieser Speicherelemente zu, wie die Wahrscheinlichkeit eines Ausfalls oder einer Unterbrechung der Steuereinheit, des Netzwerks und Schnittstellen-Komponenten. Zur Bewältigung dieser Probleme verwenden verteilte Speichersysteme im Allgemeinen einen gewissen Grad an Redundanz der Daten, Speicherknoten, Steuereinheit, Schnittstelle, Client und Netzebenen. In einigen Fällen kann die Redundanz das Bewegen von Datenobjekten zwischen Objektdatenspeichern, wie beispielsweise das Verwenden eines oder mehrerer Replikationsagenten zum Spiegeln, Lastausgleich und/oder Disaster-Recovery einschließen.
  • Eine Versionierungssteuerung unter heterogenen Datenspeichern kann eine Herausforderung darstellen. Wenn zum Beispiel ein versioniertes Objekt in einen Objektdatenspeicher oder Bucket übertragen wird, der keine Versionierung aktiviert hat, können Versionsinformationen verloren gehen. Da viele Replikationsagenten parallele und/oder asynchrone Replikationspfade verwenden, ist es für die Versionen des gleichen versionierten Objekts auch möglich, zu unterschiedlichen Zeiten übertragen zu werden. Bei dynamischen Speicherumgebungen kann es für die Konfiguration eines Zieldatenspeichers möglich sein, sich während der Übertragung der Objektversionen zu ändern. Dies könnte dazu führen, dass unvollständige versionierte Datenobjekte in dem Zielobjektspeicher gespeichert werden, wenn die Versionierung während der Übertragung deaktiviert oder ausgesetzt wird.
  • Zusätzlich können Datenobjekte groß sein und wesentliche Rechen- und Netzwerkressourcen verwenden, um zwischen Speichersystemen zu übertragen. Das Initiieren einer großen Datenobjektübertragung, die mehrteilige Datenobjektübertragungen einschließen kann, die letztlich für ungültig erklärt werden können, weil der Zielobjektspeicher keine Versionierung aktiviert hat, kann zu verschwendeten Ressourcen führen, die den System-Overhead und die Latenzzeit erhöhen.
  • Da umfangreiche Speichersysteme mehr heterogene Objektdatenspeicher innerhalb eines Speichersystems skalieren und erstellen, können zuverlässige und effiziente Implementierungen zum Verwalten der Versionierungssteuerung benötigt werden. Es besteht ein Bedarf an mindestens einer Versionierungsvalidierung für die Datenübertragung zwischen heterogenen Datenspeichern.
  • KURZDARSTELLUNG
  • Verschiedene Gesichtspunkte zur Versionierungsvalidierung, insbesondere zur Versionierungsvalidierung für die Datenübertragung zwischen heterogenen Datenspeichern, werden beschrieben.
  • Ein allgemeiner Gesichtspunkt schließt ein System ein, das einen ersten Objektdatenspeicher einschließt, der eingerichtet ist, um eine erste Vielzahl von versionierten Datenobjekten einzuschließen. Ein versioniertes Datenobjekt der ersten Vielzahl von versionierten Datenobjekten schließt eine Vielzahl von sequentiellen Versionen, die dem versionierten Datenobjekt entsprechen, ein. Ein zweiter Objektdatenspeicher ist eingerichtet, um einen Versionierung-aktiviert-Status einzuschließen. Ein Replikations-Manager schließt mindestens einen Prozessor ein, wobei der Replikations-Manager eingerichtet ist zum: Übertragen des versionierten Datenobjekts von dem ersten Objektdatenspeicher zu dem zweiten Objektdatenspeicher; Senden einer Versionsschreibanforderungsnachricht an den zweiten Objektdatenspeicher für das versionierte Datenobjekt; Empfangen einer Antwortnachricht von dem zweiten Objektdatenspeicher; Bestimmen, aus der Antwortnachricht, ob der Versionierung-aktiviert-Status ungültig ist; und, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, Senden einer Löschanforderung für das versionierte Datenobjekt.
  • Implementierungen können eines oder mehrere der folgenden Merkmale einschließen. Der Replikations-Manager kann ferner eingerichtet sein, um, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, eine Versionsschreibanforderung für das versionierte Datenobjekte zu einer Wiederholungswarteschlange hinzuzufügen. Der Replikations-Manager kann ferner eingerichtet sein, um, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, ein Benachrichtigungsereignis zu erzeugen, das eingerichtet ist, um eine Freigabe der Versionierung am zweiten Objektdatenspeicher anzufragen. Der zweite Objektdatenspeicher kann eingerichtet sein, um, als Reaktion auf die Versionsschreibanforderungsnachricht, eine Restversion des versionierten Datenobjekts in dem zweiten Objektdatenspeicher zu speichern, wenn der Versionierung-aktiviert-Status ungültig ist, und, als Reaktion auf die Löschanforderung, die Restversion des versionierten Datenobjekts zu löschen. Die Versionsschreibanforderungsnachricht kann eine mehrteilige Schreibanforderung sein, die mehrere Schreibtransaktionen zwischen dem ersten Objektdatenspeicher und dem zweiten Objektdatenspeicher einschließt, um das versionierte Datenobjekt zu übertragen. Der Replikations-Manager kann ferner eingerichtet sein, um eine Testnachricht an den zweiten Objektdatenspeicher zu senden, bevor die Versionsschreibanforderungsnachricht für die mehrteilige Schreibanforderung initiiert wird. Das Initiieren der Versionsschreibanforderungsnachricht kann auf das Bestimmen, dass der Versionierung-aktiviert-Status gültig ist, ansprechen. Die Testnachricht kann eine Testversionsschreibanforderungsnachricht sein, die eine Host-Datengröße von 0 einschließt. Der Replikations-Manager kann ferner eingerichtet sein, um, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, die Testnachricht mehrere Male zu wiederholen. Der Replikations-Manager kann ferner eine Versionierung-ungültig-Liste der Zielobjektdaten-Buckets mit einem ungültigen Versionierung-aktiviert-Status einschließen und kann ferner eingerichtet sein, um, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einen Versionierung-ungültig-Eintrag für ein Zielobjektdaten-Bucket in dem zweiten Objektdatenspeicher hinzuzufügen. Der Replikations-Manager kann ferner eingerichtet sein zum: Suchen der Versionierung-ungültig-Liste für das Zielobjektdaten-Bucket für die Versionsschreibanforderungsnachricht; Senden, als Reaktion auf das Finden des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket, einer Testversionsschreibanforderungsnachricht an das Zielobjektdaten-Bucket; und, als Reaktion auf das Empfangen einer Testantwortnachricht, die angibt, dass der Versionierung-aktiviert-Status gültig ist, Entfernen des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket; und Initiieren der Versionsschreibanforderungsnachricht.
  • Ein allgemeiner Gesichtspunkt schließt ein computerimplementiertes Verfahren ein, das Folgendes einschließt: Senden einer Versionsschreibanforderungsnachricht für ein versioniertes Datenobjekt von einem ersten Objektdatenspeicher zu einem zweiten Objektdatenspeicher; Empfangen einer Antwortnachricht von dem zweiten Objektdatenspeicher; Bestimmen aus der Antwortnachricht, ob ein Versionierung-aktiviert-Status ungültig ist; und Senden einer Löschanforderung für das versionierte Datenobjekt, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist. Das versionierte Datenobjekt schließt eine Vielzahl von sequentiellen Versionen ein, die dem versionierten Datenobjekt entsprechen, und der zweite Objektdatenspeicher schließt den Versionierung-aktiviert-Status ein.
  • Implementierungen können eines oder mehrere der folgenden Merkmale einschließen. Das computerimplementierte Verfahren kann ferner das Hinzufügen einer Versionsschreibanforderung für das versionierte Datenobjekt zu einer Wiederholungswarteschlange, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einschließen. Das computerimplementierte Verfahren kann ferner das Erzeugen eines Benachrichtigungsereignisses, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einschließen, das eingerichtet ist, um eine Freigabe der Versionierung beim zweiten Objektdatenspeicher anzufragen. Das computerimplementierte Verfahren kann ferner das Speichern einer Restversion des versionierten Datenobjekts in dem zweiten Objektdatenspeicher, als Reaktion auf die Versionsschreibanforderungsnachricht, wenn der Versionierung-aktiviert-Status ungültig ist, und das Löschen der Restversion des versionierten Datenobjekts, als Reaktion auf die Löschanforderung, einschließen. Das computerimplementierte Verfahren kann ferner das Senden einer Testnachricht zu dem zweiten Objektdatenspeicher und das Empfangen einer Testantwortnachricht von dem zweiten Objektdatenspeicher einschließen, wobei das Senden der Versionsschreibanforderungsnachricht eine Reaktion auf das Bestimmen aus der Testantwortnachricht, dass der Versionierung-aktiviert-Status gültig ist, ist. Das computerimplementierte Verfahren kann ferner das mehrmalige Wiederholen der Testnachricht als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einschließen. Das computerimplementierte Verfahren kann ferner das Hinzufügen eines Versionierung-ungültig-Eintrags, als Reaktion auf das Bestimmen, dass der Version-aktiviert-Status ungültig ist, für ein Zielobjektdaten-Bucket in dem zweiten Objektdatenspeicher an eine Versionierung-ungültig-Liste, einschließen. Das computerimplementierte Verfahren kann ferner einschließen: Suchen der Versionierung-ungültig-Liste für das Zielobjektdaten-Bucket für die Versionsschreibanforderungsnachricht; Senden einer Testnachricht zu dem Zielobjektdaten-Bucket, als Reaktion auf das Finden des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket; und, als Reaktion auf das Empfangen einer Testantwortnachricht, die angibt, dass der Versionierung-aktiviert-Status gültig ist, Entfernen des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket und Initiieren der Versionsschreibanforderungsnachricht.
  • Ein allgemeiner Gesichtspunkt schließt ein System ein, das einen ersten Objektdatenspeicher einschließt, einschließlich einer ersten Vielzahl von versionierten Datenobjekten. Ein versioniertes Datenobjekt schließt eine Vielzahl von sequentiellen Versionen, die dem versionierten Datenobjekt entsprechen, ein. Ein zweiter Objektdatenspeicher schließt einen Versionierung-aktiviert-Status ein. Mittel zum Senden einer Versionsschreibanforderungsnachricht für das versionierte Datenobjekt von dem ersten Objektdatenspeicher zu dem zweiten Objektdatenspeicher sind bereitgestellt. Mittel zum Bestimmen, ob der Versionierung-aktiviert-Status ungültig ist, als Reaktion auf eine Antwortnachricht von dem zweiten Objektdatenspeicher, sind bereitgestellt. Mittel zum Senden einer Löschanforderung für das versionierte Datenobjekt, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, sind bereitgestellt.
  • Implementierungen können eines oder mehrere der folgenden Merkmale einschließen. Das System kann ferner einschließen: Mittel zum Senden einer Testnachricht zu dem zweiten Objektdatenspeicher und Mittel zum Empfangen einer Testantwortnachricht von dem zweiten Objektdatenspeicher, wobei das Senden der Versionsschreibanforderungsnachricht eine Reaktion auf das Bestimmen aus der Testantwortnachricht, dass der Versionierung-aktiviert-Status gültig ist, ist.
  • Die verschiedenen Ausführungsformen wenden die Lehren von den verteilten Speichernetzwerken und/oder -systemen vorteilhaft an, um die Funktionalität solcher Computersysteme zu verbessern. Die verschiedenen Ausführungsformen schließen Operationen zum Überwinden oder mindestens Reduzieren der Probleme in den bisherigen Speichernetzwerken und/oder -systemen, die oben erörtert wurden, ein und sind entsprechend zuverlässiger und/oder effizienter als andere Rechennetzwerke. Das heißt, die verschiedenen hierin offenbarten Ausführungsformen schließen Hardware und/oder Software mit Funktionalität zur Verbesserung der Versionssteuerung für die Datenübertragung zwischen heterogenen Datenspeichern, wie zum Beispiel durch Verwenden einer Versionierungsvalidierung und automatischen Entfernung von Restobjekten beim Übertragen der versionierten Datenobjekte zwischen Datenspeichern ein. Entsprechend stellen die hierin offenbarten Ausführungsformen verschiedene Verbesserungen an Speichernetzwerken und/oder Speichersystemen bereit.
  • Es sei klargestellt, dass die in der vorliegenden Offenbarung verwendete Ausdrucksweise hauptsächlich für Lesbarkeits- und Anweisungszwecke gewählt wurde und den Schutzumfang des hierin offenbarten Gegenstands nicht beschränken soll.
  • Figurenliste
    • 1 veranschaulicht schematisch ein Beispiel eines verteilten Speichersystems.
    • 2 veranschaulicht schematisch eine beispielhafte Client-Architektur, in der das verteilte Speichersystem von 1 betrieben werden kann.
    • 3 veranschaulicht schematisch ein Beispiel eines Speicherknotens des verteilten Speichersystems von 1.
    • 4 veranschaulicht schematisch ein Beispiel eines Controller-Knotens oder Zugangsknotens des verteilten Speichersystems von 1.
    • 5 veranschaulicht schematisch einige beispielhafte Elemente eines Objektspeichersystems für das verteilte Speichersystem von 1.
    • 6 veranschaulicht schematisch Datenobjekte, die zwischen beispielhaften heterogenen Datenspeichern mit ungültigem Versionierung-aktiviert-Status übertragen werden.
    • 7 veranschaulicht ein beispielhaftes Verfahren zum Validieren des Versionierung-aktiviert-Status.
    • 8 veranschaulicht ein beispielhaftes Verfahren zum Reagieren auf das beispielhafte Verfahren von 7.
    • 9 veranschaulicht ein beispielhaftes Verfahren zum Validieren des Versionierung-aktiviert-Status durch Verwenden von Testnachrichten.
  • DETAILLIERTE BESCHREIBUNG
  • Wie oben erörtert, kann eine ungeordnete versionierte Objekt-Schreibaufnahme in heterogenen Objektspeichersystemen zwischen heterogenen Versionierung-aktiviert-Buckets auftreten.
  • Objektspeichersysteme weisen einen Begriff von Datenobjekten auf. Datenobjekte können in Buckets enthalten sein und jedes Bucket kann einem spezifischen Objektspeichersystem oder Objektdatenspeicher zugeordnet sein. Spezifische Objektspeichersysteme können eine Anzahl von Konfigurationsparametern einschließen, einschließlich der Versionierungsunterstützung. In einigen Systemen können die einzelnen Buckets unterschiedliche Konfigurationsparameter einschließen, einschließlich dem Aktivieren und Deaktivieren der Versionssteuerung innerhalb eines Objektsspeichersystems, das anderweitig zum Versionieren eingerichtet ist.
  • In vielen Objektspeichersystemen wird ein Datenobjekt unter Verwendung entweder einer PUT-Funktion für Einzelteilobjekte oder eines mehrteiligen Schreibprozesses, wie INIT-, Mehrfach-PARTPUT- und COMPLETE-Funktionen geschrieben. Datenobjekte, die in ein Versionierung-nicht-aktiviert- oder Versionierung-ausgesetzt-System oder -Bucket geschrieben sind, können ein Datenobjekt mit einem Versionswert, der auf null gesetzt ist, und einen Erstellungszeitstempel erstellen. Nachfolgende Lese-Funktionen, wie zum Beispiel GET, des Datenobjekts mit einem definierten Objektnamen (z. B. „Objekt1“) können das Datenobjekt zurückgeben („Objekt1“). Wenn ein Objekt später mit dem gleichen Objektnamen geschrieben wird („Objekt1“), kann das ursprüngliche Objekt überschrieben werden. Nachfolgende GET-Operationen mit dem Objektnamen („Objekt1“) können das überschriebene Objekt zurückgeben und das ursprüngliche Objekt kann verloren gehen.
  • Jedoch können in einem Versionierung-aktiviert-System oder -Bucket frühere Versionen des Objekts nicht überschrieben werden. Ein neues Schreiben eines existierenden Datenobjekts („Objekt1“) kann eine neue Version dieses Objekts erstellen. Der Objektname ändert sich nicht, aber ein zusätzlicher Versions-Identifier kann dem neuen Schreiben zugeordnet werden. Wenn zum Beispiel das Objekt anfänglich geschrieben wird, kann es einen Versions-Identifier empfangen (z. B. „1111“). Nachfolgende GET-Operationen für den Objektnamen („Objekt1“) geben das Objekt („Objektl1“) mit dem aktuellsten Versions-Identifier („1111“) zurück. Jedes nachfolgende Mal, wenn ein Objekt mit dem gleichen Objektnamen mit aktivierter Versionierung geschrieben wird, wird ein neues Objekt mit dem gleichen Objektnamen („Objekt1“), aber einem neuen Erstellungszeitstempel und einem neuen Versions-Identifier erstellt (z. B. „2222“, „3333“). Der Satz von Datenobjekten mit dem gleichen Objektnamen und unterschiedlichen Versions-Identifiern in einem gegebenen Speichersystem oder Bucket können gemeinsam als ein versioniertes Datenobjekt bezeichnet werden, das eine Vielzahl von Datenobjektversionen aufweist. Die Reihenfolge der Versionen kann für GET-Operationen wichtig sein, die keine Version spezifizieren und dazu gedacht sind, die letzte Version des Objekts abzurufen.
  • Die Datenobjekterstellungszeit und -versionierung hängt von spezifischen Implementierungen in verschiedenen Objektspeichersystemen ab, was zu heterogenen Versionierungskonfigurationen führt. Die Versionierung kann bei unterschiedlichen Objektspeichersystemen unterschiedlich sein, die komplett unterschiedliche Versionierungsschemata implementieren, die von anderen Objektspeichersystemen nicht erkannt werden können. Zum Beispiel können die Versionierungs-Identifier in einem Format oder einem Ort vorhanden sein, die dem anderen System unbekannt sind. In einem solchen Fall darf eine GET-Funktion von dem anderen System, die eine Versionsanforderung einschließen soll, nicht der notwendigen Betriebssyntax entsprechen und kann einen Fehler, ein leeres Objekt oder eine Standardversion zurückgeben, wie zum Beispiel die aktuellste gemäß dem lokalen Erstellungszeitstempel oder dem Versionierungsschema.
  • Insbesondere kann ein versioniertes Schreiben in ein Keine-Versionierung-aktiviert-Bucket oder Datenspeicher dazu führen, dass nur ein einziges, nicht versioniertes Datenobjekt übertragen und in dem Zieldatenspeicher gespeichert wird. Als ein Ergebnis können alle anderen Objektversionen und zugeordneten Metadaten verloren gehen, ohne irgendeine Art von Systemfehler oder Benachrichtigung an Systemadministratoren zu erzeugen. Auch wenn eine anfängliche Prüfung des Versionierung-aktiviert-Status gemacht wurde, kann es keine atomare Operation mit dem tatsächlichen versionierten Schreiben sein und der Status kann zwischen der anfänglichen Prüfung und Fertigstellung der versionierten Datenobjektübertragung geändert werden.
  • Während die Validierung des Versionierung-aktiviert-Status des Ziel-Buckets als Teil der versionierten Schreiboperation vorteilhaft sein kann, kann immer noch die Gefahr bestehen, dass unnötige Daten übertragen werden (unter Verwendung von wertvollen Rechen- und Netzwerkressourcen), bevor die Benachrichtigung empfangen wird, dass der Versionierung-aktiviert-Status ungültig ist. Dies kann besonders verschwenderisch für große Objekte unter Verwendung von mehrteiligen Datenübertragungen sein, wobei der Versionierungsstatus nicht bestätigt werden kann, bis die letzte Operation der mehrteiligen Sequenzen abgeschlossen ist. Zusätzliche Sicherheitsmaßnahmen, um große, unnötige Datenübertragungen zu begrenzen, können innerhalb Versionierung-aktiviert-Datenschreibanforderungen implementiert werden.
  • 1 zeigt eine Ausführungsform eines beispielhaften verteilten Speichersystems 1. In einigen Ausführungsformen kann das verteilte Speichersystem 1 als ein verteiltes Objektspeichersystem implementiert sein, das mit einem oder mehreren Clients 10.1-10.n zum Zugreifen auf Datenobjekte durch einen oder mehrere Zugangsknoten 20.1-10.n gekoppelt ist. Die Verbindung zwischen dem verteilten Speichersystem 1 und den Clients 10 könnte zum Beispiel als ein geeignetes Datenkommunikationsnetzwerk implementiert sein. Die Clients 10 können eine oder mehrere Anwendungen hosten oder verbinden, die gespeicherte Daten im verteilten Speichersystem 1 verwenden. Eine solche Anwendung könnte zum Beispiel eine dedizierte Softwareanwendung sein, die auf einer Rechenvorrichtung, wie einem Personalcomputer, einem Laptop, einem drahtlosen Telefon, einem persönlichen digitalen Assistenten oder einem beliebigen anderen Typ von Kommunikationsvorrichtung, die in der Lage ist, direkt mit dem verteilten Speichersystem 1 verbunden zu werden, ausgeführt wird. Gemäß alternativen Ausführungsformen könnten die Anwendungen jedoch zum Beispiel ein geeignetes Dateisystem, das es einer Softwareanwendung für allgemeine Zwecke ermöglicht, mit dem verteilten Speichersystem 1 verbunden zu werden, eine Anwendungsprogrammierschnittstellen-Bibliothek (application programming interface, API-Library) für das verteilte Speichersystem 1, usw. aufweisen. In einigen Ausführungsformen können Zugangsknoten 20 ein Datei-Schnittstellensystem zum Empfangen der Datei-Datenanforderungen von Clients 10 entsprechend einem Datei-Systemprotokoll und zum Zugreifen auf Daten in den Speicherknoten 30.1-30.40 unter Verwendung eines unterschiedlichen Speicherprotokolls, wie zum Beispiel eines Objekt-Speicherprotokolls, einschließen.
  • Wie ferner in 1 gezeigt, weist das verteilte Speichersystem 1 eine Vielzahl von Zugangsknoten 20 und eine Vielzahl von Speicherknoten 30 auf, die in einer geeigneten Weise zum Übertragen von Daten, zum Beispiel mittels eines herkömmlichen Datenkommunikationsnetzwerks, wie eines lokalen Netzwerks (Local Area Network, LAN), eines Weitverkehrsnetzwerks (Wide Area Network, WAN), eines Telefonnetzes, wie des öffentliches Telefonnetzes (Public Switched Telephone Network, PSTN), eines Intranets, des Internets oder eines beliebigen anderen geeigneten Kommunikationsnetzwerks oder einer Kombination von Kommunikationsnetzwerken, gekoppelt sein können. Die Zugangsknoten 20, die Speicherknoten 30 und die Rechenvorrichtungen, welche die Clients 10 aufweisen, können mittels geeigneter drahtverbundener, drahtloser, optischer usw. Netzwerkverbindungen oder einer beliebigen geeigneten Kombination solcher Netzwerkverbindungen eine Verbindung zu dem Datenkommunikationsnetzwerk herstellen. Wenngleich die Ausführungsform von 1 nur drei Zugangsknoten 20 und vierzig Speicherknoten 30 zeigt, könnte gemäß alternativen Ausführungsformen das verteilte Speichersystem 1 eine beliebige andere geeignete Anzahl von Speicherknoten 30 und zum Beispiel zwei, drei oder mehrere Zugangsknoten 20, die mit diesen Speicherknoten 30 gekoppelt sind, aufweisen.
  • Diese Zugangsknoten 20 und Speicherknoten 30 können als Allzweck-Computer aufgebaut sein. Alternativ können sie physisch für die Anordnung in großen Datenzentren angepasst sein, wo sie in modularen Racks 40.1-40.n angeordnet sind, die Standardabmessungen aufweisen. Beispielhafte Zugangsknoten 20 und Speicherknoten 30 können so dimensioniert sein, dass sie eine einzelne Einheit solcher Racks 40 aufnehmen, die allgemein als 1U bezeichnet wird. Ein solcher beispielhafter Speicherknoten kann einen Niedrigleistungsprozessor verwenden und kann mit zehn oder zwölf Serial Advanced Technology Attachment-Festplattenlaufwerken (SATA-Festplattenlaufwerken) hoher Kapazität ausgestattet sein und ist mit dem Netzwerk über redundante Ethernet-Netzwerkschnittstellen verbindbar. Ein beispielhafter Zugangsknoten 20 kann Hochleistungsserver aufweisen und einen Netzwerkzugang zu Clients 10 über mehrere Ethernet-Netzwerkschnittstellen mit hoher Bandbreite bereitstellen. Daten können zwischen Clients 10 und solchen Zugangsknoten 20 mittels einer Vielzahl von Netzwerkprotokollen, einschließlich Objektschnittstellen für Hypertext Transfer Protocol (HTTP)/Representational State Transfer (REST), sprachspezifischen Schnittstellen, wie Microsoft. Net, Python oder C, usw. übertragen werden. Außerdem können solche Zugangsknoten zusätzliche Ethernet-Ports mit hoher Bandbreite aufweisen, um mit den Speicherknoten 30 verbunden zu werden. In einigen Ausführungsformen können HTTP/REST-Protokolle, die einem Objektspeicherdienst für Amazon's einfachen Speicherdienst (Amazon Simple Storage Service, S3) entsprechen, eine Datenübertragung durch eine REST-Anwendungsprotokollschnittstellen (REST-API) ermöglichen. Solche Zugangsknoten 20 können als ein Cluster von Controller-Knoten mit hoher Verfügbarkeit mit einer oder mehreren integrierten und/oder unabhängigen Schnittstellensystemen arbeiten und stellen zum Beispiel einen gemeinsam genutzten Zugang zu den Speicherknoten 30, Metadatenzwischenspeicherung, Schutz von Metadaten, usw. bereit.
  • Wie in 1 gezeigt, können mehrere Speicherknoten 30 zusammengefasst werden, weil sie zum Beispiel in einem einzelnen Rack 40 untergebracht sind. Zum Beispiel sind die Speicherknoten 30.1-30.4 und 30.7-30.40 jeweils in die entsprechenden Racks 40.1 und 40.n gruppiert. Die Zugangsknoten 20 können in den gleichen oder unterschiedlichen Racks angeordnet sein wie die Speicherknoten, mit denen sich die Zugangsknoten verbinden. Ein Rack kann mehrere Zugangsknoten aufweisen, zum Beispiel Rack 40.1, einen einzelnen Zugangsknoten wie Rack 40.n oder keine Zugangsknoten (nicht gezeigt) und sich auf einen Zugangsknoten in einem anderen Rack oder Speicherknoten oder Clients mit eingebauten Zugangsknoten- und/oder Controller-Knoten-Fähigkeiten stützen. Diese Racks müssen sich nicht am gleichen Ort befinden, sie sind oft geografisch über verschiedene Datenzentren verteilt, wie zum Beispiel können sich Rack 40.1 bis 40.3 in einem Datenzentrum in Europa, 40.4 bis 40.7 in einem Datenzentrum in den USA und 40.8 bis 40.10 in einem Datenzentrum in China befinden.
  • 2 ist ein Blockdiagramm eines beispielhaften Speichernetzwerks 50, das eine Client-Architektur verwendet. In einigen Ausführungsformen kann das verteilte Speichersystem 1 in einem solchen Speichernetzwerk 50 ausgeführt sein. Wie gezeigt, kann das Speichernetzwerk 50 mehrere Client-Vorrichtungen 60 einschließen, die dazu in der Lage sind, mit einem Speichernetzwerk 50 über ein drahtverbundenes und/oder drahtloses Netzwerk 70 (z. B. öffentliche und/oder private Computernetzwerke in beliebiger Anzahl und/oder Konfiguration (z. B. das Internet, ein Intranet, ein Cloud-Netzwerk usw.)) gekoppelt zu sein und damit zu kommunizieren, neben anderen Beispielen, die eine Client-Vorrichtung 60.1 oder zwei oder mehrere Client-Vorrichtungen 60 (z. B. nicht auf drei Client-Vorrichtungen 60.1 bis 60.3 beschränkt) einschließen können.
  • Eine Client-Vorrichtung 60 kann jede Rechenhardware und/oder -software (z. B. ein Thick Client, ein Thin Client oder eine Mischform davon) sein, die dazu in der Lage ist, auf das Speichersystem 80 unter Verwendung des Netzwerks 70 zuzugreifen. Jede Client-Vorrichtung 60 beruht als Teil ihrer jeweiligen Operation auf dem Senden von Eingabe-/Ausgabeanforderungen (E/A-Anforderungen) in das Speichersystem 80, um Daten zu schreiben, zu lesen und/oder zu ändern. Insbesondere kann jede Client-Vorrichtung 60 E/A-Anforderungen zum Lesen, Schreiben, Speichern, Kommunizieren, Verbreiten und/oder Transportieren von Anweisungen, Daten, Computerprogrammen, Software, Code, Routinen usw. an das Speichersystem 80 übertragen. Die Client-Vorrichtung(en) 60 und das Speichersystem 80 können mindestens einen Teil eines Client-Server-Modells aufweisen. Im Allgemeinen kann durch die Client-Vorrichtung(en) 60 auf das Speichersystem 80 zugegriffen werden und/oder kann die Kommunikation mit dem Speichersystem 80 durch (eine) Client-Vorrichtung(en) 60 durch ein Netzwerk-Socket (nicht gezeigt) unter Verwendung einer oder mehrerer prozessübergreifender Netzwerktechniken initiiert werden. In einigen Ausführungsformen können die Client-Vorrichtungen 60 auf eine oder mehrere Anwendungen zugreifen, um ein verteiltes Speichersystem, wie das verteilte Speichersystem 1 in 1, zu verwenden oder zu verwalten.
  • 3 zeigt eine schematische Darstellung einer Ausführungsform von einem der Speicherknoten 30. Der Speicherknoten 30.1 kann einen Bus 310, einen Prozessor 320, einen lokalen Speicher 330, eine oder mehrere optionale Eingabeeinheiten 340, eine oder mehrere optionale Ausgabeeinheiten 350, eine Kommunikationsschnittstelle 360, eine Speicherelementschnittstelle 370 und zwei oder mehr Speicherelemente 300.1 bis 300.10 aufweisen. Der Bus 310 kann einen oder mehrere Leiter einschließen, die eine Kommunikation unter den Komponenten des Speicherknotens 30.1 ermöglichen. Der Prozessor 320 kann einen beliebigen Typ von herkömmlichem Prozessor oder Mikroprozessor einschließen, der Anweisungen interpretiert und ausführt. Der lokale Speicher 330 kann einen Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM) oder einen anderen Typ von dynamischer Speichervorrichtung, die Informationen und Anweisungen zur Ausführung durch den Prozessor 320 speichert, und/oder einen Festwertspeicher (Read Only Memory, ROM) oder einen anderen Typ von statischer Speichervorrichtung, die statische Informationen und Anweisungen zur Verwendung durch den Prozessor 320 speichert, einschließen. Die Eingabeeinheit 340 kann einen oder mehrere herkömmliche Mechanismen einschließen, die es einem Bediener ermöglichen, Informationen in den Speicherknoten 30.1 einzugeben, wie eine Tastatur, eine Maus, einen Stift, eine Spracherkennung und/oder biometrische Mechanismen usw. Die Ausgabeeinheit 350 kann einen oder mehrere herkömmliche Mechanismen einschließen, die Informationen an den Bediener ausgeben, wie eine Anzeige, einen Drucker, einen Lautsprecher usw. Die Kommunikationsschnittstelle 360 kann einen beliebigen Transceiver-artigen Mechanismus einschließen, der es dem Speicherknoten 30.1 ermöglicht, mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, zum Beispiel Mechanismen zum Kommunizieren mit anderen Speicherknoten 30 oder Zugangsknoten 20, wie zum Beispiel zwei 1-GB-Ethernet-Schnittstellen.
  • Die Speicherelementschnittstelle 370 kann eine Speicherschnittstelle, wie zum Beispiel eine SATA-Schnittstelle oder eine Small Computer System Interface (SCSI) zum Verbinden des Busses 310 mit einem oder mehreren Speicherelementen 300, wie einer oder mehreren lokalen Platten, zum Beispiel 3-Terabyte-SATA-Plattenlaufwerken (3-TB-SATA-Plattenlaufwerken), aufweisen und das Lesen und Schreiben von Daten in/von diese(n) Speicherelemente(n) 300 steuern. In einer beispielhaften Ausführungsform, wie in 2 gezeigt, könnte ein solcher Speicherknoten 30.1 zehn oder zwölf 3-TB-SATA-Plattenlaufwerke als Speicherelemente 300.1-300.10 aufweisen, und auf diese Weise würde der Speicherknoten 30.1 dem verteilten Speichersystem 1 eine Speicherkapazität von 30 TB oder 36 TB bereitstellen. Gemäß der beispielhaften Ausführungsform von 1 und in dem Fall, dass die Speicherknoten 30.2 bis 30.40 mit dem Speicherknoten 30.1 identisch sind und jeweils eine Speicherkapazität von 36 TB aufweisen, hätte das verteilte Speichersystem 1 dann insgesamt eine Speicherkapazität von 1440 TB.
  • Wie aus 1 und 3 klar hervorgeht, weist das verteilte Speichersystem 1 eine Vielzahl von Speicherelementen 300 auf. Wie unten detaillierter beschrieben wird, könnten die Speicherelemente 300 auch als redundante Speicherelemente 300 bezeichnet werden, weil die Daten derart auf diesen Speicherelementen 300 gespeichert werden, dass keines oder ein bestimmter Teil der einzelnen Speicherelemente 300 für sich allein für das Funktionieren des verteilten Speichersystems kritisch ist. Jeder der Speicherknoten 30 kann einen Anteil dieser Speicherelemente 300 aufweisen.
  • Wie in 1 gezeigt, weist der Speicherknoten 30.1 zehn Speicherelemente 300.1 bis 300.10 auf. Andere Speicherknoten 30 könnten eine ähnliche Menge an Speicherelementen 300 aufweisen, aber dies ist jedoch nicht wesentlich. Der Speicherknoten 30.2 könnte zum Beispiel sechs Speicherelemente 300.11 bis 300.16 aufweisen, und der Speicherknoten 30.3 könnte zum Beispiel vier Speicherelemente 300.17 bis 300.20 aufweisen. Wie unten detaillierter erklärt wird, kann das verteilte Speichersystem 1 als ein verteiltes Objektspeichersystem betreibbar sein, um ein Datenobjekt, aufweisend Daten (z. B. 64 Megabyte (MB) Binärdaten) und einen Datenobjekt-Identifier zum Adressieren dieses Datenobjekts, zum Beispiel einen universell eindeutigen Identifier, wie einen global eindeutigen Identifier (Globally Unique Identifier, GUID), zu speichern und abzurufen. Ausführungsformen des verteilten Speichersystems 1 können als ein verteiltes Objektspeichersystem betrieben werden. Das Speichern der Daten, die zur Speicherung durch die Anwendung in Form eines Datenobjekts angeboten werden, das auch als Objektspeicherung bezeichnet wird, kann spezifische Vorteile gegenüber anderen Speicherschemata, wie der herkömmlichen blockbasierten Speicherung oder der herkömmlichen dateibasierten Speicherung, aufweisen.
  • Die Speicherelemente 300 oder ein Abschnitt davon können redundant sein und unabhängig voneinander arbeiten. Dies bedeutet, dass, wenn ein bestimmtes Speicherelement 300 ausfällt, seine Funktion leicht durch ein anderes Speicherelement 300 in dem verteilten Speichersystem 1 übernommen werden kann. Wie weiter unten detaillierter erklärt wird, sind jedoch die Speicherelemente 300 dazu in der Lage, Redundanz bereitzustellen, ohne synchron arbeiten zu müssen, wie es zum Beispiel in vielen hinlänglich bekannten Konfigurationen einer redundanten Anordnung unabhängiger Festplatten (Redundant Array of Independent Disks, RAID) der Fall ist, die es manchmal sogar erfordern, dass die Spindeldrehung synchronisiert wird. Des Weiteren kann es der unabhängige und redundante Betrieb der Speicherelemente 300 ermöglichen, dass eine geeignete Mischung von Typen von Speicherelementen 300 in einem bestimmten verteilten Speichersystem 1 verwendet wird. Es ist möglich, zum Beispiel Speicherelemente 300 mit unterschiedlicher Speicherkapazität, Speicherelemente 300 verschiedener Hersteller, die eine unterschiedliche Hardwaretechnologie, wie zum Beispiel herkömmliche Festplatten und Festkörperspeicherelemente verwenden, die unterschiedliche Speicherschnittstellen, wie zum Beispiel unterschiedliche Revisionen von SATA, Parallel Advanced Technology Attachment (PATA) verwenden, und so weiter zu verwenden. Dies kann zu Vorteilen bezüglich Skalierbarkeit und Flexibilität des verteilten Speichersystems 1 führen, weil es das Hinzufügen oder Entfernen von Speicherelementen 300 ermöglicht, ohne ihrem Design in Korrelation mit anderen Speicherelementen 300, die bereits in dem verteilten Objektspeichersystem verwendet werden, spezifische Anforderungen aufzuerlegen.
  • 4 zeigt eine schematische Darstellung einer Ausführungsform des Zugangsknotens 20. Der Zugangsknoten 20 kann Controller-Knoten-Funktionen und/oder Dateisystemschnittstellen-Funktionen für Clientsysteme, die Dateisystemprotokolle verwenden, einschließen, um auf Daten zuzugreifen, die in Datenobjekten in den Speicherknoten 30 gespeichert sind. Der Zugangsknoten 20 kann einen Bus 210, einen Prozessor 220, einen lokalen Speicher 230, eine oder mehrere optionale Eingabeeinheiten 240, eine oder mehrere optionale Ausgabeeinheiten 250 aufweisen. In einigen Ausführungsformen kann der Zugangsknoten 20 Objektspeicherverwaltungs-Funktionen einschließen, einschließlich Objektspeicherschnittstellen-Funktionen, Versionssteuerungsverwaltung, und/oder Replikations-Engines.
  • Der Bus 210 kann einen oder mehrere Leiter einschließen, die eine Kommunikation unter den Komponenten des Zugangsknotens 20 ermöglichen. Der Prozessor 220 kann einen beliebigen Typ von herkömmlichem Prozessor oder Mikroprozessor einschließen, der Anweisungen interpretiert und ausführt. Der lokale Speicher 230 kann einen Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM) oder einen anderen Typ von dynamischer Speichervorrichtung, die Informationen und Anweisungen zur Ausführung durch den Prozessor 220 speichert, und/oder einen Festwertspeicher (Read Only Memory, ROM) oder einen anderen Typ von statischer Speichervorrichtung, die statische Informationen und Anweisungen zur Verwendung durch den Prozessor 320 speichert, und/oder ein beliebiges geeignetes Speicherelement, wie eine Festplatte oder ein Festkörperspeicherelement, einschließen. Eine optionale Eingabeeinheit 240 kann einen oder mehrere herkömmliche Mechanismen einschließen, die es einem Bediener ermöglichen, Informationen in den Zugangsknoten 20 einzugeben, wie eine Tastatur, eine Maus, einen Stift, eine Spracherkennung und/oder biometrische Mechanismen usw. Die optionale Ausgabeeinheit 250 kann einen oder mehrere herkömmliche Mechanismen einschließen, die Informationen an den Bediener ausgeben, wie eine Anzeige, einen Drucker, einen Lautsprecher usw. Die Kommunikationsschnittstelle 260 kann einen beliebigen Transceiver-artigen Mechanismus einschließen, der es dem Zugangsknoten 20 ermöglicht, mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, zum Beispiel Mechanismen zum Kommunizieren mit anderen Speicherknoten 30 oder Zugangsknoten 20, wie zum Beispiel zwei 10-GB-Ethernet-Schnittstellen.
  • Gemäß einer alternativen Ausführungsform könnte der Zugangsknoten 20 ein identisches Design wie ein Speicherknoten 30 aufweisen, oder gemäß noch einer weiteren alternativen Ausführungsform könnte einer der Speicherknoten 30 des verteilten Objektspeichersystems sowohl die Funktion eines Zugangsknotens 20 als auch die eines Speicherknotens 30 durchführen. Gemäß noch weiteren Ausführungsformen könnten die Komponenten des Zugangsknotens 20, wie unten detaillierter beschrieben, unter einer Vielzahl von Zugangsknoten 20 und/oder Speicherknoten 30 in einer beliebigen geeigneten Art und Weise verteilt sein. Gemäß einer noch weiteren Ausführungsform können die Clients 10 einen Zugangsknoten 20 ausführen. Gemäß noch weiteren Ausführungsformen kann der Zugangsknoten 20 in separaten Controller-Knoten und Schnittstellen-Knoten, mit oder ohne Redundanz unter den Controller-Knoten und/oder Schnittstellen-Knoten, ausgebildet sein.
  • 5 zeigt schematisch ausgewählte Module von einem Zugangsknoten oder Controller-Knoten mit Versionssteuerungsverwaltung, Replikationsverwaltung und unterstützenden Funktionen. Das Objektspeichersystem 500 kann als ein Knoten mit einer Architektur und/oder Hardware ähnlich dem Controller-Knoten und/oder Speicherknoten eingerichtet sein. Das Objektspeichersystem 500 kann Elemente und Konfigurationen, ähnlich den in 1-4 gezeigten, einbeziehen. Zum Beispiel kann das Objektspeichersystem 500 in einem Zugangsknoten 20 mit Objektspeicherverwaltungsfunktionen eingerichtet sein.
  • Das Objektspeichersystem 500 kann einen Bus 510 einschließen, der mindestens eine Kommunikationseinheit 512, mindestens einen Prozessor 514 und mindestens einen Speicher 516 miteinander verbindet. Der Bus 510 kann einen oder mehrere Leiter einschließen, die eine Kommunikation unter den Komponenten des Zugangssystems 500 ermöglichen. Die Kommunikationseinheit 512 kann jeden transceiverartigen Mechanismus einschließen, der es dem Zugangssystem 500 ermöglicht, mit anderen Vorrichtungen und/oder Systemen zu kommunizieren. Zum Beispiel kann die Kommunikationseinheit 512 drahtgebundene oder drahtlose Mechanismen zum Kommunizieren mit den Dateisystem-Clients, andere Zugangssysteme, und/oder eines oder mehrere Objektspeichersysteme oder Komponenten, wie etwa Speicherknoten oder Controller-Knoten, einschließen. Der Prozessor 514 kann einen beliebigen Typ von Prozessor oder Mikroprozessor einschließen, der Anweisungen interpretiert und ausführt. Der Speicher 516 kann einen Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM) oder einen anderen Typ von dynamischer Speichervorrichtung, die Informationen und Anweisungen zur Ausführung durch den Prozessor 514 speichert, und/oder einen Festwertspeicher (Read Only Memory, ROM) oder einen anderen Typ von statischer Speichervorrichtung, die statische Informationen und Anweisungen zur Verwendung durch den Prozessor 514 speichert, und/oder ein beliebiges geeignetes Speicherelement, wie eine Festplatte oder ein Festkörperspeicherelement, einschließen.
  • Das Objektspeichersystem 500 kann eine oder mehrere Datenbanken und/oder spezialisierte Datenspeicher einschließen oder Zugriff darauf haben, wie zum Beispiel Metadatenspeicher 550 und Objektspeicher 560. Datenbanken können eine oder mehrere Datenstrukturen zum Speichern, Abrufen, Indexieren, Suchen, Filtern usw. von strukturierten und/oder unstrukturierten Datenelementen einschließen. In einigen Ausführungsformen kann der Metadatenspeicher 550 als Referenzdateneinträge und/oder Datenfelder strukturiert sein, die durch Metadatenschlüsselwerteinträge indexiert sind, die sich auf Datenobjektspeicher in dem Objektspeicher 560 beziehen. Der Objektspeicher 560 kann Datenobjekte einschließen, die Objektdaten (wie Hostdaten), eine gewisse Menge von Metadaten (gespeichert als Metadaten-Tags) und eine GUID aufweisen. Metadatenspeicher 550, Objektspeicher 560 und/oder andere Datenbanken oder Datenstrukturen können in separaten Rechensystemen, wie Speicherknoten mit separater Kommunikation, Prozessor, Speicher, und anderen Rechenressourcen beibehalten und verwaltet werden und durch das Zugangssystem 500 durch Datenzugriffsprotokolle zugegriffen werden. Metadatenspeicher 550 und Objektspeicher 560 können über mehrere Objektspeichersysteme 500 hinweg gemeinsam genutzt werden.
  • Das Objektspeichersystem 500 kann eine Vielzahl von Modulen oder Subsystemen einschließen, die in dem Speicher 516 zur Ausführung durch den Prozessor 514 gespeichert und/oder instantiiert sind. Zum Beispiel kann der Speicher 516 eine Speicherschnittstelle 520 einschließen, die eingerichtet ist, um Objektdatenanforderungen von dem Client-System oder anderen Knoten in dem verteilten Speichersystem 1 zu empfangen, zu verarbeiten und darauf zu reagieren. Der Speicher 516 kann einen Versionssteuerungs-Manager 530 zum Erstellen und Verwalten von Objektversionen in dem Objektspeicher 560 einschließen. Der Speicher 516 kann einen Replikations-Manager 540 zum Verarbeiten von Daten-Replikation zwischen Speicherknoten oder Speichersystemen, wie die Übertragung oder Replikation von Datenobjekten zu einem anderen Objektspeicher, der heterogen sein kann, einschließen. In einigen Ausführungsformen können der Versionssteuerungs-Manager 530 und/oder der Replikations-Manager 540 in die Speicherschnittstelle 520 integriert werden und/oder als separate Bibliotheken oder Hintergrundprozesse (z. B. Dämon) über eine API oder eine andere Schnittstelle verwaltet werden.
  • Die Speicherschnittstelle 520 kann ein Schnittstellenprotokoll oder einen Satz von Funktionen und Parametern zum Speichern, Lesen und anderweitigem Verwalten von Datenanforderungen an ein zugeordnetes verteiltes Speichersystem und die entsprechenden Metadaten-Datenquelle zum Abbilden der Dateidaten zu persistenten Speicherdatenelementen einschließen. Zum Beispiel kann die Speicherschnittstelle 520 Funktionen zum Lesen, Schreiben, Modifizieren oder anderweitigem Manipulieren von Datenobjekten und ihrem jeweiligen Client oder Hostdaten und Metadaten gemäß den Protokollen eines Objektspeichersystems einschließen.
  • In einigen Ausführungsformen kann die Speicherschnittstelle 520 eine Vielzahl von Hardware- und/oder Software-Modulen einschließen, die eingerichtet sind, um den Prozessor 514 und den Speicher 516 zu verwenden, um definierte Operationen der Speicherschnittstelle 520 zu handhaben oder zu verwalten. Zum Beispiel kann die Speicherschnittstelle 520 einen Client-Anforderungs-Handler 522, einen Metadaten-Manager 524, einen Speichermanager 526 und einen Client-Antwort-Handler 528 einschließen. Bei einer gegebenen Client-Anforderung, kann die Speicherschnittstelle 520 eine Client-Anforderung durch den Client-Anforderungs-Handler 522 empfangen und eine oder mehrere Operationen, basierend auf dem Inhalt der Anforderung, bestimmen. Diese Operationen können Metadaten-Operationen einschließen, die durch den Metadaten-Manager 524 gehandhabt werden und/oder Objektdaten-Operationen, die durch den Speichermanager 526 gehandhabt werden. Die Ergebnisse dieser Operationen können durch den Client-Antwort-Handler 528 verarbeitet, formatiert und zurückgegeben werden.
  • Die Speicherschnittstelle 520 kann eine oder mehrere Objektspeicherkonfigurationen einschließen, die ein Speicherprotokoll definieren, das zum Validieren, Verwalten und Verarbeiten von Objektdatenanforderungen verwendet wird. Zum Beispiel können Objektspeicherkonfigurationen allgemein die Verfügbarkeit einer Versionssteuerung für ein beliebiges gegebenes Objekt oder Bucket definieren sowie spezifizieren, wie das Objektspeichersystem Versionsinformationen erstellt und verwaltet. Objektspeicherkonfigurationen können auch definieren, welche Metadaten gesammelt und gespeichert werden, sowie ob sie in einer Metadaten-Datenbank gespeichert werden, wie zum Beispiel dem Metadatenspeicher 550, in Objekt-Metadaten-Tags, die in den Datenobjekten gespeichert sind, und/oder einer Kombination davon.
  • Der Client-Anforderungs-Handler 522 kann eine Schnittstelle und/oder eine ereignisbasierte Kommunikationsbedingung zum Empfangen von Objektdatenanforderungen von einem oder mehreren Clients einschließen. Zum Beispiel können die Client-Systeme eine Objektdatenanforderung über eine Netzwerkverbindung senden und an das Objektspeichersystem 500 oder einen Port oder eine Komponente davon adressieren. Der Client-Anforderungs-Handler 522 kann diese Anforderungen empfangen und sie gemäß den entsprechenden Kommunikations- und Objektspeicherprotokollen parsen. Zum Beispiel kann der Client-Anforderungs-Handler 522 einen Transaktions-Identifier, einen Client-Identifier, einen Objekt-Identifier (Objektname oder GUID), eine Datenoperation und zusätzliche Parameter für die Datenoperation, falls vorhanden, aus der empfangenen Nachricht oder Nachrichten, aus denen sich die Objektdatenanforderung zusammensetzt, identifizieren.
  • Der Metadaten-Manager 524 kann Schnittstellen, Funktionen und/oder Parameter zum Erstellen, Modifizieren, Löschen, Zugreifen und/oder anderweitiges Verwalten von Objektmetadaten, wie zum Beispiel Objektmetadaten 554 einschließen, die in dem Metadatenspeicher 550 gespeichert sind. Wenn zum Beispiel ein neues Objekt in den Objektspeicher 560 geschrieben wird, wird mindestens ein neuer Metadaten-Eintrag in dem Metadatenspeicher 550 erstellt, um Parameter zu repräsentieren, die das neu erstellte Objekt beschreiben oder sich darauf beziehen. Der Metadaten-Manager 524 kann einen Objektdatenindex 552 erzeugen und beibehalten, der es dem Metadaten-Manager 524 ermöglicht, die Objekt-Metadaten innerhalb des Metadatenspeichers 550 zu lokalisieren. Zum Beispiel kann der Metadatenspeicher 550 als ein Schlüsselwertspeicher organisiert sein und der Objektdatenindex 552 kann Schlüsselwerte für Datenobjekte und/oder Operationen einschließen, bezogen auf solche Objekte, die mit einem Schlüsselwert indexiert sind, der den Objekt-Identifier oder GUID für jedes Objekt einschließt. In einigen Ausführungsformen kann der Metadaten-Manager 524 auch Objekt-Metadaten, die in dem Objektspeicher 560 mit Objektdaten 564 gespeichert sind, verwalten. Der Metadaten-Manager 524 kann in Verbindung mit dem Speicher-Manager 526 arbeiten, um Objekt-Metadaten, die als Objekt-Tags 566 innerhalb des Objektspeichers 560 gespeichert sind, zu erstellen, zu modifizieren, zu löschen, darauf zuzugreifen oder anderweitig zu verwalten.
  • Der Speicher-Manager 526 kann Schnittstellen, Funktionen und/oder Parameter zum Lesen, Schreiben und Löschen von Objektdaten-Elementen in dem Objektspeicher 560 einschließen. Zum Beispiel können Objekt-PUT-Befehle eingerichtet sein, um Objekt-Identifier 562, Objektdaten 564 und/oder Objekt-Tags 566 in den Objektspeicher 560 zu schreiben. Objekt-GET-Befehle können eingerichtet sein, um Daten aus dem Objektspeicher 560 zu lesen. Objekt-DELETE-Befehle können eingerichtet sein, um Daten aus dem Objektspeicher 560 zu löschen oder um mindestens ein Datenobjekt zum Löschen zu markieren, bis eine zukünftige Garbage Collection oder eine ähnliche Operation tatsächlich die Daten löscht oder den physischen Speicherort zu einem anderen Zweck neu zuordnet.
  • Weitere Objektspeicher-Befehle können durch den Speicher-Manager 526 gehandhabt werden, einschließlich spezieller Funktionen, die zur Versionssteuerung definiert sind. Objektspeicher-Befehle, die durch den Speicher-Manager 526 verarbeitet werden, können Parameter zum Zugreifen auf spezielle Funktionen und/oder Metadaten-Ressourcen, die mit Host- oder Client-Daten in den Datenobjekten gespeichert sind, einschließen. Der Speicher-Manager 526 kann in Verbindung mit dem Metadaten-Manager 524 und dem Versionssteuerungs-Manager 530 zum Verwalten von Objekt-Metadaten, einschließlich Versionierungsinformationen, arbeiten. Der Speicher-Manager 526 kann in Verbindung mit dem Replikations-Manager 540 zum Replizieren oder Migrieren von Daten aus dem Objektspeicher 560 zu einem anderen Datenspeicher arbeiten. Zum Beispiel kann der Speicher-Manager 526 den Objektspeicher 560 zur Übertragung durch einen oder mehrere Replikations-Engines lesen, die durch den Replikations-Manager 540 verwaltet werden.
  • Der Client-Antwort-Handler 528 kann eine Schnittstelle und/oder Kommunikationslogik zum Senden von Antwortnachrichten, wie das Ergebnis, den Status oder Fehlermeldungen, zu einem oder mehreren Clients, bezogen auf die empfangenen Objektdatenanforderungen, einschließen. Zum Beispiel kann der Client-Antwort-Handler 528 auf die Verarbeitung durch den Metadaten-Manager 524 und/oder den Speicher-Manager 526 warten, um einen Fehler abzuschließen oder zu erzeugen, und dann ein entsprechendes Ergebnis oder eine Fehlermeldung an das/die Client-System(e) für jede empfangene Objektdatenanforderung bereitzustellen.
  • In einigen Ausführungsformen kann der Metadatenspeicher 550 über mehrere Systeme hinweg verteilt sein, wie zum Beispiel eine Vielzahl von Zugriffssystemen. Metadatenspeicher 550 und/oder Teile davon können geteilte Datenspeicher sein, wobei die Datenspeicher in Segmente partitioniert sind, die in unterschiedlichen Rechensystemen gespeichert sind. Die Speicherschnittstelle 520 kann die Funktionen zum Lokalisieren und Zugreifen auf relevante Teile der geteilten Datenbank einschließen.
  • Der Versionssteuerungs-Manager 530 kann von der Speicherschnittstelle 520 aufgerufen werden, um die Versionssteuerung für eines oder mehrere Datenobjekte, Buckets oder den gesamten Objektspeicher 560 zu verwalten. Wenn zum Beispiel Versionierung aktiviert ist, kann jedes Mal, wenn der gleiche Objektname geschrieben wird, eine neue Objektversion erstellt werden. In ähnlicher Weise kann bestimmt werden, welche Objektversion von einem Lesevorgang zurückgegeben wird, durch einen Versions-Identifier, der als ein Parameter des Lesevorgangs eingeschlossen sein und/oder die Standard- oder die aktuellste Version sein. Der Versionssteuerung-Manager 530 kann Schnittstellen, Funktionen und Parameter zum Verwalten der Verwendung von persistenten Versionsfeldern zur Versionssteuerung über heterogene Datenspeicher hinweg bereitstellen. In einigen Ausführungsformen kann der Versionssteuerungs-Manager 530 innerhalb der Speicherschnittstelle 520 eingeschlossen sein, wie innerhalb der Bibliothek-Funktionen, die durch den Client-Anforderungs-Handler 522, den Metadaten-Manager 524, den Speicher-Manager 526 und/oder den Client-Antwort-Handler 528 verwendet werden.
  • In einigen Ausführungsformen kann der Versionssteuerungs-Manager 530 eine oder mehrere Hardware- und/oder Software-Module oder Datenstrukturen zum Ausführen spezifischer Operationen einschließen. Zum Beispiel kann der Versionssteuerungs-Manager 530 einen Versionierungs-Enabler 532, persistente Versionsfelder 534, Versionsfeld-Schreiber/-Leser 536 und Antwort-Handler 538 einschließen.
  • Der Versionierungs-Enabler 532 kann einen oder mehrere Parameter, Datenstrukturen und/oder verwandte Verfahren zum Manipulieren dieser Parameter oder Datenstrukturen einschließen. Der Versionierungs-Enabler 532 kann eingerichtet sein, um den Versionierung-aktiviert-Status 532.1 für den Objektspeicher 560 und/oder die spezifischen Buckets oder Datenobjekte, die darin enthalten sind, zu verwalten. In einigen Ausführungsformen kann jedes Bucket ein Versionierung-aktiviert-Feld einschließen, um zu bestimmen, ob eine Versionierung für dieses Bucket aktiviert ist. Zum Beispiel kann das Versionierung-aktiviert-Feld ein erster Wert sein, wenn die Versionierung für ein Zieldatenobjekt, Bucket oder Objektspeicher aktiviert ist, und ein zweiter Wert sein, wenn die Versionierung für das Zieldatenobjekt, Bucket oder Objektspeicher nicht aktiviert ist. In einigen Ausführungsformen können die Versionierung-aktiviert-Felder mehrere Werte einschließen, um zu vermitteln, ob die Versionierung verfügbar ist (unterstützt wird, aber nicht aktiviert), die Versionierung nicht unterstützt wird oder die Versionierung ausgesetzt ist (zuvor aktiviert, aber unwirksam aufgrund einer Unterbrechung, eines Konflikts oder einer Konfigurationswahl bei dem Bucket oder auf Objektebene).
  • In einigen Kontexten kann der Versionierung-aktiviert-Status 532.1 als gültig für eine spezifische Schreibtransaktion bezeichnet werden, wenn versionierte Datenobjekte mit ihren sequentiellen Objektversionen und verwandten Versionierungs-Metadaten in den Objektspeicher 560 geschrieben werden können. Es können mehrere Werte für die Versionierung-aktiviert-Felder vorhanden sein, die sich in einen gültigen Versionierung-aktiviert-Status für eine spezifische Schreibtransaktion umwandeln. In ähnlicher Weise kann der Versionierung-aktiviert-Status 532.1 als ungültig für eine spezifische Schreibtransaktion bezeichnet werden, wenn versionierte Datenobjekte mit ihren sequentiellen Objektversionen und verwandten Versionierungs-Metadaten in den Objektspeicher 560 geschrieben werden können. Es können mehrere Werte für die Versionierung-aktiviert-Felder vorhanden sein, die sich in einen ungültigen Versionierung-aktiviert-Status für eine spezifische Schreibtransaktion umwandeln.
  • Der Versionierungs-Enabler 532 kann auch einen oder mehrere konfigurierbare Parameter einschließen, die definieren, wie das Versionieren durch den Versionssteuerungs-Manager 530 gehandhabt wird. Zum Beispiel kann ein Objektspeichersystem sowohl eine standardmäßige, lokale Versionssteuerungskonfiguration als auch eine persistente Versionssteuerungskonfiguration zur Verwendung über den Objektspeichersystemen hinweg unterstützen. In einigen Ausführungsformen kann der Versionierungs-Enabler 532 einen Parameter zum Bestimmen, ob Versionsfelder in einer Metadatenbank gespeichert sind, wie zum Beispiel in Objektmetadaten 554 im Metadatenspeicher 550, oder mit Objektdaten, wie zum Beispiel in Objekt-Tags 566 im Objektspeicher 560, einschließen.
  • Persistente Versionsfelder 534 können einen oder mehrere Parameter, Datenstrukturen und/oder verwandte Verfahren zum Konfigurieren und Erzeugen persistenter Versionsfelder für Objektversionen einschließen. Zum Beispiel kann eine persistente Versionsfeldkonfiguration den Bucket-Namen 534.1, den Bucket-Identifier 534.2, den Versions-Identifier 534.3 und den Erstellungszeitstempel 534.3 einschließen. In einigen Ausführungsformen können persistente Versionsfelder 534 jeweils eine Reihe von Werten einschließen, die den Unterfeldern entsprechen, und gemäß einer definierten Syntax gespeichert und dargestellt werden. Zum Beispiel könnte ein beispielhaftes persistentes Versionsfeld „bucket1.1234.1111.05/12/2018-01:00:00“ sein. In einigen Ausführungsformen können persistente Versionsfelder 534 entstanden sein, wenn das Objekt anfänglich durch ein erstes Objektspeichersystem erstellt und mit den Objektversionen übertragen wird, wann immer sie migriert oder repliziert werden. Als ein Ergebnis kann die ursprüngliche Versionsinformation, einschließlich dem Erstellungszeitstempel, von den Objekt-Metadaten bestimmt werden, unabhängig davon, wo diese Version des Objekts endet oder durch wie viele heterogene Objektspeicher es übertragen worden sein könnte (oder wann oder in welcher Reihenfolge).
  • Das Versionsfeld-Schreiber/Leser 536 kann Funktionen, Verfahren oder Operationen zum Bereitstellen der persistenten Versionsfelder 556, 568 einschließen, die in Metadaten geschrieben und aus Metadaten gelesen werden sollen. Zum Beispiel kann der Versionsfeld-Schreiber für jede gegebene Objektversion, die erstellt und in dem Objektspeicher 560 gespeichert wird, persistente Versionsfelder 534 als eine Vorlage verwenden, um persistente Versionsfelder 556, 568 mit entsprechenden Werten für den Schreibvorgang zu belegen, wie Bucket-Name, Bucket-Identifier, Versions-Identifier und Erstellungszeitstempelwerte in Bezug auf die Schreiboperation. Für jeden gegebenen Lesevorgang für ein versioniertes Datenobjekt oder eine Objektversion davon können Versionsfeld-Leser das persistente Versionsfeld von den Metadaten für jede Objektversion von Interesse erkennen und persistente Versionsfelder 534 als eine Vorlage, um die entsprechenden Werte für die Felder zu entnehmen und wieder zurückzugeben, verwenden. In einigen Ausführungsformen kann der Versionsfeld-Schreiber/-Leser 536 von der Speicherschnittstelle 520 und/oder dem Replikations-Manager 540 aufgerufen werden.
  • Eine spezielle Instanz des Versionsfeld-Schreibers/Lesers 536 kann einen Löschmarkierung-Schreiber einschließen. Wenn zum Beispiel ein Löschereignis für ein versioniertes Datenobjekt identifiziert wird, wie zum Beispiel die Verarbeitung eines Löschbefehls für das versionierte Datenobjekt, das durch die Speicherschnittstelle 520 empfangen wird, kann der Löschmarkierungs-Schreiber eine Datenobjektversion ohne HostDaten (oder eine Host-Datengröße von 0) und ein persistentes Versionsfeld erzeugen, das die Objektversion als eine Löschmarkierung identifiziert. Diese Objektversion der Löschmarkierung kann den gleichen Objektnamen haben (wie jede andere Objektversion) und wie jede andere Objektversion verwaltet und übertragen werden in für das versionierte Datenobjekt. In einigen Ausführungsformen kann die Löschmarkierung einen Löschmarkierung-Identifier einschließen, wie zum Beispiel einen Flag, Tag oder einen ähnlichen Wert, der zu dem persistenten Versionsfeld hinzugefügt wird, um die Objektversion als eine Löschmarkierung zu identifizieren.
  • Der Schreibantwort-Handler 538 kann Funktionen, Verfahren oder Operationen zum Bereitstellen der Antworten auf Versionsschreibanforderungen einschließen, die von anderen Objektspeichersystemen empfangen werden. Wenn zum Beispiel eine Versionsschreibanforderung durch die Speicherschnittstelle 520 zum Schreiben eines versionierten Datenobjekts in den Objektspeicher 560 von einem anderen Objektspeicher empfangen wird, kann die Versionsschreibanforderung eingerichtet sein, um eine Antwort bezüglich des Versionierungsstatus für die Schreibanforderung zu empfangen. Der Schreibantwort-Handler 538 kann den Versionierung-aktiviert-Status 532.1 lesen und bestimmen, ob die Versionsschreibanforderung mit einem gültigen Versionierung-aktiviert-Status 532.1 abgeschlossen wurde. In einigen Ausführungsformen kann der gültige/ungültige Statuswert, der durch den Schreibantwort-Handler 538 bestimmt wird, an eine Schreiben-abgeschlossen-Status-Nachricht angehängt werden, die von der Speicherschnittstelle 520 erzeugt wird.
  • Der Replikations-Manager 540 kann Funktionen, Verfahren oder Operationen zum Verwalten der Übertragung von Datenobjekten, einschließlich versionierten Datenobjekten, zu anderen Objektspeichern oder Objektspeichersystemen einschließen. Zum Beispiel kann der Replikations-Manager 540 einen oder mehrere Replikations-Engines verwalten, die Datenobjekte aus dem Objektspeicher 560 zu einem Zielobjektspeicher bewegt, der vom Objektspeicher 560 entfernt sein kann. Der Replikations-Manager 540 kann eingerichtet sein, um Datenobjekte zwischen heterogenen Datenspeichern zu übertragen. In einigen Ausführungsformen überträgt der Replikations-Manager 540 jedes versionierte Datenobjekt, einschließlich den Objekt-Identifier 562, die Objektdaten 564 und zugeordneter Objekt-Tags 566, die persistente Versionsfelder 568 einschließen können. In einigen Ausführungsformen kann der Replikations-Manager 540 Metadaten, die dem Datenobjekt zugeordnet sind, auch von einem entsprechenden Metadatenspeicher, wie dem Metadatenspeicher 550, unter Verwendung des Objektdatenindex 552 übertragen, um zugeordnete Objekt-Metadaten 554 zu identifizieren, die persistente Versionsfelder 568 einschließen können.
  • In einigen Ausführungsformen kann der Replikations-Manager 540 für asynchrone Datenübertragungen eingerichtet sein. Zum Beispiel kann ein Scheduler ein Objekt zur Übertragung auswählen, basierend auf anderen Kriterien als die Reihenfolge, in welcher sie innerhalb des Objektspeichers 560 geordnet werden, wie Objektgröße, Verfügbarkeit, etc. In einigen Ausführungsformen können mehrere Replikations-Engines parallel arbeiten und Objektversionen für das gleiche versionierte Datenobjekt zu ähnlichen Zeiten und unter Verwendung von Ressourcen und Pfaden übertragen, die zu unterschiedlichen Übertragungsraten führen können. Somit können die Objektversionen von versionierten Datenobjekten an dem Zielsystem in einer anderen Reihenfolge aufgenommen werden als sie in dem Objektspeicher 560 gespeichert wurden oder sogar in einer anderen Reihenfolge als sie gesendet wurden. Der Replikations-Manager 540 kann auch mehrteilige Datenobjektübertragungen unterstützen, die eine Vielzahl von Schreibtransaktionen einschließen, um eine einzelne Objektreplikation abzuschließen. Zum Beispiel kann ein mehrteiliger Schreibprozess eine Reihe von Befehlen oder Nachrichten einschließen, wie INIT, mehrere PARTPUT- und COMPLETE-Funktionen.
  • In einigen Ausführungsformen kann der Replikations-Manager 540 eine oder mehrere Hardware- und/oder Software-Module oder Datenstrukturen zum Ausführen spezifischer Operationen einschließen. Zum Beispiel kann der Replikations-Manager 540 eine Versionsschreibanforderung 542, eine Versionierung-ungültig-Liste 544, einen Versionsantwort-Handler 546 und eine Wiederholungswarteschlange 548 einschließen.
  • Die Versionsschreibanforderung 542 kann einen Befehl, Schnittstellenprotokolle und/oder einen Satz von Funktionen und Parametern für eine spezielle Schreiboperation einschließen, um ein validiertes Schreiben eines versionierten Datenobjekts in einen anderen Objektspeicher bereitzustellen. Wenn zum Beispiel der Replikations-Manager mit der Replikation eines versionierten Datenobjekts zu einem heterogenen Datenspeicher mit unbekannter Versionierungskonfiguration beauftragt wird, kann die Versionsschreibanforderung 542 dem versionierten Datenobjekt ermöglichen, übertragen und geschrieben zu werden, während validiert wird, dass eine gültige Versionierungskonfiguration auf dem Zieldatenspeicher betriebsbereit war, bevor bestätigt wird, dass die Übertragung zur Speicherschnittstelle 520 oder einer anderen System-Ressource oder -Client abgeschlossen ist. In einigen Ausführungsformen kann eine Versionsschreibanforderung 542 als ein PUT oder ein mehrteiliger PUT-Befehl arbeiten, der auf eine Antwort-Nachricht wartet, der eine versionierungsbezogene Information zum Bestimmen, ob der Versionierungsstatus für die PUT-Anforderung gültig war, einschließt. Die Versionsschreibanforderung 542 kann in Verbindung mit dem Versionsantwort-Handler 546 arbeiten, um den Versionierungsstatus zu empfangen und zu validieren.
  • In einigen Ausführungsformen kann die Versionsschreibanforderung 542 eingerichtet sein, um ein Testobjekt 542.1 zu verwenden, um den Versionierungsstatus des Zielobjektspeichers zu validieren. Zum Beispiel kann die Versionsschreibanforderung 542 eine Testversion-Schreibanforderung oder eine PUT-Anforderung an den Zielobjektspeicher mit dem Testobjekt 542.1 anstelle einer Objektversion oder eines Objektteils (für mehrteilige PUTs) erzeugen. In einigen Ausführungsformen kann das Testobjekt 542.1 eine oder mehrere Objektversionen für das Testobjekt mit keinen Host-Nutzdaten und einer kleinen Objektdatengröße relativ zu dem versionierten Datenobjekt, das repliziert wird, einschließen. Eine Testanforderung für das Testobjekt 542.1 kann vor dem Initiieren der Versionsschreibanforderung für das versionierte Datenobjekt, das für die Replikation ausgewählt wurde, ausgeführt werden. In einigen Ausführungsformen kann eine Testanforderung als Reaktion darauf initiiert werden, dass der Zielobjektspeicher oder Bucket einen Eintrag in der Versionierung-ungültig-Liste 544 hat und/oder als Reaktion auf das Bestimmen eines ungültigen Versionierung-aktiviert-Status von einer Antwort auf eine vorherige Anforderung an das gleiche Ziel. Die Testobjekte 542.1, die erfolgreich in den Zieldatenspeicher geschrieben wurden, können noch mit einer Löschanforderung von dem Versionsantwort-Handler 546 gefolgt werden, um Testobjekte aus dem Zieldatenspeicher auf eine Weise zu entfernen, die der Entfernung von Restdatenobjekten von ausgefallenen versionierten Schreibanforderungen ähnlich ist.
  • Die Versionierung-ungültig-Liste 544 kann eine Datenstruktur einschließen, die durch den Replikations-Manager 540 beibehalten wird, um die Effizienz der anfänglichen Versionsschreibanforderungen zu verbessern und den Versionierungsstatus während der iterativen Testnachricht und Wiederholungszyklen zu überwachen. Zum Beispiel kann die Versionierung-ungültig-Liste 544 eine durchsuchbare Datenstruktur mit Einträgen für Zielobjektspeicher einschließen, die einen ungültigen Versionierung-aktiviert-Status zurückgegeben haben. In einigen Ausführungsformen können Bucket-Identifier in einer Datentabelle organisiert und verwendet werden, um den Bucket-ungültig-Status für Buckets in einem oder mehreren Zielobjektspeichern zu indexieren. Die Versionierung-ungültig-Liste 544 kann eine Funktion oder ein Verfahren einschließen, um die Datenstruktur nach einem Bucket-Identifier von Interesse zu durchsuchen.
  • Der Versionsantwort-Handler 546 kann einen Befehl, Schnittstellenprotokolle und/oder einen Satz von Funktionen und Parametern zum Empfangen und Parsen von Antworten von dem Zielobjektspeicher einschließen, um das Schreiben eines versionierten Datenobjekts zu validieren. Zum Beispiel kann der Versionsantwort-Handler 546 Versionsschreibantwort-Nachrichten empfangen, die Parameter zum Anzeigen des Versionierung-aktiviert-Status des Zielobjektspeichers zu der Zeit der Versionsschreibanforderung einschließen. In einigen Ausführungsformen kann die Versionsschreibantwort-Nachricht einen Wert für den Versionierung-aktiviert-Status einschließen. In einigen Ausführungsformen kann der Versionsantwort-Handler 546 eine Logik zum Parsen der Parameter der Versionsschreibantwort-Nachricht einschließen, um den Versionierung-aktiviert-Status als gültig oder ungültig zu bestimmen.
  • Ein gültiger Versionierung-aktiviert-Status kann eine Operation-abgeschlossen oder ein ähnliche Erfolg-Nachricht auslösen und/oder eine weitere Verarbeitung der nachfolgenden Operationen innerhalb des Replikations-Managers 540 ermöglichen, wie das Senden einer Löschanforderung 546.1 für ein erfolgreich versioniertes Schreiben des Testobjekts 542.1. Ein ungültiger Versionierung-aktiviert-Status kann die Löschanforderung 546.1 auslösen, um jegliche Restobjektversionen zu entfernen, die in den Zielobjektspeicher geschrieben wurden, aber die Versionsschreibanforderung nicht abschließen. Ein ungültiger Versionierung-aktiviert-Status kann ein Benachrichtigungsereignis 546.2 zurück an den initiierenden Dienst oder Client auslösen. In einigen Ausführungsformen kann das Benachrichtigungsereignis 546.2 den ungültigen Versionierung-aktiviert-Status und/oder eine Anforderung einer Änderung der Versionierungskonfiguration für den Zielobjektspeicher anzeigen.
  • Die Wiederholungswarteschlange 548 kann eine Datenstruktur zum Aufrechterhalten einer Liste von anhängigen Versionsschreibanforderungen einschließen, die durch einen iterativen Wiederholungsprozess erneut versucht werden können. Zum Beispiel kann ein iterativer Wiederholungsprozess für eine feste Anzahl von Wiederholungen, Wiederholungslaufzeitspanne oder ein andere Grenze der Wiederholungsversuche aktiviert werden, mit oder ohne die Verwendung von Test-Nachrichten, um auf eine Änderung des Versionierung-aktiviert-Status zu warten. In einigen Ausführungsformen kann die Wiederholungswarteschlange 548 in einer Datenstruktur beibehalten werden, wie zum Beispiel einer Operationen-Tabelle, mit Einträgen für jede anhängige Versionsschreibanforderung und einen oder mehrere Parameter zur Bestimmung der Priorität, der Anzahl der Versuche und anderer datenrelevanter Versionsschreibanforderungdaten zur Verwaltung von Wiederholungsversuchen.
  • In einigen Ausführungsformen können die Versionsschreibanforderung 542, die Versionierung-ungültig-Liste 544, der Versionsantwort-Handler 546 und/oder die Wiederholungswarteschlange 548 eine oder mehrere atomare Funktionen zum Ausführen einer gültigen versionierten Datenobjekt-Replikation bereitstellen (oder einen entsprechenden Fehler für eine Replikation, die nicht abgeschlossen werden konnte, wie oben beschrieben). Eine atomare Funktion kann von oder durch die Speicherschnittstelle 520 aufgerufen oder angefordert werden und dann einen Betriebszustand beibehalten, bis das Ergebnis oder die Antwort ohne weitere Interaktion mit dem initiierenden Dienst zurückgegeben wird. Zum Beispiel kann die Versionsschreibanforderung 542 die PUT-Anforderung senden, der Versionsantwort-Handler 546 kann die Versionsschreibantwort empfangen und bestimmen, ob eine Löschanforderung verarbeitet werden muss und der Replikations-Manager 540 kann eine Ergebnis-, Abschluss- oder Fehlermeldung erst zurückgeben, nachdem die Löschanforderung erfolgreich ausgeführt wurde. In ähnlicher Weise können, wenn eine Versionsschreibanforderung 542 eingerichtet ist, um Testanforderungen oder iterative Versuche unter Verwendung der Wiederholungswarteschlange 548 zu verwenden, solche Operationen in ähnlicher Weise durch den Replikations-Manager ausgeführt werden, bis eine Auflösung der Versionsschreibanforderung ohne weitere Eingabe von dem initiierenden Dienst oder Client erreicht wird.
  • Der Speicher 516 kann eine zusätzliche Logik und andere Ressourcen (nicht gezeigt) zum Verarbeiten von Objektdatenanforderungen, wie Module zum Erzeugen, Anstellen in Warteschlangen und anderweitigem Verwalten von Objektdatenanforderungen, einschließen. Die Verarbeitung einer Objektdatenanforderung durch die Speicherschnittstelle 520 kann eine beliebige Anzahl von Zwischenschritten einschließen, die mindestens eine Datenanforderung an das verteilte Speichersystem liefert.
  • 6 zeigt ein versioniertes Datenobjekt 634, das zwischen beispielhaften heterogenen Datenspeichern 600 in den Objektspeichersystemen 630.1 und 630.2 übertragen wurde. In einigen Ausführungsformen können heterogene Datenspeicher 600 gemäß den Systemen und Elementen konfiguriert werden, die mit Bezug auf 1-5 beschrieben wurden. In dem gezeigten Beispiel ist der Versionierungsstatus 638.1 gültig und der Versionierungsstatus 638.2 ungültig für die Übertragung zwischen den Objektspeichersystemen 630.1 und 630.2. Das versionierte Datenobjekt 634.1 ist in dem Bucket 632.1 im Objektspeichersystem 630.1 mit intakten Objektversionen gezeigt. Das Objekt 634.1 im Bucket 632.1 kann der ursprüngliche Objektspeicher sein, bei dem das Objekt 634.1 und entsprechende Objektversionen 1111, 2222, 3333 ursprünglich in sequentieller Reihenfolge erstellt wurden. Die Metadaten-Tags 636.1.1, 636.1.2, und 636.1.3 können persistente Versionsfelder einschließen, welche die ursprünglichen Versionsdaten einschließen, einschließlich des Versions-Identifier und des Erstellungszeitstempels, die den sequentiellen Versionen des Datenobjekts entsprechen.
  • Durch eine versuchte Versionsschreibanforderung 640 vom Objektspeichersystem 630.1 zum Objektspeichersystem 630.2 wurden die Objektversionen zum Objektspeichersystem 630.2 übertragen. Da der Versionierung-aktiviert-Status 638.2 ungültig war, wie die Versionierung für das Bucket 632.2 deaktiviert oder nicht verfügbar ist, wurde nur die Version 3333 erfolgreich für das Objekt 634.2 gespeichert. Dies führt dazu, dass die Version 3333 ein Restdatenobjekt für das Objekt 634.2 ist, was Fehler hervorrufen kann, wenn es im Bucket 632.2 verbleibt. Die Antwort 642 kann den Versionierung-aktiviert-Status 638.2 oder andere Parameter einschließen, aus denen der Versionierung-aktiviert-Status 638.2 bestimmt werden kann. Als ein Ergebnis kann, wenn das Objektspeichersystem 630.1 die Antwort 642 empfängt und verarbeitet, dies den Fehler beim Schreiben des versionierten Datenobjekts 634.2 identifizieren.
  • Das Objektspeichersystem 630.1 kann den ungültigen Versionsschreibversuch identifizieren. Als Reaktion kann das Objektspeichersystem 630.1 unmittelbar und automatisch die Löschen-Nachricht 644 ausgeben, um die Version 3333 und das Objekt 634.2 zu löschen. Es kann auf einen erfolgreichen Abschluss der Löschoperation und auf die Antwort 646 von dem Objektspeichersystem 630.2 vor dem Abschließen des fehlgeschlagenen Replikationsversuchs und dem Bereitstellen entsprechender Benachrichtigungen an die initiierenden Dienste oder Clients warten. In einem Endstatus können das Objekt 634.2 und die Version 3333 aus dem Objektspeichersystem 630.2 entfernt werden und ein weiterer Versuch kann durchgeführt werden, nachdem der Versionierungsstatus 638.2 aktualisiert wurde, ohne Konflikte mit dem Restdatenobjekt 634.2 zu erstellen.
  • Wie in 7 gezeigt, kann das Objektspeichersystem 500 gemäß einem beispielhaften Verfahren zum Validieren des Versionierung-aktiviert-Status betrieben werden, d. h. gemäß dem durch die Blöcke 710-780 veranschaulichten Verfahren 700 von 7.
  • Im Block 710 kann eine Versionsschreibanforderung an ein Zielobjektspeichersystem, einschließlich eines Zielobjektspeichers, gesendet werden. Zum Beispiel kann ein Replikations-Manager eine Versionsschreibanforderung für ein versioniertes Datenobjekt erzeugen und die Versionsschreibanforderung senden. In einigen Ausführungsformen kann die Versionsschreibanforderungs-Nachricht eine Reihe von Versionsschreibanforderungs-Nachrichten für jedes der Objektversionen und/oder Teile eines mehrteiligen Objektschreibers, der mehrere Schreibtransaktionen beinhaltet, einschließen. Der Replikations-Manager kann dann auf eine Antwort warten.
  • Im Block 720 kann eine Antwortnachricht durch das Objektspeichersystem, das die Versionsschreibanforderung sendet, empfangen werden. Zum Beispiel kann das Objektspeichersystem eine Antwortnachricht als Reaktion auf eine PUT-Anforderung empfangen, die als Versionsschreibanforderungs-Nachricht gesendet wurde.
  • Im Block 730 kann der Versionierung-aktiviert-Status für den Zielobjektspeicher aus der Antwortnachricht bestimmt werden. Zum Beispiel kann die Antwortnachricht ein Flag oder einen anderen Parameterwert für den Versionierung-aktiviert-Status einschließen. In einigen Ausführungsformen kann der Replikations-Manager einen oder mehrere Parameter in der Antwortnachricht extrahieren und parsen, um den Versionierung-aktiviert-Status zu bestimmen. Kann im Block 735 bestimmt werden, ob der Versionierung-aktiviert-Status gültig ist? Falls ja, kann das Verfahren 700 zu Block 740 weitergehen. Falls nein, kann das Verfahren 700 zu Block 750 weitergehen.
  • Im Block 740 wurde der gültige Versionierung-aktiviert-Status für die Versionsschreibanforderung, zum Beispiel wie für Block 730 beschrieben, bestimmt. Im Block 745 kann eine Erfolgsbenachrichtigung als Reaktion auf den gültigen Versionierung-aktiviert-Status erzeugt werden. Zum Beispiel kann eine Erfolgsbenachrichtigung an den initiierenden Systemdienst oder Client gesendet werden, dass das versionierte Datenobjekt erfolgreich mit Versionierung repliziert wurde.
  • Im Block 750 wurde der ungültige Versionierung-aktiviert-Status für die Versionsschreibanforderung, zum Beispiel wie für Block 730 beschrieben, bestimmt. Im Block 760 wird eine Löschanforderung für das versionierte Datenobjekt an den Zielobjektspeicher gesendet. Zum Beispiel kann eine Löschanforderung zum Löschen jeglicher Restversion an den Zielobjektspeicher gesendet werden. Im Block 770 kann die Versionsschreibanforderung optional zu einer Wiederholungswarteschlange hinzugefügt werden, um erneut versucht zu werden. Im Block 780 kann ein Versionierung-ungültig-Benachrichtigungsereignis erzeugt werden. Zum Beispiel kann eine Fehlerbenachrichtigung, die einen Fehlercode für Versionierung-nicht-aktiviert einschließt, an den initiierenden Systemdienst oder Client gesendet werden. In einigen Ausführungsformen kann das Versionierung-ungültig-Benachrichtigungsereignis eine Nachricht an das Zielobjektspeichersystem oder an ein verwandtes Speicherverwaltungssystem erzeugen, um die Versionierung auf dem Zielobjektspeicher zu aktivieren. Zum Beispiel kann das Objektspeichersystem eingerichtet sein, um anzufordern, dass ein Versionierungs-Enabler auf dem Zielobjektspeichersystem den Versionierung-aktiviert-Status für den Zielobjektdaten-Bucket ändert.
  • Wie in 8 gezeigt, kann das Objektspeichersystem 500 gemäß einem beispielhaften Verfahren zum Antworten auf eine Versionsschreibanforderung betrieben werden, d. h. gemäß dem durch die Blöcke 810-870 veranschaulichten Verfahren 800 von 8. In einigen Ausführungsformen kann das Verfahren 800 auf das beispielhafte Verfahren 700 von 7 ansprechen, wie es durch das Zielobjektspeichersystem ausgeführt wird. In dem gezeigten Beispiel ist die Versionierung für den Zielobjektspeicher nicht aktiviert und der Versionierung-aktiviert-Status ist ungültig.
  • Im Block 810 wird eine Versionsschreibanforderung für ein versioniertes Datenobjekt empfangen. Zum Beispiel kann das ursprüngliche Objektspeichersystem eine Versionsschreibanforderung mit einer oder mehreren Objektversionen für ein versioniertes Datenobjekt senden.
  • Im Block 820 kann die Schreibanforderung ohne Versionierung verarbeitet werden, da der Versionierung-aktiviert-Status ungültig ist. Zum Beispiel kann jede der empfangenen Objektversionen die vorherige Objektversion für das versionierte Datenobjekt überschreiben.
  • Im Block 830 wird die Restversion des versionierten Datenobjekts mit diesem Objektnamen gespeichert. Zum Beispiel kann, nachdem jede vorherige Objektversion überschrieben wurde, nur die letzte Version als Restversion verbleiben und wird auf dem Objektspeicher unter Verwendung des Objektnamens und ohne Rücksicht auf irgendwelche Versionierungsinformation gespeichert, die in der Anforderung oder dem Objekt selbst bereitgestellt sind.
  • Im Block 840 wird eine Antwortnachricht nach Abschluss der Versionsschreibanforderung gesendet. Zum Beispiel kann das Abschließen einer Schreibanforderung eine Fertigstellungsnachricht erzeugen, die Parameter einschließt, um die Fertigstellungsnachricht mit der ursprünglichen Anforderungsnachricht abzustimmen. In einigen Ausführungsformen kann die Antwortnachricht einen Indikator bezogen auf den Versionierung-aktiviert-Status einschließen. In einigen Ausführungsformen kann die Antwortnachricht Parameter zum Beschreiben der Restdatenobjekte einschließen, die ohne Versionierungsinformation gespeichert wurden, aus denen der ungültige Versionierung-aktiviert-Status bestimmt werden kann.
  • Im Block 850 kann eine Löschanforderung für das Restobjekt empfangen werden. Zum Beispiel kann das ursprüngliche Objektspeichersystem als Reaktion auf das Bestimmen des ungültigen Versionierung-aktiviert-Status eine Löschanforderung für die Restversion(en) senden.
  • Im Block 860 wird die Restversion als Reaktion auf die Löschanforderung gelöscht. Zum Beispiel kann das Zielobjektspeichersystem die Löschanforderung verarbeiten um die Restversion zu löschen.
  • Im Block 870 wird eine Antwortnachricht durch das Zielobjektspeichersystem gesendet, um die Fertigstellung des Löschvorgangs zu bestätigen. Zum Beispiel kann die Fertigstellung einer Löschanforderung eine Fertigstellungsnachricht erzeugen, die Parameter einschließt, um die Fertigstellungsnachricht mit der ursprünglichen Anforderungsnachricht abzustimmen.
  • Wie in 9 gezeigt, kann das Objektspeichersystem 500 gemäß einem beispielhaften Verfahren zum Validieren des Versionierung-aktiviert-Status unter Verwendung von Testnachrichten betrieben werden, d. h. gemäß dem durch die Blöcke 910-990 veranschaulichten Verfahren 900 von 9.
  • Im Block 910 wird eine Replikationsanforderung für ein versioniertes Datenobjekt empfangen. Zum Beispiel kann ein Client oder ein Systemdienst eine Replikationsoperation für eines oder mehrere Datenobjekte, Buckets oder Objektspeicher in dem ursprünglichen Datenspeichersystem initiieren.
  • Im Block 920 wird eine Versionierung-ungültig-Liste für den Zielobjektspeicher gesucht. Zum Beispiel kann die Replikationsanforderung ein Ziel-Bucket für die Replikationsanforderung einschließen und der Bucket-Identifier kann als ein Index verwendet werden, um eine Versionierung-ungültig-Liste zu durchsuchen, die durch das ursprüngliche Speichersystem beibehalten wird. Im Block 925 kann bestimmt werden, ob sich das Ziel-Bucket in der Versionierung-ungültig-Liste befindet. Falls ja, kann das Verfahren 900 zu Block 930 weitergehen. Falls nein, kann das Verfahren 900 zu Block 980 weitergehen.
  • Im Block 930 kann eine Testanforderung an den Zielobjektspeicher gesendet werden. Zum Beispiel kann eine Testanforderung, die eine Versionsschreibanforderung für ein versioniertes Testobjekt ist, an das Zielobjektspeichersystem gesendet werden, das auf das Ziel-Bucket zielt. In einigen Ausführungsformen kann eine Versionsstatusanforderungs-Nachricht als eine Testnachricht gesendet werden.
  • Im Block 940 kann eine Testantwortnachricht an die Testanforderung von dem Zielobjektspeichersystem empfangen werden. Zum Beispiel kann die Versionsschreibanforderung für das Testobjekt eine Antwortnachricht erzeugen, von dem der gültige Versionierung-aktiviert-Status bestimmt werden kann. Alternativ kann eine Antwortnachricht an eine Versionsstatusanforderung die Versionierung-aktiviert-Statusinformation einschließen, von der der gültige oder ungültige Status bestimmt werden kann. Im Block 945 kann bestimmt werden, ob der Versionierung-aktiviert-Status gültig ist. Falls ja, kann das Verfahren 900 zu Block 950 weitergehen. Falls nein, kann das Verfahren 900 zu Block 960 weitergehen.
  • Im Block 950 kann der Zielobjektspeicher von der ungültig-Liste als Reaktion auf den gültigen Versionierungstest entfernt werden. Zum Beispiel kann das ursprüngliche Objektspeichersystem, wenn der gültige Versionierung-aktiviert-Status aus der Antwortnachricht bestimmt wird, den Eintrag für das Ziel-Bucket aus der Versionierung-ungültig-Liste entfernen. Das Verfahren 900 kann zu Block 970 weitergehen, um einen Wiederholungsversuch zu initiieren.
  • Im Block 960 kann die Versionierung-ungültig-Liste als Reaktion auf die ungültige Versionierung aktualisiert werden. Wenn zum Beispiel bereits ein Eintrag für das Ziel-Bucket existiert, kann dieser Eintrag dann mit der aktuellsten Versuchsinformation oder anderen verwandten Daten aktualisiert werden. Wenn kein Eintrag für das Ziel-Bucket existiert, kann ein neuer Eintrag dann für das Ziel-Bucket erstellt werden.
  • Im Block 970 kann eine Wiederholungsiteration initiiert werden. Zum Beispiel kann eine Wiederholung initiiert werden, falls eine Testiteration eine gültige Versionierung bestanden oder nicht bestanden hat oder eine Versionsschreibanforderung für das versionierte Datenobjekt, das repliziert wurde, eine gültig Versionierung nicht bestanden hat. In einigen Ausführungsformen kann der Wiederholungsversuch einen Satz von Grenzbedingungen einschließen, die bestimmen, ob der Wiederholungsversuch zurück zu Block 920 geht.
  • Im Block 980 wird eine Versionsschreibanforderung für das versionierte Datenobjekt, das repliziert werden soll, initiiert. Zum Beispiel kann die Versionsschreibanforderung verarbeitet werden, wie oben für das Verfahren 700 beschrieben. Im Block 985 kann bestimmt werden, ob der Versionierung-aktiviert-Status gültig ist. Falls ja, kann das Verfahren 900 zu Block 990 weitergehen. Falls nein, kann das Verfahren 900 zu Block 960 weitergehen. Im Block 990 kann die Versionsschreibanforderung für das versionierte Datenobjekt abgeschlossen werden, wie oben in Bezug auf das Verfahren 700 beschrieben.
  • Während mindestens eine beispielhafte Ausführungsform in der vorstehenden ausführlichen Beschreibung der Technologie dargestellt worden ist, sollte gewürdigt werden, dass eine große Anzahl von Variationen existieren kann. Es sollte auch beachtet werden, dass eine beispielhafte Ausführungsform oder die beispielhaften Ausführungsformen Beispiele sind, und in keiner Weise den Umfang, die Anwendbarkeit, oder Konfiguration der Technologie einschränken sollen. Die vorangehende genaue Beschreibung wird vielmehr eine brauchbare Anleitung für Fachleute zur Implementierung einer beispielhaften Ausführungsform der Technologie bereitstellen, wobei es sich versteht, dass verschiedene Modifikationen an einer Funktion und/oder Anordnung von Elementen vorgenommen werden können, die in einer beispielhaften Ausführungsform beschrieben sind, ohne vom Umfang der Technologie abzuweichen, wie in den beigefügten Ansprüchen und ihren rechtlichen Entsprechungen dargelegt.
  • Wie einem Durchschnittsfachmann bekannt, können verschiedene Ausführungsformen der vorliegenden Erfindung als ein System, Verfahren oder Computerprogrammprodukt verkörpert werden. Folglich können Ausführungsformen der vorliegenden Offenlegung die Form einer vollständigen Hardware-Ausführung, einer vollständigen Software-Ausführung (einschließlich Firmware, speicherresidente Software, Mikrocodes, oder dergleichen) oder Ausführungsformen in der Form einer Kombination von Hardware und Software annehmen, die alle allgemein hierin als Schaltung, Modul, System und/oder Netzwerk bezeichnet werden können. Darüber hinaus können verschiedene Ausführungsformen der vorliegenden Technologie die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien verkörpert ist, einschließlich eines darauf ausgebildeten computerlesbaren Programmcodes.
  • Es kann jede Kombination eines oder mehrerer computerlesbarer Speichermedien verwendet werden. Ein computerlesbares Medium kann ein computerlesbares Signalmedium oder ein physisches oder computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, ein Gerät oder eine Vorrichtung, usw. oder irgendeine geeignete Kombination der Vorstehenden sein. Nicht einschränkende Beispiele eines physischen computerlesbaren Speichermediums können eine elektrische Verbindung, einschließlich einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM), Festwertspeicher (Read-Only Memory, ROM), löschbaren programmierbaren Festwertspeicher (Erasable Programmable Read-Only Memory, EPROM), elektrisch löschbaren programmierbaren Festwertspeicher (Electrically Erasable Programmable Read-Only Memory, EEPROM), einen Flash-Speicher, eine optische Faser, einen Compact Disk-Festwertspeicher (Compact Disk Read-Only Memory, CD-ROM), einen optischen Prozessor, einen magnetischen Prozessor usw. oder eine beliebige geeignete Kombination der Vorstehenden einschließen, sind aber nicht darauf beschränkt. Im Kontext dieses Dokuments kann ein computerlesbares und/oder ausführbares Speichermedium jedes greifbare Medium sein, das ein Programm oder Daten zur Verwendung durch ein System, ein Gerät und/oder eine Vorrichtung zur Befehlsausführung oder in Verbindung mit einer/einem solchen, enthalten oder speichern kann.
  • Ein Computercode, der auf einem computerlesbaren Medium enthalten ist, kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, einschließlich, aber nicht beschränkt auf, drahtloses, verdrahtetes, optisches Faserkabel, Radiofrequenz (RF), usw. oder jede geeignete Kombination des Vorhergehenden. Ein Computercode zur Ausführung von Prozessen bei Ausführungsformen der vorliegenden Erfindung kann in einer beliebigen statischen Sprache, wie die C-Programmiersprache oder andere ähnliche Programmiersprachen, geschrieben werden. Der Computercode kann vollständig auf einer Rechenvorrichtung des Benutzers, teilweise auf einer Rechenvorrichtung des Benutzers, als ein alleinstehendes Softwarepaket, teilweise auf einer Rechenvorrichtung des Benutzers und teilweise auf einer Remote-Rechenvorrichtung oder vollständig auf der Remote-Vorrichtung oder einem Server ausgeführt werden. In dem letzteren Gedankenspiel kann eine Remote-Rechenvorrichtung mit einer Rechenvorrichtung des Benutzers durch eine beliebige Art von Netzwerk oder Kommunikationssystem, einschließlich, aber nicht begrenzt auf, ein lokales Netzwerk (LAN) oder ein Wide Area Network (WAN), eine Netzkonvergenz, verbunden sein, oder die Verbindung kann zu einem externen Computer (z. B. durch das Internet unter Verwendung eines Internetanbieters) hergestellt werden.
  • Verschiedene Ausführungsformen der vorliegenden Erfindung können oben mit Bezug auf die Flussdiagramme und/oder Blockdiagramme von Verfahren, Vorrichtungen, Systemen und Computerprogrammprodukten beschrieben sein. Es versteht sich, dass jeder Block des schematischen Flussdiagramms und/oder schematischen Blockdiagramms und Kombinationen von Blöcken in den schematischen Flussdiagrammen und/oder schematischen Blockdiagrammen durch Computerprogrammanweisungen implementiert werden kann. Diese Computerprogrammanweisungen können einer Verarbeitungseinheit (Prozessor) eines allgemeinen Computers, speziellen Computers oder einer anderen programmierbaren Datenverarbeitungsanlage zur Erzeugung einer Maschine bereitgestellt werden, so dass die Anweisungen, die über die Verarbeitungsvorrichtung oder andere programmierbare Datenverarbeitungsanlagen ausgeführt werden können, Mittel zum Implementieren der Abläufe/Handlungen in einem Flussdiagramm und/oder Block (Blöcken) eines Blockdiagramms erzeugen.
  • Einige Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder (eine) andere Vorrichtung(en) zum Betrieb in einer bestimmten Weise steuern kann, so dass die in einem computerlesbaren Medium gespeicherten angefertigten Artikel Anweisungen beinhalten, die den in einem Flussdiagramm und/oder Block (Blöcken) eines Blockdiagramms spezifizierten Betrieb/Vorgang implementieren. Einige Computerprogrammanweisungen können auch auf eine Rechenvorrichtung, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Vorrichtung(n) geladen werden, um zu bewirken, dass eine Reihe von Betriebsschritten an der Rechenvorrichtung, einer anderen programmierbaren Vorrichtung oder (einer) anderen Vorrichtung(en) durchgeführt werden, so dass die Anweisungen, die durch den Computer oder eine andere programmierbare Vorrichtung ausgeführt werden, einen oder mehrere Prozesse zur Implementierung der in einem Flussdiagramm und/oder Block (Blöcken) eines Blockdiagramms spezifizierten Betrieb/Vorgang bereitstellen.
  • Ein Flussdiagramm und/oder Blockdiagramm in den obigen Figuren kann eine Bauweise, Funktionalität und/oder einen Vorgang möglicher Implementierungen von Vorrichtungen, Systemen, Verfahren und/oder Computerprogrammprodukten gemäß verschiedenen Aspekten der vorliegenden Technologie veranschaulichen. In dieser Hinsicht kann ein Block in einem Flussdiagramm oder Blockdiagramm ein Modul, Segment oder einen Teil eines Codes darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren einer oder mehrerer spezifizierter logischer Funktionen umfassen kann. Es sollte auch beachtet werden, dass in einigen alternativen Implementierungen die in dem Block angegebenen Funktionen außerhalb der in den Figuren angegebenen Reihenfolge auftreten können. Zum Beispiel können zwei nacheinander gezeigte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in der umgekehrten Reihenfolge ausgeführt werden, entsprechend der involvierten Funktionalität. Es sei auch angemerkt, dass ein Block einer Blockdiagramm- und/oder einer Flussdiagrammdarstellung oder eine Kombination von Blöcken in einer Blockdiagramm- und/oder einer Flussdiagrammdarstellung durch speziell auf Hardware basierenden Systemen implementiert werden kann, die eine oder mehrere spezifizierte Vorgänge oder Handlungen ausführen, oder durch Kombinationen von Hardware zu speziellen Zwecken und Computeranweisungen.
  • Während ein oder mehrere Aspekte der vorliegenden Technologie im Detail dargestellt und besprochen wurden, wird ein Fachmann erkennen, dass Modifikationen und/oder Anpassungen an die verschiedenen Aspekte vorgenommen werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen, wie in den folgenden Ansprüchen dargelegt.

Claims (20)

  1. System, das aufweist: einen ersten Objektdatenspeicher, der eingerichtet ist, um eine erste Vielzahl von versionierten Datenobjekten einzuschließen, wobei ein versioniertes Datenobjekt der ersten Vielzahl von versionierten Datenobjekten eine Vielzahl von sequentiellen Versionen einschließt, die dem versionierten Datenobjekt entspricht; einen zweiten Objektdatenspeicher, der eingerichtet ist, um einen Versionierung-aktiviert-Status einzuschließen; und einen Replikations-Manager einschließlich mindestens eines Prozessors, wobei der Replikations-Manager eingerichtet ist zum: Übertragen des versionierten Datenobjekts aus dem ersten Objektdatenspeicher in den zweiten Objektdatenspeicher; Senden einer Versionsschreibanforderungsnachricht an den zweiten Objektdatenspeicher für das versionierte Datenobjekt; Empfangen einer Antwortnachricht von dem zweiten Objektdatenspeicher; Bestimmen, aus der Antwortnachricht, ob der Versionierung-aktiviert-Status ungültig ist; und Senden, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einer Löschanforderung an den zweiten Objektdatenspeicher für das versionierte Datenobjekt.
  2. System gemäß Anspruch 1, wobei der Replikations-Manager ferner eingerichtet ist, um als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, eine Versionsschreibanforderung für das versionierte Datenobjekt zu einer Wiederholungswarteschlange hinzuzufügen.
  3. System gemäß Anspruch 1, wobei der Replikations-Manager ferner eingerichtet ist, um als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, ein Benachrichtigungsereignis zu erzeugen, das eingerichtet ist, um eine Aktivierung der Versionierung beim zweiten Objektdatenspeicher anzufordern.
  4. System gemäß Anspruch 1, wobei der zweite Objektdatenspeicher eingerichtet ist zum: Speichern einer Restversion des versionierten Datenobjekts, als Reaktion auf die Versionsschreibanforderungs-Nachricht, in dem zweiten Objektdatenspeicher, als Reaktion darauf, dass der Versionierung-aktiviert-Status ungültig ist; und Löschen der Restversion des versionierten Datenobjekts, als Reaktion auf die Löschanforderung.
  5. System gemäß Anspruch 1, wobei die Versionsschreibanforderungs-Nachricht eine mehrteilige Schreibanforderung ist, die mehrere Schreibtransaktionen zwischen dem ersten Objektdatenspeicher und dem zweiten Objektdatenspeicher einschließt, um das versionierte Datenobjekt zu übertragen.
  6. System gemäß Anspruch 5, wobei: der Replikations-Manager ferner eingerichtet ist, um eine Testnachricht an den zweiten Objektdatenspeicher zu senden, bevor die Versionsschreibanforderungs-Nachricht für die mehrteilige Schreibanforderung initiiert wird; und das Initiieren der Versionsschreibanforderungs-Nachricht als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status gültig ist, durchgeführt wird.
  7. System gemäß Anspruch 6, wobei die Testnachricht eine Testversionsschreibanforderungs-Nachricht ist, die eine Host-Datengröße von 0 einschließt.
  8. System gemäß Anspruch 6, wobei der Replikations-Manager ferner eingerichtet ist, um als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, das Senden der Testnachricht mehrere Male zu wiederholen.
  9. System gemäß Anspruch 1, wobei: der Replikations-Manager ferner eingerichtet ist, um eine Versionierung-ungültig-Liste der Zielobjektdaten-Buckets mit einem ungültigen Versionierung-aktiviert-Status einzuschließen; und der Replikations-Manager ferner eingerichtet ist, um als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einen Versionierung-ungültig-Eintrag für ein Zielobjektdaten-Bucket in dem zweiten Objektdatenspeicher hinzuzufügen.
  10. System gemäß Anspruch 9, wobei Replikations-Manager ferner eingerichtet ist zum: Durchsuchen der Versionierung-ungültig-Liste für das Zielobjektdaten-Bucket für die Versionsschrei banforderungs-Nachricht; Senden, als Reaktion auf das Finden des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket, einer Testversionsschreibanforderungsnachricht an das Zielobjektdaten-Bucket; und als Reaktion auf das Empfangen einer Testantwortnachricht, die angibt, dass der Versionierung-aktiviert-Status gültig ist: Entfernen des Versionierung-ungültig-Eintrags für den Zielobjektdaten-Bucket; und Initiieren des Sendens der Versionsschreibanforderungs-Nachricht.
  11. Computerimplementiertes Verfahren, aufweisend: Senden einer Versionsschreibanforderungs-Nachricht für ein versioniertes Datenobjekt von einem ersten Objektdatenspeicher zu einem zweiten Objektdatenspeicher, wobei: das versionierte Datenobjekt eine Vielzahl von sequentiellen Versionen einschließt, die dem versionierten Datenobjekt entsprechen; und der zweite Objektdatenspeicher einen Versionierung-aktiviert-Status einschließt; Empfangen einer Antwortnachricht von dem zweiten Objektdatenspeicher; Bestimmen, aus der Antwortnachricht, ob der Versionierung-aktiviert-Status ungültig ist; und Senden, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, einer Löschanforderung an den zweiten Objektdatenspeicher für das versionierte Datenobjekt.
  12. Computerimplementiertes Verfahren gemäß Anspruch 11, ferner aufweisend: Hinzufügen einer Versionsschreibanforderung für das versionierte Datenobjekt zu einer Wiederholungswarteschlange als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist.
  13. Computerimplementiertes Verfahren gemäß Anspruch 11, ferner aufweisend: Erzeugen eines Benachrichtigungsereignisses als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, das eingerichtet ist, um eine Aktivierung der Versionierung am zweiten Objektdatenspeicher anzufordern.
  14. Computerimplementiertes Verfahren gemäß Anspruch 11, ferner aufweisend: Speichern einer Restversion des versionierten Datenobjekts als Reaktion auf die Versionsschreibanforderungs-Nachricht in dem zweiten Objektdatenspeicher, als Reaktion darauf, dass der Versionierung-aktiviert-Status ungültig ist; und Löschen der Restversion des versionierten Datenobjekts als Reaktion auf die Löschanforderung.
  15. Computerimplementiertes Verfahren gemäß Anspruch 11, ferner aufweisend: Senden einer Testnachricht an den zweiten Objektdatenspeicher; und Empfangen einer Testantwortnachricht von dem zweiten Objektdatenspeicher, wobei das Senden der Versionsschreibanforderungs-Nachricht als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status gültig ist, von der Testantwortnachricht durchgeführt wird.
  16. Computerimplementiertes Verfahren gemäß Anspruch 15, ferner aufweisend: mehrmaliges Wiederholen des Sendens der Testnachricht als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist.
  17. Computerimplementiertes Verfahren gemäß Anspruch 11, ferner aufweisend: Hinzufügen eines Versionierung-ungültig-Eintrags als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, für ein Zielobjektdaten-Bucket in dem zweiten Objektdatenspeicher in eine Versionierung-ungültig-Liste.
  18. Computerimplementiertes Verfahren gemäß Anspruch 17, ferner aufweisend: Durchsuchen der Versionierung-ungültig-Liste für das Zielobjektdaten-Bucket für die Versionsschrei banforderungs-Nachricht; Senden einer Testnachricht zu dem Zielobjektdaten-Bucket als Reaktion auf das Finden des Versionierung-ungültig-Eintrags für das Zielobjektdaten-Bucket; und als Reaktion auf das Empfangen einer Testantwortnachricht, die angibt, dass der Versionierung-aktiviert-Status gültig ist: Entfernen des Versionierung-ungültig-Eintrags für den Zielobjektdaten-Bucket; und Initiieren des Sendens der Versionsschreibanforderungs-Nachricht.
  19. System, das aufweist: einen ersten Objektdatenspeicher, der eingerichtet ist, um eine erste Vielzahl von versionierten Datenobjekten einzuschließen, wobei ein versioniertes Datenobjekt eine Vielzahl von sequentiellen Versionen einschließt, die dem versionierten Datenobjekt entspricht; einen zweiten Objektdatenspeicher, wobei der zweite Objektdatenspeicher eingerichtet ist, um einen Versionierung-aktiviert-Status einzuschließen; Mittel zum Senden einer Versionsschreibanforderungs-Nachricht für das versionierte Datenobjekt von dem ersten Objektdatenspeicher zu dem zweiten Objektdatenspeicher; Mittel zum Bestimmen, ob der Versionierung-aktiviert-Status ungültig ist, als Reaktion auf eine Antwortnachricht von dem zweiten Objektdatenspeicher; und Mittel zum Senden einer Löschanforderung als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status ungültig ist, an den zweiten Objektdatenspeicher für das versionierte Datenobjekt.
  20. System gemäß Anspruch 19, ferner aufweisend: Mittel zum Senden einer Testnachricht an den zweiten Objektdatenspeicher; und Mittel zum Empfangen einer Testantwortnachricht von dem zweiten Objektdatenspeicher, wobei das Senden der Versionsschreibanforderungs-Nachricht, als Reaktion auf das Bestimmen, dass der Versionierung-aktiviert-Status gültig ist, von der Testantwortnachricht durchgeführt wird.
DE112019000143.4T 2018-06-02 2019-03-22 Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern Pending DE112019000143T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
IN201811020720 2018-06-02
IN201811020720 2018-06-02
US16/361,493 2019-03-22
PCT/US2019/023751 WO2019231527A1 (en) 2018-06-02 2019-03-22 Versioning validation for data transfer between heterogeneous data stores
US16/361,493 US11403269B2 (en) 2018-06-02 2019-03-22 Versioning validation for data transfer between heterogeneous data stores

Publications (1)

Publication Number Publication Date
DE112019000143T5 true DE112019000143T5 (de) 2020-09-03

Family

ID=68692653

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019000143.4T Pending DE112019000143T5 (de) 2018-06-02 2019-03-22 Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern

Country Status (4)

Country Link
US (2) US11321291B2 (de)
CN (1) CN111356996B (de)
DE (1) DE112019000143T5 (de)
WO (2) WO2019231527A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10764354B1 (en) * 2019-03-01 2020-09-01 Red Hat, Inc. Transmitting data over a network in representational state transfer (REST) applications
US11122120B2 (en) * 2019-05-28 2021-09-14 International Business Machines Corporation Object notification wherein compare and swap is performed
US11082494B2 (en) * 2019-12-05 2021-08-03 Western Digital Technologies, Inc. Cross storage protocol access response for object data stores
CN113742050B (zh) * 2020-05-27 2023-03-03 华为技术有限公司 操作数据对象的方法、装置、计算设备和存储介质
US11593017B1 (en) 2020-08-26 2023-02-28 Pure Storage, Inc. Protection of objects in an object store from deletion or overwriting
CN112463886B (zh) * 2020-11-30 2024-06-04 浙江大华技术股份有限公司 一种数据处理方法、装置、电子设备及存储介质
JP2024504131A (ja) * 2021-01-19 2024-01-30 スラック テクノロジーズ， エルエルシー 非同期分散モジュラ関数呼び出し
CN112860811B (zh) * 2021-02-05 2023-07-18 北京百度网讯科技有限公司 数据血缘关系的确定方法、装置、电子设备和存储介质
CN114116746A (zh) * 2021-11-24 2022-03-01 北京字节跳动网络技术有限公司 多系统数据存储方法、装置、介质及电子设备
US11989164B2 (en) * 2022-09-30 2024-05-21 Snowflake Inc. Data dictionary metadata for marketplace listings

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5649200A (en) 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system
US5813009A (en) * 1995-07-28 1998-09-22 Univirtual Corp. Computer based records management system method
US5729744A (en) * 1996-06-10 1998-03-17 International Business Machine Corp. Method and system of enhanced versioning control of objects in a data processing system using change control information which includes reasons for changes
US6732162B1 (en) * 1999-11-15 2004-05-04 Internet Pictures Corporation Method of providing preprocessed images for a plurality of internet web sites
US6615223B1 (en) * 2000-02-29 2003-09-02 Oracle International Corporation Method and system for data replication
US20030145199A1 (en) * 2002-01-31 2003-07-31 Miller Layne B. Data pool with validity detection
US7289973B2 (en) * 2002-12-19 2007-10-30 Mathon Systems, Inc. Graphical user interface for system and method for managing content
US20070208790A1 (en) 2006-03-06 2007-09-06 Reuter James M Distributed data-storage system
US20080005077A1 (en) 2006-06-29 2008-01-03 Eggebraaten Thomas J Encoded version columns optimized for current version access
US8731994B2 (en) * 2006-10-06 2014-05-20 Accenture Global Services Limited Technology event detection, analysis, and reporting system
US8566362B2 (en) 2009-01-23 2013-10-22 Nasuni Corporation Method and system for versioned file system using structured data representations
US8566290B2 (en) * 2009-10-30 2013-10-22 Hitachi Data Systems Corporation Fixed content storage within a partitioned content platform using namespaces, with versioning
US20120072449A1 (en) * 2010-09-17 2012-03-22 Microsoft Corporation Object instance versioning
US8533170B1 (en) * 2010-09-21 2013-09-10 Amazon Technologies, Inc. System and method for determining the latest version of a stored data object
US8504758B1 (en) 2010-09-21 2013-08-06 Amazon Technologies, Inc. System and method for logical deletion of stored data objects
JP5656563B2 (ja) 2010-11-02 2015-01-21 キヤノン株式会社 文書管理システム、文書管理システムの制御方法、プログラム
US8650156B1 (en) 2010-12-23 2014-02-11 Amazon Technologies, Inc. System and method for fetching the latest versions of stored data objects
US9053117B2 (en) 2012-04-11 2015-06-09 4Clicks Solutions, LLC Storing application data with a unique ID
US10102204B2 (en) * 2012-11-20 2018-10-16 International Business Machines Corporation Maintaining access control lists in non-identity-preserving replicated data repositories
US9098522B2 (en) 2012-11-29 2015-08-04 Sap Se Version garbage collection using snapshot lists
US9838375B2 (en) 2013-02-28 2017-12-05 Microsoft Technology Licensing, Llc RESTlike API that supports a resilient and scalable distributed application
CN105337923B (zh) * 2014-05-26 2019-07-12 腾讯科技（北京）有限公司 数据分发方法和系统及数据发送装置和数据接收装置
GB2527296A (en) * 2014-06-16 2015-12-23 Ibm A method for restoring data in a HSM system
US10120917B2 (en) 2014-09-26 2018-11-06 Oracle International Corporation Integrating object-based data integration tool with a version control system in centralized and decentralized environments
US10229128B2 (en) * 2014-11-19 2019-03-12 Rubrik, Inc. Method and apparatus for the generation, organization, storage and retrieval of time stamped blocks of data
US10884869B2 (en) * 2015-04-16 2021-01-05 Nuodb, Inc. Backup and restore in a distributed database utilizing consistent database snapshots
US10725708B2 (en) * 2015-07-31 2020-07-28 International Business Machines Corporation Replication of versions of an object from a source storage to a target storage
WO2017023709A1 (en) * 2015-08-06 2017-02-09 Nexenta Systems, Inc. Object storage system with local transaction logs, a distributed namespace, and optimized support for user directories
US10298656B2 (en) 2016-06-08 2019-05-21 Western Digital Technologies, Inc. Extending representational state transfer application program interface (REST API) functionality
US10097344B2 (en) * 2016-07-15 2018-10-09 Mastercard International Incorporated Method and system for partitioned blockchains and enhanced privacy for permissioned blockchains

Also Published As

Publication number Publication date
WO2019231526A1 (en) 2019-12-05
US11321291B2 (en) 2022-05-03
CN111356996B (zh) 2023-07-21
US11403269B2 (en) 2022-08-02
US20190370237A1 (en) 2019-12-05
WO2019231527A1 (en) 2019-12-05
CN111356996A (zh) 2020-06-30
US20190370236A1 (en) 2019-12-05

Similar Documents

Publication Publication Date Title
DE112019000143T5 (de) Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern
CN110799960B (zh) 数据库租户迁移的系统和方法
AU2016405587B2 (en) Splitting and moving ranges in a distributed system
DE102008015662B4 (de) Beseitigung von Daten
CN107077382B (zh) 在多租户应用服务器环境中进行事务恢复的系统和方法
DE112012005037B4 (de) Verwalten von redundanten unveränderlichen Dateien unter Verwendung von Deduplizierungen in Speicher-Clouds
DE112019002584T5 (de) Wechseln zwischen vermittlerdiensten für ein speichersystem
DE202009019149U1 (de) Asynchron verteilte Speicherbereinigung für replizierte Speichercluster
US11249943B2 (en) Scalable enterprise content management
DE102019111068A1 (de) Datenspeichersystem mit LUN-Archivierung in die Cloud unter Verwendung einer Volume-to-Object(Volumen-zu-Objekt)-Umsetzung
DE102014116369A1 (de) Verwaltung von sprachmarkern bei internationaler datenspeicherung
DE112019000399B4 (de) Schnelle wiederherstellung nach ausfällen in einem chronologisch geordneten log-strukturierten schlüssel-wert-speichersystem
DE112019000402T5 (de) Chronologisch geordnetes out-of-place-aktualisierungs-schlüssel-wert-speichersystem
DE102021125630A1 (de) Datensynchronisation in einem datenanalysesystem
DE102022108863A1 (de) Sicherung von daten für einen namensraum, der einem mandanten zugeordnet ist
US11436089B2 (en) Identifying database backup copy chaining
DE112021006772T5 (de) Speicherarrayfehler-minderung
US11079960B2 (en) Object storage system with priority meta object replication
DE112011104020T5 (de) Validierung des Zugriffs auf einen gemeinsam genutzen Datensatz bei Lese- und Schreibzugriff mehrerer Anforderer
DE112019000401B4 (de) Ein chronologisch geordneter log-strukturierter schlüssel-wert-speicher für fehler bei der speicherbereinigung
US11093465B2 (en) Object storage system with versioned meta objects
US11074002B2 (en) Object storage system with meta object replication
CN114461572A (zh) 用于分布式文件系统的元数据采集方法及装置
US20170308542A1 (en) File system configuration data storage

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0016210000

Ipc: G06F0016270000

R081 Change of applicant/patentee

Owner name: WESTERN DIGITAL TECHNOLOGIES, INC., SAN JOSE, US

Free format text: FORMER OWNER: WESTERN DIGITAL TECHNOLOGIES, INC., SAN JOSE, CALIF., US

R082 Change of representative

Representative=s name: MEWBURN ELLIS LLP, DE

R083 Amendment of/additions to inventor(s)
R082 Change of representative

Representative=s name: MURGITROYD GERMANY PATENTANWALTSGESELLSCHAFT M, DE