DE102021113808A1 - Handhabung von Replikationen zwischen verschiedenen Netzwerken - Google Patents

Handhabung von Replikationen zwischen verschiedenen Netzwerken Download PDF

Info

Publication number
DE102021113808A1
DE102021113808A1 DE102021113808.6A DE102021113808A DE102021113808A1 DE 102021113808 A1 DE102021113808 A1 DE 102021113808A1 DE 102021113808 A DE102021113808 A DE 102021113808A DE 102021113808 A1 DE102021113808 A1 DE 102021113808A1
Authority
DE
Germany
Prior art keywords
storage
storage system
data
network
replication
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
DE102021113808.6A
Other languages
English (en)
Inventor
Logan Jennings
Aaron Dailey
Roland Dreier
Ganga Kondapalli
Nicole Tselentis
Stephen Whitney
Daquan Zuo
Ronald Karr
John Colgrove
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 DE102021113808A1 publication Critical patent/DE102021113808A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0266—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using meta-data, objects or commands for formatting management information, e.g. using eXtensible markup language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Handhabung von Replikationen zwischen verschiedenen Netzwerkübertragungsschichten, einschließend: Aufbauen einer Kommunikationsverbindung für das Replizieren zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netznachrichtenschicht; Initiieren einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems über einen zweiten Typ von Netznachrichtenschicht; und Replizieren von Daten vom ersten Speichersystem in das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems zu unterbrechen.

Description

  • Figurenliste
  • Es zeigen:
    • 1A-1D Beispielsysteme für die 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 Festkörperspeichereinheiten gemäß einigen Ausführungsformen zeigt.
    • 2D eine Speicherserver-Umgebung, die gemäß einigen Ausführungsformen die Speicherknoten und Speichereinheiten einiger vorheriger Figuren verwendet.
    • 2E ein Blade-Hardware-Blockdiagramm, das eine Steuerungsebene, Rechen- und Speicherebenen sowie Authorities zeigt, die mit den zugrunde liegenden physischen Ressourcen interagieren, in Übereinstimmung mit einigen Ausführungsformen.
    • 2F Elasticity Software Layers in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 2G Authorities und Speicherressourcen in Blades eines Storage-Clusters in Übereinstimmung mit einigen Ausführungsformen.
    • 3A ein Diagramm eines Speichersystems, das für die Datenkommunikation mit einem Anbieter von Cloud-Diensten in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung gekoppelt ist.
    • 3B ein Diagramm eines Speichersystems in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 3C ein beispielhaftes cloudbasiertes Speichersystem in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
    • 3D ein beispielhaftes Datenverarbeitungsgerät, das speziell für die Durchführung eines oder mehrerer der hier beschriebenen Prozesse konfiguriert werden kann.
    • 4A eine beispielhafte Computerumgebung für ein synchrones Replikationsschema in Übereinstimmung mit einigen Ausführungsformen.
    • 4B ein beispielhaftes Metadatenmodell in Übereinstimmung mit einigen Ausführungsformen.
    • 5A und 5B Flussdiagramme für ein synchrones Replikationsschema in Übereinstimmung mit einigen Ausführungsformen.
    • 6A und 6B eine beispielhafte Computerumgebung für ein einheitliches Modell für verschiedene Arten von Datenreplikation in Übereinstimmung mit einigen Ausführungsformen.
    • 7 und 8 beispielhafte Steuerungsabläufe für die selektive Kommunikationsprotokoll-Schichtung für synchrone Replikation gemäß einigen Ausführungsformen.
    • 9 bis 25 Flussdiagramme zur Veranschaulichung von Verfahren zum Handhaben von Replikationen zwischen verschiedenen Netzwerken gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
  • BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Beispielhafte Verfahren, Vorrichtungen und Produkte für die Handhabung von Replikationen zwischen verschiedenen Netzwerken in Übereinstimmung mit Ausführungsformen der vorliegenden Offenbarung werden unter Bezugnahme auf die beigefügten Figuren beschrieben, beginnend mit 1A. 1A illustriert ein Beispielsystem zur Datenspeicherung gemäß einigen Implementierungen. Das System 100 (hier auch als „Speichersystem“ bezeichnet) enthält zahlreiche Elemente, die eher der Veranschaulichung als 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 andere Weise konfiguriert sind.
  • Das System 100 umfasst eine Anzahl von Datenverarbeitungsgeräten 164A-B. Datenverarbeitungsgeräte (hier auch als „Client-Geräte“ bezeichnet) können z. B. einen Server in einem Rechenzentrum, eine Workstation, einen Personal Computer, ein Notebook oder ähnliches verkörpern. Datenverarbeitungsgeräte 164A-B können für die Datenkommunikation mit einem oder mehreren Speicher-Arrays 102A-B über ein Storage Area Network („SAN“) 158 oder ein Local Area Network („LAN“) 160 gekoppelt sein.
  • Das SAN 158 kann mit einer Vielzahl von Datenkommunikationsstrukturen, -vorrichtungen und -protokollen implementiert werden. Die Fabrics für SAN 158 können z. B. 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 darauf hingewiesen, dass SAN 158 zur Veranschaulichung und nicht als Einschränkung angegeben ist. Andere Datenkommunikationskopplungen können zwischen den Datenverarbeitungsgeräten 164A-B und den Speicher-Arrays 102A-B implementiert werden.
  • Das LAN 160 kann auch mit einer Vielzahl von Strukturen, Vorrichtungen und Protokollen implementiert werden. Beispielsweise können die Strukturen für LAN 160 Ethernet (802.3), Wireless (802.11) oder ähnliches umfassen. Datenkommunikationsprotokolle zur Verwendung in LAN 160 können Transmission Control Protocol („TCP“), User Datagram Protocol („UDP“), Internet Protocol („IP“), HyperText Transfer Protocol („HTTP“), Wireless Access Protocol („WAP“), Handheld Device Transport Protocol („HDTP“), Session Initiation Protocol („SIP“), Real Time Protocol („RTP“) oder Ähnliches umfassen.
  • 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 Chassis (nicht abgebildet) und das Speicher-Array 102B in einem anderen Chassis (nicht abgebildet) enthalten sein. Die Speicher-Arrays 102A und 102B können einen oder mehrere Speicher-Array-Controller 110A-D (hier auch als „Controller“ bezeichnet) enthalten. Ein Speicher-Array-Controller 110A-D kann als Modul einer automatisierten Rechenanlage mit Computer-Hardware, Computer-Software oder einer Kombination aus Computer-Hardware und - Software ausgeführt sein. In einigen Implementierungen können die Speicher-Array-Controller 110A-D so konfiguriert sein, dass sie verschiedene Speicheraufgaben ausführen. Zu den Speicheraufgaben kann das Schreiben von Daten, die von den Datenverarbeitungsgeräten 164AB empfangen werden, in das Speicher-Array102A-B, das Löschen von Daten aus dem Speicher-Array 102A-B, das Abrufen von Daten aus dem Speicher-Array102A-B und das Bereitstellen von Daten für die Datenverarbeitungsgeräte 164A-B, das Überwachen und Berichten der Festplattenauslastung und -leistung, das Durchführen von Redundanzoperationen, wie z. B. Redundant Array of Independent Drives („RAID“) oder RAID-ähnliche Datenredundanzoperationen, das Komprimieren von Daten, das Verschlüsseln von Daten und so weiter gehören.
  • Der Speicher-Array-Controller 110A-D kann auf verschiedene Weise implementiert werden, z. B. als ein Field Programmable Gate Array („FPGA“), Programmable Logic Chip („PLC“), Application Specific Integrated Circuit („ASIC“), System-on-Chip („SOC“) oder jedes Datenverarbeitungsgerät, das diskrete Komponenten enthält, wie z. B. eine Verarbeitungsvorrichtung, eine Zentraleinheit, einen Computerspeicher oder verschiedene Adapter. Der Speicher-Array-Controller 110A-D kann z. B. einen Datenkommunikationsadapter enthalten, der so konfiguriert ist, dass er die Kommunikation über das SAN 158 oder LAN 160 unterstützt. In einigen Implementierungen kann der Speicher-Array-Controller 110A-D unabhängig mit dem LAN 160 verbunden sein. In Implementierungen kann der Speicher-Array-Controller 110A-D einen E/A-Controller oder ähnliches enthalten, der den Speicher-Array-Controller 110A-D für die Datenkommunikation über eine Midplane (nicht dargestellt) 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 (hier auch als „Speichergeräte“ bezeichnet) und eine beliebige Anzahl von Random Access Memories („NVRAM“) enthalten (nicht dargestellt).
  • In einigen Implementierungen können die NVRAM-Vorrichtungen einer persistenten Speicherressource 170A-B so konfiguriert sein, dass sie von dem Speicher-Array-Controller 110A-D Daten empfangen, die in 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 in die NVRAM-Vorrichtung schneller ausgeführt werden als das direkte Schreiben von Daten in das Speicherlaufwerk 171A-F. In Implementierungen kann der Speicher-Array-Controller 110A-D so konfiguriert sein, dass er die NVRAM-Vorrichtungen als schnell zugänglichen Puffer für Daten nutzt, die auf die Speicherlaufwerke 171A-F geschrieben werden sollen. Die Latenzzeit für Schreibanforderungen, die NVRAM-Vorrichtungen als Puffer verwenden, kann im Vergleich zu einem System verbessert werden, in dem ein Speicher-Array-Controller 110A-D Daten direkt auf die Speicherlaufwerke 171A-F schreibt. In einigen Implementierungen können die NVRAM-Vorrichtungen mit Computerspeicher in Form von RAM mit hoher Bandbreite und niedriger Latenz implementiert werden. Die NVRAM-Vorrichtung wird als „nichtflüchtig“ bezeichnet, weil die NVRAM-Vorrichtung eine eigene Stromquelle erhalten oder enthalten kann, die den Zustand des RAMs nach einem 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 sein, dass sie den Inhalt des RAM in einen persistenten Speicher schreibt, z. B. in die Speicherlaufwerke 171A-F.
  • In Implementierungen kann sich das Speicherlaufwerk 171A-F auf jedes Gerät beziehen, das so konfiguriert ist, dass es Daten dauerhaft aufzeichnet, wobei sich „dauerhaft“ oder „beständig“ auf die Fähigkeit eines Geräts bezieht, aufgezeichnete Daten nach einem Stromausfall beizubehalten. In einigen Implementierungen kann das Speicherlaufwerk 171A-F einem festplattenlosen Speichermedium entsprechen. Zum Beispiel kann das Speicherlaufwerk 171A-F ein oder mehrere Solid-State-Laufwerke („SSDs“), auf Flash-Speicher basierende Speicher, jede Art von nichtflüchtigem Festkörperspeicher oder jede andere Art von nichtmechanischem Speichergerät sein. In anderen Implementierungen kann das Speicherlaufwerk 171A-F mechanische oder rotierende Festplatten, wie z.B. Festplattenlaufwerke (‚HDD‘), enthalten.
  • In einigen Implementierungen können die Speicher-Array-Controller 110A-D so konfiguriert sein, dass sie die Aufgaben der Geräteverwaltung von den Speicherlaufwerken 171A-F im Speicher-Array102A-B übernehmen. Zum Beispiel können die Speicher-Array-Controller 110A-D Steuerinformationen verwalten, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben können. Die Steuerinformationen können beispielsweise anzeigen, dass ein bestimmter Speicherblock ausgefallen ist und nicht mehr beschrieben werden sollte, dass ein bestimmter Speicherblock einen Boot-Code für einen Speicher-Array-Controller 110A-D enthält, die Anzahl der Programm-Löschzyklen („P/E“), die für einen 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, und so weiter. In einigen Implementierungen können die Steuerinformationen mit einem zugehörigen Speicherblock als Metadaten gespeichert werden. In anderen Implementierungen können die Steuerinformationen für die Speicherlaufwerke 171A-F in einem oder mehreren bestimmten Speicherblöcken der Speicherlaufwerke 171A-F gespeichert werden, die von dem Speicher-Array-Controller 110A-D ausgewählt werden. Die ausgewählten Speicherblöcke können mit einer Kennung versehen werden, die anzeigt, dass der ausgewählte Speicherblock Steuerinformationen enthält. Die Kennung kann von den Speicher-Array-Controllern 110A-D in Verbindung mit den Speicherlaufwerken 171A-F verwendet werden, um die Speicherblöcke, die Steuerinformationen enthalten, schnell zu identifizieren. Beispielsweise können die Speicher-Controller 110A-D einen Befehl ausgeben, um Speicherblöcke zu lokalisieren, die Steuerinformationen enthalten. Es ist zu beachten, dass die Steuerinformationen so umfangreich sein können, dass Teile der Steuerinformationen an mehreren Stellen gespeichert werden können, dass die Steuerinformationen beispielsweise zu Redundanzzwecken an mehreren Stellen gespeichert werden können, oder dass die Steuerinformationen anderweitig über mehrere Speicherblöcke im Speicherlaufwerk 171A-F verteilt sein können.
  • In Implementierungen können die Speicher-Array-Controller 110A-D Geräteverwaltungsaufgaben von den Speicherlaufwerken 171A-F des Speicher-Arrays 102A-B entlasten, indem sie von den Speicherlaufwerken 171A-F Steuerinformationen abrufen, die den Zustand eines oder mehrerer Speicherblöcke in den Speicherlaufwerken 171A-F beschreiben. Das Abrufen der Steuerinformationen von den Speicherlaufwerken 171A-F kann z. B. dadurch erfolgen, dass der Speicher-Array-Controller 110A-D die Speicherlaufwerke 171A-F nach dem Ort der Steuerinformationen für ein bestimmtes Speicherlaufwerk 171A-F abfragt. Die Speicherlaufwerke 171A-F können so konfiguriert sein, dass sie Befehle ausführen, die es dem Speicherlaufwerk 171A-F ermöglichen, den Speicherort der Steuerinformationen zu identifizieren. Die Befehle können von einem Controller (nicht dargestellt) ausgeführt werden, der mit dem Speicherlaufwerk 171A-F verbunden ist oder sich anderweitig auf diesem befindet, und können das Speicherlaufwerk 171A-F veranlassen, einen Teil jedes Speicherblocks abzutasten, um die Speicherblöcke zu identifizieren, die Steuerinformationen für die Speicherlaufwerke 171A-F speichern. Die Speicherlaufwerke 171A-F können antworten, indem sie eine Antwortnachricht an den Speicher-Array-Controller 110A-D senden, welche den Ort der Steuerinformationen für das Speicherlaufwerk 171A-F enthält. Als Reaktion auf den Empfang der Antwortnachricht können die Speicher-Array-Controller 110A-D eine Anforderung zum Lesen von Daten ausgeben, die an der Adresse gespeichert sind, die dem Speicherort der Steuerinformationen für die Speicherlaufwerke 171A-F zugeordnet ist.
  • In anderen Implementierungen können die Speicher-Array-Controller 110A-D ferner Geräteverwaltungsaufgaben von den Speicherlaufwerken 171A-F abnehmen, indem sie als Reaktion auf den Empfang der Steuerinformationen eine Speicherlaufwerk-Verwaltungsoperation durchführen. Eine Speicherlaufwerk-Verwaltungsoperation kann beispielsweise eine Operation umfassen, die typischerweise von dem Speicherlaufwerk 171A-F (z. B. dem Controller (nicht dargestellt), der einem bestimmten Speicherlaufwerk 171A-F zugeordnet ist) durchgeführt wird. Eine Speicherlaufwerk-Verwaltungsoperation kann z. B. sicherstellen, dass Daten nicht in ausgefallene Speicherblöcke innerhalb des Speicherlaufwerks 171A-F geschrieben werden, sicherstellen, dass Daten in Speicherblöcke innerhalb des Speicherlaufwerks 171A-F so geschrieben werden, dass eine angemessene Verschleißnivellierung erreicht wird, und so weiter.
  • In Implementierungen kann das Speicher-Array 102A-B zwei oder mehr Speicher-Array-Controller 110A-D implementieren. Zum Beispiel kann das Speicher-Array 102A Speicher-Array-Controller 110A und Speicher-Array-Controller 110B enthalten. In einem gegebenen Fall kann ein einzelner Speicher-Array-Controller 110A-D (z. B. Speicher-Array-Controller 110A) eines Speichersystems 100 mit dem primären Status bezeichnet werden (hier auch als „primärer Controller“ bezeichnet), und andere Speicher-Array-Controller 110A-D (z. B. Speicher-Array-Controller 110A) können mit dem sekundären Status bezeichnet werden (hier auch als „sekundärer Controller“ bezeichnet). Der primäre Controller kann bestimmte Rechte aufweisen, wie z. B. die Erlaubnis, Daten in der persistenten Speicherressource 170A-B zu ändern (z. B. das Schreiben von Daten in die persistente Speicherressource 170A-B). Zumindest einige der Rechte des primären Controllers können die Rechte des sekundären Controllers überlagern. Zum Beispiel kann der sekundäre Controller nicht die Erlaubnis haben, Daten in der persistenten Speicherressource 170A-B zu ändern, wenn der primäre Controller das Recht dazu hat. Der Status von Speicher-Array-Controllern 110A-D kann sich ändern. Beispielsweise kann der Speicher-Array-Controller 110A mit dem sekundären Status und der Speicher-Array-Controller 110B mit dem primären Status bezeichnet werden.
  • In einigen Implementierungen kann ein primärer Controller, wie z. B. Speicher-Array-Controller 110A, als primärer Controller für ein oder mehrere Speicher-Arrays 102A-B dienen, und ein zweiter Controller, wie z. B. Speicher-Array-Controller 110B, kann als sekundärer Controller für das eine oder die mehreren Speicher-Arrays 102A-B dienen. Beispielsweise kann Speicher-Array-Controller 110A der primäre Controller für Speicher-Array102A und Speicher-Array102B sein, und 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 einen primären noch einen sekundären Status aufweisen. Die Speicher-Array-Controller 110C und 110D, die als Speicherverarbeitungsmodule implementiert sind, können als Kommunikationsschnittstelle zwischen den primären und sekundären Controllern (z. B. den Speicher-Array-Controllern 110A bzw. 110B) und dem Speicher-Array102B dienen. Zum Beispiel kann der Speicher-Array-Controller 110A des Speicher-Arrays 102A eine Schreibanforderung über SAN 158 an das Speicher-Array102B senden. Die Schreibanforderung kann von den 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 sei darauf hingewiesen, dass in einigen Implementierungen Speicherverarbeitungsmodule verwendet werden können, um die Anzahl der Speicherlaufwerke zu erhöhen, die von den primären und sekundären Controllern gesteuert werden.
  • In Implementierungen sind die Speicher-Array-Controller 110A-D über eine Midplane (nicht dargestellt) mit einem oder mehreren Speicherlaufwerken 171A-F und einer oder mehreren NVRAM-Vorrichtungen (nicht dargestellt) kommunikativ gekoppelt, die als Teil eines Speicher-Arrays 102A-B enthalten sind. Die Speicher-Array-Controller 110A-D können über eine oder mehrere Datenkommunikationsverbindungen mit der Midplane gekoppelt sein, und die Midplane kann über eine oder mehrere Datenkommunikationsverbindungen mit den Speicherlaufwerken 171A-F und den NVRAM-Vorrichtungen gekoppelt sein. Die hier beschriebenen Datenkommunikationsverbindungen werden gemeinsam durch die Datenkommunikationsverbindungen 108A-D dargestellt und können z. B. einen Peripheral Component Interconnect Express („PCIe“)-Bus umfassen.
  • 1B zeigt ein Beispielsystem zur Datenspeicherung gemäß einigen Implementierungen. Der in 1B dargestellte Speicher-Array-Controller 101 kann den in 1A beschriebenen Speicher-Array-Controllern 110A-D ähneln. In einem Beispiel kann der Speicher-Array-Controller 101 dem Speicher-Array-Controller 110A oder dem Speicher-Array-Controller 110B ähneln. Der Speicher-Array-Controller 101 umfasst zahlreiche Elemente, die eher der Veranschaulichung als der Einschränkung dienen. Es ist zu beachten, dass der Speicher-Array-Controller 101 die gleichen, mehr oder weniger Elemente enthalten kann, die in anderen Implementierungen auf die gleiche oder andere Weise konfiguriert sind. Es sei darauf hingewiesen, dass im Folgenden Elemente aus 1A zur Veranschaulichung von Merkmalen des Speicher-Array-Controllers 101 aufgeführt sein können.
  • Der Speicher-Array-Controller 101 kann ein oder mehrere Verarbeitungsvorrichtungen 104 und einen Direktzugriffsspeicher („RAM“) 111 enthalten. Die Verarbeitungsvorrichtung 104 (oder der Controller 101) stellt eine oder mehrere Mehrzweck-Verarbeitungsvorrichtungen dar, 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 Prozessoren, die eine Kombination von Befehlssätzen implementieren. Bei der Verarbeitungsvorrichtung 104 (oder dem Controller 101) kann es sich auch um eine oder mehrere spezielle Verarbeitungsvorrichtungen handeln, wie z. B. ein ASIC, ein FPGA, ein Digital Signal Prozessor („DSP“), ein Netzwerkprozessor oder Ähnliches.
  • Die Verarbeitungsvorrichtung 104 kann mit dem RAM 111 über eine Datenkommunikationsverbindung 106 verbunden sein, 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 sind Befehle 113 im RAM 111 gespeichert. Die Befehle 113 können Computerprogrammbefehlen zur Durchführung von Operationen in einem Direct-Mapped-Flash-Speichersystem enthalten. In einer Ausführungsform ist ein Direct-Mapped-Flash-Speichersystem eines, das Datenblöcke innerhalb von Flash-Laufwerken direkt und ohne eine von den Speicher-Controllern der Flash-Laufwerke durchgeführte Adressübersetzung adressiert.
  • In Implementierungen umfasst der Speicher-Array-Controller 101 einen oder mehrere Host-Bus-Adapter 103A-C, die über eine Datenkommunikationsverbindung 105A-C mit der Verarbeitungsvorrichtung 104 gekoppelt sind. In Implementierungen können die Host-Bus-Adapter 103A-C Computer-Hardware sein, die ein Host-System (z. B. den Speicher-Array-Controller) mit anderen Netzwerk- und Speicher-Arrays verbindet. In einigen Beispielen können Host-Bus-Adapter 103A-C ein Fibre-Channel-Adapter sein, der es dem Speicher-Array-Controller 101 ermöglicht, sich mit einem SAN zu verbinden, ein Ethernet-Adapter, der es dem Speicher-Array-Controller 101 ermöglicht, sich mit einem LAN zu verbinden, oder ein ähnlicher Adapter. Host-Bus-Adapter 103A-C können über eine Datenkommunikationsverbindung 105A-C, wie z. B. einen PCIe-Bus, mit der Verarbeitungsvorrichtung 104 gekoppelt sein.
  • In Implementierungen kann der Storage Array Controller 101 einen Host-Bus-Adapter 114 enthalten, der mit einem Expander 115 gekoppelt ist. Der Expander 115 kann verwendet werden, um ein Hostsystem an eine größere Anzahl von Speicherlaufwerken anzuschließen. Der Expander 115 kann z. B. ein SAS-Expander sein, der verwendet wird, um den Host-Bus-Adapter 114 in einer Implementierung, in der der Host-Bus-Adapter 114 als SAS-Controller ausgeführt ist, mit Speicherlaufwerken zu verbinden.
  • In Implementierungen kann der Storage Array Controller 101 einen Switch 116 enthalten, der über eine Datenkommunikationsverbindung 109 mit der Verarbeitungsvorrichtung 104 gekoppelt ist. Der Switch 116 kann eine Computer-Hardware-Vorrichtung sein, die mehrere Endpunkte aus einem einzigen Endpunkt erzeugen kann, wodurch mehrere Vorrichtungen einen einzigen Endpunkt gemeinsam nutzen können. Der Switch 116 kann beispielsweise ein PCIe-Switch sein, der mit einem PCIe-Bus (z. B. der Datenkommunikationsverbindung 109) gekoppelt ist und der Midplane mehrere PCIe-Verbindungspunkte zur Verfügung stellt.
  • In Implementierungen umfasst 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, das herkömmliche Flash-Laufwerke verwendet, kann einen Prozess über die Flash-Laufwerke implementieren, die Teil des herkömmlichen Speichersystems sind. Zum Beispiel kann ein übergeordneter Prozess 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. Daher können für das herkömmliche 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 unterer Ebene ausgeführt werden. Zum Beispiel kann das Flash-Speichersystem Flash-Laufwerke enthalten, 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 von den Speicher-Controllern der Flash-Laufwerke durchgeführte Adressübersetzung adressiert.
  • Das Betriebssystem des Flash-Speichersystems kann eine Liste von Zuordnungseinheiten über mehrere Flash-Laufwerke des Flash-Speichersystems hinweg ermitteln und pflegen. Die Zuordnungseinheiten können ganze Löschblöcke oder mehrere Löschblöcke sein. Das Betriebssystem kann eine Karte oder einen Adressbereich enthalten, der Adressen direkt den Löschblöcken der Flash-Laufwerke des Flash-Speichersystems zuordnet.
  • Die direkte Zuordnung zu den Löschblöcken der Flash-Laufwerke kann verwendet werden, um Daten neu zu schreiben und Daten zu löschen. Beispielsweise können die Operationen an 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 initiieren, 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 markieren. Auf diese Weise kann der Prozess nur von dem ü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, wenn der Prozess nur vom Betriebssystem des Flash-Speichersystems durchgeführt wird, gehört u. a. eine erhöhte Zuverlässigkeit der Flash-Laufwerke des Flash-Speichersystems, da während des Prozesses keine unnötigen oder redundanten Schreiboperationen durchgeführt werden. Ein möglicher Punkt der Neuheit ist hier das Konzept der Initiierung und Steuerung des Prozesses am Betriebssystem des Flash-Speichersystems. Darüber hinaus kann der Prozess vom Betriebssystem über mehrere Flash-Laufwerke hinweg 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 nutzt, oder es kann aus einem verteilten Netzwerk von Speicher-Array-Controllern bestehen, die jeweils über eine gewisse Anzahl von Laufwerken oder eine gewisse Menge an Flash-Speicher verfügen, 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 zeigt ein drittes Beispielsystem 117 zur Datenspeicherung gemäß einigen Implementierungen. Das System 117 (hier auch als „Speichersystem“ bezeichnet) enthält zahlreiche Elemente, die der Veranschaulichung und nicht der Einschränkung dienen. Es ist zu beachten, 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ührungsform 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 enthalten. In einer Ausführungsform kann der Speicher-Controller 119A-D eine CPU, eine ASIC, ein FPGA oder eine beliebige andere Schaltung sein, die die gemäß der vorliegenden Offenbarung erforderlichen Steuerstrukturen implementieren kann. In einer Ausführungsform umfasst das System 117 Flash-Speichervorrichtungen (z. B. einschließlich Flash-Speichervorrichtungen 120a-n), die operativ mit verschiedenen Kanälen des Speicher-Controllers 119 verbunden sind. Die Flash-Speichervorrichtungen 120a-n können dem Controller 119A-D als adressierbare Sammlung von Flash-Seiten, Löschblöcken und/oder Steuerelementen präsentiert werden, die ausreichen, um dem Speicher-Controller 119A-D das Programmieren und Abrufen verschiedener Aspekte der Flash-Speichervorrichtung zu ermöglichen. In einer Ausführungsform kann der Speicher-Controller 119A-D Operationen an den Flash-Speichervorrichtungen 120a-n durchführen, einschließlich des Speicherns und Abrufens von Dateninhalten von Seiten, des Anordnens und Löschens beliebiger Blöcke, des Verfolgens von Statistiken in Bezug auf die Verwendung und Wiederverwendung von Flash-Speicher-Seiten, Löschblöcken und Zellen, des Verfolgens und Vorhersagens von Fehlercodes und Fehlern innerhalb des Flash-Speichers, des Steuerns von Spannungspegeln in Verbindung mit dem Programmieren und Abrufen von Inhalten von Flash-Zellen 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 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, wie z. B. eine wiederaufladbare 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) für eine ausreichende Zeit zu versorgen, um den Inhalt des RAM 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 enthält 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.). Die Datenkommunikationsverbindungen 123a, 123b können auf den Spezifikationen von Non-Volatile Memory Express („NVMe“) oder NVMe over Fabrics („NVMf“) basieren, die eine externe Verbindung mit dem Speicher-Controller 119A-D von anderen Komponenten im Speichersystem 117 aus 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 dargestellt) 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 dargestellt), der für die Verwendung zum Speichern des Inhalts des RAM 121 vorgesehen ist. Der Speicher-Controller 119A-D kann über einen PCI-Bus eine logische Vorrichtung darstellen, die einen adressierbaren, schnell beschreibbaren logischen Baustein oder einen bestimmten Teil des logischen Adressraums des Speichergeräts 118 umfassen kann, das als PCI-Speicher oder als persistenter Speicher dargestellt werden kann. In einer Ausführungsform werden Operationen zum Speichern in das Gerät in den RAM 121 geleitet. Bei einem Stromausfall kann der Speicher-Controller 119A-D den gespeicherten Inhalt, der mit dem adressierbaren logischen Schnellschreibspeicher assoziiert ist, in den Flash-Speicher (z. B. Flash-Speicher 120a-n) für eine dauerhafte Speicherung schreiben.
  • In einer Ausführungsform kann die logische Vorrichtung eine Darstellung einiger oder aller Inhalte der Flash-Speichervorrichtungen 120a-n enthalten, wobei diese Darstellung es einem Speichersystem einschließlich einer Speichervorrichtung 118 (z. B. Speichersystem 117) ermöglicht, Flash-Speicherseiten direkt zu adressieren und Löschblöcke von Speichersystemkomponenten, die sich außerhalb der Speichervorrichtung befinden, über den PCI-Bus direkt neu zu programmieren. Die Darstellung kann es auch einer oder mehreren der externen Komponenten ermöglichen, andere Aspekte des Flash-Speichers zu steuern und abzurufen, einschließlich einiger oder aller der folgenden: Verfolgung von Statistiken in Bezug auf die Nutzung und Wiederverwendung von Flash-Speicherseiten, Löschblöcken und Zellen über alle Flash-Speichervorrichtungen hinweg; Verfolgung und Vorhersage von Fehlercodes und Fehlern innerhalb und über die Flash-Speichervorrichtungen hinweg; Steuerung von Spannungspegeln in Verbindung mit der Programmierung und dem Abrufen von Inhalten 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.
  • Es können verschiedene Schemata 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 teilweise Entladung des Energiespeichers 122, um entsprechende Entladeeigenschaften zu messen, usw. Wenn die verfügbare Energie im Laufe der Zeit abnimmt, kann die effektiv verfügbare Kapazität des adressierbaren Schnellschreibspeichers verringert werden, um sicherzustellen, dass er auf Basis der aktuell verfügbaren gespeicherten Energie sicher beschrieben werden kann.
  • 1D zeigt ein drittes Beispielsystem 124 zur Datenspeicherung gemäß 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 den 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 gewissen Anzahl von Host-Computern 127a-n gekoppelt sein.
  • In einer Ausführungsform stellen zwei Speicher-Controller (z. B. 125a und 125b) Storage-Dienste bereit, wie z. B. ein SCS-Blockspeicher-Array, einen Dateiserver, einen Objektserver, eine Datenbank oder einen Datenanalysedienst usw. Die Speicher-Controller 125a, 125b können Dienste über eine gewisse Anzahl von Netzwerkschnittstellen (z. B. 126a-d) 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 Rechensystem bilden. Die Speicher-Controller 125a, 125b können den Schnellschreibspeicher innerhalb oder zwischen den Speichergeräten 119a-d nutzen, um laufende Operationen zu protokollieren, um sicherzustellen, dass die Operationen bei einem Stromausfall, dem Entfernen des Speicher-Controllers, dem 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 an einem oder den anderen PCI-Bussen 128a, 128b. In einer anderen Ausführungsform können 128a und 128b auf anderen Kommunikationsstandards basieren (z. B. HyperTransport, InfiniBand usw.). Andere Ausführungsformen des Speichersystems können die 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. In einigen Ausführungsformen des Speichersystems können Speichergeräte direkt miteinander kommunizieren, anstatt nur mit den Speicher-Controllern zu kommunizieren. In einer Ausführungsform kann ein Speicher-Controller 119a auf Anweisung eines Speicher-Controllers 125a Daten, die in Flash-Speichervorrichtungen gespeichert werden sollen, aus Daten, die im RAM (z. B. im RAM 121 von 1C) gespeichert wurden, synthetisieren und übertragen. So kann beispielsweise eine neu berechnete Version des RAM-Inhalts übertragen werden, nachdem ein Speicher-Controller festgestellt hat, dass eine Operation im gesamten Speichersystem vollständig ausgeführt wurde, oder wenn der Schnellschreibspeicher auf der Vorrichtung eine bestimmte genutzte Kapazität erreicht hat, oder nach einer bestimmten Zeit, um eine verbesserte Sicherheit der Daten zu gewährleisten oder um adressierbare Schnellschreibkapazität zur Wiederverwendung freizugeben. Dieser Mechanismus kann z. B. verwendet werden, um einen zweiten Transfer über einen Bus (z. B. 128a, 128b) von den Speicher-Controllern 125a, 125b zu vermeiden. In einer Ausführungsform kann eine Neuberechnung die Komprimierung von Daten, das Anhängen von Indexierungs- oder anderen Metadaten, das Zusammenfassen mehrerer Datensegmente, die Durchführung von Löschcodeberechnungen usw. umfassen.
  • In einer Ausführungsform kann ein Speicher-Controller 119a, 119b auf Anweisung eines Speicher-Controllers 125a, 125b Daten aus den im RAM gespeicherten Daten (z. B. RAM 121 in 1C) ohne Beteiligung der Speicher-Controller 125a, 125b berechnen und an andere Speichergeräte übertragen. Dieser Vorgang kann verwendet werden, um Daten, die in einem Controller 125a gespeichert sind, auf einen anderen Controller 125b zu spiegeln, oder er 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 zum PCI-Bus 128a, 128b zu reduzieren.
  • Ein Speicher-Controller 119A-D kann Mechanismen zur Implementierung von Hochverfügbarkeitsprimitiven für die 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 anderen Speicher-Controller daran hindern kann, auf das Speichergerät zuzugreifen oder weiter darauf zuzugreifen. Dies könnte z. B. in Fällen verwendet werden, in denen ein Controller feststellt, dass der andere Controller nicht ordnungsgemäß funktioniert, oder wenn die Verbindung zwischen den beiden Speicher-Controllern selbst nicht ordnungsgemäß funktioniert.
  • In einer Ausführungsform umfasst ein Speichersystem zur Verwendung mit Dual-PCI-Direct-Mapped-Stoage-Geräten mit separat adressierbarem Schnellschreibespeicher Systeme, die Löschblöcke oder Gruppen von Löschblöcken als Zuweisungseinheiten zur Speicherung von Daten im Auftrag des Storage-Dienstes oder zur Speicherung von Metadaten (z. B. Indizes, Protokolle usw.), die mit dem Storage-Dienst verbunden sind, oder zur ordnungsgemäßen Verwaltung des Speichersystems selbst verwalten. Flash-Seiten, die einige Kilobyte groß sein können, können geschrieben werden, wenn Daten ankommen oder wenn das Speichersystem Daten über längere Zeiträume (z. B. über einen definierten Schwellenwert) aufrechterhalten soll. Um Daten schneller zu übertragen oder die Anzahl der Schreibvorgänge auf den Flash-Speichervorrichtungen zu reduzieren, können die Speicher-Controller Daten zunächst 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 den Speichergeräten (z. B. 118) in Übereinstimmung mit dem Alter und der erwarteten Restlebensdauer der Speichergeräte oder basierend auf anderen Statistiken initiieren. Die Speicher-Controller 125a, 125b können Garbage Collection und Datenmigration zwischen Speichergeräten in Übereinstimmung mit nicht mehr benötigten Seiten sowie zur Verwaltung der Lebensspanne von Flash-Seiten und Löschblöcken und zur Verwaltung der Gesamtsystemleistung initiieren.
  • In einer Ausführungsform kann das Speichersystem 124 als Teil der Speicherung von Daten in adressierbarem Schnellschreibespeicher und/oder als Teil des Schreibens von Daten in Zuordnungseinheiten, die mit Löschblöcken verbunden sind, Spiegelungs- und/oder Löschcodierungsschemata verwenden. Löschcodes können sowohl über Speichergeräte hinweg als auch innerhalb von Löschblöcken oder Zuordnungseinheiten oder innerhalb von und zwischen Flash-Speichervorrichtungen auf einem einzigen Speichergerät verwendet werden, um Redundanz gegen einzelne oder mehrere Speichergeräteausfälle zu gewährleisten oder um sich gegen interne Beschädigungen von Flash-Speicherseiten zu schützen, die aus Flash-Speicheroperationen oder aus der Degradierung von Flash-Speicherzellen resultieren. Eine Spiegelung und Löschcodierung auf verschiedenen Ebenen kann verwendet werden, um mehrere Arten von Ausfällen, die separat oder in Kombination auftreten, zu beheben.
  • Die mit Bezug auf die 2A-G dargestellten Ausführungsformen zeigen 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 die Benutzerdaten auf Speicherknoten, die sich in einem Chassis oder in mehreren Chassis befinden, unter Verwendung von Löschcodierung und redundanten Kopien von Metadaten. Die Löschcodierung bezieht sich auf ein Verfahren zur Datensicherung oder -wiederherstellung, bei dem Daten über eine Reihe verschiedener Speicherorte, wie z. B. Festplatten, 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 auf andere Typen von Festkörperspeicher oder andere Speichermedien, einschließlich Nicht-Festkörperspeicher, erweitert werden können. Die Steuerung der Speicherorte und Arbeitslasten werden in einem geclusterten Peer-to-Peer-System auf die Speicherorte verteilt. Aufgaben wie die Vermittlung der Kommunikation zwischen den verschiedenen Speicherknoten, die Erkennung, wenn ein Speicherknoten nicht mehr verfügbar ist, und der Ausgleich von E/As (Eingaben und Ausgaben) über die verschiedenen Speicherknoten werden alle auf einer verteilten Basis gehandhabt. Die 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 neu zugewiesen werden, unabhängig von Ein- und Ausgabemustern. 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 Ein- und Ausgabeoperationen verfügbar bleiben. In verschiedenen Ausführungsformen kann ein Speicherknoten als Clusterknoten, als Blade oder als Server bezeichnet werden.
  • Der Storage-Cluster kann in einem Chassis enthalten sein, d. h. in einem Chassis, in dem ein oder mehrere Speicherknoten untergebracht sind. Ein Mechanismus zur Stromversorgung der einzelnen Speicherknoten, z. B. ein Stromverteilungsbus, und ein Kommunikationsmechanismus, z. B. ein Kommunikationsbus, der die Kommunikation zwischen den Speicherknoten ermöglicht, sind im Chassis enthalten. Gemäß einigen Ausführungsformen kann der Storage-Cluster als unabhängiges System an einem Ort betrieben werden. 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, aber auch andere Technologien wie PCle, InfiniBand und andere sind gleichermaßen geeignet. Das Chassis bietet einen Anschluss für einen externen Kommunikationsbus, um die Kommunikation zwischen mehreren Chassis, direkt oder über einen Switch, und mit Client-Systemen 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 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 entweder über proprietäre Schnittstellen oder Standardschnittstellen wie Network File System („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 alle gekoppelten oder verbundenen Chassis können als Storage-Cluster bezeichnet werden. Wie vorstehend beschrieben, kann jedes Chassis mehrere Blades aufweisen, jedes Blade verfügt über eine Media Access Control („MAC“)-Adresse, aber der Storage-Cluster wird in einigen Ausführungsformen einem externen Netzwerk so präsentiert, als hätte er 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 einer und acht nichtflüchtigen Festkörperspeichereinheiten, wobei dieses eine Beispiel nicht als einschränkend angesehen werden soll. Der Speicherserver kann einen Prozessor, DRAM und Schnittstellen für den internen Kommunikationsbus und die Stromverteilung für jeden der Versorgungsbusse 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örperspeichereinheit enthält eine eingebettete CPU, einen Festkörperspeicher-Controller und eine Menge an Festkörpermassenspeicher, 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 die Übertragung einer Teilmenge des DRAM-Inhalts auf ein stabiles Speichermedium im Falle eines Stromausfalls ermöglicht. In einigen Ausführungsformen ist die nichtflüchtige Festkörperspeichereinheit mit einem Speicher der Speicherklasse aufgebaut, wie z. B. Phase-Change- oder Magnetoresistive Random Access Memories („MRAM“), welcher einen DRAM ersetzt und eine Verzögerungsvorrichtung mit reduzierter Leistung ermöglicht.
  • Eine von vielen Funktionen der Speicherknoten und nichtflüchtigen Festkörperspeicher ist die Fähigkeit, Daten in einem Storage-Cluster proaktiv wiederherzustellen. Die Speicherknoten und der nichtflüchtige Festkörperspeicher können feststellen, wenn ein Speicherknoten oder ein nichtflüchtiger Festkörperspeicher im Storage-Cluster unerreichbar 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 Speicherorten wiederherzustellen und zu rekonstruieren. Dies stellt eine proaktive Wiederherstellung dar, da das System Daten wiederherstellt, ohne zu warten, bis die Daten für einen Lesezugriff benötigt werden, der von einem Client-System initiiert wird, das den Storage-Cluster verwendet. Diese und weitere Details des Speichers und dessen Betrieb werden im Folgenden erläutert.
  • 2A ist eine perspektivische Ansicht eines Storage-Clusters 161 mit mehreren Speicherknoten 150 und einem internen Festkörperspeicher, der mit jedem Speicherknoten gekoppelt ist, um einen Network Attached Storage oder ein Storage Area Network bereitzustellen, gemäß einigen Ausführungsformen. Ein Network Attached Storage, ein Storage Area Network 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 Speichers umfassen. Der Storage-Cluster 161 ist so konzipiert, dass er in ein Rack passt, und ein oder mehrere Racks können nach Wunsch für den Speicher eingerichtet und bestückt werden. Der Storage-Cluster 161 hat ein Chassis 138 mit mehreren Steckplätzen 142. Es ist zu beachten, dass das Chassis 138 auch als Gehäuse, Einschub oder Rack-Einheit bezeichnet werden kann. In einer Ausführungsform hat das Chassis 138 vierzehn Steckplätze 142, obwohl auch andere Anzahlen von Steckplätzen ohne weiteres denkbar sind. Zum Beispiel haben einige Ausführungsformen 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 an einem Rack verwendet werden können. Lüfter 144 sorgen für die Luftzirkulation zur Kühlung der Speicherknoten 150 und ihrer Komponenten, obwohl auch andere Kühlkomponenten verwendet werden könnten oder eine Ausführungsform ohne Kühlkomponenten entwickelt werden könnte. Ein Switch Fabric 146 koppelt 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 aufeinanderfolgend oder benachbart sein. Die Speicherknoten 150 sind im laufenden Betrieb steckbar, d. h. ein Speicherknoten 150 kann in einen Steckplatz 142 im Chassis 138 eingesetzt oder aus einem Steckplatz 142 entfernt werden, ohne dass das System angehalten oder ausgeschaltet werden muss. Beim Einsetzen oder Entfernen des Speicherknotens 150 aus dem Steckplatz 142 rekonfiguriert sich das System automatisch, um die Änderung zu erkennen und sich daran anzupassen. Die Rekonfiguration umfasst in einigen Ausführungsformen die Wiederherstellung der Redundanz und/oder die Neuverteilung von Daten oder der Last.
  • Jeder Speicherknoten 150 kann aus mehreren Komponenten bestehen. In der hier gezeigten Ausführungsform umfasst der Speicherknoten 150 eine Leiterplatte 159, die mit einer CPU 156, d. h. einem Prozessor, einem mit der CPU 156 gekoppelten Speicher 154 und einem mit der CPU 156 gekoppelten nichtflüchtigen Festkörperspeicher 152 bestückt ist, obwohl in weiteren Ausführungsformen auch andere Halterungen und/oder Komponenten verwendet werden könnten. Der Speicher 154 enthält Befehle, die von der CPU 156 ausgeführt werden, und/oder Daten, die von der CPU 156 bearbeitet werden. Wie weiter unten erläutert wird, umfasst der nichtflüchtige Festkörperspeicher 152 Flash-Speicher oder, in weiteren Ausführungsformen, andere Arten von Festkörperspeichern.
  • Bezugnehmend auf 2A ist der Storage-Cluster 161 skalierbar, d. h. Speicherkapazität mit uneinheitlichen Speichergrößen kann, wie vorstehend beschrieben, problemlos hinzugefügt werden. Ein oder mehrere Speicherknoten 150 können in jedes Chassis eingesteckt oder aus diesem entfernt werden, und der Storage-Cluster konfiguriert sich in einigen Ausführungsformen selbst. Plug-in-Speicherknoten 150 können, unabhängig davon, ob sie im Auslieferungszustand in einem Chassis installiert sind oder später hinzugefügt werden, unterschiedliche Größen aufweisen. Zum Beispiel kann in einer Ausführungsform ein Speicherknoten 150 ein beliebiges Vielfaches von 4 TB aufweisen, 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 aufweisen. Die Speicherkapazität jedes Speicherknotens 150 wird übertragen und beeinflusst die Entscheidung, wie die Daten in Stripes gespeichert werden sollen. Um eine maximale Speichereffizienz zu erreichen, kann eine Ausführungsform den Stripe so breit wie möglich selbst konfigurieren, vorbehaltlich einer vorgegebenen Anforderung des fortgesetzten Betriebs bei Verlust von bis zu einer oder bis zu zwei nichtflüchtigen Festkörperspeichereinheiten 152 oder Speicherknoten 150 innerhalb des Chassis.
  • 2B ist ein Blockdiagramm, das eine Kommunikationsverbindung 173 und einen Stromverteilungsbus 172 zum Koppeln mehrerer Speicherknoten 150 zeigt. Wie in 2A dargestellt, kann die Kommunikationsverbindung 173 in einigen Ausführungsformen in der Switch Fabric 146 enthalten sein oder mit dieser implementiert werden. Wenn mehrere Storage-Cluster 161 ein Rack belegen, kann die Kommunikationsverbindung 173 in einigen Ausführungsformen in einem Top-of-Rack-Switch enthalten oder mit diesem implementiert sein. Wie in 2B dargestellt, ist der Storage-Cluster 161 in einem einzigen Chassis 138 untergebracht. Ein externer Port 176 ist über die Kommunikationsverbindung 173 mit den Speicherknoten 150 verbunden, während ein externer Port 174 direkt mit einem Speicherknoten verbunden ist. Ein externer Stromversorgungsanschluss 178 ist mit dem Stromverteilungsbus 172 gekoppelt. Die Speicherknoten 150 können unterschiedliche Mengen und unterschiedliche Kapazitäten an nichtflüchtigem Festkörperspeicher 152 enthalten, wie mit Bezug auf 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, beispielsweise als Listen oder andere im Speicher gespeicherte Datenstrukturen. In einigen Ausführungsformen werden die Authorities innerhalb des nichtflüchtigen Festkörperspeichers 152 gespeichert und 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 von Software unterstützt werden, die auf der CPU 156 des Speicherknotens 150 ausgeführt wird. Die Authorities 168 steuern 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 über welche Teile der Daten verfügen. Jede Authority 168 kann einem nichtflüchtigen Festkörperspeicher 152 zugeordnet sein. Jede Authority kann einen Bereich von Inode-Nummern, Segment-Nummern oder anderen Daten-Kennungen steuern, die den Daten durch ein Dateisystem, durch die Speicherknoten 150 oder durch den nichtflüchtigen Festkörperspeicher 152 in verschiedenen Ausführungsformen zugewiesen werden.
  • Jedes einzelne Datum und jedes einzelne Metadatum hat in einigen Ausführungsformen Redundanz im System. Darüber hinaus hat jedes einzelne Datum und jedes einzelne Metadatum einen Besitzer, der als Authority bezeichnet werden kann. Wenn diese Authority nicht erreichbar ist, z. B. 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. In einigen Ausführungsformen haben die Authorities 168 eine Beziehung zu den Speicherknoten 150 und dem nichtflüchtigen Festkörperspeicher 152. Jede Authority 168, die einen Bereich von Datensegmentnummern oder anderen Kennungen der Daten abdeckt, kann einem bestimmten nichtflüchtigen Festkörperspeicher 152 zugewiesen sein. In einigen Ausführungsformen sind die Authorities 168 für alle derartigen 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 des jeweiligen Speicherknotens 150 ermöglicht. Daten können in einem Segment gespeichert werden, das mit einer Segmentnummer verknüpft ist, und diese Segmentnummer ist in einigen Ausführungsformen eine Indirektion für eine Konfiguration eines RAID-Stripes (Redundant Array of Independent Disks). Die Zuweisung und Verwendung der Authorities 168 stellt somit eine Indirektion zu den Daten her. Indirektion kann, in Übereinstimmung mit einigen Ausführungsformen, als die Fähigkeit bezeichnet werden, Daten indirekt zu referenzieren, in diesem Fall über eine Authority 168. Ein Segment identifiziert einen Satz von nichtflüchtigen Festkörperspeichern 152 und eine lokale Kennung in dem Satz von nichtflüchtigen Festkörperspeichern 152, der Daten enthalten kann. In einigen Ausführungsformen ist die lokale Kennung ein Offset in das Gerät und kann von mehreren Segmenten sequentiell wiederverwendet werden. In anderen Ausführungsformen ist die lokale Kennung für ein bestimmtes Segment einmalig und wird nie wieder verwendet. Die Offsets im nichtflüchtigen Festkörperspeicher 152 werden zum Auffinden von Daten für das Schreiben in den oder Lesen aus dem nichtflüchtigen Festkörperspeicher 152 (in Form eines RAID-Stripes) verwendet. Die Daten werden über mehrere Einheiten des nichtflüchtigen Festkörperspeichers 152 gestriped, 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 Speicherort eines bestimmten Datensegments ändert, z. B. während einer Datenverschiebung oder einer Datenrekonstruktion, sollte die Authority 168 für dieses Datensegment bei dem nichtflüchtigen Festkörperspeicher 152 oder dem Speicherknoten 150 mit dieser Authority 168 konsultiert werden. 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. Die Ausgabe dieses Vorgangs zeigt auf einen nichtflüchtigen Festkörperspeicher 152, der die Authority 168 für dieses bestimmte Stück Daten hat. In einigen Ausführungsformen besteht diese Operation aus zwei Phasen. In der ersten Phase wird ein Entity Identifier (ID), z. B. eine Segmentnummer, Inode-Nummer oder Verzeichnisnummer, einem Authority Identifier zugeordnet. Diese Zuordnung kann eine Berechnung wie z. B. einen Hash oder eine Bitmaske beinhalten. In der zweiten Phase 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, wenn die Berechnung durchgeführt wird, das Ergebnis der Berechnung wiederholbar und zuverlässig auf einen bestimmten nichtflüchtigen Festkörperspeicher 152 verweist, der diese Authority 168 aufweist. Die Operation kann die Menge der erreichbaren Speicherknoten als Eingabe enthalten. Wenn sich die Menge der erreichbaren nichtflüchtigen Festkörperspeicher ändert, ändert sich die optimale Menge. In einigen Ausführungsformen ist der persistierte Wert die aktuelle Zuordnung (die immer wahr ist) und der berechnete Wert ist die Zielzuordnung, zu der der Cluster versucht, sich neu zu konfigurieren. Diese Berechnung kann verwendet werden, um den optimalen nichtflüchtigen Festkörperspeicher 152 für eine Authority zu bestimmen, wenn eine Menge von nichtflüchtigen Festkörperspeichern 152 vorhanden ist, die erreichbar sind und denselben Cluster bilden. Die Berechnung bestimmt auch einen angeordneten Satz von gleichrangigen nichtflüchtigen Festkörperspeichern 152, die ebenfalls die Zuordnung von Authority zu nichtflüchtigem Festkörperspeicher aufzeichnen, so dass die Authority auch dann bestimmt werden kann, wenn der zugewiesene nichtflüchtige Festkörperspeicher unerreichbar ist. In einigen Ausführungsformen kann eine Duplikat- oder eine Ersatz-Authority 168 herangezogen werden, wenn eine bestimmte Authority 168 nicht verfügbar ist.
  • Unter Bezugnahme auf die 2A und 2B sind zwei der vielen Aufgaben der CPU 156 auf einem Speicherknoten 150 das Zerlegen von Schreibdaten und das Wiederzusammensetzen von Lesedaten. Wenn das System festgestellt hat, dass Daten geschrieben werden sollen, wird die Authority 168 für diese Daten wie vorstehend beschrieben ermittelt. Wenn die Segment-ID für die Daten bereits bestimmt ist, wird die Schreibanforderung an den nichtflüchtigen Festkörperspeicher 152 weitergeleitet, der gerade als Host der aus dem Segment ermittelten Authority 168 ermittelt wird. Die Host-CPU 156 des Speicherknotens 150, auf dem sich der nichtflüchtige Festkörperspeicher 152 und die zugehörige 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 als Daten-Stripes in Übereinstimmung mit einem Löschkodierungsschema geschrieben. In einigen Ausführungsformen werden die Daten zum Abrufen angefordert, in anderen Ausführungsformen werden die Daten gepushed. Im umgekehrten Fall, wenn Daten gelesen werden, wird 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 von dem nichtflüchtigen Festkörperspeicher und den entsprechenden Speicherknoten an, auf die die Authority verweist. In einigen Ausführungsformen werden die Daten aus dem Flash-Speicher als ein Daten-Stripes gelesen. Die Host-CPU 156 des Speicherknotens 150 setzt dann die gelesenen Daten neu zusammen, korrigiert alle Fehler (falls vorhanden) gemäß dem entsprechenden Löschkodierungsschema und leitet die neu 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 Daten an, die an den Speicherknoten 150 gesendet werden sollen, indem er Seiten aus dem Speicher anfordert und dann die Daten 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 einer Inode gehandhabt, die bzw. die eine Datenstruktur angibt, die ein Objekt in einem Dateisystem darstellt. Das Objekt kann z. B. eine Datei oder ein Verzeichnis sein. Das Objekt kann von Metadaten begleitet werden, die unter anderem Attribute wie Authority-Daten und einen Zeitstempel der Erstellung enthalten. In einem Dateisystem könnte dem gesamten oder einem Teil eines solchen Objekts eine Segmentnummer zugewiesen werden. In anderen Systemen werden Datensegmente mit einer an anderer Stelle vergebenen Segmentnummer gehandhabt. Zu Diskussionszwecken 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 Gruppen 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 die 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 den physikalischen Flash-Speicherplätzen, d. h. die Datensegmentnummer befindet sich in diesem Adressraum. Segmente können auch Metadaten enthalten, die es ermöglichen, die Datenredundanz wiederherzustellen (auf verschiedene Flash-Speicherplätze oder -Geräte umzuschreiben), ohne dass eine übergeordnete Software beteiligt ist. In einer Ausführungsform enthält ein internes Format eines Segments Client-Daten und Medium-Mappings, um die Position dieser Daten zu bestimmen. Jedes Datensegment ist z. B. vor Speicher- und anderen Fehlern geschützt, indem das Segment in eine Anzahl von Daten- und Paritäts-Shards unterteilt wird, wo dieses anwendbar ist. Die Daten- und Paritäts-Shards werden über nichtflüchtige Festkörperspeicher 152, die mit den Host-CPUs 156 gekoppelt sind (siehe 2E und 2G), gemäß einem Löschkodierungsschema verteilt, d. h. striped. Die Verwendung des Begriffs „Segmente“ bezieht sich in einigen Ausführungsformen auf den Container und seinen Platz im Adressraum der Segmente. Die Verwendung des Begriffs „Stripe“ bezieht sich auf den gleichen Satz von Shards wie ein Segment und beinhaltet, wie die Shards zusammen mit Redundanz- oder Paritätsinformationen gemäß einigen Ausführungsformen verteilt werden.
  • In einem gesamten Speichersystem findet eine Reihe von Adressraum-Transformationen statt. An der Spitze stehen die Verzeichniseinträge (Dateinamen), die auf einen Inode verweisen. Inodes verweisen auf einen mittleren Adressraum, in dem die 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. Medium-Adressen können über eine Reihe von indirekten Medien abgebildet werden, um die Last großer Dateien zu verteilen, oder können Datendienste wie Deduplizierung oder Snapshots implementieren. Segmentadressen werden dann in physikalische Flash-Speicherplätze übersetzt. Physikalische Flash-Speicherplätze haben einen Adressbereich, der gemäß einigen Ausführungsformen durch die Menge an Flash im System begrenzt ist. Mittlere und Segmentadressen sind logische Container und verwenden in einigen Ausführungsformen eine Kennung von 128-Bit- oder größer, so dass sie praktisch unendlich sind, 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 in einer hierarchischen Weise zugewiesen. Anfänglich kann jeder nichtflüchtigen Festkörperspeichereinheit 152 ein Bereich von Adressraum zugewiesen werden. Innerhalb dieses zugewiesenen Bereichs kann der nichtflüchtige Festkörperspeicher 152 Adressen ohne Synchronisation mit anderen nichtflüchtigen Festkörperspeichern 152 zuweisen.
  • Daten und Metadaten werden in einer Reihe von zugrunde liegenden Speicherlayouts gespeichert, die für unterschiedliche Auslastungsmuster und Speichergeräte optimiert sind. Diese Layouts enthalten 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 ein Low Density Parity Check („LDPC“)-Code innerhalb einer einzelnen Speichereinheit verwendet. In einigen Ausführungsformen wird die Reed-Solomon-Codierung innerhalb eines Storage-Clusters und die Spiegelung innerhalb eines Speichergitters verwendet. Metadaten können unter Verwendung eines geordneten logstrukturierten Indexes (z. B. eines 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 aufrechtzuerhalten, 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 Zuordnung von Entitäten zu Authorities, durch Aufteilung von Entitäten in Bereiche basierend auf einem extern erzeugten Schlüssel oder durch Platzierung einer einzelnen Entität in jeder Authority erfolgen. Beispiele für pseudozufällige Schemata sind lineares Hashing und die Familie der Hashes „Replication Under Scalable Hashing“ („RUSH“), einschließlich „Controlled Replication Under Scalable Hashing“ („CRUSH“). In einigen Ausführungsformen wird die pseudozufällige Zuordnung nur für die Zuordnung an Authorities zu Knoten verwendet, da sich die Menge der Knoten ändern kann. Der Satz von Authorities kann sich nicht ändern, so dass in diesen Ausführungsformen eine 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 jede Authority auf einen Satz von Kandidaten für einen Authority-Besitzer abzubilden. Eine pseudozufällige Datenverteilungsfunktion, die mit CRUSH zusammenhängt, kann Authorities zu 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 zu derselben Berechnung für die Verteilung und das spätere Auffinden oder Lokalisieren einer Authority gelangen. Jedes der pseudozufälligen Schemata benötigt in einigen Ausführungsformen den erreichbaren Satz von Speicherknoten als Eingabe, 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 demselben Satz von Geräten zu speichern.
  • Beispiele für zu erwartende Ausfälle sind Geräteausfälle, gestohlene Maschinen, Brände im Rechenzentrum und regionale Notfälle, wie z. B. nukleare oder geologische Ereignisse. Unterschiedliche Ausfälle führen zu einem unterschiedlichen Grad an akzeptablen Datenverlusten. In einigen Ausführungsformen hat ein gestohlener Speicherknoten weder Auswirkungen auf die Sicherheit noch auf die Zuverlässigkeit des Systems, während ein regionales Ereignis je nach Systemkonfiguration zu keinem Datenverlust, zu einigen Sekunden oder Minuten verlorener Aktualisierungen oder sogar zu einem vollständigen Datenverlust führen kann.
  • In den Ausführungsformen ist die Platzierung von Daten für die Speicherredundanz unabhängig von der Platzierung von Authorities für die Datenkonsistenz. In einigen Ausführungsformen enthalten Speicherknoten, die Authorities enthalten, keinen persistenten Speicher. Stattdessen sind die Speicherknoten mit nichtflüchtigen Festkörperspeichereinheiten verbunden, die keine Authorities enthalten. Die Kommunikationsverbindung zwischen den Speicherknoten und den nichtflüchtigen Festkörperspeichereinheiten besteht aus mehreren Kommunikationstechnologien und hat uneinheitliche Leistungs- und Fehlertoleranzeigenschaften. In einigen Ausführungsformen sind, wie vorstehend erwähnt, nichtflüchtige Festkörperspeichereinheiten über PCI-Express mit Speicherknoten verbunden, Speicherknoten sind innerhalb eines einzelnen Chassis über eine Ethernet-Backplane miteinander verbunden und Chassis sind miteinander verbunden, um einen Storage-Cluster zu bilden. In einigen Ausführungsformen sind die Storage-Cluster über Ethernet oder Glasfaserkabel mit den Clients verbunden. Wenn mehrere Storage-Cluster zu einem Speicher-Grid konfiguriert sind, werden die mehreren Storage-Cluster über das Internet oder andere Fernnetzwerkverbindungen über große Entfernungen verbunden, z. B. eine „Metro-Scale“-Verbindung oder eine private Verbindung, die nicht über das Internet verläuft.
  • Authority-Besitzer haben das ausschließliche Recht, Entitäten zu ändern, Entitäten von einer nichtflüchtigen Festkörperspeichereinheit auf eine andere nichtflüchtige Festkörperspeichereinheit zu migrieren und Kopien von Entitäten hinzuzufügen und zu entfernen. Dies ermöglicht die Aufrechterhaltung der Redundanz der zugrunde liegenden Daten. Wenn ein Entitätsbesitzer ausfällt, außer Betrieb genommen werden soll oder überlastet ist, wird die Entität auf einen neuen Speicherknoten übertragen. Bei vorübergehenden Ausfällen ist es nicht trivial, sicherzustellen, dass alle nicht ausgefallenen Rechner dem neuen Speicherort der Authority zustimmen. Die Mehrdeutigkeit, die durch vorübergehende Ausfälle entsteht, kann automatisch durch ein Konsensprotokoll wie Paxos, Hot-Warm-Failover-Schemata, durch manuelle Eingriffe eines entfernten Systemadministrators oder durch einen lokalen Hardware-Administrator (z. B. durch physisches Entfernen des ausgefallenen Rechners aus dem Cluster oder durch Drücken einer Taste auf dem ausgefallenen Rechner) erreicht werden. 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 gemäß einigen Ausführungsformen eingreift.
  • Während Authorities zwischen Speicherknoten übertragen werden und Authority-Besitzer Entitäten in ihren Authorities aktualisieren, überträgt das System Nachrichten zwischen den Speicherknoten und nichtflüchtigen Festkörperspeichereinheiten. Im Hinblick auf persistente Nachrichten sind Nachrichten, die unterschiedliche Zwecke aufweisen, von unterschiedlichem Typ. Je nach Art der Nachricht hält das System unterschiedliche Ordnungs- und Haltbarkeitsgarantien ein. 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 Nachrichten in RAM, NVRAM und auf NAND-Flash-Geräten gespeichert, und es werden verschiedene Protokolle verwendet, um die einzelnen Speichermedien effizient zu nutzen. Latenzempfindliche Client-Anfragen können in repliziertem NVRAM und dann später im NAND gespeichert werden, während Operationen zum Rebalancing im Hintergrund direkt im NAND persistiert werden.
  • Persistente Nachrichten werden vor der Übertragung persistent gespeichert. Dies ermöglicht es dem System, Client-Anfragen trotz Ausfällen und Komponentenaustausch weiterhin zu bedienen. Obwohl viele Hardwarekomponenten eindeutige Kennungen enthalten, die für Systemadministratoren, Hersteller, die Hardware-Lieferkette und die Infrastruktur für die laufende Überwachung der Qualitätskontrolle sichtbar sind, virtualisieren Anwendungen, die auf der Infrastruktur laufen, die Adressen. Diese virtualisierten Adressen ändern sich während der Lebensdauer des Speichersystems nicht, unabhängig von Komponentenausfällen und - austausch. Dadurch kann jede Komponente des Speichersystems im Laufe der Zeit ausgetauscht werden, ohne dass es zu einer Neukonfiguration oder Unterbrechung der Client-Anfrageverarbeitung kommt, 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 von fehlerhaften Komponenten und Fertigungsdetails. Das Überwachungssystem ermöglicht auch die proaktive Übertragung von Authorities und Entitäten weg von betroffenen Geräten, bevor ein Ausfall auftritt, 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 zu dem Speicherknoten 150 über 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 Direktzugriffsspeicher („NVRAM“) 204 und einen Flash-Speicher 206. In einigen Ausführungsformen kann der 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 häufiger beschrieben zu werden, als aus dem Speicher gelesen wird. In 2C ist der NVRAM 204 in einer Ausführungsform als flüchtiger Hochgeschwindigkeitsspeicher implementiert, z. B. als dynamischer Direktzugriffsspeicher (DRAM) 216, der durch eine Energiereserve 218 gesichert wird. Die Energiereserve 218 stellt ausreichend elektrische Energie zur Verfügung, um den DRAM 216 lange genug mit Strom zu versorgen, damit der Inhalt im Falle eines Stromausfalls in den Flash-Speicher 206 übertragen werden kann. In einigen Ausführungsformen ist die Energiereserve 218 ein Kondensator, Superkondensator, eine Batterie oder ein anderes Gerät, das eine geeignete Energieversorgung liefert, die ausreicht, um die Übertragung des Inhalts des DRAM 216 auf ein dauerhaftes Speichermedium im Falle eines Stromausfalls zu ermöglichen. Der Flash-Speicher 206 ist als Mehrfach-Flash-Dies 222 implementiert, die auch als Pakete von Flash-Dies 222 oder als Array von Flash-Dies 222 bezeichnet werden können. Es sollte verstanden werden, dass die Flash-Dies 222 auf jede beliebige Art und Weise verpackt sein können, mit einem einzelnen Chip pro Chassis, mehreren Chips pro Chassis (d.h. Multichip-Chassis), in Hybrid-Chassis, als nackte Chips auf einer Leiterplatte oder einem anderen Substrat, als gekapselte Chips, usw. In der gezeigten Ausführungsform hat der nichtflüchtige Festkörperspeicher 152 einen Controller 212 oder einen anderen Prozessor und einen mit dem Controller 212 gekoppelten Eingangs-Ausgangs-Port (E/A) 210. Der E/A-Port 210 ist mit der CPU 156 und/oder dem Netzwerkschnittstellen-Controller 202 des Flash-Speicherknotens 150 gekoppelt. Der Flash-Eingangs-/Ausgangs-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 dargestellten Ausführungsform sind der E/A-Port 210, der Controller 212, die DMA-Einheit 214 und der Flash-E/A-Port 220 auf einem programmierbaren Logikbaustein („PLD“) 208, z. B. einem FPGA, implementiert. In dieser Ausführungsform hat jeder Flash-Die 222 Seiten, die als sechzehn kB (Kilobyte) Seiten 224 organisiert sind, und ein Register 226, über das Daten in den Flash-Die 222 geschrieben oder aus ihm gelesen werden können. In weiteren Ausführungsformen werden andere Arten von Festkörperspeichern anstelle von oder zusätzlich zu dem im Flash-Die 222 dargestellten Flash-Speicher verwendet.
  • Storage-Cluster 161 können in verschiedenen Ausführungsformen, wie hier offengelegt, 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 für die Bereitstellung der Daten erforderlichen Rechenleistung. Mehrere Speicherknoten 150 arbeiten zusammen, um die Daten zu speichern und abzurufen. Speicher oder Speichergeräte, wie sie in Speicher-Arrays im Allgemeinen verwendet werden, sind weniger an der Verarbeitung und Manipulation der Daten beteiligt. Der Speicher oder die 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 kennen sie die Bedeutung der Daten. Der Speicher oder die Speichergeräte in Speicher-Arrays können verschiedene Arten von Speichern umfassen, z. B. RAM, Solid-State-Laufwerke, Festplattenlaufwerke usw. 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 zu einer Kombination aus Speichereinheit 152 und Speicherknoten 150 wird. Durch die Verlagerung der Datenverarbeitung (relativ zu den Speicherdaten) in die Speichereinheit 152 wird diese Datenverarbeitung näher an die Daten selbst gebracht. Die verschiedenen Systemausführungen haben eine Hierarchie von Speicherknotenschichten mit unterschiedlichen Fähigkeiten. Im Gegensatz dazu besitzt in einem Speicher-Array ein Controller alle Daten, die er in einem Shelf oder auf Speichergeräten verwaltet, und weiß alles darüber. 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 Erasure Coding, Data Sharding, Metadatenkommunikation und -Redundanz, Erweiterung oder Verringerung der Speicherkapazität, Datenwiederherstellung usw.).
  • 2D zeigt eine Speicherserver-Umgebung, 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 Controller212 (siehe 2C), einen FPGA, einen Flash-Speicher 206 und NVRAM 204 (bei dem es sich um einen mit Superkondensatoren gesicherten DRAM 216 handelt, siehe 2B und 2C) auf einer PCIe-Platine (Peripheral Component Interconnect Express) in einem Chassis 138 (siehe 2A). Die Speichereinheit 152 kann als eine einzelne Platine mit Speicher implementiert werden und kann die größte tolerierbare Ausfall-Domäne innerhalb des Chassis sein. In einigen Ausführungsformen können bis zu zwei Speichereinheiten 152 ausfallen und das Gerät läuft ohne Datenverlust weiter.
  • In einigen Ausführungsformen ist der physische Speicher basierend auf der Anwendungsnutzung in benannte Regionen unterteilt. Der NVRAM 204 ist ein zusammenhängender Block reservierten Speichers in der Speichereinheit 152 DRAM 216 und wird durch NAND-Flash gesichert. Der NVRAM 204 ist logisch in mehrere Speicherbereiche unterteilt, die für zwei als Spool (z. B. spool_region) geschrieben werden. Der Speicherplatz innerhalb der Spools des NVRAM 204 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 Zuweisungen innerhalb dieses Speicherplatzes. Beispiele für einen Spool sind verteilte Transaktionen oder Begriffe. Wenn die primäre Stromversorgung einer Speichereinheit 152 ausfällt, sorgen die eingebauten Superkondensatoren für eine kurze Überbrückungszeit. 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.
  • Beim Speichereinheiten-Controller ist die Verantwortung des logischen „Controllers“ auf die einzelnen Blades verteilt, die Authorities 168 enthalten. Diese Verteilung der logischen Steuerung ist in 2D als Host-Controller 242, Mid-Tier-Controller 244 und Speichereinheiten-Controller 246 dargestellt. Die Verwaltung der Steuerungsebene und der Speicherebene werden unabhängig voneinander behandelt, obwohl Teile physisch auf demselben Blade untergebracht sein können. Jede Authority 168 dient effektiv als unabhängiger Controller. Jede Authority 168 bietet ihre eigenen Daten- und Metadatenstrukturen, ihre eigenen Hintergrundarbeiter und unterhält ihren eigenen Lebenszyklus.
  • 2E ist ein Hardware-Blockdiagramm des Blade 252, 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 Speicherserver-Umgebung von 2D verwendet werden. Die Steuerungsebene 254 ist in eine Reihe von Authorities 168 unterteilt, die die Rechenressourcen in der Rechenebene 256 nutzen können, um auf einem beliebigen der Blades 252 zu laufen. Die Speicherebene 258 ist in eine Reihe von Geräten partitioniert, von denen jedes Zugriff auf Flash-Ressourcen 206 und NVRAM-Ressourcen 204 bietet. In einer Ausführungsform kann die Rechenebene 256 die hier beschriebenen Operationen eines Speicher-Array-Controllers auf einem oder mehreren Geräten der Speicherebene 258 (z. B. einem Speicher-Array) ausführen.
  • In den Rechen- und Speicherebenen 256, 258 von 2E interagieren die Authorities 168 mit den zugrunde liegenden physischen Ressourcen (d. h. Geräten). Aus der Sicht einer Authority 168 werden 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 Instanzen gerade laufen. 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 zum Schreiben oder Lesen von Benutzerdaten. 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ößer dimensionierte Partitionen 260 in einer oder mehreren Speichereinheiten 152 haben als eine oder mehrere andere Authorities 168.
  • In 2F sind die Elasticity Software Layers in Blades 252 eines Storage-Clusters gemäß einigen Ausführungsformen dargestellt. In der Elastizitätsstruktur ist die Elastizitätssoftware symmetrisch, d. h., das Rechenmodul 270 jedes Blades führt die drei identischen Prozessschichten aus, die in 2F dargestellt sind. Speicherverwalter 274 führen Lese- und Schreibanfragen 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-Anfragen, indem sie die erforderlichen Lese- und Schreibvorgänge an die Blades 252 ausgeben, auf deren Speichereinheiten 152 sich die entsprechenden Daten oder Metadaten befinden. Endpunkte 272 analysieren die von der Überwachungssoftware der Switch Fabric 146 empfangenen Client-Verbindungsanfragen, leiten die Client-Verbindungsanfragen an die für die Erfüllung verantwortlichen Authorities 168 weiter und übermitteln die Antworten der Authorities 168 an die Clients. Die symmetrische Drei-Schichten-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 ein einzigartiges Scale-Out-Verfahren, das die Arbeit gleichmäßig auf alle Ressourcen verteilt, unabhängig vom Zugriffsmuster der Clients, und maximiert die Gleichzeitigkeit, indem es einen Großteil der Koordination zwischen den Blades eliminiert, die bei herkömmlichem verteiltem Sperren auftritt.
  • Wie in 2F dargestellt, führen Authorities 168, die in den Rechenmodulen 270 eines Blades 252 laufen, die internen Operationen aus, die zur Erfüllung von Client-Anforderungen erforderlich sind. Ein Merkmal der Elastizität ist, dass die Authorities 168 zustandslos sind, d. h. sie speichern aktive Daten und Metadaten in den DRAMs ihrer eigenen Blades 252 für einen schnellen Zugriff zwischen, aber die Instanzen speichern jede Aktualisierung in ihren NVRAM-Partitionen 204 auf drei separaten Blades 252, bis die Aktualisierung in den Flash 206 geschrieben wurde. Alle Schreibzugriffe des Speichersystems auf den NVRAM 204 erfolgen in einigen Ausführungsformen dreifach in 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 überstehen, ohne dass Daten, Metadaten oder der Zugriff darauf verloren gehen.
  • Da die Authorities 168 zustandslos sind, können sie zwischen Blades 252 umschalten. Jede Authority 168 hat eine eindeutige Kennung. Die NVRAM 204- und Flash 206-Partitionen sind mit den Kennungen der Authorities 168 verknüpft, nicht mit den Blades 252, auf denen sie in einigen Fällen ausgeführt werden. 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 Speicher-Clusters installiert wird, gleicht das System die Last automatisch aus, indem es den Speicher des neuen Blades 252 für die Verwendung durch die Authorities 168 des Systems partitioniert, ausgewählte Authorities 168 auf das neue Blade 252 migriert, Endpunkte 272 auf dem neuen Blade 252 startet und sie in den Algorithmus zur Verteilung der Client-Verbindungen der Switch-Fabric 146 einbezieht.
  • Von ihren neuen Standorten aus behalten die migrierten Authorities 168 den Inhalt ihrer NVRAM-Partitionen 204 auf dem Flash-Speicher 206 bei, verarbeiten Lese- und Schreibanforderungen von anderen Authorities 168 und erfüllen die Client-Anforderungen, die Endpunkte 272 an sie richten. Wenn ein Blade 252 ausfällt oder entfernt wird, verteilt das System 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 die Authorities 168 und Speicherressourcen in Blades 252 eines Storage-Clusters gemäß einigen Ausführungsformen. Jede Authority 168 ist ausschließlich für eine Partition des Flash-Speichers 206 und des NVRAM 204 auf jedem Blade 252 zuständig. Die Authority 168 verwaltet den Inhalt und die Integrität ihrer Partitionen unabhängig von anderen Authorities 168. Die Authorities 168 komprimieren die eingehenden Daten und bewahren sie vorübergehend in ihren NVRAM 204-Partitionen auf und konsolidieren, schützen und bewahren die Daten dann in Segmenten des Speichers in ihren Flash 206-Partitionen. Während die Authorities 168 Daten in den Flash-Speicher 206 schreiben, führen die Speicherverwalter 274 die notwendige Flash-Übersetzung durch, um die Schreibleistung zu optimieren und die Langlebigkeit der Medien zu maximieren. Im Hintergrund führen die Authorities 168 „Garbage Collect“ durch, d. h. sie fordern Speicherplatz zurück, der von Daten belegt ist, die von Clients durch Überschreiben der Daten veraltet wurden. Da die Partitionen der Authorities 168 disjunkt sind, ist kein verteiltes Sperren zur Ausführung von Client- und Schreibvorgängen oder zur Durchführung von Hintergrundfunktionen erforderlich.
  • 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 unterstützen. Die Ausführungsformen können z. B. Active Directory verwenden, ein datenbankbasiertes System, das Authentifizierungs-, Verzeichnis-, Richtlinien- und andere Dienste in einer WINDOWSTM-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 mit dem Network File System („NFS“) zusammenarbeitet, um eine beratende Datei- und Datensatzsperre im Stil von System V über ein Netzwerk bereitzustellen. Das Server Message Block („SMB“)-Protokoll, von dem eine Version auch als Common Internet File System („CIFS“) bekannt ist, kann in die hier beschriebenen Speichersysteme integriert werden. SMP arbeitet als Netzwerkprotokoll der Anwendungsschicht, 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 Kommunikationsmechanismus zwischen Prozessen. AMAZONTM S3 (Simple Storage Service) ist ein Webservice, der von Amazon Web Services bereitgestellt wird, und die hier beschriebenen Systeme können über Webservice-Schnittstellen (REST (Representational State Transfer), SOAP (Simple Object Access Protocol) und BitTorrent) mit Amazon S3 verbunden werden. Eine RESTfuI API (Application Programming Interface) zerlegt eine Transaktion in eine Reihe kleiner Module. Jedes Modul adressiert einen bestimmten zugrunde liegenden Teil der Transaktion. Die Kontrolle oder Authorities, die mit diesen Ausführungsformen bereitgestellt werden, insbesondere für Objektdaten, können die Verwendung einer Zugriffskontrollliste („ACL“) beinhalten. Die ACL ist eine Liste von Authorities, die an ein Objekt angehängt sind, und die ACL gibt an, welche Benutzer oder Systemprozesse Zugriff auf Objekte erhalten und welche Operationen an bestimmten Objekten erlaubt sind. Die Systeme können sowohl Internet Protocol Version 6 („IPv6“) als auch IPv4 für das Kommunikationsprotokoll verwenden, das ein Identifikations- und Lokalisierungssystem für Computer in Netzwerken bereitstellt und den Datenverkehr über das Internet leitet. Das Routing von Paketen zwischen vernetzten Systemen kann Equal-Cost-Multi-Path-Routing („ECMP“) umfassen, eine Routing-Strategie, bei der die Weiterleitung von Paketen zu einem einzelnen Ziel über mehrere „beste Pfade“ erfolgen kann, die bei der Berechnung der Routing-Metrik gleichauf liegen. Multi-Path-Routing kann in Verbindung mit den meisten Routing-Protokollen verwendet werden, da es sich um eine auf einen einzelnen Router beschränkte Pro-Hop-Entscheidung handelt. Die Software kann Multi-Tenancy unterstützen, was eine Architektur ist, in der eine einzelne Instanz einer Softwareanwendung mehrere Clients bedient. Jeder Client kann als „Tenant“ bezeichnet werden. Tenants können die Möglichkeit erhalten, einige Teile der Anwendung anzupassen, dürfen aber in einigen Ausführungsformen nicht den Code der Anwendung anpassen. Die Ausführungsformen können Audit-Protokolle führen. Ein Audit-Protokoll ist ein Dokument, das ein Ereignis in einem Computersystem aufzeichnet. Zusätzlich zur Dokumentation, auf welche Ressourcen zugegriffen wurde, enthalten Audit-Protokolleinträge typischerweise Ziel- und Quelladressen, einen Zeitstempel und Benutzeranmeldeinformationen zur Einhaltung verschiedener Vorschriften. Die Ausführungsformen können verschiedene Schlüsselverwaltungsrichtlinien unterstützen, z. B. die Rotation von Verschlüsselungsschlüsseln. Darüber hinaus kann das System dynamische Root-Passwörter oder eine Variante unterstützen, bei der sich die Passwörter dynamisch ändern.
  • 3A zeigt ein Diagramm eines Speichersystems 306, das für die Datenkommunikation mit einem Cloud-Service-Anbieter 302 in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung gekoppelt ist. Obwohl weniger detailliert dargestellt, kann das in 3A dargestellte Speichersystem 306 den vorstehend mit Bezug auf die 1A-1D und 2A-2G beschriebenen Speichersystemen ähnlich sein. In einigen Ausführungsformen kann das in 3A dargestellte Speichersystem 306 ausgeführt werden als ein Speichersystem mit unsymmetrisch aktiven/aktiven Controllern, als ein Speichersystem mit symmetrisch 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 ein Speichersystem, das vollständig aktive/aktive Controller enthält, als ein Speichersystem, das datensatzgetrennte Controller enthält, als ein Speichersystem, das Dual-Layer-Architekturen mit Front-End-Controllern und integrierten Back-End-Speicher-Controllern enthält, als ein Speichersystem, das Scale-Out-Cluster von Dual-Controller-Arrays enthält, sowie Kombinationen solcher Ausführungsformen.
  • In dem in 3A dargestellten Beispiel ist das Speichersystem 306 über eine Datenkommunikationsverbindung 304 mit dem Cloud-Service-Anbieter 302 gekoppelt. Die Datenkommunikationsverbindung 304 kann als dedizierte Datenkommunikationsverbindung, als Datenkommunikationspfad, der durch die Verwendung eines oder mehrerer Datenkommunikationsnetze, wie z. B. eines Wide Area Network („WAN“) oder eines LAN, bereitgestellt wird, oder als ein anderer Mechanismus, der in der Lage ist, digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 zu transportieren, ausgeführt werden. Eine solche Datenkommunikationsverbindung 304 kann vollständig verdrahtet, vollständig drahtlos oder eine Kombination aus verdrahteten und drahtlosen Datenkommunikationswegen sein. In einem solchen Beispiel können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung eines oder mehrerer Datenkommunikationsprotokolle ausgetauscht werden. Beispielsweise können digitale Informationen zwischen dem Speichersystem 306 und dem Cloud-Service-Anbieter 302 über die Datenkommunikationsverbindung 304 unter Verwendung des Handheld Device Transfer Protocol („HDTP“), des Hypertext Transfer Protocol („HTTP“), des Internet Protocol („IP“), des Real Time Transfer Protocol („RTP“), des Transmission Control Protocol („TCP“), des User Datagram Protocol („UDP“), des Wireless Application Protocol („WAP“) oder eines anderen Protokolls ausgetauscht werden.
  • Der in 3A dargestellte Cloud-Service-Anbieter 302 kann beispielsweise als ein System und eine Computerumgebung verkörpert werden, die den Benutzern des Cloud-Service-Providers 302 durch die gemeinsame Nutzung von Rechenressourcen über die Datenkommunikationsverbindung 304 eine große Anzahl von Diensten bereitstellt. Der Cloud-Service-Anbieter 302 kann einen On-Demand-Zugriff auf einen gemeinsamen Pool konfigurierbarer Computing-Ressourcen wie Computernetzwerke, Server, Speicher, Anwendungen und Dienste usw. bereitstellen. Der gemeinsam genutzte Pool konfigurierbarer Ressourcen kann schnell und mit minimalem Verwaltungsaufwand für einen Benutzer des Cloud-Diensteanbieters 302 bereitgestellt und freigegeben werden. Im Allgemeinen kennt der Benutzer des Cloud-Service-Anbieters 302 die genauen Computing-Ressourcen nicht, die der Cloud-Service-Anbieter 302 für die Bereitstellung der Dienste verwendet. Obwohl in vielen Fällen ein solcher Cloud-Service-Anbieter 302 über das Internet zugänglich sein kann, werden diejenigen, die im Fachgebiet erfahren sind, erkennen, dass jedes System, das die Nutzung gemeinsam genutzter Ressourcen zur Bereitstellung von Diensten für einen Benutzer über eine beliebige Datenkommunikationsverbindung bereitzustellt, als Cloud-Service-Anbieter 302 betrachtet werden kann.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Service-Anbieter 302 so konfiguriert sein, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 durch die Implementierung verschiedener Dienstmodelle eine Vielzahl von Diensten bereitstellt. Zum Beispiel kann der Cloud-Service-Anbieter 302 so konfiguriert sein, dass er Dienste durch die Implementierung eines Dienstmodells Infrastructure-as-a-Service („laaS“), durch die Implementierung eines Dienstmodells Platform-as-a-Service („PaaS“), durch die Implementierung eines Dienstmodells Service-as-a-Service („SaaS“) bereitstellt, durch die Implementierung eines Dienstmodells Authentification-as-a-Service („AaaS“), durch die Implementierung eines Dienstmodells Storage as a Service, bei dem der Cloud-Dienste-Anbieter 302 dem Speichersystem 306 und den Nutzern des Speichersystems 306 Zugang zu seiner Speicherinfrastruktur bietet, und so weiter. Für den Leser ist zu erkennen, dass der Cloud-Service-Anbieter 302 so konfiguriert sein kann, dass er dem Speichersystem 306 und den Nutzern des Speichersystems 306 durch die Implementierung zusätzlicher Servicemodelle zusätzliche Dienste bereitstellt, da die vorstehend beschriebenen Servicemodelle nur zu Erklärungszwecken enthalten sind und in keiner Weise eine Einschränkung der Dienste darstellen, die vom Cloud-Service-Anbieter 302 bereitgestellt werden können, oder eine Einschränkung hinsichtlich der Servicemodelle, die vom Cloud-Service-Anbieter 302 implementiert werden können.
  • In dem in 3A dargestellten Beispiel kann der Cloud-Service-Anbieter 302 beispielsweise als private Cloud, als öffentliche Cloud oder als eine Kombination aus einer privaten und einer öffentlichen Cloud ausgeführt sein. In einer Ausführungsform, in der der Cloud-Service-Anbieter 302 als private Cloud ausgeführt ist, kann der Cloud-Service-Anbieter 302 auf die Bereitstellung von Diensten für eine einzelne Organisation ausgerichtet sein, anstatt Dienste für mehrere Organisationen bereitzustellen. In einer Ausführungsform, in der der Cloud-Service-Anbieter 302 als öffentliche Cloud verkörpert ist, kann der Cloud-Service-Anbieter 302 Dienste für mehrere Organisationen bereitstellen. In weiteren alternativen Ausführungsformen kann der Cloud-Service-Anbieter 302 als eine Mischung aus privaten und öffentlichen Cloud-Diensten mit einer hybriden Cloud-Bereitstellung verkörpert sein.
  • Obwohl in 3A nicht explizit dargestellt, wird der Leser erkennen, dass eine große Anzahl zusätzlicher Hardwarekomponenten und zusätzlicher Softwarekomponenten erforderlich sein kann, um die Bereitstellung von Cloud-Diensten für das Speichersystem 306 und die Benutzer des Speichersystems 306 zu erleichtern. Zum Beispiel kann das Speichersystem 306 mit einem Cloud-Storage-Gateway gekoppelt sein (oder dieses sogar enthalten). Ein solches Cloud-Storage-Gateway kann beispielsweise als hardware- oder softwarebasiertes Gerät verkörpert sein, das sich vor Ort mit dem Speichersystem 306 befindet. Ein solches Cloud-Storage-Gateway kann als Brücke zwischen lokalen Anwendungen, die auf dem Speicher-Array 306 ausgeführt werden, und entferntem, cloudbasiertem Speicher, der vom Speicher-Array 306 genutzt wird, fungieren. Durch die Verwendung eines Cloud-Storage-Gateways können Unternehmen primäre iSCSI- oder NAS-Speicher zum Cloud-Service-Anbieter 302 verlagern und dadurch Platz auf ihren lokalen Speichersystemen sparen. Ein solches Cloud-Speicher-Gateway kann so konfiguriert sein, 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 übersetzen kann, die die Kommunikation mit dem Cloud-Service-Anbieter 302 erleichtern.
  • Damit das Speichersystem 306 und die Benutzer des Speichersystems 306 die vom Cloud-Service-Anbieter 302 bereitgestellten Dienste nutzen können, kann ein Cloud-Migrationsprozess stattfinden, bei dem Daten, Anwendungen oder andere Elemente aus den lokalen Systemen einer Organisation (oder sogar aus einer anderen Cloud-Umgebung) zum Cloud-Service-Anbieter 302 verschoben werden. Um Daten, Anwendungen oder andere Elemente erfolgreich in die Umgebung des Cloud-Service-Providers 302 zu migrieren, kann Middleware wie ein Cloud-Migrations-Tool verwendet werden, um Lücken zwischen der Umgebung des Cloud-Service-Providers 302 und der Umgebung einer Organisation zu überbrücken. Solche Cloud-Migrations-Tools können auch so konfiguriert sein, dass sie potenziell hohe Netzwerkkosten und lange Übertragungszeiten, die mit der Migration großer Datenmengen zum Cloud-Service-Anbieter 302 verbunden sind, sowie Sicherheitsbedenken im Zusammenhang mit sensiblen Daten zum Cloud-Service-Anbieter 302 über Datenkommunikationsnetzwerke berücksichtigen. Um das Speichersystem 306 und die Benutzer des Speichersystems 306 in die Lage zu versetzen, die vom Cloud-Service-Anbieter 302 bereitgestellten Dienste zu nutzen, kann auch ein Cloud-Orchestrator verwendet werden, um automatisierte Aufgaben anzuordnen und zu koordinieren, um einen konsolidierten Prozess oder Workflow zu erreichen. Ein solcher Cloud-Orchestrator kann Aufgaben wie die Konfiguration verschiedener Komponenten übernehmen, unabhängig davon, ob es sich bei diesen Komponenten um Cloud-Komponenten oder lokale Komponenten handelt, sowie die Verwaltung der Verbindungen zwischen diesen Komponenten. Der Cloud-Orchestrator kann die Kommunikation zwischen den Komponenten und die Verbindungen vereinfachen, um sicherzustellen, dass die Verbindungen korrekt konfiguriert und gepflegt werden.
  • In dem in 3A dargestellten Beispiel und wie vorstehend kurz beschrieben, kann der Cloud-Service-Anbieter 302 so konfiguriert sein, dass er Dienste für das Speichersystem 306 und die Benutzer des Speichersystems 306 durch die Verwendung eines SaaS-Dienstmodells bereitstellt, wodurch die Notwendigkeit entfällt, die Anwendung auf lokalen Computern zu installieren und auszuführen, was die Wartung und Unterstützung der Anwendung vereinfachen kann. Solche Anwendungen können viele Formen in Übereinstimmung mit verschiedenen Ausführungsformen der vorliegenden Offenbarung annehmen. Beispielsweise kann der Anbieter von Cloud-Diensten 302 so konfiguriert sein, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Zugang zu Datenanalyseanwendungen gewährt. Solche Datenanalyseanwendungen können beispielsweise so konfiguriert sein, dass sie große Mengen an Telemetriedaten empfangen, die von dem Speichersystem 306 abgerufen werden. Solche Telemetriedaten können verschiedene Betriebseigenschaften des Speichersystems 306 beschreiben und können für eine Vielzahl von Zwecken analysiert werden, z. B. um den Zustand des Speichersystems 306 zu bestimmen, um Arbeitslasten zu identifizieren, die auf dem Speichersystem 306 ausgeführt werden, um vorherzusagen, wann dem Speichersystem 306 verschiedene Ressourcen ausgehen, um Konfigurationsänderungen, Hardware- oder Software-Upgrades, Workflow-Migrationen oder andere Maßnahmen zu empfehlen, die den Betrieb des Speichersystems 306 verbessern können.
  • Der Cloud-Service-Anbieter 302 kann auch so konfiguriert sein, dass er dem Speichersystem 306 und den Benutzern des Speichersystems 306 Zugang zu virtualisierten Computerumgebungen bietet. Solche virtualisierten Computerumgebungen können beispielsweise als virtuelle Maschine oder andere virtualisierte Computerhardwareplattformen, virtuelle Speichergeräte, virtualisierte Computernetzwerkressourcen 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 von konkreten Dateisystemen ermöglichen, und vieles andere.
  • Zur weiteren Erläuterung ist in 3B ein Diagramm eines Speichersystems 306 gemäß einigen Ausführungsformen der vorliegenden Offenbarung dargestellt. Obwohl weniger detailliert dargestellt, kann das in 3B dargestellte Speichersystem 306 den vorstehend 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 eine große Menge an Speicherressourcen 308 enthalten, die in vielen Formen verkörpert sein können. Beispielsweise können die Speicherressourcen 308 Nano-RAM oder eine andere Form eines nichtflüchtigen Direktzugriffsspeichers, der auf einem Substrat abgeschiedene Kohlenstoffnanoröhrchen verwendet, einen nichtflüchtigen 3D-Kreuzpunktspeicher, einen Flash-Speicher 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 oder andere umfassen. Ebenso können die Speicherressourcen 308 nichtflüchtige magnetoresistive Direktzugriffsspeicher („MRAM“), einschließlich Spin-Transfer-Torque („STT“) MRAM, umfassen. Die beispielhaften Speicherressourcen 308 können alternativ einen nichtflüchtigen Phasenänderungsspeicher („PCM“), einen Quantenspeicher, der die Speicherung und den Abruf photonischer Quanteninformationen ermöglicht, einen resistiven Direktzugriffsspeicher („ReRAM“), Storage Class Memories („SCM“) oder eine andere Form von Speicherressourcen umfassen, einschließlich einer beliebigen Kombination der hier beschriebenen Ressourcen. 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 verkörpert sein, einschließlich, aber nicht beschränkt auf, Dual-In-Line-Speicher-Module („DIMMs“), nichtflüchtige Dual-In-Line-Speicher-Module („NVDIMMs“), M.2, U.2 und andere.
  • Die in 3A dargestellten Speicherressourcen 308 können verschiedene Formen von SCM enthalten. SCM kann schnellen, nichtflüchtigen Speicher (z. B. NAND-Flash) effektiv als eine Erweiterung von DRAM behandeln, so dass ein gesamter Datensatz als ein In-Memory-Datensatz behandelt werden kann, der sich vollständig in DRAM befindet. SCM kann nichtflüchtige Medien wie z. B. NAND-Flash enthalten. Auf solchen NAND-Flash kann mit NVMe zugegriffen werden, das den PCIe-Bus als Transportweg nutzen kann, was im Vergleich zu älteren Protokollen relativ geringe Zugriffslatenzen ermöglicht. Tatsächlich können die Netzwerkprotokolle, die für SSDs in All-Flash-Arrays verwendet werden, NVMe mit Ethernet (ROCE, NVME TCP), Fibre Channel (NVMe FC), InfiniBand (iWARP) und andere umfassen, die es ermöglichen, schnellen, nichtflüchtigen Speicher als eine Erweiterung von DRAM zu handhaben. Angesichts der Tatsache, dass DRAM oft Byte-adressierbar ist und schneller, nichtflüchtiger Speicher wie NAND-Flash Block-adressierbar ist, kann ein Controller-Software/Hardware-Stack erforderlich sein, um die Blockdaten in die Bytes umzuwandeln, die in den Medien gespeichert sind. Beispiele für Medien und Software, die als SCM verwendet werden können, sind z. B. 3D XPoint, Intel Memory Drive Technology, Samsungs Z-SSD und andere.
  • Das in 3B dargestellte beispielhafte Speichersystem 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 wie eine einzelne Festplatte funktioniert. Speichersysteme in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung können Objektspeicher verwenden, bei denen Daten als Objekte verwaltet werden. Jedes Objekt kann die Daten selbst, eine variable Menge an Metadaten und einer global eindeutigen Kennung enthalten, wobei die Objektspeicherung auf mehreren Ebenen implementiert werden kann (z. B. Geräteebene, Systemebene, Schnittstellenebene). 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 werden und werden sowohl dem System, das sie speichert, als auch dem System, das sie abruft, im gleichen Format präsentiert.
  • Das in 3B dargestellte beispielhafte Speichersystem 306 kann als Speichersystem ausgeführt 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 hingegen 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 umfasst 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, einschließlich Ausführungsformen, bei denen diese Ressourcen durch eine relativ große Weite getrennt sind. Die Kommunikationsressourcen 310 können so konfiguriert sein, dass sie eine Vielzahl verschiedener Protokolle und Datenkommunikationsstrukturen verwenden, um die Datenkommunikation zwischen Komponenten innerhalb des Speichersystems sowie zwischen Datenverarbeitungsgeräten, die sich außerhalb des Speichersystems befinden, zu erleichtern. Beispielsweise können die Kommunikationsressourcen 310 Fibre-Channel („FC“)-Technologien wie FC-Fabrics und FC-Protokolle umfassen, die SCSI-Befehle über FC-Netzwerke transportieren können, FC-over-Ethernet („FCoE“)-Technologien, durch die FC-Frames gekapselt und über Ethernet-Netzwerke übertragen werden, umfassen, InfiniBand („IB“)-Technologien, bei denen eine Switched-Fabric-Topologie verwendet wird, um Übertragungen zwischen Kanaladaptern zu erleichtern, umfassen, NVM Express („NVMe“)-Technologien und NVMe over Fabrics („NVMeoF“)-Technologien, über die auf nichtflüchtige Speichermedien zugegriffen werden kann, die über einen PCI Express („PCIe“)-Bus angeschlossen sind, umfassen, und andere. In der Tat können die vorstehend beschriebenen Speichersysteme direkt oder indirekt Neutrino-Kommunikationstechnologien und -geräte nutzen, über die Informationen (einschließlich binärer Informationen) mithilfe eines Neutrinostrahls übertragen werden.
  • Die Kommunikationsressourcen 310 können auch Mechanismen für den Zugriff auf Speicherressourcen 308 innerhalb des Speichersystems 306 enthalten, die Serial Attached SCSI („SAS“), Serial ATA („SATA“) Busschnittstellen für den Anschluss von Speicherressourcen 308 innerhalb des Speichersystems 306 an Host-Busadapter innerhalb des Speichersystems 306 verwenden, Internet Small Computer Systems Interface („iSCSI“)-Technologien, um den Zugriff auf die Speicherressourcen 308 innerhalb des Speichersystems 306 auf Blockebene zu ermöglichen, und andere Kommunikationsressourcen, die bei der 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 umfasst auch Verarbeitungsressourcen 312, die bei der Ausführung von Computerprogrammbefehlen und der Durchführung anderer Rechenaufgaben innerhalb des Speichersystems 306 nützlich sein können. Die Verarbeitungsressourcen 312 können einen oder mehrere ASICs umfassen, die für einen bestimmten Zweck angepasst sind, sowie eine oder mehrere CPUs. Die Verarbeitungsressourcen 312 können auch einen oder mehrere DSPs, einen oder mehrere FPGAs, ein oder mehrere Systems-on-a-Chip („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 von Software-Ressourcen 314, die im Folgenden näher beschrieben werden.
  • Das in 3B dargestellte Speichersystem 306 umfasst auch Softwareressourcen 314, die, wenn sie von den Verarbeitungsressourcen 312 innerhalb des Speichersystems 306 ausgeführt werden, eine große Anzahl von Aufgaben ausführen können. Die Softwareressourcen 314 können beispielsweise ein oder mehrere Module von Computerprogrammbefehlen enthalten, die, wenn sie von den Verarbeitungsressourcen 312 innerhalb des Speichersystems 306 ausgeführt werden, bei der Durchführung verschiedener Datenschutzverfahren nützlich sind, um die Integrität der innerhalb der Speichersysteme gespeicherten Daten zu bewahren. Für den Leser ist zu erkennen, dass solche Datensicherungsverfahren z. B. durch Systemsoftware, die auf Computerhardware innerhalb des Speichersystems ausgeführt wird, durch einen Cloud-Service-Anbieter oder auf andere Weise ausgeführt werden können. Solche Datensicherungsverfahren können beispielsweise Datenarchivierungsverfahren umfassen, die bewirken, dass Daten, die nicht mehr aktiv verwendet werden, zur langfristigen Aufbewahrung auf ein separates Speichergerät oder ein separates Speichersystem verschoben werden, Datensicherungsverfahren, durch die im Speichersystem gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um einen Datenverlust im Falle eines Geräteausfalls oder einer anderen Form von Notfall mit dem Speichersystem zu vermeiden, Datenreplikationsverfahren, durch die im Speichersystem gespeicherte Daten auf ein anderes Speichersystem repliziert werden, so dass die Daten über mehrere Speichersysteme zugänglich sein können, Daten-Snapshot-Techniken, durch die der Zustand von Daten innerhalb des Speichersystems zu verschiedenen Zeitpunkten erfasst wird, Daten- und Datenbank-Klonverfahren, durch die Duplikate von Daten und Datenbanken erstellt werden können, und andere Datenschutzverfahren.
  • Die Software-Ressourcen 314 können auch Software enthalten, die bei der Implementierung von Software-definiertem Speicher („SDS“) nützlich ist. In einem solchen Beispiel können die Softwareressourcen 314 ein oder mehrere Module mit Computerprogrammbefehlen enthalten, die, wenn sie ausgeführt werden, bei der richtlinienbasierten Bereitstellung und Verwaltung von Datenspeichern, die unabhängig von der zugrunde liegenden Hardware sind, 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, die die Speicherhardware verwaltet.
  • Die Software-Ressourcen 314 können auch Software enthalten, die bei der Erleichterung und Optimierung von E/A-Operationen nützlich ist, die an die Speicherressourcen 308 im Speichersystem 306 gerichtet sind. Beispielsweise können die Software-Ressourcen 314 Software-Module enthalten, die verschiedene Datenreduzierungsverfahren durchführen, wie z. B. Datenkomprimierung, Datendeduplizierung und andere. Die Software-Ressourcen 314 können Software-Module enthalten, die E/A-Operationen intelligent zusammenfassen, um eine bessere Nutzung der zugrunde liegenden Speicherressource 308 zu ermöglichen, Software-Module, die Datenmigrationsoperationen durchführen, um von innerhalb eines Speichersystems zu migrieren, sowie Software-Module, 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.
  • Zur weiteren Erläuterung ist in 3C ein Beispiel für ein cloudbasiertes Speichersystem 318 gemäß einigen Ausführungsformen der vorliegenden Offenbarung dargestellt. In dem in 3C dargestellten Beispiel wird das cloudbasierte Speichersystem 318 vollständig in einer Cloud-Computing-Umgebung 316 erstellt, wie z. B. Amazon Web Services („AWS“), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud und andere. Das cloudbasierte Speichersystem 318 kann verwendet werden, um Dienste bereitzustellen, die den Diensten ähnlich sind, die von den vorstehend beschriebenen Speichersystemen bereitgestellt werden können. Beispielsweise kann das cloudbasierte Speichersystem 318 verwendet werden, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems 318 bereitzustellen, das cloudbasierte Speichersystem 318 kann verwendet werden, um Storage-Dienste für Benutzer des cloudbasierten Speichersystems 318 durch die Verwendung von Festkörperspeicher bereitzustellen, und so weiter.
  • Das in 3C dargestellte cloudbasierte Speichersystem 318 umfasst zwei Cloud-Computing-Instanzen 320, 322, die jeweils zur Unterstützung der Ausführung einer Speicher-Controller-Anwendung 324, 326 verwendet werden. Die Cloud-Computing-Instanzen 320, 322 können beispielsweise als Instanzen von Cloud-Computing-Ressourcen (z. B. virtuelle Maschinen) verkörpert sein, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden können, um das Ausführen von Softwareanwendungen wie der Speicher-Controller-Anwendung 324, 326 zu unterstützen. In einer Ausführungsform können die Cloud-Computing-Instanzen 320, 322 als Amazon Elastic Compute Cloud („EC2“)-Instanzen verkörpert sein. In einem solchen Beispiel kann ein Amazon Machine Image („AMI“), das die Speicher-Controller-Anwendung 324, 326 enthält, gebootet werden, um eine virtuelle Maschine zu erstellen und zu konfigurieren, die die Speicher-Controller-Anwendung 324, 326 ausführen kann.
  • In dem in 3C dargestellten Beispielverfahren kann die Speicher-Controller-Anwendung 324, 326 als ein Modul von Computerprogrammbefehlen ausgeführt werden, das bei seiner Ausführung verschiedene Speicheraufgaben durchführt. Beispielsweise kann die Speicher-Controller-Anwendung 324, 326 als ein Modul von Computerprogrammbefehlen ausgeführt werden, das, wenn es ausgeführt wird, dieselben Aufgaben wie die vorstehend beschriebenen Steuerungen 110A, 110B in 1A ausführt, wie z. B. das Schreiben von Daten, die von den Benutzern des cloudbasierten Speichersystems 318 empfangen werden, in das cloudbasierte Speichersystem 318, Löschen von Daten aus dem cloudbasierten Speichersystem 318, Abrufen von Daten aus dem cloudbasierten Speichersystem 318 und Bereitstellen solcher Daten für Benutzer des cloudbasierten Speichersystems 318, Überwachen der Festplattenauslastung und -leistung und Berichten darüber, Durchführen von Redundanzoperationen, wie RAID- oder RAID-ähnliche Datenredundanzoperationen, Komprimieren von Daten, Verschlüsseln von Daten, Deduplizieren von Daten und so weiter. Für den Leser ist zu erkennen, dass aufgrund der Tatsache, dass es zwei Cloud-Computing-Instanzen 320, 322 gibt, die jeweils die Speicher-Controller-Anwendung 324, 326 enthalten, in einigen Ausführungsformen eine Cloud-Computing-Instanz 320 als der primäre Controller wie vorstehend beschrieben arbeiten kann, während die andere Cloud-Computing-Instanz 322 als der sekundäre Controller wie vorstehend beschrieben arbeiten kann. Für den Leser ist zu erkennen, dass die in 3C dargestellte Speicher-Controller-Anwendung 324, 326 identischen Quellcode enthalten kann, der in verschiedenen Cloud-Computing-Instanzen 320, 322 ausgeführt wird.
  • In einem Beispiel soll hier die Cloud-Computing-Umgebung 316 als AWS und die Cloud-Computing-Instanzen als EC2-Instanzen verkörpert sein. In einem solchen Beispiel kann die Cloud-Computing-Instanz 320, die als primärer Controller arbeitet, auf einem der Instanztypen eingesetzt werden, der über eine relativ große Menge an Speicher und Verarbeitungsleistung verfügt, während die Cloud-Computing-Instanz 322, die als sekundärer Controller arbeitet, auf einem der Instanztypen eingesetzt werden kann, der über eine relativ kleine Menge an Speicher und Verarbeitungsleistung verfügt. In einem solchen Beispiel kann beim Auftreten eines Failover-Ereignisses, bei dem die Rollen des primären und sekundären Controllers getauscht werden, tatsächlich ein doppeltes Failover durchgeführt werden, so dass: 1. ein erstes Failover-Ereignis, bei dem die Cloud-Computing-Instanz 322, die zuvor als sekundärer Controller betrieben wurde, als primärer Controller zu arbeiten beginnt, und 2) eine dritte Cloud-Computing-Instanz (nicht dargestellt), die von einem Instanztyp ist, der eine relativ große Menge an Speicher und Verarbeitungsleistung hat, mit einer Kopie der Speicher-Controller-Anwendung hochgefahren wird, wobei die dritte Cloud-Computing-Instanz als primärer Controller zu arbeiten beginnt, während die Cloud-Computing-Instanz 322, die ursprünglich als sekundärer Controller betrieben wurde, wieder als sekundärer Controller zu arbeiten beginnt. In einem solchen Beispiel kann die Cloud-Computing-Instanz 320, die zuvor als primärer Controller betrieben wurde, beendet werden. Für den Leser ist zu erkennen, dass in alternativen Ausführungsformen die Cloud-Computing-Instanz 320, die nach dem Failover-Ereignis als sekundärer Controller arbeitet, weiterhin als sekundärer Controller arbeiten kann und die Cloud-Computing-Instanz 322, die nach dem Auftreten des Failover-Ereignisses als primärer Controller arbeitete, beendet werden kann, sobald die primäre Rolle von der dritten Cloud-Computing-Instanz (nicht dargestellt) übernommen wurde.
  • Für den Leser ist zu erkennen, dass sich die vorstehend beschriebenen Ausführungsformen zwar auf Ausführungsformen beziehen, bei denen eine Cloud-Computing-Instanz 320 als primärer Controller und die zweite Cloud-Computing-Instanz 322 als sekundärer Controller arbeitet, dass aber auch andere Ausführungsformen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Beispielsweise kann jede Cloud-Computing-Instanz 320, 322 als primärer Controller für einen Teil des Adressraums arbeiten, der von dem cloudbasierten Speichersystem 318 unterstützt wird, jede Cloud-Computing-Instanz 320, 322 kann als primärer Controller arbeiten, bei dem die Bedienung von E/A-Operationen, die an das cloudbasierte Speichersystem 318 gerichtet sind, auf eine andere Weise aufgeteilt ist, und so weiter. In anderen Ausführungsformen, in denen Kosteneinsparungen Vorrang vor Leistungsanforderungen aufweisen können, kann sogar nur eine einzige Cloud-Computing-Instanz existieren, die die Speicher-Controller-Anwendung enthält.
  • Das in 3C dargestellte cloudbasierte Speichersystem 318 umfasst Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338. Die in 3C dargestellten Cloud-Computing-Instanzen 340a, 340b, 340n können beispielsweise als Instanzen von Cloud-Computing-Ressourcen verkörpert sein, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden können, um das Ausführen von Softwareanwendungen zu unterstützen. Die Cloud-Computing-Instanzen 340a, 340b, 340n der 3C können sich von den vorstehend beschriebenen Cloud-Computing-Instanzen 320, 322 unterscheiden, da die Cloud-Computing-Instanzen 340a, 340b, 340n der 3C über lokale Speicherressourcen 330, 334, 338 verfügen, während die Cloud-Computing-Instanzen 320, 322, die die Ausführung der Speicher-Controller-Anwendung 324, 326 unterstützen, keine lokalen Speicherressourcen aufweisen müssen. Die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 können beispielsweise als EC2 M5-Instanzen, die eine oder mehrere SSDs enthalten, als EC2 R5-Instanzen, die eine oder mehrere SSDs enthalten, als EC2 I3-Instanzen, die eine oder mehrere SSDs enthalten, usw. verkörpert sein. In einigen Ausführungsformen muss der lokale Speicher 330, 334, 338 als Festkörperspeicher (z. B. SSDs) ausgeführt sein und nicht als Speicher, der Festplattenlaufwerke verwendet.
  • In dem in 3C dargestellten Beispiel kann jede der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 einen Software-Daemon 328, 332, 336 enthalten, der, wenn er von einer Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, sich den Speicher-Controller-Anwendungen 324, 326 so präsentieren kann, als wäre die Cloud-Computing-Instanz 340a, 340b, 340n ein physisches Speichergerät (z. B. eine oder mehrere SSDs). In einem solchen Beispiel kann der Software-Daemon 328, 332, 336 Computerprogrammbefehlen enthalten, die denen ähnlich sind, die normalerweise auf einem Speichergerät enthalten wären, so dass die Speicher-Controller-Anwendungen 324, 326 die gleichen Befehle senden und empfangen können, die ein Speicher-Controller an Speichergeräte senden würde. Auf diese Weise können die Speicher-Controller-Anwendungen 324, 326 Code enthalten, der identisch (oder im Wesentlichen identisch) mit dem Code ist, der von den Controllern in den vorstehend beschriebenen Speichersystemen ausgeführt werden würde. In diesen und ähnlichen Ausführungsformen kann die Kommunikation zwischen den Speicher-Controller-Anwendungen 324, 326 und den Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 iSCSI, NVMe over TCP, Messaging, ein benutzerdefiniertes Protokoll oder einen anderen Mechanismus verwenden.
  • In dem in 3C dargestellten Beispiel kann jede der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 auch mit Blockspeicher 342, 344, 346 gekoppelt sein, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird. Der Blockspeicher 342, 344, 346, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird, kann z. B. als Amazon Elastic Block Store („EBS“)-Volume verkörpert werden. Beispielsweise kann ein erstes EBS-Volume mit einer ersten Cloud-Computing-Instanz 340a, ein zweites EBS-Volume mit einer zweiten Cloud-Computing-Instanz 340b und ein drittes EBS-Volume mit einer dritten Cloud-Computing-Instanz 340n gekoppelt sein. In einem solchen Beispiel kann der Blockspeicher 342, 344, 346, der von der Cloud-Computing-Umgebung 316 bereitgestellt wird, in ähnlicher Weise genutzt werden, wie die vorstehend beschriebenen NVRAM-Vorrichtungen genutzt werden, da der Software-Daemon 328, 332 (oder ein anderes Modul), der in einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, beim Empfang einer Anforderung zum Schreiben von Daten ein Schreiben der Daten in sein angeschlossenes EBS-Volume sowie ein Schreiben der Daten in seine lokalen Speicherressourcen 330, 334, 338 initiieren kann. In einigen alternativen Ausführungsformen können Daten nur in die lokalen Speicherressourcen 330, 334, 338 innerhalb einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n geschrieben werden. In einer alternativen Ausführungsform kann statt der Verwendung des Blockspeichers 342, 344, 346, der von der Cloud-Computing-Umgebung 316 als NVRAM bereitgestellt wird, der tatsächliche Arbeitsspeicher auf jeder der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als NVRAM verwendet werden, wodurch die Netzwerknutzungskosten, die mit der Verwendung eines EBS-Volumens als NVRAM verbunden wären, gesenkt werden.
  • In dem in 3C dargestellten Beispiel können die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 von Cloud-Computing-Instanzen 320, 322 verwendet werden, die das Ausführen der Speicher-Controller-Anwendung 324, 326 unterstützen, um E/A-Vorgänge zu bedienen, die an das cloudbasierte Speichersystem 318 gerichtet sind. In einem Beispiel soll hier eine erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, als primärer Controller arbeiten. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, (direkt oder indirekt über den sekundären Controller) Anfragen zum Schreiben von Daten in das cloudbasierte Speichersystem 318 von Benutzern des cloudbasierten Speichersystems 318 erhalten. In einem solchen Beispiel kann die erste Cloud-Computing-Instanz 320, die die Speicher-Controller-Anwendung 324 ausführt, verschiedene Aufgaben durchführen, wie zum Beispiel das Deduplizieren der in der Anforderung enthaltenen Daten, das Komprimieren der in der Anforderung enthaltenen Daten, das Bestimmen, wohin die in der Anforderung enthaltenen Daten geschrieben werden sollen, und so weiter, bevor schließlich eine Anforderung zum Schreiben einer deduplizierten, verschlüsselten oder anderweitig möglicherweise aktualisierten Version der Daten an eine oder mehrere der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 gesendet wird. Jede der Cloud-Computing-Instanzen 320, 322 kann in einigen Ausführungsformen eine Anforderung zum Lesen von Daten aus dem cloudbasierten Speichersystem 318 empfangen und kann schließlich eine Anforderung zum Lesen von Daten an eine oder mehrere der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 senden.
  • Für den Leser ist zu erkennen, dass, wenn eine Anforderung zum Schreiben von Daten von einer bestimmten Cloud-Computing-Instanz 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 empfangen wird, der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, so konfiguriert sein kann, dass er die Daten nicht nur in seinen eigenen lokalen Speicher 330, 334, 338 und jeden geeigneten Blockspeicher 342, 344, 346 zu schreiben, die von der Cloud-Computing-Umgebung 316 bereitgestellt werden, sondern der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, kann auch so konfiguriert sein, dass er die Daten in den cloudbasierten Objektspeicher 348 schreibt, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist. Der cloudbasierte Objektspeicher 348, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist, kann beispielsweise als Amazon Simple Storage Service („S3“) Speicher ausgeführt sein, auf den die bestimmte Cloud-Computing-Instanz 340a, 340b, 340n zugreifen kann. In anderen Ausführungsformen können die Cloud-Computing-Instanzen 320, 322, die jeweils die Speicher-Controller-Anwendung 324, 326 enthalten, die Speicherung der Daten im lokalen Speicher 330, 334, 338 der Cloud-Computing-Instanzen 340a, 340b, 340n und dem cloudbasierten Objektspeicher 348 initiieren.
  • Für den Leser ist zu erkennen, dass, wie vorstehend beschrieben, das cloudbasierte Speichersystem 318 verwendet werden kann, um Blockspeicherdienste für Benutzer des cloudbasierten Speichersystems 318 bereitzustellen. Während die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, den Zugriff auf Blockebene unterstützen können, unterstützt der cloudbasierte Objektspeicher 348, der mit der jeweiligen Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist, nur den objektbasierten Zugriff. Um dies zu beheben, kann der Software-Daemon 328, 332, 336 oder ein anderes Modul mit Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, so konfiguriert sein, dass er Datenblöcke nimmt, diese Blöcke in Objekte verpackt und die Objekte in den cloudbasierten Objektspeicher 348 schreibt, der mit der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n verbunden ist.
  • In einem Beispiel sollen hier Daten in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346 geschrieben werden, die von den Cloud-Computing-Instanzen 340a, 340b, 340n in 1-MB-Blöcken genutzt werden. Beispielsweise soll angenommen werden, dass ein Benutzer des cloudbasierten Speichersystems 318 eine Anfrage zum Schreiben von Daten stellt, die nach der Komprimierung und Deduplizierung durch die Speicher-Controller-Anwendung 324, 326 dazu führen, dass 5 MB an Daten geschrieben werden müssen. In einem solchen Beispiel ist das Schreiben der Daten in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, relativ einfach, da 5 Blöcke mit einer Größe von 1 MB in die Ressourcen des lokalen Speichers 330, 334, 338 und des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, geschrieben werden. In einem solchen Beispiel kann der Software-Daemon 328, 332, 336 oder ein anderes Modul von Computerprogrammbefehlen, das auf der bestimmten Cloud-Computing-Instanz 340a, 340b, 340n ausgeführt wird, konfiguriert sein, um 1. ein erstes Objekt zu erzeugen, das die ersten 1 MB Daten enthält, und das erste Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, 2. ein zweites Objekt zu erzeugen, das die zweiten 1 MB Daten enthält, und das zweite Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, 3. ein drittes Objekt zu erzeugen, das die dritten 1 MB Daten enthält, und das dritte Objekt in den cloudbasierten Objektspeicher 348 zu schreiben, und so weiter. So kann in einigen Ausführungsformen jedes Objekt, das in den cloudbasierten Objektspeicher 348 geschrieben wird, eine identische (oder nahezu identische) Größe aufweisen. Für den Leser ist zu erkennen, dass in einem solchen Beispiel Metadaten, die mit den Daten selbst verbunden sind, in jedem Objekt enthalten sein können (z. B. sind die ersten 1 MB des Objekts Daten und der restliche Teil sind Metadaten, die mit den Daten verbunden sind).
  • Für den Leser ist zu erkennen, dass der cloudbasierte Objektspeicher 348 in das cloudbasierte Speichersystem 318 integriert werden kann, um die Lebensdauerdes cloudbasierten Speichersystems 318 zu erhöhen. Wenn man mit dem vorstehend beschriebenen Beispiel fortfährt, bei dem die Cloud-Computing-Instanzen 340a, 340b, 340n EC2-Instanzen sind, wird der Leser verstehen, dass EC2-Instanzen nur eine monatliche Betriebszeit von 99,9 % garantieren und dass die im lokalen Instanzspeicher gespeicherten Daten nur während der Lebensdauer der EC2-Instanz bestehen bleiben. Wenn man sich also auf die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als einzige Quelle für persistenten Datenspeicher im cloudbasierten Speichersystem 318 verlässt, kann dies zu einem relativ unzuverlässigen Speichersystem führen. Ebenso sind EBS-Volumes für eine Verfügbarkeit von 99,999 % ausgelegt. Daher kann selbst das Verlassen auf EBS als persistenten Datenspeicher im cloudbasierten Speichersystem 318 zu einem Speichersystem führen, das nicht ausreichend langlebig ist. Amazon S3 hingegen ist für eine Lebensdauervon 99,999999999 % ausgelegt, was bedeutet, dass ein cloudbasiertes Speichersystem 318, das S3 in seinen Speicherpool einbinden kann, wesentlich langlebiger ist als verschiedene andere Optionen.
  • Für den Leser ist zu erkennen, dass ein cloudbasiertes Speichersystem 318, das S3 in seinen Speicherpool einbinden kann, zwar wesentlich langlebiger ist als verschiedene andere Optionen, dass aber die Verwendung von S3 als primärer Speicherpool zu einem Speichersystem führen kann, das relativ langsame Reaktionszeiten und relativ lange E/A-Latenzen aufweist. So speichert das in 3C dargestellte cloudbasierte Speichersystem 318 nicht nur Daten in S3, sondern das cloudbasierte Speichersystem 318 speichert auch Daten in lokalen Speicherressourcen 330, 334, 338 und Blockspeicherressourcen 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, so dass Leseoperationen von den Ressourcen des lokalen Speichers 330, 334, 338 und den Ressourcen des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, bedient werden können, wodurch die Leselatenz reduziert wird, wenn Benutzer des cloudbasierten Speichersystems 318 versuchen, Daten aus dem cloudbasierten Speichersystem 318 zu lesen.
  • In einigen Ausführungsformen können alle Daten, die vom cloudbasierten Speichersystem 318 gespeichert werden, sowohl 1. im cloudbasierten Objektspeicher 348 als auch 2. in mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, gespeichert werden. In solchen Ausführungsformen können die lokalen Speicherressourcen 330, 334, 338 und die Blockspeicherressourcen 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n genutzt werden, effektiv als Cache arbeiten, der im Allgemeinen alle Daten enthält, die auch in S3 gespeichert sind, so dass alle Lesevorgänge von Daten durch die Cloud-Computing-Instanzen 340a, 340b, 340n bedient werden können, ohne dass die Cloud-Computing-Instanzen 340a, 340b, 340n auf den cloudbasierten Objektspeicher 348 zugreifen müssen. Für den Leser ist zu erkennen, dass in anderen Ausführungsformen jedoch alle Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, in dem cloudbasierten Objektspeicher 348 gespeichert werden können, aber weniger als alle Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, in mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346 gespeichert werden können, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden. In einem solchen Beispiel können verschiedene Richtlinien verwendet werden, um zu bestimmen, welche Teilmenge der Daten, die von dem cloudbasierten Speichersystem 318 gespeichert werden, sich sowohl in 1. dem cloudbasierten Objektspeicher 348 als auch in 2. mindestens einer der Ressourcen des lokalen Speichers 330, 334, 338 oder des Blockspeichers 342, 344, 346, die von den Cloud-Computing-Instanzen 340a, 340b, 340n verwendet werden, befinden sollte.
  • Wie vorstehend beschrieben, wenn die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 als EC2-Instanzen ausgeführt werden, wird für die Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 nur eine monatliche Betriebszeit von 99,9 % garantiert, und die im lokalen Instanzspeicher gespeicherten Daten bleiben nur während der Lebensdauer jeder Cloud-Computing-Instanz 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 erhalten. Als solches können ein oder mehrere Module von Computerprogrammbefehlen, die innerhalb des cloudbasierten Speichersystems 318 ausgeführt werden (z. B. ein Überwachungsmodul, das auf seiner eigenen EC2-Instanz ausgeführt wird), dafür ausgelegt sein, den Ausfall einer oder mehrerer der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 zu handhaben. In einem solchen Beispiel kann das Überwachungsmodul den Ausfall einer oder mehrerer der Cloud-Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 handhaben, indem es eine oder mehrere neue Cloud-Computing-Instanzen mit lokalem Speicher erstellt, Daten, die auf den ausgefallenen Cloud-Computing-Instanzen 340a, 340b, 340n gespeichert waren, aus dem cloudbasierten Objektspeicher 348 abruft und die aus dem cloudbasierten Objektspeicher 348 abgerufenen Daten im lokalen Speicher der neu erstellten Cloud-Computing-Instanzen speichert. Für den Leser ist zu erkennen, dass viele Varianten dieses Prozesses implementiert werden können.
  • In einem Beispiel sollen hier alle Cloud Computing-Instanzen 340a, 340b, 340n mit lokalem Speicher 330, 334, 338 ausgefallen sein. In einem solchen Beispiel kann das Überwachungsmodul neue Cloud-Computing-Instanzen mit lokalem Speicher erstellen, wobei Instanztypen mit hoher Bandbreite ausgewählt werden, die die maximalen Datenübertragungsraten zwischen den neu erstellten Cloud-Computing-Instanzen mit hoher Bandbreite und lokalem Speicher und dem cloudbasierten Objektspeicher 348 ermöglichen. Für den Leser ist zu erkennen, dass Instanztypen ausgewählt werden, die die maximalen Datenübertragungsraten zwischen den neuen Cloud-Computing-Instanzen und dem cloudbasierten Objektspeicher 348 ermöglichen, so dass die neuen Cloud-Computing-Instanzen mit hoher Bandbreite so schnell wie möglich mit Daten aus dem cloudbasierten Objektspeicher 348 rehydriert werden können. Sobald die neuen Cloud-Computing-Instanzen mit hoher Bandbreite mit Daten aus dem cloudbasierten Objektspeicher 348 rehydriert sind, können kostengünstigere Cloud-Computing-Instanzen mit geringerer Bandbreite erstellt werden, Daten können zu den kostengünstigeren Cloud-Computing-Instanzen mit geringerer Bandbreite migriert werden, und die Cloud-Computing-Instanzen mit hoher Bandbreite können beendet werden.
  • Für den Leser ist zu erkennen, dass in einigen Ausführungsformen die Anzahl der neuen Cloud-Computing-Instanzen, die erstellt werden, die Anzahl der Cloud-Computing-Instanzen, die benötigt werden, um alle vom cloudbasierten Speichersystem 318 gespeicherten Daten lokal zu speichern, wesentlich übersteigen kann. Die Anzahl der neuen Cloud-Computing-Instanzen, die erstellt werden, kann die Anzahl der Cloud-Computing-Instanzen, die benötigt werden, um alle vom cloudbasierten Speichersystem 318 gespeicherten Daten lokal zu speichern, wesentlich übersteigen, um Daten schneller aus dem cloudbasierten Objektspeicher 348 und in die neuen Cloud-Computing-Instanzen zu ziehen, da jede neue Cloud-Computing-Instanz (parallel) einen Teil der vom cloudbasierten Speichersystem 318 gespeicherten Daten abrufen kann. In solchen Ausführungsformen können die Daten, sobald sie vom cloudbasierten Speichersystem 318 in die neu erstellten Cloud-Computing-Instanzen gezogen wurden, in einer Teilmenge der neu erstellten Cloud-Computing-Instanzen konsolidiert werden, und die neu erstellten Cloud-Computing-Instanzen, die überzählig sind, können beendet werden.
  • In einem Beispiel soll angenommen werden, dass hier 1.000 Cloud-Computing-Instanzen benötigt werden, um alle gültigen Daten lokal zu speichern, die Benutzer des cloudbasierten Speichersystems 318 in das cloudbasierte Speichersystem 318 geschrieben haben. In einem solchen Beispiel soll angenommen werden, dass alle 1.000 Cloud-Computing-Instanzen ausfallen. In einem solchen Beispiel kann das Überwachungsmodul veranlassen, dass 100.000 Cloud-Computing-Instanzen erstellt werden, wobei jede Cloud-Computing-Instanz dafür verantwortlich ist, aus dem cloudbasierten Objektspeicher 348 eindeutige 1/100.000ste Teile der gültigen Daten abzurufen, die Benutzer des cloudbasierten Speichersystems 318 in das cloudbasierte Speichersystem 318 geschrieben haben, und den eindeutigen Teil des Datensatzes, den sie abgerufen hat, lokal zu speichern. Da in einem solchen Beispiel jede der 100.000 Cloud-Computing-Instanzen parallel Daten aus dem cloudbasierten Objektspeicher 348 abrufen kann, kann die Caching-Schicht im Vergleich zu einer Ausführungsform, bei der das Überwachungsmodul nur 1000 Ersatz-Cloud-Computing-Instanzen erstellt, 100-mal schneller wiederhergestellt werden. In einem solchen Beispiel könnten im Laufe der Zeit die Daten, die lokal in den 100.000 Cloud-Computing-Instanzen gespeichert sind, in 1.000 Cloud-Computing-Instanzen konsolidiert werden und die verbleibenden 99.000 Cloud-Computing-Instanzen könnten beendet werden.
  • Für den Leser ist zu erkennen, dass verschiedene Leistungsaspekte des cloudbasierten Speichersystems 318 überwacht werden können (z. B. durch ein Überwachungsmodul, das in einer EC2-Instanz ausgeführt wird), sodass das cloudbasierte Speichersystem 318 je nach Bedarf herauf- oder herabskaliert werden kann. In einem Beispiel soll angenommen werden, dass das Überwachungsmodul die Leistung des cloudbasierten Speichersystems 318 über die Kommunikation mit einer oder mehreren der Cloud-Computing-Instanzen 320, 322 überwacht, die jeweils verwendet werden, um die Ausführung einer Speicher-Controller-Anwendung 324, 326 zu unterstützen, über die Überwachung der Kommunikation zwischen den Cloud-Computing-Instanzen 320, 322, 340a, 340b, 340n, über die Überwachung der Kommunikation zwischen den Cloud-Computing-Instanzen 320, 322, 340a, 340b, 340n und dem cloudbasierten Objektspeicher 348 oder auf eine andere Weise. Nehmen wir in einem solchen Beispiel an, dass das Überwachungsmodul feststellt, dass die Cloud-Computing-Instanzen 320, 322, die verwendet werden, um die Ausführung einer Speicher-Controller-Anwendung 324, 326 zu unterstützen, unterdimensioniert sind und die E/A-Anforderungen, die von Benutzern des cloudbasierten Speichersystems 318 ausgegeben werden, nicht ausreichend bedienen. In einem solchen Beispiel kann das Überwachungsmodul eine neue, leistungsfähigere Cloud-Computing-Instanz erstellen (z. B. eine Cloud-Computing-Instanz eines Typs, der mehr Verarbeitungsleistung, mehr Speicher usw. umfasst), die die Speicher-Controller-Anwendung enthält, so dass die neue, leistungsfähigere Cloud-Computing-Instanz den Betrieb als primärer Controller aufnehmen kann. Ebenso kann das Überwachungsmodul, wenn es feststellt, dass die Cloud-Computing-Instanzen 320, 322, die zur Unterstützung der Ausführung einer Speicher-Controller-Anwendung 324, 326 verwendet werden, überdimensioniert sind und dass Kosteneinsparungen durch den Wechsel zu einer kleineren, weniger leistungsfähigen Cloud-Computing-Instanz erzielt werden können, eine neue, weniger leistungsfähige (und kostengünstigere) Cloud-Computing-Instanz erstellen, die die Speicher-Controller-Anwendung enthält, sodass die neue, weniger leistungsfähige Cloud-Computing-Instanz als primärer Controller in Betrieb genommen werden kann.
  • In einem weiteren Beispiel für die dynamische Größenbestimmung des cloudbasierten Speichersystems 318 soll angenommen werden, dass das Überwachungsmodul feststellt, dass die Auslastung des lokalen Speichers, der gemeinsam von den Cloud-Computing-Instanzen 340a, 340b, 340n bereitgestellt wird, einen vorgegebenen Auslastungsschwellenwert (z. B. 95 %) erreicht hat. In einem solchen Beispiel kann das Überwachungsmodul zusätzliche Cloud Computing-Instanzen mit lokalem Speicher erstellen, um den Pool an lokalem Speicher zu erweitern, der von den Cloud-Computing-Instanzen bereitgestellt wird. Alternativ kann das Überwachungsmodul eine oder mehrere neue Cloud-Computing-Instanzen erstellen, die über größere Mengen an lokalem Speicher verfügen als die bereits vorhandenen Cloud-Computing-Instanzen 340a, 340b, 340n, so dass Daten, die in einer bereits vorhandenen Cloud-Computing-Instanz 340a, 340b, 340n gespeichert sind, in die eine oder mehrere neue Cloud-Computing-Instanzen migriert werden können und die bereits vorhandene Cloud-Computing-Instanz 340a, 340b, 340n beendet werden kann, wodurch der Pool an lokalem Speicher, der von den Cloud-Computing-Instanzen bereitgestellt wird, erweitert wird. Ebenso können, wenn der Pool an lokalem Speicher, der von den Cloud-Computing-Instanzen bereitgestellt wird, unnötig groß ist, Daten konsolidiert und einige Cloud-Computing-Instanzen beendet werden.
  • Für den Leser ist zu erkennen, dass das cloudbasierte Speichersystem 318 durch ein Überwachungsmodul, das einen vorbestimmten Satz von Regeln anwendet, die relativ einfach oder relativ kompliziert sein können, automatisch hoch- und runtergefahren werden kann. Tatsächlich kann das Überwachungsmodul nicht nur den aktuellen Zustand des cloudbasierten Speichersystems 318 berücksichtigen, sondern das Überwachungsmodul kann auch prädiktive Richtlinien anwenden, die z. B. auf beobachtetem Verhalten (z. B. jede Nacht von 22 Uhr bis 6 Uhr morgens ist die Nutzung des Speichersystems relativ gering), vorbestimmten Fingerprints (z. B. jedes Mal, wenn eine virtuelle Desktop-Infrastruktur 100 virtuelle Desktops hinzufügt, erhöht sich die Anzahl der an das Speichersystem gerichteten IOPS um X) und so weiter basieren. In einem solchen Beispiel kann die dynamische Skalierung des cloudbasierten Speichersystems 318 auf aktuellen Leistungsmetriken, vorhergesagten Arbeitslasten und vielen anderen Faktoren, einschließlich Kombinationen davon, basieren.
  • Für den Leser ist ferner zu erkennen, dass das cloudbasierte Speichersystem 318 sogar dynamisch skaliert werden kann, weil das cloudbasierte Speichersystem 318 auf eine Weise arbeitet, die dynamischer ist. In einem Beispiel soll die Garbage Collection betrachtet werden. In einem herkömmlichen Speichersystem ist die Menge des Speichers festgelegt. Daher kann das Speichersystem an einem bestimmten Punkt gezwungen sein, eine Garbage Collection durchzuführen, da die Menge des verfügbaren Speichers so begrenzt ist, dass das Speichersystem kurz davor steht, keinen Speicher mehr zu haben. Im Gegensatz dazu kann das hier beschriebene cloudbasierte Speichersystem 318 jederzeit zusätzlichen Speicher „hinzufügen“ (z. B. durch Hinzufügen weiterer Cloud-Computing-Instanzen mit lokalem Speicher). Da das hier beschriebene cloudbasierte Speichersystem 318 immer zusätzlichen Speicher „hinzufügen“ kann, kann das cloudbasierte Speichersystem 318 intelligentere Entscheidungen darüber treffen, wann eine Garbage Collection durchgeführt werden soll. Beispielsweise kann das cloudbasierte Speichersystem 318 eine Richtlinie implementieren, die besagt, dass die Garbage Collection nur dann durchgeführt wird, wenn die Anzahl der IOPS, die vom cloudbasierten Speichersystem 318 bedient werden, unter ein bestimmtes Niveau fällt. In einigen Ausführungsformen können auch andere Funktionen auf Systemebene (z. B. Deduplizierung, Komprimierung) als Reaktion auf die Systemlast ein- und ausgeschaltet werden, da die Größe des cloudbasierten Speichersystems 318 nicht auf die gleiche Weise eingeschränkt ist wie bei herkömmlichen Speichersystemen.
  • Leser werden verstehen, dass Ausführungsformen der vorliegenden Offenbarung ein Problem mit Blockspeicherdiensten lösen, die von einigen Cloud-Computing-Umgebungen bereitgestellt werden, da einige Cloud-Computing-Umgebungen nur eine Cloud-Computing-Instanz zulassen, die sich mit einem Blockspeicher-Volume zu einem einzigen Zeitpunkt verbindet. In Amazon AWS kann zum Beispiel nur eine einzige EC2-Instanz mit einem EBS-Volume verbunden werden. Durch die Verwendung von EC2-Instanzen mit lokalem Speicher können Ausführungsformen der vorliegenden Offenbarung Multi-Connect-Funktionen bieten, bei denen sich mehrere EC2-Instanzen mit einer anderen EC2-Instanz mit lokalem Speicher („eine Laufwerksinstanz“) verbinden können. In solchen Ausführungsformen können die Laufwerksinstanzen Software enthalten, die innerhalb der Laufwerksinstanz ausgeführt wird und es der Laufwerksinstanz ermöglicht, E/A zu unterstützen, die von jeder verbundenen EC2-Instanz an ein bestimmtes Volume gerichtet ist. Als solche können einige Ausführungsformen der vorliegenden Offenbarung als Multi-Connect-Blockspeicherdienste ausgeführt werden, die möglicherweise nicht alle in 3C dargestellten Komponenten enthalten.
  • In einigen Ausführungsformen, insbesondere in Ausführungsformen, in denen die Ressourcen des cloudbasierten Objektspeichers 348 als Amazon S3 verkörpert sind, kann das cloudbasierte Speichersystem 318 ein oder mehrere Module (z. B. ein Modul mit Computerprogrammbefehlen, die auf einer EC2-Instanz ausgeführt werden) enthalten, die so konfiguriert sind, dass sie sicherstellen, dass, wenn der lokale Speicher einer bestimmten Cloud-Computing-Instanz mit Daten aus S3 rehydriert wird, die entsprechenden Daten tatsächlich in S3 vorhanden sind. Dieses Problem tritt hauptsächlich deshalb auf, weil S3 ein Modell für Eventual Consistency implementiert, bei dem beim Überschreiben eines vorhandenen Objekts die Lesevorgänge des Objekts schließlich (aber nicht unbedingt sofort) konsistent werden und schließlich (aber nicht unbedingt sofort) die überschriebene Version des Objekts zurückgeben. Um dieses Problem zu lösen, werden in einigen Ausführungsformen der vorliegenden Offenbarung Objekte in S3 niemals überschrieben. Stattdessen würde ein herkömmliches „Überschreiben“ zur Erstellung des neuen Objekts (das die aktualisierte Version der Daten enthält) und zur eventuellen Löschung des alten Objekts (das die vorherige Version der Daten enthält) führen.
  • In einigen Ausführungsformen der vorliegenden Offenbarung kann als Teil eines Versuchs, ein Objekt nie (oder fast nie) zu überschreiben, das resultierende Objekt mit einer Sequenznummer versehen werden, wenn Daten in S3 geschrieben werden. In einigen Ausführungsformen können diese Sequenznummern an anderer Stelle (z. B. in einer Datenbank) aufbewahrt werden, so dass zu jedem Zeitpunkt die Sequenznummer bekannt ist, die mit der aktuellsten Version eines Teils der Daten verbunden ist. Auf diese Weise kann festgestellt werden, ob S3 über die aktuellste Version eines Teils der Daten verfügt, indem lediglich die mit einem Objekt verknüpfte Sequenznummer gelesen wird - ohne die Daten tatsächlich aus S3 zu lesen. Die Fähigkeit, diese Bestimmung vorzunehmen, kann besonders wichtig sein, wenn eine Cloud-Computing-Instanz mit lokalem Speicher abstürzt, da es unerwünscht wäre, den lokalen Speicher einer Ersatz-Cloud-Computing-Instanz mit veralteten Daten zu rehydrieren. Da das cloudbasierte Speichersystem 318 nicht auf die Daten zugreifen muss, um ihre Gültigkeit zu überprüfen, können die Daten verschlüsselt bleiben und Zugriffsgebühren vermieden werden.
  • Die vorstehend beschriebenen Speichersysteme können intelligente Datensicherungsverfahren ausführen, durch die im Speichersystem gespeicherte Daten kopiert und an einem anderen Ort gespeichert werden können, um einen Datenverlust im Falle eines Geräteausfalls oder einer anderen Form von Notfall zu vermeiden. Beispielsweise können die vorstehend beschriebenen Speichersysteme so konfiguriert sein, dass sie jede Datensicherung überprüfen, um zu vermeiden, dass das Speichersystem in einen unerwünschten Zustand zurückversetzt wird. In einem Beispiel soll hier Malware das Speichersystem infizieren. In einem solchen Beispiel kann das Speichersystem Softwareressourcen 314 enthalten, die jedes Backup prüfen können, um Backups zu identifizieren, die vor der Infektion des Speichersystems durch die Malware erfasst wurden, und solche, die nach der Infektion des Speichersystems durch die Malware erfasst wurden. In einem solchen Beispiel kann das Speichersystem sich selbst aus einem Backup wiederherstellen, das die Malware nicht enthält - oder zumindest nicht die Teile eines Backups wiederherstellen, die die Malware enthielten. In einem solchen Beispiel kann das Speichersystem Softwareressourcen 314 enthalten, die jedes Backup scannen können, um das Vorhandensein von Malware (oder eines Virus oder eines anderen unerwünschten Mittels) zu identifizieren, z. B. durch Identifizieren von Schreiboperationen, die vom Speichersystem bedient wurden und aus einem Netzwerk-Subnetz stammen, von dem vermutet wird, dass es die Malware bereitgestellt hat, durch Identifizieren von Schreiboperationen, die vom Speichersystem bedient wurden und von einem Benutzer stammen, der im Verdacht steht, die Malware bereitgestellt zu haben, durch Identifizieren von Schreiboperationen, die vom Speichersystem bedient wurden und Untersuchen des Inhalts der Schreiboperation anhand von Fingerprints der Malware, und auf viele andere Arten.
  • Für den Leser ist ferner zu erkennen, dass die Backups (oft in Form eines oder mehrerer Snapshots) auch für eine schnelle Wiederherstellung des Speichersystems verwendet werden können. In einem Beispiel soll hier das Speichersystem mit Ransomware infiziert sein, die Benutzer aus dem Speichersystem aussperrt. In einem solchen Beispiel können die Softwareressourcen 314 innerhalb des Speichersystems so konfiguriert sein, dass sie das Vorhandensein von Ransomware erkennen und das Speichersystem unter Verwendung der zurückgehaltenen Backups zu einem Zeitpunkt wiederherstellen, der vor dem Zeitpunkt liegt, an dem die Ransomware das Speichersystem infiziert hat. In einem solchen Beispiel kann das Vorhandensein von Ransomware explizit durch die Verwendung von Softwaretools, die von dem System verwendet werden, durch die Verwendung eines Schlüssels (z. B. eines USB-Laufwerks), der in das Speichersystem eingesteckt wird, oder auf ähnliche Weise erkannt werden. Ebenso kann auf das Vorhandensein von Ransomware geschlossen werden, wenn die Systemaktivität einem vorbestimmten Fingerprint entspricht, z. B. wenn über einen vorbestimmten Zeitraum keine Lese- oder Schreibzugriffe auf das System erfolgen.
  • Für den Leser ist zu erkennen, dass die verschiedenen vorstehend beschriebenen Komponenten in 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 mithilfe von richtliniengesteuerten Prozessen kollektiv verwaltet werden können. Solche konvergierten Infrastrukturen können mit einer konvergierten Infrastruktur-Referenzarchitektur, mit Standalone-Appliances, mit einem softwaregesteuerten hyperkonvergenten Ansatz (z. B. hyperkonvergente Infrastrukturen) oder auf andere Weise implementiert werden.
  • Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme für die Unterstützung verschiedener Arten von Softwareanwendungen nützlich sein können. Beispielsweise kann das Speichersystem 306 nützlich sein bei der Unterstützung von Anwendungen der künstlichen Intelligenz („AI“), Datenbankanwendungen, DevOps-Projekten, Electronic Design Automation Tools, Anwendungen für ereignisgesteuerte Software, Anwendungen für Hochleistungsrechner, Simulationsanwendungen, Anwendungen für die Hochgeschwindigkeitsdatenerfassung und -analyse, Anwendungen für maschinelles Lernen, Anwendungen für die Medienproduktion, Anwendungen für die Medienbereitstellung, Anwendungen für Bildarchivierungs- und Kommunikationssysteme („PACS“), Anwendungen für die Softwareentwicklung, Virtual-Reality-Anwendungen, Augmented-Reality-Anwendungen und vielen anderen Arten von Anwendungen, indem es solchen Anwendungen Speicherressourcen zur Verfügung stellt.
  • 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 Anwendungen zu unterstützen, die ressourcenintensiv sind, wie z. B. Kl-Anwendungen. Kl-Anwendungen können in einer Vielzahl von Bereichen eingesetzt werden, z. B.: prädikitve Wartung in der Fertigung und verwandten Bereichen, Anwendungen im Gesundheitswesen wie Patientendaten- und Risikoanalysen, Einzelhandels- und Marketinganwendungen (z. B. Suchwerbung, Social-Media-Werbung), Lösungen für Lieferketten, Fintech-Lösungen wie Business Analytics & Reporting-Tools, betriebliche Anwendungen wie Echtzeit-Analyse-Tools, Application Performance Management-Tools, IT-Infrastruktur-Management-Tools und viele andere.
  • Solche Kl-Anwendungen können Geräte in die Lage versetzen, ihre Umgebung wahrzunehmen und Aktionen auszuführen, die ihre Erfolgschancen bei einem bestimmten 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 von Analysemodellen zu automatisieren. Durch die Verwendung von Algorithmen, die iterativ aus Daten lernen, können Anwendungen für maschinelles Lernen Computern ermöglichen, zu lernen, ohne explizit programmiert zu werden. Ein spezieller Bereich des maschinellen Lernens wird als „Reinforcement Learning“ bezeichnet, bei dem geeignete Maßnahmen ergriffen werden, um die Belohnung in einer bestimmten Situation zu maximieren. Reinforcement Learning kann eingesetzt werden, um das bestmögliche Verhalten oder den besten Weg zu finden, den eine bestimmte Softwareanwendung oder Maschine in einer bestimmten Situation einschlagen sollte. Reinforcement Learning unterscheidet sich von anderen Bereichen des maschinellen Lernens (z. B. überwachtes Lernen, nicht überwachtes Lernen) dadurch, dass für Reinforcement Learning keine korrekten Eingabe/Ausgabe-Paare präsentiert werden müssen und suboptimale Aktionen nicht explizit korrigiert werden müssen.
  • Zusätzlich zu den bereits beschriebenen Ressourcen können die vorstehend beschriebenen Speichersysteme auch Grafikverarbeitungseinheiten („GPUs“) enthalten, die gelegentlich auch als Visual Processing Unit („VPUs“) bezeichnet werden. Solche GPUs können als spezialisierte elektronische Schaltungen verkörpert sein, die den Speicher schnell manipulieren und verändern, um das Erzeugen von Bildern in einem Bildspeicher zu beschleunigen, der für die Ausgabe an einem Anzeigegerät vorgesehen ist. Solche GPUs können in jedem der Datenverarbeitungsgeräte enthalten sein, die Teil der vorstehend beschriebenen Speichersysteme sind, auch 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 den GPUs können die vorstehend beschriebenen Speichersysteme auch neuronale Netzwerkprozessoren („NNPs“) zur Verwendung in verschiedenen Aspekten der Verarbeitung neuronaler Netzwerke enthalten. 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 für maschinelles Lernen, Big-Data-Analyseanwendungen und viele andere Arten von Anwendungen unterstützen. Das schnelle Wachstum dieser Art von Anwendungen wird von drei Technologien angetrieben: Deep Learning (DL), GPU-Prozessoren und Big Data. Deep Learning ist ein Computermodell, das in hohem Maße parallele neuronale Netzwerke nutzt, die vom menschlichen Gehirn inspiriert sind. Anstatt dass Experten die Software von Hand schreiben, schreibt ein Deep Learning-Modell seine eigene Software, indem es aus vielen Beispielen lernt. Solche GPUs können Tausende von Kernen enthalten, die gut geeignet sind, um Algorithmen auszuführen, die in etwa die parallele Natur des menschlichen Gehirns repräsentieren.
  • Fortschritte bei Deep Neural Networks haben eine neue Welle von Algorithmen und Tools für Datenwissenschaftler ausgelöst, um ihre Daten mit künstlicher Intelligenz (KI) zu erschließen. Mit verbesserten Algorithmen, größeren Datensätzen und verschiedenen Frameworks (einschließlich Open-Source-Softwarebibliotheken für maschinelles Lernen in einer Reihe von Aufgaben) befassen sich Datenwissenschaftler mit neuen Anwendungsfällen, wie z. B. autonom fahrende Fahrzeuge, Verarbeitung und Verständnis natürlicher Sprache, Computer Vision, Machine Reasoning, Strong KI und viele andere. Zu den Anwendungen solcher Techniken gehören: Erkennen, Ermitteln und Vermeiden von Maschinen und Fahrzeug-Objekten; visuelles Erkennen, Klassifizieren und Markieren; algorithmisches Performance-Management für Finanzhandelsstrategien; gleichzeitiges Lokalisieren und Kartieren; vorausschauende Wartung hochwertiger Maschinen; Vorbeugung gegen Cyber-Sicherheitsbedrohungen, Automatisierung von Expertenwissen; Bilderkennung und -klassifizierung; Beantwortung von Fragen; Robotik; Textanalyse (Extraktion, Klassifizierung) und Texterzeugung und -übersetzung; und viele andere. Anwendungen von KI-Techniken sind in einer Vielzahl von Produkten zu finden, z. B. in der Spracherkennungstechnologie von Amazon Echo, die es Benutzern ermöglicht, mit ihren Maschinen zu sprechen, in Google Translate™, das eine maschinenbasierte Sprachübersetzung ermöglicht, in Spotifys „Discover Weekly“, das Empfehlungen zu neuen Songs und Künstlern gibt, die einem Benutzer auf der Grundlage seiner Nutzungs- und Traffic-Analyse gefallen könnten, Quills Angebot zur Texterstellung, das strukturierte Daten in erzählende Geschichten verwandelt, Chatbots, die in Echtzeit kontextspezifische Antworten auf Fragen in einem Dialogformat geben, und in vielen anderen.
  • 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. Bei einer umfassenden Kl-Implementierung müssen unter Umständen kontinuierlich große Datenmengen gesammelt, bereinigt, transformiert, gekennzeichnet und gespeichert werden. Das Hinzufügen zusätzlicher qualitativ hochwertiger Datenpunkte führt direkt zu genaueren Modellen und besseren Erkenntnissen. Datenproben können eine Reihe von Verarbeitungsschritten durchlaufen, einschließlich, aber nicht beschränkt auf: 1. Einlesen der Daten aus einer externen Quelle in das Trainingssystem und Speichern der Daten in Rohform, 2. Bereinigung und Umwandlung der Daten in ein für das Training geeignetes Format, einschließlich der Verknüpfung von Beispieldaten mit dem entsprechenden Label, 3. Untersuchung von Parametern und Modellen, schnelles Testen mit einem kleineren Datensatz und Iteration, um zu den vielversprechendsten Modellen zu konvergieren, die in den Produktionscluster übertragen werden, 4. Ausführung von Trainingsphasen zur Auswahl zufälliger Stapel von Eingabedaten, einschließlich neuer und älterer Beispieldaten, und Einspeisung dieser Daten in GPU-Server für Berechnungen, um Modellparameter zu aktualisieren, und 5. Evaluierung, einschließlich der Verwendung eines zurückgehaltenen Teils der Daten, die nicht im Training verwendet wurden, um die Modellgenauigkeit auf den zurückgehaltenen Daten zu evaluieren. Dieser Lebenszyklus kann für jede Art des parallelisierten maschinellen Lernens gelten, nicht nur für neuronale Netzwerke oder Deep Learning. Beispielsweise können Standard-Frameworks für maschinelles Lernen auf CPUs statt auf GPUs basieren, aber die Arbeitsabläufe für das Einlesen der Daten und das Training können die gleichen sein. Für den Leser ist zu erkennen, dass ein einziger Datenhub mit gemeinsamem Speicher einen Koordinationspunkt während des gesamten Lebenszyklus schafft, ohne dass zusätzliche Datenkopien zwischen den Aufnahme-, Vorverarbeitungs- und Trainingsphasen erforderlich sind. Selten werden die eingelesenen Daten nur für einen Zweck verwendet, und der gemeinsame Speicher bietet die Flexibilität, mehrere verschiedene Modelle zu trainieren oder herkömmliche Analyseverfahren auf die Daten anzuwenden.
  • Die Leser werden verstehen, dass jede Phase in der Kl-Datenpipeline unterschiedliche Anforderungen an den Daten-Hub (z. B. das Speichersystem oder die Sammlung von Speichersystemen) stellen kann. Scale-out-Speichersysteme müssen kompromisslose Leistung für alle Arten von Zugriffsarten und -mustern bereitstellen - 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 Workloads unterstützen können. In der ersten Phase werden die Daten idealerweise in denselben Daten-Hub eingespeist und gespeichert, den auch die nachfolgenden Phasen nutzen werden, um übermäßiges Kopieren von Daten zu vermeiden. Die nächsten beiden Schritte können auf einem Standard-Compute-Server durchgeführt werden, der optional einen Grafikprozessor enthält, und in der vierten und letzten Phase werden dann vollständige Trainings-Produktionsaufträge auf leistungsstarken, GPU-beschleunigten Servern ausgeführt. Oft 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 zusammengeschlossen werden, um ein größeres Modell zu trainieren, sogar über mehrere Systeme hinweg für verteiltes Training. 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. Der ideale Daten-Hub für die KI-Trainings-Pipeline bietet eine ähnliche Leistung wie lokal auf dem Server-Knoten gespeicherte Daten und ist gleichzeitig so einfach und leistungsstark, dass alle Pipeline-Phasen gleichzeitig ablaufen können.
  • Obwohl in den vorangegangenen Abschnitten Deep-Learning-Anwendungen diskutiert wurden, wird der Leser verstehen, dass die hier beschriebenen Speichersysteme auch Teil einer Deep-Learning-Plattform („DDL“) sein können, um die Ausführung von DDL-Algorithmen zu unterstützen. Die vorstehend beschriebenen Speichersysteme können auch mit anderen Technologien gepaart werden, wie z. B. TensorFlow, einer Open-Source-Softwarebibliothek für die Datenflussprogrammierung für eine Reihe von Aufgaben, die für Anwendungen des maschinellen Lernens, wie z. B. neuronale Netze, verwendet werden können, um die Entwicklung solcher Modelle, Anwendungen usw. für maschinelles Lernen zu erleichtern.
  • Die vorstehend beschriebenen Speichersysteme können auch in einer neuromorphen Computing-Umgebung verwendet werden. Neuromorphes Rechnen ist eine Form des Rechnens, die Gehirnzellen nachahmt. Zur Unterstützung des neuromorphen Rechnens ersetzt eine Architektur aus miteinander verbundenen „Neuronen“ herkömmliche Rechenmodelle durch Signale mit geringer Leistung, die direkt zwischen den Neuronen übertragen werden, um eine effizientere Berechnung zu ermöglichen. Neuromorphes Rechnen kann von VLSI-Systemen (Very Large Scale Integration) Gebrauch machen, die elektronische Analogschaltungen enthalten, um die neurobiologischen Architekturen des Nervensystems zu imitieren, sowie von analogen, digitalen, gemischt analog/digitalen VLSI- und Softwaresystemen, die Modelle neuronaler Systeme für die Wahrnehmung, motorische Steuerung oder multisensorische Integration implementieren.
  • Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme so konfiguriert sein können, dass sie die Speicherung oder Verwendung von (neben anderen Arten von Daten) Blockchains unterstützen. Neben der Unterstützung der Speicherung und Verwendung von Blockchain-Technologien können die vorstehend beschriebenen Speichersysteme auch die Speicherung und Verwendung von abgeleiteten Elementen unterstützen, wie z. B. Open-Source-Blockchains und zugehörige Tools, die Teil des IBM™-Hyperledger-Projekts sind, genehmigte Blockchains, bei denen eine bestimmte Anzahl von vertrauenswürdigen Parteien auf die Blockchain zugreifen darf, Blockchain-Produkte, die es Entwicklern ermöglichen, ihre eigenen Distributed-Ledger-Projekte aufzubauen, und andere. Blockchains und die hier beschriebenen Speichersysteme können genutzt werden, um sowohl die On-Chain-Speicherung von Daten als auch die Off-Chain-Speicherung von Daten zu unterstützen.
  • Die Off-Chain-Speicherung von Daten kann auf verschiedene Weise implementiert werden und kann auftreten, wenn die Daten selbst nicht innerhalb der Blockchain gespeichert werden. Zum Beispiel kann in einer Ausführungsform eine Hash-Funktion verwendet werden und die Daten selbst können in die Hash-Funktion eingespeist werden, um einen Hash-Wert zu erzeugen. In einem solchen Beispiel können die Hashes großer Datenstücke in Transaktionen eingebettet werden, anstatt der Daten selbst. Für den Leser ist zu erkennen, dass in anderen Ausführungsformen Alternativen zu Blockchains verwendet werden können, um die dezentrale Speicherung von Informationen zu erleichtern. Eine Alternative zu einer Blockchain, die verwendet werden kann, ist zum Beispiel eine Blockweave. Während herkömmliche Blockchains jede Transaktion speichern, um eine Validierung zu erreichen, erlaubt ein Blockweave eine sichere Dezentralisierung ohne die Verwendung der gesamten Kette und ermöglicht so eine kostengünstige On-Chain-Speicherung von Daten. Solche Blockweaves können einen Konsensmechanismus verwenden, der auf Proof of Access (PoA) und Proof of Work (PoW) basiert.
  • Die vorstehend beschriebenen Speichersysteme können, entweder allein oder in Kombination mit anderen Datenverarbeitungsgeräten, zur Unterstützung von In-Memory-Computing-Anwendungen verwendet werden. In-Memory-Computing beinhaltet die Speicherung von Informationen im RAM, die über einen Cluster von Computern verteilt sind. Für den Leser ist zu erkennen, dass die vorstehend beschriebenen Speichersysteme, insbesondere solche, die mit anpassbaren Mengen an Verarbeitungsressourcen, Speicherressourcen und Speicherressourcen konfigurierbar sind (z. B. solche Systeme, in denen Blades konfigurierbare Mengen jedes Ressourcentyps enthalten), in einer Weise konfiguriert werden können, dass sie eine Infrastruktur bereitstellen, die In-Memory-Computing unterstützen kann. Ebenso können die vorstehend beschriebenen Speichersysteme Komponenten enthalten (z. B. NVDIMMs, 3D-Crosspoint-Speicher, die schnellen, persistenten Direktzugriffsspeicher bereitstellen), die tatsächlich eine verbesserte In-Memory-Computing-Umgebung im Vergleich zu In-Memory-Computing-Umgebungen bereitstellen können, die auf über dedizierte Server verteiltem RAM basieren.
  • In einigen Ausführungsformen können die vorstehend beschriebenen Speichersysteme so konfiguriert sein, dass sie als hybride In-Memory-Computing-Umgebung arbeiten, die eine universelle Schnittstelle zu allen Speichermedien (z. B. RAM, Flash-Speicher, 3D-Koppelpunktspeicher) enthält. In solchen Ausführungsformen haben Benutzer möglicherweise keine Kenntnis darüber, wo ihre Daten gespeichert sind, können aber dennoch dieselbe vollständige, einheitliche API verwenden, um Daten zu adressieren. In solchen Ausführungsformen kann das Speichersystem (im Hintergrund) Daten auf die schnellste verfügbare Ebene verschieben - einschließlich einer intelligenten Platzierung der Daten in Abhängigkeit von verschiedenen Eigenschaften der Daten oder in Abhängigkeit von einer anderen Heuristik. In einem solchen Beispiel können die Speichersysteme sogar bestehende Produkte wie Apache Ignite und GridGain verwenden, um Daten zwischen den verschiedenen Speicherebenen zu bewegen, oder die Speichersysteme können Client-spezifische Software verwenden, um Daten zwischen den verschiedenen Speicherebenen zu bewegen. Die hier beschriebenen Speichersysteme können verschiedene Optimierungen implementieren, um die Leistung des In-Memory-Computings zu verbessern, wie z. B. Berechnungen so nah wie möglich an den Daten stattfinden zu lassen.
  • Für den Leser ist ferner 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. Beispielsweise könnte eine Infrastruktur primäre Rechenleistung in Form von Servern und Workstations umfassen, die auf die Verwendung von General-Purpose-Computing auf Grafikverarbeitungseinheiten („GPGPU“) spezialisiert sind, um Deep-Learning-Anwendungen zu beschleunigen, die zu einer Rechenmaschine verbunden sind, um Parameter für Deep Neuronal 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 einziges großes Training gruppiert oder unabhängig voneinander zum Trainieren mehrerer Modelle verwendet werden. Die Infrastruktur könnte auch ein Speichersystem wie die vorstehend beschriebenen umfassen, um z. B. einen Scale-Out-All-Flash-Datei- oder Objektspeicher bereitzustellen, über den auf Daten über Hochleistungsprotokolle wie NFS, S3 usw. zugegriffen werden kann. Die Infrastruktur kann auch z. B. redundante Top-of-Rack-Ethernet-Switches umfassen, die über Ports in MLAG-Port-Kanälen zur Redundanz mit dem Speicher und den Recheneinheiten verbunden sind. Die Infrastruktur könnte auch zusätzliche Rechenleistung in Form von Whitebox-Servern, optional mit GPUs, für Dateneingabe, Vorverarbeitung und Modell-Debugging enthalten. Weitere Infrastrukturen sind natürlich auch denkbar.
  • Für den Leser ist ferner zu erkennen, dass die vorstehend beschriebenen Speichersysteme entweder allein oder in Verbindung mit anderen Rechenanlagen so konfiguriert sein können, dass sie andere Kl-bezogene Tools unterstützen. Beispielsweise können die Speichersysteme Tools wie ONXX oder andere offene Austauschformate für neuronale Netze nutzen, die die Übertragung von Modellen, die in verschiedenen Kl-Frameworks geschrieben wurden, erleichtern. Ebenso können die Speichersysteme so konfiguriert sein, dass sie Tools wie Amazons Gluon unterstützen, die es Entwicklern ermöglichen, Prototypen für Deep-Learning-Modelle zu erstellen und zu trainieren. Tatsächlich können die vorstehend beschriebenen Speichersysteme Teil einer größeren Plattform sein, wie z. B. der IBM™ Cloud Private for Data, die integrierte Data Science-, Data Engineering- und Application Building-Services umfasst.
  • Für den Leser ist ferner 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 Rande des Netzwerks, nahe der Datenquelle, durchgeführt wird. Edge-Computing kann Anwendungen, Daten und Rechenleistung (d. h. Dienste) von zentralen Punkten weg an die logischen Enden eines Netzwerks verlagern. Durch den Einsatz 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 Ausführung von Rechenaufgaben auf der Edge-Lösung, die Speicherung von Daten auf der Edge-Lösung und die allgemeine Nutzung der Edge-Lösung kann der Verbrauch von teuren cloudbasierten Ressourcen vermieden werden, und es können sogar Leistungsverbesserungen im Vergleich zu einer stärkeren Abhängigkeit von cloudbasierten Ressourcen erzielt werden.
  • Während viele Aufgaben von der Nutzung einer Edge-Lösung profitieren können, eignen sich einige spezielle Anwendungen besonders für den Einsatz in einer solchen Umgebung. Zum Beispiel können Geräte wie Drohnen, autonome Autos, Roboter und andere eine extrem schnelle Verarbeitung erfordern - so schnell, dass das Senden von Daten in eine Cloud-Umgebung und zurück, um Datenverarbeitungsunterstützung zu erhalten, einfach zu langsam sein kann. Ein weiteres Beispiel: Einige loT-Geräte, wie z. B. angeschlossene Videokameras, eignen sich möglicherweise nicht für die Nutzung von cloudbasierten Ressourcen, da es nicht praktikabel ist (nicht nur aus Sicht des Datenschutzes, der Sicherheit oder aus finanzieller Sicht), die Daten in die Cloud zu senden, einfach aufgrund der reinen Datenmenge, um die es geht. Daher sind viele Aufgaben, bei denen es wirklich um Datenverarbeitung, -speicherung oder -kommunikation geht, möglicherweise besser für Plattformen geeignet, die Edge-Lösungen wie die vorstehend beschriebenen Speichersysteme enthalten.
  • Die vorstehend beschriebenen Speichersysteme können allein oder in Kombination mit anderen Rechenressourcen als Netzwerk-Edge-Plattform dienen, die Rechenressourcen, Speicherressourcen, Netzwerkressourcen, Cloud-Technologien und Netzwerkvirtualisierungstechnologien usw. kombiniert. Als Teil des Netzwerks kann das Edge ähnliche Eigenschaften wie andere Netzwerkeinrichtungen annehmen, von der Consumer Premise und Backhaul-Aggregation-Facilities bis hin zu Points of Presence (PoPs) und regionalen Rechenzentren. Für den Leser ist zu erkennen, dass Netzwerk-Workloads, wie virtuelle Netzwerkfunktionen (VNFs) und andere, auf der Netzwerk-Edge-Plattform verbleiben. Ermöglicht durch eine Kombination aus Containern und virtuellen Maschinen, kann die Network-Edge-Plattform auf Controller und Scheduler zurückgreifen, die nicht mehr geografisch mit den Datenverarbeitungsressourcen verbunden sind. Die Funktionen können als Microservices in Steuerungsebenen, Benutzer- und Datenebenen oder sogar Zustandsmaschinen aufgeteilt werden, sodass unabhängige Optimierungs- und Skalierungsverfahren angewendet werden können. Solche Benutzer- und Datenebenen können durch verstärkte Beschleuniger ermöglicht werden, sowohl durch solche, die sich in Serverplattformen befinden, wie FPGAs und Smart NICs, als auch durch SDN-fähiges Merchant-Silizium und programmierbare ASICs.
  • Die vorstehend beschriebenen Speichersysteme können auch für den Einsatz in der Big-Data-Analytik optimiert werden. Big-Data-Analytik kann allgemein als der Prozess der Untersuchung großer und vielfältiger Datensätze beschrieben werden, um verborgene Muster, unbekannte Korrelationen, Markttrends, Kundenpräferenzen und andere nützliche Informationen aufzudecken, die Unternehmen helfen können, fundiertere Geschäftsentscheidungen zu treffen. Als Teil dieses Prozesses können halbstrukturierte und unstrukturierte Daten wie z. B. Internet-Clickstream-Daten, Webserver-Protokolle, Social-Media-Inhalte, Text aus Kunden-E-Mails und Umfrageantworten, Gesprächsdetail-Aufzeichnungen von Mobiltelefonen, loT-Sensordaten und andere Daten in eine strukturierte Form umgewandelt werden.
  • Die vorstehend beschriebenen Speichersysteme können auch Anwendungen unterstützen (einschließlich der Implementierung als Systemschnittstelle), die Aufgaben in Reaktion auf menschliche Sprache ausführen. Zum Beispiel können die Speichersysteme die Ausführung intelligenter persönlicher Assistentenanwendungen unterstützen, wie z. B. Amazons Alexa, Apple Siri, Google Voice, Samsung Bixby, Microsoft Cortana und andere. Während die im vorigen Satz beschriebenen Beispiele die Sprache 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 Methoden führen. Ebenso kann das Speichersystem eine solche Anwendung tatsächlich ausführen, um einem Benutzer, z. B. einem Systemadministrator, die Interaktion mit dem Speichersystem über Sprache zu ermöglichen. Solche Anwendungen sind im Allgemeinen in der Lage, Sprachinteraktion, Musikwiedergabe, das Erstellen von To-Do-Listen, das Einstellen von Alarmen, das Streaming von Podcasts, das Abspielen von Hörbüchern und das Bereitstellen von Wetter-, Verkehrs- und anderen Echtzeitinformationen, wie z. B. Nachrichten, durchzuführen, obwohl in Ausführungsformen gemäß der vorliegenden Offenbarung solche Anwendungen als Schnittstellen zu verschiedenen Systemverwaltungsvorgängen verwendet werden können.
  • Die vorstehend beschriebenen Speichersysteme können auch Kl-Plattformen implementieren, um die Vision eines autonomen Speichers zu verwirklichen. Solche Kl-Plattformen können so konfiguriert sein, dass sie globale prädiktive Intelligenz liefern, indem sie große Mengen an Telemetriedatenpunkten des Speichersystems sammeln und analysieren, um eine mühelose Verwaltung, Analyse und Unterstützung zu ermöglichen. Tatsächlich können solche Speichersysteme in der Lage sein, sowohl die Kapazität und die Leistung vorherzusagen als auch intelligente Ratschläge für das Bereitstellen, die Interaktion und die Optimierung von Arbeitslasten zu generieren. Solche Kl-Plattformen können so konfiguriert sein, dass sie alle eingehenden Telemetriedaten des Speichersystems mit einer Bibliothek von Problem-Fingerprints abgleichen, um Vorfälle in Echtzeit vorherzusagen und zu beheben, bevor sie sich auf Kundenumgebungen auswirken, und Hunderte von leistungsbezogenen Variablen erfassen, die zur Vorhersage der Leistungslast verwendet werden.
  • Die vorstehend beschriebenen Speichersysteme können die serielle oder gleichzeitige Ausführung von Anwendungen der künstlichen Intelligenz, Anwendungen für maschinelles Lernen, Datenanalyseanwendungen, Datentransformationen und anderen Aufgaben unterstützen, die zusammen eine Kl-Leiter bilden können. Eine solche KI-Leiter kann effektiv durch die Kombination solcher Elemente gebildet werden, um eine vollständige Data-Science-Pipeline zu bilden, wenn Abhängigkeiten zwischen den Elementen der Kl-Leiter bestehen. Beispielsweise kann KI voraussetzen, dass eine Form von maschinellem Lernen stattgefunden hat, maschinelles Lernen kann voraussetzen, dass eine Form von Analytik stattgefunden hat, Analytik kann voraussetzen, dass eine Form von Daten- und Informationsarchitektur stattgefunden hat, und so weiter. So kann jedes Element als eine Sprosse in einer Kl-Leiter betrachtet werden, die zusammen eine vollständige und anspruchsvolle Kl-Lösung bilden kann.
  • Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um überall dort eine Kl- zu ermöglichen, wo KI weite und umfangreiche Aspekte der Wirtschaft und des Lebens durchdringt. Beispielsweise kann KI eine wichtige Rolle bei der Bereitstellung von Lösungen für Deep-Learning, Deep Reinforcement Learning-Lösungen, Lösungen für künstliche allgemeine Intelligenz, autonome Fahrzeuge, kognitive Computerlösungen, kommerzielle Drohnen oder UAVs, dialogorientierte Benutzerschnittstellen, Unternehmenstaxonomien, Ontologie-Management-Lösungen, Lösungen für maschinelles Lernen, Smart Dust, Smart Robots, Smart Workplaces und vielen anderen spielen.
  • Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Computerumgebungen, verwendet werden, um eine breite Palette von transparent immersiven Erfahrungen zu ermöglichen (einschließlich solcher, die digitale Zwillinge von verschiedenen „Dingen“ wie Menschen, Orten, Prozessen, Systemen usw. verwenden), bei denen Technologie Transparenz zwischen Menschen, Unternehmen und Dingen schaffen kann. Solche transparent immersiven Erfahrungen können als Augmented-Reality-Technologien, Connected Homes, Virtual-Reality-Technologien, Brain-Computer-Interfaces, Human-Augmentation-Technologien, Nanoröhrenelektronik, volumetrische Displays, 4D-Drucktechnologien oder andere bereitgestellt werden.
  • Die vorstehend beschriebenen Speichersysteme können auch, entweder allein oder in Kombination mit anderen Rechenumgebungen, zur Unterstützung einer Vielzahl von digitalen Plattformen eingesetzt werden. Solche digitalen Plattformen können z. B. 5G-Mobilfunksysteme und -plattformen, Digital-Twin-Plattformen, Edge-Computing-Plattformen, loT-Plattformen, Quantencomputerplattformen, serverlose PaaS, softwaredefinierte Sicherheit, neuromorphe Computerplattformen usw. umfassen.
  • Die vorstehend beschriebenen Speichersysteme können auch Teil einer Multi-Cloud-Umgebung sein, in der mehrere Cloud-Computing- und Storage-Dienste in einer einzigen heterogenen Architektur eingesetzt werden. Um den Betrieb einer solchen Multi-Cloud-Umgebung zu erleichtern, können DevOps-Tools eingesetzt werden, um die Orchestrierung über Clouds hinweg zu ermöglichen. Ebenso können Continuous Development- und Continuous Integration-Tools eingesetzt werden, um Prozesse rund um Continuous Integration und Delivery, den Rollout neuer Funktionen und die Bereitstellung von Cloud-Workloads zu standardisieren. Durch die Standardisierung dieser Prozesse kann eine Multi-Cloud-Strategie implementiert werden, die die Nutzung des besten Anbieters für jede Arbeitslast ermöglicht.
  • Die vorstehend beschriebenen Speichersysteme können als Teil einer Plattform verwendet werden, um die Verwendung von Krypto-Ankern zu ermöglichen, die verwendet werden können, um die Herkunft und den Inhalt eines Produkts zu authentifizieren, um sicherzustellen, dass es mit einem dem Produkt zugeordneten Blockchain-Datensatz übereinstimmt. In ähnlicher Weise können die vorstehend beschriebenen Speichersysteme als Teil einer Reihe von Tools zum Sichern von Daten, die auf dem Speichersystem gespeichert sind, verschiedene Verschlüsselungstechnologien und -schemata implementieren, einschließlich Gitterkryptografie. Die Gitterkryptografie kann Konstruktionen von kryptografischen Primitiven beinhalten, die entweder in der Konstruktion selbst oder im Sicherheitsnachweis Gitter verwenden. Im Gegensatz zu Public-Key-Schemata wie RSA-, Diffie-Hellman- oder Elliptic-Curve-Kryptosystemen, die leicht von einem Quantencomputer angegriffen werden können, scheinen einige gitterbasierte Konstruktionen sowohl gegen Angriffe durch klassische als auch durch Quantencomputer resistent zu sein.
  • Ein Quantencomputer ist ein Gerät, das Quantenberechnungen durchführt. Quantencomputer sind Rechner, die quantenmechanische Phänomene wie Überlagerung und Verschränkung nutzen. Quantencomputer unterscheiden sich von herkömmlichen Computern, die auf Transistoren basieren, da solche herkömmlichen Computer erfordern, dass Daten in binären Ziffern (Bits) kodiert werden, von denen jede immer in einem von zwei bestimmten Zuständen ist (0 oder 1). Im Gegensatz zu herkömmlichen Computern verwenden Quantencomputer Quantenbits, die sich in Zustandsüberlagerungen befinden können. Ein Quantencomputer verwaltet eine Sequenz von Qubits, wobei ein einzelnes Qubit eine Eins, eine Null oder eine beliebige Quantenüberlagerung dieser beiden Qubit-Zustände darstellen kann. Ein Paar Qubits kann sich in einer beliebigen Quantenüberlagerung von 4 Zuständen befinden, und drei Qubits in einer beliebigen Überlagerung von 8 Zuständen. Ein Quantencomputer mit n Qubits kann sich im Allgemeinen in einer beliebigen Überlagerung von bis zu 2^n verschiedenen Zuständen gleichzeitig befinden, während sich ein herkömmlicher Computer immer nur in einem dieser Zustände befinden kann. Eine Quanten-Turing-Maschine ist ein theoretisches Modell eines solchen Computers.
  • Die vorstehend beschriebenen Speichersysteme können auch mit FPGA-beschleunigten Servern als Teil einer größeren Kl- oder ML-Infrastruktur gepaart werden. Solche FPGA-beschleunigten Server können sich in der Nähe (z. B. im selben Rechenzentrum) der vorstehend beschriebenen Speichersysteme befinden oder sogar in eine Appliance integriert sein, die ein oder mehrere Speichersysteme, einen oder mehrere FPGA-beschleunigte Server, eine Netzwerkinfrastruktur, die die Kommunikation zwischen dem einen oder den mehreren Speichersystemen und dem einen oder den mehreren FPGA-beschleunigten Servern unterstützt, sowie andere Hardware- und Softwarekomponenten umfasst. Alternativ können sich FPGA-beschleunigte Server in einer Cloud-Computing-Umgebung befinden, die zur Ausführung rechenbezogener Aufgaben für Kl- und ML-Aufgaben verwendet werden kann. Jede der vorstehend beschriebenen Ausführungsformen kann verwendet werden, um gemeinsam als FPGA-basierte Kl- oder ML-Plattform zu dienen. Für den Leser ist zu erkennen, dass in einigen Ausführungsformen der FPGA-basierten Kl- oder ML-Plattform die FPGAs, die in den FPGA-beschleunigten Servern enthalten sind, für verschiedene Arten von ML-Modellen (z. B. LSTMs, CNNs, GRUs) rekonfiguriert werden können. Die Möglichkeit, die FPGAs, die in den FPGA-beschleunigten Servern enthalten sind, neu zu konfigurieren, kann die Beschleunigung einer ML- oder Kl-Anwendung auf der Grundlage der optimalen numerischen Präzision und des verwendeten Speichermodells ermöglichen. Für den Leser ist zu erkennen, dass durch die Behandlung der Sammlung von FPGA-beschleunigten Servern als ein Pool von FPGAs jede CPU im Rechenzentrum den Pool von FPGAs als einen gemeinsam genutzten Hardware-Microservice nutzen kann, anstatt einen Server auf dedizierte Beschleuniger zu beschränken, die an ihn angeschlossen sind.
  • Die vorstehend beschriebenen FPGA-beschleunigten Server und GPU-beschleunigten Server können ein Rechenmodell implementieren, bei dem das Modell und die Parameter für maschinelles Lernen in den On-Chip-Speicher mit hoher Bandbreite eingebettet sind und viele Daten durch den On-Chip-Speicher mit hoher Bandbreite strömen, anstatt eine kleine Datenmenge in einer CPU zu speichern und einen langen Strom von Befehlen darüber laufen zu lassen, wie es bei herkömmlicheren Rechenmodellen der Fall ist. FPGAs können für dieses Rechenmodell sogar effizienter sein als GPUs, da die FPGAs nur mit den Befehlen programmiert werden können, die für diese Art von Rechenmodell benötigt werden.
  • Die vorstehend beschriebenen Speichersysteme können so konfiguriert sein, dass sie eine parallele Speicherung ermöglichen, z. B. durch die Verwendung eines parallelen Dateisystems wie BeeGFS. Solche parallelen Dateisysteme können eine verteilte Metadatenarchitektur enthalten. Beispielsweise kann das parallele Dateisystem eine Vielzahl von Metadatenservern umfassen, über die Metadaten verteilt werden, sowie Komponenten, die Dienste für Clients und Speicherserver umfassen.
  • Die vorstehend beschriebenen Systeme können die Ausführung einer breiten Palette von Softwareanwendungen unterstützen. Solche Softwareanwendungen können auf verschiedene Arten bereitgestellt werden, einschließlich Container-basierter Bereitstellungsmodelle. Container-basierte Anwendungen können mit einer Vielzahl von Tools verwaltet werden. Zum Beispiel können Container-basierte Anwendungen mit Docker Swarm, Kubernetes und anderen verwaltet werden. Container-basierte Anwendungen können verwendet werden, um ein serverloses, Cloud-Native-Computing-Bereitstellungs- und Verwaltungsmodell für Softwareanwendungen zu ermöglichen. Zur Unterstützung eines serverlosen, Cloud-Native-Computing-Bereitstellungs- und Verwaltungsmodells für Softwareanwendungen können Container als Teil eines Event-Handling-Mechanismus (z. B. AWS Lambdas) verwendet werden, so dass verschiedene Ereignisse dazu führen, dass eine Container-basierte Anwendung als Event-Handler ausgeführt wird.
  • Die vorstehend beschriebenen Systeme können auf verschiedene Weise eingesetzt werden, unter anderem so, dass sie Netzwerke der fünften Generation („5G“) unterstützen. 5G-Netze unterstützen möglicherweise eine wesentlich schnellere Datenkommunikation als frühere Generationen von Mobilfunknetzen und können infolgedessen zu einer Disaggregation von Daten- und Rechenressourcen führen, da moderne massive Rechenzentren an Bedeutung verlieren und z. B. durch lokalere Mikro-Rechenzentren ersetzt werden können, die sich in der Nähe der Mobilfunkmasten befinden. Die vorstehend beschriebenen Systeme können zu solchen lokalen, Mikro-Rechenzentren gehören und Teil von oder gepaart mit Multi-Access-Edge-Computing-Systemen („MEC“) sein. Solche MEC-Systeme können Cloud-Computing-Funktionen und eine IT-Service-Umgebung am Rande des Mobilfunknetzes ermöglichen. Durch das Ausführen von Anwendungen und damit verbundenen Verarbeitungsaufgaben näher am Mobilfunkkunden kann die Netzüberlastung reduziert werden und die Anwendungen können leistungsfähiger werden.
  • Zur weiteren Erläuterung zeigt 3D ein beispielhaftes Datenverarbeitungsgerät 350, das speziell für die Durchführung eines oder mehrerer der hier beschriebenen Prozesse konfiguriert sein kann. Wie in 3D gezeigt, kann das Datenverarbeitungsgerät 350 eine Kommunikationsschnittstelle 352, einen Prozessor 354, ein Speichergerät 356 und ein Eingabe-/Ausgabemodul 358 umfassen, die über eine Kommunikationsinfrastruktur 360 miteinander kommunizieren. Während in 3D ein beispielhaftes Datenverarbeitungsgerät 350 gezeigt wird, sind die in 3D dargestellten Komponenten nicht als einschränkend zu verstehen. Zusätzliche oder alternative Komponenten können in anderen Ausführungsformen verwendet werden. Die in 3D gezeigten Komponenten des Datenverarbeitungsgeräts 350 werden nun im Detail beschrieben.
  • Die Kommunikationsschnittstelle 352 kann für die Kommunikation mit einem oder mehreren Datenverarbeitungsgeräten konfiguriert sein. Beispiele für die Kommunikationsschnittstelle 352 umfassen ohne Einschränkung eine drahtgebundene Netzwerkschnittstelle (z. B. eine Netzwerkschnittstellenkarte), eine drahtlose Netzwerkschnittstelle (z. B. eine drahtlose Netzwerkschnittstellenkarte), ein Modem, eine Audio-/Videoverbindung und jede andere geeignete Schnittstelle.
  • Der Prozessor 354 stellt im Allgemeinen einen beliebigen Typ oder eine beliebige Form einer Verarbeitungseinheit dar, die in der Lage ist, Daten zu verarbeiten und/oder eine oder mehrere der hier beschriebenen Befehle, Prozesse und/oder Operationen zu interpretieren, auszuführen und/oder deren Ausführung zu steuern. Der Prozessor 354 kann Operationen durchführen, indem er computerausführbare Befehle 362 (z. B. eine Anwendung, Software, einen Code und/oder andere ausführbare Dateninstanzen) ausführt, die in dem Speichergerät 356 gespeichert sind.
  • Das Speichergerät 356 kann ein oder mehrere Datenspeichermedien, -geräte oder - konfigurationen enthalten und jede Art, Form und Kombination von Datenspeichermedien und/oder -geräten verwenden. Beispielsweise kann das Speichergerät 356 eine beliebige Kombination aus den hierin beschriebenen nichtflüchtigen Medien und/oder flüchtigen Medien enthalten, ist aber nicht darauf beschränkt. Elektronische Daten, einschließlich der hierin beschriebenen Daten, können vorübergehend und/oder dauerhaft im Speichergerät 356 gespeichert werden. Beispielsweise können Daten, die für computerausführbare Befehle 362 repräsentativ sind, die so konfiguriert sind, dass sie den Prozessor 354 anweisen, eine der hier beschriebenen Operationen durchzuführen, auf dem Speichergerät 356 gespeichert werden. In einigen Beispielen können die Daten in einer oder mehreren Datenbanken angeordnet sein, die sich in dem Speichergerät 356 befinden.
  • Das E/A-Modul 358 kann ein oder mehrere E/A-Module enthalten, die so konfiguriert sind, dass sie Benutzereingaben empfangen und Benutzerausgaben bereitstellen. Das E/A-Modul 358 kann eine beliebige Hardware, Firmware, Software oder eine Kombination davon enthalten, die die Eingabe- und Ausgabefunktionen unterstützt. Beispielsweise kann das E/A-Modul 358 Hardware und/oder Software zur Erfassung von Benutzereingaben enthalten, einschließlich, aber nicht beschränkt auf eine Tastatur oder ein Tastenfeld, eine Touchscreen-Komponente (z. B. ein Touchscreen-Display), einen Empfänger (z. B. einen HF- oder Infrarotempfänger), Bewegungssensoren und/oder eine oder mehrere Eingabetasten.
  • Das E/A-Modul 358 kann ein oder mehrere Geräte zur Darstellung der Ausgabe an einen Benutzer enthalten, einschließlich, aber nicht beschränkt auf eine Grafik-Engine, ein Display (z. B. einen Bildschirm), einen oder mehrere Ausgabetreiber (z. B. Display-Treiber), einen oder mehrere Audio-Lautsprecher und einen oder mehrere Audio-Treiber. In bestimmten Ausführungsformen ist das E/A-Modul 358 so konfiguriert, dass es grafische Daten an ein Display zur Darstellung für einen Benutzer bereitstellt. Die grafischen Daten können eine oder mehrere grafische Benutzeroberflächen und/oder jeden anderen grafischen Inhalt darstellen, der für eine bestimmte Implementierung geeignet ist. In einigen Beispielen kann jedes der hier beschriebenen Systeme, Datenverarbeitungsgeräte und/oder andere Komponenten durch das Datenverarbeitungsgerät 350 implementiert werden.
  • Zur weiteren Erläuterung zeigt 4A ein Blockdiagramm, das eine Vielzahl von Speichersystemen (402, 404, 406) veranschaulicht, die einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung tragen. Obwohl weniger detailliert dargestellt, können die in 4A dargestellten Speichersysteme (402, 404, 406) den vorstehend unter Bezugnahme auf die 1A-1D, die 2A-2G, die 3A-3B oder eine beliebige Kombination davon beschriebenen Speichersystemen ähnlich sein. Tatsächlich können die in 4A dargestellten Speichersysteme (402, 404, 406) die gleichen, weniger oder zusätzliche Komponenten enthalten wie die vorstehend beschriebenen Speichersysteme.
  • In dem in 4A dargestellten Beispiel ist jedes der Speichersysteme (402, 404, 406) mit mindestens einem Computerprozessor (408, 410, 412), Computer-Arbeitsspeicher (414, 416, 418) und Computer-Datenspeicher (420, 422, 424) dargestellt. 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 verschiedener Hardware-Vorrichtungen sein. Der Unterschied 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) sich physikalisch nahe bei den Computerprozessoren (408, 410, 412) befindet und Computerprogrammbefehle speichern kann, die von den Computerprozessoren (408, 410, 412) ausgeführt werden, während der Computer-Datenspeicher (420, 422, 424) als nichtflüchtiger Speicher zum Speichern von Benutzerdaten, Metadaten, die die Benutzerdaten beschreiben, und so weiter ausgeführt ist. Unter Bezugnahme 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) innerhalb einer oder mehrerer der Steuerungen (110A-110D) befinden, während die angeschlossenen Speichergeräte (171A-171F) als Computer-Datenspeicher (420, 422, 424) innerhalb eines bestimmten Speichersystems (402, 404, 406) dienen können.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) mit einem oder mehreren Pods (430, 432) gemäß einigen Ausführungsformen der vorliegenden Offenbarung verbunden sein. Jeder der in 4A 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 auf dem neuesten Stand gehalten, wenn der Datensatz geändert wird. Speichersysteme können von einem Pod entfernt werden, was dazu führt, dass der Datensatz auf dem entfernten Speichersystem nicht mehr auf dem neuesten Stand gehalten wird. In dem in 4A dargestellten Beispiel kann jedes Speichersystem, das für einen Pod aktiv ist (es ist ein aktuelles, funktionierendes, störungsfreies Element eines störungsfreien Pods), Anfragen zum Ändern oder Lesen des Datensatzes des Pods empfangen und verarbeiten.
  • In dem in 4A dargestellten Beispiel kann jeder Pod (430, 432) auch einen Satz von verwalteten Objekten und Verwaltungsoperationen sowie einen Satz von Zugriffsoperationen zum Ändern oder Lesen des Datensatzes (426, 428) enthalten, der mit dem jeweiligen Pod (430, 432) verbunden ist. In einem solchen Beispiel können die Verwaltungsoperationen verwaltete Objekte gleichwertig über jedes der Speichersysteme ändern oder abfragen. Ebenso können Zugriffsoperationen zum Lesen oder Ändern des Datensatzes äquivalent über jedes der Speichersysteme erfolgen. In einem solchen Beispiel speichert zwar jedes Speichersystem eine separate Kopie des Datensatzes als eigene Teilmenge der gespeicherten und zur Verwendung durch das Speichersystem angekündigten Datensätze, aber die Operationen zum Ändern von verwalteten Objekten oder des Datensatzes, die über ein beliebiges Speichersystem durchgeführt und abgeschlossen werden, spiegeln sich in nachfolgenden Verwaltungsobjekten zum Abfragen des Pods oder in nachfolgenden Zugriffsoperationen zum Lesen des Datensatzes wider.
  • Für den Leser ist zu erkennen, dass Pods mehr Fähigkeiten implementieren können als nur einen geclusterten, synchron replizierten Datensatz. Pods können z. B. zur Implementierung von Tenants verwendet werden, wobei die Datensätze in gewisser Weise sicher voneinander isoliert sind. Pods können auch verwendet werden, um virtuelle Arrays oder virtuelle Speichersysteme zu implementieren, bei denen jeder Pod als eindeutige Speichereinheit in einem Netzwerk (z. B. einem Storage Area Network oder einem Internet Protocol-Netzwerk) mit separaten Adressen dargestellt wird. Im Fall eines Pods mit mehreren Speichersystemen, der ein virtuelles Speichersystem implementiert, können alle physischen Speichersysteme, die mit dem Pod verbunden sind, in gewisser Weise als dasselbe Speichersystem dargestellt werden (z. B. als ob die mehreren physischen Speichersysteme nicht anders wären als mehrere Netzwerkanschlüsse an einem einzigen Speichersystem).
  • Für den Leser ist zu erkennen, dass Pods auch Verwaltungseinheiten sein können, die eine Sammlung von Volumes, Dateisystemen, Objekt-/Analysespeichern, Snapshots und anderen administrativen Einheiten darstellen, bei denen administrative Änderungen (z. B. Namensänderungen, Eigenschaftsänderungen, Verwaltung von Exporten oder Authorities für einen Teil des Pod-Datensatzes) auf einem beliebigen Speichersystem automatisch auf alle aktiven Speichersysteme übertragen werden, die dem Pod zugeordnet sind. Darüber hinaus könnten Pods auch Einheiten der Datenerfassung und Datenanalyse sein, bei denen Leistungs- und Kapazitätsmetriken auf eine Art und Weise dargestellt werden, die über alle aktiven Speichersysteme für den Pod aggregiert oder die Datenerfassung und -analyse für jeden Pod separat aufruft oder vielleicht den Beitrag jedes angeschlossenen Speichersystems zum eingehenden Inhalt und zur Leistung für jeden Pod darstellt.
  • Ein Modell für die Pod-Zugehörigkeit kann als eine Liste von Speichersystemen und eine Teilmenge dieser Liste definiert werden, bei der die Speichersysteme als synchron mit dem Pod gelten. Ein Speichersystem kann als synchron mit einem Pod betrachtet werden, wenn es zumindest innerhalb einer Wiederherstellung einen identischen Leerlaufinhalt für die letzte geschriebene Kopie des dem Pod zugeordneten Datensatzes hat. Leerlaufinhalt ist der Inhalt, nachdem alle laufenden Änderungen abgeschlossen wurden, ohne dass neue Änderungen verarbeitet wurden. Dies wird manchmal auch als „crash recoverable“ Konsistenz bezeichnet. Die Wiederherstellung eines Pods führt den Prozess des Ausgleichs von Unterschieden bei der Anwendung gleichzeitiger Aktualisierungen auf synchronen Speichersystemen im Pod aus. Die Wiederherstellung kann alle Inkonsistenzen zwischen Speichersystemen beim Abschluss gleichzeitiger Änderungen auflösen, die bei verschiedenen Elementen des Pods angefordert wurden, aber keinem Anforderer als erfolgreich abgeschlossen signalisiert wurden. Speichersysteme, die als Pod-Elemente aufgeführt sind, aber nicht als synchron mit dem Pod aufgeführt sind, können als vom Pod „getrennt“ bezeichnet werden. Speichersysteme, die als Pod-Elemente aufgelistet sind, für den Pod synchronisiert sind und aktuell für die aktive Bereitstellung von Daten für den Pod zur Verfügung stehen, sind für den Pod „online“.
  • Jedes Speichersystem, das Element eines Pods ist, kann seine 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 davon ausgehen, dass es für den Pod synchron ist, und es muss mit allen anderen Speichersystemen kommunizieren, die es für den Pod als synchron ansieht. Wenn ein Speichersystem nicht sicher sein kann, dass es synchronisiert ist und mit allen anderen Speichersystemen, die synchronisiert sind, kommuniziert, 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 synchronisiert ist und mit allen anderen Speichersystemen, die synchronisiert sind, kommuniziert. Ein erstes Speichersystem kann zu dem Schluss kommen, dass ein zweites gepaartes Speichersystem abgetrennt werden sollte, wodurch das erste Speichersystem fortfahren kann, da es nun mit allen Speichersystemen in der Liste synchronisiert ist. Das zweite Speichersystem muss jedoch daran gehindert werden, alternativ zu schlussfolgern, dass das erste Speichersystem abgetrennt werden soll, während das zweite Speichersystem den Betrieb fortsetzt. Dies würde zu einem „Split Brain“-Zustand führen, der u. a. zu unvereinbaren Datensätzen, Beschädigung von Datensätzen oder Anwendungen führen kann.
  • Die Situation, in der bestimmt werden muss, wie vorzugehen ist, wenn keine Kommunikation mit gepaarten Speichersystemen stattfindet, kann auftreten, wenn ein Speichersystem normal läuft und dann bemerkt, dass die Kommunikation unterbrochen wurde, 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 den Betrieb wieder aufnimmt, während es aus irgendeinem Grund den Betrieb von einem Satz von Speichersystem-Controllern auf einen anderen Satz umstellt oder während oder nach einer beliebigen Kombination dieser oder anderer Arten von Ereignissen. Tatsächlich kann das Speichersystem jedes Mal, wenn ein Speichersystem, das mit einem Pod verbunden ist, nicht mit allen bekannten nicht-abgekoppelten Elementen kommunizieren kann, entweder kurz warten, bis die Kommunikation hergestellt werden kann, offline gehen und weiter warten, oder es kann auf irgendeine Weise feststellen, dass es sicher ist, das nicht-kommunizierende Speichersystem abkoppeln zu können, ohne zu riskieren, dass es zu einem Split Brain kommt, weil das nicht-kommunizierende Speichersystem die alternative Ansicht abschließt, und dann fortfahren. Wenn eine sichere Trennung schnell genug erfolgen kann, kann das Speichersystem für den Pod mit kaum mehr als einer kurzen Verzögerung und ohne daraus resultierende Anwendungsausfälle für Anwendungen, welche Anforderungen an die verbleibenden Online-Speichersysteme stellen können, online bleiben.
  • Ein Beispiel für diese Situation ist, wenn ein Speichersystem wissen kann, dass es veraltet ist. Das kann z. B. 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 eine erneute Verbindung zu einem anderen Speichersystem herstellt und feststellt, dass das andere Speichersystem das erste Speichersystem bereits als getrennt markiert hatte. In diesem Fall wartet dieses erste Speichersystem einfach, bis es eine Verbindung zu einer anderen Gruppe von Speichersystemen herstellt, die für den Pod synchronisiert sind.
  • Dieses Modell erfordert ein gewisses Maß an Überlegungen dazu, wie Speichersysteme zu Pods hinzugefügt oder aus der Liste der synchronisierten Pod-Elemente entfernt werden. Da jedes Speichersystem über eine eigene Kopie der Liste verfügt 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 zur Verfügung steht, muss darauf geachtet werden, dass vorübergehende Inkonsistenzen keine Probleme verursachen. Wenn z. B. ein Speichersystem für einen Pod synchronisiert ist und ein zweites Speichersystem hinzugefügt wird, wird das zweite Speichersystem aktualisiert, um beide Speichersysteme zuerst als synchronisiert aufzulisten. Wenn dann ein Fehler auftritt und beide Speichersysteme neu gestartet werden, könnte das zweite Speichersystem starten und darauf warten, eine Verbindung mit dem ersten Speichersystem herzustellen, während das erste Speichersystem nicht weiß, dass es auf das zweite Speichersystem warten sollte oder könnte. Wenn das zweite Speichersystem dann auf die Unfähigkeit, sich mit dem ersten Speichersystem zu verbinden, reagiert, indem es einen Prozess durchläuft, um es zu trennen, dann könnte es erfolgreich sein, einen Prozess abzuschließen, von dem das erste Speichersystem nichts weiß, was zu einem Split Brain führt. Daher kann es notwendig sein, sicherzustellen, dass Speichersysteme nicht unzweckmäßig darüber abstimmen, ob sie einen Abtrennungsprozess durchlaufen sollen, wenn sie nicht miteinander kommunizieren.
  • Eine Möglichkeit, um sicherzustellen, dass Speichersysteme nicht in unzweckmäßiger Weise darüber abstimmen, ob sie einen Abtrennungsprozess durchlaufen sollen, wenn sie nicht miteinander kommunizieren, besteht darin, dass beim Hinzufügen eines neuen Speichersystems zur Liste der synchronisierten Elemente für einen Pod das neue Speichersystem zunächst speichert, dass es ein abgetrenntes Element ist (und vielleicht, dass es als synchronisiertes Element hinzugefügt wird). Dann können die vorhandenen synchronisierten Speichersysteme lokal speichern, dass das neue Speichersystem ein synchronisiertes Element ist, bevor das neue Speichersystem diese Tatsache ebenfalls lokal speichert. Wenn es eine Reihe von Neustarts oder Netzwerkausfällen gibt, bevor das neue Speichersystem seinen synchronisierten Status speichert, können die ursprünglichen Speichersysteme das neue Speichersystem aufgrund fehlender Kommunikation trennen, aber das neue Speichersystem wird warten. Eine umgekehrte Version dieser Änderung könnte für das Entfernen eines kommunizierenden Speichersystems aus einem Pod erforderlich sein: Zuerst speichert das entfernte Speichersystem, dass es nicht mehr synchronisiert ist, dann speichern die verbleibenden Speichersysteme, dass das entfernte Speichersystem nicht mehr synchronisiert ist, dann löschen alle Speichersysteme das entfernte Speichersystem aus ihren Pod-Elemente-Listen. Je nach Implementierung ist ein zwischengeschalteter persistierter abgetrennter Zustand möglicherweise nicht erforderlich. Ob bei lokalen Kopien der Elemente-Listen Vorsicht geboten ist oder nicht, kann davon abhängen, welches Modell die Speichersysteme für die gegenseitige Überwachung oder für die Validierung ihrer Zugehörigkeit verwenden. Wenn für beides ein Konsensmodell verwendet wird oder wenn ein externes System (oder ein externes verteiltes oder geclustertes System) zum Speichern und Validieren der Pod-Zugehörigkeit verwendet wird, dann spielen Inkonsistenzen in lokal gespeicherten Zugehörigkeitslisten möglicherweise keine Rolle.
  • Wenn die Kommunikation ausfällt oder ein oder mehrere Speichersysteme in einem Pod ausfallen, oder wenn ein Speichersystem hochfährt (oder auf einen sekundären Controller ausfällt) und nicht mit den gepaarten Speichersystemen für einen Pod kommunizieren kann und es für ein oder mehrere Speichersysteme an der Zeit ist, sich zu entscheiden, ein oder mehrere gepaarte Speichersysteme zu trennen, muss ein Algorithmus oder Mechanismus verwendet werden, um zu entscheiden, dass dies sicher ist, und die Trennung zu vollziehen. Eine Möglichkeit, Trennungen aufzulösen, ist die Verwendung eines Mehrheitsmodells (oder Quorum) für die Zugehörigkeit. Bei drei Speichersystemen können sich zwei kommunizierende Systeme darauf einigen, ein drittes Speichersystem, das nicht kommuniziert, zu trennen, aber dieses dritte Speichersystem kann nicht von sich aus entscheiden, eines der beiden anderen Systeme zu trennen. Verwirrung kann entstehen, wenn die Kommunikation der Speichersysteme inkonsistent ist. Beispielsweise könnte Speichersystem A mit Speichersystem B kommunizieren, aber nicht mit C, während Speichersystem B sowohl mit A als auch mit C kommuniziert. Also könnten A und B C trennen, oder B und C könnten A trennen, aber es könnte mehr Kommunikation zwischen den Pod-Elementen erforderlich sein, um dies herauszufinden.
  • In einem Modell mit Quorum-Zugehörigkeit ist beim Hinzufügen und Entfernen von Speichersystemen Vorsicht geboten. Wenn z. B. ein viertes Speichersystem hinzugefügt wird, beträgt die „Mehrheit“ der Speichersysteme zu diesem Zeitpunkt drei. Der Übergang von drei Speichersystemen (wobei zwei für die Mehrheit erforderlich sind) zu einem Pod mit einem vierten Speichersystem (wobei drei für die Mehrheit erforderlich sind) kann etwas Ähnliches wie das zuvor beschriebene Modell für das vorsichtige Hinzufügen eines Speichersystems zur In-Sync-Liste erfordern. Das vierte Speichersystem könnte beispielsweise in einem anhängenden, aber noch nicht angeschlossenen Zustand beginnen, in dem es nie eine Abstimmung über das Quorum auslösen würde. Sobald sich das vierte Speichersystem in diesem Zustand befindet, könnten die ursprünglichen drei Pod-Elemente aktualisiert werden, damit sie über das vierte Element und die neue Anforderung einer Mehrheit von drei Speichersystemen informiert sind, um ein viertes abzutrennen. Das Entfernen eines Speichersystems aus einem Pod könnte dieses Speichersystem in ähnlicher Weise in einen lokal gespeicherten „Abtrennen“-Zustand versetzen, bevor die anderen Pod-Elemente aktualisiert werden. Ein alternatives Schema hierfür ist die Verwendung eines verteilten Konsensmechanismus wie PAXOS oder RAFT, um Änderungen der Zugehörigkeit zu implementieren oder Abtrennungsanfragen zu verarbeiten.
  • Eine weitere Möglichkeit zum Handhaben von Zugehörigkeitsübergängen ist die Verwendung eines externen Systems, das außerhalb der Speichersysteme selbst eingerichtet ist, um die Pod-Zugehörigkeit zu verwalten. Um für einen Pod online zu sein, muss ein Speichersystem zuerst das externe Pod-Zugehörigkeitssystem kontaktieren, um zu überprüfen, ob es für den Pod synchronisiert ist. Jedes Speichersystem, das für einen Pod online ist, sollte dann in Kommunikation mit dem Pod-Zugehörigkeitssystem bleiben und warten oder offline gehen, wenn es die Kommunikation verliert. Ein externer Pod-Membership-Manager könnte als hochverfügbarer Cluster mit verschiedenen Cluster-Tools implementiert werden, z. B. Oracle RAC, Linux HA, VERITAS Cluster Server, HACMP von IBM oder andere. Ein externer Pod-Membership-Manager könnte auch verteilte Konfigurationstools wie Etcd oder Zookeeper oder eine zuverlässige verteilte Datenbank wie DynamoDB von Amazon verwenden.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) eine Anforderung zum Lesen eines Teils des Datensatzes (426, 428) empfangen und die Anforderung zum Lesen des Teils des Datensatzes, gemäß einigen Ausführungsformen der vorliegenden Offenbarung, lokal verarbeiten. Für den Leser ist zu erkennen, dass Anfragen zum Ändern (z. B. einer Schreiboperation) des Datensatzes (426, 428) zwar 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 Anfrage zum Lesen eines Teils des Datensatzes (426, 428) jedoch keine ähnliche Koordination zwischen den Speichersystemen (402, 404, 406) erfordert. So kann ein bestimmtes Speichersystem, das eine Leseanforderung erhält, die Leseanforderung lokal bedienen, indem es einen Teil des Datensatzes (426, 428) liest, der in den Speichergeräten des Speichersystems gespeichert ist, ohne synchrone Kommunikation mit anderen Speichersystemen im Pod. Bei Leseanforderungen, die von einem Speichersystem für einen replizierten Datensatz in einem replizierten Cluster empfangen werden, wird erwartet, dass in den allermeisten Fällen jegliche Kommunikation vermieden wird, zumindest wenn sie von einem Speichersystem empfangen werden, das innerhalb eines Clusters läuft, das ebenfalls nominell läuft. Solche Lesevorgänge sollten normalerweise einfach durch Lesen aus der lokalen Kopie eines geclusterten Datensatzes verarbeitet werden, ohne dass eine weitere Interaktion mit anderen Speichersystemen im Cluster erforderlich ist
  • Für den Leser ist zu erkennen, dass die Speichersysteme Schritte unternehmen können, um Lesekonsistenz zu gewährleisten, so dass eine Leseanforderung das gleiche Ergebnis liefert, unabhängig davon, welches Speichersystem die Leseanforderung verarbeitet. Beispielsweise sollte der resultierende Inhalt des geclusterten Datensatzes für jeden Satz von Aktualisierungen, die von einem beliebigen Satz von Speichersystemen im Cluster empfangen werden, im gesamten Cluster konsistent sein, zumindest zu jedem Zeitpunkt, an dem Aktualisierungen im Ruhezustand sind (alle vorherigen Änderungsvorgänge 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 eine Reihe von Speichersystemen hinweg nur aufgrund von noch nicht abgeschlossenen Aktualisierungen unterscheiden. Das bedeutet beispielsweise, dass zwei Schreibanforderungen, die sich in ihrem Volume-Blockbereich überschneiden, oder eine beliebige Kombination aus einer Schreibanforderung und einer überlappenden Snapshot-, Compare-and-Write- oder Virtual-Block-Range-Kopie, auf allen Kopien des Datasets ein konsistentes Ergebnis liefern müssen. Zwei Operationen sollten nicht ein Ergebnis liefern, als ob sie in einer Reihenfolge auf einem Speichersystem und in einer anderen Reihenfolge auf einem anderen Speichersystem im replizierten Cluster stattgefunden hätten.
  • Darüber hinaus können Leseanforderungen in zeitlicher Reihenfolge konsistent gemacht werden. Wenn beispielsweise eine Leseanforderung auf einem replizierten Cluster empfangen und abgeschlossen wird und auf diese Leseanforderung 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 zeitlich und im Volumenadressbereich mit einer Änderungsanforderung überschneiden, die von dem replizierten Cluster empfangen wird (unabhängig davon, ob die Leseanforderungen oder die Änderung von demselben Speichersystem oder einem anderen Speichersystem in dem replizierten Cluster empfangen werden), dann - wenn der erste Lesevorgang das Ergebnis der Aktualisierung widerspiegelt - sollte der zweite Lesevorgang ebenfalls die Ergebnisse dieser Aktualisierung widerspiegeln, anstatt möglicherweise Daten zurückzugeben, die der Aktualisierung vorausgingen. Wenn der erste Lesevorgang die Aktualisierung nicht widerspiegelt, kann der zweite Lesevorgang entweder die Aktualisierung widerspiegeln oder nicht. Dadurch wird sichergestellt, dass zwischen zwei Leseanforderungen die „Zeit“ für ein Datensegment nicht rückwärtslaufen kann.
  • In dem in 4A gezeigten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme erkennen und bestimmen, ob das jeweilige Speichersystem im Pod verbleiben soll. Eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme kann aus einer Vielzahl von Gründen auftreten. Beispielsweise kann eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme auftreten, weil eines der Speichersysteme ausgefallen ist, weil eine Netzwerkverbindung ausgefallen ist oder aus einem anderen Grund. Ein wichtiger Aspekt des synchronen replizierten Clustering ist die Sicherstellung, dass die Fehlerbehandlung nicht zu nicht wiederherstellbaren Inkonsistenzen oder inkonsistenten Antworten führt. Wenn beispielsweise ein Netzwerk zwischen zwei Speichersystemen ausfällt, kann höchstens eines der Speichersysteme die Verarbeitung neu eingehender E/A-Anfragen für einen Pod fortsetzen. Und wenn ein Speichersystem die Verarbeitung fortsetzt, kann das andere Speichersystem keine neuen Anforderungen bis zum Abschluss verarbeiten, einschließlich Leseanforderungen.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch bestimmen, ob das jeweilige Speichersystem als Reaktion auf das Erkennen einer Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme im Pod verbleiben soll. Wie vorstehend erwähnt, muss ein Speichersystem, um als Teil eines Pods „online“ zu sein, sich selbst als synchronisiert für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als synchronisiert für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es synchronisiert ist und mit allen anderen Speichersystemen kommuniziert, die synchronisiert sind, kann es die Verarbeitung neuer eingehender Anfragen zum Zugriff auf den Datensatz stoppen (426, 428). Als solches kann das Speichersystem bestimmen, ob das bestimmte Speichersystem als Teil des Pods online bleiben soll, z. B. indem es bestimmt, ob es mit allen anderen Speichersystemen kommunizieren kann, die es für den Pod als synchron betrachtet (z. B. über eine oder mehrere Testnachrichten), indem es feststellt, ob alle anderen Speichersysteme, die es als synchron für den Pod betrachtet, das Speichersystem auch als an den Pod angeschlossen betrachten, durch eine Kombination beider Schritte, bei denen das bestimmte Speichersystem bestätigen muss, dass es mit allen anderen Speichersystemen, die es als synchron für den Pod betrachtet, kommunizieren kann und dass alle anderen Speichersysteme, die es als synchron für den Pod betrachtet, das Speichersystem ebenfalls als an den Pod angeschlossen betrachten, oder durch einen anderen Mechanismus.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) den Datensatz auf dem bestimmten Speichersystem auch für Verwaltungs- und Datensatzoperationen zugänglich halten, wenn festgestellt wird, dass das bestimmte Speichersystem im Pod bleiben soll. Das Speichersystem kann den Datensatz (426, 428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen zugänglich halten, z. B. indem es Anfragen zum Zugriff auf die Version des Datensatzes (426, 428), die auf dem Speichersystem gespeichert ist, annimmt und solche Anfragen verarbeitet, durch Akzeptieren und Verarbeiten von Verwaltungsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem Host oder autorisierten Administrator ausgegeben werden, durch Akzeptieren und Verarbeiten von Verwaltungsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem der anderen Speichersysteme ausgegeben werden, oder auf eine andere Weise.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) jedoch den Datensatz auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen unzugänglich machen, wenn sie feststellen, dass das bestimmte Speichersystem nicht im Pod verbleiben soll. Das Speichersystem kann den Datensatz (426, 428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen unzugänglich machen, z. B. durch Zurückweisen von Anfragen zum Zugriff auf die Version des Datensatzes (426, 428), die auf dem Speichersystem gespeichert ist, durch Zurückweisen von Verwaltungsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem Host oder einem anderen autorisierten Administrator ausgegeben werden, durch Zurückweisen von Verwaltungsoperationen in Verbindung mit dem Datensatz (426, 428), die von einem der anderen Speichersysteme im Pod ausgegeben werden, oder auf eine andere Weise.
  • In dem in 4A 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 die Verwaltung 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 den Empfang einer Nachricht von dem einen oder mehreren der anderen Speichersysteme. Als Reaktion auf die Feststellung, dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme repariert wurde, kann das Speichersystem den Datensatz (426, 428) auf dem bestimmten Speichersystem für Verwaltungs- und Datensatzoperationen zugänglich machen, sobald das zuvor abgetrennte Speichersystem mit den Speichersystemen, die mit dem Pod verbunden blieben, neu synchronisiert wurde.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch vom Pod offline gehen, so dass das jeweilige Speichersystem keine Verwaltungs- und Datensatzoperationen mehr zulässt. Die dargestellten Speichersysteme (402, 404, 406) können vom Pod offline gehen, so dass das jeweilige Speichersystem aus einer Vielzahl von Gründen keine Verwaltungs- und Datensatzoperationen mehr zulässt. Beispielsweise können die dargestellten Speichersysteme (402, 404, 406) auch aufgrund eines Fehlers im Speichersystem selbst, aufgrund einer Aktualisierung oder einer anderen Wartung des Speichersystems, aufgrund von Kommunikationsfehlern oder aus vielen anderen Gründen vom Pod getrennt werden. In einem solchen Beispiel können die dargestellten Speichersysteme (402, 404, 406) anschließend den Datensatz auf dem jeweiligen Speichersystem aktualisieren, um alle Aktualisierungen des Datensatzes einzubeziehen, seit das jeweilige Speichersystem offline gegangen ist, und wieder mit dem Pod online gehen, so dass das jeweilige Speichersystem Verwaltungs- und Datensatzoperationen zulässt, wie in den nachstehenden Abschnitten zur Re-synchronisierung ausführlicher beschrieben wird.
  • In dem in 4A 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 der Vielzahl von Speichersystemen gehört, über die der Datensatz synchron repliziert wird. Ein solches Zielspeichersystem kann z. B. ein Backup-Speichersystem sein, ein Speichersystem, das den synchron replizierten Datensatz verwendet, usw. In der Tat kann die synchrone Replikation genutzt werden, um Kopien eines Datensatzes näher an einem 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 hinsichtlich ihrer Zuverlässigkeit sorgfältiger verwaltet werden oder mit externen Netzwerken für asynchrone Replikation oder Backup-Dienste verbunden sind.
  • In dem in 4A dargestellten Beispiel können die dargestellten Speichersysteme (402, 404, 406) auch einen Teil des Datensatzes identifizieren, der von keinem der anderen Speichersysteme asynchron in das Zielspeichersystem repliziert wird, und den Teil des Datensatzes, der von keinem der anderen Speichersysteme asynchron in das Zielspeichersystem repliziert wird, asynchron in das Zielspeichersystem replizieren, wobei die zwei oder mehr Speichersysteme den gesamten Datensatz gemeinsam in das Zielspeichersystem replizieren. Auf diese Weise kann die mit der asynchronen Replikation eines bestimmten Datensatzes verbundene Arbeit unter den Elementen eines Pods aufgeteilt werden, so dass jedes Speichersystem in einem Pod nur für die asynchrone Replikation einer Teilmenge eines Datensatzes an das Zielspeichersystem verantwortlich ist.
  • In dem in 4A dargestellten Beispiel können sich die dargestellten Speichersysteme (402, 404, 406) auch von dem Pod lösen, so dass das jeweilige Speichersystem, das sich von dem Pod löst, nicht mehr in der Menge der Speichersysteme enthalten ist, über die der Datensatz synchron repliziert wird. Wird beispielsweise das Speichersystem (404) in 4A von dem in 4A dargestellten Pod (430) abgetrennt, würde der Pod (430) nur noch Speichersysteme (402, 406) als die Speichersysteme enthalten, über die der Datensatz (426), der in dem Pod (430) enthalten ist, synchron repliziert wird. In einem solchen Beispiel könnte das Trennen des Speichersystems vom Pod auch das Entfernen des Datensatzes von dem bestimmten Speichersystem beinhalten, das vom Pod getrennt wurde. In Fortsetzung des Beispiels, bei dem das Speichersystem (404) in 4A von dem in 4A dargestellten Pod (430) getrennt wurde, könnte der Datensatz (426), der in dem Pod (430) enthalten ist, gelöscht oder anderweitig von dem Speichersystem (404) entfernt werden.
  • Für den Leser ist zu erkennen, dass es eine Reihe von einzigartigen Verwaltungsfunktionen gibt, die durch das Pod-Modell ermöglicht werden und die weiter unterstützt werden können. Außerdem führt das Pod-Modell selbst einige Probleme ein, die durch eine Implementierung adressiert werden können. Wenn z. B. ein Speichersystem für einen Pod offline ist, aber ansonsten läuft, z. B. weil eine Verbindung ausgefallen ist und sich ein anderes Speichersystem für den Pod in der Vermittlung durchgesetzt hat, besteht möglicherweise trotzdem der Wunsch oder die Notwendigkeit, auf den Datensatz des Offline-Pods auf dem Offline-Speichersystem zuzugreifen. Eine Lösung könnte sein, den Pod einfach in einem abgetrennten Modus zu aktivieren und den Zugriff auf den Datensatz zu ermöglichen. Diese Lösung kann jedoch gefährlich sein und dazu führen, dass die Metadaten und Daten des Pods viel schwieriger abzugleichen sind, wenn die Speichersysteme die Kommunikation wieder aufnehmen. Außerdem könnte es für Hosts immer noch einen separaten Pfad für den Zugriff auf das Offline-Speichersystem sowie auf die noch online befindlichen Speichersysteme geben. 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, die Volumes mit denselben Kennungen melden, und die Host-E/A-Treiber davon ausgehen, dass sie zusätzliche Pfade zu demselben Volume sehen. Dies kann zu einer ziemlich schädlichen Datenkorruption führen, da Lese- und Schreibzugriffe auf beide Speichersysteme nicht mehr konsistent sind, obwohl der Host dies annimmt. Eine Variante dieses Falles ist, dass in einer geclusterten Anwendung, z. B. einer geclusterten Datenbank mit gemeinsamem Speicher, die geclusterte Anwendung, die auf einem Host läuft, auf einem Speichersystem liest oder schreibt und dieselbe geclusterte Anwendung, die auf einem anderen Host läuft, auf dem „abgetrennten“ Speichersystem liest oder schreibt, wobei die beiden Instanzen der geclusterten Anwendung unter der Annahme miteinander kommunizieren, dass der Datensatz, den sie jeweils sehen, für abgeschlossene Schreibvorgänge vollständig konsistent ist. Da sie nicht konsistent sind, wird diese Annahme verletzt und der Datenbestand der Anwendung (z. B. die Datenbank) kann schnell beschädigt werden.
  • Eine Möglichkeit, beide Probleme zu lösen, besteht darin, dass ein Offline-Pod oder vielleicht ein Snapshot eines Offline-Pods auf einen neuen Pod mit neuen Volumes kopiert werden kann, die ausreichend neue Identitäten aufweisen, damit Host-E/A-Treiber und Cluster-Anwendungen die kopierten Volumes nicht mit den noch online befindlichen Volumes auf einem anderen Speichersystem verwechseln. Da jeder Pod eine vollständige Kopie des Datensatzes verwaltet, die zwar crashkonsistent ist, sich aber möglicherweise 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 mit dem Pod-Inhalt erforderlich sind, ist es ein einfaches Problem, eine virtuelle Kopie einiger oder aller Volumes oder Snapshots im Pod auf neue Volumes in einem neuen Pod zu erstellen. Bei der Implementierung eines Logical Extent Graphen müssen beispielsweise nur neue Volumes in einem neuen Pod definiert werden, die auf Grafen von Logical Extents des kopierten Pods verweisen, die mit den Volumes oder Snapshots des Pods verknüpft sind, wobei die Logical Extent Graphen als Kopie beim Schreiben markiert sind. Die neuen Volumes sollten als neue Volumes behandelt werden, ähnlich wie auf einen neuen Volumes kopierte Datei-Snapshots implementiert werden könnten. Volumes können denselben administrativen Namen aufweisen, wenn auch innerhalb eines neuen Pod-Namensraums. Sie sollten jedoch unterschiedliche zugrunde liegende Kennungen und unterschiedliche Kennungen für logische Einheiten von den ursprünglichen Volumes aufweisen.
  • In einigen Fällen kann es möglich sein, Techniken zur Isolierung von virtuellen Netzwerken zu verwenden (z. B. durch Erstellen eines virtuellen LANs im Fall von IP-Netzwerken oder eines virtuellen SANs im Fall von Fibre-Channel-Netzwerken), so dass die Isolierung von Volumes, die einigen Schnittstellen präsentiert werden, so gewährleistet werden kann, dass sie von Host-Netzwerkschnittstellen oder Host-SCSI-Initiator-Ports, die auch die Originalvolumes sehen könnten, nicht zugänglich sind. In solchen Fällen kann es sicher sein, die Kopien von Volumes mit denselben SCSI- oder anderen Speicherkennungen zu versehen wie die Originalvolumes. Dies könnte z. B. in Fällen genutzt werden, in denen die Anwendungen erwarten, einen bestimmten Satz von Speicherkennungen zu sehen, um ohne einen unangemessenen Aufwand bei der Neukonfiguration zu funktionieren.
  • Einige der hier beschriebenen Techniken könnten auch außerhalb eines aktiven Fehlerkontextes verwendet werden, um die Bereitschaft für die Behandlung von Fehlern zu testen. Bereitschaftstests (manchmal auch als „Fire Drills“ bezeichnet) sind üblicherweise 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 aktuellen Änderungen an Anwendungen, Datensätzen oder der Anlage berücksichtigen. Die Bereitschaftstests sollten den laufenden Produktionsbetrieb, einschließlich der Replikation, nicht beeinträchtigen. In vielen Fällen können die echten Operationen nicht auf der aktiven Konfiguration aufgerufen werden, aber eine gute Möglichkeit, sich dem anzunähern, ist die Verwendung von Speicheroperationen, um Kopien von Produktionsdatensätzen zu erstellen, und dies dann vielleicht mit der Verwendung von virtuellen Netzwerken zu koppeln, um eine isolierte Umgebung zu schaffen, die alle Daten enthält, die für die wichtigen Anwendungen als notwendig erachtet werden, die im Notfall erfolgreich wiederhergestellt werden müssen. Das Bereitstellen einer solchen Kopie eines synchron replizierten (oder sogar eines asynchron replizierten) Datensatzes innerhalb eines Standorts (oder einer Sammlung von Standorten), von dem erwartet wird, dass er einen Disaster-Recovery-Bereitschaftstest 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 Tool, da es dazu beiträgt, sicherzustellen, dass keine wichtigen Teile der Anwendungsdatensätze im Disaster-Recovery-Plan ausgelassen wurden. Falls erforderlich und praktikabel, könnte dies mit virtuellen isolierten Netzwerken gekoppelt werden, vielleicht mit einer isolierten Sammlung von physischen oder virtuellen Maschinen, um einem realen Disaster-Recovery-Übernahmeszenario so nahe wie möglich zu kommen. Das virtuelle Kopieren eines Pods (oder einer Gruppe von Pods) auf einen anderen Pod als Point-in-Time-Image der Pod-Datensätze erzeugt sofort einen isolierten Datensatz, der alle kopierten Elemente enthält und auf dem dann im Wesentlichen identisch mit den ursprünglichen Pods gearbeitet werden kann, sowie die Möglichkeit einer Isolierung auf einen einzelnen Standort (oder einige Standorte) getrennt vom ursprünglichen Pod. Außerdem sind dies schnelle Operationen, die einfach abgerissen und wiederholt werden können, so dass Tests beliebig oft wiederholt werden können.
  • Es könnten einige Verbesserungen vorgenommen werden, um weiter in Richtung perfekte Disaster-Recovery-Tests zu gelangen. Zum Beispiel könnten in Verbindung mit isolierten Netzwerken SCSI-Identitäten für logische Einheiten oder andere Arten von Identitäten in den Ziel-Pod kopiert werden, sodass die Testserver, virtuellen Maschinen und Anwendungen dieselben Identitäten sehen. Darüber hinaus könnte die administrative Umgebung der Server so konfiguriert werden, dass sie auf Anforderungen aus einem bestimmten virtuellen Satz von virtuellen Netzwerken reagiert, um auf Anforderungen und Operationen mit dem ursprünglichen Pod-Namen zu reagieren, so dass Skripte nicht die Verwendung von Testvarianten mit alternativen „Test“-Versionen von Objektnamen erfordern. Eine weitere Erweiterung kann in Fällen verwendet werden, in denen die hostseitige Serverinfrastruktur, die im Falle einer Notfall-Übernahme übernommen wird, während eines Tests verwendet werden kann. Dies schließt Fälle ein, in denen ein Disaster-Recovery-Rechenzentrum komplett mit alternativer Serverinfrastruktur bestückt ist, die in der Regel nicht verwendet wird, bis sie durch einen Notfall dazu angewiesen wird. Dazu gehören auch Fälle, in denen diese Infrastruktur für nicht-kritische Operationen verwendet wird (z. B. für die Ausführung von Analysen auf Produktionsdaten oder einfach zur Unterstützung der Anwendungsentwicklung oder anderer Funktionen, die zwar wichtig sind, aber bei Bedarf für kritischere Funktionen angehalten werden können). Insbesondere können Host-Definitionen und -Konfigurationen und die Server-Infrastruktur, die sie verwenden werden, so eingerichtet werden, wie sie für ein tatsächliches Disaster-Recovery-Übernahmeereignis sein werden, und als Teil der Disaster-Recovery-Übernahmetests getestet werden, wobei die getesteten Volumes mit diesen Host-Definitionen von der virtuellen Pod-Kopie aus verbunden werden, die verwendet wird, um einen Snapshot des Datenbestands zu erstellen. Aus Sicht der beteiligten Speichersysteme können diese für die Tests verwendeten Host-Definitionen und -Konfigurationen sowie die während der Tests verwendeten Volume-zu-Host-Verbindungskonfigurationen wiederverwendet werden, wenn ein tatsächliches Disaster-Recovery-Takeover-Ereignis ausgelöst wird, wodurch die Konfigurationsunterschiede zwischen der Testkonfiguration und der realen Konfiguration, die im Falle eines Disaster-Recovery-Takeovers verwendet wird, stark minimiert werden.
  • In einigen Fällen kann es sinnvoll sein, Volumes aus einem ersten Pod in einen neuen zweiten Pod zu verschieben, der nur diese Volumes enthält. Die Pod-Zugehörigkeit und die Hochverfügbarkeits- und Wiederherstellungseigenschaften können dann separat angepasst werden, und die Verwaltung der beiden resultierenden Pod-Datensätze kann dann voneinander isoliert werden. Ein Vorgang, der in die eine Richtung möglich ist, sollte auch in die andere Richtung möglich sein. An einem bestimmten Punkt kann es sinnvoll sein, zwei Pods zu einem zusammenzuführen, so dass die Volumes in jedem der beiden ursprünglichen Pods nun die Zugehörigkeit im Speichersystem sowie die Hochverfügbarkeits- und Wiederherstellungsmerkmale und -ereignisse gegenseitig verfolgen. Beide Vorgänge können sicher und ohne oder mit nur minimaler Unterbrechung der laufenden Anwendungen durchgeführt werden, indem Sie sich auf die in einem früheren Abschnitt beschriebenen Merkmale zum Ändern der Vermittlungs- oder Quorum-Eigenschaften für einen Pod verlassen. Bei der Vermittlung kann z. B. ein Vermittler für einen Pod geändert werden, mithilfe einer Sequenz, die aus einem Schritt besteht, bei dem jedes Speichersystem in einem Pod so geändert wird, dass es sowohl von einem ersten Vermittler als auch von einem zweiten Vermittler abhängig ist, und anschließend so geändert wird, dass es nur noch vom zweiten Vermittler abhängig ist. Wenn in der Mitte der Sequenz ein Fehler auftritt, können einige Speichersysteme sowohl vom ersten Vermittler als auch vom zweiten Vermittler abhängig sein, aber in keinem Fall führen Wiederherstellung und Fehlerbehandlung dazu, dass einige Speichersysteme nur vom ersten Vermittler und andere Speichersysteme nur vom zweiten Vermittler abhängig sind. Ein Quorum kann ähnlich gehandhabt werden, indem man vorübergehend von einem Gewinnen gegen sowohl ein erstes Quorum-Modell als auch ein zweites Quorum-Modell abhängig ist, um zur Wiederherstellung überzugehen. Dies kann zu einer sehr kurzen Zeitspanne führen, in der die Verfügbarkeit des Pods bei Fehlern von zusätzlichen Ressourcen abhängt, wodurch die potenzielle Verfügbarkeit reduziert wird, aber diese Zeitspanne ist sehr kurz und die Reduzierung der Verfügbarkeit ist oft sehr gering. Wenn bei der Vermittlung die Änderung der Vermittler-Parameter nur die Änderung des für die Vermittlung verwendeten Schlüssels ist und der verwendete Vermittlungsdienst derselbe ist, dann ist die potenzielle Verringerung der Verfügbarkeit sogar noch geringer, da sie jetzt nur noch von zwei Aufrufen desselben Dienstes im Gegensatz zu einem Aufruf dieses Dienstes abhängt, und nicht mehr von separaten Aufrufen zweier separater Dienste.
  • Der Leser wird feststellen, dass die Änderung des Quorum-Modells recht komplex sein kann. Es kann ein zusätzlicher Schritt erforderlich sein, bei dem die Speichersysteme am zweiten Quorum-Modell teilnehmen, aber nicht davon abhängen, dass sie in diesem zweiten Quorum-Modell gewinnen, worauf dann der Schritt folgt, auch vom zweiten Quorum-Modell abzuhängen. Dies kann notwendig sein, um der Tatsache Rechnung zu tragen, dass, wenn nur ein System die Änderung zur Abhängigkeit vom Quorum-Modell verarbeitet hat, es nie das Quorum gewinnen wird, da es nie eine Mehrheit geben wird. Mit diesem Modell zum Ändern der Hochverfügbarkeitsparameter (Vermittlungsbeziehung, Quorum-Modell, Übernahmepräferenzen) können wir ein sicheres Verfahren für diese Operationen erstellen, um einen Pod in zwei zu teilen oder zwei Pods zu einem zusammenzuführen. Dies erfordert möglicherweise das Hinzufügen einer weiteren Fähigkeit: das Verknüpfen eines zweiten Pods mit einem ersten Pod für die Hochverfügbarkeit, so dass, wenn zwei Pods kompatible Hochverfügbarkeitsparameter enthalten, der mit dem ersten Pod verknüpfte zweite Pod bei der Bestimmung und Initiierung von abtrennungsbezogenen Verarbeitungen und Operationen, Offline- und In-Sync-Zuständen sowie Wiederherstellungs- und Resynchronisierungsaktionen vom ersten Pod abhängen kann.
  • Für die Aufteilung eines Pods in zwei Pods, d. h. eine Operation zum Verschieben einiger Volumes in einen neu erstellten Pod, kann eine verteilte Operation gebildet werden, die wie folgt beschrieben werden kann: Es ist ein zweiter Pod zu bilden, in den eine Reihe von Volumes verschoben wird, die sich zuvor in einem ersten Pod befanden, es sind die Hochverfügbarkeitsparameter vom ersten Pod in den zweiten Pod zu kopieren, um sicherzustellen, dass sie für die Verknüpfung kompatibel sind, und er der zweite Pod ist mit dem ersten Pod zu verknüpfen für die Hochverfügbarkeit. Dieser Vorgang kann als 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 gar nicht stattfindet, wenn die Verarbeitung durch einen Fehler unterbrochen wird. Sobald alle synchronisierten Speichersysteme für die beiden Pods diesen Vorgang verarbeitet haben, können die Speichersysteme einen nachfolgenden Vorgang verarbeiten, der den zweiten Pod so ändert, dass er nicht mehr mit dem ersten Pod verbunden ist. Wie bei anderen Änderungen an den Hochverfügbarkeitsmerkmalen für einen Pod muss dazu zunächst jedes synchronisierte Speichersystem so geändert werden, dass es sich sowohl auf das vorherige Modell (das Modell mit der Hochverfügbarkeit ist mit dem ersten Pod verknüpft) als auch auf das neue Modell (das Modell, das seine eigene, jetzt unabhängige Hochverfügbarkeit darstellt) stützt. Im Fall von Vermittlung oder Quorum bedeutet dies, dass Speichersysteme, die diese Änderung verarbeitet haben, zunächst darauf angewiesen sind, dass für den ersten Pod eine Vermittlung oder ein Quorum erreicht wird, und zusätzlich darauf angewiesen sind, dass für den zweiten Pod eine neue separate Vermittlung (z. B. ein neuer Vermittlungsschlüssel) oder ein Quorum erreicht wird, bevor der zweite Pod nach einem Fehler, der eine Vermittlung oder einen Test auf Quorum erforderte, fortfahren kann. Wie bei der vorherigen Beschreibung der Änderung des Quorum-Modells kann ein Zwischenschritt die Speichersysteme so einstellen, dass sie am Quorum für den zweiten Pod teilnehmen, bevor der Schritt erfolgt, bei dem die Speichersysteme am Quorum für den zweiten Pod teilnehmen und von diesem abhängen. Sobald alle synchronisierten Speichersysteme die Änderung zur Abhängigkeit von den neuen Parametern für die Vermittlung oder das Quorum sowohl für den ersten als auch für den zweiten Pod verarbeitet haben, ist die Aufteilung abgeschlossen.
  • Das Verbinden eines zweiten Pods mit einem ersten Pod funktioniert im Wesentlichen umgekehrt. Zunächst muss der zweite Pod so angepasst werden, dass er mit dem ersten Pod kompatibel ist, indem er eine identische Liste von Speichersystemen und ein kompatibles Hochverfügbarkeitsmodell aufweist. Dies kann eine Reihe von Schritten beinhalten, wie sie an anderer Stelle in diesem Dokument beschrieben sind, um Speichersysteme hinzuzufügen oder zu entfernen oder um Vermittler- und Quorum-Modelle zu ändern. Je nach Implementierung kann es auch nur notwendig sein, eine identische Liste von Speichersystemen zu erreichen. Beim Joining wird auf jedem synchronisierten Speichersystem ein Vorgang verarbeitet, um den zweiten Pod mit dem ersten Pod für hohe Verfügbarkeit zu verbinden. Jedes Speichersystem, das diesen Vorgang verarbeitet, hängt dann vom ersten Pod für hohe Verfügbarkeit und dann vom zweiten Pod für hohe Verfügbarkeit ab. Sobald alle synchronisierten Speichersysteme für den zweiten Pod diesen Vorgang verarbeitet haben, verarbeiten die Speichersysteme jeweils einen nachfolgenden Vorgang, um die Verknüpfung zwischen dem zweiten und dem ersten Pod aufzuheben, die Volumes vom zweiten Pod in den ersten Pod zu migrieren und den zweiten Pod zu löschen. Der Host- oder Anwendungsdatensatz-Zugriff kann während dieser Vorgänge beibehalten werden, solange die Implementierung eine ordnungsgemäße Richtung der Host- oder Anwendungsdatensatz-Änderungs- oder Lesevorgänge auf das Volume nach Identität zulässt und solange die Identität entsprechend dem Speicherprotokoll oder Speichermodell beibehalten wird (z. B. solange die Kennungen der logischen Einheiten für Volumes und die Verwendung von Zielports für den Zugriff auf Volumes im Falle von SCSI beibehalten werden).
  • Das Migrieren eines Volumes zwischen Pods kann Probleme bereiten. Wenn die Pods über einen identischen Satz von synchronisierten Zugehörigkeitsspeichersystemen verfügen, kann es einfach sein: den Betrieb auf den zu migrierenden Volumes vorübergehend auszusetzen, die Kontrolle über den Betrieb dieser Volumes auf die Kontrollsoftware und -strukturen des neuen Pods zu übertragen und dann den Betrieb wieder aufzunehmen. Dies ermöglicht eine nahtlose Migration mit kontinuierlicher Betriebszeit für Anwendungen, abgesehen von der sehr kurzen Betriebsunterbrechung, vorausgesetzt, Netzwerk und Ports werden ordnungsgemäß zwischen den Pods migriert. Je nach Implementierung ist die Aussetzung des Betriebs möglicherweise gar nicht erforderlich oder so systemintern, dass die Aussetzung des Betriebs keine Auswirkungen hat. Das Kopieren von Volumes zwischen Pods mit unterschiedlichen In-Sync-Membership-Sets ist eher ein Problem. Wenn der Ziel-Pod für die Kopie eine Teilmenge der synchronen Elemente des Quell-Pods aufweist, ist dies kein großes Problem: Ein Elementsspeichersystem kann sicher genug abgelegt werden, ohne dass mehr Arbeit anfällt. Wenn jedoch der Ziel-Pod dem Volume über den Quell-Pod synchronisierte Elementsspeichersysteme hinzufügt, müssen die hinzugefügten Speichersysteme synchronisiert werden, um den Inhalt des Volumes aufzunehmen, bevor sie verwendet werden können. Solange sie nicht synchronisiert sind, unterscheiden sich die kopierten Volumes deutlich von den bereits synchronisierten Volumes, da die Fehlerbehandlung unterschiedlich ist und die Bearbeitung von Anfragen von den noch nicht synchronisierten Elementsspeichersystemen entweder nicht funktioniert oder weitergeleitet werden muss oder nicht so schnell ist, da Lesevorgänge eine Zusammenschaltung durchlaufen müssen. Außerdem muss die interne Implementierung damit umgehen, dass einige Volumes synchronisiert und für die Fehlerbehandlung bereit sind und andere nicht synchronisiert sind.
  • Es gibt weitere Probleme in Bezug auf die Zuverlässigkeit des Vorgangs angesichts von Fehlern. Die Koordination einer Migration von Volumes zwischen Pods mit mehreren Speichersystemen ist ein dezentraler Vorgang. Wenn Pods die Einheit für Fehlerbehandlung und Wiederherstellung sind und wenn Vermittlung oder Quorum oder welche Mittel auch immer verwendet werden, um Split-Brain-Situationen zu vermeiden, dann erfolgt ein Wechsel von Volumes von einem Pod mit einem bestimmten Satz von Zuständen und Konfigurationen und Beziehungen für Fehlerbehandlung, Wiederherstellung, Vermittlung und Quorum zu einem anderen Pod, dann müssen die Speichersysteme in einem Pod sorgfältig auf die Koordinierung von Änderungen in Bezug auf diese Handhabung von allen Volumes achten. Operationen können nicht atomar zwischen den Speichersystemen verteilt werden, sondern müssen auf irgendeine Weise gestaffelt werden. Vermittlungs- und Quorum-Modelle stellen Pods im Wesentlichen die Werkzeuge für die Implementierung verteilter transaktionaler Atomarität zur Verfügung, aber dies kann sich nicht auf Operationen zwischen Pods erstrecken, ohne die Implementierung zu erweitern.
  • Es soll das Beispiel betrachtet werden, dass selbst bei zwei Pods, die sich das gleiche erste und zweite Speichersystem teilen, eine einfache Migration eines Volumes von einem ersten Pod zu einem zweiten Pod erfolgt. Irgendwann stimmen sich die Speichersysteme ab, um zu definieren, dass sich das Volume nun im zweiten Pod und nicht mehr im ersten Pod befindet. Wenn es keinen inhärenten Mechanismus für transaktionale Atomarität zwischen den Speichersystemen für die beiden Pods gibt, könnte eine naive Implementierung das Volume im ersten Pod auf dem ersten Speichersystem und im zweiten Pod auf dem zweiten Speichersystem belassen, wenn ein Netzwerkfehler auftritt, der zu einer Fehlerbehandlung führt, um Speichersysteme von den beiden Pods zu trennen. Wenn die Pods getrennt bestimmen, welches Speichersystem das andere erfolgreich abtrennen kann, könnte das Ergebnis sein, dass dasselbe Speichersystem das andere Speichersystem für beide Pods abtrennen kann, in welchem Fall das Ergebnis der Wiederherstellung der Volume-Migration konsistent sein sollte, oder es könnte dazu führen, dass ein anderes Speichersystem das andere für die beiden Pods abtrennen kann. 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 das Volume im ersten Pod auf dem ersten Speichersystem und im zweiten Pod auf dem zweiten Speichersystem wiederhergestellt wird, wobei das Volume dann ausgeführt und an Hosts und Speicheranwendungen auf beiden Speichersystemen exportiert wird. Wenn stattdessen das zweite Speichersystem das erste Speichersystem für den ersten Pod und das erste Speichersystem das zweite Speichersystem für den zweiten Pod abtrennt, kann die Wiederherstellung dazu führen, dass das Volume vom ersten Speichersystem aus dem zweiten Pod und vom zweiten Speichersystem aus dem ersten Pod entfernt wird, was dazu führt, dass das Volume vollständig verschwindet. Wenn sich die Pods, zwischen denen ein Volume migriert wird, auf unterschiedlichen Speichersystemen befinden, können die Dinge sogar noch komplizierter werden.
  • Eine Lösung für diese Probleme kann die Verwendung eines Zwischen-Pods zusammen mit den zuvor beschriebenen Techniken zum Aufteilen und Verbinden von Pods sein. Dieser Zwischen-Pod kann niemals als sichtbare verwaltete Objekte dargestellt werden, die mit den Speichersystemen verbunden sind. In diesem Modell werden Volumes, die von einem ersten Pod in einen zweiten Pod verschoben werden sollen, zunächst mithilfe des zuvor beschriebenen Aufteilungsvorgangs vom ersten Pod in einen neuen Zwischen-Pod aufgeteilt. Die Speichersystem-Elemente für den Zwischen-Pod können dann so angepasst werden, dass sie mit der Zugehörigkeit der Speichersysteme übereinstimmen, indem je nach Bedarf Speichersysteme aus dem Pod hinzugefügt oder entfernt werden. Anschließend kann der Zwischen-Pod mit dem zweiten Pod verbunden werden.
  • Zur weiteren Erläuterung zeigt 4B Diagramme von Metadaten-Darstellungen, die als strukturierte Sammlung von Metadatenobjekten implementiert werden können, die zusammen ein logisches Volume von Speicherdaten oder einen Teil eines logischen Volumens in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung darstellen können. Die Metadaten-Darstellungen 451-50, 451-54 und 451-60 können in einem Speichersystem (451-06) gespeichert werden, und eine oder mehrere Metadaten-Darstellungen können für jedes von mehreren Speicherobjekten, wie z. B. Volumes oder Teile von Volumes, die in einem Speichersystem (451-06) gespeichert sind, erzeugt und gepflegt werden.
  • Während andere Arten von strukturierten Sammlungen der Metadatenobjekte möglich sind, können in diesem Beispiel Metadaten-Darstellungen als gerichteter azyklischer Graph (DAG) von Knoten strukturiert werden, wobei der DAG zur Aufrechterhaltung eines effizienten Zugriffs auf jeden beliebigen Knoten nach verschiedenen Methoden strukturiert und ausgeglichen werden kann. Beispielsweise kann ein DAG für eine Metadaten-Darstellung als eine Art B-Baum definiert und entsprechend als Reaktion auf Änderungen an der Struktur der Metadaten-Darstellung ausgeglichen werden, wobei Änderungen an der Metadaten-Darstellung als Reaktion auf Änderungen an oder Ergänzungen zu den zugrunde liegenden Daten, die durch die Metadaten-Darstellung dargestellt werden, auftreten können. Während es in diesem Beispiel der Einfachheit halber nur zwei Ebenen gibt, können sich in anderen Beispielen Metadaten-Darstellungen über mehrere Ebenen erstrecken und Hunderte oder Tausende von Knoten umfassen, wobei jeder Knoten eine beliebige Anzahl von Verknüpfungen zu anderen Knoten enthalten kann.
  • Ferner können in diesem Beispiel die Blätter einer Metadaten-Darstellung Pointer auf die gespeicherten Daten für ein Volume oder einen Teil eines Volumes enthalten, wobei eine logische Adresse oder ein Volume und ein Offset verwendet werden können, um einen oder mehrere Blattknoten zu identifizieren und durch die Metadaten-Darstellung zu navigieren, um einen oder mehrere Blattknoten zu erreichen, die auf gespeicherte Daten verweisen, die der logischen Adresse entsprechen. Beispielsweise kann ein Volume (451-52) durch eine Metadaten-Darstellung (451-50) dargestellt werden, die mehrere Metadatenobjektknoten (451-52, 451-52A-451-52N) enthält, wobei Blattknoten (451-52A-451-52N) Pointer auf entsprechende Datenobjekte (451-53A-451-53N, 451-57) enthalten. Datenobjekte können eine beliebige Größeneinheit von Daten innerhalb eines Speichersystems (451-06) sein. Beispielsweise können Datenobjekte (451-53A-451-53N, 451-57) jeweils ein Logical Extent sein, wobei Logical Extents eine bestimmte Größe aufweisen können, wie z. B. 1 MB, 4MB oder eine andere Größe.
  • In diesem Beispiel kann ein Snapshot (451-56) als Snapshot eines Speicherobjekts, in diesem Fall eines Volumes (451-52), erstellt werden, wobei zu dem Zeitpunkt, an dem der Snapshot (451-56) erstellt wird, die Metadaten-Darstellung (451-54) für den Snapshot (451-56) alle Metadatenobjekte für die Metadaten-Darstellung (451-50) für das Volume (451-52) enthält. Ferner kann als Reaktion auf die Erstellung des Snapshots (451-56) die Metadaten-Darstellung (451-54) als nur lesbar gekennzeichnet werden. Das Volume (451-52), das die Metadaten-Darstellung gemeinsam nutzt, kann jedoch weiterhin modifiziert werden, und während im Moment der Erstellung des Snapshotes die Metadaten-Darstellungen für das Volume (451-52) und den Snapshot (451-56) identisch sind, können die Metadaten-Darstellungen für das Volume (451-52) und den Snapshot (451-56) als Reaktion auf die Modifikationen divergieren und unterschiedlich werden, wenn Modifikationen an den dem Volume (451-52) entsprechenden Daten vorgenommen werden.
  • Wenn beispielsweise eine Metadaten-Darstellung (451-50) zur Darstellung eines Volumes (451-52) und eine Metadaten-Darstellung (451-54) zur Darstellung eines Snapshotes (451-56) gegeben ist, kann das Speichersystem (451-06) eine E/A-Operation empfangen, die auf Daten schreibt, die letztendlich in einem bestimmten Datenobjekt (451-53B) gespeichert sind, wobei auf das Datenobjekt (451-53B) durch einen Blattknoten-Pointer (451-52B) gezeigt wird, und wobei der Blattknoten-Pointer (451-52B) Teil beider Metadaten-Darstellungen (451-50, 451-54) ist. Als Reaktion auf den Schreibvorgang bleiben die Nur-Lese-Datenobjekte (451-53A-451-53N), auf die die Metadaten-Darstellung (451-54) verweist, unverändert, und der Pointer (451-52B) kann ebenfalls unverändert bleiben. Die Metadaten-Darstellung (451-50), die das aktuelle Volume (451-52) repräsentiert, wird jedoch modifiziert, um ein neues Datenobjekt einzuschließen, das die durch den Schreibvorgang geschriebenen Daten enthält, wobei die modifizierte Metadaten-Darstellung als Metadaten-Darstellung (451-60) dargestellt wird. Ferner kann der Schreibvorgang nur auf einen Teil des Datenobjekts (451-53B) gerichtet sein, und folglich kann das neue Datenobjekt (451-57) zusätzlich zum Inhalt für den Schreibvorgang eine Kopie der vorherigen Inhalte des Datenobjekts (451-53B) enthalten.
  • In diesem Beispiel wird als Teil der Verarbeitung des Schreibvorgangs die Metadaten-Darstellung (451-60) für das Volume (451-52) modifiziert, um einen bestehenden Metadaten-Objekt-Pointer (451-52B) zu entfernen und einen neuen Metadaten-Objekt-Pointer (451-58) einzuschließen, wobei der neue Metadaten-Objekt-Pointer (451-58) so konfiguriert ist, dass er auf ein neues Datenobjekt (451-57) zeigt, wobei das neue Datenobjekt (451-57) die durch den Schreibvorgang geschriebenen Daten speichert. Ferner enthält die Metadaten-Darstellung (451-60) für das Volume (451-52) weiterhin alle Metadatenobjekte, die in der vorherigen Metadaten-Darstellung (451-50) enthalten sind - mit Ausnahme des Metadaten-Objekt-Pointers (451-52B), der auf das Zieldatenobjekt verwiesen hat, wobei der Metadaten-Objekt-Pointer (451-52B) ferner auf das Nur-Lese-Datenobjekt (451-53B) verweist, das überschrieben worden wäre.
  • Auf diese Weise kann unter Verwendung von Metadaten-Darstellungen ein Volume oder ein Teil eines Volumes als Snapshot betrachtet oder als kopiert angesehen werden, indem Metadaten-Objekte erzeugt werden, ohne dass es zu einer tatsächlichen Duplizierung von Datenobjekten kommt - die Duplizierung von Datenobjekten kann aufgeschoben werden, bis eine Schreiboperation auf eines der Nur-Lese-Datenobjekte gerichtet wird, auf die die Metadaten-Darstellungen verweisen.
  • Mit anderen Worten, ein Vorteil der Verwendung einer Metadaten-Darstellung zur Darstellung eines Volumes ist, dass ein Snapshot oder eine Kopie eines Volumes erstellt werden kann und in konstanter Zeitfolge zugänglich ist, und zwar in der Zeit, die benötigt wird, um ein Metadaten-Objekt für den Snapshot oder die Kopie zu erstellen und einen Verweis für das Snapshot- oder Kopie-Metadaten-Objekt auf die vorhandene Metadaten-Darstellung für das Volume zu erstellen, der als Snapshot oder Kopie erstellt wird.
  • Als Beispiel kann eine virtualisierte Kopie per Verweis eine Metadaten-Darstellung in einer Weise verwenden, die der Verwendung einer Metadaten-Darstellung bei der Erstellung eines Snapshots eines Volumes ähnlich ist - wobei eine Metadaten-Darstellung für eine virtualisierte Kopie per Verweis oft einem Teil einer Metadaten-Darstellung für ein ganzes Volume entsprechen kann. Eine Beispielimplementierung von virtualisiertem Copy-by-Reference kann im Kontext eines virtualisierten Speichersystems erfolgen, in dem mehrere Blockbereiche innerhalb und zwischen Volumes 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 Metadaten-Darstellung gespeicherter Daten ermöglicht ein virtualisiertes Speichersystem, das insofern als Flash-freundlich angesehen werden kann, als es den Verschleiß des Flash-Speichers reduziert oder minimiert.
  • In einigen Beispielen können Logical Extents auf verschiedene Weise kombiniert werden, z. B. als einfache Sammlungen oder als logisch zusammenhängende Adressbereiche innerhalb eines größeren Logical Extents, der als eine Menge von Logical-Extent-Referenzen gebildet wird. Diesen größeren Kombinationen könnten auch Logical-Extent-Identitäten verschiedener Art gegeben werden, und sie könnten weiter zu noch größeren ein Logical Extents oder Sammlungen kombiniert werden. Ein Copy-on-Write-Status könnte für verschiedene Ebenen und je nach Implementierung auf unterschiedliche Weise gelten. Beispielsweise könnte ein Copy-on-Write-Status, der auf eine logische Sammlung von Logical-Extent-Sammlungen angewendet wird, dazu führen, dass eine kopierte Sammlung Verweise auf unveränderte Logical Extents beibehält und dass Copy-on-Write Logical Extents erstellt werden (durch Kopieren von Verweisen auf alle unveränderten gespeicherten Datenblöcke nach Bedarf), wenn nur ein Teil der Copy-on-Write logischen Sammlung geändert wird.
  • Deduplizierung, Volume-Snapshots oder Block-Range-Snapshots können in diesem Modell durch Kombinationen aus der Referenzierung gespeicherter Datenblöcke oder der Referenzierung von Logical Extents oder der Markierung von Logical Extents (oder identifizierter Sammlungen von Logical Extents) als Copy-on-Write implementiert werden.
  • Darüber hinaus können bei Flash-Speichersystemen gespeicherte Datenblöcke auf verschiedene Weise organisiert und gruppiert werden, während Sammlungen in Seiten geschrieben werden, die Teil größerer Löschblöcke sind. Eine eventuelle Garbage Collection von gelöschten oder ersetzten gespeicherten Datenblöcken kann das Verschieben von Inhalten, die in einer bestimmten Anzahl von Seiten gespeichert sind, an eine andere Stelle beinhalten, sodass ein gesamter Löschblock gelöscht und für die Wiederverwendung vorbereitet werden kann. Dieser Prozess der Auswahl physischer Flash-Seiten, ihrer eventuellen Migration und Garbage Collection und des anschließenden Löschens von Flash-Löschblöcken zur Wiederverwendung kann koordiniert, gesteuert oder durchgeführt werden durch den Aspekt eines Speichersystems, das auch Logical Extents, Deduplizierung, Komprimierung, Snapshots, virtuelles Kopieren oder andere Funktionen des Speichersystems handhabt, oder nicht. Ein koordinierter oder gesteuerter Prozess für die Auswahl von Seiten, die Migration von Seiten, das Garbage Collecting und das Löschen von Löschblöcken kann darüber hinaus verschiedene Eigenschaften der Zellen, Seiten und Löschblöcke des Flash-Speichers berücksichtigen, wie z. B. die Anzahl der Verwendungen, Alterungsprognosen, Anpassungen der Spannungspegel oder die Anzahl der Wiederholungsversuche, die in der Vergangenheit zur Wiederherstellung gespeicherter Daten erforderlich waren. Sie können auch Analysen und Vorhersagen für alle Flash-Speichervorrichtungen innerhalb des Speichersystems berücksichtigen.
  • Um mit diesem Beispiel fortzufahren, bei dem ein Speichersystem auf der Grundlage von gerichteten azyklischen Graphen implementiert werden kann, die Logical Extents umfassen, können Logical Extents in zwei Typen kategorisiert werden: Leaf Logical Extents , die auf irgendeine Weise auf eine Menge gespeicherter Daten verweisen, und Composite Logical Extents, die auf andere Leaf Logical Extents oder Composite Logical Extents verweisen.
  • Ein Leaf Extent kann auf verschiedene Weise auf Daten verweisen. Er kann direkt auf einen einzelnen Bereich gespeicherter Daten verweisen (z. B. 64 Kilobyte Daten), oder er kann eine Sammlung von Verweisen auf gespeicherte Daten sein (z. B. ein 1-Megabyte-„Bereich“ von Inhalten, der eine bestimmte Anzahl von virtuellen Blöcken, die dem Bereich zugeordnet sind, auf physisch gespeicherte Blöcke abbildet). Im letzteren Fall können diese Blöcke über eine Identität referenziert werden, und einige Blöcke innerhalb des Bereichs des Umfangs können auf nichts abgebildet werden. Im letzteren Fall müssen diese Blockreferenzen auch nicht eindeutig sein, so dass mehrere Zuordnungen von virtuellen Blöcken innerhalb einer gewissen Anzahl von Logical Extents innerhalb und über eine gewisse Anzahl von Volumes hinweg auf dieselben physisch gespeicherten Blöcke abgebildet werden können. Anstelle von gespeicherten Blockreferenzen könnte ein Logical Extent einfache Muster kodieren: Ein Block, der eine Zeichenkette aus identischen Bytes ist, könnte zum Beispiel einfach kodieren, dass der Block ein wiederholtes Muster aus identischen Bytes ist.
  • Ein Composite Logical Extent kann ein logischer Inhaltsbereich mit einer gewissen virtuellen Größe sein, der eine Vielzahl von Zuordnungen umfasst, die jeweils von einem Teilbereich des Logical Extent des Composite Logical Extent des Inhalts auf ein darunter liegendes Leaf oder Composite Logical Extent abbilden. Das Transformieren einer Anforderung, die sich auf den Inhalt eines Composite Logical Extent bezieht, beinhaltet also, dass der Inhaltsbereich für die Anforderung im Kontext des Composite Logical Extent genommen wird, dass bestimmt wird, auf welche darunterliegenden Leaf oder Composite Logical Extent diese Anforderung abgebildet wird, und dass die Anforderung so transformiert wird, dass sie für einen geeigneten Inhaltsbereich innerhalb dieser darunterliegenden Leaf oder Composite Logical Extent gilt.
  • Volumes, aber auch Dateien oder andere Arten von Speicherobjekten, können als Composite Logical Extents beschrieben werden. Somit können diese vorgestellten Speicherobjekte mit diesem Extent-Modell organisiert werden.
  • Je nach Implementierung können Leaf oder Composite Logical Extents von einer Vielzahl anderer Composite Logical Extents referenziert werden, was effektiv eine kostengünstige Duplizierung größerer Sammlungen von Inhalten innerhalb und über Volumes hinweg ermöglicht. Auf diese Weise können Logical Extents im Wesentlichen innerhalb eines azyklischen Graphen von Referenzen angeordnet werden, die jeweils in Leaf Logical Extents enden. Dies kann verwendet werden, um Kopien von Volumes zu erstellen, um Snapshots von Volumes zu machen oder als Teil der Unterstützung von virtuellen Bereichskopien innerhalb und zwischen Volumes als Teil von EXTENDED COPY oder ähnlichen Arten von Operationen.
  • Eine Implementierung kann jeden Logical Extent mit einer Identität versehen, mit der er benannt werden kann. Dies vereinfacht die Referenzierung, da die Referenzen innerhalb Composite Logical Extents zu Listen werden, welche Logical-Extent-Identitäten und einen logischen Teilbereich umfassen, der jeder solchen Logical-Extent-Identitäten entspricht. Innerhalb von Logical Extents kann jede gespeicherte Datenblockreferenz auch auf einer Identität basieren, die zu seiner Benennung verwendet wird.
  • Um diese doppelten Verwendungen von Extents zu unterstützen, können wir eine weitere Fähigkeit hinzufügen: copy-on-write Logical Extents. Wenn eine modifizierende Operation eine Copy-on-Write-Leaf- oder Composite Logical Extent betrifft, wird der Logical Extent kopiert, wobei die Kopie eine neue Referenz ist und möglicherweise eine neue Identität aufweist (je nach Implementierung). Die Kopie behält alle Referenzen oder Identitäten, die sich auf die zugrundeliegenden Leaf Logical Extents oder Composite Logical Extents beziehen, jedoch mit den Modifikationen, die sich aus der modifizierenden Operation ergeben. Beispielsweise kann eine WRITE-, WRITE SAME-, XDWRITEREAD-, XPWRITE- oder COMPARE AND WRITE-Anforderung neue Blöcke im Speichersystem speichern (oder Deduplizierungsverfahren verwenden, um vorhandene gespeicherte Blöcke zu identifizieren), was dazu führt, dass die entsprechenden Leaf Logical Extents modifiziert werden, um Identitäten für einen neuen Satz von Blöcken zu referenzieren oder zu speichern, wobei möglicherweise Referenzen und gespeicherte Identitäten für einen früheren Satz von Blöcken ersetzt werden. Alternativ kann eine UNMAP-Anforderung einen Leaf Logical Extent modifizieren, um einen oder mehrere Blockreferenzen zu entfernen. In beiden Fällen wird ein Leaf Logical Extent modifiziert. Wenn der Leaf Logical Extent ein Copy-on-Write ist, wird ein neuer Leaf Logical Extent erstellt, der durch Kopieren von nicht betroffenen Blockreferenzen aus dem alten Bereich und anschließendes Ersetzen oder Entfernen von Blockreferenzen auf der Grundlage der Änderungsoperation gebildet wird.
  • Ein Composite Logical Extent, der zum Auffinden des Leaf Logical Extent verwendet wurde, kann dann geändert werden, um die neue Referenz oder Identität des Leaf Logical Extent zu speichern, die mit dem kopierten und geänderten Leaf Logical Extent als Ersatz für den vorherigen Leaf Logical Extent verbunden ist. Wenn dieser Composite Logical Extent beim Schreiben kopiert wird, wird ein neuer Composite Logical Extent als neue Referenz oder mit einer neuen Identität erstellt, und alle unbeeinflussten Referenzen oder Identitäten seiner zugrunde liegenden Logical Extents werden in diesen neuen Composite Logical Extent kopiert, wobei die vorherige Referenz oder Identität des Leaf Logical Extent durch die neue Referenz oder Identität des Leaf Logical Extent ersetzt wird.
  • Dieser Prozess setzt sich weiter rückwärts von einem referenzierten Extent zum referenzierenden Composite Extent fort, basierend auf dem Suchpfad durch den azyklischen Graphen, der verwendet wird, um die modifizierende Operation zu verarbeiten, wobei alle Copy-on-Write Logical Extents kopiert, modifiziert und ersetzt werden.
  • Diese kopierten logischen Leaf- und Composite Logical Extents können dann die Eigenschaft des Kopierens beim Schreiben verlieren, so dass weitere Änderungen nicht zu einer zusätzlichen Kopie führen. Wenn z. B. zum ersten Mal ein zugrunde liegender Logical Extent innerhalb eines „übergeordneten“ Logical Extent mit Kopieren beim Schreiben geändert wird, kann dieser zugrunde liegende Logical Extent kopiert und geändert werden, wobei die Kopie eine neue Identität erhält, die dann in eine kopierte und ersetzte Instanz des übergeordneten Composite Logical Extent geschrieben wird. Wenn jedoch ein zweites Mal ein anderer zugrunde liegender Logical Extent kopiert und modifiziert wird und die neue Identität dieser anderen Kopie des zugrunde liegenden Logical Extent in den übergeordneten Logical Extent geschrieben wird, kann der übergeordnete Bereich an Ort und Stelle modifiziert werden, ohne dass ein weiteres Kopieren und Ersetzen im Namen von Referenzen auf den übergeordneten Composite Logical Extent erforderlich ist.
  • Änderungsoperationen an neuen Bereichen eines Volumes oder eines Composite Logical Extent, für die es keinen aktuellen Logical Extent gibt, können einen neuen Logical Extent erstellen, um die Ergebnisse dieser Änderungen zu speichern. Wenn dieser neue Logical Extent von einem vorhandenen Copy-On-Write Composite Logical Extent referenziert werden soll, wird dieser vorhandene Copy-On-Write Composite Logical Extent modifiziert, um den neuen Logical Extent zu referenzieren, was zu einer weiteren Kopier-, Modifizier- und Ersetzungssequenz von Operationen führt, die der Sequenz für das Modifizieren eines vorhandenen Leaf Logical Extent ähnlich ist.
  • Wenn ein übergeordneter Composite Logical Extent nicht groß genug sein kann (je nach Implementierung), um einen zugehörigen Adressbereich abzudecken, der neue Leaf Logical Extents enthält, die für einen neuen Änderungsvorgang zu erstellen sind, dann kann der übergeordnete Composite Logical Extent in zwei oder mehr neue Composite Logical Extents kopiert werden, die dann von einem einzelnen „grandparent“ Composite Logical Extent referenziert werden, der wiederum eine neue Referenz oder eine neue Identität ist. Wenn dieser logische „grandparent“-Bereich selbst durch einen anderen Composite Logical Extent gefunden wird, der Copy-on-Write ist, dann wird dieser andere Composite Logical Extent kopiert und auf ähnliche Weise modifiziert und ersetzt, wie in den vorherigen Abschnitten beschrieben. Dieses Copy-on-Write-Modell kann als Teil der Implementierung von Snapshots, Volume-Kopien und Adressbereichskopien eines virtuellen Volumes innerhalb einer Speichersystem-Implementierung verwendet werden, die auf diesen gerichteten azyklischen Graphen von Logical Extents basiert. Um einen Snapshot als schreibgeschützte Kopie eines ansonsten beschreibbaren Volumes zu erstellen, wird ein Graph der Logical Extents, die mit dem Volume verbunden sind, als Copy-on-Write markiert und ein Verweis auf den ursprünglichen Composite Logical Extent wird vom Snapshot beibehalten. Modifizierende Operationen auf dem Volume erstellen dann bei Bedarf Kopien der Logical Extents, was dazu führt, dass das Volume die Ergebnisse dieser modifizierenden Operationen speichert und die Snapshots den ursprünglichen Inhalt beibehalten. Volume-Kopien sind ähnlich, mit dem Unterschied, dass sowohl das Original-Volume als auch das kopierte Volume Inhalte ändern können, was zu eigenen kopierten Logical Extent Graphen und Untergraphen führt.
  • Adressbereichskopien eines virtuellen Volumes können entweder durch das Kopieren von Blockreferenzen innerhalb und zwischen Leaf Logical Extents arbeiten (was selbst keine Copy-on-Write-Techniken erfordert, es sei denn, Änderungen an Blockreferenzen modifizieren Copy-on-Write-Leaf-Extents). Alternativ können virtuelle Volume-Adressbereichskopien Verweise auf Leaf Logical Extents oder Composite Logical Extents duplizieren, was für Volume-Adressbereichskopien von größeren Adressbereichen gut funktioniert. Außerdem können so Graphen zu gerichteten azyklischen Graphen von Referenzen werden und nicht nur zu Referenzbäumen. Copy-on-Write-Techniken, die mit duplizierten Verweisen auf Logical Extents verbunden sind, können verwendet werden, um sicherzustellen, dass Änderungsoperationen an der Quelle oder dem Ziel einer virtuellen Adressbereichskopie zur Erstellung neuer Logical Extents führen, um diese Änderungen zu speichern, ohne das Ziel oder die Quelle zu beeinflussen, die sich denselben Logical Extent unmittelbar nach der Volume-Adressbereichs-Kopieroperation teilen.
  • Eingabe-/Ausgabeoperationen für Pods können auch auf der Grundlage replizierender gerichteter azyklischer Graphen von Logical Extents implementiert werden. Beispielsweise könnte jedes Speichersystem innerhalb eines Pods private Graphen von Logical Extents implementieren, sodass die Graphen auf einem Speichersystem für einen Pod keine besondere Beziehung zu den Graphen auf einem zweiten Speichersystem für den Pod aufweisen. Es ist jedoch sinnvoll, die Graphen zwischen den Speichersystemen eines Pods zu synchronisieren. Dies kann für die Re-synchronisierung und für die Koordination von Funktionen wie die asynchrone oder Snapshot-basierte Replikation auf 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 kopierbezogenen Verarbeitungen zu reduzieren. In einem solchen Modell ist das Synchronisieren des Inhalts eines Pods über alle synchronisierten Speichersysteme für einen Pod im Wesentlichen dasselbe wie das Synchronisieren von Graphen von Leaf- und Composite Logical Extent für alle Volumes über alle synchronisierten Speichersysteme für den Pod und das Sicherstellen, dass der Inhalt aller Logical Extents synchronisiert ist. Um synchron zu sein, sollten übereinstimmende logischen Leaf- und Composite Logical Extents entweder die gleiche Identität oder zuordnungsfähige Identitäten aufweisen. Die Zuordnung könnte einen Satz von Zwischen-Mapping-Tabellen oder eine andere Art der Identitäts-Translation beinhalten. In einigen Fällen können auch die Identitäten von Blöcken, die von Leaf Logical Extents zugeordnet werden, synchron gehalten werden.
  • In einer Pod-Implementierung, die auf einem Leader und Followern basiert, mit einem einzigen Leader für jeden Pod, kann der Leader dafür zuständig sein, alle Änderungen an den Graphen der Logical Extents zu bestimmen. Wenn ein neues Leaf oder Composite Logical Extent erstellt werden soll, kann diesem eine Identität zugewiesen werden. Wenn ein vorhandener Leaf- oder Composite Logical Extent kopiert werden soll, um einen neuen Logical Extent mit Änderungen zu bilden, kann der neue Logical Extent als Kopie eines vorherigen Logical Extent mit einer Reihe von Änderungen beschrieben werden. Wenn ein bestehender Logical Extent aufgeteilt werden soll, kann die Aufteilung zusammen mit den neuen resultierenden Identitäten beschrieben werden. Wenn ein Logical Extent als zugrundeliegender Logical Extent von einem zusätzlichen Composite Logical Extent referenziert werden soll, kann diese Referenz als eine Änderung des Composite Logical Extent beschrieben werden, um diesen zugrundeliegenden Logical Extent zu referenzieren.
  • Das Ändern von Operationen in einem Pod umfasst daher das Verteilen von Beschreibungen von Änderungen an Logical Extents (wo neue Logical Extents erstellt werden, um den Inhalt zu erweitern, oder wo Logical Extents kopiert, geändert und ersetzt werden, um Copy-on-Write-Zustände im Zusammenhang mit Snapshots, Volume-Kopien und Volume-Adressbereichskopien zu handhaben) und das Verteilen von Beschreibungen und Inhalten für Änderungen am Inhalt von Leaf Logical Extents. Ein zusätzlicher Vorteil, der sich aus der Verwendung von Metadaten in Form von gerichteten azyklischen Graphen, wie vorstehend beschrieben, ergibt, ist, 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 gemacht 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 Solid-State-Laufwerk sein kann, kann der Verschleiß, der mit Modifikationen des Flash-Speichers einhergeht, vermieden oder reduziert werden, da E/A-Operationen durch die Modifikationen der Metadaten, die die Daten repräsentieren, auf die die E/A-Operationen abzielen, statt durch das Lesen, Löschen oder Schreiben des Flash-Speichers ausgeführt werden. Wie bereits erwähnt, können in einem solchen virtualisierten Speichersystem 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 Metadaten-Darstellung gespeicherter Daten ermöglicht ein virtualisiertes Speichersystem, das insofern als Flash-freundlich angesehen werden kann, als es den Verschleiß des Flash-Speichers reduziert oder minimiert.
  • Leader Speichersysteme können ihre eigenen lokalen Operationen durchführen, um diese Beschreibungen im Kontext ihrer lokalen Kopie des Pod-Datensatzes und der Metadaten des lokalen Speichersystems zu implementieren. Ferner führen die synchronisierten 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 Operationen des Leaders als auch die des Followers abgeschlossen sind, sind das Ergebnis kompatible Graphen von Logical Extents mit kompatiblen Inhalten der Leaf Logical Extents. Diese Graphen der Logical Extents 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 an Graphen können als separate Operationen innerhalb eines Satzes von oder auch mehreren Prädikaten beschrieben werden, die Beziehungen, wie z. B. Abhängigkeiten, mit einer oder mehreren anderen Operationen beschreiben können. Mit anderen Worten: Abhängigkeiten zwischen Operationen können als eine Menge von Vorläufern beschrieben werden, von denen eine Operation in irgendeiner Weise abhängt, wobei die Menge der Vorläufer als Prädikate betrachtet werden kann, die wahr sein müssen, damit eine Operation abgeschlossen werden kann. Eine ausführlichere Beschreibung der Prädikate findet sich in der Anmeldungsreferenz Nr. 15/696,418, die hier durch Bezugnahme in ihrer Gesamtheit enthalten ist. Alternativ kann jede modifizierende Operation, die sich auf eine bestimmte gleiche Graph-Transformation stützt, von der noch nicht bekannt ist, dass sie im gesamten Pod abgeschlossen ist, die Teile jeder Graph-Transformation enthalten, auf die sie sich stützt. Die Verarbeitung einer Operationsbeschreibung, die einen „neuen“ Leaf oder Composite Logical Extent identifiziert, der bereits existiert, kann die Erstellung des neuen Logical Extent vermeiden, da dieser Teil bereits in der Verarbeitung einer früheren Operation behandelt wurde, und kann stattdessen nur die Teile der Operationsverarbeitung implementieren, die den Inhalt von Leaf oder Composite Logical Extent ändern. Es ist eine Aufgabe des Leaders, sicherzustellen, dass die Transformationen miteinander kompatibel sind. Wir können zum Beispiel mit zwei Schreibvorgängen beginnen, die bei einem Pod ankommen. Ein erster Schreibvorgang ersetzt einen Composite Logical Extent A durch eine Kopie, die als Composite Logical Extent B gebildet wird, ersetzt einen Leaf Logical Extent C durch eine Kopie, die als Leaf Logical Extent D gebildet wird, und mit Modifikationen, um den Inhalt für den zweiten Schreibvorgang zu speichern, und schreibt weiter den Leaf Logical Extent D in den Composite Logical Extent B. Währenddessen impliziert ein zweiter Schreibvorgang dieselbe Kopie und Ersetzung des Composite Logical Extent A durch den Composite Logical Extent B, kopiert und ersetzt aber einen anderen Leaf Logical Extent E durch einen Logical Extent F, der modifiziert wird, um den Inhalt des zweiten Schreibvorgangs zu speichern, und schreibt weiter den Logical Extent F in den Logical Extent B. In diesem Fall kann die Beschreibung für den ersten Schreibvorgang die Ersetzung von A durch B und C durch D und das Schreiben von D in den Composite Logical Extent B sowie das Schreiben des Inhalts des ersten Schreibvorgangs in den Leaf Extent B umfassen; und die Beschreibung des zweiten Schreibvorgangs kann die Ersetzung von A durch B und E durch F und das Schreiben von F in den Composite Logical Extent B zusammen mit dem Inhalt des zweiten Schreibvorgangs, der in den Leaf Extent F geschrieben wird, umfassen. Ein Leader oder ein beliebiger Follower kann dann den ersten Schreibvorgang oder den zweiten Schreibvorgang in beliebiger Reihenfolge separat verarbeiten, und das Endergebnis ist B, das A kopiert und ersetzt, D, das C kopiert und ersetzt, F, das E ersetzt, und D und F werden in den Composite Logical Extent B geschrieben. Auf diese Weise kann ein Leader sicherstellen, dass der Pod kompatible gemeinsame Metadaten für einen Graphen einem Logical Extent über synchronisierte Speichersysteme für einen Pod aufrechterhält.
  • Bei einer Implementierung von Speichersystemen, die gerichtete azyklische Graphen von Logical Extents verwenden, kann die Wiederherstellung von Pods auf der Grundlage replizierter gerichteter azyklischer Graphen von Logical Extents implementiert werden. Insbesondere kann in diesem Beispiel die Wiederherstellung in Pods auf replizierten Graphen eines Logical Extent basieren und umfasst dann die Wiederherstellung der Konsistenz dieser Graphen sowie die Wiederherstellung des Inhalts von Leaf Logical Extents. In dieser Implementierung der Wiederherstellung können die Vorgänge die Abfrage nach Graph-Transformationen umfassen, von denen nicht bekannt ist, dass sie auf allen synchronisierten Speichersystemen für einen Pod abgeschlossen sind, sowie nach allen Inhaltsänderungen von Leaf Logical Extents, von denen nicht bekannt ist, dass sie auf allen Speichersystemen für den Pod abgeschlossen sind. Eine solche Abfrage könnte auf Operationen seit einem koordinierten Checkpoint basieren oder es könnte sich einfach um Operationen handeln, 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 gemeldet wurden. In diesem Beispiel sind Graph-Transformationen einfach: Eine Graph-Transformation kann neue Dinge erstellen, alte Dinge in neue Dinge kopieren und alte Dinge in zwei oder mehr geteilte neue Dinge kopieren, oder Composite Extents modifizieren, um ihre Referenzen auf andere Extents zu ändern. Jede gespeicherte Operationsbeschreibung, die auf einem synchronisierten Speichersystem gefunden wird und einen Logical Extent erzeugt oder ersetzt, kann kopiert und auf jedem anderen Speichersystem ausgeführt werden, das dieser Logical Extent noch nicht besitzt. Operationen, die Änderungen an Leaf Logical Extents oder Composite Logical Extents beschreiben, können diese Änderungen auf jedes synchronisierte Speichersystem anwenden, das sie noch nicht angewendet hat, solange die betroffenen Leaf Logical Extents oder Composite Logical Extent ordnungsgemäß wiederhergestellt wurden.
  • In einem anderen Beispiel, als Alternative zur Verwendung eines Logical Extent Graphen, kann die Speicherung auf der Basis eines replizierten inhaltsadressierbaren Speichers implementiert werden. In einem inhaltsadressierbaren Speicher wird für jeden Datenblock (z. B. alle 512 Byte, 4096 Byte, 8192 Byte oder sogar 16384 Byte) ein eindeutiger Hash-Wert (manchmal auch als Fingerprint bezeichnet) auf der Grundlage des Blockinhalts berechnet, sodass ein Volume oder ein Extent-Bereich eines Volumes als eine Liste von Verweisen auf Blöcke mit einem bestimmten Hash-Wert beschrieben werden kann. In einer synchron replizierten Speichersystem-Implementierung, die auf Referenzen auf Blöcke mit demselben Hash-Wert basiert, könnte das Replizieren 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 einem oder mehreren zusätzlichen Speichersystemen als Updates der Figur von Volume-Blöcken auf referenzierte Blöcke bereitstellt. Wenn festgestellt wird, 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 eine Kennung für die Referenz entweder identisch ist oder leicht abgebildet werden kann). Alternativ kann, wenn ein Block vom ersten Speichersystem nicht gefunden wird, 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 die anderen Speichersysteme bereitgestellt werden. Außerdem werden dann die Volume-Beschreibungen jedes synchronisierten Speichersystems mit den neuen Blockreferenzen aktualisiert. Die Wiederherstellung in einem solchen Speicher kann dann den Vergleich der kürzlich aktualisierten Blockreferenzen für ein Volume beinhalten. Wenn sich die Blockreferenzen zwischen verschiedenen synchronisierten Speichersystemen für ein Volume unterscheiden, kann eine Version jeder Referenz 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 Referenzen als Teil der Implementierung des virtuellen Kopiervorgangs kopiert werden.
  • Zur weiteren Erläuterung zeigt 5A ein Flussdiagramm, das Schritte veranschaulicht, die von Speichersystemen (5-402, 5-404, 5-406) durchgeführt werden können, die einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung tragen. Obwohl weniger detailliert dargestellt, können die in 5A dargestellten Speichersysteme (5-402, 5-404, 5-406) den vorstehend beschriebenen Speichersystemen oder einer beliebigen Kombination davon ähnlich sein. In der Tat können die in 5A dargestellten Speichersysteme (5-402, 5-404, 5-406) die gleichen oder weniger zusätzliche Komponenten wie die vorstehend beschriebenen Speichersysteme enthalten.
  • In dem in 5A dargestellten Beispielverfahren kann ein Speichersystem (5-402) einem Pod zugeordnet werden (5-508). Das Modell für die Pod-Zugehörigkeit kann eine Liste von Speichersystemen und eine Teilmenge dieser Liste enthalten, bei der davon ausgegangen wird, dass die Speichersysteme für den Pod synchronisiert sind. Ein Speichersystem ist für einen Pod synchronisiert, wenn mindestens eine Wiederherstellung des identischen Leerlaufinhalts für die letzte geschriebene Kopie des mit dem Pod verbundenen Datensatzes vorliegt. Leerlaufinhalt ist der Inhalt, nachdem alle laufenden Änderungen abgeschlossen wurden, ohne dass neue Änderungen verarbeitet wurden. Dies wird manchmal auch als „crash recoverable“-Konsistenz bezeichnet. Speichersysteme, die als Pod-Elemente aufgelistet sind, aber nicht als synchronisiert für den Pod aufgeführt sind, können als vom Pod „getrennt“ bezeichnet werden. Speichersysteme, die als Pod-Elemente aufgelistet sind, für den Pod synchronisiert sind und derzeit für die aktive Bereitstellung von Daten für den Pod zur Verfügung stehen, sind für den Pod „online“.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) an einen Pod (5-508) angeschlossen werden, indem es beispielsweise seine lokal gespeicherte Version des Datensatzes (5-426) mit einer aktuellen Version des Datensatzes (5-426) synchronisiert, die auf anderen Speichersystemen (5-404, 5-406) in dem Pod gespeichert ist, die online sind, gemäß der vorstehenden Beschreibung des Begriffs. In einem solchen Beispiel muss möglicherweise eine Pod-Definition, die lokal in jedem der Speichersysteme (5-402, 5-404, 5-406) im Pod gespeichert ist, aktualisiert werden, damit das Speichersystem (5-402) eine Verbindung (5-508) mit dem Pod herstellen kann. In einem solchen Beispiel kann jedes Speichersystem-Element eines Pods über eine eigene Kopie der Zugehörigkeit verfügen, einschließlich derjenigen Speichersysteme, von denen es zuletzt wusste, dass sie synchronisiert sind, und derjenigen Speichersysteme, von denen es zuletzt wusste, dass sie die gesamte Gruppe der Pod-Elemente umfassen.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch eine Anforderung zum Lesen eines Teils des Datensatzes (5-426) empfangen (5-510) und das Speichersystem (5-402) kann die Anforderung zum Lesen des Teils des Datensatzes (5-426) lokal verarbeiten (5-512). Für den Leser ist zu erkennen, dass Anfragen zum Ändern (z. B. ein Schreibvorgang) des Datensatzes (5-426) zwar eine Koordination zwischen den Speichersystemen (5-402, 5-404, 5-406) in einem Pod erfordern, da der Datensatz (5-426) über alle Speichersysteme (5-402, 5-404, 5-406) in einem Pod konsistent sein sollte, die Beantwortung einer Anfrage zum Lesen eines Teils des Datensatzes (5-426) jedoch keine ähnliche Koordination zwischen den Speichersystemen (5-402, 5-404, 5-406) erfordert. So kann ein bestimmtes Speichersystem (5-402), das eine Leseanforderung erhält, die Leseanforderung lokal bedienen, indem es einen Teil des Datensatzes (5-426) liest, der in den Speichergeräten des Speichersystems (5-402) gespeichert ist, ohne synchrone Kommunikation mit anderen Speichersystemen (5-404, 5-406) im Pod. Bei Leseanfragen, die von einem Speichersystem für einen replizierten Datensatz in einem replizierten Cluster empfangen werden, wird erwartet, dass in den allermeisten Fällen jegliche Kommunikation vermieden wird, zumindest wenn sie von einem Speichersystem empfangen werden, das innerhalb eines Clusters läuft, das ebenfalls nominell läuft. Solche Lesevorgänge sollten normalerweise einfach durch Lesen aus der lokalen Kopie eines geclusterten Datensatzes verarbeitet werden, ohne dass eine weitere Interaktion mit anderen Speichersystemen im Cluster erforderlich ist
  • Für den Leser ist zu erkennen, dass die Speichersysteme Schritte unternehmen können, um eine Lesekonsistenz zu gewährleisten, so dass eine Leseanforderung das gleiche Ergebnis liefert, unabhängig davon, welches Speichersystem die Leseanforderung verarbeitet. Beispielsweise sollte der resultierende Inhalt des geclusterten Datensatzes für jeden Satz von Aktualisierungen, die von einem beliebigen Satz von Speichersystemen im Cluster empfangen werden, im gesamten Cluster konsistent sein, zumindest zu jedem Zeitpunkt, an dem Aktualisierungen im Leerlauf sind (alle vorherigen Änderungsvorgänge 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 eine Reihe von Speichersystemen hinweg nur aufgrund von noch nicht abgeschlossenen Aktualisierungen unterscheiden. Das bedeutet beispielsweise, dass zwei Schreibanforderungen, die sich in ihrem Volume-Blockbereich überschneiden, oder eine beliebige Kombination aus einer Schreibanforderung und einer überlappenden Snapshot-, Compare-and-Write- oder Virtual-Block-Range-Kopie auf allen Kopien des Datasets ein konsistentes Ergebnis liefern müssen. Zwei Vorgänge können nicht ein Ergebnis liefern, als ob sie in einer Reihenfolge auf einem Speichersystem und in einer anderen Reihenfolge auf einem anderen Speichersystem im replizierten Cluster stattgefunden hätten.
  • Darüber hinaus können Leseanforderungen in der zeitlichen Reihenfolge konsistent sein. Wenn beispielsweise eine Leseanforderung auf einem replizierten Cluster empfangen und abgeschlossen wird und auf diese Leseanforderung 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 zeitlich und im Volumenadressbereich mit einer Änderungsanforderung überschneiden, die von dem replizierten Cluster empfangen wird (unabhängig davon, ob die Leseanforderungen oder die Änderung von demselben Speichersystem oder einem anderen Speichersystem in dem replizierten Cluster empfangen werden), sollte, wenn der erste Lesevorgang das Ergebnis der Aktualisierung widerspiegelt, der zweite Lesevorgang ebenfalls die Ergebnisse dieser Aktualisierung widerspiegeln, anstatt möglicherweise Daten widerspiegeln, die der Aktualisierung vorausgingen. Wenn der erste Lesevorgang die Aktualisierung nicht widerspiegelt, kann der zweite Lesevorgang entweder die Aktualisierung widerspiegeln oder nicht. Dadurch wird sichergestellt, dass zwischen zwei Leseanforderungen die „Zeit“ für ein Datensegment nicht rückwärtslaufen kann.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) erkennen (5-514). Eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) kann aus einer Vielzahl von Gründen auftreten. Beispielsweise kann eine Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) auftreten, weil eines der Speichersysteme (5-402, 5-404, 5-406) ausgefallen ist, weil eine Netzwerkverbindung ausgefallen ist oder aus einem anderen Grund. Ein wichtiger Aspekt des synchronen replizierten Clustering ist die Sicherstellung, dass die Fehlerbehandlung nicht zu nicht wiederherstellbaren Inkonsistenzen oder inkonsistenten Antworten führt. Wenn beispielsweise ein Netzwerk zwischen zwei Speichersystemen ausfällt, kann höchstens eines der Speichersysteme die Verarbeitung neu eingehender E/A-Anfragen für einen Pod fortsetzen. Und wenn ein Speichersystem die Verarbeitung fortsetzt, kann das andere Speichersystem keine neuen Anforderungen, einschließlich Leseanforderungen, bis zum Abschluss verarbeiten.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch bestimmen (5-516), ob das bestimmte Speichersystem (5-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 synchronisiert für den Pod betrachten und mit allen anderen Speichersystemen kommunizieren, die es als synchronisiert für den Pod betrachtet. Wenn ein Speichersystem nicht sicher sein kann, dass es synchronisiert ist und mit allen anderen Speichersystemen kommuniziert, die synchronisiert sind, kann es die Verarbeitung neuer eingehenden Anfragen zum Zugriff auf den Datensatz stoppen (5-426). Als solches kann das Speichersystem (5-402) bestimmen (5-516), ob das bestimmte Speichersystem (5-402) als Teil des Pods online bleiben soll, z. B. indem es bestimmt, ob es mit allen anderen Speichersystemen (5-404, 5-406), die es als synchronisiert für den Pod betrachtet, kommunizieren kann (z. B. über eine oder mehrere Testnachrichten), indem festgestellt wird, ob alle anderen Speichersysteme (5-404, 5-406), die es als synchronisiert für den Pod betrachtet, das Speichersystem (5-402) ebenfalls als an den Pod angeschlossen betrachten, durch eine Kombination beider Schritte, bei denen das bestimmte Speichersystem (5-402) bestätigen muss, dass es mit allen anderen Speichersystemen (5-404, 5-406) kommunizieren kann und dass alle anderen Speichersysteme (5-404, 5-406), die es als synchron für den Pod betrachtet, auch das Speichersystem (5-402) als an den Pod angeschlossen betrachten, oder durch ein anderes Verfahren.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch in Reaktion auf die bestätigende (5-518) Feststellung, dass das bestimmte Speichersystem (5-402) als Teil des Pods online bleiben sollte, den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen zugänglich halten (5-522). Das Speichersystem (5-402) kann den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen zugänglich halten (5-522), z. B. indem es Anfragen zum Zugriff auf die Version des Datensatzes (5-426), die auf dem Speichersystem (5-402) gespeichert ist, annimmt und solche Anfragen verarbeitet, durch Akzeptieren und Verarbeiten von Verwaltungsoperationen in Verbindung mit dem Datensatz (5-426), die von einem Host oder autorisierten Administrator ausgegeben werden, durch Akzeptieren und Verarbeiten von Verwaltungsoperationen in Verbindung mit dem Datensatz (5-426), die von einem der anderen Speichersysteme (5-404, 5-406) im Pod ausgegeben werden, oder auf eine andere Weise.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch als Reaktion auf die Feststellung, dass das bestimmte Speichersystem als Teil des Pods nicht online bleiben sollte (5-520), den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen unzugänglich machen (5-524). Das Speichersystem (5-402) kann den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen unzugänglich machen (5-524), zum Beispiel durch Zurückweisen von Anfragen zum Zugriff auf die Version des Datensatzes (5-426), die auf dem Speichersystem (5-402) gespeichert ist, durch Zurückweisen von Verwaltungsoperationen in Verbindung mit dem Datensatz (5-426), die von einem Host oder einem anderen autorisierten Administrator ausgegeben werden, durch Zurückweisen von Verwaltungsoperationen in Verbindung mit dem Datensatz (5-426), die von einem der anderen Speichersysteme (5-404, 5-406) im Pod ausgegeben werden, oder auf andere Weise.
  • In dem in 5A dargestellten Beispielverfahren kann das Speichersystem (5-402) auch erkennen (5-526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) repariert wurde. Das Speichersystem (5-402) kann erkennen (5-526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) repariert wurde, z. B. durch den Empfang einer Nachricht von dem einen oder mehreren der anderen Speichersysteme (5-404, 5-406). Als Reaktion auf die Feststellung (5-526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) repariert wurde, kann das Speichersystem (5-402) den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für die Verwaltung und Datensatzoperationen zugänglich machen (5-528).
  • Für den Leser ist zu erkennen, dass das in 5A dargestellte Beispiel eine Ausführungsform beschreibt, in der verschiedene Aktionen in einer bestimmten Reihenfolge dargestellt sind, obwohl keine Reihenfolge erforderlich ist. Darüber hinaus können andere Ausführungsformen existieren, bei denen das Speichersystem (5-402) nur eine Teilmenge der beschriebenen Aktionen ausführt. Beispielsweise kann das Speichersystem (5-402) die Schritte des Erkennens (5-514) einer Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406), des Bestimmens (5-516), ob das bestimmte Speichersystem (5-402) im Pod bleiben soll, des Zugänglichhaltens (5-522) des Datensatzes (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen oder das Unzugänglichmachen (5-524) des Datensatzes (5-426) auf dem bestimmten Speichersystem (5-402) für Verwaltungs- und Datensatzoperationen, ohne zuerst eine Anfrage zum Lesen eines Teils des Datensatzes (5-426) zu empfangen (5-510) und die Anfrage zum Lesen des Teils des Datensatzes (5-426) lokal zu verarbeiten (5-512). Darüber hinaus kann das Speichersystem (5-402) erkennen (5-526), dass die Unterbrechung der Datenkommunikation mit einem oder mehreren der anderen Speichersysteme (5-404, 5-406) behoben wurde, und den Datensatz (5-426) auf dem bestimmten Speichersystem (5-402) für die Verwaltungs- und Datensatzoperationen zugänglich machen (5-528), ohne zuerst eine Anforderung zum Lesen eines Teils des Datensatzes (5-426) zu empfangen (5-510) und die Anforderung zum lokalen Lesen des Teils des Datensatzes (5-426) zu verarbeiten (5-512). Tatsächlich ist keiner der hier beschriebenen Schritte in allen Ausführungsformen ausdrücklich als Voraussetzung für die Durchführung anderer hier beschriebener Schritte erforderlich.
  • Zur weiteren Erläuterung ist in 5B ein Flussdiagramm dargestellt, das Schritte veranschaulicht, die von Speichersystemen (5-402, 5-404, 5-406) durchgeführt werden können, die einen Pod gemäß einigen Ausführungsformen der vorliegenden Offenbarung aufnehmen. Obwohl weniger detailliert dargestellt, können die in 5B dargestellten Speichersysteme (5-402, 5-404, 5-406) den vorstehend unter Bezugnahme auf die 1A-1D, die 2A-2G, die 3A-3B, die 6A oder 6B oder einer beliebigen Kombination davon beschriebenen Speichersystemen ähnlich sein. Tatsächlich können die in 5B dargestellten Speichersysteme (5-402, 5-404, 5-406) die gleichen oder weniger zusätzliche Komponenten enthalten wie die vorstehend beschriebenen Speichersysteme.
  • In dem in 5B dargestellten Beispielverfahren können zwei oder mehr der Speichersysteme (5-402, 5-404) jeweils ein Zielspeichersystem (5-618) für das asynchrone Empfangen des Datensatzes (5-426) identifizieren (5-608). Das Zielspeichersystem (5-618) zum asynchronen Empfangen des Datensatzes (5-426) kann z. B. als Backup-Speichersystem, das sich in einem anderen Rechenzentrum befindet als eines der Speichersysteme (5-402, 5-404), die Elemente eines bestimmten Pods sind, als Cloud-Speicher, der von einem Cloud-Service-Anbieter bereitgestellt wird, oder auf viele andere Arten verkörpert werden. Für den Leser ist zu erkennen, dass das Zielspeichersystem (5-618) nicht zu der Vielzahl von Speichersystemen (5-402, 5-404) gehört, über die der Datensatz (5-426) synchron repliziert wird, und daher enthält das Zielspeichersystem (5-618) zunächst keine aktuelle lokale Kopie des Datensatzes (5-426).
  • In dem in 5B dargestellten Beispielverfahren können zwei oder mehr der Speichersysteme (5-402, 5-404) jeweils auch einen Teil des Datensatzes (5-426) identifizieren (5-610), der nicht asynchron zum Zielspeichersystem (5-618) durch eines der anderen Speichersysteme repliziert wird, die Elemente eines Pods sind, der den Datensatz (5-426) enthält. In einem solchen Beispiel können die Speichersysteme (5-402, 5-404) jeweils den Teil des Datensatzes (5-426), der nicht von einem der anderen Speichersysteme asynchron in das Zielspeichersystem repliziert wird, asynchron in das Zielspeichersystem replizieren (5-612). In einem Beispiel soll hier ein erstes Speichersystem (5-402) für die asynchrone Replikation eines ersten Teils (z. B. einer ersten Hälfte eines Adressraums) des Datensatzes (5-426) an das Zielspeichersystem (5-618) verantwortlich sein. In einem solchen Beispiel wäre das zweite Speichersystem (5-404) für die asynchrone Replikation eines zweiten Teils (z. B. einer zweiten Hälfte eines Adressraums) des Datensatzes (5-426) an das Zielspeichersystem (5-618) verantwortlich, so dass die zwei oder mehr Speichersysteme (5-402, 5-404) gemeinsam den gesamten Datensatz (5-426) an das Zielspeichersystem (5-618) replizieren.
  • Für den Leser ist zu erkennen, dass durch die Verwendung von Pods, wie vorstehend beschrieben, die Replikationsbeziehung zwischen zwei Speichersystemen von einer Beziehung, in der Daten asynchron repliziert werden, zu einer Beziehung, in der Daten synchron repliziert werden, umgestellt werden kann. Wenn beispielsweise Speichersystem A so konfiguriert ist, dass ein Datensatz asynchron auf Speichersystem B repliziert wird, kann durch das Erstellen eines Pods, der den Datensatz, Speichersystem A als Element und Speichersystem B als Element enthält, die Beziehung, in der Daten asynchron repliziert werden, auf eine Beziehung umgestellt 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, zu einer Beziehung, in der Daten asynchron repliziert werden, umges umgestellt werden. Wenn beispielsweise ein Pod erstellt wird, der den Datensatz, das Speichersystem A als Element und das Speichersystem B als Element enthält, kann durch einfaches Auflösen des Pods (um das Speichersystem A als Element oder das Speichersystem B als Element zu entfernen) eine Beziehung, in der Daten zwischen den Speichersystemen synchron repliziert werden, sofort in eine Beziehung umgestellt werden, in der Daten asynchron repliziert werden. Auf diese Weise können die Speichersysteme bei Bedarf zwischen asynchroner Replikation und synchroner Replikation hin- und herwechseln.
  • Dieser Wechsel kann dadurch erleichtert werden, dass die Implementierung auf ähnliche Techniken für synchrone und asynchrone Replikation zurückgreift. Wenn z. B. die Resynchronisierung für einen synchron replizierten Datensatz auf demselben oder einem kompatiblen Mechanismus beruht wie bei der asynchronen Replikation, dann ist der Wechsel zur asynchronen Replikation konzeptionell identisch mit dem Beenden des In-Sync-Zustands und dem Beenden eines Verhältnisses in einem Zustand, der einem „Perpetual Recovery“-Modus ähnelt. Ebenso kann das Umschalten von asynchroner Replikation auf synchrone Replikation konzeptionell erfolgen durch „Aufholen“ und Synchron werden, genau wie beim Abschluss einer Resynchronisierung, bei der das umschaltende System ein synchronisiertes Pod-Element wird.
  • Alternativ oder zusätzlich können, wenn sowohl die synchrone als auch die asynchrone Replikation auf ähnliche oder identische gemeinsame Metadaten oder ein gemeinsames Modell zur Darstellung und Identifizierung logischer Ausmaße oder gespeicherter Blockidentitäten oder ein gemeinsames Modell zur Darstellung inhaltsadressierbarer gespeicherter Blöcke zurückgreifen, diese Aspekte der Gemeinsamkeit genutzt werden, um den Inhalt, der beim Wechsel zwischen synchroner und asynchroner Replikation übertragen werden muss, drastisch zu reduzieren. Wenn 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, können ein gemeinsames Metadatenmodell, gemeinsame logische Erweiterungen oder Blockidentitäten oder eine gemeinsame Darstellung von inhaltsadressierbaren gespeicherten Blöcken die Datenübertragungen, die für eine synchrone Replikation zwischen Speichersystem A und Speichersystem C erforderlich sind, drastisch reduzieren.
  • Für den Leser ist ferner zu erkennen, dass durch die Verwendung von Pods, wie vorstehend beschrieben, Replikationsverfahren verwendet werden können, um andere Aufgaben als das Replizieren von Daten durchzuführen. Da ein Pod eine Reihe von verwalteten Objekten enthalten kann, können Aufgaben wie die Migration einer virtuellen Maschine mithilfe von Pods und den hier beschriebenen Replikationsverfahren durchgeführt werden. Wenn beispielsweise die virtuelle Maschine A auf dem Speichersystem A ausgeführt wird, können durch das Erstellen eines Pods, der die virtuelle Maschine A als verwaltetes Objekt, das 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, woraufhin der Pod einfach zerstört, die Zugehörigkeit aktualisiert oder andere erforderliche Aktionen durchgeführt werden können.
  • Zur weiteren Erläuterung veranschaulicht 6 ein konfigurierbares Replikationssystem, das eine kontinuierliche Replikation mit minimalem Batching und einem einstellbaren Wiederherstellungspunktziel bereitstellt. Im Gegensatz zu den vorstehend beschriebenen Beispiel-Speichersystemen, die die Verwendung von Pods bei der Implementierung einer synchronen Replikation beschreiben, werden in diesem Beispiel Pods für eine asynchrone oder nahezu synchrone Replikation verwendet.
  • Wie weiter unten beschrieben, kann das Replizieren zwar asynchron erfolgen, aber die effiziente Verwendung von Lightweight Journals, die auch als Metadatenprotokolle bezeichnet werden, ermöglicht einen kurzen, typischen Wiederherstellungspunkt (die Zeitdifferenz zwischen der letzten Aktualisierung auf einem Daten-Repository und dem Zeitwert des Daten-Repository, der mit dem letzten konsistenten Datensatz verbunden ist, der auf einem Zieldatenspeicher verfügbar ist), der in der Größenordnung von wenigen bis 50 oder 100 Millisekunden liegen kann, oder ein kurzes intrinsisches oder konfiguriertes Wiederherstellungspunktziel (RPO), wobei in einigen Fällen das RPO in der Größenordnung von einigen zehn Millisekunden bis zu einer bestimmten Anzahl von Minuten liegen kann. In einigen Beispielen kann die RPO-Grenze eher eine Funktion einer typischen maximalen Übertragungszeit sein. Zur Veranschaulichung: Der Erdmond ist etwas mehr als eine Lichtsekunde von der Erde entfernt, so dass bei ausreichender Bandbreite zur Vermeidung von Warteschlangenverzögerungen ein RPO zum Mond von 1,2 Sekunden mit einer Implementierung eines Lightweight-Journals möglich ist (das Empfangen einer Bestätigung vom Mond für die Primärseite zur Bestätigung des Wiederherstellungspunkts dauert mindestens weitere 1,2 Sekunden).
  • In einigen Implementierungen sorgt das konfigurierbare Replikationssystem für eine Notfallwiederherstellung nach einem Ausfall eines Daten-Repository auf der Grundlage eines Zieldatenspeichers, der in der Lage ist, Lese- und Schreibzugriff mit einer konsistenten Version des Daten-Repository als Reaktion auf den Ausfall des Daten-Repository bereitzustellen. Als Beispiel soll ein Satz von Uhrzeiten betrachtet werden, die mit einem Originaldatensatz verbunden sind, der gerade aktualisiert wird, wobei eine Quellzeit eine Uhrzeit für den Quelldatensatz darstellt und alle Aktualisierungen einschließt, die vor diesem Zeitpunkt als abgeschlossen für den Originaldatensatz signalisiert wurden, und alle Aktualisierungen ausschließt, die nach diesem Zeitpunkt zur Verarbeitung gegen den Datensatz empfangen wurden. In diesem Beispiel können alle Updates, die zum Quellzeitpunkt zur Verarbeitung im Dataset empfangen wurden, aber noch nicht als abgeschlossen signalisiert wurden, im Allgemeinen beliebig einbezogen oder ausgeschlossen werden, sofern keine transaktionalen Abhängigkeiten bestehen.
  • Darüber hinaus kann ein Snapshot einen solchen Quellzeitpunkt für einen Datensatz darstellen, während Rolling Lightweight Checkpoints eine Folge von Quellzeitpunkten für Datensätze darstellen können. Bei der Near-Sync-Replikation können Checkpoints angewendet werden, wenn sie eintreffen oder wenn sie vollständig bereit sind, angewendet zu werden. In einigen Beispielen repräsentiert ein Tracking-Datensatz daher immer einen replizierten Quell-Uhrzeitwert, der im Allgemeinen um einen gewissen Betrag hinter dem Quell-Uhrzeitwert des Live-Datensatzes liegt. In diesem Beispiel kann die Differenz zwischen dem Zeittaktwert des replizierten Datensatzes und dem Zeittaktwert des Live-Datensatzes als der aktuell verfügbare „Wiederherstellungspunkt“ gemeldet werden - der Abstand zwischen dem Zeittaktwert des replizierten Datensatzes und dem Zeittaktwert des Live-Datensatzes (obwohl Ausbreitungsverzögerungen wahrscheinlich bedeuten, dass weder Quelle noch Ziel genau wissen, wie groß dieser Zeitabstand ist).
  • In einigen Implementierungen können die Lightweight Journals eine Grundlage für die Implementierung einer kontinuierlichen Datensicherung sein - mit oder ohne Implementierung einer Datenreplikation. In einigen Beispielen bietet die kontinuierliche Datensicherung eine relativ fein abgestufte Versionsverwaltung eines Datensatzes für längere Zeiträume, um ein Rollback oder einen anderen Zugriff auf eine dieser fein abgestuften Versionen zu ermöglichen. Beispielsweise können diese Versionen untersucht werden, um festzustellen, wann ein Update oder eine Beschädigung aufgetreten ist, was ein Rollback oder einen anderen Zugriff (z. B. die Erstellung eines verwendbaren Snapshots oder Klons) auf die Version unmittelbar vor diesem Update ermöglicht. In manchen Fällen ist es sinnvoll, sowohl auf den Datensatz vor der Änderung/vor der Korruption als auch auf die aktuelleren Daten (oder sogar auf einen Satz von Zeitpunkten des Datensatzes vor oder seit dem Zeitpunkt der Aktualisierung/Korruption) zuzugreifen, damit andere Änderungen kopiert oder anderweitig abgeglichen werden können, oder zu Diagnosezwecken.
  • Bei der kontinuierlichen Datensicherung können Checkpoints eines Datensatzes bis zu einer bestimmten Grenze wiedergegeben werden, um ein konsistentes Abbild zu erstellen. In einigen Fällen können solche Checkpoints in einen Nur-Lese-Snapshot umgewandelt werden, oder der Datensatz kann auch geklont werden (oder der Nur-Lese-Snapshot kann geklont werden), um ein Lese-Schreib-Volume zu bilden, das für verschiedene Zwecke verwendet werden kann. In diesem Beispiel kann eine Implementierung der kontinuierlichen Datensicherung ein Volume klonen, um es an einen bestimmten Zeitpunkt anzupassen, es testen, um festzustellen, ob das Volume einige Daten oder eine Beschädigung enthält oder ausschließt, und dann, falls erforderlich, das Volume erneut klonen, um es an einen anderen Zeitpunkt anzupassen und das Volume erneut zu testen. Wenn in diesem Beispiel ein Zeitpunkt bestimmt wird, kann dieser Zeitpunkt als Grundlage für das Erstellen eines primären Volumes verwendet werden oder es werden einfach Daten aus dem Volume zu diesem Zeitpunkt kopiert.
  • Darüber hinaus kann die kontinuierliche Datensicherung in einigen Implementierungen einen granulareren Zugriff auf diese benannten Quellzeituhrwerte aus dem Quelldatensatz bieten, wobei die Granularität auf die Granularität der Checkpoints beschränkt ist. In einigen Fällen kann die kontinuierliche Datensicherung entweder lokal (die Checkpoints werden auf einem lokalen Speichersystem aufbewahrt und sind für den lokalen Zugriff verfügbar) oder auf einem Replikationsziel (die Checkpoints werden auf einem Replikationsziel aufbewahrt) oder beides sein, wobei beide möglicherweise unterschiedliche Aufbewahrungszeiträume und Modelle für das Zusammenführen von Checkpoints oder deren Umwandlung in Langzeit-Snapshots aufweisen.
  • In einigen Implementierungen kann ein „Pod“, wie der Begriff hier und in der gesamten vorliegenden Anwendung verwendet wird, als eine Verwaltungseinheit verkörpert werden, die einen Datensatz, einen Satz von verwalteten Objekten und Verwaltungsoperationen, einen Satz von Zugriffsoperationen zum Ändern oder Lesen des Datensatzes und eine Vielzahl von Speichersystemen darstellt. Solche Verwaltungsoperationen können verwaltete Objekte über ein Speichersystem mit entsprechendem Zugriff verändern oder abfragen. Jedes Speichersystem kann eine separate Kopie des Datensatzes als geeignete Teilmenge der gespeicherten und zur Verwendung durch das Speichersystem angekündigten Datensätze speichern, wobei Operationen zum Ändern von verwalteten Objekten oder des Datensatzes, die über ein beliebiges Speichersystem durchgeführt und abgeschlossen werden, in nachfolgenden Verwaltungsobjekten zum Abfragen des Pods oder nachfolgenden Zugriffsoperationen zum Lesen des Datensatzes abgebildet werden.
  • In einigen Implementierungen wird eine Replikationsbeziehung als ein Satz von Speichersystemen 602, 624 gebildet, die einen bestimmten Datensatz 612 zwischen unabhängigen Speichern replizieren, wobei jedes Speichersystem 602, 624 seine eigene Kopie und seine eigene separate interne Verwaltung relevanter Datenstrukturen zum Definieren von Speicherobjekten, zum Abbilden von Objekten auf physischen Speicher, zur Deduplizierung, zum Definieren der Abbildung von Inhalten auf Snapshots usw. aufweisen kann. Auf diese Weise kann ein Replikationssystem ein gemeinsames, gleiches oder ähnliches Verwaltungsmodell verwenden und sowohl für die synchrone Replikation als auch für die asynchrone Replikation ein gleiches oder ähnliches Implementierungsmodell und persistente Datenstrukturen verwenden.
  • Wie dargestellt, empfängt ein Quelldaten-Repository 602 Speichersystemoperationen 652 und kann mit einem Zieldaten-Repository 624 kommunizieren, um Replikatdaten zu erzeugen. In diesem Beispiel kann das Quelldaten-Repository 602 ähnlich wie die Rechenvorrichtung 350 oder ähnlich wie ein Speichersystem 100, 306, 318 sein, wie vorstehend mit Bezug auf die 1A-3D beschrieben. Während in 6 beispielhafte Systeme dargestellt sind, sind die in 6 dargestellten Komponenten nicht als vollständig oder einschränkend zu betrachten.
  • Wie vorstehend erwähnt, können eingehende Datenspeicheroperationen 652 vom Quelldaten-Repository 602 empfangen und verarbeitet werden, und die Datenspeicheroperationen, die ein Volume 658 aktualisieren oder modifizieren, oder allgemeiner, einen oder mehrere Datensätze modifizieren, können zum Zieldaten-Repository 624 gestreamt oder übertragen werden, wenn die Datenspeicheroperationen ankommen. Mit anderen Worten, das Quelldaten-Repository 602 kann als „aktiv“ betrachtet werden, da es Schreiboperationen und andere Operationen akzeptiert, die die gespeicherten Daten verändern können, während der Zieldaten-Repository 624 als „passiv“ betrachtet werden kann, da er zwar Leseoperationen, aber keine Speicheroperationen akzeptiert, die die gespeicherten Daten verändern können.
  • In diesem Beispiel unterhält das Quelldaten-Repository 602 ein Metadatenprotokoll 604, das als ein Journal der modifizierenden Datenspeicheroperationen, geordnet nach einem Checkpoint, bezeichnet werden kann. In einigen Fällen kann ein Journal äquivalent als ein Lightweight Journal bezeichnet werden, da das Journal nur Metadateninformationen, aber wenig oder keine von einem Benutzer bereitgestellten Speicherdaten enthält, die gespeichert werden sollen. In einigen Beispielen kann das Metadatenprotokoll 604 während eines Flushs von Speicherdaten aus dem NVRAM in einen Backend-Massenspeicher erzeugt oder aktualisiert werden - wobei eine Speichersystemarchitektur mit NVRAM und ein Beispiel für einen Backend-Massenspeicher vorstehend mit Bezug auf 2D beschrieben wurden. In einigen Beispielen können die Metadaten, wie z. B. Checkpoints 604, im Quelldaten-Repository 602 als Metadaten gespeichert werden, ohne in einer Journal- oder Metadatenprotokollstruktur enthalten zu sein, wobei das Journal oder Metadatenprotokoll 604 bei Bedarf erstellt werden kann, z. B. als Reaktion darauf, dass ein oder mehrere Checkpoints für die Übertragung an einen Zieldaten-Repository 624 bereit sind.
  • In einigen Implementierungen kann ein Checkpoint auch als ein geordneter „Lightweight Checkpoint“ eines Datensatzes bezeichnet werden. In einigen Beispielen, wie an anderer Stelle beschrieben, kann ein Checkpoint Metadaten enthalten, die einen Satz von Aktualisierungen beschreiben, wobei die Checkpoints jedoch nur auf die tatsächlichen Daten verweisen, die mit einem entsprechenden Satz von Aktualisierungen verbunden sind, indem sie Verweise darauf enthalten, wo die Daten für einen bestimmten Checkpoint im normalen Betriebsablauf des Speichersystems gespeichert werden. Ein gegebener Satz von Aktualisierungen kann damit beginnen, im NVRAM oder einer ersten Ebene des Speichers eines Speichersystems bereitgestellt zu werden, bevor der Satz von Aktualisierungen oder zumindest ein Teil dieser Aktualisierungen in den Sicherungsspeicher oder eine zweite Ebene des Speichersystems gespült wird.
  • In diesem Beispiel können die Daten, auf die ein Satz von Aktualisierungen innerhalb eines bestimmten Checkpoints verweist, logische Überschreibungen (oder Adressbereiche) und Garbage Collection überstehen und werden nicht in ein separates Metadaten-Journal dupliziert. Um ein vollständiges und konsistentes Abbild eines bestimmten Zeitpunkts des ursprünglichen Datensatzes zu erhalten, sollte jeder Satz von Aktualisierungen, die in jedem Lightweight Checkpoint zwischen einem früheren konsistenten Abbild und dem einem bestimmten Lightweight Checkpoint entsprechenden Zeitpunkt beschrieben sind, entweder angewendet werden, um dieses Abbild zu bilden, oder die Aktualisierung könnte sich als unnötig erweisen, z. B. aufgrund eines Überschreibens oder Löschens. In einigen Beispielen können Lightweight Checkpoints zusammengeführt werden, was vorteilhaft sein kann, da durch die Zusammenführung einige Daten des Sicherungsspeichers freigegeben werden können, die überschrieben oder gelöscht wurden, z. B. weil sie in einen früheren Checkpoint geschrieben und in einem späteren Checkpoint überschrieben wurden, der mit dem früheren zusammengeführt wird (in diesem Fall werden die Daten für den früheren Schreibvorgang möglicherweise nicht mehr benötigt), wodurch einige ansonsten gespeicherte Daten in den Müll geworfen werden können.
  • In Fortsetzung dieses Beispiels sollen solche Lightweight Checkpoints sehr feingranulare Konsistenzpunktzeitpunkte als Konsistenzpunkte darstellen, wobei jeder Lightweight Checkpoint einen Satz von Aktualisierungen enthält, die als abgeschlossen signalisiert wurden, einen Satz von Aktualisierungen ausschließt, deren Verarbeitung noch nicht begonnen hat, und möglicherweise Aktualisierungen einschließt oder ausschließt, die mit dem Zeitpunkt, den der Checkpoint darstellt, übereinstimmen. In einigen Beispielen kann die Bildung eines neuen Lightweight Checkpoint oder eine Dauer oder Periode zwischen zwei Checkpoints auf Zeitabschnitten basieren, wie z. B. alle paar Millisekunden, oder auf der Anzahl der Operationen, wie z. B. alle 50 bis 500 Aktualisierungsoperationen, oder auf der Übertragungsgröße oder einer komplexeren Beziehung zu Aktualisierungsoperationen. Sie können sich auch auf eine explizite Operation beziehen, z. B. auf eine Operation zur expliziten Kennzeichnung oder Benennung eines bestimmten Zeitpunkts, so dass später darauf verwiesen werden kann, z. B. durch ein Programm, das die Änderung bemerkt oder benachrichtigt wird, wenn sie vom Replikationsziel empfangen und angewendet wird, oder auf eine beliebige Kombination dieser und anderer Auslöser. Nach solchen Tags oder Namen könnte auch innerhalb einer kontinuierlichen Datensicherungsimplementierung gesucht werden.
  • In einigen Implementierungen unterscheiden sich Lightweight Checkpoints von Snapshots dadurch, dass sie die dauerhafte Struktur des Speichersystems nicht beeinflussen, abgesehen von den Garbage Collection- oder Overwrite Holds, und Lightweight Checkpoints können mit minimalen Auswirkungen verworfen werden, abgesehen von der Freigabe dieser Garbage Collection- oder Overwrite Holds. Darüber hinaus können Lightweight Checkpoints in einigen Fällen auch keine individuellen Verwaltungsabläufe aufweisen, vielleicht abgesehen von Lightweight Checkpoints, die explizit markiert oder benannt sind. In einigen Beispielen existieren Lightweight Checkpoints fast ausschließlich als geordnete Liste von Metadatenbündeln, die Aktualisierungen beschreiben, wobei die geordnete Liste von Metadaten in einer logähnlichen Struktur gespeichert sein kann. Darüber hinaus können Lightweight Checkpoints persistent oder nicht persistent sein, was zumindest von der beabsichtigten Verwendung des Lightweight Checkpoint abhängt. Insbesondere kann die fast-synchrone Replikation über Wiederherstellungsmechanismen für Abstürze oder Neusynchronisierung verfügen, die unabhängig von Lightweight Checkpoints funktionieren können und die dann keine Persistenz von Lightweight Checkpoint-Protokollen erfordern, während das Ziel der Replikation separat von der Persistenz von Checkpoints auf dem Zielspeichersystem zu Zwecken der Fehlerwiederherstellung profitieren kann, z. B. als Teil der atomaren Anwendung von Lightweight Checkpoints.
  • Wenn die Metadaten für einen Lightweight-Checkpoint Logical Composite und Leaf Extents repräsentieren, wie in früheren Patenten beschrieben, kann ein Lightweight-Checkpoint in einigen Implementierungen ein Satz von Beschreibungen zum Aktualisieren dieser Logical Composite und Leaf Extents sein, die selbst Metadatenbeschreibungen sind, welche gespeicherte Daten durch Content-Identifier-Referenzen referenzieren. In einigen Fällen kann die Verwendung von Content-Identifiern unabhängig von der Verwendung eines Extent-Modells auch insofern vorteilhaft sein, als eine solche Verwendung Informationen über Duplikate bewahrt und als Teil einer Strategie verwendet werden kann, um die Übertragung von Inhalten zu vermeiden, von denen bekannt ist, dass ein Zielspeichersystem sie bereits speichert. Zur weiteren Verdeutlichung umfassen diese früheren Patente die U.S. Patent Serial No. 16/050,385 , 62/598,989 und 15/842,850 , die hier für alle Zwecke einbezogen werden.
  • Um bei diesem Beispiel zu bleiben: Die Struktur einer Metadaten-Darstellung eines Datensatzes kann in einem Flash-Speichersystem besonders effektiv sein, da Flash kein Überschreiben auf Chipebene zulässt und im Allgemeinen auf einer gewissen Ebene durch Garbage-Collection-Algorithmen gesteuert werden kann, die eine Vielzahl von Referenzen berücksichtigen können, die auf geschriebene Daten Zugriff haben. In einigen Fällen können einige Details die NVRAM-Aspekte berücksichtigen, die nicht dem gleichen „Write-elsewhere-with-Garbage-Collection“-Modell folgen müssen, aber zumindest sind die Massendaten-Schreibvorgänge für Lightweight Checkpoints keine separaten Schreibvorgänge, die eine separate Speicherung erfordern.
  • In einigen Implementierungen und wie in anderen Abschnitten dieser Referenz beschrieben, können einige Anwendungen von Lightweight Checkpoints den normalen Betrieb der nahezu synchronen Replikation (im Gegensatz zur Initialisierung oder Re-synchronisierung) umfassen, die auch als asynchrone Replikation bezeichnet werden kann. In diesem Beispiel können Lightweight Checkpoints über eine Netzwerkverbindung an ein Ziel-Repository übertragen werden, das dann die Lightweight Checkpoints auf eine Tracking-Kopie des ursprünglichen Datensatzes anwenden kann, wobei Lightweight Checkpoints (und ihre referenzierten Daten) mindestens so lange gehalten werden, bis die Tracking-Kopie aktualisiert wurde.
  • In einigen Fällen, wenn Checkpoints in ungeordneter Reihenfolge empfangen oder angewendet werden, müssen alle Zwischen-Checkpoints empfangen und angewendet werden, bevor der Lightweight Checkpoint auf dem Quellsystem freigegeben werden kann. Im Allgemeinen sollten Lightweight Checkpoints atomar angewendet werden, z. B. mit Hilfe eines Transaktionsmechanismus. Ein Transaktionsmechanismus besteht darin, die Metadaten für einen Lightweight Checkpoint zu empfangen, den gesamten Dateninhalt für einen Lightweight Checkpoint zu empfangen und lokal auf dem Ziel zu speichern und dann die Nachverfolgungskopie vorwärts zu verschieben, um die Metadatenaktualisierungen in den Lightweight Checkpoint zu integrieren, wobei seine Datenreferenzen aktualisiert werden, um auf den lokal auf dem Ziel gespeicherten Dateninhalt zu verweisen.
  • Weitere Anwendungen von Lightweight Checkpoints können sein:
    • • In einigen Beispielen kann eine Tracking-Kopie in einen Snapshot oder einen Klon umgewandelt werden, um ein stabiles Image zu einem bestimmten Zeitpunkt bereitzustellen, wodurch die Verwendung eines Point-in-Time-Images für Testzwecke oder Failover-Zwecke ermöglicht wird;
    • • wenn in einigen Beispielen eine Quelle-Ziel-Verbindung und das Zielspeicher-Repository nicht annähernd mit der Geschwindigkeit Schritt halten, mit der das Quellspeichersystem selbst Daten empfängt, speichert und Lightweight Checkpoints bildet und überträgt, dann können diese Lightweight Checkpoints anfangen, sich aufzubauen. In diesem Szenario gibt es mehrere mögliche Reaktionen darauf: Lightweight Checkpoints könnten zusammengeführt werden, um ihre Kosten zu reduzieren (die mit benannten oder markierten Checkpoints verbundenen Quelldatensatz-Zeitpunkte könnten bevorzugt beibehalten werden); auf das Quellspeichersystem könnte Gegendruck ausgeübt werden, um die Rate zu reduzieren, mit der es Aktualisierungen empfängt, verarbeitet oder abschließt; eine Teilmenge der Checkpoints könnte in haltbarere Snapshots konvertiert werden; oder die auf Lightweight Checkpoints basierende Replikation könnte zugunsten einer Replikation auf Basis periodischer Snapshots verworfen werden. In manchen Fällen wird bereits eine gewisse Anzahl periodischer Snapshots für Resync- oder Verbindungsabbruch/Wiederaufbau aufbewahrt, so dass die Umstellung auf Snapshot-Replikation bereits voll einsatzbereit sein kann - was bedeutet, dass Lightweight Checkpoints seit dem letzten Snapshot einfach verworfen werden können, wenn das Replizieren nicht ausreichend Schritt hält, damit die Lightweight Snapshots nützlich sind (weitere Erläuterungen sind in dem US-Patent mit der Seriennummer 15/842,850 zu finden, die hier für alle Anwendungen einbezogen ist);
    • • in einigen Beispielen können Verbindungsabbrüche oder andere Arten von Unterbrechungen der Replikation im Allgemeinen durch das Umschalten auf ein anderes Schema, z. B. eine Snapshot-basierte Replikation, oder durch die Verwendung eines Resync-Modells ähnlich dem, das für die Wiederherstellung der synchronen Replikation beschrieben wurde, gehandhabt werden, allerdings ohne die Notwendigkeit, den ganzen Weg bis ganz zum Schluss aufzuholen;
    • • in einigen Beispielen kann die Datenübertragung von der Senderseite initiiert werden, indem einfach die referenzierten Daten zusammen mit den Aktualisierungen der Lightweight Checkpoint-Metadaten an das Zielspeichersystem gesendet werden. Außerdem kann die Datenübertragung stattdessen vom Zielspeichersystem initiiert werden: Wenn die Lightweight Checkpoint-Metadaten Inhaltskennungen auflisten, kann das Zielspeichersystem Verweise auf Inhalte, die es bereits speichert, wiederverwenden, aber dann den Abruf von Inhalten anfordern, die es derzeit nicht speichert. Dies kann die benötigte Gesamtbandbreite reduzieren, obwohl der Nutzen gering sein kann, wenn die Netzwerkverbindung für die Aktualisierungsrate dimensioniert werden muss; und
    • • wenn das Quellspeichersystem selbst Inhalte in Form von komprimierten Blöcken speichert, können in einigen Beispielen die komprimierten Blöcke in vielen Fällen direkt übertragen werden, anstatt sie zu entkomprimieren und dann möglicherweise erneut zu komprimieren, bevor sie über das Netzwerk übertragen werden.
  • In einigen Implementierungen können Lightweight Checkpoints verwendet werden, um eine kontinuierliche Datensicherung entweder auf dem ursprünglichen Speichersystem - mit oder ohne Replikation - oder auf einem Replikationszielsystem zu implementieren, indem die Lightweight Checkpoints auf dem Zielspeichersystem gespeichert werden, anstatt sie einfach anzuwenden und dann zu verwerfen. Bei der kontinuierlichen Datensicherung kann auf verschiedene Point-in-Time-Images eines Datensatzes zugegriffen werden, indem eine Kopie eines Datensatzes vorwärts gerollt wird, um alle Lightweight-Checkpoints bis zu dem Lightweight-Checkpoint einzuschließen, der einem bestimmten interessierenden Point-in-Time des Quelldatensatzes entspricht.
  • Wenn das Speichersystem z. B. auch dauerhafte Snapshots implementiert, müssen möglicherweise nur Lightweight Checkpoints seit dem Zeitpunkt des unmittelbar vorhergehenden Snapshots angewendet werden. Im Allgemeinen ist eine höhere Granularität für die jüngere Historie eines Datensatzes interessanter und eine geringere Granularität wird weiter zurück benötigt, so dass die Möglichkeit besteht, immer aggressivere Lightweight-Checkpoints zusammenzuführen, wenn die Zeitpunkte zurückgehen, oder sie schließlich zugunsten von weniger häufigen Snapshots zu verwerfen.
  • Wenn die kontinuierliche Datensicherung verwendet wird, um einen Zeitpunkt kurz vor dem Eintreten einer unerwünschten Änderung oder Beschädigung zu bestimmen, müssen relativ fein abgestufte Lightweight Checkpoints (Millisekunden bis wenige Sekunden oder alle paar Minuten) nur so lange aufbewahrt werden, bis genügend Zeit verstrichen ist, um sicherzustellen, dass die Beschädigung bemerkt und Wiederherstellungsvorgänge eingeleitet wurden. Danach sind 30-minütige oder stündliche oder sogar tägliche Snapshots möglicherweise vorzuziehen (oder solche Rollbacks werden als unnötig erachtet). Jeder bestimmte Lightweight Checkpoint kann in einen dauerhaften Snapshot umgewandelt werden, wenn Snapshots nicht explizit erstellt wurden. Wenn Lightweight Checkpoints benannt oder mit Tags versehen werden können, könnte die kontinuierliche Datensicherung das Auffinden und den Zugriff auf diese benannten Lightweight Checkpoints unterstützen.
  • In einigen Implementierungen kann, wie unten erwähnt, unter bestimmten Speichersystem-Bedingungen oder als Reaktion auf eine benutzerspezifische Konfiguration die nahezu synchrone Replikation auf einen anderen Replikationstyp umgestellt werden, einschließlich der periodischen Replikation oder der synchronen Replikation. Ferner kann in einigen Implementierungen ein Daten-Repository-System eine synchrone Replikation implementieren, die in einem Cluster von Speichersystemen Pod-basiert ist, wobei jedoch eines oder mehrere der Daten-Repository-Systeme auch Lightweight Checkpoints für eine nahezu synchrone Replikation mit einem Zielspeichersystem implementieren, die im Falle eines Kommunikationsfehlers mit dem anderen Speichersystem im Cluster von Speichersystemen initiiert werden können - wodurch das Quellspeichersystem sowohl die synchrone Datenreplikation über kurze Distanzen als auch die Datenausfallsicherheit über längere Distanzen aufrechterhalten kann. Darüber hinaus kann in einigen Beispielen RPO konfigurierbar sein, wobei die Zeit oder die Betriebsgröße der Lightweight Checkpoints zumindest auf der Grundlage der verfügbaren Netzwerkbandbreite oder der unterstützenden Ablaufsteuerung (wie vorstehend beschrieben) konfiguriert oder angepasst werden kann. In einigen Fällen, wenn ein Satz von synchron replizierenden Speichersystemen Checkpoint-Informationen zwischen ihnen als Teil ihres Betriebs austauscht, dann kann die nahezu synchrone Replikation von jedem der Speichersysteme, die die Checkpoint-Informationen synchron replizieren, betrieben und fortgesetzt werden, einschließlich der Fortsetzung nach dem Ausfall eines solchen Speichersystems, einschließlich der parallelen Übertragung von Daten und Metadaten von mehreren der synchron replizierenden Speichersysteme. Eine solche parallele Datenübertragung könnte beispielsweise beinhalten, dass das Ziel der nahezu synchronen Replikation Daten für referenzierte Composite oder Logical Extents oder Inhaltskennungen von einer beliebigen Menge oder Teilmenge der synchron replizierenden Speichersysteme anfordert.
  • In einigen Implementierungen wird die nahezu synchrone Replikation durch eine synchrone Replikation von Metadaten und Datenaktualisierungen über kurze Distanzen ergänzt, die mit einer nichtsynchronen Replikation von Lightweight Checkpoints über längere Distanzen kombiniert wird. In einem solchen Beispiel kann dies eine sogenannte „Bunker“-Replikation ermöglichen, bei der ein Speichersystem innerhalb der synchronen Replikationsdistanz so dimensioniert ist, dass es ausreichend Platz für In-Transit-Daten und Metadaten bietet, aber nicht so dimensioniert ist, dass es einen kompletten Datensatz speichern kann. Wenn in diesem Beispiel die primäre (vollständige) Kopie ausfällt, aber der dazwischenliegende „Bunker“-Speicher überlebt, kann das weiter entfernte nicht-synchrone Ziel durch Anwendung der Updates, die synchron auf dem Bunker-Speicher gespeichert wurden, aufgeholt werden. Wenn in diesem Beispiel sowohl der Primär- als auch der Bunker-Speicher ausfallen, ist zumindest der weiter entfernte Speicher konsistent und liegt innerhalb des RPO für die größere Entfernung. Um bei diesem Beispiel zu bleiben, können die Lightweight Checkpoints entweder vom Bunkerspeichersystem oder vom Primärspeichersystem gebildet und übertragen werden, oder sie können von einer Kombination aus Primärspeichersystem und Bunkerspeichersystem gebildet und übertragen werden.
  • In einigen Implementierungen kann ein Schema des Metadatenprotokolls 604 nach (Pod, Checkpoint) sortiert sein, was einen Durchgang in der richtigen Reihenfolge ermöglicht, wobei dasselbe Schema sowohl auf einem Quelldaten-Repository 602 als auch auf einem Zieldaten-Repository 624 verwendet werden kann. In diesem Beispiel kann eine Schreiboperation in einem Metadatenprotokoll 604 kodiert werden, indem sowohl eine physische Ausdehnungsidentifikation als auch Adressinformationen aller Schreibvorgänge für einen bestimmten Checkpoint angegeben werden. Darüber hinaus kann ein Metadatenprotokoll 604 in einigen Fällen Operationen zum Ändern einer Metadaten-Darstellung 614 des Datensatzes enthalten, die Systemoperationen entsprechen, wie z. B. Copy-on-Write (CoW). Änderungen an einer Metadaten-Darstellung 614 können beispielsweise Änderungen aufgrund von XCOPY, WSAME, Snapshots, CoW und anderen umfassen. Ein Beispiel für solche betriebsähnlichen Metadaten kann eine Abfolge von Aktualisierungen an Composite Logical Extents umfassen, wobei alle geschriebenen Inhalte, die an einen Checkpoint gebunden sind, mindestens so lange aufbewahrt werden, bis der Checkpoint nicht mehr für Replikationen oder andere Zwecke benötigt wird. In diesem Fall kann das Metadatenprotokoll die Aktualisierungen der logischen und Composite Logical Extent enthalten, einschließlich der Verweise auf alle gespeicherten Daten, wobei die gespeicherten Daten ein gespeicherter Verweis auf den Inhalt sind, der im Speichersystem für die reguläre Verwendung gespeichert ist, wobei jedoch jegliche Garbage Collection oder Überschreibung zurückgehalten wird, solange der Checkpoint beibehalten wird. Darüber hinaus kann in einigen Fällen das Überschreiben von Inhalten innerhalb eines Checkpoints (einschließlich innerhalb zusammengeführter Checkpoints, wenn das Zusammenführen von Checkpoints unterstützt wird) den gespeicherten Verweis auf die früheren Inhalte verwerfen, die durch spätere, vom Checkpoint beschriebene Inhalte ersetzt werden. In einigen Beispielen kann ein Metadatenprotokoll 604 Zuordnungs-Kennungen von Metadaten-Darstellungen 614 auf einem Quelldaten-Repository 602 enthalten, was es dem Zieldaten-Repository 624 ermöglicht, das Nachschlagen von Inhaltskennungen zu vermeiden, die nicht auf dem Zieldaten-Repository 624 existieren.
  • In verschiedenen Ausführungsformen kann die Lebensdauer der Checkpoint-Einträge 606a, 606b konfigurierbar sein, um verschiedene Optionen für die Datenwiederherstellung zu ermöglichen, einschließlich einer Lebensdauer, die sich über eine fortlaufende Länge von Storage-Diensten erstreckt, die eine kontinuierliche Datensicherung ermöglicht. In diesem Beispiel kann das konfigurierbare Replikationssystem eine kontinuierliche Replikation bereitstellen, bei der beim Eintreffen von Datenspeicheroperationen, die ein Volume oder einen Datensatz modifizieren, die Speicheroperationen in Checkpoints gruppiert werden, und bei der ein gegebener Checkpoint eine unterschiedliche Anzahl von Speicheroperationen enthalten kann. In einigen Beispielen kann ein bestimmter Checkpoint Metadaten für bis zu 100 Speicheroperationen enthalten. Da ein Garbage-Collection-Prozess gespeicherte Daten auf der Grundlage von Verweisen auf den Speicherort der gespeicherten Daten aufbewahren kann, die entweder durch allgemeine Speichersystemverweise innerhalb der allgemeinen Metadaten des Speichersystems oder durch ein Metadatenprotokoll, das Checkpoints enthält, referenziert werden, entspricht die Länge der Lebensdauer der Checkpoints einer Zeitspanne für ein Wiederherstellungsfenster zum kontinuierlichen Datenschutz.
  • In diesem Beispiel kann ein Checkpoint als kleinste Einheit der Datenkonsistenz betrachtet werden. Wenn das Metadatenprotokoll 626, das am Zieldaten-Repository 624 empfangen wird, einen bestimmten Checkpoint enthält, dann enthält ein Replikat-Volume 634, das durch die Wiedergabe der Speicheroperationen in dem bestimmten Checkpoint erzeugt wird, alle Speicheroperationen von allen Checkpoints, die vor dem bestimmten Checkpoint erzeugt wurden - und eine solche Richtlinie sorgt für einen absturzsicheren Wiederherstellungspunkt für das Replikat-Volume 634. Wenn es einen Snapshot gibt, der zu einem früheren Zeitpunkt als dem gewünschten Wiederherstellungspunkt erstellt wurde, werden bei einer Wiederherstellung möglicherweise nur die Checkpoints seit diesem Snapshot benötigt. In diesem Beispiel können Checkpoints zusammengeführt werden, um die Garbage Collection von überschriebenen Daten zu ermöglichen, und Checkpoints können auch periodisch in Snapshots konvertiert werden, wenn dies zu einem saubereren Format oder einer besseren oder einfacheren Beziehung zur Garbage Collection führt.
  • In einigen Implementierungen können Snapshots verwendet werden, um einen Zeitpunkt im Aktualisierungsstrom zu koordinieren. Eine Anwendung kann beispielsweise eine Aktualisierung vornehmen und dann eine Snapshot-Anforderung ausgeben. Wenn Snapshots eine Art von Aktualisierung sind, die repliziert wird, ist dieser Zeitpunkt für die Anwendung gegeben, wenn der Snapshot auf dem Zielspeichersystem erscheint. In diesem Beispiel könnte dies auf eine Art von Tag verallgemeinert werden, so dass ein Snapshot nicht unbedingt erforderlich ist. Wenn in diesem Beispiel ein Metadaten-Tag auf einen Datensatz oder auf eine Komponente innerhalb eines Datensatzes gesetzt wird und dieses Tag als eine Art von Update innerhalb des Protokoll-/Checkpoint-Modells behandelt wird, dann könnte ein Überwachungsprogramm auf dem Zielspeichersystem erkennen, wann dieser Zeitpunkt des Quelldatensatzes auf dem Ziel erreicht wurde, indem es das Auftreten des Tags bemerkt. Das Speichersystem könnte ferner ein Mittel zur Benachrichtigung von Programmen unterstützen, die auf solche Snapshots oder benannte oder markierte Checkpoints warten, die auf einem Zielspeichersystem empfangen und verarbeitet werden. Wenn das Zielspeichersystem solche Snapshots oder benannte oder markierte Checkpoints empfangen und verarbeitet hat, könnte es eine Benachrichtigung an das Quellspeichersystem zurücksenden, das dann wiederum interessierte Programme darüber informieren könnte, dass der Snapshot oder benannte oder markierte Checkpoint auf dem Zielsystem empfangen und verarbeitet wurde. In Fortsetzung dieses Beispiels könnte ein solcher Prozess z. B. von einem Programm verwendet werden, das auf dem Quellspeichersystem läuft, das einige Daten aktualisiert, einen Checkpoint markiert und dann eine Aktion ausführt, wenn es vom Quellspeichersystem benachrichtigt wird, dass der markierte Checkpoint (und damit die Aktualisierung) als repliziert bekannt ist. Zum Beispiel könnte eine High-Level-Task eine Reihe von Aktualisierungen durchführen, die repliziert werden, und bei denen die Aktion darin besteht, dass Aspekte der Fortsetzung erst nach Erhalt dieser Benachrichtigung erfolgen. In einigen Fällen ermöglicht dies wiederum, dass Tasks auf höherer Ebene über große Entfernungen hinweg effektiv synchron repliziert werden können, selbst wenn sie viele kleinere Operationen ausführen, die selbst nicht synchron repliziert werden. Eine Webanwendung könnte dies zum Beispiel nutzen, um sicherzustellen, dass eine angeforderte Aktualisierung, z. B. eines Benutzerprofils, über Entfernungen hinweg dauerhaft ist, bevor eine Webseite die dauerhafte Änderung des Benutzerprofils anzeigt.
  • Während in diesem Beispiel das Replizieren im Kontext der Replikation eines „Volumes“ beschrieben wird, können die beschriebenen Replikationsverfahren im Allgemeinen auf jeden verallgemeinerten Datensatz angewendet werden. Mit anderen Worten, im allgemeinen Fall gilt das Replizieren für einen Datensatz, der ein oder mehrere Volumes und/oder eine oder mehrere andere Arten von Daten oder Datensammlungen zu einem bestimmten Zeitpunkt umfassen kann. In einigen Fällen kann ein Datensatz ein durch einen Pod spezifizierter Datensatz sein, wobei sich in einem Pod der tatsächliche Satz von Volumes ändern kann, da Volumes zum Pod hinzugefügt und aus ihm entfernt werden, und das Tracking spiegelt dies durch Hinzufügen und Entfernen von Volumes wider. Darüber hinaus kann die kontinuierliche Datensicherung eines Pods in einigen Beispielen dazu führen, dass Volumes vorhanden oder nicht vorhanden sind, je nachdem, zu welchem Checkpoint wir zurück- oder vorwärts rollen, und je nach der Volume-Zugehörigkeit zum Quellzeitpunkt des Pods für diesen Checkpoint.
  • In Fortsetzung dieses Beispiels kann jeder eingehende Schreibvorgang wie vorstehend mit Bezug auf die 1A-3D beschrieben persistiert werden, wobei zusätzlich zur Aktualisierung des Quellvolumens 658 ein Verweis auf den Speicherort der Daten, die dem Schreibvorgang entsprechen, zum Metadatenprotokoll 604 hinzugefügt wird. Auf diese Weise kann das Metadatenprotokoll 604 als Puffer dienen, der die Wiederherstellung nach einem Netzwerkausfall ermöglicht und Impulse von Schreiboperationen unterstützt, ohne den Empfang oder die Verarbeitung von Speicheroperationen durch den Quelldaten-Repository 602 zu behindern. In diesem Beispiel können die Checkpoints 606a, 606b, wenn sie abgeschlossen und im Metadatenprotokoll 604 erstellt sind, zum Zieldaten-Repository 624 repliziert werden, z. B. durch die Übertragung einer oder mehrerer Nachrichten, die das Metadatenprotokoll 608 enthalten, unter Verwendung eines Standardkommunikationsprotokolls über ein oder mehrere Netzwerke 659. In diesem Beispiel kann das Quelldaten-Repository 602 unabhängig von der Übertragung des Metadatenprotokolls 604 auch Daten 610 übertragen, die den Checkpoints 606 innerhalb des Metadatenprotokolls 604 entsprechen.
  • In einigen Implementierungen kann ein Monitoring-Service beim Erstellen von Checkpoints im Quelldaten-Repository 602 überwachen, welche Checkpoints vollständig sind, und bestimmen, wo die Checkpoints gelesen werden können. In einigen Beispielen kann ein Checkpoint erstellt werden, wenn ein Checkpoint in den NVRAM oder eine erste Schicht des schnellen Datenspeichers geschrieben wird. In einigen Fällen kann der Monitoring-Service eine Schnittstelle für den Zugriff auf Checkpoint-Daten aus dem NVRAM oder von einem bestimmten Speicherort bereitstellen.
  • In Fortsetzung dieses Beispiels kann ein Zieldaten-Repository 624 einen oder mehrere Weiterleitungsströme aus dem Quelldaten-Repository 602 öffnen, wobei jeder Weiterleitungsstrom auf dem Quelldaten-Repository 602 eine Anzahl von Checkpoints vom Überwachungsdienst anfordern kann. In diesem Beispiel kann ein gegebener Weiterleitungsstrom Informationen des Metadatenprotokolls 614 für einen oder mehrere Checkpoints 606 abrufen. In ähnlicher Weise kann in diesem Beispiel ein gegebener Weiterleitungsstrom entsprechende Speicherdaten für den einen oder die mehreren Checkpoints 606 abrufen. Auf diese Weise können ein oder mehrere Kommunikationskanäle, in einigen Fällen parallel, zwischen dem Quelldaten-Repository 602 und dem Zieldaten-Repository 624 geöffnet werden, wobei der eine oder die mehreren Kommunikationskanäle zur Übertragung des Metadatenprotokolls 614 und der entsprechenden Daten 612 zwischen dem Quelldaten-Repository 602 und dem Zieldaten-Repository 624 dienen.
  • In diesem Beispiel kann der Zieldaten-Repository 624 als Reaktion auf den Empfang des Metadatenprotokolls 608 die Checkpoints 628a, 628b in ein lokales Metadatenprotokoll 626 persistieren. Basierend auf einem erfolgreichen Schreiben der Checkpoints 628 in das lokale Metadatenprotokoll 626 kann der Zieldaten-Repository 624 dem Quelldaten-Repository 602 mit einer Bestätigung antworten, wobei das Quelldaten-Repository 602 als Reaktion auf die Bestätigung - in Abhängigkeit von einer Konfigurationseinstellung - die Checkpoints 606a, 606b löschen oder beibehalten kann.
  • In einigen Beispielen kann das Zieldaten-Repository 624 periodisch oder als Reaktion auf den Empfang von Informationen des Metadatenprotokolls 626 vom Quelldaten-Repository 602 die Speichervorgänge innerhalb der Checkpoints 628 wiedergeben, um ein Tracking-Volume 632 zu erzeugen und zu aktualisieren. In einigen Beispielen kann die erneute Wiedergabe der Speichervorgänge das Konvertieren von Informationen aus dem Metadatenprotokoll 626 in regulär formatierte Metadaten für das Speichersystem und das Konvertieren globaler Inhaltskennungen in lokale Inhaltskennungen umfassen; eine solche Konvertierung kann zum Beispiel das Abbilden von Inhaltskennungen zwischen dem Quelldaten-Repository 602 und dem Zieldaten-Repository 624 umfassen. In diesem Beispiel kann eine Metadaten-Darstellung 630 ähnlich wie die Metadaten-Darstellung 614 auf dem Quelldaten-Repository 602 implementiert werden, wobei die physischen Standortinformationen auf der Grundlage der Verwendung von physischem Speicher auf dem Zieldatenspeicher unterschiedlich sein können. In einigen Beispielen kann ein Tracking-Volume auch als „Schatten“-Volume bezeichnet werden.
  • In einigen Implementierungen können Inhaltskennungen verwendet werden, um geschriebenen Inhalt zu markieren, einschließlich Inhalt, der von der Quelle bereits als Duplikat von einem anderem Inhalt erkannt wurde, von dem die Quelle weiß (z. B. durch Verfolgung des Quell-Schreibverlaufs, des Quell-Snapshot-Verlaufs, des Verlaufs der virtuellen Quellkopie und/oder einer lokalen Duplikat-Erkennung). In einigen Beispielen können die Inhaltskennungen bei der Wiederherstellung genutzt werden, z. B. nach einem längeren Ausfall oder bei der Konvertierung von der nahezu synchronen Replikation zur periodischen oder asynchronen Replikation.
  • In einigen Implementierungen kann das Bereitstellen eines Checkpoints als Satz von Metadaten-Updates und Inhaltskennungen dazu führen, dass das Zielspeichersystem feststellt, welche Inhaltskennungen dem Zielspeichersystem bereits bekannt sind und es bereits speichert - das Zielspeichersystem kann dann vom Quellspeichersystem alle Inhalte anfordern, deren Inhaltskennungen das Zielspeichersystem noch nicht speichert oder die ihm noch nicht bekannt sind. In einigen Fällen, außer bei mondähnlichen Entfernungen, kann die Checkpoint-Zustellung immer noch zu RPOs im Subsekundenbereich führen und auch die Datentransferbandbreite reduzieren, wenn Duplikate häufig vorkommen. Außerdem kann in diesem Beispiel der Checkpoint erst dann als abgeschlossen betrachtet werden, wenn alle fehlenden Inhalte angefordert und vom Zielspeichersystem empfangen wurden, sodass der Checkpoint nicht gelöscht werden kann, um eine Garbage Collection zu ermöglichen.
  • In einigen Beispielen wird das Tracking-Volume 632 als Reaktion auf ein Heraufstufungsereignis erzeugt, wobei ein Heraufstufungsereignis auf einem erkannten Ausfall, einem erkannten drohenden Ausfall oder einer erkannten Verschlechterung der Reaktionsfähigkeit über einen Schwellenwert der Compliance-Richtlinie des Daten-Repository hinaus beruhen kann. In einigen Fällen kann das Heraufstufungsereignis automatisch auf der Grundlage einer solchen Erkennung eines Heraufstufungsereignisses erzeugt werden, und in anderen Fällen kann das Heraufstufungsereignis als Reaktion auf einen Benutzer erzeugt werden, der angibt, dass die Replikatdaten auf dem Zieldaten-Repository 624 heraufgestuft werden sollen.
  • In einigen Implementierungen kann ein Benutzer ein Tracking-Volume 632 heraufstufen, um ein Replikat der Quelldaten für andere Zwecke zu verwenden, z. B. zum Testen - wobei das Testen eine Änderung der Replikatdaten im Tracking-Volume 632 beinhalten kann. Basierend auf einem Heraufstufungsereignis, das ein Replikat-Volume 634 erzeugt, können jedoch alle Änderungen oder Beschädigungen des Tracking-Volumens, die während des Testens auftreten können, rückgängig gemacht oder umgekehrt werden, indem auf das Replikat-Volume 634 verwiesen wird. In diesem Beispiel umfasst die Heraufstufung des Tracking-Volumes 632 auch die Konfigurationsfilterung und/oder den Abgleich als Teil der Bereitstellung des Tracking-Volumes 632 als neues Volume zur Verwendung durch einen Rechenprozess, ein Datenverarbeitungsgerät oder einen Rechenknoten. Ferner kann das Herabstufen oder Löschen eines Volumes dazu führen, dass ein Host eine Verbindung neu konfiguriert, um weiterhin auf Replikatdaten auf dem Zieldaten-Repository 624 zuzugreifen.
  • Während in einigen Implementierungen die empfangenen Informationen des Metadatenprotokolls 608 wiedergegeben werden können, um das Tracking-Volume 632 zu erzeugen, ohne das Metadatenprotokoll 608 zu speichern oder ein gespeichertes Metadatenprotokoll 626 zu führen, kann das gespeicherte Metadatenprotokoll 626 als Grundlage für die Bereitstellung von Datenkonsistenzgarantien dienen, die vorstehend in Bezug auf die Speicheroperationen in einem Checkpoint beschrieben wurden.
  • Die Entkopplung der Generierung des Tracking-Volumens von der Abhängigkeit von empfangenen Checkpoints und stattdessen das Erzeugen des Tracking-Volumens aus gespeicherten Checkpoints unterstützt den Empfang von Checkpoints in ungeordneter Reihenfolge und die Möglichkeit, die Checkpoints vor der Erstellung des Tracking-Volumens 632 anzuordnen. Mit anderen Worten: Checkpoints können in ungeordneter Reihenfolge gesendet und empfangen werden, aber im Allgemeinen können Checkpoints nicht in ungeordneter Reihenfolge angewendet werden, so dass in einigen Fällen die Anwendung der Checkpoints auf einen Tracking-Datensatz oder ein Volume verzögert werden kann, bis dazwischen liegende Checkpoints empfangen werden. Dieses Beispiel kann dahingehend verallgemeinert werden, dass alle dazwischenliegenden Checkpoints empfangen werden müssen, bevor der Tracking-Datensatz oder das Volume auf die Zeit vorgerückt werden kann, die einem empfangenen Datensatz zugeordnet ist (unabhängig davon, wie Checkpoint-Updates tatsächlich angewendet werden).
  • Wenn in diesem Beispiel aus irgendeinem Grund, wie z. B. einem Wiederherstellungsereignis auf dem Quelldaten-Repository 602 aufgrund von Datenverlust oder aufgrund eines Benutzers oder einer Anwendung, der/die Zugriff auf das Replikat-Volume anfordert, oder aufgrund einer Failover-Anforderung, das Replikat-Volume 634 als primäres oder benutzerzugängliches Volume zu verwenden, dann kann der Zieldaten-Repository 624 das Replikat-Volume 634 vorziehen oder aktivieren. Als Reaktion darauf können die vorhandenen Checkpoints im Metadatenprotokoll 626 wiedergegeben werden, um eine Version des Tracking-Volumes 632 zu erzeugen, die mit einem zuletzt empfangenen Checkpoint übereinstimmt, und das Tracking-Volume 632 kann zum Erstellen einer Version des Quellvolumens 658 verwendet werden.
  • In einigen Beispielen kann als Reaktion auf ein Wiederherstellungsereignis - z. B. wenn ein Quelldaten-Repository 602 die Verbindung zu einem Host-Computer (nicht abgebildet) oder zu Anwendungen, die Speicheroperationen senden, verliert, die Leistung über einen Schwellenwert hinaus sinkt, die Speicherkapazität einen Schwellenwert überschreitet oder die Antwortzeiten sich verschlechtern - der Zieldaten-Repository 624 dazu veranlasst werden, alle weiteren Speicheroperationen des Host-Computers zu verarbeiten, und ein anderer Datenspeicher kann ausgewählt werden. In diesem Beispiel kann die Replikat-Verknüpfung vom ursprünglichen Quelldaten-Repository 602 zum Zieldaten-Repository 624 in umgekehrter Richtung rekonfiguriert werden, wobei der Zieldaten-Repository 624 zu einem neuen Daten-Repository und ein anderer Datenspeicher zu einem neuen Zieldatenspeicher wird und die anderen Eigenschaften der Replikat-Verknüpfung gleich bleiben.
  • Die kontinuierliche Replikation vom Quelldaten-Repository 602 zum Zieldaten-Repository 624 kann auch in Form von Pods beschrieben werden, wobei Pods und Pod-Eigenschaften vorstehend mit Bezug auf die 4 und 5 beschrieben wurden. Wie bereits erwähnt, wird in 5 die Verwendung von Pods bei der Implementierung einer synchronen Replikation beschrieben, während in diesem Beispiel Pods für eine asynchrone oder nahezu synchrone Replikation verwendet werden. Mit anderen Worten, in diesem Beispiel kann das Quellvolume 658 in einem Pod 640 enthalten sein und das Replikat-Volume 634 kann in einem Pod 642 enthalten sein. Auf diese Weise wird der Replikat-Pod 642 als Reaktion auf eine Anzeige, dass ein Benutzer oder eine Anwendung beabsichtigt, die Replikatdaten zu verwenden, und auf die Freigabe des Tracking-Volumes 632 mit dem aktuellsten Inhalt aus dem Tracking-Volume 632 aktualisiert. Während in diesem Beispiel ein Pod als ein einzelnes Volume dargestellt ist, kann ein Pod in anderen Beispielen generell jede Art und Menge von Daten enthalten, einschließlich mehrerer Volumes und/oder mehrerer strukturierter oder unstrukturierter Datensätze.
  • Darüber hinaus kann es in einigen Implementierungen, wie vorstehend beschrieben, eine dynamische Beziehung von Volumes zu Pods geben, wobei die dynamische Sammlung von Volumes innerhalb eines Pods mit einem Taktwert innerhalb des Update-Streams auf einem Quellspeichersystem in Beziehung stehen kann. Beispielsweise kann ein Checkpoint Volumes in einen Pod einführen, Volume-Eigenschaften (Name, Größe usw.) ändern und möglicherweise Volumes entfernen. Wenn es in diesem Beispiel Schutzgruppen oder ein ähnliches organisatorisches Konzept innerhalb eines Pods gibt, können sich diese Schutzgruppen ebenfalls ändern, wobei diese Änderungen durch Checkpoints propagiert werden. Auf diese Weise kann ein nahezu synchrones Zielspeichersystem tatsächlich relativ nahtlos als periodische Replikationsquelle übernommen werden, wobei alle Beziehungen intakt sind, abzüglich der Zeitdifferenz zwischen dem letzten verarbeiteten Checkpoint und der vorherigen aktiven Quelle. Kurz gesagt, in einigen Fällen ist es die vereinheitlichte Natur des Metadatenmodells zwischen synchroner Replikation, nahezu synchroner Replikation (near-sync) und periodischer Replikation (oder asynchroner Replikation), gekoppelt mit den Local-to-Global-to-Local-Content-ldentifier- und Logical- und Composite-Extension-Identifier-Transformationen, die Verbesserungen für verschiedene Aspekte eines Speichersystems und eines Speichersystem-Replikationsprozesses bietet.
  • Wie in 6 dargestellt, speichert ein Daten-Repository 602 sowohl Daten 612 aus eingehenden Datenspeicheroperationen 652 als auch eine Metadaten-Darstellung 614 der Daten 612. In diesem Beispiel kann eine Metadaten-Darstellung 614 als strukturierte Sammlung von Metadatenobjekten implementiert werden, die zusammen ein logisches Volume von Speicherdaten oder einen Teil eines logischen Volumens in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung darstellen können. Die Metadaten-Darstellung 614 kann im Quelldaten-Repository 602 gespeichert werden, und eine oder mehrere Metadaten-Darstellungen können für jedes von mehreren Speicherobjekten, wie Volumes oder Teile von Volumes, die im Daten-Repository 602 gespeichert sind, erzeugt und gepflegt werden.
  • In anderen Beispielen sind andere Arten von strukturierten Sammlungen der Metadatenobjekte möglich; in diesem Beispiel können Metadaten-Darstellungen jedoch als gerichteter azyklischer Graph (DAG) von Knoten strukturiert werden, wobei der DAG zur Aufrechterhaltung eines effizienten Zugriffs auf jeden beliebigen Knoten nach verschiedenen Methoden strukturiert und ausgeglichen werden kann. Beispielsweise kann ein DAG für eine Metadaten-Darstellung als eine Art B-Baum definiert und entsprechend als Reaktion auf Änderungen an der Struktur der Metadaten-Darstellung ausgeglichen werden, wobei Änderungen an der Metadaten-Darstellung als Reaktion auf Änderungen an oder Ergänzungen zu den zugrunde liegenden Daten, die durch die Metadaten-Darstellung dargestellt werden, auftreten können. Im Allgemeinen können sich Metadaten-Darstellungen über mehrere Ebenen erstrecken und Hunderte oder Tausende von Knoten umfassen, wobei jeder Knoten eine beliebige Anzahl von Verknüpfungen zu anderen Knoten enthalten kann.
  • Ferner können in diesem Beispiel die Blätter einer Metadaten-Darstellung Pointer auf die gespeicherten Daten für ein Volume oder einen Teil eines Volumes enthalten, wobei eine logische Adresse oder ein Volume und ein Offset verwendet werden können, um einen oder mehrere Blattknoten zu identifizieren und durch die Metadaten-Darstellung zu navigieren, um einen oder mehrere Blattknoten zu erreichen, die auf gespeicherte Daten verweisen, die der logischen Adresse entsprechen. Datenobjekte können eine beliebige Größeneinheit von Daten innerhalb des Daten-Repository 602 sein. Beispielsweise kann jedes Datenobjekt ein Logical Extent sein, wobei Logical Extents eine bestimmte Größe aufweisen können, z. B. 1 MB, 4 MB oder eine andere Größe, z. B. eine vom System vorgegebene Blockgröße.
  • In einigen Implementierungen, wie vorstehend mit Bezug auf die 1A-3D beschrieben, kann das Daten-Repository 602 mehrere Arten von Datenspeichern enthalten, einschließlich NVRAM und Flash-Speicher, wobei NVRAM als Bereitstellungsbereich für eingehende Speicheroperationen verwendet werden kann und Flash-Speicher eine langfristige, dauerhafte Speicherung bieten kann. In diesem Beispiel kann das Quellvolumen 658 oder Teile des Quellvolumens 658 in NVRAM gespeichert werden, und das gesamte Quellvolumen kann im Flash-Speicher oder, wie in 6 dargestellt, im Datenspeicher 660 gespeichert werden.
  • In einigen Implementierungen ist das Metadatenprotokoll 604 nach Checkpoints geordnet und ist ein Journal oder Protokoll, das alle Änderungen an gespeicherten Daten beschreibt, und bei dem Checkpoints innerhalb des Metadatenprotokolls 604, die noch nicht an das Zieldaten-Repository 624 übertragen wurden, als Reaktion auf die Erzeugung oder Fertigstellung eines einzelnen Checkpoints oder eines Satzes von Checkpoints in Abhängigkeit von einem Ziel-RPO übertragen werden. Abhängig von der Größe eines Checkpoints oder der Anzahl der durch den Checkpoint beschriebenen datenverändernden Operationen kann beispielsweise eine häufigere Übertragung in Abhängigkeit von einem niedrigeren Ziel-RPO erfolgen.
  • Außerdem können, wie vorstehend beschrieben, die Checkpoints 606 im Metadatenprotokoll 604 Verweise auf gespeicherte Inhalte wie Blöcke im Datenspeicher 660 enthalten, wobei diese gespeicherten Inhalte aus dem bestehen, was das Speichersystem gespeichert hätte, wenn es den replizierten Checkpoint nicht gegeben hätte. Auf diese Weise wird der für das Metadatenprotokoll und die Checkpoints benötigte Speicherplatz erheblich reduziert im Vergleich zu dem, was für ein vollständiges Protokoll aller Aktualisierungen erforderlich wäre, das sowohl Metadaten als auch eine doppelte Kopie der Daten enthält, die in das Quellspeichersystem geschrieben wurden. In einigen Beispielen kann ein Dienst oder Prozess oder Controller, der auf dem Quelldaten-Repository 602 arbeitet, die Erstellung von Checkpoints überwachen und den Checkpoint oder den Satz von Checkpoints an den Zieldaten-Repository 624 weiterleiten oder übertragen.
  • In einigen Implementierungen können sich Verweise innerhalb von Checkpoints und folglich auch Verweise innerhalb eines Metadatenprotokolls auf Objekte oder Daten beziehen, die im Quelldaten-Repository 602 gespeichert sind und durch nachfolgende Speicheroperationen verändert wurden, wobei die im Quelldaten-Repository 602 gespeicherten Daten jedoch noch nicht in den Zieldaten-Repository 624 übertragen wurden. Wenn sich in einem solchen Szenario ein Garbage-Collection-Prozess auf dem Quelldaten-Repository 602 nur auf eine Referenztabelle stützt, die von einem Speicher-Controller verwaltet wird, der Daten innerhalb des Quelldaten-Repository 602 verwaltet, dann kann der Garbage-Collection-Prozess Daten löschen oder einen Speicherplatz neu zuweisen oder anderweitig überschreiben, was dazu führt, dass Daten, auf die ein Metadatenprotokoll verweist, nicht mehr verfügbar oder als Inhaltsquelle für einen replizierten Checkpoint nicht mehr gültig sind, wodurch das Replizieren beeinträchtigt wird. Um ein solches Szenario zu vermeiden, kann in einigen Beispielen ein Garbage-Collection-Prozess auf dem Quelldaten-Repository 602 sowohl auf eine Referenztabelle verweisen, die von einem Speicher-Controller oder Quelldaten-Repository 602-Prozess gepflegt wird, als auch auf eine Liste von Referenzen, die von Lightweight Checkpoints gehalten werden, und insbesondere auf eine Liste von Referenzen innerhalb eines oder mehrerer Checkpoints innerhalb eines Metadatenprotokolls. Im Laufe der Zeit können Checkpoints zusammengeführt werden, damit einige überschriebene Inhalte für die Garbage Collection freigegeben werden können.
  • Auf diese Weise kann ein Garbage-Collection-Prozess zumindest auf der Grundlage beider Quellen von Datenreferenzen - Systemreferenzen und Metadatenprotokollreferenzen - Daten bewahren, die noch nicht repliziert wurden, aber ansonsten durch nachfolgende Speicheroperationen verändert oder gelöscht würden. Eine solche Datenerhaltung während der Garbage Collection gilt auch für die kontinuierliche Datensicherung, bei der Checkpoints auf einem Quellspeichersystem für eine gewisse Zeit aufbewahrt werden, um ein flexibles Rollback zu ermöglichen, wobei die Zeitspanne auf eine beliebige Menge an Zeit konfigurierbar sein kann. Mit anderen Worten: Ein Garbage-Collection-Prozess kann feststellen, dass der Inhalt an einem Speicherort nicht benötigt wird und zurückgewonnen oder einer Garbage Collection ausgesetzt werden kann, basierend darauf, dass der Inhalt an dem Speicherort nicht von irgendwelchen Checkpoints in einem Metadatenprotokoll referenziert wird oder von einer Referenztabelle des Speichersystems referenziert wird.
  • In einigen Implementierungen, wie vorstehend erwähnt, schließt jeder Checkpoint jeden anderen Checkpoint aus, und basierend auf der Reihenfolge der Checkpoints können die Checkpoints in beliebiger Reihenfolge an das Zieldaten-Repository 624 übertragen werden. In diesem Beispiel werden die Checkpoints auf dem Zieldatenspeicher-Repository 624 angewendet oder wiedergegeben, um eine konsistente Version der auf dem Quelldaten-Repository 602 gespeicherten Daten zu erstellen. In einigen Fällen können die vom Quelldaten-Repository 602 an den Zieldaten-Repository 624 übertragenen Daten aus dem Datenspeicher innerhalb des Datenspeichers 660 gelesen werden, z. B. wenn die Daten aus dem NVRAM in den Flash-Speicher geflusht wurden, oder aus dem NVRAM, z. B. wenn die Daten weiterhin im NVRAM gespeichert sind.
  • In einigen Implementierungen können Daten, abhängig von den Konfigurationseinstellungen in Bezug auf das RPO, länger oder kürzer im Quelldaten-Repository 602 verbleiben. Je länger die Daten im Quelldaten-Repository 602 verbleiben, desto größer ist in manchen Fällen die Möglichkeit, Transformationen durchzuführen, die die Menge der an den Zieldaten-Repository 624 übertragenen Daten reduzieren können. Eingehende Daten können z. B. dedupliziert werden oder zuvor geschriebene Daten überschreiben oder gelöscht werden, neben anderen Operationen oder Transformationen, die die Datenmenge, die vom Quelldaten-Repository 602 zum Zieldaten-Repository 624 übertragen wird, reduzieren können.
  • In einigen Implementierungen können die Messaging-Mechanismen ähnlich implementiert werden wie die vorstehend beschriebenen Messaging-Mechanismen für die synchrone Datenreplikation, mit Bezug auf die 4 und 5.
  • Zur weiteren Erläuterung veranschaulicht 7 ein konfigurierbares Replikationssystem, das eine kontinuierliche Replikation mit Minimaldosierung und einem einstellbaren Ziel für den Wiederherstellungspunkt bietet. In diesem Beispiel kann ein Verwaltungsobjekt, das eine Replikationsrichtlinie zwischen einem Quell-Pod und einem Replikations-Pod festlegt, als „Replikationsverbindung“ bezeichnet werden.
  • Eine Replikatverknüpfungsspezifikation kann eine Spezifikation für eine Datenquelle für das Replizieren und ein Ziel für Replikatdaten enthalten, einschließlich Speicherdaten, Checkpoints, Metadaten-Darstellungen oder Metadaten-Protokolle (oder Journale). In einigen Fällen kann die Datenquelle ein Volume, ein strukturierter oder unstrukturierter Datensatz, ein Bucket, eine Datei innerhalb eines Dateisystems, ein ganzes Dateisystemverzeichnis oder eine Kombination von Quellen sein - wobei die Datenquellen in einem Quelldaten-Repository 602 gespeichert sind.
  • In einigen Fällen kann es ein oder mehrere Replikationsdatenziele geben, wobei z. B. ein Quelldaten-Repository 602 mehrere Pods 640, 682 und mehrere entsprechende Replikationsdatenziele enthält, die als Zieldatenspeicher 688, 694 dargestellt sind. In diesem Beispiel umfasst der Quell-Pod 640 ein Volume 658, der Quell-Pod 682 ein Volume 680, der Replik-Pod 690 ein Replik-Volume 692 und der Replik-Pod 696 ein Replik-Volume 698. Ferner kann es, wie in 7 dargestellt, eine oder mehrere Replikationsverbindungen 684, 686 geben, die das Replizieren vom Daten-Repository zu einem oder mehreren Zieldatenspeichern 688, 694 verwalten.
  • In einigen Implementierungen, in einem Beispiel, in dem das Replizieren die Verwendung von Snapshots der Quelldaten beinhaltet, kann eine Replikationsverbindung eine Snapshot-Richtlinie spezifizieren, die Bedingungen festlegen kann, unter denen ein Snapshot erstellt werden kann. Wenn z. B. bei der asynchronen Replikation, wie vorstehend mit Bezug auf 6 beschrieben, ein Backup entsteht - z. B. wenn die Menge der gesicherten Daten und/oder Metadaten, die zur Übertragung anstehen, zu einem RPO führen würde, das über einem RPO-Schwellenwert liegt -, kann ein Snapshot erstellt werden. In anderen Beispielen kann die Snapshot-Richtlinie festlegen, dass Snapshots nach einem bestimmten Zeitplan erstellt werden sollen, und sie kann eine Zeitspanne festlegen, in der Snapshots verfügbar bleiben.
  • Ferner kann ein Daten-Repository in einigen Beispielen anstelle oder zusätzlich zur Erstellung von Snapshots für einen Daten-Repository, um einen Rückstand bei der Übertragung von Metadaten und/oder Daten an einen Zieldatenspeicher zu verringern, eine oder mehrere Transformationen oder Optimierungen an den zu übertragenden Daten und/oder Metadaten durchführen. Wenn ein Daten-Repository beispielsweise feststellt, dass die zur Übertragung anstehenden Daten mit bereits übertragenen Daten identisch sind, kann der Daten-Repository das Senden der doppelten Daten, die zur Übertragung anstehen, vermeiden. Ein weiteres Beispiel: Checkpoints innerhalb eines Metadatenprotokolls können zusammengelegt werden. Wenn zwischen zwei Checkpoints ein Überschreiben stattfindet, kann das Daten-Repository-System das Senden von Daten vermeiden, die überschrieben wurden, was durch die zusammengelegten Checkpoints angezeigt wird.
  • Darüber hinaus kann ein Replikat-Link auch eine Replikat-Richtlinie spezifizieren, wobei die Replikat-Richtlinie Snapshots enthalten oder ausschließlich sein kann, eine kontinuierliche, aber nicht synchrone Replikation spezifizieren oder eine synchrone Replikation spezifizieren kann. In allen Fällen kann einem Benutzer eine einzige Benutzeroberfläche mit einem einzigen Arbeitsablauf für eine Replikatverknüpfungsspezifikation zur Verfügung gestellt werden, die die Spezifikation einer oder mehrerer Eigenschaften für die Datenreplikation ermöglicht.
  • In einigen Implementierungen kann eine Replikationsverbindung auch eine Compliance-Richtlinie angeben. Eine Compliance-Richtlinie kann beispielsweise festlegen, dass für eine bestimmte Art von Replikationsrichtlinie - z. B. kontinuierlich, synchron, asynchron, Snapshot - das Replizieren bestimmte Parameter einhalten sollte. Für eine Snapshot-Replikationsrichtlinie kann die Compliance-Richtlinie beispielsweise festlegen, dass eine Systemwarnung generiert wird, wenn die Häufigkeit oder der Zeitplan, nach dem Snapshots erstellt werden, einen bestimmten Schwellenwert nicht einhält. Ebenso kann eine Systemwarnung oder ein Alert generiert werden, wenn Daten und/oder Metadaten nicht schnell genug übertragen werden, um ein bestimmtes RPO oder eine andere Leistungsmetrik zu erfüllen. Alternativ können die Aktualisierungen auf dem Quellspeichersystem verlangsamt werden, um ein Überschreiten des RPO zu vermeiden.
  • In anderen Fällen können jedoch als Reaktion auf das Verfehlen eines Schwellenwerts für die Konformität andere Korrekturmaßnahmen ergriffen werden, z. B. wenn ein Zieldatenspeicher die Ursache für ein Backup ist oder einen Leistungsabfall aufweist oder sich der Kapazität nähert, dann kann eine Diagnose eingeleitet werden, um korrigierbare Probleme zu identifizieren, oder es kann ein alternativer Zieldatenspeicher für das Übertragen der Zielreplikatdaten an den neuen Zieldatenspeicher identifiziert werden. In einigen Implementierungen kann die Replikationsverknüpfung auch Attribute der Replikationshistorie speichern, z. B. die Identifizierung eines Punkts, an dem ein Daten-Repository eingefroren oder nicht mehr verfügbar war.
  • Im Allgemeinen kann eine Replikationsverbindung verwendet werden, um eine Replikationsbeziehung zu spezifizieren, und je nachdem, ob ein Pod aktiv oder passiv ist, eine Replikationsrichtung zu bestimmen, wobei das Replizieren in Richtung eines aktiven (oder aktivierten oder heraufgestuften) Pods zu einem passiven (oder deaktivierten oder heruntergestuften) Pod erfolgt. In diesem Beispiel kann eine Replikationsrichtung auch dann geändert werden, wenn alle mit der Replikationsverbindung verbundenen Pods in Kommunikation stehen und einen Konsens über eine Änderung der Replikationsrichtung erzielen. Auf diese Weise kann ein Quell-Pod geschützt werden, indem ein Replikat-Link zu einem anderen, deaktivierten Pod auf einem anderen Daten-Repository erstellt wird, wobei Hosts oder Host-Gruppen mit dem deaktivierten Pod auf dem Zieldaten-Repository verbunden werden können, um - nahezu synchron - Daten vom Quell-Pod zu lesen.
  • Zur weiteren Erläuterung veranschaulichen die 7 und 8 Aspekte der selektiven Kommunikationsprotokollschichtung für die synchrone Replikation zwischen einem oder mehreren Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Genauer gesagt, als Teil einer beispielhaften Ausführungsform der selektiven Kommunikationsprotokollschichtung, veranschaulicht 7 ein beispielhaftes Verfahren eines Abfrage-Kontrollflusses, 8 veranschaulicht ein beispielhaftes Verfahren eines Connect/Accept-Kontrollflusses und 9 veranschaulicht ein beispielhaftes Verfahren eines Sende/Lese-Kontrollflusses.
  • 7 veranschaulicht Aspekte der selektiven Kommunikationsprotokollschichtung für synchrone Replikation zwischen einem oder mehreren Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Genauer gesagt zeigt 7 als Teil einer Beispielsausführungsform der selektiven Kommunikationsprotokollschichtung ein Beispielverfahren eines Connect/Accept-Kontrollflusses, das auf Speichersystemen umgesetzt werden kann, die den oben unter Bezugnahme auf die 1A-1D, 2A-2G, 3A-3C, 4A und 4B, 5-6C oder einer beliebigen Kombination davon beschriebenen Speichersystemen ähnlich sind.
  • In einigen Implementierungen kann ein Replikationsprotokoll oder ein Replikationsschema spezifiziert werden, um bidirektionale Kommunikationspfade bereitzustellen, die zwischen Speichersystemen unter Verwendung ausgewählter Merkmale eines oder mehrerer Standard-Kommunikationsprotokolle eingerichtet werden - wobei die zugrundeliegenden Standard-Kommunikationsprotokolle traditionell für die Datenübertragung in einer einzigen Richtung ausgelegt sind, von einem Computersystem, das Speicherinhalte bereitstellt, zu einem Speichersystem, das Storage-Dienste bereitstellt.
  • In einigen Implementierungen können die Speichersysteme dann eine synchrone Replikation auf der Grundlage des Replikationsprotokolls oder Replikationsschemas implementieren, das eine bidirektionale Kommunikation zwischen den Speichersystemen ermöglicht. Auf diese Weise können die vorstehend mit Bezug auf die 6A-6B beschriebenen synchronen Replikationsprotokolle oder -schemata unter Verwendung des Replikationsprotokolls oder -schemas, das eine bidirektionale Kommunikation bereitstellt, ausgeführt werden.
  • In den folgenden Beispielen kann eine Gruppe von mehreren Speichersystemen, die so konfiguriert sind, dass sie einen oder mehrere Datensätze zwischen jedem einzelnen Speichersystem innerhalb der Gruppe synchron replizieren, als Cluster von Speichersystemen bezeichnet werden oder gleichwertig als aktiver Cluster oder aktiver Cluster von Speichersystemen bezeichnet werden. Wie vorstehend erwähnt, werden Beispielimplementierungen eines aktiven Clusters von Speichersystemen, die Datensätze synchron replizieren und Pods verwalten, vorstehend unter Bezugnahme auf die 6A-6B beschrieben und in den übergeordneten Anwendungen der vorliegenden Offenbarung weiter erläutert.
  • In einigen Implementierungen werden, wie unten näher erläutert, einige, aber nicht alle Teile von Mehrfachkommunikationsprotokollen verwendet, um die bidirektionale Datenreplikation auf eine Weise zu implementieren, die außerhalb des Designbereichs der zugrunde liegenden Mehrfachkommunikationsprotokolle liegt.
  • Darüber hinaus bieten in einigen Implementierungen verschiedene Ausführungsformen eines Replikationsprotokolls oder -schemas durch die Verwendung ausgewählter Aspekte der zugrunde liegenden Kommunikationsprotokolle zusätzlich zur Rekonfiguration von Aspekten der zugrunde liegenden Kommunikationsprotokolle eine bidirektionale Replikation von Daten, die effizienter - z. B. durch die Verwendung von weniger Nachrichten im Vergleich zu einer Standardimplementierung der zugrunde liegenden Kommunikationsprotokolle - die vorstehend unter Bezugnahme auf die 6A-6B beschriebenen synchronen Replikationsprotokolle oder -schemata unterstützt, zusätzlich zur Unterstützung anderer Arten von Replikationsdiensten.
  • In einigen Implementierungen können zusätzlich zu den vorstehend unter Bezugnahme auf 6 beschriebenen Replikationsprotokollen oder -schemata, die eine synchrone Replikation implementieren, die bidirektionalen Merkmale des Replikationsprotokolls oder - schemas auch verwendet werden, um andere Arten von Datenreplikationsprotokollen oder - schemata zu implementieren, einschließlich asynchroner Replikation, oder allgemeiner jedes Protokoll oder Schema, das auf der bidirektionalen Übertragung von Daten zwischen Computersystemen und/oder Speichersystemen basiert.
  • In einigen Implementierungen können die verwendeten Kommunikationsprotokolle sein: Fibre Channel, NVMe, NVMe over Fabrics (NVME-oF), TCP/IP, RoCE, oder Kombinationen dieser Kommunikationsprotokolle.
  • Als ein Beispiel für Änderungen an den zugrunde liegenden Protokollen kann ein gegebenes Speichersystem während eines Erkennungsprozesses für eine Fibre-Channel-Protokollschicht ein Protokoll anderer Zielspeichersysteme erhalten. Weiterhin kann in diesem Beispiel auf der NVMe-Protokollschicht das gegebene Speichersystem eine Liste von Kennungen für die anderen Zielspeichersysteme erhalten, wobei die Liste der Kennungen eine Liste von NVMe Qualified Names (NQNs) sein kann.
  • In diesem Beispiel kann jedoch in Übereinstimmung mit dem Replikationsprotokoll oder - schema ein Format eines NQN so modifiziert werden, dass es eine vom Replikationsprotokoll oder -schema verwendbare Kennung enthält, wobei die Replikationsprotokoll-Kennung vom Speichersystem verwendet werden kann, um eine Liste von Speichersystemen zu identifizieren, die in einer Datenreplikationskonfiguration enthalten sein können. Genauer gesagt, kann in diesem Beispiel die Liste der Speichersysteme eine Liste von Speichersystemen sein, die in einem aktiven Cluster von Speichersystemen enthalten sein können, die einen Datensatz synchron replizieren.
  • Ferner sind Fibre Channel und NVMe in einigen Implementierungen, wie vorstehend erwähnt, für einen Host-Computer oder Server zum Speichern von Daten auf einem Speichersystem ausgelegt, aber nicht für ein angeschlossenes Speichersystem zum wechselseitigen Speichern von Speicherinhalten auf dem Host-Computer, geschweige denn, wenn der Host-Computer und das Speichersystem für eine synchrone Replikation von Daten konfiguriert sind.
  • Im Gegensatz dazu spezifiziert das Replikationsprotokoll oder -schema in einigen Implementierungen eine Logik, die eine bidirektionale Kommunikation herstellt, die von einem Initiatorspeichersystem ausgeführt wird, das einen Kommunikationskanal in einer Richtung mit einem gegebenen Zielspeichersystem herstellt, und das Zielspeichersystem - als Reaktion auf die Herstellung eines Kommunikationskanals von dem Initiatorspeichersystem zu dem Zielspeichersystem und die Feststellung, dass es keinen Kommunikationskanal von dem Zielspeichersystem zurück zu dem Initiatorspeichersystem gibt - einen Kommunikationskanal zurück zu dem Initiatorspeichersystem herstellt.
  • Auf diese Weise können in einigen Beispielen bidirektionale Kommunikationskanäle eingerichtet werden, um die bidirektionalen Datenverbindungen zu unterstützen, die oben mit Bezug auf die synchronen Replikationsprotokolle oder -schemata beschrieben wurden, welche wiederum oben mit Bezug auf die 6A-6B beschrieben wurden, wobei mehrere Speichersysteme innerhalb eines aktiven Clusters synchron replizierte Datendienste bereitstellen. Mit anderen Worten: Das offengelegte Replikationsprotokoll oder -schema spezifiziert einen eigenen Netzwerkstapel und ein eigenes Kommunikationsprotokoll, das sich von einem Einsatz von Standardimplementierungen der zugrunde liegenden Fibre-Channel-, NVMe- und IP-Protokolle, entweder allein oder in Kombination, unterscheidet.
  • In einigen Implementierungen kann das Replikationsprotokoll oder -schema mehrere Arten von Funktionalität bereitstellen, um Aspekte des Aufbaus von Verbindungen zwischen Speichersystemen, des Abfragens, ob neue Speichersysteme online gehen, und des Lesens und Sendens als Teil der bidirektionalen Kommunikation zwischen Computersystemen und/oder Speichersystemen zu implementieren.
  • Genauer gesagt kann das Replikationsprotokoll oder -schema in einigen Implementierungen, die einen oder mehrere Aspekte von Fibre-Channel-, NVMe- und TCP/IP-Kommunikationsprotokollen enthalten, Folgendes umfassen: (I) eine Replikationsprotokollschicht für aktive Cluster (in diesem Beispiel die höchste Schicht); (II) eine Replikationstransportschicht; (iii) eine NVMe-oF-Schicht; und (IV) eine NVMe-Transportschicht, wobei in einigen Beispielen die NVMe-Transportschicht Fibre Channel sein kann.
  • In Bezug auf (I) oben, die synchrone Replikationsprotokollschicht, kann das Replikationsprotokoll oder -schema beispielsweise Folgendes umfassen: (a) Erkennungsfunktionalität; (b) Remote-Client-Verbindungsfunktionalität; (c) Sendefunktionalität; (d) Empfangsfunktionalität; und (e) Trennungsfunktionalität, neben anderen.
  • Die vorstehend unter (I)(a) aufgeführte Erkennungsfunktionalität kann Folgendes umfassen:
    1. (i) Abfragen auf entfernte Speichersystem-Kennungen, die daran interessiert sein könnten, in eine Konfiguration zum Aufbau einer synchronen Replikation aufgenommen zu werden - wobei die Speichersystem-Kennung vom Replikationsprotokoll oder -schema verwendet wird, aber nicht für die zugrunde liegenden Kommunikationsprotokolle verwendet wird oder notwendig ist;
    2. (ii) Abfragen eines Replikationstransportdienstes auf neue Speichersystemkennungen oder auf neue Pfade für vorhandene Speichersystemkennungen - wobei ein gegebenes Speichersystem andere Speichersysteme nach Pfadinformationen abfragen kann, wobei die Abfrage auf jeweiligen Speichersystemkennungen für die anderen Speichersysteme im aktiven Cluster basieren kann; und
    3. (iii) Bestimmen, ob eine Verbindung unter Verwendung eines bestimmten einen oder mehrerer neuer Pfade zu einem gegebenen Speichersystem im aktiven Cluster hergestellt werden soll oder ob die vorhandenen Pfade zu dem gegebenen Speichersystem weiter verwendet werden sollen.
  • Die als (I)(b) vorstehend aufgeführte Remote-Client-Verbindungsfunktionalität kann Folgendes umfassen:
    1. (i) Verwenden einer Liste oder eines Vektors von Pfaden zur Verbindung mit entfernten Speichersystemen;
    2. (ii) Steuern einer Menge von herzustellenden Verbindungen und Verfolgen, ob die Verbindungen erfolgreich sind; und
    3. (iii) Führen einer Liste von Pfaden, die für die Replikationsprotokollschicht zugänglich sind.
  • Die vorstehend unter (I)(c)-(e) aufgeführten Funktionen zum Senden, Empfangen und Trennen der Verbindung können Folgendes umfassen: Senden von Daten an andere Speichersysteme unter Verwendung von Fibre Channel; Empfangen von Daten von anderen Speichersystemen unter Verwendung von Fibre Channel; und Trennen der Verbindung zu anderen Speichersystemen durch Initiieren des Beseitigens eines Endpunkts der Transportschicht oder durch Erkennen und Reagieren auf Fehler bei einer Übertragung. Darüber hinaus kann die Trennungsfunktionalität dadurch gesteuert werden, dass der Fibre Channel eine Trennung eines Ziels von einer Transportstruktur erkennt.
  • Um dieses Beispiel fortzusetzen, kann diese Schicht in Bezug auf (II) oben, die Replikationstransportschicht, Folgendes umfassen: (a) Nachrichtenübertragungsfunktionalität; und (b) Transport-Endpunkt-Funktionalität.
  • Die Nachrichtenübertragungsfunktionalität auf einer Replikationstransportschicht, die vorstehend als (II)(a) aufgeführt ist, kann Folgendes umfassen:
    1. (i) Abfragen, als Initiator und in Übereinstimmung mit dem NVMe-Erkennungsprotokoll, um neue NVMe-Qualified-Names (NQN)-Kennungen basierend auf Fibre-Channel-World-Wide-Port-Names (WWPNs) und/oder entfernte Fibre-Channel-WWPN-Kennungen zu erhalten, wobei als Reaktion auf das Entdecken eines neuen Speichersystems der Replikationsprotokollschicht-Abfrageeinrichtung, die vorstehend unter (I)(a)(i) beschrieben ist, benachrichtigt werden kann;
    2. (ii) Empfangen von Verbindungs/Transport-Endpunkt-Erstellungsanforderungen, was das Konfigurieren oder Einrichten eines Transport-Endpunkt-Objekts beinhalten kann, das: Puffer oder Tracker auf der Initiatorseite einer Verbindung zuweisen, Puffer oder Tracker auf einer Zielseite einer Verbindung zuweisen, Verbindungsbefehle in Übereinstimmung mit einer NVMe-Transportschicht ausgeben, auf eine Zielverbindung in Übereinstimmung mit einer NVMe-Transportschicht warten kann;
    3. (iii) Verfolgen der anstehenden initiatorseitigen Verbindungen, die auf zielseitige Verbindungen warten; und
    4. (iv) Abfragen des NVMe-Transports auf Zielverbindungen, um eine Initiatorverbindung zu vervollständigen, was das Einrichten eines Transport-Endpunktobjekts wie vorstehend umfassen kann, wobei das Transport-Endpunktobjekt Datenpuffer und/oder Tracker für die Initiatorseite einer Verbindung zuweisen, Datenpuffer und/oder Tracker für eine Zielseite einer Verbindung zuweisen, Erfolgsmeldungen über NVMe über Fibre Channel (FC-NVMe) senden und Verbindungsbefehle über eine NVMe-Transportschicht ausgeben kann.
  • Die Transport-Endpunkt-Funktionalität auf einer Replikations-Transportschicht, die vorstehend unter (ll)(b) aufgeführt ist, kann Funktionen für Folgendes umfassen:
    1. (i) Empfangen von Daten als Fibre-Channel-Endpunkt, wobei das Empfangen von Daten auch das Zuweisen einer Pufferliste umfassen kann, und ferner das Senden eines Lesevorgangs für jeden zugewiesenen Datenpuffer, wobei das Lesen von Daten vorstehend unter Bezugnahme auf 5 ausführlicher beschrieben ist;
    2. (ii) Senden von Daten, wobei das Senden von Daten das Empfangen einer Pufferliste von der Replikationsprotokollschicht, die eine Schnittstelle zu Speichersystemen in einem aktiven Cluster bildet, und von Befehlsnachrichten zur Zuweisung von ziel- und verbindungsspezifischen Datenpuffern umfassen kann, und das Initiieren des Kopierens von Inhalten in entsprechende NVMe-Lesepuffer umfassen kann;
    3. (iii) Empfangen von Daten auf der Replikationstransportebene entsprechend den NVMe-Initiator- und Leseabschlussprotokollen, wobei das Empfangen von Daten auf der Replikationstransportebene auch das Bereitstellen einer Lesefunktion umfassen kann, die das Parsen von Header-Informationen, das Verifizieren, das Zuweisen von Puffern und das Einkopieren von Daten handhaben kann;
    4. (iv) Fehlerbehandlung; und
    5. (v) Trennen von einem oder mehreren Speichersystemen im aktiven Cluster, was das Abbauen von Verbindungen auf der Replikationstransportebene und der NVMe-Ebene beinhalten kann.
  • Um dieses Beispiel fortzusetzen, kann diese Schicht in Bezug auf (III) oben, die NVMe-oF-Protokollschicht, Folgendes umfassen: (a) Polling; (b) Initiator-Erkennung; (c) Initiator-Steuerung; (d) Initiator-Verbindungen; (e) Ziel-Steuerung; und (f) Ziel-Verbindungen.
  • Die Polling-Funktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(a) aufgeführt ist, kann unter anderem feststellen, ob eine NVMe-Initiatorverbindung erfolgreich aufgebaut wurde, ob eine Zielverbindung eine Leseanforderung erhalten hat, ob eine Zielsteuerung eine Verbindungsanfrage erhalten hat, ob eine Initiatorverbindung einen Leseabschluss erhalten hat.
  • Die Initiator- Erkennungsfunktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(b) aufgeführt ist, kann Benachrichtigungen für neue lokale WWPN/entfernte WWPN-Paare erhalten, die NVMe-Erkennung initiieren, um NVMe-qualifizierte Namen (NQNs) zu erhalten, und außerdem entfernte und lokale WWPNs und NQNs an die Messaging-Transportfunktionalität auf der Replikationstransportschicht, die vorstehend unter (II)(a) aufgeführt ist, weitergeben.
  • Die Initiator- Steuerungsfunktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(c) aufgeführt ist, kann einem Initiator Keep-Alive-Dienste zur Verfügung stellen, die das Senden von Keep-Alive-Nachrichten, das Beenden von Verbindungen bei Timeouts, das Verfolgen von Keep-Alive-Latenzen und, falls bei einer Verbindungsanfrage keine Admin-Verbindungen bestehen, das Aufbauen von Admin-Verbindungen umfassen können.
  • Die Initiator-Verbindungsfunktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(d) aufgeführt ist, kann Warteschlangenkennungen verwalten, NVMe-Lesebefehle senden oder Leseanforderungen beantworten.
  • Die Zielsteuerungsfunktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(e) aufgeführt ist, kann auf der Grundlage spezifizierter NQNs feststellen, ob eine Verbindung akzeptiert wird, und kann als Reaktion auf neue Verbindungen Rückrufe an ein Zielspeichersystem liefern.
  • Die Zielverbindungsfunktionalität auf der NVMe-oF-Protokollschicht, die vorstehend unter (III)(f) aufgeführt ist, kann externe Trennungsdienste bereitstellen oder Leseanforderungen beantworten.
  • Um mit diesem Beispiel fortzufahren, kann diese Schicht in Bezug auf (IV) oben, die NVMe-Transportschicht, Folgendes umfassen: (a) Initiatorfunktionalität, die lokale WWPNs und/oder entfernte WWPNs abfragen kann, eine Verbindung zu lokalen WWPNs und/oder entfernten WWPNs herstellen kann und Befehle oder Daten senden, Daten, Datenanforderungen und Antworten empfangen und die Verbindung trennen kann; und (b) Zielfunktionalität.
  • 7 zeigt, wie vorstehend erwähnt, Aspekte der selektiven Kommunikationsprotokollschichtung für die synchrone Replikation zwischen einem oder mehreren Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Genauer gesagt, als Teil einer beispielhaften Ausführungsform der selektiven Kommunikationsprotokollschichtung oder eines Replikationsprotokolls oder -schemas, veranschaulicht 7 ein Beispielverfahren eines Listen/Get-Pfad-Kontrollflusses als Teil eines Erkennungsprozesses.
  • In einigen Implementierungen kann ein Speichersystem Pfadänderungen zu einem entfernten Speichersystem abfragen, wobei, wenn Replikationsdienste hinzugefügt werden, eine Benachrichtigung für jedes betroffene Speichersystem innerhalb des aktiven Clusters von Speichersystemen empfangen werden kann.
  • Darüber hinaus kann in einigen Implementierungen eine entsprechende Benachrichtigung für jedes betroffene andere Speichersystem empfangen werden, wenn eine Änderung der Fibre-Channel-Switch-Konfiguration die Konnektivität von einem bestimmten Speichersystem in einem aktiven Cluster zu einem anderen Speichersystem in dem aktiven Cluster beeinflusst.
  • Wie in 7 dargestellt, kann das Einrichten von Pfaden zwischen Speichersystemen zur Unterstützung bidirektionaler Kommunikation, wobei die bidirektionale Kommunikation Replikation, einschließlich synchroner Replikation zwischen einem aktiven Cluster von Speichersystemen, unterstützen kann, Folgendes umfassen: Replikation 702, Replikationstransport 704, NVMe-Erkennung 706 und NVMe-Transport 708.
  • In einigen Implementierungen wird bei Vorhandensein einer oder mehrerer neuer Replikationsprotokoll-Kennungen auf der Replikationsschicht 702, wobei die Replikationsprotokoll-Kennung als Remote-Kennung 712 dargestellt ist, die Remote-Kennung 712 zu einem Satz Remote-Kennungen 713 hinzugefügt, die einem Satz von Speichersystemen entsprechen, welche in einem aktiven Cluster von Speichersystemen enthalten sein können, die Daten untereinander replizieren.
  • In Fortsetzung dieses Beispiels und wie vorstehend in Bezug auf (I)(a)(i) und (I)(a)(ii) erwähnt, kann die Replikationstransportschicht neue Replikationsprotokollkennungen abfragen, und angesichts einer oder mehrerer Replikationsprotokollkennungen kann der Replikationstransport 704 abgefragt werden 716, um Pfade für jede der einen oder mehreren Replikationsprotokollkennungen zu erhalten. Ferner kann in diesem Beispiel für jeden der einen oder mehreren Pfade 717 ein Host, Initiator oder Speichersystem eine Verbindung 719 zu jedem jeweiligen einen oder mehreren Speichersystemen herstellen, die den jeweiligen einen oder mehreren Replikationsprotokollkennungen entsprechen.
  • In einigen Implementierungen kann ein Host, ein Speichersystem oder, allgemeiner, ein Initiator-Datenverarbeitungsgerät eine Host-Replikations-NQN bei einem Erkennungsdienst registrieren 710. Außerdem kann ein Host oder ein Speichersystem als Teil eines Erkennungsprozesses neue lokale/entfernte WWPNs für die Fibre Channel-Adressierung 714 empfangen. In ähnlicher Weise kann, wie dargestellt, ein Abfrage- oder Erkennungsvorgang sowohl für NVMe als auch für Fibre Channel Verbindungsanfrageen 720 und entsprechende Antworten 721, Fabric-Connect 722, Host-Replikations-NQN, Erkennungs-NQN und entsprechende Antworten 727 sowie Get-Log-Page-Anforderungen 724 für die NVMe-Erkennung und entsprechende Antworten 725 mit den angeforderten Protokollseiten mit NVMe-Adressierungsinformationen umfassen. In einigen Beispielen kann ein Discovery-Prozess jedoch auch ohne den Empfang von Log-Page-Anforderungen ablaufen.
  • Im weiteren Verlauf dieses Beispiels kann als Reaktion auf den Empfang neuer NQN- und WWPN-Informationen 726 eine Aktualisierung der Zuordnungsinformationen 727 vorgenommen werden, und angesichts einer neuen Remote-Protokoll-Kennung 728, die durch das Parsen der neuen NQN erhalten wurde, kann eine neue Verbindungsrunde durchgeführt werden - einschließlich des Abrufs von Pfadinformationen 730, der Überprüfung der Zuordnungsinformationen 731 und der Verbindung für jeden der neuen Pfade 732. In einigen Beispielen kann ein Erkennungsprozess jedoch fortgesetzt werden, ohne neue NQN- und WWPN-Informationen zu erhalten. Außerdem wird in einigen Beispielen, auch wenn eine Protokoll-Kennung 728 nicht neu ist, eine entsprechende Benachrichtigung verarbeitet, da sich ein Pfad geändert haben kann.
  • Kurz gesagt, ein Abfrage-Vorgang auf einem Host- oder Initiator-Speichersystem kann NVMe- und Fibre-Channel-Adressierungsinformationen für Speichersysteme erhalten, die Teil eines aktiven Clusters von Speichersystemen werden können, die einen Datensatz untereinander replizieren, und bei denen das Host- oder Initiator-Speichersystem kontinuierlich Pfad- und Verbindungsinformationen abfragt und diese aktualisieren kann.
  • Zur weiteren Erläuterung veranschaulicht 8 Aspekte der selektiven Kommunikationsprotokollschichtung für synchrone Replikation zwischen einem oder mehreren Speichersystemen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Genauer gesagt, als Teil einer beispielhaften Ausführungsform der selektiven Kommunikationsprotokollschichtung oder eines Replikationsprotokolls oder -schemas, veranschaulicht 8 ein Beispielverfahren eines Verbindungs-/Akzeptanzsteuerflusses.
  • Wie vorstehend unter Bezugnahme auf 7 erläutert, kann ein Listen/Get-Pfad-Prozess Pfade zwischen den Speichersystemen einrichten, wenn Speichersysteme online gehen oder anderweitig für die Speichernutzung verfügbar werden, wobei verfügbare Speichersysteme für die Konfiguration oder Nutzung präsentiert werden können. Beispielsweise können einem Benutzer an einer Speichersystem-Verwaltungskonsole eine oder mehrere Speicheroptionen unter mehreren Speichersystemen angezeigt werden, wobei ein Benutzer Objekte, Datensätze, Volumes oder andere Speicherdaten für das Replizieren zwischen ausgewählten Speichersystemen angeben kann. In diesem Beispiel kann bei einem Satz von Speichersystemen eine Replikation oder synchrone Replikation implementiert werden, wie vorstehend mit Bezug auf die 6A-6B beschrieben, und auch innerhalb der Anwendungen, auf die sich die vorliegende Anwendung vorrangig bezieht.
  • In diesem Beispiel kann ein Speichersystem 803 in Anbetracht eines Pfades, wobei ein Pfad wie vorstehend mit Bezug auf 7 beschrieben erhalten wird, eine Verbindung 820 mit einem anderen Speichersystem 805 initiieren. Ferner kann in diesem Beispiel das antwortende Speichersystem 805 mit der Vorbereitung der Replikationstransportschicht 814 auf die Annahme einer eingehenden Verbindungsanfrage 880 reagieren, wobei ausgewählte Schritte des Replikationsprotokolls oder -schemas zum Aufbau einer Verbindung in 8 dargestellt und im Folgenden beschrieben sind.
  • Um mit diesem Beispiel fortzufahren, wie vorstehend mit Bezug auf die Replikationsprotokollschicht und die Remote-Client-Connector-Funktionalität, aufgeführt als (I)(b)(i)-(iii), beschrieben, kann ein Speichersystem angesichts einer Liste von Pfaden Verbindungen zu einem oder mehreren entfernten Speichersystemen initiieren.
  • Wie vorstehend beschrieben, kann jedes Speichersystem innerhalb eines aktiven Clusters oder jedes Speichersystem, das einem aktiven Cluster beitreten kann, ein Replikationsprotokoll oder -schema implementieren, das eine Replikationsschicht, eine Replikationstransportschicht, eine NVMe-Initiatorschicht und eine NVMe-Zielschicht umfasst. In diesem Beispiel enthalten die Speichersysteme (803, 805) diese Schichten, die jeweils als Replikation (802, 816), Replikationstransport (804, 814), NVMe-lnitiator (806, 812) und NVMe-Ziel (808, 810) dargestellt sind.
  • Insgesamt sind in 8 Replikationsprotokollaustausche zum Einrichten - für jeden von einem oder mehreren Pfaden zu einem oder mehreren Speichersystemen - bidirektionaler Kommunikationskanäle zwischen Speichersystemen basierend auf ausgewählten Aspekten der zugrunde liegenden Protokolle dargestellt. In diesem Beispiel ist ein Ergebnis der Einrichtung der bidirektionalen Kommunikation zwischen den Speichersystemen 803, 805, dass jedes jeweilige Speichersystem 803, 805 ein jeweiliges Endpunktobjekt 821, 881 aufweist, das für das Replizieren von Daten zwischen den Speichersystemen 803, 805, einschließlich der synchronen Replikation von Daten, verwendet werden kann.
  • Genauer gesagt kann ein Speichersystem in diesem Beispiel einen Erkennungsprozess initiieren und eine Liste von NVMe-qualifizierten Namen (NQNs) empfangen, wobei jeder NQN so formatiert sein kann, dass er sowohl Standard-NVMe-Adressierungsinformationen als auch eine Replikationsprotokollkennung enthält. Wie vorstehend erwähnt, kann eine Replikationsprotokollkennung unabhängig von den zugrundeliegenden Protokollen sein, einschließlich NVMe und Fibre Channel, wobei die Replikationsprotokollkennung verwendet werden kann, um Speichersysteme zu identifizieren, die in einem aktiven Cluster enthalten sein können.
  • Während Speichersysteme in einigen Beispielen einen Fibre-Channel-Ermittlungsprozess beim Start des Speichersystems oder bei einem Neustart initiieren können, wobei der Fibre-Channel-Ermittlungsprozess das Speichersystem auf andere Speichersysteme in einem Netzwerk aufmerksam machen kann, können Replikationsprotokollkennungen verwendet werden, um andere Speichersysteme und Speicherpools für das Replizieren zwischen den Speichersystemen zu identifizieren.
  • In einigen Beispielen kann ein Benutzer einen Satz von Speichersystemen angeben, die in einem Satz von Speichersystemen in einem aktiven Cluster enthalten sein können, oder allgemeiner kann ein Benutzer Speichersysteme angeben, die für die bidirektionale Replikation von Daten konfiguriert sein können. Beispielsweise kann ein Benutzer ein erstes Speichersystem spezifizieren, das sich in einer Replikationsbeziehung mit einem zweiten Speichersystem befindet, und als Reaktion darauf kann das erste Speichersystem eine Anfrage über ein IP-Netzwerk an das zweite Speichersystem stellen, um die Replikationsprotokollkennung für das zweite Speichersystem anzufordern.
  • Auf diese Weise kann in diesem Beispiel ein bestimmtes Speichersystem Replikationsprotokollkennungen verwenden, um zu bestimmen, welches ein oder mehrere andere Speichersysteme als Teil einer Replikationsbeziehung konfiguriert werden können oder welches andere ein oder mehrere Speichersysteme für die synchrone Replikation von Daten konfiguriert werden können. Ferner kann, wie vorstehend beschrieben, basierend auf der Replikationsprotokollkennung ein entsprechendes Speichersystem ohne Verwendung von World Wide Port Names (WWPNs) auf der Fibre Channel-Schicht adressiert werden.
  • In diesem Beispiel kann ein Speichersystem 803, das eine Verbindung initiiert, als ein Speichersystem der aktiven Seite bezeichnet werden, und ein Speichersystem 805, das auf die Verbindungsanfrage antwortet, kann als ein Speichersystem der passiven Seite bezeichnet werden. In diesem Beispiel kann das Speichersystem 803, das Speichersystem der aktiven Seite, eine anfängliche Verbindungsanfrage ausgeben, um die Kommunikation vom Speichersystem 803 zum Speichersystem 805 herzustellen.
  • Ferner kann in diesem Beispiel als Reaktion auf die Verbindungsanfrage vom Speichersystem 803 das Speichersystem 805 eine Verbindung zum Speichersystem 803 herstellen - wobei die bidirektionale Kommunikation auf der Grundlage der erfolgreichen Einrichtung von Kommunikationskanälen vom Speichersystem 803 zum Speichersystem 805 und vom Speichersystem 805 zum Speichersystem 803 aufgebaut werden kann. Angesichts der Einrichtung der bidirektionalen Kommunikation zwischen dem Speichersystem 803 und dem Speichersystem 805 sind die Speichersysteme 803, 805 so konfiguriert, dass sie Daten replizieren, einschließlich synchroner Replikation von Daten.
  • Im Allgemeinen können aktive Speichersysteme nach Pfaden zu Speichersystemen mit Replikationsprotokollkennungen abfragen, die in einer Replikationsbeziehung oder einem aktiven Cluster enthalten sein können, und die Einrichtung bidirektionaler Kommunikationskanäle zur Unterstützung der Datenreplikation einleiten. In einigen Beispielen können aktive Speichersysteme auch Daten angeben, die in der Replikationsbeziehung repliziert werden sollen, einschließlich der Angabe von einem oder mehreren Datensätzen, Volumes, Objekten oder anderen spezifizierten Formen von Speicherinhalten.
  • Um mit diesem Beispiel fortzufahren, kann das Speichersystem 803 als Reaktion auf die Entdeckung eines neuen Pfades 820 oder eines aktualisierten Pfades auf der Replikationsschicht den Aufbau einer Verbindung 822 zu dem Speichersystem initiieren, das dem neuen oder aktualisierten Pfad 820 entspricht, was in diesem Beispiel das Speichersystem 805 ist. In diesem Beispiel wird als Reaktion auf die Verbindungsanfrage 822 ein Bestimmen 823 durchgeführt, ob derzeit eine Admin-Warteschlange für das Speichersystem 805 eingerichtet ist, wobei, wenn es keine aktuelle Admin-Warteschlange für das Speichersystem 805 gibt, eine Admin-Verbindungsanfrage 824 an das Speichersystem 805 gesendet wird. Ferner kann in diesem Beispiel das Speichersystem 805 als Reaktion auf die Admin-Verbindungsanfrage 824 das Speichersystem 803 als Hostsystem für die Bereitstellung von Daten für die Speicherung festlegen (827).
  • Um mit diesem Beispiel fortzufahren: Als Reaktion auf das Empfangen der administrativen Verbindungsanfrage 824 durch das Speichersystem 805 kann das Speichersystem 805 dem Speichersystem 803 antworten, um die Admin-Warteschlange einzurichten.
  • Zusätzlich zum Einrichten einer Admin-Warteschlange sendet das Speichersystem 803 auch eine E/A-Verbindungsanfrage 828 an das Speichersystem 805, um E/A-Warteschlangen einzurichten, die Daten enthalten, die vom Speichersystem 805 zum Speichersystem 803 übertragen werden sollen. Um mit diesem Beispiel fortzufahren, kann das Speichersystem 805 als Reaktion auf den Empfang der E/A-Verbindungsanfrage 828 durch das Speichersystem 805 eine Antwort 830 an das Speichersystem 803 senden, um eine oder mehrere E/A-Warteschlangen auf dem Speichersystem 803 einzurichten. Weiterhin kann das Speichersystem 805 in diesem Beispiel als Reaktion auf den Empfang der E/A-Verbindungsanfrage 828 durch das Speichersystem 805 feststellen, dass die Verbindung 829 auf der Zielseite, in diesem Fall dem Speichersystem 805, vollständig ist. Wie vorstehend unter Bezugnahme auf die 4A-5 erläutert, können Lesevorgänge durch die Vorabzuweisung von Pufferspeicherplatz effizienter gestaltet werden, um die Anzahl der Nachrichten zu reduzieren, die zur Übertragung von Daten zwischen dem Speichersystem 803 und dem Speichersystem 805 erforderlich sind.
  • In diesem Beispiel können, basierend auf der Einrichtung der administrativen Warteschlange und der einen oder mehreren E/A-Warteschlangen auf dem Speichersystem 803, Daten vom Speichersystem 805 zum Speichersystem 803 übertragen werden, und eine Verbindung 831 aus Richtung des Speichersystems 805 zum Speichersystem 803 kann als hergestellt betrachtet werden.
  • Um mit diesem Beispiel fortzufahren, kann das Speichersystem 805 in Übereinstimmung mit dem Replikationsprotokoll oder -schema als Reaktion auf die Verbindungsanfrage 822 vom Speichersystem 803 und als Teil der Operationen, die als Reaktion auf die Vorbereitung des Speichersystems 805 zum Senden von Daten an das Speichersystem 803 durchgeführt werden, und als Reaktion auf das Bilden einer Verbindung auf der Grundlage der Meldung „Verbindung vollständig 829“ eine Verbindung 832 aus der Richtung des Speichersystems 805 zum Speichersystem 803 initiieren.
  • In diesem Beispiel wird als Reaktion auf die Verbindungsanfrage 832 ein Bestimmen 833 durchgeführt, ob derzeit eine Admin-Warteschlange für das Speichersystem 805 eingerichtet ist, wobei, wenn es keine aktuelle Admin-Warteschlange für das Speichersystem 803 gibt, eine Admin-Verbindungsanfrage 834 an das Speichersystem 803 gesendet wird.
  • Um mit diesem Beispiel fortzufahren, kann das Speichersystem 803 als Reaktion auf das Empfangen der administrativen Verbindungsanfrage 834 dem Speichersystem 805 antworten, um die Admin-Warteschlange einzurichten. Ferner kann das Speichersystem 803 in diesem Beispiel als Reaktion auf die Admin-Verbindungsanfrage 834 das Speichersystem 805 als Hostsystem für das Bereitstellen von Daten für die Speicherung festlegen 835.
  • Zusätzlich zur Einrichtung einer administrativen Warteschlange sendet das Speichersystem 805 auch eine E/A-Verbindungsanfrage 838 an das Speichersystem 803, um E/A-Warteschlangen einzurichten, die Daten enthalten, die vom Speichersystem 805 zum Speichersystem 803 übertragen werden sollen. Um mit diesem Beispiel fortzufahren, kann das Speichersystem 803 als Reaktion auf den Empfang der E/A-Verbindungsanfrage 838 durch das Speichersystem 803 eine Antwort 840 an das Speichersystem 805 senden, um eine oder mehrere E/A-Warteschlangen auf dem Speichersystem 805 einzurichten. Weiterhin kann das Speichersystem 803 in diesem Beispiel als Reaktion auf den Empfang der E/A-Verbindungsanfrage 838 durch das Speichersystem 803 feststellen, dass die Verbindung 839 auf der Zielseite, in diesem Fall dem Speichersystem 803, vollständig ist.
  • In diesem Beispiel können, basierend auf der Einrichtung der administrativen Warteschlange und der einen oder mehreren E/A-Warteschlangen auf dem Speichersystem 805, Daten vom Speichersystem 803 zum Speichersystem 805 übertragen werden, und eine Verbindung 841 aus Richtung des Speichersystems 803 zum Speichersystem 805 kann als hergestellt betrachtet werden.
  • Auf diese Weise können bei Herstellung der Kommunikation in beiden Richtungen zwischen dem Speichersystem 803 und dem Speichersystem 805 die jeweiligen Endpunkte 821, 881 als hergestellt angesehen werden, wie vorstehend mit Bezug auf die Replikationstransportschicht beschrieben, die vorstehend mit Bezug auf (II)(b)(i)-(v) beschrieben wurde.
  • Zur weiteren Erläuterung ist in 9 ein Flussdiagramm dargestellt, das ein Verfahren zum Implementieren der Replikationsverarbeitung zwischen verschiedenen Netzwerken gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht. In diesem Beispiel sind auch ein zusätzliches Speichersystem (950) und ein Computersystem (952) dargestellt. Die Speichersysteme (900, 950) können die vorstehend unter Bezugnahme auf die 1A-1D, 2A-2G, 3A, 3B und 4A-8 beschriebenen Datenspeichereigenschaften implementieren, da die Speichersysteme (900, 950) einige oder alle der in den obigen Figuren beschriebenen Komponenten enthalten können.
  • In einigen Implementierungen können Speichersysteme mehrere verschiedene Replikationsschemata untereinander implementieren, wobei die verschiedenen Replikationsschemata auf einem gemeinsamen Verwaltungsmodell zur Implementierung des Replikationsschemas und des Replikationstransports basieren. In einigen Implementierungen ist das gemeinsame Verwaltungsmodell auch eine Grundlage, die es den Speichersystemen ermöglicht, von einem Typ des Replikationsschemas oder des Replikationstransports zu einem anderen Typ des Replikationsschemas oder des Replikationstransports umzuschalten, da ein und dasselbe gemeinsame Verwaltungsmodell zur Unterstützung der verschiedenen zulässigen Kombinationen von Replikationsschemata und Replikationstransporten verwendet wird.
  • Darüber hinaus können in einigen Implementierungen Kommunikationsverbindungen zwischen Speichersystemen, über die Replikationsdaten und Verwaltungsdaten zwischen Speichersystemen kommuniziert werden, über verschiedene Arten von zugrunde liegenden physikalischen Medienschichten hergestellt werden. Beispielsweise kann ein gegebenes Speichersystem mehrere verschiedene Arten von Netzwerkanschlüssen enthalten, die verschiedene Arten von Netzwerkprotokollen unterstützen, wie z. B. Fibre Channel, TCP/IP, NVMe over Fabrics, InfiniBand und andere Standardnetzwerkprotokolle.
  • Auf diese Weise kann in einigen Implementierungen ein Cluster von Speichersystemen ein oder mehrere verschiedene Replikationsschemata untereinander einrichten, und als Reaktion auf verschiedene Bedingungen können die Speichersysteme ohne Unterbrechung einer Replikationsbeziehung zwischen den Speichersystemen zwischen verschiedenen Replikationsschemata umschalten - wobei der kontinuierliche Betrieb auf den verschiedenen Replikationsschemata unter Verwendung eines gemeinsamen Verwaltungsmodells für die Datenreplikation basieren kann. In einigen Implementierungen kann eine Replikationsbeziehung zwischen zwei Speichersystemen den gleichzeitigen Betrieb mehrerer Replikationstransporte über mehrere Kommunikationsverbindungen umfassen, die auf mehreren, unterschiedlichen zugrunde liegenden physikalischen Medienschichten arbeiten.
  • Darüber hinaus kann ein gemeinsames Verwaltungsmodell in einigen Implementierungen Kommunikationsoperationen spezifizieren, die von den Transportmechanismen einer bestimmten Netzwerknachrichtenschicht gekapselt sind. Beispielsweise kann das gemeinsame Verwaltungsmodell Kommunikationsoperationen bereitstellen, die von einem bestimmten Replikationsschema verwendet werden, wobei die Kommunikationsoperationen keine Spezifikation von Details bezüglich der Operationen einer Messaging-Schicht wie einer Netzwerktransportschicht erfordern. In anderen Beispielen kann ein gemeinsames Verwaltungsmodell jedoch Kommunikationsoperationen oder Netzwerkoperationen spezifizieren, die mehr oder weniger Einblick in die Transportmechanismen einer bestimmten Netzwerktransportschicht haben.
  • Wenn man mit dieser Beispielimplementierung fortfährt und davon ausgeht, dass das gemeinsame Verwaltungsmodell die Kommunikation zwischen Speichersystemen nicht auf einer Protokollstapelschicht spezifiziert, die niedriger ist als eine Netzwerktransportschicht, können Speichersysteme - zusätzlich zum Umschalten zwischen verschiedenen Replikationsschemata oder anstelle des Umschaltens zwischen verschiedenen Replikationsschemata - zwischen verschiedenen Netzwerkanschlüssen umschalten, die verschiedene Arten von Netzwerktransportprotokollen für verschiedene Arten von zugrunde liegenden physischen Netzwerken implementieren.
  • Mit anderen Worten: Da in einigen Implementierungen mehrere Netzwerkprotokollstapel für ein Replikationsschema gleichzeitig vom gemeinsamen Verwaltungsmodell unterstützt werden, kann das gemeinsame Verwaltungsmodell mit einem bestehenden Replikationsschema fortfahren oder zu einem anderen Replikationsschema umschalten, ohne dass die physikalischen Transportmechanismen, die zur Kommunikation der Replikationsdaten oder Verwaltungsdaten verwendet werden, bekannt sind.
  • Kurz gesagt, in einigen Implementierungen kann das gemeinsame Verwaltungsmodell eine konsistente und einheitliche Schnittstelle zu abweichenden oder unterschiedlichen zugrunde liegenden Netzwerk-Messaging-Mechanismen bieten. Beispielsweise kann unter mehreren Netzwerkanschlüssen eines bestimmten Speichersystems ein Netzwerkanschluss mit einem TCP/IP-Netzwerk und ein anderer Netzwerkanschluss mit einem Fibre Channel-Netzwerk verbunden sein. In ähnlicher Weise können zusätzliche Netzwerkanschlüsse zusätzliche Kommunikationsverbindungen in Übereinstimmung mit einem oder mehreren zugrunde liegenden Netzwerk-Messaging-Mechanismen unterstützen.
  • In einigen Implementierungen kann ein Speichersystem, das so konfiguriert ist, dass es mehrere Kommunikationsverbindungen über verschiedene zugrundeliegende physische Netzwerke herstellt, weiterhin ein bestimmtes Replikationsschema über ein erstes Netzwerk betreiben und gleichzeitig andere Speichersystemfunktionen ausführen, ohne die Datenreplikation zu unterbrechen.
  • Zum Beispiel kann ein erstes Speichersystem ein erstes Replikationsschema implementieren, um eine Replikationsbeziehung mit einem zweiten Speichersystem über einen ersten Netzwerkanschluss und ein erstes Netzwerk herzustellen, und gleichzeitig ein zweites Replikationsschema implementieren, um eine Replikationsbeziehung mit einem dritten Speichersystem (oder in einigen Fällen mit demselben zweiten Speichersystem) über einen zweiten Anschluss und ein zweites Netzwerk herzustellen.
  • In Fortsetzung dieses Beispiels kann ein Speichersystem-Verwaltungsdienst einen Speichersystem-Verwaltungsbefehl ausgeben, der von dem ersten Speichersystem empfangen wird, wobei der Speichersystem-Verwaltungsbefehl die Einleitung eines Speichersystem-Upgrades anzeigt. In diesem Beispiel kann das erste Speichersystem als Reaktion auf den Upgrade-Befehl die Datenreplikation für einen Netzwerkanschluss aussetzen, der für das Speichersystem-Upgrade verwendet werden soll.
  • Auf diese Weise kann in diesem Beispiel ein Speichersystem die Datenreplikation unter Verwendung eines oder mehrerer Replikationsschemata mit einem anderen Speichersystem fortsetzen, während gleichzeitig ein Upgrade des Speichersystems durchgeführt wird - wobei die Datenreplikation zwischen den Speichersystemen ohne Unterbrechung durch das Upgrade des Speichersystems fortgesetzt wird.
  • In einigen Implementierungen kann ein Speichersystem von Komponenten, die für einen Mechanismus zur Replikationskommunikation ausgelegt sind, auf Komponenten umgestellt werden, die für einen anderen Mechanismus zur Replikationskommunikation ausgelegt sind. Ein Beispiel: Ein Speichersystem kann von einer Konfiguration mit mehreren Ethernet-Anschlüssen für die Replikationskommunikation zu einer Konfiguration mit Anschlüssen für die Verwendung von Fibre Channel für das Replizieren übergehen oder aktualisiert werden, wobei in einigen Fällen der Fibre Channel-Anschluss einen vorhandenen Netzwerkanschluss, z. B. einen Ethernet-Anschluss, ersetzen kann. In Fortsetzung dieses Beispiels kann ein Replikationsschema als Reaktion auf ein Upgrade oder die Hinzufügung des Fibre-Channel-Anschlusses von der Verwendung von Replikationstransportmechanismen, die auf Ethernet beruhen, auf Replikationstransportmechanismen, die auf Fibre Channel beruhen, umschalten - wobei das Replikationsschema von der Verwendung eines Replikationstransportmechanismus zur Verwendung eines anderen Replikationstransportmechanismus übergehen kann, ohne das Replizieren eines Datensatzes zu unterbrechen, der mit demselben Replikationsschema repliziert wird. Auf diese Weise kann in diesem Beispiel ein Upgrade oder eine Ergänzung vor der Verwendung getestet werden, wobei die Umstellung des Replikationsschemas auf die Verwendung des aktualisierten oder hinzugefügten Netzwerkmechanismus den Betrieb des Replikationsschemas nicht unterbricht.
  • Als Teil eines solchen Übergangs von einem Netzwerkport oder Netzwerktransportmechanismus zu einem anderen Netzwerkport oder Netzwerktransportmechanismus kann eine zweite, neue Netzwerkverbindung (z. B. ein neuer Port oder ein neuer Netzwerktransportmechanismus) so konfiguriert werden, dass sie parallel zu einer ersten, früheren Netzwerkverbindung (z. B. ein früherer Port oder ein neuer Netzwerktransportmechanismus) läuft, die dem Übergang vorausging. Die Verwendung der zweiten Netzwerkverbindung kann dann getestet werden, indem Nachrichten sowohl über die zweite Verbindung als auch über die erste Verbindung gesendet werden. Bei den über die zweite Verbindung gesendeten Nachrichten kann es sich um einen Bruchteil der gesamten Nachrichten handeln, die mit der Replikation verbunden sind, oder um Testnachrichten, oder um Duplikate von Nachrichten, die über die erste Verbindung gesendet wurden. Durch Messungen dieser Nachrichten kann dann festgestellt werden, dass die neue Netzwerkverbindung ausreicht, um sicherzustellen, dass das Replizieren den Übergang abschließen kann, z. B. indem festgestellt wird, dass eine Kombination aus Netzwerkbandbreite, Latenz, Paketverlust, CPU-Overhead oder anderen Faktoren ausreicht, um das Replizieren ohne die erste, vorherige Netzwerkverbindung fortzusetzen. Sobald die zweite Netzwerkverbindung erprobt ist, kann die Verwendung der ersten Netzwerkverbindung eingestellt werden.
  • Es ist zu beachten, dass diese Übergänge möglicherweise parallel auf einem ersten und einem zweiten Speichersystem stattfinden müssen, die eine Replikationsbeziehung aufweisen. Infolgedessen müssen zwei Speichersysteme mit einer solchen Replikationsbeziehung möglicherweise die Aufrüstung von Komponenten, die Konfiguration neuer Netzwerkverbindungen, das Testen neuer Netzwerkverbindungen und den Abschluss des Übergangs von einer ersten, früheren Netzwerkverbindung zu einer zweiten, neuen Netzwerkverbindung koordinieren.
  • In einigen Implementierungen kann das dargestellte Computersystem (952) durch ein Speichersystem implementiert werden, wie in den obigen 1A-8 beschrieben. In anderen Beispielen kann das Computersystem (952) jedoch durch ein beliebiges Datenverarbeitungsgerät implementiert werden, einschließlich mobiler Geräte, Desktop-Computer oder Server.
  • Weiterhin kann in anderen Implementierungen das dargestellte Computersystem (952) eine virtuelle Recheninstanz sein, wie z. B. ein Rechenknoten oder eine Recheninstanz innerhalb einer Cloud-Computing-Umgebung. Beispielsweise kann das Computersystem (952) ein virtuelles Computersystem sein, das in einer Cloud-Computing-Umgebung implementiert ist, wie die Cloud-Computing-Umgebung, die unter Bezugnahme auf die 3A-3D beschrieben ist.
  • In Fortsetzung dieses Beispiels kann das virtuelle Computersystem (952) als Teil eines Speichersystem-Verwaltungsdienstes innerhalb eines Cloud-Speichersystem-Verwaltungsdienstes implementiert werden. In diesem Beispiel kann der Cloud-Speichersystem-Verwaltungsdienst eines oder mehrere der Speichersysteme (900, 950) verwalten, einschließlich der Überwachung des Status und des Zustands der Speichersysteme (900, 950) und der Bereitstellung von Updates oder Konfigurationsänderungen für die Speichersysteme (900, 950).
  • In einigen Implementierungen kann jedes Speichersystem (900, 950) entsprechende Implementierungen mehrerer, unterschiedlicher Replikationstypen unterstützen. In einigen Beispielen können unterschiedliche Replikationsschemata unter anderem nicht aufgeführte synchrone Replikation, nahezu synchrone Replikation, asynchrone Replikation, konfigurierbare asynchrone Replikation, Snapshot-basierte Replikation, kontinuierliche Datenreplikation, periodische Replikation oder eine Kombination aus konfigurierbarer asynchroner Datenreplikation und dynamisch bestimmten Snapshot-Aktualisierungen umfassen. Beispiele für verschiedene dieser Replikationsschemata sind vorstehend mit Bezug auf die 4A-8 beschrieben.
  • In einigen Implementierungen können die vorstehend aufgelisteten Replikationsschemata auf der Grundlage eines gemeinsamen oder einheitlichen Verwaltungsmodells implementiert werden, wobei das gemeinsame Verwaltungsmodell ein gleiches oder ähnliches Metadatenmodell zur Darstellung gespeicherter Daten umfasst, wie z. B. die vorstehend mit Bezug auf 4B beschriebene Metadaten-Darstellung. In einigen Implementierungen kann ein bestimmtes Speichersystem beispielsweise jedes der vorstehend aufgeführten Replikationsschemata verwenden, um eine Replikationsbeziehung zwischen einem oder mehreren anderen Speichersystemen herzustellen, wobei die Implementierung eines Replikationsschemas auf einem Verwaltungsmodell basiert, das allen an einer Replikationsbeziehung beteiligten Speichersystemen gemeinsam ist, wobei das gemeinsame Verwaltungsmodell zur Implementierung jedes der vorstehend aufgeführten Replikationsschemata verwendet werden kann.
  • In einigen Implementierungen kann zwar jedes Speichersystem ein gemeinsames Verwaltungsmodell implementieren, aber in einigen Beispielen kann jedes an der Replikationsbeziehung teilnehmende Speichersystem seine eigene Kopie eines zu replizierenden Datensatzes und eine entsprechende Verwaltungsmodell-Spezifikation der internen Verwaltung eines Metadatenmodells und relevanter Datenstrukturen zur Definition von Speicherobjekten, zur Abbildung von Objekten auf physischen Speicher, zur Deduplizierung, zur Definition der Abbildung von Inhalten auf Snapshots usw. aufweisen.
  • In einigen Implementierungen kommuniziert jedes der verschiedenen Replikationsschemata mit der jeweils unterschiedlichen Art und Weise, in der das Replizieren erreicht wird, an irgendeinem Punkt Daten oder administrative Informationen über ein Netzwerk oder eine Kommunikationsstruktur von einem Speichersystem zu einem anderen oder mehreren Speichersystemen.
  • Mit anderen Worten, in einigen Implementierungen kann ein bestimmtes Replikationsschema unter den vorstehend aufgeführten Replikationsschemata Netzwerk- oder Kommunikationsoperationen spezifizieren, die die Kommunikation zwischen verschiedenen Speichersystemen spezifizieren. In Fortsetzung dieses Implementierungsbeispiels kann das gegebene Replikationsschema jedoch keine Implementierungsdetails in Bezug auf physikalische Medienschichten eines Netzwerkstapels, wie z. B. eine Netzwerkschicht, eine Datenverbindungsschicht oder eine physikalische Schicht, angeben. In einigen Beispielen entkoppelt eine solche Kapselung jedes gegebene Replikationsschema von der Kenntnis der Netzwerktransportmechanismen, was als Grundlage für den Wechsel zwischen Replikationstransportmechanismen ohne Unterbrechung der Replikationsschemata dient. Einige Replikationstransportmechanismen unterstützen jedoch möglicherweise nur einige Replikationsschemata; beispielsweise kann eine synchrone Replikation von einem Kommunikationsmechanismus mit niedriger Latenz und geringem Overhead unterstützt werden, wie NVMe über Fabric, NVMe über FC oder SCSI über FC.
  • Auf diese Weise wird in Fortsetzung dieser Beispielimplementierung für jedes der vorstehend aufgeführten Replikationsschemata das Senden oder Empfangen von Daten zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) auf ähnliche Weise implementiert, unabhängig davon, ob es sich bei der Medienschicht unterhalb der Netzwerknachrichtenschicht um ein Fibre-Channel-Netzwerk, ein TCP/IP-Netzwerk oder eine andere Art von physischem Netzwerk, einschließlich drahtloser Netzwerke, handelt.
  • Folglich sind in einigen Implementierungen der Replikationsabwicklung zwischen verschiedenen Netzwerken, unabhängig davon, ob ein Speichersystem asynchrone Replikation, synchrone Replikation oder ein anderes Replikationsschema implementiert, die Spezifikationen des Replikationsschemas für die Kommunikation mit einem anderen Speichersystem gleich.
  • In einigen Implementierungen können ein oder mehrere Speicher-Controller jede von mehreren Replikationsbeziehungen von einem bestimmten Speichersystem zu einem oder mehreren anderen Speichersystemen verwalten, wobei jede Replikationsbeziehung über ein jeweiliges Netzwerk und eine entsprechende Netzwerkprotokollschicht implementiert werden kann. Beispielhafte Speichersystem-Controller werden vorstehend unter Bezugnahme auf die 1A-3D ausführlicher beschrieben.
  • In einigen Implementierungen kann das Verhalten einer Replikationsbeziehung zwischen Speichersystemen durch eine Replikationsrichtlinie festgelegt werden. Beispielsweise kann eine Replikationsrichtlinie als ein Verwaltungsobjekt betrachtet werden, das das Verhalten, die Regeln und/oder die Eigenschaften zwischen Speichersystemen spezifiziert. Ferner kann in einigen Beispielen eine Replikationsrichtlinie ein Quellspeichersystem als Quelle für Daten und ein oder mehrere Zielspeichersysteme als Ziel für Replikationsdaten festlegen.
  • Darüber hinaus kann eine Replikationsrichtlinie in einigen Beispielen zu replizierende Speicherdaten, Checkpoint-Informationen, eine Metadaten-Darstellung für die zu replizierenden Speicherdaten und/oder Metadatenprotokolle oder Metadatenjournale angeben. In einigen Beispielen kann eine Datenquelle als ein Volume, ein strukturierter oder unstrukturierter Datensatz, ein Bucket, eine Datei innerhalb eines Dateisystems, ein ganzes Dateisystemverzeichnis oder als eine Kombination von Datenquellen angegeben werden.
  • Weiterhin kann in einigen Implementierungen eine Replikationsrichtlinie Bedingungen oder Regeln spezifizieren, die jede Bedingung oder Regel für die Änderung des Verhaltens eines Replikationsschemas, das Umschalten zwischen Replikationsschemata, sowohl die Änderung des Verhaltens eines Replikationsschemas als auch das Umschalten zwischen verschiedenen Netzwerken oder sowohl das Umschalten zwischen Replikationsschemata als auch das Umschalten zwischen verschiedenen Netzwerken bestimmen.
  • In einigen Implementierungen kann eine Replikationsrichtlinie beispielsweise festlegen, dass, wenn ein Fibre-Channel-Netzwerk zwischen den Speichersystemen verfügbar ist, ein anfängliches Replikationsschema, das zwischen den Speichersystemen verwendet wird, ein synchrones Replikationsschema sein kann. Ferner kann in diesem Beispiel die Replikationsrichtlinie festlegen, dass das synchrone Replikationsschema fortgesetzt wird, sofern keine Änderungen am Zustand des Netzwerks oder an der verfügbaren Bandbreite auftreten.
  • In anderen Beispielen kann die Replikationsrichtlinie jedoch festlegen, dass als Reaktion auf die Synchronisierung eines Datensatzes mit einem synchronen Replikationsschema das Replikationsschema zu einem anderen Replikationsschema wechselt, z. B. asynchrone Replikation, Snapshot-basierte Replikation oder eines der anderen vorstehend aufgeführten Replikationsschemata.
  • In einigen Implementierungen kann, als weiteres Beispiel, eine Replikationsrichtlinie festlegen, dass, wenn ein TCP/IP-Netzwerk verfügbar ist, ein anfängliches Replikationsschema, das zwischen Speichersystemen verwendet werden soll, ein asynchrones Replikationsschema oder ein nahezu synchrones Replikationsschema sein kann. Weiterhin kann in diesem Beispiel die Replikationsrichtlinie festlegen, dass, wenn ein Fibre-Channel-Netzwerk verfügbar wird, die Replikationsrichtlinie zu einer synchronen Replikationsrichtlinie wechselt und auch zur Verwendung des Fibre-Channel-Netzwerks wechselt.
  • In einigen Implementierungen kann eine Replikationsrichtlinie den Replikationsausgleich zwischen verschiedenen Netzwerken zu verschiedenen Speichersystemen festlegen. Wenn z. B. ein erstes Speichersystem sowohl über Fibre Channel als auch über IP mit einem zweiten Speichersystem verbunden ist und das erste Speichersystem nur über IP mit einem dritten Speichersystem verbunden ist, kann die Replikationsrichtlinie festlegen, dass ein Netzwerkausgleich wenn möglich die Verteilung von Replikationsbeziehungen auf mehrere verschiedene Speichersysteme auf mehrere verschiedene Netzwerke beinhaltet.
  • Um zu vermeiden, dass Daten sowohl an das zweite Speichersystem als auch an das dritte Speichersystem über dasselbe IP-Netzwerk repliziert werden, kann in diesem Beispiel die Replikationsrichtlinie festlegen, dass das Replikationsschema zwischen dem ersten Speichersystem und dem dritten Speichersystem IP verwendet, und festlegen, dass das Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem ein anderes Netzwerk verwendet, falls verfügbar, was in diesem Fall ein Fibre-Channel-Netzwerk ist, so dass das Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem angegeben ist, um das Fibre-Channel-Netzwerk zu verwenden.
  • In Fortsetzung dieses Beispiels kann die Replikationsrichtlinie zusätzlich zum Bestimmen, wie welches Replikationsschema unter den verfügbaren Netzwerken auf verschiedene Speichersysteme verteilt werden soll, bei einer Auswahl von Netzwerken, die zwischen den Speichersystemen verwendet werden sollen, angeben, welches der Replikationsschemata unter der Auswahl von Netzwerken zu den anderen Speichersystemen verwendet werden soll. In diesem Beispiel kann die Auswahl des Replikationsschemas ähnlich wie bei den vorstehend aufgeführten Beispielen durchgeführt werden.
  • In einigen Implementierungen kann eine Replikationsrichtlinie Bedingungen oder Regeln festlegen, die auf dem zugrunde liegenden Netzwerkzustand oder den zugrunde liegenden Bandbreiteneigenschaften basieren. Wenn sich beispielsweise das Netzwerkverhalten ändert oder wenn es Anzeichen für eine Verschlechterung des Netzwerkzustands oder für einen möglichen Netzwerkausfall gibt, kann die Replikationsrichtlinie von einem aktuellen Replikationsschema zu einem Replikationsschema mit geringerer Bandbreite umschalten.
  • In anderen Beispielen kann eine Replikationsrichtlinie festlegen, dass bei Hinweisen auf eine Verschlechterung des Netzwerkzustands oder bei Hinweisen auf einen möglichen Netzwerkausfall die Replikationsrichtlinie von der Verwendung eines aktuellen Netzwerks für ein aktuelles Replikationsschema auf die Verwendung eines anderen Netzwerks für ein gleiches Replikationsschema oder auf die Verwendung eines anderen Netzwerks und den Wechsel zu einem anderen Replikationsschema umschaltet.
  • In einigen Implementierungen kann eine Replikationsrichtlinie - zusätzlich zu oder anstelle der Reaktion auf den Netzwerkzustand - durch Umschalten von Netzwerken Reaktionen auf Änderungen der Netzwerklast oder der Verfügbarkeit der Netzwerkbandbreite festlegen. Beispielsweise kann eine Replikationsrichtlinie festlegen, dass ein Replikationsschema als Reaktion auf eine Netzwerkbandbreitenverfügbarkeit, die unter einen bestimmten Schwellenwert fällt, - ohne Umschalten von Netzwerken oder Umschalten zwischen Messaging-Schichten - von einem aktuellen Replikationsschema zu einem Replikationsschema wechselt, das weniger Netzwerkbandbreite verwendet. Beispielsweise kann die Replikationsrichtlinie einen Wechsel von synchroner Replikation zu Snapshot-basierter Replikation oder einer anderen Art von Replikationsschema mit geringerem Bandbreitenverbrauch vorsehen.
  • In einigen Implementierungen kann eine Replikationsrichtlinie zusätzlich zu oder anstelle der Reaktion auf den Netzwerkzustand durch Umschalten von Netzwerken Reaktionen auf Änderungen der Netzwerklast oder der Verfügbarkeit der Netzwerkbandbreite festlegen. Beispielsweise kann eine Replikationsrichtlinie festlegen, dass als Reaktion auf eine Netzwerkbandbreitenverfügbarkeit, die unter einen bestimmten Schwellenwert fällt, von einem aktuellen Netzwerk für ein aktuelles Replikationsschema auf ein anderes Netzwerk umgeschaltet wird, wobei die Umschaltung auf das andere Netzwerk mit demselben Replikationsschema fortgesetzt werden kann oder auch die Umschaltung auf ein anderes Replikationsschema beinhaltet. Wenn die Umschaltung das Umschalten von Replikationsschemata beinhaltet, kann in diesem Beispiel die Auswahl eines anderen Replikationsschemas wie vorstehend beschrieben durchgeführt werden.
  • Darüber hinaus kann in einigen Implementierungen jedes Speichersystem, das an einer Replikationsbeziehung gemäß einem der vorstehend genannten Replikationsschemata beteiligt ist, ein gemeinsames oder gemeinsames Verwaltungsmodell implementieren, das eine Metadaten-Darstellung, ein Implementierungsmodell oder persistente Datenstrukturen zur Implementierung jedes der vorstehend genannten Replikationsschemata spezifiziert.
  • Als eine Beispielimplementierung für das Umschalten zwischen Replikationsschemata, welche Pods verwenden, kann eine Replikationsbeziehung zwischen zwei Speichersystemen (900, 950) von einer Beziehung, in der Daten asynchron repliziert werden, zu einer Beziehung, in der Daten synchron repliziert werden, umgeschaltet werden. Wenn beispielsweise ein erstes Speichersystem (900) so konfiguriert ist, dass es einen Datensatz asynchron auf ein zweites Speichersystem (950) repliziert, kann durch das Erstellen eines Pods, der den Datensatz, das erste Speichersystem (900) als Element und das zweite Speichersystem (950) als Element enthält, die Beziehung, in der Daten asynchron repliziert werden, auf eine Beziehung umgeschaltet werden, in der Daten synchron repliziert werden.
  • In ähnlicher Weise kann, um mit diesem Beispiel fortzufahren, durch die Verwendung von Pods die Replikationsbeziehung zwischen zwei Speichersystemen von einer Beziehung, in der Daten synchron repliziert werden, zu einer Beziehung, in der Daten asynchron repliziert werden, umgeschaltet werden. Wenn z. B. ein Pod erstellt wird, der den Datensatz enthält, wobei der Pod das erste Speichersystem (900) als Element und das zweite Speichersystem (950) als Element enthält, kann durch Aufheben des Pods (zum Entfernen des ersten Speichersystems (900) als Element oder zum Entfernen des zweiten Speichersystems (950) als Element) eine Beziehung, in der Daten zwischen den Speichersystemen synchron repliziert werden, sofort in eine Beziehung umgeschaltet werden, in der Daten asynchron repliziert werden. Auf diese Weise können die Speichersysteme (900, 950) in einigen Implementierungen nach Bedarf zwischen asynchroner Replikation und synchroner Replikation hin- und herwechseln.
  • Außerdem kann in diesem Beispiel das Umschalten dadurch erleichtert werden, dass die Implementierung auf ähnliche Techniken sowohl für die synchrone als auch für die asynchrone Replikation zurückgreift. Wenn beispielsweise die Re-synchronisierung für einen synchron replizierten Datensatz auf demselben oder einem kompatiblen Mechanismus beruht wie bei der asynchronen Replikation, dann ist der Wechsel zur asynchronen Replikation konzeptionell identisch mit dem Verlassen des In-Sync-Zustands und dem Verlassen einer Beziehung in einem Zustand, der einem „Perpetual Recovery“-Modus ähnelt. Ebenso kann das Umschalten von asynchroner Replikation auf synchrone Replikation konzeptionell durch „Aufholen“ und Eintreten des In-Sync-Zustands erfolgen, genau wie beim Abschluss einer Resynchronisierung, bei der das umschaltende System ein In-Sync-Pod-Element wird.
  • In einigen Implementierungen, alternativ oder zusätzlich, da sowohl die synchrone als auch die asynchrone Replikation auf ähnlichen oder identischen gemeinsamen Metadaten beruhen (oder auf einem gemeinsamen Modell für die Darstellung und Identifizierung von Logical Extents oder gespeicherten Blockidentitäten oder auf einem gemeinsamen Modell für die Darstellung von inhaltsadressierbaren gespeicherten Blöcken), können diese Aspekte der Gemeinsamkeit genutzt werden, um den Inhalt, der beim Umschalten zwischen synchroner und asynchroner Replikation möglicherweise übertragen werden muss, drastisch zu reduzieren.
  • Wenn ein Datensatz asynchron von einem ersten Speichersystem (900) auf ein zweites Speichersystem (950) repliziert wird und das zweite Speichersystem (950) diesen Datensatz weiter asynchron auf ein drittes Speichersystem (nicht dargestellt) repliziert, kann ein gemeinsames Metadatenmodell, ein gemeinsamer Logical Extent oder eine Blockidentität oder eine gemeinsame Darstellung von inhaltsadressierbaren gespeicherten Blöcken die Datenübertragungen, die erforderlich sind, um eine synchrone Replikation zwischen dem ersten Speichersystem (900) und dem dritten Speichersystem zu ermöglichen, drastisch reduzieren.
  • Das Flussdiagramm in 9 veranschaulicht ein Verfahren zum Handhaben von Replikationen zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung.
  • Das in 9 dargestellte Beispielverfahren umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweite Typ von Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem auf das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über den ersten Typ von Netzwerknachrichtenschicht (960) kann mithilfe mehrerer Techniken erfolgen. Wie vorstehend unter Bezugnahme auf die 4A-8 beschrieben, kann eine Kommunikationsverbindung beispielsweise mithilfe einer Netzwerknachrichtenschicht eines Standardnetzwerkprotokolls wie Fibre Channel, TCP/IP, NVMe over Fabrics und anderen hergestellt werden. In anderen Beispielen kann eine Kommunikationsverbindung auf Basis einer selektiven Protokollschichtung aufgebaut werden, wie vorstehend mit Bezug auf die 7 und 8 beschrieben. Wie vorstehend beschrieben, kann die Netzwerknachrichtenschicht eine Netzwerktransportschicht sein.
  • Weiterhin kann in diesem Beispiel, wie vorstehend beschrieben, eine Replikationsrichtlinie Bedingungen, Regeln und/oder Kriterien angeben, auf denen eine Auswahl eines verfügbaren Netzwerktyps und eines entsprechenden zu verwendenden Netzports basiert. Weiterhin kann eine Replikationsrichtlinie in diesem Beispiel Bedingungen oder Kriterien angeben, auf denen die Auswahl des zu verwendenden Replikationsschemas basiert. In einigen Beispielen kann eine Replikationsrichtlinie mit einem jeweiligen zu replizierenden Datensatz verknüpft sein, wobei der Datensatz eine beliebige Art der Organisation von Daten sein kann, wie vorstehend beschrieben.
  • Das Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ von Netzwerknachrichtenschicht (964) kann mit mehreren Techniken durchgeführt werden. Beispielsweise kann ein entferntes Computersystem (952) über eine automatisierte Konfigurationsverwaltungssoftware verfügen oder einem Administrator eine Verwaltungskonsole für das Speichersystem zur Verfügung stellen, wobei der Administrator oder die Konfigurationsverwaltungssoftware ein Update ausgeben kann, das eine Konfigurationsänderung an einem oder mehreren Aspekten der Software oder der Firmware des Speichersystems (900) oder an beiden durchführt. In anderen Beispielen kann die Konfigurationsverwaltungssoftware in einer Cloud-Computing-Umgebung implementiert sein, oder ein Administrator kann über einen Cloud-Service-Anbieter auf eine Speichersystem-Verwaltungskonsole zugreifen.
  • Weiterhin kann in diesem Beispiel der zweite Typ von Netzwerknachrichtenschicht (964) als Teil eines Netzwerkprotokolls implementiert sein, das über ein Netzwerk arbeitet, welches über einen Netzwerkanschluss zugänglich ist, der sich von einem Netzwerkanschluss unterscheidet, der Zugang zu einem anderen Netzwerk bietet, über das der erste Typ von Netzwerknachrichtenschicht (960) arbeitet.
  • Das Replizieren (906) von Daten (970) aus dem ersten Speichersystem in das zweite Speichersystem kann wie vorstehend beschrieben durchgeführt werden, ohne dass die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) unterbrochen wird. Beispielsweise kann das erste Speichersystem (900) angesichts einer eingerichteten Kommunikationsverbindung, über die ein Replikationsschema arbeiten kann, Daten (970) an das andere Speichersystem (950) gemäß dem Replikationsschema unter Verwendung einer Messaging-Schicht (960) replizieren, die unabhängig und verschieden von der Messaging-Schicht (964) ist, über die die Konfigurationsänderung von dem Computersystem (952) an das Speichersystem (900) übertragen wird.
  • Zur weiteren Erläuterung zeigt 10 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 10 dargestellte Beispielverfahren ähnelt dem in 9 dargestellten Beispielverfahren insofern, als das in 10 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 10 dargestellte Beispielverfahren spezifiziert jedoch weiter, dass das Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ von Netzwerknachrichtenschicht das Aktualisieren (1006) einer oder mehrerer Softwarekomponenten auf dem ersten Speichersystem (900) umfasst. Weiterhin umfasst das Beispielverfahren in 10 auch: Replizieren (1002), über eine zweite Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950), eines Teils (1052) eines Datensatzes, wobei die Kommunikationsverbindung über den ersten Typ von Netzwerknachrichtenschicht eine erste Kommunikationsverbindung ist; Unterbrechen (1004) des Replizierens über die zweite Kommunikationsverbindung, um die Konfigurationsänderung zu initiieren; Aufbauen (1008) einer dritten Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) auf der Grundlage der aktualisierten einen oder mehreren Software- oder Hardwarekomponenten; und Replizieren (1010) zusätzlicher Teile (1054) des Datensatzes über die dritte Kommunikationsverbindung, wobei das Replizieren über die dritte Kommunikationsverbindung einen Typ einer Netzwerknachrichtenschicht (1060) verwendet, der sich von dem ersten Typ von Netzwerknachrichtenschicht unterscheidet.
  • In diesem Beispiel kann ein Datensatz (1050), der zwischen den Speichersystemen (900, 950) repliziert wird, mehrere Datenteile (970, 1052, 1054) enthalten, wobei die mehreren Datenteile über mehrere Kommunikationsverbindungen und entsprechende Nachrichtenschichten übertragen werden können. Ferner kann in diesem Beispiel, wie unten ausführlicher beschrieben, das Replizieren entlang einer der Kommunikationsverbindungen unterbrochen werden, um das Speichersystem (900) zu aktualisieren, damit es einen anderen Typ von Netzwerknachrichtenschicht verwenden kann, wobei das Replizieren des Datensatzes (1050) nach der Aktualisierung über eine Kommunikationsverbindung fortgesetzt werden kann, die die neue Art der Messaging-Schicht verwendet.
  • Das Replizieren (1002) eines Teils (1052) des Datensatzes über eine zweite Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950), wobei die Kommunikationsverbindung über den ersten Typ von Netzwerknachrichtenschicht eine erste Kommunikationsverbindung ist, kann in ähnlicher Weise wie vorstehend unter Bezugnahme auf das Replizieren (906) von Daten (970) von dem ersten Speichersystem (950) zu dem zweiten Speichersystem beschrieben durchgeführt werden. In einigen Beispielen kann die zweite Kommunikationsverbindung - vor dem Aktualisieren (1006) - über denselben Typ von Netzwerknachrichtenschicht (960) wie die erste Kommunikationsverbindung erfolgen. In einem Beispiel kann die Netzwerknachrichtenschicht (960), die sowohl von der ersten als auch von der zweiten Kommunikationsverbindung verwendet wird, Ethernet sein, wobei die aktualisierte Netzwerknachrichtenschicht Fibre Channel sein kann; jedoch können alle vorstehend beschriebenen Nachrichtenübertragungsschichtprotokolle den anfänglichen und/oder aktualisierten Komponenten zum Einrichtung eines Netzwerkkommunikationsprotokolls und einer Netzwerknachrichtenschicht entsprechen. In diesem Beispiel kann das Replizieren (1002) vor der Initiierung (904) der Konfigurationsänderung durchgeführt werden.
  • Die Unterbrechung (1004) der Replikation (1002) über die zweite Kommunikationsverbindung, um die Konfigurationsänderung zu initiieren (904), kann dadurch erfolgen, dass das Replikationsschema auf einen Befehl von einem Speicher-Controller reagiert, das Replizieren auszusetzen.
  • Das Aktualisieren (1006) einer oder mehrerer Softwarekomponenten auf dem ersten Speichersystem (900) kann durchgeführt werden, indem das Speichersystem (900) über eine Kommunikationsverbindung, die ein bestimmtes Netzwerkprotokoll und einen entsprechenden Netzwerknachrichtendienst (964) verwendet, einen Befehl oder eine Anweisung empfängt, der/die eine Aktualisierung oder ein Upgrade der Software des Speichersystems (900), der Firmware oder sowohl der Software als auch der Firmware spezifiziert. Wie vorstehend erwähnt, arbeitet die Kommunikationsverbindung zwischen dem Speichersystem (900) und dem Computersystem (952) über ein Netzwerk und einen entsprechenden Protokollstapel, der die Nachrichtenübermittlungsschicht (964) enthält, die von der Kommunikationsverbindung über ein anderes Netzwerk und einen entsprechenden Protokollstapel, der die Nachrichtenübermittlungsschicht (960) enthält, getrennt und unabhängig ist.
  • In Fortsetzung dieses Beispiels und angesichts der Unabhängigkeit der Netzwerke und Kommunikationsverbindungen zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) sowie zwischen dem ersten Speichersystem (900) und dem Computersystem (952) kann das vom Computersystem (952) an das erste Speichersystem (900) ausgegebene Upgrade (1002) gleichzeitig mit der Replikation von Daten (970) zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem erfolgen. Ferner kann das Upgrade (1002) aufgrund dieser Unabhängigkeit ohne Unterbrechung der Replikationsbeziehung und der Replikation von Daten zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) erfolgen.
  • Das Aufbauen (1008) einer dritten Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) auf der Grundlage der aktualisierten einen oder mehreren Software- oder Hardwarekomponenten kann ähnlich wie das Aufbauen (902) der ersten Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) durchgeführt werden, wobei der Unterschied in der Art des eingerichteten Netzwerkkommunikationsprotokolls und der Netzwerknachrichtenschicht besteht, und wobei Einzelheiten zu den Netzwerkkommunikationsprotokollen und Netzwerknachrichtenschichten vorstehend beschrieben wurden. In diesem Beispiel kann das Aufbauen (1008) der dritten Kommunikationsverbindung im Anschluss an das Einleiten (904) der Konfigurationsänderung erfolgen.
  • Das Replizieren (1010) zusätzlicher Teile (1054) des Datensatzes über die dritte Kommunikationsverbindung, wobei das Replizieren (1010) über die dritte Kommunikationsverbindung einen Typ von Netzwerknachrichtenschicht verwendet, der sich von dem ersten Typ von Netzwerknachrichtenschicht unterscheidet, kann ähnlich wie das Replizieren (906) von Daten vom ersten Speichersystem (900) zum zweiten Speichersystem (950) durchgeführt werden, wobei der Unterschied in der Art des Netzwerkkommunikationsprotokolls und der Netzwerknachrichtenschicht besteht, die für die dritte Kommunikationsverbindung verwendet werden. In diesem Beispiel kann das Replizieren (1010) der zusätzlichen Teile (1054) des Datensatzes im Anschluss an das Initiieren (904) der Konfigurationsänderung durchgeführt werden.
  • Auf diese Weise kann in diesem Beispiel das Replizieren zwischen dem ersten und dem zweiten Speichersystem (900, 950) ohne Unterbrechung über mehrere unterschiedliche Kommunikationsverbindungen und entsprechende Netzwerkkommunikationsschichten fortgesetzt werden, selbst wenn einige der Kommunikationsverbindungen unter den mehreren Kommunikationsverbindungen für Upgrades unterbrochen werden - und wobei das Replizieren unter allen Kommunikationsverbindungen nach den Upgrades fortgesetzt werden kann.
  • Zur weiteren Erläuterung zeigt 11 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 11 dargestellte Beispielverfahren ähnelt dem in 9 dargestellten Beispielverfahren insofern, als das in 11 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ von Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 11 dargestellte Beispielverfahren umfasst jedoch weiterhin: Feststellen (1102), ob die Anforderungen an ein Replikationsschema durch die Netzwerkmerkmale eines ersten Netzwerks erfüllt werden, das den ersten Typ einer Netzwerknachrichtenschicht (960) bereitstellt; Feststellen (1104), ob die Anforderungen an das Replikationsschema durch die Netzwerkmerkmale eines zweiten Netzwerks erfüllt werden, das den zweiten Typ einer Netzwerknachrichtenschicht (964) bereitstellt; und Auswählen (1106) des Replikationsschemas zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) als ein erstes Replikationsschema aus einer Vielzahl von Replikationsschemata, basierend auf den Anforderungen für das Replikationsschema, die durch die Netzwerkmerkmale des ersten Netzwerks erfüllt werden.
  • Das Feststellen (1102), ob die Anforderungen für ein Replikationsschema durch die Netzwerkmerkmale eines ersten Netzwerks, das den ersten Typ von Netzwerknachrichtenschicht (960) bereitstellt, erfüllt werden, kann durch Bezugnahme auf eine Replikationsrichtlinie für die zu replizierenden Daten (970) oder Datensätze und Identifizieren einer oder mehrerer Anforderungen zur Unterstützung des Replikationsschemas und Vergleichen mit den Netzwerkmerkmalen erfolgen. Beispielsweise kann die Replikationsrichtlinie festlegen, dass für das Replikationsschema, z. B. die synchrone Replikation, die Hin- und Rücklaufzeit für die Kommunikation mit dem zweiten Speichersystem (950) unter einer bestimmten Anzahl von Mikrosekunden liegen muss, oder dass eine bestimmte Menge an Bandbreite verfügbar sein muss, oder dass ein bestimmter Grad an Netzwerkzuverlässigkeit bereitgestellt werden muss, oder andere Eigenschaften von Metriken eines zugrunde liegenden Netzwerks. Zum Beispiel können verschiedene Netzwerke, wie Fibre Channel oder andere vorstehend aufgeführte, Metriken für Netzwerknachrichten und unterstützte Netzwerkbandbreiten angeben.
  • Um dieses Beispiel fortzusetzen, kann bei gegebenen Anforderungen an das Replikationsschema und bei gegebenen Netzwerkmerkmalen bestimmt werden, ob jede der Anforderungen an das Replikationsschema durch die Netzwerkmerkmale des ersten Netzwerks erfüllt wird.
  • Das Feststellen (1104), ob die Anforderungen für das Replikationsschema von den Netzwerkmerkmalen eines zweiten Netzwerks erfüllt werden, das der zweite Typ von Netzwerknachrichtenschicht (964) bereitstellt, kann durch Bezugnahme auf die Replikationsrichtlinie für die zu replizierenden Daten (970) oder Datensätze und Identifizieren einer oder mehrerer Anforderungen zur Unterstützung des Replikationsschemas und Vergleichen mit den Netzwerkmerkmale erfolgen. Wie bereits erwähnt, kann die Replikationsrichtlinie beispielsweise festlegen, dass für das Replikationsschema, z. B. die synchrone Replikation, die Hin- und Rücklaufzeit für die Kommunikation mit dem zweiten Speichersystem (950) unter einer bestimmten Anzahl von Mikrosekunden liegen muss, oder dass eine bestimmte Menge an Bandbreite verfügbar sein muss, oder dass ein bestimmtes Maß an Netzwerkzuverlässigkeit bereitgestellt werden muss, oder andere Eigenschaften von Metriken eines zugrunde liegenden Netzwerks. In Anbetracht der Anforderungen des Replikationsschemas und der Netzwerkmerkmale kann bestimmt werden, ob jede der Anforderungen des Replikationsschemas durch die Netzwerkmerkmale des zweiten Netzwerks erfüllt wird.
  • Das Auswählen (1106) des Replikationsschemas zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) als ein erstes Replikationsschema aus einer Vielzahl von Replikationsschemata, basierend auf den Anforderungen für das Replikationsschema, die durch die Netzwerkmerkmale des ersten Netzwerks erfüllt werden, kann unter Verwendung der Feststellungen (1102, 1104) durchgeführt werden, ob das Replikationsschema durch das erste Netzwerk oder das zweite Netzwerk erfüllt wird, wobei das Netzwerk, das die Anforderungen des Replikationsschemas erfüllt oder am besten erfüllt, als das Netzwerk für das Replikationsschema ausgewählt werden kann.
  • Zur weiteren Erläuterung zeigt 12 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 12 dargestellte Beispielverfahren ist dem in 11 dargestellten Beispielverfahren insofern ähnlich, als das in 12 dargestellte Beispielverfahren Folgendes umfasst: Feststellen (1102), ob die Anforderungen für ein Replikationsschema durch die Netzwerkmerkmale eines ersten Netzwerks erfüllt werden, das den ersten Typ einer Netzwerknachrichtenschicht (960) bereitstellt; Feststellen (1104), ob die Anforderungen für das Replikationsschema durch die Netzwerkmerkmale eines zweiten Netzwerks erfüllt werden, das den zweiten Typ einer Netzwerknachrichtenschicht (964) bereitstellt; Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Im Gegensatz zu dem in 11 dargestellten Beispielverfahren, das die Auswahl (1106) des Replikationsschemas aus einer Vielzahl von Replikationsschemata einschließt, beinhaltet das in 12 dargestellte Beispielverfahren jedoch: Auswählen (1202) eines zweiten Replikationsschemas zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250), wobei das zweite Replikationsschema zu einer Vielzahl von Replikationsschemata gehört, basierend auf den Anforderungen an ein zweites Replikationsschema, die durch die Netzwerkmerkmale des zweiten Netzwerks erfüllt werden.
  • Das Auswählen (1202) eines zweiten Replikationsschemas zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250), basierend auf den Anforderungen für ein zweites Replikationsschema, die durch die Netzwerkmerkmale des zweiten Netzwerks erfüllt werden, kann ähnlich wie das Auswählen (1106) des Replikationsschemas zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) durchgeführt werden.
  • Zur weiteren Erläuterung zeigt 13 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 13 dargestellte Beispielverfahren ist dem in 12 dargestellten Beispielverfahren insofern ähnlich, als das in 13 dargestellte Beispielverfahren Folgendes umfasst: Auswählen (1202) eines zweiten Replikationsschemas zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250), basierend auf den Anforderungen an ein zweites Replikationsschema, die durch die Netzwerkmerkmale des zweiten Netzwerks erfüllt werden; Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem auf das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 13 dargestellte Beispielverfahren umfasst jedoch weiterhin: Aufbauen (1302) einer Kommunikationsverbindung für das zweite Replikationsschema zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250) über den zweiten Typ von Nachrichtenübermittlungsschicht (964); und gleichzeitiges Replizieren (1304) von Daten (970) von dem ersten Speichersystem (900), über entsprechende Netzwerknachrichtenschichten (960, 964), sowohl auf das zweite Speichersystem (950) als auch auf das dritte Speichersystem (1250).
  • Das Aufbauen (1302) einer Kommunikationsverbindung für das zweite Replikationsschema zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250) über den zweiten Typ von Nachrichtenübermittlungsschicht (964) kann ähnlich wie das Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960) durchgeführt werden, wie vorstehend unter Bezugnahme auf 9 beschrieben.
  • Das gleichzeitige Replizieren (1304) von Daten (970) aus dem ersten Speichersystem (900) über entsprechende Netzwerknachrichtenschichten (960, 964) sowohl auf das zweite Speichersystem (950) als auch auf das dritte Speichersystem (1250) kann wie vorstehend beschrieben durchgeführt werden.
  • Basierend darauf, dass das erste Speichersystem (900) beispielsweise so konfiguriert ist, dass es mehrere Kommunikationsverbindungen über verschiedene zugrunde liegende physische Netzwerke herstellt, wie z. B. verschiedene Netzwerke zum zweiten Speichersystem (950) und zum dritten Speichersystem (1250), kann das erste Speichersystem (900) das Replizieren von Daten (970) zum zweiten Speichersystem (950) über ein erstes Netzwerk und einen ersten Typ von Messaging-Schicht (960) fortsetzen, während gleichzeitig Daten (970) vom ersten Speichersystem (900) zum dritten Speichersystem (1250) über ein zweites Netzwerk und einen zweiten Typ von Messaging-Schicht (964) repliziert werden.
  • Zur weiteren Erläuterung zeigt 14 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 14 dargestellte Beispielverfahren ähnelt dem in 13 dargestellten Beispielverfahren insofern, als das in 14 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (1302) einer Kommunikationsverbindung für das zweite Replikationsschema zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250) über den zweiten Typ von Nachrichtenübermittlungsschicht (964); Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960); gleichzeitiges Replizieren (1304), über entsprechende Netzwerknachrichtenschichten (960, 964), von Daten (970) aus dem ersten Speichersystem (900) auf sowohl das zweite Speichersystem (950) als auch das dritte Speichersystem (1250); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ von Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) vom ersten Speichersystem auf das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 14 dargestellte Beispielverfahren beinhaltet jedoch das Unterbrechen (1402) der Replikation zwischen dem ersten Speichersystem (900) und dem dritten Speichersystem (1250), um eine Konfigurationsänderung zu beginnen.
  • Das Unterbrechen (1402) der Replikation zwischen dem ersten Speichersystem (900) und dem dritten Speichersystem (1250), um eine Konfigurationsänderung zu beginnen, kann von einem Speicher-Controller als Reaktion auf den Empfang einer Nachricht, die eine Aktualisierung anzeigt, durchgeführt werden, wobei das Replizieren, die über die Kommunikationsverbindung zwischen dem ersten Speichersystem (900) und dem dritten Speichersystem (1250) stattfindet, ausgesetzt oder unterbrochen wird. Ferner kann der Speicher-Controller in diesem Beispiel nach dem Aussetzen der Replikation zwischen dem ersten Speichersystem (900) und dem dritten Speichersystem (1250) die in der Aktualisierungsnachricht angegebene Konfigurationsänderung anwenden.
  • Zur weiteren Erläuterung zeigt 15 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 15 dargestellte Beispielverfahren ähnelt dem in 9 dargestellten Beispielverfahren insofern, als das in 15 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 15 dargestellte Beispielverfahren umfasst jedoch weiterhin: Aufbauen (1502) einer Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) über den zweiten Typ von Netzwerknachrichtenschicht (964); und gleichzeitiges Replizieren (1504) von Daten (970) von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) über den ersten Typ von Netzwerknachrichtenschicht (960) und von Daten (1570) von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) über den zweiten Typ von Netzwerknachrichtenschicht (964) über verschiedene Netzwerknachrichtenschichten (960, 964).
  • Das Aufbauen (1502) einer Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) über den zweiten Typ von Netzwerknachrichtenschicht (964) kann ähnlich wie das Aufbauen (902) einer Kommunikationsverbindung für das Replikationsschema zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) durchgeführt werden - wobei ein Unterschied darin besteht, dass die Kommunikationsverbindung über eine andere Nachrichtenübermittlungsschicht hergestellt wird.
  • Das gleichzeitige Replizieren (1504) von Daten (970) von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) über verschiedene Netzwerknachrichtenschichten (960, 964) und von Daten (1570) von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) über den zweiten Typ von Netzwerknachrichtenschicht (964) kann auf der Grundlage ausgeführt werden, dass das erste Speichersystem (900) so konfiguriert ist, dass es mehrere Kommunikationsverbindungen über verschiedene zugrunde liegende physikalische Netzwerke herstellt, wie z.B. verschiedene Netzwerke zu demselben zweiten Speichersystem (950) - wobei das erste Speichersystem (900) das Replizieren von Daten (970) zu dem zweiten Speichersystem (950) über ein erstes Netzwerk und einen ersten Typ einer Nachrichtenübermittlungsschicht (960) fortsetzen kann, während es gleichzeitig Daten (1570) von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) über ein zweites Netzwerk und einen zweiten Typ einer Nachrichtenübermittlungsschicht (964) repliziert.
  • Zur weiteren Erläuterung zeigt 16 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 16 dargestellte Beispielverfahren ähnelt dem in 9 dargestellten Beispielverfahren insofern, als das in 16 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 16 dargestellte Beispielverfahren umfasst jedoch im Gegensatz zum Beispielverfahren von 9 weiterhin: Erkennen (1602) einer Änderung der Netzwerkmerkmale des ersten Netzwerks, das die erste Kommunikationsverbindung zum zweiten Speichersystem (950) unterstützt; und Feststellen (1604), dass die Änderung der Netzwerkmerkmale eine oder mehrere Replikationsschema-Anforderungen nicht erfüllt.
  • Das Erkennen (1602) einer Änderung der Netzwerkmerkmale des ersten Netzwerks, das die erste Kommunikationsverbindung zum zweiten Speichersystem (950) unterstützt, kann durch einen Diagnose- oder Überwachungsprozess erfolgen, der periodisch oder als Reaktion auf Netzwerkereignisse Metriken und Statusinformationen für ein bestimmtes Netzwerk, wie in diesem Beispiel das erste Netzwerk, sammelt.
  • Das Feststellen (1604), dass die Änderung der Netzwerkmerkmale eine oder mehrere Replikationsschema-Anforderungen nicht erfüllt, kann durch Vergleichen der aktuellen Netzwerkmerkmale - basierend auf den vorstehend festgestellten Änderungen (1602) - und Bezugnahme auf eine Replikationsrichtlinie für die zu replizierenden Daten (970) oder den Datensatz und Identifizieren einer oder mehrerer Anforderungen zur Unterstützung des Replikationsschemas und Vergleichen mit den aktuellen Netzwerkmerkmale erfolgen. Beispielsweise kann die Replikationsrichtlinie festlegen, dass für das Replikationsschema, z. B. die synchrone Replikation, eine bestimmte Netzwerkgeschwindigkeit oder eine bestimmte Menge an Bandbreite verfügbar sein muss, oder dass ein bestimmtes Maß an Netzwerkzuverlässigkeit bereitgestellt werden muss, oder andere Eigenschaften von Metriken eines zugrunde liegenden Netzwerks.
  • Zur weiteren Erläuterung zeigt 17 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 17 dargestellte Beispielverfahren ähnelt dem in 16 dargestellten Beispielverfahren insofern, als das in 17 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; Replizieren (906) von Daten (970) von dem ersten Speichersystem zu dem zweiten Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen; Erkennen (1602) einer Änderung der Netzwerkmerkmale des ersten Netzwerks, das die erste Kommunikationsverbindung zu dem zweiten Speichersystem (950) unterstützt; und Feststellen (1604), dass die Änderung der Netzwerkmerkmale eine oder mehrere Replikationsschema-Anforderungen des Replikationsschemas nicht erfüllt.
  • Das in 17 dargestellte Beispielverfahren legt jedoch weiterhin fest, dass als Reaktion auf das Feststellen (1604), dass die Änderung der Netzwerkmerkmale die eine oder mehrere Replikationsschema-Anforderungen des Replikationsschemas nicht erfüllt: Auswählen (1702) des Ersatzreplikationsschemas aus einer Vielzahl von Replikationsschemata, basierend auf den aktuellen Netzwerkmerkmale nach der Änderung der Netzwerkbedingungen und basierend auf den aktuellen Netzwerkbedingungen, die die Anforderungen eines Ersatzreplikationsschemas erfüllen.
  • Das Auswählen (1702) des Ersatzreplikationsschemas aus einer Vielzahl von Replikationsschemata basierend auf den aktuellen Netzwerkmerkmalen nach der Änderung der Netzwerkbedingungen und basierend auf den aktuellen Netzwerkbedingungen, die die Anforderungen eines Ersatzreplikationsschemas erfüllen, kann ähnlich wie das Auswählen (1202) eines zweiten Replikationsschemas zwischen dem ersten Speichersystem (900) und einem dritten Speichersystem (1250) basierend auf den Anforderungen für ein zweites Replikationsschema, die durch die Netzwerkmerkmale des zweiten Netzwerks erfüllt werden, durchgeführt werden, wobei das zweite Replikationsschema zu einer Vielzahl von Replikationsschemata gehört, wie in 12 beschrieben.
  • Zur weiteren Erläuterung zeigt 18 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 18 dargestellte Beispielverfahren ähnelt dem in 17 dargestellten Beispielverfahren insofern, als das in 18 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; Replizieren (906) von Daten (970) von dem ersten Speichersystem auf das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen; Erkennen (1602) einer Änderung der Netzwerkmerkmale des ersten Netzwerks, das die erste Kommunikationsverbindung zu dem zweiten Speichersystem (950) unterstützt; Feststellen (1604), dass die Änderung der Netzwerkmerkmale eine oder mehrere Replikationsschema-Anforderungen des Replikationsschemas nicht erfüllt; und als Reaktion auf das Feststellen (1604), dass die Änderung der Netzwerkmerkmale die eine oder mehreren Replikationsschema-Anforderungen des Replikationsschemas nicht erfüllt: Auswählen (1702) des Ersatzreplikationsschemas aus einer Vielzahl von Replikationsschemata, basierend auf den aktuellen Netzwerkmerkmale nach der Änderung der Netzwerkbedingungen und basierend auf den aktuellen Netzwerkbedingungen, die die Anforderungen eines Ersatzreplikationsschemas erfüllen.
  • Das in 18 dargestellte Beispielverfahren umfasst jedoch weiterhin: Aufbauen (1802) einer dritten Kommunikationsverbindung für das Ersatzreplikationsschema zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) über einen dritten Typ von Netzwerknachrichtenschicht (1850).
  • Das Aufbauen (1802) einer dritten Kommunikationsverbindung für das Ersatzreplikationsschema zwischen dem ersten Speichersystem (900) und dem zweiten Speichersystem (950) über einen dritten Typ von Netzwerknachrichtenschicht (1850) kann ähnlich wie das Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ von Netzwerknachrichtenschicht (960) ausgeführt werden, wie vorstehend mit Bezug auf 9 beschrieben. Wie vorstehend erwähnt, kann das erste Speichersystem (900) mehrere Netzwerkanschlüsse enthalten, wobei jeder Netzwerkanschluss ein oder mehrere Netzwerkprotokolle über ein oder mehrere Kommunikationsnetzwerke oder Fabrics unterstützen kann, und wobei jedes Netzwerkprotokoll einem Netzwerkprotokollstapel entsprechen kann, der eine Nachrichtenübermittlungsschicht enthält.
  • Zur weiteren Erläuterung zeigt 19 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Das in 19 dargestellte Beispielverfahren ähnelt dem in 9 dargestellten Beispielverfahren insofern, als das in 19 dargestellte Beispielverfahren Folgendes umfasst: Aufbauen (902) einer Kommunikationsverbindung für ein Replikationsschema zwischen einem ersten Speichersystem (900) und einem zweiten Speichersystem (950) über einen ersten Typ einer Netzwerknachrichtenschicht (960); Initiieren (904) einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems (900) über einen zweiten Typ einer Netzwerknachrichtenschicht; und Replizieren (906) von Daten (970) von dem ersten Speichersystem auf das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems (900) zu unterbrechen.
  • Das in 19 dargestellte Beispielverfahren umfasst jedoch im Gegensatz zu dem Beispielverfahren von 9 weiterhin: Feststellen (1902), dass ein Datensatz, der von dem ersten Speichersystem (900) zu dem zweiten Speichersystem (950) repliziert wird, synchronisiert ist; und reagierend auf den synchronisierten Datensatz (1904): Umschalten (1904A) von der ersten Netzwerknachrichtenschicht zu einer dritten Netzwerknachrichtenschicht (1950), und Umschalten (1904B) von dem Replikationsschema als synchrones Replikationsschema zu dem Replikationsschema als nahezu synchrones Replikationsschema.
  • In diesem Beispiel kann eine einem Datensatz zugeordnete Replikationsrichtlinie Bedingungen festlegen, unter denen auf ein anderes Replikationsschema umgeschaltet werden kann. Beispielsweise kann die anfängliche Synchronisierung eines Datensatzes bandbreitenintensiv sein, sodass eine Replikationsrichtlinie ein Fibre Channel-Netzwerk für die anfängliche Synchronisierung des Datensatzes auswählen kann. Ferner kann in diesem Beispiel die Replikationsrichtlinie für den Datensatz festlegen, dass als Reaktion auf die anfängliche Synchronisierung des Datensatzes auf ein anderes Replikationsschema und/oder einen anderen Typ von Netzwerktransportmechanismus umgeschaltet wird.
  • In Fortsetzung dieses Beispiels kann als Reaktion auf die Synchronisierung des Datensatzes - zum Beispiel, um das Fibre-Channel-Netzwerk für eine andere bandbreitenintensive Replikationsschema-Nutzung bereitzustellen - das Replikationsschema auf ein anderes Netzwerk umgeschaltet werden, basierend auf einer Replikationsrichtlinie, die einen Ausgleich der Netzwerknutzung spezifiziert, der die Verwendung von Netzwerken mit geringerer Bandbreite oder Replikationsschemata mit geringerem Datenverkehr im Anschluss an die anfängliche Synchronisierung des Datensatzes umfasst. In einigen Beispielen kann das Replikationsschema zusätzlich zum Umschalten auf ein anderes Netzwerk und eine entsprechend andere Messaging-Schicht auch auf ein anderes Replikationsschema umgeschaltet werden.
  • Das Feststellen (1902), dass ein Datensatz, der vom ersten Speichersystem (900) zum zweiten Speichersystem (950) repliziert wird, synchronisiert ist, kann unter Verwendung verschiedener Techniken in Übereinstimmung mit einem bestimmten verwendeten Replikationsschema durchgeführt werden. Wie vorstehend unter Bezugnahme auf ein synchrones Replikationsschema beschrieben, kann beispielsweise die Synchronisierung eines Datensatzes (426) zwischen mehreren Speichersystemen (402, 404, 406) Bestätigungsmeldungen zwischen den Speichersystemen verwenden, um einen synchronisierten Datensatz anzuzeigen. In anderen Beispielen können verschiedene Replikationsschemata über entsprechende Mechanismen verfügen, um zu bestimmen, wann ein Datensatz synchronisiert ist, wie vorstehend unter Bezugnahme auf die 4A-8 beschrieben.
  • Das Umschalten (1904A), als Reaktion auf die Synchronisierung (1904) des Datensatzes, von der ersten Netzwerknachrichtenschicht zu einer dritten Netzwerknachrichtenschicht (1950) kann von einem Speicher-Controller durchgeführt werden, der die Replikationsoperationen vom ersten Speichersystem zum zweiten Speichersystem in einem aktuellen Netzwerk unter Verwendung einer aktuellen ersten Netzwerknachrichtenschicht (960) aussetzt und dann eine Kommunikationsverbindung mit dem zweiten Speichersystem (950) unter Verwendung eines anderen Netzwerks und einer dritten Netzwerknachrichtenschicht (1950) herstellt. In diesem Beispiel kann das Aufbauen der Kommunikationsverbindung zum Aufbauen (902) einer Kommunikationsverbindung wie vorstehend mit Bezug auf 9 beschrieben durchgeführt werden.
  • Das Umschalten (1904B) vom Replikationsschema, bei dem es sich um ein synchrones Replikationsschema handelt, zum Replikationsschema, bei dem es sich um ein nahezu synchrones Replikationsschema handelt, kann dadurch erfolgen, dass die Speichersteuerung das aktuelle synchrone Replikationsschema aussetzt, indem sie alle ausstehenden Operationen für das aktuelle synchrone Replikationsschema abschließt, ohne neue Replikationsoperationen einzuleiten. Als Reaktion auf den Abschluss aller aktuellen ausstehenden Replikationsoperationen kann der Speicher-Controller dann das asynchrone Replikationsschema über die eingerichtete Kommunikationsverbindung einleiten, die vorstehend unter Bezugnahme auf das Umschalten (1904A) zwischen Netzwerknachrichtenschichten beschrieben wurde.
  • Zur weiteren Erläuterung zeigt 20 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • In diesem Beispiel können zwei Speichersysteme (2000, 2050) eine Replikationsbeziehung in Übereinstimmung mit einem bestimmten Replikationsschema herstellen, wobei die Speichersysteme mehrere unterschiedliche Netzwerke und entsprechend unterschiedliche Netzwerknachrichtenmechanismus verwenden können, um Daten gleichzeitig zu replizieren.
  • Konkret beinhaltet das in 20 dargestellte Beispielverfahren ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ einer Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ einer Messaging-Schicht (2060); und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Teilen eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050).
  • Das Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062) kann ähnlich wie das Aufbauen (902) einer Kommunikationsverbindung zwischen Speichersystemen, das vorstehend mit Bezug auf 9 beschrieben wurde, durchgeführt werden.
  • Das Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Messaging-Schicht (2060) kann in ähnlicher Weise erfolgen wie das Aufbauen (902) einer Kommunikationsverbindung zwischen Speichersystemen, das vorstehend mit Bezug auf 9 beschrieben wurde.
  • Das gleichzeitige Replizieren (2006) von jeweiligen Teilen eines Datensatzes (2052) vom ersten Speichersystem (2000) zum zweiten Speichersystem (2050) sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060) kann ähnlich wie das gleichzeitige Replizieren (1304) von Daten zwischen einem ersten Speichersystem und einem zweiten und dritten Speichersystem durchgeführt werden. Im Gegensatz zur gleichzeitigen Replikation (1304) auf verschiedene Speichersysteme in 13, repliziert das erste Speichersystem in diesem Beispiel jedoch gleichzeitig Datenteile (2070, 2072) des Datensatzes (2052) auf dasselbe zweite Speichersystem (2050) über verschiedene Netzwerke unter Verwendung verschiedener Netzwerknachrichtenschichten (2060, 2062).
  • Zur weiteren Erläuterung zeigt 21 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • In diesem Beispiel, wie in 20 beschrieben, haben die beiden Speichersysteme (2000, 2050) eine eingerichtete Replikationsbeziehung in Übereinstimmung mit einem gegebenen Replikationsschema, wobei die Speichersysteme mehrere unterschiedliche Netzwerke und entsprechend unterschiedliche Netzwerknachrichtenmechanismus verwenden können, um Daten gleichzeitig zu replizieren.
  • Im Beispielverfahren von 20 kann eine Replikationsrichtlinie jedoch Reaktionen auf Änderungen der Netzwerkverfügbarkeit spezifizieren, wobei die Reaktionen das Umschalten von Replikationsschemata und/oder das Umschalten auf ein anderes Netzwerk und einen entsprechenden Netzwerknachrichtenmechanismus umfassen können.
  • Konkret beinhaltet das in 21 dargestellte Beispielverfahren, ähnlich dem Beispielverfahren von 20, ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Nachrichtenübermittlungsschicht (2060); und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Abschnitten eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050).
  • Das Beispielverfahren in 21 umfasst jedoch weiterhin: als Reaktion auf das Ermitteln der verfügbaren Netzwerkbandbreite über die erste Kommunikationsverbindung und das Ermitteln eines Mangels an Netzwerkbandbreite über die zweite Kommunikationsverbindung, das Umschalten (2102) eines oder mehrerer Datenabschnitte, die für das Replizieren über die zweite Kommunikationsverbindung vorgesehen sind, um stattdessen über die erste Kommunikationsverbindung repliziert zu werden.
  • Das Umschalten (2102) eines oder mehrerer Teile von Daten, die für das Replizieren über die zweite Kommunikationsverbindung vorgesehen sind, um stattdessen über die erste Kommunikationsverbindung repliziert zu werden, als Reaktion auf das Bestimmen der verfügbaren Netzwerkbandbreite über die erste Kommunikationsverbindung und das Bestimmen eines Mangels an Netzwerkbandbreite über die zweite Kommunikationsverbindung, kann ähnlich wie das Umschalten (1904A) von einem Typ von Netzwerknachrichtenschicht (1950) zu einem anderen Typ von Netzwerknachrichtenschicht (964) ausgeführt werden, wie vorstehend mit Bezug auf 19 beschrieben. Ferner kann in diesem Beispiel das Bestimmen der verfügbaren Netzwerkbandbreite und der fehlenden Netzwerkbandbreite von einem Speicher-Controller ausgeführt werden, der mit einem Netzwerküberwachungsprozess kommuniziert, um Statusinformationen für verschiedene Netzwerke zu bestimmen, die dem Speichersystem (2000) zur Verfügung stehen.
  • Zur weiteren Erläuterung zeigt 22 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • In diesem Beispiel, wie in 20 beschrieben, haben die beiden Speichersysteme (2000, 2050) eine eingerichtete Replikationsbeziehung in Übereinstimmung mit einem gegebenen Replikationsschema, wobei die Speichersysteme mehrere unterschiedliche Netzwerke und entsprechend unterschiedliche Netzwerknachrichtenmechanismus verwenden können, um Daten gleichzeitig zu replizieren.
  • Im Beispielverfahren von 22 kann eine Replikationsrichtlinie jedoch Reaktionen auf Änderungen oder Unterbrechungen des Netzwerkzustands spezifizieren, wobei die Reaktionen das Umschalten von Replikationsschemata und/oder das Umschalten auf ein anderes Netzwerk und einen entsprechenden Netzwerknachrichtenmechanismus umfassen können.
  • Konkret beinhaltet das in 22 dargestellte Beispielverfahren, ähnlich dem Beispielverfahren von 20, ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Nachrichtenübermittlungsschicht (2060); und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Teilen eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050).
  • Das Beispielverfahren in 22 umfasst jedoch weiterhin: als Reaktion auf das Feststellen eines Netzwerkfehlers auf der ersten Kommunikationsverbindung, die den ersten Typ von Netzwerknachrichtenschicht (2062) unterstützt, das Umschalten (2202) eines oder mehrerer Datenabschnitte, die für das Replizieren über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden.
  • Das Umschalten (2202) eines oder mehrerer Datenabschnitte, die für das Replizieren über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden, als Reaktion auf das Bestimmen eines Netzwerkfehlers auf der ersten Kommunikationsverbindung, die den ersten Typ von Netzwerknachrichtenschicht (2062) unterstützt, kann ähnlich wie das Umschalten (1904A) von einem Typ von Netzwerknachrichtenschicht (1950) zu einem anderen Typ von Netzwerknachrichtenschicht (964) ausgeführt werden, wie vorstehend mit Bezug auf 19 beschrieben. Ferner kann in diesem Beispiel das Bestimmen des Netzwerkzustands oder von Netzwerkausfällen durch eine Speichersteuerung erfolgen, die mit einem Netzwerküberwachungsprozess kommuniziert, um Statusinformationen für verschiedene Netzwerke zu bestimmen, die dem Speichersystem (2000) zur Verfügung stehen.
  • Zur weiteren Erläuterung zeigt 23 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • In diesem Beispiel, wie in 20 beschrieben, haben die beiden Speichersysteme (2000, 2050) eine eingerichtete Replikationsbeziehung in Übereinstimmung mit einem gegebenen Replikationsschema, wobei die Speichersysteme mehrere unterschiedliche Netzwerke und entsprechend unterschiedliche Netzwerknachrichtenmechanismen verwenden können, um Daten gleichzeitig zu replizieren.
  • In der Beispielmethode von 23 kann eine Replikationsrichtlinie jedoch Reaktionen auf Änderungen oder Unterbrechungen des Netzwerkzustands spezifizieren, wobei die Reaktionen das Umschalten von Replikationsschemata und das Umschalten des Netzwerknachrichtenmechanismus umfassen können.
  • Konkret beinhaltet das in 23 dargestellte Beispielverfahren, ähnlich dem Beispielverfahren von 22, ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Nachrichtenübermittlungsschicht (2060); gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Teilen eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050); und als Reaktion auf das Feststellen eines Netzwerkfehlers auf der ersten Kommunikationsverbindung, die den ersten Typ von Netzwerknachrichtenschicht (2062) unterstützt, Umschalten (2202) eines oder mehrerer Datenabschnitte, die zur Replikation über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden.
  • Das Beispielverfahren in 23 spezifiziert jedoch weiter, dass das Umschalten (2202) von Daten, die zur Replikation über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden, das Umschalten (2302) von der Verwendung des ersten Replikationsschemas über den ersten Typ von Netzwerknachrichtenschicht (2062) auf die Verwendung des zweiten Replikationsschemas über den zweiten Typ von Netzwerknachrichtenschicht einschließt.
  • Das Umschalten (2302) von der Verwendung des ersten Replikationsschemas über den ersten Typ von Netzwerknachrichtenschicht (2062), um stattdessen das zweite Replikationsschema über den zweiten Typ von Netzwerknachrichtenschicht zu verwenden, kann ähnlich wie das Umschalten (1904B) zwischen verschiedenen Replikationsschemata durchgeführt werden, das vorstehend mit Bezug auf 19 beschrieben wurde.
  • Zur weiteren Erläuterung zeigt 24 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • In diesem Beispiel kann eine Replikationsrichtlinie für einen entsprechenden Datensatz eine oder mehrere Grundlagen angeben, auf denen ein erstes Replikationsschema zur Replikation des Datensatzes ausgewählt wird, einschließlich der Verwendung von Netzwerkmerkmalen als Grundlage.
  • Konkret umfasst das in 24 dargestellte Beispielverfahren, ähnlich wie das Beispielverfahren von 20, ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Nachrichtenübermittlungsschicht (2060); und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Teilen eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050).
  • Das Beispielverfahren in 24 umfasst jedoch weiterhin: Auswählen (2402) eines ersten Replikationsschemas zum Replizieren von Daten (2072) unter Verwendung eines ersten Typs einer Netzwerknachrichtenschicht (2062) auf der Grundlage von Netzwerkmerkmalen für ein erstes Netzwerk.
  • Das Auswählen (2402) eines ersten Replikationsschemas auf der Grundlage von Netzwerkmerkmalen für ein erstes Netzwerk zum Replizieren von Daten (2072) unter Verwendung eines ersten Typs von Netzwerknachrichtenschicht (2462) kann ähnlich wie das Auswählen (1202) eines Replikationsschemas auf der Grundlage von Netzwerkmerkmalen eines Netzwerks, wie vorstehend unter Bezugnahme auf 12 beschrieben, durchgeführt werden. In diesem Beispiel kann, wie vorstehend beschrieben, eine Replikationsrichtlinie Netzwerkanforderungen für verschiedene Replikationsschemata spezifizieren, wobei ein Replikationsschema basierend auf gegebenen Netzwerkeigenschaften, die das Replikationsschema erfüllen, ausgewählt werden kann.
  • Zur weiteren Erläuterung zeigt 25 ein Flussdiagramm, das ein Verfahren zum Implementieren der Replikationsbehandlung zwischen verschiedenen Netzwerken in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Ähnlich wie im Beispiel von 24, wo eine Replikationsrichtlinie für ein erstes Netzwerk ausgewählt wird, kann in diesem Beispiel eine Replikationsrichtlinie für einen entsprechenden Datensatz eine oder mehrere Grundlagen angeben, auf denen ein zweites Replikationsschema zum Replizieren des Datensatzes ausgewählt wird, einschließlich der Verwendung von Netzwerkmerkmalen als Grundlage.
  • Konkret umfasst das in 25 dargestellte Beispielverfahren, ähnlich dem Beispielverfahren von 20, ein Speichersystem (2000): Aufbauen (2002) einer Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem (2000) und einem zweiten Speichersystem (2050) über einen ersten Typ von Netzwerknachrichtenschicht (2062); Aufbauen (2004) einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem (2050) über einen zweiten Typ von Nachrichtenübermittlungsschicht (2060); und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht (2062) als auch über den zweiten Typ von Netzwerknachrichtenschicht (2060), von entsprechenden Teilen eines Datensatzes (2052) von dem ersten Speichersystem (2000) zu dem zweiten Speichersystem (2050).
  • Das Beispielverfahren in 25 umfasst jedoch weiterhin: Auswählen (2502) eines zweiten Replikationsschemas auf der Grundlage von Netzwerkmerkmalen für ein zweites Netzwerk, um Daten zu replizieren (2070), unter Verwendung eines zweiten Typs von Netzwerknachrichtenschicht (2460).
  • Das Auswählen (2502) eines zweiten Replikationsschemas zur Replikation von Daten (2070) unter Verwendung eines zweiten Typs einer Netzwerknachrichtenschicht (2460) auf der Grundlage von Netzwerkmerkmalen für ein zweites Netzwerk kann ähnlich wie die Auswahl (2502) eines Replikationsschemas auf der Grundlage von Netzwerkmerkmalen eines Netzwerks, wie vorstehend mit Bezug auf 24 beschrieben, durchgeführt werden.
  • Die Vorteile und Merkmale der vorliegenden Offenbarung können durch die folgenden Aussagen weiter beschrieben werden:
    1. 1. Verfahren, umfassend: Aufbauen einer Kommunikationsverbindung für das Replizieren zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netzwerknachrichtenschicht; Initiieren einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems über einen zweiten Typ von Netzwerknachrichtenschicht; und Replizieren von Daten aus dem ersten Speichersystem in das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems zu unterbrechen.
    2. 2. Verfahren nach Aussage 1, wobei die Kommunikationsverbindung eine erste Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem ist, wobei die Daten ein Teil eines Datensatzes sind, der zwischen dem ersten Speichersystem und dem zweiten Speichersystem repliziert wird, und wobei das Verfahren ferner umfasst: vor der Konfigurationsänderung: Replizieren, über eine zweite Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem, eines Teils eines Datensatzes; und Unterbrechen der Replikation über die zweite Kommunikationsverbindung, um die Konfigurationsänderung zu initiieren, wobei die Konfigurationsänderung das Aktualisieren einer oder mehrerer Software- oder Hardwarekomponenten umfasst; und nach der Konfigurationsänderung: Aufbauen einer dritten Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem, basierend auf der aktualisierten einen oder mehreren Software- oder Hardwarekomponente; und Replizieren zusätzlicher Teile des Datensatzes über die dritte Kommunikationsverbindung, wobei das Replizieren über die dritte Kommunikationsverbindung einen Typ von Netzwerknachrichtenschicht verwendet, der sich von dem ersten Typ von Netzwerknachrichtenschicht unterscheidet.
    3. 3. Verfahren nach Aussage 2 oder Aussage 1, wobei das Replizieren der Daten vom ersten Speichersystem zum zweiten Speichersystem gleichzeitig mit der Aktualisierung des ersten Speichersystems erfolgt.
    4. 4. Verfahren nach Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: Feststellen, ob Anforderungen für das Replizieren durch Netzwerkmerkmale eines ersten Netzwerks erfüllt werden, das den ersten Typ von Netzwerknachrichtenschicht bereitstellt; und Feststellen, ob Anforderungen für das Replizieren durch Netzwerkmerkmale eines zweiten Netzwerks erfüllt werden, das den zweiten Typ von Netzwerknachrichtenschicht bereitstellt.
    5. 5. Verfahren nach Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend:
      • Auswählen eines Replikationsschemas zwischen dem ersten Speichersystem und dem zweiten Speichersystem als ein erstes Replikationsschema aus einer Vielzahl von Replikationsschemata, basierend auf den Anforderungen für das Replizieren, die von den Netzwerkmerkmalen des ersten Netzwerks erfüllt werden.
    6. 6. Verfahren nach Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: Auswählen des zweiten Replikationsschemas zwischen dem ersten Speichersystem und einem dritten Speichersystem vor der Konfigurationsänderung und basierend auf Anforderungen für ein zweites Replikationsschema, die von den Netzwerkmerkmalen des zweiten Netzwerks erfüllt werden, wobei das zweite Replikationsschema zu der Vielzahl von Replikationsschemata gehört.
    7. 7. Verfahren nach Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: Aufbauen einer Kommunikationsverbindung für das zweite Replikationsschema zwischen dem ersten Speichersystem und dem dritten Speichersystem über den zweiten Typ von Netzwerknachrichtenschicht; und gleichzeitiges Replizieren von Daten aus dem ersten Speichersystem über die jeweiligen Netzwerknachrichtenschichten sowohl in das zweite Speichersystem als auch in das dritte Speichersystem.
    8. 8. Verfahren nach Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: vor der Konfigurationsänderung, Unterbrechen des Replizierens zwischen dem ersten Speichersystem und dem dritten Speichersystem, um die Konfigurationsänderung zu beginnen.
    9. 9. Verfahren nach Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: Aufbauen einer Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem nach der Konfigurationsänderung und über den zweiten Typ von Netzwerknachrichtenschicht; und gleichzeitiges Replizieren, über verschiedene Netzwerknachrichtenschichten, von Daten vom ersten Speichersystem in das zweite Speichersystem über den ersten Typ von Netzwerknachrichtenschicht und von Daten vom ersten Speichersystem in das zweite Speichersystem über den zweiten Typ von Netzwerknachrichtenschicht.
    10. 10. Verfahren nach Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: Erfassen einer Änderung von Netzwerkmerkmalen des ersten Netzwerks, das die erste Kommunikationsverbindung unterstützt; und Feststellen, dass die Änderung von Netzwerkmerkmalen eine oder mehrere Replikationsschemaanforderungen des ersten Replikationsschemas nicht erfüllt.
    11. 11. Verfahren nach Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend: als Reaktion auf das Feststellen, dass die Änderung von Netzwerkmerkmalen die eine oder mehreren Replikationsschema-Anforderungen des ersten Replikationsschemas nicht erfüllt:
      • Auswählen des Ersatzreplikationsschemas aus einer Vielzahl von Replikationsschemata, basierend auf aktuellen Netzwerkmerkmalen nach der Änderung von Netzwerkmerkmalen und basierend darauf, dass die aktuellen Netzwerkmerkmale die Anforderungen eines Ersatzreplikationsschemas erfüllen.
    12. 12. Verfahren nach Aussage 11, Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, ferner umfassend:
      • Aufbauen einer dritten Kommunikationsverbindung für das Ersatzreplikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem über das erste Netzwerk und über einen dritten Typ von Netzwerknachrichtenschicht.
    13. 13. Verfahren nach Aussage 12, Aussage 11, Aussage 10, Aussage 9, Aussage 8, Aussage 7, Aussage 6, Aussage 5, Aussage 4, Aussage 3, Aussage 2 oder Aussage 1, wobei das Replikationsschema ein synchrones Replikationsschema ist, und wobei das Verfahren ferner umfasst: Feststellen, dass ein Datensatz, der von dem ersten Speichersystem zu dem zweiten Speichersystem repliziert wird, synchronisiert ist; und als Reaktion auf den zu synchronisierenden Datensatz: Umschalten von der ersten Netzwerknachrichtenschicht auf eine dritte Netzwerknachrichtenschicht; und Umschalten vom synchronen Replikationsschema auf ein nahezu synchrones Replikationsschema.
    14. 14. Verfahren, umfassend: Aufbauen einer ersten Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netzwerknachrichtenschicht; Aufbauen einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem über einen zweiten Typ von Netzwerknachrichtenschicht; und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht als auch über den zweiten Typ von Netzwerknachrichtenschicht, jeweiliger Teile eines Datensatzes von dem ersten Speichersystem in das zweite Speichersystem.
    15. 15. Verfahren nach Aussage 14, ferner umfassend: als Reaktion auf das Feststellen von verfügbarer Netzwerkbandbreite über die erste Kommunikationsverbindung und das Bestimmen eines Mangels an Netzwerkbandbreite über die zweite Kommunikationsverbindung: Umschalten eines oder mehrerer Teile von Daten, die für das Replizieren über die zweite Kommunikationsverbindung vorgesehen sind, um stattdessen über die erste Kommunikationsverbindung repliziert zu werden.
    16. 16. Verfahren nach Aussage 15 oder Aussage 14, ferner umfassend: als Reaktion auf das Feststellen eines Netzwerkausfalls auf der ersten Kommunikationsverbindung, die den ersten Typ von Netzwerknachrichtenschicht unterstützt: Umschalten eines oder mehrerer Teile von Daten, die für das Replizieren über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden.
    17. 17. Verfahren nach Aussage 16, Aussage 15 oder Aussage 14, ferner umfassend: Umschalten von der Verwendung des ersten Replikationsschemas über den ersten Typ von Netzwerknachrichtenschicht auf die Verwendung des zweiten Replikationsschemas über den zweiten Typ von Netzwerknachrichtenschicht.
    18. 18. Verfahren nach Aussage 17, Aussage 16, Aussage 15 oder Aussage 14, ferner umfassend:
      • Auswählen des ersten Replikationsschemas, basierend auf Netzwerkmerkmalen für das erste Netzwerk, um Daten unter Verwendung des ersten Typs von Netzwerknachrichtenschicht zu replizieren.
    19. 19. Verfahren nach Aussage 18, Aussage 17, Aussage 16, Aussage 15 oder Aussage 14, ferner umfassend: Auswählen des zweiten Replikationsschemas, basierend auf Netzwerkmerkmalen für das zweite Netzwerk, um Daten unter Verwendung des zweiten Typs von Netzwerknachrichtenschicht zu replizieren.
    20. 20. Verfahren nach Aussage 19, Aussage 18, Aussage 17, Aussage 16, Aussage 15 oder Aussage 14, wobei der erste Typ von Netzwerknachrichtenschicht FibreChannel ist, wobei das erste Replikationsschema synchrone Replikation ist, wobei der zweite Typ von Netzwerknachrichtenschicht TCP/IP ist und wobei das zweite Replikationsschema nahezu synchrone Replikation ist.
  • Eine oder mehrere Ausführungsformen können hier mit Hilfe von Verfahrensschritten beschrieben werden, die die Ausführung bestimmter Funktionen und deren Beziehungen veranschaulichen. Die Grenzen und die Abfolge dieser Funktionsbausteine und Verfahrensschritte wurden hier zur Vereinfachung der Beschreibung willkürlich definiert. Andere Grenzen und Abfolgen können definiert werden, solange die spezifizierten Funktionen und Beziehungen in geeigneter Weise ausgeführt werden. Alle derartigen alternativen Grenzen oder Abfolgen liegen daher im Rahmen und im Sinne der Ansprüche. Ferner wurden die Grenzen dieser Funktionsbausteine zur Vereinfachung der Beschreibung willkürlich festgelegt. Es können auch andere Grenzen definiert werden, solange die bestimmten signifikanten Funktionen in geeigneter Weise ausgeführt werden. In ähnlicher Weise können auch Flussdiagramm-Blöcke willkürlich definiert worden sein, um bestimmte signifikante Funktionen zu veranschaulichen.
  • In dem verwendeten Umfang hätten die Grenzen der Flussdiagramm-Blöcke und die Sequenz auch anders definiert werden können und dennoch die bestimmte signifikante Funktionalität ausführen. Solche alternativen Definitionen sowohl der Funktionsbausteine als auch der Flussdiagramm-Blöcke und -Sequenzen liegen daher im Rahmen und im Sinne der Ansprüche. Derjenige mit durchschnittlichem Fachwissen wird auch erkennen, dass die Funktionsbausteine und andere hierin dargestellte Blöcke, Module und Komponenten wie dargestellt oder durch diskrete Komponenten, anwendungsspezifische integrierte Schaltungen, Prozessoren, die geeignete Software ausführen, und dergleichen oder eine beliebige Kombination davon implementiert werden können.
  • Während bestimmte Kombinationen verschiedener Funktionen und Merkmale der einen oder mehreren Ausführungsformen hier ausdrücklich beschrieben sind, sind andere Kombinationen dieser Merkmale und Funktionen ebenfalls möglich. Die vorliegende Offenbarung ist nicht durch die hierin offengelegten besonderen Beispiele beschränkt und schließt diese anderen Kombinationen ausdrücklich mit ein.
  • 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
    • US 16050385 [0276]
    • US 62598989 [0276]
    • US 15842850 [0276]

Claims (21)

  1. Verfahren, Folgendes umfassend: Aufbauen einer Kommunikationsverbindung für das Replizieren zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netzwerknachrichtenschicht, wobei der erste Typ von Netzwerknachrichtenschicht eine Transmission Control Protocol („TCP“)/lnternet Protocol („IP“)-Nachrichtenschicht umfasst; Initiieren einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems über einen zweiten Typ von Netzwerknachrichtenschicht, wobei der zweite Typ von Netzwerknachrichtenschicht eine Fibre-Channel- („FC“) Nachrichtenschicht enthält; und Replizieren von Daten aus dem ersten Speichersystem in das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems zu unterbrechen.
  2. Verfahren, umfassend: Aufbauen einer Kommunikationsverbindung für das Replizieren zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netzwerknachrichtenschicht, wobei der erste Typ von Netzwerknachrichtenschicht eine Fibre Channel („FC“)-Nachrichtenschicht enthält; Initiieren einer Konfigurationsänderung an einem oder mehreren Aspekten des ersten Speichersystems über einen zweiten Typ von Netzwerknachrichtenschicht, wobei der zweite Typ von Netzwerknachrichtenschicht eine Transmission Control Protocol („TCP“/Internet Protocol („IP“-)Nachrichtenschicht umfasst; und Replizieren von Daten aus dem ersten Speichersystem in das zweite Speichersystem, ohne die Konfigurationsänderung an dem einen oder den mehreren Aspekten des ersten Speichersystems zu unterbrechen.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Kommunikationsverbindung eine erste Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem ist, wobei die Daten ein Teil eines Datensatzes sind, der zwischen dem ersten Speichersystem und dem zweiten Speichersystem repliziert wird, und wobei das Verfahren ferner umfasst: vor der Konfigurationsänderung: Replizieren, über eine zweite Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem, eines Teils eines Datensatzes; und Unterbrechen der Replikation über die zweite Kommunikationsverbindung, um die Konfigurationsänderung zu initiieren, wobei die Konfigurationsänderung das Aktualisieren einer oder mehrerer Software- oder Hardwarekomponenten umfasst; und nach der Konfigurationsänderung: Aufbauen einer dritten Kommunikationsverbindung zwischen dem ersten Speichersystem und dem zweiten Speichersystem, basierend auf der aktualisierten einen oder mehreren Software- oder Hardwarekomponente; und Replizieren zusätzlicher Teile des Datensatzes über die dritte Kommunikationsverbindung, wobei das Replizieren über die dritte Kommunikationsverbindung einen Typ von Netzwerknachrichtenschicht verwendet, der sich von dem ersten Typ von Netzwerknachrichtenschicht unterscheidet.
  4. Verfahren nach Anspruch 3, wobei das Replizieren der Daten vom ersten Speichersystem zum zweiten Speichersystem gleichzeitig mit der Aktualisierung des ersten Speichersystems erfolgt.
  5. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend: Feststellen, ob Anforderungen für das Replizieren durch Netzwerkmerkmale eines ersten Netzwerks erfüllt werden, das den ersten Typ von Netzwerknachrichtenschicht bereitstellt; und Feststellen, ob Anforderungen für das Replizieren durch die Netzwerkmerkmale eines zweiten Netzwerks erfüllt werden, das den zweiten Typ von Netzwerknachrichtenschicht bereitstellt.
  6. Verfahren nach Anspruch 5, ferner umfassend: Auswählen eines Replikationsschemas zwischen dem ersten Speichersystem und dem zweiten Speichersystem als ein erstes Replikationsschema aus einer Vielzahl von Replikationsschemata, basierend auf den Anforderungen für das Replizieren, die durch die Netzwerkmerkmale des ersten Netzwerks erfüllt werden.
  7. Verfahren nach Anspruch 5, ferner umfassend: Auswählen des zweiten Replikationsschemas zwischen dem ersten Speichersystem und einem dritten Speichersystem vor der Konfigurationsänderung und basierend auf Anforderungen für ein zweites Replikationsschema, die von den Netzwerkmerkmale des zweiten Netzwerks erfüllt werden, wobei das zweite Replikationsschema zu der Vielzahl von Replikationsschemata gehört.
  8. Verfahren nach Anspruch 7, ferner umfassend: Aufbauen einer Kommunikationsverbindung für das zweite Replikationsschema zwischen dem ersten Speichersystem und dem dritten Speichersystem über den zweiten Typ von Netzwerknachrichtenschicht; und gleichzeitiges Replizieren von Daten aus dem ersten Speichersystem über die jeweiligen Netzwerknachrichtenschichten sowohl in das zweite Speichersystem als auch in das dritte Speichersystem.
  9. Verfahren nach Anspruch 8, ferner umfassend: vor der Konfigurationsänderung, Unterbrechen des Replizierens zwischen dem ersten Speichersystem und dem dritten Speichersystem, um die Konfigurationsänderung zu beginnen.
  10. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend: Aufbauen einer Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem nach der Konfigurationsänderung und über den zweiten Typ von Netzwerknachrichtenschicht; und gleichzeitiges Replizieren, über verschiedene Netzwerknachrichtenschichten, von Daten vom ersten Speichersystem in das zweite Speichersystem über den ersten Typ von Netzwerknachrichtenschicht und von Daten vom ersten Speichersystem in das zweite Speichersystem über den zweiten Typ von Netzwerknachrichtenschicht.
  11. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend: Erfassen einer Änderung von Netzwerkmerkmalen des ersten Netzwerks, das die erste Kommunikationsverbindung unterstützt; und Feststellen, dass die Änderung von Netzwerkmerkmalen eine oder mehrere Replikationsschemaanforderungen des ersten Replikationsschemas nicht erfüllt.
  12. Verfahren nach Anspruch 11, ferner umfassend: als Reaktion auf das Feststellen, dass die Änderung von Netzwerkmerkmalen die eine oder mehreren Replikationsschema-Anforderungen des ersten Replikationsschemas nicht erfüllt: Auswählen des Ersatzreplikationsschemas aus einer Vielzahl von Replikationsschemata, basierend auf aktuellen Netzwerkmerkmalen nach der Änderung von Netzwerkmerkmalen und basierend darauf, dass die aktuellen Netzwerkmerkmale die Anforderungen eines Ersatzreplikationsschemas erfüllen.
  13. Verfahren nach Anspruch 12, ferner umfassend: Aufbauen einer dritten Kommunikationsverbindung für das Ersatzreplikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem über das erste Netzwerk und über einen dritten Typ von Netzwerknachrichtenschicht.
  14. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Replizieren nach einem synchronen Replikationsschema durchgeführt wird, und wobei das Verfahren ferner umfasst: Feststellen, dass ein Datensatz, der von dem ersten Speichersystem zu dem zweiten Speichersystem repliziert wird, synchronisiert ist; und als Reaktion auf den zu synchronisierenden Datensatz: Umschalten von der ersten Netzwerknachrichtenschicht auf eine dritte Netzwerknachrichtenschicht; und Umschalten vom synchronen Replikationsschema auf ein nahezu synchrones Replikationsschema.
  15. Verfahren, Folgendes umfassend: Aufbauen einer ersten Kommunikationsverbindung für ein erstes Replikationsschema zwischen einem ersten Speichersystem und einem zweiten Speichersystem über einen ersten Typ von Netzwerknachrichtenschicht, wobei der erste Typ von Netzwerknachrichtenschicht eine Transmission Control Protocol („TCP“)/lnternet Protocol („IP“)-Nachrichtenschicht umfasst; Aufbauen einer zweiten Kommunikationsverbindung für ein zweites Replikationsschema zwischen dem ersten Speichersystem und dem zweiten Speichersystem über einen zweiten Typ von Netzwerknachrichtenschicht, wobei der zweite Typ von Netzwerknachrichtenschicht eine Fibre Channel („FC“)-Nachrichtenschicht enthält; und gleichzeitiges Replizieren, sowohl über den ersten Typ von Netzwerknachrichtenschicht als auch über den zweiten Typ von Netzwerknachrichtenschicht, jeweiliger Teile eines Datensatzes von dem ersten Speichersystem in das zweite Speichersystem.
  16. Verfahren nach Anspruch 15, ferner umfassend: als Reaktion auf das Feststellen von verfügbarer Netzwerkbandbreite über die erste Kommunikationsverbindung und das Bestimmen eines Mangels an Netzwerkbandbreite über die zweite Kommunikationsverbindung: Umschalten eines oder mehrerer Teile von Daten, die für das Replizieren über die zweite Kommunikationsverbindung vorgesehen sind, um stattdessen über die erste Kommunikationsverbindung repliziert zu werden.
  17. Verfahren nach Anspruch 15, ferner umfassend: als Reaktion auf das Feststellen eines Netzwerkausfalls auf der ersten Kommunikationsverbindung, die den ersten Typ von Netzwerknachrichtenschicht unterstützt: Umschalten eines oder mehrerer Teile von Daten, die für das Replizieren über die erste Kommunikationsverbindung vorgesehen sind, um stattdessen über die zweite Kommunikationsverbindung repliziert zu werden.
  18. Verfahren nach Anspruch 17, ferner umfassend: Umschalten von der Verwendung des ersten Replikationsschemas über den ersten Typ von Netzwerknachrichtenschicht auf die Verwendung des zweiten Replikationsschemas über den zweiten Typ von Netzwerknachrichtenschicht.
  19. Verfahren nach Anspruch 15, ferner umfassend: Auswählen des ersten Replikationsschemas, basierend auf Netzwerkmerkmalen für das erste Netzwerk, um Daten unter Verwendung des ersten Typs von Netzwerknachrichtenschicht zu replizieren.
  20. Verfahren nach Anspruch 15, ferner umfassend: Auswählen des zweiten Replikationsschemas, basierend auf Netzwerkmerkmalen für das zweite Netzwerk, um Daten unter Verwendung des zweiten Typs von Netzwerknachrichtenschicht zu replizieren.
  21. Verfahren nach Anspruch 15, wobei der erste Typ von Netzwerknachrichtenschicht FibreChannel ist, wobei das erste Replikationsschema synchrone Replikation ist, wobei der zweite Typ von Netzwerknachrichtenschicht TCP/IP ist und wobei das zweite Replikationsschema nahezu synchrone Replikation ist.
DE102021113808.6A 2020-07-23 2021-05-28 Handhabung von Replikationen zwischen verschiedenen Netzwerken Pending DE102021113808A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/937,396 2020-07-23
US16/937,396 US11349917B2 (en) 2020-07-23 2020-07-23 Replication handling among distinct networks

Publications (1)

Publication Number Publication Date
DE102021113808A1 true DE102021113808A1 (de) 2022-01-27

Family

ID=79179537

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021113808.6A Pending DE102021113808A1 (de) 2020-07-23 2021-05-28 Handhabung von Replikationen zwischen verschiedenen Netzwerken

Country Status (2)

Country Link
US (2) US11349917B2 (de)
DE (1) DE102021113808A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11966415B2 (en) 2019-09-18 2024-04-23 Microsoft Technology Licensing, Llc Multimaster database for identity and electronic mail in DDIL environments

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11625806B2 (en) * 2019-01-23 2023-04-11 Qualcomm Incorporated Methods and apparatus for standardized APIs for split rendering
US11474986B2 (en) * 2020-04-24 2022-10-18 Pure Storage, Inc. Utilizing machine learning to streamline telemetry processing of storage media
US11442652B1 (en) 2020-07-23 2022-09-13 Pure Storage, Inc. Replication handling during storage system transportation
US11349917B2 (en) 2020-07-23 2022-05-31 Pure Storage, Inc. Replication handling among distinct networks
US20220100749A1 (en) * 2020-09-25 2022-03-31 Oracle International Corporation System and method for use of a fragmented query model in an analytic applications environment
US11991208B2 (en) * 2020-11-30 2024-05-21 Dell Products L.P. Secure fibre channel/NVMe fabric communication system
US11558306B2 (en) * 2020-12-23 2023-01-17 Cisco Technology, Inc. Selective fidelity rates for network traffic replication by a digital twin device
US11449625B2 (en) * 2021-01-18 2022-09-20 Vmware, Inc. Optimized directory enumeration and data copy for client drive redirection in virtual desktops
US11805171B2 (en) * 2021-03-04 2023-10-31 Dell Products L.P. Automated ethernet layer 3 (L3) connectivity between non-volatile memory express over fabric (NVMe-oF) hosts and NVM-oF subsystems using bind
US11818031B2 (en) 2021-03-04 2023-11-14 Dell Products L.P. Automated internet protocol (IP) route update service for ethernet layer 3 (L3) IP storage area networks (SANs)
US11593034B2 (en) * 2021-04-19 2023-02-28 Dell Products L.P. Simulating stretched volume remote instance using a shadow volume on a local system
US11954073B2 (en) * 2022-03-16 2024-04-09 International Business Machines Corporation Multi-protocol multi-site replication
JP7506707B2 (ja) * 2022-04-28 2024-06-26 株式会社日立製作所 記憶システム及び障害対処方法
US20240020056A1 (en) * 2022-07-12 2024-01-18 Dell Products L.P. Systems and methods for send log page commands for pull model devices

Family Cites Families (223)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2700401B1 (fr) 1993-01-08 1995-02-24 Cegelec Système de synchronisation de tâches répondantes.
US5651133A (en) 1995-02-01 1997-07-22 Hewlett-Packard Company Methods for avoiding over-commitment of virtual capacity in a redundant hierarchic data storage system
JPH08242229A (ja) 1995-03-01 1996-09-17 Fujitsu Ltd ネットワーク監視における状態整合処理システム
US5799200A (en) 1995-09-28 1998-08-25 Emc Corporation Power failure responsive apparatus and method having a shadow dram, a flash ROM, an auxiliary battery, and a controller
US6012032A (en) 1995-11-30 2000-01-04 Electronic Data Systems Corporation System and method for accounting of computer data storage utilization
US5933598A (en) 1996-07-17 1999-08-03 Digital Equipment Corporation Method for sharing variable-grained memory of workstations by sending particular block including line and size of the block to exchange shared data structures
US6085333A (en) 1997-12-19 2000-07-04 Lsi Logic Corporation Method and apparatus for synchronization of code in redundant controllers in a swappable environment
US7103797B1 (en) * 1998-03-30 2006-09-05 Emc Corporation Resource allocation throttling in remote data mirroring system
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
US20020107966A1 (en) 2001-02-06 2002-08-08 Jacques Baudot Method and system for maintaining connections in a network
US20030014523A1 (en) 2001-07-13 2003-01-16 John Teloh Storage network data replicator
US7827136B1 (en) 2001-09-20 2010-11-02 Emc Corporation Management for replication of data stored in a data storage environment including a system and method for failover protection of software agents operating in the environment
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
US7546364B2 (en) 2002-05-16 2009-06-09 Emc Corporation Replication of remote copy data for internet protocol (IP) transmission
US6895464B2 (en) 2002-06-03 2005-05-17 Honeywell International Inc. Flash memory management system and method utilizing multiple block list windows
US7334124B2 (en) 2002-07-22 2008-02-19 Vormetric, Inc. Logical access block processing protocol for transparent secure file storage
US7146521B1 (en) 2002-08-21 2006-12-05 3Pardata, Inc. Preventing damage of storage devices and data loss in a data storage system
CA2461446A1 (en) 2002-08-29 2004-03-11 Matsushita Electric Industrial Co., Ltd. Semiconductor memory apparatus and method for writing data into the flash memory device
US6831865B2 (en) 2002-10-28 2004-12-14 Sandisk Corporation Maintaining erase counts in non-volatile storage systems
US20040153844A1 (en) 2002-10-28 2004-08-05 Gautam Ghose Failure analysis method and system for storage area networks
US7072905B2 (en) 2002-12-06 2006-07-04 Sun Microsystems, Inc. Better placement of objects reachable from outside a generation managed by the train algorithm
AU2003299671A1 (en) 2002-12-17 2004-07-22 Systemauto System, method and computer program product for sharing information in a distributed framework
US7181580B2 (en) 2003-03-27 2007-02-20 International Business Machines Corporation Secure pointers
WO2004095201A2 (en) 2003-04-09 2004-11-04 Intervideo 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
US7293048B2 (en) 2003-10-29 2007-11-06 Hewlett-Packard Development Company, L.P. System for preserving logical object integrity within a remote mirror cache
US7246256B2 (en) 2004-01-20 2007-07-17 International Business Machines Corporation Managing failover of J2EE compliant middleware in a high availability system
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
JP4476683B2 (ja) 2004-04-28 2010-06-09 株式会社日立製作所 データ処理システム
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
JP4555029B2 (ja) * 2004-09-01 2010-09-29 株式会社日立製作所 ディスクアレイ装置
JP4887618B2 (ja) 2004-11-19 2012-02-29 日本電気株式会社 ストレージシステムとそのレプリケーション方法並びにプログラム
US7734573B2 (en) 2004-12-14 2010-06-08 Microsoft Corporation Efficient recovery of replicated data items
WO2006065973A2 (en) 2004-12-15 2006-06-22 Exostar Corporation Enabling trust in a federated collaboration of networks
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
EP1875393B1 (de) 2005-04-25 2015-08-05 NetApp, Inc. Architektur zur unterstützung spärlicher volumina
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
US9043640B1 (en) 2005-08-26 2015-05-26 Open Invention Network, LLP System and method for event-driven live migration of multi-process applications
US8584145B1 (en) 2010-08-06 2013-11-12 Open Invention Network, Llc System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications
US8621275B1 (en) 2010-08-06 2013-12-31 Open Invention Network, Llc System and method for event-driven live migration of multi-process applications
US8301700B1 (en) 2010-08-06 2012-10-30 Open Invention Network Llc System and method for event-driven live migration of multi-process applications
US8589953B1 (en) 2010-08-06 2013-11-19 Open Invention Network, Llc System and method for transparent consistent application-replication of multi-process multi-threaded applications
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
AU2006331932B2 (en) 2005-12-19 2012-09-06 Commvault Systems, Inc. Systems and methods for performing data replication
US7651593B2 (en) 2005-12-19 2010-01-26 Commvault Systems, Inc. Systems and methods for performing data replication
US7606844B2 (en) 2005-12-19 2009-10-20 Commvault Systems, Inc. System and method for performing replication copy storage operations
US7617253B2 (en) 2005-12-19 2009-11-10 Commvault Systems, Inc. Destination systems and methods for performing data replication
US7831783B2 (en) 2005-12-22 2010-11-09 Honeywell International Inc. Effective wear-leveling and concurrent reclamation method for embedded linear flash file systems
US7421552B2 (en) 2006-03-17 2008-09-02 Emc Corporation Techniques for managing data within a data storage system utilizing a flash-based memory vault
US7899780B1 (en) 2006-03-30 2011-03-01 Emc Corporation Methods and apparatus for structured partitioning of management information
US20070294564A1 (en) 2006-04-27 2007-12-20 Tim Reddin High availability storage system
US8266472B2 (en) 2006-05-03 2012-09-11 Cisco Technology, Inc. Method and system to provide high availability of shared data
US9455955B2 (en) 2006-05-17 2016-09-27 Richard Fetik Customizable storage controller with integrated F+ storage firewall protection
US7743239B2 (en) 2006-06-30 2010-06-22 Intel Corporation Accelerating integrity checks of code and data stored in non-volatile memory
US7627786B2 (en) 2006-09-26 2009-12-01 International Business Machines Corporation Tracking error events relating to data storage drives and/or media of automated data storage library subsystems
US8620970B2 (en) 2006-10-03 2013-12-31 Network Appliance, Inc. Methods and apparatus for changing versions of a filesystem
US7669029B1 (en) 2006-11-15 2010-02-23 Network Appliance, Inc. Load balancing a data storage system
US7710777B1 (en) 2006-12-20 2010-05-04 Marvell International Ltd. Semi-volatile NAND flash memory
US7640332B2 (en) 2006-12-27 2009-12-29 Hewlett-Packard Development Company, L.P. System and method for hot deployment/redeployment in grid computing environment
KR100923990B1 (ko) 2007-02-13 2009-10-28 삼성전자주식회사 플래시 저장 장치의 특성을 기반으로 한 컴퓨팅 시스템
US7925629B2 (en) 2007-03-28 2011-04-12 Netapp, Inc. Write ordering style asynchronous replication utilizing a loosely-accurate global clock
US9632870B2 (en) 2007-03-29 2017-04-25 Violin Memory, Inc. Memory system with multiple striping of raid groups and method for performing the same
US7996599B2 (en) 2007-04-25 2011-08-09 Apple Inc. Command resequencing in memory operations
US7991942B2 (en) 2007-05-09 2011-08-02 Stmicroelectronics S.R.L. Memory block compaction method, circuit, and system in storage devices based on flash memories
JP4430093B2 (ja) * 2007-08-29 2010-03-10 富士通株式会社 記憶制御装置およびファームウェア更新方法
US7870360B2 (en) 2007-09-14 2011-01-11 International Business Machines Corporation Storage area network (SAN) forecasting in a heterogeneous environment
US8775549B1 (en) 2007-09-27 2014-07-08 Emc Corporation Methods, systems, and computer program products for automatically adjusting a data replication rate based on a specified quality of service (QoS) level
KR101433859B1 (ko) 2007-10-12 2014-08-27 삼성전자주식회사 불휘발성 메모리 시스템 및 그것의 파일 데이터 관리 방법
US8271700B1 (en) 2007-11-23 2012-09-18 Pmc-Sierra Us, Inc. Logical address direct memory access with multiple concurrent physical ports and internal switching
US7743191B1 (en) 2007-12-20 2010-06-22 Pmc-Sierra, Inc. On-chip shared memory based device architecture
JP4471007B2 (ja) 2008-02-05 2010-06-02 ソニー株式会社 記録装置、記録装置の制御方法、記録装置の制御方法のプログラム及び記録装置の制御方法のプログラムを記録した記録媒体
US8949863B1 (en) 2008-04-30 2015-02-03 Netapp, Inc. Creating environmental snapshots of storage device failure events
US8099387B2 (en) 2008-06-02 2012-01-17 International Business Machines Corporation Managing consistency groups using heterogeneous replication engines
US9032032B2 (en) 2008-06-26 2015-05-12 Microsoft Technology Licensing, Llc Data replication feedback for transport input/output
US8214329B2 (en) 2008-08-26 2012-07-03 Zeewise, Inc. Remote data collection systems and methods
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
US8117156B2 (en) 2008-10-26 2012-02-14 Microsoft Corporation Replication for common availability substrate
US9473419B2 (en) 2008-12-22 2016-10-18 Ctera Networks, Ltd. Multi-tenant cloud storage system
BRPI0922542B1 (pt) 2008-12-22 2020-10-13 Google Llc Método realizado por um dispositivo de pluralidade de dispositivos num sistema distribuído de replicação de dados, sistema e memória legível em computador
US8345334B2 (en) 2008-12-31 2013-01-01 General Electric Company Mastering and replication of micro-holographic data storage media
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 存取儲存裝置的方法及相關控制電路
US8655848B1 (en) 2009-04-30 2014-02-18 Netapp, Inc. Unordered idempotent logical replication operations
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
US8335765B2 (en) 2009-10-26 2012-12-18 Amazon Technologies, Inc. Provisioning and managing replicated data instances
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
US8725698B2 (en) 2010-03-30 2014-05-13 Commvault Systems, Inc. Stub file prioritization in a data replication system
US8352422B2 (en) 2010-03-30 2013-01-08 Commvault Systems, Inc. Data restore systems and methods in a replication environment
US8856593B2 (en) 2010-04-12 2014-10-07 Sandisk Enterprise Ip Llc Failure recovery using consensus replication in a distributed flash memory system
US20120023144A1 (en) 2010-07-21 2012-01-26 Seagate Technology Llc Managing Wear in Flash Memory
US20120054264A1 (en) 2010-08-31 2012-03-01 International Business Machines Corporation Techniques for Migrating Active I/O Connections with Migrating Servers and Clients
US8566546B1 (en) 2010-09-27 2013-10-22 Emc Corporation Techniques for enforcing capacity restrictions of an allocation policy
US8775868B2 (en) 2010-09-28 2014-07-08 Pure Storage, Inc. Adaptive RAID for an SSD environment
US8949502B2 (en) 2010-11-18 2015-02-03 Nimble Storage, Inc. PCIe NVRAM card based on NVDIMM
US8812860B1 (en) 2010-12-03 2014-08-19 Symantec Corporation Systems and methods for protecting data stored on removable storage devices by requiring external user authentication
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
US8589723B2 (en) 2010-12-22 2013-11-19 Intel Corporation Method and apparatus to provide a high availability solid state drive
US8465332B2 (en) 2011-01-13 2013-06-18 Tyco Electronics Corporation Contact assembly for an electrical connector
WO2012120667A1 (ja) 2011-03-09 2012-09-13 株式会社日立製作所 計算機システム、データ複製スケジューリング方法及び計算機読み取り可能な非一時的記憶媒体
US8578442B1 (en) 2011-03-11 2013-11-05 Symantec Corporation Enforcing consistent enterprise and cloud security profiles
US8826041B1 (en) 2011-03-30 2014-09-02 Emc Corporation In-band detection mechanism for detecting intermediate layer in a storage I/O driver stack
US8495178B1 (en) * 2011-04-01 2013-07-23 Symantec Corporation Dynamic bandwidth discovery and allocation to improve performance for backing up data
US9235482B2 (en) 2011-04-29 2016-01-12 International Business Machines Corporation Consistent data retrieval in a multi-site computing infrastructure
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
US9170868B2 (en) 2011-07-27 2015-10-27 Cleversafe, Inc. Identifying an error cause within a dispersed storage network
US8931041B1 (en) 2011-07-29 2015-01-06 Symantec Corporation Method and system for visibility and control over access transactions between clouds using resource authorization messages
US20130036272A1 (en) 2011-08-02 2013-02-07 Microsoft Corporation Storage engine node for cloud-based storage
US8527544B1 (en) 2011-08-11 2013-09-03 Pure Storage Inc. Garbage collection in a storage system
US9525900B2 (en) 2011-09-15 2016-12-20 Google Inc. Video management system
JP2013077278A (ja) 2011-09-16 2013-04-25 Toshiba Corp メモリ・デバイス
US9350718B2 (en) 2011-09-29 2016-05-24 Oracle International Corporation Using representational state transfer (REST) for consent management
AU2011379960A1 (en) 2011-10-24 2014-05-15 Schneider Electric Industries Sas System and method for managing industrial processes
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
US8738813B1 (en) * 2011-12-27 2014-05-27 Emc Corporation Method and apparatus for round trip synchronous replication using SCSI reads
US20130219164A1 (en) 2011-12-29 2013-08-22 Imation Corp. Cloud-based hardware security modules
US8613066B1 (en) 2011-12-30 2013-12-17 Amazon Technologies, Inc. Techniques for user authentication
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access
US9423983B2 (en) 2012-01-19 2016-08-23 Syncsort Incorporated Intelligent storage controller
US9116812B2 (en) 2012-01-27 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a de-duplication cache
JP2013161235A (ja) 2012-02-03 2013-08-19 Fujitsu Ltd ストレージ装置、ストレージ装置の制御方法及びストレージ装置の制御プログラム
US10474584B2 (en) 2012-04-30 2019-11-12 Hewlett Packard Enterprise Development Lp Storing cache metadata separately from integrated circuit containing cache controller
US8832372B2 (en) 2012-05-24 2014-09-09 Netapp, Inc. Network storage systems having clustered raids for improved redundancy and load balancing
WO2013188382A2 (en) 2012-06-12 2013-12-19 Centurylink Intellectual Property Llc High performance cloud storage
US9130927B2 (en) 2012-07-02 2015-09-08 Sk Planet Co., Ltd. Single certificate service system and operational method thereof
US8817624B2 (en) 2012-07-25 2014-08-26 Futurewei Technologies, Inc. Higher layer compression with lower layer signaling
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
US9462502B2 (en) 2012-09-25 2016-10-04 Empire Technology Development Llc Limiting data usage of a device connected to the internet via tethering
US9245144B2 (en) 2012-09-27 2016-01-26 Intel Corporation Secure data container for web applications
US8990914B2 (en) 2012-09-28 2015-03-24 Intel Corporation Device, method, and system for augmented reality security
US8990905B1 (en) 2012-09-28 2015-03-24 Emc Corporation Protected resource access control utilizing intermediate values of a hash chain
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
US9367457B1 (en) 2012-12-19 2016-06-14 Veritas Technologies, LLC Systems and methods for enabling write-back caching and replication at different abstraction layers
US9075529B2 (en) 2013-01-04 2015-07-07 International Business Machines Corporation Cloud based data migration and replication
US9436720B2 (en) 2013-01-10 2016-09-06 Pure Storage, Inc. Safety for volume operations
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
US9083725B2 (en) 2013-08-12 2015-07-14 Fred Korangy System and method providing hierarchical cache for big data applications
US9454423B2 (en) 2013-09-11 2016-09-27 Dell Products, Lp SAN performance analysis tool
DE112013007296T5 (de) 2013-09-27 2016-04-21 Intel Corporation Bestimmung eines geeigneten Ziels für einen Initiator durch einen Prozessor auf Steuerungsebene
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
US9880777B1 (en) 2013-12-23 2018-01-30 EMC IP Holding Company LLC Embedded synchronous replication for block and file objects
US9529546B2 (en) 2014-01-08 2016-12-27 Netapp, Inc. Global in-line extent-based deduplication
US9460182B2 (en) * 2014-03-20 2016-10-04 International Business Machines Corporation Networking-assisted input/output order preservation for data replication
US9250823B1 (en) 2014-05-20 2016-02-02 Emc Corporation Online replacement of physical storage in a virtual storage system
EP2988221B1 (de) 2014-06-27 2017-08-09 Huawei Technologies Co., Ltd. Steuerung, flash-speichervorrichtung und verfahren zum schreiben von daten in eine flash-speicher-vorrichtung
US9766930B2 (en) 2014-06-28 2017-09-19 Vmware, Inc. Using active/passive asynchronous replicated storage for live migration
US9516167B2 (en) 2014-07-24 2016-12-06 Genesys Telecommunications Laboratories, Inc. Media channel management apparatus for network communications sessions
US10628380B2 (en) 2014-07-24 2020-04-21 Netapp Inc. Enabling data replication processes between heterogeneous storage systems
US10455019B2 (en) 2014-09-10 2019-10-22 Oracle International Corporation Highly performant reliable message storage using in-memory replication technology
US10204010B2 (en) 2014-10-03 2019-02-12 Commvault Systems, Inc. Intelligent protection of off-line mail data
US10021186B2 (en) 2014-12-19 2018-07-10 Microsoft Technology Licensing, Llc Guaranteed delivery of replication message
US9864791B2 (en) 2014-12-19 2018-01-09 Microsoft Technology Licensing, Llc Flow for multi-master replication in distributed storage
US20160259836A1 (en) * 2015-03-03 2016-09-08 Overland Storage, Inc. Parallel asynchronous data replication
US9521200B1 (en) 2015-05-26 2016-12-13 Pure Storage, Inc. Locally providing cloud storage array services
US9716755B2 (en) 2015-05-26 2017-07-25 Pure Storage, Inc. Providing cloud storage array services by a local storage array in a data center
US9300660B1 (en) 2015-05-29 2016-03-29 Pure Storage, Inc. Providing authorization and authentication in a cloud for a user of a storage array
US20160350009A1 (en) 2015-05-29 2016-12-01 Pure Storage, Inc. Buffering data to be written to an array of non-volatile storage devices
US9444822B1 (en) 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US10021170B2 (en) 2015-05-29 2018-07-10 Pure Storage, Inc. Managing a storage array using client-side services
US9774539B1 (en) * 2015-06-15 2017-09-26 Veritas Technologies Llc Systems and methods for reconfiguring data flow across network channels
US10310951B1 (en) 2016-03-22 2019-06-04 EMC IP Holding Company LLC Storage system asynchronous data replication cycle trigger with empty cycle detection
US9959063B1 (en) 2016-03-30 2018-05-01 EMC IP Holding Company LLC Parallel migration of multiple consistency groups in a storage 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
US10534796B1 (en) 2016-06-30 2020-01-14 EMC IP Holding Company LLC Maintaining an active-active cloud across different types of cloud storage services
US10459657B2 (en) 2016-09-16 2019-10-29 Hewlett Packard Enterprise Development Lp Storage system with read cache-on-write buffer
US10942666B2 (en) 2017-10-13 2021-03-09 Cisco Technology, Inc. Using network device replication in distributed storage clusters
US10496489B1 (en) 2017-11-21 2019-12-03 EMC IP Holding Company LLC Storage system configured for controlled transition between asynchronous and synchronous replication modes
US10904068B2 (en) 2018-01-12 2021-01-26 Datera, Inc. System and method to provide seamless data placement, data movement, and data management into cloud
US10496324B2 (en) 2018-03-30 2019-12-03 EMC IP Holding Company LLC Storage system with concurrent fan-out asynchronous replication using decoupled replication sessions
US11645237B2 (en) 2018-05-10 2023-05-09 International Business Machines Corporation Replicating data utilizing a virtual file system and cloud storage
US20190354628A1 (en) 2018-05-21 2019-11-21 Pure Storage, Inc. Asynchronous replication of synchronously replicated data
US11099777B2 (en) 2018-07-30 2021-08-24 EMC IP Holding Company LLC Unified approach to import, replication, and migration of a storage volume
US11165849B2 (en) * 2018-07-31 2021-11-02 Pixspan, Inc. Accelerated cloud data transfers using optimized file handling and a choice of speeds across heterogeneous network paths
US10970310B2 (en) 2018-08-02 2021-04-06 Netapp Inc. Synchronous replication based cutover engine
US11349917B2 (en) 2020-07-23 2022-05-31 Pure Storage, Inc. Replication handling among distinct networks

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11966415B2 (en) 2019-09-18 2024-04-23 Microsoft Technology Licensing, Llc Multimaster database for identity and electronic mail in DDIL environments

Also Published As

Publication number Publication date
US20220030062A1 (en) 2022-01-27
US11882179B2 (en) 2024-01-23
US20220263898A1 (en) 2022-08-18
US11349917B2 (en) 2022-05-31

Similar Documents

Publication Publication Date Title
US11797569B2 (en) Configurable data replication
US11838359B2 (en) Synchronizing metadata in a cloud-based storage system
US11882179B2 (en) Supporting multiple replication schemes across distinct network layers
US11704044B2 (en) Modifying a cloned image of replica data
US20210303164A1 (en) Managing host mappings for replication endpoints
US11704202B2 (en) Recovering from system faults for replicated datasets
DE112020003420T5 (de) Datenwiederherstellung in einem virtuellen Speichersystem
US20190354628A1 (en) Asynchronous replication of synchronously replicated data
DE112020003423T5 (de) Architektur von virtuellem speichersystem
US11789638B2 (en) Continuing replication during storage system transportation
DE112020003277T5 (de) Erzeugen von tags für die datenzuweisung
US11625185B2 (en) Transitioning between replication sources for data replication operations
US20220147490A1 (en) Replica transitions for file storage
US20210303527A1 (en) Mapping equivalent hosts at distinct replication endpoints
WO2023129292A1 (en) Improved ribbon cable alignment apparatus
WO2023070025A1 (en) Declarative provisioning of storage
US20220091743A1 (en) Bucket versioning snapshots
WO2023239701A1 (en) Converting storage resources to distributed persistent storage for containerized applications

Legal Events

Date Code Title Description
R012 Request for examination validly filed