DE112019006784T5

DE112019006784T5 - Skalierbare Datenbereinigung für die deduplizierte Speicherung

Info

Publication number: DE112019006784T5
Application number: DE112019006784.2T
Authority: DE
Inventors: Philip Shilane; Kimberly Lu; Joseph Brandt; Nicholas Noto; Tipper Truong; Mariah Arevalo
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-02-01
Filing date: 2019-10-03
Publication date: 2021-11-04
Also published as: CN113366424B; US20210342264A1; IE87486B1; GB2594888A; US20200250083A1; GB202110968D0; WO2020159585A1; IE20190232A1; GB2594888B; CN113366424A; US11068390B2

Abstract

Systeme und Verfahren zum Bereinigen eines Speichersystems. Ein dedupliziertes Speichersystem wird durch Identifizieren von Strukturen bereinigt, die tote Segmente und unreferenzierte Segmente beinhalten. Dies beinhaltet das Verarbeiten von Rezepten, um die Segmente zu identifizieren, die nicht mehr länger Teil eines aktiven Objekt-Rezepts sind. Danach werden die toten Segmente entfernt. Dies wird durch Vorkopieren der aktiven Segmente und danach Löschen als Ganzes der Struktur, die die toten Segmente beinhaltete, umgesetzt.

Description

GEBIET DER ERFINDUNG
Ausführungsformen der Erfindung beziehen sich auf Systeme, Vorrichtungen und Verfahren zum Durchführen von Datenschutzoperationen wie der Datenbereinigung (Garbage Collection). Insbesondere beziehen sich Ausführungsformen der Erfindung auf Systeme und Verfahren zur Datenbereinigung in einem deduplizierten Speichersystem wie einem deduplizierten cloudbasierten Speichersystem.
HINTERGRUND
Der Schutz von Daten ist ein grundlegender Aspekt heutiger Computertechnologien. Werden Daten nicht geschützt, so ist es wahrscheinlicher, dass die Daten verloren gehen, und der Verlust von Daten kann in einem beträchtlichen Schaden an einer Entität resultieren. Folglich speichern viele Entitäten ihre Daten oder Backups von Daten in einem Speichersystem wie einem cloudbasierten Speichersystem. Der Schutz von Daten ist aber wegen der damit zusammenhängenden Kosten und Strategien, die auf Daten angelegt werden oder damit assoziiert sind, wesentlich komplexer als einfach eine Kopie von Daten in der Cloud zu speichern. So sind Backups z.B. oftmals Backup-Strategien (z.B. tägliche, wöchentliche, monatliche Erzeugung von Backups) und Retentionsstrategien unterworfen. Dies resultiert in einer wesentlichen Menge an Daten, die in Hinblick sowohl auf Speicheranforderungen als auch Rechenanforderungen, selbst wenn die Daten dedupliziert sind, entsprechende Kosten haben.
Aus verschiedenen Gründen werden Backups im Allgemeinen mit der Zeit gelöscht. So kann ein System z.B. ein Backup löschen, wenn eine Retentionsdauer ausläuft. Das Löschen eines Backups ist keine triviale Aufgabe, insbesondere in deduplizierten Speichersystemen. In deduplizierten Systemen werden Daten oftmals in Chunks oder Segmente geteilt und in einer deduplizierten Form gespeichert. Dies reduziert Speicheranforderungen (und Kosten), indem dieselben Chunks oder Segmente auch für mehrere Backups oder mehrere Objekte verwendet werden.
Unweigerlich sind einige der Daten oder Objekte, die in dem Datenschutzsystem gespeichert werden, tot. Tote Objekte oder Daten sind nicht referenziert und werden vom Client oder dem Speichersystem nicht mehr länger benötigt. Wenn Backups auslaufen oder aus anderen Grünen führen Backup-Systeme Datenbereinigungsoperationen durch, um Objekte, die beliebige der gültigen Backups nicht mehr referenzieren, zu löschen oder zu entfernen. Dies kann aber nicht einfach durch Löschen der Segmente eines toten Objekts erzielt werden, weil genau diese Segmente einem aktiven Objekt entsprechen können. Ferner sind herkömmliche Ansätze wie Referenzzählungen unhandlich, weil sie erfordern, dass das Schutzsystem Milliarden von Zählungen hält. Referenzzählungen brauchen somit signifikanten Speicher, und sie sind sehr schwierig zu verwalten, insbesondere in verteilten und cloudbasierten Systemen.
Figurenliste
Um die Art und Weise zu beschreiben, in welcher zumindest einige Aspekte dieser Offenbarung erhalten werden können, ist eine genauere Beschreibung durch Verweis auf spezifische Ausführungsformen davon gegeben, die in den angehängten Zeichnungen veranschaulicht sind. Geht man davon aus, dass diese Zeichnungen nur beispielhafte Ausführungsformen der Erfindung darstellen und somit nicht als deren Umfang einschränkend anzusehen sind, sind die Ausführungsformen der Erfindung mit zusätzlicher Spezifizität und Detail durch die Verwendung der begleitenden Zeichnungen beschrieben und erklärt, in welchen:

