Opções e considerações de HA/DR

Embora a possibilidade de uma zona ou região de AWS disponibilidade ficar completamente off-line seja extremamente rara, recomendamos uma abordagem multifacetada para backup e recuperação em caso de desastre para redundância e para minimizar a perda de dados. Os processos de backup e recuperação devem incluir o nível adequado de granularidade para atender ao objetivo de tempo de recuperação (RTO) e ao objetivo de ponto de recuperação (RPO) para o workload e para dar suporte a seus processos de negócios, e muitas vezes dependem no aplicativo. No caso de bancos de dados, AWS também oferece suporte a todas as recomendações da Microsoft para instalação e configuração do SQL Server para alta disponibilidade e recuperação de desastres (HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/developmentambiente, considere usar a edição SQL Server Developer, que é gratuita, mas vem com limitações).

Para um caso de uso que exige um RPO de 15 minutos e um RTO de 4 horas, você pode considerar uma combinação das seguintes opções de HA/DR:

• Opções nativas de HA/DR do SQL Server com standby quente (nível de banco de dados) — Para obter ilustrações de algumas dessas arquiteturas, consulte a seção Diagramas de EC2 arquitetura do SQL Server na Amazon mais adiante neste guia.

  • Dois nós, Multi-AZ em uma única região (modo de confirmação síncrona) ou em várias regiões (modo de confirmação assíncrona, grupo de disponibilidade básica)

  • Três nós (ou mais), Multi-AZ em várias regiões (modos de confirmação síncrona e confirmação assíncrona)

  • Envio de dois nós, Multi-AZ e logs em várias regiões (com backups de logs a cada 5 minutos)

• Backups nativos do SQL Server no Amazon S3 (somente em nível de banco de dados, DR) — Backups completos (uma vez por dia)

  • Backups diferenciais (a cada 2-4 horas).

  • Backups de logs (a cada 5-10 minutos).

  • Os backups precisam ser feitos e copiados para o Amazon Simple Storage Service (Amazon S3) usando scripts personalizados ou uma opção como um gateway de arquivos para backup e transferência eficientes.

  • Se você tiver centenas de bancos de dados, poderá continuar usando suas ferramentas de backup existentes (como Commvault ou Litespeed) para gerenciar backups com eficiência e armazená-los diretamente no Amazon S3.

  • Use o Amazon S3 Cross-Region Replication (CRR) com o S3 Replication Time Control (RTC) para controlar e monitorar a replicação de objetos dentro de um SLA de 15 minutos.

  • Para fins de conformidade e economia de custos, você também pode usar o gerenciamento do ciclo de vida do S3 para mover e armazenar backups antigos para armazenamento de longo prazo.

  • Se você fizer backups nativos do SQL Server e movê-los para o Amazon S3 regularmente, no caso de um desastre, os backups estarão prontamente disponíveis na região de destino. Isso elimina a necessidade de transferir backups ou restaurar snapshots.

  • Recomendamos usar o SQL Native Backup Compression para reduzir o tamanho dos arquivos.

• AWS instantâneos (nível de instância e volume, somente DR)

  • Amazon Elastic Compute Cloud (Amazon EC2) Backups da Amazon Machine Image (AMI) para reconstruir bancos de dados do zero

  • Snapshots de volume do Amazon Elastic Block Store (Amazon EBS) para anexar volumes do EBS à Amazon EC2

Gerenciando recursos de HA/DR em AWS Backup

AWS Backupé um serviço totalmente gerenciado que oferece a capacidade de criar planos e programações de backup e atribuir AWS recursos envolvidos na configuração de HA/DR, como volumes Amazon EBS para criar snapshots e Amazon, a esses planos de backup. EC2 AMIs Você também pode usar o AWS Backup para programar cópias multirregionais desses snapshots do EBS. Para um uso ideal, é AWS Backup necessário um mecanismo de marcação eficiente para que os recursos estejam disponíveis. AWS Backup também oferece suporte a backups consistentes com aplicativos por meio do Windows Volume Shadow Copy Service (VSS), que você pode usar para o SQL Server. Para proteção a nível de armazenamento, recomendamos o uso de snapshots do EBS. Os snapshots iniciais do EBS são completos, e os snapshots subsequentes são incrementais. Embora os snapshots do EBS ofereçam proteção em nível de armazenamento, eles não substituem os backups nativos baseados em arquivos do SQL Server que oferecem recuperação. point-in-time

Usando AWS DMS para HA/DR

Se você estiver procurando uma alternativa às opções Always On do SQL Server para replicação ou se tiver bancos de dados heterogêneos de origem e destino, em uma configuração híbrida ou em AWS, você pode usar AWS Database Migration Service (AWS DMS) das seguintes maneiras.

Se você usa AWS DMS com o SQL Server em um contexto autogerenciado (hospedado na Amazon EC2 ou no local), ele oferece suporte à replicação única e contínua em dois modos: usando MS-REPLICATION (para capturar alterações em tabelas que têm chaves primárias) e MS-CDC (para capturar alterações em tabelas que não têm chaves primárias). No entanto, se você usar o Amazon Relational Database Service (Amazon RDS) como fonte, somente o AWS DMS MS-CDC é suportado. AWS DMS oferece uma variedade de endpoints de origem e destino, oferece suporte a mecanismos de banco de dados heterogêneos e oferece controle refinado sobre o processo de replicação. Você também pode usar o AWS Schema Conversion Tool (AWS SCT) com AWS DMS para migrações heterogêneas de bancos de dados. AWS SCT automatiza as mudanças no nível do esquema e também produz relatórios para preparação e planejamento da migração.

