Faça o downgrade do SQL Server Enterprise usando o AWS Systems Manager Document para reduzir custos

Aqui está o fluxograma que pode ajudá-lo a identificar os recursos mais usados da edição Enterprise.

Fluxograma para identificar os recursos mais usados da edição Enterprise

Para determinar se sua instância do SQL Service está usando os recursos da edição Enterprise, use esse script.

Downgrade manual do SQL Server Enterprise Edition:

Você pode fazer o downgrade da edição do SQL Server manualmente seguindo estas etapas. Essa é uma operação off-line e exigirá tempo de inatividade.

1. Certifique-se de ter um backup COMPLETO bem-sucedido de todos os bancos de dados do usuário e do sistema.
2. Anote a versão secundária atual do SQL Server, incluindo Service Pack, Atualizações Cumulativas e GDR.
3. Desanexe todos os bancos de dados de usuário.
4. Pare o SQL Server e copie os data files e log files do banco de dados do sistema (master, model, msdb) para a pasta de backup local.
5. Desinstale a edição SQL Server Enterprise, incluindo todos os componentes.
6. Reinicie o servidor.
7. Instale o SQL Server de acordo com suas necessidades, SQL Server Standard Edition ou SQL Server Developer Edition.
8. Instale os mesmos service packs e atualizações cumulativas que você tinha antes da desinstalação.
9. Pare o serviço do SQL Server e substitua os bancos de dados master, model e msdb pelos backups que você fez na etapa 4.
10. Inicie o serviço SQL Server e reconecte os arquivos mdf e ldf do banco de dados de usuário, que foram detectados na etapa 3, à instância do SQL Server.

Downgrade automatizado do SQL Server Enterprise Edition:

Neste blog, explicaremos como usar o AWS Systems Manager (SSM Document) para fazer o downgrade de sua instância existente do SQL Server da edição Enterprise para a edição SQL Server Standard. O documento SSM fornece uma maneira simples e segura de executar comandos ou scripts remotamente em instâncias do EC2 ou servidores locais.

Esta postagem do blog só se aplica ao caso de uso do Bring Your Own License (BYOL).

Figura 1: Downgrade do SQL Enterprise usando o documento SSM

Pré-requisitos

• Instância Windows do Amazon EC2 com a edição SQL Server Enterprise instalada.
• Bucket do Amazon Simple Storage Service (S3) para mídia de instalação do SQL Standard, atualização cumulativa e arquivo de configuração para instalar a edição SQL Server Standard.
• As instâncias do SQL Server EC2 que você está fazendo o downgrade precisam ter acesso ao bucket do S3 para baixar a mídia de instalação.
• O agente do AWS Systems Manager precisa ser instalado na instância do Amazon EC2 para SQL Server que você está fazendo o downgrade.
• SQL Server Management Studio com conexão à instância EC2 do SQL Server que você está fazendo downgrade.
• Verifique a versão do SQL Server executando o comando select @@version e certifique-se de fazer upload  da versão exata das atualizações cumulativas/Service Pack no bucket do S3.
• Role do IAM anexada à instância do Amazon EC2 com permissão de leitura no AWS Secrets Manager.

Ao usar o Systems Manager no EC2, você precisará primeiro preencher alguns pré-requisitos. O pré-requisito mais importante é que você precisa do AWS Systems Manager Agent (agente SSM) instalado em suas instâncias. O agente SSM é instalado por padrão nas instâncias EC2 do Windows Server 2016 e nas instâncias do EC2 criadas a partir do Windows Server 2003-2012 R2 Amazon Machine Images (AMIs) publicadas em novembro de 2016 ou posterior.

Outro pré-requisito é que suas instâncias precisam receber uma role do AWS Identity and Access Management (IAM). A role do IAM é usada para proteger as políticas de permissão necessárias para se comunicar com a API do Systems Manager. A role do IAM pode ser atribuída ao EC2 na criação. Você também pode adicionar uma função às instâncias existentes usando o AWS Console ou o AWS CLI.

Walk Through

A AWS oferece suporte a instâncias que executam várias versões e edições do Microsoft SQL Server.

Standard: esta edição permite o gerenciamento de banco de dados com o mínimo de recursos de TI, com oferta limitada de recursos e falta de alguns recursos de alta disponibilidade e poucas operações de DDL on-line em comparação com a edição Enterprise. A edição padrão tem uma limitação de 24 núcleos e 128 GB de memória.

Enterprise: Esta é a edição mais completa de todas. Com esta edição, você tem todos os recursos sem limitação de CPU e memória e é usada para cargas de trabalho de missão crítica.

Desenvolvedor: a edição SQL Server Developer inclui todas as funcionalidades da edição Enterprise, mas deve ser usada somente em ambientes que não sejam de produção.

