0

EMC VPlex – Virtualização de storage

24 Flares 24 Flares ×

Hoje vou falar um pouco sobre o produto da EMC para virtualização de storage. O VPlex.
Recentemente participei de um treinamento referente este produto, que vem com uma ideia inovadora, mostrando estabilidade, escalabilidade e acima de tudo disponibilidade, quando o assunto é acesso aos dados.
O conceito de virtualização de storage é termos uma nova camada que irá receber os discos lógicos (LUNS, Devices, ETC) dos storages propriamente dito, seja ele de qualquer vendor não especificamente da EMC, e este passar a ser um fornecedor de discos para os hosts.

Exemplo de conexão:

vplex

Vamos a explicação:

  • Temos nossa SAN redundante, tendo dois fabrics (SAN1 e SAN2);
  • O VPlex através das portas de front-end (Linhas em verde) são as portas que devem fazer zonning com as HBAs dos initiators (também em verde);
  • As linhas que estão em azul e vermelho representam a comunicação de back-end do VPlex com os storages, neste exemplo o VNX e o VMAX. Sendo assim, deve existir um zonning das portas de back-end para as portas de front-end de cada storage (SP e FA neste modelo);

Dessa forma, teremos todos os nossos storages entregando discos para o VPlex neste caso e ele fazendo a função para os initiators de storage.

Para os storages o VPlex passa a ter função de initiator e com isso fazendo o processo de criação de recursos seguir seu curso normal dependendo do modelo do storage.
No caso do VMAX, devemos seguir com a criação dos devices, depois os meta-devices, adicionar em um POOL, configurar o Initiator Group, Storage Group, Port Group e Masking View. Se estivermos falando de um VNX, criar as LUNs, registrar os Initiators e configurar o Storage Group. E por aí vai, cada storage irá trabalhar da mesma forma que sempre trabalhou e você como administrador irá criar os recursos da mesma forma.
No VPlex teremos que trabalhar as LUNs e ou esses devices entregues para que eles façam a função de Virtual Devices para os hosts. Por enquanto não vou entrar nessa questão, pois por enquanto quero falar apenas do VPlex e um pouco de como funciona essa questão de virtualização de storage.
Feito todo processo de configuração das LUNs no VPlex, temos que fazer o mesmo processo de masking para que possamos informar logicamente quais discos um determinado host pode acessar e quais portas ele pode utilizar. Nesta etapa, temos o VPlex como um storage entregando recursos de discos para os Initiators.

Então o processo de zonning deve ocorrer da seguinte forma:

  • Portas de back-end do VPlex em zonning com as portas do storage, seja FA, SP, etc;
  • Portas de front-end do VPlex em zonning com as portas HBAs dos initiators;

Agora pelo fato de termos que criar recursos em dois ambientes parece um tanto quanto complicado do ponto de vista administrativo, pois temos a sensação de que teremos agora sempre duas atividades de entrega de disco.
Porém, a grande vantagem de podermos usar o storage virtualizado é que assim que tivermos as definições do ambiente ou dos ambientes, os recursos de storage serão criados 100% no lado storage, ficando conforme demanda apenas a criação dos recursos no VPlex.
Se formos seguir o modelo tradicional de entrega, realmente teremos que fazer duas atividades de entrega de discos isso sem contar a parte de zonning.

A família VPLex possui três modelos, sendo eles:

VPlex_Family

Falando um pouco de cada modelo:

VPlex Local: Usado de forma centralizada, atendendo assim um único site. Neste modelo temos os nossos storages fornecendo recursos para o VPlex, e o VPlex fazendo a função de storage em nossa SAN para os initiators.
VPlex Metro: Este modelo tem o conceito de accessanywhere, ou seja, ele possui uma interconexão com dois sites tendo o site 1 uma estrutura com SAN, VPlex e storage e o site 2 com os mesmos componentes. Dessa forma temos de forma síncrona o tráfego dos dados, garantindo alta disponibilidade, acesso rápido as informações, e para o lado host, tanto faz por qual estrutura ele está efetivamente armazenando os dados. Aqui vale lembrar que temos um limitação quanto a implementação que é a distância de um site para outro. Não podemos ter mais do que 5ms de RTT (round-trip time ou tempo de ida e volta).
VPlex GEO: Para esse modelo temos o mesma funcionalidade do Metro, porém aqui devido a ele comportar uma distância maior, em torno de 50ms de RTT, ele trabalha de forma assíncrona para poder fazer essa comunicação. Aqui no entanto temos que levar em consideração que podemos ter perda de dados devido a forma assíncrona, pois não temos confirmação de que foi escrito, de que foi gravado o dado no destino para que ela possa disparar as novas solicitações de gravação.

Abaixo, segue um desenho da implementação de um VPlex Metro e do quanto ele pode melhorar a eficiência do nosso ambiente, bem como a alta disponibilidade:

VPlex_Mob

No desenho temos dos clusters ESX, sendo o A em um site e o B em outro site. Uma VM pode existir inicialmente em um determinado site e posteriormente por uma questão de VMotion automático do sistema, ou através de intervenção do administrador ir para o outro site sem problemas. Isso tudo de forma transparente para o usuário final.
Claro que algumas aplicações devido a sensibilidade quanto a alguns fatores externos, tendem a perceber algumas movimentações, ou alterações podem apresentar algum comportamento anormal. Mas isso vale para qualquer ambiente. Para isso um bom estudo de caso antes de implementar uma solução é importante.
Alguns pontos de vantagem que eu vejo quanto ao uso do VPlex é em relação a podermos ter vários storages conectados em um mesmo ponto, facilitando assim a administração quanto a criação de recursos posterior setup do VPlex, migração de storage, pois podemos migrar os recursos dentro do próprio VPlex, sendo muito útil quando precisamos desativar um determinado storage, escalabilidade de crescimento, segurança do dados, alta disponibilidade, para os casos de Metro e GEO a praticidade de existir a comunicação site-to-site e que ambientes existam dentro desta estrutura e para eles tanto faz por onde o dado efetivamente está sendo acessado, uma camada tão eficiente quanto as estruturas de back-end/front-end dos storages para aguentar cargas de I/Os. Enfim, vale novamente um estudo de caso para ver como seu ambiente irá se comportar numa estrutura como a do VPlex, porém as vantagens são enormes.
Sem contar também as integrações que temos hoje com o Recover Point que é um outro produto da EMC, integração com o VIPR (software defined storage).

Segue alguns links referente ao VPlex, que serviram de base para este artigo e que podem ser de grande ajuda caso você queira saber um pouco mais e algumas questões mais específicas.

http://www.emc.com/storage/vplex/vplex.htm
http://www.emc.com/collateral/hardware/data-sheet/h7070-vplex-family-ds.pdf
http://www.emc.com/campaign/global/vplex/index.htm

Espero que tenham gostado e até a próxima.

RECOMENDADO PARA VOCÊ

João Paulo G. Marinho

Usuário linux, defensor do linux, podemos usar linux em tudo (até que se prove o contrário :D). Enfim, entusiasta de tecnologia, games, cultura, coisas de Nerd e o que mais interessar. Storage?! Só se for bom e útil... SAN? Sim, mas redundante por favor!!! :wq!

Dúvidas? Deixe seu comentário ou entre em contato.