Escopo do projeto

Avaliação de compatibilidade do banco: versão, recursos usados, tamanho, taxa de mudança e objetos que o DMS deixa de replicar, como procedimentos e jobs, que são migrados à parte. Provisionamento do Amazon RDS Multi-AZ no mesmo motor (SQL Server para Amazon RDS for SQL Server, PostgreSQL para Amazon RDS for PostgreSQL, MySQL para Amazon RDS for MySQL; Oracle avaliado caso a caso). Instância de replicação do AWS DMS com tarefa de carga completa mais replicação contínua (CDC) e validação de dados.

Ensaio de virada em ambiente de teste. Virada: pausa de escrita, confirmação de que a replicação zerou, troca da string de conexão das aplicações, validação. Ajuste de parâmetros, alarmes e planos de backup. Operação assistida nas primeiras semanas.

Quando a aplicação for PostgreSQL ou MySQL e precisar de mais leitura e escala, o Amazon Aurora é avaliado como destino alternativo no mesmo projeto.

Desafio e problemas de hoje

  • Banco em servidor próprio, com patch atrasado e backup com restauração nunca testada.
  • Um único servidor: se cai, o sistema para.
  • Janela de parada aceitável de poucas horas, e a cópia completa levaria mais que isso.
  • DBA inexistente, ou é a mesma pessoa que cuida de tudo.
  • Crescimento do dado com plano de capacidade por fazer.
  • Várias aplicações e relatórios leem direto no banco, e ninguém sabe quantas.

O ambiente de partida (perfil típico deste exemplo)

Perfil típico do ambiente de partida deste exemplo
ItemO que costuma existir
BancoSQL Server, PostgreSQL ou MySQL, de 100 GB a 3 TB, uma instância, sem réplica
Onde rodaServidor físico ou VM no datacenter, ou instância Amazon EC2 instalada à mão
AplicaçõesERP ou sistema de gestão, relatórios, integrações que leem direto no banco
Volume de mudançaCentenas a milhares de transações por minuto em horário comercial; rotinas pesadas à noite
DependênciasString de conexão fixa em várias aplicações; jobs agendados no próprio banco; usuários locais; procedimentos armazenados
RestriçõesJanela de parada de 1 a 3 horas; dados pessoais sob LGPD; licenciamento do motor; link de internet único

Perfil típico, com faixas, construído a partir de projetos desse tipo. O inventário real é o primeiro entregável do diagnóstico.

Requisitos

  1. R1Migrar com o banco de origem em uso durante a cópia.
  2. R2Virada curta, com rollback possível.
  3. R3Alta disponibilidade com failover automático.
  4. R4Backup automático com retenção definida e restauração pontual.
  5. R5Patches e manutenção feitos pelo serviço gerenciado.
  6. R6Dados cifrados em repouso e em trânsito, acesso auditado (LGPD).
  7. R7Visibilidade de desempenho e alertas, inclusive da replicação durante a migração.

O que desenhamos para cada requisito

Decisão de arquitetura e serviço AWS para cada requisito
RequisitoDecisão de arquiteturaServiço AWS
R1Tarefa de carga completa mais replicação contínua (CDC) a partir do banco de origem em uso, por túnel privadoAWS Database Migration Service (AWS DMS), AWS Site-to-Site VPN
R2Ensaio de virada com validação de dados; virada real com pausa de escrita, latência de replicação zerada e troca de string de conexão; origem preservada até o aceiteAWS DMS (validação de dados)
R3Implantação Multi-AZ: instância primária em uma zona e réplica síncrona em espera na outra, com failover automáticoAmazon RDS
R4Backups automáticos com janela e retenção definidas, restauração pontual; cópias adicionais no plano centralAmazon RDS, AWS Backup
R5Janela de manutenção definida; versões menores aplicadas pelo serviçoAmazon RDS
R6Cifra em repouso com chaves gerenciadas, TLS obrigatório, sub-rede privada, acesso por função e trilha de auditoriaAWS Key Management Service (AWS KMS), Amazon VPC, AWS CloudTrail
R7Métricas, logs e alarmes de CPU, conexões, espaço e latência de replicação durante a migraçãoAmazon CloudWatch

