INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES · Introdução à XtremIO Virtual Copies ......

White paper

Resumo

Este white paper apresenta a XtremIO Virtual Copies como uma abordagem exclusiva para cópias graváveis em memória que são totalmente eficientes no uso de espaço. Ele descreve as práticas recomendadas e os principais aspectos da tecnologia Virtual Copies do XtremIO. Março 2016

INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES

2 Introdução à tecnologia XtremIO Virtual Copies

Copyright © 2016 EMC Corporation. Todos os direitos reservados. A EMC assegura que as informações apresentadas neste documento estão corretas na data da publicação. As informações estão sujeitas a alterações sem prévio aviso. As informações nesta publicação são fornecidas “no estado em que se encontram”. A EMC Corporation não faz declarações nem oferece garantias de nenhum tipo relativas às informações desta publicação e especificamente se isenta de garantias implícitas de comercialização ou adequação a qualquer propósito específico. O uso, a cópia e a distribuição de qualquer software da EMC descrito nesta publicação exigem uma licença de software. Para uma lista mais atualizada de produtos da EMC, consulte "Produtos" no site brazil.emc.com. Número da peça H13035-01 (Rev. 02)


Índice

Resumo executivo ................................................................................................... 5

Snapshots convencionais ........................................................................................ 7

Gerenciamento de volume convencional ............................................................................ 7

Snapshots do Copy-on-Write .............................................................................................. 7

Snapshots Redirect-on-Write ............................................................................................ 10

Outras tecnologias de cópia ............................................................................................. 12

Snapshots convencionais - eficiência e desempenho ....................................................... 12

Casos de uso de snapshots legados ................................................................................. 14

Introdução à XtremIO Virtual Copies ....................................................................... 15

Criando cópias com a tecnologia XtremIO Virtual Copies .................................................. 16

Recursos .......................................................................................................................... 17

Comparação .......................................................................................................... 18

Vantagens da arquitetura ...................................................................................... 20

Cópias de vários volumes consistentes entre si ................................................................ 28

Consistency Groups .......................................................................................................... 30

Snapshot Sets .................................................................................................................. 30

Bitmap de existência ........................................................................................................ 31

Exclusões de cópia virtual ................................................................................................ 33

Sem coleta de lixo ............................................................................................................ 33

Grupo de snapshot de volumes ........................................................................................ 34

Remoção de gravações de sombra ................................................................................... 35

Recursos de atualização ................................................................................................... 36

Diretrizes de atualização .............................................................................................. 38

Tags ................................................................................................................................. 38

Casos de uso......................................................................................................... 39

Descarregando as operações de backup .......................................................................... 39

Principais benefícios .................................................................................................... 39

Criando uma XVC para uso de backup — nos bastidores .............................................. 40

Casos de uso de teste e desenvolvimento ........................................................................ 42


Proteção de dados lógicos ............................................................................................... 45

Descarregando o processamento e a lógica analítica de dados ........................................ 48


Provisionamento de VMs em massa usando a tecnologia XVC em um VMFS (Virtual Machine File System) ....................................................................................................... 50


Conclusão ............................................................................................................. 52


Resumo executivo Os arrays XtremIO utilizam a XtremIO Virtual Copy, também conhecida como tecnologia XVC. A tecnologia XVC abstrai as operações de cópia como uma operação exclusiva de metadados em memória sem impacto sobre a mídia de back-end. A XVC possibilita cópias instantâneas e de alto desempenho de qualquer conjunto de dados em praticamente qualquer quantidade desejada. Ela faz uso totalmente eficiente de espaço, com serviços de dados como compactação e desduplicação em linha, e não afeta a produção ou outras cópias.

Normalmente os processos essenciais aos negócios exigem várias cópias de cada instância de banco de dados e de dados do aplicativo para diversas finalidades, como desenvolvimento, lógica analítica, operações e proteção de dados. Para aprimorar a agilidade e a competitividade organizacional, “quanto mais, melhor” (mais cópias, com mais frequência e mais autoatendimento operacional entre os ciclos do processo). Embora existam diversas abordagens para o gerenciamento de dados de cópia (CDM, conforme descrito pela Gartner e IDC), tais abordagens basicamente se esforçam para enfrentar a proliferação do armazenamento, a limitação da frequência de cópia, as limitações de desempenho e os processos operacionais complexos.

Com I/O por segundo e latência consistentes e “à prova de falhas” e a capacidade de dimensionar horizontalmente mais desempenho conforme necessário sem tempo de inatividade do aplicativo, o XtremIO oferece um desempenho incrível para aplicativos de produção e fora de produção sem afetar os SLAs (Service Level Agreement, contrato de nível de serviço) de produção.

A tecnologia XVC habilita a criação instantânea de imagens de cópia de dados de um volume, capturando os dados exatamente como aparecem no point-in-time específico no qual a cópia foi criada. A XVC permite que os usuários salvem o estado dos dados de um volume e posteriormente acessem os dados do volume específico (conforme necessário), mesmo depois que o volume de origem tiver sido alterado.

As cópias da XVC são implementadas de uma maneira exclusiva, que pela primeira vez mantém a eficiência de espaço nos metadados e nos dados das cópias (graváveis ou somente leitura). Em conjunto com a exclusiva arquitetura de metadados em memória do XtremIO, a XVC permite um grande número de cópias somente leitura/graváveis de alto desempenho e baixa latência.

As XVCs são eficientes no uso de metadados e de espaço físico, podem ser criadas instantaneamente, não têm impacto sobre o desempenho e têm os mesmos serviços de dados que qualquer outro volume no cluster (como provisionamento thin e redução de dados em linha).


As XVCs são um componente fundamental da tecnologia iCDM (Integrated Copy Data Management, gerenciamento integrado de dados de cópia) do XtremIO, permitindo vários casos de uso, inclusive:

Gerenciamento de ambiente de teste e desenvolvimento

Lógica analítica de banco de dados e processamento de transmissão

Proteção de dados

Operação

Provisionamento em massa de VMs

As XVCs são fáceis de usar e visualizar, e são gerenciadas como volumes padrão no cluster.


Snapshots convencionais Os snapshots convencionais foram inventados principalmente para fornecer proteção de dados com uso eficiente de espaço. A obtenção de um snapshot de um volume ou de um grupo de volumes cria uma cópia point-in-time do conjunto original de dados que o usuário pode reverter quando e se necessário.

Gerenciamento de volume convencional

Nos storage arrays de bloco convencionais, um volume lógico é o intervalo de endereços lógicos dentro desse volume.

Figura 1: Gerenciamento de volume convencional

Os endereços lógicos são mapeados para os blocos físicos de dados no disco. O procedimento real de mapeamento é responsabilidade do LVM (Logical Volume Manager, gerenciador de volumes lógicos). Esse procedimento pode ser simples ou complexo, dependendo de fatores como provisionamento thin, classificação por níveis, desduplicação, compactação e outros fatores.

Snapshots do Copy-on-Write

