PowerMax 2500 en 8500: Onbeheerde snapshots

Onbeheerde snapshots in PowerMax 2500 en 8500
Local Replication (LREP)

SnapVX is opnieuw ontworpen in V4. V4 kopieert standaard bij een leesbewerking en kopieert bij een schrijfbewerking wanneer deze wordt onderschept. V3 en eerder waren niet standaard ingesteld op kopiëren bij lezen.

Onbeheerde snapshots: 

• Net als een VMAX3 handhaaft een PowerMax 2500 of 8500 doeldata, zelfs nadat deze zijn ontkoppeld van de bronapparaten.
• Onbeheerde snapshots zijn images die intern door de PowerMax worden bewaard om de afhankelijkheden tussen een bron en een doel te behouden nadat ze zijn ontkoppeld.
• Er zijn fundamentele verschillen tussen de manier waarop LREP/VP is geïmplementeerd in PowerMax 2500 of 8500 in vergelijking met de oudere VMAX All Flash/VMAX3/Powermax arrays.
• In PowerMax 2500 of 8500 doorlopen doelapparaten niet het definitieproces
• Het VMAX3-definitieproces verbruikt volledige Track ID (TID)-metadata voor een doelapparaat, waardoor overprovisioning duur wordt
• Met de PowerMax 2500 of 8500 is besloten om het delen op trackniveau af te schaffen en nu een schema voor delen op apparaatniveau te gebruiken (terwijl ook doelapparaten ongedefinieerd blijven)
  • Dit verbeterde ook de prestaties op niet-gedefinieerde doelen
• In PowerMax 2500 of 8500 krijgen doelen dus alleen toewijzingen wanneer ze worden geschreven (niet als onderdeel van het definitieproces)
  • Ze ontlenen hun data aan het point-in-time beeld, waar ze eerder aan gekoppeld waren.
  • Deze relatie blijft bestaan nadat ze zijn losgekoppeld
  • Zelfs in VMAX3 werd de data-integriteit op een doelapparaat gehandhaafd nadat dit was ontkoppeld (dit gebeurde op trackniveau)
• Als u een IO naar een onbeheerd doelapparaat krijgt, zoals elke IO, controleert de code of deze moet worden onderschept
  • Dit gebeurt vroeg in de IO-stroom
  • Lees IO's om tracks te targeten die nog niet zijn gekopieerd, genereer SNAPVX_COPY_ON_READ_INTERCEPT als daarom werd gevraagd.
    • Voor MF IO's zijn er enkele gevallen die leiden tot COPY ON READ INTERCEPTS
      • Gevraagd om te doen COPY_INDIRECT_ON_READ
      • Het is een speciale MF 0x96, op 0x46 commando dat een kopie afdwingt bij het lezen
      • Het is een SRDF R2 SRDF/A-apparaat en alle leesbewerkingen zijn ingesteld COPY ON READ (Voorbeeld: RDC-scans doen dit omdat er een verzoek naar de io-machine wordt gestuurd om de gegevens van de externe site te lezen om te vergelijken. Dit veroorzaakt een onderschepping van leesbewerkingen, waardoor het kopiëren van data wordt geforceerd)

Algemeen voorbeeld met onbeheerde doelen:

• De sequentie A -> s1 -> B vertegenwoordigt een doelapparaat (B) dat is gekoppeld aan een momentopname (s1) van het bronapparaat (A)
• Deze relatie blijft ook bestaan na het ontkoppelen van het doel (B) en het beëindigen van de snapshot (s1)
• Wanneer er schrijfbewerkingen plaatsvinden naar het bronapparaat (A), wordt RDP zodanig naar de snapshot (s1) gepusht dat het toewijzingen blijft accumuleren
• Deze RDP's kunnen worden gedeeld over meerdere snapshots en worden gebruikt door meerdere doelen (zelfs snapshots die nog actief zijn met gekoppelde doelen)
• Data die naar het doel (B) worden geschreven, zijn de enige toewijzingen die worden weergegeven op het doel (B)
• Door "free-all" uit te voeren op het doel (B), worden de interne relatie en afhankelijkheid van de beëindigde snapshot (s1) verwijderd
• Op dezelfde manier verwijdert het koppelen van het doel aan een andere snapshot de interne relatie en afhankelijkheid van de beëindigde snapshot (s1)