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.
-
Uma configuração de grupo de disponibilidade do SQL Server Always On para DR com dois ou mais nós fornece failover automático para o nó secundário por meio do modo de confirmação síncrona ou assíncrona, para que o banco de dados esteja disponível imediatamente. Para uma configuração de HA, os dois nós estão disponíveis para operações de leitura. Essa opção atende confortavelmente aos requisitos de RTO e RPO. Na edição SQL Server Standard, usar grupos de disponibilidade básicos também é uma opção, mas está limitado a dois nós, porque um grupo de disponibilidade pode incluir somente um banco de dados. No entanto, você pode configurar vários grupos de disponibilidade em uma região ou entre regiões. Essa configuração proporciona economia de custos, pois não há custo adicional para o nó secundário, que não é acessível para operações de leitura. A edição SQL Server Enterprise fornece funcionalidade completa e failover para todos os bancos de dados em um único grupo de disponibilidade. Para obter exemplos dessa opção, consulte os seguintes diagramas de arquitetura:
-
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. Para obter um exemplo dessa opção, consulte os seguintes diagramas de arquitetura:
-
-
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 |
|
|
|
Recursos primários |
|
|
|
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 |