DE112019006530T5

DE112019006530T5 - Markieren von betroffenen ähnlichkeitsgruppen in freispeichersammeloperationen in duplizierten speichersystemen

Info

Publication number: DE112019006530T5
Application number: DE112019006530.0T
Authority: DE
Inventors: Kimberly R. Lu; Joseph S. Brandt; Nicholas A. Noto; Tipper Truong; Mariah Arevalo; Philip Shilane
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-03-29
Filing date: 2019-12-17
Publication date: 2021-09-23
Also published as: GB2594222B; IE87454B1; US20200310964A1; GB202110973D0; GB2594222A; US11392490B2; IE20190233A1; CN113574498A; WO2020205015A1

Abstract

Systeme und Verfahren zum Markieren von Ähnlichkeitsgruppen, die von einer Freispeichersammeloperation betroffen sind, werden offenbart. Ähnlichkeitsgruppen werden verwendet, um Segmente zu identifizieren, die Objekten in einem Rechensystem zugeordnet sind. Unter Verwendung von Löschprotokollen, die zu löschende Objekte identifizieren, können die Ähnlichkeitsgruppen identifiziert werden, die von den Löschprotokollen betroffen sind. Die lebenden Segmente, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, werden ebenfalls identifiziert. Dies ermöglicht die Entfernung von Segmenten, die den gelöschten Objekten zugeordnet sind und keinem lebenden Objekt zugeordnet sind.

Description

Gebiet der Erfindung
Ausführungsformen der Erfindung betreffen Systeme, Vorrichtungen und Verfahren zur Ausführung von Datenschutzoperationen wie die Freispeichersammlung. Insbesondere betreffen Ausführungsformen der Erfindung Systeme und Verfahren zur Freispeichersammlung in einem deduplizierten Speichersystem, wie einem deduplizierten Cloud-basierten Speichersystem. Insbesondere betreffen Ausführungsformen der Erfindung Systeme und Verfahren zum Markieren oder Identifizieren von Datenobjekten oder Ähnlichkeitsgruppen, die von Datenschutzoperationen wie Freispeichersammeloperationen betroffen sind.
HINTERGRUND
Daten zu schützen ist ein grundlegender Aspekt der heutigen Computertechnologien. Wenn Daten nicht geschützt sind, ist die Wahrscheinlichkeit höher, dass Daten verloren gehen, und der Verlust von Daten kann einer Organisation erheblichen Schaden zufügen. Daher speichern viele Organisationen ihre Daten oder Backups ihrer Daten in einem Speichersystem, wie z. B. einem Cloud-basierten Speichersystem. Daten zu schützen ist jedoch aufgrund der damit verbundenen Kosten und aufgrund der Anforderungen und Richtlinien, die für die Daten gelten oder mit ihnen zusammenhängen, wesentlich komplexer als einfach eine Datenkopie in der Cloud zu speichern. Backups unterliegen beispielsweise häufig Backup-Richtlinien (z. B. tägliche, wöchentliche, monatliche Erstellung von Backups) und Aufbewahrungsrichtlinien. Das führt zu einer erheblichen Mengen von Daten, was sowohl in Bezug auf den Speicherbedarf als auch den Rechenbedarf entsprechende Kosten verursacht, selbst wenn die Daten dedupliziert sind.
Aus verschiedenen Gründen werden Backups im Allgemeinen im Laufe der Zeit gelöscht. Beispielsweise kann ein System ein Backup löschen, wenn eine Aufbewahrungsfrist abläuft. Das Löschen eines Backups ist keine triviale Aufgabe, insbesondere bei deduplizierten Speichersystemen. In deduplizierten Systemen werden Daten häufig in Blöcke oder Segmente aufgeteilt und in deduplizierter Form gespeichert. Dies verringert den Speicherbedarf (und die Kosten), indem die gleichen Blöcke oder Segmente für mehrere Backups oder mehrere Objekte verwendet werden können.
Es ist unvermeidlich, dass einige der im Datenschutzsystem gespeicherten Daten oder Objekte tot sind. Tote Objekte oder Daten werden nicht referenziert oder werden von einem Client oder Speichersystem nicht mehr benötigt. Bei Ablaufen von Backups oder aus anderen Gründen führen Backup-Systeme Freispeichersammeloperationen durch, um Objekte zu löschen oder zu entfernen, die keine der gültigen Backups mehr referenzieren. Dies kann jedoch nicht durch einfaches Löschen der Segmente eines toten Objekts erreicht werden, da dieselben Segmente zu einem lebenden Objekt gehören können. Darüber hinaus sind herkömmliche Ansätze wie Referenzzählungen unhandlich, da sie erfordern können, dass das Schutzsystem Milliarden von Zählungen behält. Referenzzählungen verbrauchen daher erheblichen Speicherplatz und sind sehr schwer zu verwalten, insbesondere in verteilten und Cloud-basierten Systemen.
Figurenliste
Um die Art und Weise zu beschreiben, wie zumindest einige Aspekte dieser Offenbarung erreicht werden können, folgt eine genauere Beschreibung unter Bezugnahme auf bestimmte Ausführungsformen davon, die in den beiliegenden Zeichnungen veranschaulicht sind. Mit dem Hinweis, dass diese Zeichnungen lediglich beispielhafte Ausführungsformen der Erfindung zeigen und daher nicht als Einschränkung ihres Schutzumfangs zu sehen sind, werden Ausführungsformen der Erfindung mithilfe der beiliegenden Zeichnungen genauer und mit mehr Detail beschrieben und erläutert, wobei:

1A ein Beispiel für eine Art und Weise zum Speichern von deduplizierten Daten in einem Speichersystem, wie z. B. einem Cloud-basierten Speichersystem, zeigt;
1B ein Beispiel für gespeicherte Daten vor dem Reinigen und nach dem Reinigen in einem Speichersystem, wie z. B. einem Cloud-basierten Speichersystem, zeigt;
1C ein Beispiel für ein Schutzsystem zeigt, das konfiguriert ist, um Datenschutzoperationen, welche die Freispeichersammlung umfassen, in einem Speichersystem, wie z. B. einem Cloud-basierten Speichersystem, auszuführen;
2 ein Beispiel für einen Objektspeicher-Bucket und einen Lösch-Bucket zur Verwendung durch ein Schutzsystem zum Reinigen des Objektspeichers zeigt;
3 einen Vorgang des Verschiebens eines Objekts vom Objektspeicher-Bucket in den Lösch-Bucket als Vorbereitung zur Ausführung von Freispeichersammeloperationen zeigt;
4 ein Beispiel für ein Verfahren zur Ausführung einer Datenschutzoperation wie Freispeichersammlung zeigt;
5 ein Beispiel für eine Anlaufphase einer Freispeichersammeloperation zeigt, in der die Worker und Worker-Kapazitäten geschätzt werden;
6 ein Beispiel für ein Verfahren zum Schätzen einer Anzahl an Workern basierend auf den Ähnlichkeitsgruppen zeigt, die von dem Freispeichersammelvorgang betroffen sind;
7 ein Beispiel für Faktoren zeigt, die gegebenenfalls berücksichtigt werden, wenn die Anzahl an Workern geschätzt wird, die für einen Freispeichersammelvorgang notwendig sind;
8A und 8B Beispiele für die Verarbeitung von Ähnlichkeitsgruppen zeigen, die das Markieren von betroffenen Ähnlichkeitsgruppen während der Ausführung eines Freispeichersammelvorgangs zeigt;
9 ein Beispiel für eine Ähnlichkeitsgruppe und zugehörige Untergruppen zeigt, die den gleichen Identifikator aufweisen wie die Ähnlichkeitsgruppe;
10 ein Beispiel für eine Markierung von lebenden Segmenten als Vorbereitung für eine Übertragungsphase des Freispeichersammelvorgangs zeigt;
11A-11C Systeme und Verfahren zum gleichzeitigen Ausführen von Freispeichersammeloperationen und normalen Systemoperationen zeigen;
12A und 12B ein Beispiel für ein Verfahren zum Löschen eines oder mehrerer Objekte aus einem Speichersystem wie einem deduplizierten Speichersystem zeigen; und
13 ein Beispiel für ein Verfahren zum Markieren von Ähnlichkeitsgruppen oder insbesondere zum Markieren oder Identifizieren von Segmenten, die im Speichersystem behalten werden sollen, und Segmenten, die aus dem Speichersystem entfernt werden sollen, zeigt.

