Otimização de custo de SQL Server na nuvem AWS

Por Caio Ribeiro César, Phil Ekins e Bruno Lopes

Os clientes têm executado cargas de trabalho da Microsoft na AWS por mais de 12 anos, mais do que qualquer outro provedor de nuvem. Os clientes escolhem a AWS porque temos mais experiência com aplicativos Microsoft na nuvem e oferecemos a melhor plataforma para Windows Server e SQL Server nestas áreas: maior desempenho e confiabilidade, maior segurança e serviços de identidade, mais suporte à migração, o mais amplo e profundo portfólio de recursos, menor custo total de propriedade e opções de licenciamento flexíveis. A AWS oferece suporte a tudo que você precisa para construir e executar aplicativos do Windows, incluindo Active Directory, .NET, Microsoft SQL Server, desktop como serviço do Windows e todas as versões compatíveis do Windows Server. Com a nossa experiência comprovada, podemos ajudar clientes a migrar e efetuar resize, refatorar ou até mesmo modernizar suas cargas de trabalho do Windows.

Neste post, iremos discutir algumas estratégias de redução de custo para SQL Server na nuvem AWS.

1. Utilize o AWS OLA (Optimization and Licensing Assessment)

Como posso utilizar o OLA? Você pode trabalhar com um parceiro como Cloudmize, Cloudchomp ou até mesmo diretamente junto a AWS, conversando com seu gerente de conta. Faremos uma avaliação detalhada, coletando seus dados de infraestrutura.

O OLA fornecerá uma compreensão de como seus recursos estão sendo utilizados na origem, com relação as licenças e recursos, para nos dar um ponto de dados melhor para fornecer uma previsão precisa de como reduzir no ambiente de destino. Mas como? A partir da avaliação, podemos obter dados de desempenho e entender se você está com provisionamento excessivo ou com licenciamento acima do necessário.

2. Escolhendo o tipo certo de instância AWS

Precisamos sempre alinhar a carga de trabalho com o tipo certo de instância necessária. As instâncias amarelas desta lista também estão disponíveis em RDS e as sublinhadas também podem ser usadas como Dedicated Hosting. Para cargas de trabalho SQL Server associadas à memória tradicional, damos ênfase para as instâncias com memória otimizada, como r5 ou x1, e geralmente são instâncias adequadas. Se o seu ambiente for CPU “bounded” (com maior foco no consumo de CPU), oferecemos instâncias de computação intensiva, como a família c5.

Ao escolher o tamanho de computação correto para sua carga de trabalho significa que você está obtendo a proporção correta de memória e CPU e não está superprovisionando recursos, portanto, custos de licenciamento também.

Além disso, as instâncias R5b trazem IOPS mais alto e, consequentemente, maior largura de banda. Como a maioria dos ambientes SQL Server são IOPS “bounded“, você pode precisar de menos núcleos (vCPU) e  mais memória e performance de disco, portanto, menos necessidades de licenciamento.

3. Utilize CPU Optimization

Se olharmos para trás no mundo on-premises, ao construir o SQL Server, pediríamos um servidor com muita memória RAM (suponhamos 4 TB de memória) para um ambiente SQL clássico. Naquela época, normalmente não precisávamos de altas contagens de CPU, pois dependíamos da memória.

Hoje em dia você pode obter o mesmo servidor na nuvem, com os mesmos 4 TB de memória, que será fornecido com uma alta de quantidade de CPU, o que aumentará o custo de licenciamento. Porém podemos reduzir este custo de licenciamento com o CPU Optimization. Isso significa que podemos solicitar uma instância com muita memória RAM (como a r5 ou x1 mencionada anteriormente*) e, em seguida, habilitar o recurso de CPU Optimization para ela, usando menos núcleos e pagando menos licenças do SQL Server, o que reduzirá seus custos de banco de dados.

*Esses são apenas exemplos, lembrando de que há um requisito mínimo de 4 núcleos para licenças no SQL Server, o que significa que você pode redimensionar seu ambiente de tempos em tempos e testar qual desempenho é mais adequado, para que você não fique “licenciado demais”.

4. BYOL (traga sua própria licença) vs. License Included

