Práticas recomendadas para a execução do SQL … · do SQL Server no EMC XtremIO RESUMO Este...

WHITE PAPER DA EMC

Práticas recomendadas para execução do SQL Server no EMC XtremIO

RESUMO Este white paper explica as características gerais de execução de SQL Server no array de armazenamento totalmente flash corporativo da EMC, XtremIO. Ele revela estudos nas áreas de desempenho, eficiência de armazenamento, implementação, planejamento de capacidade e gerenciamento do ciclo de vida de aplicativos do SQL Server. Este documento também fornece orientação geral sobre as considerações e as práticas recomendadas de implementação.

Outubro de 2015

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.

VMware, VMware vSphere e VMKernel Scheduler são marcas registradas ou comerciais da VMware, Inc. nos Estados Unidos e/ou em outras jurisdições. Todas as outras marcas comerciais aqui mencionadas pertencem a seus respectivos proprietários.

Número da peça H14583

http://brazil.emc.com/contact-us/contact-us.esp

http://brazil.emc.com/

https://store.emc.com/?EMCSTORE_CPP

3

ÍNDICE

SUMÁRIO EXECUTIVO .............................................................................................. 5

Público-alvo ............................................................................................................ 5

INTRODUÇÃO AO XTREMIO ...................................................................................... 6

Arquitetura ............................................................................................................. 6

Serviços de dados de cópia ....................................................................................... 7

DESEMPENHO ........................................................................................................... 8

EFICIÊNCIA NO ARMAZENAMENTO ........................................................................... 9

Provisionamento thin ............................................................................................... 9

Espaço pré-alocado do SQL Server e provisionamento thin ..................................................... 9

Desduplicação de dados em linha ............................................................................. 11

Banco de dados único ...................................................................................................... 11

Várias cópias do banco de dados ....................................................................................... 12

Compactação de dados em linha .............................................................................. 13

Compactação de dados no SQL Server ............................................................................... 13

Compactação de array do XtremIO e compactação de dados nativa do SQL Server ................... 13

SERVIÇOS DE DADOS DO SQL SERVER E CÓPIA DO XTREMIO ................................ 16

CONSIDERAÇÕES SOBRE PLANEJAMENTO E OPERAÇÕES DE ARMAZENAMENTO ..... 18

Provisões para SQL Server ...................................................................................... 18

Configuração do RAID ...................................................................................................... 18

Separação de arquivos ..................................................................................................... 18

Número de LUNs ............................................................................................................. 19

Número de arquivos ........................................................................................................ 20

Atendendo às necessidades de dados de downstream ................................................. 20

Teste e desenvolvimento .................................................................................................. 20

Relatórios quase em tempo real ........................................................................................ 21

Atualizando dados de downstream com atualização de snapshot ............................................ 24

Manutenção do banco de dados ............................................................................... 24

Ajuste de consulta ........................................................................................................... 25

DBCC ............................................................................................................................ 25

4

Backup/restauração ............................................................................................... 25

Backup/restauração de snapshots com o EMC AppSync ......................................................... 26

Upgrade ............................................................................................................... 26

CONSIDERAÇÕES SOBRE A IMPLEMENTAÇÃO ......................................................... 27

Múltiplos caminhos ................................................................................................ 27

Tamanho da fila .................................................................................................... 27

Tamanho de setor físico de 512 B em comparação a 4 KB ........................................... 29

Determinando qual tamanho de setor usar .......................................................................... 31

Tamanho da unidade de alocação ............................................................................ 32

Snapshot consistente com aplicativos em comparação ao snapshot consistente em caso de falha ................................................................................................... 33

Snapshot consistente em caso de falha ............................................................................... 33

Snapshot consistente com aplicativos ................................................................................. 33

Determinando qual snapshot usar ...................................................................................... 34

CONCLUSÃO ........................................................................................................... 35

APÊNDICE I: RESUMO DAS PRÁTICAS RECOMENDADAS ......................................... 36

APÊNDICE II: CONFIGURAÇÕES E METODOLOGIAS DE TESTES DE DESEMPENHO .. 38

Metodologias de teste ............................................................................................ 38

Configurações de teste ........................................................................................... 38

APÊNDICEIII: ATUALIZAÇÃO DE SNAPSHOT .......................................................... 40

REFERÊNCIAS ......................................................................................................... 43

5

SUMÁRIO EXECUTIVO Para muitas organizações, o SQL Server é a infraestrutura de mecanismo de banco de dados principal para aplicativos essenciais aos negócios. Embora os departamentos de TI em organizações precisam reduzir os custos e aumentar a eficiência, os aplicativos do SQL Server estão ficando mais complexos, os tamanhos de banco de dados são altíssimos e as janelas de serviço estão diminuindo. No entanto, as empresas, estão exigindo uma resposta melhor. É trabalho tanto dos administradores de TI como dos administradores de banco de dados do SQL Server buscar soluções para acompanhar os SLAs (Service Level Agreements, contratos de nível de serviço) e as medidas de desempenho enquanto aumentam a eficiência e a agilidade do workflow.

O storage array totalmente flash XtremIO da EMC é uma plataforma ideal para aplicativos essenciais aos negócios, como o SQL Server. A arquitetura scale-out exclusiva do XtremIO não apenas oferece altíssimo desempenho, com dimensionamento perfeito de latência baixa consistente para qualquer implementação de SQL Server, mas também traz novos níveis de eficiência de armazenamento, simplicidade e agilidade que aumentam significativamente a capacidade de produção da TI e dos administradores de banco de dados.

Este paper discute:

• Recursos do XtremIO e valor agregado para SQL Server

• Os cenários de caso de uso sobre a utilização de recursos do XtremIO para melhorar o gerenciamento de ciclo de vida de aplicativos do SQL Server aumentam a produtividade de administradores de banco de dados e das equipes de Business Intelligence

• Considerações sobre a implementação do SQL Server no XtremIO, inclusive práticas recomendadas

Um resumo das recomendações de práticas recomendadas está presente no Apêndice I: Resumo das práticas recomendadas.

PÚBLICO-ALVO Este white paper foi elaborado para:

• Administradores de banco de dados SQL Server

• Administradores de TI

• Arquitetos de armazenamento/datacenter

• Gerentes técnicos

• Qualquer outro profissional de TI responsável pelo projeto, implementação e gerenciamento de bancos de dados, infraestrutura e datacenters do SQL Server

6

INTRODUÇÃO AO XTREMIO O XtremIO é um storage array de armazenamento totalmente flash de nível corporativo com serviços avançados de dados. Ele foi projetado do zero para liberar todo o potencial de desempenho do flash e oferecer recursos baseados em array que aproveitam as características exclusivas dos SSDs (Solid State Drive).

ARQUITETURA O Storage Array é um sistema totalmente flash, baseado em uma arquitetura scale-out. O sistema é projetado para dimensionar, usando componentes básicos (X-Bricks). Cada X-Brick é uma unidade de alta disponibilidade que consiste em duas controladoras de armazenamento ativo-ativo e um conjunto de 25 SSDs. Os X-Bricks são colocados em cluster para aumentar o desempenho e a capacidade conforme necessário. Interconexões entre controladoras de armazenamento e X-Bricks são fornecidas pelo RDMA (Remote Direct Memory Access, acesso remoto de memória direta) de alta velocidade e latência ultrabaixa com o InfiniBand. Aproveitando o RDMA, o sistema XtremIO é, em essência, um espaço único de memória compartilhada que abrange todas as controladoras de armazenamento. Dimensionando linearmente todos os recursos, como CPU, RAM, SSDs e portas de host de forma balanceada, o array atinge qualquer nível de desempenho desejado e mantém a consistência de desempenho que é essencial para o comportamento previsível dos aplicativos.

Com uma arquitetura projetada para dar suporte a um número ilimitado de X-Bricks, o lançamento da versão 4.0 do XtremIO atual dá suporte a até oito X-Bricks com diferentes capacidades SSD.

Figura 1. Arquitetura de array de armazenamento do storage array totalmente flash XtremIO

O mecanismo de armazenamento do XtremIO tem reconhecimento de conteúdo. Conforme o fluxo de dados entra no sistema, ele é subdividido em blocos de dados. Cada bloco de dados recebe uma impressão digital com uma assinatura exclusiva, com base no conteúdo do bloco de dados. O sistema mantém uma tabela de mapeamento na memória. Cada impressão digital do bloco de dados de entrada é verificada com relação à tabela de mapeamento para duplicações. Além disso, apenas os blocos de dados que são exclusivos (nunca-gravados anteriormente no sistema) são compactados e armazenados em SSDs. Inicialmente, os dados sempre são armazenados com o menor espaço ocupado, sem a necessidade de redução de dados pós-processamento. O processo matemático que calcula as impressões digitais sempre resulta em uma distribuição uniforme dos valores de impressão digital e o mapeamento de impressão digital é distribuído de maneira uniforme entre todas as controladoras de armazenamento do cluster.

Graças a sua arquitetura de armazenamento que reconhece conteúdo, o XtremIO oferece:

• Distribuição uniforme de blocos de dados. O desempenho é inerentemente equilibrado entre todas as controladoras de armazenamento e todos os SSDs.

• Distribuição uniforme de metadados.

• Nenhum hotspot de dados ou metadados, resultando em maior resistência do flash.

• Fácil de instalar e nenhuma necessidade de ajuste. Nenhum planejamento de capacidade complexo é necessário para espalhar LUNs por grupo de RAID ou spindles.

• Os serviços de dados avançados, inclusive desduplicação de dados em linha, compactação de dados em linha, provisionamento thin, proteção avançada de dados (XDP) e serviços de dados de cópia com snapshots.

7

SERVIÇOS DE DADOS DE CÓPIA Uma das partes mais incríveis que a tecnologia do XtremIO oferece é os serviços de dados ágeis de cópia. Os serviços de dados de cópia do XtremIO elevam os snapshots graváveis para além da simples proteção de dados. Os serviços de dados de cópia do XtremIO criam instantaneamente cópias de volume com tamanho e desempenho completo, mas ainda assim economizando espaço. Todo o ambiente de aplicativo, incluindo instâncias de produção e fora de produção, pode ser gerenciado eficientemente em um único array, com uma excelente economia. Isso permite que suas equipes de aplicativo e infraestrutura tenham agilidade inovadora de workflow e processo de negócios ao eliminar técnicas de cópia de força bruta que desperdiçam tempo, consomem desempenho e ocupam muito espaço. As equipes de aplicativo e infraestrutura podem trabalhar em projetos com mais valor agregado e inovação.

Figura 2. Serviços de dados de cópia do XtremIO

8

DESEMPENHO As cargas de trabalho de aplicativos típicos, como SQL Server, direcionam de forma moderada IOPS/largura de banda que raramente estende a capacidade de uma rede de área de armazenamento compartilhado (SAN). As organizações consolidam várias cargas de trabalho em SAN para maximizar a utilização de recursos e aproveitam as vantagens da disponibilidade, da capacidade de expansão e da facilidade de gerenciamento de uma SAN. Embora a consolidação do armazenamento fornece as promessas de eficiência de gerenciamento, manter o desempenho do aplicativo e o nível de serviço do usuário tem sido um enorme desafio para servidores de SQL em execução na SAN devido a problemas de “vizinho barulhento” para compartilhamento de recursos ou combinação de cargas de trabalho com diferentes padrões de acesso ao disco.

O XtremIO é um array totalmente flash de classe corporativa que foi desenvolvido para resolver muitos desafios de uma SAN tradicional. O XtremIO não apenas oferece alta IOPS/largura de banda, mas também consistentemente mantém uma latência de submilissegundos conforme o número de cargas de trabalho aumenta, ou conforme o sistema é dimensionado. A arquitetura exclusiva de scale-out do sistema também permite o dimensionamento linear de desempenho, bem como de capacidade. A arquitetura do XtremIO permite que o desempenho e a capacidade sejam ampliados com o acréscimo de X-Bricks. Cada X-Brick oferece 150 mil IOPS de 8K com leitura/gravação mistas na proporção de 70:30 ou 250 mil de IOPS de 8K de leitura 100%. A arquitetura é construída para dar suporte a um número ilimitado de X-Bricks. A versão atual 4.0 dá suporte a até oito X-Bricks com mais de 1,2 milhão de IOPS com leituras/gravações mistas.

