DE102020120553A1 - Virtuell persistente volumes für containerisierte anwendungen - Google Patents

Virtuell persistente volumes für containerisierte anwendungen Download PDF

Info

Publication number
DE102020120553A1
DE102020120553A1 DE102020120553.8A DE102020120553A DE102020120553A1 DE 102020120553 A1 DE102020120553 A1 DE 102020120553A1 DE 102020120553 A DE102020120553 A DE 102020120553A DE 102020120553 A1 DE102020120553 A1 DE 102020120553A1
Authority
DE
Germany
Prior art keywords
storage
virtual
containerized
data
mount point
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020120553.8A
Other languages
English (en)
Inventor
Bradley Cain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102020120553A1 publication Critical patent/DE102020120553A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G06F3/0641—De-duplication techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1461—Backup scheduling policy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1466—Management of the backup or restore process to make the backup process non-disruptive
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0664—Virtualisation aspects at device level, e.g. emulation of a storage device or system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Beispielimplementierungen beziehen sich auf virtuelle persistente Volumes für containerisierte Anwendungen. In einem Beispiel werden mehrere verschiedene Speicher-Mounts aus einer Mischung von Speichertypen erworben. Ein containerisiertes Speichervirtualisierungssystem erstellt und verwaltet ein virtuelles persistentes Volume, das die erworbenen Speicher-Mounts aggregiert. Ein Mount-Punkt des virtuellen persistenten Volumes wird der containerisierten Anwendung zur Verfügung gestellt. Das virtuelle persistente Volume enthält eine hierarchische Struktur, die Datenobjekte der containerisierten Anwendung durch inhaltsbasierte Signaturen mit einem Wurzelobjekt verbindet.

