DE112019005770T5 - Speicherverwaltung für ein cloudbasiertes Speichersystem - Google Patents

Speicherverwaltung für ein cloudbasiertes Speichersystem Download PDF

Info

Publication number
DE112019005770T5
DE112019005770T5 DE112019005770.7T DE112019005770T DE112019005770T5 DE 112019005770 T5 DE112019005770 T5 DE 112019005770T5 DE 112019005770 T DE112019005770 T DE 112019005770T DE 112019005770 T5 DE112019005770 T5 DE 112019005770T5
Authority
DE
Germany
Prior art keywords
storage
cloud
data
cloud computing
storage system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019005770.7T
Other languages
English (en)
Inventor
Aswin Karumbunathan
John Colgrove
Constantine Sapuntzakis
Joshua Freilich
Naveen Neelakantam
Sergey Zhuravlev
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pure Storage Inc
Original Assignee
Pure Storage Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pure Storage Inc filed Critical Pure Storage Inc
Publication of DE112019005770T5 publication Critical patent/DE112019005770T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2089—Redundant storage control functionality
    • G06F11/2092—Techniques of failing over between control units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3034—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a storage system, e.g. DASD based or network based
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447—Performance evaluation by modeling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0617—Improving the reliability of storage systems in relation to availability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0632—Configuration or reconfiguration of storage systems by initialisation or re-initialisation of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Ein cloudbasiertes Speichersystem als Teil einer Cloud-Computing-Umgebung, wobei das cloudbasierte Speichersystem Folgendes umfasst: Bestimmen, an dem cloudbasierten Speichersystem und in Reaktion auf eine Datenanforderung, dass die zuvor in einer oder mehreren virtuellen Instanzen einer virtuellen Instanzenschicht gespeicherten Daten nicht mehr in der einen oder den mehreren virtuellen Instanzen gespeichert sind; Erzeugen, innerhalb der virtuellen Instanzenschicht, einer Menge von virtuellen Instanzen, um Daten zu empfangen, die von einer cloudbasierten Speicherebene des cloudbasierten Speichersystems wiederhergestellt wurden; und Wiederherstellen, in der Menge von virtuellen Instanzen an der virtuellen Instanzenschicht, von Daten von der cloudbasierten Speicherebene des cloudbasierten Speichersystems.