A arquitetura scale-out exclusiva do XtremIO oferece excelente flexibilidade para implementações de SQL Server. Você pode começar pequeno e, à medida que sua empresa cresce, adicionar mais desempenho e capacidade com X-Bricks adicionais. Quando você faz scale-out com a adição de X-Bricks, os dados do SQL Server são rebalanceados automaticamente em todos os SSDs no cluster do XtremIO. Com a capacidade de expansão de cluster on-line do XtremIO, as cargas de trabalho automaticamente se beneficiam de SSDs adicionais e das controladoras de armazenamento, sem nenhuma interrupção de serviço.

A Figura 3 exibe os resultados de um estudo realizado na consolidação de até oito cargas de trabalho do SQL Server em um cluster dual do XtremIO de X-Brick. Cada carga de trabalho parecida com OLTP simula um aplicativo de operações financeiras e gera atividades de I/O de uma carga de trabalho típica de transações on-line do SQL Server de 90% de leitura e 10% de gravação. A maioria dos acessos aos dados é aleatória de 8K. O estudo mede o IOPS e a latência conforme o número de cargas de trabalho do SQL Server aumenta. De acordo com a Figura 3, conforme o número de instâncias de SQL Server aumenta de 1, 2, 4 e 8, o IOPS de total agregado aumenta a partir de 22K, 45K, 95K e 182K, respectivamente. A capacidade de expansão de IOPS é quase linear conforme o número de cargas de trabalho do SQL Server aumenta. A latência média do disco é observada à medida que o aplicativo do SQL Server é mantido em cerca de 500 µs. Para obter mais detalhes sobre a configuração de teste e metodologias, consulte o Apêndice II: Configurações e metodologias de testes de desempenho

Figura 3. Desempenho do XtremIO com a consolidação de até 8 SQL Servers

9

A capacidade de manter a latência de submilissegundos consistente sob alta carga e de dimensionar linearmente em um ambiente compartilhado diferencia o XtremIO dos híbridos tradicionais e outros arrays totalmente flash. O XtremIO Storage Array oferece previsibilidade e consistência que são absolutamente essenciais para a execução de todos os aplicativos corporativos de SQL Server em uma SAN.

EFICIÊNCIA NO ARMAZENAMENTO O XtremIO oferece uma ampla variedade de recursos de eficiência de armazenamento que são globais, em linha e ininterruptos. Esses recursos de eficiência de armazenamento não apenas reduzem significativamente o espaço ocupado pelo armazenamento para executar bancos de dados do SQL Server no XtremIO, mas também efetivamente melhoram o desempenho e a longevidade de SSD, reduzindo o número de operações de gravação para os SSDs. Os recursos de eficiência de armazenamento do XtremIO incluem o provisionamento thin, a desduplicação de dados em linha e a compactação de dados em linha.

PROVISIONAMENTO THIN Os sistemas de armazenamento legado usam provisionamento thick em vez de provisionamento thin. O provisionamento thick normalmente exige uma projeção do uso potencial de armazenamento de aplicativo de três anos, mas pagamento pelo custo do armazenamento no momento da compra. Em muitos casos, o armazenamento é provisionado em excesso e, consequentemente, uma grande quantidade de espaço é desperdiçada por um longo período. O provisionamento thin foi projetado para aumentar a utilização do armazenamento e maximizar o investimento em armazenamento de organização.

O armazenamento do XtremIO é de provisionamento thin nativo e aceita 100% de armazenamento sob demanda. Com o provisionamento thin, o administrador de TI provisiona armazenamento para SQL Server como de costume, mas o sistema do XtremIO só consome capacidade quando realmente precisa. O provisionamento thin otimiza a utilização de armazenamento, eliminando qualquer capacidade não utilizada provisionada.

ESPAÇO PRÉ-ALOCADO DO SQL SERVER E PROVISIONAMENTO THIN A implementação típica do SQL Server pré-aloca 10 a 30% de espaço para prever o crescimento de dados e para evitar o crescimento automático dos data file durante a execução. A parte do espaço alocado previamente é zero na inicialização, mas ainda não foi gravada pelo SQL Server.

Com o XtremIO, a parte do espaço alocado previamente é considerada como espaços em branco que não serão armazenados fisicamente. Neste estudo, foi criado um banco de dados de 1,6 TB, com uma grande quantidade de espaço alocado previamente (cerca de 61%) para observar o espaço físico ocupado do armazenamento no XtremIO. Conforme indicado na Figura 4 e na Figura 5, o painel de armazenamento do painel de controle do XtremIO mostra a quantidade de espaço provisionado para o volume como 2 TB, e o consumo real do espaço de cerca de 610 GB. A quantidade de espaço alocado previamente é de provisionamento thin.

A Figura 4 mostra um banco de dados com cerca de 1,6 TB de espaço reservado, com 610 GB de espaço real usado.

Figura 4. Espaço de banco de dados usado do SQL Server

10

A Figura 5 mostra a capacidade de volume que é considerada como usada pelo XtremIO. Como indicado na figura, o espaço alocado previamente do SQL Server é considerado como com provisionamento thin.

Figura 5. Painel de controle do XtremIO Painel Storage

O provisionamento thin nativo do XtremIO fornece as seguintes vantagens:

• Os administradores de banco de dados podem ser mais generosos na atribuição de espaço pré-alocado para evitar a sobrecarga de desempenho para crescimento de arquivos de banco de dados.

• Os administradores de TI não precisam se preocupar com desperdício de espaço de armazenamento devido a uma grande quantidade de espaço alocado previamente que não está sendo usada.

• Os administradores de TI têm mais flexibilidade no dimensionamento. Aplicativos como o SQL Server raramente usam a capacidade provisionada total. A capacidade de consumir capacidade sob demanda permite que os administradores de TI maximizem a capacidade física do armazenamento com mais eficiência.

O provisionamento thin é parte integrante da arquitetura que reconhece conteúdo do XtremIO. Ao contrário de alguns arquiteturas orientadas a discos, o provisionamento thin do XtremIO não afeta o desempenho nem causa problemas de fragmentação.

O provisionamento thin proporciona muitos benefícios. No entanto, ele requer que os administradores de TI implementem medidas para monitorar a porcentagem da capacidade física disponível. Para evitar problemas com o SQL Server, armazenamento extra deve ser adicionado desde o início, quando a quantidade de capacidade física disponível é baixa. Os recursos de expansão de cluster sem causar interrupções e alertas do XtremIO permitem o monitoramento proativo e o dimensionamento da capacidade de espaço.

11

DESDUPLICAÇÃO DE DADOS EM LINHA O XtremIO armazena dados de acordo com seu conteúdo. Quando o fluxo de dados entra no sistema, ele é dividido em blocos de dados de 8 KB e recebe uma impressão digital com base em seu conteúdo. Cada bloco de dados é automaticamente marcado para desduplicação globalmente em todo o cluster do XtremIO. Somente dados exclusivos que ainda não existem no storage array totalmente flash XtremIO são gravados nos SSDs.

A arquitetura exclusiva do XtremIO de uso de impressões digitais de conteúdo não somente permite a desduplicação de dados em linha, mas também proporciona flexibilidade para distribuição proporcional de dados. Os blocos de dados em qualquer volume de SQL Server são distribuídos igualmente entre todos os SSDs no cluster. Os dados são balanceados automaticamente para evitar qualquer hotspot nos SSDs para balanceamento de desgaste de flash ideal. É feito o balanceamento de carga automático do desempenho em todas as controladoras de armazenamento em todos os X-Bricks no cluster do XtremIO.

Esse recurso do XtremIO e seu processo inteligente de armazenamento de dados garantem:

• Utilização balanceada dos recursos do sistema, maximizando o desempenho do sistema

• Quantidade mínima de operações do flash, maximizando a longevidade do flash

• Distribuição uniforme de dados, resultando em desgaste balanceado do flash em todo o sistema.

• Não existe coleta de lixo no nível do sistema (ao contrário de redução de dados pós-processamento)

• Uso inteligente de capacidade de SSD, minimizando custos de armazenamento

BANCO DE DADOS ÚNICO O SQL Server armazena dados em páginas. Cada página é uma unidade de dados de 8 KB. A Figura 6 ilustra a estrutura de uma página do SQL Server. Cada página contém um cabeçalho com campos que são exclusivas da página. Os dados reais de linhas estão localizados na parte restante da página. Ao implementar um banco de dados no XtremIO, a desduplicação de dados em linha não deve reduzir o espaço ocupado em disco dos bancos de dados devido ao cabeçalho da página exclusivo em cada página de dados. No entanto, há muitos ocasiões em que mais de uma cópia dos bancos de dados são necessárias devido a problemas como geração de relatórios, teste e desenvolvimento.

Figura 6. Estrutura de uma página de dados do SQL Server

12

VÁRIAS CÓPIAS DO BANCO DE DADOS A Figura 7 mostra os efeitos da desduplicação de dados em linha ao implementar várias cópias do mesmo banco de dados. O gráfico exibe a implementação de 1, 2, 4 e 8 cópias de um banco de dados. Enquanto a capacidade provisionada (espaço reservado pelo SQL Server) e o espaço usado pelo SQL Server são multiplicados conforme o número de cópias aumenta, o XtremIO consome apenas o espaço físico para um único banco de dados. Quando cópias são criadas inicialmente, não é necessário usar espaço adicional. O consumo de espaço só aumenta posteriormente, quando há alterações no conteúdo do banco de dados.

Figura 7. Eficiência de armazenamento com cópias de banco de dados

13

COMPACTAÇÃO DE DADOS EM LINHA Como parte do fluxo do I/O de gravação, o XtremIO compacta dados automaticamente após todas as duplicações serem removidas. A compactação é uma operação global, em linha e ininterrupta que é executada somente em blocos de dados exclusivos. O XtremIO usa um algoritmo que é baseado em Lempel-Ziv-Welch, que otimiza o equilíbrio entre a capacidade de compactação e a alocação de recursos.

A compactação complementa a desduplicação de dados para implementações de SQL Server. Se você estiver implementando um banco de dados, várias cópias do mesmo banco de dados, ou vários bancos de dados do aplicativo, a compactação em linha reduzirá automaticamente o espaço ocupado pelo armazenamento ao armazenar blocos de dados da maneira mais eficiente. O XtremIO pode efetivamente compactar dados exclusivos em uma proporção de até 4:1. A natureza dos dados determina a taxa geral de compactação deles.

COMPACTAÇÃO DE DADOS NO SQL SERVER Os administradores de banco de dados do SQL Server estão familiarizados com os recursos de compactação de dados nativos do SQL Server, ou seja, compactação de linha e compactação de página. A compactação de linha armazena tipos de dados de comprimento fixo em formato de tamanho variável e remove as necessidades de armazenamento para valores nulos e espaço em branco. A compactação de página procura ainda mais oportunidades de redução de dados, minimizando os dados da coluna redundante em uma ou mais linhas em uma página de 8 KB. Os dados redundantes de coluna são armazenados apenas uma vez em uma página e têm várias colunas como referência.

A implementação de compactação de linha e compactação de página efetivamente reduz o espaço usado pelo SQL Server. No entanto, há alguns desafios que prejudicam a ampla adoção desse processo. Eles incluem:

• A compactação e a descompactação consomem ciclos de CPU do host. Especialmente para compactação de página, a sobrecarga de CPU pode ser substancial e ainda pode mostrar um impacto negativo no desempenho de consulta se a carga de trabalho estiver executando muitas atualizações. Um estudo mais detalhado feito pela equipe do SQL Server está disponível em: https://technet.microsoft.com/en-us/library/dd894051 (v=sql.100).aspx

