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.

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:

Canal Youtube

 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.

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.

Certificação - Uma conquista com orgulho!!!

Pessoal, bom dia.

 O post de hoje será rápido... :)

 É com satisfação que compartilho uma conquista na minha carreira e principalmente na parte acadêmica.

 Consegui duas certificações, a VCE Associated e VMware Associated (Data center virtualization).

 

E agora é ver qual será a próxima meta!!!

Valeu galera.

Abs e boa semana.

Symmetrix VMAX - Part. 4 - Grupos para provisionamento de recursos

Boa noite galera.

 Hoje vamos para parte 4. Vamos falar sobre grupos de provisionamento (autoprovisioning groups).
 Estamos falando nada mais do que criarmos grupos para initiators (wwns dos hosts), para portas de front-end, para devices e tudo isso sendo agrupado pelo masking view.

 Isso é útil na questão de provisionamento, crescimento, administração, identificação, parametrização, enfim, é o que determina um cenário limpo de trabalho e mais preciso, limitando assim questões que as vezes podem levar o administrador ao erro.

 Esse grupos devem receber nomes "amigáveis" e que sirvam para identificar o propósito de existirem. Falo isso pois, podemos criar um nome para o grupo de initiators como servidor_de_banco e isso também para o storage group, ou masking. Embora nós sabemos de qual servidor é, na hora da administração teremos que ficar chegando o que temos atribuído a este nome e ver de qual objeto estamos falando.

 Particularmente, eu recomendo seguir da seguinte forma:

Initiators group:
 - IG_CLIENTE_SERVIDOR
 - IG_SERVIDOR

Storage group:
 - SG_CLIENTE_SERVIDOR(ES)
 - SG_SERVIDOR(ES)

Port group:
 - PG_AMBIENTE
 - PG_FAs

Masking view:
 - MV_CLIENTE_SERVIDOR
 - MV_SERVIDOR

Coloco como duas opções, uma contendo o nome do cliente e outra apenas do servidor pois podemos ter dois cenários, onde o uso do storage será compartilhado para mais de um cliente ou apenas para a organização.
 Claro que isso foi apenas uma recomendação pois assim, logo de cara já sabemos que se começa com IG é de initiator group, SG storage group e assim por diante.

O Desenho abaixo ilustra cada objeto e sua localização na solução:

Os nomes que podemos dar para cada objeto são case sensitive e tem um limite de 64 caracteres.

Mais algumas vantagens:

 - Initiators podem ser adicionados e removidos dinamicamente nos initiators group;

 - Porta de FA podem ser adicionadas também dinamicamente aos port groups ou removidas;

 - O mesmo vale para o storage group, onde Devices ou meta devices podem ser adicionados e/ou removidos;

 Para criarmos estes objetos devemos usar o comando syamccess.

 Uma tabela para consulta rápida:

- Symaccess controle:

- Symaccess visualização:

Storage groups:

 Contém devices, sendo que um mesmo device pode fazer parte de mais de um storage group (cuidado nesse ponto, pois caso seu ambiente não seja um cluster ou não esteja preparado para trabalho usando um mesmo disco e já sabendo que ele pode estar formatado e usado podemos ter problemas).

 Podemos ter um storage group pai e adicionar storage group filhos nele. Neste caso, ele herda os discos que estão apresentados para os filhos.

 Um storage group pai pode ter no máximo 32 storage group filhos.

 Por sua vez, um storage group filho só pode ter um storage group pai.

 O storage group pode conter devices ou outro storage group, mas não ambos.

 É o storage group que associamos à uma Fast policy, porém não podemos adicionar um storage group pai a uma fast, somente os filhos.

 Um masking view pode ser configurado para um storage group pai ou filho, porém não para ambos.

 E caso queira fazer limitação de I/O, deve ser feito no storage group.

 Como podemos ver acima, temos várias restrições quanto a alguns aspectos de uso de storage group, porém isso é mais em relação a segurança de uso do que por falta de "liberdade"para usá-lo.

 Exemplo de como criar um storage group:

 #symaccess -sid 093 create -name SG_SERV_BD -type storage create devs 0978, 0ABC

 Para adicionar devices a um storage group existente:

 #symaccess -sid 093 create -name SG_SERV_BD -type storage add devs 0ACD

