DE102019111068A1

DE102019111068A1 - Datenspeichersystem mit LUN-Archivierung in die Cloud unter Verwendung einer Volume-to-Object(Volumen-zu-Objekt)-Umsetzung

Info

Publication number: DE102019111068A1
Application number: DE102019111068.8A
Authority: DE
Inventors: Jean-Pierre Bono; Sudhir Srinivasan
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2018-04-30
Filing date: 2019-04-29
Publication date: 2019-10-31
Also published as: US20190334984A1; GB2575155B; GB2575155A; US10536522B2; GB201906019D0

Abstract

Das Archivieren lokaler logischer Einheiten von Datenspeichern (LUNs) im Cloud-Speicher, wobei sich die lokalen LUNs auf dem lokalen physischen Speicher eines Datenspeichersystems befinden, umfasst das Einrichten einer Spiegelung zwischen einer lokalen LUN und einer Cloud-gestützten LUN, gesichert durch physische Cloud-Speicherung eines Cloud-Speichersystems, wobei die Spiegelung den Dateninhalt der Cloud-gestützten LUN mit dem Dateninhalt der lokalen LUN identisch macht. Sobald die Spiegelung eingerichtet ist, wird (a) ein Stub auf der lokalen LUN abgelegt, um nachfolgende EAs an die Cloud-gestützte LUN zu leiten, und (b) der lokale physische Speicher der lokalen LUN für die Zuordnung zu anderen lokalen LUNs freigegeben. Nachfolgende EAs an die lokale LUN werden von der Cloud-gestützten LUN erfüllt. Eine archivierte LUN kann durch einen Wiederherstellungsprozess wiederhergestellt werden.

Description

STAND DER TECHNIK
Die vorliegende Erfindung bezieht sich auf das Gebiet von Datenspeichersystemen, die zur sekundären Speicherung von Daten in Computersystemen verwendet werden. Insbesondere betrifft sie Datenspeichersysteme, die einen Cloud-basierten Speicher zum Speichern von Daten lokal definierter Speicherelemente wie beispielsweise logischer Einheiten (LUNs) verwenden.
ZUSAMMENFASSUNG
In modernen Computersystemen kann es wünschenswert sein, Datenspeicherdienste zu verwenden, die von sogenannten „Cloud“-Anbietern verfügbar sind, deren Skaleneffekte ihnen helfen, eine sehr kostengünstige und zuverlässige Femdatenspeicherung bereitzustellen. Die vorliegende Offenbarung ist auf eine Technik gerichtet, die bestimmte Daten in „der Cloud“ (d.h. in einem entfernten Speichersystem mit einer allgemeinen, objektorientierten Schnittstelle) unter Verwendung bestimmter Verfahren speichert, einhergehend mit der Fähigkeit zur Wiederherstellung von Daten aus der Cloud zurück zum lokalen Speicher. Sie ist insbesondere auf die Cloud-basierte Archivierung inaktiver LUNs in der Cloud gerichtet, während Attribute/Merkmale wie die folgenden beibehalten/aktiviert werden:

1) Sobald eine LUN archiviert ist, kann der zugehörige lokale Speicher freigegeben/wiederbeansprucht werden, wodurch im lokalen Speicher mehr freier Platz zum Erstellen neuer LUNs oder zur Verwendung für andere vorhandene LUNs geschaffen wird.
2) Eine archivierte LUN kann Anwendungen weiterhin zur Verfügung stehen, mit der Erwartung, dass nur sehr wenige EAs an sie geleitet werden, da sie eigentlich als inaktiv gilt.
3) Writes (Schreibvorgänge) in eine archivierte LUN werden lokal zwischengespeichert und außerhalb der Bandbreite von Host-EAs über eine Cloud-Anwendung in die Cloud übertragen.
4) Reads (Lesevorgänge) zu einer archivierten LUN werden über die Cloud-Anwendung aus der Cloud abgerufen.

Insbesondere wird ein computergestütztes Verfahren zum Archivieren lokaler logischer Einheiten von Datenspeichern (LUNs) in Cloud-Speicher offenbart, wobei sich die lokalen LUNs auf dem lokalen physischen Speicher eines Datenspeichersystems befinden. Das Verfahren umfasst das Einrichten einer Spiegelung zwischen einer lokalen LUN und einer Cloud-gestützten LUN, die durch den physischen Cloud-Speicher eines separaten Cloud-Speichersystems gesichert wird, wobei die Spiegelung die Identität zwischen dem Dateninhalt der Cloud-gestützten LUN und dem Dateninhalt der lokalen LUN herstellt. Wenn die Spiegelung eingerichtet ist, legt die Methode (a) einen Stub (Platzhalter) auf der lokalen LUN ab, wobei der Stub anzeigt, dass die lokale LUN archiviert wurde, und die Cloud-gestützte LUN als Ziel nachfolgender EAs an die lokale LUN identifiziert, und (b) gibt die Methode den lokalen physischen Speicher der lokalen LUN für die Zuteilung zu anderen lokalen LUNs frei. Für nachfolgende EAs an die lokale LUN werden die EAs von der Cloud-gestützten LUN abhängig vom Vorhandensein des Stubs erfüllt.
Figurenliste
Die vorgenannten und andere Ziele, Merkmale und Vorteile werden aus der folgenden Beschreibung bestimmter Ausführungsformen der Erfindung ersichtlich, wie in den beigefügten Zeichnungen dargestellt, in denen gleiche Bezugszeichen sich in den verschiedenen Ansichten auf dieselben Teile beziehen.

