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!!!

Symmetrix VMAX - Part. 6 - Passos para implementação VP

Boa noite pessoal.

 Dando continuidade agora no módulo de VMAX, vou falar um pouco dos steps para implementação do virtual provisioning.





 São eles:


- Criar o Thin Pool;

- Add data devices no thin pool;
- Bind do Tdev no thin pool;

Segue aqui os passos:


symconfigure -sid XYX -cmd “create dev count=8, size=1150,config=TDEV,emulation=FBA;” commit


symconfigure -sid XYZ -cmd “create pool POOL1 type=thin;”commit

symconfigure -sid XYZ -cmd “add dev 187:188 to pool POOL1 type=thin, member_state=ENABLE;” commit


symcfg list -pool -thin -sid XYZ

Feito isso você pode fazer os passos de criação dos initiators group, storage group, port group para o qual os devices Tdevs devem fazer Map e criar o masking view.


 Recomendo que seja criado um port group, e não um port group para cada masking view. Por que?

 Simplesmente para facilitar sua administração. Tendo um único port group fica mais fácil para coletar informações, executar comandos de consulta, pois se você tiver as mesmas portas mapeadas em 10 port groups fica bem pior.

Essa parte do virtual provisioning é bem simples, porém requer essas pequenas atenções quanto a distribuição dos recursos e entendimento de cada ponto para não comprometer sua própria administração.


Abraços e boa noite.

domingo, 5 de abril de 2015

FreeNAS - Instalação básica (Utilizando VirtualBox)



Boa noite pessoal.

 Falando ainda de armazenamento, cada vez mais temos a necessidade de utilizarmos recursos para salvarmos nossas fotos, nossas músicas, enfim qualquer outro dado que seja importante para nós e que queremos salva-lo em algum lugar que não nosso PC ou nosso Notebook.
 Com as constantes disponibilidades de recursos Web como Dropbox, GoogleDrive, dentre outros, na maioria das vezes acabamos salvando nossas coisas nesses lugares, no entanto, temos espaço pequeno, ou temos que pagar se quisermos mais espaço e isso muitas vezes fica inviável.

 Hoje vou mostrar uma solução para termos nosso próprio local externo de armazenamento, podendo utilizar um micro mais antigo, ou mesmo fazer um investimento e montar um micro para tal finalidade e salvar nossos recursos através da nossa rede Wifi ou cabeada.

 Estou falando do FreeNAS.

 O FreeNAS é baseado do Unix BSD, customizado para trabalhar como um file server através de uma interface para administrar seus recursos e objetos.
 Nele podemos criar RAID (por software também), customizar paths para armazenar dados específicos, como Music para músicas, backup para backup do computador ou notebook, etc.

Abaixo está um vídeo que fiz de como fazer uma instalação básica do FreeNAS.
 No exemplo utilizei o virtualbox para demonstrar a instalação. Posteriormente irei colocar mais alguns tópicos de mais algumas coisas que podemos ir configurando no FreeNAS.

 Vamos ao vídeo:



 Eu tive que alterar as configurações de rede, pois como Nat ele ficou em uma rede isolada da rede ao qual estava conectado. Colocando ela para Bridge eu consigo criar uma interface no mesmo range de ip que minha máquina física e assim poder acessar por fora da console da VM, principalmente pela interface de administração web.

Abraços galera e boa noite.

sábado, 4 de abril de 2015

Symmetrix VMAX - Part. 5 - Provisionamento virtual

Boa noite pessoal, tudo bem?

 Agora vou falar um pouco sobre virtual provisioning...

 Isso nada mais é do que criar objetos lógicos sobre uma estrutura física, podendo inclusive fazermos entrega de espaço sem termos o espaço físico real. Estamos falando neste caso de over-subscription.

 Vejamos como um host acesso um volume entregue para ele, porém virtual provisioning do lado do storage VMAX.

 Vamos a figura abaixo:



 O que estamos vendo aqui é uma representação macro, do uso de devices com thin. O host A possui um disco de 200GB o mesmo temos para o host B, um disco de 200GB. Em um modelo tradicional como chamamos o modelo antigo, ou thick, ao criarmos dois discos de 200GB no storage estaríamos alocando um total de 400GB. O storage iria reservar este espaço com 0 e 1, para garantir que este espaço seja reservado para o device criado. Bem, seguindo o exemplo, entregando um disco de 200GB para um host dificilmente ele irá consumir inicialmente os 200GB, isso será consumido gradativamente, o que do ponto de vista de storage é um problema e uma perda de espaço, pois as vezes podemos não consumir estes 200GB em anos.
 Para suprir essa falta de conservadorismo de quem solicita espaço em disco e falta de poder dos administradores de storage em questionar e negar ( rsrsrsr ), criou-se o conceito de thin device.
 Cada disco apresentado no momento estão consumindo 10GB e 100GB que é o que realmente o host gravou até o momento, e consumindo no lado do storage apenas 110GB.

 No VMAX chamamos estes Devices de TDEV (Thin Devices).