Removendo devices:

 #symaccess -sid 093 -name SG_SERV_BD -type storage remove devs 0ACD (-unmap)

 O -unmap é opcional em relação se quisermos desmapear o disco das portas FA

Listando e mostrando o que temos em um storage group:

 #symaccess -sid 093 show SG_SERV_BD -type storage

 #symaccess -sid 093 list SG_SERV_BD -type storage

Criei o nome errado do storage group :( ... Calma tem como renomear:

 #symaccess -sid 093 rename -name SG_SERV_BD -new_name SG_SERV_WIN -type storage

Agora que corrigi o nome, preciso deletar :D

 #symaccess -sid 093 -name SG_SERV_WIN -type storage delete

Port groups

 Contém as portas de FA (fiber adapter) do VMAX, sendo que pelo menos duas portas devem ser adicionadas.

 Uma porta FA pode estar em mais de um port group.

 Portas podem conter flag de ACLX, necessária para quando usamos autoprovisioning.

Mas  como eu crio um port group?

Segue um comando de exemplo:

#symaccess -sid 093 create -name PG_01 -type port -dirport 7E:1, 8E:1

Para adicionar uma porta:

#symaccess -sid 093 -name PG_01 -type port -dirport 9E:1 add

Removendo:

#symaccess -sid 093 -name PG_01 -type port remove -dirport 9E:1 -unmap 

Para visualizar ou listar um port group:

#symaccess -sid 093 show PG_01 -type port

#symaccess -sid 093 list -type port

Deletando um port group:
#symaccess -sid 093 -name PG_01 -type port delete

Initiator group

 Contém os WWNs das HBAs dos hosts ou os ISCSI names.
 Pode conter no máximo 32 entradas.
 Um WWN só pode existir em um initiator group.
 Também podemos ter um cenário equivalente ao storage group. Podemos ter um Initiator group pai e dele termos initiator group filhos. Porém os WWNs devem ser adicionados nos initiators group filhos.

Criando um initiator group:
 #symaccess -sid 093 -type initiator -name IG_SRV01create -wwn wwndohost
 #symaccess -sid 093 -type initiator -name IG_SRV01 add -wwn wwndohost

Para remover um initiator do grupo:

#symaccess -sid 098 -name IG_SRV -type initiator -wwn wwndohost remove

Renomeando:

#symaccess -sid 098 rename -name IG_SRV -new_name IG_APP_WEB -type initiator

Deletando um grupo:

#symaccess -sid 098 -name IG_APP_WEB -type initiator delete

Agora, nada disso é de certa forma útil senão criarmos um masking view para amarra todos esses objetos.

Masking view

 Nele devemos colocar o initiator group, o port group, storage group e definir um nome. Nada mais do que isso.

Criando um masking view:

#symaccess -sid 098 create view -name MV_SRV02 -pg PG_01 -ig IG_APP_WEB -sg SG_SERV_APP_WEB

Para renomear um masking view:

#symaccess -sid 098 rename view -name MV_SRV02 -new_name MV_SRV_APP

Deletando um masking view:

#symaccess -sid 098 -name MV_SRV_APP delete view

Também podemos fazer o unmap neste momento:

#symaccess -sid 098 -name MV_SRV_APP delete view

Show do masking view:

#symaccess -sid 098 show view MV_SRV_APP

Também podemos fazer um backup ou um restore de uma masking view:

#symaccess -f sym.bak -sid 098 backup

#symaccess -f sym.bak -sid 098 retore

Pode parecer complexo tudo isso, pode parecer uma tarefa muito árdua fazer tudo isso. No entanto, VMAX é assim.

Um storage highend, necessita que o administrador saiba o que realmente está fazendo, como funciona, boas práticas, podem fazer reutilização de recurso de configurações diferentes.

Quem é adepto de scripts e consegue fazer isso (eu não tenho esse dom :D) pode facilitar muito as tarefas do dia-a-dia.

Bom, estou encerrando aqui a parte 4 e já iniciando a parte 5 para o quanto antes dar continuidade.

Espero que todos estejam gostando e vale lembrar que comentários sempre são bem vindos (mesmo críticas pessoal :D), dúvidas também, com isso posso ajudar no que for preciso e caso não saiba de bate pronto vou atrás da informação para tentar ajudar.

Abraços e boa noite!!!

Symmetrix VMAX - Part. 3 - Conectividade com o(s) host(s)

Boa noite pessoal.

 Essa semana está um pouco corrida devido a um curso que estou fazendo sobre MDS, uma linha de switches da Cisco (mais para frente teremos mais este assunto :) ), mas vamos a mais uma parte do conteúdo sobre VMAX.

 Vamos agora a parte 3 falando um pouco sobre a conectividade dos hosts com o VMAX e algumas coisas mais que sejam necessários e relevantes nesse quisito.

 Basicamente, o VMAX é homologado para diferentes sistemas operacionais como HP-UX, AIX, Solaris, Linux, Windows, Virtual Machines e Hypervisors como ESX, XEN Server.
 Para todos os hosts existe um documento da EMC de connectivity guide, onde são informadas as melhores configurações de parâmetros, tuning, multipath, dentre algumas best practices para conseguirmos usar todos os recursos do VMAX e não causar problemas na percepção do host e do usuário final quanto a performance e disponibilidade.

 Devemos ter pelo menos duas portas de front-end do VMAX mapeadas para um host, sendo que estas portas não devem compor se possível o mesmo director, pois em caso de falhas não teremos redundância.

 Abaixo, segue um desenho bem macro sobre a conexão de hosts para portar do VMAX:

 Como podemos ver, cada host possui duas fibras indo para portas de front-end do VMAX, embora esta conexão esteja direto e sendo isso possível, não é recomendado. Dessa forma estaremos perdendo recursos de portas do VMAX, pois seria necessário na verdade, duas portas para cada host, onde três hosts iriam consumir 6 portas no total.

 Essa comunicação é estabelecida através de uma SAN e processo de zoning. Dessa forma duas portas podem ser as mesmas para compartilhar recursos com estes três ou mais hosts.

 Para diferentes tipos de hosts podem ser necessários bit flags configurados nas portas de FA, porém isso eu já comentei e para saber basta usar o connectivity guide dos hosts, lembrando que podemos fazer isso nos initiators group e não diretamente nas FA's, assim podemos fazer com que as FA's tratem caso-a-caso e não de forma global, sendo por atender determinados hosts e assim ser necessário criar mais port groups.