AUSFÜHRLICHE BESCHREIBUNG EINIGER BEISPIELHAFTER
AUSFÜHRUNGSFORMEN
Ausführungsformen der Erfindung betreffen Systeme, Geräte und Verfahren zur Bereitstellung oder Ausführung von Datenschutzoperationen. Beispiele für Datenschutzoperationen umfassen ohne Einschränkung Backup-Operationen, Wiederherstellungsoperationen, Deduplizierungsoperationen, Replizierungsoperationen und/oder Freispeichersammeloperationen. Eine Freispeichersammeloperation wird beispielsweise ausgeführt, um ein Speichersystem von toten Objekten oder von nichtreferenzierten Objekten zu bereinigen. Anders gesagt wird eine Freispeichersammeloperation ausgeführt, um Objekte aus einem Speichersystem zu entfernen, die von einem Client nicht länger gebraucht werden oder nicht länger von einem lebenden Objekt referenziert werden oder ein Teil davon sind. Das Löschen eines Objekts in einem deduplizierten Speichersystem ist kompliziert, weil Segmente, die einem gelöschten Objekt zugeordnet sind, nicht sofort aus dem Speichersystem entfernt werden können, da einige der Segmente des gelöschten Objekts gegebenenfalls anderen lebenden Objekten zugeordnet sind. Ein lebendes Objekt kann ohne Einschränkung ein Objekt sein, das im Speichersystem behalten werden sollte. Ein totes Objekt ist ein Objekt, das verworfen oder aus dem Speichersystem entfernt werden kann. Ein Objekt kann Daten, Akten, Datensätze wie Backup-Datensätze, einzelne Dateien oder dergleichen oder eine Kombination davon repräsentieren. Die hierin erläuterten Datenschutzoperationen können in einem System wie einer DELL EMC Data Domain ausgeführt werden, die Cloud-Implementierungen umfasst.
Ausführungsformen der Erfindung betreffen Freispeichersammeloperationen, die Datenintegrität sicherstellen, keine finanziellen Kosten verursachen, wenn sie nicht laufen, und skalierbar sind, um Leistungs- und/oder zeitliche Einschränkungen zu erfüllen. Außerdem unterstützen Ausführungsformen der Erfindung gleichzeitiges Lesen/Schreiben, während die Freispeichersammlung ausgeführt wird. Ausführungsformen der Erfindung vereinfachen außerdem Schwierigkeiten in Verbindung mit Kodier- und Fehlerbeseitigungsaktivitäten.
In einem Beispiel kann ein Cloud-basiertes Datenschutzsystem (Schutzsystem) als Microservice- oder Container-basierte Anwendung implementiert sein und kann konfiguriert sein, um in einer Cloud-Umgebung zu laufen. Genauer gesagt kann die Freispeichersammlung als Microservice implementiert sein, der ein Speichersystem von Objekten reinigt, die von Clients oder gemäß den Aufbewahrungsrichtlinien gelöscht wurden, um nichtreferenzierte Segmente (oder andere Datenrepräsentationen oder -strukturen) aus dem Speichersystem zu löschen, ohne lebende Segmente zu beeinflussen. Das Schutzsystem kann in Containern laufen und das Schutzsystem kann je nach Bedarf vergrößert oder verkleinert werden. Komponenten des Schutzsystems können als Microservice implementiert sein.
Ausführungsformen der Erfindung verbessern den Betrieb eines Datenschutzsystems, einschließlich von Operationen, die vom Datenschutzsystem ausgeführt werden, indem sichergestellt wird, dass nichtreferenzierte Daten nicht unnötigerweise Speicherplatz verbrauchen, und indem sichergestellt wird, dass die nichtreferenzierten Daten keine Rechenressourcen verbrauchen. Genauer gesagt wird das Datenschutzsystem durch die Entfernung von toten Objekten nicht damit belastet, Daten verarbeiten zu müssen, die nicht referenziert sind. Das eliminiert einen Teil der Verarbeitung und verbessert so den Betrieb des Datenschutzsystems. Außerdem basieren die Speicherkosten, beispielsweise von Cloudbasierter Speicherung, häufig auf der gespeicherten Datenmenge. Durch die Ausführung der Freispeichersammlung können tote Objekte oder Segmente entfernt werden.
In manchen Cloud-Systemen fallen auch Kosten für den Verbrauch von Rechenressourcen an. Ausführungsformen der Erfindung sparen Rechenressourcen zumindest dadurch, dass Rechenressourcen für die Freispeichersammeloperation nur dann zugewiesen und genutzt werden, während die Freispeichersammeloperation ausgeführt wird. Wenn die Freispeichersammeloperation nicht läuft, können die Rechenressourcen freigegeben werden. In einem Beispiel kann das Schutzsystem Objekte deduplizieren, indem die Objekte in Tranchen und Segmente aufgeteilt oder zusammengefasst werden (sehr große Objekte können in Teile aufgeteilt werden, die in Tranchen aufgeteilt werden, die in Segmente aufgeteilt werden).
1A veranschaulicht ein Beispiel dafür, wie Objekte in einem Cloud-basierten Speichersystem gespeichert werden können. 1A veranschaulicht einen Objektspeicher 48, der ein Objektspeicher-Bucket sein kann. Der Speicher kann auch auf andere Weise repräsentiert oder konfiguriert sein. Die tatsächlichen Daten (die Segmente) eines Objekts, das einem Objekt-Recipe 50 zugeordnet ist, werden in Kompressionsregionen gespeichert, z. B. in Kompressionsregionen 60, 66, 68 und/oder 70. So können Segmente eines Objekts, die dem Objekt-Recipe 50 zugeordnet sind, in einer oder mehreren der Kompressionsregionen 60, 66, 68 und 70 gespeichert werden.
Die Kompressionsregion 60 kann Segmente 64 und Fingerprints 62 dieser Segmente 64 enthalten. Die anderen Kompressionsregionen 66, 68 und 70 sind ähnlich konfiguriert. In diesem Beispiel ist die Ähnlichkeitsgruppe 56 mehreren Kompressionsregionen zugeordnet, einschließlich der Kompressionsregionen 60 und 66. Auf ähnliche Weise ist die Ähnlichkeitsgruppe 58 den Kompressionsregionen 68 und 70 zugeordnet.
Die Ähnlichkeitsgruppe 56 kann eine oder mehrere Untergruppen aufweisen oder solchen zugeordnet sein, die als Untergruppe 56-1 bis Untergruppe 56-n dargestellt sind. Wie dargestellt enthält die Ähnlichkeitsgruppe 58 auf ähnliche Weise Untergruppen 58-1 bis 58-n. In diesem Beispiel werden die Ähnlichkeitsgruppe 56 und die Untergruppe 56-1 jeweils als Objekt gespeichert. Die anderen Untergruppen werden auf ähnliche Weise gespeichert. Jede Untergruppe kann den gleichen Ähnlichkeitsgruppen-Identifikator (ID) aufweisen wie die entsprechende Ähnlichkeitsgruppe und die Untergruppen können unterschiedlich nummeriert sein (z. B. in aufsteigender Reihenfolge). Die Ähnlichkeitsgruppe 56 identifiziert die Kompressionsregionsnamen und zugeordneten Fingerprints, die einem Objekt zugeordnet sind. Genauer gesagt können die Kompressionsregionen bestimmten Untergruppen zugeordnet sein. Das Tranchen-Recipe 52 identifiziert die Ähnlichkeitsgruppe und die Untergruppe für eine Tranche eines zugeordneten Objekts. In einem Beispiel ist jede Tranche einer einzigen Ähnlichkeitsgruppe zugeordnet. Das Objekt-Recipe 50 identifiziert die Tranchen eines Objekts.
In einem Beispiel umfasst die Ähnlichkeitsgruppe 56 eine Untergruppe. Mit anderen Worten ist ein Objekt einer Ähnlichkeitsgruppe und einer Untergruppe zugeordnet. Beispielsweise kann eine Ähnlichkeitsgruppe als Objekt mit einer Gruppen-ID und einer Untergruppen-ID gespeichert werden, aber niemals ohne die Untergruppen-ID. 1A veranschaulicht, dass die Ähnlichkeitsgruppe 56 und die zugeordneten Untergruppen als separate Objekte gespeichert werden können. Die Recipes der Objekte identifizieren jedoch üblicherweise jede aus einer Ähnlichkeitsgruppe, einer Untergruppe und von Kompressionsregionen.
1A veranschaulicht im Wesentlichen ein einzelnes Objekt und dass das Objekt in zwei Tranchen aufgeteilt wurde. In diesem Beispiel umfasst jede Tranche etwa 8 MB. Das Objekt-Recipe 50 identifiziert alle Tranchen des Objekts. Somit wird das Objekt-Recipe 50 erzeugt, wenn ein zugeordnetes Objekt in einem Speichersystem gespeichert wird, und wird verwendet, um das Objekt wieder zusammenzustellen, wenn das Objekt aus dem Speichersystem gelesen wird. Der Objektspeicher 48 kann eine Vielzahl von Objekten auf diese Weise umfassen. Außerdem können das Objekt-Recipe 50, die Tranchen-Recipes 52, 54, die Ähnlichkeitsgruppen 56, 58 und die Kompressionsregionen alle unabhängige Objekte im Objektspeicher 48 sein. In diesem Beispiel identifiziert das Tranchen-Recipe 52 für das Objekt die Ähnlichkeitsgruppe 56:Untergruppe 56-1 und das Tranchen-Recipe 54 identifiziert die Ähnlichkeitsgruppe 58:Untergruppe 58-n. Jede Untergruppe kann mehreren Kompressionsregionen zugeordnet sein oder solche identifizieren (z. B. Segmente 3, 4 und 5 in Kompressionsregion 60 und Segmente 1 und 2 in Kompressionsregion 66 (abhängig vom Recipe).
Während der Deduplizierung kann ein Objekt in Tranchen aufgeteilt werden und die Tranchen können weiter in Segmente aufgeteilt oder gruppiert werden. Die Größe der Tranchen und Gruppierungen sind konfigurierbar. Lediglich beispielhaft kann ein Objekt in 8-MB-Tranchen aufgeteilt werden. Jede der Tranchen kann in 8-KB-Segmente aufgeteilt werden. Um eine Deduplizierung auszuführen wird jede Tranche in eine Ähnlichkeitsgruppe gemappt. Die Ähnlichkeitsgruppe kann basierend auf dem Inhalt der Tranche oder basierend auf einer Funktion bestimmt werden, die auf den Inhalt der Tranche angewandt wird. Da eine Tranche in eine Ähnlichkeitsgruppe gemappt wird, können die Segmente oder der Inhalt der Tranche, die dedupliziert wird, schon in der Ähnlichkeitsgruppe vorhanden sein. Lediglich beispielhaft kann eine Tranche nur in Bezug auf die Ähnlichkeitsgruppe und in Bezug auf eine bestimmte Untergruppe der Ähnlichkeitsgruppe dedupliziert werden.
Beispielsweise kann ein Objekt-Recipe eine Tranche identifizieren. Das Tranchen-Recipe kann die Ähnlichkeitsgruppe und die Untergruppe identifizieren. Die Kompressionsregionen sind in der identifizierten Ähnlichkeitsgruppe und Untergruppe enthalten oder diesen zugeordnet. Während der Deduplizierung können einzigartige Fingerprints in Kompressionsregionen an die Untergruppe 1 angehängt werden. Sobald die Untergruppe 1 eine Schwellengröße erreicht, wird eine Untergruppe 2 erzeugt. Neue Fingerprints und Kompressionsregionen für die Ähnlichkeitsgruppe werden dann zur Untergruppe 2 hinzugefügt, weil die Untergruppe 1 voll ist. Weitere Untergruppen werden nach Bedarf hinzugefügt.
Im Allgemeinen wird eine Deduplizierung ausgeführt, indem Fingerprints von Segmenten verglichen werden, die in den Speicher mit den Fingerprints von Segmenten geschrieben werden sollen, die schon vom Schutzsystem gespeichert wurden. Ein Fingerprint ist ein Identifikator eines Segments (z. B. ein Hash des Segments) und kann in Systemen implementiert werden, in denen die Daten unverschlüsselt oder verschlüsselt sind.
Im Zusammenhang mit einer Ähnlichkeitsgruppe werden Fingerprints der Segmente von einer eingehenden Tranche als Duplikate markiert, wenn die Fingerprints der eingehenden Segmente mit beliebigen Fingerprints der Segmente übereinstimmen, die schon in der Ähnlichkeitsgruppe gespeichert sind. Wenn die Fingerprints der Segmente der eingehenden Tranche mit keinen der vorhandenen Fingerprints für die Ähnlichkeitsgruppe übereinstimmen, dann werden diese Segmente als neu erachtet und in der Ähnlichkeitsgruppe gespeichert.
1B veranschaulicht das Ergebnis einer Freispeichersammeloperation. Während der Freispeichersammlung kann bestimmt werden, dass ein gelöschtes Objekt die Segmente 82, 84 und 86 enthält und dass diese Segmente in der Kompressionsregion 80 enthalten sind. Es kann auch bestimmt werden, dass die Segmente 82 und Segmente 86 einem anderen lebenden Objekt zugeordnet sind. Somit sind die Segmente 82 und 86 lebende Segmente, während das Segment 84 tot ist und durch kein anderes Recipe referenziert wird. Nach der Identifizierung der lebenden und toten Segmente wird die Kompressionsregion 80 bereinigt, indem nur die lebenden Segmente in die neue Kompressionsregion 88 geschrieben (z. B. übertragen) werden. Die Kompressionsregion 80 kann dann gelöscht werden. So wird die Ähnlichkeitsgruppe, die der Kompressionsregion 80 zugeordnet ist, von toten Segmenten bereinigt und die neue Kompressionsregion 88 enthält nur die Segmente der Kompressionsregion 80, die lebenden Objekten zugeordnet wurden. In manchen Objekt-Speichersystemen ist es gegebenenfalls nicht möglich, ein vorhandenes Objekt zu modifizieren, sodass die Kompressionsregion 80 nicht direkt geändert werden kann. Stattdessen wird während der Freispeichersammlung eine neue Kompressionsregion 88 mit den lebenden Segmenten erzeugt. Die neue Kompressionsregion 88 kann denselben Namen haben wie die Kompressionsregion 80, in welchem Fall die Kompressionsregion 80 nicht gelöscht werden muss, da sie ersetzt wird. In einem Beispiel werden basierend auf ihrem Inhalt einzigartige Namen für die Kompressionsregionen erzeugt. In einem Beispiel kann ein Metadatenserver verwendet werden, um die Ähnlichkeitsgruppen zu verwalten oder die Fingerprints allgemein zu verwalten. Der Metadatenserver kann beispielsweise Beziehungen zwischen Fingerprints, Segmenten, und/oder Ähnlichkeitsgruppen speichern. Der Metadatenserver kann alle Fingerprints aller Segmente speichern, die vom Schutzsystem verwaltet werden. Während der Deduplizierung und/oder der Freispeichersammlung kann der Metadatenserver abgefragt werden, um zu bestimmen, ob ein Segment oder eine Gruppe von Segmenten einzigartig, dupliziert oder lebend ist. Wenn beispielsweise eine Tranche zu einer Ähnlichkeitsgruppe hinzugefügt wird, kann eine Abfrage an den Metadatenserver unter Verwendung der Fingerprints der Segmente in der Tranche, die hinzugefügt wird, durchgeführt werden, um zu bestimmen, ob irgendwelche der Segmente Duplikate sind. Einzigartige Segmente werden zur Ähnlichkeitsgruppe hinzugefügt und duplizierte Segmente werden vermerkt. Häufig wird eine Deduplizierung nur in Bezug auf Fingerprints ausgeführt, die der Ähnlichkeitsgruppe und einer bestimmten Untergruppe der Ähnlichkeitsgruppe zugeordnet sind.
1C veranschaulicht ein Beispiel für eine Rechenumgebung oder ein Schutzsystem, die/das Datenschutzoperationen einschließlich Freispeichersammlung ausführt. 1C veranschaulicht ein Schutzsystem 100 (oder ein Beispiel für ein Speichersystem für deduplizierte Objekte) und einen Objektspeicher 120. Das Schutzsystem 100 kann eine containerisierte Implementierung eines Datenschutzsystems sein und kann Microservices umfassen. In einem Beispiel kann das Schutzsystem 100 in einer Kubernetes-Umgebung implementiert sein. Der Objektspeicher 120 kann ein Cloud-basiertes Speichersystem sein, beispielsweise eines, das in einem Datenzentrum gehosted wird. Der Objektspeicher 120 kann in einer lokalen Umgebung in einer privaten Cloud vorhanden sein. Das System 100 und/oder der Objektspeicher 120 können verteilt sein und können skalierbar sein.
Der Objektspeicher 120 ist konfiguriert, um Objekte oder Daten zu speichern. Das System 100 ist konfiguriert, um das Objekt oder die Daten in deduplizierter Form zu speichern, obwohl die Deduplizierung in einigen Situationen gegebenenfalls nicht 100 % ist. Objekte können wie zuvor beschrieben im Objektspeicher 120 gespeichert werden. So kann der Objektspeicher 120 ein Objekt-Recipe 122 umfassen, das einem Tranchen-Recipe 124, einer Ähnlichkeitsgruppe 128 (und Untergruppe) und Kompressionsregionen 126 zugeordnet ist.
Das Schutzsystem 100 kann Kundenzugriffsserver 102 umfassen. Kundenzugriffsserver 102 können ein Frontend 104 und ein Backend 106 umfassen. Das Frontend 104 und das Backend 106 können Microservices sein, die unter Verwendung von zugewiesenen Rechenressourcen laufen (Prozessoren, Arbeitsspeicher und andere erforderliche Hardware-Komponenten). Das Frontend 104 kann eine Schnittstelle zu Kunden bereitstellen. Objekte können durch das Frontend 104 empfangen werden. Unter Verwendung des Frontends 104 kann ein Benutzer oder Client in der Lage sein, Objekte anzusehen, Objekte hinzuzufügen, Objekte zu löschen, Datenschutzoperationen wie Backup-Operationen zu konfigurieren und Operationen wiederherzustellen oder dergleichen oder ein Kombination davon. In einigen Beispielen kann das Schutzsystem 100 ein Logikkonstrukt zwischen den Clients und den tatsächlichen Daten anordnen.
Das Frontend 104 kann auch dafür verantwortlich sein, ein Objekt in Tranchen zu unterteilen. Das Backend 106 kann konfiguriert sein, um verschiedene Operationen an Daten oder Objekten auszuführen. Sobald ein Objekt in Tranchen unterteilt wurde (was auch vom Backend 106 ausgeführt werden kann), kann das Backend 106 dafür verantwortlich sein, Hashes zu berechnen und ein Objekt-Recipe, Tranchen-Recipe und dergleichen zu bilden, das im Objektspeicher 120 gespeichert werden kann. Das Backend 106 kann auf den Metadatenserver 108 zugreifen, um Ähnlichkeitsgruppen für die Tranchen zu identifizieren. Das Backend 106 kann die Objekt-Recipes erzeugen oder bestimmen und mit dem Metadatenserver 108 kommunizieren.
Im Zusammenhang mit der Freispeichersammlung kann die Freispeichersammlung als Job konfiguriert sein, der regelmäßig oder laut einem Zeitplan läuft. Wenn die Freispeichersammlung abgeschlossen ist, können die zur Ausführung der Freispeichersammlung verwendeten Ressourcen freigegeben werden. So ist es möglich, dass die Ressourcen nur dann genutzt werden, wenn sie benötigt werden, und freigegeben werden, wenn sie nicht benötigt werden. Dies verringert vorteilhafterweise die Kosten im Vergleich zu Lösungen, die keine Rechenressourcen freigeben.
Freispeichersammlung - Überblick
Die Freispeichersammlung wird von einem Controller 110 (z. B. einem Server oder einem Knoten in der Rechenumgebung) geregelt oder gesteuert. Der Controller 110 kann einen oder mehreren Knoten wie Worker 112 und Worker 114 steuern, um die Freispeichersammlung auszuführen.
Das Datenschutzsystem 100 führt die Freispeichersammlung durch, indem es nichtreferenzierte oder tote Segmente aus dem Objektspeicher 120 entfernt oder löscht. Obwohl auf Segmente Bezug genommen wird, versteht sich, das Ausführungsformen der Erfindung mit anderen Datenrepräsentationen arbeiten können.
Indem Segmente aus dem Objektspeicher 120 entfernt werden, werden vorteilhafterweise Kosten und Rechenkosten verringert. Ausführungsformen der Erfindung berücksichtigen auch die Tatsache, dass dem Schutzsystem 100 in einem Cloud-Speichersystem nicht der Speicherplatz ausgeht. Dies ermöglicht etwas Spielraum bei Freispeichersammeloperationen, wenn Freispeicher gesammelt wird, und ermöglicht es dem Schutzsystem 100, bei Objekten zu warten, die teilweise am Leben sind (z. B. einigen Segmenten zugeordnet sind, die einem anderen Objekt zugeordnet sind). Außerdem können Rechenkosten, die typischerweise höher sind als Speicherkosten, niedrig gehalten oder verringert werden, indem teilweise lebende Objekte für eine bestimmte Zeit gespeichert werden. Beispielsweise kann eine Kompressionsregion lebende und tote Segmente umfassen. Wenn die Anzahl an toten Segmenten gering ist, kann es vorteilhafter sein zu warten, bis der Prozentsatz an toten Segmenten eine Schwelle überschreitet, bevor die Kompressionsregion bereinigt wird. Ausführungsformen der Erfindung weisen auch Rechenressourcen (z. B. Worker-Knoten) basierend auf dem Arbeitsvolumen, das ausgeführt werden muss, und basierend auf den Ressourcen, die zur Ausführung der Freispeichersammeloperation erforderlich sind, und/oder basierend auf Einschränkungen wie Arbeitsspeichereinschränkungen, IO-Einschränkungen, Durchsatzeinschränkungen oder dergleichen zu.
In einem Beispiel werden Lösch-Buckets verwendet, um die Freispeichersammlung auszuführen. Ein Lösch-Bucket speichert Protokolle, die Objekten entsprechen, die gelöscht wurden oder nie abgeschlossen (z. B. zum Teil geschrieben) wurden. Wenn der Freispeichersammelvorgang ausgeführt ist, werden die Protokolle im Lösch-Bucket verarbeitet.
In der folgenden Erläuterung geht es um Buckets. Ein Bucket ist eine allgemeine Repräsentation von zumindest einem Teil eines Speichersystems. Objekte können in einem Objektspeicher-Bucket gespeichert werden. Wenn ein von einem Client geschriebenes Objekt gelöscht wird oder wenn ein Objekt aus einem anderen Grund gelöscht wird, wird ein Löschprotokoll für das gelöschte Objekt zu einem Lösch-Bucket hinzugefügt. Ein Löschprotokoll kann das vom Client geschriebene Objekt auf beliebige Weise identifizieren, z. B. durch das Recipe des Objekts. In einem Beispiel enthält das Löschprotokoll eventuell nur den Namen des Objekts (der Name kann ausreichen, um das Recipe zu identifizieren). Somit kann das Löschprotokoll einige Informationen über das Objekt enthalten. Das ermöglicht die Identifikation der relevanten Segmente während der Freispeichersammeloperation. Das Recipe kann die Ähnlichkeitsgruppen und die Kompressionsregionen identifizieren, die dem Objekt zugeordnet sind. Die Menge oder Art von Daten, die im Löschprotokoll gespeichert sind, können somit variieren. Unter Verwendung der Löschprotokolle können der Controller 110 und die Worker 112, 114 alle der betroffenen Ähnlichkeitsgruppen (jene, die gegebenenfalls tote Segmente enthalten) unter Verwendung der Löschprotokolle identifizieren und den Objektspeicher 120 bereinigen.
Die betroffenen Ähnlichkeitsgruppen (oder spezifische Untergruppen) können schreibgeschützt sein, sodass sich eingehende Objekte nicht auf die Ähnlichkeitsgruppen/Untergruppen auswirken, die bereinigt werden. Um sicherzustellen, dass der Schreibzugriff während einer Freispeichersammeloperation erhalten bleibt, können nach Bedarf neue Untergruppen zu den betroffenen Ähnlichkeitsgruppen hinzugefügt werden. Jegliche Objekte, die während einer Freispeichersammeloperation in den Objektspeicher 120 geschrieben werden, können in Bezug auf die neuen und/oder nicht betroffenen Ähnlichkeitsgruppen oder in Bezug auf Ähnlichkeitsgruppen oder Untergruppen, die nicht schreibgeschützt sind, dedupliziert werden.
In einem Beispiel wird das Arbeitsvolumen des Vorgangs zur Freispeichersammlung in Teile unterteilt (häufig auf Ähnlichkeitsgruppenbasis) und den Workern zugeteilt. Nachdem identifiziert wurde, welche der Ähnlichkeitsgruppen und Untergruppen von der Freispeichersammlung betroffen sind, können der Controller 110 und/oder die Worker 112, 114 lebende Fingerprints in ihren entsprechenden Ähnlichkeitsgruppen identifizieren und markieren. Beispielsweise kann ein Objekt, das gelöscht wurde, aus den 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 enthalten. In diesem Fall können die Fingerprints (oder Identifikatoren, wie z. B. ein Hash) der Segmente 1, 2, 3, 6 und 7 als lebend markiert werden. Die Segmente 4 und 5 werden gelöscht.
Lebende Segmente in der Ähnlichkeitsgruppe/Untergruppe (insbesondere in einer Kompressionsregion) werden dann in neue Kompressionsregionen übertragen. Wenn beispielsweise eine Kompressionsregion die Segmente 1, 2, 3, 4 und 5 enthielt, würde die neue Kompressionsregion die Segmente 1, 2 und 3 enthalten. Die alte Kompressionsregion, welche die Segmente 4 und 5 enthielt, wird entfernt oder gelöscht. So werden die ungenutzten oder nichtreferenzierten Segmente 4 und 5 aus dem Objektspeicher 120 bereinigt. Der Schreibschutz kann dann aufgehoben werden.
Freispeichersammlung
2-4 zeigen Aspekte einer Freispeichersammeloperation und eines Schutzsystems, das die Freispeichersammlung ausführt. In der folgenden Erläuterung wird die Bezeichnung Bucket verwendet, um zu beschreiben, wie Objekte und Protokolle gespeichert werden. Die Objekte und Protokolle können jedoch auch in anderen Strukturen wie Containern, einer Datenbank oder dergleichen gespeichert werden. Im Objektspeicher können Clients ihre Objekte in 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) Präfix-String oder auf andere Weise aufgelistet sein. In einem Beispiel kann eine Indirektionsschicht, wie z. B. ein Logik-Bucket 262, zwischen Clients 260 und dem Bucket 230 implementiert sein. Die Clients 260 können mit dem Logik-Bucket 262 interagieren. String-Manipulationen können an den verschiedenen Bucket-Namen durchgeführt werden, bevor der darunterliegende Objektspeicher-Bucket 230 abgefragt wird.
In 2 und als Beispiel kann das Speichersystem einen Objektspeicher-Bucket 230 (oder mehrere Buckets) und einen Lösch-Bucket 220 umfassen. Während der Freispeichersammeloperation kann ein Controller 210 (der Controller kann basierend auf einem Zeitplan oder auf Abruf instanziiert werden) einen oder mehrere Worker (z. B. den Worker 212 und den Worker 214) erzeugen und jedem der Worker 212, 214 einen Teil der auszuführenden Arbeit zuordnen. In einem Beispiel kann jedem Worker eine Reihe von Ähnlichkeitsgruppen zugeordnet werden. In einem Beispiel können der Controller 210 und die Worker 212 und 214 als Pods implementiert sein.
Der Controller 210 (und/oder die Worker) können bestimmen, welche Ähnlichkeitsgruppen von der Freispeichersammeloperation betroffen sind. Diese Bestimmung basiert beispielsweise auf Protokollen, die im Lösch-Bucket 250 enthalten sind. Wie zuvor angegeben kann es aufgrund der Deduplizierung unpraktisch sein, alle Segmente, die einem Objekt zugeordnet sind, zu dem Zeitpunkt zu löschen, an dem ein Client das Objekt löscht. Stattdessen konzentriert sich die Freispeichersammeloperation auf die Strukturen, welche die gelöschten Objekte referenzieren. Wenn ein Client ein Objekt aus dem Objektspeicher 230 löscht oder wenn ein Objekt aus einem anderen Grund gelöscht wird, kann das Objekt-Recipe des Objekts entfernt (z. B. in den Lösch-Bucket 220 verschoben) werden und ist gegebenenfalls für den Client nicht sichtbar.
In diesem Beispiel enthält der Objektspeicher-Bucket 230 Objekt X und Objekt Y. Das Objekt X hat ein Objekt-Recipe 232. Der Einfachheit halber wird eine einzelne Tranche für jedes der Objekte X (Tranche 246) und Y (Tranche 248) angenommen. Die Tranche 246 von Objekt X ist einer Ähnlichkeitsgruppe 234 (genauer gesagt Ähnlichkeitsgruppe A, Untergruppe 1) zugeordnet. Die Segmente des Objekts X werden physisch in Kompressionsregionen 236 (genauer gesagt Kompressionsregionen 3 und 4) gespeichert. Auf ähnliche Weise weist das Objekt Y ein Objekt-Recipe 240 auf und ist einer Ähnlichkeitsgruppe 242 (genauer gesagt Ähnlichkeitsgruppe A, Untergruppe 1) und Kompressionsregionen 244 (Kompressionsregionen 3 und 4) zugeordnet. Dies zeigt, dass Kompressionsregionen und Ähnlichkeitsgruppen von mehreren Objekt-Recipes referenziert werden können, um eine Deduplizierung zu vermeiden.
Ein Client kann das Objekt X löschen. Wenn das Objekt X von einem Client oder gemäß Aufbewahrungsrichtlinien oder aus einem anderen Grund gelöscht wird, wird das Objekt-Recipe 232 aus dem Objektspeicher-Bucket 230 entfernt und kann im Lösch-Bucket 250 gespeichert werden.
3 veranschaulicht diesen Vorgang und zeigt, dass ein Löschprotokoll 252, das dem Objekt entspricht, dem das Objekt-Recipe 232 zugeordnet ist, in den Lösch-Bucket 250 gegeben wurde. Das Löschprotokoll 252 kann Daten 254 und/oder einen Zeitstempel 258 umfassen. In einem Beispiel entsprechen die Daten 254 dem Objekt-Recipe 232. Als Folge ist das Objekt X für den Client 260 nicht länger sichtbar. Der Name des Objekts X kann im Lösch-Bucket 250 als Daten 254 protokolliert werden, anstatt das Objekt-Recipe 232 zu kopieren. Diese Informationen (z. B. Objekt-Recipe 232, Objektname usw.) sind ein Beispiel für ein Löschprotokoll 252. Der Lösch-Bucket 250 wird dann während der Freispeichersammlung verwendet, um den Objektspeicher-Bucket 230 zu bereinigen.
Zusätzlich zu Objekten, die explizit von Clients gelöscht werden oder aufgrund von Richtlinien wie Aufbewahrungsrichtlinien gelöscht werden, bereinigen oder löschen Ausführungsformen der Erfindung auch Objekte, die nur zum Teil geschrieben sind oder die vor dem Abschließen aufgegeben wurden. Ein zum Teil geschriebenes Objekt ist gegebenenfalls für den Client nicht sichtbar und folglich wird der Client dieses Objekt nicht löschen. Es ist jedoch nützlich, den von dieser Art von Objekten eingenommenen Platz freizumachen.
In einem Beispiel entspricht der Lösch-Bucket 252 einem laufenden Schreibvorgang. Somit wird das Löschprotokoll 252 für den laufenden Schreibvorgang in den Lösch-Bucket 250 eingegeben. Das Löschprotokoll 252 wird aus dem Lösch-Bucket 250 entfernt, wenn der Schreibvorgang abgeschlossen ist. Während der Schreibvorgang läuft, kann ein Zeitstempel 258, der im Löschprotokoll 252 enthalten ist, aktualisiert werden. Insbesondere stellt der Zeitstempel 258 einen Modifikationszeitstempel dar, der identifiziert, wann das Objekt in Bearbeitung zuletzt modifiziert wurde. Der Zeitstempel 258 kann in Zeitabständen aktualisiert werden, während das Objekt geschrieben wird, beispielsweise alle zehn Minuten.
Wenn die Freispeichersammlung ausgeführt wird, werden Objekte in Bearbeitung bereinigt oder entfernt, wenn der Zeitstempel 258 älter als eine Schwelle ist. Mit anderen Worten wird, wenn in dem Objekt in Bearbeitung für eine Schwellenzeitdauer nicht geschrieben wurde, das Objekt in Bearbeitung gelöscht, da es von Client aufgegeben wurde. Dies kann einen Vorgang umfassen, der vom Objekt-Recipe abhängt, wie hierin erläutert ist, um das Objekt in Bearbeitung zu identifizieren und aus dem Objektspeicher-Bucket 230 zu entfernen.
4 veranschaulicht ein Beispiel für eine Freispeichersammeloperation. In einem Beispiel wird die Freispeichersammeloperation in Phasen ausgeführt. Das Verfahren kann mit einer Anlaufphase 402 beginnen, in der der Controller instanziiert wird und die Worker zugeordnet oder instanziiert werden. Ein Teil der Zuordnung von Workern kann das Bestimmen der Anzahl an Workern umfassen, die zur Ausführung der Freispeichersammeloperation erforderlich sind. Die Anlaufphase 402 ist in 5 genauer dargestellt.
5 veranschaulicht ein Beispiel für eine Anlaufphase. Die Anlaufphase beginnt typischerweise durch Initiieren oder Instanziieren 502 eines Controllers. Wenn beispielsweise die Zeit für die Ausführung einer Freispeichersammeloperation erreicht ist, wird ein Job (z. B. einen Cronjob) erzeugt und der Controller wird instanziiert. Der Controller kann in einem Cluster wie einem Kubernetes-Cluster erzeugt werden.
Sobald der Controller instanziiert ist, schätzt 504 der Controller die Anzahl an Workern, die erforderlich ist, um die Freispeichersammeloperation auszuführen. Das Schätzen 504 der Anzahl an Workern kann das Bestimmen 506 oder Identifizieren von Ähnlichkeitsgruppen umfassen, die von der Freispeichersammeloperation betroffen sind. Dies kann bestimmt werden, indem die Löschprotokolle bewertet werden. Die Anzahl an Workern wird auch durch das Schätzen 508 der Kapazität jedes der Worker beeinflusst. Außerdem kann diese Schätzung verschiedene Einschränkungen berücksichtigen, die für das Schutzsystem gelten, einschließlich Arbeitsspeicher, Input/Output (IO), IO-Operationen oder Durchsatz.
Das Schätzen 504 der Anzahl an Workern kann auf unterschiedliche Arten erreicht werden. In einem Beispiel kann die Anzahl an Workern über eine Umgebungsvariable festgelegt werden. Eine Umgebungsvariable kann für Test-, Fehlerbeseitigungs- und Leistungsvergleichszwecke nützlich sein. Die Verwendung einer Umgebungsvariable unterstützt auch die Bewertung von Szenarien, die gegebenenfalls nicht berücksichtigt oder vorausgesehen wurden, mit komplexeren Schätzungsmethoden. Die Umgebungsvariable kann basierend auf vergangener Leistung oder aus anderen Gründen aktualisiert werden.
Wie zuvor angemerkt, kann die auszuführende Arbeit durch die Anzahl von betroffenen Ähnlichkeitsgruppen beeinflusst werden. Als Folge kann die Anzahl an betroffenen Ähnlichkeitsgruppen bestimmt 506 werden, wenn die Anzahl an Workern geschätzt wird, die verwendet werden soll.
6 veranschaulicht ein Beispiel für ein Verfahren zum Schätzen der Anzahl an Workern, die zur Ausführung der Freispeichersammeloperation erforderlich ist. In einem Beispiel werden Maps zur Dimensionierung erzeugt 602. Die Maps helfen dabei, den Platz oder Arbeitsspeicherplatz zu identifizieren, der erforderlich ist, damit ein Worker die Freispeichersammlung ausführen kann. In einem Beispiel wird die Freispeichersammeloperation den Workern basierend auf Ähnlichkeitsgruppen zugewiesen - jeder Worker ist für eine Reihe von Ähnlichkeitsgruppen verantwortlich. Diese Reihen sind jedoch nicht gleich. Beispielsweise können die Worker jeweils einer Reihe von Ähnlichkeitsgruppen zugeordnet sein, um basierend auf der Größe der betroffenen Ähnlichkeitsgruppen zu bereinigen.
Die Maps können eine Ähnlichkeitsgruppenmap für jede Untergruppe einer Ähnlichkeitsgruppe und eine Ähnlichkeitsgesamtmap umfassen, um die Gesamtgröße des erforderlichen Arbeitsspeichers für alle betroffenen Ähnlichkeitsgruppen nachzuverfolgen. Nachdem die Maps erstellt wurden, werden die Protokolle der gelöschten Objekte aus dem Lösch-Bucket gelesen 604. Die Protokolle werden geparst oder bewertet, um die Tranchen zu identifizieren oder aufzulisten 606, die den gelöschten Objekten im Lösch-Bucket zugeordnet sind. Die Ähnlichkeitsgruppen-Identifikatoren können aus der Liste von Tranchen erhalten werden, die aus den Löschprotokollen identifiziert wurden. Gemäß einer Benennungskonvention umfasst der Name jedes Tranchen-Recipes den Namen der Ähnlichkeitsgruppe und der Untergruppe, die das Tranchen-Recipe referenziert. Die Ähnlichkeitsgruppen-Identifikatoren, die aus den Löschprotokollen erhalten wurden, können in die Maps eingefügt werden und die Größen werden berechnet. In einer Implementierung wird die Größe der <Ähnlichkeitsgruppe, Untergruppe> sofort überprüft. In einer anderen Implementierung wird der Ähnlichkeitsgruppen-Identifikator in einer Map gespeichert und eine separate Auflistung enthält alle Ähnlichkeitsgruppen und Untergruppen gemeinsam mit ihren Größen und die erforderlichen Größen werden in den Maps gespeichert. So werden die betroffenen Ähnlichkeitsgruppen und ihre Größen in der Ähnlichkeitsgruppenmap und in der Ähnlichkeitsgesamtmap protokolliert. Die Größe der Map wird berechnet und beispielsweise verwendet, wenn die Arbeit auf die Worker aufgeteilt wird.
In diesem Beispiel bezieht sich die Größe auf die Bits, die erforderlich sind, um die betroffenen Ähnlichkeitsgruppen in einem Arbeitsspeicher zu repräsentieren. Somit kann jeder Ähnlichkeitsgruppe und Untergruppe eine Größe zugeordnet werden. Alle Größen von Untergruppen von Ähnlichkeitsgruppen werden in der Gesamtmap zusammengezählt und die Gesamtgröße kann bestimmt werden. Unter Verwendung der Größe kann jedem Worker eine Reihe von Ähnlichkeitsgruppen zugeordnet werden, die effektiv verarbeitet werden können. In einer Ausführungsform werden alle Untergruppen einer Ähnlichkeitsgruppe demselben Worker zugeordnet, um die Bestimmung zu vereinfachen, welcher Worker welche Ähnlichkeitsgruppen und Untergruppen handhabt. Die Maps können beispielsweise unter Verwendung von Hashtabellen implementiert werden. Die Größe jeder Ähnlichkeitsgruppe und Untergruppe kann sich auf die Größe in einem Objektspeicher oder auf die Anzahl an Bits (oder Bytes) beziehen, die zur Repräsentation der Fingerprints der Ähnlichkeitsgruppe unter Verwendung einer Hashtabelle, eines Bloom-Filters oder eines perfekten Hashvektors erforderlich sind.
Nachdem die Ähnlichkeitsgruppen und ihre Größen protokolliert wurden, können die Ähnlichkeitsgruppen untergliedert 610 werden. Beispielsweise kann eine Ähnlichkeitsgesamtmap von der niedrigsten Ähnlichkeitsgruppen-ID zur höchsten Ähnlichkeitsgruppen-ID sortiert werden. Der Vorgang kann durch die Map iteriert werden und Ähnlichkeitsgruppen-IDs einem Worker zuordnen, bis die Größe der aktuell zugeordneten Ähnlichkeitsgruppe zu groß für den Worker ist. In diesem Fall endet die Untergliederung und eine Untergliederung für den nächsten Worker wird bestimmt. Die aktuelle Zuordnung ordnet alle Untergruppen einer Ähnlichkeitsgruppe einem Worker zu und nachfolgende Ähnlichkeitsgruppen-Identifikatoren werden einem Worker zugeordnet, obwohl auch andere Zuordnungsmethoden möglich sind. Die Löschprotokolle können dann entfernt 612 werden. Der Inhalt der Löschprotokolle kann die Operation der Bestimmung der Anzahl von betroffenen Ähnlichkeitsgruppen beeinflussen. Wenn beispielsweise die Löschprotokolle ein Objekt-Recipe oder einen Namen des Objekts enthalten, würde das die Identifikation der Anzahl an betroffenen Tranchen ermöglichen und eine Obergrenze für die Anzahl an betroffenen Ähnlichkeitsgruppen bereitstellen. Dies kann auch die Zeit verringern, die erforderlich ist, um die einzigartigen Ähnlichkeitsgruppen zu zählen, die durch die gelöschten Protokolle referenziert werden, weil die Auflistung der Tranchen eine möglicherweise kostengünstige Objektspeicheroperation ermöglicht.
Im Zusammenhang mit der Schätzung der Anzahl an Workern für die Freispeichersammeloperation kann die Anzahl an Workern auch von der Worker-Kapazität abhängen. Die Kapazität kann vom Arbeitsspeicher, von IO-Operationen, vom Durchsatz und dergleichen abhängen. Diese Faktoren können auch in den Bestimmungsvorgang der Anzahl an Workern für den Freispeichersammelvorgang eingeschlossen werden.
Der dem oder den Knoten zugewiesene Arbeitsspeicher, auf dem die Worker laufen, kann begrenzt oder eingeschränkt sein und kann berücksichtigt werden, wenn die Anzahl an Worker für die Freispeichersammeloperation geschätzt wird. In dieser Situation kann die Anzahl an Workern geschätzt werden, indem die Arbeitskapazität eines Workers basierend auf seiner Arbeitsspeicherzuweisung geschätzt wird.
Beispielsweise können die Worker durch den Arbeitsspeicher eingeschränkt sein. Eine Ähnlichkeitsgruppe referenziert eine oder mehrere Kompressionsregionen, die jeweils ein Segment oder über 1.000 Segmente aufweisen können, jedes mit einer Größe von etwa 8 KB. Eine Ähnlichkeitsgruppe protokolliert mit jedem Kompressionsregionsnamen, den es referenziert, die Liste der Fingerprints und die Segmentgrößen, die den Segmenten in den Kompressionsregionen entsprechen. Ein Worker führt ein Protokoll für jeden Fingerprint für jede Ähnlichkeitsgruppe und Untergruppe, die dem Worker zugeordnet ist, so dass er die Lebendigkeit jedes Segments bestimmen kann, das von diesen Ähnlichkeitsgruppen referenziert wird. Die Gesamtgröße von Untergruppen von Ähnlichkeitsgruppen ist derzeit auf 8 MB beschränkt. Die Arbeitskapazität (oder Anzahl an Ähnlichkeitsgruppen, die der Worker verarbeiten kann) für jeden Worker kann wie folgt bestimmt oder geschätzt 508 werden: $\frac{Arbeitsspeicher des Worker-Knoten}{8 MB}$
In einer weiteren Erweiterung können anstelle der Protokollierung von Fingerprints in einer Hashtabelle für jede Ähnlichkeitsgruppe und Untergruppe die Fingerprints in einem Bloomfilter protokolliert werden. Das verringert den Arbeitsspeicherbedarf von 8 MB pro Ähnlichkeitsgruppe auf etwa 400 KB, weil ein Bloomfilter eine Kompaktsatz-Mitgliedsstruktur ist. Ein perfekter Hashvektor könnte anstelle eines Bloomfilters verwendet werden, der den Arbeitsspeicherbedarf auf etwa 130 KB verringern würde.
Sobald die Worker-Kapazität pro Worker und die Gesamtanzahl an betroffenen Ähnlichkeitsgruppen berechnet wurde, kann die Anzahl an Workern, die für die Freispeichersammeloperation erforderlich ist, wie folgt berechnet werden: $⌈ \frac{Anzahl an betroffenen Ähnlichkeitsgruppen}{Anzahl an Ähnlichkeitsgruppen, die jeder Worker verarbeiten kann} ⌉$
In einer weiteren Erweiterung können, anstatt davon auszugehen, dass alle Ähnlichkeitsgruppen die maximal mögliche Größe von 8 MB aufweisen, die Größen der Ähnlichkeitsgruppen und Untergruppen vom Controller in der Berechnung des zur Darstellung der Fingerprints der Ähnlichkeitsgruppen und Untergruppen erforderlichen Arbeitsspeichers innerhalb eines Workers bestimmt werden. Diese Größe wird basierend auf der ausgewählten Repräsentation, z. B. als Hashtabelle, Bloomfilter oder perfekter Hashvektor, modifiziert. Diese Größe wird zusammengezählt und durch das Ausmaß an Arbeitsspeicher dividiert, die jeder Worker haben kann, um die Anzahl an zuzuweisenden Worker zu bestimmen.
In einem anderen Beispiel können die Freispeichersammeloperation oder Aspekte des Schutzsystems durch IO (Eingabe/Ausgabe-Operationen) eingeschränkt sein und diese Einschränkung kann sich auch auf die Anzahl an Workern auswirken, die für die Freispeichersammeloperation erforderlich ist. In diesem Beispiel kann die Anzahl an Workern auf eine Weise bestimmt werden, die die den Worker-Knoten zugewiesenen IOs effizient oder am besten nutzt.
In einem Beispiel können die IOs, die den Knoten zugewiesen sind, auf denen die Worker-Pods laufen, mit der Zeitdauer kombiniert werden, welche die Freispeichersammeloperation laufen gelassen wird. Um das Ausmaß an IO-Operationen zu schätzen, die während einer Freispeichersammeloperation stattfinden, können die Arten von IOs, die im Schutzsystem stattfinden, differenziert werden. Beispielsweise gibt es IO-Operationen, die Druck-Logs, dem Senden von RPC-Calls zwischen Diensten und Calls an Objektspeicher zugeordnet sind. Von diesen Arten von IO-Operationen dominiert die Latenz zum Objektspeicher. Dies ermöglicht es Ausführungsformen der Erfindung, sich auf Objektspeicher-Calls alleine zu fokussieren, um eine Schätzung für alle IO-Operationen zu erhalten.
In einem Beispiel wird die Anzahl an IO-Operationen, die zur Bereinigung einer einzelnen Ähnlichkeitsgruppe erforderlich ist, geschätzt oder bestimmt. Es kann 1 IO-Operation erforderlich sein, um eine Ähnlichkeitsgruppe auszulesen, 1 IO-Operation, um eine Ähnlichkeitsgruppe zu schreiben, und 1 IO-Operation, um jede Kompressionsregion auszulesen. Wenn die Kompressionsregionen bereinigt werden, ist es möglich, 2 Lesevorgänge von Kompressionsregionen pro 1 geschriebene Kompressionsregion anzunehmen. Das ist ein Verhältnis von 2:1 für das Lesen zum Schreiben von Kompressionsregionen. Als Nächstes folgen Lösch-Calls an die alten Kompressionsregionen, die etwa demselben als Anzahl an IO-Operationen zugeordnet sind wie die Anzahl an Lesevorgängen von Kompressionsregionen.
Es kann eine Annahme über die Anzahl von Kompressionsregionen getroffen werden, die pro Ähnlichkeitsgruppe referenziert wird. Beispielsweise kann eine Ähnlichkeitsgruppe etwa 8 MB Werte enthalten, um Tranche-Identifikatoren zu identifizieren. Eine Tranche mit ~8 MB umfasst etwa 1024 8-KB-Segmente. Unter der Annahme, dass 50 Prozent dieser Segmente während der Deduplizierung entfernt werden, werden etwa 512 Segmente in jede Kompressionsregion eingegeben oder geschrieben. Jede von einer Ähnlichkeitsgruppe referenzierte Kompressionsregion hat einen Namen und eine gewissen Anzahl an Fingerprint-Referenzen (20 Byte für SHAI-Hash und 4 Byte für Größe). Daher benötigt jeder Segment-Fingerprint 24 Byte. Folglich benötigt eine Kompressionsregion etwa 512 * 24 = 12.288 Byte in einer Ähnlichkeitsgruppe. Bei ~8 MB bedeutet eine Ähnlichkeitsgruppe dividiert durch 12.288 Byte, dass eine Ähnlichkeitsgruppe -683 Kompressionsregionen referenzieren kann. Es kann auch notwendig sein, die Tranchen zu berücksichtigen, die während der Phase „Markierung von lebenden Fingerprints“ gelesen werden. Als Schätzung kann sinnvollerweise angenommen werden, dass es einen Tranche-Lesevorgang pro Kompressionsregion gibt.
Diese Informationen ermöglichen die Schätzung der Anzahl an IO-Operationen, die zur Bereinigung einer Ähnlichkeitsgruppe erforderlich ist, wie folgt: $\begin{array}{l} 1 (z u m A u s l e s e n d e r Ä h n l i c h k e i t s g r u p p e n) + \\ 683 (z u m A u s l e s e n v o n K o m p r e s s i o n s r e g i o n e n) + \\ 683 (z u m A u s l e s e n v o n T r a n c h e n) + 1 (z u m S c h r e i b e n v o n Ä h n l i c h k e i t s g r u p p e n) + \\ 342 (z u m S c h r e i b e n v o n K o m p r e s s i o n s r e g i o n e n) + \\ 683 (z u m L ö s c h e n v o n K o m p r e s s i o n s r e g i o n e n) + \\ 1 (z u m L ö s c h e n v o n a l t e n Ä h n l i c h k e i t s g r u p p e n) = 2.394 IO - Operationen \end{array}$
Nach dem Schätzen der gesamten IO-Operationen, die zum Bereinigen einer Ähnlichkeitsgruppe erforderlich sind, ist es notwendig, die betroffenen Ähnlichkeitsgruppen während der Laufzeit zu zählen, um zu bestimmen, wie viele IO-Operationen erforderlich sind, um alle betroffenen Ähnlichkeitsgruppen zu bereinigen. Die Schätzung der Anzahl an IO-Operationen kann basierend auf der Größe der Ähnlichkeitsgruppen und Untergruppen eingestellt werden. Ähnlichkeitsgruppen und Untergruppen, die kleiner als die vollen 8 MB oder kleiner als die definierte Maximalgröße sind, erfordern weniger IO-Operationen als das angeführte Beispiel.
Sobald die Gesamtzahl an IO-Operationen bestimmt oder geschätzt wurde, kann die Anzahl an Workern basierend auf den Leistungsmerkmalen der Worker-Knoten bestimmt werden, welche die mögliche IOPS für den jeweiligen Knoten vorgeben, zusammen mit der gewünschten Dauer zur Beendigung des Durchlaufs zur Freispeichersammlung. In einem Beispiel sind die IO-Operationen typischerweise durch die Netzwerkkarte, die CPU oder den Prozessor und dergleichen beschränkt. Unter Verwendung einer Offline-Analyse in einem Beispiel kann die Anzahl an IOPS, die pro Vorgang unterstützt werden kann, bestimmt werden und wird als Eingabe in die Berechnung verwendet.
Mit diesen Informationen kann die Anzahl an Workern wie folgt geschätzt werden: $⌈ \frac{Gesamte \frac{I}{O} -Oprerationen}{\begin{matrix} IOPS pro Knoten * Zeit zur Beeingung eines Durchlaufs zum \\ Sammeln von Datenmüll in Sekunden \end{matrix}} ⌉$
In einem anderen Beispiel können diese Verfahren durch Ändern einiger Annahmen eingestellt werden. In einem Beispiel können Zähler verwendet werden, um IO-Operationen während einer Freispeichersammeloperation nachzuverfolgen. Dies ermöglicht eine Aktualisierung der Zählung von IO-Operationen in einer Konfigurationsdatei, die während nachfolgender Freispeichersammeloperationen verwendet werden kann. Dies ist ein Beispiel für eine Rückmeldeschleife, die eine Verbesserung der Genauigkeit der Schätzung der IO-Operationen basierend auf vorherigen Daten ermöglicht.
Mit diesen Informationen kann die Anzahl an Workern geschätzt werden und der Controller kann das Generieren der Worker beenden. 7 veranschaulicht Beispiele für Faktoren, die bei der Bestimmung oder Schätzung der Anzahl an Workern verwendet werden können. Das Schätzen der Worker 702 kann von Faktoren abhängen, die eine oder mehrere aus einer Umgebungsvariable 704, einem Worker-Arbeitsspeicher 706, betroffenen Ähnlichkeitsgruppen 708 und/oder IO-Operationen 710 umfassen.
Es versteht sich, dass das Schätzen der Anzahl an Workern eine oder mehrere dieser Merkmale in einer beliebigen Kombination verwenden kann. In einem weiteren Beispiel kann die Anzahl an Workern unter Verwendung jedes Merkmals und der minimalen, durchschnittlichen oder maximalen Anzahl an Workern, die für jedes Merkmal geschätzt werden, zugewiesen werden. In einem Beispiel kann sich die Freispeichersammeloperation auf das Bereinigen von Ähnlichkeitsgruppen und Kompressionsregionen fokussieren, die von den Ähnlichkeitsgruppen referenziert werden. Da die Ähnlichkeitsgruppen eine ID in einem gegebenen Bereich (z. B. 0 bis 4 Milliarden) aufweisen, können die Ähnlichkeitsgruppen gleichmäßig (basierend auf der Anzahl und/oder den angenommenen Größen) über die Worker aufgeteilt werden. Die Aufteilungen können in einer Tabelle protokolliert werden, die zwischen dem Controller und den Workern geteilt wird. Der Controller und die Worker können miteinander beispielsweise unter Verwendung von RPC-Calls (Remote Procedure Calls) kommunizieren.
Auf 4 zurückkommend können die betroffenen Ähnlichkeitsgruppen nach der Anlaufphase 402 markiert 404 werden. Um zu wissen, welche Datenstrukturen aus dem Objektspeicher-Bucket bereinigt werden sollen, werden die Löschprotokolle analysiert, um die Tranchen-Recipes und betroffenen Ähnlichkeitsgruppen zu analysieren, die den Löschprotokollen zugeordnet sind. Da Ähnlichkeitsgruppen Tranchen zugeordnet sind, ermöglicht das Identifizieren der Tranchen das Markieren oder Identifizieren der assoziierten Ähnlichkeitsgruppen.
8A veranschaulicht ein Beispiel für die Verarbeitung von Ähnlichkeitsgruppen. In einem Beispiel kann der Controller, nachdem er initiiert wurde (und bevor die Worker instanziiert werden), die Löschprotokolle evaluieren, um die betroffenen Ähnlichkeitsgruppen zu identifizieren, die Größen der betroffenen Ähnlichkeitsgruppen/Untergruppen zu bestimmen und Worker-Zuweisungen vorzubereiten.
8A veranschaulicht, dass ein Controller auf die Löschprotokolle zugreift 802. Die Löschprotokolle ermöglichen es dem Controller, die Tranchen-Recipes abzurufen oder auf diese zuzugreifen 804. Da die Tranchen-Recipes jeweils einer bestimmten Ähnlichkeitsgruppe zugeordnet sind, können die betroffenen Untergruppen identifiziert werden und ihre Größe kann bestimmt werden 806. Die Größe jeder betroffenen Untergruppe kann angenommen oder tatsächlich bestimmt werden. Wenn die betroffenen Ähnlichkeitsgruppen und die Größe der Ähnlichkeitsgruppen und betroffenen Untergruppen bestimmt werden, können verschiedene Größe gespeichert werden. Beispielsweise können die Größe jeder betroffenen Untergruppe, die Größe einer betroffenen Ähnlichkeitsgruppe und die Größe aller betroffenen Ähnlichkeitsgruppen gespeichert werden.
Basierend auf den Größen und/oder der Anzahl der betroffenen Ähnlichkeitsgruppen kann der Controller Worker-Zuordnungen vorbereiten 808. Mit anderen Worten werden die Ähnlichkeitsgruppen untergliedert und den Workern zugeordnet. Diese Zuordnungen oder Untergliederungen weisen effektiv jedem der geplanten Worker eine Gruppierung von Ähnlichkeitsgruppen zu. Mit anderen Worten kann der Controller die erforderliche Anzahl an Workern schätzen und Zuordnungen für jeden dieser Worker vorbereiten. Die Ähnlichkeitsgruppen können basierend auf der Größe gleichmäßig verteilt werden, sodass die Anzahl an Ähnlichkeitsgruppen, die jedem Worker zugeordnet wird, variieren kann, oder dergleichen. Alternativ dazu können die Ähnlichkeitsgruppen so verteilt werden, dass ihre Größe für jeden Worker etwa gleich ist.
Als Nächstes werden die Worker instanziiert und die Zuordnungen werden vorgenommen 810. In diesem Beispiel können die Worker mit dem Controller kommunizieren, um ihre zugeordnete Liste von Ähnlichkeitsgruppen und Untergruppen zu erhalten. Basierend auf den zugeordneten Größen kann der Worker eine Mapping-Struktur erzeugen, um die Fingerprints der Segmente nachzuverfolgen. So können die lebenden Segmente identifiziert werden, damit die lebenden Segmente übertragen werden können.
8B veranschaulicht ein weiteres Beispiel zur Identifizierung oder Markierung von betroffenen Ähnlichkeitsgruppen. Die Löschprotokolle werden abgerufen oder empfangen 820 (z. B. als Liste), beispielsweise vom Controller. Der Controller kann dann einen Call (z. B. einen RPC-Call) an einen der Worker basierend auf der zugeordneten Ähnlichkeitsgruppe ausgeben, sodass der Worker zumindest einen Teil der Löschprotokollliste empfängt.
Die Tranchen-Recipes werden aus den Löschprotokollen abgerufen 822 oder aufgelistet. Der Worker ruft 822 dann die Tranchen-Recipes für die gelöschten Objekte und zugeordneten Ähnlichkeitsgruppen ab. Die Worker sind üblicherweise für das Bereinigen der Tranchen-Recipes, die in den Löschprotokollen identifiziert sind, aus dem Objektspeicher verantwortlich. Genauer gesagt umfasst der Name jedes Tranchen-Recipes die Ähnlichkeitsgruppen, die von den einzelnen Tranchen-Recipe referenziert werden.
Das ermöglicht es dem Worker, die Ähnlichkeitsgruppe zu markieren 824, solange die Ähnlichkeitsgruppe in den Umfang von Ähnlichkeitsgruppen fällt, die dem Worker zugeordnet sind. Wenn eine Ähnlichkeitsgruppe nicht in den dem Worker zugeordneten Umfang von Ähnlichkeitsgruppen fällt, kann der Worker einen Call an einen geeigneten Worker vornehmen, sodass der angerufenen Worker die Ähnlichkeitsgruppe markieren kann.
Als Teil der Markierung können die Ähnlichkeitsgruppen/Untergruppen gemappt und ihre Größe kann bestimmt werden 826. Mit anderen Worten kann ein Mapping erzeugt werden, das die betroffenen Ähnlichkeitsgruppen mit Größen mappt. Genauer gesagt führt diese Operation oder dieser Vorgang zu einem Mapping von betroffenen Ähnlichkeitsgruppen mit Datenstrukturen, die lebende Segmente, die Anzahl an lebenden Tranchen und die Anzahl an lebenden Segmenten enthalten, die in nachfolgenden Phasen verwendet werden, einschließlich der Phasen des Markierens von lebenden Fingerprints 408 und des Übertragens 410.
Die Freispeichersammlung kann ein zeitintensiver Vorgang sein. Folglich werden, nachdem die Ähnlichkeitsgruppen markiert wurden 404, die betroffenen Ähnlichkeitsgruppen wie in 4 gezeigt schreibgeschützt 406. Damit Clients normale Operationen ausführen können, werden somit betroffene Ähnlichkeitsgruppen schreibgeschützt. So kann die Freispeichersammeloperation gleichzeitig oder simultan mit normalen Operationen verarbeitet werden.
Beispielsweise kann sich die Freispeichersammeloperation auf eine Ähnlichkeitsgruppe auswirken, die Gegenstand einer normalen Schreiboperation ist. Dies kann zur Entfernung von Segmenten führen, die eine Schreiboperation referenziert oder Anderes betrifft. Dies wird durch Schreibschützen von betroffenen Ähnlichkeitsgruppen verhindert.
Genauer gesagt können, um Verzögerungen zu verringern und gleichzeitige Schreiboperationen zu ermöglichen, die Ähnlichkeitsgruppen Untergruppen umfassen. Typischerweise sind normale Schreiboperationen auf die höchstnummerierte Untergruppe gerichtet (z. B. weil die anderen Untergruppen voll sind). Wenn die höchstnummerierte Untergruppe in einer Ähnlichkeitsgruppe zur Bereinigung markiert ist, wird eine neue Untergruppe zur Ähnlichkeitsgruppe für eingehende Schreibvorgänge hinzugefügt. Folglich referenzieren keine eingehenden Schreiboperationen eine betroffene Ähnlichkeitsgruppe und diese Operationen können gleichzeitig ausgeführt werden.
9 veranschaulicht ein Beispiel für betroffene zugehörige Untergruppen, die derselben Ähnlichkeitsgruppe zugeordnet sind. Wie in 9 dargestellt ist jede der Untergruppen 1, N und N+1 derselben Ähnlichkeitsgruppe 902 zugeordnet und jede Untergruppe kann ein eindeutiges Objekt sein. Die Ähnlichkeitsgruppe 902, die eine ID A aufweist, kann auch ein Objekt im Speicher 900 sein. Jede der Untergruppen 1, N und N+1 hat dieselbe Ähnlichkeitsgruppen-ID A, die die Untergruppen der Ähnlichkeitsgruppe 902 zuordnet.
9 veranschaulicht auch den Vorgang des Hinzufügens einer neuen Untergruppe, wenn die höchstnummerierte Untergruppe vom Freispeichersammelvorgang betroffen ist. In diesem Beispiel ist die Untergruppe N die höchstnummerierte Untergruppe. Wenn die Untergruppe N eine betroffene Untergruppe ist (z. B. Gegenstand der Freispeichersammlung ist), dann wird eine neue Untergruppe N+1 hinzugefügt. Dies ermöglicht die Verwendung der neuen Untergruppe N+! für die Deduplizierung und die Verwendung der Untergruppe N für Lesevorgänge und zum Bereinigen. Jede Untergruppe kann als separates Objekt im Objektspeicher gespeichert sein.
Genauer gesagt ist jede Tranche eines Objekts basierend auf einer Funktion der Daten innerhalb der Tranche mit einer Ähnlichkeitsgruppe gemappt. Die Funktion erzeugt in einem Beispiel typischerweise einen Identifikator (ID) zwischen 1 und 4 Milliarden. Tranchen werden typischerweise nur gegenüber der Ähnlichkeitsgruppe und höchsten Untergruppe mit derselben Ähnlichkeitsgruppen-ID dedupliziert. Wenn eine Untergruppe eine Schwellengröße erreicht (z. B. 8 MB), wird eine leere Ähnlichkeitsgruppe mit derselben Ähnlichkeitsgruppen-ID, aber einer erhöhten Untergruppen-ID gebildet. Zukünftige Tranchen, die zur Ähnlichkeitsgruppe gemappt werden, werden gegenüber der aktuellen Untergruppen-ID dedupliziert. Dies stellt sicher, dass neue Schreibvorgänge keine betroffenen Ähnlichkeitsgruppen oder Untergruppen, die durch die Freispeichersammeloperation bereinigt werden, beeinflussen.
Dies kann zu einem potenziellen Verlust in der Deduplizierung führen, weil Untergruppen leer starten. Leere Untergruppen können jedoch entfernt werden, weil es sicher ist, nach einer Bereinigung in Bezug auf eine Ähnlichkeitsgruppe und/oder Untergruppe zu deduplizieren. Alternativ dazu können Deduplizierungsaufgaben vom Metadatenserver ausgeführt werden, um die geeigneten Fingerprints zu markieren, indem mit den Workern zur Freispeichersammlung kommuniziert wird.
Auf 4 zurückkommend werden nach dem Schützen von betroffenen Ähnlichkeitsgruppen lebende Fingerprints in den betroffenen Ähnlichkeitsgruppen markiert 408. 10 veranschaulicht ein Beispiel für die Markierung von lebenden Fingerprints. 10 dient auch dazu, ein Verfahren zum Markieren von lebenden Fingerprints zu veranschaulichen. Anfangs kann der Controller 1002 eine Liste von Lebende-Tranchen-Recipes erhalten. Dies kann erreicht werden, indem alle Deduplizierungsdomänenidentifikatoren im Speichersystem gesammelt werden. In einem Beispiel ist ein Deduplizierungsdomänenidentifikator ein einzigartiger Identifikator, der einem Benutzer zugeordnet ist. Jedes Objekt, das von diesem Benutzer im Objektspeicher gespeichert wird, enthält eine Referenz zum Deduplizierungsdomänenidentifikator. Neue Objekte werden nur gegenüber anderen Objekten dedupliziert, die demselben Deduplizierungsdomänenidentifikator zugeordnet sind, und zwar zum Zweck der Inhaberisolierung, des Datenschutzes und der Sicherheit. Ein Benutzer kann sich beispielsweise auf eine Entität oder Organisation beziehen. Diese Informationen können auch von einem Metadatenserver erhalten werden. Dann werden alle Objekt-Recipes für die Deduplizierungsdomänenidentifikatoren bestimmt und aus jedem Objekt-Recipe werden die Lebende-Tranchen-Recipes aufgelistet. Nachdem die Liste von Lebende-Tranchen-Recipes erhalten wurde, kann der Controller die Tranchen-Recipes basierend auf der vorherigen Zuweisung den Workern zuweisen (z. B. dem Worker 1004 und dem Worker 1006). Beispielsweise sind die Tranchen, die dem Worker 1004 zugewiesen werden, jene, die der dem Ähnlichkeitsgruppenumfang entsprechen, der dem Worker 1004 vom Controller 1002 zugewiesen sind.
Genauer gesagt kann der Controller 1002 den Namen des Tranchen-Recipes parsen oder analysieren, um die Ähnlichkeitsgruppen-ID und die Untergruppen-ID zu bestimmen. Mit der Ähnlichkeitsgruppen-ID und Untergruppen-ID sieht der Controller 1002 in seiner Worker-Tabelle nach, um die Worker zu identifizieren, deren zugeordneter Ähnlichkeitsgruppenumfang die bestimmte Ähnlichkeitsgruppen-ID enthält. Die Tranche wird dann in den Kanal für die lebende Tranche des Workers 1036 (z. B. eine Warteschleife) geschoben. Jeder Worker hat seinen eigenen Kanal für lebende Tranchen und dieses Mapping wird vom Controller unter Verwendung der IP-Adresse des Workers verwaltet. Sobald der Controller alle Lebende-Tranchen-Recipes durchgegangen ist und die Lebende-Tranchen-Recipes in den entsprechenden Worker-Kanal geschoben hat, kann der Controller alle Worker-Kanäle schließen.
In der Zwischenzeit nimmt der Worker 1004 (und die anderen Worker) Calls an den Controller 1002 vor und nimmt eine Charge der Tranchen-Recipes aus dem Kanal 1036, in den der Controller 1002 Lebende-Tranchen-Recipes gegeben hat. Der Worker 1004 fährt fort, die Lebende-Tranchen-Recipes in Chargen aus dem Kanal 1036 zu ziehen, bis der Kanal leer ist. Mit der Liste von Lebende-Tranchen-Recipes bestimmt der Worker 1004 die Ähnlichkeitsgruppen-ID. Mit der Ähnlichkeitsgruppen-ID überprüft der Worker 1004, ob die Ähnlichkeitsgruppe zur Bereinigung markiert oder eine betroffene Ähnlichkeitsgruppe ist. Wenn die Ähnlichkeitsgruppe markiert ist, liest der Worker 1004 das zugeordnete Tranchen-Recipe aus und protokolliert die Liste von lebenden Fingerprints in einer internen Lebende-Segmente-Struktur 1034, z. B. einem Bloomfilter. Diese Lebende-Segmente-Struktur 1034 kann konfiguriert sein, um Informationen wie die Anzahl an lebenden Tranchen, die Anzahl an lebenden Segmenten und eine Liste, welche Segmente lebend sind, zu enthalten. Um den Arbeitsspeicherbedarf zu verringern, kann die Liste von Segmenten in einer Hashtabelle, einem Bloomfilter oder einem perfekten Hashvektor repräsentiert sein. Der Worker 1004 kann eine Liste von Segmentstrukturen für jede betroffene Ähnlichkeitsgruppe führen, für die der Worker verantwortlich ist. Nachdem alle Worker durch ihre Liste von Lebende-Tranchen-Recipes gegangen sind, wurde jede Lebende-Segment-Struktur vollständig aktualisiert.
10 veranschaulicht das Schutzsystem in der Markierungsphase der lebenden Segmente. Beispielsweise kann das Objekt X aus den Segmenten 1, 2, 3, 4 und 5 bestehen. Das Objekt X kann wie in 3 dargestellt gelöscht worden sein. 10 veranschaulicht, dass im Objektspeicher 1020 die betroffene Ähnlichkeitsgruppe eine Ähnlichkeitsgruppe A, Untergruppe 1 umfasst. Wenn dies die höchste Untergruppe ist, würde wie zuvor beschrieben eine neue Untergruppe 2 während der Freispeichersammeloperation erzeugt werden.
Die Ähnlichkeitsgruppe A ist Kompressionsregionen (CR) zugeordnet, einschließlich CR 3, die Fingerprints 1, 2, 3, 4, 5 und die entsprechenden Segmente enthält, und CR 4, de Fingerprints 6, 7 und die entsprechenden Segmente enthält.
Das Objekt Y wurde nicht gelöscht und der Objektspeicher 1020 umfasst das Objekt-Recipe 1022 und das Tranchen-Recipe 1024 von Y, das die Ähnlichkeitsgruppe A, Untergruppe 1 und die Fingerprints 1, 2, 5, 6 und 7 identifiziert.
Somit teilen sich Objekt X und Objekt Y die Segmente 1 und 2. CR 3 umfasst die Segmente 1, 2, 3,4 und 5 und CR 4 umfasst die Segmente 6, 7.
Wenn der Worker 1004 ein Tranchen-Recipe vom Controller 1002 abruft, bestimmt der Worker, ob das Tranchen-Recipe eine betroffene Ähnlichkeitsgruppe referenziert. Wenn nicht, wird die Tranche übersprungen. Wenn ja, wird das Tranchen-Recipe gelesen und lebende Fingerprints werden in der Ähnlichkeitsgruppe markiert.
Wenn das Recipe für das Objekt Y empfangen wird, werden somit die Fingerprints oder Segmente 1, 2, und 5 in CR 3 markiert und die Segmente 6 und 7 in CR 4 markiert. Dies zeigt sich in der Struktur 1034, in der die Segmente 1, 2, 5, 6 und 7 als lebend markiert sind. Unter Bezugnahme auf 4 kann die Übertragungsphase 410 fortschreiten, nachdem die lebenden Segmente markiert wurden. Das Übertragen ist eine Phase, die sicherstellt, dass keine unreferenzierten Strukturen oder Segmente im Objektspeicher verbleiben. Dies verringert vorteilhafterweise die Speicherkosten. Gleichzeitig kann es Situationen geben, in denen einige Strukturen nicht bereinigt werden, beispielsweise basierend auf dem Verhältnis von lebenden Segmenten zu toten Segmenten.
In einem Beispiel verarbeitet der Worker 1004 seine Liste von Tranchen und die entsprechende betroffene Ähnlichkeitsgruppe. Jede Ähnlichkeitsgruppe ist einem Mapping von lebenden Segmenten für jede Ähnlichkeitsgruppe zugeordnet. Somit ist die Struktur 1034 ein Mapping für die Ähnlichkeitsgruppe A. Für jede Ähnlichkeitsgruppe werden die referenzierten Kompressionsregionen gelesen und es wird bestimmt, ob sie ausreichend tot für eine Bereinigung sind oder in ihrem aktuellen Zustand belassen werden sollten. Während die Kompressionsregionen aus den Segment-Fingerprints gelesen werden, kann ein Mapping des Kompressionsregionsnamens zur Anzahl an lebenden Fingerprints erzeugt werden. Die Bestimmung, ob die jeweilige Kompressionsregion bereinigt werden soll, wird ausgeführt, indem der Prozentsatz der Kompressionsregion, der lebend ist, basierend auf der Anzahl an lebenden Fingerprints berechnet wird und dieser Prozentsatz mit einer vordefinierten Schwelle verglichen wird (z. B. 85 % oder eine andere Zahl), die als ausreichend lebend in der Kompressionsregion erachtet wird. Wenn der Prozentsatz an lebenden Fingerprints in der Kompressionsregion unter die vordefinierte Schwelle fällt, wird die Kompressionsregion als bereinigungswürdig erachtet. Die Schwelle kann angepasst werden, um Platzgewinnung zu priorisieren oder IO-Kosten zu minimieren.
Für jede Kompressionsregion, die bereinigt wird, werden die lebenden Segmente kopiert, um neue Kompressionsregionen zu bilden. Sobald alle neuen Kompressionsregionen gebildet und in einer neuen Version der Ähnlichkeitsgruppe protokolliert wurden, wird die neue Version der Ähnlichkeitsgruppe gespeichert. Der Metadatenserver wird benachrichtigt, die alten Ähnlichkeitsgruppen hinauszuwerfen und die neue Ähnlichkeitsgruppe hinzuzufügen. Schließlich werden die alten Ähnlichkeitsgruppen und Kompressionsregionen gelöscht. So werden tote Segmente aus dem Objektspeicher entfernt.
Die Freispeichersammeloperation kann als partielle oder verzögerte Mark-and-Sweep-Operation implementiert werden. Die Freispeichersammeloperation umfasst das Bereinigen oder Entfernen von gelöschten Objekten von den lebenden Objekten. Wenn ein Objekt gelöscht wird, wird ein Protokoll in einem Lösch-Bucket (oder einer anderen Struktur) aufgezeichnet. Die Protokolle im Lösch-Bucket werden später verwendet, wenn die Freispeichersammeloperation ausgeführt wird. Die Freispeichersammeloperation kann in Phasen oder aufeinanderfolgenden Aktionsschritten ablaufen. Ausführungsformen der Erfindung sind eine fokussierte Mark-and-Sweep-Freispeichersammlung, die sich auf Ähnlichkeitsgruppen konzentriert, die, zumindest teilweise, tote Segmente umfassen kann.
11A und 11B veranschaulichen Beispiele für die gleichzeitige Ausführung der Freispeichersammlung und von normalen Systemoperationen. Wie zuvor erläutert kann eine Ähnlichkeitsgruppe mehreren Untergruppen zugeordnet sein. Die Anzahl an Untergruppen in einer Ähnlichkeitsgruppe kann sich im Laufe der Zeit ändern. Beispielsweise können Untergruppen hinzugefügt werden. Jeder Untergruppe können Informationen zugeordnet sein, welche die Ähnlichkeitsgruppe, die Untergruppe und einen Transaktionsidentifikator identifizieren.
11A veranschaulicht N Untergruppen, die als Untergruppen 1102 (Untergruppe 1), 1104 (Untergruppe 2) und 1106 (Untergruppe N) dargestellt sind und derselben Ähnlichkeitsgruppe zugeordnet sind. Die Untergruppe 1102 ist wie folgt identifiziert: Ähnlichkeitsgruppe A, Untergruppe 1, Transaktion 3. Die Untergruppe 1104 ist wie folgt identifiziert: Ähnlichkeitsgruppe A, Untergruppe 2, Transaktion 2. The Ähnlichkeitsgruppe 1106 ist wie folgt identifiziert: Ähnlichkeitsgruppe A, Untergruppe N, Transaktion 0.
In diesem Beispiel hat jede der Untergruppen einen anderen Untergruppen-Identifikator. Im Lauf der Zeit können Untergruppen hinzugefügt werden. Untergruppen können aus unterschiedlichen Gründen hinzugefügt werden, einschließlich bei der Ausführung der Freispeichersammlung und wenn normale Operationen ausgeführt werden (z. B. ist eine neue Untergruppe erforderlich, wenn die jüngste Untergruppe voll ist). Wenn eine neue Untergruppe hinzugefügt wird, wird der neuen Untergruppe derselbe Ähnlichkeitsgruppen-Identifikator (z. B. Ähnlichkeitsgruppe A), ein anderer Untergruppen-Identifikator (z. B. N+1) und ein Transaktionsidentifikator zugeordnet. Der Transaktionsidentifikator kann in einem Beispiel identifizieren, wie oft eine Untergruppe modifiziert oder bereinigt wurde.
Untergruppen werden oft für Deduplizierungszwecke verwendet, was ein Beispiel für eine normale Systemoperation ist. Außerdem können Untergruppen währen normaler Operationen aus verschiedenen Gründen gelesen werden, z. B. wenn ein Datenobjekt aus seinen Teilen wiederhergestellt wird. Ausführungsformen der Erfindung ermöglichen, dass Vorgänge wie Freispeichersammlung und normale Operationen gleichzeitig stattfinden.
11A veranschaulicht ein Beispiel für Freispeichersammeloperationen und normale Operationen, wenn die Untergruppe, die bereinigt wird, nicht die jüngste Untergruppe ist (d. h. nicht den höchsten Untergruppen-Identifikator aufweist). In diesem Beispiel wurde die Untergruppe 1104: Ähnlichkeitsgruppe A Untergruppe 2 zur Bereinigung markiert.
Wenn eine Untergruppe oder eine Ähnlichkeitsgruppe zur Bereinigung oder zur Freispeichersammlung identifiziert wurde, kann die Ähnlichkeitsgruppe oder Untergruppe in einer Tabelle, Map oder dergleichen markiert sein. Als Teil des Vorgangs zur Freispeichersammlung für die Untergruppe 1104 wird eine neue Untergruppe 1108 erzeugt. Die neue Untergruppe 1108 weist einige derselben Segmentreferenzen wie die alte Untergruppe 1104 auf. So wird die Untergruppe 1108 wie folgt identifiziert: Ähnlichkeitsgruppe A, Untergruppe 2 und Transaktion 3.
Genauer gesagt weist die Untergruppe 1108 denselben Ähnlichkeitsgruppen-Identifikator und denselben Untergruppen-Identifikator auf wie die Untergruppe 1104, die bereinigt wird. Der Transaktionsidentifikator unterscheidet sich und kann während des Vorgangs zur Freispeichersammlung verwendet werden. Referenzen auf lebende Segmente von der Untergruppe 1104 (oder von einer oben definiert mehreren Kompressionsregionen) werden in die Untergruppe 1108 übertragen oder kopiert. Tote oder nichtreferenzierte Segmente werden nicht in die Untergruppe 1108 kopiert.
Wenn die Untergruppe 1104 anschließend gelöscht wird, werden auch alle der toten Segmente gelöscht. Der Transaktionsidentifikator wird verwendet, um zu bestimmen, welche Untergruppen 1104 und 1108 gelöscht werden sollen, weil sie denselben Ähnlichkeitsgruppen-Identifikator und denselben Untergruppen-Identifikator aufweisen. In diesem Beispiel bleibt die Untergruppe mit dem höchsten Transaktionsidentifikator erhalten.
Dieser Aspekt der Freispeichersammlung wird unter Bezugnahme auf 1B genauer beschrieben. Wie zuvor angemerkt kann eine Untergruppe mehreren Kompressionsregionen zugeordnet sein. Jede Kompressionsregion speichert eine Reihe von Segmenten und Segment-Identifikatoren. Folglich kann der Kopiervorgang von lebenden Segmenten basierend auf Kompressionsregionen und nicht auf der gesamten Untergruppe ausgeführt werden (obwohl eine gesamte Untergruppe auf ähnliche Weise verarbeitet werden könnte). Wie in 1B für eine bestimmte Kompressionsregion dargestellt, werden die Segmente 82 und Segmente 86 von der Kompressionsregion 80 in die neue Kompressionsregion 88 übertragen. Sobald die lebenden Segmente in die neue Kompressionsregion kopiert wurden, kann die alte Kompressionsregion (z. B. Kompressionsregion 80) als Gesamtes gelöscht werden. So werden tote oder nichtreferenzierte Segmente aus dem Speicher entfernt, indem neue Kompressionsregionen erzeugt werden, welche nur die lebenden Segmente von der vorherigen Kompressionsregion enthalten. Sobald dieser Vorgang für alle betroffenen Kompressionsregionen ausgeführt wurde und die neuen Kompressionsregionen erzeugt wurden, können die vorherigen Kompressionsregionen, die zum Teil oder vollständig tot waren, entfernt werden. Als Folge dieses Vorgangs kann die Untergruppe 1108 eine Kombination von vorhandenen Kompressionsregionen (z. B. jene Kompressionsregionen, die nicht von der Freispeichersammlung betroffen waren) und neuen Kompressionsregionen referenzieren.
Während die Untergruppe 1104 bereinigt wird oder während der Freispeichersammlung sind andere Untergruppen für normale Operationen verfügbar. Somit ist die Untergruppe 1102 für Operationen wie Leseoperationen verfügbar. Eine Deduplizierung, ein anderes Beispiel für eine normale Systemoperation, wird oft nur in Bezug auf die jüngste Untergruppe ausgeführt. So wird in einem Beispiel nur die jüngste Untergruppe (oder die Untergruppe mit dem höchsten Untergruppen-Identifikator) für eine Deduplizierung verwendet. Folglich kann die Untergruppe 1106 für Operationen wie Leseoperationen, Schreiboperationen und Deduplizierungsoperationen verwendet werden. In 11A wird nur die Untergruppe N zum Schreiben verwendet. Anders gesagt ist die Untergruppe 1104 schreibgeschützt, obwohl die Untergruppe 1104 für Lese- und andere Operationen verfügbar sein kann.
Außerdem ist die Untergruppe 1104 immer für Leseoperationen verfügbar. Die Aktualisierungen werden so eingeteilt, dass die Untergruppe 1104 (oder 1108) immer für Leseoperationen verfügbar ist. Aktualisierungen oder die Freispeichersammlung können wie folgt ablaufen: Ausschreiben neuer Kompressionsregionen, Ausschreiben einer Untergruppe 1108 (so dass die Untergruppe 1108 den neuen Kompressionsregionen und den Kompressionsregionen, die nicht bereinigt wurden, zugeordnet ist), Entfernen von toten Kompressionsregionen (die Kompressionsregionen, die bereinigt wurden) und dann Entfernen der Untergruppe 1104. So kann ein Client Daten durch Zugreifen auf die Untergruppe 1104 und ihre Kompressionsregionen oder durch Zugreifen auf die Untergruppe 1108 und ihre Kompressionsregionen lesen.
Wenn ein Client während der Freispeichersammlung gerade dabei ist, auf die Untergruppe 1104 und ihre Kompressionsregionen zuzugreifen, kann ein Lesevorgang fehlschlagen. Die Auslesung wird jedoch abgerufen und führt zu einer Leseoperation, die auf die Untergruppe 1108 zugreift. Dieser interne fehlgeschlagene Lesevorgang kann vor dem anfragenden Client verborgen bleiben.
Als Folge können die Datenobjekte, die im System und in der Ähnlichkeitsgruppe A gespeichert sind, gleichzeitig Gegenstand von Freispeichersammeloperationen als auch normalen Systemoperationen sein.
11B veranschaulicht die Ausführung von sowohl Freispeichersammeloperationen als auch normalen Systemoperationen, wenn die jüngste Untergruppe (Untergruppe 1106 oder Untergruppe N) Gegenstand der Freispeichersammlung ist. In 11B ist die Untergruppe 1106 Gegenstand der Freispeichersammlung. Als Folge wird eine neue Untergruppe 1112 erzeugt und die Untergruppe 1106 wird schreibgeschützt. Die neue Untergruppe 1112 ist wie folgt identifiziert: Ähnlichkeitsgruppe A, Untergruppe N+1, Transaktion 0.
Da eine neue Untergruppe 1112 erzeugt wurde, werden nun Deduplizierungsoperationen und Schreiboperationen in Bezug auf die Untergruppe 1112 ausgeführt. Dies ermöglicht die Ausführung von normalen Schreib- und Deduplizierungsoperationen in Bezug auf die Ähnlichkeitsgruppe A.
Die Untergruppe 1106 wird dann wie zuvor beschrieben bereinigt. Während der Bereinigung oder während der Freispeichersammlung wird die Untergruppe 1110 erzeugt, um die Untergruppe 1106 effektiv zu ersetzen. Die Untergruppe 1110 hat denselben Ähnlichkeitsgruppen-Identifikator und denselben Untergruppen-Identifikator wie die Untergruppe 1106. Der Transaktionsidentifikator der Untergruppe 1110 ist unterschiedlich. Während die Untergruppe 1106 bereinigt wird und die Untergruppe 1110 erzeugt wird, um sie zu ersetzen, können normale Systemoperationen unter Verwendung der Ähnlichkeitsgruppe A ausgeführt werden. So können die Untergruppen 1102, 1104, 1106 und/oder 1112 für Leseoperationen verwendet werden. Die Untergruppe 1112 kann auch für Schreib- und/oder Deduplizierungsoperationen verwendet werden. Im Laufe der Zeit kann die Größe der Untergruppen abnehmen, weil tote Segmente als Freispeicher gesammelt oder entfernt werden. Dies verringert den Speicherbedarf.
Das Schreibschützen einer Untergruppe kann implizit vom System erreicht werden. Genauer gesagt kann beispielsweise und ohne Einschränkung eine Deduplizierung in Bezug auf die jüngste Untergruppe ausgeführt werden. Somit werden die anderen Untergruppen nicht für eine Deduplizierung verwendet und es ist gegebenenfalls nicht notwendig, in diese Untergruppen zu schreiben. Sie werden vielmehr für Leseoperationen verwendet. Alternativ dazu kann das System aktiv sicherstellen, dass keine Schreibvorgänge an bestimmten Objekten, wie z. B. an einer bestimmten Untergruppe, stattfinden. Ein aktiver Schutz kann während bestimmter Aspekte des Vorgangs zur Freispeichersammlung aufrechterhalten werden, beispielsweise wenn eine neue Untergruppe gebildet wird, wenn lebende Segmente in die neue Untergruppe kopiert werden oder dergleichen.
11C veranschaulicht ein Beispiel für ein Verfahren zur gleichzeitigen Ausführung von normalen Operationen und Freispeichersammeloperationen. Das Verfahren kann mit dem Identifizieren 1120 von Ähnlichkeitsgruppen beginnen, die von einer Freispeichersammeloperation betroffen sind. Dies kann das Identifizieren bestimmter Untergruppen in den betroffenen Ähnlichkeitsgruppen umfassen.
Als Nächstes wird die Ähnlichkeitsgruppe für einen gleichzeitigen Zugriff konfiguriert 1122. Dies kann das Schreibschützen einer Untergruppe umfassen, wenn erforderlich. Das Konfigurieren der Ähnlichkeitsgruppe kann auch das Erzeugen einer neuen Untergruppe umfassen, wenn die betroffene Untergruppe aktuell für eine Deduplizierung verwendet wird. Dann werden Freispeichersammeloperationen und normale Operationen gleichzeitig ausgeführt 1124. Dies kann umfassen, dass das System Lesevorgänge, Schreibvorgänge, Deduplizierung oder dergleichen unter Verwendung der Ähnlichkeitsgruppe ausführen gelassen wird, während Freispeicher in der Ähnlichkeitsgruppe gesammelt wird.
12A und 12B (12) veranschaulichen ein Beispiel für ein Verfahren zum Löschen eines oder mehrerer Objekte aus einem Speichersystem, wie z. B. einem deduplizierten Speichersystem. Da das Löschen eines Objekts in Phasen stattfinden kann, veranschaulicht 12A eine erste Phase des Verfahrens zum Löschen eines Objekts und 12B veranschaulicht eine zweite Löschphase eines Objekts.
Wie zuvor angemerkt, ist der Vorgang des Löschens eines Objekts in einem deduplizierten Speichersystem nicht trivial, zumindest aus dem Grund, dass Objekte typischerweise in Teile (z. B. Segmente) unterteilt sind. Als Folge kann ein Segment, das im Speichersystem gespeichert ist, sowohl einem lebenden Datenobjekt als auch einem toten Objekt entsprechen.
12 veranschaulicht ein Beispiel für ein Verfahren zum Löschen von Segmenten, die vollständig tot sind oder die von keinem lebenden Objekt oder lebenden Objekt-Recipe im deduplizierten Speichersystem referenziert werden.
Unter Bezugnahme auf 2 und 3 beginnt der Löschvorgang eines Objekts wie in 12A dargestellt. Ein Objekt wird in einen Lösch-Bucket gegeben 1202 und ein Löschprotokoll für das Objekt wird erzeugt 1204. Platzieren eines Objekts im Lösch-Bucket findet üblicherweise als Antwort auf eine Aktion statt. Beispielsweise kann ein Objekt laut z. B. einer Richtlinie ablaufen. Häufig werden Backups für eine begrenzte Zeitdauer behalten, und wenn diese Zeitdauer abläuft, können das Backup und zugeordnete Objekte gelöscht werden. Dies führt dazu, dass Objekte in den Lösch-Bucket gegeben werden. Ein bestimmtes Objekt oder eine Gruppe von Objekten kann vom Benutzer oder Client in den Lösch-Bucket gegeben werden, der das jeweilige Objekt oder die Gruppe von Objekten aktiv löscht.
Objekte können vorübergehend in das Löschobjekt gegeben werden, wenn Objekte geschrieben werden. Objekte, die nicht abgeschlossen werden, bleiben im Lösch-Bucket, während Objekte, die abgeschlossen wurden, aus dem Lösch-Bucket entfernt werden können.
In engem Zusammenhang mit dem Platzieren eines Objekts im Lösch-Bucket steht die Erstellung eines Löschprotokolls als 1204. Wenn ein Löschprotokoll erstellt wird, werden ausreichend Informationen aufgenommen, sodass die Segmente des Objekts identifiziert werden können. Dies kann das Recipe des Objekts, einen Namen des Objekts oder dergleichen umfassen. Wenn ein Objekt in den Lösch-Bucket gegeben wird und ein Löschprotokoll erstellt wird, ist das Objekt aus der Perspektive des Clients nicht länger sichtbar.
Im Laufe der Zeit kann sich eine Reihe von Löschprotokollen im Lösch-Bucket ansammeln. Genauer gesagt ist der Vorgang zur tatsächlichen Entfernung der Objekte, die in den Lösch-Bucket gegeben wurden, wie zuvor erwähnt aufgrund der deduplizierten Beschaffenheit des Speichersystems kompliziert. Die tatsächliche Entfernung oder Löschung des Objekts kann zu einem späteren Zeitpunkt stattfinden, beispielsweise laut einem Zeitplan, basierend auf der Anzahl an Löschprotokollen, basierend auf einem expliziten Befehl oder dergleichen.
12B veranschaulicht somit einen Vorgang oder eine zweite Phase des Löschvorgangs. In dieser Phase werden Ähnlichkeitsgruppen, die von einer Freispeichersammeloperation betroffen sind, identifiziert 1210. Das Identifizieren 1210 der betroffenen Ähnlichkeitsgruppen kann das Abrufen der Löschprotokolle aus dem Lösch-Bucket umfassen. Die Löschprotokolle, die ein Recipe enthalten können, ermöglichen die Identifikation von Objekt-Tranchen. Da jede Tranche einer Ähnlichkeitsgruppe entspricht, können die Ähnlichkeitsgruppen identifiziert werden, die vom Freispeichersammelvorgang betroffen sind.
Sobald die Ähnlichkeitsgruppe für ein Objekt identifiziert wurde, kann eine Struktur, welche die Segmente des Objekts tatsächlich speichert, identifiziert werden 1212. Beispielsweise speichern tatsächlich Kompressionsregionen die Segmente und Kompressionsregionen werden in Untergruppen gespeichert. Unter Verwendung des Tranchen-Recipes können die Untergruppen der Ähnlichkeitsgruppe identifiziert werden, die vom Freispeichersammelvorgang betroffen sind. Tatsächlich können die spezifischen Kompressionsregionen auch aus den Tranchen-Recipes identifiziert werden.
Da ein Segment sowohl einem lebenden Objekt als auch einem toten Objekt entsprechen kann, veranschaulicht 12B, dass lebende Segmente in den identifizierten Strukturen markiert 1214 oder identifiziert werden. Somit werden die lebenden Segmente in der Ähnlichkeitsgruppe identifiziert und das kann das Identifizieren der lebenden Segmente in den betroffenen Untergruppen und insbesondere in den betroffenen Kompressionsregionen umfassen. Die lebenden Segmente können basierend auf einer Analyse von lebenden Objekten im Speichersystem identifiziert werden. Das Verarbeiten des Objekts und der Tranchen-Recipes von lebenden Objekten wird ausgeführt und wann immer ein lebendes Objekt einer Ähnlichkeitsgruppe zugeordnet ist, die vom Freispeichersammelvorgang betroffen ist, werden die lebenden Segmente in dieser Ähnlichkeitsgruppe identifiziert oder markiert.
Sobald die lebenden Segmente markiert sind, sind jegliche unmarkierte Segmente tote Segmente, zumindest aus dem Grund, dass sie von keinem lebenden Objekt im Speichersystem referenziert werden. Als Nächstes werden die lebenden Segmente in eine neue Struktur übertragen 1216, wie in 11A-11C beschrieben ist. Schließlich können die alten Strukturen, aus denen die lebenden Segmente kopiert wurden, als Gesamtes entfernt werden 1218.
In einigen Beispielen kann es vorkommen, dass eine betroffene Struktur nicht tatsächlich verarbeitet wird, wenn der Prozentsatz an lebenden Segmenten über einem Schwellenwert liegt. Dies kann Kosten in Verbindung mit Rechenressourcen verringern. Der Schwellenwert kann konfigurierbar sein und basierend auf Speicherbedarf, Kostenanforderungen oder dergleichen verändert werden. Durch das Löschen von Segmenten auf diese Weise, kann eine Deduplizierung beibehalten und in einem aktiven Zustand gehalten werden, während auch das Ausmaß an Speicherplatz verwaltet wird, das von den Objekten eingenommen wird. So können sowohl Rechenressourcen als auch Speicherressourcen auf kosteneffiziente Weise verwaltet werden.
13 veranschaulicht ein Beispiel für ein Verfahren zum Markieren von Ähnlichkeitsgruppen oder genauer gesagt Markieren oder Identifizieren von Segmenten, die im Speichersystem behalten werden sollen, und Segmenten, die aus dem Speichersystem entfernt werden sollen. Bei der Ausführung der Freispeichersammlung als partielle oder verzögerte Mark-and-Sweep-Operation werden nur die Ähnlichkeitsgruppen bereinigt, die vom Freispeichersammelvorgang betroffen sind. Genauer gesagt werden nur betroffene Kompressionsregionen (die Strukturen, die tatsächlich die Segmente speichern) bereinigt. Das Bereinigen aller Ähnlichkeitsgruppen in einer vollständigen Mark-and-Sweep-Operation würde wesentlich länger dauern.
Das Markieren der betroffenen Ähnlichkeitsgruppen ist eine Möglichkeit, die Ähnlichkeitsgruppen zu identifizieren, die verarbeitet werden müssen. Das Verfahren aus 13 beginnt somit diesen Vorgang des Markierens oder Identifizierens der betroffenen Ähnlichkeitsgruppen durch Empfangen 1302 oder Abrufen von Löschprotokollen aus einem Lösch-Bucket. Wie zuvor angemerkt identifizieren die Löschprotokolle die Objekte, die aus dem Speichersystem gelöscht werden sollen. Diese Objekte können als gelöschte Objekte bezeichnet werden, auch wenn sie gegebenenfalls immer noch im Speichersystem vorhanden sind, bis die betroffenen Strukturen bereinigt werden.
Jedes Löschprotokoll wird verarbeitet, um Tranchen-Recipes zu identifizieren 1304. Das Löschprotokoll eines Objekte kann ein Objekt-Recipe identifizieren und die Tranchen-Recipes können aus dem Objekt-Recipe bestimmt werden. Jedes Tranchen-Recipe ist einer Ähnlichkeitsgruppe zugeordnet. Eine einzelne Ähnlichkeitsgruppe kann mehreren Tranchen-Recipes zugeordnet sein. Wenn ein Objekt zwei Tranchen-Recipes zugeordnet ist, dann betreffen die Freispeichersammeloperation für dieses Objekt eine oder zwei Ähnlichkeitsgruppen, wenn dieses Objekt Gegenstand einer Löschung ist
Somit werden die Ähnlichkeitsgruppen, die vom Freispeichersammelvorgang betroffen sind und den Tranchen-Recipes zugeordnet sind, markiert 1306. Die Löschprotokolle ermöglichen es dem Freispeichersammelvorgang, zu identifizieren, welche Ähnlichkeitsgruppen betroffen sein werden. Tatsächlich ermöglicht das Objekt-Recipe das Identifizieren oder Markieren der Untergruppen und spezifischen Kompressionsregionen. Als Folge können alle Kompressionsregionen bestimmt werden, die vom Freispeichersammelvorgang betroffen sind und den Löschprotokollen zugeordnet sind, die aktuell verarbeitet werden.
In einem Beispiel werden alle Kompressionsregionen, die von markierten Ähnlichkeitsgruppen referenziert werden, zum Bereinigen in Betracht gezogen. Kompressionsregionen, die von nichtmarkierten Ähnlichkeitsgruppen referenziert werden, werden nicht zum Bereinigen in Betracht gezogen. Außerdem kann es viele Kompressionsregionen in einer markierten Ähnlichkeitsgruppe geben, die nicht von einem Löschprotokoll referenziert werden.
Ausführungsformen der Erfindung können Kompressionsregionen bereinigen oder nicht bereinigen, die nicht von einem Löschprotokoll referenziert werden. Als Ergebnis kann der Freispeichersammelvorgang Kompressionsregionen verarbeiten, die keine Segmente speichern, die den gelöschten Objekten zugeordnet sind. Dies könnte unter Verwendung einer Mapping-Struktur erreicht werden, um betroffene Kompressionsregionen weiter zu markieren, anstatt einfach betroffene Ähnlichkeitsgruppen zu identifizieren. In einem Beispiel kann es auch möglich sein, aus der Perspektive von Untergruppen zu überspringen. Wenn eine Untergruppe keine betroffenen Kompressionsregionen enthält, kann die gesamte Untergruppe übersprungen werden.
Diese Informationen reichen aber typischerweise nicht aus, um die Freispeichersammeloperation im deduplizierten System auszuführen, weil einige der Segmente, die den zu löschenden Objekten zugeordnet sind, auch lebenden Objekten zugeordnet sein können.
So werden die lebenden Segmente in den betroffenen Ähnlichkeitsgruppen oder in den betroffenen Untergruppen und Kompressionsregionen identifiziert 1308. Das Identifizieren von lebenden Segmenten kann durch Verarbeiten aller lebenden Objekte (oder Lebende-Objekte-Recipes) im Rechensystem beginnen, um die lebenden Objekte zu identifizieren, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind.
Beispielsweise kann ein Objekt-Recipe eines lebenden Objekts beurteilt werden. Wenn ein Tranchen-Recipe eines lebenden Objekts keiner betroffenen Ähnlichkeitsgruppe entspricht, kann das Tranchen-Recipe übersprungen werden und das nächste Tranchen-Recipe kann beurteilt werden. Die lebenden Objekte, die vom Freispeichersammelvorgang betroffen sein können, werden ebenfalls identifiziert. Das Identifizieren der lebenden Objekte oder der lebenden Segmente stellt sicher, dass ein Segment, das in Bezug auf ein Objekt lebend ist und in Bezug auf ein anderes Objekt tot ist, im deduplizierten Speichersystem nicht korrumpiert wird.
Sobald die lebenden Objekte, die vom Freispeichersammelvorgang betroffen sind, identifiziert wurden, werden die Segmente der lebenden Objekte markiert. Wie in 10 dargestellt kann beispielsweise eine Struktur eines lebenden Segments für eine Ähnlichkeitsgruppe (oder für eine Untergruppe und/oder eine Kompressionsregion) aufrechterhalten werden. Die lebenden Segmente werden in dieser Struktur identifiziert und markiert. In einem Beispiel werden die Ähnlichkeitsgruppen oder die Kompressionsregionen mit einer Struktur gemappt, die identifiziert, welche der Segmente lebend sind. Eine Kompressionsregion kann einer Bitmap zugeordnet sein (ein Bit für jedes Segment in der Kompressionsregion). Lebende Segmente können in der Bitmap markiert sein. Unmarkierte Segmente in der Map sind tote Segmente. Betroffene Ähnlichkeitsgruppen können auf ähnliche Weise unter Verwendung einer MapStruktur markiert werden, die Ähnlichkeitsstrukturen entspricht.
Sobald alle der betroffenen lebenden Objekte verarbeitet wurden und die entsprechenden lebenden Segmente identifiziert wurden, sollten die unmarkierten Segmente den Objekten entsprechen, die gelöscht werden und ansonsten von keinem anderen lebenden Objekt referenziert werden.
In einem Beispiel kann das Element des Identifizierens 1308 in den betroffenen Ähnlichkeitsgruppen Workern zugewiesen werden. Die lebenden Objekte können zwischen den Workern aufgeteilt werden, sodass die lebenden Objekte effektiv parallel beurteilt werden. Auf ähnliche Weise kann der Vorgang des Bereinigens der betroffenen Ähnlichkeitsgruppen den Workern zugewiesen werden.
Als Nächstes werden die in den Löschprotokollen identifizierten Objekte tatsächlich gelöscht 1310. Unter Verwendung dieser Struktur von lebenden Segmenten können die Ähnlichkeitsgruppen (oder die Kompressionsregionen) wie beispielsweise in 1B, 11A-11C und 12A-12B erläutert bereinigt werden.
Es gilt darauf hinzuweisen, dass die vorliegende Erfindung auf zahlreiche Weisen implementiert werden kann, einschließlich als Vorgang, als Vorrichtung, als System, als Gerät, als Verfahren oder als computerlesbares Medium, wie z. B. als computerlesbares Speichermedium, oder als Computernetzwerk, in dem Computerprogrammanweisungen über optische oder elektronische Kommunikationsverbindungen gesendet werden. Anwendungen können in Form von Softwareausführung auf einem Universalrechner vorliegen oder festverdrahtet oder in Hardware fest programmiert sein. In dieser Patentschrift können diese Implementierungen oder beliebige andere Formen, in denen die Erfindung vorliegen kann, als Methoden bezeichnet werden. Im Allgemeinen kann die Reihenfolge der Schritte von offenbarten Vorgängen innerhalt des Schutzumfangs der Erfindung geändert werden.
Die hierin offenbarten Ausführungsformen können die Verwendung eines Spezial- oder Universalcomputers umfassen, der verschiedene Computer-Hardware- oder -Software-Module einschließen kann, wie nachstehend genauer erläutert wird. Ein Computer kann einen Prozessor und Computerspeichermedien umfassen, die Anweisungen enthalten, die bei Ausführung durch den Prozessor und/oder bei Bewirken ihrer Ausführung durch den Prozessor eines oder mehrere der hierin offenbarten Verfahren ausführen.
Wie oben angemerkt umfassen Ausführungsformen innerhalb des Schutzumfangs der vorliegenden Erfindung auch Computerspeichermedien, bei denen es sich um physische Medien handelt, auf denen Computer-ausführbare Anweisungen oder Datenstrukturen gespeichert sind oder die solche tragen. Solche Computerspeichermedien können beliebige verfügbare physische Medien sein, auf die Universal- oder Spezialcomputer zugreifen können. Beispielsweise und ohne Einschränkung können solche Computerspeichermedien Hardware wie ein Festkörperspeicher (SSD), RAM, ROM, EEPROM, CD-ROM, Flashspeicher, Phasenänderungsspeicher („PCM“) oder ein anderer optischer Plattenspeicher, Magnetplattenspeicher oder eine andere Magnetspeichervorrichtung oder eine beliebige andere Hardwarespeichervorrichtung sein, die zum Speichern eines Programmcodes in Form von Computer-ausführbaren Anweisungen oder Datenstrukturen verwendet werden können und auf die ein Universal- oder Spezialcomputersystem zugreifen kann, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen des Obigen sind ebenfalls im Schutzumfang der Erfindung enthalten. Solche Medien sind auch Beispiele für nichttransitorische Speichermedien, und nichttransitorische Speichermedien umfassen auch Cloud-basierte Speichersysteme und Strukturen, obwohl der Schutzumfang der Erfindung nicht auf diese Beispiele für nichttransitorische Speichermedien eingeschränkt ist. Computer-ausführbare Anweisungen umfassen beispielsweise Anweisungen und Daten, die bewirken, dass ein Universalcomputer, ein Spezialcomputer oder eine Spezialverarbeitungsvorrichtung eine bestimmte Funktion oder Gruppe von Funktionen ausführt. Obwohl der Gegenstand in einer Sprache beschrieben wurde, die für Strukturmerkmale und/oder methodologische Aktionen spezifisch ist, versteht sich, dass der in den beiliegenden Ansprüche definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Aktionen eingeschränkt ist. Vielmehr sind die hierin offenbarten spezifischen Merkmale und Aktionen als beispielhafte Formen zur Implementierung der Ansprüche offenbart.
Wie hierin verwendet kann sich die Bezeichnung „Modul“ oder „Komponente“ auf Softwareobjekte oder Routinen beziehen, die auf dem Rechensystem laufen. Die verschiedenen Komponenten, Module, Engines und Dienste, die hierin beschrieben wurden, können als Objekte oder Vorgänge implementiert werden, die auf dem Rechensystem laufen, beispielsweise als separate Threads. Während das System und die Verfahren, die hierin beschrieben wurden, in Software implementiert werden können, sind auch Implementierungen in Hardware oder eine Kombination aus Software und Hardware möglich und vorgesehen. In der vorliegenden Offenbarung kann eine Recheneinheit' jedes beliebige Rechensystem wie hierin zuvor definiert oder ein beliebiges Modul oder eine Kombination aus Modulen, die auf einem Rechensystem laufen, sein.
Zumindest in einigen Fällen wird ein Hardware-Prozessor bereitgestellt, der betreibbar ist, um ausführbare Anweisungen zur Ausführung eines Verfahrens oder Vorgangs auszuführen, wie beispielsweise die hierin offenbarten Verfahren und Vorgänge. Der Hardware-Prozessor kann anderes Hardware-Element, wie z. B. die hierin offenbarten Rechenvorrichtungen und Systeme, umfassen oder nicht.
In Bezug auf Rechenumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, seien es Netzwerk- oder lokale Umgebungen, oder in einer beliebigen anderen geeigneten Umgebung ausgeführt werden. Geeignete Betriebsumgebungen für zumindest einige Ausführungsformen der Erfindung umfassen Cloud-Rechenumgebungen, wo eines oder mehrere aus einem Client, einem Server oder einer virtuellen Zielmaschine in einer Cloud-Umgebung vorhanden sein und laufen kann.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihrem Geist oder wesentlichen Merkmalen abzuweichen. Die beschriebenen Ausführungsformen sind in allen Hinblicken lediglich als veranschaulichend und nicht als einschränkend zu sehen. Der Schutzumfang der Erfindung ist daher durch die beiliegenden Ansprüche gegeben und nicht durch die vorstehende Beschreibung. Alle Änderungen, die innerhalb der Bedeutung und des Äquivalenzumfangs der Ansprüche liegen, sind in ihren Schutzumfang eingeschlossen.

