Como migrar os bancos de dados para soluções em nuvem

Por Angie Nobre, Arquiteta de Soluções Senior para Database da AWS

Migrações de bancos de dados para nuvem tornaram-se prioridade em muitas empresas, impulsionado fortemente por fatores como:

• Necessidade de atualização de hardware e software são trabalhosas e geralmente demandam projetos de longa duração.
• Acompanhar as limitações impostas por “End of Life” dos produtos também é um desafio devido à falta de suporte do software, não ter mais acesso às correções do produto, e incompatibilidade com aplicações em versões mais recentes.
• Em nuvem, os ambientes que não estão em uso por longos períodos como ambientes de homologação e desenvolvimento, podem ser parados durante finais de semana e períodos sem atividade, reduzindo o custo de utilização.
• Agilidade na adequação à carga de trabalho imposta ao banco de dados, habilitando scale up/down e scale in/out.
• Atualizações em bancos de dados frequentemente precisam áreas de manobra para segurança da execução por exemplo de um upgrade de versão, tanto em armazenamento como em capacidade computacional. Em um ambiente on-premises é necessário adquirir um novo equipamento para viabilizar uma manutenção com segurança. Em cloud é possível utilizar o ambiente de manobra para uma tarefa que implica em maior risco, somente pelo período necessário da manutenção, sem a necessidade de aquisição de novos equipamentos.
• Necessidade de uma solução de banco de dados com melhor escalabilidade e agilidade para as aplicações que também precisam de soluções nativas na nuvem.

Estratégias de migração:

Os ambientes de bancos de dados são complexos, sendo fundamental avaliar também a camada de aplicação e a melhor forma de migrar preferencialmente as duas camadas (banco e aplicação) juntas para nuvem.

Tipicamente o mercado utiliza soluções on-premises baseadas em bancos de dados como:

• Oracle
• Microsoft SQL Server
• PostgreSQL
• MySQL

Para escolher a melhor estratégia e solução de banco de dados, é fundamental mapear os seguintes aspectos:

• Quais são os requerimentos de disponibilidade que a aplicação precisa atender para suportar o negócio?
• O ambiente atual atende tais requerimentos?
• A camada de aplicação está em uma arquitetura compatível para executar em nuvem ou precisa de conversão?
• Baseado na compatibilidade da aplicação o banco precisa ser mantido em seu software de banco de dados atual ou pode ser convertido para uma solução nativa em nuvem?
• Qual método ou ferramenta atenderá melhor o tipo de migração requerida.

A seguir vamos abordar de uma forma prática e objetiva alguns tipos de migração de banco de dados.

Como escolher a melhor estratégia para migrar o ambiente de banco de dados?

Entre os fatores de decisão para escolher a estratégia de migração, passa por decidir entre as opções abaixo:

• O software de banco de dados atual atende os requisitos da aplicação e se precisa ser mantido exatamente o mesmo. Por exemplo caso a aplicação não pode ser convertida para outro banco e a melhor alternativa de migração é manter o software de banco de dados.
• A aplicação está apta a passar por um processo de modernização e as estruturas de tabelas, índices e demais códigos (em funções, procedures, ou triggers por exemplo) podem ser convertidos para uma nova estrutura. Por exemplo a estrutura do banco pode ser convertida de Oracle para PostgreSQL, dessa forma utilizando as ferramentas de apoio é viável definir um plano de conversão e migração.
• Validar se um serviço gerenciado como RDS atenderá melhor a performance e disponibilidade da aplicação e reduzir a carga administrativa e operacional, ou então se a aplicação requer o banco de dados em uma instância EC2.

Após definidos esses fatores, para planejar a migração de bancos precisamos:

• Verificar métricas de utilização do ambiente (CPU, Memória e IOPS) para dimensionar o requerimento de instância correto.
• Identificar os requerimentos de disponibilidade do banco, caso ocorra uma falha no ambiente de banco de dados, em quanto tempo (RTO) precisa estar disponível novamente para a aplicação. E se ocorrer essa falha quanto tempo de perda as transações é aceitável (RPO).
• Identificar o tamanho do banco e o tempo de indisponibilidade que a aplicação pode suportar.
• Identificar a ferramenta ou técnica adequada de migração.
• Mapear os critérios de sucesso para a operação do banco de dados em nuvem.
• Planejar os testes de migração do banco de dados e da aplicação, para validar a estratégia de migração e a performance das aplicações. Assim certifica que o processo adotado irá atender adequadamente as necessidades do ambiente.
• Após os testes, identificar eventuais correções e ajustes do processo de migração.

Aqui estão alguns cenários como exemplo de modernização dos ambientes de bancos de dados on-premises para nuvem, separando em dois tipos migrações homogêneas (onde não há mudança do software de banco de dados) e migrações heterogêneas (onde há mudança do software de banco de dados).