• Por causa da possível sobrecarga de desempenho, a ativação da compactação de linha ou página precisa ser avaliada cuidadosamente no nível de tabela, de partição ou até mesmo de índice.

• A ativação da compactação exige a movimentação de dados para um novo formato de registro e a remoção de duplicações. Esse processo consome tempo e recursos. O custo inicial para ativar a compactação pode levar horas ou dias, dependendo do tamanho do banco de dados. Isso pode ser uma grande sobrecarga ao gerenciar um grande número de bancos de dados.

• A economia da compactação de espaço não pode ser recuperada até que os arquivos de banco de dados ou dados sejam reduzidos. Essa operação de redução é muito invasiva e consome tempo e recursos.

COMPACTAÇÃO DE ARRAY DO XTREMIO E COMPACTAÇÃO DE DADOS NATIVA DO SQL SERVER O recurso de compactação de dados do XtremIO em linha pode complementar a compactação de dados nativa do SQL Server de muitas maneiras.

Este estudo examinou um banco de dados não compactado, um banco de dados compactado em linha e um banco de dados compactado em página, tanto no array de armazenamento do XtremIO como em um disco local sem a compactação do armazenamento. Os dados de espaço usado do SQL Server foram capturados do relatório de utilização de disco do Management Studio do SQL Server para determinar o espaço de banco de dados real que é usado com os métodos de compactação diferentes. O contador de capacidade física usada do XtremIO foi usado para medir o consumo de armazenamento físico no XtremIO.

Como mostrado na Figura 8, a economia da compactação para compactação de linha, compactação de página e compactação do XtremIO é de 16%, 48% e 37%, respectivamente. O armazenamento de banco de dados não compactado no XtremIO reduz o espaço ocupado pelo armazenamento de 610 GB para 383 GB. Essa é uma economia de 37% de espaço sem exigir o uso de reconstruções demoradas de índice. Além disso, não há nenhum impacto no desempenho.

https://technet.microsoft.com/en-us/library/dd894051(v=sql.100).aspx

14

Figura 8. Compactação de array do XtremIO em comparação à compactação de dados nativa do SQL Server

O estudo mostrou que a compactação de página forneceu a maior economia de espaço, de 48%. Em comparação, a compactação de linha apresentou a menor economia de compactação, de 16%. As compactações de página e de linha estão sujeitas às restrições acima de sobrecarga de desempenho possível, complexidade operacional e o espaço não pode ser recuperado até depois da operação custosa de redução. Embora a compactação de página deva ser considerada para dados menos ativos ou de arquivamento, a compactação em linha do XtremIO parece oferecer uma alternativa melhor que a compactação de linha para todos os dados ativos.

As vantagens de usar a compactação em linha do XtremIO incluem:

• Boa economia de compactação em comparação com opções de compactação de dados nativa do SQL

• Aplicação automática para todos os bancos de dados do SQL Server, sem a necessidade de ativar qualquer botão adicional

• Impacto zero no desempenho das consultas existentes e sem sobrecarga da CPU do host

• Sem taxas de licenciamento adicionais

Para bancos de dados que já são compactados com compactação de linha ou de página, a compactação em linha do XtremIO pode maximizar ainda mais a economia por compactação. A Figura 9 mostra a capacidade física consumida pelos bancos de dados que foram compactados por linha ou página. A compactação em linha do XtremIO é capaz de oferecer uma economia adicional de 38% para um banco de dados compactado por linha e uma economia adicional de 7% em um banco de dados compactado por página.

15

A economia de compactação pode variar dependendo da capacidade de compactação de dados.

Figura 9. Usando a compactação de dados nativa do SQL Server com compactação de array do XtremIO

Sugestões de práticas recomendadas:

• Use a compactação em linha do XtremIO em vez de compactação de linha nativa do SQL Server para alcançar uma compactação automática de dados ativos. Use a compactação de página nativa do SQL Server para maximizar a economia de compactação de dados menos ativos ou de arquivamento.

• Use a compactação de linha ou de página nativa do SQL Server se o banco de dados é criptografado com criptografia de dados transparente do SQL Server. Um banco de dados criptografado de dados transparentes não obtém economia por compactação com a compactação em linha do XtremIO. Uma alternativa para resolver o problema de compatibilidade é considerar a criptografia de dados em repouso do XtremIO.

16

SERVIÇOS DE DADOS DO SQL SERVER E CÓPIA DO XTREMIO Durante um ciclo de vida de aplicativos do SQL Server, os administradores de banco de dados muitas vezes têm a necessidade de criar cópias de bancos de dados (por exemplo, para o serviço de dados de downstream e proteção de dados). Os métodos tradicionais de criação de cópias de bancos de dados normalmente envolvem os seguintes métodos:

• Backup/restauração — Backup do banco de dados na origem e restauração no destino.

• Cópia/conexão — Pausa temporária do serviço do SQL Server. Por exemplo, em um cenário de upgrade do lado a lado, é possível fazer uma cópia dos arquivos SQL da origem, e anexar a cópia a um SQL Server de destino.

Ambos os métodos requerem ler os dados do armazenamento, transferir dados da origem ao destino por meio da rede de host e gravar os dados de volta no armazenamento. O processo não é apenas demorado; ele também exige uma grande quantidade de recursos da CPU do host, memória e largura de banda de rede.

O XtremIO oferece uma nova alternativa para a implementação de cópias dos bancos de dados com serviços de cópia. Os serviços de dados de cópia do XtremIO são baseados em sua tecnologia única de redirecionamento em gravação, onde você é capaz de criar uma cópia totalmente gravável do banco de dados. Ele é 100% eficiente para espaço e não consome recursos do host.

No laboratório, um estudo foi realizado para comparar o tempo de implementação para um banco de dados de 1 TB usando:

• Backup e restauração tradicionais

• Cópia/conexão

• Serviços de cópia de dados do XtremIO

A Figura 10 exibe os resultados do estudo.

Figura 10. Comparações de tempo de implementação do banco de dados

O método de backup/restauração ou cópia/conexão de criação de cópias de banco de dados automaticamente obtém o benefício do recurso de desduplicação de dados em linha do XtremIO. As cópias de banco de dados não ocupam nenhum espaço de armazenamento adicional. No entanto, os dois métodos ainda exigem a transmissão de blocos de dados do armazenamento para o host e de volta para o armazenamento. O tempo de implementação está vinculado ao desempenho de leitura/gravação do armazenamento, largura de banda de rede e os recursos de host disponíveis. No estudo realizado, a implementação de uma cópia de um banco de dados de 1 TB usando o método de backup/restauração em um host ocioso, em uma rede de 10 GB situada no armazenamento do XtremIO, levou mais de 60 minutos. O método cópia/conexão usa o método de conexão mais eficiente para recuperar o banco de dados, mas ainda levou 30 minutos para implementar.

Com a nova alternativa de serviços de dados de cópia do XtremIO, a criação de uma cópia do banco de dados de 1 TB foi instantânea, enquanto a montagem e a recuperação do banco de dados levou menos de 5 segundos.

Os serviços de dados de cópia do XtremIO baseiam-se em sua tecnologia exclusiva de snapshot. Os snapshots podem ser somente leitura ou graváveis. A tecnologia de snapshot do XtremIO é implementada com o aproveitamento dos recursos de endereçamento de conteúdo do array juntamente com metadados na memória e os metadados de duas etapas do sistema (o que leva à redução de dados em linha).

17

Conforme mostrado pela Figura 11, quando um snapshot é criado, os metadados para o volume de origem tornam-se uma entidade “ancestral” que é compartilhada entre o volume de produção e o snapshot. Novos contêineres vazios são criados para alterações subsequentes no volume de origem de produção e no volume do snapshot. Assim, o ato de criar um snapshot é extremamente eficiente e exige apenas operação com metadados na memória. A operação de criação de um snapshot em um banco de dados é instantânea, não importando se ele é composto por alguns megabytes ou por centenas de terabytes.

Figura 11. Serviços de dados de cópia do XtremIO com base na tecnologia de snapshot

Como volumes do XtremIO têm provisionamento thin, os novos contêineres vazios criados para o processo de criação do snapshot não ocupam nenhum espaço. Portanto, a implementação de cópias de bancos de dados usando os serviços de dados de cópia é 100% eficiente para economia de espaço. O consumo de capacidade do snapshot ocorre apenas se uma alteração exigir gravação de um novo bloco.

Sugestão de prática recomendada:

• Use serviços de dados de cópia do XtremIO para uma rápida implementação de cópias de banco de dados com eficiência de armazenamento.

18

CONSIDERAÇÕES SOBRE PLANEJAMENTO E OPERAÇÕES DE ARMAZENAMENTO

PROVISÕES PARA SQL SERVER O SQL Server mapeia um banco de dados ao longo de um conjunto de arquivos no disco. As informações de registro de transações e dados são armazenadas em arquivos separados. Para maximizar o desempenho e a eficiência operacional do SQL Server, a otimização do layout de arquivos de banco de dados tem sido o ponto focal da discussão por muitos anos. Nesta seção, podemos examinar as considerações e recomendações comuns e discutir a relevância para o provisionamento de um banco de dados do SQL Server no XtremIO.

As considerações comuns para o layout de arquivos de banco de dados do SQL Server incluem:

• Configuração do RAID

• Separação de arquivos do SQL Server

• Número de LUNs

• Número de arquivos

CONFIGURAÇÃO DO RAID O SQL Server normalmente apresenta as recomendações a seguir no RAID, ao considerar aspectos como desempenho, proteção de dados e considerações sobre custo:

• Use RAID 10 para arquivos de registros e dados de usuário para obter o melhor desempenho e disponibilidade. No entanto, quando o custo é uma preocupação, os dados podem ser alocados no RAID 5 ou equivalente.

• Para gravação intensa TempDB, use RAID 10. RAID 0 é uma opção se o custo é um problema. No entanto, o sistema pode ficar indisponível durante a falha de disco se RAID 0 é usado. RAID 5 é suficiente para TempDB com uso intenso de não gravação.

• Use um grande número de discos menores em vez de um número menor de grandes discos.

Ao implementar o SQL Server no XtremIO, as considerações sobre a configuração RAID não são mais relevantes, pelos seguintes motivos:

• O sistema XtremIO tem um RAID de paridade dupla integrado de “Autocorreção” como parte de sua arquitetura.

• O XDP (XtremIO Data Protection) é projetado para aproveitar as propriedades específicas da mídia flash e a arquitetura de armazenamento de conteúdo endereçável do XtremIO.

• Com a arquitetura de armazenamento de conteúdo endereçável, os arquivos do SQL Server são automaticamente distribuídos entre todos os SSDs e processados por todas as controladoras de armazenamento no cluster.

Sugestões de práticas recomendadas

• Não é necessária nenhuma configuração de RAID. Um RAID otimizado para flash (XDP) é integrado e pré-configurado no XtremIO.

SEPARAÇÃO DE ARQUIVOS Recomendações de SQL Server comuns:

• Alocar LUNs separadas para dados, registro e arquivos TempDB.

• Alocar discos físicos separados para LUNs usadas pelos registros e dados.

• Alocar LUNs separadas para tipos de carga de trabalho diferentes (por exemplo, OLTP em comparação com lógica analítica).

A origem para a separação de arquivos é provocada por características de I/O do SQL Server e a otimização para a mídia de disco rígido rotacional menos eficiente usada no armazenamento tradicional.

O SQL Server acessa os arquivos de registros e dados com padrões de I/O muito diferentes. Enquanto o acesso aos arquivos de dados é principalmente aleatório por natureza, o acesso de arquivos de registros de transação é apenas sequencial. O armazenamento tradicional desenvolvido com a mídia de disco rotacional requer novo posicionamento da cabeça do disco para acesso aleatório de gravação e leitura. Portanto, dados sequenciais são muito mais eficientes do que o acesso aleatório aos dados. A separação dos arquivos que têm padrões diferentes de acesso aleatório versus sequencial ajuda a minimizar movimentos da cabeça disco e, portanto, otimiza o desempenho de armazenamento.

