O blog da AWS

Anúncio: Amazon RDS para SQL Server encerrando o suporte ao Microsoft SQL Server 2012

Por Bruno Lopes, Sr. Solutions Architect Specialist, Microsoft Workloads on AWS
Lucas Henrique Garcia, Arquiteto de Soluções de SMB na AWS
Luciano Bernardes, Sr. Solutions Architect Specialist, Microsoft Workloads on AWS

 

A Microsoft anunciou que encerrou o suporte ao SQL Server 2012 em 12 de julho deste ano (2022). Nessa data, a Microsoft interrompeu as atualizações críticas de patches para o SQL Server 2012. Sendo assim, é altamente recomendável que você atualize suas instâncias de banco de dados que ainda executam o SQL Server 2012 para uma versão mais recente o mais rápido possível, a fim de garantir que seus bancos de dados estejam mais seguros e protegidos. Visando minimizar os impactos para nossos clientes que fazem uso do SQL Server 2012 em instâncias do Amazon RDS, a AWS comunicou-os sobre o encerramento do suporte e organizou agendas de atualização, que estão acontecendo de forma automática e gerenciada. Caso você tenha alguma dúvida sobre este processo, sobre as datas de atualização enviadas ou demais situações relacionadas, por gentileza entre em contato com a equipe de Suporte da AWS através do link aqui referenciado.

 

Anúncio do fabricante sobre EOS (End of Support)

Desde 1º de setembro de 2021, havíamos desativado a criação de novas instâncias de banco de dados do Amazon RDS para SQL Server usando o Microsoft SQL Server 2012. No dia 1º de junho deste ano (2022), a AWS encerrou o suporte ao Microsoft SQL Server 2012 no Amazon RDS for SQL Server. A partir deste dia, todas as instâncias foram programadas para serem migradas automaticamente para o SQL Server 2014 (versão secundária mais recente disponível), conforme descrito abaixo:

 

 

No geral, para uma instância de banco de dados SQL Server, existem dois tipos atualizações possíveis:

  • Atualização de versão principal (por exemplo, atualizando do SQL Server 2012 para o SQL Server 2014)
  • Atualização de versão secundária (por exemplo, atualizando do SQL Server 2016 RTM para o SQL Server 2016 SP1)

Quando atualizações deste porte acontecem no Amazon RDS, você pode agendá-las para uma versão diferente acessando a página de modificação de instância no Console de Gerenciamento da AWS e alterando a versão do banco de dados para a versão desejada. Se você escolher a opção “Aplicar imediatamente”, a atualização será iniciada imediatamente após sair da página de modificação. Se você optar por não aplicar a alteração imediatamente, a atualização será agendada durante a próxima janela de manutenção.

SQL Server 2012 EOS (End of Support)

O encerramento do suporte ao SQL Server 2012 aconteceu em 12 de julho de 2022. Quando isto acontece, a Microsoft interrompe a disponibilização de atualizações de segurança e demais patches, o que pode deixar ambientes fora de conformidade e com riscos de segurança.

Clientes que utilizam suas próprias licenças do SQL Server, importadas através do processo conhecido como Bring Your Own License (BYOL) e que possuam Software Assurance (SA) ativado podem contratar através da Microsoft a extensão das atualizações de segurança (Extended Security Updates – ESU). Da mesma forma, clientes que utilizam SQL Server 2012 em modelo de licenciamento incluso (License Included) também podem adquirir esta extensão para terem os benefícios do suporte estendido em suas instâncias EC2 na AWS. Vale ressaltar que a contratação do ESU é limitada a três anos, então, eventualmente será necessário realizar o upgrade para se manter em conformidade e com suporte do fabricante.

O custo da contratação ESU é de aproximadamente 75% do valor da licença do produto, por ano. Para evitar este custo adicional, a AWS recomenda duas estratégias:

  • Realizar o upgrade para alguma versão ainda suportada e evitar o custo com a contratação ESU;
  • Trabalhar no planejamento para modernização e mover as estruturas de banco de dados elegíveis para soluções cloud-native e/ou open-source (como Amazon Aurora for PostgreSQL ou MySQL), evitando ciclos de suporte e lock-in com o fabricante.

Caso você opte pela segunda opção, sugerimos uma leitura sobre a solução fornecidade pela AWS, conhecida como DMA – Amazon Database Migration Accelerator, focada em opções programadas de migrações de databases com ferramentas e experts no assunto.

Uma vez que o SQL Server 2012 chegou ao fim do suporte, as AMIs com License Included dessa versão foram removidas da console AWS. Entretanto, clientes que já tenham AMIs customizadas com essa versão ainda podem criar novas instâncias EC2, caso necessário. Reiteramos a importância, contudo, de que estes ambientes sejam isolados, caso possível, e que medidas adicionais de segurança sejam adotadas para proteger seus ambientes.

 

Opções de Upgrade

