Escalando o desempenho do SQL Server além de 1 milhão de transações por minuto com o Amazon FSx

No geral, nossa estratégia pode ser usada por clientes que buscam maneiras econômicas de executar as implantações de banco de dados SQL Server de mais alto desempenho na nuvem.

1. Introdução

Em 2021, nossa equipe lançou uma postagem no blog que estabeleceu uma nova referência para o desempenho do SQL Server na AWS. Os autores usaram instâncias R5b.24xlarge do Amazon Elastic Compute Cloud (Amazon EC2) otimizadas para memória, capazes de até 60 Mbps de largura de banda do Amazon Elastic Block Store (EBS) e 260.000 operações de entrada/saída por segundo (IOPS). Para aproveitar ao máximo os recursos de I/O dessa instância, um banco de dados de teste TPCC HammerDB de 3,5 TB foi armazenado em dois volumes io2 Block Express (IO2-BE), organizados na configuração RAID-0. Os testes de desempenho usando o HammerDB com essa configuração alcançaram quase 830.000 TPM.

Na mesma postagem do blog, os autores mostraram que hospedar o banco de dados no volume de armazenamento de instâncias do Amazon EC2 melhora o desempenho em aproximadamente 20%. No entanto, os volumes de armazenamento de instâncias são efêmeros, fornecendo apenas armazenamento temporário em nível de bloco que é perdido se você interromper a instância. Isso torna os volumes de armazenamento de instâncias adequados para armazenamento tempdb, enquanto os volumes do EBS e os sistemas de arquivos Amazon FSx fornecem soluções de armazenamento duráveis e escaláveis para hospedar seus bancos de dados.

Famílias de instâncias mais novas, como x2iedn e r6idn, oferecem melhorias de desempenho significativas em relação à r5b.24xlarge usada na postagem do blog. Essas melhorias levam a um aumento de cerca de 30% no desempenho, resultando em cerca de 1 milhão de TPM. No entanto, esses ganhos de desempenho têm um custo. O aumento do número de CPUs virtuais (vCPUs) exige licenciamento adicional do SQL Server, e a necessidade de usar RAID-0 em 3 volumes de IO2-BE para saturar a taxa de transferência da instância também aumenta os custos de armazenamento do EBS.

Nesta postagem do blog, mostraremos como o uso inovador do Amazon FSx permite que você obtenha maior desempenho do SQL Server do que é possível apenas com o EBS ou volumes de armazenamento de instâncias.

2. Configuração de teste

Para nossos testes de desempenho do SQL Server no Windows, usamos sistemas de arquivos Amazon FSx compatíveis com o Windows, ou seja, Amazon FSx for NetApp ONTAP (FSx for ONTAP) e Amazon FSx for Windows File Server. Configuramos cada sistema de arquivos Amazon FSx com 26 TB de armazenamento SSD, 80.000 IOPS e taxa de transferência de 2 GBps. O FSx para ONTAP oferece taxa de transferência de até 4 GBps e 160.000 IOPS, e o FSx para Windows oferece taxa de transferência de até 12 GBps e 350.000 IOPS, mas essas ofertas só estavam disponíveis em algumas regiões da AWS no momento em que este artigo foi escrito, então excluímos essas configurações de nossos testes. (Planejamos acompanhar esses testes de desempenho usando os níveis mais altos de capacidade de produção.)

Para nossos testes de desempenho, usamos a licença da Amazon, incluindo o Microsoft Windows Server 2019 com a edição SQL Server 2019 Enterprise na região da Virgínia (us-east-1) da AWS. Usamos instâncias EC2 r5dn.24xlarge, que oferecem 768 GB de RAM, 96 vCPUs, 100 Gbps de largura de banda de rede e quatro volumes de armazenamento de instâncias SSD NVMe de 900 GB. Selecionamos essa instância porque ela é comparável em termos de vCPU e RAM à r5b.24xlarge usada na postagem original do blog, mas oferece maior taxa de transferência de rede, o que é importante, pois usamos armazenamento conectado à rede para o banco de dados.

Para o tempdb, criamos um volume RAID-0 em quatro volumes de armazenamento de instâncias, que estão disponíveis em instâncias EC2 r5dn.24xlarge. Também usamos volumes IO2-Be EBS provisionados com 64.000 IOPS para arquivos de log do banco de dados do SQL Server. Armazenamos os arquivos de dados do banco de dados nos sistemas de arquivos Amazon FSx.