As implementações legadas de snapshots foram baseadas em uma tecnologia chamada “copy-on-first-write”. Nesse esquema, os metadados pertencentes ao local onde os dados originais estão armazenados são copiados no momento da criação do snapshot, e um novo pool de armazenamento é definido e reservado no cluster para o snapshot. Nenhuma cópia física é produzida ainda. Cada nova gravação aciona uma operação de movimentação de dados entre o volume de produção e o pool reservado de snapshot.

O fluxo de I/O ocorre da seguinte maneira:

1. O cluster recebe a nova gravação.

2. O sistema lê os dados originais do volume de produção.


3. O cluster grava os dados originais no pool reservado de snapshot.

4. O cluster sobregrava a produção com os novos dados.

Nesse esquema, somente os metadados pertencentes ao local onde os dados originais estão armazenados são copiados no momento da criação do snapshot. Nenhuma cópia física dos dados é realizada. Então, o gerenciador de volumes rastreia os blocks alterados no volume original enquanto as gravações são realizadas no volume original. Os dados originais que estão sendo gravados são copiados para o pool de armazenamento designado e reservados para o snapshot antes que os dados originais sejam substituídos (portanto o nome “copy-on-write”, ou cópia em gravação).

Isso significa que cada gravação tem uma penalidade de mais duas operações de I/O. É possível imaginar que ao usar mídia de alto desempenho, como SSDs, a abordagem poderia ser menos problemática. Isso não é necessariamente verdade, já que a metodologia ainda representa uma sobrecarga significativa em termos de gerenciamento de movimentação de dados. Ela afeta negativamente a latência para operações de gravação e leitura, limita a flexibilidade e o desempenho para topologias complexas de snapshot (p. ex., snapshots de snapshots) e representa um impacto negativo na durabilidade da mídia SSD.


Figura 2: Copy-on-Write — gravação no host

As operações de leitura são realizadas de modo semelhante. I/Os lidas no volume de produção são fornecidas sempre pelo pool reservado de dados de produção. As leituras no snapshot são fornecidas a partir do pool de produção para blocks que permanecem inalterados, e a partir do pool de snapshot reservado para blocks que foram alterados.

Figura 3: Copy-on-Write — leitura no host

Desvantagem:

As topologias complexas de snapshot sofrem degradação grave no desempenho.

Desvantagens:

Os metadados são copiados quando um snapshot é criado, o que consome tempo e capacidade e impossibilita gerenciá-los na memória.

O pool de snapshot reservado muitas vezes deve ser alocado antecipado, mesmo se não for utilizado completamente, e pode ficar sem espaço.

O desempenho é muito penalizado, especialmente para gravações.

As topologias complexas de snapshot sofrem degradação grave no desempenho.


Snapshots Redirect-on-Write

Nesse esquema, somente os metadados correspondentes ao local onde os dados originais estão armazenados são copiados no momento da criação do snapshot. Nenhuma cópia física dos dados é realizada. O gerenciador de volumes controla os blocos em mudança no volume original enquanto gravações no volume original são realizadas. Entretanto, quando novos dados são gravados no volume de produção, os dados são gravados diretamente no pool de armazenamento e o gerenciador de volumes atualiza (redireciona) os metadados do volume de produção para o novo local físico dos dados (portanto o nome “redirect-on-write”, ou redirecionamento em gravação).


Figura 4: Redirect-on-Write — gravação no host

Quando um snapshot é criado, os metadados da produção e os metadados dos volumes de snapshot no gerenciador de volumes apontam para os mesmos blocos físicos. Assim que o volume de produção recebe novas gravações (presumindo que os LBAs [Logical Block Address, endereço de bloco lógico] dos blocks B e D tenham sido substituídos), seus indicadores de metadados são atualizados de acordo com o novo local do bloco.

As leituras são executadas usando os indicadores de metadados no gerenciador de volumes para determinar onde o block físico reside.

Figura 5: Redirect-on-Write — leitura no host

Desvantagem:

Como cada snapshot consome volumes altos de metadados em memória e a quantidade de memória no array é limitada, é necessário desfazer a preparação de metadados para o SSD, o que afeta o desempenho mesmo em um array totalmente flash.

Desvantagens:

Normalmente, os metadados são copiados quando um snapshot é criado, consumindo tempo e capacidade.

Em alguns casos, uma operação adicional é necessária para tornar os snapshots passíveis de leitura/gravação.

Algumas implementações não copiam metadados quando os snapshots são criados, pois são somente leitura. Contudo, quando o snapshot precisa ser acessado em leitura/gravação, os metadados são copiados, consumindo tempo e memória.


Os snapshots redirect-on-write têm uso eficiente de espaço, mas não de metadados, pois a metodologia envolve copiar todo o conjunto de metadados do volume original durante o processo de criação do snapshot.

Outras tecnologias de cópia

Outras tecnologias estão disponíveis para fazer cópias de volumes. Os clones, que normalmente são criados a partir de um snapshot estático, oferecem uma cópia completa dos dados (já que os clones normalmente são feitos para separar fisicamente drives de disco rígido ou SSDs). Embora os clones tenham o potencial de fornecer o mesmo desempenho que os volumes de produção no cluster, normalmente o tempo de criação de um clone é muito demorado porque os dados são copiados para o clone. Os SLAs podem ser afetados durante a produção da operação de clonagem. Além disso, os clones são ineficientes porque consomem o dobro da capacidade e dos metadados.

Os split mirrors são usados para criar clones com mais eficiência a partir de uma origem dinâmica. O espelhamento é estabelecido entre o volume de produção e o clone (um processo de sincronização que permanece em andamento até que o clone alcance a produção). Uma vez atingido, os administradores podem dividir o clone para ter uma cópia independente dos dados.

As duas tecnologias oferecem bom desempenho. Entretanto, os tempos de criação e de atualização são muito longos com qualquer uma dessas opções. Os clones e os split mirrors são ineficientes em termos de capacidade de dados e metadados.

Snapshots convencionais - eficiência e desempenho

Gravações em snapshots resultam em fragmentação, com o mesmo resultado sendo verdadeiro para redirect-on-write ou copy-on-write. Além disso, quando vários snapshots são criados, o acesso aos dados originais e o rastreamento de alterações dos metadados para todos os snapshots, a fragmentação e a reconciliação após a exclusão dos snapshots resultarão em grande degradação do desempenho.

A exclusão de um snapshot redirect-on-write envolve a digitalização e o processamento dos metadados do snapshot, eliminando todos os blocos de dados correspondentes que pertencem exclusivamente ao snapshot, potencialmente movendo dados do pool de reserva do snapshot para o pool de volumes de produção. O tempo necessário para a conclusão desse processo é proporcional ao tamanho original do volume, em vez de ser proporcional à quantidade de blocos alterados desses no volume original (desde a criação do snapshot).

Os snapshots copy-on-write não são eficientes nas gravações no volume original. Os snapshots copy-on-write e redirect-on-write têm de lidar com fragmentação de dados ao longo do tempo, bem como com alterações significativas de metadados. Isso


