ATUALIZAÇÃO DE SNAPSHOT DO XTREMIO PARA PRODUÇÃO, DESENVOLVIMENTO E TESTE DE UM BANCO DE DADOS ORACLE

Transcrição

1 ATUALIZAÇÃO DE SNAPSHOT DO XTREMIO PARA PRODUÇÃO, DESENVOLVIMENTO E TESTE DE UM BANCO DE DADOS ORACLE Uma análise do recurso de atualização de snapshot do XtremIO RESUMO Este white paper apresenta uma ampla visão sobre como a tecnologia de snapshot do XtremIO, combinada com atualização de snapshot versão 4.0, muda o modo de o provisionamento de dados ser tratado em tempo hábil para grupos de desenvolvimento e de teste dentro da organização. Janeiro 2016 WHITE PAPER DA EMC

2 Para saber mais sobre como os produtos, serviços e soluções da EMC ajudam a resolver seus desafios de negócios e de TI, entre em contato com seu representante local ou revendedor autorizado, acesse nosso site brazil.emc.com ou explore e compare produtos na EMC Store. Copyright 2015 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 contidas 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. Todas as marcas comerciais aqui mencionadas pertencem a seus respectivos proprietários. Número da peça H

3 ÍNDICE SUMÁRIO EXECUTIVO... 5 PÚBLICO-ALVO... 5 INTRODUÇÃO... 5 VERSÃO 4.0 DO XTREMIO, RECURSO DE ATUALIZAÇÃO DE SNAPSHOT DA VERSÃO SNAPSHOTS DO XTREMIO EM COMPARAÇÃO ÀS OFERTAS DA CONCORRÊNCIA... 7 SNAPSHOTS DE ARMAZENAMENTO DO EXADATA... 7 ATUALIZAÇÃO DE SNAPSHOTS DO XTREMIO PARA PANORAMAS DE TESTE E DESENVOLVIMENTO DE ORACLE... 8 VISÃO GERAL DA ARQUITETURA DA SOLUÇÃO... 8 NÃO USE MAIS CÓPIAS COMPLETAS DE BANCOS DE DADOS PARA TESTE E DESENVOLVIMENTO... 8 PROVISIONAMENTO DE SNAPSHOT DE PRODUÇÃO PARA DESENVOLVIMENTO PARA TESTE/DESENVOLVIMENTO ORACLE... 9 SNAPSHOTS CONSISTENTES EM CASO DE FALHAS PARA BANCO DE DADOS ORACLE... 9 VISÃO GERAL FUNCIONAL PARA PROVISIONAMENTO DE ARMAZENAMENTO DE PRODUÇÃO PARA DESENVOLVIMENTO DO XTREMIO GRUPO DE SNAPSHOTS DE VOLUME DO XtremIO XTREMIO ARRAY DE PRODUÇÃO, TESTE E DESENVOLVIMENTO DO BANCO DE DADOS ORACLE: UM ESTUDO DE CASO SNAPSHOTS GRAVÁVEIS COM ECONOMIA DE ESPAÇO DE PRODUÇÃO PARA TESTE E DESENVOLVIMENTO ANÁLISE DE CRONOGRAMA ATUALIZAÇÃO DE DESENVOLVIMENTO GOLD PELA PRODUÇÃO TEXTO DESCRITIVO DO CRONOGRAMA

4 ATUALIZAÇÃO DE SNAPSHOT DE DESENVOLVIMENTO GOLD DA PRODUÇÃO ANÁLISE DE CRONOGRAMA ATUALIZANDO O CONJUNTO DE SNAPSHOTS DE DESENVOLVIMENTO GOLD PARA O ESTADO DE BANCO DE DADOS DE PRODUÇÃO ATUAL RESUMO DO CRONOGRAMA ESTUDO DE CASO ANÁLISE DE USO DO ARMAZENAMENTO DE DESENVOLVIMENTO E PRODUÇÃO UTILIZAÇÃO DO ARMAZENAMENTO UMA ANÁLISE DETALHADA USO DO ESPAÇO INICIAL DO XtremIO UTILIZAÇÃO DO ESPAÇO DEPOIS DA CRIAÇÃO DO BANCO DE DADOS DE PRODUÇÃO RECONCILIANDO UM ESPAÇO ASM USANDO GERAÇÃO DE RELATÓRIOS COM RELATÓRIOS DE USO DE ESPAÇO DO XtremIO SOBRE O ESPAÇO LIVRE DO ASM USO DO ESPAÇO DEPOIS DA DEVOLUÇÃO DO ESPAÇO LIVRE DO ASM PARA O ARRAY USANDO O UTILITÁRIO DE RECUPERAÇÃO DE ESPAÇO DO ASM PARA DEVOLUÇÃO DE ESPAÇO ASM NÃO UTILIZADO PARA O ARRAY USO DO ESPAÇO APÓS O MASCARAMENTO DE DADOS DO SNAPSHOTS DE DESENVOLVIMENTO GOLD SOBRE OS NOMES DO GRUPO DE DISCOS DO ASM COM SNAPSHOTS DO XtremIO USO DE ESPAÇO COM TODOS OS BANCOS DE DADOS ATIVOS EM CONJUNTOS DE SNAPSHOTS GRAVÁVEIS USO DO ESPAÇO DEPOIS DE O DESENVOLVEDOR ATUALIZAR CONJUNTOS DE SNAPSHOTS PARA CONJUNTOS DE SNAPSHOT DE DESENVOLVIMENTO GOLD.. 26 RESUMO DO USO DE ESPAÇO INTERFACE GRÁFICA DO USUÁRIO DO XTREMIO GERENCIAMENTO DO GRUPO DE SNAPSHOT DE VOLUME RESUMO DO ESTUDO DE CASO