A tabela abaixo, mostra alguns exemplos de bit flags que são necessários para alguns hosts:

Abaixo segue uma lista dos comandos para fazer scan SCSI Bus para reconhecer devices ou novos devices:

Solaris:
 #devfsadm -C

IBM AIX:
>lsdev -Cc adapter -Fname |grep FC (comando para identificar os adapters HBA no AIX)
>cfgmgr -l fcs? (corresponde ao número do BUS adapter)

HP-UX:
$ioscan -fnC disk (scan e identificação de novos devices)
$insf -e (criação de volume para devices especiais)

Linux:
#echo " - - - " > /sys/class/fc_host/hostX/scan (sendo que o X corresponde ao número do BUS Adapter)

Windows:
C:\DISKPART
DISKPART> rescan
DISKPART> exit

 Caso o mesmo servidor que vá receber um novo disco tenha instalado o Solutions Enabler, é possível fazer o rescan através do comando:
symcfg rescan
symntctl rescan (este apenas para Windows)

 No caso de discos para ambientes virtuais, temos algumas formas para que isso seja feito. Na verdade uma coisa sempre será feita, que é zoning do host hypervisor na SAN para as portas de front-end do VMAX e por vez os discos apresentado para os WWNs do hypervisor ou dos hypervisors.
 Este disco pode ser formatado pelo hypervisor e ser fatiado e assim entregue para as máquinas virtuais.
 Todo o controle é feito na camada do hypervisor, referente a multipath, formatação, blocagem, alinhamento, etc.
 Uma outra forma, é fazermos o mesmo processo de zoning, porém não formatar o disco na camada do hypervisor e mapear o disco diretamente para uma VM como RDM (raw device mapping). Seria o equivalente ao que fazemos com um host físico. Vale lembrar que hoje em dia já foi comprovado que apresentar um disco dessa forma tem praticamente a mesma eficiência a nível de performance do que um disco entregue e formatado pelo hypervisor. No entanto, isso ainda pode ser necessário por conta de algumas aplicações em específico como Oracle, Cluster dentre outros que precisam possuir um controle maior sobre esse disco diretamente e ver como esse disco é realmente, no modelo que ele foi criado no storage, como bloco, tipo, vendor, etc.

