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.
