DE112019005311T5

DE112019005311T5 - Serverlose lösung zur optimierung von objektversionierung

Info

Publication number: DE112019005311T5
Application number: DE112019005311.6T
Authority: DE
Inventors: Assaf Natanzon; Yossef Saad
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2018-10-26
Filing date: 2019-07-10
Publication date: 2021-08-19
Also published as: GB2591925B; CN112955860A; US20200134030A1; WO2020086125A1; IE20190227A1; GB202104604D0; US11281635B2; GB2591925A

Abstract

Ein beispielhaftes Verfahren umfasst das Implementieren einer Funktion als Dienst (FaaS) in einem Datenzentrum durch Durchführen von Operationen, die Empfangen eines Anwendungsprogrammschnittstellen(API)-Gateway-Aufrufs von einer Client-Anwendung, wobei der API-Gateway-Aufruf mit einer Objekt-PUT-Anfrage assoziiert ist, und automatisches Auslösen, mit dem API-Gateway-Aufruf, der Durchführung einer Objekteinfügefunktion umfassen. Die Objekteinfügefunktion umfasst Abrufen einer vorherigen Version des Objekts von einer Backend-Objektspeichervorrichtung, differentielles Komprimieren des Objekts in Bezug auf die vorherige Version des Objekts, um eine Differential zu erzeugen, und Speichern des Differentials in der Backend-Objektspeichervorrichtung.

Description

GEBIET DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung betreffen allgemein Datenschutz und -verfügbarkeit. Insbesondere betreffen zumindest einige Ausführungsformen der Erfindung Systeme, Hardware, Software, computerlesbare Medien und Verfahren zur Optimierung von Objektversionierung, um den Speicherplatz zu verringern, der von Objekten verbraucht wird.
HINTERGRUND
Unternehmen produzieren signifikante Mengen an wichtigen Daten, die typischerweise in einer Art von Datenschutzumgebung gespeichert werden. Typische Datenschutzumgebungen verwenden unterschiedliche Hardware und Software, um Datensicherheit, -zugang und -verfügbarkeit bereitzustellen.
Beispielsweise ist Objektspeicherung heute in öffentlichen Clouds und auch in Räumlichkeiten von Unternehmen oder anderen Einheiten weit verbreitet. Beispiele für solche öffentlichen Cloud-Speicherumgebungen umfassen Amazon S3 und Dell EMC Elastic Cloud Storage (ECS).
Viele der von Cloud-Speicherumgebungen verwendete Objektspeicher unterstützen Objektversionierung, wodurch es dem Benutzer ermöglicht wird, vorherige Versionen eines Objekts zu Datenschutz- und Datenverwaltungszwecken zu behalten. Diese Flexibilität und Kapazität hat jedoch ihren Preis. D. h. obwohl verschiedene Versionen desselben Objekts häufig sehr ähnlich sind, muss der Benutzer für die Speicherkapazität bezahlen, die jede vollständige Version des Objekts verbraucht. Somit zahlt der Benutzer für Speicherkapazität, die eventuell nicht benötigt wird.
Genauer gesagt sind Versionen desselben Objekts tendenziell ähnlich. Im Falle von Präsentationen und Word-Dokumenten ändert jede Version der Datei üblicherweise beispielsweise das Objekt nur geringfügig. Ein weiteres Beispiel sind Sicherungskopien des Objekts. Sicherungskopien werden regelmäßig erstellt, z. B. einmal täglich, und die jeden Tag erstellten Kopien unterschieden sich nicht stark oder möglicherweise gar nicht voneinander. Mit aktuellen Verfahren zur Erzeugung von Versionen besteht der Speicher, der einem Kunden verrechnet wird, aus einer vollständigen Kopie jeder Version, was unnötig teuer ist. D. h. die Kosten für eine Objektversion basieren nur auf der Objektgröße und nicht auf dem Umfang oder dem Ausmaß von Änderungen am Objekt, sodass die Kosten für die Speicherung der modifizierten Version die gleichen sind wie die Kosten für die Speicherung der vorherigen Version des Objekts, auch wenn nur geringfügige Änderungen am Objekt vorgenommen werden. Folglich können die Kosten für die Speicherung eines Objekts mit mehreren Versionen in der Cloud signifikant höher sein als die lokale Speicherung des Objekts in beispielsweise einem Deduplizierungsunterstützungsspeicher.
Figurenliste
Um die Weise zu beschreiben, in der zumindest einige der Vorteile und Merkmale der Erfindung erhalten werden können, folgt eine genauere Beschreibung von Ausführungsformen der Erfindung unter Bezugnahme auf bestimmte Ausführungsformen davon, die in den beiliegenden Zeichnungen veranschaulicht sind. Basierend auf dem Verständnis, dass diese Zeichnungen lediglich typische Ausführungsformen der Erfindung darstellen und daher nicht als Einschränkung ihres Schutzumfangs zu erachten sind, werden Ausführungsformen der Erfindung unter Verwendung der beiliegenden Zeichnungen mit mehr Genauigkeit und in größerem Detail beschrieben und erläutert.

1 offenbart Aspekte einer beispielhaften Betriebsumgebung für einige Ausführungsformen der Erfindung.
2 offenbart Aspekte einer beispielhaften Host-Konfiguration.
3 ist eine graphische Darstellung, die einige allgemeine Aspekte der Struktur und des Betriebs von FaaS offenbart.
4 ist eine graphische Darstellung, die einige Aspekte der Struktur und des Betriebs von FaaS mit Objektversionierung offenbart.
5 ist ein Flussdiagramm, das Aspekte eines Verfahrens zur Implementierung von Objekteinfügung in FaaS umfasst.
6 ist ein Flussdiagramm, das Aspekte eines Verfahrens zur Implementierung von Objektauslesungen in FaaS offenbart.
7 ist ein Flussdiagramm, das Aspekte eines Verfahrens zur Implementierung von Objektlöschung als FaaS offenbart.