Exemplos de hypervisors suportados pelo VMAX:

O desenho abaixo mostra a abstração do que seria a conexão de um hypervisor com um storage array, tendo criado uma VM com um disco apresentado:

O disco neste exemplo é entregue pela camada do hypervisor, ou seja, está formatado pelo virtualizador.

Aqui podemos ver que o host VM continua recebendo os recursos do hypervisor, porém ele tem um disco que esta sendo entregue de forma "direta", passando apenas pelo hypervisor como uma ponte pela VM não possuir uma HBA atribuída.

Hoje temos a possibilidade de algumas vizualizações e administração de apresentação de discos para ambiente virtual, sejam feitas direto pelo Solution Enabler, porém é necessário passar o login de root e senha para o administrador de storage. O que pode não ser muito fácil de conseguir a nível de segurança dependendo do perfil da empresa.

Segue o comando para adicionar um hypervisor a administração do solutions enabler:

#symcfg auth -vmware add -host 192.168.0.123 -username root -password ******

Para verificar os hosts cadastrados:

#symcfg auth list -vmware

    hostname                      Username                  Namespace               Port

----------------------     ------------------------     ----------------------     -------------

192.168.0.122                   root

192.168.0.123                   root

#symvm list -server all

Server Name                                               Type

---------------------------------------------------------------------

192.168.0.122                                           VMware

192.168.0.123                                           VMware

 É possível através do Solution Enabler verificar quais são os servidores, hostname, sistema operacional e status de power on/off de um hypervisor:

#symvm list -server 192.168.0.122 -vm all

 Podemos verificar os datastes:

#symvm list -server 192.168.0.122 -storage all

Para ver as informações específicas de um datastore:

#symvm show -server 192.168.0.122 -storage datastore_name

Verificando as informações de uma VM:

#symvm show -server 192.168.0.123 -vm LNX129

Adicionando um device RDM a uma VM pelo Solutions Enabler:

#symvm map -server 192.168.0.123 -vm LNX129 -array_id 0000129039401 -devs 386:387

O array_id deve ser o serial number completo do VMAX.

Comandos para fazer rescan em um ESX:

#esxcli storage core adapter rescan -all

#esxcli -s 192.168.0.122 -u root -p <password> storage core adapter rescan -all

Bem por hoje é só.

Com o tempo vocês irão ver que essa parte não é tão complicada. Alguns ambientes por serem mais sensíveis com certeza merecem alguma atenção e uma certa configuração de bit flags, como é o caso de clusters, banco de dados, Windows principalmente. No entanto, tudo configurado corretamente não tende a ser uma dor de cabeça para o administrador de storage, muito menos gargalo para o VMAX.

Algumas dicas que eu dou é de sempre lembrar aos sys admins de que deve ser configurado corretamente o multipath, sempre que possível encaminhar para estes times o PDF com o connectivity guide do respectivo SO, acompanhar e auxiliar nessa parte sempre que possível pois senão você sempre será acionado em caso de problemas de performance em disco, latência, erros de I/O enfim, quando recebem um problema de performance e vem que o disco vem de storage sempre existe um trabalho a quatro mãos.

Outra ferramenta que podemos utilizar para gerar uma matriz de compatibilidade entre host x storage é o E-lab no site da EMC.

