Anuncios

domingo, 2 de agosto de 2015

Symmetrix VMAX - Part. 8 - Federated Tiered Storage (FTS)

Olá pessoal, tudo bem?

Na parte 8 vamos falar sobre Federated Tiered Storage, para simplificar, vamos tratar apenas como FTS, ok?

Mas afinal, o que é FTS?

FTS é a capacidade do VMAX de usar discos/Luns que estão criada em outro storage array. Essa feature está disponível a partir da Enginuity 58756 para os modelos 10K, 20K e 40K.
Aqui vale ressaltar que essa feature é gratuita, não requerendo nenhuma aquisição de software ou licença adicional.

As luns externas podem ser utilizadas no VMAX como raw storage space para criação  de Symmetrix devices, data sources podem ser encapsulados e a informação pode ser disponibilizada aos hosts pelo Symmetrix.
Os discos que são disponibilizados de outros arrays para o Symmetrix não são protegidos por ele, com isso a proteção deve ser garantida pelo outro array.

Esses devices são os chamados eDisks no VMAX (external disks).

Benefícios do uso do FTS:

Simplifica a gerência/administração pois teremos ao final uma única console de administração, uma única forma de configurações a serem realizadas;
Mobilidade de dados entre storages heterogêneos;
O benefício de virtual provisioning dos arrays externos;
Habilitar as features de replicação (TimeFinder ou SRDF) para uso nos arrays externos;
Extender o uso de arrays externos antigos para que estes façam uso do recurso de tiering;

Algumas práticas de uso:

Continuar usando arrays antigos enquanto eles ainda fazem uso das features da enginuity do Symmetrix;
Proteção de dados nos arrays externos;
Migração de dados entre arrays;

DX Directors

DA eXternal que se comporta apenas como uma DA;
Roda sob Fiber Optic SLICs apenas assim como uma FA e RF emulations;
Lida com LUNs como se fossem drives Symmetrix;



eDISKS

Associado com uma SCSI logical unit externa;
Acessados pela SAN;
Por ser virtual, não possui proteção por RAID;
Refere-se a um external spindle;

External disk group

É criado um virtual group contendo eDisks;
Exclusivamente um disk group external começa com o número 512. External spindle e internal physical spindles não podem ser misturados em um disk group.

Virtual raid group

Creado para cada eDisk;
Não possui proteção no Symmetrix;
A confiança de proteção deve vir do array externo;



Zoning:


FTS virtualization

Temos dois modos de usar um array externo no Symmetrix:
Podemos usar o discos como raw capacity, sendo que neste modo teremos a perda de dados do disco externo;
Encapsular os discos externos de modo que ele preserve os dados originais. Aqui temos dois tipos sendo o standard encapsulation e virtual provisioning encapsulation;

External provisioning
O spindle dos discos são criados e usados como raw capacity para novos Symmetrix devices;
Discos externos aparecem como desprotegidos, pois a proteção deve ser de responsabilidade do array externo;
Virtual provisioning Data Devices (TDATs) podem ser criados nos discos externos;

Agora vamos falar do standard encapsulation e virtual provisioning encapsulation

Standard encapsulation
Cria um eDISK para cada external lun e adiciona no external disk group;
Um Symmetrix device também é criado ao mesmo tempo;
O acesso para uso dos dados deste device é permitido pelo Symmetrix device;

Virtual provisioning encapsulation
Cria um eDISK para cada external lun e adiciona no external disk group;
Um data device totalmente alocado e um Thin device também são criados;
Este thin device pode ser usado para migração usando VLUN migration ou Virtual provisioning;

Para obter as informações de um device, devemos utilizar o seguinte comando:

symdev show




Arrays externos suportados para uso com o FTS:
Todos os arrays Symmetrix VMAX Family possuem suporte ao FTS;

Arrays externos EMC:
Todos os Symmetrix VMAX;
Linha DMX;
Clariion CX3, CX4 (Apenas ALUA);
VNX (Apenas ALUA);

Arrays de terceiros:
HDS;
IBM;
Netapp;
Sun;
HP;

* Recomendo sempre consultar o site da EMC para verificar a nova listagem de arrays externos que são aceitos pelo FTS.

Detalhes de um provisionamento externo
eDISKS são criados e adicionados a um específico disk group external;
* Separado dos grupos de discos que contém discos físicos internos
* Adicionado para um grupo virtual de discos desprotegidos

