Cenários de recuperação de desastres - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Cenários de recuperação de desastres

Esta seção fornece exemplos de uma única falha na zona de disponibilidade ou região da AWS e discute as opções para recuperação de desastres (DR, disaster recovery). Os exemplos pressupõem um objetivo de ponto de recuperação (RPO) de 15 minutos e um objetivo de tempo de recuperação (RTO) de 4 horas.

Falha na zona de disponibilidade

Você pode usar uma das seguintes opções para se recuperar de uma única falha na zona de disponibilidade dentro dos parâmetros fornecidos (RPO de 15 minutos, RTO de 4 horas).

  • Provisione a recuperação do aplicativo usando o backup de imagem mais recente do Amazon Elastic Compute Cloud (Amazon EC2) e conecte-se à instância de banco de dados standby quente existente por meio de uma implantação de grupo de disponibilidade Always On ou envio de logs.

  • Se você tiver um aplicativo como o SQL Server Reporting Services (SSRS) que tenha uma implantação em escala horizontal, o balanceador de carga poderá redirecionar todo o tráfego para o nó secundário.

  • Você pode usar AMIs baseadas no Amazon EC2 para o servidor de aplicativos e bancos de dados para provisionar a infraestrutura. Os bancos de dados podem ser restaurados em uma nova zona de disponibilidade, dependendo do tamanho e da frequência de backup, a partir dos backups nativos mais recentes (backup completo, backup diferencial ou backups de logs de transações a cada 5 minutos) ou usando snapshots do EBS. Essa opção atende aos requisitos de RPO e RTO, mas requer scripts personalizados. Você também deve considerar o tempo necessário para provisionar a infraestrutura, e atender aos requisitos de RPO e RTO pode ser um desafio.

  • As imagens do Amazon EC2 (incluindo volumes do EBS) para aplicativos e para o servidor de banco de dados podem ser restauradas em uma nova zona de disponibilidade. O RPO pode ser desafiador, dependendo do backup mais recente, mas essa opção pode ser combinada com os logs de transações mais recentes para atender aos requisitos. Essa opção oferece suporte a snapshots do Windows Volume Shadow Copy Service (VSS).

Falha de região

Você pode usar uma das seguintes opções para se recuperar de uma única falha na Região da AWS dentro dos parâmetros fornecidos (RPO de 15 minutos, RTO de 4 horas).

  • Você pode usar imagens de máquina da Amazon (AMIs) baseadas no Amazon EC2 para o servidor de aplicativos e bancos de dados para provisionar a infraestrutura. Os bancos de dados podem ser restaurados em uma nova Região, dependendo do tamanho e da frequência de backup, a partir dos backups nativos mais recentes (backup completo, backup diferencial ou backups de logs de transações a cada 5 minutos). Essa opção atende aos requisitos de RPO e RTO, mas requer scripts personalizados.

    • O envio de registros do SQL Server como uma solução de DR requer um failover manual para um servidor em espera e depende da frequência dos backups de log. Essa é uma das opções de DR mais baratas. As edições do SQL Server para o local de DR primário e enviado por log não precisam corresponder. Essa opção atende ao RPO (usando backups de logs de transações a cada 5 minutos) e ao RTO, mas requer manutenção por meio de scripts manuais e personalizados. Bancos de dados grandes exigem tempos de restauração longos.

  • Você pode usar uma AMI do Amazon EC2 para o aplicativo e o servidor de banco de dados e restaurá-la para um destino em uma nova região. O RPO depende do tamanho e da frequência dos backups.

    • As imagens mais recentes do aplicativo podem ser restauradas usando uma AMI. Você pode usar backups diferenciais nativos recentes ou de logs de transações a cada 5 minutos para atualizar o banco de dados para atender ao RPO.

    • O RTO depende do tamanho e do tempo para transferir e restaurar os snapshots para a nova região, se a origem ainda não estiver sincronizada com o destino.

  • A solução com o menor tempo de inatividade é restaurar a imagem de backup do aplicativo e ter um nó SQL Server em standby quente em uma região remota usando uma configuração de grupo de disponibilidade de dois, três ou quatro nós (básica, clássica ou distribuída) e conectar-se ao servidor de banco de dados em espera após um failover. A réplica do modo de confirmação síncrona atende aos requisitos de RPO, enquanto a réplica do modo de confirmação assíncrona pode ser adiada dependendo do volume de transações. Você pode usar uma configuração de grupo de disponibilidade distribuído para aumentar a escala horizontalmente os nós do banco de dados em uma nova região, se necessário. Essa configuração também reduz a complexidade porque usa dois grupos de disponibilidade independentes em vez de um único grupo de disponibilidade distribuído pelas regiões no modo de confirmação síncrona ou assíncrona e atende confortavelmente aos requisitos de RTO e RPO. Como alternativa, usar grupos de disponibilidade básica do SQL Server na edição Standard também é uma opção. No entanto, ele tem limitações, porque suporta somente até dois nós, e somente um banco de dados pode estar em um único grupo de disponibilidade, embora vários grupos de disponibilidade sejam suportados. Você pode configurar a edição SQL Server Standard em uma região ou entre regiões. Esta edição oferece economia de custos porque não cobra pelo nó secundário, que não é acessível para operações de leitura. A edição SQL Server Enterprise fornece funcionalidade completa e é compatível com o failover de todos os bancos de dados em um único failover de grupo de disponibilidade.