5 SUMÁRIO EXECUTIVO Todos os ambientes de bancos de dados Oracle exigem cópias de bancos de dados para esses fins como lógica analítica e geração de relatórios off-hosting, desenvolvimento, testes, garantia de qualidade e testes de aceitação do usuário. A cópia dos bancos de dados Oracle tem um custo significativo, tanto em termos de tempo de processamento quanto em requisitos de armazenamento adicionados. Como resultado, a maioria dos ambientes Oracle atuais precisam confiar em soluções que exigem pelo menos algumas cópias completas dos bancos de dados. Com o XtremIO, agora você não precisa mais copiar fisicamente bancos de dados. Este white paper foi escrito para administradores de banco de dados Oracle. Seu objetivo é garantir que o leitor entenda como os snapshots do XtremIO podem ser aproveitados para resolver todos os problemas associados ao provisionamento de cópias oportunas e com uso eficiente de espaço de bancos de dados mascarados 1 para desenvolvimento, teste, garantia de qualidade e outras atividades empresariais relacionadas ao Oracle. A seguir, uma sinopse das seções principais deste white paper: Uma introdução aos snapshots do XtremIO e ao novo recurso de atualização de snapshot do XtremIO versão 4.0. Uma comparação da solução de snapshots do XtremIO a outras soluções de snapshot do setor. Uma introdução detalhada da funcionalidade de atualização de snapshots do XtremIO para provisionamento de bancos de dados Oracle mascarados de produção para hosts de desenvolvimento e teste. Esta seção inclui um estudo de caso, com foco nos aspectos de administração do banco de dados Oracle relacionados à atualização de snapshots do XtremIO. Uma descrição detalhada das características de uso de espaço do XtremIO e do Oracle Automatic Storage Management, relacionadas a snapshots do XtremIO observados durante o estudo de caso. Este white paper demonstra as capacidades exclusivas da funcionalidade de snapshots do XtremIO versão 4.0 para eliminar por completo os problemas de cópia de banco de dados com os quais os atuais clientes corporativos da Oracle precisam lidar. Com a funcionalidade de atualização de snapshots do XtremIO versão 4.0, o XtremIO atinge níveis inalcançáveis em qualquer outra plataforma para gerenciamento de dados de cópia. PÚBLICO-ALVO Este white paper é destinado a profissionais de banco de dados Oracle, que estão familiarizados com os desafios de manter panoramas complexos de armazenamento e de host que abrangem produção, teste e desenvolvimento. INTRODUÇÃO Os snapshots do XtremIO são criados capturando o estado dos dados nos volumes em um terminado point-in-time e permitindo que os usuários acessem esses dados quando necessário, mesmo quando o volume de origem foi alterado. Os snapshots do XtremIO são inerentemente graváveis, mas podem ser criados como somente leitura para manter a imutabilidade. Os snapshots podem ser criados por meio de volumes ou de outros snapshots. Os snapshots do XtremIO são tratados como volumes padrão e se beneficiam dos mesmos serviços de dados e do desempenho dos volumes. A arquitetura de scale-out do XtremIO garante que, mesmo com um enorme número de snapshots graváveis em uso, o desempenho continua a ser previsível. Os snapshots podem ser empregados em vários casos de uso, entre eles: Desenvolvimento e teste o XtremIO permite que o administrador crie snapshots dos dados de produção, crie várias cópias (com economia de espaço e alto desempenho) do sistema de produção e apresente-as para fins de desenvolvimento e teste. Backup é possível criar snapshots para serem apresentados a um servidor/agente de backup e usados para liberar o processo de backup do servidor de produção, sem afetar o desempenho de produção. Descarregar processamento e dados os snapshots podem ser utilizados como meio de descarregar o processamento de dados do servidor de produção. Por exemplo, se existir a necessidade de executar um processo pesado nos dados (o que pode afetar o desempenho do servidor de produção), é possível usar os snapshots para criar uma cópia recente dos dados de produção e montá-la em outro servidor. O processo pode, então, ser executado (no outro servidor), sem consumir os recursos do servidor de produção. O XtremIO é compatível com um enorme número de snapshots. Na versão atual, 512 snapshots por volume e snapshots por array são compatíveis. Para obter mais informações sobre a funcionalidade de snapshots do XtremIO em geral, consulte xtremio.com/snapshot. Para obter uma análise detalhada de snapshots do XtremIO no caso de uso do Oracle em grande escala, consulte o seguinte white paper da EMC: 1 O termo mascaramento é usado neste paper apenas no sentido genérico. Não há produtos de mascaramento de dados comerciais considerados neste estudo de caso. 5

6 VERSÃO 4.0 DO XtremIO, RECURSO DE ATUALIZAÇÃO DE SNAPSHOT DA VERSÃO 4.0 O lançamento da versão 4.0 do storage array XtremIO aprimora os recursos existentes de snapshot do XtremIO dando suporte à atualização de snapshot e à funcionalidade de atualização de volume. A criação de snapshots da versão 4.0 do XtremIO permanece imediata e consistente em caso de falhas e não exige nenhuma sobrecarga de espaço de armazenamento. Além disso, a versão 4.0 introduz a funcionalidade de consistency group para operações de snapshot. Por isso, o XtremIO é considerado uma plataforma inovadora para provisionamento de snapshots graváveis com uso eficiente de espaço de bancos de dados de produção para organizações de teste e desenvolvimento. Os snapshots podem ser criados independentemente se houver bancos de dados em execução com arquivos abertos nos volumes de origem (ou snapshots). Para complementar a natureza não invasiva da criação do Snapshot, as operações de atualização são imediatas e consistentes em caso de falhas e não há sobrecarga de espaço de armazenamento. Além disso, as operações de atualização não afetam os atributos de SCSI de nível de host (por exemplo, NAA). Isso significa que, por meio de comandos simples do XtremIO (GUI, CLI ou API REST), os administradores podem imediatamente atualizar o conteúdo de um volume ou um snapshot sem necessidade de qualquer ação de administração de sistema relacionada à LUN do nível de host. Os volumes podem ser atualizados por meio de snapshots ou restaurados por meio de snapshots somente leitura. Por outro lado, os snapshots, podem ser atualizados por meio de outros snapshots ou volumes. Essa flexibilidade apresenta maneiras novas e eficientes para resolver um problema antigo no ambiente de banco de dados Oracle: como provisionar os dados corretos para organizações de teste e desenvolvimento de maneira eficiente e em tempo hábil. O foco principal deste artigo é o provisionamento de volumes de snapshots do XtremIO que contêm bancos de dados Oracle de produção para outros hosts, com a finalidade de atividades de teste e desenvolvimento. O valor dessa solução é a eficiência de espaço significativa e a economia de tempo. 6