1 ist ein Blockdiagramm eines Datenspeichersystems;
2 ist ein schematisches Diagramm von Metadaten;
3 ist ein schematisches Diagramm der Beziehungen zwischen einer lokalen LUN und einer entsprechenden Cloud-gestützten LUN unmittelbar nach dem Beginn eines Archivierungsprozesses;
4 ist ein schematisches Diagramm der Beziehungen zwischen einer lokalen LUN und einer entsprechenden Cloud-gestützten LUN nach Abschluss des Archivierungsprozesses;
5 ist ein Flussdiagramm für eine LUN-Archivierungsoperation.
6 ist ein Flussdiagramm für eine LUN-Wiederherstellungsoperation.

DETAILLIERTE BESCHREIBUNG
1 zeigt eine beispielhafte Umgebung 100, in der Ausführungsformen der gegenständlichen verbesserten Technik praktiziert werden können. Hier greifen mehrere Hostcomputervorrichtungen („Hosts“) 110 über ein Netzwerk 114 auf ein Datenspeichersystem 116 zu. Auch eine Administrationsmaschine 104 kann über das Netzwerk 114 mit dem Datenspeichersystem 116 verbunden sein. Das Datenspeichersystem 116 kann eine beliebige Anzahl von Computerknoten umfassen, wobei zwei Knoten 120a und 120b spezifisch gezeigt sind. Der erste Knoten 120a ist dazu konfiguriert, Host-E/A-Anforderungen 112, beispielsweise Leseanforderungen und Schreibanforderungen, zu verarbeiten, und ist mit einem angeschlossenen Speicher 170 verbunden, beispielsweise mit einem oder mehreren Magnetplattenlaufwerken, Festkörperlaufwerken und dergleichen. In einem Beispiel ist der erste Knoten 120a über Kabel oder über ein SAN (Storage Area Network) mit dem angeschlossenen Speicher 170 verbunden. Der zweite Knoten 120b ist dazu konfiguriert, auf einen Cloud-Speicher zuzugreifen, und ist mit einem Cloud-basierten Datenspeicher 180 gekoppelt, z. B. über ein WAN (Wide Area Network), beispielsweise das Internet. Der Cloud-basierte Datenspeicher 180 kann Teil einer öffentlichen Cloud oder einer privaten Cloud sein und kann von jeder geeigneten Plattform bereitgestellt werden, wie etwa Amazon Cloud Services (ACS), Microsoft Azure, Dell EMC Elastic Cloud Services (ECS) und dergleichen. In einem Beispiel speichert der Cloud-basierte Datenspeicher 180 Daten in Form von Objekten 182 und unterstützt die Speicherung von durchsuchbaren Metadatenelementen 184. Zum Beispiel unterstützt der Cloud-basierte Datenspeicher 180 das Speichern von durchsuchbaren Blobs (binary large objects), in denen die durchsuchbaren Metadatenelemente 184 bereitgestellt werden können. Die Erfindung ist jedoch nicht auf objektbasierte Daten oder auf Datenspeicher beschränkt, die Blobs bereitstellen. Wie allgemein bekannt, sind die Objekte 182 benutzerdefinierte Einheiten von Daten, die jeweils eine Größe sowie eine eindeutige Identität haben. Die Beziehung der Objekte 182 zu internen Datenstrukturen des Datenspeichersystems 116, wie beispielsweise Volumes, LUNs, Blöcke usw., wird durch das Datenspeichersystem 116 und insbesondere durch einen VTO-Umsetzer 151 (Volume-to-Object) definiert, wie weiter unten näher beschrieben.
Jeder der Knoten 120a und 120b enthält einen Satz von Kommunikationsschnittstellen (122a oder 122b), wie beispielsweise einen oder mehrere Netzwerkschnittstellenadapter, zum Umwandeln elektronischer und/oder optischer Signale, die über das Netzwerk 114 empfangen werden, in eine elektronische Form zur Verwendung durch den jeweiligen Knoten. Jeder der Knoten 120a und 120b enthält ferner einen Satz von Verarbeitungseinheiten (124a oder 124b) und Speicher (130a oder 130b). Jeder Satz von Verarbeitungseinheiten 124a und 124b enthält einen oder mehrere Verarbeitungs-Chips und/oder Baugruppen. In einem bestimmten Beispiel enthält jeder Satz von Verarbeitungseinheiten zahlreiche Multi-core CPUs. Jeder der Speicher 130a und 130b enthält sowohl einen flüchtigen Speicher (z. B. ein RAM) als auch einen nichtflüchtigen Speicher, wie beispielsweise eine oder mehrere ROMs, Plattenlaufwerke, Festkörperlaufwerke und dergleichen. In jedem Knoten 120 bilden der Satz von Verarbeitungseinheiten und der Speicher zusammen eine Steuerschaltung, die dazu konstruiert und angeordnet ist, verschiedene hier beschriebene Verfahren und Funktionen auszuführen. Jeder der Speicher 130a und 130b enthält unterschiedliche Software-Konstrukte, die in Form von ausführbaren Anweisungen realisiert sind. Wenn die ausführbaren Anweisungen von dem jeweiligen Satz von Verarbeitungseinheiten 124a oder 124b ausgeführt werden, wird der Satz von Verarbeitungseinheiten veranlasst, die durch die Softwarekonstrukte definierten Operationen auszuführen. Obwohl bestimmte Softwarekonstrukte spezifisch gezeigt und beschrieben werden, versteht es sich, dass jeder Speicher typischerweise viele andere Softwarekonstrukte enthält, die nicht dargestellt sind, beispielsweise verschiedene Anwendungen, Prozesse und Daemons. Ferner ist zu beachten, dass die Verwendung von zwei Knoten 120a und 120b lediglich veranschaulichend ist, da das Datenspeichersystem 116 eine beliebige Anzahl von Knoten umfassen kann, einschließlich eines einzelnen Knotens.
Wie ferner in 1 gezeigt ist, „enthält“ der Speicher 130a des Knotens 120a, d.h. er realisiert durch Ausführung von Softwareanweisungen, einen Blockanbieter 134, der einen Archivmanager (Archive Mgr) 136 enthält. Der Blockanbieter 134 unterhält logische Speichereinheiten (LUNs) 135 und stellt sie den Hosts 110 zur sekundären Datenspeicherung zur Verfügung. Der Archivmanager 136 sorgt für die Archivierung der LUNs 135 in einem Cloud-Speicher. Die LUNs 135 und die Snaps 137 sind typischerweise „lokal gesichert“, d.h. sie nutzen den angeschlossenen Speicher 170 für den zugrunde liegenden physischen Speicher für die LUNs 135 und die Snaps 137, im Unterschied zu „Cloud-gestützten“ Elementen, die den Cloud-basierten Datenspeicher 180 verwenden, wie weiter unten beschrieben. Die Archivierung umfasst das Kopieren von LUN-Daten in den Cloud-basierten Datenspeicher 180 und das nachfolgende Freigeben des lokalen Speichers. Eine weitere Struktur und Arbeitsweise des Blockanbieters 134 ist unten dargestellt. Der Speicher 130a kann eine beliebige Anzahl solcher Blockanbieter 134 enthalten.
Obwohl in 1 nicht gezeigt, kann das Datenspeichersystem 116 auch einen oder mehrere zusätzliche Knoten enthalten, die als NAS-(Network Attached Storage)-Knoten fungieren, die selbst Kunden des Blockanbieters 134 sein können, die den dadurch bereitgestellten Blockspeicher verwenden. Wie allgemein bekannt, dient ein NAS-Knoten als netzwerkbasierte Erweiterung eines hostbasierten Dateisystems und verwendet ein Dateisystemzugriffsprotokoll bei der Kommunikation mit den Hosts 110 über das Netzwerk 114. Beispiele für solche Protokolle sind das Common Internet File System (CIFS) und der Server Messaging Block (SMB). Ein solcher NAS-Knoten kann lose mit dem Blockanbieter 134 (z. B. über das Netzwerk 114) oder wesentlich enger gekoppelt sein, z. B. durch den physischen Speicher eines einzelnen Computerservers, der sowohl den NAS-Knoten als auch den Blockanbieter 134 je als virtuelle Maschinen hostet.
Der Speicher 130b des Knotens 120b enthält eine Cloud-Appliance 150, die ferner einen Volume-to-Object-Umsetzer (VTO-Umsetzer) 151 (hier auch als VTO 151 bezeichnet), eine LUN-Wartungs- und Orchestrierungs-Einheit 152 (LNMO) und eine oder mehrere Cloud-APIs (Anwendungsprogrammschnittstellen) 154 zum Management der Kommunikation mit dem Cloud-basierten Datenspeicher 180 enthält. Der VTO-Umsetzer 151 ist dazu konfiguriert, blockbasierte Volumes aus jeweiligen Objektgruppen 182 im Datenspeicher 180 zusammenzusetzen. Beispielhafte blockbasierte Volumes sind als VTO-LUNs 156 und VTO-Snaps 158 analog zu den lokalen LUNs 135 und Snaps 137 des Blockanbieters 134 dargestellt. Im Betrieb ordnet der VTO 151 den Volumes entsprechende Objektgruppen 182 zu. Der VTO 151 ist ferner so konfiguriert, dass er die gemeinsame Nutzung von Objekten zwischen Volumes unterstützt, sodass dasselbe Objekt 182 Teil mehrerer Volumes sein kann, z.B. wenn die entsprechenden Daten über die Volumes hinweg identisch sind. Der VTO 151 ist darüber hinaus so konfiguriert, dass er Snapshot-Operationen unterstützt. Beispielsweise kann der VTO 151 einen Snapshot eines Volumes als Point-in-Time-Version dieses Volumes erzeugen. Aufgrund des Objekts-Sharings können das Volume und sein Snapshot die meisten, wenn nicht gar alle Objekte gemeinsam nutzen, die sie unterstützen. Darüber hinaus werden Objekte in der Regel von mehreren unterschiedlichen Snapshots desselben Volumes gemeinsam genutzt. Der VTO-Umsetzer 151 speichert vorzugsweise Kartierungsstrukturen zum Organisieren von Volume-Daten in Objekten 182 sowie die Daten selbst. Ein geeigneter VTO-Umsetzer, der diese Merkmale aufweist, ist von Dell EMC aus Hopkinton, MA, als Teil der CloudArray-Appliance im Handel erhältlich.
Die Cloud-Appliance 150 ist dazu konfiguriert, den Datenspeicher 180 basierend auf durchsuchbaren Metadatenelementen 184 abzufragen. Beispielsweise ordnet der VTO-Umsetzer 151 jedem der durchsuchbaren Metadatenelemente 184 ein entsprechendes Volume zu. Beispielsweise kann für jedes vom VTO-Umsetzer 151 verwaltete Volume ein anderes durchsuchbares Metadatenelement 184 bereitgestellt werden. Wie unten beschrieben enthalten die durchsuchbaren Metadatenelemente 184 Informationen, die LUNs und Versionen davon identifizieren, denen bestimmte VTO-Datenträger zugeordnet sind.
In einer beispielhaften Operation empfängt der Knoten 120a im Datenspeichersystem 116 E/A-Anforderungen 112 von den Hosts 110 (oder von einem separaten NAS-Knoten, wie oben erwähnt). Die E/A-Anforderungen 112 enthalten Leseanforderungen und/oder Schreibanforderungen, die an die LUNs 135 (und in einigen Fällen an die Snaps 137) gerichtet sind. Der Blockanbieter 134 erfüllt die Anforderungen durch Zugriff auf den zugrunde liegenden physischen Speicher. Für aktive, nicht archivierte („Produktions“-) LUNs 135 bedeutet dies den Zugriff auf den lokal angeschlossenen Speicher 170. In anderen Fällen kann es erforderlich sein, über die Cloud-Appliance 150 auf einen anderen physischen Speicher zuzugreifen, beispielsweise den Cloud-basierten Datenspeicher 180. Typischerweise implementiert der Blockanbieter 134 eine Art Zwischenspeicherung, um einzelne Lese- und Schreibvorgänge von dem angefügten Speicher 170 zu entkoppeln, wie in der Fachwelt allgemein bekannt ist.
Die Verbindungen zwischen dem Blockanbieter 134 und der Cloud-Appliance 150 umfassen sowohl einen Datenübertragungskanal als auch einen Steuerkanal. Der Datenübertragungskanal verwendet vorzugsweise ein Blockspeicherprotokoll wie iSCSI, und dieses bestimmte Beispiel wird in der verbleibenden Beschreibung angenommen. Der Steuerkanal ist für allgemeinere Kommunikationen strukturiert, beispielsweise für den Austausch von Out-of-Band-Anforderungen und entsprechenden Antworten. Der Steuerkanal kann eine Schnittstelle verwenden, die sogenannte RESTfül-Techniken einsetzt, wobei REST für den in der Fachwelt allgemein bekannten „Representational State Transfer“ steht. Wie bei den Verbindungen zu einem separaten NAS-Knoten, wie oben beschrieben, können der Blockanbieter 134 und die Cloud-Appliance 150 lose gekoppelt sein, z. B. über ein externes Netzwerk 114, oder sie können viel enger gekoppelt sein, z.B. innerhalb eines einzelnen VM-Server-Computers.
2 zeigt beispielhafte Informationen 210, die der VTO-Umsetzer 151 in einem durchsuchbaren Metadatenelement 184 speichern kann. Die Informationen 210 können als unterschiedliche Felder oder auf jede geeignete Weise gespeichert werden, abhängig von den Merkmalen, die von dem bestimmten Typ des verwendeten Cloud-basierten Datenspeichers 180 bereitgestellt werden. In einem Beispiel wird ein anderes durchsuchbares Metadatenelement 184 für jeden Snapshot erstellt, der gemäß einer Gruppen-Snapshot-Operation erzeugt wird. In einem nicht einschränkenden Beispiel enthält jedes durchsuchbare Metadatenelement 184 die folgenden Informationen:

• LUN-Name. Der Name der Produktions-LUN 135, die diesem Volume zugeordnet ist (VTO LUN 156 oder VTO Snap 158).
• LUN UUID. Eine universell eindeutige Kennung der LUN
• Versionsnummer. Eine Nummer, die bei jeder Snapshot-Operation erhöht wird und eine Versionsnummer der LUN angibt.
• Zeitstempel. Eine Uhrzeit und ein Datum, wann die Snapshot-Operation ausgeführt wurde, die diesen Snapshot erzeugt hat.

Einige der Informationen 210 in dem durchsuchbaren Metadatenelement 184 können eher aus operativen Gründen als aus Gründen der Notwendigkeit bereitgestellt werden. Informationen können während Wiederherstellungsvorgängen und/oder zur Unterstützung verschiedener Arten von Abfragen hilfreich sein. Beispielsweise können Administratoren durchsuchbare Metadatenelemente 184 basierend auf einer der Informationen 210 abfragen. Das Abfragen auf der Basis eines Zeitstempels erlaubt Administratoren beispielsweise die Wiederherstellung zu einem bestimmten Zeitpunkt, beispielsweise vor einem bekannten Korruptionsereignis. Der VTO-Umsetzer 151 kann durchsuchbare Metadatenelemente 184 den jeweiligen Snapshots oder Archiven auf verschiedene Weise zuordnen, beispielsweise beim Abbilden von Metadaten im Datenspeicher 180, in vordefinierten Speicherbereichen oder auf irgendeine geeignete Weise.
3 zeigt detailliertere Aspekte des Blockanbieters 134 und der Cloud-Appliance 150 in Bezug auf das Erstellen von Cloud-basierten Archiven lokaler LUNs 135. Dieses Diagramm zeigt eine Situation nach der Erstellung einer Cloud-basierten VTO LUN 156, die Teil des Archivierungsprozesses ist, wie weiter unten beschrieben. Einer lokalen LUN 135 ist ein lokaler Speicher des angeschlossenen Speichers 170 zugeordnet, der durch eine funktionale Verbindung 200 angezeigt wird, und weist auch eine separate funktionale Verbindung 202 zu einer entsprechenden VTO LUN 156 auf, die durch einen Satz 204 von Objekten 182 gesichert wird. In diesem Betriebszustand ist die Archivierung nicht vollständig, und somit werden die an die lokale LUN 135 gerichteten E/As immer noch bezüglich des angeschlossenen Speichers 170 bedient. Dies wird durch die Angabe gezeigt, dass auf der Verbindung 200 Datenabrufe und Umspeicherungen (Destaging) vorkommen. Die Verbindung 202 ist eine Spiegelverbindung, über die die Daten der lokalen LUN 135 in die Archiv-VTO-LUN 156 kopiert werden, wie weiter unten beschrieben.
4 zeigt die Anordnung von 3 zu einem späteren Zeitpunkt, nachdem die Archivierung abgeschlossen ist. Ein als „Stub“ 210 bezeichneter Zeiger wurde auf der lokalen LUN 135 abgelegt, und die funktionelle Verbindung 200 zum angeschlossenen Speicher 170 wurde deaktiviert. Der zugrunde liegende physische Speicher wird jetzt von der VTO LUN 156 bereitgestellt, und der Stub 210 zeigt auf die VTO LUN 156. An die lokale LUN 135 gerichtete IOs werden nun bezüglich der VTO-LUN 156 bedient. Obwohl diese Art von Zugriff im Allgemeinen viel langsamer ist und damit die Leistung beeinträchtigt, wird davon ausgegangen, dass solche EAs bestenfalls sehr selten sind, zumal die LUN 135 archiviert wurde. Das System überwacht vorzugsweise die Verwendung von archivierten LUNs 135, und wenn sie mehr Verwendung erfahren, kann eine Entscheidung getroffen werden, die LUN in den nichtarchivierten Status zurückzusetzen. Ein Prozess für eine solche Wiederherstellung wird unten beschrieben.
5 zeigt einen LUN-Archivierungsprozess. Der Prozess wird durch die Aktion der LNMO 152 der Cloud-Appliance 150 initiiert und primär gesteuert. Dies kann in Übereinstimmung mit einem vorbestimmten Zeitplan oder einer anderen Richtlinie erfolgen, z. B. Überwachung der Nutzung und Verfolgen des Unterschreitens eines bestimmten Schwellenwerts. In alternativen Ausführungsformen können die Initiierung und/oder Steuerung andere Akteure einschließen, einschließlich beispielsweise des Blockanbieters 134 und/oder eines externen Agenten wie des Administrators 104.
Es wird gezeigt, dass der Prozess zwei Hauptoperationen aufweist, wobei bei 300 eine Spiegelung und bei 302 eine nachfolgende laufende Operation („Ausführung“) durchgeführt wird.
In dem Spiegelungsprozess 300 wird bei 304 basierend auf Heuristiken bestimmt, dass eine LUN 135 als inaktiv gilt, und der Archivierungsprozess für diese LUN wird initiiert.
Bei 306 wird eine VTO-LUN der gleichen Größe wie die zu archivierende lokale LUN 135 erstellt.
Bei 308 fordert die LNMO 152 den Blockanbieter 134 auf, die LUN 135 über iSCSI verfügbar zu machen.
Bei 310 fordert die LNMO 152 (unter Verwendung einer REST-Anforderung) von dem Blockanbieter 134 eine Karte der Offsets innerhalb der LUN 135 an, in die geschrieben wurde.
Bei 312 orchestriert der LNMO 152 eine Kopie der LUN 135 in die VTO-LUN 156, die eine Spiegelverbindung zwischen ihnen herstellt und verwendet. Während des Kopiervorgangs müssen E/As an die LUN 135 auf irgendeine Weise verwaltet werden, um die Kontinuität zu gewährleisten. Bei einer Methode wird bestimmt, ob ein EA auf sowohl die Quell-LUN 135 wie auf die VTO-LUN 156 oder nur auf die Quell-LUN 135 anzuwenden ist, abhängig von dem Offset des EA relativ zu dem Ort, an dem sich der Cursor der Kopie befindet. Wenn der Offset bereits kopiert wurde, muss jede Aktualisierung dieses Offsets auf die VTO-LUN 156 gespiegelt werden.
In der nachfolgenden Operation 302 legt die LNMO 152 bei 314 den Stub 210 auf der lokalen LUN 135 ab, die auf die VTO LUN 156 zeigt, und der lokale Speicher (des angeschlossenen Speichers 170), der der lokalen LUN 135 zugeordnet ist, wird freigegeben, d.h. verfügbar gemacht für die Zuordnung zu anderen LUNs.
Bei 316 werden nachfolgende IOs in Bezug auf die VTO LUN 156 verarbeitet. Writes in die archivierte LUN 135 werden lokal zwischengespeichert und an den Host bestätigt und anschließend auf die VTO LUN 156 umgespeichert. Reads an der archivierten LUN 135 werden entweder aus dem lokalen Write-Cache abgerufen (wenn der Offset dort gespeichert ist) oder von der VTO LUN 156 erhalten.
6 veranschaulicht Vorgänge eines Wiederherstellungsprozesses oder -Workflows, der auf eine gespeicherte, Cloud-gestützte VTO LUN 156 zugreift, um eine Produktions-LUN 135 wiederherzustellen. Wie erwähnt, kann dieser Wiederherstellungsprozess verwendet werden, wenn die Zugriffshäufigkeit soweit angestiegen ist, dass der Zugriff mit niedrigerer Latenz und höherer Bandbreite erforderlich ist, der durch Nutzung des angeschlossenen Speichers 170 anstelle des Cloud-Speichers 180 bereitgestellt wird.
Bei 400 initiiert LNMO 152 eine Kopie der VTO-LUN 156 in die lokale LUN 135.
Bei 402 werden während des Kopierens auftretende EAs verarbeitet. Schreibvorgänge werden lokal zwischengespeichert und selektiv auf die VTO-LUN 156 umgespeichert oder nicht, abhängig vom Offset relativ zum Rückkopiercursor. Lesevorgänge werden entweder von der lokalen LUN 135 oder der VTO LUN 156 bedient, abhängig vom Offset relativ zum Rückkopiercursor und davon, ob die Daten eventuell lokal zwischengespeichert wurden.
Bei 404 wird der Stub 210 entfernt, sobald die Kopie abgeschlossen ist, und die entsprechende VTO LUN 156 wird gelöscht. Zu diesem Zeitpunkt ist die LUN 135 wieder lokal gesichert und bereit für die Nutzung bei voller Leistung.
Auch wenn hier unterschiedliche Ausführungsformen der Erfindung im Einzelnen gezeigt und beschrieben worden sind, ist dem Fachmann bewusst, dass verschiedene Änderungen an der Form und den Details darin vorgenommen werden können, ohne vom Geltungsumfang der Erfindung abzuweichen, wie er durch die beigefügten Ansprüche definiert ist.

