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;
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
- 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:
- Não podem estar configurados em sessão de BCV ou Snap;
- Se for um data device, ele deve estar desabilitado e não possuir nenhuma trilha;
- Não pode estar mapeado para alguma porta de front-end;
- Não pode fazer parte de algum grupo de replicacao remota (SRDF);
- O source ou targer não podem fazer parte de sessão de clone;
- Virtual device não pode estar em uso;
- Não pode ser RDF;
- Não pode ser um metamember;
- Não pode ser SFS device;
- Save device também não;
- VCM Database device;
- Masked de um VCM;
- Não pode ser um thin device com bound em algum pool;
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);
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!!!
Nenhum comentário:
Postar um comentário