Description

  • HINTERGRUND
  • Container sind eine Art der Virtualisierung. Ein Container kann eine Anwendung zusammen mit Abhängigkeiten und Bibliotheken paketiert enthalten. Eine containerisierte Anwendung kann persistente Daten verwenden oder erzeugen.
  • Figurenliste
  • Im Folgenden werden verschiedene Beispiele anhand der folgenden Abbildungen beschrieben.
    • BILD 1 stellt ein Beispielsystem dar, das ein virtuelles persistentes Volume erstellt, das eine Vielzahl verschiedener zugrunde liegender Speicher aggregiert und einer containerisierten Anwendung präsentiert wird.
    • BILD 2 zeigt eine Beispielmethode, die die Erstellung eines virtuellen persistenten Volumens beinhaltet.
    • BILD 3 zeigt eine Beispielmethode, die die Ausführung eines Datendienstes mit einem virtuellen persistenten Volumen beinhaltet.
    • BILD 4. zeigt ein Beispielsystem mit einem maschinenlesbaren Medium, das Anweisungen zur Erstellung eines virtuellen persistenten Datenträgers enthält.
  • DETAILLIERTE BESCHREIBUNG
  • Die Containertechnologie ist ein Paradigma der Computervirtualisierung, bei dem eine Anwendung zusammen mit Abhängigkeiten und Bibliotheken in einen Container gepackt wird, um eine isolierte Umgebung für die Ausführung der Anwendung bereitzustellen. Eine solche Anwendung kann als containerisierte Anwendung bezeichnet werden. Viele Container können auf einem einzigen Betriebssystem laufen, aber jeder Container ist inhärent von anderen Containern isoliert. Auf diese Weise kann das Container-Paradigma als Virtualisierung des Betriebssystems verstanden werden. Container können leichter sein als andere Formen der Virtualisierung, wie z.B. virtuelle Maschinen, die Hardware virtualisieren. Beispielsweise kann jede virtuelle Maschine ihre eigene Kopie eines Betriebssystemkerns haben, während sich im Gegensatz dazu mehrere Container einen Betriebssystemkern teilen können.
  • Containerisierte Anwendungen benötigen möglicherweise Speicherplatz, um persistente Daten zu erhalten. Container-Orchestratoren können die Möglichkeit bieten, einen Teil des Speichers für einen Container bereitzustellen. Es gibt jedoch viele Arten von Speicher, einschließlich, aber nicht beschränkt auf Speicher, der lokal zum Container, entfernt zum Container, Hardware (z.B. ein lokal angeschlossenes Laufwerk), softwaredefiniert (z.B. ein Dateisystem, virtualisierter oder containerisierter Speicher, über eine API dargestellter Speicher usw.) oder Speicher mit einer Kombination der oben genannten Aspekte ist. Frühere Bemühungen um die Bereitstellung von Container-Speicherplatz bieten möglicherweise nicht den Grad an Flexibilität bei der Speicherkonfiguration und den Datendiensten, den Benutzer und Administratoren von Container-Umgebungen wünschen. Beispielsweise kann ein Container-Orchestrator auf die Bereitstellung eines einzigen Speichertyps für eine Anwendung beschränkt sein. Andere Systemtypen können versuchen, mehrere Datenträger zu einem einzigen Datenträger zu verketten, aber eine solche Verkettung bietet möglicherweise nicht die Flexibilität, bestimmte Datendienste ohne Unterbrechung des Benutzerzugriffs auf die Daten bereitzustellen.
  • Im Gegensatz dazu kann die Fähigkeit, eine beliebige Mischung beliebiger Speichertypen in einem virtuellen persistenten Volume in einer Containerumgebung bereitzustellen und dieses virtuelle persistente Volume in einer hochgradig virtualisierten Weise zu verwalten, Konfigurationsflexibilität und robuste, konsistente Datendienste ermöglichen, die Effizienzen und Vorteile für einen Containernutzer (einschließlich Administratoren) erschließen. Das virtuelle persistente Volume kann die zugrundeliegende Speichermischung von der Art und Weise entkoppeln, wie die Daten abstrahiert und einem Datenkonsumenten, z. B. einer containerisierten Anwendung, präsentiert werden. Infolgedessen können Datendienste wie Tiering, Migration, Snapshot-basierte Sicherung, Datensicherung usw. auf dem virtuellen persistenten Volume auf eine Art und Weise durchgeführt werden, die für eine containerisierte Anwendung, die das virtuelle persistente Volume verwendet, transparent und nicht störend ist, und sie können auch auf eine konsistente und vorhersehbare Art und Weise durchgeführt werden, unabhängig von der zugrunde liegenden Speichermischung, aus der das virtuelle persistente Volume besteht.
  • Um die oben genannten technischen Vorteile zu bieten, können sich die hier beschriebenen Beispiele auf ein containerisiertes Speichervirtualisierungssystem beziehen, das eine Speicheranforderung von einer containerisierten Anwendung empfängt, entsprechend der Anforderung eine Vielzahl unterschiedlicher Speicher-Mounts von lokalen und entfernten Speichertypen erwirbt, ein virtuelles persistentes Volume erstellt, das die Vielzahl unterschiedlicher Speicher-Mounts aggregiert (und somit die entsprechenden lokalen und entfernten Speicherzuweisungen aggregiert) und der containerisierten Anwendung einen Mount-Punkt des virtuellen persistenten Volumes zur Verfügung stellt. Das virtuelle persistente Volume kann in Form einer hierarchischen Struktur, wie z.B. einem Merkle-Baum, vorliegen, der Datenobjekte der containerisierten Anwendung durch ihre inhaltsbasierten Signaturen mit einem Wurzelobjekt verbindet. Das Wurzelobjekt kann das gesamte virtuelle persistente Volume repräsentieren. Außerdem kann der Mount-Punkt des virtuellen persistenten Volumes eine beliebige Art der Speicherzugriffsabstraktion sein, die vom containerisierten Speichervirtualisierungssystem verstanden wird, wie z. B. Datei-, Block- oder Schlüssel/Wertspeicher. Auf diese Weise kann aufgrund des Vorstehenden ein virtuelles persistentes Volume erstellt werden, das den zugrunde liegenden Speicher von der containerisierten Anwendung entkoppelt.
  • Unter Bezugnahme auf die Zahlen stellt BILD 1 ein Beispiel für ein Computersystem 100 dar, das eine Containerumgebung 120 unterstützt und daran teilnimmt. Das Rechensystem 100 umfasst eine Verarbeitungsressource 102, die einen Mikrocontroller, einen Mikroprozessor, Zentraleinheit(en), eine anwendungsspezifische integrierte Schaltung (ASIC), ein FPGA (Field Programmable Gate Array) usw. umfassen kann. Das Computersystem 100 enthält ein maschinenlesbares Medium 104, das nicht vorübergehend sein kann und einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), einen Flash-Speicher, ein Festplattenlaufwerk usw. enthalten kann.
  • Die Verarbeitungsressource 102 kann Anweisungen 105 (d.h. Programmier- oder Softwarecode) ausführen, die auf einem maschinenlesbaren Medium 104 gespeichert sind, um Funktionen des Computersystems 100 auszuführen, wie z.B. die Bereitstellung eines Container-Orchestrators 122 und eines containerisierten Speichersystems 130, wie weiter unten beschrieben wird. Insbesondere kann jede der Komponenten des containerisierten Speichervirtualisierungssystems 130 als ausführbare Anweisungen 105 implementiert werden, einschließlich des Datendienstanbieters 134, des Speichervirtualisierers 136, des Datenträgermanagers 138, der Adapter 139, der Policy Engine 142 und der Container-Speicherschnittstelle API 144. Containerisierte Anwendungen 124, 126 und Container-Speicherschnittstellen-Plug-ins 128 können auch als Anweisungen implementiert werden, die in den ausführbaren Anweisungen 105 enthalten sind. Zusätzlich oder alternativ kann die Verarbeitungsressource 102 elektronische Schaltungen zur Ausführung der hier beschriebenen Funktionalität enthalten.
  • Das Computersystem 100 kann auch andere Hardwarekomponenten enthalten, wie z.B. den physischen Speicher 106. Der physische Speicher 106 kann jedes physische Speichergerät, wie z.B. ein Festplattenlaufwerk, ein Festkörperlaufwerk oder ähnliches, oder eine Vielzahl solcher Speichergeräte (z.B. eine Anordnung von Platten) umfassen und kann lokal im Computersystem 100 angeschlossen (d.h. installiert) sein. In einigen Implementierungen kann auf den physischen Speicher 106 als Blockspeichergerät zugegriffen werden.
  • In einigen Fällen kann das Computersystem 100 auch ein lokales Dateisystem 108 enthalten, das als Schicht über dem physischen Speicher 106 implementiert werden kann. Beispielsweise kann ein Betriebssystem 107 auf dem Computersystem 100 ausgeführt werden (aufgrund der Verarbeitungsressource 102, die bestimmte Anweisungen 105 in Bezug auf das Betriebssystem ausführt), und das Betriebssystem 107 kann ein Dateisystem 108 bereitstellen, um Daten auf dem physischen Speicher 106 zu speichern.
  • Das Computersystem 100 kann mit anderen Computersystemen, wie z.B. dem Computersystem 110, über ein drahtgebundenes und/oder drahtloses Netzwerk kommunizieren. Die anderen Computersysteme können ähnlich wie das Computersystem 100 sein und können jeweils mindestens eine Verarbeitungsressource und ein maschinenlesbares Medium enthalten. Die Computersysteme 100 und 110 können jeweils Software ausführen (d.h. die Verarbeitungsressource 102 führt bestimmte Anweisungen 105 aus), um Knoten eines Container-Orchestrators 122 bereitzustellen. Mit anderen Worten, der Container-Orchestrator 122 kann eine Cluster-Architektur haben, die die Container-Orchestrator-Knoten von in einem Cluster zusammengeschlossenen Computersystemen umfasst. Der Container-Orchestrator 122 fungiert als Plattform für die Bereitstellung und Verwaltung containerisierter Anwendungen im gesamten Cluster von Computersystemen. Der Container-Orchestrator 122, davon entfaltete containerisierte Anwendungen und andere Container-Ressourcen (wie z.B. Container-Speicher) gelten als innerhalb einer Container-Umgebung 120. Im Gegensatz dazu können andere Elemente außerhalb der Container-Umgebung 120 funktionieren, wie z.B. das lokale Dateisystem 108 und ein Betriebssystem 107 des Computersystems 100.
  • Zur Veranschaulichung werden in BILD 1 die containerisierten Anwendungen 124 und 126 über den Container-Orchestrator 122 lokal auf dem Rechnersystem 100 eingesetzt. Man kann also sagen, dass die Anwendungen 124, 126 von anderen Knoten, wie z.B. dem Rechnersystem 110, entfernt sind. Die containerisierten Anwendungen 124, 126 können Mikrodienste, Benutzeranwendungen oder ähnliches darstellen. Die Containerumgebung 120 kann auch containerisierte Anwendungen (nicht abgebildet) lokal auf anderen Rechnersystemen im Cluster hosten.
  • Der Container-Orchestrator 122 setzt auch ein containerisiertes Speichervirtualisierungssystem 130 ein, das im Folgenden ausführlicher beschrieben wird. Im Beispiel von BILD 1 wird das containerisierte Speichervirtualisierungssystem 130 auch lokal auf dem Computersystem 100 und dessen Verarbeitungsressource 102 ausgeführt. In einigen Implementierungen sind auch andere containerisierte Speichervirtualisierungssysteme anderer Rechnersysteme im Cluster in der Containerumgebung 120 enthalten, obwohl sie in BILD 1 nicht dargestellt sind. Beispielsweise kann das containerisierte Speichervirtualisierungssystem 130 als Knoten in einer Speichervirtualisierungsplattform mit einer Cluster-Architektur dienen, bei der mehrere containerisierte Speichervirtualisierungssysteme (von denen zumindest einige auf verschiedenen und getrennten physischen Computersystemen ausgeführt werden können) zusammenarbeiten, um Daten in einer Speichervirtualisierungsschicht zu speichern und zu verwalten.
  • Der Container-Orchestrator 122 kann auch eine standardisierte Container-Speicherschnittstelle 123 enthalten. Die Container-Speicherschnittstelle 123 hat eine Plug-In-Architektur und kann Speicher in Form eines persistenten Volumes aus einer Speicherquelle unter Verwendung eines entsprechenden von mehreren verfügbaren Container-Speicherschnittstellen-Plug-Ins 128 bereitstellen. Die „Bereitstellung“ von Speicher kann sich auf den Prozess der Zuweisung einer bestimmten Menge an Speicherkapazität und die Bereitstellung dieser Zuweisung für einen Verbraucher beziehen. Plug-ins 128 können von verschiedenen Anbietern bereitgestellt werden und können ein zugeordnetes Speichersystem der Container-Speicherschnittstelle 123 aussetzen. Zu den nicht einschränkenden Beispielen für Plug-ins gehören ein Blockprotokoll-Plug-in (z.B. auf der Grundlage des Internet Small Computer Systems Interface oder des iSCSI-Protokolls), ein Dateiprotokoll-Plug-in (z.B. auf der Grundlage des Network File System oder des NFS-Protokolls, des Common Internet File System oder des CIFS-Protokolls, des Server Message Block oder des SMB-Protokolls), ein Public Cloud Persistent Volume Plug-in und andere Plug-ins, die auf einem anderen Speichertyp basieren (z.B. kundenspezifische Treiber). Der Einfachheit halber können einzelne der Plug-ins 128 hier als Plug-in 128 bezeichnet werden (z.B. ein Blockprotokoll-Plug-in 128 oder ein Dateiprotokoll-Plug-in 128). Ein Plug-in 128 kann einen Installations- und Einrichtungsprozess in der Container-Umgebung 120 durchlaufen, wie es für dieses Plug-in erforderlich ist (z.B. das Ausfüllen von Zugangsdaten oder andere Konfigurationsdetails). In einigen Fällen kann eines oder mehrere der Plug-Ins 128 als containerisierte Anwendung ausgeführt werden. Ein persistenter Datenträger, der über das Plug-in 128 bereitgestellt wird, kann jedoch auf einen einzigen Speichertyp beschränkt sein, der diesem Plug-in entspricht. Im Gegensatz dazu kann das hierin vorteilhaft offen gelegte containerisierte Speichervirtualisierungssystem 130 für die Erstellung persistenter Volumes nützlich sein, die mehrere zugrunde liegende Speichertypen vermischen.
  • Das containerisierte Speichervirtualisierungssystem 130 (auch als Speichervirtualisierungssystem 130 bezeichnet) läuft innerhalb eines oder mehrerer Container und kann in ausführbaren Anweisungen 105 implementiert werden. Wie sich zeigen wird, bietet das Speichervirtualisierungssystem 130 eine zusätzliche Speichervirtualisierungsschicht zwischen einer anfordernden Anwendung und einer oder mehreren Zuweisungen von Speicher, der über die Container-Speicherschnittstelle 123 bereitgestellt wird. Das Speichervirtualisierungssystem 130 umfasst einen Datenpfad 132 und eine Steuerungsebene 140. Der Datenpfad 132 umfasst den Datendienstanbieter 134, den Speichervirtualisierer 136 und einen Volume-Manager 138. Der Datenpfad 132 kann auch Speicheradapter 139 für den Zugriff auf lokalen Speicher (d.h. Speicher auf demselben Computersystem 100, auf dem das Speichervirtualisierungssystem 130 gehostet wird) enthalten, wie z.B. einen Blockadapter für die Montage des lokalen physischen Speichers 106, gestapelte Datei- und Blockadapter für den Zugriff auf das lokale Dateisystem 108 als Blockgerät oder andere Speicheradapter.
  • Die Steuerungsebene 140 umfasst eine Policy-Engine 142 und eine Container-Speicherschnittstelle API (Application Programming Interface) 144. Während einer Initialisierungsphase des Speichervirtualisierungssystems 130 kann die Steuerungsebene 140 von einem Administrator oder dem Container-Orchestrator 122 eine Liste der verfügbaren Container-Speicherschnittstellen-Plug-ins 128 in der Containerumgebung 120 erhalten. Die Steuerungsebene 140 kann auch die Speicheradapter 139 bestätigen, die für den Datenpfad 132 zur Montage des lokalen Speichers verfügbar sind. Die Steuerungsebene 140 kann auch eine Liste von Merkmalen des Speichers führen, die mit jedem dieser verfügbaren Plug-Ins 128 verknüpft sind, wie z.B. Leistungsmerkmale (z.B. Latenz, IOPS oder Input/Output-Operationen pro Sekunde usw.), Sicherheitsmerkmale (z.B. Verschlüsselung, Isolierung usw.), Datenschutzmerkmale (z.B. verfügbares RAID oder redundante Anordnung unabhängiger Platten, Ebenen), Kostenmerkmale (z.B. Dollar pro GB) oder andere Merkmale.
  • Die Funktionalität der Datenpfadfunktionen 132 und der Steuerungsebenenfunktionen 140 wird nun im Zusammenhang mit der Bereitstellung von Speicherplatz für containerisierte Anwendungen 124, 126 beschrieben. Eine containerisierte Anwendung, wie z.B. Anwendung 124, kann Speicher vom Container-Orchestrator 122 anfordern. Beispielsweise kann die Anwendung 124 ein persistentes Volume zur Speicherung von Daten benötigen. In einigen Implementierungen kann die Anwendung 124 eine oder mehrere Anforderungen mit der Anforderung übergeben, z. B. eine Kapazitätsanforderung, eine Leistungsanforderung (z. B. Latenz, IOPS usw.), eine Datenschutzanforderung (z. B. RAID-Level), eine Kostenanforderung (z. B. , Dollar pro GB), eine Sicherheitsanforderung, eine Tiering-Anforderung (z. B. bestimmte Mengen an Warm- und Kältespeicher) oder eine andere Anforderung. In einigen Implementierungen kann der Container-Orchestrator 122 als Reaktion auf die Anforderung eine Speicherabstraktion beibehalten, die als „Orchestrator Persistent Volume“ bezeichnet wird.
  • Der Container-Orchestrator 122 kann die Container-Speicherschnittstelle 123 verwenden, um die Anforderung über die Container-Speicherschnittstelle API 144 der Steuerungsebene 140 (wobei die Schnittstelle 144 als Server fungiert) an das Speichervirtualisierungssystem 130 zu senden. Auf diese Weise kann das containerisierte Speichervirtualisierungssystem 130 so verstanden werden, dass es als Speicheranbieter für den Container-Orchestrator 122 fungiert. In einigen Implementierungen kann die Steuerungsebene 140 der Anforderung eine Kennung zuweisen, so dass jede Anforderung einzeln identifiziert werden kann, insbesondere im Hinblick auf den Speicher, der für jede Anforderung in der hier beschriebenen Weise bereitgestellt wird.
  • Die Richtlinien-Engine 142 des Container-Orchestrators 122 analysiert die Anforderung, um festzustellen, welche Arten der Speicherung die Anforderungen der Anforderung erfüllen. Beispielsweise kann die Steuerungsebene 140 einen oder mehrere der folgenden Typen für die Speicherbereitstellung zur Verfügung haben: den physischen Speicher 106, das lokale Dateisystem 108, ein Remote-Speichersystem 160, einen virtualisierten Speicher 162 oder einen Public-Cloud-Speicher 164. Darüber hinaus kann mehr als einer der dargestellten Speichertypen vorhanden sein, werden aber aus Gründen der Übersichtlichkeit nicht dargestellt. Beispielsweise können mehrere Remote-Speicher 160 verfügbar sein, von denen aus Speicherzuweisungen bereitgestellt werden können.
  • Das entfernte Speichersystem 160, wie in dargestellt, kann entweder ein Dateisystem (z.B. ein an das Netzwerk angeschlossener Speicher oder NAS, Dateiserver), ein Blockspeichersystem (z.B. ein Speicherbereichsnetzwerk oder SAN, Speichergerät) oder jede andere Art von Speichersystem darstellen, das vom Computersystem 100 und damit vom containerisierten Speichervirtualisierungssystem 130 entfernt ist. Entfernt zu sein, kann zum Beispiel bedeuten, dass das Computersystem 100 mit dem entfernten Speichersystem 160 über eine Netzwerkverbindung oder ähnliches kommuniziert.
  • Der virtualisierte Speicher 162 kann ein beliebiges vorhandenes persistentes Volumen in einer virtuellen Umgebung darstellen, z. B. ein persistentes Volumen in der Containerumgebung 120 einschließlich des Container-Speichers, der über die Container-Speicherschnittstelle 123 unabhängig von dem Container-Speichervirtualisierungssystem 130 bereitgestellt wird. In einigen Beispielen kann der virtualisierte Speicher 162 einen Container-Speicher darstellen, der von einem anderen Container-Speichervirtualisierungssystem als System 130 bereitgestellt wird (z.B. gehostet auf einem anderen Knoten als das Computersystem 100). In einigen Beispielen kann der virtualisierte Speicher 162 Speicher darstellen, der von einer virtuellen Maschine oder einer Hypervisor-basierten, softwaredefinierten Speicherplattform bereitgestellt wird.
  • Das Policy-Engine 142 kann eine Mischung aus den oben genannten Speichertypen bestimmen. Beispielsweise kann das Richtlinien-Engine 142 die Anforderung mit den verfügbaren Speichertypen vergleichen, um eine möglichst große Übereinstimmung zu ermitteln. Zur Veranschaulichung: Die Anforderung kann eine bestimmte Menge an Hochgeschwindigkeitsspeicher und eine bestimmte Menge an kostengünstigem Archivierungsklassenspeicher erfordern. Die Richtlinien-Engine kann feststellen, dass der physische Speicher 106 die Hochgeschwindigkeits-Speicheranforderung erfüllt (z. B. zum Teil aufgrund der örtlichen Gegebenheiten und weil es sich in diesem Beispiel um ein Hochgeschwindigkeitsmedium handelt) und ein Blockspeichergerät 160 die Anforderungen der kostengünstigen Archivierungsklasse erfüllt.
  • Anschließend verwendet die Steuerungsebene 140 die Adapter 139 und/oder Container-Speicherschnittstellen-Plug-ins 128, um jeden Speichertyp in der festgelegten Mischung bereitzustellen und einen Montagepunkt für jeden bereitgestellten Speicher zu erfassen. Ein Mount-Punkt ermöglicht den Zugriff auf den bereitgestellten Speicher durch einen Verbraucher, z.B. den Datenpfad 132, wie im Folgenden beschrieben wird.
  • Als Beispiel für die lokale Bereitstellung kann die Steuerungsebene 140 einen Blockadapter von den Adaptern 139 verwenden, um eine Zuweisung aus dem physischen Speicher 106 bereitzustellen, und einen lokalen Block-Mountpunkt 170 (z. B. einen lokalen Host-Gerät-Mountpunkt) erwerben, um auf diese Zuweisung zuzugreifen. Als weiteres Beispiel kann die Steuerungsebene 140 gestapelte Datei- und Blockadapter verwenden, um eine Zuweisung aus dem lokalen Dateisystem 108 bereitzustellen und einen lokalen Dateisystem-Mountpunkt 172 zu erwerben, um auf diese Zuweisung als Blockgerät (d.h. „Datei als Blockgerät“) zuzugreifen.
  • Um Speicher über die Plug-Ins 128 bereitzustellen, kommuniziert die Steuerungsebene 140 über die Container-Speicherschnittstelle API 144 mit der Speicherschnittstelle 123, um anzufordern, dass ein Plug-In 128 eine Zuweisung aus seinem zugehörigen Speicher bereitstellt und einen Montagepunkt zurück zur Steuerungsebene 140 bereitstellt. Beispiel: Angenommen, das entfernte Speichersystem 160 stellt ein entferntes Blockgerät dar (z.B. ein SAN-Speicherarray außerhalb des Rechnersystems 100), so kann die Steuerungsebene 140 (über 144 und 123) anfordern, dass ein Blockprotokoll-Plug-in 128 (z.B. basierend auf dem iSCSI-Protokoll) eine Zuweisung von dem blockartigen entfernten Speichersystem 160 bereitstellt und einen entfernten Volume-Mountpunkt 174 (z.B. iSCSI-Ziel und LUN oder Logical Unit Number) bereitstellt, um auf diese Zuweisung zuzugreifen. Ein weiteres Beispiel: Das entfernte Speichersystem 160 kann ein entferntes Dateigerät (z.B. ein NAS-Dateiserver) darstellen, und die Steuerungsebene 140 kann (über 144 und 123) anfordern, dass ein Dateiprotokoll-Plug-in 128 (z.B. auf dem NFS-Protokoll basierend) eine Zuweisung vom entfernten Dateispeichersystem 160 bereitstellt und einen entfernten Volume-Mountpunkt 174 (z.B. eine IP-Adresse und einen Exportnamen unter NFS) für den Zugriff auf diese Zuweisung bereitstellt. In einigen Implementierungen kann die Steuerungsebene 140 anstelle eines Adapters 139 ein Blockprotokoll-Plug-in 128 für die Bereitstellung aus dem physischen Speicher 106 oder ein Dateiprotokoll-Plug-in 128 für die Bereitstellung aus dem lokalen Dateisystem 108 verwenden.
  • Ein weiteres Beispiel für die Bereitstellung über ein Plug-In: Die Steuerungsebene 140 kann (über 144 und 123) verlangen, dass ein Plug-In 128, das mit dem virtualisierten Speicher 162 übereinstimmt, eine Zuweisung aus dem virtualisierten Speicher 162 bereitstellt und einen virtualisierten Speicher-Mountpunkt 176 für den Zugriff auf diese Zuweisung bereitstellt. Als weiteres Beispiel kann die Steuerungsebene 140 (über 144 und 123) anfordern, dass ein Public-Cloud-Plug-in 128 eine Zuweisung aus dem Public-Cloud-Speicher 164 bereitstellt. Im Gegenzug kann das Public Cloud-Plug-in 128 einen Public Cloud Persistent Volume Mount Point 178 für den Zugriff auf diese Zuweisung bereitstellen.
  • Obwohl BILD 1 einen lokalen Block-Mountpunkt 170, einen lokalen Dateisystem-Mountpunkt 172, einen entfernten Volume-Mountpunkt 174, einen virtualisierten Speicher-Mountpunkt 176 und einen Public Cloud Persistent Volume-Mountpunkt 178 darstellt, können mehr oder weniger Mountpunkte und Mountpunkte jeder Kombination von der Steuerungsebene 140 angefordert und über die Adapter 139 oder Plug-ins 128 erworben werden. In verschiedenen Fällen können mehrere lokale Block-Mountpunkte 170, mehrere lokale Dateisystem-Mountpunkte 172, mehrere entfernte Volume-Mountpunkte 174, mehrere virtualisierte Speicher-Mountpunkte 176 und/oder mehrere persistente Public-Cloud-Volume-Mountpunkte 178 angefordert und von der Steuerungsebene 140 erfasst werden. Darüber hinaus können das Speichersystem 160 und der entfernte Mount-Punkt 174 jeweils eine oder mehrere der gleichen oder verschiedenen Arten von entferntem Speicher und einen Mount-Punkt davon darstellen, einschließlich Block-, Datei- oder anderer Arten von fernzugänglichem Speicher. Die bestimmte Kombination von Speichermontagepunkten, die von der Steuerebene 140 angefordert und erfasst werden, kann von der Speicheranforderung aus der containerisierten Anwendung 124 und insbesondere von der Handhabung dieser Speicheranforderung durch die Policy Engine 142 abhängen.
  • Sobald ein oder mehrere Speichermontagepunkte (z.B. 170, 172, 174, 176 oder 178) von der Steuerebene 140 in Übereinstimmung mit dem Policy-Engine 142 erfasst wurden, übergibt die Steuerebene 140 die erfassten Montagepunkte an den Datenpfad 132. Die Steuerebene 140 kann die Befestigungspunkte als einer bestimmten Anforderung zugeordnet identifizieren, indem sie die Befestigungspunkte z.B. der Anforderungskennung zuordnet. Wie im Folgenden beschrieben wird, konsumiert und mischt der Datenpfad 132 die Mount-Punkte, um ein virtuelles persistentes Volume 156 zu erzeugen, das von einem Mount-Punkt 180 an die anfordernde containerisierte Anwendung 124 übergeben wird. Auf diese Weise kann der zugewiesene Speicher, der den erworbenen Mount-Punkten (z.B. 170, 172, 174, 176 oder 178) entspricht, als der zugrunde liegende Speicher des virtuellen persistenten Volumes 156 bezeichnet werden. Die containerisierte Anwendung 124 liest und schreibt also Daten auf das virtuelle persistente Volume 156. Bevor die Erstellung des virtuellen persistenten Volumes 156 beschrieben wird, werden zunächst betriebliche Aspekte des Datenpfades 132 beschrieben.
  • Der Datenpfad 132 enthält Speichervirtualisierer 136, der eine objektbasierte Speichervirtualisierungsschicht 150 unterhält. Ein Zweck der Speichervirtualisierungsschicht 150 besteht darin, den Speicherort der Daten (d.h. die Speicherzuweisungen, auf die über die Mount-Punkte 170, 172, 174, 176 und/oder 178 zugegriffen wird) von der Art und Weise zu entkoppeln, wie die Daten einem Datenkonsumenten (z.B. einer containerisierten Anwendung 124) präsentiert werden. Auf diese Weise können Datendienste wie Migration, Backup, Snapshoting, Replikation, Deduplizierung, Komprimierung und andere auf jeder beliebigen Mischung des zugrundeliegenden Speichers und mit verringerter, minimaler oder gar keiner Unterbrechung für einen Verbraucher der Daten durchgeführt werden.
  • Ein Aspekt der Speichervirtualisierungsschicht 150 ist, dass der Speichervirtualisierer 136 Daten als „Objekte“ in einem Objektspeicher 152 speichert. Insbesondere kann der Objektspeicher 152 verschiedene Arten von Objekten speichern, darunter Datenobjekte und Metadatenobjekte. Daten, die sich auf die containerisierte Anwendung 124 beziehen, einschließlich Dateien und/oder Verzeichnisse, bestehen aus einem oder mehreren Datenobjekten. Metadatenobjekte können unter anderem nützlich sein, um die Datenobjekte in einer nützlichen und geordneten Weise zu organisieren, wie im Folgenden beschrieben wird. In einigen Implementierungen kann jedes Datenobjekt im Objektspeicher eine feste Datenmenge sein, z.B. 4 oder 8 Kibbyte Daten, und Metadatenobjekte können auch eine feste Datenmenge sein, z.B. 1 Kibbyte.
  • Eine objektbasierte Speichervirtualisierungsschicht 150 kann sich von Block-Level-Storage (z. B. implementiert in einem SAN und dargestellt über ein Speicherprotokoll wie iSCSI oder Fibre Channel) und File-Level-Storage (z. B. ein Dateisystem, das Daten in einer Dateihierarchie verwaltet und über ein File-Level-Protokoll wie NFS oder SMB/CIFS dargestellt wird) unterscheiden, obwohl die objektbasierte Speichervirtualisierungsschicht 150 Block- oder File-Level-Storage-Protokollen unterliegen kann (z. B. durch Abstraktion über Mount-Punkte 180, 182, wie beschrieben wird).
  • Der Speichervirtualisierer 136 verwaltet einen Objektindex 154, der für jedes Objekt (Datenobjekt und Metadatenobjekt) im Objektspeicher 152 eine Signatur, eine physische Adresse und einen Referenzzähler verfolgt. Die Signatur eines Objekts kann ein kryptografischer Digest des Inhalts dieses Objekts unter Verwendung einer Hash-Funktion wie SHA-1, SHA-256, MD5 usw. sein. Daher kann die Signatur auch als inhaltsbasierte Signatur bezeichnet werden. Der Referenzzähler im Objektindex 154 bezieht sich auf die Anzahl der Verweise auf das zugehörige Objekt über alle virtuellen persistenten Datenträger (einschließlich 156, 158) in der Speichervirtualisierungsschicht 150.
  • Die physische Adresse im Objektindex 154 bezieht sich auf den tatsächlichen physischen Standort des Objekts. In einigen Beispielen kann der Objektspeicher 152 zwar als ein Speicherkonstrukt zur Beschreibung der Speicherung von Objekten innerhalb der Speichervirtualisierungsschicht 150 verstanden werden, es kann aber auch so verstanden werden, dass die Objekte physisch auf dem darunter liegenden Speicher an der physischen Adresse gespeichert werden. Da der Datenpfad 132 mehrere Speicher-Mountpunkte beanspruchen kann, kann der jeweilige Mountpunkt ein Teil der physischen Adresse sein. Zusätzlich kann die physische Adresse einen Ort innerhalb der Speicherzuordnung eines bestimmten Mountpoints enthalten. Wenn sich der Mountpoint beispielsweise auf den physischen Speicher 106 bezieht, kann die physische Adresse eine logische Blocknummer enthalten. Wenn sich der Mount-Punkt auf den öffentlichen Cloud-Speicher 164 bezieht, kann die physische Adresse einen Verweis auf ein Cloud-Objekt in der Syntax des entsprechenden Hosting-Providers enthalten. Der Volume-Manager 138 ist so konfiguriert, dass er Daten an angegebenen physischen Adressen liest und schreibt, z. B. an die physischen Adressen, die im Objektindex 154 gespeichert sind.
  • In einigen Implementierungen kann das containerisierte Speichervirtualisierungssystem 130 eine zusätzliche Schicht der Indirektion zwischen dem Objektindex 154 und dem tatsächlichen physischen Standort von Objekten nutzen. In solchen Implementierungen kann der Volume-Manager 138 die zugrundeliegenden Speicherzuweisungen an jedem von der Steuerungsebene 140 bereitgestellten Einhängepunkt zuweisen und/oder in Ausdehnungen (oder auch als Mini-Volumes bezeichnet) unterteilen. Die zusätzliche Ebene der Indirektion kann implementiert werden, indem im Objektindex 154 in Verbindung mit einer Objektsignatur statt einer physischen Adresse eine virtuelle Adresse gespeichert wird und eine Extent-Tabelle gepflegt wird, die eine gegebene virtuelle Adresse einem Extent und damit dem entsprechenden zugrunde liegenden Speicher zuordnet. Um also auf ein Objekt auf der Grundlage einer virtuellen Adresse zuzugreifen, kann der Datenträgerverwalter 138 zunächst das von der virtuellen Adresse anvisierte Extent unter Verwendung der Extent-Tabelle und eines ersten Teils der virtuellen Adresse identifizieren und dann das Objekt innerhalb des Extents unter Verwendung eines zweiten Teils der virtuellen Adresse lokalisieren. Auf diese Weise können bestimmte Datendienste wie Migration und Tiering zwischen Extents auf effiziente Weise durchgeführt werden, indem nur die Extent-Identifikatoren in der Extent-Tabelle aktualisiert werden, anstatt eine große Menge an speicherinternen oder persistenten Verweisen auf die Datenobjekte (d.h. jede betroffene Adresse im Objektindex 154) zu aktualisieren und verschiedene logische Adressen, Indizes und andere Datenstrukturen, die bei der Verwaltung des Speichersystems verwendet werden, neu zu generieren.
  • Innerhalb der Speichervirtualisierungsschicht 150 unterhält der Speichervirtualisierer 136 ein oder mehrere virtuelle persistente Volumes (hier auch als virtuelle PVs bezeichnet), die durch den Objektspeicher 152 gesichert werden. In einigen Implementierungen wird eine containerisierte Anwendung mit einem virtuellen PV in einer Eins-zu-Eins-Beziehung verknüpft. In der Beispieldarstellung von ist z.B. die containerisierte Anwendung 124 mit dem virtuellen PV 156 und die containerisierte Anwendung 126 mit dem virtuellen PV 158 assoziiert. In einigen Implementierungen wird jedes virtuelle PV vom Container-Orchestrator 122 auf ein entsprechendes persistentes Orchestrator-Volume abgebildet, das vom Container-Orchestrator 122 verwaltet wird, und die anfordernde containerisierte Anwendung 124 greift über das persistente Orchestrator-Volume auf den Speicher des virtuellen PV 156 zu.
  • In anderen Fällen können containerisierte Anwendungen und virtuelle PVs in Eins-zu-Viele-, Mann-zu-Eins- oder Many-zu-Viele-Beziehungen verknüpft werden. Nur zur Veranschaulichung werden virtuelle PVs jetzt mit Bezug auf das virtuelle PV 156 beschrieben, obwohl es verstanden werden sollte, dass eine ähnliche Beschreibung auch für andere virtuelle PVs wie das virtuelle PV 158 und andere nicht gezeigte virtuelle PVs gelten kann.
  • In einer Implementierung kann der virtuelle persistente Datenträger 156 eine Organisation von Metadatenobjekten und Datenobjekten sein, die im Objektspeicher 152 gespeichert sind, wobei die Organisation die Datenobjekte durch zugehörige inhaltsbasierte Signaturen bis zu einem Wurzelobjekt hierarchisch in Beziehung setzt. In einem Beispiel kann das virtuelle PV 156 ein Merkle-Baum (auch als Hash-Baum bezeichnet) oder jede andere hierarchische Anordnung (z.B. gerichtete azyklische Graphen usw.) sein. Im Falle eines hierarchischen Merkle-Baums können sich Datenobjekte auf der untersten Baumebene eines jeden Zweiges befinden (auch als Blattebene bezeichnet, die am weitesten vom Wurzelobjekt entfernt ist), und solche Datenobjekte können als Blattdatenobjekte bezeichnet werden. Wie oben beschrieben, bilden Datenobjekte die Daten der containerisierten Anwendung 124, wie z.B. Dateien und Verzeichnisse.
  • Innerhalb der hierarchischen Anordnung bezieht sich ein übergeordnetes Objekt auf ein Objekt, das als Inhalt die Signaturen von untergeordneten Objekten enthält. Beispielsweise ist ein übergeordnetes Objekt von Datenobjekten auf Blattebene ein Metadatenobjekt, das als seinen Inhalt die Signaturen seiner untergeordneten Datenobjekte auf Blattebene speichert. Auf diese Weise werden die Signaturen von Objekten auf jeder Ebene in übergeordneten Objekten auf einer in der hierarchischen Anordnung nächsthöheren Ebene gesammelt, bis das Wurzelobjekt erreicht ist. Das Wurzelobjekt ist also ebenfalls ein Metadatenobjekt, das als Inhalt die Signaturen der jeweiligen untergeordneten Objekte speichert. Aus einer anderen Perspektive erweitert sich die hierarchische Anordnung in einer Richtung vom Wurzelobjekt zur Blattebene - ein Metadatenobjekt auf einer beliebigen Ebene kann sich auf eine Anzahl von Unterknoten ausdehnen, die durch einen vordefinierten Verzweigungsfaktor vorgegeben ist. Ein Metadatenobjekt kann unter Umständen eine Anzahl von Signaturen speichern, die mindestens einem Verzweigungsfaktor der hierarchischen Anordnung entspricht, so dass es die Signaturen aller untergeordneten Objekte enthalten kann.
  • Jede Änderung der Daten des virtuellen PV (d.h. neue Daten, geänderte Daten, gelöschte Daten) führt zu einer Änderung des Inhalts eines oder mehrerer Datenobjekte auf Blattebene, was eine Änderung der inhaltsbasierten Signaturen dieser geänderten Datenobjekte bewirkt, wodurch sich die Inhalts- und Signaturänderungen durch die übergeordneten Knoten nach oben zum Wurzelobjekt ausbreiten. Auf diese Weise kann ein virtuelles PV 156 zu einem bestimmten Zeitpunkt (auch als zeitliche Momentaufnahme bezeichnet) durch sein Wurzelobjekt und insbesondere durch seine Signatur des Wurzelobjekts eindeutig identifiziert werden.
  • Ein weiterer Aspekt des virtuellen PV 156 ist, dass in einigen Implementierungen eine bestimmte Datei oder ein Verzeichnis aus der containerisierten Anwendung 124 in einer entsprechenden Unterbaumanordnung innerhalb des virtuellen PV 156 gespeichert werden kann. Mit anderen Worten, das virtuelle PV 156 kann in Unterbäume unterteilt werden, von denen jeder einer entsprechenden Datei oder einem entsprechenden Verzeichnis der containerisierten Anwendung 124 entspricht.
  • Da Dateien und Verzeichnisse aus einem oder mehreren Datenobjekten bestehen und diese Datenobjekte im virtuellen PV 156 und dessen Unterbäumen durch Verweis auf zugehörige Datenobjektsignaturen angeordnet sind, kann in einigen Implementierungen jedes der Datenobjekte physikalisch nur einmal im Objektspeicher 152 gespeichert sein und durch ihre jeweiligen Signaturen in mehreren Metadatenobjekten im virtuellen PV 156 oder in jedem anderen virtuellen PV (z.B. 158) in der Speichervirtualisierungsschicht 150 referenziert werden. Somit können Daten auf diese Weise durch den Speichervirtualisierer 136 dedupliziert werden. Ebenso können Metadatenobjekte einmal gespeichert und durch entsprechende Signaturen mehrfach referenziert werden. Die Anzahl der Verweise auf ein Daten- oder Metadatenobjekt in der Speichervirtualisierungsschicht 150 kann in den entsprechenden Referenzzählern des Objektindex 154 aufgezeichnet werden. In einigen Implementierungen kann die Deduplizierung von Daten inline während eines Schreibvorgangs durchgeführt werden, im Gegensatz zur nachbearbeiteten oder Nearline-Deduplizierung, und auf diese Weise kann die Speicherung von Daten in der Speichervirtualisierungsschicht 150 und unter den virtuellen PVs 156, 158 als nativ dedupliziert bezeichnet werden.
  • In Anwendungsfällen, in denen Sicherheit eine Überlegung ist, einschließlich Multi-Tenancy-Szenarien, können für jede sensible Sicherheitsdomäne separate Objektspeicher verwendet werden. So können sensible Daten in einen gesicherten Objektspeicher isoliert werden, ohne an der Deduplizierung anderer virtueller PVs außerhalb der Sicherheitsdomäne teilzunehmen.
  • Damit die containerisierte Anwendung 124 auf das virtuelle PV 156 zugreifen kann, kann der Datenpfad 132 einen Mount-Point 180 bereitstellen. Der Datenpfad 132 kann jede Art von Mount-Punkt aus einer Vielzahl von Typen von Mount-Punkten bereitstellen, einschließlich, ohne Einschränkung, eines Mount-Punktes vom Blocktyp (z.B. iSCSI-kompatibel), eines Mount-Punktes vom Dateityp (z.B. ein Filesystem im Userspace oder eine FUSE-Schnittstelle oder NFS-, SMB- oder CIFS-kompatibel), eines Schlüssel/Wert-Freigabe-Mountpunktes (z.B. ein noSQL-Volume oder eine Amazon S3-kompatible API) und anderer Typen von Mount-Punkten. Auf diese Weise kann der Mount-Punkt so verstanden werden, dass er zur vollständigen Abstraktion des Speicherzugriffs beiträgt, da die containerisierte Anwendung 124 mit jeder Art von Speicherzugriff ausgestattet ist, die von der containerisierten Anwendung 124 benötigt wird (z.B. Dateiprotokoll oder Blockprotokoll usw.), unabhängig von der zugrunde liegenden Speicherart, aus der das virtuelle PV 156 besteht (z.B. unabhängig von software- oder hardwarebasiert, Block oder Datei, lokal oder remote usw.).
  • Der Typ des Mount-Punktes, d.h. die Art der Abstraktion, kann vom Benutzer ausgewählt oder entsprechend der die Speicherung anfordernden containerisierten Anwendung 124 vordefiniert werden (d.h. basierend auf einer Klasse von containerisierten Anwendungen, diktiert durch den Container-Orchestrator 122 usw.). Die Art der Abstraktion kann dem containerisierten Speichervirtualisierungssystem 130 über die an der Steuerungsebene 140 empfangene Speicheranforderung angezeigt werden.
  • Im Beispiel von BILD 1 kann das containerisierte Speichervirtualisierungssystem 130 auch einen Mount-Punkt 182 für die containerisierte Anwendung 126 bereitstellen, um auf ein virtuelles persistentes Volumen 158 zuzugreifen, das als Antwort auf eine Speicheranforderung von der containerisierten Anwendung 126 an den Container-Orchestrator 122 erstellt wurde, und zwar in ähnlicher Weise wie oben für den Mount-Punkt 180 des virtuellen PV 156 für die containerisierte Anwendung 124 beschrieben. Die virtuellen PVs 156 und 158 können beide entsprechende Merkle-Bäume zum Organisieren entsprechender Datensätze enthalten, während der Objektspeicher 152 die Daten der beiden virtuellen PVs 156 und 158 in einer deduplizierten Weise speichert.
  • Im Betrieb (d.h. nach der Erstellung des virtuellen PV 156 und der Bereitstellung des Mount-Punktes 180 für die Anwendung 124) kann das Speichervirtualisierungssystem 130 Input/Output (I/O)-Anforderungen von der containerisierten Anwendung 124 bedienen, die über den Mount-Punkt 180 an ein virtuelles PV 156 gerichtet sind. Um beispielsweise eine Leseanforderung zu bedienen, die über den Mount-Punkt 180 empfangen wird, kann der Speichervirtualisierungssystem 136 die Signaturen von Datenobjekten in dem virtuellen PV, das durch die Leseanforderung adressiert wird, identifizieren (d.h., was das Durchlaufen der Merkle-Baumstruktur des virtuellen PV auf der Grundlage einer Adresse der Leseanforderung einschließen kann) und die physischen Adressen dieser Datenobjektsignaturen aus dem Objektindex 154 ermitteln. In einigen Implementierungen kann die physische Adresse eines Datenobjekts den Mount-Point der zugrunde liegenden Speicherzuordnung angeben, in der das Datenobjekt gespeichert ist (z.B. einer oder mehrere der Mount-Punkte 170, 172, 174, 176 oder 178). Das Speichervirtualisierungssystem kann dann über den Volume-Manager 138 die Datenobjekte unter Verwendung der physischen Adressen (oder unter Verwendung einer virtuellen Adresse und einer Extend-Map wie oben beschrieben) lesen und die gelesenen Daten über den Mount-Punkt 180 an die containerisierte Anwendung 124 zurückgeben.
  • Um eine Schreibanforderung zu bedienen, kann der Speichervirtualisierer 136 in Beispielimplementierungen die in das virtuelle PV 156 zu schreibenden Daten von der containerisierten Anwendung 124 empfangen, prüfen, ob die Daten irgendwelche Datenobjekte enthalten, die aufgrund inhaltsbasierter Signaturen neu in den Objektspeicher 152 aufgenommen wurden, und die neuen Datenobjekte (d.h. Datenobjekte, die nicht bereits im Datenspeicher existieren) in den Objektspeicher schreiben. In einigen Implementierungen kann der Speichervirtualisierer 136 die neuen Datenobjekte vor dem Schreiben in den Objektspeicher 152 komprimieren. Der Prozess des Schreibens in den Objektspeicher 152 kann insbesondere die Kontrolle darüber beinhalten, in welche zugrunde liegende Speicherzuweisung (z. B. 106, 108, 160, 162 oder 164) die neuen Datenobjekte geschrieben werden. In einigen Implementierungen kann die containerisierte Anwendung in der Schreibanforderung angeben, in welche zugrundeliegende Speicherzuordnung die Daten geschrieben werden sollen. In einigen Implementierungen können neue Daten standardmäßig in einen lokalen Speicherabschnitt des virtuellen PV 156 geschrieben werden, wie z.B. in den lokal angeschlossenen physischen Speicher 106, der möglicherweise „heißen“ Tier-Speicher bietet, der für häufigen Zugriff optimiert ist. In einigen Implementierungen kann die containerisierte Anwendung eine bestimmte Richtlinie oder ein Service-Level-Agreement für das Schreiben der Daten angeben, und das Speichervirtualisierungssystem kann bestimmen, welche zugrunde liegende Speicherzuweisung dieser Richtlinie oder diesem SLA entspricht. Das Speichervirtualisierungssystem verwendet dann den Mount-Point (z.B. 170, 172, 174, 176 oder 178), der der zugrunde liegenden Speicherzuweisung entspricht, um die Datenobjekte zu schreiben. Das Speichervirtualisierungssystem fügt den Metadatenobjekten des virtuellen PV 156 auch die Signatur der Datenobjekte hinzu.
  • Die Darstellung von Daten in einem virtuellen PV 156, das nativ dedupliziert und durch eine Signatur des Stammobjekts eindeutig identifiziert ist, kann effiziente Datendienste ermöglichen, einschließlich derer, die vom Datendienstanbieter 134 bereitgestellt werden. Beispielsweise kann der Datendienstanbieter 134 ohne Einschränkung Snapshot-basierte Sicherung, Replikation, Migration, Tiering, redundanzbasierte Datensicherung (z. B. redundantes Array unabhängiger Knoten, auch als RAIN; oder RAID bezeichnet) oder andere Funktionen durchführen. Der Datendienstanbieter 134 kann die Datendienste mit dem virtuellen PV 156 auf eine Weise durchführen, die für die containerisierte Anwendung 124 transparent oder nicht störend ist. Beispielsweise können die Datendienste ohne Änderung des Mount-Punktes 180 und im Fall einiger Datendienste ohne Eingabe oder Anweisung (z.B. Konfigurationsdetails, Einrichtungsbefehle usw.) durch einen Benutzer, die containerisierte Anwendung 124 oder den Container-Orchestrator 122 durchgeführt werden. Darüber hinaus kann in einigen Beispielen der Datendienstanbieter 134 Daten primär auf der Speichervirtualisierungsschicht 150 manipulieren, so dass die Datendienste unabhängig von den verschiedenen zugrunde liegenden Speicher-Mounts und der besonderen Zusammensetzung des virtuellen PV 156 durchgeführt werden. Mit anderen Worten: Der Datendienstanbieter 134 kann einen gemeinsamen Satz von Datendiensten unabhängig von der Art des zugrunde liegenden Speichers, aus dem das virtuelle PV 156 besteht, unterbrechungsfrei und konsistent ausführen. Die oben genannten technischen Vorteile können z.B. dadurch ermöglicht werden, dass das virtuelle PV 156 den zugrunde liegenden Speicher von der containerisierten Anwendung 124 entkoppelt.
  • Beispielsweise kann der Datendienstanbieter 134 einen effizienten, auf Momentaufnahmen basierenden Sicherungsdatendienst durchführen. In einigen Implementierungen kann der Zeitunterschied zwischen Momentaufnahmen eines hierarchisch angeordneten virtuellen PV 156 effizient durch den Vergleich von Objektsignaturen in einer von oben nach unten iterativen Art und Weise, beginnend mit dem Wurzelobjekt, erreicht werden, um Metadaten und Datenobjekte zu finden, die sich unterscheiden. Bei einer Operation zur Sicherung eines aktuellen Zustands des virtuellen PV 156 (d.h. einer aktuellen Momentaufnahme) kann sich beispielsweise die aktuelle Momentaufnahme auf einem Primärsystem (z.B. Computersystem 100) befinden und eine ältere, zuvor gesicherte Momentaufnahme kann bereits auf einem Backup-System (z.B. Computersystem 110) vorhanden sein. In diesem Beispiel kann der Unterschied zwischen dem aktuellen Snapshot und dem älteren Snapshot ermittelt werden, indem die Signaturen der Snapshots in der zuvor beschriebenen Weise verglichen werden, und das Backup-System kann durchsucht werden, um festzustellen, ob die Metadaten oder Datenobjekte, die sich unterscheiden, bereits auf dem Backup-System (d.h. in einem Objektspeicher des Backup-Systems) vorhanden sind. Nur die Metadaten oder Datenobjekte, die nicht existieren, werden vom Primärsystem auf das Sicherungssystem kopiert, wodurch der Datenverkehr reduziert und die Sicherungszeiten verbessert werden. In anderen Implementierungen können Snapshot-basierte Backups auf demselben Primärsystem anstelle oder zusätzlich zum Backup-System auf ähnliche Weise durchgeführt werden.
  • Das Snapshot-basierte Backup kann z.B. planmäßig durchgeführt werden, ohne die containerisierte Anwendung 124 zu unterbrechen. Darüber hinaus kann das Snapshot-basierte Backup in erster Linie auf der Software-Virtualisierungsebene 150 durchgeführt werden, wodurch die Komplexität der direkten Verwaltung jedes einzelnen zugrunde liegenden Speichers vermieden wird. Ähnlich wie der Backup-Prozess kann auch ein Wiederherstellungsprozess mit einem Vergleich der wiederherzustellenden Metadaten oder Datenobjekte mit den bereits auf dem Wiederherstellungsziel vorhandenen Objekten und einer Übertragung nur der Daten, die auf dem Wiederherstellungsziel nicht vorhanden sind, ablaufen.
  • Der Datendienstanbieter 134 kann auch einen Migrationsvorgang durchführen. Die Migration kann Datenobjekte zwischen verschiedenen des zugrunde liegenden Speichers innerhalb eines virtuellen PV 156 verschieben, einschließlich zwischen verschiedenen lokalen Speichern, zwischen lokalen und entfernten Speichern, zwischen verschiedenen entfernten Speichern, zwischen verschiedenen öffentlichen Cloud-Speichern, zwischen öffentlichen Cloud-Speichern und nicht-öffentlichen Cloud-Speichern (entweder lokal oder entfernt) oder zwischen anderen Kombinationen von zugrunde liegenden Speichern. Die Migration wird auf der Speichervirtualisierungsschicht 150 abgewickelt, indem die neue physische Adresse eines verschobenen Datenobjekts mit der unveränderten inhaltsbasierten Signatur im Objektindex 154 verknüpft wird, wodurch die Migration für die containerisierte Anwendung 124 transparent gemacht wird.
  • Als weiteres Beispiel kann der Datendienstanbieter 134 das virtuelle PV 156 auf ein anderes Computersystem migrieren. In einigen Fällen kann es zum Beispiel sinnvoll sein, ein virtuelles PV 156 zu migrieren, um nahe an einer Arbeitslast zu sein, die das virtuelle PV 156 verwendet. In einem Beispielszenario kann der Container-Orchestrator 122 die containerisierte Anwendung 124 aus Gründen des Lastausgleichs oder aus einem anderen Grund auf ein anderes Computersystem verschieben (z.B. vom Quell-Computersystem 100 auf das Ziel-Computersystem 110), und das virtuelle PV 156 muss möglicherweise migriert werden, um nahe an der containerisierten Anwendung 124 zu sein. In einigen Implementierungen kann das Speichervirtualisierungssystem 130 die Verwaltung des virtuellen PV 156 auf ein anderes Speichervirtualisierungssystem auf dem Zielrechnersystem 110 migrieren, auf das die containerisierte Anwendung 124 migriert wurde. Der Datendienstanbieter 134 kann auch einige der Daten im virtuellen PV 156 migrieren, wie z.B. die Migration von Datenobjekten, die sich lokal auf dem Rechensystem 100 befanden (z.B. auf dem darunter liegenden physischen Speicher 106), auf den physischen Speicher des anderen Rechensystems 110, was für die Aufrechterhaltung der Speicherlokalität und anderer Leistungsmerkmale des virtuellen PV 156 nützlich sein kann. Bei einer solchen Migration kann es erforderlich sein, festzustellen, ob das Zielrechnersystem 110 bereits über eine Kopie der zu migrierenden Metadaten oder Datenobjekte verfügt, und nur Datenobjekte zu übertragen, die auf dem Zielrechnersystem 110 nicht vorhanden sind. Gleichzeitig kann derselbe Mount-Punkt 180 für die containerisierte Anwendung 124 beibehalten und nicht unterbrochen werden.
  • Der Datendienstanbieter 134 kann auch Daten-Tiering innerhalb eines virtuellen PV 156 durchführen, d. h. Daten zwischen verschiedenen Arten von zugrunde liegenden Speichern verschieben, die unterschiedliche Merkmale aufweisen und unterschiedlichen Speicherrichtlinien entsprechen können. Zum Beispiel kann ein Tiering durch Zuweisung und/oder Aufteilung der einzelnen Speicherzuweisungen des virtuellen PV 156 in unterschiedlichem Umfang implementiert werden, wie zuvor beschrieben. Unter bestimmten auslösenden Bedingungen kann der Datendienstanbieter 134 (in einigen Implementierungen in Verbindung mit dem Datenträgerverwalter 138) Datenobjekte von einem Extent in einen anderen Extent verschieben und die Extent-Tabelle entsprechend aktualisieren. Auslösende Bedingungen können z.B. ein erhöhter Sicherheitsstatus von Daten sein, der den Datendienstanbieter 134 veranlassen kann, diese Daten von einem öffentlichen Cloud-Speicher 164 in einen Nicht-Cloud-Speicher 106, 108, 160 oder 162 zu verschieben; Alterung von Daten, die den Datendienstanbieter 134 veranlassen kann, diese Daten in eine Archivierungsklasse von Speicher (z.B. Remote-Speicher 160) zu verschieben; häufiger Zugriff auf Daten in jüngster Zeit, der den Datendienstanbieter 134 veranlassen kann, diese Daten in einen Hochleistungsspeicher (z.B. einen lokalen physischen Speicher 106) zu verschieben; oder andere Arten von Bedingungen. Durch das Verschieben und Verwalten von Daten auf der Speichervirtualisierungsschicht 150 kann das Daten-Tiering über jede Art von zugrunde liegendem Speicher und ohne Unterbrechung des Mount-Punktes 180 oder der containerisierten Anwendung 124 durchgeführt werden.
  • Der Datendienstanbieter 134 kann auch redundanzbasierte Datensicherung unterstützen. Beispielsweise kann der Datendienstanbieter 134 RAID-Datenschutz bereitstellen. Beispielsweise kann der Datendienstanbieter 134 (in einigen Implementierungen in Verbindung mit dem Volume-Manager 138) einen RAID-Satz über zugrunde liegende Speicherzuweisungen oder innerhalb einer zugrunde liegenden Speicherzuweisung erstellen (z. B. in Fällen, in denen der lokale physische Speicher 106 einen Satz Laufwerke umfasst). Der Datendienstanbieter 134 kann über einen Software-RAID-Controller verfügen oder mit einem Hardware-RAID-Controller zusammenarbeiten, um Objekte des virtuellen PV 156 gemäß einem RAID-Schema wie RAID 1, RAID 5 oder RAID 6 in den RAID-Satz zu schreiben.
  • Der Datendienstanbieter 134 kann auch RAIN-Datenschutz durch Replikation oder Spiegelung von Daten eines virtuellen PV 156 (der Einfachheit halber auch als primäres virtuelles PV bezeichnet) für Datensicherungs- und Hochverfügbarkeitszwecke in Übereinstimmung mit den RAIN-Architekturprinzipien bereitstellen. In einigen Implementierungen kann der Datendienstanbieter 134 Daten zu Beginn replizieren oder spiegeln, wenn die Daten als Schreibanforderung von der containerisierten Anwendung 124 in die Speichervirtualisierungsschicht 150 kommen. In einigen Implementierungen können die replizierten Daten ein virtuelles PV-Replikat bilden, das eine ähnliche Form wie ein virtuelles PV haben kann (z.B. einschließlich eines Merkle-Baums) und von einem anderen Speichervirtualisierungssystem auf einem anderen Computersystem 110 verwaltet und lokal auf diesem verwaltet werden kann, relativ zu dem primären virtuellen PV, das lokal auf dem Computersystem 100 liegt. Zusätzlich oder alternativ kann das virtuelle PV-Replikat aus einem zugrundeliegenden Speicher bestehen, der von dem zugrundeliegenden Speicher, der das primäre virtuelle PV 156 bildet, verschieden und/oder getrennt ist. Wenn also Daten auf dem primären virtuellen PV nicht wiederhergestellt werden können, können die Daten mit Hilfe eines Failover-Verfahrens aus der virtuellen PV-Reproduktion wiederhergestellt werden.
  • Zusammenfassend lässt sich sagen, dass durch ein containerisiertes Speichervirtualisierungssystem, das verschiedene Speichertypen zu einem virtuellen persistenten Volume aggregiert, das als eine beliebige Anzahl verfügbarer Speicherabstraktionen dargestellt werden kann, der Datenpfad des Container-Speichers von Ende zu Ende hochgradig virtualisiert werden kann. Auf diese Weise kann den Anwendern containerisierter Anwendungen ein hohes Maß an Flexibilität geboten werden, indem sie eine beliebige Zusammensetzung des zugrundeliegenden Speichers anfordern können, um den Leistungsanforderungen (oder anderen Bedürfnissen) einer Anwendung gerecht zu werden, während sie gleichzeitig in der Lage sind, den Speicher mit jeder Art von für die Anwendung geeigneter Abstraktion zu nutzen. Darüber hinaus kann ein konsistenter Satz von Speicherdiensten unabhängig von der Zusammensetzung des zugrundeliegenden Speichers und unabhängig von der Art der Speicherzugriffsabstraktion, die zur Darstellung des virtuellen PV verwendet wird, bereitgestellt werden.
  • 2 und 3 sind Flussdiagramme, die verschiedene Beispielmethoden darstellen. In einigen Implementierungen können ein oder mehrere Blöcke der Methoden im Wesentlichen gleichzeitig oder in einer anderen Reihenfolge als gezeigt ausgeführt werden. In einigen Implementierungen kann eine Methode mehr oder weniger Blöcke enthalten, als gezeigt sind. In einigen Implementierungen können einer oder mehrere der Blöcke einer Methode zu bestimmten Zeiten fortlaufend und/oder wiederholt ausgeführt werden. In einigen Implementierungen können Blöcke der Methoden kombiniert werden.
  • Die in 2 und 3 dargestellten Methoden können in Form von ausführbaren Befehlen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind (z.B. wie die Befehle 105, die auf dem maschinenlesbaren Medium 104 gespeichert sind) und von einer Verarbeitungsressource (z.B. wie die Verarbeitungsressource 102) und/oder in Form von elektronischen Schaltungen ausgeführt werden. Zum Beispiel können Aspekte der Methoden im folgenden als von einem Speichervirtualisierungssystem auf einem Computersystem ausgeführt beschrieben werden, ein Beispiel dafür kann das oben beschriebene containerisierte Speichervirtualisierungssystem 130 auf dem Computersystem 100 sein. Mit anderen Worten, in einigen Implementierungen können zumindest Teile des Speichervirtualisierungssystems, das in Verbindung mit den Methoden 200 und 300 beschrieben wird, in einem Container implementiert werden, der auf einer hardwarebasierten Verarbeitungsressource ausgeführt wird. Zusätzlich können andere Aspekte der unten beschriebenen Methoden unter Bezugnahme auf andere Elemente beschrieben werden, die zur Veranschaulichung in 1 dargestellt sind.
  • BILD 2 ist ein Flussdiagramm, das eine Beispielmethode 200 darstellt. Methode 200 kann nützlich sein, um einer containerisierten Anwendung Speicher in Form eines virtuellen persistenten Volumens zur Verfügung zu stellen, das andere Arten von persistentem Speicher virtualisiert. Methode 200 beginnt bei Block 202 und setzt sich fort bis Block 204, wo ein Speichervirtualisierungssystem (z.B. 130) eine Speicheranforderung von einer containerisierten Anwendung (z.B. 124) erhält. In einigen Implementierungen kann die Anforderung von einem Aspekt der Steuerungsebene (z.B. 140) des Speichervirtualisierungssystems empfangen werden. Darüber hinaus kann in einigen Implementierungen die Anforderung von der containerisierten Anwendung an einen Container-Orchestrator (z.B. 122) übermittelt werden, der wiederum die Anforderung über eine Container-Speicherschnittstelle (z.B. 123) an das Speichervirtualisierungssystem übermittelt.
  • In Block 206 erwirbt das Speichervirtualisierungssystem (oder insbesondere dessen Steuerungsebene) je nach Anforderung eine Vielzahl verschiedener Speicher-Mounts aus verschiedenen verfügbaren Speichertypen. Die verschiedenen Speichertypen können als lokaler oder entfernter Speicher, Hardware/physikalischer Speicher oder softwaredefinierter Speicher, dateibasierter Speicher, blockbasierter Speicher, objektbasierter Speicher, Cloud-Speicher, beliebige andere Speichertypen oder eine Kombination der vorgenannten Typen charakterisiert werden.
  • Zu den lokalen Speichertypen kann beispielsweise Speicher gehören, der sich lokal zum Speichervirtualisierungssystem befindet (d. h. in demselben Computersystem wie die Verarbeitungsressource, auf der das Speichervirtualisierungssystem ausgeführt wird), z. B. ein lokal angeschlossener physischer Speicher (z. B. 106), der als Blockspeichergerät erscheinen kann, ein lokales Dateisystem (z. B. 108) oder ein lokal virtualisiertes Speichervolumen (z. B. 162). Zu einem Remote-Speicher kann beispielsweise ein Speichersystem gehören, das sich außerhalb des Speichervirtualisierungssystems befindet und vom Speichervirtualisierungssystem über ein Kommunikationsmedium wie Ethernet, Fibre Channel usw. erreicht wird. Remote-Speicherung kann ein entferntes Dateisystem (z.B. 160), ein entferntes Blockspeichersystem (z.B. 160), Cloud-Speicherung (z.B. 164) wie Public-Cloud-Speicherung oder ein entferntes virtualisiertes Speichervolumen umfassen. Hardware oder physischer Speicher kann sich z.B. auf lokal angeschlossenen Speicher beziehen (z.B. 106). Software-definierter Speicher kann sich auf Speicher beziehen, der z.B. nicht an eine bestimmte Hardware-Implementierung gebunden ist, als Software in verschiedenen Infrastrukturtypen, einschließlich virtualisierter Infrastruktur, oder ähnlichem, eingesetzt werden kann. Zusammenfassend lässt sich also sagen, dass das Speichervirtualisierungssystem bei der Erfüllung der Anforderung nicht auf einen einzigen Speichertyp beschränkt ist.
  • Um die Speicher-Mounts in Block 206 zu erwerben, kann das Speichervirtualisierungssystem eine standardisierte Container-Speicherschnittstelle verwenden (z.B. 144 und 123 zusammen mit einem Plug-in 128), um zumindest einen Teil des Speichers, der mit der Vielzahl der verschiedenen Speicher-Mounts verbunden ist, aus den lokalen und entfernten Speichertypen bereitzustellen. Beispielsweise kann das Speichervirtualisierungssystem die standardisierte Container-Speicherschnittstelle mit einem Plug-in nutzen, um eine Speicherzuweisung von einem bestimmten Speichersystem bereitzustellen und den resultierenden Mount-Punkt von diesem Speichersystem zu erhalten. Bei einigen Speichertypen, wie z.B. lokal angeschlossenem physischen Speicher, kann das Speichervirtualisierungssystem einen Adapter (z.B. 139) verwenden, um direkt eine Speicherzuweisung und einen daraus resultierenden Speicher-Mountpunkt bereitzustellen, ohne die Container-Speicherschnittstelle zu verwenden. In einigen Implementierungen kann die Steuerungsebene des Speichervirtualisierungssystems die erfassten Mount-Punkte an einen Datenpfadteil (z.B. 132) des Speichervirtualisierungssystems übergeben.
  • In Block 208 erstellt das Speichervirtualisierungssystem (oder insbesondere dessen Datenpfad) ein virtuelles persistentes Volume (z. B. 156), das die Vielzahl der verschiedenen Speicher-Mounts, die in Block 206 erworben wurden, aggregiert. Das virtuelle persistente Volume enthält eine hierarchische Struktur, die Datenobjekte der containerisierten Anwendung durch inhaltsbasierte Signaturen mit einem Wurzelobjekt in Beziehung setzt. Die hierarchische Struktur des virtuellen persistenten Datenträgers kann die Form eines Merkle-Baums (auch als Hash-Baum bezeichnet) haben. Die Datenobjekte können virtuell in einem gemeinsamen deduplizierten Objektspeicher (z.B. 152) gespeichert werden, der auch andere virtuelle PVs bedient, die vom Speichervirtualisierungssystem erstellt wurden. Der Objektspeicher kann die Datenobjekte über einen Objektindex mit einem tatsächlichen Speicherort auf dem zugrunde liegenden Speicher verbinden.
  • In Block 210 stellt das Speichervirtualisierungssystem der containerisierten Anwendung, die den Speicher angefordert hat, einen Mount-Punkt des virtuellen persistenten Volumes zur Verfügung (z. B. über eine in Block 204 empfangene Anforderung). Das Speichervirtualisierungssystem kann in der Lage sein, einen beliebigen aus einer Vielzahl von Mount-Punkten bereitzustellen, die sich auf verschiedene Arten von Speicherzugriffsabstraktionen beziehen. Beispielsweise kann das Speichervirtualisierungssystem das virtuelle PV als einen Dateisystemtyp der Speicherabstraktion darstellen und dementsprechend einen Dateisystem-Mountpunkt exportieren. Als weiteres Beispiel kann das Speichervirtualisierungssystem das virtuelle PV als Blockspeichersystem darstellen und dementsprechend einen Blockgeräte-Mountpunkt exportieren. Ein weiteres Beispiel: Das Speichervirtualisierungssystem kann das virtuelle PV als Schlüssel/Wert-Paar-Speicher darstellen und dementsprechend einen Schlüssel/Wert-Paar-Speicher-Mountpunkt exportieren. Methode 200 kann bei Block 212 enden.
  • BILD 3 ist ein Flussdiagramm, das eine Beispielmethode 300 darstellt, die nützlich sein kann, um verschiedene Lebenszyklus-Aktionen für ein virtuell persistentes Volumen durchzuführen, das mit der Methode 200 erstellt wurde. Zum Beispiel kann in einigen Implementierungen Methode 300 nach Methode 200 durchgeführt werden. Methode 300 beginnt bei Block 302 und setzt sich fort bis Block 304, wo das Speichervirtualisierungssystem Ein-/Ausgabeanforderungen (E/A-Anforderungen) bedient, die über einen Mount-Punkt an ein virtuelles PV gerichtet sind (z. B. ein virtuelles PV, das in Block 208 erstellt wurde, und ein Mount-Punkt, der über Block 210 oben bereitgestellt wird). Zum Beispiel kann die containerisierte Anwendung (z.B. 124) Daten aus dem virtuellen PV lesen (z.B. 156) oder Daten in das virtuelle PV schreiben (z.B. 156) unter Verwendung des Mount-Punktes (z.B. 180), in der zuvor in Bezug auf BILD 1 beschriebenen Weise.
  • In Block 306 kann das Speichervirtualisierungssystem einen Datendienst ausführen. Die Datendienste können mit dem virtuellen PV durchgeführt werden, unabhängig von den verschiedenen zugrunde liegenden Speicher-Mounts. Mit anderen Worten, die Datendienste können auf virtuellen PVs konsistent ausgeführt werden, unabhängig davon, welche Art von zugrunde liegendem Speicher ein virtuelles PV darstellt. Darüber hinaus können die Datendienste ohne Änderung des Mount-Punktes des virtuellen PV durchgeführt werden, so dass die Datendienste transparent oder unterbrechungsfrei in Bezug auf die containerisierte Anwendung bereitgestellt werden können. Beispiele für Datendienste sind Migration, Tiering, Snapshot-basierte Backups, Replikation und redundanzbasierte Datensicherung (z.B. RAIN und/oder RAID). Solche Datendienste können wie zuvor in Bezug auf 1 beschrieben durchgeführt werden. Methode 300 kann bei Block 308 enden.
  • BILD 4 stellt ein Beispielsystem 400 dar, das ein nicht-transitorisches, maschinenlesbares Medium 404 enthält, das mit den Beispielanweisungen 406, 408, 410, 412, 414, 416 (zusammen als Anweisungen 406-416 bezeichnet) kodiert ist, die von einer Verarbeitungsressource 402 ausgeführt werden können. In einigen Implementierungen ist das System 400 für die Implementierung des containerisierten Speichervirtualisierungssystems 130 von 1, für die Durchführung der Methode 200 von 2 und für die Durchführung der Methode 300 von 3 nützlich. Zum Beispiel können die Anweisungen 406-416 in den Anweisungen 105 von 1 enthalten sein. In einigen Implementierungen kann die in Bezug auf 1-3 beschriebene Funktionalität in den Anweisungen 406-416 enthalten sein.
  • Die Verarbeitungsressource 402 kann einen Mikrocontroller, einen Mikroprozessor, einen oder mehrere Kerne einer Zentraleinheit, einen ASIC, einen FPGA und/oder ein anderes Hardwaregerät umfassen, das zum Abrufen und/oder Ausführen von Befehlen von dem maschinenlesbaren Medium 404 geeignet ist, um Funktionen im Zusammenhang mit verschiedenen Beispielen auszuführen. Zusätzlich oder alternativ kann die Verarbeitungsressource 402 eine elektronische Schaltung oder eine dedizierte Logik enthalten oder mit einer solchen gekoppelt sein, um einige oder alle Funktionen der hier beschriebenen Befehle auszuführen.
  • Das maschinenlesbare Medium 404 kann jedes Medium sein, das zur Speicherung ausführbarer Befehle geeignet ist, wie RAM, ROM, EEPROM, Flash-Speicher, ein Festplattenlaufwerk, eine optische Platte oder ähnliches. In einigen Beispielimplementierungen kann das maschinenlesbare Medium 404 ein greifbares, nicht vorübergehendes Medium sein. Das maschinenlesbare Medium 404 kann innerhalb des Systems 400 angeordnet sein. In diesem Fall können die ausführbaren Anweisungen als auf dem System 400 installiert oder eingebettet betrachtet werden. Alternativ kann das maschinenlesbare Medium 404 ein portables (z.B. externes) Speichermedium sein und Teil eines Installationspakets sein.
  • Wie weiter unten beschrieben, kann das maschinenlesbare Medium 404 mit einem Satz ausführbarer Anweisungen 406-416 kodiert werden. Es ist davon auszugehen, dass ein Teil oder alle ausführbaren Befehle und/oder elektronischen Schaltungen, die in einem Feld enthalten sind, in alternativen Implementierungen in einem anderen, in den Abbildungen gezeigten Feld oder in einem anderen, nicht gezeigten Feld enthalten sein können. Einige Implementierungen des Systems 400 können mehr oder weniger Anweisungen enthalten, als in 4 dargestellt sind.
  • Wenn die Anweisung 406 ausgeführt wird, veranlasst sie die Verarbeitungsressource 402, ein containerisiertes Speichervirtualisierungssystem zu instanziieren, das Daten in hierarchischen Strukturen, wie z. B. Hash-Bäumen, verwaltet. Insbesondere unterhält das containerisierte Speichervirtualisierungssystem einen deduplizierten Objektspeicher, der die Datenobjekte und Metadatenobjekte speichert, die von virtuellen persistenten Volumes referenziert werden, die durch die unten beschriebenen Anweisungen 412 erstellt werden. In einigen Implementierungen kann die Anweisung 406 mit einem Container-Orchestrator koordiniert werden, um das Speichervirtualisierungssystem als containerisierte Anwendung bereitzustellen. Zum Beispiel kann das containerisierte Speichervirtualisierungssystem 130 aus BILD 1 ein Beispiel für das durch die Instruktion 406 instanziierte containerisierte Speichervirtualisierungssystem sein. In einigen Implementierungen können eine oder mehrere der zu beschreibenden Anweisungen 408, 410, 412, 414, 416 Teil der Funktionalität des Speichervirtualisierungssystems selbst sein.
  • Die Instruktion 408 bewirkt bei ihrer Ausführung, dass die Verarbeitungsressource 402 eine Speicheranforderung von einer containerisierten Anwendung erhält. Instruktionen 410, wenn sie ausgeführt wird, veranlassen die Verarbeitungsressource 402, eine Vielzahl verschiedener Speicherhalterungen aus einer Mischung von Speichertypen in Übereinstimmung mit der über Instruktion 408 empfangenen Anforderung zu erwerben. Die Mischung von Speichertypen kann z.B. verschiedene (d.h. verschiedene Speichergeräte) lokale Speichertypen, verschiedene (d.h. verschiedene Speichergeräte) entfernte Speichertypen oder eine Kombination von mindestens einem der lokalen Speichertypen und mindestens einem der entfernten Speichertypen umfassen. Beispiele für lokale Speichertypen sind insbesondere Speicher, der sich lokal auf dem System 400 befindet (z.B. in oder auf dem System 400 installiert ist), wie z.B. ein lokal angeschlossener physischer Speicher, ein lokales Dateisystem oder ein lokaler virtualisierter Speicher. Beispiele für entfernte Speichertypen sind ein entferntes Dateisystem, ein entferntes Blockspeichersystem, Cloud-Storage oder ein entfernter virtualisierter Speicher.
  • In einigen Implementierungen kann die Verarbeitungsressource 402 durch die Instruktionen 408 veranlasst werden, eine standardisierte Container-Speicherschnittstelle zu verwenden, um zumindest einen Teil der Mischung von Speichertypen bereitzustellen und zumindest einen Teil der Vielzahl verschiedener Speicherhalterungen zu empfangen. Die standardisierte Container-Speicherschnittstelle kann in Verbindung mit einem Container-Orchestrator und Plug-Ins zur Bereitstellung von Zuweisungen aus den Speichertypen arbeiten. Die Anweisung 408 kann die Verarbeitungsressource 402 auch veranlassen, Adapter (d.h. einen Blockadapter oder einen Dateiadapter) zur Bereitstellung von Speicher, insbesondere von lokalen Speichertypen, zu verwenden.
  • Wenn die Anweisung 412 ausgeführt wird, veranlasst sie die Verarbeitungsressource 402, ein virtuelles persistentes Volume zu erstellen, das vom containerisierten Speichervirtualisierungssystem verwaltet wird und das die Vielzahl der verschiedenen Speicher-Mounts aggregiert. In einer Implementierung enthält das virtuelle persistente Volume einen Hash-Baum (z. B. einen Merkle-Baum), der Datenobjekte auf Blattebene durch inhaltsbasierte Signaturen mit einem Wurzelobjekt verbindet. Bei den Datenobjekten kann es sich um Daten aus der containerisierten Anwendung 124 handeln, z. B. Dateien oder Verzeichnisse.
  • Wenn die Anweisung 414 ausgeführt wird, veranlasst sie die Verarbeitungsressource 402, der containerisierten Anwendung einen Mount-Punkt des virtuellen persistenten Volumes zur Verfügung zu stellen. Die Anweisung 414 kann mehrere Arten von Speicherzugriffsabstraktionen und entsprechende Mount-Punkte zur Auswahl enthalten. Beispielsweise kann Anweisung 414 einen Dateisystem-Mountpunkt bereitstellen, um das virtuelle PV als Dateisystem zu präsentieren, kann einen Blockgerät-Mountpunkt bereitstellen, um das virtuelle PV als Blockspeichergerät zu präsentieren, und kann einen Schlüssel/Wertspeicher-Mountpunkt bereitstellen, um das virtuelle PV als Schlüssel/Wertspeicherpaar zu präsentieren.
  • Wenn die Anweisung 416 ausgeführt wird, veranlasst sie die Verarbeitungsressource 402, einen Datendienst mit dem virtuellen persistenten Volume auszuführen. In einigen Implementierungen können die Instruktionen 416 jederzeit ausgeführt werden, nachdem das virtuelle PV durch die Instruktionen 412 erzeugt wurde. Da der Datendienst in erster Linie mit dem virtuellen persistenten Volume und auf einer Speichervirtualisierungsschicht ausgeführt werden kann, kann der Datendienst unabhängig von der Art des zugrunde liegenden Speichers bereitgestellt werden, in dem die Daten des virtuellen persistenten Volumes physisch gespeichert sind. Der Datendienst kann ohne Rücksicht darauf, wie das virtuelle PV präsentiert wird (d.h. Abstraktion des Speicherzugriffs des virtuellen PV), bereitgestellt werden. Darüber hinaus muss der Mount-Punkt des virtuellen persistenten Volumes nicht geändert werden, und der Zugriff auf das virtuelle PV durch die containerisierte Anwendung muss nicht unterbrochen werden. Der Datendienst kann Migration, Tiering, Snapshot-basierte Sicherung, Replikation oder redundanzbasierte Datensicherung (z.B. RAID oder RAIN) umfassen, und die Instruktionen 416 können diese Datendienste in ähnlicher Weise durchführen wie oben in Bezug auf BILD 1 beschrieben.
  • In der vorstehenden Beschreibung werden zahlreiche Einzelheiten dargelegt, um ein Verständnis des hier offengelegten Gegenstands zu ermöglichen. Die Umsetzung kann jedoch auch ohne einige oder alle dieser Details praktiziert werden. Andere Implementierungen können Modifikationen, Kombinationen und Abweichungen von den oben besprochenen Details beinhalten. Es ist beabsichtigt, dass die folgenden Ansprüche solche Modifikationen und Variationen abdecken.

