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á.
# Amazon EC2 para SQL Server
O Amazon EC2 oferece suporte a um banco de dados SQL Server autogerenciado. Ou seja, oferece controle total sobre a configuração da infraestrutura e do ambiente de banco de dados. Executar o banco de dados no Amazon EC2 é muito semelhante à execução do banco de dados em seu próprio servidor. Você tem controle total do banco de dados e do acesso no nível do sistema operacional e, portanto, pode usar as ferramentas de sua escolha para gerenciar o sistema operacional, o software do banco de dados, os patches, a replicação de dados, o backup e a restauração. Essa opção de migração exige que você configure, gerencie e ajuste todos os componentes, incluindo instâncias do EC2, volumes de armazenamento, escalabilidade, rede e segurança, com base nas melhores práticas de AWS arquitetura. Você é responsável pela replicação e recuperação de dados em suas instâncias na mesma região ou em AWS regiões diferentes.
## Quando escolher o Amazon EC2
O Amazon EC2 é uma boa opção de migração para seu banco de dados SQL Server quando:
+ Você precisa de controle total sobre o banco de dados e acesso ao sistema operacional subjacente, à instalação e à configuração do banco de dados.
+ Você deseja administrar seu banco de dados, incluindo backups e recuperação, corrigir o sistema operacional e o banco de dados, ajustar o sistema operacional e os parâmetros do banco de dados, gerenciar a segurança e configurar a alta disponibilidade ou replicação.
+ Você deseja usar atributos e opções que atualmente não são compatíveis com o Amazon RDS. Para obter detalhes, consulte [Atributos não compatíveis e atributos com compatibilidade limitada](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) na documentação do Amazon RDS.
+ Você precisa de uma versão específica do SQL Server que não seja compatível com o Amazon RDS. Para obter uma lista das versões e edições compatíveis, consulte as [versões do SQL Server no Amazon RDS na ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport)documentação do Amazon RDS.
+ O tamanho e as necessidades de desempenho do seu banco de dados excedem as ofertas atuais do Amazon RDS para SQL Server. Para obter detalhes, consulte [Armazenamento de instâncias de banco de dados do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) na documentação do Amazon RDS.
+ Você quer evitar patches automáticos de software que podem não ser compatíveis com seus aplicativos.
+ Você quer trazer sua própria licença em vez de usar o modelo incluído na licença do Amazon RDS para SQL Server.
+ Você deseja alcançar maior IOPS e capacidade de armazenamento do que os limites atuais. Para obter detalhes, consulte [Armazenamento de instâncias de banco de dados do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) na documentação do Amazon RDS.
Para obter uma lista dos atributos e versões do SQL Server atualmente compatíveis no Amazon EC2, consulte [Como escolher entre o Amazon EC2 e o Amazon RDS](comparison.md) mais adiante neste guia.
# Alta disponibilidade
Você pode usar qualquer tecnologia de replicação compatível com o SQL Server com seu banco de dados SQL Server no Amazon EC2 para obter alta disponibilidade, proteção de dados e recuperação de desastres. Algumas das soluções comuns são envio de log, espelhamento de banco de dados, grupos de disponibilidade Always On e Instâncias de Cluster de Failover Always On.
O diagrama a seguir mostra como você pode usar o SQL Server no Amazon EC2 em várias zonas de disponibilidade em uma única AWS região. O banco de dados principal é um banco de dados de leitura e gravação, e o banco de dados secundário é configurado com envio de log, espelhamento de banco de dados ou grupos de disponibilidade Always On para alta disponibilidade. Todos os dados da transação do banco de dados principal são transferidos e podem ser aplicados ao banco de dados secundário de forma assíncrona para envio de log e de forma assíncrona para espelhamento e grupos de disponibilidade Always On.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Envio de logs
O envio de logs permite que você envie automaticamente backups de logs de transações de uma instância de banco de dados primária para um ou mais bancos de dados secundários (também conhecidos como *espera quente*) em instâncias de banco de dados separadas. O envio de logs usa trabalhos do SQL Server Agent para automatizar o processo de backup, cópia e aplicação dos backups do log de transações. Embora o envio de logs seja normalmente considerado um atributo de recuperação de desastres, ele também pode fornecer alta disponibilidade ao permitir que instâncias de banco de dados secundárias sejam promovidas se a instância de banco de dados primária falhar. Se seu RTO e RPO forem flexíveis ou se seus bancos de dados não forem considerados altamente essenciais, considere usar o envio de logs para fornecer melhor disponibilidade para seus bancos de dados do SQL Server.
O envio de logs aumenta a disponibilidade dos bancos de dados, fornecendo acesso aos bancos de dados secundários para uso como cópias somente para leitura do banco de dados primário, quando necessário. Você pode configurar um atraso (um tempo de atraso maior) durante o qual você pode recuperar dados alterados acidentalmente no banco de dados principal antes que essas alterações sejam enviadas para o banco de dados secundário.
Recomendamos executar as instâncias de banco de dados primária e secundária em zonas de disponibilidade separadas e implantar uma instância de monitoramento para rastrear todos os detalhes do envio de log. Eventos de backup, cópia, restauração e falha para um grupo de envio de log estão disponíveis na instância do monitor. Uma configuração de envio de log não passa automaticamente do servidor primário para o servidor secundário. No entanto, qualquer um dos bancos de dados secundários pode ser colocado on-line manualmente se o banco de dados primário ficar indisponível.
O envio de log geralmente é usado como uma solução de recuperação de desastres, mas também pode ser usado como uma solução de alta disponibilidade, dependendo dos requisitos do seu aplicativo. Use o envio de log quando:
+ Você tem requisitos flexíveis de RTO e RPO. O envio de logs fornece um RPO de minutos e um RTO de minutos a horas.
+ Você não precisa de um failover automático para o banco de dados secundário.
+ Você deseja ler do banco de dados secundário, mas não precisa de legibilidade durante uma operação de restauração.
Para obter mais informações sobre o registro de log, consulte a [documentação do Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Espelhamento de banco de dados
O espelhamento de banco de dados usa um banco de dados que está em uma instância do EC2 e fornece uma cópia completa ou quase completa somente para leitura (espelho) dele em uma instância de banco de dados separada. O Amazon RDS usa espelhamento de banco de dados para fornecer suporte Multi-AZ para o Amazon RDS para SQL Server. Esse atributo aumenta a disponibilidade e a proteção dos bancos de dados e fornece um mecanismo para manter os bancos de dados disponíveis durante as atualizações.
**nota**
De acordo com a [documentação da Microsoft](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server), o espelhamento do banco de dados será removido em uma versão futura do SQL Server. Em vez disso, você deve planejar usar grupos de disponibilidade Always On.
No espelhamento de banco de dados, os servidores SQL podem assumir uma das três funções:
+ O servidor principal, que hospeda a read/write versão principal do banco de dados.
+ O servidor espelho, que hospeda uma cópia do banco de dados da entidade principal.
+ Um servidor de testemunhas opcional. Esse servidor está disponível somente no modo de alta segurança. Ele monitora o estado do espelho do banco de dados e automatiza o failover do banco de dados principal para o banco de dados espelho.
Uma sessão de espelhamento é estabelecida entre os servidores da entidade principal e espelho. Durante o espelhamento, todas as alterações do banco de dados que são realizadas no banco de dados da entidade principal também são realizadas no banco de dados espelho. O espelhamento do banco de dados pode ser uma operação síncrona ou assíncrona. Isso é determinado por dois modos de operação de espelhamento: modo de alta segurança e modo de alto desempenho.
+ **Modo de alta segurança:** este modo usa operações síncronas. Nesse modo, a sessão de espelhamento do banco de dados sincroniza as operações de inserção, atualização e exclusão do banco de dados da entidade principal com o banco de dados espelho o mais rápido possível. Assim que o banco de dados é sincronizado, a transação é confirmada nos bancos de dados da entidade principal e espelho. Recomendamos que você use esse modo operacional quando os bancos de dados espelhados estiverem na mesma zona de disponibilidade ou em zonas de disponibilidade diferentes, mas hospedados na mesma região AWS .
+ **Modo de alto desempenho:** esse modo usa operações assíncronas. Nesse modo, a sessão de espelhamento do banco de dados sincroniza as operações de inserção, atualização e exclusão do banco de dados da entidade principal para o banco de dados espelho, mas pode haver um intervalo entre o momento em que o banco de dados da entidade principal confirma as transações e o momento em que o banco de dados espelho confirma as transações. Recomendamos que você use esse modo quando os bancos de dados espelhados estiverem em AWS regiões diferentes.
Use o espelhamento de banco de dados quando:
+ Você tem requisitos rígidos de RTO e RPO e não pode ter atrasos entre os bancos de dados primário e secundário. O espelhamento do banco de dados fornece um RPO de zero segundos (com confirmação síncrona) e um RTO de segundos a minutos.
+ Você não precisa ler do banco de dados secundário.
+ Você deseja realizar o failover automático quando tiver um servidor testemunha configurado no modo de sincronização.
+ Você não pode usar grupos de disponibilidade Always On, que é a opção preferida.
Limitações:
+ Somente o one-to-one failover é suportado. Você não pode ter vários destinos de banco de dados sincronizados com o banco de dados principal.
Para obter mais informações sobre o espelhamento, consulte a [documentação do Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# Grupos de Disponibilidade Always On
Os grupos de disponibilidade Always On do SQL Server fornecem soluções de alta disponibilidade e recuperação de desastres para bancos de dados do SQL Server. Um grupo de disponibilidade consiste em um conjunto de bancos de dados de usuários que realizam failover juntos. Ele inclui um único conjunto de read/write bancos de dados primários e vários (um a oito) conjuntos de bancos de dados secundários relacionados. Você pode disponibilizar os bancos de dados secundários para a camada do aplicativo como cópias somente para leitura dos bancos de dados primários (somente na edição SQL Server Enterprise), para fornecer uma arquitetura escalável para workloads de leitura. Você também pode usar os bancos de dados secundários para operações de backup.
Os grupos de disponibilidade do SQL Server Always On oferecem suporte aos modos de confirmação síncrono e assíncrono. No modo síncrono, a réplica primária confirma as transações do banco de dados depois que as alterações são confirmadas ou gravadas no log da réplica secundária. Usando esse modo, você pode realizar um failover manual planejado e um failover automático se as réplicas estiverem sincronizadas. Você pode usar o modo de confirmação síncrona entre instâncias do SQL Server dentro do mesmo ambiente (por exemplo, se todas as instâncias estiverem no local ou se todas as instâncias estiverem dentro). AWS
No modo de confirmação assíncrona, a réplica primária confirma as transações do banco de dados sem esperar pela réplica secundária. Você pode usar o modo de confirmação assíncrona entre instâncias do SQL Server que estão em ambientes diferentes (por exemplo, se você tiver instâncias locais e internas). AWS
Você pode usar grupos de disponibilidade Always On para alta disponibilidade ou recuperação de desastres. Use esse método quando:
+ Você tem requisitos estritos de RTO e RPO. Os grupos de disponibilidade Always On fornecem um RPO de segundos e um RTO de segundos a minutos.
+ Você deseja gerenciar e executar o failover de um grupo de bancos de dados. Os grupos de disponibilidade do Always On oferecem suporte a 0 a 4 réplicas secundárias no modo de confirmação síncrona para o SQL Server 2019.
+ Você deseja usar o failover automático no modo de confirmação síncrona e não precisa de um servidor testemunha.
+ Você deseja ler do banco de dados secundário.
+ Você deseja sincronizar vários destinos de banco de dados com o banco de dados primário.
A partir do SQL Server 2016 SP1, o SQL Server Standard Edition fornece alta disponibilidade básica para um único banco de dados secundário e não legível e um ouvinte por grupo de disponibilidade. Também suporta no máximo dois nós por grupo de disponibilidade.
# Instâncias de cluster de failover Always On
As Instâncias de Cluster de Failover Always On do SQL Server (FCIs) usam o Clustering de Failover do Windows Server (WSFC) para fornecer alta disponibilidade no nível da instância do servidor. Um FCI é uma instância única do SQL Server que é instalada nos nós do WSFC para fornecer alta disponibilidade para toda a instalação do SQL Server. Se o nó subjacente apresentar falhas de hardware, sistema operacional, aplicativo ou serviço, tudo dentro da instância do SQL Server será movido para outro nó do WSFC. Isso inclui bancos de dados do sistema, logons do SQL Server, trabalhos do SQL Server Agent e certificados.
Geralmente, é preferível um FCI a um grupo de disponibilidade Always On quando:
+ Você está usando a edição SQL Server Standard em vez da edição Enterprise.
+ Você tem um grande número de bancos de dados pequenos por instância.
+ Você está constantemente modificando objetos no nível da instância, como trabalhos do SQL Server Agent, logins e assim por diante.
Há quatro opções para implantação FCIs em AWS:
+ Amazon EBS Multi-Attach com reservas persistentes
+ Servidor FSx de arquivos Amazon para Windows
+ Amazon FSx para NetApp ONTAP
+ Soluções de AWS parceiros
## Usar o Amazon EBS Multi-Attach com reservas persistentes
[O Amazon EBS Multi-Attach com NVMe reservas](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) suporta a criação do SQL Server com `io2` volumes do FCIs Amazon EBS como armazenamento compartilhado em clusters de failover do Windows Server. Esse recurso simplifica o processo de configuração do cluster de failover, permitindo que você crie um cluster de failover usando volumes `io2` do Amazon EBS. Esses volumes podem ser anexados apenas a instâncias que estejam na mesma Zona de disponibilidade. Para implantar clusters de failover do Windows Server usando `io2` volumes do Amazon EBS, você deve usar os drivers mais recentes AWS NVMe .
Os volumes do Amazon EBS e os volumes de armazenamento de instâncias são expostos como dispositivos de NVMe bloco em instâncias [baseadas em Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). Você deve ter o [AWS NVMe driver](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) instalado com o [recurso de reserva persistente SCSI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) configurado ao usar `io2` volumes do Amazon EBS para formar o WSFC e o SQL Server. FCIs
Para obter mais informações sobre esse recurso, consulte a postagem do AWS blog [Como implantar um cluster de failover do SQL Server com o Amazon EBS Multi-Attach no Windows](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) Server.
## Usando o Amazon FSx para Windows File Server
[O Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) fornece armazenamento de arquivos compartilhado totalmente gerenciado. Ele replica automaticamente o armazenamento de forma síncrona em duas zonas de disponibilidade para fornecer alta disponibilidade. Usar o FSx for Windows File Server para armazenamento de arquivos ajuda a simplificar e otimizar suas implantações de alta disponibilidade do SQL Server no Amazon EC2.
Com o Microsoft SQL Server, a alta disponibilidade é normalmente implantada em vários nós de banco de dados em um WSFC, e cada nó tem acesso ao armazenamento de arquivos compartilhados. Você pode usar o FSx Windows File Server como armazenamento compartilhado para implantações de alta disponibilidade do SQL Server de duas maneiras: como armazenamento para arquivos de dados ativos e como testemunha de compartilhamento de arquivos SMB.
Para obter informações sobre como você pode reduzir a complexidade e o custo da execução de implantações de FCI do SQL Server usando FSx o Windows File Server, consulte a postagem do blog [Simplifique suas implantações de alta disponibilidade do Microsoft SQL Server usando o Amazon FSx para Windows](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) File Server. A postagem do blog também fornece step-by-step instruções para implantar o SQL Server FCIs usando um sistema de arquivos Amazon FSx Multi-AZ como solução de armazenamento compartilhado. Para obter mais informações, consulte a documentação do [Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Usando a Amazon FSx para NetApp ONTAP
O Amazon FSx for NetApp ONTAP é um serviço totalmente gerenciado que fornece armazenamento de arquivos altamente confiável, escalável, de alto desempenho e rico em recursos, construído no sistema de arquivos ONTAP. NetApp FSx for ONTAP combina os recursos, o desempenho, os recursos e as operações de API familiares dos sistemas de NetApp arquivos com a agilidade, escalabilidade e simplicidade de um serviço totalmente gerenciado. AWS
FSx para ONTAP fornece acesso multiprotocolo aos dados por meio dos protocolos NFS, SMB e iSCSI para sistemas Windows e Linux. Você pode criar uma arquitetura SQL Server Always On FCI altamente disponível, conforme explicado em detalhes na postagem do blog [SQL Server High Availability Deployments Using Amazon FSx for NetApp ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) ONTAP. FSx for ONTAP também pode fornecer uma maneira rápida de transferir seu ambiente SQL Server para outro, a Região da AWS fim de atender aos requisitos de objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para obter mais informações, consulte a postagem do blog [Implementando HA e DR para a instância de cluster de failover sempre ativa do SQL Server](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/) usando o ONTAP. FSx
Você também pode usar AWS Launch Wizard para implantar soluções do SQL Server em AWS, com suporte para grupos de disponibilidade Always On e implantações de nó único. O Launch Wizard suporta a implantação do SQL Server Always on FCIs no Amazon EC2 FSx com o ONTAP como armazenamento compartilhado. Esse serviço poupa tempo e esforços, substituindo um processo de implantação manual complexo por um assistente guiado baseado em console que acelera a migração de suas workloads do SQL Server on-premises que dependem de armazenamento compartilhado. Para obter mais informações sobre como o Launch Wizard pode ajudá-lo a provisionar e configurar o SQL Server FCIs em horas, consulte a postagem do blog [Simplifique as implantações do SQL Server Always On com AWS Launch Wizard a Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/). O Launch Wizard também oferece suporte à implantação do SQL Server Always On FCIs usando o [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) como solução de armazenamento compartilhado.
## Usando soluções de AWS parceiros
+ O [SIOS DataKeeper](https://us.sios.com/) fornece suporte de failover de cluster de alta disponibilidade em todas as zonas Regiões da AWS de disponibilidade. O SIOS DataKeeper está disponível em [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408).
+ [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)from DH2i permite o failover totalmente automático dos grupos de disponibilidade do SQL Server no Kubernetes e o failover unificado de instâncias para Windows e Linux. O D2HI está disponível no [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b).
# FSx para Windows File Server
FSx para Windows O File Server fornece armazenamento de arquivos totalmente gerenciado, altamente confiável e escalável, acessível usando o protocolo Server Message Block (SMB). Ele é baseado no Windows Server e oferece uma ampla variedade de atributos administrativos, como cotas de usuários, restauração de arquivos para o usuário final e integração com o Microsoft Active Directory (AD). Ele oferece opções de implantação Single-AZ e Multi-AZ, backups totalmente gerenciados e criptografia de dados em repouso e em trânsito. Você pode otimizar o custo e o desempenho de suas workloads com opções de armazenamento em unidades de estado sólido (SSD) e unidades de disco rígido (HDD), além de escalar o armazenamento e alterar o desempenho da taxa de throughput do seu sistema de arquivos a qualquer momento. O armazenamento de FSx arquivos da Amazon pode ser acessado a partir de instâncias computacionais Windows e Linux executadas no AWS local e no local.
A Amazon FSx facilita a implantação de armazenamento compartilhado do Windows para implantações de alta disponibilidade do SQL Server por meio de seu suporte para compartilhamentos de arquivos continuamente disponíveis (CA) e sistemas de arquivos menores. Essa opção é adequada para esses casos de uso:
+ Como armazenamento compartilhado usado pelos nós do SQL Server em uma instância do WSFC.
+ Como testemunha de compartilhamento de arquivos SMB que pode ser usada com qualquer cluster do SQL Server com WSFC.
FSx A Amazon oferece desempenho rápido com taxa de transferência básica de até 2 GB/second por sistema de arquivos, centenas de milhares de IOPS e latências consistentes de menos de um milissegundo.
Para fornecer o desempenho certo para suas instâncias SQL, você pode escolher um nível de taxa de throughput que seja independente do tamanho do seu sistema de arquivos. Níveis mais altos de capacidade de throughput também vêm com níveis mais altos de IOPS que o servidor de arquivos pode fornecer às instâncias do SQL Server que o acessam.
A capacidade de armazenamento determina não apenas a quantidade de dados que você pode armazenar, mas também quantas IOPS você pode realizar no armazenamento. Cada gigabyte de armazenamento fornece 3 IOPS. Você pode provisionar cada sistema de arquivos para ter até 64 TB de tamanho.
Para obter informações sobre como configurar e usar FSx a Amazon para reduzir a complexidade e os custos de suas implantações de alta disponibilidade do SQL Server, consulte [Simplifique suas implantações de alta disponibilidade do Microsoft SQL Server usando o FSx Windows File Server no AWS blog Storage](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/). Para saber mais sobre a criação de um novo compartilhamento CA, consulte a [FSx documentação do Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Recuperação de desastres
Muitas organizações implementam alta disponibilidade para seus bancos de dados SQL Server, mas isso não é suficiente para organizações que precisam de verdadeira resiliência de TI. Recomendamos que você implemente uma solução de recuperação de desastres para evitar perda de dados e tempo de inatividade de bancos de dados essenciais. A adoção de uma arquitetura de recuperação de desastres em várias regiões para suas implantações do SQL Server ajuda você a:
+ Alcançar a continuidade de negócios
+ Melhorar a latência de sua base de clientes distribuída geograficamente
+ Satisfazer seus requisitos regulatórios e de auditoria
As opções para recuperação de desastres incluem [envio de registros](ec2-log-shipping.md), [grupos de disponibilidade Always On](ec2-always-on.md), [snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) que são armazenados no Amazon S3 e replicados AWS entre regiões[, instâncias de cluster de failover Always On FCIs (](ec2-fci.md)) combinadas com grupos de disponibilidade Always On e grupos de disponibilidade distribuídos.
## Grupos de disponibilidade distribuídos
Uma arquitetura com grupos de disponibilidade distribuídos é uma abordagem ideal para a implantação do SQL Server em várias regiões. Um grupo de disponibilidade distribuído é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade separados. Você pode pensar nisso como um grupo de disponibilidade de grupos de disponibilidade. Os grupos de disponibilidade subjacentes são configurados em dois clusters WSFC diferentes.
Os grupos de disponibilidade distribuídos têm acoplamento fraco, o que significa que não exigem um único cluster WSFC e são mantidos pelo SQL Server. Como os clusters do WSFC são mantidos individualmente e as transmissões são basicamente assíncronas entre dois grupos de disponibilidade, é mais fácil configurar a recuperação de desastres em outro local. As réplicas primárias em cada grupo de disponibilidade sincronizam suas próprias réplicas secundárias.
No momento, grupos de disponibilidade distribuídos oferecem suporte somente ao failover manual. Para garantir que nenhum dado seja perdido, interrompa todas as transações nos bancos de dados primários globais (ou seja, nos bancos de dados do grupo de disponibilidade principal). Em seguida, defina o grupo de disponibilidade distribuído como confirmação síncrona.