Esse recurso de thin provisioning nos permite realmente fazer uso mais eficiente do storage no nível de que podemos entregar a volumetria que o usuário final solicitou, no entanto, se começarmos a entregar Tdevs a vontade e não fazermos controle e monitoração disso podemos ter problemas.

Quando entregamos mais recursos do que temos disponível, chamamos isso de over subscription. Isso não é inicialmente um problema, mas vamos imaginar que nosso espaço físico seja de 20TB. Com o passar das implantações, crescimento do ambientes criados nos novos setups, e vemos que um somatório de todos os volumes criados seja de 25TB. Se todos os hosts consumirem o restante do espaço que lhes estão como disponíveis na visão do host chegar no 20TB, os demais que ainda aparecem com espaço livre não conseguiram escrever.

Uma vantagem de trabalharmos com POOL é que estes podem ser aumentados dinamicamente e on-line. O único impacto que temos é que durante o período de resize do pool o equipamento ficará com um lock, não sendo possível criarmos devices, novos grupos de objetos, iremos conseguir no máximo fazer funções de view de configurações.

Vamos fazer agora um levantamento dos componentes necessários para virtual provisioning:

- Data device;
- Thin device;
- Thin pool;

Basicamente, os Tdevs existem em cache e isso faz com que o acesso as informações seja muito mais rápido e eficaz e vale lembrar que toda essa memória cache é espelha no VMAX, então temos segurança e integridade dos dados.

É necessário apenas uma locação inicial do device criado que é de 12 trilhas, mais ou mesmo 768KB quando feito bound no Pool.
Isso mesmo, ao criarmos um Tdev, ele existe, porém se ele não for atribuído a nenhum Pool ele fica com o status de not ready. Se apresentarmos ele dessa forma para o host não será possível escrever no disco.

Então quando criamos um Tdev ele não possui nenhuma informação de RAID para proteção. Essa proteção passa a vir do Pool em que o Tdev será adicionada, passando assim a ter permissão de ready, que para o host significa poder escrever.

A estrutura ficaria da seguinte forma:


Podemos ver que toda área laranja representa um POOL, um pool é formado por data devices, os discos físicos por assim dizer e em cima do Thin Pool é que criamos os Thin Devices.

Os data devices, não podem ser utilizados neste ponto para serem usados como recursos de disco e apresentados para os hosts, muito menos para fazermos replicação de dados.

Quando adicionamos um Thin Device à um POOL, um extent é alocado para cada Thin Device.
Um extent equivale a:

12x64 KB tracks = 768 KB 
1536x512 bytes blocks

O mecanismo de balanceamento do Symmetrix faz com que a gravação destes extents seja cuidadosamente alocada. 
Caso um TDev tenha 4 meta member, teremos a alocação de 4 extents.

De certa forma, os POOLs também possuem atributos de configuração, são separados por tecnologias de disco, velocidade, para que possamos escrever em TDevs, estes devem fazer parte, ou melhor dizendo, fazer Bind em um POOL. Os devices podem ser migrados de POOLs, os POOLs podem ser expandidos.

Vou mostrar agora alguns comandos de como criar TDevs e POOLs:

Criando TDEVs:
symconfigure -sid IDSYM -cmd “create dev count=8, size=1150,config=TDEV,emulation=FBA;” commit

Criando 8 devices, com 1150 cylinders (podemos informar em MB ou GB também), o tipo de Device e emulação.

Criando Thin POOL:
symconfigure -sid IDSYM -cmd “create pool POOL1 type=thin;”commit

Adicionando data devices ao POOL:
symconfigure -sid IDSYM -cmd “add dev 187:188 to pool POOL1 type=thin, member_state=ENABLE;” commit

Estamos adicionando dois devices ao pool que criamos, informando que é do tipo thin e o status destes membros dentro do POOL serão como ENABLE.

Listando um thin pool:
symcfg list -pool -thin -sid IDSYM

Informação de um POOL especifico:
symcfg show -pool POOL1 -thin -sid IDSYM


Adicionando thin devices ao POOL:
symconfigure -sid IDSYM -cmd "bind tdev 0F1:0F4 to pool POOL1;" commit 

Criando um thin meta device:
symconfigure -sid IDSYM -cmd "form meta from dev 199, config=strapped; add dev 19A to meta 199;" commit

Espero que eu tenha conseguido explicar de forma clara um pouco sobre essa parte de virtual provisioning.
Caso fique alguma dúvida é só deixar um comentário que o mais rápido possível eu tento responder.

Abraços pessoal e boa noite.