Claims (20)

  1. Ein nicht-transitorisches maschinenlesbares Medium, das Anweisungen speichert, die von einer Verarbeitungsressource ausführbar sind, wobei das nicht-transitorische maschinenlesbare Medium umfasst: Anweisungen zur Instantiierung eines containerisierten Speichervirtualisierungssystems, das Daten in Hash-Bäumen verwaltet; Anweisungen zum Empfang einer Speicheranfrage von einer containerisierten Anwendung; Instruktionen, entsprechend der Anfrage eine Vielzahl verschiedener Speicherhalterungen aus einer Mischung von Speichertypen zu erwerben; Anweisungen, um ein virtuelles persistentes Volume zu erzeugen, das von dem containerisierten Speichervirtualisierungssystem verwaltet wird und das die Vielzahl von verschiedenen Speicherbefestigungen aggregiert, wobei das virtuelle persistente Volume einen Hash-Baum enthält, der Datenobjekte der containerisierten Anwendung durch inhaltsbasierte Signaturen mit einem Wurzelobjekt in Beziehung setzt; und Anweisungen, über das containerisierte Speichervirtualisierungssystem einen Mount-Punkt des virtuellen persistenten Volumes für die containerisierte Anwendung bereitzustellen.
  2. Das nicht vorübergehende maschinenlesbare Medium nach Anspruch 1, wobei die Mischung der Speichertypen verschiedene lokale Speichertypen, verschiedene entfernte Speichertypen oder eine Kombination aus mindestens einem der lokalen Speichertypen und mindestens einem der entfernten Speichertypen umfasst.
  3. Das nicht vorübergehende maschinenlesbare Medium nach Anspruch 1 oder 2, wobei die lokalen Speichertypen umfassen lokal angeschlossenen physischen Speicher, ein lokales Dateisystem oder lokal virtualisierten Speicher; und Die Remote-Speichertypen umfassen ein Remote-Dateisystem, ein Remote-Blockspeichersystem, Cloud-Storage oder einen Remote-virtualisierten Speicher.
  4. Das nicht vorübergehende maschinenlesbare Medium nach einem der vorhergehenden Ansprüche, wobei die zu erwerbenden Anweisungen Anweisungen zur Verwendung einer standardisierten Container-Speicherschnittstelle enthalten, um wenigstens einen Teil der Mischung von Speichertypen bereitzustellen und wenigstens einen Teil der Vielzahl von verschiedenen Speicherbefestigungen zu empfangen.
  5. Das nicht-transitorische maschinenlesbare Medium nach einem der vorhergehenden Ansprüche, wobei das containerisierte Speichervirtualisierungssystem einen deduplizierten Objektspeicher unterhält, der die Datenobjekte des virtuellen persistenten Datenträgers speichert.
  6. Das nicht-transitorische maschinenlesbare Medium nach einem der vorangegangenen Ansprüche, das ferner Anweisungen zur Durchführung eines Datendienstes mit dem virtuellen persistenten Volume unabhängig von den verschiedenen Speicher-Mounts und ohne Änderung des Mount-Punktes enthält.
  7. Das nicht vorübergehende maschinenlesbare Medium von Anspruch 6, wobei der Datendienst Migration, Tiering, Snapshot-basierte Backups, Replikation und redundanzbasierte Datensicherung umfasst.
  8. Das nicht-transitorische maschinenlesbare Medium eines jeden vorhergehenden Anspruchs, wobei der Mount-Punkt des virtuellen persistenten Volumes aus Speicherzugriffsabstraktionen ausgewählt wird, die für die bereitzustellenden Anweisungen zur Verfügung stehen, einschließlich eines Dateisystem-Mountpunkts, eines Blockgerät-Mountpunkts und eines Schlüssel/Wertspeicher-Mountpunkts.
  9. Eine Verfahren, umfassend: Empfangen einer Speicheranforderung von einer containerisierten Anwendung durch ein Speichervirtualisierungssystem; Erwerben, durch das Speichervirtualisierungssystem und in Übereinstimmung mit der Anforderung, einer Vielzahl von verschiedenen Speicher-Mounts von lokalen und entfernten Speichertypen; Erzeugen, durch das Speichervirtualisierungssystem, eines virtuellen persistenten Volumens, das die Vielzahl von verschiedenen Speicherbefestigungen aggregiert, wobei das virtuelle persistente Volumen eine hierarchische Struktur enthält, die Datenobjekte der containerisierten Anwendung durch inhaltsbasierte Signaturen mit einem Wurzelobjekt in Beziehung setzt; und Bereitstellen eines Mount-Punktes des virtuellen persistenten Volumes durch das Speichervirtualisierungssystem für die containerisierte Anwendung.
  10. Verfahren nach Anspruch 9, wobei die lokalen und entfernten Speichertypen umfassen: einen lokal angeschlossenen physischen Speicher oder ein lokales Dateisystem; und ein entferntes Dateisystem, ein entferntes Blockspeichersystem oder einen Cloud-Speicher.
  11. Verfahren nach Anspruch 9 oder 10, wobei das Erwerben die Verwendung einer standardisierten Container-Speicherschnittstelle umfasst, um zumindest einen Teil des Speichers bereitzustellen, der mit der Vielzahl unterschiedlicher Speicherhalterungen aus den lokalen und entfernten Speichertypen verbunden ist.
  12. Verfahren nach einem der Ansprüche 9 bis 11, wobei mindestens Teile des Speichervirtualisierungssystems in einem Container implementiert sind, der auf einer hardwarebasierten Verarbeitungsressource ausgeführt wird.
  13. Verfahren nach einem der Ansprüche 9 bis 12, bei der die Datenobjekte des virtuellen persistenten Datenträgers in einem deduplizierten Objektspeicher gespeichert werden und die hierarchische Struktur ein Hash-Baum ist.
  14. Verfahren nach einem der Ansprüche 9 bis 13, die ferner die Durchführung eines Datendienstes mit dem virtuellen persistenten Volume unabhängig von den verschiedenen Speicher-Mounts und ohne Änderung des Mount-Punktes umfasst.
  15. Verfahren nach einem der Ansprüche 9 bis 14, wobei der Mount-Punkt des virtuellen persistenten Volumes aus Speicherzugriffsabstraktionen ausgewählt wird, die dem Speichervirtualisierungssystem zur Verfügung stehen, einschließlich eines Dateisystem-Mount-Punktes, eines Blockgerät-Mount-Punktes und eines Schlüssel/Wert-Speicher-Mount-Punktes.
  16. System bestehend aus: eine Verarbeitungsressource; und ein nicht vorübergehendes maschinenlesbares Medium, das Anweisungen speichert, die bei ihrer Ausführung die Verarbeitungsressource veranlassen: ein containerisiertes Speichervirtualisierungssystem instanziieren, das auf der Verarbeitungsressource ausgeführt wird und Daten in Hash-Bäumen verwaltet, von einer containerisierten Anwendung eine Anfrage zur Speicherung erhalten, in Übereinstimmung mit der Anfrage eine Vielzahl verschiedener Speicherhalterungen aus einer Mischung von Speichertypen erwerben, ein virtuelles persistentes Volume zu erzeugen, das von dem containerisierten Speichervirtualisierungssystem verwaltet wird und das die Vielzahl von verschiedenen Speicherbefestigungen aggregiert, wobei das virtuelle persistente Volume einen Hash-Baum enthält, der Datenobjekte der containerisierten Anwendung durch inhaltsbasierte Signaturen mit einem Wurzelobjekt in Beziehung setzt, und über das containerisierte Speichervirtualisierungssystem einen Mount-Punkt des virtuellen persistenten Volumes für die containerisierte Anwendung bereitstellen.
  17. System nach Anspruch 16, das ferner ein physisches Speichermedium umfasst, wobei die Mischung der Lagertypen umfasst: das physische Speichergerät oder ein lokales Dateisystem auf dem physischen Speichergerät; und ein entferntes Dateisystem, ein entferntes Blockspeichersystem, Cloud-Speicher oder ein entfernter virtualisierter Speicher.
  18. System nach Anspruch 16 oder 17, bei dem die Anweisungen, die die Verarbeitungsressource veranlassen, Anweisungen einschließen, die die Verarbeitungsressource veranlassen, eine standardisierte Container-Speicherschnittstelle zu verwenden, um zumindest einen Teil der Mischung von Speichertypen bereitzustellen und zumindest einen Teil der Vielzahl von verschiedenen Speicherbefestigungen zu empfangen.
  19. System nach einem der Ansprüche 16 bis 18, bei dem das nicht-transitorische maschinenlesbare Medium Anweisungen speichert, die bei ihrer Ausführung bewirken, dass die Verarbeitungsressource einen Datendienst mit dem virtuellen persistenten Volume unabhängig von den verschiedenen Speicher-Mounts und ohne Änderung des Mount-Punktes ausführt.
  20. System nach einem der Ansprüche 16 bis 18, wobei der Mount-Punkt des virtuellen persistenten Volumes aus Speicherzugriffsabstraktionen ausgewählt wird, die für die bereitzustellenden Anweisungen verfügbar sind, einschließlich eines Dateisystem-Mountpunkts, eines Blockgerät-Mountpunkts und eines Schlüssel/Wertspeicher-Mountpunkts.