Usamos o HammerDB, uma ferramenta de benchmarking amplamente usada, para simular uma carga de trabalho do banco de dados. A carga de trabalho OLTP do HammerDB foi a base de nossos testes de desempenho porque cargas de trabalho semelhantes são comuns nas migrações do SQL Server para a AWS. Geramos um banco de dados de teste que inclui 30.000 Data Warehouses, com cerca de 3 TB de tamanho.

Os usuários virtuais do HammerDB são usuários simulados que colocam uma carga no banco de dados para testes de desempenho. Para medir o desempenho máximo de um sistema, é aconselhável começar com alguns usuários virtuais e aumentar esse número de forma incremental até que o TPM do banco de dados atinja um patamar. Quando aumentamos o número de usuários virtuais, a métrica de desempenho cresce até atingir um ponto de saturação, no qual o crescimento para ou até diminui.

Para cada configuração, escolhemos o seguinte número de usuários virtuais: 256, 362, 512, 724 e 1024. Para obter resultados confiáveis e consistentes, realizamos três testes separados para cada ponto de carga de usuário virtual. Em seguida, calculamos a média desses testes.

3. Teste de desempenho usando FSx for NetApp ONTAP

O FSx for ONTAP oferece dois protocolos — iSCSI e SMB. Usamos os dois protocolos em nossos testes de desempenho.

3.1. Usando FSx for ONTAP com protocolo iSCSI

Conectamos interfaces iSCSI, fornecidas por quatro instâncias FSx for ONTAP separados, como drives à instância EC2. Essas unidades foram então distribuídas em uma configuração RAID-0 usando o recurso Windows Storage Spaces. Para melhorar o desempenho dos drives iSCSI, habilitamos o MPIO e atribuímos quatro caminhos a cada drive. Mostramos a configuração desse cenário na Figura 1.

Figure 1. Configuração de teste de desempenho do FSx for Windows File Server.

Os resultados do teste de desempenho do HammerDB para essa configuração são apresentados na Tabela 1 e na Figura 2. Conforme indicado pelos resultados, essa configuração nos permitiu dobrar o desempenho detalhado na postagem original do blog. O ponto de estabilização foi alcançado com 724 usuários virtuais nessa configuração, o que significa que qualquer aumento adicional na carga levou à diminuição do desempenho.

Tabela 1. Resultados de desempenho do FSx for ONTAP iSCSI.

Figura 2. Resultados de desempenho do FSx for ONTAP iSCSI.

3.2. Usando FSx for ONTAP com protocolo SMB

O FSx for ONTAP também suporta o protocolo SMB, um protocolo de comunicação cliente-servidor usado para compartilhar o acesso a arquivos pela rede. Ao contrário do protocolo iSCSI, o SMB não apresenta drives virtuais, mas oferece compartilhamentos de arquivos. Portanto, não pudemos usar a distribuição RAID-0 para melhorar o desempenho, como fizemos no cenário anterior.

Em vez de distribuição de volume, usamos um recurso do SQL Server que distribui arquivos de banco de dados em um grupo de arquivos em vários volumes ou compartilhamentos de arquivos. Distribuímos o grupo de arquivos primário em quatro compartilhamentos de arquivos apresentados por quatro sistemas de arquivos FSx ONTAP.

Em um cenário RAID-0, cada registro de uma tabela é dividido em vários drives subjacentes. No entanto, quando distribuímos o grupo de arquivos primário em vários compartilhamentos, cada registro de tabela alocado para esse grupo de arquivos é armazenado inteiramente em um único compartilhamento SMB. Todos os registros de uma tabela serão distribuídos uniformemente em vários compartilhamentos. Essa configuração se assemelha ao RAID-0. Ilustramos essa configuração na Figura 3.

Figura 3. Configuração de teste de desempenho FSx for ONTAP para protocolo SMB.

Apresentamos os resultados do teste de desempenho do HammerDB para essa configuração na Tabela 2 e na Figura 4. Conforme mostrado pelos resultados, essa configuração superou a que discutimos anteriormente na Seção 3.1 acima. À medida que a carga aumenta, o desempenho também melhora, embora em um ritmo desacelerado, atingindo um patamar de 1.024 usuários virtuais.

Tabela 2. Resultados de desempenho do FSx for ONTAP SMB

Figura 4. Resultados de desempenho do FSx for ONTAP SMB

4. Teste de desempenho usando FSx for Windows File Server

O FSx for Windows File Server suporta somente o protocolo SMB, portanto, em nossos testes, usamos uma configuração semelhante à que apresentamos na Figura 3, com a exceção de que usamos FSx para Windows File Server em vez de FSx para ONTAP, conforme mostrado na Figura 5.

