Práticas recomendadas para a execução do SQL Server

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
WHITE PAPER DA EMC
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
2
Í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
3
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
4
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
5
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.
6
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
7
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
8
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
9
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.
10
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
11
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
12
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.
13
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.
14
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.
15
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).
16
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.
17
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.
18
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.
Sugestões de práticas recomendadas:
•
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.
Sugestões de práticas recomendadas:
•
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.
19
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.
Sugestão de prática recomendada:
•
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?
20
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.
Sugestões de práticas recomendadas:
•
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.
21
HORA
T0
FASE
FIGURA
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
22
HORA
T1
FASE
FIGURA
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
23
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.
Sugestões de práticas recomendadas:
•
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
24
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.
Sugestão de prática recomendada:
•
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.
25
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.
Sugestões de práticas recomendadas:
•
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.
Sugestões de práticas recomendadas:
•
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.
26
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-HostConfiguration-Guide.pdf?language=en_US.
Sugestões de práticas recomendadas:
•
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
27
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.
Sugestões de práticas recomendadas:
•
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.
28
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.
29
Figura 18. Verificar o tamanho de setor de volume usando FSUTIL
30
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.
Sugestões de práticas recomendadas:
•
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.
31
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
Sugestão de prática recomendada:
•
Use o tamanho de unidade de alocação de 64 KB para volumes de dados e registros do SQL Server.
32
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
33
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)
Sugestões de práticas recomendadas:
•
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.
34
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.
35
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.
•
Não é necessária nenhuma configuração de RAID. Um RAID otimizado para flash (XDP) é integrado
e pré-configurado no XtremIO.
LAYOUT DE
ARQUIVOS DO
SQL SERVER E
PROVISIO-
•
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:
NAMENTO
o
o
Separe TempDB de registros e arquivos de dados do usuário.
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
o
Aumente o tamanho da fila de LUN. Consulte a seção Tamanho da fila.
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.
GERENCIAMENT
O 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.
36
CATEGORIAS
PRÁTICAS RECOMENDADAS
MÚLTIPLOS
•
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.
CAMINHOS
TAMANHO
•
Defina o tamanho da fila de LUN como 256.
DA FILA
•
Para implementação do SQL Server no VMware vSphere:
TAMANHO DO
SETOR FÍSICO
TAMANHO DA
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.
•
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.
•
Use o tamanho de unidade de alocação de 64 KB para volumes de dados e registros do SQL Server.
•
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.
UNIDADE DE
ALOCAÇÃO
SNAPSHOT
CONSISTENTE
COM
APLICATIVOS
EM COMPARAÇÃO
AO SNAPSHOT
CONSISTENTE EM
CASO DE FALHA
37
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
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
Recursos de software
38
Projeto de armazenamento do SQL Server no XtremIO
VOLUME
VOLUME
BANCO DE DADOS DE
NAME
SIZE
TEMPDB/USUÁRIO
4 TB
TempDB de 250 GB x 8
OBSERVAÇÕES
(NOME DO
VOLUME)
Infra
Sql1
Sql2
Sql3
Sql4
Sql5
Sql6
Sql7
Sql8
2 TB
2 TB
2 TB
2 TB
2 TB
2 TB
2 TB
2 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
Banco de dados do usuário
de 1 TB
•
Datastore compartilhado para todos os vmdks de
binários de SO/SQL 8
•
Datastore compartilhado para todos os TempDBs
•
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
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 2
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 3
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 4
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 5
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 6
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 7
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
•
Arquivos de dados de usuário do SQL Server e arquivos
de registros do SQL Server 8
•
Datastore dedicado com o datastore de 1:1 para
o mapeamento de vmdk
39
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
40
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 “createsnapshot-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*
41
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:\Scaling_2.ndf' ),
( FILENAME = N'J:\Scaling_3.ndf' ),
( FILENAME = N'J:\Growing_1.ndf' ),
( FILENAME = N'J:\Growing_2.ndf' ),
( FILENAME = N'J:\Growing_3.ndf' )
FOR ATTACH
GO
42
REFERÊNCIAS
Esta seção lista links relevantes para as conclusões descritas neste White paper.
XtremIO
https://support.emc.com/docu56210_XtremIO-2.2.x---4.0-Host-Configuration-Guide.pdf?language=en_US
http://info.xtremio.com/rs/xtremio/images/White-Paper_Introduction-to-XtremIO-Storage-Array_Ver-3-0_H11752-5_Rev06_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-8E567BF3C672DF9D/SQLCAT's%20Guide%20to%20Relational%20Engine.pdf
https://support.microsoft.com/en-us/kb/2154845
https://support.microsoft.com/en-us/kb/2515143
http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx
https://support.microsoft.com/en-us/kb/2510009
https://support.microsoft.com/en-us/kb/926930
https://technet.microsoft.com/en-us/library/dd894051(v=sql.100).aspx
https://technet.microsoft.com/en-US/library/ms345584(v=SQL.105).aspx
VMware
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2091600
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1268
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1267
43