As etapas a seguir mostram como fazer o downgrade da edição do SQL Server e, ao mesmo tempo, manter os objetos do sistema, como logins e servidores vinculados, em seu banco de dados master. Você precisa planejar o tempo de inatividade, pois esse é um processo off-line.

Aqui estão as etapas de alto nível executadas pelo documento SSM.

1. Faça backup completo dos sistemas e bancos de dados de usuários da edição existente do SQL Server Enterprise.
2. Pare os serviços do SQL Server.
3. Copie os arquivos do banco de dados físico master, model e msdb para a pasta Backup.
4. Desinstale o software da edição Enterprise.
5. Instale o SQL Server Standard ou a edição SQL Server Developer.
6. Instale a atualização cumulativa ou o service pack com base nos arquivos de patch fornecidos no local do S3.
7. Anexe bancos de dados de usuários do SQL Server da edição Enterprise à edição Standard ou Developer.
8. Pare os serviços do SQL Server.
9. Substitua os novos arquivos de banco de dados master, model e msdb pelo backup de arquivos realizado na etapa 3.
10. Inicie os serviços do SQL Server. Para este exercício, usaremos um documento SSM personalizado para realizar o downgrade da edição Enterprise.

Crie um documento SSM personalizado:

Encontre instruções detalhadas para criar um documento SSM personalizado. Baixe o SQLServerEditionDowngrade.ps como código-fonte para o documento personalizado Run Command. O script do PowerShell que você usa para criar um documento personalizado fará um backup de todos os bancos de dados do usuário, desinstalará a edição Enterprise, instalará a nova edição do SQL Server, anexará todos os bancos de dados de usuário, substituirá o banco de dados master e o banco de dados msdb usando arquivos de banco de dados dos quais fizemos backup anteriormente.

Figura 2: Conteúdo do documento do AWS SSM

Para instalar o SQL Server, o Systems Manager precisa acessar a mídia do SQL Server e o ConfigurationFile.Ini, que estão armazenados no S3. O exemplo do arquivo ConfigurationFile.ini é carregado no bucket do S3 para sua referência. Edite as contas de serviço e as senhas no arquivo de configuração de exemplo com base no seu ambiente e faça o upload do arquivo no mesmo bucket do S3.

Vamos fazer login no AWS Management Console. Para confirmar que suas instâncias estão em um estado para serem gerenciadas, certifique-se de que as listamos no console do Systems Manager em Painel do EC2 ou Instâncias gerenciadas. Na Figura 3 abaixo, você pode ver os nós gerenciados do Systems Manager.

Figura 3: Nós gerenciados do AWS SSM

São necessários 7 parâmetros de entrada, conforme mostrado na Figura 4.

InstanceID: instância EC2 de destino na qual o downgrade da edição do SQL Server é necessário. Podemos selecionar isso usando um seletor de instâncias interativo de todas as instâncias gerenciadas pelo Systems Manager.

BackupLocation: é o local onde residem os backups dos bancos de dados, por exemplo, D:\MSSQL\Backup.

EditionDowngradeUser: Nome secreto do AWS Secrets Manager que armazena o usuário e a senha do Windows AD que têm permissões de administrador na instância EC2 e na role de administrador do sistema para o SQL Server. Por exemplo, domain\ sqladmin.

S3BucketName: É o nome do bucket do S3 em que guardamos nossa mídia de instalação do SQL Standard e o ConfigurationFile.Ini, que instalará o SQL Server. por exemplo, sqlbackup.

S3CUName: Nome do arquivo de atualização cumulativa.

saPwdSecret: senha da conta “sa” do SQL Server se for uma instalação no modo de Autenticação Mista.

Figura 4: Parâmetros do documento do AWS SSM

Os parâmetros do documento SSM são armazenados no AWS Secrets Manager e no AWS Parameter Store.

Conforme mostrado na Figura 5, a senha de usuário do Windows AD e a senha SA são armazenadas no AWS Secrets Manager. Leia o AWS Secrets Manager para criar segredos e obter instruções detalhadas.

Figura 5: Segredos armazenados no AWS Secrets Manager

Conforme mostrado na Figura 6, os parâmetros restantes do documento são armazenados no AWS Systems Manager Parameter Store. Consulte as instruções detalhadas para criar parâmetros no Parameter Store.

Figura 6: Parâmetros armazenados no AWS Systems Manager Parameter Store

No bucket do S3, os binários da edição SQL Server Standard precisam ser armazenados no formato montado em uma pasta SQLInstall/ e em Cumulative Updates/Service Packs em uma pasta CU. Certifique-se de seguir a mesma estrutura de pastas mostrada na Figura 7.

Figura 7: Estrutura de pastas do bucket do S3

Podemos executar o documento SSM a partir do AWS Management Console ou por meio da CLI.

Figura 8: Executar documento SSM

A automação criará 3 arquivos de log na pasta C:\Windows\temp na instância EC2 do SQL Server. Você pode ver a saída do processo em cada etapa.