7 SNAPSHOTS DO XtremIO EM COMPARAÇÃO ÀS OFERTAS DA CONCORRÊNCIA O caso de uso para o provisionamento de bancos de dados Oracle mascarados de produção para teste e desenvolvimento é muito popular. Muitos fornecedores de armazenamento estão oferecendo soluções para lidar com esse mercado importante. A maioria das soluções, oferecidas por outros fornecedores de armazenamento, não tem a riqueza dos snapshots do XtremIO com a atualização de snapshots. Diferentemente dos snapshots do XtremIO, a maioria dos fornecedores exige a criação de uma cópia completa do banco de dados de produção, que se tornará o doador de snapshot. A criação de cópias completas de produção para fins de provisionamento de dados para desenvolvedores é insustentável. O aumento de I/O durante a operação de cópia geralmente requer uma janela de manutenção. Isso, por sua vez, limita a frequência na qual as atualizações podem ocorrer. Além disso,o uso ineficiente de espaço para um doador de cópia completa é algo que os departamentos de TI atuais com preocupação com os custos simplesmente não podem custear. SNAPSHOTS DE ARMAZENAMENTO DO EXADATA Um bom exemplo de uma solução de tecnologia que exige um doador um snapshot de cópia completa é o recurso de snapshots de armazenamento do Oracle Exadata da Oracle Exadata Database Machine 12c. Esse recurso funciona somente com armazenamento do Exadata. A documentação do Oracle 2 estipula o requisito de doador um snapshot de cópia completa no seguinte trecho: Um snapshot do Exadata baseia-se em um mestre de teste, que é um clone completo do banco de dados de origem. O mestre de teste é a única cópia completa do banco de dados de origem. A partir de um mestre de teste único, você pode criar vários snapshots de Exadata com o mínimo de armazenamento adicional e o mínimo de esforço. Cada snapshot do Exadata usa uma pequena fração do espaço em disco necessário para o mestre de teste e pode ser criado ou descartado em segundos. A Figura 1 mostra uma cópia em destaque do gráfico na documentação do Oracle que abrange snapshots de armazenamento do Exadata. Figura 1. Snapshots de armazenamento do Exadata exigem uma cópia de banco de dados completa Outra limitação documentada importante de snapshots de servidor de armazenamento do Exadata é o requisito de que todos os hosts usando os snapshots devem ser membros do mesmo cluster de ASM do Oracle conforme a citação abaixo: O banco de dados mestre de teste e seus snapshots Exadata devem estar no mesmo ambiente de cluster do ASM. Exigir que os hosts sejam membros do mesmo cluster do ASM apenas para permitir o uso de snapshots força os clientes a implementar configurações Exadata mais caras e em maior quantidade. Em comparação a isso, snapshots de armazenamento do XtremIO são baseados em array, permitindo que os hosts que usam os snapshots sejam físicos ou virtuais e não tenham as restrições de associação do cluster. Em um ambiente do XtremIO, os arquitetos de TI têm a liberdade de escolher qualquer servidor que se enquadre em suas necessidades e em seu orçamento. O restante deste white paper descreve um estudo de caso destacando como o XtremIO permite fazer escolhas prudentes de TI

8 ATUALIZAÇÃO DE SNAPSHOTS DO XtremIO PARA PANORAMAS DE TESTE E DESENVOLVIMENTO DE ORACLE VISÃO GERAL DA ARQUITETURA DA SOLUÇÃO Em ambientes de banco de dados Oracle modernos, a equipe de desenvolvimento e teste não pode executar suas tarefas vitais com cópias de fax de baixa qualidade, obsoletas e atualizadas pouca frequência dos bancos de dados de produção para os quais ela cria aplicativos. Os desenvolvedores modernos precisam ser capazes de atualizar com frequência sua sandbox de desenvolvimento e os administradores precisam ser capazes de avançar com cópias mascaradas do banco de dados de produção sem cópia de arquivos. NÃO USE MAIS CÓPIAS COMPLETAS DE BANCOS DE DADOS PARA TESTE E DESENVOLVIMENTO A cópia de bancos de dados é um problema sério, ainda predominante em ambientes de banco de dados Oracle, para o qual os snapshots do XtremIO são a solução. Como mencionado acima, os snapshots do XtremIO são criados imediatamente, não precisam de nenhum espaço de armazenamento e podem ser criados mesmo que haja bancos de dados Oracle em execução envolvidos. Contudo, um snapshot não será tão útil se ele não puder ser facilmente acessado e usado por outros hosts. Portanto, é importante entender o mecanismo de atualização de snapshots do XtremIO do ponto de vista do DBA Oracle. O fluxo de trabalho para a atualização de snapshots do XtremIO, que contêm arquivos de banco de dados Oracle, consiste nestas cinco etapas simples: 1. Desligue as instâncias de banco de dados com os arquivos no conjunto de snapshots de destino. 2. Desmonte o grupo de discos ASM (ou file system) envolvido. 3. Atualize o snapshot por meio da GUI do XtremIO (ou da CLI ou da API RESTful). 4. Monte os grupos de discos ASM (ou file system) envolvidos. 5. Inicie as instâncias de banco de dados. Todo o workflow é medido em segundos (não em minutos). Para esclarecer esse ponto, este documento oferece um estudo de caso detalhado da atualização de snapshots do XtremIO envolvendo bancos de dados Oracle. 8

9 PROVISIONAMENTO DE SNAPSHOT DE PRODUÇÃO PARA DESENVOLVIMENTO PARA TESTE/DESENVOLVIMENTO ORACLE Com os arrays tradicionais, o provisionamento de snapshots de bancos de dados de produção para fins de desenvolvimento e teste sequer podia ser cogitado. A tecnologia envolvida não era adequada para a tarefa. De fato, o simples ato de copiar os arquivos de banco de dados de produção para criar um doador de staging (do qual criar snapshots) consumia muito tempo e prejudicava o desempenho. A cópia de dados em arrays tradicionais era um problema, não apenas durante a operação de cópia, mas posteriormente, já que os dados de produção exigem algum nível de mascaramento de dados. Essa tarefa que envolve também uma quantidade significativa de I/O. Por fim, o uso de snapshots resulta na adição de I/O que não pode ser mantida junto com o I/O de produção. Com o XtremIO, por outro lado, a cópia de dados para teste e desenvolvimento é livre, pois os dados nunca são realmente copiados. Em vez disso, os volumes apenas tornam-se snapshots. Também é importante notar que o uso dos Snapshots não tem custos do ponto de vista de desempenho, pois o XtremIO é um array totalmente flash de scale-out. Usar uma combinação de volumes e snapshots é uma opção realista, pois o tempo de serviço permanece constante. Além disso, os serviços de redução de dados em linha do XtremIO também se aplicam a snapshots graváveis. Considere, por exemplo, o mascaramento de dados de produção para uso de teste e desenvolvimento. A menos que o banco de dados inteiro exija mascaramento, haverá eficiência de espaço porque os snapshots do XtremIO não são cópias completas. As partes do banco de dados, armazenadas em um snapshot do XtremIO que não precisam de mascaramento, não consumirão espaço no array. Além disso, como os snapshots graváveis são usados pelos desenvolvedores, as alterações feitas aos snapshots são desduplicadas sempre primeiro e, em seguida, compactadas no armazenamento. SNAPSHOTS CONSISTENTES EM CASO DE FALHAS PARA BANCO DE DADOS ORACLE O princípio fundamental por trás do recurso de atualização de snapshots do XtremIO para desenvolvimento e teste Oracle ágeis é a natureza consistente em caso de falhas da operação de atualização. De modo geral, as cópias de banco de dados de teste e desenvolvimento não precisam ser consistentes com a produção em termos transacionais. Uma imagem recente do banco de dados geralmente é o suficiente. A criação de um snapshot de um volume do XtremIO, usado para ASM ou bancos de dados Oracle baseados em file system, gera uma imagem consistente em caso de falhas. O banco de dados Oracle é particularmente adequado para lidar com imagens consistentes em caso de falhas de dados em disco. Com relação ao banco de dados Oracle, uma imagem consistente em caso de falhas não difere do que é deixado em um disco depois de desligar um host ou encerrar imediatamente todos os caminhos para armazenamento. Os bancos de dados Oracle lidam facilmente com recuperação de instância desses eventos 3. É possível criar snapshots dos volumes de origem do XtremIO que contêm arquivos de banco de dados Oracle, a qualquer momento, sem qualquer interação com bancos de dados ou ASM. Isso significa que não é necessário qualquer comando preparatório emitido para bancos de dados nem instâncias do ASM antes de criar um snapshot do XtremIO. Quando o conjunto de snapshots resultante é montado em um host, e o banco de dados for inicializado, o Oracle realiza uma recuperação simples da instância. 3 Para obter mais informações sobre a recuperação de instância, consulte: 9

