DE112020003423T5 - Architektur von virtuellem speichersystem - Google Patents

Architektur von virtuellem speichersystem Download PDF

Info

Publication number
DE112020003423T5
DE112020003423T5 DE112020003423.2T DE112020003423T DE112020003423T5 DE 112020003423 T5 DE112020003423 T5 DE 112020003423T5 DE 112020003423 T DE112020003423 T DE 112020003423T DE 112020003423 T5 DE112020003423 T5 DE 112020003423T5
Authority
DE
Germany
Prior art keywords
storage
data
virtual
storage system
memory
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
DE112020003423.2T
Other languages
English (en)
Inventor
Ronald Karr
Naveen Neelakantam
Radek Aster
Joshua Freilich
Aswin Karumbunathan
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.)
Pure Storage Inc
Original Assignee
Pure Storage Inc
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 Pure Storage Inc filed Critical Pure Storage Inc
Publication of DE112020003423T5 publication Critical patent/DE112020003423T5/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/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/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • 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/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • 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/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

Abstract

Bedienen von E/A-Operationen in einem virtuellen Speichersystem, einschließlich: Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; Speichern der Daten in einem Staging-Speicher, der von einem oder mehreren virtuellen Laufwerken des virtuellen Speichersystems bereitgestellt wird; und Migrieren mindestens eines Teils der in dem Staging-Speicher gespeicherten Daten aus dem Staging-Speicher in einen dauerhafteren Datenspeicher, der von einem Cloud-Service-Anbieter bereitgestellt wird.

Description

  • Figurenliste
  • Es zeigen:
    • 1A ein erstes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1B ein zweites Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1C ein drittes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1D ein viertes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 2A eine perspektivische Ansicht eines Storage-Clusters mit mehreren Speicherknoten und internem Speicher, der an jeden Speicherknoten gekoppelt ist, um gemäß einigen Ausführungsformen Network Attached Storage bereitzustellen.
    • 2B ein Blockdiagramm, das einen Interconnect-Switch zeigt, der gemäß einigen Ausführungsformen mehrere Speicherknoten koppelt.
    • 2C ein Blockdiagramm mit mehreren Ebenen, das den Inhalt eines Speicherknotens und den Inhalt einer der nichtflüchtigen Solid-State-Speichereinheiten gemäß einigen Ausführungsformen zeigt.
    • 2D eine Speicherserver-Umgebung, die Ausführungsformen der Speicherknoten und Speichereinheiten einiger vorhergehender Figuren in Übereinstimmung mit einigen Ausführungsformen verwendet.
    • 2E ist ein Blade-Hardware-Blockdiagramm, das eine Steuerungsebene, Rechen- und Speicherebenen und Authorities zeigt, die mit den zugrunde liegenden physischen Ressourcen interagieren, in Übereinstimmung mit einigen Ausführungsformen.
    • 2F Elasticity Software Layers in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 2G Authorities und Speicherressourcen in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 3A ein Diagramm eines Speichersystems, das für die Datenkommunikation mit einem Cloud-Service-Anbieter gemäß einigen Ausführungsformen der vorliegenden Offenbarung gekoppelt ist.
    • 3B ein Diagramm eines Speichersystems in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung
    • 3C ein beispielhaftes Computergerät, das speziell für die Durchführung eines oder mehrerer der hier beschriebenen Prozesse konfiguriert werden kann.
    • 3D ein Blockdiagramm, das eine Vielzahl von Speichersystemen veranschaulicht, die einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung unterstützen.
    • 3E ein Flussdiagramm, das ein Beispielverfahren für das Handhaben von E/A-Operationen darstellt, die an einen Datensatz gerichtet sind, der über eine Vielzahl von Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenlegung synchronisiert ist.
    • 4 ein Beispiel für ein cloudbasiertes Speichersystem in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 5 ein Beispiel für ein zusätzliches cloudbasiertes Speichersystem in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 6 ein Flussdiagramm, das ein Beispielverfahren zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
    • 7 ein Flussdiagramm, das ein Beispielverfahren zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
    • 8 ein Flussdiagramm, das ein weiteres Beispielverfahren zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
    • 9 ein Flussdiagramm, das ein weiteres Beispielverfahren für das Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
    • 10 ein Flussdiagramm, das ein weiteres Beispielverfahren für das Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
    • 11 ein Flussdiagramm, das ein weiteres Beispielverfahren für das Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht
    • 12 ein Beispiel für eine virtuelle Speichersystemarchitektur in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 13 ein weiteres Beispiel für eine virtuelle Speichersystemarchitektur in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 14 ein weiteres Beispiel für eine virtuelle Speichersystemarchitektur in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 15 ein weiteres Beispiel für eine virtuelle Speichersystemarchitektur in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 16 ein weiteres Beispiel für eine virtuelle Speichersystemarchitektur in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 17 ein Flussdiagramm, das ein weiteres Beispielverfahren für das Handhaben von E/A-Operationen in einem virtuellen Speichersystem veranschaulicht.
    • 18 ein Flussdiagramm, das ein weiteres Beispielverfahren für das Handhaben von E/A-Operationen in einem virtuellen Speichersystem veranschaulicht.
  • BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Beispielhafte Verfahren, Vorrichtungen und Produkte für virtuelle Speichersystemarchitekturen gemäß den Ausführungsformen der vorliegenden Offenbarung werden unter Bezugnahme auf die beigefügten Figuren beschrieben, beginnend mit 1A. 1A veranschaulicht ein Beispielsystem für Datenspeicherung in Übereinstimmung mit einigen Implementierungen. Das System 100 (hier auch als „Speichersystem“ bezeichnet) enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es sei darauf hingewiesen, dass das System 100 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder eine andere Weise konfiguriert sind.
  • Das System 100 umfasst eine Reihe von Datenverarbeitungsgeräten 164A-B. Datenverarbeitungsgeräte (hierin auch als „Client-Geräte“ bezeichnet) können z.B. einen Server in einem Datenzentrum, eine Workstation, einen Personal Computer, ein Notebook oder ähnliches verkörpern. Datenverarbeitungsgeräte 164A-B können für die Datenkommunikation über ein Storage Area Network („SAN“) 158 oder ein Local Area Network („LAN“) 160 mit einem oder mehreren Speicher-Arrays 102A-B gekoppelt sein.
  • Das SAN 158 kann mit einer Vielzahl von Datenkommunikationsstrukturen, - vorrichtungen und -protokollen implementiert werden. Beispielsweise können die Strukturen für SAN 158 Fibre Channel, Ethernet, Infiniband, Serial Attached Small Computer System Interface („SAS“) oder ähnliches umfassen. Datenkommunikationsprotokolle zur Verwendung mit SAN 158 können Advanced Technology Attachment („ATA“), Fibre Channel Protocol, Small Computer System Interface („SCSI“), Internet Small Computer System Interface („iSCSI“), HyperSCSI, Non-Volatile Memory Express („NVMe“) over Fabrics oder ähnliches umfassen. Es sei angemerkt, dass SAN 158 der Veranschaulichung und nicht der Einschränkung dient. Andere Datenkommunikationskopplungen können zwischen Datenverarbeitungsgeräten 164A-B und Speicher-Arrays 102A-B implementiert werden.
  • Das LAN 160 kann auch mit einer Vielzahl von Strukturen, Vorrichtungen und Protokollen implementiert werden. Zum Beispiel können die Strukturen für LAN 160 Ethernet (802.3), Wireless (802.11) oder ähnliches umfassen. Zu den Datenkommunikationsprotokollen zur Verwendung in LAN 160 können das Transmission Control Protocol („TCP“), das User Datagram Protocol („UDP“), das Internet Protocol („IP“), das HyperText Transfer Protocol („HTTP“), das Wireless Access Protocol („WAP“), das Handheld Device Transport Protocol („HDTP“), das Session Initiation Protocol („SIP“), das Real Time Protocol („RTP“) oder ähnliche Protokolle gehören.
  • Speicher-Arrays 102A-B können persistente Datenspeicherung für die Datenverarbeitungsgeräte 164A-B bereitstellen. In Implementierungen kann das Speicher-Array 102A in einem Gehäuse (nicht abgebildet) und das Speicher-Array 102B in einem anderen Gehäuse (nicht abgebildet) enthalten sein. Die Speicher-Arrays 102A und 102B können einen oder mehrere Speicher-Array-Controller 110A-D (hier auch als „Controller“ bezeichnet) enthalten. Ein Speicher-Array-Controller 110A-D kann als Modul einer automatisierten Rechenanlage mit Computer-Hardware, Computer-Software oder einer Kombination aus Computer-Hardware und -Software ausgeführt sein. In einigen Implementierungen können die Speicher-Array-Controller 110A-D für die Ausführung verschiedener Speicheraufgaben konfiguriert werden. Zu den Speicheraufgaben können Folgendes einschließen: das Schreiben von Daten, die von den Datenverarbeitungsgeräten 164A-B empfangen werden, in das Speicher-Array 102A-B, das Löschen von Daten aus dem Speicher-Array 102A-B, das Abrufen von Daten aus dem Speicher-Array 102A-B und das Bereitstellen von Daten für die Datenverarbeitungsgeräte 164A-B, das Überwachen und Melden der Plattenauslastung und -leistung, das Ausführen von Redundanzbetrieb, wie z.B. Redundant Array of Independent Drives („RAID“) oder RAID-ähnliche Datenredundanzoperationen, das Komprimieren von Daten, das Verschlüsseln von Daten usw.
  • Der Speicher-Array-Controller 110A-D kann auf verschiedene Weise implementiert werden, z. B. als ein Field Programmable Gate Array („FPGA“), Programmable Logic Chip („PLC“), Application Specific Integrated Circuit („ASIC“), System-on-Chip („SOC“) oder jedes Datenverarbeitungsgerät, das diskrete Komponenten enthält, wie z. B. eine Verarbeitungsvorrichtung, eine Zentraleinheit, einen Computerspeicher oder verschiedene Adapter. Der Speicher-Array-Controller 110A-D kann z.B. einen Datenkommunikationsadapter enthalten, der so konfiguriert ist, dass er die Kommunikation über das SAN 158 oder LAN 160 unterstützt. In einigen Implementierungen kann der Speicher-Array-Controller 110A-D unabhängig an das LAN 160 gekoppelt werden. In Implementierungen kann der Speicher-Array-Controller 110A-D einen E/A-Controller oder ähnliches enthalten, der den Speicher-Array-Controller 110A-D für die Datenkommunikation über eine Midplane (nicht abgebildet) mit einer persistenten Speicherressource 170A-B (hier auch als „Speicherressource“ bezeichnet) koppelt. Die persistente Speicherressource 170AB kann eine beliebige Anzahl von Speicherlaufwerken 171A-F (hierin auch als „Speichergeräte“ bezeichnet) und eine beliebige Anzahl von nichtflüchtigen Random Access Memories („NVRAM“) (nicht abgebildet) einschließen.
  • In einigen Implementierungen können die NVRAM-Vorrichtungen einer persistenten Speicherressource 170A-B so konfiguriert sein, dass sie vom Speicher-Array-Controller 110A-D Daten empfangen, die auf den Speicherlaufwerken 171A-F gespeichert werden sollen. In einigen Beispielen können die Daten von den Datenverarbeitungsgeräten 164A-B stammen. In einigen Beispielen kann das Schreiben von Daten auf der NVRAM-Vorrichtung schneller durchgeführt werden als das direkte Schreiben von Daten auf das Speicherlaufwerk 171A-F. In Implementierungen kann der Speicher-Array-Controller 110A-D so konfiguriert werden, dass die NVRAM-Vorrichtungen als schnell zugänglicher Puffer für Daten verwendet werden, die auf die Speicherlaufwerke 171A-F geschrieben werden sollen. Eine Latenzzeit für Schreibanforderungen unter Verwendung von NVRAM- Vorrichtungen als Puffer kann verbessert werden im Vergleich zu einem System, in dem ein Speicher-Array-Controller 110A-D Daten direkt auf die Speicherlaufwerke 171A-F schreibt. In einigen Implementierungen können die NVRAM-Vorrichtungen mit einem Computerspeicher in der Form von RAM mit hoher Bandbreite und niedriger Latenz implementiert werden. Die NVRAM-Vorrichtung wird als „nichtflüchtig“ bezeichnet, da die NVRAM-Vorrichtung eine spezifische Stromquelle erhalten oder enthalten kann, die den Zustand des RAM nach dem Hauptstromausfall der NVRAM-Vorrichtung aufrechterhält. Bei einer solchen Stromquelle kann es sich um eine Batterie, einen oder mehrere Kondensatoren oder Ähnliches handeln. Als Reaktion auf einen Stromausfall kann die NVRAM-Vorrichtung so konfiguriert werden, dass der Inhalt des RAM in einen persistenten Speicher, wie z. B. die Speicherlaufwerke 171A-F, geschrieben wird.
  • In Implementierungen kann sich das Speicherlaufwerk 171A-F auf jedes Gerät beziehen, das für die dauerhafte Aufzeichnung von Daten konfiguriert ist, wobei sich „dauerhaft“ oder „beständig“ auf die Fähigkeit eines Geräts bezieht, aufgezeichnete Daten nach einem Stromausfall zu halten. In einigen Implementierungen kann das Speicherlaufwerk 171A-F Speichermedien entsprechen, die keine Plattenspeicher sind. Zum Beispiel kann das Speicherlaufwerk 171A-F ein oder mehrere Solid-State-Laufwerke (‚SSDs‘), auf Flash-Speicher basierende Speicher, jede Art von nichtflüchtigem Festkörperspeicher oder jede andere Art von nichtmechanischem Speichergerät sein. In anderen Implementierungen kann das Speicherlaufwerk 171A-F mechanische oder rotierende Festplatten, wie z.B. Festplattenlaufwerke (‚HDD‘), enthalten.
  • In einigen Implementierungen können die Speicher-Array-Controller 110A-D so konfiguriert werden, dass die Geräteverwaltungsaufgaben vom Speicherlaufwerk 171A-F in das Speicher-Array 102A-B ausgelagert werden. Beispielsweise können die Speicher-Array-Controller 110A-D Steuerinformationen verwalten, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben können. Die Steuerinformationen können z.B. angeben, dass ein bestimmter Speicherblock ausgefallen ist und nicht mehr beschrieben werden sollte, dass ein bestimmter Speicherblock den Boot-Code für einen Speicher-Array-Controller 110A-D enthält, die Anzahl der Programm-Löschzyklen („P/E“), die an einem bestimmten Speicherblock durchgeführt wurden, das Alter der in einem bestimmten Speicherblock gespeicherten Daten, die Art der Daten, die in einem bestimmten Speicherblock gespeichert sind, usw. In einigen Implementierungen können die Steuerinformationen mit einem zugehörigen Speicherblock als Metadaten gespeichert werden. In anderen Implementierungen können die Steuerinformationen für die Speicherlaufwerke 171A-F in einem oder mehreren bestimmten Speicherblöcken der Speicherlaufwerke 171A-F gespeichert werden, die von dem Speicher-Array-Controller 110A-D ausgewählt werden. Die ausgewählten Speicherblöcke können mit einer Kennung versehen werden, die anzeigt, dass der ausgewählte Speicherblock Steuerinformationen enthält. Die Kennung kann von den Speicher-Array-Controllern 110A-D in Verbindung mit den Speicherlaufwerken 171A-F verwendet werden, um die Speicherblöcke, welche Steuerinformationen enthalten, schnell zu ermitteln. Beispielsweise können die Speicher-Array-Controller 110A-D einen Befehl zur Lokalisierung von Speicherblöcken erteilen, die Steuerinformationen enthalten. Es ist zu beachten, dass die Steuerinformation so groß sein kann, dass Teile der Steuerinformation an mehreren Authorities gespeichert sein können, dass die Steuerinformation z.B. aus Gründen der Redundanz an mehreren Authorities gespeichert sein kann oder dass die Steuerinformation ansonsten auf mehrere Speicherblöcke im Speicherlaufwerk 171A-F verteilt sein kann.
  • In Implementierungen können Speicher-Array-Controller 110A-D die Geräteverwaltungsaufgaben von den Speicherlaufwerken 171A-F des Speicher-Arrays 102AB entlasten, indem sie von den Speicherlaufwerken 171A-F Steuerinformationen abrufen, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben. Das Abrufen der Steuerinformationen von den Speicherlaufwerken 171A-F kann z.B. durch den Speicher-Array-Controller 110A-D erfolgen, der die Speicherlaufwerke 171A-F nach dem Ort der Steuerinformationen für ein bestimmtes Speicherlaufwerk 171A-F abfragt. Die Speicherlaufwerke 171A-F können für die Ausführung von Befehlen konfiguriert werden, die es dem Speicherlaufwerk 171A-F ermöglichen, den Ort der Steuerinformationen zu ermitteln. Die Befehle können von einem Controller (nicht abgebildet) ausgeführt werden, der mit dem Speicherlaufwerk 171A-F verbunden ist oder sich anderweitig auf dem Speicherlaufwerk 171A-F befindet und der das Speicherlaufwerk 171A-F veranlassen kann, einen Teil jedes Speicherblocks abzutasten, um die Speicherblöcke zu ermitteln, die Steuerinformationen für die Speicherlaufwerke 171A-F speichern. Die Speicherlaufwerke 171A-F können antworten, indem sie eine Antwortnachricht an den Speicher-Array-Controller 110A-D senden, die den Ort der Steuerinformationen für das Speicherlaufwerk 171A-F enthält. Als Reaktion auf das Empfangen der Antwortnachricht können die Speicher-Array-Controller 110A-D eine Anforderung zum Lesen von Daten ausgeben, die an der Adresse gespeichert sind, die mit dem Ort der Steuerinformationen für die Speicherlaufwerke 171A-F verknüpft ist.
  • In anderen Implementierungen können die Speicher-Array-Controller 110A-D die Geräteverwaltungsaufgaben weiter von den Speicherlaufwerken 171A-F abnehmen, indem sie als Reaktion auf das Empfangen der Steuerinformationen eine Speicherlaufwerk-Verwaltungsoperation durchführen. Eine Speicherlaufwerk-Verwaltungsoperation kann z.B. eine Operation umfassen, die typischerweise vom Speicherlaufwerk 171A-F durchgeführt wird (z.B. der Controller (nicht abgebildet), der einem bestimmten Speicherlaufwerk 171A-F zugeordnet ist). Eine Speicherlaufwerk-Verwaltungsoperation kann z.B. das Sicherstellen umfassen, dass Daten nicht in ausgefallene Speicherblöcke innerhalb des Speicherlaufwerks 171A-F geschrieben werden, das Sicherstellen, dass Daten so in Speicherblöcke innerhalb des Speicherlaufwerks 171A-F geschrieben werden, dass ein angemessenes Wear-Leveling erreicht wird, und so weiter.
  • In Implementierungen kann das Speicher-Array 102A-B zwei oder mehr Speicher-Array-Controller 110A-D implementieren. Beispielsweise kann das Speicher-Array 102A den Speicher-Array-Controller 110A und den Speicher-Array-Controller 110B einschließen. In einem bestimmten Fall kann ein einzelner Speicher-Array-Controller 110A-D (z. B. Speicher-Array-Controller 110A) eines Speichersystems 100 mit dem Primärstatus (hierin auch als „primärer Controller“ bezeichnet) und andere Speicher-Array-Controller 110A-D (z. B. Speicher-Array-Controller 110A) mit dem Sekundärstatus (hierin auch als „sekundärer Controller“ bezeichnet) bezeichnet werden. Der primäre Controller kann bestimmte Rechte haben, wie z.B. die Erlaubnis, Daten in der persistenten Speicherressource 170A-B zu ändern (z.B. Daten in die persistente Speicherressource 170A-B zu schreiben). Zumindest einige der Rechte des primären Controllers können die Rechte des sekundären Controllers ersetzen. Beispielsweise hat der sekundäre Controller möglicherweise nicht die Erlaubnis, Daten in der persistenten Speicherressource 170A-B zu ändern, wenn der primäre Controller das Recht dazu hat. Der Status der Speicher-Array-Controller 110A-D kann sich ändern. Beispielsweise kann der Speicher-Array-Controller 110A mit dem sekundären Status und der Speicher-Array-Controller 110B mit dem primären Status bezeichnet werden.
  • In einigen Implementierungen kann ein primärer Controller, z. B. Speicher-Array-Controller 110A, als primärer Controller für ein oder mehrere Speicher-Arrays 102A-B dienen, und ein sekundärer Controller, z. B. Speicher-Array-Controller 110B, kann als sekundärer Controller für ein oder mehrere Speicher-Arrays 102A-B dienen. Beispielsweise kann der Speicher-Array-Controller 110A der primäre Controller für Speicher-Array 102A und Speicher-Array 102B sein, und der Speicher-Array-Controller 110B kann der sekundäre Controller für Speicher-Array 102A und Speicher-Array 102B sein. In einigen Implementierungen können die Speicher-Array-Controller 110C und 110D (auch als „Speicherverarbeitungsmodule“ bezeichnet) weder den primären noch den sekundären Status aufweisen. Die Speicher-Array-Controller 110C und 110D, die als Speicherverarbeitungsmodule implementiert sind, können als eine Kommunikationsschnittstelle zwischen den primären und sekundären Controllern (z. B. Speicher-Array-Controller 110A bzw. 110B) und dem Speicher-Array 102B fungieren. Beispielsweise kann der Speicher-Array-Controller 110A des Speicher-Arrays 102A eine Schreibanforderung über SAN 158 an das Speicher-Array 102B senden. Die Schreibanforderung kann von beiden Speicher-Array-Controllern 110C und 110D des Speicher-Arrays 102B empfangen werden. Die Speicher-Array-Controller 110C und 110D erleichtern die Kommunikation, z.B. senden sie die Schreibanforderung an das entsprechende Speicherlaufwerk 171A-F. Es ist zu beachten, dass in einigen Implementierungen Speicherverarbeitungsmodule verwendet werden können, um die Anzahl der von den primären und sekundären Controllern gesteuerten Speicherlaufwerke zu erhöhen.
  • In Implementierungen sind Speicher-Array-Controller 110A-D über eine Midplane (nicht abgebildet) kommunikativ mit einem oder mehreren Speicherlaufwerken 171A-F und mit einer oder mehreren NVRAM-Vorrichtungen (nicht abgebildet) gekoppelt, die als Teil eines Speicher-Arrays 102A-B enthalten sind. Die Speicher-Array-Controller 110A-D können über eine oder mehrere Datenkommunikationsverbindungen mit der Midplane gekoppelt werden, und die Midplane kann über eine oder mehrere Datenkommunikationsverbindungen mit den Speicherlaufwerken 171A-F und den NVRAM-Vorrichtungen gekoppelt werden. Die hier beschriebenen Datenkommunikationsverbindungen werden gemeinsam durch die Datenkommunikationsverbindungen 108A-D dargestellt und können z.B. einen Peripheral Component Interconnect Express (‚PCle‘) - Bus enthalten.
  • 1B veranschaulicht ein Beispielsystem für die Datenspeicherung, in Übereinstimmung mit einigen Implementierungen. Der in 1B dargestellte Speicher-Array-Controller 101 kann den in Bezug auf 1A beschriebenen Speicher-Array-Controllern 110A-D ähneln. In einem Beispiel kann der Speicher-Array-Controller 101 dem Speicher-Array-Controller 110A oder dem Speicher-Array-Controller 110B ähnlich sein. Der Speicher-Array-Controller 101 enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es sei darauf hingewiesen, dass der Speicher-Array-Controller 101 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder eine andere Weise konfiguriert sind. Zur Veranschaulichung der Merkmale des Speicher-Array-Controllers 101 können im Folgenden Elemente aus 1A eingeschlossen werden.
  • Der Speicher-Array-Controller 101 kann ein oder mehrere Verarbeitungsvorrichtungen 104 und einen Direktzugriffsspeicher (‚RAM‘) 111 enthalten. Die Verarbeitungsvorrichtung 104 (oder der Controller 101) repräsentiert eine oder mehrere Mehrzweck-Verarbeitungsvorrichtungen, wie z.B. einen Mikroprozessor, eine Zentraleinheit oder ähnliches. Insbesondere kann die Verarbeitungsvorrichtung 104 (oder der Controller 101) ein Complex Instruction Set Computing („CISC“) Mikroprozessor, ein Reduced Instruction Set Computing („RISC“) Mikroprozessor, ein Very Long Instruction Word („VLIW“) Mikroprozessor oder ein Prozessor sein, der andere Befehlssätze implementiert, oder ein Prozessor, der eine Kombination von Befehlssätzen implementiert. Bei der Verarbeitungsvorrichtung 104 (oder dem Controller 101) kann es sich auch um eine oder mehrere Verarbeitungsvorrichtungen für spezielle Zwecke handeln, wie z.B. Application Specific Integrated Circuit („ASIC“), Field Programmable Gate Array („FPGA“), Digital Signal Processor („DSP“), Netzwerkprozessor oder ähnliches.
  • Die Verarbeitungsvorrichtung 104 kann über eine Datenkommunikationsverbindung 106 an den RAM 111 angeschlossen werden, die als Hochgeschwindigkeits-Speicherbus, wie z.B. ein Double-Data-Rate-4-Bus („DDR4“), ausgeführt sein kann. Im RAM 111 ist ein Betriebssystem 112 gespeichert. In einigen Implementierungen werden Befehle 113 im RAM 111 gespeichert. Die Befehle 113 können Computerprogrammbefehle für die Durchführung von Operationen in einem Direct-Mapped-Flash-Speichersystem enthalten. In einer Ausführungsform ist ein Direct-Mapped-Flash-Speichersystem ein System, das Datenblöcke innerhalb von Flash-Laufwerken direkt und ohne Adressübersetzung durch die Speicher-Controller der Flash-Laufwerke adressiert.
  • In Implementierungen enthält der Speicher-Array-Controller 101 einen oder mehrere Host-Bus-Adapter 103A-C, die über eine Datenkommunikationsverbindung 105A-C an die Verarbeitungsvorrichtung 104 gekoppelt sind. In Implementierungen kann es sich bei den Host-Bus-Adaptern 103A-C um Computerhardware handeln, die ein Host-System (z.B. den Speicher-Array-Controller) mit anderen Netzwerk- und Speicher-Arrays verbindet. In einigen Beispielen kann es sich bei den Host-Bus-Adaptern 103A-C um einen Fibre-Channel-Adapter handeln, der die Verbindung des Speicher-Array-Controller 101 mit einem SAN ermöglicht, um einen Ethernet-Adapter, der die Verbindung des Speicher-Array-Controller 101 mit einem LAN ermöglicht, oder um einen ähnlichen Adapter. Host-Bus-Adapter 103A-C können über eine Datenkommunikationsverbindung 105A-C, wie z.B. einen PCIe-Bus, an die Verarbeitungsvorrichtung 104 gekoppelt werden.
  • In Implementierungen kann der Speicher-Array-Controller 101 einen Host-Bus-Adapter 114 einschließen, der mit einem Expander 115 gekoppelt ist. Der Expander 115 kann verwendet werden, um ein Host-System an eine größere Anzahl von Speicherlaufwerken anzuschließen. Der Expander 115 kann beispielsweise ein SAS-Expander sein, der verwendet wird, damit der Host-Bus-Adapter 114 an Speicherlaufwerke in einer Implementierung angeschlossen werden kann, in welcher der Host-Bus-Adapter 114 als SAS-Controller ausgeführt ist.
  • In Implementierungen kann der Speicher-Array-Controller 101 einen Switch 116 einschließen, der über eine Datenkommunikationsverbindung 109 mit der Verarbeitungsvorrichtung104 gekoppelt ist. Der Switch 116 kann eine Computer-Hardware-Vorrichtung sein, die mehrere Endpunkte von einem einzigen Endpunkt aus erstellen kann, wodurch mehrere Vorrichtungen einen einzigen Endpunkt gemeinsam nutzen können. Der Switch 116 kann z.B. ein PCIe-Switch sein, der an einen PCIe-Bus (z.B. Datenkommunikationsverbindung 109) gekoppelt ist und mehrere PCIe-Verbindungspunkte zur Midplane darstellt.
  • In Implementierungen enthält der Speicher-Array-Controller 101 eine Datenkommunikationsverbindung 107 zur Kopplung des Speicher-Array-Controllers 101 mit anderen Speicher-Array-Controllern. In einigen Beispielen kann die Datenkommunikationsverbindung 107 eine QuickPath Interconnect (QPI) - Verbindung sein.
  • Ein herkömmliches Speichersystem, welches herkömmliche Flash-Laufwerke verwendet, kann einen Prozess über die Flash-Laufwerke hinweg implementieren, die Teil des herkömmlichen Speichersystems sind. Beispielsweise kann ein Prozess auf höherer Ebene des Speichersystems einen Prozess über die Flash-Laufwerke hinweg initiieren und steuern. Ein Flash-Laufwerk des herkömmlichen Speichersystems kann jedoch einen eigenen Speicher-Controller enthalten, der den Prozess ebenfalls durchführt. So kann beim herkömmlichen Speichersystem sowohl ein Prozess auf höherer Ebene (z.B. initiiert durch das Speichersystem) als auch ein Prozess auf niedrigerer Ebene (z.B. initiiert durch einen Speicher-Controller des Speichersystems) ausgeführt werden.
  • Um verschiedene Unzulänglichkeiten eines herkömmlichen Speichersystems zu beheben, können Operationen von Prozessen auf höherer Ebene und nicht von den Prozessen auf niedrigerer Ebene durchgeführt werden. Beispielsweise kann das Flash-Speichersystem Flash-Laufwerke einschließen, die keine Speicher-Controller enthalten, die den Prozess bereitstellen. Daher kann das Betriebssystem des Flash-Speichersystems selbst den Prozess initiieren und steuern. Dies kann durch ein direkt abgebildetes Flash-Speichersystem erreicht werden, das Datenblöcke innerhalb der Flash-Laufwerke direkt und ohne eine Adressübersetzung durch die Speicher-Controller der Flash-Laufwerke adressiert.
  • Das Betriebssystem des Flash-Speichersystems kann eine Liste von Zuordnungseinheiten über mehrere Flash-Laufwerke des Flash-Speichersystems ermitteln und halten. Bei den Zuordnungseinheiten kann es sich um ganze Löschblöcke oder um mehrere Löschblöcke handeln. Das Betriebssystem kann eine Karte oder einen Adressbereich enthalten, der Adressen direkt den Löschblöcken der Flash-Laufwerke des Flash-Speichersystems zuordnet.
  • Ein direktes Abbilden auf die Löschblöcke der Flash-Laufwerke kann verwendet werden, um Daten neu zu schreiben und Daten zu löschen. Die Operationen können zum Beispiel auf einer oder mehreren Zuordnungseinheiten durchgeführt werden, die erste Daten und zweite Daten enthalten, wobei die ersten Daten gespeichert werden sollen und die zweiten Daten nicht mehr vom Flash-Speichersystem verwendet werden. Das Betriebssystem kann den Prozess einleiten, um die ersten Daten an neue Authorities innerhalb anderer Zuordnungseinheiten zu schreiben und die zweiten Daten zu löschen und die Zuordnungseinheiten als für die Verwendung für nachfolgende Daten verfügbar zu kennzeichnen. Somit kann der Prozess nur vom übergeordneten Betriebssystem des Flash-Speichersystems durchgeführt werden, ohne dass ein zusätzlicher untergeordneter Prozess von Controllern der Flash-Laufwerke durchgeführt wird.
  • Zu den Vorteilen des Prozesses, der nur vom Betriebssystem des Flash-Speichersystems durchgeführt wird, gehört eine erhöhte Zuverlässigkeit der Flash-Laufwerke des Flash-Speichersystems, da während des Prozesses keine unnötigen oder redundanten Schreibvorgänge durchgeführt werden. Ein möglicher Neuheitspunkt ist hier das Konzept der Initiierung und Steuerung des Prozesses am Betriebssystem des Flash-Speichersystems. Darüber hinaus kann der Prozess über mehrere Flash-Laufwerke hinweg vom Betriebssystem gesteuert werden. Dies steht im Gegensatz zu dem Prozess, der von einem Speicher-Controller eines Flash-Laufwerks durchgeführt wird.
  • Ein Speichersystem kann aus zwei Speicher-Array-Controllern bestehen, die sich einen Satz von Laufwerken für Failover-Zwecke teilen, oder es kann aus einem einzelnen Speicher-Array-Controller bestehen, der einen Storage-Dienst bereitstellt, der mehrere Laufwerke verwendet, oder es kann aus einem verteilten Netzwerk von Speicher-Array-Controllern bestehen, von denen jeder eine bestimmte Anzahl von Laufwerken oder eine bestimmte Menge an Flash-Speicher besitzt, wobei die Speicher-Array-Controller im Netzwerk zusammenarbeiten, um einen vollständigen Storage-Dienst bereitzustellen und bei verschiedenen Aspekten eines Storage-Dienstes einschließlich der Speicherzuweisung und der Garbage Collection zusammenzuarbeiten.
  • 1C veranschaulicht ein drittes Beispielsystem 117 zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen. Das System 117 (hier auch als „Speichersystem“ bezeichnet) enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es sei angemerkt, dass das System 117 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder eine andere Weise konfiguriert sind.
  • In einer Ausführung enthält das System 117 eine duale Peripheral Component Interconnect („PCI“) Flash-Speichervorrichtung 118 mit separat adressierbarem Schnellschreibspeicher. Das System 117 kann einen Speicher-Controller 119 einschließen. In einer Ausführungsform kann der Speicher-Controller 119A-D eine CPU, eine ASIC, ein FPGA oder eine andere Schaltungsanordnung sein, die die gemäß der vorliegenden Offenbarung erforderlichen Steuerungsstrukturen implementiert. In einer Ausführungsform schließt das System 117 Flash-Speichervorrichtungen (z.B. einschließlich Flash-Speichervorrichtungen 120a-n) ein, die operativ mit verschiedenen Kanälen des Speicher-Controllers 119 gekoppelt sind. Flash-Speichervorrichtungen 120a-n können dem Controller 119A-D als eine adressierbare Sammlung von Flash-Seiten, Löschblöcken und/oder Steuerelementen präsentiert werden, die ausreichen, um dem Speicher-Controller 119A-D die Programmierung und den Abruf verschiedener Aspekte der Flash-Speichervorrichtung zu ermöglichen. In einer Ausführungsform kann der Speicher-Controller 119A-D Operationen auf Flash-Speichervorrichtungen 120a-n durchführen, einschließlich des Speicherns und Abrufens von Dateninhalten von Seiten, des Anordnens und Löschens von Blöcken, des Verfolgens von Statistiken bezüglich der Verwendung und Wiederverwendung von Flash-Speicherseiten, Löschblöcken und -zellen, des Verfolgens und Vorhersagens von Fehlercodes und Fehlern innerhalb des Flash-Speichers, der Steuerung von Spannungspegeln, die mit der Programmierung und dem Abrufen von Inhalten von Flash-Zellen verbunden sind, usw.
  • In einer Ausführungsform kann das System 117 einen RAM 121 enthalten, um separat adressierbare Schnellschreibdaten zu speichern. In einer Ausführungsform kann der RAM 121 aus einem oder mehreren separaten diskreten Bausteinen bestehen. In einer anderen Ausführungsform kann der RAM 121 in den Speicher-Controller 119A-D oder in mehrere Speicher-Controller integriert sein. Der RAM 121 kann auch für andere Zwecke verwendet werden, z.B. als temporärer Programmspeicher für eine Verarbeitungsvorrichtung (z.B. eine CPU) im Speicher-Controller 119.
  • In einer Ausführungsform kann das System 117 ein Energiespeichergerät 122 enthalten, z.B. eine wieder aufladbare Batterie oder einen Kondensator. Das Energiespeichergerät 122 kann Energie speichern, die ausreicht, um den Speicher-Controller 119, einen Teil des RAM-Speichers (z.B. RAM 121) und einen Teil des Flash-Speichers (z.B. Flash-Speicher 120a-120n) ausreichend lange zu versorgen, um den Inhalt des RAM-Speichers in den Flash-Speicher zu schreiben. In einer Ausführungsform kann der Speicher-Controller 119A-D den Inhalt des RAM in den Flash-Speicher schreiben, wenn der Speicher-Controller einen Verlust der externen Stromversorgung feststellt.
  • In einer Ausführungsform umfasst das System 117 zwei Datenkommunikationsverbindungen 123a, 123b. In einer Ausführungsform können die Datenkommunikationsverbindungen 123a, 123b PCI-Schnittstellen sein. In einer anderen Ausführungsform können die Datenkommunikationsverbindungen 123a, 123b auf anderen Kommunikationsstandards basieren (z.B. HyperTransport, InfiniBand usw.). Datenkommunikationsverbindungen 123a, 123b können auf nichtflüchtigen Speicher-Express („NVMe“) - Spezifikationen oder NVMe over Fabrics („NVMf“) - Spezifikationen basieren, die eine externe Verbindung mit dem Speicher-Controller 119A-D von anderen Komponenten im Speichersystem 117 ermöglichen. Es ist zu beachten, dass Datenkommunikationsverbindungen hier der Einfachheit halber austauschbar als PCI-Busse bezeichnet werden können.
  • Das System 117 kann auch eine externe Stromquelle (nicht abgebildet) enthalten, die über eine oder beide Datenkommunikationsverbindungen 123a, 123b oder auch separat bereitgestellt werden kann. Eine alternative Ausführungsform umfasst einen separaten Flash-Speicher (nicht abgebildet), der für Speichern des Inhalts von dem RAM 121 bestimmt ist. Der Speicher-Controller 119A-D kann über einen PCI-Bus eine logische Vorrichtung darstellen, die einen adressierbaren logischen Schnellschreibbaustein oder einen bestimmten Teil des logischen Adressraums des Speicherbausteins 118 enthalten kann, der als PCI-Speicher oder als persistenter Speicher dargestellt werden kann. In einer Ausführungsform werden die in das Gerät zu speichernden Operationen in den RAM 121 geleitet. Bei einem Stromausfall kann der Speicher-Controller 119A-D gespeicherte Inhalte, die mit dem adressierbaren logischen Schnellschreibspeicher assoziiert sind, in den Flash-Speicher (z.B. Flash-Speicher 120a-n) für eine langfristige persistente Speicherung schreiben.
  • In einer Ausführungsform kann die logische Vorrichtung eine Darstellung eines Teils oder des gesamten Inhalts der Flash-Speichervorrichtungen 120a-n enthalten, wobei diese Darstellung es einem Speichersystem mit einer Speichervorrichtung 118 (z.B. Speichersystem 117) ermöglicht, Flash-Speicherseiten direkt anzusprechen und Löschblöcke von Speichersystemkomponenten, die sich außerhalb des Speicherbausteins befinden, über den PCI-Bus direkt umzuprogrammieren. Die Darstellung kann es auch einer oder mehreren der externen Komponenten ermöglichen, andere Aspekte des Flash-Speichers zu steuern und abzurufen, darunter einige oder alle der folgenden: Verfolgen von Statistiken in Bezug auf die Nutzung und Wiederverwendung von Flash-Speicherseiten, Löschblöcken und Zellen über alle Flash-Speichervorrichtungen hinweg; Verfolgen und Vorhersagen von Fehlercodes und Fehlern innerhalb der Flash-Speichervorrichtungen und über die Flash-Speichervorrichtungen hinweg; Steuern der Spannungspegel in Verbindung mit der Programmierung und dem Abrufen der Inhalte von Flash-Zellen; usw.
  • In einer Ausführungsform kann das Energiespeichergerät 122 ausreichen, um den Abschluss von laufenden Operationen an den Flash-Speichervorrichtungen 120a-120n sicherzustellen, und das Energiespeichergerät 122 kann den Speicher-Controller 119A-D und zugehörige Flash-Speichervorrichtungen (z.B. 120a-n) für diese Operationen sowie für Speichern von schnell schreibendem RAM in Flash-Speicher antreiben. Das Energiespeichergerät 122 kann zum Speichern akkumulierter Statistiken und anderer Parameter verwendet werden, die von den Flash-Speichervorrichtungen 120a-n und/oder dem Speicher-Controller 119 gespeichert und verfolgt werden. Für einige oder alle der hier beschriebenen Vorgänge können separate Kondensatoren oder Speichervorrichtungen (z.B. kleinere Kondensatoren in der Nähe der Flash-Speichervorrichtungen oder die in diese eingebettet sind) verwendet werden.
  • Verschiedene Schemata können verwendet werden, um die Lebensdauer der gespeicherten Energiekomponente zu verfolgen und zu optimieren, wie z.B. die Anpassung der Spannungspegel im Laufe der Zeit, die Teilentladung des Energiespeichers 122 zur Messung der entsprechenden Entladungseigenschaften usw. Wenn die verfügbare Energie mit der Zeit abnimmt, kann die effektiv verfügbare Kapazität des adressierbaren Schnellschreibspeichers verringert werden, um sicherzustellen, dass er auf der Grundlage der aktuell verfügbaren gespeicherten Energie sicher beschrieben werden kann.
  • 1D veranschaulicht ein drittes Beispielsystem 124 zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen. In einer Ausführungsform umfasst das System 124 die Speicher-Controller 125a, 125b. In einer Ausführungsform sind die Speicher-Controller 125a, 125b operativ mit Dual-PCI-Speichergeräten 119a, 119b bzw. 119c, 119d gekoppelt. Die Speicher-Controller 125a, 125b können operativ (z.B. über ein Speichernetzwerk 130) mit einer bestimmten Anzahl von Host-Computern 127a-n gekoppelt sein.
  • In einer Ausführungsform stellen zwei Speicher-Controller (z. B. 125a und 125b) Storage-Dienste zur Verfügung, z. B. ein SCS-Blockspeicher-Array, einen Dateiserver, einen Objektserver, eine Datenbank oder einen Datenanalysedienst usw. Die Speicher-Controller 125a, 125b können über eine bestimmte Anzahl von Netzwerkschnittstellen (z.B. 126a-d) Dienste für Host-Computer 127a-n außerhalb des Speichersystems 124 bereitstellen. Die Speicher-Controller 125a, 125b können integrierte Dienste oder eine Anwendung vollständig innerhalb des Speichersystems 124 bereitstellen und so ein konvergiertes Speicher- und Rechnersystem bilden. Die Speicher-Controller 125a, 125b können den Schnellschreibspeicher innerhalb oder über Speichergeräte119a-d hinweg nutzen, um laufende Operationen zu protokollieren, um sicherzustellen, dass die Operationen bei Stromausfall, Entfernen des Speicher-Controllers, Herunterfahren des Speicher-Controllers oder des Speichersystems oder bei einem Fehler einer oder mehrerer Software- oder Hardwarekomponenten innerhalb des Speichersystems 124 nicht verloren gehen.
  • In einer Ausführungsform arbeiten die Controller 125a, 125b als PCI-Master für die einen oder anderen PCI-Busse 128a, 128b. In einer anderen Ausführungsform können die PCI-Busse 128a und 128b auf anderen Kommunikationsstandards basieren (z.B. HyperTransport, InfiniBand usw.). Andere Speichersystemausführungen können Speicher-Controller 125a, 125b als Multi-Master für beide PCI-Busse 128a, 128b betreiben. Alternativ kann eine PCI/NVMe/NVMf-Switching-Infrastruktur oder -Fabric mehrere Speicher-Controller verbinden. Einige Speichersystemausführungen ermöglichen es Speichergeräten, direkt miteinander zu kommunizieren, anstatt nur mit Speicher-Controllern zu kommunizieren. In einer Ausführungsform kann ein Speicher-Controller 119a unter der Leitung eines Speicher-Controllers 125a betrieben werden, um Daten, die in Flash-Speichergeräten gespeichert werden sollen, aus Daten, die im RAM gespeichert wurden (z.B. RAM 121 in 1C), zu synthetisieren und zu übertragen. So kann z.B. eine neu berechnete Version des RAM-Inhalts übertragen werden, nachdem ein Speicher-Controller festgestellt hat, dass eine Operation im gesamten Speichersystem vollständig festgelegt wurde, oder wenn der Schnellschreibspeicher auf der Vorrichtung eine bestimmte benutzte Kapazität erreicht hat, oder nach einer bestimmten Zeit, um die Sicherheit der Daten zu verbessern oder um adressierbare Schnellschreibkapazität zur Wiederverwendung freizugeben. Dieser Mechanismus kann z.B. verwendet werden, um eine zweite Übertragung über einen Bus (z.B. 128a, 128b) von den Speicher-Controllern 125a, 125b zu vermeiden. In einer Ausführungsform kann ein Neuberechnen das Komprimieren von Daten, das Anhängen von Indexierungs- oder anderen Metadaten, das Kombinieren mehrerer Datensegmente miteinander, das Durchführen von Löschcode-Berechnungen usw. umfassen.
  • In einer Ausführungsform kann ein Speicher-Controller 119a, 119b unter der Leitung eines Speicher-Controllers 125a, 125b betriebsbereit sein, um Daten, von im RAM (z.B. RAM 121 in 1C) gespeicherten Daten, zu berechnen und zu anderen Vorrichtungen zu übertragen, ohne Beteiligung der Speicher-Controller 125a, 125b. Diese Operation kann verwendet werden, um Daten, die in einem Controller 125a gespeichert sind, auf einen anderen Controller 125b zu spiegeln, oder sie kann verwendet werden, um Komprimierungs, Datenaggregations- und/oder Löschkodierungsberechnungen und -übertragungen auf Speichergeräte auszulagern, um die Belastung der Speicher-Controller oder der Speicher-Controller-Schnittstelle 129a, 129b auf den PCI-Bus 128a, 128b zu reduzieren.
  • Ein Speicher-Controller 119A-D kann Mechanismen zum Implementieren von Hochverfügbarkeitsprimitiven zur Verwendung durch andere Teile eines Speichersystems außerhalb des Dual-PCI-Speichergeräts 118 enthalten. Beispielsweise können Reservierungs- oder Ausschlussprimitive bereitgestellt werden, so dass in einem Speichersystem mit zwei Speicher-Controllern, die einen hochverfügbaren Storage-Dienst bereitstellen, ein Speicher-Controller den Zugriff des anderen Speicher-Controllers auf das Speichergerät oder den weiteren Zugriff darauf verhindern kann. Dies könnte z.B. in Fällen verwendet werden, in denen ein Controller feststellt, dass der andere Controller nicht richtig funktioniert, oder wenn die Verbindung zwischen den beiden Speicher-Controllern selbst nicht richtig funktioniert.
  • In einer Ausführungsform umfasst ein Speichersystem zur Verwendung mit Dual PCI Direct Mapped Storage-Geräten mit separat adressierbarem Schnellschreibspeicher, Systeme, die Löschblöcke oder Gruppen von Löschblöcken als Zuordnungseinheiten zum Speichern von Daten im Auftrag des Storage-Dienstes oder zum Speichern von Metadaten (z. B. Indizes, Protokolle usw.) verwalten, die mit dem Storage-Dienst assoziiert sind, oder zum ordnungsgemäßen Verwalten des Speichersystems selbst. Flash-Seiten, die einige Kilobyte groß sein können, können geschrieben werden, wenn Daten ankommen oder wenn das Speichersystem Daten für lange Zeitintervalle (z.B. oberhalb eines definierten Zeitschwellenwertes) halten soll. Um Daten schneller zu übertragen oder um die Anzahl der Schreibvorgänge auf die Flash-Speichergeräte zu reduzieren, können die Speicher-Controller zunächst Daten in den separat adressierbaren Schnellschreibspeicher auf einem weiteren Speichergerät schreiben.
  • In einer Ausführungsform können die Speicher-Controller 125a, 125b die Verwendung von Löschblöcken innerhalb und zwischen Speichergeräten (z.B. 118) in Übereinstimmung mit einem Alter und der erwarteten Restlebensdauer der Speichergeräte oder auf der Grundlage anderer Statistiken initiieren. Die Speicher-Controller 125a, 125b können in Übereinstimmung mit nicht mehr benötigten Seiten die Garbage Collection und Datenmigrationsdaten zwischen Speichergeräten initiieren, um die Lebensdauer von Flash-Seiten und Löschblöcken und die gesamte Systemleistung zu verwalten.
  • In einer Ausführungsform kann das Speichersystem 124 Spiegelungs- und/oder Löschkodierungsschemata als Teil der Speicherung von Daten in einem adressierbaren Schnellschreibspeicher und/oder als Teil des Schreibens von Daten in Zuordnungseinheiten, die mit Löschblöcken verbunden sind, verwenden. Löschcodes können sowohl über Speichergeräte hinweg als auch innerhalb von Löschblöcken oder Zuordnungseinheiten oder innerhalb und zwischen Flash-Speichergeräten auf einem einzelnen Speichergerät verwendet werden, um Redundanz gegen Ausfälle einzelner oder mehrerer Speichergeräte zu gewährleisten oder um vor internen Beschädigungen von Flash-Speicherseiten zu schützen, die aus Flash-Speicheroperationen oder aus der Degradierung von Flash-Speicherzellen resultieren. Die Spiegel- und Löschcodierung auf verschiedenen Ebenen kann verwendet werden, um mehrere Arten von Ausfällen, die einzeln oder in Kombination auftreten, zu beheben.
  • Die mit Bezug auf die 2A-G dargestellten Ausführungsformen veranschaulichen einen Storage-Cluster, der Benutzerdaten speichert, z. B. Benutzerdaten, die von einem oder mehreren Benutzer- oder Client-Systemen oder anderen Quellen außerhalb des Storage-Clusters stammen. Der Storage-Cluster verteilt Benutzerdaten auf Speicherknoten, die innerhalb eines Chassis oder auf mehrere Chassis untergebracht sind, wobei eine Löschcodierung und redundante Kopien von Metadaten verwendet werden. Die Löschcodierung bezieht sich auf ein Verfahren zur Datensicherung oder -wiederherstellung, bei dem Daten über eine Reihe verschiedener Standorte, wie z. B. Platten, Speicherknoten oder geografische Standorte, gespeichert werden. Ein Flash-Speicher ist ein Typ von Festkörperspeicher, der in die Ausführungsformen integriert werden kann, obwohl die Ausführungsformen auch auf andere Typen von Festkörperspeichern oder andere Speichermedien, einschließlich Nicht-Festkörperspeicher, erweitert werden können. In einem geclusterten Peer-to-Peer-System werden die Steuerung über Speicherorte und Arbeitslasten auf die Speicherorte verteilt. Aufgaben wie das Vermitteln der Kommunikation zwischen den verschiedenen Speicherknoten, das Erkennen der Nichtverfügbarkeit eines Speicherknotens und das Ausgleichen der E/As (Ein- und Ausgänge) über die verschiedenen Speicherknoten werden alle auf verteilter Basis abgewickelt. Daten werden über mehrere Speicherknoten in Datenfragmenten oder -Stripes angeordnet oder verteilt, die in einigen Ausführungsformen die Datenwiederherstellung unterstützen. Der Besitz von Daten kann innerhalb eines Clusters unabhängig von Ein- und Ausgabemustern neu zugewiesen werden. Diese im Folgenden näher beschriebene Architektur ermöglicht den Ausfall eines Speicherknotens im Cluster, wobei das System betriebsbereit bleibt, da die Daten von anderen Speicherknoten rekonstruiert werden können und somit für Eingabe- und Ausgabeoperationen verfügbar bleiben. In verschiedenen Ausführungsformen kann ein Speicherknoten als ein Clusterknoten, ein Blade oder ein Server bezeichnet werden.
  • Der Storage-Cluster kann sich in einem Chassis befinden, d. h. in einem Gehäuse, das einen oder mehrere Speicherknoten enthält. Ein Mechanismus zur Stromversorgung jedes Speicherknotens, wie z. B. ein Stromverteilungsbus, und ein Kommunikationsmechanismus, wie z. B. ein Kommunikationsbus, der die Kommunikation zwischen den Speicherknoten ermöglicht, sind im Chassis enthalten. Der Storage-Cluster kann gemäß einigen Ausführungsformen als unabhängiges System an einem Ort laufen. In einer Ausführungsform enthält ein Chassis mindestens zwei Instanzen sowohl der Stromverteilung als auch des Kommunikationsbusses, die unabhängig voneinander aktiviert oder deaktiviert werden können. Der interne Kommunikationsbus kann ein Ethernet-Bus sein, jedoch sind andere Technologien wie PCle, InfiniBand und andere gleichermaßen geeignet. Das Gehäuse bietet einen Anschluss für einen externen Kommunikationsbus, um die Kommunikation zwischen mehreren Gehäusen, direkt oder über einen Switch, und mit Clientsystemen zu ermöglichen. Für die externe Kommunikation kann eine Technologie wie Ethernet, InfiniBand, Fibre Channel usw. verwendet werden. In einigen Ausführungsformen verwendet der externe Kommunikationsbus unterschiedliche Kommunikationsbustechnologien für die Kommunikation zwischen Chassis und Client-Systemen. Wenn ein Switch innerhalb oder zwischen dem Chassis eingesetzt wird, kann der Switch als Übersetzung zwischen mehreren Protokollen oder Technologien fungieren. Wenn mehrere Chassis miteinander verbunden sind, um einen Storage-Cluster zu definieren, kann ein Client über proprietäre Schnittstellen oder Standardschnittstellen wie Netzwerk-Dateisystem („NFS“), Common Internet File System („CIFS“), Small ComputerSystem Interface („SCSI“) oder Hypertext Transfer Protocol („HTTP“) auf den Storage-Cluster zugreifen. Die Übersetzung vom Client-Protokoll kann am Switch, am externen Kommunikationsbus des Chassis oder innerhalb jedes Speicherknotens erfolgen. In einigen Ausführungsformen können mehrere Chassis gekoppelt oder über einen Aggregator-Switch miteinander verbunden sein. Ein Teil und/oder das gesamte gekoppelte oder verbundene Chassis kann als Storage-Cluster bezeichnet werden. Wie oben erläutert, kann jedes Chassis mehrere Blades aufweisen, jedes Blade verfügt über eine MAC-Adresse (Media Access Control), aber der Storage-Cluster wird einem externen Netzwerk so präsentiert, als hätte er in einigen Ausführungsformen eine einzige Cluster-IP-Adresse und eine einzige MAC-Adresse.
  • Jeder Speicherknoten kann ein oder mehrere Speicherserver sein, und jeder Speicherserver ist mit einer oder mehreren nichtflüchtigen Festkörperspeichereinheiten verbunden, die als Speichereinheiten oder Speichergeräte bezeichnet werden können. Eine Ausführungsform umfasst einen einzelnen Speicherserver in jedem Speicherknoten und zwischen ein bis acht nichtflüchtige Festkörperspeichereinheiten, wobei dieses eine Beispiel jedoch nicht einschränkend sein soll. Der Speicherserver kann einen Prozessor, DRAM und Schnittstellen für den internen Kommunikationsbus und die Stromverteilung für jeden der Energiebusse enthalten. Innerhalb des Speicherknotens teilen sich die Schnittstellen und die Speichereinheit einen Kommunikationsbus, z.B. PCI Express, in einigen Ausführungsformen. Die nichtflüchtigen Festkörperspeichereinheiten können über einen Kommunikationsbus des Speicherknotens direkt auf die interne Kommunikationsbusschnittstelle zugreifen oder den Speicherknoten auffordern, auf die Busschnittstelle zuzugreifen. Die nichtflüchtige Festkörper-Speichereinheit enthält eine eingebettete CPU, einen Festkörper-Speicher-Controller und eine Anzahl von Festkörper-Massenspeichern, z.B. zwischen 2-32 Terabyte („TB“) in einigen Ausführungsformen. Ein eingebettetes flüchtiges Speichermedium, wie z.B. DRAM, und eine Energiereservevorrichtung sind in der nichtflüchtigen Festkörperspeichereinheit enthalten. In einigen Ausführungsformen ist die Energiereservevorrichtung ein Kondensator, Superkondensator oder eine Batterie, die es ermöglicht, eine Teilmenge des DRAM-Inhalts im Falle eines Stromausfalls auf ein stabiles Speichermedium zu übertragen. In einigen Ausführungsformen ist die nichtflüchtige Festkörperspeichereinheit mit einem Speicher der Speicherklasse aufgebaut, wie z. B. einem Phase Change oder Magnetoresistive Random Access Memory („MRAM“), welcher einen DRAM ersetzt und eine Verzögerungsvorrichtung mit reduzierter Leistung ermöglicht.
  • Eines von vielen Merkmalen der Speicherknoten und des nichtflüchtigen Festkörperspeichers ist die Fähigkeit, Daten in einem Storage-Cluster proaktiv wiederherzustellen. Die Speicherknoten und der nichtflüchtige Festkörperspeicher können bestimmen, wann ein Speicherknoten oder ein nichtflüchtiger Festkörperspeicher im Storage-Cluster nicht erreichbar ist, unabhängig davon, ob ein Versuch zum Lesen von Daten unter Einbeziehung dieses Speicherknotens oder des nichtflüchtigen Festkörperspeichers erfolgt. Die Speicherknoten und der nichtflüchtige Festkörperspeicher arbeiten dann zusammen, um die Daten an zumindest teilweise neuen Orten wiederherzustellen und zu rekonstruieren. Dies stellt insofern eine proaktive Wiederherstellung dar, als das System die Daten wiederherstellt, ohne zu warten, bis die Daten für einen Lesezugriff benötigt werden, der von einem Client-System aus eingeleitet wird, das den Storage-Cluster verwendet. Diese und weitere Einzelheiten zum Speicher und dessen Betrieb werden im Folgenden erörtert.
  • 2A ist eine perspektivische Ansicht eines Storage-Clusters 161 mit mehreren Speicherknoten 150 und internem Festkörperspeicher, der an jeden Speicherknoten gekoppelt ist, um gemäß einigen Ausführungsformen Network Attached Storage oder Storage Area Network bereitzustellen. Ein netzwerkgebundener Speicher, ein Speicherbereichsnetzwerk oder ein Storage-Cluster oder ein anderer Speicher könnte einen oder mehrere Storage-Cluster 161 mit jeweils einem oder mehreren Speicherknoten 150 in einer flexiblen und rekonfigurierbaren Anordnung sowohl der physischen Komponenten als auch der Menge des dadurch bereitgestellten Speicherplatzes enthalten. Der Storage-Cluster 161 ist so konzipiert, dass er in ein Rack passt, und ein oder mehrere Racks können je nach Wunsch für den Speicher eingerichtet und bestückt werden. Der Storage-Cluster 161 hat ein Gehäuse 138 mit mehreren Steckplätzen 142. Es ist zu beachten, dass das Chassis 138 als Gehäuse, Einschub oder Rack-Einheit bezeichnet werden kann. In einer Ausführung verfügt das Chassis 138 über vierzehn Steckplätze 142, obwohl andere Steckplatzanzahlen ohne weiteres möglich sind. Einige Ausführungsformen haben beispielsweise vier Steckplätze, acht Steckplätze, sechzehn Steckplätze, zweiunddreißig Steckplätze oder eine andere geeignete Anzahl von Steckplätzen. Jeder Steckplatz 142 kann in einigen Ausführungsformen einen Speicherknoten 150 aufnehmen. Das Chassis 138 enthält Flaps 148, die zur Montage des Chassis 138 in einem Rack verwendet werden können. Lüfter 144 sorgen für die Luftzirkulation zur Kühlung der Speicherknoten 150 und deren Komponenten, obwohl auch andere Kühlkomponenten verwendet werden könnten oder eine Ausführung ohne Kühlkomponenten entwickelt werden könnte. Eine Switch Fabric 146 verbindet die Speicherknoten 150 innerhalb des Chassis 138 miteinander und mit einem Netzwerk zur Kommunikation mit dem Speicher. In einer hier dargestellten Ausführungsform sind die Steckplätze 142 links von der Switch Fabric 146 und den Lüftern 144 mit Speicherknoten 150 belegt, während die Steckplätze 142 rechts von der Switch Fabric 146 und den Lüftern 144 leer sind und zur Veranschaulichung für das Einsetzen von Speicherknoten 150 zur Verfügung stehen. Diese Konfiguration ist ein Beispiel, und ein oder mehrere Speicherknoten 150 könnten die Steckplätze 142 in verschiedenen weiteren Anordnungen belegen. Die Speicherknotenanordnungen müssen in einigen Ausführungsformen nicht sequentiell oder benachbart sein. Die Speicherknoten 150 sind Hot-Plug-fähig, d. h. ein Speicherknoten 150 kann in einen Steckplatz 142 im Chassis 138 eingesetzt oder aus einem Steckplatz 142 entfernt werden, ohne das System anzuhalten oder auszuschalten. Beim Einsetzen oder Entfernen des Speicherknotens 150 aus dem Steckplatz 142 konfiguriert sich das System automatisch neu, um die Änderung zu erkennen und sich daran anzupassen. Die Rekonfiguration umfasst in einigen Ausführungsformen die Wiederherstellung der Redundanz und/oder den Neuausgleich von Daten oder Last.
  • Jeder Speicherknoten 150 kann mehrere Komponenten aufweisen. In der hier gezeigten Ausführungsform enthält der Speicherknoten 150 eine Leiterplatte 159, die mit einer CPU 156 bestückt ist, d.h. einen Prozessor, einen Speicher 154, der mit der CPU 156 gekoppelt ist, und einen nichtflüchtigen Festkörperspeicher 152, der mit der CPU 156 gekoppelt ist, obwohl andere Halterungen und/oder Komponenten in weiteren Ausführungsformen verwendet werden könnten. Der Speicher 154 verfügt über Befehle, die von der CPU 156 ausgeführt werden, und/oder Daten, die von der CPU 156 bearbeitet werden. Wie weiter unten näher erläutert wird, enthält der nichtflüchtige Festkörperspeicher 152 Flash-Speicher oder, in weiteren Ausführungsformen, andere Arten von Festkörperspeichern.
  • Wie in 2A dargestellt, ist der Storage-Cluster 161 skalierbar, was bedeutet, dass Speicherkapazität mit uneinheitlichen Speichergrößen leicht hinzugefügt werden kann, wie vorstehend beschrieben. Ein oder mehrere Speicherknoten 150 können in jedes Chassis eingesteckt oder aus jedem Chassis entfernt werden, und der Storage-Cluster konfiguriert sich in einigen Ausführungsformen selbst. Plug-in-Speicherknoten 150 können, unabhängig davon, ob sie in ein Chassis im Auslieferungszustand eingebaut oder später hinzugefügt werden, unterschiedliche Größen aufweisen. Beispielsweise kann ein Speicherknoten 150 in einer Ausführung ein beliebiges Vielfaches von 4 TB haben, z. B. 8 TB, 12 TB, 16 TB, 32 TB usw. In weiteren Ausführungsformen kann ein Speicherknoten 150 ein beliebiges Vielfaches anderer Speichermengen oder -kapazitäten haben. Die Speicherkapazität jedes Speicherknotens 150 wird übertragen und beeinflusst die Entscheidungen darüber, wie die Daten in Stripes gespeichert werden sollen. Um eine maximale Speichereffizienz zu erzielen, kann sich eine Ausführungsform so breit wie möglich im Stripe selbst konfigurieren, sofern eine vorgegebene Anforderung an den fortgesetzten Betrieb mit einem Verlust von bis zu einer oder bis zu zwei nichtflüchtigen Festkörperspeichereinheiten 152 oder Speicherknoten 150 innerhalb des Chassis erfüllt ist.
  • 2B ist ein Blockdiagramm, das eine Kommunikationsverbindung 173 und einen Stromverteilungsbus 172 zeigt, die mehrere Speicherknoten 150 koppeln. Erneut Bezug nehmend auf 2A, kann die Kommunikationsverbindung 173 in einigen Ausführungsformen in der Switch Fabric 146 enthalten sein oder mit dieser implementiert werden. Wenn mehrere Storage-Cluster 161 ein Rack besetzen, kann die Kommunikationsverbindung 173 in einigen Ausführungsformen in einen Switch oben im Rack eingebaut oder mit diesem implementiert werden. Wie in 2B dargestellt, ist der Storage-Cluster 161 in einem einzigen Chassis 138 eingeschlossen. Ein externer Port 176 ist über die Kommunikationsverbindung 173 mit den Speicherknoten 150 verbunden, während ein externer Port 174 direkt mit einem Speicherknoten verbunden ist. Ein externer Stromversorgungsanschluss 178 ist mit dem Stromverteilungsbus 172 verbunden. Speicherknoten 150 können eine unterschiedliche Anzahl und unterschiedliche Kapazitäten des nichtflüchtigen Festkörperspeichers 152 enthalten, wie in 2A beschrieben. Darüber hinaus können ein oder mehrere Speicherknoten 150 ein reiner Rechenspeicherknoten sein, wie in 2B dargestellt. Authorities 168 sind auf den nichtflüchtigen Festkörperspeichern 152 implementiert, z.B. als Listen oder andere im Speicher gespeicherte Datenstrukturen. In einigen Ausführungsformen sind die Authorities innerhalb des nichtflüchtigen Festkörperspeichers 152 gespeichert und werden durch Software unterstützt, die auf einem Controller oder einem anderen Prozessor des nichtflüchtigen Festkörperspeichers 152 ausgeführt wird. In einer weiteren Ausführungsform sind die Authorities 168 auf den Speicherknoten 150 implementiert, beispielsweise als Listen oder andere Datenstrukturen, die im Speicher 154 gespeichert sind und durch Software unterstützt werden, die auf der CPU 156 des Speicherknotens 150 ausgeführt wird. Authorities 168 kontrollieren in einigen Ausführungsformen, wie und wo Daten in den nichtflüchtigen Festkörperspeichern 152 gespeichert werden. Diese Steuerung hilft bei dem Bestimmen, welche Art von Löschkodierungsschema auf die Daten angewendet wird und welche Speicherknoten 150 welche Datenteile aufweisen. Jeder Authority 168 kann ein nichtflüchtiger Festkörperspeicher 152 zugeordnet werden. Jede Authority kann einen Bereich von Inode-Nummern, Segment-Nummern oder anderen Daten-Kennungen steuern, die den Daten durch ein Dateisystem, durch die Speicherknoten 150 oder durch den nichtflüchtigen Festkörperspeicher 152 in verschiedenen Ausführungsformen zugewiesen werden.
  • Jedes einzelne Datum und jedes einzelne Metadatum hat in einigen Ausführungsformen Redundanz im System. Darüber hinaus hat jeder Datensatz und jede Metadatei einen Besitzer, der als Authority bezeichnet werden kann. Wenn diese Authority nicht erreichbar ist, zum Beispiel durch den Ausfall eines Speicherknotens, gibt es einen Nachfolgeplan, wie diese Daten oder Metadaten gefunden werden können. In verschiedenen Ausführungsformen gibt es redundante Kopien von Authorities 168. Authorities 168 haben in einigen Ausführungsformen eine Beziehung zu Speicherknoten 150 und nichtflüchtigem Festkörperspeicher 152. Jede Authority 168, die einen Bereich von Datensegmentnummern oder andere Kennungen der Daten abdeckt, kann einem bestimmten nichtflüchtigen Festkörperspeicher 152 zugeordnet werden. In einigen Ausführungsformen sind die Authorities 168 für alle diese Bereiche über die nichtflüchtigen Festkörperspeicher 152 eines Storage-Clusters verteilt. Jeder Speicherknoten 150 verfügt über einen Netzwerkanschluss, der den Zugriff auf den/die nichtflüchtigen Festkörperspeicher 152 dieses Speicherknotens 150 ermöglicht. Daten können in einem Segment gespeichert werden, das mit einer Segmentnummer verbunden ist, und diese Segmentnummer ist in einigen Ausführungsformen eine Indirektion für eine Konfiguration von RAID-Stripes (redundante Anordnung unabhängiger Platten). Die Zuweisung und Verwendung der Authorities 168 stellt somit eine Indirektion zu den Daten dar. Eine Indirektion kann als die Fähigkeit bezeichnet werden, in Übereinstimmung mit einigen Ausführungsformen indirekt auf Daten zu verweisen, in diesem Fall über eine Authority 168. Ein Segment identifiziert einen Satz nichtflüchtiger Festkörperspeicher 152 und eine lokale Kennung in den Satz nichtflüchtiger Festkörperspeicher 152, der Daten enthalten kann. In einigen Ausführungsformen ist die lokale Kennung ein Offset in das Gerät und kann nacheinander von mehreren Segmenten wiederverwendet werden. In anderen Ausführungsformen ist die lokale Kennung für ein bestimmtes Segment einmalig und wird niemals wiederverwendet. Die Offsets im nichtflüchtigen Festkörperspeicher 152 werden zur Lokalisierung von Daten zum Schreiben in den oder Lesen aus dem nichtflüchtigen Festkörperspeicher 152 (in Form von RAID-Stripes) verwendet. Die Daten werden über mehrere Einheiten des nichtflüchtigen Festkörperspeichers 152 in Stripes gespeichert, die den nichtflüchtigen Festkörperspeicher 152 mit der Authority 168 für ein bestimmtes Datensegment enthalten oder sich von diesem unterscheiden können.
  • Wenn sich der Standort eines bestimmten Datensegments ändert, z. B. während einer Datenbewegung oder einer Datenrekonstruktion, sollte die Authority 168 für dieses Datensegment konsultiert werden, und zwar an dem nichtflüchtigen Festkörperspeicher 152 oder dem Speicherknoten 150 mit dieser Authority 168. Um ein bestimmtes Datensegment zu lokalisieren, berechnen Ausführungsformen einen Hash-Wert für ein Datensegment oder wenden eine Inode-Nummer oder eine Datensegment-Nummer an. Das Ergebnis dieser Operation zeigt auf einen nichtflüchtigen Festkörperspeicher 152 mit der Authority 168 für dieses bestimmte Datenelement. In einigen Ausführungsformen besteht diese Operation aus zwei Stufen. Die erste Stufe bildet eine Entitätskennung (ID) ab, z.B. eine Segment-Nummer, Inode-Nummer oder Verzeichnis-Nummer auf eine Authority-Kennung. Diese Zuordnung kann eine Berechnung wie z.B. einen Hash oder eine Bitmaske einschließen. In der zweiten Stufe wird die Authority-Kennung einem bestimmten nichtflüchtigen Festkörperspeicher 152 zugeordnet, was durch eine explizite Zuordnung erfolgen kann. Der Vorgang ist wiederholbar, so dass bei der Durchführung der Berechnung das Ergebnis der Berechnung wiederholt und zuverlässig auf einen bestimmten nichtflüchtigen Festkörperspeicher 152 mit dieser Authority verweist 168. Die Operation kann die Menge der erreichbaren Speicherknoten als Eingabe enthalten. Wenn sich der Satz erreichbarer nichtflüchtiger Festkörperspeichereinheiten ändert, ändert sich der optimale Satz. In einigen Ausführungsformen ist der persistierende Wert die aktuelle Zuweisung (die immer wahr ist), und der berechnete Wert ist die Zielzuweisung, auf die der Cluster versuchen wird, sich neu zu konfigurieren. Diese Berechnung kann verwendet werden, um den optimalen nichtflüchtigen Festkörperspeicher 152 für eine Authority zu bestimmen, wenn ein Satz nichtflüchtiger Festkörperspeicher 152 vorhanden ist, die erreichbar sind und den gleichen Cluster bilden. Die Berechnung bestimmt auch einen angeordneten Satz gleichrangiger nichtflüchtiger Festkörperspeicher 152, der auch die Authority für die Zuordnung nichtflüchtiger Festkörperspeicher aufzeichnet, so dass die Authority auch dann bestimmt werden kann, wenn der zugewiesene nichtflüchtige Festkörperspeicher nicht erreichbar ist. Eine Duplikat- oder Ersatz-Authority 168 kann herangezogen werden, wenn eine bestimmte Authority 168 in einigen Ausführungsformen nicht verfügbar ist.
  • Unter Bezugnahme auf die 2A und 2B sind zwei der vielen Aufgaben der CPU 156 auf einem Speicherknoten 150, Schreibdaten zu zerlegen und Lesedaten wieder zusammenzusetzen. Wenn das System festgestellt hat, dass Daten geschrieben werden sollen, befindet sich die Authority 168 für diese Daten wie oben angegeben. Wenn die Segment-ID für Daten bereits bestimmt ist, wird die Anforderung zum Schreiben an den nichtflüchtigen Festkörperspeicher 152 weitergeleitet, der gegenwärtig als Host der aus dem Segment bestimmten Authority 168 bestimmt wird. Die Host-CPU 156 des Speicherknotens 150, auf dem sich der nichtflüchtige Festkörperspeicher 152 und die entsprechende Authority 168 befinden, zerlegt oder zerstückelt dann die Daten und überträgt die Daten an verschiedene nichtflüchtige Festkörperspeicher 152. Die übertragenen Daten werden gemäß einem Löschkodierungsschema als Daten-Stripes geschrieben. In einigen Ausführungsformen werden Daten angefordert, um abgerufen zu werden, und in anderen Ausführungsformen werden Daten gepusht. Umgekehrt wird beim Lesen von Daten die Authority 168 für die Segment-ID, die die Daten enthält, wie vorstehend beschrieben lokalisiert. Die Host-CPU 156 des Speicherknotens 150, auf dem sich der nichtflüchtige Festkörperspeicher 152 und die entsprechende Authority 168 befinden, fordert die Daten aus dem nichtflüchtigen Festkörperspeicher und den entsprechenden Speicherknoten an, auf die die Authority verweist. In einigen Ausführungsformen werden die Daten als Daten-Stripes aus dem Flash-Speicher gelesen. Die Host-CPU 156 des Speicherknotens 150 setzt dann die gelesenen Daten wieder zusammen, korrigiert etwaige Fehler (falls vorhanden) gemäß dem entsprechenden Löschkodierungsschema und leitet die wieder zusammengesetzten Daten an das Netzwerk weiter. In weiteren Ausführungsformen können einige oder alle dieser Aufgaben in dem nichtflüchtigen Festkörperspeicher 152 ausgeführt werden. In einigen Ausführungsformen fordert der Segment-Host die an den Speicherknoten 150 zu sendenden Daten an, indem er Seiten aus dem Speicher anfordert und die Daten dann an den Speicherknoten sendet, der die ursprüngliche Anforderung stellt.
  • In einigen Systemen, z. B. in Dateisystemen im UNIX-Stil, werden Daten mit einem Indexknoten oder Inode gehandhabt, der eine Datenstruktur angibt, die ein Objekt in einem Dateisystem repräsentiert. Das Objekt kann z.B. eine Datei oder ein Verzeichnis sein. Metadaten können mit dem Objekt einhergehen, unter anderem als Attribute wie Berechtigungsdaten und ein Erstellungszeitstempel. Eine Segmentnummer könnte dem gesamten oder einem Teil eines solchen Objekts in einem Dateisystem zugewiesen werden. In anderen Systemen werden Datensegmente mit einer anderswo zugewiesenen Segmentnummer gehandhabt. Für Diskussionszwecke ist die Verteilungseinheit eine Entität, und eine Entität kann eine Datei, ein Verzeichnis oder ein Segment sein. Das heißt, Entitäten sind Einheiten von Daten oder Metadaten, die von einem Speichersystem gespeichert werden. Entitäten werden in Sets gruppiert, die Authorities genannt werden. Jede Authority hat einen Authority-Besitzer, d.h. einen Speicherknoten, der das exklusive Recht hat, die Entitäten in der Authority zu aktualisieren. Mit anderen Worten, ein Speicherknoten enthält die Authority, und diese Authority wiederum enthält Entitäten.
  • Ein Segment ist ein logischer Container von Daten in Übereinstimmung mit einigen Ausführungsformen. Ein Segment ist ein Adressraum zwischen dem mittleren Adressraum, und die physischen Flash-Speicherorte, d.h. die Datensegmentnummern, befinden sich in diesem Adressraum. Segmente können auch Metadaten enthalten, die es ermöglichen, Datenredundanz wiederherzustellen (auf verschiedene Flash-Speicherorte oder Geräte zurückzuschreiben), ohne dass eine übergeordnete Software involviert ist. In einer Ausführungsform enthält ein internes Format eines Segments Client-Daten und Medium-Mappings zum Bestimmen der Position dieser Daten. Jedes Datensegment wird z.B. vor Speicher- und anderen Ausfällen geschützt, indem das Segment in eine Anzahl von Daten- und Paritäts-Shards zerlegt wird, wo dies anwendbar ist. Die Daten- und Paritäts-Shards werden gemäß einem Löschkodierungsschema über den nichtflüchtigen Festkörperspeicher 152 verteilt, der an die Host-CPUs 156 (siehe 2E und 2G) gekoppelt ist. Die Verwendung des Begriffs „Segment“ bezieht sich auf den Container und seinen Platz in dem Adressraum von Segmenten in einigen Ausführungsformen. Die Verwendung des Begriffs „Stripe“ bezieht sich auf denselben Satz von Shards, als ein Segment, und schließt ein, wie die Shards zusammen mit Redundanz- oder Paritätsinformationen in Übereinstimmung mit einigen Ausführungsformen verteilt werden.
  • In einem gesamten Speichersystem findet eine Reihe von Adressraum-Transformationen statt. Ganz oben stehen die Verzeichniseinträge (Dateinamen), die auf einen Inode verweisen. Der Inode verweist auf einen mittleren Adressraum, in dem Daten logisch gespeichert werden. Mittlere Adressen können über eine Reihe von indirekten Medien abgebildet werden, um die Last großer Dateien zu verteilen oder Datendienste wie Deduplizierung oder Snapshots zu implementieren. Segmentadressen werden dann in physische Flash-Speicherorte übersetzt. Physische Flash-Speicherorte haben gemäß einigen Ausführungsformen einen Adressbereich, der durch die Menge an Flash im System begrenzt ist. Mittlere Adressen und Segmentadressen sind logische Container, und in einigen Ausführungsformen wird eine Kennung von 128 Bit oder mehr verwendet, so dass er praktisch unendlich ist, wobei die Wahrscheinlichkeit der Wiederverwendung als länger als die erwartete Lebensdauer des Systems berechnet wird. Adressen aus logischen Containern werden in einigen Ausführungsformen hierarchisch zugeordnet. Anfänglich kann jeder nichtflüchtigen Festkörperspeichereinheit 152 ein Bereich von eines Adressraums zugewiesen werden. Innerhalb dieses zugewiesenen Bereichs ist der nichtflüchtige Festkörperspeicher 152 in der Lage, Adressen ohne Synchronisation mit anderen nichtflüchtigen Festkörperspeichern 152 zuzuweisen.
  • Daten und Metadaten werden durch eine Reihe von zugrunde liegenden Speicherlayouts gespeichert, die für unterschiedliche Auslastungsmuster und Speichergeräte optimiert sind. Diese Layouts umfassen mehrere Redundanzschemata, Komprimierungsformate und Indexalgorithmen. Einige dieser Layouts speichern Informationen über Authorities und Authority-Master, während andere Dateimetadaten und Dateidaten speichern. Zu den Redundanzschemata gehören Fehlerkorrekturcodes, die beschädigte Bits innerhalb eines einzelnen Speichergeräts (z. B. eines NAND-Flash-Chips) tolerieren, Löschcodes, die den Ausfall mehrerer Speicherknoten tolerieren, und Replikationsschemata, die Ausfälle von Datenzentren oder Regionen tolerieren. In einigen Ausführungsformen wird innerhalb einer einzelnen Speichereinheit ein LDPC-Code (Low Density Parity Check) verwendet. Innerhalb eines Storage-Clusters wird Reed-Solomon-Kodierung verwendet, und in einigen Ausführungsformen wird die Spiegelung innerhalb eines Speicherrasters verwendet. Metadaten können unter Verwendung eines geordneten logarithmisch strukturierten Index (z. B. ein Log Structured Merge Tree) gespeichert werden, und große Daten werden möglicherweise nicht in einem logarithmisch strukturierten Layout gespeichert.
  • Um die Konsistenz über mehrere Kopien einer Entität hinweg zu gewährleisten, stimmen die Speicherknoten durch Berechnungen implizit in zwei Dingen überein: (1) die Authority, die die Entität enthält, und (2) den Speicherknoten, der die Authority enthält. Die Zuordnung von Entitäten zu Authorities kann durch pseudozufällige Zuweisung von Entitäten zu Authorities, durch Aufteilung von Entitäten in Bereiche auf der Grundlage eines extern erstellten Schlüssels oder durch Platzierung einer einzelnen Entität in jeder Authority erfolgen. Beispiele für pseudozufällige Schemata sind lineares Hashing und Replication Under Scalable Hashing („RUSH“) - Familie der Hashes, einschließlich der Controlled Replication Under Scalable Hashing („CRUSH“). In einigen Ausführungsformen wird die pseudozufällige Zuweisung nur für die Zuweisung von Befugnissen an Knoten verwendet, da sich die Menge der Knoten ändern kann. Der Satz von Authorities kann sich nicht ändern, so dass in diesen Ausführungsformen jede beliebige subjektive Funktion angewendet werden kann. Einige Platzierungsschemata platzieren Authorities automatisch auf Speicherknoten, während andere Platzierungsschemata auf einer expliziten Zuordnung von Authorities zu Speicherknoten beruhen. In einigen Ausführungsformen wird ein pseudozufälliges Schema verwendet, um die Zuordnung von jeder Authority zu einem Satz von Kandidaten für die Authority-Besitzer vorzunehmen. Eine pseudozufällige Datenverteilungsfunktion im Zusammenhang mit CRUSH kann Authorities Speicherknoten zuweisen und eine Liste erstellen, in der die Authorities zugewiesen werden. Jeder Speicherknoten verfügt über eine Kopie der pseudozufälligen Datenverteilungsfunktion und kann die gleiche Berechnung für die Verteilung und das spätere Auffinden oder Lokalisieren einer Authority durchführen. Jedes der pseudozufälligen Schemata erfordert den erreichbaren Satz von Speicherknoten als Eingabe in einigen Ausführungsformen, um auf dieselben Zielknoten zu schließen. Sobald eine Entität in einer Authority platziert wurde, kann die Entität auf physischen Geräten gespeichert werden, so dass kein erwarteter Ausfall zu einem unerwarteten Datenverlust führt. In einigen Ausführungsformen versuchen Rebalancing-Algorithmen, die Kopien aller Entitäten innerhalb einer Authority im gleichen Layout und auf dem gleichen Satz von Rechnern zu speichern.
  • Beispiele für zu erwartende Ausfälle sind Geräteausfälle, gestohlene Maschinen, Brände im Rechenzentrum und regionale Katastrophen, wie nukleare oder geologische Ereignisse. Unterschiedliche Ausfälle führen zu einem unterschiedlichen Grad an akzeptablem Datenverlust. In einigen Ausführungsformen beeinträchtigt ein gestohlener Speicherknoten weder die Sicherheit noch die Zuverlässigkeit des Systems, während ein regionales Ereignis je nach Systemkonfiguration zu keinem Datenverlust, einigen Sekunden oder Minuten verlorener Aktualisierungen oder sogar zum vollständigen Datenverlust führen kann.
  • In den Ausführungsformen ist die Platzierung der Daten für die Speicherredundanz unabhängig von der Platzierung der Authorities für die Datenkonsistenz. In einigen Ausführungsformen enthalten Speicherknoten, die Authorities enthalten, keine persistente Speicherung. Stattdessen sind die Speicherknoten mit nichtflüchtigen Festkörperspeichereinheiten verbunden, die keine Authorities enthalten. Die Kommunikationsverbindung zwischen Speicherknoten und nichtflüchtigen Festkörperspeichereinheiten besteht aus mehreren Kommunikationstechnologien und weist uneinheitliche Leistungs- und Fehlertoleranzeigenschaften auf. In einigen Ausführungsformen sind, wie oben erwähnt, nichtflüchtige Festkörperspeichereinheiten über PCI-Express mit Speicherknoten verbunden, Speicherknoten sind innerhalb eines einzigen Chassis über eine Ethernet-Backplane miteinander verbunden, und Chassis sind zu einem Storage-Cluster zusammengeschlossen. Storage-Cluster werden in einigen Ausführungsformen über Ethernet oder Glasfaserkanal mit Clients verbunden. Wenn mehrere Storage-Cluster zu einem Speicher-Grid konfiguriert sind, werden die mehreren Storage-Cluster über das Internet oder andere Fernnetzwerkverbindungen miteinander verbunden, wie z. B. eine „Metro-Scale“-Verbindung oder eine private Verbindung, die nicht über das Internet läuft.
  • Authority-Besitzer haben das ausschließliche Recht, Entitäten zu modifizieren, Entitäten von einer nichtflüchtigen Festkörper-Speichereinheit in eine andere nichtflüchtige Festkörper-Speichereinheit zu migrieren und Kopien von Entitäten hinzuzufügen und zu entfernen. Auf diese Weise kann die Redundanz der zugrunde liegenden Daten aufrechterhalten werden. Wenn ein Berechtigungsinhaber ausfällt, außer Betrieb genommen werden soll oder überlastet ist, wird die Berechtigung auf einen neuen Speicherknoten übertragen. Bei vorübergehenden Ausfällen ist es nicht unbedeutend, sicherzustellen, dass alle nicht ausfallenden Rechner den neuen Autoritätsstandort akzeptieren. Die Zweideutigkeit, die durch vorübergehende Ausfälle entsteht, kann automatisch durch ein Konsensprotokoll wie Paxos, Hot-Warm-Failover-Schemata, durch manuelles Eingreifen eines entfernten Systemadministrators oder durch einen lokalen Hardware-Administrator erreicht werden (z. B. durch physisches Entfernen des ausgefallenen Rechners aus dem Cluster oder durch Drücken einer Taste auf dem ausgefallenen Rechner). In einigen Ausführungsformen wird ein Konsensprotokoll verwendet, und das Failover erfolgt automatisch. Wenn zu viele Ausfälle oder Replikationsereignisse in einer zu kurzen Zeitspanne auftreten, geht das System in einen Selbsterhaltungsmodus über und stoppt die Replikations- und Datenbewegungsaktivitäten, bis ein Administrator entsprechend einiger Ausführungsformen eingreift.
  • Wenn Authorities zwischen Speicherknoten übertragen werden und Authority-Besitzer Entitäten in ihren Authorities aktualisieren, überträgt das System Nachrichten zwischen den Speicherknoten und den nichtflüchtigen Festkörperspeichereinheiten. Im Hinblick auf persistente Nachrichten sind Nachrichten, die unterschiedliche Zwecke aufweisen, von unterschiedlichem Typ. Je nach Art der Nachricht unterhält das System unterschiedliche Ordnungs- und Haltbarkeitsgarantien. Während die persistenten Nachrichten verarbeitet werden, werden die Nachrichten vorübergehend in mehreren dauerhaften und nicht dauerhaften Speicherhardwaretechnologien gespeichert. In einigen Ausführungsformen werden die Nachrichten in RAM, NVRAM und auf NAND-Flash-Geräten gespeichert, und eine Vielzahl von Protokollen wird verwendet, um jedes Speichermedium effizient zu nutzen. Latenzempfindliche Client-Anforderungen können im replizierten NVRAM und später im NAND gespeichert werden, während Rebalancing-Operationen im Hintergrund direkt im NAND gespeichert werden.
  • Persistente Nachrichten werden vor der Übertragung persistent gespeichert. Dadurch ist das System in der Lage, Client-Anfragen trotz Ausfällen und Komponentenaustausch weiterhin zu bearbeiten. Obwohl viele Hardware-Komponenten eindeutige Kennungen enthalten, die für Systemadministratoren, Hersteller, die Hardware-Lieferkette und die Infrastruktur zur laufenden Überwachung der Qualitätskontrolle sichtbar sind, virtualisieren Anwendungen, die über der Infrastruktur laufen, Adressen. Diese virtualisierten Adressen ändern sich während der Lebensdauer des Speichersystems nicht, unabhängig von Ausfällen und Austausch von Komponenten. Dadurch kann jede Komponente des Speichersystems im Laufe der Zeit ohne Neukonfiguration oder Unterbrechungen der Verarbeitung von Client-Anfragen ersetzt werden, d.h. das System unterstützt unterbrechungsfreie Upgrades.
  • In einigen Ausführungsformen werden die virtualisierten Adressen mit ausreichender Redundanz gespeichert. Ein kontinuierliches Überwachungssystem korreliert den Hardware- und Software-Status und die Hardware-Kennungen. Dies ermöglicht die Erkennung und Vorhersage von Ausfällen aufgrund fehlerhafter Komponenten und Fertigungsdetails. Das Überwachungssystem ermöglicht außerdem den proaktiven Transfer von Authorities und Entitäten weg von betroffenen Geräten, bevor es zu einem Ausfall kommt, indem die Komponente in einigen Ausführungsformen aus dem kritischen Pfad entfernt wird.
  • 2C ist ein Blockdiagramm mit mehreren Ebenen, das den Inhalt eines Speicherknotens 150 und den Inhalt eines nichtflüchtigen Festkörperspeichers 152 des Speicherknotens 150 zeigt. In einigen Ausführungsformen werden Daten von und zum Speicherknoten 150 durch einen Netzwerk-Schnittstellen-Controller (‚NIC‘) 202 übertragen. Jeder Speicherknoten 150 hat eine CPU 156 und einen oder mehrere nichtflüchtige Festkörperspeicher 152, wie vorstehend beschrieben. Eine Ebene tiefer in 2C hat jeder nichtflüchtige Festkörperspeicher 152 einen relativ schnellen nichtflüchtigen Festkörperspeicher, wie z.B. einen nichtflüchtigen Speicher mit wahlfreiem Zugriff (‚NVRAM‘) 204 und einen Flash-Speicher 206. In einigen Ausführungsformen kann NVRAM 204 eine Komponente sein, die keine Programm-/Löschzyklen benötigt (DRAM, MRAM, PCM), und kann ein Speicher sein, der es unterstützt, wesentlich öfter beschrieben zu werden als aus dem Speicher gelesen wird. Auf einer weiteren Ebene in 2C wird das NVRAM 204 in einer Ausführungsform als flüchtiger Hochgeschwindigkeitsspeicher implementiert, z. B. als dynamischer Speicher mit wahlfreiem Zugriff (DRAM) 216, der durch eine Energiereserve 218 gesichert wird. Die Energiereserve 218 stellt ausreichend elektrische Leistung zur Verfügung, um den DRAM 216 lange genug mit Strom zu versorgen, damit bei einem Stromausfall Inhalte auf den Flash-Speicher 206 übertragen werden können. In einigen Ausführungsformen ist die Energiereserve 218 ein Kondensator, Superkondensator, eine Batterie oder ein anderes Gerät, das eine geeignete Energiezufuhr liefert, die ausreicht, um bei einem Stromausfall die Übertragung des Inhalts von den DRAM 216 auf ein dauerhaftes Speichermedium zu ermöglichen. Der Flash-Speicher 206 ist als Mehrfach-Flash-Dies 222 implementiert, die als Pakete von Flash-Dies 222 oder ein Array von Flash-Dies 222 bezeichnet werden können. Es ist zu beachten, dass die Flash-Dies 222 auf beliebig viele Arten verpackt werden können, mit einem einzigen Chip pro Gehäuse, mehreren Chips pro Gehäuse (d.h. Multichip-Gehäuse), in Hybridgehäusen, als nackte Chips auf einer Leiterplatte oder einem anderen Substrat, als gekapselte Chips usw. In der gezeigten Ausführung hat der nichtflüchtige Festkörperspeicher 152 einen Controller 212 oder einen anderen Prozessor und einen mit dem Controller 212 gekoppelten Eingangs-Ausgangs-(E/A-)Port 210. Der E/A-Port 210 ist mit der CPU 156 und/oder dem Netzwerk-Schnittstellen-Controller 202 des Flash-Speicherknotens 150 gekoppelt. Der Flash-Eingangs-Ausgangs-(E/A)-Port 220 ist mit den Flash-Dies 222 gekoppelt, und eine Direct Memory Access Unit (DMA) 214 ist mit dem Controller 212, dem DRAM 216 und den Flash-Dies 222 gekoppelt. In der gezeigten Ausführung sind der E/A-Port 210, der Controller 212, die DMA-Einheit 214 und der Flash-E/A-Port 220 auf einem programmierbaren Logikbaustein („PLD“) 208 implementiert, z.B. einem Field Programmable Gate Array (FPGA). In dieser Ausführung hat jeder Flash-Die 222 Seiten, organisiert als sechzehn kB (Kilobyte) Seiten 224, und ein Register 226, über das Daten auf den Flash-Die 222 geschrieben oder von ihm gelesen werden können. In weiteren Ausführungsformen werden andere Arten von Festkörperspeichern anstelle von oder zusätzlich zu den Flash-Speichern verwendet, die im Flash-Die 222 abgebildet sind.
  • Die Storage-Cluster 161 in verschiedenen Ausführungsformen, wie sie hier offengelegt werden, können mit Speicher-Arrays im Allgemeinen verglichen werden. Die Speicherknoten 150 sind Teil einer Sammlung, die den Storage-Cluster 161 bildet. Jeder Speicherknoten 150 besitzt einen Teil der Daten und der Berechnungen, die zur Bereitstellung der Daten erforderlich sind. Mehrere Speicherknoten 150 arbeiten zusammen, um die Daten zu speichern und abzurufen. Speicher oder Speichergeräte, wie sie im Allgemeinen in Speicher-Arrays verwendet werden, sind weniger an der Verarbeitung und Handhabung der Daten beteiligt. Speicher oder Speichergeräte in einem Speicher-Array empfangen Befehle zum Lesen, Schreiben oder Löschen von Daten. Der Speicher oder die Speichergeräte in einem Speicher-Array kennen weder ein größeres System, in das sie eingebettet sind, noch wissen sie, was die Daten bedeuten. Der Speicher oder die Speichergeräte in einem Speicher-Array können verschiedene Arten von Speicher wie RAM, Solid-State-Laufwerke, Festplattenlaufwerke usw. enthalten. Die hier beschriebenen Speichereinheiten 152 haben mehrere Schnittstellen, die gleichzeitig aktiv sind und mehreren Zwecken dienen. In einigen Ausführungsformen wird ein Teil der Funktionalität eines Speicherknotens 150 in eine Speichereinheit 152 verlagert, wodurch die Speichereinheit 152 in eine Kombination aus Speichereinheit 152 und Speicherknoten 150 umgewandelt wird. Durch die Verlagerung von Berechnungen (relativ zu den Speicherdaten) in die Speichereinheit 152 wird diese Berechnung näher an die Daten selbst herangeführt. Die verschiedenen Systemausführungen haben eine Hierarchie von Speicherknotenschichten mit unterschiedlicher Tauglichkeit. Im Gegensatz dazu besitzt ein Controller in einem Speicher-Array alle Daten, die der Controller in einem Shelf oder in Speichergeräten verwaltet, und weiß alles über sie. In einem Storage-Cluster 161, wie hier beschrieben, arbeiten mehrere Controller in mehreren Speichereinheiten 152 und/oder Speicherknoten 150 auf verschiedene Weise zusammen (z.B. für Löschcodierung, Daten-Sharding, Metadatenkommunikation und -redundanz, Erweiterung oder Verkleinerung der Speicherkapazität, Datenwiederherstellung usw.).
  • 2D zeigt eine Speicherserverumgebung, die die Ausführungsformen der Speicherknoten 150 und Speichereinheiten 152 der 2A-C verwendet. In dieser Version verfügt jede Speichereinheit 152 über einen Prozessor wie z. B. einen Controller 212 (siehe 2C), ein FPGA (Field Programmable Gate Array), einen Flash-Speicher 206 und ein NVRAM 204 (bei dem es sich um ein DRAM 216 mit Superkondensator-Unterstützung handelt, siehe 2B und 2C) auf einer PCIe-Platine (Peripheral Component Interconnect Express) in einem Chassis 138 (siehe 2A). Die Speichereinheit 152 kann als einzelne Platine mit Speicher implementiert werden und stellt möglicherweise die größte tolerierbare Ausfalldomäne innerhalb des Chassis dar. In einigen Ausführungsformen können bis zu zwei Speichereinheiten 152 ausfallen, und das Gerät läuft ohne Datenverlust weiter.
  • Der physische Speicher ist in einigen Ausführungsformen auf der Grundlage der Anwendungsnutzung in benannte Regionen unterteilt. Das NVRAM 204 ist ein zusammenhängender Block von reserviertem Speicher in der Speichereinheit 152 DRAM 216 und wird durch NAND-Flash gesichert. Das NVRAM 204 ist logisch in mehrere Speicherregionen unterteilt, die für zwei als Spool geschrieben werden (z. B. spool_region). Der Platz innerhalb der NVRAM 204-Spools wird von jeder Authority 168 unabhängig verwaltet. Jedes Gerät stellt jeder Authority 168 eine bestimmte Menge an Speicherplatz zur Verfügung. Diese Authority 168 verwaltet außerdem die Lebensdauer und die Zuweisungen innerhalb dieses Speicherplatzes. Beispiele für einen Spool sind verteilte Transaktionen oder Begriffe. Wenn die Primärstromversorgung einer Speichereinheit 152 ausfällt, sorgen eingebaute Superkondensatoren für eine kurze Dauer des Stromausfalls. Während dieses Überbrückungsintervalls wird der Inhalt des NVRAM 204 in den Flash-Speicher 206 geleert. Beim nächsten Einschalten wird der Inhalt des NVRAM 204 aus dem Flash-Speicher 206 wiederhergestellt.
  • Was den Controller der Speichereinheit anbelangt, so ist die Verantwortung des logischen „Controllers“ auf die einzelnen Blades verteilt, welche Authorities 168 enthalten. Diese Verteilung der logischen Steuerung ist in 2D als Host-Controller 242, Mid-Tier-Controller 244 und Speichereinheit-Controller 246 dargestellt. Die Verwaltung der Steuerungsebene und der Speicherebene werden unabhängig voneinander behandelt, obwohl sich Teile physisch auf demselben Blade befinden können. Jede Authority 168 dient effektiv als unabhängiger Controller. Jede Authority 168 stellt ihre eigenen Daten- und Metadatenstrukturen und ihre eigenen Background-Worker bereit und unterhält ihren eigenen Lebenszyklus.
  • 2E ist ein Blade 252 - Hardware-Blockdiagramm, das eine Steuerungsebene 254, die Rechen- und Speicherebenen 256, 258 und die Authorities 168 zeigt, die mit den zugrunde liegenden physischen Ressourcen interagieren, wobei Ausführungsformen der Speicherknoten 150 und Speichereinheiten 152 der 2A-C in der Speicherserverumgebung von 2D verwendet werden. Die Steuerungsebene 254 ist in eine Reihe von Authorities 168 unterteilt, die die Rechenressourcen in der Rechenebene 256 verwenden können, um auf jedem der Blades 252 ausgeführt zu werden. Die Speicherebene 258 ist in eine Reihe von Geräten partitioniert, von denen jedes den Zugriff auf die Ressourcen von Flash 206 und NVRAM 204 ermöglicht. In einer Ausführung kann die Rechenebene 256 die hier beschriebenen Operationen eines Speicher-Array-Controllers auf einem oder mehreren Geräten der Speicherebene 258 (z.B. einem Speicher-Array) ausführen.
  • In den Rechen- und Speicherebenen 256, 258 der 2E interagieren die Authorities 168 mit den zugrunde liegenden physischen Ressourcen (d.h. den Geräten). Aus der Sicht einer Authority 168 sind ihre Ressourcen über alle physischen Geräte verteilt. Aus der Sicht eines Geräts stellt es allen Authorities 168 Ressourcen zur Verfügung, unabhängig davon, wo die Authorities gerade aktiv sind. Jede Authority 168 hat eine oder mehrere Partitionen 260 des Speicherplatzes in den Speichereinheiten 152 zugewiesen oder zugewiesen bekommen, z.B. Partitionen 260 im Flash-Speicher 206 und NVRAM 204. Jede Authority 168 verwendet die ihr zugewiesenen Partitionen 260, die ihr gehören, zum Schreiben oder Lesen von Benutzerdaten. Die Authorities können mit unterschiedlichen Mengen an physischem Speicher des Systems verbunden sein. Zum Beispiel könnte eine Authority 168 eine größere Anzahl von Partitionen 260 oder größere Partitionen 260 in einer oder mehreren Speichereinheiten 152 aufweisen als eine oder mehrere andere Authorities 168.
  • 2F zeigt Elastizitätssoftware-Schichten in Blades 252 eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen. In der Elastizitätsstruktur ist die Elastizitätssoftware symmetrisch, d.h. das Rechenmodul 270 jedes Blades führt die drei identischen Schichten der in 2F dargestellten Prozesse aus. Speichermanager 274 führen Lese- und Schreibanforderungen von anderen Blades 252 für Daten und Metadaten aus, die in der lokalen Speichereinheit 152 NVRAM 204 und im Flash 206 gespeichert sind. Authorities 168 erfüllen Client-Anforderungen, indem sie die erforderlichen Lese- und Schreibvorgänge auf die Blades 252 ausführen, auf deren Speichereinheiten 152 sich die entsprechenden Daten oder Metadaten befinden. Endpunkte 272 analysieren die von der Überwachungssoftware Switch Fabric 146 empfangenen Client-Verbindungsanfragen, leiten die Client-Verbindungsanfragen an die für die Erfüllung zuständigen Authorities 168 weiter und leiten die Antworten der Authorities 168 an die Clients weiter. Die symmetrische dreischichtige Struktur ermöglicht den hohen Grad an Gleichzeitigkeit des Speichersystems. Elastizität skaliert in diesen Ausführungsformen effizient und zuverlässig. Darüber hinaus implementiert Elastizität eine einzigartige Scale-Out-Technik, die die Arbeit unabhängig vom Client-Zugriffsmuster gleichmäßig auf alle Ressourcen verteilt und die Gleichzeitigkeit maximiert, indem sie einen Großteil der Koordination zwischen den einzelnen Blades überflüssig macht, die typischerweise bei herkömmlichen verteilten Sperren auftritt.
  • Unter Bezugnahme auf 2F führen die Authorities 168, die in den Rechenmodulen 270 eines Blades 252 laufen, die internen Operationen durch, die zur Erfüllung der Client-Anforderungen erforderlich sind. Ein Merkmal der Elastizität besteht darin, dass die Authorities 168 zustandslos sind, d. h. sie speichern aktive Daten und Metadaten in den 252 DRAMs ihrer eigenen Blades für einen schnellen Zugriff zwischen, aber die Authorities speichern jede Aktualisierung in ihren NVRAM 204-Partitionen auf drei separaten Blades 252, bis die Aktualisierung in dem Flash 206 geschrieben wurde. Alle Schreibzugriffe des Speichersystems auf NVRAM 204 erfolgen in einigen Ausführungsformen in dreifacher Ausführung auf Partitionen auf drei separaten Blades 252. Mit dreifach gespiegeltem NVRAM 204 und persistentem Speicher, der durch Parität und Reed-Solomon-RAID-Prüfsummen geschützt ist, kann das Speichersystem den gleichzeitigen Ausfall von zwei Blades 252 ohne Verlust von Daten, Metadaten oder Zugriff auf beide überleben.
  • Da Authorities 168 zustandslos sind, können sie zwischen den Blades 252 wechseln. Jede Authority 168 hat eine eindeutige Kennung. NVRAM 204- und Flash 206-Partitionen sind mit den Kennungen der Authorities 168 verknüpft, nicht mit den Blades 252, auf denen sie in manchen Fällen laufen. Wenn also eine Authority 168 migriert, verwaltet die Authority 168 weiterhin die gleichen Speicherpartitionen von ihrem neuen Standort aus. Wenn ein neues Blade 252 in einer Ausführungsform des Storage-Clusters installiert wird, gleicht das System die Last automatisch aus, indem es den Speicher des neuen Blades 252 für die Verwendung durch die Authority 168 des Systems partitioniert, ausgewählte Authorities 168 auf das neue Blade 252 migriert, Endpunkte 272 auf dem neuen Blade 252 beginnt und sie in den Verteilungsalgorithmus für Client-Verbindungen der Switch-Fabric 146 einbezieht.
  • Von ihren neuen Standorten aus lassen die migrierten Authorities 168 den Inhalt ihrer NVRAM 204 - Partitionen auf Flash 206 bestehen, verarbeiten Lese- und Schreibanforderungen anderer Authorities 168 und erfüllen die Client-Anforderungen, die die Endpunkte 272 direkt an sie richten. In ähnlicher Weise verteilt das System, wenn ein Blade 252 ausfällt oder entfernt wird, seine Authorities 168 unter den verbleibenden Blades 252 des Systems neu. Die neu verteilten Authorities 168 führen ihre ursprünglichen Funktionen von ihren neuen Standorten aus weiter aus.
  • 2G zeigt Authorities 168 und Speicherressourcen in Blades 252 eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen. Jede Authority 168 ist ausschließlich für eine Partition des Flash 206 und NVRAM 204 auf jedem Blade 252 verantwortlich. Die Authority 168 verwaltet den Inhalt und die Integrität ihrer Partitionen unabhängig von anderen Authorities 168. Die Authority 168 komprimiert eingehende Daten und bewahrt sie vorübergehend in ihren NVRAM 204-Partitionen auf. Anschließend werden die Daten konsolidiert, RAID-geschützt und in Segmenten des Speichers auf ihren Flash 206-Partitionen persistent gemacht. Während die Authorities 168 Daten in dem Flash 206 schreiben, führen Speicherverwalter 274 die notwendige Flash-Übersetzung durch, um die Schreibleistung zu optimieren und die Langlebigkeit der Medien zu maximieren. Im Hintergrund erfolgt die „Garbage Collection“ durch die Authorities 168 oder diese fordern Speicherplatz zurück, der von Daten belegt ist, die von Clients durch Überschreiben der Daten veraltet sind. Da die Partitionen der Authorities 168 disjunkt sind, sollte man sich darüber im Klaren sein, dass für das Ausführen von Client- und Schreibvorgängen oder für das Ausführen von Hintergrundfunktionen keine verteilte Sperre erforderlich ist.
  • Die hier beschriebenen Ausführungsformen können verschiedene Software-, Kommunikations- und/oder Netzwerkprotokolle verwenden. Darüber hinaus kann die Konfiguration der Hardware und/oder Software angepasst werden, um verschiedene Protokolle zu berücksichtigen. Beispielsweise können die Ausführungsformen Active Directory verwenden, ein datenbankbasiertes System, das Authentifizierungs-, Verzeichnis-, Richtlinien- und andere Dienste in einer WINDOWS™-Umgebung bereitstellt. In diesen Ausführungsformen ist LDAP (Lightweight Directory Access Protocol) ein Beispiel für ein Anwendungsprotokoll zum Abfragen und Ändern von Elementen in Verzeichnisdienstanbietern wie Active Directory. In einigen Ausführungsformen wird ein Network Lock Manager („NLM“) als eine Einrichtung verwendet, die in Zusammenarbeit mit dem Network File System („NFS“) arbeitet, um über ein Netzwerk eine Datei- und Datensatzsperre im Stil von System V zur Verfügung zu stellen. Das Server Message Block („SMB“)-Protokoll, von dem eine Version auch als Common Internet File System („CIFS“) bekannt ist, kann mit den hier besprochenen Speichersystemen integriert werden. SMP arbeitet als ein Netzwerkprotokoll auf Anwendungsebene, das typischerweise für den gemeinsamen Zugriff auf Dateien, Drucker und serielle Schnittstellen sowie für verschiedene Kommunikationen zwischen Knoten in einem Netzwerk verwendet wird. SMB bietet auch einen authentifizierten Interprozesskommunikationsmechanismus. AMAZON™ S3 (Simple Storage Service) ist ein Webdienst, der von Amazon Web Services angeboten wird, und die hier beschriebenen Systeme können über Webdienst-Schnittstellen (REST (Representational State Transfer), SOAP (Simple Object Access Protocol) und BitTorrent) mit Amazon S3 verbunden werden. Eine RESTful-API (Application Programming Interface) bricht eine Transaktion auf, um eine Reihe von kleinen Modulen zu erstellen. Jedes Modul spricht einen bestimmten zugrunde liegenden Teil der Transaktion an. Die Steuerung oder Berechtigungen, die mit diesen Ausführungsformen bereitgestellt werden, insbesondere für Objektdaten, können die Verwendung einer Zugriffskontrollliste („ACL“) einschließen. Die ACL ist eine Liste von Berechtigungen, die an ein Objekt angehängt ist, und die ACL legt fest, welchen Benutzern oder Systemprozessen der Zugriff auf Objekte gewährt wird und welche Operationen auf gegebenen Objekten erlaubt sind. Die Systeme können sowohl das Internet-Protokoll Version 6 („IPv6“) als auch IPv4 für das Kommunikationsprotokoll verwenden, das ein Identifikations- und Ortungssystem für Computer in Netzwerken bereitstellt und den Verkehr über das Internet leitet. Das Routing von Paketen zwischen vernetzten Systemen kann das Equal-cost Multi-Path-Routing („ECMP“) umfassen, eine Routing-Strategie, bei der die Weiterleitung von Paketen auf dem nächsten Sprung zu einem einzelnen Ziel über mehrere „beste Pfade“ erfolgen kann, die bei metrischen Routing-Berechnungen den ersten Platz belegen. Multi-Path-Routing kann in Verbindung mit den meisten Routing-Protokollen verwendet werden, da es eine auf einen einzelnen Router beschränkte Entscheidung pro Hop ist. Die Software kann Multi-Tenancy unterstützen, d.h. eine Architektur, in der eine einzelne Instanz einer Software-Anwendung mehrere Kunden bedient. Jeder Client kann als Tenant bezeichnet werden. Tenants kann die Möglichkeit gegeben werden, einige Teile der Anwendung anzupassen, aber in einigen Ausführungsformen kann der Code der Anwendung nicht angepasst werden. Die Ausführungsformen können Audit-Protokolle führen. Ein Audit-Protokoll ist ein Dokument, das ein Ereignis in einem Computersystem aufzeichnet. Neben der Dokumentation, auf welche Ressourcen zugegriffen wurde, enthalten Audit-Protokolleinträge in der Regel Ziel- und Quelladressen, einen Zeitstempel und Benutzeranmeldeinformationen zur Einhaltung verschiedener Vorschriften. Die Ausführungsformen können verschiedene Schlüsselverwaltungsrichtlinien unterstützen, wie z.B. die Schlüsselrotation bei der Verschlüsselung. Darüber hinaus kann das System dynamische Root-Passwörter oder einige Variationen sich dynamisch ändernder Passwörter unterstützen.
  • 3A zeigt ein Diagramm eines Speichersystems 306, das für die Datenkommunikation mit einem Cloud-Service-Anbieter 302 gemäß einigen Ausführungsformen der vorliegenden Offenbarung gekoppelt ist. Obwohl es weniger detailliert dargestellt ist, kann das in 3A gezeigte Speichersystem 306 den oben mit Bezug auf die 1A-1D und 2A-2G beschriebenen Speichersystemen ähnlich sein. In einigen Ausführungsformen kann das in 3A gezeigte Speichersystem 306 als ein Speichersystem dargestellt werden mit unsymmetrischen aktiven/aktiven Controllern, als ein Speichersystem mit symmetrischen aktiven/aktiven Controllern, als ein Speichersystem mit aktiven/aktiven Controllern, bei dem weniger als alle Ressourcen jedes Controllers genutzt werden, so dass jeder Controller über Reserveressourcen verfügt, die zur Unterstützung der Ausfallsicherung verwendet werden können, als Speichersystem mit vollständig aktiven/aktiven Controllern, als Speichersystem mit datensatzgetrennten Controllern, als Speichersystem mit Dual-Layer-Architekturen mit Front-End-Controllern und integrierten Back-End-Speicher-Controllern, als Speichersystem mit Scale-Out-Clustern aus Dual-Controller-Arrays sowie Kombinationen solcher Ausführungsformen.
  • In dem in 3A dargestellten Beispiel ist das Speichersystem 306 über eine Datenkommunikationsverbindung 304 an den Cloud-Service-Anbieter 302 gekoppelt. Die Datenkommunikationsverbindung 304 kann ausgeführt sein als eine dedizierte Datenkommunikationsverbindung, als ein Datenkommunikationsweg, der durch die Verwendung eines oder mehrerer Datenkommunikationsnetze wie eines Wide Area Network („WAN“) oder eines lokalen Netzwerks („LAN“) bereitgestellt wird, oder als ein anderer Mechanismus, der digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 transportieren kann. Eine solche Datenkommunikationsverbindung 304 kann vollständig verdrahtet, vollständig drahtlos oder eine gewisse Aggregation von verdrahteten und drahtlosen Datenkommunikationswegen sein. In einem solchen Beispiel können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung eines oder mehrerer Datenkommunikationsprotokolle ausgetauscht werden. Beispielsweise können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung des Handheld Device Transfer Protocol („HDTP“), des Hypertext Transfer Protocol (‚HTTP‘), Internet Protocol (‚IP‘), Real-Time Transfer Protocol (‚RTP‘), Transmission Control Protocol (‚TCP‘), User Datagram Protocol (‚UDP‘), Wireless Application Protocol (‚WAP‘), oder anderer Protokolle ausgetauscht werden.
  • Der in 3A dargestellte Cloud-Service-Anbieter 302 kann beispielsweise als ein System und eine Rechenumgebung verkörpert werden, die den Nutzern des Cloud-Service-Anbieters 302 Dienste durch die gemeinsame Nutzung von Rechenressourcen über die Datenkommunikationsverbindung 304 bereitstellt. Der Cloud-Service-Anbieter 302 kann bei Bedarf Zugriff auf einen gemeinsamen Pool konfigurierbarer Computing-Ressourcen wie Computernetzwerke, Server, Speicher, Anwendungen und Dienste usw. bereitstellen. Der gemeinsame Pool konfigurierbarer Ressourcen kann schnell und mit minimalem Verwaltungsaufwand für einen Benutzer des Cloud-Service-Anbieters 302 bereitgestellt und freigegeben werden. Im Allgemeinen ist dem Benutzer des Cloud-Service-Anbieters 302 nicht bekannt, welche genauen Computing-Ressourcen der Cloud-Service-Anbieter 302 für die Bereitstellung der Dienste verwendet. Obwohl in vielen Fällen ein solcher Cloud-Service-Anbieter 302 über das Internet zugänglich sein kann, werden diejenigen, die im Fachgebiet erfahren sind, erkennen, dass jedes System, das die Nutzung gemeinsam genutzter Ressourcen zur Bereitstellung von Diensten für einen Benutzer über eine beliebige Datenkommunikationsverbindung abstrahiert, als Cloud-Service-Anbieter 302 betrachtet werden kann.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 durch die Implementierung verschiedener Dienstmodelle eine Vielzahl von Diensten zur Verfügung stellt. Beispielsweise kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Infrastructure-as-a-Service“ („laaS“) - Servicemodells bereitstellt, bei dem der Cloud-Service-Anbieter 302 Recheninfrastruktur wie virtuelle Maschinen und andere Ressourcen als Dienst für Abonnenten anbietet. Darüber hinaus kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Platform-as-a-Service“ („PaaS“) - Servicemodells anbietet, bei dem der Cloud-Service-Anbieter 302 Anwendungsentwicklern eine Entwicklungsumgebung zur Verfügung stellt. Eine solche Entwicklungsumgebung kann z.B. ein Betriebssystem, eine Ausführungsumgebung für die Programmiersprache, eine Datenbank, einen Webserver oder andere Komponenten umfassen, die von Anwendungsentwicklern zur Entwicklung und zum Betrieb von Softwarelösungen auf einer Cloud-Plattform verwendet werden können. Darüber hinaus kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Software-as-a-Service“ („SaaS“)-Servicemodells bereitstellt, bei dem der Cloud-Service-Anbieter 302 Anwendungssoftware und Datenbanken anbietet, sowie die Plattformen, die für die Ausführung der Anwendungen für das Speichersystem 306 und die Benutzer des Speichersystems 306 verwendet werden, wodurch das Speichersystem 306 und die Benutzer des Speichersystems 306 mit On-Demand-Software versorgt werden und die Notwendigkeit entfällt, die Anwendung auf lokalen Computern zu installieren und auszuführen, was die Handhabung und Unterstützung der Anwendung vereinfachen kann. Der Cloud-Service-Anbieter 302 kann darüber hinaus so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Dienste zur Verfügung stellt, indem er ein „Authentication-as-a-Service“ („AaaS“) - Servicemodell implementiert, bei dem der Cloud-Service-Anbieter 302 Authentifizierungsdienste anbietet, die zur Sicherung des Zugriffs auf Anwendungen, Datenquellen oder andere Ressourcen verwendet werden können. Der Cloud-Services-Anbieter 302 kann auch so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Storage-as-a-Service“-Modells anbietet, bei dem der Cloud-Services-Anbieter 302 Zugang zu seiner Speicherinfrastruktur zur Nutzung durch das Speichersystem 306 und den Benutzer des Speichersystems 306 anbietet. Für den Leser ist zu erkennen, dass der Cloud-Service-Anbieter 302 so konfiguriert werden kann, dass er dem Speichersystem 306 und den Nutzern des Speichersystems 306 durch die Implementierung zusätzlicher Servicemodelle zusätzliche Dienste zur Verfügung stellt, da die vorstehend beschriebenen Servicemodelle nur zu Erklärungszwecken enthalten sind und in keiner Weise eine Einschränkung der Dienste, die vom Cloud-Service-Anbieter 302 angeboten werden können, oder eine Beschränkung hinsichtlich der Servicemodelle, die vom Cloud-Service-Anbieter 302 implementiert werden können, darstellen.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Service-Anbieter 302 beispielsweise als Private Cloud, als Public Cloud oder als eine Kombination aus Private Cloud und Public Cloud verkörpert sein. In einer Ausführungsform, in welcher der Cloud-Service-Anbieter 302 als Private Cloud verkörpert ist, kann der Cloud-Service-Anbieter 302 sich der Bereitstellung von Diensten für eine einzelne Organisation widmen, anstatt Dienste für mehrere Organisationen bereitzustellen. In einer Ausführungsform, in der der Cloud-Service-Anbieter 302 als Public Cloud verkörpert ist, kann der Cloud-Service-Anbieter 302 Dienste für mehrere Organisationen bereitstellen. Public Cloud- und Private Cloud-Bereitstellungsmodelle können sich unterscheiden und mit verschiedenen Vor- und Nachteilen verbunden sein. Da eine Bereitstellung in einer Public Cloud beispielsweise die gemeinsame Nutzung einer Computerinfrastruktur durch verschiedene Organisationen beinhaltet, ist eine solche Bereitstellung möglicherweise nicht ideal für Organisationen mit Sicherheitsbedenken, geschäftskritischen Arbeitslasten, Anforderungen an die Betriebszeit usw. Während eine Private Cloud-Bereitstellung einige dieser Probleme lösen kann, erfordert eine Private Cloud-Bereitstellung möglicherweise Personal vor Ort, um die Private Cloud zu verwalten. In noch alternativen Ausführungsformen kann der Cloud-Service-Anbieter 302 als eine Mischung aus Private Cloud- und Public Cloud-Diensten mit einer hybriden Cloud-Bereitstellung dargestellt werden.
  • Obwohl in 3A nicht explizit gezeigt, werden die Leser erkennen, dass zusätzliche Hardwarekomponenten und zusätzliche Softwarekomponenten erforderlich sein können, um die Bereitstellung von Cloud-Diensten für das Speichersystem 306 und die Benutzer des Speichersystems 306 zu erleichtern. Beispielsweise kann das Speichersystem 306 an ein Cloud-Storage-Gateway gekoppelt sein (oder sogar ein solches enthalten). Ein solches Cloud-Storage-Gateway kann z. B. als hardware- oder softwarebasierte Vorrichtung ausgeführt werden, die sich zusammen mit dem Speichersystem 306 vor Ort befindet. Ein solches Cloud-Storage-Gateway kann als Brücke zwischen lokalen Anwendungen, die auf dem Speicher-Array 306 ausgeführt werden, und einem entfernten, cloudbasierten Speicher fungieren, der vom Speicher-Array 306 genutzt wird. Durch die Verwendung eines Cloud-Storage-Gateways können Unternehmen primäre iSCSI- oder NAS-Systeme zum Cloud-Service-Anbieter 302 verlagern, wodurch das Unternehmen auf seinen lokalen Speichersystemen Platz sparen kann. Ein solches Cloud-Storage-Gateway kann so konfiguriert werden, dass es ein Disk-Array, ein blockbasiertes Gerät, einen Dateiserver oder ein anderes Speichersystem emuliert, das die SCSI-Befehle, Dateiserver-Befehle oder andere geeignete Befehle in REST-Space-Protokolle übersetzt, die die Kommunikation mit dem Cloud-Service-Anbieter 302 erleichtern.
  • Damit das Speichersystem 306 und die Benutzer des Speichersystems 306 die vom Cloud-Service-Anbieter 302 bereitgestellten Dienste nutzen können, kann ein Cloud-Migrationsprozess stattfinden, bei dem Daten, Anwendungen oder andere Elemente aus den lokalen Systemen einer Organisation (oder sogar aus einer anderen Cloud-Umgebung) zum Cloud-Service-Anbieter 302 verschoben werden. Um Daten, Anwendungen oder andere Elemente erfolgreich in die Umgebung des Cloud-Service-Anbieters 302 zu migrieren, kann Middleware wie z. B. ein Cloud-Migrationstool verwendet werden, um Lücken zwischen der Umgebung des Cloud-Service-Anbieters 302 und der Umgebung einer Organisation zu überbrücken. Solche Cloud-Migrationstools können auch so konfiguriert werden, dass sie potenziell hohe Netzwerkkosten und lange Übertragungszeiten, die mit der Migration großer Datenmengen zum Cloud-Service-Anbieter 302 verbunden sind, sowie Sicherheitsbedenken im Zusammenhang mit sensiblen Daten zum Cloud-Service-Anbieter 302 über Datenkommunikationsnetzwerke berücksichtigen. Um das Speichersystem 306 und die Benutzer des Speichersystems 306 in die Lage zu versetzen, die vom Cloud-Service-Anbieter 302 bereitgestellten Dienste zu nutzen, kann ein Cloud-Orchestrator auch zur Anordnung und Koordinierung automatisierter Aufgaben im Hinblick auf die Schaffung eines konsolidierten Prozesses oder Workflows eingesetzt werden. Ein solcher Cloud-Orchestrator kann Aufgaben wie die Konfiguration verschiedener Komponenten durchführen, unabhängig davon, ob es sich bei diesen Komponenten um Cloud-Komponenten oder Komponenten vor Ort handelt, sowie die Verwaltung der Verbindungen zwischen diesen Komponenten. Der Cloud-Orchestrator kann die Kommunikation und die Verbindungen zwischen den Komponenten vereinfachen, um sicherzustellen, dass die Verbindungen korrekt konfiguriert und gewartet werden.
  • In dem in 3A dargestellten Beispiel und wie oben kurz beschrieben, kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Verwendung eines SaaS-Servicemodells bereitstellt, bei dem der Cloud-Service-Anbieter 302 Anwendungssoftware und Datenbanken anbietet, sowie die Plattformen, die für die Ausführung der Anwendungen für das Speichersystem 306 und die Benutzer des Speichersystems 306 verwendet werden, wodurch das Speichersystem 306 und die Benutzer des Speichersystems 306 mit Software auf Abruf versorgt werden und die Notwendigkeit entfällt, die Anwendung auf lokalen Computern zu installieren und auszuführen, was die Handhabung und Unterstützung der Anwendung vereinfachen kann. Solche Anwendungen können viele Formen in Übereinstimmung mit verschiedenen Ausführungsformen der vorliegenden Offenbarung annehmen. Zum Beispiel kann der Cloud-Service-Anbieter 302 so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Zugang zu Datenanalyseanwendungen gewährt. Solche Datenanalyseanwendungen können z.B. so konfiguriert werden, dass sie Telemetriedaten empfangen, die vom Speichersystem 306 „nach Hause telefoniert werden“. Solche Telemetriedaten können verschiedene Betriebseigenschaften des Speichersystems 306 beschreiben und können analysiert werden, um z.B. den Zustand des Speichersystems 306 zu bestimmen, um Arbeitslasten zu ermitteln, die auf dem Speichersystem 306 ausgeführt werden, um vorherzusagen, wann dem Speichersystem 306 die verschiedenen Ressourcen ausgehen werden, um Konfigurationsänderungen, Hardware- oder Software-Upgrades, Workflow-Migrationen oder andere Aktionen zu empfehlen, die den Betrieb des Speichersystems 306 verbessern können.
  • Der Cloud-Service-Anbieter 302 kann auch so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Zugang zu virtualisierten Computerumgebungen bietet. Solche virtualisierten Datenverarbeitungsumgebungen können z.B. als virtuelle Maschine oder andere virtualisierte Computer-Hardwareplattformen, virtuelle Speichergeräte, virtualisierte Computernetzwerk-Ressourcen usw. verkörpert sein. Beispiele für solche virtualisierten Umgebungen können virtuelle Maschinen sein, die erstellt werden, um einen tatsächlichen Computer zu emulieren, virtualisierte Desktop-Umgebungen, die einen logischen Desktop von einer physischen Maschine trennen, virtualisierte Dateisysteme, die einen einheitlichen Zugriff auf verschiedene Arten konkreter Dateisysteme ermöglichen, und vieles andere.
  • Zur weiteren Erläuterung ist in 3B ein Diagramm eines Speichersystems 306 in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung dargestellt. Obwohl es weniger detailliert dargestellt ist, kann das in 3B dargestellte Speichersystem 306 den oben mit Bezug auf die 1A-1D und 2A-2G beschriebenen Speichersystemen ähnlich sein, da das Speichersystem viele der vorstehend beschriebenen Komponenten enthalten kann.
  • Das in 3B dargestellte Speichersystem 306 kann die Speicherressourcen 308 enthalten, die in vielen Formen verkörpert sein können. Zum Beispiel können die Speicherressourcen 308 in einigen Ausführungsformen Nano-RAM oder eine andere Form von nichtflüchtigem Speicher mit wahlfreiem Zugriff enthalten, der auf einem Substrat abgeschiedene Kohlenstoff-Nanoröhren verwendet. In einigen Ausführungsformen können die Speicherressourcen 308 einen nichtflüchtigen 3D-Kreuzpunkt-Speicher umfassen, bei dem die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert, in Verbindung mit einem stapelbaren Kreuzgitter-Datenzugriffsarray. In einigen Ausführungsformen können die Speicherressourcen 308 Flash-Speicher umfassen, einschließlich Single-Level Cell (‚SLC‘) NAND Flash, Multi-Level Cell (‚MLC‘) NAND Flash, Triple-Level Cell (‚TLC‘) NAND Flash, Quad-Level Cell (‚QLC‘) NAND Flash und andere. In einigen Ausführungsformen können die Speicherressourcen 308 nichtflüchtige magnetoresistive Speicher mit wahlfreiem Zugriff („MRAM“) einschließlich Spin-Transfer-Drehmoment („STT“) MRAM umfassen, in denen Daten durch die Verwendung von magnetischen Speicherelementen gespeichert werden. In einigen Ausführungsformen kann das Beispiel der Speicherressourcen 308 einen nichtflüchtigen Phasenänderungsspeicher („PCM“) enthalten, der die Fähigkeit haben kann, mehrere Bits in einer einzigen Zelle zu halten, da Zellen eine Reihe von unterschiedlichen Zwischenzuständen erreichen können. In einigen Ausführungsformen können die Speicherressourcen 308 einen Quantenspeicher enthalten, der Speichern und den Abruf von photonischer Quanteninformation ermöglicht. In einigen Ausführungsformen können die Speicherressourcen 308 beispielsweise einen resistiven Speicher mit wahlfreiem Zugriff (‚ReRAM‘) enthalten, in dem Daten durch Änderung des Widerstands über ein dielektrisches Festkörpermaterial gespeichert werden. In einigen Ausführungsformen können die Speicherressourcen 308 Storage Class Memories („SCM“) enthalten, in denen nichtflüchtige Festkörperspeicher mit hoher Dichte unter Verwendung einer Kombination aus sublithographischen Musterungsverfahren, mehreren Bits pro Zelle, mehreren Schichten von Bauelementen usw. hergestellt werden können. Für den Leser ist zu erkennen, dass andere Formen von Computerspeichern und Speichergeräten von den vorstehend beschriebenen Speichersystemen verwendet werden können, einschließlich DRAM, SRAM, EEPROM, Universal Memory und viele andere. Die in 3A dargestellten Speicherressourcen 308 können in einer Vielzahl von Formfaktoren ausgeführt sein, einschließlich, aber nicht beschränkt auf, Dual-In-Line-Speichermodule („DIMMs“), nichtflüchtige Dual-In-Line-Speichermodule („NVDIMMs“), M.2, U.2 und andere.
  • Die in 3A dargestellten Speicherressourcen 308 können verschiedene Formen des Speicherklassenspeichers („SCM“) umfassen. SCM kann einen schnellen, nichtflüchtigen Speicher (z. B. NAND-Flash) effektiv als eine Erweiterung von DRAM behandeln, so dass ein gesamter Datensatz als ein In-Memory-Datensatz behandelt werden kann, der sich vollständig im DRAM befindet. Ein SCM kann nichtflüchtige Medien, wie z. B. einen NAND-Flash, umfassen. Auf ein solches NAND-Flash kann mit NVMe zugegriffen werden, das den PCIe-Bus als Transportmittel verwenden kann, wodurch im Vergleich zu älteren Protokollen relativ geringe Zugriffslatenzen entstehen. Tatsächlich können die für SSDs in All-Flash-Arrays verwendeten Netzwerkprotokolle NVMe unter Verwendung von Ethernet (ROCE, NVME TCP), Fibre Channel (NVMe FC), InfiniBand (iWARP) und anderen Protokollen umfassen, die es ermöglichen, schnelle, nichtflüchtige Speicher als Erweiterung von DRAM zu behandeln. Angesichts der Tatsache, dass DRAM häufig Byte-adressierbar ist und schneller, nichtflüchtiger Speicher wie NAND-Flash blockadressierbar ist, kann ein Controller-Software-/Hardware-Stack erforderlich sein, um die Blockdaten in die auf den Medien gespeicherten Bytes zu konvertieren. Beispiele für Medien und Software, die als SCM verwendet werden können, sind z.B. 3D XPoint, Intel Memory Drive Technology, Z-SSD von Samsung und andere.
  • Das in 3B dargestellte Beispielspeichersystem 306 kann eine Vielzahl von Speicherarchitekturen implementieren. Beispielsweise können Speichersysteme in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung Blockspeicher verwenden, bei denen Daten in Blöcken gespeichert werden und jeder Block im Wesentlichen als individuelle Festplatte fungiert. Speichersysteme in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung können Objektspeicher nutzen, bei denen Daten als Objekte verwaltet werden. Jedes Objekt kann die Daten selbst, eine variable Menge von Metadaten und eine global eindeutige Kennung enthalten, wobei die Objektspeicher auf mehreren Ebenen (z.B. Geräteebene, Systemebene, Schnittstellenebene) implementiert werden können. Speichersysteme in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung verwenden Dateispeicher, in denen Daten in einer hierarchischen Struktur gespeichert werden. Solche Daten können in Dateien und Ordnern gespeichert und dem System, das sie speichert, und dem System, das sie abruft, im gleichen Format präsentiert werden.
  • Das in 3B dargestellte Beispielspeichersystem 306 kann als ein Speichersystem verkörpert werden, in dem zusätzliche Speicherressourcen hinzugefügt werden können durch die Verwendung eines Scale-Up-Modells, durch die Verwendung eines Scale-Out-Modells oder durch eine Kombination davon. In einem Scale-Up-Modell kann zusätzlicher Speicher durch Hinzufügen zusätzlicher Speichergeräte hinzugefügt werden. In einem Scale-Out-Modell jedoch können zusätzliche Speicherknoten zu einem Cluster von Speicherknoten hinzugefügt werden, wobei solche Speicherknoten zusätzliche Verarbeitungsressourcen, zusätzliche Netzwerkressourcen usw. enthalten können.
  • Das in 3B dargestellte Speichersystem 306 enthält auch Kommunikationsressourcen 310, die nützlich sein können bei der Erleichterung der Datenkommunikation zwischen Komponenten innerhalb des Speichersystems 306 sowie der Datenkommunikation zwischen dem Speichersystem 306 und Datenverarbeitungsgeräten, die sich außerhalb des Speichersystems 306 befinden. Die Kommunikationsressourcen 310 können so konfiguriert werden, dass sie eine Vielzahl verschiedener Protokolle und Datenkommunikationsstrukturen nutzen, um die Datenkommunikation zwischen Komponenten innerhalb des Speichersystems sowie zwischen dem Speichersystem 306 und Datenverarbeitungsgeräten außerhalb des Speichersystems 306 zu erleichtern. Beispielsweise können die Kommunikationsressourcen 310 Fibre-Channel („FC“) - Technologien wie FC-Fabrics und FC-Protokolle umfassen, welche SCSI-Befehle über FC-Netzwerke transportieren können. Die Kommunikationsressourcen 310 können auch FCüber-Ethernet („FCoE“) - Technologien umfassen, durch die FC-Frames gekapselt und über Ethernet-Netzwerke übertragen werden. Die Kommunikationsressourcen 310 können auch InfiniBand-Technologien („IB“) umfassen, bei denen eine Switched-Fabric-Topologie verwendet wird, um Übertragungen zwischen Channel Adaptern zu erleichtern. Die Kommunikationsressourcen 310 können auch NVM Express („NVMe“) - Technologien und NVMe over Fabrics („NVMeoF“) - Technologien umfassen, über die auf nichtflüchtige Speichermedien zugegriffen werden kann, die über einen PCI Express („PCle“) - Bus angeschlossen sind. Zu den Kommunikationsressourcen 310 können auch Mechanismen für den Zugriff auf Speicherressourcen 308 innerhalb des Speichersystems 306 gehören, die Serial Attached SCSI (‚SAS‘), Serial ATA (‚SATA‘) Busschnittstellen für die Verbindung von Speicherressourcen 308 innerhalb des Speichersystems 306 mit Host-Busadaptern innerhalb des Speichersystems 306 verwenden, Internet Small Computer Systems Interface („iSCSI“)-Technologien, um den Zugriff auf Speicherressourcen 308 innerhalb des Speichersystems 306 auf Blockebene zu ermöglichen, und andere Kommunikationsressourcen, die zur Erleichterung der Datenkommunikation zwischen Komponenten innerhalb des Speichersystems 306 sowie der Datenkommunikation zwischen dem Speichersystem 306 und Datenverarbeitungsgeräten außerhalb des Speichersystems 306 nützlich sein können.
  • Das in 3B dargestellte Speichersystem 306 enthält auch Verarbeitungsressourcen 312, die bei der Ausführung von Computerprogrammbefehlen und anderen Rechenaufgaben innerhalb des Speichersystems 306 nützlich sein können. Die Verarbeitungsressourcen 312 können eine oder mehrere anwendungsspezifische integrierte Schaltungen („ASICs“), die für einen bestimmten Zweck angepasst sind, sowie eine oder mehrere Zentraleinheiten („CPUs“) enthalten. Die Verarbeitungsressourcen 312 können auch einen oder mehrere digitale Signalprozessoren („DSPs“), ein oder mehrere feldprogrammierbare Gate-Arrays („FPGAs“), ein oder mehrere Ein-Chip-Systeme („SoCs“) oder eine andere Form von Verarbeitungsressourcen 312 umfassen. Das Speichersystem 306 kann die Speicherressourcen 312 nutzen, um eine Vielzahl von Aufgaben auszuführen, einschließlich, aber nicht beschränkt auf die Unterstützung der Ausführung der Software-Ressourcen 314, die weiter unten ausführlicher beschrieben werden.
  • Das in 3B dargestellte Speichersystem 306 enthält auch die Software-Ressourcen 314, die bei der Ausführung durch die Verarbeitungsressourcen 312 innerhalb des Speichersystems 306 verschiedene Aufgaben ausführen können. Die Software-Ressourcen 314 können z.B. ein oder mehrere Module von Computerprogrammbefehlen enthalten, die, wenn sie von der Verarbeitungsressource 312 innerhalb des Speichersystems 306 ausgeführt werden, bei der Durchführung verschiedener Datensicherungsverfahren nützlich sind, um die Integrität der in den Speichersystemen gespeicherten Daten zu erhalten. Für den Leser ist zu erkennen, dass solche Datensicherungsverfahren z.B. durch Systemsoftware, die auf Computerhardware innerhalb des Speichersystems ausgeführt wird, durch einen Cloud-Service-Anbieter oder auf andere Weise durchgeführt werden können. Solche Datensicherungsverfahren können z.B. Datenarchivierungsverfahren umfassen, die dazu führen, dass Daten, die nicht mehr aktiv genutzt werden, auf ein separates Speichergerät oder ein separates Speichersystem zur langfristigen Aufbewahrung verschoben werden, Datensicherungsverfahren, durch das im Speichersystem gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um Datenverluste im Falle eines Geräteausfalls oder einer anderen Form der Katastrophe mit dem Speichersystem zu vermeiden, Datenreplizierungsverfahren, durch das im Speichersystem gespeicherte Daten auf ein anderes Speichersystem repliziert werden, so dass die Daten über mehrere Speichersysteme zugänglich sind, Daten-Snapshot-Verfahren, durch das der Zustand der Daten innerhalb des Speichersystems zu verschiedenen Zeitpunkten erfasst wird, Daten- und Datenbank-Cloning-Verfahren, durch welche Duplikate von Daten und Datenbanken erstellt werden können, und andere Datensicherungsverfahren. Durch den Einsatz solcher Datensicherungsverfahren können die Ziele der Business Continuity und der Disaster-Recovery-Ziele erreicht werden, da ein Ausfall des Speichersystems nicht zum Verlust der im Speichersystem gespeicherten Daten führen kann.
  • Die Software-Ressourcen 314 können auch Software enthalten, die bei der Implementierung von software-definierter Speicherung (‚SDS‘) nützlich ist. In einem solchen Beispiel können die Software-Ressourcen 314 ein oder mehrere Module von Computerprogrammbefehlen enthalten, die, wenn sie ausgeführt werden, bei der richtlinienbasierten Bereitstellung und Verwaltung von Datenspeicherung, die unabhängig von der zugrunde liegenden Hardware ist, nützlich sind. Solche Software-Ressourcen 314 können bei der Implementierung von Speichervirtualisierung nützlich sein, um die Speicherhardware von der Software zu trennen, welche die Speicherhardware verwaltet.
  • Die Software-Ressourcen 314 können auch Software enthalten, die zur Erleichterung und Optimierung von E/A-Operationen nützlich ist, die auf die Speicherressourcen 308 im Speichersystem 306 gerichtet sind. Die Software-Ressourcen 314 können beispielsweise Softwaremodule enthalten, die verschiedene Datenreduzierungsverfahren ausführen, wie z. B. Datenkomprimierung, Datendeduplizierung und andere. Die Software-Ressourcen 314 können Softwaremodule enthalten, die E/A-Operationen intelligent gruppieren, um eine bessere Nutzung der zugrunde liegenden Speicherressource 308 zu ermöglichen, Softwaremodule, die Datenmigrationsoperationen zur Migration von innerhalb eines Speichersystems durchführen, sowie Softwaremodule, die andere Funktionen ausführen. Solche Software-Ressourcen 314 können als ein oder mehrere Software-Container oder auf viele andere Arten verkörpert sein.
  • Für den Leser ist zu erkennen, dass das Vorhandensein solcher Software-Ressourcen 314 für eine verbesserte Benutzerfreundlichkeit des Speichersystems 306, für eine Erweiterung der vom Speichersystem 306 unterstützten Funktionalität und für viele andere Vorteile sorgen kann. Betrachten wir ein Beispiel der Software-Ressourcen 314, welche Datensicherungsverfahren durchführen, mit denen im Speichersystem 314 gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um Datenverluste im Falle eines Geräteausfalls oder einer anderen Art von Katastrophe zu vermeiden. In einem solchen Beispiel können die hier beschriebenen Systeme zuverlässiger (und mit weniger Belastung für den Benutzer) Sicherungsvorgänge im Vergleich zu interaktiven Sicherungsverwaltungssystemen durchführen, die ein hohes Maß an Benutzerinteraktivität erfordern, weniger robuste Automatisierung und Funktionssätze bieten usw.
  • Die vorstehend beschriebenen Speichersysteme können intelligente Datensicherungstechniken durchführen, durch die im Speichersystem gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um einen Datenverlust im Falle eines Geräteausfalls oder einer anderen Form von Unglücksfall zu vermeiden. Die oben beschriebenen Speichersysteme können beispielsweise so konfiguriert werden, dass sie jedes Backup prüfen, um zu verhindern, dass das Speichersystem in einen unerwünschten Zustand zurückversetzt wird. Nehmen wir ein Beispiel, bei dem das Speichersystem durch Schadsoftware infiziert wird. In einem solchen Beispiel kann das Speichersystem Softwareressourcen 314 enthalten, die jedes Backup scannen können, um Backups zu identifizieren, die vor dem Infizieren des Speichersystems durch die Malware aufgezeichnet wurden, und solche, die nach dem Infizieren des Speichersystems durch die Malware aufgezeichnet wurden. In einem solchen Beispiel kann das Speichersystem sich selbst aus einem Backup wiederherstellen, das die Schadsoftware nicht enthält - oder zumindest nicht die Teile eines Backups wiederherstellen, die die Schadsoftware enthielten. In einem solchen Beispiel kann das Speichersystem Software-Ressourcen 314 enthalten, die jedes Backup scannen können, um das Vorhandensein von Schadsoftware (oder eines Virus oder einer anderen unerwünschten Substanz) zu identifizieren, z. B. durch das Identifizieren von Schreiboperationen, die vom Speichersystem gehandhabt wurden und aus einem Netzwerk-Subnetz stammen, von dem vermutet wird, dass es die Schadsoftware geliefert hat, durch das Identifizieren von Schreibvorgängen, die vom Speichersystem gehandhabt wurden und von einem Benutzer stammen, bei dem der Verdacht besteht, dass er die Schadsoftware übertragen hat, durch das Identifizieren von Schreibvorgängen, die vom Speichersystem gehandhabt wurden, und das Untersuchen des Inhalts der Schreiboperation anhand von Fingerabdrücken der Schadsoftware und auf viele andere Arten.
  • Für den Leser wird verständlich sein, dass die Backups (oft in Form von einem oder mehreren Snapshots) auch zur schnellen Wiederherstellung des Speichersystems verwendet werden können. Nehmen wir ein Beispiel, bei dem das Speichersystem mit Ransomware infiziert ist, die die Benutzer aus dem Speichersystem aussperrt. In einem solchen Beispiel können die Softwareressourcen 314 innerhalb des Speichersystems so konfiguriert sein, dass sie das Vorhandensein von Ransomware erkennen und das Speichersystem unter Verwendung der gespeicherten Backups auf einen Zeitpunkt wiederherstellen, vor dem Zeitpunkt, zu dem die Ransomware das Speichersystem infiziert hat. In einem solchen Beispiel kann das Vorhandensein von Ransomware explizit durch die Verwendung von Softwaretools, die von dem System genutzt werden, durch die Verwendung eines Schlüssels (z. B. eines USB-Laufwerks), der in das Speichersystem eingeführt wird, oder auf ähnliche Weise erkannt werden. Ebenso kann auf das Vorhandensein von Ransomware geschlossen werden, wenn die Systemaktivität einem vorgegebenen Fingerabdruck entspricht, z. B. wenn über einen bestimmten Zeitraum keine Lese- oder Schreibvorgänge in das System gelangen.
  • Der Leser wird verstehen, dass die verschiedenen in 3B dargestellten Komponenten zu einem oder mehreren optimierten Datenverarbeitungspaketen als konvergierte Infrastrukturen zusammengefasst werden können. Solche konvergierten Infrastrukturen können Pools von Computern, Speicher- und Netzwerkressourcen umfassen, die von mehreren Anwendungen gemeinsam genutzt und mit Hilfe von richtliniengesteuerten Prozessen kollektiv verwaltet werden können. Solche konvergierten Infrastrukturen können Kompatibilitätsprobleme zwischen verschiedenen Komponenten innerhalb des Speichersystems 306 minimieren und gleichzeitig verschiedene Kosten im Zusammenhang mit der Einrichtung und dem Betrieb des Speichersystems 306 reduzieren. Solche konvergierten Infrastrukturen können mit einer konvergierten Infrastruktur-Referenzarchitektur, mit eigenständigen Geräten, mit einem softwaregesteuerten hyper-konvergierten Ansatz (z. B. hyper-konvergierten Infrastrukturen) oder auf andere Weise implementiert werden.
  • Der Leser wird verstehen, dass das in 3B dargestellte Speichersystem 306 für die Unterstützung verschiedener Arten von Softwareanwendungen nützlich sein kann. Beispielsweise kann das Speichersystem 306 bei der Unterstützung von Anwendungen der künstlichen Intelligenz („AI“), Datenbankanwendungen, DevOps-Projekten, elektronischen Design-Automatisierungstools, ereignisgesteuerten Softwareanwendungen, Hochleistungscomputeranwendungen, Simulationsanwendungen, Hochgeschwindigkeits-Datenerfassungs- und -analyseanwendungen, Anwendungen für maschinelles Lernen, Medienproduktionsanwendungen, Medienbereitstellungsanwendungen, Bildarchivierungs- und Kommunikationssystemen („PACS“), Softwareentwicklungsanwendungen, Virtual-Reality-Anwendungen, Augmented-Reality-Anwendungen und vielen anderen Arten von Anwendungen durch das Bereitstellen von Speicherressourcen für solche Anwendungen nützlich sein.
  • Die vorstehend beschriebenen Speichersysteme können zur Unterstützung einer Vielzahl von Anwendungen eingesetzt werden. In Anbetracht der Tatsache, dass die Speichersysteme Rechenressourcen, Speicherressourcen und eine Vielzahl anderer Ressourcen umfassen, können die Speichersysteme gut geeignet sein, ressourcenintensive Anwendungen wie beispielsweise Kl-Anwendungen zu unterstützen. Solche Kl-Anwendungen können Geräte in die Lage versetzen, ihre Umgebung wahrzunehmen und Maßnahmen zu ergreifen, die ihre Erfolgschancen im Hinblick auf ein bestimmtes Ziel maximieren. Beispiele für solche Kl-Anwendungen sind IBM Watson, Microsoft Oxford, Google DeepMind, Baidu Minwa und andere. Die oben beschriebenen Speichersysteme können auch gut geeignet sein, um andere Arten von ressourcenintensiven Anwendungen zu unterstützen, wie z. B. Anwendungen für maschinelles Lernen. Anwendungen für maschinelles Lernen können verschiedene Arten der Datenanalyse durchführen, um die Erstellung von Analysemodellen zu automatisieren. Mithilfe von Algorithmen, die iterativ aus Daten lernen, können Computer lernen, ohne explizit programmiert zu werden. Ein besonderer Bereich des maschinellen Lernens ist das so genannte Verstärkungslernen, bei dem geeignete Maßnahmen ergriffen werden, um die Belohnung in einer bestimmten Situation zu maximieren. Verstärkungslernen kann eingesetzt werden, um das bestmögliche Verhalten oder den besten Weg zu finden, den eine bestimmte Softwareanwendung oder Maschine in einer bestimmten Situation einschlagen sollte. Verstärkungslernen unterscheidet sich von anderen Bereichen des maschinellen Lernens (z. B. überwachtes Lernen, unüberwachtes Lernen) dadurch, dass für das Verstärkungslernen keine korrekten Eingabe-/Ausgabepaare vorliegen müssen und suboptimale Aktionen nicht ausdrücklich korrigiert werden müssen.
  • Zusätzlich zu den bereits beschriebenen Ressourcen können die oben beschriebenen Speichersysteme auch Grafikverarbeitungseinheiten („GPUs“) enthalten, die gelegentlich auch als visuelle Verarbeitungseinheiten („VPUs“) bezeichnet werden. Solche GPUs können als spezialisierte elektronische Schaltungen ausgeführt sein, die den Speicher schnell bearbeiten und verändern, um die Erstellung von Bildern in einem Bildpuffer zu beschleunigen, der zur Ausgabe an ein Anzeigegerät bestimmt ist. Solche GPUs können in jedem der Rechengeräte enthalten sein, welche Teil der oben beschriebenen Speichersysteme sind, auch als eine von vielen individuell skalierbaren Komponenten eines Speichersystems, wobei andere Beispiele für individuell skalierbare Komponenten eines solchen Speichersystems Datenspeicherkomponenten, Arbeitsspeicherkomponenten, Rechenkomponenten (z. B. CPUs, FPGAs, ASICs), Netzwerkkomponenten, Softwarekomponenten und andere umfassen können. Zusätzlich zu den GPUs können die oben beschriebenen Speichersysteme auch neuronale Netzwerkprozessoren („NNPs“) zur Verwendung in verschiedenen Aspekten der Verarbeitung im neuronalen Netz enthalten. Solche NNPs können anstelle von (oder zusätzlich zu) GPUs verwendet werden und können auch unabhängig skalierbar sein.
  • Wie oben beschrieben, können die hier beschriebenen Speichersysteme so konfiguriert werden, dass sie Anwendungen der künstlichen Intelligenz, Anwendungen des maschinellen Lernens, Big-Data-Analyseanwendungen und viele andere Arten von Anwendungen unterstützen. Das schnelle Wachstum dieser Art von Anwendungen wird von drei Technologien angetrieben: Deep Learning (DL), GPU-Prozessoren und Big Data. Deep Learning ist ein Computermodell, bei dem massiv parallele neuronale Netze nach dem Vorbild des menschlichen Gehirns zum Einsatz kommen. Anstatt dass Experten die Software von Hand erstellen, schreibt ein Deep-Learning-Modell seine eigene Software, indem es aus vielen Beispielen lernt. Ein GPU ist ein moderner Prozessor mit Tausenden von Kernen, der sich gut für die Ausführung von Algorithmen eignet, die der Parallelität des menschlichen Gehirns nahekommen.
  • Fortschritte bei tiefen neuronalen Netzen haben eine neue Welle von Algorithmen und Tools für Datenwissenschaftler ausgelöst, die ihre Daten mit künstlicher Intelligenz (Kl) nutzen wollen. Mit verbesserten Algorithmen, größeren Datensätzen und verschiedenen Frameworks (einschließlich Open-Source-Softwarebibliotheken für maschinelles Lernen in einer Reihe von Aufgaben) gehen Datenwissenschaftler neue Anwendungsfälle wie autonom fahrende Fahrzeuge, die Verarbeitung und das Verstehen von natürlicher Sprache, Computer Vision, maschinelles Schlussfolgern, starke KI und viele andere an. Zu den Anwendungen solcher Techniken gehören: Erkennen, Identifizieren und Umgehen von Objekten durch Maschinen und Fahrzeuge; visuelles Erkennen, Klassifizieren und Kennzeichnen; algorithmisches Leistungsmanagement von Finanzhandelsstrategien; gleichzeitige Lokalisierung und Kartierung; vorausschauende Wartung hochwertiger Maschinen; Vorbeugung gegen Bedrohungen der Cybersicherheit, Automatisierung von Fachwissen; Bilderkennung und -klassifizierung; Beantwortung von Fragen; Robotik; Textanalyse (Extraktion, Klassifizierung) sowie Texterstellung und -übersetzung und viele andere. Anwendungen von KI-Techniken sind in einer Vielzahl von Produkten zu finden, z. B. in der Spracherkennungstechnologie von Amazon Echo, die es Nutzern ermöglicht, mit ihren Maschinen zu sprechen, in Google Translate™, das eine maschinengestützte Sprachübersetzung ermöglicht, in Spotifys Discover Weekly, das auf der Grundlage der Nutzungs- und Datenverkehrsanalyse des Nutzers Empfehlungen zu neuen Songs und Künstlern gibt, die ihm gefallen könnten, in Quills Angebot zur Texterstellung, das strukturierte Daten in erzählende Geschichten umwandelt, in Chatbots, die in Echtzeit kontextspezifische Antworten auf Fragen in einem Dialogformat geben, und in vielen anderen. Darüber hinaus kann sich die KI auf eine Vielzahl von Branchen und Sektoren auswirken. So können Kl-Lösungen im Gesundheitswesen eingesetzt werden, um klinische Aufzeichnungen, Patientenakten, Forschungsdaten und andere Eingaben zu erfassen und daraus potenzielle Behandlungsoptionen für Ärzte abzuleiten. Ebenso können Kl-Lösungen von Einzelhändlern eingesetzt werden, um Kundenempfehlungen auf der Grundlage des digitalen Fußabdrucks von Verhaltensweisen, Profildaten oder anderen Daten einer Person zu personalisieren.
  • Das Training von tiefen neuronalen Netzen erfordert jedoch sowohl qualitativ hochwertige Eingabedaten als auch große Mengen an Berechnungen. GPUs sind massiv parallele Prozessoren, die große Datenmengen gleichzeitig verarbeiten können. Wenn sie in einem Multi-GPU-Cluster kombiniert werden, kann eine Pipeline mit hohem Durchsatz erforderlich sein, um die Eingabedaten vom Speicher zu den Recheneinheiten zu leiten. Deep Learning ist mehr als nur das Erstellen und Trainieren von Modellen. Es gibt auch eine gesamte Datenpipeline, die für die Skalierung, Iteration und Experimente ausgelegt sein muss, die für den Erfolg eines Data-Science-Teams erforderlich sind.
  • Daten sind das Herzstück moderner Kl- und Deep-Learning-Algorithmen. Bevor mit dem Training begonnen werden kann, muss ein Problem gelöst werden, das sich um das Sammeln der beschrifteten Daten dreht, die für das Training eines genauen Kl-Modells entscheidend sind. Bei einer umfassenden Kl-Implementierung kann es erforderlich sein, kontinuierlich große Datenmengen zu sammeln, zu bereinigen, umzuwandeln, zu kennzeichnen und zu speichern. Das Hinzufügen zusätzlicher hochwertiger Datenpunkte führt direkt zu genaueren Modellen und besseren Erkenntnissen. Datenproben können eine Reihe von Verarbeitungsschritten durchlaufen, die unter anderem Folgendes umfassen: 1) Einspeisung der Daten aus einer externen Quelle in das Trainingssystem und Speicherung der Daten in Rohform, 2) Bereinigung und Umwandlung der Daten in ein für das Training geeignetes Format, einschließlich der Verknüpfung von Datenproben mit der entsprechenden Kennzeichnung, 3) Erkundung von Parametern und Modellen, schnelles Testen mit einem kleineren Datensatz und Iteration, um die vielversprechendsten Modelle zu ermitteln, die in den Produktionscluster übertragen werden, 4) Durchführung von Trainingsphasen zur Auswahl zufälliger Stapel von Eingabedaten, einschließlich neuer und älterer Proben, und Einspeisung dieser Daten in GPU-Server für Berechnungen zur Aktualisierung von Modellparametern, und 5) Evaluierung, einschließlich der Verwendung eines zurückbehaltenen Teils der Daten, die nicht für das Training verwendet wurden, um die Modellgenauigkeit anhand der zurückbehaltenen Daten zu bewerten. Dieser Lebenszyklus kann für jede Art des parallelisierten maschinellen Lernens gelten, nicht nur für neuronale Netze oder Deep Learning. Beispielsweise können Standard-Frameworks für maschinelles Lernen auf CPUs statt auf GPUs basieren, aber die Arbeitsabläufe für die Dateneingabe und das Training können dieselben sein. Die Leser werden es zu schätzen wissen, dass eine einzige gemeinsam genutzte Datendrehscheibe einen Koordinationspunkt für den gesamten Lebenszyklus schafft, ohne dass zusätzliche Datenkopien für die Aufnahme-, Vorverarbeitungs- und Trainingsphasen erforderlich sind. Selten werden die aufgenommenen Daten nur für einen einzigen Zweck verwendet, und die gemeinsame Speicherung bietet die Flexibilität, mehrere verschiedene Modelle zu trainieren oder traditionelle Analysen auf die Daten anzuwenden.
  • Die Leser werden verstehen, dass jede Stufe der Kl-Datenpipeline unterschiedliche Anforderungen an die Datendrehscheibe (z. B. das Speichersystem oder die Sammlung von Speichersystemen) stellen kann. Scale-out-Speichersysteme müssen kompromisslose Leistung für alle Arten von Zugriffsarten und -mustern bieten - von kleinen, metadatenlastigen bis hin zu großen Dateien, von zufälligen bis hin zu sequentiellen Zugriffsmustern und von geringer bis hin zu hoher Gleichzeitigkeit. Die oben beschriebenen Speichersysteme können als ideale KI-Datendrehscheibe dienen, da die Systeme unstrukturierte Arbeitslasten bedienen können. In der ersten Phase werden die Daten idealerweise in dieselbe Datendrehscheibe eingespeist und dort gespeichert, die auch von den nachfolgenden Phasen verwendet wird, um übermäßiges Kopieren von Daten zu vermeiden. Die nächsten beiden Schritte können auf einem Standard-Rechenserver durchgeführt werden, der optional einen Grafikprozessor enthält, und in der vierten und letzten Stufe werden dann vollständige Trainings-Produktionsaufträge auf leistungsstarken GPU-beschleunigten Servern ausgeführt. Oft gibt es eine Produktionspipeline neben einer experimentellen Pipeline, die mit demselben Datensatz arbeitet. Darüber hinaus können die GPU-beschleunigten Server unabhängig voneinander für verschiedene Modelle verwendet oder zusammengeschlossen werden, um ein größeres Modell zu trainieren, das sogar mehrere Systeme für verteiltes Training umfasst. Wenn die gemeinsam genutzte Speicherebene langsam ist, müssen die Daten für jede Phase auf den lokalen Speicher kopiert werden, was zu Zeitverlusten bei der Bereitstellung der Daten auf verschiedenen Servern führt. Die ideale Datendrehscheibe für die KI-Trainings-Pipeline bietet eine ähnliche Leistung wie lokal auf dem Serverknoten gespeicherte Daten und ist gleichzeitig so einfach und leistungsfähig, dass alle Pipeline-Phasen gleichzeitig ablaufen können.
  • Ein Datenwissenschaftler arbeitet daran, die Nützlichkeit des trainierten Modells durch eine Vielzahl von Ansätzen zu verbessern: mehr Daten, bessere Daten, intelligenteres Training und tiefere Modelle. In vielen Fällen gibt es Teams von Datenwissenschaftlern, die sich dieselben Datensätze teilen und parallel an der Erstellung neuer und verbesserter Trainingsmodelle arbeiten. Oft arbeitet ein Team von Datenwissenschaftlern in diesen Phasen gleichzeitig an denselben gemeinsam genutzten Datensätzen. Mehrere gleichzeitige Arbeitslasten bei der Datenverarbeitung, beim Experimentieren und beim Training in vollem Umfang überlagern die Anforderungen der verschiedenen Zugriffsmuster auf die Speicherebene. Mit anderen Worten: Der Speicher kann nicht nur große Dateien lesen, sondern muss eine Mischung aus Lese- und Schreibvorgängen für große und kleine Dateien bewältigen. Schließlich kann es bei der Untersuchung von Datensätzen und Modellen durch mehrere Datenwissenschaftler von entscheidender Bedeutung sein, die Daten in ihrem nativen Format zu speichern, um jedem Benutzer die Flexibilität zu geben, die Daten auf einzigartige Weise zu transformieren, zu bereinigen und zu verwenden. Die oben beschriebenen Speichersysteme können einen natürlichen gemeinsamen Speicherplatz für den Datensatz bieten, mit redundanter Datensicherung (z. B. durch RAID6) und der notwendigen Leistung, um ein gemeinsamer Zugangspunkt für mehrere Entwickler und mehrere Experimente zu sein. Durch die Verwendung der oben beschriebenen Speichersysteme kann vermieden werden, dass Teilmengen der Daten für die lokale Arbeit sorgfältig kopiert werden müssen, was sowohl den Entwicklern als auch den GPU-beschleunigten Servern Zeit spart. Diese Kopien werden zu einer konstanten und wachsenden Belastung, da der Rohdatensatz und die gewünschten Transformationen ständig aktualisiert und verändert werden.
  • Die Leser werden verstehen, dass ein wesentlicher Grund für den großen Erfolg von Deep Learning die kontinuierliche Verbesserung der Modelle bei größeren Datensätzen ist. Im Gegensatz dazu hören klassische Algorithmen des maschinellen Lernens, wie die logistische Regression, bei kleineren Datenmengen auf, ihre Genauigkeit zu verbessern. Die Trennung von Rechen- und Speicherressourcen ermöglicht eine unabhängige Skalierung der einzelnen Ebenen und vermeidet viele der Probleme, die mit der gemeinsamen Verwaltung beider Ebenen verbunden sind. Wenn die Datenmenge wächst oder neue Datensätze berücksichtigt werden, muss ein skalierbares Speichersystem problemlos erweitert werden können. Wenn mehr gleichzeitiges Training erforderlich ist, können zusätzliche GPUs oder andere Rechenressourcen hinzugefügt werden, ohne sich um deren internen Speicher zu kümmern. Darüber hinaus können die oben beschriebenen Speichersysteme den Aufbau, den Betrieb und das Wachstum eines KI-Systems vereinfachen, da sie eine zufällige Lesebandbreite zur Verfügung stellen, kleine Dateien (50 KB) mit hohen Raten zufällig lesen können (was bedeutet, dass kein zusätzlicher Aufwand erforderlich ist, um einzelne Datenpunkte zu größeren, speicherfreundlichen Dateien zusammenzufassen), die Kapazität und Leistung der Speichersysteme skalieren können, wenn entweder der Datensatz oder die Durchsatzanforderungen wachsen, die Speichersysteme Dateien oder Objekte unterstützen und die Leistung für große oder kleine Dateien einstellen können (d. h. keine Notwendigkeit für den Benutzer, Dateisysteme bereitzustellen), die Fähigkeit der Speichersysteme, unterbrechungsfreie Upgrades von Hardware und Software selbst während des Trainings von Produktionsmodellen zu unterstützen, und aus vielen anderen Gründen.
  • Die Leistung der Speicherebene in Bezug auf kleine Dateien kann von entscheidender Bedeutung sein, da viele Arten von Eingaben wie Text, Audio oder Bilder von Natur aus als kleine Dateien gespeichert werden. Wenn die Speicherebene kleine Dateien nicht gut handhaben kann, ist ein zusätzlicher Schritt zur Vorverarbeitung und Gruppierung von Proben in größere Dateien erforderlich. Ein Speicher, der auf rotierenden Festplatten aufgebaut ist und sich auf SSD als Caching-Ebene verlässt, kann die erforderliche Leistung nicht erreichen. Da das Training mit zufälligen Eingabestapeln zu genaueren Modellen führt, muss der gesamte Datensatz mit voller Leistung zugänglich sein. SSD-Zwischenspeicher bieten nur für eine kleine Teilmenge der Daten eine hohe Leistung und sind nicht in der Lage, die Latenz von Festplatten zu verbergen.
  • Obwohl in den vorangegangenen Abschnitten Deep-Learning-Anwendungen erörtert wurden, werden die Leser verstehen, dass die hier beschriebenen Speichersysteme auch Teil einer verteilten Deep-Learning-Plattform („DDL“) sein können, um die Ausführung von DDL-Algorithmen zu unterstützen. Verteiltes Deep Learning kann verwendet werden, um Deep Learning mit verteiltem Rechnen auf GPUs (oder anderen Formen von Beschleunigern oder Ausführungsprogrammen für Computerprogramme) erheblich zu beschleunigen, so dass Parallelität erreicht werden kann. Darüber hinaus können die Ergebnisse des Trainings von Machine-Learning- und Deep-Learning-Modellen, z. B. ein vollständig trainiertes Machine-Learning-Modell, für eine Vielzahl von Zwecken und in Verbindung mit anderen Tools verwendet werden. Beispielsweise können trainierte Modelle für maschinelles Lernen in Verbindung mit Tools wie Core ML verwendet werden, um eine breite Palette von Modellarten für maschinelles Lernen in eine Anwendung zu integrieren. So können trainierte Modelle durch Core ML-Konverter-Tools ausgeführt und in eine benutzerdefinierte Anwendung eingefügt werden, die auf kompatiblen Geräten eingesetzt werden kann. Die oben beschriebenen Speichersysteme können auch mit anderen Technologien wie TensorFlow, einer Open-Source-Softwarebibliothek für die Datenflussprogrammierung für eine Reihe von Aufgaben, die für Anwendungen des maschinellen Lernens wie neuronale Netze verwendet werden können, kombiniert werden, um die Entwicklung solcher maschinellen Lernmodelle, Anwendungen usw. zu erleichtern.
  • Der Leser wird ferner verstehen, dass die oben beschriebenen Systeme auf vielfältige Weise eingesetzt werden können, um die Demokratisierung von KI zu unterstützen, da KI zunehmend für den Massenkonsum verfügbar wird. Die Demokratisierung von KI kann zum Beispiel die Möglichkeit beinhalten, KI als Platform-as-a-Service anzubieten, das Wachstum von Angeboten für künstliche allgemeine Intelligenz, die Verbreitung von autonomen Fahrzeugen der Stufen 4 und 5, die Verfügbarkeit von autonomen mobilen Robotern, die Entwicklung von Plattformen für konversationelle KI und vieles mehr. Die oben beschriebenen Systeme können beispielsweise in Cloud-Umgebungen, Edge-Umgebungen oder anderen Umgebungen eingesetzt werden, die für die Demokratisierung von KI nützlich sind. Im Rahmen der Demokratisierung der KI kann es zu einer Bewegung von der eng gefassten Kl, die aus hochspezialisierten maschinellen Lernlösungen besteht, die auf eine bestimmte Aufgabe abzielen, hin zur allgemeinen künstlichen Intelligenz kommen, bei der die Nutzung des maschinellen Lernens auf eine breite Palette von Anwendungsfällen ausgeweitet wird, die im Wesentlichen jede intelligente Aufgabe ausführen können, die ein Mensch ausführen könnte, und die dynamisch lernen können, ähnlich wie ein Mensch.
  • Die oben beschriebenen Speichersysteme können auch in einer neuromorphen Datenverarbeitungsumgebung verwendet werden. Neuromorphes Rechnen ist eine Form des Rechnens, die Gehirnzellen nachahmt. Zur Unterstützung des neuromorphen Rechnens ersetzt eine Architektur aus miteinander verbundenen „Neuronen“ herkömmliche Rechenmodelle durch Signale mit geringer Leistung, die direkt zwischen den Neuronen übertragen werden, um eine effizientere Berechnung zu ermöglichen. Neuromorphes Rechnen kann auf VLSI-Systeme (Very Large Scale Integration) zurückgreifen, die analoge elektronische Schaltungen enthalten, um die neurobiologischen Architekturen des Nervensystems nachzuahmen, sowie auf analoge, digitale, gemischt analog/digitale VLSI- und Softwaresysteme, die Modelle neuronaler Systeme für die Wahrnehmung, die motorische Steuerung oder die multisensorische Integration umsetzen.
  • Der Leser wird verstehen, dass die oben beschriebenen Speichersysteme so konfiguriert sein können, dass sie die Speicherung oder Verwendung von (neben anderen Arten von Daten) Blockchains unterstützen. Solche Blockchains können als eine kontinuierlich wachsende Liste von Datensätzen, die als Blöcke bezeichnet werden, verkörpert werden, die miteinander verknüpft und durch Kryptografie gesichert sind. Jeder Block in einer Blockchain kann einen Hash-Pointer als Link zu einem vorherigen Block, einen Zeitstempel, Transaktionsdaten usw. enthalten. Blockchains können so konzipiert sein, dass sie gegen eine Änderung der Daten resistent sind und als offene, verteilte Ledger dienen, die Transaktionen zwischen zwei Parteien effizient und auf nachprüfbare und dauerhafte Weise aufzeichnen können. Dadurch eignen sich Blockchains potenziell für die Aufzeichnung von Ereignissen, medizinischen Aufzeichnungen und anderen Aktivitäten zur Verwaltung von Aufzeichnungen, wie z. B. Identitätsmanagement, Transaktionsverarbeitung usw. Zusätzlich zur Unterstützung der Speicherung und Nutzung von Blockchain-Technologien können die oben beschriebenen Speichersysteme auch die Speicherung und Nutzung von Derivaten unterstützen, wie z. B. Open-Source-Blockchains und zugehörige Tools, die Teil des IBM™-Hyperledger-Projekts sind, genehmigte Blockchains, bei denen eine bestimmte Anzahl von vertrauenswürdigen Parteien auf die Blockchain zugreifen darf, Blockchain-Produkte, die es Entwicklern ermöglichen, ihre eigenen Distributed-Ledger-Projekte zu erstellen, und andere. Die Leser werden verstehen, dass Blockchain-Technologien sich auf eine Vielzahl von Branchen und Sektoren auswirken können. So können Blockchain-Technologien beispielsweise bei Immobilientransaktionen in Form von Blockchain-basierten Verträgen eingesetzt werden, die die Notwendigkeit von Drittparteien überflüssig machen und selbstausführende Aktionen ermöglichen, wenn die Bedingungen erfüllt sind. Ebenso können universelle Gesundheitsakten erstellt werden, indem die Gesundheitsdaten einer Person in einem Blockchain-Ledger zusammengefasst und gespeichert werden, so dass jeder Gesundheitsdienstleister oder berechtigte Gesundheitsdienstleister darauf zugreifen und sie aktualisieren kann.
  • Die Leser werden verstehen, dass die Verwendung von Blockchains nicht auf Finanztransaktionen, Verträge und dergleichen beschränkt ist. Tatsächlich können Blockchains genutzt werden, um die dezentralisierte Aggregation, Ordnung, Zeitstempelung und Archivierung jeglicher Art von Informationen zu ermöglichen, einschließlich strukturierter Daten, Korrespondenz, Dokumentation oder anderer Daten. Durch den Einsatz von Blockchains können sich die Teilnehmer nachweislich und dauerhaft darauf einigen, welche Daten wann und von wem eingegeben wurden, ohne auf einen vertrauenswürdigen Mediator angewiesen zu sein. Die kürzlich von SAP eingeführte Blockchain-Plattform, die MultiChain und Hyperledger Fabric unterstützt, zielt beispielsweise auf eine breite Palette von Lieferketten- und andere nicht-finanzielle Anwendungen ab.
  • Eine Möglichkeit, eine Blockchain für die Aufzeichnung von Daten zu nutzen, besteht darin, jedes Datenelement direkt in eine Transaktion einzubetten. Jede Blockchain-Transaktion kann von einer oder mehreren Parteien digital signiert, auf eine Vielzahl von Knoten repliziert, durch den Konsensalgorithmus der Chain geordnet und mit einem Zeitstempel versehen und dauerhaft und fälschungssicher gespeichert werden. Alle Daten innerhalb der Transaktion werden daher von jedem Knoten identisch, aber unabhängig voneinander gespeichert, zusammen mit einem Nachweis darüber, wer sie wann geschrieben hat. Die Nutzer der Chain sind in der Lage, diese Informationen jederzeit abzurufen. Diese Art der Speicherung kann als On-Chain-Speicherung bezeichnet werden. Die On-Chain-Speicherung ist jedoch nicht besonders praktisch, wenn es darum geht, einen sehr großen Datensatz zu speichern. Daher können Blockchains und die hierin beschriebenen Speichersysteme in Übereinstimmung mit den Ausführungsformen der vorliegenden Offenlegung so eingesetzt werden, dass sie sowohl die On-Chain-Speicherung von Daten als auch die Off-Chain-Speicherung von Daten unterstützen.
  • Die Off-Chain-Speicherung von Daten kann auf verschiedene Weise erfolgen und kann auftreten, wenn die Daten selbst nicht in der Blockchain gespeichert werden. In einer Ausführungsform kann zum Beispiel eine Hash-Funktion verwendet werden, und die Daten selbst können in die Hash-Funktion eingegeben werden, um einen Hash-Wert zu erzeugen. In einem solchen Beispiel können die Hashes großer Datenstücke in Transaktionen eingebettet werden, anstatt der Daten selbst. Jeder Hash-Wert kann als eine Festlegung gegenüber den Eingabedaten dienen, wobei die Daten selbst außerhalb der Blockchain gespeichert werden. Jeder Blockchain-Teilnehmer, der ein Off-Chain-Datenstück benötigt, kann die Daten nicht anhand ihres Hashes reproduzieren, aber wenn die Daten auf andere Weise abgerufen werden können, dann dient der On-Chain-Hash dazu, zu bestätigen, wer sie wann erstellt hat. Genau wie reguläre On-Chain-Daten kann der Hash in eine digital signierte Transaktion eingebettet sein, die durch Konsens in die Chain aufgenommen wurde.
  • Der Leser wird verstehen, dass in anderen Ausführungsformen auch Alternativen zu Blockchains verwendet werden können, um die dezentrale Speicherung von Informationen zu erleichtern. Eine Alternative zu einer Blockchain kann zum Beispiel ein Blockweave sein. Während herkömmliche Blockchains jede Transaktion speichern, um eine Validierung zu erreichen, ermöglicht ein Blockweave eine sichere Dezentralisierung ohne die Verwendung der gesamten Chain, wodurch eine kostengünstige Speicherung von Daten auf der Chain ermöglicht wird. Solche Blockweaves können einen Konsensmechanismus verwenden, der auf einem Proof of Access (PoA) und einem Proof of Work (PoW) basiert. Während typische PoW-Systeme nur auf den vorherigen Block angewiesen sind, um jeden nachfolgenden Block zu erzeugen, kann der PoA-Algorithmus Daten aus einem zufällig ausgewählten vorherigen Block einbeziehen. In Kombination mit der Blockweave-Datenstruktur müssen die Miner nicht alle Blöcke speichern (die eine Blockchain bilden), sondern können alle vorherigen Blöcke speichern, die ein Geflecht aus Blöcken bilden (ein Blockweave). Dies ermöglicht ein höheres Maß an Skalierbarkeit, Schnelligkeit und geringen Kosten und senkt die Kosten für die Datenspeicherung zum Teil deshalb, weil die Miner nicht alle Blöcke speichern müssen, was zu einer erheblichen Verringerung des Stromverbrauchs während des Mining-Prozesses führt, da der Stromverbrauch mit zunehmender Ausdehnung des Netzes sinkt, weil ein Blockweave immer weniger Hashing-Leistung für die Konsensfindung erfordert, je mehr Daten dem System hinzugefügt werden. Darüber hinaus können Blockweaves in einem dezentralen Speichernetzwerk eingesetzt werden, in dem Anreize geschaffen werden, um einen schnellen Datenaustausch zu fördern. Solche dezentralen Speichernetze können auch Blockshadowing-Techniken nutzen, bei denen die Knoten nur einen minimalen Block-„Schatten“ an andere Knoten senden, der es den anderen Knoten ermöglicht, einen vollständigen Block zu rekonstruieren, anstatt den vollständigen Block selbst zu übertragen.
  • Die oben beschriebenen Speichersysteme können entweder allein oder in Kombination mit anderen Datenverarbeitungsgeräten zur Unterstützung von In-Memory-Computing-Anwendungen verwendet werden. Beim In-Memory-Computing werden Informationen in einem Arbeitsspeicher (RAM) gespeichert, der über eine Gruppe von Computern verteilt ist. In-Memory-Computing hilft Geschäftskunden wie Einzelhändlern, Banken und Versorgungsunternehmen, Muster schnell zu erkennen, riesige Datenmengen im Handumdrehen zu analysieren und ihre Operationen schnell durchzuführen. Der Leser wird verstehen, dass die oben beschriebenen Speichersysteme, insbesondere solche, die mit anpassbaren Mengen an Verarbeitungsressourcen, Speicherressourcen und Arbeitsspeicherressourcen konfigurierbar sind (z. B. solche Systeme, in denen Blades konfigurierbare Mengen jedes Ressourcentyps enthalten), so konfiguriert werden können, dass sie eine Infrastruktur bereitstellen, die In-Memory-Computing unterstützen kann. Ebenso können die oben beschriebenen Speichersysteme Komponenten enthalten (z. B. NVDIMMs, 3D-Kreuzpunkt-Speicher, die einen schnellen, dauerhaften Direktzugriffsspeicher bereitstellen), die im Vergleich zu In-Memory-Computing-Umgebungen, die sich auf über dedizierte Server verteilten Arbeitsspeicher stützen, tatsächlich eine verbesserte In-Memory-Computing-Umgebung bieten können.
  • In einigen Ausführungsformen können die oben beschriebenen Speichersysteme so konfiguriert werden, dass sie als hybride In-Memory-Computing-Umgebung arbeiten, die eine universelle Schnittstelle zu allen Speichermedien (z. B. RAM, Flash-Speicher, 3D-Kreuzpunkt-Speicher enthält. In solchen Ausführungsformen haben die Benutzer keine Kenntnis darüber, wo ihre Daten gespeichert sind, können aber dennoch dieselbe vollständige, einheitliche API verwenden, um Daten anzusprechen. In solchen Fällen kann das Speichersystem (im Hintergrund) Daten auf die schnellste verfügbare Ebene verschieben - einschließlich einer intelligenten Platzierung der Daten in Abhängigkeit von verschiedenen Merkmalen der Daten oder in Abhängigkeit von einer anderen Heuristik. In einem solchen Beispiel können die Speichersysteme sogar bestehende Produkte wie Apache Ignite und GridGain nutzen, um Daten zwischen den verschiedenen Speicherebenen zu verschieben, oder die Speichersysteme können kundenspezifische Software nutzen, um Daten zwischen den verschiedenen Speicherebenen zu verschieben. Die hier beschriebenen Speichersysteme können verschiedene Optimierungen implementieren, um die Leistung des In-Memory-Computing zu verbessern, z. B. indem die Berechnungen so nah wie möglich an den Daten durchgeführt werden.
  • Die Leser werden ferner verstehen, dass die oben beschriebenen Speichersysteme in einigen Ausführungsformen mit anderen Ressourcen kombiniert werden können, um die oben beschriebenen Anwendungen zu unterstützen. Eine Infrastruktur könnte beispielsweise primäre Rechenleistung in Form von Servern und Workstations umfassen, die auf die Verwendung von General-Purpose-Computing auf Grafikverarbeitungseinheiten („GPGPU“) spezialisiert sind, um Deep-Learning-Anwendungen zu beschleunigen, die zu einer Berechnungsmaschine zum Trainieren von Parametern für tiefe neuronale Netze zusammengeschaltet sind. Jedes System kann über eine externe Ethernet-Verbindung, eine externe InfiniBand-Verbindung, eine andere Form der externen Verbindung oder eine Kombination davon verfügen. In einem solchen Beispiel können die GPUs für ein einziges großes Training gruppiert oder unabhängig voneinander für das Training mehrerer Modelle verwendet werden. Die Infrastruktur könnte auch ein Speichersystem wie die oben beschriebenen umfassen, um beispielsweise einen skalierbaren All-Flash-Datei- oder Objektspeicher bereitzustellen, über den der Zugriff auf Daten über Hochleistungsprotokolle wie NFS, S3 usw. erfolgen kann. Die Infrastruktur kann beispielsweise auch redundante Topof-Rack-Ethernet-Switches umfassen, die über Ports in MLAG-Port-Kanälen mit dem Speicher und den Rechnern verbunden sind, um Redundanz zu gewährleisten. Die Infrastruktur könnte auch zusätzliche Rechenleistung in Form von Whitebox-Servern, optional mit GPUs, für Dateneingabe, Vorverarbeitung und Modell-Debugging umfassen. Die Leser werden verstehen, dass auch zusätzliche Infrastrukturen denkbar sind.
  • Die Leser werden verstehen, dass die oben beschriebenen Systeme für die oben beschriebenen Anwendungen besser geeignet sein können als andere Systeme, zu denen beispielsweise eine verteilte, direkt angeschlossene Speicherlösung (DDAS) gehört, die in Serverknoten eingesetzt wird. Solche DDAS-Lösungen können für die Verarbeitung großer, weniger sequentieller Zugriffe ausgelegt sein, sind aber möglicherweise weniger in der Lage, kleine, zufällige Zugriffe zu verarbeiten. Der Leser wird ferner verstehen, dass die oben beschriebenen Speichersysteme verwendet werden können, um eine Plattform für die oben beschriebenen Anwendungen bereitzustellen, die der Nutzung von cloudbasierten Ressourcen vorzuziehen ist, da die Speichersysteme in eine Vor-Ort- oder Inhouse-Infrastruktur eingebunden werden können, die sicherer, lokaler und interner verwaltet, robuster in Bezug auf Funktionen und Leistung ist oder anderweitig der Nutzung von cloudbasierten Ressourcen als Teil einer Plattform zur Unterstützung der oben beschriebenen Anwendungen vorzuziehen ist. Beispielsweise können Dienste, die auf Plattformen wie IBMs Watson aufgebaut sind, es erforderlich machen, dass ein Unternehmen individuelle Nutzerdaten, wie Informationen über Finanztransaktionen oder identifizierbare Patientendaten, an andere Einrichtungen weitergibt. Daher sind cloudbasierte Angebote von KI als Dienstleistung möglicherweise weniger wünschenswert als intern verwaltete und angebotene KI als Dienstleistung, die von Speichersystemen wie den oben beschriebenen Speichersystemen unterstützt wird, und zwar sowohl aus einer Vielzahl technischer Gründe als auch aus verschiedenen geschäftlichen Gründen.
  • Der Leser wird verstehen, dass die oben beschriebenen Speichersysteme entweder allein oder in Abstimmung mit anderen Rechnern so konfiguriert werden können, dass sie andere Kl-bezogene Tools unterstützen. So können die Speichersysteme beispielsweise Tools wie ONXX oder andere offene Austauschformate für neuronale Netze nutzen, die die Übertragung von Modellen, die in verschiedenen Kl-Frameworks geschrieben wurden, erleichtern. Ebenso können die Speichersysteme so konfiguriert sein, dass sie Tools wie Amazons Gluon unterstützen, die es Entwicklern ermöglichen, Prototypen für Deep-Learning-Modelle zu erstellen und zu trainieren. Die oben beschriebenen Speichersysteme können sogar Teil einer größeren Plattform wie IBM™ Cloud Private for Data sein, die integrierte Data-Science-, Data-Engineering- und Anwendungsentwicklungsdienste umfasst. Solche Plattformen können Daten in einem Unternehmen nahtlos sammeln, organisieren, sichern und analysieren sowie hybrides Datenmanagement, einheitliche Datenverwaltung und - integration, Datenwissenschaft und Geschäftsanalysen mit einer einzigen Lösung vereinfachen.
  • Der Leser wird ferner verstehen, dass die oben beschriebenen Speichersysteme auch als Edge-Lösung eingesetzt werden können. Eine solche Edge-Lösung kann zur Optimierung von Cloud-Computing-Systemen eingesetzt werden, indem die Datenverarbeitung am Rande des Netzes, nahe der Datenquelle, durchgeführt wird. Edge Computing kann Anwendungen, Daten und Rechenleistung (d. h. Dienste) von zentralen Punkten weg an die logischen Enden eines Netzes verlagern. Durch den Einsatz von Edge-Lösungen wie den oben beschriebenen Speichersystemen können Rechenaufgaben unter Verwendung der von solchen Speichersystemen bereitgestellten Rechenressourcen durchgeführt werden, Daten können unter Verwendung der Speicherressourcen des Speichersystems gespeichert werden, und auf cloudbasierte Dienste kann durch die Verwendung verschiedener Ressourcen des Speichersystems (einschließlich Netzwerkressourcen) zugegriffen werden. Durch die Ausführung von Rechenaufgaben auf der Edge-Lösung, das Speichern von Daten auf der Edge-Lösung und die allgemeine Nutzung der Edge-Lösung kann der Verbrauch teurer cloudbasierter Ressourcen vermieden werden, und es können sogar Leistungsverbesserungen im Vergleich zu einer stärkeren Abhängigkeit von cloudbasierten Ressourcen erzielt werden.
  • Während viele Aufgaben von der Nutzung einer Edge-Lösung profitieren können, eignen sich einige spezielle Anwendungen besonders für den Einsatz in einer solchen Umgebung. So können Geräte wie Drohnen, autonome Autos, Roboter und andere eine extrem schnelle Verarbeitung erfordern - so schnell, dass das Senden von Daten in eine Cloud-Umgebung und das Zurücksenden zur Unterstützung der Datenverarbeitung einfach zu langsam sein kann. Ebenso können Maschinen wie Lokomotiven und Gasturbinen, die durch den Einsatz einer Vielzahl von datenerzeugenden Sensoren große Mengen an Informationen generieren, von den schnellen Datenverarbeitungsfunktionen einer Edge-Lösung profitieren. Ein weiteres Beispiel: Einige loT-Geräte wie vernetzte Videokameras eignen sich möglicherweise nicht für die Nutzung cloudbasierter Ressourcen, da es (nicht nur aus Sicht des Datenschutzes, der Sicherheit oder aus finanzieller Sicht) unpraktisch sein kann, die Daten in die Cloud zu senden, allein schon wegen der damit verbundenen Datenmenge. Daher sind viele Aufgaben, bei denen es wirklich um Datenverarbeitung, - speicherung oder -kommunikation geht, besser für Plattformen geeignet, die Edge-Lösungen wie die oben beschriebenen Speichersysteme umfassen.
  • Betrachten wir ein konkretes Beispiel für die Bestandsverwaltung in einem Lager, einem Vertriebszentrum oder einem ähnlichen Ort. Ein großes Lager, eine Lagerhaltung, ein Versand, eine Auftragsabwicklung, eine Fertigung oder ein anderer Betrieb verfügt über eine große Menge an Inventar in den Regalen und über hochauflösende Digitalkameras, die eine Flut großer Daten produzieren. Alle diese Daten können in ein Bildverarbeitungssystem eingespeist werden, das die Datenmenge auf einen Strom kleiner Daten reduziert. Alle kleinen Daten können vor Ort in einem Speicher abgelegt werden. Der lokale Speicher am Rande der Anlage kann mit der Cloud verbunden werden, um externe Berichte, Echtzeitkontrolle und Cloud-Speicherung zu ermöglichen. Die Bestandsverwaltung kann mit den Ergebnissen der Bildverarbeitung durchgeführt werden, so dass der Bestand in den Regalen nachverfolgt und wieder aufgefüllt, verschoben, versandt, mit neuen Produkten ergänzt oder auslaufende/veraltete Produkte gelöscht werden können, usw. Das oben beschriebene Szenario ist ideal geeignet für die oben beschriebenen konfigurierbaren Verarbeitungs- und Speichersysteme. Eine Kombination aus Blades, die nur für die Verarbeitung von Daten zuständig sind, und Offload-Blades, die für die Bildverarbeitung geeignet sind, vielleicht mit Deep Learning auf Offload-FPGA- oder Offload-Custom-Blades, könnte den Strom großer Daten von allen Digitalkameras aufnehmen und den Strom kleiner Daten erzeugen. Alle kleinen Daten könnten dann von Speicherknoten gespeichert werden, die mit Speichereinheiten in einer beliebigen Kombination von Speicherblades arbeiten, die den Datenfluss am besten bewältigen. Dies ist ein Beispiel für die Beschleunigung und Integration von Speicherung und Funktionen. Je nach dem Bedarf an externer Kommunikation mit der Cloud und externer Verarbeitung in der Cloud und je nach der Zuverlässigkeit der Netzwerkverbindungen und Cloud-Ressourcen könnte das System für die Speicher- und Rechenverwaltung mit stoßweiser Arbeitsbelastung und variabler Leitfähigkeitszuverlässigkeit dimensioniert werden. In Abhängigkeit von anderen Aspekten der Bestandsverwaltung könnte das System auch für die Planung und Verwaltung von Ressourcen in einer hybriden Edge-/Cloud-Umgebung konfiguriert werden.
  • Die oben beschriebenen Speichersysteme können allein oder in Kombination mit anderen Rechenressourcen als Netzwerk-Edge-Plattform dienen, die Rechenressourcen, Speicherressourcen, Netzressourcen, Cloud-Technologien und Netz-Virtualisierungstechnologien usw. kombiniert. Als Teil des Netzwerks kann der Edge ähnliche Eigenschaften wie andere Netzeinrichtungen aufweisen, vom Kundenstandort und Backhaul-Aggregationseinrichtungen bis hin zu Points of Presence (PoPs) und regionalen Rechenzentren. Die Leser werden verstehen, dass Netzwerk-Workloads, wie z. B. virtuelle Netzwerkfunktionen (VNFs) und andere, auf der Netzwerk-Edge-Plattform angesiedelt sein werden. Durch eine Kombination aus Containern und virtuellen Maschinen kann die Network-Edge-Plattform auf Controller und Scheduler zurückgreifen, die nicht mehr geografisch mit den Datenverarbeitungsressourcen verbunden sind. Die Funktionen können als Microservices in Steuerebenen, Benutzer- und Datenebenen oder sogar Zustandsmaschinen aufgeteilt werden, so dass unabhängige Optimierungs- und Skalierungstechniken angewendet werden können. Solche Benutzer- und Datenebenen können durch verstärkte Beschleuniger ermöglicht werden, sowohl durch solche, die sich in Serverplattformen befinden, wie FPGAs und Smart NICs, als auch durch SDN-fähiges Handelssilizium und programmierbare ASICs.
  • Die oben beschriebenen Speichersysteme können auch für den Einsatz in der Big-Data-Analytik optimiert werden. Big-Data-Analytik kann allgemein als der Prozess der Untersuchung großer und vielfältiger Datensätze beschrieben werden, um verborgene Muster, unbekannte Korrelationen, Markttrends, Kundenpräferenzen und andere nützliche Informationen aufzudecken, die Unternehmen helfen können, fundiertere Geschäftsentscheidungen zu treffen. Big-Data-Analyseanwendungen ermöglichen es Datenwissenschaftlern, Prognosemodellierern, Statistikern und anderen Analysefachleuten, wachsende Mengen an strukturierten Transaktionsdaten sowie andere Formen von Daten zu analysieren, die von herkömmlichen Business-Intelligence- (Bl) und Analyseprogrammen oft nicht genutzt werden. Im Rahmen dieses Prozesses können halbstrukturierte und unstrukturierte Daten, wie z. B. Internet-Clickstream-Daten, Webserver-Protokolle, Social-Media-Inhalte, Texte aus Kunden-E-Mails und Umfrageantworten, Mobiltelefon-Anrufdetailaufzeichnungen, loT-Sensordaten und andere Daten in eine strukturierte Form umgewandelt werden. Big-Data-Analytik ist eine Form der fortgeschrittenen Analytik, die komplexe Anwendungen mit Elementen wie Vorhersagemodellen, statistischen Algorithmen und Was-wäre-wenn-Analysen umfasst, die von leistungsstarken Analysesystemen unterstützt werden.
  • Die oben beschriebenen Speichersysteme können auch Anwendungen unterstützen (einschließlich der Implementierung als Systemschnittstelle), die Aufgaben in Reaktion auf menschliche Sprache ausführen. So können die Speichersysteme beispielsweise die Ausführung intelligenter persönlicher Assistentenanwendungen wie Alexa von Amazon, Siri von Apple, Google Voice, Bixby von Samsung, Cortana von Microsoft und andere unterstützen. Während die im vorigen Satz beschriebenen Beispiele die Sprache als Eingabe verwenden, können die oben beschriebenen Speichersysteme auch Chatbots, Talkbots, Chatterbots oder künstliche Gesprächsentitäten oder andere Anwendungen unterstützen, die so konfiguriert sind, dass sie ein Gespräch über auditive oder textuelle Verfahren führen. Ebenso kann das Speichersystem eine solche Anwendung tatsächlich ausführen, um einem Benutzer, z. B. einem Systemadministrator, die Interaktion mit dem Speichersystem über Sprache zu ermöglichen. Solche Anwendungen sind im Allgemeinen in der Lage, Sprachinteraktion, Musikwiedergabe, das Erstellen von Aufgabenlisten, das Einstellen von Alarmen, das Streaming von Podcasts, das Abspielen von Hörbüchern und das Bereitstellen von Wetter-, Verkehrs- und anderen Echtzeitinformationen, wie z. B. Nachrichten, zu ermöglichen, obwohl in Ausführungsformen gemäß der vorliegenden Offenlegung solche Anwendungen als Schnittstellen zu verschiedenen Systemverwaltungsvorgängen verwendet werden können.
  • Die oben beschriebenen Speichersysteme können auch Kl-Plattformen implementieren, um die Vision eines selbststeuernden Speichers zu verwirklichen. Solche Kl-Plattformen können so konfiguriert werden, dass sie globale prädiktive Intelligenz liefern, indem sie große Mengen von Telemetriedaten des Speichersystems sammeln und analysieren, um mühelos Verwaltung, Analyse und Support zu ermöglichen. Solche Speichersysteme können sowohl die Kapazität als auch die Leistung vorhersagen und intelligente Empfehlungen für den Einsatz, die Interaktion und die Optimierung von Arbeitslasten geben. Solche Kl-Plattformen können so konfiguriert werden, dass sie alle eingehenden Telemetriedaten des Speichersystems mit einer Bibliothek von thematischen Fingerabdrücken abgleichen, um Störungen in Echtzeit vorherzusagen und zu beheben, bevor sie sich auf Kundenumgebungen auswirken, und Hunderte von leistungsbezogenen Variablen erfassen, die zur Vorhersage der Leistungsbelastung verwendet werden.
  • Die oben beschriebenen Speichersysteme können die serielle oder gleichzeitige Ausführung von Anwendungen der künstlichen Intelligenz, Anwendungen des maschinellen Lernens, Datenanalyseanwendungen, Datentransformationen und anderen Aufgaben unterstützen, die zusammen eine Kl-Leiter bilden können. Eine solche Kl-Leiter kann durch die Kombination solcher Elemente zu einer vollständigen Data-Science-Pipeline gebildet werden, wobei Abhängigkeiten zwischen den Elementen der Kl-Leiter bestehen. Beispielsweise kann KI voraussetzen, dass eine Form des maschinellen Lernens stattgefunden hat, maschinelles Lernen kann voraussetzen, dass eine Form der Analyse stattgefunden hat, Analyse kann voraussetzen, dass eine Form der Daten- und Informationsarchitektur stattgefunden hat, und so weiter. So kann jedes Element als eine Sprosse auf einer Kl-Leiter betrachtet werden, die zusammen eine vollständige und hochentwickelte Kl-Lösung bilden kann.
  • Die oben beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um eine umfassende KI-Erfahrung bereitzustellen, bei der Kl weite und ausgedehnte Aspekte der Wirtschaft und des Lebens durchdringt. Beispielsweise kann KI eine wichtige Rolle bei der Bereitstellung von Deep Learning-Lösungen, Deep Reinforcement Learning-Lösungen, Lösungen für künstliche allgemeine Intelligenz, autonomen Fahrzeugen, kognitiven Computerlösungen, kommerziellen UAVs oder Drohnen, konversationellen Benutzerschnittstellen, Unternehmenstaxonomien, Ontologie-Management-Lösungen, maschinellen Lernlösungen, Smart Dust, intelligenten Robotern, intelligenten Arbeitsplätzen und vielen anderen spielen. Die oben beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um ein breites Spektrum an transparenten immersiven Erfahrungen zu bieten, bei denen die Technologie Transparenz zwischen Menschen, Unternehmen und Dingen schaffen kann. Solche transparenten, immersiven Erfahrungen können in Form von Augmented-Reality-Technologien, Connected Homes, Virtual-Reality-Technologien, Brain-Computer-Interfaces, Human-Augmentation-Technologien, Nanoröhrenelektronik, volumetrischen Displays, 4D-Drucktechnologien oder anderen bereitgestellt werden. Die oben beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, zur Unterstützung einer Vielzahl von digitalen Plattformen verwendet werden. Solche digitalen Plattformen können beispielsweise 5G-Mobilfunksysteme und -plattformen, digitale Zwillingsplattformen, Edge-Computing-Plattformen, loT-Plattformen, Quantencomputerplattformen, serverlose PaaS, softwaredefinierte Sicherheit, neuromorphe Computerplattformen usw. umfassen.
  • Die Leser werden verstehen, dass einige transparente immersive Erfahrungen die Verwendung von digitalen Zwillingen verschiedener „Dinge“ wie Menschen, Orte, Prozesse, Systeme usw. beinhalten können. Solche digitalen Zwillinge und andere immersive Technologien können die Art und Weise, wie Menschen mit Technologie interagieren, verändern, da Konversationsplattformen, Augmented Reality, Virtual Reality und Mixed Reality eine natürlichere und immersivere Interaktion mit der digitalen Welt ermöglichen. Tatsächlich können digitale Zwillinge mit der realen Welt verbunden werden, vielleicht sogar in Echtzeit, um den Zustand einer Sache oder eines Systems zu verstehen, auf Veränderungen zu reagieren usw. Da digitale Zwillinge riesige Mengen an Informationen über einzelne Assets und Gruppen von Assets konsolidieren (und möglicherweise sogar die Kontrolle über diese Assets übernehmen), können digitale Zwillinge miteinander kommunizieren, um digitale Fabrikmodelle von mehreren miteinander verbundenen digitalen Zwillingen zu erstellen.
  • Die oben beschriebenen Speichersysteme können auch Teil einer Multi-Cloud-Umgebung sein, in der mehrere Cloud-Computing- und Speicherdienste in einer einzigen heterogenen Architektur eingesetzt werden. Um den Betrieb einer solchen Multi-Cloud-Umgebung zu erleichtern, können DevOps-Tools eingesetzt werden, um eine Cloudübergreifende Orchestrierung zu ermöglichen. Ebenso können Tools für die kontinuierliche Entwicklung und die kontinuierliche Integration eingesetzt werden, um die Prozesse für die kontinuierliche Integration und Bereitstellung, die Einführung neuer Funktionen und die Bereitstellung von Cloud-Workloads zu standardisieren. Durch die Standardisierung dieser Prozesse kann eine Multi-Cloud-Strategie implementiert werden, die die Nutzung des besten Anbieters für jede Arbeitslast ermöglicht. Darüber hinaus können Tools zur Anwendungsüberwachung und -transparenz eingesetzt werden, um Anwendungs-Workloads zwischen verschiedenen Clouds zu verschieben, Leistungsprobleme zu erkennen und andere Aufgaben zu erfüllen. Darüber hinaus können Sicherheits- und Compliance-Tools eingesetzt werden, um die Einhaltung von Sicherheitsanforderungen, gesetzlichen Vorschriften usw. zu gewährleisten. Eine solche Multi-Cloud-Umgebung kann auch Tools für die Anwendungsbereitstellung und die intelligente Verwaltung von Arbeitslasten umfassen, um eine effiziente Anwendungsbereitstellung zu gewährleisten und Arbeitslasten über die verteilte und heterogene Infrastruktur zu lenken, sowie Tools, die die Bereitstellung und Wartung von paketierten und benutzerdefinierten Anwendungen in der Cloud erleichtern und die Übertragbarkeit zwischen Clouds ermöglichen. Die Multi-Cloud-Umgebung kann in ähnlicher Weise Werkzeuge für die Datenportabilität umfassen.
  • Die oben beschriebenen Speichersysteme können als Teil einer Plattform verwendet werden, um die Verwendung von Krypto-Ankern zu ermöglichen, die zur Authentifizierung der Herkunft und des Inhalts eines Produkts verwendet werden können, um sicherzustellen, dass es mit einem mit dem Produkt verbundenen Blockchain-Datensatz übereinstimmt. Solche Krypto-Anker können viele Formen annehmen, z. B. als essbare Tinte, als mobiler Sensor, als Mikrochip und andere. In ähnlicher Weise können die oben beschriebenen Speichersysteme als Teil einer Reihe von Werkzeugen zur Sicherung der auf dem Speichersystem gespeicherten Daten verschiedene Verschlüsselungstechnologien und - verfahren implementieren, einschließlich der Gitterkryptografie. Die Gitterkryptografie kann Konstruktionen von kryptografischen Primitiven beinhalten, die entweder in der Konstruktion selbst oder im Sicherheitsnachweis mit Gittern arbeiten. Im Gegensatz zu Public-Key-Verfahren wie RSA-, Diffie-Hellman- oder Elliptic-Curve-Kryptosystemen, die leicht von einem Quantencomputer angegriffen werden können, scheinen einige gitterbasierte Konstruktionen sowohl gegen Angriffe durch klassische als auch durch Quantencomputer resistent zu sein.
  • Ein Quantencomputer ist ein Gerät, das Quantenberechnungen durchführt. Quantencomputer sind Rechner, die quantenmechanische Phänomene wie Überlagerung und Verschränkung nutzen. Quantencomputer unterscheiden sich von herkömmlichen Computern, die auf Transistoren basieren, da bei diesen Computern die Daten in binären Ziffern (Bits) kodiert werden müssen, von denen sich jede immer in einem von zwei bestimmten Zuständen (0 oder 1) befindet. Im Gegensatz zu herkömmlichen Computern verwenden Quantencomputer Quantenbits, die sich in Überlagerungen von Zuständen befinden können. Ein Quantencomputer verwaltet eine Folge von Qubits, wobei ein einzelnes Qubit eine Eins, eine Null oder eine beliebige Quantenüberlagerung dieser beiden Qubit-Zustände darstellen kann. Ein Qubit-Paar kann sich in einer beliebigen Quantenüberlagerung von 4 Zuständen befinden, und drei Qubits in einer beliebigen Überlagerung von 8 Zuständen. Ein Quantencomputer mit n Qubits kann sich im Allgemeinen in einer beliebigen Überlagerung von bis zu 2^n verschiedenen Zuständen gleichzeitig befinden, während sich ein herkömmlicher Computer immer nur in einem dieser Zustände befinden kann. Eine Quanten-Turing-Maschine ist ein theoretisches Modell eines solchen Computers.
  • Die oben beschriebenen Speichersysteme können auch mit FPGA-beschleunigten Servern als Teil einer größeren Kl- oder ML-Infrastruktur gepaart werden. Solche FPGA-beschleunigten Server können sich in der Nähe (z. B. im selben Rechenzentrum) der oben beschriebenen Speichersysteme befinden oder sogar in eine Appliance integriert sein, die ein oder mehrere Speichersysteme, einen oder mehrere FPGA-beschleunigte Server, eine Netzwerkinfrastruktur, die die Kommunikation zwischen dem einen oder den mehreren Speichersystemen und dem einen oder den mehreren FPGA-beschleunigten Servern unterstützt, sowie andere Hardware- und Softwarekomponenten umfasst. Alternativ können sich FPGA-beschleunigte Server in einer Cloud-Computing-Umgebung befinden, die zur Ausführung rechenbezogener Aufgaben für Kl- und ML-Aufgaben verwendet werden kann. Jede der oben beschriebenen Ausführungsformen kann gemeinsam als FPGA-basierte KI-oder ML-Plattform verwendet werden. Der Leser wird verstehen, dass in einigen Ausführungsformen der FPGA-basierten Kl- oder ML-Plattform die FPGAs, die in den FPGA-beschleunigten Servern enthalten sind, für verschiedene Arten von ML-Modellen (z. B. LSTMs, CNNs, GRUs) rekonfiguriert werden können. Die Möglichkeit, die in den FPGA-beschleunigten Servern enthaltenen FPGAs neu zu konfigurieren, kann die Beschleunigung einer ML- oder Kl-Anwendung auf der Grundlage der optimalen numerischen Präzision und des am häufigsten verwendeten Speichermodells ermöglichen. Die Leser werden verstehen, dass durch die Behandlung der Sammlung von FPGA-beschleunigten Servern als FPGA-Pool jede CPU im Rechenzentrum den FPGA-Pool als gemeinsam genutzten Hardware-Microservice nutzen kann, anstatt einen Server auf dedizierte Beschleuniger zu beschränken, die an ihn angeschlossen sind.
  • Die oben beschriebenen FPGA-beschleunigten Server und GPU-beschleunigten Server können ein Rechenmodell implementieren, bei dem das Modell des maschinellen Lernens und die Parameter in den On-Chip-Speicher mit hoher Bandbreite eingebettet sind und viele Daten durch den On-Chip-Speicher mit hoher Bandbreite strömen, anstatt eine kleine Datenmenge in einer CPU zu speichern und einen langen Strom von Befehlen darüber laufen zu lassen, wie dies bei traditionelleren Rechenmodellen der Fall ist. FPGAs können für dieses Berechnungsmodell sogar effizienter sein als GPUs, da die FPGAs nur mit den Anweisungen programmiert werden können, die für diese Art von Berechnungsmodell erforderlich sind.
  • Die oben beschriebenen Speichersysteme können so konfiguriert werden, dass sie eine parallele Speicherung ermöglichen, z. B. durch die Verwendung eines parallelen Dateisystems wie BeeGFS. Solche parallelen Dateisysteme können eine verteilte Metadatenarchitektur enthalten. Das parallele Dateisystem kann beispielsweise eine Vielzahl von Metadatenservern umfassen, auf die die Metadaten verteilt werden, sowie Komponenten, die Dienste für Clients und Speicherserver umfassen. Durch die Verwendung eines parallelen Dateisystems können Dateiinhalte über eine Vielzahl von Speicherservern unter Verwendung von Striping verteilt werden, und Metadaten können über eine Vielzahl von Metadatenservern auf einer Verzeichnisebene verteilt werden, wobei jeder Server einen Teil des gesamten Dateisystembaums speichert. In einigen Ausführungsformen können die Speicherserver und Metadatenserver im Userspace auf einem bestehenden lokalen Dateisystem laufen. Außerdem ist für die Client-Dienste, die Metadatenserver oder die Hardwareserver keine spezielle Hardware erforderlich, da die Metadatenserver, die Speicherserver und sogar die Client-Dienste auf denselben Rechnern ausgeführt werden können.
  • Die Leser werden verstehen, dass teilweise aufgrund des Aufkommens vieler der oben genannten Technologien, einschließlich mobiler Endgeräte, Cloud-Dienste, sozialer Netzwerke, Big-Data-Analysen usw., eine IT-Plattform erforderlich sein kann, um all diese Technologien zu integrieren und neue Geschäftsmöglichkeiten durch die schnelle Bereitstellung von umsatzsteigernden Produkten, Diensten und Erfahrungen zu fördern - und nicht nur die Technologie zur Automatisierung interner Geschäftsprozesse bereitzustellen. IT-Organisationen müssen unter Umständen ein Gleichgewicht zwischen den Ressourcen und Investitionen finden, die erforderlich sind, um bestehende Kernsysteme aufrechtzuerhalten und gleichzeitig Technologien zu integrieren, um eine IT-Plattform zu schaffen, die Geschwindigkeit und Flexibilität in Bereichen wie beispielsweise der Nutzung von Big Data, der Verwaltung unstrukturierter Daten und der Arbeit mit Cloud-Anwendungen und -Diensten bietet. Eine mögliche Ausführungsform einer solchen informationstechnischen Plattform ist eine zusammensetzbare Infrastruktur, die fluide Ressourcenpools umfasst, wie viele der oben beschriebenen Systeme, die den sich ändernden Anforderungen von Anwendungen gerecht werden können, indem sie die Zusammensetzung und Neuzusammensetzung von Blöcken disaggregierter Rechen-, Speicher- und Netzinfrastruktur ermöglichen. Eine solche zusammensetzbare Infrastruktur kann auch eine einzige Verwaltungsschnittstelle zur Beseitigung der Komplexität und eine einheitliche API zum Erkennen, Suchen, Inventarisieren, Konfigurieren, Bereitstellen, Aktualisieren und Diagnostizieren der zusammensetzbaren Infrastruktur umfassen.
  • Die oben beschriebenen Systeme können die Ausführung einer breiten Palette von Softwareanwendungen unterstützen. Solche Softwareanwendungen können auf unterschiedliche Weise bereitgestellt werden, einschließlich Container-basierter Bereitstellungsmodelle. Containerisierte Anwendungen können mit einer Vielzahl von Tools verwaltet werden. Beispielsweise können containerisierte Anwendungen mit Docker Swarm verwaltet werden, einem Clustering- und Scheduling-Tool für Docker-Container, mit dem IT-Administratoren und Entwickler einen Cluster von Docker-Knoten als ein einziges virtuelles System einrichten und verwalten können. Ebenso können containerisierte Anwendungen mit Hilfe von Kubernetes verwaltet werden, einem Container-Orchestrierungssystem zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Kubernetes kann auf Betriebssystemen wie z. B. Red Hat Enterprise Linux, Ubuntu Server, SUSE Linux Enterprise Server und anderen ausgeführt werden. In solchen Beispielen kann ein Master-Knoten Aufgaben an Worker/Minion-Knoten zuweisen. Kubernetes kann eine Reihe von Komponenten (z. B. kubelet, kube-proxy, cAdvisor) enthalten, die einzelne Knoten verwalten, sowie eine Reihe von Komponenten (z. B. etcd, API-Server, Scheduler, Control Manager), die eine Steuerungsebene bilden. Verschiedene Controller (z. B. Replication Controller, DaemonSet Controller) können den Zustand eines Kubernetes-Clusters steuern, indem sie eine Reihe von Pods verwalten, die einen oder mehrere Container enthalten, die auf einem einzelnen Knoten bereitgestellt werden. Containerisierte Anwendungen können verwendet werden, um ein serverloses, Cloud-natives Computing-Bereitstellungs- und Verwaltungsmodell für Softwareanwendungen zu erleichtern. Zur Unterstützung eines serverlosen, Cloud-nativen Computing-Bereitstellungs- und - Verwaltungsmodells für Softwareanwendungen können Container als Teil eines Mechanismus zur Ereignisbehandlung (z. B. AWS Lambdas) verwendet werden, sodass verschiedene Ereignisse dazu führen, dass eine containerisierte Anwendung gestartet wird, um als Event-Handler zu fungieren.
  • Die oben beschriebenen Systeme können auf verschiedene Weise eingesetzt werden, unter anderem so, dass sie Netze der fünften Generation („5G“) unterstützen. 5G-Netze können eine wesentlich schnellere Datenkommunikation unterstützen als frühere Generationen von Mobilfunknetzen und infolgedessen zu einer Disaggregation von Daten- und Rechenressourcen führen, da moderne große Rechenzentren an Bedeutung verlieren und beispielsweise durch lokalere Mikro-Rechenzentren ersetzt werden können, die sich in der Nähe der Mobilfunktürme befinden. Die oben beschriebenen Systeme können in solchen lokalen Mikro-Rechenzentren enthalten sein und können Teil von Multi-Access-Edge-Computing-Systemen („MEC“) sein oder mit diesen gekoppelt werden. Solche MEC-Systeme können Cloud-Computing-Funktionen und eine IT-Dienstumgebung am Rande des Mobilfunknetzes ermöglichen. Durch die Ausführung von Anwendungen und damit zusammenhängenden Verarbeitungsaufgaben näher am Mobilfunkkunden kann die Netzüberlastung verringert und die Leistung der Anwendungen verbessert werden. Die MEC-Technologie ist so konzipiert, dass sie an den Mobilfunk-Basisstationen oder anderen Edge-Knotenpunkten implementiert werden kann und eine flexible und schnelle Einführung neuer Anwendungen und Dienste für Kunden ermöglicht. MEC kann es Mobilfunkbetreibern auch ermöglichen, ihr Funkzugangsnetz („RAN“) für zugelassene Dritte wie Anwendungsentwickler und Inhaltsanbieter zu öffnen. Darüber hinaus können Edge Computing und Mikrorechenzentren die Kosten von Smartphones, die mit dem 5G-Netz arbeiten, erheblich senken, da die Kunden keine Geräte mit einer so intensiven Rechenleistung und den teuren erforderlichen Komponenten benötigen.
  • Die Leser werden verstehen, dass 5G-Netze mehr Daten erzeugen können als frühere Netzgenerationen, insbesondere angesichts der Tatsache, dass die hohe Netzwerkbandbreite, die 5G-Netze bieten, dazu führen kann, dass die 5G-Netze Datenmengen und -typen verarbeiten können (z. B. Sensordaten von selbstfahrenden Autos, von AR/VR-Technologien erzeugte Daten), die für Netze der vorherigen Generation nicht so gut geeignet waren. In solchen Beispielen kann die Skalierbarkeit, die die oben beschriebenen Systeme bieten, sehr wertvoll sein, wenn die Datenmenge zunimmt, die Einführung neuer Technologien steigt usw.
  • Zur weiteren Erläuterung zeigt 3C ein beispielhaftes Computergerät 350, das speziell für die Durchführung eines oder mehrerer der hier beschriebenen Prozesse konfiguriert werden kann. Wie in 3C dargestellt, kann die Rechenvorrichtung 350 eine Kommunikationsschnittstelle 352, einen Prozessor 354, ein Speichergerät 356 und ein Eingabe-/Ausgabemodul 358 umfassen, die über eine Kommunikationsinfrastruktur 360 miteinander verbunden sind. Obwohl in 3C ein beispielhaftes Computergerät 350 gezeigt wird, sind die in 3C dargestellten Komponenten nicht als Einschränkung zu verstehen. Zusätzliche oder alternative Komponenten können in anderen Ausführungsformen verwendet werden. Die in 3C gezeigten Komponenten des Computergeräts 350 werden nun im Detail beschrieben.
  • Die Kommunikationsschnittstelle 352 kann so konfiguriert sein, dass sie mit einem oder mehreren Computergeräten kommuniziert. Beispiele für eine Kommunikationsschnittstelle 352 sind unter anderem eine drahtgebundene Netzwerkschnittstelle (z. B. eine Netzwerkschnittstellenkarte), eine drahtlose Netzwerkschnittstelle (z. B. eine drahtlose Netzwerkschnittstellenkarte), ein Modem, eine Audio-/Videoverbindung und jede andere geeignete Schnittstelle.
  • Der Prozessor 354 stellt im Allgemeinen eine beliebige Art oder Form einer Verarbeitungseinheit dar, die in der Lage ist, Daten zu verarbeiten und/oder eine oder mehrere der hier beschriebenen Anweisungen, Prozesse und/oder Operationen zu interpretieren, auszuführen und/oder deren Ausführung zu steuern. Der Prozessor 354 kann Operationen durchführen, indem er computerausführbare Anweisungen 362 (z. B. eine Anwendung, Software, einen Code und/oder eine andere ausführbare Dateninstanz) ausführt, die im Speichergerät 356 gespeichert sind.
  • Die Speichervorrichtung 356 kann ein oder mehrere Datenspeichermedien, -geräte oder -konfigurationen enthalten und kann jede Art, Form und Kombination von Datenspeichermedien und/oder -geräten verwenden. Beispielsweise kann die Speichervorrichtung 356 eine beliebige Kombination der hier beschriebenen nichtflüchtigen Medien und/oder flüchtigen Medien enthalten, ist aber nicht darauf beschränkt. Elektronische Daten, einschließlich der hierin beschriebenen Daten, können vorübergehend und/oder dauerhaft in der Speichervorrichtung 356 gespeichert werden. Beispielsweise können Daten, die für computerausführbare Anweisungen 362 stehen, die so konfiguriert sind, dass sie den Prozessor 354 anweisen, einen der hier beschriebenen Vorgänge durchzuführen, in der Speichervorrichtung 356 gespeichert werden. In einigen Beispielen können die Daten in einer oder mehreren Datenbanken angeordnet sein, die sich in der Speichervorrichtung 356 befinden.
  • Das E/A-Modul 358 kann ein oder mehrere E/A-Module enthalten, die so konfiguriert sind, dass sie Benutzereingaben empfangen und Benutzerausgaben bereitstellen. Das E/A-Modul 358 kann eine beliebige Hardware, Firmware, Software oder eine Kombination davon enthalten, die die Eingabe- und Ausgabefunktionen unterstützt. Beispielsweise kann das E/A-Modul 358 Hardware und/oder Software zur Erfassung von Benutzereingaben enthalten, einschließlich, aber nicht beschränkt auf eine Tastatur oder ein Tastenfeld, eine Touchscreen-Komponente (z. B. ein Touchscreen-Display), einen Empfänger (z. B. einen RF- oder Infrarotempfänger), Bewegungssensoren und/oder eine oder mehrere Eingabetasten.
  • Das E/A-Modul 358 kann ein oder mehrere Geräte zur Ausgabe an einen Benutzer enthalten, einschließlich, aber nicht beschränkt auf eine Grafik-Engine, ein Display (z. B. einen Bildschirm), einen oder mehrere Ausgabetreiber (z. B. Display-Treiber), einen oder mehrere Audio-Lautsprecher und einen oder mehrere Audio-Treiber. In bestimmten Ausführungsformen ist das E/A-Modul 358 so konfiguriert, dass es grafische Daten an eine Anzeige zur Präsentation für einen Benutzer liefert. Die grafischen Daten können eine oder mehrere grafische Benutzeroberflächen und/oder einen anderen grafischen Inhalt darstellen, der für eine bestimmte Implementierung geeignet ist. In einigen Beispielen kann jedes der hier beschriebenen Systeme, Computergeräte und/oder anderen Komponenten durch das Computergerät 350 implementiert werden.
  • Zur weiteren Erläuterung zeigt 3D ein Blockdiagramm, das eine Vielzahl von Speichersystemen (311-402, 311-404, 311-406) veranschaulicht, die einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung tragen. Obwohl weniger detailliert dargestellt, können die in 3D dargestellten Speichersysteme (311-402, 311-404, 311-406) den oben unter Bezugnahme auf die 1A-1D, die 2A-2G, die 3A-3B oder eine beliebige Kombination davon beschriebenen Speichersystemen ähnlich sein. Tatsächlich können die in 3D dargestellten Speichersysteme (311-402, 311-404, 311-406) die gleichen, weniger oder zusätzliche Komponenten wie die oben beschriebenen Speichersysteme enthalten.
  • In dem in 3D dargestellten Beispiel ist jedes der Speichersysteme (311-402, 311-404, 311-406) mit mindestens einem Computerprozessor (311-408, 311-410, 311-412), Computerspeicher (311-414, 311-416, 311-418) und Computerspeicher (311-420, 311-422, 311-424) dargestellt. Obwohl in einigen Ausführungsformen der Computerspeicher (311-414, 311-416, 311-418) und der Computerspeicher (311-420, 311-422, 311-424) Teil derselben Hardware-Vorrichtungen sein können, können in anderen Ausführungsformen der Computerspeicher (311-414, 311-416, 311-418) und der Computerspeicher (311-420, 311-422, 311-424) Teil verschiedener Hardware-Vorrichtungen sein. Der Unterschied zwischen dem Computerspeicher (311-414, 311-416, 311-418) und dem Computerspeicher (311-420, 311-422, 311-424) kann in diesem speziellen Beispiel darin bestehen, dass der Computerspeicher (311-414, 311-416, 311-418) physisch nahe bei den Computerprozessoren (311-408, 311-410, 311-412) befindet und Computerprogrammanweisungen speichern kann, die von den Computerprozessoren (311-408, 311-410, 311-412) ausgeführt werden, während der Computerspeicher (311-420, 311-422, 311-424) als nichtflüchtiger Speicher zum Speichern von Benutzerdaten, Metadaten, die die Benutzerdaten beschreiben, usw. ausgeführt ist. Unter Bezugnahme auf das obige Beispiel in 1A können sich zum Beispiel die Computerprozessoren (311-408, 311-410, 311-412) und der Computerspeicher (311-414, 311-416, 311-418) für ein bestimmtes Speichersystem (311-402, 311-404, 311-406) in einem oder mehreren Controllern (110A-110D) befinden, während die angeschlossenen Speichergeräte (171A-171F) als Computerspeicher (311-420, 311-422, 311-424) innerhalb eines bestimmten Speichersystems (311-402, 311-404, 311-406) dienen können.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) mit einem oder mehreren Pods (311-430, 311-432) gemäß einigen Ausführungsformen der vorliegenden Offenbarung verbunden sein. Jeder der in 3D dargestellten Pods (311-430, 311-432) kann einen Datensatz (311-426, 311-428) enthalten. Zum Beispiel enthält ein erster Pod (311-430), an den drei Speichersysteme (311-402, 311-404, 311-406) angeschlossen sind, einen ersten Datensatz (311-426), während ein zweiter Pod (311-432), an den zwei Speichersysteme (311-404, 311-406) angeschlossen sind, einen zweiten Datensatz (311-428) enthält. Wenn in einem solchen Beispiel ein bestimmtes Speichersystem an einen Pod angeschlossen wird, wird der Datensatz des Pods auf das bestimmte Speichersystem kopiert und dann auf dem neuesten Stand gehalten, wenn der Datensatz geändert wird. Speichersysteme können von einem Pod entfernt werden, was dazu führt, dass der Datensatz auf dem entfernten Speichersystem nicht mehr auf dem neuesten Stand gehalten wird. In dem in 3D dargestellten Beispiel kann jedes Speichersystem, das für einen Pod aktiv ist (es ist ein aktuelles, in Betrieb befindliches, nicht gestörtes Element eines nicht gestörten Pods), Aufforderungen zum Ändern oder zum Lesen des Datensatzes des Pods empfangen und bearbeiten.
  • In dem in 3D dargestellten Beispiel kann jeder Pod (311-430, 311-432) auch einen Satz von verwalteten Objekten und Verwaltungsoperationen sowie einen Satz von Zugriffsoperationen zum Ändern oder Lesen des Datensatzes (311-426, 311-428) enthalten, der mit dem jeweiligen Pod (311-430, 311-432) verbunden ist. In einem solchen Beispiel können die Verwaltungsoperationen verwaltete Objekte gleichwertig über jedes der Speichersysteme ändern oder abfragen. Ebenso können Zugriffsoperationen zum Lesen oder Ändern des Datenbestands gleichwertig über jedes der Speichersysteme erfolgen. In einem solchen Beispiel speichert zwar jedes Speichersystem eine separate Kopie des Datensatzes als eine eigene Teilmenge der gespeicherten und zur Verwendung durch das Speichersystem angekündigten Datensätze, aber die über ein beliebiges Speichersystem durchgeführten und abgeschlossenen Operationen zur Änderung verwalteter Objekte oder des Datensatzes spiegeln sich in nachfolgenden Verwaltungsobjekten zur Abfrage des Pods oder nachfolgenden Zugriffsoperationen zum Lesen des Datensatzes wider.
  • Die Leser werden verstehen, dass Pods mehr Funktionen implementieren können als nur einen geclusterten, synchron replizierten Datensatz. So können Pods beispielsweise zur Implementierung von Tenants verwendet werden, wobei die Datensätze in gewisser Weise sicher voneinander isoliert sind. Pods können auch zur Implementierung virtueller Arrays oder virtueller Speichersysteme verwendet werden, bei denen jeder Pod als eindeutige Speichereinheit in einem Netzwerk (z. B. einem Storage Area Network oder einem Internet Protocol-Netzwerk) mit separaten Adressen dargestellt wird. Im Falle eines Pods mit mehreren Speichersystemen, der ein virtuelles Speichersystem implementiert, können sich alle physischen Speichersysteme, die mit dem Pod verbunden sind, in gewisser Weise als ein und dasselbe Speichersystem darstellen (z. B. so, als wären die mehreren physischen Speichersysteme nichts anderes als mehrere Netzwerkanschlüsse an einem einzigen Speichersystem).
  • Pods können auch Verwaltungseinheiten sein, die eine Sammlung von Datenträgern, Dateisystemen, Objekt-/Analysespeichern, Snapshots und anderen Verwaltungseinheiten darstellen, bei denen administrative Änderungen (z. B. Namensänderungen, Eigenschaftsänderungen, Verwaltung von Exporten oder Berechtigungen für einen Teil des Pod-Datensatzes) auf einem beliebigen Speichersystem automatisch auf alle mit dem Pod verbundenen aktiven Speichersysteme übertragen werden. Darüber hinaus könnten Pods auch Einheiten der Datenerfassung und -analyse sein, in denen Leistungs- und Kapazitätskennzahlen in einer Weise dargestellt werden, die alle aktiven Speichersysteme für den Pod zusammenfasst oder die Datenerfassung und -analyse für jeden Pod getrennt aufruft oder vielleicht den Beitrag jedes angeschlossenen Speichersystems zum eingehenden Inhalt und zur Leistung für jeden Pod darstellt.
  • Ein Modell für die Pod-Zugehörigkeit kann als eine Liste von Speichersystemen und eine Teilmenge dieser Liste definiert werden, bei der die Speichersysteme als synchron für den Pod gelten. Ein Speichersystem kann als synchron für einen Pod betrachtet werden, wenn es zumindest innerhalb einer Wiederherstellung einen identischen Idle-Inhalt für die letzte geschriebene Kopie des dem Pod zugeordneten Datensatzes hat. Ein Idle-Inhalt ist der Inhalt, nachdem alle laufenden Änderungen abgeschlossen sind und keine neuen Änderungen verarbeitet wurden. Dies wird manchmal auch als „crash recoverable“ Konsistenz bezeichnet. Die Wiederherstellung eines Pods führt den Prozess des Ausgleichs von Unterschieden bei der Anwendung gleichzeitiger Aktualisierungen auf synchronisierte Speichersysteme im Pod durch. Die Wiederherstellung kann alle Inkonsistenzen zwischen den Speichersystemen beim Abschluss gleichzeitiger Änderungen beheben, die bei verschiedenen Elementen des Pods angefordert wurden, aber keinem Anforderer als erfolgreich abgeschlossen gemeldet wurden. Speichersysteme, die als Pod-Elemente aufgeführt sind, aber nicht als synchron für den Pod aufgeführt sind, können als vom Pod „abgetrennt“ bezeichnet werden. Speichersysteme, die als Pod-Elemente aufgeführt sind, für den Pod synchronisiert sind und derzeit für die aktive Bereitstellung von Daten für den Pod zur Verfügung stehen, sind für den Pod „online“.
  • Jedes Speichersystem, das ein Element eines Pods ist, kann seine eigene Kopie der Zugehörigkeit haben, einschließlich der Speichersysteme, von denen es zuletzt wusste, dass sie synchronisiert sind, und der Speichersysteme, von denen es zuletzt wusste, dass sie die gesamte Gruppe der Pod-Elemente umfassen. Um für einen Pod online zu sein, muss ein Speichersystem sich selbst als synchron für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als synchron für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es synchron ist und mit allen anderen Speichersystemen, die synchron sind, kommuniziert, dann muss es die Verarbeitung neuer eingehender Anfragen für den Pod einstellen (oder sie mit einem Fehler oder einer Ausnahme abschließen), bis es sicher sein kann, dass es synchron ist und mit allen anderen Speichersystemen, die synchron sind, kommuniziert. Ein erstes Speichersystem kann zu dem Schluss kommen, dass ein zweites gepaartes Speichersystem abgetrennt werden sollte, wodurch das erste Speichersystem fortfahren kann, da es nun mit allen Speichersystemen in der Liste synchronisiert ist. Es muss jedoch verhindert werden, dass das zweite Speichersystem zu dem Schluss kommt, dass das erste Speichersystem abgetrennt werden sollte, während das zweite Speichersystem den Betrieb fortsetzt. Dies würde zu einem „Split Brain“-Zustand führen, der unter anderem unvereinbare Datensätze, beschädigte Datensätze oder beschädigte Anwendungen zur Folge haben kann.
  • Die Situation, in der festgelegt werden muss, wie vorzugehen ist, wenn keine Kommunikation mit gepaarten Speichersystemen möglich ist, kann eintreten, wenn ein Speichersystem normal läuft und dann einen Kommunikationsverlust bemerkt, wenn es sich gerade von einem früheren Fehler erholt, wenn es neu startet oder nach einem vorübergehenden Stromausfall oder einem wiederhergestellten Kommunikationsausfall den Betrieb wieder aufnimmt, wenn es aus irgendeinem Grund den Betrieb von einem Satz von Speichersystem-Controllern auf einen anderen Satz umstellt oder während oder nach einer beliebigen Kombination dieser oder anderer Arten von Ereignissen. Jedes Mal, wenn ein Speichersystem, das mit einem Pod verbunden ist, nicht mit allen bekannten, nicht abgetrennten Elementen kommunizieren kann, kann das Speichersystem entweder kurz warten, bis die Kommunikation hergestellt werden kann, offline gehen und weiter warten, oder es kann auf irgendeine Weise feststellen, dass es sicher ist, das nicht kommunizierende Speichersystem abzutrennen, ohne Gefahr zu laufen, dass es zu einem Split Brain kommt, weil das nicht kommunizierende Speichersystem die alternative Sichtweise abschließt, und dann weitermachen. Wenn eine sichere Trennung schnell genug erfolgen kann, kann das Speichersystem für den Pod mit kaum mehr als einer kurzen Verzögerung und ohne daraus resultierende Anwendungsausfälle für Anwendungen, die Anfragen an die verbleibenden Online-Speichersysteme stellen können, online bleiben.
  • Ein Beispiel für diese Situation ist, wenn ein Speichersystem weiß, dass es nicht mehr aktuell ist. Dies kann beispielsweise der Fall sein, wenn ein erstes Speichersystem zum ersten Mal zu einem Pod hinzugefügt wird, der bereits mit einem oder mehreren Speichersystemen verbunden ist, oder wenn ein erstes Speichersystem eine erneute Verbindung zu einem anderen Speichersystem herstellt und feststellt, dass das andere Speichersystem das erste Speichersystem bereits als abgetrennt markiert hat. In diesem Fall wartet das erste Speichersystem einfach, bis es eine Verbindung zu einer anderen Gruppe von Speichersystemen herstellt, die mit dem Pod synchronisiert sind.
  • Dieses Modell erfordert ein gewisses Maß an Überlegungen darüber, wie Speichersysteme zu Pods oder zur Liste der synchronisierten Pod-Elemente hinzugefügt oder aus ihnen entfernt werden. Da jedes Speichersystem über eine eigene Kopie der Liste verfügt, zwei unabhängige Speichersysteme ihre lokale Kopie nicht genau zur gleichen Zeit aktualisieren können und die lokale Kopie alles ist, was bei einem Neustart oder in verschiedenen Fehlerszenarien zur Verfügung steht, muss darauf geachtet werden, dass vorübergehende Inkonsistenzen keine Probleme verursachen. Wenn z. B. ein Speichersystem für einen Pod synchron ist und ein zweites Speichersystem hinzugefügt wird und das zweite Speichersystem so aktualisiert wird, dass es beide Speichersysteme zuerst als synchron auflistet, könnte bei einem Fehler und einem Neustart beider Speichersysteme das zweite Speichersystem starten und darauf warten, eine Verbindung mit dem ersten Speichersystem herzustellen, während das erste Speichersystem nicht weiß, dass es auf das zweite Speichersystem warten sollte oder könnte. Wenn das zweite Speichersystem dann auf die Unfähigkeit, eine Verbindung mit dem ersten Speichersystem herzustellen, reagiert, indem es einen Abtrennungsprozess durchläuft, könnte es einen Prozess erfolgreich abschließen, von dem das erste Speichersystem nichts weiß, was zu einem Split Brain führt. Es muss also sichergestellt werden, dass die Speichersysteme nicht in unangemessener Weise darüber streiten, ob sie einen Abtrennungsprozess durchführen sollen, wenn sie nicht miteinander kommunizieren.
  • Eine Möglichkeit, um sicherzustellen, dass Speichersysteme nicht in unangemessener Weise darüber streiten, ob sie einen Abtrennungsprozess durchlaufen sollen, wenn sie nicht miteinander kommunizieren, besteht darin, sicherzustellen, dass beim Hinzufügen eines neuen Speichersystems zur Liste der synchronen Elemente eines Pods das neue Speichersystem zunächst speichert, dass es ein abgetrenntes Element ist (und vielleicht, dass es als synchrones Element hinzugefügt wird). Dann können die vorhandenen synchronen Speichersysteme lokal speichern, dass das neue Speichersystem ein synchrones Pod-Element ist, bevor das neue Speichersystem diese Tatsache lokal speichert. Wenn es eine Reihe von Neustarts oder Netzwerkausfälle gibt, bevor das neue Speichersystem seinen In-Sync-Status speichert, können die ursprünglichen Speichersysteme das neue Speichersystem wegen fehlender Kommunikation abkoppeln, aber das neue Speichersystem wird warten. Eine umgekehrte Version dieser Änderung könnte für das Entfernen eines kommunizierenden Speichersystems aus einem Pod erforderlich sein: Zuerst speichert das entfernte Speichersystem, dass es nicht mehr synchron ist, dann speichern die verbleibenden Speichersysteme, dass das entfernte Speichersystem nicht mehr synchron ist, dann löschen alle Speichersysteme das entfernte Speichersystem aus ihren Pod-Zugehörigkeitslisten. Je nach Implementierung ist ein zwischengeschalteter persistierter abgetrennter Zustand möglicherweise nicht erforderlich. Ob bei lokalen Kopien der Elemente-Listen Vorsicht geboten ist oder nicht, kann davon abhängen, welches Modell die Speichersysteme für die gegenseitige Überwachung oder für die Validierung ihrer Zugehörigkeit verwenden. Wenn für beides ein Konsensmodell verwendet wird oder wenn ein externes System (oder ein externes verteiltes oder geclustertes System) zur Speicherung und Validierung der Pod-Zugehörigkeit verwendet wird, dann spielen Inkonsistenzen in lokal gespeicherten Elemente-Listen möglicherweise keine Rolle.
  • Wenn die Kommunikation ausfällt oder ein oder mehrere Speichersysteme in einem Pod ausfallen, oder wenn ein Speichersystem hochfährt (oder auf einen sekundären Controller ausfällt) und nicht mit den gepaarten Speichersystemen eines Pods kommunizieren kann und es für ein oder mehrere Speichersysteme an der Zeit ist, ein oder mehrere gepaarte Speichersysteme zu trennen, muss ein Algorithmus oder Mechanismus eingesetzt werden, um zu entscheiden, dass es sicher ist, dies zu tun und die Trennung zu vollziehen. Eine Möglichkeit, Trennungen aufzulösen, ist die Verwendung eines Mehrheitsmodells (oder Quorum) für die Zugehörigkeit. Bei drei Speichersystemen können diese, solange zwei miteinander kommunizieren, vereinbaren, ein drittes Speichersystem, das nicht kommuniziert, zu trennen, aber dieses dritte Speichersystem kann nicht von sich aus entscheiden, eines der beiden anderen zu trennen. Verwirrung kann entstehen, wenn die Kommunikation der Speichersysteme inkonsistent ist. Zum Beispiel könnte Speichersystem A mit Speichersystem B kommunizieren, aber nicht mit C, während Speichersystem B sowohl mit A als auch mit C kommunizieren könnte.
  • Bei einem Quorum-Zugehörigkeitsmodell ist beim Hinzufügen und Entfernen von Speichersystemen Vorsicht geboten. Wenn zum Beispiel ein viertes Speichersystem hinzugefügt wird, beträgt die „Mehrheit“ der Speichersysteme zu diesem Zeitpunkt drei. Der Übergang von drei Speichersystemen (wobei zwei für die Mehrheit erforderlich sind) zu einem Pod mit einem vierten Speichersystem (wobei drei für die Mehrheit erforderlich sind) kann etwas Ähnliches erfordern wie das zuvor beschriebene Modell für das vorsichtige Hinzufügen eines Speichersystems zur In-Sync-Liste. Das vierte Speichersystem könnte sich beispielsweise zunächst in einem anschließenden, aber noch nicht angeschlossenen Zustand befinden, in dem es nie eine Abstimmung über die Beschlussfähigkeit auslösen würde. Sobald es sich in diesem Zustand befindet, könnten die ursprünglichen drei Pod-Elemente aktualisiert werden, um das vierte Element und die neue Anforderung einer Mehrheit von drei Speichersystemen zu kennen, um ein viertes abzulösen. Wird ein Speichersystem aus einem Pod entfernt, könnte dieses Speichersystem in ähnlicher Weise in einen lokal gespeicherten „Abtrennungs“-Zustand versetzt werden, bevor die anderen Pod-Elemente aktualisiert werden. Eine Variante ist die Verwendung eines verteilten Konsensmechanismus wie PAXOS oder RAFT zur Durchführung von Änderungen der Zugehörigkeit oder zur Bearbeitung von Abtrennungsanfragen.
  • Eine weitere Möglichkeit zur Verwaltung von Zugehörigkeitsübergängen ist die Verwendung eines externen Systems, das außerhalb der Speichersysteme selbst liegt, um die Pod-Zugehörigkeit zu verwalten. Um für einen Pod online zu werden, muss ein Speichersystem zunächst das externe Pod-Zugehörigkeitssystem kontaktieren, um zu überprüfen, ob es für den Pod synchronisiert ist. Jedes Speichersystem, das für einen Pod online ist, sollte dann in Kommunikation mit dem Pod-Zugehörigkeitssystem bleiben und warten oder offline gehen, wenn es die Verbindung verliert. Ein externer Pod-Membership-Manager könnte als hochverfügbarer Cluster mit verschiedenen Cluster-Tools wie Oracle RAC, Linux HA, VERITAS Cluster Server, IBM HACMP oder anderen implementiert werden. Ein externer Pod-Membership-Manager könnte auch verteilte Konfigurationstools wie Etcd oder Zookeeper oder eine zuverlässige verteilte Datenbank wie DynamoDB von Amazon verwenden.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) eine Anforderung zum Lesen eines Teils des Datensatzes (311-426, 311-428) empfangen und die Anforderung zum Lesen des Teils des Datensatzes lokal gemäß einigen Ausführungsformen der vorliegenden Offenbarung verarbeiten. Der Leser wird verstehen, dass, obwohl Anforderungen zum Ändern (z.B. eine Schreiboperation) des Datensatzes (311-426, 311-428) eine Koordination zwischen den Speichersystemen (311-402, 311-404, 311-406) in einem Pod erfordern, da der Datensatz (311-426, 311-428) über alle Speichersysteme (311-402, 311-402, 311-404, 311-406) in einem Pod konsistent sein sollte, erfordert die Beantwortung einer Anforderung zum Lesen eines Teils des Datenbestands (311-426, 311-428) keine ähnliche Koordination zwischen den Speichersystemen (311-402, 311-404, 311-406). So kann ein bestimmtes Speichersystem, das eine Leseanforderung erhält, die Leseanforderung lokal bedienen, indem es einen Teil des Datensatzes (311-426, 311-428) liest, der in den Speichergeräten des Speichersystems gespeichert ist, ohne eine synchrone Kommunikation mit anderen Speichersystemen im Pod. Bei Leseanfragen, die von einem Speichersystem für einen replizierten Datensatz in einem replizierten Cluster empfangen werden, wird erwartet, dass in den allermeisten Fällen jegliche Kommunikation vermieden wird, zumindest wenn sie von einem Speichersystem empfangen werden, das innerhalb eines Clusters läuft, welches ebenfalls nominell läuft. Solche Lesevorgänge sollten normalerweise einfach durch Lesen aus der lokalen Kopie eines geclusterten Datensatzes verarbeitet werden, ohne dass eine weitere Interaktion mit anderen Speichersystemen im Cluster erforderlich ist
  • Der Leser wird verstehen, dass die Speichersysteme Maßnahmen ergreifen können, um die Lesekonsistenz zu gewährleisten, so dass eine Leseanfrage unabhängig davon, welches Speichersystem die Leseanfrage bearbeitet, dasselbe Ergebnis liefert. So sollte beispielsweise der Inhalt des geclusterten Datensatzes für jeden Satz von Aktualisierungen, die von einem beliebigen Satz von Speichersystemen im Cluster empfangen werden, im gesamten Cluster konsistent sein, zumindest zu dem Zeitpunkt, zu dem die Aktualisierungen im Ruhezustand sind (alle früheren Änderungsvorgänge wurden als abgeschlossen angezeigt und es wurden keine neuen Aktualisierungsanforderungen empfangen und verarbeitet). Genauer gesagt können sich die Instanzen eines geclusterten Datensatzes in einer Reihe von Speichersystemen nur aufgrund von noch nicht abgeschlossenen Aktualisierungen unterscheiden. Das bedeutet zum Beispiel, dass zwei Schreibanforderungen, die sich in ihrem Datenträger-Block-Bereich überschneiden, oder eine Kombination aus einer Schreibanforderung und einem überlappenden Snapshot, einer Comparison-and-Write- oder einer Virtual-Block-Range-Kopie auf allen Kopien des Datensatzes ein konsistentes Ergebnis liefern müssen. Zwei Vorgänge sollten nicht zu einem Ergebnis führen, als ob sie in einer bestimmten Reihenfolge auf einem Speichersystem und in einer anderen Reihenfolge auf einem anderen Speichersystem des replizierten Clusters stattgefunden hätten.
  • Darüber hinaus können Leseanforderungen in der zeitlichen Reihenfolge konsistent gemacht werden. Wenn beispielsweise eine Leseanforderung auf einem replizierten Cluster empfangen und abgeschlossen wird und auf diese Leseanforderung eine weitere Leseanforderung in einem sich überschneidenden Adressbereich folgt, die von dem replizierten Cluster empfangen wird, und wenn eine oder beide Leseanforderungen sich in irgendeiner Weise zeitlich und im Volumenadressbereich mit einer Änderungsanforderung überschneiden, die von dem replizierten Cluster empfangen wird (unabhängig davon, ob die Leseanforderung oder die Änderung von demselben Speichersystem oder einem anderen Speichersystem in dem replizierten Cluster empfangen wird), dann sollte - wenn der erste Lesevorgang das Ergebnis der Aktualisierung widerspiegelt - der zweite Lesevorgang ebenfalls die Ergebnisse dieser Aktualisierung widerspiegeln, anstatt möglicherweise Daten zurückzugeben, die der Aktualisierung vorausgingen. Wenn der erste Lesevorgang die Aktualisierung nicht widerspiegelt, kann der zweite Lesevorgang entweder die Aktualisierung widerspiegeln oder nicht. Damit wird sichergestellt, dass zwischen zwei Leseanforderungen die „Zeit“ für ein Datensegment nicht zurücklaufen kann.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme erkennen und bestimmen, ob das betreffende Speichersystem im Pod verbleiben soll. Eine Unterbrechung der Datenkommunikation mit einem oder mehreren anderen Speichersystemen kann aus einer Vielzahl von Gründen auftreten. Beispielsweise kann eine Unterbrechung der Datenkommunikation mit einem oder mehreren anderen Speichersystemen auftreten, weil eines der Speichersysteme ausgefallen ist, weil eine Netzwerkverbindung ausgefallen ist, oder aus einem anderen Grund. Ein wichtiger Aspekt des synchronen replizierten Clustering ist die Gewährleistung, dass die Fehlerbehandlung nicht zu nicht wiederherstellbaren Inkonsistenzen oder inkonsistenten Antworten führt. Wenn beispielsweise ein Netzwerk zwischen zwei Speichersystemen ausfällt, kann höchstens eines der Speichersysteme die Verarbeitung neu eingehender E/A-Anfragen für einen Pod fortsetzen. Und wenn ein Speichersystem die Verarbeitung fortsetzt, kann das andere Speichersystem keine neuen Anfragen bis zum Abschluss verarbeiten, auch keine Leseanfragen.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch bestimmen, ob das jeweilige Speichersystem als Reaktion auf die Feststellung einer Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme in der Gruppe verbleiben soll. Wie bereits erwähnt, muss ein Speichersystem, um als Teil eines Pods „online“ zu sein, sich selbst als synchron für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als synchron für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es synchron ist und mit allen anderen Speichersystemen, die synchron sind, kommuniziert, kann es die Bearbeitung neu eingehender Aufforderungen zum Zugriff auf den Datensatz einstellen (311-426, 311-428). So kann das Speichersystem bestimmen, ob das betreffende Speichersystem als Teil des Pods online bleiben soll, indem es z. B. feststellt, ob es mit allen anderen Speichersystemen, die es für den Pod als synchron betrachtet, kommunizieren kann (z. B. über eine oder mehrere Testnachrichten), indem es feststellt, ob alle anderen Speichersysteme, die es als synchron für den Pod betrachtet, das Speichersystem ebenfalls als an den Pod angeschlossen betrachten, durch eine Kombination beider Schritte, bei denen das bestimmte Speichersystem bestätigen muss, dass es mit allen anderen Speichersystemen, die es als synchron für den Pod betrachtet, kommunizieren kann und dass alle anderen Speichersysteme, die es als synchron für den Pod betrachtet, das Speichersystem ebenfalls als an den Pod angeschlossen betrachten, oder durch einen anderen Mechanismus.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) den Datensatz auf dem bestimmten Speichersystem auch für Verwaltungs- und Datensatzoperationen zugänglich halten, wenn festgestellt wird, dass das bestimmte Speichersystem im Pod verbleiben soll. Das Speichersystem kann den Datensatz (311-426, 311-428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen zugänglich halten, indem es beispielsweise Aufforderungen zum Zugriff auf die Version des Datensatzes (311-426, 311-428), die auf dem Speichersystem gespeichert ist, annimmt und solche Anfragen verarbeitet, durch Annahme und Verarbeitung von Verwaltungsoperationen im Zusammenhang mit dem Datensatz (311-426, 311-428), die von einem Host oder autorisierten Administrator ausgegeben werden, durch Annahme und Verarbeitung von Verwaltungsoperationen im Zusammenhang mit dem Datensatz (311-426, 311-428), die von einem der anderen Speichersysteme ausgegeben werden, oder auf andere Weise.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) jedoch den Datensatz auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen unzugänglich machen, wenn festgestellt wird, dass das bestimmte Speichersystem nicht im Pod verbleiben sollte. Das Speichersystem kann den Datensatz (311-426, 311-428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen unzugänglich machen, z. B. durch Zurückweisen von Aufforderungen zum Zugriff auf die Version des Datensatzes (311-426, 311-428), die auf dem Speichersystem gespeichert ist, durch Ablehnung von Verwaltungsoperationen in Verbindung mit dem Datensatz (311-426, 311-428), die von einem Host oder einem anderen autorisierten Administrator ausgegeben werden, durch Ablehnung von Verwaltungsoperationen in Verbindung mit dem Datensatz (311-426, 311-428), die von einem der anderen Speichersysteme im Pod ausgegeben werden, oder auf andere Weise.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch erkennen, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme repariert wurde, und den Datensatz auf dem jeweiligen Speichersystem für die Verwaltung und Datensatzoperationen zugänglich machen. Das Speichersystem kann erkennen, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme behoben wurde, indem es beispielsweise eine Nachricht von dem einen oder den mehreren anderen Speichersystemen erhält. Als Reaktion auf die Feststellung, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme behoben wurde, kann das Speichersystem den Datensatz (311-426, 311-428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen zugänglich machen, sobald das zuvor abgetrennte Speichersystem wieder mit den Speichersystemen synchronisiert wurde, die mit dem Pod verbunden blieben.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch vom Pod offline gehen, so dass das jeweilige Speichersystem keine Verwaltungs- und Datensatzoperationen mehr zulässt. Die dargestellten Speichersysteme (311-402, 311-404, 311-406) können aus einer Vielzahl von Gründen offline gehen, so dass das jeweilige Speichersystem keine Verwaltungs- und Datensatzoperationen mehr zulässt. Beispielsweise können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch aufgrund eines Fehlers im Speichersystem selbst, aufgrund einer Aktualisierung oder einer anderen Wartung des Speichersystems, aufgrund von Kommunikationsfehlern oder aus vielen anderen Gründen vom Pod getrennt werden. In einem solchen Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) anschließend den Datensatz auf dem jeweiligen Speichersystem aktualisieren, um alle Aktualisierungen des Datensatzes einzubeziehen, seit das jeweilige Speichersystem offline gegangen ist, und wieder mit dem Pod online gehen, so dass das jeweilige Speichersystem Verwaltungs- und Datensatzoperationen ermöglicht, wie in den nachstehenden Abschnitten zur Resynchronisierung ausführlicher beschrieben wird.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch ein Zielspeichersystem für den asynchronen Empfang des Datensatzes identifizieren, wobei das Zielspeichersystem nicht zu der Vielzahl von Speichersystemen gehört, über die der Datensatz synchron repliziert wird. Ein solches Zielspeichersystem kann z. B. ein Backup-Speichersystem oder ein Speichersystem sein, das den synchron replizierten Datensatz verwendet usw. Die synchrone Replikation kann sogar dazu genutzt werden, Kopien eines Datensatzes näher an einem Server-Rack zu verteilen, um die lokale Leseleistung zu verbessern. Ein solcher Fall sind kleinere Top-of-Rack-Speichersysteme, die symmetrisch auf größere Speichersysteme repliziert werden, die sich zentral im Rechenzentrum oder auf dem Campus befinden und wo diese größeren Speichersysteme aus Gründen der Zuverlässigkeit sorgfältiger verwaltet werden oder an externe Netzwerke für asynchrone Replikations- oder Sicherungsdienste angeschlossen sind.
  • In dem in 3D dargestellten Beispiel können die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch einen Teil des Datensatzes identifizieren, der von keinem der anderen Speichersysteme asynchron in das Zielspeichersystem repliziert wird, und können den Teil des Datensatzes, der von keinem der anderen Speichersysteme asynchron in das Zielspeichersystem repliziert wird, asynchron in das Zielspeichersystem replizieren, wobei die zwei oder mehr Speichersysteme gemeinsam den gesamten Datensatz in das Zielspeichersystem replizieren. Auf diese Weise kann die mit der asynchronen Replikation eines bestimmten Datensatzes verbundene Bearbeitung unter den Elementen eines Pods aufgeteilt werden, so dass jedes Speichersystem in einem Pod nur für die asynchrone Replikation einer Teilmenge eines Datensatzes an das Zielspeichersystem verantwortlich ist.
  • In dem in 3D dargestellten Beispiel können sich die dargestellten Speichersysteme (311-402, 311-404, 311-406) auch von dem Pod lösen, so dass das jeweilige Speichersystem, das sich von dem Pod löst, nicht mehr in der Menge der Speichersysteme enthalten ist, über die der Datensatz synchron repliziert wird. Wenn sich beispielsweise das Speichersystem (311-404) in 3D von dem in 3D dargestellten Pod (311-430) löst, würde der Pod (311-430) nur noch die Speichersysteme (311-402, 311-406) als die Speichersysteme umfassen, über die der Datensatz (311-426), der in dem Pod (311-430) enthalten ist, synchron repliziert werden würde. In einem solchen Beispiel könnte das Trennen des Speichersystems vom Pod auch das Entfernen des Datensatzes von dem bestimmten Speichersystem beinhalten, das sich vom Pod getrennt hat. In Fortsetzung des Beispiels, bei dem das Speichersystem (311-404) in 3D von dem in 3D dargestellten Pod (311-430) getrennt wurde, könnte der Datensatz (311-426), der in dem Pod (311-430) enthalten ist, gelöscht oder auf andere Weise von dem Speichersystem (311-404) entfernt werden.
  • Die Leser werden verstehen, dass das Pod-Modell eine Reihe einzigartiger Verwaltungsfunktionen ermöglicht, die weiter unterstützt werden können. Auch das Pod-Modell selbst wirft einige Probleme auf, die durch eine Implementierung gelöst werden können. Wenn z. B. ein Speichersystem für einen Pod offline ist, sich aber ansonsten in Betrieb befindet, z. B. weil eine Verbindung ausgefallen ist und sich ein anderes Speichersystem für den Pod in der Mediation durchgesetzt hat, kann dennoch der Wunsch oder die Notwendigkeit bestehen, auf den Datensatz des Offline-Pods auf dem Offline-Speichersystem zuzugreifen. Eine Lösung könnte darin bestehen, den Pod einfach in einem abgetrennten Modus zu aktivieren und den Zugriff auf den Datensatz zu ermöglichen. Diese Lösung kann jedoch gefährlich sein und dazu führen, dass die Metadaten und Daten des Pods viel schwieriger in Einklang zu bringen sind, wenn die Speichersysteme wieder miteinander kommunizieren. Außerdem könnte es für Hosts immer noch einen separaten Pfad für den Zugriff auf das Offline-Speichersystem und die noch online befindlichen Speichersysteme geben. In diesem Fall könnte ein Host eine Eingabe/Ausgabe an beide Speichersysteme ausgeben, obwohl sie nicht mehr synchron gehalten werden, weil der Host Ziel-Ports sieht, die Datenträger mit denselben Kennungen melden, und die Host-E/A-Treiber davon ausgehen, dass sie zusätzliche Pfade zu demselben Datenträger sehen. Dies kann zu einer ziemlich schädlichen Datenverfälschung führen, da Lese- und Schreibvorgänge auf beiden Speichersystemen nicht mehr konsistent sind, obwohl der Host davon ausgeht, dass sie es sind. Eine Variante dieses Falles ist, dass in einer Clusteranwendung, z. B. einer Clusterdatenbank mit gemeinsamem Speicher, die Clusteranwendung auf einem Host ein Speichersystem liest oder beschreibt und dieselbe Clusteranwendung auf einem anderen Host das „abgetrennte“ Speichersystem liest oder beschreibt, wobei die beiden Instanzen der Clusteranwendung in der Annahme miteinander kommunizieren, dass der Datensatz, den sie jeweils sehen, für abgeschlossene Schreibvorgänge vollständig konsistent ist. Da sie nicht konsistent sind, wird diese Annahme verletzt und der Datensatz der Anwendung (z. B. die Datenbank) kann schnell beschädigt werden.
  • Eine Möglichkeit, diese beiden Probleme zu lösen, besteht darin, einen Offline-Pod oder vielleicht einen Snapshot eines Offline-Pods auf einen neuen Pod mit neuen Datenträgern zu kopieren, die ausreichend neue Identitäten haben, damit Host-E/A-Treiber und Cluster-Anwendungen die kopierten Datenträger nicht mit den noch online befindlichen Datenträgern auf einem anderen Speichersystem verwechseln. Da jeder Pod eine vollständige Kopie des Datenbestands verwaltet, die zwar crashkonsistent ist, sich aber möglicherweise geringfügig von der Kopie des Pod-Datenbestands auf einem anderen Speichersystem unterscheidet, und da jeder Pod über eine unabhängige Kopie aller Daten und Metadaten verfügt, die für die Bearbeitung des Pod-Inhalts erforderlich sind, ist es ein einfaches Problem, eine virtuelle Kopie einiger oder aller Datenträger oder Snapshots im Pod auf neue Datenträger in einem neuen Pod zu erstellen. Bei einer Implementierung von logischen Ausdehnungsgraphen müssen beispielsweise nur neue Datenträger in einem neuen Pod definiert werden, die auf logische Ausdehnungsgraphen des kopierten Pods verweisen, die mit den Datenträgern oder Snapshots des Pods verknüpft sind, wobei die logischen Ausdehnungsgraphen als Kopie beim Schreiben gekennzeichnet sind. Die neuen Datenträger sollten als neue Datenträger behandelt werden, ähnlich wie Datenträger-Snapshots, die auf einen neuen Datenträger kopiert werden, implementiert werden könnten. Datenträger können denselben administrativen Namen haben, wenn auch innerhalb eines neuen Pod-Namensraums. Sie sollten jedoch unterschiedliche zugrundeliegende Kennungen und unterschiedliche Kennungen für logische Einheiten haben, die sich von denen der ursprünglichen Datenträger unterscheiden.
  • In einigen Fällen kann es möglich sein, Techniken zur Isolierung virtueller Netze zu verwenden (z. B. durch Schaffung eines virtuellen LANs im Falle von IP-Netzen oder eines virtuellen SANs im Falle von Fibre-Channel-Netzen), so dass die Isolierung von Datenträgern, die einigen Schnittstellen präsentiert werden, gewährleistet werden kann, dass sie von Host-Netzwerkschnittstellen oder Host-SCSI-Initiator-Ports, die auch die Originaldatenträger sehen könnten, unzugänglich sind. In solchen Fällen kann es sicher sein, die Kopien von Datenträgern mit denselben SCSI- oder anderen Speicherkennungen zu versehen wie die Originaldatenträger. Dies könnte z. B. in Fällen verwendet werden, in denen die Anwendungen erwarten, einen bestimmten Satz von Speicherkennungen zu sehen, um ohne übermäßigen Aufwand bei der Neukonfiguration zu funktionieren.
  • Einige der hier beschriebenen Techniken können auch außerhalb eines aktiven Fehlerkontextes eingesetzt werden, um die Bereitschaft für die Behandlung von Fehlern zu testen. Bereitschaftstests (manchmal auch als „Fire Drills“ bezeichnet) sind in der Regel für Disaster-Recovery-Konfigurationen erforderlich, bei denen häufige und wiederholte Tests als notwendig erachtet werden, um sicherzustellen, dass die meisten oder alle Aspekte eines Disaster-Recovery-Plans korrekt sind und alle kürzlich vorgenommenen Änderungen an Anwendungen, Datensätzen oder Ausrüstungsänderungen berücksichtigt werden. Die Bereitschaftstests sollten den laufenden Produktionsbetrieb, einschließlich der Replikation, nicht unterbrechen. In vielen Fällen können die echten Operationen nicht auf der aktiven Konfiguration aufgerufen werden, aber eine gute Möglichkeit, sich dem anzunähern, ist die Verwendung von Speichervorgängen, um Kopien von Produktionsdatensätzen zu erstellen, und dies dann vielleicht mit der Verwendung von virtuellen Netzwerken zu verbinden, um eine isolierte Umgebung zu schaffen, die alle Daten enthält, die für die wichtigen Anwendungen, die im Katastrophenfall erfolgreich wiederhergestellt werden müssen, als notwendig erachtet werden. Die Bereitstellung einer solchen Kopie eines synchron replizierten (oder sogar eines asynchron replizierten) Datensatzes innerhalb eines Standorts (oder einer Sammlung von Standorten), von dem/der erwartet wird, dass er/sie ein Testverfahren für die Wiederherstellungsbereitschaft im Katastrophenfall durchführt, und das anschließende Starten der wichtigen Anwendungen auf diesem Datensatz, um sicherzustellen, dass sie gestartet werden und funktionieren können, ist ein hervorragendes Instrument, da es dazu beiträgt, dass keine wichtigen Teile der Anwendungsdatensätze im Wiederherstellungsplan für den Katastrophenfall ausgelassen wurden. Falls erforderlich und praktikabel, könnte dies mit virtuellen isolierten Netzwerken gekoppelt werden, vielleicht mit einer isolierten Sammlung von physischen oder virtuellen Maschinen, um einem realen Disaster-Recovery-Szenario so nahe wie möglich zu kommen. Durch das virtuelle Kopieren eines Pods (oder einer Reihe von Pods) auf einen anderen Pod als Point-in-Time-Image der Pod-Datensätze wird sofort ein isolierter Datensatz erstellt, der alle kopierten Elemente enthält und auf dem dann im Wesentlichen identisch wie auf den ursprünglichen Pods gearbeitet werden kann, wobei auch die Isolierung auf einen einzelnen Standort (oder einige Standorte) getrennt vom ursprünglichen Pod möglich ist. Außerdem sind diese Vorgänge schnell und können leicht wieder abgebaut und wiederholt werden, so dass die Tests beliebig oft wiederholt werden können.
  • Es könnten noch einige Verbesserungen vorgenommen werden, um perfekte Disaster-Recovery-Tests zu ermöglichen. In Verbindung mit isolierten Netzwerken könnten beispielsweise die Identitäten logischer SCSI-Einheiten oder andere Arten von Identitäten in den Ziel-Pod kopiert werden, so dass die Testserver, virtuellen Maschinen und Anwendungen dieselben Identitäten sehen. Darüber hinaus könnte die administrative Umgebung der Server so konfiguriert werden, dass sie auf Anforderungen aus einem bestimmten virtuellen Satz virtueller Netzwerke reagiert, um auf Anforderungen und Operationen mit dem ursprünglichen Pod-Namen zu reagieren, so dass Skripte nicht die Verwendung von Testvarianten mit alternativen „Test“-Versionen von Objektnamen erfordern. Eine weitere Verbesserung kann in Fällen verwendet werden, in denen die hostseitige Serverinfrastruktur, die im Falle einer Katastrophe übernommen wird, während eines Tests verwendet werden kann. Dazu gehören Fälle, in denen ein Datenzentrum für die Wiederherstellung nach einer Katastrophe vollständig mit einer alternativen Serverinfrastruktur ausgestattet ist, die im Allgemeinen erst dann verwendet wird, wenn eine Katastrophe dies erfordert. Dazu gehören auch Fälle, in denen diese Infrastruktur für nicht kritische Operationen verwendet wird (z. B. für Analysen von Produktionsdaten oder einfach zur Unterstützung der Anwendungsentwicklung oder anderer Funktionen, die zwar wichtig sind, aber bei Bedarf für kritischere Funktionen unterbrochen werden können). Insbesondere können Host-Definitionen und -Konfigurationen sowie die Server-Infrastruktur, die sie verwenden werden, so eingerichtet werden, wie sie für einen tatsächlichen Disaster-Recovery-Übernahmefall benötigt werden, und als Teil der Disaster-Recovery-Übernahme-Tests getestet werden, wobei die getesteten Datenträger mit diesen Host-Definitionen von der virtuellen Pod-Kopie aus verbunden werden, die verwendet wird, um einen Snapshot des Datenbestands zu erstellen. Aus der Sicht der beteiligten Speichersysteme können diese Host-Definitionen und -Konfigurationen, die für die Tests verwendet werden, sowie die Konfigurationen für die Datenträger-zu-Host-Verbindungen, die während der Tests verwendet werden, wiederverwendet werden, wenn ein tatsächliches Disaster-Recovery-Takeover-Ereignis ausgelöst wird, wodurch die Konfigurationsunterschiede zwischen der Testkonfiguration und der realen Konfiguration, die im Falle eines Disaster-Recovery-Takeovers verwendet wird, stark minimiert werden.
  • In manchen Fällen kann es sinnvoll sein, Datenträger aus einem ersten Pod in einen neuen zweiten Pod zu verschieben, der nur diese Datenträger enthält. Die Pod-Zugehörigkeit und die Hochverfügbarkeits- und Wiederherstellungseigenschaften können dann separat angepasst werden, und die Verwaltung der beiden resultierenden Pod-Datensätze kann dann voneinander isoliert werden. Ein Vorgang, der in eine Richtung möglich ist, sollte auch in die andere Richtung möglich sein. Irgendwann kann es sinnvoll sein, zwei Pods zu einem zu verschmelzen, so dass die Datenträger in jedem der beiden ursprünglichen Pods sich nun hinsichtlich der Zugehörigkeit im Speichersystem sowie der Hochverfügbarkeits- und Wiederherstellungsmerkmale und -ereignisse gegenseitig verfolgen. Beide Vorgänge können sicher und mit minimaler oder gar keiner Unterbrechung der laufenden Anwendungen durchgeführt werden, indem man sich auf die Merkmale stützt, die für die Änderung der Mediations- oder Quorum-Eigenschaften eines Pods vorgeschlagen wurden und die in einem früheren Abschnitt behandelt wurden. Bei der Mediation kann beispielsweise ein Mediator für einen Pod mit Hilfe einer Sequenz geändert werden, die aus einem Schritt besteht, bei dem jedes Speichersystem in einem Pod so geändert wird, dass es sowohl von einem ersten Mediator als auch von einem zweiten Mediator abhängig ist, und dann so geändert wird, dass es nur noch vom zweiten Mediator abhängig ist. Wenn in der Mitte der Sequenz ein Fehler auftritt, können einige Speichersysteme sowohl vom ersten Mediator als auch vom zweiten Mediator abhängig sein, aber auf keinen Fall werden Wiederherstellung und Fehlerbehandlung dazu führen, dass einige Speichersysteme nur vom ersten Mediator und andere Speichersysteme nur vom zweiten Mediator abhängig sind. Das Quorum kann in ähnlicher Weise gehandhabt werden, indem vorübergehend sowohl ein erstes als auch ein zweites Quorum-Modell verwendet wird, um zur Wiederherstellung überzugehen. Dies kann zu einer sehr kurzen Zeitspanne führen, in der die Verfügbarkeit des Pods angesichts von Fehlern von zusätzlichen Ressourcen abhängt, wodurch die potenzielle Verfügbarkeit verringert wird, aber diese Zeitspanne ist sehr kurz und die Verringerung der Verfügbarkeit ist oft sehr gering. Wenn bei der Mediation die Änderung der Mediator-Parameter nur die Änderung des für die Mediation verwendeten Schlüssels ist und der verwendete Mediationsdienst derselbe ist, ist die potenzielle Verringerung der Verfügbarkeit sogar noch geringer, da sie nur noch von zwei Aufrufen desselben Dienstes statt von einem Aufruf dieses Dienstes abhängt und nicht mehr von getrennten Aufrufen zweier separater Dienste.
  • Der Leser wird feststellen, dass die Änderung des Quorum-Modells recht komplex sein kann. Ein zusätzlicher Schritt kann erforderlich sein, wenn Speichersysteme am zweiten Quorum-Modell teilnehmen, aber nicht davon abhängig sind, dass sie in diesem zweiten Quorum-Modell gewinnen. Dies kann notwendig sein, um der Tatsache Rechnung zu tragen, dass, wenn nur ein System die Änderung so verarbeitet hat, dass es vom Quorum-Modell abhängt, es niemals das Quorum gewinnen wird, da es niemals eine Mehrheit geben wird. Mit diesem Modell für die Änderung der Hochverfügbarkeitsparameter (Mediatorbeziehung, Quorum-Modell, Übernahmepräferenzen) können wir ein sicheres Verfahren für diese Operationen schaffen, um einen Pod in zwei zu teilen oder zwei Pods zu einem zusammenzuführen. Dies kann die Hinzufügung einer weiteren Fähigkeit erfordern: die Verknüpfung eines zweiten Pods mit einem ersten Pod zur Hochverfügbarkeit, so dass, wenn zwei Pods kompatible Hochverfügbarkeitsparameter enthalten, der mit dem ersten Pod verknüpfte zweite Pod bei der Bestimmung und Einleitung von abtrennungsbezogenen Verarbeitungen und Operationen, Offline- und In-Sync-Zuständen sowie Wiederherstellungs-und Resynchronisierungsaktionen vom ersten Pod abhängen kann.
  • Für die Aufteilung eines Pods in zwei Teile, d. h. die Verschiebung einiger Datenträger in einen neu erstellten Pod, kann ein verteilter Vorgang gebildet werden, der wie folgt beschrieben werden kann: Bilden eines zweiten Pods, in den wir eine Reihe von Datenträgern verschieben, die sich zuvor in einem ersten Pod befanden, Kopieren der Hochverfügbarkeitsparameter vom ersten Pod in den zweiten Pod, um sicherzustellen, dass sie für die Verknüpfung kompatibel sind, und Verknüpfen des zweiten Pods mit dem ersten Pod für hohe Verfügbarkeit. Dieser Vorgang kann in Form von Nachrichten kodiert werden und sollte von jedem Speichersystem im Pod so implementiert werden, dass das Speichersystem sicherstellt, dass der Vorgang vollständig auf diesem Speichersystem abläuft oder gar nicht erst stattfindet, wenn die Verarbeitung durch einen Fehler unterbrochen wird. Sobald alle synchronen Speichersysteme für die beiden Pods diesen Vorgang verarbeitet haben, können die Speichersysteme einen nachfolgenden Vorgang verarbeiten, der den zweiten Pod so ändert, dass er nicht mehr mit dem ersten Pod verbunden ist. Wie bei anderen Änderungen an den Hochverfügbarkeitsmerkmalen eines Pods muss dazu zunächst jedes In-Sync-Speichersystem so umgestellt werden, dass es sich sowohl auf das vorherige Modell (d. h. die Hochverfügbarkeit ist mit dem ersten Pod verknüpft) als auch auf das neue Modell (d. h. seine eigene, jetzt unabhängige Hochverfügbarkeit) stützt. Im Falle der Mediation oder des Quorums bedeutet dies, dass Speichersysteme, die diese Änderung verarbeitet haben, zunächst darauf angewiesen sind, dass die Mediation oder das Quorum für den ersten Pod erreicht wird, und zusätzlich darauf, dass eine neue separate Mediation (z. B. ein neuer Mediationsschlüssel) oder das Quorum für den zweiten Pod erreicht wird, bevor der zweite Pod nach einem Fehler, der eine Mediation oder einen Test für das Quorum erfordert, fortfahren kann. Wie bei der vorherigen Beschreibung der Änderung des Quorum-Modells kann ein Zwischenschritt die Speichersysteme so einstellen, dass sie am Quorum für den zweiten Pod teilnehmen, bevor der Schritt erfolgt, bei dem die Speichersysteme am Quorum für den zweiten Pod teilnehmen und davon abhängen. Sobald alle synchronisierten Speichersysteme die Änderung verarbeitet haben und von den neuen Parametern für die Mediation oder das Quorum sowohl für den ersten als auch für den zweiten Pod abhängig sind, ist die Aufteilung abgeschlossen.
  • Das Zusammenführen eines zweiten Pods mit einem ersten Pod funktioniert im Wesentlichen umgekehrt. Zunächst muss der zweite Pod so angepasst werden, dass er mit dem ersten Pod kompatibel ist, indem er eine identische Liste von Speichersystemen und ein kompatibles Hochverfügbarkeitsmodell hat. Dies kann eine Reihe von Schritten beinhalten, wie sie an anderer Stelle in diesem Dokument beschrieben sind, um Speichersysteme hinzuzufügen oder zu entfernen oder um Mediator- und Quorum-Modelle zu ändern. Je nach Implementierung ist es möglicherweise nur notwendig, eine identische Liste von Speichersystemen zu erreichen. Beim Joining wird auf jedem synchronisierten Speichersystem eine Operation ausgeführt, um den zweiten Pod mit dem ersten Pod zu verbinden und so eine hohe Verfügbarkeit zu erreichen. Jedes Speichersystem, das diesen Vorgang verarbeitet, hängt dann vom ersten Pod für Hochverfügbarkeit und dann vom zweiten Pod für Hochverfügbarkeit ab. Sobald alle synchronisierten Speichersysteme für den zweiten Pod diesen Vorgang verarbeitet haben, führen die Speichersysteme jeweils einen weiteren Vorgang durch, um die Verbindung zwischen dem zweiten Pod und dem ersten Pod aufzuheben, die Datenträger vom zweiten Pod in den ersten Pod zu migrieren und den zweiten Pod zu löschen. Der Zugriff auf Host- oder Anwendungsdatensätze kann während dieser Vorgänge beibehalten werden, solange die Implementierung eine ordnungsgemäße Ausrichtung von Host- oder Anwendungsdatensatzänderungen oder Lesevorgängen auf den Datenträger nach Identität ermöglicht und solange die Identität entsprechend dem Speicherprotokoll oder Speichermodell beibehalten wird (z. B. solange logische Einheitskennungen für Datenträger und die Verwendung von Ziel-Ports für den Zugriff auf Datenträger im Falle von SCSI beibehalten werden).
  • Die Migration eines Datenträgers zwischen Pods kann zu Problemen führen. Wenn die Pods über identische, synchronisierte Zugehörigkeitsspeichersysteme verfügen, ist dies kein Problem: Der Betrieb der zu migrierenden Datenträger wird vorübergehend unterbrochen, die Kontrolle über den Betrieb dieser Datenträger wird auf die Kontrollsoftware und -strukturen des neuen Pods übertragen, und dann wird der Betrieb wieder aufgenommen. Dies ermöglicht eine nahtlose Migration mit kontinuierlicher Betriebszeit für Anwendungen, abgesehen von der sehr kurzen Betriebsunterbrechung, vorausgesetzt, Netzwerk und Ports werden ordnungsgemäß zwischen den Pods migriert. Je nach Implementierung ist die Unterbrechung des Betriebs möglicherweise gar nicht erforderlich oder so systemintern, dass die Unterbrechung des Betriebs keine Auswirkungen hat. Das Kopieren von Datenträgern zwischen Pods mit unterschiedlichen In-Sync-Membership-Sets stellt ein größeres Problem dar. Wenn der Ziel-Pod für die Kopie eine Teilmenge der synchronen Elemente des Quell-Pods aufweist, ist dies kein großes Problem: Ein Elemente-Speichersystem kann sicher genug entfallen, ohne dass mehr Arbeit anfällt. Wenn jedoch der Ziel-Pod dem Datenträger über den Quell-Pod synchrone Elemente-Speichersysteme hinzufügt, müssen die hinzugefügten Speichersysteme synchronisiert werden, um den Inhalt des Datenträgers aufzunehmen, bevor sie verwendet werden können. Solange sie nicht synchronisiert sind, unterscheiden sich die kopierten Datenträger deutlich von den bereits synchronisierten Datenträgern, da die Fehlerbehandlung unterschiedlich ist und die Bearbeitung von Anfragen von den noch nicht synchronisierten Elemente-Speichersystemen entweder nicht funktioniert oder weitergeleitet werden muss oder nicht so schnell ist, weil die Lesevorgänge eine Verbindung durchlaufen müssen. Außerdem muss die interne Implementierung damit umgehen, dass einige Datenträger synchronisiert und für die Fehlerbehandlung bereit sind und andere nicht synchronisiert sind.
  • Es gibt noch weitere Probleme im Zusammenhang mit der Zuverlässigkeit des Vorgangs bei Fehlern. Die Koordinierung einer Migration von Datenträgern zwischen Multi-Storage-System-Pods ist ein verteilter Vorgang. Wenn Pods die Einheit für Fehlerbehandlung und Wiederherstellung sind und wenn Mediation oder Quorum oder welche Mittel auch immer verwendet werden, um Split-Brain-Situationen zu vermeiden, dann muss ein Wechsel von Datenträgern von einem Pod mit einem bestimmten Satz von Zuständen und Konfigurationen und Beziehungen für Fehlerbehandlung, Wiederherstellung, Mediation und Quorum zu einem anderen die Speichersysteme in einem Pod sorgfältig auf die Koordinierung von Änderungen im Zusammenhang mit dieser Behandlung für alle Datenträger achten. Operationen können nicht atomar zwischen den Speichersystemen verteilt werden, sondern müssen in irgendeiner Weise gestaffelt werden. Mediation- und Quorum-Modelle bieten Pods im Wesentlichen die Werkzeuge für die Implementierung verteilter transaktionaler Atomizität, aber dies kann nicht auf Operationen zwischen Pods ausgedehnt werden, ohne die Implementierung zu erweitern.
  • Man betrachte selbst eine einfache Migration eines Volumes von einem ersten Pod zu einem zweiten Pod, selbst bei zwei Pods, die sich dasselbe erste und zweite Speichersystem teilen. Irgendwann stimmen sich die Speichersysteme ab, um festzulegen, dass sich der Datenträger nun im zweiten Pod und nicht mehr im ersten Pod befindet. Wenn es keinen inhärenten Mechanismus für die transaktionale Atomarität zwischen den Speichersystemen der beiden Pods gibt, könnte eine naive Implementierung den Datenträger im ersten Pod auf dem ersten Speichersystem und im zweiten Pod auf dem zweiten Speichersystem belassen, wenn ein Netzwerkfehler auftritt, der eine Fehlerbehandlung zum Trennen der Speichersysteme von den beiden Pods zur Folge hat. Wenn die Pods getrennt bestimmen, welches Speichersystem das andere erfolgreich abtrennt, könnte das Ergebnis sein, dass dasselbe Speichersystem das andere Speichersystem für beide Pods abtrennt, wobei das Ergebnis der Wiederherstellung der Datenträger-Migration konsistent sein sollte, oder es könnte dazu führen, dass ein anderes Speichersystem das andere für die beiden Pods abtrennt. Wenn das erste Speichersystem das zweite Speichersystem für den ersten Pod abkoppelt und das zweite Speichersystem das erste Speichersystem für den zweiten Pod abkoppelt, könnte die Wiederherstellung dazu führen, dass der Datenträger auf dem ersten Pod auf dem ersten Speichersystem und der Datenträger auf dem zweiten Pod auf dem zweiten Speichersystem wiederhergestellt wird, wobei der Datenträger dann ausgeführt und auf Hosts und Speicheranwendungen auf beiden Speichersystemen exportiert wird. Wenn stattdessen das zweite Speichersystem das erste Speichersystem für den ersten Pod abtrennt und das erste Speichersystem das zweite Speichersystem für den zweiten Pod abtrennt, kann die Wiederherstellung dazu führen, dass der Datenträger vom ersten Speichersystem aus dem zweiten Pod und vom zweiten Speichersystem aus dem ersten Pod verworfen wird, was dazu führt, dass der Datenträger vollständig verschwindet. Wenn sich die Pods, zwischen denen ein Datenträger migriert wird, auf unterschiedlichen Speichersystemen befinden, können die Dinge noch komplizierter werden.
  • Eine Lösung für diese Probleme kann die Verwendung eines Zwischen-Pods in Verbindung mit den zuvor beschriebenen Techniken zur Aufteilung und Zusammenführung von Pods sein. Dieser Zwischen-Pod kann niemals als sichtbare verwaltete Objekte in Verbindung mit den Speichersystemen dargestellt werden. Bei diesem Modell werden die Datenträger, die von einem ersten Pod in einen zweiten Pod verschoben werden sollen, zunächst mit Hilfe des zuvor beschriebenen Aufteilungsvorgangs vom ersten Pod in einen neuen Zwischen-Pod aufgeteilt. Die Elemente des Speichersystems für den Zwischen-Pod können dann so angepasst werden, dass sie mit den Elementen der Speichersysteme übereinstimmen, indem Speichersysteme aus dem Pod hinzugefügt oder entfernt werden, wenn dies erforderlich ist. Anschließend kann der Zwischen-Pod mit dem zweiten Pod verbunden werden.
  • Zur weiteren Erläuterung ist in 3E ein Flussdiagramm dargestellt, das ein Beispielverfahren zur Bearbeitung von E/A-Operationen zeigt, die auf einen Datensatz (311-42) gerichtet sind, der über eine Vielzahl von Speichersystemen (311-38, 311-40) gemäß einigen Ausführungsformen der vorliegenden Offenbarung synchronisiert ist. Obwohl weniger detailliert dargestellt, können die in 3E dargestellten Speichersysteme (311-38, 311-40) den oben unter Bezugnahme auf die 1A-1D, die 2A-2G, die 3A-3B oder eine beliebige Kombination davon beschriebenen Speichersystemen ähnlich sein. Tatsächlich kann das in 3E dargestellte Speichersystem die gleichen oder weniger zusätzliche Komponenten enthalten wie die oben beschriebenen Speichersysteme.
  • Der in 3E dargestellte Datensatz (311-42) kann z. B. als Inhalt eines bestimmten Datenträgers, als Inhalt eines bestimmten gemeinsam genutzten Datenträgers oder als jede andere Sammlung von einem oder mehreren Datenelementen dargestellt werden. Der Datensatz (311-42) kann über eine Vielzahl von Speichersystemen (311-38, 311-40) synchronisiert werden, so dass jedes Speichersystem (311-38, 311-40) eine lokale Kopie des Datensatzes (311-42) behält. In den hier beschriebenen Beispielen wird ein solcher Datensatz (311-42) synchron über die Speichersysteme (311-38, 311-40) repliziert, so dass auf den Datensatz (311-42) über jedes der Speichersysteme (311-38, 311-40) mit solchen Leistungsmerkmalen zugegriffen werden kann, dass ein beliebiges Speichersystem im Cluster kein anderes Speichersystem im Cluster wesentlich besser auslastet, zumindest solange der Cluster und das jeweilige Speichersystem, auf das zugegriffen wird, nominell laufen. In solchen Systemen sollten Änderungen an dem Datensatz (311-42) an der Kopie des Datensatzes, die sich auf jedem Speichersystem (311-38, 311-40) befindet, so vorgenommen werden, dass der Zugriff auf den Datensatz (311-42) auf jedem Speichersystem (311-38, 311-40) konsistente Ergebnisse liefert. So muss beispielsweise eine Schreibanforderung für den Datenbestand auf allen Speichersystemen (311-38, 311-40) oder auf keinem der Speichersysteme (311-38, 311-40), die zu Beginn der Schreiboperation nominell in Betrieb waren und bis zum Abschluss der Schreiboperation nominell in Betrieb blieben, bearbeitet werden. Ebenso müssen einige Gruppen von Operationen (z. B. zwei Schreiboperationen, die an dieselbe Stelle innerhalb des Datensatzes gerichtet sind) auf allen Speichersystemen (311-38, 311-40) in derselben Reihenfolge ausgeführt werden, oder es müssen andere Schritte unternommen werden, wie weiter unten ausführlicher beschrieben, so dass der Datensatz letztlich auf allen Speichersystemen (311-38, 311-40) identisch ist. Änderungen am Datensatz (311-42) müssen nicht genau zur gleichen Zeit erfolgen, aber einige Aktionen (z. B. die Ausgabe einer Bestätigung, dass eine an den Datensatz gerichtete Schreibanforderung vorliegt, die den Lesezugriff auf eine Stelle im Datensatz ermöglicht, auf die eine Schreibanforderung abzielt, die auf beiden Speichersystemen noch nicht abgeschlossen ist) können verzögert werden, bis die Kopie des Datensatzes auf jedem Speichersystem (311-38, 311-40) geändert wurde.
  • In dem in 3E dargestellten Beispielverfahren kann sich die Bezeichnung eines Speichersystems (311-40) als „Leader“ und eines anderen Speichersystems (311-38) als „Follower“ auf die jeweiligen Beziehungen der einzelnen Speichersysteme zum Zwecke der synchronen Replikation eines bestimmten Datensatzes über die Speichersysteme hinweg beziehen. In einem solchen Beispiel kann das Leader-Speichersystem (311-40), wie weiter unten näher beschrieben wird, für die Verarbeitung einer eingehenden E/A-Operation und die Weitergabe dieser Informationen an das Follower-Speichersystem (311-38) verantwortlich sein oder andere Aufgaben ausführen, die vom Follower-Speichersystem (311-40) nicht benötigt werden. Das Leader-Speichersystem (311-40) kann für die Durchführung von Aufgaben verantwortlich sein, die vom Follower-Speichersystem (311-38) für alle eingehenden E/A-Operationen nicht benötigt werden, oder alternativ kann die Beziehung zwischen Leader- und Follower-Speichersystem nur für eine Teilmenge der E/A-Operationen spezifisch sein, die von einem der Speichersysteme empfangen werden. Beispielsweise kann die Leader-Follower-Beziehung spezifisch für E/A-Operationen sein, die an einen ersten Datenträger, eine erste Gruppe von Datenträgern, eine erste Gruppe von logischen Adressen, eine erste Gruppe von physischen Adressen oder eine andere logische oder physische Abgrenzung gerichtet sind. Auf diese Weise kann ein erstes Speichersystem als Leader Speichersystem für E/A-Operationen dienen, die auf eine erste Gruppe von Datenträgern (oder eine andere Abgrenzung) gerichtet sind, während ein zweites Speichersystem als Leader-Speichersystem für E/A-Operationen dienen kann, die auf eine zweite Gruppe von Datenträgern (oder eine andere Abgrenzung) gerichtet sind. Das in 3E dargestellte Beispielverfahren zeigt eine Ausführungsform, bei der die Synchronisierung einer Vielzahl von Speichersystemen (311-38, 311-40) als Reaktion auf das Empfangen einer Anforderung (311-04) zur Änderung eines Datensatzes (311-42) durch das Leader-Speichersystem (311-40) erfolgt, obwohl die Synchronisierung einer Vielzahl von Speichersystemen (311-38, 311-40) auch als Reaktion auf das Empfangen einer Anforderung (311-04) zur Änderung eines Datensatzes (311-42) durch das Follower-Speichersystem (311-38) erfolgen kann, wie weiter unten ausführlicher beschrieben wird.
  • Das in 3E dargestellte Beispielverfahren umfasst das Empfangen (311-06) einer Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch ein Leader-Speichersystem (311-40). Die Anforderung (311-04) zum Modifizieren des Datensatzes (311-42) kann beispielsweise als Anforderung zum Schreiben von Daten an einen Speicherort innerhalb des Speichersystems (311-40), der Daten enthält, die in dem Datensatz (311-42) enthalten sind, als Anforderung zum Schreiben von Daten auf einen Datenträger, der Daten enthält, die in dem Datensatz (311-42) enthalten sind, als Anforderung zum Erstellen eines Snapshots des Datensatzes (311-42), als virtuelle Bereichskopie, als UNMAP-Operation, die im Wesentlichen eine Löschung eines Teils der Daten im Datenbestand (311-42) darstellt, als modifizierende Transformationen des Datenbestands (311-42) (anstatt einer Änderung eines Teils der Daten im Datenbestand) oder als eine andere Operation, die zu einer Änderung eines Teils der Daten führt, die im Datenbestand (311-42) enthalten sind. In dem in 3E dargestellten Beispielverfahren wird die Anforderung (311-04) zum Ändern des Datensatzes (311-42) von einem Host (311-02) ausgegeben, der beispielsweise als eine Anwendung, die auf einer virtuellen Maschine ausgeführt wird, als eine Anwendung, die auf einem Computergerät ausgeführt wird, das mit dem Speichersystem (311-40) verbunden ist, oder als eine andere Einheit, die für den Zugriff auf das Speichersystem (311-40) konfiguriert ist, verkörpert werden kann.
  • Das in 3E dargestellte Beispielverfahren umfasst auch die Erzeugung (311-08) von Informationen (311-10) durch das Leader-Speichersystem (311-40), die die Änderung des Datensatzes (311-42) beschreiben. Das Leader-Speichersystem (311-40) kann die Informationen (311-10) erzeugen (311-08), die die Änderung des Datensatzes (311-42) beschreiben, zum Beispiel durch Bestimmen der Reihenfolge im Vergleich zu anderen laufenden Operationen, durch Bestimmen des richtigen Ergebnisses von sich überschneidenden Änderungen (z.B. das richtige Ergebnis von zwei Aufforderungen zum Ändern desselben Speicherplatzes), die Berechnung verteilter Zustandsänderungen, z. B. an gemeinsamen Elementen von Metadaten über alle Elemente des Pods (z. B. alle Speichersysteme, über die der Datensatz synchron repliziert wird), usw. Die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, können beispielsweise als Informationen auf Systemebene verkörpert werden, die zur Beschreibung einer E/A-Operation verwendet werden, die von einem Speichersystem durchgeführt werden soll. Das Leader-Speichersystem (311-40) kann die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, generieren (311-08), indem es die Anforderung (311-04) zur Änderung des Datensatzes (311-42) gerade so weit verarbeitet, dass es herausfindet, was geschehen sollte, um die Anforderung (311-04) zur Änderung des Datensatzes (311-42) zu bedienen. Beispielsweise kann das Leader-Speichersystem (311-40) feststellen, ob eine bestimmte Reihenfolge der Ausführung der Anforderung (311-04) zur Änderung des Datensatzes (311-42) im Verhältnis zu anderen Anforderungen zur Änderung des Datensatzes (311-42) erforderlich ist oder ob andere Schritte unternommen werden müssen, wie unten ausführlicher beschrieben, um auf jedem Speichersystem (311-38, 311-40) ein gleichwertiges Ergebnis zu erzielen.
  • Betrachten wir ein Beispiel, in dem die Anforderung (311-04) zur Änderung des Datensatzes (311-42) als Anforderung zum Kopieren von Blöcken aus einem ersten Adressbereich im Datensatz (311-42) in einen zweiten Adressbereich im Datensatz (311-42) verkörpert wird. In einem solchen Beispiel wird angenommen, dass drei andere Schreiboperationen (Schreiboperation A, Schreiboperation B, Schreiboperation C) an den ersten Adressbereich im Datenbestand (311-42) gerichtet sind. Wenn in einem solchen Beispiel das Leader-Speichersystem (311-40) vor dem Kopieren der Blöcke aus dem ersten Adressbereich im Datenbestand (311-42) in den zweiten Adressbereich im Datenbestand (311-42) die Schreiboperationen A und B (aber nicht die Schreiboperation C) ausführt, muss das Follower-Speichersystem (311-38) auch Schreiboperation A und Schreiboperation B (aber nicht Schreiboperation C) vor dem Kopieren der Blöcke aus dem ersten Adressbereich im Datensatz (311-42) in den zweiten Adressbereich im Datensatz (311-42) bedienen, um konsistente Ergebnisse zu erzielen. Wenn das Leader-Speichersystem (311-40) die Informationen (311-10) generiert (311-08), die die Änderung des Datensatzes (311-42) beschreiben, könnte das Leader-Speichersystem (311-40) in diesem Beispiel Informationen generieren (z. B. Sequenznummern für Schreiboperation A und Schreiboperation B), die andere Operationen identifizieren, welche abgeschlossen werden müssen, bevor das Follower-Speichersystem (311-38) die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeiten kann.
  • Betrachten wir ein weiteres Beispiel, bei dem zwei Anfragen (z. B. Schreiboperation A und Schreiboperation B) an sich überschneidende Teile des Datensatzes (311-42) gerichtet sind. Wenn in einem solchen Beispiel das Leader-Speichersystem (311-40) die Schreiboperation A und anschließend die Schreiboperation B durchführt, während das Follower-Speichersystem (311-38) die Schreiboperation B und anschließend die Schreiboperation A durchführt, wäre der Datensatz (311-42) in beiden Speichersystemen (311-38, 311-40) nicht konsistent. Wenn das Leader-Speichersystem (311-40) die Informationen (311-10) generiert (311-08), die die Änderung des Datensatzes (311-42) beschreiben, könnte das Leader-Speichersystem (311-40) in diesem Beispiel Informationen (z. B. Sequenznummern für Schreiboperation A und Schreiboperation B) generieren, die die Reihenfolge angeben, in der die Anfragen ausgeführt werden sollten. Anstatt Informationen (311-10) zu generieren, die die Änderung des Datensatzes (311-42) beschreiben, was ein Zwischenverhalten von jedem Speichersystem (311-38, 311-40) erfordert, kann das Leader-Speichersystem (311-40) auch Informationen (311-10) generieren (311-08), die die Änderung des Datensatzes (311-42) beschreiben und Informationen enthalten, die das korrekte Ergebnis der beiden Anfragen identifizieren. Wenn z. B. Schreiboperation B logisch auf Schreiboperation A folgt (und sich mit Schreiboperation A überschneidet), muss das Endergebnis sein, dass der Datensatz (311-42) die Teile von Schreiboperation B enthält, die sich mit Schreiboperation A überschneiden, und nicht die Teile von Schreiboperation A, die sich mit Schreiboperation B überschneiden. Ein solches Ergebnis könnte durch das Zusammenführen eines Ergebnisses im Speicher und das Schreiben des Ergebnisses einer solchen Zusammenführung in den Datensatz (311-42) erleichtert werden, anstatt strikt zu verlangen, dass ein bestimmtes Speichersystem (311-38, 311-40) Schreiboperation A und anschließend Schreiboperation B ausführt.
  • Der Leser wird auch verstehen, dass korrekte Ergebnisse für jede Operation so weit übertragen werden müssen, dass sie wiederhergestellt werden können, bevor die Operation bestätigt werden kann. Mehrere Vorgänge können jedoch zusammen übertragen werden, oder Vorgänge können teilweise übertragen werden, wenn die Wiederherstellung die Korrektheit gewährleisten würde. Beispielsweise könnte ein Snapshot lokal mit einer aufgezeichneten Abhängigkeit von einer erwarteten Schreiboperation von A und B übertragen werden, aber A oder B könnten selbst nicht übertragen worden sein. Der Snapshot kann nicht bestätigt werden, und die Wiederherstellung könnte dazu führen, dass der Snapshot zurückgesetzt wird, wenn die fehlende E/A nicht von einem anderen Array wiederhergestellt werden kann. Wenn sich die Schreiboperation B mit der Schreiboperation A überschneidet, kann der Leader die Schreiboperation B nach der Schreiboperation A „anordnen“, aber A könnte tatsächlich verworfen werden und die Schreiboperation A würde dann einfach auf B warten. Die Schreiboperationen A, B, C und D, gekoppelt mit einem Snapshot zwischen A, B und C, D, könnten einige oder alle Teile zusammen übertragen und/oder bestätigt werden, solange die Wiederherstellung nicht zu einer Snapshot-Inkonsistenz zwischen den Arrays führen kann und solange die Bestätigung eine spätere Operation nicht abschließt, bevor eine frühere Operation soweit persistiert wurde, dass sie garantiert wiederherstellbar ist.
  • Das in 3E dargestellte Beispielverfahren umfasst auch das Senden (311-12) von Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, von dem Leader-Speichersystem (311-40) an ein Follower-Speichersystem (311-38). Das Senden (311-12) von Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, von dem Leader-Speichersystem (311-40) an ein Follower-Speichersystem (311-38) kann zum Beispiel dadurch erfolgen, dass das Leader-Speichersystem (311-40) eine oder mehrere Nachrichten an das Follower-Speichersystem (311-38) sendet. Das Leader-Speichersystem (311-40) kann in denselben Nachrichten oder in einer oder mehreren verschiedenen Nachrichten auch E/A-Nutzlast (311-14) für die Anforderung (311-04) zur Änderung des Datensatzes (311-42) senden. Die E/A-Nutzlast (311-14) kann beispielsweise als Daten verkörpert werden, die in den Speicher innerhalb des Follower-Speichersystems (311-38) zu schreiben sind, wenn die Anforderung (311-04) zur Änderung des Datensatzes (311-42) als Anforderung zum Schreiben von Daten in den Datensatz (311-42) verkörpert wird. In einem solchen Beispiel hat das Follower-Speichersystem (311-38) die mit der Anforderung (311-04) zum Ändern des Datensatzes (311-42) verbundene E/A-Nutzlast (311-14) nicht empfangen, da die Anforderung (311-04) zum Ändern des Datensatzes (311-42) von dem Leader-Speichersystem (311-40) empfangen wurde (311-06). In dem in 3E dargestellten Beispielverfahren können die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, und die E/A-Nutzlast (311-14), die mit der Anforderung (311-04) zum Ändern des Datensatzes (311-42) verbunden ist, von dem Leader-Speichersystem (311-40) an das Follower-Speichersystem (311-38) über ein oder mehrere Datenkommunikationsnetze gesendet werden (311-12), die das Leader-Speichersystem (311-40) mit dem Follower-Speichersystem (311-38) verbinden, über eine oder mehrere dedizierte Datenkommunikationsverbindungen (z.B. über eine oder mehrere dedizierte Datenkommunikationsverbindungen (z. B. eine erste Verbindung zum Senden von E/A-Nutzlast und eine zweite Verbindung zum Senden von Informationen, die Änderungen an Datensätzen beschreiben), die das Leader-Speichersystem (311-40) mit dem Follower-Speichersystem (311-38) verbinden, oder über einen anderen Mechanismus.
  • Das in 3E dargestellte Beispielverfahren umfasst auch das Empfangen (311-16) der Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, durch das Follower-Speichersystem (311-38). Das Follower-Speichersystem (311-38) kann die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, und die E/A-Nutzlast (311-14) vom Leader-Speichersystem (311-40) empfangen (311-16), beispielsweise über eine oder mehrere Nachrichten, die vom Leader-Speichersystem (311-40) an das Follower-Speichersystem (311-38) gesendet werden. Die eine oder mehreren Nachrichten können vom Leader-Speichersystem (311-40) an das Follower-Speichersystem (311-38) über eine oder mehrere dedizierte Datenkommunikationsverbindungen zwischen den beiden Speichersystemen (311-38, 311-40) gesendet werden, indem das Leader-Speichersystem (311-40) die Nachricht an einen vorbestimmten Speicherplatz (z. B. den Platz einer Warteschlange) auf dem Follower-Speichersystem (311-38) unter Verwendung von RDMA oder eines ähnlichen Mechanismus schreibt, oder auf andere Weise.
  • In einer Ausführungsform kann das Follower-Speichersystem (311-38) die Informationen (311-10), die die Änderung des Datensatzes (311-42) und der E/A-Nutzlast (311-14) beschreiben, vom Leader-Speichersystem (311-40) durch die Verwendung von SCSI-Anforderungen (Schreibvorgänge vom Sender zum Empfänger oder Lesevorgänge vom Empfänger zum Sender) als Kommunikationsmechanismus empfangen (311-16). In einer solchen Ausführungsform wird eine SCSI-Schreibanforderung verwendet, um Informationen zu kodieren, die gesendet werden sollen (einschließlich beliebiger Daten und Metadaten) und die an ein spezielles Pseudogerät oder über ein speziell konfiguriertes SCSI-Netz oder über einen anderen vereinbarten Adressierungsmechanismus geliefert werden können. Alternativ kann das Modell eine Reihe offener SCSI-Leseanforderungen von einem Empfänger an einen Sender ausgeben, ebenfalls unter Verwendung spezieller Geräte, speziell konfigurierter SCSI-Netze oder anderer vereinbarter Mechanismen. Als Antwort auf eine oder mehrere dieser offenen SCSI-Anforderungen werden verschlüsselte Informationen, einschließlich Daten und Metadaten, an den Empfänger geliefert. Ein solches Modell kann über Fibre-Channel-SCSI-Netze implementiert werden, die häufig als „Dark-Fibre“-Speichernetzinfrastruktur zwischen Rechenzentren eingesetzt werden. Ein solches Modell ermöglicht auch die Verwendung derselben Netzwerkleitungen für die Multipathing-Kommunikation zwischen Host und entfernten Arrays sowie für die Massenkommunikation zwischen Arrays.
  • Das in 3E dargestellte Beispielverfahren umfasst auch die Verarbeitung (311-18) der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Follower-Speichersystem (311-38). In dem in 3E dargestellten Beispielverfahren kann das Follower-Speichersystem (311-38) die Anforderung (311-04) zum Ändern des Datensatzes (311-42) verarbeiten (311-18), indem es den Inhalt eines oder mehrerer Speichergeräte (z. B. ein NVRAM-Gerät, eine SSD, eine HDD), die in dem Follower-Speichersystem (311-38) enthalten sind, in Abhängigkeit von den Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, sowie von der E/A-Nutzlast (311-14), die von dem Leader-Speichersystem (311-40) empfangen wurde. Betrachten wir ein Beispiel, in dem die Anforderung (311-04) zum Ändern des Datensatzes (311-42) als Schreiboperation ausgeführt wird, der an einen Datenträger gerichtet ist, welcher im Datensatz (311-42) enthalten ist, und die Information (311-10), die die Änderung des Datensatzes (311-42) beschreibt, angibt, dass die Schreiboperation erst ausgeführt werden kann, nachdem eine zuvor ausgegebene Schreiboperation verarbeitet worden ist. In einem solchen Beispiel kann die Verarbeitung (311-18) der Anforderung (311-04) zum Ändern des Datensatzes (311-42) dadurch erfolgen, dass das Follower-Speichersystem (311-38) zunächst verifiziert, dass die zuvor ausgegebene Schreiboperation auf dem Follower-Speichersystem (311-38) verarbeitet wurde, und anschließend die mit der Schreiboperation verbundene E/A-Nutzlast (311-14) auf ein oder mehrere Speichergeräte schreibt, die in dem Follower-Speichersystem (311-38) enthalten sind. In einem solchen Beispiel kann die Anforderung (311-04) zum Ändern des Datensatzes (311-42) als abgeschlossen und erfolgreich verarbeitet angesehen werden, wenn beispielsweise die E/A-Nutzlast (311-14) in den permanenten Speicher innerhalb des Follower-Speichersystems (311-38) übertragen wurde.
  • Das in 3E dargestellte Beispielverfahren umfasst auch die Bestätigung (311-20) der Fertigstellung der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Follower-Speichersystem (311-38) an das Leader-Speichersystem (311-40). In dem in 3E dargestellten Beispielverfahren kann die Bestätigung (311-20) des Abschlusses der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Follower-Speichersystem (311-38) an das Leader-Speichersystem (311-40) dadurch erfolgen, dass das Follower-Speichersystem (311-38) eine Bestätigungsmeldung (311-22) an das Leader-Speichersystem (311-40) sendet. Solche Nachrichten können beispielsweise Informationen enthalten, die die bestimmte Anforderung (311-04) zur Änderung des Datensatzes (311-42) identifizieren, die abgeschlossen wurde, sowie alle zusätzlichen Informationen, die für die Bestätigung (311-20) des Abschlusses der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Follower-Speichersystem (311-38) nützlich sind. In dem in 3E dargestellten Beispielverfahren wird die Bestätigung (311-20) des Abschlusses der Anforderung (311-04) zur Änderung des Datensatzes (311-42) an das Leader-Speichersystem (311-40) dadurch veranschaulicht, dass das Follower-Speichersystem (311-38) eine Bestätigungsnachricht (311-22) an das Leader-Speichersystem (311-38) sendet.
  • Das in 3E dargestellte Beispielverfahren umfasst auch die Verarbeitung (311-24) der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Leader-Speichersystem (311-40). In dem in 3E dargestellten Beispielverfahren kann das Leader-Speichersystem (311-40) die Anforderung (311-04) zum Ändern des Datensatzes (311-42) verarbeiten (311-24), indem es den Inhalt eines oder mehrerer Speichergeräte (z.B. ein NVRAM-Gerät, eine SSD, eine HDD), die in dem Leader-Speichersystem (311-40) enthalten sind, in Abhängigkeit von den Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, sowie von der E/A-Nutzlast (311-14), die als Teil der Anforderung (311-04) zur Änderung des Datensatzes (311-42) empfangen wurde, modifiziert. Betrachten wir ein Beispiel, in dem die Anforderung (311-04) zum Ändern des Datensatzes (311-42) als Schreiboperation ausgeführt wird, die an einen Datenträger gerichtet ist, der in dem Datensatz (311-42) enthalten ist, und die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, angeben, dass die Schreiboperation erst ausgeführt werden kann, nachdem eine zuvor ausgegebene Schreiboperation verarbeitet wurde. In einem solchen Beispiel kann die Verarbeitung (311-24) der Anforderung (311-04) zum Ändern des Datensatzes (311-42) durch das Leader-Speichersystem (311-40) durchgeführt werden, indem zunächst überprüft wird, ob die zuvor ausgegebene Schreiboperation durch das Leader-Speichersystem (311-40) verarbeitet wurde, und anschließend die mit der Schreiboperation verbundene E/A-Nutzlast (311-14) auf ein oder mehrere Speichergeräte geschrieben wird, die im Leader-Speichersystem (311-40) enthalten sind. In einem solchen Beispiel kann die Anforderung (311-04) zum Ändern des Datensatzes (311-42) als abgeschlossen und erfolgreich verarbeitet angesehen werden, wenn beispielsweise die E/A-Nutzlast (311-14) in den permanenten Speicher des Leader-Speichersystems (311-40) übertragen wurde.
  • Das in 3E dargestellte Beispielverfahren umfasst auch das Empfangen (311-26) einer Anzeige vom Follower-Speichersystem (311-38), dass das Follower-Speichersystem (311-38) die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeitet hat. In diesem Beispiel wird die Anzeige, dass das Follower-Speichersystem (311-38) die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeitet hat, als eine Bestätigungsnachricht (311-22) dargestellt, die vom Follower-Speichersystem (311-38) an das Leader-Speichersystem (311-40) gesendet wird. Der Leser wird verstehen, dass viele der oben beschriebenen Schritte zwar in einer bestimmten Reihenfolge dargestellt und beschrieben werden, aber eigentlich keine bestimmte Reihenfolge erforderlich ist. Da das Follower-Speichersystem (311-38) und das Leader-Speichersystem (311-40) unabhängige Speichersysteme sind, kann jedes Speichersystem einige der oben beschriebenen Schritte parallel durchführen. Zum Beispiel kann das Follower-Speichersystem (311-38) die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, empfangen (311-16), die Anfrage (311-04) zur Änderung des Datensatzes (311-42) verarbeiten (311-18), oder den Abschluss der Anforderung (311-04) zur Änderung des Datensatzes (311-42) bestätigen (311-20), bevor das Leader-Speichersystem (311-40) die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeitet hat (311-24). Alternativ kann das Leader-Speichersystem (311-40) die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeitet (311-24) haben, bevor das Follower-Speichersystem (311-38) die Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, erhalten hat (311-16), die Anforderung (311-04) zur Änderung des Datensatzes (311-42) verarbeitet (311-18) oder die Fertigstellung der Anforderung (311-04) zur Änderung des Datensatzes (311-42) bestätigt (311-20) hat.
  • Das in 3E dargestellte Beispielverfahren umfasst auch die Bestätigung (311-34) der Fertigstellung der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch das Leader-Speichersystem (311-40). In dem in 3E dargestellten Beispielverfahren kann die Bestätigung (311-34) des Abschlusses der Anforderung (311-04) zur Änderung des Datensatzes (311-42) durch die Verwendung einer oder mehrerer Bestätigungsmeldungen (311-36) erfolgen, die vom Leader-Speichersystem (311-40) an den Host (311-02) oder über einen anderen geeigneten Mechanismus gesendet werden. In dem in 3E dargestellten Beispielverfahren kann das Leader-Speichersystem (311-40) feststellen (311-28), ob die Anforderung (311-04) zur Änderung des Datensatzes (311-42) vom Follower-Speichersystem (311-38) verarbeitet wurde (311-18), bevor es den Abschluss der Anforderung (311-04) zur Änderung des Datensatzes (311-42) bestätigt (311-34). Das Leader-Speichersystem (311-40) kann feststellen (311-28), ob die Anfrage (311-04) zur Änderung des Datensatzes (311-42) vom Follower-Speichersystem (311-38) verarbeitet wurde (311-18), z. B. indem festgestellt wird, ob das Leader-Speichersystem (311-40) eine Bestätigungsnachricht oder eine andere Nachricht von dem Follower-Speichersystem (311-38) erhalten hat, die anzeigt, dass die Anforderung (311-04) zum Ändern des Datensatzes (311-42) von dem Follower-Speichersystem (311-38) verarbeitet wurde (311-18). Wenn in einem solchen Beispiel das Leader-Speichersystem (311-40) bestätigend (311-30) feststellt, dass die Anfrage (311-04) zum Ändern des Datensatzes (311-42) durch das Follower-Speichersystem (311-38) verarbeitet (311-18) und auch durch das Leader-Speichersystem (311-38) verarbeitet (311-24) wurde, wird das Leader-Speichersystem (311-40) die Anfrage (311-04) zum Ändern des Datensatzes (311-42) durch das Follower-Speichersystem (311-38) verarbeiten, kann das Leader-Speichersystem (311-40) fortfahren, indem es dem Host (311-02), der die Anfrage (311-04) zum Ändern des Datensatzes (311-42) initiiert hat, den Abschluss der Anfrage (311-04) zum Ändern des Datensatzes (311-42) bestätigt (311-34). Wenn das Leader-Speichersystem (311-40) feststellt, dass die Anfrage (311-04) zum Ändern des Datensatzes (311-42) nicht (311-32) durch das Follower-Speichersystem (311-38) verarbeitet wurde (311-18) oder nicht durch das Leader-Speichersystem (311-38) verarbeitet wurde (311-24), kann das Leader-Speichersystem (311-40) jedoch dem Host (311-02), der die Anfrage (311-04) zum Ändern des Datensatzes (311-42) initiiert hat, noch nicht den Abschluss der Anfrage (311-04) zum Ändern des Datensatzes (311-42) bestätigen (311-34), da das Leader-Speichersystem (311-40) dem Host (311-02), der die Anfrage (311-04) zum Ändern des Datensatzes (311-42) initiiert hat, den Abschluss der Anfrage (311-04) zum Ändern des Datensatzes (311-42) nur dann bestätigen kann (311-34), wenn die Anfrage (311-04) zum Ändern des Datensatzes (311-42) auf allen Speichersystemen (311-38, 311-40), über die ein Datensatz (311-42) synchron repliziert wird, erfolgreich verarbeitet wurde.
  • Der Leser wird verstehen, dass in dem in 3E dargestellten Beispielverfahren das Senden (311-12) von Informationen (311-10), die die Änderung des Datensatzes (311-42) beschreiben, vom Leader-Speichersystem (311-40) an ein Follower-Speichersystem (311-38), und das Bestätigen (311-20), durch das Follower-Speichersystem (311-38) an das Leader-Speichersystem (311-40), des Abschlusses der Anfrage (311-04) zur Änderung des Datensatzes (311-42) unter Verwendung von Single-Roundtrip-Messaging durchgeführt werden kann. Single-Roundtrip-Messaging kann z. B. durch die Verwendung von Fibre Channel als Datenverbindung genutzt werden. In der Regel werden SCSI-Protokolle mit Fibre Channel verwendet. Solche Verbindungen werden in der Regel zwischen Rechenzentren bereitgestellt, da einige ältere Replikationstechnologien im Wesentlichen für die Replikation von Daten als SCSI-Transaktionen über Fibre-Channel-Netzwerke ausgelegt sind. Außerdem hatte die Fibre-Channel-SCSI-Infrastruktur in der Vergangenheit weniger Overhead und geringere Latenzen als Netzwerke, die auf Ethernet und TCP/IP basieren. Wenn Rechenzentren intern mit Blockspeicher-Arrays über Fibre Channel verbunden sind, können die Fibre Channel-Netzwerke auch auf andere Rechenzentren ausgedehnt werden, so dass Hosts in einem Rechenzentrum auf Speicher-Arrays in einem entfernten Rechenzentrum zugreifen können, wenn lokale Speicher-Arrays ausfallen.
  • SCSI kann als allgemeiner Kommunikationsmechanismus verwendet werden, auch wenn es normalerweise für die Verwendung mit Blockspeicherprotokollen zum Speichern und Abrufen von Daten in blockorientierten Datenträgern (oder für Bänder) konzipiert ist. SCSI READ oder SCSI WRITE könnten beispielsweise dazu verwendet werden, um Nachrichtendaten zwischen Speicher-Controllern in gepaarten Speichersystemen zu übermitteln oder abzurufen. Eine typische Implementierung von SCSI WRITE erfordert zwei Nachrichtenumläufe: Ein SCSI-Initiator sendet einen SCSI CDB, der die SCSI WRITE-Operation beschreibt, ein SCSI-Ziel empfängt diesen CDB und das SCSI-Ziel sendet eine „Ready to Receive“-Nachricht an den SCSI-Initiator. Der SCSI-Initiator sendet dann Daten an das SCSI-Ziel, und wenn SCSI WRITE abgeschlossen ist, antwortet das SCSI-Ziel dem SCSI-Initiator mit einer Erfolgsmeldung. Eine SCSI READ-Anforderung hingegen erfordert nur einen Hin- und Rückweg: Der SCSI-Initiator sendet einen SCSI CDB, der die SCSI READ-Operation beschreibt, ein SCSI-Ziel empfängt diesen CDB und antwortet mit Daten und dann mit einem „Success Completion“. Folglich verursacht ein SCSI READ über die Entfernung nur die Hälfte der entfernungsbedingten Latenzzeit wie ein SCSI WRITE. Aus diesem Grund kann es für einen Datenkommunikationsempfänger schneller sein, SCSI READ-Anforderungen zum Empfangen von Nachrichten zu verwenden als für einen Sender von Nachrichten, SCSI WRITE-Anforderungen zum Senden von Daten zu verwenden. Die Verwendung von SCSI READ setzt lediglich voraus, dass ein Nachrichtensender als SCSI-Ziel und ein Nachrichtenempfänger als SCSI-Initiator arbeitet. Ein Nachrichtenempfänger kann eine gewisse Anzahl von SCSI CDB READ-Anforderungen an einen beliebigen Nachrichtenabsender senden, und der Nachrichtenabsender würde auf eine der ausstehenden CDB READ-Anforderungen antworten, wenn Nachrichtendaten verfügbar sind. Da SCSI-Subsysteme eine Zeitüberschreitung erleiden können, wenn eine READ-Anforderung zu lange aussteht (z. B. 10 Sekunden), sollten READ-Anforderungen innerhalb weniger Sekunden beantwortet werden, auch wenn keine Nachrichtendaten zu senden sind.
  • SCSI-Bandanfragen, wie sie in der Norm SCSI Stream Commands des Technischen Komitees T10 des InterNational Committee on Information Technology Standards beschrieben sind, unterstützen variable Antwortdaten, die bei der Rückgabe von Nachrichtendaten variabler Größe flexibler sein können. Der SCSI-Standard unterstützt auch einen Sofortmodus für SCSI-WRITE-Anforderungen, der Single-Round-Trip SCSI-WRITE-Befehle ermöglichen könnte. Der Leser wird verstehen, dass viele der unten beschriebenen Ausführungsformen auch Single-Round-Trip-Messaging verwenden.
  • Zur weiteren Erläuterung wird in 4 ein Beispiel für ein cloudbasiertes Speichersystem (403) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung dargestellt. In dem in 4 dargestellten Beispiel wird das cloudbasierte Speichersystem (403) vollständig in einer Cloud-Computing-Umgebung (402) erstellt, wie z.B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere. Das cloudbasierte Speichersystem (403) kann zur Bereitstellung von Diensten verwendet werden, die den Diensten ähnlich sind, die von den vorstehend beschriebenen Speichersystemen bereitgestellt werden können. Beispielsweise kann das cloudbasierte Speichersystem (403) verwendet werden, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems (403) bereitzustellen, das cloudbasierte Speichersystem (403) kann verwendet werden, um Speicherdienste für Benutzer des cloudbasierten Speichersystems (403) durch die Verwendung von Festkörperspeichern bereitzustellen, und so weiter.
  • Das in 4 dargestellte cloudbasierte Speichersystem (403) umfasst zwei Cloud-Computing-Instanzen (404, 406), die jeweils zur Unterstützung der Ausführung einer Speichersteuerungsanwendung (408, 410) verwendet werden. Die Cloud-Computing-Instanzen (404, 406) können beispielsweise als Instanzen von Cloud-Computing-Ressourcen (z.B. virtuelle Maschinen) verkörpert werden, die von der Cloud-Computing-Umgebung (402) bereitgestellt werden können, um die Ausführung von Software-Anwendungen wie der Speichersteuerungsanwendung (408, 410) zu unterstützen. In einer Ausführungsform können die Cloud-Computing-Instanzen (404, 406) als Amazon Elastic Compute Cloud („EC2“-Instanzen) ausgeführt werden. In einem solchen Beispiel kann ein Amazon Machine Image („AMI“), das die Speichersteuerungsanwendung (408, 410) einschließt, gebootet werden, um eine virtuelle Maschine zu erstellen und zu konfigurieren, die die Speichersteuerungsanwendung ausführen kann (408, 410).
  • In der in 4 dargestellten Beispielmethode kann die Speichersteuerungsanwendung (408, 410) als ein Modul von Computerprogrammbefehlen verkörpert sein, das bei seiner Ausführung verschiedene Speicheraufgaben ausführt. Beispielsweise kann die Speichersteuerungsanwendung (408, 410) als ein Modul von Computerprogrammbefehlen ausgeführt werden, das bei seiner Ausführung dieselben Aufgaben wie die vorstehend beschriebenen Controller (110A, 110B in 1A) ausführt, wie z.B. das Schreiben von Daten, die von den Benutzern des cloudbasierten Speichersystems (403) empfangen wurden, in das cloudbasierte Speichersystem (403), das Löschen von Daten aus dem cloudbasierten Speichersystem (403), das Abrufen von Daten aus dem cloudbasierten Speichersystem (403) und das Bereitstellen solcher Daten für Benutzer des cloudbasierten Speichersystems (403), das Überwachen und Berichten der Plattenauslastung und -leistung, das Durchführen von Redundanzoperationen, wie z.B. Redundant Array of Independent Drives („RAID“) oder RAID-ähnliche Datenredundanzoperationen, das Komprimieren von Daten, das Verschlüsseln von Daten, das Deduplizieren von Daten und so weiter. Da es zwei Cloud-Computing-Instanzen (404, 406) gibt, die jeweils die Speichersteuerungsanwendung (408, 410) enthalten, werden die Leser erkennen, dass in einigen Ausführungsformen eine Cloud-Computing-Instanz (404) als primärer Controller wie vorstehend beschrieben arbeiten kann, während die andere Cloud-Computing-Instanz (406) als sekundärer Controller wie vorstehend beschrieben arbeiten kann. Um Kosten zu sparen, kann in einem solchen Beispiel die Cloud-Computing-Instanz (404), die als primäre Steuerung fungiert, auf einer relativ leistungsstarken und relativ teuren Cloud-Computing-Instanz eingesetzt werden, während die Cloud-Computing-Instanz (406), die als sekundäre Steuerung fungiert, auf einer relativ leistungsschwachen und relativ kostengünstigen Cloud-Computing-Instanz eingesetzt werden kann. Für den Leser ist zu erkennen, dass die in 4 dargestellte Speichersteuerungsanwendung (408, 410) identischen Quellcode enthalten kann, der in verschiedenen Cloud-Computing-Instanzen (404, 406) ausgeführt wird.
  • Betrachten wir ein Beispiel, in dem die Cloud-Computing-Umgebung (402) als AWS und die Cloud-Computing-Instanzen als EC2-Instanzen verkörpert sind. In einem solchen Beispiel bietet AWS viele Arten von EC2-Instanzen an. Beispielsweise bietet AWS eine Reihe von EC2-Instanzen für allgemeine Zwecke an, die unterschiedliche Speicher- und Verarbeitungsleistungsniveaus aufweisen. In einem solchen Beispiel kann die Cloud-Computing-Instanz (404), die als primärer Controller fungiert, auf einem der Instanztypen eingesetzt werden, der über relativ viel Speicher und Verarbeitungsleistung verfügt, während die Cloud-Computing-Instanz (406), die als sekundärer Controller fungiert, auf einem der Instanztypen eingesetzt werden kann, der über relativ wenig Speicher und Verarbeitungsleistung verfügt. In einem solchen Beispiel kann beim Auftreten eines Failover-Ereignisses, bei dem die Rollen des primären und sekundären Controllers vertauscht werden, tatsächlich ein doppeltes Failover durchgeführt werden, so dass 1) ein erstes Failover-Ereignis, bei dem die Cloud-Computing-Instanz (406), die zuvor als sekundärer Controller arbeitete, als primärer Controller zu arbeiten beginnt, und 2) eine dritte Cloud-Computing-Instanz (nicht gezeigt), die von einem Instanztyp ist, der eine relativ große Menge an Speicher und Verarbeitungsleistung aufweist, mit einer Kopie der Speichersteuerungsanwendung anläuft, wobei die dritte Cloud-Computing-Instanz als primärer Controller zu arbeiten beginnt, während die Cloud-Computing-Instanz (406), die ursprünglich als sekundärer Controller arbeitete, wieder als sekundärer Controller zu arbeiten beginnt. In einem solchen Beispiel kann die Cloud-Computing-Instanz (404), die ursprünglich als primärer Controller arbeitete, beendet werden. Für den Leser ist zu erkennen, dass in alternativen Ausführungsformen die Cloud-Computing-Instanz (404), die nach dem Failover-Ereignis als sekundärer Controller betrieben wird, weiterhin als sekundärer Controller betrieben werden kann und die Cloud-Computing-Instanz (406), die nach dem Auftreten des Failover-Ereignisses als primärer Controller betrieben wurde, beendet werden kann, sobald die dritte Cloud-Computing-Instanz (nicht gezeigt) die primäre Rolle übernommen hat.
  • Es ist für den Leser zu verstehen, dass sich die vorstehend beschriebenen Ausführungsformen zwar auf Ausführungsformen beziehen, bei denen eine Cloud-Computing-Instanz (404) als primärer Controller und die zweite Cloud-Computing-Instanz (406) als sekundärer Controller fungiert, dass aber auch andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Zum Beispiel kann jede Cloud-Computing-Instanz (404, 406) als primärer Controller für einen Teil des vom cloudbasierten Speichersystem (403) unterstützten Adressraums arbeiten, jede Cloud-Computing-Instanz (404, 406) kann als primärer Controller arbeiten, wobei die Bedienung der an das cloudbasierte Speichersystem (403) gerichteten E/A-Operationen auf andere Weise aufgeteilt wird, und so weiter. Tatsächlich kann in anderen Ausführungsformen, in denen Kosteneinsparungen Vorrang vor Leistungsanforderungen haben können, nur eine einzige Cloud-Computing-Instanz existieren, die die Speichersteuerungsanwendung enthält. In einem solchen Beispiel kann es bei einem Controller-Ausfall länger dauern, bis eine neue Cloud-Computing-Instanz, die die Speichersteuerungsanwendung enthält, wiederhergestellt werden kann, da eine neue Cloud-Computing-Instanz, die die Speichersteuerungsanwendung enthält, aufgespalten werden müsste, anstatt dass eine bereits erstellte Cloud-Computing-Instanz die Rolle der Bedienung von E/A-Operationen übernimmt, die andernfalls von der ausgefallenen Cloud-Computing-Instanz erledigt worden wären.
  • Das in 4 dargestellte cloudbasierte Speichersystem (403) umfasst Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokaler Speicherung (414, 418, 422). Die in 4 dargestellten Cloud-Computing-Instanzen (424a, 424b, 424n) können zum Beispiel als Instanzen von Cloud-Computing-Ressourcen verkörpert werden, die von der Cloud-Computing-Umgebung (402) zur Unterstützung der Ausführung von Software-Anwendungen bereitgestellt werden können. Die Cloud-Computing-Instanzen (424a, 424b, 424n) in 4 können sich von den vorstehend beschriebenen Cloud-Computing-Instanzen (404, 406) unterscheiden, da die Cloud-Computing-Instanzen (424a, 424b, 424n) in 4 über lokale Speicherressourcen (414, 418, 422) verfügen, während die Cloud-Computing-Instanzen (404, 406), die die Ausführung der Speichersteuerungsanwendung (408, 410) unterstützen, nicht über lokale Speicherressourcen verfügen müssen. Die Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) können z. B. als EC2 M5-Instanzen mit einem oder mehreren SSDs, als EC2 R5-Instanzen mit einem oder mehreren SSDs, als EC2 I3-Instanzen mit einem oder mehreren SSDs usw. ausgeführt werden. In einigen Ausführungsformen muss der lokale Speicher (414, 418, 422) als Festkörperspeicher (z. B. SSDs) und nicht als Speicher mit Festplattenlaufwerken ausgeführt werden.
  • In dem in 4 dargestellten Beispiel kann jede der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) einen Software-Daemon (412, 416, 420) enthalten, der, wenn er von einer Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, sich den Speichersteuerungsanwendungen (408, 410) so präsentieren kann, als wäre die Cloud-Computing-Instanz (424a, 424b, 424n) ein physisches Speichergerät (z. B. eine oder mehrere SSDs). In einem solchen Beispiel kann der Software-Daemon (412, 416, 420) Computerprogrammbefehle enthalten, die denen ähnlich sind, die normalerweise auf einem Speichergerät enthalten wären, so dass die Speichersteuerungsanwendungen (408, 410) dieselben Befehle senden und empfangen können, die ein Speicher-Controller an Speichergeräte senden würde. Auf diese Weise können die Speichersteuerungsanwendungen (408, 410) Code enthalten, der identisch (oder im Wesentlichen identisch) mit dem Code ist, der von den Controllern in den vorstehend beschriebenen Speichersystemen ausgeführt werden würde. In diesen und ähnlichen Ausführungsformen kann die Kommunikation zwischen den Speichersteuerungsanwendungen (408, 410) und den Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) iSCSI, NVMe over TCP, Messaging, ein benutzerdefiniertes Protokoll oder einen anderen Mechanismus verwenden.
  • In dem in 4 dargestellten Beispiel kann jede der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) auch an den Blockspeicher (426, 428, 430) gekoppelt werden, der von der Cloud-Computing-Umgebung (402) angeboten wird. Der Blockspeicher (426, 428, 430), der von der Cloud-Computing-Umgebung (402) angeboten wird, kann zum Beispiel als Amazon Elastic Block Store („EBS“-Volumes) ausgeführt werden. Zum Beispiel kann ein erstes EBS-Volumen (426) an eine erste Cloud-Computing-Instanz (424a) gekoppelt werden, ein zweites EBS-Volumen (428) an eine zweite Cloud-Computing-Instanz (424b) und ein drittes EBS-Volumen (430) an eine dritte Cloud-Computing-Instanz (424n). In einem solchen Beispiel kann der Blockspeicher (426, 428, 430), der von der Cloud-Computing-Umgebung (402) angeboten wird, ähnlich wie die vorstehend beschriebenen NVRAM-Geräte genutzt werden, wie der Software-Daemon (412, 416, 420) (oder ein anderes Modul), der innerhalb einer bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, bei Erhalt einer Anforderung zum Schreiben von Daten, ein Schreiben der Daten in das angeschlossene EBS-Volumen sowie ein Schreiben der Daten in die lokalen Speicherressourcen (414, 418, 422) initiieren kann. In einigen alternativen Ausführungsformen können Daten nur in die lokalen Speicherressourcen (414, 418, 422) innerhalb einer bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) geschrieben werden. In einer alternativen Ausführungsform kann anstelle des Blockspeichers (426, 428, 430), der von der Cloud-Computing-Umgebung (402) als NVRAM angeboten wird, der tatsächliche RAM auf jeder der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) als NVRAM verwendet werden, wodurch die Netzwerknutzungskosten gesenkt werden, die mit der Verwendung eines EBS-Volumes als NVRAM verbunden wären.
  • In dem in 4 dargestellten Beispiel können die Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) von Cloud-Computing-Instanzen (404, 406) genutzt werden, die die Ausführung der Speichersteuerungsanwendung (408, 410) unterstützen, um E/A-Operationen handzuhaben, die an das cloudbasierte Speichersystem (403) gerichtet sind. Betrachten wir ein Beispiel, bei dem eine erste Cloud-Computing-Instanz (404), die die Speichersteuerungsanwendung (408) ausführt, als primärer Controller fungiert. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz (404), die die Speichersteuerungsanwendung (408) ausführt, (direkt oder indirekt über den sekundären Controller) Anforderungen zum Schreiben von Daten in das cloudbasierte Speichersystem (403) von Benutzern des cloudbasierten Speichersystems (403) empfangen. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz (404), die die Speichersteuerungsanwendung (408) ausführt, verschiedene Aufgaben ausführen, wie z.B. das Deduplizieren der in der Anforderung enthaltenen Daten, das Komprimieren der in der Anforderung enthaltenen Daten, das Bestimmen, wohin die in der Anforderung enthaltenen Daten geschrieben werden sollen usw., bevor schließlich eine Anforderung zum Schreiben einer deduplizierten, verschlüsselten oder anderweitig möglicherweise aktualisierten Version der Daten an eine oder mehrere der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokaler Speicherung (414, 418, 422) gesendet wird. Jede Cloud-Computing-Instanz (404, 406) kann in einigen Ausführungsformen eine Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem (403) erhalten und schließlich eine Anforderung zum Lesen von Daten an eine oder mehrere der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) senden.
  • Die Leser werden erkennen, dass, wenn eine Anforderung zum Schreiben von Daten von einer bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) empfangen wird, der Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogramm-Befehlen, das auf der bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, so konfiguriert werden kann, dass die Daten nicht nur in seinen eigenen lokalen Speicher (414, 418) geschrieben werden, 422) Ressourcen und jeder geeignete Blockspeicher (426, 428, 430), die von der Cloud-Computing-Umgebung (402) angeboten werden, aber der Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, kann auch so konfiguriert werden, dass die Daten in einen cloudbasierten Objektspeicher (432) geschrieben werden, der an die bestimmte Cloud-Computing-Umgebung (424a, 424b, 424n) angeschlossen ist. Der cloudbasierte Objektspeicher (432), der an die bestimmte Cloud-Computing-Instanz (424a, 424b, 424n) angeschlossen ist, kann zum Beispiel als Amazon Simple Storage Service („S3“)-Speicher verkörpert werden, auf den die bestimmte Cloud-Computing-Instanz (424a, 424b, 424n) zugreifen kann. In anderen Ausführungsformen können die Cloud-Computing-Instanzen (404, 406), die jeweils die Speichersteuerungsanwendung (408, 410) enthalten, die Speicherung der Daten im lokalen Speicher (414, 418, 422) der Cloud-Computing-Instanzen (424a, 424b, 424n) und im cloudbasierten Objektspeicher (432) initiieren.
  • Für den Leser ist zu erkennen, dassder Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogramm-Befehlen, das die Daten in den Blockspeicher (z. B. lokale Speicher (414, 418, 422)-Ressourcen) und auch die Daten in den cloudbasierten Objektspeicher (432) schreibt, auf Verarbeitungsvorrichtungen unterschiedlichen Typs ausgeführt werden kann (z. B. unterschiedliche Typen von Cloud-Computing-Instanzen, Cloud-Computing-Instanzen, die unterschiedliche Verarbeitungsvorrichtungen enthalten). Tatsächlich kann der Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogrammbefehlen, das die Daten in Blockspeicher (z.B. Ressourcen des lokalen Speichers (414, 418, 422)) und auch die Daten in cloudbasierten Objektspeicher (432) schreibt, zwischen verschiedenen Typen von Cloud-Computing-Instanzen je nach Bedarf migriert werden.
  • Die Leser werden erkennen, dass, wie vorstehend beschrieben, das cloudbasierte Speichersystem (403) verwendet werden kann, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems (403) bereitzustellen. Während die lokalen Speicherressourcen (414, 418, 422) und die Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) genutzt werden, den Zugriff auf Blockebene unterstützen können, unterstützt der cloudbasierte Objektspeicher (432), der an die jeweilige Cloud-Computing-Instanz (424a, 424b, 424n) angeschlossen ist, nur den objektbasierten Zugriff. Um dem entgegenzuwirken, kann der Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, so konfiguriert werden, dass er Datenblöcke nimmt, diese Blöcke in Objekte verpackt und die Objekte in den cloudbasierten Objektspeicher (432) schreibt, der an die bestimmte Cloud-Computing-Instanz (424a, 424b, 424n) angeschlossen ist.
  • Betrachten wir ein Beispiel, bei dem Daten in 1 MB-Blöcken auf die lokalen Speicherressourcen (414, 418, 422) und die Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden, geschrieben werden. In einem solchen Beispiel wird angenommen, dass ein Benutzer des cloudbasierten Speichersystems (403) eine Anforderung zum Schreiben von Daten ausgibt, die nach dem Komprimieren und Deduplizieren durch die Speichersteuerungsanwendung (408, 410) dazu führt, dass 5 MB Daten geschrieben werden müssen. In einem solchen Beispiel ist das Schreiben der Daten in die lokalen Speicherressourcen (414, 418, 422) und die Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden, relativ einfach, da 5 Blöcke mit einer Größe von 1 MB auf die lokalen Speicherressourcen (414, 418, 422) und die Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) genutzt werden, geschrieben werden. In einem solchen Beispiel kann der Software-Daemon (412, 416, 420) oder ein anderes Modul von Computerprogrammbefehlen, das auf der jeweiligen Cloud-Computing-Instanz (424a, 424b, 424n) ausgeführt wird, konfiguriert werden, um: 1) ein erstes Objekt zu erzeugen, das die ersten 1 MB Daten enthält, und das erste Objekt in den cloudbasierten Objektspeicher (432) zu schreiben, 2) ein zweites Objekt zu erzeugen, das die zweiten 1 MB Daten enthält, und das zweite Objekt in den cloudbasierten Objektspeicher (432) zu schreiben, 3) ein drittes Objekt zu erzeugen, das die dritten 1 MB Daten enthält, und das dritte Objekt in den cloudbasierten Objektspeicher (432) zu schreiben, und so weiter. Daher kann in einigen Ausführungsformen jedes Objekt, das in den cloudbasierten Objektspeicher (432) geschrieben wird, identisch (oder fast identisch) groß sein. Für den Leser ist zu erkennen, dass in einem solchen Beispiel Metadaten, die mit den Daten selbst verbunden sind, in jedem Objekt enthalten sein können (z.B. sind die ersten 1 MB des Objekts Daten und der restliche Teil Metadaten, die mit den Daten verbunden sind).
  • Für den Leser ist zu erkennen, dass der cloudbasierte Objektspeicher (432) in das cloudbasierte Speichersystem (403) integriert werden kann, um die Haltbarkeit des cloudbasierten Speichersystems (403) zu erhöhen. Um mit dem vorstehend beschriebenen Beispiel fortzufahren, bei dem die Cloud-Computing-Instanzen (424a, 424b, 424n) EC2-Instanzen sind, werden die Leser verstehen, dass die EC2-Instanzen nur eine garantierte monatliche Verfügbarkeit von 99,9 % aufweisen und die im lokalen Instanzspeicher gespeicherten Daten nur während der Lebensdauer der EC2-lnstanz bestehen bleiben. Wenn man sich also auf die Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) als einzige Quelle für die persistente Datenspeicherung im cloudbasierten Speichersystem (403) verlässt, kann dies zu einem relativ unzuverlässigen Speichersystem führen. Ebenso sind EBS-Volumes für eine Verfügbarkeit von 99,999% ausgelegt. Daher kann selbst der Rückgriff auf EBS als persistente Datenspeicherung im cloudbasierten Speichersystem (403) zu einem Speichersystem führen, das nicht langlebig genug ist. Amazon S3 ist jedoch für eine Haltbarkeit von 99,99999999999% ausgelegt, was bedeutet, dass ein cloudbasiertes Speichersystem (403), das S3 in seinen Speicherpool aufnehmen kann, wesentlich langlebiger ist als verschiedene andere Optionen.
  • Für den Leser ist zu erkennen, dass ein cloudbasiertes Speichersystem (403), das S3 in seinen Speicherpool aufnehmen kann, zwar wesentlich langlebiger ist als verschiedene andere Optionen, die Verwendung von S3 als primärer Speicherpool jedoch zu einem Speichersystem mit relativ langensamen Antwortzeiten und relativ langen E/A-Latenzen führen kann. Daher speichert das in 4 dargestellte cloudbasierte Speichersystem (403) nicht nur Daten in S3, sondern das cloudbasierte Speichersystem (403) speichert auch Daten in lokalen Speicherressourcen (414, 418, 422) und Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) genutzt werden, so dass Lesevorgänge aus lokalen Speicherressourcen (414, 418, 422) und den Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden, bedient werden können, wodurch die Leselatenz reduziert wird, wenn Benutzer des cloudbasierten Speichersystems (403) versuchen, Daten aus dem cloudbasierten Speichersystem (403) zu lesen.
  • In einigen Ausführungsformen können alle Daten, die vom cloudbasierten Speichersystem (403) gespeichert werden, in Folgendem gespeichert werden: 1) in dem cloudbasierten Objektspeicher (432) und auch 2) in mindestens einer der lokalen Speicherressourcen (414, 418, 422) oder Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden. In solchen Ausführungsformen können die lokalen Speicherressourcen (414, 418, 422) und Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden, effektiv als Cache arbeiten, der im Allgemeinen alle Daten enthält, die auch in S3 gespeichert sind, so dass alle Lesevorgänge von Daten von den Cloud-Computing-Instanzen (424a, 424b, 424n) durchgeführt werden können, ohne dass die Cloud-Computing-Instanzen (424a, 424b, 424n) auf den cloudbasierten Objektspeicher (432) zugreifen müssen. Die Leser werden jedoch erkennen, dass in anderen Ausführungsformen alle Daten, die vom cloudbasierten Speichersystem (403) gespeichert werden, im cloudbasierten Objektspeicher (432) gespeichert werden können, jedoch weniger als alle Daten, die vom cloudbasierten Speichersystem (403) gespeichert werden, in mindestens einer der lokalen Speicherressourcen (414, 418, 422) oder Blockspeicherressourcen (426, 428, 430) gespeichert werden können, die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden. In einem solchen Beispiel können verschiedene Richtlinien verwendet werden, um zu bestimmen, welche Teilmenge der Daten, die vom cloudbasierten Speichersystem (403) gespeichert werden, in Folgendem vorhanden sein sollte: 1) in dem cloudbasierten Objektspeicher (432) und auch 2) in mindestens einer der lokalen Speicherressourcen (414, 418, 422) oder Blockspeicherressourcen (426, 428, 430), die von den Cloud-Computing-Instanzen (424a, 424b, 424n) verwendet werden.
  • Wie vorstehend beschrieben, haben die Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422), wenn sie als EC2-Instanzen verkörpert werden, nur eine garantierte monatliche Betriebszeit von 99.9% und die im lokalen Instanzenspeicher gespeicherten Daten bleiben nur während der Lebensdauer jeder Cloud-Computing-Instanz (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) erhalten. Daher können ein oder mehrere Module von Computerprogrammbefehlen, die innerhalb des cloudbasierten Speichersystems (403) ausgeführt werden (z.B. ein Überwachungsmodul, das auf einer eigenen EC2-Instanz ausgeführt wird), so ausgelegt sein, dass sie den Ausfall einer oder mehrerer Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) bewältigen können. In einem solchen Beispiel kann das Überwachungsmodul den Ausfall einer oder mehrerer der Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) handhaben, durch Erzeugen von einer oder mehreren neue Cloud-Computing-Instanzen mit lokalem Speicher, Abrufen von Daten, die auf den ausgefallenen Cloud-Computing-Instanzen (424a, 424b, 424n) gespeichert waren, aus dem cloudbasierten Objektspeicher (432), und Speichern der aus dem cloudbasierten Objektspeicher (432) abgerufenen Daten im lokalen Speicher auf den neu erstellten Cloud-Computing-Instanzen. Für den Leser ist zu erkennen, dass viele Varianten dieses Prozesses implementiert werden können.
  • Betrachten wir ein Beispiel, bei dem alle Cloud-Computing-Instanzen (424a, 424b, 424n) mit lokalem Speicher (414, 418, 422) ausgefallen sind. In einem solchen Beispiel kann das Überwachungsmodul neue Cloud-Computing-Instanzen mit lokalem Speicher erstellen, wobei Instanztypen mit hoher Bandbreite ausgewählt werden, die die maximalen Datenübertragungsraten zwischen den neu erstellten Cloud-Computing-Instanzen mit hoher Bandbreite mit lokalem Speicher und dem cloudbasierten Objektspeicher (432) ermöglichen. Für den Leser ist zu erkennen, dass Instanztypen ausgewählt werden, die die maximalen Datentransferraten zwischen den neuen Cloud-Computing-Instanzen und dem cloudbasierten Objektspeicher (432) ermöglichen, so dass die neuen Cloud-Computing-Instanzen mit hoher Bandbreite so schnell wie möglich mit Daten aus dem cloudbasierten Objektspeicher (432) rehydriert werden können. Sobald die neuen Cloud-Computing-Instanzen mit hoher Bandbreite mit Daten aus dem cloudbasierten Objektspeicher (432) rehydriert sind, können kostengünstigere Cloud-Computing-Instanzen mit geringerer Bandbreite erstellt werden, die Daten können zu den kostengünstigeren Cloud-Computing-Instanzen mit geringerer Bandbreite migriert werden, und die Cloud-Computing-Instanzen mit hoher Bandbreite können beendet werden.
  • Für den Leser ist zu erkennen, dass in einigen Ausführungsformen die Anzahl der neu geschaffenen Cloud-Computing-Instanzen die Anzahl der Cloud-Computing-Instanzen, die für die lokale Speicherung aller vom cloudbasierten Speichersystem (403) gespeicherten Daten benötigt werden, erheblich übersteigen kann. Die Anzahl neuer Cloud-Computing-Instanzen, die erzeugt werden, kann die Anzahl der Cloud-Computing-Instanzen, die benötigt werden, um alle vom cloudbasierten Speichersystem (403) gespeicherten Daten lokal zu speichern, erheblich übersteigen, um Daten schneller aus dem cloudbasierten Objektspeicher (432) und in die neuen Cloud-Computing-Instanzen zu ziehen, da jede neue Cloud-Computing-Instanz (parallel) einen Teil der vom cloudbasierten Speichersystem (403) gespeicherten Daten abrufen kann. In solchen Ausführungsformen können die Daten, sobald die vom cloudbasierten Speichersystem (403) gespeicherten Daten in die neu geschaffenen Cloud-Computing-Instanzen gezogen worden sind, innerhalb einer Teilmenge der neu geschaffenen Cloud-Computing-Instanzen konsolidiert werden, und die neu geschaffenen Cloud-Computing-Instanzen, die übermäßig viele Daten enthalten, können beendet werden.
  • Betrachten wir ein Beispiel, bei dem 1.000 Cloud-Computing-Instanzen benötigt werden, um alle gültigen Daten lokal zu speichern, die Benutzer des cloudbasierten Speichersystems (403) auf das cloudbasierte Speichersystem (403) geschrieben haben. Nehmen wir in einem solchen Beispiel an, dass alle 1.000 Cloud-Computing-Instanzen ausfallen. In einem solchen Beispiel kann das Überwachungsmodul bewirken, dass 100.000 Cloud-Computing-Instanzen erstellt werden, wobei jede Cloud-Computing-Instanz dafür verantwortlich ist, aus dem cloudbasierten Objektspeicher (432) verschiedene 1/100.000ste Segmente der gültigen Daten abzurufen, die Benutzer des cloudbasierten Speichersystems (403) in das cloudbasierte Speichersystem (403) geschrieben haben, und das verschiedene Segment des abgerufenen Datensatzes lokal zu speichern. Da in einem solchen Beispiel jede der 100.000 Cloud-Computing-Instanzen parallel Daten aus dem cloudbasierten Objektspeicher (432) abrufen kann, kann die Cache-Schicht im Vergleich zu einer Ausführungsform, bei der das Überwachungsmodul nur 1.000 Ersatz-Cloud-Computing-Instanzen erstellt, 100 Mal schneller wiederhergestellt werden. In einem solchen Beispiel könnten im Laufe der Zeit die Daten, die lokal in den 100.000 gespeichert sind, zu 1.000 Cloud-Computing-Instanzen konsolidiert und die verbleibenden 99.000 Cloud-Computing-Instanzen beendet werden.
  • Für den Leser ist zu erkennen, dass verschiedene Leistungsaspekte des cloudbasierten Speichersystems (403) überwacht werden können (z. B. durch ein Überwachungsmodul, das in einer EC2-Instanz ausgeführt wird), so dass das cloudbasierte Speichersystem (403) je nach Bedarf hoch- oder herunterskaliert werden kann. Betrachten wir ein Beispiel, in dem das Überwachungsmodul die Leistung des cloudbasierten Speichersystems (403) über die Kommunikation mit einer oder mehreren der Cloud-Computing-Instanzen (404, 406) überwacht, die jeweils zur Unterstützung der Ausführung einer Speichersteuerungsanwendung (408, 410) verwendet werden, über die Überwachung der Kommunikation zwischen Cloud-Computing-Instanzen (404, 406, 424a, 424b, 424n), über die Überwachung der Kommunikation zwischen Cloud-Computing-Instanzen (404, 406, 424a, 424b, 424n) und dem cloudbasierten Objektspeicher (432) oder auf andere Weise. Gehen wir in einem solchen Beispiel davon aus, dass das Überwachungsmodul feststellt, dass die Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung einer Speichersteuerungsanwendung (408, 410) verwendet werden, zu klein sind und die E/A-Anforderungen, die von Benutzern des cloudbasierten Speichersystems (403) ausgegeben werden, nicht in ausreichendem Maße handhaben. In einem solchen Beispiel kann das Überwachungsmodul eine neue, leistungsstärkere Cloud-Computing-Instanz erstellen (z.B. eine Cloud-Computing-Instanz eines Typs, der mehr Rechenleistung, mehr Speicher usw. umfasst), die die Speichersteuerungsanwendung einschließt, so dass die neue, leistungsstärkere Cloud-Computing-Instanz den Betrieb als primärer Controller aufnehmen kann. Wenn das Überwachungsmodul feststellt, dass die Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung einer Speichersteuerungsanwendung (408, 410) verwendet werden, überdimensioniert sind und dass durch den Wechsel zu einer kleineren, weniger leistungsstarken Cloud-Computing-Instanz Kosteneinsparungen erzielt werden könnten, kann das Überwachungsmodul eine neue, weniger leistungsstarke (und kostengünstigere) Cloud-Computing-Instanz erzeugen, die die Speichersteuerungsanwendung enthält, so dass die neue, weniger leistungsstarke Cloud-Computing-Instanz als primärer Controller in Betrieb genommen werden kann.
  • Betrachten wir als ein zusätzliches Beispiel für die dynamische Größenbestimmung des cloudbasierten Speichersystems (403) ein Beispiel, bei dem das Überwachungsmodul feststellt, dass die Auslastung des lokalen Speichers, der kollektiv von den Cloud-Computing-Instanzen (424a, 424b, 424n) bereitgestellt wird, einen vorgegebenen Auslastungsschwellenwert (z. B. 95 %) erreicht hat. In einem solchen Beispiel kann das Überwachungsmodul zusätzliche Cloud-Computing-Instanzen mit lokalem Speicher erzeugen, um den Pool des lokalen Speichers, der von den Cloud-Computing-Instanzen angeboten wird, zu erweitern. Alternativ kann das Überwachungsmodul eine oder mehrere neue Cloud-Computing-Instanzen erzeugen, die über größere Mengen an lokalem Speicher verfügen als die bereits vorhandenen Cloud-Computing-Instanzen (424a, 424b, 424n), so dass Daten, die in einer bereits vorhandenen Cloud-Computing-Instanz (424a, 424b, 424n) gespeichert sind, zu der einen oder den mehreren neuen Cloud-Computing-Instanzen migriert werden können und die bereits vorhandene Cloud-Computing-Instanz (424a, 424b, 424n) beendet werden kann, wodurch der Pool an lokalem Speicher, der von den Cloud-Computing-Instanzen angeboten wird, erweitert wird. Ebenso können Daten konsolidiert und einige Cloud-Computing-Instanzen beendet werden, wenn der von den Cloud-Computing-Instanzen angebotene Pool an lokalem Speicher unnötig groß ist.
  • Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem (403) durch ein Überwachungsmodul, das einen vorbestimmten Satz von Regeln anwendet, die relativ einfach oder relativ kompliziert sein können, automatisch vergrößert oder verkleinert werden kann. Tatsächlich kann das Überwachungsmodul nicht nur den aktuellen Zustand des cloudbasierten Speichersystems (403) berücksichtigen, sondern das Überwachungsmodul kann auch prädiktive Richtlinien anwenden, die z.B. auf beobachtetem Verhalten (z.B. jede Nacht von 22:00 Uhr bis 6:00 Uhr ist die Nutzung des Speichersystems relativ gering), vorbestimmten Fingerabdrücken (z.B. jedes Mal, wenn eine virtuelle Desktop-Infrastruktur 100 virtuelle Desktops hinzufügt, erhöht sich die Anzahl der an das Speichersystem gerichteten IOPS um X) und so weiter basieren. In einem solchen Beispiel kann die dynamische Skalierung des cloudbasierten Speichersystems (403) auf aktuellen Leistungsmetriken, vorhergesagten Arbeitslasten und vielen anderen Faktoren, einschließlich Kombinationen davon, basieren.
  • Die Leser werden außerdem erkennen, dass das cloudbasierte Speichersystem (403) sogar noch dynamischer arbeiten kann, da es dynamisch skalierbar ist. Betrachten wir das Beispiel der Garbage Collection. In einem herkömmlichen Speichersystem ist die Speichermenge fest vorgegeben. Daher kann das Speichersystem irgendwann gezwungen sein, Garbage Collection durchzuführen, da die Menge des verfügbaren Speichers so eingeschränkt ist, dass das Speichersystem kurz davor steht, den Speicher zu erschöpfen. Im Gegensatz dazu kann das hier beschriebene cloudbasierte Speichersystem (403) immer zusätzlichen Speicher „hinzufügen“ (z.B. durch Hinzufügen weiterer Cloud-Computing-Instanzen mit lokalem Speicher). Da das hier beschriebene cloudbasierte Speichersystem (403) immer zusätzlichen Speicher „hinzufügen“ kann, kann das cloudbasierte Speichersystem (403) intelligentere Entscheidungen darüber treffen, wann die Speicherbereinigung durchgeführt werden soll. Beispielsweise kann das cloudbasierte Speichersystem (403) eine Richtlinie implementieren, die besagt, dass die Speicherbereinigung nur dann durchgeführt wird, wenn die Anzahl der IOPS, die vom cloudbasierten Speichersystem (403) gewartet werden, unter ein bestimmtes Niveau fällt. In einigen Ausführungsformen können auch andere Funktionen auf Systemebene (z. B. Deduplizierung, Komprimierung) als Reaktion auf die Systembelastung aus- und eingeschaltet werden, da die Größe des cloudbasierten Speichersystems (403) nicht in der gleichen Weise eingeschränkt ist wie bei herkömmlichen Speichersystemen.
  • Für den Leser ist zu erkennen, dass die Ausführungsformen der vorliegenden Offenbarung ein Problem mit Blockspeicherdiensten lösen, die von einigen Cloud-Computing-Umgebungen angeboten werden, da einige Cloud-Computing-Umgebungen es nur einer Cloud-Computing-Instanz erlauben, sich zu einem einzigen Zeitpunkt mit einem Blockspeichervolumen zu verbinden. Beispielsweise kann bei Amazon AWS nur eine einzige EC2-Instanz mit einem EBS-Volumen verbunden werden. Durch die Verwendung von EC2-Instanzen mit lokalem Speicher können Ausführungsformen der vorliegenden Offenbarung Multi-Verbindungsfähigkeiten bieten, bei denen mehrere EC2-Instanzen mit einer anderen EC2-Instanz mit lokalem Speicher („eine Laufwerksinstanz“) verbunden werden können. In solchen Ausführungsformen können die Laufwerksinstanzen Software enthalten, die innerhalb der Laufwerksinstanz ausgeführt wird und es der Laufwerksinstanz ermöglicht, einen E/A zu unterstützen, der von jeder angeschlossenen EC2-Instanz an ein bestimmtes Volume gerichtet ist. Als solche können einige Ausführungsformen der vorliegenden Offenbarung als Blockspeicherdienste mit mehreren Anschlüssen ausgeführt werden, die möglicherweise nicht alle in 4 dargestellten Komponenten umfassen.
  • In einigen Ausführungsformen, insbesondere in Ausführungsformen, in denen die Ressourcen des cloudbasierten Objektspeichers (432) als Amazon S3 verkörpert sind, kann das cloudbasierte Speichersystem (403) ein oder mehrere Module enthalten (z.B. ein Modul von Computerprogrammbefehlen, die auf einer EC2-Instanz ausgeführt werden), die so konfiguriert sind, dass sie sicherstellen, dass, wenn der lokale Speicher einer bestimmten Cloud-Computing-Instanz mit Daten aus S3 rehydriert wird, die entsprechenden Daten tatsächlich in S3 vorliegen. Diese Frage stellt sich vor allem deshalb, weil S3 ein mögliches Konsistenzmodell implementiert, bei dem beim Überschreiben eines vorhandenen Objekts die Lesevorgänge des Objekts schließlich (aber nicht unbedingt sofort) konsistent werden und schließlich (aber nicht unbedingt sofort) die überschriebene Version des Objekts zurückgeben. Um dieses Problem zu lösen, werden in einigen Ausführungsformen der vorliegenden Offenbarung Objekte in S3 niemals überschrieben. Stattdessen würde eine herkömmliche „Überschreibung“ zur Erstellung des neuen Objekts (das die aktualisierte Version der Daten enthält) und schließlich zur Löschung des alten Objekts (das die vorherige Version der Daten enthält) führen.
  • In einigen Ausführungsformen der vorliegenden Offenbarung, als Teil eines Versuchs, ein Objekt nie (oder fast nie) zu überschreiben, kann beim Schreiben von Daten nach S3 das resultierende Objekt mit einer Sequenznummer versehen werden. In einigen Ausführungsformen können diese Sequenznummern an anderer Stelle (z.B. in einer Datenbank) persistiert sein, so dass zu jedem Zeitpunkt die Sequenznummer bekannt sein kann, die mit der aktuellsten Version eines Datensegments verbunden ist. Auf diese Weise kann festgestellt werden, ob S3 über die aktuelle Version eines Datensegments verfügt, indem einfach die mit einem Objekt verbundene Sequenznummer gelesen wird - und ohne dass die Daten tatsächlich aus S3 gelesen werden. Die Möglichkeit, diese Bestimmung vorzunehmen, kann besonders wichtig sein, wenn eine Cloud-Computing-Instanz mit lokalem Speicher abstürzt, da es unerwünscht wäre, den lokalen Speicher einer Ersatz-Cloud-Computing-Instanz mit veralteten Daten zu rehydrieren. Da das cloudbasierte Speichersystem (403) nicht auf die Daten zugreifen muss, um ihre Gültigkeit zu verifizieren, können die Daten verschlüsselt bleiben und Zugriffsgebühren vermieden werden.
  • In dem in 4 dargestellten Beispiel und wie vorstehend beschrieben, können die Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung der Speichersteuerungsanwendungen (408, 410) verwendet werden, in einer primären/sekundären Konfiguration arbeiten, in der eine der Cloud-Computing-Instanzen (404 406), die zur Unterstützung der Ausführung der Speichersteuerungsanwendungen (408, 410) verwendet werden, für das Schreiben von Daten in den lokalen Speicher (414, 418, 422) verantwortlich ist, der an die Cloud-Computing-Instanzen mit lokalem Speicher (424a, 424b, 424n) angeschlossen ist. Da jedoch in einem solchen Beispiel jede der Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung der Speichersteuerungsanwendungen (408, 410) verwendet werden, auf die Cloud-Computing-Instanzen mit lokalem Speicher (424a, 424b, 424n) zugreifen kann, können beide Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung der Speichersteuerungsanwendungen (408, 410) verwendet werden, Anforderungen zum Lesen von Daten aus dem cloudbasierten Speichersystem (403) handhaben.
  • Zur weiteren Erläuterung wird in 5 ein Beispiel für ein zusätzliches cloudbasiertes Speichersystem (502) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung dargestellt. In dem in 5 dargestellten Beispiel wird das cloudbasierte Speichersystem (502) vollständig in einer Cloud-Computing-Umgebung (402) erstellt, wie z. B. AWS, Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere. Das cloudbasierte Speichersystem (502) kann zur Bereitstellung von Diensten verwendet werden, die den Diensten ähnlich sind, die von den vorstehend beschriebenen Speichersystemen bereitgestellt werden können. Beispielsweise kann das cloudbasierte Speichersystem (502) verwendet werden, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems (502) bereitzustellen, das cloudbasierte Speichersystem (403) kann verwendet werden, um Storage-Dienste für Benutzer des cloudbasierten Speichersystems (403) durch die Verwendung von Festkörperspeichern bereitzustellen, und so weiter.
  • Das in 5 dargestellte cloudbasierte Speichersystem (502) kann auf eine Weise funktionieren, die dem in 4 dargestellten cloudbasierten Speichersystem (403) etwas ähnlich ist, da das in 5 dargestellte cloudbasierte Speichersystem (502) eine Speichersteuerungsanwendung (506) enthält, die in einer Cloud-Computing-Instanz (504) ausgeführt wird. In dem in 5 dargestellten Beispiel ist die Cloud-Computing-Instanz (504), die die Speichersteuerungsanwendung (506) ausführt, jedoch eine Cloud-Computing-Instanz (504) mit lokalem Speicher (508). In einem solchen Beispiel können Daten, die in das cloudbasierte Speichersystem (502) geschrieben werden, sowohl im lokalen Speicher (508) der Cloud-Computing-Instanz (504) als auch im cloudbasierten Objektspeicher (510) auf die gleiche Weise gespeichert werden, wie der cloudbasierte Objektspeicher (510) oben verwendet wurde. In einigen Ausführungsformen kann beispielsweise die Speichersteuerungsanwendung (506) dafür verantwortlich sein, Daten in den lokalen Speicher (508) der Cloud-Computing-Instanz (504) zu schreiben, während ein Software-Daemon (512) dafür verantwortlich sein kann, sicherzustellen, dass die Daten in den cloudbasierten Objektspeicher (510) auf die gleiche Weise geschrieben werden, wie der cloudbasierte Objektspeicher (510) oben verwendet wurde. In anderen Ausführungsformen kann dieselbe Entität (z.B. die Speichersteuerungsanwendung) dafür verantwortlich sein, Daten in den lokalen Speicher (508) der Cloud-Computing-Instanz (504) zu schreiben und auch dafür verantwortlich sein, sicherzustellen, dass die Daten in den cloudbasierten Objektspeicher (510) auf die gleiche Weise geschrieben werden, wie der cloudbasierte Objektspeicher (510) oben verwendet wurde.
  • Für den Leser ist zu erkennen, dass ein cloudbasiertes Speichersystem (502), das in 5 dargestellt ist, möglicherweise eine kostengünstigere, weniger robuste Version eines cloudbasierten Speichersystems darstellt als in 4. In noch alternativen Ausführungsformen könnte das in 5 dargestellte cloudbasierte Speichersystem (502) zusätzliche Cloud-Computing-Instanzen mit lokalem Speicher enthalten, die die Ausführung der Speichersteuerungsanwendung (506) unterstützen, so dass ein Failover auftreten kann, wenn die Cloud-Computing-Instanz (504), die die Speichersteuerungsanwendung (506) ausführt, ausfällt. Ebenso kann in anderen Ausführungsformen das in 5 dargestellte cloudbasierte Speichersystem (502) zusätzliche Cloud-Computing-Instanzen mit lokalem Speicher enthalten, um die Menge an lokalem Speicher zu erweitern, die von den Cloud-Computing-Instanzen im cloudbasierten Speichersystem (502) angeboten wird.
  • Für den Leser ist zu erkennen, dass viele der oben mit Bezug auf 4 beschriebenen Fehlerszenarien auch das in 5 dargestellte cloudbasierte Speichersystem (502) gebrauchen würden. Ebenso kann das in 5 dargestellte cloudbasierte Speichersystem (502) in ähnlicher Weise wie vorstehend beschrieben dynamisch nach oben und unten skaliert werden. Auch die Ausführung verschiedener Aufgaben auf Systemebene kann von dem in 5 dargestellten cloudbasierten Speichersystem (502) auf intelligente Weise ausgeführt werden, wie vorstehend beschrieben.
  • Für den Leser ist zu erkennen, dass in dem Bemühen, die Widerstandsfähigkeit der vorstehend beschriebenen cloudbasierten Speichersysteme zu erhöhen, verschiedene Komponenten in verschiedenen Verfügbarkeitszonen untergebracht sein können. Beispielsweise kann sich eine erste Cloud-Computing-Instanz, die die Ausführung der Speichersteuerungsanwendung unterstützt, in einer ersten Verfügbarkeitszone befinden, während sich eine zweite Cloud-Computing-Instanz, die ebenfalls die Ausführung der Speichersteuerungsanwendung unterstützt, in einer zweiten Verfügbarkeitszone befinden kann. Ebenso können die Cloud-Computing-Instanzen mit lokalem Speicher über mehrere Verfügbarkeitszonen verteilt sein. Tatsächlich könnte in einigen Ausführungsformen ein ganzes zweites cloudbasiertes Speichersystem in einer anderen Verfügbarkeitszone erstellt werden, wobei Daten im ursprünglichen cloudbasierten Speichersystem (synchron oder asynchron) auf das zweite cloudbasierte Speichersystem repliziert werden, so dass bei einem Ausfall des gesamten ursprünglichen cloudbasierten Speichersystems ein Ersatzcloudbasiertes Speichersystem (das zweite cloudbasierte Speichersystem) in einer geringen Zeitspanne hochgefahren werden könnte.
  • Für den Leser ist zu erkennen, dass die hier beschriebenen cloudbasierten Speichersysteme als Teil einer Flotte von Speichersystemen eingesetzt werden können. Tatsächlich können die hier beschriebenen cloudbasierten Speichersysteme mit lokalen Speichersystemen gepaart werden. In einem solchen Beispiel können die im lokalen Speicher gespeicherten Daten (synchron oder asynchron) auf das cloudbasierte Speichersystem repliziert werden und umgekehrt.
  • Zur weiteren Erläuterung ist in 6 ein Flussdiagramm dargestellt, das eine Beispielmethode zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (604). Obwohl es weniger detailliert dargestellt ist, kann das in 6 dargestellte cloudbasierte Speichersystem (604) ähnlich wie die vorstehend beschriebenen cloudbasierten Speichersysteme sein und von einer Cloud-Computing-Umgebung (602) unterstützt werden.
  • Die in 6 dargestellte Beispielmethode umfasst das Empfangen (606) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (604) durch das cloudbasierte Speichersystem (604). Die Anforderung zum Schreiben von Daten kann z.B. von einer in der Cloud-Computing-Umgebung ausgeführten Anwendung, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise empfangen werden. In einem solchen Beispiel kann die Anforderung die Daten enthalten, die in das cloudbasierte Speichersystem (604) geschrieben werden sollen. In anderen Ausführungsformen kann die Anforderung, Daten in das cloudbasierte Speichersystem (604) zu schreiben, zur Boot-Zeit erfolgen, wenn das cloudbasierte Speichersystem (604) hochgefahren wird.
  • Die in 6 dargestellte Beispielmethode beinhaltet auch das Deduplizieren (608) der Daten. Die Daten-Deduplizierung ist eine Datenreduktionstechnik zur Eliminierung doppelter Kopien sich wiederholender Daten. Das cloudbasierte Speichersystem (604) kann die Daten deduplizieren (608), z.B. durch Vergleichen eines oder mehrerer Segmente der Daten mit Daten, die bereits im cloudbasierten Speichersystem (604) gespeichert sind, durch Vergleichen eines Fingerabdrucks für einen oder mehrere Segmente der Daten mit Fingerabdrücken für Daten, die bereits im cloudbasierten Speichersystem (604) gespeichert sind, oder auf andere Weise. In einem solchen Beispiel können doppelte Daten entfernt und durch einen Verweis auf eine bereits vorhandene Kopie der Daten ersetzt werden, die bereits im cloudbasierten Speichersystem (604) gespeichert ist.
  • Die in 6 dargestellte Beispielmethode beinhaltet auch das Komprimieren (610) der Daten. Datenkomprimierung ist eine Datenreduktionstechnik, bei der Informationen mit weniger Bits als die ursprüngliche Darstellung kodiert werden. Das cloudbasierte Speichersystem (604) kann die Daten komprimieren (610), indem es einen oder mehrere Datenkomprimierungsalgorithmen auf die Daten anwendet, die zu diesem Zeitpunkt möglicherweise keine Daten enthalten, die bereits im cloudbasierten Speichersystem (604) gespeichert sind.
  • Die in 6 dargestellte Beispielmethode beinhaltet auch das Verschlüsseln (612) der Daten. Bei der Datenverschlüsselung handelt es sich um eine Technik, bei der die Daten aus einem lesbaren Format in ein kodiertes Format umgewandelt werden, das erst nach der Entschlüsselung der Daten gelesen oder verarbeitet werden kann. Das cloudbasierte Speichersystem (604) kann die Daten, die zu diesem Zeitpunkt möglicherweise bereits dedupliziert und komprimiert sind, mit einem Kodierungsschlüssel verschlüsseln (612). Die Leser werden erkennen, dass, obwohl die in 6 dargestellte Ausführungsform das Deduplizieren (608) der Daten, das Komprimieren (610) der Daten und das Verschlüsseln (612) der Daten beinhaltet, andere Ausführungsformen existieren, in denen weniger dieser Schritte ausgeführt werden, und Ausführungsformen, in denen die gleiche Anzahl von Schritten oder weniger dieser Schritte in einer anderen Reihenfolge ausgeführt werden.
  • Die in 6 dargestellte Beispielmethode beinhaltet auch das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems (604). Das Speichern (614) der Daten in Blockspeicherung des cloudbasierten Speichersystems (604) kann z.B. durch Speichern (616) der Daten in einem Festkörperspeicher, wie eine lokale Speicherung (z.B. SSDs) einer oder mehrerer Cloud-Computing-Instanzen, wie oben näher beschrieben, erfolgen. In einem solchen Beispiel können die Daten über den lokalen Speicher vieler Cloud-Computing-Instanzen zusammen mit Paritätsdaten verteilt werden, um RAID- oder RAID-ähnliche Datenredundanz zu implementieren.
  • Das in 6 dargestellte Beispielverfahren umfasst auch das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems (604). Das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems kann das Erstellen (620) eines oder mehrerer gleich großer Objekte umfassen, wobei jedes gleich große Objekt ein bestimmtes Segment der Daten enthält. Da in einem solchen Beispiel jedes Objekt Daten und Metadaten enthält, kann der Datenteil jedes Objekts gleich groß sein. In anderen Ausführungsformen ist der Datenteil jedes erstellten Objekts möglicherweise nicht gleich groß. Beispielsweise könnte jedes Objekt die Daten aus einer vorgegebenen Anzahl von Blöcken in dem Blockspeicher enthalten, der im vorhergehenden Absatz oder auf andere Weise verwendet wurde.
  • Die in 6 dargestellte Beispielmethode umfasst auch das Empfangen (622) einer Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem durch das cloudbasierte Speichersystem (604). Die Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem (604) kann beispielsweise von einer Anwendung empfangen werden, die in der Cloud-Computing-Umgebung ausgeführt wird, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise. Die Anforderung kann z.B. eine logische Adresse der Daten enthalten, die aus dem cloudbasierten Speichersystem (604) gelesen werden sollen.
  • Die in 6 dargestellte Beispielmethode umfasst auch das Abrufen (624) der Daten aus dem Blockspeicher des cloudbasierten Speichersystems (604). Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem (604) die Daten aus dem Blockspeicher des cloudbasierten Speichersystems (604) abrufen (624) kann, z.B. indem die Speichersteuerungsanwendung die Leseanforderung an die Cloud-Computing-Instanz weiterleitet, die die angeforderten Daten in ihrem lokalen Speicher enthält. Für den Leser ist zu erkennen, dass durch das Abrufen (624) der Daten aus dem Blockspeicher des cloudbasierten Speichersystems (604) die Daten schneller abgerufen werden können, als wenn die Daten aus dem cloudbasierten Objektspeicher gelesen würden, auch wenn der cloudbasierte Objektspeicher eine Kopie der Daten enthält.
  • Für den Leser ist zu erkennen, dass in dem in 6 dargestellten Beispielverfahren der Blockspeicher des cloudbasierten Speichersystems (604) durch eine geringe Leselatenzzeit im Vergleich zum Objektspeicher des cloudbasierten Speichersystems gekennzeichnet ist. Daher kann das cloudbasierte Speichersystem (604) durch das Bereitstellen von Leseoperationen aus dem Blockspeicher statt aus dem Objektspeicher in der Lage sein, Leseoperationen unter Verwendung von Blockspeichern mit niedriger Latenzzeit bereitzustellen, während es weiterhin die Widerstandsfähigkeit bietet, die mit Objektspeicherlösungen von Cloud-Service-Anbietern verbunden ist. Darüber hinaus bietet die Blockspeicherung des cloudbasierten Speichersystems (604) möglicherweise eine relativ hohe Bandbreite. Die Blockspeicherung des cloudbasierten Speichersystems (604) kann auf verschiedene Weise implementiert werden, wie es den Lesern dieser Offenbarung in den Sinn kommt.
  • Zur weiteren Erläuterung ist in 7 ein Flussdiagramm dargestellt, das eine weitere Beispielmethode zur Handhabung von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (604). Die in 7 dargestellte Beispielmethode ähnelt der in 6 dargestellten Beispielmethode, da die in 7 dargestellte Beispielmethode auch das Empfangen (606) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (604), das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems (604) und das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems (604) umfasst.
  • Die in 7 dargestellte Beispielmethode beinhaltet auch das Erkennen (702), dass zumindest ein Teil des Blockspeichers des cloudbasierten Speichersystems nicht mehr verfügbar ist. Das Erkennen (702), dass zumindest ein Teil des Blockspeichers des cloudbasierten Speichersystems nicht mehr verfügbar ist, kann z.B. durch das Erkennen, dass eine oder mehrere der Cloud-Computing-Instanzen, die lokalen Speicher enthalten, nicht mehr verfügbar sind, durchgeführt werden, wie im Folgenden näher beschrieben wird.
  • Die in 7 dargestellte Beispielmethode umfasst auch das Ermitteln (704) von Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert wurden, der nicht mehr verfügbar ist. Das Ermitteln (704) von Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist, kann z.B. durch die Verwendung von Metadaten erfolgen, die eine bestimmte Kennung eines Datensegments (z.B. eine Sequenznummer, eine Adresse) dem Ort zuordnen, an dem die Daten gespeichert sind. Solche Metadaten oder separate Metadaten können die Daten auch auf eine oder mehrere Objektkennungen abbilden, die im Objektspeicher des cloudbasierten Speichersystems gespeicherte Objekte ermitteln, welche die Daten enthalten.
  • Die in 7 dargestellte Beispielmethode umfasst auch das Abrufen (706) der Daten aus dem Objektspeicher des cloudbasierten Speichersystems, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist. Das Abrufen (706) der Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der aus dem Objektspeicher des cloudbasierten Speichersystems nicht mehr verfügbar ist, kann z.B. durch das Verwenden der vorstehend beschriebenen Metadaten erfolgen, die die Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist, einem oder mehreren Objekten zuordnen, die im Objektspeicher des cloudbasierten Speichersystems gespeichert sind und die Daten enthalten. In einem solchen Beispiel kann das Abrufen (706) der Daten durch Lesen der Objekte erfolgen, die auf die Daten aus dem Objektspeicher des cloudbasierten Speichersystems abbilden.
  • Die in 7 dargestellte Beispielmethode beinhaltet auch das Speichern (708) der abgerufenen Daten im Blockspeicher des cloudbasierten Speichersystems. Das Speichern (708) der abgerufenen Daten im Blockspeicher des cloudbasierten Speichersystems kann z.B. durch das Erstellen von Ersatz-Cloud-Computing-Instanzen mit lokalem Speicher und das Speichern der Daten im lokalen Speicher einer oder mehrerer der Ersatz-Cloud-Computing-Instanzen erfolgen, wie oben ausführlicher beschrieben.
  • Die Leser werden verstehen, dass, obwohl sich die vorstehend beschriebenen Ausführungsformen auf Ausführungsformen beziehen, in denen Daten, die in dem nicht mehr verfügbaren Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert wurden, im Wesentlichen durch Abrufen der Daten aus der Objektspeicherschicht des cloudbasierten Speichersystems in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden, andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Da die Daten beispielsweise über den lokalen Speicher mehrerer Cloud-Computing-Instanzen unter Verwendung von Datenredundanzverfahren wie RAID verteilt sein können, können in einigen Ausführungsformen die verlorenen Daten durch einen RAID-Neuaufbau wieder in die Blockspeicherebene des cloudbasierten Speichersystems gebracht werden.
  • Zur weiteren Erläuterung ist in 8 ein Flussdiagramm dargestellt, das eine Beispielmethode zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (804). Obwohl es weniger detailliert dargestellt ist, kann das in 8 dargestellte cloudbasierte Speichersystem (804) ähnlich wie die vorstehend beschriebenen cloudbasierten Speichersysteme sein und von einer Cloud-Computing-Umgebung (802) unterstützt werden.
  • Die in 8 dargestellte Beispielmethode umfasst das Empfangen (806) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (804) durch das cloudbasierte Speichersystem (804). Die Anforderung zum Schreiben von Daten kann z.B. von einer in der Cloud-Computing-Umgebung ausgeführten Anwendung, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise empfangen werden. In einem solchen Beispiel kann die Anforderung die Daten enthalten, die in das cloudbasierte Speichersystem geschrieben werden sollen (804). In anderen Ausführungsformen kann die Anforderung, Daten in das cloudbasierte Speichersystem (804) zu schreiben, zur Boot-Zeit erfolgen, wenn das cloudbasierte Speichersystem (804) hochgefahren wird.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Deduplizieren (808) der Daten. Das Daten-Deduplizieren ist eine Datenreduktionstechnik zum Eliminieren von Dubletten von sich wiederholender Daten. Das cloudbasierte Speichersystem (804) kann die Daten deduplizieren (808), z.B. durch Vergleichen eines oder mehrerer Datenteile mit Daten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind, durch Vergleichen eines Fingerabdrucks für einen oder mehrere Datenteile mit Fingerabdrücken für Daten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind, oder auf andere Weise. In einem solchen Beispiel können doppelte Daten entfernt und durch einen Verweis auf eine bereits vorhandene Kopie der Daten ersetzt werden, die bereits im cloudbasierten Speichersystem (804) gespeichert ist.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Komprimieren (810) der Daten. Datenkomprimierung ist eine Datenreduktionstechnik, bei der Informationen mit weniger Bits als die ursprüngliche Darstellung kodiert werden. Das cloudbasierte Speichersystem (804) kann die Daten komprimieren (810), indem es einen oder mehrere Datenkomprimierungsalgorithmen auf die Daten anwendet, die zu diesem Zeitpunkt möglicherweise keine Daten enthalten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Verschlüsseln (812) der Daten. Bei der Datenverschlüsselung handelt es sich um eine Technik, bei der die Daten aus einem lesbaren Format in ein kodiertes Format umgewandelt werden, das erst nach dem Entschlüsseln der Daten gelesen oder verarbeitet werden kann. Das cloudbasierte Speichersystem (804) kann die Daten, die zu diesem Zeitpunkt möglicherweise bereits dedupliziert und komprimiert sind, mit einem Verschlüsselungsschlüssel verschlüsseln (812). Die Leser werden erkennen, dass, obwohl die in 8 dargestellte Ausführungsform das Deduplizieren (808) der Daten, das Komprimieren (810) der Daten und das Verschlüsseln (812) der Daten beinhaltet, andere Ausführungsformen existieren, in denen weniger dieser Schritte ausgeführt werden, und Ausführungsformen, in denen die gleiche Anzahl von Schritten oder weniger in einer anderen Reihenfolge ausgeführt werden.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Speichern (814) der Daten im Blockspeicher des cloudbasierten Speichersystems (804). Das Speichern (814) der Daten im Blockspeicher des cloudbasierten Speichersystems (804) kann z.B. durch Speichern (816) der Daten im lokalen Speicher (z.B. SSDs) einer oder mehrerer Cloud-Computing-Instanzen erfolgen, wie oben ausführlicher beschrieben. In einem solchen Beispiel verteilen sich die Daten über den lokalen Speicher mehrerer Cloud-Computing-Instanzen zusammen mit Paritätsdaten, um RAID- oder RAID-ähnliche Datenredundanz zu implementieren.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Speichern (818) der Daten im Objektspeicher des cloudbasierten Speichersystems (804). Das Speichern (818) der Daten in Objektspeichern des cloudbasierten Speichersystems kann das Erzeugen (820) eines oder mehrerer gleich großer Objekte umfassen, wobei jedes gleich große Objekt ein bestimmtes Segment der Daten enthält, wie oben ausführlicher beschrieben.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Empfangen (822) einer Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem durch das cloudbasierte Speichersystem (804). Die Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem (804) kann beispielsweise von einer Anwendung empfangen werden, die in der Cloud-Computing-Umgebung ausgeführt wird, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise. Die Anforderung kann z.B. eine logische Adresse der Daten enthalten, die aus dem cloudbasierten Speichersystem (804) gelesen werden sollen.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Abrufen (824) der Daten aus dem Blockspeicher des cloudbasierten Speichersystems (804). Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem (804) die Daten aus dem Blockspeicher des cloudbasierten Speichersystems (804) abrufen (824) kann, z.B. indem die Speichersteuerungsanwendung die Leseanforderung an die Cloud-Computing-Instanz weiterleitet, die die angeforderten Daten in ihrem lokalen Speicher enthält. Für den Leser ist zu erkennen, dass durch das Abrufen (824) der Daten aus dem Blockspeicher des cloudbasierten Speichersystems (804) die Daten schneller abgerufen werden können, als wenn die Daten aus dem cloudbasierten Objektspeicher gelesen würden, auch wenn der cloudbasierte Objektspeicher eine Kopie der Daten enthält.
  • Zur weiteren Erläuterung ist in 9 ein Flussdiagramm dargestellt, das eine weitere Beispielmethode zur Handhabung von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (804). Die in 9 dargestellte Beispielmethode ähnelt der in 8 dargestellten Beispielmethode, da die in 9 dargestellte Beispielmethode auch das Empfangen (806) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (804), das Speichern (814) der Daten im Blockspeicher des cloudbasierten Speichersystems (804) und das Speichern (818) der Daten im Objektspeicher des cloudbasierten Speichersystems (804) umfasst.
  • Die in 9 dargestellte Beispielmethode umfasst auch das Erkennen (902), dass zumindest ein Teil des Blockspeichers des cloudbasierten Speichersystems nicht mehr verfügbar ist. Das Erkennen (902), dass zumindest ein Teil des Blockspeichers des cloudbasierten Speichersystems nicht mehr verfügbar ist, kann z.B. durch das Erkennen, dass eine oder mehrere der Cloud-Computing-Instanzen, die lokalen Speicher enthalten, nicht mehr verfügbar sind, durchgeführt werden, wie im Folgenden näher beschrieben wird.
  • Die in 9 dargestellte Beispielmethode umfasst auch das Ermitteln (904) von Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert wurden, der nicht mehr verfügbar ist. Das Ermitteln (904) von Daten, die in dem nicht mehr verfügbaren Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, kann z.B. durch die Verwendung von Metadaten erfolgen, die eine bestimmte Kennung eines Datensegments (z.B. eine Sequenznummer, eine Adresse) dem Ort zuordnen, an dem die Daten gespeichert sind. Solche Metadaten oder separate Metadaten können die Daten auch auf eine oder mehrere Objektkennungen abbilden, die im Objektspeicher des cloudbasierten Speichersystems gespeicherte Objekte ermitteln, die die Daten enthalten.
  • Die in 9 dargestellte Beispielmethode umfasst auch das Abrufen (906) der Daten aus dem Objektspeicher des cloudbasierten Speichersystems, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist. Das Abrufen (906) der Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der aus dem Objektspeicher des cloudbasierten Speichersystems nicht mehr verfügbar war, kann z.B. durch die Verwendung der vorstehend beschriebenen Metadaten erfolgen, die die Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar war, einem oder mehreren Objekten zuordnen, die im Objektspeicher des cloudbasierten Speichersystems gespeichert sind und die Daten enthalten. In einem solchen Beispiel kann das Abrufen (906) der Daten durch Lesen der Objekte erfolgen, die auf die Daten aus dem Objektspeicher des cloudbasierten Speichersystems abbilden.
  • Die in 9 dargestellte Beispielmethode beinhaltet auch das Speichern (908) der abgerufenen Daten im Blockspeicher des cloudbasierten Speichersystems. Das Speichern (908) der abgerufenen Daten im Blockspeicher des cloudbasierten Speichersystems kann z.B. durch das Bilden von Ersatz-Cloud-Computing-Instanzen mit lokalem Speicher und das Speichern der Daten im lokalen Speicher einer oder mehrerer der Ersatz-Cloud-Computing-Instanzen erfolgen, wie oben ausführlicher beschrieben.
  • Zur weiteren Erläuterung ist in 10 ein Flussdiagramm dargestellt, das ein zusätzliches Beispielverfahren zur Abwicklung von E/A-Operationen in einem cloudbasierten Speichersystem (604) zeigt. Das in 10 dargestellte Beispielverfahren ähnelt dem in vielen der obigen Figuren dargestellten Beispielverfahren, da das in 10 dargestellte Beispielverfahren auch das Empfangen (606) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (604), das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems (604) und das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems (604) umfasst.
  • In dem in 10 dargestellten Beispielverfahren kann das Empfangen (606) der Anforderung, Daten in das cloudbasierte Speichersystem zu schreiben, das Empfangen (1002) der Anforderung, Daten in den cloudbasierten Speicher zu schreiben, durch eine Speichersteuerungsanwendung umfassen, die in einer Cloud-Computing-Instanz ausgeführt wird. Die Speichersteuerungsanwendung, die in einer Cloud-Computing-Instanz ausgeführt wird, kann den oben beschriebenen Speichersteuerungsanwendungen ähnlich sein und kann zum Beispiel in einer EC2-Instanz ausgeführt werden, wie oben ausführlicher beschrieben. Tatsächlich kann das cloudbasierte Speichersystem (604) mehrere EC2-Instanzen oder ähnliche Cloud-Computing-Instanzen umfassen, wobei mehrere Cloud-Computing-Instanzen jeweils die Speichersteuerungsanwendung ausführen.
  • In dem in 10 dargestellten Beispielverfahren kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems das Ausgeben (1004) einer Anweisung zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher durch die in der Cloud-Computing-Instanz ausgeführte Speichersteuerungsanwendung umfassen. Die eine oder mehreren Cloud-Computing-Instanzen mit lokalem Speicher können den oben beschriebenen Cloud-Computing-Instanzen mit lokalem Speicher ähnlich sein. In dem in 10 dargestellten Beispielverfahren kann die in der Cloud-Computing-Instanz ausgeführte Speichersteuerungsanwendung für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher gekoppelt sein. Auf diese Weise kann die in der Cloud-Computing-Instanz ausgeführte Speichersteuerungsanwendung die mehreren Cloud-Computing-Instanzen mit lokalem Speicher als einzelne Speichergeräte behandeln, so dass die in der Cloud-Computing-Instanz ausgeführte Speichersteuerungsanwendung eine Anweisung zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher ausgeben kann (1004), indem sie denselben Satz von Befehlen ausgibt, den die Speichersteuerungsanwendung beim Schreiben von Daten in ein angeschlossenes Speichergerät ausgeben würde. Leser werden verstehen, dass, da die in der Cloud-Computing-Instanz ausgeführte Speichersteuerungsanwendung für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher verbunden sein kann, der Storage-Array-Controller mit mehreren Quellen von Blockspeicher verbunden sein kann, wobei der Storage-Array-Controller nur mit einem einzigen EBS-Datenträger verbunden sein kann, wenn der Storage-Array-Controller für die Verwendung von EBS als Blockspeicher konfiguriert ist.
  • In dem in 10 dargestellten Beispielverfahren können eine oder mehrere der mehreren Cloud-Computing-Instanzen mit lokalem Speicher zur Datenkommunikation mit mehreren Cloud-Computing-Instanzen gekoppelt werden, die jeweils die Speichersteuerungsanwendung ausführen. Der Leser wird verstehen, dass in einigen Ausführungsformen, da es eine Vielzahl von Cloud-Computing-Instanzen gibt, die jeweils die Speichersteuerungsanwendung ausführen, eine Speichersteuerungsanwendung, die auf einer ersten Cloud-Computing-Instanz ausgeführt wird, als primäre Steuerung dienen kann, während zusätzliche Speichersteuerungsanwendungen, die auf zusätzlichen Cloud-Computing-Instanzen ausgeführt werden, als sekundäre Steuerungen dienen können, die beim Auftreten eines Ereignisses (z. B. Ausfall der primären Steuerung) für die primäre Steuerung einspringen können.
  • Zur weiteren Erläuterung ist in 11 ein Flussdiagramm dargestellt, das ein zusätzliches Beispielverfahren zur Abwicklung von E/A-Operationen in einem cloudbasierten Speichersystem (604) zeigt. Das in 11 dargestellte Beispielverfahren ähnelt dem in vielen der obigen Figuren dargestellten Beispielverfahren, da das in 11 dargestellte Beispielverfahren auch das Empfangen (606) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (604), das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems (604) und das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems (604) umfasst.
  • In dem in 11 dargestellten Beispielverfahren kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems das Schreiben (1102) der Daten in einen oder mehrere Blöcke des Blockspeichers unter Verwendung eines Protokolls auf Blockebene umfassen. In dem in 11 dargestellten Beispielverfahren kann der Blockspeicher als ein oder mehrere Blockspeichergeräte, wie z. B. NAND-Flash-Speicher, ausgeführt werden, in denen Daten in Blöcken gespeichert werden, die jeweils zum Speichern von Daten einer maximalen Größe (d. h. einer Blockgröße) verwendet werden können. Daten können in solche Speichergeräte geschrieben werden (1102), indem ein Protokoll auf Blockebene verwendet wird, wie z. B. iSCSI, Fibre Channel und FCoE (Fibre Channel over Ethernet) und so weiter. Der Leser wird verstehen, dass durch das Schreiben (1102) der Daten in einen oder mehrere Blöcke des Blockspeichers unter Verwendung eines Protokolls auf Blockebene die Daten, die in den Blockspeicher des cloudbasierten Speichersystems geschrieben werden, daher in Blöcken gespeichert werden.
  • In dem in 11 dargestellten Beispielverfahren kann das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems das Schreiben (1104) der Daten in ein oder mehrere Objekte im Objektspeicher unter Verwendung eines Protokolls auf Objektebene umfassen. In dem in 11 dargestellten Beispielverfahren kann der Objektspeicher so konfiguriert sein, dass er Daten als Objekte verwaltet, im Gegensatz zu anderen Speicherarchitekturen wie Dateisystemen, die Daten als eine Dateihierarchie verwalten, und Blockspeichern, die Daten als Blöcke verwalten. Ein solcher Objektspeicher kann auf der Geräteebene (Objektspeichergerät), der Systemebene, der Schnittstellenebene oder auf eine andere Weise implementiert werden. Daten können in den Objektspeicher geschrieben werden (1104), indem ein Protokoll auf Objektebene verwendet wird, wie z. B. der SCSI-Befehlssatz für Objektspeichergeräte, RESTful-/HTTP-Protokolle, AWS S3 APIs, die Cloud Data Management Interface für den Zugriff auf Cloud-Speicher und andere. Der Leser wird verstehen, dass durch das Schreiben (1104) eines oder mehrerer Objekte in den Objektspeicher unter Verwendung eines Protokolls auf Objektebene die Daten, die in den Objektspeicher des cloudbasierten Speichersystems geschrieben werden, daher in Objekten gespeichert werden - und nicht in Blöcken, wie es im vorangegangenen Absatz der Fall war.
  • In dem in 11 dargestellten Beispielverfahren können für jeden Datenblock die in einem bestimmten Block enthaltenen Daten in ein eindeutiges Objekt geschrieben werden. Der Leser wird verstehen, dass jedes Objekt, das in den Objektspeicher geschrieben wird (1104), sowohl die Daten selbst als auch die zugehörigen Metadaten enthalten kann, und dass jedes Objekt mit einer weltweit eindeutigen Kennung verknüpft werden kann - anstelle eines Dateinamens und eines Dateipfads, einer Blocknummer und so weiter. So können die in einem bestimmten Block enthaltenen Daten in ein eindeutiges Objekt in dem Sinne geschrieben werden, dass das eindeutige Objekt die Daten selbst, die mit den Daten verbundenen Metadaten und eine weltweit eindeutigen Kennung enthält. In solchen Ausführungsformen kann das cloudbasierte Speichersystem daher eine Zuordnung zwischen jedem Datenblock, der im Blockspeicher des cloudbasierten Speichersystems gespeichert ist, und jedem Objekt, das im Objektspeicher des cloudbasierten Speichersystems gespeichert ist, vornehmen. In einigen Ausführungsformen kann jedes Objekt die Daten enthalten, die in mehreren Blöcken enthalten sind, aber die Daten, die in mehreren Blöcken enthalten sind, müssen nur in einem einzigen Objekt gespeichert werden.
  • Zur weiteren Erläuterung zeigt 12 ein Beispiel für eine virtuelle Speichersystemarchitektur 1200 in Übereinstimmung mit einigen Ausführungsformen. Die Architektur des virtuellen Speichersystems kann ähnliche cloudbasierte Datenverarbeitungsressourcen enthalten wie die oben unter Bezugnahme auf die 4-11 beschriebenen cloudbasierten Speichersysteme.
  • Wie oben unter Bezugnahme auf die 1A-3E beschrieben, kann ein physisches Speichersystem in einigen Ausführungsformen einen oder mehrere Controller enthalten, die Speicherdienste für einen oder mehrere Hosts bereitstellen, wobei das physische Speichersystem langlebige Speichergeräte, wie Solid-State-Laufwerke oder Festplatten, und auch einige schnelle dauerhafte Speicher, wie NVRAM, enthält. In einigen Beispielen kann der schnelle dauerhafte Speicher für Staging oder Transaktions-Commits oder zur Beschleunigung der Bestätigung der Dauerhaftigkeit von Operationen verwendet werden, um die Latenzzeit für Host-Anforderungen zu verringern.
  • Im Allgemeinen wird ein schneller dauerhafter Speicher häufig für Intent-Logging, für schnelle Durchführung oder für die schnelle Sicherstellung der Konsistenz von Transaktionen verwendet, wobei solche (und ähnliche) Zwecke hier als Staging-Speicher bezeichnet werden. Im Allgemeinen können sowohl physische als auch virtuelle Speichersysteme einen oder mehrere Controller und spezialisierte Speicherkomponenten aufweisen, wie z. B. im Fall von physischen Speichergeräten spezialisierte Speichergeräte. Darüber hinaus kann in einigen Fällen in physischen und virtuellen Speichersystemen der Staging-Speicher auf verschiedene Weise organisiert und reorganisiert werden, wie in den später beschriebenen Beispielen. In einigen Beispielen kann es unabhängig von der Art und Weise, wie Speicherkomponenten oder Speichergeräte konstruiert, erzeugt oder organisiert werden, einen Satz von Speichersystemlogik geben, der ausgeführt wird, um einen Satz von angekündigten Speicherdiensten zu implementieren, und der Massendaten für unbestimmte Zeit speichert, und es kann auch eine gewisse Menge an Staging-Speicher vorhanden sein.
  • In einigen Beispielen kann die Steuerungslogik, die ein physisches Speichersystem wie die physischen Speichersysteme 1A-3E betreibt, in einem virtuellen Speichersystem ausgeführt werden, indem geeignete virtuelle Komponenten bereitgestellt werden, die einzeln oder insgesamt als Ersatz für Hardwarekomponenten in einem physischen Speichersystem dienen, wobei die virtuellen Komponenten so konfiguriert sind, dass sie die Steuerungslogik betreiben und mit anderen virtuellen Komponenten interagieren, die so konfiguriert sind, dass sie andere physische Komponenten als die Steuerung ersetzen.
  • In Fortsetzung dieses Beispiels können virtuelle Komponenten, die eine Steuerungslogik ausführen, Hochverfügbarkeitsmodelle implementieren und/oder anpassen, um ein virtuelles Speichersystem im Falle von Ausfällen in Betrieb zu halten. Ein weiteres Beispiel: Virtuelle Komponenten, die Steuerungslogik ausführen, können Protokolle implementieren, um zu verhindern, dass das virtuelle Speichersystem bei vorübergehenden Ausfällen Daten verliert, die über das hinausgehen, was das virtuelle Speichersystem bei laufendem Betrieb tolerieren kann.
  • In einigen Implementierungen und insbesondere im Hinblick auf die verschiedenen Architekturen virtueller Speichersysteme, die unter Bezugnahme auf die 12-17 beschrieben werden, kann eine Computerumgebung eine Reihe verfügbarer, angekündigter Konstrukte enthalten, die typisch für cloudbasierte Infrastrukturen als Dienstplattformen sind, wie beispielsweise Cloud-Infrastrukturen, die von Amazon Web Services™, Microsoft Azure™ und/oder Google Cloud Platform™ bereitgestellt werden. In einigen Implementierungen können Beispielkonstrukte und Konstruktmerkmale innerhalb solcher Cloud-Plattformen umfassen:
    • • Recheninstanzen, wobei eine Recheninstanz als virtuelle Maschine ausgeführt oder betrieben werden kann, die physischen Host-Servern flexibel zugewiesen wird;
    • • Aufteilung der Rechenressourcen in verschiedene geografische Regionen, wobei die Rechenressourcen auf verschiedene geografische Regionen verteilt oder aufgeteilt werden können, so dass Nutzer in derselben Region oder derselben Zone wie eine bestimmte Cloud-Computing-Ressource im Vergleich zu Nutzern in einer anderen Region oder einer anderen Zone als die Rechenressourcen einen schnelleren und/oder höheren Bandbreitenzugang erhalten können;
    • • Unterteilung von Ressourcen innerhalb geografischer Regionen in „Verfügbarkeitszonen“ mit separater Verfügbarkeit und Überlebensfähigkeit bei großflächigen Ausfällen von Rechenzentren, Netzwerkausfällen, Ausfällen des Stromnetzes, Verwaltungsfehlern und so weiter. Darüber hinaus haben in einigen Beispielen Ressourcen innerhalb einer bestimmten Cloud-Plattform, die sich in getrennten Verfügbarkeitszonen innerhalb derselben geografischen Region befinden, im Allgemeinen eine recht hohe Bandbreite und eine relativ geringe Latenzzeit untereinander;
    • • Lokaler Instanzspeicher, z. B. Festplatten, Solid-State-Laufwerke, Rack-Local Storage, der einer Recheninstanz privaten Speicher zur Verfügung stellen kann. Weitere Beispiele für lokale Instanzspeicher sind oben mit Bezug auf die 4-11 beschrieben;
    • • Blockspeicher, die relativ schnell und langlebig sind und mit einer virtuellen Maschine verbunden sein können, deren Zugriff jedoch migriert werden kann. Einige Beispiele sind EBS (Elastic Block Store™) in AWS, Managed Disks in Microsoft Azure™ und Compute Engine Persistent Disks in Google Cloud Platform™. EBS in AWS wird innerhalb einer einzigen Verfügbarkeitszone betrieben, ist aber ansonsten einigermaßen zuverlässig und verfügbar und für die langfristige Nutzung durch Recheninstanzen vorgesehen, auch wenn diese Recheninstanzen zwischen physischen Systemen und Racks wechseln können;
    • • Objektspeicher wie Amazon S3™ oder ein Objektspeicher, der ein von S3 abgeleitetes, mit S3 kompatibles Protokoll verwendet oder einige ähnliche Eigenschaften wie S3 aufweist (z. B. Azure Blob Storage™ von Microsoft). Im Allgemeinen sind Objektspeicher sehr langlebig und überstehen weit verbreitete Ausfälle durch die Replikation zwischen Verfügbarkeitszonen und über geografische Grenzen hinweg;
    • • Cloud-Plattformen, die eine Vielzahl von Objektspeichern oder anderen Speichertypen unterstützen können, die sich in ihren Kombinationen aus Kapazitätspreisen, Zugriffspreisen, erwarteter Latenz, erwartetem Durchsatz, Verfügbarkeits- oder Haltbarkeitsgarantien unterscheiden können. In AWS™ beispielsweise unterscheiden sich die S3-Speicherklassen Standard und Infrequent Access (hier als Standard- und Schreibspeicherklassen bezeichnet) in der Verfügbarkeit (aber nicht in der Dauerhaftigkeit) sowie in den Kapazitäts- und Zugriffspreisen (wobei die Speicherebene mit seltenem Zugriff in Bezug auf die Kapazität preiswerter, in Bezug auf den Abruf jedoch teurer ist und die erwartete Verfügbarkeit 1/10 beträgt). S3 mit seltenem Zugriff unterstützt auch eine noch kostengünstigere Variante, die gegenüber dem vollständigen Verlust einer Verfügbarkeitszone nicht tolerant ist und hier als dauerhafter Speicher mit nur einer Verfügbarkeitszone bezeichnet wird. AWS unterstützt darüber hinaus Archivierungsebenen wie Glacier™ und Deep Glacier™, die die niedrigsten Kapazitätspreise bieten, aber eine sehr hohe Zugriffslatenz in der Größenordnung von Minuten bis Stunden für Glacier und bis zu 12 Stunden mit Einschränkungen bei der Abrufhäufigkeit für Deep Glacier. Glacier und Deep Glacier werden hier als Beispiele für Archiv- und Deep-Archive-Speicherklassen angeführt;
    • • Datenbanken, und zwar oft mehrere verschiedene Arten von Datenbanken, darunter hochskalierbare Key-Value-Store-Datenbanken mit angemessener Haltbarkeit (ähnlich wie schnelle, langlebige Blockspeicher) und praktische Sätze atomarer Aktualisierungsprimitive. Einige Beispiele für langlebige Key-Value-Datenbanken sind AWS DynamoDB™, Google Cloud Platform Big Table™ und/oder CosmoDB™ von Microsoft Azure; und
    • • Dynamische Funktionen, wie z. B. Code Snippets, die so konfiguriert werden können, dass sie als Reaktion auf Ereignisse oder Aktionen, die mit der Konfiguration verbunden sind, dynamisch innerhalb der Cloud-Plattform-Infrastruktur ausgeführt werden. Bei AWS werden diese dynamischen Funktionen beispielsweise als AWS Lambdas™ bezeichnet, während Microsoft Azure und Google Cloud Platform solche dynamischen Funktionen als Azure Functions™ bzw. Cloud Functions™ bezeichnen.
  • In einigen Implementierungen ist der lokale Instanzspeicher nicht für eine langfristige Nutzung vorgesehen, und in einigen Beispielen wird der lokale Instanzspeicher möglicherweise nicht migriert, wenn virtuelle Maschinen zwischen Hostsystemen migrieren. In einigen Fällen kann lokaler Instanzspeicher auch nicht von virtuellen Maschinen gemeinsam genutzt werden und kann aufgrund seiner lokalen Beschaffenheit nur wenige Haltbarkeitsgarantien bieten (er übersteht wahrscheinlich lokale Strom- und Softwarefehler, aber nicht notwendigerweise weitreichendere Ausfälle). Darüber hinaus kann in einigen Beispielen lokaler Instanzspeicher im Vergleich zu Objektspeicher relativ kostengünstig sein und nicht auf der Grundlage von E/As abgerechnet werden, wie dies bei den dauerhafteren Blockspeicherdiensten oft der Fall ist.
  • In einigen Implementierungen sind Objekte in Objektspeichern leicht zu erstellen (z. B. eine PUT-Operation eines Webdienstes, um ein Objekt mit einem Namen in einem mit einem Konto verbundenen Bucket zu erstellen) und abzurufen (z. B. eine GET-Operation eines Webdienstes), und das parallele Erstellen und Abrufen einer ausreichenden Anzahl von Objekten kann eine enorme Bandbreite ergeben. In einigen Fällen sind die Latenzzeiten jedoch im Allgemeinen sehr schlecht, und Änderungen oder der Austausch von Objekten können in unvorhersehbarer Zeit abgeschlossen werden, oder es kann schwierig sein, festzustellen, wann ein Objekt in der gesamten Cloud-Plattform-Infrastruktur vollständig dauerhaft und konsistent verfügbar ist. Darüber hinaus ist die Verfügbarkeit von Objektspeichern im Gegensatz zur Dauerhaftigkeit oft gering, was bei vielen Diensten in Cloud-Umgebungen ein Problem darstellt.
  • In einigen Implementierungen kann ein virtuelles Speichersystem eine oder mehrere der folgenden virtuellen Komponenten und Konzepte für den Aufbau, das Bereitstellen und/oder die Definition eines virtuellen Speichersystems auf einer Cloud-Plattform umfassen:
    • • Virtueller Controller, wie z. B. ein virtueller Speichersystem-Controller, der auf einer Recheninstanz innerhalb der Infrastruktur einer Cloud-Plattform oder einer Cloud-Computing-Umgebung läuft. In einigen Beispielen kann ein virtueller Controller auf virtuellen Maschinen, in Containern oder auf Bare Metal Servern laufen;
    • • Virtuelle Laufwerke, wobei ein virtuelles Laufwerk ein spezifisches Speicherobjekt sein kann, das einem Controller eines virtuellen Speichersystems bereitgestellt wird, um einen Datensatz zu repräsentieren; ein virtuelles Laufwerk kann beispielsweise ein Datenträger oder ein emuliertes Festplattenlaufwerk sein, das innerhalb des virtuellen Speichersystems analog zu einem physischen Speichersystem als „Speichergerät“ dienen kann. Darüber hinaus können virtuelle Laufwerke den Controllern des virtuellen Speichersystems durch „virtuelle Laufwerksserver“ bereitgestellt werden;
    • • Virtuelle Laufwerksserver können durch Recheninstanzen implementiert werden, wobei virtuelle Laufwerksserver Speicher, wie z. B. virtuelle Laufwerke, aus verfügbaren Komponenten bereitstellen können, die von einer Cloud-Plattform bereitgestellt werden, wie z. B. verschiedene Arten lokaler Speicheroptionen, und wobei virtuelle Laufwerksserver eine Logik implementieren, die virtuelle Laufwerke einem oder mehreren Controllern für virtuelle Speichersysteme bereitstellt, oder in einigen Fällen virtuelle Laufwerke einem oder mehreren virtuellen Speichersystemen bereitstellt.
    • • Staging-Speicher, der schnell und langlebig oder zumindest einigermaßen schnell und einigermaßen langlebig sein kann, wobei „einigermaßen langlebig“ nach einer Haltbarkeitsmetrik und „einigermaßen schnell“ nach einer Leistungsmetrik, wie z. B. IOPS, angegeben werden kann;
    • • Datensatz eines virtuellen Speichersystems, bei dem es sich um eine definierte Sammlung von Daten und Metadaten handeln kann, die einen kohärent verwalteten Inhalt darstellen, der eine Sammlung von Dateisystemen, Datenträgern, Objekten und anderen ähnlichen adressierbaren Speicherbereichen repräsentiert;
    • • Objektspeicher, der dem Staging-Speicher einen dauerhaften Objektspeicher im Backend zur Verfügung stellt. Wie in 12 dargestellt, kann der cloudbasierte Objektspeicher 432 von den virtuellen Laufwerken 1210-1216 verwaltet werden;
    • • Segmente, die als mittelgroße Datenblöcke angegeben werden können. So kann ein Segment beispielsweise in einem Bereich von 1 MB bis 64 MB definiert werden, wobei ein Segment eine Kombination aus Daten und Metadaten enthalten kann; und
    • • Virtuelle Speichersystemlogik, bei der es sich um eine Reihe von Algorithmen handeln kann, die zumindest auf einem oder mehreren virtuellen Controllern 408, 410 und in einigen Fällen auch auf einem oder mehreren virtuellen Laufwerken 1210-1216 ausgeführt werden.
  • In einigen Implementierungen kann eine virtuelle Steuerung E/A-Operationen und/oder Konfigurationsanforderungen von Client-Hosts 1260, 1262 (möglicherweise über zwischengeschaltete Server, nicht abgebildet) oder von Verwaltungsschnittstellen oder -tools entgegennehmen und dann sicherstellen, dass E/A-Anforderungen und andere Operationen bis zum Abschluss ausgeführt werden.
  • In einigen Beispielen können virtuelle Controller Dateisysteme, blockbasierte Datenträger, Objektspeicher und/oder bestimmte Arten von Massenspeicherdatenbanken oder Schlüssel/Wertespeichern darstellen und Datendienste wie Snapshots, Replikation, Migrationsdienste, Bereitstellung, Host-Konnektivitätsmanagement, Deduplizierung, Komprimierung, Verschlüsselung, sichere Freigabe und andere derartige Speichersystemdienste bereitstellen.
  • In der in 12 dargestellten Beispielarchitektur des virtuellen Speichersystems 1200 umfasst ein virtuelles Speichersystem 1200 zwei virtuelle Controller, wobei ein virtueller Controller in einer Zeitzone, Zeitzone 1251, und ein anderer virtueller Controller in einer anderen Zeitzone, Zeitzone 1252, läuft. In diesem Beispiel werden die beiden virtuellen Controller als Speichersteuerungsanwendung 408, die in der Cloud-Computing-Instanz 404 läuft, und als Speichersteuerungsanwendung 410, die in der Cloud-Computing-Instanz 406 läuft, dargestellt.
  • In einigen Implementierungen kann ein virtueller Laufwerksserver, wie oben beschrieben, für einen Host etwas Ähnliches wie ein physisches Speichergerät darstellen, z. B. ein Disk Drive oder ein Solid-State-Laufwerk, wobei das physische Speichergerät im Kontext eines physischen Speichersystems betrieben wird.
  • Während jedoch in diesem Beispiel das virtuelle Laufwerk ähnlich wie ein physisches Speichergerät für einen Host dargestellt wird, wird das virtuelle Laufwerk durch eine virtuelle Speichersystemarchitektur implementiert - wobei die virtuelle Speichersystemarchitektur eine der in den 4-16 dargestellten sein kann. Im Gegensatz zu virtuellen Laufwerken, die als Analogon ein physisches Speichergerät haben, wie es in den Beispielarchitekturen für virtuelle Speichersysteme implementiert ist, kann ein virtueller Laufwerksserver kein Analogon im Kontext eines physischen Speichersystems haben. Insbesondere kann ein virtueller Laufwerksserver in einigen Beispielen eine Logik implementieren, die über das hinausgeht, was für Speichergeräte in physischen Speichersystemen typisch ist, und kann sich in einigen Fällen auf atypische Speichersystemprotokolle zwischen dem virtuellen Laufwerksserver und virtuellen Speichersystemcontrollern stützen, die kein Analogon in physischen Speichersystemen haben. Vom Konzept her kann ein virtueller Laufwerksserver jedoch Ähnlichkeiten mit einem skalierbaren Shared-Nothing- oder Software-definierten Speichersystem aufweisen.
  • In einigen Implementierungen (siehe 12) können die jeweiligen virtuellen Laufwerksserver 1210-1216 entsprechende Softwareanwendungen oder Daemons 1230-1236 implementieren, um virtuelle Laufwerke bereitzustellen, deren Funktionalität ähnlich oder sogar identisch mit der eines physischen Speichergeräts ist - was eine einfachere Portierung von Speichersystemsoftware oder Anwendungen ermöglicht, die für physische Speichersysteme entwickelt wurden. Sie könnten beispielsweise ein standardmäßiges SAS-, SCSI- oder NVMe-Protokoll implementieren oder diese Protokolle mit geringfügigen oder bedeutenden nicht standardmäßigen Erweiterungen implementieren.
  • In einigen Implementierungen (siehe 12) kann der Staging-Speicher durch ein oder mehrere virtuelle Laufwerke 1210-1216 implementiert werden, wobei das eine oder die mehreren virtuellen Laufwerke 1210-1216 Daten in den jeweiligen Blockspeicher-Datenträgern 1240-1246 und im lokalen Speicher 1220-1226 speichern. In diesem Beispiel können die Blockspeicher-Datenträger AWS EBS-Datenträger sein, die, wie in 12 dargestellt, nacheinander an zwei oder mehr andere virtuelle Laufwerke angeschlossen werden können. Wie in 12 dargestellt, ist der Blockspeicher-Datenträger 1240 an das virtuelle Laufwerk 1212 angeschlossen, der Blockspeicher-Datenträger 1242 an das virtuelle Laufwerk 1214 und so weiter.
  • In einigen Implementierungen kann ein Segment so spezifiziert werden, dass es Teil eines löschungscodierten Satzes ist, z. B. auf der Grundlage einer RAID-ähnlichen Implementierung, bei der ein Segment berechnete Paritätsinhalte auf der Grundlage von Löschcodes (z. B. RAID-5 P- und Q-Daten) speichern kann, die aus dem Inhalt anderer Segmente berechnet wurden. In einigen Beispielen kann der Inhalt von Segmenten einmal erstellt werden, und nachdem das Segment erstellt und ausgefüllt wurde, wird es nicht mehr verändert, bis das Segment verworfen oder gelöscht wird.
  • In einigen Implementierungen kann die Logik des virtuellen Speichersystems auch von anderen Komponenten des virtuellen Speichersystems ausgeführt werden, z. B. von dynamischen Funktionen. Die virtuelle Speichersystemlogik kann eine vollständige Implementierung der vom virtuellen Speichersystem 1200 beworbenen Fähigkeiten und Dienste bereitstellen, wobei das virtuelle Speichersystem 1200 eine oder mehrere verfügbare Cloud-Plattformkomponenten, wie die oben beschriebenen, verwendet, um diese Dienste zuverlässig und mit angemessener Haltbarkeit zu implementieren.
  • Während das in 12 dargestellte Beispiel eines virtuellen Speichersystems 1200 zwei virtuelle Controller umfasst, können andere virtuelle Speichersystemarchitekturen im Allgemeinen mehr oder weniger virtuelle Controller aufweisen, wie in den 13-16 dargestellt. Darüber hinaus kann ein virtuelles Speichersystem in einigen Implementierungen, ähnlich wie die in den 1A-4 beschriebenen physischen Speichersysteme, einen aktiven virtuellen Controller und einen oder mehrere passive virtuelle Controller umfassen.
  • Zur weiteren Erläuterung zeigt 13 ein Beispiel für eine virtuelle Speichersystemarchitektur 1300 in Übereinstimmung mit einigen Ausführungsformen. Die Architektur des virtuellen Speichersystems kann ähnliche cloudbasierte Datenverarbeitungsressourcen enthalten wie die oben unter Bezugnahme auf die 4-12 beschriebenen cloudbasierten Speichersysteme.
  • In dieser Implementierung kann ein virtuelles Speichersystem die Logik des virtuellen Speichersystems, wie oben unter Bezugnahme auf 12 beschrieben, gleichzeitig auf mehreren virtuellen Controllern ausführen, beispielsweise durch Aufteilung eines Datensatzes oder durch sorgfältige Implementierung gleichzeitiger verteilter Algorithmen. In diesem Beispiel sind die mehreren virtuellen Steuerungen 1320, 408, 410, 1322 in den jeweiligen Cloud-Computing-Instanzen 1310, 404, 406, 1312 implementiert.
  • Wie oben unter Bezugnahme auf 12 beschrieben, kann in einigen Implementierungen eine bestimmte Gruppe von Hosts bevorzugt oder ausschließlich zu einer Untergruppe von virtuellen Controllern für einen Datensatz geleitet werden, während eine bestimmte andere Gruppe von Hosts bevorzugt oder ausschließlich zu einer anderen Untergruppe von Controllern für denselben Datensatz geleitet werden kann. Beispielsweise könnte SCSI ALUA (Asymmetric Logical Unit Access) oder NVMe ANA (Asymmetric Namespace Access) oder ein ähnlicher Mechanismus verwendet werden, um bevorzugte (manchmal als „optimiert“ bezeichnete) Pfadpräferenzen von einem Host zu einer Untergruppe von Controllern einzurichten, bei denen der Datenverkehr im Allgemeinen an die bevorzugte Untergruppe von Controllern geleitet wird, aber bei fehlerhaften Anfragen oder Netzwerkausfällen oder Ausfällen von Controllern virtueller Speichersysteme dieser Datenverkehr an eine andere Untergruppe von Controllern virtueller Speichersysteme umgeleitet werden könnte. Alternativ könnten SCSI/NVMe-Volumenanzeigen oder Netzwerkbeschränkungen oder ein ähnlicher alternativer Mechanismus den gesamten Datenverkehr von einer bestimmten Gruppe von Hosts ausschließlich zu einer Untergruppe von Controllern oder den Datenverkehr von einer anderen bestimmten Gruppe von Hosts zu einer anderen Untergruppe von Controllern leiten.
  • Wie in 13 dargestellt, kann ein virtuelles Speichersystem E/A-Anforderungen vom Host 1260 bevorzugt oder ausschließlich an die virtuellen Speicher-Controller 1320 und 408 richten, wobei die Speicher-Controller 410 und vielleicht 1322 für den Host 1260 zur Verwendung bei fehlerhaften Anforderungen verfügbar sind, und kann E/A-Anforderungen vom Host 1262 bevorzugt oder ausschließlich an die virtuellen Speicher-Controller 410 und 1322 richten, wobei die Speicher-Controller 408 und vielleicht 1320 für den Host 12622 zur Verwendung bei fehlerhaften Anforderungen verfügbar sind. In einigen Implementierungen kann ein Host angewiesen werden, E/A-Anforderungen an einen oder mehrere virtuelle Speicher-Controller innerhalb derselben Verfügbarkeitszone wie der Host zu stellen, wobei virtuelle Speicher-Controller in einer anderen Verfügbarkeitszone als der Host für die Verwendung im Falle von Fehlern verfügbar sind.
  • Zur weiteren Erläuterung zeigt 14 ein Beispiel für eine virtuelle Speichersystemarchitektur 1400 in Übereinstimmung mit einigen Ausführungsformen. Die Architektur des virtuellen Speichersystems kann ähnliche cloudbasierte Datenverarbeitungsressourcen enthalten wie die oben unter Bezugnahme auf die 4-13 beschriebenen cloudbasierten Speichersysteme.
  • In einigen Implementierungen können die Grenzen zwischen virtuellen Controllern und virtuellen Laufwerksservern, die virtuelle Laufwerke hosten, flexibel sein. Darüber hinaus können in einigen Beispielen die Grenzen zwischen virtuellen Komponenten für die Client-Hosts 1450a-1450p nicht sichtbar sein, und die Client-Hosts 1450a-1450p erkennen möglicherweise keinen Unterschied zwischen zwei unterschiedlich aufgebauten virtuellen Speichersystemen, die denselben Satz von Speichersystemdiensten anbieten.
  • Beispielsweise können virtuelle Controller und virtuelle Laufwerke zu einer einzigen virtuellen Einheit zusammengeführt werden, die ähnliche Funktionen wie ein herkömmliches, Blade-basiertes Scale-out-Speichersystem bieten kann. In diesem Beispiel umfasst das virtuelle Speichersystem 1400 n virtuelle Blades, virtuelle Blades 1402a-1402n, wobei jedes virtuelle Blade 1402a-1402n einen virtuellen Controller 1404a-1404n und einen lokalen Speicher 1220-1226, 1240-1246 umfassen kann, wobei die Speicherfunktion jedoch einen von der Plattform bereitgestellten Objektspeicher nutzen kann, wie dies bei den zuvor beschriebenen virtuellen Laufwerk-Implementierungen der Fall sein könnte.
  • Da virtuelle Laufwerksserver allgemeine Berechnungen unterstützen, unterstützt diese Architektur des virtuellen Speichersystems in einigen Fällen die Migration von Funktionen zwischen virtuellen Speichersystem-Controllern und virtuellen Laufwerksservern. In anderen Fällen unterstützt diese Architektur des virtuellen Speichersystems andere Arten von Optimierungen, wie die oben beschriebenen Optimierungen, die im Staging-Speicher durchgeführt werden können. Darüber hinaus können virtuelle Blades mit unterschiedlicher Verarbeitungsleistung konfiguriert werden, wobei die Leistungsspezifikationen eines bestimmten virtuellen Blades oder mehrerer virtueller Blades auf den zu erwartenden Optimierungen beruhen können.
  • Zur weiteren Erläuterung zeigt 15 ein Beispiel für eine virtuelle Speichersystemarchitektur 1500 in Übereinstimmung mit einigen Ausführungsformen. Die Architektur des virtuellen Speichersystems kann ähnliche cloudbasierte Datenverarbeitungsressourcen enthalten wie die oben unter Bezugnahme auf die 4-14 beschriebenen cloudbasierten Speichersysteme.
  • In dieser Implementierung kann ein virtuelles Speichersystem 1500 an verschiedene Verfügbarkeitszonen angepasst werden, wobei ein solches virtuelles Speichersystem 1500 eine speicherübergreifende synchrone Replikationslogik verwenden kann, um so viele Teile einer Instanz eines virtuellen Speichersystems wie möglich innerhalb einer Verfügbarkeitszone zu isolieren. Beispielsweise kann das vorgestellte virtuelle Speichersystem 1500 aus einem ersten virtuellen Speichersystem 1502 in einer Verfügbarkeitszone, Zone 1, aufgebaut sein, das Daten synchron auf ein zweites virtuelles Speichersystem 1504 in einer anderen Verfügbarkeitszone, Zone 2, repliziert, so dass das vorgestellte virtuelle Speichersystem auch im Falle eines Daten- oder Verfügbarkeitsverlustes in der einen oder anderen Verfügbarkeitszone weiterlaufen und seine Dienste anbieten kann. Eine solche Implementierung könnte ferner so umgesetzt werden, dass langlebige Objekte gemeinsam genutzt werden, so dass die Speicherung von Daten im Objektspeicher koordiniert wird, damit die beiden virtuellen Speichersysteme den gespeicherten Inhalt nicht duplizieren. Darüber hinaus können bei einer solchen Implementierung die beiden synchron replizierenden Speichersysteme Aktualisierungen der Staging-Speicher und möglicherweise der lokalen Instanzspeicher in jeder ihrer Verfügbarkeitszonen synchron replizieren, um die Gefahr von Datenverlusten erheblich zu verringern, während Aktualisierungen der Objektspeicher als spätere asynchrone Aktivität koordiniert werden, um die Kosten der im Objektspeicher gespeicherten Kapazität erheblich zu verringern.
  • In diesem Beispiel wird das virtuelle Speichersystem 1504 innerhalb der Cloud-Computing-Umgebung 1501 implementiert. Ferner kann in diesem Beispiel das virtuelle Speichersystem 1502 einen cloudbasierten Objektspeicher 1550 und das virtuelle Speichersystem 1504 kann einen cloudbasierten Speicher 1552 verwenden, wobei in einigen Fällen, wie z. B. AWS S3, die verschiedenen Objektspeicher 1550, 1552 ein und derselbe Cloud-Objektspeicher mit verschiedenen Buckets sein können.
  • Um bei diesem Beispiel zu bleiben, kann das virtuelle Speichersystem 1502 in einigen Fällen Daten synchron auf andere virtuelle Speichersysteme oder physische Speichersysteme in anderen Verfügbarkeitszonen (nicht dargestellt) replizieren.
  • In einigen Implementierungen kann die Architektur der virtuellen Speichersysteme 1502 und 1504 unterschiedlich und sogar inkompatibel sein, wobei die synchrone Replikation stattdessen davon abhängen kann, dass die synchronen Replikationsmodelle protokollkompatibel sind. Die synchrone Replikation wird oben unter Bezugnahme auf die 3D und 3E ausführlicher beschrieben.
  • In einigen Implementierungen kann das virtuelle Speichersystem 1502 ähnlich implementiert werden wie das virtuelle Speichersystem 1400, das oben unter Bezugnahme auf 14 beschrieben wurde, und das virtuelle Speichersystem 1504 kann ähnlich implementiert werden wie das virtuelle Speichersystem 1200, das oben unter Bezugnahme auf 12 beschrieben wurde.
  • Zur weiteren Erläuterung zeigt 16 ein Beispiel für eine virtuelle Speichersystemarchitektur 1500 in Übereinstimmung mit einigen Ausführungsformen. Die Architektur des virtuellen Speichersystems kann ähnliche cloudbasierte Datenverarbeitungsressourcen umfassen wie die oben unter Bezugnahme auf die 4-15 beschriebenen cloudbasierten Speichersysteme.
  • In einigen Implementierungen kann ein virtuelles Speichersystem 1600, ähnlich wie das oben unter Bezugnahme auf 15 beschriebene virtuelle Speichersystem 1500, mehrere virtuelle Speichersysteme 1502, 1504 umfassen, die sich koordinieren, um eine synchrone Replikation von einem virtuellen Speichersystem zu einem anderen virtuellen Speichersystem durchzuführen.
  • Im Gegensatz zu dem oben beschriebenen Beispiel eines virtuellen Speichersystems 1500 bietet das in 16 dargestellte virtuelle Speichersystem 1600 jedoch einen einzigen cloudbasierten Objektspeicher 1650, der von den virtuellen Speichersystemen 1502, 1504 gemeinsam genutzt wird.
  • In diesem Beispiel kann der gemeinsam genutzte cloudbasierte Objektspeicher 1650 als zusätzliches Ziel für die Datenreplikation behandelt werden, mit verzögerten Aktualisierungen unter Verwendung von Mechanismen und Logik, die mit konsistenten, aber nicht-synchronen Replikationsmodellen verbunden sind. Auf diese Weise kann ein einzelner cloudbasierter Objektspeicher 1650 konsistent von mehreren einzelnen virtuellen Speichersystemen 1502, 1504 eines virtuellen Speichersystems 1600 gemeinsam genutzt werden.
  • In jedem dieser virtuellen Speichersysteme kann die Logik des virtuellen Speichersystems im Allgemeinen verteilte Programmierkonzepte enthalten, um die Implementierung der Kernlogik des virtuellen Speichersystems auszuführen. Mit anderen Worten, die virtuelle Systemlogik kann bei den virtuellen Speichersystemen zwischen virtuellen Speichersystem-Controllern, Scale-out-Implementierungen, die virtuelle System-Controller und virtuelle Laufwerksserver kombinieren, und Implementierungen, die die Verarbeitung zwischen den virtuellen Speichersystem-Controllern und den virtuellen Laufwerksservern aufteilen oder anderweitig optimieren, verteilt werden.
  • Zur weiteren Erläuterung ist in 17 ein Flussdiagramm dargestellt, das ein Beispielverfahren für den Datenfluss in einem virtuellen Speichersystem 1700 zeigt. Das in 17 dargestellte Beispielverfahren kann auf jedem der oben unter Bezugnahme auf die 12-16 beschriebenen virtuellen Speichersysteme implementiert werden. Mit anderen Worten: Das virtuelle Speichersystem 1700 kann entweder durch das virtuelle Speichersystem 1200, 1300, 1400, 1500 oder 1600 implementiert werden.
  • Wie in 17 dargestellt, umfasst das Beispielverfahren das Empfangen (1702) einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem 1700 durch ein virtuelles Speichersystem 1700; das Speichern (1704) der Daten 1754 in einem Staging-Speicher, der durch ein oder mehrere virtuelle Laufwerke des virtuellen Speichersystems 1700 bereitgestellt wird; und das Migrieren (1706) mindestens eines Teils der in dem Staging-Speicher gespeicherten Daten aus dem Staging-Speicher in einen dauerhafteren Datenspeicher, der von einem Cloud-Dienstanbieter bereitgestellt wird.
  • Das Empfangen (1702) der Anforderung zum Schreiben von Daten in das virtuelle Speichersystem 1700 durch das virtuelle Speichersystem 1700 kann wie oben unter Bezugnahme auf die 4-16 beschrieben durchgeführt werden, wobei die Daten in einer oder mehreren empfangenen Speicheroperationen 1752 enthalten sein können und die Anforderung unter Verwendung eines oder mehrerer Kommunikationsprotokolle oder eines oder mehrerer API-Aufrufe empfangen werden kann, die von einer Cloud-Computing-Umgebung 402 bereitgestellt werden, die das virtuelle Speichersystem 1700 hostet.
  • Das Speichern (1704) der Daten 1754 in einem Staging-Speicher, der von einem oder mehreren virtuellen Laufwerken des virtuellen Speichersystems 1700 bereitgestellt wird, kann wie oben unter Bezugnahme auf virtuelle Speichersysteme 1200-1600 beschrieben durchgeführt werden, wobei ein virtuelles Speichersystem, z. B. das virtuelle Speichersystem 1200, Daten von einem Client-Host 1260 an einem virtuellen Controller 408, 410 empfängt und wobei der virtuelle Controller 408, 410 die Daten im lokalen Speicher der Schicht der virtuellen Laufwerke 1210-1216 speichert. Der durch virtuelle Laufwerke bereitgestellte Staging-Speicher wird oben unter Bezugnahme auf 12 ausführlicher beschrieben.
  • Die Migration (1706) mindestens eines Teils der im Staging-Speicher gespeicherten Daten aus dem Staging-Speicher in einen dauerhafteren Datenspeicher, der von einem Cloud-Dienstanbieter bereitgestellt wird, kann wie oben unter Bezugnahme auf die 4-16 beschrieben durchgeführt werden, wobei die Daten aus dem Staging-Speicher in einen cloudbasierten Objektspeicher migriert werden.
  • Weitere Beispiele für das Empfangen von Daten und das Speichern der Daten in einem Staging-Speicher und die anschließende Migration von Daten aus dem Staging-Speicher in einen dauerhafteren Speicher werden in der gemeinsam angemeldeten Patentanmeldung Nr. 16/524.861 beschrieben, die für alle Zwecke in diesem Dokument vollständig übernommen wird. Insbesondere alle Migrationstechniken, die in der gemeinsam angemeldeten Patentanmeldung Nr. 16/524.861 beschrieben sind, beschreiben das Speichern von Daten im Staging-Speicher, der auch als erste Speicherebene bezeichnet wird, und die optionale Verarbeitung, Änderung oder Optimierung der Daten im Staging-Speicher, bevor die Staging-Speicherdaten auf der Grundlage eines Migrationsereignisses in einen dauerhafteren Speicher oder einen cloudbasierten Objektspeicher migriert werden.
  • Zur weiteren Erläuterung ist in 18 ein Flussdiagramm dargestellt, das ein Beispielverfahren für den Datenfluss in einem virtuellen Speichersystem 1700 illustriert. Das in 18 dargestellte Beispielverfahren kann von einem beliebigen der oben unter Bezugnahme auf die 4-16 beschriebenen virtuellen Speichersysteme implementiert werden. Mit anderen Worten: Das virtuelle Speichersystem 1700 kann zumindest durch eines der virtuellen Speichersysteme 1200, 1300, 1400, 1500, 1502, 1504 oder 1600 implementiert werden, entweder einzeln oder durch eine Kombination einzelner Merkmale.
  • Das obige Beispiel in Bezug auf 18 beschreibt eine Implementierung des Datenflusses durch die Speicherebenen eines virtuellen Speichersystems, insbesondere den Datenfluss vom Staging-Speicher zum dauerhafteren Objektspeicher. Allgemeiner ausgedrückt kann der Datenfluss durch ein virtuelles Speichersystem jedoch stufenweise zwischen einem beliebigen Paar mehrerer unterschiedlicher Speicherebenen erfolgen. In diesem Beispiel kann es sich bei den verschiedenen Speicherebenen insbesondere um folgende handeln: (1) virtueller Controller-Speicher, (2) Staging-Speicher für Transaktionskonsistenz und schnelle Abschlüsse, (3) Speicher in virtuellen Laufwerken, die von virtuellen Laufwerksservern bereitgestellt werden, (4) lokale(r) Instanzspeicher des virtuellen Laufwerksservers und (5) ein Objektspeicher, der von einem Cloud-Dienstanbieter bereitgestellt wird.
  • Wie in 18 dargestellt, umfasst das Beispielverfahren: Empfangen (1802) einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem 1700 durch ein virtuelles Speichersystem 1700; Speichern (1804) der Daten 1854 in einem von einer ersten Speicherebene des virtuellen Speichersystems 1700 bereitgestellten Speicher; und Migrieren (1806) mindestens eines Teils der in der ersten Speicherebene gespeicherten Daten von der ersten Speicherebene zu einer zweiten Speicherebene.
  • Das Empfangen (1802) der Anforderung zum Schreiben von Daten 1854 in das virtuelle Speichersystem 1700 durch das virtuelle Speichersystem 1700 kann wie oben unter Bezugnahme auf die 4-17 beschrieben durchgeführt werden, wobei die Daten in einer oder mehreren empfangenen Speicheroperationen 1852 von einem Host-Computer oder einer Anwendung enthalten sein können und die Anforderung unter Verwendung eines oder mehrerer Kommunikationsprotokolle oder eines oder mehrerer API-Aufrufe empfangen werden kann, die von einer Cloud-Computing-Umgebung 402 bereitgestellt werden, die das virtuelle Speichersystem 1700 hostet.
  • Das Speichern (1804) der Daten 1854 in einem Speicher, der von einer ersten Speicherebene des virtuellen Speichersystems 1700 bereitgestellt wird, kann wie oben unter Bezugnahme auf die 4-17 beschrieben erfolgen, wobei eine oder mehrere virtuelle Steuerungen so konfiguriert sein können, dass sie Speicheroperationen 1852 empfangen und abwickeln, einschließlich der Verarbeitung von Schreibanforderungen und der Speicherung entsprechender Schreibdaten in einer oder mehreren Speicherebenen des virtuellen Speichersystems 1700. Fünf Beispielspeicherebenen des virtuellen Speichersystems sind oben unter Bezugnahme auf die Anfangsbeschreibung von 18 beschrieben.
  • Bei der Migration (1806) von der ersten Speicherebene zu einer zweiten Speicherebene kann zumindest ein Teil der in der ersten Speicherebene gespeicherten Daten wie oben im Hinblick auf die Bewegung von Daten durch verschiedene Speicherebenen beschrieben übertragen werden. Darüber hinaus können in einigen Beispielen, wie oben beschrieben, Daten auf verschiedene Weise auf einer oder mehreren Speicherebenen transformiert werden, einschließlich Deduplizieren, Überschreiben, Aggregation in Segmente, neben anderen Transformationen, Generieren von Wiederherstellungsmetadaten oder Metadaten für den kontinuierlichen Datenschutz, während die Daten von einem oder mehreren virtuellen Controllern durch das virtuelle Speichersystem 1700 in den Backend-Speicher fließen, einschließlich eines oder mehrerer Objektspeicher und einer der unten beschriebenen Speicherklassenoptionen.
  • Ein virtuelles Speichersystem kann die Ressourcennutzung der Cloud-Plattform dynamisch an veränderte Kostenanforderungen anpassen, die auf den Preisstrukturen der Cloud-Plattform basieren, wie im Folgenden näher beschrieben.
  • Unter verschiedenen Bedingungen können sich Budgets, Kapazitäten, Nutzungs- und/oder Leistungsanforderungen ändern, und einem Benutzer können Kostenprognosen und eine Vielzahl von Kalkulationsszenarien vorgelegt werden, die eine Erhöhung der Anzahl von Server- oder Speicherkomponenten, der verfügbaren Komponententypen, der Plattformen, die geeignete Komponenten bereitstellen können, und/oder Modelle dafür umfassen, wie Alternativen zu einer aktuellen Einrichtung in Zukunft funktionieren und kosten könnten. In einigen Beispielen können solche Kostenprognosen die Kosten für die Migration zwischen Alternativen einschließen, da Netzwerkübertragungen Kosten verursachen, Migrationen in der Regel einen Verwaltungsaufwand beinhalten und für die Dauer eines Datentransfers zwischen Speichertypen oder Anbietern zusätzliche Gesamtkapazitäten erforderlich sein können, bis die erforderlichen Dienste voll einsatzfähig sind.
  • In einigen Implementierungen kann ein Benutzer stattdessen ein Budget angeben oder auf andere Weise einen Kostenschwellenwert spezifizieren, und der Speichersystemdienst kann eine virtuelle Speichersystemkonfiguration mit spezifizierter Ressourcennutzung generieren, so dass der Speichersystemdienst innerhalb des Budgets oder des Kostenschwellenwerts arbeitet, anstatt einen Preis für die verwendeten Ressourcen zu berechnen und Optionen für Konfigurationen bereitzustellen.
  • Um dieses Beispiel eines Speichersystemdienstes fortzusetzen, der innerhalb eines Budgets oder einer Kostenschwelle arbeitet, können die Kosten im Hinblick auf die Rechenressourcen verwaltet werden, indem die Konfigurationen virtueller Anwendungsserver, virtueller Speichersystemcontroller und anderer virtueller Speichersystemkomponenten durch Hinzufügen, Entfernen oder Ersetzen durch schnellere oder langsamere virtuelle Speichersystemkomponenten geändert werden, während die Begrenzung der Rechenressourcen die Leistung begrenzt. Wenn in einigen Beispielen die Kosten oder Budgets über einen bestimmten Zeitraum betrachtet werden, z. B. über eine monatliche, vierteljährliche oder jährliche Abrechnung, dann können durch die Senkung der Kosten für virtuelle Rechenressourcen als Reaktion auf eine geringere Arbeitslast mehr Rechenressourcen als Reaktion auf eine höhere Arbeitslast verfügbar sein.
  • Ferner können in einigen Beispielen als Reaktion auf die Feststellung, dass bestimmte Arbeitslasten zu flexiblen Zeiten ausgeführt werden können, diese Arbeitslasten so geplant werden, dass sie in Zeiträumen ausgeführt werden, in denen der Betrieb oder die Aktivierung von Rechenressourcen innerhalb des virtuellen Speichersystems weniger kostspielig ist. In einigen Beispielen können die Kosten und die Nutzung im Laufe eines Abrechnungszeitraums überwacht werden, um festzustellen, ob die Nutzung zu einem früheren Zeitpunkt des Abrechnungszeitraums die Fähigkeit beeinträchtigt, später im Abrechnungszeitraum mit der erwarteten oder akzeptablen Leistung zu arbeiten, oder ob eine geringere als die erwartete Nutzung während Teilen eines Abrechnungszeitraums darauf hindeutet, dass noch genügend Budget für die Ausführung optionaler Arbeiten vorhanden ist oder dass eine Neuverhandlung der Bedingungen die Kosten senken würde.
  • Ein solches Modell der dynamischen Anpassung eines virtuellen Speichersystems als Reaktion auf Kosten- oder Ressourcenbeschränkungen kann von den Rechenressourcen auf die Speicherressourcen ausgeweitet werden. Eine andere Überlegung für Speicherressourcen ist jedoch, dass die Preise für Speicherressourcen weniger elastisch sind als für Rechenressourcen, da die gespeicherten Daten über einen bestimmten Zeitraum hinweg weiterhin Speicherressourcen belegen.
  • Darüber hinaus können in einigen Beispielen Übertragungskosten innerhalb von Cloud-Plattformen anfallen, die mit der Migration von Daten zwischen Speicherdiensten mit unterschiedlichen Kapazitäten und Übertragungspreisen verbunden sind. Alle diese Kosten für die Wartung virtueller Speichersystemressourcen müssen berücksichtigt werden und können als Grundlage für die Konfiguration, Bereitstellung und Änderung von Rechen- und/oder Speicherressourcen innerhalb eines virtuellen Speichersystems dienen.
  • In einigen Fällen kann das virtuelle Speichersystem als Reaktion auf Speicherkosten auf der Grundlage von Kostenprognosen angepasst werden, die einen Vergleich der fortlaufenden Speicherkosten unter Verwendung vorhandener Ressourcen mit einer Kombination aus Übertragungskosten des Speicherinhalts und Speicherkosten weniger teurer Speicherressourcen (wie z. B. Speicher, der von einer anderen Cloud-Plattform bereitgestellt wird, oder zu oder von Speicherhardware in vom Kunden verwalteten Rechenzentren oder zu oder von vom Kunden verwalteter Hardware, die in einem gemeinsam verwalteten Rechenzentrum aufbewahrt wird) umfassen können. Auf diese Weise kann sich ein auf einem Budgetlimit basierendes virtuelles Speichersystemmodell über eine bestimmte Zeitspanne, die lang genug ist, um Datenübertragungen zu unterstützen, und in einigen Fällen auf der Grundlage vorhersehbarer Nutzungsmuster an unterschiedliche Kosten- oder Budgetbeschränkungen oder -anforderungen anpassen.
  • In einigen Implementierungen kann ein dynamisch konfigurierbares virtuelles Speichersystem, wenn die Kapazität als Reaktion auf eine Ansammlung gespeicherter Daten wächst und die Arbeitslasten über einen bestimmten Zeitraum um eine Durchschnitts- oder Trendlinie schwanken, berechnen, ob die Kosten für die Übertragung einer Datenmenge auf eine weniger teure Speicherklasse oder einen weniger teuren Speicherort innerhalb eines bestimmten Budgets oder innerhalb einer bestimmten Budgetänderung möglich sind. In einigen Beispielen kann das virtuelle Speichersystem Speicherübertragungen auf der Grundlage der Kosten über einen Zeitraum bestimmen, der einen Abrechnungszyklus oder mehrere Abrechnungszyklen umfasst, und auf diese Weise verhindern, dass ein Budget oder Kosten in einem nachfolgenden Abrechnungszyklus überschritten werden.
  • In einigen Implementierungen kann ein kostenverwaltetes oder kostenbeschränktes virtuelles Speichersystem, d. h. ein virtuelles Speichersystem, das sich selbst als Reaktion auf Kostenbeschränkungen oder andere Ressourcenbeschränkungen rekonfiguriert, auch Speicherklassen für Schreibzugriff, Archivierung oder Tiefenarchivierung verwenden, die von Cloud-Infrastrukturanbietern bereitgestellt werden. Darüber hinaus kann das virtuelle Speichersystem in einigen Fällen gemäß den Modellen und Einschränkungen arbeiten, die an anderer Stelle im Hinblick auf die Implementierung eines Speichersystems für die Arbeit mit Speicherklassen mit unterschiedlichem Verhalten beschrieben wurden.
  • Ein virtuelles Speichersystem kann beispielsweise automatisch eine Speicherklasse verwenden, die hauptsächlich zum Schreiben verwendet wird, wenn festgestellt wird, dass Kosten oder Budget eingespart und für andere Zwecke wiederverwendet werden können, wenn Daten mit einer geringen Zugriffswahrscheinlichkeit konsolidiert werden, z. B. in Segmenten, die Daten mit ähnlichen Zugriffsmustern oder ähnlichen Zugriffswahrscheinlichkeitseigenschaften zusammenfassen.
  • In einigen Fällen können konsolidierte Datensegmente dann auf eine Speicherklasse mit überwiegendem Schreibzugriff oder eine andere kostengünstigere Speicherklasse migriert werden. In einigen Beispielen kann die Verwendung lokaler Instanzspeicher auf virtuellen Laufwerken zu Kostensenkungen führen, die eine Anpassung der Ressourcen des virtuellen Speichersystems ermöglichen, um Kosten- oder Budgetänderungsauflagen zu erfüllen. In einigen Fällen können die lokalen Instanzspeicher überwiegend schreibende Objektspeicher als Backend verwenden, und da die Leselast oft vollständig von den lokalen Instanzspeichern aufgenommen wird, können die lokalen Instanzspeicher hauptsächlich als Cache fungieren, anstatt vollständige Kopien eines aktuellen Datensatzes zu speichern.
  • In einigen Beispielen kann ein einfach verfügbarer, dauerhafter Speicher auch verwendet werden, wenn ein Datensatz identifiziert werden kann, der den Verlust einer Verfügbarkeitszone nicht überstehen muss oder soll, und eine solche Verwendung kann als Grundlage für Kosteneinsparungen bei der dynamischen Neukonfiguration eines virtuellen Speichersystems dienen. In einigen Fällen kann die Verwendung einer einzigen Verfügbarkeitszone für einen Datensatz eine explizite Bestimmung des Datensatzes oder eine indirekte Bestimmung durch eine Speicherrichtlinie beinhalten.
  • In einigen Fällen kann die spezifische Verfügbarkeitszone jedoch durch eine Datensatzzuordnung bestimmt werden, z. B. zu Hostsystemen, die von einer bestimmten Verfügbarkeitszone aus auf ein virtuelles Speichersystem zugreifen. Mit anderen Worten: In diesem Beispiel kann die spezifische Verfügbarkeitszone als dieselbe Verfügbarkeitszone bestimmt werden, die ein Hostsystem umfasst.
  • In einigen Implementierungen kann ein virtuelles Speichersystem eine dynamische Rekonfiguration auf die Verwendung von Archiv- oder Deep-Archive-Speicherklassen stützen, wenn das virtuelle Speichersystem in der Lage ist, Leistungsanforderungen zu erfüllen, während Speicheroperationen durch die Beschränkungen von Archiv- und/oder Deep-Archive-Speicherklassen begrenzt sind. Darüber hinaus kann in einigen Fällen die Übertragung alter Snapshot- oder kontinuierlicher Datensicherungsdatensätze oder anderer nicht mehr aktiver Datensätze in Archivspeicherklassen auf der Grundlage einer Speicherrichtlinie aktiviert werden, die eine Datenübertragung als Reaktion auf ein bestimmtes Aktivitätsniveau vorschreibt, oder auf der Grundlage einer Speicherrichtlinie, die eine Datenübertragung als Reaktion auf Daten vorschreibt, auf die über einen bestimmten Zeitraum nicht zugegriffen wurde. In anderen Beispielen kann das virtuelle Speichersystem Daten als Reaktion auf eine bestimmte Benutzeranforderung an eine Archivspeicherklasse übertragen.
  • Da der Abruf aus einer Archivspeicherklasse Minuten, Stunden oder Tage dauern kann, können die Benutzer eines bestimmten Datensatzes, der in einer Archiv- oder Deep-Archive-Speicherklasse gespeichert ist, vom virtuellen Speichersystem aufgefordert werden, die für den Abruf des Datensatzes erforderliche Zeit zu genehmigen. In einigen Beispielen kann bei der Verwendung von Deep-Archive-Speicherklassen auch die Häufigkeit des Datenzugriffs begrenzt sein, wodurch die Umstände, unter denen der Datensatz in Archiv- oder Deep-Archive-Speicherklassen gespeichert werden kann, weiter eingeschränkt werden können.
  • Die Implementierung eines virtuellen Speichersystems für die Arbeit mit Speicherklassen, die sich unterschiedlich verhalten, kann mit verschiedenen Techniken erfolgen, die im Folgenden näher beschrieben werden.
  • In verschiedenen Implementierungen können einige Speichertypen, wie z. B. eine Speicherklasse mit überwiegendem Schreibzugriff, niedrigere Preise für das Speichern und Aufbewahren von Daten haben als für den Zugriff auf und den Abruf von Daten. Wenn in einigen Beispielen festgestellt wird, dass Daten selten abgerufen werden oder unterhalb eines bestimmten Schwellenwerts abgerufen werden, können die Kosten durch das Speichern der Daten in einer Speicherklasse mit überwiegendem Schreibzugriff gesenkt werden. In einigen Fällen kann eine solche Speicherklasse mit überwiegendem Schreibzugriff zu einer zusätzlichen Speicherebene werden, die von virtuellen Speichersystemen mit Zugang zu einer oder mehreren Cloud-Infrastrukturen genutzt werden kann, die solche Speicherklassen bereitstellen.
  • So kann beispielsweise in einer Speicherrichtlinie festgelegt werden, dass eine Speicherklasse mit überwiegendem Schreibzugriff oder eine andere Archivspeicherklasse für das Speichern von Datensegmenten aus Snapshots, Prüfpunkten oder historischen, kontinuierlichen Datensicherungsdatensätzen verwendet werden kann, die aus aktuellen Instanzen der Datensätze, die sie verfolgen, überschrieben oder gelöscht wurden. Darüber hinaus können diese Segmente in einigen Fällen übertragen werden, wenn sie ein Zeitlimit überschreiten, ohne dass auf sie zugegriffen wird, wobei das Zeitlimit in einer Speicherrichtlinie festgelegt werden kann und das Zeitlimit einer geringen Wahrscheinlichkeit einer Wiederherstellung entspricht - abgesehen von einer versehentlichen Löschung oder Beschädigung, die den Zugriff auf eine ältere historische Kopie eines Datensatzes erfordern kann, oder eine Störung oder eine größere Katastrophe, die möglicherweise eine forensische Untersuchung erfordert, ein kriminelles Ereignis, ein Verwaltungsfehler wie das versehentliche Löschen jüngerer Daten oder die Verschlüsselung oder Löschung oder eine Kombination von Teilen oder des gesamten Datensatzes und seiner jüngeren Snapshots, Klone oder kontinuierlichen Datenschutz-Tracking-Images als Teil eines Ransomware-Angriffs.
  • In einigen Implementierungen kann die Verwendung einer Cloud-Plattform mit überwiegendem Schreibzugriff zu Kosteneinsparungen führen, die dann zur Bereitstellung von Rechenressourcen verwendet werden können, um die Leistung des virtuellen Speichersystems zu verbessern. Wenn ein virtuelles Speichersystem Speicherzugriffsinformationen nachverfolgt und verwaltet, z. B. mit einem Garbage Collector, der Alter und Snapshot/Klon/kontinuierlichen Datenschutz berücksichtigt, oder mit einem Segmentkonsolidierungs- und/oder Migrationsalgorithmus, kann das virtuelle Speichersystem in einigen Beispielen ein Segmentmodell als Teil der Einrichtung effizienter Metadatenreferenzen verwenden und dabei die an die Speicherklasse mit überwiegendem Schreibzugriff übertragene Datenmenge minimieren.
  • Darüber hinaus kann ein virtuelles Speichersystem, das Snapshots, Klone oder Informationen zur Nachverfolgung des kontinuierlichen Datenschutzes integriert, in einigen Implementierungen auch die Datenmenge reduzieren, die aus einem überwiegend schreibgeschützten Speicher zurückgelesen werden kann, da die Daten bereits in weniger teuren Speicherklassen gespeichert sind, wie z. B. lokale Instanzspeicher auf virtuellen Laufwerken oder Objekte, die in der Standardspeicherklasse einer Cloud-Plattform gespeichert sind, für Daten verwendet werden können, die aus diesen lokalen Speicherquellen noch verfügbar sind und nicht überschrieben oder gelöscht wurden, seit ein Snapshot, ein Klon oder ein Wiederherstellungspunkt mit kontinuierlichem Datenschutz in den überwiegend schreibgeschützten Speicher geschrieben wurde. Darüber hinaus können in einigen Beispielen Daten, die aus einer Speicherklasse mit überwiegendem Schreibzugriff abgerufen wurden, zur weiteren Verwendung in eine andere Speicherklasse, z. B. in lokale Instanzspeicher eines virtuellen Laufwerks, geschrieben werden, um in einigen Fällen zu vermeiden, dass für den Abruf erneut Gebühren erhoben werden.
  • In einigen Implementierungen kann eine zusätzliche Ebene wiederherstellbarer Inhalte auf der Grundlage der oben beschriebenen Verfahren und Techniken in Bezug auf die Wiederherstellung nach dem Verlust von Staging-Speicherinhalten bereitgestellt werden, wobei die zusätzliche Ebene wiederherstellbarer Inhalte verwendet werden kann, um die Zuverlässigkeit bis zu einigen konsistenten Punkten in der Vergangenheit vollständig aus Daten zu gewährleisten, die in einem dieser sekundären Speicher gespeichert sind, einschließlich der in diesen anderen Speicherklassen gespeicherten Objekte.
  • Darüber hinaus kann die Wiederherstellbarkeit in diesem Beispiel auf der Aufzeichnung der Informationen beruhen, die für ein Rollback zu einem konsistenten Punkt, wie z. B. einem Snapshot oder Checkpoint, erforderlich sind, wobei Informationen verwendet werden, die vollständig in dieser Speicherklasse enthalten sind. In einigen Beispielen kann eine solche Implementierung auf einer Speicherklasse basieren, die ein vollständiges Abbild eines Datensatzes aus der Vergangenheit enthält, anstatt nur Daten, die überschrieben oder gelöscht wurden, wobei das Überschreiben oder Löschen verhindern kann, dass Daten in neueren Inhalten des Datensatzes vorhanden sind. Diese Beispiel-Implementierung kann zwar die Kosten erhöhen, aber dafür kann das virtuelle Speichersystem einen wertvollen Dienst wie die Wiederherstellung nach einem Ransomware-Angriff bieten, wobei der Schutz vor einem Ransomware-Angriff darauf beruhen kann, dass zusätzliche Berechtigungs- oder Zugriffsebenen erforderlich sind, die das Löschen oder Überschreiben von in der jeweiligen Speicherklasse gespeicherten Objekten verhindern.
  • In einigen Implementierungen kann ein virtuelles Speichersystem zusätzlich zu oder anstelle einer Speicherklasse mit überwiegendem Schreibzugriff auch Archivspeicherklassen und/oder Deep-Archive-Speicherklassen für Inhalte verwenden, auf die - im Vergleich zu Speicherklassen mit überwiegendem Schreibzugriff - noch seltener zugegriffen wird oder die nur bei voraussichtlich seltenen Katastrophen benötigt werden, für die sich aber ein hoher Aufwand lohnt, um die Inhalte abrufen zu können. Beispiele für solche Inhalte mit geringem Zugriff können historische Versionen eines Datensatzes, Snapshots oder Klone sein, die in seltenen Fällen benötigt werden, etwa in der Offenlegungsphase eines Rechtsstreits oder einer ähnlichen Katastrophe, insbesondere wenn eine andere Partei für die Wiederherstellung zahlen muss.
  • Ein weiteres Beispiel ist die Aufbewahrung historischer Versionen eines Datensatzes, Snapshots oder Klone für den Fall eines Ransomware-Angriffs (siehe oben). In einigen Beispielen, z. B. im Falle eines Rechtsstreits, kann ein virtuelles Speichersystem zur Verringerung der gespeicherten Datenmenge nur frühere Versionen von Daten in Datensätzen speichern, die überschrieben oder gelöscht wurden. In anderen Beispielen, z. B. im Fall von Ransomware oder Disaster Recovery, kann ein virtuelles Speichersystem, wie oben beschrieben, einen vollständigen Datensatz in einer Archiv- oder Deep-Archive-Speicherklasse speichern, zusätzlich zur Speicherung von Kontrollen, um die Wahrscheinlichkeit unbefugter Löschungen oder Überschreibungen der in der gegebenen Archiv- oder Deep-Archive-Speicherklasse gespeicherten Objekte auszuschließen, einschließlich der Speicherung aller Daten, die zur Wiederherstellung eines konsistenten Datensatzes von mindestens einigen verschiedenen Zeitpunkten erforderlich sind.
  • In einigen Implementierungen besteht ein Unterschied darin, wie ein virtuelles Speichersystem verwendet wird: (a) Objekten, die in einer Speicherklasse mit überwiegendem Schreibzugriff gespeichert sind, und (b) Objekten, die in Archiv- oder Deep-Archive-Speicherklassen gespeichert sind, kann der Zugriff auf einen Snapshot, einen Klon oder einen Prüfpunkt mit kontinuierlichem Datenschutz einschließen, der auf eine bestimmte Speicherklasse zugreift. Im Beispiel einer Speicherklasse mit überwiegendem Schreibzugriff können Objekte mit einer ähnlichen oder sogar identischen Latenzzeit abgerufen werden wie Objekte, die in einer von der Cloud-Plattform des virtuellen Speichersystems bereitgestellten Standardspeicherklasse gespeichert sind, wobei die Kosten für das Speichern in der Speicherklasse mit überwiegendem Schreibzugriff höher sein können als in der Standardspeicherklasse.
  • In einigen Beispielen kann ein virtuelles Speichersystem die Verwendung der Speicherklasse „write-mostly“ als eine untergeordnete Variante eines regulären Modells für den Zugriff auf Inhalte implementieren, die Segmenten entsprechen, die derzeit nur von Objekten der Standardspeicherklasse verfügbar sind. Insbesondere können in diesem Beispiel Daten abgerufen werden, wenn eine Operation diese Daten liest, z. B. durch Lesen aus einem logischen Offset eines Snapshots eines Tracking-Volumes. In einigen Fällen kann ein virtuelles Speichersystem von einem Benutzer verlangen, dass er zusätzliche Gebühren für solche Abrufe bezahlt, wenn der Zugriff auf den Snapshot oder eine andere Art von gespeichertem Bild angefordert wird, und die abgerufenen Daten können in lokalen Instanzspeichern gespeichert werden, die mit einem virtuellen Laufwerk verbunden sind, oder in Objekte in einer Standardspeicherklasse kopiert (oder konvertiert) werden, um zu vermeiden, dass weiterhin höhere Gebühren für den Abruf von Speicherplatz gezahlt werden, wenn die andere Speicherklasse verwendet wird, die nicht in der Architektur des virtuellen Speichersystems enthalten ist.
  • Im Gegensatz zu den oben erwähnten vernachlässigbaren Latenzen bei Speicherklassen, die hauptsächlich zum Schreiben verwendet werden, können in einigen Fällen Latenzen oder Verfahren, die mit dem Abrufen von Objekten aus Archiv- oder Deep-Archive-Speicherklasse verbunden sind, die Implementierung unpraktisch machen. Wenn das Abrufen von Objekten aus einer Archiv- oder einer Deep-Archive-Speicherklasse Stunden oder Tage dauert, kann in einigen Fällen ein alternatives Verfahren implementiert werden. Beispielsweise kann ein Benutzer den Zugriff auf einen Snapshot anfordern, von dem bekannt ist, dass er zumindest einige Segmente benötigt, die in Objekten gespeichert sind, die in einer Archiv- oder Deep-Archive-Speicherklasse gespeichert sind. Als Antwort darauf kann das virtuelle Speichersystem eine Liste von Segmenten ermitteln, die den angeforderten Datensatz (oder Snapshot, Klon oder kontinuierlichen Datenschutz-Wiederherstellungspunkt) enthalten und in Objekten im Archiv- oder Deep-Archive-Speicher gespeichert sind, anstatt alle diese Segmente auf Anforderung zu lesen.
    Auf diese Weise kann das virtuelle Speichersystem in diesem Beispiel anfordern, dass die Segmente in der ermittelten Segmentliste abgerufen werden, um beispielsweise in Objekte einer Standardspeicherklasse oder in virtuelle Laufwerke kopiert zu werden, die in lokalen Instanzspeichern gespeichert werden. In diesem Beispiel kann das Abrufen der Segmentliste Stunden oder Tage dauern, aber aus Leistungs- und Kostengründen ist es vorzuziehen, die gesamte Segmentliste auf einmal anzufordern, anstatt einzelne Anfragen nach Bedarf zu stellen. Nachdem die Liste der Segmente aus dem Archiv oder dem Deep-Archive-Speicher abgerufen wurde, kann der Zugriff auf den abgerufenen Snapshot, den Klon oder den Wiederherstellungspunkt der kontinuierlichen Datensicherung erfolgen.
  • Der Leser wird verstehen, dass, obwohl sich die oben beschriebenen Ausführungsformen auf Ausführungsformen beziehen, bei denen Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist, im Wesentlichen in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden, indem die Daten aus der Objektspeicherebene des cloudbasierten Speichersystems abgerufen werden, andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenlegung fallen. Da beispielsweise Daten über den lokalen Speicher mehrerer Cloud-Computing-Instanzen unter Verwendung von Datenredundanztechniken wie RAID verteilt werden können, können in einigen Ausführungsformen die verlorenen Daten durch einen RAID-Neuaufbau in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden.
  • Der Leser wird ferner verstehen, dass - obwohl die vorstehenden Abschnitte cloudbasierte Speichersysteme und deren Betrieb beschreiben - die oben beschriebenen cloudbasierten Speichersysteme verwendet werden können, um Blockspeicher als Dienst anzubieten, da die cloudbasierten Speichersysteme hochgefahren und genutzt werden können, um Blockdienste auf Anfrage und nach Bedarf bereitzustellen. In einem solchen Beispiel kann die Bereitstellung von Blockspeichern als Dienst in einer Cloud-Computing-Umgebung Folgendes umfassen: Empfangen einer Anfrage nach Blockspeicherdiensten von einem Benutzer; Erstellen eines Datenträgers zur Verwendung durch den Benutzer; Empfangen von E/A-Operationen, die an den Datenträger gerichtet sind; und Weiterleiten der E/A-Operationen an ein Speichersystem, das zusammen mit Hardwareressourcen für die Cloud-Computing-Umgebung angeordnet ist.
  • Beispielhafte Ausführungsformen werden weitgehend im Zusammenhang mit einem voll funktionsfähigen Computersystem beschrieben. Fachkundige Leser werden jedoch erkennen, dass die vorliegende Offenbarung auch in einem Computerprogrammprodukt verkörpert sein kann, das auf einem computerlesbaren Speichermedium zur Verwendung mit einem geeigneten Datenverarbeitungssystem eingerichtet ist. Solche computerlesbaren Speichermedien können jedes Speichermedium für maschinenlesbare Informationen sein, einschließlich magnetischer Medien, optischer Medien oder anderer geeigneter Medien. Beispiele für solche Medien sind Magnetplatten in Festplattenlaufwerken oder Disketten, Compact Disks für optische Laufwerke, Magnetbänder und andere, die demjenigen bekannt sind, der im Fachgebiet erfahren ist. Der Fachmann wird sofort erkennen, dass jedes Computersystem mit geeigneten Programmiermitteln in der Lage ist, die Schritte des Verfahrens, wie sie in einem Computerprogrammprodukt verkörpert sind, auszuführen. Diejenigen, die im Fachgebiet erfahren sind, werden auch erkennen, dass - obwohl einige der in dieser Beschreibung beschriebenen Beispielsausführungen auf Software ausgerichtet sind, die auf Computerhardware installiert und ausgeführt wird - alternative Ausführungsformen, die als Firmware oder als Hardware implementiert sind, durchaus in den Anwendungsbereich der vorliegenden Offenbarung fallen.
  • Ausführungsformen können ein System, ein Verfahren und/oder ein Computerprogrammprodukt sein. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder Medien) mit computerlesbaren Programmanweisungen darauf enthalten, um einen Prozessor zu veranlassen, Aspekte der vorliegenden Offenbarung auszuführen.
  • Bei dem computerlesbaren Speichermedium kann es sich um eine konkrete Vorrichtung handeln, die Befehle zur Verwendung durch eine Befehlsausführungsvorrichtung aufbewahren und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich beispielsweise um eine elektronische Speichervorrichtung, eine magnetische Speichervorrichtung, eine optische Speichervorrichtung, eine elektromagnetische Speichervorrichtung, eine Halbleiterspeichervorrichtung oder eine beliebige geeignete Kombination der vorgenannten Vorrichtungen handeln, ist aber nicht darauf beschränkt. Eine nicht erschöpfende Liste spezifischerer Beispiele für ein computerlesbares Speichermedium umfasst Folgendes: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Compact-Disc-Festwertspeicher (CD-ROM), eine Digital Versatile Disk (DVD), ein Memory-Stick, eine Diskette, eine mechanisch kodierte Vorrichtung wie Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Befehlen sowie jede geeignete Kombination der vorgenannten. Ein computerlesbares Speichermedium, wie es hier verwendet wird, ist nicht so zu verstehen, dass es sich um transitorische Signale per se handelt, wie z. B. Radiowellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z. B. Lichtimpulse, die durch ein Glasfaserkabel laufen), oder elektrische Signale, die durch einen Draht übertragen werden.
  • Die hier beschriebenen computerlesbaren Programmanweisungen können von einem computerlesbaren Speichermedium auf die jeweiligen Rechen-/Verarbeitungsgeräte oder auf einen externen Computer oder ein externes Speichergerät über ein Netzwerk, z. B. das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk, heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, optische Übertragungsfasern, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jedem Computer/Verarbeitungsgerät empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium im jeweiligen Computer/Verarbeitungsgerät weiter.
  • Bei den computerlesbaren Programmanweisungen zur Durchführung von Operationen der vorliegenden Offenbarung kann es sich um Assembler-Befehle, ISA-Befehle (Instruction-Set-Architecture), Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Firmware-Befehle, Zustandsdaten oder entweder um Quellcode oder Objektcode handeln, der in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen, einschließlich einer objektorientierten Programmiersprache wie Smalltalk, C++ oder ähnlichen, und herkömmlichen prozeduralen Programmiersprachen wie der Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben ist. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernten Computer oder vollständig auf dem entfernten Computer oder Server ausgeführt werden. Im letztgenannten Fall kann der entfernte Computer mit dem Computer des Benutzers über eine beliebige Art von Netzwerk verbunden sein, einschließlich eines Local Area Networks (LAN) oder eines Wide Area Networks (WAN), oder die Verbindung kann zu einem externen Computer hergestellt werden (z. B. über das Internet unter Verwendung eines Internetdienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, die beispielsweise programmierbare Logikschaltungen, feldprogrammierbare Gate-Arrays (FPGA) oder programmierbare Logik-Arrays (PLA) umfassen, die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen verwenden, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Offenbarung durchzuführen.
  • Aspekte der vorliegenden Offenbarung werden hier unter Bezugnahme auf Flussdiagrammdarstellungen und/oder Blockdiagramme von Verfahren, Geräten (Systemen) und Computerprogrammprodukten gemäß einigen Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Flussdiagrammdarstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammdarstellungen und/oder Blockdiagrammen durch computerlesbare Programmanweisungen implementiert werden können.
  • Diese computerlesbaren Programmanweisungen können einem Prozessor eines Allzweckcomputers, eines Spezialcomputers oder eines anderen programmierbaren Datenverarbeitungsgeräts bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computers oder des anderen programmierbaren Datenverarbeitungsgeräts ausgeführt werden, Mittel zur Implementierung der im Flussdiagramm und/oder Blockdiagramm angegebenen Funktionen/Aktionen schaffen. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, ein programmierbares Datenverarbeitungsgerät und/oder andere Vorrichtungen anweisen kann, in einer bestimmten Weise zu funktionieren, so dass das computerlesbare Speichermedium, in dem Anweisungen gespeichert sind, einen Herstellungsgegenstand umfasst, der Anweisungen enthält, die Aspekte der in dem Flussdiagramm und/oder dem Blockdiagrammblock oder den Blöcken angegebenen Funktion/Aktion implementieren.
  • Die computerlesbaren Programmanweisungen können auch auf einen Computer, ein anderes programmierbares Datenverarbeitungsgerät oder ein anderes Gerät geladen werden, um eine Reihe von Betriebsschritten zu veranlassen, die auf dem Computer, einem anderen programmierbaren Gerät oder einer anderen Vorrichtung ausgeführt werden, um einen computerimplementierten Prozess zu erzeugen, so dass die Anweisungen, die auf dem Computer, einem anderen programmierbaren Gerät oder einer anderen Vorrichtung ausgeführt werden, die in dem Flussdiagramm und/oder dem Blockdiagrammblock oder den Blöcken angegebenen Funktionen/Aktionen implementieren.
  • Die Flussdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenlegung. In diesem Zusammenhang kann jeder Block im Flussdiagramm oder in den Blockdiagrammen ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Implementierung der angegebenen logischen Funktion(en) umfasst. In einigen alternativen Implementierungen können die in den Blöcken angegebenen Funktionen in einer anderen als der in den Figuren angegebenen Reihenfolge auftreten. So können z. B. zwei nacheinander gezeigte Blöcke in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, je nach der betreffenden Funktionalität. Es wird auch darauf hingewiesen, dass jeder Block in den Blockdiagrammen und/oder Flussdiagrammen sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder Flussdiagrammen durch spezielle Hardware-basierte Systeme implementiert werden können, die die angegebenen Funktionen oder Handlungen ausführen oder Kombinationen von spezieller Hardware und Computerbefehlen ausführen.
  • Einige Ausführungsformen der vorliegenden Offenbarung können eine Vorrichtung zum Bedienen von E/A-Operationen in einem virtuellen Speichersystem umfassen, wobei die Vorrichtung Folgendes umfasst: ein Mittel zum Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; ein Mittel zum Speichern der Daten in einem Speicher, der von einer ersten Speicherebene des virtuellen Speichersystems bereitgestellt wird; und ein Mittel zum Migrieren mindestens eines Teils der in der ersten Speicherebene gespeicherten Daten von der ersten Speicherebene zu einer zweiten Speicherebene, die dauerhafter ist als die erste Speicherebene des virtuellen Speichersystems. In einigen Ausführungsformen umfasst die erste Speicherebene einen Staging-Speicher, der Transaktionskonsistenz und Schreibbestätigungen bereitstellt, und die zweite Speicherebene umfasst virtuelle Laufwerke, die von virtuellen Laufwerkservern des virtuellen Speichersystems bereitgestellt werden. In einigen Ausführungsformen umfasst die erste Speicherebene die virtuellen Laufwerke, die von virtuellen Laufwerksservern des virtuellen Speichersystems bereitgestellt werden, und die zweite Speicherebene umfasst eine Objektspeicherung, die von einem Cloud-Service-Anbieter bereitgestellt wird, welcher eine Objektspeicherung unabhängig von dem virtuellen Speichersystem bereitstellt. In einigen Ausführungsformen reagiert das Migrieren zumindest des Teils der im Staging-Speicher gespeicherten Daten auf das Erkennen einer Bedingung für die Übertragung von Daten zwischen dem Staging-Speicher und dem dauerhaften Datenspeicher, der von dem Cloud-Service-Anbieter bereitgestellt wird. In einigen Ausführungsformen umfasst der Staging-Speicher mehrere virtuelle Laufwerke, die von virtuellen Laufwerksservern bereitgestellt werden. In einigen Ausführungsformen enthalten mehrere virtuelle Laufwerksserver einen entsprechenden lokalen Speicher. In einigen Ausführungsformen stellen die mehreren virtuellen Laufwerksserver virtuelle Laufwerke als blockartige Datenspeicher bereit. In einigen Ausführungsformen wird die Anforderung, Daten in das virtuelle Speichersystem zu schreiben, von einem oder mehreren virtuellen Controllern empfangen, die in einer virtuellen Maschine, einem Container oder einem Bare-Metal-Server laufen. In einigen Ausführungsformen wird der Staging-Speicher von mehreren virtuellen Laufwerksservern bereitgestellt, die jeweils sowohl einen virtuellen Controller als auch einen lokalen Speicher enthalten. In einigen Ausführungsformen wird zumindest der Teil der im Staging-Speicher gespeicherten Daten vor der Migration vom Staging-Speicher zum dauerhaften Datenspeicher dedupliziert, verschlüsselt oder komprimiert. In einigen Ausführungsformen zeichnet sich der Staging-Speicher des virtuellen Speichersystems durch eine niedrige Leselatenz im Vergleich zum dauerhaften Datenspeicher aus, der vom Cloud-Service-Anbieter bereitgestellt wird
  • Die Vorteile und Merkmale der vorliegenden Offenbarung können durch die folgenden Aussagen weiter beschrieben werden:
  • Aussage 1. Ein Verfahren zum Bedienen von E/A-Operationen in einem virtuellen Speichersystem, wobei das Verfahren umfasst: Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; Speichern der Daten in einem von einer ersten Speicherebene des virtuellen Speichersystems bereitgestellten Speicher; und Migrieren mindestens eines Teils der in der ersten Speicherebene gespeicherten Daten von der ersten Speicherebene zu einer zweiten Speicherebene, die dauerhafter ist als die erste Speicherebene des virtuellen Speichersystems.
  • Aussage 2. Das Verfahren nach Aussage 1, wobei das Migrieren des mindestens einen Teils der im Staging-Speicher gespeicherten Daten auf das Erkennen einer Bedingung für die Übertragung von Daten zwischen dem Staging-Speicher und dem vom Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher reagiert.
  • Aussage 3. Das Verfahren nach Aussage 2 oder Aussage 1, wobei der Staging-Speicher mehrere virtuelle Laufwerksserver enthält.
  • Aussage 4. Das Verfahren nach Aussage 3, Aussage 2 oder Aussage 1, wobei die mehreren virtuellen Laufwerksserver jeweils einen lokalen Speicher enthalten.
  • Aussage 5. Das Verfahren nach Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die mehreren virtuellen Laufwerksserver virtuelle Laufwerke als blockartige Datenspeicher bereitstellen.
  • Aussage 6. Das Verfahren nach Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die Anforderung, Daten in das virtuelle Speichersystem zu schreiben, von einem oder mehreren virtuellen Controllern empfangen wird, die in einer virtuellen Maschine, einem Container oder einem Bare-Metal-Server laufen.
  • Aussage 7. Das Verfahren nach Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei der Staging-Speicher durch mehrere virtuelle Laufwerksserver bereitgestellt wird, die jeweils sowohl einen virtuellen Controller als auch einen lokalen Speicher enthalten.
  • Aussage 8. Das Verfahren nach Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei zumindest der Teil der im Staging-Speicher gespeicherten Daten vor der Migration vom Staging-Speicher zum dauerhaften Datenspeicher dedupliziert, verschlüsselt oder komprimiert wird.
  • Aussage 9. Das Verfahren nach Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei der Staging-Speicher des virtuellen Speichersystems durch eine niedrige Leselatenz im Vergleich zu dem vom Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher gekennzeichnet ist.
  • Aussage 10. Das Verfahren nach Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die erste Speicherebene einen Staging-Speicher enthält, der Transaktionskonsistenz und Schreibbestätigungen bereitstellt, und wobei die zweite Speicherebene virtuelle Laufwerke enthält, die von virtuellen Laufwerksservern des virtuellen Speichersystems bereitgestellt werden.
  • Aussage 11. Das Verfahren nach Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die erste Speicherebene die virtuellen Laufwerke umfasst, die von virtuellen Laufwerksservern des virtuellen Speichersystems bereitgestellt werden, und wobei die zweite Speicherebene Objektspeicher umfasst, der von einem Cloud-Service-Anbieter bereitgestellt wird, welcher Objektspeicher unabhängig von dem virtuellen Speichersystem bereitstellt.
  • Vorteile und Merkmale der vorliegenden Offenbarung können durch die folgenden Aussagen weiter beschrieben werden:
    • Aussage 1. Ein virtuelles Speichersystem, das in einer Cloud-Computing-Umgebung enthalten ist, wobei das cloudbasierte Speichersystem Folgendes umfasst: ein oder mehrere virtuelle Laufwerke, die einen Staging-Speicher für Speicheroperationen bereitstellen; und eine oder mehrere virtuelle Steuerungen, wobei jede virtuelle Steuerung in einer Cloud-Computing-Instanz ausgeführt wird, wobei die eine oder die mehreren virtuellen Steuerungen konfiguriert sind zum: Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; Speichern der Daten in einem von einer ersten Speicherebene des virtuellen Speichersystems bereitgestellten Speicher; und Migrieren mindestens eines Teils der in dem Staging-Speicher gespeicherten Daten von der ersten Speicherebene zu einer zweiten Speicherebene, die dauerhafter ist als die erste Speicherebene des virtuellen Speichersystems.
    • Aussage 2. Das virtuelle Speichersystem nach Aussage 1, wobei der lokale Speicher für ein gegebenes virtuelles Laufwerk mit einem oder mehreren anderen virtuellen Laufwerken verbunden ist.
    • Aussage 3. Das virtuelle Speichersystem nach Aussage 2 oder Aussage 1, wobei sich eine erste Untergruppe von virtuellen Controllern in einer ersten Verfügbarkeitszone befindet und wobei sich eine zweite Untergruppe von virtuellen Controllern in einer zweiten Verfügbarkeitszone befindet.
    • Aussage 4. Das virtuelle Speichersystem nach Aussage 3, Aussage 2 oder Aussage 1, wobei sich eine erste Teilmenge virtueller Laufwerke in einer ersten Verfügbarkeitszone befindet und wobei sich eine zweite Teilmenge virtueller Laufwerke in einer zweiten Verfügbarkeitszone befindet.
    • Aussage 5. Das virtuelle Speichersystem nach Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei sowohl die erste Teilmenge virtueller Laufwerke in der ersten Verfügbarkeitszone als auch die zweite Teilmenge virtueller Laufwerke in der zweiten Verfügbarkeitszone denselben cloudbasierten Objektspeicher verwenden.
    • Aussage 6. Das virtuelle Speichersystem nach Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das Migrieren des mindestens einen Teils der im Staging-Speicher gespeicherten Daten auf das Erkennen einer Bedingung für die Übertragung von Daten zwischen dem Staging-Speicher und dem vom Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher reagiert.
    • Aussage 7. Das virtuelle Speichersystem nach Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei der Staging-Speicher mehrere virtuelle Laufwerksserver enthält.
    • Aussage 8. Das virtuelle Speichersystem nach Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die jeweiligen virtuellen Laufwerke sowohl einen jeweiligen virtuellen Controller als auch jeweiligen lokalen Speicher umfassen.
    • Aussage 9. Das virtuelle Speichersystem nach Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei der Staging-Speicher durch mehrere virtuelle Laufwerksserver bereitgestellt wird, die jeweils sowohl einen virtuellen Controller als auch einen lokalen Speicher enthalten.
    • Aussage 10. Das virtuelle Speichersystem nach Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das virtuelle Speichersystem die Daten synchron mit einem oder mehreren anderen virtuellen Speichersystemen repliziert.
    • Aussage 11. Das virtuelle Speichersystem nach Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei sich eine virtuelle Speichersystemarchitektur, die das virtuelle Speichersystem implementiert, von einer virtuellen Speichersystemarchitektur unterscheidet, die mindestens ein virtuelles Speichersystem unter einem oder mehreren anderen virtuellen Speichersystemen implementiert.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • WO 16/524861 [0328]

Claims (20)

  1. Verfahren zum Bedienen von E/A-Operationen in einem virtuellen Speichersystem, wobei das Verfahren Folgendes umfasst: Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; Speichern der Daten in einem von einer ersten Speicherebene des virtuellen Speichersystems bereitgestellten Speicher; und Migrieren mindestens eines Teils der in der ersten Speicherebene gespeicherten Daten von der ersten Speicherebene zu einer zweiten Speicherebene, die dauerhafter ist als die erste Speicherebene des virtuellen Speichersystems.
  2. Verfahren nach Anspruch 1, wobei die erste Speicherebene einen Staging-Speicher einschließt, der Transaktionskonsistenz und Schreibbestätigungen bereitstellt, und wobei die zweite Speicherebene virtuelle Laufwerke einschließt, die von virtuellen Laufwerksservern des virtuellen Speichersystems bereitgestellt werden.
  3. Verfahren nach Anspruch 1, wobei die erste Speicherebene die virtuellen Laufwerke einschließt, die von virtuellen Laufwerksservern des virtuellen Speichersystems bereitgestellt werden, und wobei die zweite Speicherebene Objektspeicher einschließt, der von einem Cloud-Service-Anbieter bereitgestellt wird, der Objektspeicher unabhängig von dem virtuellen Speichersystem bereitstellt.
  4. Verfahren nach Anspruch 2, wobei das Migrieren des mindestens in dem Staging-Speicher gespeicherten Teils der Daten auf das Erkennen einer Bedingung für die Übertragung von Daten zwischen dem Staging-Speicher und dem vom Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher reagiert.
  5. Verfahren nach Anspruch 2, wobei der Staging-Speicher mehrere virtuelle Laufwerke einschließt, die von virtuellen Laufwerksservern bereitgestellt werden.
  6. Verfahren nach Anspruch 5, wobei die mehreren virtuellen Laufwerksserver jeweils einen lokalen Speicher einschließen.
  7. Verfahren nach Anspruch 5, wobei die mehreren virtuellen Laufwerksserver virtuelle Laufwerke als blockartige Datenspeicher bereitstellen.
  8. Verfahren nach Anspruch 1, wobei die Anforderung, Daten in das virtuelle Speichersystem zu schreiben, von einem oder mehreren virtuellen Controllern empfangen wird, die in einer virtuellen Maschine, einem Container oder einem Bare-Metal-Server laufen.
  9. Verfahren nach Anspruch 2, wobei der Staging-Speicher durch mehrere virtuelle Laufwerksserver bereitgestellt wird, die jeweils sowohl einen virtuellen Controller als auch einen lokalen Speicher enthalten.
  10. Verfahren nach Anspruch 2, wobei zumindest der Teil der im Staging-Speicher gespeicherten Daten vor der Migration vom Staging-Speicher zum dauerhaften Datenspeicher dedupliziert, verschlüsselt oder komprimiert wird.
  11. Verfahren nach Anspruch 2, wobei der Staging-Speicher des virtuellen Speichersystems durch eine niedrige Leselatenz im Vergleich zu dem vom Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher gekennzeichnet ist.
  12. Virtuelles Speichersystem, das in einer Cloud-Computing-Umgebung enthalten ist, wobei das cloudbasierte Speichersystem umfasst: ein oder mehrere virtuelle Laufwerke, die einen Staging-Speicher für Speicheroperationen bereitstellen; und eine oder mehrere virtuelle Steuerungen, wobei jede virtuelle Steuerung in einer Cloud-Computing-Instanz ausgeführt wird, wobei die eine oder mehreren virtuellen Steuerungen konfiguriert sind zum: Empfangen einer Anforderung zum Schreiben von Daten in das virtuelle Speichersystem durch das virtuelle Speichersystem; Speichern der Daten im Staging-Speicher, der von einem oder mehreren virtuellen Laufwerken des virtuellen Speichersystems bereitgestellt wird; und Migrieren mindestens eines Teils der im Staging-Speicher gespeicherten Daten aus dem Staging-Speicher in einen dauerhafteren Datenspeicher, der von einem Cloud-Service-Anbieter bereitgestellt wird.
  13. Virtuelles Speichersystem nach Anspruch 12, wobei der lokale Speicher für einen bestimmten virtuellen Laufwerksserver einem oder mehreren virtuellen Laufwerken bereitgestellt wird.
  14. Virtuelles Speichersystem nach Anspruch 12, wobei sich eine erste Untergruppe von virtuellen Controllern in einer ersten Verfügbarkeitszone befindet und wobei sich eine zweite Untergruppe von virtuellen Controllern in einer zweiten Verfügbarkeitszone befindet.
  15. Virtuelles Speichersystem nach Anspruch 12, wobei sich eine erste Teilmenge virtueller Laufwerke in einer ersten Verfügbarkeitszone und eine zweite Teilmenge virtueller Laufwerke in einer zweiten Verfügbarkeitszone befindet.
  16. Virtuelles Speichersystem nach Anspruch 15, wobei sowohl die erste Teilmenge virtueller Laufwerke in der ersten Verfügbarkeitszone als auch die zweite Teilmenge virtueller Laufwerke in der zweiten Verfügbarkeitszone denselben cloudbasierten Objektspeicher verwenden, und wobei die erste Teilmenge virtueller Laufwerke in der ersten Verfügbarkeitszone und die zweite Teilmenge virtueller Laufwerke in der zweiten Verfügbarkeitszone sich koordinieren, um replizierte Daten synchron zu speichern, anstatt unabhängige Datensätze zu speichern.
  17. Virtuelles Speichersystem nach Anspruch 14, wobei das Migrieren des mindestens einen Teils der im Staging-Speicher gespeicherten Daten auf das Erkennen einer Bedingung für die Übertragung von Daten zwischen dem Staging-Speicher und dem von dem Cloud-Service-Anbieter bereitgestellten dauerhaften Datenspeicher reagiert.
  18. Virtuelles Speichersystem nach Anspruch 12, wobei der Staging-Speicher mehrere virtuelle Laufwerksserver enthält.
  19. Virtuelles Speichersystem nach Anspruch 12, wobei die jeweiligen virtuellen Laufwerke sowohl einen jeweiligen virtuellen Controller als auch einen jeweiligen lokalen Speicher umfassen.
  20. Virtuelles Speichersystem nach Anspruch 12, wobei der Staging-Speicher durch mehrere virtuelle Laufwerksserver bereitgestellt wird, die jeweils sowohl einen virtuellen Controller als auch einen lokalen Speicher enthalten.
DE112020003423.2T 2019-07-18 2020-04-28 Architektur von virtuellem speichersystem Pending DE112020003423T5 (de)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201962875947P 2019-07-18 2019-07-18
US62/875,947 2019-07-18
US201962878877P 2019-07-26 2019-07-26
US62/878,877 2019-07-26
US201962900998P 2019-09-16 2019-09-16
US62/900,998 2019-09-16
US202062967368P 2020-01-29 2020-01-29
US62/967,368 2020-01-29
US16/777,211 US11126364B2 (en) 2019-07-18 2020-01-30 Virtual storage system architecture
US16/777,211 2020-01-30
PCT/US2020/030261 WO2021011050A1 (en) 2019-07-18 2020-04-28 Virtual storage system architecture

Publications (1)

Publication Number Publication Date
DE112020003423T5 true DE112020003423T5 (de) 2022-03-31

Family

ID=70847503

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020003423.2T Pending DE112020003423T5 (de) 2019-07-18 2020-04-28 Architektur von virtuellem speichersystem

Country Status (4)

Country Link
US (1) US11126364B2 (de)
CN (1) CN114041112A (de)
DE (1) DE112020003423T5 (de)
WO (1) WO2021011050A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230099538A1 (en) * 2021-09-27 2023-03-30 International Business Machines Corporation Private ledger partitions in blockchain networks

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11327676B1 (en) 2019-07-18 2022-05-10 Pure Storage, Inc. Predictive data streaming in a virtual storage system
US11853266B2 (en) 2019-05-15 2023-12-26 Pure Storage, Inc. Providing a file system in a cloud environment
CA3203827A1 (en) 2020-12-30 2022-07-07 Jose R. ROSAS BUSTOS Systems and methods of creating and operating a cloudless infrastructure of computing devices
US11449625B2 (en) * 2021-01-18 2022-09-20 Vmware, Inc. Optimized directory enumeration and data copy for client drive redirection in virtual desktops
US11853285B1 (en) * 2021-01-22 2023-12-26 Pure Storage, Inc. Blockchain logging of volume-level events in a storage system
CN113037824B (zh) * 2021-03-02 2022-04-08 山东大学 一种面向云计算的高性能区块链的构建方法
WO2022240950A1 (en) * 2021-05-12 2022-11-17 Pure Storage, Inc. Role enforcement for storage-as-a-service
US20220365827A1 (en) 2021-05-12 2022-11-17 Pure Storage, Inc. Rebalancing In A Fleet Of Storage Systems Using Data Science
US11467776B1 (en) 2021-06-28 2022-10-11 H3 Platform Inc. System supporting virtualization of SR-IOV capable devices
US11880605B2 (en) * 2022-02-15 2024-01-23 Netapp, Inc. Managing ephemeral storage of a virtual machine to provide victim caches for use by virtual storage appliances in a cloud environment
CN114225385B (zh) * 2022-02-25 2022-07-08 腾讯科技（深圳）有限公司 云游戏数据处理方法、装置、设备及存储介质
US11695853B1 (en) 2022-04-07 2023-07-04 T-Mobile Usa, Inc. Content management systems providing zero recovery point objective
CN114647388B (zh) * 2022-05-24 2022-08-12 杭州优云科技有限公司 一种分布式块存储系统和管理方法
US20230385730A1 (en) * 2022-05-24 2023-11-30 Red Hat, Inc. Segmenting processes into stand-alone services
CN116155594B (zh) * 2023-02-21 2023-07-14 北京志凌海纳科技有限公司 一种网络异常节点的隔离方法及系统

Family Cites Families (161)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5651133A (en) 1995-02-01 1997-07-22 Hewlett-Packard Company Methods for avoiding over-commitment of virtual capacity in a redundant hierarchic data storage system
JPH08242229A (ja) 1995-03-01 1996-09-17 Fujitsu Ltd ネットワーク監視における状態整合処理システム
US5799200A (en) 1995-09-28 1998-08-25 Emc Corporation Power failure responsive apparatus and method having a shadow dram, a flash ROM, an auxiliary battery, and a controller
US6012032A (en) 1995-11-30 2000-01-04 Electronic Data Systems Corporation System and method for accounting of computer data storage utilization
US5933598A (en) 1996-07-17 1999-08-03 Digital Equipment Corporation Method for sharing variable-grained memory of workstations by sending particular block including line and size of the block to exchange shared data structures
US6085333A (en) 1997-12-19 2000-07-04 Lsi Logic Corporation Method and apparatus for synchronization of code in redundant controllers in a swappable environment
US6647514B1 (en) 2000-03-23 2003-11-11 Hewlett-Packard Development Company, L.P. Host I/O performance and availability of a storage array during rebuild by prioritizing I/O request
US6643641B1 (en) 2000-04-27 2003-11-04 Russell Snyder Web search engine with graphic snapshots
JP2002041305A (ja) 2000-07-26 2002-02-08 Hitachi Ltd 仮想計算機システムにおける計算機資源の割当て方法および仮想計算機システム
US6789162B1 (en) 2000-10-17 2004-09-07 Sun Microsystems, Inc. Storage controller configured to select unused regions of a storage device for data storage according to head position
US6857045B2 (en) 2002-01-25 2005-02-15 International Business Machines Corporation Method and system for updating data in a compressed read cache
US6728738B2 (en) 2002-04-03 2004-04-27 Sun Microsystems, Inc. Fast lifetime analysis of objects in a garbage-collected system
US6895464B2 (en) 2002-06-03 2005-05-17 Honeywell International Inc. Flash memory management system and method utilizing multiple block list windows
US7334124B2 (en) 2002-07-22 2008-02-19 Vormetric, Inc. Logical access block processing protocol for transparent secure file storage
US7146521B1 (en) 2002-08-21 2006-12-05 3Pardata, Inc. Preventing damage of storage devices and data loss in a data storage system
EP1533702A4 (de) 2002-08-29 2007-05-23 Matsushita Electric Ind Co Ltd Halbleiterspeicherbaustein und verfahren zum schreiben von daten in flash-speicher
US6831865B2 (en) 2002-10-28 2004-12-14 Sandisk Corporation Maintaining erase counts in non-volatile storage systems
US20040153844A1 (en) 2002-10-28 2004-08-05 Gautam Ghose Failure analysis method and system for storage area networks
US7072905B2 (en) 2002-12-06 2006-07-04 Sun Microsystems, Inc. Better placement of objects reachable from outside a generation managed by the train algorithm
US7181580B2 (en) 2003-03-27 2007-02-20 International Business Machines Corporation Secure pointers
US7809252B2 (en) 2003-04-09 2010-10-05 Corel Inc. Systems and methods for caching multimedia data
US7437530B1 (en) 2003-04-24 2008-10-14 Network Appliance, Inc. System and method for mapping file block numbers to logical block addresses
US7434097B2 (en) 2003-06-05 2008-10-07 Copan System, Inc. Method and apparatus for efficient fault-tolerant disk drive replacement in raid storage systems
US7089272B1 (en) 2003-06-18 2006-08-08 Sun Microsystems, Inc. Specializing write-barriers for objects in a garbage collected heap
US7434214B2 (en) 2004-01-21 2008-10-07 International Business Machines Corporation Method for determining a close approximate benefit of reducing memory footprint of a Java application
US20050188246A1 (en) 2004-02-25 2005-08-25 Emberty Robert G. Persistent worldwide names assigned to removable media storage
US7526684B2 (en) 2004-03-24 2009-04-28 Seagate Technology Llc Deterministic preventive recovery from a predicted failure in a distributed storage system
US7493424B1 (en) 2004-04-30 2009-02-17 Netapp, Inc. Network storage system with shared software stack for LDMA and RDMA
JP4392601B2 (ja) 2004-05-07 2010-01-06 パナソニック株式会社 データアクセス装置および記録媒体
US8042163B1 (en) 2004-05-20 2011-10-18 Symatec Operating Corporation Secure storage access using third party capability tokens
US7441096B2 (en) * 2004-07-07 2008-10-21 Hitachi, Ltd. Hierarchical storage management system
US7533292B2 (en) 2004-07-15 2009-05-12 International Business Machines Corporation Management method for spare disk drives in a raid system
EP1829332A2 (de) 2004-12-15 2007-09-05 Exostar Corporation Vertrauensermöglichung bei einer föderierten kollaboration von netzwerken
US7426623B2 (en) 2005-01-14 2008-09-16 Sandisk Il Ltd System and method for configuring flash memory partitions as super-units
US20060230245A1 (en) 2005-04-08 2006-10-12 Microsoft Corporation Data storage safety indicator and expander
US8200887B2 (en) 2007-03-29 2012-06-12 Violin Memory, Inc. Memory management system and method
US7689609B2 (en) 2005-04-25 2010-03-30 Netapp, Inc. Architecture for supporting sparse volumes
US7366825B2 (en) 2005-04-26 2008-04-29 Microsoft Corporation NAND flash memory management
GB0514529D0 (en) 2005-07-15 2005-08-24 Ibm Virtualisation engine and method, system, and computer program product for managing the storage of data
JP4506594B2 (ja) 2005-07-22 2010-07-21 日本電気株式会社 冗長パス制御方法
US7694082B2 (en) 2005-07-29 2010-04-06 International Business Machines Corporation Computer program and method for managing resources in a distributed storage system
US7617216B2 (en) 2005-09-07 2009-11-10 Emc Corporation Metadata offload for a file server cluster
ITVA20050061A1 (it) 2005-11-08 2007-05-09 St Microelectronics Srl Metodo di gestione di un dispositivo di memoria non volatile e relativa memoria
US7831783B2 (en) 2005-12-22 2010-11-09 Honeywell International Inc. Effective wear-leveling and concurrent reclamation method for embedded linear flash file systems
US7421552B2 (en) 2006-03-17 2008-09-02 Emc Corporation Techniques for managing data within a data storage system utilizing a flash-based memory vault
US7899780B1 (en) 2006-03-30 2011-03-01 Emc Corporation Methods and apparatus for structured partitioning of management information
US20070294564A1 (en) 2006-04-27 2007-12-20 Tim Reddin High availability storage system
US8266472B2 (en) 2006-05-03 2012-09-11 Cisco Technology, Inc. Method and system to provide high availability of shared data
US9455955B2 (en) 2006-05-17 2016-09-27 Richard Fetik Customizable storage controller with integrated F+ storage firewall protection
US7743239B2 (en) 2006-06-30 2010-06-22 Intel Corporation Accelerating integrity checks of code and data stored in non-volatile memory
US7627786B2 (en) 2006-09-26 2009-12-01 International Business Machines Corporation Tracking error events relating to data storage drives and/or media of automated data storage library subsystems
US8620970B2 (en) 2006-10-03 2013-12-31 Network Appliance, Inc. Methods and apparatus for changing versions of a filesystem
US7669029B1 (en) 2006-11-15 2010-02-23 Network Appliance, Inc. Load balancing a data storage system
US7710777B1 (en) 2006-12-20 2010-05-04 Marvell International Ltd. Semi-volatile NAND flash memory
US7640332B2 (en) 2006-12-27 2009-12-29 Hewlett-Packard Development Company, L.P. System and method for hot deployment/redeployment in grid computing environment
KR100923990B1 (ko) 2007-02-13 2009-10-28 삼성전자주식회사 플래시 저장 장치의 특성을 기반으로 한 컴퓨팅 시스템
US9632870B2 (en) 2007-03-29 2017-04-25 Violin Memory, Inc. Memory system with multiple striping of raid groups and method for performing the same
US7996599B2 (en) 2007-04-25 2011-08-09 Apple Inc. Command resequencing in memory operations
US7991942B2 (en) 2007-05-09 2011-08-02 Stmicroelectronics S.R.L. Memory block compaction method, circuit, and system in storage devices based on flash memories
US7870360B2 (en) 2007-09-14 2011-01-11 International Business Machines Corporation Storage area network (SAN) forecasting in a heterogeneous environment
KR101433859B1 (ko) 2007-10-12 2014-08-27 삼성전자주식회사 불휘발성 메모리 시스템 및 그것의 파일 데이터 관리 방법
US8271700B1 (en) 2007-11-23 2012-09-18 Pmc-Sierra Us, Inc. Logical address direct memory access with multiple concurrent physical ports and internal switching
US7743191B1 (en) 2007-12-20 2010-06-22 Pmc-Sierra, Inc. On-chip shared memory based device architecture
JP4471007B2 (ja) 2008-02-05 2010-06-02 ソニー株式会社 記録装置、記録装置の制御方法、記録装置の制御方法のプログラム及び記録装置の制御方法のプログラムを記録した記録媒体
US8949863B1 (en) 2008-04-30 2015-02-03 Netapp, Inc. Creating environmental snapshots of storage device failure events
US8093868B2 (en) 2008-09-04 2012-01-10 International Business Machines Corporation In situ verification of capacitive power support
US8086585B1 (en) 2008-09-30 2011-12-27 Emc Corporation Access control to block storage devices for a shared disk based file system
US9473419B2 (en) 2008-12-22 2016-10-18 Ctera Networks, Ltd. Multi-tenant cloud storage system
US8762642B2 (en) 2009-01-30 2014-06-24 Twinstrata Inc System and method for secure and reliable multi-cloud data replication
JP4844639B2 (ja) 2009-02-19 2011-12-28 Ｔｄｋ株式会社 メモリコントローラ及びメモリコントローラを備えるフラッシュメモリシステム、並びにフラッシュメモリの制御方法
US9134922B2 (en) 2009-03-12 2015-09-15 Vmware, Inc. System and method for allocating datastores for virtual machines
KR101586047B1 (ko) 2009-03-25 2016-01-18 삼성전자주식회사 불휘발성 메모리 장치 및 그것의 프로그램 방법
US8805953B2 (en) 2009-04-03 2014-08-12 Microsoft Corporation Differential file and system restores from peers and the cloud
TWI408689B (zh) 2009-04-14 2013-09-11 Jmicron Technology Corp 存取儲存裝置的方法及相關控制電路
JP4874368B2 (ja) 2009-06-22 2012-02-15 株式会社日立製作所 フラッシュメモリを用いたストレージシステムの管理方法及び計算機
US7948798B1 (en) 2009-07-22 2011-05-24 Marvell International Ltd. Mixed multi-level cell and single level cell storage device
US8402242B2 (en) 2009-07-29 2013-03-19 International Business Machines Corporation Write-erase endurance lifetime of memory storage devices
US8868957B2 (en) 2009-09-24 2014-10-21 Xyratex Technology Limited Auxiliary power supply, a method of providing power to a data storage system and a back-up power supply charging circuit
TWI428917B (zh) 2009-11-25 2014-03-01 Silicon Motion Inc 快閃記憶裝置、資料儲存系統、以及資料儲存系統之運作方法
US8250324B2 (en) 2009-11-30 2012-08-21 International Business Machines Corporation Method to efficiently locate meta-data structures on a flash-based storage device
US8387136B2 (en) 2010-01-05 2013-02-26 Red Hat, Inc. Role-based access control utilizing token profiles
US8452932B2 (en) 2010-01-06 2013-05-28 Storsimple, Inc. System and method for efficiently creating off-site data volume back-ups
US20120023144A1 (en) 2010-07-21 2012-01-26 Seagate Technology Llc Managing Wear in Flash Memory
US20120054264A1 (en) 2010-08-31 2012-03-01 International Business Machines Corporation Techniques for Migrating Active I/O Connections with Migrating Servers and Clients
US8566546B1 (en) 2010-09-27 2013-10-22 Emc Corporation Techniques for enforcing capacity restrictions of an allocation policy
US8775868B2 (en) 2010-09-28 2014-07-08 Pure Storage, Inc. Adaptive RAID for an SSD environment
US8949502B2 (en) 2010-11-18 2015-02-03 Nimble Storage, Inc. PCIe NVRAM card based on NVDIMM
US8812860B1 (en) 2010-12-03 2014-08-19 Symantec Corporation Systems and methods for protecting data stored on removable storage devices by requiring external user authentication
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
US8589723B2 (en) 2010-12-22 2013-11-19 Intel Corporation Method and apparatus to provide a high availability solid state drive
US8465332B2 (en) 2011-01-13 2013-06-18 Tyco Electronics Corporation Contact assembly for an electrical connector
US8578442B1 (en) 2011-03-11 2013-11-05 Symantec Corporation Enforcing consistent enterprise and cloud security profiles
US8738882B2 (en) 2011-06-03 2014-05-27 Apple Inc. Pre-organization of data
US8769622B2 (en) 2011-06-30 2014-07-01 International Business Machines Corporation Authentication and authorization methods for cloud computing security
US8751463B1 (en) 2011-06-30 2014-06-10 Emc Corporation Capacity forecasting for a deduplicating storage system
US9852017B2 (en) 2011-07-27 2017-12-26 International Business Machines Corporation Generating dispersed storage network event records
US8931041B1 (en) 2011-07-29 2015-01-06 Symantec Corporation Method and system for visibility and control over access transactions between clouds using resource authorization messages
US20130036272A1 (en) 2011-08-02 2013-02-07 Microsoft Corporation Storage engine node for cloud-based storage
US8527544B1 (en) 2011-08-11 2013-09-03 Pure Storage Inc. Garbage collection in a storage system
US9525900B2 (en) 2011-09-15 2016-12-20 Google Inc. Video management system
JP2013077278A (ja) 2011-09-16 2013-04-25 Toshiba Corp メモリ・デバイス
US9374356B2 (en) 2011-09-29 2016-06-21 Oracle International Corporation Mobile oauth service
EP2771802A4 (de) 2011-10-24 2016-05-25 Schneider Electric Ind Sas System und verfahren zur verwaltung industrieller prozesse
WO2013071087A1 (en) 2011-11-09 2013-05-16 Unisys Corporation Single sign on for cloud
US20130311434A1 (en) 2011-11-17 2013-11-21 Marc T. Jones Method, apparatus and system for data deduplication
US9330245B2 (en) 2011-12-01 2016-05-03 Dashlane SAS Cloud-based data backup and sync with secure local storage of access keys
US20130219164A1 (en) 2011-12-29 2013-08-22 Imation Corp. Cloud-based hardware security modules
US8613066B1 (en) 2011-12-30 2013-12-17 Amazon Technologies, Inc. Techniques for user authentication
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access
US9423983B2 (en) 2012-01-19 2016-08-23 Syncsort Incorporated Intelligent storage controller
US9116812B2 (en) 2012-01-27 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a de-duplication cache
JP2013161235A (ja) 2012-02-03 2013-08-19 Fujitsu Ltd ストレージ装置、ストレージ装置の制御方法及びストレージ装置の制御プログラム
US10474584B2 (en) 2012-04-30 2019-11-12 Hewlett Packard Enterprise Development Lp Storing cache metadata separately from integrated circuit containing cache controller
US8832372B2 (en) 2012-05-24 2014-09-09 Netapp, Inc. Network storage systems having clustered raids for improved redundancy and load balancing
WO2013188382A2 (en) 2012-06-12 2013-12-19 Centurylink Intellectual Property Llc High performance cloud storage
WO2014007516A1 (ko) 2012-07-02 2014-01-09 에스케이플래닛 주식회사 단일 인증 서비스 시스템 및 이의 운용 방법
US9047181B2 (en) 2012-09-07 2015-06-02 Splunk Inc. Visualization of data from clusters
US8769651B2 (en) 2012-09-19 2014-07-01 Secureauth Corporation Mobile multifactor single-sign-on authentication
WO2014051552A1 (en) 2012-09-25 2014-04-03 Empire Technology Development Llc Limiting data usage of a device connected to the internet via tethering
US9245144B2 (en) 2012-09-27 2016-01-26 Intel Corporation Secure data container for web applications
US8990905B1 (en) 2012-09-28 2015-03-24 Emc Corporation Protected resource access control utilizing intermediate values of a hash chain
US8990914B2 (en) 2012-09-28 2015-03-24 Intel Corporation Device, method, and system for augmented reality security
US8850546B1 (en) 2012-09-30 2014-09-30 Emc Corporation Privacy-preserving user attribute release and session management
US20140101434A1 (en) 2012-10-04 2014-04-10 Msi Security, Ltd. Cloud-based file distribution and management using real identity authentication
US9209973B2 (en) 2012-11-20 2015-12-08 Google Inc. Delegate authorization in cloud-based storage system
US8997197B2 (en) 2012-12-12 2015-03-31 Citrix Systems, Inc. Encryption-based data access management
US9317223B2 (en) 2012-12-17 2016-04-19 International Business Machines Corporation Method and apparatus for automated migration of data among storage centers
US9075529B2 (en) 2013-01-04 2015-07-07 International Business Machines Corporation Cloud based data migration and replication
US9646039B2 (en) 2013-01-10 2017-05-09 Pure Storage, Inc. Snapshots in a storage system
US9483657B2 (en) 2013-01-14 2016-11-01 Accenture Global Services Limited Secure online distributed data storage services
US9052917B2 (en) 2013-01-14 2015-06-09 Lenovo (Singapore) Pte. Ltd. Data storage for remote environment
US9009526B2 (en) 2013-01-24 2015-04-14 Hewlett-Packard Development Company, L.P. Rebuilding drive data
US20140229654A1 (en) 2013-02-08 2014-08-14 Seagate Technology Llc Garbage Collection with Demotion of Valid Data to a Lower Memory Tier
US20140230017A1 (en) 2013-02-12 2014-08-14 Appsense Limited Programmable security token
US8902532B2 (en) 2013-03-20 2014-12-02 International Business Machines Corporation Write avoidance areas around bad blocks on a hard disk drive platter
GB2513377A (en) 2013-04-25 2014-10-29 Ibm Controlling data storage in an array of storage devices
US9317382B2 (en) 2013-05-21 2016-04-19 International Business Machines Corporation Storage device with error recovery indication
US10038726B2 (en) 2013-06-12 2018-07-31 Visa International Service Association Data sensitivity based authentication and authorization
US9124569B2 (en) 2013-06-14 2015-09-01 Microsoft Technology Licensing, Llc User authentication in a cloud environment
US8898346B1 (en) 2013-06-20 2014-11-25 Qlogic, Corporation Method and system for configuring network devices
US8984602B1 (en) 2013-06-28 2015-03-17 Emc Corporation Protected resource access control utilizing credentials based on message authentication codes and hash chain values
US9454423B2 (en) 2013-09-11 2016-09-27 Dell Products, Lp SAN performance analysis tool
US9577953B2 (en) 2013-09-27 2017-02-21 Intel Corporation Determination of a suitable target for an initiator by a control plane processor
US9442662B2 (en) 2013-10-18 2016-09-13 Sandisk Technologies Llc Device and method for managing die groups
US9519580B2 (en) 2013-11-11 2016-12-13 Globalfoundries Inc. Load balancing logical units in an active/passive storage system
US9619311B2 (en) 2013-11-26 2017-04-11 International Business Machines Corporation Error identification and handling in storage area networks
US9529546B2 (en) 2014-01-08 2016-12-27 Netapp, Inc. Global in-line extent-based deduplication
US9250823B1 (en) 2014-05-20 2016-02-02 Emc Corporation Online replacement of physical storage in a virtual storage system
CN105830166B (zh) 2014-06-27 2018-02-23 华为技术有限公司 一种控制器、闪存装置和将数据写入闪存装置的方法
US9516167B2 (en) 2014-07-24 2016-12-06 Genesys Telecommunications Laboratories, Inc. Media channel management apparatus for network communications sessions
US10204010B2 (en) 2014-10-03 2019-02-12 Commvault Systems, Inc. Intelligent protection of off-line mail data
US9716755B2 (en) 2015-05-26 2017-07-25 Pure Storage, Inc. Providing cloud storage array services by a local storage array in a data center
US9521200B1 (en) 2015-05-26 2016-12-13 Pure Storage, Inc. Locally providing cloud storage array services
US9300660B1 (en) 2015-05-29 2016-03-29 Pure Storage, Inc. Providing authorization and authentication in a cloud for a user of a storage array
US20160350009A1 (en) 2015-05-29 2016-12-01 Pure Storage, Inc. Buffering data to be written to an array of non-volatile storage devices
US10021170B2 (en) 2015-05-29 2018-07-10 Pure Storage, Inc. Managing a storage array using client-side services
US9444822B1 (en) 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US9507532B1 (en) 2016-05-20 2016-11-29 Pure Storage, Inc. Migrating data in a storage array that includes a plurality of storage devices and a plurality of write buffer devices
US10191916B1 (en) 2016-06-17 2019-01-29 EMC IP Holding Company LLC Storage system comprising cluster file system storage nodes and software-defined storage pool in cloud infrastructure
US10459657B2 (en) 2016-09-16 2019-10-29 Hewlett Packard Enterprise Development Lp Storage system with read cache-on-write buffer
US20200272444A1 (en) 2019-02-22 2020-08-27 International Business Machines Corporation Placement of explicit preemption points into compiled code

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230099538A1 (en) * 2021-09-27 2023-03-30 International Business Machines Corporation Private ledger partitions in blockchain networks
US11968307B2 (en) * 2021-09-27 2024-04-23 International Bisuness Machines Corporation Private ledger partitions in blockchain networks

Also Published As

Publication number Publication date
US20210019070A1 (en) 2021-01-21
WO2021011050A1 (en) 2021-01-21
CN114041112A (zh) 2022-02-11
US11126364B2 (en) 2021-09-21

Similar Documents

Publication Publication Date Title
US11093139B1 (en) Durably storing data within a virtual storage system
US11550514B2 (en) Efficient transfers between tiers of a virtual storage system
US11526408B2 (en) Data recovery in a virtual storage system
US11663097B2 (en) Mirroring data to survive storage device failures
US11797569B2 (en) Configurable data replication
DE112020003423T5 (de) Architektur von virtuellem speichersystem
US20220035714A1 (en) Managing Disaster Recovery To Cloud Computing Environment
US20220083245A1 (en) Declarative provisioning of storage
DE112019005770T5 (de) Speicherverwaltung für ein cloudbasiertes Speichersystem
US11360689B1 (en) Cloning a tracking copy of replica data
DE112019000841T5 (de) Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem
DE112019002609T5 (de) Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem
US20210019063A1 (en) Utilizing data views to optimize secure data access in a storage system
DE102021113808A1 (de) Handhabung von Replikationen zwischen verschiedenen Netzwerken
US11422751B2 (en) Creating a virtual storage system
DE112020003277T5 (de) Erzeugen von tags für die datenzuweisung
US20220075546A1 (en) Intelligent application placement in a hybrid infrastructure
US11442669B1 (en) Orchestrating a virtual storage system
US20220358019A1 (en) Initiating Recovery Actions When A Dataset Ceases To Be Synchronously Replicated Across A Set Of Storage Systems
US20230205591A1 (en) System Having Dynamic Power Management
WO2023070025A1 (en) Declarative provisioning of storage
US20220091744A1 (en) Optimized Application Agnostic Object Snapshot System
US20220091743A1 (en) Bucket versioning snapshots
WO2022081632A1 (en) Creating a virtual storage system

Legal Events

Date Code Title Description
R012 Request for examination validly filed