PowerMax 2500 e 8500: Snapshots não gerenciados

Snapshots não gerenciados no PowerMax 2500 e 8500
Replicação local (LREP)

O SnapVX foi reformulado na V4. O V4 tem como padrão a cópia em uma leitura e a cópia em uma gravação quando interceptada. V3 e anteriores não copiavam como padrão na leitura.

Snapshots não gerenciados: 

• Assim como um VMAX3, um PowerMax 2500 ou 8500 mantém os dados de destino mesmo depois de serem desvinculados dos dispositivos de origem.
• Snapshots não gerenciados são imagens mantidas internamente pelo PowerMax para manter dependências entre uma origem e um destino depois de serem desvinculadas.
• Há diferenças fundamentais entre a forma como o LREP/VP é implementado no PowerMax 2500 ou 8500 em comparação com os arrays VMAX All Flash/VMAX3/Powermax mais antigos.
• No PowerMax 2500 ou 8500, os dispositivos de destino não passam pelo processo de definição
• O processo de definição do VMAX3 consumiria metadados de ID de rastreamento (TID) completos para um dispositivo de destino, tornando o provisionamento excessivo caro
• Com o PowerMax 2500 ou 8500, decidiu-se acabar com o compartilhamento no nível do rastreamento e usar agora um esquema de compartilhamento no nível do dispositivo (mantendo os dispositivos de destino indefinidos)
  • Isso também melhorou o desempenho em destinos indefinidos
• Portanto, no PowerMax 2500 ou 8500, os destinos só obtêm alocações quando são gravados (não como parte do processo de definição)
  • Eles derivam seus dados da imagem point-in-time, à qual foram vinculados anteriormente.
  • Essa relação permanece depois que eles são desvinculados
  • Mesmo no VMAX3, a integridade dos dados era mantida em um dispositivo de destino depois de desvincular (isso era feito no nível da trilha)
• Se estiver levando uma E/S para um dispositivo de destino não gerenciado, como toda E/S, o código verifica se ela deve interceptar
  • Isso é feito no início do fluxo de E/S
  • E/S de leitura para trilhas de destino que ainda não foram copiadas, gerar SNAPVX_COPY_ON_READ_INTERCEPT se lhe foi pedido.
    • Para E/S de MF, há alguns casos que geram COPY ON READ INTERCEPTS
      • Solicitado a fazer COPY_INDIRECT_ON_READ
      • É um comando especial MF 0x96, op 0x46 que força uma cópia na leitura
      • É um dispositivo SRDF R2 SRDF/A e todas as leituras estão definidas COPY ON READ (Exemplo: As verificações de RDC fazem isso porque uma solicitação é enviada à máquina de E/S para ler os dados do local remoto a serem comparados. Isso causa uma interceptação de leitura, forçando a cópia dos dados)

Exemplo geral com destinos não gerenciados:

• A sequência A -> s1 -> B representa um dispositivo de destino (B) vinculado a um snapshot (s1) do dispositivo de origem (A)
• Essa relação permanece mesmo depois de desvincular o destino (B) e encerrar o snapshot (s1)
• À medida que as gravações ocorrem no dispositivo de origem (A), o RDP é enviado para o snapshot (s1) de modo que ele continue a acumular alocações
• Esses RDP podem ser compartilhados entre vários snapshots e usados por vários destinos (até mesmo snapshots que ainda estão ativos com destinos vinculados)
• Os dados gravados no destino (B) são as únicas alocações exibidas no destino (B)
• A execução de "free-all" no destino (B) remove a relação interna e a dependência no snapshot encerrado (s1)
• Da mesma forma, vincular o destino a um snapshot diferente remove a relação interna e a dependência no snapshot encerrado (s1)