segunda-feira, 30 de março de 2015

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.

sexta-feira, 27 de março de 2015

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

quinta-feira, 26 de março de 2015

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!



domingo, 22 de março de 2015

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