Mais para frente irei fazer um post de como acessar e usar essa ferramenta do site da EMC que ajuda e muito. Provavelmente farei até um vídeo pois assim fica mais fácil de visualizar.

Bom pessoal, boa noite, fiquem com Deus e até a próxima!!! (quem sabe amanhã rsrs).

Abs!

Symmetrix VMAX - Part. 2 - Criação de devices e mapping

Bom pessoal, Boa noite.

Dando sequência na séries VMAX, vou dar inicio agora na segunda parte onde irei abordar os seguintes assuntos: 

• Desenho e explicação da arquitetura de back e front-end;
• Engine e Director;
• Create e delete devices;
• Form e dissolve meta volumes;
• Map e unmap devices;
• Característica de portas;
• Reserva de devices;

  Abaixo, segue um desenho da estrutura de uma engine e a divisão deste compondo dois directors:

  Engine: A Engine é um componente modular necessário para o crescimento do VMAX. É aquela “geladeira”preta que vemos uma do lado da outra no data center. Cada engine contém dois Directors, sendo identificados como par (even) ímpar (odd) sendo composto cada Director por portas de front e back-end, Cpu, Global memory (ou cache) e discos. As portas de front-end são identificadas da seguinte forma: 

• E, F, G, H

 Contendo porta 0 e porta 1 (em alguns documentos ou mesmo na SAN pode aparecer como A para porta 0 e B para porta 1). Então temos as seguintes combinações de portas: 

• E0, E1, F0, F1, G0, G1, H0, H1 

Cada Director também possui uma número de identificação como, por exemplo, 9 e 10.Temos dessa forma as portas: 

• 9E:0, 9E:1, 9F:0, 9F:1, 9G:0, 9G:1, 9H:0, 9H:1
• 10E:0, 10E:1, 10F:0, 10F:1, 10G:0, 10G:1, 10H:0, 10H:1

 Já as portas de back-end possui a seguinte identificação: 

• A, B, C, D

 Também contendo duas portas cada, porém, com a identificação de C e D. Então temos as seguintes combinações:

• AC, AD, BC, BD, CC, CD, DC, DD

 Como as portas de back-end também fazem parte do director, segue o exemplo com dois directors, que no caso vou manter o 9 e 10. Outro ponto neste caso é que cada disco mapeado em uma dessas portas, recebe uma sequência numérica, iniciando em 0. Então se tivermos 5 discos mapeados em uma determinada porta, teremos os discos 0, 1, 2, 3 e 4. Exemplo do endereço de um disco: 

• 9A:C0, 9D:C1, 9D:C3

 O Enginuity (Sistema Operacionao do VMAX) mapeia a localização dos Logical Volumes no disco físico no back-end. Cada fatia lógica de disco o VMAX chama de Hyper. Por exemplo, um disco físico de 146GB, pode conter um hyper de 16GB, outro de 8GB, outro de 9GB e assim por diante até utilizarmos o tamanho total do disco físico. 

A criação desses volumes lógicos são definidos no momento do BIN file do VMAX, ou seja, quando está ainda em faze de instalação e ativação. Esses volumes lógicos, ou melhor dizendo, Hypers (para que possamos ir acostumando com o nome utilizado) podem ser utilizados para BCV, para ser membro de um RAID 5 ou RAID 6, para uma replica remota com SRDF, dentre outras utilidades. 

O máximo de hypers que um disco físico pode ter varia de acordo com a versão de software do VMAX, sendo de 512 na versão 5874 e de 1024 na 5875+.

Os hypers também podem varias de tamanho. O SLV (Symmetrix logical volume) é uma emulação do disco físico, então usa uma terminologia similar: Setor (16) 512 byte Block=8k Pista (track – R/W Head)(8) setores = 64k Cilindros(15) pistas = 960k Em muitos ambientes é normal vermos a trativa de volumetria sem cilindros e não em MB ou GB, porém, podemos criar usando qualquer um dessas três unidades. 