Migrações homogêneas:

• Oracle on-premises para Oracle na AWS
• SQL Server on-premises para SQL Server na AWS
• PostgreSQL on-premises para Amazon RDS PostgreSQL ou Aurora PostgreSQL
• MySQL on-premises para RDS MySQL ou Aurora MySQL

Migrações heterogêneas:

• Oracle on-premises para Amazon RDS PostgreSQL ou Aurora PostgreSQL
• SQL Server on-premises para Amazon Aurora MySQL ou Amazon Aurora PostgreSQL

Migrações homogêneas

Em migrações onde não haverá mudança da solução de banco de dados e a escolha em geral tem como base se será um serviço gerenciado ou se irá usar o seu banco de dados em EC2, as ferramentas nativas de cada solução são as melhores formas de replicar e migrar o banco de dados.

Como migrar Oracle on-premises para AWS:

A migração banco de dados Oracle on-premises para Oracle na AWS é uma boa alternativa em algumas condições, por exemplo:

• A aplicação não pode ser convertida para outro tipo de banco de dados devido à compatibilidade e ou versão.
• Maior flexibilidade e escalabilidade quanto aos tipos de instância e storage, podendo aumentar ou reduzir recursos alocados para a instancia com mais facilidade e menores impactos de custo.
• Automação de tarefas em serviço gerenciado (RDS Oracle) como aplicação de patches, backup automático, criação de réplicas de leitura, failover automático para uma instancia standby (Multi-AZ) em caso de falhas.

Você pode utilizar Oracle na AWS de duas formas:

• Em uma instância EC2, onde terá total controle e administração da instância, bibliotecas do sistema operacional e instalação do software de banco de dados.
• Em RDS Oracle, onde você criará o schema que será utilizado pela aplicação, e terá disponível a automação de tarefas de um serviço gerenciado.

A documentação abaixo traz recomendações sobre como escolher a melhor alternativa para o seu ambiente Oracle na AWS:
https://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/choosing-between-amazon-rds-amazon-ec2-or-vmware-cloud-on-aws-for-your-oracle-database.html

Para identificar se a melhor opção é utilizar RDS ou Oracle em EC2, é importante avaliar:

• Dimensionamento, verificando as métricas de utilização do banco de dados, tais como CPU, memória, IOPS e throughput, daí então buscar o tipo de instância adequado para suportar o workload. Caso necessário, consulte um dos nossos arquitetos de solução para apoiar.
• Validação se a aplicação faz uso de opções adicionais (options) da versão Enterprise Edition, tais como partitioning, advanced compression, parallel, entre outras que podem ser validadadas na lista:

https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-B6113390-9586-46D7-9008-DCC9EDA45AB4
Para aplicações que não necessitam das options da versão Enterprise Edition e a quantidade de recursos estão adequadas até 16 VCPUs, uma boa opção é Oracle Standard Edition Two.

• Requisitos da aplicação:

1. 1. 1. A aplicação requer acesso às bibliotecas do sistema operacional e arquivos de instalação do banco? Se sim, não é possível utilizar RDS, pois é um serviço gerenciado que não oferece essa opção.
      2. A aplicação requer acesso aos usuários SYS e/ou SYSTEM do banco Oracle? Se sim, não é possível utilizar RDS, pois é um serviço gerenciado que não oferece essa opção.
      3. Qual o RTO da aplicação caso ocorra uma situação de failover da instância de banco de dados, suportaria entre 1 e 2 minutos? Se sim, RDS atende esse requisito.

No link abaixo , você pode verificar versões suportadas, funcionalidades e restrições:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html

Após o dimensionamento dos recursos necessários (CPU, memória, IOPS, e throughput) , é possível verificar qual tipo de instância será mais adequada para acomodar o workload:
https://aws.amazon.com/rds/oracle/instance-types/

Nesse quick start você encontrará um guia completo para implementar Oracle em EC2:
https://aws-quickstart.github.io/quickstart-oracle-database/

Nessa referência abaixo você encontrará o guia para implementar RDS Oracle:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Oracle.html

Quais métodos de migração de Oracle on-premises para AWS:

Para planejar as estratégias possíveis de migração é importante identificar a versão do Oracle, plataforma e tamanho do banco de dados no ambiente on-premises.

Quais são os cenários recomendados para a execução da migração para a AWS?

1. Origem Oracle em Linux ou Windows x86-64 – Destino Oracle em Linux ou Windows EC2:

Oracle em ambientes Linux x86-64 ou Windows apresentam compatibilidade de plataforma com o Oracle em EC2, assim é possível gerar um backup do ambiente de origem (por meio de rman ou cópia de datafiles), e manter uma sincronização por meio de archived log files (inclusive Oracle Data Guard).