Como você já deve ter percebido neste ponto, entender o licenciamento é fundamental para reduzir o custo dos ambientes de SQL Server. Os clientes adotam o BYOL (Bring Your Own License) por uma série de razões, sendo algumas delas exemplos como: já possuir suas licenças no ambiente de origem, aproveitar o benefício de usar suas licenças não utilizadas em ambientes híbridos, usar seus benefícios de garantia de software, como não pagar por seus nós passivos em cenários de HA ou DR com software assurance.

Por outro lado, os clientes também optam pelo modelo de “license included”, pois evita a complexidade dos requisitos de licença do SQL Server, como high water mark rule e outros. Consequentemente estes clientes também podem licenciar seu ambiente em uma base mensal e, em seguida, desligar os servidores quando o projeto for concluído, pagando apenas pelo que usam e também eliminando a necessidade de ter acordos com a Microsoft, como o Enterprise Agreement e o SCE. Além disso, às vezes não sabemos o quão “ocupado” o servidor vai estar, portanto, a licença incluída ajuda a não fazer um compromisso até que entendamos a carga de trabalho

Não existe mágica. A combinação dessas duas ofertas tornará você mais dinâmico e adaptável às mudanças em seu ambiente. O mais importante é simplesmente entender quando escolher uma das opções.

Lembre-se: BYOL só é aplicável ao EC2, enquanto License Included se aplica tanto ao EC2 quanto ao RDS.

5. Consolidação de Workloads SQL

Lembram quando mencionamos que precisamos de licenças de 4 núcleos no mínimo como um requisito para SQL Server? Isso significa que é uma boa ideia consolidar cargas de trabalho de SQL de pequeno porte em instâncias de tamanhos maiores.

O que significa que posso escolher instâncias com tamanho abaixo dos quatro núcleos mínimos e combiná-los em um único servidor.

No exemplo abaixo, temos quatro instâncias SQL, cada uma dimensionada com 2 vCPUs para um total de 8 vCPUs, mas que requer 16 núcleos sendo licenciados! Ao consolidar essas quatro instâncias em 2 instâncias maiores, eliminamos 50% do custo de licenciamento.

6. Considere o “step-down” de SQL Enterprise para SQL Standard

O step-down (reduzir o nível do licenciamento) da edição Enterprise para a Standard reduzirá o custo de licenciamento, bem como os custos anuais de Software Assurance. A partir do Service Pack 1 do SQL Server 2016, muitos recursos exclusivos para Enterprise também se tornaram disponíveis para a versão Standard. Isso significa que você pode estar executando um ambiente que não requer mais a edição Enterprise.

Mais recentemente, no SQL Server 2019, a funcionalidade Transparent Data Encryption (TDE) tornou-se uma opção da edição Standard. Neste ponto, a pergunta que precisamos nos fazer é: eu preciso da edição Enterprise? Se você estiver usando Read Replica, reindexação online, se seus servidores usarem mais de 128 GB de RAM para SQL Server, então sim. Compreender o ambiente e combinar a edição de licença apropriada é importante.

Outro exemplo é a arquitetura de alta disponibilidade para essas versões. Para a edição Enterprise, conforme ilustrado abaixo, usamos o grupo de disponibilidade Always On, com réplicas primária, passiva e de leitura versus o Standard, em que podemos implementar o mesmo modelo de alta disponibilidade usando cluster de failover do Windows Server e FSx como nosso armazenamento compartilhado.

Antes de fazer o downgrade, temos que levar alguns pontos em consideração, como por exemplo se você está no meio do prazo de seu Contrato Empresarial e se já adquiriu essas licenças em direitos de uso perpétuo.

7. Utilizando Dedicated Hosts (DHs)

Se você já possui licenciamento do sistema operacional Windows e deseja trazer suas licenças de software da Microsoft que não estão cobertas pelos benefícios do Software Assurance ou Mobilidade de Licença, você pode. Contanto que as licenças sejam adquiridas antes de 1º de outubro de 2019, ou adicionadas como um true-up sob um Enterprise Enrollment ativo que entrou em vigor antes de 1º de outubro de 2019. EC2 Dedicated Hosts são recomendados para clientes que desejam trazer suas licenças de SQL Server sem Software Assurance ativo.

