DE112019002609T5 - Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem - Google Patents

Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem Download PDF

Info

Publication number
DE112019002609T5
DE112019002609T5 DE112019002609.7T DE112019002609T DE112019002609T5 DE 112019002609 T5 DE112019002609 T5 DE 112019002609T5 DE 112019002609 T DE112019002609 T DE 112019002609T DE 112019002609 T5 DE112019002609 T5 DE 112019002609T5
Authority
DE
Germany
Prior art keywords
storage
data
storage system
storage systems
pod
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
DE112019002609.7T
Other languages
English (en)
Inventor
David Grunwald
Ronald Karr
Zoheb Shivani
John Colgrove
Thomas Gill
Connor Brooks
Claudiu Schmidt
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 DE112019002609T5 publication Critical patent/DE112019002609T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • 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/2069—Management of state, configuration or failover
    • 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/2082—Data synchronisation
    • 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/2094—Redundant storage or storage space
    • 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/2097—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 maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/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/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/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/0653—Monitoring storage devices or 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/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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/356—Switches specially adapted for specific applications for storage area networks
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82—Solving problems relating to consistency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5625—Operations, administration and maintenance [OAM]

Abstract

Speichersystem, das zwischen Vermittlungsmodellen innerhalb eines Speichersystems wechselt, wobei das Wechseln zwischen Vermittlungsmodellen Folgendes umfasst: Bestimmen einer Änderung in der Verfügbarkeit eines Vermittlerdienstes unter einem oder mehreren der Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung von dem Vermittlerdienst anfordern; und Vermitteln eines Fehlerreaktionsmodells, das als Alternative zu dem Vermittlerdienst unter einem oder mehreren der Vielzahl von Speichersystemen zu verwenden ist, zwischen der Vielzahl von Speichersystemen und als Reaktion auf das Bestimmen der Änderung in der Verfügbarkeit des Vermittlerdienstes.

Description

  • Figurenliste
  • Es zeigen:
    • 1A ein erstes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1B ein zweites Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1C ein drittes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 1D ein viertes Beispielsystem zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen.
    • 2A eine perspektivische Ansicht eines Storage-Clusters mit mehreren Speicherknoten und internem Speicher, der an jeden Speicherknoten gekoppelt ist, um gemäß einigen Ausführungsformen Network Attached Storage bereitzustellen.
    • 2B ein Blockdiagramm, das einen Interconnect-Switch zeigt, der gemäß einigen Ausführungsformen mehrere Speicherknoten koppelt.
    • 2C ein Blockdiagramm mit mehreren Ebenen, das den Inhalt eines Speicherknotens und den Inhalt einer der nichtflüchtigen Solid-State-Speichereinheiten gemäß einigen Ausführungsformen zeigt.
    • 2D eine Speicherserver-Umgebung, die Ausführungsformen der Speicherknoten und Speichereinheiten einiger vorhergehender Figuren in Übereinstimmung mit einigen Ausführungsformen verwendet.
    • 2E ist ein Blade-Hardware-Blockdiagramm, das eine Steuerungsebene, Rechen- und Speicherebenen und Authorities zeigt, die mit den zugrunde liegenden physischen Ressourcen interagieren, in Übereinstimmung mit einigen Ausführungsformen.
    • 2F Elasticity Software Layers in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 2G Authorities und Speicherressourcen in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 3A ein Diagramm eines Speichersystems, das für die Datenkommunikation mit einem Cloud-Dienst-Anbieter gemäß einigen Ausführungsformen der vorliegenden Offenbarung gekoppelt ist.
    • 3B ein Diagramm eines Speichersystems in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 4 ein Blockdiagramm, das eine Vielzahl von Speichersystemen darstellt, die gemäß einigen Ausführungsformen der vorliegenden Offenbarung an einen Pod angeschlossen sind.
    • 5 ein Blockdiagramm, das eine Vielzahl von Speichersystemen darstellt, die an einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung angeschlossen sind.
    • 6 ein Blockdiagramm, das eine Vielzahl von Speichersystemen darstellt, die an einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung angeschlossen sind.
    • 7 Diagramme von Metadaten-Darstellungen, die als strukturierte Sammlung von Metadaten-Objekten implementiert werden können, die ein logisches Volumen von Speicherdaten oder einen Teil eines logischen Volumens gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellen können.
    • 8 ein Flussdiagramm, das eine Beispielmethode der Vermittlung zwischen Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
    • 9 ein Flussdiagramm, das eine Beispielmethode zum Wechseln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems veranschaulicht, das Daten gemäß einigen Ausführungsformen der vorliegenden Offenbarung synchron repliziert.
    • 10 ein Flussdiagramm, das eine Beispielmethode zum Vermitteln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems veranschaulicht, das Daten gemäß einigen Ausführungsformen der vorliegenden Offenbarung synchron repliziert.
    • 11 ein Flussdiagramm, das eine Beispielmethode zum Vermitteln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems veranschaulicht, das Daten gemäß einigen Ausführungsformen der vorliegenden Offenbarung synchron repliziert.
  • BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
  • Beispielhafte Verfahren, Vorrichtungen und Produkte zum Vermitteln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems, das Daten gemäß den Ausführungsformen der vorliegenden Offenbarung synchron repliziert, werden unter Bezugnahme auf die beigefügen 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 110 (hier auch als „Controller“ bezeichnet) enthalten. Ein Speicher-Array-Controller 110 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 110 für die Ausführung verschiedener Speicheraufgaben konfiguriert werden. Zu den Speicheraufgaben können Folgendes einschließen: das Schreiben von Daten, die von den Datenverarbeitungsgeräten 164A-B empfangen werden, in das Speicher-Array 102A-B, das Löschen von Daten aus dem Speicher-Array 102A-B, das Abrufen von Daten aus dem Speicher-Array 102A-B und das Bereitstellen von Daten für die Datenverarbeitungsgeräte 164A-B, das Überwachen und Melden der Plattenauslastung und -leistung, das Ausführen von Redundanzbetrieb, wie z.B. Redundant Array of Independent Drives („RAID“) oder RAID-ähnliche Datenredundanzoperationen, das Komprimieren von Daten, das Verschlüsseln von Daten usw.
  • Der Speicher-Array-Controller 110 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 110 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 110 unabhängig an das LAN 160 gekoppelt werden. In Implementierungen kann der Speicher-Array-Controller 110 einen E/A-Controller oder ähnliches enthalten, der den Speicher-Array-Controller 110 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 110 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 110 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 110 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 110 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 110 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 110 enthält, die Anzahl der Programm-Löschzyklen („P/E“), die an einem bestimmten Speicherblock durchgeführt wurden, das Alter der in einem bestimmten Speicherblock gespeicherten Daten, die Art der Daten, die in einem bestimmten Speicherblock gespeichert sind, usw. In einigen Implementierungen können die Steuerinformationen mit einem zugehörigen Speicherblock als Metadaten gespeichert werden. In anderen Implementierungen können die Steuerinformationen für die Speicherlaufwerke 171A-F in einem oder mehreren bestimmten Speicherblöcken der Speicherlaufwerke 171A-F gespeichert werden, die von dem Speicher-Array-Controller 110 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 110 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 110 die Geräteverwaltungsaufgaben von den Speicherlaufwerken 171A-F des Speicher-Arrays 102AB entlasten, indem sie von den Speicherlaufwerken 171A-F Steuerinformationen abrufen, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben. Das Abrufen der Steuerinformationen von den Speicherlaufwerken 171A-Fkann z.B. durch den Speicher-Array-Controller 110 erfolgen, der die Speicherlaufwerke 171A-F nach dem Ort der Steuerinformationen für ein bestimmtes Speicherlaufwerk 171A-Fabfragt. 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-Fkönnen antworten, indem sie eine Antwortnachricht an den Speicher-Array-Controller 110 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 110 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 110 die Geräteverwaltungsaufgaben weiter von den Speicherlaufwerken 171A-Fabnehmen, indem sie als Reaktion auf den Empfang der Steuerinformationen eine Speicherlaufwerk-Betriebsoperation durchführen. Eine Speicherlaufwerk-Betriebsoperation 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-Betriebsoperation 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 110 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 110 (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 110 (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 110 kann sich ändern. Beispielsweise kann der Speicher-Array-Controller 110A mit dem sekundären Status und der Speicher-Array-Controller 11 OB 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 110 ü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 110 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 11 OB ähnlich sein. Der Speicher-Array-Controller 101 enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es sei darauf hingewiesen, dass der Speicher-Array-Controller 101 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder eine andere Weise konfiguriert sind. Zur Veranschaulichung der Merkmale des Speicher-Array-Controllers 101 können im Folgenden Elemente aus 1A eingeschlossen werden.
  • Der Speicher-Array-Controller 101 kann ein oder mehrere Verarbeitungsvorrichtungen 104 und einen Direktzugriffsspeicher (‚RAM‘) 111 enthalten. Die Verarbeitungsvorrichtung 104 (oder der Controller 101) repräsentiert eine oder mehrere Mehrzweck-Verarbeitungsvorrichtungen, wie z.B. einen Mikroprozessor, eine Zentraleinheit oder ähnliches. Insbesondere kann die Verarbeitungsvorrichtung 104 (oder der Controller 101) ein Complex Instruction Set Computing („CISC“) Mikroprozessor, ein Reduced Instruction Set Computing („RISC“) Mikroprozessor, ein Very Long Instruction Word („VLIW“) Mikroprozessor oder ein Prozessor sein, der andere Befehlssätze implementiert, oder ein Prozessor, der eine Kombination von Befehlssätzen implementiert. Bei der Verarbeitungsvorrichtung 104 (oder dem Controller 101) kann es sich auch um eine oder mehrere Verarbeitungsvorrichtungen für spezielle Zwecke handeln, wie z.B. Application Specific Integrated Circuit („ASIC“), Field Programmable Gate Array („FPGA“), Digital Signal Processor („DSP“), Netzwerkprozessor oder ähnliches.
  • Die Verarbeitungsvorrichtung 104 kann über eine Datenkommunikationsverbindung 106 an den RAM 111 angeschlossen werden, die als Hochgeschwindigkeits-Speicherbus, wie z.B. ein Double-Data-Rate-4-Bus („DDR4“), ausgeführt sein kann. Im RAM 111 ist ein Betriebssystem 112 gespeichert. In einigen Implementierungen werden Befehle 113 im RAM 111 gespeichert. Die Befehle 113 können Computerprogrammbefehle für die Durchführung von Operationen in einem Direct-Mapped-Flash-Speichersystem enthalten. In einer Ausführungsform ist ein Direct-Mapped-Flash-Speichersystem ein System, das Datenblöcke innerhalb von Flash-Laufwerken direkt und ohne Adressübersetzung durch die Speicher-Controller der Flash-Laufwerke adressiert.
  • In Implementierungen enthält der Speicher-Array-Controller 101 einen oder mehrere Host-Bus-Adapter 103A-C, die über eine Datenkommunikationsverbindung 105A-C an die Verarbeitungsvorrichtung 104 gekoppelt sind. In Implementierungen kann es sich bei den Host-Bus-Adaptern 103A-C um Computerhardware handeln, die ein Host-System (z.B. den Speicher-Array-Controller) mit anderen Netzwerk- und Speicher-Arrays verbindet. In einigen Beispielen kann es sich bei den Host-Bus-Adaptern 103A-C um einen Fibre-Channel-Adapter handeln, der die Verbindung des Speicher-Array-Controller 101 mit einem SAN ermöglicht, um einen Ethernet-Adapter, der die Verbindung des Speicher-Array-Controller 101 mit einem LAN ermöglicht, oder um einen ähnlichen Adapter. Host-Bus-Adapter 103A-C können über eine Datenkommunikationsverbindung 105A-C, wie z.B. einen PCIe-Bus, an die Verarbeitungsvorrichtung 104 gekoppelt werden.
  • In Implementierungen kann der Speicher-Array-Controller 101 einen Host-Bus-Adapter 114 einschließen, der mit einem Expander 115 gekoppelt ist. Der Expander 115 kann verwendet werden, um ein Host-System an eine größere Anzahl von Speicherlaufwerken anzuschließen. Der Expander 115 kann beispielsweise ein SAS-Expander sein, der verwendet wird, damit der Host-Bus-Adapter 114 an Speicherlaufwerke in einer Implementierung angeschlossen werden kann, in welcher der Host-Bus-Adapter 114 als SAS-Controller ausgeführt ist.
  • In Implementierungen kann der Speicher-Array-Controller 101 einen Switch 116 einschließen, der über eine Datenkommunikationsverbindung 109 mit der Verarbeitungsvorrichtung104 gekoppelt ist. Der Switch 116 kann eine Computer-Hardware-Vorrichtung sein, die mehrere Endpunkte von einem einzigen Endpunkt aus erstellen kann, wodurch mehrere Vorrichtungen einen einzigen Endpunkt gemeinsam nutzen können. Der Switch 116 kann z.B. ein PCIe-Switch sein, der an einen PCIe-Bus (z.B. Datenkommunikationsverbindung 109) gekoppelt ist und mehrere PCIe-Verbindungspunkte zur Midplane darstellt.
  • In Implementierungen enthält der Speicher-Array-Controller 101 eine Datenkommunikationsverbindung 107 zur Kopplung des Speicher-Array-Controllers 101 mit anderen Speicher-Array-Controllern. In einigen Beispielen kann die Datenkommunikationsverbindung 107 eine QuickPath Interconnect (QPI) - Verbindung sein.
  • Ein herkömmliches Speichersystem, welches herkömmliche Flash-Laufwerke verwendet, kann einen Prozess über die Flash-Laufwerke hinweg implementieren, die Teil des herkömmlichen Speichersystems sind. Beispielsweise kann ein Prozess auf höherer Ebene des Speichersystems einen Prozess über die Flash-Laufwerke hinweg initiieren und steuern. Ein Flash-Laufwerk des herkömmlichen Speichersystems kann jedoch einen eigenen Speicher-Controller enthalten, der den Prozess ebenfalls durchführt. So kann beim herkömmlichen Speichersystem sowohl ein Prozess auf höherer Ebene (z.B. initiiert durch das Speichersystem) als auch ein Prozess auf niedrigerer Ebene (z.B. initiiert durch einen Speicher-Controller des Speichersystems) ausgeführt werden.
  • Um verschiedene Unzulänglichkeiten eines herkömmlichen Speichersystems zu beheben, können Operationen von Prozessen auf höherer Ebene und nicht von den Prozessen auf niedrigerer Ebene durchgeführt werden. Beispielsweise kann das Flash-Speichersystem Flash-Laufwerke einschließen, die keine Speicher-Controller enthalten, die den Prozess bereitstellen. Daher kann das Betriebssystem des Flash-Speichersystems selbst den Prozess initiieren und steuern. Dies kann durch ein direkt abgebildetes Flash-Speichersystem erreicht werden, das Datenblöcke innerhalb der Flash-Laufwerke direkt und ohne eine Adressübersetzung durch die Speicher-Controller der Flash-Laufwerke adressiert.
  • Das Betriebssystem des Flash-Speichersystems kann eine Liste von Zuordnungseinheiten über mehrere Flash-Laufwerke des Flash-Speichersystems ermitteln und halten. Bei den Zuordnungseinheiten kann es sich um ganze Löschblöcke oder um mehrere Löschblöcke handeln. Das Betriebssystem kann eine Karte oder einen Adressbereich enthalten, der Adressen direkt den Löschblöcken der Flash-Laufwerke des Flash-Speichersystems zuordnet.
  • Ein direktes Abbilden auf die Löschblöcke der Flash-Laufwerke kann verwendet werden, um Daten neu zu schreiben und Daten zu löschen. Die Operationen können zum Beispiel auf einer oder mehreren Zuordnungseinheiten durchgeführt werden, die erste Daten und zweite Daten enthalten, wobei die ersten Daten gespeichert werden sollen und die zweiten Daten nicht mehr vom Flash-Speichersystem verwendet werden. Das Betriebssystem kann den Prozess einleiten, um die ersten Daten an neue Authorities innerhalb anderer Zuordnungseinheiten zu schreiben und die zweiten Daten zu löschen und die Zuordnungseinheiten als für die Verwendung für nachfolgende Daten verfügbar zu kennzeichnen. Somit kann der Prozess nur vom übergeordneten Betriebssystem des Flash-Speichersystems durchgeführt werden, ohne dass ein zusätzlicher untergeordneter Prozess von Controllern der Flash-Laufwerke durchgeführt wird.
  • Zu den Vorteilen des Prozesses, der nur vom Betriebssystem des Flash-Speichersystems durchgeführt wird, gehört eine erhöhte Zuverlässigkeit der Flash-Laufwerke des Flash-Speichersystems, da während des Prozesses keine unnötigen oder redundanten Schreibvorgänge durchgeführt werden. Ein möglicher Neuheitspunkt ist hier das Konzept der Initiierung und Steuerung des Prozesses am Betriebssystem des Flash-Speichersystems. Darüber hinaus kann der Prozess über mehrere Flash-Laufwerke hinweg vom Betriebssystem gesteuert werden. Dies steht im Gegensatz zu dem Prozess, der von einem Speicher-Controller eines Flash-Laufwerks durchgeführt wird.
  • Ein Speichersystem kann aus zwei Speicher-Array-Controllern bestehen, die sich einen Satz von Laufwerken für Failover-Zwecke teilen, oder es kann aus einem einzelnen Speicher-Array-Controller bestehen, der einen Storage-Dienst bereitstellt, der mehrere Laufwerke verwendet, oder es kann aus einem verteilten Netzwerk von Speicher-Array-Controllern bestehen, von denen jeder eine bestimmte Anzahl von Laufwerken oder eine bestimmte Menge an Flash-Speicher besitzt, wobei die Speicher-Array-Controller im Netzwerk zusammenarbeiten, um einen vollständigen Storage-Dienst bereitzustellen und bei verschiedenen Aspekten eines Storage-Dienstes einschließlich der Speicherzuweisung und der Garbage Collection zusammenzuarbeiten.
  • 1C veranschaulicht ein drittes Beispielsystem 117 zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen. Das System 117 (hier auch als „Speichersystem“ bezeichnet) enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es sei angemerkt, dass das System 117 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder eine andere Weise konfiguriert sind.
  • In einer Ausführung enthält das System 117 eine duale Peripheral Component Interconnect („PCI“) Flash-Speichervorrichtung 118 mit separat adressierbarem Schnellschreibspeicher. Das System 117 kann einen Speicher-Controller 119 einschließen. In einer Ausführungsform kann der Speicher-Controller 119A-D eine CPU, eine ASIC, ein FPGA oder eine andere Schaltungsanordnung sein, die die gemäß der vorliegenden Offenbarung erforderlichen Steuerungsstrukturen implementiert. In einer Ausführungsform schließt das System 117 Flash-Speichervorrichtungen (z.B. einschließlich Flash-Speichervorrichtungen 120a-n) ein, die operativ mit verschiedenen Kanälen des Speicher-Controllers 119 gekoppelt sind. Flash-Speichervorrichtungen 120a-n können dem Controller 119A-D als eine adressierbare Sammlung von Flash-Seiten, Löschblöcken und/oder Steuerelementen präsentiert werden, die ausreichen, um dem Speicher-Controller 119A-D die Programmierung und den Abruf verschiedener Aspekte der Flash-Speichervorrichtung zu ermöglichen. In einer Ausführungsform kann der Speicher-Controller 119A-D Operationen auf Flash-Speichervorrichtungen 120a-n durchführen, einschließlich des Speicherns und Abrufens von Dateninhalten von Seiten, des Anordnens und Löschens von Blöcken, des Verfolgens von Statistiken bezüglich der Verwendung und Wiederverwendung von Flash-Speicherseiten, Löschblöcken und -zellen, des Verfolgens und Vorhersagens von Fehlercodes und Fehlern innerhalb des Flash-Speichers, der Steuerung von Spannungspegeln, die mit der Programmierung und dem Abrufen von Inhalten von Flash-Zellen verbunden sind, usw.
  • In einer Ausführungsform kann das System 117 einen RAM 121 enthalten, um separat adressierbare Schnellschreibdaten zu speichern. In einer Ausführungsform kann der RAM 121 aus einem oder mehreren separaten diskreten Bausteinen bestehen. In einer anderen Ausführungsform kann der RAM 121 in den Speicher-Controller 119A-D oder in mehrere Speicher-Controller integriert sein. Der RAM 121 kann auch für andere Zwecke verwendet werden, z.B. als temporärer Programmspeicher für eine Verarbeitungsvorrichtung (z.B. eine CPU) im Speicher-Controller 119.
  • In einer Ausführungsform kann das System 117 ein Energiespeichergerät 122 enthalten, z.B. eine wieder aufladbare Batterie oder einen Kondensator. Das Energiespeichergerät 122 kann Energie speichern, die ausreicht, um den Speicher-Controller 119, einen Teil des RAM-Speichers (z.B. RAM 121) und einen Teil des Flash-Speichers (z.B. Flash-Speicher 120a-120n) ausreichend lange zu versorgen, um den Inhalt des RAM-Speichers in den Flash-Speicher zu schreiben. In einer Ausführungsform kann der Speicher-Controller 119A-D den Inhalt des RAM in den Flash-Speicher schreiben, wenn der Speicher-Controller einen Verlust der externen Stromversorgung feststellt.
  • In einer Ausführungsform umfasst das System 117 zwei Datenkommunikationsverbindungen 123a, 123b. In einer Ausführungsform können die Datenkommunikationsverbindungen 123a, 123b PCI-Schnittstellen sein. In einer anderen Ausführungsform können die Datenkommunikationsverbindungen 123a, 123b auf anderen Kommunikationsstandards basieren (z.B. HyperTransport, InfiniBand usw.). Datenkommunikationsverbindungen 123a, 123b können auf nichtflüchtigen Speicher-Express („NVMe“) - Spezifikationen oder NVMe over Fabrics („NVMf“) - Spezifikationen basieren, die eine externe Verbindung mit dem Speicher-Controller 119A-D von anderen Komponenten im Speichersystem 117 ermöglichen. Es ist zu beachten, dass Datenkommunikationsverbindungen hier der Einfachheit halber austauschbar als PCI-Busse bezeichnet werden können.
  • Das System 117 kann auch eine externe Stromquelle (nicht abgebildet) enthalten, die über eine oder beide Datenkommunikationsverbindungen 123a, 123b oder auch separat bereitgestellt werden kann. Eine alternative Ausführungsform umfasst einen separaten Flash-Speicher (nicht abgebildet), der für die Speicherung des Inhalts von dem RAM 121 bestimmt ist. Der Speicher-Controller 119A-D kann über einen PCI-Bus eine logische Vorrichtung darstellen, die einen adressierbaren logischen Schnellschreibbaustein oder einen bestimmten Teil des logischen Adressraums des Speicherbausteins 118 enthalten kann, der als PCI-Speicher oder als persistenter Speicher dargestellt werden kann. In einer Ausführungsform werden die in das Gerät zu speichernden Operationen in den RAM 121 geleitet. Bei einem Stromausfall kann der Speicher-Controller 119A-D gespeicherte Inhalte, die mit dem adressierbaren logischen Schnellschreibspeicher assoziiert sind, in den Flash-Speicher (z.B. Flash-Speicher 120a-n) für eine langfristige persistente Speicherung schreiben.
  • In einer Ausführungsform kann die logische Vorrichtung eine Darstellung eines Teils oder des gesamten Inhalts der Flash-Speichervorrichtungen 120a-n enthalten, wobei diese Darstellung es einem Speichersystem mit einer Speichervorrichtung 118 (z.B. Speichersystem 117) ermöglicht, Flash-Speicherseiten direkt anzusprechen und Löschblöcke von Speichersystemkomponenten, die sich außerhalb des Speicherbausteins befinden, über den PCI-Bus direkt umzuprogrammieren. Die Darstellung kann es auch einer oder mehreren der externen Komponenten ermöglichen, andere Aspekte des Flash-Speichers zu steuern und abzurufen, darunter einige oder alle der folgenden: Verfolgen von Statistiken in Bezug auf die Nutzung und Wiederverwendung von Flash-Speicherseiten, Löschblöcken und Zellen über alle Flash-Speichervorrichtungen hinweg; Verfolgen und Vorhersagen von Fehlercodes und Fehlern innerhalb der Flash-Speichervorrichtungen und über die Flash-Speichervorrichtungen hinweg; Steuern der Spannungspegel in Verbindung mit der Programmierung und dem Abrufen der Inhalte von Flash-Zellen; usw.
  • In einer Ausführungsform kann das Energiespeichergerät 122 ausreichen, um den Abschluss von laufenden Operationen an den Flash-Speichervorrichtungen 120a-120n sicherzustellen, und das Energiespeichergerät 122 kann den Speicher-Controller 119A-D und zugehörige Flash-Speichervorrichtungen (z.B. 120a-n) für diese Operationen sowie für die Speicherung von schnell schreibendem RAM in Flash-Speicher antreiben. Das Energiespeichergerät 122 kann zum Speichern akkumulierter Statistiken und anderer Parameter verwendet werden, die von den Flash-Speichervorrichtungen 120a-n und/oder dem Speicher-Controller 119 gespeichert und verfolgt werden. Für einige oder alle der hier beschriebenen Vorgänge können separate Kondensatoren oder Speichervorrichtungen (z.B. kleinere Kondensatoren in der Nähe der Flash-Speichervorrichtungen oder die in diese eingebettet sind) verwendet werden.
  • Verschiedene Schemata können verwendet werden, um die Lebensdauer der gespeicherten Energiekomponente zu verfolgen und zu optimieren, wie z.B. die Anpassung der Spannungspegel im Laufe der Zeit, die Teilentladung des Energiespeichers 122 zur Messung von entsprechenden Entladungseigenschaften usw. Wenn die verfügbare Energie mit der Zeit abnimmt, kann die effektiv verfügbare Kapazität des adressierbaren Schnellschreibspeichers verringert werden, um sicherzustellen, dass er auf der Grundlage der aktuell verfügbaren gespeicherten Energie sicher beschrieben werden kann.
  • 1D veranschaulicht ein drittes Beispielsystem 124 zur Datenspeicherung in Übereinstimmung mit einigen Implementierungen. In einer Ausführungsform umfasst das System 124 die Speicher-Controller 125a, 125b. In einer Ausführungsform sind die Speicher-Controller 125a, 125b operativ mit Dual-PCI-Speichergeräten 119a, 119b bzw. 119c, 119d gekoppelt. Die Speicher-Controller 125a, 125b können operativ (z.B. über ein Speichernetzwerk 130) mit einer bestimmten Anzahl von Host-Computern 127a-n gekoppelt sein.
  • In einer Ausführungsform stellen zwei Speicher-Controller (z. B. 125a und 125b) Storage-Dienste zur Verfügung, z. B. ein SCS-Blockspeicher-Array, einen Dateiserver, einen Objektserver, eine Datenbank oder einen Datenanalysedienst usw. Die Speicher-Controller 125a, 125b können über eine bestimmte Anzahl von Netzwerkschnittstellen (z.B. 126a-d) Dienste für Host-Computer 127a-n außerhalb des Speichersystems 124 bereitstellen. Die Speicher-Controller 125a, 125b können integrierte Dienste oder eine Anwendung vollständig innerhalb des Speichersystems 124 bereitstellen und so ein konvergiertes Speicher- und Rechnersystem bilden. Die Speicher-Controller 125a, 125b können den Schnellschreibspeicher innerhalb oder über Speichergeräte119a-d hinweg nutzen, um laufende Operationen zu protokollieren, um sicherzustellen, dass die Operationen bei Stromausfall, Entfernen des Speicher-Controllers, Herunterfahren des Speicher-Controllers oder des Speichersystems oder bei einem Fehler einer oder mehrerer Software- oder Hardwarekomponenten innerhalb des Speichersystems 124 nicht verloren gehen.
  • In einer Ausführungsform arbeiten die Controller 125a, 125b als PCI-Master für die einen oder anderen PCI-Busse 128a, 128b. In einer anderen Ausführungsform können die PCI-Busse 128a und 128b auf anderen Kommunikationsstandards basieren (z.B. HyperTransport, InfiniBand usw.). Andere Speichersystemausführungen können Speicher-Controller 125a, 125b als Multi-Master für beide PCI-Busse 128a, 128b betreiben. Alternativ kann eine PCI/NVMe/NVMf-Switching-Infrastruktur oder -Fabric mehrere Speicher-Controller verbinden. Einige Speichersystemausführungen ermöglichen es Speichergeräten, direkt miteinander zu kommunizieren, anstatt nur mit Speicher-Controllern zu kommunizieren. In einer Ausführungsform kann ein Speicher-Controller 119a unter der Leitung eines Speicher-Controllers 125a betrieben werden, um Daten, die in Flash-Speichergeräten gespeichert werden sollen, aus Daten, die im RAM gespeichert wurden (z.B. RAM 121 in 1C), zu synthetisieren und zu übertragen. So kann z.B. eine neu berechnete Version des RAM-Inhalts übertragen werden, nachdem ein Speicher-Controller festgestellt hat, dass eine Operation im gesamten Speichersystem vollständig festgelegt wurde, oder wenn der Schnellschreibspeicher auf der Vorrichtung eine bestimmte benutzte Kapazität erreicht hat, oder nach einer bestimmten Zeit, um die Sicherheit der Daten zu verbessern oder um adressierbare Schnellschreibkapazität zur Wiederverwendung freizugeben. Dieser Mechanismus kann z.B. verwendet werden, um eine zweite Übertragung über einen Bus (z.B. 128a, 128b) von den Speicher-Controllern 125a, 125b zu vermeiden. In einer Ausführungsform kann ein Neuberechnen das Komprimieren von Daten, das Anhängen von Indexierungs- oder anderen Metadaten, das Kombinieren mehrerer Datensegmente miteinander, das Durchführen von Löschcode-Berechnungen usw. umfassen.
  • In einer Ausführungsform kann ein Speicher-Controller 119a, 119b unter der Leitung eines Speicher-Controllers 125a, 125b betriebsbereit sein, um Daten, von im RAM (z.B. RAM 121 in 1C) gespeicherten Daten, zu berechnen und zu anderen Vorrichtungen zu übertragen, ohne Beteiligung der Speicher-Controller 125a, 125b. Diese Operation kann verwendet werden, um Daten, die in einem Controller 125a gespeichert sind, auf einen anderen Controller 125b zu spiegeln, oder sie kann verwendet werden, um Komprimierungs, Datenaggregations- und/oder Löschkodierungsberechnungen und -übertragungen auf Speichergeräte auszulagern, um die Belastung der Speicher-Controller oder der Speicher-Controller-Schnittstelle 129a, 129b auf den PCI-Bus 128a, 128b zu reduzieren.
  • Ein Speicher-Controller 119A-D kann Mechanismen zum Implementieren von Hochverfügbarkeitsprimitiven zur Verwendung durch andere Teile eines Speichersystems außerhalb des Dual-PCI-Speichergeräts 118 enthalten. Beispielsweise können Reservierungs- oder Ausschlussprimitive bereitgestellt werden, so dass in einem Speichersystem mit zwei Speicher-Controllern, die einen hochverfügbaren Storage-Dienst bereitstellen, ein Speicher-Controller den Zugriff des anderen Speicher-Controllers auf das Speichergerät oder den weiteren Zugriff darauf verhindern kann. Dies könnte z.B. in Fällen verwendet werden, in denen ein Controller feststellt, dass der andere Controller nicht richtig funktioniert, oder wenn die Verbindung zwischen den beiden Speicher-Controllern selbst nicht richtig funktioniert.
  • In einer Ausführungsform umfasst ein Speichersystem zur Verwendung mit Dual PCI Direct Mapped Storage-Geräten mit separat adressierbarem Schnellschreibspeicher, Systeme, die Löschblöcke oder Gruppen von Löschblöcken als Zuordnungseinheiten zum Speichern von Daten im Auftrag des Storage-Dienstes oder zum Speichern von Metadaten (z. B. Indizes, Protokolle usw.) verwalten, die mit dem Storage-Dienst assoziiert sind, oder zum ordnungsgemäßen Verwalten des Speichersystems selbst. Flash-Seiten, die einige Kilobyte groß sein können, können geschrieben werden, wenn Daten ankommen oder wenn das Speichersystem Daten für lange Zeitintervalle (z.B. oberhalb eines definierten Zeitschwellenwertes) halten soll. Um Daten schneller zu übertragen oder um die Anzahl der Schreibvorgänge auf die Flash-Speichergeräte zu reduzieren, können die Speicher-Controller zunächst Daten in den separat adressierbaren Schnellschreibspeicher auf einem weiteren Speichergerät schreiben.
  • In einer Ausführungsform können die Speicher-Controller 125a, 125b die Verwendung von Löschblöcken innerhalb und zwischen Speichergeräten (z.B. 118) in Übereinstimmung mit einem Alter und der erwarteten Restlebensdauer der Speichergeräte oder auf der Grundlage anderer Statistiken initiieren. Die Speicher-Controller 125a, 125b können in Übereinstimmung mit nicht mehr benötigten Seiten die Garbage Collection und Datenmigrationsdaten zwischen Speichergeräten initiieren, um die Lebensdauer von Flash-Seiten und Löschblöcken und die gesamte Systemleistung zu verwalten.
  • In einer Ausführungsform kann das Speichersystem 124 Spiegelungs- und/oder Löschkodierungsschemata als Teil der Speicherung von Daten in einem adressierbaren Schnellschreibspeicher und/oder als Teil des Schreibens von Daten in Zuordnungseinheiten, die mit Löschblöcken verbunden sind, verwenden. Löschcodes können sowohl über Speichergeräte hinweg als auch innerhalb von Löschblöcken oder Zuordnungseinheiten oder innerhalb und zwischen Flash-Speichergeräten auf einem einzelnen Speichergerät verwendet werden, um Redundanz gegen Ausfälle einzelner oder mehrerer Speichergeräte zu gewährleisten oder um vor internen Beschädigungen von Flash-Speicherseiten zu schützen, die aus Flash-Speicheroperationen oder aus der Degradierung von Flash-Speicherzellen resultieren. Die Spiegel- und Löschcodierung auf verschiedenen Ebenen kann verwendet werden, um mehrere Arten von Ausfällen, die einzeln oder in Kombination auftreten, zu beheben.
  • Die mit Bezug auf die 2A-G dargestellten Ausführungsformen veranschaulichen einen Storage-Cluster, der Benutzerdaten speichert, z. B. Benutzerdaten, die von einem oder mehreren Benutzer- oder Client-Systemen oder anderen Quellen außerhalb des Storage-Clusters stammen. Der Storage-Cluster verteilt Benutzerdaten auf Speicherknoten, die innerhalb eines Chassis oder auf mehrere Chassis untergebracht sind, wobei eine Löschcodierung und redundante Kopien von Metadaten verwendet werden. Die Löschcodierung bezieht sich auf ein Verfahren zur Datensicherung oder -wiederherstellung, bei dem Daten über eine Reihe verschiedener Standorte, wie z. B. Platten, Speicherknoten oder geografische Standorte, gespeichert werden. Ein Flash-Speicher ist ein Typ von Festkörperspeicher, der in die Ausführungsformen integriert werden kann, obwohl die Ausführungsformen auch auf andere Typen von Festkörperspeichern oder andere Speichermedien, einschließlich Nicht-Festkörperspeicher, erweitert werden können. In einem geclusterten Peer-to-Peer-System werden die Steuerung über Speicherorte und Arbeitslasten auf die Speicherorte verteilt. Aufgaben wie das Vermitteln der Kommunikation zwischen den verschiedenen Speicherknoten, das Erkennen der Nichtverfügbarkeit eines Speicherknotens und das Ausgleichen der E/As (Ein- und Ausgänge) über die verschiedenen Speicherknoten werden alle auf verteilter Basis abgewickelt. Daten werden über mehrere Speicherknoten in Datenfragmenten oder -Stripes angeordnet oder verteilt, die in einigen Ausführungsformen die Datenwiederherstellung unterstützen. Der Besitz von Daten kann innerhalb eines Clusters unabhängig von Ein- und Ausgabemustern neu zugewiesen werden. Diese im Folgenden näher beschriebene Architektur ermöglicht den Ausfall eines Speicherknotens im Cluster, wobei das System betriebsbereit bleibt, da die Daten von anderen Speicherknoten rekonstruiert werden können und somit für Eingabe- und Ausgabeoperationen verfügbar bleiben. In verschiedenen Ausführungsformen kann ein Speicherknoten als ein Clusterknoten, ein Blade oder ein Server bezeichnet werden.
  • Der Storage-Cluster kann sich in einem Chassis befinden, d. h. in einem Gehäuse, das einen oder mehrere Speicherknoten enthält. Ein Mechanismus zur Stromversorgung jedes Speicherknotens, wie z. B. ein Stromverteilungsbus, und ein Kommunikationsmechanismus, wie z. B. ein Kommunikationsbus, der die Kommunikation zwischen den Speicherknoten ermöglicht, sind im Chassis enthalten. Der Storage-Cluster kann gemäß einigen Ausführungsformen als unabhängiges System an einem Ort laufen. In einer Ausführungsform enthält ein Chassis mindestens zwei Instanzen sowohl der Stromverteilung als auch des Kommunikationsbusses, die unabhängig voneinander aktiviert oder deaktiviert werden können. Der interne Kommunikationsbus kann ein Ethernet-Bus sein, jedoch sind andere Technologien wie PCIe, InfiniBand und andere gleichermaßen geeignet. Das Gehäuse bietet einen Anschluss für einen externen Kommunikationsbus, um die Kommunikation zwischen mehreren Gehäusen, direkt oder über einen Switch, und mit Clientsystemen zu ermöglichen. Für die externe Kommunikation kann eine Technologie wie Ethernet, InfiniBand, Fibre Channel usw. verwendet werden. In einigen Ausführungsformen verwendet der externe Kommunikationsbus unterschiedliche Kommunikationsbustechnologien für die Kommunikation zwischen Chassis und Client-Systemen. Wenn ein Switch innerhalb oder zwischen dem Chassis eingesetzt wird, kann der Switch als Übersetzung zwischen mehreren Protokollen oder Technologien fungieren. Wenn mehrere Chassis miteinander verbunden sind, um einen Storage-Cluster zu definieren, kann ein Client über proprietäre Schnittstellen oder Standardschnittstellen wie Netzwerk-Dateisystem („NFS“), Common Internet File System („CIFS“), Small Computer System Interface („SCSI“) oder Hypertext Transfer Protocol („HTTP“) auf den Storage-Cluster zugreifen. Die Übersetzung vom Client-Protokoll kann am Switch, am externen Kommunikationsbus des Chassis oder innerhalb jedes Speicherknotens erfolgen. In einigen Ausführungsformen können mehrere Chassis gekoppelt oder über einen Aggregator-Switch miteinander verbunden sein. Ein Teil und/oder das gesamte gekoppelte oder verbundene Chassis kann als Storage-Cluster bezeichnet werden. Wie oben erläutert, kann jedes Chassis mehrere Blades aufweisen, jedes Blade verfügt über eine MAC-Adresse (Media Access Control), aber der Storage-Cluster wird einem externen Netzwerk so präsentiert, als hätte er in einigen Ausführungsformen eine einzige Cluster-IP-Adresse und eine einzige MAC-Adresse.
  • Jeder Speicherknoten kann ein oder mehrere Speicherserver sein, und jeder Speicherserver ist mit einer oder mehreren nichtflüchtigen Festkörperspeichereinheiten verbunden, die als Speichereinheiten oder Speichergeräte bezeichnet werden können. Eine Ausführungsform umfasst einen einzelnen Speicherserver in jedem Speicherknoten und zwischen ein bis acht nichtflüchtige Festkörperspeichereinheiten, wobei dieses eine Beispiel jedoch nicht einschränkend sein soll. Der Speicherserver kann einen Prozessor, DRAM und Schnittstellen für den internen Kommunikationsbus und die Stromverteilung für jeden der Energiebusse enthalten. Innerhalb des Speicherknotens teilen sich die Schnittstellen und die Speichereinheit einen Kommunikationsbus, z.B. PCI Express, in einigen Ausführungsformen. Die nichtflüchtigen Festkörperspeichereinheiten können über einen Kommunikationsbus des Speicherknotens direkt auf die interne Kommunikationsbusschnittstelle zugreifen oder den Speicherknoten auffordern, auf die Busschnittstelle zuzugreifen. Die nichtflüchtige Festkörper-Speichereinheit enthält eine eingebettete CPU, einen Festkörper-Speicher-Controller und eine Anzahl von Festkörper-Massenspeichern, z.B. zwischen 2-32 Terabyte („TB“) in einigen Ausführungsformen. Ein eingebettetes flüchtiges Speichermedium, wie z.B. DRAM, und eine Energiereservevorrichtung sind in der nichtflüchtigen Festkörperspeichereinheit enthalten. In einigen Ausführungsformen ist die Energiereservevorrichtung ein Kondensator, Superkondensator oder eine Batterie, die es ermöglicht, eine Teilmenge des DRAM-Inhalts im Falle eines Stromausfalls auf ein stabiles Speichermedium zu übertragen. In einigen Ausführungsformen ist die nichtflüchtige Festkörperspeichereinheit mit einem Speicher der Speicherklasse aufgebaut, wie z. B. einem Phase Change oder Magnetoresistive Random Access Memory („MRAM“), welcher einen DRAM ersetzt und eine Verzögerungsvorrichtung mit reduzierter Leistung ermöglicht.
  • Eines von vielen Merkmalen der Speicherknoten und des nichtflüchtigen Festkörperspeichers ist die Fähigkeit, Daten in einem Storage-Cluster proaktiv wiederherzustellen. Die Speicherknoten und der nichtflüchtige Festkörperspeicher können bestimmen, wann ein Speicherknoten oder ein nichtflüchtiger Festkörperspeicher im Storage-Cluster nicht erreichbar ist, unabhängig davon, ob ein Versuch zum Lesen von Daten unter Einbeziehung dieses Speicherknotens oder des nichtflüchtigen Festkörperspeichers erfolgt. Die Speicherknoten und der nichtflüchtige Festkörperspeicher arbeiten dann zusammen, um die Daten an zumindest teilweise neuen Orten wiederherzustellen und zu rekonstruieren. Dies stellt insofern eine proaktive Wiederherstellung dar, als das System die Daten wiederherstellt, ohne zu warten, bis die Daten für einen Lesezugriff benötigt werden, der von einem Client-System aus eingeleitet wird, das den Storage-Cluster verwendet. Diese und weitere Einzelheiten zum Speicher und dessen Betrieb werden im Folgenden erörtert.
  • 2A ist eine perspektivische Ansicht eines Storage-Clusters 161 mit mehreren Speicherknoten 150 und internem Festkörperspeicher, der an jeden Speicherknoten gekoppelt ist, um gemäß einigen Ausführungsformen Network Attached Storage oder Storage Area Network bereitzustellen. Ein netzwerkgebundener Speicher, ein Speicherbereichsnetzwerk oder ein Storage-Cluster oder ein anderer Speicher könnte einen oder mehrere Storage-Cluster 161 mit jeweils einem oder mehreren Speicherknoten 150 in einer flexiblen und rekonfigurierbaren Anordnung sowohl der physischen Komponenten als auch der Menge des dadurch bereitgestellten Speicherplatzes enthalten. Der Storage-Cluster 161 ist so konzipiert, dass er in ein Rack passt, und ein oder mehrere Racks können je nach Wunsch für den Speicher eingerichtet und bestückt werden. Der Storage-Cluster 161 hat ein Gehäuse 138 mit mehreren Steckplätzen 142. Es ist zu beachten, dass das Chassis 138 als Gehäuse, Einschub oder Rack-Einheit bezeichnet werden kann. In einer Ausführung verfügt das Chassis 138 über vierzehn Steckplätze 142, obwohl andere Steckplatzanzahlen ohne weiteres möglich sind. Einige Ausführungsformen haben beispielsweise vier Steckplätze, acht Steckplätze, sechzehn Steckplätze, zweiunddreißig Steckplätze oder eine andere geeignete Anzahl von Steckplätzen. Jeder Steckplatz 142 kann in einigen Ausführungsformen einen Speicherknoten 150 aufnehmen. Das Chassis 138 enthält Flaps 148, die zur Montage des Chassis 138 in einem Rack verwendet werden können. Lüfter 144 sorgen für die Luftzirkulation zur Kühlung der Speicherknoten 150 und deren Komponenten, obwohl auch andere Kühlkomponenten verwendet werden könnten oder eine Ausführung ohne Kühlkomponenten entwickelt werden könnte. Eine Switch Fabric 146 verbindet die Speicherknoten 150 innerhalb des Chassis 138 miteinander und mit einem Netzwerk zur Kommunikation mit dem Speicher. In einer hier dargestellten Ausführungsform sind die Steckplätze 142 links von der Switch Fabric 146 und den Lüftern 144 mit Speicherknoten 150 belegt, während die Steckplätze 142 rechts von der Switch Fabric 146 und den Lüftern 144 leer sind und zur Veranschaulichung für das Einsetzen von Speicherknoten 150 zur Verfügung stehen. Diese Konfiguration ist ein Beispiel, und ein oder mehrere Speicherknoten 150 könnten die Steckplätze 142 in verschiedenen weiteren Anordnungen belegen. Die Speicherknotenanordnungen müssen in einigen Ausführungsformen nicht sequentiell oder benachbart sein. Die Speicherknoten 150 sind Hot-Plug-fähig, d. h. ein Speicherknoten 150 kann in einen Steckplatz 142 im Chassis 138 eingesetzt oder aus einem Steckplatz 142 entfernt werden, ohne das System anzuhalten oder auszuschalten. Beim Einsetzen oder Entfernen des Speicherknotens 150 aus dem Steckplatz 142 konfiguriert sich das System automatisch neu, um die Änderung zu erkennen und sich daran anzupassen. Die Rekonfiguration umfasst in einigen Ausführungsformen die Wiederherstellung der Redundanz und/oder den Neuausgleich von Daten oder Last.
  • Jeder Speicherknoten 150 kann mehrere Komponenten aufweisen. In der hier gezeigten Ausführungsform enthält der Speicherknoten 150 eine Leiterplatte 159, die mit einer CPU 156 bestückt ist, d.h. einen Prozessor, einen Speicher 154, der mit der CPU 156 gekoppelt ist, und einen nichtflüchtigen Festkörperspeicher 152, der mit der CPU 156 gekoppelt ist, obwohl andere Halterungen und/oder Komponenten in weiteren Ausführungsformen verwendet werden könnten. Der Speicher 154 verfügt über Befehle, die von der CPU 156 ausgeführt werden, und/oder Daten, die von der CPU 156 bearbeitet werden. Wie weiter unten näher erläutert wird, enthält der nichtflüchtige Festkörperspeicher 152 Flash-Speicher oder, in weiteren Ausführungsformen, andere Arten von Festkörperspeichern.
  • Wie in 2A dargestellt, ist der Storage-Cluster 161 skalierbar, was bedeutet, dass Speicherkapazität mit uneinheitlichen Speichergrößen leicht hinzugefügt werden kann, wie vorstehend beschrieben. Ein oder mehrere Speicherknoten 150 können in jedes Chassis eingesteckt oder aus jedem Chassis entfernt werden, und der Storage-Cluster konfiguriert sich in einigen Ausführungsformen selbst. Plug-in-Speicherknoten 150 können, unabhängig davon, ob sie in ein Chassis im Auslieferungszustand eingebaut oder später hinzugefügt werden, unterschiedliche Größen aufweisen. Beispielsweise kann ein Speicherknoten 150 in einer Ausführung ein beliebiges Vielfaches von 4 TB haben, z. B. 8 TB, 12 TB, 16 TB, 32 TB usw. In weiteren Ausführungsformen kann ein Speicherknoten 150 ein beliebiges Vielfaches anderer Speichermengen oder -kapazitäten haben. Die Speicherkapazität jedes Speicherknotens 150 wird übertragen und beeinflusst die Entscheidungen darüber, wie die Daten in Stripes gespeichert werden sollen. Um eine maximale Speichereffizienz zu erzielen, kann sich eine Ausführungsform so breit wie möglich im Stripe selbst konfigurieren, sofern eine vorgegebene Anforderung an den fortgesetzten Betrieb mit einem Verlust von bis zu einer oder bis zu zwei nichtflüchtigen Festkörperspeichereinheiten 152 oder Speicherknoten 150 innerhalb des Chassis erfüllt ist.
  • 2B ist ein Blockdiagramm, das eine Kommunikationsverbindung 171A-F und einen Stromverteilungsbus 172 zeigt, die mehrere Speicherknoten 150 koppeln. Erneut Bezug nehmend auf 2A, kann die Kommunikationsverbindung 171A-F 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 171A-F 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 171A-F 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 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-Dienst-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-Dienst-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-Dienst-Anbieter 302 transportieren kann. Eine solche Datenkommunikationsverbindung 304 kann vollständig verdrahtet, vollständig drahtlos oder eine gewisse Aggregation von verdrahteten und drahtlosen Datenkommunikationswegen sein. In einem solchen Beispiel können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Dienst-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung eines oder mehrerer Datenkommunikationsprotokolle ausgetauscht werden. Beispielsweise können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Dienst-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung des Handheld Device Transfer Protocol („HDTP“), des Hypertext Transfer Protocol (‚HTTP‘), Internet Protocol (‚IP‘), Real-Time Transfer Protocol (‚RTP‘), Transmission Control Protocol (‚TCP‘), User Datagram Protocol (‚UDP‘), Wireless Application Protocol (‚WAP‘), oder anderer Protokolle ausgetauscht werden.
  • Der in 3A dargestellte Cloud-Dienst-Anbieter 302 kann beispielsweise als ein System und eine Rechenumgebung verkörpert werden, die den Nutzern des Cloud-Dienst-Anbieters 302 Dienste durch die gemeinsame Nutzung von Rechenressourcen über die Datenkommunikationsverbindung 304 bereitstellt. Der Cloud-Dienst-Anbieter 302 kann bei Bedarf Zugriff auf einen gemeinsamen Pool konfigurierbarer Computing-Ressourcen wie Computernetzwerke, Server, Speicher, Anwendungen und Dienste usw. bereitstellen. Der gemeinsame Pool konfigurierbarer Ressourcen kann schnell und mit minimalem Betriebsaufwand für einen Benutzer des Cloud-Dienst-Anbieters 302 bereitgestellt und freigegeben werden. Im Allgemeinen ist dem Benutzer des Cloud-Dienst-Anbieters 302 nicht bekannt, welche genauen Computing-Ressourcen der Cloud-Dienst-Anbieter 302 für die Bereitstellung der Dienste verwendet. Obwohl in vielen Fällen ein solcher Cloud-Dienst-Anbieter 302 über das Internet zugänglich sein kann, werden diejenigen, die im Fachgebiet erfahren sind, erkennen, dass jedes System, das die Nutzung gemeinsam genutzter Ressourcen zur Bereitstellung von Diensten für einen Benutzer über eine beliebige Datenkommunikationsverbindung abstrahiert, als Cloud-Dienst-Anbieter 302 betrachtet werden kann.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Dienst-Anbieter 302 so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 durch die Implementierung verschiedener Dienstmodelle eine Vielzahl von Diensten zur Verfügung stellt. Beispielsweise kann der Cloud-Dienst-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Infrastructure-as-a-Service“ („laaS“) - Servicemodells bereitstellt, bei dem der Cloud-Dienst-Anbieter 302 Recheninfrastruktur wie virtuelle Maschinen und andere Ressourcen als Dienst für Abonnenten anbietet. Darüber hinaus kann der Cloud-Dienst-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Platform-as-a-Service“ („PaaS“) - Servicemodells anbietet, bei dem der Cloud-Dienst-Anbieter 302 Anwendungsentwicklern eine Entwicklungsumgebung zur Verfügung stellt. Eine solche Entwicklungsumgebung kann z.B. ein Betriebssystem, eine Ausführungsumgebung für die Programmiersprache, eine Datenbank, einen Webserver oder andere Komponenten umfassen, die von Anwendungsentwicklern zur Entwicklung und zum Betrieb von Softwarelösungen auf einer Cloud-Plattform verwendet werden können. Darüber hinaus kann der Cloud-Dienst-Anbieter 302 so konfiguriert werden, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Implementierung eines „Software-as-a-Service“ („SaaS“)-Servicemodells bereitstellt, bei dem der Cloud-Dienst-Anbieter 302 Anwendungssoftware und Datenbanken anbietet, sowie die Plattformen, die für die Ausführung der Anwendungen für das Speichersystem 306 und die Benutzer des Speichersystems 306 verwendet werden, wodurch das Speichersystem 306 und die Benutzer des Speichersystems 306 mit On-Demand-Software versorgt werden und die Notwendigkeit entfällt, die Anwendung auf lokalen Computern zu installieren und auszuführen, was die Handhabung und Unterstützung der Anwendung vereinfachen kann. Der Cloud-Dienst-Anbieter 302 kann darüber hinaus so konfiguriert werden, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Dienste zur Verfügung stellt, indem er ein „Authentication-as-a-Service“ („AaaS“) - Servicemodell implementiert, bei dem der Cloud-Dienst-Anbieter 302 Authentifizierungsdienste anbietet, die zur Sicherung des Zugriffs auf Anwendungen, Datenquellen oder andere Ressourcen verwendet werden können. Der Cloud-Dienst-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-Dienst-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-Dienst-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-Dienst-Anbieter 302 angeboten werden können, oder eine Beschränkung hinsichtlich der Servicemodelle, die vom Cloud-Dienst-Anbieter 302 implementiert werden können, darstellen.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Dienst-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-Dienst-Anbieter 302 als Private Cloud verkörpert ist, kann der Cloud-Dienst-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-Dienst-Anbieter 302 als Public Cloud verkörpert ist, kann der Cloud-Dienst-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 beheben 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-Dienst-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-Dienst-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-Dienst-Anbieter 302 erleichtern.
  • Damit das Speichersystem 306 und die Benutzer des Speichersystems 306 die vom Cloud-Dienst-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-Dienst-Anbieter 302 verschoben werden. Um Daten, Anwendungen oder andere Elemente erfolgreich in die Umgebung des Cloud-Dienst-Anbieters 302 zu migrieren, kann Middleware wie z. B. ein Cloud-Migrationstool verwendet werden, um Lücken zwischen der Umgebung des Cloud-Dienst-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-Dienst-Anbieter 302 verbunden sind, sowie Sicherheitsbedenken im Zusammenhang mit sensiblen Daten zum Cloud-Dienst-Anbieter 302 über Datenkommunikationsnetzwerke berücksichtigen. Um das Speichersystem 306 und die Benutzer des Speichersystems 306 in die Lage zu versetzen, die vom Cloud-Dienst-Anbieter 302 bereitgestellten Dienste zu nutzen, kann ein Cloud-Orchestrator auch zur Anordnung und Koordinierung automatisierter Aufgaben im Hinblick auf die Schaffung eines konsolidierten Prozesses oder Workflows eingesetzt werden. Ein solcher Cloud-Orchestrator kann Aufgaben wie die Konfiguration verschiedener Komponenten durchführen, unabhängig davon, ob es sich bei diesen Komponenten um Cloud-Komponenten oder Komponenten vor Ort handelt, sowie die Verwaltung der Verbindungen zwischen diesen Komponenten. Der Cloud-Orchestrator kann die Kommunikation und die Verbindungen zwischen den Komponenten vereinfachen, um sicherzustellen, dass die Verbindungen korrekt konfiguriert und gewartet werden.
  • In dem in 3A dargestellten Beispiel und wie oben kurz beschrieben, kann der Cloud-Dienst-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-Dienst-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-Dienst-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-Dienst-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.
  • 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 Field Programmable Gate Arrays („FPGAs“), ein oder mehrere Ein-Chip-Systeme („SoCs“) oder eine andere Form von Verarbeitungsressourcen 312 umfassen. Das Speichersystem 306 kann die Speicherressourcen 312 nutzen, um eine Vielzahl von Aufgaben auszuführen, einschließlich, aber nicht beschränkt auf die Unterstützung der Ausführung der Software-Ressourcen 314, die weiter unten ausführlicher beschrieben werden.
  • Das in 3B dargestellte Speichersystem 306 enthält auch die Software-Ressourcen 314, die bei der Ausführung durch die Verarbeitungsressourcen 312 innerhalb des Speichersystems 306 verschiedene Aufgaben ausführen können. Die Software-Ressourcen 314 können z.B. ein oder mehrere Module von Computerprogrammbefehlen enthalten, die, wenn sie von der Verarbeitungsressource 312 innerhalb des Speichersystems 306 ausgeführt werden, bei der Durchführung verschiedener Datensicherungsverfahren nützlich sind, um die Integrität der in den Speichersystemen gespeicherten Daten zu erhalten. Für den Leser ist zu erkennen, dass solche Datensicherungsverfahren z.B. durch Systemsoftware, die auf Computerhardware innerhalb des Speichersystems ausgeführt wird, durch einen Cloud-Dienst-Anbieter oder auf andere Weise durchgeführt werden können. Solche Datensicherungsverfahren können z.B. Datenarchivierungsverfahren umfassen, die dazu führen, dass Daten, die nicht mehr aktiv genutzt werden, auf ein separates Speichergerät oder ein separates Speichersystem zur langfristigen Aufbewahrung verschoben werden, Datensicherungsverfahren, durch das im Speichersystem gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um Datenverluste im Falle eines Geräteausfalls oder einer anderen Form der Katastrophe mit dem Speichersystem zu vermeiden, Datenreplizierungsverfahren, durch das im Speichersystem gespeicherte Daten auf ein anderes Speichersystem repliziert werden, so dass die Daten über mehrere Speichersysteme zugänglich sind, Daten-Snapshot-Verfahren, durch das der Zustand der Daten innerhalb des Speichersystems zu verschiedenen Zeitpunkten erfasst wird, Daten- und Datenbank-Cloning-Verfahren, durch welche Duplikate von Daten und Datenbanken erstellt werden können, und andere Datensicherungsverfahren. Durch den Einsatz solcher Datensicherungsverfahren können die Ziele der Business Continuity und der Disaster-Recovery-Ziele erreicht werden, da ein Ausfall des Speichersystems nicht zum Verlust der im Speichersystem gespeicherten Daten führen kann.
  • Die Software-Ressourcen 314 können auch Software enthalten, die bei der Implementierung von software-definierter Speicherung (‚SDS‘) nützlich ist. In einem solchen Beispiel können die Software-Ressourcen 314 ein oder mehrere Module von Computerprogrammbefehlen enthalten, die, wenn sie ausgeführt werden, bei der richtlinienbasierten Bereitstellung und Verwaltung von Datenspeicherung, die unabhängig von der zugrunde liegenden Hardware ist, nützlich sind. Solche Software-Ressourcen 314 können bei der Implementierung von Speichervirtualisierung nützlich sein, um die Speicherhardware von der Software zu trennen, welche die Speicherhardware verwaltet.
  • Die Software-Ressourcen 314 können auch Software enthalten, die zur Erleichterung und Optimierung von E/A-Operationen nützlich ist, die auf die Speicherressourcen 308 im Speichersystem 306 gerichtet sind. Die Software-Ressourcen 314 können beispielsweise Softwaremodule enthalten, die verschiedene Datenreduzierungsverfahren ausführen, wie z. B. Datenkomprimierung, Datendeduplizierung und andere. Die Software-Ressourcen 314 können Softwaremodule enthalten, die E/A-Operationen intelligent gruppieren, um eine bessere Nutzung der zugrunde liegenden Speicherressource 308 zu ermöglichen, Softwaremodule, die Datenmigrationsoperationen zur Migration von innerhalb eines Speichersystems durchführen, sowie Softwaremodule, die andere Funktionen ausführen. Solche Software-Ressourcen 314 können als ein oder mehrere Software-Container oder auf viele andere Arten verkörpert sein.
  • Für den Leser ist zu erkennen, dass 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.
  • 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, und viele andere. 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 Kl 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 GPU-beschleunigte 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.
  • Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme so konfiguriert werden können, dass sie die Speicherung 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.
  • 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 KI-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.
  • 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 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- Fingerprints abgeglichen werden, um Vorfälle in Echtzeit vorherzusagen und zu beheben, bevor sie sich auf Kundenumgebungen auswirken, und dass Hunderte von leistungsbezogenen Variablen erfasst werden, die zur Vorhersage der Leistungslast verwendet werden.
  • Zur weiteren Erläuterung ist in 4 ein Blockdiagramm dargestellt, das eine Vielzahl von Speichersystemen (402, 404, 406) veranschaulicht, die gemäß einigen Ausführungsformen der vorliegenden Offenbarung an einen Pod angeschlossen sind. Obwohl sie weniger detailliert dargestellt sind, können die in 4 dargestellten Speichersysteme (402, 404, 406) den vorstehend beschriebenen Speichersystemen unter Bezugnahme auf die 1A-1D, 2A-2G, 3A-3B oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 4 dargestellten Speichersysteme (402, 404, 406) die gleichen, weniger oder zusätzliche Komponenten enthalten wie die vorstehend beschriebenen Speichersysteme.
  • In dem in 4 dargestellten Beispiel ist jedes der Speichersysteme (402, 404, 406) so dargestellt, dass es mindestens einen Computerprozessor (408, 410, 412), einen Computer-Arbeitsspeicher (414, 416, 418) und einen Computer-Datenspeicher (420, 422, 424) aufweist. Obwohl in einigen Ausführungsformen der Computer-Arbeitsspeicher (414, 416, 418) und der Computer-Datenspeicher (420, 422, 424) Teil derselben Hardware-Vorrichtungen sein können, können in anderen Ausführungsformen der Computer-Arbeitsspeicher (414, 416, 418) und der Computer-Datenspeicher (420, 422, 424) Teil unterschiedlicher Hardware-Vorrichtungen sein. Die Unterscheidung zwischen dem Computer-Arbeitsspeicher (414, 416, 418) und dem Computer-Datenspeicher (420, 422, 424) kann in diesem speziellen Beispiel darin bestehen, dass der Computer-Arbeitsspeicher (414, 416, 418) physisch in der Nähe der Computerprozessoren (408, 410, 412) angeordnet ist und kann Computerprogrammbefehle speichern, die von den Computerprozessoren (408, 410, 412) ausgeführt werden, während der Computer-Datenspeicher (420, 422, 424) als nichtflüchtiger Speicher zur Speicherung von Benutzerdaten, Metadaten, die die Benutzerdaten beschreiben, usw. ausgeführt wird. Bezogen auf das obige Beispiel in 1A können sich beispielsweise die Computerprozessoren (408, 410, 412) und der Computer-Arbeitsspeicher (414, 416, 418) für ein bestimmtes Speichersystem (402, 404, 406) in einem von mehreren Controllern (110A-110D) befinden, während die angeschlossenen Speichergeräte (171A-171F) als Computer-Datenspeicher (420, 422, 424) in einem bestimmten Speichersystem (402, 404, 406) dienen können.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) an einem oder mehreren Pods (430, 432) gemäß einigen Ausführungsformen der vorliegenden Offenbarung befestigt sein. Jeder der in 4 dargestellten Pods (430, 432) kann einen Datensatz (426, 428) enthalten. Zum Beispiel enthält ein erster Pod (430), an den drei Speichersysteme (402, 404, 406) angeschlossen sind, einen ersten Datensatz (426), während ein zweiter Pod (432), an den zwei Speichersysteme (404, 406) angeschlossen sind, einen zweiten Datensatz (428) enthält. Wenn in einem solchen Beispiel ein bestimmtes Speichersystem an einen Pod angeschlossen wird, wird der Datensatz des Pods auf das bestimmte Speichersystem kopiert und dann bei Änderungen des Datensatzes auf dem neuesten Stand gehalten. Speichersysteme können aus einem Pod entfernt werden, was dazu führt, dass der Datensatz auf dem entfernten Speichersystem nicht mehr auf dem neuesten Stand gehalten wird. In dem in 4 dargestellten Beispiel kann jedes Speichersystem, das für einen Pod aktiv ist (es ist ein aktuelles, in Betrieb befindliches, nicht fehlerhaftes Element eines nicht fehlerhaften Pods), Anfragen zum Ändern oder zum Lesen des Datensatzes des Pods empfangen und verarbeiten.
  • In dem in 4 dargestellten Beispiel kann jeder Pod (430, 432) auch einen Satz von verwalteten Objekten und Betriebsoperationen sowie einen Satz von Zugriffsoperationen zum Ändern oder Lesen des Datensatzes (426, 428) enthalten, der dem jeweiligen Pod (430, 432) zugeordnet ist. In einem solchen Beispiel können die Betriebsoperationen verwaltete Objekte gleichwertig über eines der Speichersysteme modifizieren oder abfragen. Ebenso können die Zugriffsoperationen zum Lesen oder Ändern des Datensatzes äquivalent über eines der Speichersysteme erfolgen. Während in einem solchen Beispiel jedes Speichersystem eine separate Kopie des Datensatzes als ordnungsgemäße Teilmenge der gespeicherten und zur Verwendung durch das Speichersystem beworbenen Datensätze speichert, werden die Operationen zur Modifizierung gehandhabter Objekte oder des Datensatzes, die über ein beliebiges Speichersystem durchgeführt und abgeschlossen werden, in nachfolgenden Betriebsobjekten zum Abfragen des Pods oder in nachfolgenden Zugriffsoperationen zum Lesen des Datensatzes widergespiegelt.
  • Die Leser werden verstehen, dass Pods mehr Fähigkeiten implementieren können als nur einen geclusterten, synchron replizierten Datensatz. Beispielsweise können Pods zum Implementieren von Tenants verwendet werden, wobei die Datensätze in irgendeiner Weise sicher voneinander isoliert sind. Pods können auch verwendet werden, um virtuelle Arrays oder virtuelle Speichersysteme zu implementieren, bei denen jeder Pod als eine einzigartige Speichereinheit in einem Netzwerk (z.B. einem Storage Area Network oder einem Internet-Protokoll-Netzwerk) mit separaten Adressen dargestellt wird. Im Falle eines Multispeicher-System-Pods, der ein virtuelles Speichersystem implementiert, können sich alle physischen Speichersysteme, die mit dem Pod verbunden sind, in gewisser Weise als dasselbe Speichersystem darstellen (z.B. so, als ob die mehreren physischen Speichersysteme nicht anders als multiple Netzwerkanschlüsse in einem einzigen Speichersystem wären).
  • Die Leser werden verstehen, dass Pods auch Betriebseinheiten sein können, die eine Sammlung von Datenträgern, Dateisystemen, Objekt-/Analysespeichern, Snapshots und anderen administrativen Einheiten darstellen, bei denen die Durchführung administrativer Änderungen (z. B. Namensänderungen, Änderungen von Eigenschaften, Verwaltung von Exporten oder Berechtigungen für einen Teil des Datensatzes des Pods) auf einem beliebigen Speichersystem automatisch auf alle aktiven Speichersysteme gespiegelt wird, die mit dem Pod verbunden sind. Darüber hinaus könnten Pods auch Einheiten der Datenerfassung und Datenanalyse sein, in denen Leistungs- und Kapazitätsmetriken auf eine Weise dargestellt werden, die über alle aktiven Speichersysteme für den Pod aggregiert werden oder die Datenerfassung und -analyse für jeden Pod separat aufrufen, oder vielleicht den Beitrag jedes angeschlossenen Speichersystems zum eingehenden Inhalt und zur Leistung für jeden einzelnen Pod darstellen.
  • Ein Modell für die Pod-Zugehörigkeit kann definiert werden als eine Liste von Speichersystemen und eine Teilmenge dieser Liste, in welcher Speichersysteme als in-sync für den Pod angesehen werden. Ein Speichersystem kann für einen Pod als in-sync für einen Pod angesehen werden, wenn es zumindest innerhalb einer Wiederherstellungsphase identische inaktive Inhalte für die letzte schriftliche Kopie des mit dem Pod verbundenen Datensatzes aufweist. Idle-Inhalt ist der Inhalt, nachdem alle laufenden Änderungen abgeschlossen sind, ohne dass neue Änderungen verarbeitet wurden. Manchmal wird dies als „absturzwiederherstellbare“ Übereinstimmung bezeichnet. Bei der Wiederherstellung eines Pods wird der Prozess des Abgleichs von Unterschieden bei der Anwendung gleichzeitiger Aktualisierungen auf In-Sync Speichersysteme im Pod durchgeführt. Die Wiederherstellung kann alle Inkonsistenzen zwischen Speichersystemen bei der Durchführung gleichzeitiger Änderungen beheben, die bei verschiedenen Elementen des Pods angefordert wurden, die aber keinem Anforderer als erfolgreich abgeschlossen signalisiert wurden. Speichersysteme, die als Pod-Elemente aufgelistet sind, aber nicht als in-sync für den Pod aufgelistet sind, können als „abgetrennt“ vom Pod bezeichnet werden. Speichersysteme, die als Pod-Elemente aufgelistet sind, für den Pod in-sync sind und derzeit für die aktive Bereitstellung von Daten für den Pod zur Verfügung stehen, sind für den Pod „online“.
  • Jedes Speichersystem-Element eines Pods kann eine eigene Kopie der Zugehörigkeit aufweisen, einschließlich der Speichersysteme, von denen es zuletzt wusste, dass sie synchronisiert sind, und der Speichersysteme, von denen es zuletzt wusste, dass sie die gesamte Gruppe der Pod-Elemente umfassen. Um für einen Pod online zu sein, muss ein Speichersystem sich selbst als in-sync für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als in-sync für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es in-sync ist und mit allen anderen Speichersystemen kommuniziert, die in-sync sind, muss es die Verarbeitung neuer eingehender Anfragen für den Pod stoppen (oder sie mit einem Fehler oder einer Ausnahme abschließen), bis es sicher sein kann, dass es in-sync ist und mit allen anderen Speichersystemen kommuniziert, die in-sync sind. Ein erstes Speichersystem kann zu dem Schluss kommen, dass ein zweites gepaartes Speichersystem abgetrennt werden sollte, wodurch das erste Speichersystem weiterarbeiten kann, da es jetzt mit allen Speichersystemen in der Liste in-sync ist. Es muss jedoch verhindert werden, dass das zweite Speichersystem zu dem Schluss kommt, dass alternativ dazu das erste Speichersystem abgetrennt und das zweite Speichersystem weiter betrieben werden sollte. Dies würde zu einem „Split Brain“-Zustand führen, der unter anderem zu unvereinbaren Datensätzen, Datensatz- oder Anwendungskorruption führen kann.
  • Die Situation, dass bestimmt werden muss, wie vorzugehen ist, wenn keine Kommunikation mit gepaarten Speichersystemen stattfindet, kann entstehen, während ein Speichersystem normal läuft und dann einen Kommunikationsverlust bemerkt, während es sich gerade von einem früheren Fehler erholt, während es neu startet oder nach einem vorübergehenden Stromausfall oder einem wiederhergestellten Kommunikationsausfall wieder aufnimmt, während es Operationen von einem Satz Speichersystem-Controller auf einen anderen Satz - aus welchem Grund auch immer -umschaltet, oder während oder nach einer Kombination dieser oder anderer Arten von Ereignissen. Jedes Mal, wenn ein Speichersystem, das mit einem Pod verbunden ist, nicht mit allen bekannten, nicht abgekoppelten Elementen kommunizieren kann, kann das Speichersystem entweder kurz warten, bis die Kommunikation hergestellt werden kann, offline gehen und das Warten fortsetzen, oder es kann auf irgendeine Weise feststellen, dass es sicher ist, das nicht kommunizierende Speichersystem abzutrennen, ohne Gefahr zu laufen, einen „Split Brain“-Zustand aufgrund des nicht kommunizierenden Speichersystems zu riskieren, das die alternative Ansicht beendet, und dann weitermachen. Wenn eine sichere Abtrennung schnell genug erfolgen kann, kann das Speichersystem für den Pod mit kaum mehr als einer kurzen Verzögerung und ohne daraus resultierende Anwendungsausfälle für Anwendungen, die Anfragen an die verbleibenden Online-Speichersysteme stellen können, online bleiben.
  • Ein Beispiel für diese Situation ist, wenn ein Speichersystem möglicherweise weiß, dass es veraltet ist. Das kann zum Beispiel passieren, wenn ein erstes Speichersystem zum ersten Mal zu einem Pod hinzugefügt wird, der bereits mit einem oder mehreren Speichersystemen verbunden ist, oder wenn ein erstes Speichersystem sich wieder mit einem anderen Speichersystem verbindet und feststellt, dass das andere Speichersystem das erste Speichersystem bereits als abgetrennt markiert hatte. In diesem Fall wartet dieses erste Speichersystem einfach, bis es mit einem anderen Satz von Speichersystemen verbunden wird, die für den Pod synchronisiert sind.
  • Dieses Modell erfordert ein gewisses Maß an Überlegung, wie Speichersysteme zu den Pods oder aus der Liste der in-sync Pod-Elemente hinzugefügt oder entfernt werden. Da jedes Speichersystem seine eigene Kopie der Liste haben wird, und da zwei unabhängige Speichersysteme ihre lokale Kopie nicht genau zur gleichen Zeit aktualisieren können, und da die lokale Kopie alles ist, was bei einem Neustart oder in verschiedenen Fehlerszenarien verfügbar ist, muss darauf geachtet werden, dass vorübergehende Inkonsistenzen keine Probleme verursachen. Wenn z.B. ein Speichersystem für einen Pod in-sync ist und ein zweites Speichersystem hinzugefügt wird, dann könnte, wenn das zweite Speichersystem so aktualisiert wird, dass beide Speichersysteme zuerst als in-sync aufgelistet werden, bei einem Fehler und einem Neustart beider Speichersysteme das zweite hochfahren und auf die Verbindung mit dem ersten Speichersystem warten, während das erste möglicherweise nicht weiß, dass es auf das zweite Speichersystem warten soll oder könnte. Wenn das zweite Speichersystem dann auf eine Unfähigkeit, eine Verbindung mit dem ersten Speichersystem herzustellen, reagiert, indem es einen Prozess durchläuft, um es zu trennen, dann könnte es erfolgreich einen Prozess abschließen, der dem ersten Speichersystem nicht bekannt ist, was zu einem Split Brain führt. Daher muss möglicherweise sichergestellt werden, dass Speichersysteme sich nicht unangemessen uneinig darüber sind, ob sie sich dafür entscheiden könnten, einen Abtrennungsprozess zu durchlaufen, wenn sie nicht kommunizieren.
  • Eine Möglichkeit um sicherzustellen, dass Speichersysteme sich nicht unangemessen darüber uneinig sind, ob sie sich bei fehlender Kommunikation für eine Abtrennung entscheiden, besteht darin, sicherzustellen, dass beim Hinzufügen eines neuen Speichersystems zur In-Sync-Elemente-Liste für einen Pod das neue Speichersystem zunächst speichert, dass es ein abgetrenntes Element ist (und vielleicht auch, dass es als In-Sync-Element hinzugefügt wird). Dann können die vorhandenen In-Sync Speichersysteme lokal speichern, dass das neue Speichersystem ein In-Sync-Pod-Element ist, bevor das neue Speichersystem dieselbe Tatsache lokal speichert. Wenn es eine Reihe von Neustarts oder Netzwerkausfällen gibt, bevor das neue Speichersystem seinen In-Sync-Status speichert, können die ursprünglichen Speichersysteme das neue Speichersystem aufgrund der Nicht-Kommunikation trennen, aber das neue Speichersystem wartet. Eine umgekehrte Version dieser Änderung könnte zum Entfernen eines kommunizierenden Speichersystems aus einem Pod erforderlich sein: Zuerst speichert das entfernte Speichersystem, dass es nicht mehr in-sync ist, dann speichern die verbleibenden Speichersysteme, dass das entfernte Speichersystem nicht mehr in-sync ist, dann löschen alle Speichersysteme das entfernte Speichersystem aus ihren Pod-Zugehörigkeitslisten. Je nach Implementierung ist ein zwischenzeitlicher persistierender abgetrennter Zustand möglicherweise nicht erforderlich. Ob bei lokalen Kopien von Elemente-Listen Vorsicht geboten ist oder nicht, kann davon abhängen, welche Speichersysteme zur gegenseitigen Überwachung oder zur Validierung ihrer Zugehörigkeit verwendet werden. Wenn ein Konsensmodell für beides verwendet wird oder wenn ein externes System (oder ein externes verteiltes oder geclustertes System) zur Speicherung und Validierung der Pod-Zugehörigkeit verwendet wird, spielen Inkonsistenzen in lokal gespeicherten Elemente-Listen möglicherweise keine Rolle.
  • Wenn die Kommunikation fehlschlägt oder ein oder mehrere Speichersysteme in einem Pod ausfallen, oder wenn ein Speichersystem startet (oder auf einen sekundären Controller ausfällt) und nicht mit den gepaarten Speichersystemen für einen Pod kommunizieren kann, und es an der Zeit ist, dass ein oder mehrere Speichersysteme sich entscheiden, ein oder mehrere gepaarte Speichersysteme abzutrennen, muss ein Algorithmus oder Mechanismus verwendet werden, um zu entscheiden, dass dies sicher ist, und die Abtrennung zu Ende zu führen. Ein Mittel zur Lösung von Abtrennungen ist die Verwendung eines Mehrheits- (oder Quorum-) Modells für die Zugehörigkeit. Bei drei Speichersystemen können sie sich, solange zwei miteinander kommunizieren, darauf einigen, ein drittes Speichersystem abzutrennen, das nicht kommuniziert, aber dieses dritte Speichersystem kann sich nicht allein dafür entscheiden, eines der beiden anderen abzutrennen. Verwirrung kann entstehen, wenn die Kommunikation des Speichersystems inkonsistent ist. Beispielsweise könnte Speichersystem A mit Speichersystem B, aber nicht mit C kommunizieren, während Speichersystem B sowohl mit A als auch mit C kommuniziert. A und B könnten also C abkoppeln oder B und C könnten A abkoppeln, aber es könnte mehr Kommunikation zwischen den Pod-Elementen erforderlich sein, um dies herauszufinden.
  • Bei einem Quorum-Elemente-Modell ist beim Hinzufügen und Entfernen von Speichersystemen Vorsicht geboten. Wenn beispielsweise ein viertes Speichersystem hinzugefügt wird, dann ist die „Mehrheit“ der Speichersysteme an diesem Punkt drei. Der Übergang von drei Speichersystemen (wobei zwei für die Mehrheit erforderlich sind) zu einem Pod mit einem vierten Speichersystem (wobei drei für die Mehrheit erforderlich sind) erfordert möglicherweise etwas Ähnliches wie das zuvor beschriebene Modell für das sorgfältige Hinzufügen eines Speichersystems zur In-Sync-Liste. Zum Beispiel könnte das vierte Speichersystem in einem anhängenden, aber noch nicht angehängten Zustand beginnen, in dem es niemals zu einer Abstimmung über die Beschlussfähigkeit führen würde. Sobald es sich in diesem Zustand befindet, könnten die ursprünglichen drei Pod-Elemente jeweils aktualisiert werden, um das vierte Element und die neue Anforderung einer Mehrheit von drei Speichersystemen für die Abtrennung eines vierten Elements zu berücksichtigen. Das Entfernen eines Speichersystems von einem Pod könnte dieses Speichersystem in ähnlicher Weise in einen lokal gespeicherten „Abtrennungs“-Zustand versetzen, bevor andere Pod-Elemente aktualisiert werden. Ein Variantenschema hierfür ist die Verwendung eines verteilten Konsensmechanismus wie PAXOS oder RAFT zur Durchführung von Zugehörigkeitsänderungen oder zur Bearbeitung von Abtrennungsanträgen.
  • Ein weiteres Mittel zur Verwaltung von Zugehörigkeitsübergängen ist die Verwendung eines externen Systems, das sich außerhalb der Speichersysteme selbst befindet, um die Pod-Zugehörigkeit zu verwalten. Um für einen Pod online zu werden, muss ein Speichersystem zunächst das externe Pod-Zugehörigkeitssystem kontaktieren, um zu überprüfen, ob es für den Pod in-sync ist. Jedes Speichersystem, das für einen Pod online ist, sollte dann in Kommunikation mit dem Pod-Zugehörigkeitssystem bleiben und warten oder offline gehen, wenn es die Kommunikation verliert. Ein externer Pod-Zugehörigkeitsmanager könnte als hochverfügbarer Cluster unter Verwendung verschiedener Cluster-Tools implementiert werden, wie z.B. Oracle RAC, Linux HA, VERITAS Cluster Server, HACMP von IBM oder andere. Ein externer Pod-Zugehörigkeitsverwalter könnte auch verteilte Konfigurationswerkzeuge wie Etcd oder Zookeeper oder eine zuverlässige verteilte Datenbank wie die DynamoDB von Amazon verwenden.
  • In dem in 4 dargestellten Beispiel erhalten die dargestellten Speichersysteme (402, 404, 406) möglicherweise eine Anforderung zum Lesen eines Teils des Datensatzes (426, 428) und verarbeiten die Anforderung zum lokalen Lesen des Teils des Datensatzes gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Leser werden verstehen, dass, obwohl Anforderungen zum Ändern (z.B. eine Schreiboperation) des Datensatzes (426, 428) eine Koordination zwischen den Speichersystemen (402, 404, 406) in einem Pod erfordern, da der Datensatz (426, 428) über alle Speichersysteme (402, 404, 406) in einem Pod konsistent sein sollte, die Beantwortung einer Anforderung zum Lesen eines Teils des Datensatzes (426, 428) keine ähnliche Koordination zwischen den Speichersystemen (402, 404, 406) erfordert. Daher kann ein bestimmtes Speichersystem, das eine Leseanforderung empfängt, die Leseanforderung lokal bedienen, indem es einen Teil des Datensatzes (426, 428) liest, der in den Speichergeräten des Speichersystems gespeichert ist, ohne dass eine synchrone Kommunikation mit anderen Speichersystemen in dem Pod stattfindet. Es wird erwartet, dass Leseanforderungen, die von einem Speichersystem für einen replizierten Datensatz in einem replizierten Cluster empfangen werden, in den allermeisten Fällen jegliche Kommunikation vermeiden, zumindest wenn sie von einem Speichersystem empfangen werden, das innerhalb eines Clusters läuft, der auch nominell läuft. Solche Lesevorgänge sollten normalerweise einfach durch Lesen aus der lokalen Kopie eines geclusterten Datensatzes verarbeitet werden, ohne dass eine weitere Interaktion mit anderen Speichersystemen im Cluster erforderlich ist.
  • Die Leser werden verstehen, dass die Speichersysteme Maßnahmen zur Sicherstellung der Lesekonsistenz ergreifen können, so dass eine Leseanforderung unabhängig davon, welches Speichersystem die Leseanforderung verarbeitet, das gleiche Ergebnis liefert. Beispielsweise sollte der resultierende geclusterte Datensatzinhalt für jeden Satz von Aktualisierungen, die von jedem beliebigen Satz von Speichersystemen im Cluster empfangen werden, im gesamten Cluster konsistent sein, zumindest zu jeder Zeit, wenn Aktualisierungen nicht ausgeführt werden (alle früheren Änderungsoperationen wurden als abgeschlossen angezeigt, und es wurden keine neuen Aktualisierungsanforderungen empfangen und in irgendeiner Weise verarbeitet). Genauer gesagt können sich die Instanzen eines geclusterten Datensatzes über einen Satz von Speichersystemen hinweg nur aufgrund von Aktualisierungen unterscheiden, die noch nicht abgeschlossen sind. Das bedeutet zum Beispiel, dass zwei Schreibanforderungen, die sich in ihrem Datenträgerblockbereich überlappen, oder eine Kombination aus einer Schreibanforderung und einem überlappenden Snapshot, Vergleichen und Schreiben oder einer Kopie des virtuellen Blockbereichs ein konsistentes Ergebnis auf allen Kopien des Datenbestands liefern müssen. Zwei Operationen sollten nicht zu einem Ergebnis führen, als ob sie in einer Reihenfolge auf einem Speichersystem und in einer anderen Reihenfolge auf einem anderen Speichersystem im replizierten Cluster stattfinden würden.
  • Darüber hinaus können Leseanfragen in zeitlicher Reihenfolge konsistent gemacht werden. Zum Beispiel, wenn eine Leseanforderung auf einem replizierten Cluster empfangen und abgeschlossen wird und auf diese Leseanforderung dann eine weitere Leseanforderung an einen überlappenden Adressbereich folgt, die vom replizierten Cluster empfangen wird und bei der sich eine oder beide Leseanforderungen in irgendeiner Weise in Zeit und Datenträgeradressbereich mit einer Änderungsanforderung überlappen, die vom replizierten Cluster empfangen wird (unabhängig davon, ob eine der Leseanforderungen oder die Änderung vom selben Speichersystem oder einem anderen Speichersystem im replizierten Cluster empfangen wird), dann sollte, wenn die erste Ablesung das Ergebnis der Aktualisierung widerspiegelt, die zweite Ablesung ebenfalls die Ergebnisse dieser Aktualisierung widerspiegeln, anstatt möglicherweise Daten zurückzugeben, die der Aktualisierung vorausgingen. Wenn die erste Ablesung nicht die Aktualisierung widerspiegelt, dann kann die zweite Ablesung entweder die Aktualisierung widerspiegeln oder nicht. Dadurch wird sichergestellt, dass zwischen zwei Leseanforderungen die „Zeit“ für ein Datensegment nicht rückwärts drehen kann.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme erkennen, und sie können bestimmen, ob das jeweilige Speichersystem in dem Pod verbleiben soll. Eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme kann aus einer Vielzahl von Gründen auftreten. Zum Beispiel kann eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme auftreten, weil eines der Speichersysteme ausgefallen ist, weil eine Netzverbindung ausgefallen ist oder aus einem anderen Grund. Ein wichtiger Aspekt des synchronen replizierten Clustering ist die Sicherstellung, dass eine Fehlerbehandlung nicht zu nicht behebbaren Inkonsistenzen oder inkonsistenten Antworten führt. Wenn beispielsweise ein Netzwerk zwischen zwei Speichersystemen ausfällt, kann höchstens eines der Speichersysteme die Verarbeitung neu eingehender E/A-Anforderungen für einen Pod fortsetzen. Und wenn ein Speichersystem die Verarbeitung fortsetzt, kann das andere Speichersystem keine neuen Anforderungen, einschließlich Leseanforderungen, bis zum Abschluss verarbeiten.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch bestimmen, ob das bestimmte Speichersystem als Reaktion auf das Erkennen einer Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme in dem Pod verbleiben soll. Wie oben erwähnt, muss ein Speichersystem, um als Teil eines Pods „online“ zu sein, sich selbst als in-sync für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als in-sync für den Pod betrachten. Wenn ein Speichersystem nicht sicher sein kann, dass es in-sync ist und mit allen anderen Speichersystemen, die in-sync sind, kommuniziert, dann kann es die Verarbeitung neuer eingehender Anfragen für den Zugriff auf den Datensatz (426, 428) stoppen. So kann das Speichersystem z.B. bestimmen, ob das bestimmte Speichersystem als Teil des Pods online bleiben soll, indem es feststellt, ob es mit allen anderen Speichersystemen kommunizieren kann, die es für den Pod als in-sync betrachtet (z.B. über eine oder mehrere Testnachrichten), indem bestimmt wird, ob alle anderen Speichersysteme, die es für den Pod als in-sync für den Pod erachtet, auch das Speichersystem als mit dem Pod verbunden betrachten, durch eine Kombination beider Schritte, wobei das bestimmte Speichersystem bestätigen muss, dass es mit allen anderen Speichersystemen kommunizieren kann, die es für den Pod als in-sync für den Pod erachtet, und dass alle anderen Speichersysteme, die es für den Pod als in-sync für den Pod erachtet, auch das Speichersystem als mit dem Pod verbunden betrachten, oder durch einen anderen Mechanismus.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch den Datensatz auf dem bestimmten Speichersystem für Betriebs- und Datensatzoperationen zugänglich halten, wenn bestimmt wird, dass das bestimmte Speichersystem in dem Pod verbleiben soll. Das Speichersystem kann den Datensatz (426, 428) auf dem bestimmten Speichersystem für Betriebs- und Datensatzoperationen zugänglich halten, z.B. durch die Annahme von Anfragen zum Zugriff auf die Version des Datensatzes (426, 428), die auf dem Speichersystem gespeichert ist, und die Bearbeitung solcher Anfragen, durch Annahme und Verarbeitung von Betriebsoperationen im Zusammenhang mit dem Datensatz (426, 428), die von einem Host oder autorisierten Administrator ausgegeben werden, durch Annahme und Verarbeitung von Betriebsoperationen im Zusammenhang mit dem Datensatz (426, 428), die von einem der anderen Speichersysteme ausgegeben werden, oder auf andere Weise.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) jedoch dazu führen, dass der Datensatz auf dem bestimmten Speichersystem für Betriebs- und Datensatzoperationen unzugänglich wird, wenn bestimmt wird, dass das bestimmte Speichersystem nicht im Pod verbleiben soll. Das Speichersystem kann den Datensatz (426, 428) auf dem bestimmten Speichersystem für Betriebs- und Datensatz-Operationen unzugänglich machen, z.B. durch Ablehnung von Anträgen auf Zugriff auf die Version des Datensatzes (426, 428), die auf dem Speichersystem gespeichert ist, durch Ablehnen von Betriebsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem Host oder einem anderen autorisierten Administrator ausgegeben werden, durch Ablehnen von Betriebsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem der anderen Speichersysteme im Pod oder auf andere Weise ausgegeben werden.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch erkennen, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme repariert wurde, und den Datensatz auf dem jeweiligen Speichersystem für Betriebs- und Datensatzoperationen zugänglich machen. Das Speichersystem kann erkennen, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme repariert wurde, z.B. durch Empfang einer Nachricht von dem einen oder mehreren der anderen Speichersysteme. Als Reaktion auf die Feststellung, dass die Unterbrechung in der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme repariert wurde, kann das Speichersystem den Datensatz (426, 428) auf dem bestimmten Speichersystem für Betriebs- und Datensatzoperationen zugänglich machen, sobald das zuvor abgetrennte Speichersystem mit den Speichersystemen, die mit dem Pod verbunden blieben, wieder synchronisiert wurde.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch vom Pod offline gehen, so dass das jeweilige Speichersystem keine Betriebs- und Datensatzvorgänge mehr zulässt. Die abgebildeten Speichersysteme (402, 404, 406) können vom Pod offline gehen, so dass das jeweilige Speichersystem aus verschiedenen Gründen keine Betriebs- und Datensatzoperationen mehr zulässt. Zum Beispiel können die abgebildeten Speichersysteme (402, 404, 406) auch wegen eines Fehlers im Speichersystem selbst, wegen einer Aktualisierung oder einer anderen Wartung des Speichersystems, wegen Kommunikationsfehlern oder aus vielen anderen Gründen vom Pod offline gehen. In einem solchen Beispiel können die dargestellten Speichersysteme (402, 404, 406) anschließend den Datensatz auf dem bestimmten Speichersystem aktualisieren, um alle Aktualisierungen des Datensatzes seit der Offline-Stellung des bestimmten Speichersystems einzubeziehen, und mit dem Pod wieder online gehen, so dass das bestimmte Speichersystem Betriebs- und Datensatzoperationen ermöglicht, wie in den unten aufgeführten Abschnitten zur Resynchronisierung ausführlicher beschrieben wird.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch ein Zielspeichersystem für den asynchronen Empfang des Datensatzes identifizieren, wobei das Zielspeichersystem nicht zu den mehreren Speichersystemen gehört, über die der Datensatz synchron repliziert wird. Ein solches Zielspeichersystem kann z.B. ein Backup-Speichersystem darstellen, als ein Speichersystem, das den synchron replizierten Datensatz verwendet, und so weiter. Tatsächlich kann die synchrone Replikation genutzt werden, um Kopien eines Datensatzes näher an irgendein Server-Rack zu verteilen, um eine bessere lokale Leseleistung zu erzielen. Ein solcher Fall sind kleinere Top-of-Rack-Speichersysteme, die symmetrisch auf größere Speichersysteme repliziert werden, die sich zentral im Rechenzentrum oder auf dem Campus befinden und bei denen diese größeren Speichersysteme im Hinblick auf ihre Zuverlässigkeit sorgfältiger verwaltet werden oder für asynchrone Replikations- oder Sicherungsdienste an externe Netzwerke angeschlossen sind.
  • In dem in 4 dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch einen Teil des Datensatzes identifizieren, der nicht asynchron durch eines der anderen Speichersysteme auf das Zielspeichersystem repliziert wird, und den Teil des Datensatzes, der nicht asynchron durch eines der anderen Speichersysteme auf das Zielspeichersystem repliziert wird, asynchron auf das Zielspeichersystem replizieren, wobei die zwei oder mehr Speichersysteme gemeinsam den gesamten Datensatz auf das Zielspeichersystem replizieren. Auf diese Weise kann die Arbeit, die mit der asynchronen Replikation eines bestimmten Datensatzes verbunden ist, unter den Elementen eines Pods aufgeteilt werden, so dass jedes Speichersystem in einem Pod nur für die asynchrone Replikation einer Teilmenge eines Datensatzes in das Zielspeichersystem verantwortlich ist.
  • In dem in 4 dargestellten Beispiel können sich die dargestellten Speichersysteme (402, 404, 406) auch vom Pod lösen, so dass das bestimmte Speichersystem, das sich vom Pod löst, nicht mehr in dem Satz von Speichersystemen enthalten ist, über den der Datensatz synchron repliziert wird. Wenn sich beispielsweise das Speichersystem (404) in 4 von dem in 4 dargestellten Pod (430) löst, würde der Pod (430) nur noch Speichersysteme (402, 406) als die Speichersysteme enthalten, über die der im Pod (430) enthaltene Datensatz (426) synchron repliziert würde. In einem solchen Beispiel könnte das Lösen des Speichersystems vom Pod auch das Entfernen des Datensatzes aus dem bestimmten Speichersystem umfassen, das sich vom Pod gelöst hat. Um mit dem Beispiel fortzufahren, bei dem sich das Speichersystem (404) in 4 von dem in 4 dargestellten Pod (430) gelöst hat, könnte der Datensatz (426), der in dem Pod (430) enthalten ist, gelöscht oder anderweitig aus dem Speichersystem (404) entfernt werden.
  • Die Leser werden verstehen, dass das Pod-Modell eine Reihe einzigartiger Betriebsfunktionen ermöglicht, die weiter unterstützt werden können. Außerdem führt das Pod-Modell selbst einige Probleme ein, die durch eine Implementierung gelöst werden können. Wenn z.B. ein Speichersystem für einen Pod offline ist, aber anderweitig läuft, z.B. weil eine Verbindung fehlgeschlagen ist und ein anderes Speichersystem für den Pod bei der Vermittlung gewonnen hat, kann es immer noch den Wunsch oder die Notwendigkeit geben, auf den Datensatz des Offline-Pods auf dem Offline-Speichersystem zuzugreifen. Eine Lösung könnte einfach darin bestehen, den Pod in einem abgetrennten Modus zu aktivieren und den Zugriff auf den Datensatz zu ermöglichen. Diese Lösung kann jedoch gefährlich sein, und sie kann dazu führen, dass die Metadaten und Daten des Pods sehr viel schwieriger abzugleichen sind, wenn die Speichersysteme wieder miteinander kommunizieren. Darüber hinaus könnte es immer noch einen separaten Pfad für Hosts geben, um sowohl auf das Offline-Speichersystem als auch auf die noch online befindlichen Speichersysteme zuzugreifen. In diesem Fall könnte ein Host E/A an beide Speichersysteme ausgeben, obwohl sie nicht mehr synchron gehalten werden, weil der Host Ziel-Ports sieht, welche Datenträger mit denselben Identifikatoren melden, und die E/A-Treiber des Hosts davon ausgehen, dass er zusätzliche Pfade zu demselben Datenträger sieht. Dies kann zu einer ziemlich schädlichen Datenbeschädigung führen, da Lese- und Schreibvorgänge, die an beide Speichersysteme ausgegeben werden, nicht mehr konsistent sind, obwohl der Host davon ausgeht, dass sie es sind. Als Variante dieses Falls könnte in einer Cluster-Anwendung, wie z.B. einer Cluster-Datenbank mit gemeinsamem Speicher, die Cluster-Anwendung, die auf einem Host läuft, auf einem Speichersystem lesen oder schreiben, und die gleiche Cluster-Anwendung, die auf einem anderen Host läuft, auf dem „abgesetzten“ Speichersystem lesen oder schreiben, und dennoch kommunizieren die beiden Instanzen der Cluster-Anwendung miteinander unter der Annahme, dass der Datensatz, den sie jeweils sehen, für abgeschlossene Schreibvorgänge vollständig konsistent ist. Da sie nicht konsistent sind, wird diese Annahme widerlegt, und der Datensatz der Anwendung (z.B. die Datenbank) kann schnell korrumpiert werden.
  • Eine Möglichkeit, diese beiden Probleme zu beheben, besteht darin, einen Offline-Pod oder vielleicht einen Snapshot eines Offline-Pods auf einen neuen Pod mit neuen Datenträgern zu kopieren, die über ausreichend neue Identitäten verfügen, so dass E/A-Treiber und geclusterte Anwendungen die kopierten Datenträger nicht mit den noch online befindlichen Datenträgern auf einem anderen Speichersystem verwechseln. Da jeder Pod eine vollständige Kopie des Datensatzes enthält, die zwar absturzkonsistent ist, sich aber vielleicht geringfügig von der Kopie des Pod-Datensatzes auf einem anderen Speichersystem unterscheidet, und da jeder Pod über eine unabhängige Kopie aller Daten und Metadaten verfügt, die für den Betrieb des Pod-Inhalts erforderlich sind, ist es ein unkompliziertes Problem, eine virtuelle Kopie einiger oder aller Datenträger oder Snapshots im Pod auf neue Datenträger in einem neuen Pod zu erstellen. Bei einer Implementierung eines Graphen mit logischen Erweiterungsgraphen genügt es beispielsweise, neue Datenträger in einem neuen Pod zu definieren, die auf Graphen mit logischen Erweiterungsgraphen aus dem kopierten Pod verweisen, die mit den Datenträgern oder Snapshots des Pods verknüpft sind, wobei die Graphen mit logischen Erweiterungsgraphen als Kopie beim Schreiben markiert werden. Die neuen Datenträger sollten als neue Datenträger behandelt werden, ähnlich wie Datenträger-Snapshots, die auf einen neuen Datenträger kopiert werden, implementiert werden könnten. Die Datenträger können denselben administrativen Namen aufweisen, allerdings innerhalb eines neuen Pod-Namensraums. Sie sollten jedoch andere zugrundeliegende Kennungen und andere Kennungen logischer Einheiten als der ursprüngliche Datenträger aufweisen.
  • In einigen Fällen kann es möglich sein, virtuelle Netzwerk-Isolationstechniken (z.B. durch Schaffung eines virtuellen LAN im Falle von IP-Netzwerken oder eines virtuellen SAN im Falle von Glasfaserkanalnetzwerken) so zu verwenden, dass die Isolation von Datenträgern, die einigen Schnittstellen präsentiert werden, von Host-Netzwerk-Schnittstellen oder Host-SCSI-Initiator-Ports, die auch die Originaldatenträger sehen könnten, nicht zugänglich ist. In solchen Fällen kann es sicher sein, die Kopien von Datenträgern mit den gleichen SCSI- oder anderen Speicherkennungen wie die Originaldatenträger zu versehen. Dies könnte z.B. in Fällen verwendet werden, in denen die Anwendungen erwarten, einen bestimmten Satz von Speicher-Identifikatoren zu sehen, damit sie ohne übermäßigen Aufwand bei der Re-Konfiguration funktionieren.
  • Einige der hier beschriebenen Techniken könnten auch außerhalb eines aktiven Fehlerkontextes eingesetzt werden, um die Bereitschaft zur Fehlerbehandlung zu testen. Bereitschaftsprüfungen (manchmal auch als „Fire Drills“ bezeichnet) sind häufig für Disaster-Recovery-Konfigurationen erforderlich, bei denen häufige und wiederholte Tests als notwendig erachtet werden, um sicherzustellen, dass die meisten oder alle Aspekte eines Disaster-Recovery-Plans korrekt sind und alle kürzlichen Änderungen an Anwendungen, Datensätzen oder Geräte-Änderungen berücksichtigen. Bereitschaftsprüfungen sollten den laufenden Produktionsbetrieb, einschließlich der Replikation, nicht stören. In vielen Fällen kann der reale Betrieb in der aktiven Konfiguration nicht wirklich aufgerufen werden, aber eine gute Möglichkeit, sich dem zu nähern, besteht darin, mit Hilfe von Speicheroperationen Kopien von Produktionsdatensätzen zu erstellen und dies dann vielleicht mit dem Einsatz eines virtuellen Netzwerks zu verbinden, um eine isolierte Umgebung zu schaffen, die alle Daten enthält, die für die wichtigen Anwendungen, die im Katastrophenfall erfolgreich hochgefahren werden müssen, für notwendig erachtet werden. Das Verfügbarmachen einer solchen Kopie eines synchron replizierten (oder sogar asynchron replizierten) Datensatzes innerhalb eines Standorts (oder einer Sammlung von Standorten), von dem erwartet wird, dass er ein Testverfahren für die Disaster-Recovery-Bereitschaft durchführt, und das anschließende Starten der wichtigen Anwendungen auf diesem Datensatz, um sicherzustellen, dass er starten und funktionieren kann, ist ein großartiges Werkzeug, da es dazu beiträgt sicherzustellen, dass keine wichtigen Teile der Anwendungsdatensätze im Disaster-Recovery-Plan ausgelassen wurden. Falls erforderlich und praktisch durchführbar, könnte dies mit virtuellen isolierten Netzwerken gekoppelt werden, die vielleicht mit einer isolierten Sammlung physischer oder virtueller Maschinen gekoppelt sind, um einem realen Disaster-Recovery-Übernahme-Szenario so nahe wie möglich zu kommen. Durch virtuelles Kopieren eines Pods (oder eines Satzes von Pods) auf einen anderen Pod als Point-in-Time-Image der Pod-Datensätze wird sofort ein isolierter Datensatz erstellt, der alle kopierten Elemente enthält und der dann im Wesentlichen identisch mit den ursprünglichen Pods betrieben werden kann, wobei das Isolieren auf einen einzelnen Standort (oder einige wenige Standorte) getrennt vom ursprünglichen Pod möglich ist. Darüber hinaus handelt es sich hierbei um schnelle Operationen, die abgebrochen und leicht wiederholt werden können, so dass die Tests beliebig oft wiederholt werden können.
  • Einige Verbesserungen könnten vorgenommen werden, um auf dem Weg zu perfekten Disaster-Recovery-Tests weiter voranzukommen. Beispielsweise könnten in Verbindung mit isolierten Netzwerken Identitäten von logischen SCSI-Einheiten oder andere Arten von Identitäten in den Ziel-Pod kopiert werden, so dass die Testserver, virtuellen Maschinen und Anwendungen die gleichen Identitäten sehen. Darüber hinaus könnte die administrative Umgebung der Server so konfiguriert werden, dass sie auf Anfragen von einem bestimmten virtuellen Satz virtueller Netzwerke reagiert, um auf Anfragen und Operationen auf dem ursprünglichen Pod-Namen zu reagieren, so dass Skripte nicht die Verwendung von Testvarianten mit alternativen „Test“-Versionen von Objektnamen erfordern. Eine weitere Verbesserung kann in Fällen eingesetzt werden, in denen die Server-Infrastruktur auf der Host-Seite, die im Falle einer Übernahme im Katastrophenfall übernommen wird, während eines Tests verwendet werden kann. Dies schließt Fälle ein, in denen ein Disaster-Recovery-Rechenzentrum vollständig mit einer alternativen Server-Infrastruktur ausgestattet ist, die in der Regel erst auf Anweisung einer Katastrophe zum Einsatz kommt. Dazu gehören auch Fälle, in denen diese Infrastruktur für nicht-kritische Operationen verwendet werden könnte (z.B. für die Durchführung von Analysen von Produktionsdaten oder einfach zur Unterstützung der Anwendungsentwicklung oder anderer Funktionen, die zwar wichtig sein können, aber bei Bedarf für kritischere Funktionen angehalten werden können). Konkret können Host-Definitionen und -Konfigurationen und die Server-Infrastruktur, die sie verwenden wird, so eingerichtet werden, wie sie für ein tatsächliches Disaster-Recovery-Übernahmeereignis vorgesehen sind, und im Rahmen von Disaster-Recovery-Übernahmetests getestet werden, wobei die getesteten Datenträger von der virtuellen Pod-Kopie, die zur Erstellung eines Snapshots des Datensatzes verwendet wird, mit diesen Host-Definitionen verbunden werden. Aus der Sicht der beteiligten Speichersysteme können diese Host-Definitionen und - Konfigurationen, die zum Testen verwendet werden, sowie die Volume-zu-Host-Verbindungskonfigurationen, die während des Testens verwendet werden, wiederverwendet werden, wenn ein tatsächliches Disaster-Recovery-Übernahmeereignis ausgelöst wird, wodurch die Konfigurationsunterschiede zwischen der Testkonfiguration und der realen Konfiguration, die im Falle einer Disaster-Recovery-Übernahme verwendet wird, stark minimiert werden.
  • In einigen Fällen kann es sinnvoll sein, Datenträger aus einem ersten Pod in einen neuen zweiten Pod zu verschieben, der genau diese Datenträger enthält. Die Pod-Zugehörigkeit und die Hochverfügbarkeits- und Wiederherstellungsmerkmale können dann getrennt eingestellt werden, und die Verwaltung der beiden resultierenden Pod-Datensätze kann dann voneinander isoliert werden. Eine Operation, die in einer Richtung durchgeführt werden kann, sollte auch in der anderen Richtung möglich sein. Irgendwann kann es sinnvoll sein, zwei Pods zu einem zusammenzuführen, so dass die Volumina in jedem der beiden ursprünglichen Pods sich nun hinsichtlich der Zugehörigkeit im Speichersystem und der Hochverfügbarkeits- und Wiederherstellungsmerkmale und -ereignisse gegenseitig verfolgen. Beide Vorgänge können sicher und mit relativ minimaler oder keiner Unterbrechung der laufenden Anwendungen durchgeführt werden, wenn man sich auf die Merkmale verlässt, die für die Änderung der Vermittler- oder Quorum-Eigenschaften für einen Pod vorgeschlagen wurden und die in einem früheren Abschnitt diskutiert wurden. Bei der Vermittlung kann z.B. ein Vermittler für einen Pod durch eine Sequenz geändert werden, die aus einem Schritt besteht, bei dem jedes Speichersystem in einem Pod so geändert wird, dass es sowohl von einem ersten als auch von einem zweiten Vermittler abhängt, und dann jeweils so geändert wird, dass es nur vom zweiten Vermittler abhängt. Wenn ein Fehler in der Mitte der Sequenz auftritt, können einige Speichersysteme sowohl vom ersten als auch vom zweiten Vermittler abhängig sein, aber in keinem Fall werden die Wiederherstellung und Fehlerbehandlung dazu führen, dass einige Speichersysteme nur vom ersten Vermittler und andere Speichersysteme nur vom zweiten Vermittler abhängig sind. Das Quorum kann ähnlich gehandhabt werden, indem es vorübergehend davon abhängig gemacht wird, dass man sowohl gegen ein erstes als auch gegen ein zweites Quorum-Modell gewinnt, um zur Wiederherstellung überzugehen. Dies kann zu einem sehr kurzen Zeitraum führen, in dem die Verfügbarkeit des Pods bei Störungen von zusätzlichen Ressourcen abhängt, wodurch die potenzielle Verfügbarkeit verringert wird. Wenn bei der Vermittlung die Änderung der Parameter des Vermittlers nichts anderes als die Änderung des für die Vermittlung verwendeten Schlüssels ist und der verwendete Vermittlerdienst derselbe ist, dann ist die potenzielle Verringerung der Verfügbarkeit noch geringer, da sie jetzt nur noch von zwei Anrufen bei demselben Dienst gegenüber einem Anruf bei diesem Dienst abhängt und nicht mehr von getrennten Anrufen bei zwei verschiedenen Diensten.
  • Die Leser werden feststellen, dass die Änderung des Quorum-Modells recht komplex sein kann. Ein zusätzlicher Schritt kann erforderlich sein, wenn Speichersysteme am zweiten Quorum-Modell teilnehmen, aber nicht davon abhängen, ob sie in diesem zweiten Quorum-Modell gewinnen, worauf dann der Schritt folgt, auch vom zweiten Quorum-Modell abhängig zu sein. Dies kann notwendig sein, um der Tatsache Rechnung zu tragen, dass, wenn nur ein System die Änderung verarbeitet hat, um vom Quorum-Modell abhängig zu sein, es niemals das Quorum gewinnen wird, da es niemals eine Mehrheit geben wird. Mit diesem Modell zur Änderung der Hochverfügbarkeitsparameter (Vermittlerbeziehung, Quorum-Modell, Übernahmepräferenzen) können wir ein sicheres Verfahren für diese Operationen schaffen, um einen Pod in zwei zu teilen oder zwei Pods zu einem zusammenzufügen. Dazu kann es erforderlich sein, eine weitere Fähigkeit hinzuzufügen: die Verbindung eines zweiten Pods mit einem ersten Pod für Hochverfügbarkeit, so dass, wenn zwei Pods kompatible Hochverfügbarkeitsparameter enthalten, der zweite Pod, der mit dem ersten Pod verbunden ist, von dem ersten Pod abhängen kann, um abtrennungsbezogene Verarbeitungen und Operationen, Offline- und In-Sync-Zustände sowie Wiederherstellungs- und Resynchronisierungsaktionen zu bestimmen und einzuleiten.
  • Um einen Pod in zwei zu teilen, was eine Operation zum Verschieben einiger Datenträger in einen neu erstellten Pod bedeutet, kann eine verteilte Operation gebildet werden, die wie folgt beschrieben werden kann: Bilden eines zweiten Pods, in den wir einen Satz von Datenträgern verschieben werden, die zuvor in einem ersten Pod waren, Kopieren der Hochverfügbarkeitsparameter aus dem ersten Pod in den zweiten Pod, um sicherzustellen, dass sie für die Verknüpfung kompatibel sind, und Verknüpfen des zweiten Pods mit dem ersten Pod für eine hohe Verfügbarkeit. Dieser Vorgang kann in Form von Nachrichten kodiert werden und sollte von jedem Speichersystem im Pod so implementiert werden, dass das Speichersystem sicherstellt, dass der Vorgang vollständig auf diesem Speichersystem stattfindet oder überhaupt nicht stattfindet, wenn die Verarbeitung durch einen Fehler unterbrochen wird. Sobald alle In-Sync-Speichersysteme für die beiden Pods diesen Vorgang verarbeitet haben, können die Speichersysteme dann einen Folgevorgang verarbeiten, der den zweiten Pod so verändert, dass er nicht mehr mit dem ersten Pod verbunden ist. Wie bei anderen Änderungen an den Hochverfügbarkeitsmerkmalen für eine Pod bedeutet dies, dass zunächst jedes In-Sync-Speichersystem so geändert werden muss, dass es sich sowohl auf das vorherige Modell (wobei dieses Modell darin besteht, dass die Hochverfügbarkeit mit dem ersten Pod verbunden ist) als auch auf das neue Modell (wobei dieses Modell sein eigenes, jetzt unabhängiges Hochverfügbarkeitsmodell ist) stützt. Im Falle von Vermittlung oder Quorum bedeutet dies, dass die Speichersysteme, die diese Änderung verarbeitet haben, zunächst davon abhängen, ob die Vermittlung oder das Quorum für den ersten Pod erreicht wird, und zusätzlich davon, ob eine neue separate Vermittlung (z.B. ein neuer Vermittlerschlüssel) oder das Quorum für den zweiten Pod erreicht wird, bevor der zweite Pod nach einem Fehler, der eine Vermittlung oder Prüfung auf Quorum erforderte, fortgesetzt werden kann. Wie bei der vorhergehenden Beschreibung von sich ändernden Quorum-Modellen kann ein Zwischenschritt Speichersysteme so einstellen, dass sie am Quorum für den zweiten Pod teilnehmen, und zwar vor dem Schritt, bei dem Speichersysteme am Quorum für den zweiten Pod teilnehmen und vom Quorum für den zweiten Pod abhängen. Sobald alle In-Sync-Speichersysteme die Änderung in Abhängigkeit von den neuen Parametern für die Vermittlung oder das Quorum sowohl für den ersten Pod als auch für den zweiten Pod verarbeitet haben, ist die Aufteilung abgeschlossen.
  • Das Zusammenfügen eines zweiten Pods mit einem ersten Pod funktioniert im Wesentlichen umgekehrt. Zunächst muss der zweite Pod so angepasst werden, dass er mit dem ersten Pod kompatibel ist, indem eine identische Liste von Speichersystemen und ein kompatibles Hochverfügbarkeitsmodell verwendet werden. Dies kann eine Reihe von Schritten erfordern, wie sie an anderer Stelle in diesem Papier beschrieben werden, um Speichersysteme hinzuzufügen oder zu entfernen oder um Vermittler- und Quorum-Modelle zu ändern. Je nach Implementierung kann es notwendig sein, nur eine identische Liste von Speichersystemen zu erzielen. Das Zusammenfügen erfolgt durch die Verarbeitung eines Vorgangs auf jedem In-Sync-Speichersystem, um den zweiten Pod mit dem ersten Pod für eine hohe Verfügbarkeit zu verbinden. Jedes Speichersystem, das diesen Vorgang verarbeitet, hängt dann für die Hochverfügbarkeit von den ersten und dann für die Hochverfügbarkeit von den zweiten Pods ab. Sobald alle In-Sync-Speichersysteme für den zweite Pod diesen Vorgang verarbeitet haben, verarbeitet jedes Speichersystem einen nachfolgenden Vorgang, um die Verbindung zwischen dem zweiten Pod und dem ersten Pod zu beseitigen, die Datenträger von dem zweiten Pod in den ersten Pod zu migrieren und den zweite Pod zu löschen. Der Zugriff auf den Host- oder Anwendungsdatensatz kann während dieser Operationen erhalten bleiben, solange die Implementierung eine korrekte Ausrichtung der Host- oder Anwendungsdatensatz-Modifikation oder der Leseoperationen auf den Datenträger nach Identität erlaubt und solange die Identität entsprechend dem Speicherprotokoll oder Speichermodell erhalten bleibt (z.B. solange die Identifikatoren der logischen Einheiten für Datenträger und die Verwendung von Ziel-Ports für den Zugriff auf Datenträger im Falle von SCSI erhalten bleiben).
  • Die Migration eines Datenträgers zwischen Pods kann zu Problemen führen. Wenn die Pods über einen identischen Satz von Speichersystemen für synchrone Elemente verfügen, kann es einfach sein: die Operationen auf den zu migrierenden Datenträgern vorübergehend aussetzen, die Kontrolle über die Operationen auf diesen Datenträgern auf die Kontrolle der Software und Strukturen für den neuen Pod verlagern und dann die Operationen wieder aufnehmen. Dies ermöglicht eine nahtlose Migration mit kontinuierlicher Betriebszeit für Anwendungen, abgesehen von der sehr kurzen Aussetzung des Betriebs, vorausgesetzt, dass Netzwerk und Ports ordnungsgemäß zwischen den Pods migriert werden. Je nach Implementierung ist die Aussetzung des Betriebs möglicherweise nicht einmal notwendig oder so systemintern, dass die Aussetzung des Betriebs keine Auswirkungen hat. Das Kopieren von Datenträgern zwischen Pods mit unterschiedlichen synchronen Zugehörigkeitssätzen stellt eher ein Problem dar. Wenn der Ziel-Pod für die Kopie eine Untermenge von In-Sync-Elementen aus dem Quell-Pod aufweist, ist das kein großes Problem: ein Elemente-Speichersystem kann sicher genug abgelegt werden, ohne dass mehr Arbeit anfällt. Wenn jedoch der Ziel-Pod dem Datenträger über den Quell-Pod Speichersysteme von In-Sync-Elementen hinzufügt, dann müssen die hinzugefügten Speichersysteme synchronisiert werden, um den Inhalt des Datenträgers aufzunehmen, bevor sie verwendet werden können. Bis sie synchronisiert sind, unterscheiden sich die kopierten Datenträger deutlich von den bereits synchronisierten Datenträgern, da sich die Fehlerbehandlung unterscheidet und die Behandlung von Anfragen von den noch nicht In-Sync-Speichersystemen der Elemente entweder nicht funktioniert oder weitergeleitet werden muss oder nicht so schnell ist, weil die Lesevorgänge über eine Verbindung laufen müssen. Außerdem muss die interne Implementierung damit umgehen, dass einige Datenträger synchronisiert und für die Fehlerbehandlung bereit sind und andere nicht synchronisiert sind.
  • Es gibt weitere Probleme im Zusammenhang mit der Zuverlässigkeit des Betriebs angesichts von Störungen. Die Koordination einer Migration von Volumina zwischen Pods von Mehrspeichersystemen ist eine verteilte Operation. Wenn die Pods die Einheit der Fehlerbehandlung und -behebung sind und wenn Vermittlung oder Quorum oder welche Mittel auch immer zur Vermeidung von Split-Brain-Situationen eingesetzt werden, dann müssen bei einem Wechsel der Datenträger von einem Pod - mit einem bestimmten Satz von Zuständen und Konfigurationen und Beziehungen für Fehlerbehandlung, Behebung, Vermittlung und Quorum - zu einem anderen, Speichersysteme in einem Pod bei der Koordinierung von Änderungen im Zusammenhang mit dieser Behandlung für alle Datenträger vorsichtig sein. Operationen können nicht atomarisch zwischen Speichersystemen verteilt werden, sondern müssen in irgendeiner Weise ausgerichtet werden. Vermittler- und Quorum-Modelle liefern den Pods im Wesentlichen die Werkzeuge für die Implementierung verteilter transaktionaler Atomarität, aber dies darf sich nicht auf Operationen zwischen den Pods erstrecken, ohne die Implementierung zu erweitern.
  • Es ist sogar eine einfache Migration eines Datenträgers von einem ersten in einen zweiten Pod in Betracht zu ziehen, selbst bei zwei Pods, die sich das gleiche erste und zweite Speichersystem teilen. Irgendwann werden sich die Speichersysteme koordinieren, um festzulegen, dass sich der Datenträger jetzt in dem zweiten Pod und nicht mehr in dem ersten Pod befindet. Wenn es keinen inhärenten Mechanismus für transaktionale Atomarität zwischen den Speichersystemen für die beiden Pods gibt, dann könnte eine naive Implementierung den Datenträger zum Zeitpunkt eines Netzwerkfehlers, der zu einer Fehlerbehandlung führt, um die Speichersysteme von den beiden Pods zu trennen, im ersten Pod auf dem ersten Speichersystem und im zweiten Pod auf dem zweiten Speichersystem belassen. Wenn die Pods getrennt bestimmen, welches Speichersystem das andere erfolgreich abtrennt, könnte das Ergebnis sein, dass dasselbe Speichersystem das andere Speichersystem für beide Pods abtrennt. In diesem Fall sollte das Ergebnis der Wiederherstellung der Datenträgermigration konsistent sein, oder es könnte dazu führen, dass ein anderes Speichersystem das andere für die beiden Pods abtrennt. Wenn das erste Speichersystem das zweite Speichersystem für den ersten Pod abtrennt und das zweite Speichersystem das erste Speichersystem für den zweiten Pod abtrennt, könnte die Wiederherstellung dazu führen, dass der Datenträger im ersten Pod auf dem ersten Speichersystem und im zweiten Pod auf dem zweiten Speichersystem wiederhergestellt wird, wobei der Datenträger dann ausgeführt und zu Hosts und Speicheranwendungen auf beiden Speichersystemen exportiert wird. Wenn stattdessen das zweite Speichersystem das erste Speichersystem vom ersten Speichersystem für den ersten Pod abtrennt und der erste Speicher das zweite Speichersystem für den zweiten Pod abtrennt, dann könnte die Wiederherstellung dazu führen, dass der Datenträger vom ersten Speichersystem aus dem zweiten Pod entfernt wird und der Datenträger vom zweiten Speichersystem aus dem ersten Pod entfernt wird, was dazu führt, dass der Datenträger vollständig verschwindet. Wenn sich die Pods, zwischen denen ein Datenträger migriert wird, auf unterschiedlichen Speichersystemen befinden, kann die Sache noch komplizierter werden.
  • Eine Lösung für diese Probleme könnte darin bestehen, einen Zwischen-Pod zusammen mit den zuvor beschriebenen Techniken zum Teilen und Zusammenfügen von Pods zu verwenden. Dieser Zwischen-Pod darf niemals als sichtbare verwaltete Objekte präsentiert werden, die mit den Speichersystemen verbunden sind. In diesem Modell werden Volumina, die von einem ersten Pod in einen zweite Pod verschoben werden sollen, zunächst von dem ersten Pod in einen neuen Zwischen-Pod unter Verwendung des zuvor beschriebenen Aufteilungsvorgangs aufgeteilt. Die Speichersystem-Elemente für den Zwischen-Pod können dann an die Zugehörigkeit zu Speichersystemen angepasst werden, indem Speichersysteme je nach Bedarf dem Pod hinzugefügt oder aus ihm entfernt werden. Anschließend kann der Zwischen-Pod mit dem zweiten Pod verbunden werden.
  • Zur weiteren Erläuterung enthält 5 ein Flussdiagramm, in dem die Schritte dargestellt sind, welche von Speichersystemen (402, 404, 406) durchgeführt werden können, die gemäß einigen Ausführungsformen der vorliegenden Offenbarung an einen Pod angeschlossen sind. Obwohl weniger detailliert dargestellt, können die in 5 dargestellten Speichersysteme (402. 404, 406) den vorstehend beschriebenen Speichersystemen mit Bezug auf die 1A-1D, 2A-2G, 3A-3B, 4 oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 5 dargestellten Speichersysteme (402, 404, 406) die gleichen, weniger zusätzliche Komponenten enthalten wie die vorstehend beschriebenen Speichersysteme.
  • In der in 5 dargestellten Beispielmethode kann ein Speichersystem (402) an einen Pod (508) angeschlossen werden. Das Modell für die Pod-Zugehörigkeit kann eine Liste von Speichersystemen und eine Untermenge dieser Liste enthalten, wobei davon ausgegangen wird, dass die Speichersysteme für den Pod synchronisiert sind. Ein Speichersystem ist für einen Pod in-sync, wenn er zumindest innerhalb einer Wiederherstellungsphase identische inaktive Inhalte für die letzte schriftliche Kopie des mit dem Pod verknüpften Datensatzes aufweist. Idle-Inhalt ist der Inhalt, nachdem alle laufenden Änderungen abgeschlossen sind, ohne dass neue Änderungen verarbeitet wurden. Manchmal wird dies als „absturzwiederherstellbare“ Konsistenz bezeichnet. Speichersysteme, die als Pod-Elemente, aber nicht als in-sync für den Pod aufgelistet sind, können als „abgetrennt“ vom Pod bezeichnet werden. Speichersysteme, die als Pod-Elemente aufgelistet sind, für den Pod in-sync sind und derzeit für die aktive Bereitstellung von Daten für den Pod zur Verfügung stehen, sind für den Pod „online“.
  • In der in 5 dargestellten Beispielmethode kann sich das Speichersystem (402) beispielsweise an einen Pod (508) anschließen, indem es seine lokal gespeicherte Version des Datensatzes (426) zusammen mit einer aktuellen Version des Datensatzes (426) synchronisiert, welcher auf anderen Speichersystemen (404, 406) im Pod gespeichert ist, die online sind, wie der Begriff vorstehend beschrieben wird. Damit das Speichersystem (402) den Pod (508) anschließen kann, muss in einem solchen Beispiel möglicherweise eine Pod-Definition, die lokal in jedem der Speichersysteme (402, 404, 406) im Pod gespeichert ist, aktualisiert werden, damit das Speichersystem (402) den Pod (508) anschließen kann. In einem solchen Beispiel kann jedes Speichersystem-Element eines Pods über eine eigene Kopie der Zugehörigkeit verfügen, einschließlich der Speichersysteme, von denen es zuletzt wusste, dass sie synchronisiert sind, und der Speichersysteme, von denen es zuletzt wusste, dass sie die gesamte Gruppe der Pod-Elemente umfassen.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) auch eine Anforderung zum Lesen eines Teils des Datensatzes (426) empfangen (510) und das Speichersystem (402) kann die Anforderung zum lokalen Lesen des Teils des Datensatzes (426) verarbeiten (512). Die Leser werden verstehen, dass, obwohl Anfragen zur Änderung (z.B. eine Schreiboperation) des Datensatzes (426) eine Koordination zwischen den Speichersystemen (402, 404, 406) in einem Pod erfordern, da der Datensatz (426) über alle Speichersysteme (402, 404, 406) in einem Pod konsistent sein sollte, die Beantwortung einer Anfrage zum Lesen eines Teils des Datensatzes (426) keine ähnliche Koordination zwischen den Speichersystemen (402, 404, 406) erfordert. Daher kann ein bestimmtes Speichersystem (402), das eine Leseanforderung empfängt, die Leseanforderung lokal bedienen, indem es einen Teil des Datensatzes (426) liest, der in den Speichergeräten des Speichersystems (402) gespeichert ist, ohne dass eine synchrone Kommunikation mit anderen Speichersystemen (404, 406) in dem Pod stattfindet. Es wird erwartet, dass Leseanforderungen, die von einem Speichersystem für einen replizierten Datensatz in einem replizierten Cluster empfangen werden, in den allermeisten Fällen jegliche Kommunikation vermeiden, zumindest wenn sie von einem Speichersystem empfangen werden, das innerhalb eines Clusters läuft, der auch nominell läuft. Solche Lesevorgänge sollten normalerweise einfach durch Lesen aus der lokalen Kopie eines geclusterten Datensatzes verarbeitet werden, ohne dass eine weitere Interaktion mit anderen Speichersystemen im Cluster erforderlich ist.
  • Die Leser werden verstehen, dass die Speichersysteme Maßnahmen zur Sicherstellung der Lesekonsistenz ergreifen können, so dass eine Leseanforderung unabhängig davon, welches Speichersystem die Leseanforderung verarbeitet, das gleiche Ergebnis liefert. Beispielsweise sollte der resultierende geclusterte Datensatzinhalt für jeden Satz von Aktualisierungen, die von jedem beliebigen Satz von Speichersystemen im Cluster empfangen werden, im gesamten Cluster konsistent sein, zumindest zu jeder Zeit, wenn Aktualisierungen nicht ausgeführt werden (alle früheren Änderungsoperationen wurden als abgeschlossen angezeigt, und es wurden keine neuen Aktualisierungsanforderungen empfangen und in irgendeiner Weise verarbeitet). Genauer gesagt können sich die Instanzen eines Cluster-Datensatzes über einen Satz von Speichersystemen hinweg nur aufgrund von Aktualisierungen unterscheiden, die noch nicht abgeschlossen sind. Das bedeutet zum Beispiel, dass zwei Schreibanforderungen, die sich in ihrem Datenträgerblockbereich überlappen, oder eine Kombination aus einer Schreibanforderung und einem überlappenden Snapshot, Vergleichen und Schreiben oder einer Kopie des virtuellen Blockbereichs ein konsistentes Ergebnis auf allen Kopien des Datenbestands liefern müssen. Zwei Operationen können nicht zu einem Ergebnis führen, als würden sie in einer Reihenfolge auf einem Speichersystem und in einer anderen Reihenfolge auf einem anderen Speichersystem im replizierten Cluster stattfinden.
  • Darüber hinaus können Leseanfragen in der zeitlichen Reihenfolge konsistent sein. Zum Beispiel, wenn eine Leseanforderung auf einem replizierten Cluster empfangen und abgeschlossen wird und auf diese Leseanforderung dann eine weitere Leseanforderung an einen überlappenden Adressbereich folgt, die von dem replizierten Cluster empfangen wird und bei der sich eine oder beide Leseanforderungen in irgendeiner Weise in Zeit und im Datenträgeradressbereich mit einer Änderungsanforderung überlappen, die von dem replizierten Cluster empfangen wird (unabhängig davon, ob eine der Leseanforderungen oder die Änderung von demselben Speichersystem oder einem anderen Speichersystem in dem replizierten Cluster empfangen wird), Wenn die erste Ablesung das Ergebnis der Aktualisierung widerspiegelt, dann sollte die zweite Ablesung ebenfalls die Ergebnisse dieser Aktualisierung widerspiegeln, anstatt möglicherweise Daten zurückzugeben, die der Aktualisierung vorausgingen. Wenn die erste Ablesung nicht die Aktualisierung widerspiegelt, dann kann die zweite Ablesung entweder die Aktualisierung widerspiegeln oder nicht. Dadurch wird sichergestellt, dass zwischen zwei Leseanforderungen die „Zeit“ für ein Datensegment nicht rückwärts drehen kann.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) auch eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) erkennen (514). Eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) kann aus einer Vielzahl von Gründen auftreten (514). Beispielsweise kann eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) auftreten, weil eines der Speichersysteme (402, 404, 406) ausgefallen ist, weil eine Netzverbindung ausgefallen ist oder aus einem anderen Grund. Ein wichtiger Aspekt des synchronen replizierten Clustering ist die Sicherstellung, dass eine Fehlerbehandlung nicht zu nicht behebbaren Inkonsistenzen oder inkonsistenten Antworten führt. Wenn beispielsweise ein Netzwerk zwischen zwei Speichersystemen ausfällt, kann höchstens eines der Speichersysteme die Verarbeitung neu eingehender E/A-Anforderungen für einen Pod fortsetzen. Und wenn ein Speichersystem die Verarbeitung fortsetzt, kann das andere Speichersystem keine neuen Anforderungen, einschließlich Leseanforderungen, bis zum Abschluss verarbeiten.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) auch bestimmen (516), ob das bestimmte Speichersystem (402) als Teil des Pods online bleiben soll. Wie vorstehend erwähnt, muss ein Speichersystem, um als Teil eines Pods „online“ zu sein, sich selbst als in-sync für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als in-sync für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es in-sync ist und mit allen anderen Speichersystemen, die in-sync sind, kommuniziert, dann kann es die Verarbeitung neuer eingehender Anfragen für den Zugriff auf den Datensatz stoppen (426). Als solches kann das Speichersystem (402) bestimmen (516), ob das bestimmte Speichersystem (402) als Teil des Pods online bleiben soll, z.B. indem es bestimmt, ob es mit allen anderen Speichersystemen (404, 406) kommunizieren kann, die es für den Pod als in-sync betrachtet (z.B. über eine oder mehrere Testnachrichten), indem bestimmt wird, ob alle anderen Speichersysteme (404, 406), die sie für den Pod als in-sync für den Pod erachtet, auch das Speichersystem (402) als an den Pod angeschlossen betrachten, und zwar durch eine Kombination beider Schritte, wobei das bestimmte Speichersystem (402) bestätigen muss, dass es mit allen anderen Speichersystemen kommunizieren kann (404, 406), sie als in-sync für den Pod erachtet und dass alle anderen Speichersysteme (404, 406), die sie als in-sync für den Pod erachtet, ebenfalls das Speichersystem (402) berücksichtigen, das am Pod oder durch einen anderen Mechanismus verbunden ist.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) als Reaktion auf die bejahende (518) Entscheidung, dass das bestimmte Speichersystem (402) als Teil des Pods online bleiben soll, auch den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen zugänglich halten (522). Das Speichersystem (402) kann den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen zugänglich halten (522), z.B. durch die Annahme von Anfragen zum Zugriff auf die Version des Datensatzes (426), die auf dem Speichersystem (402) gespeichert ist, und die Bearbeitung solcher Anfragen, durch Akzeptieren und Verarbeiten von Betriebsoperationen im Zusammenhang mit dem Datensatz (426), die von einem Host oder autorisierten Administrator ausgegeben werden, durch Akzeptieren und Verarbeiten von Betriebsoperationen im Zusammenhang mit dem Datensatz (426), die von einem der anderen Speichersysteme (404, 406) im Pod oder auf andere Weise ausgegeben werden.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) als Reaktion auf das Bestimmen, dass das bestimmte Speichersystem nicht (520) als Teil des Pods online bleiben soll, auch den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen unzugänglich machen (524). Das Speichersystem (402) kann den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen unzugänglich machen (524), z.B. durch Ablehnung von Anträgen auf Zugriff auf die Version des Datensatzes (426), die auf dem Speichersystem (402) gespeichert ist, durch Ablehnen von Betriebsoperationen in Verbindung mit dem Datensatz (426), die von einem Host oder einem anderen autorisierten Administrator ausgegeben werden, durch Ablehnen von Betriebsoperationen in Verbindung mit dem Datensatz (426), die von einem der anderen Speichersysteme (404, 406) im Pod oder auf andere Weise ausgegeben werden.
  • In der in 5 dargestellten Beispielmethode kann das Speichersystem (402) auch erkennen (526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) repariert wurde. Das Speichersystem (402) kann erkennen (526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) repariert wurde, z.B. durch Empfangen einer Nachricht von dem einen oder mehreren der anderen Speichersysteme (404, 406). Als Reaktion auf die Feststellung (526), dass die Unterbrechung in der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) repariert wurde, kann das Speichersystem (402) den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen zugänglich machen (528).
  • Die Leser werden verstehen, dass das in 5 dargestellte Beispiel eine Ausführungsform beschreibt, in der verschiedene Handlungen so dargestellt werden, dass sie innerhalb einer bestimmten Reihenfolge stattfinden, obwohl keine Reihenfolge erforderlich ist. Darüber hinaus können andere Ausführungsformen existieren, bei denen das Speichersystem (402) nur eine Teilmenge der beschriebenen Aktionen ausführt. Zum Beispiel kann das Speichersystem (402) die folgenden Schritte ausführen: Erkennen (514) einer Unterbrechung in der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406), Bestimmen (516), ob das bestimmte Speichersystem (402) in dem Pod verbleiben soll, Beibehalten (522) des Datensatzes (426) auf dem bestimmten Speichersystem (402), der für Betriebs- und Datensatzoperationen zugänglich ist, oder Unzugänglichmachen (524) des Datensatzes (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen, ohne zuvor eine Anforderung zum Lesen eines Teils des Datensatzes (426) zu empfangen (510) und die Anforderung zum lokalen Lesen des Teils des Datensatzes (426) zu verarbeiten (512). Darüber hinaus kann das Speichersystem (402) erkennen (526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (404, 406) repariert worden ist, und den Datensatz (426) auf dem bestimmten Speichersystem (402) für Betriebs- und Datensatzoperationen zugänglich machen (528), ohne zuvor eine Anforderung zum Lesen eines Teils des Datensatzes (426) zu empfangen (510) und die Anforderung zum lokalen Lesen des Teils des Datensatzes (426) zu verarbeiten (512). Tatsächlich ist keiner der hier beschriebenen Schritte in allen Ausführungsformen als Voraussetzung für die Durchführung anderer hier beschriebener Schritte ausdrücklich erforderlich.
  • Zur weiteren Erläuterung enthält 6 ein Flussdiagramm, in dem die Schritte dargestellt sind, die von Speichersystemen (402, 404, 406) durchgeführt werden können, die gemäß einigen Ausführungsformen der vorliegenden Offenbarung an einen Pod angeschlossen sind. Obwohl sie weniger detailliert dargestellt sind, können die in 6 dargestellten Speichersysteme (402. 404, 406) den vorstehend beschriebenen Speichersystemen unter Bezugnahme auf die 1A-1D, 2A-2G, 3A-3B, 4 oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 6 dargestellten Speichersysteme (402, 404, 406) die gleichen, weniger, zusätzliche Komponenten enthalten wie die vorstehend beschriebenen Speichersysteme.
  • In der in 6 dargestellten Beispielmethode können zwei oder mehr der Speichersysteme (402, 404) jeweils ein Zielspeichersystem (618) für das asynchrone Empfangen des Datensatzes (426) erkennen (608). Das Zielspeichersystem (618) für den asynchronen Empfang des Datensatzes (426) kann z.B. als Backup-Speichersystem, das sich in einem anderen Datenzentrum befindet als eines der Speichersysteme (402, 404), die Elemente eines bestimmten Pods sind, als Cloud-Speicher, der von einem Cloud-Dienstanbieter bereitgestellt wird, oder auf viele andere Weisen verkörpert sein. Die Leser werden verstehen, dass das Zielspeichersystem (618) nicht eines der mehreren Speichersysteme (402, 404) ist, über die der Datensatz (426) synchron repliziert wird, und dass das Zielspeichersystem (618) als solches anfänglich keine aktuelle lokale Kopie des Datensatzes (426) enthält.
  • In der in 6 dargestellten Beispielmethode können zwei oder mehr der Speichersysteme (402, 404) jeweils auch einen Teil des Datensatzes (426) erkennen (610), der nicht asynchron von einem der anderen Speichersysteme, die Elemente eines Pods sind, der den Datensatz (426) enthält, auf das Zielspeichersystem (618) repliziert wird. In einem solchen Beispiel können die Speichersysteme (402, 404) jeweils den Teil des Datensatzes (426), der nicht durch eines der anderen Speichersysteme asynchron auf das Zielspeichersystem (618) repliziert wird, asynchron auf das Zielspeichersystem (618) replizieren (612). Angenommen, in einem Beispiel ist ein erstes Speichersystem (402) für die asynchrone Replikation eines ersten Teils (z.B. einer ersten Hälfte eines Adressraums) des Datensatzes (426) in das Zielspeichersystem (618) verantwortlich. In einem solchen Beispiel wäre das zweite Speichersystem (404) für die asynchrone Replikation eines zweiten Teils (z.B. einer zweiten Hälfte eines Adressraums) des Datensatzes (426) an das Zielspeichersystem (618) verantwortlich, so dass die zwei oder mehr Speichersysteme (402, 404) gemeinsam den gesamten Datensatz (426) an das Zielspeichersystem (618) replizieren.
  • Die Leser werden verstehen, dass durch die Verwendung von Pods, wie vorstehend beschrieben, die Replikationsbeziehung zwischen zwei Speichersystemen von einer Beziehung, in der Daten asynchron repliziert werden, auf eine Beziehung, in der Daten synchron repliziert werden, umgeschaltet werden kann. Wenn z.B. Speichersystem A so konfiguriert ist, dass es einen Datensatz asynchron auf Speichersystem B repliziert, kann die Beziehung, in der Daten asynchron repliziert werden, durch die Erstellung eines Pods, der den Datensatz, Speichersystem A als Element und Speichersystem B als Element enthält, auf eine Beziehung umgeschaltet werden, in der Daten synchron repliziert werden. Ebenso kann durch die Verwendung von Pods die Replikationsbeziehung zwischen zwei Speichersystemen von einer Beziehung, in der Daten synchron repliziert werden, auf eine Beziehung umgeschaltet werden, in der Daten asynchron repliziert werden. Wenn z.B. ein Pod erstellt wird, der den Datensatz, Speichersystem A als Element und Speichersystem B als Element enthält, indem man den Pod lediglich entspannt (um Speichersystem A als Element zu entfernen oder Speichersystem B als Element zu entfernen), kann eine Beziehung, in der Daten synchron zwischen den Speichersystemen repliziert werden, sofort in eine Beziehung umgeschaltet werden, in der Daten asynchron repliziert werden. Auf diese Weise können Speichersysteme je nach Bedarf zwischen asynchroner Replikation und synchroner Replikation hin- und herwechseln.
  • Dieser Wechsel kann dadurch erleichtert werden, dass die Implementierung sowohl für die synchrone als auch für die asynchrone Replikation auf ähnliche Techniken zurückgreift. Wenn z.B. die Resynchronisierung für einen synchron replizierten Datensatz auf demselben oder einem kompatiblen Mechanismus beruht, der für die asynchrone Replikation verwendet wird, dann ist das Umschalten auf asynchrone Replikation konzeptionell identisch mit dem Beenden des In-Sync-Zustands und dem Belassen einer Beziehung in einem Zustand, der einem „Perpetual Recovery“-Modus ähnelt. Ebenso kann das Umschalten von asynchroner Replikation auf synchrone Replikation konzeptionell dadurch erfolgen, dass man „aufholt“ und in-sync wird, genauso wie es beim Abschluss einer Resynchronisation geschieht, wenn das Umschaltsystem ein in-sync Pod-Element wird.
  • Alternativ oder zusätzlich, wenn sich sowohl die synchrone als auch die asynchrone Replikation auf ähnliche oder identische gemeinsame Metadaten oder ein gemeinsames Modell zur Darstellung und Identifizierung von logischen Erweiterungen oder Identitäten gespeicherter Blöcke oder ein gemeinsames Modell zur Darstellung inhalts-adressierbarer gespeicherter Blöcke stützt, dann können diese Aspekte der Gemeinsamkeit genutzt werden, um den Inhalt, der beim Wechsel zur und von der synchronen und asynchronen Replikation möglicherweise übertragen werden muss, drastisch zu reduzieren. Wenn außerdem ein Datensatz asynchron von einem Speichersystem A auf ein Speichersystem B repliziert wird und System B diesen Datensatz weiter asynchron auf ein Speichersystem C repliziert, dann kann ein gemeinsames Metadatenmodell, eine gemeinsame logische Erweiterung oder Blockidentitäten oder eine gemeinsame Darstellung inhalts-adressierbarer gespeicherter Blöcke die Datenübertragungen, die für eine synchrone Replikation zwischen Speichersystem A und Speichersystem C erforderlich sind, drastisch reduzieren.
  • Die Leser werden ferner zu schätzen wissen, dass durch die Verwendung von Pods, wie vorstehend beschrieben, Replikationstechniken auch für andere Aufgaben als die Datenreplikation eingesetzt werden können. Da ein Pod eine Reihe von verwalteten Objekten enthalten kann, können Aufgaben wie die Migration einer virtuellen Maschine mit Hilfe von Pods und den hier beschriebenen Replikationstechniken durchgeführt werden. Wenn beispielsweise die virtuelle Maschine A auf dem Speichersystem A ausgeführt wird, können durch die Erstellung eines Pods, der die virtuelle Maschine A als verwaltetes Objekt, welches Speichersystem A als Element und das Speichersystem B als Element enthält, die virtuelle Maschine A und alle zugehörigen Bilder und Definitionen auf das Speichersystem B migriert werden.
  • Zur weiteren Erläuterung enthält 7 Diagramme von Metadatendarstellungen, die als strukturierte Sammlung von Metadatenobjekten implementiert werden können, die zusammen ein logisches Volumen von Speicherdaten oder einen Teil eines logischen Volumens gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellen können. Die Metadatendarstellungen 750, 754 und 760 können in einem Speichersystem gespeichert werden (706), und eine oder mehrere Metadatendarstellungen können für jedes von mehreren Speicherobjekten, wie z.B. Datenträger oder Teile von Datenträgern, die in einem Speichersystem gespeichert sind, erzeugt und gepflegt werden (706).
  • Während andere Arten von strukturierten Sammlungen der Metadatenobjekte möglich sind, können die Metadatendarstellungen in diesem Beispiel als ein gerichteter azyklischer Graph (DAG) von Knoten strukturiert werden, wobei der DAG zur Aufrechterhaltung eines effizienten Zugriffs auf jeden beliebigen Knoten nach verschiedenen Verfahren strukturiert und ausbalanciert werden kann. Beispielsweise kann ein DAG für eine Metadatendarstellung als eine Art B-Baum definiert und als Reaktion auf Änderungen an der Struktur der Metadatendarstellung entsprechend ausbalanciert werden, wobei Änderungen an der Metadatendarstellung als Reaktion auf Änderungen oder Ergänzungen der zugrundeliegenden Daten, die durch die Metadatendarstellung dargestellt werden, auftreten können. Während es in diesem Beispiel der Einfachheit halber nur zwei Ebenen gibt, können sich die Metadatendarstellungen in anderen Beispielen über mehrere Ebenen erstrecken und Hunderte oder Tausende von Knoten umfassen, wobei jeder Knoten beliebig viele Verknüpfungen zu anderen Knoten enthalten kann.
  • Ferner können in diesem Beispiel die Leafs einer Metadatendarstellung Zeiger auf die gespeicherten Daten für einen Datenträger oder einen Teil eines Datenträgers enthalten, wobei eine logische Adresse oder ein Datenträger und ein Offset verwendet werden können, um die Metadatendarstellung zu identifizieren und durch sie zu navigieren, um einen oder mehrere Leaf-Knoten zu erreichen, die auf gespeicherte Daten verweisen, die der logischen Adresse entsprechen. Zum Beispiel kann ein Datenträger (752) durch eine Metadatendarstellung (750) repräsentiert werden, die mehrere Metadaten-Objektknoten (752, 752A-752N) enthält, wobei Leaf-Knoten (752A-752N) Zeiger auf entsprechende Datenobjekte (753A-753N, 757) enthalten. Datenobjekte können beliebig große Dateneinheiten innerhalb eines Speichersystems sein (706). Beispielsweise können Datenobjekte (753A-753N, 757) jeweils eine logische Erweiterung sein, wobei logische Erweiterungen eine bestimmte Größe haben können, z. B. 1 MB, 4 MB oder eine andere Größe.
  • In diesem Beispiel kann eine Momentaufnahme (756) als Momentaufnahme eines Speicherobjekts, in diesem Fall eines Datenträgers (752), erstellt werden, wobei zum Zeitpunkt der Erstellung der Momentaufnahme (756) die Metadatendarstellung (754) für die Momentaufnahme (756) alle Metadatenobjekte für die Metadatendarstellung (750) für den Datenträger (752) umfasst. Darüber hinaus kann als Reaktion auf die Erstellung des Snapshots (756) die Metadatendarstellung (754) für den Datenträger (752) als schreibgeschützt gekennzeichnet werden. Der Datenträger (752), der die Metadatendarstellung gemeinsam nutzt, kann jedoch weiterhin modifiziert werden, und während zum Zeitpunkt der Erstellung der Momentaufnahme die Metadatendarstellungen für den Datenträger (752) und die Momentaufnahme (756) identisch sind, da Änderungen an Daten vorgenommen werden, die dem Datenträger (752) entsprechen, und als Reaktion auf die Änderungen, können die Metadatendarstellungen für den Datenträger (752) und die Momentaufnahme (756) voneinander abweichen und unterschiedlich werden.
  • Wenn beispielsweise eine Metadatendarstellung (750) zur Darstellung eines Datenträgers (752) und eine Metadatendarstellung (754) zur Darstellung eines Snapshots (756) gegeben ist, kann das Speichersystem (706) eine E/A-Operation empfangen, die in Daten schreibt, die letztlich in einem bestimmten Datenobjekt (753B) gespeichert sind, wobei auf das Datenobjekt (753B) durch einen Leaf-Knotenzeiger (752B) gezeigt wird und wobei der Leaf-Knotenzeiger (752B) Teil beider Metadatendarstellungen (750, 754) ist. Als Reaktion auf den Schreibvorgang bleiben die Nur-Lese-Datenobjekte (753A-753N), auf die von der Metadatendarstellung (754) verwiesen wird, unverändert, und der Zeiger (752B) kann ebenfalls unverändert bleiben. Die Metadatendarstellung (750), die den aktuellen Datenträger (752) darstellt, wird jedoch geändert, um ein neues Datenobjekt zur Aufnahme der durch den Schreibvorgang geschriebenen Daten aufzunehmen, wobei die geänderte Metadatendarstellung als Metadatendarstellung (760) dargestellt wird. Darüber hinaus kann der Schreibvorgang nur auf einen Teil des Datenobjekts (753B) gerichtet sein, und folglich kann das neue Datenobjekt (757) zusätzlich zu der Nutzlast für den Schreibvorgang eine Kopie des früheren Inhalts des Datenobjekts (753B) enthalten.
  • In diesem Beispiel wird als Teil der Verarbeitung des Schreibvorgangs die Metadatendarstellung (760) für den Datenträger (752) geändert, um einen vorhandenen Metadaten-Objektzeiger (752B) zu entfernen und einen neuen Metadaten-Objektzeiger (758) aufzunehmen, wobei der neue Metadaten-Objektzeiger (758) so konfiguriert ist, dass er auf ein neues Datenobjekt (757) zeigt, wobei das neue Datenobjekt (757) die durch den Schreibvorgang geschriebenen Daten speichert. Darüber hinaus umfasst die Metadatendarstellung (760) für den Datenträger (752) weiterhin alle Metadatenobjekte, die in der vorherigen Metadatendarstellung (750) enthalten waren - mit Ausnahme des Metadatenobjektzeigers (752B), der auf das Zieldatenobjekt verwiesen hat, wobei der Metadatenobjektzeiger (752B) weiterhin auf das Nur-Lese-Datenobjekt (753B) verweist, das überschrieben worden wäre.
  • Auf diese Weise kann unter Verwendung von Metadatendarstellungen ein Datenträger oder ein Teil eines Datenträgers durch die Erstellung von Metadatenobjekten und ohne tatsächliche Duplizierung von Datenobjekten als Snapshot oder Kopie betrachtet werden, wobei die Duplizierung von Datenobjekten aufgeschoben werden kann, bis ein Schreibvorgang auf eines der Nur-Lese-Datenobjekte gerichtet ist, auf die sich die Metadatendarstellungen beziehen.
  • Mit anderen Worten, ein Vorteil der Verwendung einer Metadatendarstellung zur Darstellung eines Datenträgers besteht darin, dass ein Snapshot oder eine Kopie eines Datenträgers erstellt werden kann und in konstanter Reihenfolge und insbesondere in der Zeit zugänglich ist, die benötigt wird, um ein Metadatenobjekt für den Snapshot oder die Kopie zu erstellen und eine Referenz für das Metadatenobjekt des Snapshots oder der Kopie auf die vorhandene Metadatendarstellung für den zu erstellenden oder zu kopierenden Datenträger zu erstellen.
  • Beispielsweise kann eine virtualisierte Kopie nach Referenz eine Metadatendarstellung in ähnlicher Weise wie eine Metadatendarstellung bei der Erstellung eines Snapshots eines Datenträgers verwenden, wobei eine Metadatendarstellung für eine virtualisierte Kopie nach Referenz oft einem Teil einer Metadatendarstellung für einen ganzen Datenträger entsprechen kann. Eine Beispielimplementierung einer virtualisierten Kopie nach Referenz kann im Kontext eines virtualisierten Speichersystems erfolgen, wo mehrere Blockbereiche innerhalb und zwischen den Datenträgern auf eine einheitliche Kopie der gespeicherten Daten verweisen können. In einem solchen virtualisierten Speichersystem können die vorstehend beschriebenen Metadaten verwendet werden, um die Beziehung zwischen virtuellen oder logischen Adressen und physischen oder realen Adressen zu handhaben - mit anderen Worten, die Metadatendarstellung der gespeicherten Daten ermöglicht ein virtualisiertes Speichersystem, das als Flash-freundlich angesehen werden kann, da es die Abnutzung des Flash-Speichers reduziert oder minimiert.
  • In einigen Beispielen können logische Erweiterungen auf verschiedene Weise kombiniert werden, u.a. als einfache Sammlungen oder als logisch zusammenhängende Adressbereiche innerhalb einer größeren logischen Erweiterung, die als eine Reihe von logischen Erweiterungesreferenzen gebildet wird. Diesen größeren Kombinationen könnten auch verschiedene Arten von Identitäten logischer Erweiterungen zugewiesen werden, und sie könnten weiter zu noch größeren logischen Erweiterungen oder Sammlungen kombiniert werden. Ein Copy-on-Write-Status könnte für verschiedene Schichten gelten, und zwar je nach Implementierung auf unterschiedliche Weise. Beispielsweise könnte ein Copy-on-Write-Status, der aufeine logische Sammlung von logischen Erweiterungen angewendet wird, dazu führen, dass eine kopierte Sammlung Verweise auf unveränderte logische Erweiterungen beibehält und die Erstellung von kopierten logischen Erweiterungen beim Schreiben (durch das Kopieren von Verweisen auf beliebige unveränderte gespeicherte Datenblöcke nach Bedarf), wenn nur ein Teil der kopierten logischen Sammlung beim Schreiben geändert wird.
  • Deduplizierung, Datei-Snapshots oder Blockbereich-Snapshots können in diesem Modell durch Kombinationen aus der Referenz auf gespeicherte Datenblöcke oder der Referenz auf logische Erweiterungen oder der Markierung logischer Erweiterungen (oder identifizierter Sammlungen logischer Erweiterungen) als Copy-on-Write implementiert werden.
  • Darüber hinaus können bei Flash-Speichersystemen gespeicherte Datenblöcke auf verschiedene Weise organisiert und gruppiert werden, wenn Sammlungen auf Seiten ausgeschrieben werden, die Teil größerer Löschblöcke sind. Eine eventuelle Garbage Collection gelöschter oder ersetzter gespeicherter Datenblöcke kann das Verschieben von Inhalten, die in einer bestimmten Anzahl von Seiten gespeichert sind, an einen anderen Ort beinhalten, so dass ein ganzer Löschblock gelöscht und für die Wiederverwendung vorbereitet werden kann. Dieser Prozess des Auswählens physischer Flash-Seiten, ihrer eventuellen Migration und Garbage Collection und des anschließenden Löschens von Flash-Löschblöcken zur Wiederverwendung kann durch den Aspekt eines Speichersystems koordiniert, gesteuert oder durchgeführt werden, der auch logische Erweiterungen, Deduplizierung, Komprimierung, Snapshots, virtuelles Kopieren oder andere Speichersystemfunktionen handhabt, oder auch nicht. Ein koordinierter oder gesteuerter Prozess für die Auswahl von Seiten, die Migration von Seiten, das Sammeln von Datenmüll und das Löschen von Löschblöcken kann darüber hinaus verschiedene Eigenschaften der Zellen, Seiten und Löschblöcke des Flash-Speichergeräts berücksichtigen, wie z.B. die Anzahl der Verwendungen, Alterungsvorhersagen, Anpassungen der Spannungspegel oder die Anzahl der in der Vergangenheit zur Wiederherstellung gespeicherter Daten erforderlichen Wiederholungsversuche. Sie können auch Analysen und Vorhersagen für alle Flash-Speichergeräte innerhalb des Speichersystems berücksichtigen.
  • Um mit diesem Beispiel fortzufahren, bei dem ein Speichersystem auf der Grundlage von gerichteten azyklischen Graphen mit logischen Erweiterungen implementiert werden kann, können logische Erweiterungen in zwei Typen kategorisiert werden: logische Leaf-Erweiterungen, die sich in irgendeiner Weise auf eine bestimmte Menge gespeicherter Daten beziehen, und zusammengesetzte logische Erweiterungen, die sich auf andere Leaf- oder zusammengesetzte logische Erweiterungen beziehen.
  • Eine Leaf-Erweiterung kann auf verschiedene Weise auf Daten verweisen. Es kann direkt auf einen einzelnen Bereich gespeicherter Daten verweisen (z.B. 64 Kilobyte Daten), oder es kann eine Sammlung von Verweisen auf gespeicherte Daten sein (z.B. ein 1-Megabyte-„Bereich“ von Inhalten, der eine gewisse Anzahl virtueller Blöcke, die mit dem Bereich verbunden sind, auf physisch gespeicherte Blöcke abbildet). Im letzteren Fall können diese Blöcke unter Verwendung einer gewissen Identität referenziert werden, und einige Blöcke innerhalb des Bereichs der Erweiterung können auf nichts abgebildet werden. Auch im letzteren Fall müssen diese Blockreferenzen nicht eindeutig sein, so dass mehrere Zuordnungen von virtuellen Blöcken innerhalb einer bestimmten Anzahl von logischen Erweiterungen innerhalb und über eine bestimmte Anzahl von Datenträgern hinweg auf dieselben physisch gespeicherten Blöcke abgebildet werden können. Anstelle von gespeicherten Blockreferenzen könnte eine logische Erweiterung einfache Muster kodieren: zum Beispiel könnte ein Block, der eine Zeichenfolge aus identischen Bytes ist, einfach kodieren, dass der Block ein wiederholtes Muster aus identischen Bytes ist.
  • Eine zusammengesetzte logische Erweiterung kann ein logischer Inhaltsbereich mit einer gewissen virtuellen Größe sein, der eine Vielzahl von Figuren umfasst, die jeweils aus einem Teilbereich des zusammengesetzten logischen Inhaltsbereichs der logischen Erweiterung auf ein darunter liegendes Leaf oder eine zusammengesetzte logische Erweiterung abbilden. Das Transformieren einer inhaltsbezogenen Anforderung für eine zusammengesetzte logische Erweiterung beinhaltet dann, dass der Inhaltsbereich für die Anforderung im Kontext der zusammengesetzten logischen Erweiterung genommen wird, dass bestimmt wird, auf welche zugrunde liegenden Leaf- oder zusammengesetzten logischen Erweiterungen die Zuordnungen angewendet werden sollen, und dass die Anforderung so transformiert wird, dass sie auf einen geeigneten Inhaltsbereich innerhalb dieser zugrunde liegenden Leaf- oder zusammengesetzten logischen Erweiterungen angewendet wird.
  • Datenträger oder Dateien oder andere Arten von Speicherobjekten können als zusammengesetzte logische Erweiterungen beschrieben werden. Daher können diese präsentierten Speicherobjekte mit diesem Erweiterungsmodell organisiert werden.
  • Je nach Implementierung könnten Leaf- oder zusammengesetzte logische Erweiterungen aus einer Vielzahl anderer zusammengesetzter logischer Erweiterungen referenziert werden, was effektiv eine kostengünstige Vervielfältigung größerer Inhaltssammlungen innerhalb und über Datenträger hinweg ermöglicht. Auf diese Weise können logische Erweiterungen im Wesentlichen innerhalb eines azyklischen Graphen von Verweisen angeordnet werden, die jeweils in Leaf-Iogischen Erweiterungen enden. Dies kann zur Erstellung von Kopien von Datenträgern, zur Erstellung von Snapshots von Datenträgern oder als Teil der Unterstützung von Kopien virtueller Bereiche innerhalb und zwischen Datenträgern als Teil von EXTENDED COPY oder ähnlichen Arten von Operationen verwendet werden.
  • Eine Implementierung kann jeder logischen Erweiterung eine Identität geben, mit der sie benannt werden kann. Dies vereinfacht die Referenzierung, da die Verweise innerhalb zusammengesetzter logischer Erweiterungen zu Listen werden, die Identitäten logischer Erweiterungen und einen logischen Unterbereich umfassen, der jeder dieser Identitäten logischer Erweiterungen entspricht. Innerhalb logischer Erweiterungen kann jede gespeicherte Datenblockreferenz auch auf einer Identität basieren, die zu seiner Benennung verwendet wird.
  • Um diese doppelten Verwendungen von Erweiterungen zu unterstützen, können wir eine weitere Fähigkeit hinzufügen: Copy-on-Write logische Erweiterungen. Wenn eine modifizierende Operation ein Copy-on-Write-Leaf oder eine zusammengesetzte logische Erweiterung betrifft, wird die logische Erweiterung kopiert, wobei die Kopie eine neue Referenz ist und möglicherweise eine neue Identität aufweist (je nach Implementierung). Die Kopie behält alle Verweise oder Identitäten, die mit den zugrunde liegenden logischen Erweiterungen des Leafs oder der zusammengesetzten logischen Erweiterung zusammenhängen, jedoch mit allen Änderungen, die sich aus der Änderungsoperation ergeben. Beispielsweise kann eine WRITE-, WRITE SAME-, XDWRITEREAD-, XPWRITE- oder COMPARE AND WRITE-Anforderung neue Blöcke im Speichersystem speichern (oder Deduplizierungstechniken verwenden, um bestehende gespeicherte Blöcke zu identifizieren), was dazu führt, dass die entsprechenden logischen Erweiterungen der Leafs geändert werden, um auf einen neuen Satz von Blöcken zu verweisen oder Identitäten zu speichern, wobei möglicherweise Verweise und gespeicherte Identitäten für einen früheren Satz von Blöcken ersetzt werden. Alternativ dazu kann eine UNMAP-Anforderung eine Leaf-logische Erweiterung ändern, um eine oder mehrere Blockreferenzen zu entfernen. In beiden Fällen wird eine Leaf-logische Erweiterung geändert. Wenn es sich bei der Leaf-logischen Erweiterung um eine Kopierfunktion handelt, wird eine neue Leaf-logische Erweiterung erstellt, die durch Kopieren nicht betroffener Blockreferenzen aus der alten Erweiterung und anschließendes Ersetzen oder Entfernen von Blockreferenzen auf der Grundlage der Änderungsoperation gebildet wird.
  • Eine zusammengesetzte logische Erweiterung, die verwendet wurde, um die logische Leaf-Erweiterung zu lokalisieren, kann dann modifiziert werden, um die neue Leaf-Referenz oder Identität, die mit der kopierten und modifizierten logischen Leaf-Erweiterung verbunden ist, als Ersatz für die vorherige logische Leaf-Erweiterung zu speichern. Wenn es sich bei dieser zusammengesetzten logischen Erweiterung um eine Schreibkopie handelt, wird eine neue zusammengesetzte logischer Erweiterung als neue Referenz oder mit einer neuen Identität erstellt, und alle nicht betroffenen Verweise oder Identitäten zu den zugrunde liegenden logischen Ausmaßen werden in diese neue zusammengesetzte logische Erweiterung kopiert, wobei die Referenz auf die vorherige logische Erweiterung des Leafs oder die Identität durch die Referenz auf die neue logische Erweiterung des Leafs oder die neue Identität ersetzt wird.
  • Dieser Prozess setzt sich weiter rückwärts von der referenzierten Erweiterung zur referenzierenden zusammengesetzten Erweiterung fort, basierend auf dem Suchpfad durch den azyklischen Graphen, der zur Verarbeitung der modifizierenden Operation verwendet wird, wobei alle logischen Copy-on-Write-Erweiterungen kopiert, modifiziert und ersetzt werden.
  • Diese kopierten Leaf- und zusammengesetzten logischen Erweiterungen können dann die Eigenschaft, Kopie beim Schreiben zu sein, fallen lassen, so dass weitere Änderungen nicht zu einer zusätzlichen Kopie führen. Wenn zum Beispiel zum ersten Mal eine zugrundeliegende logische Erweiterung innerhalb einer Copy-on-Write - „übergeordneten“ zusammengesetzten Erweiterung modifiziert wird, kann diese zugrundeliegende logische Erweiterung kopiert und modifiziert werden, wobei die Kopie eine neue Identität aufweist, die dann in eine kopierte und ersetzte Instanz der übergeordneten zusammengesetzten logischen Erweiterung geschrieben wird. Wenn jedoch ein zweites Mal ein anderer zugrundeliegender logischer Ansatz kopiert und modifiziert wird und die neue Identität der Kopie dieses anderen zugrundeliegenden logischen Ansatzes in den übergeordneten zusammengesetzten logischen Ansatz geschrieben wird, kann der übergeordnete logische Ansatz dann an Ort und Stelle modifiziert werden, ohne dass eine weitere Kopie und ein Austausch im Namen von Verweisen auf den übergeordneten zusammengesetzten logischen Ansatz erforderlich ist.
  • Das Ändern von Operationen auf neue Regionen eines Datenträgers oder einer zusammengesetzten logischen Erweiterung, für die es keine aktuelle Leaf-logische Erweiterung gibt, kann eine neue Leaf-Iogische Erweiterung schaffen, um die Ergebnisse dieser Änderungen zu speichern. Wenn diese neue logische Erweiterung von einer bestehenden zusammengesetzten logischen Copy-on-Write-Erweiterung referenziert werden soll, dann wird diese bestehende zusammengesetzte logische Copy-on-Write-Erweiterung modifiziert, um auf die neue logische Erweiterung zu verweisen, was zu einer weiteren Folge von Kopier-, Modifikations- und Ersetzungsoperationen führt, die der Folge zur Modifikation einer bestehenden logischen Leaf-Erweiterung ähnlich ist.
  • Wenn eine übergeordnete zusammengesetzte logische Erweiterung nicht groß genug (basierend auf der Implementierung) werden kann, um einen zugeordneten Adressbereich abzudecken, der neue Leaf-logische Erweiterungen enthält, die für eine neue modifizierende Operation erstellt werden sollen, dann kann die übergeordnete zusammengesetzte logische Erweiterung in zwei oder mehr neue zusammengesetzte logischen Erweiterungen kopiert werden, die dann von einer einzigen „über-übergeordneten“ kompositen logischen Erweiterung referenziert werden, die wiederum eine neue Referenz oder eine neue Identität ist. Wenn diese „über-übergeordnete“ logische Erweiterung selbst durch einen anderen zusammengesetzten logischen Zusatz gefunden wird, welches Copy-on-Write ist, dann wird dieser andere zusammengesetzte logische Zusatz kopiert und modifiziert und auf ähnliche Weise ersetzt, wie in den vorhergehenden Absätzen beschrieben. Dieses Copy-on-Write-Modell kann als Teil der Implementierung von Snapshots, Volume-Kopien und Kopien virtueller Volume-Adressbereiche innerhalb einer SpeichersystemImplementierung verwendet werden, die auf diesen gerichteten azyklischen Graphen logischer Erweiterungen basiert. Um ein Snapshot als Nur-Lese-Kopie eines anderweitig beschreibbaren Datenträgers zu erstellen, wird ein dem Datenträger zugeordneter Graph der logischen Erweiterungen als ,,copy-on-write‟ markiert, und eine Referenz auf die ursprünglichen zusammengesetzten logischen Erweiterungen wird vom Snapshot beibehalten. Durch Änderungsoperationen auf dem Datenträger werden dann bei Bedarf Kopien der logischen Erweiterungen erstellt, was dazu führt, dass der Datenträger die Ergebnisse dieser Änderungsoperationen speichert und die Schnappschüsse den ursprünglichen Inhalt beibehalten. Volume-Kopien sind ähnlich, mit der Ausnahme, dass sowohl der Originaldatenträger als auch der kopierte Datenträger den Inhalt modifizieren können, was zu eigenen kopierten Graphen und Untergraphen der logischen Erweiterung führt.
  • Kopien virtueller Volume-Adressbereichskopien können entweder durch Kopieren von Blockreferenzen innerhalb und zwischen den logischen Erweiterungen von Leafs erfolgen (was an sich nicht die Verwendung von Copy-on-Write-Verfahren erfordert, es sei denn, Änderungen an Blockreferenzen ändern die logischen Erweiterungen von Copy-on-Write-Leafs). Alternativ dazu können Kopien virtueller Volume-Adressbereichskopien Verweise auf logische Erweiterungen von Leafs oder zusammengesetzte logische Erweiterungen duplizieren, was für Volume-Adressbereichskopien größerer Adressbereiche gut funktioniert. Außerdem können Graphen auf diese Weise zu gerichteten azyklischen Graphen von Verweisen und nicht nur zu Verweisbäumen werden. Copy-on-Write-Techniken, die mit duplizierten Verweisen auf logische Erweiterungen verbunden sind, können verwendet werden, um sicherzustellen, dass Änderungsoperationen an der Quelle oder am Ziel einer Kopie eines virtuellen Adressbereichs zur Erzeugung neuer logischer Erweiterungen führen, um diese Änderungen zu speichern, ohne das Ziel oder die Quelle zu beeinträchtigen, die unmittelbar nach der Datenträger-Adressbereichskopieroperation die gleiche logische Erweiterung haben.
  • Ein-/Ausgabe-Operationen für Pods können auch auf der Grundlage von replizierenden gerichteten azyklischen Graphen mit logischen Erweiterungen implementiert werden. Beispielsweise könnte jedes Speichersystem innerhalb eines Pods eigene Graphen mit logischen Erweiterungen implementieren, so dass die Graphen auf einem Speichersystem für einen Pod keine besondere Beziehung zu den Graphen auf einem zweiten Speichersystem für den Pod haben. Es ist jedoch sinnvoll, die Diagramme zwischen den Speichersystemen in einem Pod zu synchronisieren. Dies kann für die Resynchronisierung und zur Koordinierung von Funktionen wie der asynchronen oder Snapshot-basierten Replikation in entfernte Speichersysteme nützlich sein. Außerdem kann es nützlich sein, um einen gewissen Overhead für die Handhabung der Verteilung von Snapshot- und kopierbezogener Verarbeitung zu reduzieren. In einem solchen Modell ist das Synchronhalten des Inhalts eines Pods über alle In-Sync-Speichersysteme für einen Pod im Wesentlichen dasselbe wie das Synchronhalten von Diagrammen von Leaf- und zusammengesetzten logischen Erweiterungen für alle Datenträger über alle In-Sync-Speichersysteme für den Pod und das Sicherstellen, dass der Inhalt aller logischen Erweiterungen in-sync ist. Um in-sync zu sein, sollten übereinstimmende Leaf- und zusammengesetzte logische Erweiterungen entweder die gleiche Identität oder map-bare Identitäten haben. Die Zuordnung könnte einen Satz von Zwischenzuordnungstabellen oder eine andere Art der Identitätsübersetzung beinhalten. In einigen Fällen könnten auch die Identitäten von Blöcken, die durch Leaf-logische Erweiterungen abgebildet werden, synchron gehalten werden.
  • Bei einer Pod-Implementierung, die auf einem Leader und Followern basiert, mit einem einzigen Leader für jeden Pod, kann der Leader dafür verantwortlich sein, alle Änderungen an den logischen Erweiterungsgrafiken zu bestimmen. Wenn ein neues Leaf oder eine zusammengesetzte logische Erweiterung erstellt werden soll, kann es mit einer Identität versehen werden. Wenn ein bestehendes Leaf oder eine zusammengesetzte logische Erweiterung kopiert werden soll, um eine neue logische Erweiterung mit Modifikationen zu bilden, kann die neue logische Erweiterung als eine Kopie einer früheren logischen Erweiterung mit einem Satz von Modifikationen beschrieben werden. Wenn eine bestehende logische Erweiterung geteilt werden soll, kann die Teilung zusammen mit den neuen resultierenden Identitäten beschrieben werden. Wenn eine logische Erweiterung als eine zugrunde liegende logische Erweiterung aus einer zusätzlichen zusammengesetzten logischen Erweiterung referenziert werden soll, kann diese Referenz als eine Änderung der zusammengesetzten logischen Erweiterung beschrieben werden, um auf diese zugrunde liegende logische Erweiterung zu verweisen.
  • Die Änderungsoperationen in einem Pod umfassen somit die Verteilung von Beschreibungen von Änderungen an Graphen mit logischen Erweiterungen (wo neue logische Erweiterungen erstellt werden, um den Inhalt zu erweitern, oder wo logische Erweiterungen kopiert, modifiziert und ersetzt werden, um Copy-on-Write-Zustände zu behandeln, die sich auf Momentaufnahmen, Datenträgerkopien und Kopien von Datenträger-Adressbereichen beziehen) sowie die Verteilung von Beschreibungen und Inhalten für Änderungen am Inhalt von logischen Leaf-Erweiterungen. Ein zusätzlicher Vorteil, der sich aus der Verwendung von Metadaten in Form von gerichteten azyklischen Graphen, wie vorstehend beschrieben, ergibt, besteht darin, dass E/A-Operationen, die gespeicherte Daten im physischen Speicher modifizieren, auf Benutzerebene durch die Modifikation von Metadaten, die den gespeicherten Daten im physischen Speicher entsprechen, wirksam werden können, ohne die gespeicherten Daten im physischen Speicher zu modifizieren. In den offengelegten Ausführungsformen von Speichersystemen, bei denen der physische Speicher ein Festkörperlaufwerk sein kann, kann der Verschleiß, der mit Modifikationen des Flash-Speichers einhergeht, vermieden oder verringert werden, da E/A-Operationen durch die Modifikation der Metadaten, die die Daten repräsentieren, auf die die E/A-Operationen abzielen, und nicht durch das Lesen, Löschen oder Schreiben des Flash-Speichers wirksam werden. Darüber hinaus können in einem solchen virtualisierten Speichersystem, wie vorstehend erwähnt, die vorstehend beschriebenen Metadaten verwendet werden, um die Beziehung zwischen virtuellen oder logischen Adressen und physischen oder realen Adressen zu handhaben - mit anderen Worten, die Metadatendarstellung der gespeicherten Daten ermöglicht ein virtualisiertes Speichersystem, das als flash-freundlich angesehen werden kann, da es die Abnutzung des Flash-Speichers reduziert oder minimiert.
  • Führende Speichersysteme können ihre eigenen lokalen Operationen durchführen, um diese Beschreibungen im Zusammenhang mit ihrer lokalen Kopie des Pod-Datensatzes und den Metadaten des lokalen Speichersystems zu implementieren. Darüber hinaus führen die In-Sync-Follower ihre eigenen separaten lokalen Operationen durch, um diese Beschreibungen im Kontext ihrer separaten lokalen Kopie des Pod-Datensatzes und der Metadaten ihres separaten lokalen Speichersystems zu implementieren. Wenn sowohl die Leader- als auch die Follower-Operationen abgeschlossen sind, sind das Ergebnis kompatible Graphen der logischen Erweiterungen mit kompatiblen Inhalten der Leaf-logischen Erweiterungen. Diese Diagramme der logischen Erweiterungen werden dann zu einer Art „gemeinsamer Metadaten“, wie in den vorherigen Beispielen beschrieben. Diese gemeinsamen Metadaten können als Abhängigkeiten zwischen modifizierenden Operationen und erforderlichen gemeinsamen Metadaten beschrieben werden. Transformationen in Graphen können als separate Operationen innerhalb eines Satzes von oder mehreren Bezeichnungen beschrieben werden, die Beziehungen, wie z.B. Abhängigkeiten, zu einer oder mehreren anderen Operationen beschreiben können. Mit anderen Worten: Interdependenzen zwischen Operationen können als ein Satz von Vorläufern beschrieben werden, von denen eine Operation in irgendeiner Weise abhängt, wobei der Satz von Vorläufern als Bezeichnungen betrachtet werden kann, die wahr sein müssen, damit eine Operation abgeschlossen werden kann. Eine ausführlichere Beschreibung von Bezeichnungen findet sich in der Anwendung mit der Referenz Nummer 15/696,418, die hierin durch Verweis in ihrer Gesamtheit eingeschlossen ist. Alternativ kann jede modifizierende Operation, die sich auf eine bestimmte gleiche Graph-Transformation stützt, von der noch nicht bekannt ist, dass sie in dem gesamten Pod abgeschlossen ist, die Teile jeder Graph-Transformation enthalten, auf die sie sich stützt. Die Verarbeitung einer Operationsbeschreibung, die ein „neues“ Leaf oder eine bereits vorhandene zusammengesetzte logische Erweiterung identifiziert, kann die Erstellung der neuen logischen Erweiterung vermeiden, da dieser Teil bereits bei der Verarbeitung einer früheren Operation behandelt wurde, und kann stattdessen nur die Teile der Operationsverarbeitung implementieren, die den Inhalt von Leaf- oder zusammengesetzten logischen Erweiterungen ändern. Es ist die Aufgabe des Leaders, sicherzustellen, dass die Transformationen miteinander kompatibel sind. Wir können zum Beispiel mit zwei Schreibvorgängen beginnen, die für einen Pod eingehen. Ein erster Schreibvorgang ersetzt eine zusammengesetzte logische Erweiterung A durch eine Kopie der als zusammengesetzte logische Erweiterung B gebildeten, ersetzt eine Leaf-logische Erweiterung C durch eine Kopie als Leaf-Iogische Erweiterung D und durch Modifikationen, um den Inhalt für den zweiten Schreibvorgang zu speichern, und schreibt weiter die Leaf-logische Erweiterung D in die zusammengesetzte logische Erweiterung B. Währenddessen impliziert ein zweiter Schreibvorgang dieselbe Kopie und den Ersatz der zusammengesetzten logischen Erweiterung A durch die zusammengesetzte logische Erweiterung B, kopiert und ersetzt jedoch eine andere Leaf-logische Erweiterung E durch eine logische Erweiterung F, die modifiziert wird, um den Inhalt des zweiten Schreibvorgangs zu speichern, und schreibt weiter die logische Erweiterung F in die logische Erweiterung B. In diesem Fall kann die Beschreibung des ersten Schreibens die Ersetzung von A durch B und C durch D und das Schreiben von D in die zusammengesetzte logische Erweiterung B und das Schreiben des Inhalts des ersten Schreibens in die Leaf-Erweiterung B umfassen; und die Beschreibung des zweiten Schreibens kann die Ersetzung von A durch B und E durch F und das Schreiben von F in die zusammengesetzte logische Erweiterung B zusammen mit dem Inhalt des zweiten Schreibens, das in die Leaf-Erweiterung F geschrieben wird, umfassen. Ein Leader oder ein beliebiger Follower kann dann die erste oder die zweite Schrift in beliebiger Reihenfolge getrennt verarbeiten, und das Endergebnis ist, dass B kopiert und A ersetzt, D kopiert und C ersetzt, F kopiert und E ersetzt und D und F in der zusammengesetzten logischen Erweiterung B geschrieben werden. Eine zweite Kopie von A in die Form B kann vermieden werden, indem man anerkennt, dass B bereits existiert. Auf diese Weise kann ein Leader sicherstellen, dass der Pod kompatible gemeinsame Metadaten für einen Graphen der logischen Erweiterung über In-Sync-Speichersysteme für einen Pod hinweg beibehält.
  • Bei einer Implementierung von Speichersystemen, die gerichtete azyklische Graphen mit logischen Erweiterungen verwenden, kann die Wiederherstellung von Pods auf der Grundlage replizierter gerichteter azyklischer Graphen mit logischen Erweiterungen implementiert werden. Konkret kann in diesem Beispiel die Wiederherstellung von Pods auf replizierten Erweiterungsgraphen basieren und beinhaltet dann die Wiederherstellung der Konsistenz dieser Graphen sowie die Wiederherstellung des Inhalts der logischen Erweiterungen der Leafs. Bei dieser Implementierung der Wiederherstellung können die Operationen das Abfragen von Graph-Transformationen umfassen, von denen nicht bekannt ist, dass sie auf allen In-Sync-Speichersystemen für einen Pod abgeschlossen wurden, sowie alle Inhaltsänderungen der logischen Erweiterung von Leafs, von denen nicht bekannt ist, dass sie auf allen Speichersystemen für den Pod abgeschlossen wurden. Solche Abfragen könnten auf Operationen seit irgendeinem koordinierten Kontrollpunkt basieren oder einfach Operationen sein, von denen nicht bekannt ist, dass sie abgeschlossen sind, wobei jedes Speichersystem eine Liste von Operationen während des normalen Betriebs führt, die noch nicht als abgeschlossen signalisiert wurden. In diesem Beispiel sind Graph-Transformationen unkompliziert: Eine Graph-Transformation kann neue Dinge erzeugen, alte Dinge auf neue Dinge kopieren und alte Dinge in zwei oder mehr geteilte neue Dinge kopieren, oder sie modifizieren zusammengesetzte Erweiterungen, um ihre Referenzen auf andere Erweiterungen zu modifizieren. Jede gespeicherte Operationsbeschreibung, die auf einem beliebigen In-Sync-Speichersystem gefunden wird und eine logische Erweiterung erzeugt oder ersetzt, kann kopiert und auf jedem anderen Speichersystem ausgeführt werden, das diese logische Erweiterung noch nicht hat. Operationen, die Modifikationen von Leaf- oder zusammengesetzten logischen Erweiterungen beschreiben, können diese Modifikationen auf jedes In-Sync Speichersystem anwenden, das sie noch nicht angewendet hat, solange die betroffenen Leaf- oder zusammengesetzten logischen Erweiterungen ordnungsgemäß wiederhergestellt wurden.
  • In einem anderen Beispiel kann als Alternative zur Verwendung eines logischen Erweiterungsgraphen die Speicherung auf der Grundlage eines replizierten inhalts-adressierbaren Speichers implementiert werden. In einem inhalts-adressierbaren Speicher wird für jeden Datenblock (z.B. alle 512 Bytes, 4096 Bytes, 8192 Bytes oder sogar 16384 Bytes) ein eindeutiger Hash-Wert (manchmal auch als Fingerprint bezeichnet) auf der Grundlage des Blockinhalts berechnet, so dass ein Datenträger oder ein Erweiterungsbereich eines Datenträgers als eine Liste von Verweisen auf Blöcke beschrieben werden kann, die einen bestimmten Hash-Wert haben. In einer synchron replizierten Speichersystemimplementierung, die auf Verweisen auf Blöcke mit demselben Hash-Wert basiert, könnte die Replikation beinhalten, dass ein erstes Speichersystem Blöcke empfängt, Fingerprints für diese Blöcke berechnet, Blockreferenzen für diese Fingerprints identifiziert und Änderungen an ein oder mehrere zusätzliche Speichersysteme als Aktualisierungen der Zuordnung von Datenträgerblöcken zu referenzierten Blöcken liefert. Wenn sich herausstellt, dass ein Block bereits vom ersten Speichersystem gespeichert wurde, kann dieses Speichersystem seine Referenz verwenden, um die Referenz in jedem der zusätzlichen Speichersysteme zu benennen (entweder weil die Referenz denselben Hash-Wert verwendet oder weil ein Identifizierer für die Referenz entweder identisch ist oder leicht abgebildet werden kann). Wenn ein Block vom ersten Speichersystem nicht gefunden wird, kann alternativ der Inhalt des ersten Speichersystems als Teil der Operationsbeschreibung zusammen mit dem Hash-Wert oder der Identität, die mit diesem Blockinhalt verbunden ist, an andere Speichersysteme geliefert werden. Ferner werden dann die Datenträgerbeschreibungen jedes In-Sync-Speichersystems mit den neuen Blockreferenzen aktualisiert. Die Wiederherstellung in einem solchen Speicher kann dann den Vergleich kürzlich aktualisierter Blockreferenzen für einen Datenträger umfassen. Wenn sich Blockreferenzen zwischen verschiedenen In-Sync Speichersystemen für einen Pod unterscheiden, kann eine Version jedes Verweises auf andere Speichersysteme kopiert werden, um sie konsistent zu machen. Wenn die Blockreferenz auf einem System nicht vorhanden ist, kann sie von einem Speichersystem kopiert werden, das einen Block für diese Referenz speichert. Virtuelle Kopiervorgänge können in einem solchen Block- oder Hash-Referenzspeicher unterstützt werden, indem die Verweise als Teil der Implementierung des virtuellen Kopiervorgangs kopiert werden.
  • Wie vorstehend beschrieben, können Metadaten zwischen Speichersystemen synchronisiert werden, die einen Datensatz synchron replizieren. Solche Metadaten können als gemeinsame Metadaten oder gemeinsam genutzte Metadaten bezeichnet werden, die von einem Speichersystem für einen Pod gespeichert werden und sich auf die Zuordnung von Inhaltssegmenten, die innerhalb des Pods gespeichert sind, zu virtuellen Adressen innerhalb von Speicherobjekten innerhalb des Pods beziehen, wobei Informationen in Bezug auf diese Zuordnungen zwischen den Speichersystemen der Elemente für den Pod synchronisiert werden, um ein korrektes Verhalten - oder eine bessere Leistung - für Speicheroperationen in Bezug auf den Pod zu gewährleisten. In einigen Beispielen kann ein Speicherobjekt einen Datenträger oder einen Snapshot implementieren. Zu den synchronisierten Metadaten können gehören: (a) Informationen, um die Zuordnungen der Volume-Inhalte zwischen den Speichersystemen im Pod synchronisiert zu halten; (b) Verfolgungsdaten für Wiederherstellungskontrollpunkte oder für laufende Schreiboperationen; (c) Informationen im Zusammenhang mit der Bereitstellung von Daten und Zuordnungsinformationen zu einem entfernten Speichersystem für asynchrone oder periodische Replikation.
  • Informationen zur Synchronisierung der Zuordnungen von Volume-Inhalten zwischen den Speichersystemen im Pod können die effiziente Erstellung von Snapshots ermöglichen, was wiederum ermöglicht, dass nachfolgende Aktualisierungen, Kopien von Snapshots oder das Entfernen von Snapshots effizient und konsistent über die Speichersysteme der Pod-Elemente hinweg durchgeführt werden können.
  • Das Verfolgen von Daten für Wiederherstellungskontrollpunkte oder für laufende Schreibvorgänge kann eine effiziente Absturz-Wiederherstellung und eine effiziente Erkennung von Inhalts- oder Volume-Zuordnungen ermöglichen, die auf einzelnen Speichersystemen für einen Pod teilweise oder vollständig angewendet wurden, die jedoch auf anderen Speichersystemen für den Pod möglicherweise nicht vollständig angewendet wurden.
  • Informationen, die sich auf die Bereitstellung von Daten und Abbildungsinformationen an ein entferntes Speichersystem für die asynchrone oder periodische Replikation beziehen, können es ermöglichen, dass mehr als ein Element Speichersystem für einen Pod als Quelle für den replizierten Pod-Inhalt dienen kann, wobei minimale Bedenken hinsichtlich des Umgangs mit Unstimmigkeiten bei den Abbildungs- und Vergleichsmetadaten bestehen, die zur Steuerung der asynchronen oder periodischen Replikation verwendet werden.
  • In einigen Beispielen können gemeinsam genutzte Metadaten Beschreibungen oder Hinweise auf eine benannte Gruppierung oder Identifikatoren für einen oder mehrere Datenträger oder ein oder mehrere Speicherobjekte enthalten, die eine Teilmenge eines gesamten synchron replizierten Datensatzes für einen Pod darstellen - wobei eine solche Gruppe von Datenträgern oder Speicherobjekten eines Datensatzes als Konsistenzgruppe bezeichnet werden kann. Eine Konsistenzgruppe kann definiert werden, um eine Teilmenge von Datenträgern oder Speicherobjekten des Datensatzes anzugeben, die für konsistente Snapshots, asynchrone Replikation oder periodische Replikation verwendet werden soll. In einigen Beispielen kann eine Konsistenzgruppe dynamisch berechnet werden, z. B. durch Einbeziehung aller Datenträger, die mit einem bestimmten Satz von Hosts oder Host-Netzwerk-Ports verbunden sind oder die mit einem bestimmten Satz von Anwendungen oder virtuellen Maschinen oder Containern verbunden sind, wobei die Anwendungen, virtuellen Maschinen oder Container auf externen Serversystemen oder auf einem oder mehreren der Speichersysteme, die Elemente eines Pod sind, betrieben werden können. In anderen Beispielen kann eine Konsistenzgruppe nach der Auswahl eines Datentyps oder einer Datenmenge durch den Benutzer oder nach den Spezifikationen einer Konsistenzgruppe ähnlich der dynamischen Berechnung definiert werden, wobei ein Benutzer z.B. über eine Befehls- oder Betriebskonsole festlegen kann, dass eine bestimmte oder benannte Konsistenzgruppe erstellt wird, die alle mit einer bestimmten Menge von Hosts oder Host-Netzwerk-Ports verbundenen Datenträger einschließt, oder die erstellt wird, um Daten für eine bestimmte Menge von Anwendungen oder virtuellen Maschinen oder Containern einzuschließen.
  • In einem Beispiel mit einer Konsistenzgruppe kann ein erster Konsistenzgruppen-Snapshot einer Konsistenzgruppe einen ersten Satz von Snapshots für alle Datenträger oder andere Speicherobjekte enthalten, die zum Zeitpunkt des ersten Datensatz-Snapshots Elemente der Konsistenzgruppe sind, während ein zweiter Konsistenzgruppen-Snapshot der gleichen Konsistenzgruppe einen zweiten Satz von Snapshots für die Datenträger oder andere Speicherobjekte enthält, die zum Zeitpunkt des zweiten Datensatz-Snapshots Elemente der Konsistenzgruppe sind. In anderen Beispielen kann ein Snapshot des Datenbestands auf einem oder mehreren Zielspeichersystemen asynchron gespeichert werden. In ähnlicher Weise kann die asynchrone Replikation einer Konsistenzgruppe dynamische Änderungen an Elemente-Datenträger und anderen Speicherobjekten der Konsistenzgruppe berücksichtigen, wobei Konsistenzgruppen-Snapshots der Konsistenzgruppe entweder an der Quelle oder am Ziel der Verknüpfung für die asynchrone Replikation die Datenträger und anderen Speicherobjekte enthalten, die zum Zeitpunkt, auf den sich der Datensatz-Snapshot bezieht, Elemente der Konsistenzgruppe sind. Im Falle eines Ziels einer asynchronen Replikationsverbindung hängt die Zeit, auf die sich der Datenbestand-Snapshot bezieht, von dem dynamischen Datenbestand des Senders ab, wie er empfangen wurde und zum Zeitpunkt des Konsistenzgruppen-Snapshots in Bearbeitung auf dem Ziel war. Wenn z.B. ein Ziel einer asynchronen Replikation z.B. 2000 Operationen zurückliegt, wobei einige dieser Operationen Änderungen von Konsistenzgruppen-Elementen sind, wobei ein erster Satz solcher Änderungen für die Quelle mehr als 2000 Operationen zurückliegt und ein zweiter Satz von Änderungen innerhalb der letzten 2000 liegt, dann berücksichtigt ein Konsistenzgruppen-Snapshot zu diesem Zeitpunkt auf dem Ziel den ersten Satz von Elemente-Änderungen und nicht den zweiten Satz von Änderungen. Andere Verwendungen des Ziels der asynchronen Replikation können in ähnlicher Weise die Art der Zeit des Datensatzes für die Konsistenzgruppe bei der Bestimmung der Datenträger oder anderer Speicherobjekte (und ihres Inhalts) für diese Verwendungen berücksichtigen. Wenn beispielsweise die asynchrone Replikation 2000 Operationen zurückliegt, kann die Verwendung des Ziels für einen Disaster-Recovery-Failover von einem Datensatz ausgehen, der die Datenträger und andere Speicherobjekte (und deren Inhalt) enthält, wie sie vor 2000 Operationen an der Quelle waren. In dieser Diskussion haben konkurrierende Operationen an der Quelle (z.B. Schreibvorgänge, Erstellen oder Löschen von Speicherobjekten, Änderungen an Eigenschaften, die sich auf das Einschließen oder Ausschließen von Datenträgern oder anderen Speicherobjekten oder anderen Daten aus einer Konsistenzgruppe auswirken, oder andere Operationen, die im Gange waren und nicht als zu demselben Zeitpunkt abgeschlossen signalisiert wurden) möglicherweise keine einzige genau definierte Reihenfolge, so dass die Anzahl der Operationen nur eine plausible Reihenfolge darstellen muss, die auf einer beliebigen zulässigen Reihenfolge von konkurrierenden Operationen an der Quelle basiert.
  • Ein weiteres Beispiel für die Verwendung von Konsistenzgruppen: Bei einer periodischen Replikation, die auf der Replikation von Konsistenzgruppen-Snapshots basiert, würde jeder replizierte Konsistenzgruppen-Snapshot die Datenträger und andere Speicherobjekte zum Zeitpunkt der Erstellung jedes Konsistenzgruppen-Snapshots auf der Quelle enthalten. Die Gewährleistung der Konsistenz der Zugehörigkeit in einer Konsistenzgruppe durch die Verwendung gemeinsamer oder gemeinsam genutzter Metadaten stellt sicher, dass bei einer Fehler- oder sonstigen Änderung, die dazu führen kann, dass die Quelle der Replikation oder das System, das eine Datensatz-Momentaufnahme erstellt, von einem Speichersystem in einem Pod zu einem anderen wechselt, keine Informationen verloren gehen, die für die ordnungsgemäße Handhabung dieser Konsistenzgruppen-Momentaufnahmen oder der Konsistenzgruppen-Replikation benötigt werden. Außerdem kann diese Art der Handhabung es ermöglichen, dass mehrere Speichersysteme, die Elemente eines Pods sind, gleichzeitig als Quellsysteme für die asynchrone oder periodische Replikation dienen.
  • Darüber hinaus sind synchronisierte Metadaten, die das Abbilden von Segmenten auf Speicherobjekte beschreiben, nicht auf das Abbilden selbst beschränkt und können zusätzliche Informationen wie Sequenznummern (oder einen anderen Wert zur Identifizierung gespeicherter Daten), Zeitstempel, Datenträger/Snapshot-Beziehungen, Checkpoint-Identitäten, Bäume oder Diagramme, die Hierarchien definieren, oder gerichtete Diagramme von Mapping-Beziehungen neben anderen Speichersysteminformationen enthalten.
  • Zur weiteren Erläuterung ist in 8 ein Flussdiagramm dargestellt, das eine Beispielmethode für die Vermittlung zwischen Speichersystemen veranschaulicht, die einen Datensatz gemäß einigen Ausführungsformen der vorliegenden Offenbarung synchron replizieren. Obwohl die in 8 dargestellte Beispielmethode eine Ausführungsform veranschaulicht, in der ein Datensatz (426) synchron über nur zwei Speichersysteme (814, 824) repliziert wird, kann das in 8 dargestellte Beispiel auf Ausführungsformen erweitert werden, in denen der Datensatz (426) synchron über weitere Speichersysteme repliziert wird.
  • In den folgenden Beispielen ermöglicht die Vermittlung zwischen einer Reihe von Speichersystemen (814, 824) für einen Pod den Speichersystemen, die verlorene Kommunikation mit einem gekoppelten System aufzuheben, bei dem die Kommunikation aufgrund von Kommunikationsfehlern oder einer anderen Art von Systemfehler verloren gehen kann. Wie unten beschrieben, können Lösungen für die Vermittlung die Verwendung von Queren und eines externen Steuersystems umfassen, das vorschreibt, welches der Speichersysteme die Verarbeitung von E/A-Operationen, die an einen Pod-Datensatz gerichtet sind, fortsetzen soll, sowie das Race um eine Ressource wie einen Vermittler. Ein Vorteil der Vermittlung ist jedoch, dass sie einfacher ist als Quorum-Protokolle, und die Vermittlung funktioniert gut mit einer Konfiguration mit zwei Speichersystemen für synchron replizierte Speichersysteme, was eine übliche Konfiguration ist. Darüber hinaus kann die Vermittlung robuster und einfacher zu konfigurieren sein als externe Kontrollsysteme und viele andere Arten von Ressourcen, gegen die ein Race stattfinden kann.
  • Wie in 8 dargestellt, können mehrere Speichersysteme (814, 824), die einen Datensatz (426) synchron replizieren, über ein Netzwerk (854) mit einem Vermittlerdienst (800) kommunizieren, wobei ein Vermittlerdienst (800) bei einem Kommunikationsfehler zwischen Speichersystemen, bei einem Ausfall eines Speichersystems oder aufgrund eines anderen auslösenden Ereignisses entscheiden kann, welches Speichersystem den Datensatz weiterhin bedient. Eine Vermittlung ist vorteilhaft, denn wenn die Speichersysteme nicht in der Lage sind, miteinander zu kommunizieren, können sie möglicherweise keinen synchron replizierten Datensatz aufrechterhalten, und alle empfangenen Anfragen zur Änderung eines Datensatzes wären unbrauchbar, weil der Datensatz sonst unsynchronisiert würde. In diesem Beispiel können Vermittlerdienste für Speichersysteme, die einen Datensatz synchron replizieren, von einem Vermittlerdienst (800) bereitgestellt werden, der sich außerhalb der Speichersysteme befindet (814, 824). Während in diesem Beispiel nur zwei Speichersysteme (814, 824) dargestellt sind, kann im Allgemeinen eine andere Anzahl von zwei oder mehr Speichersystemen Teil einer In-Sync-Liste sein, die einen Datensatz synchron repliziert. Insbesondere wenn ein erstes Speichersystem (814) ein auslösendes Ereignis, wie den Verlust einer Kommunikationsverbindung (816) zu einem zweiten Speichersystem (824), festgestellt hat, kann das erste Speichersystem (814) einen externen Vermittlerdienst (800) kontaktieren, um festzustellen, ob es die Aufgabe, das nicht kommunizierende Speichersystem aus einer In-Sync-Liste zu entfernen, die die Speichersysteme angibt, die in Bezug auf die Replikation eines Datensatzes synchronisiert sind, sicher übernehmen kann. In anderen Fällen kann das erste Speichersystem (814) den externen Vermittlerdienst (800) kontaktieren und feststellen, dass es - das erste Speichersystem (814) - möglicherweise von einem zweiten Speichersystem aus der In-Sync-Liste entfernt worden ist. In diesen Beispielen müssen die Speichersysteme (814, 824) nicht in ständiger Kommunikation mit dem externen Vermittlerdienst (800) stehen, da die Speichersysteme (814, 824) unter normalen Bedingungen keine Informationen vom Vermittlerdienst (800) benötigen, um normal zu funktionieren und die synchrone Replikation eines Datensatzes aufrechtzuerhalten (426). Mit anderen Worten, in diesem Beispiel hat der Vermittlerdienst (800) möglicherweise keine aktive Rolle bei der Elemente-Verwaltung einer Synchronisierungsliste, und darüber hinaus ist dem Vermittlerdienst (800) möglicherweise nicht einmal der normale Betrieb der Speichersysteme (814, 824) in der Synchronisierungsliste bekannt. Stattdessen kann der Vermittlerdienst (800) einfach dauerhafte Informationen bereitstellen, die von den Speichersystemen (814, 824) verwendet werden, um die Zugehörigkeit in einer Synchronisierungsliste zu bestimmen oder um festzustellen, ob ein Speichersystem ein anderes Speichersystem abtrennen kann.
  • In einigen Beispielen kann ein Vermittlerdienst (800) von einem oder mehreren Speichersystemen (814, 824) als Reaktion auf ein auslösendes Ereignis wie einen Ausfall der Kommunikationsverbindung kontaktiert werden, der die Speichersysteme (814, 824) daran hindert, miteinander zu kommunizieren; jedoch kann jedes Speichersystem (814, 824) in der Lage sein, mit dem Vermittlerdienst (800) über einen Kommunikationskanal zu kommunizieren, der sich von dem zwischen den Speichersystemen (814, 824) verwendeten Kommunikationskanal unterscheidet. Folglich können die Speichersysteme (814, 824) zwar nicht miteinander kommunizieren, aber jedes der Speichersysteme (814, 824) kann immer noch mit dem Vermittlerdienst (800) kommunizieren, wobei die Speichersysteme (814, 824) den Vermittlerdienst (800) benutzen können, um zu entscheiden, welches Speichersystem Datenspeicheranfragen bearbeiten kann. Ferner kann das Speichersystem, das die Vermittlung durch den Vermittlerdienst (800) gewinnt, ein anderes Speichersystem abtrennen und eine In-Sync-Liste aktualisieren, die die Speichersysteme angibt, die weiterhin einen Datensatz synchron replizieren können (426). In einigen Beispielen kann ein Vermittlerdienst (800) verschiedene Arten von Anfragen bearbeiten, wie z.B. eine Anfrage zur Erstellung einer Elemente-Liste, die ein Speichersystem des Anfragenden einschließt und ein anderes Speichersystem ausschließt. In diesem Beispiel wird ein Antrag erfolgreich abgeschlossen, wenn der Vermittlerdienst (800) den Antragsteller derzeit als Element auflistet, und der Antrag schlägt fehl, wenn der Vermittlerdienst (800) den Antragsteller derzeit nicht als Element auflistet. Auf diese Weise kann, wenn zwei Speichersysteme (814, 824) jeweils ungefähr gleichzeitig Anträge stellen, wobei die Anträge dazu dienen, das andere auszuschließen, der erste eingegangene Antrag erfolgreich sein - wobei der Vermittlerdienst die Elemente-Liste so einstellt, dass das andere Speichersystem gemäß dem ersten Antrag ausgeschlossen wird - und der zweite eingegangene Antrag kann fehlschlagen, weil die Elemente-Liste so eingestellt wurde, dass das andere Speichersystem ausgeschlossen wird. Der sich gegenseitig ausschließende Zugriff auf eine gemeinsam genutzte Ressource, die eine Elemente-Liste speichert, dient dazu sicherzustellen, dass nur ein einziges System als Zeiteinheit für das Setzen einer Elemente-Liste zugelassen wird.
  • In einem anderen Beispiel kann die Vermittlung auf einer Partitionskennung basieren, wobei ein Wert definiert werden kann, der eine Partitionskennung der Pod-Zugehörigkeit angibt, um geltend zu machen, dass die Zugehörigkeit einen bestimmten Satz von Speichersystemen von einem Pod abgetrennt oder entfernt hat. Ein „Pod“, wie der Begriff hier und im Rest der vorliegenden Anwendung verwendet wird, kann als eine Betriebseinheit verkörpert sein, die einen Datensatz, einen Satz verwalteter Objekte und Betriebsoperationen, einen Satz von Zugriffsoperationen zum Ändern oder Lesen des Datensatzes und eine Vielzahl von Speichersystemen repräsentiert. Solche Betriebsoperationen können verwaltete Objekte äquivalent über jedes der Speichersysteme modifizieren oder abfragen, wobei Zugriffsoperationen zum Lesen oder Modifizieren des Datensatzes äquivalent über jedes der Speichersysteme erfolgen. Jedes Speichersystem kann eine separate Kopie des Datensatzes als eine geeignete Teilmenge der gespeicherten und zur Verwendung durch das Speichersystem beworbenen Datensätze speichern, wobei Operationen zur Modifizierung verwalteter Objekte oder des Datensatzes, die über ein beliebiges Speichersystem durchgeführt und abgeschlossen werden, in nachfolgenden Betriebsobjekten zur Abfrage des Pod oder in nachfolgenden Zugriffsoperationen zum Lesen des Datensatzes reflektiert werden. Weitere Einzelheiten zu einem „Pod“ finden sich in der zuvor eingereichten provisorischen Patentanmeldung Nr. 62/518.071 , die hierin durch Verweis aufgenommen wird.
  • Eine Partitionskennung kann eine lokale Information sein, die auf einem bestimmten Speichersystem zusätzlich zu dem Speichersystem gespeichert ist, auf dem eine Pod-Elemente-Liste gespeichert ist. Systeme, die ordnungsgemäß miteinander kommunizieren und synchronisiert sind, können dieselbe Partitionskennung aufweisen, und wenn Speichersysteme zu einem Pod hinzugefügt werden, kann die aktuelle Partitionskennung zusammen mit dem Pod-Dateninhalt kopiert werden. Wenn in diesem Beispiel ein Satz von Speichersystemen nicht mit einem anderen Satz von Speichersystemen kommuniziert, kann ein Speichersystem aus jedem Satz mit einer neuen und eindeutigen Partitionskennung aufwarten und versuchen, diese in der gemeinsam genutzten Ressource, die vom Vermittlerdienst (800) verwaltet wird, zu setzen, indem eine bestimmte Operation verwendet wird, die für ein Speichersystem erfolgreich ist, das zuerst eine Sperre auf der gemeinsam genutzten Ressource erfasst, wenn ein anderes Speichersystem - das keine Sperre auf der gemeinsam genutzten Ressource erfassen konnte - einen Versuch zur Durchführung der bestimmten Operation scheitert. In einer Implementierung kann eine atomare Compare-and-set-Operation verwendet werden, bei der der letzte vom Vermittlerdienst (800) gespeicherte Wert der Partitionskennung von einem Speichersystem bereitgestellt werden kann, um die Erlaubnis zu erhalten, die Partitionskennung auf einen neuen Wert zu ändern. In diesem Beispiel kann eine Compare-and-set-Operation für ein Speichersystem erfolgreich sein, das den aktuellen Partitionskennungswert kennt, wobei ein Speichersystem, das den Partitionskennungswert zuerst setzt, das Speichersystem wäre, das den aktuellen Partitionskennungswert kennt. Darüber hinaus kann eine Conditional-Store- oder eine PUT-Operation, die in Web-Service-Protokollen verfügbar sein kann, den Partitionskennungswert wie in diesem Beispiel beschrieben einstellen. In anderen Fällen, z.B. in einer SCSI-Umgebung, kann eine Compare-and-write-Operation verwendet werden. In noch anderen Fällen kann der Vermittlerdienst (800) die Compare-and-set-Operation durch Empfangen einer Anforderung von einem Speichersystem durchführen, wobei die Anforderung einen alten Partitionskennungswert und auch einen neuen Partitionskennungswert angibt und wobei der Vermittlerdienst (800) die gespeicherte Partitionskennung auf den neuen Partitionskennungswert ändert, wenn und nur wenn der gegenwärtig gespeicherte Wert gleich der alten Partitionskennung ist.
  • Auf diese Weise kann die auf einer Partitionskennung basierende Vermittlung dazu verwendet werden, Informationen zu persistieren, die von Speichersystemen verwendet werden können, um festzustellen, ob ein bestimmtes Speichersystem in einem partitionierten Off-Set konsistenter Pod-Elemente enthalten ist oder nicht. In einigen Fällen kann sich eine Partitionskennung nur im Falle einer spontanen Abtrennung aufgrund eines Fehlers in einem Speichersystem oder einer Netzverbindung ändern. In diesen Beispielen kann ein Speichersystem, das sich für einen Pod auf kontrollierte Weise offline schaltet, mit anderen Speichersystemen kommunizieren, um sich selbst als in-sync Pod-Element zu entfernen, so dass die Bildung einer vermittelten neuen Partitionskennung nicht erforderlich ist. Weiterhin kann ein Speichersystem, das sich selbst als Element eines In-Sync-Pods entfernt, sich dann auf eine kontrollierte Weise, die keine vermittelte neue Partitionskennung erfordert, wieder als In-Sync-Pod-Element hinzufügen. Darüber hinaus kann ein neues Speichersystem dem In-Sync-Pod hinzugefügt werden, solange die Speichersysteme mit In-Sync-Pod-Elementen kommunizieren, wobei die neuen Speichersysteme sich selbst auf eine kontrollierte Weise hinzufügen können, die keine vermittelte neue Partitionskennung erfordert.
  • Folglich besteht ein Vorteil des Identifizierungsmechanismus für vermittelte Partitionen darin, dass der Vermittlerdienst (800) nur dann erforderlich sein kann, wenn ein Fehler oder ein anderes auslösendes Ereignis vorliegt, auf das mindestens ein Satz von Speichersystemen reagiert, indem er versucht, ein oder mehrere nicht kommunizierende Speichersysteme aus der In-Sync-Pod-Elemente-Liste zu entfernen, wobei die nicht kommunizierenden Speichersysteme versuchen können, dasselbe zu tun, aber in umgekehrter Richtung. Ein weiterer Vorteil besteht darin, dass ein Vermittlerdienst (800) unter Umständen nicht absolut zuverlässig ist und nur geringe Auswirkungen auf die Verfügbarkeit des gesamten von den Elementen des In-Sync-Pods angebotenen Speicherdienstes hat. Wenn beispielsweise zwei synchron replizierte Speichersysteme jeweils einmal pro Jahr ausfallen, sollte das zweite Speichersystem erfolgreich vermitteln, um das erste Speichersystem zu entfernen, es sei denn, der Vermittlerdienst (800) ist genau in dem Moment nicht verfügbar, in dem ein erstes der beiden Speichersysteme ausfällt. Kurz gesagt, wenn der Vermittlerdienst (800) zu mindestens 99% der Zeit verfügbar ist, wird die Wahrscheinlichkeit, dass der Vermittlerdienst (800) bei Bedarf nicht verfügbar ist, äußerst gering. In diesem Beispiel läge die Wahrscheinlichkeit nur bei 1 von 100 (1 % oder weniger), dass der Vermittlerdienst (800) zu einem kritischen Zeitpunkt nicht zur Verfügung steht, was einen einmaligen Ausfall pro Jahr auf einen einmaligen Ausfall pro Jahrhundert reduzieren kann. Um die Wahrscheinlichkeit der Nichtverfügbarkeit eines Vermittlerdienstes (800) zu verringern, kann der Vermittlerdienst (800) jedoch in regelmäßigen Abständen überwacht werden, um einen Administrator zu alarmieren, wenn ein Vermittlerdienst nicht allgemein verfügbar ist, wobei der Vermittlerdienst (800) auch Speichersysteme überwachen kann, um eine Warnung zu generieren, falls ein bestimmtes Speichersystem nicht verfügbar ist.
  • In einem anderen Beispiel kann der Vermittlerdienst (800) als Alternative zur Verwendung einer Partitionskennung, die mit In-Sync-Elementen für einen Pod verbunden ist, ein einmaliges Ziel für ein Vermittler-Race bieten. Konkret kann jedes Mal, wenn die Speichersysteme der In-Sync-Elemente für einen Pod die Möglichkeit einkalkulieren müssen, dass ein Speichersystem von anderen getrennt werden kann, ein Ziel für ein Vermittler-Race festgelegt werden. Zum Beispiel kann ein vereinbarter Schlüssel in einer Tabelle mit Vermittlerwerten einmal auf einen neuen Wert gesetzt werden, wobei ein Speichersystem, um die Vermittlung zu gewinnen, den vereinbarten Schlüssel auf einen eindeutigen Wert setzt, den kein anderes separates Race-Speichersystem verwenden würde. Vor dem Vermittler-Race existiert der vereinbarte Schlüssel möglicherweise nicht, oder wenn er existiert, kann er auf einen vereinbarten Vorläuferwert, wie z.B. einen UNSET- oder Nullwert, gesetzt werden. In diesem Beispiel ist eine Operation zum Setzen des Schlüssels auf einen bestimmten Wert erfolgreich, wenn der Schlüssel nicht existiert, wenn sich der Schlüssel im Zustand UNSET befindet oder wenn der Schlüssel auf einen Wert gesetzt wird, der einem aktuellen Wert entspricht - andernfalls schlägt die Operation zum Setzen des Schlüssels fehl. Sobald eine Gruppe von Speichersystemen die Vermittlung gewinnt, kann die verbleibende Gruppe von Speichersystemen einen neuen Schlüssel definieren, der für zukünftige Vermittlungen verwendet werden kann. In diesem Beispiel kann ein Speichersystem den Wert aufzeichnen, den es vor dem Vermittler-Race verwendet, so dass das Speichersystem den Wert erneut verwenden kann, wenn es einen Fehler aufweist und sich erholt oder neu startet, bevor es erfährt, dass es das Vermittler-Race möglicherweise gewonnen hat. Wenn zwei oder mehr Speichersysteme miteinander kommunizieren und zusammen gegen eine andere Gruppe von Speichersystemen antreten, die nicht kommunizieren, kann dieser Wert an das andere kommunizierende Speichersystem weitergegeben werden, so dass jedes von ihnen das Vermittler-Race fortsetzen und nach einer zusätzlichen Fehlerfolge vielleicht ein zweites Vermittler-Race starten kann. Zum Beispiel kann es für die Korrektheit notwendig sein, vor dem Race um einen eindeutigen Wert für ein zweites Ziel des Vermittler-Race das erste Ziel des Vermittler-Race anzustreben oder zu validieren. Insbesondere kann diese Sequenz so lange erforderlich sein, bis ein zweites Ziel des Vermittler-Race zuverlässig an alle Speichersysteme verteilt ist, die das erste Ziel des Vermittler-Race gemeinsam haben, und alle Speichersysteme darauf aufmerksam gemacht werden, dass es zuverlässig verteilt worden ist. Zu diesem Zeitpunkt ist es unter Umständen nicht mehr notwendig, zuerst das erste Ziel des ersten Vermittler-Race zu erreichen, bevor das zweite Ziel des Vermittler-Race erreicht wird.
  • In einigen Beispielen kann ein Vermittlerdienst (800) auf Computersystemen verwaltet werden, die von einer anderen Organisation als einer Organisation oder einem Eigentümer der vermittelten Speichersysteme bereitgestellt werden. Wenn z.B. ein Anbieter zwei Speichersysteme an einen Kunden verkauft, kann der Anbieter die Vermittler auf Servern hosten, die in anbietereigenen oder verwalteten Rechenzentren bereitgestellt werden, oder der Anbieter kann einen Vertrag mit einem Cloud-Dienst-Anbieter schließen, um den Dienst zu hosten. Ein Anbieter kann auch sicherstellen, dass der Vermittlerdienst hinreichend zuverlässig ist und sich von allen Fehlerzonen des Kunden unterscheidet. In einem Fall, ohne andere Cloud-Dienst-Anbieter auszuschließen, kann der Vermittlerdienst bei Amazon Web Services™ gehostet werden, und der Vermittlerdienst kann mit DynamoDB für einen zuverlässigen Datenbankservice implementiert werden, wobei DynamoDB Unterstützung für Conditional-Store-Primitive als Web-API-Datenbank-Updates bereitstellen kann. In einigen Fällen kann ein Vermittlerdienst so implementiert werden, dass er über mehrere Regionen oder Fehlerzonen von Anbietern von Cloud-Diensten funktioniert, um die Zuverlässigkeit weiter zu verbessern. Ein Vorteil der Verwendung eines Anbieters zur Bereitstellung von Vermittlerdiensten besteht darin, dass der Vermittlerdienst einfach zu konfigurieren ist. Darüber hinaus kann ein Speichersystem während der Erstellung eines Pod ein kryptographisches Token vom Vermittlerdienst erhalten und das kryptographische Token zusätzlich zur Speicherung einer Partitionskennung und einer Pod-Zugehörigkeitsliste speichern - wobei das kryptographische Token zur sicheren Kommunikation der eindeutigen Vermittlerdienstinformationen für einen Pod verwendet werden kann.
  • In einigen Fällen kann es vorkommen, dass der Vermittlerdienst (800) nicht verfügbar ist, wenn ein Speichersystem versucht, zu vermitteln, und die folgende Methode bietet einen Prozess, um sich zumindest letztendlich von einem solchen Dienstausfall zu erholen. Wenn beispielsweise eine erste Gruppe von Speichersystemen versucht, eine zweite Gruppe von Speichersystemen über einen Vermittlerdienst abzulösen, die erste Gruppe von Speichersystemen jedoch nicht mit dem Vermittlerdienst (800) kommunizieren kann, dann kann die erste Gruppe von Speichersystemen den Ablösevorgang nicht abschließen und den Pod nicht weiter bedienen. In einigen Fällen, wenn es den beiden Sätzen von Speichersystemen gelingt, sich wieder miteinander zu verbinden, so dass alle in-sync-Speichersysteme wieder miteinander kommunizieren, der Vermittlerdienst (800) aber immer noch nicht verfügbar ist, können sich die beiden Sätze von Speichersystemen synchronisieren und die Versorgung dem Pod wieder aufnehmen. In diesem Beispiel könnten jedoch eine oder mehrere Anfragen an den Vermittlerdienst (800) gesendet worden sein, um die Partitionskennung oder andere mit der Vermittlung verbundene Eigenschaften zu ändern, und keines der Speichersysteme kann sicher sein, ob eine Anfrage empfangen und verarbeitet wurde oder nicht, wobei eine bestätigende Antwort verloren gegangen sein könnte. Infolgedessen kann bei einer Reihe von fehlerhaften Speichersystemen oder Netzwerkverbindungen kein Speichersystem sicher sein, welchen Wert für die Partitionskennung geltend zu machen ist, wenn und wann der Vermittlerdienst (800) wieder online geht. In einem solchen Szenario ist es vorzuziehen, dass der Pod-Dienst entweder dann wieder aufgenommen wird, wenn alle In-Sync-Speichersysteme wieder online sind und die Kommunikation wieder aufgenommen wird, oder wenn ein In-Sync-Speichersystem wieder eine Verbindung zum Vermittlerdienst (800) herstellen kann. In einer Implementierung tauschen alle In-Sync-Speichersysteme - wenn alle In-Sync-Speichersysteme wieder verbunden sind - bekannte Partitionskennungswerte aus, die möglicherweise an den Vermittlerdienst (800) gesendet wurden. Wenn beispielsweise zwei Speichersysteme jeweils versucht haben, den Partitionskennungswert zu ändern, wobei ein Speichersystem versucht, die Partitionskennung z.B. in 1749137481890 zu ändern, und ein anderes Speichersystem versucht, die Partitionskennung z.B. in 87927401839 zu ändern, und der letzte bekannte Wert, der vom Vermittlerdienst (800) bestätigt wurde, 79223402936 war, dann kann der Vermittlerdienst (800) gegenwärtig jeden dieser drei Partitionskennungswerte speichern. Infolgedessen kann jeder künftige Versuch, die Vermittler-Partitionskennung auf einen neuen Wert zu ändern, einige oder alle dieser drei Partitionskennungen liefern, um die Authority für die Änderung zu erlangen. Darüber hinaus kann ein vierter Versuch, den Partitionskennungswert zu ändern, ebenfalls auf einen Fehler stoßen, was zu einem vierten Wert führt, der möglicherweise von jedem Speichersystem gespeichert werden muss, das später einen weiteren Vermittlerversuch unternimmt. Wenn ein Speichersystem den Wert der Partitionskennung des Vermittlerdienstes (800) erfolgreich ändert, kann dieses Speichersystem darüber hinaus die älteren Partitionskennungswerte von allen In-Sync-Speichersystemen und von allen Speichersystemen, die in Zukunft in-sync werden, bereinigen.
  • In einem anderen Beispiel kann ein Vermittlerdienst (800) auf der Grundlage eines eindeutigen Schlüssels vermitteln, der für jedes potenzielle zukünftige Race vereinbart wird. In einem solchen Fall können sich die In-Sync-Speichersysteme darauf einigen, einen neuen Schlüssel zu verwenden. Da ein neuer Schlüssel möglicherweise nicht auf allen Speichersystemen gleichzeitig atomar festgelegt wird, sollten alle Speichersysteme ihre alten Schlüssel und die Werte, die jedes Speichersystem bei einem früheren Vermittlerversuch festzulegen versuchte, beibehalten, bis alle In-Sync-Speichersysteme den neuen Schlüssel empfangen und aufzeichnen. In diesem Beispiel können alle früheren nicht gerasterten Schlüssel und alle früheren Schlüssel/Wert-Vermittlerversuche zwischen allen In-Sync-Speichersystemen für den Pod zirkulieren und auf jedem dieser Speichersysteme zusammen mit einem neuen Schlüssel, der für zukünftige Vermittlerversuche verwendet werden kann, aufgezeichnet werden. Für jeden früheren, nicht in dem Race befindlichen Schlüssel (den neuen Schlüssel nicht eingeschlossen) kann bei diesem Austausch auch ein einziger, vereinbarter Wert ausgewählt werden, den alle Systeme im Race um diesen Schlüssel verwenden können. Nachdem alle In-Sync-Speichersysteme für einen Pod alle diese Vermittlerschlüssel und -werte (und den neuen vereinbarten Schlüssel für jedes zukünftige Race) erhalten und aufgezeichnet haben, können die Speichersysteme im Pod dann vereinbaren, die älteren Schlüssel und Werte zugunsten des einzigen neuen Schlüssels zu verwerfen. Es ist zu beachten, dass zwei oder mehr Speichersysteme möglicherweise versucht haben, denselben Vermittlerschlüssel auf unterschiedliche Werte zu setzen, und alle diese Werte können aufgezeichnet werden. Wenn während des Prozesses des Austauschs oder Empfangens all dieser Vermittlerschlüssel und Schlüssel/Wertepaare für frühere Vermittlerversuche ein Fehler auftritt, dann haben einige Speichersysteme die neuen Vermittlerschlüssel und -werte möglicherweise nicht empfangen und aufgezeichnet, während andere dies möglicherweise getan haben. Wenn der Vermittlerdienst (800) verfügbar wird, bevor alle In-Sync-Speichersysteme für den Pod wieder miteinander verbunden werden können, kann eine Untergruppe von Speichersystemen für den Pod versuchen, den Vermittlerdienst (800) zu nutzen, um ein anderes Speichersystem vom Pod zu lösen. Um die Vermittlung zu gewinnen, kann ein Speichersystem versuchen, alle aufgezeichneten Schlüssel auf ihre aufgezeichneten Werte zu setzen, und wenn das funktioniert, den neuen Schlüssel dann auf einen eindeutigen Wert zu setzen. Wenn mehr als ein Wert für denselben Schlüssel aufgezeichnet wurde, dann ist dieser Schritt erfolgreich, wenn das Setzen eines dieser Werte erfolgreich ist. Wenn der erste Schritt (Setzen früherer Schlüssel) fehlschlägt oder der zweite Schritt (Setzen des neuen Schlüssels auf den neuen eindeutigen Wert) scheitert, dann können die an diesem Vermittlerversuch beteiligten Speichersysteme offline gehen (und den Wert beibehalten, den sie versucht haben, für den neuen Schlüssel zu setzen). Wenn beide Schritte erfolgreich sind, können die kommunizierenden Speichersysteme die nicht kommunizierenden Speichersysteme abtrennen und den Pod weiter bedienen. Als Alternative zum Austausch aller bisherigen Schlüssel und Werte kann ein Speichersystem nur die Schlüssel und Werte aufzeichnen, die es versucht hat, ohne Schlüssel und Werte aus anderen Speichersystemen gegen einen Pod auszutauschen. Wenn sich dann ein In-Sync-Speichersystem wieder mit anderen In-Sync-Speichersystemen für einen Pod verbindet (wobei es keinem gelungen ist, mit einem Vermittlerdienst zu interagieren), kann das In-Sync-Speichersystem einen neuen Vermittlerschlüssel austauschen und dann eine Bestätigung austauschen, dass sie beide den vereinbarten neuen Schlüssel erhalten und aufgezeichnet haben. Wenn ein Fehler den Austausch der Bestätigung verhindert, dann kann ein zukünftiger Vermittlerversuch (an einen jetzt verfügbaren Vermittlerdienst) durch ein Speichersystem, das den neuen Schlüssel nie erhalten hat, versuchen, seine früheren Schlüssel und Werte wieder geltend zu machen. Ein Speichersystem, das den neuen Schlüssel erhalten hatte, aber keinen Hinweis darauf erhalten hatte, dass alle Speichersysteme für den Pod den Schlüssel erhalten hatten, kann sowohl seine früheren Vermittlerschlüssel als auch einen Wert für den neuen Schlüssel geltend machen, wobei zuerst die früheren Schlüssel und dann der neue Schlüssel geltend gemacht werden. Dieser zukünftige Vermittlerversuch kann immer noch scheitern, und dann kann das Speichersystem wieder eine Verbindung zu anderen In-Sync-Speichersystemen herstellen und wieder unvollständig neue Schlüssel austauschen, was zu einem anderen Schlüssel führt. Dadurch wird ein weiterer Schlüssel hinzugefügt. Da sich die Schlüssel im Laufe der Zeit mit einer Reihe unvollständiger Austauschvorgänge neuer Schlüssel ansammeln, kann es vorkommen, dass bei künftigen Vermittlerversuchen eines Speichersystems jeder seiner Schlüssel zusammen mit allen Werten, die es zuvor für diese Schlüssel geltend gemacht hat, in der Reihenfolge, in der sie aufgezeichnet wurden, erneut geltend gemacht wird, bis es erfolgreich einen Wert für alle Schlüssel geltend macht oder bis es einen Fehler bei der Geltendmachung eines Schlüssels feststellt und an diesem Punkt aufhört, Schlüssel geltend zu machen und offline geht.
  • In einem anderen Beispiel kann ein neuer Vermittlerdienst konfiguriert werden, wenn ein aktueller Vermittlerdienst nicht verfügbar ist. Wenn z.B. alle In-Sync Speichersysteme für einen Pod miteinander kommunizieren, aber nicht mit dem aktuellen Vermittlerdienst, dann kann der Pod mit einem neuen Vermittlerdienst konfiguriert werden. Dies ist ähnlich wie der vorherige Algorithmus zur Auswahl eines neuen Schlüssels oder neuer Vermittlerwerte, aber der neue Schlüssel ist weiterhin so konfiguriert, dass er einen neuen Vermittlerdienst verwendet und nicht nur ein weiterer Schlüssel ist, der mit demselben Dienst verbunden ist. Wenn außerdem während dieses Vorgangs ein Fehler auftritt, wie beim vorherigen Algorithmus, können einige Systeme nach älteren Schlüsseln ein Race durchführen, so dass Systeme, die sowohl die alten Schlüssel als auch den neuen Schlüssel mit dem neuen Vermittlerdienst kennen, nach dem neuen Schlüssel auf dem neuen Vermittlerdienst ein Race durchführen können. Wenn der vorherige Vermittlerdienst dauerhaft nicht verfügbar ist, sollten alle In-Sync-Speichersysteme schließlich wieder miteinander verbunden werden und den Austausch des neuen Vermittlerdienstes und aller mit dem neuen Vermittlerdienst verbundenen Schlüssel und Werte abschließen, bevor der Pod-Dienst sicher wieder aufgenommen werden kann.
  • In einem anderen Beispiel kann ein Modell zur Fehlerbehebung darin bestehen, Präferenzregeln zu implementieren, um ein Speichersystem gegenüber anderen Speichersystemen zu bevorzugen. Wenn in diesem Beispiel ein bevorzugtes Speichersystem läuft, bleibt es in Betrieb und trennt alle Speichersysteme, mit denen es nicht kommuniziert. Darüber hinaus schaltet sich jedes andere System, das nicht nachweislich mit dem bevorzugten System kommuniziert, selbst ab. Wenn in diesem Beispiel ein nicht bevorzugtes Speichersystem schließlich wieder eine Verbindung mit einem bevorzugten Speichersystem herstellt, können die beiden Speichersysteme, wenn das bevorzugte Speichersystem das wiederverbindende Speichersystem noch nicht abgetrennt hatte, sich wiederherstellen und den Zustand wiederherstellen, in dem beide Speichersysteme synchronisiert sind, wohingegen, wenn das bevorzugte Speichersystem das wiederverbindende Speichersystem abgetrennt hatte, das wiederverbindende Speichersystem zuerst wieder synchronisiert werden muss, damit es für den Pod synchronisiert wird, bevor es die Handhabung des Pods wieder aufnehmen kann. Ein bevorzugtes Speichersystem ist möglicherweise nicht so nützlich für die Bereitstellung hoher Verfügbarkeit, kann aber für andere Anwendungen der synchronen Replikation nützlich sein, insbesondere für die asymmetrische synchrone Replikation. Beispielsweise angenommen der Fall der Spiegelung eines Pods von einem zentralen, großen Speichersystem in einem Datenzentrum oder Campus auf ein kleineres (vielleicht weniger verwaltetes) Speichersystem, das näher an den Anwendungsservern läuft, wie z.B. in Top-of-Rack-Konfigurationen. In diesem Fall kann es vorteilhaft sein, bei Netzwerkausfällen oder beim Ausfall des Top-of-Rack-Speichersystems immer das größere, besser verwaltete zentrale Speichersystem zu bevorzugen, während der Dienst für einen Pod ganz eingestellt wird, wenn das zentral verwaltete Speichersystem ausfällt. Solche Top-of-Rack-Speichersysteme können nur zur Verbesserung der Leseleistung oder zur Verringerung der Last auf Speichernetzwerken im Rechenzentrum verwendet werden. Wenn jedoch asynchrone Replikation oder andere Datenverwaltungsdienste nur auf dem zentral verwalteten System ausgeführt werden, ist es unter Umständen vorzuziehen, den Datenverkehr auf das zentrale Speichersystem umzuleiten oder die Handhabung einzustellen und den technischen Support anzurufen, als das Top-of-Rack-Speichersystem allein weiterlaufen zu lassen. Darüber hinaus können die Präferenzregeln komplexer sein - es kann zwei oder mehr solcher „bevorzugten“ Speichersysteme geben, die vielleicht mit einer gewissen Anzahl zusätzlicher Speichersysteme gekoppelt sind, die sich auf die bevorzugten oder erforderlichen Speichersysteme stützen. In diesem Beispiel ist der Pod online, wenn alle bevorzugten oder erforderlichen Speichersysteme laufen, und ist heruntergefahren, wenn einige von ihnen nicht laufen. Dies ähnelt einem Quorum-Modell, bei dem die Größe des Quorums der Anzahl der stimmberechtigten Elemente entspricht, ist aber einfacher zu implementieren als ein allgemeines Quorum-Modell, das weniger als alle stimmberechtigten Elemente zulässt.
  • In einem anderen Beispiel kann eine Kombination von Mechanismen verwendet werden, was nützlich sein kann, wenn ein Pod sich über mehr als zwei Speichersysteme erstreckt. In einem Beispiel können Präferenzregeln mit Vermittlung kombiniert werden. Im Top-of-Rack-Beispiel könnte das größere zentrale Speichersystem in einem Rechenzentrum oder Campus selbst synchron auf ein großes Speichersystem an einem zweiten Standort repliziert werden. In diesem Fall werden die Top-of-Rack-Speichersysteme möglicherweise nie allein weiterarbeiten und möglicherweise eines der größeren zentralen Speichersysteme an den beiden Standorten bevorzugen. Die beiden größeren Speichersysteme könnten in diesem Fall so konfiguriert sein, dass sie zwischen einander vermitteln, und alle kleineren Speichersysteme, die eine Verbindung zu demjenigen der beiden größeren Speichersysteme herstellen können, das online bleibt, können die Wartung ihres Pod fortsetzen, und alle kleineren Speichersysteme, die keine Verbindung zu einem der beiden großen Speichersysteme herstellen können (oder die nur zu einem der beiden großen Speichersysteme herstellen können, das für den Pod offline ist), können die Wartung des Pod einstellen. Darüber hinaus kann ein Präferenzmodell auch mit einem quorumbasierten Modell kombiniert werden. Beispielsweise könnten drei große Speichersysteme an drei Standorten untereinander ein Quorum-Modell verwenden, wobei kleinere Satelliten- oder Top-of-Rack-Speichersysteme keine Stimmen erhalten und nur dann funktionieren, wenn sie eine Verbindung zu einem der größeren In-Sync Speichersysteme herstellen können, die online sind.
  • In einem anderen Beispiel für die Kombination von Mechanismen kann die Vermittlung mit einem Quorum-Modell kombiniert werden. Beispielsweise kann es drei Speichersysteme geben, die normalerweise miteinander abstimmen, um sicherzustellen, dass zwei Speichersysteme ein drittes, nicht kommunizierendes Speichersystem sicher abtrennen können, während ein Speichersystem die beiden anderen Speichersysteme niemals allein abtrennen kann. Nachdem jedoch zwei Speichersysteme erfolgreich ein drittes Speichersystem abgetrennt haben, ist die Konfiguration nun auf zwei Speichersysteme reduziert, die sich einig sind, dass sie synchronisiert sind, und die sich darüber einig sind, dass das dritte Speichersystem abgetrennt ist. In diesem Fall können sich die beiden verbleibenden Speichersysteme darauf einigen, eine Vermittlung (z.B. mit einem Cloud-Dienst) zu verwenden, um einen zusätzlichen Speicher- oder Netzwerkfehler zu behandeln. Diese Kombination aus Vermittlung und Quorum kann weiter ausgedehnt werden. Zum Beispiel können in einem Pod, der sich zwischen vier Speichersystemen erstreckt, drei beliebige ein viertes abtrennen, aber wenn zwei In-Sync-Speichersysteme zwar miteinander kommunizieren, aber nicht mit zwei anderen Speichersystemen, die beide derzeit als in-sync Systeme betrachtet werden, dann könnten sie die Vermittlung verwenden, um die beiden anderen sicher abzutrennen. Selbst bei einer Pod-Konfiguration mit fünf Speichersystemen können, wenn vier Speichersysteme dafür stimmen, ein fünftes abzutrennen, die verbleibenden vier die Vermittlung verwenden, wenn sie in zwei gleiche Hälften geteilt werden, und wenn der Pod auf zwei Speichersysteme reduziert ist, können sie die Vermittlung verwenden, um einen aufeinanderfolgenden Fehler zu beheben. Fünf bis drei könnten dann das Quorum zwischen den drei nutzen, um einen Rückgang auf zwei zu ermöglichen, wobei die beiden verbleibenden Speichersysteme bei einem weiteren Ausfall erneut die Vermittlung nutzen können. Dieser allgemeine Multimode-Quorums- und Vermittlermechanismus kann eine zusätzliche Anzahl von Situationen bewältigen, die weder das Quorum zwischen symmetrischen Speichersystemen noch die Vermittlung allein bewältigen kann. Diese Kombination kann die Zahl der Fälle erhöhen, in denen fehlerhafte oder gelegentlich unerreichbare Vermittler zuverlässig eingesetzt werden können (oder im Falle von Cloud-Vermittlern, bei denen die Kunden ihnen möglicherweise nicht ganz vertrauen). Darüber hinaus kann diese Kombination den Fall von drei Speichersystem-Pods besser handhaben, in dem die Vermittlung allein dazu führen könnte, dass ein erstes Speichersystem bei einem Netzwerkfehler, der nur das erste Speichersystem betrifft, erfolgreich ein zweites und drittes Speichersystem abtrennt. Diese Kombination kann auch besser mit einer Folge von Fehlern umgehen, die jeweils nur ein Speichersystem betreffen, wie in den drei bis zwei und dann in einem Beispiel beschrieben. Diese Kombinationen funktionieren, weil die In-Sync- und die Detache-Operation zu bestimmten Zuständen führen - mit anderen Worten, das System ist zustandsbehaftet, weil es sich um einen Prozess handelt, der von der Detache-Operation zur In-Sync-Operation übergeht, und jede Stufe in einer Sequenz von Quorum/Vermittler-Beziehungen stellt sicher, dass zu jedem Zeitpunkt alle Online-/ln-Sync Speichersysteme mit dem aktuellen persistenten Zustand für den Pod übereinstimmen. Dies ist anders als bei einigen anderen Clustering-Modellen, bei denen erwartet wird, dass es zur Wiederaufnahme des Betriebs ausreicht, wenn die Mehrheit der Cluster-Knoten wieder miteinander kommunizieren. Das Präferenzmodell kann jedoch immer noch hinzugefügt werden, wobei Satelliten- oder Top-of-Rack-Speichersysteme nie an der Vermittlung oder dem Quorum teilnehmen und den Pod nur dann bedienen, wenn sie eine Verbindung zu einem Online-Speichersystem herstellen können, das an der Vermittlung oder dem Quorum teilnimmt.
  • In einigen Beispielen können sich ein Vermittlerdienst (800) oder externe Pod-Zugehörigkeitsmanager in Fehlerzonen befinden, die sich von den Fehlerzonen für die synchron replizierten Speichersysteme (814, 824) unterscheiden. Wenn z.B. bei einem Pod mit zwei Speichersystemen (430) die beiden Speichersysteme (814, 824) in verschiedene Fehlerzonen unterteilt sind, z.B. durch ihren physischen Standort - eines in einer Stadt und das andere am Stadtrand oder eines in einem Datenzentrum, das an ein Stromnetz oder einen Internetzugangspunkt angeschlossen ist, und das andere in einem anderen Datenzentrum, das an ein anderes Stromnetz oder einen anderen Internetzugangspunkt angeschlossen ist-, dann ist es im Allgemeinen vorzuziehen, sich in einer anderen Fehlerzone als die beiden Speichersysteme zu befinden. Ein Beispiel: Der Vermittlerdienst (800) kann sich in einem anderen Teil des ausgedehnten Stadtgebiets der Stadt befinden oder an ein anderes Stromnetz oder einen anderen Internetzugangspunkt angeschlossen sein. Synchron replizierte Speichersysteme können sich jedoch auch innerhalb desselben Rechenzentrums befinden, um eine bessere Speicherzuverlässigkeit zu gewährleisten, und in diesem Fall können Netz-, Strom- und Kühlzonen berücksichtigt werden.
  • Die in 8 dargestellte Beispielmethode umfasst die Anforderung (802) einer Vermittlung durch einen Vermittlerdienst (800) durch ein erstes Speichersystem (814) als Reaktion auf die Erkennung eines auslösenden Ereignisses. In diesem Beispiel kann ein auslösendes Ereignis ein Kommunikationsfehler in der Datenkommunikationsverbindung (816) zwischen dem ersten Speichersystem (814) und dem zweiten Speichersystem (824) sein, wobei die Erkennung des Fehlers auf einem Hardware-Fehler, der eine Unterbrechung auslöst, auf einem Versagen, eine Übertragung zu bestätigen, oder auf fehlgeschlagenen Wiederholungsversuchen oder auf einer anderen Methode beruhen kann. In anderen Fällen kann ein auslösendes Ereignis das Auslaufen eines Lease für synchrone Replikation sein, und die Anforderung einer Vermittlung kann Teil des Versuchs sein, die Synchronisierung der Verbindung und die Wiederaufnahme von Aktivitäts-Leases zu koordinieren. Ein solcher Lease kann anfänglich in Abhängigkeit von der Zeitinformation für mindestens eines der mehreren Speichersysteme auf verschiedene Weise abgeschlossen werden. Beispielsweise können die Speichersysteme einen synchronen Replikations-Lease einrichten, indem sie die Zeitinformation für jedes der mehreren Speichersysteme zur Koordinierung oder zum Austausch von Taktwerten verwenden. In einem solchen Beispiel kann das Speichersystem, sobald die Taktwerte für jedes der Speichersysteme koordiniert sind, eine synchrones Replikations-Lease einrichten, die sich für eine vorbestimmte Zeitspanne über die koordinierten oder ausgetauschten Taktwerte hinaus erstreckt. Wenn z.B. die Taktwerte für jedes Speichersystem zur Zeit X koordiniert werden, können die Speichersysteme jeweils so konfiguriert werden, dass sie einen synchronen Replikations-Lease einrichten, der bis X + 2 Sekunden gültig ist. Eine weitere Erklärung für die Koordinierung oder den Austausch von Taktwerten findet sich in der provisorischen US-Anwendung 62/518.071, die hierin durch Verweis in ihrer Gesamtheit enthalten ist.
  • Ferner kann die Anforderung (802) durch das erste Speichersystem (814) als Reaktion auf die Erfassung des auslösenden Ereignisses eine Vermittlung von dem Vermittlerdienst (800) durch einen Controller des ersten Speichersystems (814) implementiert werden, der ein auslösendes Ereignis erfasst und eine Anforderung (860) über ein Netzwerk (854) an einen Vermittlerdienst (800) sendet. In einigen Beispielen kann ein Vermittlerdienst (800) ein Dienst einer dritten Partei sein, der für mehrere Computersysteme einen gegenseitig exklusiven Zugriff auf eine Ressource, wie z.B. einen bestimmten Datenbankeintrag zur Speicherung eines Wertes, bereitstellt. Zum Beispiel kann der Vermittlerdienst (800) von einem Datenbankdienst eines Anbieters von Cloud-Diensten, von einem Host-Computer, der Anfragen zur Änderung des Datensatzes ausgibt, oder von einem Drittanbieterdienst bereitgestellt werden, der einen sich gegenseitig ausschließenden Zugriff auf eine Ressource bietet, wobei die Ressource ein Speicher, eine Zustandsmaschine oder eine andere Art von Ressource sein kann, die in der Lage ist, eine bestimmte Änderung auf der Grundlage einer Anfrage eines bestimmten Kunden anzuzeigen. In diesem Beispiel wartet (803A) das erste Speichersystem (814) nach dem Senden der Vermittleranfrage (860) auf einen Hinweis des Vermittlerdienstes (800), der ein positives Vermittlerergebnis (803B) oder ein negatives Vermittlerergebnis oder eine fehlende Antwort (803C) anzeigt. Wenn das erste Speichersystem (814) ein negatives Vermittlerergebnis oder keine Antwort (803C) erhält und wenn ein Schwellenwert für die Wartezeit nicht überschritten wurde, dann kann das erste Speichersystem (814) weiter warten (806). Wenn jedoch die Wartezeit den Schwellenwert überschreitet, kann das erste Speichersystem (814) fortfahren (806), indem es feststellt, dass ein anderes Computersystem die Vermittlung gewonnen hat, und sich selbst offline schaltet. In einigen Beispielen kann, wie oben erörtert, eine Vermittleranfrage vom Vermittlerdienst (800) als atomare Compare-and-set-Operation empfangen werden, der versucht, einen Wert für eine gemeinsam genutzte Ressource (852) festzulegen, der auch das Ziel einer Compare-and-set-Operation sein kann, der von einem anderen der Speichersysteme, die den Pod (430) warten, empfangen wird, wobei das Speichersystem, das die gemeinsam genutzte Ressource (852) erfolgreich setzt, die Vermittlung gewinnt.
  • Das Beispiel in 8 umfasst auch das zweite Speichersystem (824), das als Reaktion auf das Erkennen eines auslösenden Ereignisses die Vermittlung durch den Vermittlerdienst (800) anfordert (810). Das Anfordern (810), als Reaktion auf das Erkennen eines auslösenden Ereignisses, der Vermittlung durch den Vermittlerdienst (800) kann ähnlich wie das Durchführen des Anforderns (802), als Reaktion auf das auslösende Ereignis, der Vermittlung auf dem ersten Speichersystem (814) implementiert werden. In diesem Beispiel kann jedoch das zweite Speichersystem (824) als Reaktion auf das Senden einer Anforderung (862) an den Vermittlerdienst - im Gegensatz zum Vermittlererfolg des ersten Speichersystems (814) - eine Misserfolgsmeldung oder einen Hinweis darauf erhalten, dass die Anforderung (862) für eine Vermittlung nicht erfolgreich war.
  • Das Beispielverfahren in 8 fährt fort mit (804). Für den Fall, dass eine Anzeige (864) eines positiven Vermittlerergebnisses von dem ersten Computersystem (814) empfangen wird, verarbeitet das erste Computersystem (814) als Reaktion auf die Anzeige (864) des positiven Vermittlerergebnisses von dem Vermittlerdienst (800) - anstelle des zweiten Speichersystems (824) - Datenspeicheranforderungen, die an einen Datensatz (426) gerichtet sind, der synchron über das erste Speichersystem (814) und das zweite Speichersystem (824) repliziert wird. Die synchrone Replikation eines Datensatzes (426), die einen Pod (430) implementiert, kann zusätzlich zum Empfangen und Verarbeiten von Datenspeicheranforderungen, die an einen Datensatz (426) gerichtet sind, wie unter Bezugnahme auf die 8A und 8B der U.S. Provisional Applications 62/470,172 und 62/518,071 beschrieben, die hier in ihrer Gesamtheit enthalten sind, implementiert werden. In diesem Beispiel kann, wie zuvor unter Bezugnahme auf 8 beschrieben, als Reaktion auf einen Hinweis (864) auf ein positives Vermittlerergebnis das erste Speichersystem (814) als das Speichersystem angesehen werden, das die Vermittlung gewinnt, und das erste Speichersystem (814) kann das Speichersystem, mit dem die Kommunikation verloren ging, abtrennen. In anderen Beispielen kann die Vermittlung jedoch nach jeder der anderen beschriebenen Vermittlerverfahren oder Kombinationen von Vermittlerverfahren durchgeführt werden.
  • In einigen Beispielen kann die Festlegung einer Präferenz, für welches Speichersystem aus einer Vielzahl von Speichersystemen, die einen Datensatz (426) synchron replizieren, die Vermittlung gewinnen soll, durch Angabe eines Verzögerungswertes für jedes der Vielzahl von Speichersystemen implementiert werden. Wenn z.B. ein erstes Speichersystem (814) als bevorzugtes Speichersystem bezeichnet wird, dann kann dem ersten Speichersystem (814) ein Verzögerungswert von Null (0) zugewiesen werden, bevor ein Antrag auf Vermittlung von dem Vermittlerdienst gestellt wird. Für nicht bevorzugte Speichersysteme kann jedoch ein Verzögerungswert größer als Null (z.B. 3 Sekunden) oder ein anderer Wert zugewiesen werden, der im Allgemeinen dazu führt, dass das bevorzugte Speichersystem die Vermittlung allein aufgrund eines Kommunikationsverlustes zwischen synchron replizierten Speichersystemen gewinnt.
  • Zur weiteren Erläuterung von Vermittlerlösungen erweitern die folgenden Beispiele die beschriebenen Techniken zur Durchführung einer Vermittlung, die in den U.S. Anmeldungen mit den Seriennummern 62/470.172 und 62/518.071 beschrieben werden, die hierin in ihrer Gesamtheit enthalten sind, einschließlich, aber nicht beschränkt auf, Implementierungen in Bezug auf „Pods“ für eine Darstellung eines bestimmten Datensatzes, der zwischen einer bestimmten Anzahl von Speichersystemen synchron repliziert wird, „Zugehörigkeit“ als Bezeichnung für die Speichersysteme, die nominell synchrone Replikate eines bestimmten Pods enthalten, „in-sync“ für eine Zugehörigkeitskopie eines Datensatzes, der in Bezug auf den Datensatz eines Pods als aktuell angesehen wird, und „online“ für ein Speichersystem, das bereit ist, den Inhalt eines Pods aktiv bereitzustellen.
  • Wie in den oben genannten Anwendungen beschrieben, kann ein Speichersystem eine Reihe von Modellen zum Erkennen und Reagieren auf Fehler innerhalb und zwischen den Speichersystemen implementieren, welche Daten synchron replizieren - wobei eine solche Implementierung sicherstellen kann, dass es nicht zu einem Split-Brain-Betrieb kommt, was einen synchron replizierten Datensatz anfällig für Datenbeschädigungen machen kann. Darüber hinaus beschreiben die Ausführungsformen in den oben genannten Anwendungen Implementierungen, die Folgendes umfassen: Definition von Präferenzen; Vermittlung; Quorum-Richtlinien; wie Teilmengen von Speichersystemen, die mit einem Pod verbunden sind, die Vermittlung verzögern oder nicht automatisch auslösen können, um weiche Präferenzen zu codieren; Modelle zur Aktualisierung von Vermittlern; Änderung von Präferenzen; und Wechsel von Quorum-Modellen zu Präferenzmodellen oder Vermittlermodellen, wenn Speichersysteme inkrementell versagen. Wie unten beschrieben, können eine oder mehrere dieser Implementierungen als Grundlage für weitere Implementierungen dienen.
  • In einigen Implementierungen kann ein Speichersystem, als Reaktion auf nicht verfügbare Vermittler, Anpassungen vornehmen. Zum Beispiel sollte ein Speichersystem, das einen Pod implementiert, der so konfiguriert ist, dass er als Reaktion auf Störungen Vermittlungen verwendet, einen Vermittlerdienst vereinbaren und sich auf einen Satz von Vermittlerparametern einigen, die für die Vermittlung verwendet werden sollen - wie zum Beispiel den Schlüssel, der bei der Durchführung der Vermittlung verwendet wird. Darüber hinaus können ein Vermittlerdienst und die Vermittlerparameter geändert werden, z.B. durch die Verwendung eines Modells, das Übergänge durch Zwischenschritte ausführt, die sowohl einen früheren als auch einen nachfolgenden Vermittlerdienst und Parameter vor dem Übergang zur Verwendung eines einzigen, nachfolgenden Vermittlerdienstes und Vermittlerparameters verwenden. In einigen Implementierungen können diese Beispieländerungen sicher bis zur Fertigstellung durch ein Speichersystem durchgeführt werden, ohne dass das Speichersystem mit einem Vermittlerdienst kommuniziert, da zumindest einige der Speichersysteme in der Lage sind, miteinander zu kommunizieren. Wenn z.B. ein oder mehrere Speichersysteme, die für die Vermittlung konfiguriert sind, die Kommunikation stoppen, z.B. wegen eines Speichersystem- oder Netzwerkfehlers, dann kann die Vermittlung - möglicherweise unter Verwendung mehrerer Vermittlerdienste oder Vermittlerparameter - verwendet werden, um weiterzumachen, bis die Kommunikation wiederhergestellt ist.
  • In einigen Implementierungen kann der Betrieb eines Pods bei Ausfall eines Vermittlerdienstes zum Zeitpunkt eines Netzwerk- oder Speichersystemfehlers ausfallen oder unterbrochen werden, bis der Vermittlerdienst wieder verfügbar ist oder bis der Netzwerk- oder Speichersystemfehler behoben oder die Kommunikation anderweitig wiederhergestellt ist. In einigen Beispielen kann bei einem einzelnen Speichersystem der Ausfall eines Pods vom Ausfall sowohl eines Speichersystems innerhalb des Pods als auch des Vermittlerdienstes (oder zumindest des Zugangs zum Vermittlerdienst) abhängen - dies kann als ein Ereignis mit geringer Wahrscheinlichkeit und doppelter Fehlerhaftigkeit angesehen werden. Wenn es jedoch eine große Anzahl von Speichersystemen und eine große Anzahl von Pods gibt, in denen diese Pods denselben Vermittlerdienst benutzen, dann steigt die Wahrscheinlichkeit, dass ein Ausfall des Vermittlerdienstes zu einem Ausfall mindestens eines Pods führt, erheblich. In einem solchen Beispiel kann dieses Problem der erhöhten Ausfallwahrscheinlichkeit gelöst werden, indem man die Fähigkeit zur Laufzeit-Umschaltung von Vermittlerdiensten durch vermittlungsfähige Speichersysteme für einen Pod nutzt, indem Speichersysteme im Pod ihre Fähigkeit überwachen, mit verschiedenen Vermittlerdiensten zu kommunizieren, und indem man die Vermittlerdienste für den Pod umschaltet, wenn irgendwelche Probleme auftreten, wobei das Ziel darin bestehen kann, eine Umschaltung abzuschließen, bevor irgendein Problem auftritt, das möglicherweise eine Vermittlung erfordert, und während die Online-Speichersysteme für einen Pod noch miteinander kommunizieren. In einigen Beispielen kann der Wechsel zu einem neuen Vermittlerdienst schnell erfolgen; wenn z.B. der Zugang zum Vermittlerdienst periodisch überprüft wird oder als Reaktion auf ein Überwachungsereignis - wobei ein Beispielzeitraum einmal alle 30 Sekunden stattfinden kann und ein Überwachungsereignis eine Änderung des Netzwerkstatus beinhalten kann - kann der Vermittlerdienst als Reaktion auf eine oder mehrere fehlgeschlagene Gesundheitsprüfungen oder auf ein oder mehrere Überwachungsereignisse geschaltet werden. Um mit diesem Beispiel fortzufahren: Als Reaktion auf eine negative periodische Kontrolle und/oder ein Überwachungsereignis können alle Pods, die den bestimmten Vermittlerdienst in Anspruch nehmen, zu einer alternativen Lösung für die Vermittlung wechseln, wobei der Wechsel in einigen Beispielen innerhalb von etwa einer Minute nach Nichtverfügbarkeit oder Nichterreichbarkeit eines Vermittlerdienstes erfolgen kann. In diesen Beispielen kann eine solche Überwachung oder Reaktion auf Überwachungsereignisse das Fenster der Anfälligkeit für jeden der Pods, die aufgrund eines doppelten Versagens, zu dem auch ein Versagen des Vermittlerdienstes gehört, ausfallen, erheblich verkleinern.
  • In einigen Implementierungen können Vermittlerdienste auf physischen oder virtuellen Servern implementiert werden, wobei ein bestimmter Vermittlerdienst intern geclustert oder für hohe Verfügbarkeit mit mehreren Netzwerkadressen verteilt sein kann. In anderen Fällen kann ein Vermittlerdienst ein einfacher Ein-Knoten-Service sein, der keine interne Form der Hochverfügbarkeit verwendet, In einigen Beispielen können Vermittlerdienste auch innerhalb einer öffentlichen Cloud implementiert werden, wie z.B. Amazon Web Services™, Microsoft Azure™, AlibabaCloud™, unter anderen, oder ein Vermittlerdienst kann in von Anbietern bereitgestellten und verwalteten Datenzentren implementiert werden. In anderen Beispielen kann ein Vermittlerdienst unter Verwendung eines Datenbankdienstes zur Speicherung von Schlüsseln unter Verwendung von atomaren Primitiven, wie z.B. einer exklusiven Erstellung oder eines atomaren Vergleichs und Austauschs, implementiert werden.
  • In einigen Implementierungen kann ein bestimmter Vermittlerdienst nach einem Vermittlertyp, einer Zugangsmethode oder nach Typen von Vermittlerprimitiven beschrieben werden, die angeboten werden, zusätzlich zu der Beschreibung, wie eine Bestimmung für die Benennung und den Zugang zu einem Vermittlerdienst über ein Netzwerk getroffen wird. Zum Beispiel kann ein Vermittlerdienst eine Liste von Internet-Protokolladressen, einen oder mehrere Namen, die über DNS nachgeschlagen werden können, oder einen Dienstnamen, der in anderen Arten von Verzeichnissen oder über andere Verzeichnisdienste nachgeschlagen werden kann, bereitstellen. Darüber hinaus können einige bestehende Web-Speicher- oder Datenbankdienste, die von Cloud-Diensten bereitgestellt werden, Vermittlerdienste direkt implementieren, die auf der Bereitstellung von Operationen wie bedingten PUT-Anforderungen, wie z.B. bedingten PUT-Anforderungen in Amazon™ S3 oder einigen bedingten Datenbankoperationen, wie z.B. denen von DynamoDB™, basieren. In diesen Beispielen für Cloud-Dienste kann die Benennung ein Bereich oder ein Datenbankname sein, der mit einem Kundenkonto verbunden ist.
  • In einigen Implementierungen kann eine Reihe von Speichersystemen oder Pods mit einer Reihe von möglichen Vermittlerdiensten konfiguriert werden. In einigen Beispielen können alternativ oder zusätzlich Speichersysteme oder Pods so konfiguriert werden, dass sie zwischengeschaltete Vermittlerdienste verwenden, die Listen möglicher Vermittlerdienste bereitstellen, wobei sich diese Listen im Laufe der Zeit auch ändern können, z.B. kann eine Liste aktualisiert werden, um neue Vermittlerdienste aufzunehmen oder um Vermittlerdienste zu entfernen oder zu ersetzen, die möglicherweise veraltet sind oder deren Wartung geplant ist oder die offline genommen werden sollen. Beispielsweise kann ein Anbieter einen Vermittlerdienst-Broker anbieten, der Speichersysteme mit einer Reihe von öffentlichen, auf der Cloud basierenden Vermittlerdiensten anbietet, die um und zwischen verschiedenen Verfügbarkeitszonen verstreut sind, wie z.B. die von AWS™, die um und zwischen verschiedenen geographischen Regionen verstreut sind oder sogar zwischen mehreren verschiedenen Anbietern von Cloud-Diensten verstreut sind. Darüber hinaus kann ein Anbieter eine Reihe von Vermittlerdiensten hinzufügen, die auf seiner eigenen Infrastruktur zusätzlich zu den über öffentliche Cloud-Dienste bereitgestellten Vermittlerdiensten laufen. In einigen Beispielen kann ein lokaler IT-Dienst oder eine lokale IT-Abteilung alternativ sowohl Speichersysteme einsetzen, die synchron replizierte Daten implementieren, als auch lokale Vermittlerdienste, wie z.B. einen lokalen Vermittlerdienst, der in einer lokalen virtuellen Maschine betrieben wird, wobei die lokalen Vermittlerdienste an einer Vielzahl von Standorten installiert werden können, die vom lokalen IT-Dienst oder der lokalen IT-Abteilung verwaltet werden. Darüber hinaus können in einigen Beispielen Kombinationen von Umgebungen bei der Implementierung von Vermittlerdiensten verwendet werden, z.B. wenn ein lokaler Vermittlerdienst ein lokales Speichersystem bedient, das Daten synchron repliziert, wenn anstelle eines Cloud-basierten Meditator-Dienstes ein lokaler Vermittlerdienst bereitgestellt wird - wobei ein lokaler Vermittlerdienst mit einem anbieter- oder Cloud-betriebenen Dienst integriert werden kann, um Verbindungen zu lokalen Vermittlerdienst-Instanzen zurück zu lokalen Speichersystemen vom anbieter- oder Cloud-betriebenen Dienst bereitzustellen, um zu vermeiden, dass alle Speichersysteme für die Kommunikation mit einem lokalen Vermittler konfiguriert werden müssen.
  • In einigen Implementierungen müssen Speichersysteme, die für die Verwendung von Vermittlungen konfiguriert sind, sich darauf einigen, welcher Vermittlerdienst zu verwenden ist, sich darauf einigen, welche Ereignisse oder Umstände vor der Vermittlung eintreten sollen, und sich auf Vermittlerparameter einigen, wenn ein Vermittlerdienst aufgerufen wird. Darüber hinaus kann es während einer Änderung des Vermittlerdienstes oder der Vermittlerparameter für einen Speichersystem-Pod zu einer Diskrepanz in der Vermittler-Konfiguration zwischen Speichersystemen kommen, die einen Pod implementieren; solche Unterschiede können jedoch vorübergehender oder temporärer Natur sein.
  • In einigen Implementierungen kann eine Liste von Vermittlerdiensten, wie die vorstehend beschriebene Liste, mit einer Liste vorgeschlagener Vermittlerdienste gekoppelt werden, die von Vermittlerdienst-Brokern bestimmt werden, wobei die sich daraus ergebende Liste eine Liste potentieller Vermittlerdienste bilden kann, aus denen ein Speichersystem, oder Pod, ausgewählt werden kann. Wenn z.B. ein Pod sich so erstreckt, dass er ein zweites oder nachfolgendes Speichersystem enthält, das für die Vermittlung für den Pod konfiguriert ist, dann kann einer dieser Vermittlerdienste und alle notwendigen Vermittlerparameter ausgewählt und zwischen diesen vermittlerfähigen Speichersystemen kommuniziert werden. In diesem Beispiel sollte ein Vermittlerdienst von allen diesen Speichersystemen aus nutzbar sein, und wenn sich die Speichersysteme nicht auf einen gemeinsamen nutzbaren Vermittlerdienst einigen können, dann könnte ein Ausdehnungsvorgang fehlschlagen oder verzögert werden, bis sich die Bedingungen ändern und die Speichersysteme sich einigen oder einen Konsens erreichen können.
  • In einigen Implementierungen können online vermittlungsfähige Speichersysteme für einen Pod einen derzeit gewählten Vermittlerdienst und potenzielle Alternativen laufend überwachen. Beispielsweise können ein oder mehrere Speichersysteme auf periodischer oder aperiodischer Basis einen oder mehrere der verfügbaren Vermittlerdienste überwachen, um festzustellen, ob ein Vermittlerdienst nicht verfügbar oder unzuverlässig ist. In diesem Beispiel kann ein bestimmter Vermittlerdienst unter mehreren Vermittlerdiensten als nicht verfügbar bestimmt werden, wenn ein oder mehrere Versuche, mit dem bestimmten Vermittlerdienst zu kommunizieren, nicht erfolgreich sind. Ferner kann in diesem Beispiel ein bestimmter Vermittlerdienst unter mehreren Vermittlerdiensten als unzuverlässig angesehen werden, wenn er in einem früheren Zeitfenster nicht verfügbar war, selbst wenn der bestimmte Vermittlerdienst zu einem aktuellen Zeitpunkt verfügbar ist, insbesondere wenn er sich als nicht verfügbar erwiesen hat, aber verfügbar wird und dann in einem nicht zu weit zurückliegenden Zeitraum mehrmals wieder nicht verfügbar ist. In einigen Beispielen kann ein Vermittlerdienst auch als unzuverlässig angesehen werden, wenn er ungewöhnlich langsam reagiert, um Anfragen zu überwachen. In ähnlicher Weise kann ein Vermittlerdienst, der zuvor als unzuverlässig eingestuft wurde, als zuverlässig eingestuft werden, wenn er in einem späteren Zeitfenster schnell oder zuverlässig antwortet.
  • In einigen Implementierungen könnte die Überwachung des Vermittlerdienstes auch zu Warnmeldungen führen, die einen Administrator oder Benutzer benachrichtigen, den Public-Cloud-Anbieter benachrichtigen oder den Verkäufer benachrichtigen, damit der Vermittlerdienst repariert werden kann oder die Liste der Vermittlerdienste des Vermittlers angepasst werden kann, um zuverlässigere Alternativen aufzunehmen.
  • In einigen Implementierungen können die Parameter und Merkmale eines Vermittlerdienstes von einem Speichersystem-Pod als Grundlage für die Auswahl eines Vermittlerdienstes unter mehreren verfügbaren Vermittlerdiensten verwendet werden. Wenn z.B. die Standorte der Speichersysteme der Pod-Elemente und die Standorte der Vermittlerdienste bekannt sind (z.B. weil die Standorte durch Netzwerkanalyse ermittelt werden oder weil der Standort explizit konfiguriert ist), dann können diese Informationen auch für die Auswahl eines Vermittlerdienstes verwendet werden. Wenn z.B. ein lokal bereitgestelltes synchron repliziertes Speichersystem über mehrere Datenzentren hinweg betrieben wird und wenn die Speichersysteme durch ein bestimmtes Datenzentrum und die Vermittler durch ein bestimmtes Datenzentrum markiert sind (oder wenn markierte Speichersysteme als Vermittler dienen können), dann kann ein Pod, der sich zwischen zwei oder mehr der mehreren Datenzentren erstreckt, automatisch einen Vermittlerdienst (oder ein Speichersystem als Vermittler) von einem anderen Datenzentrum als einem der Datenzentren, auf die sich der Pod erstreckt, verwenden.
  • In einigen Implementierungen können, wie oben erwähnt, vermittlungsfähige Speichersysteme für einen Pod einen aktuellen Vermittlerdienst auf Verfügbarkeit oder Zuverlässigkeit überwachen und bewerten. Beispielsweise kann ein Dienst als verfügbar bestimmt werden, wenn er erreichbar ist und auf Überwachungsanforderungen reagiert. Ferner kann in diesem Beispiel der Gesundheitszustand oder Status eines Vermittlerdienstes durch andere Speichersysteme oder andere Hilfsmittel überwacht werden, wobei der Gesundheitszustand oder Status als Teil eines Auswahlkriteriums an Speichersysteme übermittelt werden kann. Auf diese Weise könnte bei einem Cloud- oder Anbieter-gehosteten Vermittler-Überwachungsdienst jedes Speichersystem oder jeder Überwachungsdienst die Gesundheits- oder Statusergebnisse für jeden Vermittlerdienst aus einer Liste verfügbarer Vermittlerdienste verfolgen. In einigen Beispielen könnte ein anderer Dienst, der vielleicht mit einem Vermittlerdienst integriert ist, auf Anfrage Gesundheits- oder Zustandsinformationen sammeln und bereitstellen oder anderweitig Speichersysteme und Pods aktualisieren, so dass Speichersysteme auf alle Probleme mit einem bestimmten Vermittlerdienst aufmerksam gemacht werden können. Ein solcher Überwachungsdienst ist für die Durchführung der eigentlichen Vermittlung nicht entscheidend, so dass diese Gesundheits- oder Zustandsdaten so verteilt werden können, dass sie weithin verfügbar sind, solange sie einigermaßen aktuell sind und keine Ergebnisse melden, die übermäßig falsch sind oder anderweitig über eine gegebene Fehlertoleranz hinausgehen.
  • In einigen Implementierungen kann ein Speichersystem, das Daten synchron repliziert, mehrere verschiedene Vermittlerpräferenzen implementieren. Wenn man zum Beispiel eine Liste von Vermittlerdiensten zur Auswahl hat, kann ein Satz von Speichersystemen bestimmen, ob einige Vermittlerdienste in irgendeiner Weise besser sind als andere, oder sie können einige Vermittlerdienste ganz ausschließen. In einigen Beispielen könnten Vermittlerdienst-Präferenzen auch für einen Speichersystem-Pod oder für Speichersysteme oder für eine bestimmte IT-Abteilung oder einen Kunden definiert werden, und zwar explizit durch einen Mechanismus, z.B. durch das Festlegen eines Wertes, der nach Präferenz sortiert werden kann, oder durch die Kennzeichnung von Vermittlerdiensten als für einen bestimmten Zweck bevorzugt oder für einige Speichersysteme oder Pods.
  • Bei einigen Implementierungen ist, wie bereits erwähnt, im Hinblick auf die Parameter des Vermittlers, der Standort des Vermittlerdienstes ein nützlicher Parameter. Wenn z.B. der Standort des Vermittlerdienstes bekannt ist und der Standort eines Speichersystems bekannt ist, dann kann der Standort des Vermittlerdienstes auf der Grundlage eines relativen Standorts eines bestimmten Speichersystems und eines Vermittlerdienstes gewählt werden - wobei ein näher gelegener oder schneller erreichbarer Vermittlerdienst gegenüber weiter entfernten Vermittlerdiensten bevorzugt werden kann. Ferner kann in einigen Beispielen, wenn Speichersysteme zu einem Pod hinzugefügt werden, der Standort des Vermittlerdienstes im Hinblick auf die hinzugefügten Speichersysteme neu bewertet werden. Wenn ein Pod zwei vermittlungsfähige Speichersysteme enthält und diese beiden Speichersysteme sich in getrennten Datenzentren befinden, kann ein Vermittlerdienst ausgewählt werden, der sich in einem dritten Datenzentrum befindet. Mit anderen Worten, ein Vermittlerdienst kann auf der Grundlage der Implementierung in einem Datenzentrum ausgewählt werden, das unabhängig von dem einen oder den mehreren Datenzentren ist, die einen Speichersystem-Pod implementieren, um eine größere Zuverlässigkeit und/oder Verfügbarkeit des Vermittlerdienstes zu gewährleisten, falls das eine oder die mehreren Datenzentren, die den Speichersystem-Pod implementieren, Netzwerkfehler, Stromausfälle oder eine andere Art von Datenzentrumsfehler aufweisen. In anderen Fällen jedoch, wenn sich mehrere vermittlungsfähige Speichersysteme für einen Pod im selben Datenzentrum befinden, kann ein Vermittlerdienst innerhalb desselben Datenzentrums gewählt werden, wobei jedoch ein Netzwerk-Layout in Bezug auf den Vermittlerdienst und die Speichersysteme in Betracht gezogen werden kann; beispielsweise kann ein Vermittlerdienst so gewählt werden, dass ein Kommunikationsfehler zwischen den Speichersystemen wahrscheinlich nicht mit einem Kommunikationsfehler zwischen allen vermittlungsfähigen Speichersystemen und dem gewählten Vermittlerdienst zusammenfällt.
  • In einigen Implementierungen, wie z.B. im Fall von Vermittlerdiensten, die von der Cloud oder von Anbietern angeboten werden, kann entweder die Geographie markiert oder das Netzwerk auf Antwortzeiten, Netzwerk-Hops oder Netzwerk-Adressbereiche untersucht werden. Ein von einer Cloud oder einem Anbieter bereitgestellter Vermittlerdienst kann geografische Standortinformationen ohne großen Aufwand bereitstellen. Im Falle einer Implementierung eines lokalen Speichersystems für die synchrone Replikation von Daten können geographische Informationen jedoch aus Netzwerkinformationen wie IP-Adressen oder Geolokalisierung und anderen Verfahren abgeleitet werden. Darüber hinaus wird die synchrone Replikation in der Regel nicht über sehr große Entfernungen implementiert, so dass Speichersysteme, die Elemente eines Pods sind, sich typischerweise innerhalb einer Geografie befinden und mit ähnlicher Latenz und Netzwerk-Hop-Zahl wie typische von der Cloud oder von Anbietern bereitgestellte Vermittlerdienste innerhalb dieser Geografie verbunden werden können.
  • Bei einigen Implementierungen, wie oben erörtert, kann die Standortinformation mehrere Aspekte aufweisen. Zum Beispiel Informationen über Rechenzentren, Informationen über das Netzwerklayout innerhalb eines Rechenzentrums, Informationen über Strom- und Kühlzonen innerhalb eines Rechenzentrums, Informationen über das Stromnetz der zivilen Infrastruktur, Informationen über Rechenzentrumskomplexe, Beschreibungen städtischer Gebiete, Informationen über Betriebszonen, Informationen über kontrollierende Regierungseinheiten und andere Informationen, wobei Vermittlerdienste und Speichersysteme mit einer beliebigen Menge oder Teilmenge dieser und anderer Arten von Standortinformationen gekennzeichnet sein können. Darüber hinaus kann in einigen Beispielen eine beliebige Anzahl dieser verschiedenen Aspekte von Ortsinformationen gleichzeitig berücksichtigt werden, so dass, wenn vermittlungsfähige Speichersysteme für einen Pod durch einen bestimmten Parameter voneinander getrennt zu sein scheinen, ein Vermittlerdienst ausgewählt werden kann, der in Bezug auf diesen bestimmten Parameter von jedem der vermittlungsfähigen Speichersysteme unabhängig ist. In einigen Fällen können Aspekte der Standortinformationen vorrangig behandelt werden. Zum Beispiel können sich zwei Speichersysteme in verschiedenen Betriebszonen befinden, aber es kann keine dritte Betriebszone geben, obwohl es ein drittes Stromnetz gibt.
  • Bei einigen Implementierungen können im Hinblick auf die Parameter des Vermittlers die Gesundheitsgeschichte und die geplante Ausfallzeit als Grundlage für die Auswahl eines Vermittlerdienstes in Betracht gezogen werden. Wenn z.B. eine geplante Ausfallzeit für eine Computerumgebung, die einen Vermittlerdienst implementiert, im Voraus geplant werden kann, kann ein Speichersystem, das einen Pod implementiert, Zeit haben, zu einem anderen Vermittler als dem Vermittlerdienst zu wechseln, der vor der Ausfallzeit für die Ausfallzeit geplant war - wobei das Speichersystem nach der geplanten Ausfallzeit wieder zurückschalten kann oder das Speichersystem so lange bei dem auf den Vermittlerdienst umgeschalteten Dienst verbleibt, bis ein anderes Ereignis einen weiteren Wechsel veranlasst.
  • In einigen Implementierungen kann ein Faktor für die Auswahl eines Vermittlerdienstes darauf beruhen, dass eine Einrichtung als Host für den Vermittlerdienst fungiert. Beispielsweise kann eine IT-Abteilung vor Ort lokal implementierte Vermittlerdienste bevorzugen, aber auch die Nutzung eines von einer Cloud oder einem Anbieter bereitgestellten Vermittlerdienstes akzeptieren, wenn ein geeigneter lokaler Vermittlerdienst nicht verfügbar ist oder offline genommen wird, z.B. für Wartungsarbeiten, oder wenn ein geeigneter dritter Standort noch nicht konfiguriert ist. Darüber hinaus kann es in einigen Beispielen vorkommen, dass ein Anbieter es vorzieht, dass Kunden für den Anbieter einen öffentlichen Cloud-basierten Vermittlerdienst nutzen, aber es den Kunden erlauben kann, während eines Ausfalls der öffentlichen Cloud oder zur Verbesserung der Vermittler-Reaktionszeit (z.B. weil ein Cloud-Dienst unter einem Denial-of-Service-Angriff steht oder keine Datenzentren in einer Region wie China oder der Antarktis betreibt) einen vom Anbieter gehosteten Back-End-Vermittlerdienst zu nutzen.
  • In einigen Implementierungen können angesichts einer Liste verfügbarer und konfigurierter Vermittlerdienste aus beliebigen Quellen (explizite Konfiguration, Vermittlerdienst-Broker usw.) einige Vermittlerdienste von der Berücksichtigung ausgeschlossen werden, um als Vermittler zu dienen, wenn bestimmte Anforderungen nicht erfüllt oder nicht eingehalten werden (z.B. befinden sich vermittlungsfähige Speichersysteme für einen Pod in getrennten Datenzentren, aber ein bestimmter Vermittlerdienst befindet sich in einem dieser Datenzentren) oder wenn eine Ausfallzeit geplant ist. In einigen Beispielen können andere Vermittlerdienste nach Priorität sortiert werden, basierend auf einer oder mehreren der folgenden Kriterien: Gesundheit oder Gesundheitsgeschichte, Eignung gemäß einer oder mehreren Präferenzen oder Anforderungen, planmäßige Wartung, Geographie, Netzwerk-Sprünge, um einen bestimmten Vermittlerdienst zu erreichen, Netzwerk-Latenzzeit zum Vermittlerdienst, Netzwerk-Subnetze und andere.
  • In einigen Implementierungen kann im Hinblick auf die Auswahl eines Vermittlerdienstes eine aktuelle Liste potenzieller Vermittlerdienste evaluiert und der am besten geeignete Vermittlerdienst ausgewählt werden, der einer oder mehreren Anforderungen entspricht, oder die Auswahl könnte den meisten Anforderungen mit hoher Priorität entsprechen. Wie bereits erwähnt, kann eine Liste potentieller Vermittlerdienste von Zeit zu Zeit neu evaluiert werden oder auf Ereignisse reagieren, die Änderungen im Status des Vermittlerdienstes oder der Aufnahme weiterer verfügbarer Vermittlerdienste entsprechen.
  • Bei einigen Implementierungen ist eine zukünftige Vermittlung möglicherweise nur für einen Pod erforderlich, wenn es derzeit mehr als ein aktives Online-Vermittlung-fähiges Speichersystem gibt. In einigen Beispielen können frühere (vielleicht vermittelte) Fehler bereits dazu geführt haben, dass einige Speichersysteme für einen Pod offline geworden sind. Solange eines dieser Speichersysteme nicht wieder online ist, spielt es in einem solchen Beispiel möglicherweise keine Rolle, wie sich die Offline-Speichersysteme zu einem bestimmten Vermittlerdienst verhalten. Damit in diesem Beispiel ein Speichersystem für einen Pod wieder online gehen und die Vermittlung wieder aktiviert werden kann, muss das Speichersystem, das für den Pod offline war, zunächst sicherstellen, dass es einen zuverlässigen Zugang zu einem geeigneten Vermittlerdienst hat, der von den Speichersystemen gemeinsam genutzt wird und auf den der Vermittlerdienst zuverlässig von dem bestehenden, für die Vermittlung aktivierten Online-Speichersystem für den Pod zugreifen kann. In diesem Beispiel kann dies dazu führen, dass die bestehenden vermittlungsfähigen Online-Speichersysteme zu einem neuen Vermittler wechseln, um das zusätzliche vermittlungsfähige Speichersystem wieder online zu bringen. In einigen Beispielen handelt es sich um einen degenerierten Fall, bei dem ein Fehler oder eine Folge von Fehlern dazu führte, dass genau ein vermittlungsaktiviertes Speichersystem für einen Pod online blieb. In diesem Fall ist eine Vermittlung nicht mehr notwendig, bis ein anderes vermittlungsaktiviertes Speichersystem wieder online geht.
  • In einigen Implementierungen, in denen ein Speichersystem nicht für die Verwendung eines Vermittlerdienstes konfiguriert ist, kann das Speichersystem online bleiben und weiterhin synchron Daten für einen Pod replizieren oder nach der Rückkehr in den Offline-Zustand wieder einem Pod beitreten, wobei die Speichersysteme online und in-sync bleiben, wenn sie mit anderen Speichersystemen kommunizieren können. Wenn Speichersysteme in diesem Beispiel jedoch nicht in der Lage sind, miteinander zu kommunizieren, kann ein Speichersystem offline bleiben, bis eine Kommunikationsverbindung wiederhergestellt ist. Ferner kann in diesem Beispiel, wenn ein Vermittlerdienst nicht verfügbar ist oder wenn ein Speichersystem nicht für die Verwendung eines Vermittlerdienstes konfiguriert ist, das Speichersystem ein oder mehrere Quorum-Protokolle implementieren, wie zuvor besprochen. Darüber hinaus können in diesem Beispiel zusätzliche Speichersysteme, die derzeit nicht zu einem Pod gehören, hinzugefügt werden, um den Satz der Speichersysteme zu erweitern, die an dem einen oder den mehreren Quorum-Protokollen teilnehmen.
  • In einigen Implementierungen kann ein Speichersystem als Reaktion auf Änderungen der Zuverlässigkeit des Vermittlers oder der Verfügbarkeit des Vermittlers zu alternativen Modellen wechseln. In diesem Beispiel kann ein Speichersystem als Reaktion auf die Nichtverfügbarkeit oder Unzuverlässigkeit eines ersten Vermittlerdienstes auf einen alternativen Vermittlerdienst zu wechseln - was eine Reaktion unter anderen möglichen Reaktionen ist. Eine andere Reaktion darauf, dass ein Vermittlerdienst nicht verfügbar oder unzuverlässig wird, ist z.B. das Vermitteln von Cluster-Verfügbarkeitsmodellen. In Fortführung dieser Beispiele wurden in den früher erwähnten Anwendungen andere Verfügbarkeitsmodelle vorgeschlagen, darunter Quorum-Modelle und Präferenzmodelle. In einigen Fällen ist ein Präferenzmodell ein besonders anwendbares Alternativmodell, da eine effiziente Reaktion auf die Nichtverfügbarkeit geeigneter Vermittlerdienste darin besteht, dass sich die Speichersysteme für einen Pod auf ein bevorzugtes Speichersystem einigen, das für einen Pod online bleibt, wenn ein späterer Fehler die Kommunikation der Speichersysteme für den Pod verhindert. In diesem Beispiel kann das Präferenzmodell sicher funktionieren, solange dieser Übergang zu einem Präferenzmodell vor einem Fehler, der andernfalls vermittelt worden wäre, zuverlässig und ausreichend kommuniziert wird. Als spezifischeres Beispiel kann bei einem Pod mit zwei vermittlungsaktivierten Speichersystemen für den Fall, dass sich der Vermittlerdienst als nicht verfügbar oder unzuverlässig erweist, eines dieser beiden Speichersysteme gewählt werden, und wenn die beiden Speichersysteme anschließend nicht mehr miteinander kommunizieren, dann kann das bevorzugte Speichersystem für die Wartung oder Instandhaltung des Pods online bleiben (vorausgesetzt, dass das bevorzugte Speichersystem ordnungsgemäß funktioniert) und das andere, nicht bevorzugte Speichersystem für den Pod offline gehen (unabhängig davon, ob es ordnungsgemäß funktioniert und ob das andere Speichersystem ordnungsgemäß läuft). Zum Abschluss dieses Beispiels kann diese Situation erneut evaluiert werden, bis die fortgesetzte Überwachung der Vermittlerdienste darauf hinweist, dass wieder ein geeigneter, verfügbarer und ausreichend zuverlässiger Vermittlerdienst für das Speichersystem ausgewählt werden kann.
  • Wenn es in einigen Implementierungen mehr als zwei vermittlungsfähige Speichersysteme gibt, die einen Pod implementieren, und mindestens zwei der Speichersysteme immer noch zuverlässig auf einen gemeinsamen Vermittlerdienst zugreifen können, eines oder mehrere aber nicht, dann muss die Unfähigkeit der zusätzlichen Speichersysteme, zuverlässig auf den Vermittlerdienst zuzugreifen, möglicherweise nicht zu einem Wechsel zu einem Präferenzmodell oder einem anderen Modell führen, da die Vermittlung nur zwischen diesen beiden als ausreichend zuverlässig und besser als der Wechsel zu einem Präferenzmodell angesehen werden könnte. Um mit diesem Beispiel fortzufahren: Selbst wenn nur ein vermittlungsfähiges Speichersystem für einen Pod auf einen Vermittlerdienst zugreifen kann, könnte die Vermittlung bestehen bleiben, anstatt zu einem Präferenzmodell zu wechseln, was im Wesentlichen bedeutet, dass im Falle eines Ausfalls nur das Speichersystem, das mit dem Vermittlerdienst kommuniziert, übernehmen kann, bis die Situation behoben ist. In diesem Beispiel kann das Speichersystem in Kommunikation mit dem übernehmenden Vermittlerdienst vorzuziehen sein, wobei selbst nach vollständiger Nichtverfügbarkeit eines geeigneten Vermittlerdienstes ein Pod auf ein bevorzugtes Speichersystem umschalten kann, nachdem mindestens ein Speichersystem zuverlässig auf einen Vermittlerdienst zugreift, anstatt auf mehrere Speichersysteme oder alle Speichersysteme zu warten. In diesem Beispiel ist nur ein Speichersystem, das vermitteln kann, nicht schlechter als ein Präferenzmodell, da der Vermittlerdienst verfügbar bleibt und es einem anderen Speichersystem ermöglicht, die Vermittlung zu gewinnen, wenn das Problem behoben ist - selbst dann, wenn alle Speichersysteme ausfallen und einige mit reparierten Verbindungen des Vermittlerdienstes wieder hochkommen.
  • In einigen Implementierungen kann das Speichersystem für den Pod als Reaktion auf das derzeit aktive und online vermittlungsfähige Speichersystem für einen Pod, das feststellt, dass einige oder alle früheren zuverlässig verfügbaren und geeigneten Vermittlerdienste für den Pod nicht mehr zuverlässig oder verfügbar sind, und als Reaktion auf die Entscheidung, auf ein Präferenz-Fehlerbehandlungsmodell umzuschalten, zumindest bis sich der Zustand teilweise oder vollständig erholt, eine Vielzahl von Modellen verwenden, um zu entscheiden, ob einem Speichersystem oder einem anderen Speichersystem für den Pod der Vorzug gegeben werden soll. In einigen Fällen können verschiedene Modelle auf der Grundlage eines oder mehrerer Faktoren ausgewählt werden, die u.a. folgenden Faktoren entsprechen: Host-Konnektivität, Host-Standorte, Stromlast, Netzwerkpfade oder Latenz zwischen Hosts und einzelnen Speicher-Controllern oder Netzwerkadaptern auf einzelnen Speichersystemen innerhalb des Pods. In anderen Fällen kann eine Fallback-Präferenz explizit konfiguriert werden, oder es können verfügbare Informationen über Anwendungen und Dienste, die auf Hosts laufen, und ihre Fähigkeit, sich an den Verlust des Zugriffs auf das eine oder andere Speichersystem anzupassen, verfolgt werden.
  • Darüber hinaus kann in einigen Beispielen als Reaktion auf den Wechsel von der vermittelten Verfügbarkeit zur bevorzugten Verfügbarkeit die Änderung an eine hostseitige Geräte-, Anwendungs- oder Rechenzentrums-Betriebsinfrastruktur kommuniziert werden, was dazu führen kann, dass einige Anwendungen oder Dienste verschoben werden, um den neuen Speichersystempräferenzen zu entsprechen. In anderen Fällen könnten einige Anwendungen oder Dienste so konfiguriert werden, dass sie bei Zugriffsproblemen auch selbst zu den Standorten oder Zugriffspfaden wechseln, die mit dem bevorzugten Speichersystem für den Pod verbunden sind. Auf diese Weise kann in diesem Beispiel die bidirektionale Kommunikation mit anderen Anwendungen und Diensten, die auf die Speicherung von Daten angewiesen sind, für die Handhabung dieser Anwendungen und Dienste von Vorteil sein.
  • In einigen Implementierungen kann ein Speichersystem für einen Pod verschiedene Techniken zur Verwaltung der Notfallwiederherstellung implementieren. Beispielsweise besteht ein Modell für die Konfiguration von Hosts, Anwendungen und Speichersystemen für die Notfallwiederherstellung darin, eine Reihe von Speichersystemen und Servern zu haben, die für eine Reihe von Anwendungen und Diensten an einem ersten Standort zusammenlaufen, bei dem jedoch Verfahren vorhanden sind, um Speichersysteme, Anwendungen und Dienste an einem zweiten Standort zusammenzubringen, wenn ein ausreichend katastrophaler Fehler auftritt, so dass der erste Standort kritische Anwendungen und Dienste nicht mehr bedienen kann (Überschwemmungen, längerer Ausfall des Stromnetzes und Terrorismus sind häufig angeführte Beispiele, häufiger sind jedoch menschliches Versagen und Netzwerkisolation). Bei einigen Implementierungen besteht eine Technik zur Bewältigung dieser Situation darin, sich auf einen übergeordneten Überwachungs- und Hochverfügbarkeitsdienst zu verlassen, um die Speicherzugänglichkeit zusammen mit Anwendungen und Diensten vom ersten Standort zum zweiten Standort zu migrieren und die gesamte Migration als Reaktion darauf durchzuführen, dass der übergeordnete Überwachungs- und Hochverfügbarkeitsdienst feststellt, dass eine solche Migration notwendig ist. In einigen Umgebungen kann diese Änderung nicht automatisch, sondern durch menschliches Eingreifen über eine Steuerschnittstelle ausgelöst werden.
  • In einigen Implementierungen ist die Speicherung ein besonders kritischer Aspekt der Zugriffsmigration, da der Speicher besonders anfällig dafür ist, beschädigt oder nicht wiederherstellbar zu werden, wenn Dienste versehentlich an zwei Standorten ausgeführt werden. Ein Beispiel für die Handhabung von Diensten, die an zwei Standorten mit geringerer Beschädigungsgefahr laufen, ist die Verwendung von Snapshots als Reaktion auf einen Dienst höherer Ebene, der die Migration des Speicherzugriffs auf einen zweiten Standort auslöst. In diesem Modell könnte ein Speichersystem am zweiten Standort für einen Pod so konfiguriert sein, dass es nicht vermittelt, nicht am Quorum teilnimmt oder es vorzieht, selbst den Pod zu übernehmen. Wenn in diesem Beispiel ein Pod nur zwei Speichersysteme umfasst, wobei sich ein Speichersystem an einem ersten Standort und ein weiteres Speichersystem an einem zweiten Standort befindet, dann kann der erste Standort bevorzugt werden. Um mit diesem Beispiel fortzufahren, könnte der erste Standort (oder ein erster Standort und ein dritter Standort) andernfalls mehrere Speichersysteme für den Pod umfassen, die so konfiguriert sein können, dass sie die Beschlussfähigkeit zwischen ihnen vermitteln oder nutzen (oder eine Teilmenge dieser Speichersysteme bevorzugen könnten), aber die Speichersysteme am zweiten Standort würden nicht an einer Beschlussfähigkeit teilnehmen und im Falle von Fehlern offline werden, die die Speichersysteme am zweiten Standort daran hindern, mit anderen Online-, In-Sync-Speichersystemen für den Pod zu kommunizieren.
  • Um mit diesem Beispiel fortzufahren, könnte in diesem Modell die Speicherübernahme im zweiten Rechenzentrum das Erstellen einer logischen Kopie beliebiger Pods umfassen, um neue Pods zu bilden, wobei die neuen Pods und Speichereinheiten (Datenträger, Dateisysteme, Objektspeicher usw.) ausreichend unterschiedliche Identitäten haben, so dass die logische Kopie jeder dieser Pods von Hosts, Anwendungen oder Diensten nicht mit solchen Speichereinheiten und Pods verwechselt wird, die möglicherweise noch am ersten (oder anderen) Standort (oder Standorten) laufen. Darüber hinaus sind Beispielmodelle für das Kopieren eines Pods, einschließlich des logischen Kopierens eines Pods auf ein Speichersystem, das derzeit für den Pod offline ist, in der U.S. Patentanmeldung Nr. 62/518,071 enthalten, die hierin in ihrer Gesamtheit aufgenommen ist.
  • Wenn in einigen Beispielen ein Netzwerk- oder Kommunikationsfehler behoben ist und der ursprüngliche Pod für die Speichersysteme am ersten und zweiten Standort wieder online gehen kann, dann kann zu diesem Zeitpunkt die logische Kopie des Pods als Teil einer koordinierten Failback-Operation logisch auf den ursprünglichen Pod zurückkopiert werden, wobei zunächst sichergestellt wird, dass die betroffenen Hosts, Anwendungen und Dienste am ersten Standort (und an anderen Standorten) offline sind, bevor der Pod logisch zurückkopiert wird. In diesem Beispiel kann dabei z.B. vorübergehend von asynchroner oder periodischer Replikation Gebrauch gemacht werden, oder es können Modelle wie Resynchronisationsverfahren der synchronen Replikation verwendet werden, um den ursprünglichen Pod auf den neuesten Stand zu bringen, bevor die Hosts, Anwendungen und Dienste am ersten Standort (und möglicherweise an anderen Standorten) ausfallen. Außerdem könnte in diesem Beispiel vor dem logischen Zurückkopieren auf den Original-Pod eine Momentaufnahme dieses Pods erstellt werden, um sicherzustellen, dass Aktualisierungen nicht verloren gehen.
  • Um mit diesem Beispiel fortzufahren, können logische Kopien von Pods an einem zweiten Standort auch für Tests verwendet werden, z. B. als Teil eines Verfahrens, mit dem sichergestellt werden soll, dass alle kritischen Datensätze ordnungsgemäß an den zweiten Standort repliziert werden, oder für andere Verwendungszwecke einer logischen Kopie eines Datensatzes, z. B. für laufende Berichte oder für die Verwendung von Kopien von Produktionsdaten für Entwicklungs- oder Forschungszwecke, die logisch von den Produktionsstandorten isoliert sind. Darüber hinaus können in einigen Fällen Identitäten, die als Teil der Herstellung und Präsentation einer geeigneten Kopie eines Pods geändert werden müssen, Fibre-Channel-Kennungen, Netzwerkadressen, iSCSI-IQNs, SCSI-Seriennummern, Volume-Kennungen, Pod-Kennungen, eindeutige Dateisystem-Kennungen, Dateisystem-Exportnamen oder Objektpool-/Bucket-Kennungen enthalten. In einigen Fällen können die Namen gleichbleiben, selbst wenn die zugrunde liegenden Bezeichner geändert werden (was ausreichen kann, um beispielsweise sicherzustellen, dass ein Multipathing-Festplattentreiber nicht verwechselt wird). In anderen Fällen können auch Namen geändert werden, z.B. weil Übernahmeskripte und Prozeduren geschrieben werden, um neue Namen für speicherbezogene Entitäten als Teil der Durchführung einer Übernahme zu verwenden.
  • In einigen Implementierungen kann ein Speichersystem unterschiedliche Modelle auf pod-übergreifende Konsistenzgruppen anwenden. Beispielsweise kann ein konsistenter Datensatz in einigen Fällen mehr als einen Pod umfassen oder Pods umfassen, die auf unterschiedlichen oder sich überlappenden Sätzen von Speichersystemen operieren. Wenn in diesem Beispiel bei der ordnungsgemäßen Pflege eines pod-übergreifenden Datensatzes bei der Erhaltung des Zugriffs auf Speichersysteme als Teil der Fehlerbehandlung der Standort berücksichtigt werden soll, z.B. weil ein Satz von Anwendungskomponenten und Diensten Daten für einen Satz von Pods an mehr als einem Speichersystem innerhalb jedes Standorts speichert, dann kann eine Technik erforderlich sein, um sicherzustellen, dass automatisierte Online-/Offline-Entscheidungen für mehrere Pods sowie für mehrere Speichersysteme für diese mehreren Pods standortkonsistent sind. In solchen Fällen können Speichersysteme an einem Standort die Vermittlung, die Wahl der Vermittlerserver, die Handhabung des Quorums oder jeden Wechsel von der Vermittlung zur Fehlerpräferenz koordinieren.
  • Um mit diesem Beispiel fortzufahren, könnte in einem Fall ein erster Satz von Speichersystemen S1, S2 und S3 an einem ersten Standort L1 jeweils Elemente der Pods P1, P2 bzw. P3 sein, während ein zweiter Satz von Speichersystemen S'1, S'2 und S'3 an einem zweiten Standort L2 ebenfalls Elemente der Pods P1, P2 bzw. P3 sind. In diesem Beispiel könnte eine Gruppe von Anwendungen und Diensten, die derzeit auf Hosts am Ort L1 laufen, erwarten, als Gruppe auf Hosts in L2 migriert zu werden, wenn ein Fehler dies erforderlich macht. In solchen Fällen muss der Standort von Speichersystemen, die für alle drei Pods aufgrund einer Folge von Fehlern online bleiben, unter Umständen zwischen allen drei Pods konsistent sein. Zum Beispiel müssen im Falle eines Netzwerkfehlers, der die Kommunikation zwischen den Standorten L1 und L2 unterbricht, alle drei Pods entweder zu S1, S2 und S3 am Standort L1 oder zu S'1, S'2 und S'3 am Standort L2 wechseln und können ihre Ergebnisse nicht anderweitig mischen. Wenn ein Speichersystem am ersten Standort, z.B. S1 am Standort L1, Störungen aufweist, können alle drei Pods am Standort L2 online bleiben, aber wenn es eine zweite Störung gibt, an der ein Speichersystem am zweiten Standort, z.B. S'3, beteiligt ist, dann müssen alle drei Pods möglicherweise an beiden Standorten offline gehen, bis die Situation repariert ist, da keiner der beiden Standorte über einen vollständigen Datensatz verfügt. Implementierungen könnten S2 unterstützen, und S3 könnte entweder offline gehen oder nach nur S1-Fehlern im vorherigen Beispiel online bleiben.
  • Darüber hinaus können im Falle von Präferenzmodellen die bevorzugten Speichersysteme für alle drei Pods identisch konfiguriert werden, z.B. indem jeder Pod die Speichersysteme am ersten Standort bevorzugt. Diese Lösung kann so lange funktionieren, wie nicht zu erwarten ist, dass eine Störung eines ersten Speichersystems am zweiten Standort dazu führt, dass das zweite und dritte Speichersystem am zweiten Standort ebenfalls offline gehen.
  • Bei einigen Implementierungen können Vermittler- oder Quorum-Modelle komplizierter sein. Im Falle von Vermittler- oder Quorum-Modellen können die Pods beispielsweise nicht in der Lage sein, Entscheidungen getrennt voneinander zu treffen, wenn diese getrennten Entscheidungen zu unterschiedlichen Ergebnissen führen können. Im Allgemeinen reicht es allein nicht aus, dass die Pods lediglich denselben Vermittlerdienst oder dieselbe Beschlussfähigkeitskonfiguration teilen. Im Falle eines Vermittlerdienstes ist es möglich, dass ein Schlüssel und ein erster Wert von Speichersystemen am ersten Standort gemeinsam genutzt werden, während derselbe Schlüssel und ein bestimmter zweiter Wert von Speichersystemen am zweiten Standort gemeinsam genutzt werden, so dass ein erstes Speichersystem, das bei einem Ausfall erfolgreich vermittelt, sicherstellen kann, dass nur andere Speichersysteme am selben Standort erfolgreich sein können, weil sie unter Verwendung desselben Schlüssels und Wertes vermitteln. Ein zuverlässiger Wechsel der Vermittler ist in einem solchen Modell jedoch komplizierter, und nach einem erfolgreichen Einsatz der Vermittlung innerhalb eines Pod-Speichers erfordert der nachfolgende Einsatz der Vermittlung zur Behandlung nachfolgender Fehler eine neue Schlüssel/Wert-Kombination (je nach Vermittlermodell), die dann erneut ausgetauscht werden müsste.
  • In einigen Implementierungen können sich alternativ zum vorhergehenden Beispiel Speichersysteme für sich erstreckende Pods an einem ersten Standort auf ein einziges Speichersystem einigen, um sich an der Vermittlung oder an Quorum-Protokollen für diese Speichersysteme an diesem ersten Standort zu beteiligen, wobei von diesen Speichersystemen erwartet wird, dass sie Fehler für die sich erstreckenden Pods konsistent behandeln. Darüber hinaus könnten sich in diesem Beispiel Speichersysteme an anderen Orten ebenfalls auf ein bestimmtes ihrer Speichersysteme einigen, sich an der Vermittlung oder an Quorum-Protokollen im Namen dieser anderen Orte zu beteiligen.
  • In einigen Implementierungen könnten Speichersysteme an einem Standort eine von mehreren Techniken zur Koordinierung verwenden, welches Speichersystem vermittelt oder sich an Quorum-Protokollen beteiligt, wobei in einigen Fällen ein Speichersystem dafür eingesetzt werden kann. Zum Beispiel könnten Speichersysteme untereinander abstimmen. In anderen Beispielen können Speichersysteme innerhalb eines Standorts die Vermittlung untereinander an einen Vermittlerdienst nutzen, der innerhalb des Standorts oder über einen Cloud-Dienst oder einen vom Anbieter bereitgestellten Dienst läuft, um zu bestimmen, wer im Namen des Standorts vermitteln kann. Im Allgemeinen kann jedes Modell funktionieren, das zu einem einzigen, vereinbarten Speichersystem führt, das zu einem bestimmten Zeitpunkt verwendet werden kann. In einigen Fällen ist ein Protokoll für wechselnde Vermittler ein Beispiel für ein Modell, das zur Anpassung an solche Änderungen verwendet werden könnte.
  • Im Allgemeinen kann ein anderes Datenverarbeitungsgerät als ein Speichersystem im Namen von Speichersystemen an einem Ort, der konsistent zusammenarbeiten sollte, eine Vermittlung oder ein Quorum-Protokoll durchführen. In einigen Beispielen könnte stattdessen irgendwo an einem Standort ein Dienst laufen, der die konsistente Koordination mehrerer Standorte für diesen Standort übernimmt. Auf diese Weise können in diesem Beispiel Speichersysteme, die sich auf koordinierte Konsistenz in Bezug auf einen gemeinsamen Standort im Namen eines Satzes von Pods verlassen, für die Koordinierung durch diesen Dienst registriert werden. In diesem Beispiel kann der Dienst zur Selbstverwaltung Protokolle mit hoher Verfügbarkeit oder Vermittlung oder Quorum innerhalb des Standorts verwenden, und der Dienst könnte zum Zeitpunkt der Vermittlung oder des Quorum-Austauschs auch ein zuverlässiges verteiltes Vereinbarungsmodell verwenden, z.B. durch Verwendung eines PAXOS- oder RAFT-basierten Modells innerhalb des Standorts. In einigen Fällen könnte dieser Prozess auf ein ausreichend zuverlässiges, gemeinsam genutztes Cluster-Dateisystem zurückgreifen, das innerhalb des Standorts läuft.
  • Zur weiteren Erläuterung ist in 9 ein Flussdiagramm dargestellt, das die Schritte für ein Speichersystem zum wechseln zwischen verschiedenen Fehlerreaktionsmodellen gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Obwohl es weniger detailliert dargestellt ist, kann das in 9 dargestellte Speichersystem (814) den oben mit Bezug auf die 1A-1D, 2A-2G, 3A-3B und 4-8 beschriebenen Speichersystemen oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 9 dargestellten Speichersysteme (814) die gleichen, weniger oder zusätzliche Komponenten enthalten wie die oben beschriebenen Speichersysteme.
  • In der in 9 dargestellten Beispielmethode kann ein Speichersystem (814) in einem Anfangszustand eine oder mehrere Kommunikationsverbindungen aufweisen, die zwischen einem oder mehreren Speichersystemen und zwischen einem Vermittlerdienst (952) in Betrieb sind, wobei zumindest einige der Speichersysteme so konfiguriert sind, dass sie eine Vermittlung von einem Vermittlerdienst (952) anfordern. Mit anderen Worten, wie oben diskutiert, sind in einigen Beispielen einige, aber nicht alle Speichersysteme, die einen Datensatz synchron replizieren, vermittlungsfähig.
  • Das in 9 dargestellte Beispielverfahren umfasst das Bestimmen (904) einer Änderung der Verfügbarkeit des Vermittlerdienstes (952) unter einem oder mehreren einer Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung vom Vermittlerdienst anfordern. Das Bestimmen (904), unter dem einen oder mehreren der Mehrzahl von Speichersystemen, der Änderung in der Verfügbarkeit des Vermittlerdienstes (952) kann wie oben beschrieben im Hinblick auf verschiedene Techniken zum Bestimmen implementiert werden, wenn ein Vermittlerdienst nicht mehr antwortet, nicht mehr erreichbar ist oder begonnen hat, außerhalb einer Schwellenantwortzeit zu antworten.
  • Das in 9 dargestellte Beispielverfahren umfasst auch das Vermitteln (906) eines Fehlerreaktionsmodells, das als Alternative zum Vermittlerdienst (952) unter einem oder mehreren der Speichersysteme zu verwenden ist, zwischen der Vielzahl von Speichersystemen und ansprechend auf das Bestimmen der Änderung der Verfügbarkeit des Vermittlerdienstes (952). Das Vermitteln (906), zwischen der Vielzahl von Speichersystemen und ansprechend auf das Bestimmen der Änderung der Verfügbarkeit des Vermittlerdienstes (952), kann das als Alternative zum Vermittlerdienst (952) zu verwendende Fehlerreaktionsmodell unter dem einen oder den mehreren der Vielzahl von Speichersystemen implementiert werden, wie oben beschrieben in Bezug auf verschiedene Techniken zum Umschalten von einem Fehlerreaktionsmodell, das auf einem Vermittlerdienst basiert, zu einem Fehlerreaktionsmodell, das unter einem oder mehreren der Speichersysteme, die Daten synchron replizieren, eingerichtet wird.
  • Auf diese Weise kann für den Fall, dass ein Vermittlerdienst (952), der gegenwärtig ein vereinbarter Vermittlerdienst ist, unzuverlässig wird, um zwischen den Speichersystemen zu vermitteln, ein Speichersystem zu einem alternativen Vermittlungsmodell wechseln, bevor der gegenwärtige Vermittlerdienst (952) völlig versagt, anstatt einfach weniger zuverlässig zu werden. Mit anderen Worten, wenn in einigen Beispielen ein Vermittler völlig ausfällt oder weniger zuverlässig wird, und wenn die Speichersysteme miteinander kommunizieren, dann können die Speichersysteme entweder einen Wechsel des Vermittlerdienstes oder einen Wechsel zu einem anderen Fehlerreaktionsmodell koordinieren - wenn dieser Wechsel vor dem Ausfall eines Speichersystems oder einer Netzwerkverbindung zwischen Speichersystemen koordiniert wird, kann der Pod ohne Unterbrechungen weiterhin verfügbar sein. Kurz gesagt, in einigen Beispielen können die Speichersysteme, die einen Pod implementieren, in Erwartung eines Ausfalls präventiv vor einem Fehler zwischen Fehlerreaktionsmodellen umschalten, um die Nichtverfügbarkeit des Pod zu vermeiden.
  • Zur weiteren Erläuterung ist in 10 ein Flussdiagramm dargestellt, das die Schritte für ein Speichersystem zum Umschalten zwischen verschiedenen Fehlerreaktionsmodellen gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Obwohl es weniger detailliert dargestellt ist, kann das in 10 dargestellte Speichersystem (814) den oben mit Bezug auf die 1A-1D, 2A-2G, 3A-3B und 4-8 beschriebenen Speichersystemen oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 9 dargestellten Speichersysteme (814) die gleichen, weniger, zusätzliche Komponenten enthalten wie die oben beschriebenen Speichersysteme.
  • Das in 10 dargestellte Flussdiagramm ist dem in 9 dargestellten Flussdiagramm insofern ähnlich, als das in 10 dargestellte Flussdiagramm Folgendes einschließt: Bestimmen (904) einer Änderung der Verfügbarkeit des Vermittlerdienstes (952) unter einem oder mehreren einer Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung von dem Vermittlerdienst anfordern; und Vermitteln (906), zwischen der Vielzahl von Speichersystemen und ansprechend auf das Bestimmen der Änderung der Verfügbarkeit des Vermittlerdienstes (952), eines Fehlerreaktionsmodells, das als Alternative zu dem Vermittlerdienst (952) unter dem einen oder den mehreren der Vielzahl von Speichersystemen zu verwenden ist.
  • Das in 10 dargestellte Flussdiagramm - das ein Beispiel zeigt, bei dem das alternative Fehlerreaktionsmodell ein alternativer Vermittlerdienst ist - beinhaltet jedoch auch die Auswahl (1002) des alternativen Vermittlerdienstes (1052) in Abhängigkeit von einem oder mehreren Faktoren (1052) aus einer Liste von Vermittlerdiensten (1054). Das Auswählen (1002), in Abhängigkeit von einem oder mehreren Faktoren (1052), des alternativen Vermittlerdienstes (1052) aus der Liste der Vermittlerdienste (1054) kann wie oben in Bezug auf das Auswählen alternativer Vermittlerdienste aus einer Liste von Vermittlern besprochen durchgeführt werden. Ferner können, wie oben ausführlicher erörtert, der eine oder die mehreren Faktoren einen oder mehrere der folgenden Faktoren einschließen: geographische Nähe, Zuverlässigkeitsinformationen, Netzwerksprünge, um einen gegebenen Vermittlerdienst zu erreichen, Kommunikationsantwortzeit, Verfügbarkeitszone, vordefinierte Prioritätsinformationen, Betriebszoneninformationen, Informationen über Rechenzentrumskomplexe, Informationen über Rechenzentren, Netzwerklayout zwischen dem Speichersystem und einem gegebenen Vermittlerdienst, Stadtgebietsbeschreibung der Vermittlerdienstimplementierung oder Stromnetzinformationen, die einen gegebenen Vermittlerdienst versorgen.
  • Zur weiteren Erläuterung ist in 11 ein Flussdiagramm dargestellt, das die Schritte für ein Speichersystem zum Vermitteln zwischen verschiedenen Vermittlungsmodellen gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Obwohl es weniger detailliert dargestellt ist, kann das in 10 dargestellte Speichersystem (814) den oben mit Bezug auf die 1A-1D, 2A-2G, 3A-3B und 4-8 beschriebenen Speichersystemen oder einer beliebigen Kombination davon ähnlich sein. Tatsächlich können die in 9 dargestellten Speichersysteme (814) die gleichen, weniger, zusätzliche Komponenten enthalten wie die oben beschriebenen Speichersysteme.
  • Das in 11 dargestellte Flussdiagramm ist dem in 10 dargestellten Flussdiagramm insofern ähnlich, als das in 11 dargestellte Flussdiagramm Folgendes einschließt: Bestimmen (904) einer Änderung der Verfügbarkeit des Vermittlerdienstes (952) unter einem oder mehreren einer Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung vom Vermittlerdienst anfordern; und Vermitteln (906), zwischen der Vielzahl von Speichersystemen und ansprechend auf das Bestimmen der Änderung der Verfügbarkeit des Vermittlerdienstes (952), eines Fehlerreaktionsmodells, das als eine Alternative zu dem Vermittlerdienst (952) unter dem einen oder mehreren der Vielzahl von Speichersystemen zu verwenden ist, und Auswählen (1002) eines alternativen Vermittlerdienstes (1052) aus einer Liste von Vermittlerdiensten (1054), in Abhängigkeit von einem oder mehreren Faktoren (1052).
  • Das in 11 dargestellte Flussdiagramm enthält jedoch auch das Vermitteln (1102), das auf das Bestimmen einer zuverlässigen Verbindung zum alternativen Vermittlerdienst (1052) anspricht, von der Untergruppe der Speichersysteme zum Handhaben der Vermittlung zum alternativen Vermittlerdienst (1052) zum Handhaben der Vermittlung. Ein Wechseln (1102), das auf das Bestimmen einer zuverlässigen Verbindung zu dem alternativen Vermittlerdienst (1052) anspricht, von der Teilmenge von Speichersystemen zum Handhaben der Vermittlung zu dem alternativen Vermittlerdienst (1052) zum Handhaben der Vermittlung kann, wie oben in Bezug auf das Umschalten zu einem alternativen Vermittlerdienst diskutiert, implementiert werden.
  • Die Leser werden verstehen, dass die oben beschriebenen Methoden von jeder beliebigen Kombination der oben beschriebenen Speichersysteme ausgeführt werden können. Darüber hinaus kann jedes der oben beschriebenen Speichersysteme auch mit Speicher kombiniert werden, der von einem Cloud-Dienst-Anbieter wie z.B. Amazon™ Web Services („AWS“), Google™ Cloud Platform, Microsoft™ Azure oder anderen angeboten wird. In einem solchen Beispiel können die Elemente eines bestimmten Pods daher sowohl eines der oben beschriebenen Speichersysteme als auch eine logische Darstellung eines Speichersystems enthalten, das aus Speicher besteht, der von einem Cloud-Dienst-Anbieter angeboten wird. Ebenso können die Elemente eines bestimmten Pods ausschließlich aus logischen Darstellungen von Speichersystemen bestehen, die aus Speicher bestehen, der von einem Cloud-Dienst-Anbieter angeboten wird. Beispielsweise kann ein erstes Element eines Pods eine logische Darstellung eines Speichersystems sein, das aus Speicher in einer ersten AWS-Verfügbarkeitszone besteht, während ein zweites Element des Pods eine logische Darstellung eines Speichersystems sein kann, das aus Speicher in einer zweiten AWS-Verfügbarkeitszone besteht.
  • Um die Fähigkeit zu unterstützen, einen Datensatz (oder andere verwaltete Objekte wie virtuelle Maschinen) synchron auf Speichersysteme zu replizieren, die aus Speicher bestehen, der von einem Cloud-Dienst-Anbieter angeboten wird, und alle anderen in der vorliegenden Anwendung beschriebenen Funktionen auszuführen, können Softwaremodule, die verschiedene Speichersystemfunktionen ausführen, auf Verarbeitungsressourcen ausgeführt werden, die von einem Cloud-Dienst-Anbieter bereitgestellt werden. Solche Softwaremodule können z.B. auf einer oder mehreren virtuellen Maschinen ausgeführt werden, die vom Cloud-Dienst-Anbieter unterstützt werden, wie z.B. eine Block Device Amazon™ Machine Image („AMI“-Instanz). Alternativ können solche Softwaremodule in einer Bare-Metal-Umgebung ausgeführt werden, die von einem Cloud-Dienst-Anbieter bereitgestellt wird, wie z.B. einer Amazon™ EC2-Bare-Metal-Instanz, die direkten Zugriff auf Hardware hat. In einer solchen Verkörperung kann die Amazon™ EC2-Bare-Metal-Instanz mit dichten Flash-Laufwerken gekoppelt werden, um effektiv ein Speichersystem zu bilden. In beiden Implementierungen würden die Softwaremodule idealerweise auf Cloud-Ressourcen mit anderen traditionellen Rechenzentrumsdiensten wie z.B. Virtualisierungssoftware und von VMware™ angebotenen Diensten wie vSAN™ zusammengeführt. Die Leser werden verstehen, dass viele andere Implementierungen möglich sind und in den Rahmen der vorliegenden Offenbarung fallen.
  • Die Leser werden verstehen, dass in Situationen, in denen ein Datensatz oder ein anderes verwaltetes Objekt in einem Pod in einem On-Promises-Speichersystem aufbewahrt wird und der Pod sich so erstreckt, dass er ein Speichersystem enthält, dessen Ressourcen von einem Cloud-Dienstanbieter angeboten werden, der Datensatz oder das andere verwaltete Objekt auf das Speichersystem übertragen werden kann, dessen Ressourcen von einem Cloud-Dienstanbieter als verschlüsselte Daten angeboten werden. Solche Daten können durch das On-Promises-Speichersystem verschlüsselt werden, so dass die Daten, die auf den von einem Cloud-Dienst-Anbieter angebotenen Ressourcen gespeichert werden, verschlüsselt werden, ohne dass der Cloud-Dienst-Anbieter über den Kodierungsschlüssel verfügt. Auf diese Weise können in der Cloud gespeicherte Daten sicherer sein, da die Cloud keinen Zugriff auf den Kodierungsschlüssel hat. In ähnlicher Weise könnte die Netzwerkverschlüsselung verwendet werden, wenn Daten ursprünglich in das lokale Speichersystem geschrieben werden, und verschlüsselte Daten könnten in die Cloud übertragen werden, so dass die Cloud weiterhin keinen Zugriff auf den Kodierungsschlüssel hat.
  • Durch die Verwendung von Speichersystemen, die aus Speicher bestehen, der von einem Cloud-Dienst-Anbieter angeboten wird, kann die Notfallwiederherstellung als Service angeboten werden. In einem solchen Beispiel können sich Datensätze, Workloads, andere verwaltete Objekte usw. auf einem lokalen Speichersystem befinden und synchron auf ein Speichersystem repliziert werden, dessen Ressourcen von einem Cloud-Dienstanbieter angeboten werden. Tritt beim lokalen Speichersystem eine Katastrophe ein, kann das Speichersystem, dessen Ressourcen von einem Cloud-Dienstanbieter angeboten werden, die Verarbeitung der an den Datensatz gerichteten Anforderungen übernehmen, bei der Migration des Datensatzes auf ein anderes Speichersystem helfen usw. Ebenso kann das Speichersystem, dessen Ressourcen von einem Cloud-Dienst-Anbieter angeboten werden, als sekundäres Speichersystem auf Abruf dienen, das in Zeiten starker Auslastung oder bei sonstigem Bedarf verwendet werden kann. Die Leser werden verstehen, dass Benutzeroberflächen oder ähnliche Mechanismen entworfen werden können, die viele der hier beschriebenen Funktionen initiieren, so dass die Aktivierung der Notfallwiederherstellung als Dienst so einfach sein kann wie ein einziger Mausklick.
  • Durch die Verwendung von Speichersystemen, die aus Speicher bestehen, der von einem Cloud-Dienst-Anbieter angeboten wird, kann auch Hochverfügbarkeit als Service angeboten werden. In einem solchen Beispiel können Datensätze, Workloads und andere verwaltete Objekte, die sich möglicherweise auf einem lokalen Speichersystem befinden, synchron auf ein Speichersystem repliziert werden, dessen Ressourcen von einem Cloud-Dienstanbieter angeboten werden. In einem solchen Beispiel kann aufgrund der dedizierten Netzwerkkonnektivität zu einer Cloud wie AWS Direct Connect eine Latenzzeit von unter einer Millisekunde zu AWS von verschiedenen Standorten erreicht werden. Anwendungen können daher in einem Stretched-Cluster-Modus ohne massive Ausgaben im Voraus ausgeführt werden, und es kann eine hohe Verfügbarkeit erreicht werden, ohne dass mehrere, deutlich voneinander getrennte Speichersysteme vor Ort angeschafft, gewartet usw. werden müssen. Die Leser werden verstehen, dass Benutzeroberflächen oder ähnliche Mechanismen entwickelt werden können, die viele der hier beschriebenen Funktionen initiieren, so dass die Anwendungen durch einen einzigen Mausklick in die Cloud skaliert werden können.
  • Durch die Verwendung von Speichersystemen, die aus Speicher bestehen, der von einem Cloud-Dienst-Anbieter angeboten wird, können auch Systemwiederherstellungen als Service angeboten werden. In einem solchen Beispiel können Point-in-Time-Kopien von Datensätzen, verwalteten Objekten und anderen Entitäten, die sich möglicherweise auf einem lokalen Speichersystem befinden, synchron auf ein Speichersystem repliziert werden, dessen Ressourcen von einem Cloud-Service-Anbieter angeboten werden. Wenn in einem solchen Beispiel die Notwendigkeit besteht, ein Speichersystem zu einem bestimmten Zeitpunkt wiederherzustellen, können die Point-in-Time-Kopien von Datensätzen und anderen verwalteten Objekten, die sich auf dem Speichersystem befinden, dessen Ressourcen von einem Cloud-Dienstanbieter angeboten werden, zur Wiederherstellung eines Speichersystems verwendet werden.
  • Durch die Verwendung von Speichersystemen, die aus Ressourcen bestehen, die von einem Cloud-Dienst-Anbieter angeboten werden, können Daten, die auf einem standortnahen Speichersystem gespeichert sind, zur Nutzung durch verschiedene Cloud-Dienste nativ in die Cloud geleitet werden. In einem solchen Beispiel können die Daten, die in ihrem nativen Format vorliegen, wie sie im lokalen Speichersystem gespeichert wurden, geklont und in ein Format konvertiert werden, das für verschiedene Cloud-Dienste verwendet werden kann. Beispielsweise können Daten in ihrem nativen Format, wie sie im lokalen Speichersystem gespeichert sind, geklont und in ein Format konvertiert werden, das von Amazon™ Redshift verwendet wird, so dass Datenanalyseabfragen mit den Daten durchgeführt werden können. Ebenso können Daten, die in ihrem nativen Format im lokalen Speichersystem gespeichert sind, geklont und in ein Format konvertiert werden, das von Amazon™ DynamoDB, Amazon™ Aurora oder einem anderen Cloud-Datenbankdienst verwendet wird. Da solche Konvertierungen außerhalb des lokalen Speichersystems stattfinden, können Ressourcen innerhalb des lokalen Speichersystems erhalten bleiben und zur Verwendung bei der Wartung von E/A-Operationen beibehalten werden, während Cloud-Ressourcen, die bei Bedarf ausgelagert werden können, zur Durchführung der Datenkonvertierung verwendet werden, was besonders wertvoll in Ausführungsformen sein kann, in denen das lokale Speichersystem als primärer Servicer von E/A-Operationen fungiert und die Speichersysteme, die aus Ressourcen bestehen, die von einem Cloud-Dienstanbieter angeboten werden, eher als Backup-Speichersystem fungieren. Da verwaltete Objekte über Speichersysteme hinweg synchronisiert werden können, können die Komponenten einer solchen Pipeline in eine Cloud exportiert und in einer Cloud-Umgebung ausgeführt werden, wenn ein lokales Speichersystem ursprünglich für die Ausführung der in einer ETL-Pipeline (ETL = Extract, Transform, Load) erforderlichen Schritte verantwortlich war. Durch die Verwendung solcher Techniken kann auch Analytik als Dienst angeboten werden, einschließlich der Verwendung von Point-in-Time-Kopien des Datensatzes (d. h. Momentaufnahmen) als Input für Analysedienste.
  • Die Leser werden verstehen, dass Anwendungen auf jedem der oben beschriebenen Speichersysteme ausgeführt werden können, und in einigen Ausführungsformen können solche Anwendungen auf einem primären Controller, einem sekundären Controller oder sogar auf beiden Controllern gleichzeitig laufen. Beispiele für solche Anwendungen können Anwendungen sein, die im Hintergrund gestapelte Datenbank-Scans durchführen, Anwendungen, die statistische Analysen von Laufzeitdaten durchführen, und so weiter.
  • Die Vorteile und Merkmale der vorliegenden Offenbarung können durch die folgenden Aussagen weiter beschrieben werden:
    • 1. Verfahren zum Wechseln zwischen Fehlerreaktionsmodellen unter einer Vielzahl von Speichersystemen, wobei das Verfahren umfasst: Bestimmen einer Änderung in der Verfügbarkeit eines Vermittlerdienstes unter einem oder mehreren der Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung von dem Vermittlerdienst anfordern; und Vermitteln, unter der Vielzahl von Speichersystemen und als Reaktion auf das Bestimmen der Änderung in der Verfügbarkeit des Vermittlerdienstes, eines Fehlerreaktionsmodells, das als Alternative zu dem Vermittler zu verwenden ist.
    • 2. Das Verfahren von Aussage 1, wobei das Fehlerreaktionsmodell spezifiziert, dass eine Teilmenge der Vielzahl von Speichersystemen dazu bestimmt ist, online und in Kommunikation miteinander zu bleiben, damit die synchron replizierten Daten online bleiben, wobei, wenn ein gegebenes Speichersystem, das sich nicht in der Teilmenge von Speichersystemen befindet, nach einem Fehler mit der Teilmenge von Speichersystemen in Kommunikation steht, die gegebenen Speichersysteme weiterhin den Datensatz synchron replizieren.
    • 3. Das Verfahren von Aussage 2 oder Aussage 1, wobei die Teilmenge der Speichersysteme auf der Grundlage vordefinierter Präferenzen ausgewählt wird.
    • 4. Das Verfahren von Aussage 3, Aussage 2 oder Aussage 1, das ferner Folgendes umfasst: Auswählen eines alternativen Vermittlerdienstes aus einer Liste von Vermittlerdiensten auf der Grundlage von einem oder mehreren Faktoren.
    • 5. Das Verfahren von Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, das ferner Folgendes umfasst: Wechseln, als Reaktion auf das Bestimmen einer zuverlässigen Verbindung zu dem alternativen Vermittlerdienst, von der Teilmenge der Speichersysteme zum Handhaben der Vermittlung zu dem alternativen Vermittlerdienst zum Handhaben der Vermittlung.
    • 6. Das Verfahren von Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das Fehlerreaktionsmodell auf der Grundlage einer oder mehrerer der folgenden Kriterien ausgewählt wird: Host-Konnektivität, Host-Standort, aktuelle Arbeitsbelastung, Netzwerkpfade oder Netzwerklatenz zwischen Hosts und einzelnen Speichersystemen, Speichersystem-Hardware-Eigenschaften.
    • 7. Das Verfahren von Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei die Teilmenge der Speichersysteme auf der Grundlage von Tracking-Informationen für Anwendungen oder Dienste, die auf einem Host-Rechnergerät betrieben werden, und einer Messung von Auswirkungen aufgrund eines Kommunikationsverlustes zu einem bestimmten Speichersystem unter der Vielzahl von Speichersystemen bestimmt wird.
  • Beispielhafte Ausführungsformen werden weitgehend im Zusammenhang mit einem voll funktionsfähigen Computersystem beschrieben. Diejenigen Leser, die im Fachgebiet erfahren sind, werden jedoch erkennen, dass die vorliegende Offenbarung auch in einem Computerprogrammprodukt 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. Fachkundige Personen 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 Computerprogrammprodukt 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 Computerprogrammprodukt sein. Das Computerprogrammprodukt 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 fassbares Gerät sein, das Anweisungen zur Verwendung durch ein Befehlsausführungsgerät aufbewahren und speichern kann. Das computerlesbare Speichermedium kann z.B. 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 sein, ist aber nicht darauf beschränkt. Eine nicht erschöpfende Liste mit spezifischeren Beispielen für das computerlesbare Speichermedium umfasst das Folgende: eine tragbare Computerdiskette, eine Festplatte, einen Random Access Memory (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 vorstehenden Elemente. 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 eine Leitung übertragen werden.
  • Die hierin beschriebenen computerlesbaren Programmbefehle können von einem computerlesbaren Speichermedium oder über ein Netzwerk, z.B. das Internet, ein Local Area Network, ein Wide Area Network und/oder ein drahtloses Netzwerk, auf die entsprechenden Rechen- und Verarbeitungsgeräte heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, optische Übertragungsfasern, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jedem Rechen-/Prozessorgerät empfängt computerlesbare Programmbefehle vom Netzwerk und leitet die computerlesbaren Programmbefehle zum Speichern 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, Befehle mit Befehlssatzarchitektur (ISA), Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Firmware-Befehle, statuseinstellende Daten oder entweder um Source Code oder Object Code 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, Field Programmable Gate Arrays (FPGA) oder Programmable 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, Apparaten (Systemen) und Computerprogramm-Produkten gemäß einigen Ausführungsformen der Offenbarung beschrieben. Es wird davon ausgegangen, dass jeder Block der Flussdiagramm-Darstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagramm-Abbildungen und/oder Blockdiagrammen durch computerlesbare Programmanweisungen implementiert werden kann.
  • Diese computerlesbaren Programmbefehle können einem Prozessor eines Allzweckrechners, eines Spezialrechners oder eines anderen programmierbaren Datenverarbeitungsgeräts zur Erzeugung einer Maschine zur Verfügung gestellt werden, so dass die Befehle, die über den Prozessor des Rechners oder eines anderen programmierbaren Datenverarbeitungsgeräts ausgeführt werden, Mittel zur Implementierung der im Flussdiagramm und/oder Block oder in Blockdiagrammblöcken spezifizierten Funktionen/Aktionen bereitstellen. 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 ein Erzeugnis umfasst, das Befehle einschließt, welche Aspekte der im Ablaufdiagramm und/oder im 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 Block oder in den Block oder Blöcken des Blockdiagramms 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 Computerprogrammprodukten 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 zur Implementierung der angegebenen logischen Funktion(en) umfasst. In einigen alternativen Implementierungen können die im Block angegebenen Funktionen in einer anderen, als 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 hardwarebasierte Systeme mit besonderer Zweckbestimmung implementiert werden kann, die die angegebenen Funktionen oder Handlungen ausführen oder Kombinationen von hardwarebasierten Systemen mit besonderer Zweckbestimmung und Computerbefehlen ausführen.
  • Die Leser werden verstehen, dass die hier beschriebenen Schritte auf unterschiedliche Art und Weise durchgeführt werden können und dass keine besondere Reihenfolge erforderlich ist. Aus der vorstehenden Beschreibung wird ferner ersichtlich, dass Modifikationen und Änderungen in verschiedenen Ausführungsformen der vorliegenden Offenbarung vorgenommen werden können, ohne von ihrem wahren Geist abzuweichen. Die Beschreibungen in dieser Spezifikation dienen lediglich der Veranschaulichung und sind nicht in einem einschränkenden Sinne auszulegen. Der Umfang der vorliegenden Offenbarung wird nur durch die folgenden Ansprüche eingeschränkt.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 62/518071 [0222]
    • US 62470172 [0238]
    • US 62518071 [0238, 0269]

Claims (20)

  1. Verfahren zum Wechseln zwischen Fehlerreaktionsmodellen unter einer Vielzahl von Speichersystemen, wobei das Verfahren umfasst: Bestimmen einer Änderung in der Verfügbarkeit eines Vermittlerdienstes unter einem oder mehreren der Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung von dem Vermittlerdienst anfordern; und Vermitteln, unter der Vielzahl von Speichersystemen und als Reaktion auf das Bestimmen der Änderung in der Verfügbarkeit des Vermittlerdienstes, eines Fehlerreaktionsmodells, das als eine Alternative zu dem Vermittlerdienst unter einem oder mehreren der Vielzahl von Speichersystemen zu verwenden ist.
  2. Verfahren nach Anspruch 1, wobei das Fehlerreaktionsmodell spezifiziert, dass eine Teilmenge der Vielzahl von Speichersystemen dazu bestimmt ist, online und in Kommunikation miteinander zu bleiben, damit die synchron replizierten Daten online bleiben, wobei, wenn ein gegebenes Speichersystem, das sich nicht in der Teilmenge von Speichersystemen befindet, nach einem Fehler mit der Teilmenge von Speichersystemen in Kommunikation steht, die gegebenen Speichersysteme weiterhin den Datensatz synchron replizieren.
  3. Verfahren nach Anspruch 2, wobei die Teilmenge der Speichersysteme auf der Grundlage vordefinierter Präferenzen ausgewählt wird.
  4. Verfahren nach Anspruch 2, weiter umfassend: Auswählen eines alternativen Vermittlerdienstes aus einer Liste von Vermittlerdiensten auf der Grundlage von einem oder mehreren Faktoren.
  5. Verfahren nach Anspruch 4, weiter umfassend: Wechseln, als Reaktion auf das Bestimmen einer zuverlässigen Verbindung zu dem alternativen Vermittlerdienst, von der Teilmenge der Speichersysteme zum Handhaben der Vermittlung zu dem alternativen Vermittlerdienst zum Handhaben der Vermittlung.
  6. Verfahren nach Anspruch 1, wobei das Fehlerreaktionsmodell auf der Grundlage von einem oder mehreren von Folgendem ausgewählt wird: Host-Konnektivität, Host-Standort, aktuelle Arbeitsbelastung, Netzwerkpfade oder Netzwerklatenz zwischen Hosts und einzelnen Speichersystemen, Speichersystem-Hardware-Eigenschaften.
  7. Verfahren nach Anspruch 4, wobei die Teilmenge der Speichersysteme bestimmt wird auf der Grundlage von Tracking-Informationen für Anwendungen oder Dienste, die auf einem Host-Rechnergerät betrieben werden, und einer Messung von Auswirkungen aufgrund eines Kommunikationsverlustes zu einem bestimmten Speichersystem unter der Vielzahl von Speichersystemen.
  8. Speichersystem zum Wechseln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems, wobei das Speichersystem einen Computerprozessor und einen Computerspeicher umfasst, der operativ mit dem Computerprozessor gekoppelt ist, wobei der Computerspeicher Computerprogrammbefehle speichert, die, wenn sie vom Computerprozessor ausgeführt werden, das Speichersystem veranlassen, die folgenden Schritte auszuführen: Bestimmen einer Änderung in der Verfügbarkeit eines Vermittlerdienstes unter einem oder mehreren der Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung vom Vermittlerdienst anfordern; und Vermitteln, unter der Vielzahl von Speichersystemen und als Reaktion auf das Bestimmen der Änderung in der Verfügbarkeit des Vermittlerdienstes, eines Fehlerreaktionsmodells, das als eine Alternative zum Vermittlerdienst zwischen einem oder mehreren der Vielzahl von Speichersystemen zu verwenden ist.
  9. Speichersystem nach Anspruch 8, wobei das Fehlerreaktionsmodell spezifiziert, dass eine Teilmenge der Vielzahl von Speichersystemen dazu bestimmt ist, online und in Kommunikation miteinander zu bleiben, damit die synchron replizierten Daten online bleiben, wobei, wenn ein gegebenes Speichersystem, das sich nicht in der Teilmenge von Speichersystemen befindet, nach einem Fehler mit der Teilmenge von Speichersystemen in Kommunikation steht, die gegebenen Speichersysteme weiterhin den Datensatz synchron replizieren.
  10. Speichersystem nach Anspruch 9, wobei die Teilmenge der Speichersysteme auf der Grundlage vordefinierter Präferenzen ausgewählt wird.
  11. Speichersystem nach Anspruch 9, wobei die Computerbefehle, wenn sie vom Computerprozessor ausgeführt werden, das Speichersystem ferner veranlassen, die folgenden Schritte auszuführen: Auswählen eines alternativen Vermittlerdienstes aus einer Liste von Vermittlerdiensten auf der Grundlage von einem oder mehreren Faktoren.
  12. Speichersystem nach Anspruch 11, wobei die Computerbefehle, wenn sie vom Computerprozessor ausgeführt werden, ferner das Speichersystem veranlassen, die folgenden Schritte auszuführen: Wechseln, als Reaktion auf das Bestimmen einer zuverlässigen Verbindung zu dem alternativen Vermittlerdienst, von der Teilmenge der Speichersysteme zum Handhaben der Vermittlung zu dem alternativen Vermittlerdienst zum Handhaben der Vermittlung.
  13. Speichersystem nach Anspruch 11, wobei das Fehlerreaktionsmodell auf der Grundlage von einem oder mehreren von Folgendem ausgewählt wird: Host-Konnektivität, Host-Standort, aktuelle Arbeitsbelastung, Netzwerkpfade oder Netzwerklatenz zwischen Hosts und einzelnen Speichersystemen, Speichersystem-Hardware-Eigenschaften.
  14. Speichersystem nach Anspruch 11, wobei die Teilmenge der Speichersysteme bestimmt wird auf der Grundlage von Tracking-Informationen für Anwendungen oder Dienste, die auf einem Host-Rechnergerät betrieben werden, und einer Messung von Auswirkungen aufgrund eines Kommunikationsverlustes zu einem bestimmten Speichersystem unter der Vielzahl von Speichersystemen.
  15. Vorrichtung zum Wechseln zwischen Fehlerreaktionsmodellen innerhalb eines Speichersystems, wobei die Vorrichtung einen Computerprozessor und einen Computerspeicher umfasst, der operativ mit dem Computerprozessor gekoppelt ist, wobei der Computerspeicher Computerprogrammbefehle speichert, die, wenn sie von dem Computerprozessor ausgeführt werden, die Vorrichtung veranlassen, die folgenden Schritte auszuführen: Bestimmen einer Änderung in der Verfügbarkeit eines Vermittlerdienstes unter einem oder mehreren der Vielzahl von Speichersystemen, wobei eines oder mehrere der Vielzahl von Speichersystemen so konfiguriert sind, dass sie als Reaktion auf einen Fehler eine Vermittlung vom Vermittlerdienst anfordern; und Vermitteln, unter der Vielzahl von Speichersystemen und als Reaktion auf das Bestimmen der Änderung in der Verfügbarkeit des Vermittlerdienstes, eines Fehlerreaktionsmodells, das als eine Alternative zum Vermittlerdienst zwischen einem oder mehreren der Vielzahl von Speichersystemen zu verwenden ist.
  16. Vorrichtung nach Anspruch 15, wobei das Fehlerreaktionsmodell spezifiziert, dass eine Teilmenge der Vielzahl von Speichersystemen dazu bestimmt ist, online und in Kommunikation miteinander zu bleiben, damit die synchron replizierten Daten online bleiben, wobei, wenn ein gegebenes Speichersystem, das sich nicht in der Teilmenge von Speichersystemen befindet, nach einem Fehler mit der Teilmenge von Speichersystemen in Kommunikation steht, die gegebenen Speichersysteme weiterhin den Datensatz synchron replizieren.
  17. Vorrichtung nach Anspruch 16, wobei die Teilmenge der Speichersysteme auf der Grundlage vordefinierter Präferenzen ausgewählt wird.
  18. Vorrichtung nach Anspruch 16, wobei die Computerprogrammbefehle, wenn sie vom Computerprozessor ausgeführt werden, die Vorrichtung ferner veranlassen, die folgenden Schritte auszuführen: Auswählen eines alternativen Vermittlerdienstes aus einer Liste von Vermittlerdiensten auf der Grundlage von einem oder mehreren Faktoren.
  19. Vorrichtung nach Anspruch 18, wobei die Computerprogrammbefehle, wenn sie vom Computerprozessor ausgeführt werden, ferner das Gerät veranlassen, die folgenden Schritte auszuführen: Wechseln, als Reaktion auf das Bestimmen einer zuverlässigen Verbindung zu dem alternativen Vermittlerdienst, von der Teilmenge der Speichersysteme zum Handhaben der Vermittlung zu dem alternativen Vermittlerdienst zum Handhaben der Vermittlung.
  20. Vorrichtung nach Anspruch 15, wobei das Fehlerreaktionsmodell auf der Grundlage von einem oder mehreren von Folgendem ausgewählt wird: Host-Konnektivität, Host-Standort, aktuelle Arbeitsbelastung, Netzwerkpfade oder Netzwerklatenz zwischen Hosts und einzelnen Speichersystemen, Speichersystem-Hardware-Eigenschaften.
DE112019002609.7T 2018-05-21 2019-05-21 Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem Pending DE112019002609T5 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201862674570P 2018-05-21 2018-05-21
US62/674,570 2018-05-21
US201862695433P 2018-07-09 2018-07-09
US62/695,433 2018-07-09
US16/050,382 US10992598B2 (en) 2018-05-21 2018-07-31 Synchronously replicating when a mediation service becomes unavailable
US16/050,382 2018-07-31
PCT/US2019/033205 WO2019226586A1 (en) 2018-05-21 2019-05-21 Switching between fault response models in a storage system

Publications (1)

Publication Number Publication Date
DE112019002609T5 true DE112019002609T5 (de) 2021-05-06

Family

ID=68533191

Family Applications (2)

Application Number Title Priority Date Filing Date
DE112019002584.8T Pending DE112019002584T5 (de) 2018-05-21 2019-05-20 Wechseln zwischen vermittlerdiensten für ein speichersystem
DE112019002609.7T Pending DE112019002609T5 (de) 2018-05-21 2019-05-21 Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE112019002584.8T Pending DE112019002584T5 (de) 2018-05-21 2019-05-20 Wechseln zwischen vermittlerdiensten für ein speichersystem

Country Status (4)

Country Link
US (7) US11128578B2 (de)
CN (1) CN112470142A (de)
DE (2) DE112019002584T5 (de)
WO (3) WO2019226573A1 (de)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110010518A1 (en) 2005-12-19 2011-01-13 Srinivas Kavuri Systems and Methods for Migrating Components in a Hierarchical Storage Network
US10275320B2 (en) 2015-06-26 2019-04-30 Commvault Systems, Inc. Incrementally accumulating in-process performance data and hierarchical reporting thereof for a data stream in a secondary copy operation
US10521344B1 (en) * 2017-03-10 2019-12-31 Pure Storage, Inc. Servicing input/output (‘I/O’) operations directed to a dataset that is synchronized across a plurality of storage systems
US11238164B2 (en) * 2017-07-10 2022-02-01 Burstiq, Inc. Secure adaptive data storage platform
US10831591B2 (en) 2018-01-11 2020-11-10 Commvault Systems, Inc. Remedial action based on maintaining process awareness in data storage management
US10901846B2 (en) * 2018-04-02 2021-01-26 Microsoft Technology Licensing, Llc Maintenance of storage devices with multiple logical units
US11455409B2 (en) 2018-05-21 2022-09-27 Pure Storage, Inc. Storage layer data obfuscation
US11954220B2 (en) 2018-05-21 2024-04-09 Pure Storage, Inc. Data protection for container storage
US11675503B1 (en) 2018-05-21 2023-06-13 Pure Storage, Inc. Role-based data access
US11128578B2 (en) * 2018-05-21 2021-09-21 Pure Storage, Inc. Switching between mediator services for a storage system
US10769042B2 (en) * 2018-06-25 2020-09-08 Seagate Technology Llc Single port data storage device with multi-port virtualization
US11099925B2 (en) 2018-07-10 2021-08-24 EMC IP Holding Company LLC Datacenter preemptive measures for improving protection using IoT sensors
US11100135B2 (en) 2018-07-18 2021-08-24 EMC IP Holding Company LLC Synchronous replication in a storage system
US10802935B2 (en) * 2018-07-23 2020-10-13 EMC IP Holding Company LLC Method to support synchronous replication failover
US10860444B2 (en) * 2018-07-30 2020-12-08 EMC IP Holding Company LLC Seamless mobility for kubernetes based stateful pods using moving target defense
US11237750B2 (en) 2018-08-30 2022-02-01 Portworx, Inc. Dynamic volume replication factor adjustment
US11172052B2 (en) * 2018-09-13 2021-11-09 International Business Machines Corporation Merging storage protocols
US11106528B2 (en) 2018-10-10 2021-08-31 EMC IP Holding Company LLC Datacenter IoT-triggered preemptive measures using machine learning
US11275764B2 (en) * 2018-10-11 2022-03-15 EMC IP Holding Company LLC Highly resilient synchronous replication with automatic recovery
JP7361711B2 (ja) * 2018-10-22 2023-10-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、コンテンツ管理システム、及び、プログラム
US11113409B2 (en) * 2018-10-26 2021-09-07 Pure Storage, Inc. Efficient rekey in a transparent decrypting storage array
US11038961B2 (en) * 2018-10-26 2021-06-15 Western Digital Technologies, Inc. Ethernet in data storage device
US10884646B2 (en) * 2018-11-06 2021-01-05 International Business Machines Corporation Data management system for storage tiers
US11132339B2 (en) 2018-11-13 2021-09-28 Netapp Inc. Synchronous replication for synchronous mirror copy guarantee
US20200192572A1 (en) 2018-12-14 2020-06-18 Commvault Systems, Inc. Disk usage growth prediction system
US11720600B1 (en) * 2018-12-17 2023-08-08 Enterprise e-Support Inc. Methods and apparatus for machine learning to produce improved data structures and classification within a database
US10877682B2 (en) * 2019-01-10 2020-12-29 Western Digital Technologies, Inc. Non-disruptive cross-protocol live data migration
US11288286B2 (en) * 2019-01-22 2022-03-29 EMC IP Holding Company LLC Storage system with data consistency checking in synchronous replication using active snapshot set
US11068191B2 (en) 2019-01-23 2021-07-20 EMC IP Holding Company LLC Adaptive replication modes in a storage system
US20200250232A1 (en) * 2019-01-31 2020-08-06 Hewlett Packard Enterprise Development Lp Partial file system instances
US11221923B2 (en) * 2019-02-05 2022-01-11 International Business Machines Corporation Performing selective backup operations
US10412086B1 (en) 2019-03-22 2019-09-10 Trace, LLC Systems and methods for validating device permissions of computing devices to execute code on a decentralized database
US11388054B2 (en) * 2019-04-30 2022-07-12 Intel Corporation Modular I/O configurations for edge computing using disaggregated chiplets
US11301418B2 (en) * 2019-05-02 2022-04-12 EMC IP Holding Company LLC Method and system for provenance-based data backups
US10999316B2 (en) * 2019-05-17 2021-05-04 International Business Machines Corporation Cyber resiliency of application data
US11003501B2 (en) * 2019-07-03 2021-05-11 Advanced New Technologies Co., Ltd. Loading models on nodes having multiple model service frameworks
US10585882B1 (en) * 2019-09-23 2020-03-10 Trace, LLC Systems and methods for writing updates to and/or reading previously stored updates of assets implemented as smart contracts on a decentralized database
US11334455B2 (en) * 2019-09-28 2022-05-17 Atlassian Pty Ltd. Systems and methods for repairing a data store of a mirror node
US11115461B1 (en) * 2019-11-14 2021-09-07 Jason Kim Systems and methods of using asynchronous distributed hash generation for accelerated network file transfers
US11442960B2 (en) * 2019-12-17 2022-09-13 Verizon Patent And Licensing Inc. Edge key value store for a distributed platform
US11893064B2 (en) * 2020-02-05 2024-02-06 EMC IP Holding Company LLC Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace
US11514181B2 (en) * 2020-02-12 2022-11-29 Netapp, Inc. Bin syncing technique for multiple data protection schemes
CN111552672B (zh) * 2020-02-19 2023-09-15 中国船舶工业系统工程研究院 一种基于ZooKeeper的分布式服务状态一致性维护方法及装置
US11657300B2 (en) * 2020-02-26 2023-05-23 Samsung Electronics Co., Ltd. Systems and methods for predicting storage device failure using machine learning
CN113312326B (zh) * 2020-02-26 2024-04-16 伊姆西Ip控股有限责任公司 用于存储管理的方法、电子设备和计算机程序产品
US11567840B2 (en) * 2020-03-09 2023-01-31 Rubrik, Inc. Node level recovery for clustered databases
US11228645B2 (en) * 2020-03-27 2022-01-18 Microsoft Technology Licensing, Llc Digital twin of IT infrastructure
US11669494B2 (en) * 2020-05-22 2023-06-06 EMC IP Holding Company LLC Scaling out data protection infrastructure
US11972440B1 (en) * 2020-06-05 2024-04-30 Trace Labs Llc Systems and methods for providing a decentralized anti-counterfeit solution for supply chain tracking using single-use codes
US11595306B2 (en) * 2020-07-22 2023-02-28 CAST AI Group, Inc. Executing workloads across multiple cloud service providers
US11349917B2 (en) 2020-07-23 2022-05-31 Pure Storage, Inc. Replication handling among distinct networks
US11442652B1 (en) 2020-07-23 2022-09-13 Pure Storage, Inc. Replication handling during storage system transportation
JP7153942B2 (ja) * 2020-08-17 2022-10-17 ラトナ株式会社 情報処理装置、方法、コンピュータプログラム、及び、記録媒体
US11651096B2 (en) 2020-08-24 2023-05-16 Burstiq, Inc. Systems and methods for accessing digital assets in a blockchain using global consent contracts
US11720271B2 (en) * 2020-09-11 2023-08-08 Vmware, Inc. Direct access storage for persistent services in a virtualized computing system
US11218427B1 (en) * 2020-10-24 2022-01-04 Zscaler, Inc. Detecting lagging nodes in a time-synchronized distributed environment
CN112511569B (zh) * 2021-02-07 2021-05-11 杭州筋斗腾云科技有限公司 网络资源访问请求的处理方法、系统及计算机设备
US11513737B2 (en) 2021-04-16 2022-11-29 Red Hat, Inc. Preventing data overflow in edge computing systems
US11789651B2 (en) * 2021-05-12 2023-10-17 Pure Storage, Inc. Compliance monitoring event-based driving of an orchestrator by a storage system
US11816068B2 (en) 2021-05-12 2023-11-14 Pure Storage, Inc. Compliance monitoring for datasets stored at rest
US11620307B2 (en) * 2021-06-07 2023-04-04 Snowflake Inc. Stage replication in a cloud data lake
US11469944B1 (en) * 2021-06-14 2022-10-11 Oracle International Corporation Techniques for migrating worker nodes to a new manager instance
US11816356B2 (en) * 2021-07-06 2023-11-14 Pure Storage, Inc. Container orchestrator-aware storage system
CN113918092A (zh) * 2021-09-18 2022-01-11 中国长城科技集团股份有限公司 一种分配存储空间的方法及系统
CN114285865B (zh) * 2021-12-28 2023-08-08 天翼云科技有限公司 共享云硬盘的访问权限控制系统
CN114513515B (zh) * 2022-01-12 2022-11-04 重庆大学 一种边缘环境下移动偏差感知的任务迁移方法
US11894973B2 (en) * 2022-03-10 2024-02-06 Ricoh Company, Ltd. Assigning and prioritizing mediation servers for monitoring legacy devices
US20240086287A1 (en) * 2022-09-09 2024-03-14 Samsung Electronics Co., Ltd. Mechanism for increasing data protection in storage failure scenarios
CN115599316B (zh) * 2022-12-15 2023-03-21 南京鹏云网络科技有限公司 分布式数据处理方法、装置、设备、介质和计算机程序产品
CN115996230B (zh) * 2023-03-22 2023-06-16 北京源堡科技有限公司 跨云数据同步方法、装置、计算机设备及可读存储介质

Family Cites Families (212)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3060775A (en) 1952-08-08 1962-10-30 Gen Cigar Co Shuttle-type dispenser of ribbon segments
US3042163A (en) 1957-12-26 1962-07-03 Clark Equipment Co Retractable vane fluid clutch
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
JP3628777B2 (ja) * 1995-10-30 2005-03-16 株式会社日立製作所 外部記憶装置
US6012032A (en) 1995-11-30 2000-01-04 Electronic Data Systems Corporation System and method for accounting of computer data storage utilization
US5740348A (en) 1996-07-01 1998-04-14 Sun Microsystems, Inc. System and method for selecting the correct group of replicas in a replicated computer database system
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
US6748416B2 (en) * 1999-01-20 2004-06-08 International Business Machines Corporation Client-side method and apparatus for improving the availability and performance of network mediated services
US7281030B1 (en) 1999-09-17 2007-10-09 Intel Corporation Method of reading a remote memory
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
US7107359B1 (en) 2000-10-30 2006-09-12 Intel Corporation Host-fabric adapter having hardware assist architecture and method of connecting a host system to a channel-based switched fabric in a data network
US7111084B2 (en) 2001-12-28 2006-09-19 Hewlett-Packard Development Company, L.P. Data storage network with host transparent failover controlled by host bus adapter
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
US7487264B2 (en) 2002-06-11 2009-02-03 Pandya Ashish A High performance IP processor
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
US20040153844A1 (en) 2002-10-28 2004-08-05 Gautam Ghose Failure analysis method and system for storage area networks
US6831865B2 (en) 2002-10-28 2004-12-14 Sandisk Corporation Maintaining erase counts in non-volatile storage systems
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
US7711820B2 (en) 2004-11-08 2010-05-04 Cisco Technology, Inc. High availability for intelligent applications in storage networks
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
US7953890B1 (en) * 2006-01-27 2011-05-31 Symantec Operating Corporation System and method for switching to a new coordinator resource
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
US8589504B1 (en) 2006-06-29 2013-11-19 Emc Corporation Full array non-disruptive management data migration
US8533408B1 (en) 2006-06-29 2013-09-10 Emc Corporation Consolidating N-storage arrays into one storage array using virtual array non-disruptive data migration
US7484057B1 (en) 2006-06-29 2009-01-27 Emc Corporation Consolidating N-storage arrays into one storage array using full array non-disruptive data migration
US7484056B2 (en) 2006-06-29 2009-01-27 Emc Corporation Partitioning of a storage array into N-storage arrays using full array non-disruptive data migration
US7484059B1 (en) 2006-06-29 2009-01-27 Emc Corporation Full array non-disruptive migration of extended storage functionality
US7743239B2 (en) 2006-06-30 2010-06-22 Intel Corporation Accelerating integrity checks of code and data stored in non-volatile memory
US7627786B2 (en) 2006-09-26 2009-12-01 International Business Machines Corporation Tracking error events relating to data storage drives and/or media of automated data storage library subsystems
US8620970B2 (en) 2006-10-03 2013-12-31 Network Appliance, Inc. Methods and apparatus for changing versions of a filesystem
US7669029B1 (en) 2006-11-15 2010-02-23 Network Appliance, Inc. Load balancing a data storage system
US7710777B1 (en) 2006-12-20 2010-05-04 Marvell International Ltd. Semi-volatile NAND flash memory
US7640332B2 (en) 2006-12-27 2009-12-29 Hewlett-Packard Development Company, L.P. System and method for hot deployment/redeployment in grid computing environment
KR100923990B1 (ko) 2007-02-13 2009-10-28 삼성전자주식회사 플래시 저장 장치의 특성을 기반으로 한 컴퓨팅 시스템
US9632870B2 (en) 2007-03-29 2017-04-25 Violin Memory, Inc. Memory system with multiple striping of raid groups and method for performing the same
US7996599B2 (en) 2007-04-25 2011-08-09 Apple Inc. Command resequencing in memory operations
US8788750B2 (en) 2007-04-27 2014-07-22 Hewlett-Packard Development Company, L.P. Managing resources in cluster storage systems
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
US8060775B1 (en) 2007-06-14 2011-11-15 Symantec Corporation Method and apparatus for providing dynamic multi-pathing (DMP) for an asymmetric logical unit access (ALUA) based storage system
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 ソニー株式会社 記録装置、記録装置の制御方法、記録装置の制御方法のプログラム及び記録装置の制御方法のプログラムを記録した記録媒体
US8332505B2 (en) 2008-03-04 2012-12-11 Lsi Corporation Method to automatically determine host to LUN (logical unit number) path availability for multi path attached storage systems
US8949863B1 (en) 2008-04-30 2015-02-03 Netapp, Inc. Creating environmental snapshots of storage device failure events
US8001413B2 (en) * 2008-05-05 2011-08-16 Microsoft Corporation Managing cluster split-brain in datacenter service site failover
US8093868B2 (en) 2008-09-04 2012-01-10 International Business Machines Corporation In situ verification of capacitive power support
US8086585B1 (en) 2008-09-30 2011-12-27 Emc Corporation Access control to block storage devices for a shared disk based file system
US8190816B2 (en) 2008-10-17 2012-05-29 Netapp, Inc. Embedded scale-out aggregator for storage array controllers
US9473419B2 (en) 2008-12-22 2016-10-18 Ctera Networks, Ltd. Multi-tenant cloud storage system
US8566362B2 (en) * 2009-01-23 2013-10-22 Nasuni Corporation Method and system for versioned file system using structured data representations
US8762642B2 (en) 2009-01-30 2014-06-24 Twinstrata Inc System and method for secure and reliable multi-cloud data replication
JP4844639B2 (ja) 2009-02-19 2011-12-28 Ｔｄｋ株式会社 メモリコントローラ及びメモリコントローラを備えるフラッシュメモリシステム、並びにフラッシュメモリの制御方法
US9134922B2 (en) 2009-03-12 2015-09-15 Vmware, Inc. System and method for allocating datastores for virtual machines
KR101586047B1 (ko) 2009-03-25 2016-01-18 삼성전자주식회사 불휘발성 메모리 장치 및 그것의 프로그램 방법
US8805953B2 (en) 2009-04-03 2014-08-12 Microsoft Corporation Differential file and system restores from peers and the cloud
TWI408689B (zh) 2009-04-14 2013-09-11 Jmicron Technology Corp 存取儲存裝置的方法及相關控制電路
US8595397B2 (en) 2009-06-09 2013-11-26 Netapp, Inc Storage array assist architecture
JP4874368B2 (ja) 2009-06-22 2012-02-15 株式会社日立製作所 フラッシュメモリを用いたストレージシステムの管理方法及び計算機
US7948798B1 (en) 2009-07-22 2011-05-24 Marvell International Ltd. Mixed multi-level cell and single level cell storage device
US8402242B2 (en) 2009-07-29 2013-03-19 International Business Machines Corporation Write-erase endurance lifetime of memory storage devices
US8868957B2 (en) 2009-09-24 2014-10-21 Xyratex Technology Limited Auxiliary power supply, a method of providing power to a data storage system and a back-up power supply charging circuit
TWI428917B (zh) 2009-11-25 2014-03-01 Silicon Motion Inc 快閃記憶裝置、資料儲存系統、以及資料儲存系統之運作方法
US8250324B2 (en) 2009-11-30 2012-08-21 International Business Machines Corporation Method to efficiently locate meta-data structures on a flash-based storage device
US8387136B2 (en) 2010-01-05 2013-02-26 Red Hat, Inc. Role-based access control utilizing token profiles
US8452932B2 (en) 2010-01-06 2013-05-28 Storsimple, Inc. System and method for efficiently creating off-site data volume back-ups
US8751878B1 (en) 2010-03-30 2014-06-10 Emc Corporation Automatic failover during online data migration
US8799413B2 (en) * 2010-05-03 2014-08-05 Panzura, Inc. Distributing data for a distributed filesystem across multiple cloud storage systems
US20120023144A1 (en) 2010-07-21 2012-01-26 Seagate Technology Llc Managing Wear in Flash Memory
US20120054264A1 (en) 2010-08-31 2012-03-01 International Business Machines Corporation Techniques for Migrating Active I/O Connections with Migrating Servers and Clients
US8566546B1 (en) 2010-09-27 2013-10-22 Emc Corporation Techniques for enforcing capacity restrictions of an allocation policy
US8775868B2 (en) 2010-09-28 2014-07-08 Pure Storage, Inc. Adaptive RAID for an SSD environment
US20120089781A1 (en) * 2010-10-11 2012-04-12 Sandeep Ranade Mechanism for retrieving compressed data from a storage cloud
US8949502B2 (en) 2010-11-18 2015-02-03 Nimble Storage, Inc. PCIe NVRAM card based on NVDIMM
US8812860B1 (en) 2010-12-03 2014-08-19 Symantec Corporation Systems and methods for protecting data stored on removable storage devices by requiring external user authentication
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
US8589723B2 (en) 2010-12-22 2013-11-19 Intel Corporation Method and apparatus to provide a high availability solid state drive
US8465332B2 (en) 2011-01-13 2013-06-18 Tyco Electronics Corporation Contact assembly for an electrical connector
US8578442B1 (en) 2011-03-11 2013-11-05 Symantec Corporation Enforcing consistent enterprise and cloud security profiles
US8738882B2 (en) 2011-06-03 2014-05-27 Apple Inc. Pre-organization of data
US8751463B1 (en) 2011-06-30 2014-06-10 Emc Corporation Capacity forecasting for a deduplicating storage system
US8769622B2 (en) 2011-06-30 2014-07-01 International Business Machines Corporation Authentication and authorization methods for cloud computing security
US9852017B2 (en) 2011-07-27 2017-12-26 International Business Machines Corporation Generating dispersed storage network event records
US8931041B1 (en) 2011-07-29 2015-01-06 Symantec Corporation Method and system for visibility and control over access transactions between clouds using resource authorization messages
US20130036272A1 (en) 2011-08-02 2013-02-07 Microsoft Corporation Storage engine node for cloud-based storage
US8527544B1 (en) 2011-08-11 2013-09-03 Pure Storage Inc. Garbage collection in a storage system
US8832216B2 (en) 2011-08-31 2014-09-09 Oracle International Corporation Method and system for conditional remote direct memory access write
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
US20130091285A1 (en) * 2011-10-11 2013-04-11 International Business Machines Corporation Discovery-based identification and migration of easily cloudifiable applications
EP2771802A4 (de) 2011-10-24 2016-05-25 Schneider Electric Ind Sas System und verfahren zur verwaltung industrieller prozesse
US8595546B2 (en) * 2011-10-28 2013-11-26 Zettaset, Inc. Split brain resistant failover in high availability clusters
WO2013071087A1 (en) 2011-11-09 2013-05-16 Unisys Corporation Single sign on for cloud
US20130311434A1 (en) 2011-11-17 2013-11-21 Marc T. Jones Method, apparatus and system for data deduplication
US9330245B2 (en) 2011-12-01 2016-05-03 Dashlane SAS Cloud-based data backup and sync with secure local storage of access keys
US20130219164A1 (en) 2011-12-29 2013-08-22 Imation Corp. Cloud-based hardware security modules
US8613066B1 (en) 2011-12-30 2013-12-17 Amazon Technologies, Inc. Techniques for user authentication
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access
US8893147B2 (en) * 2012-01-13 2014-11-18 Ca, Inc. Providing a virtualized replication and high availability environment including a replication and high availability engine
US9116862B1 (en) * 2012-01-17 2015-08-25 Amazon Technologies, Inc. System and method for data replication using a single master failover protocol
US9423983B2 (en) 2012-01-19 2016-08-23 Syncsort Incorporated Intelligent storage controller
US9116812B2 (en) 2012-01-27 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a de-duplication cache
JP2013161235A (ja) 2012-02-03 2013-08-19 Fujitsu Ltd ストレージ装置、ストレージ装置の制御方法及びストレージ装置の制御プログラム
US10474584B2 (en) 2012-04-30 2019-11-12 Hewlett Packard Enterprise Development Lp Storing cache metadata separately from integrated circuit containing cache controller
US8832372B2 (en) 2012-05-24 2014-09-09 Netapp, Inc. Network storage systems having clustered raids for improved redundancy and load balancing
WO2013188382A2 (en) 2012-06-12 2013-12-19 Centurylink Intellectual Property Llc High performance cloud storage
CA2781648A1 (en) * 2012-06-28 2013-12-28 Beanstalk Corporation Scalable and timely network intermediary for time or quantity limited goods and services
WO2014007516A1 (ko) 2012-07-02 2014-01-09 에스케이플래닛 주식회사 단일 인증 서비스 시스템 및 이의 운용 방법
US8868870B1 (en) 2012-07-11 2014-10-21 Symantec Corporation Systems and methods for managing off-host storage migration
US9047181B2 (en) 2012-09-07 2015-06-02 Splunk Inc. Visualization of data from clusters
US8769651B2 (en) 2012-09-19 2014-07-01 Secureauth Corporation Mobile multifactor single-sign-on authentication
US9152506B2 (en) * 2012-09-20 2015-10-06 Hitachi, Ltd. Management apparatus and management method
WO2014051552A1 (en) 2012-09-25 2014-04-03 Empire Technology Development Llc Limiting data usage of a device connected to the internet via tethering
US8898507B1 (en) 2012-09-27 2014-11-25 Emc Corporation Methods and apparatus for disaster tolerant clusters of hypervisors as a virtualized infrastructure service
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
US9152642B2 (en) * 2012-12-21 2015-10-06 Zetta, Inc. Systems and methods for on-demand data storage
US9075529B2 (en) 2013-01-04 2015-07-07 International Business Machines Corporation Cloud based data migration and replication
US9646039B2 (en) 2013-01-10 2017-05-09 Pure Storage, Inc. Snapshots in a storage system
US9483657B2 (en) 2013-01-14 2016-11-01 Accenture Global Services Limited Secure online distributed data storage services
US9052917B2 (en) 2013-01-14 2015-06-09 Lenovo (Singapore) Pte. Ltd. Data storage for remote environment
US9009526B2 (en) 2013-01-24 2015-04-14 Hewlett-Packard Development Company, L.P. Rebuilding drive data
US20140229654A1 (en) 2013-02-08 2014-08-14 Seagate Technology Llc Garbage Collection with Demotion of Valid Data to a Lower Memory Tier
US20140230017A1 (en) 2013-02-12 2014-08-14 Appsense Limited Programmable security token
US8902532B2 (en) 2013-03-20 2014-12-02 International Business Machines Corporation Write avoidance areas around bad blocks on a hard disk drive platter
GB2513377A (en) 2013-04-25 2014-10-29 Ibm Controlling data storage in an array of storage devices
US9317382B2 (en) 2013-05-21 2016-04-19 International Business Machines Corporation Storage device with error recovery indication
US10038726B2 (en) 2013-06-12 2018-07-31 Visa International Service Association Data sensitivity based authentication and authorization
US9124569B2 (en) 2013-06-14 2015-09-01 Microsoft Technology Licensing, Llc User authentication in a cloud environment
US8898346B1 (en) 2013-06-20 2014-11-25 Qlogic, Corporation Method and system for configuring network devices
US8984602B1 (en) 2013-06-28 2015-03-17 Emc Corporation Protected resource access control utilizing credentials based on message authentication codes and hash chain values
US9986028B2 (en) 2013-07-08 2018-05-29 Intel Corporation Techniques to replicate data between storage servers
US9454423B2 (en) 2013-09-11 2016-09-27 Dell Products, Lp SAN performance analysis tool
US9577953B2 (en) 2013-09-27 2017-02-21 Intel Corporation Determination of a suitable target for an initiator by a control plane processor
US9442662B2 (en) 2013-10-18 2016-09-13 Sandisk Technologies Llc Device and method for managing die groups
US9519580B2 (en) 2013-11-11 2016-12-13 Globalfoundries Inc. Load balancing logical units in an active/passive storage system
US9619311B2 (en) 2013-11-26 2017-04-11 International Business Machines Corporation Error identification and handling in storage area networks
US9529546B2 (en) 2014-01-08 2016-12-27 Netapp, Inc. Global in-line extent-based deduplication
US9465698B2 (en) * 2014-03-06 2016-10-11 Software Ag Systems and/or methods for data recovery in distributed, scalable multi-tenant environments
US9887008B2 (en) 2014-03-10 2018-02-06 Futurewei Technologies, Inc. DDR4-SSD dual-port DIMM device
US9727503B2 (en) 2014-03-17 2017-08-08 Mellanox Technologies, Ltd. Storage system and server
US9250823B1 (en) 2014-05-20 2016-02-02 Emc Corporation Online replacement of physical storage in a virtual storage system
CN105830166B (zh) 2014-06-27 2018-02-23 华为技术有限公司 一种控制器、闪存装置和将数据写入闪存装置的方法
US9516167B2 (en) 2014-07-24 2016-12-06 Genesys Telecommunications Laboratories, Inc. Media channel management apparatus for network communications sessions
US9367410B2 (en) * 2014-09-12 2016-06-14 Facebook, Inc. Failover mechanism in a distributed computing system
US9720626B2 (en) * 2014-09-19 2017-08-01 Netapp Inc. Cluster configuration information replication
US10204010B2 (en) 2014-10-03 2019-02-12 Commvault Systems, Inc. Intelligent protection of off-line mail data
US10545987B2 (en) * 2014-12-19 2020-01-28 Pure Storage, Inc. Replication to the cloud
US20160197834A1 (en) * 2015-01-02 2016-07-07 Siegfried Luft Architecture and method for traffic engineering between diverse cloud providers
US20160217049A1 (en) 2015-01-22 2016-07-28 Nimble Storage, Inc. Fibre Channel Failover Based on Fabric Connectivity
US9984140B1 (en) * 2015-02-05 2018-05-29 Amazon Technologies, Inc. Lease based leader election system
US9716755B2 (en) 2015-05-26 2017-07-25 Pure Storage, Inc. Providing cloud storage array services by a local storage array in a data center
US9521200B1 (en) 2015-05-26 2016-12-13 Pure Storage, Inc. Locally providing cloud storage array services
US9300660B1 (en) 2015-05-29 2016-03-29 Pure Storage, Inc. Providing authorization and authentication in a cloud for a user of a storage array
US9444822B1 (en) 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US20160350009A1 (en) 2015-05-29 2016-12-01 Pure Storage, Inc. Buffering data to be written to an array of non-volatile storage devices
US10021170B2 (en) 2015-05-29 2018-07-10 Pure Storage, Inc. Managing a storage array using client-side services
US9892071B2 (en) 2015-08-03 2018-02-13 Pure Storage, Inc. Emulating a remote direct memory access (‘RDMA’) link between controllers in a storage array
US9836368B2 (en) * 2015-10-22 2017-12-05 Netapp, Inc. Implementing automatic switchover
US9916214B2 (en) * 2015-11-17 2018-03-13 International Business Machines Corporation Preventing split-brain scenario in a high-availability cluster
US9858011B2 (en) * 2015-12-16 2018-01-02 International Business Machines Corporation Repopulating failed replicas through modified consensus recovery
US9864663B2 (en) * 2016-02-19 2018-01-09 Dell Products L.P. Storage controller failover system
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
US10459657B2 (en) 2016-09-16 2019-10-29 Hewlett Packard Enterprise Development Lp Storage system with read cache-on-write buffer
US10146648B1 (en) * 2016-09-30 2018-12-04 EMC IP Holding Company LLC Preserving disaster recovery protection for a data storage object
US10445193B2 (en) * 2017-03-06 2019-10-15 Dell Products, Lp Database failure recovery in an information handling system
US10521344B1 (en) * 2017-03-10 2019-12-31 Pure Storage, Inc. Servicing input/output (‘I/O’) operations directed to a dataset that is synchronized across a plurality of storage systems
US11128578B2 (en) 2018-05-21 2021-09-21 Pure Storage, Inc. Switching between mediator services for a storage system

Also Published As

Publication number Publication date
US10992598B2 (en) 2021-04-27
US20210243139A1 (en) 2021-08-05
WO2019226573A1 (en) 2019-11-28
US20190354450A1 (en) 2019-11-21
WO2019226597A1 (en) 2019-11-28
DE112019002584T5 (de) 2021-05-12
US20230396565A1 (en) 2023-12-07
US11677687B2 (en) 2023-06-13
US20210409349A1 (en) 2021-12-30
US20230344783A1 (en) 2023-10-26
US11757795B2 (en) 2023-09-12
US11128578B2 (en) 2021-09-21
US20190356609A1 (en) 2019-11-21
US20190354628A1 (en) 2019-11-21
WO2019226586A1 (en) 2019-11-28
CN112470142A (zh) 2021-03-09

Similar Documents

Publication Publication Date Title
DE112019002609T5 (de) Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem
US20210397359A1 (en) Storing Data For Machine Learning And Artificial Intelligence Applications In A Decentralized Storage Network
DE112020003420T5 (de) Datenwiederherstellung in einem virtuellen Speichersystem
US20220318083A1 (en) Prioritizing Highly Performant Storage Systems For Servicing A Synchronously Replicated Dataset
US20210373761A1 (en) Leveraging Distinct Storage Tiers In A Virtual Storage System
US11138103B1 (en) Resiliency groups
DE112020003423T5 (de) Architektur von virtuellem speichersystem
US11704044B2 (en) Modifying a cloned image of replica data
DE112019005770T5 (de) Speicherverwaltung für ein cloudbasiertes Speichersystem
US20220083245A1 (en) Declarative provisioning of storage
DE102021113808A1 (de) Handhabung von Replikationen zwischen verschiedenen Netzwerken
DE112019000841T5 (de) Handhaben von E/A-Operationen in einem cloudbasierten Speichersystem
US11036677B1 (en) Replicated data integrity
AU2018230871A1 (en) Synchronously replicating datasets and other managed objects to cloud-based storage systems
DE112020003277T5 (de) Erzeugen von tags für die datenzuweisung
US20220019505A1 (en) Message persistence in a zoned system
US20220334990A1 (en) Zone drive data format
US20220253216A1 (en) Converting Data Formats In A Storage System
US20220358019A1 (en) Initiating Recovery Actions When A Dataset Ceases To Be Synchronously Replicated Across A Set Of Storage Systems
WO2023070025A1 (en) Declarative provisioning of storage
US20220091744A1 (en) Optimized Application Agnostic Object Snapshot System
US20220091743A1 (en) Bucket versioning snapshots
US20230213710A1 (en) Ribbon cable alignment apparatus
US20230350858A1 (en) Providing Block-Based Storage

Legal Events

Date Code Title Description
R012 Request for examination validly filed