Arquitetura

Diagrama de arquitetura: banco de dados de origem e servidor de aplicação no datacenter da empresa, conectados por AWS Site-to-Site VPN a uma Amazon VPC na AWS, onde o AWS DMS replica carga completa e mudanças para o Amazon RDS primário, com réplica síncrona em espera em outra zona de disponibilidade, protegido pelo AWS Backup e monitorado pelo Amazon CloudWatch.
O banco de origem continua em uso no datacenter enquanto o AWS DMS faz a carga inicial e replica as mudanças, por VPN, para o Amazon RDS primário; a réplica síncrona em espera fica em outra zona de disponibilidade. Na virada, a aplicação troca a string de conexão. AWS Backup e Amazon CloudWatch cobrem proteção e visibilidade. Abrir o diagrama em tela cheia
Componentes e fluxos deste diagrama
  • Datacenter da empresa: Banco de dados de origem e Servidor de aplicação.
  • AWS Site-to-Site VPN: túnel privado entre o datacenter e a Amazon VPC.
  • AWS DMS (zona de disponibilidade A): recebe a carga inicial e a replicação de mudanças do banco de origem, via VPN, e aplica no Amazon RDS primário.
  • Amazon RDS primário (zona A) e Amazon RDS em espera (zona B): réplica síncrona entre os dois.
  • Na virada: o Servidor de aplicação passa a usar a nova string de conexão, via VPN, para o Amazon RDS primário.
  • AWS Backup: protege o Amazon RDS.
  • Amazon CloudWatch: recebe a latência de replicação do AWS DMS.

Ganhos: o que medimos no projeto

Indicadores medidos no projeto, como são medidos e o que muda
IndicadorComo medimosO que muda
Janela de parada da viradaMinutos entre pausar a escrita na origem e liberar a aplicação no destinoDe cópia completa que estoura a janela para virada curta, porque os dados já estão replicados
Perda máxima de dados e tempo de retornoTeste de failover e de restauração pontual, com os tempos registradosDe servidor único para failover automático entre zonas, com backup pontual
Restaurações testadasTestes de restauração por trimestre e tempo de restauraçãoDe backup nunca restaurado para restauração pontual comprovada
Horas de administraçãoHoras por mês em patch, backup e manutenção do bancoDe tarefa manual para serviço gerenciado; a equipe cuida da aplicação e das consultas
Incidentes de capacidadeEventos de espaço ou CPU no limiteDe surpresa para alarme antes do limite e ajuste com parada curta

Indicadores de um projeto típico, medidos no próprio projeto: resultado típico, não garantia.

Escopo e entregáveis por fase

Fases do projeto, o que acontece, entregáveis e duração típica
FaseO que aconteceEntregáveisDuração
1. AvaliaçãoCompatibilidade do motor e da versão, inventário de objetos, aplicações que acessam o banco, taxa de mudançaRelatório de compatibilidade, lista de strings de conexão a trocar, plano de virada1 semana
2. Destino e replicaçãoAmazon RDS Multi-AZ provisionado, VPN, instância do DMS, carga completa e CDC, validação de dadosDestino em sincronia, relatório de validaçãode 1 a 3 semanas
3. EnsaioVirada em ambiente de teste, medição do tempo de virada, ajuste do roteiroRoteiro de virada e rollback validado1 semana
4. Virada e operação assistidaVirada real na janela acordada, alarmes, planos de backup, teste de failover, transferência para o time, desligamento da origem após aceiteAta de virada, alarmes ativos, teste de failover registrado, documentaçãode 1 a 3 semanas

Durações típicas, em faixa. O plano do projeto fixa as datas reais.

Algo a mais: banco instalado no Amazon EC2 ou banco gerenciado no Amazon RDS, quem faz o quê

