Compartilhar via


Benefícios de usar o Azure NetApp Files para implantação do SQL Server

O Azure NetApp Files reduz o TCO (custo total de propriedade) do SQL Server em comparação com as soluções de armazenamento em bloco. Com o armazenamento em bloco, maquinas virtuais colocaram limites na E/S e na largura de banda para operações de disco. Somente os limites de largura de banda de rede são aplicados no Azure NetApp Files e apenas na saída, nesse caso. Em outras palavras, nenhum limite de e/s de nível de VM é aplicado ao Azure NetApp Files. Sem esses limites de E/S, o SQL Server em execução em máquinas virtuais menores conectadas ao Azure NetApp Files pode funcionar tão bem quanto o SQL Server em execução em máquinas virtuais muito maiores. Dimensionar instâncias para menos dessa forma reduz o custo de computação para 25% do preço anterior. É possível reduzir os custos de computação com Azure NetApp Files.

No entanto, os custos de computação são pequenos em comparação com os custos de licença do SQL Server. O licenciamento do Microsoft SQL Server está vinculado à contagem de núcleos físicos. Dessa forma, diminuir o tamanho da instância apresenta um economia de custo ainda maior para o licenciamento de software. É possível reduzir os custos de licença de software com o Azure NetApp Files.

Este artigo mostra uma análise detalhada de custos e benefícios de desempenho sobre o uso do Azure NetApp Files para implantação do SQL Server. As instâncias menores, não só têm CPU suficiente para fazer o que o trabalho com banco de dados que só seria possível com blocos em instâncias maiores, como, em muitos casos, as instâncias menores têm um desempenho ainda melhor do que as contrapartes maiores, baseadas em disco, por causa do Azure NetApp Files.

Análise de custo detalhada

Os dois conjuntos de gráficos nesta seção mostram o exemplo de TCO. O número e o tipo de discos gerenciados, o nível de serviço do Azure NetApp Files e a capacidade de cada cenário foram selecionados para atingir o melhor preço-capacidade-desempenho. Cada elemento gráfico é composto de máquinas agrupadas (D16 com o Azure NetApp Files, em comparação com a D64 com disco gerenciado por exemplo), e os preços são divididos para cada tipo de computador.

O primeiro conjunto de gráficos mostra o custo geral da solução usando um tamanho de banco de dados de 1 TiB, comparando a D16s_v4 com D64, a D8 com a D32 e a D4 com a D16. O IOPs projetado para cada configuração é indicado por uma linha verde ou amarela e corresponde ao eixo Y do lado direito.

Gráfico que mostra o custo geral da solução que usa um tamanho de banco de dados de 1 TiB.

O segundo conjunto de gráficos mostra o custo geral usando um banco de dados de 50-TiB. As comparações são, de outra forma, as mesmas – D16 comparadas com o Azure NetApp Files versus um D64 com um exemplo de bloco.

Gráfico que mostra o custo geral com um tamanho de banco de dados de 50 TiB.

Desempenho e muito mais

Fornecer uma declaração de redução de custos significativa requer muito desempenho – as maiores instâncias do inventário do Azure geral dão suporte ao 80.000 IOPS de disco por exemplo. Um único volume do Azure NetApp Files pode atingir 80.000 IOPS de banco de dados, e instâncias como a D16 consomem a mesma coisa. A D16, normalmente capaz de 25.600 IOPS de disco, tem 25% do tamanho da D64. A D64s_v4 é capaz de 80.000 IOPS de disco e, como tal, apresenta um excelente ponto de comparação de nível superior.

A D16s_v4 pode direcionar um volume do Azure NetApp Files para 80.000 IOPS de banco de dados. Como comprovado pela ferramenta de comparação SSB (SQL Storage Benchmark), a instância D16 atingiu uma carga de trabalho 125% maior do que a que seria possível para o disco da instância D64. Consulte a seção Ferramenta de teste do SSB para obter detalhes sobre a ferramenta.