Description

  • Figurenliste
  • Es zeigen:
    • 1A ein erstes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1B ein zweites Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1C ein drittes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1D ein viertes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 2A eine perspektivische Ansicht eines Storage-Clusters mit mehreren Speicherknoten und internem Speicher, der an jeden Speicherknoten gekoppelt ist, um gemäß einigen Ausführungsformen Network Attached Storage bereitzustellen.
    • 2B ein Blockdiagramm, das einen Interconnect-Switch zeigt, der gemäß einigen Ausführungsformen mehrere Speicherknoten koppelt.
    • 2C ein Blockdiagramm mit mehreren Ebenen, das den Inhalt eines Speicherknotens und den Inhalt einer der nichtflüchtigen Solid-State-Speichereinheiten gemäß einigen Ausführungsformen zeigt.
    • 2D eine Speicherserver-Umgebung, die Ausführungsformen der Speicherknoten und Speichereinheiten einiger vorhergehender Figuren in Übereinstimmung mit einigen Ausführungsformen verwendet.
    • 2E ist ein Blade-Hardware-Blockdiagramm, das eine Steuerungsebene, Rechen- und Speicherebenen und Authorities zeigt, die mit den zugrunde liegenden physischen Ressourcen interagieren, in Übereinstimmung mit einigen Ausführungsformen.
    • 2F Elasticity Software Layers in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 2G Authorities und Speicherressourcen in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 3A ein Diagramm eines Speichersystems, das für die Datenkommunikation mit einem 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 cloudbasiertes Speichersystem in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 3D ein beispielhaftes Computergerät, das speziell für die Durchführung eines oder mehrerer der hier beschriebenen Prozesse konfiguriert werden kann.
    • 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.
    • 10A eine Illustration eines beispielhaften cloudbasierten Speichersystems gemäß einigen Ausführungsformen.
    • 10B eine Illustration eines beispielhaften cloudbasierten Speichersystems gemäß einigen Ausführungsformen.
    • 11 ein Flussdiagramm, das ein zusätzliches Beispielverfahren zur Datenwiederherstellung in einem cloudbasierten Speichersystem veranschaulicht.
    • 12 ein Flussdiagramm, das ein zusätzliches Beispielverfahren zur Datenwiederherstellung in einem cloudbasierten Speichersystem veranschaulicht.
    • 13 ein Flussdiagramm, das ein zusätzliches Beispielverfahren zur Datenwiederherstellung in einem cloudbasierten Speichersystem veranschaulicht.
  • BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
  • Beispielhafte Verfahren, Vorrichtungen und Produkte zum Bereitstellen einer Speicherverwaltung für ein 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 Meiden 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 170A-B 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 („PIE“), 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 102A-B entlasten, indem sie von den Speicherlaufwerken 171A-F Steuerinformationen abrufen, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben. Das Abrufen der Steuerinformationen von den Speicherlaufwerken 171A-F kann z.B. durch den Speicher-Array-Controller 110A-D erfolgen, der die Speicherlaufwerke 171A-F nach dem Ort der Steuerinformationen für ein bestimmtes Speicherlaufwerk 171A-F abfragt. Die Speicherlaufwerke 171A-F können für die Ausführung von Befehlen konfiguriert werden, die es dem Speicherlaufwerk 171A-F ermöglichen, den Ort der Steuerinformationen zu ermitteln. Die Befehle können von einem Controller (nicht abgebildet) ausgeführt werden, der mit dem Speicherlaufwerk 171A-F verbunden ist oder sich anderweitig auf dem Speicherlaufwerk 171A-F befindet und der das Speicherlaufwerk 171A-F veranlassen kann, einen Teil jedes Speicherblocks abzutasten, um die Speicherblöcke zu ermitteln, die Steuerinformationen für die Speicherlaufwerke 171A-F speichern. Die Speicherlaufwerke 171A-F können antworten, indem sie eine Antwortnachricht an den Speicher-Array-Controller 110A-D senden, die den Ort der Steuerinformationen für das Speicherlaufwerk 171A-F enthält. Als Reaktion auf 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 PCle-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 PCl-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äte 119a-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 PCl-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 PCl-Busse 128a, 128b betreiben. Alternativ kann eine PCI/NVMe/NVMf-Switching-lnfrastruktur 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 vorstehend 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.
  • Zur weiteren Erläuterung ist in 3C ein Beispiel für ein cloudbasiertes Speichersystem 318 gemäß einigen Ausführungsformen der vorliegenden Offenlegung dargestellt. In dem in 3C dargestellten Beispiel wird das cloudbasierte Speichersystem 318 vollständig in einer Cloud-Computing-Umgebung 316 erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere. Das cloudbasierte Speichersystem 318 kann verwendet werden, um Dienste bereitzustellen, die den Diensten ähnlich sind, die von den oben beschriebenen Speichersystemen bereitgestellt werden können. Beispielsweise kann das cloudbasierte Speichersystem 318 verwendet werden, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems 318 bereitzustellen, das cloudbasierte Speichersystem 318 kann verwendet werden, um Speicherdienste für Benutzer des cloudbasierten Speichersystems 318 durch die Verwendung von Solid-State-Speicher bereitzustellen, und so weiter.
  • Das in 3C dargestellte cloudbasierte Speichersystem 318 umfasst zwei Cloud-Computing-Instanzen 320, 322, die jeweils zur Unterstützung der Ausführung einer Speicher-Controller-Anwendung 324, 326 verwendet werden. Die Cloud-Computing-Instanzen 320, 322 können beispielsweise als Instanzen von Cloud-Computing-Ressourcen (z. B. virtuelle Maschinen) verkörpert sein, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden können, um das Ausführen von Softwareanwendungen wie der Speicher-Controller-Anwendung 324, 326 zu unterstützen. In einer Ausführungsform können die Cloud-Computing-Instanzen 320, 322 als Amazon Elastic Compute Cloud („EC2“)-Instanzen verkörpert sein. In einem solchen Beispiel kann ein Amazon Machine Image („AMI“), das die Speicher-Controller-Anwendung 324, 326 enthält, gebootet werden, um eine virtuelle Maschine zu erstellen und zu konfigurieren, die die Speicher-Controller-Anwendung 324, 326 ausführen kann.
  • In dem in 3C dargestellten Beispielverfahren kann die Speicher-Controller-Anwendung 324, 326 als ein Modul von Computerprogrammanweisungen ausgeführt werden, das bei seiner Ausführung verschiedene Speicheraufgaben durchführt. Beispielsweise kann die Speicher-Controller-Anwendung 324, 326 als ein Modul von Computerprogrammanweisungen ausgeführt werden, das, wenn es ausgeführt wird, dieselben Aufgaben wie die oben beschriebenen Steuerungen 110A, 110B in 1A ausführt, wie z. B. das Schreiben von Daten, die von den Benutzern des cloudbasierten Speichersystems 318 empfangen werden, in das cloudbasierte Speichersystem 318, Löschen von Daten aus dem cloudbasierten Speichersystem 318, Abrufen von Daten aus dem cloudbasierten Speichersystem 318 und Bereitstellen solcher Daten für Benutzer des cloudbasierten Speichersystems 318, Überwachen der Festplattenauslastung und -leistung und Berichten darüber, Durchführen von Redundanzoperationen, wie RAID- oder RAID-ähnliche Datenredundanzoperationen, Komprimieren von Daten, Verschlüsseln von Daten, Deduplizieren von Daten und so weiter. Für den Leser ist zu erkennen, dass aufgrund der Tatsache, dass es zwei Cloud-Computing-Instanzen 320, 322 gibt, die jeweils die Speicher-Controller-Anwendung 324, 326 enthalten, in einigen Ausführungsformen eine Cloud-Computing-Instanz 320 als der primäre Controller wie oben beschrieben arbeiten kann, während die andere Cloud-Computing-Instanz 322 als sekundärer Controller wie oben beschrieben arbeiten kann. In einem solchen Beispiel kann, um Kosten zu sparen, die Cloud-Computing-Instanz 320, die als primärer Controller arbeitet, auf einer relativ leistungsstarken und relativ teuren Cloud-Computing-Instanz eingesetzt werden, während die Cloud-Computing-Instanz 322, die als sekundärer Controller arbeitet, auf einer relativ leistungsschwachen und relativ kostengünstigen Cloud-Computing-Instanz eingesetzt werden kann. Für den Leser ist zu erkennen, dass die in 3C dargestellte Speicher-Controller-Anwendung 324, 326 identischen Quellcode enthalten kann, der in verschiedenen Cloud-Computing-Instanzen 320, 322 ausgeführt wird.
  • In einem Beispiel soll hier die Cloud-Computing-Umgebung 316 als AWS und die Cloud-Computing-Instanzen als EC2-Instanzen verkörpert sein. In einem solchen Beispiel bietet AWS viele Arten von EC2-Instanzen an. AWS bietet zum Beispiel eine Reihe von EC2-Instanzen für allgemeine Zwecke an, die unterschiedliche Level an Speicher- und Verarbeitungsleistungen umfassen. In einem solchen Beispiel kann die Cloud-Computing-Instanz 320, die als primärer Controller arbeitet, bei einem der Instanztypen eingesetzt werden, der eine relativ große Menge an Speicher und Verarbeitungsleistung aufweist, während die Cloud-Computing-Instanz 322, die als sekundärer Controller arbeitet, bei einem der Instanztypen eingesetzt werden kann, der eine relativ kleine Menge an Speicher und Verarbeitungsleistung aufweist. In einem solchen Beispiel kann beim Auftreten eines Failover-Ereignisses, bei dem die Rollen von primär und sekundär getauscht werden, tatsächlich ein doppeltes Failover durchgeführt werden, so dass: 1) ein erstes Failover-Ereignis, bei dem die Cloud-Computing-Instanz 322, die zuvor als sekundärer Controller betrieben wurde, als primärer Controller zu arbeiten beginnt, und 2) eine dritte Cloud-Computing-Instanz (nicht dargestellt) - die von einem Instanztyp ist, der eine relativ große Menge an Speicher und Verarbeitungsleistung aufweist - mit einer Kopie der Speicher-Controller-Anwendung hochgefahren wird, wobei die dritte Cloud-Computing-Instanz als primärer Controller zu arbeiten beginnt, während die Cloud-Computing-Instanz 322, die ursprünglich als sekundärer Controller betrieben wurde, wieder als sekundärer Controller zu arbeiten beginnt. In einem solchen Beispiel kann die Cloud-Computing-Instanz 320, die zuvor als primärer Controller betrieben wurde, beendet werden. Für den Leser ist zu erkennen, dass in alternativen Ausführungsformen die Cloud-Computing-Instanz 320, die nach dem Failover-Ereignis als sekundärer Controller arbeitet, weiterhin als sekundärer Controller arbeiten kann und die Cloud-Computing-Instanz 322, die nach dem Auftreten des Failover-Ereignisses als primärer Controller arbeitete, beendet werden kann, sobald die primäre Rolle von der dritten Cloud-Computing-Instanz (nicht dargestellt) übernommen wurde.
  • Für den Leser ist zu erkennen, dass sich die oben beschriebenen Ausführungsformen zwar auf Ausführungsformen beziehen, bei denen eine Cloud-Computing-Instanz 320 als primärer Controller und die zweite Cloud-Computing-Instanz 322 als sekundärer Controller arbeitet, dass aber auch andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenlegung fallen. Beispielsweise kann jede Cloud-Computing-Instanz 320, 322 als ein primärer Controller für einen Teil des Adressraums arbeiten, der von dem cloudbasierten Speichersystem 318 unterstützt wird, jede Cloud-Computing-Instanz 320, 322 kann als ein primärer Controller arbeiten, bei dem die Bedienung von E/A-Operationen, die an das cloudbasierte Speichersystem 318 gerichtet sind, auf eine andere Weise aufgeteilt ist, und so weiter. In anderen Ausführungsformen, in denen Kosteneinsparungen Vorrang vor Leistungsanforderungen haben können, kann sogar nur eine einzige Cloud-Computing-Instanz existieren, die die Speicher-Controller-Anwendung enthält. In einem solchen Beispiel kann die Wiederherstellung nach einem Controller-Ausfall mehr Zeit in Anspruch nehmen, da eine neue Cloud-Computing-Instanz, die die Speicher-Controller-Anwendung enthält, hochgefahren werden muss, anstatt dass eine bereits erstellte Cloud-Computing-Instanz die Rolle der Bedienung von E/A-Operationen übernimmt, die ansonsten von der ausgefallenen Cloud-Computing-Instanz übernommen worden wären.
  • Das in 3C dargestellte cloudbasierte Speichersystem 318 umfasst Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338. Die in 3C dargestellten Cloud-Computing-Instanzen 340a, 340b, 340n können beispielsweise als Instanzen von Cloud-Computing-Ressourcen verkörpert sein, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden können, um das Ausführen von Softwareanwendungen zu unterstützen. Die Cloud-Computing-Instanzen 340a, 340b, 340n von 3C können sich von den oben beschriebenen Cloud-Computing-Instanzen 320, 322 unterscheiden, da die Cloud-Computing-Instanzen 340a, 340b, 340n von 3C über lokale Speicherressourcen 330, 334, 338 verfügen, während die Cloud-Computing-Instanzen 320, 322, die die Ausführung der Speicher-Controller-Anwendung 324, 326 unterstützen, keine lokalen Speicherressourcen aufweisen müssen. Die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 können beispielsweise als EC2 M5-Instanzen, die eine oder mehrere SSDs enthalten, als EC2 R5-lnstanzen, die eine oder mehrere SSDs enthalten, als EC2 I3-Instanzen, die eine oder mehrere SSDs enthalten, usw. verkörpert sein. In einigen Ausführungsformen muss der lokale Speicher 330, 334, 338 als Solid-State-Speicher (z. B. SSDs) ausgeführt sein und nicht als Speicher, der Festplattenlaufwerke verwendet.
  • In dem in 3C dargestellten Beispiel kann jede der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 einen Software-Daemon 328, 332, 336 enthalten, der, wenn er von einer Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, sich den Speicher-Controller-Anwendungen 324, 326 so präsentieren kann, als wäre die Cloud-Computing-Instanz 340a, 340b, 340n ein physisches Speichergerät (z. B. eine oder mehrere SSDs). In einem solchen Beispiel kann der Software-Daemon 328, 332, 336 Computerprogrammanweisungen enthalten, die denen ähnlich sind, die normalerweise auf einem Speichergerät enthalten wären, so dass die Speicher-Controller-Anwendungen 324, 326 die gleichen 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 324, 326 Code enthalten, der identisch (oder im Wesentlichen identisch) mit dem Code ist, der von den Controllern in den oben beschriebenen Speichersystemen ausgeführt werden würde. In diesen und ähnlichen Ausführungsformen kann die Kommunikation zwischen den Speicher-Controller-Anwendungen 324, 326 und den Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 iSCSI, NVMe over TCP, Messaging, ein benutzerdefiniertes Protokoll oder einen anderen Mechanismus verwenden.
  • In dem in 3C dargestellten Beispiel kann jede der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 auch mit einem Blockspeicher 342, 344, 346 gekoppelt sein, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird. Der Blockspeicher 342, 344, 346, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird, kann z. B. als Amazon Elastic Block Store („EBS“) -Volumen verkörpert werden. Beispielsweise kann ein erstes EBS-Volumen mit einer ersten Cloud-Computing-Instanz 340a, ein zweites EBS-Volumen mit einer zweiten Cloud-Computing-Instanz 340b und ein drittes EBS-Volumen mit einer dritten Cloud-Computing-Instanz 340n gekoppelt sein. In einem solchen Beispiel kann der Blockspeicher 342, 344, 346, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird, in ähnlicher Weise genutzt werden, wie die oben beschriebenen NVRAM-Geräte genutzt werden, da der Software-Daemon 328, 332, 336 (oder ein anderes Modul), der in einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, beim Empfang einer Anforderung zum Schreiben von Daten, ein Schreiben von Daten in sein angeschlossenes EBS-Volume sowie ein Schreiben von Daten in seine lokalen Speicherressourcen 330, 334, 338 initiieren kann. In einigen alternativen Ausführungsformen können Daten nur in die lokalen Speicherressourcen 330, 334, 338 innerhalb einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n geschrieben werden. In einer alternativen Ausführungsform kann statt der Verwendung des Blockspeichers 342, 344, 346, der von der Cloud-Computing-Umgebung 316 als NVRAM bereitgestellt wird, der tatsächliche Arbeitsspeicher auf jeder der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als NVRAM verwendet werden, wodurch die Netzwerknutzungskosten, die mit der Verwendung eines EBS-Volumens als NVRAM verbunden wären, gesenkt werden.
  • In dem in 3C dargestellten Beispiel können die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 von Cloud-Computing-Instanzen 320, 322 verwendet werden, die das Ausführen der Speicher-Controller-Anwendung 324, 326 unterstützen, um E/A-Vorgänge zu bedienen, die an das cloudbasierte Speichersystem 318 gerichtet sind. In einem Beispiel soll hier eine erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, als der primäre Controller arbeiten. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, (direkt oder indirekt über den sekundären Controller) Anfragen zum Schreiben von Daten in das cloudbasierte Speichersystem 318 von Benutzern des cloudbasierten Speichersystems 318 erhalten. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, verschiedene Aufgaben durchführen, wie zum Beispiel 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, und so weiter, 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 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 gesendet wird. Jede der Cloud-Computing-Instanzen 320, 322 kann in einigen Ausführungsformen eine Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem 318 empfangen und kann schließlich eine Anforderung zum Lesen von Daten an eine oder mehrere der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 senden.
  • Für den Leser ist zu erkennen, dass, wenn eine Anforderung zum Schreiben von Daten von einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 empfangen wird, der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammanweisungen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, so konfiguriert sein kann, um die Daten nicht nur in seinen eigenen lokalen Speicher 330, 334, 338 und jeden geeigneten Blockspeicher 342, 344, 346 zu schreiben, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden, sondern der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammanweisungen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, kann auch so konfiguriert sein, dass er die Daten in den cloudbasierten Objektspeicher 348 schreibt, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist. Der cloudbasierte Objektspeicher 348, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist, kann beispielsweise als Amazon Simple Storage Service („S3“) Speicher ausgeführt sein, auf den die bestimmte Cloud-Computing-Instanz 340a, 340b, 340n zugreifen kann. In anderen Ausführungsformen können die Cloud-Computing-Instanzen 320, 322, die jeweils die Speicher-Controller-Anwendung 324, 326 enthalten, die Speicherung der Daten im lokalen Speicher 330, 334, 338 der Cloud-Computing-Instanzen 340a, 340b, 340n und dem cloudbasierten Objektspeicher 348 initiieren.
  • Für den Leser ist zu erkennen, dass, wie oben beschrieben, das cloudbasierte Speichersystem 318 verwendet werden kann, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems 318 bereitzustellen. Während die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, den Zugriff auf Blockebene unterstützen können, unterstützt der cloudbasierte Objektspeicher 348, der mit der jeweiligen Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist, nur den objektbasierten Zugriff. Um dies zu beheben, kann der Software-Daemon 328, 332, 336 oder ein anderes Modul mit Computerprogrammanweisungen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, so konfiguriert sein, dass er Datenblöcke aufnimmt, diese Blöcke in Objekte verpackt und die Objekte in den cloudbasierten Objektspeicher 348 schreibt, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist.
  • In einem Beispiel sollen hier Daten in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346 geschrieben werden, die von den Cloud-Computing-Instanzen 340a, 340b, 340n in 1-MB-Blöcken genutzt werden. Es soll angenommen werden, dass in einem solchen Beispiel ein Benutzer des cloudbasierten Speichersystems 318 eine Anfrage zum Schreiben von Daten stellt, die nach der Komprimierung und Deduplizierung durch die Speicher-Controller-Anwendung 324, 326 dazu führen, dass 5 MB an Daten geschrieben werden müssen. In einem solchen Beispiel ist das Schreiben der Daten in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, relativ einfach, da 5 Blöcke mit einer Größe von 1 MB in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, geschrieben werden. In einem solchen Beispiel kann der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammanweisungen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, konfiguriert sein, um 1. ein erstes Objekt zu erzeugen, das die ersten 1 MB Daten enthält, und das erste Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, 2. ein zweites Objekt zu erzeugen, das die zweiten 1 MB Daten enthält, und das zweite Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, 3. ein drittes Objekt zu erzeugen, das die dritten 1 MB Daten enthält, und das dritte Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, und so weiter. So kann in einigen Ausführungsformen jedes Objekt, das in den cloudbasierten Objektspeicher 348 geschrieben wird, eine identische (oder nahezu identische) Größe aufweisen. 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 sind Metadaten, die mit den Daten verbunden sind).
  • Für den Leser ist zu erkennen, dass der cloudbasierte Objektspeicher 348 in das cloudbasierte Speichersystem 318 integriert werden kann, um die Lebensdauer des cloudbasierten Speichersystems 318 zu erhöhen. Wenn man mit dem oben beschriebenen Beispiel fortfährt, bei dem die Cloud-Computing-Instanzen 340a, 340b, 340n EC2-Instanzen sind, wird der Leser erkennen, dass EC2-lnstanzen nur eine monatliche Betriebszeit von 99,9 % garantieren und dass 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 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als einzige Quelle für persistenten Datenspeicher im cloudbasierten Speichersystem 318 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 das Verlassen auf EBS als persistenten Datenspeicher im cloudbasierten Speichersystem 318 zu einem Speichersystem führen, das nicht ausreichend langlebig ist. Amazon S3 hingegen ist für eine Haltbarkeit von 99,999999999 % ausgelegt, was bedeutet, dass ein cloudbasiertes Speichersystem 318, das S3 in seinen Speicherpool einbinden kann, wesentlich langlebiger ist als verschiedene andere Optionen.
  • Für den Leser ist zu erkennen, dass ein cloudbasiertes Speichersystem 318, das S3 in seinen Speicherpool einbinden kann, zwar wesentlich langlebiger ist als verschiedene andere Optionen, dass aber die Verwendung von S3 als primärer Speicherpool zu einem Speichersystem führen kann, das relativ langsame Reaktionszeiten und relativ lange E/A-Latenzen aufweist. So speichert das in 3C dargestellte cloudbasierte Speichersystem 318 nicht nur Daten in S3, sondern das cloudbasierte Speichersystem 318 speichert auch Daten in lokalen Speicherressourcen 330, 334, 338 und Blockspeicherressourcen 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, so dass Leseoperationen von den Ressourcen des lokalen Speichers 330, 334, 338 und den Ressourcen des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, bedient werden können, wodurch die Leselatenz reduziert wird, wenn Benutzer des cloudbasierten Speichersystems 318 versuchen, Daten aus dem cloudbasierten Speichersystem 318 zu lesen.
  • In einigen Ausführungsformen können alle Daten, die vom cloudbasierten Speichersystem 318 gespeichert werden, sowohl 1. im cloudbasierten Objektspeicher 348 als auch 2. in mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, gespeichert werden. In solchen Ausführungsformen können die lokalen Speicherressourcen 330, 334, 338 und die Blockspeicherressourcen 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt 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 durch die Cloud-Computing-Instanzen 340a, 340b, 340n bedient werden können, ohne dass die Cloud-Computing-Instanzen 340a, 340b, 340n auf den cloudbasierten Objektspeicher 348 zugreifen müssen. Für den Leser ist zu erkennen, dass in anderen Ausführungsformen jedoch alle Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, in dem cloudbasierten Objektspeicher 348 gespeichert werden können, aber weniger als alle Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, in mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346 gespeichert werden können, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden. In einem solchen Beispiel können verschiedene Richtlinien verwendet werden, um zu bestimmen, welche Teilmenge der Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, sich sowohl in 1. dem cloudbasierten Objektspeicher 348 als auch in 2. mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, befinden sollte.
  • Wie vorstehend beschrieben, wenn die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als EC2-lnstanzen ausgeführt werden, wird für die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 nur eine monatliche Betriebszeit von 99,9 % garantiert, und die im lokalen Instanzspeicher gespeicherten Daten bleiben nur während der Lebensdauer jeder Cloud-Computing-Instanz 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 erhalten. Als solches können ein oder mehrere Module von Computerprogrammanweisungen, die innerhalb des cloudbasierten Speichersystems 318 ausgeführt werden (z. B. ein Überwachungsmodul, das auf seiner eigenen EC2-Instanz ausgeführt wird), dafür ausgelegt sein, den Ausfall einer oder mehrerer der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 zu handhaben. In einem solchen Beispiel kann das Überwachungsmodul den Ausfall einer oder mehrerer der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 handhaben, indem es eine oder mehrere neue Cloud-Computing-Instanzen mit lokalem Speicher erstellt, Daten, die auf den ausgefallenen Cloud-Computing-Instanzen 340a, 340b, 340n gespeichert waren, aus dem cloudbasierten Objektspeicher 348 abruft und die aus dem cloudbasierten Objektspeicher 348 abgerufenen Daten im lokalen Speicher der neu erstellten Cloud-Computing-Instanzen speichert. Für den Leser ist zu erkennen, dass viele Varianten dieses Prozesses implementiert werden können.
  • In einem Beispiel soll angenommen werden, dass alle Cloud Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 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 und lokalem Speicher und dem cloudbasierten Objektspeicher 348 ermöglichen. Für den Leser ist zu erkennen, dass Instanztypen ausgewählt werden, die die maximalen Datenübertragungsraten zwischen den neuen Cloud-Computing-Instanzen und dem cloudbasierten Objektspeicher 348 ermöglichen, so dass die neuen Cloud-Computing-Instanzen mit hoher Bandbreite so schnell wie möglich mit Daten aus dem cloudbasierten Objektspeicher 348 rehydriert werden können. Sobald die neuen Cloud-Computing-Instanzen mit hoher Bandbreite mit Daten aus dem cloudbasierten Objektspeicher 348 rehydriert sind, können kostengünstigere Cloud-Computing-Instanzen mit geringerer Bandbreite erstellt werden, 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 neuen Cloud-Computing-Instanzen, die erstellt werden, die Anzahl der Cloud-Computing-Instanzen, die benötigt werden, um alle vom cloudbasierten Speichersystem 318 gespeicherten Daten lokal zu speichern, deutlich übersteigen kann. Die Anzahl der neuen Cloud-Computing-Instanzen, die erstellt werden, kann die Anzahl der Cloud-Computing-Instanzen, die benötigt werden, um alle vom cloudbasierten Speichersystem 318 gespeicherten Daten lokal zu speichern, deutlich übersteigen, um Daten schneller aus dem cloudbasierten Objektspeicher 348 und in die neuen Cloud-Computing-Instanzen zu ziehen, da jede neue Cloud-Computing-Instanz (parallel) einen Teil der vom cloudbasierten Speichersystem 318 gespeicherten Daten abrufen kann. In solchen Ausführungsformen können die Daten, sobald sie vom cloudbasierten Speichersystem 318 in die neu erstellten Cloud-Computing-Instanzen gezogen wurden, in einer Teilmenge der neu erstellten Cloud-Computing-Instanzen konsolidiert werden, und die neu erstellten Cloud-Computing-Instanzen, die überzählig sind, können beendet werden.
  • In einem Beispiel soll angenommen werden, dass 1.000 Cloud-Computing-Instanzen benötigt werden, um alle gültigen Daten lokal zu speichern, die Benutzer des cloudbasierten Speichersystems 318 in das cloudbasierte Speichersystem 318 geschrieben haben. In einem solchen Beispiel soll angenommen werden, dass alle 1.000 Cloud-Computing-Instanzen ausfallen. In einem solchen Beispiel kann das Überwachungsmodul veranlassen, dass 100.000 Cloud-Computing-Instanzen erstellt werden, wobei jede Cloud-Computing-Instanz dafür verantwortlich ist, aus dem cloudbasierten Objektspeicher 348 eindeutige 1/100.000ste Teile der gültigen Daten abzurufen, die Benutzer des cloudbasierten Speichersystems 318 in das cloudbasierte Speichersystem 318 geschrieben haben, und den eindeutigen Teil des Datensatzes, den sie abgerufen hat, lokal zu speichern. Da in einem solchen Beispiel jede der 100.000 Cloud-Computing-Instanzen parallel Daten aus dem cloudbasierten Objektspeicher 348 abrufen kann, kann die Caching-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 Cloud-Computing-Instanzen gespeichert sind, in 1.000 Cloud-Computing-Instanzen konsolidiert werden und die verbleibenden 99.000 Cloud-Computing-Instanzen könnten beendet werden.
  • Für den Leser ist zu erkennen, dass verschiedene Leistungsaspekte des cloudbasierten Speichersystems 318 überwacht werden können (z. B. durch ein Überwachungsmodul, das in einer EC2-Instanz ausgeführt wird), sodass das cloudbasierte Speichersystem 318 je nach Bedarf herauf- oder herabskaliert werden kann. In einem Beispiel soll angenommen werden, dass das Überwachungsmodul die Leistung des cloudbasierten Speichersystems 318 über die Kommunikation mit einer oder mehreren der Cloud-Computing-Instanzen 320, 322 überwacht, die jeweils verwendet werden, um das Ausführen einer Speicher-Controller-Anwendung 324, 326 zu unterstützen, über die Überwachung der Kommunikation zwischen den Cloud-Computing-Instanzen 320, 322, 340a, 340b, 340n, über die Überwachung der Kommunikation zwischen den Cloud-Computing-Instanzen 320, 322, 340a, 340b, 340n und dem cloudbasierten Objektspeicher 348 oder auf eine andere Weise. Nehmen wir in einem solchen Beispiel an, dass das Überwachungsmodul feststellt, dass die Cloud-Computing-Instanzen 320, 322, die verwendet werden, um das Ausführen einer Speicher-Controller-Anwendung 324, 326 zu unterstützen, unterdimensioniert sind und die E/A-Anforderungen, die von Benutzern des cloudbasierten Speichersystems 318 ausgegeben werden, nicht ausreichend bedienen. In einem solchen Beispiel kann das Überwachungsmodul eine neue, leistungsfähigere Cloud-Computing-Instanz erstellen (z. B. eine Cloud-Computing-Instanz eines Typs, der mehr Verarbeitungsleistung, mehr Speicher usw. umfasst), die die Speicher-Controller-Anwendung enthält, so dass die neue, leistungsfähigere Cloud-Computing-Instanz den Betrieb als primärer Controller aufnehmen kann. Ebenso kann das Überwachungsmodul, wenn es feststellt, dass die Cloud-Computing-Instanzen 320, 322, die zur Unterstützung der Ausführung einer Speicher-Controller-Anwendung 324, 326 verwendet werden, überdimensioniert sind und dass Kosteneinsparungen durch den Wechsel zu einer kleineren, weniger leistungsfähigen Cloud-Computing-Instanz erzielt werden können, eine neue, weniger leistungsfähige (und kostengünstigere) Cloud-Computing-Instanz erstellen, die die Speicher-Controller-Anwendung enthält, sodass die neue, weniger leistungsfähige Cloud-Computing-Instanz als primärer Controller in Betrieb genommen werden kann.
  • In einem weiteren Beispiel für die dynamische Größenbestimmung des cloudbasierten Speichersystems 318 soll angenommen werden, dass das Überwachungsmodul feststellt, dass die Auslastung des lokalen Speichers, der gemeinsam von den Cloud-Computing-Instanzen 340a, 340b, 340n 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 erstellen, um den Pool an lokalem Speicher zu erweitern, der von den Cloud- Computing-Instanzen angeboten wird. Alternativ kann das Überwachungsmodul eine oder mehrere neue Cloud-Computing-Instanzen erstellen, die über größere Mengen an lokalem Speicher verfügen als die bereits vorhandenen Cloud-Computing-Instanzen 340a, 340b, 340n, so dass Daten, die in einer bereits vorhandenen Cloud-Computing-Instanz 340a, 340b, 340n gespeichert sind, in die eine oder mehreren neuen Cloud-Computing-Instanzen migriert werden können und die bereits vorhandene Cloud-Computing-Instanz 340a, 340b, 340n beendet werden kann, wodurch der Pool an lokalem Speicher, der von den Cloud-Computing-Instanzen angeboten wird, erweitert wird. Ebenso können, wenn der Pool an lokalem Speicher, der von den Cloud-Computing-Instanzen angeboten wird, unnötig groß ist, Daten konsolidiert und einige Cloud-Computing-Instanzen beendet werden.
  • Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem 318 durch ein Überwachungsmodul, das einen vorbestimmten Satz von Regeln anwendet, die relativ einfach oder relativ kompliziert sein können, automatisch hoch- und runtergefahren werden kann. Tatsächlich kann das Überwachungsmodul nicht nur den aktuellen Zustand des cloudbasierten Speichersystems 318 berücksichtigen, sondern das Überwachungsmodul kann auch prädiktive Richtlinien anwenden, die z. B. auf beobachtetem Verhalten (z. B. jede Nacht von 22 Uhr bis 6 Uhr morgens 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 318 auf aktuellen Leistungsmetriken, vorhergesagten Arbeitslasten und vielen anderen Faktoren, einschließlich Kombinationen davon, basieren.
  • Der Leser wird weiter verstehen, dass das cloudbasierte Speichersystem 318 sogar dynamisch skaliert werden kann, weil das cloudbasierte Speichersystem 318 auf eine Weise arbeitet, die dynamischer ist. In einem Beispiel soll die Garbage Collection betrachtet werden. In einem herkömmlichen Speichersystem ist die Menge an Speicherplatz festgelegt. Daher kann das Speichersystem an einem bestimmten Punkt gezwungen sein, eine Garbage Collection durchzuführen, da die Menge des verfügbaren Speichers so begrenzt ist, dass das Speichersystem kurz davor steht, keinen Speicher mehr zur Verfügung zu haben. Im Gegensatz dazu kann das hier beschriebene cloudbasierte Speichersystem 318 jederzeit zusätzlichen Speicher „hinzufügen“ (z. B. durch Hinzufügen weiterer Cloud-Computing-Instanzen mit lokalem Speicher). Da das hier beschriebene cloudbasierte Speichersystem 318 immer zusätzlichen Speicher „hinzufügen“ kann, kann das cloudbasierte Speichersystem 318 intelligentere Entscheidungen darüber treffen, wann eine Garbage Collection durchgeführt werden soll. Beispielsweise kann das cloudbasierte Speichersystem 318 eine Richtlinie implementieren, dass die Garbage Collection nur dann durchgeführt wird, wenn die Anzahl der vom cloudbasierten Speichersystem 318 bedienten IOPS 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 Systemlast ein- und ausgeschaltet werden, da die Größe des cloudbasierten Speichersystems 318 nicht auf die gleiche Weise eingeschränkt ist wie bei herkömmlichen Speichersystemen.
  • Der Leser wird verstehen, dass Ausführungsformen der vorliegenden Offenlegung ein Problem mit Blockspeicherdiensten lösen, die von einigen Cloud-Computing-Umgebungen angeboten werden, da einige Cloud-Computing-Umgebungen nur eine Cloud-Computing-Instanz zulassen, die sich mit einem Blockspeicher-Volume zu einem einzigen Zeitpunkt verbindet. In Amazon AWS kann zum Beispiel nur eine einzige EC2-Instanz mit einem EBS-Volume verbunden werden. Durch die Verwendung von EC2-Instanzen mit lokalem Speicher können Ausführungsformen der vorliegenden Offenlegung Multi-Connect-Funktionen bieten, bei denen sich mehrere EC2-Instanzen mit einer anderen EC2-Instanz mit lokalem Speicher („eine Laufwerksinstanz“) verbinden 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, E/A zu unterstützen, die von jeder verbundenen EC2-Instanz an ein bestimmtes Volume gerichtet ist. Als solche können einige Ausführungsformen der vorliegenden Offenlegung als Multi-Connect-Blockspeicherdienste ausgeführt werden, die möglicherweise nicht alle in 3C dargestellten Komponenten enthalten.
  • In einigen Ausführungsformen, insbesondere in Ausführungsformen, in denen die Ressourcen des cloudbasierten Objektspeichers 348 als Amazon S3 verkörpert sind, kann das cloudbasierte Speichersystem 318 ein oder mehrere Module (z. B. ein Modul mit Computerprogrammanweisungen, die auf einer EC2-Instanz ausgeführt werden) enthalten, 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 vorhanden sind. Dieses Problem tritt hauptsächlich deshalb auf, weil S3 ein Modell für Eventual Consistency 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 Offenlegung Objekte in S3 niemals überschrieben. Stattdessen würde ein herkömmliches „Überschreiben“ zum Erstellen des neuen Objekts (das die aktualisierte Version der Daten enthält) und zum eventuellen Löschen des alten Objekts (das die vorherige Version der Daten enthält) führen.
  • In einigen Ausführungsformen der vorliegenden Offenlegung kann als Teil eines Versuchs, ein Objekt nie (oder fast nie) zu überschreiben, das resultierende Objekt mit einer Sequenznummer versehen werden, wenn Daten in S3 geschrieben werden. In einigen Ausführungsformen können diese Sequenznummern an anderer Stelle (z. B. in einer Datenbank) aufbewahrt werden, so dass zu jedem Zeitpunkt die Sequenznummer bekannt ist, die mit der aktuellsten Version eines Teils der Daten verbunden ist. Auf diese Weise kann festgestellt werden, ob S3 über die aktuellste Version eines Teils der Daten verfügt, indem lediglich die mit einem Objekt verknüpfte Sequenznummer gelesen wird - ohne die Daten tatsächlich aus S3 zu lesen. Die Fähigkeit, dieses Bestimmen vorzunehmen, kann besonders wichtig sein, wenn eine Cloud-Computing-Instanz mit lokalem Speicher abstürzt, da es nicht erwünscht wäre, den lokalen Speicher einer Ersatz-Cloud-Computing-Instanz mit veralteten Daten zu rehydrieren. Da das cloudbasierte Speichersystem 318 nicht auf die Daten zugreifen muss, um ihre Gültigkeit zu überprüfen, können die Daten verschlüsselt bleiben und Zugriffsgebühren vermieden werden.
  • 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. Kl-Anwendungen zu unterstützen. Solche Kl-Anwendungen können Geräte in die Lage versetzen, ihre Umgebung wahrzunehmen und Maßnahmen zu ergreifen, die ihre Erfolgschancen 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 (Kl) erschließen können. Mit verbesserten Algorithmen, größeren Datensätzen und verschiedenen Frameworks (einschließlich Open-Source-Softwarebibliotheken 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 Kl 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 Kl-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 Kl-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 Kl zu unterstützen, da die Kl immer mehr für den Massenkonsum verfügbar wird. Die Demokratisierung der Kl kann z.B. die Fähigkeit einschließen, Kl 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 Kl 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 Kl nützlich sind. Als Teil der Demokratisierung der Kl kann eine Bewegung von der engen Kl, 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 Speicherebenen zu bewegen, oder die Speichersysteme können clientspezifische Software verwenden, um Daten zwischen den verschiedenen Speicherebenen 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 Kl als Service weniger wünschenswert sein als intern verwaltete und angebotene Kl 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 Kl-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 loT-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, loT-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 Kl-Plattformen implementieren, um die Vision der selbstfahrenden Speicherung zu verwirklichen. Solche Kl-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 Kl-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 Kl-Leiter bilden können. Eine solche Kl-Leiter kann effektiv durch die Kombination solcher Elemente zu einer vollständigen datenwissenschaftlichen Pipeline gebildet werden, wenn Abhängigkeiten zwischen Elementen der Kl-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 Kl weite und umfangreiche Aspekte des Geschäftslebens durchdringt. Beispielsweise kann die Kl 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, dialog orientierte 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 Welt ermöglichen. Tatsächlich können digitale Zwillinge mit der realen Welt verbunden werden, vielleicht sogar in Echtzeit, um den Zustand einer Sache oder eines Systems zu verstehen, auf Veränderungen zu reagieren 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 undtransparenz 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 undschemata 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 FPGAbeschleunigten Servern als Teil einer größeren Al- 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 FPGAbeschleunigte Server, eine Netzwerkinfrastruktur, die die Kommunikation zwischen dem einen oder den mehreren Speichersystemen und dem einen oder den mehreren FPGAbeschleunigten 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 Al- 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 Al-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 Netzwerkschnittstellenkarte), eine drahtlose Netzwerkschnittstelle (z. B. eine drahtlose Netzwerkschnittstellenkarte), ein Modem, eine Audio-Nideoverbindung 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-Instanz an ein bestimmtes Volume gerichtet ist. Als solche können einige Ausführungsformen der vorliegenden Offenbarung als Blockspeicherdienste mit mehreren Anschlüssen ausgeführt werden, die möglicherweise nicht alle in 4 dargestellten Komponenten umfassen.
  • In einigen Ausführungsformen, insbesondere in Ausführungsformen, in denen die Ressourcen des cloudbasierten Objektspeichers (432) als Amazon S3 verkörpert sind, kann das cloudbasierte Speichersystem (403) ein oder mehrere Module enthalten (z.B. ein Modul von Computerprogrammbefehlen, die auf einer EC2-Instanz ausgeführt werden), die so konfiguriert sind, dass sie sicherstellen, dass, wenn der lokale Speicher einer bestimmten Cloud-Computing-Instanz mit Daten aus S3 rehydriert wird, die entsprechenden Daten tatsächlich in S3 vorliegen. Diese Frage stellt sich vor allem deshalb, weil S3 ein mögliches Konsistenzmodell implementiert, bei dem beim Überschreiben eines vorhandenen Objekts die Lesevorgänge des Objekts schließlich (aber nicht unbedingt sofort) konsistent werden und schließlich (aber nicht unbedingt sofort) die überschriebene Version des Objekts zurückgeben. Um dieses Problem zu lösen, werden in einigen Ausführungsformen der vorliegenden Offenbarung Objekte in S3 niemals überschrieben. Stattdessen würde eine herkömmliche „Überschreibung“ zur Erstellung des neuen Objekts (das die aktualisierte Version der Daten enthält) und schließlich zur Löschung des alten Objekts (das die vorherige Version der Daten enthält) führen.
  • In einigen Ausführungsformen der vorliegenden Offenbarung, als Teil eines Versuchs, ein Objekt nie (oder fast nie) zu überschreiben, kann beim Schreiben von Daten nach S3 das resultierende Objekt mit einer Sequenznummer versehen werden. In einigen Ausführungsformen können diese Sequenznummern an anderer Stelle (z.B. in einer Datenbank) persistiert sein, so dass zu jedem Zeitpunkt die Sequenznummer bekannt sein kann, die mit der aktuellsten Version eines Datensegments verbunden ist. Auf diese Weise kann festgestellt werden, ob S3 über die aktuelle Version eines Datensegments verfügt, indem einfach die mit einem Objekt verbundene Sequenznummer gelesen wird - und ohne dass die Daten tatsächlich aus S3 gelesen werden. Die Möglichkeit, diese Bestimmung vorzunehmen, kann besonders wichtig sein, wenn eine Cloud-Computing-Instanz mit lokalem Speicher abstürzt, da es unerwünscht wäre, den lokalen Speicher einer Ersatz-Cloud-Computing-Instanz mit veralteten Daten zu rehydrieren. Da das cloudbasierte Speichersystem (403) nicht auf die Daten zugreifen muss, um ihre Gültigkeit zu verifizieren, können die Daten verschlüsselt bleiben und Zugriffsgebühren vermieden werden.
  • In dem in 4 dargestellten Beispiel und wie vorstehend beschrieben, können die Cloud-Computing-Instanzen (404, 406), die zur Unterstützung der Ausführung der 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. In einigen Ausführungsformen kann das Empfangen (606) der Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem das Empfangen der Anforderung zum Schreiben von Daten in den cloudbasierten Speicher durch eine Speicher-Controller-Anwendung umfassen, die in einer Cloud-Computing-Instanz ausgeführt wird. Die Speicher-Controller-Anwendung, die in einer Cloud-Computing-Instanz ausgeführt wird, kann den oben beschriebenen Speicher-Controller-Anwendungen ähnlich sein und kann z. B. in einer EC2-Instanz ausgeführt werden, wie vorstehend ausführlicher beschrieben wurde. Tatsächlich kann das cloudbasierte Speichersystem (604) mehrere EC2-Instanzen oder ähnliche Cloud-Computing-Instanzen umfassen, wobei mehrere Cloud-Computing-Instanzen jeweils die Speicher-Controller-Anwendung ausführen.
  • 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. In einigen Ausführungsformen kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems die Ausgabe einer Anweisung zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher durch die in der Cloud-Computing-Instanz ausgeführte Speicher-Controller-Anwendung umfassen. Die eine oder mehreren Cloud-Computing-Instanzen mit lokalem Speicher können den oben beschriebenen Cloud-Computing-Instanzen mit lokalem Speicher ähneln. In einigen Ausführungsformen 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 in der Cloud-Computing-Instanz ausgeführte Speicher-Controller-Anwendung die mehreren Cloud-Computing-Instanzen mit lokalem Speicher als einzelne Speichergeräte behandeln, so dass die in der Cloud-Computing-Instanz ausgeführte Speicher-Controller-Anwendung eine Anweisung zum Schreiben der Daten in den lokalen Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen mit lokalem Speicher ausgeben 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. Für den Leser ist zu erkennen, dass - 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 Quellen des Blockspeichers verbunden sein kann, der Speicher-Array-Controller nur mit einem einzigen EBS-Volumen verbunden sein könnte, wenn der Speicher-Array-Controller so konfiguriert wäre, dass er EBS als seinen Blockspeicher verwendet.
  • In einigen Ausführungsformen kann das Speichern (614) der Daten im Blockspeicher des cloudbasierten Speichersystems das Schreiben (1102) der Daten in einen oder mehrere Blöcke des Blockspeichers unter Verwendung eines Protokolls auf Blockebene umfassen. In dem in 6 dargestellten Beispielverfahren kann der Blockspeicher als ein oder mehrere Blockspeichergeräte, wie z. B. NAND-Flash-Speicher, verkörpert sein, in denen Daten in Blöcken gespeichert werden, die jeweils zum Speichern von Daten einer maximalen Größe (d. h. einer Blockgröße) verwendet werden können. Daten können in solche Speichergeräte mit einem Block-Level-Protokoll wie z. B. iSCSI, Fibre Channel und FCoE (Fibre Channel over Ethernet) usw. geschrieben werden. Für den Leser ist zu erkennen, dass durch das Schreiben der Daten in einen oder mehrere Blöcke des Blockspeichers unter Verwendung eines Block-Level-Protokolls die Daten, die in den Blockspeicher des cloudbasierten Speichersystems geschrieben werden, daher in Blöcken gespeichert werden.
  • In einigen Ausführungsformen können eine oder mehrere der mehreren Cloud-Computing-Instanzen mit lokalem Speicher zur Datenkommunikation mit mehreren Cloud-Computing-Instanzen gekoppelt sein, die jeweils die Speicher-Controller-Anwendung ausführen. Für den Leser ist zu erkennen, dass in einigen Ausführungsformen - da es eine Vielzahl von Cloud-Computing-Instanzen gibt, die jeweils die Speicher-Controller-Anwendung ausführen - eine Speicher-Controller-Anwendung, die auf einer ersten Cloud-Computing-Instanz ausgeführt wird, als primäre Steuerung dienen kann, während zusätzliche Speicher-Controller-Anwendungen, die auf zusätzlichen Cloud-Computing-Instanzen ausgeführt werden, als sekundäre Steuerungen dienen können, die bei Auftreten eines Ereignisses (z. B. Ausfall der primären Steuerung) die primäre Steuerung übernehmen können.
  • 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.
  • In dem in 6 dargestellten Beispielverfahren kann das Speichern (618) der Daten im Objektspeicher des cloudbasierten Speichersystems das Schreiben der Daten in ein oder mehrere Objekte im Objektspeicher umfassen, wobei die Daten ein Protokoll auf Objektebene nutzen. In einem solchen Beispiel kann der Objektspeicher so konfiguriert sein, dass er Daten als Objekte verwaltet, im Gegensatz zu anderen Speicherarchitekturen wie Dateisystemen, die Daten als eine Dateihierarchie verwalten, und Blockspeichern, die Daten als Blöcke verwalten. Ein solcher Objektspeicher kann auf der Geräteebene (Objektspeichergerät), der Systemebene, der Schnittstellenebene oder auf eine andere Weise implementiert sein. Daten können in den Objektspeicher geschrieben werden, indem ein Protokoll auf Objektebene verwendet wird, wie z. B. der SCSI-Befehlssatz für Objektspeichergeräte, RESTfuI- / HTTP-Protokolle, AWS S3 APIs, das Cloud Data Management Interface für den Zugriff auf Cloud-Speicher und andere. Für den Leser ist zu erkennen, dass durch das Schreiben 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 vorhergehenden Absatz der Fall war.
  • In dem in 6 dargestellten Beispielverfahren 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, sowohl die Daten selbst als auch die zugehörigen Metadaten enthalten kann, und jedes Objekt kann mit einer global eindeutigen Kennung verbunden sein - anstelle eines Dateinamens und eines Dateipfads, einer Blocknummer und so weiter. So können die Daten, die in einem bestimmten Block enthalten sind, in ein eindeutiges Objekt in dem Sinne geschrieben werden, dass das eindeutige Objekt die Daten selbst, die mit den Daten verknüpften Metadaten und eine global eindeutige Kennung enthält. In solchen Ausführungsformen kann das cloudbasierte Speichersystem daher eine Abbildung von jedem Datenblock, der im Blockspeicher des cloudbasierten Speichersystems gespeichert ist, und jedem Objekt, das im Objektspeicher des cloudbasierten Speichersystems gespeichert ist, aufrechterhalten. In einigen Ausführungsformen kann jedes Objekt die Daten enthalten, die in mehreren Blöcken enthalten sind, aber die Daten, die in mehreren Blöcken enthalten sind, müssen nur in einem einzigen Objekt gespeichert sein.
  • 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 Objektspeicherebene des cloudbasierten Speichersystems in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden, andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Da die Daten beispielsweise über den lokalen Speicher mehrerer Cloud-Computing-Instanzen unter Verwendung von Datenredundanzverfahren wie RAID verteilt sein können, können in einigen Ausführungsformen die verlorenen Daten durch einen RAID-Neuaufbau wieder in die Blockspeicherebene des cloudbasierten Speichersystems gebracht werden.
  • Zur weiteren Erläuterung ist in 8 ein Flussdiagramm dargestellt, das eine Beispielmethode zum Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem veranschaulicht (804). Obwohl es weniger detailliert dargestellt ist, kann das in 8 dargestellte cloudbasierte Speichersystem (804) ähnlich wie die vorstehend beschriebenen cloudbasierten Speichersysteme sein und von einer Cloud-Computing-Umgebung (802) unterstützt werden.
  • Die in 8 dargestellte Beispielmethode umfasst das Empfangen (806) einer Anforderung zum Schreiben von Daten in das cloudbasierte Speichersystem (804) durch das cloudbasierte Speichersystem (804). Die Anforderung zum Schreiben von Daten kann z.B. von einer in der Cloud-Computing-Umgebung ausgeführten Anwendung, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise empfangen werden. In einem solchen Beispiel kann die Anforderung die Daten enthalten, die in das cloudbasierte Speichersystem geschrieben werden sollen (804). In anderen Ausführungsformen kann die Anforderung, Daten in das cloudbasierte Speichersystem (804) zu schreiben, zur Boot-Zeit erfolgen, wenn das cloudbasierte Speichersystem (804) hochgefahren wird.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Deduplizieren (808) der Daten. Das Daten-Deduplizieren ist eine Datenreduktionstechnik zum Eliminieren von Dubletten von sich wiederholender Daten. Das cloudbasierte Speichersystem (804) kann die Daten deduplizieren (808), z.B. durch Vergleichen eines oder mehrerer Datenteile mit Daten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind, durch Vergleichen eines Fingerabdrucks für einen oder mehrere Datenteile mit Fingerabdrücken für Daten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind, oder auf andere Weise. In einem solchen Beispiel können doppelte Daten entfernt und durch einen Verweis auf eine bereits vorhandene Kopie der Daten ersetzt werden, die bereits im cloudbasierten Speichersystem (804) gespeichert ist.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Komprimieren (810) der Daten. Datenkomprimierung ist eine Datenreduktionstechnik, bei der Informationen mit weniger Bits als die ursprüngliche Darstellung kodiert werden. Das cloudbasierte Speichersystem (804) kann die Daten komprimieren (810), indem es einen oder mehrere Datenkomprimierungsalgorithmen auf die Daten anwendet, die zu diesem Zeitpunkt möglicherweise keine Daten enthalten, die bereits im cloudbasierten Speichersystem (804) gespeichert sind.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Verschlüsseln (812) der Daten. Bei der Datenverschlüsselung handelt es sich um eine Technik, bei der die Daten aus einem lesbaren Format in ein kodiertes Format umgewandelt werden, das erst nach dem Entschlüsseln der Daten gelesen oder verarbeitet werden kann. Das cloudbasierte Speichersystem (804) kann die Daten, die zu diesem Zeitpunkt möglicherweise bereits dedupliziert und komprimiert sind, mit einem Verschlüsselungsschlüssel verschlüsseln (812). Die Leser werden erkennen, dass, obwohl die in 8 dargestellte Ausführungsform das Deduplizieren (808) der Daten, das Komprimieren (810) der Daten und das Verschlüsseln (812) der Daten beinhaltet, andere Ausführungsformen existieren, in denen weniger dieser Schritte ausgeführt werden, und Ausführungsformen, in denen die gleiche Anzahl von Schritten oder weniger in einer anderen Reihenfolge ausgeführt werden.
  • Die in 8 dargestellte Beispielmethode beinhaltet auch das Speichern (814) der Daten im Blockspeicher des cloudbasierten Speichersystems (804). Das Speichern (814) der Daten im Blockspeicher des cloudbasierten Speichersystems (804) kann z.B. durch Speichern (816) der Daten im lokalen Speicher (z.B. SSDs) einer oder mehrerer Cloud-Computing-Instanzen erfolgen, wie oben ausführlicher beschrieben. In einem solchen Beispiel verteilen sich die Daten über den lokalen Speicher mehrerer Cloud-Computing-Instanzen zusammen mit Paritätsdaten, um RAID- oder RAID-ähnliche Datenredundanz zu implementieren.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Speichern (818) der Daten im Objektspeicher des cloudbasierten Speichersystems (804). Das Speichern (818) der Daten in Objektspeichern des cloudbasierten Speichersystems kann das Erzeugen (820) eines oder mehrerer gleich großer Objekte umfassen, wobei jedes gleich große Objekt ein bestimmtes Segment der Daten enthält, wie oben ausführlicher beschrieben.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Empfangen (822) einer Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem durch das cloudbasierte Speichersystem (804). Die Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem (804) kann beispielsweise von einer Anwendung empfangen werden, die in der Cloud-Computing-Umgebung ausgeführt wird, von einem Benutzer des Speichersystems, das kommunikativ mit der Cloud-Computing-Umgebung gekoppelt ist, und auf andere Weise. Die Anforderung kann z.B. eine logische Adresse der Daten enthalten, die aus dem cloudbasierten Speichersystem (804) gelesen werden sollen.
  • Die in 8 dargestellte Beispielmethode umfasst auch das Abrufen (824) der Daten aus dem Blockspeicher des cloudbasierten Speichersystems (804). Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem (804) die Daten aus dem Blockspeicher des cloudbasierten Speichersystems (804) abrufen (824) kann, z.B. indem die 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.
  • Für den Leser ist zu erkennen, dass, obwohl sich die oben beschriebenen Ausführungsformen auf Ausführungsformen beziehen, in denen Daten, die in dem Teil des Blockspeichers des cloudbasierten Speichersystems gespeichert waren, der nicht mehr verfügbar ist, im Wesentlichen in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden, indem die Daten aus der Objektspeicherebene des cloudbasierten Speichersystems abgerufen werden, andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenlegung fallen. Da beispielsweise Daten über den lokalen Speicher mehrerer Cloud-Computing-Instanzen unter Verwendung von Datenredundanztechniken wie RAID verteilt sein können, können in einigen Ausführungsformen die verlorenen Daten durch ein RAID-Rebuild in die Blockspeicherebene des cloudbasierten Speichersystems zurückgebracht werden.
  • Der Leser wird ferner verstehen, dass, obwohl die vorangegangenen Abschnitte cloudbasierte Speichersysteme und deren Betrieb beschreiben, die vorstehend beschriebenen cloudbasierten Speichersysteme verwendet werden können, um Blockspeicher als Dienst anzubieten, da die cloudbasierten Speichersysteme hochgefahren und verwendet werden können, um Blockdienste auf Anfrage und nach Bedarf bereitzustellen. In einem solchen Beispiel kann das Bereitstellen von Blockspeicher als Dienst in einer Cloud-Computing-Umgebung Folgendes umfassen: Empfangen einer Anforderung für Blockspeicherdienste von einem Benutzer; Erstellen eines Volumens für die Verwendung durch den Benutzer; Empfangen von E/A-Operationen, die an das Volumen gerichtet sind; und Weiterleiten der E/A-Operationen an ein Speichersystem, das sich zusammen mit Hardware-Ressourcen für die Cloud-Computing-Umgebung befindet.
  • Zur weiteren Erläuterung ist in 10A ein Beispiel für ein cloudbasiertes Speichersystem (1002) gemäß einigen Ausführungsformen der vorliegenden Offenlegung dargestellt. In dem in 10A dargestellten Beispiel wird das cloudbasierte Speichersystem (1002) vollständig innerhalb einer Cloud-Computing-Umgebung (402) erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere.
  • In einigen Implementierungen kann das cloudbasierte Speichersystem (1002) so ausgelegt sein, dass es sich nach einem Datenverlust wiederherstellt, indem es die Cloud-Architektur, die zum anfänglichen Speichern der Daten verwendet wurde, hochskaliert, um Daten schneller wiederherzustellen, als wenn die ursprüngliche Cloud-Architektur verwendet würde. Beispielsweise kann das cloudbasierte Speichersystem (1002), wie vorstehend unter Bezugnahme auf die 4 bis 9 beschrieben, Schichten oder Ebenen der Speicherung verwenden, wobei eine erste, nicht dauerhafte Ebene unter Verwendung virtueller Recheninstanzen und eine zweite, dauerhafte Ebene unter Verwendung eines cloudbasierten Objektspeichers implementiert ist. In diesem Beispiel können bei einem Datenverlust in der virtuellen Instanzebene die Daten aus dem cloudbasierten Objektspeicher wiederhergestellt werden, da der cloudbasierte Objektspeicher ein Repository für Daten ist, die in der virtuellen Instanzebene empfangen wurden.
  • In Fortsetzung dieses Beispiels kann als Reaktion auf einen Datenverlust, aufgrund eines Ausfalls einer virtuellen Instanz auf der Ebene der virtuellen Instanz, die verlorene virtuelle Instanz durch mehrere virtuelle Instanzen ersetzt werden, die mit den in der ausgefallenen virtuellen Instanz verlorenen Daten mit den Daten im cloudbasierten Objektspeicher wiederhergestellt werden können. Des Weiteren kann die Wiederherstellung der Daten der verlorenen virtuellen Instanz mit den Daten der cloudbasierten Objektspeicher-Ebene parallel durchgeführt werden. Auf diese Weise sind nach der Wiederherstellung Daten, die sich auf einer einzelnen ausgefallenen virtuellen Instanz befanden, auf mehreren virtuellen Instanzen gespeichert. Während in diesem Beispiel der Ausfall in Bezug auf eine einzelne virtuelle Instanz beschrieben wird, können im Allgemeinen mehrere virtuelle Instanzen auf der Ebene der virtuellen Instanz verloren gehen und jede dieser verlorenen virtuellen Instanzen kann durch mehr als eine virtuelle Ersatzinstanz ersetzt werden.
  • In einigen Implementierungen kann das cloudbasierte Speichersystem (1002) verwendet werden, um Dienste bereitzustellen, die den Diensten ähnlich sind, die von den oben beschriebenen Speichersystemen, wie dem cloudbasierten Speichersystem (520), bereitgestellt werden können. Beispielsweise kann das cloudbasierte Speichersystem (1002) verwendet werden, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems (1002) bereitzustellen, wobei ein Benutzer des cloudbasierten Speichersystems (1002) ein Cloud-Speicherdienstanbieter sein kann, der Speicherdienste für Benutzer des cloudbasierten Speichersystems (1002) bereitstellt durch die Verwendung von Festkörperspeichern, anderem physischen Speicher, virtuellem Speicher, einer Kombination aus physischem Speicher und virtuellem Speicher usw.
  • In einigen Implementierungen kann das cloudbasierte Speichersystem (1002) in einer Weise arbeiten, die dem in 4 dargestellten cloudbasierten Speichersystem (403) ähnlich ist, da das cloudbasierte Speichersystem (1002) eine Speicher-Controller-Anwendung (408) enthält, die innerhalb des cloudbasierten Speichersystems (1002) ausgeführt wird, wobei das cloudbasierte Speichersystem (1002) eine Recheninstanz innerhalb der Cloud-Computing-Umgebung (402) ist.
  • In dieser Beispielimplementierung eines cloudbasierten Speichersystems (1002) umfasst die Architektur des cloudbasierten Speichersystems (1002) zusätzlich zu einer Cloud-Computing-Instanz (404), die eine Speicher-Controller-Anwendung (408) implementiert, eine nicht dauerhafte Cloud-Speicherebene (1004) und eine dauerhafte Cloud-Speicherebene (1006). In einigen Beispielen kann die nicht dauerhafte Cloud-Speicherebene als virtuelle Instanzebene und die dauerhafte Cloud-Speicherebene als cloudbasierte Speicherebene bezeichnet werden.
  • (HINWEIS: Diese nächste Implementierung wurde zwar nicht offengelegt, wird aber hier vorgestellt, um möglichst viele mögliche Versionen eines cloudbasierten Speichersystems abzudecken). In einigen Implementierungen kann die cloudbasierte Speicherebene jedoch auch unter Verwendung virtueller Instanzen von nicht dauerhaftem Speicher implementiert werden. Mit anderen Worten, in einigen Beispielen kann es zwei oder mehr Schichten von nicht-dauerhaftem Speicher geben, wobei die Gesamtverbesserung der Dauerhaftigkeit im Vergleich zu einer einzelnen nicht-dauerhaften Speicherebene auf der geringen Wahrscheinlichkeit beruht, dass zwei virtuelle Instanzen auf verschiedenen nichtdauerhaften Speicherebenen ausfallen, so dass Daten von mindestens einer der virtuellen Instanzen auf einer der nicht-dauerhaften Speicherebenen nicht wiederherstellbar sind. In diesem Beispiel kann ein Ausfall einer virtuellen Instanz auf einer beliebigen Ebene der nicht dauerhaften Speicherebene durch Kopieren der verlorenen Daten von einer anderen nicht dauerhaften Speicherebene wiederhergestellt werden - wobei der Datenverlust auf einer beliebigen Ebene oder Stufe der mehreren nicht dauerhaften Speicherebenen auftreten kann. In einigen Beispielen können die virtuellen Instanzen auf den verschiedenen nicht dauerhaften Speicherebenen Spiegelungen voneinander sein, und in anderen Beispielen kann die Verteilung der Daten unter den virtuellen Instanzen zwischen den virtuellen Instanzen und den verschiedenen nicht dauerhaften Speicherebenen unterschiedlich sein.
  • In diesem Beispiel kann die nicht dauerhafte Cloud-Speicherebene weniger zuverlässig sein als die dauerhafte Cloud-Speicherebene, bei der alle von der Speichersteuerung (408) gespeicherten Daten in der nicht dauerhaften Speicherebene (1004) gespeichert werden und bei der die nicht dauerhafte Speicherebene (1004) dann alle von der Speichersteuerung (408) zur Speicherung empfangenen Daten in der dauerhaften Cloud-Speicherebene (1006) speichert. Ferner können in einigen Beispielen alle zur Speicherung von der Speichersteuerung (408) empfangenen Daten in der nicht dauerhaften Cloud-Speicherebene (1004) gespeichert bleiben, nachdem die Daten in der dauerhaften Cloud-Speicherebene gespeichert wurden. In anderen Beispielen kann die nicht dauerhafte Cloud-Speicherebene (1004) jedoch eine Teilmenge der von der Speichersteuerung (408) zur Speicherung empfangenen Daten speichern - zum Beispiel eine Teilmenge der empfangenen Daten, die gemäß einer Aufbewahrungsrichtlinie bestimmt wird -, wobei die dauerhafte Cloud-Speicherebene (1004) alle von der nicht dauerhaften Speicherebene (1004) zur Speicherung empfangenen Daten speichert. In einigen Beispielen kann die Aufbewahrungsrichtlinie Regeln oder Bedingungen festlegen, unter denen gespeicherte Daten gelöscht werden können.
  • In einigen Beispielen, wie oben unter Bezugnahme auf die 4 bis 9 näher beschrieben, kann der Speicher innerhalb der nicht dauerhaften Cloud-Speicherebene (1002) konsistent sein, und der Speicher innerhalb der dauerhaften Cloud-Speicherebene (1006) kann eventuell konsistent sein.
  • Die beispielhafte nicht dauerhafte Cloud-Speicherebene (1004) oder virtuelle Instanzebene kann eine oder mehrere Cloud-Computing-Instanzen (424a-424n) umfassen, die in Kombination eine Speicherschnittstelle und Speicherebene für den Speicher-Controller (408) bereitstellen, wobei die Speicherebene z. B. als EC2 M5-Instanzen, die eine oder mehrere SSDs enthalten, als EC2 R5-Instanzen, die eine oder mehrere SSDs enthalten, als EC2 I3-Instanzen, die eine oder mehrere SSDs enthalten, usw. verkörpert sein kann. In einigen Ausführungsformen kann der lokale Speicher (414...422 und 426...430) als Solid-State-Speicher (z. B. SSDs) und nicht als Speicher mit Festplattenlaufwerken ausgeführt sein.
  • In dieser beispielhaften Cloud-Speicherarchitektur des cloudbasierten Speichersystems (1002) kann das Wiederherstellen nach einem Datenverlust auf mehrere Arten implementiert werden. Beispielsweise können innerhalb der nicht dauerhaften Cloud-Speicherebene (1004) eine oder mehrere der Cloud-Computing-Instanzen (424a-424n) ausfallen, oder Teile des Speichers (414, 426...422, 430) für eine oder mehrere der Cloud-Computing-Instanzen (424a-424n) können ausfallen. In einigen Beispielen können alle virtuellen Instanzen innerhalb der virtuellen Instanzebene (nicht dauerhafte Cloud-Speicherebene) ausfallen, und die Datenwiederherstellung erfolgt wie unten für jede einzelne ausgefallene virtuelle Instanz beschrieben - wobei derselbe Wiederherstellungsprozess für jede der ausgefallenen virtuellen Instanzen gilt.
  • Wie vorstehend erwähnt, kann das Wiederherstellen von Daten aus dem cloudbasierten Speicher (1052) mit einer Sequenznummer versehen werden, wobei die Sequenznummer für alle wiederhergestellten Daten mit einer Datenbank mit entsprechenden Sequenznummern verglichen werden kann, die erstellt wurden, als die Daten im cloudbasierten Speicher (1052) gespeichert wurden. Wenn auf diese Weise für ein gegebenes Datenobjekt die wiederhergestellten Daten aus dem cloudbasierten Speicher (1052) nicht die zuletzt geschriebenen Daten sind, was dadurch bestimmt wird, dass die Daten nicht einer Sequenznummer entsprechen, die mit einer Sequenznummer in der Datenbank übereinstimmt, die der jüngsten Sequenznummer für dieses Datenobjekt entspricht, dann werden die Daten nicht in der Cloud-Computing-Instanz oder den Instanzen auf der nicht dauerhaften Cloud-Speicherebene (1004) oder der virtuellen Instanzebene wiederhergestellt, und das Datenobjekt kann als ungültig gekennzeichnet werden, bis die jüngste Version des Datenobjekts wiederhergestellt ist.
  • In einem Beispiel für die Datenwiederherstellung kann jede jeweilige ausgefallene Cloud-Computing-Instanz unter der einen oder mehreren Cloud-Computing-Instanzen (424a-424n) vor dem Ausfall durch eine neu instanziierte jeweilige Cloud-Computing-Instanz ersetzt werden, die genau oder ähnlich wie die jeweilige ausgefallene Cloud-Computing-Instanz konfiguriert ist - wobei alle Daten, die in der jeweiligen ausgefallenen Cloud-Computing-Instanz gespeichert waren, aus der dauerhaften Cloud-Speicherebene (1006) wiederhergestellt, gelesen oder rehydriert werden.
  • Als weiteres Beispiel für die Wiederherstellung von Daten kann jede jeweilige ausgefallene Cloud-Computing-Instanz unter der einen oder den mehreren Cloud-Computing-Instanzen (424a-424n) vor dem Ausfall durch eine neu instanziierte jeweilige Cloud-Computing-Instanz ersetzt werden, die im Vergleich zur jeweiligen ausgefallenen Cloud-Computing-Instanz mit einer höheren Rechenleistung und/oder Speicherkapazität konfiguriert ist - wobei alle Daten, die in der jeweiligen ausgefallenen Cloud-Computing-Instanz gespeichert waren, aus der dauerhaften Cloud-Speicherebene (1006) wiederhergestellt, gelesen oder rehydriert werden.
  • Als weiteres Beispiel für die Datenwiederherstellung kann jede jeweilige ausgefallene Cloud-Computing-Instanz unter den vor dem Ausfall vorhandenen ein oder mehreren Cloud-Computing-Instanzen (424a-424n) durch mehrere neu instanziierte jeweilige Cloud-Computing-Instanzen ersetzt werden, die ähnlich konfiguriert sein können oder mit einer höheren Rechenleistung und/oder Speicherkapazität im Vergleich zu der jeweiligen ausgefallenen Cloud-Computing-Instanz konfiguriert sind - wobei alle Daten, die in der jeweiligen ausgefallenen Cloud-Computing-Instanz gespeichert waren, aus der dauerhaften Cloud-Speicherebene (1006) wiederhergestellt, gelesen oder rehydriert werden. Auf diese Weise können die Ersatz-Cloud-Computing-Instanzen (424a-1-424a-x) - jeweils mit entsprechendem Speicher (414-1...424-x und 426-1...426-x) - als Reaktion auf den Verlust einer oder mehrerer Cloud-Computing-Instanzen, z. B. den Verlust der Cloud-Computing-Instanz (424a), erstellt werden (siehe 10B).
  • In einer Beispielimplementierung kann es sich bei der nicht dauerhaften Cloud-Speicherebene (1004) um Amazon EBS™ und bei der dauerhaften Cloud-Speicherebene (1006) um Amazon S3™ handeln, wobei in diesem Beispiel eine unbegrenzte Bandbreite zwischen der nicht dauerhaften Cloud-Speicherebene (1004) und der dauerhaften Cloud-Speicherebene (1006) besteht. In einigen Beispielen können, nachdem alle Daten von der dauerhaften Speicherebene (1006) in die mehreren, neu instanziierten Cloud-Computing-Instanzen wiederhergestellt wurden, eine oder mehrere der mehreren, neu instanziierten Cloud-Computing-Instanzen konsolidiert oder zu weniger Cloud-Computing-Instanzen kombiniert werden, die gemeinsam alle wiederhergestellten Daten speichern.
  • Außerdem können in diesem Beispiel die konsolidierten Cloud-Computing-Instanzen so konfiguriert sein, dass sie weniger Leistungskapazität oder Speicherkapazität aufweisen als die Cloud-Computing-Instanzen, in denen die Daten wiederhergestellt wurden. Auf diese Weise können Daten schneller in Cloud-Computing-Instanzen mit höherer Leistung und höheren Kosten wiederhergestellt werden, und nachdem die Daten wiederhergestellt wurden, können die Daten weiterhin in Cloud-Computing-Instanzen mit niedrigerer Leistung und geringeren Kosten gespeichert werden.
  • In Fortsetzung dieses Beispiels und wie vorstehend erwähnt, kann die Parallelität für die Datenwiederherstellung auf der cloudbasierten Speicherebene (1006) basieren, die einen parallelen Zugriff unterstützt. Wenn der cloudbasierte Speicher (1052) beispielsweise durch Amazon S3 implementiert ist, können die Daten einer bestimmten virtuellen Recheninstanz über mehrere verschiedene Buckets (1050-1-1050-x) gespeichert werden, wobei die S3-Schlüssel für die mehreren verschiedenen Buckets (1050-1-1050-x) gehasht werden können, um ein gleichzeitiges Lesen der einzelnen Bucket-Inhalte zu ermöglichen. Der Hash kann z. B. so gestaltet werden, dass die Präfixe der Schlüssel mit hoher Wahrscheinlichkeit unterschiedlich sind, so dass auf die den gehashten Schlüsseln entsprechenden S3-Buckets gleichzeitig zugegriffen werden kann.
  • Außerdem kann in einigen Fällen ein einzelner S3-Bucket einer einzelnen SSD für eine einzelne Cloud-Computing-Instanz entsprechen. In anderen Fällen kann eine einzelne SSD oder ein Speicher für eine einzelne Cloud-Computing-Instanz jedoch mehreren unterschiedlichen S3-Buckets, auf die gleichzeitig zugegriffen werden kann, entsprechen. Mit anderen Worten, eine einzelne Cloud-Computing-Instanz kann verschiedene Teile einer einzelnen SSD angeben, die mehreren entsprechenden SSDs entsprechen, und jeder der mehreren entsprechenden SSDs eine eigene AWS-ID zuweisen, auf die gleichzeitig zugegriffen werden kann.
  • Wenn eine einzelne SSD in beispielweise 100-GB-Abschnitte unterteilt ist, können auf diese Weise während der Datenwiederherstellung mehrere virtuelle Recheninstanzen erstellt werden, die jeweils mindestens 100 GB enthalten, und wobei jede der erstellten virtuellen Recheninstanzen auf der virtuellen Instanzebene (1004) parallel mit Wiederherstellungsdaten aus der cloudbasierten Speicherebene (1052) gefüllt werden kann. In anderen Beispielen können verschiedene Teilmengen des Speichers für eine einzelne gegebene Cloud-Computing-Instanz angegeben werden.
  • Da die nicht dauerhafte Cloud-Speicherebene unzuverlässig sein kann, besteht in einigen Implementierungen ein technischer Nutzen, die dauerhafte Cloud-Speicherebene (1006) nicht einfach ohne die nicht dauerhafte Cloud-Speicherebene (1004) zu verwenden, darin, dass die nicht dauerhafte Cloud-Speicherebene (1004) schneller sein kann, und folglich kann die nicht dauerhafte Speicherebene (1004) Bedingungen der Dienstqualität erfüllen, die die dauerhafte Cloud-Speicherebene (1006) nicht erfüllt. Da jedoch die nicht dauerhafte Cloud-Speicherebene (1004) die meisten oder alle Leseanforderungen erfüllen kann und die dauerhafte Cloud-Speicherebene (1006) alle Daten dauerhaft und zuverlässig speichert, kann die hier offengelegte Cloud-Speicherarchitektur die Zuverlässigkeit der dauerhaften Cloud-Speicherebene (1006) und gleichzeitig die Leistung der nicht dauerhaften Cloud-Speicherebene (1004) bereitstellen.
  • In einigen Implementierungen kann die Schicht des nicht dauerhaften Cloud-Speichers (1004) mit der Bearbeitung von E/A-Operationen beginnen, sobald die Daten aus der Schicht des dauerhaften Cloud-Speichers (1006) wiederhergestellt sind, bevor alle Daten wiederhergestellt sind. Außerdem kann die Datenwiederherstellung in einigen Beispielen die wiederherzustellenden Daten auf der Grundlage mehrerer Faktoren priorisieren, einschließlich, aber nicht darauf beschränkt, auf die Häufigkeit des Zugriffs, die Anzahl der Zugriffe, die Anzahl der Verweise und andere Faktoren.
  • Zur weiteren Erläuterung zeigt 11 ein beispielhaftes Flussdiagramm der Datenwiederherstellung innerhalb eines cloudbasierten Speichersystems (1002) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenlegung. In dem in den 10A und 10B dargestellten Beispiel wird das cloudbasierte Speichersystem (1002) vollständig innerhalb einer Cloud-Computing-Umgebung (402) erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere.
  • Wie vorstehend mit Bezug auf die 10A und 10B beschrieben, ist das cloudbasierte Speichersystem (1002) so ausgelegt, dass es die Datenwiederherstellung von einer cloudbasierten Speicherebene (1006) in eine virtuelle Instanzebene als Reaktion auf einen Datenverlust in der virtuellen Instanzebene (1004) massiv parallelisiert.
  • Das in 10A dargestellte Beispielverfahren umfasst: Bestimmen (1102) eines Datenverlustes innerhalb einer oder mehrerer virtueller Instanzen einer virtuellen Instanzebene (1004), die Daten in einer cloudbasierten Speicherebene (1006) speichert; als Reaktion auf das Bestimmen des Datenverlustes in der virtuellen Instanzebene, Erzeugen (1104) einer Menge von virtuellen Instanzen in der virtuellen Instanzebene, um Daten zu empfangen, die von der cloudbasierten Speicherebene (1006) wiederhergestellt wurden; und Wiederherstellen (1106) von Daten aus der cloudbasierten Speicherebene (1006) in der Menge der virtuellen Instanzen, die in der virtuellen Instanzebene (1004) erzeugt wurden.
  • Das Ermitteln (1102) eines Datenverlusts innerhalb einer oder mehrerer virtueller Instanzen einer virtuellen Instanzebene (1004), die Daten in einer cloudbasierten Speicherebene (1006) speichert, kann wie vorstehend mit Bezug auf die 10A und 10B beschrieben durchgeführt werden. Beispielsweise kann die Speicher-Controller-Anwendung (408) bei einem Ausfall einer bestimmten virtuellen Instanz ein Signal empfangen, das den Ausfall anzeigt, wobei die Speicher-Controller-Anwendung (408) dann das Erzeugen (1104) der ersetzenden einen oder mehreren virtuellen Recheninstanzen einleiten kann.
  • Das Erzeugen (1104) einer Menge von virtuellen Instanzen in der virtuellen Instanzebene (1004), die die von der cloudbasierten Speicherebene (1006) wiederhergestellten Daten empfangen sollen - wobei das Erzeugen als Reaktion auf die Feststellung des Datenverlusts in der virtuellen Instanzebene (1004) erfolgt - kann wie vorstehend unter Bezugnahme auf die 10A und 10B beschrieben durchgeführt werden. Wie in den obigen Beispielen beschrieben, kann die Menge der virtuellen Instanzen eine ähnlich konfigurierte virtuelle Instanz, eine virtuelle Instanz mit höherer Leistung oder mehrere virtuelle Instanzen sein, wobei die Menge durch eine Anzahl von parallelen Zugriffen begrenzt ist, die von der cloudbasierten Speicherebene (1006) unterstützt werden.
  • In einigen Beispielen wird die Menge der parallelen Zugriffe basierend auf einer angegebenen Prioritätsstufe bestimmt, wobei eine dringende Priorität eine größere Anzahl von Instanzen erzeugt als eine niedrige Priorität. In einigen Beispielen wird die Menge der parallelen Zugriffe auf der Grundlage einer Kostenbegrenzung bestimmt, wobei nicht mehr als ein bestimmter Schwellenwert an virtuellen Instanzen gekauft wird.
  • Das Wiederherstellen (1106) von Daten aus der cloudbasierten Speicherebene (1006) in die Menge der virtuellen Instanzen, die auf der Ebene der virtuellen Instanzen (1004) erstellt wurden, kann wie vorstehend mit Bezug auf die 10A und 10B beschrieben durchgeführt werden.
  • Zur weiteren Erläuterung zeigt 12 ein Beispiel für die Speicherverwaltung eines cloudbasierten Speichersystems (1002) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenlegung. In dem in 12 dargestellten Beispiel wird das cloudbasierte Speichersystem (1002) vollständig innerhalb einer Cloud-Computing-Umgebung (402) erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere.
  • Im Gegensatz zu den vorstehend beschriebenen Beispielen in Bezug auf ein cloudbasiertes Speichersystem (1002), das auf einen Datenverlust reagiert, beschreibt dieses Beispiel, wie das cloudbasierte Speichersystem (1002) allgemeiner auf eine Situation reagieren kann, in der das cloudbasierte Speichersystem (1002) feststellt, dass Daten von einer cloudbasierten Speicherebene (1006) in eine virtuelle Instanzebene (1004) verschoben werden sollten, da die Daten nicht mehr innerhalb der virtuellen Instanzebene (1004) gespeichert sind.
  • Im Allgemeinen werden alle vom cloudbasierten Speichersystem (1002) empfangenen Daten zumindest für einen gewissen Zeitraum in einer oder mehreren Cloud-Computing-Instanzen der virtuellen Instanzebene (1004) gespeichert, und alle Daten werden dauerhaft in der cloudbasierten Speicherebene (1006) gespeichert - oder ohne jemals aus dieser gelöscht zu werden. In einigen Implementierungen können jedoch Daten aus der virtuellen Instanzebene (1004) gelöscht werden, wobei das cloudbasierte Speichersystem als Reaktion auf das Löschen der Daten die Cloud-Architektur der virtuellen Instanzebene (1004) modifizieren kann - z. B. durch Verkleinern, indem es eine oder mehrere Cloud-Architekturkomponenten, wie die vorstehend beschriebenen, entfernt. Beispielsweise kann das cloudbasierte Speichersystem (1002) eine Aufbewahrungsrichtlinie speichern, die angibt, welche Daten auf der virtuellen Instanzebene (1004) aufrechterhalten werden sollen und welche Daten von der virtuellen Instanzebene (1004) entfernt werden sollen - wobei Beispiele von Aufbewahrungsrichtlinien weiter unten mit Bezug auf 13 ausführlicher beschrieben werden.
  • In einigen Beispielen können Daten, die aus der virtuellen Instanzebene (1004) entfernt wurden, von einem Client-Computer angefordert werden, und als Reaktion darauf kann das cloudbasierte Speichersystem (1002) virtuelle Instanzen erzeugen, um Daten zu empfangen, die von der Cloud-Speicherebene (1006) wiederhergestellt wurden.
  • In anderen Beispielen zum Skalieren des cloudbasierten Speichersystems (1002) können Daten, die nicht angefordert wurden, bei denen aber festgestellt wurde, dass zu erwarten ist, dass sie angefordert werden, als Reaktion auf eine solche Feststellung in generierte virtuelle Instanzen zum Empfangen von Daten, die von der Cloud-Speicherebene (1006) wiederhergestellt wurden, wiederhergestellt werden. Beispielsweise kann das cloudbasierte Speichersystem (1002) auf der Grundlage früherer Zugriffsmuster, auf der Grundlage einer Anforderung von Daten, die Teil eines gleichen oder ähnlichen Datensatzes sind, oder auf der Grundlage anderer Bedingungen oder Analysen feststellen, dass Daten zu erwarten sind.
  • Wie in 12 dargestellt, umfasst das Beispielverfahren: Ermitteln (1202), in einem cloudbasierten Speichersystem (1002) und in Reaktion auf eine Datenanforderung, dass Daten, die zuvor in einer oder mehreren virtuellen Instanzen einer virtuellen Instanzenschicht (1004) gespeichert waren, nicht mehr in der einen oder den mehreren virtuellen Instanzen gespeichert sind; Erzeugen (1204) einer Menge von virtuellen Instanzen innerhalb der virtuellen Instanzebene (1004), um Daten zu empfangen, die von einer cloudbasierten Speicherebene (1006) wiederhergestellt wurden; und Wiederherstellen (1206) von Daten von der cloudbasierten Speicherebene (1006) des cloudbasierten Speichersystems (1002) in die Menge von virtuellen Instanzen, die in der virtuellen Instanzebene (1004) erzeugt wurden.
  • Das Bestimmen (1202) im cloudbasierten Speichersystem (1002) und als Reaktion auf die Datenanforderung, dass Daten, die zuvor in einer oder mehreren virtuellen Instanzen einer virtuellen Instanzebene (1004) gespeichert waren, nicht mehr in der einen oder den mehreren virtuellen Instanzen gespeichert sind, kann von einem Speicher-Controller des cloudbasierten Speichersystems (1002) durchgeführt werden, der versucht, die angeforderten Daten zu lokalisieren, und bestimmt, dass die Daten oder zumindest ein Teil der angeforderten Daten in keiner der virtuellen Instanzen der virtuellen Instanzebene (1004) gespeichert sind. Beispielsweise kann die Speichersteuerung eines von mehreren Indizierungsverfahren zum Verfolgen gültiger und ungültiger Daten verwenden, die innerhalb der virtuellen Instanzebene gespeichert sind, und feststellen, ob die angeforderten Daten gültig sind und sich innerhalb einer oder mehrerer der virtuellen Instanzen der virtuellen Instanzebene (1004) befinden.
  • Das Erzeugen (1204) einer Menge von virtuellen Instanzen in der virtuellen Instanzebene (1004), um Daten zu empfangen, die von der cloudbasierten Speicherebene (1006) wiederhergestellt wurden, kann in ähnlicher Weise durchgeführt werden, wie vorstehend unter Bezugnahme auf 11 beschrieben, die das Erzeugen (1104) einer Menge von virtuellen Instanzen in der virtuellen Instanzebene (1004) beschreibt, um Daten zu empfangen, die von der cloudbasierten Speicherebene (1006) wiederhergestellt wurden.
  • Das Wiederherstellen (1206) von Daten aus der cloudbasierten Speicherebene (1006) des cloudbasierten Speichersystems (1002) in die Menge der auf der virtuellen Instanzebene (1004) erzeugten (1204) virtuellen Instanzen kann in ähnlicher Weise durchgeführt werden, wie vorstehend mit Bezug auf 11 beschrieben, die das Wiederherstellen (1106) von Daten aus der cloudbasierten Speicherebene (1006) in eine Menge von auf der virtuellen Instanzebene (1004) erzeugten virtuellen Instanzen beschreibt.
  • Zur weiteren Erläuterung zeigt 13 ein Beispiel für die Speicherverwaltung eines cloudbasierten Speichersystems (1002) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenlegung. In dem in 13 dargestellten Beispiel wird das cloudbasierte Speichersystem (1002) vollständig innerhalb einer Cloud-Computing-Umgebung (402) erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere.
  • Wie vorstehend unter Bezugnahme auf 12 beschrieben, wird in diesem Beispiel festgestellt, dass einige Daten aus einer virtuellen Instanzebene (1004) des cloudbasierten Speichersystems (1002) entfernt oder für ungültig erklärt werden müssen, und es werden Beispiele dafür gegeben, wann und wie das cloudbasierte Speichersystem (1002) Daten identifizieren kann, die entfernt oder für ungültig erklärt werden müssen, wobei in einigen Beispielen Daten, die für ungültig erklärt werden, als gelöscht oder entfernt angesehen werden können.
  • Wie vorstehend unter Bezugnahme auf 12 beschrieben, kann das cloudbasierte Speichersystem (1002) eine Aufbewahrungsrichtlinie (1352) implementieren, wobei die Aufbewahrungsrichtlinie Parameter, Regeln oder Ereignisse festlegt, die Bedingungen entsprechen, unter denen das cloudbasierte Speichersystem (1002) Speicherressourcen, die für die Speicherung auf der virtuellen Instanzebene (1004) verwendet werden, löscht oder anderweitig ungültig macht oder freigibt. In Abhängigkeit von einer solchen Aufbewahrungsrichtlinie werden in diesem Beispiel alle Datenobjekte schließlich auf der cloudbasierten Speicherebene (1006) gespeichert, und nur eine Teilmenge aller gespeicherten Datenobjekte bleibt auf der virtuellen Instanzebene (1004) gespeichert.
  • Beispielsweise kann die Aufbewahrungsrichtlinie festlegen, dass alle Datenobjekte, die in die cloudbasierte Speicherebene (1006) repliziert wurden und die auf der virtuellen Instanzebene (1004) über einen bestimmten Schwellenwert hinaus gespeichert wurden, gelöscht werden sollen. In anderen Beispielen kann die Aufbewahrungsrichtlinie Regeln festlegen, die für bestimmte Arten von Datenobjekten gelten, wie z. B. Datenobjekte, die mit bestimmten Anwendungen (408) oder Diensten verknüpft sind, wie z. B. Datenobjekte, die eine Referenzanzahl über einem bestimmten Schwellenwert aufweisen, wie z. B. Datenobjekte, die mit bestimmten Anwendungen oder Diensten referenziert werden, die eine bestimmte Priorität aufweisen, wie z. B. Datenobjekte, die mit einem bestimmten Benutzer oder Client-Computer verknüpft sind, wie z. B. Datenobjekte, die von Datenobjekten wie den zuvor angegebenen Datenobjekten referenziert werden. In einigen Beispielen kann die Aufbewahrungsrichtlinie so spezifiziert sein, dass nach einer bestimmten Anzahl von Datenspeicheroperationen seit dem Empfangen eines bestimmten Datenobjekts festgelegt wird, dass das Datenobjekt gelöscht werden kann. In anderen Beispielen kann die Aufbewahrungsrichtlinie so spezifiziert werden, dass das Datenobjekt gelöscht werden kann, nachdem eine bestimmte Menge an Daten seit dem Empfangen eines bestimmten Datenobjekts empfangen wurde.
  • In einigen Implementierungen kann die Aufbewahrungsrichtlinie dynamisch sein und von einem Modul für maschinelles Lernen aktualisiert oder definiert werden, das angesichts einer Historie von Datenspeicheranforderungen und/oder einer Historie der Nutzung von Datenspeicherressourcen durch eine oder mehrere Anwendungen oder einen oder mehrere Dienste eine oder mehrere Eigenschaften eines Datenobjekts oder eine oder mehrere Bedingungen bestimmt, die, wenn sie von einer oder mehreren Eigenschaften eines Datenobjekts erfüllt werden, dem hybriden Daten-Tiering-Manager anzeigen, dass Speicherressourcen für das Datenobjekt gelöscht oder freigegeben werden sollen.
  • Wie in 13 dargestellt, umfasst das Beispielverfahren: Replizieren (1302) von Daten aus dem Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen einer virtuellen Instanzebene (1004) in den Speicher innerhalb einer cloudbasierten Speicherebene (1006); Identifizieren, in Übereinstimmung mit einer Aufbewahrungsrichtlinie (1352), eines oder mehrerer Teile der Daten, die weiterhin in der virtuellen Instanzebene (1004) gespeichert werden sollen, wobei alle Daten in der cloudbasierten Speicherebene (1006) gespeichert bleiben; und in Reaktion auf eine Änderung der gespeicherten Daten in der virtuellen Instanzebene (1004), Modifizieren einer oder mehrerer Komponenten der Cloud-Speicherarchitektur der virtuellen Instanzebene (1004) des cloudbasierten Speichersystems (1002).
  • Das Replizieren (1302) von Daten aus dem Speicher innerhalb einer oder mehrerer Cloud-Computing-Instanzen einer virtuellen Instanzebene (1004) in den Speicher innerhalb einer cloudbasierten Speicherebene (1006) kann von einem Speicher-Controller durchgeführt werden, wie vorstehend mit Bezug auf die 4 bis 9 beschrieben, wobei die Daten sowohl auf der virtuellen Instanzebene (1004) als auch auf der cloudbasierten Speicherebene (1006) kopiert werden.
  • Das Identifizieren (1304), in Übereinstimmung mit einer Aufbewahrungsrichtlinie (1352), eines oder mehrerer Teile der Daten, die weiterhin auf der virtuellen Instanzebene (1004) gespeichert werden sollen, wobei alle Daten auf der cloudbasierten Speicherebene (1006) gespeichert bleiben, kann wie vorstehend unter Bezugnahme auf den Speicher-Controller unter Verwendung und Implementierung verschiedener Merkmale und Aspekte einer gegebenen Aufbewahrungsrichtlinie durchgeführt werden.
  • Das Modifizieren (1306) einer oder mehrerer Komponenten der Cloud-Speicherarchitektur der virtuellen Instanzebene (1004) des cloudbasierten Speichersystems (1002) als Reaktion auf eine Änderung der gespeicherten Daten in der virtuellen Instanzebene (1004) kann ähnlich wie das Erzeugen (1104) einer Menge von virtuellen Instanzen in der virtuellen Instanzebene (1004) ausgeführt werden, um die von der cloudbasierten Speicherebene (1006) wiederhergestellten Daten zu empfangen.
  • 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.

Claims (20)

  1. Verfahren für eine Speicherverwaltung eines cloudbasierten Speichersystems, wobei das Verfahren Folgendes umfasst: Bestimmen, am cloudbasierten Speichersystem und als Reaktion auf eine Datenanforderung, dass die Daten, die zuvor in einer oder mehreren virtuellen Instanzen einer virtuellen Instanzebene gespeichert waren, nicht mehr in der einen oder den mehreren virtuellen Instanzen gespeichert sind; Erzeugen einer Menge von virtuellen Instanzen innerhalb der virtuellen Instanzebene, um Daten zu empfangen, die von einer cloudbasierten Speicherebene des cloudbasierten Speichersystems wiederhergestellt wurden; und Wiederherstellen von Daten aus der cloudbasierten Speicherebene des cloudbasierten Speichersystems in die Menge der virtuellen Instanzen auf der Ebene der virtuellen Instanzen.
  2. Verfahren nach Anspruch 1, wobei die Menge der erzeugten virtuellen Instanzen größer ist als die Menge der einen oder mehreren virtuellen Instanzen, bei denen ein Datenverlust festgestellt wurde.
  3. Verfahren nach Anspruch 2, wobei die Menge der erzeugten virtuellen Instanzen als Reaktion auf den Abschluss der Wiederherstellung der Daten aus der cloudbasierten Speicherebene reduziert wird.
  4. Verfahren nach Anspruch 1, wobei die Menge der virtuellen Instanzen auf einer Menge an verfügbarer Bandbreite von der cloudbasierten Speicherebene in die virtuelle Instanzebene basiert, und wobei eine größere verfügbare Bandbreite einer größeren Menge an erzeugten virtuellen Instanzen entspricht.
  5. Verfahren nach Anspruch 1, wobei die Gesamtmenge der Rechenressourcen der Menge der erzeugten virtuellen Instanzen größer ist als die Gesamtmenge der Rechenressourcen der einen oder mehreren virtuellen Instanzen, bei denen ein Datenverlust festgestellt wurde.
  6. Verfahren nach Anspruch 1, wobei die virtuelle Instanzebene eine Menge von virtuellen Instanzen enthält, die einer Anzahl verschiedener Speicherrepositorien innerhalb der cloudbasierten Speicherebene entspricht, und wobei je größer die Anzahl der unterschiedlichen Speicherrepositorien innerhalb der cloudbasierten Speicherebene ist, desto größer ist die Menge der virtuellen Instanzen, die in der virtuellen Instanzebene gebildet sind.
  7. Verfahren nach Anspruch 1, wobei die virtuelle Instanzebene virtuelle Instanzen einschließt, die nicht dauerhaft genug sind, um ein Service Level Agreement für gespeicherte Daten zu erfüllen.
  8. Verfahren nach Anspruch 7, wobei die virtuellen Instanzen der virtuellen Instanzenschicht die Leistungsanforderungen für das Service Level Agreement erfüllen.
  9. Verfahren nach Anspruch 8, wobei die cloudbasierte Speicherebene in einem Ausmaß dauerhaft ist, das das Service Level Agreement erfüllt.
  10. Verfahren nach Anspruch 9, wobei die cloudbasierte Speicherebene die Leistungsanforderungen für das Service Level Agreement nicht erfüllt.
  11. Verfahren nach Anspruch 1, wobei alle Daten, die zum Speichern in der virtuellen Instanzebene empfangen werden, in der cloudbasierten Speicherebene gespeichert werden, und wobei ein oder mehrere Teile von Daten, die in der virtuellen Instanzebene gespeichert sind, zum Entfernen in Übereinstimmung mit einer Aufbewahrungsrichtlinie ausgewählt werden, die eine oder mehrere Richtlinien oder Bedingungen spezifiziert, unter denen Daten in der virtuellen Instanzebene gespeichert oder gelöscht werden sollen.
  12. Cloudbasiertes Speichersystem, das in einer Cloud-Computing-Umgebung enthalten ist, wobei das cloudbasierte Speichersystem einschließt: eine virtuelle Instanzebene mit einer oder mehreren Cloud-Computing-Instanzen mit lokalem Speicher; eine cloudbasierte Speicherebene mit cloudbasiertem Objektspeicher; und eine oder mehrere Speicher-Controller-Anwendungen, wobei jede Speicher-Controller-Anwendung in einer Cloud-Computing-Instanz ausgeführt wird, wobei die eine oder mehreren Speicher-Controller-Anwendungen konfiguriert sind zum: Feststellen eines Datenverlustes innerhalb der einen oder mehreren Cloud-Computing-Instanzen der virtuellen Instanzebene; Erzeugen, als Reaktion auf das Bestimmen des Verlustes der Daten in der virtuellen Instanzebene, einer Menge von Cloud-Computing-Instanzen in der virtuellen Instanzebene, um Daten zu empfangen, die von der cloudbasierten Speicherebene wiederhergestellt wurden; und Wiederherstellen von Daten aus der cloudbasierten Speicherebene in die Menge von Cloud-Computing-Instanzen auf der virtuellen Instanzebene.
  13. Cloudbasiertes Speichersystem nach Anspruch 11, wobei die Menge der erzeugten Cloud-Computing-Instanzen größer ist als eine Menge der einen oder mehreren Cloud-Computing-Instanzen, auf denen ein Datenverlust erkannt wurde.
  14. Cloudbasiertes Speichersystem nach Anspruch 12, wobei die Menge der erzeugten Cloud-Computing-Instanzen, als Reaktion auf den Abschluss der Wiederherstellung der Daten aus der cloudbasierten Speicherebene, reduziert wird.
  15. Cloudbasiertes Speichersystem nach Anspruch 11, wobei die Menge der Cloud-Computing-Instanzen auf einer Menge an verfügbarer Bandbreite von der cloudbasierten Speicherebene in die virtuelle Instanzebene basiert, und wobei eine größere verfügbare Bandbreite einer größeren Menge an erzeugten Cloud-Computing-Instanzen entspricht.
  16. Cloudbasiertes Speichersystem nach Anspruch 11, wobei eine Gesamtmenge an Rechenressourcen der Menge der erzeugten Cloud-Computing-Instanzen größer ist als eine Gesamtmenge an Rechenressourcen der einen oder mehreren Cloud-Computing-Instanzen, auf denen ein Datenverlust festgestellt wurde.
  17. Cloudbasiertes Speichersystem nach Anspruch 11, wobei die virtuelle Instanzebene eine Menge von Cloud-Computing-Instanzen einschließt, die einer Anzahl von unterschiedlichen Speicherrepositorien innerhalb der cloudbasierten Speicherebene entspricht, und wobei je größer die Anzahl der unterschiedlichen Speicherrepositorien innerhalb der cloudbasierten Speicherebene ist, desto größer ist die Menge der Cloud-Computing-Instanzen, die in der virtuellen Instanzebene gebildet sind.
  18. Cloudbasiertes Speichersystem nach Anspruch 11, wobei die virtuelle Instanzebene Cloud-Computing-Instanzen enthält, die nicht dauerhaft genug sind, um ein Service Level Agreement für gespeicherte Daten zu erfüllen.
  19. Cloudbasiertes Speichersystem nach Anspruch 17, wobei die Cloud-Computing-Instanzen der virtuellen Instanzebene Leistungsanforderungen für das Service Level Agreement erfüllen.
  20. Verfahren für eine Speicherverwaltung eines cloudbasierten Speichersystems, wobei das Verfahren Folgendes umfasst: Replizieren von Daten von einem Speicher innerhalb einer Cloud-Computing-Instanzebene zu einem Speicher innerhalb einer cloudbasierten Speicherebene; Identifizieren, in Übereinstimmung mit einer Aufbewahrungsrichtlinie, eines oder mehrerer Teile von Daten, die weiterhin auf der Cloud-Computing-Instanz-Ebene gespeichert werden sollen, wobei alle Daten auf der cloudbasierten Speicherebene gespeichert bleiben; und Modifizieren einer oder mehrerer Komponenten der Cloud-Speicherarchitektur der Cloud-Computing-Instanz-Ebene des cloudbasierten Speichersystems als Reaktion auf eine Änderung der gespeicherten Daten in der Cloud-Computing-Instanz-Ebene.
DE112019005770.7T 2018-11-18 2019-11-18 Speicherverwaltung für ein cloudbasiertes Speichersystem Pending DE112019005770T5 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201862768952P 2018-11-18 2018-11-18
US62/768,952 2018-11-18
US201862769277P 2018-11-19 2018-11-19
US62/769,277 2018-11-19
US16/373,733 US11023179B2 (en) 2018-11-18 2019-04-03 Cloud-based storage system storage management
US16/373,733 2019-04-03
PCT/US2019/061994 WO2020102805A1 (en) 2018-11-18 2019-11-18 Cloud-based storage system storage management

Publications (1)

Publication Number Publication Date
DE112019005770T5 true DE112019005770T5 (de) 2021-09-02

Family

ID=70727201

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019005770.7T Pending DE112019005770T5 (de) 2018-11-18 2019-11-18 Speicherverwaltung für ein cloudbasiertes Speichersystem

Country Status (4)

Country Link
US (9) US11379254B1 (de)
CN (1) CN113302584A (de)
DE (1) DE112019005770T5 (de)
WO (2) WO2020102805A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022113961A1 (de) 2022-06-02 2023-12-07 Cariad Se Verfahren zum Betreiben eines Speichersystems sowie Datenspeicher-Überwachungsmodul zum Betreiben des Speichersystems und Kraftfahrzeug

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10305979B2 (en) * 2015-06-12 2019-05-28 International Business Machines Corporation Clone efficiency in a hybrid storage cloud environment
US11050824B2 (en) * 2018-07-11 2021-06-29 T-Mobile Usa, Inc. Network controlled content recording using network and local storage
US11340837B1 (en) 2018-11-18 2022-05-24 Pure Storage, Inc. Storage system management via a remote console
US11379254B1 (en) * 2018-11-18 2022-07-05 Pure Storage, Inc. Dynamic configuration of a cloud-based storage system
US10855757B2 (en) * 2018-12-19 2020-12-01 At&T Intellectual Property I, L.P. High availability and high utilization cloud data center architecture for supporting telecommunications services
US11416285B1 (en) * 2019-04-30 2022-08-16 Splunk Inc. Efficient and secure scalable-two-stage data collection
WO2020223099A2 (en) * 2019-04-30 2020-11-05 Clumio, Inc. Cloud-based data protection service
US20200403935A1 (en) * 2019-06-18 2020-12-24 Tmrw Foundation Ip & Holding S. À R.L. Software engine virtualization and dynamic resource and task distribution across edge and cloud
US11372626B2 (en) * 2019-08-07 2022-06-28 Jpmorgan Chase Bank, N.A. Method and system for packaging infrastructure as code
US20210089403A1 (en) * 2019-09-20 2021-03-25 Samsung Electronics Co., Ltd. Metadata table management scheme for database consistency
US11418429B2 (en) 2019-11-01 2022-08-16 Microsoft Technology Licensing, Llc Route anomaly detection and remediation
US11132217B2 (en) * 2019-11-03 2021-09-28 Microsoft Technology Licensing, Llc Cloud-based managed networking service that enables users to consume managed virtualized network functions at edge locations
US11943293B1 (en) * 2019-12-06 2024-03-26 Pure Storage, Inc. Restoring a storage system from a replication target
CN111078780A (zh) * 2019-12-23 2020-04-28 北京中创信测科技股份有限公司 一种ai优化数据治理的方法
EP3855315A1 (de) * 2020-01-22 2021-07-28 Softimize Ltd. Systeme und verfahren zur verwaltung eines mehrbereichs-saas-modells
US11546991B2 (en) * 2020-03-11 2023-01-03 Peter C. Salmon Densely packed electronic systems
US11188450B2 (en) * 2020-04-02 2021-11-30 Sap Se Cloud application architecture using edge computing
US20210373951A1 (en) * 2020-05-28 2021-12-02 Samsung Electronics Co., Ltd. Systems and methods for composable coherent devices
US11443047B2 (en) * 2020-04-20 2022-09-13 Mastercard International Incorporated Systems and methods for use in validating artifacts for deployment
US11669308B2 (en) * 2020-05-19 2023-06-06 Grass Valley Canada System and method for generating a factory layout for optimizing media content production
US11516096B2 (en) * 2020-06-17 2022-11-29 Red Hat, Inc. Automatically managing performance of software in a distributed computing environment
CN113259147B (zh) * 2020-06-28 2022-07-26 中兴通讯股份有限公司 网元管理方法、装置、计算机设备、介质
US11477267B2 (en) 2020-11-09 2022-10-18 Microsoft Technology Licensing, Llc Operating cloud-managed remote edge sites at reduced disk capacity
US11500898B2 (en) * 2020-11-25 2022-11-15 Sap Se Intelligent master data replication
US20220171667A1 (en) * 2020-11-30 2022-06-02 Amazon Technologies, Inc. Application reliability service
US11503140B2 (en) * 2020-12-11 2022-11-15 Western Digital Technologies, Inc. Packet processing by programmable network interface
WO2022185145A1 (en) * 2021-03-04 2022-09-09 Profisea Labs Ltd System and method for spot life cycle mangement
DE102021202935A1 (de) * 2021-03-25 2022-09-29 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Steuern einer Fahrfunktion
US11776090B2 (en) 2021-04-12 2023-10-03 Sas Institute Inc. Dynamic per-node pre-pulling in distributed computing
US11726759B2 (en) * 2021-04-12 2023-08-15 Capital One Services, Llc Deployment of a computing environment
US20220365701A1 (en) * 2021-05-11 2022-11-17 InContact Inc. System and method for determining and utilizing an effectiveness of lifecycle management for interactions storage, in a contact center
US11775396B1 (en) * 2021-08-24 2023-10-03 Veritas Technologies Llc Methods and systems for improved backup performance
US11733729B2 (en) * 2021-09-27 2023-08-22 International Business Machines Corporation Centralized imposing of multi-cloud clock speeds
CN113884976B (zh) * 2021-11-25 2022-10-14 安徽南瑞中天电力电子有限公司 一种基于云平台的智能电表数据保护方法、系统
US11556238B1 (en) * 2022-01-19 2023-01-17 International Business Machines Corporation Implementation of architecture document via infrastructure as code
US20230297719A1 (en) * 2022-03-21 2023-09-21 International Business Machines Corporation Filtering sensitive data in cloud native application logs
US20230388180A1 (en) * 2022-05-31 2023-11-30 Microsoft Technology Licensing, Llc Techniques for provisioning workspaces in cloud-based computing platforms
JP2024018388A (ja) * 2022-07-29 2024-02-08 ブラザー工業株式会社 通信装置と通信装置のためのコンピュータプログラムと通信装置によって実行される方法
US11789784B1 (en) 2023-02-08 2023-10-17 Bank Of America Corporation Monitoring and management of a cloud-based computing system
CN116915781B (zh) * 2023-09-14 2023-12-12 南京邮电大学 一种基于区块链的边缘协作缓存系统及方法

Family Cites Families (238)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5651133A (en) 1995-02-01 1997-07-22 Hewlett-Packard Company Methods for avoiding over-commitment of virtual capacity in a redundant hierarchic data storage system
JPH08242229A (ja) 1995-03-01 1996-09-17 Fujitsu Ltd ネットワーク監視における状態整合処理システム
US5799200A (en) 1995-09-28 1998-08-25 Emc Corporation Power failure responsive apparatus and method having a shadow dram, a flash ROM, an auxiliary battery, and a controller
US6012032A (en) 1995-11-30 2000-01-04 Electronic Data Systems Corporation System and method for accounting of computer data storage utilization
US5933598A (en) 1996-07-17 1999-08-03 Digital Equipment Corporation Method for sharing variable-grained memory of workstations by sending particular block including line and size of the block to exchange shared data structures
US6085333A (en) 1997-12-19 2000-07-04 Lsi Logic Corporation Method and apparatus for synchronization of code in redundant controllers in a swappable environment
US6647514B1 (en) 2000-03-23 2003-11-11 Hewlett-Packard Development Company, L.P. Host I/O performance and availability of a storage array during rebuild by prioritizing I/O request
US6643641B1 (en) 2000-04-27 2003-11-04 Russell Snyder Web search engine with graphic snapshots
JP2002041305A (ja) 2000-07-26 2002-02-08 Hitachi Ltd 仮想計算機システムにおける計算機資源の割当て方法および仮想計算機システム
US6789162B1 (en) 2000-10-17 2004-09-07 Sun Microsystems, Inc. Storage controller configured to select unused regions of a storage device for data storage according to head position
US6857045B2 (en) 2002-01-25 2005-02-15 International Business Machines Corporation Method and system for updating data in a compressed read cache
US6728738B2 (en) 2002-04-03 2004-04-27 Sun Microsystems, Inc. Fast lifetime analysis of objects in a garbage-collected system
US6895464B2 (en) 2002-06-03 2005-05-17 Honeywell International Inc. Flash memory management system and method utilizing multiple block list windows
US7334124B2 (en) 2002-07-22 2008-02-19 Vormetric, Inc. Logical access block processing protocol for transparent secure file storage
US7146521B1 (en) 2002-08-21 2006-12-05 3Pardata, Inc. Preventing damage of storage devices and data loss in a data storage system
EP1533702A4 (de) 2002-08-29 2007-05-23 Matsushita Electric Ind Co Ltd Halbleiterspeicherbaustein und verfahren zum schreiben von daten in flash-speicher
US6831865B2 (en) 2002-10-28 2004-12-14 Sandisk Corporation Maintaining erase counts in non-volatile storage systems
US20040153844A1 (en) 2002-10-28 2004-08-05 Gautam Ghose Failure analysis method and system for storage area networks
US7072905B2 (en) 2002-12-06 2006-07-04 Sun Microsystems, Inc. Better placement of objects reachable from outside a generation managed by the train algorithm
US7181580B2 (en) 2003-03-27 2007-02-20 International Business Machines Corporation Secure pointers
US7809252B2 (en) 2003-04-09 2010-10-05 Corel Inc. Systems and methods for caching multimedia data
US7437530B1 (en) 2003-04-24 2008-10-14 Network Appliance, Inc. System and method for mapping file block numbers to logical block addresses
US7434097B2 (en) 2003-06-05 2008-10-07 Copan System, Inc. Method and apparatus for efficient fault-tolerant disk drive replacement in raid storage systems
US7089272B1 (en) 2003-06-18 2006-08-08 Sun Microsystems, Inc. Specializing write-barriers for objects in a garbage collected heap
US7434214B2 (en) 2004-01-21 2008-10-07 International Business Machines Corporation Method for determining a close approximate benefit of reducing memory footprint of a Java application
US20050188246A1 (en) 2004-02-25 2005-08-25 Emberty Robert G. Persistent worldwide names assigned to removable media storage
US7526684B2 (en) 2004-03-24 2009-04-28 Seagate Technology Llc Deterministic preventive recovery from a predicted failure in a distributed storage system
US7493424B1 (en) 2004-04-30 2009-02-17 Netapp, Inc. Network storage system with shared software stack for LDMA and RDMA
JP4392601B2 (ja) 2004-05-07 2010-01-06 パナソニック株式会社 データアクセス装置および記録媒体
US8042163B1 (en) 2004-05-20 2011-10-18 Symatec Operating Corporation Secure storage access using third party capability tokens
US7533292B2 (en) 2004-07-15 2009-05-12 International Business Machines Corporation Management method for spare disk drives in a raid system
EP1829332A2 (de) 2004-12-15 2007-09-05 Exostar Corporation Vertrauensermöglichung bei einer föderierten kollaboration von netzwerken
US7426623B2 (en) 2005-01-14 2008-09-16 Sandisk Il Ltd System and method for configuring flash memory partitions as super-units
US20060230245A1 (en) 2005-04-08 2006-10-12 Microsoft Corporation Data storage safety indicator and expander
US8200887B2 (en) 2007-03-29 2012-06-12 Violin Memory, Inc. Memory management system and method
US7689609B2 (en) 2005-04-25 2010-03-30 Netapp, Inc. Architecture for supporting sparse volumes
US7366825B2 (en) 2005-04-26 2008-04-29 Microsoft Corporation NAND flash memory management
JP4506594B2 (ja) 2005-07-22 2010-07-21 日本電気株式会社 冗長パス制御方法
US7694082B2 (en) 2005-07-29 2010-04-06 International Business Machines Corporation Computer program and method for managing resources in a distributed storage system
US7617216B2 (en) 2005-09-07 2009-11-10 Emc Corporation Metadata offload for a file server cluster
ITVA20050061A1 (it) 2005-11-08 2007-05-09 St Microelectronics Srl Metodo di gestione di un dispositivo di memoria non volatile e relativa memoria
US7831783B2 (en) 2005-12-22 2010-11-09 Honeywell International Inc. Effective wear-leveling and concurrent reclamation method for embedded linear flash file systems
US7421552B2 (en) 2006-03-17 2008-09-02 Emc Corporation Techniques for managing data within a data storage system utilizing a flash-based memory vault
US7899780B1 (en) 2006-03-30 2011-03-01 Emc Corporation Methods and apparatus for structured partitioning of management information
US20070294564A1 (en) 2006-04-27 2007-12-20 Tim Reddin High availability storage system
US8266472B2 (en) 2006-05-03 2012-09-11 Cisco Technology, Inc. Method and system to provide high availability of shared data
US9455955B2 (en) 2006-05-17 2016-09-27 Richard Fetik Customizable storage controller with integrated F+ storage firewall protection
US7743239B2 (en) 2006-06-30 2010-06-22 Intel Corporation Accelerating integrity checks of code and data stored in non-volatile memory
US7627786B2 (en) 2006-09-26 2009-12-01 International Business Machines Corporation Tracking error events relating to data storage drives and/or media of automated data storage library subsystems
US8620970B2 (en) 2006-10-03 2013-12-31 Network Appliance, Inc. Methods and apparatus for changing versions of a filesystem
US7529867B2 (en) * 2006-11-01 2009-05-05 Inovawave, Inc. Adaptive, scalable I/O request handling architecture in virtualized computer systems and networks
US7669029B1 (en) 2006-11-15 2010-02-23 Network Appliance, Inc. Load balancing a data storage system
US7710777B1 (en) 2006-12-20 2010-05-04 Marvell International Ltd. Semi-volatile NAND flash memory
US7640332B2 (en) 2006-12-27 2009-12-29 Hewlett-Packard Development Company, L.P. System and method for hot deployment/redeployment in grid computing environment
KR100923990B1 (ko) 2007-02-13 2009-10-28 삼성전자주식회사 플래시 저장 장치의 특성을 기반으로 한 컴퓨팅 시스템
US9632870B2 (en) 2007-03-29 2017-04-25 Violin Memory, Inc. Memory system with multiple striping of raid groups and method for performing the same
US7996599B2 (en) 2007-04-25 2011-08-09 Apple Inc. Command resequencing in memory operations
US7991942B2 (en) 2007-05-09 2011-08-02 Stmicroelectronics S.R.L. Memory block compaction method, circuit, and system in storage devices based on flash memories
US7870360B2 (en) 2007-09-14 2011-01-11 International Business Machines Corporation Storage area network (SAN) forecasting in a heterogeneous environment
KR101433859B1 (ko) 2007-10-12 2014-08-27 삼성전자주식회사 불휘발성 메모리 시스템 및 그것의 파일 데이터 관리 방법
US8271700B1 (en) 2007-11-23 2012-09-18 Pmc-Sierra Us, Inc. Logical address direct memory access with multiple concurrent physical ports and internal switching
US7743191B1 (en) 2007-12-20 2010-06-22 Pmc-Sierra, Inc. On-chip shared memory based device architecture
JP4471007B2 (ja) 2008-02-05 2010-06-02 ソニー株式会社 記録装置、記録装置の制御方法、記録装置の制御方法のプログラム及び記録装置の制御方法のプログラムを記録した記録媒体
US8949863B1 (en) 2008-04-30 2015-02-03 Netapp, Inc. Creating environmental snapshots of storage device failure events
US8093868B2 (en) 2008-09-04 2012-01-10 International Business Machines Corporation In situ verification of capacitive power support
US8458717B1 (en) * 2008-09-23 2013-06-04 Gogrid, LLC System and method for automated criteria based deployment of virtual machines across a grid of hosting resources
US8086585B1 (en) 2008-09-30 2011-12-27 Emc Corporation Access control to block storage devices for a shared disk based file system
US8117156B2 (en) 2008-10-26 2012-02-14 Microsoft Corporation Replication for common availability substrate
US9473419B2 (en) 2008-12-22 2016-10-18 Ctera Networks, Ltd. Multi-tenant cloud storage system
US8762642B2 (en) 2009-01-30 2014-06-24 Twinstrata Inc System and method for secure and reliable multi-cloud data replication
JP4844639B2 (ja) 2009-02-19 2011-12-28 Ｔｄｋ株式会社 メモリコントローラ及びメモリコントローラを備えるフラッシュメモリシステム、並びにフラッシュメモリの制御方法
US9134922B2 (en) 2009-03-12 2015-09-15 Vmware, Inc. System and method for allocating datastores for virtual machines
KR101586047B1 (ko) 2009-03-25 2016-01-18 삼성전자주식회사 불휘발성 메모리 장치 및 그것의 프로그램 방법
US8296419B1 (en) * 2009-03-31 2012-10-23 Amazon Technologies, Inc. Dynamically modifying a cluster of computing nodes used for distributed execution of a program
US8805953B2 (en) 2009-04-03 2014-08-12 Microsoft Corporation Differential file and system restores from peers and the cloud
TWI408689B (zh) 2009-04-14 2013-09-11 Jmicron Technology Corp 存取儲存裝置的方法及相關控制電路
JP4874368B2 (ja) 2009-06-22 2012-02-15 株式会社日立製作所 フラッシュメモリを用いたストレージシステムの管理方法及び計算機
US8332688B1 (en) * 2009-07-21 2012-12-11 Adobe Systems Incorporated Failover and recovery of a computing application hosted by a virtual instance of a machine
US7948798B1 (en) 2009-07-22 2011-05-24 Marvell International Ltd. Mixed multi-level cell and single level cell storage device
US8402242B2 (en) 2009-07-29 2013-03-19 International Business Machines Corporation Write-erase endurance lifetime of memory storage devices
US8868957B2 (en) 2009-09-24 2014-10-21 Xyratex Technology Limited Auxiliary power supply, a method of providing power to a data storage system and a back-up power supply charging circuit
US8762337B2 (en) 2009-10-30 2014-06-24 Symantec Corporation Storage replication systems and methods
TWI428917B (zh) 2009-11-25 2014-03-01 Silicon Motion Inc 快閃記憶裝置、資料儲存系統、以及資料儲存系統之運作方法
US8250324B2 (en) 2009-11-30 2012-08-21 International Business Machines Corporation Method to efficiently locate meta-data structures on a flash-based storage device
US9489266B2 (en) 2009-12-11 2016-11-08 Google Inc. System and method of storing backup image catalog
US8387136B2 (en) 2010-01-05 2013-02-26 Red Hat, Inc. Role-based access control utilizing token profiles
US8452932B2 (en) 2010-01-06 2013-05-28 Storsimple, Inc. System and method for efficiently creating off-site data volume back-ups
US8260840B1 (en) * 2010-06-28 2012-09-04 Amazon Technologies, Inc. Dynamic scaling of a cluster of computing nodes used for distributed execution of a program
US20120023144A1 (en) 2010-07-21 2012-01-26 Seagate Technology Llc Managing Wear in Flash Memory
US20120054264A1 (en) 2010-08-31 2012-03-01 International Business Machines Corporation Techniques for Migrating Active I/O Connections with Migrating Servers and Clients
US8762980B1 (en) * 2010-09-09 2014-06-24 Symantec Corporation Rolling incremental updates
US8589625B2 (en) * 2010-09-15 2013-11-19 Pure Storage, Inc. Scheduling of reconstructive I/O read operations in a storage environment
US8566546B1 (en) 2010-09-27 2013-10-22 Emc Corporation Techniques for enforcing capacity restrictions of an allocation policy
US8775868B2 (en) 2010-09-28 2014-07-08 Pure Storage, Inc. Adaptive RAID for an SSD environment
US8949502B2 (en) 2010-11-18 2015-02-03 Nimble Storage, Inc. PCIe NVRAM card based on NVDIMM
US8812860B1 (en) 2010-12-03 2014-08-19 Symantec Corporation Systems and methods for protecting data stored on removable storage devices by requiring external user authentication
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
US8589723B2 (en) 2010-12-22 2013-11-19 Intel Corporation Method and apparatus to provide a high availability solid state drive
US8465332B2 (en) 2011-01-13 2013-06-18 Tyco Electronics Corporation Contact assembly for an electrical connector
US8578442B1 (en) 2011-03-11 2013-11-05 Symantec Corporation Enforcing consistent enterprise and cloud security profiles
KR101483127B1 (ko) * 2011-03-31 2015-01-22 주식회사 케이티 클라우드 스토리지 시스템에서 리소스를 고려한 자료분배방법 및 장치
US20120297059A1 (en) * 2011-05-20 2012-11-22 Silverspore Llc Automated creation of monitoring configuration templates for cloud server images
US8738882B2 (en) 2011-06-03 2014-05-27 Apple Inc. Pre-organization of data
US8769622B2 (en) 2011-06-30 2014-07-01 International Business Machines Corporation Authentication and authorization methods for cloud computing security
US8751463B1 (en) 2011-06-30 2014-06-10 Emc Corporation Capacity forecasting for a deduplicating storage system
US9852017B2 (en) 2011-07-27 2017-12-26 International Business Machines Corporation Generating dispersed storage network event records
US8931041B1 (en) 2011-07-29 2015-01-06 Symantec Corporation Method and system for visibility and control over access transactions between clouds using resource authorization messages
US20130036272A1 (en) 2011-08-02 2013-02-07 Microsoft Corporation Storage engine node for cloud-based storage
US8863124B1 (en) * 2011-08-10 2014-10-14 Nutanix, Inc. Architecture for managing I/O and storage for a virtualization environment
US8930307B2 (en) * 2011-09-30 2015-01-06 Pure Storage, Inc. Method for removing duplicate data from a storage array
US8527544B1 (en) 2011-08-11 2013-09-03 Pure Storage Inc. Garbage collection in a storage system
US9525900B2 (en) 2011-09-15 2016-12-20 Google Inc. Video management system
JP2013077278A (ja) 2011-09-16 2013-04-25 Toshiba Corp メモリ・デバイス
US9374356B2 (en) 2011-09-29 2016-06-21 Oracle International Corporation Mobile oauth service
CN103034453B (zh) * 2011-09-30 2015-11-25 国际商业机器公司 管理虚拟机实例中预安装应用的持久数据的方法和装置
EP2771802A4 (de) 2011-10-24 2016-05-25 Schneider Electric Ind Sas System und verfahren zur verwaltung industrieller prozesse
WO2013071087A1 (en) 2011-11-09 2013-05-16 Unisys Corporation Single sign on for cloud
TWI533146B (zh) * 2011-11-10 2016-05-11 財團法人資訊工業策進會 虛擬資源調整裝置、方法及儲存其之電腦可讀取紀錄媒體
US20130311434A1 (en) 2011-11-17 2013-11-21 Marc T. Jones Method, apparatus and system for data deduplication
US9330245B2 (en) 2011-12-01 2016-05-03 Dashlane SAS Cloud-based data backup and sync with secure local storage of access keys
US20130219164A1 (en) 2011-12-29 2013-08-22 Imation Corp. Cloud-based hardware security modules
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access
US8613066B1 (en) 2011-12-30 2013-12-17 Amazon Technologies, Inc. Techniques for user authentication
US8756609B2 (en) * 2011-12-30 2014-06-17 International Business Machines Corporation Dynamically scaling multi-tier applications vertically and horizontally in a cloud environment
US9423983B2 (en) 2012-01-19 2016-08-23 Syncsort Incorporated Intelligent storage controller
US9116812B2 (en) 2012-01-27 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a de-duplication cache
JP2013161235A (ja) 2012-02-03 2013-08-19 Fujitsu Ltd ストレージ装置、ストレージ装置の制御方法及びストレージ装置の制御プログラム
US9104331B2 (en) * 2012-09-28 2015-08-11 Emc Corporation System and method for incremental virtual machine backup using storage system functionality
US10474584B2 (en) 2012-04-30 2019-11-12 Hewlett Packard Enterprise Development Lp Storing cache metadata separately from integrated circuit containing cache controller
US8832372B2 (en) 2012-05-24 2014-09-09 Netapp, Inc. Network storage systems having clustered raids for improved redundancy and load balancing
WO2013188382A2 (en) 2012-06-12 2013-12-19 Centurylink Intellectual Property Llc High performance cloud storage
US8856077B1 (en) 2012-06-15 2014-10-07 Amazon Technologies, Inc. Account cloning service for cloud computing environments
WO2014007516A1 (ko) 2012-07-02 2014-01-09 에스케이플래닛 주식회사 단일 인증 서비스 시스템 및 이의 운용 방법
US10148530B2 (en) 2012-09-07 2018-12-04 Oracle International Corporation Rule based subscription cloning
US9047181B2 (en) 2012-09-07 2015-06-02 Splunk Inc. Visualization of data from clusters
US9858095B2 (en) * 2012-09-17 2018-01-02 International Business Machines Corporation Dynamic virtual machine resizing in a cloud computing infrastructure
US8769651B2 (en) 2012-09-19 2014-07-01 Secureauth Corporation Mobile multifactor single-sign-on authentication
WO2014051552A1 (en) 2012-09-25 2014-04-03 Empire Technology Development Llc Limiting data usage of a device connected to the internet via tethering
US9245144B2 (en) 2012-09-27 2016-01-26 Intel Corporation Secure data container for web applications
US8990905B1 (en) 2012-09-28 2015-03-24 Emc Corporation Protected resource access control utilizing intermediate values of a hash chain
US8990914B2 (en) 2012-09-28 2015-03-24 Intel Corporation Device, method, and system for augmented reality security
US8850546B1 (en) 2012-09-30 2014-09-30 Emc Corporation Privacy-preserving user attribute release and session management
US20140101434A1 (en) 2012-10-04 2014-04-10 Msi Security, Ltd. Cloud-based file distribution and management using real identity authentication
US9209973B2 (en) 2012-11-20 2015-12-08 Google Inc. Delegate authorization in cloud-based storage system
US8997197B2 (en) 2012-12-12 2015-03-31 Citrix Systems, Inc. Encryption-based data access management
US9317223B2 (en) 2012-12-17 2016-04-19 International Business Machines Corporation Method and apparatus for automated migration of data among storage centers
US9256622B2 (en) * 2012-12-21 2016-02-09 Commvault Systems, Inc. Systems and methods to confirm replication data accuracy for data backup in data storage systems
US9075529B2 (en) 2013-01-04 2015-07-07 International Business Machines Corporation Cloud based data migration and replication
US9646039B2 (en) 2013-01-10 2017-05-09 Pure Storage, Inc. Snapshots in a storage system
US9052917B2 (en) 2013-01-14 2015-06-09 Lenovo (Singapore) Pte. Ltd. Data storage for remote environment
US9483657B2 (en) 2013-01-14 2016-11-01 Accenture Global Services Limited Secure online distributed data storage services
US9009526B2 (en) 2013-01-24 2015-04-14 Hewlett-Packard Development Company, L.P. Rebuilding drive data
US20140229654A1 (en) 2013-02-08 2014-08-14 Seagate Technology Llc Garbage Collection with Demotion of Valid Data to a Lower Memory Tier
US20140230017A1 (en) 2013-02-12 2014-08-14 Appsense Limited Programmable security token
US9571567B2 (en) * 2013-03-14 2017-02-14 Vmware, Inc. Methods and systems to manage computer resources in elastic multi-tenant cloud computing systems
US8902532B2 (en) 2013-03-20 2014-12-02 International Business Machines Corporation Write avoidance areas around bad blocks on a hard disk drive platter
GB2513377A (en) 2013-04-25 2014-10-29 Ibm Controlling data storage in an array of storage devices
US9317382B2 (en) 2013-05-21 2016-04-19 International Business Machines Corporation Storage device with error recovery indication
US10038726B2 (en) 2013-06-12 2018-07-31 Visa International Service Association Data sensitivity based authentication and authorization
US9124569B2 (en) 2013-06-14 2015-09-01 Microsoft Technology Licensing, Llc User authentication in a cloud environment
US8898346B1 (en) 2013-06-20 2014-11-25 Qlogic, Corporation Method and system for configuring network devices
US8984602B1 (en) 2013-06-28 2015-03-17 Emc Corporation Protected resource access control utilizing credentials based on message authentication codes and hash chain values
EP3028166A1 (de) 2013-07-31 2016-06-08 Hewlett Packard Enterprise Development LP Designvererbung für cloud-basierten dienst
US11422907B2 (en) 2013-08-19 2022-08-23 Microsoft Technology Licensing, Llc Disconnected operation for systems utilizing cloud storage
US9454423B2 (en) 2013-09-11 2016-09-27 Dell Products, Lp SAN performance analysis tool
US20150074222A1 (en) * 2013-09-12 2015-03-12 Guanfeng Liang Method and apparatus for load balancing and dynamic scaling for low delay two-tier distributed cache storage system
US9577953B2 (en) 2013-09-27 2017-02-21 Intel Corporation Determination of a suitable target for an initiator by a control plane processor
CN105531696B (zh) * 2013-10-09 2020-03-31 英特尔公司 用于管理云存储的技术
US9246920B2 (en) 2013-10-09 2016-01-26 Globalfoundries Inc. Cloud resource cloning based on collaborative content
US9442662B2 (en) 2013-10-18 2016-09-13 Sandisk Technologies Llc Device and method for managing die groups
US9519580B2 (en) 2013-11-11 2016-12-13 Globalfoundries Inc. Load balancing logical units in an active/passive storage system
GB201320778D0 (en) * 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
US9619311B2 (en) 2013-11-26 2017-04-11 International Business Machines Corporation Error identification and handling in storage area networks
US9798486B1 (en) * 2013-12-18 2017-10-24 EMC IP Holding Company LLC Method and system for file system based replication of a deduplicated storage system
US10977063B2 (en) * 2013-12-20 2021-04-13 Vmware, Inc. Elastic compute fabric using virtual machine templates
US9529546B2 (en) 2014-01-08 2016-12-27 Netapp, Inc. Global in-line extent-based deduplication
US20150269032A1 (en) * 2014-03-18 2015-09-24 Netapp, Inc. Backing up data to cloud data storage while maintaining storage efficiency
US9722945B2 (en) * 2014-03-31 2017-08-01 Microsoft Technology Licensing, Llc Dynamically identifying target capacity when scaling cloud resources
US9250823B1 (en) 2014-05-20 2016-02-02 Emc Corporation Online replacement of physical storage in a virtual storage system
US9639546B1 (en) * 2014-05-23 2017-05-02 Amazon Technologies, Inc. Object-backed block-based distributed storage
US10133508B1 (en) * 2014-06-13 2018-11-20 EMC IP Holding Company LLC Method and system for data protection based on storage status
CN105830166B (zh) 2014-06-27 2018-02-23 华为技术有限公司 一种控制器、闪存装置和将数据写入闪存装置的方法
US10430102B2 (en) * 2014-06-27 2019-10-01 Nec Corporation Storage device, program, and information processing method
US10108496B2 (en) * 2014-06-30 2018-10-23 International Business Machines Corporation Use of replicated copies to improve database backup performance
US10387208B2 (en) * 2014-07-15 2019-08-20 Technion Research & Development Foundation Limited Distributed cloud computing elasticity
US9516167B2 (en) 2014-07-24 2016-12-06 Genesys Telecommunications Laboratories, Inc. Media channel management apparatus for network communications sessions
US9442669B2 (en) * 2014-08-06 2016-09-13 International Business Machines Corporation Cost-effective IAAS (infrastructure-as-a-service) cloud storage based on adaptive virtual disks (AVD)
US9684567B2 (en) * 2014-09-04 2017-06-20 International Business Machines Corporation Hypervisor agnostic interchangeable backup recovery and file level recovery from virtual disks
US10204010B2 (en) 2014-10-03 2019-02-12 Commvault Systems, Inc. Intelligent protection of off-line mail data
US9886347B2 (en) 2015-01-08 2018-02-06 International Business Machines Corporation Data replication in a database management system
US9848041B2 (en) * 2015-05-01 2017-12-19 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters
US9521200B1 (en) 2015-05-26 2016-12-13 Pure Storage, Inc. Locally providing cloud storage array services
US9716755B2 (en) 2015-05-26 2017-07-25 Pure Storage, Inc. Providing cloud storage array services by a local storage array in a data center
US9300660B1 (en) 2015-05-29 2016-03-29 Pure Storage, Inc. Providing authorization and authentication in a cloud for a user of a storage array
US9444822B1 (en) 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US10021170B2 (en) 2015-05-29 2018-07-10 Pure Storage, Inc. Managing a storage array using client-side services
US20160350009A1 (en) 2015-05-29 2016-12-01 Pure Storage, Inc. Buffering data to be written to an array of non-volatile storage devices
US9645847B1 (en) * 2015-06-08 2017-05-09 Amazon Technologies, Inc. Efficient suspend and resume of instances
US9524389B1 (en) * 2015-06-08 2016-12-20 Amazon Technologies, Inc. Forensic instance snapshotting
US10305979B2 (en) 2015-06-12 2019-05-28 International Business Machines Corporation Clone efficiency in a hybrid storage cloud environment
US10108502B1 (en) * 2015-06-26 2018-10-23 EMC IP Holding Company LLC Data protection using checkpoint restart for cluster shared resources
US10244050B2 (en) * 2015-07-21 2019-03-26 Netapp, Inc. Network-based elastic storage
US20170031699A1 (en) * 2015-07-29 2017-02-02 Netapp, Inc. Multiprocessing Within a Storage Array System Executing Controller Firmware Designed for a Uniprocessor Environment
US10089097B2 (en) * 2015-09-13 2018-10-02 Extreme Networks, Inc. Dynamic templates for virtualized systems
US10942813B2 (en) * 2015-10-30 2021-03-09 Netapp, Inc. Cloud object data layout (CODL)
EP3179699B1 (de) * 2015-12-11 2020-05-27 Alcatel Lucent Steuerung für einen cloud-basierten dienst in einem telekommunikationsnetzwerk und verfahren zur bereitstellung eines cloud-basierten dienstes
US20170177443A1 (en) * 2015-12-20 2017-06-22 International Business Machines Corporation Point-in-time-copy creation for direct cloud backup
US10628192B2 (en) * 2015-12-24 2020-04-21 Intel Corporation Scalable techniques for data transfer between virtual machines
US10296594B1 (en) 2015-12-28 2019-05-21 EMC IP Holding Company LLC Cloud-aware snapshot difference determination
US9946569B1 (en) * 2016-02-08 2018-04-17 Nutanix, Inc. Virtual machine bring-up with on-demand processing of storage requests
US10540165B2 (en) * 2016-02-12 2020-01-21 Nutanix, Inc. Virtualized file server rolling upgrade
US20170322834A1 (en) * 2016-05-03 2017-11-09 International Business Machines Corporation Compute instance workload monitoring and placement
US10432722B2 (en) * 2016-05-06 2019-10-01 Microsoft Technology Licensing, Llc Cloud storage platform providing performance-based service level agreements
US9507532B1 (en) 2016-05-20 2016-11-29 Pure Storage, Inc. Migrating data in a storage array that includes a plurality of storage devices and a plurality of write buffer devices
US10785299B2 (en) * 2016-06-08 2020-09-22 Nutanix, Inc. Generating cloud-hosted storage objects from observed data access patterns
US10776216B2 (en) 2016-08-18 2020-09-15 Red Hat, Inc. Tiered cloud storage for different availability and performance requirements
US10459657B2 (en) 2016-09-16 2019-10-29 Hewlett Packard Enterprise Development Lp Storage system with read cache-on-write buffer
US10346062B2 (en) * 2016-11-16 2019-07-09 International Business Machines Corporation Point-in-time backups via a storage controller to an object storage cloud
US9906401B1 (en) * 2016-11-22 2018-02-27 Gigamon Inc. Network visibility appliances for cloud computing architectures
US10409642B1 (en) * 2016-11-22 2019-09-10 Amazon Technologies, Inc. Customer resource monitoring for versatile scaling service scaling policy recommendations
US10467032B2 (en) * 2017-03-02 2019-11-05 International Business Machines Corporation Dynamic cloud image updates based on subjective customization and user input
US10503427B2 (en) * 2017-03-10 2019-12-10 Pure Storage, Inc. Synchronously replicating datasets and other managed objects to cloud-based storage systems
US20200012510A1 (en) * 2017-03-24 2020-01-09 Nokia Technologies Oy Methods and apparatuses for multi-tiered virtualized network function scaling
US10776329B2 (en) * 2017-03-28 2020-09-15 Commvault Systems, Inc. Migration of a database management system to cloud storage
US10489073B2 (en) * 2017-04-28 2019-11-26 Netapp Inc. Multi-tier write allocation
US10521273B2 (en) * 2017-06-08 2019-12-31 Cisco Technology, Inc. Physical partitioning of computing resources for server virtualization
US10691666B1 (en) * 2017-08-23 2020-06-23 CloudBD, LLC Providing strong consistency for object storage
US10963349B2 (en) 2017-08-25 2021-03-30 Vmware, Inc. Containerized application snapshots
US10372363B2 (en) * 2017-09-14 2019-08-06 International Business Machines Corporation Thin provisioning using cloud based ranks
US10534549B2 (en) 2017-09-19 2020-01-14 Robin Systems, Inc. Maintaining consistency among copies of a logical storage volume in a distributed storage system
US20190097895A1 (en) * 2017-09-28 2019-03-28 Oracle International Corporation System and method for dynamic auto-scaling based on roles
US20190155598A1 (en) * 2017-11-17 2019-05-23 Apple Inc. Techniques for updating a file using a multi-version patch file
US10795774B2 (en) 2018-01-19 2020-10-06 Rubrik, Inc. Disaster recovery of archived data
US20200133532A1 (en) * 2018-10-31 2020-04-30 EMC IP Holding Company LLC Geological Allocation of Storage Space
US10977217B2 (en) * 2018-10-31 2021-04-13 EMC IP Holding Company LLC Method and system to efficiently recovering a consistent view of a file system image from an asynchronously remote system
US10656876B1 (en) * 2018-11-12 2020-05-19 Cohesity, Inc. Cloud edition and retrieve
US11379254B1 (en) 2018-11-18 2022-07-05 Pure Storage, Inc. Dynamic configuration of a cloud-based storage system
KR102202107B1 (ko) * 2018-12-28 2021-01-12 (주)글루시스 사용자 개별 서비스 환경을 위한 스토리지 장치 제어 방법 및 스토리지 컨트롤러

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022113961A1 (de) 2022-06-02 2023-12-07 Cariad Se Verfahren zum Betreiben eines Speichersystems sowie Datenspeicher-Überwachungsmodul zum Betreiben des Speichersystems und Kraftfahrzeug

Also Published As

Publication number Publication date
US11455126B1 (en) 2022-09-27
US11184233B1 (en) 2021-11-23
US11928366B2 (en) 2024-03-12
US11379254B1 (en) 2022-07-05
WO2020102805A1 (en) 2020-05-22
US10917470B1 (en) 2021-02-09
US20220350493A1 (en) 2022-11-03
US20230009921A1 (en) 2023-01-12
US11023179B2 (en) 2021-06-01
US20200159415A1 (en) 2020-05-21
US20220052910A1 (en) 2022-02-17
CN113302584A (zh) 2021-08-24
WO2020102807A1 (en) 2020-05-22
US20200159421A1 (en) 2020-05-21
US11907590B2 (en) 2024-02-20
US11822825B2 (en) 2023-11-21

Similar Documents

Publication Publication Date Title
DE112019005770T5 (de) Speicherverwaltung für ein cloudbasiertes Speichersystem
DE112019000841T5 (de) Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem
US11663097B2 (en) Mirroring data to survive storage device failures
US11399063B2 (en) Network authentication for a storage system
US10871922B2 (en) Integrated storage management between storage systems and container orchestrators
US11068389B2 (en) Data resiliency with heterogeneous storage
US10963189B1 (en) Coalescing write operations in a cloud-based storage system
DE112020003420T5 (de) Datenwiederherstellung in einem virtuellen Speichersystem
US11263095B1 (en) Managing a data analytics pipeline
DE112020003423T5 (de) Architektur von virtuellem speichersystem
US20210019063A1 (en) Utilizing data views to optimize secure data access in a storage system
US11416298B1 (en) Providing application-specific storage by a storage system
DE112019002609T5 (de) Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem
US11068162B1 (en) Storage management in a cloud data store
DE112020003277T5 (de) Erzeugen von tags für die datenzuweisung
DE102021113808A1 (de) Handhabung von Replikationen zwischen verschiedenen Netzwerken
US20200174671A1 (en) Bucket views
WO2019231634A1 (en) Mechanism for updating host file system and flash translation layer based on underlying nand technology
US11403000B1 (en) Resiliency in a cloud-based storage system
US11829629B2 (en) Synchronously replicating data using virtual volumes
US11340837B1 (en) Storage system management via a remote console
US10976947B2 (en) Dynamically selecting segment heights in a heterogeneous RAID group
US20210055885A1 (en) Enhanced data access using composite data views
US20220222004A1 (en) Prioritizing Garbage Collection Based On The Extent To Which Data Is Deduplicated
US20240004568A1 (en) Striping data across erase blocks having differing sizes

Legal Events

Date Code Title Description
R012 Request for examination validly filed