Em uma plataforma self-managed, a atualização para a versão mais recente do banco de dados possui riscos associados, muitas vezes relacionados à falta de documentação dos ambiente e pelas complexidades dos pré-requisitos de migração, que muitas vezes são executadas por equipes distantes de DBAs e SysAdmins. Sabemos que, por diversas razões, várias empresas vivem de acordo com o lema “Se não estiver quebrado, não mexa”. Felizmente, muitos dos desafios que você normalmente enfrenta em uma plataforma self-managed são atenuados com a automações tais quais as que o Amazon RDS oferece.

Suportamos várias combinações diferentes de versão principal/secundária do SQL Server. Essas instâncias de banco de dados podem ser atualizadas diretamente para a versão secundária mais recente do SQL Server 2014, 2016, 2017 e 2019. Para obter mais informações sobre atualização, consulte o documento deste link.

Você ainda poderá restaurar um snapshot de um banco de dados do SQL Server 2012 para qualquer instância com suporte de versão principal no Amazon RDS SQL Server, mesmo após a descontinuação da versão 2012. Para obter mais informações sobre como restaurar um banco de dados no RDS, consulte a documentação aqui. Para questões técnicas de migração e para auxílios pontuais, bem como demais dúvidas ou preocupações sobre este processo, você poderá contar a ajuda com a equipe especializada do AWS Premium Support.

Como testar e atualizar sua instância no Amazon RDS for SQL Server

Em primeiro lugar, independentemente da plataforma ou das garantias oferecidas por qualquer serviço, recomendamos o planejamento de mudanças de acordo com as políticas de sua empresa; e que sejam realizados testes em ambientes não produtivos antes das alterações serem executadas em seus banco de dados de produção. O processo de testes pode ser extremamente simplificado em ambientes com Amazon RDS graças às automações disponíveis, o que reforça ainda mais as nossas recomendações. Com o Amazon RDS, você pode realizar seus testes por meio do AWS Management Console, da AWS CLI ou da API do RDS. Para simplificar, usaremos o console para atualizar nosso banco de dados no exemplo a seguir.

  1. Primeiro, crie um snapshot:
    • No console, escolha a instância que você deseja atualizar e, em seguida, escolha Take a DB Snapshot na área Actions
  2. Restaure o snapshot:
    • Quando o snapshot estiver concluído, escolha o mesmo e vá em Restore Snapshot, em Actions
    • Para fins de teste, recomendamos manter todas as especificações da instância iguais. Se você precisar, você pode modificá-las ao atualizar sua instância.
  3. Execute a atualização em seu snapshot:
    • Quando o snapshot terminar de restaurar, você poderá testar a atualização.
    • Recomendamos que você não permita operações de gravação na instância de banco de dados até confirmar que tudo está funcionando corretamente.
    • Além de todos os seus casos de teste normais, certifique-se de testar todas as Procedures e Functions armazenadas.
    • Em Instances, escolha o snapshot restaurado e escolha Modify em Actions. Quando se modifica uma instância de banco de dados, você pode fazer algumas atualizações diferentes além da versão da engine de banco de dados, incluindo o seguinte:
      • Classe de instância de banco de dados — Você altera a classe da instância para atender aos requisitos de computação ou memória.
      • Tipo de armazenamento — Você pode alterar o tipo de armazenamento de Provisioned IOPS ou General Purpose, dependendo de suas necessidades.
      • Monitoramento aprimorado — Recomenda-se ativar o monitoramento avançado para instâncias de produção.
        • Escolha a versão da engine de banco de dados para a qual você deseja atualizar. Nesse caso, escolhemos o SQL Server 2016.

 

    • Certifique-se de escolher Aplicar imediatamente. Caso contrário, sua instância não será atualizada até a janela de manutenção especificada.

Antes de atualizar sua instância, é importante levar em consideração alguns itens. Vamos mencionar a seguir uma lista com itens importantes a serem considerados:

Trabalhando com instâncias Multi-AZ

Ao atualizar uma instância Multi-AZ, o RDS executa a atualização na instância secundária primeiro. Após a conclusão do processo, um failover será executado e as atualizações serão realizadas no nó primário. Como atualizar seu banco de dados pode redefini-lo para suas configurações padrão, algumas customizações podem ser perdidas.

Vale ressaltar que, ao realizar essa alteração, o nó secundário precisará de um determinado período de tempo para copiar totalmente os dados para seus volumes EBS. Embora os volumes estejam disponíveis imediatamente, para que o desempenho de sua instância seja de acordo com o esperado, você precisará esperar até que o volume “aqueça” completamente. Por este motivo, ao realizar o processo de conversão entre Single-AZ e Multi-AZ, recomendamos que esta alteração seja realizada de três a quatro dias antes da atualização de versão do SQL Server. Esse período dará ao nó secundário mais tempo para sincronizar os dados antes que o failover aconteça e ele assuma o papel da instância principal.