O VMAX aceita um volume de no máximo 262668 cilindros, que é algo em torno de 240GB. Então quer dizer que se uma aplicação que necessite de um disco de 500GB não poderemos utilizer discos do VMAX? 
Claro que vai poder usar, porém, precisaremos criar um recurso chamado de Meta Volume que nada mais é do que a junção de vários ou de alguns volumes até chegarmos na volumetria deseja ou pelo menos próxima. Por exemplo, para criar um disco de 500GB podemos criar 5 discos de 100GB e fazer um meta volume de 500GB. 
Cada device que criamos no VMAX ele recebe uma identificação única em hexadecimal, equivalente ao LUN ID no modelos da Clariion, então quando vamos formar um meta volume, devemos definir quem será o meta head e os meta members, podendo o meta head ser escolhido pelo administrado no momento da criação dentre os volumes definidos. 

Bem no decorrer vou falando um pouco mais sobre isso e assim iremos absorvendo gradativamente essa questão. 

Os tipos de RAID que podemos configurar no VMAX são RAID 1, RAID 5 e RAID 6, sendo que para o five podemos escolher as opções de 3+1 ou 7+1 (quantidade de discos + paridade) e no RAID 6 de 6+2 ou 14+2 (quantidade + paridade). Bom agora vamos para as partes um pouco mais “legais”que é o procedimento para criar alguns objetos no VMAX. 

Criando Devices:


O commando base é o:

 #symconfigure –sid 200 –file nomedoarquivo –prepare/commit O arquivo deve conter: create dev count=4, size=1100, config=RAID-6, emulation=fba, data_member_count=6; 

Criando 4 devices de 1100 cilindros (poderiamos especificar 20GB por exemplo para criamos com tamanho de 20GB), o tipo de RAID, neste caso RAID6 o tipo de emulação FBA (tipo open) com a opção de 6+2 (data_member_count). 

Caso você queira saber quatos de espaço de discos livres temos quando formos criar os volumes, podemos executar o seguindo comando:  

symdisk list –dskgrp_summary -sid SymmID 

Alguns tipos de configurações criam um tipo de lock no VMAX para impedir que outras configurações iguais possam causar algum impacto para o ambiente. 

Segue os tipos de configurações que causam lock do VMAX: 

-       Director lock
-       Front-end device lock
-       Backend device lock
-       Configurações no arquivo IMPL 

Lembrando que caso duas ações semelhantes sejam iniciadas, apenas uma irá funcionar e não as duas. Sempre uma delas irá passar e concluir. 

Criando devices de gatekeepers (devices de controle para adm do VMAX): 

Inserir em um arquivo de texto:

create gatekeeper count=3, emulation=FBA, type=thin, mapping to dir 7E:0 starting target=0, lun=0D5; 

Neste exemplo, já estamos mapeando o disco criado para a porta de front-end 7E:0 iniciando o endereço do host ID em 0 para este device e o LUN em 0D5. Esse endereço LUN não é a mesma coisa que o LUN ID no storages Clariion. Mais para frente eu explico melhor. 

Caso seja necessário deletar algum device ou alguns devices, segue o comando que devemos adicionar no arquivo de texto:  

delete dev SymDevName[:SymDevName]; 

Onde symdevname:symdevename é o range de devices. Para que seja possível deletar um device, ele deve obecer algumas regras, caso contrário, ele não será deletado: 

1. Não podem estar configurados em sessão de BCV ou Snap;
2. Se for um data device, ele deve estar desabilitado e não possuir nenhuma trilha;
3. Não pode estar mapeado para alguma porta de front-end;
4. Não pode fazer parte de algum grupo de replicacao remota (SRDF);
5. O source ou targer não podem fazer parte de sessão de clone;
6. Virtual device não pode estar em uso;
7. Não pode ser RDF;
8. Não pode ser um metamember;
9. Não pode ser SFS device;
10. Save device também não;
11. VCM Database device;
12. Masked de um VCM;
13. Não pode ser um thin device com bound em algum pool;

 A necessidade de criar um meta device vem de que podemos criar um único volume de apenas 240GB, então para que possamos atender a necessidade de outras volumetrias, criamos volumes e formamos um meta device com esses volumes sendo um meta head e os outros meta members.Eles podem ser de dois tipos, concatenated ou striped. Do ponto de vista de performance, o striped é recomendado pois oferecer mais spindles de leitura e gravação, sendo que o concatenated oferece tudo isso de forma sequencial. Porém o concatenated oferece maior facilidade quando precisamos expandir um meta device existente. 