significa que, uma vez que um snapshot é criado, o desempenho de I/O no volume original geralmente é afetado de forma negativa.

Esses problemas de desempenho não podem ser reduzidos na arquitetura legada de controladora dupla, muito menos com a arquitetura ativo-passivo. O principal motivo para isso é que é possível ter apenas uma controladora por volume ou snapshot (ou no máximo, duas controladoras) envolvida no gerenciamento do volume ou do snapshot. A escalabilidade não é possível, e um grande número de snapshots e de volumes de produção cria uma sobrecarga significativa na controladora, afetando o desempenho em snapshots, volumes de produção ou em ambos.


Casos de uso de snapshots legados

Originalmente os snapshots eram criados e utilizados por períodos curtes de tempo, normalmente para criar uma cópia “ativa” dos dados de produção para fins de backup. Os snapshots permitiam que os administradores congelassem o aplicativo de produção por um curto período de tempo, criassem um snapshot e retomassem as operações normais. Essas ações resultavam em uma cópia estática dos dados de produção, que normalmente era acessada no modo somente leitura e podia ter um backup feito para um dispositivo externo de backup. Os motivos pelos quais os snapshots eram utilizados somente para períodos curtos incluíam problemas de desempenho, considerações de utilização de capacidade e um número limitado de snapshots compatíveis.

Posteriormente, com o desenvolvimento de tecnologias redirect-on-write, o uso de snapshots foi ampliado para períodos maiores de tempo, principalmente para processos de teste e desenvolvimento. Entretanto, o uso do snapshot era limitado porque na maioria dos casos o desempenho era afetado, seja em decorrência de implementações de snapshots copy-on-write com alta degradação no desempenho para o ambiente de produção ou por conta de snapshots redirect-on-write que apresentavam maior latência de leitura, resultante da varredura de dados dos metadados vinculados no array ou de sobrecargas nas CPUs das controladora e de fragmentação de dados.


Introdução à XtremIO Virtual Copies As cópias da tecnologia XtremIO Virtual Copies são graváveis ou somente leitura. Cópias somente leitura permitem manter imutabilidade das cópias. É possível criar uma cópia virtual a partir de um volume de produção ou de uma cópia de qualquer outro volume de produção.

As XVCs podem ser usadas em um número de casos de uso, inclusive nos seguintes exemplos:

Proteção contra corrupção lógica: crie cópias point-in-time frequentes (de acordo com intervalos de RPO – segundos, minutos, horas) e utilize-as para se recuperar de qualquer corrupção lógica dos dados. Uma XVC pode ser mantida no sistema pelo tempo que for necessário. Em caso de corrupção lógica dos dados, é possível usar uma cópia point-in-time de um estado anterior do aplicativo (antes da corrupção lógica dos dados) para recuperar o aplicativo em um point-in-time “bom”. Também é possível executar uma restauração completa dos volumes de produção a partir da cópia de backup.

Backup: crie cópias virtuais que serão apresentadas a um servidor/agente de backup. As cópias podem ser usadas para descarregar o processo de backup de um servidor de produção.

Teste e desenvolvimento: crie cópias virtuais dos dados de produção e então crie várias cópias (com economia de espaço e alto desempenho) do sistema de produção para apresentá-las para fins de desenvolvimento e teste. Como a tecnologia XtremIO Virtual Copy possibilita uma hierarquia ilimitado de cópia, vários processos de teste e desenvolvimento são compatíveis. É possível atualizar ambientes de teste e desenvolvimento com dados de produção novos ou atualizados. A operação de atualização é fácil e imediata. As entidades SCSI usadas pelos servidores de teste e desenvolvimento são preservadas durante a atualização, alterando apenas os dados subjacentes, e, portanto, evitando que o host examine novamente o barramento SCSI. Todos os ambientes podem ter scripts criados com facilidade por meio da CLI ou da API RESTful.

Lógica analítica de dados em tempo praticamente real: use a tecnologia XVC como meio de descarregar o processamento de dados, como ETL, do servidor de produção. Por exemplo, se for necessário executar um processo pesado nos dados (que pode afetar o desempenho do servidor de produção), é possível usar a XVC para criar uma cópia atual dos dados de produção e montá-la em outro servidor. Esse processo pode, então, ser executado no outro servidor sem consumir os recursos do servidor de produção. Esse recurso habilita capacidades de lógica analítica em tempo praticamente real e sob demanda.


Criando cópias com a tecnologia XtremIO Virtual Copies

Para obter instruções detalhadas sobre a criação de XVCs a partir de volumes, conjuntos de volumes ou consistency groups, consulte o Guia do Usuário do XtremIO Storage Array.


Recursos

A tecnologia XtremIO Virtual Copies oferece os seguintes recursos:

As cópias são criadas instantaneamente, fornecendo uma cópia funcional e gravável do volume de produção.

As cópias são cópias de leitura-gravação ou somente leitura* dos volumes de origem.

As cópias são volumes normais no cluster.

As cópias têm os mesmos serviços de dados que qualquer volume no sistema, enquanto os recursos globais de provisionamento thin e desduplicação em linha estão em operação constante.

As cópias são eficientes no uso de dados e de metadados.

As cópias não precisam de espaço reservado.

O sistema comporta uma imagem de cópia consistente em vários volumes (consistency group).

As cópias podem ser criadas a partir de qualquer cópia, em qualquer nível ou extensão da hierarquia.

A exclusão de um volume ou de qualquer XVC não afeta a cópia filha ou o volume/XVC pai.

O sistema fornece desempenho previsível e consistente em volumes de produção ou em qualquer cópia.

Os volumes de produção podem ser facilmente restaurados a partir de qualquer uma das imagens de cópia de backup.

Ambientes de teste e desenvolvimento podem ser facilmente atualizados com novas informações, preservando todas as informações SCSI (portanto, eliminando a necessidade de examinar novamente o barramento SCSI no host).

*As XVCs criadas como somente leitura são imutáveis. Para obter acesso de gravação a uma cópia somente leitura, é necessário criar uma nova cópia R/W a partir da cópia somente leitura de origem.


Comparação A Tabela 1 compara algumas das principais diferenças entre as várias tecnologias de cópia e as XtremIO Virtual Copies.

Tabela 1: Tecnologias legadas de cópia em comparação às XtremIO Virtual Copies

Copy-on-Write Redirect-on-Write Clones FULL XtremIO Virtual Copies

Dados com economia de espaço

Sim Sim Não Sim + redução de dados em linha

Metadados com economia de espaço

Não Não Não Sim

Metadados de snapshots e de volumes

Metadados distribuídos a partir de disco e de memória.



Metadados sempre 100% em memória.

Tempo de criação

Instantâneo Instantâneo Muito tempo Instantâneo

Impacto de desempenho na produção

Alto impacto Impacto moderado

Sem impacto após o clone ser concluído

Sem impacto

Desempenho dos snapshots

Degradado Degradado Pode ser igual ao de produção