Claims

Verfahren zum Archivieren lokaler logischer Einheiten von Datenspeichern (LUNs) in Cloud-Speicher, wobei sich die lokalen LUNs auf dem lokalen physischen Speicher eines Datenspeichersystems befinden, umfassend: Einrichten einer Spiegelung zwischen einer lokalen LUN und einer Cloud-gestützten LUN, die durch den physischen Cloud-Speicher eines separaten Cloud-Speichersystems gesichert wird, wobei die Spiegelung den Dateninhalt der Cloud-gestützten LUN mit dem Dateninhalt der lokalen LUN identisch macht; wenn der Spiegel eingerichtet ist, dann (a) Ablegen eines Stubs auf der lokalen LUN, wobei der Stub anzeigt, dass die lokale LUN archiviert wurde und die Cloud-gestützte LUN als Ziel nachfolgender EAs an die lokale LUN identifiziert, und (b) Freigabe von lokalem physischen Speicher der lokalen LUN zur Zuweisung an andere lokale LUNs; und für nachfolgende EAs an die lokale LUN, basierend auf dem Vorhandensein des Stubs, das Erfüllen der EAs von der Cloud-gestützten LUN
Verfahren nach Anspruch 1, wobei das Cloud-Speichersystem das Speichern von durchsuchbaren Metadatenelementen unterstützt, die zum Zuordnen von Cloud-gestützten LUNs zu entsprechenden LUNs des Datenspeichersystems geeignet sind.
Verfahren nach Anspruch 2, wobei jedes durchsuchbare Metadatenelement für eine entsprechende Cloud-gestützte LUN einen LUN-Namen, eine LUN-Kennung, eine Versionsnummer und einen Zeitstempel enthält, wobei der LUN-Name ein Name der lokalen LUN ist, die der Cloud-gestützten LUN entspricht, die LUN-Kennung eine Kennung der lokalen LUN ist, die Versionsnummer eine Version der lokalen LUN angibt und der Zeitstempel das Datum und die Uhrzeit der Erstellung der Cloud-gestützten LUN anzeigt.
Verfahren nach Anspruch 1, wobei das Datenspeichersystem einen Blockanbieter enthält, der einem Hostcomputer den Zugriff auf die LUNs ermöglicht, und eine Cloud-Appliance, die den Zugriff auf das Cloud-Speichersystem ermöglicht, wobei die Cloud-Appliance einen Volume-to-Object-Umsetzer umfasst, der unter Verwendung entsprechender logischer Abbildungen auf entsprechenden Objektgruppen die Cloud-gestützte LUN bereitstellt.
Verfahren nach Anspruch 4, wobei die Cloud-Appliance ferner eine LUN-Wartungs- und Orchestrierungseinheit (LNMO) und eine oder mehrere Cloud-AnwendungsprogrammSchnittstellen (APIs) enthält, wobei die LNMO das Archivieren der lokalen LUN initiiert und steuert und die Cloud-APIs die Kommunikationen mit dem Cloud-Speichersystem verwalten.
Verfahren nach Anspruch 4, ferner umfassend das Aufrechterhalten von Verbindungen zwischen dem Blockanbieter und der Cloud-Appliance, einschließlich eines Datenübertragungskanals und eines Steuerkanals, wobei der Datenübertragungskanal ein Blockspeicherprotokoll verwendet und der Steuerkanal für allgemeinere Kommunikationen einschließlich des Austauschs von Out-of-Band-Anfragen und entsprechenden Antworten strukturiert ist.
Verfahren nach Anspruch 6, wobei der Datenübertragungskanal ein iSCSI-Kanal ist und der Steuerkanal eine REST-Schnittstelle (Representation State Transfer) verwendet.
Verfahren nach Anspruch 4, wobei der Blockanbieter und die Cloud-Appliance in jeweiligen virtuellen Maschinen eines einzelnen Servercomputers enthalten sind.
Verfahren nach Anspruch 1, wobei das Identifizieren der Dateninhaltsunterschiede das Verwenden einer Snapdifferenzoperation umfasst, bei der Dateninhalte des lokalen Baseline-Snapshots mit dem nachfolgenden lokalen Snapshot verglichen werden, um eine Differenzkarte zu erzeugen, wobei die Differenzkarte (1) alle Datenblöcke der nachfolgenden lokalen Snapshots identifiziert, die Ergänzungen oder Änderungen gegenüber den Inhalten des Baseline-Snapshots darstellen, und (2) alle Datenblöcke identifiziert, die Freigaben oder Löschungen aus dem lokalen Baseline-Snapshot repräsentieren.
Verfahren nach Anspruch 1, ferner umfassend Schritte eines Wiederherstellungsprozesses, durch den eine lokale Produktions-LUN von einer entsprechenden Cloud-gestützten LUN wiederhergestellt wird, wobei die Schritte umfassen: Initiieren einer Kopie der Cloud-gestützten LUN in die lokale LUN; Verarbeiten von EAs während des Kopierens, einschließlich (1) lokalem Zwischenspeichern von Writes und selektivem Umspeichern von Schreibdaten auf die Cloud-gestützte LUN in Abhängigkeit von einer Offset-Adresse der Schreibdaten relativ zur Nutzung eines Kopiercursors im Kopierprozess, und (2) Anbieten von Reads entweder aus der lokalen LUN oder der Cloud-gestützten LUN auf Basis einer Offset-Adresse relativ zum Rückkopiercursor und dazu, ob die Lesedaten lokal zwischengespeichert wurden; und wenn die Kopie fertig ist, Entfernen des Stubs aus der lokalen LUN und Löschen der Cloud-gestützten LUN, wodurch die lokale LUN lokal gesichert und bereit für die Nutzung mit voller Leistung wird.
Datenspeichersystem mit lokalem physischem Speicher, einem Computer-gestützten Blockanbieter und einer Computer-gestützten Cloud-Appliance, wobei der Blockanbieter lokale logische Datenspeichereinheiten (LUNs) im lokalen physischen Speicher speichert, wobei der Blockanbieter und die Cloud-Appliance dazu konfiguriert und kooperativ ausgelegt sind, um die lokalen LUNs im Cloud-Speicher zu archivieren durch: Einrichten einer Spiegelung zwischen einer lokalen LUN und einer Cloud-gestützten LUN, die durch den physischen Cloud-Speicher eines separaten Cloud-Speichersystems gesichert wird, wobei die Spiegelung den Dateninhalt der Cloud-gestützten LUN mit dem Dateninhalt der lokalen LUN identisch macht; wenn die Spiegelung eingerichtet ist, dann (a) Ablegen eines Stubs auf der lokalen LUN, wobei der Stub anzeigt, dass die lokale LUN archiviert wurde und die Cloud-gestützte LUN als Ziel nachfolgender EAs an die lokale LUN identifiziert, und (b) Freigabe von dem lokalen physischen Speicher der lokalen LUN zur Zuweisung an andere lokale LUNs; und für nachfolgende EAs an die lokale LUN, basierend auf dem Vorhandensein des Stubs, das Erfüllen der EAs von der Cloud-gestützten LUN
Datenspeichersystem nach Anspruch 11, wobei das Cloud-Speichersystem das Speichern von durchsuchbaren Metadatenelementen unterstützt, die zum Zuordnen Cloud-gestützter LUNs zu entsprechenden LUNs des Datenspeichersystems verwendbar sind.
Datenspeichersystem nach Anspruch 12, wobei jedes durchsuchbare Metadatenelement für eine entsprechende Cloud-gestützte LUN einen LUN-Namen, eine LUN-Kennung, eine Versionsnummer und einen Zeitstempel enthält, wobei der LUN-Name ein Name der lokalen LUN ist, die der Cloud-gestützten LUN entspricht, die LUN-Kennung eine Kennung der lokalen LUN ist, die Versionsnummer eine Version der lokalen LUN angibt und der Zeitstempel ein Datum und eine Uhrzeit der Erstellung der Cloud-gestützten LUN anzeigt.
Datenspeichersystem nach Anspruch 11, wobei die Cloud-Appliance einen Volume-to-Object-Umsetzer umfasst, der die Cloud-gestützte LUN unter Verwendung entsprechender logischer Abbildungen auf entsprechenden Objektgruppen bereitstellt.
Datenspeichersystem nach Anspruch 14, wobei die Cloud-Appliance ferner eine LUN-Wartungs- und Orchestrierungseinheit (LNMO) und eine oder mehrere Cloud-Anwendungsprogrammschnittstellen (APIs) enthält, wobei die LNMO die Archivierung der lokalen LUN initiiert und steuert und die Cloud-APIs die Kommunikationen mit dem Cloud-Speichersystem verwalten.
Datenspeichersystem nach Anspruch 11, ferner umfassend Verbindungen zwischen dem Blockanbieter und der Cloud-Appliance, einschließlich eines Datenübertragungskanals und eines Steuerkanals, wobei der Datenübertragungskanal ein Blockspeicherprotokoll verwendet und wobei der Steuerkanal für allgemeinere Kommunikationen strukturiert ist, einschließlich des Austauschs von Out-of-Band-Anfragen und entsprechender Antworten.
Datenspeichersystem nach Anspruch 16, wobei der Datenübertragungskanal ein iSCSI-Kanal ist und der Steuerkanal eine REST-Schnittstelle (Representation State Transfer) verwendet.
Datenspeichersystem nach Anspruch 14, wobei der Blockanbieter und die Cloud-Appliance in entsprechenden virtuellen Maschinen eines einzelnen Servercomputers enthalten sind.
Datenspeichersystem nach Anspruch 11, wobei das Identifizieren der Dateninhaltsdifferenzen das Verwenden einer Snap-Differenzoperation beinhaltet, bei der der Dateninhalt des lokalen Baseline-Snapshots mit dem nachfolgenden lokalen Snapshot verglichen wird, um eine Differenzkarte zu erzeugen, wobei die Differenzkarte (1) alle Datenblöcke des nachfolgenden lokalen Snapshots identifiziert, die Ergänzungen oder Modifikationen gegenüber dem Inhalt des Baseline-Snapshots darstellen, und (2) alle Datenblöcke identifiziert, die Freigaben oder Löschungen aus dem lokalen Baseline-Snapshot darstellen.
Datenspeichersystem nach Anspruch 11, wobei der Blockanbieter und die Cloud-Appliance ferner dazu konfiguriert und kooperativ ausgelegt sind, um Schritte eines Wiederherstellungsprozesses auszuführen, durch die eine lokale Produktions-LUN von einer entsprechenden Cloud-gestützten LUN wiederhergestellt wird, wobei die Schritte umfassen: Initiieren einer Kopie der Cloud-gestützten LUN in die lokale LUN; Verarbeiten von EAs während des Kopierens, einschließlich (1) lokalem Zwischenspeichern von Writes und selektivem Umspeichern von Schreibdaten auf die Cloud-gestützte LUN in Abhängigkeit von einer Offset-Adresse der Schreibdaten relativ zur Nutzung eines Kopiercursors im Kopierprozess, und (2) Anbieten von Reads entweder aus der lokalen LUN oder der Cloud-gestützten LUN auf Basis einer Offset-Adresse relativ zum Rückkopiercursor und ob die Lesedaten lokal zwischengespeichert wurden; und wenn die Kopie fertig ist, Entfernen des Stubs aus der lokalen LUN und Löschen der Cloud-gestützten LUN, wodurch die lokale LUN lokal gesichert und bereit für die Nutzung mit voller Leistung wird.