DE112020003437T5

DE112020003437T5 - Hyper-scale p2p-dedupliziertes speichersystem unter verwendung einesdistributed ledger

Info

Publication number: DE112020003437T5
Application number: DE112020003437.2T
Authority: DE
Inventors: Arun Murti; Joey C. Lei; E. Brenner Adam; Mark D. Malamut
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-07-18
Filing date: 2020-03-23
Publication date: 2022-05-19
Also published as: WO2021011038A1; US11789824B2; US20230376384A1; US20210019232A1; GB2599527B; GB2599527A; GB202117842D0

Abstract

Ein beispielhaftes Verfahren beinhaltet das Empfangen von einem Knoten in einem HSAN, das mehrere Knoten beinhaltet, einer ADD DATA-Anfrage, um einen Eintrag zu einem Distributed Ledger des HSAN hinzuzufügen, wobei die Anfrage eine Benutzerkennzeichnung, die den Knoten identifiziert, einen Hash eines Datensegments und einen Speicherplatz des Datensegments an dem Knoten umfasst, das Durchführen eines Challenge-and-Response-Prozesses mit dem Knoten, um zu verifizieren, dass der Knoten eine Kopie der Daten besitzt, die der Gegenstand des Eintrags war, das Bestimmen, dass ein Replikationsfaktor X nicht erreicht wurde, und das Hinzufügen des Eintrags zu dem Distributed Ledger nach dem erfolgreichen Abschluss des Challenge-and-Response-Prozesses.

Description

GEBIET DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung beziehen sich im Allgemeinen auf Datenschutz und Datendeduplizierung. Genauer gesagt beziehen sich zumindest einige Ausführungsformen der Erfindung auf Systeme, Hardware, Software, computerlesbare Medien und Verfahren, um die Deduplizierung von Daten im großen Maßstab über separate Nutzerdatenspeicherstätten (user data repositories) hinweg zu vereinfachen, während die Integrität der Benutzerdaten gewahrt bleibt.
HINTERGRUND
Aktuelle Datendeduplizierungsspeicherung (data de-duplication storage) oder Dedupe-Speicherung wird typischerweise mit einer „firmeneigenen Lokalität“ implementiert, was bedeutet, dass die Daten, die dedupliziert werden können, auf die Daten beschränkt sind, die sich innerhalb des Datensee (data lake), so etwa beispielsweise Datenzentren oder Clouds, einer bestimmten Organisation befinden. Auch gibt es oftmals eine signifikante Anzahl an Datensegmenten, die mehrere verschiedene Unternehmen gemeinsam haben, so etwa Betriebssystemdateien wie z.B. Windows sowie Anwendungssoftwaredateien wie z.B. SQL-Server. In solchen Fällen könnte eine einzelne Kopie des Datensegments, der Datei oder eines anderen Datensatzes den Bedarf für mehrere Unternehmen zufriedenstellen. Somit ist das Beschränken von Deduplizierungsbemühungen auf die Grenzen eines spezifischen Unternehmens kein optimaler Ansatz.
In Anerkennung solcher Beschränkungen können Cloud-Service-Provider, die ihren Kunden Backup-as-a-Service anbieten, Deduplizierungsspeicherziele „poolen“, um größere Deduplizierungsdomänen zu erzeugen. Dieser Ansatz stellt aber signifikante Probleme dar. So werden die Kostenvorteile des Deduplizierens von gemeinsamen Daten über mehrere verschiedene Kunden im ersten Fall vom Service-Provider umgesetzt, aber es kann sein, dass der Service-Provider diese Einsparungen nicht an die Kunden selbst weitergibt. Als ein weiteres Beispiel müssen Kunden von Backup-Service-Providern, damit sie selbst von der Möglichkeit einer gepoolten Deduplizierung profitieren können, die Kontrolle über die gespeicherte Daten an eine zentrale Einheit abgeben, die damit ein attraktives Ziel für Datenbrüche wird. Kann ein Bedrohungsakteur (malicious actor) auf die Systeme des Service-Providers zugreifen, so können Backup-Daten kompromittiert werden, und das Vertrauen der Kunden in diesen geht verloren.
Figurenliste
Um die Art und Weise zu beschreiben, wie zumindest einige der Vorteile und Merkmale der Erfindung erhalten werden können, wird eine genauere Beschreibung von Ausführungsformen der Erfindung durch Verweis auf spezifische Ausführungsformen davon, die in den angehängten Zeichnungen veranschaulicht sind, gegeben. Geht man davon aus, dass diese Zeichnungen nur typische Ausführungsformen der Erfindung darstellen und nicht als deren Umfang einschränkend auszulegen sind, so werden die Ausführungsformen der Erfindung mit zusätzlicher Spezifität und Detail durch die Verwendung der begleitenden Zeichnungen beschrieben und erklärt.

1 offenbart Aspekte eines beispielhaften HSAN.
2 offenbart weitere Aspekte eines beispielhaften HSAN.
3 offenbart Aspekte einer beispielhaften Host-Konfiguration.
4 ist ein Ablaufdiagramm, das einige allgemeine Aspekte eines beispielhaften Verfahrensdeduplizierungsprozesses offenbart, der in einem HSAN durchgeführt wird.