Sym devices podem ser criados para acesso como raw storage
* VAULT, SFS e ACLX
* Caso contrário será tratado como qualquer outro tipo de Symmetrix device
* Podemos usar TDATs para virtual provisioning

Encapsulating for Standard provisioning
eDISKS são criados e adicionados a um específico disk group external;
* Separado dos grupos de discos que contém discos físicos internos
* Adicionado para um grupo virtual de discos desprotegidos
* Sym devices podem ser criados habilitando acesso aos dados preservados
* Caso contrário será tratado como qualquer outro tipo de Symmetrix device

Encapsulating for virtual provisioning
eDISK e RAID Group são criados;
Data devs (TDATs) são criados e adicionados a um POOL;
Um Thin device totalmente alocado é criado e atribuido a um POOL;
O dado em uma LUN externa é preservado;



Manipulação para eDISKS grandes

São suportados tamanhos de discos maiores do que o suportado pelo device do Symmetrix.
Múltiplos Symmetrix devices podem ser criados se necessário para contabilizar o tamanho total de um eDISK criado caso necessário.
Devices podem ser feitos em um único meta concatenado:
* Aqui nesse caso temos o seguinte cenário, onde por questões de geometria de devices, se um ambiente necessitar de um device de 22GB, teremos que criar meta members de 9GB e assim teremos na verdade 27GB de volumetria. Caso não necessite de equalização quanto a geometria dos devices, podemos criar dois meta members de 9GB e um 4GB ao final não tendo limitação geometrica.
* O tamanho do auto meta member pode ser alterado;

Geometria de disco e encapsulamente

Devido a peculiaridade na forma de tratar o tamanho de devices na Enginuity do Symmetrix, onde temos quinze trilhas de 64k formando um cilindro. 
Por conta disso, a capacidade de um Symmetrix device criado não vai refletir exatamente a capacidade real de um eDisk.
Encapsulando devices, teremos a geometria setada que irá refletir a capacidade real do eDisk.
Os devices encapsulado tem um tamanho maior do que o reportado e do limite geométrico.



Geometria limitada por restrições de dispositivo

Replicação local:
Só pode ser por source devices;
Regras são aplicadas para operações em targets grandes;

SRDF
Pode ser apenas para devices R1;
Regras são aplicadas para operações em R2 maiores;

VLUN
Não pode ser target para migração;
Migração apenas para espaços não configurados;

Metas não podem ser expandidos, dissolvidos ou convertidos;

Como nem tudo são flores, vamos as restrições do FTS...

FTS Restrictions

Apenas para sistemas Open.
Para devices que são encapsulados não podem utilizar FastVP por não ser suportado.
Um POOL não pode conter ambos os tipos de devices (internal e external).
DARE (Data rest encryption) não é suportado para devices externos.
Ferramentas terceiras podem ser necessárias quando necessário usar para medir recursos de performance em relação aos arrays externos.
FCP 8Gb/s e menos são suportadas.

FTS System limitations

A capacidade máxima externa será determinada pelo cache do VMAX.
O número máximo de LUNs  por storage externo para cada porta é de 8000. Por sua vez, a capacidade máxima de uma única LUN externa é de 30TB.
512 portas externas por initiator group e todas as FAs podem ser mapeadas para DX emulation.
14.000 eDisks por par de director DX.
128.000 eDisks por sistema.

Abaixo segue um quadro do suporte FTS pelas features Enginuity:

1)

2)


3)

De certo modo, essa feature é a mesma questão que temos com virtualizadores de storage. Ele consegue fazer usufruto de recursos de espaço de armazenamento de outro array, utilizar suas featues (Raids, controladores, redundância, capacidade de crescimento, heterogenidade, etc) sendo elas boas ou não, e prover através do array VMAX o ponto de storage único para os hosts.

Vale tomar cuidado com algumas limitações quanto a parte utilização dos recursos, conversão de valores na parte de espaço entre os devices do Symmetrix e o raw capacity dos arrays externos.

Recomendo também um estudo de caso na parte do quanto é eficiente deixarmos a segurança em outro array que não o VMAX.

Talvez a forma que o outro array se comporte, pode ser que seja um gargalo para o VMAX e gerar sim algum impacto mais relacionado a performance ou até mesmo a perda de dados.

Abraços e até a próxima.

Nenhum comentário:

Postar um comentário