As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Selecione a EC2 instância certa para cargas de trabalho do SQL Server
Importante
Antes de ler esta seção, recomendamos que você leia primeiro as seções Compreender o licenciamento do SQL Server e Selecionar o tipo de instância certo para workloads do Windows deste guia.
Visão geral do
O Microsoft SQL Server está sendo executado nas instâncias do Amazon Elastic Compute Cloud (Amazon EC2) há mais de 15 anos. AWS pegou essa experiência e a usou para ajudar a desenvolver EC2 instâncias da Amazon adequadas às cargas de trabalho do SQL Server, executadas desde especificações mínimas até clusters multirregionais de alto desempenho.
A escolha da EC2 instância correta para o SQL Server depende muito da sua carga de trabalho. Entender como o SQL Server é licenciado, como ele usa a memória e como os recursos do SQL Server se alinham às EC2 ofertas da Amazon pode ajudar a orientá-lo até a melhor EC2 instância para seu aplicativo.
Esta seção aborda uma variedade de cargas de trabalho do SQL Server e como elas podem ser combinadas com determinadas EC2 instâncias para reduzir ao mínimo seus custos de licenciamento e computação.
Comparação de custos
A Amazon EC2 permite que você traga sua própria licença (BYOL) ou pague conforme o uso com o licenciamento do Windows Server e do SQL Server. Para pay-as-you-go licenciamento, os custos de licenciamento das licenças do Windows Server e do SQL Server são incorporados ao custo por hora da instância. EC2 Por exemplo, você pode ter preços diferentes AMIs com preços diferentes. O preço da AMI depende da edição do SQL Server em que a AMI é executada.
Os preços do Windows Server e do SQL Server não são discriminados. Você não encontrará preços discriminados em ferramentas como a AWS Calculadora de Preços
| EC2 instância | AMI | Preço de computação | Preço de licença do Windows | Preço da licença do SQL | Preço total |
|---|---|---|---|---|---|
| r5.xlarge | Linux (preços de computação) | $183,96 | - | - | $183,96 |
| r5.xlarge | Linux + SQL Developer | $183,96 | $0 | $0 | $183,96 |
| r5.xlarge | Windows Server (LI) | $183,96 | $134,32 | - | $318,28 |
| r5.xlarge | Windows + SQL Developer | $183,96 | $134,32 | $0 | $318,28 |
| r5.xlarge | Windows + SQL Web (LI) | $183,96 | $134,32 | $49,64 | $367,92 |
| r5.xlarge | Windows + SQL Standard (LI) | $183,96 | $134,32 | $350,4 | $668,68 |
| r5.xlarge | Windows + SQL Enterprise (LI) | $183,96 | $134,32 | $1095 | $1413,28 |
nota
Os preços na tabela anterior são baseados nos preços sob demanda na região us-east-1.
O método mais econômico para executar o SQL Server é permanecer em uma edição de nível inferior até que você precise de um recurso de uma edição de nível superior. Para obter mais informações, consulte a seção Comparar edições do SQL Server deste guia. A atualização da edição SQL Server Web para a edição SQL Server Standard é sete vezes o custo de licenciamento do SQL Server e mais de três vezes o custo da mudança da edição Standard para a edição Enterprise. A disparidade nos custos de licenciamento é um fator importante a ser considerado, e será analisada no restante desta seção.
Cenário de otimização de custos
Considere um exemplo de cenário em que uma empresa de analytics que rastreia veículos de entrega está buscando melhorar a performance do SQL Server. Depois que um especialista em MACO analisa os gargalos de performance da empresa, ela faz a transição das instâncias x1e.2xlarge para as instâncias x2iedn.xlarge. Embora o tamanho da instância seja menor, os aprimoramentos nas instâncias x2 melhoram a performance e a otimização do SQL Server usando extensões do grupo de buffers. Isso permitiu que a empresa fizesse o downgrade da edição SQL Server Enterprise para a edição SQL Server Standard e reduzisse seu licenciamento do SQL Server de 8 v CPUs para 4 v. CPUs
Antes da otimização:
| Servidor | EC2 instância | Edição do SQL Server | Custo mensal |
|---|---|---|---|
| Cutucar DB1 | x1e.2xlarge | Enterprise | $3.918,64 |
| Cutucar DB2 | x1e.2xlarge | Enterprise | $3.918,64 |
| Total | $7.837,28 |
Após a otimização:
| Servidor | EC2 instância | Edição do SQL Server | Custo mensal |
|---|---|---|---|
| Cutucar DB1 | x2iedn.xlarge | Standard | $1.215,00 |
| Cutucar DB2 | x2iedn.xlarge | Standard | $1.215,00 |
| Total | $2.430,00 |
As mudanças combinadas de instâncias x1e.2xlarge para instâncias x2iedn.xlarge permitiram que o cliente do exemplo economizasse USD 5.407 por mês em seus servidores de banco de dados de produção. Isso reduziu o custo total da workload em 69%.
nota
Os preços na tabela anterior são baseados nos preços sob demanda na região us-east-1.
Recomendações de otimização de custos
Instâncias otimizadas para memória
Um dos aspectos mais importantes do SQL Server é entender sua dependência da memória. O SQL Server tenta usar toda a RAM disponível que não está sendo usada pelo sistema operacional (até 2 TB para uma instalação padrão). Ele faz isso por motivos de performance. Trabalhar com dados na memória é muito mais eficiente do que ter que extrair dados constantemente do disco, fazer alterações e depois gravá-los de volta no disco. Em vez disso, o SQL Server tenta carregar o máximo possível de dados dos bancos de dados anexados e os mantém na RAM. As alterações feitas nos dados acontecem na memória e são posteriormente gravadas no disco.
nota
Para obter uma explicação detalhada de como o SQL Server grava alterações, consulte Writing Pages
Como o SQL Server funciona melhor com grandes quantidades de RAM, geralmente recomendamos começar com os tipos de instância otimizados para EC2 memória da Amazon
Cargas de trabalho abaixo do mínimo de recursos (menos de 4 v) CPUs
Embora alguns casos de uso funcionem bem com instâncias expansíveis (T3), recomendamos que você geralmente evite usá-las para workloads do SQL Server. O licenciamento do SQL Server é baseado no número de v CPUs atribuído a uma instância. Se o SQL Server ficar ocioso a maior parte do dia e estiver adquirindo créditos de expansão, você pagará pelas licenças do SQL que não está utilizando totalmente. Além disso, o SQL Server tem um requisito mínimo de licença de 4 núcleos por servidor. Isso significa que, se você tem uma carga de trabalho do SQL Server que não exige 4 V CPUs de potência computacional, você está pagando uma licença do SQL Server que não está usando. Nesses cenários, seria melhor consolidar várias instâncias do SQL Server em um servidor maior.
Workloads usando recursos mínimos (menos de 64 GB de RAM)
Muitas workloads do SQL Server com menos de 64 GB de RAM não priorizam a alta performance ou a alta disponibilidade. Para esses tipos de workloads, a edição SQL Server Web pode ser uma boa opção se a aplicação estiver coberta pelas restrições de licenciamento da Microsoft.
Importante
A edição SQL Server Web tem um caso de uso restrito com base nos termos de licenciamento da Microsoft. A edição SQL Server Web pode ser usada apenas para fornecer suporte a páginas da Web, sites, aplicativos da Web e serviços da Web públicos e acessíveis pela Internet. Ele não pode ser usado para oferecer suporte a line-of-business aplicativos (por exemplo, gerenciamento de relacionamento com clientes, gerenciamento de recursos corporativos e outros aplicativos similares).
O SQL Server Web Edition pode ser expandido até 32 v CPUs e 64 GB de RAM e é 86% mais barato do que o SQL Server Standard Edition. Para workloads com poucos recursos, usar uma instância otimizada para memória AMD, como a r6a, que tem um preço de computação 10% mais barato do que sua equivalente da Intel, também é uma boa maneira de reduzir ao mínimo os custos de computação e licenciamento do SQL.
Workloads com recursos médios (menos de 128 GB de RAM)
A edição SQL Server Standard é usada na maioria das workloads do SQL Server com até 128 GB de RAM. A edição SQL Server Standard é 65 a 75% mais barata do que a edição SQL Server Enterprise e pode ser expandida para até 48 v CPUs e 128 GB de RAM. Como a limitação de 128 GB de RAM geralmente é atingida antes da limitação de 48 vCPUs, este é o foco da maioria dos clientes que desejam evitar a atualização para a edição SQL Server Enterprise.
O SQL Server tem um recurso chamado extensão do grupo de buffers
As extensões do grupo de buffers não substituem a RAM normal. No entanto, se você precisar de mais de 128 GB de RAM, poderá usar extensões de buffer pool com EC2 instâncias como r6id.4xlarge e x2iedn.xlarge para atrasar uma atualização para o licenciamento da edição Enterprise.
Workloads de alta performance (mais de 128 GB de RAM)
As workloads do SQL Server que exigem alta performance são um desafio para a otimização de custos devido à sua dependência de muitos recursos. No entanto, entender as diferenças nas EC2 instâncias pode impedir que você faça a escolha errada.
A tabela a seguir mostra uma variedade de EC2 instâncias otimizadas para memória e seus limites de desempenho.
| r5b | r6idn | r7iz | x2iedn | x2iezn | |
|---|---|---|---|---|---|
| Processador | 3.1 GHz Processador Intel Xeon de segunda geração |
3.5 GHz Processador Intel Xeon de terceira geração |
3.9 GHz Processador Intel Xeon escalável de quarta geração |
3.5 GHz Processador Intel Xeon de terceira geração |
4.5 GHz Processador Intel Xeon de segunda geração |
| Proporção CPU:RAM | 1:8 | 1:8 | 1:8 | 1:32 | 1:32 |
| Máximo de vCPU | 96 | 128 | 128 | 128 | 48 |
| RAM máxima | 768 GB | 1.024 GB | 1.024 GB | 4.096 GB | 1.536 GB |
| Armazenamento de instância | – | NVMe SSD (4x 1.900 GB) |
– | NVMe SSD (2x 1.900 GB) |
– |
| io2 Block Express | Compatível | Compatível | Compatível | Compatível | – |
| IOPS máxima do EBS | 260.000 | 350,000 | 160.000 | 260.000 | 80.000 |
| Throughput máximo do EBS | 60 Gbps | 80 Gbps | 40 Gbps | 80 Gbps | 19 Gbps |
| Largura de banda da rede máxima | 25 Gbps | 200 Gbps | 50 Gbps | 100 Gbps | 100 Gbps |
Cada instância é usada para uma finalidade diferente. Compreender sua workload do SQL Server pode ajudar você a escolher o tipo de instância mais adequado para você.
Detalhes sobre atributos:
-
r5b: o atributo “b” em r5b significa que esse tipo de instância está focado na alta performance do EBS. Na quinta geração de instâncias otimizadas para memória, a r5b foi a escolha de preferência. Foi o primeiro tipo de instância a utilizar volumes io2 Block Express e a atingir a IOPS máxima de armazenamento de 260 mil. O tipo de instância r5b ainda é uma alternativa econômica para as necessidades de alta performance do EBS.
-
r6idn: a sexta geração de instâncias otimizadas para memória ofereceu melhorias consideráveis em relação à geração anterior. Os aprimoramentos de performance do EBS da r5b são levados um passo adiante com a r6idn, aumentando a IOPS máxima para 350 mil. A r6idn também tem um volume de armazenamento de instâncias para extensões de grupos de buffers e tempdb para aumentar ainda mais a performance do SQL Server.
-
x2iedn: a x2iedn é semelhante à r6idn. Ele oferece níveis semelhantes de EBS aprimorado, rede aprimorada e armazenamento de instâncias NVMe SSD, mas com uma vCPU-to-RAM proporção de 1:32 para altas cargas de trabalho de memória e baixa quantidade de CPU (menores custos de licenciamento do SQL Server).
-
x2iezn: o atributo “z” em x2iezn indica que esse tipo de instância está focado na alta performance do processador. O processador Cascade Lake tem uma frequência turbo de todos os núcleos de até 4,5. GHz Recomendamos que você use essa EC2 instância, juntamente com uma vCPU-to-RAM proporção de 1:32, em um cenário em que você queira manter a quantidade de vCPU baixa. Isso, por sua vez, pode manter baixos os custos de licenciamento do SQL Server.
-
r7iz: o atributo “z” em r7iz indica que esse tipo de instância está focado na alta performance do processador. O processador Sapphire Rapids tem uma frequência turbo de todos os núcleos de até 3,9. GHz Como as instâncias x2iezn, o r7iz prioriza o desempenho do processador de alta frequência, mas com uma proporção de 1:8. vCPU-to-RAM
Recursos adicionais do
-
EC2Instâncias da Amazon de uso geral
(AWS documentação) -
Comparison tool
(Vantage) -
Licenciamento — SQL Server
(AWS documentação)