Esta diretriz não se aplica mais ao implementar o SQL Server no XtremIO Storage Array porque:

• O XtremIO usa todos os discos de estado sólido (SSDs). Os SSDs não têm peças móveis, e não importa onde o bloco de dados físico está localizado. Não há nenhum movimento na cabeça do disco para o acesso de leitura/gravação.

19

• Com a arquitetura exclusiva do XtremIO, os dados são igualmente distribuídos de forma inteligente entre todos os SSDs por seu mecanismo de armazenamento de conteúdo endereçável. Isso maximiza a capacidade de processamento de todas as controladoras de armazenamento.

Não há nenhum ganho de desempenho na alocação de LUNs diferentes para dados do SQL Server, registros, arquivos de TempDB ou tipos de carga de trabalho diferentes. No entanto, de uma perspectiva de eficiência operacional, deve-se considerar a separação de arquivos de banco de dados temporário dos arquivos de banco de dados, ou seja, dados do usuário e arquivos de registro de transação. O banco de dados temporário (TempDB) é um recurso global que é compartilhado por todos os bancos de dados dentro de uma instância do SQL Server. É um espaço de trabalho temporário que é recriado sempre que uma instância do SQL Server é iniciada. Ao usar a tecnologia de snapshot do XtremIO para criar um backup, implemente cópias de um banco de dados ou replique um banco de dados para um local secundário, separando o TempDB que permitiria que o snapshot fosse aplicado aos arquivos de banco de dados somente, removendo, portanto, qualquer ruído desnecessário.


• Não há motivos relacionados ao desempenho necessários para a separação de arquivos.

• Para o uso mais eficiente de serviços de dados de cópia ou replicação de armazenamento, considere o seguinte:

o Separe TempDB de registros e arquivos de dados do usuário.

o A menos que sua transação comercial abranja vários bancos de dados, não compartilhe a LUN com vários bancos de dados. Um volume/LUN é a menor unidade de operação de snapshot.

NÚMERO DE LUNS O SQL Server permite que objetos de banco de dados e arquivos sejam agrupados em grupos de arquivos. Os grupos de arquivos proporcionam os meios para separar os objetos de usuário um do outro em diferentes LUNs ou discos físicos. Como um grupo de arquivos não pode ser distribuído com qualquer arquivo, você nunca pode ter dados de objetos atribuídos a diferentes grupos de arquivos que residem no mesmo arquivo físico.

As práticas recomendadas da configuração do SQL Server são:

• Use grupos de arquivos para requisitos de administração, como disponibilidade do banco de dados parciais e backup/restauração.

• Use arquivos de dados para “fracionar” o banco de dados em sua configuração específica de I/O (por exemplo, para LUNs e discos físicos).

• A menos que você esteja familiarizado com o aplicativo, evite a otimização em excesso do I/O, colocando objetos seletivamente em spindles separados.

Esta diretriz pode ser significativamente simplificada para a maioria das implementações de SQL Server:

• Em geral, uma única LUN é capaz de gerar um sistema de armazenamento do XtremIO com sua capacidade máxima se o aplicativo está impulsionando o volume de atividades de I/O.

• Vários grupos de arquivos devem continuar a ser usados para aprimorar a disponibilidade de banco de dados e gerenciar o particionamento de tabela.

• Não é mais necessário otimizar mais I/Os ao colocar seletivamente objetos em spindles separados. Uma única LUN por banco de dados oferece as necessidades de desempenho para a maioria das implementações de SQL Server. Você pode manter configuração da LUN simples e padrão com o aproveitamento do recurso do XtremIO de equilibrar automaticamente a carga de trabalho e os dados.


• Um única LUN por banco de dados é suficiente para a maioria dos cenários de implementação. O XtremIO automaticamente cuida da distribuição uniforme de dados e garante o processamento máximo em paralelo.

• Para implementação em grande escala do SQL Server com uso intenso de I/O, considere as seguintes opções de ajustes:

o Aumente o tamanho da fila de LUN. Para obter detalhes, consulte Tamanho da fila.

o Se os I/Os excederem o tamanho de fila máximo permitido, distribua os arquivos de banco de dados entre várias LUNs. Isso aumenta o tamanho da fila geral além do valor máximo configurável por LUN.

• Se o armazenamento é dedicado a um só banco de dados do SQL Server, um mínimo de quatro LUNs/volumes deve ser criado no cluster do XtremIO. Isso tira proveito total das capacidades de processamento paralelo de várias controladoras de armazenamento no cluster e maximiza o desempenho.

20

NÚMERO DE ARQUIVOS O SQL Server “fraciona” alocações em arquivos em um grupo de arquivos, usando um algoritmo de preenchimento proporcional. Cada arquivo tem seu próprio espaço livre da página (PFS), páginas de mapa de alocação global (GAM) e de mapa compartilhado de alocação global (SGAM). Essas “páginas de administração” especiais rastreiam o espaço livre e a alocação no arquivo. Se os arquivos no grupo são do mesmo tamanho (conforme recomendado pelo SQL Server), a alocação é de round-robin.

Ter vários arquivos de dados adiciona vantagens de escalabilidade para cargas de trabalho com uso intenso de alocação. Isso é especialmente válido para o TempDB, no qual atividades tendem a ter muita atividade de alocação.

Os comportamentos de alocação do SQL Server não se alteram em execução no XtremIO. Essa recomendação deve ser seguida para otimizar a implementação de TempDB e as melhorias de cargas de trabalho com muita atividade de inserção de atividades.


• Siga as recomendações do SQL Server sobre criação de vários arquivos de dados para um banco de dados de usuário e a criação de TempDB. Para obter recomendações do SQL Server, consulte https://support.microsoft.com/en-us/kb/2154845.

Ao implementar o SQL Server no XtremIO, lembre-se de que muitas das considerações e recomendações sobre o armazenamento existentes do SQL Server concentram-se em torno da mídia de disco rígido rotacional tradicional. Além disso, o Storage Array do XtremIO foi desenvolvido com a mídia SSD mais avançada, que é otimizada para acesso aleatório e sequencial. O mecanismo inteligente de conteúdo e a arquitetura scale-out do sistema também simplificam significativamente a complexidade do armazenamento de provisionamento para um SQL Server. Com o XtremIO, os administradores de banco de dados devem estar livres de preocupações com o RAID, contagens de eixos ou qualquer uma das configurações de armazenamento destacadas.

ATENDENDO ÀS NECESSIDADES DE DADOS DE DOWNSTREAM Em todo o ciclo de vida de aplicativo do SQL Server, os administradores de banco de dados talvez precisem implementar cópias do banco de dados de produção para consumo de dados de downstream. A manutenção de ambientes de teste e desenvolvimento e a necessidade de dados de geração de relatórios quase em tempo real são os dois casos de uso principais para esse cenário. Os administradores de banco de dados podem implementar cópias do banco de dados no XtremIO usando metodologias tradicionais e aproveitar a eficiência de armazenamento que o XtremIO oferece. Um modo mais eficiente de atender às necessidades de dados de downstream de serviço é obtido por meio da implementação com serviços de dados de cópia do XtremIO.

TESTE E DESENVOLVIMENTO Enquanto recursos do aplicativo continuam a ser desenvolvidos, testados e implementados para produção, cópias de banco de dados de produção existentes são necessárias para apoiar os esforços de desenvolvimento e para realizar os testes de aceitação do usuário. Como o tamanho do banco de dados de produção continua aumentando, os administradores de banco de dados estão enfrentando alguns desafios sérios, entre eles:

• Como implementar e atualizar ambientes de teste e desenvolvimento com eficiência? Métodos tradicionais de backup/restauração demoram muito e fazem um uso muito intenso de recursos.

• Onde encontrar o armazenamento adicional para hospedar várias cópias de teste e desenvolvimento do banco de dados?

• Como garantir que as cópias de teste e desenvolvimento sejam executadas em um armazenamento com desempenho similar à produção?

https://support.microsoft.com/en-us/kb/2154845

21

Os serviços de dados de cópia do XtremIO podem ser utilizados para oferecer cópias de teste e desenvolvimento dos dados de produção. Várias cópias mestras podem ser criadas, 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. Várias cópias podem ser criadas a partir de cada cópia mestre e apresentadas a várias equipes de desenvolvimento. O provisionamento de cópias é um processo fácil e instantâneo. Os checkpoints para monitorar os estágios do desenvolvimento podem ser criados por meio de snapshots de vários níveis.

Figura 12. Implementar ambientes de teste e desenvolvimento com serviços de dados de cópia do XtremIO

Os serviços de dados de cópia do XtremIO permite que as cópias sejam criadas com base na demanda da eficiência máxima de negócios, em vez de com base nas limitações de desempenho ou capacidade de armazenamento. As cópias do banco de dados podem ser criadas instantaneamente, sem consumir armazenamento adicional. Com a abundância de IOPS e a latência baixa e consistente que o XtremIO oferece, teste e desenvolvimento podem aproveitar o mesmo desempenho de produção.


• Use os serviços de cópia para implementar cópias do banco de dados para fins de teste e desenvolvimento.

• Use o recurso de snapshot multinível para limpar os dados confidenciais antes da apresentação do banco de dados para fins de teste ou desenvolvimento.

• Use o recurso de snapshot multinível para criar checkpoints ou ramificações para desenvolvimento.

RELATÓRIOS QUASE EM TEMPO REAL Um dos principais objetivos de um banco de dados é a geração de relatórios de serviço. As consultas de geração de relatórios são normalmente prolongadas e requerem uma grande quantidade de recursos de CPU e memória (já que pesam no disco/I/Os). A combinação de geração de relatórios com as atividades do usuário on-line na mesma unidade de computação pode causar conflito de acesso de recursos, bloqueio e problemas de impasses. A capacidade de transmitir a geração de relatórios e separar as atividades de geração de relatórios de cargas de trabalho principais do usuário on-line ajuda a reduzir a carga e melhorar o desempenho no ambiente de produção. Os serviços de dados de cópia do XtremIO permitem que você crie facilmente uma solução que dimensiona horizontalmente um banco de dados para fornecer quase em tempo real cópias dos dados de produção para fins de geração de relatórios. A solução também dá suporte a atualizações periódicas dos dados de produção por meio da acumulação de atualizações de bancos de dados de geração de relatórios.

A solução baseia-se no SQL SSD (SQL Server Scalable Shared Database, banco de dados compartilhado dimensionável do SQL Server). Para obter detalhes do SQL SSD, consulte https://technet.microsoft.com/en-us/library/ms345584 (v=SQL.105).aspx.

A solução para o uso de serviços de dados de cópia do XtremIO para geração de relatórios de scale-out aprimorou o SQL SSD com clonagem rápida de snapshot e atualização de recursos que são nativos do XtremIO. A tabela a seguir mostra as etapas detalhadas para a solução proposta.

https://technet.microsoft.com/en-US/library/ms345584(v=SQL.105).aspx

22

HORA FASE FIGURA

T0 Essa fase define o processo de construção para criar os bancos de dados iniciais de geração de relatórios. 1. Crie um snapshot mestre

de volumes de banco de dados em T0.

2. Crie os snapshots de

segundo nível com base no snapshot mestre.

3. Monte os snapshots de

segundo nível para todos os servidores de geração de relatórios.

Figura 13. Fase inicial de geração de relatórios quase em tempo real

23

HORA FASE FIGURA

T1 Esta fase define o processo de atualização periódica dos bancos de dados de geração de relatórios. Nessa fase, metade dos bancos de dados de geração de relatórios foi atualizada por vez e a abordagem de atualização acumulada foi usada para maximizar a disponibilidade do serviço de geração de relatórios. 1. Atualize o snapshot mestre

com dados de produtos atuais em T1.

2. Coloque metade da geração

