-
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 Anbieter von Cloud-Diensten 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 Datenverarbeitungsgerät, das speziell konfiguriert werden kann, um einen oder mehrere der hier beschriebenen Prozesse auszuführen.
- 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 zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht.
-
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
-
Beispielhafte Verfahren, Vorrichtungen und Produkte zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem 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 171 A-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 den Empfang 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 den Empfang 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 die Speicherung 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 die Speicherung 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 Computer System 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 der Bestimmung, 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-Identifikatoren 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 Identifikatoren 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 ein Identifikator 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 Identifikatoren 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 I/O-Port 210, der Controller 212, die DMA-Einheit 214 und der Flash-I/O-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 Anbieter von Cloud-Diensten 302 über die Datenkommunikationsverbindung 304 unter Verwendung eines oder mehrerer Datenkommunikationsprotokolle ausgetauscht werden. Beispielsweise können digitale Informationen zwischen dem Speichersystem 306 und dem Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 302 Recheninfrastruktur wie virtuelle Maschinen und andere Ressourcen als Dienst für Abonnenten anbietet. Darüber hinaus kann der Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 Anbieter von Cloud-Diensten 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 die Speicherung 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 Anbieter von Cloud-Diensten 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 Datensicherungsverfahren ausführen, durch die im Speichersystem gespeicherte Daten kopiert und an einem bestimmten Ort gespeichert werden können, um Datenverluste im Falle eines Geräteausfalls oder einer anderen Form der Katastrophe zu vermeiden. Beispielsweise können die vorstehend beschriebenen Speichersysteme so konfiguriert werden, dass sie jede Datensicherung untersuchen, um eine Wiederherstellung des Speichersystems in einen unerwünschten Zustand zu vermeiden. Betrachten wir ein Beispiel, bei dem Malware das Speichersystem infiziert. In einem solchen Beispiel kann das Speichersystem Software-Ressourcen 314 enthalten, die jedes Backup prüfen können, um Backups zu ermitteln, die erfasst wurden, bevor die Malware das Speichersystem infizierte, sowie jene Backups, die erfasst wurden, nachdem die Malware das Speichersystem infizierte. In einem solchen Beispiel kann sich das Speichersystem von einem Backup, das die Malware nicht enthält, selbst wiederherstellen - oder zumindest die Teile eines Backups, die die Malware enthielten, nicht wiederherstellen. In einem solchen Beispiel kann das Speichersystem Software-Ressourcen 314 enthalten, die jedes Backup scannen können, um das Vorhandensein von Malware (oder eines Virus oder eines anderen Unerwünschtem) zu ermitteln, z. B. durch Ermitteln von Schreibvorgängen, die vom Speichersystem bedient wurden und aus einem Netzwerk-Subnetz stammen, von dem vermutet wird, dass es die Malware geliefert hat, durch das Ermitteln von Schreibvorgängen, die vom Speichersystem bedient wurden und von einem Benutzer stammen, von dem vermutet wird, dass er Verursacher der Malware ist, durch das Ermitteln von Schreibvorgängen, die vom Speichersystem bedient wurden, und durch die Untersuchung des Inhalts des Schreibvorgangs anhand von Fingerabdrücken der Malware und auf viele andere Arten.
-
Für den Leser ist ferner zu erkennen, dass die Backups (oft in Form eines oder mehrerer Snapshots) auch zur schnellen Wiederherstellung des Speichersystems verwendet werden können. Betrachten wir ein Beispiel, bei dem das Speichersystem mit Ransomware infiziert ist, die Benutzer aus dem Speichersystem aussperrt. In einem solchen Beispiel können die Software-Ressourcen 314 innerhalb des Speichersystems so konfiguriert werden, dass sie das Vorhandensein von Ransomware erkennen und das Speichersystem unter Verwendung der zurückbehaltenen Backups zu einem Zeitpunkt vor dem Zeitpunkt, an dem die Ransomware das Speichersystem infiziert hat, wiederherstellen. In einem solchen Beispiel kann das Vorhandensein von Ransomware explizit durch die Verwendung von Software-Tools, die vom System verwendet werden, durch die Verwendung eines Schlüssels (z.B. eines USB-Laufwerks), der in das Speichersystem eingesteckt wird, oder auf ähnliche Weise erkannt werden. Ebenso kann auf das Vorhandensein von Ransomware als Reaktion auf eine Systemaktivität geschlossen werden, die auf einen vorbestimmten Fingerabdruck trifft, wie z.B. keine Lese- oder Schreibvorgänge, die für eine vorbestimmte Zeitspanne in das System gelangen.
-
Für den Leser ist zu erkennen, dass die verschiedenen in 3B dargestellten Komponenten zu einem oder mehreren optimierten Rechenpaketen als konvergierte Infrastrukturen gruppiert werden können. Solche konvergierten Infrastrukturen können Pools von Computern, Speicher- und Netzwerkressourcen umfassen, die von mehreren Anwendungen gemeinsam genutzt und mit Hilfe richtliniengesteuerter Prozesse 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 senken. Solche konvergierten Infrastrukturen können mit einer konvergierten Infrastruktur-Referenzarchitektur, mit eigenständigen Vorrichtungen, mit einem softwaregesteuerten hyperkonvergierten Ansatz (z.B. hyperkonvergierte Infrastrukturen) oder auf andere Weise implementiert werden.
-
Für den Leser ist zu erkennen, 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 zur Unterstützung von folgenden Anwendungen nützlich sein, durch die Bereitstellung von Speicherressourcen für solche Anwendungen: Anwendungen der künstlichen Intelligenz („Kl“), Datenbankanwendungen, DevOps-Projekten, Electronic Design Automation Tools, ereignisgesteuerten Softwareanwendungen, Hochleistungsrechneranwendungen, Simulationsanwendungen, Anwendungen für die Hochgeschwindigkeitsdatenerfassung und -analyse, Anwendungen für maschinelles Lernen, Anwendungen für die Medienproduktion, Anwendungen für die Medienbedienung, Anwendungen für Bildarchivierungs- und Kommunikationssysteme („PACS“), Anwendungen für die Softwareentwicklung, Anwendungen für Vitual Reality, Anwendungen für Augmented Reality und viele andere Arten von Anwendungen.
-
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, um ressourcenintensive Anwendungen wie z.B. KI-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 auf ein bestimmtes Ziel maximieren. Beispiele für solche Kl-Anwendungen können IBM Watson, Microsoft Oxford, Google DeepMind, Baidu Minwa und andere sein. Die vorstehend beschriebenen Speichersysteme können auch gut geeignet sein, um andere Arten von Anwendungen zu unterstützen, die ressourcenintensiv sind, wie z.B. Anwendungen für maschinelles Lernen. Anwendungen für maschinelles Lernen können verschiedene Arten der Datenanalyse durchführen, um die Erstellung analytischer Modelle zu automatisieren. Mithilfe von Algorithmen, die iterativ aus Daten lernen, können Anwendungen für maschinelles Lernen es Computern ermöglichen zu lernen, ohne explizit programmiert zu werden. Ein besonderer Bereich des maschinellen Lernens wird als „Reinforcement Learning“ bezeichnet, bei dem geeignete Maßnahmen ergriffen werden, um die Belohnung in einer bestimmten Situation zu maximieren. Reinforcement Learning kann eingesetzt werden, um das bestmögliche Verhalten oder den bestmöglichen Weg zu finden, den eine bestimmte Software-Anwendung oder Maschine in einer bestimmten Situation einschlagen sollte. Reinforcement Learning unterscheidet sich von anderen Bereichen des maschinellen Lernens (z.B. überwachtes Lernen, unüberwachtes Lernen) dadurch, dass beim Reinforcement Learning keine korrekten Input/Output-Paare vorgelegt werden müssen und suboptimale Aktionen nicht explizit korrigiert werden müssen.
-
Zusätzlich zu den bereits beschriebenen Ressourcen können die vorstehend beschriebenen Speichersysteme auch Grafikverarbeitungseinheiten („GPUs“) enthalten, die gelegentlich als Visual Processing Unit („VPUs“) bezeichnet werden. Solche GPUs können als spezialisierte elektronische Schaltungen verkörpert sein, die den Speicher schnell betätigen und verändern, um das Erzeugen von Bildern in einem für die Ausgabe auf einem Anzeigegerät bestimmten Bildpuffer zu beschleunigen. Solche GPUs können in jedem der Datenverarbeitungsgeräte enthalten sein, die Teil der vorstehend beschriebenen Speichersysteme sind, einschließlich als eine von vielen individuell skalierbaren Komponenten eines Speichersystems, wobei andere Beispiele für individuell skalierbare Komponenten eines solchen Speichersystems Speicherkomponenten, Arbeitsspeicherkomponenten, Rechenkomponenten (z.B. CPUs, FPGAs, ASICs), Netzwerkkomponenten, Softwarekomponenten und andere umfassen können. Zusätzlich zu GPUs können die vorstehend beschriebenen Speichersysteme auch neuronale Netzwerkprozessoren („NNPs“) zur Verwendung in verschiedenen Aspekten der Verarbeitung neuronaler Netzwerke umfassen. Solche NNPs können anstelle von (oder zusätzlich zu) GPUs verwendet werden und können auch unabhängig skalierbar sein.
-
Wie vorstehend beschrieben, können die hier beschriebenen Speichersysteme so konfiguriert werden, dass sie Anwendungen der künstlichen Intelligenz, Anwendungen des maschinellen Lernens, große Datenanalyseanwendungen und viele andere Arten von Anwendungen unterstützen. Die schnelle Zunahme dieser Art von Anwendungen wird durch drei Technologien angetrieben: Deep Learning (DL), GPU-Prozessoren und Big Data. Deep Learning ist ein Rechenmodell, das sehr stark parallele neuronale Netze nach dem Vorbild des menschlichen Gehirns nutzt. Anstatt dass Experten Software herstellen, schreibt ein Modell für Deep Learning seine eigene Software, indem es aus vielen Beispielen lernt. Ein Grafikprozessor (GPU) ist ein moderner Prozessor mit Tausenden von Kernen, der sich gut dazu eignet, Algorithmen auszuführen, die ungefähr die parallele Natur des menschlichen Gehirns darstellen.
-
Fortschritte in Deep Neural Networks haben eine neue Welle von Algorithmen und Tools ausgelöst, mit denen Datenwissenschaftler ihre Daten mit künstlicher Intelligenz (KI) erschließen können. Mit verbesserten Algorithmen, größeren Datensätzen und verschiedenen Frameworks (einschließlich Open-Source-Softwarebibtiotheken für maschinelles Lernen für eine Reihe von Aufgaben) befassen sich Datenwissenschaftler mit neuen Anwendungsfällen wie autonomes Fahren von Fahrzeugen, Verarbeiten und Verstehen natürlicher Sprache, Computervision, Machine Reasoning, starke KI und vielen anderen. Zu den Anwendungen solcher Verfahren können gehören: Erkennen, Ermitteln und Vermeiden von Maschinen- und Fahrzeugobjekten; visuelles Erkennen, Klassifizieren und Markieren; Leistungsmanagement algorithmischer finanzieller Handelsstrategien; gleichzeitige Lokalisierung und Kartierung; vorausschauende Handhabung hochwertiger Maschinen; Vorbeugung gegen Bedrohungen der Cybersicherheit, Automatisierung von Expertenwissen; Bilderkennung und Klassifizierung; Beantwortung von Fragen; Robotik; Textanalyse (Extraktion, Klassifizierung) und Texterzeugung und -übersetzung; und viele andere. Anwendungen von KI-Verfahren haben sich in einer Vielzahl von Produkten materialisiert, darunter z.B. die Spracherkennungstechnologie von Amazon Echo, die es Benutzern ermöglicht, mit ihren Maschinen zu sprechen, Google Translate™, die eine maschinengestützte Sprachübersetzung ermöglicht, Spotify's Discover Weekly, das auf der Grundlage der Nutzungs- und Verkehrsanalyse des Benutzers Empfehlungen zu neuen Liedern und Künstlern gibt, Quill's Textgenerierungsangebot, das strukturierte Daten in erzählerische Geschichten verwandelt, Chatbots, die in Echtzeit kontextspezifische Antworten auf Fragen in einem Dialogformat liefern, und viele andere. Darüber hinaus kann KI eine Vielzahl von Branchen und Sektoren beeinflussen. Beispielsweise können Kl-Lösungen im Gesundheitswesen eingesetzt werden, um klinische Notizen, Patientenakten, Forschungsdaten und andere Inputs zu erfassen, um potenzielle Behandlungsoptionen zu generieren, die Ärzte untersuchen können. Ebenso können KI-Lösungen von Einzelhändlern verwendet werden, um Verbraucherempfehlungen zu personalisieren, die auf dem digitalen Fußabdruck von Verhaltensweisen, Profildaten oder anderen Daten einer Person basieren.
-
Das Training von Deep Neural Networks erfordert jedoch sowohl qualitativ hochwertige Eingabedaten als auch große Berechnungsmengen. GPUs sind massiv-parallele Prozessoren, die in der Lage sind, große Datenmengen gleichzeitig zu verarbeiten. Wenn sie zu einem Multi-GPU-Cluster kombiniert werden, kann eine Pipeline mit hohem Durchsatz erforderlich sein, um die Eingabedaten aus dem Speicher den Rechenmaschinen zuzuführen. Deep Learning ist mehr als nur das Konstruieren und Trainieren von Modellen. Es gibt auch eine ganze Datenpipeline, die für den Umfang, die Iteration und das Experimentieren ausgelegt sein muss, die für den Erfolg eines datenwissenschaftlichen Teams erforderlich sind.
-
Daten sind das Herzstück moderner KI und Deep Learning - Algorithmen. Bevor mit dem Training begonnen werden kann, muss ein Problem gelöst werden, das sich um das Sammeln der gekennzeichneten Daten dreht, die für das Training eines genauen Kl-Modells entscheidend sind. Ein KI-Einsatz in vollem Umfang kann erforderlich sein, um kontinuierlich große Datenmengen zu sammeln, zu bereinigen, umzuwandeln, zu beschriften und zu speichern. Das Hinzufügen zusätzlicher Datenpunkte von hoher Qualität führt direkt zu genaueren Modellen und besseren Einblicken. Datenproben können einer Reihe von Verarbeitungsschritten unterzogen werden, einschließlich, aber nicht beschränkt auf 1) Aufnahme der Daten aus einer externen Quelle in das Trainings-System und Speicherung der Daten in Rohform, 2) Bereinigung und Transformation der Daten in ein für das Training geeignetes Format, einschließlich der Verknüpfung der Beispieldaten mit dem entsprechenden Label, 3) Untersuchung von Parametern und Modellen, schnelles Testen mit einem kleineren Datensatz und Iteration, um die vielversprechendsten Modelle zu konvergieren und in den Produktionscluster zu bringen, 4) Durchführung von Trainingsphasen zur Auswahl zufälliger Stapel von Eingabedaten, einschließlich neuer und älterer Beispieldaten, und Einspeisung dieser Daten in GPU-Produktionsserver zur Berechnung, um die Modellparameter zu aktualisieren, und 5) Auswertung, einschließlich der Verwendung eines zurückgehaltenen Teils der Daten, die nicht bei dem Training verwendet werden, um die Modellgenauigkeit bei den Holdout-Daten zu bewerten. Dieser Lebenszyklus kann für jede Art von parallelisiertem maschinellem Lernen gelten, nicht nur für neuronale Netze oder Deep Learning. Beispielsweise können sich standardmäßige Rahmen für maschinelles Lernen auf CPUs anstelle von GPUs stützen, aber die Dateneingabe und die Trainingsabläufe können dieselben sein. Für den Leser ist zu erkennen, dass eine einzige Daten-Drehscheibe mit gemeinsamem Speicher einen Koordinationspunkt während des gesamten Lebenszyklus schafft, ohne dass zusätzliche Datenkopien zwischen Aufnahme-, Vorverarbeitungs- und Trainingsphasen erforderlich sind. Seiten werden die aufgenommenen Daten nur für einen einzigen Zweck verwendet, und der gemeinsam genutzte Speicher bietet die Flexibilität, mehrere verschiedene Modelle zu trainieren oder herkömmliche Analyseverfahren auf die Daten anzuwenden.
-
Die Leser werden verstehen, dass jede Stufe in der Kl-Datenpipeline unterschiedliche Anforderungen an die Datendrehscheibe stellen kann (z. B. das Speichersystem oder die Sammlung von Speichersystemen). Scale-Out-Speichersysteme müssen kompromisslose Leistung für alle Arten von Zugriffstypen und -mustern bieten - von kleinen, Metadaten-lastigen bis hin zu großen Dateien, von zufälligen bis hin zu sequentiellen Zugriffsmustern und von geringer bis hin zu hoher Gleichzeitigkeit. Die vorstehend beschriebenen Speichersysteme können als ideale KI-Datendrehscheibe dienen, da die Systeme unstrukturierte Arbeitslasten unterstützen können. In der ersten Phase werden die Daten idealerweise auf derselben Datendrehscheibe gespeichert, die auch für die folgenden Phasen verwendet wird, um ein übermäßiges Kopieren von Daten zu vermeiden. Die nächsten beiden Schritte können auf einem Standard-Computer-Server durchgeführt werden, der optional einen Grafikprozessor (GPU) enthält, und dann werden in der vierten und letzten Stufe vollständige Trainings-Produktionsaufträge auf leistungsstarken GPU-beschleunigten Servern ausgeführt. Häufig gibt es eine Produktionspipeline neben einer experimentellen Pipeline, die auf demselben Datensatz arbeitet. Darüber hinaus können die GPU-beschleunigten Server unabhängig voneinander für verschiedene Modelle verwendet oder zum Training auf einem größeren Modell zusammengeschlossen werden, auch über mehrere Systeme hinweg für verteilte Trainings. Wenn die gemeinsam genutzte Speicherebene langsam ist, müssen die Daten für jede Phase in den lokalen Speicher kopiert werden, was zu Zeitverlusten bei der Bereitstellung der Daten auf verschiedenen Servern führt. Die ideale Datendrehscheibe für die Kl-Trainingspipeline liefert eine Leistung, die der von lokal auf dem Serverknoten gespeicherten Daten ähnelt, und verfügt gleichzeitig über die Einfachheit und Leistung, die es ermöglicht, alle Pipelinestufen gleichzeitig zu betreiben.
-
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 wird es Teams von Datenwissenschaftlern geben, die dieselben Datensätze gemeinsam nutzen und parallel an der Erstellung neuer und verbesserter Trainingsmodelle arbeiten. Häufig gibt es ein Team von Datenwissenschaftlern, die innerhalb dieser Phasen gleichzeitig an denselben gemeinsamen Datensätzen arbeiten. Mehrere, gleichzeitige Arbeitslasten der Datenverarbeitung, des Experimentierens und des umfassenden Trainings schichten die Anforderungen von Mehrfachzugriffsmustern auf der Speicherebene. Mit anderen Worten, die Speicherung kann nicht nur das Lesen großer Dateien erfüllen, sondern muss sich mit einer Mischung aus Lesen und Schreiben großer und kleiner Dateien auseinandersetzen. Wenn mehrere Datenwissenschaftler Datensätze und Modelle untersuchen, kann es schließlich entscheidend 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 vorstehend beschriebenen Speichersysteme können einen natürlichen gemeinsamen Speicherort für den Datensatz bereitstellen, mit Datensicherungsredundanz (z.B. durch Verwendung von RAID) und der Leistung, die erforderlich ist, um einen gemeinsamen Zugriffspunkt für mehrere Entwickler und mehrere Experimente darzustellen. Durch die Verwendung der vorstehend beschriebenen Speichersysteme kann die Notwendigkeit vermieden werden, Teilmengen der Daten für die lokale Arbeit sorgfältig zu kopieren, wodurch sowohl technische als auch GPUbeschleunigte Server Zeit sparen. Diese Kopien werden zu einer ständigen 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 Erfolg des Deep Learning die kontinuierliche Verbesserung von Modellen mit größeren Datensätzen ist. Im Gegensatz dazu hören klassische Algorithmen des maschinellen Lernens, wie die logistische Regression, bei kleineren Datensatzgrößen auf, sich in der Genauigkeit zu verbessern. Daher kann die Trennung von Rechen- und Speicherressourcen auch eine unabhängige Skalierung der einzelnen Ebenen ermöglichen, wodurch viele der Komplexitäten vermieden werden können, die bei der gemeinsamen Verwaltung von beiden auftreten. Wenn die Größe des Datensatzes wächst oder neue Datensätze in Betracht gezogen werden, muss ein Scale-Out-Speichersystem leicht erweiterbar sein. In ähnlicher Weise können, wenn mehr gleichzeitige Trainings erforderlich sind, zusätzliche GPUs oder andere Rechenressourcen hinzugefügt werden, ohne sich um deren internen Speicher zu kümmern. Darüber hinaus können die vorstehend beschriebenen Speichersysteme den Aufbau, den Betrieb und das Wachstum eines KI-Systems erleichtern, und zwar aufgrund der von den Speichersystemen bereitgestellten Bandbreite für zufälliges Lesen, der Fähigkeit der Speichersysteme, kleine Dateien (50 KB) mit hoher Rate zufällig zu lesen (d.h. es ist kein zusätzlicher Aufwand erforderlich, um einzelne Datenpunkte zu größeren, speicherfreundlichen Dateien zu aggregieren), der Fähigkeit der Speichersysteme, Kapazität und Leistung zu skalieren, wenn entweder der Datensatz wächst oder die Durchsatzanforderungen steigen, der Fähigkeit der Speichersysteme, Dateien oder Objekte zu unterstützen, der Fähigkeit der Speichersysteme, die Leistung für große oder kleine Dateien einzustellen (i.e., keine Notwendigkeit für den Benutzer, Dateisysteme bereitzustellen), die Fähigkeit der Speichersysteme, unterbrechungsfreie Upgrades von Hardware und Software sogar während des Produktionsmodell-Trainings zu unterstützen, und aus vielen anderen Gründen.
-
Die Leistung der Speicherebene für kleine Dateien kann entscheidend sein, da viele Arten von Eingaben, darunter Text, Audio oder Bilder, nativ als kleine Dateien gespeichert werden. Wenn die Speicherebene kleine Dateien nicht gut verarbeiten kann, ist ein zusätzlicher Schritt zur Vorverarbeitung und Gruppierung von Beispieldaten zu größeren Dateien erforderlich. Ein Speicher, der auf rotierenden Platten aufgebaut ist und auf SSD als eine Cache-Ebene basiert, kann die erforderliche Leistung unterschreiten. Da das Training mit zufälligen Eingabestapeln zu genaueren Modellen führt, muss der gesamte Datensatz mit voller Leistung zugänglich sein. SSD-Caches bieten nur für eine kleine Teilmenge der Daten eine hohe Leistung und können die Latenz von rotierenden Laufwerken nicht wirksam verbergen.
-
Obwohl in den vorhergehenden Absätzen Anwendungen für Deep Learning behandelt werden, werden die Leser verstehen, dass die hier beschriebenen Speichersysteme auch Teil einer Distributed Deep Learning („DDL“) - Plattform sein können, um die Ausführung von DDL-Algorithmen zu unterstützen. Distributed Deep Learning kann verwendet werden, um das Deep Learning mit verteiltem Rechnen auf GPUs (oder einer anderen Form von Beschleuniger oder einem Computerprogramm -Instruction Executor) erheblich zu beschleunigen, so dass Parallelität erreicht werden kann. Darüber hinaus kann die Ausgabe von Modellen für maschinelles Lernen und Deep Learning, wie z.B. ein vollständig trainiertes maschinelles Lernmodell, für eine Vielzahl von Zwecken und in Verbindung mit anderen Tools verwendet werden. Beispielsweise können trainierte maschinelle Lernmodelle in Verbindung mit Tools wie Core ML verwendet werden, um eine breite Palette von maschinellen Lernmodellen in eine Anwendung zu integrieren. Tatsächlich 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 vorstehend beschriebenen Speichersysteme können auch mit anderen Technologien wie TensorFlow, einer Open-Source-Softwarebibliothek zur Datenflussprogrammierung für eine Reihe von Aufgaben, die für Anwendungen des maschinellen Lernens, wie z.B. neuronale Netze, verwendet werden können, gepaart werden, um die Entwicklung solcher Modelle, Anwendungen usw. für maschinelles Lernen zu erleichtern.
-
Für den Leser ist ferner zu erkennen, dass die vorstehend beschriebenen Systeme auf vielfältige Weise eingesetzt werden können, um die Demokratisierung der KI zu unterstützen, da die KI immer mehr für den Massenkonsum verfügbar wird. Die Demokratisierung der KI kann z.B. die Fähigkeit einschließen, KI als Platform-as-a-Service anzubieten, die Zunahme der Angebote an künstlicher allgemeiner Intelligenz, die Verbreitung von autonomen Fahrzeugen der Stufen 4 und 5, die Verfügbarkeit von autonomen mobilen Robotern, die Entwicklung von Plattformen für dialogorientierte KI und vieles andere. Die vorstehend beschriebenen Systeme können zum Beispiel in Cloud-Umgebungen, Edge-Umgebungen oder anderen Umgebungen eingesetzt werden, die bei der Unterstützung der Demokratisierung der KI nützlich sind. Als Teil der Demokratisierung der KI kann eine Bewegung von der engen KI, die aus Lösungen für maschinelles Lernen mit hohem Umfang besteht, welche auf eine bestimmte Aufgabe abzielen, zur generellen künstlichen Intelligenz stattfinden, wo der Einsatz von maschinellem Lernen erweitert wird, um ein breites Spektrum von Anwendungsfällen zu bewältigen, die im Wesentlichen jede intelligente Aufgabe erfüllen könnten, die ein Mensch ausführen und dynamisch lernen könnte, ähnlich wie ein Mensch.
-
Die vorstehend beschriebenen Speichersysteme können auch in einer neuromorphen Computerumgebung eingesetzt werden. Neuromorphes Rechnen ist eine Form des Rechnens, die Gehirnzellen nachahmt. Um das neuromorphe Rechnen zu unterstützen, ersetzt eine Architektur aus miteinander verbundenen „Neuronen“ herkömmliche Rechenmodelle durch Signale mit geringer Leistung, die direkt zwischen den Neuronen verlaufen, um eine effizientere Berechnung zu ermöglichen. Neuromorphes Rechnen kann VLSI-Systeme (Very Large Scale Integration) mit elektronischen Analogschaltungen nutzen, um neurobiologische Architekturen im Nervensystem nachzuahmen, sowie analoge, digitale, gemischt analog/digitale VLSI- und Softwaresysteme, die Modelle neuronaler Systeme zur Wahrnehmung, motorischen Steuerung oder multisensorischen Integration implementieren.
-
Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme so konfiguriert werden können, dass sie die Speicherung oder Verwendung von (neben anderen Arten von Daten) Blockketten unterstützen. Solche Blockketten können als eine ständig wachsende Liste von Datensätzen, genannt Blöcke, verkörpert werden, die durch Kryptographie verknüpft und gesichert werden. Jeder Block in einer Blockkette kann einen Hash-Pointer als Verbindung zu einem vorherigen Block, einen Zeitstempel, Transaktionsdaten usw. enthalten. Blockketten können so gestaltet werden, dass sie gegen Änderungen der Daten resistent sind und als offener Distributed Ledger dienen können, der Transaktionen zwischen zwei Parteien effizient und auf überprüfbare und dauerhafte Weise aufzeichnen kann. Dadurch eignen sich Blockketten potenziell für die Aufzeichnung von Ereignissen, medizinischen Aufzeichnungen und anderen Datensatzmanagement-Aktivitäten, wie Identitätsmanagement, Transaktionsverarbeitung und andere. Neben der Unterstützung der Speicherung und Verwendung von Blockkettentechnologien können die vorstehend beschriebenen Speichersysteme auch die Speicherung und Verwendung abgeleiteter Elemente unterstützen, wie z.B. Open-Source-Blockketten und verwandte Tools, die Teil des IBM™ Hyperledger-Projekts sind, genehmigte Blockketten, bei denen eine bestimmte Anzahl vertrauenswürdiger Parteien auf die Blockkette zugreifen darf, Blockkettenprodukte, die es Entwicklern ermöglichen, ihre eigenen verteilten Ledger-Projekte zu erstellen, und andere. Die Leser werden verstehen, dass sich Blockkettentechnologien auf eine Vielzahl von Branchen und Sektoren auswirken können. So können Blockkettentechnologien zum Beispiel bei Immobilientransaktionen als blockkettenbasierte Verträge eingesetzt werden, deren Verwendung die Notwendigkeit von Drittparteien ausschließen und selbstausführende Aktionen ermöglichen kann, wenn die Bedingungen erfüllt sind. Ebenso können universelle Gesundheitsakten erstellt werden, indem die Gesundheitsgeschichte einer Person aggregiert und in ein Blockketten-Ledger gestellt wird, auf das jeder beliebige Gesundheitsdienstleister oder zugelassene Gesundheitsdienstleister zugreifen und es aktualisieren kann.
-
Für den Leser ist zu erkennen, dass die Verwendung von Blockketten nicht auf finanzielle Transaktionen, Verträge und dergleichen beschränkt ist. Vielmehr können Blockketten genutzt werden, um die dezentrale Aggregation, Ordnung, Zeitstempelung und Archivierung jeglicher Art von Informationen zu ermöglichen, einschließlich strukturierter Daten, Korrespondenz, Dokumentation oder anderer Daten. Durch die Verwendung von Blockketten können sich die Teilnehmer nachweislich und dauerhaft darauf einigen, welche Daten wann und von wem genau eingegeben wurden, ohne sich auf einen vertrauenswürdigen Vermittler verlassen zu müssen. So zielt beispielsweise die kürzlich von SAP eingeführte Blockkettenplattform, die MultiChain und Hyperledger Fabric unterstützt, auf ein breites Spektrum von Lieferketten- und anderen Nicht-Finanzanwendungen ab.
-
Eine Möglichkeit, eine Blockkette zur Aufzeichnung von Daten zu verwenden, besteht darin, die einzelnen Daten direkt in eine Transaktion einzubetten. Jede Blockketten-Transaktion kann von einer oder mehreren Parteien digital signiert, auf eine Vielzahl von Knoten repliziert, durch den Konsens-Algorithmus der Kette geordnet und mit einem Zeitstempel versehen und dauerhaft manipulationssicher 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 Benutzer der Kette 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 unter Umständen nicht besonders praktisch, wenn man versucht, einen sehr großen Datenbestand zu speichern. In Übereinstimmung mit den Ausführungsformen der vorliegenden Offenbarung können Blockketten und die hier beschriebenen Speichersysteme eingesetzt werden, um sowohl die On-Chain-Speicherung von Daten als auch die Off-Chain-Speicherung von Daten zu unterstützen.
-
Die Off-Chain-Speicherung von Daten kann auf verschiedene Weise implementiert werden und kann auftreten, wenn die Daten selbst nicht innerhalb der Blockkette gespeichert sind. Beispielsweise kann in einer Ausführungsform eine Hash-Funktion verwendet werden und die Daten selbst können in die Hash-Funktion eingespeist werden, um einen Hash-Wert zu erzeugen. In einem solchen Beispiel können anstelle der Daten selbst die Hashes von großen Datensegmenten in Transaktionen eingebettet sein. Jeder Hash-Wert kann als Festlegung für seine Eingabedaten dienen, wobei die Daten selbst außerhalb der Blockkette gespeichert werden. Für den Leser ist zu erkennen, dass jeder Blockchain-Teilnehmer, der ein Off-Chain-Datenteil benötigt, die Daten aus seinem Hash nicht reproduzieren kann, aber wenn die Daten auf andere Weise abgerufen werden können, dann dient der On-Chain-Hash zur Bestätigung, wer ihn erstellt hat und wann. Genau wie normale On-Chain-Daten kann der Hash in eine digital signierte Transaktion eingebettet werden, die durch Konsens in die Kette aufgenommen wurde.
-
Für den Leser ist zu erkennen, dass in anderen Ausführungsformen Alternativen zu Blockketten verwendet werden können, um die dezentrale Speicherung von Informationen zu erleichtern. Eine Alternative zu einer Blockkette, die verwendet werden kann, ist zum Beispiel ein Blockgeflecht. Während herkömmliche Blockketten jede Transaktion speichern, um eine Validierung zu erreichen, erlaubt ein Blockgeflecht eine sichere Dezentralisierung ohne die Verwendung der gesamten Kette und ermöglicht so eine kostengünstige On-Chain-Speicherung von Daten. Solche Blockgeflechte können einen Konsensmechanismus nutzen, der auf Zugriffsnachweisen (Proof of Access, PoA) und Arbeitsnachweisen (Proof of Work, PoW) basiert. Während typische PoW-Systeme nur vom vorherigen Block abhängen, um jeden nachfolgenden Block zu erzeugen, kann der PoA-Algorithmus Daten aus einem zufällig gewählten vorherigen Block einbeziehen. In Kombination mit der Blockgeflecht-Datenstruktur müssen die Miner nicht alle Blöcke speichern (Bildung einer Blockkette), sondern können alle vorherigen Blöcke speichern, die ein Geflecht von Blöcken bilden (ein Blockgeflecht). Dies ermöglicht ein höheres Maß an Skalierbarkeit, Geschwindigkeit und geringen Kosten und reduziert die Kosten der Datenspeicherung zum Teil deshalb, weil die Miner nicht alle Blöcke speichern müssen, was zu einer erheblichen Verringerung der Strommenge führt, die während des Miner-Prozesses verbraucht wird, denn mit der Erweiterung des Netzwerks sinkt der Stromverbrauch, da ein Blockgeflecht immer weniger Hashing-Leistung für den Konsens erfordert, je mehr Daten dem System hinzugefügt werden. Darüber hinaus können Blockgeflechte in einem dezentralen Speichernetzwerk eingesetzt werden, in dem Anreize geschaffen werden, um einen schnellen Datenaustausch zu fördern. Solche dezentralen Speichernetzwerke können auch Blockshadowing-Verfahren verwenden, bei denen die Knoten nur einen minimalen „Schatten“ eines Blocks an andere Knoten senden, der es den Peers ermöglicht, einen vollständigen Block zu rekonstruieren, anstatt den vollständigen Block selbst zu übertragen.
-
Die vorstehend beschriebenen Speichersysteme können, entweder allein oder in Kombination mit anderen Datenverarbeitungsgeräten, zur Unterstützung von In-Memory-Computing-Anwendungen eingesetzt werden. Beim In-Memory-Computing werden Informationen im Arbeitsspeicher (RAM) gespeichert, die über ein Cluster von Computern verteilt sind. In-Memory-Computing hilft Geschäftskunden, einschließlich Einzelhändlern, Banken und Versorgungsunternehmen, Muster schnell zu erkennen, riesige Datenmengen spontan zu analysieren und ihre Operationen schnell durchzuführen. Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme, insbesondere solche, die mit anpassbaren Mengen an Verarbeitungs-, Speicher- und Speicherressourcen konfigurierbar sind (z. B. solche Systeme, in denen Blades mit konfigurierbaren Mengen jeder Art von Ressource enthalten sind), so konfiguriert werden können, dass sie eine Infrastruktur bieten, die In-Memory-Computing unterstützen kann. Ebenso können die vorstehend beschriebenen Speichersysteme Komponenten (z.B. NVDIMMs, 3D-Koppelpunktspeicher, die schnellen, persistenten Speicher mit wahlfreiem Zugriff bieten) enthalten, die tatsächlich eine verbesserte In-Memory-Computing-Umgebung im Vergleich zu In-Memory-Computing-Umgebungen bieten können, die sich auf über dedizierte Server verteilten RAM stützen.
-
In einigen Ausführungsformen können die vorstehend 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-Koppelpunktspeicher) umfasst. In solchen Ausführungsformen haben die Benutzer möglicherweise keine Kenntnis darüber, wo ihre Daten im Einzelnen gespeichert sind, aber sie können trotzdem dieselbe vollständige, einheitliche API verwenden, um Daten zu adressieren. In solchen Ausführungsformen kann das Speichersystem (im Hintergrund) Daten auf die schnellste verfügbare Schicht verschieben - einschließlich der intelligenten Platzierung der Daten in Abhängigkeit von verschiedenen Eigenschaften der Daten oder in Abhängigkeit von einer anderen Heuristik. In einem solchen Beispiel können die Speichersysteme sogar vorhandene Produkte wie Apache Ignite und GridGain verwenden, um Daten zwischen den verschiedenen Speicherschichten zu bewegen, oder die Speichersysteme können clientspezifische Software verwenden, um Daten zwischen den verschiedenen Speicherschichten zu bewegen. Die hier beschriebenen Speichersysteme können verschiedene Optimierungen implementieren, um die Leistung des In-Memory-Computing zu verbessern, wie z.B., dass die Berechnungen so nah wie möglich an den Daten stattfinden.
-
Für den Leser ist zu erkennen, dass in einigen Ausführungsformen die vorstehend beschriebenen Speichersysteme mit anderen Ressourcen gepaart werden können, um die vorstehend beschriebenen Anwendungen zu unterstützen. Eine Infrastruktur könnte z.B. primäres Computing in Form von Servern und Workstations umfassen, die auf die Verwendung von General-Purpose Computing auf Grafikverarbeitungseinheiten („GPGPU“) spezialisiert sind, um Anwendungen für Deep Learning zu beschleunigen, die in einer Rechenmaschine zusammengeschaltet sind, um Parameter für Deep Neural Networks zu trainieren. Jedes System kann über eine externe Ethernet-Konnektivität, eine externe InfiniBand-Konnektivität, eine andere Form der externen Konnektivität oder eine Kombination davon verfügen. In einem solchen Beispiel können die GPUs für ein einzelnes großes Training gruppiert oder unabhängig voneinander verwendet werden, um mehrere Modelle zu trainieren. Die Infrastruktur könnte auch ein Speichersystem wie das vorstehend beschriebene umfassen, um z.B. einen Scale-Out-All-Flash-Datei- oder Objektspeicher bereitzustellen, über den über Hochleistungsprotokolle wie NFS, S3 usw. auf die Daten zugegriffen werden kann. Die Infrastruktur kann auch z.B. redundante Top-of-Rack-Ethernet-Switches umfassen, die mit dem Speicher verbunden sind und über Ports in MLAG-Portkanälen für Redundanz berechnet werden. Die Infrastruktur könnte auch zusätzliche Rechenleistung in Form von Whitebox-Servern, optional mit GPUs, für Datenaufnahme, Vorverarbeitung und Modelldebugging umfassen. Für den Leser ist zu erkennen, dass auch zusätzliche Infrastrukturen möglich sind.
-
Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Systeme für die vorstehend beschriebenen Anwendungen im Vergleich zu anderen Systemen, zu denen beispielsweise eine DDAS-Lösung (Distributed Direct-Attached Storage) in Serverknoten gehören kann, besser geeignet sind. Solche DDAS-Lösungen können für die Handhabung großer, weniger sequentieller Zugriffe ausgelegt sein, sind aber möglicherweise weniger in der Lage, kleine, wahlfreie Zugriffe zu handhaben. Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme genutzt werden können, um eine Plattform für die vorstehend beschriebenen Anwendungen bereitzustellen, die der Nutzung von cloudbasierten Ressourcen vorzuziehen ist, da die Speichersysteme in eine Vor-Ort- oder firmeninterne Infrastruktur eingebunden sein können, die sicherer, lokaler und interner verwaltet wird, robuster in Funktionsumfang und Leistung ist oder anderweitig der Nutzung von cloudbasierten Ressourcen als Teil einer Plattform zur Unterstützung der vorstehend beschriebenen Anwendungen vorzuziehen ist. Beispielsweise können Dienste, die auf Plattformen wie Watson von IBM aufgebaut sind, von einem Unternehmen erfordern, dass es individuelle Benutzerinformationen, wie z.B. Informationen zu Finanztransaktionen oder identifizierbare Patientendaten, an andere Institutionen weitergibt. Daher können cloudbasierte Angebote von KI als Service weniger wünschenswert sein als intern verwaltete und angebotene KI als Service, der durch Speichersysteme wie die vorstehend beschriebenen Speichersysteme unterstützt wird, und zwar aus einer Vielzahl von technischen Gründen sowie aus verschiedenen geschäftlichen Gründen.
-
Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme, entweder allein oder in Verbindung mit anderen Computervorrichtungen, so konfiguriert werden können, dass sie andere Kl-bezogene Tools unterstützen. Beispielsweise können die Speichersysteme Tools wie ONXX oder andere Austauschformate für offene neuronale Netze verwenden, die die Übertragung von Modellen erleichtern, die in verschiedenen KI-Frameworks geschrieben wurden. Ebenso können die Speichersysteme so konfiguriert werden, dass sie Tools wie Amazons Gluon unterstützen, die es Entwicklern ermöglichen, Modelle für Deep Learning zu entwerfen, zu bauen und zu trainieren. Tatsächlich können die vorstehend beschriebenen Speichersysteme Teil einer größeren Plattform sein, wie z.B. IBM™ Cloud Private for Data, die integrierte Datenwissenschaft, Datentechnik und Dienste zur Anwendungserstellung umfasst. Solche Plattformen können Daten in einem Unternehmen nahtlos sammeln, organisieren, sichern und analysieren sowie hybride Datenverwaltung, vereinheitlichte Datenverwaltung und -integration, Datenwissenschaft und Geschäftsanalyse mit einer einzigen Lösung vereinfachen.
-
Für den Leser ist zu erkennen, dass die vorstehend 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 Rand des Netzwerks, nahe der Datenquelle, durchgeführt wird. Edge-Computing kann Anwendungen, Daten und Rechenleistung (d.h. Dienste) von zentralen Punkten weg auf die logischen Extreme eines Netzwerks verlagern. Durch die Verwendung von Edge-Lösungen wie den vorstehend 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 Durchführung von Rechenaufgaben auf der Edge-Lösung, die Speicherung von Daten auf der Edge-Lösung und die generelle Nutzung der Edge-Lösung kann der Verbrauch teurer cloudbasierter Ressourcen vermieden werden, und es kann sogar zu Leistungsverbesserungen im Vergleich zu einer stärkeren Abhängigkeit von cloudbasierten Ressourcen kommen.
-
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. Zum Beispiel können Geräte wie Drohnen, autonome Autos, Roboter und andere Geräte eine extrem schnelle Verarbeitung erfordern - so schnell, dass das Senden von Daten in eine Cloud-Umgebung und zurück, um Datenverarbeitungsunterstützung zu erhalten, einfach zu langsam sein kann. Ebenso können Maschinen wie Lokomotiven und Gasturbinen, die große Informationsmengen durch den Einsatz einer Vielzahl von datenerzeugenden Sensoren erzeugen, von den schnellen Datenverarbeitungsfunktionen einer Edge-Lösung profitieren. Ein weiteres Beispiel: Einige IoT-Geräte wie angeschlossene Videokameras eignen sich möglicherweise nicht gut 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 einfach wegen des reinen Datenvolumens in die Cloud zu schicken. Daher sind viele Aufgaben, die wirklich mit Datenverarbeitung, Speicherung oder Kommunikation zu tun haben, möglicherweise besser für Plattformen geeignet, welche Edge-Lösungen wie die vorstehend beschriebenen Speichersysteme umfassen.
-
Betrachten wir ein spezifisches Beispiel für die Bestandsverwaltung in einem Lager, Verteilzentrum oder einem ähnlichen Ort. Ein großer Lagerbestand, eine Lagerhaltung, der Versand, die Auftragsabwicklung, die Fertigung oder ein anderer Betrieb hat eine große Menge an Bestand in Lagerregalen und hochauflösende Digitalkameras, die ein Data Firehose mit großen Datenmengen produzieren. All diese Daten können in ein Bildverarbeitungssystem aufgenommen werden, das die Datenmenge auf ein Data Firehose mit kleinen Daten reduzieren kann. Alle diese kleinen Daten können vor Ort gespeichert werden. Der lokale Speicher am Rand der Einrichtung kann für externe Berichte, Echtzeitsteuerung und Cloud-Speicherung an die Cloud gekoppelt werden. Das Bestandsmanagement kann mit den Ergebnissen der Bildverarbeitung durchgeführt werden, so dass der Bestand in den Regalen verfolgt und wieder aufgefüllt, verschoben, versandt, mit neuen Produkten modifiziert oder eingestellte/veraltete Produkte gelöscht werden können usw. Das obige Szenario ist ein erstklassiger Kandidat für eine Ausführungsform der vorstehend beschriebenen konfigurierbaren Verarbeitungs- und Speichersysteme. Eine Kombination aus Nur-Compute-Blades und Offload-Blades, die für die Bildverarbeitung geeignet sind, vielleicht mit Deep Learning auf Offload-FPGA oder Offload-Custom-Blade(s), könnte den Data Firehose mit großen Datenmangen von allen Digitalkameras aufnehmen und den Data Firehose mit kleinen Datenmengen erzeugen. Alle kleinen Datenmengen könnten dann von Speicherknoten gespeichert werden, die mit Speichereinheiten in der Kombination von Speicher-Blades arbeiten, die den Datenfluss am besten handhaben. Dies ist ein Beispiel für eine Speicher- und Funktionsbeschleunigung und -integration. Abhängig von den externen Kommunikationsbedürfnissen mit der Cloud und der externen Verarbeitung in der Cloud und abhängig von der Zuverlässigkeit der Netzwerkverbindungen und Cloud-Ressourcen könnte das System für Speicher- und Rechenmanagement mit Burst-Workloads und variabler Leitfähigkeitszuverlässigkeit dimensioniert werden. Abhängig von anderen Aspekten des Bestandsmanagements könnte das System auch für die Planung und das Ressourcenmanagement in einer hybriden Edge/Cloud-Umgebung konfiguriert werden.
-
Die vorstehend beschriebenen Speichersysteme können allein oder in Kombination mit anderen Rechnerressourcen als Netzwerk-Edge-Plattform dienen, welche Rechnerressourcen, Speicherressourcen, Netzwerkressourcen, Cloud-Technologien und Technologien zur Netzwerkvirtualisierung usw. kombiniert. Als Teil des Netzwerks kann die Edge-Lösung ähnliche Eigenschaften wie andere Netzwerkeinrichtungen annehmen, von der Customer Premise und Backhaul Aggregation Facilities bis hin zu Points of Presence (PoPs) und regionalen Datenzentren. Für den Leser ist zu erkennen, dass Netzwerkauslastungen, wie z.B. virtuelle Netzwerkfunktionen (VNFs) und andere, auf der Netzwerk-Edge-Plattform verbleiben. Die Netzwerk-Edge-Plattform, die durch eine Kombination von Containern und virtuellen Maschinen ermöglicht wird, kann sich auf Controller und Scheduler stützen, die nicht mehr geographisch mit den Datenverarbeitungsressourcen zusammen angeordnet sind. Die Funktionen können als Mikrodienste in Steuerungsebenen, Benutzer- und Datenebenen oder sogar in Zustandsautomaten aufgeteilt werden, so dass unabhängige Optimierungs- und Skalierungsverfahren angewendet werden können. Solche Benutzer- und Datenebenen können durch erhöhte Beschleuniger ermöglicht werden, und zwar sowohl durch solche, die in Server-Plattformen wie FPGAs und Smart-NICs untergebracht sind, als auch durch SDNfähige handelsübliche Silizium- und programmierbare ASICs.
-
Die vorstehend beschriebenen Speichersysteme können auch für den Einsatz in der Analyse großer Datenmengen optimiert werden. Die Analyse großer Datenmengen kann allgemein als der Prozess der Untersuchung großer und unterschiedlicher Datensätze beschrieben werden, um verborgene Muster, unbekannte Korrelationen, Markttrends, Kundenpräferenzen und andere nützliche Informationen aufzudecken, die Unternehmen dabei helfen können, fundiertere Geschäftsentscheidungen zu treffen. Große Datenanalyseanwendungen ermöglichen es Datenwissenschaftlern, Experten für Vorhersagemodelle, Statistikern und anderen Analyseexperten, wachsende Mengen strukturierter Transaktionsdaten sowie andere Formen von Daten zu analysieren, die von herkömmlichen Business Intelligence (Bl)- und Analyseprogrammen oft ungenutzt bleiben. Als Teil 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, Gesprächsdetailaufzeichnungen von Mobiltelefonen, IoT-Sensordaten und andere Daten in eine strukturierte Form umgewandelt werden. Die Analyse großer Datenmengen ist eine Form der fortgeschrittenen Analytik, die komplexe Anwendungen mit Elementen wie Vorhersagemodellen, statistischen Algorithmen und Waswäre-wenn-Analysen auf der Grundlage von Hochleistungsanalysesystemen umfasst.
-
Die vorstehend beschriebenen Speichersysteme können auch Anwendungen unterstützen (einschließlich der Implementierung als Systemschnittstelle), welche Aufgaben als Reaktion auf menschliche Sprache ausführen. Beispielsweise können die Speichersysteme die Ausführung intelligenter persönlicher Assistenten-Anwendungen unterstützen, wie z.B. Alexa von Amazon, Apple Siri, Google Voice, Samsung Bixby, Microsoft Cortana und andere. Während die im vorigen Satz beschriebenen Beispiele die Stimme als Eingabe verwenden, können die vorstehend beschriebenen Speichersysteme auch Chatbots, Talkbots, Chatterbots oder künstliche Gesprächseinheiten oder andere Anwendungen unterstützen, die so konfiguriert sind, dass sie eine Konversation über auditive oder textuelle Verfahren führen. Ebenso kann das Speichersystem eine solche Anwendung tatsächlich ausführen, um es einem Benutzer wie einem Systemadministrator zu ermöglichen, mit dem Speichersystem über Sprache zu interagieren. Solche Anwendungen sind im Allgemeinen in der Lage, Sprachinteraktion, Musikwiedergabe, Erstellung von To-Do-Listen, Einstellung von Alarmen, Streaming von Podcasts, Wiedergabe von Hörbüchern und Bereitstellung von Wetter-, Verkehrs- und anderen Echtzeitinformationen, wie z.B. Nachrichten, zu ermöglichen, obwohl solche Anwendungen in Ausführungsformen in Übereinstimmung mit der vorliegenden Offenbarung als Schnittstellen zu verschiedenen Systemverwaltungsoperationen verwendet werden können.
-
Die vorstehend beschriebenen Speichersysteme können auch KI-Plattformen implementieren, um die Vision der selbstfahrenden Speicherung zu verwirklichen. Solche KI-Plattformen können so konfiguriert werden, dass sie globale vorausschauende Intelligenz liefern, indem sie große Mengen von Telemetrie-Datenpunkten des Speichersystems sammeln und analysieren, um mühelose Verwaltung, Analyse und Unterstützung zu ermöglichen. Tatsächlich können solche Speichersysteme in der Lage sein, sowohl Kapazität und Leistung vorherzusagen als auch intelligente Ratschläge zur Bereitstellung, Interaktion und Optimierung der Arbeitslast zu geben. Solche KI-Plattformen können so konfiguriert werden, dass alle eingehenden Telemetriedaten des Speichersystems mit einer Bibliothek von Problem-Fingerabdrücken abgeglichen werden, um Vorfälle in Echtzeit vorherzusagen und zu lösen, bevor sie sich auf Kundenumgebungen auswirken, und dass Hunderte von leistungsbezogenen Variablen erfasst werden, die zur Vorhersage der Leistungslast verwendet werden.
-
Die vorstehend beschriebenen Speichersysteme können die serialisierte oder simultane Ausführung von Anwendungen der künstlichen Intelligenz, Anwendungen des maschinellen Lernens, Datenanalyseanwendungen, Datentransformationen und andere Aufgaben unterstützen, die zusammen eine KI-Leiter bilden können. Eine solche KI-Leiter kann effektiv durch die Kombination solcher Elemente zu einer vollständigen datenwissenschaftlichen Pipeline gebildet werden, wenn Abhängigkeiten zwischen Elementen der KI-Leiter bestehen. Zum Beispiel kann die KI erfordern, dass eine Form des maschinellen Lernens stattgefunden hat, maschinelles Lernen kann erfordern, dass eine Form der Analytik stattgefunden hat, Analytik kann erfordern, dass eine Form der Daten- und Informationsarchitektur stattgefunden hat, und so weiter. Als solche kann jedes Element als eine Sprosse in einer Kl-Leiter angesehen werden, die zusammengenommen eine vollständige und anspruchsvolle Kl-Lösung bilden kann.
-
Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um überall dort eine Kl zu ermöglichen, wo KI weite und umfangreiche Aspekte des Geschäftslebens durchdringt. Beispielsweise kann die KI eine wichtige Rolle spielen bei der Bereitstellung von Lösungen für Deep Learning, Lösungen für Reinforcement Learning, Lösungen für künstliche allgemeine Intelligenz, autonome Fahrzeuge, Lösungen für kognitive Computer, kommerzielle UAVs oder Drohnen, dialogorientierte Benutzerschnittstellen, Unternehmenstaxonomien, Ontologie-Management-Lösungen, Lösungen für maschinelles Lernen, Smart Dust, Smart Robots, Smart Workplaces und viele andere. Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um ein breites Spektrum an transparenten immersiven Erlebnissen zu ermöglichen, bei denen die Technologie Transparenz zwischen Menschen, Unternehmen und Dingen schaffen kann. Solche transparenten immersiven Erlebnisse können als Augmented-Reality-Technologien, vernetzte Häuser, Virtual-Reality-Technologien, Gehirn-Computer-Schnittstellen, menschliche Augmentationstechnologien, Nanoröhren-Elektronik, volumetrische Anzeigen, 4D-Drucktechnologien oder andere bereitgestellt werden. Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, zur Unterstützung einer Vielzahl von digitalen Plattformen eingesetzt werden. Solche digitalen Plattformen können z.B. drahtlose 5G-Systeme und -Plattformen, Digital-Twin- Plattformen, Edge-Computing-Plattformen, loT-Plattformen, Quantencomputerplattformen, serverlose PaaS, softwaredefinierte Sicherheit, neuromorphe Computerplattformen usw. umfassen.
-
Für den Leser ist zu erkennen, dass einige transparente immersive Erlebnisse die Verwendung von digitalen Zwillingen verschiedener „Dinge“ wie Menschen, Orte, Prozesse, Systeme und so weiter beinhalten können. Solche digitalen Zwillinge und andere immersive Technologien können die Art und Weise verändern, wie Menschen mit der Technologie interagieren, da Konversationsplattformen, Augmented Reality, Virtual Reality und Mixed Reality eine natürlichere und immersivere Interaktion mit der digitalen Weit 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 und so weiter. Da digitale Zwillinge riesige Mengen an Informationen über einzelne Assets und Gruppen von Assets konsolidieren (und möglicherweise sogar die Steuerung über diese Assets übernehmen), können digitale Zwillinge miteinander zu digitalen Fabrikmodellen von mehreren miteinander verbundenen digitalen Zwillingen kommunizieren.
-
Die vorstehend beschriebenen Speichersysteme können auch Teil einer Multi-Cloud-Umgebung sein, in der mehrere Cloud-Computing- und Storage-Dienste in einer einzigen heterogenen Architektur bereitgestellt werden. Um den Betrieb einer solchen Multi-Cloud-Umgebung zu erleichtern, können DevOps-Tools eingesetzt werden, um eine Orchestrierung über Clouds hinweg zu ermöglichen. Ebenso können Tools für die kontinuierliche Entwicklung und kontinuierliche Integration eingesetzt werden, um Prozesse rund um die kontinuierliche Integration und Bereitstellung, den Rollout 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 in verschiedene Clouds zu verschieben, Leistungsprobleme zu ermitteln und andere Aufgaben durchzuführen. 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 intelligentes Workload-Management umfassen, um eine effiziente Anwendungsbereitstellung zu gewährleisten und die Arbeitslasten über die verteilte und heterogene Infrastruktur zu lenken, sowie Tools, die die Bereitstellung und Handhabung von gebündelten und benutzerdefinierten Anwendungen in der Cloud erleichtern und die Portabilität zwischen Clouds ermöglichen. Die Multi-Cloud-Umgebung kann in ähnlicher Weise Tools für die Datenportabilität umfassen.
-
Die vorstehend beschriebenen Speichersysteme können als Teil einer Plattform verwendet werden, um die Verwendung von Crypto-Anchors 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 Blockkettendatensatz übereinstimmt. Solche Crypto-Anchor können viele Formen annehmen, z.B. als essbare Tinte, als mobiler Sensor, als Mikrochip und andere. In ähnlicher Weise können die vorstehend beschriebenen Speichersysteme als Teil einer Reihe von Tools zur Sicherung der auf dem Speichersystem gespeicherten Daten verschiedene Verschlüsselungstechnologien und - schemata implementieren, einschließlich der Gitterkryptographie. Die Gitterkryptographie kann Konstruktionen von kryptographischen Primitiven beinhalten, die entweder in der Konstruktion selbst oder im Sicherheitsnachweis Gitter enthalten. Im Gegensatz zu Public-Key-Schemata wie RSA-, Diffie-Hellman- oder Elliptische-Kurve-Kryptosystemen, die leicht von einem Quantencomputer angegriffen werden können, scheinen einige gitterbasierte Konstruktionen gegen Angriffe sowohl von klassischen als auch von Quantencomputern resistent zu sein.
-
Ein Quantencomputer ist ein Gerät, das Quantenberechnungen durchführt. Quantencomputing ist Rechnen mit quantenmechanischen Phänomenen wie Überlagerung und Verschränkung. Quantencomputer unterscheiden sich von herkömmlichen Computern, die auf Transistoren basieren, da solche herkömmlichen Computer erfordern, dass Daten in Binärziffern (Bits) kodiert werden, 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 Zustandsüberlagerungen befinden können. Ein Quantencomputer unterhält eine Sequenz von Qubits, wobei ein einzelnes Qubit eine Eins, eine Null oder eine beliebige Quantenüberlagerung dieser beiden Qubit-Zustände darstellen kann. Ein Paar von Qubits kann sich in einer beliebigen Quantenüberlagerung von 4 Zuständen und drei Qubits können sich in einer beliebigen Überlagerung von 8 Zuständen befinden. 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 ein herkömmlicher Computer sich zu einem Zeitpunkt immer nur in einem dieser Zustände befinden kann. Eine Quanten-Turing-Maschine ist ein theoretisches Modell eines solchen Computers.
-
Die vorstehend beschriebenen Speichersysteme können auch mit FPGA-beschleunigten Servern als Teil einer größeren AI- oder ML-Infrastruktur gepaart werden. Solche FPGA-beschleunigten Server können sich in der Nähe (z.B. im gleichen Rechenzentrum) der vorstehend beschriebenen Speichersysteme befinden oder sogar in eine Vorrichtung 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 FPGA-beschleunigte Server in einer Cloud-Computing-Umgebung untergebracht sein, die zur Ausführung von rechenbezogenen Aufgaben für AI- und ML-Aufgaben verwendet werden kann. Jede der vorstehend beschriebenen Ausführungsformen kann gemeinsam als FPGA-basierte AI- oder ML-Plattform verwendet werden. Für den Leser ist zu erkennen, dass in einigen Ausführungsformen der FPGA-basierten AI- 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 Fähigkeit zur Rekonfiguration der FPGAs, die in den FPGA-beschleunigten Servern enthalten sind, kann die Beschleunigung einer ML- oder AI-Anwendung auf der Grundlage des optimalen numerischen Präzisions- und Speichermodells, das verwendet wird, ermöglichen. Für den Leser ist zu erkennen, dass durch die Behandlung der Sammlung von FPGA-beschleunigten Servern als ein Pool von FPGAs jede CPU im Rechenzentrum den Pool von FPGAs als gemeinsam genutzten Hardware-Mikroservice nutzen kann, anstatt einen Server auf dedizierte Beschleuniger zu beschränken, die an ihn angeschlossen sind.
-
Die vorstehend beschriebenen FPGA-beschleunigten Server und die GPUbeschleunigten Server können ein Rechenmodell implementieren, bei dem das Modell und die Parameter des maschinellen Lernens in den On-Chip-Speicher mit hoher Bandbreite gespeichert werden und viele Daten durch den On-Chip-Speicher mit hoher Bandbreite fließen, anstatt eine kleine Datenmenge in einer CPU zu halten und einen langen Befehlsstrom darüber laufen zu lassen, wie es bei herkömmlicheren Rechenmodellen der Fall war. FPGAs sind für dieses Rechenmodell möglicherweise sogar effizienter als GPUs, da die FPGAs nur mit den für die Ausführung dieser Art von Rechenmodell erforderlichen Befehlen programmiert werden können.
-
Die vorstehend beschriebenen Speichersysteme können so konfiguriert werden, dass sie 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, über die Metadaten verteilt sind, sowie Komponenten, die Dienste für Clients und Speicherserver umfassen. Durch die Verwendung eines parallelen Dateisystems können Dateiinhalte mittels Striping über eine Vielzahl von Speicherservern und Metadaten auf eine Vielzahl von Metadatenservern auf Verzeichnisebene verteilt werden, wobei jeder Server einen Teil des gesamten Dateisystembaums speichert. Für den Leser ist zu erkennen, dass in einigen Ausführungsformen die Speicher- und Metadatenserver im Userspace auf einem bestehenden lokalen Dateisystem laufen können. Darüber hinaus ist für die Client-Dienste keine dedizierte Hardware erforderlich, die Metadatenserver oder die Hardware-Server als Metadatenserver, Speicherserver und sogar die Client-Dienste können auf denselben Maschinen laufen.
-
Die Leser werden verstehen, dass - zum Teil aufgrund des Aufkommens vieler der oben besprochenen Technologien, einschließlich mobiler Geräte, Cloud-Dienste, sozialer Netzwerke, großer Datenanalysen usw. - eine Informationstechnologieplattform erforderlich sein kann, um all diese Technologien zu integrieren und neue Geschäftsmöglichkeiten durch die schnelle Bereitstellung von umsatzgenerierenden Produkten, Dienstleistungen und Erlebnissen zu eröffnen - anstatt nur die Technologie zur Automatisierung interner Geschäftsprozesse bereitzustellen. IT-Organisationen müssen unter Umständen die Ressourcen und Investitionen ausgleichen, die erforderlich sind, um die zentralen Altsysteme am Laufen zu halten, und gleichzeitig Technologien integrieren, um eine IT-Plattform aufzubauen, die die Geschwindigkeit und Flexibilität in Bereichen wie z.B. der Nutzung großer Datenmengen, der Verwaltung unstrukturierter Daten und der Arbeit mit Cloud-Anwendungen und -Diensten bietet. Eine mögliche Ausführungsform einer solchen Informationstechnologieplattform ist eine zusammensetzbare Infrastruktur, welche fluide Ressourcenpools umfasst, wie viele der vorstehend beschriebenen Systeme, die den sich ändernden Anforderungen von Anwendungen gerecht werden können, indem sie die Zusammensetzung und Neuzusammensetzung von Blöcken einer disaggregierten Rechen-, Speicher- und Fabric-Infrastruktur ermöglichen. Eine solche zusammensetzbare Infrastruktur kann auch eine einzige Verwaltungsschnittstelle zum Vermeiden von Komplexität und eine einheitliche API zum Erkennen, Suchen, Inventarisieren, Konfigurieren, Bereitstellen, Aktualisieren und Diagnostizieren der zusammensetzbaren Infrastruktur umfassen.
-
Die vorstehend beschriebenen Systeme können das Ausführen einer breiten Palette von Software-Anwendungen unterstützen. Solche Software-Anwendungen können auf verschiedene Weise eingesetzt werden, einschließlich container-basierter Einsatzmodelle. 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, welches es IT-Administratoren und Entwicklern ermöglicht, einen Cluster von Docker-Knoten als ein einziges virtuelles System einzurichten und zu verwalten. 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 können auf Betriebssystemen wie z. B. Red Hat Enterprise Linux, Ubuntu Server, SUSE Linux Enterprise Servers und anderen ausgeführt werden. In solchen Beispielen kann ein Masterknoten Worker/Minion-Knoten Aufgaben zuweisen. Kubernetes können eine Reihe von Komponenten (z. B. Kubelet, Kube-Proxy, cAdvisor) enthalten, welche einzelne Knoten verwalten, sowie eine Reihe von Komponenten (z. B. API-Server, Scheduler, Control Manager usw.), die eine Steuerungsebene bilden. Verschiedene Controller (z.B. Replication Controller, DaemonSet Controller) können den Zustand eines Kubernetes-Clusters steuern, indem sie einen Satz von Pods verwalten, der einen oder mehrere Container umfasst, die auf einem einzelnen Knoten bereitgestellt werden. Containerisierte Anwendungen können verwendet werden, um ein serverloses, Cloud-Native-Computing-Bereitstellungs- und Verwaltungsmodell für Softwareanwendungen zu ermöglichen. Zur Unterstützung eines serverlosen, Cloud-Native-Computing-Bereitstellungs- und Verwaltungsmodells für Softwareanwendungen können Container als Teil eines Event Handling Mechanismus (z.B. AWS-Lambdas) verwendet werden, so dass verschiedene Ereignisse dazu führen, dass eine containerisierte Anwendung als Event-Handler ausgeführt wird.
-
Die vorstehend beschriebenen Systeme können auf verschiedene Art und Weise eingesetzt werden, darunter auch so, dass sie Netzwerke der fünften Generation („5G“) unterstützen. 5G-Netze können eine wesentlich schnellere Datenkommunikation als frühere Generationen von Mobilfunknetzen unterstützen und in der Folge zu einer Disaggregation von Daten- und Rechenressourcen führen, da moderne massive Datenzentren an Bedeutung verlieren und z.B. durch örtlichere, Mikrodatenzentren ersetzt werden können, die sich in der Nähe der Mobilfunkmasten befinden. Die vorstehend beschriebenen Systeme können zu solchen lokalen Mikrodatenzentren gehören und Teil von oder gepaart mit Multi-Access-Edge-Computing-Systemen („MEC“) sein. Solche MEC-Systeme können Cloud-Computing-Fähigkeiten und eine IT-Service-Umgebung am Rande des Mobilfunknetzes ermöglichen. Indem Anwendungen und damit verbundene Verarbeitungsaufgaben näher am Mobilfunkkunden ausgeführt werden, können Netzwerküberlastungen verringert und Anwendungen leistungsfähiger gemacht werden. Die MEC-Technologie ist so konzipiert, dass sie in den zellularen Basisstationen oder anderen Randknoten implementiert werden kann, und ermöglicht eine flexible und schnelle Bereitstellung neuer Anwendungen und Dienste für die Kunden. MEC kann es Mobilfunkbetreibern auch ermöglichen, ihr Funkzugangsnetz („RAN“) für autorisierte Dritte, wie z.B. Anwendungsentwickler und Inhaltsanbieter, zu öffnen. Darüber hinaus können Edge-Computing und Mikrodatenzentren die Kosten für Smartphones, die mit dem 5G-Netz arbeiten, erheblich senken, da die Kunden möglicherweise keine Geräte mit so intensiver Rechenleistung und den dafür erforderlichen teuren Komponenten benötigen.
-
Für den Leser ist zu erkennen, dass 5G-Netze möglicherweise mehr Daten erzeugen als frühere Netzgenerationen, insbesondere angesichts der Tatsache, dass die von 5G-Netzen angebotene hohe Netzbandbreite dazu führen kann, dass die 5G-Netze Datenmengen und -arten verarbeiten (z.B. Sensordaten von selbstfahrenden Autos, von AR/VR-Technologien erzeugte Daten), die für Netze der früheren Generation nicht so realisierbar waren. In solchen Beispielen kann die Skalierbarkeit, die die vorstehend beschriebenen Systeme bieten, sehr wertvoll sein, da die Datenmenge zunimmt, die Einführung neuer Technologien zunimmt und so weiter.
-
Zur weiteren Erläuterung ist in 3C ein beispielhaftes Datenverarbeitungsgerät 350 dargestellt, das speziell konfiguriert werden kann, um einen oder mehrere der hier beschriebenen Prozesse auszuführen. Wie in 3C dargestellt, kann das Datenverarbeitungsgerät 350 eine Kommunikationsschnittstelle 352, einen Prozessor 354, ein Speichergerät 356 und ein Ein-/Ausgabe- („E/A“-) Modul 358 umfassen, die über eine Kommunikationsinfrastruktur 360 kommunikativ miteinander verbunden sind. Während ein beispielhaftes Datenverarbeitungsgerät 350 in 3C dargestellt ist, sind die in 3C dargestellten Komponenten nicht als begrenzend zu verstehen. Zusätzliche oder alternative Komponenten können in anderen Ausführungsformen verwendet werden. Die in 3C dargestellten Komponenten des Datenverarbeitungsgeräts 350 werden nun zusätzlich detailliert beschrieben.
-
Die Kommunikationsschnittstelle 352 kann für die Kommunikation mit einem oder mehreren Datenverarbeitungsgeräten konfiguriert werden. Beispiele für die Kommunikationsschnittstelle 352 sind unter anderem eine drahtgebundene Netzwerkschnittstelle (z. B. eine Netzwerkschnittsteflenkarte), eine drahtlose Netzwerkschnittstelle (z. B. eine drahtlose Netzwerkschnittstellenkarte), ein Modem, eine Audio-A/ideoverbindung und jede andere geeignete Schnittstelle.
-
Ein Prozessor 354 stellt im Allgemeinen jede Art oder Form einer Verarbeitungsvorrichtung dar, die in der Lage ist, Daten zu verarbeiten und/oder einen oder mehrere der hier beschriebenen Befehle, Prozesse und/oder Operationen zu interpretieren, auszuführen und/oder die Ausführung zu steuern. Der Prozessor 354 kann Operationen ausführen, indem er computerausführbare Befehle 362 (z.B. eine Anwendung, eine Software, einen Code und/oder andere ausführbare Dateninstanzen) ausführt, die in einem Speichergerät 356 gespeichert sind.
-
Das Speichergerät 356 kann ein oder mehrere Datenspeichermedien, -geräte oder - konfigurationen einschließen und kann jede Art, Form und Kombination von Datenspeichermedien und/oder -geräten verwenden. Zum Beispiel kann das Speichergerät 356 jede 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 auf dem Speichergerät 356 gespeichert werden. Beispielsweise können Daten, die für computerausführbare Befehle 362 repräsentativ sind, die so konfiguriert sind, dass sie den Prozessor 354 anweisen, eine der hierin beschriebenen Operationen auszuführen, auf dem Speichergerät 356 gespeichert werden. In einigen Beispielen können die Daten in einer oder mehreren Datenbanken angeordnet sein, die sich im Speichergerät 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 jede Hardware, Firmware, Software oder eine Kombination davon enthalten, die Ein- und Ausgabefunktionen unterstützt. Zum Beispiel kann das E/A-Modul 358 Hardware und/oder Software zum Erfassen von Benutzereingaben enthalten, einschließlich, aber nicht beschränkt auf eine Tastatur oder ein Tastenfeld, eine Touchscreen-Komponente (z.B. Touchscreen-Display), einen Empfänger (z.B. einen HF- oder Infrarot-Empfänger), Bewegungssensoren und/oder eine oder mehrere Eingabetasten.
-
Das E/A-Modul 358 kann ein oder mehrere Geräte zur Darstellung der Ausgabe an einen Benutzer enthalten, einschließlich, aber nicht beschränkt auf, eine Grafik-Engine, eine Anzeige (z. B. einen Bildschirm), einen oder mehrere Ausgangstreiber (z. B. Anzeigetreiber), einen oder mehrere Audiolautsprecher und einen oder mehrere Audiotreiber. In bestimmten Ausführungsformen ist das E/A-Modul 358 so konfiguriert, dass es grafische Daten für eine Anzeige zur Darstellung für einen Benutzer bereitstellt. Die graphischen Daten können repräsentativ für eine oder mehrere graphische Benutzerschnittstellen und/oder jeden anderen graphischen Inhalt sein, der einer bestimmten Implementierung dient. In einigen Beispielen kann jedes der hier beschriebenen Systeme, Datenverarbeitungsgeräte und/oder andere Komponenten durch das Datenverarbeitungsgerät 350 implementiert werden.
-
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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (408, 410) einschließt, gebootet werden, um eine virtuelle Maschine zu erstellen und zu konfigurieren, die die Speicher-Controller-Anwendung ausführen kann (408, 410).
-
In der in 4 dargestellten Beispielmethode kann die Speicher-Controller-Anwendung (408, 410) als ein Modul von Computerprogrammbefehlen verkörpert sein, das bei seiner Ausführung verschiedene Speicheraufgaben ausführt. Beispielsweise kann die Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung 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 Speicher-Controller-Anwendung enthält. In einem solchen Beispiel kann es bei einem Controller-Ausfall länger dauern, bis eine neue Cloud-Computing-Instanz, die die Speicher-Controller-Anwendung enthält, wiederhergestellt werden kann, da eine neue Cloud-Computing-Instanz, die die Speicher-Controller-Anwendung 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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (408) ausführt, als primärer Controller fungiert. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz (404), die die Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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-Instanz 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 haltbarer 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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung 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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung 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-lnstanz 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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendungen (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung) 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 Speicher-Controller-Anwendung (506) unterstützen, so dass ein Failover auftreten kann, wenn die Cloud-Computing-Instanz (504), die die Speicher-Controller-Anwendung (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 Speicher-Controller-Anwendung unterstützt, in einer ersten Verfügbarkeitszone befinden, während sich eine zweite Cloud-Computing-Instanz, die ebenfalls die Ausführung der Speicher-Controller-Anwendung 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.
-
Die in 6 dargestellte Beispielmethode 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 Speicher-Controller-Anwendung 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 Blockspeicherschicht 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 Blockspeicherschicht 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 Speicher-Controller-Anwendung 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 eine weitere Beispielmethode zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (604). Die in 10 dargestellte Beispielmethode ähnelt der in vielen der obigen Figuren dargestellten Beispielmethode, da die in 10 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.
-
In der in 10 dargestellten Beispielmethode kann das Empfangen (606) der Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem das Empfangen (1002) der Anforderung zum Schreiben von Daten in den cloudbasierten Speicher durch eine Speicher-Controller-Anwendung, die in einer Cloud-Computing-Instanz ausgeführt wird, umfassen. Die Speicher-Controller-Anwendung, die in einer Cloud-Computing-Instanz ausgeführt wird, kann den vorstehend beschriebenen Speicher-Controller-Anwendungen ähnlich sein und kann z.B. in einer EC2-Instanz ausgeführt werden, wie oben ausführlicher beschrieben. Tatsächlich kann das cloudbasierte Speichersystem (604) tatsächlich mehrere EC2-Instanzen oder ähnliche Cloud-Computing-Instanzen umfassen, wobei mehrere Cloud-Computing-Instanzen jeweils die Speicher-Controller-Anwendung ausführen.
-
In der in 10 dargestellten Beispielmethode kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems das Ausgeben (1004), durch die in der Cloud-Computing-Instanz ausgeführte Speicher-Controller-Anwendung, eines Befehls zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher umfassen. Die eine oder mehrere Cloud-Computing-Instanzen mit lokalem Speicher können den vorstehend beschriebenen Cloud-Computing-Instanzen mit lokalem Speicher ähnlich sein. In der in 10 dargestellten Beispielmethode kann die in der Cloud-Computing-Instanz ausgeführte Speicher-Controller-Anwendung für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher gekoppelt sein. Auf diese Weise kann die Speicher-Controller-Anwendung, die in der Cloud-Computing-Instanz ausgeführt wird, die Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher als einzelne Speichergeräte behandeln, so dass die Speicher-Controller-Anwendung, die in der Cloud-Computing-Instanz ausgeführt wird, einen Befehl zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher ausgeben (1004) kann, indem sie denselben Satz von Befehlen ausgibt, den die Speicher-Controller-Anwendung beim Schreiben von Daten in ein angeschlossenes Speichergerät ausgeben würde. Da die Speicher-Controller-Anwendung, die in der Cloud-Computing-Instanz ausgeführt wird, für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher gekoppelt sein kann, der Speicher-Array-Controller mit mehreren Blockspeicherquellen verbunden sein kann, werden die Leser erkennen, dass der Speicher-Array-Controller nur dann mit einem einzigen EBS-Volume verbunden werden könnte, wenn der Speicher-Array-Controller so konfiguriert wäre, dass er ein EBS als Blockspeicher verwendet.
-
In dem in 10 dargestellten Beispielverfahren können eine oder mehrere der Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen gekoppelt werden, die jeweils die Speicher-Controller-Anwendung ausführen. Da es eine Vielzahl von Cloud-Computing-Instanzen gibt, die jeweils die Speicher-Controller-Anwendung ausführen, werden die Leser erkennen, dass in einigen Ausführungsformen eine Speicher-Controller-Anwendung, die auf einer ersten Cloud-Computing-Instanz ausgeführt wird, als primärer Controller dienen kann, während zusätzliche Speicher-Controller-Anwendungen, die auf zusätzlichen Cloud-Computing-Instanzen ausgeführt werden, als sekundäre Controller dienen können, die beim Eintreten eines Ereignisses (z.B. Ausfall des primären Controllers) den primären Controller übernehmen können.
-
Zur weiteren Veranschaulichung ist in 11 ein Flussdiagramm dargestellt, das eine weitere Beispielmethode zur Handhabung von E/A-Operationen in einem cloudbasierten Speichersystem (604) veranschaulicht. Die in 11 dargestellte Beispielmethode ähnelt der in vielen der obigen Figuren dargestellten Beispielmethode, da die in 11 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.
-
Bei der in 11 dargestellten Beispielmethode, kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems das Schreiben (1102) in einen oder mehrere Blöcke des Blockspeichers (1102) einschließen, wobei die Daten ein Protokoll auf Blockebene verwenden. In der in 11 dargestellten Beispielmethode kann der Blockspeicher als eine oder mehrere Blockspeichereinheiten, wie z.B. ein NAND-Flash-Speicher, ausgeführt sein, bei dem die Daten in Blöcken gespeichert werden, die jeweils zur Speicherung von Daten einer maximalen Größe (d.h. einer Blockgröße) verwendet werden können. Daten können unter Verwendung eines Protokolls auf Blockebene, wie z. B. iSCSI, Fibre Channel und FCoE (Fibre Channel over Ethernet) usw., auf solche Speichergeräte geschrieben werden (1102). Für den Leser ist zu erkennen, 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 der in 11 dargestellten Beispielmethode, dem Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems das Schreiben (1104) in ein oder mehrere Objekte im Objektspeicher einschließen, wobei die Daten ein Protokoll auf Objektebene verwenden. In der in 11 dargestellten Beispielmethode kann der Objektspeicher so konfiguriert sein, dass er Daten als Objekte verwaltet, im Gegensatz zu anderen Speicherarchitekturen wie Dateisystemen, die Daten als Dateihierarchie verwalten, und Blockspeichern, die Daten als Blöcke verwalten. Eine solche Objektspeicherung kann auf der Geräteebene (Objektspeichergerät), der Systemebene, der Schnittstellenebene oder auf 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 den Cloud-Speicher und andere. Für den Leser ist zu erkennen, 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 vorigen Absatz der Fall war.
-
In der in 11 dargestellten Beispielmethode können für jeden Datenblock die in einem bestimmten Block enthaltenen Daten in ein eindeutiges Objekt geschrieben werden. Für den Leser ist zu erkennen, 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 einer global eindeutigen Kennung zugeordnet werden kann - und nicht nur ein Dateiname und ein Dateipfad, eine Blocknummer und so weiter. Somit 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 global eindeutige Kennung enthält. In solchen Ausführungsformen kann das cloudbasierte Speichersystem daher eine Zuordnung von jedem Datenblock, der im Blockspeicher des cloudbasierten Speichersystems gespeichert ist, und jedem Objekt, das im Objektspeicher des cloudbasierten Speichersystems gespeichert ist, beibehalten. 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, brauchen nur in einem einzigen Objekt gespeichert zu werden.
-
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 Blockspeicherschicht des cloudbasierten Speichersystems zurückgebracht werden, andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Da 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 verloren gegangenen Daten durch eine RAID-Wiederherstellung in die Blockspeicherschicht des cloudbasierten Speichersystems zurückgebracht werden.
-
Die Leser werden ferner erkennen, dass, obwohl die vorstehenden Absätze cloudbasierte Speichersysteme und deren Betrieb beschreiben, die vorstehend beschriebenen cloudbasierten Speichersysteme verwendet werden können, um einen Block-Storage-as-a-Service anzubieten, da die cloudbasierten Speichersysteme ausgegliedert und genutzt werden können, um einen Block-Service bei Bedarf On-Demand bereitzustellen. In einem solchen Beispiel kann die Bereitstellung von einem Block-Storage-as-a-Service in einer Cloud-Computing-Umgebung Folgendes umfassen: Empfangen einer Anforderung von Blockspeicherdiensten von einem Benutzer; Erstellen eines Volumes zur Verwendung durch den Benutzer; Empfangen von E/A-Operationen, die an das Volume gerichtet sind; und Weiterleiten der E/A-Operationen an ein Speichersystem, das zusammen mit Hardwareressourcen für die Cloud-Computing-Umgebung angeordnet ist.
-
Die Vorteile und Merkmale der vorliegenden Offenbarung können durch die folgenden Aussagen weiter beschrieben werden:
- 1. Ein Verfahren zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem, wobei das Verfahren umfasst: Empfangen einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem durch das cloudbasierte Speichersystem; Speichern der Daten in einem Blockspeicher des cloudbasierten Speichersystems; und Speichern der Daten in einem Objektspeicher des cloudbasierten Speichersystems.
- 2. Das Verfahren der Aussage 1, ferner umfassend: Erkennen, dass mindestens ein Teil des Blockspeichers des cloudbasierten Speichersystems nicht mehr verfügbar ist; Ermitteln von Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist; Abrufen der Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist, aus dem Objektspeicher des cloudbasierten Speichersystems; und Speichern der abgerufenen Daten im Blockspeicher des cloudbasierten Speichersystems.
- 3. Das Verfahren der Aussage 2 oder Aussage 1, wobei: das Empfangen der Anforderung, Daten in das cloudbasierte Speichersystem zu schreiben, das Empfangen - durch eine Speicher-Controller-Anwendung, die in einer Cloud-Computing-Instanz ausgeführt wird - der Anforderung einschließt, Daten in den cloudbasierten Speicher zu schreiben; und das Speichern der Daten in einem Blockspeicher des cloudbasierten Speichersystems, das Ausgeben - durch die Speicher-Controller-Anwendung, die in der Cloud-Computing-Instanz ausgeführt wird - eines Befehls einschließt, Daten in einen lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher zu schreiben, wobei die Speicher-Controller-Anwendung, die in der Cloud-Computing-Instanz ausgeführt wird, zur Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher gekoppelt ist.
- 4. Das Verfahren der Aussage 3, Aussage 2 oder Aussage 1, wobei eine oder mehrere der Vielzahl von Cloud-Computing-Instanzen mit lokalem Speicher für die Datenkommunikation mit einer Vielzahl von Cloud-Computing-Instanzen gekoppelt sind, die jeweils die Speicher-Controller-Anwendung ausführen.
- 5. Das Verfahren der Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das Speichern der Daten im Blockspeicher des cloudbasierten Speichersystems ferner das Speichern der Daten in einem lokalen Speicher einer oder mehrerer Cloud-Computing-Instanzen umfasst.
- 6. Das Verfahren der Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei: das Speichern der Daten im Blockspeicher des cloudbasierten Speichersystems ferner das Schreiben der Daten in einen oder mehrere Blöcke des Blockspeichers umfasst, unter Verwendung eines Protokolls auf Blockebene; und das Speichern der Daten im Objektspeicher des cloudbasierten Speichersystems ferner das Schreiben der Daten in ein oder mehrere Objekte im Objektspeicher umfasst, unter Verwendung eines Protokolls auf Objektebene.
- 7. Das Verfahren der Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei, für jeden Datenblock, die in einem bestimmten Block enthaltenen Daten in ein einziges Objekt geschrieben werden.
- 8. Das Verfahren der Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend das Komprimieren der Daten.
- 9. Das Verfahren der Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend das Deduplizieren der Daten.
- 10. Das Verfahren der Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend das Verschlüsseln der Daten.
- 11. Das Verfahren der Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend das Empfangen einer Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem durch das cloudbasierte Speichersystem; Abrufen der Daten aus dem Blockspeicher des cloudbasierten Speichersystems.
- 12. Das Verfahren der Aussage 11, Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das Speichern der Daten in einem Objektspeicher des cloudbasierten Speichersystems ferner das Erzeugen eines oder mehrerer gleich großer Objekte umfasst, wobei jedes gleich große Objekt ein unterschiedliches Segment der Daten einschließt.
- 13. Das Verfahren der Aussage 12, Aussage 11, Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei der Blockspeicher des cloudbasierten Speichersystems durch eine geringe Leselatenz im Vergleich zum Objektspeicher des cloudbasierten Speichersystems gekennzeichnet ist.
-
Beispielausführungen werden weitgehend im Zusammenhang mit einem voll funktionsfähigen Computersystem beschrieben. Fachkundige Leser werden jedoch erkennen, dass die vorliegende Offenbarung auch in einem Computerprogramm-Produkt verkörpert sein kann, das auf computerlesbaren Speichermedien zur Verwendung mit jedem 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 Festplatten oder Disketten, Compact Disks für optische Laufwerke, Magnetbänder und andere, wie es sich für diejenigen, die im Fachgebiet erfahren sind, ergibt. Diejenigen, die im Fachgebiet erfahren sind, werden sofort erkennen, dass jedes Computersystem, das über geeignete Programmiermittel verfügt, in der Lage ist, die Schritte des Verfahrens so auszuführen, wie sie in einem Computerprogramm-Produkt verkörpert sind. Diejenigen, die im Fachgebiet erfahren sind, werden auch erkennen, dass, obwohl einige der in dieser Spezifikation beschriebenen beispielhaften Ausführungsformen auf Software ausgerichtet sind, die auf Computer-Hardware installiert und ausgeführt wird, alternative Ausführungsformen, die als Firmware oder als Hardware implementiert sind, dennoch gut in den Anwendungsbereich dieser Offenbarung fallen.
-
Ausführungsformen können ein System, ein Verfahren und/oder ein Computerprogramm-Produkt einschließen. Das Computerprogramm-Produkt kann ein computerlesbares Speichermedium (oder -medien) mit darauf befindlichen computerlesbaren Programmbefehlen umfassen, die einen Prozessor veranlassen, Aspekte der vorliegenden Offenbarung auszuführen.
-
Das computerlesbare Speichermedium kann ein konkretes Gerät sein, das Befehle zur Verwendung durch ein Befehlsausführungsgerät festhalten und speichern kann. Das computerlesbare Speichermedium kann z.B. das Folgende darstellen, ist aber nicht darauf beschränkt: ein elektronisches Speichergerät, ein magnetisches Speichergerät, ein optisches Speichergerät, ein elektromagnetisches Speichergerät, ein Halbleiterspeichergerät oder eine geeignete Kombination der vorgenannten. Eine nicht erschöpfende Liste mit spezifischeren Beispielen für das computerlesbare Speichermedium umfasst das Folgende: eine tragbare Computerdiskette, eine Festplatte, einen Speicher mit wahlfreiem Zugriff (RAM), einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flash-Speicher), einen statischen Speicher mit wahlfreiem Zugriff (SRAM), einen tragbaren Nur-Lese-Speicher für Compact Discs (CD-ROM), eine Digital Versatile Disk (DVD), einen Speicherstick, eine Diskette, eine mechanisch kodierte Vorrichtung wie Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Befehlen und jede geeignete Kombination der vorgenannten. Ein computerlesbares Speichermedium, wie es hier verwendet wird, ist nicht als vorübergehendes Signal an sich auszulegen, wie z.B. Radiowellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich über einen Wellenleiter oder andere Übertragungsmedien ausbreiten (z.B. Lichtimpulse, die durch ein Glasfaserkabel laufen), oder elektrische Signale, die über einen Draht übertragen werden.
-
Die hierin beschriebenen computerlesbaren Programmbefehle können von einem computerlesbaren Speichermedium oder über ein Netzwerk, z.B. das Internet, ein lokales Netzwerk, ein Wide Area Network und/oder ein drahtloses Netzwerk, auf die entsprechenden Rechen- und Verarbeitungsvorrichtungen heruntergeladen werden. Das Netzwerk kann aus Kupferübertragungskabeln, optischen Übertragungsfasern, drahtloser Übertragung, Routern, Firewalls, Switches, Gateway-Computern und/oder Edge-Servern bestehen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jedem Rechen-/Prozessorgerät empfängt computerlesbare Programmbefehle vom Netzwerk und leitet die computerlesbaren Programmbefehle zur Speicherung in einem computerlesbaren Speichermedium innerhalb des jeweiligen Rechen-/Prozessorgeräts weiter.
-
Bei computerlesbaren Programmbefehlen zur Durchführung von Operationen dieser Offenbarung kann es sich um Assembler-Befehle, Befehlssatzarchitektur (ISA) - Befehle, Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Firmware-Befehle, zustandsfestlegende Daten oder entweder um Quellcode oder Objektcode handeln, die in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache wie Smalltalk, C++ oder ähnlichem, und herkömmlicher prozeduraler Programmiersprachen wie der Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben sind. Die computerlesbaren Programmbefehle 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 letzteren Fall kann der entfernte Computer über jede Art von Netzwerk, einschließlich eines Local Area Network (LAN) oder eines Wide Area Network (WAN), mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer hergestellt werden (z.B. über das Internet mit Hilfe eines Internet Service Providers). In einigen Ausführungsformen können elektronische Schaltungen, z.B. programmierbare Logikschaltungen, feldprogrammierbare Gate Arrays (FPGA) oder programmierbare Logic Arrays (PLA), die computerlesbaren Programmbefehle ausführen, indem sie die Zustandsinformationen der computerlesbaren Programmbefehle zur Personalisierung der elektronischen Schaltungen nutzen, um Aspekte der vorliegenden Offenbarung durchzuführen.
-
Aspekte der vorliegenden Offenbarung werden hierin unter Bezugnahme auf Flussdiagramm-Illustrationen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogramm-Produkten gemäß einigen Ausführungsformen der Offenbarung beschrieben. Es wird verstanden werden, dass jeder Block der Flussdiagramm-Figuren und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagramm-Figuren und/oder Blockdiagrammen durch computerlesbare Programmbefehle implementiert werden kann.
-
Diese computerlesbaren Programmbefehle können einem Prozessor eines Allzweckrechners, eines Spezialrechners oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zum Erzeugen einer Maschine zur Verfügung gestellt werden, so dass die Befehle, die über den Prozessor des Rechners oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der im Flussdiagramm und/oder im Block oder in Blockdiagrammblöcken spezifizierten Funktionen/Aktionen erzeugen. Diese computerlesbaren Programmbefehle 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 mit den darin gespeicherten Befehlen einen Herstellungsgegenstand umfasst, der Befehle enthält, die Aspekte der im Flussdiagramm und/oder in dem Blockdiagrammblock oder in den Blockdiagrammblöcken spezifizierten Funktion/Handlung implementieren.
-
Die computerlesbaren Programmbefehle können auch auf einen Computer, ein anderes programmierbares Datenverarbeitungsgerät oder eine andere Vorrichtung geladen werden, um eine Reihe von Betriebsschritten auf dem Computer, einem anderen programmierbaren Gerät oder einer anderen Vorrichtung auszuführen, um einen computerimplementierten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer, einem anderen programmierbaren Gerät oder einer anderen Vorrichtung ausgeführt werden, die Funktionen/Aktionen implementieren, die im Flussdiagramm und/oder im Blockdiagrammblock oder in den Blockdiagrammblöcken spezifiziert sind.
-
Das Flussdiagramm und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogramm-Produkten entsprechend den verschiedenen Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in dem Flussdiagramm oder den Blockdiagrammen ein Modul, ein Segment oder einen Teil von Befehlen darstellen, der einen oder mehrere ausführbare Befehle zum Implementieren der spezifizierten logischen Funktion(en) umfasst. In einigen alternativen Implementierungen können die im Block angegebenen Funktionen außerhalb der in den Figuren angegebenen Reihenfolge auftreten. So können z.B. zwei nacheinander dargestellte Blöcke tatsächlich 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 der Blockdiagramme und/oder der Flussdiagrammdarstellung sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagrammdarstellung durch auf Special-Purpose-Hardware basierende Systeme implementiert werden kann, die die angegebenen Funktionen oder Aktionen ausführen oder Kombinationen von Special-Purpose-Hardware und Computerbefehlen ausführen.