Igual ao de produção

Exclusões rápidas

Não Não Não Sim

Limitações de exclusão

Limitado Limitado N/D Qualquer cópia na árvore de hierarquia pode ser excluída sem afetar pais ou filhos.

Limitações de topologia

Limitado Pode ser compatível com snapshot em snapshot

Não compatível com snap em snaps

Qualquer topologia

Reserva de espaço na frente

Sim Pode exigir reserva de espaço

Sim Não

Limitações de serviços de dados

Sim Pode limitar serviços de dados

Não Não. Há disponibilidade de serviços de dados completos.


Copy-on-Write Redirect-on-Write Clones FULL XtremIO Virtual Copies

Restauração/atualização instantânea entre qualquer cópia de filho na hierarquia

Não Muito limitado Pode exigir uma nova sincronização e afetar SLAs de produção.

Sim. Restauração/atualização instantânea entre qualquer cópia na topologia.


Vantagens da arquitetura As vantagens da arquitetura da XtremIO Virtual Copies incluem:

O processo de gravação e o desempenho são os mesmos para o volume de produção e suas cópias.

Metadados com uso eficiente de espaço:

A criação de uma cópia virtual não consome metadados.

Os metadados são consumidos apenas para blocos de dados novos e globalmente exclusivos.

Sem impacto sobre o desempenho:

A criação de cópias virtuais não causa nenhum impacto.

O desempenho de leitura é igual em todos os níveis de hierarquia de cópia.

Altamente dimensionável:

Compatível com altos números de cópias.

Compatível com um grande número de consistency groups.

Método “redirect-on-unique-write” aprimorado por redução de dados em linha:

Consome espaço apenas para blocos de dados novos e globalmente exclusivos.

Não há movimentação física de dados em novas gravações.

Sem ajuste, sem otimização e com uma distribuição constante e uniforme de recursos do sistema:

Todas as controladoras de armazenamento no cluster estão constantemente envolvidas no gerenciamento do fluxo de dados de I/O e de metadados, independentemente do tipo de entidade.

Mais potência de CPU e memória permanecem disponíveis (por meio de uma única controladora em relação a várias controladoras).

Provisionamento de uma distribuição uniforme e consistente da carga de trabalho em todos os recursos disponíveis.

Otimizado para memória flash:

As XtremIO Virtual Copies são otimizadas para durabilidade máxima do flash.

Nenhuma movimentação de dados é gerada na criação de cópias ou durante gravações.

A redução de dados em linha fornece valor agregado à eficiência da capacidade e à durabilidade de flash.


Há benefícios adicionais oferecidos com a mídia flash (em termos de desempenho).

O sistema fornece utilização da capacidade e metadados eficientes.


A tecnologia de cópias virtuais do XtremIO é implementada mediante o aproveitamento dos recursos de endereçamento de conteúdo do array juntamente com metadados em memória, e com os metadados de duas etapas e otimizados para mídia SSD do sistema (que fornecem redução de dados em linha), com uma estrutura exclusiva em árvore de metadados que direciona os I/Os para o registro correto de data e hora dos dados. Esse aproveitamento possibilita uma tecnologia eficiente de cópia que sustenta alto desempenho enquanto maximiza a resistência da mídia, tanto em termos de capacidade de criar várias cópias quanto em termos de quantidade de I/Os que um snapshot pode comportar.

Figura 6: mapeamento de endereço para conteúdo

A Figura 6 é um diagrama de volumes lógicos, mostrando que o endereço de cada bloco gravado está associado a uma impressão digital. Portanto, esse mapeamento é chamado de mapeamento de endereço para conteúdo. Adicionalmente, existe um mapeamento individual de metadados do conteúdo para os blocos físicos reais exclusivos que são gravados nos SSDs (formando assim a estrutura de metadados em duas etapas).

Como cada volume ou cópia virtual do XtremIO tem provisionamento thin, os endereços que não foram gravados permanecem vazios e não ocupam espaço de metadados (ou de dados). Portanto, o provisionamento thin do XtremIO tem 100% de eficiência de espaço.

Ao criar uma cópia virtual, o sistema gera um indicador para os metadados ancestrais do volume real no cluster. Portanto, a criação de uma cópia é uma operação muito rápida, que não tem impacto sobre o cluster e não consome capacidade física ou lógica. Portanto, não afeta o SLA de produção. O consumo de capacidade de cópia virtual ocorre apenas se uma alteração exigir gravação de um novo block.


Figura 7: XtremIO Virtual Copies


Quando uma cópia é criada, os metadados existentes do volume se tornam uma entidade “ancestral” que é compartilhada entre o volume de produção e a cópia. Novos contêineres vazios são criados para alterações subsequentes no volume de produção e no volume da cópia virtual. Portanto, o ato de criar uma cópia é instantâneo e não envolve nenhuma cópia de dados ou metadados.

Quando um novo bloco é gravado no ancestral, o sistema atualiza os metadados do volume ancestral para refletir a nova gravação, armazenando o block no cluster. Isso é feito usando o processo padrão de fluxo de gravação. Enquanto esse bloco for compartilhado entre as cópias e o volume ancestral, ele não será excluído do cluster após uma gravação. Isso se aplica tanto a uma gravação em um novo local no volume (um LBA não utilizado) quanto a uma gravação em um local já gravado.

O cluster gerencia os metadados da cópia e os metadados do ancestral por meio de uma estrutura em árvore.

A Figura 8 exibe a cópia e os volumes ancestrais, representados como “folhas” dessa estrutura.

Figura 8: estrutura em árvore de metadados

Os metadados são compartilhados entre todas as cópias que permanecem inalteradas (a partir do ancestral original da cópia). A cópia mantém metadados exclusivos apenas para um LBA com um bloco de dados diferente dos dados existentes, fornecendo assim o gerenciamento econômico de metadados.

Quando uma nova cópia é criada, o cluster sempre cria duas folhas (duas entidades descendentes) a partir da entidade de origem. Uma dessas folhas representa a cópia, a outra torna-se a entidade de origem. O contêiner original dos metadados da


entidade de origem não é mais usado diretamente, mas é mantido no cluster apenas para fins de gerenciamento de metadados (apenas).


A Figura 9 ilustra um volume de 16 blocks no sistema XtremIO. A primeira linha (marcada como A(t0)/S(t0)) mostra o volume no momento da criação da primeira cópia virtual (t0). Em t0, o ancestral (A(t0)) e a cópia (S(t0)) têm os mesmos dados e metadados, porque S(t0) é a cópia somente leitura de A(t0) (contendo os mesmos dados que seu ancestral).

Figura 9: criação de cópias

Obs.: dos 16 blocks, apenas 8 blocks são usados. Os blocks de 0 e 4 consomem apenas um block de capacidade física em função da desduplicação. Os blocks marcados com pontos em branco representam os blocks que são provisionados de modo thin e não consomem capacidade física.

Conforme exibido na Figura 9, antes de criar a cópia virtual em S(t1), dois novos blocos são gravados em P:

H8 sobregrava H2 em LBA 3.


H2 é gravado no LBA D. Os dados não consomem mais capacidade física, pois têm a mesma impressão digital dos dados armazenados em LBA 3 em A(t0) (H2).


S(t1) é uma cópia de leitura/gravação. Ela contém 2 blocos adicionais (em LBA 2 e LBA 3) que são diferentes de sua entidade ancestral de origem.

Diferentemente das implementações tradicionais de snapshots (que reservam espaço para blocks alterados e uma cópia integral dos metadados para cada snapshot), o XtremIO não exige nenhum espaço físico reservado para suas cópias virtuais e nunca tem um “excesso” de metadados. As cópias virtuais só usam esses recursos quando necessário, e os recursos são consumidos a partir do pool de recursos globais do cluster. Não há gerenciamento de pools no XtremIO.

Todas as entidades acessíveis na árvore de cópia que representa o volume, inclusive todas as cópias provenientes desse volume, são gerenciadas por uma entidade chamada VSG (Volume Snapshot Group, grupo de snapshots do volume).

Uma XtremIO Virtual Copy consome metadados apenas para novas gravações (blocks não compartilhados) e utiliza especificamente metadados compartilhados a partir das entidades ancestrais da cópia. Isso permite que o cluster mantenha eficientemente um grande número de cópias usando um espaço adicional muito pequeno de armazenamento, que é dinâmico e proporcional à quantidade de alterações nas entidades.

Por exemplo, na hora t2, os LBAs 0, 3, 4, 6, 8, A, B, D e F são compartilhados com as entidades ancestrais. Apenas o LBA 5 (H6) é exclusivo para essa cópia. Portando, o XtremIO consume apenas uma unidade de metadados. Os blocos restantes são compartilhados com os ancestrais e usam a estrutura de dados dos ancestrais para compilar os dados e a estrutura corretos do volume.

Cópias de vários volumes consistentes entre si

O XtremIO é compatível com a criação de cópias virtuais em um conjunto de volumes. Todas as cópias obtidas a partir dos volumes no conjunto são consistentes entre si. As cópias em um conjunto de volumes podem ser criadas manualmente mediante a seleção de um conjunto de volumes para as operações de cópia ou colocando os volumes em um contêiner de consistency group e criando uma cópia do consistency group. Um conjunto de snapshots (que é um objeto lógico) é criado para se correlacionar com todas as cópias criadas.

O cluster desativa os volumes em microssegundos, garantindo assim que cópias virtuais recém-criadas permaneçam consistentes entre si. Não há nenhum impacto no desempenho do sistema, mesmo quando essa operação é repetida em intervalos curtos. Somente os volumes de origem são desativados durante a operação de criação de cópia virtual.

Para garantir a consistência, o cluster retém temporariamente todas as confirmações de volta aos hosts para todas as gravações feitas nos volumes de origem durante o procedimento de desativação, garantindo assim que nenhuma nova gravação seja


gerada a partir do iniciador durante a desativação. Como resultado, todas as cópias que são criadas são consistentes entre si.


Consistency Groups

O XtremIO permite o agrupamento de vários volumes para proteção de dados e para outros casos de uso. Quando os volumes são colocados juntos em um consistency group, isso permite a criação de uma cópia consistente entre todos os membros do consistency group.

Sempre que houver uma necessidade recorrente de criar cópias de vários volumes, é aconselhável agrupar os vários volumes. O resultado de criação de uma cópia virtual em um consistency group é que cada um dos volumes membros do consistency group cria uma cópia.

Um conjunto de snapshots (que é um objeto lógico) é criado para se correlacionar com todas as cópias criadas.

Quando um volume é adicionado a um consistency group, ele é atribuído a uma posição a (deslocamento). Essa posição é usada durante a restauração e/ou as operações de atualização para fazer a correlação entre o objeto certo a ser atualizado. O deslocamento é mantido dentro do objeto do conjunto de snapshots.

Um volume pode ser membro de vários consistency groups. Consulte o documento atual de notas da versão do XtremIO para obter as informações mais atualizadas sobre os números, restrições e limitações do consistency group.

Snapshot Sets

Sempre que uma cópia virtual é criada, o sistema cria um novo conjunto de snapshots para representar a cópia point-in-time. Isso ocorre independentemente de o objeto de origem se um só volume ou um conjunto de volumes (uma lista de volumes ou um consistency group).

Um conjunto de snapshots é uma representação lógica de um point-in-time específico e mantém todos os volumes recém-criados para apresentar esse point-in-time. Ele pode ser usado para correlações com diferentes volumes criados a partir da mesma operação de criação de cópia.


Bitmap de existência

O storage array do XtremIO tem uma estrutura de dados adicional chamada de bitmap de existência.

Figura 10: Árvore da XtremIO Virtual Copy

A implementação da tecnologia XtremIO Virtual Copy permite a criação de uma cópia de uma cópia sem restrições. Em sistemas que permitem tais cópias em cascata, encontrar o local no qual os dados devem ser recuperados é um desafio que pode afetar o desempenho de leitura. Para cada LBA na cópia, os dados podem ser encontrados no próprio volume do snapshot (nos casos em que o LBA foi gravado depois que a cópia foi criada) ou em um dos seus ancestrais.

O algoritmo nativo para leitura de uma cópia com uso eficiente de espaço deve verificar se os dados foram ou não gravados no próprio volume da cópia; caso contrário, deve verificar seu pai, e assim por diante. Em alguns casos, como quando esse LBA nunca foi gravado, o ancestral original precisa ser localizado, resultando em uma pesquisa demorada. Esse algoritmo tem alta degradação no desempenho em leituras. Além disso, o desempenho é imprevisível, já que depende da extensão da cadeia. Além disso, as cópias que estão longe do volume raiz enfrentam desempenho pior que cópias mais próximas da raiz.

A estrutura de dados e o algoritmo do bitmap de existência otimizam as operações de leitura em cópias com uso eficiente de espaço. O bitmap de existência oferece


desempenho uniforme e previsível para todas as cópias, independentemente da distância delas em relação ao volume raiz.


Há uma estrutura com bitmaps por VSG; um para cada LBA no volume original. O número de bits em cada bitmap é igual ao número máximo de volumes por VSG. Sempre que os dados são gravados em um volume, o bit correspondente a esse volume é definido no bitmap do LBA correspondente, independentemente de ser o volume original ou um snapshot.

O bitmap na Figura 10 (na página 31) mapeia, por LBA, onde o LBA é gravado por cópia. Cada índice no bitmap representa uma cópia. Por exemplo, apenas A(t0) é gravado no LBA 0. Portanto, cada leitura do LBA 0 para cópias criadas após o tempo t1 deve ser atendida pelas informações de metadados armazenadas em A(t0).