Um outro ponto importante a ser considerado é o de que não se pode replicar o banco de dados Tempdb em instâncias Multi-AZ. Todos os dados que você armazena em suas instâncias primárias no Tempdb não estão disponíveis em suas instâncias secundárias. Durante uma atualização, essa funcionalidade pode causar problemas para as aplicações porque o Tempdb tenta fazer o registro automático com base na atividade da aplicação.

Para mitigar esse impacto, você tem duas opções:

    • Use o método mencionado anteriormente para modificar sua instância de banco de dados e desativar o Multi-AZ. Em seguida, modifique Tempdb e, finalmente, reative o Multi-AZ novamente. Esse método não requer tempo de inatividade.
    • Modifique Tempdb na instância primária original, depois faça o failover manualmente e modifique o Tempdb na nova instância primária. Esse método envolve tempo de inatividade.

Outros tópicos relevantes durante o processo de atualização a serem considerados são os seguintes:

Provisioned IOPS — Suponha que sua instância esteja no Single-AZ e que você esteja planejando mudar para o Multi-AZ para um tempo de inatividade mínimo antes da atualização. Nesse caso, se você estiver usando IOPS provisionados no Single-AZ e já estiver próximo do I/O máximo, recomendamos dobrar sua capacidade de I/O no cenário com Multi-AZ. Recomendamos isso porque sua instância secundária precisa de recursos adicionais para não ter impacto no desempenho do primário. Como as atualizações no Multi-AZ exigem um failover, uma quantidade de I/O inadequado pode prolongar os tempos de failover. A recuperação de banco de dados requer taxas de I/O maiores!

Compatibilidade de banco de dados do SQL Server — Para manter a compatibilidade com versões mais antigas do SQL Server durante a atualização, defina o nível de compatibilidade para a versão do SQL Server que você usa atualmente. Para obter os comandos e uma visão geral da compatibilidade, consulte ALTER DATABASE (Transact-SQL) Compatibility Level na documentação do SQL Server. Se você não alterar a compatibilidade do banco de dados, não poderá usar novos recursos na versão atualizada. Ao executar uma atualização, o RDS em si não altera o nível de compatibilidade do banco de dados.

Option Groups — Se sua instância de banco de dados usa um grupo de opções personalizado, em alguns casos, o Amazon RDS não poderá atribuir automaticamente a sua instância de banco de dados um novo Option Groups. Por exemplo, esse é o caso quando você atualiza para uma nova versão principal. Nesse caso, você deve especificar um novo Option Groups ao atualizar. Recomendamos que você crie um novo Option Groups e adicione as mesmas opções a ele como no seu Option Groups personalizado existente. Para obter mais informações, consulte Criando um Option Groups  ou Fazendo uma cópia de um Option Groups  na documentação do Amazon RDS.

Parameter Groups — Se sua instância de banco de dados usa um parameter group personalizado, em alguns casos, o Amazon RDS não poderá atribuir automaticamente a sua instância de banco de dados um novo parameter group. Por exemplo, esse é o caso quando você atualiza para uma nova versão principal. Nesse caso, você deve especificar um novo parameter group ao atualizar. Recomendamos que você crie um novo parameter group e configure os parâmetros como no parameter group personalizado existente. Para obter mais informações, consulte Criando um parameter group de banco de dados ou Copiando um parameter group de banco de dados na documentação do RDS.

Migrando para o RDS SQL Server — Oferecemos uma variedade de métodos diferentes de migração para o Amazon RDS para SQL Server que podem ser encontrados na documentação. Além disso, guias específicos podem ser encontrados em outras postagens do AWS Blog, como para restaurações nativas de backup, replicação contínua com o AWS DMS e replicação transacional. Também temos uma documentação completa sobre migrações de databases do SQL Server na nossa seção intitulada AWS Prescriptive Guidance – SQL Database Migrations.

Mesmo que o SQL Server 2012 não seja mais suportado, você ainda poderá migrar seu banco de dados local e realizar o lift and shift para o RDS. Lidamos com a atualização com base na instância do SQL Server que você provisiona, conforme descrito na documentação do RDS.

 

 

 

Conclusão

As informações contidas nesse blog foram organizadas para promover o conhecimento sobre o fim do suporte ao SQL Server 2012, pelo fabricante, e recomendar ações que ajudem a contornar, visando evitar cenários de não-conformidade e falhas de segurança por falta de atualizações. Reiteramos a importância de realizar o upgrade do SQL Server 2012 para uma versão superior e iniciar o planejamento para cenários de modernização.

 

Sobre os autores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

 

 

 

 

Lucas Henrique Garcia é Arquiteto de Soluções do time de SMB e trabalhou previamente no time de Premium Support da AWS em Dublin. Seu foco está em ajudar clientes da AWS a resolverem seus problemas e a desenhar arquiteturas para seus negócios.

 

 

 

 

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workloads Microsoft na nuvem AWS.