INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES

Transcrição

1 White paper INTRODUÇÃO À TECNOLOGIA XtremIO VIRTUAL COPIES 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

2 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 H (Rev. 02) 2

3 Índice Resumo executivo... 5 Snapshots convencionais... 7 Gerenciamento de volume convencional... 7 Snapshots do Copy-on-Write... 7 Snapshots Redirect-on-Write Outras tecnologias de cópia Snapshots convencionais - eficiência e desempenho Casos de uso de snapshots legados Introdução à XtremIO Virtual Copies Criando cópias com a tecnologia XtremIO Virtual Copies Recursos Comparação Vantagens da arquitetura Cópias de vários volumes consistentes entre si Consistency Groups Snapshot Sets Bitmap de existência Exclusões de cópia virtual Sem coleta de lixo Grupo de snapshot de volumes Remoção de gravações de sombra Recursos de atualização Diretrizes de atualização Tags Casos de uso Descarregando as operações de backup Principais benefícios Criando uma XVC para uso de backup nos bastidores Casos de uso de teste e desenvolvimento Principais benefícios Proteção de dados lógicos Descarregando o processamento e a lógica analítica de dados Principais benefícios Provisionamento de VMs em massa usando a tecnologia XVC em um VMFS (Virtual Machine File System)

4 Conclusão

5 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). 5

6 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. 6

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

8 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. 8

9 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. 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. Desvantagem: As topologias complexas de snapshot sofrem degradação grave no desempenho. Figura 3: Copy-on-Write leitura no host 9

10 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). 10

11 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. 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. 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. Figura 5: Redirect-on-Write leitura no host 11

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

13 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. 13

14 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. 14

15 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. 15

16 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. 16

17 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. 17

18 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 Metadados com economia de espaço Metadados de snapshots e de volumes Tempo de criação Impacto de desempenho na produção Desempenho dos snapshots Exclusões rápidas Limitações de exclusão Limitações de topologia Reserva de espaço na frente Limitações de serviços de dados Sim Sim Não Sim + redução de dados em linha Não Não Não Sim Metadados distribuídos a partir de disco e de memória. Metadados distribuídos a partir de disco e de memória. Metadados distribuídos a partir de disco e de memória. Metadados sempre 100% em memória. Instantâneo Instantâneo Muito tempo Instantâneo Alto impacto Impacto moderado Sem impacto após o clone ser concluído Degradado Degradado Pode ser igual ao de produção Não Não Não Sim Sem impacto Igual ao de produção Limitado Limitado N/D Qualquer cópia na árvore de hierarquia pode ser excluída sem afetar pais ou filhos. Limitado Sim Sim Pode ser compatível com snapshot em snapshot Pode exigir reserva de espaço Pode limitar serviços de dados Não compatível com snap em snaps Sim Não Qualquer topologia Não Não. Há disponibilidade de serviços de dados completos. 18

19 Copy-on-Write Redirect-on-Write Clones FULL XtremIO Virtual Copies Restauração/at ualizaçã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/atua lização instantânea entre qualquer cópia na topologia. 19

20 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. 20

21 Há benefícios adicionais oferecidos com a mídia flash (em termos de desempenho). O sistema fornece utilização da capacidade e metadados eficientes. 21

22 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. 22

23 Figura 7: XtremIO Virtual Copies 23

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

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

26 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. 26

27 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). 27

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

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

30 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-intime. Ele pode ser usado para correlações com diferentes volumes criados a partir da mesma operação de criação de cópia. 30

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

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

33 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. 33

34 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 xbrickdrm G G 0 CRM1 8 disabled disabled CRM xbrickdrm G G 0 CRM1 8 disabled disabled CRM xbrickdrm G G 0 CRM1 8 disabled disabled CRM xbrickdrm G G 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 34

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

36 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. 36

37 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. 37

38 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. 38

39 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. 39

40 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. 40

41 Figura 14: descarregando uma operação de backup 01 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. Figura 15: descarregando uma operação de backup 02 41

42 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. 42

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

44 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. 44

45 Principais benefícios 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. Cópias com uso eficiente de espaço: 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 45

46 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). 46

47 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). 47

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

49 Principais benefícios 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 scaleout 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 Cópias com uso eficiente de espaç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 49

50 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) 50