Para que o SQL Server sem Software Assurance ativo seja elegível ao BYOL no EC2 Dedicated Host, a versão requerida deve ser um SQL Server 2017 ou anterior, e a licença deve ser adquirida junto a Microsoft antes de 1º de outubro de 2019, ou adquirida como um true-up sob um contrato Enterprise ativo que entrou em vigor antes de 01/10/2019.

O que significa que se a licença não atender a esses requisitos, os termos de licenciamento da Microsoft não permitirão o BYOL e consideramos então um RDS SQL ou EC2 com licença inclusa. Hosts dedicados (DH – Dedicated Hosts) podem oferecer benefícios de custo significativos e permitir que os clientes controlem o colocation de suas instâncias e licenças em um host fisicamente dedicado ao seu uso.

Para sistemas locais que usam intensamente virtualização ilimitada do Windows/SQL Server e desejam continuar a usar essa licença, DH é o caminho para fazer isso. Se você usa muito seu hypervisor e licencia o SQL Server por núcleos físicos, a locação compartilhada rapidamente torna o custo elevado demais para as cargas de trabalho do SQL Server, portanto, o DH pode ser uma opção melhor.

É importante ressaltar que nem todos os clientes licenciam o SQL Server no modelo de “core licensing”.

Clientes podem licenciar o Host Dedicado completo com SQL Enterprise Server + CAL, mas não podem alocar um número ilimitado de instâncias dentro deste Dedicated Host. Se formos comparar com ambientes on-premises, mesmo um host VMware não pode tecnicamente executar um número ilimitado de VMs com SQL Server.

Uma licença SQL Server Enterprise + CAL cobre o host, e então esse host é coberto por até 4 instâncias para um total de 20 vCPUs para estas instâncias. Se o cliente deseja ter mais de 4 instâncias/20 vCPUs em execução no host, ele pode simplesmente adicionar outra licença SQL Server Enterprise + CAL ao mesmo host para permitir um total de 4 instâncias/20 vCPUs adicionais. Além disso, neste modelo de licenciamento, o cliente também deve ter o número correto de CALs do SQL Server para cobrir os usuários/dispositivos com acesso direto ou indireto às instâncias do SQL Server no host.

Para finalizar, a automação do DH lida com a alocação de hosts, alocação de instâncias e, mais importante, recuperação (por exemplo, um auto-recovery em uma AZ diferente do DH original). Isso torna a experiência de configuração consistente, como as implantações de “shared tenancy”.

8. Utilizando Block-Level Replication

A replicação em bloco não apenas eliminará o requisito de licença do SQL Core em DR, mas também eliminará as instâncias EC2 que estariam em execução 24 horas por dia, 7 dias por semana no ambiente de recuperação de desastres (DR). A replicação de bloco é simplesmente copiar os dados brutos do disco de origem para o disco de destino – em nosso caso, o EBS.

Digamos que temos uma carga de trabalho SQL ativa/passiva usando BYOL, e já estamos usando os direitos de uso passivos do licenciamento. No entanto, é realmente importante entender que você só tem o direito de 1 uso passivo. O que acontecerá se também tivermos um requisito de DR para esse mesmo ambiente? Não importa como você projeta o nó de DR, se o SQL Server está lidando com a replicação ou mesmo o envio de log, você está sem direitos de uso passivo gratuito e tem que licenciar o DR como se fosse um ambiente ativo. É por isso que usar grupos de disponibilidade Always On para oferecer suporte a DR multirregional pode aumentar o custo da licença!

Qual poderia ser a solução? Algo tão simples como a replicação em bloco para o ambiente de DR pode fornecer proteção de DR sem exigir nenhuma licença SQL Server, até que você mude para o DR. Isso evita o custo de licenças extras necessárias e pode reduzir os custos de computação de DR, uma vez que o SQL Server não está em execução até que ocorra um evento de DR.

Logicamente, o grupo de disponibilidade Always On é uma tecnologia superior ao block-level replication. Porém, temos que ter em mente o custo-benefício da solução e principalmente valores necessários de RPO (Recovery Point Objective) e RTO (Recovery Time Objective), já que em block-level replication, temos que configurar o cluster via script ou manualmente.

