Benefícios do uso dos Arquivos NetApp do Azure para implantação do SQL Server
Os Arquivos NetApp do Azure reduzem o custo total de propriedade (TCO) do SQL Server em comparação com as soluções de armazenamento em bloco. Com o armazenamento em bloco, as máquinas virtuais impuseram limites de E/S e largura de banda para operações de disco. Somente os limites de largura de banda de rede são aplicados nos Arquivos NetApp do Azure e somente na saída. Em outras palavras, nenhum limite de E/S de nível de VM é aplicado aos Arquivos NetApp do Azure. Sem esses limites de E/S, o SQL Server em execução em máquinas virtuais menores conectadas aos Arquivos NetApp do Azure pode funcionar tão bem quanto o SQL Server em execução em máquinas virtuais muito maiores. O dimensionamento de instâncias como tal reduz o custo de computação para 25% do preço anterior. Você pode reduzir os custos de computação com os Arquivos NetApp do Azure.
Os custos de computação, no entanto, 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. Como tal, a diminuição do tamanho da instância introduz uma economia de custos ainda maior para o licenciamento de software. Você pode reduzir os custos de licença de software com os Arquivos NetApp do Azure.
Este artigo mostra uma análise de custos detalhada e benefícios de desempenho sobre como usar o Azure NetApp Files para implantação do SQL Server. Não só as instâncias menores têm CPU suficiente para fazer o trabalho de banco de dados só possível com bloco em instâncias maiores, em muitos casos, as instâncias menores têm ainda mais desempenho do que suas contrapartes maiores baseadas em disco por causa dos Arquivos NetApp do Azure.
Análise detalhada de custos
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 dos Arquivos NetApp do Azure e a capacidade para cada cenário foram selecionados para obter o melhor preço-capacidade-desempenho. Cada gráfico é composto por máquinas agrupadas (D16 com Arquivos NetApp do Azure, em comparação com D64 com disco gerenciado por exemplo) e os preços são divididos para cada tipo de máquina.
O primeiro conjunto de gráficos mostra o custo total da solução usando um tamanho de banco de dados de 1 TiB, comparando o D16s_v4 com o D64, o D8 com o D32 e o D4 com o D16. As IOPs projetadas para cada configuração são indicadas por uma linha verde ou amarela e correspondem ao eixo Y do lado direito.
O segundo conjunto de gráficos mostra o custo total usando um banco de dados de 50 TiB. As comparações são as mesmas – D16 comparado com Arquivos NetApp do Azure versus D64 com bloco por exemplo.
Desempenho, e muito disso
Para cumprir a afirmação de redução de custos significativa, é necessário muito desempenho - as maiores instâncias no inventário geral do Azure suportam 80.000 IOPS de disco por exemplo. Um único volume de Arquivos NetApp do Azure pode atingir 80.000 IOPS de banco de dados, e instâncias como a D16 podem consumir o mesmo. O D16, normalmente capaz de 25.600 IOPS de disco, tem 25% do tamanho do D64. O D64s_v4 é capaz de 80.000 IOPS de disco e, como tal, apresenta um excelente ponto de comparação de nível superior.
O D16s_v4 pode direcionar um volume de Arquivos NetApp do Azure para 80.000 IOPS de banco de dados. Conforme comprovado pela ferramenta de benchmarking do SQL Storage Benchmark (SSB), a instância D16 alcançou uma carga de trabalho 125% maior do que a possível obter em disco a partir da instância D64. Consulte a seção Ferramenta de teste SSB para obter detalhes sobre a ferramenta.
Usando um tamanho de conjunto de trabalho de 1 TiB e uma carga de trabalho SQL Server de 80% de leitura e atualização de 20%, os recursos de desempenho da maioria das instâncias na classe de instância D foram medidos; a maioria, não todas, uma vez que as próprias instâncias D2 e D64 foram excluídas dos testes. O primeiro foi deixado de fora, pois não suporta redes aceleradas, e o segundo porque é o ponto de comparação. Consulte o gráfico a seguir para entender os limites de D4s_v4, D8s_v4, D16s_v4 e D32s_v4, respectivamente. Os testes de armazenamento em disco gerenciado não são mostrados no gráfico. 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 da classe D.
Com os Arquivos NetApp do Azure, cada uma das instâncias na classe D pode atender ou exceder os recursos de desempenho de disco das instâncias duas vezes maiores. Você pode reduzir significativamente os custos de licença de software com os Arquivos NetApp do Azure.
- O D4 com 75% de utilização da CPU correspondia aos recursos de disco do D16.
- O D16 tem taxa limitada a 25.600 IOPS de disco.
- O D8 com 75% de utilização da CPU correspondia aos recursos de disco do D32.
- O D32 tem taxa limitada a 51.200 IOPS de disco.
- O D16 com 55% de utilização da CPU correspondia aos recursos de disco do D64.
- O D64 tem taxa limitada a 80.000 IOPS de disco.
- O D32 com 15% de utilização da CPU também correspondia aos recursos de disco do D64.
- O D64, como dito acima, tem taxa limitada a 80.000 IOPS de disco.
Teste de limites da CPU S3B – Desempenho versus poder de processamento
O diagrama a seguir resume o teste de limites da CPU S3B:
A escalabilidade é apenas uma parte da história. A outra parte é a latência. Uma coisa é as máquinas virtuais menores terem a capacidade de gerar taxas de E/S muito mais altas, outra coisa é fazê-lo com latências baixas de um dígito, como mostrado abaixo.
- O D4 gerou 26.000 IOPS contra Arquivos NetApp do Azure com latência de 2,3 ms.
- O D8 gerou 51.000 IOPS contra Arquivos NetApp do Azure com latência de 2,0 ms.
- O D16 gerou 88.000 IOPS contra Arquivos NetApp do Azure com latência de 2,8 ms.
- O D32 gerou 80.000 IOPS contra Arquivos NetApp do Azure com latência de 2,4 ms.
Resultados de latência do S3B por tipo de instância
O diagrama a seguir mostra a latência do SQL Server de instância única sobre os Arquivos NetApp do Azure:
Ferramenta de teste SSB
A ferramenta de benchmarking TPC-E, por design, enfatiza a computação em vez do armazenamento. Os resultados do teste mostrados nesta seção são baseados em uma ferramenta de teste de esforço chamada SQL Storage Benchmark (SSB). O SQL Server Storage Benchmark pode gerar execução SQL em grande escala em um banco de dados SQL Server para simular uma carga de trabalho OLTP, semelhante à ferramenta de benchmarking SLOB2 Oracle.
A ferramenta SSB gera uma carga de trabalho orientada por SELECT e UPDATE emitindo as referidas instruções diretamente para o banco de dados do SQL Server em execução na máquina virtual do Azure. Para este projeto, as cargas de trabalho do SSB aumentaram de 1 para 100 usuários do SQL Server, com 10 ou 12 pontos intermediários em 15 minutos por contagem de usuários. Todas as métricas de desempenho dessas execuções foram do ponto de vista do perfmon, para repetibilidade SSB executado três vezes por cenário.
Os testes em si foram configurados como 80% SELECT e 20% UPDATE statement, portanto, 90% de leitura aleatória. O banco de dados em si, que o SSB criou, tinha 1000 GB de tamanho. É composto por 15 tabelas de usuários e 9.000.000 de linhas por tabela de usuário e 8192 bytes por linha.
O índice de referência SSB é uma ferramenta de código aberto. Ele está disponível gratuitamente na página do GitHub do SQL Storage Benchmark.
Em resumo
Com os Arquivos NetApp do Azure, você pode aumentar o desempenho do SQL Server e, ao mesmo tempo, reduzir significativamente o custo total de propriedade.