Durante a leitura de dados de um LBA específico, primeiro o cluster lê o bitmap associado ao LBA específico (que normalmente se encaixa em uma linha de cache e é muito eficiente). Então a partir do bitmap ele encontra qual volume deve ser acessado para ler os dados. O cluster depois vai diretamente a esse volume para recuperar os dados. Como a manipulação de bitmap é uma operação de baixo custo em termos de desempenho, a profundidade da cópia na cadeia de cópias não afeta o desempenho de leitura ou de gravação.

Exclusões de cópia virtual

As exclusões da XVC são proporcionais apenas à quantidade de blocks alterados entre as entidades. O cluster usa seus recursos que reconhecem conteúdo para manipular exclusões de cópia.

Cada block exclusivo de dados tem um contador que indica o número de instâncias daquele block no cluster. Quando um block é excluído, o valor do contador diminui uma unidade. Qualquer block com valor zero no contador — indicando que não há nenhum LBA nos volumes ou nas cópias no cluster que se refiram a esse block — é sobregravado pelo XDP (XtremIO Data Protection) quando novos dados exclusivos são inseridos no cluster.

A exclusão de uma cópia no meio da árvore aciona um processo que mescla os metadados dos filhos da entidade excluída com os de seus avós. Esse processo garante que a estrutura em árvore não seja fragmentada.

Sem coleta de lixo

Com o XtremIO, cada bloco que precisa ser excluído é imediatamente marcado como “disponível”. Portanto, não há coleta de lixo no SSD e o cluster não precisa executar nenhum processo de varredura para localizar e excluir blocks órfãos.

A implementação das cópias virtuais do XtremIO é totalmente orientada por metadados e aproveita a redução de dados em linha do array para garantir que os dados nunca sejam copiados dentro do array. Portanto, é possível manter muitas cópias simultâneas.


Grupo de snapshot de volumes

Um VSG é uma entidade que representa todas as entidades externas (entidades que podem ser mapeadas) de uma árvore de cópia. Todas as cópias originadas a partir de um único ancestral compartilham o mesmo VSG, que é criado sempre que um novo volume é definido no cluster.

As informações do VSG podem ser visualizadas no painel de propriedades do volume da GUI.

Figura 11: painel de propriedades do volume na GUI

As informações do VSG também podem ser exibidas no índice do VSG usando o seguinte comando de CLI:

show-volumes

show-volume

xmcli (tech)> show-volumes sg-id=8 Volume-Name Index Cluster-Name Index Vol-Size LB-Size VSG-Space-In-Use Offset Created-From-Volume VSG-Index Small-IO-Alerts Unaligned-IO-Alerts CRM1 8 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292016546 131 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292325841 139 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292427812 147 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled xmcli (tech)

Para listar as informações sobre todos os VSGs existentes no cluster, use o seguinte comando de CLI:

show-volume-snapshot-groups


Remoção de gravações de sombra

As gravações no mesmo LBA em um volume, e a gravação de suas cópias, liberam os dados do LBA no ancestral compartilhado da entidade. Isso melhora a utilização do array tanto em termos de consumo de metadados quanto de consumo de capacidade física.

Depois que uma cópia virtual é criada, o resultado é uma estrutura simples com as três entidades a seguir:

A entidade ancestral

A cópia (nova entidade)

Uma nova entidade de produção

No exemplo a seguir, a Figura 12 exibe um volume que está completamente cheio com dados exclusivos não desduplicados e todos os LBA contendo dados.

Observe o impacto no gerenciamento dos dados e metadados na seguinte situação: a cópia é gravada no LBA 4 e, depois de algum tempo, o LBA 4 em produção é sobregravado.

Figura 12: remoção de gravações de sombra


Quando a cópia virtual é inicialmente criada, a produção e a cópia não têm nenhum dado exclusivo. Todas as leituras são fornecidas usando os metadados e os dados da entidade ancestral.

Suponha que as gravações posteriores no LBA 4 foram gravadas para a produção e para a cópia. Agora o LBA 4 ancestral está sombreado pelas atualizações do LBA 4 na cópia e no volume de produção. Portanto, os dados no ancestral não são mais necessários e podem ser descartados do cluster. O cluster libera os metadados relacionados ao LBA 4 e reduz a contagem de referência da impressão digital armazenada no LBA 4. Se essa impressão digital não for usada em nenhum outro lugar do cluster, a impressão digital e o conteúdo correspondente são excluídos do cluster, liberando capacidade física e lógica. A remoção da sombra ocorre de maneira assíncrona, sem afetar o desempenho do cluster.

Recursos de atualização

O XtremIO tem a capacidade de vincular uma identificação SCSI a qualquer entidade na árvore. A atualização do XtremIO é convocada a partir de um comando que cria uma nova cópia e conecta a nova cópia a uma personalidade SCSI existente. Portanto, a operação permite a atualização de qualquer volume mapeado para qualquer uma das cópias na árvore de cópia em memória. O processo de atualização do XtremIO é invocado mediante a execução do seguinte procedimento:

1. Selecione a personalidade SCSI a ser atualizada.

2. Selecione a entidade a partir da qual você deseja atualizar.

3. Defina se a entidade de origem atualizada deve ser descartada ou mantida no sistema.


O seguinte diagrama ilustra o processo de atualização do XtremIO de um volume a partir de uma de suas cópias virtuais.

Presuma um volume conectado a um host e uma cópia virtual conectada a um host diferente.

1. Crie uma nova cópia na cópia que deseja usar como base para a atualização (a cópia original é mantida no sistema).

2. A personalidade SCSI do volume de produção vai para o novo contêiner de dados criado na memória do XtremIO.

3. A personalidade SCSI da cópia é movida para apontar para os outros metadados criados (com base na entidade a partir da qual você deseja atualizar).

4. O sistema exclui ou mantém os dados antigos da entidade atualizada.

O método acima permite uma operação de atualização de qualquer entidade na árvore de cópia virtual para qualquer entidade, sem restrições. O resultado final é que a personalidade SCSI é atualizada com dados a partir da entidade desejada, sem a necessidade de executar o mapeamento ou realizar configurações de barramento SCSI no host para acessar os dados. Isso economiza muito trabalho e tempo de administração.


Diretrizes de atualização

As diretrizes de atualização são as seguintes:

Volumes individuais

Qualquer volume individual ou cópia virtual pode ser atualizado a partir de qualquer volume ou cópia virtual no VSG, sem restrições.

Consistency Groups

Cópias criadas a partir de um consistency group podem ser restauradas ou atualizadas em todas as combinações.

Conjuntos de snapshots

As operações de atualização ou de restauração só são compatíveis em conjuntos de snapshots gerados a partir do mesmo consistency groups ou a partir de outros conjuntos de snapshots criados a partir desse consistency group.

Lista de volumes

Operações de restauração ou de atualização não são compatíveis em conjuntos de snapshots gerados a partir de listas de volumes.