Usando um tamanho de conjunto de trabalho de 1 TiB e carga de trabalho do SQL Server, 80% de leitura e 20% de atualização, foram medidos os recursos de desempenho da maioria das instâncias na classe de instância D; a maioria, nem todas, as próprias instâncias D2 e D64, foram excluídas do teste. A D2 foi excluída porque não é compatível com a rede acelerada e a D64 porque é o ponto de comparação. Consulte o grafo a seguir para entender os limites da D4s_v4, D8s_v4, D16s_v4 e D32s_v4, respectivamente. Os testes de armazenamento em disco gerenciado não são mostrados no grafo. Os valores de comparação são extraídos diretamente da tabela de limites da Máquina Virtual do Azure para o tipo de instância de classe D.

Com o Azure NetApp Files, cada uma das instâncias na classe D pode atender ou exceder os recursos de desempenho de disco de instâncias duas vezes maiores. É possível reduzir significativamente os custos de licença de software com o Azure NetApp Files.

  • A D4 a 75% de utilização da CPU correspondeu aos recursos de disco da D16.
    • A D16 tem taxa limitada em 25.600 IOPS de disco.
  • A D8 a 75% de utilização da CPU correspondeu aos recursos de disco da D32.
    • A D32 tem taxa limitada em 51.200 IOPS de disco.
  • A D16 a 55% de utilização da CPU correspondeu aos recursos de disco da D64.
    • A D64 tem taxa limitada em 80.000 IOPS de disco.
  • A D32 a 15% de tilização da CPU também correspondeu aos recursos de disco da D64.
    • A D64, conforme declarado acima, tem taxa limitada a 80.000 IOPS de disco.

Teste de limites de CPU S3B – desempenho versus capacidade de processamento

O diagrama a seguir resume o teste de limites de CPU S3B:

Diagrama que mostra a porcentagem média de CPU para SQL Server de instância única no Azure NetApp Files.

Escalabilidade é apenas uma parte da história. A outra parte é a latência. Uma coisa é as máquinas virtuais menores terem capacidade de gerar taxas de E/S muito mais altas, outra coisa é fazerem isso com latências de um único dígito, conforme mostrado abaixo.

  • A D4 gerou 26.000 IOPS em relação ao Azure NetApp Files com latência de 2,3 ms.
  • A D8 gerou 51.000 IOPS em relação ao Azure NetApp Files com latência de 2,0 ms.
  • A D16 gerou 88.000 IOPS em relação ao Azure NetApp Files com latência de 2,8 ms.
  • A D32 gerou 80.000 IOPS em relação ao Azure NetApp Files com latência de 2,4 ms.

Resultados de latência de S3B por tipo de instância

O diagrama a seguir mostra a latência para SQL Server de instância única no Azure NetApp Files:

Diagrama que mostra a latência para SQL Server de instância única no Azure NetApp Files.

Ferramenta de testes SSB

A ferramenta de benchmark do TPC-E, por design, prioriza a computação em vez do armazenamento. Os resultados de teste mostrados nesta seção são baseados em uma ferramenta de teste de estresse chamada SQL Storage Benchmark (SSB). O SQL Server Storage Benchmark pode direcionar a execução em massa do SQL contra um banco de dados SQL Server para simular uma carga de trabalho OLTP, semelhante à ferramenta de benchmark SLOB2 Oracle.

A ferramenta SSB gera uma carga de trabalho baseada em SELECT e UPDATE, emitindo as instruções citadas diretamente para o banco de dados SQL Server em execução na máquina virtual do Azure. Para este projeto, as cargas de trabalho do SSB aumentaram de 1 a 100 usuários do SQL Server, com 10 ou 12 pontos intermediários em 15 minutos por contagem de usuário. Todas as métricas de desempenho dessas execuções eram do ponto de vista do Perfmon, por questões de repetibilidade, o SSB foi executado três vezes por cenário.

Os próprios testes foram configurados considerando a proporção das instruções, 80% SELECT e 20% UPDATE, portanto, 90% de leitura aleatória. O próprio banco de dados, criado pelo SSB, tinha 1000 GB de tamanho. Ele é composto por 15 tabelas de usuário, com 9 milhões linhas por tabela e 8192 bytes por linha.

O SSB é uma ferramenta de código-fonte aberto. E está disponível gratuitamente na página SQL Storage Benchmark do GitHub.

Em resumo

Com o Azure NetApp Files, é possível aumentar o desempenho do SQL Server e reduzir significativamente o custo total de propriedade.

Próximas etapas