DR — Disaster Recovery Strategies
Este é um texto produzido para estudar para mais uma certificação. Tem vários copia e cola, anotações, e experiências minhas sobre o tema.
“Disaster Recovery” é sobre preparar para se recuperar de um evento negativo que prejudica a continuidade do negócio ou financeiro. Mas antes, é necessário entendermos oque é :
- RPO (Recovery Point Objective) — Quantos dados se está disposto a perder?
- RTO (Recovery Time Objective) — Quanto tempo se está disposto a ficar fora do ar? Quanto tempo demora pra voltar?
Estratégias de DR
O diagrama abaixo ilustra bem a evolução do tema DR. Além de ilustrar como ao avançar nas técnicas, diminuindo o tempo de indisponibilidade aumentamos o custo.
1. Backup and Restore — tem o mais alto RPO, e o menor custo, porém o maior tempo de inatividade
2. Pilot Light
Uma pequena versão da aplicação está sempre em execução na “cloud”. Utilizamos esta técnica apenas para as aplicações mais críticas, e em caso de desastre adicionamos os sistemas não criticos utilizando a estratégia “Backup and Restore”.
3. Warm Standby
“Warm Standby” é quando temos um sistema completo em funcionamento, com um tamanho mínimo, para que esteja pronto em caso de desastre e que possamos escalá-lo para a carga de produção.
Nesta estratégia, possívelmente possamos utilizar o “workload” a direita como fonte de consulta, mesmo sem termos um desastre.
4. Hot Site / Multi Site Approach / Multi AZs — tem o mais baixo RPO, e o maior custo e o menor tempo de inatividade em caso de um desastre
Na estratégia HotSite, Multi Site, Multi AZs temos o menor tempo de recuperação, porém o maior custo porque você tem duas escalas de produção completamente provisionadas e em execução, ou seja os dois estão ativos e operantes.
AWS Multi Region
Disaster Recovery Tips
Backup
- EBS Snapshots
- RDS automated backups
- Regular pushes to S3/S3 Glacier, lifecycle policy, cross-region replication
- From on-premise: Snowball or Storage Gateway
High Availability
- Use Route53 to migrate, DNS over from Region to Region
- RDS Multi-AZ, ElasticCache Multi-AZ, EFS, S3
- Site to Site VPN as recovery from Direct
Replication
- RDS Replication (Cross-Region), AWS Aurora + Global Databases
- Database replication from on-premises to RDS
- Storage Gateway
Automation
- CloudFormation / Elastic Beanstalk to re-create a whole new environment
- Recover / Reboot EC2 instances with CloudWatch if alarms fail
- AWS Lambda functions for customized automation
Chaos
- RDS Multi-AZ, ElasticCache Multi-AZ, EFS, S3
- Site to Site VPN as recovery from Direct Connect
Desafios comuns da “Recuperação de desastres”
- Alto custo de recursos duplicados sem uso (em espera)
- Falta de habilidade de recuperar backups
- Diferentes ferramentas para recuperar partes diferentes do sistema
AWS PartnerCast: Oque você pode fazer com “Networking na AWS”
DMS — Database Migration Service
Digamos que você queira migrar um banco de dados dos seus sistemas locais para a nuvem do AWS. Nesse caso, você deve usar o DMS, ou Database Migration Service.
DMS é um serviço de banco de dados rápido e seguro que permite que você migre seu banco de dados do local para o AWS, mas o mais legal é que ele é resiliente e autorrecuperável. Durante toda a migração, o banco de dados de origem continua disponível.
Oferece suporte a vários tipos de mecanismos, como migração homogênea, portanto, de Oracle para Oracle ou Postgres para Postgres, mas também migrações heterogêneas. Por exemplo, se você quiser migrar do Microsoft SQL Server para o Aurora e ele for compatível com a replicação contínua de dados usando o CDC, que é o Change Data Capture.
Por fim, para usar o DMS, você precisa criar uma instância do EC2, e essa instância do EC2 executará as tarefas de replicação para você.
AWS Schema Conversion Tool (SCT)
E se o banco de dados de origem e o banco de dados de destino não tiverem o mesmo DB Schema? Você precisará usar algo chamado AWS SCT, sigla em inglês para Ferramenta de Conversão de Esquema, que converterá o esquema do banco de dados para outro. Por exemplo:
- OLTP — podemos migrar de SQL Server ou Oracle para MySQL, PostgreSQL ou Aurora.
- OLAP — podemos migrar de Teradata ou Oracle para Amazon Redshift
Não é necessário utilizar o SCT quando o “DataBase Engine” for o mesmo
- PostgreSQL no On-Premisses para RDS PostgreSQL na AWS
AWS DMS — Multi-AZ Deployment
Quando Multi-AZ está habilitado, DMS pode prover e manter replicas sincronizadas, provendo redundancia de dados, eliminando I/O freezes e diminuindo latência ou spykes.
Maneira de fazer migrações para o Aurora MySQL. Se você tiver um banco de dados RDS e quiser movê-lo para o Aurora MySQL:
— Tirar um snapshot o do banco de dados RDS MySQL e restaurar este snapshot como um banco de dados MySQL Aurora. Potencialmente, você terá algum tempo parado porque terá que parar as operações no primeiro banco de dados MySQL antes de migrar para a Aurora.
— Utilizar e criar uma réplica de leitura da Amazon Aurora em cima do seu RDS MySQL, esta opção é mais contínua. E uma vez que o atraso da Réplica for zero, isso significa que uma vez que a Réplica Aurora tenha alcançado completamente o MySQL, você pode promovê-la em seu próprio cluster de banco de dados. Pode levar um pouco mais de tempo do que a opção que utiliza snapshot do banco de dados e custar algum dinheiro por causa do custo da rede que pode estar associado a esta replicação.
— Se você tem um banco de dados MySQL que é externo ao RDS, então você pode fazer backup usando o utilitário Percona XtraBackup. Isto criará um arquivo de backup e você o colocará no Amazon S3 e depois há uma opção da Amazon Aurora de importar diretamente este arquivo de backup para um novo cluster Aurora MySQL DB.
— Usar o utilitário MySQL Dump para executá-lo contra um banco de dados MySQL e você canalizaria a saída deste para seu banco de dados Amazon Aurora existente. Esta opção pode demorar e não utiliza o Amazon S3.
— Usar o Amazon DMS, se ambos os bancos de dados estiverem em funcionamento para fazer replicação contínua entre os dois bancos de dados.
É possível utilizar estas opções para PostgreSQL.