DE102020120553.8A 2019-10-15 2020-08-04 Virtuell persistente volumes für containerisierte anwendungen Pending DE102020120553A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/653,375 2019-10-15
US16/653,375 US11467775B2 (en) 2019-10-15 2019-10-15 Virtual persistent volumes for containerized applications

Publications (1)

Publication Number Publication Date
DE102020120553A1 true DE102020120553A1 (de) 2021-04-15

Family

ID=75155897

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020120553.8A Pending DE102020120553A1 (de) 2019-10-15 2020-08-04 Virtuell persistente volumes für containerisierte anwendungen

Country Status (3)

Country Link
US (1) US11467775B2 (de)
CN (1) CN112667147B (de)
DE (1) DE102020120553A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11340807B2 (en) * 2019-12-17 2022-05-24 Vmware, Inc. Mounting a shared data store of a server cluster on a client cluster for use as a remote data store
US11727126B2 (en) * 2020-04-08 2023-08-15 Avaya Management L.P. Method and service to encrypt data stored on volumes used by containers
US11687267B2 (en) 2020-04-14 2023-06-27 Hewlett Packard Enterprise Development Lp Containerized application manifests and virtual persistent volumes
US20210334235A1 (en) * 2020-04-23 2021-10-28 Netapp, Inc. Systems and methods for configuring, creating, and modifying parallel file systems
US11163462B1 (en) * 2020-04-29 2021-11-02 EMC IP Holding Company LLC Automated resource selection for software-defined storage deployment
US11556372B2 (en) * 2020-06-05 2023-01-17 Vmware, Inc. Paravirtual storage layer for a container orchestrator in a virtualized computing system
US11194483B1 (en) * 2020-06-05 2021-12-07 Vmware, Inc. Enriching a storage provider with container orchestrator metadata in a virtualized computing system
US11693573B2 (en) 2020-06-18 2023-07-04 Hewlett Packard Enterprise Development Lp Relaying storage operation requests to storage systems using underlying volume identifiers
US11960773B2 (en) * 2020-07-31 2024-04-16 Hewlett Packard Enterprise Development Lp Modifying virtual persistent volumes based on analysis of performance metrics
CN113641311B (zh) * 2021-10-18 2022-02-01 浩鲸云计算科技股份有限公司 一种基于本地盘的容器存储资源动态分配的方法和系统
CN114265563B (zh) * 2021-12-31 2023-03-28 北京瑞莱智慧科技有限公司 基于云计算的对象存储方法、装置及存储介质
JP2023167703A (ja) * 2022-05-12 2023-11-24 株式会社日立製作所 計算機システム、及び記憶領域割当制御方法
CN115576655B (zh) * 2022-12-09 2023-04-14 浪潮电子信息产业股份有限公司 容器数据保护系统、方法、装置、设备及可读存储介质
CN116107515B (zh) * 2023-04-03 2023-08-18 阿里巴巴（中国）有限公司 存储卷挂载与访问方法、设备及存储介质
CN116991324B (zh) * 2023-08-08 2024-05-14 深圳市云存宝技术有限公司 一种基于存储虚拟化的云硬盘数据扩容方法及系统