Abaixo está uma tabela de considerações e restrições sobre meta devices: 

 














Para criar um meta device, adicione o seguinte conteúdo em um arquivo de texto:  

form meta from dev SymDevName, config=MetaOption[,stripe_size=<MetaStripeSize>[cyl]][,count=<member_count>]; 

Exemplo: 

form meta from dev 10a0, config=concatenated;
add dev 10aa to meta 10a0; 

Para desfazer um meta device: 

dissolve meta dev 10a0; 

Agora mesmo que esteja pronto o zoning do host para as portas de front-end do VMAX e os devices criados, o host não irá ter acesso, pois não informamos que este disco pode estar acessível por determinada porta.

Para isso, precisamos fazer o criar um arquivo com o seguinte conteúdo:

map dev 10a0 to dir 7E:0

Executar o comando symconfigure e apontar para este arquivo: #symconfigure –sid XXXX –file map.txt –commit Para fazer o unmap, criar um arquivo texto com o conteúdo: unmap dev 10a0 from dir 7E:0; Podemos colocar o intervalo de devices para fazer o map ou unmap de vários ao mesmo tempo, separando sempre por dois pontos (:); Para atender alguns ambientes, sendo por critérios de cluster ou alguma peculiaridade de versão, enfim, algumas características de configuração de porta se fazem necessário como:  

• Common Serial Number
• SCSI3
• SPC2
• Volume_set_addressing (quando usamos hosts com HP-UX);

 Quando utilizamos cluster Windows e cluster ESX, precisamos utilizer estes parametros também para que o cluster não se perca e reconheça ora o disco em um nó, ora em outro, e nunca em ambos ao mesmo tempo. Quando utilizamos auto provisioning, precisamos ter a feature ACLX habilitada nas portas. 

Para alguns ambientes pode ser interessante utilizar não configurações de porta, pois isso será gobal a todos. Podemos criar através do symaccess características para cada initiator group e assim atender esses requisitos sob demanda. 

Uma função muito legal que temos no VMAX é a reserva de devices, no entanto, como nem tudo pode ser perfeito, essa reserva serve apenas como aviso quando alguém tentar utilizar determinados devices.Caso em seu time existam por exemplo três administradores, você pode querer adiantar algum trabalho do dia seguinte deixando alguns devices criados e para não correr o risco de algum dos seus companheiros utilizá-los e você ter que fazer tudo novamente, basta colocar essa informação de reserve.Porém, vai depender do bom senso e do quanto seu time se ajuda nas tarefas administrativas para não usá-los, por que mesmo após a notificação ele pode seguir com o uso do device.  

Dois parametros dentro do arquivo options devem estar habilitados para que o reserve funcione. São eles: 

SYMAPI_ENABLE_DEVICE_RESERVATIONS=TRUE
SYMAPI_ENFORCE_DEVICE_RESERVATIONS=TRUE 

Segue o exemplo de reserva para um device: 

#symconfigure –sid XXXX –cmd “reserve dev 05a;” –owner Joao –comment “Devices reservados para o projeto BD – SUL reserve –nop 

Agora, também vou ensinar como fazer o bypass, porém é bom tomar cuidado para não virar confusão, pois existem administradores com um EGO que só vendo. Por qualquer coisa viram bicho. 

Vamos verificar a lista de reservas: 

#symconfigure –reserved list 


 Caso exista alguma reserva, ela irá aparecer neste formato.

 Exemplo: 0001 01/20/2015 E- Joao 0059 - - 

Primeiro campo ID, Date, Flags, Dono, Device, porta e endereço 

Bypass: 

#symconfigure –sid XXXX release –reserve_id 0001 –nop 

Bom pessoal, por enquanto, a parte dois da saga de administração e conceitos do VMAX fica por aqui.Espero que todos estejam gostando e que esteja sendo útil à todos. 

Abraços e boa noite!!!