PowerMax 2500 et 8500 : Snapshots non gérés

Snapshots non gérés dans PowerMax 2500 et 8500
Réplication locale (LREP)

SnapVX a été restructuré dans la version 4. V4 est par défaut copie sur une lecture et copie sur une écriture en cas d’interception. Les versions 3 et antérieures n’étaient pas définies par défaut sur Copy on Read.

Snapshots non gérés : 

• Comme un VMAX3, un PowerMax 2500 ou 8500 conserve les données cibles même après leur dissociation des appareils sources.
• Les snapshots non gérés sont des images conservées en interne par PowerMax pour maintenir les dépendances entre une source et une cible après leur dissociation.
• Il existe des différences fondamentales entre la façon dont LREP/VP est implémenté dans PowerMax 2500 ou 8500 et les anciennes baies VMAX All Flash/VMAX3/PowerMax.
• Dans PowerMax 2500 ou 8500, les appareils cibles ne passent pas par le processus de définition
• Le processus de définition VMAX3 consomme l’intégralité des métadonnées de l’ID de piste (TID) pour un appareil cible, ce qui rend le surprovisionnement coûteux
• Avec PowerMax 2500 ou 8500, il a été décidé de supprimer le partage au niveau des pistes et d’utiliser un schéma de partage au niveau des appareils (tout en gardant les appareils cibles non définis)
  • Cela a également permis d’améliorer les performances sur des cibles non définies
• Ainsi, dans PowerMax 2500 ou 8500, les cibles obtiennent uniquement des allocations lorsqu’elles sont écrites dans (et non dans le cadre du processus de définition)
  • Ils tirent leurs données de l’image à un point dans le temps, à laquelle ils étaient précédemment liés.
  • Cette relation perdure une fois qu’ils ont été dissociés
  • Même dans VMAX3, l’intégrité des données a été maintenue sur un appareil cible après sa dissociation (au niveau de la piste)
• Si une E/S est envoyée à un appareil cible non géré, comme toutes les E/S, le code vérifie s’il doit intercepter
  • Cette opération s’effectue tôt dans le flux d’E/S
  • Lire les E/S vers les pistes cibles qui n’ont pas encore été copiées, générer SNAPVX_COPY_ON_READ_INTERCEPT si on lui a demandé de le faire.
    • Pour les E/S MF, il existe quelques cas qui génèrent COPY ON READ INTERCEPTS
      • Tâche demandée COPY_INDIRECT_ON_READ
      • Il s’agit d’une commande spéciale MF 0x96, op 0x46 qui force une copie en lecture
      • Il s’agit d’un appareil SRDF R2 SRDF/A, et toutes les lectures sont définies COPY ON READ (Exemple : Les analyses RDC le font, car une demande est envoyée à la machine d’E/S pour lire les données du site distant à comparer. Cela provoque une interception de lecture, forçant la copie des données)

Exemple général avec des cibles non gérées :

• La séquence A -> s1 -> B représente un appareil cible (B) lié à un snapshot (s1) de l’appareil source (A)
• Cette relation perdure même après la dissociation de la cible (B) et la suspension du snapshot (s1)
• Au fur et à mesure que les écritures se produisent sur l’appareil source (A), RDP est transmis au snapshot (S1) de sorte qu’il continue à accumuler des allocations
• Ces RDP peuvent être partagés entre plusieurs snapshots et utilisés par plusieurs cibles (même les snapshots qui sont toujours actifs avec les cibles liées)
• Les données écrites sur la cible (B) sont les seules allocations qui s’affichent sur la cible (B)
• L’exécution de « free-all » sur la cible (B) supprime la relation interne et la dépendance vis-à-vis du snapshot suspendu (s1)
• De même, la liaison de la cible à un autre snapshot supprime la relation interne et la dépendance vis-à-vis du snapshot suspendu (s1)