AUSFÜHRLICHE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Ausführungsformen der vorliegenden Erfindung beziehen sich beziehen sich im Allgemeinen auf Datenschutz und Datendeduplizierung. Genauer gesagt beziehen sich zumindest einige Ausführungsformen der Erfindung auf Systeme, Hardware, Software, computerlesbare Medien und Verfahren, um die Deduplizierung von Daten im großen Maßstab über separate Datenspeicherstätten hinweg zu vereinfachen, während die Integrität der Nutzerdaten gewahrt bleibt.
Im Allgemeinen umfassen beispielhafte Ausführungsformen der Erfindung ein Hyper-scale Peer-to-peer (P2P)-dedupliziertes Speichersystem (HSAN), das sicher über mehrere Organisationen hinweg gemeinsam verwendet werden kann. Die HSAN Konfiguration erlaubt Nutzern, über ihre jeweiligen Data Lakes hinweg zu deduplizieren, wodurch die Gesamtkosten für Datenschutz-SLAs in einem globalen Maßstab gesenkt werden. Das HSAN arbeitet in Verbindung mit einem unveränderbaren Distributed Ledger, das unter Verwendung von Blockchain Technologie implementiert werden kann und als eine öffentliche Aufzeichnung von Referenzen auf Datensegmente wirkt, die innerhalb der verschiedenen privaten Data Lakes gespeichert sind. Diese Referenzen enthalten den inhaltlichen Fingerabdruck und die Speicherplätze der Datensegmente, aber nicht die Metadaten über die Dateien und Verzeichnisse, zu welchen die Segmente gehören, oder den tatsächlichen Inhalt der Segmente. Auf diese Weise stellt das Speichersystem eine sichere Speicherung für jeden der verschiedenen Nutzer bereit, ungeachtet dessen, dass es sich um ein öffentliches Speichersystem handelt.
Ausführungsformen der Erfindung können dann vorteilhaft verschiedene Nutzen und Verbesserungen bereitstellen, die sich auf herkömmliche Hardware, Systeme und Verfahren beziehen. Zur Veranschaulichung kann eine Ausführungsform der Erfindung die Anforderung eliminieren, dass ein Kunde einer externen Drittpartei mit seinen tatsächlichen Daten vertrauen muss. Stattdessen ermöglichen Ausführungsformen der Erfindung dem Kunden, ähnliche Nutzen durch das Teilen von nur begrenzter Information wie Fingerabdrücken über seine Daten zu realisieren. Als ein anderes Beispiel können Ausführungsformen der Erfindung insofern vorteilhaft sein, als sie eine öffentliche Aufzeichnung von Transaktionen bereitstellen, die dazu verwendet werden können, um Integrität über die jeweiligen Datenspeicherplätze hinweg mehrerer verschiedener Nutzer zu verifizieren, um das gegenseitige Vertrauen sicherzustellen. Als ein letztes Beispiel teilen Ausführungsformen der Erfindung die öffentlichen und privaten Elemente der Daten eines Nutzers, so dass die Nutzen einer Deduplizierung realisiert werden können, während die Integrität der jeweiligen privaten Daten der Nutzer gewahrt wird.
Es ist anzumerken, dass die vorstehenden vorteilhaften Aspekte verschiedener Ausführungsformen nur beispielhaft dargestellt sind und dass verschiedene andere vorteilhafte Aspekte von beispielhaften Ausführungsformen der Erfindung sich aus dieser Offenbarung ergeben. Es ist ferner anzumerken, dass es nicht erforderlich ist, dass eine beliebige Ausführungsform einen beliebigen solcher vorteilhafter, hierin geoffenbarter Aspekte implementiert oder ermöglicht.
A. Aspekte von beispielhaften Betriebsumgebungen und Architektur
Das Folgende ist eine Erläuterung von Aspekten von beispielhaften Betriebsumgebungen für verschiedene Ausführungsformen der Erfindung. Die Erläuterung soll nicht den Umfang der Erfindung oder die Anwendbarkeit der Ausführungsformen in irgendeiner Art und Weise beschränken. Zusätzlich zu der folgenden Erläuterung sind weitere Details betreffend beispielhafter Betriebsumgebungen, in welchen Ausführungsformen der Erfindung implementiert werden können, in den Verwandten Anmeldungen geoffenbart. Im Allgemeinen können Ausführungsformen der Erfindung in Verbindung mit Systemen, Software und Komponenten implementiert werden, die einzeln und/oder kollektiv Datenverwaltungsoperationen implementieren oder deren Implementierung veranlassen können. Solche Datenverwaltungsoperationen können Datenlese-/-schreib-/- löschoperationen, Daten-Backup-Operationen, Datenwiederherstellungsoperationen, Datenklonierungsoperationen, Datenarchivierungsoperationen, Datendeduplizierungsoperationen und Disaster-Recovery-Operationen beinhalten. Somit ist, während die Erläuterung hierin in einigen Aspekten auf eine Erläuterung von Datenschutzumgebungen und - operationen gerichtet sein kann, der Umfang der Erfindung nicht derart beschränkt. Allgemeiner umfasst der Umfang der Erfindung jegliche Betriebsumgebung, in welcher die geoffenbarten Konzepte nützlich sein können. Veranschaulichend aber nicht einschränkend können Ausführungsformen der Erfindung in Verbindung mit Daten-Backup- und Wiederherstellungsplattformen, Systemen und Vorrichtungen, wofür Beispiele die Dell-EMC NetWorker und Avamar Plattformen, Dell-EMC Enterprise Copy Data Management (ECDM), Dell-EMC Integrated Data Protection Appliance (IDPA), Dell-EMC PowerProtect umfassen, aber nicht darauf beschränkt sind, und/oder Datenschutzumgebungen wie Dell-EMC DataDomain verwendet werden und/oder darin aufgenommen sein.
Eine Datenschutzumgebung kann die Form einer öffentlichen oder privaten Cloudspeicherumgebung, einer Speicherumgebung am Standort sowie hybrider Speicherumgebungen, die öffentliche und private Elemente beinhalten, annehmen, wenngleich sich der Umfang der Erfindung auch auf jeden beliebigen anderen Typ einer Datenschutzumgebung ausdehnen lässt. Es können beliebige dieser beispielhaften Speicherumgebungen teilweise oder komplett visualisiert werden. Die Speicherumgebung kann ein Datenzentrum umfassen oder daraus bestehen, das bedient werden kann, um Lese- und Schreiboperationen zu leisten, die von einem oder mehreren Clients initiiert werden. Zusätzlich zur Speicherumgebung kann die Betriebsumgebung auch eine oder mehrere Host-Vorrichtungen beinhalten, so z.B. Clients, die eine oder mehrere Anwendungen hosten. Derart kann ein bestimmter Client eine oder mehrere Instanzen jeder der einen oder mehreren Anwendungen verwenden oder in anderer Weise damit assoziiert sein. Im Allgemeinen sind die von den Clients verwendeten Anwendungen nicht auf eine bestimmte Funktionalität oder einen bestimmten Typ von Funktionalität beschränkt. Einige beispielhafte Anwendungen und Daten beinhalten z.B. Email-Anwendungen wie MS Exchange, Datensysteme sowie Datenbanken wie Oracle Datenbanken und SQL Server-Datenbanken. Die Anwendungen auf den Clients können neue und/oder modifizierte Daten erzeugen, die man schützen möchte.
Jede der hierin geoffenbarten Vorrichtungen oder Einheiten kann durch eine oder mehrere Datenschutzstrategien gemäß verschiedenen Ausführungsformen der Erfindung geschützt werden. Doch noch andere Beispiele für Vorrichtungen, die mittels einer Datenschutzstrategie gemäß Ausführungsformen der Erfindung geschützt werden können, beinhalten Container und VMs, sind aber nicht darauf beschränkt.
Beliebige der Vorrichtungen, einschließlich dabei die Clients, Server und Hosts, in der Betriebsumgebung können die Form von Software, physischen Maschinen oder virtuellen Maschinen (VM) oder eine beliebige Kombination dieser annehmen, wenngleich keine bestimmte Vorrichtungsimplementierung oder -konfiguration für eine beliebige Ausführungsform erforderlich ist. Ebenso können Datenschutzsystemkomponenten wie Datenbanken, Speicherserver, Speichervolumen (LUNs), Speicherplatten, Replikations-Services, Backup-Server, Wiederherstellungs-Server, Backup-Clients und Wiederherstellungs-Clients z.B. ebenfalls die Form von Software, physischen Maschinen oder virtuellen Maschinen (VM) annehmen, wenngleich keine bestimmte Komponentenimplementierung für eine beliebige Ausführungsform erforderlich ist. Werden VMs verwendet, so kann ein Hypervisor oder ein anderer Virtueller Maschinenmotor (VMM) verwendet werden, um die VMS zu erzeugen und zu steuern.
Wie hierin verwendet, soll der Begriff „Daten“ einen weiten Umfang haben. Somit umfasst der Begriff beispielhaft und nicht einschränkend Datensegmente wie solche, die durch Datenstromsegmentierungsprozesse produziert werden können, Daten-Chunks, Datenblöcke, atomare Daten, Emails, Objekte jedes beliebigen Typs, Dateien, Kontakte, Verzeichnisse, Unterverzeichnisse, Volumina und jede beliebige Gruppe von einem oder mehreren der Vorstehenden.
Beispielhafte Ausführungsformen der Erfindung können auf jedes beliebige System angewendet werden, das verschiedene Typen von Objekten in analoger, digitaler oder anderer Form speichern und handhaben kann. Obwohl z.B. Begriffe wie Dokument, Datei, Block oder Objekt verwendet werden können, sind die Prinzipien der Offenbarung nicht auf eine bestimmte Form der Darstellung und Speicherung von Daten oder anderen Informationen beschränkt. Vielmehr können solche Prinzipien gleichermaßen auf ein beliebiges Objekt übertragen werden, das Informationen darstellen kann.
Mit besonderem Augenmerk nunmehr auf 1 kann eine beispielhafte Betriebsumgebung 100 ein HSAN 200 umfassen oder daraus bestehen, das ein Peer-to-Peer-Datenschutzspeichersystem ist, das als ein Satz (set) von Peer-to-Peer-Knoten wie die Knoten 300a und 300b implementiert ist, die ein dedupliziertes distributed Speichersystem implementieren. Somit steht das HSAN einem zentralisierten System wie jenem eines Service-Providers gegenüber, in welchem eine Gruppe von entfernten Datensilos Daten zu einem zentralen Silo repliziert, und das HSAN steht auch einem dezentralisierten System eines privaten Unternehmens gegenüber, in welchem die Replizierung von Daten zwischen zentralisierten Datensilos erfolgt.
Die HSAN Knoten 300a und 300b können von einer einzelnen Einheit wie einer Firma besessen oder von dieser gesteuert werden, oder die Knoten können jeweils von verschiedenen jeweiligen Einheiten besessen und gesteuert werden. Die Daten in dem HSAN 200 werden in zwei Typen aufgeteilt, nämlich in atomare Daten und Metadaten. Im Allgemeinen können die atomaren Daten öffentlich sein, währen die Metadaten privat gehalten werden. Während, um es einfach zu halten, 1 nur zwei Knoten offenbart, ist zu verstehen, dass Ausführungsformen der Erfindung in Verbindung mit einer beliebigen Anzahl von Knoten verwendet werden können, wenngleich es aus praktischen Gründen manchmal nützlich sein kann, die Anzahl von Knoten, die an der Teilnahme im HSAN zugelassen sind, zu beschränken.
B. Atomare Daten und Metadaten
Mit weiterem Bezug auf 1 und die atomaren Daten insbesondere ist zu sehen, dass Backup-Daten in Chunks aufgeteilt werden können, d.h. z.B. die atomaren Daten a1, a2, a3, aX, aY und aZ. Einer, einige oder alle Chunks oder atomaren Daten können die Knoten 300a und 300b sowie alle anderen Knoten gemein haben. Eine kryptografische Hash-Funktion wie etwa z.B. SHA-2 wird verwendet, um einen Fingerabdruck oder Hash des Inhalts des Chunks zu erzeugen. Der Hash identifiziert eindeutig den Inhalt des Chunks, identifiziert aber weder die Datenquelle selbst wie etwa den Creator noch referenziert es auf beliebige Metadaten wie z.B. den Dateinamen, die mit dem Chunk assoziiert sind. Somit ist der Hash der atomaren Daten a1 H(a1), der Hash der atomaren Daten a2 ist H(a2) und so weiter, wie dies in 1 gezeigt ist. In dem veranschaulichten Beispiel stellen die atomaren Daten a1...aZ, zusammen mit den Hashes H(a1) ... H(aZ), die öffentlichen Daten dar. In einigen Ausführungsformen weisen die Chunks eine feststehende Größe auf, so z.B. 64KB, und sie sind ein feststehendes Vielfaches von Malen über die Knoten 300a und 300b gespeichert. In anderen Ausführungsformen können die Chunks eine variable Größe aufweisen und/oder sie können variierende Anzahlen von Kopien aufweisen. Im Allgemeinen werden die atomaren Daten auf einem Privatdatenschutzspeichersystem einer Firma gespeichert, wobei Beispiele dafür die Plattformen Dell-EMC Avamar und Data Domain beinhalten. Wie gezeigt ist, kann sich der Hashing-Prozess über eine beliebige Anzahl von Ebenen nach oben hin fortsetzen. Somit können z.B. H(a1), H(a2) und H(a3) miteinander kombiniert und dann gehasht werden, um H(c1) zu produzieren. H(c1) kann wiederum mit H(c2) und H(c3) kombiniert werden, und die resultierende Kombination kann gehasht werden, um H(cc1) zu produzieren. Dieser Prozess kann fortgesetzt werden, bis ein Root-Hash H(Root) des gesamten Merkle-Baums produziert wird.
Auf diese Weise werden die Hashes ‚H‘ der atomaren Daten-Chunks als eine Grundlage verwendet, um den Merkle-Baum zu bauen, der in 1 als „KOMPOSIT-Daten (Metadaten)“ bezeichnet ist und letztlich den Root-Hash H(Root) produziert. Genauer gesagt identifizieren Root-Hashes in aufsteigenden Ebenen Objekte höherer Ebenen wie Dateien (H(a1) beispielsweise), Verzeichnisse (H(c1) beispielsweise), Volumina (H(cc1) beispielsweise) und Backups (H(Root)). Die Root-Hashes für Backups, „H(Root)“, werden innerhalb der Backup-Aufzeichnungen referenziert, die Teil des gesamten Backup-Katalogs eines Unternehmens sind. Im Beispiel von 1 ist H(Root) der Hash des gesamten Merkle-Baums. Es ist auch anzumerken, dass ein Hash ein „Hash von Hashes“ sein kann, der einen Teil einer Datei ausmacht. Beispielsweise können große Dateien 2 oder mehr Ebenen von inhaltlichen Hashes haben. In jedem Fall können alle inhaltlichen Hashes im HSAN gespeichert werden, aber alle Metadaten, die Objekte höherer Ebenen (z. B. Dateien und Verzeichnisse) identifizieren, werden nicht im HSAN gespeichert.
Jeder Teil oder Unterbaum des Merkle-Baums bis hinauf und einschließlich des gesamten Baums kann mit dem entsprechenden Teil eines anderen Merkle-Baums verglichen werden, und wenn die beiden Teile jeweils denselben Root-Hash aufweisen, kann man daraus schließen, dass alles, was in einem der Teile enthalten ist, dasselbe ist wie das, was im anderen Teil beinhaltet ist. Wenn z. B. ein Verzeichnisebenenbaum (directory level tree) des Knotens 300a denselben Root-Hash wie ein Verzeichnisebenenbaum des Knotens 300b aufweist, dann muss der Inhalt der jeweiligen Verzeichnisebenenbäume derselbe sein. Die KOMPOSIT-Daten und der Backup-Katalog bleiben für eine gegebene Einheit privat, und KOMPOSIT-Daten werden nicht über die privaten Data Lakes hinweg, die durch die Knoten 300a und 300b dargestellt sind, dedupliziert. Somit kann kein HSAN Nutzer die Dateien, Verzeichnisse oder Backups eines anderen HSAN Nutzers rekonstruieren, sofern sie nicht auch dieselben Dateien, Verzeichnisse oder Backups haben. Ein Nutzer kann höchstens wissen, dass ein anderer Nutzer dieselben Daten hat, aber man erwartet, dass dies hauptsächlich für gemeinsame Daten gilt, die von Nutzern geteilt werden, so z.B. OS Dateien wie Linus oder Windows oder Anwendungssoftwaredateien wie z.B. Oracle Binärdateien.
C. Distributed Ledger
Mit weiterem Bezug auf 1 und auch mit direktem Blick auf 2 wird ein öffentlicher Distributed Ledger, der allgemein mit 400 bezeichnet ist, aber beispielhafte Instanzen 400a-f umfasst und ähnlich dem in den Bitcoin- oder Ethereum-Blockchains verwendetem Ledger ist, dazu verwendet, Informationen zwischen den Knoten 300a-e darüber zu teilen, wo Kopien von atomaren Chunks gespeichert sind. Ein Distributed Ledger bezieht sich auf die Auffassung, dass jeder Knoten 300a, 300b, 300c, 300d, 300e und 300f eine Kopie des Ledger aufweist, wie dies im Beispiel der 2 gezeigt ist. Im Allgemeinen dient der Ledger 400 als eine öffentliche Aufzeichnung von Referenzen auf Datensegmente, die an den verschiedenen Knoten 300a-e gespeichert sind, wobei ein oder mehrere dieser Knoten einen privaten Data Lake umfassen können oder daraus bestehen können. Die Referenzen in dem Ledger 400 enthalten den inhaltlichen Fingerabdruck oder Hash und die Speicherplätze in den jeweiligen Data Lakes der Datensegmente. Die Referenzen in dem Ledger 400 enthalten aber keine Metadaten über die privaten Dateien und Verzeichnisse, zu welchen die Datensegmente gehören, und auch enthalten die Referenzen keine tatsächlichen Datensegmente. Somit kann auf die privaten Daten, die an den verschiedenen Knoten gespeichert sind, nicht mittels des Ledgers 400 zugegriffen werden. Das bedeutet, dass nur der Hash hinzugefügt wird und für andere in dem Ledger sichtbar ist. Darüber hinaus kann der Hash nicht umgekehrt werden, so dass, während die Aufzeichnung, die den Hash beinhaltet, öffentlich ist, die darunter liegenden Daten des Hash weder öffentlich sind noch auf sie durch irgendeinen anderen als den Aufrufer (caller) zugegriffen werden kann.
Im Einzelnen enthält jeder Eintrag oder Verweis im Ledger 400 die folgenden Informationen: die Benutzerkennung, wie z. B. den öffentlichen Schlüssel eines Knotens; den Hash des atomaren, d. h. des Datensegments, und die Transaktionsinformationen zu diesem Datensegment, wobei Beispiele für Transaktionen weiter unten behandelt werden. Ledger-Einträge werden in Blöcken gespeichert, die eine feststehende maximale Anzahl von Einträgen sowie eine Kopfzeile enthalten. Der Inhalt jedes Blocks wird gehasht, und dieser Hash wird in der Kopfzeile des nächsten Blocks in einer verknüpften Liste von Blöcken referenziert, wodurch eine unabänderliche Blockchain gebildet wird. Somit enthält das Ledger 400 alle Informationen, die zur Erstellung des Merkle-Baums für jeden Knoten 300a-e im HSAN erforderlich sind, obwohl, wie hier erwähnt ist, die Informationen im Ledger zwar öffentlich sind, die Datensegmente, auf die die Ledger-Einträge aber referenzieren, privat und nur für den Besitzer der Daten zugänglich sind. Auf diese Weise können die öffentlichen Daten, die von den Knoten gemeinsam genutzt werden, dedupliziert werden, ohne dass die Gefahr besteht, dass die Öffentlichkeit auf private Daten zugreifen kann.
Wie 2 vermuten lässt, speichert jeder Knoten 300a-f eine Kopie der gesamte Blockchain. Die Blockchain ist eine Permissioned Blockchain und nicht eine Trustless Blockchain wie Bitcoin. Wie hierin verwendet, bezieht sich eine Permissioned Blockchain darauf, dass eine Ebene von impliziertem Vertrauen zwischen / unter den Knoten 300a-f gegeben ist. So müssen z.B. Einheiten, die die bestehenden Knoten in dem System besitzen, miteinander übereinkommen, z.B. mittels einer rechtlichen oder einer anderen Übereinkunft beispielsweise, dass eine neue Einheit einen oder mehrere Knoten in das System hinzufügen darf.
D. Einige beispielhafte HSAN Transaktionen
Mit weiterem Bezug auf die 1 und 2 sind nunmehr Details bezüglich einiger beispielhafter HSAN Transaktionen oder Operationen bereitgestellt. Im Allgemeinen kann jeder beliebige Teilnehmer im HSAN seine im Ledger aufgelisteten Transaktionen nachvollziehen und verifizieren, dass die Ledger-Aufzeichnungen korrekt sind. Ist eine Transaktion aus welchem Grund auch immer nicht korrekt, so kann der Teilnehmer, zu dem die Transaktion gehört, eine Anfrage an die anderen Mitglieder einbringen, die notwendigen Korrekturen vorzunehmen.
Beispielhafte Ausführungsformen der Erfindung umfassen den folgenden Satz von HSAN Operationen, wenngleich auch andere und zusätzliche Operationen ebenfalls genutzt werden können: IS PRESENT, ADD DATA; REF DATA; GET DATA; DEREF DATA; DEL_DATA; CHECK DATA; und, REPL_DATA. Nachfolgend findet sich wiederum eine Erläuterung jeder dieser beispielhaften Operationen.
Die Operation IS_PRESENT fragt den Ledger 400 nach Einträgen ab, die einen Fingerabdruck enthalten, der bestimmten Daten entspricht. Ist ein Eintrag nicht vorhanden, oder wenn eine unzureichende Anzahl an Einträgen nicht vorhanden ist, um den erwünschten Replikationsfaktor zu erreichen, so kann ein Eintrag unter Verwendung der Operation ADD_DATA hinzugefügt werden, wie dies nachfolgend erläutert ist. Andererseits, wenn eine ausreichende Anzahl an Einträgen für ein Datensegment in dem Ledger gegeben ist, ist es nicht erforderlich, den Eintrag hinzuzufügen. In jedem Fall ist der Replikationsfaktor während der Initialisierungszeit auf der Ebene eines Diagramms festgelegt, um die Komplexität zu minimieren. In anderen Ausführungsformen könnte der Replikationsfaktor pro Chunk oder auf einer anderen Ebene von Granularität festgelegt werden.
Eine Brute-Force-Implementierung einer IS PRESENT-Abfrage könnte das Scannen des gesamten Ledgers erfordern, was mit wachsender Größe des Ledgers lineare Zeit in Anspruch nehmen würde. Der Abfrageprozess könnte jedoch durch die Verwendung und Pflege eines durchsuchbaren Index der Ledger-Einträge optimiert oder zumindest verbessert werden. IS_PRESENT-Abfragen an diesen Index könnten weiter optimiert werden, indem ein Bloom-Filter mit geeigneter Größe als eine anfängliche Prüfung verwendet wird, um das wahrscheinliche Vorhandensein eines Hashes im Index zu bestimmen. In einigen Ausführungsformen erzeugt und pflegt jeder Knotenbesitzer separat seinen eigenen Index. In anderen Ausführungsformen kann eine Gruppe von vertrauenswürdigen Besitzern zusammenarbeiten, um einen solchen Index zu erzeugen und zu pflegen, an den alle in der Gruppe IS_PRESENT-Abfragen richten könnten.
Eine weitere Operation, die durch Ausführungsformen der Erfindung implementiert wird, ist ADD_DATA. Im Allgemeinen fügt die Operation ADD_DATA einen Eintrag zu dem Ledger, um anzugeben, dass der Aufrufer eine Kopie des Chunks speichert. Handelt es sich hierbei um die erste Kopie des Chunks, so wird dem Aufrufer implizit vertraut. Die Anzahl der Instanzen eines Chunks, auf die im Ledger referenziert wird, kann durch einen Replikationsfaktor festgelegt werden. Auf diese Weise wird eine unnötige Duplizierung von Datensegmenten über die Data Lakes der Kunden hinweg vermieden, da nur eine gewisse Anzahl von Kopien eines Datensegments einen Eintrag in den Ledger erhalten darf. So wird die Datendeduplizierung in verschiedenen Ausführungsformen der Erfindung durch die Steuerung der Anzahl der Einträge für ein Datensegment im Ledger realisiert. Es ist anzumerken, dass Deduplizierung, wie sie hier verwendet wird, nicht notwendigerweise bedingt, dass nur eine einzige Kopie eines Datensegments im Ledger referenziert wird. Vielmehr und ganz allgemein umfasst die Datendeduplizierung den Ansatz, dass die Anzahl der Kopien eines Datensegments, auf die im Ledger referenziert werden kann, in irgendeiner Weise begrenzt wird, wobei diese Zahl X eine ganze Zahl ist, die jede Zahl sein kann, für die gilt: ≥ 1 sein kann. Wie nachstehend erläutert ist, umfassen Ausführungsformen der Erfindung Mechanismen zur Sicherstellung der Datenverfügbarkeit im Falle eines Problems. Während der Replikationsfaktor X für eine maximale Deduplizierung so niedrig wie 1 sein könnte, kann der Wert des Replikationsfaktors in der Praxis typischerweise ≥ 2 sein, um Knoten- oder Hardwareausfällen mehr Resilienz zu verleihen. Aus diesem Grund kann die Verwendung des Replikationsfaktors in einigen Ausführungsformen optional sein, da ein Replikationswert von 1 keiner Replikation entspricht.
Insbesondere verwenden Ausführungsformen des HSAN einen grundlegenden Replikationsfaktor (basic replication factor), um X Kopien eines Chunks zu speichern, so dass die Nutzer sich sicher sein können, dass noch immer auf die gespeicherten Daten-Chunks zugegriffen werden kann, wenn ein Datenträger, ein System oder sogar ein ganze Firma, die Systeme und Daten zum HSAN beisteuert, entfernt wird oder aus irgendeinem Grund nicht mehr verfügbar ist. Da der Replikationsfaktor X (wobei X mindestens 2 ist) dafür sorgt, dass X Kopien eines Chunks gespeichert werden, stehen selbst dann, wenn ein oder mehrere Chunks verloren gehen, beeinträchtigt werden oder auf sie nicht mehr zugegriffen werden kann, noch immer X-1 Kopien dieses Chunks zur Verfügung und alle Mitglieder des HSAN können auf diese zugreifen.
Wie oben erwähnt ist, wird dem Aufrufer implizit vertraut, wenn eine erste Kopie eines Chunks gespeichert wird. Wenn jedoch ein ADD_DATA-Aufruf erfolgt, um eine nachfolgende Kopie dieses Chunks zu speichern, stellen Ausführungsformen der Erfindung einen Challenge-Response-Mechanismus bereit, um Spoofing zu verhindern. In einem Beispiel für einen Challenge/Response-Prozess sendet der Aufrufer der Operation ADD_DATA eine Anfrage an einen oder mehrere Knoten 300a-e, die bereits Einträge für den in der Anfrage identifizierten Hash haben. Diese anderen Knoten antworten auf die Anfrage ADD_DATA, indem sie dem Aufrufer eine eindeutige Information zurücksenden, mit der er die in dem ADD_DATA-Aufruf identifizierten Daten transformieren kann. Diese eindeutige Information kann z. B. aus einem Salt-Wert bestehen, mit dem die Daten neu gehasht werden, oder aus einem Schlüssel, mit dem die Daten neu verschlüsselt und neu gehasht werden. Unter Verwendung des Salt, des Schlüssels oder anderer eindeutiger Informationen, die von den anderen Knoten bereitgestellt werden, antwortet der Aufrufer dann den anderen Knoten mit der angeforderten Transformation der Daten. Die anderen Knoten kommunizieren dann untereinander, und wenn sie alle zustimmen, dass der Aufrufer die richtige Antwort gegeben hat, wird zu dem Ledger ein Eintrag entsprechend dem ADD_DATA-Aufruf hinzugefügt.
Auf diese Weise verhindert der Challenge/Response-Mechanismus, dass ein Aufrufer fälschlicherweise behauptet, die Daten für einen Hash zu besitzen, und dann später den entsprechenden Chunk abruft, wodurch möglicherweise Informationen von Knoten, die den Chunk wirklich besitzen, durchsickern. Dies bedeutet, dass der Aufrufer beweisen muss, dass er die Daten besitzt, bevor er einen Eintrag zu dem Ledger für diese Daten hinzufügen darf.
In jedem Fall, in dem sich die Knoten nicht über die dem Hash entsprechenden Daten einigen können, schlägt die Operation ADD_DATA mit einem Fehler fehl, und der Zustand des HSAN gilt als unbestimmt. Die weitere Analyse kann zwischen den beteiligten Unternehmen koordiniert werden, um die Natur des Fehlers zu bestimmen. Außerdem muss bei der Initialisierung des HSAN eine kryptografische Hash-Funktion gewählt werden, die stark genug ist, um Kollisionen bei einer bestimmten Chunk-Größe zu verhindern. Die vorstehende Erläuterung bezieht sich auf Prozesse, die durchgeführt werden können, wenn ein ADD_DATA-Aufruf von einem Besitzer in Bezug auf private Daten dieses Besitzers gemacht wird. Ausführungsformen der Erfindung stellen auch das Hinzufügen von Referenzen auf öffentliche Informationen zum Ledger bereit. Wenn beispielsweise ein Knoten versucht, öffentliche Informationen hinzuzufügen, wie z. B. ein Bild in sozialen Medien, auf das im Ledger bereits durch einen Fingerabdruck referenziert wird, wird der Einreicher darüber informiert, dass die Datei bereits gespeichert wurde und eine zweite Kopie nicht erforderlich ist. In diesem Fall kann der Einreicher einfach vermerken, dass er eine Referenz auf die Daten besitzt, und er kann diese Referenz dazu verwenden, bei Bedarf von dem Knoten, der diese Daten hat, auf die Daten zuzugreifen. Bei einer erstmaligen Einreichung von öffentlichen Daten kann der im Ledger gespeicherte Eintrag einfach darauf hindeuten, dass der Einreichende im Besitz einer öffentlich zugänglichen Kopie dieser öffentlichen Daten ist.
Mit weiterem Verweis nunmehr auf einige andere beispielhafte HSAN Transaktionen kann die Transaktion REF_DATA denselben Challenge-/Response-Mechanismus nutzen, der bei den ADD DATA-Transaktionen verwendet wird, um aufzuzeichnen, dass ein Nutzer eine Referenz auf den Chunk besitzt, wenn bereits ausreichend Kopien der auf dem Diagramm aufgezeichneten Daten vorhanden sind. Das Hinzufügen eines solchen Eintrags zu dem Ledger stellt sicher, dass der Nutzer später den Chuck rückgewinnen kann, wenn dessen lokale Kopie gelöscht oder beschädigt wurde, verloren gegangen ist oder kompromittiert wurde .
Ebenso können alle Knoten, die zuvor ADD_DATA oder REF_DATA aufgerufen haben, GET_DATA dazu verwenden, anzufragen, dass ein anderer Knoten, der die Daten besitzt, den Chunk bereitstellt, der dem gelieferten Fingerabdruck entspricht. Bevor aber der Chunk bereitgestellt wird, muss der Knoten, von welchem die Daten angefragt wurden, verifizieren, dass das Ledger den passenden Eintrag für den anfragenden Knoten enthält. Die Transaktion DEREF DATA zeichnet auf, dass ein Knoten nicht mehr länger Referenzen auf einen Chunk aufweist.
Mit Bezug nunmehr auf die DEL_DATA Transaktion arbeitet diese HSAN Transaktion mit DEREF DATA zusammen, um Einträge aus dem Ledger des HSAN zu entfernen. Ein Knoten, der eine Kopie eines Chunks speichert, kann durch den Ledger scannen, um herauszufinden, ob alle Verwendungen von REF_DATA für den Chunk eine entsprechende DEREF DATA aufweisen. Diese Aktion kann ausgelöst werden, wenn die Knotenkopie des Chunks nicht mehr länger von einem Backup im Backup-Katalog des Unternehmens referenziert wird, so etwa durch eine Pflegeoperation wie beispielsweise Speicherbereinigung auf der Avamar oder DataDomain.
Stellt der vorstehend angesprochene Scan fest, dass keine externen Referenzen auf den Chunk vorliegen, kann der Knoten, der den Scan durchgeführt hat, eine DEL_DATA-Anfrage für diesen Chunk an die anderen Knoten stellen, die Kopien der Daten besitzen. Stimmen alle Knoten zu, dass nicht mehr länger etwaige Referenzen auf den Chunk gegeben sind, so zeichnen alle Knoten DEL_DATA_Einträge auf dem Ledger auf und löschen ihre jeweiligen Kopien des Chunks. Auf diese Weise wird eine Speicherbereinigungsfunktion für den HSAN durchgeführt. Es ist anzumerken, dass immer, selbst nachdem die Chunk-Kopien gelöscht worden sind, eine permanente Aufzeichnung auf dem Ledger vorhanden sein wird, dass die Daten hinzugefügt, referenziert, entreferenziert und dann gelöscht wurden. Kommt eine Anfrage ADD DATA oder REF DATA an einem beliebigen Knoten an, bevor der Eintrag DEL DATA bestätigt wurde, dann wird die Löschoperation von diesem Knoten abgebrochen, was wiederum die gesamte Operation über den HSAN abbricht. Auch wenn die Anfrage, Daten hinzuzufügen oder zu referenzieren, ankommt, nachdem DEL_DATA bestätigt wurde, müssen die Daten unter Verwendung der zuvor angesprochenen Prozesse ADD_DATA erneut hinzugefügt werden.
Die Transaktion CHECK DATA HSAN ist eine Variation von IS PRESENT, die an jeden beliebigen Knoten ausgegeben werden kann, der eine Kopie des Chunks, der einem spezifizierten Hash entspricht, aufweist. Aufrufer können diese Anfrage als Teil ihrer Datenschutzspeichersystemvalidierungsprozesse ausgeben, so etwa beispielsweise den Avamar ‚hfscheck‘ Prozess. Ein Knoten, der eine Anfrage CHECK_DATA empfängt, liest und hasht seine Kopie des Chunks erneut, um zu verifizieren, dass die Daten an diesem Knoten vorhanden und intakt sind. Das Resultat der von dem Knoten in Antwort auf die Anfrage CHECK DATA durchgeführte Operation kann für eine feststehende Zeitdauer wie etwa 1 Tag oder 1 Woche beispielsweise in einem Cache zwischengespeichert werden, um zu vermeiden, dass die Daten zu oft erneut verifiziert werden müssen. Es obliegt den Aufrufern von CHECK DATA zu entscheiden, welche Anzahl von Kopien eines Daten-Chunks ausreichend ist, um den in Antwort auf die Anfrage CHECK_DATA durchgeführten Validierungsprozess zufriedenzustellen.
Zeigt die Anfrage CHEC_DATA, dass eine oder mehrere Kopien eines Chunks aus welchen Gründen auch immer nicht zur Verfügung stehen, so führt der Knoten, der die CHECK_DATA-Anfrage initiiert hat, eine Anfrage GET_DATA durch, um eine lokale Kopie des Daten-Chunks zu speichern und um sicherzustellen, dass der Replikationsfaktor erreicht wird. Weitere DEL_DATA-Anfragen können überschüssige Daten-Chunk-Kopien bereinigen, die als ein Resultat von vorübergehenden Problemen erzeugt worden sind, so etwa dass Knoten temporär offline sind, wenn CHECK_DATA-Anfragen ausgegeben werden.
E. Beispielhafte Host- und Server-Konfigurationen
Mit Verweis nunmehr kurz auf 3 kann jede beliebige eine oder mehrere von Betriebsumgebung 100, HSAN 200, Knoten 300a-e und Ledger-Instanzen 400a-2 die Form einer physischen Rechenvorrichtung, wofür ein Beispiel mit 500 bezeichnet ist, annehmen oder diese beinhalten oder darauf implementiert sein oder davon gehostet werden. Auch wenn beliebige der zuvor angesprochenen Elemente eine virtuelle Maschine (VM) umfassen oder daraus bestehen, kann diese VM eine Virtualisierung einer beliebigen Kombination der physischen Komponenten darstellen, die in 3 geoffenbart sind.
Im Beispiel der 3 beinhaltet die physische Rechenvorrichtung 500 einen Speicher 502, der einen, einige oder alle von Random Access Memory (RAM), nicht-flüchtigem Random Access Memory (NVRAM) 504, Read-Only Memory (ROM) und nichtflüchtigem Speicher, einem oder mehreren Hardware-Prozessoren 506, nicht-flüchtigen Speichermedien 508, UI-Vorrichtung 510 und Datenspeicher 512 beinhalten. Eine oder mehrere der Speicherkomponenten 502 der physischen Rechenvorrichtung 500 können die Form eines Speichers einer Solid-State-Vorrichtung (SSD) annehmen. Auch sind eine oder mehrere Anwendungen 514 bereitgestellt, die ausführbare Instruktionen umfassen. Solche ausführbaren Instruktionen können verschiedene Formen annehmen, einschließlich dabei z.B. Instruktionen, die ausführbar sind, um eine beliebige Funktion, ein solches Verfahren oder einen Teil davon wie hierin geoffenbart durchzuführen, und/oder an/von einer beliebigen Speicherstelle ausführbar sind, sei dies nur am firmeneigenen Standort oder an einer Cloudspeicherstelle, Client, Datenzentrum, Backup-Server, Blockchain-Netzwerk oder Blockchain-Netzwerkknoten, um die hierin geoffenbarten Funktion durchzuführen. Auch können solche Instruktionen ausführbar sein, um beliebige der andere hierin geoffenbarten Operationen durchzuführen, einschließlich, aber nicht darauf beschränkt, Blockchain-Ledger-Operationen, Ledger-Eintrageinreichungen und HSAN Transaktionen.
F. Beispielhafte Verfahren
Mit Blick nunmehr auf 4 sind Aspekte von beispielhaften Verfahren geoffenbart. Ein besonders Verfahren ist allgemein mit 600 bezeichnet und betrifft die Datendeduplizierung in einer HSAN Umgebung. Das beispielhafte Verfahren 600 kann gemeinsam von mehreren Einheiten wie beispielsweise einem Knoten, HSAN und Distributed Ledger durchgeführt werden. Die in 4 angezeigte Funktionszuweisung ist nur beispielhaft bereitgestellt, und in anderen Ausführungsformen können die geoffenbarten Funktionen unter den verschiedenen Einheiten anders zugewiesen werden. Es ist auch anzumerken, dass mit den anderen Verfahren und Prozessen, die hierin geoffenbart sind, die Reihenfolge der verschiedenen Prozesse in dem Verfahren 600 anders sein kann als die angegebene Reihenfolge, und die geoffenbarten Prozesse müssen nicht in der in den Figuren angegebenen Reihenfolge durchgeführt werden.
Das beispielhafte Verfahren 600 kann beginnen, wenn ein Knoten, der als der Aufrufer bezeichnet werden kann, eine Anfrage ADD_DATA 602 an ein HSAN überträgt, wobei angefragt wird, dass ein Eintrag zu einem öffentlichen Distributed Ledger des HSAN hinzugefügt wird. In einigen Ausführungsformen zumindest ist der Aufrufer einer von einer Gruppe von Knoten, die in dem HSAN beinhaltet sind, und dementsprechend kann der übertragende Knoten eine Kopie des Distributed Ledger beinhalten. Die von dem Aufrufer übertragene Anfrage 602 kann eine Benutzerkennung umfassen, die den Knoten, einen Hash eines Datensegments und einen Speicherplatz des Datensegments an dem Knoten identifiziert. Es ist anzumerken, dass, während die Anfrage 602 einen Hash eines Datensegments beinhaltet, das Datensegment selbst nicht in der Anfrage beinhaltet ist, und der Hash kann umgekehrt nicht berechnet werden, außer von dem Aufrufer, der die ADD_DATA-Anfrage gestellt hat.
Bei 604 wird die Anfrage von den anderen Knoten des HSAN empfangen und evaluiert. Beliebige, alle oder ein bestimmter der anderen Knoten kann einen Challenge-and-Response-Prozess mit dem Aufrufer initiieren, der die Anfrage übermittelt hat 602. Der Challenge-and-Response-Prozess kann dabei helfen, Spoofing zu verhindern, indem sichergestellt wird, dass der Aufrufer tatsächlich eine Kopie des Datensegments besitzt, das de vorgibt zu besitzen. Dies geht darauf zurück, dass die ADD_DATA-Anfrage allein keine solche Sicherstellung ausgibt. Als ein Teil des Challenge-and-Response-Prozesses 606 empfängt der Aufrufer 608 eine Challenge von dem/den anderen Knoten des HSAN. Die Challenge kann eine eindeutige Information umfassen, mit welcher die in dem ADD-DATA-Aufruf identifizierten Daten zu transformieren sind. Unter Verwendung eines Salt, Schlüssels oder einer anderen eindeutigen Information, die von dem/den anderen Knoten bereitgestellt wird, antwortet 610 der Aufrufer den anderen Knoten mit der angefragten Transformation der Daten. Daraufhin kommunizieren die anderen Knoten untereinander 612, und wenn sie alle zustimmen, dass der Aufrufer die korrekte Antwort geliefert hat, wird ein Eintrag, der dem ADD_DATA - Aufruf entspricht, zu dem Ledger hinzugefügt 616.
Wie ebenfalls in 4 dargestellt ist, kann die Evaluierung der Response 610 durch den/die anderen Knoten des HSAN das Bestimmen beinhalten, ob ein Replikationsfaktor erreicht ist 614. Der Prozess 614 kann das Vergleichen beinhalten, wie viele Kopien des bei 602 identifizierten Datensegments zum Zeitpunkt der Anfrage 602 bereits im Speicher vorhanden sind. Wenn der Replikationsfaktor X ist und X-1 Kopien des Datensegments zum Zeitpunkt der Anfrage 602 existieren, wird der vom Aufrufer angefragte Eintrag 616 zu dem Ledger hinzugefügt, sofern die anderen Bedingungen dafür erfüllt sind.
Wenn andererseits der Replikationsfaktor X ist und X Kopien des Datensegments zum Zeitpunkt der Anfrage 602 existieren, wird der vom Aufrufer angefragte Eintrag nicht zu dem Ledger hinzugefügt. In diesem Fall kann dem Aufrufer mitgeteilt werden, dass der Replikationsfaktor bereits erreicht wurde und kein neuer Eintrag in den Ledger vorgenommen wird. Auf diese Weise wird eine Datendeduplizierung durchgeführt, indem die Anzahl der Kopien eines Datensegments, die im HSAN existieren dürfen, begrenzt wird.
Es wird darauf hingewiesen, dass selbst in dem Fall, in dem der Replikationsfaktor erreicht ist, der Challenge-and-Response-Prozess immer noch durchgeführt werden kann, da der Aufrufer möglicherweise irgendwann in der Zukunft auf das gespeicherte Datensegment zugreifen möchte und somit dem HSAN nachweisen müsste, dass er eine Kopie dieses Datensegments besitzt. Wenn ein Knoten also kein ADD DATA benötigt, kann stattdessen ein REF_DATA zum Ledger hinzugefügt werden, um dem Aufrufer einen zukünftigen Zugriff auf die Daten zu ermöglichen. Bei einigen Ausführungsformen der Erfindung kann daher der Prozess 616 einfach weggelassen werden, während die anderen in 4 gezeigten Prozesse beibehalten werden.
Wie aus der vorstehenden Erläuterung hervorgeht, kann der Prozess 614 jederzeit nach dem Empfang 604 der ADD _DATA-Anfrage durchgeführt werden. Die in 4 geoffenbarten besonderen Prozesse und ihre Reihenfolge sind daher nur beispielhaft dargestellt und sollen den Umfang der Erfindung nicht einschränken.
G. Weitere beispielhafte Ausführungsformen
Es folgen einige weitere beispielhafte Ausführungsformen der Erfindung. Diese sind nur beispielhaft dargestellt und sollen nicht den Umfang der Erfindung in irgendeiner Art und Weise beschränken.
Ausführungsform 1. Ein Verfahren, das umfasst: Empfangen von einem Knoten in einem HSAN, das mehrere Knoten beinhaltet, einer ADD_DATA-Anfrage, um einen Eintrag zu einem Distributed Ledger des HSAN hinzuzufügen, wobei die Anfrage eine Benutzerkennung, die den Knoten identifiziert, einen Hash eines Datensegments und einen Speicherplatz des Datensegments an dem Knoten umfasst; Durchführen eines Challenge-and-Response-Prozesses mit dem Knoten, um zu verifizieren, dass der Knoten eine Kopie der Daten besitzt, die der Gegenstand des Eintrags waren; Bestimmen, dass ein Replikationsfaktor X nicht erreicht wurde; und Hinzufügen des Eintrags zu dem Distributed Ledger nach dem erfolgreichen Abschluss des Challenge-and-Response-Prozesses.
Ausführungsform 2. Das Verfahren wie in der Ausführungsform 1 angeführt, das ferner das Aufteilen von Backup-Daten in eine Vielzahl von Datensegmenten, die das Datensegment beinhaltet, und Hashing des Datensegments umfasst.
Ausführungsform 3. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei das Distributed Ledger einem HSAN Knoten nicht gestattet, auf das Datensegment zuzugreifen, auf welchem der Eintrag basiert, sofern nicht der HSAN Knoten den Besitz einer Kopie dieses Datensegments nachgewiesen hat.
Ausführungsform 4. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei das Distributed Ledger ein öffentliches Distributed Ledger ist, das jedem beliebigen HSAN Knoten Zugriff auf den Eintrag gestattet.
Ausführungsform 5. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei das Distributed Ledger ein öffentliches Distributed Ledger ist, das einen oder mehrere Einträge beinhaltet, die auf öffentliche Daten hinweisen, auf die von allen Knoten des HSAN zugegriffen werden kann.
Ausführungsform 6. Das Verfahren wie in der Ausführungsform 1 angeführt, das ferner das Hinzufügen eines Knotens zu dem HSAN nach gegenseitiger Zustimmung der anderen Knoten des HSAN umfasst.
Ausführungsform 7. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei Metadaten, die das in der Anfrage identifizierte Datensegment betreffen, von der Anfrage ausgeschlossen sind.
Ausführungsform 8. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei die Verwendung des Replikationsfaktors X sicherstellt, dass nicht mehr als X Kopien eines Datensegments in dem HSAN gespeichert werden.
Ausführungsform 9. Das Verfahren wie in der Ausführungsform 1 angeführt, wobei Einträge in dem Distributed Ledger als eine Blockchain gespeichert sind.
Ausführungsform 10. Das Verfahren wie in der Ausführungsform 1 angeführt, das ferner das Durchführen einer oder mehrerer der folgenden HSAN Operationen umfasst: IS_PRESENT; REF_DATA; GET DATA; DEREF_DATA; DEL DATA; CHECK DATA; und/oder REPL_DATA.
Ausführungsform 11. Ein Verfahren zum Durchführen eines beliebigen der hierin geoffenbarten Prozesse oder eines beliebigen Teils davon.
Ausführungsform 12. Ein nicht-flüchtiges Speichermedium mit darauf gespeicherten Instruktionen, die von einem oder mehreren Hardware-Prozessoren ausführbar sind, um die Operationen einer beliebigen einen oder mehrerer der Ausführungsformen 1 bis 22 durchzuführen.
H. Beispielhafte Rechenvorrichtungen und assoziierte Medien
Die hier geoffenbarten Ausführungsformen können die Verwendung eines Spezial- oder Universalcomputers mit verschiedenen Computerhardware- oder -softwaremodulen beinhalten, wie nachfolgend ausführlicher erläutert ist. Ein Computer kann einen Prozessor und Computerspeichermedien umfassen, die Instruktionen enthalten, die bei Ausführung durch den Prozessor und/oder bei Veranlassung der Ausführung durch den Prozessor eines oder mehrere der hier geoffenbarten Verfahren durchführen.
Wie bereits erwähnt, umfassen Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung auch Computerspeichermedien, bei denen es sich um physische Medien handelt, auf denen computerausführbare Instruktionen oder Datenstrukturen gespeichert sind oder auf denen diese gespeichert werden können. Solche Computerspeichermedien können beliebige verfügbare physische Medien sein, auf die ein Universal- oder Spezialcomputer zugreifen kann.
Als Beispiel und ohne Einschränkung können solche Computerspeichermedien Hardwarespeicher wie Solid-State-Disk/Device (SSD), RAM, ROM, EEPROM, CD-ROM, Flash-Speicher, Phase-Change-Memory („PCM“) oder andere optische Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder andere Hardwarespeichervorrichtungen umfassen, die verwendet werden können, um Programmcode in Form von computerausführbaren Instruktionen oder Datenstrukturen zu speichern, auf die ein Universal- oder Spezialcomputersystem zugreifen und sie ausführen kann, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen der oben genannten Medien sollten ebenfalls im Umfang der Computerspeichermedien beinhaltet sein. Solche Medien sind auch Beispiele für nicht-flüchtige Speichermedien, und nicht-flüchtige Speichermedien umfassen auch Cloud-basierte Speichersysteme und - strukturen, wenngleich der Umfang der Erfindung nicht auf diese Beispiele für nicht-flüchtige Speichermedien beschränkt ist.
Computerausführbare Instruktionen umfassen beispielsweise Instruktionen und Daten, die einen Allzweckcomputer, einen Spezialcomputer oder eine Spezialverarbeitungsvorrichtung veranlassen, eine bestimmte Funktion oder eine Gruppe von Funktionen durchzuführen. Obwohl der Gegenstand in einer Sprache beschrieben wurde, die für strukturelle Merkmale und/oder methodische Vorgänge spezifisch ist, ist es zu verstehen, dass der in den angehängten Ansprüchen definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Vielmehr werden die hierin geoffenbarten spezifischen Merkmale und Handlungen als beispielhafte Formen der Implementierung der Ansprüche geoffenbart.
Wie hier verwendet, kann sich der Begriff „Modul“ oder „Komponente“ auf Softwareobj ekte oder -routinen beziehen, die auf dem Rechensystem ausgeführt werden. Die verschiedenen hierin beschriebenen Komponenten, Module, Maschinen und Dienste bzw. Services können als Objekte oder Prozesse implementiert werden, die auf dem Rechensystem ausgeführt werden, zum Beispiel als separate Threads. Das hier beschriebene System und die Methoden können zwar in Software implementiert werden, doch sind auch Implementierungen in Hardware oder eine Kombination aus Software und Hardware möglich und in Betracht zu ziehen. In der vorliegenden Offenbarung kann eine „Recheneinheit“ ein beliebiges Rechensystem, wie es zuvor definiert wurde, oder ein beliebiges Modul oder eine beliebige Kombination von Modulen sein, die auf einem Rechensystem laufen.
In zumindest einigen Fällen wird ein Hardware-Prozessor bereitgestellt, der wirksam ist, ausführbare Instruktionen zur Durchführung eines Verfahrens oder Prozesses, wie die hierin geoffenbarten Verfahren und Prozesse, auszuführen. Der Hardware-Prozessor kann, muss aber nicht ein Element anderer Hardware sein, wie z. B. die hierin geoffenbarten Rechenvorrichtungen und -systeme.
In Bezug auf Rechenumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, in Netzwerk- oder lokalen Umgebungen oder in jeder beliebigen anderen geeigneten Umgebung ausgeführt werden. Geeignete Betriebsumgebungen für zumindest einige Ausführungsformen der Erfindung beinhalten Cloud-Rechenumgebungen, in denen sich ein oder mehrere von Clients, Server oder anderen Maschinen in einer Cloud-Umgebung befinden und dort arbeiten können.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt sein, ohne von ihrem Geist oder ihren wesentlichen Charakteristiken abzuweichen. Die beschriebenen Ausführungsformen sind in jeder Hinsicht nur als veranschaulichend und nicht als einschränkend zu betrachten. Der Umfang der Erfindung ergibt sich daher eher aus den angehängten Ansprüchen als aus der vorangehenden Beschreibung. Alle Änderungen, die unter die Bedeutung und den Äquivalenzbereich der Ansprüche fallen, sind in deren Anwendungsbereich einzubeziehen.