Figura 5. Configuração de teste de desempenho do FSx for Windows File Server.

Ao executar o SQL Server usando essa configuração para armazenamento, obtivemos os resultados de desempenho apresentados na Tabela 3 e na Figura 6.

Tabela 3. Resultados de desempenho do FSx for Windows File Server.

Figura 6. Resultados de desempenho do FSx for Windows File Server.

Alcançamos mais de 2 milhões de TPM — quase 3 vezes mais do que o melhor resultado obtido com os volumes do IO2-Block Express EBS mencionados na postagem original do blog.

5. Comparação de preço/desempenho

A Tabela 4 resume os resultados de nossos testes de desempenho nas três configurações discutidas anteriormente, além da configuração original usando volumes IO2-Be EBS (da postagem original do blog). Também fornecemos estimativas de custo para cada configuração. Ao calcular o custo do Amazon FSx, não consideramos o custo de backup ou a economia de duplicação, pois elas não se aplicam às cargas de trabalho do banco de dados.

O desempenho das configurações usando FSx for ONTAP usou os valores de desempenho de estado estacionário, que, para cargas de trabalho dinâmicas como o SQL Server, normalmente são 10 a 15% menores do que os resultados fornecidos nas Tabelas 1 e 2. O custo de computação é baseado na instância EC2 r5dn.24xlarge com licença incluída Windows Server e SQL Server Enterprise Edition na região da AWS us-east-1 (Norte da Virgínia), válida no momento em que este artigo foi escrito.

Tabela 4. Dados de comparação de preço e desempenho.

A adição de quatro sistemas de arquivos Amazon FSx aumentou o custo total do sistema. No entanto, devido ao aumento do desempenho, reduziu o custo geral por transação.

O FSx for ONTAP, quando usado com a interface SMB, ofereceu a melhor relação preço/desempenho. O FSx for Windows File Server forneceu o melhor desempenho geral, mas tem o maior custo total. No entanto, quando consideramos o desempenho superior do SQL Server obtido com essa configuração, o custo por 1.000 TPM é comparável ao do FSx for ONTAP usando a interface SMB.

6. Ampliando o escopo dos testes de desempenho

Nossa análise seria incompleta se não considerássemos os novos tipos de instâncias da AWS, especificamente, a família de instâncias EC2 otimizadas para memória x2iedn, que são usadas para uma ampla variedade de aplicações de grande escala que consomem muita memória. Essa família oferece uma proporção de 32:1 de memória para vCPU em todos os tamanhos, escalando até 4 TB de RAM, o que os torna atraentes para uso em cargas de trabalho do SQL Server. Para comparação com a instância r5dn.24xlarge, usada em todos os nossos testes anteriores, optamos pela x2iedn.24xlarge e x2iedn.32xlarge, com 2 TB e 4 TB de RAM, respectivamente.

O uso de um banco de dados de 3,5 TB em instâncias do EC2 com RAM próxima ou superior ao tamanho do banco de dados pode não fornecer uma carga adequada para testar o subsistema IO. Portanto, geramos um banco de dados HammerDB com 75.000 warehouses, o que, com 8,5 TB, nos permite testar o subsistema de IO. Também pretendemos aumentar ainda mais a carga do SQL Server aumentando o número de usuários virtuais para 2.048.

Para o subsistema de armazenamento, selecionamos a configuração de melhor desempenho com quatro FSx para servidores de arquivos Windows em uma configuração correspondente à da Figura 8. Os resultados de nossos testes são apresentados na Tabela 5 e na Figura 7.

Tabela 5. Resultados do teste de desempenho, banco de dados de 8,5 TB.

Figura 7. Resultados do teste de desempenho, banco de dados de 8,5 TB.

O SQL Server na instância r5dn.24xlarge atingiu um pico de cerca de 1,5 milhão de TPM para o banco de dados de 8,5 TB. O aumento da quantidade de RAM na família x2iedn foi o fator determinante para permitir que o SQL Server nessas instâncias ultrapassasse a marca de 2 milhões de TPM. Com o banco de dados de 8,5 TB, a memória extra na família x2iedn, comparada aos 768 GB disponíveis no r5dn.24xlarge, de fato fez uma diferença significativa.

A análise de preço-desempenho para este conjunto de testes é fornecida na Tabela 6. A instância EC2 x2iedn.24xlarge surgiu como uma clara vencedora em termos de custo por 1.000 TPM, embora tenha oferecido um desempenho um pouco menor em comparação com a instância maior do EC2 x2iedn.32xlarge. Para realmente se beneficiar dos 4 TB de RAM disponíveis na instância x2iedn.32xlarge do EC2, talvez seja necessário considerar um banco de dados ainda maior.

