DE102021109729A1

DE102021109729A1 - Schätzung der nutzung der speichersystemkapazität

Info

Publication number: DE102021109729A1
Application number: DE102021109729.0A
Authority: DE
Inventors: Glenn Watkins; Peter Madany; John Czerkowicz
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-07-27
Filing date: 2021-04-19
Publication date: 2022-01-27
Also published as: CN113986826A; US11481371B2; CN113986826B; US20220027334A1

Abstract

Es werden Techniken und Architekturen zur Abschätzung der Kapazität von Speichersystemen offengelegt. Deduplizierte Daten und ein Index von Objekteinträgen werden in einem Speichersystem verwaltet. Die Einträge enthalten flache Referenzwerte. Die flachen Referenzzählwerte zeigen eine Anzahl von übergeordneten Metadatenobjekten an, die einen Verweis auf das entsprechende Objekt enthalten. Ein oder mehrere Baum-Milli-Indizes und ein oder mehrere Knoten-Milli-Indizes von Objekteinträgen werden im Speichersystem verwaltet. Die Einträge entsprechen einer Teilmenge der im Speichersystem gespeicherten Objekte. Die Einträge haben auch verkürzte Objektsignaturwerte und tiefe Referenzzählwerte für die entsprechenden Objekte im Speichersystem. Die Kapazitätsauslastung des Speichersystems wird auf der Grundlage einer Analyse ermittelt, bei der die Deep-Reference-Count-Werte zur Durchführung verschiedener Multiset-Operationen verwendet werden.

Description

HINTERGRUND
In vielen komplexen Computerumgebungen werden verteilte Computerressourcen zusammen mit verteilten Speicherressourcen verwendet. Diese komplexen Datenverarbeitungsumgebungen erfordern ein hohes Maß an Vernetzung und Optimierung. Eine Reihe von Strategien bezieht sich auf die Deduplizierung von Daten innerhalb der Speicherressourcen.
Figurenliste
Ausführungsformen der Erfindung sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich gleiche Bezugsziffern auf ähnliche Elemente beziehen.