de relatórios de bancos de dados em modo off-line. Relatórios podem ser atendidos sem interrupção com a metade restante.

3. Desmonte os discos de

propriedade dos bancos de dados de geração de relatórios off-line.

4. Use o recurso de atualização

de snapshot para atualizar os snapshots de segundo nível usando o snapshot mestre.

5. Monte os discos para todos os

bancos de dados de geração de relatórios off-line.

6. Coloque os bancos de dados

em modo on-line. 7. Repita as etapas 2 a 6 para

atualizar a segundo metade de banco de dados de geração de relatórios.

Figura 14. Atualização de geração de relatórios quase em tempo real: Fase I

Figura 15. Atualização de geração de relatórios quase em tempo real: Fase II

Figura 16. Atualização de geração de relatórios quase em tempo real: Fase III

24

ATUALIZANDO DADOS DE DOWNSTREAM COM ATUALIZAÇÃO DE SNAPSHOT Se você estiver usando serviços de dados de cópia do XtremIO para fornecer serviços de dados para teste, desenvolvimento ou geração de relatórios, o snapshot acabará se tornando ultrapassado e perderá sua utilidade. Deve haver um processo em vigor para periodicamente atualizar os dados de geração de relatórios, ou oferecer novas versões do banco de dados para fins de teste ou desenvolvimento. O recurso de atualização de snapshot do XtremIO simplifica o processo para atualizar um snapshot obsoleto.

O processo de atualização de um banco de dados de downstream exige a conclusão das cinco etapas a seguir:

1. Desconecte o banco de dados obsoleto

2. Desmonte os volumes de banco de dados

3. Execute a atualização de snapshot no XtremIO

4. Monte os volumes

5. Conecte o banco de dados atualizado

Para obter scripts detalhados de cada etapa, consulte o Apêndice III: Atualização de snapshot.


• Use os serviços de dados de cópia para criar réplicas secundárias legíveis para geração de relatórios quase em tempo real, sem a implementação dos AlwaysOn Availability Groups.

• Use snapshots de vários níveis para sincronizar os dados em todas as instâncias de geração de relatórios.

MANUTENÇÃO DO BANCO DE DADOS Em todo o ciclo de vida de aplicativo do SQL Server, os bancos de dados precisam ser mantidos para garantir que não exista nenhum problema de integridade de dados. Enquanto as tarefas de manutenção de banco de dados ajudam a manter o SQL Server em execução na sua melhor condição, a execução das tarefas pode ocupar uma grande quantidade de recursos do host. Isso afeta o desempenho de um SQL Server de produção. Os serviços de dados de cópia do XtremIO permitem a rápida implementação de cópias de banco de dados com eficiência de armazenamento. As tarefas de manutenção de banco de dados de atividades com uso intenso de recursos podem ser descarregadas em uma unidade de computação secundária para minimizar o impacto para a carga de trabalho de produção.

Figura 17. Liberação de tarefas de manutenção de banco de dados

25

AJUSTE DE CONSULTA Conforme os aplicativos continuam a serem desenvolvidos com novos recursos adicionais, os índices existentes no banco de dados podem não ser suficientes para comportar mais atividades do usuário. O ajuste de índice é parte da vida diária para os administradores de banco de dados do SQL Server. O ajuste de consulta eficaz exige a execução em um banco de dados semelhante ao de produção e pode necessitar de várias versões e passar por erros. Não é viável tentar o ajuste em um ambiente de produção. No entanto, seria difícil tentar obter uma cópia do banco de dados de produção de tamanho de terabyte para consulta de ajustes, tanto de uma perspectiva de requisito de capacidade de armazenamento, como de uma perspectiva de tempo de implementação. Esse é um dilema enfrentado por muitos administradores de banco de dados do SQL Server com armazenamento tradicional.

Os serviços de dados de cópia do XtremIO podem criar um snapshot totalmente gravável de um banco de dados instantaneamente, sem ocupar qualquer espaço de armazenamento físico adicional. Ao conectar o snapshot a uma instância do SQL Server secundária, você pode ter um ambiente dedicado para fins de ajustes sem impacto na carga de trabalho de produção.

DBCC DBCC CHECKDB é uma tarefa de manutenção que verifica a integridade lógica e física de todos os objetos no banco de dados. É uma tarefa importante a ser realizada, pois ela garante a integridade do banco de dados do SQL Server. No entanto, DBCC CHECKDB pode ser muito conturbado para um SQL Server de produção. O pool de buffer do SQL Server pode ser completamente destruído conforme o CHECKDB lê todas as páginas de todos os objetos. A execução de DBCC CHECKDB em um servidor de produção não é uma prática recomendada. Como resultado, muitos administradores de banco de dados passam por um longo processo para restaurar uma cópia do banco de dados de produção em um ambiente de não produção para realizar DBCC CHECKDB. No entanto, outros podem não ter o luxo de executar DBCC CHECKDB e, assim, incorrer em mais riscos de corrupção dos dados.

Com os serviços de dados de cópia do XtremIO, os administradores de banco de dados podem facilmente conectar uma cópia de snapshot do banco de dados de produção a uma instância do SQL Server secundária para executar DBCC CHECKDB. Além disso, não há preocupação com a destruição do pool de buffer do SQL Server de produção. Com o recurso de atualização de snapshot do XtremIO, a integridade do banco de dados pode ser verificada periodicamente em uma cópia atualizada do snapshot para garantir a integridade contínua do banco de dados.


• Descarregue tarefas de manutenção de banco de dados com uso intensivo de recursos, como o ajuste de consulta e o DBCC CHECKDB para uma unidade de computação secundária, usando cópias de bancos de dados criados com os serviços de dados de cópia.

BACKUP/RESTAURAÇÃO O backup é essencial para fornecer proteção de dados para um banco de dados do SQL Server. O backup do banco de dados do SQL Server e a execução em um armazenamento tradicional podem ser demorados,fazerem uso intenso de recursos e requerem uma grande quantidade de armazenamento. Uma estratégia comum de armazenamento para backup envolve fazer primeiro o backup de SAN local e, em seguida, copiar o backup para um compartilhamento de arquivos de rede. Depois, copiar os backups para um sistema de arquivamento no local, além da criação de cópias de transporte em um local externo.

Os serviços de dados de cópia do XtremIO podem melhorar significativamente o backup/restauração de banco de dados de SQL Server para a SAN local de várias maneiras:

• Backup/restauração rápida com a tecnologia de snapshot

• Descarregamento de processos de backup com uso intenso de recursos a unidade de computação secundária

• Armazenamento de várias imagens de backup com eficiência com a tecnologia de desduplicação de dados em linha

A restauração de um backup de snapshot não exige esforços. Os administradores de banco de dados podem facilmente executar uma recuperação completa do banco de dados, ou montar o snapshot com um nome de banco de dados diferente para restaurar parcialmente tabelas ou linhas de um banco de dados.

26

BACKUP/RESTAURAÇÃO DE SNAPSHOTS COM O EMC APPSYNC O XtremIO integra-se com o EMC AppSync para fornecer um recurso de backup e restauração de snapshot consistente com aplicativos para SQL Server. O AppSync interage com a VDI (Virtual Desktop Interface, inteface de desktop virtual) do SQL Server para coordenar o backup de snapshot com o XtremIO.

Neste estudo, uma comparação foi realizada para comparar o tempo de backup de um banco de dados de 1 TB usando o método tradicional de backup do SQL e o backup de snapshot consistente com aplicativos usando o AppSync. O tempo de backup foi reduzido de 28 minutos para 1 minuto ao usar o backup de snapshot consistente com aplicativos. Como o backup de snapshot é uma operação completa de metadados, sem qualquer necessidade de copiar ou mover dados físicos, quanto maior banco de dados, maior a diferença de tempo de backup.

O AppSync dá suporte a backup completo e a backup somente cópia com snapshot consistente com aplicativos. Com a opção de backup completo, é feito o backup dos dados e da parte ativa da registro de transação. Um backup completo pode ser restaurado em estado NORECOVERY para permitir que os registros de transações adicionais sejam restaurados. Essa opção é compatível com recuperação point-in-time com registros de transação.

Um backup somente cópia faz o backup do banco de dados sem afetar a sequência de um backup convencional. Essa opção cria um backup do banco de dados sem interferir nos aplicativos de backup de terceiros que podem estar criando backups diferenciais e/ou completos dos bancos de dados do SQL Server.

A criação de um backup completo de banco de dados usando o recurso de um snapshot consistente com aplicativos, o AppSync, é uma forma eficaz de se obter uma cópia recuperável rápida do banco de dados no armazenamento local. Para proteger ainda mais bancos de dados em caso de um desastre catastrófico ou falha de armazenamento físico que vai muito além de recuperação, os volumes de snapshot devem ser copiados para o compartilhamento de arquivos de rede, para o sistema de arquivamento no local e para o armazenamento externo para obter uma proteção completa.


• Descarregue backups em uma unidade de computação secundária, usando os serviços de dados de cópia.

• Crie backups de banco de dados completos e rápidos direcionados para armazenamentos usando snapshots consistentes com aplicativos do AppSync. Copie os volumes de snapshot para armazenamentos secundários para recuperação de desastres e proteja dados contra falhas de armazenamento físico irrecuperáveis.

• Use o tipo de recuperação flexível de AppSync para restaurar um banco de dados no estado NORECOVERY para fins de recuperação point-in-time, usando backups de registros de transação.

UPGRADE Conforme aplicativos e o SQL Server continuam a amadurecer, mais recursos são lançados. Os ambientes precisam receber upgrade para aproveitar as vantagens dos novos recursos. Os serviços de dados de cópia do XtremIO podem aprimorar as experiências de upgrade, simplificando o processo de upgrade, minimizando o tempo de inatividade e reduzindo os riscos de upgrade.

Com a capacidade de criar uma cópia gravável instantânea do banco de dados sem usar qualquer espaço de armazenamento adicional, use os serviços de dados de cópia do XtremIO para:

• Testar o upgrade em uma cópia do banco de dados para resolver possíveis problemas.

• Simular o processo de upgrade usando uma cópia do banco de dados para obter uma percepção real de quanto tempo levará o upgrade.

• Proteger o banco de dados ao obter uma cópia dele antes do upgrade. Se o upgrade falhar por qualquer motivo, basta apontar a instância do SQL Server na cópia e recuperar.


• Execute um teste de upgrade em uma cópia de snapshot para identificar possíveis problemas de upgrade e medir o tempo de upgrade.

• Criar um backup de snapshot antes do upgrade, caso haja necessidade de failback.

27

CONSIDERAÇÕES SOBRE A IMPLEMENTAÇÃO

MÚLTIPLOS CAMINHOS Caminhos múltiplos facilitam o roteamento de I/O em caminhos de hardware redundantes ao conectar um host ao armazenamento. Se qualquer componente do caminho de armazenamento falhar (por exemplo, cabos, adaptadores de barramento do host [HBAs], switches, controladoras de armazenamento ou até mesmo a energia), o software de múltiplos caminhos redefine a conexão e transmite a solicitação ao longo de um caminho alternativo. Aplicativos como o SQL Server podem continuar a atender I/Os sem nenhuma interrupção. Além de proteger aplicativos de falhas de caminho de hardware, múltiplos caminhos também aprimoram o desempenho dos aplicativos ao realizar o balanceamento de carga de I/Os em todos os caminhos disponíveis para otimizar recursos, maximizar o throughput e reduzir a latência de I/O.

O XtremIO é compatível com os seguintes produtos de software de múltiplos caminhos nativos de fornecedores ou múltiplos caminhos usando o EMC PowerPath:

• O XtremIO é compatível com o recurso de múltiplos caminhos nativo utilizando o Microsoft Multipath I/O (MPIO) nativo da Microsoft com Windows Server 2008 e posteriores. Para operação ideal com o armazenamento do XtremIO, configure a política Least Queue Depth para MPIO para dispositivos apresentados por meio do XtremIO. Utilizando essa política, o I/O é enviado pelo caminho com o menor número de solicitações de I/O pendentes atualmente.