10 VISÃO GERAL FUNCIONAL PARA PROVISIONAMENTO DE ARMAZENAMENTO DE PRODUÇÃO PARA DESENVOLVIMENTO DO XtremIO A lista a seguir é uma visão geral funcional de alto nível das etapas administrativas do XtremIO necessárias para facilitar o provisionamento de snapshots de produção para desenvolvimento: O banco de dados de produção reside em volumes do XtremIO. o O banco de dados pode residir em grupos de ASMdisk ou file systems. Um consistency group do XtremIO do volume de produção é criado. Um conjunto de snapshots graváveis do consistency group de produção é criado para o banco de dados de desenvolvimento gold. o O banco de dados de desenvolvimento gold pode ser montado em outros hosts (físicos ou virtuais), para realizar qualquer mascaramento de dados necessário antes da criação do snapshot para uso ativos dos desenvolvedores. Os hosts não precisam ser membros de um cluster específico do ASM para que possam usar bancos de dados armazenados em snapshots do XtremIO. Em seguida, um número de conjuntos de snapshots graváveis é criado com base no consistency group de produção. Essa ação também produz conjuntos de snapshots, que podem ser atualizados a qualquer momento do conjunto de snapshots gold ou outros conjuntos de snapshots de desenvolvedores. GRUPO DE SNAPSHOTS DE VOLUME DO XtremIO As quatro etapas simples descritas acima criam uma hierarquia de árvore chamada de Grupo de snapshot de volume. Todos os objetos em um grupo de snapshot de volume podem ser considerados irmãos, no sentido de que as atualizações podem ocorrer em qualquer direção entre eles. A criação de todos os conjuntos de snapshots do consistency group também garante que as operações de atualização de vários volumes sejam realizadas de maneira consistente por padrão. Figura 2 mostra uma parte da GUI do XtremIO ver. 4.0 com um exemplo de volumes e conjuntos de snapshots para um panorama de banco de dados Oracle, abrangendo produção, teste e desenvolvimento. Figura 2. Grupo de snapshot de volumes 10

11 XtremIO ARRAY DE PRODUÇÃO, TESTE E DESENVOLVIMENTO DO BANCO DE DADOS ORACLE: UM ESTUDO DE CASO SNAPSHOTS GRAVÁVEIS COM ECONOMIA DE ESPAÇO DE PRODUÇÃO PARA TESTE E DESENVOLVIMENTO Os administradores de banco de dados Oracle (DBAs) podem aproveitar a atualização de snapshots do XtremIO Ver. 4.0 de maneiras muito avançadas para oferecer mais valor para a empresa. Esta seção descreve um estudo de caso de laboratório de um cenário no qual snapshots eficientes de armazenamento do XtremIO com economia de espaço de um banco de dados de produção simulado são usados para o provisionamento de snapshots graváveis com dados mascarados para hosts de teste e de desenvolvimento. Os engenheiros do XtremIO construíram o ambiente de teste usando Oracle Database 12c Real Application Clusters e Oracle Linux 6.6 com o Unbreakable Enterprise Kernel. Os sistemas envolvidos no estudo de caso são: A configuração de produção simulada Uma configuração de Real Application Clusters (RAC) de dois nós de soquete dual de servidores com base Intel Xeon, conectados a um array XtremIO de X-Brick único de 40 TB por meio de Fibre Channel. Esse cluster RAC atuou como a configuração de produção. O banco de dados de produção simulado residia inteiramente em um grupo de discos do ASM composto por dois volumes do XtremIO. A configuração de desenvolvimento de Gold simulada Uma máquina virtual (VM), que não era membro do cluster do Grid Infrastructure, foi provisionada para processamento de banco de dados de desenvolvimento gold do host. Nessa arquitetura, atividade de banco de dados de desenvolvimento gold consiste em mascaramento do banco de dados de produção em preparação para provisionamento de snapshots para desenvolvedores ativos. A transformação de dados de produção em um caso de uso do mundo real provavelmente incluiria o mascaramento dos dados. Portanto, neste estudo de caso, engenheiros da EMC executaram uma atividade de mascaramento no snapshot de banco de dados simulado de produção depois que ele foi provisionado para o host de desenvolvimento gold. As VMs simuladas de Sandbox de desenvolvedor Duas máquinas virtuais adicionais configuradas para uso simulado dos desenvolvedores do banco de dados de produção mascarados. A Figura 3 mostra uma representação gráfica da configuração de laboratório usada para o estudo de caso. O gráfico representa um consistency group de volumes de produção: um conjunto de snapshots graváveis para a imagem gold do banco de dados de desenvolvimento, usada pelo host DEV_GOLD e dois conjuntos de snapshots graváveis provisionados para desenvolvedores nos hosts de DEV_WORK1 e DEV_WORK2. Todos os arquivos de banco de dados Oracle para produção e desenvolvimento foram armazenados em um único array do XtremIO de X-Brick de 40 TB. Figura 3. Visão geral da configuração de teste de estudo de caso 11