Tabela 6. Comparação de preço/desempenho para testes de grandes bancos de dados.

Outra observação interessante, ilustrada na Figura 8, é que, à medida que passamos para instâncias com maior RAM, o IOPS e a taxa de transferência consumidos pelo FSx subjacente para o Windows File Server diminuíram. Isso ocorre porque o SQL Server concluiu mais operações no cache, reduzindo a demanda no sistema de arquivos.

Figura 8. O IOPS e a taxa de transferência mudam com o aumento da RAM.

7. Conclusão

Nosso uso inovador de vários sistemas de arquivos Amazon FSx nos permitiu alcançar um desempenho de armazenamento significativamente superior ao que um único sistema de arquivos poderia oferecer. Isso levou a um aumento significativo no desempenho do SQL Server. Embora o uso de vários sistemas Amazon FSx aumente o custo da implantação, o aumento resultante no desempenho do SQL Server reduz o custo geral por transação para níveis comparáveis ou até mais baixos do que outras configurações.

Embora o FSx for ONTAP com a interface iSCSI tenha mostrado um desempenho um pouco menor em nossos testes do SQL Server, o uso do RAID-0 oferece um caminho de implantação mais simples, pois não precisamos distribuir o grupo de arquivos primário em quatro volumes.

Realizamos nossos testes usando quatro sistemas de arquivos Amazon FSx, mas “quatro” não é um “número mágico” nesse caso. Você pode obter um aumento significativo no desempenho do SQL Server usando apenas dois ou três sistemas de arquivos Amazon FSx, dependendo das instâncias do EC2 usadas para hospedar o SQL Server e de seus requisitos específicos de desempenho e custo.

Esse método fornece outra opção para nossos clientes gerenciarem cargas de trabalho de alto desempenho do SQL Server. Especificamente, nossa estratégia pode ser usada por clientes que buscam maneiras econômicas de executar as implantações de banco de dados SQL Server de mais alto desempenho na nuvem.

A AWS tem muito mais serviços e mais recursos dentro desses serviços do que qualquer outro provedor de nuvem, o que torna mais rápido, fácil e econômico mover seus aplicativos existentes para a nuvem e criar praticamente qualquer coisa que você possa imaginar. Ofereça às suas aplicações da Microsoft a infraestrutura de que eles
precisam para impulsionar os resultados comerciais que você deseja. Visite nossos blogs .NET on AWS e AWS Database para obter orientações e opções adicionais para suas cargas de trabalho da Microsoft. Entre em contato conosco para iniciar sua jornada de migração e modernização hoje mesmo.

Sobre os autores

Alex Zarenin é arquiteto principal de soluções da Amazon Web Services. Ele trabalha com empresas de serviços financeiros projetando e implementando uma ampla variedade de soluções técnicas. Com experiência de domínio em tecnologias da Microsoft, Alex tem mais de 30 anos de experiência técnica nos setores comercial e público. Alex é Ph.D. em Ciência da Computação pela NYU.

Sudhir Amin é arquiteto sênior de soluções na Amazon Web Services. Em sua função em Nova York, ele fornece orientação arquitetônica e assistência técnica para clientes corporativos em diferentes setores da indústria, acelerando a adoção da nuvem. Ele é um grande fã de sinuca e esportes de combate, como boxe e UFC, e adora viajar para países com ricas reservas de vida selvagem, onde pode ver de perto os animais mais majestosos do mundo.

Vikas Babu Gali é arquiteto de soluções especialista, com foco em cargas de trabalho da Microsoft na Amazon Web Services. A Vikas fornece orientação arquitetônica e assistência técnica para clientes em diferentes setores do setor, acelerando a adoção da nuvem.

Tradutor

Luiz Rampanelli é um Solutions Architect no time da AWS Latam. Possui mais de 10 anos anos de experiência com workloads Microsoft em nuvem e ambientes híbridos. Atua com desenho de soluções seguindo as melhores práticas para que os clientes possam aproveitar ao máximo os benefícios da nuvem da AWS.

Revisor

Guilherme Marques é Cloud Infrastructure Architect no time ProServe Latam. Possuí mais de 15 anos de experiência em TI, muitos destes voltados para ambientes Microsoft em nuvem e ambientes OnPremises. Atualmente atua no time de ProServe AWS criando soluções de escala e ajudando clientes a trazerem seus ambientes para nuvem AWS.