• O XtremIO é compatível com a tecnologia de múltiplos caminhos nativa (NMP) do VMware vSphere. Para um melhor desempenho, recomenda-se:

o Configurar a política de seleção de caminhos nativa round robin nos volumes XtremIO apresentados ao host ESX.

o Configurar o caminho de Round Robin de recurso de múltiplos caminhos nativo do vSphere alternando a frequência dos volumes do XtremIO do valor padrão (1000 pacotes de I/O) para 1.

• O XtremIO é compatível com o EMC PowerPath. Para obter detalhes sobre instalação e a configuração do EMC PowerPath com suporte a classes nativas do XtremIO no host, consulte o Guia de Administração e Instalação no Windows do EMC PowerPath ou o Guia de Administração e Instalação do EMC PowerPath no VMware vSphere. O guia fornece as informações necessárias para posicionar os volumes do XtremIO sob o controle do PowerPath e garante a melhor distribuição e disponibilidade de carga entre os caminhos de I/O para o armazenamento do XtremIO.

Para obter etapas detalhadas sobre a habilitação e a configuração de múltiplos caminhos para plataformas de host diferentes, consulte o Guia de Configuração de Host do XtremIO em https://support.emc.com/docu56210_XtremIO-2.2.x---4.0-Host-Configuration-Guide.pdf?language=en_US.


• Para Windows 2008 e posteriores, use a política Least Queue Depth com Microsoft Multipath IO nativo da Microsoft (MPIO).

• Para SQL Server no VMware vSphere, use a política de seleção de caminhos nativos round-robin do VMware e defina a frequência de alternância como um.

• Para obter práticas recomendadas com o PowerPath, consulte o Guia de Administração e Instalação no Windows do EMC PowerPath ou o Guia de Administração e Instalação do EMC PowerPath no VMware vSphere.

TAMANHO DA FILA Os drivers de dispositivo SCSI têm um parâmetro configurável chamado tamanho da fila, que determina o número máximo de comandos SCSI ou solicitações de I/O pendentes que uma determinada LUN pode ter uma só vez. Se o valor de tamanho da fila for muito baixo, os I/Os em excesso são enfileirados no aplicativo. À medida que a latência de I/O do SQL Server aumenta, o throughput pode ser afetado. Se o valor de tamanho da fila for muito alto e o sistema de armazenamento não consegue acompanhar o processamento de I/O, o sistema de armazenamento pode ficar sobrecarregado, afetando assim o desempenho de I/O para todos os aplicativos em execução no sistema de armazenamento.

Uma configuração de tamanho da fila ideal deve se esforçar para obter um projeto de sistema balanceado e considerar o seguinte:

• Requisitos de throughput e IOPS do SQL Server

• Número de LUNs usado pelo SQL Server

• O máximo de IOPS e throughput que o sistema de armazenamento aceita

• O número de hosts e iniciadores que estão conectados ao sistema de armazenamento

• Tipos de HBA (marca e largura de banda) usados para conectar os hosts e o sistema de armazenamento

https://support.emc.com/docu56210_XtremIO-2.2.x---4.0-Host-Configuration-Guide.pdf?language=en_US


28

O tamanho da fila é por LUN e não por iniciador. Um valor de tamanho de fila pré-configurado de fornecedor de HBA (Host Bus Adapter, adaptador de barramento de host) é definido como 32. O valor pode variar de acordo com o fornecedor ou em algumas implementações de virtualização. Cada porta de iniciador é capaz de dar suporte a um número muito maior de solicitações de I/O simultâneas, normalmente variando em milhares, dependendo da implementação do fornecedor específico.

A maioria das configurações do fornecedor para tamanho da fila padrão é otimizada para sistemas de armazenamento de disco rígido tradicional. Um array totalmente flash como o XtremIO pode processar as solicitações de I/O em microssegundos. A arquitetura exclusiva de scale-out do sistema também significa que ele pode processar milhões de solicitações de I/O simultâneas. Além disso, dada a simplicidade de projeto do XtremIO, o número de LUNs pode possivelmente ser reduzido para uma única LUN. O tamanho de fila padrão pode se tornar o fator limitante para prejudica o desempenho do SQL Server.

Para operação ideal com o armazenamento do XtremIO, considere o seguinte:

• Defina o tamanho da fila como 256. A configuração de tamanho da fila é uma configuração global. Se você tiver um ambiente misto com um host conectado a várias plataformas de armazenamento, consulte recomendações sobre todas as plataformas de armazenamento para evitar problemas de desempenho.

• Para implementação no ambiente do VMware vSphere, o tamanho da fila é ainda mais controlado por limites definidos no adaptador vSCSI e no VMKernel Scheduler.

• A configuração de tamanho de fila deve ser definida em todas as camadas, inclusive HBA físicas, o adaptador vSCSI e o VMKernel Scheduler para garantir a configuração adequada.

• Para obter detalhes sobre como alterar o tamanho da fila do adaptador vSCSI, consulte: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1267

• Para obter detalhes sobre a configuração de política de admissão do VMKernel scheduler, consulte: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1268 Recomendamos a configuração Disk.SchedNumReqOutstanding no valor máximo compatível de 256 para volumes do XtremIO.

• Para obter etapas detalhadas sobre a configuração de tamanho da fila com diferentes implementações de fornecedores HBA, consulte o Guia de Configuração de Host do XtremIO em: https://support.EMC.com/docu56210_XtremIO-2.2.x---4.0-Host-Configuration-Guide.PDF?Language=en_US.


• Defina o tamanho da fila de LUN como 256.

• Para implementação do SQL Server no VMware vSphere:

o Defina o tamanho da fila em todas as camadas, inclusive HBA físicas, adaptador vSCSI e VMKernel Scheduler, ao configurar a fila para SQL Server em execução no VMware vSphere.

o Defina schednumreqoutstanding de disco como 256.

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1267

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1268


29

TAMANHO DE SETOR FÍSICO DE 512 B EM COMPARAÇÃO A 4 KB O XtremIO pode apresentar o tamanho de setor físico de 512 B ou 4 KB para Windows e para o SQL Server. Como parte das opções de “volume de criação”, você pode especificar um volume a ser usado tanto de 512 LBs como 4 KB LBs. Até recentemente, o Microsoft Windows e o SQL Server eram gravados com base no tamanho de setores de disco de 512 B. A Microsoft começou o suporte nativo para o tamanho de setor de 4 KB com o lançamento do Windows 2012. Para obter mais detalhes sobre o suporte, consulte:

• https://support.microsoft.com/en-us/kb/2510009

• https://support.microsoft.com/en-us/kb/926930

O SQL Server armazena dados em páginas de unidade 8 K. Usar o tamanho de setor de 4 KB permite que uma página de dados do SQL Server ocupe dois setores físicos em vez de 16 setores físicos com o tamanho de setor de 512 B. O tamanho do setor de 4 KB alinha-se com eficiência ao limite de 8 KB de página de dados do SQL Server e reduz a quantidade de sobrecarga de metadados. O efeito da melhoria do metadados é muito visível com uma cópia ODX que opere com muitos metadados. Com uma cópia ODX de um conjunto de arquivos do SQL Server com o tamanho total de 1 TB, a largura de banda média para copiar de 512 B para o volume de 512 B é de 6 GB/s. A largura de banda média para copiar de 4 KB para o volume de 4 KB é de 12 GB/s.

Apesar de o tamanho do setor de 4 KB oferecer melhor capacidade de armazenamento com menos sobrecarga de metadados, estas são algumas restrições das quais você deve estar ciente antes de apresentar volumes de tamanho de setor de 4 KB ao SQL Server:

• As gravações de registro de transações do SQL Server sempre estão alinhadas com o tamanho físico do setor. O tamanho de block de gravação do registro pode ser um ou um múltiplo do tamanho físico do setor, com até 60 KB. Com um tamanho de setor de 4 KB, aplicativos que executam um grande número de operações reduzidas de gravação com confirmações frequentes podem resultar em maior uso de espaço de registro.

• As versões anteriores do SQL Server impedem a restauração ou a conexão a um banco de dados em um ambiente que tem um tamanho de setor físico maior que o tamanho do banco de dados do setor no qual ele foi formatado. Para obter mais detalhes, consulte: http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx

• As versões do SQL Server anteriores ao SQL Server 2005 tinham um sistema e uma amostra bancos de dados com base em 512 B. Portanto, não é possível definir as versões legadas do SQL Server em um volume de setores de 4 KB, já que ele falhará.

• Ao colocar o TempDB e o bancos de dados de usuário em volumes diferentes, lembre-se de que as criações de banco de dados e TempDB usam o tamanho de setor que é relatado pelo sistema de operação no momento da criação, com base no tamanho do setor do volume no qual o arquivo está localizado. A variação de tamanhos de setor pode ocorrer quando os arquivos de banco de dados ou arquivos de banco de dados temporário estão localizados em volumes com um tamanho de setor físico diferente. A variação de tamanho do setor nos caminhos de I/O deve ser evitada para impedir qualquer acesso a dados abaixo do ideal.

• Se você executar o SQL Server em um ambiente virtual, esteja ciente de que o tamanho de setor físico de 4 KB ainda não é aceito por todos os fornecedores de hipervisor. Por exemplo, o VMware vSphere não é atualmente compatível com o tamanho de setor de 4 KB. Para obter mais detalhes sobre suporte do Windows Hyper-V e VMware vSphere, consulte:

o http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2091600

o https://support.microsoft.com/en-us/kb/2515143

Antes de implementar um banco de dados do SQL Server, sempre verifique o tamanho de setor físico dos volumes provisionado para o SQL Server. Isso é realizado executando FSUTIL. A Figura 18 mostra um exemplo de resultados da execução de FSUTIL em um volume de setor de 512 B e de 4 KB.



http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx



30

Figura 18. Verificar o tamanho de setor de volume usando FSUTIL

31

Os administradores de banco de dados do SQL Server também podem executar um fileheader dbcc para verificar o tamanho de setor do banco de dados (que é determinado durante a criação do banco de dados) e o tamanho de setor físico do volume no qual o banco de dados reside atualmente. A Figura 19 mostra resultados de amostra de um fileheader dbcc para um banco de dados criado no tamanho do setor de 4 KB e um banco de dados criado no tamanho do setor de 512 B. A coluna SectorSize mostra que o tamanho do setor no qual o banco de dados foi criado. A coluna ActualSectorSize mostra que o tamanho de setor do volume no qual o banco de dados está atualmente. Para obter melhor desempenho, o valor de SectorSize deve ser igual ao de ActualSectorSize.

Figura 19. Exemplo de Fileheader dbcc

DETERMINANDO QUAL TAMANHO DE SETOR USAR O uso do tamanho de setor de 4 KB está se tornando a tecnologia mais popular de escolha na indústria de software e armazenamento, pois ele aprimora a armazenamento de página de dados do SQL Server e reduz a sobrecarga de metadados. Para qualquer novo desenvolvimento de banco de dados, o tamanho do setor de 4 KB seria uma boa escolha como o novo padrão. No entanto, apesar das vantagens oferecidas pelo tamanho do setor de 4 KB, o tamanho de setor de 512 B permanece como o tamanho de setor amplamente compatível com menor probabilidade de causar qualquer problema de suporte de aplicativos ou ferramentas. Verifique o suporte na plataforma de software e as ferramentas de armazenamento integradas ao implementar o tamanho do setor de 4 KB.


• Use o tamanho do setor de 4 KB para implementações físicas Windows e Hyper-V com implementação independente do XtremIO.

• Use o tamanho do setor de 512 B se a implementação incluir produtos como o RecoverPoint para replicação ou o VPLEX.

• Use o tamanho do setor de 512 B para SQL Server em implementações do VMware.

• Ao mover um banco de dados existente para a plataforma do XtremIO, verifique o tamanho de setor no banco de dados existente, usando dbcc fileheader. Alinhe o tamanho de setor de volume do XtremIO com o tamanho de setor de banco de dados existente.