1 ist ein schematisches Blockdiagramm einer Ausführungsform eines Knotens.
2 zeigt ein Beispiel für einen Datenpfad.
3 veranschaulicht eine Ausführungsform eines Objektspeichers.
4 ist eine konzeptionelle Darstellung einer Zuordnung von einem vollständigen Index zu einem Milli-Index.
Die 5A-5C enthalten konzeptionelle Darstellungen von Beispielbäumen, die die Grundlage für entsprechende Milli-Indizes bilden können.
6 ist ein Flussdiagramm einer Technik zur Schätzung der Systemspeicherkapazität unter Verwendung von Milli-Indizes und Deep-Reference-Count-Informationen.
7 ist ein computerlesbares Medium mit Anweisungen zur Bereitstellung einer Technik zur Abschätzung der Systemspeicherkapazität unter Verwendung von Milli-Indizes und Deep-Reference-Count-Informationen.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung sind zahlreiche spezifische Details aufgeführt. Ausführungsformen der Erfindung können jedoch auch ohne diese spezifischen Details ausgeführt werden. In anderen Fällen wurden bekannte Strukturen und Techniken nicht im Detail dargestellt, um das Verständnis dieser Beschreibung nicht zu beeinträchtigen.
Wie hier verwendet, ist ein „Objekt“ ein Datenblock bekannter Größe, der durch eine „Signatur“ eindeutig identifiziert werden kann, die aus einer kryptografischen Zusammenfassung der Daten selbst, der Art des Objekts und der Größe des Objekts abgeleitet ist. In alternativen Ausführungsformen kann die Definition der Signatur auch den Algorithmus umfassen, der zur Berechnung des kryptografischen Auszugs verwendet wird. Das heißt, die Signatur kann die kryptografische Auswertung, den zur Berechnung der kryptografischen Auswertung verwendeten Algorithmus, die Größe des Objekts und die Art des Objekts enthalten.
Ein „Objektdatensatz“ ist eine Datenstruktur, die eine Objektsignatur mit einer Referenzzahl und einem physischen Speicherort für die zugehörigen Daten verknüpft. Ein „Index“ ist eine Datenstruktur, die eine assoziative Zuordnung von Signaturen zu Objektdatensätzen ermöglicht. Ein „Objektspeicher“ ordnet Objektsignaturen durch Zugriff auf den Index und die Festplatte(n), auf der/denen die Daten gespeichert sind, Objektdaten zu.
In den hier beschriebenen Beispielsystemen kann ein Dateisystem mindestens zwei Arten von Objekten enthalten: 1) Datenobjekte, die undurchsichtige Benutzerobjekte enthalten, und 2) Metadatenobjekte (auch hnode-Objekte genannt), die die Objektsignaturen von Unter Objekten in einer Baumstruktur enthalten. Das Dateisystem kann als Baumstruktur organisiert sein. In verschiedenen Ausführungsformen werden Dateisystem-„Inodes“ über „Inode hnodes“, die entweder eine Datei oder ein Verzeichnis darstellen können, auf Datei-/Verzeichnisinhalte abgebildet. Die Wurzel des Dateisystembaums kann als „Dateisystemwurzelknoten“ bezeichnet werden, der eine als „Wurzelobjektsignatur“ bezeichnete Signatur aufweist.
In einigen Ausführungsformen sind die obersten N Ebenen des Dateisystembaums der „imap-Baum“, der eine Zuordnung von Inode-Nummern zu Inodehnode-Signaturen durch Indizierung der in den Blattknoten des imap-Baums gespeicherten Signaturen ermöglicht. Ein Inode hnode kann drei Signaturen enthalten: 1) eine Signatur eines Datenobjekts, das Attribute enthält; 2) eine Signatur eines Datenobjekts, das erweiterte Attribute enthält; und 3) eine Signatur des Inode Root hnode. Die Blattknoten des Baums, der im Inode Root hnode wurzelt, enthalten die Daten der Datei oder des Verzeichnisses, die mit dem Inode verbunden sind.
Wie bereits erwähnt, können Daten auf verschiedenen Arten von Rechnersystemen gespeichert werden, z. B. auf Servern, Computergeräten, Workstations, Speichersystemen oder Speicherarrays, konvergenten oder hyperkonvergenten Systemen oder Ähnlichem. Rechnersysteme, die über ein Netz verbunden sind, können als Knoten bezeichnet werden. Zur Speicherung von Daten können einige Computersysteme eine Datenvirtualisierungsplattform verwenden, die Aspekte der physischen Speicherhardware, auf der die Daten physisch gespeichert sind, abstrahiert (z. B. Aspekte wie Adressierung, Konfigurationen usw.) und einer Benutzerumgebung (z. B. einem Betriebssystem, Anwendungen, Prozessen usw.) virtualisierten oder logischen Speicher bereitstellt. Der virtualisierte Speicher kann aus mehreren Speichergeräten (z. B. Festplattenlaufwerken, Solid-State-Laufwerken usw.) in einem Datenspeicher zusammengeführt werden, aus dem der virtualisierte oder logische Speicher bereitgestellt werden kann. Die Datenvirtualisierungsplattform kann auch Datendienste wie Deduplizierung, Komprimierung, Replikation und Ähnliches bereitstellen.
Die Komponenten einer beispielhaften objektbasierten Datenvirtualisierungsplattform können unter anderem einen flachen Objektspeicher und eine oder mehrere Dateisysteminstanzen umfassen. Die Daten können als Objekte im Objektspeicher gespeichert werden. So können beispielsweise Dateien und Verzeichnisse, auf die der Benutzer zugreifen kann, aus mehreren Datenobjekten bestehen. Der Objektspeicher kann auch Metadatenobjekte speichern, die sich auf den Betrieb der Datenvirtualisierungsplattform beziehen, wie weiter unten beschrieben wird. In einem Beispiel können die Objekte im Objektspeicher eine vorgegebene feste Größe haben (z. B. 4 kb oder 8 kb für Datenobjekte und 1 kb oder 2 kb für Metadatenobjekte). Jedes Objekt kann durch seine Signatur (auch als Objekt-Fingerprint bezeichnet) identifiziert werden. Ein Objektindex kann die Signatur eines Objekts im Objektspeicher mit einer physischen Adresse des Objektinhalts (d. h. einer physischen Adresse auf der Speicherhardware, z. B. einer Festplatte) in Beziehung setzen.
Eine Dateisysteminstanz kann sich auf eine Organisation von Metadatenobjekten und Datenobjekten beziehen, die die Datenobjekte hierarchisch mit dem Stammobjekt verknüpfen. So kann eine Dateisysteminstanz durch ihr Stammobjekt identifiziert werden. Die Dateisysteminstanz kann z. B. ein Merkle-Baum oder eine andere hierarchische Anordnung sein (z. B. gerichtete azyklische Graphen usw.). Im Falle eines hierarchischen Merkle-Baums können sich die Datenobjekte auf der untersten Ebene eines jeden Zweigs befinden (d. h. am weitesten vom Stammobjekt entfernt) und auch als Blattdatenobjekte bezeichnet werden. Ein übergeordnetes Objekt enthält als Inhalt die Signaturen der untergeordneten Objekte. Ein übergeordnetes Objekt von Blattdatenobjekten ist zum Beispiel ein Metadatenobjekt, das als Inhalt die Signaturen seiner untergeordneten Blattdatenobjekte speichert. Das Wurzelobjekt und andere interne Objekte eines Baums können ebenfalls Metadatenobjekte sein, die als Inhalt die Signaturen der jeweiligen Kindobjekte speichern. Ein Metadatenobjekt kann eine Anzahl von Signaturen speichern, die mindestens dem Verzweigungsfaktor des hierarchischen Baums entspricht, so dass es die Signaturen aller seiner untergeordneten Objekte enthalten kann.
Eine Folge der Datendeduplizierung kann eine Verringerung der Informationen über die Kapazitätsauslastung sein. Eine weitere Folge kann die Schwierigkeit sein, die Ressourcen abzuschätzen, die durch das Löschen (oder Verschieben) eines oder mehrerer Datensätze aus einem Speichersystem freigesetzt werden können, und die Schwierigkeit, die Ressourcen abzuschätzen, die durch das Verschieben eines oder mehrerer Datensätze in ein zweites Speichersystem verbraucht werden würden
Beschrieben werden hier Techniken zur Kapazitätsabschätzung von Speichersystemen auf der Grundlage von Stichproben, Signaturen und tiefen Referenzzählungen. Insbesondere beziehen sich die Ausführungsformen auf Techniken zur Schätzung des Kapazitätsverbrauchs für Speichersysteme, die flache Referenzzählungen verwenden, um Datenmanagement und Deduplizierung zu unterstützen, z. B. Sampling, tiefe Referenzzählungen und Multiset-Operationen. In verschiedenen Ausführungsformen können Merkle-Bäume mit flachen Referenzzählungen verwendet werden, die nur auf der Ebene, auf der eine gemeinsame Nutzung stattfindet, erhöht/verringert werden.
In Beispielimplementierungen können die Daten einer oder mehrerer virtueller Gastmaschinen von einer oder mehreren Dateisysteminstanzen gespeichert werden (z. B. eine Gast-VM, die den Speicher von mehreren Dateisysteminstanzen nutzt, viele Gast-VMs, die den Speicher von einer einzigen Dateisysteminstanz nutzen, oder eine beliebige Variante dazwischen). In einem Beispiel kann jede virtuelle Gastmaschine eins-zu-eins mit einer entsprechenden Dateisysteminstanz verbunden sein. Die Datenvirtualisierungsplattform kann einen Einhängepunkt für das Dateiprotokoll exportieren (z. B. einen NFS- oder SMB-Einhängepunkt), über den eine virtuelle Gastmaschine auf den von einer Dateisysteminstanz bereitgestellten Speicher über den Namensraum des Dateiprotokolls zugreifen kann.
In einigen Implementierungen erfolgt dieser Gastzugang über eine von einem Hypervisor bereitgestellte vSCSI-Schicht, die SCSI-Operationen auf Dateioperationen abbildet. In anderen Implementierungen kann eine Dateisysteminstanz mit anderen Speichereinheiten verknüpft sein und der Zugriff darauf erfolgen, z. B. über ein Block-Volume, eine an das Netzwerk angeschlossene Speicherfreigabe, ein Container-Volume usw. In einigen Implementierungen können Objekte in einem Objektspeicher mehr als einmal in einer einzelnen Dateisysteminstanz referenziert werden oder mehrfach in Dateisysteminstanzen referenziert werden. So kann das mehrfach referenzierte Objekt einmal gespeichert, aber mehrfach referenziert werden, um eine Deduplizierung zu ermöglichen.
1 ist ein schematisches Blockdiagramm einer Ausführungsform eines Knotens. Der Knoten 100 kann beispielsweise ein hyperkonvergenter Infrastrukturknoten mit einer softwarezentrierten Architektur sein, die Rechen-, Speicher, Netzwerk- und Virtualisierungsressourcen sowie andere Technologien eng integriert. Knoten 100 kann eine beliebige Anzahl von virtuellen Gastmaschinen (VMs) 102, 104 und 106 hosten und kann so konfiguriert werden, dass er lokale und entfernte Backups und Snapshots der virtuellen Maschinen erstellt. In einigen Beispielen kann eine Vielzahl solcher Knoten in einem Netzwerk angeordnet sein, wie unten beschrieben.
In einigen Beispielen kann der Knoten 100 eine virtuelle Anwendung 108 und einen Hypervisor 110 umfassen. Das virtuelle Gerät 108 kann ein virtuelles Dateisystem 112 enthalten, das mit der Steuerungsebene 114 und dem Datenpfad 116 kommuniziert. Die Steuerebene 114 kann den Datenfluss zwischen Anwendungen und Ressourcen innerhalb des Knotens 100 steuern. Der Datenpfad 116 kann eine geeignete E/A-Schnittstelle zwischen dem virtuellen Dateisystem 112 und dem Betriebssystem (OS) 118 bereitstellen und auch Funktionen wie Datenkompression, Deduplizierung und Optimierung ermöglichen.
Der Knoten 100 kann auch Hardwarekomponenten enthalten, die vom Hypervisor 110 verwaltet werden. So kann der Knoten 100 beispielsweise einen Speicher 120 enthalten, der ein RAID-Speicher-Controller oder ein Host-Bus-Adapter mit Verbindungen zu einer Reihe von Festplattenlaufwerken (HDDs) 122 und/oder Solid-State-Laufwerken (SSDs) 124 sein kann. Der Knoten 100 kann auch einen Speicher 126 (z.B. RAM, ROM, Flash, etc.) und einen oder mehrere Prozessoren 128 enthalten. Der Knoten 100 kann auch drahtlose und/oder drahtgebundene Netzwerkschnittstellenkomponenten 130 enthalten, um die Kommunikation mit anderen Knoten zu ermöglichen. In einigen Ausführungsformen können die Knoten auch eine Beschleunigerkarte enthalten, die Rechenleistung und/oder nichtflüchtigen Arbeitsspeicher bereitstellen kann (in 1 nicht dargestellt).
2 zeigt ein Ausführungsbeispiel für einen Datenpfad. In verschiedenen Ausführungsformen kann der Datenpfad 116 mit dem Replikationsmanager 200 kommunizieren, der so konfiguriert ist, dass er zumindest Fernsicherungsvorgänge durchführt. Der Datenpfad 116 kann auch das Dateisystem 202 enthalten, das mit der Steuerebene 114 kommuniziert. In einer Ausführungsform ist das Dateisystem 202 für die Verwaltung von Dateisystemkomponenten innerhalb des Datenpfads 116 verantwortlich, z. B. durch die Instanziierung von Dateisystemkomponenten, die Verwaltung von Verzeichnissen und Dateien innerhalb dieser Verzeichnisse und Ähnliches.
Das Dateisystem 202 kann auch die E/A-Verarbeitungskapazitäten des Knotens bestimmen und eine hohe Verfügbarkeit implementieren, indem es z. B. Datenschreibvorgänge vom primären Knoten (z. B. Knoten 100) auf einen sekundären Knoten spiegelt. Das Dateisystem 202 bietet außerdem sowohl synchrone als auch asynchrone Datenübertragungsschnittstellen für verschiedene Komponenten innerhalb des Datenpfads 116. Der Objektspeicher 204 und der Speichermanager 206 sind für die E/A-Operationen von Datenobjekten zwischen dem Datenpfad 116 und dem E/A-Subsystem 208 zuständig.
3 veranschaulicht eine Ausführungsform eines Objektspeichers. In einer Ausführungsform enthält der Objektspeicher 310 binäre, undurchsichtige Objekte, z. B. P 312, Q 314 bzw. R 316. Die Objekte können unterschiedlich groß sein, wobei sie in einer Implementierung Potenzen von 2 sind. Ein Objekt befindet sich an einem bestimmten Offset im Container, bei dem es sich um einen Byte-Offset oder einen Offset modulo der kleinsten Objektgröße handeln kann (d. h., wenn das kleinste Objekt 512 Byte groß ist, würde der Offset mit 512 multipliziert werden, um den Byte-Offset zu erhalten).
Wie bereits erwähnt, hat jedes Objekt einen Namen, der hier als Signatur (oder Fingerabdruck) bezeichnet wird und eine kryptografische Zusammenfassung (z. B. Hash) des Objektinhalts darstellt. Die Objektnamen (Signaturen) werden zum Beispiel mit H(p), H(q) und H(r) bezeichnet. Auf diese Weise kann jedes Objekt, das Daten und/oder Metadaten enthalten kann, eine weltweit eindeutige Signatur haben, die aus dem Inhalt seiner Daten abgeleitet wird.
Im Beispiel von 3 werden in der Indexstruktur 325 Objektnamen, Objektstandorte und Objektverweise gespeichert. In diesem deduplizierten Dateisystem und Objektspeicher kann eine einzige Kopie jedes eindeutigen Daten- oder Metadatenobjekts gespeichert werden, das durch seine Signatur identifiziert wird. Die Referenz eines Objekts wird jedes Mal erhöht, wenn das Objekt geschrieben wird. Mit anderen Worten: Während das Dateisystem viele „Kopien“ desselben Objekts erzeugen kann, speichert der Objektspeicher 310 nur eine einzige und verfolgt, wie viele der Namensraum hat, sowie die entsprechende Zuordnung. Auf diese Weise ist die Deduplizierung systemeigen.
Der Objektspeicher 310 kann mehrere Schnittstellenklassen 352a-d haben. Die Lese-, Schreib- und Löschschnittstelle 352a führt die genannten Funktionen aus. In diesem Zusammenhang ist das Löschen eines Objekts funktionell eine Dekrementierung der Referenzzahl des Objekts. Der Speicher für das Objekt innerhalb des Objektspeichers wird freigegeben, wenn der Referenzzähler auf 0 geht. Indizierungsoperationen 352b ermöglichen die Aufzählung von Objekten nach Namen, die Anpassung des Referenzzählers und das Nachschlagen von Objekten nach Namen. Der Objektspeicher 310 verfügt über eine transaktionale Semantik (ACID-Eigenschaften), und Transaktionsgrenzen werden durch transaktionale Operationen 352c verwaltet. Dazu gehören das Starten, Übertragen und Abbrechen einer Transaktion sowie die Auflistung anstehender Transaktionen. Über die Bereitstellungsschnittstelle 352d können Objektspeicher erstellt, gelöscht, zusammengeführt, aufgeteilt und aggregiert werden.
In einer Ausführungsform ist der Index 325 eine Karte, deren Primärschlüssel der Objektname (Signatur) ist. Für jedes Objekt im System gibt es einen Indexeintrag. In einer Ausführungsform enthält jeder Eintrag mindestens: 1) eine Signatur des Objektinhalts (Signaturen werden z. B. durch einen kryptografischen Digest (Hash) des Inhalts erzeugt); 2) eine Referenzzahl, die angibt, wie oft auf das Objekt verwiesen wird; 3) einen Speicherort; und 4) Flags für verschiedene Verwendungszwecke.
In einer Ausführungsform kann die Referenzzählung eine Sättigungsarithmetik verwenden, um Platz zu sparen. Beispielsweise kann der Index 325 nur 8 Bits zur Verfolgung von Referenzen verwenden: Die Referenzzahl kann addiert und dekrementiert werden, aber wenn sie 255 erreicht oder überschreitet, ist die Zahl „gesättigt“ und weitere Dekremente sind nicht mehr zulässig. Da Objekte Verweiszahlen haben, ist die Deduplizierung in dem Maße, wie es identische Objekte gibt, systemeigen. Befindet sich das Objekt auf einer physischen Festplatte, kann der Speicherort eine logische Blocknummer LBN sein. Wenn das Objekt von einem Hosting-Anbieter gehostet wird (z. B. Amazon S3), kann es sich um einen Verweis auf das Cloud-Objekt handeln. Ein Kennzeichen gibt an, ob das Objekt komprimiert oder nicht komprimiert gespeichert ist, ein anderes, ob es verschlüsselt ist oder nicht. Andere Flags sind verfügbar, aber nicht für eine bestimmte Verwendung vorgesehen.
In einer Ausführungsform ist die Zuweisungskarte 320 eine Bitmap, die für zugewiesene Blöcke im Objektcontainer 330 verwendet wird. Der Objektcontainer 330 ist eine zufällig adressierbare, dauerhafte Speicherabstraktion. Beispiele sind eine rohe LUN, eine Datei, eine Partition auf einer Festplatte oder ein iSCSI-Gerät über ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) (d. h. ein Telekommunikationsnetz oder ein Computernetz, das sich über eine große geografische Entfernung erstreckt, z. B. eine Entfernung von mehr als 60 Meilen). Der Objektcontainer 330 kann aus mehreren Komponenten 340-348 bestehen. Abgesehen von dem Container-Deskriptor-Block 340, der sich an einem bekannten Offset befindet, ist die Reihenfolge der anderen Komponenten nicht wesentlich. Der Objektindex 330 kann containerresidente Teile oder Teile des Index 325 oder beides enthalten, z. B. einen B-Baum oder eine andere Baumstruktur. Die Zuordnungsliste 320 kann sich auch teilweise auf der Festplatte und im Index 342 befinden. Die Migration zwischen den beiden kann mit Paging-Techniken durchgeführt werden.
Wenn der Objektspeicher geändert wird, wird das Transaktionsprotokoll 348 auf dem permanenten Speicher gehalten. Das Transaktionsprotokoll 348 verfolgt alle Objektaktivitäten, einschließlich Lese-, Schreib- und Löschvorgänge, Referenzanpassungen usw. In einer Ausführungsform wird das Transaktionsprotokoll 348 in zeitlicher Reihenfolge geführt und periodisch in den Hauptindex 342 übernommen. In einer Ausführungsform wird die Objektaktivität im Protokoll zuerst durchsucht, bevor der Hauptindex durchsucht wird. Jeder Protokolleintrag besteht aus einer Vorgangsart 352a, 352b, 352c, 352d, dem Fingerabdruck, der Referenzanzahl, der Transaktions-ID oder Epochennummer und dem Standort. Ein Protokolleintrag ähnelt strukturell einem Indexeintrag, mit dem Zusatz der Transaktions-ID.
Die globale Objektbenennung ermöglicht es dem Objektspeicher, Objekte zu verschieben und dabei eine konsistente Benennung und einen einheitlichen Zugriff beizubehalten. Gründe für das Verschieben eines Objekts sind beispielsweise: 1) Verschieben zusammengehöriger Objekte in der Nähe voneinander auf einer physischen Festplatte aus Leistungsgründen; 2) Replizieren von Objekten über Fehlergrenzen hinweg (z. B. über zwei lokale Festplatten, eine lokale Festplatte und eine entfernte Festplatte oder mehrere davon); 3) Hintergrundoperationen an Objekten wie Komprimierung, Dekomprimierung, Verschlüsselung, Entschlüsselung; oder 4) Verschieben von Objekten auf der Grundlage ihrer Häufigkeit oder der erwarteten Häufigkeit ihrer Verwendung. Die Replikation kann auch Vorteile bei der Leseleistung bringen. Die Replikation kann auch die Aufteilung von Objekten beinhalten, wie z. B. bei Löschcodes.
Wie bereits erwähnt, stellt die Verwendung von Deduplizierungstechniken in Speichersystemen im Vergleich zu Systemen ohne Deduplizierung eine besondere Herausforderung für die Verwaltung dar. Grundlegende Kapazitätsinformationen wie die verfügbare Speicherkapazität lassen sich in deduplizierten Systemen nicht so einfach ermitteln wie in nicht-duplizierten Systemen. Die meisten Statistiken, die in nichtdeduplizierten Systemen verfügbar sind, sind additiv (oder können von additiven Statistiken abgeleitet werden). Zum Beispiel kann die genutzte Speicherkapazität bei jeder Transaktion erhöht oder verringert werden, um nützliche Informationen zu erhalten. In deduplizierten Systemen kann das Verschieben eines Datensatzes von einem Knoten zu einem anderen zu vorher nicht vorhersehbaren und möglicherweise ungleichen Kapazitätsänderungen an jedem Knoten führen, z. B. könnte die Menge des wiedergewonnenen Speicherplatzes im ersten Knoten geringer, gleich oder größer sein als die Menge des verbrauchten Speicherplatzes im zweiten Knoten.
Die hier beschriebenen Techniken liefern nützliche Informationen über das Speichersystem, z. B. darüber, wie viel Kapazität durch verschiedene Aktionen wiedergewonnen werden kann (z. B. wie viel Platz frei wird, wenn ein Datensatz aus einem Knoten entfernt wird (der „wiedergewinnbare Platz“ des Datensatzes in Bezug auf den Knoten, in dem er derzeit gespeichert ist). Andere ähnliche Arten von Statistiken können ebenfalls unterstützt werden.
In verschiedenen Ausführungsformen werden flache Referenzzählungen verwendet, um Statistiken zu erstellen, die für die Verwaltung des Speichersystems verwendet werden. Der Begriff „shallow reference count“ bezieht sich auf die Anzahl der übergeordneten Metadatenobjekte, die einen Verweis auf das Objekt enthalten, und nicht darauf, wie viele Bäume einen Verweis auf das Objekt enthalten oder wie oft ein Objekt in einer Datei oder einem Dateisystem vorkommt. Um festzustellen, ob ein Objekt nur in einem bestimmten Baum vorkommt, kann es erforderlich sein, den Baum zu durchlaufen, um festzustellen, ob die Anzahl der Verweise auf ein übergeordnetes Objekt im Pfad zur Wurzel nicht durch Löschen des Baums auf Null reduziert würde. In einer Ausführungsform kann dieser Aufwand vermieden werden, indem eine separate Datenstruktur mit tiefen Referenzzählungen von nur stichprobenartigen Objekten geführt wird.
In einigen Ausführungsformen können Milli-Indizes auf Anwendungs-, Hive- oder Knotenebene verwendet und als Multisets behandelt werden. Multiset-Operationen, die Änderungen des Speicherverbrauchs auf der Grundlage verschiedener Datensatzoperationen (z. B. Verschieben von Daten von einem Knoten zu einem anderen, Löschen eines oder mehrerer Datensätze) vorhersagen, können unterstützt werden. Der Begriff „Hive“ bezieht sich auf einen Datensatz mit Daten und einem zugehörigen baumstrukturierten Dateisystem, wie oben beschrieben. Ein Hive kann hier auch als Dateisysteminstanz bezeichnet werden.
In einigen Ausführungsformen ähnelt ein Milli-Index den oben erörterten Indizes, mit der Ausnahme, dass: 1) der Milli-Index nur Signaturen speichert, die eine kleine Anzahl möglicher Objektsignaturen repräsentieren (z.B. unter Verwendung von Sampling-Techniken, wie z.B. die ersten N (z.B. 13, 15, 9) Bits des Hashes sind klar); 2) nur eine Teilmenge jeder Signatur (z.B. nur die ersten M (z.B. 64, 32, 128) Bits); und 3) tiefe Referenzzählungen beibehalten werden. Diese Deep-Reference-Counts können so bemessen sein (z. B. 32 Bits), dass sie der erwarteten Redundanz innerhalb des Systems entsprechen (z. B. bis zu 4 Milliarden logische Vorkommen desselben Objekts).
In einem Hive mit 1 TiB (2^40 Byte) von Nicht-Null-Daten, die alle eindeutig sind, wobei N = 13 und M = 64 und die Größe eines Datenobjekts 2^13 Byte, d. h. 8 KiB beträgt, enthalten die Milli-Indizes etwa 2^(40-(13+13)) Signaturen oder etwa 16K Einträge. Die größenreduzierten Signaturen selbst sollten etwa 128 KiB verbrauchen, während die tiefen Referenzzählungen weitere 64 KiB verbrauchen sollten.
In einigen Ausführungsformen kann jeder Milli-Index persistiert werden, um zu vermeiden, dass der Milli-Index für jede Anfrage neu erstellt wird, und um Kapazitätsschätzungen in Echtzeit zu erfüllen. In einigen Ausführungsformen werden bei eingehenden Schreibvorgängen Intent-Log-Einträge erzeugt, um Aktualisierungen der hnode-Baumstruktur zu verfolgen. Dadurch wird vermieden, dass die Merkle-Baumstruktur zum Zeitpunkt des ersten Schreibvorgangs bis hin zur Wurzel des Baums aktualisiert werden muss. Dieser Prozess der asynchronen Anwendung von Intent-Log-Einträgen auf den Merkle-Baum kann als „Rollup“ des Merkle-Baums bezeichnet werden.
In einigen Ausführungsformen werden Milli-Indizes nur mit tiefen Referenzzahlen für die unterste Ebene des Merkle-Baums verwendet. In einigen Ausführungsformen erfolgt beim Rollup-Prozess auf dieser untersten Ebene ein zusätzlicher Schritt, um den Milli-Index des Baums für alle Datenobjekte zu aktualisieren, die die Stichprobenkriterien erfüllen. Dies beinhaltet sowohl das Erhöhen des Referenzzählers für Stichprobenunterschriften, die geschrieben werden, als auch das Verringern des Referenzzählers für Stichprobenunterschriften, die überschrieben werden. Dies kann als atomarer Vorgang erfolgen, um die Konsistenz des/der Milli-Index(s) in Bezug auf den Inhalt des Speichersystems im Falle eines Fehlers (z. B. Softwareabsturz oder Stromunterbrechung) zu gewährleisten. In einigen Ausführungsformen können die Milli-Indizes auch als Merkle-Bäume dargestellt werden, wobei sich die abgetasteten Signaturen und ihre Referenzzahlen auf der untersten Ebene des Baums befinden. Absichtsprotokolle können als Mechanismus verwendet werden, um atomare Aktualisierungen des/der Milli-Index(s) bereitzustellen.
In einigen Ausführungsformen wird jeder Milli-Index eines Baums als Datei/Knoten in dem entsprechenden Hive-Baum selbst gespeichert, so dass ein Schnappschuss des Hive-Baums den Milli-Index erfasst, der die Stichproben dieses einzelnen Baum-Schnappschusses darstellt. Ein Snapshot-Vorgang kann auch den Milli-Index des Knotens für jedes in diesem Snapshot-Baum enthaltene Objekt aktualisieren. Dazu wird die Anzahl der Knoten-Milli-Index-Datensätze um den Betrag erhöht, der im Milli-Index des Snapshot-Baums enthalten ist. Umgekehrt kann das Löschen eines vorhandenen Schnappschusses dazu führen, dass der Milli-Index des Baums vom Milli-Index des Knotens subtrahiert wird.
So werden in einigen Ausführungsformen als Reaktion auf eine Snapshot-Anforderung die ausstehenden Intent-Log-Einträge für die ausstehenden Intent-Log-Einträge für den Baum aufgerollt. Das Ergebnis ist ein statischer Baum mit stabilen Milli-Index(s). Die Milli-Indizes des Baums werden zu den Milli-Indizes der Knoten addiert, um die Anzahl der zusätzlichen Tiefenreferenzen zu berücksichtigen. Ein Milli-Index kann selbst als Baum dargestellt werden, der auf der untersten Ebene die Signaturen der abgetasteten Objekte enthält. In einigen Implementierungen kann die Anzahl der Milli-Index-Wurzelsignaturreferenzen dauerhaft und zeitversetzt erhöht werden, wie in U.S. Pat. Nr. 10,587,454 , das am 10. März 2020 Watkins et al. erteilt wurde, in einer Weise erhöht werden, dass die vollständigen tiefen Referenzzahlen der darin enthaltenen abgetasteten Signaturen an den/die Milli-Index(s) weitergegeben werden. Dies ist eine Technik, die eine vollständige Momentaufnahme ermöglicht.
4 ist eine konzeptionelle Darstellung eines Mappings von einem vollständigen Index zu einem Milli-Index. In einigen Ausführungsformen kann ein vollständiger Index (z. B. 400) auf jedem Knoten vorhanden sein und dazu dienen, Objektdatensätze unter Verwendung einer Strategie der flachen Referenzzählung zu verfolgen. Diese Strategie kann für die Deduplizierung auf hohen Ebenen des Merkle-Baums optimiert werden, um den mit der Aktualisierung jedes Objektindexeintrags auf niedrigeren Baumebenen verbundenen Systemaufwand zu verringern.
Derselbe Index kann verwendet werden, um die Anzahl der tiefen Verweise auf Knotenebene für Zwecke des Milli-Index (z. B. 450) zu verfolgen. Wenn er als gemeinsame Struktur für die Persistenz aller Objektdatensätze verwendet wird, kann der vollständige Index 400 die Anzahl der flachen Verweise für Metadatenobjekte und nicht abgetastete Datenobjekte speichern. In einigen Ausführungsformen kann der vollständige Index 400 vollständig persistent sein, und die entsprechende Milli-IndexStruktur 450 kann als teilweiser Cache des vollständigen Index 400 behandelt werden, der nur die für die Kapazitätsschätzungsfunktionalität benötigten Stichproben verfolgt.
In einigen Ausführungsformen wird bei der Aktualisierung eines abgetasteten Objektdatensatzes (z. B. 410, 412, 414, 416, 418) im vollständigen Index 400 der entsprechende Datensatz (z. B. 460, 462, 464, 466) im Milli-Index 450 ebenfalls aktualisiert. Im Beispiel von 4 ist jede Hash mit einer führenden Null im vollständigen Index 450 für die Abtastung des Milli-Index geeignet. Im Falle einer Kollision (z. B. 416, 418) beim Abschneiden des Hashes können beide Datensätze im Milli-Index zusammengeführt werden (z. B. 466), um die insgesamt hinzugefügten Referenzzahlen zu berücksichtigen.
Die 5A-5C enthalten konzeptionelle Darstellungen von Beispielbäumen, die die Grundlage für entsprechende Milli-Indizes bilden können. Ein Milli-Index kann als Beispiel für ein Multiset betrachtet werden. Das Beispiel in den 5A-5C zeigt eine Reihe von Bäumen (z. B. 600, 620, 640, 660, 680), die mit Milli-Indizes verbunden sind.
Das Beispiel in den 5A-5C basiert auf 8-Byte-Hashes, es können jedoch Hashes jeder Größe unterstützt werden. Ferner basiert das Beispiel der 5A-5C auf einer Abtastrate von 1/N, wobei N=2 ist, was bedeutet, dass der Milli-Index etwa einen von zwei Datenhashes enthält. Für N kann jeder beliebige Wert verwendet werden, z. B. auch Werte in der Größenordnung von Hunderten oder Tausenden. Der spezifische Wert für N kann z. B. so gewählt werden, dass er platzsparend ist und dennoch die gewünschten Vorteile bietet.
Das Beispiel in den 5A-5C basiert auf einem Modell, bei dem der Hash bei zwei Bytes (16 Bits) abgeschnitten wird; es kann jedoch jede beliebige Abschneideebene verwendet werden. Das Beispiel geht ferner davon aus, dass jedes Datenobjekt 8 KiB groß ist, es kann jedoch jede Größe unterstützt werden.
In den Beispielbäumen der 5A-5C enthält jeder Baum einen Wurzelknoten (z. B. Knoten 601 in Baum 600, Knoten 621 in Baum 620, Knoten 641 in Baum 640, Knoten 661 in Baum 660, Knoten 681 in Baum 680). Die Beispielbäume in den 5A-5C sind vereinfacht mit nur drei Ebenen dargestellt, aber es können Baumstrukturen beliebiger Komplexität unterstützt werden. Jeder Baum enthält einen oder mehrere Zwischenknoten (z. B. die Knoten 602-605 in Baum 600, die Knoten 622-625 in Baum 620, die Knoten 642-645 in Baum 640, die Knoten 662-665 in Baum 660, die Knoten 682-685 in Baum 680).
Außerdem enthält jeder Baum einen oder mehrere Blattknoten (z. B. die Knoten 606-613 in Baum 600, die Knoten 626-633 in Baum 620, die Knoten 646-653 in Baum 640, die Knoten 668-675 in Baum 660, die Knoten 688-695 in Baum 680). Eine Teilmenge der Blattknoten kann auf der Grundlage der festgelegten Stichprobenstrategie beprobt werden. Unter Verwendung der Beispielstrategie 1/N, wobei N=2 ist, werden die Knoten 606, 609, 611, 612, 627, 629, 631, 632, 647, 648, 651, 652, 669, 670, 672, 674, 689, 690, 692 und 694 erfasst.
Als Ergebnis der Probenahme ergibt sich für den Baum 600 ein Milli-Index:

Abgeschnittener Hash Referenzzahl

005c 1

0a6e 1

4fc6 1

B8ec 1
Der Milli-Index für Baum 620 ist:

Abgeschnittener Hash Referenzzahl

005c 1

0a6e 1

15df 1

4fc6 1
Der Milli-Index für Baum 640 ist:

Abgeschnittener Hash Referenzzahl

0a6e 1

15df 1

4fc6 1

dddf 1
Der Milli-Index für Baum 660 ist:

Abgeschnittener Hash Referenzzahl

0a6e 1

15df 1

27c 1

dddf 1
Der Milli-Index für Baum 680 ist:

Abgeschnittener Hash Referenzzahl

15df 1

27c 2

dddf 1
Der resultierende Knoten Milli-Index ist:

Abgeschnittener Hash Referenzzahl

005c 2

0a6e 4

15df 4

27c 3

4fc6 3

b8ec 1

dddf 3
Angesichts der oben beschriebenen Bäume und Tabellen, die Milli-Indizes darstellen, können Kapazitätsinformationen auf der Grundlage der Auswertung der Tabellendaten geschätzt werden. Um beispielsweise zu ermitteln, wie viel Platz durch das Löschen eines einzelnen Baums (z. B. Baum 600) wiedergewonnen werden kann, wird die Referenzzahl für jedes Objekt in dem angegebenen Baum von den gleichen Objekten im Milli-Index des Knotens subtrahiert:

Abbruch. Raute Knoten Ref. Anzahl - Baum 600 Ref. Anzahl = Multiset Diff. Ref. Anzahl

005c 2 1 1

0a6e 4 1 3

4fc6 3 1 2

b8ec 1 1 0
Damit ein Objekt zurückgewonnen werden kann, muss die Anzahl der Baumreferenzen mit der Anzahl der Knotenreferenzen übereinstimmen. Mit anderen Worten, die Anzahl der Multiset-Differenzreferenzen muss Null sein.
In einigen Ausführungsformen wird die Anzahl der eindeutigen Objekte im Baum auf der Grundlage der Anzahl der eindeutigen Stichproben im Milli-Index des Baums extrapoliert, um die geschätzte Platzrückgewinnung aus dem Löschbaum 600 zu erhalten: $Baum 600 Milli-Index-Stichprobe n | * N = 4 eindeutige Stichprobenobjekte * 2$
$= 8 einzigartige Objekte$
In Anbetracht der obigen Multiset-Differenz-Referenzzahlen wird durch das Löschen von Baum 600 das Objekt mit dem abgeschnittenen Hash „b8ec“ freigegeben, da seine Multiset-Differenz-Referenzzahl im Knoten-Milli-Index auf Null geht. Somit würde eines von vier eindeutigen Objekten befreit werden. Wendet man dieses Verhältnis auf die hochgerechnete Anzahl der eindeutigen Blöcke im Baum an: $\begin{array}{l} (1 freigegebenes Objekte/ 4 eindeutige abgetastete Objekte) * 8 eindeutige \\ Objekte*8 KiB pro Objekte \\ = 16 KiB zur \ddot{u} ckgewonnen \end{array}$
Ein weiteres Beispiel: Um zu ermitteln, wie viel Platz durch das Löschen eines anderen Einzelbaums (z. B. Baum 680) gewonnen werden kann, wird die Anzahl der Verweise für jedes Objekt in dem angegebenen Baum von den gleichen Objekten im Milli-Index des Knotens subtrahiert:

Abbruch. Raute Knoten Ref. Anzahl - Baum 680 Ref. Anzahl = Multiset Diff. Ref. Anzahl

15df 4 1 3

27c 2 2 0

dddf 3 1 2
Damit ein Objekt zurückgewonnen werden kann, muss die Anzahl der Baumreferenzen mit der Anzahl der Knotenreferenzen übereinstimmen.
In einigen Ausführungsformen wird die Anzahl der eindeutigen Objekte im Baum auf der Grundlage der Anzahl der eindeutigen Stichproben im Milli-Index des Baums extrapoliert, um die erwartete Platzrückgewinnung aus dem Löschen des Baums 680 zu ermitteln: $\begin{array}{l} | Baum 680 Milli-Index-Stichproben | *N = 3 einzigartige Stichprobenobjekte * 2 \\ = 6 einzigartige Objekte \end{array}$
Angesichts der obigen Multiset-Differenz-Referenzzahlen wird durch das Löschen von Baum 600 das Objekt mit dem abgeschnittenen Hash „27ce“ freigegeben, da seine Multiset-Differenz-Referenzzahl im Knoten-Milli-Index auf Null geht. Somit würde eines von drei eindeutigen Objekten freigegeben werden. Wendet man dieses Verhältnis auf die hochgerechnete Anzahl der eindeutigen Blöcke im Baum an: $\begin{array}{l} (1 freigegebenes Objekte / 3 eindeutige abgetastete Objekte) * 6 eindeutige \\ Objekte*8 KiB pro Objekte \\ = 16 KiB zur \ddot{u} ckgewonnen \end{array}$
Als komplexeres Beispiel können diese Techniken verwendet werden, um den durch das Löschen von zwei Bäumen (z. B. Baum 600 und Baum 620) wiedergewonnenen Platz zu schätzen. In einigen Ausführungsformen werden die Referenzzahlen zunächst über die Milli-Indizes für die Bäume summiert, und das Ergebnis wird von den entsprechenden Objekten im Milli-Index des Knotens subtrahiert. Die Multiset-Referenzzahlen ergeben sich aus der Vereinigung aller in den einzelnen Bäumen enthaltenen Objekte:

Abbruch. Raute Baum 600 Ref. Anzahl + Baum 620 Ref. Anzahl = Multiset Union Ref. Anzahl

005c 1 1 2

0a6e 1 1 2

15df - 1 1

4fc6 1 1 2

b8ec 1 - 1
Differenz zwischen den Zählungen der Knoten-Milli-Index-Referenzen und den Zählungen der Multiset-Union-Referenzen, um zu bestimmen, wie viele Objekte zurückgewonnen werden sollen:

Abbruch. Raute Knoten Ref. Anzahl - Multiset Union Ref. Anzahl = Multiset Diff. Ref. Anzahl

005c 2 2 0

0a6e 4 2 2

15df 4 1 3

4fc6 3 2 1

b8ec 1 1 0
Wie oben muss die Multiset-Union der Baumreferenzzahlen mit der Knotenreferenzzahl übereinstimmen, damit ein Objekt zurückgefordert werden kann.
In einigen Ausführungsformen wird die Anzahl der eindeutigen Objekte im Baum auf der Grundlage der Anzahl der eindeutigen Stichproben in der Multiset-Union der Baum-Milli-Indizes extrapoliert, um die Schätzung der erwarteten Platzrückgewinnung durch Löschen der Bäume 600 und 620 zu erhalten: $\begin{array}{l} * N = 5 eindeutige Stichprobenobjekte * 2 \\ = 10 einzigartige Objekte \end{array}$
In Anbetracht der obigen Multiset-Differenz-Referenzzahlen werden durch das Löschen der Bäume 600 und 620 die Objekte mit den abgeschnittenen Hashes „005c“ und „b8ec“ freigegeben, da ihre Multiset-Differenz-Referenzzahl im Knoten-Milli-Index auf Null geht. Somit würden zwei von fünf eindeutigen Objekten freigegeben werden. Die Anwendung dieses Verhältnisses auf die hochgerechnete Anzahl der eindeutigen Blöcke in der Baumgruppe: $\begin{array}{l} (2 freigegebenes Objekte/ 5 einmalig abgetastete Objekte) * 10 einmalige Objekte \\ *8 KiB pro Objekte = 32 KiB zur \ddot{u} ckgewonnen \end{array}$
In einigen Ausführungsformen kann für Dateien von Festplatten virtueller Maschinen (VMDK) und virtueller Festplatten (VHDX) (und möglicherweise auch für andere Dateien, die größer als z. B. 64 MiB werden) ein Inode-Milli-Index geführt werden. In diesen Ausführungsformen kann für den Rest des Hives ein weiterer Hive-Milli-Index geführt werden.
In einer Ausführungsform werden der/die Hive-Milli-Index(s) und der/die Inode-Milli-Index(s) in erster Linie während des Rollups aktualisiert, z. B. um übermäßige Aktualisierungen zu vermeiden, sie werden innerhalb des Hives gespeichert, sie werden jedem Inode für virtuelle Festplattendateien und andere sehr große Dateien zugeordnet, die Auswahl der Dateien, denen diese Indizes zugeordnet werden sollen, könnte z. B. darauf beruhen, welche Dateinamenserweiterungen am wahrscheinlichsten an serverseitigen Kopiervorgängen beteiligt sind, und für den Rest des Hives kann der Hive-Milli-Index dem Inode 0 oder 2 zugeordnet werden. In einigen Implementierungen stellt Inode 2 das Stammverzeichnis des Dateisystems dar.
In einer Ausführungsform erbt der Schnappschuss (oder die Sicherung) bei der Erstellung eines Schnappschusses oder einer Sicherung den Hive-Milli-Index und alle Inode-Milli-Indizes. Wenn ein Client, z. B. ein Hypervisor-Verwaltungssystem, eine vom Server ausgelagerte Kopie einer Inode anfordert, erbt die Kopie der Datei den Inode-Milli-Index der Originaldatei. Dieser Inode-Milli-Index wird auf den/die Node-Milli-Index(s) angewandt, um eine genaue Zählung der Tiefenreferenzen für jede der abgetasteten Signaturen in der kopierten Datei zu erhalten. Dies kann auf dieselbe beständige Weise geschehen, wie für Snapshot-Operationen beschrieben.
In einer Ausführungsform werden bei der Durchführung von unlink-, rmdir- oder truncate-Vorgängen die Milli-Indizes von Hives oder Inodes aktualisiert. In einer Ausführungsform kann ein Milli-Index pro Inode geführt und als Teil der Verzeichnisstruktur aufgerollt werden, so dass zu jedem beliebigen Zeitpunkt eine Schätzung der Verzeichnis-, Unterverzeichnis- oder Inode-Nutzung gegeben werden kann. Wenn ein Inode entfernt wird, wird die Anzahl der im Milli-Index des Inodes enthaltenen Stichproben-Signaturen vom Milli-Index des Knotens abgezogen.
In einigen Ausführungsformen wird für jeden Knoten in einer Umgebung ein Milli-Index geführt. Der Milli-Index des Knotens kann jedes Mal aktualisiert werden, wenn eine Hive-Milli-Index-Operation für den Knoten durchgeführt wird.
Ein Implementierungsbeispiel: Bei einem Knoten mit 32 TiB Daten, die im Verhältnis 2:1 komprimiert sind, und einer Datenobjektgröße von 8 KiB, wobei N = 13 und M = 64, enthält der Milli-Index des Knotens etwa 2^(1+45-(13+13)) Signaturen oder etwa 1 Million. Die verkleinerten Signaturen selbst dürften etwa 8 MiB verbrauchen. Die Wahrscheinlichkeit einer Kollision ist hinreichend gering, wenn der log2-Wert der Anzahl der Signaturen im Milli-Index des Knotens kleiner als M/2 ist.
In einigen Fällen können die Knoten-Milli-Indizes über eine REST-Anwendungsprogrammschnittstelle (API) abgerufen werden (Representational State Transfer). In einigen Ausführungsformen kann das Vorhandensein oder Nichtvorhandensein einer Hive-Milli-Index-Signatur innerhalb eines Knoten-Milli-Index über dieselbe API ermittelt werden. Nach dem Abruf, z. B. über die REST-API, kann der/die Milli-Index(s) als Multiset behandelt werden, was bedeutet, dass Vereinigungs- und Differenzoperationen gültig sind.
Unter Verwendung der hier beschriebenen Techniken und Strukturen können eine oder mehrere der folgenden Auswertungen durchgeführt werden. Die Menge an Speicherplatz, die durch das Löschen eines Backups freigesetzt/zurückgewonnen werden könnte, kann ermittelt werden. Diese Information kann zum Beispiel durch den Vergleich des Milli-Index des Backups mit dem Milli-Index des Knotens ermittelt werden. In einem anderen Beispiel kann durch den Vergleich einer Sicherung mit der nächsten und der vorherigen Sicherung die Menge an Speicherplatz ermittelt werden, die durch das Löschen der Sicherung freigesetzt werden könnte.
Als Erweiterung könnte die Menge an Speicherplatz ermittelt werden, die durch das Löschen einer Reihe von Sicherungen freigegeben/zurückgewonnen werden könnte. Als weiteres Beispiel könnte die Menge der Sicherungen ermittelt werden, die bestimmte Kriterien in Bezug auf die Freigabe von Speicherplatz erfüllen. Es könnte ermittelt werden, welche Folgen das Verschieben einer oder mehrerer virtueller Maschinen zwischen Knoten hat. Die Änderungsrate von Inhalten in einem Hive könnte ermittelt werden. Es können auch andere Auswertungen durchgeführt werden.
6 ist ein Flussdiagramm einer Technik zur Schätzung der Speicherkapazität eines Systems unter Verwendung von Milli-Indizes und Deep-Reference-Count-Informationen. Wie bereits erwähnt, kann das Speichersystem, das Speicherkapazität für eine beliebige Anzahl von Objekten bietet, ein dedupliziertes System sein. Weitere Techniken (z. B. Komprimierung) können ebenfalls eingesetzt werden.
Das System verwaltet einen oder mehrere Indizes der im System gespeicherten Objekte (Block 710). Die Indexeinträge enthalten Signaturen, die den Objekten entsprechen, sowie die Anzahl der flachen Verweise auf die Objekte. Die Indexeinträge können auch zusätzliche Informationen enthalten.
Das System verwaltet auch Milli-Indizes für eine Teilmenge der im System gespeicherten Objekte (Block 715). Die Milli-Index-Einträge verwenden abgeschnittene Signaturwerte und Zählungen von Tiefenreferenzen. Die „shallow reference counts“ geben die Anzahl der übergeordneten Metadatenobjekte an, die einen Verweis auf das Objekt enthalten, und nicht, wie viele Bäume einen Verweis auf das Objekt enthalten. Die Anzahl der tiefen Verweise gibt die Anzahl der logischen Vorkommen eines Objekts in einem Baum oder Knoten an.
Das System kann eine Anfrage zur Bewertung der Kapazität des Speichersystems erhalten (Block 720). Die Auswertungsanforderung kann z. B. lauten, wie viel wiedergewinnbarer Speicherplatz in einem bestimmten, in einem bestimmten Knoten gespeicherten Datensatz vorhanden ist. Es können auch komplexere Auswertungen durchgeführt werden, z. B. die Folgen des Löschens mehrerer Datensätze von einem Knoten oder des Verschiebens eines Datensatzes zu einem anderen Knoten im System. Es können viele verschiedene Arten von Auswertungen durchgeführt werden.
Die Kapazitätsbewertungen werden unter Verwendung der Milli-Index-Informationen durchgeführt, um Schätzungen für das Speichersystem zu erstellen (Block 725). Wie bereits erwähnt, können die Schätzungen auf Stichproben und statistischen Modellen beruhen. Die sich daraus ergebenden Schätzungen können dem Antragsteller zur Verfügung gestellt werden (Block 730).
Als Ergebnis von Anforderungen zur Bewertung der Systemkapazität kann es wünschenswert sein, einen Datensatzbaum von einem Knoten zu einem anderen zu migrieren, um die Gesamtauslastung des Clusters zu verbessern. In einigen Ausführungsformen umfasst dies einen zweistufigen Prozess: Zuerst wird der Datensatz auf den Zielknoten geschrieben und dann vom Quellknoten gelöscht. Auf dem Zielknoten werden neue Milli-Indizes erstellt und die entsprechenden Aktualisierungen der Milli-Indizes der Knoten vorgenommen. Das Löschen des Dataset-Baums vom ersten Knoten erfordert auch die Subtraktion der zugehörigen Milli-Indizes von den Milli-Index-Referenzzahlen des Knotens. Dies ist ein atomarer Vorgang und kann eine verzögerte Referenzzählerpersistenz verwenden, wie sie für Snapshot-Löschungen beschrieben ist.
7 ist ein computerlesbares Medium mit Befehlen zur Bereitstellung einer Technik zur Schätzung der Systemspeicherkapazität unter Verwendung von Milli-Indizes und Deep-Reference-Zählinformationen. In dem Ausführungsbeispiel umfasst das System 800 einen Prozessor 880 und ein computerlesbares Medium 885, die z. B. über einen Systembus (in 7 nicht dargestellt) miteinander kommunizieren. Bei dem Prozessor 880 kann es sich um jede Art von Zentraleinheit (CPU), Mikroprozessor oder Verarbeitungslogik handeln, die maschinenlesbare Anweisungen interpretiert und ausführt, die im computerlesbaren Speichermedium 885 gespeichert sind.
Bei dem computerlesbaren Speichermedium 885 kann es sich um einen Speicher mit wahlfreiem Zugriff (RAM) oder eine andere Art von dynamischem Speichergerät handeln, das Informationen und computerlesbare Anweisungen speichern kann, die vom Prozessor 880 ausgeführt werden können. Bei dem computerlesbaren Speichermedium 885 kann es sich beispielsweise um Synchron-DRAM (SDRAM), Double Data Rate (DDR), Rambus-DRAM (RDRAM), Rambus-RAM, nichtflüchtigen Speicher (NVM) usw. oder Speichermedien wie eine Festplatte, ein RAID-Array, eine DVD usw. handeln. In einigen Beispielen kann das computerlesbare Speichermedium 885 ein nicht-transitorisches computerlesbares Medium sein. In einigen Beispielen kann das computerlesbare Speichermedium 885 entfernt, aber für das System 800 zugänglich sein.
Das computerlesbare Speichermedium 885 kann Anweisungen 810, 815, 820, 825 und 830 speichern. In einigen Beispielen können die Anweisungen 810 vom Prozessor 880 ausgeführt werden, um einen oder mehrere Indizes in einem deduplizierten Speichersystem zu verwalten. Die Indizes können Signaturen, oberflächliche Referenzzahlen und/oder zusätzliche Informationen enthalten. Anweisungen 815 können vom Prozessor 880 ausgeführt werden, um einen oder mehrere Milli-Indizes unter Verwendung von abgeschnittenen Signaturen und tiefen Referenzzählungen zu pflegen.
Anweisungen 820 können vom Prozessor 880 ausgeführt werden, um eine Anfrage zur Bewertung der Kapazität des Speichersystems zu erhalten. Anweisungen 825 können vom Prozessor 880 ausgeführt werden, um die angeforderte Kapazitätsauswertung unter Verwendung der Milli-Indizes und der darin gespeicherten Informationen durchzuführen. Anweisungen 830 können vom Prozessor 880 ausgeführt werden, um die Ergebnisse der Kapazitätsabschätzung an den Anforderer zurückzugeben.
Wenn in der Beschreibung auf „eine Ausführungsform“ oder „eine Ausführungsform“ Bezug genommen wird, bedeutet dies, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die im Zusammenhang mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der Erfindung enthalten ist. Die Formulierung „in einer Ausführungsform“, die an verschiedenen Stellen der Beschreibung auftaucht, bezieht sich nicht unbedingt auf dieselbe Ausführungsform.
Während die Erfindung anhand mehrerer Ausführungsformen beschrieben wurde, wird der Fachmann erkennen, dass die Erfindung nicht auf die beschriebenen Ausführungsformen beschränkt ist, sondern mit Modifikationen und Änderungen im Rahmen des Geistes und des Umfangs der beigefügten Ansprüche ausgeführt werden kann. Die Beschreibung ist daher als illustrativ und nicht als einschränkend zu betrachten.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 10587454 [0038]