AUSFÜHRLICHE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Ausführungsformen der vorliegenden Erfindung betreffen allgemein Datenschutz und -verfügbarkeit. Insbesondere betreffen zumindest einige Ausführungsformen der Erfindung Systeme, Hardware, Software, computerlesbare Medien und Verfahren zur Optimierung von Objektversionierung, um den Speicherplatz zu verringern, der von Objekten verbraucht wird.
Im Allgemeinen umfassen beispielhafte Ausführungsformen der Erfindung einen Ansatz Funktion als Dienst (FaaS; Function as a Service) für einen Objektversionierungsdienst, der eine Kompaktifizierung mehrerer Versionen eines Objekts und möglicherweise signifikante Kosteneinsparungen angesichts der verringerten Speichermenge ermöglicht, die für die Objekte eines Client erforderlich sind. Wie hierin verwendet umfasst FaaS, ohne Einschränkung, eine Kategorie von Cloud-Computing-Diensten, die eine Plattform bereitstellen, die es Kunden ermöglichen, Anwendungsfunktionalitäten ohne die Komplexität des Aufbauens und Wartens der Infrastruktur zu entwickeln, auszuführen und zu verwalten, die üblicherweise mit der Entwicklung und dem Starten einer App assoziiert ist.
Ausführungsformen innerhalb des Schutzumfangs der Erfindung umfassen FaaS, die vorhandene Versionierung wirksam einsetzen kann, die von öffentlichen Clouds unterstützt wird, die aber die Daten in der öffentlichen Cloud in einem viel kompakteren Format speichern kann. Kurz gesagt wird unter Verwendung einer Anwendungsprogrammierschnittstelle (Application Program Interface, API) ein Objektspeicher-Frontend erzeugt, das einen Einsprungspunkt für den FaaS-Dienst darstellen wird. Das API-Frontend wird eine Objektspeicher-API unterstützende Objektversionierung darlegen. Wenn eine Funktion im API-Frontend aktiviert wird, wird die FaaS aufgerufen. Die Funktion wird die APIs, z. B. PUT/GET/DELETE Objekt implementieren, indem sie die Aufrufe an einen Backend-Objektspeicher weiterleitet.
Dann können Ausführungsformen der Erfindung vorteilhafterweise verschiedene Vorteile und Verbesserungen im Vergleich zu herkömmlicher Hardware, herkömmlichen Systemen und herkömmlichen Verfahren bereitstellen. Zur Veranschaulichung können Ausführungsformen der Erfindung den Betrieb eines Rechensystems oder eines Elements eines Rechensystems durch eine Verbesserung der Effizienz verbessern, mit der die Daten gespeichert werden. Außerdem verbessern Ausführungsformen der Erfindung den Betrieb von Rechensystemen durch Erhöhung des Platzes, der für die Datenspeicherung verfügbar ist. Als letztes Beispiel verbessern Ausführungsformen der Erfindung den Betrieb von Rechensystemen durch Verringerung der Datenmenge, die gespeichert werden muss. Verschiedene andere vorteilhafte Aspekte von beispielhaften Ausführungsformen der Erfindung werden aus dieser Offenbarung hervorgehen. Darüber hinaus erfordern zumindest einige beispielhafte Ausführungsformen der FaaS-Implementierung keine externen Datenbanken. Somit basieren die Kosten großteils auf dem Aufruf von Funktionen und weniger auf den Speicherkosten. Demgemäß können signifikante Kosteneinsparungen in Bezug auf den verwendeten Speicherplatz erzielt werden.
Aspekte einer beispielhaften Betriebsumgebung
Nachstehend folgt eine Erläuterung von Aspekten von beispielhaften Betriebsumgebungen für verschiedene Ausführungsformen der Erfindung. Diese Erläuterung soll den Schutzumfang der Erfindung oder die Anwendbarkeit der Ausführungsformen in keiner Weise einschränken.
Bei Datenschutzoperationen, wie z. B. Sicherungs- und/oder Wiederherstellungsoperationen, können zumindest einige Ausführungsformen in Verbindung mit einer Datenschutzumgebung eingesetzt werden, die Sicherungs-, Archivierungs-, Wiederherstellungs- und/oder Notfallwiederherstellungsfunktionen implementieren kann. Der Schutzumfang der Erfindung ist jedoch nicht auf diese beispielhafte Datenschutzumgebung eingeschränkt und erstreckt sich allgemeiner auf jegliche Datenschutzumgebung, in Verbindung mit welcher Daten erzeugt, gespeichert, gesichert und/oder wiederhergestellt werden. Noch allgemeiner umfasst der Schutzumfang der Erfindung jegliche Betriebsumgebung, in welcher die offenbarten Konzepte nützlich sein können. Beispielsweise können Ausführungsformen der Erfindung in Verbindung mit Datensicherungs- und -Wiederherstellungsplattformen wie den Plattformen Dell-EMC NetWorker und Avamar verwendet werden.
Die Datenschutzumgebung kann die Form einer öffentlichen oder privaten Cloud-Speicherumgebung, einer Vor-Ort-Speicherumgebung und von Hybrid-Speicherumgebungen, die öffentliche und private Elemente umfassen, aufweisen, obwohl sich der Schutzumfang der Erfindung auch auf jegliche andere Art von Datenschutzumgebung erstreckt. Jede dieser beispielhaften Speicherumgebungen kann teilweise oder vollständig virtualisiert sein. Die Speicherumgebung kann ein Datenzentrum umfassen oder daraus bestehen, das betreibbar ist, um Dienste für Lese- und Schreiboperationen bereitzustellen, die von einem oder mehreren Clients initiiert werden.
Zusätzlich zur Speicherumgebung kann die Betriebsumgebung auch eine oder mehrere Host-Vorrichtungen, z. B. Clients, umfassen, die eine oder mehrere Anwendungen aufweisen. Als solches kann ein bestimmter Client einen oder mehrere Fälle einer oder mehrerer solcher Anwendungen einsetzen oder auf andere Weise damit assoziiert sein. Im Allgemeinen sind die von den Clients eingesetzten Anwendungen nicht auf eine bestimmte Funktionalität oder Art von Funktionalität eingeschränkt. Einige beispielhafte Anwendungen und Daten umfassen E-Mail-Anwendungen, wie z. B. MS Exchange, Datensysteme sowie Datenbanken wie etwa Oracle-Datenbanken und SQL-Server-Datenbanken. Die Anwendungen auf den Clients können neue und/oder modifizierte Daten erzeugen, die geschützt werden sollen.
Jede der hierin offenbarten Vorrichtungen oder Einheiten kann durch eine oder mehrere Datenschutzpolitiken gemäß verschiedenen Ausführungsformen der Erfindung geschützt sein. Weitere Beispiele für Vorrichtungen, die anhand einer Datenschutzpolitik gemäß Ausführungsformen der Erfindung geschützt werden können, umfassen, ohne Einschränkung, Container und VMs.
Jede der Vorrichtungen, einschließlich der Clients, Server und Hosts, in der Betriebsumgebung kann die Form von Software, physischen Maschinen oder virtuellen Maschinen (VM) oder eine beliebige Kombination davon aufweisen, obwohl keine bestimmte Vorrichtunsgimplementierung oder -konfiguration für irgendeine Ausführungsform erforderlich ist. Auf ähnliche Weise können beispielsweise Datenschutzsystemkompomenten, wie z. B. Datenbanken, Speicher-Server, Speichervolumina (LUNs), Speicherplatten, Replikationsdienste, Sicherungsserver, Wiederherstellungsserver, Sicherungs-Clients und Wiederherstellungs-Clients, auch die Form von Software, pyhsikalischen Maschinen oder virtuellen Maschinen (VM) aufweisen, obwohl keine bestimmte Komponentenimplementierung für irgendeine Ausführungsform erforderlich ist. Wenn VMs eingesetzt werden, kann ein Hypervisor oder ein anderer Virtuelle-Maschine-Monitor (VMM) eingesetzt werden, um die VMS zu erzeugen und zu steuern.
Wie hierin verwendet soll die Bezeichnung „Daten‟ eine umfassende Bedeutung haben. Somit umfasst die Bezeichnung beispielsweise und ohne Einschränkung Datensegmente, wie sie beispielsweise durch Datenstromsegmentierungsprozesse hergestellt werden können, Datenblöcke, atomare Daten, E-Mails, Objekte beliebiger Art, Dateien, Kontakte, Verzeichnisse, Unterverzeichnisse, Volumina und jede beliebige Gruppe aus einer oder mehreren der Vorgenannten.
Beispielhafte Ausführungsformen der Erfindung sind in jedem System anwendbar, das in der Lage ist, verschiedene Arten von Objekten in analoger, digitaler oder anderer Form zu speichern und zu bearbeiten. Obwohl Bezeichnungen wie Dokumente, Datei, Block oder Objekt als Beispiel verwendet werden können, sind die Prinzipien der Offenbarung nicht auf eine bestimmte Darstellungs- und Speicherform von Daten oder anderen Informationen eingeschränkt. Solche Prinzipien sind vielmehr auf jedes beliebige Objekt anwendbar, das Informationen darstellen kann.
Unter besonderer Bezugnahme auf 1 kann eine Betriebsumgebung 100 eine Datenschutzumgebung umfassen, die beispielsweise ein Datenzentrum 200, wie z. B. ein Cloud-Datenzentrum, umfassen oder daraus bestehen kann. Das Datenzentrum 200 kann Microsoft Azure Blob Storage, Amazon S3, Dell EMC ECS oder eine beliebige andere Cloud-Speicherumgebung sein. Beispielsweise kann jede(s) aus verschiedenen FaaS-Anbietern und assoziierten APIs in Verbindung mit Ausführungsformen der Erfindung eingesetzt werden, und solche FaaS-Anbieter/APIs umfassen, ohne Einschränkung, Amazon AWS (AWS Lambda API), Google (Firebase), Microsoft (Azure - serverlose Funktionen) und IBM (Bluemix).
In dem Beispiel aus 1 kann das Datenzentrum 200 ein FaaS-Modul 202 umfassen, das einen Teil oder das Ganze beliebiger der hierin offenbarten beispielhaften Verfahren in Bezug auf die Optimierung von Objektspeicherung ausführen kann. Das Datenzentrum 200 kann auch verschiedene Hardware 204 umfassen, wobei Beispiele hierin offenbart sind, die zur Bereitstellung von Diensten verwendet werden können, die vom und/oder in die Richtung des FaaS-Moduls(s) 202 ausgeführt werden.
Da die Hardware 204, die in einigen Ausführungsformen die Form eines oder mehrerer Server annehmen kann, der zur Ausführung eines Benutzercodes notwendig ist, wie z. B. durch das FaaS-Modul 202 ausgeführt, befindet sich beispielsweise im Datenzentrum 200, wobei einige beispielhafte Ausführungsformen der Erfindung als Implementierung einer serverlosen Lösung zur Optimierung von Objektversionierung bezeichnet werden können. D. h. das FaaS-Modul 202 kann beispielsweise einen Benutzercode als Antwort auf das Auftreten bestimmter Ereignisse ausführen, z. B. von HTTP-Befehlen und API-Aufrufen. In einer solchen serverlosen Konfiguration kann die Verwaltung der zugrundeliegenden Ressourcen, die zur Ausführung des Codes notwendig sind, am Datenzentrum 200 und nicht auf der Benutzerseite stattfinden. Daher muss der Benutzer nicht die Ressourcen haben oder bereitstellen, wie beispielsweise Server, die zur Ausführung des Benutzercodes notwendig sind. Somit spart der Benutzer die Zeit und die Ausgaben zur Erhaltung der Ressourcen, die zur Ausführung des Benutzercodes notwendig sind. D. h. die Infrastruktur, die zur Ausführung des Benutzercodes notwendig ist, wird am Datenzentrum 200 bereitgestellt und muss nicht vom Benutzer bereitgestellt werden. Ein Beispiel für eine Infrastruktur, die serverlose Client-Operationen bereitstellen kann, ist das System Amazon Lambda, obwohl der Schutzumfang der Erfindung nicht auf dieses Beispiel eingeschränkt ist.
Das Datenzentrum 200 kann verschiedene Datenschutzprozesse unterstützen, einschließlich beispielsweise Datenreplikation, Datenreduplikation, Klonierung, Datensicherung und Datenwiederherstellung. Wie hierin verwendet ist die Bezeichnung Sicherungskopie breit zu verstehen und umfasst, ohne Einschränkung, teilweise Sicherungskopien, inkrementelle Sicherungskopien, volle Sicherungskopien, Klone, Snapshots, kontinuierliche Replikation und jede beliebige andere Art von Kopien von Daten und jede beliebige Kombination der Vorgenannten. Jedes der Vorgenannten kann dedupliziert werden oder nicht.
Weiterhin auf 1 Bezug nehmend kann das Datenzentrum 200 eine Objektspeichervorrichtung 206 umfassen oder auf andere Weise Zugang dazu haben. Im Allgemeinen kann die Objektspeichervorrichtung 206, die hierin auch einfach als Objektspeicher bezeichnet werden kann, Objekte und Versionen von Objekten beispielsweise in Verbindung mit Befehlen PUT, GET und DELETE abrufbar speichern. Die Objektspeichervorrichtung 206 kann eine Mischung von Speicherarten einsetzen oder durch eine solche unterstützt werden, wie z. B. einen Festkörper(solid state drive; SSD)-Speicher für Arbeitsvorgänge vom Transaktionstyp wie Datenbanken und Boot-Volumina, deren Leistung typischerweise im Hinblick auf die durchgeführte Anzahl von Eingabe-/Ausgabeoperationen (IOPS) betrachtet wird. Zusätzlich oder alternativ dazu kann die Objektspeichervorrichtung 206 Festplatten(hard disk drive; HDD)-Speicherung für durchlaufintensive Arbeitsvorgänge umfassen.
Wie in 1 dargestellt kann die Betriebsumgebung 100 einen oder mehrere Clients 300 umfassen. Im Allgemeinen kann ein Client 300 eine beliebige Recheneinheit sein, die Hardware und/oder Software umfassen kann, die verschiedene Prozesse in Verbindung mit einem oder mehreren Objekten ausführt. Solche Prozesse können beispielsweise das Erzeugen, Löschen und Modifizieren eines Objekts umfassen. Einer, einige oder alle dieser Prozesse können durch eine Anwendung oder durch Anwendungen ausgeführt werden, die beim Client 300 liegen oder von diesem gehostet werden. In einigen bestimmten Ausführungsformen kann der Client 300 einen Sicherungs- und Wiederherstellungsserver umfassen oder daraus bestehen, obwohl das nicht erforderlich ist.
In Verbindung mit der Leistung verschiedener Prozesse und Operationen in Bezug auf Objekte und Objektversionen kann der Client 300 eine App 302 umfassen, die vom Benutzer betrieben werden kann, um API-Aufrufe an eine API 400 auszugeben, durch die der Benutzer auf den FaaS 2020 zugreifen kann. Somit kann die API 400 als Eintrittspunkt in das FaaS 202 dienen. Weitere Details bezüglich des Betriebs von Client 300, API 400 und FaaS 202 werden an anderer Stelle hierin offenbart.
Beispielhafte Host- und Server-Konfigurationen
Unter kurzer Bezugnahme auf 2 können eines oder mehrere aus Datenzentrum 200, FaaS-Modul 202, Hardware 204, Objektspeichervorrichtung 206, Client 300 und API 400/ die Form einer physischen Rechenvorrichtung annehmen oder eine solche umfassen oder auf einer solchen implementiert sein oder von einer solchen gehostet werden, wobei ein Beispiel mit 500 bezeichnet ist. Beispielsweise können ein Teil der oder die gesamte Funktionalität von FaaS 202 in einem Server am Datenzentrum 200 implementiert sein. Wenn eines der vorgenannten Elemente eine virtuelle Maschine (VM) umfasst oder daraus besteht, kann diese VM außerdem eine Virtualisierung jeder Kombination der physischen Komponenten darstellen, wie in 2 offenbart.
Im Beispiel aus 2 umfasst die physische Rechenvorrichtung 500 einen Arbeitsspeicher 502, der eines, mehrere oder alle aus einem Direktzugriff-Arbeitsspeicher (RAM), nichtflüchtigen Direktzugriff-Arbeitsspeicher (NVRAM) 504, schreibgeschützten Arbeitsspeicher (ROM) und persistenten Arbeitsspeicher, einem oder mehreren Hardware-Prozessoren 506, nichtflüchten Speichermedium 508, einer Ul-Vorrichtung 510 und einem Datenspeicher 512 umfassen kann. Eines oder mehrere aus den Arbeitsspeicherkomponenten 502 der physischen Rechenvorrichtung 500 können die Form eines Festkörper(SSD)-Speichers aufweisen. Außerdem sind eine oder mehrere Anwendungen 514 bereitgestellt, die ausführbare Anweisungen umfassen. Solche ausführbaren Anweisungen können verschiedene Formen annehmen, einschließlich beispielsweise Anweisungen, die ausführbar sind, um ein beliebiges Verfahren oder einen Teil davon wie hierin offenbart auszuführen, und/oder von/an einer Speicherstelle ausführbar sind, egal ob vor Ort bei einem Unternehmen oder an einer Cloud-Speicherstelle, einem Client, einem Datenzentrum oder einem Sicherungsserver, um hierin offenbarte Funktionen in Verbindung mit Ausführungsformen von FaaS 202 auszuführen. Außerdem können solche Anweisungen ausführbar sein, um beliebige der anderen hierin offenbarten Operationen auszuführen, einschließlich, ohne Einschränkung, Lese-, Schreib-, Sicherungs- und Wiederherstellungsoperationen und/oder beliebiger anderer Datenschutzoperationen.
Beispielhafte FaaS-Operationen und -Konfigurationen
Unter Bezugnahme auf 3 werden nun Details zu einem beispielhaften Arbeitsablauf eines FaaS bereitgestellt. Der bestimmte angeführte Vorgang ist eine Objekteinfügung, aber der angegebene allgemeine Arbeitsablauf gilt auch für andere Operationen. In dem Beispiel aus 3 löst eine Aktion, wie z. B. die Einfügung eines Objekts in einen Objektspeicher, einen Funktionsaufruf aus, z. B. einer Funktion zur Verarbeitung des Objekts und zum Speichern des Objekts in einer Datenbank (DB). In manchen Fällen kann die Auslöseaktion beispielsweise durch einen Client oder Benutzer über eine API initiiert werden, wobei ein Beispiel in 1 offenbart ist. Somit kann der Prozess „Objekt einfügen‟ eine Aktion umfassen, d. h. die Einfügung des Objekts, und kann auch als Auslöser zum Auslösen eines weiteren Funktionsaufrufs dienen, z. B. des Funktionsaufrufs zur Verarbeitung und Speicherung des Objekts. Dieser Ansatz kann als eine Kettenformat oder eine Kettenstruktur aufweisend bezeichnet werden.
Wie weiter in 3 dargestellt kann die Aktion/der Auslöseprozess in Kaskaden- oder abhängiger Form weiterlaufen, bei dem beispielsweise eine erste Aktion/ein erster Auslöser, wie z. B. „Objekt einfügen‟, die Durchführung einer zweiten Aktion durch Auslösung, d. h. Bewirken des Aufrufs eines Funktionsaufrufs, z. B. „Objekt verarbeiten‟, bewirkt, was zur Ausführung der zweiten Aktion führt, d. h. zur Verarbeitung des Objekts. Während die Funktion „Objekt verarbeiten‟ vielleicht nicht explizit vom Benutzer aufgerufen wird, wird die Funktion „Objekt verarbeiten‟ implizit aufgerufen, wenn der Benutzer die Aktion der Objekteinfügung initiiert, die bewirkt, dass die Funktion „Objekt verarbeiten‟ aufgerufen wird.
Bei jedem Vorkommen des Prozesses Aktion/Auslöser kann eine Aktion auf eine unterschiedliche jeweilige Einheit gerichtet sein. So ist in dem veranschaulichten Beispiel die Aktion „Objekt einfügen‟ auf einen Objektspeicher gerichtet, während die Aktion in Verbindung mit dem Funktionsaufruf „Objekt verarbeiten‟ auf eine andere jeweilige Einheit gerichtet sein kann, und in manchen Ausführungsform können eine oder mehrere Aktionen auf eine gemeinsame Einheit gerichtet sein. Dieser Aktion/Auslöser-Ansatz kann nach Bedarf wiederholt werden.
Somit ist in dem Beispiel aus 3 die Verarbeitung des Objekts in Verbindung mit der Funktion „Objekt verarbeiten‟ eine Aktion, die auch als Auslöser zum Aktivieren einer Funktion „DB verarbeiten‟ dient, die eine Verarbeitung und Speicherung des Objekts in einer SQL-Datenbank bewirkt. Solch eine Verarbeitung und Speicherung löst wiederum den Aufruf einer Funktion „DB verarbeiten‟ aus, was beispielsweise zur Verarbeitung und dann Speicherung des Objekts in einer verteilten Datenbank, wie z. B. Mongo, führt. Schließlich löst die Verarbeitung und Speicherung in Bezug auf die verteilte Datenbank wiederum den Aufruf einer Funktion „Kognitiven Algorithmus in Bluemix ausführen‟ aus, die bewirkt, dass ein kognitiver Algorithmus in Bezug auf die IBM-Bluemix-Umgebung ausgeführt wird. IBM Bluemix ist allgemein eine Cloud-Plattform, die verschiedene Sprachen und Dienste unterstützt und das Bauen, Ausführen und Einsetzen von Anwendungen in einer Cloud-Rechenumgebung ermöglicht.
In Verbindung mit dem Beispiel aus 3 kann das der hierin offenbarte beispielhafte FaaS-Arbeitsablauf an einer Stelle ausgeführt werden, die von einem Benutzerstandort entfernt ist, wie z. B. einem Cloud-Datenzentrum, obwohl die verschiedenen ausgeführten Funktionen vom Benutzer initiiert werden können. Außerdem kann die Bereitstellung des beispielhaften FaaS-Arbeitsablaufs von einem FaaS-Modul im Cloud-Datenzentrum ausgeführt werden. Somit können der beispielhafte FaaS-Arbeitsablauf und assoziierte Funktionen als serverlos in ihrer Art bezeichnet werden, da der/die Server zur Implementierung des Arbeitsablaufs sich nicht am Benutzerstandort befinden.
Beispielhafte Objektversionierungsdienste und -architektur
Unter Bezugnahme auf 4 werden nun Details zu einigen beispielhaften Objektversionierungsdiensten, die als FaaS implementiert werden und assoziierten Architekturen bereitgestellt. Im Allgemeinen offenbart 4 ein effizientes Objektspeicherversionierungsschema in einer Amazon-Lambda-Implementierung, obwohl solche Schemata in jedem beliebigen Objektspeicher und jedem FaaS-Dienst implementiert werden können. Kurz zusammengefasst offenbart das Beispiel von 4 ein Schema, bei dem der Benutzer an eine reguläre Amazon-S3-API schreibt und eine Funktion aufgerufen und ausgeführt wird, die das Differential erzeugt und es effizient in einem Backend-Speicher speichert.
Im Beispiel aus 4 umfasst die Architektur 600 eine Amazon-Lambda-Implementierung. Der Schutzumfang der Erfindung ist jedoch nicht auf diese beispielhafte Implementierung eingeschränkt. In Verbindung mit der Architektur 600 kann ein Verfahren (siehe 5) zur Erzeugung eines Dienstes zur Objektversionierung unter Verwendung einer Funktion als Dienst (FaaS) implementiert werde. Im Allgemeinen kann der Objektversionierungsdienst von öffentlichen Clous unterstütze Versionierung wirksam einsetzen, die Daten aber in einem viel kompakteren Format halten.
Die beispielhafte Architektur 600 umfasst ein Objektspeicher-Frontend, das eine API 602 umfasst oder daraus besteht, die als Einsprungspunkt zum FaaS-Dienst dient. Die API 602 kann beispielsweise die Amazon S3 API umfassen, obwohl nicht unbedingt eine bestimmte API erforderlich ist. Die API 602 kann mit einem Benutzer, z. B. dem Client 300 (siehe 2) in Kontakt sein und kann API-Aufrufe von einer Client-App, z. B. der Client-App 302, empfangen. Im Allgemeinen bietet das Frontende der API 602 eine Objektspeicher-API, die Objektversionierung unterstützt. Wenn eine Funktion im Frontend der API 602 aktiviert wird, wird eine Funktion als Dienst (FaaS) aufgerufen, indem eine Anfrage zur Ausführung eines Benutzercodes von der API 602 an eine Rechendienstplattform 604, z. B. AWS Lambda, übertragen wird. Die Rechendienstplattform 604 kann an die API 602 zurück antworten und beispielsweise angeben, dass die Anfrage zur Ausführung eines Benutzercodes empfangen wurde.
Die Rechendienstplattform 604 kann dann den Benutzercode ausführen. Beispielsweise kann die FaaS die API-Aufrufe, z. B. PUT/GET/DELETE Objekt, ausführen, indem sie die Funktionsaufrufe zu einer Backend-Objektspeichervorrichtung weiterleitet. In dem bestimmten Beispiel aus 4 umfasst die Ausführung des Benutzercodes die Schaffung und Speicherung eines Differentials in Amazon S3. Wie dargestellt können durch die API 602 PUT-Aufrufe für eine Objekt-Version1 und Objekt-Version2 ausgegeben werden. Wenn die Objektversionierungsfunktionalität aktiviert wird, wird die Objekt-Version2 in Bezug auf Objekt-Version1 komprimiert, um Objekt-Version2Diff zu bilden, und in der Backend-Objektspeichervorrichtung gespeichert. Auf diese Weise wird weniger Platz in der Backend-Speichervorrichtung 606 verbraucht als erforderlich wäre, wenn die vollständige Objekt-Version2 gespeichert würde. Weitere Details zu diesen und anderen beispielhaften Prozessen werden in Verbindung mit 5 erläutert.
Beispielhafte Objektversionierungsverfahren
Unter Bezugnahme auf 5 können Ausführungsformen der Erfindung besonders gut für die Implementierung von Objekt-PUT-Operationen auf effiziente und effektive Weise geeignet sein, vor allem, wenn solche Operationen in Verbindung mit Objektversionen ausgeführt werden. 5 offenbart Aspekte von Verfahren für PUT-Operationen für Objektversionen, wobei ein beispielhaftes Verfahren allgemein mit 700 bezeichnet ist. Ein Teil des oder das gesamte Verfahren(s) 700 kann, z. B. durch ein FaaS-Modul, an einem Cloud-Datenzentrum oder einem beliebigen anderen Speicherort ausgeführt werden, der Dienste für PUT/GET/DELETE-Aufrufe anbietet. Die Bereitstellung von Hardware und/oder Software, die für die Ausführung von Verfahren 700 erforderlich sind, kann ebenfalls im Cloud-Datenzentrum und/oder an anderen Orten, die vom Benutzerstandort entfernt sind, stattfinden und als solches kann das Verfahren 700 als eine serverlose Implementierung eines Objektionierunsversionsierungsverfahrens darstellend bezeichnet werden.
Wenn eine neue Version eines Objekts eingefügt wird, wird im Allgemeinen die vorherige Version des Objekts oder die erste nichtdifferentielle Version des Objekts vom Backend-Objektspeicher abgerufen und die neue Version wird dann im Vergleich zur vorherigen Version differentiell komprimiert. Wenn die differentielle Kompression signifikant besser als eine reguläre Kompression ist, beispielsweise „X“ mehr MB Speicherplatz spart, wird die Funktion, welch die nächste Version des Objekts einfügt, nur die differentielle und nicht die gesamte neue Version des Objekts speichern. Wenn der Backend-Objektdienst Versionierung unterstützt, kann die differentielle als neue Version des Objekts eingegeben werden. Wenn keine Versionierung vom Backend-Objektdienst unterstützt wird, können Metadaten-Informationen als Teil des Namens des Objekts gespeichert werden, als an das Objekt angehängte Metadaten oder in manchen Fällen in einer externen Datenbank.
In manchen Ausführungsformen kann der Kompressionsalgorithmus Dateitypen erkennen. Beispielsweise kann ein MS-Office-Dokument schon komprimiert sein, sodass eine differentielle Kompression des Objekts eventuell nicht vorteilhaft ist, sofern das Objekt nicht vorher dekomprimiert wird. In solch einem Fall kann das System zuerst die Objekte dekomprimieren und dann die differentiellen komprimieren.
Unter spezieller Bezugnahme auf das Beispiel aus 5 kann nun das Verfahren 700 beginnen, wenn ein Benutzer die Einfügung eines Objekts 702 in die Backend-Objektspeichervorrichtung anfragt, die sich beispielsweise in einem Datenzentrum befinden kann. Die Objekteinfügung kann beispielsweise von einer Client-Anwendung angefragt werden 702. In einigen bestimmten beispielhaften Ausführungsformen setzt der Benutzer eine PUT-Anfrage ein, um ein Objekt in einem Objektspeicher einzufügen oder zu insertieren. In solchen Ausführungsformen wird die PUT-Anfrage verwendet, um die Schaffung/Aktualisierung eines Objekts anzufordern, das von einem Dienst-URL identifiziert wurde, die in der PUT-Anfrage enthalten ist.
Die PUT-Anfrage führt wiederum automatisch zur Übertragung 704 eines Funktionsaufrufs, wie z. B. eines API-Gateway-Aufrufs, an das Datenzentrum. Am Datenzentrum aktiviert 706 der Funktionsaufruf dann automatisch die Funktion zur Speicherung des in der PUT-Anfrage identifizierten Objekts. Insbesondere veranlasst das Auslösen 706 der Funktion, dass das FaaS-Modul eine vorherige Version des Objekts, dessen Insertion angefordert wurde, oder die erste nichtdifferentielle Version dieses Objekts vom Backend-Objektspeicher abruft.
Nachdem die vorherige Version oder die erste nichtdifferentielle Version abgerufen wurde 708, kann die neue Version des Objekts in Bezug auf die vorherige Version differentiell komprimiert werden 710. D. h. nur die Unterschiede, d. h. das Differential, zwischen den beiden Objekten wird gespeichert 712. Das Differential kann in den Backend-Objektspeicher als neue Version des Objekts eingefügt werden. Da die Unterschiede in manchen Fällen oder vielen Fällen relativ gering sein können, kann die differentielle Kompression zu signifikanten Platzeinsparungen im Backend-Objektspeicher führen.
Wenn die differentielle Kompression 710 wenig Wirkung zeigt oder erwartet wird, dass sie wenig Wirkung zeigt, d. h. wenn die die Unterschiede zwischen den beiden Objektversionen erheblich sind oder eine vorbestimmte Schwelle überschreiten, kann die zweite Version in ihrer Gesamtheit gespeichert werden. Wie an anderer Stelle hierin angeführt, können, wenn der Backend-Objektspeicher keine Versionierung, d. h. kein Speichern einer differentiellen Version, unterstützt, verschiedene andere Ansätze verwendet werden, um die neue Version des Objekts zu speichern und zu berücksichtigen, z. B. durch Anhängen von Metadaten an die vorherige Version des Objekts, das im Objektspeicher gespeichert ist, welche die Unterschiede zwischen der vorherigen Version und der neuen Version angeben.
Wenn der Kompressionsalgorithmus Dateitypen erkennt, kann der Prozess 710 das Dekomprimieren der gespeicherten Version des Objekts und dann das Durchführen einer differentiellen Kompression der neueren Version des Objekts in Bezug auf die vorherige Version des Objekts umfassen. Wenn die differentielle Kompression wenig Wirkung zeigt, kann die neue Version des Objekts komprimiert und dann gespeichert werden.
Nachdem die differentielle oder ganze neue Version gespeichert wurde 712, kann das Verfahren 700 dann enden 714. Nachfolgende Objektinsertionsanfragen 702 können dann das Verfahren 700 neu starten. So werden die Funktionsaufrufe nur nach Bedarf gemacht, was die Kosten für den Benutzer verringern kann. Da differentielle Versionen erzeugt und gespeichert werden können, kann auch der Speicherplatz im Backend-Objektspeicher, der von einem jeweiligen Benutzer verbraucht wird, in Bezug auf den Speicherplatz, der erforderlich wäre, wenn vollständige Objektversionen gespeichert würden, verringert werden. Darüber hinaus muss, da das Verfahren 700 auf serverlose Weise ausgeführt werden kann, der Benutzer keine Bereitstellung oder Wartung von Hardware und/oder Software vornehmen, die zur Ausführung der Funktionsaufrufe notwendig sind.
Um eine Situation zu vermeiden, bei der zu viele abhängige Kopien vorhanden sind, kann das System eine vollständige Kopie des Objekts für jede „n.‟ Version des Objekts einfügen. Beispielsweise umfasst jede 10. Version eines Objekts eine vollständige Kopie dieser Version. Es kann jedoch jeder beliebige andere Ansatz zum Aussondern von abhängigen Kopien alternativ eingesetzt werden.
Wie an anderer Stelle angemerkt umfassen Ausführungsformen der Erfindung auch Ausleseprozesse. In diesem Zusammenhang wird auf 6 Bezug genommen, die Aspekte von Verfahren für GET-Operationen für Objektversionen offenbart, wobei ein beispielhaftes Verfahren allgemein mit 800 bezeichnet ist. Ein Teil des oder das gesamte Verfahren(s) 800 kann beispielsweise von einem FaaS-Modul in einem Cloud-Datenzentrum oder an einem beliebigen anderen Speicherort ausgeführt werden, der Dienste für PUT/GET/DELETE-Aufrufe anbietet. Die Bereitstellung von Hardware und/oder Software, die für die Ausführung des Verfahrens 800 notwendig sind, kann ebenfalls im Cloud-Datenzentrum und/oder an anderen Orten, die vom Benutzerstandort entfernt sind, erfolgen, sodass das Verfahren 800 als eine serverlose Implementierung eines Objektionierungsausleseprozesses darstellend bezeichnet werden kann. Im Allgemeinen wird, wenn eine Objektversion ausgelesen wird, eine Lesefunktion das Objekt aus dem Backend-Speicher auslesen. Wenn das Objekt ein Differential ist, wird auch die vorherige vollständige Kopie des Objekts abgerufen und das Objekt wird wiederaufgebaut.
Unter spezieller Bezugnahme auf das Beispiel von 6 kann das Verfahren 800 nun beginnen, wenn ein Benutzer eine Auslesung eines Objekts 802 in einer Backend-Objektspeichervorrichtung anfragt, die sich beispielsweise in einem Datenzentrum befinden kann. Die Objektauslesung kann beispielsweise von einer Client-Anwendung angefragt werden 802. In einigen bestimmten beispielhaften Ausführungsformen setzt der Benutzer eine GET-Anfrage ein, um ein Objekt von der Backend-Objektspeichervorrichtung auszulesen. In solchen Ausführungsformen wird die GET-Anfrage verwendet, um das Abrufen eines Objekts anzufordern, das von einer Dienst-URL identifiziert wurde, die in der GET-Anfrage enthalten ist.
Die GET-Anfrage bewirkt wiederum automatisch die Übertragung 804 eines Funktionsaufrufs, wie z. B. eines API-Gateway-Aufrufs, an das Datenzentrum. Am Datenzentrum aktiviert der Funktionsaufruf dann automatisch 806 die Funktion des Auslesens des in der GET-Anfrage identifizierten Objekts. Genauer gesagt bewirkt das Aufrufen 806 der Funktion, dass das FaaS-Modul das in der Auseleseanfrage identifizierte Objekt von der Backend-Objektspeichervorrichtung abruft 808. Wenn die vom Benutzer angeforderte Version ein Differential ist, wird die vorherige vollständige Kopie des Objekts ebenfalls zusammen mit den Differentialen abgerufen, die nach der vorherigen vollständigen Kopie erzeugt wurden. Wenn es beispielsweise drei Versionen gibt, wobei eine vollständig und die anderen differentiell sind, werden die letzte vollständige Version und alle Differentiale, die nach der letzten vollständigen Version erzeugt wurden, abgerufen und das Objekt wird wiederaufgebaut 810. Somit kann in Ausführungsformen, in denen keine differentielle Version abgerufen wird, der Prozess 810 weggelassen werden.
Egal ob nur eine vorherige vollständige Kopie des Objekts abgerufen wird oder ein Objekt mit einer differentiellen und vorherigen vollständigen Kopie wiederaufgebaut wird, die vollständige Kopie oder das wiederaufgebaute Objekt, je nach Fall, wird dann zum Client zurückgeschickt 812 und vom Client empfangen 814. Der Prozess 800 kann dann enden 816.
Unter Bezugnahme auf 7 werden schließlich Details bezüglich Aspekten von Verfahren für DELETE-Operationen für Objektversionen bereitgestellt, wobei ein beispielhaftes Verfahren allgemein mit 900 bezeichnet ist. Ein Teil des oder das gesamte Verfahren(s) 900 kann z. B. durch ein FaaS-Modul in einem Cloud-Datenzentrum oder an einem beliebigen anderen Speicherort ausgeführt werden, der Dienste für PUT/GET/DELETE-Aufrufe anbietet. Die Bereitstellung von Hardware und/oder Software, die für die Ausführung des Verfahrens 900 notwendig sind, können ebenfalls im Cloud-Datenzentrum und/oder an anderen Orten, die vom Benutzerstandort entfernt sind, erfolgen, und somit kann das Verfahren 800 als eine serverlose Implementierung eines Objektionierungsausleseprozesses darstellend bezeichnet werden.
Wenn eine Objektversion gelöscht wird, wird im Allgemeinen eine Überprüfung durchgeführt, um zu bestimmen, ob das Objekt ein Basisobjekt für ein anderes Objekt ist. In solch einem Fall kann das Objekt als gelöscht markiert werden, indem beispielsweise Metadaten zum Objekt hinzugefügt werden oder das Objekt umbenannt wird. Sobald alle abhängigen Kopien eines Objekts gelöscht sind, kann das Objekt selbst auch gelöscht werden. Um eine Situation zu vermeiden, in der zu viele abhängige Kopien vorhanden sind, kann das System eine vollständige Kopie des Objekts für jede „n.‟ Version des Objekts hinterlegen. Beispielsweise umfasst jede 10. Version eines Objekts eine vollständige Kopie dieser Version.
Unter spezieller Bezugnahme auf 7 kann nun das Verfahren 900 beginnen, wenn ein Benutzer eine Löschung eines Objekts 902 aus der Backend-Objektspeichervorrichtung anfragt, die sich beispielsweise in einem Datenzentrum befinden kann. Die Objektlöschung kann beispielsweise von einer Client-Anwendung angefragt werden 902. In einigen bestimmten beispielhaften Ausführungsformen setzt der Benutzer eine DELETE-Anfrage ein, um ein Objekt aus der Backend-Objektspeichervorrichtung zu löschen. In solchen Ausführungsformen wird die DELETE-Anfrage verwendet, um die Löschung eines Objekts zu beantragen, das von einer Dienst-URL identifiziert wurde, die in der DELETE-Anfrage enthalten ist.
Die DELETE-Anfrage bewirkt wiederum automatisch eine Übertragung 904 eines Funktionsaufrufs, wie z. B. eines API-Gateway-Aufrufs, an das Datenzentrum. Am Datenzentrum bewirkt 906 der Funktionsaufruf dann automatisch die Funktion zur Löschung des in der DELETE-Anfrage identifizierten Objekts. Insbesondere bewirkt die Auslösung 906 der Funktion, dass das FaaS-Modul überprüft 908, ob das Objekt, dessen Löschung aus der Backend-Objektspeichervorrichtung angefragt wurde, ein Basisobjekt für ein anderes Objekt ist. Wenn bestimmt wird 908, dass das Objekt, dessen Löschung angefragt wird, kein Basisobjekt ist, dann wird das Objekt aus der Backend-Objektspeichervorrichtung gelöscht 910 und der Prozess 900 endet 912.
Wenn andererseits bestimmt wird 908, dass das Objekt, dessen Löschung angefragt wird, ein Basisobjekt für eine oder mehrere differentielle Versionen ist, kann das Objekt als gelöscht markiert werden 914 und die entsprechende differentielle Version kann gelöscht werden. Solche Markierungen 914 können auf jede beliebige geeignete Weise erfolgen. Beispielsweise kann das Objekt durch Hinzufügen von Metadaten zum Objekt markiert werden 914, die angeben, dass es ein Basisobjekt ist, oder durch Umbenennen des Objekts auf eine Weise, die angibt, dass es sich um ein Basisobjekt handelt. An diesem Punkt kann das Verfahren 900 beispielsweise zu 906 zurückkehren und auf einen weiteren Aufruf der Funktion warten. Dies kann wiederholt werden, bis alle abhängigen Kopien eines Objekts gelöscht sind, an welchem Punkt das Objekt selbst ebenfalls gelöscht werden kann 910.
Es gilt anzumerken, dass solche Verfahren in Bezug auf die beispielhaften Verfahren der 5, 6 und 7 in der in diesen Figuren angegebenen Reihenfolge ausgeführt werden können, obwohl das nicht unbedingt erforderlich ist. In andern Ausführungsformen kann die Reihenfolge der Ausführung eines oder mehrerer Prozesse beliebiger der Verfahren geändert werden. Außerdem müssen nicht unbedingt alle Prozesse der Verfahren ausgeführt werden. In manchen Ausführungsformen kann der Prozess 810 beispielsweise weggelassen werden.
Beispielhafte Rechenvorrichtungen und assoziierte Medien
Die hierin offenbarten Ausführungsformen können die Verwendung eines Computers für spezielle Zwecke oder für allgemeine Zwecke umfassen, der verschiedene Computer-Hardware- oder -Software-Module umfasst, wie sie nachstehend genauer erläutert werden. Ein Computer kann einen Prozessor und ein Computerspeichermedium umfassen, das Anweisungen enthält, die eines oder mehrere der hierin offenbaren Verfahren durchführen, wenn sie durch den Prozessor ausgeführt werden und/oder ihre Ausführung vom Prozessor bewirkt wird.
Wie oben angeführt umfassen Ausführungsformen innerhalb des Schutzumfangs der vorliegenden Erfindung auch Computerspeichermedien, bei denen es sich um physische Medien handelt und die computerausführbare Anweisungen oder Datenstrukturen tragen oder darauf gespeichert haben. Solche Computerspeichermedien können beliebige verfügbare physische Medien umfassen, auf die ein Computer für allgemeine Zwecke oder spezielle Zwecke zugreifen kann.
Als Beispiel und nicht als Einschränkung können solche Computerspeichermedien Hardwarespeicher, wie z. B. Festkörperplatten/ -vorrichtungen (SSD), RAM, ROM, EEPROM, CD-ROM, Flash-Arbeitsspeicher, Phasenänderungsarbeitsspeicher („PCM“) oder andere optische Plattenspeicher, magnetische Plattenspeicher oder andere magnetische Speichervorrichtungen oder beliebige andere Hardware-Speichervorrichtungen sein, die verwendet werden können, um einen Programmcode in Form von computerausführbaren Anweisungen oder Datenstrukturen zu speichern, auf die ein Computersystem für allgemeine Zwecke oder spezielle Zwecke zugreifen kann und die diese ausführen können, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen des Obigen sollten ebenfalls innerhalb des Umfangs von Computerspeichermedien eingeschlossen sein. Solche Medien sind ebenfalls Beispiele für nichttransitorische Speichermedien, und nichttransitorische Speichermedien schließen auch Cloudbasierte Speichersysteme und -strukturen ein, obwohl der Schutzumfang der Erfindung nicht auf diese Beispiele für nichttransitorische Speichermedien eingeschränkt ist.
Computerausführbare Anweisungen umfassen beispielsweise Anweisungen und Daten, die bewirken, dass ein Computer für allgemeine Zwecke, ein Computer für spezielle Zwecke oder eine Verarbeitungsvorrichtung für spezielle Zwecke eine bestimmte Funktion oder Gruppe von Funktionen ausführt. Obwohl der Gegenstand in einer für Strukturmerkmale und/oder methodologische Vorgänge spezifischen Sprache beschrieben wurde, versteht sich, dass der in den beiliegenden Ansprüchen definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Vorgänge eingeschränkt ist. Die hierin offenbarten spezifischen Merkmale und Vorgänge werden vielmehr als beispielhafte Implementierungsformen der Ansprüche offenbart.
Wie hierin verwendet kann sich die Bezeichnung „Modul‟ oder „Komponente‟ auf Softwareobjekte oder Routinen beziehen, die auf dem Rechensystem ausgeführt werden. Die verschiedenen hierin beschriebenen Komponenten, Module, Engines und Dienste können als Objekte oder Prozesse implementiert werden, die auf dem Rechensystem ausgeführt werden, beispielsweise als separate Threads. Während das System und die Verfahren wie hierin beschrieben in Software implementiert werden können, sind auch Implementierungen in Hardware oder ein Kombination aus Software und Hardware möglich und vorgesehen. In der vorliegenden Offenbarung kann eine „Recheneinheit‟ ein beliebiges Rechensystem, wie es zuvor hierin definiert wurde, oder ein beliebiges Modul oder eine beliebige Kombination von Modulen sein, die auf einem Rechensystem laufen.
Zumindest in einigen Fällen wird ein Hardware-Prozessor bereitgestellt, der betreibbar ist, um Anweisungen zur Ausführung eines Verfahrens oder Prozesses, z. B. der hierin offenbarten Verfahren und Prozesse, auszuführen. Der Hardware-Prozessor kann ein anderes Hardware-Element umfassen, z. B. die Rechenvorrichtungen und Systeme wie hierin beschrieben.
In Bezug auf Rechenumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, egal ob Netzwerk- oder lokale Umgebungen, oder in jeder beliebigen anderen geeigneten Umgebung ausgeführt werden. Geeignete Betriebsumgebungen für zumindest einige Ausführungsformen der Erfindung umfassen Cloud-Rechenumgebungen, wo eines oder mehrere aus einem Client, einem Server oder einer anderen Maschine in einer Cloud-Umgebung vorhanden sein und arbeiten kann.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihrem Geist oder ihren wesentlichen Eigenschaften abzuweichen. Die beschriebenen Ausführungsformen sind in allen Belangen lediglich als veranschaulichend und nicht als einschränkend zu erachten. Der Schutzumfang der Erfindung ist daher durch die beiliegenden Ansprüche gegeben und nicht durch die vorstehende Beschreibung. Alle Änderungen, die innerhalb der Bedeutung und des Äquivalenzbereichs der Ansprüche sind, sollen innerhalb ihres Schutzumfangs liegen.