32

TAMANHO DA UNIDADE DE ALOCAÇÃO O tamanho da unidade de alocação é uma opção configurável para formatar um volume NTFS. Ele não deve ser confundido com tamanho de setor físico. O amanho do setor físico especifica a menor unidade que pode ser gravada por um aplicativo, como o SQL Server. O tamanho de unidade de alocação é a menor unidade de armazenamento que qualquer arquivo individual pode assumir.

O tamanho de unidade de alocação padrão em um drive do Windows é 4 KB. Ao formatar o drive, você pode defini-lo como um tamanho maior. O valor de 64 KB é recomendado para dados do SQL Server, arquivos de registro e de banco de dados temporário pelos motivos a seguir:

• Os arquivos do SQL Server estão normalmente muito maiores do que 64 KB.

• A alocação do SQL Server é definida por extent. Cada extent no SQL Server tem oito páginas de 8 KB, que totalizam 64 KB.

Figura 20. Configurar o tamanho de unidade de alocação


• Use o tamanho de unidade de alocação de 64 KB para volumes de dados e registros do SQL Server.

33

SNAPSHOT CONSISTENTE COM APLICATIVOS EM COMPARAÇÃO AO SNAPSHOT CONSISTENTE EM CASO DE FALHA Os serviços de dados de cópia do XtremIO podem ser usados para aprimorar muitos cenários de uso do SQL Server e simplificar as operações diárias para um administrador de banco de dados. Os serviços de dados de cópia do XtremIO são baseados na tecnologia de snapshot. Ele dá suporte a snapshots consistentes em caso de falhas e snapshot consistentes com aplicativos. Então, qual é a diferença entre o snapshot consistente em caso de falhas e o snapshot consistente com aplicativos? Quando você precisa de cada tipo?

SNAPSHOT CONSISTENTE EM CASO DE FALHA Snapshots consistentes em caso de falhas capturam o estado dos volumes de dados em um ponto específico no tempo. O SQL Server não tem conhecimento do snapshot. Dessa forma, não existe impacto na execução da instância do SQL Server. Um snapshot consistente em caso de falha de um banco de dados do SQL Server é equivalente a ou consistente com o estado de um banco de dados em execução durante uma falta de energia. Nesse estado, pode haver páginas de dados em memória que ainda não foram submetidas a flush no disco (transações abertas). O SQL Server usa registro à frente da gravação (WAL), onde todas as transações confirmadas são registradas no registro de transações do SQL Server no disco. Esse SQL Server pode se recuperar de uma falha usando informações no registro de transações. É nele que as páginas de dados que ainda não são submetidas a flush no disco podem ser recriadas, e transações em trânsito são marcadas como falha.

SNAPSHOT CONSISTENTE COM APLICATIVOS Um snapshot consistente com aplicativos requer a coordenação do snapshot com o SQL Server. O XtremIO integra-se ao EMC AppSync para dar suporte a snapshots consistentes com aplicativos com o SQL Server. O AppSync coordena a obtenção de um snapshot entre o SQL Server (via SQL Server Virtual Device Interface) e o XtremIO. A versão 4.0 do XtremIO também vem com um VSS Provider nativo que permite que os desenvolvedores ou fornecedores terceirizados gravem seus próprios utilitários parecidos com o AppSync para criar snapshots consistentes com aplicativos.

Antes de criar um snapshot consistente com aplicativos, o SQL Server é notificado de que o backup dele está prestes a ser feito; portanto, ele pode ser preparado. Então, o SQL Server pode:

• Confirmar ou reverter transações em trânsito.

• Execute um checkpoint para fazer flush de páginas sujas para disco e anote o número de sequência de registro. Isso é feito para garantir que os arquivos de dados e os arquivos de registros estejam sincronizados e, portanto, minimizem o volume de trabalho durante um processo de restauração.

• Congelar I/Os.

• Fazer um backup dos metadados.

Os snapshots consistentes com aplicativos são considerados um backup completo para o SQL Server. Com o AppSync, um snapshot consistente com aplicativos pode ser montado e restaurado em vários estados de recuperação, ou seja, recovery, NORECOVERY ou standby, conforme mostrado na Figura 21. Com a restauração com NORECOVERY, o banco de dados é colocado em um estado não operacional e não reverte as transações não confirmadas. Como consequência, os registros de transações adicionais podem ser restaurados.

Figura 21. Tipos de recuperação de banco de dados compatíveis com o AppSync

34

DETERMINANDO QUAL SNAPSHOT USAR As principais diferenças entre snapshots consistentes com aplicativos e consistentes em caso de falhas são:

• A quantidade de trabalho necessária durante a recuperação do banco de dados:

Com snapshots consistentes com aplicativos, os arquivos de dados e arquivos de registros estão sincronizados. Não há nenhum trabalho adicional necessário para refazer ou desfazer todas as transações. Embora os snapshots consistentes com aplicativos e snapshots consistentes em caso de falhas tenham o mesmo RPO (Recovery Point Objective, objetivo de ponto de recuperação), o snapshot consistente com aplicativos pode oferecer um RTO melhor.

• Se o SQL Server congela I/Os durante a operação de snapshot:

O SQL Server permite que um snapshot seja feito em até 10 segundos. O aplicativo pode passar por uma queda de desempenho durante o tempo em que os I/Os estão parados.

• Se o SQL Server tem um backup de metadados da operação de snapshot ou trata o snapshot como um backup completo:

Um snapshot consistente com aplicativos pode ser restaurado no modo de NORECOVERY para continuar a acumular backups de registros de avanço.

Para determinar qual tipo de snapshot a ser usado, você deve considerar o requisito de disponibilidade, a frequência do snapshot, o impacto no desempenho e se é necessário dar suporte a backups de registros.

Considerações para o uso de snapshots consistentes com aplicativos em comparação com snapshots consistentes em caso de falhas:

• Snapshot consistente com aplicativos

o Backup de banco de dados

o Criando réplicas secundárias de availability groups com disponibilidade ininterrupta, servidor de mirror de espelhamento de banco de dados ou envio de logs secundário

• Snapshot consistente em caso de falha

o Realocação para teste, desenvolvimento ou geração de relatórios

o Processamento de descarga (por exemplo, ajuste e dbcc)


• Use snapshots consistentes com aplicativos para backup e para alta disponibilidade que exigem o acúmulo de dados do registro de transação adicionais.

• Use snapshots consistentes em caso de falha para fins de realocação, processamento de descarga ou backup que não exige registros adicionais de avanço.

35

CONCLUSÃO Os arrays totalmente flash EMC XtremIO são projetados para transformar o SQL Server por meio de uma arquitetura scale-out com desempenho singular, com compactação em memória sempre ativa, desduplicação e serviços de dados de cópia com eficiência no uso de espaço, viabilizando a aceleração, a consolidação e a agilidade de aplicativos.

O storage array totalmente flash XtremIO oferece não somente desempenho excepcional para qualquer implementação do SQL Server, mas também apresenta simplicidade e eficiência refinadas para administradores de armazenamento e banco de dados que gerenciam o ciclo de vida de aplicativos do SQL Server. Ele aprimora a carga de trabalho do SQL Server e resolve os desafios dos administradores de banco de dados do SQL Server de muitas maneiras, conforme listado abaixo:

• Desempenho — O Storage Array do XtremIO aumenta significativamente qualquer desempenho de carga de trabalho do SQL Server sem precisar de ajustes. Com latência baixa consistente para qualquer acesso a block data aleatório ou sequencial, pequeno ou grande, os administradores de banco de dados do SQL Server podem consolidar com segurança várias cargas de trabalho do SQL Server ou cargas de trabalho mistas de SQL Server no XtremIO, sem se preocupar com o problema do “vizinho barulhento”. O desempenho e a capacidade de armazenamento pode aumentar linearmente sob demanda sem a interrupção de serviços com a exclusiva arquitetura scale-out do XtremIO e a capacidade de expansão não disruptiva.

• Eficiência — A eficiência de armazenamento é desenvolvida na arquitetura do XtremIO, oferecida como um serviço de dados gratuitos para qualquer carga de trabalho do SQL Server. O banco de dados no espaço ocupado pelo armazenamento é automaticamente reduzido com provisionamento thin ininterrupto, desduplicação de dados em linha e compactação de dados em linha.

• Agilidade — Os serviços de dados de cópia do XtremIO aprimoram a agilidade para gerenciamento de workflow de ciclo de vida do SQL Server. Os serviços de dados de cópia do XtremIO criam instantaneamente cópias de volume com tamanho e desempenho completo, mas ainda assim economizando espaço que pode ser realocado para serviços de dados de downstream. Além disso, eles podem ser usados para simplificar a manutenção de banco de dados, o backup ou os workflows de upgrade. Isso resulta em melhorias drásticas de produtividade do administrador de banco de dados e maior agilidade do workflow.

• Simplicidade — Não é preciso fazer planejamentos complexos de capacidade para cargas de trabalho do SQL Server. Os administradores de banco de dados não precisam mais se preocupar com RAID, contagens de eixos ou qualquer uma das configurações de armazenamento destacadas ao planejar implementações de SQL Server. Um RAID otimizado para flash é integrado para oferecer proteção para falha de hardware. Os bancos de dados obtêm automaticamente o desempenho de todos os SSDs e de todas as controladoras de armazenamento com a natureza inerentemente balanceada da arquitetura scale-out. O provisionamento de carga de trabalho do SQL Server é tão fácil como especificar o tamanho para os volumes.

36

APÊNDICE I: RESUMO DAS PRÁTICAS RECOMENDADAS A tabela a seguir resume as recomendações de práticas recomendadas, conforme discutido neste artigo.

CATEGORIAS PRÁTICAS RECOMENDADAS

GERAL • Use a compactação em linha do XtremIO em vez de compactação de linha nativa do SQL Server para alcançar uma compactação automática de dados ativos. Use a compactação de página nativa do SQL Server para maximizar a economia de compactação de dados menos ativos ou de arquivamento.

• Use a compactação de linha ou de página nativa do SQL Server se o banco de dados é criptografado com criptografia de dados transparente do SQL Server. Um banco de dados criptografado de dados transparentes não obtém economia por compactação com a compactação em linha do XtremIO. Uma alternativa para resolver o problema de compatibilidade é considerar a criptografia de dados em repouso do XtremIO .

• Use serviços de dados de cópia do XtremIO para uma rápida implementação de cópias de banco de dados com eficiência de armazenamento.

LAYOUT DE ARQUIVOS DO SQL SERVER E PROVISIO-NAMENTO

• Não é necessária nenhuma configuração de RAID. Um RAID otimizado para flash (XDP) é integrado e pré-configurado no XtremIO.

• Não há motivos relacionados ao desempenho necessários para a separação de arquivos. • Para o uso mais eficiente de serviços de dados de cópia ou replicação de armazenamento, considere

o seguinte: o Separe TempDB de registros e arquivos de dados do usuário.

o A menos que sua transação comercial abranja vários bancos de dados, não compartilhe a LUN com vários bancos de dados. Um volume/LUN é a menor unidade de operação de snapshot.

• Um única LUN por banco de dados é suficiente para a maioria dos cenários de implementação. O XtremIO automaticamente cuida da distribuição uniforme de dados e garante o processamento máximo em paralelo.

• Para implementação extrema em grande escala do SQL Server com uso intenso de I/O, considere as seguintes opções de ajustes: o Aumente o tamanho da fila de LUN. Consulte a seção Tamanho da fila.

o Se os I/Os excederem o tamanho de fila máximo permitido, distribua os arquivos de banco de dados entre várias LUNs para aumentar o tamanho da fila geral além do valor máximo configurável por LUN.

• Se o armazenamento é dedicado a um só banco de dados do SQL Server, um mínimo de quatro LUNs/volumes deve ser criado no cluster do XtremIO. Isso tira proveito total das capacidades de processamento paralelo de várias controladoras de armazenamento no cluster e maximiza o desempenho.

