PowerMax 2500 und 8500: Nicht verwaltete Snapshots

Nicht gemanagte Snapshots in PowerMax 2500 und 8500
Lokale Replikation (LREP)

SnapVX wurde in V4 neu gestaltet. V4 kopiert standardmäßig bei einem Lesevorgang und kopiert bei einem Schreibvorgang, wenn er abgefangen wird. Bei V3 und früheren Versionen wurde die Standardeinstellung nicht auf "Kopieren beim Lesen" festgelegt.

Nicht verwaltete Snapshots: 

• Wie ein VMAX3 behält auch ein PowerMax 2500 oder 8500 die Zieldaten bei, selbst nachdem die Verknüpfung mit den Quellgeräten aufgehoben wurde.
• Nicht gemanagte Snapshots sind Images, die intern von PowerMax aufbewahrt werden, um Abhängigkeiten zwischen einer Quelle und einem Ziel aufrechtzuerhalten, nachdem die Verknüpfung aufgehoben wurde.
• Es gibt grundlegende Unterschiede zwischen der Art und Weise, wie LREP/VP in PowerMax 2500 oder 8500 im Vergleich zu den älteren VMAX All Flash/VMAX3/Powermax-Arrays implementiert wird.
• Bei PowerMax 2500 oder 8500 durchlaufen Zielgeräte nicht den Definitionsprozess
• Der VMAX3-Definitionsprozess würde die vollständigen Track-ID-Metadaten (TID) für ein Zielgerät verbrauchen, was ein Overprovisioning teuer machen würde
• Bei PowerMax 2500 oder 8500 wurde beschlossen, die gemeinsame Nutzung auf Track-Ebene abzuschaffen und ein Freigabeschema auf Geräteebene zu verwenden (wobei Zielgeräte gleichzeitig nicht definiert sind)
  • Dadurch wurde auch die Performance bei undefinierten Zielen verbessert
• In PowerMax 2500 oder 8500 erhalten Ziele also nur dann Zuweisungen, wenn sie in sie geschrieben werden (nicht als Teil des Definitionsprozesses)
  • Sie leiten ihre Daten aus dem Point-in-Time-Image ab, mit dem sie zuvor verknüpft waren.
  • Diese Beziehung bleibt bestehen, nachdem die Verknüpfung aufgehoben wurde
  • Selbst in VMAX3 wurde die Datenintegrität auf einem Zielgerät aufrechterhalten, nachdem die Verknüpfung aufgehoben wurde (dies geschah auf Track-Ebene)
• Wenn eine IO an ein nicht verwaltetes Zielgerät übertragen wird, prüft der Code wie jede I/O, ob sie abgefangen werden muss.
  • Dies erfolgt früh im I/O-Fluss
  • Lese-IOs für Zielspuren, die noch nicht kopiert wurden, generieren SNAPVX_COPY_ON_READ_INTERCEPT wenn sie dazu aufgefordert wurde.
    • Bei MF-IOs gibt es einige Fälle, in denen COPY ON READ INTERCEPTS
      • Darum gebeten COPY_INDIRECT_ON_READ
      • Es handelt sich um einen speziellen MF-0x96, op-0x46-Befehl, der eine Kopie beim Lesen erzwingt.
      • Es handelt sich um ein SRDF R2 SRDF/A-Gerät, und alle Lesevorgänge sind festgelegt COPY ON READ (Beispiel: RDC-Scans tun dies, da eine Anforderung an die I/O-Maschine gesendet wird, die Daten vom Remotestandort zu lesen und zu vergleichen. Dies führt zu einem Leseabfang, der das Kopieren von Daten erzwingt.)

Allgemeines Beispiel mit nicht gemanagten Zielen:

• Die Sequenz A -> s1 -> B stellt ein Zielgerät (B) dar, das mit einem Snapshot (s1) des Quellgeräts (A) verknüpft ist
• Diese Beziehung bleibt auch nach dem Aufheben der Verknüpfung des Ziels (B) und dem Beenden des Snapshots (S1) bestehen
• Wenn Schreibvorgänge auf das Quellgerät (A) erfolgen, wird RDP auf den Snapshot (s1) übertragen, sodass weiterhin Zuweisungen angesammelt werden
• Diese RDP können von mehreren Snapshots gemeinsam genutzt und von mehreren Zielen verwendet werden (auch von Snapshots, die noch mit verknüpften Zielen aktiv sind)
• Daten, die auf das Ziel (B) geschrieben werden, sind die einzigen Zuweisungen, die auf dem Ziel (B) angezeigt werden
• Das Ausführen von "free-all" auf dem Ziel (B) entfernt die interne Beziehung und Abhängigkeit vom beendeten Snapshot (S1)
• Auf ähnliche Weise entfernt die Verknüpfung des Ziels mit einem anderen Snapshot die interne Beziehung und Abhängigkeit vom beendeten Snapshot (S1)