Claims

Verfahren zum Markieren von Ähnlichkeitsgruppen, die von einer Freispeichersammeloperation betroffen sind, die in einem Speichersystem ausgeführt wird, wobei das Verfahren umfasst: Empfangen einer Liste von Löschprotokollen, die Objekte identifizieren, die aus dem Speichersystem gelöscht werden sollen; Identifizieren von Tranchen-Recipes für die Objekte, die gelöscht werden sollen, aus den Löschprotokollen; Markieren von Ähnlichkeitsgruppen, die den Tranchen-Recipes zugeordnet sind, als betroffene Ähnlichkeitsgruppen, die Segmenten der Objekte in den Löschprotokollen zugeordnet sind, und Erzeugen eines Mappings der betroffenen Ähnlichkeitsgruppen in einer Mapstruktur, die lebende Segmente in den betroffenen Ähnlichkeitsgruppen identifiziert, wobei es die Mapstruktur ermöglicht, tote Segmente, die den zu löschenden Objekten zugeordnet sind, zu identifizieren und aus den betroffenen Ähnlichkeitsgruppen zu entfernen.
Verfahren nach Anspruch 1, das außerdem das Bereinigen der betroffenen Ähnlichkeitsgruppen umfasst.
Verfahren nach Anspruch 2, das außerdem das Bereinigen von Kompressionsregionen, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, oder das Bereinigung von nur betroffenen Kompressionsregionen, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, umfasst.
Verfahren nach Anspruch 1, wobei die Liste von Löschprotokollen Objekte umfasst, die nicht fertig geschrieben wurden.
Verfahren nach Anspruch 1, das außerdem das Identifizieren der lebenden Segmente umfasst, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, indem die lebenden Objekte beurteilt werden.
Verfahren nach Anspruch 5, Erzeugen der Mapstruktur, welche die lebenden Segmente mit den Kompressionsregionen der betroffenen Ähnlichkeitsgruppen mappt, wobei Segmente in der Mapstruktur, die nicht markiert sind, toten Segmenten in den Kompressionsregionen der betroffenen Ähnlichkeitsgruppen entsprechen.
Verfahren nach Anspruch 5, das außerdem das Zuweisen der lebenden Objekte zu einer Vielzahl von Workern zur Beurteilung und das Zuweisen der betroffenen Ähnlichkeitsgruppen zu einer Vielzahl von Workern umfasst, die konfiguriert sind, um die betroffenen Ähnlichkeitsgruppen zu bereinigen.
Verfahren nach Anspruch 8, das außerdem das Bereinigen der betroffenen Ähnlichkeitsgruppen basierend auf den Kompressionsregionen umfasst, wobei lebende Segmente in den betroffenen Kompressionsregionen in eine neue Kompressionsregion übertragen werden und die alte Kompressionsregion als Gesamtes aus dem Speichersystem gelöscht wird.
Verfahren nach Anspruch 1, das außerdem das Entfernen der Löschprotokolle umfasst.
Nichttransitorisches computerlesbares Medium, das Computer-ausführbare Anweisungen zur Implementierung eines Verfahrens zum Markieren von Ähnlichkeitsgruppen umfasst, die von einer Freispeichersammeloperation betroffen sind, die in einem Speichersystem ausgeführt wird, wobei das Verfahren umfasst: Empfangen einer Liste von Löschprotokollen, die Objekte identifizieren, die aus dem Speichersystem gelöscht werden sollen; Identifizieren von Tranchen-Recipes für die Objekte, die gelöscht werden sollen, aus den Löschprotokollen; Markieren von Ähnlichkeitsgruppen, die den Tranchen-Recipes zugeordnet sind, als betroffene Ähnlichkeitsgruppen, die Segmenten der Objekte in den Löschprotokollen zugeordnet sind, und Erzeugen eines Mappings der betroffenen Ähnlichkeitsgruppen in einer Mapstruktur, die lebende Segmente in den betroffenen Ähnlichkeitsgruppen identifiziert, wobei es die Mapstruktur ermöglicht, tote Segmente, die den zu löschenden Objekten zugeordnet sind, zu identifizieren und aus den betroffenen Ähnlichkeitsgruppen zu entfernen.
Verfahren nach Anspruch 10, das außerdem das Bereinigen der betroffenen Ähnlichkeitsgruppen umfasst.
Verfahren nach Anspruch 11, das außerdem das Bereinigen von Kompressionsregionen, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, oder das Bereinigung von nur betroffenen Kompressionsregionen, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, umfasst.
Verfahren nach Anspruch 10, wobei die Liste von Löschprotokollen Objekte umfasst, die nicht fertig geschrieben wurden.
Verfahren nach Anspruch 10, das außerdem das Identifizieren der lebenden Segmente umfasst, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, indem die lebenden Objekte beurteilt werden.
Verfahren nach Anspruch 14, Erzeugen der Mapstruktur, welche die lebenden Segmente mit den Kompressionsregionen der betroffenen Ähnlichkeitsgruppen mappt, wobei Segmente in der Mapstruktur, die nicht markiert sind, toten Segmenten in den Kompressionsregionen der betroffenen Ähnlichkeitsgruppen entsprechen.
Verfahren nach Anspruch 15, das außerdem das Zuweisen der lebenden Objekte zu einer Vielzahl von Workern zur Beurteilung und das Zuweisen der betroffenen Ähnlichkeitsgruppen zu einer Vielzahl von Workern umfasst, die konfiguriert sind, um die betroffenen Ähnlichkeitsgruppen zu bereinigen.
Verfahren nach Anspruch 16, das außerdem das Bereinigen der betroffenen Ähnlichkeitsgruppen basierend auf den Kompressionsregionen umfasst, wobei lebende Segmente in den betroffenen Kompressionsregionen in eine neue Kompressionsregion übertragen werden und die alte Kompressionsregion als Gesamtes aus dem Speichersystem gelöscht wird.
Verfahren nach Anspruch 10, das außerdem das Entfernen der Löschprotokolle umfasst.
Verfahren zum Markieren von Ähnlichkeitsgruppen, die von einer Freispeichersammeloperation betroffen sind, die in einem Speichersystem ausgeführt wird, wobei das Verfahren umfasst: Empfangen einer Liste von Löschprotokollen, die Objekte identifizieren, die aus dem Speichersystem gelöscht werden sollen; Instanziieren einer Vielzahl von Workern; Identifizieren von Ähnlichkeitsgruppen aus den Löschprotokollen als betroffene Ähnlichkeitsgruppen, wobei die betroffenen Ähnlichkeitsgruppen Segmente speichern, die den zu löschenden Objekten zugeordnet sind, in Kompressionsregionen speichern; Beurteilen, mittels der Vielzahl von Workern, lebender Objekte oder lebender Recipes der lebenden Objekte, um betroffene lebende Objekte zu identifizieren, die den betroffenen Ähnlichkeitsgruppen zugeordnet sind, Erzeugen von Mapstrukturen für die Kompressionsregionen in der betroffenen Ähnlichkeitsgruppe; Identifizieren lebender Segmente von den lebenden Objekten oder den lebenden Recipes und entsprechendes Markieren der Mapstrukturen, sodass die Mapstrukturen identifizieren, welche Segmente in den Kompressionsregionen lebende Segmente sind und welche der Segmente tote Segmente sind, wobei die toten Segmente von keinem der lebenden Objekte oder Recipes der lebenden Objekte referenziert werden; Bereinigen der Kompressionsregionen der toten Segmente mittels der Vielzahl von Workern, sodass nur die lebenden Segmente übrigbleiben.
Verfahren nach Anspruch 19, das außerdem das Bereinigen von nur jenen Kompressionsregionen umfasst, bei denen ein Verhältnis von toten Segmenten zu lebenden Segmente größer als eine vorbestimmte Schwelle ist.