Você adiciona bancos de dados de origem e destino como pontos finais AWS DMS, conforme ilustrado no diagrama a seguir. Esse serviço implementa um processo de replicação lógica usando o MS-REPLICATION ou o MS-CDC. Se você tiver uma configuração híbrida, poderá configurar AWS DMS a replicação contínua entre locais e. AWS Durante a transição, a tarefa de AWS DMS migração pode ser interrompida e o aplicativo poderá se conectar ao banco de dados que já está sincronizado com o banco de dados local sem mais demoras. O AWS DMS uso do SQL Server como fonte tem algumas limitações, descritas na AWS DMS documentação.

Considere usar, AWS DMS em vez de métodos nativos de HA/DR, nos seguintes cenários:

• Quando você quiser economizar nos custos de licenciamento. Por exemplo, se você estiver usando uma versão avançada, como a edição SQL Server Enterprise, somente para as opções Always On, AWS DMS considere configurá-la, pois ela pode fornecer uma opção de replicação lógica sem o custo de uma licença da edição Enterprise.

• Quando você tem origens e destinos heterogêneos. As versões do SQL Server nos nós primários e de recuperação de desastres não precisam ser iguais (dentro AWS DMS das limitações), o que oferece flexibilidade significativa.

• Para evitar a sobrecarga do Windows, do cluster do SQL Server e da configuração e gerenciamento de grupos de disponibilidade distribuídos. AWS DMS oferece uma configuração simples e um gerenciamento fácil das tarefas de replicação.

• Para casos de uso comercial, como transferência quase em tempo real (dependendo da instância de replicação, da configuração da rede e do volume de dados), mascaramento de dados, filtragem seletiva, mapeamento de esquema/tabela (homogêneo e heterogêneo), avaliações de pré-migração e suporte a JSON.

• Para duplicar, interromper e iniciar tarefas com facilidade, conforme necessário, com base em números de sequência de registro (LSNs), carimbos de data/hora e opções semelhantes.

O diagrama a seguir mostra uma abordagem alternativa de como AWS DMS fornecer suporte à replicação. Nessa configuração, a origem é um cluster de grupos de disponibilidade Always On do SQL Server e AWS DMS usa a opção de captura de dados de alteração (CDC) para replicar dados continuamente em um destino em uma região diferente AWS . Para obter o melhor desempenho, é fundamental garantir que a instância de replicação tenha o tamanho certo e permaneça na região de origem.

Os mecanismos de origem e de destino não precisam ser iguais. No diagrama, os nós primário e secundário marcados como (1) podem ser um cluster do SQL Server em uma configuração Single-AZ ou Multi-AZ. Ou a origem pode ser um único nó do SQL Server que ofereça suporte ao MS-CDC ou ao MS-REPLICATION.

A instância de banco de dados de destino, marcada como (2) no diagrama, pode ser qualquer versão do SQL Server no Amazon RDS, na Amazon EC2 ou em qualquer outro destino heterogêneo. Ele não precisa corresponder às instâncias primária e secundária nem oferecer suporte aos grupos de disponibilidade do Always On. Por exemplo, a origem pode ser um cluster de grupos de disponibilidade do SQL Server Always On e o destino pode ser uma edição compatível do Amazon Aurora PostgreSQL.

Usando AWS Application Migration Service para DR

Recomendamos usar o AWS Application Migration Service para lift-and-shift migrações para o. AWS O Application Migration Service replica continuamente suas máquinas (incluindo o sistema operacional, a configuração do estado do sistema, bancos de dados, aplicativos e arquivos) em uma área de armazenamento de baixo custo em sua conta da AWS de destino e região preferida. No caso de um desastre, você pode usar o Application Migration Service para iniciar automaticamente milhares de suas máquinas em seu estado totalmente provisionado em minutos.

Considerações adicionais

A lista a seguir identifica os possíveis gargalos que você deve considerar ao projetar uma estratégia de HA/DR.

• Largura de banda, latência, complexidade da rede e conectividade em uma configuração de nó multirregional.

• Tamanho dos EC2 snapshots do Amazon EBS ou da Amazon e o tempo necessário para copiá-los usando. AWS Backup

  • O Amazon EBS e os EC2 snapshots da Amazon são armazenados no Amazon S3 usando. AWS Backup

  • Um snapshot do EBS não é replicado para a região de destino no Amazon S3 até que o snapshot atual seja concluído. A duração da replicação também depende do tamanho do volume.

  • Quando o snapshot estiver concluído, o tempo de cópia dos snapshots pode ser de apenas 15 minutos para 99,99% dos objetos. No entanto, testes completos são necessários para casos de uso específicos e grandes volumes críticos.

• Tempo necessário para restaurar os volumes do EBS na zona e região de disponibilidade de destino.

• Tempo necessário para restaurar EC2 imagens da Amazon na zona de disponibilidade e região de destino.

• Se estiver construindo do zero, é necessário tempo para provisionar a infraestrutura para a EC2 imagem da Amazon ou restaurar os instantâneos do EBS na zona de disponibilidade e região de destino.

• Se estiver restaurando do zero, será necessário tempo para restaurar backups completos, diferenciais e de log nativos do SQL Server na zona e região de disponibilidade de destino.

• Dependências externas e aplicativos que precisam estar disponíveis em todas as regiões.

• Limitações nos tamanhos dos arquivos para volumes e para upload para o Amazon S3.