2. Origem Oracle (todas as plataformas) – Destino RDS Oracle:

Datapump é um formato de backup compatível entre todas as plataformas, sozinho o datapump é um método amplamente conhecido pelos especialistas e relativamente fácil de utilizar. Se associado ao DMS, o método pode reduzir o tempo de indisponibilidade da migração.

https://aws.amazon.com/blogs/database/migrating-oracle-databases-with-near-zero-downtime-using-aws-dms/

Nesse documento você encontrará descrito em detalhe cada um dos métodos de migração:
https://d1.awsstatic.com/whitepapers/migrating-oracle-database-workloads-to-oracle-linux-on-aws.pdf

Migração de SQL Server on-premises para SQL Server na AWS

Quando planejamos migrar o SQL Server on-premises para a AWS precisamos levar em consideração os seguintes fatores:

• Preciso de serviço gerenciado ou preciso de acesso irrestrito a todas as estruturas do banco de dados?
• Qual a quantidade de recursos necessária para acomodar o workload das aplicações que vou migrar?
• Qual a forma de licenciamento?

É possível utilizar o SQL Server na AWS de duas maneiras:

• Instalar o SQL Server em instâncias Windows em Amazon EC2, dessa forma você terá controle total.
• Utilizar Amazon RDS SQL Server como um serviço gerenciado, dessa forma desde a instalação do sistema operacional, software de banco de dados, bem como as tarefas administrativas como automação de backup, aplicação de patches, habilitar alta disponibilidade e configuração da monitoração já estão disponíveis na plataforma e pronta para o uso.

Como escolher qual é a melhor alternativa de migração para o workload em questão?

• Segue abaixo os fatores importantes para optar por SQL Server em EC2:

• • • Requer o controle total da instância de banco de dados e sistema operacional.
    • O gerenciamento do backup e replicação precisa ser controlado pelos times locais.
    • O gerenciamento de clusterização precisa ser controlado pelos times locais.
    • Requer acesso à role sysadmin

• E fatores para optar por RDS SQL Server:

• • • Preferência por banco de dados nativo na nuvem.
    • Maior foco nas atividades relacionadas ao negócio.
    • Maior foco nas tarefas de ajuste (tuning) de performance de alto nível.
    • Maior foco em otimização do schema do banco de dados.
    • Requer menor capacitação relacionado a tecnologia de banco de dados utilizada.

Quais são as versões disponíveis de SQL Server na AWS?

Na referência abaixo você pode acompanhar as atualizações de versões do RDS SQL Server:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html

Na documentação abaixo você encontra o guia completo para instalar SQL Server em Amazon EC2:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-windows-launch-sql-server/

Na documentação abaixo você encontra o guia para implementar o Amazon RDS SQL Server:
https://aws.amazon.com/getting-started/hands-on/create-microsoft-sql-db/?nc1=h_ls

Quais as formas de licenciamento do SQL Server na AWS?

• Licença incluída (LI – License Included): em SQL Server em Amazon EC2 e Amazon RDS SQL Server.
• Utilizar sua própria licença (BYOL – Bring your own license): SQL Server em Amazon EC2.

No documento abaixo descreve em detalhes cada as duas formas:

https://aws.amazon.com/windows/resources/licensing/?nc1=h_ls

Quais métodos de migração disponíveis de um banco Microsoft SQL Server on-premises para AWS?

Migrar os bancos utilizando os bancos com as ferramentas nativas, são os metodos com o menor esforço de configuração. É fundamental na fase de planejamento identificar o melhor método de acordo com as características do ambiente.

Verifique no documento abaixo cada método em detalhe e considerando também o caso de uso:
https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html

Como migrar um banco de dados MySQL para AWS:

A melhor forma de migrar um banco de dados que apresenta a mesma engine na nuvem, como é o caso do MySQL, é utilizando as ferramentas nativas como o mysqldump. O Amazon Aurora MySQL é compatível também com o PerconaXtraBackup

O documento abaixo descreve em detalhes como utilizar o mysqldump para migrar o seu MySQL on-premises para AWS:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

E nesse outro documento descreve como migrar seu banco MySQL para Amazon Aurora MySQL utilizando Percona XtraBackup:

https://aws.amazon.com/pt/blogs/aws-brasil/como-migrar-seu-banco-de-dados-mysql-para-amazon-aurora/

Como migrar um banco de dados PostgreSQL para AWS:

A melhor forma de migrar um banco de dados que apresenta a mesma engine na nuvem, como é o caso do PostgreSQL, é utilizando as ferramentas nativas.

As ferramentas pg_dump, pg_restore, replicação lógica e o comando copy são compatíveis com os serviços gerenciados Amazon RDS PostgreSQL e Amazon Aurora PostgreSQL.

O documento abaixo descreve em detalhes como utilizar tais ferramentas:

https://aws.amazon.com/blogs/database/best-practices-for-migrating-PostgreSQL-databases-to-amazon-rds-and-amazon-aurora/

Migrações heterogêneas

Em um processo de modernização de banco de dados, a diretriz de buscar soluções de código aberto está crescendo de forma significativa. Atualmente as soluções de bancos de dados “Open Source” já superam as licenças comerciais:

Fonte: https://db-engines.com/en/ranking_osvsc

Os fatores que impulsionam essa mudança de soluções são:

• Alto custo das licenças comerciais.
• Avanço no nível de maturidade das soluções de código aberto, disponibilizando alta disponibilidade e resiliência.
• Disponibilidade de ferramentas que ajudam durante a conversão das estruturas de banco de dados e códigos fonte, e consequentemente podem mapear o esforço necessário e reduzir o esforço de conversão.
• Disponibilidade de ferramentas para a migração do dado entre diferentes distribuições de bancos de dados.

Como migrar uma base de dados Oracle on-premises para Amazon RDS PostgreSQL ou Aurora PostgreSQL

Tratando-se de soluções diferentes de banco de dados, é necessário utilizar ferramentas de conversão da estrutura e em seguida utilizar uma solução para migrar os dados entre a origem e o destino.

1. Converter a estrutura originalmente em Oracle para PostgreSQL:

Para conversão dos objetos a AWS disponibiliza a ferramenta Amazon SCT (Schema Convertion Tool), que está disponível para Windows, Ubuntu, e Fedora  no link para download https://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Installing.html.

Para o processo de conversão será necessário criar um banco de dados RDS PostgreSQL ou Amazon Aurora PostgreSQL e seguir as instruções do manual https://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Converting.html.

2. Migrar os dados armazenados nas tabelas do Oracle para PostgreSQL:

A AWS disponibiliza como serviço gerenciado, a ferramenta Amazon DMS (Database Migration Service). O DMS conecta-se em diferentes origens e destino, faz a carga inicial (full-load) e mantém o CDC (change data capture) para a atualização contínua entre origem e destino.

O blog abaixo demonstra em detalhe como proceder com a migração: https://aws.amazon.com/blogs/database/how-to-migrate-your-oracle-database-to-PostgreSQL/.

Como migrar uma base de dados Microsoft SQL Server on-premises para Amazon Aurora PostgreSQL e Aurora MySQL

Tratando-se de soluções diferentes de banco de dados, é necessário utilizar ferramentas de conversão da estrutura e em seguida utilizar uma solução para migrar os dados entre a origem e o destino. A primeira parte que trata a conversão por meio da ferramenta SCT, e se aplica aos dois casos.

A segunda parte é específica para a engine MySQL ou PostgreSQL

1. Converter a estrutura originalmente em SQL Server para MySQL:

Para conversão dos objetos a AWS disponibiliza a ferramenta Amazon SCT (Schema Convertion Tool), que está disponível para Windows, Ubuntu, e Fedora  no link para download https://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Installing.html.

Para o processo de conversão será necessário criar um banco de dados Amazon Aurora MySQL e seguir as instruções do manual https://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Converting.html.

2. Migrar os dados armazenados nas tabelas do SQL Server para Aurora:

A AWS disponibiliza como serviço gerenciado, a ferramenta Amazon DMS (Database Migration Service). O DMS conecta-se em diferentes origens e destino, faz a carga inicial (full-load) e mantém o CDC (change data capture) para a atualização contínua entre origem e destino.

2.1. O documento abaixo demonstra em detalhe como proceder com a migração de SQL Server para Aurora PostegreSQL:

https://d1.awsstatic.com/whitepapers/Migration/sql-server-database-amazon-aurora-postgresql-migration-playbook-12.4.pdf

2.2 O blog abaixo demonstra em detalhe como proceder com a migração para Aurora MySQL:

https://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/migrate-a-microsoft-sql-server-database-to-aurora-mysql-by-using-aws-dms-and-aws-sct.html.

Resumo

A administração de bancos de dados on-premises é uma tarefa que demanda tempo, recursos e profissionais especializados. E as empresas tem adotado cada vez mais a estratégia de buscar como primeira opção utilizar seus bancos de dados na nuvem.

A disponibilidade de soluções de bancos de dados compatíveis com suas aplicações atuais e as estratégias adequadas de migração certamente irão ajudar a acelerar o processo de adoção da nuvem.

Sobre a autora

Angie Nobre Cocharero é Senior Database Migrations Specialist Solution Architect na AWS.

Sobre os revisores

Leonardo Ciccone é Senior Database Consultant no time de Proserv na AWS.

Fabricio Quiles é Senior Analytics Specialist Solution Architect na AWS.

Daniel Soto é Associate Solutions Architect na AWS.