Family Cites Families (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7107385B2 (en) * 2002-08-09 2006-09-12 Network Appliance, Inc. Storage virtualization by layering virtual disk objects on a file system
US7159093B2 (en) 2002-12-20 2007-01-02 Veritas Operating Corporation Development of a detailed logical volume configuration from high-level user requirements
US7143260B2 (en) 2002-12-20 2006-11-28 Veritas Operating Corporation Intermediate descriptions of intent for storage allocation
US7383410B2 (en) 2002-12-20 2008-06-03 Symantec Operating Corporation Language for expressing storage allocation requirements
US7143259B2 (en) 2002-12-20 2006-11-28 Veritas Operating Corporation Preservation of intent of a volume creator with a logical volume
US7162575B2 (en) 2002-12-20 2007-01-09 Veritas Operating Corporation Adaptive implementation of requested capabilities for a logical volume
US7519814B2 (en) * 2003-09-15 2009-04-14 Trigence Corp. System for containerization of application sets
US7627724B2 (en) 2004-06-21 2009-12-01 Microsoft Corporation Persistent, real-time determination of the freshness of changeable data associated with a container
CN101243413B (zh) 2005-06-24 2013-08-14 信科索尔特公司 用于对备份映像进行虚拟化的系统和方法
US7587570B2 (en) 2006-05-31 2009-09-08 International Business Machines Corporation System and method for providing automated storage provisioning
US8984504B2 (en) 2007-06-22 2015-03-17 Red Hat, Inc. Method and system for determining a host machine by a virtual machine
US8949827B2 (en) 2007-06-22 2015-02-03 Red Hat, Inc. Tracking a virtual machine
WO2009033074A2 (en) * 2007-09-05 2009-03-12 Emc Corporation De-duplication in virtualized server and virtualized storage environments
US7930476B1 (en) 2007-12-28 2011-04-19 Emc Corporation Application aware storage resource provisioning
EP2248003A1 (de) 2007-12-31 2010-11-10 Netapp, Inc. System und verfahren zum automatischen speicherungs-lastausgleich in virtuellen server-umgebungen
US8856783B2 (en) 2010-10-12 2014-10-07 Citrix Systems, Inc. Allocating virtual machines according to user-specific virtual machine metrics
US8478799B2 (en) 2009-06-26 2013-07-02 Simplivity Corporation Namespace file system accessing an object store
US20110126197A1 (en) 2009-11-25 2011-05-26 Novell, Inc. System and method for controlling cloud and virtualized data centers in an intelligent workload management system
US20110124409A1 (en) 2009-11-25 2011-05-26 Baynes Nick Graphical object customization based on performance metrics
US9317368B2 (en) 2010-07-14 2016-04-19 Nimble Storage, Inc. Unified management of storage and application consistent snapshots
US8327373B2 (en) 2010-08-24 2012-12-04 Novell, Inc. System and method for structuring self-provisioning workloads deployed in virtualized data centers
US9705730B1 (en) 2013-05-07 2017-07-11 Axcient, Inc. Cloud storage using Merkle trees
US20120117029A1 (en) 2010-11-08 2012-05-10 Stephen Gold Backup policies for using different storage tiers
US8904126B2 (en) 2010-11-16 2014-12-02 Actifio, Inc. System and method for performing a plurality of prescribed data management functions in a manner that reduces redundant access operations to primary storage
US8621461B1 (en) 2010-11-22 2013-12-31 Netapp, Inc. Virtual machine based operating system simulation using host ram-based emulation of persistent mass storage device
US9244967B2 (en) * 2011-08-01 2016-01-26 Actifio, Inc. Incremental copy performance between data stores
US8775773B2 (en) 2011-08-26 2014-07-08 Vmware, Inc. Object storage system
US9590879B2 (en) 2012-03-21 2017-03-07 Tier 3, Inc. Cloud application scaling framework
US9043530B1 (en) 2012-04-09 2015-05-26 Netapp, Inc. Data storage within hybrid storage aggregate
US9921752B2 (en) 2012-05-04 2018-03-20 Netapp, Inc. Systems, methods, and computer program products providing read access in a storage system
US9021476B1 (en) 2012-06-19 2015-04-28 Bromium, Inc. Ensuring the privacy and integrity of a hypervisor
US9135046B1 (en) 2012-06-19 2015-09-15 Bromium, Inc. Preventing host operating system from inspecting or modifying data received by hardware controller by moving host operating system into a virtual machine after boot up
US10140139B1 (en) 2012-06-19 2018-11-27 Bromium, Inc. Ensuring the privacy and integrity of a hypervisor
US20140040889A1 (en) 2012-08-03 2014-02-06 International Business Machines Corporation Facilitating Customer-Initiated Virtual Machine Migration and Swapping
WO2014088445A1 (en) 2012-12-05 2014-06-12 Emc Corporation Storage resource usage analysis for customized application options
US9253520B2 (en) 2012-12-14 2016-02-02 Biscotti Inc. Video capture, processing and distribution system
US10241709B2 (en) 2013-12-09 2019-03-26 Vmware, Inc. Elastic temporary filesystem
US10500441B2 (en) 2014-02-04 2019-12-10 Lagree Technologies, Inc. Pilates exercise routine system and method
US9436391B1 (en) 2014-03-28 2016-09-06 Formation Data Systems, Inc. Efficient scalable I/O scheduling
US10380026B2 (en) 2014-09-04 2019-08-13 Sandisk Technologies Llc Generalized storage virtualization interface
US9800575B1 (en) 2014-09-24 2017-10-24 Ebay Inc. Assigning storage responsibility in a distributed data storage system with replication
WO2016048185A1 (en) 2014-09-26 2016-03-31 Emc Corporation Policy based provisioning of storage system resources
US20170013046A1 (en) 2014-11-18 2017-01-12 Primarydata, Inc. Data-centric data storage
US10496488B2 (en) 2014-12-31 2019-12-03 Netapp, Inc. Methods and systems for clone management
US9740633B2 (en) 2015-01-07 2017-08-22 International Business Machines Corporation Updatable address lookup application program interface
US10127234B1 (en) * 2015-03-27 2018-11-13 Amazon Technologies, Inc. Proactive optimizations at multi-tier file systems
US9910613B2 (en) 2015-03-30 2018-03-06 Ebay Inc. Volume admission control for high-performance distributed data storage system
US9817578B2 (en) 2015-06-05 2017-11-14 Ebay Inc. Data storage space recovery
US10055420B1 (en) 2015-06-30 2018-08-21 EMC IP Holding Company LLC Method to optimize random IOS of a storage device for multiple versions of backups using incremental metadata
US9667725B1 (en) 2015-08-06 2017-05-30 EMC IP Holding Company LLC Provisioning isolated storage resource portions for respective containers in multi-tenant environments
US9940041B2 (en) 2015-09-21 2018-04-10 International Business Machines Corporation Copy-redirect on write
US9798474B2 (en) 2015-09-25 2017-10-24 International Business Machines Corporation Software-defined storage system monitoring tool
US10166478B2 (en) 2015-09-30 2019-01-01 International Business Machines Corporation Predictive recommendations for skills development
US10191944B2 (en) 2015-10-23 2019-01-29 Oracle International Corporation Columnar data arrangement for semi-structured data
US10180886B2 (en) 2015-11-16 2019-01-15 Red Hat, Inc. Recreating a computing environment using tags and snapshots
US20170177224A1 (en) 2015-12-21 2017-06-22 Oracle International Corporation Dynamic storage transitions employing tiered range volumes
US10326744B1 (en) 2016-03-21 2019-06-18 EMC IP Holding Company LLC Security layer for containers in multi-tenant environments
US10498726B2 (en) * 2016-03-22 2019-12-03 International Business Machines Corporation Container independent secure file system for security application containers
US10503623B2 (en) 2016-04-29 2019-12-10 Ca, Inc. Monitoring containerized applications
US10355945B2 (en) 2016-09-21 2019-07-16 International Business Machines Corporation Service level management of a workload defined environment
US10432483B1 (en) 2016-09-26 2019-10-01 Amazon Technologies, Inc. General-purpose metrics publishing with variable resolution
US10223024B2 (en) 2016-10-12 2019-03-05 Oracle International Corporation Storage controller for provisioning storage services for an application based upon application-specific requirements
US9678683B1 (en) 2016-11-01 2017-06-13 Red Hat, Inc. Lazy persistent storage volume provisioning
US10397236B1 (en) 2016-12-12 2019-08-27 Amazon Technologies, Inc. Anamoly detection and recovery of a corrupted computing resource
US10229270B2 (en) * 2016-12-23 2019-03-12 Amazon Technologies, Inc. Host attestation
US10216455B1 (en) 2017-02-14 2019-02-26 Veritas Technologies Llc Systems and methods for performing storage location virtualization
CA3055987C (en) 2017-03-23 2023-03-14 Dh2I Company Highly available stateful containers in a cluster environment
US10909554B2 (en) 2017-03-24 2021-02-02 Verizon Patent And Licensing Inc. Analyzing big data to determine a data plan
US10831385B2 (en) * 2017-04-17 2020-11-10 StorageOS Limited System and method for managing volumes of data in a block storage system
US10452298B2 (en) 2017-05-09 2019-10-22 Microsoft Technology Licensing, Llc Portable file-backed virtual storage class memory
CN110019081B (zh) * 2017-07-20 2023-04-07 中兴通讯股份有限公司 数据持久化处理方法、装置、系统及可读存储介质
US10963349B2 (en) 2017-08-25 2021-03-30 Vmware, Inc. Containerized application snapshots
US11481511B2 (en) 2017-11-03 2022-10-25 Visa International Service Association Secure identity and profiling system
US10742690B2 (en) 2017-11-21 2020-08-11 Juniper Networks, Inc. Scalable policy management for virtual networks
US11392363B2 (en) 2018-01-11 2022-07-19 Robin Systems, Inc. Implementing application entrypoints with containers of a bundled application
US10838624B2 (en) 2018-01-31 2020-11-17 Hewlett Packard Enterprise Development Lp Extent pool allocations based on file system instance identifiers
US10565125B2 (en) 2018-02-27 2020-02-18 Hewlett Packard Enterprise Development Lp Virtual block addresses
US10732868B2 (en) * 2018-08-02 2020-08-04 Red Hat, Inc. Implementing a base set of data storage features for containers across multiple cloud computing environments
US11507403B2 (en) 2019-01-24 2022-11-22 Vmware, Inc. Host computing systems determination to deploy virtual machines based on disk specifications
US10963287B2 (en) 2019-03-27 2021-03-30 Amazon Technologies, Inc. Reducing request latency in a multi-tenant web service host
US10999408B2 (en) 2019-04-05 2021-05-04 Sap Se Automated cloud computing tenant deployment service
US10922213B2 (en) * 2019-05-29 2021-02-16 Red Hat, Inc. Embedded quality indication data for version control systems
WO2021007581A1 (en) 2019-07-11 2021-01-14 Elo Labs, Inc. Interactive personal training system
US11436033B2 (en) 2019-10-11 2022-09-06 International Business Machines Corporation Scalable virtual memory metadata management
US11775353B2 (en) 2019-10-23 2023-10-03 Schlumberger Technology Corporation Mapping workloads to cloud infrastructure
US11593497B2 (en) 2019-10-30 2023-02-28 EMC IP Holding Company LLC System and method for managing sensitive data
US20210173815A1 (en) 2019-12-04 2021-06-10 International Business Machines Corporation Automatically dispositioning of copies of data
US20200241999A1 (en) 2020-03-25 2020-07-30 Intel Corporation Performance monitoring for short-lived functions
US11693573B2 (en) 2020-06-18 2023-07-04 Hewlett Packard Enterprise Development Lp Relaying storage operation requests to storage systems using underlying volume identifiers

Also Published As

Publication number Publication date
CN112667147A (zh) 2021-04-16
US11467775B2 (en) 2022-10-11
CN112667147B (zh) 2023-05-30
US20210109683A1 (en) 2021-04-15

Similar Documents

Publication Publication Date Title
DE102020120553A1 (de) Virtuell persistente volumes für containerisierte anwendungen
DE102021108572A1 (de) Containerisierte anwendungsmanifeste und virtuelle persistente volumes
JP7053682B2 (ja) データベーステナントマイグレーションのシステム及び方法
DE112018004178B4 (de) Mehrstufige speicherung in einem verteilten dateisystem
DE102021109227A1 (de) Weiterleitung von speicheroperationsanfragen an speichersysteme unter verwendung der zugrunde liegenden datenträgerkennungen
DE102013215535B4 (de) Sicherung oder wiederherstellung von daten mit hilfe eines hauptspeichers und nichtflüchtiger speichermedien
US8996837B1 (en) Providing multi-tenancy within a data storage apparatus
DE102021109502A1 (de) Ändern virtueller persistenter volumes auf der grundlage der analyse von leistungskennzahlen
US9424263B1 (en) Multi-tiered filesystem
US20210240369A1 (en) Virtual storage policies for virtual persistent volumes
DE112014006156B4 (de) Speichersystem und Datenmigrationsverfahren
US20150227543A1 (en) Method and apparatus for replication of files and file systems using a deduplication key space
US10042711B1 (en) Distributed data protection techniques with cloning
DE102012218269B4 (de) Schnittstelle zur Verwaltung von Datenverschiebung in einem Speichersystem mit thin provisioning
DE112013004250T5 (de) Systeme, Verfahren und Schnittstellen für adaptive Persistenz
DE102021125179A1 (de) Erzeugen und bereitstellen von containerabbildern
DE102021109729A1 (de) Schätzung der nutzung der speichersystemkapazität
DE102022108863A1 (de) Sicherung von daten für einen namensraum, der einem mandanten zugeordnet ist
DE112021004991T5 (de) Verwaltung einer wiederherstellung eines datenspeicher-datenvolumens
US10620883B1 (en) Multi-format migration for network attached storage devices and virtual machines
DE112019000756T5 (de) Datenmigration in einem hierarchischen Speicherverwaltungssystem
DE102021214029A1 (de) System und verfahren zur sicherungserzeugung unter verwendung von zusammengesetzten systemen
DE112021003610T5 (de) Auf metadaten beruhende datenreplikation

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: HL KEMPNER PATENTANWAELTE, SOLICITORS (ENGLAND, DE

Representative=s name: HL KEMPNER PATENTANWALT, RECHTSANWALT, SOLICIT, DE

R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TEX., US

R016 Response to examination communication