12 O principal objetivo do estudo de caso foi ilustrar as ações simples necessárias para provisionar snapshots graváveis com eficiência de espaço de um banco de dados de produção para um cenário de teste/desenvolvimento. O objetivo secundário era mostrar horários de operações essenciais, como a atualização de um snapshot de volumes usados ativamente ao executar bancos de dados Oracle. A primeira característica funcional, analisada pelos engenheiros do XtremIO, foi o tempo necessário para atualizar o conjunto de snapshots graváveis de desenvolvimento gold dos volumes de banco de dados de produção. Observe que em arquiteturas alternativas, como snapshots de armazenamento do Exadata, essa tarefa envolve recriar uma cópia completa do banco de dados de produção. ANÁLISE DE CRONOGRAMA ATUALIZAÇÃO DE DESENVOLVIMENTO GOLD PELA PRODUÇÃO Os engenheiros do XtremIO executaram as etapas necessárias para atualizar um conjunto de snapshots de desenvolvimento gold dos volumes de banco de dados de produção e os horários críticos coletados ao longo do caminho. TEXTO DESCRITIVO DO CRONOGRAMA A Figura 4 exibe uma descrição detalhada da série de eventos durante a atualização de snapshot programado. Figura 4. Descrição do teste Atualização de snapshots de desenvolvimento Gold de volumes de produção 1. O cronograma é iniciada às 14:49:28. A instância de banco de dados de produção (PROD) estava sendo executada e o banco de dados do v$ foi consultado mostrar o identificador exclusivo do banco de dados (DBID) e a hora em que o banco de dados foi criado. Isso é essencial para estabelecer que o host de desenvolvimento "gold" (DEV_GOLD) usará uma duplicação de snapshot desse banco de dados. Uma tabela de token (snaptest) foi criada na qual a hora atual do dia foi inserida. Isso é essencial para verificar a comprovação de cronograma. 2. O horário foi 14:49:41 e o banco de dados no host DEV_GOLD já estava em execução. A consulta ao valor DBID do banco de dados do v$ provou que ele era uma duplicação de snapshot do banco de dados de produção. A tabela snaptest de token ainda não existia neste snapshot do banco de dados. Em outras palavras, DEV_GOLD foi atualizada pela última vez com o PROD antes da criação da tabela snaptest de token no banco de dados PROD. Isso é essencial para estabelecer o fato de que o host DEV_GOLD está usando um snapshot gravável. Produção e desenvolvimento são irmãos, ainda que independentes. 3. No host DEV_GOLD, a instância de banco de dados foi interrompida e o grupo de discos do ASM foi desmontado. Isso foi na preparação de uma atualização de Snapshot por meio do host de produção. 4. A ação de atualização de snapshots do XtremIO ocorreu, o que atualizou o DEV_GOLD a partir da produção. Principais pontos: a. Nenhuma ação de administração do DBA ou dos sistemas era necessária no host de produção. Ou seja, o snapshot DEV_GOLD foi atualizado do consistency group PROD enquanto a instância de banco de dados PROD estava em execução. b. Nenhuma ação de administração de sistemas onde for necessário no host DEV_GOLD. Somente ações simples de DBA foram necessárias. 5. No host DEV_GOLD, o grupo de discos do ASM foi montado e a instância de banco de dados de desenvolvimento foi inicializada por meio do conjunto de snapshots atualizado. O banco de dados Oracle realizou uma recuperação simples da instância. Os DBAs reconhecerão isso como inicialização de uma instância de DEV pelo banco de dados PROD (consulte DBID de banco de dados do v$). 6. Em 14:51:38 no cronograma, a tabela snaptest de token foi consultada na DEV_GOLD, o conteúdo foi validado e a hora do dia foi consultada do banco de dados. A Figura 5 fornece uma representação gráfica da cronologia de eventos durante o teste de atualização de snapshot cronometrado explicado na Figura 4. O cronograma todo foi de apenas 130 segundos, a maioria deles envolvidos na digitação de comandos e capturas de tela. Figura 5. Visão geral do cronograma Atualização do conjunto de snapshot de desenvolvimento Gold por meio de volumes de banco de dados de produção 12

13 ATUALIZAÇÃO DE SNAPSHOT DE DESENVOLVIMENTO GOLD DA PRODUÇÃO ANÁLISE DE CRONOGRAMA Esta seção mostra os resultados da tela familiares para os DBAs Oracle. Essas capturas de tela foram feitas durante a atualização de snapshot programada, mostrada na Figura 5 e detalhada na Figura 4. A Figura 6 mostra a tela de saída, estabelecendo o evento inicial do cronograma (ponto 1 na Figura 4) no host RAC de produção simulada. Figura 6. Resultado de tela do host PROD Comprovação de atualização de snapshot 13

14 A Figura 7 mostra a tela de resultado do host DEV_GOLD no ponto 2 no texto descritivo do cronograma acima (consulte a Figura 4). Os DBAs podem observar que o script info.sql (consulte a Figura 6) mostra que o banco de dados em uso pelo host DEV_GOLD (dev.localdomain) era o mesmo banco de dados em uso no host PROD, conforme o resultado da consulta ao banco de dados do v$. Durante o estudo de caso, os engenheiros do XtremIO mantiveram o nome do banco de dados PROD e todos os nomes de grupo de discos de ASM intactos, para que os scripts administrativos funcionassem em todos os hosts. Os DBAs Oracle podem usar o utilitário DBNEWID 4 para alterar a DBID e DBNAME de bancos de dados em snapshots do XtremIO se determinado pelos requisitos do local. Figura 7. Host DEV_GOLD antes da ocorrência da atualização de snapshot 4 Para obter mais informações sobre o utilitário DBNEWID, consulte: 14

15 A Figura 8 mostra a tela de resultado correspondente para o ponto 3 no texto descritivo do cronograma acima (consulte a Figura 4). O gráfico mostra que o grupo de discos do ASM foi desmontado na preparação para a atualização do conjunto de snapshots provisionado para o host DEV_GOLD. Figura 8. Ações de DBA no host DEV_GOLD antes da atualização de snapshot 15

16 ATUALIZANDO O CONJUNTO DE SNAPSHOTS DE DESENVOLVIMENTO GOLD PARA O ESTADO DE BANCO DE DADOS DE PRODUÇÃO ATUAL A Figura 9 mostra a GUI do XtremIO no ponto 4 (consulte o texto descritivo do cronograma na Figura 4). A captura de tela mostra que o administrador de armazenamento apenas selecionou o conjunto de snapshots DEV_ROOT (associa ao host DEV_GOLD) e optou por atualizá-lo pelo consistency group PROD_CG, um processo que envolve quatro cliques do mouse. Observe que a funcionalidade de atualização de snapshot é demonstrada usando a GUI do XtremIO. No entanto, a atualização de snapshot pode ser realizada com a CLI ou a API RESTful também. Em uma futura versão do EMC AppSync, o evento todo poderá ser feito por autoatendimento. Figura 9. XtremIO GUI Atualização de snapshot do snapshot de desenvolvimento gold do consistency group de PROD 16