Casos de uso comuns

Como um exercício de dimensionamento, 80% dos aplicativos do SQL Server executados no Amazon EC2 que têm uma workload normal de processamento de transações on-line (OLTP) podem ser agrupados em uma das três categorias com base em sua importância:

  • SQL Server HA/DR com backups do SQL Server, usando duas réplicas de confirmação síncrona e uma réplica em modo de confirmação assíncrona

  • AWS Backup HA/DR com backups do SQL Server, usando uma AMI do Amazon EC2 para o aplicativo e o banco de dados, e armazenamento Amazon EBS

  • AWS Backup HA/DR com backups do SQL Server, usando uma AMI do Amazon EC2 para o servidor do banco de dados, uma imagem do Amazon EC2 para o aplicativo e snapshots do Amazon EBS

A tabela a seguir fornece detalhes sobre cada categoria.

  HA/DR do SQL Server com backups do SQL Server AWS Backup HA/DR com AMIs, armazenamento EBS e backups do SQL Server AWS Backup HA/DR com AMIs, snapshots EBS e backups do SQL Server

Processo de restauração em caso de desastre

  • Restaure a AMI base do Amazon EC2 para o aplicativo a partir do AWS Backup

  • Failover para a instância em espera na região (no caso de falha na zona de disponibilidade) ou para a instância entre regiões (no caso de falha na região)

  • Atende aos requisitos de RPO e RTO

  • Restaure imagens do Amazon EC2 a partir de backups do aplicativo e do banco de dados

  • Fornece suporte em regiões e entre regiões

  • Aplique os backups diferenciais e de log de transações mais recentes do SQL Server (a cada 15 minutos) para atender aos requisitos de RPO e RTO do banco de dados

  • Restaure a imagem do Amazon EC2 a partir do backup para o aplicativo

  • Restaure a AMI base do Amazon EC2 para o servidor do banco de dados

  • Restaure snapshots do EBS (se houver)

  • O cluster precisa ser reconstruído

  • Fornece suporte em regiões e entre regiões

  • Aplique os backups diferenciais e de log de transações mais recentes ao banco de dados para atender aos requisitos de RPO, mas pode não atender o RTO

Recursos primários

  • Três licenças da edição SQL Server Enterprise (a licença passiva de nós HA e DR é gratuita se você tiver um contrato de licenciamento de Software Assurance existente com a Microsoft; veja o anúncio)

  • Espaço de backup do Amazon EC2 no Amazon Simple Storage Service (Amazon S3)

  • Transferência de dados entre regiões

  • Uma licença do SQL Server (qualquer edição).

  • Espaço de backup do Amazon EC2 no Amazon S3

  • Backups do SQL Server (arquivos diferenciais e de log) no Amazon S3

  • Transferência de dados entre regiões

  • Uma licença do SQL Server (qualquer edição).

  • Espaço de backup do Amazon EC2 no Amazon S3

  • Backups do SQL Server (arquivos diferenciais e de log) no Amazon S3

  • Transferência de dados entre regiões

HA/DR

Oferece HA e DR

Oferece somente DR

Oferece somente DR

RPO

O failover é tratado pelo grupo de disponibilidade do SQL Server (o DR é manual)

Manual ou com script personalizado

Manual ou com script personalizado

RTO

Segundos para minutos

Minutos para horas

Várias horas

Risco de perder SLAs

Baixo

Médio

Alto

Capacidade de gerenciamento

Simples

Médio

Médio

Escalabilidade

Simples

Médio

Médio

Limitações de tamanho de arquivo para uploads para o Amazon S3 ou transferência entre regiões

N/A — Manipulado no modo de confirmação síncrona ou no modo de confirmação assíncrona para um standby quente

Sim

Sim

Perda de dados

Quase zero (depende da workload e da infraestrutura provisionada)

Depende da frequência das imagens de backup do Amazon EC2 e dos backups do SQL Server

Depende da frequência das imagens de backup do Amazon EC2 ou dos snapshots de EBS e dos backups do SQL Server

Custos

Médio

Baixo - médio

Baixo - médio