1A ein Beispiel für eine Art und Weise, um deduplizierte Daten in einem Speichersystem wie einem cloudbasierten Speichersystem zu speichern, veranschaulicht;
1B ein Beispiel für gespeicherte Daten vor der Bereinigung und nach der Bereinigung in einem Speichersystem wie einem cloudbasierten Speichersystem veranschaulicht;
1C ein Beispiel für ein Schutzsystem veranschaulicht, das ausgelegt ist, um Datenschutzoperationen durchzuführen, einschließlich Datenbereinigung in einem Speichersystem wie einem cloudbasierten Speichersystem;
2 ein Beispiel für einen Objektspeicher-Bucket und einen Lösch-Bucket veranschaulicht, der von einem Schutzsystem verwendet wird, um den Objektspeicher zu bereinigen;
3 einen Prozess zum Bewegen eines Objekts vom Objektspeicher-Bucket zum Lösch-Bucket in Vorbereitung zur Durchführung der Datenbereinigungsoperationen veranschaulicht;
4 ein Beispiel für ein Verfahren zum Durchführen einer Datenschutzoperation wie Datenbereinigung veranschaulicht;
5 ein Beispiel für eine Startup-Phase einer Datenbereinigungsoperation veranschaulicht, in welcher die Worker und Worker-Kapazitäten ermittelt werden;
6 ein Beispiel für ein Verfahren zum Ermitteln einer Anzahl von Workern basierend auf den Ähnlichkeitsgruppen veranschaulicht, die von dem Datenbereinigungsprozess betroffen sind;
7 ein Beispiel für Faktoren veranschaulicht, die berücksichtigt werden können, wenn die Anzahl an Workern ermittelt wird, die für einen Datenbereinigungsprozess erforderlich sind;
die 8A und 8B Beispiele für die Verarbeitung von Ähnlichkeitsgruppen veranschaulichen, die das Markieren von betroffenen Ähnlichkeitsgruppen beinhaltet, während ein Datenbereinigungsprozess durchgeführt wird;
9 ein Beispiel für Ähnlichkeitsgruppen und assoziierte Teilgruppen veranschaulicht, die denselben Identifikator wie die Ähnlichkeitsgruppen haben; und
10 ein Beispiel für das Markieren von aktiven Segmenten in Vorbereitung für eine Vorkopierphase des Datenbereinigungsprozesses veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Ausführungsformen der Erfindung beziehen sich auf Systeme, Vorrichtungen und Verfahren zum Bereitstellen oder Durchführen von Datenschutzoperationen. Beispielhafte Datenschutzoperationen beinhalten, sind aber nicht darauf beschränkt, Backup-Operationen, Wiederherstellungsoperationen, Deduplikationsoperationen, Replikationsoperationen und/oder Datenbereinigungsoperationen. Eine Datenbereinigungsoperation wird beispielsweise durchgeführt, um ein Speichersystem von toten Objekten oder von unreferenzierten Objekten zu bereinigen. Anders gesagt: Eine Datenbereinigungsoperation wird durchgeführt, um Objekte aus einem Speichersystem zu entfernen, die nicht mehr länger von einem Client benötigt werden oder nicht mehr länger von einem aktiven Objekts referenziert werden oder Teil davon sind.
Das Löschen eines Objekts ist in einem deduplizierten Speichersystem kompliziert, weil mit einem gelöschten Objekte assoziierte Segmente nicht unmittelbar aus dem Speichersystem entfernt werden können, weil einige Segmente des gelöschten Objekts mit anderen aktiven Objekten assoziiert sein können. Ohne Einschränkung kann ein aktives Objekt ein Objekt sein, das in dem Speichersystem gehalten werden sollte. Ein totes Objekt ist ein Objekt, das verworfen oder aus dem Speicher entfernt werden kann. Ein Objekt kann Daten, Dateien, Datensätze wie Backup-Datensätze, Einzeldateien oder dergleichen oder Kombinationen davon darstellen. Die hierin besprochenen Datenschutzoperationen können in einem System wie DELL EMC Data Domain, einschließlich Cloudimplementierungen, durchgeführt werden.
Ausführungsformen der Erfindung beziehen sich auf Datenbereinigungsoperationen, die Datenintegrität sicherstellen, die, wenn sie durchgeführt werden, keine Kosten ansammeln lassen, und die skalierbar sind, um die Leistung- und/oder zeitlichen Vorgaben zu erfüllen. Zusätzlich dazu unterstützen Ausführungsformen der Erfindung gleichzeitiges Lesen / Schreiben, während die Datenbereinigung durchgeführt wird. Ausführungsformen der Erfindung vereinfachen ferner Schwierigkeiten, die mit Aktivitäten von Coding und Debugging assoziiert sind.
In einem Beispiel kann ein cloudbasiertes Datenschutzsystem (Schutzsystem) als ein Mikrodienst oder eine containerbasierte Anwendung implementiert und dazu ausgelegt sein, in einer Cloudumgebung zu arbeiten. Genauer gesagt kann die Datenbereinigung als ein Mikrodienst implementiert sein, der ein Speichersystem von Objekten bereinigt, die von Clients gelöscht werden oder entsprechend Retentionsstrategien gelöscht werden, indem unreferenzierte Segmente (oder andere Datendarstellungen oder -strukturen) aus dem Speichersystem entfernt werden, ohne aktive Segmente zu betreffen. Das Schutzsystem kann in Containern laufen gelassen werden, und das Schutzsystem kann je nach Bedarf hinauf- oder hinabskaliert werden. Komponenten des Schutzsystems können als Mikrodienste implementiert sein.
Ausführungsformen der Erfindung verbessern den Betrieb eines Datenschutzsystems, einschließlich Operationen, die von dem Datenschutzsystem durchgeführt werden, indem sichergestellt wird, dass unreferenzierte Daten nicht unnötig Speicher verbrauchen, und indem sichergestellt wird, dass die unreferenzierten Daten nicht unnötig Rechenressourcen verbrauchen. Genauer gesagt wird durch die Entfernung toter Objekte das Datenschutzsystem nicht damit belastet, dass es Daten verarbeiten muss, die nicht referenziert sind. Dies eliminiert etwas Verarbeitung und verbessert somit den Betrieb des Datenschutzsystems. Dazu basieren die Kosten von Speicherung wie etwa einer cloudbasierten Speicherung oftmals auf der Menge an gespeicherten Daten. Indem Datenbereinigung durchgeführt wird, können tote Objekte oder Segmente entfernt werden.
In einigen Cloudsystemen sind auch Kosten für den Verbrauch von Rechenressourcen gegeben. Ausführungsformen der Erfindung konservieren Rechenressourcen zumindest, weil die für die Datenbereinigungsoperation verwendeten Rechenressourcen nur zugeteilt und verwendet werden, während die Datenbereinigungsoperation ausgeführt wird. Die Rechenressourcen können freigegeben werden, wenn die Datenbereinigungsoperation nicht abläuft.
In einem Beispiel kann das Schutzsystem Objekte deduplizieren, indem es die Objekte in Slices und Segmente teilt oder in Chunks aufteilt (sehr große Objekte können in Teile geteilt werden, die in Slices geteilt werden, die in Segmente geteilt werden).
1A veranschaulicht ein Beispiel dafür, wie Objekte in einem cloudbasierten Speichersystem gespeichert werden können. 1A veranschaulicht einen Objektspeicher 48, der ein Objektspeicher-Bucket sein kann. Der Speicher kann auch auf andere Weisen dargestellt oder konfiguriert sein. Die tatsächlichen Daten (die Segmente) eines mit einem Objektrezept 50 assoziierten Objekts werden in Kompressionsregionen wie den Kompressionsregionen 60, 66, 68 und/oder 70 gespeichert. Somit können Segmente eines mit dem Objektrezept 50 assoziierten Objekts in einer oder mehreren der Kompressionsregionen 60, 66, 68 und 70 gespeichert werden.
Die Kompressionsregion 60 kann Segmente 64 und Fingerabdrücke 62 dieser Segmente 64 beinhalten. Die anderen Kompressionsregionen 66, 68 und 70 sind ähnlich konfiguriert. In diesem Beispiel ist die Ähnlichkeitsgruppe 56 mit mehreren Kompressionsregionen, einschließlich der Kompressionsregionen 60 und 66, assoziiert. Ebenso ist die Ähnlichkeitsgruppe 58 mit den Kompressionsregionen 68 und 70 assoziiert.
Die Ähnlichkeitsgruppe 56 kann eine oder mehrere Teilgruppen, die als Teilgruppen 56-1 bis Teilgruppen 56-n veranschaulicht sind, aufweisen oder damit assoziiert sein. Wie veranschaulicht ist, beinhaltet die Ähnlichkeitsgruppe 58 ebenso Teilgruppen 58-1 bis 58-n. In diesem Beispiel sind die Ähnlichkeitsgruppe 56 und die Teilgruppe 56-1 als ein Objekt gespeichert. Die anderen Teilgruppen sind ebenso gespeichert. Jede Teilgruppe kann denselben Ähnlichkeitsgruppen-Identifikator (ID) wie die entsprechende Ähnlichkeitsgruppe aufweisen, und die Teilgruppen können verschieden nummeriert sein (z.B. in aufsteigender Reihenfolge). Die Ähnlichkeitsgruppe 56 identifiziert die Kompressionsregionsnamen und assoziierten Fingerabdrücke, die mit einem Objekt assoziiert sind. Genauer gesagt können die Kompressionsregionen mit spezifischen Teilgruppen assoziiert sein. Das Slice-Rezept 52 identifiziert die Ähnlichkeitsgruppe und Teilgruppe für ein Slice eines assoziierten Objekts. In einem Beispiel ist jedes Slice mit einer einzelnen Ähnlichkeitsgruppe assoziiert. Das Objektrezept 50 identifiziert die Slices eines Objekts.
In einem Beispiel beinhaltete die Ähnlichkeitsgruppe 56 eine Teilgruppe. Anders gesagt: Ein Objekt ist mit einer Ähnlichkeitsgruppe und einer Teilgruppe assoziiert. Als ein Beispiel dafür kann eine Ähnlichkeitsgruppe als ein Objekt mit einem Gruppen-ID und einem Teilgruppen-ID aber niemals ohne den Teilgruppen-ID gespeichert werden. 1A veranschaulicht, dass die Ähnlichkeitsgruppe 56 und die assoziierten Teilgruppen als separate Objekte gespeichert werden können. Die Rezepte der Objekte identifizieren aber für gewöhnlich jede einer Ähnlichkeitsgruppe, einer Teilgruppe und Kompressionsregionen.
1A veranschaulicht im Wesentlichen ein einzelnes Objekt und dass das Objekt in zwei Slices geteilt wurde. In diesem Beispiel hat jedes Slice etwa 8 MB. Das Objektrezept 50 identifiziert alle Slices des Objekts. Somit wird das Objektrezept 50 generiert, wenn ein assoziiertes Objekt in ein Speichersystem gespeichert wird, und dazu verwendet, das Objekt wieder zusammenzusetzen, wenn das Objekt aus dem Speichersystem ausgelesen wird. Der Objektspeicher 48 kann auf diese Weise eine Vielzahl von Objekten beinhalten. Ferner können das Objektrezept 50, die Slice-Rezepte 52, 54, die Ähnlichkeitsgruppen 56, 58 und die Kompressionsregionen alle unabhängige Objekte im Objektspeicher 48 sein. In diesem Beispiel identifiziert das Slice-Rezept 52 für das Objekt die Ähnlichkeitsgruppe 56:Teilgruppe 56-1, und das Slice-Rezept 54 identifiziert die Ähnlichkeitsgruppe 58:Teilgruppe 58-n. Jede Teilgruppe kann mit mehreren Kompressionsregionen assoziiert sein oder diese identifizieren (z.B. die Segmente 3, 4 und 5 in der Kompressionsregion 60 und die Segmente 1 und 2 in der Kompressionsregion 66 (abhängig vom Rezept)).
Während der Deduplikation kann ein Objekt in Slices geteilt werden, und die Slices können weiter in Segmente geteilt oder Chunks unterteilt werden. Die Größen der Slices und Chunks können konfiguriert werden. So kann z.B. ein Objekt in 8 MB-Slices geteilt werden. Jedes der Slices kann in 8 KB-Segmente geteilt werden. Um Deduplikation durchzuführen, wird jedes Slice einer Ähnlichkeitsgruppe zugeordnet (Mapping). Die Ähnlichkeitsgruppe kann basierend auf dem Inhalt des Slice oder basierend auf einer Funktion, die auf den Inhalt des Slice angewendet wird, bestimmt werden. Weil ein Slice einer Ähnlichkeitsgruppe zugeordnet wird, können die Segmente oder der Inhalt des Slice, das dedupliziert wird, bereits in der Ähnlichkeitsgruppe vorhanden sein. Nur beispielhaft kann ein Slice nur in Bezug auf die Ähnlichkeitsgruppe und in Bezug auf eine bestimmte Teilgruppe der Ähnlichkeitsgruppe dedupliziert werden.
So kann ein Objektrezept z.B. ein Slice identifizieren. Das Slice-Rezept kann die Ähnlichkeitsgruppe und die Teilgruppe identifizieren. Die Kompressionsregionen sind in der identifizierten Ähnlichkeitsgruppe und Teilgruppe beinhaltet oder damit assoziiert.
Während der Deduplikation können eindeutige Fingerabdrücke in Kompressionsregion der Teilgruppe 1 angehängt werden. Sobald die Teilgruppe 1 eine Schwellengrenze erreicht hat, wird eine Teilgruppe 2 erzeugt. Neue Fingerabdrücke und Kompressionsregionen für die Ähnlichkeitsgruppe werden dann zur Teilgruppe 2 hinzugefügt, weil die Teilgruppe 1 voll ist. Zusätzliche Teilgruppen werden je nach Bedarf hinzugefügt.
Im Allgemeinen wird die Deduplikation durch Vergleich von Fingerabdrücken von Segmenten, die in den Speicher zu schreiben sind, mit den Fingerabdrücken von Segmenten durchgeführt, die bereits durch das Schutzsystem gespeichert wurden. Ein Fingerabdruck ist ein Identifikator eines Segments (d.h. ein Hash des Segments) und kann in Systemen implementiert werden, in welchen die Daten klar oder verschlüsselt sind.
Im Kontext einer Ähnlichkeitsgruppe werden Fingerabdrücke der Segmente aus einem hereinkommenden Slice als Duplikate markiert, wenn die Fingerabdrücke der hereinkommenden Segmente zu beliebigen der Fingerabdrücke der Segmente passen, die bereits in der Ähnlichkeitsgruppe gespeichert sind. Passen die Fingerabdrücke der Segmente von dem hereinkommenden Slice nicht zu einem beliebigen der bestehenden Fingerabdrücke für die Ähnlichkeitsgruppe, so werden diese Segmente dann als neu angesehen und in der Ähnlichkeitsgruppe gespeichert.
1B veranschaulicht das Resultat einer Datenbereinigungsoperation. Während der Datenbereinigung kann bestimmt werden, dass ein gelöschtes Objekt Segmente 82, 84 und 86 beinhaltet und dass diese Segmente in der Kompressionsregion 89 beinhaltet sind. Es kann auch bestimmt werden, dass die Segmente 82 und die Segmente 86 mit einem anderen aktiven Objekt assoziiert sind. Somit sind die Segmente 82 und 86 aktive Segmente, während das Segment 84 tot und von einem anderen Rezept unreferenziert ist. Nachdem die aktiven und toten Segmente identifiziert wurden, wird die Kompressionsregion 90 nur durch Schreiben (z.B. Vorkopieren) der aktiven Segmente in die neue Kompressionsregion 88 bereinigt. Die Kompressionsregion 80 kann dann gelöscht werden. Somit wird eine mit der Kompressionsregion 80 assoziierte Ähnlichkeitsgruppe von toten Segmenten bereinigt, und die neue Kompressionsregion 88 enthält nur die Segmente der Kompressionsregion 80, die mit aktiven Objekten assoziiert waren. In einigen Objektspeichersystemen kann es sein, dass es nicht möglich ist, ein bestehendes Objekt zu modifizieren, so dass die Kompressionsregion 80 nicht direkt geändert werden kann. Stattdessen wird eine neue Kompressionsregion 88 während der Datenbereinigung mit den aktiven Segmenten erzeugt. Die neue Kompressionsregion 88 könnte denselben Namen wie die Kompressionsregion 80 haben, in welchem Fall die Kompressionsregion 80 nicht gelöscht werden müsste, weil sie ersetzt wird. In einem Beispiel werden eindeutige Namen für die Kompressionsregionen auf der Grundlage ihres Inhalts generiert.
In einem Beispiel kann ein Metadaten-Server verwendet werden, um die Ähnlichkeitsgruppen zu verwalten oder um die Fingerabdrücke im Allgemeinen zu verwalten. Der Metadaten-Server kann z.B. Beziehungen zwischen Fingerabdrücken, Segmenten und/oder Ähnlichkeitsgruppen speichern. Der Metadaten-Server kann alle Fingerabdrücke aller Segmente speichern, die durch das Schutzsystem verwaltet werden. Während der Deduplikation und/oder der Datenbereinigung kann der Metadaten-Server abgefragt werden zu bestimmen, ob ein Segment oder eine Gruppe von Segmenten einmalig ist oder Duplikate oder aktiv. Wenn z.B. ein Slice zu einer Ähnlichkeitsgruppe hinzugefügt wird, kann eine Abfrage an den Metadaten-Server gestellt werden, wobei die Fingerabdrücke der Segmente in dem Slice, das hinzugefügt wurde, verwendet werden, um zu bestimmen, ob beliebige der Segmente Duplikate sind. Einmalige Segmente werden zu der Ähnlichkeitsgruppe hinzugefügt und Duplikatsegmente werden notiert. Oftmals wird Deduplikation nur in Bezug auf Fingerabdrücke durchgeführt, die mit der Ähnlichkeitsgruppe und einer spezifischen Teilgruppe der Ähnlichkeitsgruppe assoziiert sind.
1C veranschaulicht ein Beispiel für eine Rechenumgebung oder ein Schutzsystem, die/das Datenschutzoperationen, einschließlich Datenbereinigung, durchführt. 1C veranschaulicht ein Schutzsystem 100 (oder ein Beispiel für ein dedupliziertes Objektspeichersystem) und einen Objektspeicher 120. Das Schutzsystem 100 kann eine containerisierte Implementierung eines Datenschutzsystems sein und kann Mikrodienste beinhalten. In einem Beispiel kann das Schutzsystem 100 in einer Kubernetes-Umgebung implementiert sein. Der Objektspeicher 120 kann ein cloudbasiertes Speichersystem sein, so etwa eines, das in einem Datenzentrum gehostet ist. Der Objektspeicher 120 kann in einer Umgebung vor Ort innerhalb einer privaten Cloud gegeben sein. Das System 100 und/oder der Objektspeicher 120 können in ihrer Natur verteilt sein, und sie können skalierbar sein.
Der Objektspeicher 120 ist dazu ausgelegt, Objekte oder Daten zu speichern. Das System 100 ist dazu ausgelegt, das Objekt oder die Daten in einer deduplizierten Form zu speichern, wenngleich eine Deduplikation in einigen Fällen nicht 100% sein kann. Objekte können in dem Objektspeicher 120 wie zuvor beschrieben gespeichert sein. Somit kann der Objektspeicher 120 ein Objektrezept 122 beinhalten, das mit einem Slice-Rezept 124, einer Ähnlichkeitsgruppe 128 (und Teilgruppe) und Kompressionsregionen 126 assoziiert ist.
Das Schutzsystem 100 kann Kundenzugriff-Server 102 beinhalten. Kundenzugriff-Server 102 können ein Front-End 104 und ein Back-End 106 beinhalten. Das Front-End 104 und das Back-End 106 können Mikrodienste sein, die unter Verwendung von zugeteilten Rechenressourcen (Prozessoren, Speicher und andere erforderlich Hardware-Komponenten) laufengelassen werden. Das Front-End 104 kann den Kunden eine Schnittstelle bereitstellen. Objekte können durch das Front-End 104 empfangen werden. Unter Verwendung des Front-Ends 104 kann ein Nutzer oder Client in der Lage sein, Objekte zu betrachten, Objekte hinzuzufügen, Objekte zu löschen, Datenschutzoperationen wie Backup-Operationen und Wiederherstellungsoperationen zu konfigurieren oder dergleichen oder eine Kombination davon. In einigen Beispielen kann das Schutzsystem 100 ein logisches Konstrukt zwischen den Clients und den tatsächlichen Daten anordnen.
Das Front-End 104 kann auch für die Teilung eines Objekts in Slices verantwortlich sein. Das Back-End 106 kann dazu ausgelegt sein, verschiedene Operationen an Daten oder Objekten durchzuführen. Sobald ein Objekt in Slices geteilt wurde (was auch durch das Back-End 106 durchgeführt werden kann), kann das Back-End 106 dafür verantwortlich sein, Hashes zu berechnen und ein Objektrezept, Slice-Rezept und dergleichen zu bilden, die in dem Objektspeicher 120 gespeichert werden können. Das Back-End 106 kann auf den Metadaten-Server 108 zugreifen, um Ähnlichkeitsgruppen für die Slices zu identifizieren. Das Back-End 106 kann die Objektrezepte generieren oder bestimmen und mit dem Metadaten-Server 108 kommunizieren.
Im Kontext von Datenbereinigung kann Datenbereinigung als eine Aufgabe konfiguriert sein, die periodisch oder entsprechend einem Zeitplan abläuft. Ist die Datenbereinigung abgeschlossen, können die Ressourcen, die zum Durchführen der Datenbereinigung verwendet werden, freigegeben werden. Dies erlaubt, dass Ressourcen nur akquiriert werden, wenn sie benötigt werden, und freigegeben, wenn sie nicht benötigt werden. Dies reduziert in vorteilhafter Weise Kosten im Vergleich zu Lösungen, die Rechenressourcen nicht freigeben.
Übersicht Datenbereinigung
Datenbereinigung wird von einer Steuerung 110 (z.B. einem Server oder einem Knoten in der Rechenumgebung) gelenkt oder gesteuert. Die Steuerung 110 kann einen oder mehrere Knoten wie Worker 112 und Worker 114 steuern, um die Datenbereinigung durchzuführen.
Das Datenschutzsystem 100 führt die Datenbereinigung durch, indem sie unreferenzierte oder tote Segmente aus dem Objektspeicher 120 entfernt oder löscht. Obwohl auf Segmente eine Referenz hergestellt wird, versteht sich, dass Ausführungsformen der Erfindung auch mit anderen Datendarstellungen arbeiten können.
Indem Segmente aus dem Objektspeicher 120 entfernt werden, werden Speicherkosten und Rechenkosten vorteilhaft reduziert. Ausführungsformen der Erfindung können auch zu der Tatsache beisteuern, dass in einem Cloudspeichersystem das Schutzsystem 100 nicht mehr Speicher zur Verfügung hat. Dies ermöglicht Datenbereinigungsoperationen etwas Spielraum, wenn Daten bereinigt werden, und es ermöglicht dem Schutzsystem 100, auf Objekte zu warten, die teilweise aktiv sind (z.B. mit einigen Segmenten assoziiert sind, die mit einem anderen Objekt assoziiert sind). Ferner können die Rechenkosten, die typischerweise höher als Speicherkosten sind, niedrig gehalten werden oder reduziert werden, indem teilweise aktive Objekte über eine gewisse Zeitspanne hinweg weiter gespeichert werden. So kann z.B. eine Kompressionsregion aktive und tote Segmente beinhalten. Ist die Anzahl an toten Segment gering, dann kann es günstig sein zu warten, bis der Prozentanteil an toten Segmenten eine Schwelle überschreitet, bevor die Kompressionsregion bereinigt wird.
Ausführungsformen der Erfindung teilen auch Rechenressourcen (z.B. Worker-Knoten) basierend auf der Menge an Arbeit, die durchzuführen ist, und basierend auf den Ressourcen, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen, und/oder basierend auf Beschränkungen wie etwa Speicherbeschränkungen, IO-Beschränkungen, Durchsatzbeschränkungen oder dergleichen zu.
In einem Beispiel werden Lösch-Buckets verwendet, um Datenbereinigung durchzuführen. Ein Lösch-Bucket speichert Aufzeichnungen, die Objekten entsprechen, die gelöscht wurden oder die niemals komplettiert wurden (z.B. teilweise geschrieben). Wird der Datenbereinigungsprozess durchgeführt, werden die Aufzeichnungen in dem Lösch-Bucket verarbeitet.
Die folgende Erläuterung bezieht sich auf Buckets. Ein Bucket ist eine allgemeine Darstellung mindestens eines Teils eines Speichersystems. Objekte können in einem Objektspeicher-Bucket gespeichert werden. Wird ein von einem Client geschriebenes Objekt gelöscht, oder wenn ein Objekt aus einem anderen Grund gelöscht wird, wird eine Löschaufzeichnung für das gelöschte Objekt einem Lösch-Bucket hinzugefügt. Eine Löschaufzeichnung kann das vom Client geschriebene Objekt in einer Weise identifizieren, so etwa durch das Rezept des Objekts. In einem Beispiel kann die Löschaufzeichnung nur den Namen des Objekts beinhalten (der Name kann ausreichend sein, um das Rezept zu identifizieren). Somit kann die Löschaufzeichnung einige Informationen über das Objekt beinhalten. Dies erlaubt, dass die relevanten Segmente während der Datenbereinigungsoperation identifiziert werden können. Das Rezept kann die Ähnlichkeitsgruppen und die Kompressionsregionen, die mit dem Objekt assoziiert sind, identifizieren. Die Menge oder Art an Daten, die in der Löschaufzeichnung gespeichert werden, kann somit variieren. Unter Verwendung der Löschaufzeichnungen sind die Steuerung 110 und die Worker 112, 114 in der Lage, alle betroffenen Ähnlichkeitsgruppen (jene, die tote Segmente beinhalten können) unter Verwendung der Löschaufzeichnungen zu identifizieren und den Objektspeicher 120 zu bereinigen.
Die betroffenen Ähnlichkeitsgruppen (oder spezifischen Teilgruppen) können schreibgesperrt werden, so dass hereinkommende Objekte nicht die Ähnlichkeitsgruppen / Teilgruppen, die bereinigt werden, betreffen können. Um sicherzustellen, dass der Schreibzugriff während einer Datenbereinigungsoperation beibehalten wird, können neue Teilgruppen zu den betroffenen Ähnlichkeitsgruppen nach Bedarf hinzugefügt werden. Alle Objekte, die während einer Datenbereinigungsoperation in den Objektspeicher 120 geschrieben werden, können in Bezug auf die neuen und/oder nicht betroffenen Ähnlichkeitsgruppen oder in Bezug auf Ähnlichkeitsgruppen oder Teilgruppen, die nicht schreibgesperrt sind, dedupliziert werden.
In einem Beispiel wird die Arbeitslast des Datenbereinigungsprozesses in Abschnitte (oftmals auf Basis einer Ähnlichkeitsgruppe) geteilt und den Workern zugewiesen. Nach der Identifikation, welche der Ähnlichkeitsgruppen und Teilgruppen von dem Datenbereinigungsprozess betroffen sind, können die Steuerung 110 und/oder die Worker 112, 114 aktive Fingerabdrücke in ihren jeweiligen Ähnlichkeitsgruppen identifizieren und markieren. So kann z.B. ein Objekt, das gelöscht wurde, aus Segmenten 1, 2, 3, 4 und 5 bestehen. Ein anderes Objekt, das nicht gelöscht wurde, kann die Segmente 1, 2, 3, 6 und 7 beinhalten. In diesem Fall können die Fingerabdrücke (oder Identifikatoren wie ein Hash) von Segmenten 1, 2, 3, 6 und 7 als aktiv markiert werden. Die Segmente 4 und 5 werden gelöscht.
Aktive Segmente in der Ähnlichkeitsgruppe / Teilgruppe (und insbesondere in einer Kompressionsregion) werden dann vor in neue Kompressionsregionen getragen. Wenn z.B. eine Kompressionsregion die Segmente 1, 2, 3, 4 und 5 beinhaltet, würde die neue Kompressionsregion die Segmente 1, 2 und 3 beinhalten. Die alte Kompressionsregion, die die Segmente 4 und 5 beinhaltete, wird entfernt oder gelöscht. Somit werden die nicht verwendeten oder unreferenzierten Segmente 4 und 5 aus dem Objektspeicher 120 bereinigt. Die Schreibsperre kann daraufhin freigegeben werden.
Datenbereinigung
Die 2-4 veranschaulichen Aspekte einer Datenbereinigungsoperation und ein Schutzsystem, das Datenbereinigung durchführt. In der folgenden Erläuterung wird der Begriff Bucket in der Beschreibung verwendet, wie Objekte und Aufzeichnungen gespeichert werden. Die Objekte und Aufzeichnungen können aber auch in anderen Strukturen wie Containern, einer Datenbank oder dergleichen gespeichert werden. Im Objektspeicher können Clients ihre Objekte innerhalb von Strukturen organisieren, die als Buckets bezeichnet werden. Buckets können erzeugt und gelöscht werden, und Objekte in einem Bucket können basierend auf einem (möglicherweise leeren) String mit Vorzeichen oder auf eine andere Weise gelistet werden. In einem Beispiel kann eine Indirektionsschicht wie ein logischer Bucket 262 zwischen Clients 260 und dem Bucket 230 implementiert sein. Die Clients 260 können mit dem logischen Bucket 262 interagieren. String-Manipulationen können auf den verschiedenen Bucket-Namen durchgeführt werden, bevor der darunterliegende Objektspeicher-Bucket 230 abgefragt wird.
In der 2 und beispielhaft kann das Speichersystem einen Objektspeicher-Bucket 230 (oder mehrere Buckets) und einen Lösch-Bucket 220 beinhalten. Während der Datenbereinigungsoperation kann eine Steuerung 210 (die Steuerung kann basierend auf einem Plan oder nach Bedarf instanziiert werden) einen oder mehrere Worker (z.B. den Worker 212 und den Worker 214) erzeugen und einen Teil der durchzuführenden Arbeit jedem der Worker 212, 214 zuweisen. In einem Beispiel kann jedem Worker ein Bereich von Ähnlichkeitsgruppen zugewiesen werden. In einem Beispiel können die Steuerung 210 und die Worker 212 und 214 als Pods implementiert sein.
Die Steuerung 210 (und/oder die Worker) kann/können bestimmen, welche Ähnlichkeitsgruppen von der Datenbereinigungsoperation betroffen sind. Diese Bestimmung basiert z.B. auf Aufzeichnungen, die in dem Lösch-Bucket 250 beinhaltet sind. Wie zuvor erläutert wurde, kann es unpraktisch sein, alle der mit einem Objekt assoziierten Segmente zu dem Zeitpunkt zu reinigen, zu welchem ein Client das Objekt aufgrund von Deduplikation löscht. Stattdessen konzentriert sich die Datenbereinigungsoperation auf die von den gelöschten Objekten referenzierten Strukturen. Löscht ein Client ein Objekt aus dem Objektspeicher 230 oder wird ein Objekt aus einem anderen Grund gelöscht, so kann das Objektrezept des Objekts entfernt werden (z.B. zum Lösch-Bucket 220 bewegt werden) und kann für den Client nicht mehr sichtbar sein.
In diesem Beispiel beinhaltet der Objektspeicher-Bucket 230 ein Objekt X und ein Objekt Y. Das Objekt X hat ein Objektrezept 232. Der Einfachheit halber wird ein einzelnes Slice für jedes der Objekte X (Slice 246) und Y (Slice 248) angenommen. Das Slice 246 von Objekt X ist mit einer Ähnlichkeitsgruppe 234 (insbesondere der Ähnlichkeitsgruppe A, Teilgruppe 1) assoziiert. Die Segmente des Objekts X werden physisch in Kompressionsregionen 236 (insbesondere Kompressionsregionen 3 und 4) gespeichert. Ebenso weist das Objekt Y ein Objektrezept 240 auf und ist mit einer Ähnlichkeitsgruppe 242 (insbesondere der Ähnlichkeitsgruppe A, Teilgruppe 1) und Kompressionsregionen 244 (Kompressionsregionen 3 und 4) assoziiert. Dies zeigt, dass Kompressionsregionen und Ähnlichkeitsgruppen durch mehrere Objektrezepte referenziert werden können, um eine Deduplikation zu erreichen.
Ein Client kann das Objekt X löschen. Wird das Objekt X von einem Client oder entsprechend einer Retentionsstrategie oder aus einem anderen Grund gelöscht, so wird das Objektrezept 232 aus dem Objektspeicher-Bucket 230 entfernt und kann in dem Lösch-Bucket 250 gespeichert werden.
3 veranschaulicht diesen Prozess und zeigt, dass eine Löschaufzeichnung 252, die dem mit dem Objektrezept 232 assoziierten Objekt entspricht, in dem Lösch-Bucket 250 angeordnet wurde. Die Löschaufzeichnung 252 kann Daten 254 und/oder einen Zeitstempel 258 beinhalten. In einem Beispiel entsprechen die Daten 254 dem Objektrezept 232. Als ein Resultat davon ist das Objekt X nicht mehr länger für den Client 260 sichtbar. Der Name des Objekts X kann in dem Lösch-Bucket 250 als die Daten 254 gespeichert werden, anstatt das Objektrezept 232 zu kopieren. Diese Information (z.B. Objektrezept 232, Objektname etc.) ist ein Beispiel für eine Löschaufzeichnung 252. Der Lösch-Bucket 250 wird dann während des Datenbereinigungsprozesses verwendet, um den Objektspeicher-Bucket 230 zu bereinigen.
Zusätzlich zu Objekten, die explizit von Clients gelöscht oder aufgrund von Strategien wie Retentionsstrategien gelöscht wurden, können Ausführungsformen der Erfindung auch Objekte bereinigen oder löschen, die teilweise geschrieben sind oder die vor der Komplettierung abgelegt wurden. Ein teilweise geschriebenes Objekt kann für den Client nicht sichtbar sein, und als ein Resultat davon löscht der Client dieses Objekt nicht. Es ist aber nützlich, den Raum, der von diesen Arten von Objekten eingenommen wird, frei zu machen.
In einem Beispiel entspricht der Lösch-Bucket 252 einem Schreibvorgang in Bearbeitung. Somit wird die Löschaufzeichnung 252 in den Lösch-Bucket 250 für bearbeiteten Schreibvorgang in Bearbeitung eingegeben. Die Löschaufzeichnung 252 wird aus dem Lösch-Bucket 250 entfernt, wenn der Schreibvorgang abgeschlossen ist. Während der Schreibvorgang erfolgt, kann ein in der Löschaufzeichnung 252 beinhalteter Zeitstempel 258 aktualisiert werden. Insbesondere stellt der Zeitstempel 258 einen Modifikationszeitstempel dar, der identifiziert, wann das Objekt in Bearbeitung zuletzt aktualisiert wurde. Der Zeitstempel 258 kann in Intervallen aktualisiert werden, während das Objekt geschrieben wird, so etwa alle zehn Minuten.
Wird eine Datenbereinigung durchgeführt, so werden Objekte in Bearbeitung bereinigt oder entfernt, wenn der Zeitstempel 258 älter als ein Schwellenwert ist. Anders gesagt, wenn das Objekt in Bearbeitung nicht für eine Schwellenwertdauer geschrieben wurde, wird das Objekt in Bearbeitung gelöscht, weil es von dem Client abgelegt wurde. Dies kann einen Prozess beinhalten, der auf dem wie hierin erläuterten Objektrezept basiert, um das Objekt in Bearbeitung zu identifizieren und aus dem Objektspeicher-Bucket 230 zu entfernen.
4 veranschaulicht ein Beispiel für eine Datenbereinigungsoperation. In einem Beispiel wird die Datenbereinigungsoperation in Phasen durchgeführt. Das Verfahren kann mit einer Startup-Phase 402 beginnen, in welcher die Steuerung instanziiert wird und die Worker zugeteilt oder instanziiert werden. Ein Teil der Zuweisung von Workern kann das Bestimmen der Anzahl an Worker beinhalten, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen. Die Startup-Phase 402 ist weiter in 5 veranschaulicht.
5 veranschaulicht ein Beispiel für eine Startup-Phase. Die Startup-Phase beginnt typischerweise durch Initiieren oder Instanziieren 502 einer Steuerung. Wenn z.B. der Zeitpunkt zum Durchführen einer Datenbereinigungsoperation erreicht ist, wird ein Job (z.B. ein Cron Job) erzeugt und die Steuerung wird instanziiert. Die Steuerung kann innerhalb eines Clusters wie eines Kubernetes-Clusters erzeugt werden.
Sobald die Steuerung instanziiert wurde, ermittelt die Steuerung 504 die Anzahl an Workern, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen. Das Ermitteln 504 der Anzahl an Workern kann das Bestimmen 506 oder Identifizieren der Ähnlichkeitsgruppen beinhalten, die von der Datenbereinigungsoperation betroffen sind. Dies kann durch Evaluierung der Löschaufzeichnungen bestimmt werden. Die Anzahl der Worker wird auch durch die Ermittlung 508 der Kapazität jedes der Worker beeinflusst. Ferner kann diese Ermittlung verschiedene Beschränkungen berücksichtigen, von denen das Schutzsystem betroffen ist, einschließlich dabei Speicher, Input / Output Operationen (I/O) oder Durchsatz.
Die Anzahl an Workern kann auf verschiedene Weisen ermittelt 504 werden. In einem Beispiel kann die Anzahl von Workern über eine Umgebungsvariable festgelegt werden. Eine Umgebungsvariable kann aus Test-, Debugging- und Leistungsvergleichszwecken nützlich sein. Die Verwendung einer Umgebungsvariablen hüft auch dabei, Szenarien zu evaluieren, die bei komplexeren Ermittlungsverfahren nicht berücksichtigt oder antizipiert werden können. Die Umgebungsvariable kann basierend auf der vergangenen Leistung oder aus anderen Gründen aktualisiert werden.
Wie zuvor angeführt wurde, kann die durchzuführende Arbeit von einer Reihe von betroffenen Ähnlichkeitsgruppen beeinflusst werden. Als Folge dessen kann die Anzahl von betroffenen Ähnlichkeitsgruppen bestimmt werden 506, wenn die Anzahl an zu verwendenden Workern ermittelt wird.
6 veranschaulicht ein Beispiel für ein Verfahren, das die Anzahl an Workern ermittelt, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen. In einem Beispiel werden Zuordnungen für die Dimensionierung erzeugt 602. Die Zuordnungen helfen dabei, den Raum oder den Speicher zu identifizieren, der von einem Worker benötigt wird, um die Datenbereinigungsoperation durchzuführen. In einem Beispiel wird die Datenbereinigungsoperation den Workern basierend auf Ähnlichkeitsgruppen zugewiesen - jeder Worker ist für einen Bereich von Ähnlichkeitsgruppen verantwortlich. Jeder Bereich muss aber nicht derselbe sein. So können die Worker z.B. jeweils einem Bereich von Ähnlichkeitsgruppen zugewiesen werden, um basierend auf den Größen der betroffenen Ähnlichkeitsgruppen zu bereinigen.
Die Zuordnungen können eine Ähnlichkeitsgruppenzuordnung für die Teilgruppen jeder Ähnlichkeitsgruppe und eine Gesamtähnlichkeitszuordnung, um die Gesamtgröße des für alle betroffenen Ähnlichkeitsgruppen betroffenen Speichers zu verfolgen, beinhalten. Nach dem Erzeugen der Zuordnungen werden die gelöschten Objektaufzeichnungen aus dem Lösch-Bucket gelesen 604. Die Aufzeichnungen werden geparst oder evaluiert, um die mit den gelöschten Objekten in dem Lösch-Bucket assoziierten Slices zu identifizieren oder aufzulisten 606. Die Ähnlichkeitsgruppenidentifikatoren können aus der Liste von Slices erhalten werden, die aus den Löschaufzeichnungen identifiziert wurden. In einer Namenskonvention beinhaltet der Name jedes Slice-Rezeptes den Namen der Ähnlichkeitsgruppe und Teilgruppe, die das Slice-Rezept referenziert. Die aus den Löschaufzeichnungen erhaltenen Ähnlichkeitsgruppenidentifikatoren können in die Zuordnungen eingefügt werden, und die Größen werden berechnet. In einer Implementierung wird die Größe der <Ähnlichkeitsgruppe, Teilgruppe> unmittelbar überprüft. In einer anderen Implementierung wird der Ähnlichkeitsgruppenidentifikator in einer Zuordnung gespeichert, und eine separate Auflistung erfolgt aller Ähnlichkeitsgruppen und Teilgruppen entsprechend ihrer Größen, und die erforderlichen Größen werden in den Zuordnungen gespeichert. Somit werden die betroffenen Ähnlichkeitsgruppen und ihre Größen in der Ähnlichkeitsgruppenzuordnung und der Gesamtähnlichkeitszuordnung aufgezeichnet. Die Größe der Zuordnung wird berechnet und z.B. bei der Verteilung von Arbeit an die Worker verwendet.
In diesem Beispiel bezieht sich Größe auf die Bits, die benötigt werden, um die betroffenen Ähnlichkeitsgruppen im Speicher darzustellen. Somit kann jede Ähnlichkeitsgruppe und Teilgruppe mit einer Größe assoziiert sein. Alle Größen der Teilgruppe der Ähnlichkeitsgruppe werden in der Gesamtzuordnung zusammengezählt, und die Gesamtgröße insgesamt kann bestimmt werden. Unter Verwendung der Größe kann jedem Worker ein Bereich von Ähnlichkeitsgruppen zugewiesen werden, die effektiv verarbeitet werden können. In einer Ausführungsform werden alle Teilgruppen einer Ähnlichkeitsgruppe demselben Worker zugewiesen, um die Bestimmung zu vereinfachen, welcher Worker welche Ähnlichkeitsgruppen und Teilgruppen handhabt. Die Zuordnungen können unter Verwendung z.B. von Hash-Tabellen implementiert werden. Die Größe jeder Ähnlichkeitsgruppe und Teilgruppe kann sich auf die Größe innerhalb eines Objektspeichers oder die Anzahl an Bits (oder Bytes) beziehen, die erforderlich sind, um die Fingerabdrücke der Ähnlichkeitsgruppe unter Verwendung einer Hash-Tabelle, eines Bloom-Filters oder eines perfekten Hash-Vektors darzustellen.
Nachdem die Ähnlichkeitsgruppen und ihre Größen aufgezeichnet wurden können die Ähnlichkeitsgruppen partitioniert werden 610. So kann z.B. die Gesamtähnlichkeitskarte von dem niedrigsten Ähnlichkeitsgruppen-ID zum höchsten Ähnlichkeitsgruppen-ID sortiert werden. Der Prozess kann durch die Zuordnung iterieren und Ähnlichkeitsgruppen-IDs einem Worker zuweisen, bis die Größe der aktuellen zugewiesenen Ähnlichkeitsgruppe für den Worker zu groß ist. In diesem Fall endet die Partition, und eine Partition wird für den nächsten Worker bestimmt. Die aktuelle Zuweisung weist alle Teilgruppen einer Ähnlichkeitsgruppe einem Worker zu, und nachfolgende Ähnlichkeitsgruppenidentifikatoren werden einem Worker zugewiesen, wenngleich auch andere Zuweisungstechniken möglich sind. Die Löschaufzeichnungen können dann entfernt werden 612.
Die Inhalte der Löschaufzeichnungen können die Operation der Bestimmung der Anzahl von betroffenen Ähnlichkeitsgruppen beeinflussen. Wenn z.B. die Löschaufzeichnungen ein Objektrezept oder einen Namen des Objekts enthalten, so erlaubt dies, dass die Anzahl von betroffenen Slices identifiziert wird und eine Obergrenze für die Anzahl an betroffenen Ähnlichkeitsgruppen ergibt. Dies kann auch die Zeit reduzieren, die erforderlich ist, um die eindeutigen Ähnlichkeitsgruppen zu zählen, die von den gelöschten Aufzeichnungen referenziert werden, weil das Auflisten der Slices eine möglicherweise teure Objektspeicheroperation umfasst.
Im Kontext der Ermittlung der Anzahl von Workern für die Datenbereinigungsoperation kann die Anzahl von Workern auch von der Worker-Kapazität abhängen. Die Kapazität kann vom Speicher, den IO-Operationen, dem Durchsatz und dergleichen abhängen. Diese Faktoren können auch in den Prozess zur Bestimmung der Anzahl von Workern für den Datenbereinigungsprozess aufgenommen werden.
Der dem Knoten oder den Knoten, auf welchen die Worker laufen, zugeteilte Speicher kann begrenzt oder beschränkt sein und kann berücksichtigt werden, wenn die Anzahl von Workern für die Datenbereinigungsoperation ermittelt wird. In dieser Situation kann die Anzahl von Workern durch Ermitteln der Arbeitskapazität eines Workers basierend auf ihrer Speicherzuteilung ermittelt werden.
So können die Worker z.B. durch den Speicher beschränkt sein. Eine Ähnlichkeitsgruppe referenziert eine oder mehrere Kompressionsregionen, die jeweils ein Segment oder über 1.000 aufweisen, jeweils mit einer Größe von etwa 8KB. Eine Ähnlichkeitsgruppe zeichnet mit jedem Kompressionsregionsnamen, den sie referenziert, die Liste von Fingerabdrücken und Segmentgrößen, die den Segmenten in den Kompressionsregionen entsprechen, auf. Ein Worker hält eine Aufzeichnung für jeden Fingerabdruck für jede Ähnlichkeitsgruppe und Teilgruppe, die dem Worker zugewiesen ist, so dass er die Aktivität jedes Segments bestimmen kann, das von diesen Ähnlichkeitsgruppen referenziert wird. Teilgruppen der Ähnlichkeitsgruppe werden gegenwärtig bei einer Gesamtgröße von 8MB gekürzt. Die Arbeitskapazität (oder Anzahl an Ähnlichkeitsgruppen, die der Worker verarbeiten kann) für jeden Worker kann wie folgt bestimmt oder ermittelt werden 508: $\frac{Worker - Knoten - Speicher}{8 MB}$
In einer Erweiterung können anstelle der Aufzeichnung von Fingerabdrücken in einer Hash-Tabelle für jede Ähnlichkeitsgruppe oder Teilgruppe die Fingerabdrücke in einem Bloom-Filter aufgezeichnet werden Dies reduziert die Speicheranforderungen von 8MB pro Ähnlichkeitsgruppe auf etwa 400KB, weil ein Bloom-Filter eine kompakte festgelegte Zugehörigkeitsstruktur ist. Es könnte ein perfekter Hash-Vektor anstelle eines Bloom-Filters verwendet werden, was die Speicheranforderungen auf etwa 130KB reduzieren würde.
Sobald die Arbeitskapazität pro Worker und die Gesamtanzahl an betroffenen Ähnlichkeitsgruppen berechnet wurden, kann die Anzahl an Workern, die für die Datenbereinigungsoperation erforderlich sind, wie folgt berechnet werden:
$⌈ \frac{Anzahl an betroffenen \ddot{A} hnlichkeitsgruppen}{Anzahl an \ddot{A} hnlichkeitsgruppen, die jeder Worker verarbeiten kann} ⌉$
In einer Erweiterung können anstatt der Annahme, dass alle Ähnlichkeitsgruppen die maximal mögliche Größe von 8MB haben, die Größen der Ähnlichkeitsgruppe und Teilgruppe von der Steuerung bei der Berechnung für den Speicher bestimmt werden, der notwendig ist, um die Fingerabdrücke der Ähnlichkeitsgruppe und der Teilgruppe innerhalb eines Workers darzustellen. Die Größe wird basierend auf der gewählten Darstellung, so z.B. einer Hash-Tabelle, eines Bloom-Filters oder eines perfekten Hash-Vektors, modifiziert. Die Größe wird zusammengerechnet und durch die Menge an Speicher geteilt, die jedem Worker zur Verfügung steht, um die Anzahl an zuzuteilenden Workern zu bestimmen.
In einem anderen Beispiel können die Datenbereinigungsoperation oder Aspekte des Schutzsystems durch IO (Input/Output-Operationen) beschränkt werden, und diese Beschränkung kann auch die Anzahl an Workern betreffen, die für die Datenbereinigungsoperation erforderlich sind. In diesem Beispiel kann die Anzahl an Workern in einer Weise bestimmt werden, die effizient oder am besten die IOs verwendet, die den Worker-Knoten zugeteilt sind.
In einem Beispiel können die IOs, die den Knoten, auf welchen die Worker-Pods laufen, zugeteilt sind, mit der Zeitdauer kombiniert werden, über welche die Datenbereinigungsoperation laufen darf. Um die Menge an IO-Operationen zu ermitteln, die während einer Datenbereinigungsoperation ablaufen, können die Typen von IOs, die in dem Schutzsystem auftreten, differenziert werden. So sind z.B. IO-Operationen gegeben, die mit dem Drucken von Logs, dem Senden von RPC-Aufrufen zwischen Diensten und mit Aufrufen an den Objektspeicher assoziiert sind. Unter diesen Typen von IO-Operationen dominiert die Wartezeit (Latenz) auf den Objektspeicher. Dies ermöglicht Ausführungsformen der Erfindung, sich auf Objektspeicheraufrufe allein zu konzentrieren, um eine Ermittlung der IO-Operationen insgesamt zu erhalten.
In einem Beispiel wird die Anzahl an IO-Operationen ermittelt oder bestimmt, die notwendig sind, um eine einzelne Ähnlichkeitsgruppe zu bereinigen. Es kann 1 IO-Operation gegeben sein, um eine Ähnlichkeitsgruppe zu lesen, 1 IO-Operation, um eine Ähnlichkeitsgruppe zu schreiben, und 1 OP-Operation, um jede Kompressionsregion auszulesen. Wenn die Kompressionsregionen bereinigt werden, ist es möglich, von 2 gelesenen Kompressionsregionen pro 1 geschriebenen Kompressionsregion ausgehen. Dies stellt ein Verhältnis von 2:1 für gelesene zu geschriebenen Kompressionsregionen dar. Als nächstes gibt es Löschaufrufe an die alten Kompressionsregionen, die mit etwa derselben Anzahl von IO-Operationen wie der Anzahl an Kompressionsregionsauslesungen assoziiert sind.
Es kann eine Annahme über die Anzahl an Kompressionsregionen gemacht werden, die pro Ähnlichkeitsgruppe referenziert sind. So kann z.B. eine Ähnlichkeitsgruppe etwa 8MB an Werten beinhalten, die Slice-Identifikatoren identifizieren. Ein Slice von ~8MB slice beinhaltet etwa 1024 8KB Segmente. Geht man davon aus, dass 50 Prozent dieser Segmente während der Deduplikation entfernt werden, so werden etwa 512 Segmente in jede Kompressionsregion eingegeben oder geschrieben. Jede von einer Ähnlichkeitsgruppe referenzierte Kompressionsregion weist einen Namen und eine Anzahl von Fingerabdruckreferenzen (20 Bytes für SHA1 Hash und 4 Bytes für die Größe) auf. Aus diesem Grund benötigt jeder Segmentfingerabdruck 24 Bytes. Daraus resultierend benötigt eine Kompressionsregion etwa 512 * 24 = 12.288 Bytes in einer Ähnlichkeitsgruppe. Bei ~8 MB bedeutet eine durch 12.288 Bytes geteilte Ähnlichkeitsgruppe, dass eine Ähnlichkeitsgruppe -683 Kompressionsregionen referenzieren könnte. Es kann auch notwendig sein, die Slices zu berücksichtigen, die während der Phase „Mark Live Fingerprints (Markieren von aktiven Fingerabdrücken)“ ausgelesen werden. Als Schätzung kann man vernünftigerweise annehmen, dass ein gelesenes Slice pro Kompressionsregion gegeben ist.
Diese Information ermöglicht, dass die Anzahl an IO-Operationen, die notwendig sind, um eine Ähnlichkeitsgruppe zu bereinigen, wie folgt ermittelt werden kann: $\begin{array}{l} 1 (z u m L e s e n d e r \ddot{A} h n l i c h k e i t s g r u p p e) \\ + 683 (f \ddot{u} r K o m p r e s s i o n s r e g i o n s a u s l e s u n g e n) + \\ 683 (f \ddot{u} r S l i c e - A u s l e s u n g e n) + 1 (z u m S c h r e i b e n d e r \ddot{A} h n l i c h k e i t s g r u p p e) \\ + \\ 342 (f \ddot{u} r K o m p r e s s i o n s r e g i o n s s c h r e i b v o r g \ddot{a} n g e) \\ + 683 (f \ddot{u} r K o m p r e s s i o n s r e g i o n s l \ddot{o} s c h u n g e n) + \\ 1 + (z u m L \ddot{o} s c h e n d e r a l t e n \ddot{A} h n l i c h k e i t s g r u p p e n) = 2.394 IO - \\ O p e r a t i o n e n \end{array}$
Nach der Ermittlung der IO-Operationen insgesamt, die notwendig sind, um ein Ähnlichkeitsgruppe zu bereinigen, ist es erforderlich, die betroffenen Ähnlichkeitsgruppen während der Laufzeit zu zählen, um zu bestimmen, wie viele IO-Operationen erforderlich sind, um all betroffenen Ähnlichkeitsgruppen zu bereinigen. Die Ermittlung der Anzahl an IO-Operationen kann basierend auf der Größe der Ähnlichkeitsgruppen und Teilgruppen angepasst werden. Ähnlichkeitsgruppen und Teilgruppen, die kleiner als die vollen 8MB oder kleiner als die maximal definierte Größe sind, bedingen weniger IO-Operationen als das gegebene Beispiel.
Sobald die Gesamtanzahl an IO-Operationen bestimmt oder ermittelt wurde, kann die Anzahl an Workern basierend auf den Leistungscharakteristiken der Worker-Knoten entschieden werden, die die möglichen IOPS für diesen bestimmten Knoten diktieren, zusammen mit der erwünschten Zeit, um den Datenbereinigungslauf abzuschließen. In einem Beispiel werden die IO-Operationen typischerweise durch die Netzwerkkarte, die CPU oder den Prozessor und dergleichen begrenzt. Unter Verwendung einer Offline-Analyse kann in einem Beispiel die Anzahl an IOPS, die jede Instanz unterstützen kann, bestimmt und als Input (Eingabe) für die Berechnung verwendet werden.
Mit dieser Information kann die Anzahl an Workern wie folgt ermittelt werden:
$⌈ \frac{I / O - Operationen insgesamt}{IOPS pro Knoten * Zeit in Sekunden, um den GC - Lauf abzuschlie ß en} ⌉$
In einem anderen Beispiel können diese Verfahren durch Veränderung einiger der Annahmen angepasst werden. In einem Beispiel können Zähler verwendet werden, um die IO-Operationen während einer Datenbereinigungsoperation zu verfolgen. Dies erlaubt, dass eine IO-Operationszählung in einer Konfigurationsdatei aktualisiert werden kann, die während der nachfolgenden Datenbereinigungsoperationen verwendet werden kann. Dies stellt ein Beispiel für eine Feedback-Schlaufe dar, die erlaubt, die Genauigkeit der IO-Operationsermittlung basierend auf vorherigen Daten zu verbessern.
Mit dieser Information kann die Anzahl an Workern ermittelt werden, und die Steuerung kann die Erzeugung der Worker abschließen. 7 veranschaulicht Beispiele für Faktoren, die bei der Bestimmung und Ermittlung der Anzahl an Workern verwendet werden können. Die Ermittlung von Workern 702 kann auf Faktoren beruhen, die ein oder mehrere einer Umgebungsvariable 704, Worker-Speicher 706, betroffene Ähnlichkeitsgruppen 708 und/oder IO-Operationen 710 einschließen.
Es ist zu verstehen, dass die Ermittlung der Anzahl an Workern eine oder mehrere dieser Eigenschaften in einer beliebigen Kombination verwenden kann. In einem weiteren Beispiel kann die Anzahl an Workern unter Verwendung jeder Eigenschaft berechnet werden, und die minimale, durchschnittliche oder maximale Anzahl von ermittelten Workern könnte für jede Eigenschaft zugeteilt werden.
In einem Beispiel kann sich die Datenbereinigungsoperation auf die Bereinigung von Ähnlichkeitsgruppen und Kompressionsregionen, die von den Ähnlichkeitsgruppen referenziert werden, konzentrieren. Weil die Ähnlichkeitsgruppen einen ID in einem gegebenen Bereich (z.B. 8 bis 4 Milliarden) aufweisen, können die Ähnlichkeitsgruppen gleichmäßig (basierend auf Anzahl und/oder angenommenen Größen) über die Worker geteilt werden. Die Teilungen können in einer Tabelle aufgezeichnet werden, die von der Steuerung und den Workern gemeinsam verwendet wird. Die Steuerung und die Worker können miteinander unter Verwendung von beispielsweise RPC-Aufrufen (Remote Procedure Calls) kommunizieren.
Zurück zu 4 können die betroffenen Ähnlichkeitsgruppen nach der Startup-Phase 402 markiert werden 404. Um zu wissen, welche Datenstrukturen aus dem Objektspeicher-Bucket zu bereinigen sind, werden die Löschaufzeichnungen analysiert, um die Slice-Rezepte und betroffenen Ähnlichkeitsgruppen zu identifizieren, die mit den Löschaufzeichnungen assoziiert sind. Weil Ähnlichkeitsgruppen mit Slices assoziiert sind, ermöglicht das Identifizieren der Slices, die assoziierten Ähnlichkeitsgruppen zu markieren oder zu identifizieren.
8A veranschaulicht ein Beispiel für die Verarbeitung von Ähnlichkeitsgruppen. In einem Beispiel kann, nachdem eine Steuerung initiiert wurde (und bevor die Worker instanziiert werden), die Steuerung die Löschaufzeichnungen evaluieren, um die betroffenen Ähnlichkeitsgruppen zu identifizieren, die Größen der betroffenen Ähnlichkeitsgruppen / Teilgruppen zu bestimmen und Worker-Zuweisungen vorzubereiten.
8A veranschaulicht, dass eine Steuerung auf die Löschaufzeichnungen zugreift 802. Die Löschaufzeichnungen erlauben der Steuerung, die Slice-Rezepte abzurufen oder auf diese zuzugreifen 804. Weil die Slice-Rezepte jeweils mit einer spezifischen Ähnlichkeitsgruppe assoziiert sind, können die betroffenen Teilgruppen identifiziert werden, und ihre Größen können bestimmt werden 806. Die Größe jeder betroffenen Teilgruppe kann angenommen oder tatsächlich bestimmt werden. Bei der Bestimmung der betroffenen Ähnlichkeitsgruppen und der Größen der Ähnlichkeitsgruppen können verschiedene Größen gespeichert werden. Die Größe jeder betroffenen Teilgruppe, die Größe einer betroffenen Ähnlichkeitsgruppe und die Größe aller betroffenen Ähnlichkeitsgruppen können z.B. gespeichert werden.
Basierend auf den Größen und/oder der Anzahl an betroffenen Ähnlichkeitsgruppen kann die Steuerung die Worker-Zuteilungen vorbereiten 808. Anders gesagt, die Ähnlichkeitsgruppen werden partitioniert und den Workern zugewiesen. Diese Zuweisungen oder Partitionen teilen effektiv eine Gruppierung von Ähnlichkeitsgruppen jedem der geplanten Worker zu. Anders gesagt, die Steuerung kann die Anzahl an erforderlichen Workern ermitteln und Zuweisungen für jeden dieser Worker vorbereiten. Die Ähnlichkeitsgruppen können gleichmäßig, basierend auf Größen, verteilt werden, so dass die Anzahl an Ähnlichkeitsgruppen, die jedem Worker zugewiesen wird, variieren kann oder dergleichen. Alternativ können die Ähnlichkeitsgruppen derart verteilt werden, so dass ihre Größen für jeden Worker etwa gleich sind.
Als nächstens werden die Worker instanziiert und die Zuweisungen werden gemacht 810. In diesem Beispiel können die Worker mit der Steuerung kommunizieren, um ihre zugewiesene Liste von Ähnlichkeitsgruppen und Teilgruppen zu erhalten. Basierend auf den assoziierten Größen können die Worker eine passende Struktur erzeugen, um die Fingerabdrücke der Segmente zu verfolgen. Dies erlaubt, die aktiven Segmente zu identifizieren, so dass die aktiven Segmente nach vor getragen werden können.
8B veranschaulicht ein anderes Beispiel für die Identifizierung oder Markierung betroffener Ähnlichkeitsgruppen. Die Löschaufzeichnungen werden z.B. von der Steuerung abgerufen oder erhalten 820 (z.B. als eine Liste). Die Steuerung kann dann einen Aufruf (z.B. einen RPC-Aufruf) an einen der Worker basierend auf deren zugewiesenen Ähnlichkeitsgruppen ausgeben, so dass der Worker zumindest einen Teil der Liste von Löschaufzeichnungen empfängt.
Die Slice-Rezepte werden aus den Löschaufzeichnungen abgerufen 822 oder aufgelistet. Der Worker ruft dann die Slice-Rezepte für die gelöschten Objekte und assoziierten Ähnlichkeitsgruppen ab. Die Worker sind typischerweise für die Bereinigung der Slice-Rezepte, die in den Löschaufzeichnungen identifiziert sind, aus dem Objektspeicher verantwortlich. Genauer gesagt beinhaltet der Name jedes Slice-Rezeptes die Ähnlichkeitsgruppe, die durch jedes Slice-Rezept referenziert ist.
Dies ermöglicht dem Worker, die Ähnlichkeitsgruppe zu markieren 824, so lange die Ähnlichkeitsgruppe innerhalb des Bereichs von dem Worker zugewiesenen Ähnlichkeitsgruppen liegt. Liegt eine Ähnlichkeitsgruppe nicht innerhalb des zugewiesenen Bereichs an Ähnlichkeitsgruppen des Workers, so kann der Worker einen Aufruf an einen passenden Worker machen, so dass der aufgerufene Worker die Ähnlichkeitsgruppe markieren kann.
Als Teil der Markierung können die Ähnlichkeitsgruppen/Teilgruppen zugeordnet und dimensioniert werden 826. Anders gesagt, es kann eine Zuordnung generiert werden, die die betroffenen Ähnlichkeitsgruppen den Größen zuordnet. Genauer gesagt resultiert diese Operation oder dieser Prozess in einer Zuordnung von betroffenen Ähnlichkeitsgruppen zu Datenstrukturen, die aktive Segmente, die Anzahl an aktiven Slices und die Anzahl an aktiven Segmenten hält, die in nachfolgenden Phasen verwendet werden, einschließlich Phasen der Markierung von aktiven Fingerabdrücken 408 und der Vorkopie 410.
Datenbereinigung kann ein zeitintensiver Prozess sein. Als ein Resultat davon werden, nachdem die Ähnlichkeitsgruppen markiert wurden 404, die betroffenen Ähnlichkeitsgruppen schreibgesperrt 406, wie dies in 4 gezeigt ist. Somit werden, um den Clients zu erlauben, normale Operationen auszuführen, die betroffenen Ähnlichkeitsgruppen schreibgesperrt. Dies ermöglicht, dass die Datenbereinigungsoperation gleichzeitig oder simultan mit den normalen Operationen verarbeitet.
So kann die Datenbereinigungsoperation z.B. eine Ähnlichkeitsgruppe betreffen, die das Ziel einer normalen Schreiboperation ist. Dies kann in der Entfernung von Segmenten resultieren, die eine Schreiboperation referenziert oder ausgibt. Dies wird durch die durch Schreibsperre betroffenen Ähnlichkeitsgruppen verhindert.
Genauer gesagt können die Ähnlichkeitsgruppen Teilgruppen beinhalten, um Verzögerungen zu verhindern oder zu reduzieren und gleichzeitige Schreiboperationen zu ermöglichen. Typischerweise sind normale Schreiboperationen auf die höchstnummerierte Teilgruppe gerichtet (z.B. weil die anderen Teilgruppen voll sind). Wird die höchstnummerierte Teilgruppe in einer Ähnlichkeitsgruppe für die Bereinigung markiert, so wird eine neue Teilgruppe zu der Ähnlichkeitsgruppe für hereinkommende Schreibvorgänge hinzugefügt. Daraus resultierend referenzieren keine hereinkommenden Schreiboperationen eine betroffene Ähnlichkeitsgruppe, und diese Operationen können gleichzeitig durchgeführt werden.
9 veranschaulicht ein Beispiel für eine Ähnlichkeitsgruppe. Die Ähnlichkeitsgruppe 902 ist mit Teilgruppen 1 durch Teilgruppe N assoziiert. Wie in 9 veranschaulicht ist, ist jede der Teilgruppen mit derselben Ähnlichkeitsgruppe 902 assoziiert, und jede Teilgruppe kann ein eigenes Objekt sein. Der Ähnlichkeitsgruppen-ID 904 stellt dar, dass jede der Teilgruppe zu der Ähnlichkeitsgruppe gehört, die mit demselben Ähnlichkeitsgruppen-ID assoziiert ist. In diesem Beispiel ist die Teilgruppe N die höchstnummerierte Teilgruppe. Ist die Teilgruppe N eine betroffene Teilgruppe, so wird eine neue Teilgruppe N+1 hinzugefügt. Jede Teilgruppe wird als ein separates Objekt in einem Objektspeicher gespeichert.
Genauer gesagt wird jedes Slice eines Objekts einer Ähnlichkeitsgruppe basierend auf einer Funktion der Daten innerhalb des Slice zugeordnet. Die Funktion produziert typischerweise einen Identifikator (ID) zwischen 1 und 4 Milliarden in einem Beispiel. Slices werden typischerweise nur gegen die Ähnlichkeitsgruppe und die höchste Teilgruppe mit demselben Ähnlichkeitsgruppen-ID dedupliziert. Erreicht eine Teilgruppe einen Schwellengröße (z.B. 8 MB), wird eine leere Ähnlichkeitsgruppe mit demselben Ähnlichkeitsgruppen-ID aber einem erhöhten Teilgruppen-ID gebildet. Zukünftige Slices, die der Ähnlichkeitsgruppe zugeordnet sind, werden gegen den aktuellen Teilgruppen-ID dedupliziert. Dies stellt sicher, dass neue Schreibvorgänge nicht betroffene Ähnlichkeitsgruppen oder Teilgruppen, die von der Datenbereinigungsoperation bereinigt werden, stören.
Dies kann zu einem möglichen Deduplikationsverlust führen, weil Teilgruppen leer beginnen. Leere Teilgruppen können aber entfernt werden, weil es sicher ist, sie gegen eine Ähnlichkeitsgruppe und/oder Teilgruppe zu deduplizieren, sobald sie bereinigt sind. Alternativ könnten Deduplikationsaufgaben von dem Metadaten-Server durchgeführt werden, um die passenden Fingerabdrücke zu markieren, indem mit den Datenbereinigungs-Workern kommuniziert wird.
Zurück zu 4 werden, nachdem betroffene Ähnlichkeitsgruppen gesperrt wurden, aktive Fingerabdrücke in den betroffenen Ähnlichkeitsgruppen markiert 408. 10 veranschaulicht ein Beispiel für das Markieren von aktiven Fingerabdrücken. 10 wird auch verwendet, um ein Verfahren zum Markieren von aktiven Fingerabdrücken zu veranschaulichen.
Anfänglich kann die Steuerung 1002 eine Liste von aktiven Slice-Rezepten erhalten. Dies kann durch Sammeln aller Deduplikationsdomänenidentifikatoren in dem Speichersystem erzielt werden. In einem Beispiel ist ein Deduplikationsdomänenidentifikator ein eindeutiger Identifikator, der mit einem Nutzer assoziiert ist. Jedes Objekt, das von diesem Nutzer im Objektspeicher gespeichert wird, enthält eine Referenz auf den Deduplikationsdomänenidentifikator. Neue Objekte werden nur gegen andere Objekte, die mit demselben Deduplikationsdomänenidentifikator assoziiert sind, aus Gründen von Mandantenisolation, Datenschutz und Sicherheit dedupliziert. Ein Nutzer kann sich z.B. auf eine Entität oder Organisation beziehen. Diese Information kann auch von einem Metadaten-Server erhalten werden. Dann werden alle Objektrezepte für die Deduplikationsdomänenidentifikatoren bestimmt, und aus jedem Objektrezept werden die aktiven Slice-Rezepte aufgelistet. Nach dem Erhalt der Liste von aktiven Slice-Rezepten kann die Steuerung die Slice-Rezepte den Workern (z.B. dem Worker 1004 und dem Worker 1006) auf der Basis der vorherigen Zuteilung zuweisen. So sind z.B. die Slices, die dem Worker 1004 zugewiesen sind, jene, die dem Ähnlichkeitsgruppenbereich entsprechen, der dem Worker 1004 von der Steuerung 1002 zugewiesen wird.
Insbesondere kann die Steuerung 1002 den Slice-Rezeptnamen parsen oder analysieren, um den Ähnlichkeitsgruppen-ID und Teilgruppen-ID zu bestimmen. Mit dem Ähnlichkeitsgruppen-ID und dem Teilgruppen-ID sieht die Steuerung 1002 in ihrer Worker-Tabelle nach, um den Worker zu identifizieren, dessen zugewiesener Ähnlichkeitsgruppenbereich den bestimmten Ähnlichkeitsgruppen-ID enthält. Das Slice wird dann in den Kanal 1036 (z.B. eine Schlange) der aktiven Slices des Workers gedrückt. Jeder Worker besitzt seinen eigenen aktiven Slice-Kanal, und diese Zuordnung wird von der Steuerung unter der Verwendung der ID-Adresse des Workers verwaltet. Sobald die Steuerung durch all aktiven Slice-Rezepte hindurchgegangen ist und die aktiven Slice-Rezepte in ihren entsprechenden Worker-Kanal gedrückt hat, kann die Steuerung alle Worker-Kanäle schließen.
Währenddessen macht der Worker 1004 (und andere Worker) Aufrufe an die Steuerung 1002 und entnimmt eine Charge von Slice-Rezepten aus dem Kanal 1036, in welchen die Steuerung 1002 aktive Slice-Rezepte hineingibt. Der Worker 1004 zieht die aktiven Slice-Rezepte in Chargen weiter aus dem Kanal 1036, bis der Kanal leer ist. Mit der Liste an aktiven Slice-Rezepten bestimmt der Worker 1004 den Ähnlichkeitsgruppen-ID. Mit dem Ähnlichkeitsgruppen-ID überprüft der Worker 1004, ob die Ähnlichkeitsgruppe zum Bereinigen markiert ist oder eine betroffene Ähnlichkeitsgruppe ist. Ist die Ähnlichkeitsgruppe markiert, liest der Worker 1004 das assoziierte Slice-Rezept und zeichnet die Liste an aktiven Fingerabdrücken in einer internen aktiven Segmentstruktur 1034 wie einem Bloom-Filter auf. Diese aktive Segmentstruktur 1034 kann konfiguriert sein, um Informationen wie die Anzahl an aktiven Slices, die Anzahl an aktiven Segmenten und eine List davon, welche Segmente aktiv sind, zu enthalten. Um Speicheranforderungen zu reduzieren, kann die Liste von Segmenten in einer Hash-Tabelle, einem Bloom-Filter oder einem perfekten Hash-Vektor dargestellt werden. Der Worker 1004 kann eine Liste von Segmentstrukturen für jede betroffene Ähnlichkeitsgruppe halten, für die der Worker verantwortlich ist. Nachdem alle Worker ihre Liste von aktiven Slice-Rezepten durchgegangen sind, wurde jede aktive Segmentstruktur vollständig aktualisiert.
10 veranschaulicht das Schutzsystem in der Phase der Markierung der aktiven Segmente. So kann das Objekt X z.B. aus den Segmenten 1, 2, 3, 4 und 5 gebildet sein. Das Objekt X kann, wie dies in 3 veranschaulicht ist, gelöscht worden sein. 10 veranschaulicht, dass im Objektspeicher 1020 die betroffene Ähnlichkeitsgruppe die Ähnlichkeitsgruppe A, Teilgruppe 1, beinhaltet. Ist dies die höchste Teilgruppe, so würde eine neue Teilgruppe 2 während der Datenbereinigungsoperation erzeugt, wie dies zuvor beschrieben wurde.
Die Ähnlichkeitsgruppe A ist mit Kompressionsregionen (CR) assoziiert, einschließlich dabei CR 3, welche die Fingerabdrücke 1, 2, 3, 4, 5 und die entsprechenden Segmente beinhaltet, sowie CR 4, welche die Fingerabdrücke 6, 7 und die entsprechenden Segmente beinhaltet.
Das Objekt Y wurde nicht gelöscht, und der Objektspeicher 1020 beinhaltet das Objektrezept 1022 und das Slice-Rezept 1024 von Y, welches die Ähnlichkeitsgruppe A, Teilgruppe 1, und die Fingerabdrücke 1, 2, 5, 6 und 7 identifiziert.
Somit haben die beiden Objekte X und Y die Segmente 1 und 2 gemeinsam. CR 3 beinhaltet die Segmente 1, 2, 3, 4 und 5, und CR 4 beinhaltet die Segmente 6, 7.
Ruft der Worker 1004 ein Slice-Rezept von der Steuerung 1002 ab, so bestimmt der Worker, ob das Slice-Rezept eine betroffene Ähnlichkeitsgruppe referenziert. Falls nicht, so wird das Slice ausgelassen. Falls ja, so wird das Slice-Rezept ausgelesen und die aktiven Fingerabdrücke werden in der Ähnlichkeitsgruppe markiert.
Somit werden, wenn das Rezept für das Objekt Y empfangen wird, die Fingerabdrücke oder Segmente 1, 2 und 5 in CR 3 markiert, und die Segmente 6 und 7 in CR 4 werden markiert. Dies spiegelt sich in der Struktur 1034 wider, wo die Segmente 1, 2, 5, 6 und 7 als aktiv markiert sind.
Mit Verweis auf 4 kann die Phase des Vorkopierens 410 fortsetzen, nachdem die aktiven Segmente markiert wurden. Das Vorkopieren ist eine Phase, die sicherstellt, dass keine unreferenzierten Strukturen oder Segmente im Objektspeicher verbleiben. Dies reduziert vorteilhaft die Speicherkosten. Gleichzeitig gibt es Situationen, in welchen einige Strukturen basierend auf z.B. dem Verhältnis von aktiven Segmenten zu toten Segmenten nicht bereinigt werden.
In einem Beispiel verarbeitet der Worker 1004 seine Liste von Slices und entsprechender betroffener Ähnlichkeitsgruppe. Jede Ähnlichkeitsgruppe ist mit einer Zuordnung von aktiven Segmenten für jede Ähnlichkeitsgruppe assoziiert. Somit ist die Struktur 1034 eine Zuordnung für die Ähnlichkeitsgruppe A. Für jede Ähnlichkeitsgruppe werden die referenzierten Kompressionsregionen ausgelesen und eine Bestimmung darüber wird gemacht, ob sie ausreichend tot sind, um sie zu bereinigen, oder ob sie in ihrem aktuellen Zustand gelassen werden sollten. Während die Kompressionsregionen der Segmentfingerabdrücke ausgelesen werden, kann eine Zuordnung von Kompressionsregionsname zu Anzahl von aktiven Fingerabdrücken erzeugt werden. Die Bestimmung, ob jede Kompressionsregion bereinigt werden sollte, wird durch die Berechnung des Prozentanteils der Kompressionsregion, der aktiv ist, basierend auf der Anzahl von aktiven Fingerabdrücken und durch den Vergleich dieses Prozentanteils mit einem vordefinierten Schwellenwert (z.B. 85%), der als ausreichend aktiv innerhalb der Kompressionsregion angesehen wird, durchgeführt. Fällt der Prozentanteil an aktiven Fingerabdrücken in der Kompressionsregion unter den vordefinierten Schwellenwert, so wird die Kompressionsregion als reinigungswert angesehen. Der Schwellenwert kann angepasst werden, um die Nutzbarmachung von Raum zu priorisieren oder die IO-Kosten zu minimieren.
Für jede Kompressionsregion, die bereinigt wird, werden die aktiven Segmente kopiert, um neue Kompressionsregionen zu bilden. Sobald alle neuen Kompressionsregionen gebildet und in einer neuen Version der Ähnlichkeitsgruppe aufgezeichnet sind, wird die neue Version der Ähnlichkeitsgruppe gespeichert. Der Metadaten-Dienst wird benachrichtigt, die alten Ähnlichkeitsgruppen hinauszuwerfen und die neue Ähnlichkeitsgruppe hinzuzufügen. Schließlich werden die alten Ähnlichkeitsgruppen und Kompressionsregionen gelöscht. Dies entfernt die toten Segmente aus dem Objektspeicher.
Die Datenbereinigungsoperation kann als eine Teil- oder verzögerte Markierungs- und Sweep-Operation implementiert werden. Die Datenbereinigungsoperation beinhaltet das Bereinigen oder Entfernen von gelöschten Objekten von den aktiven Objekten. Wird ein Objekt gelöscht, so wird eine Aufzeichnung in einem Lösch-Bucket (oder einer anderen Struktur) aufgezeichnet. Die Aufzeichnungen in dem Lösch-Bucket werden später verwendet, wann immer die Datenbereinigungsoperation durchgeführt wird. Die Datenbereinigungsoperation kann in Phasen oder in aufeinander folgenden Vorgangsschritten arbeiten. Ausführungsformen der Erfindung sind eine konzentrierte Markierungs- und Sweep-Datenbereinigung, die sich auf Ähnlichkeitsgruppen konzentriert, die zumindest teilweise tote Segmente beinhalten kann.
Es versteht sich, dass die vorliegende Erfindung auf zahlreiche Weisen implementiert werden kann, einschließlich als ein Prozess, eine Apparatur, ein System, eine Vorrichtung, ein Verfahren oder ein computerlesbares Medium wie ein computerlesbares Speichermedium oder ein Computernetzwerk, in welchem Computerprogramminstruktionen über optische oder elektronische Kommunikationsverbindungen gesendet werden. Anwendungen können die Form von Software, die auf einem Universalrechner ausgeführt wird, annehmen oder in Hardware festverdrahtet oder festkodiert sein. In dieser Beschreibung können diese Implementierungen oder jede beliebige andere Form, die die Erfindung annehmen kann, als Techniken bezeichnet werden. Im Allgemeinen kann die Reihenfolge der Schritte der geoffenbarten Prozesse innerhalb des Umfangs der Erfindung verändert werden.
Die hierin geoffenbarten Ausführungsformen können die Verwendung eines Spezial- oder Universalrechners beinhalten, einschließlich verschiedener Computerhardware- oder -softwaremodule, wie dies nachfolgend ausführlicher erklärt ist. Ein Computer kann einen Prozessor und Computerspeichermedien beinhalten, die Instruktionen tragen, die, wenn sie von dem Prozessor ausgeführt werden oder veranlasst werden, von dem Prozessor ausgeführt zu werden, eines oder mehrere der hierin geoffenbarten Verfahren ausführen.
Wie oben angegeben ist, beinhalten Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung auch Computerspeichermedien, die physische Medien sind, um vom Computer ausführbare Instruktionen oder darauf gespeicherte Datenstrukturen zu tragen oder aufzuweisen. Solche Computerspeichermedien können beliebige verfügbare physische Medien sein, auf die von einem Universal- oder Spezialrechner zugegriffen werden kann.
Beispielhaft und ohne Einschränkung können solche Computerspeichermedien Hardware wie Solid-State-Disk (SSD), RAM, ROM, EEPROM, CD-ROM, Flash-Speicher, Phasenwechselspeicher („PCM“) oder anderen optischen Disk-Speicher, magnetischen Disk-Speicher oder andere magnetische Speichervorrichtungen oder beliebige andere Hardware-Speichervorrichtungen umfassen, die dazu verwendet werden können, Programmcode in der Form von vom Computer ausführbaren Instruktionen oder Datenstrukturen zu speichern, auf die von einem Universal- oder Spezialrechensystem zugegriffen werden kann oder von diesem ausgeführt werden kann, um die geoffenbarte Funktionalität der Erfindung zu implementieren. Kombinationen aus Obigem sollten ebenfalls innerhalb des Umfangs der Computerspeichermedien beinhaltet sein. Solche Medien sind Beispiele für nicht-flüchtige Speichermedien, und nicht-flüchtige Speichermedien umfassen auch cloudbasierte Speichersysteme und Strukturen, wenngleich der Umfang der Erfindung nicht auf diese Beispiele für nicht-flüchtige Speichermedien beschränkt ist.
Vom Computer ausführbare Instruktionen umfassen z.B. Instruktionen und Daten, die einen Universalrechner, einen Spezialrechner oder eine Spezialverarbeitungsvorrichtung veranlassen, eine gewisse Funktion oder Gruppe von Funktionen durchzuführen. Obwohl der Gegenstand in einer für strukturelle Merkmale und/oder methodologische Vorgänge spezifischen Sprache beschrieben wurde, ist zu verstehen, dass der in den angehängten Ansprüchen definierte Gegenstand nicht notwendigerweise auf die obig beschriebenen spezifischen Merkmale oder Vorgänge beschränkt ist. Vielmehr sind die hierin geoffenbarten spezifischen Merkmale und Vorgänge als beispielhafte Formen der Implementierung der Ansprüche geoffenbart.
Wie hierin verwendet, kann sich der Begriff „Modul“ oder „Komponente“ auf Software-Objekte oder -routinen beziehen, die auf dem Rechensystem ausgeführt werden. Die verschiedenen Komponenten, Module, Engines und Dienste, die hierin beschrieben sind, können als Objekte oder Prozesse implementiert werden, die auf dem Rechensystem z.B. als separate Threads ausgeführt werden. Während das hierin beschriebene System und die hierin beschriebenen Verfahren in Software implementiert werden können, sind auch Implementierungen in Hardware oder einer Kombination aus Software und Hardware möglich und vorgesehen. In der vorliegenden Offenbarung kann eine „Rechenentität“ ein beliebiges Rechensystem sein, wie es zuvor hierin definiert wurde, oder ein beliebiges Modul oder eine Kombination aus Modulen, die auf einem Rechensystem ablaufen.
In zumindest einigen Fällen ist ein Hardware-Prozessor bereitgestellt, der bedient werden kann, um ausführbare Instruktionen auszuführen, um ein Verfahren oder einen Prozess wie die hierin geoffenbarten Verfahren und Prozesse durchzuführen. Der Hardware-Prozessor kann ein Element einer anderen Hardware umfassen, so etwa die hierin geoffenbarten Rechenvorrichtungen und -systeme, oder auch nicht.
In Bezug auf Rechenumgebungen können die Ausführungsformen der Erfindung in Client-Server-Umgebungen, sei es nun Netzwerk- oder lokale Umgebungen, oder in einer beliebigen anderen geeigneten Umgebung durchgeführt werden. Geeignete Betriebsumgebungen für zumindest einige Ausführungsformen der Erfindung beinhalten Cloud-Rechenumgebungen, in welchen ein oder mehrere eines Client, Servers oder virtueller Zielmaschine in einer Cloud-Umgebung aufgenommen oder betrieben werden können.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt sein, ohne von ihrem Geist oder wesentlichen Charakteristiken abzuweichen. Die beschriebenen Ausführungsformen sind in jeder Hinsicht nur als veranschaulichend und nicht als einschränkend anzusehen. Der Umfang der Erfindung ist somit durch die angehängten Ansprüche und nicht nur die vorstehende Beschreibung angegeben. Alle Änderungen, die sich innerhalb der Bedeutung und des Äquivalenzbereichs der Ansprüche ergeben, sind innerhalb des Umfangs aufgenommen zu sein.