17 A Figura 10 mostra a conclusão do teste de atualização de snapshot programado com uma captura de tela dos eventos detalhados nos pontos 5 e 6 no texto descritivo (consulte a Figura 4). Neste ponto, os engenheiros do XtremIO tinham atualizado o conjunto de snapshots graváveis provisionados para o host DEV_GOLD, e todo o cronograma de eventos levou apenas 130 segundos, uma parte significativa do que era gasto na digitação de comandos e coleta capturas de tela. O gráfico mostra o conteúdo correto inserido na tabela de token (snaptest). O conteúdo da tabela de token mostra que alterações confirmadas, aplicadas no banco de dados em execução no host PROD, são vistas imediatamente em um snapshot do XtremIO atualizado. Essa sequência inteira de operações do XtremIO também pode ser feita com script por meio da CLI do XtremIO ou a API RESTful. Figura 10. Utilização do espaço de host ASM DEV_GOLD após a atualização de snapshot RESUMO DO CRONOGRAMA Os engenheiros do XtremIO estavam pensando nos administradores de banco de dados Oracle ao conduzir a análise de cronograma do estudo de caso da atualização de snapshot de desenvolvimento gold. Esse estudo de caso demonstrou aos DBAs que os snapshots do XtremIO que contêm bancos de dados Oracle podem ser atualizados de volumes de origem em questão de segundos. A natureza não invasiva da atualização de snapshots do XtremIO foi claramente demonstrada pela atualização imediata do banco de dados de desenvolvimento gold dos volumes de produção sem nenhuma ação no banco de dados de produção, que estava em execução o tempo todo. Mais importante, os DBAs agora podem ver que, com o ASM, eles têm controle total dos requisitos de nível de host para a atualização de snapshots, pois nenhuma ação de administração do sistema é necessária para fazer a atualização de snapshots do XtremIO 5. 5 Para bancos de dados Oracle armazenados em arquivos do file system, a consequência para a operação de montagem e desmontagem do ASM é a montagem e a desmontagem do file system, respectivamente. 17

18 ESTUDO DE CASO ANÁLISE DE USO DO ARMAZENAMENTO DE DESENVOLVIMENTO E PRODUÇÃO Para destacar a eficiência de espaço do XtremIO para armazenamento de volumes de banco de dados de produção junto com o desenvolvimento e o teste de snapshots graváveis, os engenheiros do XtremIO coletaram relatórios de uso de espaço do ASM e do XtremIO durante o estudo de caso. Esta seção detalha como o uso de espaço do XtremIO varia conforme os casos de uso de banco de dados diversos mudam. O XtremIO oferece redução de dados em linha ininterrupta que inclui desduplicação e compactação. Esses recursos são aplicados não só para os volumes de origem, mas também para os snapshots graváveis. O estudo de caso de uso de armazenamento incluiu a captura de detalhes de uso de espaço do ASM e do XtremIO conforme o progresso do teste. A Figura 11 mostra um gráfico, que descreve como o uso de espaço lógico e físico do XtremIO mudou durante o estudo de caso. Em alto nível, o gráfico mostra o uso de espaço de array físico e lógico do XtremIO nas seguintes fases de teste: Fase 1: uso do array físico e lógico depois que o banco de dados de produção simulada (PROD) foi criado. Fase 2: uso do array físico e lógico depois de recuperar espaço livre no disco ASM, usando o utilitário de recuperação de espaço do ASM. Fase 3: uso do array físico e lógico após o snapshot de desenvolvimento gold de PROD ter passado por mascaramento de dados. Fase 4: uso do array físico e lógico após PROD, DEV_GOLD e dois hosts de desenvolvimento adicionais (DEV_WORK1 e DEV_WORK2) estarem usando de forma independente seus conjuntos de snapshots graváveis. Fase 5: uso do array físico e lógico depois que os conjuntos de snapshot para DEV_WORK1 e DEV_WORK2 foram atualizados para o estado atual do conjunto de snapshot de desenvolvimento gold. Figura 11. Utilização do espaço do XtremIO durante o estudo de caso 18

19 UTILIZAÇÃO DO ARMAZENAMENTO UMA ANÁLISE DETALHADA Esta seção fornece uma análise detalhada do uso de espaço por meio de cinco fases descritas na Figura 11. USO DO ESPAÇO INICIAL DO XtremIO A Figura 12 mostra uma captura de tela da GUI do XtremIO, com foco no grupo de snapshot de volume criado para o estudo de caso. Os objetos foram criados conforme detalhado na VISÃO GERAL FUNCIONAL PARA PROVISIONAMENTO DE ARMAZENAMENTO DE PRODUÇÃO PARA DESENVOLVIMENTO DO XtremIO. O gráfico mostra o uso concreto de tags do XtremIO Ver As tags são um mecanismo simples para gerenciar configurações de grupos grandes de snapshot de volume no array XtremIO. Aqui vemos a marcação clara de objetos associados a vários conjuntos de snapshot e PROD envolvidos com o caso de uso de provisionamento de armazenamento de produção para teste. Figura 12. Grupos de snapshot de volume do XtremIO no início do estudo de caso A Figura 13 mostra a guia XtremIO GUI Storage Efficiency no início do estudo de caso. O gráfico mostra que houve 8,5 TB de capacidade do volume provisionados e que a taxa de redução de dados foi um valor de linha de base de Figura 13. Taxa de redução de dados do XtremIO de linha de base para o estudo de caso Depois de estabelecer uma linha de base do uso de espaço, os engenheiros do XtremIO iniciaram os testes da fase 1, descritos na Figura

20 UTILIZAÇÃO DO ESPAÇO DEPOIS DA CRIAÇÃO DO BANCO DE DADOS DE PRODUÇÃO Esta seção corresponde a fase 1 na Figura 11. RECONCILIANDO UM ESPAÇO ASM USANDO GERAÇÃO DE RELATÓRIOS COM RELATÓRIOS DE USO DE ESPAÇO DO XtremIO A Figura 14 e a Figura 15 correspondem ao uso de espaço de array ASM e XtremIO depois que o banco de dados de produção foi carregado. A Figura 14 mostra uma saída de tela do ASM Configuration Assistant (ASMCA) depois que o banco de dados de produção foi carregado no cluster RAC (consulte a Figura 3). O ASMCA relatou que o grupo de discos PROD_DATA tinha apenas 115,7 GB livres, sendo 1792 GB usados e aproximadamente 12 GB de PROD_REDO usados. A Figura 11 e a Figura 15 mostram o uso de espaço lógico de 1952 GB na fase 1, então pode haver uma discrepância entre a geração de relatórios de espaço do XtremIO e do ASM. No entanto, não há discrepância. O ASMCA relata o espaço conhecido para estar em uso pela instância do ASM, mas o XtremIO não sabe nada sobre ao espaço livre do ASM. Figura 14. Uso de espaço do ASM após o banco de dados PROD ter sido carregado (1792 GB de PROD_DATA usados) 20