Responsabilidades com o banco instalado no Amazon EC2 e com o banco gerenciado no Amazon RDS
ResponsabilidadeBanco instalado no Amazon EC2Banco gerenciado no Amazon RDS
Otimização da aplicaçãoVocêVocê
EscalabilidadeVocêAWS
Alta disponibilidadeVocêAWS
Backup do bancoVocêAWS
Patches do bancoVocêAWS
Instalação do bancoVocêAWS
Patches do sistema operacionalVocêAWS
Instalação do sistema operacionalVocêAWS
Manutenção do servidorAWSAWS
Ciclo de vida do hardwareAWSAWS
Rack, energia, refrigeração e redeAWSAWS

Modelo de responsabilidade comparado da AWS, conforme o Guia do usuário do Amazon RDS (comparação entre datacenter próprio, Amazon EC2 e Amazon RDS).

Perguntas frequentes deste exemplo

Durante a cópia, continua em uso. A parada acontece só na virada, para pausar a escrita e trocar a string de conexão, e é curta porque os dados já estão replicados.

Neste exemplo a migração é no mesmo motor. A troca de motor (por exemplo, para PostgreSQL ou Amazon Aurora) é outro projeto, com conversão de esquema e testes mais longos.

O DMS replica dados; procedimentos, jobs e usuários são migrados à parte, por script, e fazem parte do inventário da fase 1.

Dados cifrados em repouso e em trânsito, banco em sub-rede privada, acesso por função e trilha de auditoria. A base legal e o mapeamento de dados pessoais continuam sendo da empresa; o projeto entrega os controles técnicos.

O Amazon RDS assume backup, patches, failover e escala. A equipe cuida da aplicação e das consultas; a RFX pode manter a operação gerenciada, se contratada.

Serviços AWS deste exemplo

  • AWS Database Migration Service (AWS DMS)
  • Amazon RDS
  • AWS Backup
  • Amazon CloudWatch
  • AWS Key Management Service (AWS KMS)
  • Amazon VPC
  • AWS Site-to-Site VPN
  • AWS CloudTrail
  • Amazon Aurora (variante)

Incentivos AWS

A RFX busca para o projeto os programas de incentivo e créditos da AWS aplicáveis, sempre sujeitos a aprovação da AWS.

Agende uma conversa com um especialista

Conte em uma linha o que você tem hoje. Um engenheiro da RFX responde em até 4 horas úteis com o próximo passo para o seu caso. O primeiro contato é uma conversa técnica; a proposta vem depois, se fizer sentido para você.

Ver cases reais da RFX (anonimizados por confidencialidade)

A RFX busca para o projeto os programas de incentivo e créditos da AWS aplicáveis, sempre sujeitos a aprovação da AWS.

Onde roda hoje? (opcional)
Prazo? (opcional)

Quem responde é um engenheiro da RFX, AWS Partner Advanced Tier, em até 4 horas úteis. Usamos seus dados para responder a este contato, conforme a Política de Privacidade.

Casos relacionados

Migração

ERP e servidores com AWS MGN

Replicação contínua dos servidores e virada com janela curta, chegando num ambiente governado desde o primeiro dia.

Caminho: Mover (Rehost) · Duração típica: de 6 a 12 semanas

Ver o exemplo
Modernização

Aplicação em contêineres no Amazon ECS ou EKS

A aplicação que precisa continuar como está é empacotada em contêiner, roda em duas zonas, escala e recebe atualizações frequentes com a plataforma administrada pela AWS.

Caminho: Ajustar (Replatform), com Redesenhar pontual · Duração típica: de 6 a 12 semanas

Ver o exemplo
Fundação

Ambiente base (landing zone)

Governança central, duas zonas de disponibilidade e backup desde a primeira conta: o ponto de partida antes de migrar o primeiro sistema.

Caminho: Fundação · Duração típica: de 2 a 4 semanas

Ver o exemplo
Falar com um engenheiro