• Siga as recomendações do SQL Server sobre criação de vários arquivos de dados para um banco de dados de usuário e a criação de TempDB. Para obter recomendações do SQL Server, consulte https://support.microsoft.com/en-us/kb/2154845.

GERENCIAMENTO DO CICLO DE VIDA DO SQL SERVER

• Use os serviços de cópia para implementar cópias do banco de dados para fins de teste e desenvolvimento.

• Use o recurso de snapshot multinível para limpar os dados confidenciais antes da apresentação do banco de dados para fins de teste ou desenvolvimento.

• Use o recurso de snapshot multinível para criar checkpoints ou ramificações para desenvolvimento. • Use os serviços de dados de cópia para criar réplicas secundárias legíveis para geração de relatórios

quase em tempo real, sem a implementação dos AlwaysOn Availability Groups. • Use snapshots de vários níveis para sincronizar os dados em todas as instâncias de geração

de relatórios. • Descarregue tarefas de manutenção de banco de dados com uso intensivo de recursos, como o

ajuste de consulta e o DBCC CHECKDB para uma unidade de computação secundária, usando cópias de bancos de dados criados com os serviços de dados de cópia.

• Descarregue backups em uma unidade de computação secundária, usando os serviços de dados de cópia.

• Crie backups de banco de dados completos e rápidos direcionados para armazenamentos usando snapshots consistentes com aplicativos do AppSync. Copie os volumes de snapshot para armazenamentos secundários para recuperação de desastres e proteja dados contra falhas de armazenamento físico irrecuperáveis.

• Use o tipo de recuperação flexível de AppSync para restaurar um banco de dados no estado NORECOVERY para fins de recuperação point-in-time, usando backups de registros de transação.

• Execute um teste de upgrade em uma cópia de snapshot para identificar possíveis problemas de upgrade e medir o tempo de upgrade.

• Crie um backup de snapshot antes do upgrade, caso haja necessidade de failback.


37

CATEGORIAS PRÁTICAS RECOMENDADAS

MÚLTIPLOS CAMINHOS

• Para Windows 2008 e posteriores, use a política Least Queue Depth com Microsoft Multipath IO nativo da Microsoft (MPIO).

• Para SQL Server no VMware vSphere, use a política de seleção de caminhos nativos round-robin do VMware e defina a frequência de alternância como um.

• Para obter práticas recomendadas com o PowerPath, consulte o Guia de Administração e Instalação no Windows do EMC PowerPath ou o Guia de Administração e Instalação do EMC PowerPath no VMware vSphere.

TAMANHO DA FILA

• Defina o tamanho da fila de LUN como 256.

• Para implementação do SQL Server no VMware vSphere:

o Defina o tamanho da fila em todas as camadas, inclusive HBA físicas, adaptador vSCSI e VMKernel Scheduler, ao configurar a fila para SQL Server em execução no VMware vSphere.

o Defina schednumreqoutstanding de disco como 256.

TAMANHO DO SETOR FÍSICO

• Use o tamanho do setor de 4KB para implementações físicas Windows e Hyper-V com implementação independente do XtremIO.

• Use o tamanho do setor de 512 B se a implementação incluir produtos como o RecoverPoint para replicação ou o VPLEX.

• Use o tamanho do setor de 512 B para SQL Server em implementações do VMware.

• Ao mover um banco de dados existente para a plataforma do XtremIO, verifique o tamanho de setor no banco de dados existente, usando dbcc fileheader. Alinhe o tamanho de setor de volume do XtremIO com o tamanho de setor de banco de dados existente.

TAMANHO DA UNIDADE DE ALOCAÇÃO

• Use o tamanho de unidade de alocação de 64 KB para volumes de dados e registros do SQL Server.

SNAPSHOT CONSISTENTE COM APLICATIVOS EM COMPARAÇÃO AO SNAPSHOT CONSISTENTE EM CASO DE FALHA

• Use snapshots consistentes com aplicativos para backup e para alta disponibilidade que exigem o acúmulo de dados do registro de transação adicionais.

• Use snapshots consistentes em caso de falha para fins de realocação, processamento de descarga ou backup que não exige registros adicionais de avanço.

38

APÊNDICE II: CONFIGURAÇÕES E METODOLOGIAS DE TESTES DE DESEMPENHO Esta seção descreve as configurações e as metodologias usadas no estudo de desempenho e do dimensionamento em expansão de até oito cargas de trabalho do SQL Server no XtremIO Storage Array.

METODOLOGIAS DE TESTE A finalidade desse estudo é examinar o desempenho do sistema de armazenamento do XtremIO, em termos de IOPS e latência, quando o número de instâncias do SQL Server são dimensionados verticalmente em um ambiente consolidado. O objetivo não é demonstrar a capacidade de desempenho máximo do sistema.

Este estudo dimensiona o número de instâncias do SQL Server em um cluster do XtremIO de X-Brick dual. Os testes iniciais foram feitos primeiramente com um cenário de uma instância do SQL Server. Cada teste subsequente dobrou o número de instâncias do SQL Server no teste anterior, até atingir o número de oito instâncias do SQL Server executadas. As medição de desempenho foram capturadas por 30 minutos durante o estado steady para cada cenário de teste.

Cada instância do SQL Server executou uma carga de trabalho tipo OLTP de 1 TB, gerada pelo Microsoft BenchCraft TPC-E Toolkit. O Kit de ferramentas da Microsoft simula as atividades do usuário de uma empresa de corretagem. A carga de trabalho representa um perfil de acesso de aplicativo típico de transações on-line, com 90% de leitura e 10% de gravação, e IOPSs na sua maioria aleatórios de 8 KB.

CONFIGURAÇÕES DE TESTE O ambiente de teste é composto pelos seguintes componentes de hardware e software.

Recursos de hardware

HARDWARE QUANTIDADE CONFIGURATION

Storage array 1 X-Brick 20 TB dual

Hosts 4 Dell PowerEdge R620

• 2 x 8 núcleos @2,40 GHz, 380 GB de RAM

• 1 x NICs de 1 GbE (rede de gerenciamento)

• 1 x NICs de 10 GBE (rede de dados)

• 2 x FC HBAs de 8 GB

Máquinas virtuais (VMs) 8 Máquinas virtuais de SQL Server com 2 VMs por host

Switches LAN 1 Switch Ethernet de 10 GBe

Switches SAN 1 Fibre Channel Switch de 16 GB

Recursos de software

SOFTWARE VERSÃO OBSERVAÇÕES

XtremIO v3.0 SO de armazenamento

VMware vSphere v5.5 Hipervisor que hospeda todas as máquinas virtuais do SQL Server

Microsoft Windows Windows 2012 R2 Sistema operacional que hospeda todos os SQL Servers

SQL Server SQL Server 2014 Enterprise Edition

Banco de dados

Microsoft BenchCraft TPC-E Toolkit

1.12.0-1026 Driver de carga e do gerador de carga de trabalho

39

Projeto de armazenamento do SQL Server no XtremIO

VOLUME NAME (NOME DO VOLUME)

VOLUME SIZE

BANCO DE DADOS DE TEMPDB/USUÁRIO

OBSERVAÇÕES

Infra 4 TB TempDB de 250 GB x 8 • Datastore compartilhado para todos os vmdks de binários de SO/SQL 8

• Datastore compartilhado para todos os TempDBs

Sql1 2 TB Banco de dados do usuário de 1 TB

• Arquivos de dados de usuário do SQL Server e arquivos de registros do SQL Server 1

• Datastore dedicado com o datastore de 1:1 para o mapeamento de vmdk






















40

APÊNDICEIII: ATUALIZAÇÃO DE SNAPSHOT As etapas a seguir descrevem em detalhes os scripts e os processos de Transact-SQL, Windows PowerShell e CLI do XtremIO para atualizar os dados de um banco de dados do SQL Server usando o recurso de atualização de snapshot do XtremIO:

Etapa 1: Desconecte o banco de dados obsoleto.

Execute a seguinte instrução SQL:

sp_detach_db @dbname ='<nome do banco de dados>'

Etapa 2: Desmonte os volumes de banco de dados.

No PowerShell, primeiro liste todos os discos do XtremIO e, em seguida, mude o status dos discos de banco

de dados específico para off-line e verifique se o disco está off-line.

Get-disk -FriendlyName XtremIO*

Set-Disk -Number 6 -IsOffline $True

Get-Disk | Where-Object IsOffline –Eq $True

Figura 22. Exemplos de scripts do PowerShell na desmontagem de um volume

Etapa 3: Execute a atualização de snapshot no XtremIO.

A Figura 23 mostra a relação pai-filho para o volume de origem de produção, o snapshot mestre e os snapshots de segundo nível para os bancos de dados.

Figura 23. Exibição em árvore do snapshot de volume do XMS

41

Execute o comando CLI “create-snapshot-and-reassign” para atualizar o snapshot mestre do volume de origem de produção e, em seguida, execute “create-snapshot-and-reassign” em cada um dos volumes de geração de relatórios. O comando “create-snapshot-and-reassign” atualiza o volume de snapshot com dados de origem e salva e renomeia o snapshot antigo com um novo nome. Por exemplo, SnapshotSet.1437607649, conforme mostrado na Figura 24, é a versão antiga do sql1-master-snap.

Figura 24. CLI do exemplo na atualização de snapshot

O comando da CLI “create-snapshot-and-reassign” dá suporte à atualização de snapshot em nível de volume, consistency group ou conjunto de snapshot. Consulte a Figura 25 para obter detalhes sobre a sintaxe.

Figura 25. Sintaxe da CLI para atualização de snapshot

Etapa 4: Desmonte os volumes.

No PowerShell, liste todos os discos do XtremIO e, em seguida, mude o status dos discos de banco de dados

específico para on-line e verifique se o disco está on-line.

Get-disk -FriendlyName XtremIO* | Where-Object IsOffline -Eq $True

Set-Disk -Number 6 -IsOffline $False

Get-disk -FriendlyName XtremIO*

42

Etapa 5: Conecte o bancos de dados.

Execute a instrução de SQL “create database … on <filespec> for attach” para conectar o banco de dados,

por exemplo:

USE [master]

GO

CREATE DATABASE [oltp] ON

( FILENAME = N'J:\MSSQL_tpce_root.mdf' ),

( FILENAME = N'J:\TPCE_Log.ldf' ),

( FILENAME = N'J:\Fixed_1.ndf' ),

( FILENAME = N'J:\Scaling_1.ndf' ),



( FILENAME = N'J:\Growing_1.ndf' ),

( FILENAME = N'J:\Growing_2.ndf' ),

( FILENAME = N'J:\Growing_3.ndf' )

FOR ATTACH

GO

43

REFERÊNCIAS Esta seção lista links relevantes para as conclusões descritas neste White paper.

XtremIO


http://info.xtremio.com/rs/xtremio/images/White-Paper_Introduction-to-XtremIO-Storage-Array_Ver-3-0_H11752-5_Rev-06_Draft_2014-07-02_1.pdf

http://info.xtremio.com/rs/xtremio/images/h13183-so-xtremio-for-sql-server.pdf

http://brazil.emc.com/collateral/white-papers/h13163-xtremio-microsoft-sql-server-wp.pdf

http://brazil.emc.com/collateral/technical-documentation/h13925-emc-xtremio-data-warehouse-fast-track-ra.pdf

Microsoft

http://download.microsoft.com/download/0/F/B/0FBFAA46-2BFD-478F-8E56-7BF3C672DF9D/SQLCAT's%20Guide%20to%20Relational%20Engine.pdf








VMware







http://www.emc.com/collateral/white-papers/h13163-xtremio-microsoft-sql-server-wp.pdf













Práticas recomendadas para a execução do SQL … · do SQL Server no EMC XtremIO RESUMO Este...

Documents

Transcript of Práticas recomendadas para a execução do SQL … · do SQL Server no EMC XtremIO RESUMO Este...