21 SOBRE O ESPAÇO LIVRE DO ASM Os volumes do XtremIO são sempre com provisionamento thin. Quando um volume do XtremIO é dado ao ASM, o Oracle grava informações de cabeçalho no dispositivo, mas ele permanece com provisionamento thin. Criar um tablespace no ASM consome espaço no volume com provisionamento thin em um grau limitado. Todos os dados gravados em um array do XtremIO são desduplicados primeiro e, em seguida, compactados. A eficácia de desduplicação e compactação varia de acordo com o conteúdo de bloco do banco de dados Oracle. Quando o Oracle cria um tablespace, ele sobregrava completamente o espaço em disco com blocos de dados individualmente inicializados. Cada bloco tem algumas informações de cabeçalho exclusivo. Esses blocos inicializados, mas vazios, são profundamente compactados no XtremIO. Contudo, descartar um tablespace no ASM não retorna automaticamente o espaço livre no array 6. Por exemplo, um tablespace criado recentemente de 1 TB pode exigir apenas 330 GB de espaço físico no array, devido à compactação (a taxa de compactação aproximada é 3:1). Se o DBA decidir descartar o tablespace de 1 TB, ainda haverá 330 GB consumidos no array do XtremIO. Na realidade, esta é a situação do estudo de caso. Alguns dos tablespaces foram descartados depois que os dados foram carregados e, portanto, o array do XtremIO continuou a relatar 1952 TB usados, como na Figura 11 e na Figura 15. Figura 15. Uso de espaço do XtremIO depois que o banco de dados PROD foi carregado 6 O Oracle Database 12c é compatível com o novo atributo de disco do ASM THIN_PROVISIONED, que exige o driver de filtro ASM: ; No momento de publicação deste documento, defeitos de software do driver de filtro ASM não permitiam a funcionalidade THIN_PROVISIONING. 21

22 USO DO ESPAÇO DEPOIS DA DEVOLUÇÃO DO ESPAÇO LIVRE DO ASM PARA O ARRAY Esta seção corresponde à fase 2 na Figura 11. USANDO O UTILITÁRIO DE RECUPERAÇÃO DE ESPAÇO DO ASM PARA DEVOLUÇÃO DE ESPAÇO ASM NÃO UTILIZADO PARA O ARRAY O utilitário de recuperação de espaço do ASM 7 (ASRU) é um conjunto de scripts opcionais fornecidos pela Oracle. Se os DBAs assim optarem, eles podem usar o ASRU para devolver o espaço livre em um volume de armazenamento do XtremIO com provisionamento thin depois de tablespaces terem sido descartados em grupos de discos do ASM. O ASRU usa o dicionário de dados da instância do ASM para determinar as seções físicas de discos do ASM que não estão mais em uso. Em seguida, o script abre os arquivos e executa dd(1) para sobregravar essas seções do dispositivo físico com zeros. A gravação de zeros sobre o espaço usado em um volume do XtremIO devolve o espaço para o array. No entanto, a gravação de zeros no XtremIO não resulta em uma gravação para um SSD. O XtremIO tem otimização exclusiva de block zero, o que resulta em uma atualização simples de somente metadados quando uma gravação composta somente de zeros é recebida pelo array. No entanto, o ASRU usa dd(1) com operações síncronas de 1 MB. Portanto, o desempenho absoluto da operação é limitado aos tempos de transferência de Fibre Channel envolvidos. Usar o ASRU durante esse estudo de caso não teve como objetivo sugerir qualquer tipo de prática recomendada para gerenciamento de espaço de array do XtremIO. O único propósito era ajudar os leitores a terem uma compreensão mais profunda da relação entre o array ASM e o XtremIO. Os DBAs Oracle de produção são incentivados a buscar My Oracle Support antes de usar o ASRU, começando com a nota MOS Os engenheiros do XtremIO conheciam o processamento de carregamento de banco de dados PROD e o uso temporário de alguns tablespaces do Oracle. Depois que o procedimento de carregamento era concluído, alguns tablespaces eram descartados. Depois de registrar o uso de espaço na fase 1 (consulte a Figura 11), o utilitário de recuperação de espaço do ASM (ASRU) foi usado para devolver o espaço para o array. A Figura 16 mostra o resultado de tela após a conclusão da execução do ASRU. Figura 16. Execução do utilitário ASRU depois da conclusão do procedimento de carregamento de banco de dados PROD O resultado do comando dd(1) mostra que o ASRU gravou zeros em 274 GB. Esse é o espaço liberado de volta para o array. 7 Para uma introdução sobre o utilitário de recuperação de espaço do ASM, consulte o seguinte white paper da Oracle: 22

23 A Figura 17 mostra a GUI do XtremIO após a conclusão do processamento do ASRU. Como mostra o gráfico,o ASRU devolveu o espaço não utilizado do ASM para o array e, portanto, a GUI do XtremIO mostrou o uso do espaço muito próximo ao relatado pelo ASMCA (consulte a Figura 14). Figura 17. GUI do XtremIO após a conclusão do procedimento do ASRU 23

24 USO DO ESPAÇO APÓS O MASCARAMENTO DE DADOS DO SNAPSHOTS DE DESENVOLVIMENTO GOLD Esta seção corresponde a fase 3 na Figura 11. A Figura 18 mostra a GUI do XtremIO após a conclusão do procedimento de mascaramento de dados do host DEV_GOLD. O procedimento de mascaramento de dados alterou uma parte significativa do conjunto de snapshot do desenvolvimento gold. O gráfico mostra como o uso de espaço lógico no array aumentou 69%, passando de 1762 GB para 2973 GB, e mesmo assim o uso físico aumentou somente 28%, de 999 GB para 1279 GB. Essa economia de espaço é devido ao fato de que a desduplicação aumentou em 30%, de 1.0: para 1.3.1:1 e a compactação de 1.9:1 para 2.4:1, um aumento de 26%. O aumento na desduplicação não é resultado do uso de snapshot. Alguns dos arquivos envolvidos com o processo de mascaramento de dados no host DEV_GOLD continham dados duplicados. O valor de 2973 GB relatado pela GUI do XtremIO inclui o espaço agregado usado pelo PROD e DEV_GOLD após o mascaramento de dados. Observe que o banco de dados PROD estava independentemente executando cargas de trabalho desde a conclusão da liberação de espaço para o array via ASRU na fase 2 do teste (consulte a Figura 11). Observe também como a capacidade do volume aumentou de 8,5 TB na Figura 17 para 10,6 TB na Figura 18. O motivo é que havia um snapshot somente leitura criado em PROD entre as fases 3 e 4 (consulte a Figura 11). Figura 23 mostra esse conjunto de snapshot somente leitura e as tags associadas a GUI do XtremIO. Figura 18. GUI do XtremIO após a conclusão do mascaramento de dados de desenvolvimento Gold A Figura 19 mostra uma saída do ASMCA do host DEV_GOLD, revelando que, após a conclusão do procedimento de mascaramento de dados, o uso de espaço combinado dos grupos de disco PROD_DATA e PROD_REDO foi 1873 GB (( ,61) + ( ,77)). Figura 19. Uso do espaço do ASMCA no host DEV_GOLD após mascaramento de dados SOBRE OS NOMES DO GRUPO DE DISCOS DO ASM COM SNAPSHOTS DO XtremIO Quando um snapshot de um disco do ASM é montado em um host, ele leva o nome do grupo de disco com ele, devido à rotulação interna do ASM. Os DBAs Oracle podem usar a ferramenta renamedg do ASM 8 para renomear os discos do ASM, se assim desejarem. 8 Para obter informações sobre a ferramenta renamedg, consulte: httwp://docs.oracle.com/cd/e11882_01/server.112/e18951/asmdiskgrps.htm#chdjaghe 24