Quando uma operação de atualização é iniciada, um novo conjunto de snapshots é criado e então vinculado às entidades SCSI atualizadas. O novo conjunto de snapshots representa um novo point-in-time que foi criado no sistema. Isso pode apresentar um desafio se você pretende ter um manipulador fixo ou um objeto referenciado destinado ao uso em uma operação de atualização (p. ex., se você deseja executar atualizações diárias). O método para alcançar isso é o uso de uma tag como manipulador fixo para uma operação de atualização. Crie uma tag nos conjuntos de snapshots e então use a opção “Atualizar” na tag. As entidades SCSI atualizadas alteram o nome do conjunto de snapshots. No entanto, a tag é atualizada com o conjunto de snapshots recém-criado, possibilitando o uso de um manipulador fixo.

Tags

O XtremIO é compatível com o uso de tags. As tags podem ser atribuídas a praticamente qualquer tipo de objeto, como a um consistency group, a um conjunto de snapshots, a um volume, a um grupo de iniciadores, a um agendador e mais.

O uso de tags em conjuntos de snapshots é altamente recomendável ao trabalhar com um grande número de objetos ou ao trabalhar com XtremIO Virtual Copies.


Casos de uso

Descarregando as operações de backup

Normalmente as operações de backup podem consumir muitos recursos ambientais ao transferir dados de servidores de aplicativos para servidores de backup ou de mídia, resultando em uma alta utilização de rede, grandes janelas de backup e impactos graves nos aplicativos. Tudo isso são problemas recorrentes e bem conhecidos por administradores de backup e de armazenamento.

As XtremIO Virtual Copies podem ser usadas para descarregar o backup dos dados de produção em um dispositivo de backup externo. O backup pode ser obtido a partir de uma cópia em vez da cópia de produção, liberando assim o processo de mover os dados para um servidor de backup externo.

Outra solução que é habilitada usando as XVC é o ProtectPoint, que aproveita cópias com o RecoverPoint para fazer diretamente o backup dos dados a partir do XtremIO para o DataDomain de maneira eficiente, com reconhecimento e recursos de desduplicação.

Principais benefícios

Os principais benefícios do uso de XVCs para operações de backup incluem:

Criação, atualização e mapeamento imediatos de XVCs usando:

Funcionalidade de atualização instantânea para viabilizar a agilidade dos ciclos de backup.

Economia de tempo em novas varreduras do HBA, útil em cada backup ou servidor de mídia, já que novas verificações dos HBAs tendem a montar centenas de dispositivos.

Cópias com uso eficiente de espaço:

Nenhuma capacidade física ou lógica é reservada ou usada.

Consumo eficiente de memória lógica.

Economia de recursos durante ciclos de backup:

Nenhum recurso de CPU de produção é usado, já que não é necessário fazer backup diretamente a partir do servidor de aplicativos.

Menos recursos de rede, já que o conjunto de backups não é transferido do servidor de aplicativos por meio da LAN.


Figura 13: descarregando uma operação de backup — 00

As cópias de backup podem ser atualizadas instantaneamente a partir da produção com frequência diária ou semanal. O servidor de backup ou de montagem não exige nova varredura no nível do HBA.

Essa abordagem economiza uma enorme quantidade de tempo, já que os servidores de backup geralmente montam centenas de dispositivos na organização.

Criando uma XVC para uso de backup — nos bastidores

Esta seção descreve um exemplo de como criar um backup usando XtremIO Virtual Copies, e o que acontece nos bastidores.

1. O host de produção é mapeado para volumes a partir de “Prod CG”, conforme exibido na Figura 14 (na página 41). A operação de criação de cópia é iniciada a partir de “Prod CG” (feito para criar uma cópia para operações de backup).

2. O conjunto de snapshots recém-criado hospeda as cópias recém-criadas, que então são mapeadas para o host de backup e montadas.

3. Uma tag para o conjunto de snapshots de backup é criada e identificada como “BackupCopyTag”. Essa tag é usada durante a operação de atualização.



Uma operação de backup é — ao menos nos ambientes da maioria dos clientes — uma tarefa diária. Isso significa que a cópia de backup precisa ser atualizados em cada ciclo. As XtremIO Virtual Copy são nativamente compatíveis com esses requisitos. Os comandos para fazer isso podem ser executados manualmente ou facilmente estruturados em scripts por meio da CLI ou usando a API RESTful.

O comando de CLI para criar uma XVC para backup nesta instância é: create-snapshot-and-reassign from ProdCG to BackupCopyTag

A Figura 15 mostra o impacto interno.



Um novo conjunto de snapshots é criado, apontando para os mesmos volumes (eliminando a necessidade de examinar novamente no nível do host).

O novo “SnapshotSet02” permanece marcado com a tag “BackupCopyTag”, que permite a execução do mesmo comando com script durante o próximo ciclo.

O XtremIO preserva automaticamente cópias de “backup/desfazer” dos volumes atualizados. Isso é feito para oferecer recuperação rápida em caso de erro humano. Essa cópia de “backup/desfazer” está localizada no conjunto de snapshots antigo no exemplo “Snapshot Set01”. Esse conjunto de snapshots pode ser excluído manualmente ou ser excluído por argumento, usando o comando “no-backup”.

Casos de uso de teste e desenvolvimento

As XtremIO Virtual Copies podem ser aproveitadas para oferecer cópias de teste e desenvolvimento dos dados de produção. É possível criar várias cópias mestras, e cada cópia pode ser processada (como um processo de anonimização ou de saneamento) para ser preparada como uma imagem de ouro para fins de desenvolvimento e teste. Então é possível criar várias cópias a partir de cada cópia mestra e apresentá-las a várias equipes de desenvolvimento. O provisionamento de mais cópias é um processo fácil e instantâneo, e também é possível criar ainda mais cópias das cópias provisionadas.

A eficiência das XVCs permite que as cópias sejam criadas com base na demanda para eficiência máxima de negócios, em vez de se basear nas limitações de desempenho ou capacidade de armazenamento.


Figura 16: casos de uso de teste e desenvolvimento

Além disso, o processo fácil de atualização do XtremIO possibilita uma atualização instantânea dos ambientes de desenvolvimento.

O layout de árvore na Figura 17 mostra que o ambiente de cópia (snapshot) para “DevTeam1” está criado. Uma cópia instantânea da produção é criada e então mapeada para o servidor DevTeam1.

O ambiente de produção não sofre impacto da operação, durante a qual “SnashotSet01” é criado contendo a cópia dos volumes que estão visíveis para o servidor DevTeam1.

É recomendável marcar SnapshotSet01 para apontar para a cópia para desenvolvimento recém-criada, usando a tag “DevTeam1”.

Figura 17: criação do ambiente de desenvolvimento para DevTeam1

As equipes de teste e desenvolvimento ganham um valor extremamente alto das operações de atualização. Atualizar uma cópia de desenvolvimento a partir de uma cópia mestre nunca foi tão fácil ou tão realizável de maneira tão instantânea.

Uma única chamada de API RESTful, ou um único comando de CLI (ou Assistente de GUI) permite a execução da tarefa.

O comando CLI para criar uma XVC para teste e desenvolvimento nesta instância é: create-snapshot-and-reassign from ProdCG to DevTeam1