Claims

Verfahren zum Bereinigen von gelöschten Objekten aus einem Speichersystem, wobei das Verfahren umfasst: Erzeugen einer Mehrzahl von Workern, um eine Datenbereinigungsoperation durchzuführen, die die gelöschten Objekte, die in dem Speichersystem gespeichert sind, von den in dem Speichersystem gespeicherten Objekten bereinigt; Identifizieren von betroffenen Ähnlichkeitsgruppen, die von der Datenbereinigungsoperation betroffen sind, wobei die betroffenen Ähnlichkeitsgruppen Segmente beinhalten, die mit den gelöschten Objekten assoziiert sind, sowie Segmente, die mit aktiven Objekten assoziiert sind; Identifizieren von aktiven Segmenten in den betroffenen Ähnlichkeitsgruppen, die mit den aktiven Objekten assoziiert sind; Entfernen der mit den gelöschten Objekten assoziierten Segmente; Aktualisieren der betroffenen Ähnlichkeitsgruppen, um Segmente widerzuspiegeln, die mit den gelöschten Objekten assoziiert sind, die entfernt wurden.
Verfahren nach Anspruch 1, das ferner das Initiieren einer Steuerung umfasst, um die Datenbereinigungsoperation zu steuern, wobei die Steuerung die Mehrzahl von Workern steuert.
Verfahren nach Anspruch 1, wobei das Entfernen der mit den gelöschten Objekten assoziierten Segmente das Kopieren der mit den aktiven Objekten assoziierten Segmente in eine neue Struktur beinhaltet, so dass die neue Struktur nicht die Segmente speichert, die nicht mehr länger von den aktiven Objekten referenziert sind.
Verfahren nach Anspruch 3, das ferner das Löschen einer Struktur umfasst, die die mit den gelöschten Objekten assoziierten Segmente und die mit den aktiven Objekten assoziierten Segmente speichert, nachdem die neue Struktur abgeschlossen wurde.
Verfahren nach Anspruch 1, das ferner das Ermitteln durch die Steuerung einer Anzahl von Workern umfasst, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen.
Verfahren nach Anspruch 1, das ferner das Ermitteln der Anzahl von Workern durch Berücksichtigung eines oder mehrerer Faktoren, die eine Umgebungsvariable, die die Anzahl von Workern festlegt, eine Speicherzuteilung jedes Workers, eine Anzahl und/oder Größe von Ähnlichkeitsgruppen, die durch die Datenbereinigungsoperation betroffen sind, Eingabe/Ausgabe-Operationen oder Durchsatz beinhalten, umfasst.
Verfahren nach Anspruch 1, wobei ein Objektrezept Slice-Rezepte beinhaltet und jedes Slice-Rezept mit einer Ähnlichkeitsgruppe assoziiert ist, ferner umfassend das Zuweisen eines Bereichs von Ähnlichkeitsgruppen zu jedem der Mehrzahl von Workern.
Verfahren nach Anspruch 1, das ferner das Identifizieren der betroffenen Ähnlichkeitsgruppen und Teilgruppen umfasst.
Verfahren nach Anspruch 8, das ferner das Abrufen von Aufzeichnungen, die den gelöschten Objekten entsprechen, umfasst, wobei die Aufzeichnungen zumindest Obj ektrezepte für die betroffenen Ähnlichkeitsgruppen und Teilgruppen identifizieren und wobei die betroffenen Ähnlichkeitsgruppen aus mit den Objektrezepten assoziierten Slice-Rezepten identifiziert werden.
Verfahren nach Anspruch 8, das ferner das Aufzeichnen von Größen der betroffenen Ähnlichkeitsgruppen umfasst.
Verfahren nach Anspruch 1, das ferner das Schreibsperren von zumindest betroffenen Teilgruppen der betroffenen Ähnlichkeitsgruppen umfasst, um die normale Operation und die Datenbereinigungsoperation gleichzeitig zu unterstützen.
Nicht-flüchtiges computerlesbares Medium, das vom Computer ausführbare Instruktionen umfasst, die, wenn sie ausgeführt werden, das Verfahren von Anspruch 1 durchführen.
Verfahren zum Bereinigen von gelöschten Objekten aus einem deduplizierten Speichersystem, wobei das deduplizierte Speichersystem Objekte unter Verwendung eines Objekt-Rezepts speichert, das Slice-Rezepte referenziert, wobei die Slice-Rezepte Ähnlichkeitsgruppen referenzieren und wobei die Ähnlichkeitsgruppen Kompressionsregionen referenzieren, wobei Segmente von Objekten in dem Speichersystem in den Kompressionsregionen gespeichert sind, wobei das Verfahren umfasst: Durchführen einer Startup-Phase einer Datenbereinigungsoperation, um eine Steuerung zu instanziieren, wobei die Datenbereinigungsoperation unreferenzierte Segmente aus dem Speichersystem bereinigt; Ermitteln durch die Steuerung einer Anzahl von Workern, die erforderlich sind, um die Datenbereinigungsoperation durchzuführen, basierend auf einer Anzahl von betroffenen Ähnlichkeitsgruppen und der Worker-Kapazität; Bestimmen von betroffenen Ähnlichkeitsgruppen in dem Speichersystem, die mit den unreferenzierten Segmenten assoziiert sind, wobei die betroffenen Ähnlichkeitsgruppen mit den unreferenzierten Segmenten und mit aktiven Segmenten assoziiert sind; Markieren der aktiven Segmente in den betroffenen Ähnlichkeitsgruppen; Entfernen der unreferenzierten Segmente; und Aktualisieren der betroffenen Ähnlichkeitsgruppen, um widerzuspiegeln, dass die unreferenzierten Segmente, die mit den gelöschten Objekten assoziiert sind, entfernt wurden.
Verfahren nach Anspruch 13, das ferner das Entfernen der unreferenzierten Segmente durch Vorkopieren der aktiven Segmente aus einer bestehenden Kompressionsregion in eine neue Kompressionsregion umfasst, wobei die unreferenzierten Segmente in der bestehenden Kompressionsregion nicht in die neue Kompressionsregion kopiert werden.
Verfahren nach Anspruch 13, das ferner das Bestimmen der betroffenen Ähnlichkeitsgruppen basierend auf Löschaufzeichnungen umfasst.
Verfahren nach Anspruch 15, wobei die Löschaufzeichnungen in einem Lösch-Bucket des Speichersystems gespeichert werden und wobei die Löschaufzeichnungen zumindest ein Objekt-Rezept beinhalten.
Verfahren nach Anspruch 16, das ferner das Bestimmen der betroffenen Ähnlichkeitsgruppen basierend auf Slice-Rezepten umfasst, die in dem Objekt-Rezept beinhaltet sind oder von diesem referenziert sind.
Verfahren nach Anspruch 13, das ferner das Partitionieren der betroffenen Ähnlichkeitsgruppen zu den Workern umfasst, wobei jeder Worker einen Bereich der betroffenen Ähnlichkeitsgruppen basierend zumindest teilweise auf angenommenen Größen und Identifikatoren der betroffenen Ähnlichkeitsgruppen empfängt.
Verfahren nach Anspruch 13, das ferner das Schreibsperren der betroffenen Ähnlichkeitsgruppen umfasst, so dass die Datenbereinigungsoperation und die normalen Operationen nebeneinander erfolgen können.
Nicht-flüchtiges computerlesbares Medium, das vom Computer ausführbare Instruktionen beinhaltet, um das Verfahren von Anspruch 13 durchzuführen.