Claims

Verfahren, das umfasst: Empfangen von einem Knoten in einem HSAN, das mehrere Knoten beinhaltet, einer ADDDATA-Anfrage, um einen Eintrag zu einem Distributed Ledger des HSAN hinzuzufügen, wobei die Anfrage eine Benutzerkennzeichnung, die den Knoten identifiziert, einen Hash eines Datensegments und einen Speicherplatz des Datensegments an dem Knoten umfasst; Durchführen eines Challenge-and-Response-Prozesses mit dem Knoten, um zu verifizieren, dass der Knoten eine Kopie der Daten besitzt, die der Gegenstand des Eintrags waren; Bestimmen, dass ein Replikationsfaktor X nicht erreicht wurde; und Hinzufügen des Eintrags zu dem Distributed Ledger nach dem erfolgreichen Abschluss des Challenge-and-Response-Prozesses.
Verfahren wie im Anspruch 1 angeführt, das ferner das Aufteilen von Backup-Daten in eine Vielzahl von Datensegmenten, die das Datensegment beinhaltet, und Hashing des Datensegments umfasst.
Verfahren wie im Anspruch 1 angeführt, wobei der Distributed Ledger einem HSAN Knoten nicht gestattet, auf das Datensegment zuzugreifen, auf welchem der Eintrag basiert, sofern nicht der HSAN Knoten den Besitz einer Kopie dieses Datensegments nachgewiesen hat.
Verfahren wie im Anspruch 1 angeführt, wobei der Distributed Ledger ein öffentlicher Distributed Ledger ist, der jedem beliebigen HSAN Knoten Zugriff auf den Eintrag gestattet.
Verfahren wie im Anspruch 1 angeführt, wobei der Distributed Ledger ein öffentlicher Distributed Ledger ist, der einen oder mehrere Einträge beinhaltet, die auf öffentliche Daten hinweisen, auf die von allen Knoten des HSAN zugegriffen werden kann.
Verfahren wie im Anspruch 1 angeführt, das ferner das Hinzufügen eines Knotens zu dem HSAN nach gegenseitiger Zustimmung der anderen Knoten des HSAN umfasst.
Verfahren wie im Anspruch 1 angeführt, wobei Metadaten, die das in der Anfrage identifizierte Datensegment betreffen, von der Anfrage ausgeschlossen sind.
Verfahren wie im Anspruch 1 angeführt, wobei die Verwendung des Replikationsfaktors X sicherstellt, dass nicht mehr als X Kopien eines Datensegments in dem HSAN gespeichert werden.
Verfahren wie im Anspruch 1 angeführt, wobei Einträge in dem Distributed Ledger als eine Blockchain gespeichert sind.
Verfahren wie im Anspruch 1 angeführt, das ferner das Durchführen einer oder mehrerer der folgenden HSAN Operationen umfasst: IS_PRESENT; REF_DATA; GET DATA; DEREF_DATA; DEL DATA; CHECK DATA; und/oder REPL DATA.
Nicht-flüchtiges Speichermedium, das darin gespeichert Instruktionen, die von einem oder mehreren Hardware-Prozessoren ausgeführt werden können, um Operationen durchzuführen, aufweist, dabei umfassend: Empfangen von einem Knoten in einem HSAN, das mehrere Knoten beinhaltet, einer ADDDATA-Anfrage, um einen Eintrag zu einem Distributed Ledger des HSAN hinzuzufügen, wobei die Anfrage eine Benutzerkennzeichnung, die den Knoten identifiziert, einen Hash eines Datensegments und einen Speicherplatz des Datensegments an dem Knoten umfasst; Durchführen eines Challenge-and-Response-Prozesses mit dem Knoten, um zu verifizieren, dass der Knoten eine Kopie der Daten besitzt, die der Gegenstand des Eintrags waren; Bestimmen, dass ein Replikationsfaktor X nicht erreicht wurde; und Hinzufügen des Eintrags zu dem Distributed Ledger nach dem erfolgreichen Abschluss des Challenge-and-Response-Prozesses.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei die Operationen ferner das Aufteilen von Backup-Daten in eine Vielzahl von Datensegmenten, die das Datensegment beinhaltet, und das Hashing des Datensegments umfassen.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei das Distributed Ledger einem HSAN Knoten nicht gestattet, auf das Datensegment zuzugreifen, auf welchem der Eintrag basiert, sofern nicht der HSAN Knoten den Besitz einer Kopie dieses Datensegments nachgewiesen hat.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei der Distributed Ledger ein öffentlicher Distributed Ledger ist, der jedem beliebigen HSAN Knoten Zugriff auf den Eintrag gestattet.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei der Distributed Ledger ein öffentlicher Distributed Ledger ist, der einen oder mehrere Einträge beinhaltet, die auf öffentliche Daten hinweisen, auf die von allen Knoten des HSAN zugegriffen werden kann.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei die Operationen ferner das Hinzufügen eines Knotens zu dem HSAN nach gegenseitiger Zustimmung der anderen Knoten des HSAN umfassen.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei Metadaten, die das in der Anfrage identifizierte Datensegment betreffen, von der Anfrage ausgeschlossen sind.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei die Verwendung des Replikationsfaktors X sicherstellt, dass nicht mehr als X Kopien eines Datensegments in dem HSAN gespeichert werden.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, wobei Einträge in dem Distributed Ledger als eine Blockchain gespeichert sind.
Nicht-flüchtiges Speichermedium wie im Anspruch 11 angeführt, das ferner das Durchführen einer oder mehrerer der folgenden HSAN Operationen umfasst: IS_PRESENT; REF_DATA; GET DATA; DEREF_DATA; DEL DATA; CHECK DATA; und/oder REPL_DATA.