Claims

Ein System bestehend aus: ein Speichersystem zum Speichern von Daten für einen oder mehrere Hardware-Prozessoren, wobei das Speichersystem die darin gespeicherten Daten dedupliziert und einen Index von Objekten aufrechterhält, wobei jedes Objekt mindestens eine entsprechende oberflächliche Referenzzählung aufweist, die eine Anzahl von übergeordneten Objekten angibt, die eine Referenz auf das Objekt halten; und den einen oder mehrere Hardware-Prozessoren, die mit dem Speichersystem verbunden sind, wobei der eine oder die mehreren Hardware-Prozessoren dazu dienen: mindestens einen Baum-Milli-Index und mindestens einen Knoten-Milli-Index führen, die jeweils Einträge aufweisen, die einer Untermenge von Objekten entsprechen, die in dem Index von Objekten in dem Speichersystem gespeichert sind, wobei jeder der Einträge abgetastete Objektsignaturwerte und Tiefenreferenzzählwerte für entsprechende Objekte der Untermenge von Objekten in dem Index in dem Speichersystem aufweist, wobei die Tiefenreferenzwerte eine Anzahl von logischen Vorkommen von zugehörigen Objekten innerhalb eines Baums von Objekten entsprechend dem Index von Objekten anzeigen, und Bestimmen einer Kapazitätsauslastung des Speichersystems auf der Grundlage einer Analyse unter Verwendung der tiefen Referenzwerte aus dem mindestens einen Baum-Milli-Index oder dem mindestens einen Knoten-Milli-Index.
System nach Anspruch 1, bei dem eine Schnappschussoperation den Knoten-Milli-Index für jedes abgetastete Objekt, das in einem Schnappschussbaum enthalten ist, aktualisiert, indem die Knoten-Milli-Index-Datensatzreferenzzahlen um den Betrag erhöht werden, der in einem Baum-Milli-Index für den Schnappschussbaum dargestellt ist.
System nach Anspruch 1, bei dem das Löschen eines vorhandenen Schnappschusses bewirkt, dass ein Baum-Milli-Index, der dem gelöschten vorhandenen Schnappschuss entspricht, vom Knoten-Milli-Index subtrahiert wird.
Das System nach Anspruch 1, wobei die Analyse das Schätzen einer Speicherkapazität umfasst, die auf einem ersten Speicherknoten wiedergewonnen und auf einem zweiten Speicherknoten verbraucht wird, wenn der Baum von Objekten von dem ersten Speicherknoten zu dem zweiten Speicherknoten verschoben wird.
System nach Anspruch 1, bei dem der Knoten-Milli-Index außerdem abgeschnittene Objektsignaturwerte speichert, die eine Teilmenge von Bits eines vollständigen Objektsignaturwerts im Index der Objekte im Speichersystem umfassen.
Das System nach Anspruch 1, wobei die abgeschnittenen Objektsignaturwerte auf eine Teilmenge möglicher Objektsignaturwerte im Objektindex begrenzt sind und ferner auf der Grundlage einer Stichprobentechnik begrenzt werden.
System nach Anspruch 1, bei dem der eine oder die mehreren Hardware-Prozessoren ferner eine separate Datenstruktur von Objektsignaturwerten für abgetastete Objektsignaturwerte unterhalten, wobei die in der separaten Datenstruktur unterhaltenen Referenzzahlen tiefe Referenzzahlen für Objekte sind, die den abgetasteten Objektsignaturwerten entsprechen.
Ein nicht-transitorisches computerlesbares Medium, auf dem Befehle gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen,: einen Index von Objekten in einem Speichersystem zu führen, um Daten für den einen oder die mehreren Hardware-Prozessoren zu speichern, wobei das Speichersystem die darin gespeicherten Daten deduplizieren soll, wobei jedes Objekt in dem Index von Objekten mindestens eine entsprechende flache Referenzzählung hat, die eine Anzahl von übergeordneten Objekten angibt, die eine Referenz auf das Objekt halten; mindestens einen Baum-Milli-Index und mindestens einen Knoten-Milli-Index führen, die jeweils Einträge aufweisen, die einer Untermenge von Objekten entsprechen, die in dem Index von Objekten in dem Speichersystem gespeichert sind, wobei jeder der Einträge abgetastete Objektsignaturwerte und Tiefenreferenzzählwerte für entsprechende Objekte der Untermenge von Objekten in dem Index in dem Speichersystem aufweist, wobei die Tiefenreferenzwerte eine Anzahl von logischen Vorkommen von zugehörigen Objekten innerhalb eines Baums von Objekten entsprechend dem Index von Objekten anzeigen; und Bestimmen einer Kapazitätsauslastung des Speichersystems auf der Grundlage einer Analyse unter Verwendung der tiefen Referenzwerte aus dem mindestens einen Baum-Milli-Index oder dem mindestens einen Knoten-Milli-Index.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei eine Schnappschuss-Operation den Knoten-Milli-Index für jedes abgetastete Objekt, das in einem Schnappschuss-Baum enthalten ist, aktualisiert, indem die Knoten-Milli-Index-Datensatz-Referenzzahlen um den Betrag erhöht werden, der in einem Baum-Milli-Index für den Schnappschuss-Baum dargestellt ist.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei das Löschen eines vorhandenen Schnappschusses bewirkt, dass ein Baum-Milli-Index, der dem gelöschten vorhandenen Schnappschuss entspricht, vom Knoten-Milli-Index subtrahiert wird.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei die Analyse das Schätzen einer Speicherkapazität umfasst, die auf einem ersten Speicherknoten wiedergewonnen und auf einem zweiten Speicherknoten verbraucht wird, als Ergebnis des Verschiebens des Baums von Objekten von dem ersten Speicherknoten zu dem zweiten Speicherknoten.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei der Knoten-Milli-Index ferner abgeschnittene Objektsignaturwerte speichert, die eine Teilmenge von Bits eines vollständigen Objektsignaturwerts in dem Index von Objekten in dem Speichersystem umfassen.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei die abgeschnittenen Objektsignaturwerte auf eine Teilmenge möglicher Objektsignaturwerte im Objektindex begrenzt sind und ferner auf der Grundlage einer Stichprobentechnik begrenzt sind.
Nicht-transitorisches computerlesbares Medium nach Anspruch 8, wobei der eine oder die mehreren Hardwareprozessoren ferner eine separate Datenstruktur von Objektsignaturwerten für abgetastete Objektsignaturwerte aufrechterhalten, wobei in der separaten Datenstruktur aufrechterhaltene Referenzzählungen tiefe Referenzzählungen für Objekte sind, die den abgetasteten Objektsignaturwerten entsprechen.
Ein Verfahren, das Folgendes umfasst: Führen eines Indexes von Objekten in einem Speichersystem, um Daten für den einen oder die mehreren Hardware-Prozessoren zu speichern, wobei das Speichersystem die darin gespeicherten Daten dedupliziert, wobei jedes Objekt in dem Index von Objekten mindestens eine entsprechende flache Referenzzählung aufweist, die eine Anzahl von übergeordneten Objekten angibt, die eine Referenz auf das Objekt halten; Führen von mindestens einem Baum-Milli-Index und mindestens einem Knoten-Milli-Index, die jeweils Einträge aufweisen, die einer Untermenge von Objekten entsprechen, die in dem Index von Objekten in dem Speichersystem gespeichert sind, wobei jeder der Einträge abgetastete Objektsignaturwerte und Tiefenreferenz-Zählwerte für entsprechende Objekte der Untermenge von Objekten in dem Index in dem Speichersystem aufweist, wobei die Tiefenreferenzwerte eine Anzahl von logischen Vorkommen von zugehörigen Objekten innerhalb eines Baums von Objekten entsprechend dem Index von Objekten anzeigen; und Bestimmen einer Kapazitätsauslastung des Speichersystems auf der Grundlage einer Analyse unter Verwendung der tiefen Referenzwerte aus dem mindestens einen Baum-Milli-Index oder dem mindestens einen Knoten-Milli-Index.
Verfahren nach Anspruch 15, bei dem eine Schnappschussoperation den Knoten-Milli-Index für jedes abgetastete Objekt, das in einem Schnappschussbaum enthalten ist, aktualisiert, indem die Knoten-Milli-Index-Datensatzreferenzzahlen um den Betrag erhöht werden, der in einem Baum-Milli-Index für den Schnappschussbaum dargestellt ist.
Verfahren nach Anspruch 15, bei dem das Löschen eines vorhandenen Schnappschusses bewirkt, dass ein Baum-Milli-Index, der dem gelöschten vorhandenen Schnappschuss entspricht, vom Knoten-Milli-Index subtrahiert wird.
Verfahren nach Anspruch 15, wobei die Analyse die Schätzung einer Speicherkapazität umfasst, die auf einem ersten Speicherknoten wiedergewonnen und auf einem zweiten Speicherknoten verbraucht wird, wenn der Baum von Objekten von dem ersten Speicherknoten zu dem zweiten Speicherknoten verschoben wird.
Verfahren nach Anspruch 15, bei dem der Knoten-Milli-Index ferner abgeschnittene Objektsignaturwerte speichert, die eine Teilmenge von Bits eines vollständigen Objektsignaturwerts im Index der Objekte im Speichersystem umfassen.
Verfahren nach Anspruch 15, bei dem die abgeschnittenen Objektsignaturwerte auf eine Teilmenge möglicher Objektsignaturwerte im Objektindex begrenzt werden und außerdem auf der Grundlage einer Stichprobentechnik begrenzt werden.