Aqui está a lista de verificações que o documento SSM validará antes da desinstalação e relatará um erro. Esse teste deve ser aprovado para executar o downgrade com êxito.

1. O SQL Server está instalado.
2. Somente uma instância do SQL Server está instalada. Se houver várias instâncias do SQL Server instaladas na instância do EC2, não continuará.
3. A edição do SQL Server é Enterprise.
4. O SQL Server está em execução.
5. Nenhuma reinicialização pendente ou operação de renomeação de arquivo pendente.
6. O SQL Server é independente. Se o SQL Server fizer parte do clustering ou dos grupos de Disponibilidade Always On. Se fizer parte da configuração do SQL Server Clustering ou do HADR, o script gerará um erro.

Depois que todas as verificações mencionadas acima forem concluídas, a automação começará a fazer backup de todos os bancos de dados de usuário e do sistema no BackupLocation com base no parâmetro de entrada. Verifique se você tem espaço suficiente disponível para todos os backups completos do banco de dados. Você precisará ter espaço livre equivalente ao tamanho total de todos os bancos de dados. Se o backup falhar em qualquer banco de dados, o documento SSM interromperá a execução, retornará um erro e será encerrado sem fazer o downgrade.

Depois que todo o backup do banco de dados for concluído, ele gerará um arquivo de script com comandos TSQL para anexar os bancos de dados de usuário após a conclusão do downgrade. Ele armazenará esse arquivo no mesmo local em que os backups são armazenados. Na próxima etapa, o script interromperá o serviço SQL Server, copiará os arquivos físicos master e msdb para a pasta de backup.

Conforme mostrado na Figura 9, a pasta de backup armazena backups do banco de dados de usuário, arquivos do banco de dados do sistema e scripts de anexação.

Figura 9: Conteúdo da pasta de backup

Na próxima etapa, o script de automação iniciará a desinstalação do SQL Server, incluindo outros componentes do SQL Server que estão instalados no servidor, como SSIS, SSAS, SSRS etc. Depois que a desinstalação for concluída, a próxima etapa é instalar o SQL Server Standard ou a edição Developer.

Para instalar o SQL Server Standard Edition, precisamos acessar a mídia de instalação do SQL Server. Para esta demonstração, já mantivemos nossa mídia SQL no bucket do S3, onde nossa instância EC2 tem acesso para baixar a mídia. A instalação do SQL será feita usando o ConfigurationFile.ini. Conforme mencionado, o ConfigurationFile.ini tem as informações sobre os parâmetros e recursos necessários para a instalação do SQL Server.

O script baixa automaticamente os arquivos do S3 e inicia a instalação do SQL Server. Depois que o SQL Server for instalado com êxito, ele procurará atualizações cumulativas para instalar. Após a conclusão da atualização cumulativa, o script continua anexando bancos de dados de usuário, master e msdb. Conforme mostrado na Figura 10, podemos encontrar o status dessa automação no AWS Systems Manager >Automation.

Figura 10: Status de execução do documento SSM

Desktop remoto em sua instância EC2 do SQL Server para verificar a edição e os arquivos de log do SQL Server. Os arquivos de log podem ser encontrados em C:\Windows\Temp.

A Figura 11 mostra um exemplo de arquivo de log.

Figura 11: Registro de automação de downgrade do SQL

Em seguida, vamos validar se os serviços SQL estão em execução e se podemos nos conectar à instância do SQL Server por meio do SQL Server Management Studio. Execute, select @@version para ver a edição atualizada. Conforme mostrado na Figura 12, devemos ver a versão como Standard Edition.

Figura 12: Validação de versão do SQL Server

Depois de verificar se está tudo certo, você pode excluir arquivos baixados do S3, arquivos de log gerados por documentos SSM e arquivos renomeados do banco de dados do sistema SQL Server, conforme mostrado na Figura 13.

Figura 13: Arquivos obsoletos do banco de dados do sistema

Conclusão

Neste post, mostramos como usar o documento de SSM da AWS para facilmente fazer o downgrade do SQL Server da Enterprise Edition para a Standard Edition. Muitos de nossos clientes gostariam de mudar da Enterprise Edition do SQL Server para a Standard Edition para economizar custos. Você pode usar o mesmo documento para fazer o downgrade do SQL Server Enterprise Edition para qualquer edição inferior fornecendo a mídia correta do SQL Server no bucket do S3. Para instâncias incluídas na licença da AWS, alterar a edição do SQL Server na instância não alterará o faturamento associado à AMI. Você deve migrar seus bancos de dados para uma nova instância do EC2 com uma AMI executando a nova edição do SQL Server e fazer o downgrade lado a lado.

Para obter mais informações, consulte Melhores práticas para implantar o Microsoft SQL Server no Amazon EC2.