Figura 18: criação de ambiente adicional de desenvolvimento para DevTeam2

O ambiente de desenvolvimento para team1 é atualizado instantaneamente a partir da cópia de produção. A operação também preserva todas as informações de LUN para eliminar nova verificação dos HBAs no nível do host.

Sob uma perspectiva de proteção, os volumes de “backup/desfazer” são mantidos em caso de erro humano ou em caso de necessidade de uma reversão pelo usuário. A cópia de backup sempre é mantida no conjunto de snapshots antigo (“SnapshotSet01” no exemplo acima). A cópia de backup só pode ser removida se não for mais necessária.

P XtremIO permite ter cerca de 512 cópias a partir de um volume de produção, atendendo assim aos requisitos dos clientes mais exigentes.

A tag Devteam1 permite uma fácil repetição desse procedimento ou de seu scripting para uso automático.

Qualquer outra cópia no ciclo de vida de desenvolvimento, como controle de qualidade, pré-produção, teste, etc., também pode ser identificada por uma tag.

A operação de atualização pode ser facilmente executada entre tags, bem como ser executada a partir de uma marca para um consistency group.



Os principais benefícios do uso de XVCs para operações de teste e desenvolvimento incluem:

Extrema agilidade para atender ao ciclo de vida de desenvolvimento.


Os recursos são apropriados apenas para novas gravações.

Nenhuma capacidade física ou lógica é reservada.

É possível criar dezenas de cópias de teste e desenvolvimento, criando um sandbox de alto desempenho para cada engenheiro possível com uma operação que não consome tempo.

Atualização rápida dos ambientes de teste e desenvolvimento.

Desduplicação, compactação e provisionamento thin sempre são permitidos.

Compatibilidade com cópias de cópias.

Proteção de dados lógicos

É possível criar cópias dos volumes de produção para a proteção contra corrupção de dados lógicos. É possível criar várias cópias em um curto intervalo para fornecer um bom RPO (Recovery Point Objective, objetivo de ponto de recuperação) de maneira cíclica (um RPO superior para um backup).

Por exemplo, é possível criar 48 cópias a cada 30 minutos e excluir a cópia mais recente. Isso fornece um RPO de 30 minutos para o último dia de alterações de produção.

Figura 19: várias cópias point-in-time para proteção de dados lógicos


Políticas flexíveis de retenção podem ser facilmente configuradas usando o agendador integrado do XtremIO, de intervalos explícitos a retenções semanais e diárias. As cópias padrão de backup são criadas como somente leitura (imutáveis).


Isso traz automatização para o campo de backup e elimina a necessidade de scripting externo. As XVCs criadas usando o agendador integrado são apenas cópias consistentes em caso de falhas. Se for necessário ter cópias com reconhecimento de aplicativos, o AppSync da EMC pode fornecer recursos de agendamento compatíveis com reconhecimento de aplicativos.

Figura 20: janela de configuração do agendador

O fluxo de restauração atende ao tema do agendador, permitindo que as operações de restauração sejam feitas somente a partir de cópias “somente leitura” (o fluxo de atualização permite o uso de qualquer grupo de snapshots como origem).


Figura 21: fluxo de restauração

Descarregando o processamento e a lógica analítica de dados

As XtremIO Virtual Copies também podem ser usadas para oferecer lógica analítica em tempo real, permitindo assim que os usuários executem as seguintes ações:

Descarregar o processamento em um servidor externo.

Processos ETL (Extract, transform and load, extrair, transformar e carregar) para carregar dados em um data warehouse.

Obter lógica analítica quase em tempo real para relatórios do Business Intelligence (BI).

Consolidar OLTP (Online Transaction Processing) e tempo real em uma só plataforma.

Figura 22: descarregar o processamento e a lógica analítica de dados



Os principais benefícios do uso de XVCs para descarregar o processamento e a lógica analítica de dados incluem:

Cópias de produção atualizadas imediatamente sem a necessidade de fazer uma SAN copy de força bruta

Consolidação de diferentes cargas de trabalho em uma só plataforma de scale-out totalmente flash, com desempenho consistente e previsível

Lógica analítica de Business Intelligence precisa e em tempo real com base na cópia mais atualizada dos dados de produção


Nenhuma capacidade física ou lógica é reservada ou usada nas cópias.

Desduplicação e provisionamento thin estão sempre ativados

A cópia da cópia sempre contém apenas um delta exclusivo.

Descarga de processamento a partir do servidor de produção:

Recursos de SAN BW/IOPS disponíveis

Recursos de CPU disponíveis

Recursos de rede DISPONÍVEIS

Alto desempenho em cópias de produção


Provisionamento de VMs em massa usando a tecnologia XVC em um VMFS (Virtual Machine File System)

A obtenção de XVCs a partir de um volume VMFS que contém várias máquinas virtuais provou ser o método mais rápido de clonagem de VMs. Esse método é muito mais rápido do que qualquer outra alternativa, como o método VAAI XCOPY.

Figura 23: criação de clones nativos para VM

A Figura 23 apresenta um exemplo de um clone nativo criado para uma VM empregando o uso dos recursos XVC, diminuindo o tempo de operação para uma questão de segundos.

Para facilitar para os administradores de VMware, a EMC oferece o plug-in gratuito VSI for VMware Virtual Center.

O plug-in VSI permite o gerenciamento integrado do XtremIO a partir do Virtual Center enquanto acrescenta os seguintes benefícios adicionais:

Gerenciamento e monitoramento integrados do XtremIO

Operações automatizadas de restauração/atualização no nível de VM e de datastore

Aplicação de práticas recomendadas do XtremIO para uma infraestrutura ESXi

Suporte a implementações de VDI (para Citrix e View)


Provisionamento rápido de VMs em grande escala

Clonagem com uso eficiente de espaço de VMs


Conclusão A tecnologia XtremIO Virtual Copies oferece um grande número de cópias somente leitura ou graváveis com alto desempenho e baixa latência.

As XtremIO Virtual Copies são eficientes no uso de metadados e de espaço físico, podem ser criadas instantaneamente, não têm impacto no desempenho e têm os mesmos serviços de dados que qualquer outro volume no cluster (como provisionamento thin e redução de dados em linha).

As XVCs são fáceis de usar e de gerenciar, e aproveitam um mecanismo sofisticado de gerenciamento de metadados que oferece o melhor suporte para mídia flash, permitindo um processo de cópia com alto desempenho.

A tecnologia XVC apresenta uma base crucial para fornecer recursos de gerenciamento integrado de dados de cópia, permitindo assim que os clientes consolidem cargas de trabalho nível 1 de produção e fora de produção em uma plataforma de scale-out com desempenho previsível e consistente.

As XVCs podem ser usadas para teste e desenvolvimento, backups, operação, proteção de dados e lógica analítica em tempo praticamente real.

INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES · Introdução à XtremIO Virtual Copies ......

Documents

Transcript of INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES · Introdução à XtremIO Virtual Copies ......