25 USO DE ESPAÇO COM TODOS OS BANCOS DE DADOS ATIVOS EM CONJUNTOS DE SNAPSHOTS GRAVÁVEIS Esta seção corresponde a fase 4 na Figura 11. Na fase 4 na Figura 11, todos os bancos de dados do estudo de caso estão executando cargas de trabalho por algum tempo. Os conjuntos de snapshot usado pelos hosts DEV_WORK1 e DEV_WORK2 foram atualizados dos conjuntos de snapshot DEV_GOLD para obter cópias atuais da imagem do banco de dados de desenvolvimento gold. Figura 20 mostra a geração de relatório do uso de espaço do ASMCA em todos os hosts de desenvolvimento. Neste momento, todos os hosts de desenvolvimento estão processando cargas de trabalho intensas de gravação moderadamente por várias horas. Figura 20 mostra que todos os hosts estão usando independentemente seus próprios snapshots graváveis. Figura 20. Saída do ASMCA de todos os hosts de desenvolvimento A Figura 21 mostra a geração de relatórios do uso de espaço da GUI do XtremIO que corresponde à fase 4 (consulte a Figura 11). A captura de tela mostra um aumento de 20% na taxa de desduplicação depois que todos os hosts de desenvolvimento têm se mostrado ativos por um período de tempo. Por outro lado, o impacto de compactação foi reduzido em 8% para uma proporção de 2.1:1. As taxas de redução de dados do XtremIO refletem o fato de que os hosts foram processando independentemente das cargas de trabalho Oracle: alguns beneficiam-se mais da desduplicação do que da compactação. O XtremIO oferece várias camadas de redução de dados em linha para cobrir cargas de trabalho variáveis e os dados mostram uma taxa de redução líquida de dados de 2.6:1. A Figura 21 também mostra o benefício claro da tecnologia de snapshot do XtremIO sob uma perspectiva de uso de espaço. Mesmo quando todos os bancos de dados estão ativos, a redução global de dados fica clara: 5,5 TB de espaço de volume usado pelo Oracle ASM exigiam apenas 2,1 TB de espaço físico no array. Figura 21. GUI do XtremIO após uso ativo de todos os hosts dos volumes e snapshots do XtremIO 25

26 USO DO ESPAÇO DEPOIS DE O DESENVOLVEDOR ATUALIZAR CONJUNTOS DE SNAPSHOTS PARA CONJUNTOS DE SNAPSHOT DE DESENVOLVIMENTO GOLD Esta seção corresponde a fase 5 na Figura 11. A medida final obtida pelos engenheiros do XtremIO foi representada na fase 5 (consulte a Figura 11). Depois de algumas modificações da imagem de desenvolvimento gold no conjunto de snapshot de DEV_GOLD, era o momento para a atualização dos Snapshots usados pelos hosts DEV_WORK1 e DEV_WORK2. Depois da desmontagem dos grupos de discos do ASM nos hosts de DEV_WORK1 e DEV_WORK2, seus snapshots foram atualizados do estado atual do conjunto de snapshot DEV_GOLD. Como resultado, o uso de espaço lógico agregado do XtremIO caiu 23%, de 5519 GB para 4253 GB, conforme mostrado na Figura 22. O espaço físico necessário para o todo o grupo de snapshot de volume de desenvolviment e produção foi de 1,46 TB. Figura 22. GUI do XtremIO após a atualização dos snapshots de DEV_WORK para DEV_GOLD RESUMO DO USO DE ESPAÇO O estudo de caso de uso de espaço mostra claramente que qualquer número de hosts usando snapshots graváveis do XtremIO de modo independente se beneficiarão dos serviços ininterruptos de redução de dados em linha do XtremIO. O valor de volumes com provisionamento thin, combinado com compactação e desduplicação, é claramente demonstrado por meio da análise do array do XtremIO e relatórios de utilização de espaço do ASM. No pico de uso do espaço durante o estudo de caso, o array do XtremIO lidou com 5,5 TB de espaço lógico, usando apenas 2,1 TB de espaço físico no array. 26

27 INTERFACE GRÁFICA DO USUÁRIO DO XtremIO GERENCIAMENTO Do GRUPO DE SNAPSHOT DE VOLUME O XtremIO versão 4.0 introduz uma funcionalidade de marcação para gerenciamento de objetos da GUI do XtremIO. As tags são definidas pelo usuário e permitem a exibição ordenada e o gerenciamento de objetos específicos de aplicativos, como os conjuntos de snapshot associados ao desenvolvimento e produção. Figura 23 mostra uma captura de tela da GUI do XtremIO no final do estudo de caso. A figura demonstra que a navegação com tags iniciando no painel de volume para baixo para objetos de gerenciamento específicos, como consistency groups e conjuntos de snapshot, pode ser feita com aplicativos em mente, ao contrário do objeto de armazenamento do XtremIO subjacente (por exemplo, Volume Ou Snapshot). A seta na Figura 23 marca os snapshots somente leitura que foram criados com o volume de produção durante o estudo de caso. No final do estudo de caso, uma captura de tela da GUI do XtremIO foi criada para mostrar como a marcação dos objetos do estudo de caso evoluiu para uma visualização de gerenciamento simples de usar, apesar de números crescentes de volumes e snapshots. O gráfico mostra tags com nomes que devem ser familiares para o leitor, com base no estudo de caso. Os engenheiros do XtremIO criaram tags de nível superior para rastrear todos os objetos associados a ações de produção e desenvolvimento no estudo de caso. Por exemplo, os engenheiros do XtremIO foram capazes de usar a tag DEV_OBJECTS para navegar e manipular objetos de armazenamento provisionados para o desenvolvimento gold e snapshots de desenvolvedor em funcionamento (DEV_WORK1, DEV_WORK2). Para obter mais informações sobre a funcionalidade de marcação do XtremIO Ver. 4.0, consulte o Guia do usuário do EMC XtremIO Storage Array. Figura 23. XtremIO GUI Gerenciamento de objetos com tags, inclusive um exemplo de um snapshot somente leitura 27