9. Utilizando GP2 striping vs. Provisioned IOPS (ou melhor, GP3! J)

O armazenamento em bloco persistente é um componente crítico e, em última análise, responsável pela velocidade, segurança e durabilidade de seus dados. A AWS fornece armazenamento em bloco de alto desempenho e fácil de usar para atender às necessidades do SQL Server por meio do EBS. Embora você possa usar um único volume Provisioned IOPS (io1 ou io2) para atender aos seus requisitos de IOPS e taxa de transferência, os volumes General Purpose SSD (gp2) oferecem um equilíbrio líder de preço e desempenho para cargas de trabalho do SQL Server quando configurados adequadamente.

Os volumes GP2 fornecem latências de milissegundos de um dígito e a capacidade de expandir para 3.000 IOPS por longos períodos. Essa propriedade é adequada para SQL Server em cargas de trabalho não críticas, onde o desempenho máximo não é necessário 24 horas por dia. Além disso, o GP3 tem custo menor quando comparado ao GP2 (uma redução de aproximadamente 20%) e não possui a necessidade de aumentar o volume para aumentar IOPS!

Se você precisar de desempenho consistente, precisará de soluções IOPS provisionadas, como io1 e io2. O IO2 tem mais rendimento por gibibyte e muito mais durabilidade quando comparado ao IO1.

Para mais informações de GP2 striping, clique aqui.

10. Executando ambientes não produtivos em Developer Edition

Embora possa parecer simples, alguns clientes pagam licenciamento para seu ambiente de desenvolvimento. O SQL Server Developer é uma edição gratuita com recursos completos, licenciada para uso como banco de dados de desenvolvimento e até mesmo de teste em um ambiente de não produção. Isso significa que você pode desenvolver e testar SQL Server sem a necessidade de licenciar. Também podemos dar um passo adiante se quisermos reduzir mais custos – na camada do sistema operacional – com ressalvas.

• Com o SQL Server no Linux, temos o mesmo mecanismo de banco de dados SQL, com recursos e serviços semelhantes. Alguns clientes optam por executar seus ambientes de desenvolvimento e homologação no Linux. O Ubuntu, por exemplo, terá um custo menor de implementação quando comparado ao Windows.
• Suponhamos que você tenha um ambiente de desenvolvimento SQL Server e queira permitir que seus desenvolvedores façam testes de unidade, que são, em resumo, testes de pequenas alterações em seus códigos. Alguns ambientes de desenvolvimento usam licenciamento de produção incorretamente para seu ambiente de desenvolvimento. Com as inscrições do MSDN, esse não era um problema real; mas hoje em dia pode ser.

Com o AWS Dev fabric para SQL Server, que é uma solução de código aberto disponível no GitHub e criada por nossa equipe de arquitetos, podemos ajudar os clientes a reduzir significativamente o trabalho pesado do Amazon EC2. Isso é específico para ambientes de desenvolvimento, permitindo a implantação de várias instâncias do SQL Server em minutos para oferecer suporte às necessidades individuais dos desenvolvedores e aos esforços da equipe de desenvolvimento em minutos, além de remover as necessidades de licenciamento do Windows EC2. Esta solução executa o Ubuntu Linux em contêineres e traz a possibilidade de economizar quando comparada ao Amazon EC2 Windows, tornando-o uma boa opção para ambientes de desenvolvimento enquanto replataforma a camada de banco de dados.

Neste blog post, discutimos opções para redução de custo SQL na nuvem AWS. Para mais informações sobre SQL na AWS, clique aqui.

Sobre os autores

Caio Ribeiro Cesar atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 14 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.

Phil Ekins passou os últimos 25 anos trabalhando com bancos de dados e SQL Server no ambiente onpremises, virtualizado e na nuvem. Com ampla experiência orientando clientes em arquiteturas de nuvem, migrações e soluções HA / DR, Phil traz as necessidades do DBA para o mundo da computação em nuvem.

Bruno Lopes é Technical Trainer no time da AWS Brasil. Trabalha com soluções de TI há mais de 12 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes. Como Trainer, já está há mais de 5 anos dedicando seus dias a ensinar tecnologias de ponta aos clientes da América Latina.