sábado, 18 de abril de 2015

Symmetrix VMAX - Part. 7 - Migração Virtual LUN

Boa noite pessoal!

 Na parte 7 iremos falar de migração de Lun virtual no VMAX.

 Mas o que a migração de um virtual lun pode fazer ou proporcionar?

  • Mover dados de aplicações em um mesmo storage array sem que os dados sejam corrompidos;
  • Podemos alterar o tipo de tecnologia de disco, de SATA para EFD por exemplo;
  • Isso tudo sem afetar a replicação remota ou local dos dados;
  • Suporte para thick e thin devices;


Mais por que eu habilitaria isso?

  • Para habilitar virtualização de storage;
  • Para fazer migrações sem que os dados sejam corrompidos e sem downtime;
  • Para gerenciamento do ciclo de vida da informação;
  • Otimizar a performance do seu ambiente e do seu storage;


Tecnologias de Virtual LUN

DP - Disk group provisioning

  • Move de forma que os dados não sejam corrompidos;
  • Move os dados para um lado que não esteja configurado, ou seja, necessita de um espaço livro para o lado target;
  • Move o espaço usado para um device que não esteja usado;


VP - Virtual provisioning

  • Move as alocações de thin devices para outros pools;
  • A migração de um virtual device faz BIND no pool target à menos que seja especificado um pool no source;


Device pool level migrations

  • Se um source pool foi informado, as trilhas alocadas neste source pool, são migrados para um pool target se que o processo de bind seja afetado;


Arquitetura de RAID Virtual

Neste ponto temos a abstração do conceito de RAID tradicional. O RAID virtual faz a manipulação de um device usado, espelhando a posição de determinada informação.
Com este cenário temos o que chamados de FAST, que nada mais é do que Fully Automated Storage Tiering.
Tipos de RAID suportados são RAID-1, RAID-5, RAID-6.

Durante o processo de migração, será necessário o uso de dois RAID Groups, podendo estes terem tipos de disco diferentes.

Para iniciarmos uma migração, devemos utilizar o comando symmigrate:

symmigrate -name migrate1 -f devs_migration.txt establish

Segue mais opções que podemos usar com o symmigrate:


Com a implementação do processo de migração temos ganhos principalmente na facilidade de criação e movimentação de RAID Groups, um target pode ser adicionado como um mirror secundário, ou até mesmo fazer a vez de um primary mirro. 
Quando o processo de migração termina, o source RAID group pode até ser deletado.

A tabela abaixo mostra o que precisamos como parâmetro para a migração:


A migração para um espaço configurado, faz com que exista uma troca de posições entre os dados que estão no source e o target.

Sempre que um processo de symmigrate é iniciado, devemos ao término encerrar a sessão para finaliza-la por completo:

symmigrate terminate -sid XYZ -name migration1 -nop

A migração para um espaço não configurado é mais simples, pois não se faz necessário essa transição de dados que estão no target para o RAID group onde estão os dados source. Neste caso temos uma migração unidirecional.

Para um Thin Device esse processo é ainda bem mais simples, pois ele já nasce de certa forma como um objeto dentro de uma estrutura que trabalhar melhor as questões de armazenamento, otimização de espaço, então de certo modo esse objeto "transita"mais facilmente.

Parametros da migração Thin:


O mais legal disso tudo é que podemos fazer migração de dados a todo momento sem que exista perda de dados, sem downtime dos ambientes/aplicações, podemos fazer uso de vários tiers do storage, temos o suporte para várias ferramentas de migração de dados, sem que isso seja impactante neste processo para determinada ferramenta, facilidade da movimentação dos dados e por que não falar que dessa forma teremos uma otimização do storage como um todo e para todos.

Mas como nem tudo são flores, existem recomendações para este processo também:

- Se temos trilhas compactadas no source, o pool target também deve aceitar compressão;
- Trilhas descompactadas podem ser migradas descompactadas independentemente do pool target estar com compressão habilitada;

Até que nesse tópico são mais simples as observações que devemos fazer.

Esse trabalho de tierização é muito importante para que possamos atender recursos de performance, pois podemos ter dados que hoje necessitam de muito acesso e estarem em pontos do storage que oferecem recursos limitados de performance, devido a sua tecnologia, o que não é algo errado. Mas se existe dados não muito utilizados em pontos do storage que podem oferecer uma performance bem melhor, por que não fazer essa troca ou mesmo fazer com que esses dados possam residir ao mesmo tempo no mesmo ponto?
O VMAX trabalho isso de forma transparente para as aplicações e em todo tempo, o que mostra mais uma vez o quanto este storage é confiável para o dia-a-dia e o quanto pode oferecer em relação a performance e otimização de recurso.

Abraços e até a próxima!!!

Nenhum comentário:

Postar um comentário