Claims

Verfahren, umfassend: Implementieren einer Funktion als Dienst (FaaS) in einem Datenzentrum durch Ausführen von Operationen, umfassend: Empfangen eines Anwendungsprogrammschnittstellen(API)-Gateway-Aufrufs von einer Client-Anwendung, wobei der API-Gateway-Aufruf mit einer Objekt-PUT-Anfrage assoziiert ist; und automatisches Auslösen, mit dem API-Gateway-Aufruf, der Durchführung einer Objektinsertionsfunktion, die umfasst: Abrufen einer vorherigen Version des Objekts von einer Backend-Objektspeichervorrichtung; differentielles Komprimieren des Objekts in Bezug auf die vorherige Version des Objekts, um ein Differential zu erzeugen; und Speichern des Differentials in der Backend-Objektspeichervorrichtung.
Verfahren nach Anspruch 1, weiters Empfangen eines API-Gateway-Aufrufs, der mit einer Objekt-GET-Anfrage assoziiert ist, und automatisches Auslösen, mit dem mit der Objekt-GET-Anfrage assoziierten API-Gateway-Aufruf, der Durchführung einer Objektauslesefunktion umfassend, die umfasst: Abrufen einer in der GET-Anfrage identifizierten Objektversion von der Backend-Objektspeichervorrichtung und, wenn die Objektversion ein Differential ist, ebenfalls Abrufen einer vorherigen vollständigen Kopie der Objektversion und jeglicher Differentiale, die nach der Erzeugung der vorherigen vollständigen Kopie erzeugt wurden, von der Backend-Objektspeichervorrichtung; wenn die Objektversion en Differential ist, Wiederaufbauen der Objektversion unter Verwendung der vorherigen vollständigen Kopie und jeglicher Differentiale; und Rückführen der Objektversion.
Verfahren nach Anspruch 1, wobei das Differential kleiner ist als das Objekt und die vorherige Version des Objekts.
Verfahren nach Anspruch 1, wobei, wenn die Größe des Differentials eine definierte Schwelle überschreitet, das Differential nicht gespeichert wird.
Verfahren nach Anspruch 1, außerdem Dekomprimieren des Objekts vor dem differentiellen Komprimieren des Objekts umfassend.
Verfahren nach Anspruch 6, wobei das Objekt eine Datei ist.
Verfahren nach Anspruch 1, außerdem Empfangen eines API-Gateway-Aufrufs, der mit einer Objekt-DELETE-Anfrage assoziiert ist, und automatisches Auslösen, mit dem mit der Objekt-DELETE-Anfrage assoziierten API-Gateway-Aufruf, der Durchführung einer Objektlöschungsfunktion umfassend, die umfasst: wenn eine in der DELETE-Anfrage identifizierte Objektversion kein Basisobjekt ist, Löschen der in der DELETE-Anfrage identifizierten Objektversion aus der Backend-Objektspeichervorrichtung; wenn die Objektversion ein Basisobjekt ist, von dem eine oder mehrere differentielle Objektversions abhängen, markieren der Objektversion als gelöscht und Löschen einer entsprechenden differentiellen Objektversion; und wenn alle abhängigen Kopien des Basisobjekts gelöscht sind, Löschen des Basisobjekts.
Verfahren nach Anspruch 1, wobei die Operationen außerdem Weiterleiten des API-Gateway-Aufrufs an die Backend-Objektspeichervorrichtung umfassen.
Verfahren nach Anspruch 1, außerdem Bereitstellen eines oder mehrerer aus dem Abrufprozess, differentiellen Komprimierungsprozess und differentiellen Speicherprozess umfassend.
Nichttransitorisches Speichermedium, in dem computerausführbare Anweisungen gespeichert sind, die bei Ausführung durch einen oder mehrere Hardware-Prozessoren Folgendes ausführen: Implementieren einer Funktion als Dienst (FaaS) in einem Datenzentrum durch Ausführen von Operationen, umfassend: Empfangen eines Anwendungsprogrammschnittstellen(API)-Gateway-Aufrufs von einer Client-Anwendung, wobei der API-Gateway-Aufruf mit einer Objekt-PUT-Anfrage assoziiert ist; und automatisches Auslösen, mit dem API-Gateway-Aufruf, der Durchführung einer Objektinsertionsfunktion, die umfasst: Abrufen einer vorherigen Version des Objekts von einer Backend-Objektspeichervorrichtung; differentielles Komprimieren des Objekts in Bezug auf die vorherige Version des Objekts, um ein Differential zu erzeugen; und Speichern des Differentials in der Backend-Objektspeichervorrichtung.
Nichttransitorisches Speichermedium nach Anspruch 10, wobei die Operationen außerdem Empfangen eines API-Gateway-Aufrufs, der mit einer Objekt-GET-Anfrage assoziiert ist, und automatisches Auslösen, mit dem mit der Objekt-GET-Anfrage assoziierten API-Gateway-Aufruf, der Durchführung einer Objektauslesefunktion umfasst, die umfasst: Abrufen einer in der GET-Anfrage identifizierten Objektversion von der Backend-Objektspeichervorrichtung und, wenn die Objektversion ein Differential ist, ebenfalls Abrufen einer vorherigen vollständigen Kopie der Objektversion und jeglicher Differentiale, die nach der Erzeugung der vorherigen vollständigen Kopie erzeugt wurden, von der Backend-Objektspeichervorrichtung; wenn die Objektversion ein Differential ist, Wiederaufbauen der Objektversion unter Verwendung der vorherigen vollständigen Kopie und jeglicher Differentiale; und Rückführen der Objektversion.
Nichttransitorisches Speichermedium nach Anspruch 10, wobei das Differential kleiner ist als das Objekt und die vorherige Version des Objekts.
Nichttransitorisches Speichermedium nach Anspruch 10, wobei, wenn die Größe des Differentials eine definierte Schwelle überschreitet, das Differential nicht gespeichert wird.
Nichttransitorisches Speichermedium nach Anspruch 1, wobei die Operationen außerdem Dekomprimieren des Objekts vor dem differentiellen Komprimieren des Objekts umfassen.
Nichttransitorisches Speichermedium nach Anspruch 14, wobei das Objekt eine Datei ist.
Nichttransitorisches Speichermedium nach Anspruch 10, wobei die Operationen außerdem Abrufen eines mit einer Objekt-DELETE-Anfrage assoziierten API-Gateway-Aufrufs und automatisches Auslösen, mit dem mit der Objekt-DELETE-Anfrage assoziierten API-Gateway-Aufruf, der Durchführung einer Objektelöschungsfunktion umfassen, die umfasst: wenn eine in der DELETE-Anfrage identifizierte Objektversion kein Basisobjekt ist, Löschen der in der DELETE-Anfrage identifizierten Objektversion aus der Backend-Objektspeichervorrichtung; wenn die Objektversion ein Basisobjekt ist, von dem eine oder mehrere differentielle Objektversions abhängen, Markieren der Objektversion als gelöscht und Löschen einer entsprechenden differentiellen Objektversion; und wenn alle abhängigen Kopien des Basisobjekts gelöscht sind, Löschen des Basisobjekts.
Nichttransitorisches Speichermedium nach Anspruch 1, wobei die Operationen außerdem Weiterleiten des API-Gateway-Aufrufs an die Backend-Objektspeichervorrichtung umfassen.
Nichttransitorisches Speichermedium nach Anspruch 10, wobei die Operationen außerdem Bereitstellen eines oder mehrerer aus dem Abrufprozess, differentiellen Komprimierungsprozess und differentiellen Speicherprozess umfassen.
Nichttransitorisches Speichermedium nach Anspruch 18, wobei der API-Gateway-Aufruf durch Einfügen des Objekts in einen Objektspeicher ausgelöst wird.
Physisches Rechensystem, umfassend: einen oder mehreren Hardware-Prozessoren; und ein nichttransitorisches Speichermedium nach Anspruch 10.